PAYCO 쇼핑 서비스 소개
발표자와 PAYCO 쇼핑을 소개한다. 검색 기반 큐레이션 커머스로, 여러 입점 파트너로부터 상품 데이터를 수집해 알고리즘·마케팅·유저 검색으로 노출하고 구매·주문 데이터를 다시 수집해 서비스를 정밀화하는 컨셉으로 개발이 시작됐다.
PAYCO 쇼핑은 부서에서 자체 개발하던 커머스 플랫폼 NCP 위에 얹는 형태로 출발했다. 자바·SaaS 기반에 프론트 API가 제공돼 공통 부분을 재사용하고 필요한 것만 추가하면 될 것 같아, 두 달 반 정도의 짧은 기간에 로드밸런서·Redis 캐시를 둔 아키텍처로 오픈했다.
공통 소스를 모두 `common` 모듈에 몰아넣다 보니 이 모듈이 '모든 걸 집어삼키는 괴물'이 됐다. 코드 100만 라인·클래스 1만 개에 `common` 빌드만 2분 넘게 걸리고, 테스트·배포 시간도 급증해 배포 담당·시간을 매번 조율하는 등 생산성이 급락했다.
뒤죽박죽 섞인 소스를 단순히 레포만 나누는 방식은 빌드 시간을 그대로 두는 미봉책이라 판단했다. 프레임워크가 스프링 4점대에 머물러 있던 상황에서, 커플링을 줄이고 독립적 스케일아웃과 개발 언어 자유도를 얻기 위해 아예 마이크로서비스 아키텍처로 전환하기로 했다.
업무 메뉴를 기준으로 도메인을 분류하되, 소스 중복·배포 주기·내부 통신량·분산 트랜잭션 필요 여부를 고려해 일부는 다시 묶었다. 최종적으로 어드민·프론트 API 등을 포함한 8개 마이크로서비스로 정리하고 각각 레포를 만들어 스프링부트 기반으로 개발을 시작했다.
논블로킹 리액티브로 개발하던 중 초기 도입한 넷플릭스 Zuul이 동기 방식이라 게이트웨이에서 병목이 발생했다. Zuul 자체 이슈를 우회하려 만든 구현도 한계가 있어, 논블로킹·리액터 기반의 Spring Cloud Gateway로 갈아타 병목을 해소했다. Eureka 서비스 디스커버리도 함께 설명한다.
분산 환경에서 커진 설정 파일을 외부 Git 등으로 중앙 관리하는 Spring Cloud Config와, 스프링5의 리프레시 스코프로 무중단 갱신하는 구조를 소개한다. 이어 Docker·Nexus 레지스트리·Jenkins 파이프라인·Ansible로 컨테이너 이미지 빌드부터 타깃 서버 배포까지 자동화한 CI/CD를 다룬다.
MSA 환경에서 조직 간 협업 수단으로 문서가 중요해지자, 개발 코드와 무관해지기 쉬운 Swagger 애노테이션의 한계를 지적한다. 테스트 코드가 통과해야만 문서가 생성되도록 강제하는 Spring REST Docs와 OpenAPI 3.0을 결합해, 실제 동작과 문서의 정합성을 확보한 방식을 설명한다.