이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
오버엔지니어링은 현재 필요하지 않은 복잡성을 미리 구축하는 것이고, 언더엔지니어링은 당장 동작하게만 만들고 확장 가능성을 무시하는 것이라고 생각합니다.
인턴 때 간단한 알림 기능을 맡았는데, 처음에는 메시지 큐와 재시도 로직까지 설계했습니다. 그런데 당시 DAU가 200명 수준이라 단순 HTTP 호출로도 충분했고, 결국 복잡한 설계가 개발 속도만 늦추는 결과를 낳았습니다. 반대로 팀 내 다른 기능은 하드코딩으로 급하게 배포했다가 세 달 뒤 구조 전체를 다시 짜야 하는 상황이 생겼습니다.
그 경험 이후 저는 현재 사용자 규모와 6개월 내 예측 규모를 함께 고려해 설계 복잡도를 조율합니다. 지금 당장 필요한 수준보다 한 단계 정도만 더 유연하게 만드는 것이 적절한 균형점이라는 판단입니다.
오버/언더엔지니어링의 경계는 지금 이 규모에서 이 복잡성이 정당한가를 묻는 것에서 출발한다고 생각합니다. 팀 프로젝트에서 마이크로서비스 구조를 도입할지 논의했을 때, 기능 범위가 충분히 명확하지 않은 상태였습니다. 현재 팀원 수, 예상 DAU, 서비스 경계가 얼마나 안정적인지를 점검하고 나서 모놀리식으로 시작해 경계가 명확해지면 분리하는 방향으로 결정했습니다.
모듈 경계는 마이크로서비스처럼 명확하게 가져가면서도 배포는 하나로 유지한 결과, 초기 운영 복잡도가 낮아졌습니다. 기준은 현재 트래픽과 6개월 내 예측치를 함께 보는 것이었습니다. 6개월 후에도 이 구조가 버틸 수 있는가를 물어보면, 지금 당장 필요한 수준이 어느 정도인지 윤곽이 잡혔습니다. 설계 결정은 추상적 원칙이 아니라 현재 맥락에서 내려야 한다는 결이 남았습니다.
마이크로서비스 구조가 멋있어 보여서 처음부터 서비스를 5개로 나눴습니다. 기능별로 경계를 그었고, 배포도 각각 독립적으로 했습니다. 초반에는 구조가 깔끔해 보였는데 팀이 3명이다 보니 서비스 간 통신 오류를 추적하는 데 시간이 더 걸리기 시작했습니다.
분산 트레이싱도 없었고, 한 기능을 바꾸면 어느 서비스에 영향이 가는지 파악하는 것 자체가 부담이 됐습니다. 결국 3개 서비스를 하나로 합치는 결정을 했고, 오히려 개발 속도가 빨라졌습니다. YAGNI 원칙을 그때 처음 이해했습니다. 지금 필요하지 않은 구조는 지금 만들지 않는 것이 원칙이었는데, 그 원칙을 경험으로 배운 셈입니다.
오버엔지니어링의 비용은 구조 자체가 아니라 그 구조를 유지하는 팀 역량이 감당할 수 있는가에서 드러나는 결이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오모빌리티 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.