이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
다중 마켓 추상화를 설계할 때 핵심은 공통 인터페이스를 정의하고, 마켓별 차이는 구현체로 격리하는 것입니다. 국가마다 세금 계산 방식, 결제 수단, 배송 정책, 언어가 다른데 이것을 if-else로 하드코딩하면 마켓이 하나 추가될 때마다 기존 코드를 건드려야 하는 구조가 됩니다. Strategy 패턴이나 플러그인 구조로 마켓별 규칙을 독립 모듈로 분리하면 기존 코드 수정 없이 새 마켓을 추가할 수 있습니다. 또한 설정 주도(config-driven) 방식으로 마켓별 차이를 코드가 아닌 설정으로 관리하면 배포 없이 조정이 가능합니다. 학교 프로젝트에서 여러 국가 대상 이커머스 가격 계산 모듈을 만들 때 국가 코드를 키로 하는 설정 맵으로 세율과 환율을 외부화했고, 신규 국가 추가 시 설정 파일만 수정하면 됐습니다.
확장 가능한 설계는 처음부터 변경이 발생할 지점을 예측하고 격리하는 것에서 시작한다는 것을 그때 배웠습니다.
다중 마켓 추상화를 설계할 때 제가 가장 먼저 분리하는 것은 비즈니스 규칙 계층과 데이터 표현 계층입니다. 국가마다 날짜·통화·주소 형식이 다르고, 이것을 비즈니스 로직 안에 섞으면 하나의 수정이 연쇄 오류를 만드는 구조가 됩니다. 팀 프로젝트에서 다국어 대시보드를 만들 때, 처음에는 각 언어별로 컴포넌트를 따로 만들었는데 번역 수정이 생길 때마다 모든 컴포넌트를 함께 고쳐야 하는 문제가 생겼습니다. 리팩터링을 통해 언어 파일을 외부 JSON으로 분리하고 컴포넌트는 키만 참조하도록 바꿨더니, 번역 수정이 JSON 파일 하나로 해결됐습니다. 이 경험에서 변화가 자주 생기는 부분을 코드 바깥으로 꺼내는 것이 다중 환경 설계의 출발점이라는 것을 체감했습니다. 지역 확장은 처음에 어떤 것을 고정하고 어떤 것을 유동으로 설계하느냐에 따라 나중에 드는 비용이 크게 달라집니다.
다중 마켓 추상화 설계에서 기술적 결정만큼 어디까지 공통화하고 어디서부터 분리할지 경계를 합의하는 것이 중요합니다. 공통화를 너무 넓게 잡으면 특정 마켓의 요구를 수용하지 못하고, 너무 좁게 잡으면 중복 코드가 쌓입니다. 팀 프로젝트에서 글로벌 결제 모듈을 만들 때, 처음에 팀 전체가 공통 코드베이스를 하나로 유지하려 했습니다. 그러다 북미와 유럽의 세금 처리 방식이 구조적으로 달라서 공통 모듈 안에 분기문이 계속 쌓이는 문제가 생겼습니다. 저는 공통 인터페이스만 고정하고 각 지역 구현체를 분리하는 방향을 제안했고, 팀원들과 어떤 것이 진짜 공통인지를 먼저 목록화했습니다. 결제 흐름 자체는 공통이었지만 세금 계산·환불 정책·영수증 형식은 지역별로 달랐고, 이 경계를 명확히 하자 분기문이 거의 사라지고 각 지역 구현체가 독립적으로 테스트 가능해졌습니다. 추상화의 경계는 코드보다 팀이 먼저 합의해야 하는 것이라는 것을 그 프로젝트에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.