React와 Spring Boot로 구조를 나누면 프론트엔드와 백엔드의 역할이 명확해질 것이라고 생각했습니다.

화면은 React가 담당하고, 데이터와 업무 처리는 Spring Boot API가 담당하면 된다는 설명은 단순합니다. 하지만 실제 업무 화면을 나누기 시작하니 어디까지가 화면의 책임이고 어디부터가 서버의 책임인지 애매한 지점이 계속 나타났습니다.

역할을 정리한 뒤에는 또 다른 질문이 남았습니다. 코드는 나누었는데, 변경하고 빌드하고 배포하는 단위도 실제로 나뉘어 있는가 하는 문제였습니다.

데이터를 보여주는 것과 업무를 판단하는 것은 달랐습니다

화면은 사용자의 입력과 상태를 빠르게 표현해야 합니다. 입력값 형식이나 필수 항목을 확인하고, 로딩과 오류 상태를 보여주며, 이전 화면에서 이어진 흐름을 유지합니다.

하지만 화면에서 확인했다고 업무 조건까지 신뢰할 수는 없었습니다. 계좌 상태, 상품 조건, 거래 가능 여부, 권한처럼 실제 처리 결과를 바꾸는 판단은 서버에서 다시 확인해야 했습니다.

  • 화면은 빠른 피드백과 입력 편의를 담당합니다.
  • API는 업무 가능 여부와 요청 데이터의 정합성을 검증합니다.
  • 원장이나 코어 서비스의 응답은 채널 API가 화면에서 사용할 수 있는 형태로 정리합니다.

같은 조건을 프론트엔드와 백엔드에 무작정 중복하는 것이 아니라, 각 검증이 필요한 이유를 구분하려고 했습니다. API도 원장 응답을 그대로 전달하지 않고, 화면에 필요한 데이터와 공통 오류 형식으로 다시 정리해 채널 서비스의 경계 역할을 맡도록 했습니다.

책임은 나눴지만 변경 단위는 여전히 묶여 있었습니다

화면과 API의 책임을 정리하고 나니, 이번에는 변경을 어떤 단위로 관리할지 고민하게 되었습니다.

화면만 수정했는데 여러 애플리케이션을 함께 빌드해야 하거나, 한 서비스의 변경을 다른 서비스와 같은 릴리즈에 맞춰야 한다면 코드의 분리가 운영의 독립성으로 이어졌다고 보기는 어려웠습니다.

반대로 저장소를 나눈다고 이 문제가 저절로 해결되는 것도 아니었습니다. 저장소가 달라도 API 변경 때마다 함께 배포해야 한다면 두 영역의 변경은 여전히 연결되어 있습니다. 그래서 저장소를 몇 개로 나눌지보다, 무엇을 독립적으로 바꿀 수 있어야 하는지부터 다시 확인할 필요가 있었습니다.

독립적으로 바꿀 수 있어야 하는 것을 다시 확인했습니다

프론트엔드, 게이트웨이, 업무 API는 모두 같은 서비스 흐름에 참여하지만 변경하는 이유와 주기가 반드시 같지는 않습니다.

화면의 문구나 배치를 바꾸는 일, 요청을 연결하는 방식을 바꾸는 일, 업무 규칙을 바꾸는 일은 영향 범위가 다릅니다. 각 변경에 어떤 검증이 필요하고 어떤 애플리케이션을 다시 배포해야 하는지 설명할 수 있어야 했습니다.

이때 독립 배포를 모든 변경에서 단독으로 배포할 수 있다는 뜻으로 보지는 않았습니다. API 계약이 달라지는 변경은 호환되는 조합과 적용 순서를 함께 확인해야 합니다. 독립성의 기준은 경계를 그어 놓았는지가 아니라, 변경의 영향을 확인하고 필요한 범위만 안전하게 내보낼 수 있는지에 가까웠습니다.

여러 애플리케이션이 포함된 멀티모듈 구조를 다루면서는 모듈, 저장소, 배포 단위를 같은 의미로 취급하지 않는 것도 중요했습니다. 저장소는 소스와 협업의 경계이고, 모듈은 코드와 의존성의 경계이며, 배포물은 운영에 반영하는 단위였습니다.

릴리즈 버전은 운영과의 약속이었습니다

개발 브랜치는 계속 바뀝니다. 같은 브랜치 이름이라도 어느 시점의 코드를 빌드했는지에 따라 결과가 달라질 수 있습니다. 그래서 브랜치 이름만으로 운영에 반영할 대상을 설명하기에는 부족했습니다.

  • 어떤 소스 변경을 기준으로 빌드했는가
  • 어떤 애플리케이션의 산출물이며 어떤 릴리즈에 포함되는가
  • 검수한 산출물과 실제 반영할 산출물이 같은가
  • 함께 사용하는 화면과 API의 버전 조합은 호환되는가

재현 가능한 배포를 위해서는 버전 이름을 붙이는 것에서 한 걸음 더 나아가야 했습니다. 소스 기준점뿐 아니라 의존성과 빌드 환경을 추적하고, 검증한 산출물을 보관해 이행 대상과 연결할 필요가 있었습니다.

좋은 분리는 변경의 영향을 예측할 수 있게 합니다

처음에는 화면과 API의 책임을 나누는 데 집중했습니다. 이후에는 그 경계가 소스 관리와 빌드, 운영 반영까지 이어지는지 살펴보게 되었습니다.

좋은 분리는 경계를 많이 만드는 일이 아니라는 생각이 들었습니다. 어떤 코드를 바꾸면 무엇을 확인해야 하고, 어느 산출물을 배포해야 하며, 문제가 생기면 어디로 돌아가야 하는지 설명할 수 있게 만드는 일에 가까웠습니다.

고객은 프론트엔드와 백엔드의 경계를 구분하지 않습니다. React와 Spring Boot를 나눈 뒤 달라진 것은 기술 구조만이 아니었습니다. 변경을 준비하고 운영에 전달하는 기준도 함께 정리해야 하는 문제로 이어졌습니다.