레거시를 대물림하지 않는 아키텍처: flex의 5년간의 여정

팀 스토리

2025. 6. 2

우리 모두 처음부터 레거시를 만들려고 한 적은 없는데, 어느새 레거시와 씨름하고 있는 자신을 발견하곤 하죠.

플렉스팀은 지난 5월 29일, 'flexible#2: Tech Talk' 행사에서 많은 개발자들의 고민을 함께 나누는 시간을 가졌습니다.

이날 flex Lounge에 50여 명의 개발자분들이 모여 스타트업 환경에서 레거시를 어떻게 방지할 수 있을지에 대한 이야기를 나눴는데요. "Monolith, MSA, 그리고 Hexagonal Architecture까지, 레거시를 막기 위한 시도는 많았지만, 이 문제를 완전히 해결한 팀은 아직 없어요." 라며 플렉스팀이 5년간 고민하고 발전시켜온 레거시 방지 전략을 솔직하게 공유하는 시간으로 시작했습니다.

우리 모두의 고민, 레거시

행사 초반에는 참석해주신 분들이 사전 서베이를 통해 알려주신 '레거시의 위험 요소'들을 함께 살펴봤어요. 서베이 결과 '개발 속도의 저하'와 '코드 변경의 파급효과'가 가장 많이 언급된 문제점으로 나타났는데요.

"이런 문제가 발생하는 근본 원인은 결국 코드 구조와 아키텍처에 있어요. 개발 속도가 느려지고 변경이 어려워지는 건 모두 설계의 문제에서 비롯됩니다."

이어서 플렉스팀은 이런 문제를 야기하는 구체적인 패턴으로 ComponentScan 사용의 위험성을 실제 코드 예제와 함께 설명했어요. "초기에는 편리하지만, 시간이 지날수록 통제하기 어려워집니다. 이렇게 결합한 코드들은 어디에 문제가 있는지를 파악하는 데 몇 시간씩 걸리기도 하죠." 이처럼 편의성을 위한 선택이 나중에는 레거시의 씨앗이 된다는 점이 흥미로웠습니다.

단일 모놀리스에서 MSA까지, flex의 아키텍처 여정

플렉스팀이 걸어온 아키텍처 변화의 여정도 솔직하게 공유되었어요. 초기의 단일 Monolith에서 시작해 모듈형 Monolith로, 그리고 최근에는 MSA로 전환하는 과정에서 배운 교훈들을 들을 수 있었습니다.

"처음에는 우리도 전형적인 레이어드 아키텍처를 사용했어요. Controller, Service, Repository가 깔끔하게 분리된 구조였죠. 하지만 빠른 성장 과정에서 이 구조의 한계를 직면했어요. 개발 속도가 점차 느려지고, 작은 변경이 예상치 못한 곳에 영향을 미치는 경우가 많아졌거든요."

모듈형 모놀리스로 전환하면서 발견한 핵심 원칙은 '레이어를 도메인 안으로 숨기고, 도메인 간 통신은 인터페이스만을 통하게 하는 것'이었다고 해요. 이 과정에서 팀은 점진적으로 Kotlin으로의 전환도 시작했습니다.

"MSA로 전환한 것은 더 최근의 일이에요. 배포 단위에 맞게 패키징을 분리하고, Spring Boot Auto Configuration을 활용해 모듈 간 유연한 통합을 가능하게 했어요. 덕분에 변경의 파급효과를 최소화하고 개발 속도를 유지할 수 있었죠."

레거시를 방지하는 5가지 전략

세션 후반부에는 플렉스팀이 현재 적용 중인 레거시 방지 전략들이 공유되었어요:

쉬워야 하는 변경과 어려워야 하는 변경의 격리: 변경의 성격에 따라 코드를 분리해 관리하는 방법
재사용성의 범위에 따른 코드 분리: 범용 코드, 제품 공통 코드, 도메인 코드를 명확히 구분하기
모듈 구성의 표준화: 일관된 모듈 구조로 개발자 경험 개선하기
ComponentScan 대신 Auto Configuration 활용: 메타데이터 기반의 설정 관리하기
Hexagonal Architecture 적용: 비즈니스 로직과 기술적 의존성 분리하기

특히 Spring Boot Auto Configuration을 활용한 접근법은 많은 분들의 관심을 끌었어요. "코드와 configuration을 분리하고, 메타데이터를 통해 구성을 관리하면 유연성과 유지보수성이 크게 높아져요." 라는 설명에 고개를 끄덕이는 참석자분들이 많았습니다.

플렉스팀은 "한 번에 모든 것을 바꿀 수는 없고, 그럴 필요도 없어요"라고 강조했는데요. 중요한 건 레거시가 되기 쉬운 구조를 식별하고, 지속적으로 개선해나가는 과정이라고 해요. "지속 가능한 아키텍처는 '빠른 개발 속도'와 '유지보수성' 사이의 균형을 찾는 여정이에요. 이 균형점은 제품과 팀의 성숙도에 따라 달라질 수 있어요."

따뜻한 네트워킹의 시간

발표 후에는 Q&A와 함께 플렉스팀 Product Engineer와 참석자분들의 네트워킹 시간이 이어졌어요. 맛있는 식사와 함께 더 깊은 기술적 대화가 오갔답니다.

행사에 참석해주신 한 개발자 분은 "오늘 공유된 내용이 정말 실용적이었어요. 특히 단계적인 아키텍처 발전 전략이 현실적으로 와닿았어요"라고 소감을 전해주셨어요.

플렉스팀도 "완벽한 해결책은 없지만, 꾸준히 레거시가 되지 않는 코드를 유지하기 위해 노력하고 있어요. 정답은 없을 수도 있지만 명확히 해로운 프랙티스들은 존재하니, 그것들을 피하는 것만으로도 레거시가 되기 어려운 코드베이스를 만들 수 있다고 생각해요"라고 의견 남겨주셨습니다.

앞으로도 이런 Tech Talk 행사를 통해 개발 경험과 통찰을 지속적으로 공유할 예정이라고 하니, 많은 관심과 참여 부탁드립니다!