이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
API 설계에서 가장 중요하게 생각하는 원칙은 일관성입니다. 응답 구조, 에러 포맷, 네이밍 규칙이 엔드포인트마다 달라지면 클라이언트 개발자가 문서를 읽어도 예측이 안 됩니다. 팀 프로젝트에서 백엔드 API를 설계할 때, 처음엔 각자 편한 방식으로 만들었더니 프론트 팀에서 에러 처리 방식이 달라 혼란스럽다는 피드백을 받았습니다. 그 이후 공통 응답 래퍼와 에러 코드 표준을 먼저 정하고 시작했고, 연동 오류가 눈에 띄게 줄었습니다.
REST에서는 HTTP 상태 코드와 메서드를 의미에 맞게 쓰는 것도 일관성의 일부라고 생각합니다. 좋은 API는 문서 없이도 어느 정도 예측 가능한 계약이어야 한다고 봅니다. 일관된 API 계약이 있으면 협업 속도가 빨라지고 통합 오류가 줄어듭니다. 설계 단계에서 시간을 쓰는 것이 개발 전체 비용을 낮추는 방법입니다.
팀 프로젝트에서 백엔드와 프론트엔드가 API 응답 구조를 다르게 원하는 상황이 생겼습니다. 백엔드는 DB 구조에 가까운 형태를 선호했고, 프론트는 화면에서 바로 쓸 수 있는 형태를 요청했습니다. 양쪽 모두 타당한 이유가 있었는데, 논의가 길어지면서 시간이 소모되고 있었습니다. 해결한 방식은 양쪽 선호를 동시에 만족시키려 하지 않고, 변경 비용이 더 낮은 쪽에 맞추는 기준을 먼저 정하는 것이었습니다. 프론트에서 가공하는 것이 백엔드에서 추가 엔드포인트를 만드는 것보다 비용이 낮다는 판단이 나왔고, 그것으로 방향이 정해졌습니다.
의견 충돌을 해결할 때 각자가 옳고 그름을 따지기보다 변경 비용을 기준으로 삼으면 감정이 아닌 논리로 결론이 납니다. 팀 내 API 의견 조율은 기술 판단만큼 소통 설계가 중요합니다.
API 설계에서 또 하나 중요하게 생각하는 것은 지금 필요한 것만 설계하고 나중에 필요해지면 확장하는 방식입니다. 처음부터 모든 경우를 대비한 설계를 하면 복잡성이 올라가고, 실제로 쓰이지 않는 엔드포인트가 생기는 경우가 많습니다. 프로젝트에서 '나중에 쓸 것 같아서' 만든 API 파라미터가 실제로는 사용되지 않고 문서에서만 있었던 경험이 있습니다. 그것을 유지하면서 오히려 다른 팀원이 어디에 쓰이는지를 이해하는 데 시간을 썼습니다.
지금 쓰지 않는 것은 설계하지 않는 것이 유지보수 비용을 줄이는 방법입니다. 단순한 API가 변경이 쉽고, 변경이 쉬우면 요구사항이 바뀌어도 대응이 빠릅니다. 일관성이 기본 원칙이라면 단순성은 그것을 유지하게 만드는 전제 조건입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 HL그룹 인프라 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.