면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
API 설계에서 저는 일관성 · 변경 가능성 · 실패 처리 세 가지를 봅니다. 자원 명명과 HTTP 메서드 사용을 규칙으로 고정해 사용하는 쪽이 문서 없이도 예측할 수 있게 만듭니다.
변경 가능성은 버전 정책으로 다룹니다. 응답 필드는 추가에는 열어 두되 제거나 의미 변경은 새 버전으로 분리했습니다. 실패 처리가 특히 중요합니다. 오류 코드 체계를 클라이언트가 분기 가능한 수준으로 나누고, 재시도 가능 여부를 응답에 명시했습니다. 재시도 가능 여부를 알리지 않으면 클라이언트가 위험한 재시도를 하거나 복구 가능한 실패를 포기합니다.
데이터베이스 설계에서 저는 조회 패턴을 먼저 확인합니다. 정규화 수준은 그다음 문제라고 봅니다.
주요 조회가 어떤 조건으로 얼마나 자주 들어오는지에 따라 인덱스와 비정규화 여부가 결정됩니다. 이전 프로젝트에서 정규화를 우선해 설계했다가 목록 조회에 조인이 다섯 단계 필요해진 적이 있습니다. 자주 함께 읽히는 필드를 일부 복제하고 갱신 시점을 명확히 하는 것으로 조회 성능을 회복했습니다. 다만 복제한 데이터는 반드시 갱신 책임을 한 곳으로 모아 불일치 위험을 줄였습니다.
보안 체계를 세울 때 가장 먼저 하는 일은 지킬 대상을 정하는 것입니다. 모든 것을 같은 수준으로 보호하려 하면 예산도 운영도 감당이 안 됩니다.
저는 자산을 식별해 데이터 민감도와 서비스 중요도로 등급을 나누고, 등급별로 접근 통제·암호화·로그 보관 수준을 다르게 적용했습니다. 그다음이 접근 권한입니다. 최소 권한 원칙으로 기본을 차단하고 필요한 것만 여는 방식이 반대보다 안전합니다. 마지막이 탐지입니다. 침해를 완전히 막을 수는 없다고 보고, 이상 징후를 알아챌 수 있는 로그를 설계 단계에서 확보했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.