수기 시트 운영을 백오피스 시스템으로 — 마케팅 대행사 A 구축기
3줄 요약
- 경영 컨설팅으로 들어갔다가, 조언을 실행할 주체가 사내에 없다는 것을 확인하고 직접 구축하는 컨설턴트(FDE) 로 역할을 전환했다.
- 1만 4천여 행의 수기 구글시트로 굴러가던 핵심 운영을 실데이터 전수 분석으로 진단하고, 2주 만에 작동하는 화면 3개를 가진 백오피스로 대체했다.
- 시스템을 만드는 것만큼 조직이 그것을 쓰게 만드는 설계(순차 공개 게이트·병행 대조·커뮤니케이션 케이던스)에 공을 들였고, 폐쇄망 납품까지 완주하는 중이다.
1. 진입 — 컨설팅으로 들어가 구축으로 전환한 이유
계약의 시작은 경영 자문·교육이었다. 대표의 구상을 구조화하고 실행 방법을 코칭하는 역할. 그런데 몇 주 안에 구조적인 문제가 드러났다: 조언은 쌓이는데 그것을 시스템으로 옮길 사람이 사내에 없었다. 직원들은 당일 물량을 처리하는 것만으로 하루가 끝났고, 외부 개발자를 쓰기에는 도메인 맥락 전달 비용이 구축 비용보다 컸다.
그래서 역할을 바꿨다. 조언을 문서로 남기는 컨설턴트가 아니라, 현장에 들어가 직접 만들고 나오는 Forward-Deployed Engineer 방식. 판단 근거는 명확했다 — 이 회사의 문제는 “무엇을 해야 하는지 모르는 것”이 아니라 “아는 것을 실행할 손이 없는 것”이었다.
2. 진단 — 숫자로 확인한 수기 운영의 한계
추측으로 시작하지 않았다. 회사의 실제 운영 시트를 내려받아 전수 분석했다.
| 항목 | 실측 |
|---|---|
| 운영 일지 누적 | 14,824행 (13개월, 실사용 191일) |
| 일 처리량 | 평균 ~78건/일 (피크 104건) |
| 거래처(광고주) | 표기 1,034개 → 별칭 정규화 시 853개 (표기 흔들림 다수) |
| 운영 채널 | 표기 197개 → 정규화 시 166개 |
| 리스크 판정 입력 칸 | 채워진 행 28.5%, 한 칸에 최대 42개 항목 수기 나열 |
핵심 발견은 “가독성이 나쁘다”가 아니었다. 계산이 조용히 틀릴 수 있는 구조라는 것이었다. 오늘 어떤 운영 자산을 쓸 수 있는지를 판정하는 규칙이 색깔 패널 5개짜리 수기 계산기에 들어 있었고, 담당자 한 명의 손에 의존했다. 나는 그 규칙을 원본 데이터로 역산해 재현하고(결과값 완전 일치 확인), 그다음에야 시스템화를 제안했다 — 규칙을 코드로 옮기려면 먼저 그 규칙이 무엇인지 증명해야 한다.
자산 운영 리스크도 숫자로 확인됐다: 자산 재사용 간격 중앙값 9일, 14일 이내 재사용이 59%, 운영 계정 308개 중 34개가 이미 정지 상태. 이 숫자들은 평가나 질책 없이 그대로 대표에게 전달했다. 숫자가 스스로 말하게 하는 것이 실행 동의를 얻는 가장 빠른 길이었다.
3. 구축 — 2주 만에 작동하는 화면 3개
| 화면 | 대체한 것 |
|---|---|
| 자산 현황판 | 색깔 패널 수기 계산기 — 리스크 판정 규칙을 코드로 이관 |
| 대시보드 | 대표가 매일 묻던 질문들 — 처리량·부하·리스크 현황 |
| 요청 보드 (칸반) | 카톡 DM으로 오가던 영업↔사무 원고 요청 — 상태 기반 워크플로로 |
스택은 웹앱(TypeScript) + PostgreSQL, 데이터 모델 13개. 설계 원칙 하나를 불변으로 박았다: 자격증명 비저장 — 시스템은 어떤 계정 비밀번호도 저장하지 않는다. 편의보다 법·약관 경계를 구조적으로 강제하는 쪽을 택했고, 이것은 협상 대상이 아니라고 명시했다.
레거시 14,824행은 그대로 이관하되, 표기 흔들림(같은 거래처가 다른 이름으로 1,034가지 표기)을 별칭 정규화로 통합했다. 데이터를 옮기는 것이 아니라 온톨로지를 옮기는 것이 이관의 본질이었다.
4. 운영 설계 — 만드는 것과 쓰게 만드는 것은 다른 문제다
시스템 도입이 실패하는 지점은 코드가 아니라 사람이다. 그래서 공개 방식 자체를 설계했다.
- 껍데기 UI를 열지 않는다. “버튼만 눌리는 데모”는 만들 수 있었지만 거부했다 — 불안한 클라이언트에게 안 되는 화면은 불신을 확인시켜 줄 뿐이다. 단계마다 실데이터로 꽉 찬 화면을 하나씩 열었다.
- 4주 순차 공개 게이트. 전량 일괄 오픈 대신 주 단위 게이트. 각 단계에 완료 선언 조건을 명시하고, 구 시스템(시트)과 병행 대조 기간을 확보해 일치율로 신뢰를 증명한다.
- 2~3일 케이던스의 드롭. 진행 상황을 몰아서 보고하지 않고 짧은 주기로 전달. 첫 드롭은 진단 숫자를 평가어 없이 담백하게 전달하는 톤으로 설계했다.
- 시연 = 교육 + 증빙. 시연 자리에서 실제 요청 1건을 끝까지 완주시켜, 다음 주 실사용이 “빈 보드를 여는 것”이 아니라 “이미 돌아가는 보드에 사람이 들어오는 것”이 되게 했다.
- 말이 시스템을 바꾼다. 대표의 회신 한 줄에서 문서에 없던 요구사항을 발굴해 기능으로 반영하는 루프를 유지했다. 요구사항은 문서가 아니라 대화 속에 산다.
5. 납품 — 폐쇄망 이관까지
납품 조건은 까다로웠다: 회사 내부 PC로의 폐쇄망 이관. 작업을 물리접근 필요/불필요, 쓰기중단 필요/불필요 두 축으로 분해해 현장 방문 2회로 이관이 성립하도록 설계했다. DB는 처음부터 이식성(표준 덤프/복원)을 전제로 구축했고, 내부 검증용 하네스와 회사에 넘길 세팅 스크립트를 분리해 인계 범위를 명세했다 — 받은 쪽이 유지·운영할 수 없는 납품은 납품이 아니다.
6. 결과
v1 시점 (진행 중) 확보된 것:
- 구축 2주, 작동 화면 3개, 데이터 모델 13개
- 레거시 14,824행 무손실 이관 + 거래처 853개 별칭 정규화
- 수기 리스크 계산 → 코드 이관 (역산 검증으로 결과 완전 일치 확인)
- 카톡 DM 워크플로 → 상태 기반 요청 보드 대체
이 프로젝트는 현재 진행 중이다. 납품이 종료되면 병행 대조 일치율, 요청→게시 리드타임 변화, 자산 재사용 간격 개선폭 같은 최종 숫자로 이 글을 갱신할 예정이다 — 결과를 측정하지 않는 구축은 이 회사의 방식이 아니다.
방법론 박스 — 이 케이스에서 재사용되는 원칙
- 진단은 실데이터 전수로. 인터뷰가 아니라 원본 14,824행을 내려받아 분석하는 것에서 시작한다.
- 규칙은 역산으로 증명한 뒤 코드로. 기존 수기 계산을 재현해 완전 일치를 확인하기 전에는 시스템화하지 않는다.
- 경계는 구조로 강제. 자격증명 비저장처럼, 법·약관 경계는 운영 수칙이 아니라 아키텍처 불변식으로 박는다.
- 공개는 게이트로, 신뢰는 병행 대조로. 일괄 오픈 대신 단계 게이트 + 구/신 시스템 병행 기간의 일치율.
- 숫자는 평가어 없이. 나쁜 진단일수록 담백하게 — 숫자가 스스로 말하게 한다.