도전은 연결된다. — 5년차 소프트웨어 엔지니어편

Intro: 문제 해결은 도전에서 시작된다

“개발을 한 번도 해본 적 없지만, 이 회사가 너무 좋다.” 이유 하나로 나는 트레바리에 무작정 지원했다. 그렇게 시작된 나의 커리어는 늘 새로운 영역에 던져지고, 그 안에서 부딪히고, 배우고, 정리하는 과정의 반복이었다. 지금 돌아보면 그 모든 순간들이 결국 “문제 해결자”로서의 나를 만들어왔다.

트레바리에서의 나

도전 1: 10,000줄의 스파게티 코드, 도메인으로 쪼개다

변경된 아키텍쳐

트레바리에서 처음 맡았던 주문 시스템은 유지보수 악몽의 현장이었다. 하나의 함수에 10,000줄 가까운 절차지향 코드가 붙어 있었고, 신규 입사자가 이 코드를 이해하려면 며칠이 걸릴 정도였다.

나는 먼저 그 코드를 프린트해 책처럼 넘겨보며 공통점을 찾았다. 주문의 흐름은 결국 “준비 → 검증 → 처리”로 정리할 수 있었고, 이를 PreOrder, Order 등 도메인 객체와 Validator, Processor, Service, Command로 나누어 객체지향 구조로 리팩토링했다. 핵심은 비즈니스 규칙을 코드 안에 명시적으로 드러내는 것이었다.

그 결과, 주문 로직 수정 시 참고해야 할 코드량이 10,000줄에서 15줄로 줄었고, 신규 기능도 명확한 책임 단위에만 코드를 추가하면 되는 구조로 바뀌었다. 이때 나는 처음으로 “도메인 모델링의 힘”을 체감했다.

도전 2: 기획과 사용자 사이에서 구조를 잡다

청강대 캐릭터빌딩캠프 CJ ENM(캐디터) 주최

CJ ENM의 사내벤처 프로젝트인 “캐디터”에서는 완전히 다른 도전에 마주쳤다. 창작자를 위한 도구를 만든다는 명확한 목표는 있었지만, 도메인 지식은 없었고 기획서는 UI 중심에 머물러 있었다.

나는 먼저 “작품-캐릭터-설정-히스토리”로 이어지는 창작의 흐름을 도메인 모델로 정리하고, 유저스토리 기반 커뮤니케이션을 통해 기획자와 개발자가 같은 언어를 쓸 수 있게 했다. 그 결과, 단축키, 자동저장 같은 실사용 기능 중심 MVP를 빠르게 만들 수 있었고, 실제 해커톤 사용자 피드백을 통해 도구의 가능성을 검증할 수 있었다.

이 경험은 내가 어떤 시스템이든 도메인을 먼저 정리하고, 사용자 시나리오로 소통하는 습관을 들이게 만든 계기였다.

도전 3: CEO가 되어보니 개발이 다가 아니더라

코스믹커넥션에서의 나

창업은 내게 또 다른 도전이었다. 익명 투표 기반 소셜 앱 “무물(MUMUL)”을 만들며, 나는 기획부터 개발, 마케팅, 투자유치까지 모든 걸 동료들과 함께 도전해야 했다. 개발자의 시야에서 벗어나, 시장 반응을 보고 기능을 조정하고, 사용자 인터뷰를 통해 핵심 지표를 확인하는 법을 배웠다.

3주 만에 Flutter로 앱을 만들고, 마케팅을 통해 1,000명의 사용자를 유입시키며 실험은 성공적이었다. 예비창업패키지, 500Global Post Fast-Track, 엔젤라운드 투심 대상 선정 등 성과도 있었다. 하지만 결국 유저 리텐션 저조와 자금 부족으로 폐업하게 되었다.

이 실패는 내게 기술적 완성도만큼이나 사업성과 리스크 관리가 중요하다는 걸 뼈저리게 가르쳐줬다.

도전 4: 실패로부터 배운 사가 패턴의 필요성

이전의 경험들을 바탕으로, 나는 위밋모빌리티에서 제주오늘 서비스를 MSA로 전환하는 프로젝트를 주도했다. Node.js 모놀리스를 Spring Boot + Kafka 기반 MSA로 전환하면서, 다양한 서비스 간 이벤트 통신을 설계했다.

하지만 테스트 단계에서 이벤트 소비 실패 시 정합성 문제가 반복되었고, 확인해보니 트랜잭션 처리가 제대로 되지 않았던 것이다. 이때 비로소 나는 분산 트랜잭션의 복잡함과 사가 패턴의 필요성을 체감했다. 비록 비즈니스 이슈로 상용화되진 못했지만, 이 경험은 내게 아키텍처 설계의 새로운 관점을 열어주었다.

위밋모빌리티에서의 나

도전 5: 도메인을 이해하는 방법, 현장에 답이 있다

HLB Therapeutics의 콜드체인 시스템 프로젝트에서는 익숙한 기술보다 도메인 자체를 이해하는 것이 핵심 과제였다. 콜드체인 물류 도메인에 대한 지식이 전무한 상태에서, 나는 이천 물류센터로 직접 향했다. 입고, 출고, 온도 관리, 유통기한 추적, 배차 과정을 실무자와 함께 직접 체험하면서, 도메인을 몸으로 익혔다.

현장의 흐름을 따라가며 요구사항을 구체화했고, 이를 팀에 문서로 정리해 공유했다. 핵심 도메인(주문, 재고, 배차 등) 중심으로 API를 설계하고, 통계 대시보드까지 구현해 운영 가시성을 높였다. 결과적으로 40만 재고와 3만 건의 주문, 2만 건의 배차를 안정적으로 처리하는 시스템을 한 달 만에 구축할 수 있었다.

또 다른 도전이었던 루티프로 프로젝트에선, 내부 플랫폼 API 설계를 맡아 다양한 파트와의 커뮤니케이션을 주도했다. 정산, 배차, 거래처 관리 등 협업 도메인을 조율하며, 비즈니스 요구사항을 기술적으로 명확하게 전환하는 연습을 할 수 있었다. 이 경험을 통해 나는 도메인을 이해하고 설계하는 방식이 ‘현장과 대화하는 것’이라는 걸 다시 한번 체감했다.

내가 생각하는 좋은 개발자의 조건

내가 도전을 반복하면서 가장 크게 배운 건, 좋은 개발자는 기술뿐 아니라 도메인과 팀, 비즈니스를 함께 바라볼 수 있어야 한다는 점이다. 기술은 도구일 뿐이고, 우리는 항상 팀과 함께 문제를 풀고 있다는 걸 잊지 말아야 한다.

그래서 나는 지금도 테스트와 코드 리뷰 문화를 팀에 정착시키고, 스터디를 운영하며 함께 성장하는 팀을 만드는 데 힘쓰고 있다. 이게 결국 문제 해결의 기반이 되니까.

Outro: 다음 도전을 준비하며

지금의 나는 과거보다 조금 더 구조적으로 문제를 보고, 조금 더 겸손하게 실패를 받아들이며, 다음 도전을 준비하고 있다.

앞으로도 나는 늘 그래왔듯, 도전하고, 실패하고, 배우고, 연결하며 성장할 것이다.