백오피스를 고민하다

좋은 백오피스란 무엇일까, 그리고 어떻게 만들 수 있을까.

의도하지는 않았지만, 저는 항상 백오피스 개발을 맡아왔고, 외부 고객이 바라보는 프로덕트 이상으로 내부 고객이 사용하는 백오피스에 대한 고민을 많이 해왔습니다. 회사마다 팀마다 사정이 다 다르지만, 공통적으로 적용될 부분이 있다고 생각합니다.

백오피스?

일단 보편적인 정의를 먼저 살펴보겠습니다. 국문으로 검색해보면 '어드민 페이지'나 'ERP'와 백오피스를 동일하게 보는 글이 많습니다. 영문으로 검색하면 조금 다른데, 위키피디아 백오피스 항목을 보면 회사 내부자가 사용하는 툴이라고 하더라도 고객을 바라보는 CRM같은 툴은 front-office로 보고, 고객과 무관하게 회사 내부적인 비즈니스 운영을 위한 관리도구를 back-office로 보는군요. 리테일에 초점이 맞춰져 있기는 하지만, 재고를 서비스 데이터와 동일하게 보면 대체로 맞을 것 같습니다. 백오피스라는 단어의 유래를 생각하면 정의 자체는 이게 더 정확할 것입니다. 하지만 실무에서는 어떨까요?

백오피스의 역할?

백오피스는 enterprise operation supporting system 입니다.

저는 백오피스를 enterprise operation supporting system (전사운영지원 시스템)의 일부라고 생각합니다. 그 시스템은 단일 소프트웨어로 구성되어 있지 않을 수 있습니다. G-Suite나 Salesforce, 기타 SaaS를 사용한다 하더라도 그것들이 독립적으로 작동하는게 아니라 백오피스를 중심으로 유기적으로 연결되어야 하기 때문에, 별도로 보기 어렵습니다. 결과적으로 백오피스에서 바깥으로 뻗어나가야 하고 그 업무도 백오피스 팀이 맡게 되기 때문에, 실무에서는 백오피스 = 전사운영지원 시스템이라는 등식이 성립한다고 봅니다.

그렇기에 백오피스 작업도 범위가 좀 넓습니다. 실 예로 저는 센드버드에서 백오피스 고유의 기능 - 서비스 데이터 조회, 내부 유저 관리 및 권한 제어, KPI 조회, 과금 기능 외 서비스 운영을 위한 여러 기능들 - 을 개발하기도 했지만 그에 못지 않게 세일즈 툴 연동 (Salesforce 외), 마케팅 툴 연동 (Hubspot 외), 분석 툴 연동 (GA 외), 그리고 이 툴들이 회사의 오퍼레이션에 맞게 유기적이고 자동적으로 작동하도록 많은 고민과 개발을 해야 했습니다. 직접 개발하는 파트 뿐만 아니라, 간접적으로 연결되는 부분도 적지 않은 (때로는 더 큰) 백오피스 개발의 일부입니다.

백오피스 팀은 다른 팀 일도 잘 알아야 합니다.

백오피스 팀은 회사와 각 팀의 크고작은 오퍼레이션에 대해 자세하게 알아야 합니다. 다른 팀이 하는 일을 더 수월하게 할 수 있도록 돕고, 어떤 팀의 결정이 시스템에 미치는 영향을 정확하게 판단해서 결정에 필요한 정보를 제공할 수 있어야 합니다.

실제 예를 들어볼까요? 통신사 요금제처럼 몇 종류의 플랜이 제공되는 구독 시스템에서, 고객이 임의의 시점에 플랜을 변경할 수 있다고 하면 기본요금의 차액과 변경 시점까지 사용량에 대한 금액은 어떻게 처리해야 할까요? 변경 처리가 늦어져서 이미 요금이 청구된 이후 요금제 변경을 처리해야 한다면? 정책을 결정하는 팀에서 한번에 완전한 정책과 워크플로우가 나오기는 어렵습니다. 검토하다보면 빈 구멍이 보이게 마련이고, 번복하려면 비용이 큰 결정도 많습니다. 정확히 어떻게 처리하기를 희망하는지 전체적인 프로세스를 같이 그리고, 빈 구멍에 대해 몇 가지 방안과 결정을 요청하고, 뒤집기 어려운 결정은 왜 그런지 미리 알려주어야 합니다.

기본적으로는 각 팀 - 세일즈팀, 마케팅팀, 오퍼레이션팀, 파이낸스팀 등에서 밑그림을 그리겠지만, 그게 전사적인 관점에서 맞는 방향인지, 구현이 가능한지, 구체적인 각 팀의 니즈를 이해한 위에 더 좋은 대안이 있는지 검토하고 최종적으로 개발하는 것은 시스템 전문가인 백오피스 팀의 몫입니다. 저는 직접적인 개발 뿐만 아니라 이런 과정 모두가 백오피스 작업이고 백오피스 팀의 역할이라고 생각하고 있습니다.

하나 더 예를 들어볼까요? 의류 상품 재고 시스템이라면, 같은 티셔츠라도 흰색, 검은색같은 옵션이 있을 수 있고, 여러 사이즈가 있고, 각 옵션/사이즈마다 재고 수량이 있을겁니다. 이 때 어디까지를 동일한 상품이라고 봐야 할까요? 물류 운영에 맞춘다면, 상품 물류 파트에서 결정할 부분이고, 고객 경험에 맞춘다면 프로덕트 팀에서 알아볼 부분이겠죠. 하지만 이 결정은 상품관리, 재고관리는 물론 서비스 UI 레이어, 주문관리 시스템까지 전체적으로 큰 영향을 미치는 핵심적인 부분입니다. 전사적인 관점에서 적절한 결정을 할 수 있도록 지원해야 합니다.

백오피스의 특성상 타 팀에서 의사결정이 내려온다거나 타 팀의 주도로 무언가 해야하는 상황이 빈번합니다. 그러나 팀과 역할이 어느정도 세분화 된 이후의 조직에서, 각 팀이나 담당자는 다른 파트에 미치는 영향까지 종합적으로 고려해서 일을 추진하기는 어렵습니다. 백오피스 팀은 중앙에서 이런 부분을 조율할 수 있어야 합니다.

좋은 백오피스는

위와 같은 팀에서 만드는 좋은 백오피스는
1. 사내 구성원들의 업무 효율을 높여줍니다.
2. 기본에 충실합니다.
3. 단순하고 직관적입니다.

1. 사내 구성원들의 생산성을 제고합니다.

   백오피스는 서비스 데이터에 대한 가시성을 제공하고, 소모적인 단순작업을 자동화하고, 회사의 주요 오퍼레이션을 구현합니다. 여기서 사내 구성원에는 백오피스 팀도 포함됩니다. 즉, 어떤 팀에서 일주일에 한번, 1시간 하는 작업을 위해 백오피스 팀에서 한 스프린트 혹은 그만한 개발시간을 사용할 필요가 있는지 저울에 올려봐야 합니다.

   실제 사례입니다. 계약 내용을 입력하는 폼과 이를 승인하기 위한 기능이 있습니다. 사용 빈도는 주당 10회 안팎입니다. PO는 여러가지 커스텀 UI를 주문했고, 결과적으로 기본 UI를 이용해 일차적으로 완료한 폼에서 개발자 한명의 스프린트 하나 이상을 추가적으로 사용했습니다. 과연 그 작업에 그만한 의미가 있었을까요?

   회사의 비즈니스 목표를 가중치로 잡고, 회사에서 추구하는 가치의 총량이 최대한 증가하는 방향으로 함수를 잘 짜 자원배분을 해야 합니다.

2. 기본에 충실합니다.

   백오피스의 구성요소의 많은 부분은 이미 정해져 있어서, 백엔드 관점에서는 RBAC나 로깅같은 기능들, 프런트 관점에서는 데이터 리스트 테이블과 필터, 데이터 상세 페이지 등 정형화된 부분들이 많습니다. 솔직히 이런 부분은 많은 백오피스나 어드민 페이지, CRM 등에 공통적으로 나타나는 모습을 보면 알겠지만 패턴이 명확합니다.

   실제 사례입니다. 서비스 데이터 필터에 대한 백/프런트의 모듈화가 되어있지 않아 이 페이지에서는 이렇게 필터링 하고, 또 다른 페이지에서는 저렇게 필터링 하고 있습니다. 어떤 페이지는 뒤로 가면 필터가 초기화되고, 어떤 페이지는 그대로입니다. 페이지마다 동작이 달라져 사용자들이 불편해합니다. 전부 고치자니 작업이 꽤 커져버렸습니다.

   다른 실제 사례입니다. 백오피스에서의 어떤 액션 A에 대해 로그를 남겨야 합니다. A액션로그 라는 테이블이 생겼습니다. 액션 B가 추가됩니다. B액션로그 라는 다른 테이블이 생겼습니다. 어느새 그런 로그 테이블이 두자릿수를 바라봅니다. 누가 어떤 작업을 했는지 파악하려면 많은 수고가 필요한 상황이 되어버렸습니다. 로깅 모듈을 잘 설계했으면 달랐겠지요.

   백오피스는 FM이 있습니다. 이 FM을 아는 PO와 개발자에게, 기초공사를 충분히 할 시간을 주고 맡기세요.

3. 단순하고 직관적입니다.

   백오피스는 단순해야 합니다. 백오피스 hierarchy로부터 서비스 데이터 구조와 ERD가 자연스럽게 파악될 수 있을 정도로 명확하고 직관적이어야 합니다. 설령 오퍼레이션 관점에서 하나의 액션이라 하더라도, 최대한 단일 모델 기준으로 CRUD를 분리하여 백/프런트 양쪽 다 명확함을 유지해야 합니다.

   어떤 쇼핑몰을 예로 들겠습니다. 새로운 물건이 한 박스 입고됐습니다. 기존에 없던 카테고리입니다. 그 물건을 시스템에 등록할 때, (더 있을수도 있지만) 크게는 카테고리, 상품, 재고 세 모델에 인스턴스를 추가해야 합니다. 이를 "입고"라는 하나의 행위로 보고 하나의 폼으로 입력받아 신규 카테고리 등록부터 상품 등록, 재고 등록까지 한번에 처리하려고 할 수도 있겠습니다만, 절대로 좋은 방법이 아닙니다. "입고"라는 로직 자체가 카테고리, 상품, 재고라는 복수의 모델에 종속되어 변동성이 크게 증가합니다. 또한 3개의 단순 CRUD일 수 있었던 로직을 한번에 하려면 복잡도가 크게 증가하고 백/프런트 양쪽 모두 개발 시간과 테스트 범위가 늘어납니다.

   데이터 흐름에 있어 단방향을 지향해야 합니다. 회원가입으로 유저가 생겼을 때 서버에서 외부 SaaS에 리드를 생성한다면, 전체적으로 리드에 대한 정보는 자사 DB에서 외부 SaaS로만 향해야 하고 다시 외부 SaaS에서 자사 DB를 업데이트 하는 순환고리가 생겨서는 안됩니다. 불가피한 경우라면 명확한 규칙으로 데이터 종류를 분리하고 같은 종류에 대해서는 최대한 단방향이 될 수 있도록 해야 합니다.

   Single Source of Truth가 명확해야 합니다. 같은 유저에 대한 이메일을 시스템 A, B에서 각각 a, b라고 서로 다르게 알고 있을 때, B가 이메일에 대한 SSOT라면 그 유저에 대한 이메일은 a가 아닌 b이며, 그 데이터는 B에서 A로 흘러야 하고, 바람직하게는 전체 유저에 대한 정보가 B에서 A로 흘러야 합니다. 그게 직관적이니까요. 시스템이 MSA 구조라서 R&R을 나눠갖는다면, 그 R&R을 반드시 지켜야 합니다.

백오피스 팀에서 겪는 이슈들

백오피스에서 겪는 이슈는 외부 고객을 바라보는 팀의 상황과는 좀 다른 경우가 많습니다. 제가 겪었던 몇 가지 문제와 대처했던 방법들입니다.

• 스펙(기획/요구사항)이 빈약하고, 현 시스템과 동떨어져 있습니다.

  백오피스 기능의 경우 해당 기능을 사용할 팀에서 주도권을 갖고있는 경우가 많은데, 그런 경우에는 요구사항이 현재 시스템이나 데이터 모델에, 기타 제반환경에 대한 고려가 거의 없습니다. 엣지 케이스를 비롯한 스펙의 완성도도 문제가 있습니다. 그렇기에 수동적인 태도로 그저 수용한다면 반드시 문제가 생깁니다.

  해답은 커뮤니케이션과 적절한 대안 제시입니다. 현재 시스템이 어떻게 되어 있고 어떤 부분이 문제가 되는지 충분히 설명하고 같은 목적을 달성할 수 있는 더 좋은 방법을 제시해야 합니다. 또한 기획상 비어있는 부분을 묵과하지 말고 직접 처리하거나 수면위로 올려 결정을 요구해야 합니다.

• 기술적으로 깊이가 얕아 오히려 품질이 떨어지게 됩니다.

  백오피스에는 개발 기술의 깊이가 필요한 작업이 잘 없어 실력향상에 목마른 개발자들이 선호하지 않는 분야입니다. 제 주변에서도 욕심 있고 잘하시는 분들은 결국 팀을 옮기시거나 이직하거나 하셨습니다. 그렇게 백오피스는 신입-주니어 중심으로, 가끔 업무가 넘치면 주변에서 거들어주는 그런 프로젝트가 되기가 쉽습니다. 프로젝트가 커지면, 개별 피쳐의 깊이와 별개로 규모에서 오는 관리적인 요소들이 불거집니다. 여러 사람이 거쳐가는 프로젝트는 그런 맥락이 끊겨 개발의 스타일이 흔들리고, 전체적인 생산성과 품질 저하로 이어집니다.

  이에 대해 팀 레벨에서는 백오피스에 적용할 적절한 수준의 프로토콜을 정하고, 코드 리뷰와 파트 순환 배치를 통해 공통분모를 늘리는 방법 등을 적용해볼 수 있습니다. 일부러 쉬운 문제를 어렵게 만들 필요는 없지만, 새로운 시도를 장려하는 것도 한 가지 방법입니다. 보통 조직에서는 백오피스의 완성도보다 작동여부와 신규 피쳐를 중요시하지만, 백오피스 팀은 그와 별개로 리팩토링을 통해 백오피스가 조직의 성장 속도에 맞춰갈 수 있도록 스스로가 챙겨야 합니다.

  개인 레벨에서는 업무에 직접적으로 관련이 없더라도 학습의 긴장감을 유지할 수 있는 주제를 찾아야 내적 동기부여를 끌어올려야 합니다. 저는 언어와 프레임워크를 좀 더 깊이 공부하고 프레임워크를 최대한 레버리지해서 생산성을 끌어올리는 연구를 했었습니다.

백오피스의 팁 몇가지

• 백오피스는 UI가 상대적으로 중요하지 않습니다. 프런트에 최대한 힘을 빼세요.

  부트스트랩 등의 여러 라이브러리를 검토해서 하나를 채택하고, 해당 라이브러리의 여러 컴포넌트와 그것들이 하나의 페이지에서 어떻게 어우러지는지 충분히 숙지하세요. 완성된 컴포넌트를 조합하고, 데이터만 끼워넣는다는 느낌으로 작업하세요. 있는 컴포넌트로 대체할 수 있는 기능이라면 절대로 그 사소한 차이를 위해 커스텀 컴포넌트를 만들지 마세요. 예를 들어 ant design을 쓴다면, 예시 페이지 처럼 만들면 되고, 필요한 adobe/sketch/figma 리소스도 이미 준비되어 있습니다. 도대체 왜 안쓰는걸까요. 하하.

  이렇게 되면 디자이너도 필요 없고, PO의 UI에 대한 개입도 줄어들고, 전체적인 작업량과 커뮤니케이션 비용이 줄어들어 인풋 대비 아웃풋이 유리해집니다. 여기서 아낀 리소스는 회사의 더 중요한 영역으로 돌릴 수 있습니다.

  또한 디자인의 통일성을 유지할 수 있습니다. 디자이너와 프런트 개발자가 붙어서 디자인 시스템을 완성한 경우가 아니라면 필연적으로 UI가 흔들리고 백오피스는 난잡해집니다.

• Model을 따라가는 Restful API, API를 따라가는 UI

  유저 모델이 있습니다. 그렇다면 백오피스에는 유저에 대한 create, read (list/detail), update, delete API와 필터가 있는 list화면, 연관 모델까지 조회 가능한 detail화면, create/update폼 이렇게가 기본 구조입니다. 통일된 구조는 생산성을 높여주고, 동작에 대한 기대값을 명확하게 하여 사용이 편하게 합니다.

  이런 규칙을 없이 그때그때 기능을 하나씩 추가한 백오피스를 본 적이 있습니다. 페이지간의 통일성이 없었습니다. 어떤 페이지에 무엇이 있는지, 페이지를 보면서도 눈에 들어오지 않았습니다. 유지보수도 매우 곤란했습니다.

• 외부 데이터 연동을 위한 메세지 브로커

  백오피스는 여러 외부 SaaS와 연결하게 됩니다. 그렇게 되면 데이터가 흐르고, 데이터의 일관성을 위해 위에서 데이터 흐름은 단방향이어야 한다고 말씀드렸는데 사실 이게 현실적으로 쉽지 않습니다. 기존의 연동방식이 좀 답답해서 해결 방법으로 event pub/sub + central message broker을 제안한 적이 있는데, 충분한 계획이 없어 팀장님이 반려하셨고 실무에 적용해보지는 못했습니다.

마치며

참 많은 고민과 경험이 있지만, 백오피스 사례들이 완전히 공개하기 어려운 내용들이 많아 표현을 골랐습니다.
백오피스 관련 커피챗(온&오프라인)은 언제든 환영합니다.