프론트오피스와 백오피스는 언제 분리해야 할까

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

‘프론트오피스’와 ‘백오피스’는 사용자를 설명하는 이름이지, 그 자체로 아키텍처 경계는 아니다. 고객이 쓰는 시스템과 운영자가 쓰는 시스템은 화면과 권한이 달라도 하나의 제품처럼 함께 변할 수 있다.

합칠지 나눌지는 두 시스템의 실제 목적에서 출발해야 한다. 여기서 다룬 익명 사례는 코드베이스 크기와 역사, 팀 구성 같은 중요한 정보가 빠져 있었으므로 하나의 결론보다 판단 기준이 중요하다.

목적과 생명주기, 기능의 겹침을 비교한다

먼저 두 시스템의 기능을 나란히 놓고 보자. 백오피스가 같은 개념을 사용하면서 프론트오피스 기능에 더 강한 권한만 더한 형태이고, 한쪽이 바뀔 때마다 다른 쪽도 함께 바뀐다면 이름만큼 경계가 강하지 않을 수 있다.

각자 고유한 기능이 충분히 클 때는 분리의 근거가 선명해진다. 내부 운영 도구에는 고객 화면에 열어둘 수 없는 강제 변경 기능이 필요할 수 있다. 성장 속도와 사용자 집단도 다를 수 있다. 일부 기능이 겹치는 것은 자연스럽다. 중요한 것은 겹치는 부분이 거의 전체인지, 서로 다른 두 제품의 중심 일부만 공유하는지다.

규모도 보되 규모 하나로 결정하지는 않는다. 간단한 설정과 켜고 끄는 기능만 있는 가벼운 어드민이라면 별도 프로젝트가 과할 수 있다. 독자적인 기능과 생명주기를 가진 큰 백오피스라면 분리가 어울릴 수 있다. 차이는 그림의 이름이 아니라 소프트웨어가 실제로 하는 일에서 보여야 한다.

팀이 일하는 방식으로 경계를 검증한다

아키텍처와 작업 방식이 서로 어긋날 수 있다. 작은 팀에서는 개발자 한 명이 한 기능을 프론트오피스부터 백오피스까지 이어서 맡기도 한다. 기능 하나를 만들 때마다 두 저장소를 함께 수정하고 별도로 배포하며 같은 모델 변경을 반복한다면, 독립적인 소유권 없이 마찰만 늘어날 수 있다.

이 경우 프로젝트를 합치거나 한 저장소의 모듈로 두는 선택을 검토할 만하다. 발표자는 작은 팀에서 함께 시작한 뒤 목적, 생명주기, 코드베이스 크기, 소유권 차이가 구체적으로 생길 때 분리하는 편을 선호한다. 다만 이미 분리할 역사가 있는 시스템까지 무조건 합치라는 규칙은 아니다.

반대의 신호는 별도 팀과 작업 흐름이다. 발표자가 겪은 한 사례에서는 백오피스 영역이 커지면서 전담 팀이 생겼다. 이때 분리는 미래를 미리 맞힌 그림이 아니라 독립된 책임을 반영하는 구조가 됐다.

실제로 작업하는 팀원과 비용을 확인해야 한다. 한 작업을 위해 계속 경계를 넘나들고 분리 구조가 전달 속도를 높이지 못한다면 그 마찰은 중요한 근거다. 서로 다른 책임을 중심으로 각자 발전할 수 있다면 분리를 유지할 이유가 생긴다.

영속성 코드만 공유하는 세 번째 경계를 경계한다

같은 테이블을 본다는 이유만으로 곧바로 MSA 방식의 데이터베이스 분리가 필요한 것은 아니다. 개발자가 직접 스키마를 관리하고 별도 DBA가 없는 이 작은 팀의 상황에서는, 애플리케이션 경계도 확인되지 않은 채 데이터 경계를 더하는 일이 먼저 비용을 만들 수 있다.

별도 버전으로 배포하는 엔티티 라이브러리도 비슷한 문제를 만들 수 있다. 발표자는 두 애플리케이션이 배포된 엔티티 패키지를 참조하는 구조에서 일한 경험을 이야기한다. 버전이 어긋나고, 한쪽 변경이 다른 쪽 배포와 조정을 요구했으며, 공유 패키지 자체가 또 하나의 관리 대상이 됐다. 이렇게 작고 강하게 결합된 시스템에서는 중간 계층이 결합을 없애기보다 결합도에 버전 번호를 붙일 수 있다.

더 명확한 선택은 애플리케이션을 실제로 독립시켜 각각 관리하거나, 대부분의 변경이 함께 움직이는 코드를 합치는 것이다. 분리된 모양을 유지하기 위해서만 공유 라이브러리를 두지는 말아야 한다.

판단 순서는 아키텍처에서 시작한다. 두 목적과 생명주기가 실제로 존재하는지부터 확인한 뒤, 거기에 맞는 가장 작은 운영 경계를 선택해야 한다.