이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 초기 모놀리식 구조로 개발했다가 기능이 늘면서 마이크로서비스로 전환하는 경험을 했습니다. 처음엔 빠르게 만들기 위해 단일 서버로 시작했는데, 사용자 인증·상품·주문 모듈이 하나의 코드베이스에 얽히면서 한 부분 수정이 다른 부분에 영향을 주기 시작했습니다. 각 모듈을 분리하고 REST API로 연결하는 구조로 바꾸면서 독립 배포가 가능해졌고 장애 격리도 됐습니다. 아키텍처 선택에서 배운 건 처음부터 최적 구조를 선택하는 것보다 현재 팀 규모와 복잡도에 맞는 구조를 선택하는 것이 중요하다는 것입니다. 과도한 분리는 오히려 서비스 간 통신 오버헤드와 운영 복잡도를 높입니다. 필요한 순간에 확장하는 판단이 더 현실적입니다. 이 과정에서 아키텍처 결정은 현재 요구사항과 미래 확장성 사이의 균형에서 나온다는 걸 배웠습니다.
서비스 규모가 커지면서 컴포넌트 간 동기 호출이 누적될수록 전체 시스템의 가용성이 낮아지는 문제를 경험했습니다. 특정 서비스가 느려지면 그것을 동기로 호출하는 다른 서비스도 같이 느려지는 패턴이 반복됐고, 이벤트 드리븐 방식으로 전환해서 서비스 간 의존성을 이벤트 큐를 통해 비동기로 분리했습니다.
이벤트 드리븐 아키텍처(EDA) 가 서비스 간 결합도를 낮추고 각 컴포넌트가 독립적으로 스케일링되는 구조를 만드는 방식입니다. 트레이드오프로 이벤트 순서 보장과 중복 처리 방지를 위한 멱등성 설계가 추가로 필요했는데, 이 부분이 비동기 구조의 복잡도를 높이는 지점이었습니다. 결과적으로 특정 서비스 장애가 전체 시스템으로 전파되는 범위가 줄어들었습니다.
느슨한 결합이 전체 시스템의 회복 탄력성을 높입니다. EDA 패턴이 서비스 간 의존성을 낮추는 실질적인 설계 도구였습니다.
시스템 설계에서 자주 요청되는 데이터를 매번 DB에서 조회하는 패턴이 병목을 만든다는 것을 실제로 경험했습니다. 읽기 트래픽이 급증하면서 DB 연결이 포화되는 상황이 생겼고, 캐싱 레이어를 추가해서 자주 조회되는 데이터는 Redis에서 서빙하도록 아키텍처를 변경했습니다.
Cache-Aside 패턴이 DB 조회 빈도를 낮추면서 동시에 데이터 일관성을 유지하는 캐싱 전략입니다. 트레이드오프로 캐시 만료 정책과 캐시 무효화 로직이 복잡해졌고, 특히 데이터가 변경됐을 때 캐시와 DB의 동기화 타이밍이 이슈가 됐습니다. TTL 기반 만료와 명시적 무효화를 혼합하는 방식으로 운영하면서 안정화됐습니다.
성능 문제의 70%는 잘못된 데이터 접근 패턴에서 시작됩니다. Cache-Aside 패턴 이해가 시스템 성능 설계의 핵심 기반이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.