React 기반 웹서비스로 전환을 준비하면서 작은 고민이 하나 생겼습니다.

화면의 안내 문구 하나를 바꾸기 위해 개발자가 코드를 수정하고, 테스트하고, 다시 배포하는 방식이 앞으로도 맞을까 하는 질문이었습니다.

문구 수정 자체는 어렵지 않습니다. 하지만 변경이 발생할 때마다 개발과 배포가 필요하다면 운영 속도는 계속 개발 일정에 묶이게 됩니다.

처음에는 React로 모두 만들면 된다고 생각했습니다

JSP 화면을 React로 옮기면서 화면과 API의 책임을 분리하는 것이 우선이었습니다.

React는 공통 컴포넌트와 상태를 관리하기 좋고, 서비스 화면을 일관된 기준으로 만들 수 있습니다. 그래서 메뉴, 배너, 공지, 안내 콘텐츠도 React 화면 안에서 관리하면 된다고 생각했습니다.

하지만 운영 관점에서 다시 보니 성격이 다른 영역이 섞여 있었습니다.

업무 규칙과 연결된 화면은 개발과 검증이 필요합니다. 반면 배너 이미지, 공지, 메뉴 노출 여부, 설명 문구처럼 자주 바뀌는 콘텐츠는 운영자가 시점에 맞춰 직접 관리하는 편이 더 자연스러울 수 있습니다.

변경 빈도와 위험도를 함께 봤습니다

모든 화면을 CMS로 관리하면 유연해 보이지만, 업무 로직까지 콘텐츠처럼 다루면 검증하기 어려워집니다. 반대로 모든 변경을 개발 코드에 두면 작은 운영 변경에도 배포가 반복됩니다.

그래서 기능의 성격을 기준으로 나누기 시작했습니다.

  • 거래와 신청처럼 업무 규칙이 있는 영역은 애플리케이션이 담당합니다.
  • 인증, 권한, 고객 데이터와 연결된 내용은 서버 검증을 유지합니다.
  • 배너, 공지, 메뉴, 단순 안내 콘텐츠는 CMS 관리 대상으로 검토합니다.
  • 공통 레이아웃과 디자인 시스템은 React 컴포넌트로 유지합니다.

구분 기준은 단순히 자주 바뀌는지 여부만은 아니었습니다. 잘못 변경되었을 때 고객과 업무에 미치는 영향, 별도의 승인과 검수가 필요한지, 정형화된 데이터로 관리할 수 있는지도 함께 봐야 했습니다.

CMS는 개발을 대신하는 도구가 아니었습니다

CMS를 도입하면 개발자가 필요 없어지는 것이 아니라 개발이 책임져야 할 영역이 더 분명해집니다.

개발팀은 운영자가 안전하게 변경할 수 있는 콘텐츠 모델과 권한, 미리보기, 이력 관리, 배포 기준을 만들어야 합니다. 운영팀은 정해진 범위 안에서 콘텐츠를 등록하고 검수합니다.

React 화면은 CMS에서 받은 데이터를 디자인 시스템 기준에 맞게 표현하고, 값이 없거나 잘못되었을 때도 화면이 무너지지 않도록 처리해야 합니다.

CMS와 React의 관계는 서로 대체하는 구조가 아니라 역할을 나누는 구조에 가까웠습니다.

작은 문구가 플랫폼의 운영 방식을 보여줬습니다

문구 하나를 바꾸는 일은 작아 보입니다. 하지만 그 변경을 누가, 어떤 절차로, 어느 시점에 반영할지는 플랫폼의 운영 방식과 연결됩니다.

개발 없이 바꿀 수 있는 범위를 넓히는 것만이 목표는 아니었습니다. 개발과 검증이 필요한 영역은 지키고, 운영이 직접 책임질 수 있는 영역에는 적절한 도구와 기준을 제공하는 것이 중요했습니다.

CMS에 대한 고민은 기능 하나를 추가하는 데서 시작하지 않았습니다. 작은 변경을 반복해서 안전하게 다루려면 어떤 구조가 필요한지 생각하면서 자연스럽게 시작되었습니다.