이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 수업 이후 직접 작은 쇼핑몰 사이드 프로젝트를 만들며 이커머스 아키텍처를 처음 깊이 들여다봤습니다. 주문이 들어오면 재고를 먼저 예약하고 결제가 성공하면 확정, 실패하면 예약을 해제하는 흐름을 구현하면서 재고 동시성 문제가 처음 발목을 잡았습니다. 두 요청이 동시에 같은 재고를 확인하면 음수 재고가 생기는 케이스가 실제로 재현됐고, SELECT FOR UPDATE로 비관적 락을 적용해 막았습니다. 처리량이 줄어드는 트레이드오프를 확인했고, 그 다음엔 낙관적 락도 비교 실험해서 충돌 빈도가 낮은 상품 유형에는 낙관적 락이 더 효율적이라는 걸 수치로 확인했습니다. CRM과 물류 연동은 웹훅으로 구성해서 서비스 간 결합도를 낮추는 방향을 택했습니다.
이커머스 구조는 단순해 보이지만 각 경계마다 정합성 설계가 필요한 자리라는 걸 그때 배웠습니다.
이커머스 사이드 프로젝트에서 주문·결제·재고를 처음에 한 서비스에 묶었다가 문제가 생겼습니다. 주문이 들어오면 재고 확인, 결제 승인, 상태 업데이트가 한 트랜잭션에서 일어나는데 어느 하나가 실패하면 전체가 롤백되어야 하는 구조라 코드가 점점 얽혔습니다. 도메인을 명확하게 나누고 결제 완료 이벤트를 구독해서 주문 확정을 처리하도록 바꿨더니 각 도메인이 독립적으로 테스트 가능해졌습니다. CRM과 물류는 이벤트 기반으로 느슨하게 연결해서 결제 도메인에 변경이 생겨도 물류 쪽에 영향이 가지 않는 구조로 분리했습니다. 처음에는 도메인 경계를 어디에 그을지 감이 없었는데, 이 기능이 바뀌면 어느 도메인에 영향을 주는가를 물어보는 방식으로 경계를 잡기 시작했습니다. 이커머스 IT 구조는 기능 목록이 아니라 경계와 연결 방식이 핵심이라는 결이 남았습니다.
이커머스 프로젝트에서 플래시 세일 이벤트 시뮬레이션을 해봤을 때, 동시 요청이 몰리면서 재고 처리가 밀리는 현상이 발생했습니다. 모든 요청이 DB에 직접 쓰는 구조라 연결 풀이 금방 소진됐고, 일부 요청은 타임아웃이 났습니다. 메시지 큐로 주문 요청을 버퍼링해서 처리 속도를 평탄화하는 방식을 도입했고, 큐 뒤에서 순서대로 처리하도록 변경했습니다. 이 구조에서는 사용자가 즉시 확인 응답을 받고, 실제 재고 확정은 큐 처리 후 별도로 알림이 가는 방식이었습니다. 피크 트래픽 상황에서는 일관성보다 가용성을 우선하는 설계가 사용자 경험에 유리할 수 있다는 것을 직접 확인했습니다. 트래픽 패턴이 균일하지 않은 서비스일수록 스파이크 흡수 구조를 미리 설계하는 결이 중요하다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 K2코리아 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.