AI 에이전트 여러 개를 협업시키며 배운 것 — 역할 분리와 교차검증

왜 하나의 AI가 아니라 여러 개였나

처음 이 프로젝트를 시작할 때 가장 자연스러운 선택은 AI 하나에게 "자동매매 시스템을 만들어줘"라고 맡기는 것이었다. 실제로 그렇게 시작했다. 그런데 얼마 안 가 한계가 보였다. 같은 AI가 코드를 짜고, 그 코드를 스스로 검토하고, 그 검토 결과까지 스스로 판단하는 구조에서는 한 번 잘못 든 확신이 끝까지 유지되는 경향이 있었다.

사람이 코드를 짤 때도 비슷한 문제가 있다. 자기가 짠 코드의 버그는 자기 눈에 잘 안 보인다. 그래서 코드 리뷰 문화가 존재한다. AI도 마찬가지였다. 하나의 대화 맥락 안에서 "이 로직이 맞나?"를 스스로에게 물으면, 이미 그 로직을 만든 전제 자체를 의심하기가 구조적으로 어려웠다.

그래서 역할을 나누기로 했다. 기획을 맡는 AI, 개발을 맡는 AI, 검증을 맡는 AI를 분리하고, 서로가 서로의 결과물을 처음 보는 입장에서 검토하게 만들었다. 이 글은 그 과정에서 실제로 배운 것들을 정리한 것이다. 구체적인 도구나 내부 구성은 밝히지 않지만, 역할을 나누는 접근 자체는 재현 가능한 형태로 풀어본다.

역할을 어떻게 나눴나

세 가지 축으로 나눴다.

기획. 무엇을 만들지, 어떤 순서로 만들지, 이번 단계에서 어디까지가 범위인지를 정하는 역할이다. 코드를 직접 짜지 않는다. "이번엔 리스크 관리 규칙만 다루고 실행 로직은 건드리지 않는다"처럼 범위를 명확히 긋는 게 이 역할의 핵심 산출물이었다.

개발. 기획이 정한 범위 안에서 실제로 코드를 짠다. 여기서 중요했던 건 개발 역할에게 "왜 이렇게 짰는지"를 남기게 한 것이다. 코드만 던지면 검증 역할이 의도를 추측해야 하는데, 그러면 검증이 겉핥기가 되기 쉬웠다.

검증. 개발이 만든 결과물을 처음 보는 입장에서 검토한다. 여기서 결정적이었던 건 검증 역할에게 개발 과정의 맥락을 최대한 적게 준 것이다. 맥락을 많이 주면 "왜 이렇게 짰는지" 이해는 빨라지지만, 그만큼 개발의 전제를 그대로 받아들이는 경향도 강해졌다. 맥락을 의도적으로 줄이니 오히려 "이 전제 자체가 맞나?" 같은 질문이 더 잘 나왔다.

역할 분리만으로는 부족했던 지점

역할을 나눠도 곧바로 문제가 사라지지는 않았다. 처음엔 검증 역할이 "코드가 의도대로 동작하는가"만 확인했는데, 이건 개발 역할이 짠 로직의 틀 안에서만 도는 검증이라 개발 단계에서 이미 놓친 전제는 그대로 통과됐다. 예를 들어 손절 로직이 코드로는 정확히 구현됐지만, 애초에 손절 판단과 전략 신호 생성 로직이 한 함수에 뒤섞여 있어서 전략에 버그가 생기면 손절도 같이 무력화되는 구조적 문제 같은 것들이다. "구현이 맞는가"와 "설계가 맞는가"는 다른 질문이라는 걸 이때 배웠다.

그래서 검증 역할에게 준 질문을 바꿨다. "이 코드가 의도대로 동작하는가"에서 "이 설계에서 한 요소가 실패하면 다른 요소도 함께 무너지는 지점이 있는가"로. 질문을 바꾸자 그제야 구조적인 문제들이 걸러지기 시작했다.

교차검증에서 실제로 걸러진 문제들의 유형

구체적인 코드나 실제 발견 내용은 공개 범위 밖이지만, 걸러진 문제들을 유형으로 정리하면 이렇다.

1. 암묵적 전제의 불일치. 기획이 "이 부분은 항상 최신 데이터만 들어온다"고 가정했지만, 개발 단계에서는 그 가정이 코드로 강제되지 않은 경우. 검증 역할이 "이 가정이 코드 어디서 보장되는가"를 물으면서 드러났다.
2. 경계 조건 누락. 정상적인 흐름에서는 잘 동작하지만, 데이터가 하나도 없거나 극단적인 값이 들어왔을 때의 처리가 빠진 경우. 개발 단계에서 정상 케이스 위주로 사고하다 보니 자주 놓쳤다.
3. 책임 범위의 중복 또는 공백. 두 역할이 서로 "상대가 처리할 거라고 생각한" 부분이 실제로는 아무도 처리하지 않고 있던 경우. 역할을 나누면서 새로 생긴 유형의 문제였다.

세 번째 유형은 역할을 나누기 전에는 아예 존재하지 않았던 문제라는 점이 흥미로웠다. 역할 분리가 기존 문제를 줄이는 동시에 새로운 종류의 문제(경계에서 책임이 비는 것)를 만들어낼 수 있다는 걸 직접 겪고서야 이해했다.

배운 것 정리

같은 AI에게 만들기와 검토하기를 동시에 맡기면, 검토는 "확인"이 아니라 "재확인"에 그치기 쉽다. 맥락을 공유한 상태에서는 원래 전제를 의심하는 질문 자체가 잘 나오지 않는다.

역할을 나누는 것보다 중요한 건 각 역할에게 "무엇을 물을지"를 명확히 정하는 것이다. 검증 역할에게 "맞는지 확인해줘"라고만 하면 구현 확인 수준에 머문다. "이 설계가 무너지는 지점이 있는가"처럼 질문의 층위를 설계·구조 쪽으로 올려야 더 깊은 문제가 걸러졌다.

역할을 나누면 경계에서 책임이 비는 새로운 문제가 생긴다. 이건 역할 분리의 부작용이 아니라 역할 분리를 하는 이상 반드시 별도로 관리해야 하는 지점이다. "이 부분은 누구 책임인가"를 역할 정의 단계에서부터 명시적으로 정리해두는 게 나중에 훨씬 덜 아프다.

오늘의 정리

1. 하나의 AI가 만들고 스스로 검토하는 구조는 이미 세운 전제를 다시 의심하기 어렵다는 구조적 한계가 있어, 기획·개발·검증 역할을 분리했다.
2. 검증 역할에게 "구현이 의도대로 동작하는가"가 아니라 "설계가 무너지는 지점이 있는가"를 묻도록 질문의 층위를 바꾸자 더 깊은 문제가 걸러졌다.
3. 역할을 나누는 것 자체가 "책임이 비는 경계"라는 새로운 문제를 만들 수 있어서, 이건 역할 분리와 별도로 관리해야 하는 지점이다.

이번 글은 코드보다 협업 구조에 대한 이야기였다. 다음 글에서는 다시 실무로 돌아와 다른 개념을 다뤄볼 예정이다.

이 글은 익명의 1인 운영자가 AI 에이전트 조직을 활용해 자동매매 시스템을 구축한 실제 경험을 바탕으로 하되, 구체적인 도구·내부 구성·실제 발견 사례의 세부 내용은 특정 가능성을 배제하기 위해 유형화해 작성했습니다. 이 글은 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 수익을 보장하지 않으며, 투자 손실에 대한 책임은 투자자 본인에게 있습니다.