AI에게 코드 리뷰를 시킬 때 「하나의 에이전트(Agent)에게 전부 체크하게 하는 것」을 그만두고, 여러 전문 에이전트에게 병렬로 분업시키는 구성으로 바꿨더니, 체감상 정밀도가 크게 향상되었습니다.

하지만 진짜 수확은 정밀도 향상 그 자체보다, 「사고를 병렬로 분리하는 것」 자체가 컨텍스트 효율(Context Efficiency)과 할루시네이션(Hallucination) 대책을 동시에 해결하고 있었다는 점을 깨달은 것이었습니다.

처음에는 하나의 서브 에이전트(Sub-agent)에게 14가지 관점(요건 정합성, 보안, DB/ORM, 테스트…)을 전부 체크하게 했습니다.

이렇게 하면 전문성이 낮은 지적만 돌아오거나, 중요한 관점을 그냥 지나치거나, 과장된 Critical(치명적 오류)이 양산되는 등 모든 것이 얕아집니다.

원인은 단순합니다. 하나의 컨텍스트(Context)에 관점을 너무 많이 집어넣고 있기 때문입니다. 프롬프트(Prompt)도 코드도 방대해져서, 후반부의 관점은 읽기 건너뛰게 되고 사고의 방향성도 정해지지 않습니다. 「전부 봐라」는 구조적으로 무리가 있다고 판단했습니다.

그래서 구조를 다음과 같이 바꿨습니다.

각 레이어(Layer)의 역할은 다음과 같습니다.

레이어 1: 전문 리뷰어 (병렬)

관점마다 전속 에이전트를 세워 병렬로 동작시킵니다. 각 에이전트에게는 「자신의 영역만 깊게 봐라. 나머지는 다른 리뷰어에게 맡겨라」라고 지시합니다. 이번에는 6명으로 설정했지만, 관점의 수는 프로젝트에 따라 다릅니다.

레이어 2: Aggregator (통합 역할)

6명분의 지적에는 중복이나 모순이 포함되어 있으므로, 별도의 AI가 이를 집약 및 정리하게 합니다. 여러 리뷰어가 동일한 부분을 지적했다는 사실을 「확도가 높은 시그널」로 명시하는 것이 포인트입니다.

레이어 3: Self-Critique (검증 역할)

Aggregator의 출력을 그대로 믿지 않고, 다시 별도의 AI가 「이것이 정말 타당한가? 사실인가?」를 재평가하게 합니다. 이를 통해 할루시네이션과 과잉 지적을 걸러냅니다.

병렬화하는 것은 전문 리뷰어뿐입니다. Aggregator와 Self-Critique는 전 단계의 결과를 받으므로 순차적으로 실행됩니다 (Claude Code에서는 한 메시지 내에 여러 Agent 호출을 나열하면 병렬 기동이 됩니다).

이 설계는 「분업하여 정밀도를 높이는 것」뿐만 아니라, 생성형 AI가 구조적으로 안고 있는 두 가지 문제를 동시에 해결하고 있다는 점을 깨달은 것이 운영하면서 얻은 가장 큰 발견이었습니다.

한 명의 AI에게 14가지 관점을 모두 보여주면, 프롬프트와 코드도 방대해져 컨텍스트를 다 써버립니다. 관점이 뒤에 있을수록 읽기 건너뛰게 되고, 코드베이스를 깊게 읽어들일 여유도 남지 않습니다. 「전부 봐라」고 말하면서 실상은 「넓고 얕게」 되어 있는 상태입니다.

병렬로 나누면, 각 에이전트는 자신의 관점에 필요한 정보만을 깊게 읽을 수 있습니다. 1인당 컨텍스트 부하는 줄어들었음에도 전체적으로 보이는 범위는 오히려 넓어집니다. 또한 에이전트마다 사고의 방향성이 「Security 전담」, 「Migration 전담」 등으로 강제되므로 전문성도 담보됩니다.

「병렬화 = 빨라진다」뿐만 아니라, 「병렬화 = 깊게 볼 수 있다」는 것이 본질이라고 생각합니다.

한 명의 AI가 내놓은 결론은 틀렸더라도 아무도 알아차릴 수 없습니다. 같은 AI에게 「자신의 출력을 체크해줘」라고 부탁해도, 출력 시의 편향(Bias)을 그대로 가져가서 동일한 오류를 옳다고 판정하기 쉽습니다. 자신의 답안을 스스로 채점하고 있는 것과 같습니다.

이 구조에서는,

• 6명이 독립적으로 출력한다 → 「한 사람만 말하는 지적」과 「복수가 말하는 지적」이 자연스럽게 분리된다.
• Self-Critique가 별도의 에이전트로서 검증한다 → 생성과 검증이 완전히 분리된다.

즉, 「자신의 출력을 스스로 체크하는 것의 한계」를 구조적으로 회피할 수 있습니다. 이것이 할루시네이션 감소의 본질이라고 생각합니다.

좋은 점만 있는 것은 아니며 비용도 발생합니다. 벽시계 시간(Wall-clock time)은 1.31.5배 (병렬이므로 그렇게 많이 늘어나지는 않음), 토큰(Token) 소비는 23배입니다. 병목은 토큰 소비량입니다.

중요한 변경에만 멀티 에이전트(Multi-agent) 리뷰를 적용하고, 가벼운 변경은 단독 리뷰로 끝내는 식의 구분 사용이 현실적입니다.

또한 영역에 따라 효과의 차이가 있습니다. 보안이나 마이그레이션 정합성처럼 관점이 명확한 영역에서는 크게 효과를 보지만, 비즈니스 로직 버그처럼 비즈니스 문맥 그 자체를 알아야 하는 영역에서는 AI만으로는 한계가 있어 인간의 리뷰가 필요했습니다.

정밀도가 올라가면서 가장 기뻤던 점은, 인간이 AI의 리뷰 결과를 신뢰할 수 있게 되었다는 것이었습니다.

단독 리뷰 시대에는 "이게 정말 맞나?"라고 의심하며 전부 직접 확인해야 했기에, AI를 사용하고 있음에도 작업량이 줄어들지 않았습니다. 지금은 "복수 리뷰어의 지적 + Self-Critique (자기 비판) 통과"된 결과물은 높은 확률로 신뢰할 수 있으므로, 인간은 판단과 의사결정에 집중할 수 있습니다. 리뷰 시간과 재작업(rework)도 명확하게 줄어들고 있습니다.

AI에게 무엇을 시킬 것인가보다, AI를 어떻게 조합할지를 설계하는 단계에 들어섰다는 것이 이번 경험을 통한 소감입니다. 한 명의 AI에게 무리하게 시키기보다, 여러 개의 AI를 병렬로 구동하여 역할을 나누는 것이 구조적으로 다양한 문제를 해결할 수 있습니다. "한 명의 AI로는 한계가 있다"고 느끼는 분이 있다면, 꼭 병렬 분할을 시도해 보시기 바랍니다.

주식회사 Cynthia에서는 실무 경험이 없는 엔지니어분들이나 학생 엔지니어 인턴을 채용하여 함께 일하고 있습니다.

※ Cynthia에서의 근무 모습은 이쪽에서 확인하실 수 있습니다:

Cynthia에는 연간 100명 정도의 실무 미경험자가 지원하여 기술 면접을 치릅니다. 그 경험을 통해, 실무 미경험자분들이 꼭 갖추었으면 하는 기술력(문법)을 이곳에서 소개해 나가겠습니다.