어떤 문제였나
저는 GPTers에서 B2B 기업 교육 세일즈를 담당하고 있습니다. 리드 관리는 Linear의 [B2B] Sales Funnel 프로젝트로 하는데, 혼자 수십 개 리드를 굴리다 보면 꼭 이런 일이 생깁니다.
커피챗 제안 메일을 보내고 3주 넘게 회신 확인을 잊음
이슈 status가 실제 진행 상황과 어긋난 채 방치됨 (협상 단계가 아닌데 In Review에 있다든지)
"이번 주에 연락해야지" 하고 넘어간 리드가 그대로 증발
매주 손으로 보드를 훑는 것도 한계가 있고, 그렇다고 AI에게 "알아서 정리해줘" 하면 그럴듯하게 정리한 척만 하는 결과가 나옵니다. 그래서 이번에 로나(Rona) 실습으로 이 업무를 검증 가능한 루프로 만들어봤습니다.
핵심 질문은 이것이었습니다. "AI가 한 일을 어떻게 믿을 것인가?"
로나가 잡아준 5단계
로나 실습은 아래 5단계로 진행됐습니다.
루프로 만들 업무 고르기 — B2B 세일즈 리드 후속 관리로 확정. 반복되고, 증거가 남고, 놓치면 손해가 명확한 업무라서.
합격 기준 정하기 — 기계 판정 4개 + 사람 판정 1개로 채점표 확정. 일부러 뚫어보고 대리 지표 구멍 2곳을 조임.
루프 흐름 잡기 — 만들고(Generate)-검사하고(Test)-고치는(Repair) 리듬. 루프는 연락 리스트까지만, 실제 연락은 사람이.
만드는 역할과 판정 기준 나누기 — 만드는 쪽(Maker)과 판정하는 쪽을 분리하고 채점표를 잠금. 채점표는 사람만 수정.
검증 방식 정하고 실제로 한 바퀴 — 가벼운 검사부터 무거운 검사까지 배치하고 실제 이슈로 검증.
단계 이름만 보면 평범해 보이는데, 각 단계에서 로나가 강제한 원칙들이 이 루프의 진짜 알맹이였습니다.
원칙 1. 채점표는 잠그고, 사람만 고친다
가장 먼저 만든 건 루프 코드가 아니라 채점표(checker.md)였습니다. 이진(예/아니오)으로 판정 가능한 기준 4개:
C1. 지난 7일간 아무 업데이트 없는 이슈가 모두 priority=Urgent로 격상됐는가
C2. 코멘트에 특정 일자가 언급된 이슈는 그 날짜가 due date에 반영됐는가
C3. Urgent 격상 후 2일 안에 담당자 코멘트가 없으면 연락 리스트에 포함됐는가
C4. due date가 지난 지 1일 안에 코멘트가 없으면 연락 리스트에 포함됐는가
그리고 이 파일 맨 위에 이렇게 박았습니다.
이 파일은 불가침이다. Maker(갱신안을 만드는 쪽)는 이 파일을 읽을 수만 있고 수정할 수 없다. 기준 변경은 사람(광밤)만 한다.
AI가 자기 결과물을 통과시키려고 기준 자체를 슬쩍 바꾸는 걸 원천 차단하는 장치입니다. 시험 응시자가 채점 기준표를 고칠 수 있으면 그 시험은 무의미하니까요.
원칙 2. 만드는 AI와 채점하는 AI를 분리한다
status 판정(C5)은 이진 판정이 어렵습니다. "In Review = 코멘트에 실제 협상 사건이 있는 리드" 같은 기준은 결국 글을 읽고 해석해야 하니까요. 그래서 Maker와 별도의 심판(Judge)을 두고, 심판 프롬프트에 이 규칙을 넣었습니다.
Maker의 갱신안이 왜 맞는지에 대한 Maker 자신의 설명은 증거로 인정하지 않는다 (심판 매수 방지).
In Review 판정은 코멘트에서 협상 사건의 직접 증거 문장을 인용할 수 있을 때만 내린다.
"곧 될 것 같다", "분위기 좋다" 같은 감상은 증거가 아니다.
증거가 애매하면 낮은 단계로 판정하고 "사람 확인 필요"를 붙인다.
같은 AI라도 역할과 근거 자료를 분리하면, "만든 놈이 자기 답안을 채점하는" 구조를 피할 수 있습니다.
원칙 3. 만들자마자 일부러 뚫어본다
채점표를 만들고 바로 한 일은 일부러 채점표를 속이는 결과물을 만들어보는 것이었습니다. 굿하트의 법칙("지표가 목표가 되면 좋은 지표이기를 멈춘다")을 직접 재현해본 거죠.
정상 갱신안에서 연락하기 귀찮은 리드 하나를 연락 리스트에서 슬쩍 뺀 변형본을 만들어 검증 스크립트에 넣었습니다.
[C3] 대상 6건 · 통과 5 · 실패 1
FAIL EDU-XXXX — Urgent + 담당자 코멘트 35일 전인데 연락 리스트에 없음
판정: 불합격 (1건) — Repair 대상처음 설계한 채점표는 이 공격에 뚫렸습니다. 그래서 C3·C4 두 기준을 추가로 조였고(위 채점표의 "대리 지표 보강"이 그 흔적), 조인 뒤에는 같은 공격이 정확히 잡혔습니다. 뚫리는 걸 확인하고 조이는 과정 자체가 실습의 절반이었습니다.
이렇게 조립된 루프의 전체 구조는 이렇습니다.
실제 한 바퀴: 진짜 이슈 10건으로 검증
설계만 하고 끝나면 의미가 없어서, 실제 Linear 이슈 10건 스냅샷으로 루프를 한 바퀴 돌렸습니다.
Generate(Maker) — 갱신안 산출: Urgent 격상 3건, status 이동 3건, 오늘 연락할 리스트 8건 (드랍됐지만 불씨가 남은 리드, 계약 완료됐지만 재계약 시점인 리드 포함).
Test(Checker) — 검증 스크립트가 C1~C4 전체 통과 판정.
Judge(심판) — 이슈별로 증거 문장을 인용하며 판정:
이슈 | 현재 status | 판정 | 증거
K사 | In Review | In Progress | "커피챗 제안 메일 발송" — 협상 사건 아님
L사 | In Review | In Progress | "준비하던 세미나는 hold" — 협상 사건 아님
S사 | In Review | In Progress | "제안서 발송" — 정의표상 In Progress
R사 | In Review | 사람 확인 필요 | 협상 정황은 있으나 직접 증거로는 애매
법률사무소 | In Progress| 사람 확인 필요 | 진행 기록이 없어 증거 부족여기서 중요한 건 마지막 두 줄입니다. 심판이 억지로 판정하지 않고 "애매한 건 붙들지 않고 사람에게 넘긴다"는 정지 조건을 발동했습니다. 저는 이 2건만 보고 결정했고(하나는 유지, 하나는 드랍 처리), 승인 후 6건이 Linear에 반영됐습니다. 10건을 다 들여다보는 대신 2건만 판단하면 되는 구조가 된 겁니다.
사람 몫을 명확히 남겨두기
이 루프에서 AI가 절대 못 하게 막은 것들이 오히려 설계의 핵심입니다.
이슈에 코멘트 작성 금지 — 코멘트는 "사람이 실제로 연락했다"는 신호입니다. 루프가 코멘트를 쓰기 시작하면 C3·C4(연락이 실제로 나갔는지 감시)가 무력화됩니다.
실제 연락(메일·전화) 금지 — 루프는 "오늘 연락할 리스트"까지만. 연락은 사람이.
Linear 반영은 사람 승인 후에만 — 루프의 산출물은 어디까지나 '제안'.
C3·C4가 재밌는 지점인데, 이 기준은 AI가 아니라 저를 감시합니다. "Urgent로 격상해놓고 2일 안에 연락 안 했으면 다음 주 연락 리스트에 다시 올라온다" — 루프가 사람의 실행까지 물고 늘어지는 구조입니다.
마무리: 평일 매일 오전 9시 자동 실행
마지막으로 이 루프를 Claude Code의 클라우드 루틴(routine)으로 걸었습니다. 처음엔 주 1회(월요일)로 걸었는데, 곧 구조적인 문제를 발견했습니다. C3(격상 후 2일 내 연락)·C4(마감 경과 1일 내 연락)의 감시 창은 일 단위인데 검사가 주 단위면, 위반을 최대 5~6일 늦게 알게 됩니다. "연락 리마인드"가 아니라 "지난주에 연락 안 하셨네요" 사후 통보가 되는 거죠.
그래서 평일 매일 오전 9시 + 2단 리포트로 조정했습니다.
월요일 = 풀 루프: Generate→Test→Judge 전체를 돌리고 갱신안·심판 판정·연락 리스트를 Slack DM으로 보고
화~금 = 라이트 감시: C3·C4 위반과 마감 임박(D-1)만 검사. 위반이 있을 때만 DM, 없으면 침묵 — 매일 풀 리포트를 보내면 금방 안 읽게 되니까요
물론 어느 요일이든 루틴에게 반영 권한은 없고, 제가 승인해야 로컬에서 반영됩니다.
배운 것
AI 자동화의 병목은 생성이 아니라 검증이다. 갱신안 만드는 건 몇 분이면 됩니다. 이걸 믿을 수 있게 만드는 장치(잠긴 채점표, 분리된 심판, 뚫기 시험)가 작 업의 대부분이었습니다.
채점표를 먼저 잠그고 시작하라. 기준을 AI 손이 닿지 않는 곳에 두는 것만으로 "그럴듯한 척"의 상당수가 차단됩니다.
만든 직후 일부러 속여봐라. 뚫리는 채점표는 뚫린 다음에 고치면 됩니다. 실전에서 뚫리는 것보다 백배 낫습니다.
사람 몫을 지우지 말고 명시하라. 연락과 승인을 루프 밖에 남겨둔 덕분에, 오히려 루프 전체를 안심하고 자동화할 수 있었습니다.
리드 관리가 아니어도, "AI가 한 일을 어떻게 믿지?"가 고민되는 반복 업무라면 이 구조(잠긴 채점표 + Maker/심판 분리 + 뚫기 시험 + 사람 승인 게이트)를 그대로 가져다 쓸 수 있을 겁니다.
