brunch

매거진 3시 27분

You can make anything
by writing

C.S.Lewis

by 기획하는 족제비 Mar 03. 2023

결제 프로세스 및 백오피스 개선 프로젝트 회고-1

내부 고객을 위한 백오피스 기획


인트로

본인이 다녔던 회사는 소수 코파운더들의 사이드 프로젝트로 시작한 회사다. 최초에는 빠른 MVP 검증을 목적으로 개발된 플랫폼이었는데, 현재는 약 70명이 넘는 중견 정도의 회사로 성장했다.


문제는 확장성이 고려되지 않은 개발구조를 그 누구도 건들 생각을 못하고 있었단 것. 초기 개발자의 퇴사, 코드 주석과 시니어 개발자의 부재라는 콤비네이션으로 인해 덮어두어 곪아있던 문제들이 결국 회사의 스케일이 확장됨에 따라 터져 나오기 시작했다.


이번 회고 글은 CPO님이 입사하시면서 회사의 곪은 상처들을 봉합하기 위해 진행한 플랫폼 리뉴얼 프로젝트 중 하나인 결제 프로세스 및 백오피스 개선 프로젝트에 대한 내용이다. 백엔드 기획이 낯설었던 2년 차 프로덕트 매니저가 진행한 프로젝트인 만큼 베테랑들이 보기에는 답답한 부분들이 분명히 있을 것이다. 그럴 때는 기꺼이 피드백을 남겨주시길.




결제 프로세스 및 백오피스 개선이 왜 필요했을까?

이 프로젝트가 발화된 작년 시점에 내년에 BEP를 달성하는 것이 회사의 목표로 정해졌다. 이 때문에 영업을 더욱 확장하여 매출을 늘려야 한다는 결론이 따라왔는데, 백오피스 시스템에 얹어지지 못한 프로세스들이 담당자들의 발목을 잡았다.


시스템에서 그들의 업무를 받쳐주지 못하니 담당자들은 다른 방법을 찾아 일을 기록하며 진행했고 결국 분절된 프로세스의 각 단계들을 커뮤니케이션을 통해 메꾸기 시작했다. 하지만 시간이 지날수록 더욱 많아지는 업무들을 몸빵으로 버티다가 한계에 다다르게 된 것. 그들은 구조 개선 없이는 영업 확장을 견딜 수 있는 상태가 아니었다.


이 때문에 플랫폼 리뉴얼이라는 대규모 프로젝트 안에서 결제 프로세스 백오피스 개선을 함께 진행하는 것으로 결정되었다. (리뉴얼 프로젝트 개요: NoSQL기반의 Firebase와 Vue.js를 사용하던 플랫폼을 React.js + Spring + RDB의 형태로 리뉴얼하는 게 1차 목표였던 대규모 프로젝트)



“담당자분들 시간 좀 내주세요.” 유저 인터뷰를 진행하다.

프로젝트의 필요성이 제기되었으면 진짜 이 프로젝트가 필요한 것인지, 실제로 어떤 문제를 겪고 있는지 실제 유저들과 인터뷰를 하는 것이 바람직하다고 생각한다. 그래야 좋은 사용자 경험을 이끌어낼 수 있을 것이니 말이다. 그래서 여타 프로젝트와 마찬가지로 문제 진단과 분석을 위해 인터뷰를 먼저 진행했다.


이 프로세스의 주 사용자는 영업팀, 운영팀, 회계팀. 백오피스 기획 프로젝트여서 다행인 것은 인터뷰해야 하는 대상이 멀리 있지 않다는 것 그리고 이미 어느 정도의 라포Rapport가 형성되어 있다는 것이었다. VOC를 운영하며 외부 고객들과 소통하는 과정보다는 정보 수집이 쉬웠다.


인터뷰에 앞서 먼저 한 것은 각 담당자들이 업무에 사용하는 노션, 구글 시트를 확인하는 것이었다. 앞서 리뉴얼 프로젝트를 진행하기 위해 문서 위치와 성격은 모두 파악해 놨기 때문에 인터뷰 때 사용할 질문 정리는 그리 어렵지 않았다. 결제, 세금계산서에 대한 팀별 업무 분석을 이틀에 걸쳐 1차로 마무리한 뒤, 각 팀장님들께 팀 인터뷰를 요청하여 어렵지 않게 미팅을 잡을 수 있었다. (여기서 이해관계자와 라포의 중요성을 다시 한번 느꼈다.)


미팅은 2주에 걸쳐 진행했다. 당시 영업팀이 7명, 운영팀이 6명, 회계팀이 2명이었는데 사람이 많아 일정 조율이 힘들었다. 워킹데이 6일 정도에 걸쳐 팀장님, CPO님과 함께 팀별 미팅을 한 이클 돌리고, 영업팀의 경우에는 워킹데이 9일쯤 되는 날 단독으로 영업팀 팀장님을 포함해 4명 정도와 미팅을 한 차례 더 가졌다. 그렇게 정리한 업무 분석 및 요구사항 리스트.

유저 인터뷰 때 사용한 시트



그들의 문제는 무엇이었을까?

그들과 인터뷰를 통해 분석한 흐름은 이러했다.


영업팀은 계약을 따오고 마케팅 신청을 유도하고, 자신을 마크업 하고 있는 운영팀 멤버에게 알린다. 그러면 운영팀에서 해당 건에 대한 입금을 확인하고 구두 혹은 툴의 멘션 기능을 통해 영업팀에게 이를 다시 알린다. 별개로 회계팀은 입금 확인된 건을 따로 확인하고 세금계산서를 발급한다. 만약 입금을 받기 전 세금계산서를 먼저 발급해야 하는 경우라면 영업팀은 별도 페이지를 통해 세금계산서 선발급을 신청하고 회계팀을 멘션 하여 세금계산서를 발급받는다.

개선 전 업무 흐름


1차 업무 분석을 하면서 설마 했던 것이 인터뷰를 하니 실제로 밝혀졌다. 결제 확인부터 세금계산서 발급까지의 업무 프로세스가 오프라인과 노션을 걸쳐 파편화되어 있다는 것. 심지어 담당자마다 프로세스가 약간씩 달랐다. 누구는 이 단계를 선행하고 누구는 이 단계를 건너뛴다던지..


이를 통해 정의한 문제는 아래와 같다.   

1. 결제 건에 대한 생성 근거는 알 수 있어도 어떤 근거로 프로세스가 진행되는지 그 흔적을 추적하기가 어렵다는 점. 실제로 프로젝트를 진행하기에 앞서 인터뷰를 진행하다 보니 구글시트에서 왜 생성되었는지 모르는 레코드들이 나타나는 사례가 왕왕 등장했다.


2. 업무 파편화로 인해 히스토리 관리가 쉽지 않다는 점. 구글 시트의 경우에는 데이터 수정 시 누가 언제 수정했다를 관리하지 못하고 있었다. 그리고 구글 시트 및 노션에서 데이터가 중복되어 혼재되어 있는 것은 물론, 설령 데이터가 백오피스(어드민)를 통해 남겨지더라도 기존 개발이 Firebase로 되어있다 보니 SQL을 통한 데이터 확인이 힘들다는 문제가 있었다. 


3. 업무 프로세스의 표준화가 되어있지 않았다는 점. 이 때문에 이슈 발생 시 매뉴얼화가 쉽지 않았고 대처들이 구두로 그때 그때 이루어졌다. 히스토리를 잘 아는 한 명이 퇴사하게 되면 즉시 병목현상이 발생하게 된다는 문제가 았었다.




꽤 큰 프로젝트였던 만큼 회고를 하니 내용이 길어져서 2부로 나눠서 올릴 예정


ⓒ 327roy

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari