[신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - 프롤로그] 입사 1년차 선물로.. 중요한 자사 프로젝트의 설계를 맡게 되었다!?

예상치 못한 선물

2024년 9월, 입사 1년을 갓 넘긴 시점에서 저는 뜻밖의 '선물'을 받았습니다.
병역 특례로 복무하던 제 사수분이 퇴사하게 되면서, 사내의 가장 중요한 프로젝트 중 하나인 크로스플랫폼 POS의 아키텍쳐를 설계하고 개발을 리딩해야 하는 상황이 되었기 때문입니다.

두려움과 설렘 사이

사실, 프로젝트를 리딩해 나가야 되는 상황인 건 맞았지만, 아키텍쳐를 새로 설계해야 된다는 책임이 부여된건 아니었습니다.
하지만, 저는 짧다면 짧은 1년간 레거시 코드를 유지보수하고 추가 개발을 하면서, 기존의 아키텍쳐와 개발 방법에 많은 문제가 있다는 것을 느끼고 있었습니다.
하여, 어차피 할 거라면 신규 프로젝트니까 아키텍쳐 부터 탄탄하고 깔끔하게 만들고 가자는 생각이 들었습니다.

위와 같은 상황이었기에 처음에는 정말 큰 부담감이 밀려왔습니다.
우리 회사의 POS 시스템은 전국 천여 개의 매장에서 실제로 운영되는 핵심 시스템입니다.
게다가 이번 프로젝트는 기존 Windows 전용 POS를 크로스 플랫폼으로 확장하는 매우 중요한 작업이었죠.

 

'내가 할 수 있을까?'
'시키지도 않은 일을 했다가 실패하면 어쩌지?'
'다른 개발자들은 뭐라고 생각할까?'

 

하지만 한편으로는 이런 생각도 들었습니다.

 

'이걸 성공적으로 해내면 정말 큰 성장이 될 거야.'
'기존 시스템의 문제점들을 개선할 수 있는 기회야.'

'깔끔한 아키텍쳐로 모듈화를 잘 시켜두면, 다른 오프라인 결제 솔루션에도 비즈니스 로직의 재사용이 가능할거야'

 

시작은 분석부터

첫 번째로 한 일은 기존 시스템의 아키텍처를 분석하는 것이었습니다.

 

먼저, 오프라인 결제 솔루션은 그 특성상 외부 세계에 대한 의존성을 굉장히 많이 가지는데요.

몇 가지 예를 들어 보아도 아래처럼 여러 외부 의존성을 가진다는걸 금새 알 수 있습니다.

 

1. 다양한 VAN사 결제 모듈 연동

2. 다양한 상품권사 API 연동

3. 배달, 선주문 앱 등의 다양한 주문 채널 연동

4. 다양한 기종의 프린터 연동

 

이 외에도 고객사의 멤버십 관리를 해주는 업체와의 연동 등 정말 많은 외부 의존성을 가집니다.

기존의 레이어드 아키텍쳐의 경우 표현력이 부족해 서비스 레이어에 모든 외부 의존 코드를 작성해야 해서, 서비스레이어가 불필요하게 비대해지는 문제가 있었습니다.

 

이 외에도 레거시 코드를 하나 하나 뜯어보면서, 현재 시스템이 가진 문제점들을 정리했습니다.

그 과정에서 깨달은 것이 있습니다.
신입인 제가 오히려 기존 시스템을 객관적으로 바라볼 수 있다는 점이었죠.
기존 개발자분들은 너무 익숙해져서 당연하게 여기던 부분들도, 제게는 "이건 왜 이렇게 되어 있지?"라는 의문으로 다가왔습니다.

새로운 아키텍쳐 설계와 적용.

그렇게 시작된 설계와 그 결과물, 그리고 그 사이의 고민들을 이 블로그 시리즈를 통해 공유하려 합니다.

혹시의 혹시 만약의 만약에라도 비슷한 상황에 처한 다른 주니어 개발자분들에게도 도움이 될 수 있지 않을까요?
저처럼 큰 도전 앞에서 두려워하고 있을 누군가에게, 이 블로그 시리즈가 작은 도움이나마 되었으면 합니다.

시리즈 소개

이 시리즈는 총 3편으로 구성될 예정입니다:

1. 레거시 아키텍처의 문제점 분석
2. 헥사고널 아키텍처 도입과 설계
3. 새로운 아키텍처의 효과와 개선점

각 편에서 기술적인 내용과 함께, 제가 겪은 실제 경험과 고민들도 함께 담아내려 합니다.

아, 결론부터 말씀드리자면, 입사 초기 부터 언젠가 아키텍트 역할을 수행해야 될 때가 왔을 때를 대비해 미리 공부해둔, 헥사고날 아키텍쳐를 실제로 적용해보았습니다.

그 때 공부했던 내용과 헥사고날 아키텍쳐 자체에 대한 이론 적인 부분은 아래 제 다른 포스팅을 참고 부탁드립니다!

 

2023.11.20 - [개발 방법론] - 헥사고날 아키텍쳐(feat. 코틀린 멀티 모듈)

헥사고날 아키텍쳐(feat. 코틀린 멀티 모듈)