AI와 함께 업무 시스템을 다시 설계하다: Salesforce 대체 CRM 개발기

0. CRM을 새로 만든다는 것

안녕하세요. Ad Management 파트 서버 엔지니어 프랭크, 고영민입니다. 올해 3월 세일즈포스 대체 방안을 처음 논의한 뒤, 6월 내재화 CRM인 "버즈포스(BuzzForce)"로 실제 업무를 전환하기까지의 여정을 소개하려고 합니다.

버즈빌은 마케팅 리드 확보, 영업 파이프라인 관리, 캠페인 운영, 성과 기반 정산으로 이어지는 긴 업무 흐름을 세일즈포스 위에서 운영하고 있었습니다. 현업의 업무 방식은 계속 바뀌었지만, 외부 CRM을 커스터마이징하고 내부 시스템과 연동하는 속도는 점점 병목이 되고 있었습니다. 버즈포스 프로젝트는 단순히 세일즈포스를 대체하는 것이 아니라, 각 담당자의 업무 방식을 전환하고 개선하는 일이었습니다.

제한된 일정 안에서 유지할 업무 방식과 개선할 비효율을 구분해야 했고, 과거 데이터와 backward-compatible하면서도 데이터 가시성과 정합성을 높이는 설계를 선택해야 했습니다. 이미 운영 중인 업무 시스템을 옮기는 일이었기 때문에 무중단 배포와 데이터 마이그레이션도 안전하게 준비해야 했습니다.

이 글에서는 세일즈포스를 탈출하기로 결정하기 위해 설득과 설계의 기반을 어떻게 마련했는지, 제품 구현 과정에서 AI와 어떻게 분업했는지, 최종 전환 이후 버즈포스가 버즈빌에 어떤 가치를 가져왔는지 이야기해보겠습니다.

1. 세일즈포스는 어떤 비효율을 가지고 있었나?

버즈빌은 세일즈포스를 10년 이상 사용해왔고, 그 사이 세일즈포스를 사용하는 팀과 각 팀의 업무 방식도 모두 바뀌었습니다. 하지만 세일즈포스는 외주사를 거쳐야만 커스텀이 가능했고 현재는 세일즈포스를 전담하는 팀도 없습니다. 무엇보다 데이터 구조를 온전히 이해하고 지속적으로 개선할 책임자가 부재했습니다. 사용하지 않는 필드와 규칙이 복잡하게 얽히면서, 세일즈팀과 재무팀 모두 불편에 익숙해진 상태로 업무를 지속하고 있었습니다.

또한 버즈빌의 셀프서빙 플랫폼인 광고센터를 출시하면서 백엔드 시스템과 세일즈포스의 연동을 자동화했습니다. 세일즈포스의 데이터 구조와 조회 방식을 이해하는 데에도 리소스를 투자해야 했고, 광고센터, 광고운영시스템, 세일즈포스 3개 시스템의 정합성을 유지하는 난이도도 상당히 높았습니다. atomic한 트랜잭션을 구현하는 것도 사실상 불가능했으며, 예상치 못한 이유로 API token이 무효화될 때마다 secret rotation과 데이터 백필에도 긴 시간이 걸렸습니다.

AI Agent가 업무에 도입되었음에도 세일즈포스의 비효율이 병목이 되어 전체 업무 효율은 크게 나아지지 않았습니다. 실제 사용자인 운영 조직과 세일즈포스를 기반으로 프로덕트를 개발해야 하는 제품 조직의 문제의식이 합쳐지면서, "우리가 직접 만들자"는 의견이 나왔습니다.

7월 라이선스 연장을 4개월 앞두고, 세일즈포스를 제거하면서 라이선스 비용 약 1억 원을 절약하는 계획을 논의하기 시작했습니다.

2. AX전환의 불확실성 낮추기: ERD & PoC

그렇다고 "그럼 직접 만들면 되겠다"라고 바로 결론을 낼 수는 없었습니다. 세일즈포스 비용과 비효율은 명확했지만, 자체 CRM을 만든다는 결정은 되돌리기 어렵습니다. 한 번 내부 시스템으로 전환하면 이후 유지보수, 장애 대응, 기능 개선, 데이터 정합성에 대한 책임도 모두 내부에 남습니다.

개발 리소스 관점에서도 부담이 있었습니다. 별도의 전담 제품팀 없이 디자인, FE 구현 등을 AI Agent로 완수해야 했습니다. 기존 업무와 OKR을 진행하면서, 동시에 회사 전체가 사용할 업무 시스템을 새로 만들어야 했습니다.

불확실성을 줄이고, 성공 여부에 대한 의심을 실질적인 피드백으로 바꾸기 위해 "ERD"와 "PoC"를 1차 목표로 정했습니다.

ERD(Entity-Relationship Diagram)는 제품 개발의 초기 단계에서 각 객체(Entity)가 어떤 데이터를 담고 있고, 객체 간에 어떤 관계가 있는지 그림으로 표현하는 과정입니다. ERD를 통해 버즈포스의 데이터 구조가 세일즈포스의 주요 데이터를 표현할 수 있는지, 그리고 앞으로의 변경에 대응할 유연성을 갖추고 있는지 설명할 수 있었습니다.

특히 AI Agent를 활용해 각 객체를 클릭했을 때 객체의 특징을 하이라이트하고, 업무 시나리오마다 어떤 객체가 관여하는지 보여주는 인터랙티브 ERD를 제공했습니다. ERD는 "우리가 만드는 제품이 표준 CRM과 너무 달라서 나중에 문제가 되지 않을까?"라는 막연한 의심을, "세일즈포스의 이 데이터는 왜 버즈포스에서는 이렇게 저장하나요?"라는 구체적인 질문으로 바꾸는 매개가 되었습니다.

아래 ERD는 인터랙티브 다이어그램입니다. 엔티티를 직접 클릭하면 관련 관계가 하이라이트되고, 시나리오 탭에서 업무 흐름별로 어떤 객체가 관여하는지 확인할 수 있습니다.

ERD를 공유한 뒤에는 4월 말까지 PoC 제품을 만들어 실제 사용자에게 시연하고, 완전 전환 여부를 판단하기로 했습니다.

3. 세일즈포스는 무슨 일을 하고 있었나?

세일즈포스는 영업관리 툴인 CRM의 대명사처럼 여겨지지만, 실제 버즈빌에서는 CRM보다 더 큰 역할을 하고 있었습니다.

가장 앞단에는 MC(Marketing & Communication)팀이 Pardot이라는 마케팅 툴을 사용하여 마케팅 캠페인을 운영하고, 전략적으로 리드를 확보해 세일즈팀에게 전달하고 있었습니다. 세일즈팀은 MC팀으로부터 인계받은 신규 고객이나 기존 고객과의 미팅을 통해 새로운 광고 집행을 제안하는데, 이 거래 단위를 "기회(Opportunity)"라고 부르고 있었습니다.

기회는 제안 단계를 시작으로 체결, 광고 운영, 최종 정산까지 광고 수주의 전체 사이클을 담당합니다. 재무팀은 광고 집행이 종료된 기회에 매출, 매입 세금계산서를 매칭하여 버즈빌이 광고주로부터 받는 돈과 대행사에게 지급해야 하는 돈을 기록합니다. 특히 정산에는 다양한 엣지케이스가 있어 기존에도 세일즈팀과 재무팀 사이에 비효율적인 커뮤니케이션이 상당히 많았습니다.

또한 기회와 클라이언트를 중심으로 자유롭게 리포트를 생성하여 버즈빌의 영업 현황을 파악하고 의사결정을 내리는 기능도 필요했습니다.

즉 버즈빌의 세일즈포스는 CRM, 마케팅, 영업 리포트, 정산까지 모두 책임지는 시스템이었습니다. 버즈포스를 만들기 위해서는 각 사용자의 니즈와 현재 워크플로우, 개선하고 싶은 방향을 이해해야 했습니다.

4. AI로 가설을 세우고, 인터뷰로 검증한다

저는 세일즈포스를 직접 업무에 사용해본 적이 없었기 때문에, 각 필드의 의미와 validation 규칙을 이해하고, 사용자가 직접 입력하는 데이터와 자동으로 계산되는 값을 구분하는 데 어려움이 있었습니다. 이때 AI Agent를 활용해 세일즈포스 데이터의 패턴을 분석했고, 필드 간 관계와 숨어 있는 업무 규칙을 역추적했습니다.

예를 들어 기회가 체결 단계로 넘어가면 집행 시작일과 종료일의 채움률이 20%에서 89%로 올라가고, 세팅요청 단계에서는 Daily Cap과 타겟팅 정보의 채움률도 90% 이상으로 올라갔습니다. 이 분석은 곧바로 버즈포스의 Stage 전환 validation으로 이어졌습니다.

정산 데이터에서도 비슷한 방식으로 규칙을 찾았습니다. 일부 대행사는 월마다 수십~수백 개의 광고를 집행한 뒤 통합 세금계산서 1건을 발행했고, 이 세금계산서를 여러 기회에 나누어 매칭해야 했습니다. 마이그레이션 과정에서는 기회별 수수료율 비중을 기준으로 금액을 분배하는 fallback rule을 만들었고, 이 방식으로 대부분의 기존 데이터를 설명할 수 있었습니다. 데이터 모델에서 OppBilling을 별도로 둔 것도 이런 분석 결과가 있었기 때문입니다.

운영팀은 세일즈포스를 사용하고 있었지만 직접 설계하지 않았기 때문에, 사용자 인터뷰만으로는 이런 규칙을 파악하기 어려웠을 가능성이 큽니다. AI로 데이터에서 얻은 인사이트는 즉시 제품 설계로 이어졌습니다.

하지만 데이터가 모든 것을 설명해주지는 못했습니다. Stage가 거꾸로 이동하는 경우가 있는지, 세일즈팀이 실제로 어떤 화면 순서로 값을 입력하는지, 재무팀이 예외 케이스를 어떤 기준으로 처리하는지 같은 "유스케이스"는 데이터 분석만으로 알 수 없었습니다.

그래서 세일즈팀, MC팀, 재무팀 인터뷰를 직접 진행했습니다. 세일즈팀에는 기회가 제안에서 체결, 세팅요청으로 넘어가는 실제 흐름을 물었고, MC팀에는 Pardot에서 들어온 리드가 어떤 기준으로 세일즈팀에 전달되는지 확인했습니다. 재무팀에는 매출 세금계산서, 매입 세금계산서, 입금 내역을 각각 어떤 순서로 확인하고 어떤 경우에 수동 판단이 필요한지 물었습니다.

AI는 세일즈포스 DB 스키마와 샘플 데이터를 빠르게 분석하여 필드 채움률과 이상 패턴을 뽑아냈습니다. 이런 방식은 "이 필드는 이 단계에서 확정되는 것 같다"는 가설과 인터뷰 질문 목록을 만드는 데 유용했습니다. 반면 그 가설을 실제 사용자에게 검증하고, 어떤 규칙을 제품에 반영할지 결정하고, 이해관계자들이 납득할 수 있는 언어로 설명하는 일은 사람이 해야 했습니다.

AI는 분석의 속도를 높여주었지만, 그 분석이 실제 업무와 맞는지 확인하고 제품의 책임 범위로 바꾸는 과정에는 커뮤니케이션이 필요했습니다.

5. 화면 뒤의 데이터를 다시 설계하기

세일즈포스에는 하나의 필드가 여러 의미를 가지는 경우가 있어 데이터 유실의 위험이 항상 존재했습니다. 예를 들어 광고주에게 제안한 캠페인의 "예산"과 실제 캠페인이 송출된 뒤의 "소진액"을 구분하고 있지 않아, 각 기회의 미소진 비율을 확인하려면 광고운영플랫폼을 함께 확인해야 했습니다. 이러한 묵은 문제를 해결하기 위해 버즈포스의 데이터 구조는 "명시성"을 중심으로 설계했습니다.

대표적인 예가 기회와 클라이언트의 관계입니다. 각 광고 기회에는 광고주, 대행사, 미디어렙사 클라이언트가 관여할 수 있습니다. 세일즈포스는 기회에 관련된 클라이언트를 모두 기회 테이블의 필드 레벨로 관리하고 있어, 3개 이상의 클라이언트가 참여하는 경우 데이터 유실이 있었습니다. 버즈포스에서는 이를 OppAccount라는 별도 테이블로 분리했습니다. 하나의 기회가 여러 클라이언트와 연결될 수 있고, 각 연결은 advertiser, agency, media_rep 같은 역할과 수수료율을 가집니다. 정산 대상 클라이언트를 찾고, 광고주/대행사/렙사 기준으로 리포트를 집계할 때 기준이 명확해졌습니다.

클라이언트와 연락처의 관계도 마찬가지였습니다. 실무에서는 한 담당자가 여러 광고주나 대행사와 연결될 수 있고, 담당자와 클라이언트의 관계가 명확해야 활동 등록, 세금계산서 발행 등에서 휴먼 에러가 줄어듭니다. 그래서 연락처를 특정 클라이언트 하나에만 종속시키지 않고 AccountContact라는 중간 테이블을 두었습니다. 이 모델은 담당자와 클라이언트의 N:M 관계를 표현하고, role, is_primary, is_active 같은 정보를 함께 저장할 수 있게 해줍니다.

정산 영역에서는 OppBilling이 핵심이었습니다. 월마다 수십~수백 개의 광고를 집행하는 대행사가 통합 1건의 세금계산서를 발행한 경우, 전체 금액을 여러 기회에 분배해서 매칭해야 합니다. 또한 장기간 집행하는 광고 캠페인의 경우 하나의 기회가 여러 번 정산 과정을 거칠 수 있습니다. 버즈포스는 OppBilling을 통해 Opportunity와 Billing의 N:M 관계를 만들고, 필요할 경우 기회별 배정 금액까지 저장할 수 있게 했습니다.

표현해야 하는 모든 엣지케이스를 데이터 유실 없이 기록하고 분석할 수 있도록, 버즈포스에서는 relation 테이블을 적극적으로 활용했습니다.

6. AI 개발의 병목은 피드백 루프였다

FE 개발 경험이 전무했던 저는 FE 레포에서 간단한 기능 개발이나 버그 픽스 정도만 해보았고, A부터 Z까지 Agent를 활용해 FE를 개발한 것은 버즈포스가 처음이었습니다. 제가 버즈빌에 입사한 2024년 12월 이후 Agent의 발전 속도는 점점 빨라졌고, 버즈포스 출시 전에도 자유도가 높은 리포트 기능을 제외하면 "기능 구현" 자체가 병목이 되는 경우는 거의 없었습니다. 오히려 프로젝트가 진행될수록 병목은 코드를 작성하는 시간이 아니라, 그 결과물을 검증하고 다시 수정하는 피드백 루프였습니다.

가장 위험했던 착각은 AI가 화면을 빠르게 만들어준다는 이유로, AI가 프론트엔드 엔지니어의 역할까지 대신해준다고 생각한 순간이었습니다. 프론트엔드 엔지니어 동료였다면 구현 이후 "bulk 작업인데 단건 모달만 있으면 안 되지 않나?", "4XX 에러인데 에러 토스트가 불친절해서 사용자가 현재 상태를 파악하지 못하겠네?" 같은 질문을 스스로 던졌을 것입니다. 하지만 Agent는 제가 입력한 문제를 빠르게 풀었을 뿐, 제품 맥락을 지속적으로 붙잡고 스스로 피드백 루프를 돌리지는 못했습니다. 버즈포스는 데이터 정합성 등의 이유로 dual write 기간을 따로 두지 않고 바로 전환하기로 결정했기 때문에 반드시 사용자가 업무를 완수할 수 있는 상태로 만들어야 했습니다.

현재 일하는 팀에는 QA 엔지니어가 없기 때문에 기능을 직접 QA하는 업무 프로세스에는 익숙했습니다. 하지만 버즈포스는 QA 범위가 매우 넓었고, 저 역시 모든 업무 맥락을 처음부터 알고 있던 상태가 아니었기 때문에 난이도가 높았습니다. 그래서 Agent에게 작업을 지시할 때는 반드시 QA를 위한 테스트 데이터 생성과 QA 가이드라인 HTML 문서를 함께 작성하도록 했습니다.

Agent는 staging DB에 접근할 수 있었기 때문에, 이번에 구현한 기능을 테스트하기에 적절한 기존 데이터를 선택하거나 필요한 데이터를 새로 생성할 수 있었습니다. QA 가이드라인 문서는 제가 여러 기능을 동시에 개발하는 와중에도 집중도를 잃지 않게 해주었습니다. 동시에 CLI 화면이 아니어도 Agent에게 "이 기능은 이렇게 수정되어야 한다", "이 엣지케이스에 맞는 데이터를 생성해달라" 같은 지시를 내릴 수 있는 인터페이스가 되었습니다.

출시 이후 실제 사용자가 업무를 시작하자 문의와 버그가 계속 들어왔고, 그때마다 원인 분석, 기능 수정, 테스트를 빠르게 반복해야 했습니다. 이 과정에서도 여러 Agent를 동시에 돌리며 각 이슈를 병렬로 처리했습니다. 개발 중의 빠른 iteration이 출시 후 운영 iteration으로 이어졌습니다.

이때 새롭게 드러난 병목은 제 맥락 전환 비용이었습니다. 여러 Agent가 동시에 결과물을 만들어내면, 저는 각 작업의 배경을 다시 떠올리고 원하는 결과가 나왔는지 판단한 뒤 다음 지시를 내려야 했습니다. 마치 CPU가 실제 연산보다 context switching에 더 많은 시간을 쓰는 상태에 가까웠습니다. 정신적인 체력도 꽤 부담이 되었습니다.

다음에 비슷한 프로젝트를 한다면 Agent가 스스로 피드백 루프를 돌릴 수 있는 프레임워크를 먼저 만들 계획입니다. 사용자 시나리오, acceptance criteria, 테스트 데이터 등을 Agent가 스스로 확인하게 만드는 방식입니다. AI 개발의 다음 병목은 코드를 더 빨리 쓰는 것이 아니라 피드백 루프를 얼마나 자율적으로 돌릴 수 있느냐에 있다고 느꼈습니다.

* 저는 AI Agent에게 작업을 지시할 때 STICC Framework를 애용합니다. Situation(상황), Task(작업), Intent(의도), Concern(우려), Calibration(조정) 5가지 관점에서 일을 묘사하면 모호한 프롬프트에 비해 작업물의 완성도가 훨씬 높아집니다. 프롬프트 엔지니어링은 이미 과거의 유산처럼 느껴지지만, 제 머릿속의 암묵지를 AI Agent에게 전달하는 과정은 여전히 중요합니다. STICC 프레임워크에 맞게 일을 지시하면서 미처 생각하지 못했던 엣지케이스를 발견한 경우도 많았습니다. 버즈빌 동료인 루카스께서 알려주셨습니다. 감사합니다.

7. 버즈포스가 남긴 것

버즈포스를 통해 "모든 것을 의심하는 태도"가 AX 시대의 중요한 덕목이라는 생각을 하게 되었습니다. AI와 함께라면 이전에는 개인이 시작하기 어려웠던 일도 끝까지 밀어붙일 수 있습니다. 그래서 출발점은 "당연해서 의심하지 않았던 것이 뭘까?"가 되어야 합니다.

질문에서 시작했다면 완수는 AI와의 분업으로 가능해집니다. AI는 빠른 구현과 반복 작업, 사람의 context switching을 보조하는 역할을 맡을 수 있습니다. 반면 사람은 도메인 지식을 Agent가 이해할 수 있는 형태로 전달하고, 인터뷰를 통해 실제 사용자의 니즈를 파악해야 합니다. 옆 사람을 설득해 프로젝트를 앞으로 끌고 나가는 것도 여전히 사람의 역할입니다.

버즈포스는 6월 15일 공식 런칭 이후 업무 전환되었고, 세일즈팀과 재무팀은 더 이상 세일즈포스를 사용하지 않고 기존 업무를 수행하고 있습니다. 리포트 고도화, 기존 광고 운영 시스템과의 연동, 기능 개선과 버그 픽스는 계속 진행 중이며 7월 초 현재 6월 집행 광고에 대한 광고비 정산 업무도 버즈포스에서 진행되고 있습니다.

아직 공식 만족도 조사나 정량 지표 분석을 진행한 것은 아니지만, 문의 채널과 사용자 피드백에서 흥미로운 차이를 느꼈습니다. 세일즈팀은 "기존 업무를 문제 없이 이어갈 수 있다"는 반응에 가까웠다면, 재무팀은 "업무가 많이 효율화되었다"는 반응을 더 명확하게 표현했습니다.

차이는 제품을 사용하는 방식에서 나왔다고 생각합니다. 세일즈팀이 사용하는 기능과 메뉴는 대부분 데이터와 엔티티 중심입니다. 광고주와 미팅한 뒤 클라이언트와 기회를 생성하고, 이메일과 미팅을 거치며 광고 집행 일정이 확정되면 단계를 변경하고, 광고 운영팀은 기회를 보고 캠페인을 운영합니다. 즉 세일즈팀에게 버즈포스는 버즈포스 바깥에서 일어난 일을 기록하고 조회하는 시스템에 가깝습니다.

반면 재무팀은 "매입 세금계산서와 기회를 매칭한다", "매출 세금계산서를 업로드한다"처럼 행동과 유스케이스 중심으로 버즈포스를 사용합니다. 재무팀의 업무는 새로운 데이터를 생성한다기보다 여러 시스템과 문서에 흩어진 데이터를 연결하고 검증하는 액션에 가깝습니다. 기존 세일즈포스에서는 이런 유스케이스가 기회 상세 페이지 곳곳에 흩어져 있어 불편이 컸지만, 버즈포스에서는 유스케이스 단위로 페이지와 URL을 분리하고 자동화 기능을 추가했습니다.

이 차이를 보며 업무 시스템의 만족도는 "사용자의 일을 어떤 단위로 제품화했는가"에 크게 영향을 받는다는 것을 느꼈습니다. 플랫폼 안에서 많은 일을 처리할 수 있고, 플랫폼 밖의 업무와 자연스럽게 연결되며, 사용자가 자신의 업무를 유스케이스 단위로 이해하고 실행할 수 있을 때 변화가 더 크게 체감됩니다. 비개발자 또한 자신의 업무를 유스케이스 단위로 정의할 수 있어야 Agent를 이용한 업무 효율화가 쉬워질 것이라고 생각합니다.

세일즈팀이 사용하는 버즈포스의 현재 모습은 아직 세일즈포스와 유사한 부분이 많습니다. 세일즈팀의 업무 효율을 더 크게 높이려면, 그들이 실제로 어떤 흐름으로 일하는지 더 깊게 이해하고 이를 유스케이스 단위로 다시 제품화하는 과정이 필요합니다. 엔티티 이름이 곧 메뉴 이름이 되는 고전적인 UI에서 벗어나면 업무 시스템이 더 큰 변화를 만들 수 있지 않을까 상상해보았습니다. 물론 그런 큰 변화까지 가기 전에도 할 일이 많아, 아직 고민을 깊게 해보진 못했습니다.

남은 하반기에는 영업 및 운영 효율화 태스크에 제 리소스의 20~30% 정도를 사용할 계획입니다. 우선 광고 운영 시스템과 버즈포스의 연동을 강화해, 운영자가 직접 개입해야만 광고가 집행되는 현재 프로세스를 줄여가려고 합니다. 동시에 버즈빌 영업의 병목을 더 빠르게 찾고 원인을 분석할 수 있는 인터페이스도 마련하려고 합니다. 버즈포스의 데이터를 분석계에 연동하여 LLM을 통한 분석도 쉽게 가능합니다.

버즈포스를 통해 관습적인 상태를 다시 질문하고 유스케이스 단위로 제품화하는 경험을 얻었습니다. 무엇이든 더 빨리 만들 수 있는 시대일수록, 무엇을 만들고 어떤 업무를 책임질지 정의하는 일이 더 중요해졌습니다. 앞으로도 버즈빌에서 중요한 질문을 던지고, 그 질문을 실제 변화로 만드는 엔지니어로 성장하고 싶습니다.