녹취가 쌓일수록 교재가 진화하는 구조 만들기
요즘 콜드콜이 재밌다.
예전보다 전화를 거는 데 부담이 줄기도 했지만, 가장 큰 이유는 담당자의 반응을 끌어낼 수 있는 WinWin 상품이 생겼기 때문이다. 영업하는 사람 입장에서 콜드콜이 어려운 이유는 단순히 모르는 사람에게 전화를 걸어야 해서만은 아니다. 전화를 받은 담당자가 짧은 시간 안에 “이 전화를 조금 더 들어볼 이유가 있겠다”라고 생각할 만한 이야기가 있어야 한다.
최근에는 그 역할을 해주는 상품이 생겼다. 실제로 콜드콜을 해보면 담당자들의 반응도 이전보다 긍정적이다. 자연스럽게 나도 전화를 거는 데 자신감이 생겼고, 여러 기업에 계속 전화하면서 조금씩 재미도 붙기 시작했다.
그래서 이 타이밍에 하나 만들어보기로 했다. 회사의 상품과 솔루션에 최적화된 콜드콜링 플레이북.
다만 인터넷에 있는 일반적인 콜드콜 방법론을 정리해서 교재를 만들 생각은 없다. 내가 실제로 잠재고객에게 전화한 녹취를 계속 축적하고, 통화에서 잘됐던 부분과 잘되지 않았던 부분을 분석하면서 플레이북 자체를 계속 수정하는 방식으로 만들어보려고 한다.
완성된 교재가 아니라, 계속 수정되는 교재
처음 생각한 방식은 단순했다.
콜드콜을 한다. → 통화 녹취를 저장한다. → 잘된 통화와 잘되지 않은 통화를 비교한다. → 그리고 다음 전화에서 바꿔본다.
예를 들어 이런 것들이다.
- 첫 20초 안에 어떤 이야기를 해야 담당자가 전화를 끊지 않는지
- 교육담당자에게 어떤 질문을 했을 때 대화가 이어지는지
- “이미 교육했습니다”, “계획 없습니다” 같은 답변이 나왔을 때 어떻게 대응하는지
- 자료 발송에서 끝나지 않고 다음 통화나 미팅으로 연결하려면 어떻게 해야 하는지
- 어떤 상품이 콜드콜의 Hook으로 잘 작동하는지
몇 번의 통화만으로 정답을 정하기보다 실제 통화 데이터가 쌓일 때마다 기존 내용을 다시 검토하는 방식이 더 맞다고 생각했다. 그래서 플레이북을 하나의 문서로 만들기보다 ‘교재가 진화하는 리포지토리’ 형태로 만들어보기로 했다.
VS Code + Codex로 만든 첫 번째 구조
작업은 VS Code에서 Codex를 활용해서 진행하고 있다. 내가 원하는 환경은 대략 이랬다.
- 콜드콜 녹취록을 계속 추가할 수 있어야 하고, 새 녹취가 들어오면 기존 통화와 비교해서 분석할 수 있어야 한다.
- STT로 만들어진 녹취에는 오타도 꽤 많기 때문에 상품명이나 HRD 용어에 맞게 잘못 인식된 단어를 교정하는 과정도 필요했다.
- 다만 원본 녹취 자체를 수정하면 안 된다.
- 실제로 내가 어떤 말을 했는지와, 나중에 분석해서 “이렇게 말하는 게 더 좋겠다”고 판단한 내용은 분리되어 있어야 하기 때문이다.
- 그리고 Codex가 매번 제멋대로 다른 기준으로 분석하지 않도록
AGENTS.md에 프로젝트의 목적과 분석 기준도 넣어둘 필요가 있었다.
이런 조건들을 이야기하면서 만든 첫 번째 프로토타입이 아래 구조다.
cold_calling_playbook/
│
├─ AGENTS.md
├─ README.md
├─ CHANGELOG.md
│
├─ 00_inbox/
│ └─ 신규로 넣은 미처리 녹취록
│
├─ 01_raw/
│ └─ 원본 녹취록.txt
│
├─ 02_clean/
│ └─ STT 교정 완료 녹취록.md
│
├─ 03_analysis/
│ ├─ calls/
│ │ └─ 통화별 분석.md
│ ├─ patterns/
│ │ ├─ opening_patterns.md
│ │ ├─ discovery_patterns.md
│ │ ├─ objection_patterns.md
│ │ ├─ closing_patterns.md
│ │ └─ failure_patterns.md
│ └─ call_index.csv
│
├─ 04_book/
│ ├─ README.md
│ ├─ 01_cold_calling_principles.md
│ ├─ 02_gatekeeper.md
│ ├─ 03_opening.md
│ ├─ 04_discovery.md
│ ├─ 05_objection_handling.md
│ ├─ 06_next_action.md
│ ├─ 07_hunet_solutions.md
│ ├─ 08_case_studies.md
│ └─ 09_scripts.md
│
├─ 05_knowledge/
│ ├─ hunet_products.md
│ ├─ hrd_glossary.md
│ ├─ stt_dictionary.md
│ ├─ customer_terms.md
│ └─ sales_taxonomy.md
│
├─ 06_evals/
│ ├─ call_scoring_rubric.md
│ ├─ book_quality_checklist.md
│ └─ regression_cases.md
│
├─ templates/
│ ├─ cleaned_transcript_template.md
│ ├─ call_analysis_template.md
│ └─ case_study_template.md
│
└─ scripts/
└─ 향후 자동화 스크립트
처음 보면 조금 복잡해 보이지만 흐름 자체는 단순하다.
녹취가 들어오고 → 원본을 보관하고 → STT를 정리하고 → 통화를 분석하고 → 필요한 내용만 플레이북에 반영한다.
원본 녹취와 교재를 분리한 이유
이 구조에서 가장 중요하게 생각한 부분은 01_raw과 02_clean을 나눈 것이다. STT 녹취를 보면 이름이나 회사명, HRD 용어가 이상하게 변환되는 경우가 꽤 많다. 이런 데이터를 그대로 분석하면 나중에 사례를 교재에 넣을 때 문제가 된다. 그래서 원본 파일은 그대로 보존하고, 별도의 정제 파일을 만든다.
여기서도 한 가지 원칙을 정했다. “통화 내용을 더 좋은 영업 멘트로 고치지 않는다.” STT가 잘못 인식한 내용만 바로잡는다. 내가 실제로 좋지 않은 표현을 사용했다면 그것도 그대로 남아 있어야 한다. 그래야 나중에 실패 사례로 분석할 수 있다.
실제 통화를 바로 교재에 넣지 않는 이유
녹취를 정리했다고 바로 플레이북을 수정하는 것도 아니다. 중간에 03_analysis라는 단계가 있다. 여기에서는 통화마다 Opening, Hook, 질문, 고객 반응, 거절 이유, 대응 방식, 마지막 CTA(Call to Action, 행동 유도) 등을 분석한다. 예를 들어 자료 발송에는 성공했지만 다음 연락 일정을 잡지 못했다면, 단순히 “자료 발송 성공”이라고 보기보다 그 이후 영업기회로 이어질 가능성을 따로 보는 식이다.
통화가 쌓이면 개별 사례뿐만 아니라 패턴도 볼 수 있다. opening_patterns.md에는 어떤 오프닝이 반응이 좋았는지 쌓이고, objection_patterns.md에는 “이미 하고 있습니다.”, “필요 없습니다.”, “올해 계획 없습니다.” 같은 답변에 어떻게 대응했는지를 모을 수 있다.
반대로 통화가 잘 풀리지 않았던 사례는 failure_patterns.md에 남긴다. 개인적으로는 성공한 통화만큼 실패한 통화가 플레이북을 만드는 데 중요하다고 생각한다.
AGENTS.md는 이 프로젝트의 작업 기준서
이 프로젝트에서 중요한 파일 중 하나가 AGENTS.md다. Codex가 이 폴더에서 작업할 때 어떤 원칙으로 움직여야 하는지를 적어두는 파일이다. 예를 들어 이런 내용들이 들어간다.
- 원본 녹취 파일은 수정하지 않는다.
- STT 교정은 실제 발화의 의미를 바꾸지 않는다.
- 하나의 사례만으로 콜드콜 원칙을 만들지 않는다.
- 자료 발송과 실제 영업기회는 구분해서 평가한다.
- 새로운 녹취가 들어와도 기존 플레이북 전체를 무조건 다시 작성하지 않는다.
- 기존 원칙을 강화하거나 반박할 만한 근거가 있을 때 플레이북을 수정한다.
결국 Codex에게 단순히 “이 녹취 분석해줘”라고 매번 설명하는 대신, 프로젝트 안에서 지켜야 할 방법을 미리 정의해두는 것이다.
아직은 프로토타입
현재 이 구조는 어디까지나 첫 번째 버전이다. 실제로 콜드콜 녹취를 계속 집어넣고 분석하다 보면 필요 없는 폴더가 생길 수도 있고, 반대로 새로운 분류가 필요해질 수도 있다. 플레이북의 목차도 마찬가지다.
지금은 오프닝, 게이트키퍼, 니즈 탐색, 반론 대응, 다음 행동, 상품별 접근법, 실제 사례, 스크립트 정도로 나눴지만 통화가 50건, 100건 쌓이면 전혀 다른 구조가 더 적합할 수도 있다. 그래서 처음부터 완벽한 구조를 만드는 데 시간을 많이 쓰지는 않으려고 한다. 일단 전화를 하고, 데이터를 넣고, 분석해보고, 다시 고치는 쪽을 택했다. 이 플레이북을 만드는 과정 자체도 하나의 실험이다.
앞으로 실제 콜드콜을 하면서 발견한 내용, 잘 먹혔던 멘트, 실패했던 접근, 플레이북이 어떻게 바뀌었는지를 계속 기록해볼 생각이다. 첫 번째 단계는 일단 콜드콜 경험이 사라지지 않고 계속 축적될 수 있는 구조를 만든 것이다. 이제 이 안에 실제 통화 데이터를 계속 넣어볼 차례다.