현대화 프로젝트의 가장 큰 착각은 기술 스택을 바꾸면 곧바로 시스템이 새로워진다고 믿는 것이다. 실제 현장에서는 경계를 다시 긋는 일이 더 중요했다.
이 팀은 Java를 버리지 않았다. 대신 모놀리식 서비스 안에서 어떤 규칙을 먼저 떼어내고, 무엇을 계약으로 남길지 정리했다.
회의에서 실제로 본 선택지
전면 재작성
장점 새 구조를 한 번에 가져갈 수 있다.
주의점 도메인 지식이 코드 밖으로 증발하기 쉽다.
경계 분리 후 단계 이관
장점 운영 지식을 유지한 채 서비스 계약을 정리할 수 있다.
주의점 당장 화려한 성과가 적어 보일 수 있다.
왜 Java가 계속 남았나
문제의 핵심은 언어 노후화가 아니라 시스템 경계 혼합이었다. 정산 규칙, 관리자 승인, 외부 제휴 연동이 한 서비스에 얽혀 있었다.
Java는 기존 자산과 팀의 운영 습관을 유지하면서도, 새 API 경계를 뽑아내기에 충분히 강했다. 특히 테스트와 배치, 트랜잭션 계층을 건드릴 때 안정감이 컸다.
현대화 때 지킨 원칙
- 관측 가능성을 붙이기 전에는 서비스 분리를 시작하지 않는다.
- 새 시스템은 옛 시스템의 데이터를 설명할 수 있어야 한다.
- “프레임워크 교체”보다 “도메인 경계 명확화”를 먼저 진행한다.
메모 끝에 남긴 결론
- Java는 레거시의 상징이 아니라 장기 운영 시스템의 기본 체력으로 여전히 유효하다.
- 현대화 프로젝트는 재작성보다 경계 재설정이 성패를 좌우한다.
- 조직이 클수록 명시적인 구조가 곧 속도다.