이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
아키텍처 결정에서 가장 먼저 묻는 것은 지금 풀어야 할 문제가 무엇인가입니다. 어떤 아키텍처가 좋은지보다 현재 시스템에서 어떤 문제가 가장 크게 작동하는지를 파악하는 것이 먼저였고, 문제가 명확하지 않으면 방향이 쉽게 흔들렸습니다.
선택지 간 트레이드오프를 팀과 명시적으로 비교했습니다. A는 빠르지만 운영이 복잡하고, B는 느리지만 단순하다처럼 장단점을 나열하면 팀이 같은 맥락에서 결정에 참여할 수 있었고, 결정 후 이견이 생길 가능성도 줄었습니다.
팀 역량과 변경 비용도 고려했습니다. 이론적으로 좋은 아키텍처가 현재 팀에 적합하지 않은 경우가 있어, 도입 비용과 유지보수 부담을 현실적으로 평가했습니다. 지금 감당할 수 있는 복잡도를 기준으로 결정하면, 과도한 설계로 인한 기술 부채를 줄일 수 있었습니다.
아키텍처 결정에서 의견이 갈릴 때 설득보다 데이터로 먼저 비교하는 방식을 쓰게 됐습니다. 팀 프로젝트에서 메시지 큐를 도입할지 말지를 두고 의견이 나뉘었는데, 양쪽 모두 경험이 없어 어느 주장이 맞는지 판단할 기준이 없었습니다. 그래서 작은 POC를 직접 만들어보기로 했습니다.
RabbitMQ를 로컬에 띄우고 현재 동기 처리 방식과 비교하는 테스트를 이틀 안에 만들었습니다. 초당 처리량과 오류 격리 여부를 측정하니 비동기 방식이 특정 트래픽 패턴에서 3배 빠른 걸 수치로 확인할 수 있었습니다. 그 결과를 팀에 공유하니 토론보다 빠르게 방향이 잡혔습니다. POC는 결정이 어려울수록 빠르게 만들어 보는 것이 가장 좋은 합의 방법이라는 걸 알았습니다.
마이크로서비스 아키텍처를 너무 이른 시점에 도입했다가 오히려 개발 속도가 느려지는 경험을 했습니다. 팀이 3명이고 서비스가 작았는데, 네트워크 지연·서비스 간 계약·배포 조율이 모두 새 문제가 됐습니다. 처음엔 아키텍처를 계속 개선하면 해결될 거라 생각했는데, 몇 주가 지나도 복잡도만 쌓이고 기능 개발은 멈췄습니다. 결국 모노리스로 되돌리는 결정을 팀과 함께 내렸습니다. 돌아가는 과정에서 어떤 부분이 진짜 분리가 필요했는지가 더 명확해졌고, 도메인 경계만 먼저 코드 안에서 나눈 뒤 필요할 때 서비스를 분리하는 순서가 맞다는 걸 알았습니다. 아키텍처 결정은 되돌릴 수 있는 결정은 빠르게, 되돌리기 어려운 결정은 늦게 내리는 원칙을 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.