ioT 시스템을 글로벌 플랫폼으로 도약하기 위한 회고
1. 왜 이 문제를 해결해야 했는가
기존 시스템은 제주파크 전용으로 설계된 맞춤형 구조였어요. 하나의 파크를 안정적으로 운영하는 데에는 문제가 없었지만, 사업이 확장되기 시작하면서 한계가 분명해졌어요.
- 새로운 파크가 추가될 때마다 시스템 복제 필요 (비용 더블)
- 파크별 규칙이 점점 조건문으로 누적
- 특정 기능을 수정하면 다른 파크에 영향이 갈 가능성 존재
- 특정 기능이 다른 파크에 사용할지 모름
결과적으로 **"지금은 잘 돌아가지만, 다음 파크를 추가할 때가 유리하지 않은 상태"**였어요.
이 문제는 기능 부족의 문제가 아니라, 시스템이 확장을 전제로 설계되지 않았다는 구조적 문제라고 판단했어요.
2. 문제를 어떻게 정의했는가
처음에는 단순히 "하드코딩이 많다", "유지보수가 어렵다"는 표현으로만 논의되었어요. 하지만 실제로 코드를 분석해보니 문제는 더 명확했어요.
• 도메인 경계가 불분명 • 비즈니스 규칙과 인프라 코드가 강하게 결합 • 테스트가 어려워 변경이 곧 리스크로 이어짐
결국 '어디까지가 비즈니스 로직이고, 어디부터가 구현 세부사항인지'가 드러나지 않는 구조였어요.
그래서 문제를 이렇게 재정의했어요.
"새로운 파크가 추가되더라도, 기존 도메인을 거의 건드리지 않고 확장할 수 있는 구조를 만들 수 없는가?"
3. 선택 가능한 대안들은 무엇이었는가
문제를 정의한 뒤, 몇 가지 접근 방법을 검토했죠.
① 기존 구조 유지 + 조건 분기 최소화
• 단기적으로 가장 안전한 선택 • 개발 비용이 적음 • 하지만 파크가 늘어날수록 복잡도는 계속 증가
→ 확장 문제를 '미루는 선택'이라고 판단
② 프레임워크 중심의 구조 개편
• 일정 수준의 구조 표준화 가능 • 하지만 프레임워크에 설계 의도가 묻힘 • 도메인 자체의 책임은 여전히 불명확
→ 구조는 바뀌지만, 문제 인식은 그대로 남는다고 판단했어요
③ 도메인 중심으로 구조 재설계
• 도메인별 책임과 역할을 명확히 정의 • 외부 의존성과 비즈니스 로직 분리 가능 • 테스트 가능한 구조로 전환 가능
→ 시간은 걸리지만, 장기적으로 가장 안전한 선택
4. 그래서 어떤 선택을 했는가
결론적으로 도메인을 재정의하고, Hexagonal Architecture를 적용하기로 결정했죠.
핵심 선택은 다음과 같았죠.
• 메타데이터, 상태, 기록, 로그, 제어 등 핵심 도메인 경계 재정의 • 비즈니스 로직을 도메인 계층에 집중 • DB, 외부 API와의 의존성을 포트/어댑터로 분리하여 테스트에 용이한 구조 수용
이 선택의 목적은 단순했죠.
"비즈니스 규칙이 바뀌어도, 시스템이 흔들리지 않게 만들자."
5. 구현에서 가장 중요했던 포인트
① 기존 시스템의 구조를 먼저 '보이게' 만들기
아키텍처를 바꾸기 전에 기존 ERD와 Inbound / Outbound 흐름을 문서화했어요.
어디가 섞여 있는지, 어디서 책임이 흐려지는지를 팀 전체가 공유하지 않으면 설계 변경은 공감받기 어렵다고 판단했어요.
② 작은 도메인부터 점진적으로 적용
한 번에 모든 도메인을 바꾸지 않았어요.
• 티켓 도메인부터 적용 • 효과 검증 후 다른 도메인으로 확장
이를 통해 "이 구조가 왜 필요한지"를 코드로 설명할 수 있었어요.
③ 테스트 가능한 구조를 우선 확보
기존 코드베이스에는 테스트 코드가 거의 없었어요. 그래서 아키텍처 전환과 함께 테스트 전략을 동시에 도입했어요.
• 도메인 계층 단위 테스트 • 외부 의존성은 Mock 또는 Adapter로 분리 • 핵심 도메인 기준 커버리지 목표 설정
테스트는 품질을 위한 장치이기도 했지만, 팀이 안심하고 코드를 수정할 수 있는 안전장치이기도 했어요.
6. 결과는 무엇이 달라졌는가
구조 전환 이후 변화는 점진적이지만 분명했죠.
• 새로운 파크 추가 시 설정 중심으로 대응 가능 • 도메인별 책임과 역할이 드러나 코드 가독성 향상 • 테스트 기반 변경으로 배포 안정성 확보
무엇보다 "이 코드를 고쳐도 괜찮을까?"라는 불안이 크게 줄었어요.
7. 이 경험을 통해 얻은 판단 기준
이 프로젝트를 통해 명확해진 기준이 있죠.
• 확장을 고려하지 않은 구조는 결국 발목을 잡아요 • 아키텍처는 기술 선택이 아니라 책임 분리의 문제예요 • 테스트 가능한 구조는 개발 문화까지 바꿔요
구조는 코드 품질뿐 아니라 팀의 심리적 안정감과 생산성에 직접적인 영향을 준다는 점을 체감했죠.
8. 다음에 다시 한다면
초기에는 아키텍처 개념에 대한 팀원 간 이해도 차이가 있었어요. 다음에는 코드 변경 전에 도메인 모델과 책임과 역할을 더 가볍게 합의하는 단계를 먼저 가져가고 싶어요.
아키텍처 전환은 기술 과제가 아니라 사람을 설득하는 과정이라는 점도 다시 느꼈죠.