AI 교육 회사에서 교육 운영을 맡고 있습니다. 얼마 전 강사님이 교육 세션에서 쓰실 챗봇용 시스템 프롬프트를 보내주셨어요. 수강생의 업무를 단계별로 분해해주는, 몇 페이지 짜리 정교한 프롬프트였습니다. 제 역할은 이걸 검토하는 것이었는데요. 읽어보니… "잘 만든 것 같은데?" 이상의 판단이 서질 않더라고요. 정교한 프롬프트일수록 사람이 혼자 읽어서는 허점이 안 보입니다.
그래서 Claude Code에게 심사위원단을 꾸리게 했습니다. AI가 만든 산출물을 AI 15명이 검증한 이야기입니다.
검토를 맡기며 한 요청은 하나였습니다
강사님이 세션에 활용하실 프롬프트인데, 어떤 원리로 진행되는 프롬프트인지,
로직은 괜찮은건지 꼼꼼하게 검토해서 보고해. 보고는 쉬운 표현으로 why까지 설명해Claude Code는 이 요청을 받고 멀티에이전트 워크플로우로 15개의 에이전트를 4단계에 배치했습니다. 제가 15명을 지정한 게 아니라, "꼼꼼하게"를 실행 가능한 구조로 AI가 알아서 설계한 것이었어요.
심사위원 15명은 이렇게 구성됐습니다
관점 렌즈 4 → 실전 투입 2 → 반박 전담 8 → 종합 1, 총 15개 에이전트
1단계 — 관점이 다른 심사위원 4명 (동시 진행)
같은 프롬프트를 놓고 서로 다른 것을 봅니다: 프롬프트 구조 / 논리 완결성 / 교육 현장 적용성(1.5시간 세션에서 소화 가능한가) / 업무 자동화 방법론의 타당성. 한 명이 다 보게 하면 뭉뚱그린 총평이 나오는데, 관점을 쪼개니 지적이 구체적으로 나왔습니다.
2단계 — 실전 투입 2명
말로만 평가하면 감상평이 됩니다. 그래서 실제 업무 사례 2건(채용 프로세스, 월 급여 마감)을 가진 가상의 수강생이 됐다 치고 프롬프트를 처음부터 직접 실행하게 했어요. 어디서 막히는지, 제한 시간 안에 끝나긴 하는지를 기록합니다.
3단계 — 반박 전담 8명 (적대 검증)
앞 단계에서 나온 심각한 지적 8건에 대해, 지적마다 한 명씩 붙어서 "그 지적, 정말 타당해? 반박해봐"를 시켰습니다. AI는 그럴듯한 비판을 지어낼 수도 있기 때문에, 반박을 통과하고 살아남은 지적만 채택합니다. 이 단계가 이번 구조의 핵심이었어요.
4단계 — 종합 1명
전체 결과를 모아 최종 판정을 내립니다.
판정: 조건부 사용 가능 — 그리고 반전
판정은 조건부 사용 가능. 로직은 견고했고, 문제는 '누가 언제 쓰느냐'였다
결과가 재미있었습니다. 프롬프트의 로직 자체는 견고했어요. 심사단도 설계 사상은 오히려 칭찬했습니다. 문제는 완성도가 아니라 "누가, 언제 쓰느냐"였습니다.
- 업무 하나를 분해할 때 항목 23개를 채우게 하는 밀도 → 컨설턴트에겐 좋지만, 1.5시간짜리 비개발자 세션에는 과중
- 영어 전문용어가 도입부에 몰려 있어 초보 수강생이 첫 5분에 이탈할 위험
- 판단 규칙이 정해지지 않은 업무를 만나면, AI가 규칙을 그럴듯하게 지어낼 수 있는 구멍
그래서 "이대로 쓰지 말고 이렇게 바꾸자"는 필수 개선 3건이 나왔습니다.
- 수강생이 직접 쓰는 대신 강사가 뒤에서 돌리는 엔진으로 (수강생에게는 쉬운 한글 워크시트 제공)
- 산출 범위 축소 — 항목 23개 → 핵심 6개
- "모르는 규칙은 지어내지 말고 '미정'으로 남겨라"를 프롬프트에 명문화 (환각 방지 가드)
특히 실전 투입조가 찾아낸 게 컸습니다. 급여 마감 시뮬레이션에서 "판정 기준이 담당자 머릿속에만 있다"는 실제 병목이 그대로 드러났거든요. 읽기만 하는 리뷰로는 절대 못 찾는 부분이었어요.
혼자 검토 vs 15-agent 검증
혼자 읽는 검토와 15개 에이전트 검증의 차이
구분 혼자 검토 15-agent 검증
──────────────────────────────────────────────────────
관점 내 관점 1개 렌즈 4 + 실행 2 + 반박 8 + 종합 1
근거 "좋아 보인다" 감상 실행 시뮬레이션 증거
지적 신뢰도 검증 없음 반박을 통과한 지적만 채택
결론 애매한 OK 조건부 판정 + 필수 개선 3건이 검토 결과를 근거로 강사님과 "챗봇 형태로 바꿔 진행하 자"는 방향을 잡았고, 개선안은 제작에 반영하도록 전달됐습니다.
AI 활용 팁!
- AI가 만든 산출물(프롬프트·기획서·제안서)을 다른 AI에게 "잘 됐는지 봐줘"라고 뭉뚱그려 시키면 대부분 칭찬만 돌아옵니다. 역할을 쪼개고, 실제로 실행시키고, 지적에는 반박을 붙이세요.
- "잘 만든 것"과 "지금 우리 상황에 맞는 것"은 다릅니다. 검증 관점에 반드시 대상·시간·환경 적합성을 한 자리 넣으세요.
- 저는 Claude Code의 워크플로우 기능(구독 요금 안에서 동작)을 썼지만, 일반 챗봇에서도 아래 프롬프트로 축소판을 돌릴 수 있습니다.
바로 쓸 수 있는 프롬프트
아래 [산출물]을 검증해줘.
1) 서로 다른 관점 4개([구조] / [논리] / [실사용 환경 적합성] / [방법론])로 각각 분석해줘.
2) 실제 사용 상황 2가지를 가정해서 처음부터 직접 실행해보고, 막히는 지점을 기록해줘.
3) 심각한 지적에는 각각 "이 지적이 정말 타당한가"를 반박하는 검증을 거치고, 살아남은 지적만 최종 보고에 담아줘.
4) 최종 판정을 그대로 사용 / 조건부 사용 / 수정 필요 중 하나로 내리고, 조건부라면 필수 개선을 우선순위로 정리해줘.
[대괄호]는 본인 산출물에 맞게 바꿔서 쓰세요.
