Kakao Commerce Software Engineer, Backend

Software Engineer, Backend

서비스 개발 및 운영

• 선물하기 for Biz의 주문 및 결제 도메인에서 서버 애플리케이션 개발을 진행

• 선물하기 for Biz의 주문 생성시 이미지의 스크린샷에 캐싱 전략을 도입하여 주문 생성 시간을 대폭 개선하였음. (3s -> 500ms) 또한 주문 내역을 고객사에게 제공하는 데이터 다운로드 기능에 Bulk API 및 쿼리 최적화 적용으로 처리 시간 90% 이상 단축

• 외부 파트너사 대상 선물하기 B2B의 교환권 PIN 코드 발행/관리 플랫폼을 설계부터 구축까지 전담하여 대규모 거래 규모의 신규 채널 창출에 기여. 외부 파트너사를 대상으로 API Gateway 부터 실제 서버 애플리케이션까지 개발 리드를 담당. 파트너사에게 API Docs를 만들어서 제공하였음. 대부분의 API는 RESTful 하게 설계하려고 했으며, 코드 발행에 대한 멱등성 보장 및 코드 상태에 대한 API Callback을 제공하여 파트너사의 코드 발행 플랫폼 연동 과정을 지원함.

• B2B의 서비스 특성상, 고객사별로 발생하는 거래액이 B2C에 비해 큰편임. 고객사별로 선물하기 for Biz의 기능을 커스터마이징 할 수 있도록 데이터 모델을 설계하고 해당 데이터 모델을 기반으로 서버 기능을 커스터마이징.

결제 시스템 구축

• 선불전자지급수단 관련 법령 대응으로 중개상품의 카드결제가 필요했으나, 기존 시스템이 캐시(포인트) 결제에 강결합되어 신규 결제수단 추가가 어려운 구조였음

• 데이터 구조 설계 및 결제 플로우별 시퀀스 다이어그램을 작성하였고 팀원들에게 공유함. 스크럼을 진행하면서 팀원들과 추가로 논의·의사결정을 진행하고, 설계부터 개발까지 주도적으로 수행

• 결제 도메인과 관련된 기능을 신규 서버 애플리케이션으로 설계·구축하고, 이벤트 기반 아키텍처를 도입하여 결제 처리를 비동기로 전파하는 구조로 개발

• 카카오 내부 결제 플랫폼과 직연동하여 카드결제를 구현하고, 결제 데이터 정합성 검증을 위한 대사 배치 개발

• 기존 주문 서버의 결제 로직을 점진적으로 이관하여 주문-결제 도메인 간 관심사를 분리하고, 결제내역 데이터 마이그레이션을 수행하여 전환 완료

• 후불결제 등 추가 결제수단을 유연하게 확장할 수 있는 구조를 확보하여, 중개상품 직접 판매와 영업팀의 외부 고객사 영업 확대에 기여

플랫폼 라이브러리 개발 및 현대화

• Spring Boot 기반이고, AutoConfiguration을 사용하지 않는 카카오커머스 공통 라이브러리가(Spring Boot 2.X) 존재하였으나, 해당 라이브러리의 개발자 퇴사로 인해 유지보수가 어려운 상황이였음. 이에 대한 대안으로 Spring Boot(3.X) 기반의 신규 라이브러리를 만들었고, Spring Boot의 신규버전이 출시될때마다 팀내에서 업그레이드를 진행하는 방향으로 의사결정. 모노레포 형식으로 구성하였으며 이를 통해 라이브러리에 대한 유지보수 및 디버그를 쉽게 하도록 하였음. 선물하기 for Biz 서비스를 운영하는 서버 애플리케이션의 Type을 5가지로 정하였고, 해당 Type별로 공통 코드를 제공 (API, Consumer, API Gateway, Streaming, Batch)

RabbitMQ -> Kafka로의 전환

• 주문·결제·이벤트 처리에서 RabbitMQ + Redis 분산락 조합의 Lock Timeout이 빈번하게 발생하고, 간헐적 메시지 유실 이슈가 있어 Kafka로 전환을 결정 Kafka 파티션 키 기반 순차 처리를 도입하여 분산락 없이 동일 키의 메시지 직렬 처리를 실현하고, Lock Timeout 운영 이슈를 해소 기존 Delay Queue + Dead Letter 기능은 Spring Kafka Retryable Topic을 활용한 3단계 비동기 재처리 구조로 대체하여 현재까지 안정적으로 운영 중

Webflux Gateway -> MVC Gateway로의 전환

• Spring WebFlux 기반 Gateway의 팀 내 리액티브 프로그래밍 이해도 부족으로 트러블슈팅과 기능 확장에 어려움이 있어, Java 21 Virtual Thread + Spring MVC 기반으로 전환 전환 전 성능 비교에서 WebFlux가 소폭 우위였으나, 팀 전체의 기술 이해도와 유지보수성을 우선시하여 MVC를 선택 기존 Servlet Filter·로깅 컴포넌트를 그대로 재사용할 수 있었고, 전환 이후 점검 기능·인증/인가·로깅 등 핵심 기능을 안정적으로 확장하여 현재까지 운영 중

인프라 운영 및 클러스터 관리

• PM 장비에서 Kubernetes 환경으로 전면 이관, Kustomize 기반 Manifest 관리 및 GitHub Actions 빌드 환경 구축. PM장비의 배포는 Jenkins + Ansible을 사용하였었으나, 이를 Github Actions + 사내 클라우드 배포 시스템으로 전환

• 3개 멀티 IDC를 단일 k8s 클러스터로 구성 및 통합 운영 체계 구축, 로그 수집 파이프라인 구축. 애플리케이션별 Filebeat Sidecar를 구성하고 Logstash로 전송한뒤 가공하여 Kafka 전송 및 ES에 적재하는 방식으로 로그 수집. GSLB를 이용하여 3개 멀티 IDC에 Round Robin으로 트래픽을 분신하여 서비스 제공. 이와 관련된 경험을 토대로 다른팀에서 제공하는 서비스에 대해 멀티 IDC 단일 클러스터 전환 및 GSLB 트래픽 분산을 지원하였음.

• Kustomize 기반으로 k8s의 Manifest를 전면 구성함. 일반적으로 Helm 차트로도 많이 구성하지만 사내 배포시스템에서 Helm 차트 및 저장소를 지원하지 않는 상황이였으며 Helm에 대한 러닝커브 곡선이 Kustomize에 비해 어렵다고 판단. Kustomize는 복잡하지 않은대신, Helm에 비해 지원하는 기능이 비교적 작지만 Kustomize의 기능만으로도 서비스를 운영하는데 부족함이 없다고 판단하였음.

Software Engineer, Backend, Intern

Java, Spring

MySQL, MongoDB, ElasticSearch

RabbitMQ, Kafka

Redis

Docker, Kubernetes