[회고] 글로벌 커머스 개발자로 보낸 첫 1년 회고

데이터 엔지니어에서 백엔드 개발자로 직무를 변경한 지 어느덧 1년이 되었다. 새로운 언어, 새로운 도메인, 새로운 조직에서 적응하는 과정이 쉬운건 아니었지만, 참 재미있는 1년이었다. 규모가 대기업이고, 사실 IT 회사라기보단 리테일에 가까운 회사여서 경직된 조직이면 어떡하지 라는 걱정을 했지만, 걱정을 할 필요가 전혀 없었을 정도로 참 다이나믹하고 스타트업스럽게 움직였던 1년이었다. 

이번 글에서는 지난 1년 동안 어떤 프로젝트를 했고, 무엇을 배웠으며, 앞으로 어떤 엔지니어, 어떤 사람이 되고 싶은지 정리해보려고 한다.

 

1년 동안 참여한 프로젝트

1:1 문의 게시판 다국어 번역 기능 추가

처음으로 담당한 프로젝트는 온보딩 용으로 적합한 사이즈였다. Aws translate api 를 기반으로 번역 버튼을 추가하는 간단한 작업이었다. 간단한 건이지만, 번역 api 개발 뿐만 아니라 기존의 jsp 로 구현되어 있던 프론트 페이지를 모듈 페더레이션이라는 기술로 게시판 부분을 새로 개발하는 것까지 진행했다.

이 당시에는 ai 로 코드를 작성하제 않던 시기였는데, 서비스 회사에서 첫 프로젝트라서 잘해내야 한다고 부담이 좀 있었던 것 같다. 그리고 거대한 legacy code base 를 처음 경험했는데, 이때까지만 해도 뭔가 잘못된것 같긴 하지만 엄청 이게 나쁜 예시들을 어떤식으로 개선해야 한다까지 생각을 못한 것 같다

관세 대응

트럼프가 취임된 이후 관세 협상이 큰 이슈였다 글로벌 몰을 운영하는 우리 서비스에도 큰 타격이었다.

갑자기 미국을 대상으로 관세를 15% 부과해야하는 상황이었다. 기존에는 판매세는 수취했으나 관세를 수취하는 기능은 당연하게도 없았다. 그렇지만 우리 회사의 전통(?) 인 3 6 9 12월에 있는 올영세일 매출을 위해서는 구현해내야 하는 기능이었다.

개발 기간도 촉박했던 터라, 3주-4주 정도 크런치 모드로 일했던 것 같아서 기억에 남는다. 기간이 촉박해서 기능을 어떻게 간단하게 구현할 수 있을지 개발 방향과 기획에서의 타협이 필요했다. 복잡한 문제를 단순화하면서 현실적인 타협을 취하는 방법을 배울 수 있었다. 

그리고 장바구니-주문서로 넘어갈때 관세를 부여하고, 환불할 때에도 관세를 포함하여 환불해줘야 했으므로 전반적인 주문 프로세스를 익힐 수 있었다 !

텍스 엔진 개발 

 앞서서 관세 대응했던 건은 관세율을 feature gate 의 dynamic config 를 이용하여 저장했으며, 관세 및 판매세를 계산하는 식을 직접 코드로 구현하였다. 그렇지만 글로벌 서비스는 국제 정세에 타격을 빠르고 크게 받기 때문에 세금에 대한 관리는 필수이며, 새로 세법이 업데이트 될 때마다 산식을 바꾸는 것은 번거로우며 리스크가 크다. 

이에 좀 더 유연하게 대응하기 위해서 우리 조직에서는 Zonos 와 Avalara 를 비교하여 후자인 Avalara 라는 Tax 계산 SaaS 를 구독하게 되었다. Tax Engine 은 글로벌 몰 (Cross Border Platform) 과 새로 오픈을 준비했던 미국 로컬몰 (USE) 에 각각 필요했다. 그래서 설계 시에 공통으로 쓰이는 모듈은 묶어서 같이 쓰도록 하고 겹치는 코드가 없는게 좋을 거라고 예상했다. 그렇지만 글로벌몰과 미국몰의 세부 정책들이 점차 달라지게 되면서, 이 결정은 후에 후회를 하게 된다... 결국 중복된 코드를 감수하더라도, 다른 플랫폼에 쓰이는 텍스엔진은 별도로 구현하도록 분리하는 리팩토링을 조금씩 진행했다.  

안타깝게도 이후에 Avalara 서비스는 중국이나 영국 대응이 어려웠던 것으로 전해 듣게 되며 글로벌몰에서는 오픈을 하지 못하게 된다. 그렇지만 미국로컬몰에서는 USE 오픈을 하면서 실제 운영이 되었다. USE 용 Tax Engine 은 별도의 db 를 사용하지 않는 세금 계산 엔진으로 설계하였다. 

Customer Service SaaS 플랫폼, Zendesk 연동

USE 오픈을 준비하며 Zendesk SaaS 에서 우리 서비스에 필요한 주문 / 상담 데이터를 서빙하는 API 개발과 Zendesk 와 USE 몰을 SSO 로 연동하는 작업을 했다. SSO 연동, 인증 작업을 하면서 keycloak 을 사용했는데, jwks를 편리하게 관리 할 수 있었다. 

USE 오픈

약 3개월 동안의 개발 끝에 USE 오픈을 위한 기능을 모두 완성했다. 기획 일정이 늦어지고 상대적으로 QA 기간이 길게 확보되면서 실제 개발에 사용할 수 있는 시간은 점점 줄어들었다. 당시 개발팀은 정해진 오픈 일정을 맞추기 위해 대부분의 요구사항을 최대한 수용하는 분위기였던 것 같다.

오픈 당일에는 미국 현지 시간에 맞춰 저녁부터 회사에 남아 모니터링을 진행했다.  Datadog 대시보드를 실시간으로 확인하면서 주문이 정상적으로 발생하는지, 오류는 없는지 함께 살펴봤다. 첫 주문이 들어올 때마다 다 같이 기뻐했던 기억이 난다.

내가 담당했던 CS 서비스는 주문이나 결제 시스템과 비교하면 상대적으로 작은 서비스라고 생각했다. 하지만 오픈 후에 실제 문의가 생각보다 많이 들어오는걸 보면서, 고객들의 입장에서는 정말 꼭 필요한 서비스라는 것도 느꼈다. CBE에서 USE 로 전환하면서 멤버 등급에 대한 문의, 제품에 대한 문의 등 정말 다양했다. 

 

성장한 부분 

지난 1년 동안 생각보다 다양한 도메인과 시스템을 경험했다. 기존 글로벌몰인 CBE의 레거시 프로젝트를 다뤄보기도 했고, 새롭게 구축을 시작한 미국 로컬몰 USE의 개발에도 참여했다. 이미 오랜 시간 운영된 시스템과 처음부터 구조를 만들어가는 시스템을 모두 경험하면서, 각각의 장점과 어려움을 비교해볼 수 있었다.

CBE에서는 거대한 레거시 코드베이스 안에서 기존의 흐름을 파악하고, 영향을 최소화하며 기능을 변경하는 방법을 배웠다.

반면 USE는 MSA 기반으로 새롭게 구축되는 서비스였기 때문에, 어떻게 설계할지 고민이 많이 필요했다. 자연스럽게 DDD 공부도 하게 되었고, kotlin 이라는 언어에도 관심을 가지게 되었다. 또한 msa 간에 이벤트 기반으로 통신하는 부분들을 구현했는데, 처음으로 kafka consumer 와 producer 개념을 실무에서 접할 수 있었다. 이전에도 Kafka에 대한 개념적인 이해는 있었지만, 실제 서비스에서 이벤트가 어떤 시점에 발행되어야 하는지, 소비에 실패했을 때 어떻게 처리해야 하는지, 고민해보니 훨씬 재미있었다.

Claude Code 도 적극적으로 활용하면서 이제는 컨텍스트를 넘나들며 작업을 하는 것에 익숙해진 것 같다. 

 

아쉬웠던 점 

가장 아쉬운 점은 지난 1년 동안 회사 업무와 야근에 많은 에너지를 사용하면서, 개인적인 공부에는 충분한 시간을 쓰지 못했다는 것이다. 실무에서 다양한 경험을 쌓기는 했지만, 그 경험을 체계적으로 정리하거나 부족한 기초 지식을 깊게 공부하는 시간은 상대적으로 적었다. 업무 중에 새롭게 접한 기술이나 설계 방식에 대해 궁금한 점이 생겨도, 당장의 일정과 개발 업무를 처리하다 보면 충분히 파고들지 못한 채 넘어가는 경우가 많았다.

AI를 활용하는 방식에서도 더 고민할 부분이 남아 있다. Claude Code와 Codex를 사용하고, 여러 Skill과 MCP를 연동하면서 개인 단위에서는 AI Agent를 활용한 개발에 익숙해졌다. 그러나 이를 팀 단위의 개발 방식으로 확장하는 하네스 엔지니어링에 대해서는 충분히 고민하지 못했던 것 같다. 앞으로는 구축이 끝난 운영모드라서, 팀원들과 더 논의를 해 볼 여력이 생긴것 같아서 도입을 해볼 수 있을 것 같다. 

운영 이슈에 대응하는 태도에서도 스스로에게 조금 아쉬움이 있다. 내가 잘 알고 있는 영역이 아닌 경우에는 문제 해결에 적극적으로 뛰어들기보다, 해당 영역을 잘 아는 사람이 대응하기를 기다렸던 순간들이 있었다. USE 주문 클레임 영역을 처음부터 개발한 것이 아니라 중간에 합류했기 때문에 도메인 지식이 많지 않았다. 그렇지만 코어 기능들이기에 앞으로는 직접 관련 프로젝트도 하고, 주도적으로 트러블 슈팅도 하려고 한다.