이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 트래픽이 예상되는 졸업 프로젝트에서 아키텍처 설계를 처음 고민해봤습니다. 서비스를 기능 단위로 분리해 각각 독립적으로 배포·확장할 수 있는 구조를 목표로 했고, API 게이트웨이로 요청을 분산하는 방식을 적용했습니다. 고성능을 위해 자주 조회되는 데이터는 캐시 레이어를 두어 DB 부하를 줄이는 방향을 잡았고, 확장성은 수평 확장이 가능하도록 상태를 외부 저장소에 분리하는 구조로 설계했습니다. 안정성 측면에서는 서킷 브레이커 패턴을 학습해 다운스트림 장애가 전체로 전파되지 않는 방어 구조를 추가했습니다. 실무 수준은 아니지만, 설계 원칙을 직접 구현해보면서 왜 이런 패턴이 필요한지를 이해했습니다. 이 경험으로 아키텍처 설계는 현재 요구사항보다 변화에 유연하게 대응할 수 있는 구조를 먼저 고민해야 한다는 걸 배웠고, 설계 결정의 이유를 문서화하는 습관도 생겼습니다.
백엔드 아키텍처에서 성능 문제의 상당 부분이 데이터베이스 설계와 쿼리 패턴에서 비롯된다는 것을 경험했습니다. 아키텍처 접근 방식으로는 읽기 요청이 많은 서비스는 읽기 전용 복제본을 분리하고, 쓰기 트래픽은 주 DB로만 라우팅하는 CQRS 방향을 검토했습니다. 고성능을 위해서는 N+1 문제를 방지하기 위한 쿼리 최적화와 인덱스 설계가 기본이고, 자주 조회되는 데이터는 캐시 레이어를 두어 DB 왕복을 줄이는 방식을 적용했습니다. 확장성 측면에서는 수평 확장 가능한 상태 비저장(stateless) 서버 구조를 만들어야 오토스케일링이 효과적으로 작동합니다. 프로젝트에서 서비스 초기에 단일 DB로 시작했다가 트래픽이 늘면서 쿼리 응답 시간이 길어지는 경험을 했고, 이를 계기로 인덱스 재설계와 자주 조회되는 결과 캐싱을 도입해 응답 시간을 절반으로 줄인 경험이 있습니다. 안정성은 DB 연결 풀 설정과 타임아웃 정책을 명확히 해서 연결 고갈로 인한 장애를 방지하는 방향으로 접근했습니다.
고성능 아키텍처는 DB가 얼마나 적게 호출되는가를 설계하는 것입니다.
백엔드 서비스에서 확장성 문제가 가장 많이 나타나는 구간은 동기 처리가 긴 구간이라는 것을 경험으로 배웠습니다. 아키텍처 접근 방식으로는 시간이 오래 걸리는 작업은 메시지 큐를 통해 비동기로 처리하고, 요청자에게 즉시 응답하는 방식을 선택했습니다. 이렇게 하면 하나의 느린 요청이 전체 서비스를 블로킹하는 문제를 방지할 수 있습니다. 고성능을 위해서는 연결 풀과 I/O 비동기 처리가 핵심이고, 잦은 DB 호출을 줄이기 위해 배치 조회나 Redis 캐싱을 활용했습니다. 확장성 경험으로는 이벤트 기반 구조를 적용해 생산자와 소비자를 분리하면 소비자 수를 늘리는 것만으로 처리량을 선형적으로 확장할 수 있다는 것을 프로젝트에서 확인했습니다. 안정성은 실패한 메시지를 재처리할 수 있는 DLQ(Dead Letter Queue) 구조와 멱등성 설계를 함께 갖춰야 비동기 시스템이 신뢰성 있게 작동합니다.
확장 가능한 서비스는 처리량이 늘어도 구조 변경 없이 버틸 수 있어야 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.