매주 비슷한 리서치 리포트를 만드는 분이라면 공감하실 거예요. 소스를 여러 개 펼쳐놓고, 하나씩 읽고, 종합하고, 수치가 맞는지 확인하고… 저는 이걸 그동안 AI 하나에게 통째로 "다 조사해서 정리해줘" 하고 맡겨왔어요. 결과는 그럴듯한데, 어딘가 판별과 검증이 헐거 운 느낌이 늘 남았죠.
이번에 멀티에이전트 오케스트레이션을 실제 제 업무에 붙여봤어요. 결론부터 말하면, 배운 건 "AI를 많이 붙이는 법"이 아니라 "언제 여럿을 쓰고, 언제 안 쓰는지"를 판단하는 감각이었어요. 그리고 그 과정을 다음 주에도 그대로 다시 쓸 수 있는 재사용 커맨드 하나로 남겼습니다.
AI 하나에 통째로 맡기던 리서치 — 뭐가 헐거웠나
제가 반복하는 일은 "교안 소재 심층 리포트"예요. 주제 하나를 잡고, 원문 여러 개랑 웹 자료를 조사해서, 팩트체크를 거쳐 하나의 리포트로 종합하는 작업이죠. 매번 주제만 바뀌고 방법은 똑같이 반복돼요.
그동안은 이렇게 시켰어요.
이 주제로 소스들 다 조사해서 리포트로 정 리해줘문제는, AI 하나가 "조사"부터 "종합"까지 한 흐름에서 다 하다 보니 자기가 조사한 걸 자기가 검증하게 된다는 거였어요. 틀린 수치가 섞여도 그냥 그럴듯하게 흘러가고, 나중에 원문을 다시 열어보면 "어? 이 숫자 원문이랑 다른데?" 하는 일이 생겼죠.
그래서 이번엔 역할을 나눠봤어요. 조사하는 AI 여럿, 종합하는 AI 하나, 검증하는 역할 따로.
첫 번째 배움 — 읽기는 여럿이 나눠도, 쓰기는 하나가
조사원 역할의 AI에게 요청문을 주는데, 딱 네 가지를 넣었어요: 무엇을 조사할지(목표), 어떤 모양으로 답할지(형식), 어디서 찾을지(출처), 어디까지만 할지(경계).
실제로 조사원 하나를 돌려보고, 그 결과를 반장 역할 AI 하나에게 종합시켰더니 재밌는 일이 생겼어요. 개별 조사원은 함정을 하나씩 따로 뽑아왔는데, 반장은 그걸 묶어서 "이 함정들의 근본 원인은 사실 하나"라는 걸 뽑아냈어요. 조사원 각자에겐 없던 통찰이었죠.
여기서 궁금해서 일부러 실험을 하나 했어요. 요청문에서 '형식'만 빼고 다시 돌려본 거예요. 그랬더니 조사원 출력이 매번 제각각 모양으로 나오고, 반장이 그걸 하나로 맞추느라 힘을 빼더라고요. "형식이 곧 바통"이라는 걸 눈으로 봤어요. 조사원 하나면 티가 안 나지만, 여럿이 제각각 넘기면 종합하는 쪽이 정리에만 시간을 다 쓰게 돼요.
두 번째 배움 — 소스가 6개라고 조사원 6명이 답은 아니다
제 소스는 6개였어요. 그래서 처음엔 "그럼 조사원 6명?" 했는데, 반장에게 3명으로 나눠보게 시켰더니 문제가 보였어요. 소스들이 개념적으로 겹치더라고요. 예를 들어 어떤 개념의 "정의"와 "실제 사례"가 다른 소스에 각각 있어서, 6명한테 시키면 세 명쯤이 거의 같은 걸 조사하게 돼요.
그래서 6개를 3층(이론 / 사례·방어 / 통제)으로 2개씩 묶어 조사원 3명으로 정했어요. 겹침이 층 경계 몇 군데로 압축돼서 관리가 쉬워지고, 낭비도 줄었죠.
이게 이번 실습에서 가장 크게 남은 감각이에요. "여럿이 더 똑똑한가"가 아니라 "이 일이 그 비용을 낼 만한가"를 먼저 묻는 것. 소스 하나에서 날짜 하나 확인하는 일이면 조사원 6명은 순수 낭비예요.
세 번째 배움 — '실행됐다'와 '맞다'는 다르다
가장 인상 깊었던 건 일부러 실패를 심어본 실험이에요. 조사 결과에 틀린 수치를 하나 조작해서 심고, 두 명의 반장에게 각각 넘겼어요.
- 반장 A에게는 그냥 "종합해줘"라고 했더니, 조작된 수치를 검산 없이 그대로 리포트에 인용했어요.
- 반장 B에게는 "앞 단계 수치는 원문에서 다시 확인해"라고 한 줄 넣었더니, 원문을 열어 대조해서 틀린 수치를 잡아내고 정정했어요. 심지어 제가 시키지도 않은 "이 수치는 이해관계 편향이 있으니 조건부로 읽어야 한다"까지 덧붙였고요.
결과물이 나왔다고 맞은 게 아니에요. "원문 재확인"이라는 한 줄이 틀린 정보가 최종 리포트로 새어 나가는 걸 막았어요. 이걸 눈으로 보고 나니, 검증 단계를 왜 조사한 AI와 분리해야 하는지 확 와닿았어요.
결과
무엇보다, 이 흐름 전체를 재사용 커맨드 하나로 박제했어요. 다음 주에 주제만 바뀌면 커맨드 한 줄로 조사원 배정부터 종합·검증·승인까지 같은 품질로 돌아가요. 안전장치도 넣었어요 — 한 번에 최대 3건만 처리하고 멈춰서 물어보고, 발행·삭제 같은 되돌리기 어려운 일 앞에서는 반드시 사람 승인을 받도록요.
솔직한 한계도 있어요. 이번엔 각 조각(조사원·반장·검증)을 미니로 맛보기만 했어서, "진짜 리포트 한 편을 통째로" 산출하는 실전은 다음 숙제로 남겼어요. 조각이 잘 도는 건 확인했으니, 이제 커맨드로 한 바퀴 완주해보면 업무에 진짜로 붙는 실감이 날 것 같아요.
AI 활용 팁!
이 방식은 읽을 소스가 여러 개인 반복 업무에 잘 맞아요. 경쟁사 모니터링, 시장 동향 조사, 사용자 피드백 분류처럼요. 반대로 소스 하나를 정해진 형식으로 요약만 하는 일이면, 멀티에이전트는 오히려 과설계예요 — 그냥 AI 하나에 시키는 게 빠르고 싸요.
판단 기준은 딱 네 가지로 봤어요: ① 읽을 소스가 둘 이상인가 ② 상황에 따라 갈리는 분기가 있나 ③ 주기적으로 반복되나 ④ 틀렸을 때 티가 나서 검증할 가치가 있나. 넷 다 "예"면 여럿을 쓸 만하고, 아 니면 하나로 충분해요.
바로 쓸 수 있는 프롬프트
내가 반복하는 [리서치 업무]를 멀티에이전트로 설계해줘.
먼저 이 업무가 정말 여럿을 쓸 만한지 4조건으로 판단해줘: ①읽을 소스가 둘 이상인가 ②'~에 따라' 분기가 2개 이상인가 ③주기적으로 반복되나 ④틀리면 티 나는 검증 가치가 있나.
통과하면: 조사원 여럿(소스별로 배정, 겹치면 담당 한 명 지정) + 반장 하나(최종 종합만) + 검증(조사한 AI와 분리, 수치는 원문에서 재확인)으로 나눠줘.
조사원 요청문에는 목표·형식·출처·경계 네 가지를 꼭 넣고, 한 번에 최대 3건만 처리 후 멈춰서 나에게 물어봐.[리서치 업무] 부분은 본인 상황에 맞게 바꾸세요.
