얼마 전 새 업무 프로세스 하나를 추가했다.
우리는 프로젝트 진행시 아홉 단계 절차로 나눠 진행하고, 기획서 내용을 확정하는 단계가 있다. 여기에 새로운 방법을 추가한 것이다.
모든 문서 관리 및 작성은 앨리(메인 AI)가 한다. (TMI로 첨언하면 자료조사는 밥 우드워드가 진행한다) 기획서 작성시 기존에는 앨리가 작성한 후 검토까지 완료하고 나에게 보고한다. 물론 문서 검토 단계에서 gemini와 codex의 검수를 거쳐서 오탈자 및 비문 등을 잡아 문서의 완성도를 높이고 있다. 그런데 이번에 추가한 것은 각기 다른 역할을 맡은 세 사람에게 각자 문서 초안을 따로 보여주고, 본인의 페르소나에 맞는 관점으로 문서를 평가해 의견을 추가하기로 한 것이다.
결과는 예상보다 훨씬 더 좋았다 — 세 사람이 짚은 문제가 겹치지 않고 정확히 각기 다른 의견을 내놓은 것이다.
왜 여러 사람(agent)에게 나눠 맡겼나
지금까지 기획서는 앨리가 쓰고 앨리가 검토해서 나한테 올렸다. 문장 검수는 따로 받지만 내용을 보는 눈은 앨리 하나다. 쓴 사람과 본 사람이 같으니, 앨리가 놓친 것은 나한테 올라올 때까지 아무도 못 잡는다. 보고를 마친 뒤에 뒤늦게 오류가 드러나는 일이 반복됐다.
그래서 확정하기 전에 한 단계를 끼워 넣었다. 여덟 개 역할(기획자·UI/UX디자이너·그래픽디자이너·영화감독·카메라감독·개발자·마케터·데이터분석가)을 미리 정해 두고, 과제 성격에 맞는 세 명에서 네 명만 그때그때 불러 검토를 맡긴다.
한 사람에게 모든 관점을 다 맡기지 않고 역할마다 볼 곳을 셋씩만 정해 준다 — 기획자에게는 "단계 정의에 오류는 없나·실행 주체는 분명한가·성공 기준을 잴 수 있는가", 개발자에게는 "실제로 지켜질 절차인가·자동으로 강제할 수 있는데 규칙으로만 둔 곳은 없는가·유지보수 부담은 없는가" 같은 식이다.
관점을 너무 넓히면 같은 말을 하게 되는 경우가 있어 역할을 일부러 좁혀서 의견을 듣는다. 뭐...추후 이 부분도 실험을 거쳐 더 나은 방향으로 만들어볼 생각이다.
검토는 서로 다른 AI 서비스 두 개에 나눠 맡긴다(현재 우리는 claude, gemini, codex, grok를 구독하고 있고, 로컬 모델로 Ollama:8b도 설치해 사용중이다). 세 명이면 한쪽에 둘, 한쪽에 하나. 각자 정해진 관점으로만 지적하고, 타당한 지적을 가려 반영하는 일은 앨리가 담당한다. 반영한 의견은 같은 사람에게 한 번 더 보여주고, 새로 나오는 지적이 없으면 거기서 마무리한다.
새로 지어낸 방식은 아니다. 이렇게 여러 AI에 역할을 나눠 검토하고 토론시키는 것을 연구 쪽에서는 멀티 에이전트 토론(multi-agent debate)이라고 부른다. 여러 AI가 서로의 답을 두고 토론하면 정확도가 오르고 할루시네이션이 줄어든다는 연구가 있고, 하나의 AI는 한번 확신한 생각을 스스로는 잘 바꾸지 못한다는 관찰도 있다. 문서를 작성한 쪽이 검토까지 하면 오류가 발생하고, 발생한 오류에 대해 반복해서 놓치는 이유가 이것이다.
첫 시도 — 기획자·개발자·데이터분석가에게 맡겼다
이번 기획서 검토에는 기획자(경력 13년)·개발자(경력 15년)·데이터분석가 세 사람을 불렀다. 같은 문서를 세 사람에게 그대로 보여주고, 각자에게 정해 준 세 가지 관점만 보게 했다.
기획자는 성공 기준부터 짚었다. 문서에 "이 기획서 하나로 판단할 수 있다"는 문장이 있었는데, 이 문장이 걸렸다.
'판단할 수 있음'은 주관적 상태이며 측정이 불가능합니다.
개발자는 절차가 실제로 지켜질지를 봤다. 가벼운 정비 작업에까지 무거운 절차를 통째로 요구하는 대목을 두고 이렇게 적었다.
개발자가 절차를 무시하고 '경미한 변경'으로 억지 우회 판정할 원인이 됩니다.
데이터분석가는 근거의 크기를 문제 삼았다. 결론을 받치는 사례가 세 건뿐이라는 것이다.
단 3건의 과제 표본만으로 … 결론을 내리고 있습니다.
세 사람이 같은 문서를 읽었는데 겹치는 지적이 하나도 없었다. 기획자는 판단할 수 없는 문장을, 개발자는 지켜지지 않을 절차를, 데이터분석가는 얕은 근거를 짚어낸 것이다. 각자 정해 준 관점 그대로다.
반영 결과
타당한 지적 아홉 건을 그 자리에서 기획서에 반영했다. 다시 보여줬을 때 새로 나온 지적은 없었다.
가장 눈에 띄는 것은 개발자가 짚은 "억지 우회" 지적이었다. 이 지적을 받아들여, 정비 수준 작업에는 큰 규모 절차를 그대로 진행하지 않고 작업계획서 한 장으로 기획과 계획을 합칠 수 있는 짧은 경로를 새로 넣었다. 절차를 피해 갈 이유를 없앤 셈이다.
관점을 정해 주는 것부터
검토를 여러 사람에게 맡겨 본 적이 있다면 알겠지만, 그냥 "봐 주세요"라고 하면 다들 비슷한 것부터 본다. 이번에 확인한 것은 하나다. 무엇을 보라고 미리 정해 주면, 그 정한 만큼 서로 다른 것을 찾아낸다.