AI 에이전트에게 일을 나누기 전에 정할 것들

세 에이전트가 같은 파일을 고친다면

API 오류를 수정하는 일을 세 에이전트에게 맡겼다고 해 볼게요. 한쪽은 응답 형식을 고치고, 다른 쪽은 예외 처리를 바꾸고, 마지막은 테스트를 추가해요. 작업 이름은 다르지만 셋 다 같은 컨트롤러를 수정한다면 결과를 합치는 순간 충돌할 수 있어요.

멀티 에이전트는 여러 에이전트에 작업을 나누는 방식이에요. 동시에 실행할 수 있다는 장점이 있지만, 각각의 결과를 검토하고 합치는 일도 생겨요. 작업을 많이 나눴다는 사실만으로 시간이 줄었다고 말할 수는 없어요.

AGS의 coordinate-subagents는 작업이 복잡하다는 이유만으로 위임하지 않도록 해요. 사용자가 위임을 요청했거나, 따로 실행할 실익을 확인했을 때 위임하도록 기준을 둬요. 이 글에서는 그 실익을 판단할 때 무엇을 확인하는지 살펴봐요.

독립적으로 끝낼 수 있는 일인지 먼저 보기

AGS가 제시하는 조건에는 독립적인 결과와 완료 기준, 실제 대기 시간의 감소, 제한된 설명만으로 충분한 맥락, 겹치지 않는 수정 담당, 전달·검토·통합 비용이 있어요. 단순히 파일이 많거나 단계가 많다는 것은 충분한 근거가 아니에요.

처음 예시에서는 응답 형식을 결정하기 전까지 예외 처리와 테스트를 확정하기 어려울 수 있어요. 세 작업이 순서대로 의존한다면 동시에 시작해도 뒤쪽 에이전트는 추측으로 진행하거나 기다려야 해요. 이런 경우에는 공통 응답 형식을 먼저 정한 뒤 독립적인 부분만 나누는 편이 합리적이에요.

반대로 수정 대상의 의존성을 조사하는 일과 이미 정해진 API의 오류 응답 테스트를 검토하는 일은 동시에 진행할 여지가 있어요. 중요한 것은 역할 이름보다 입력이 준비됐는지, 다른 작업의 중간 결과 없이 완료할 수 있는지예요.

파일을 수정할 담당자는 한 명으로 정하기

공유 작업 공간에서는 서로 다른 대화에서 실행하더라도 같은 파일을 볼 수 있어요. 에이전트가 분리됐다는 사실과 파일 변경이 분리됐다는 사실은 같지 않아요. AGS는 공유 파일이나 외부 상태마다 수정 담당자를 하나로 정하도록 해요.

다음은 API 수정 작업에 적용해 볼 수 있는 예시예요. AGS의 고정된 역할 구성이나 자동 배분 결과는 아니에요.

역할을 이렇게 적으면 같은 파일을 두 사람이 동시에 수정하는 일을 줄일 수 있어요. 다른 담당 영역에서 문제가 발견되면 조정한 뒤 소유권을 옮기거나 원래 담당자에게 수정을 요청해요. 각자 선의로 고친 뒤 나중에 합치는 방식은 누가 어떤 상태를 기준으로 작업했는지 추적하기 어려워요.

짧게 전달하되 필요한 조건은 빼지 않기

“테스트를 봐 주세요”라는 요청만으로는 충분하지 않아요. 어떤 동작을 기대하고, 무엇을 바꾸면 안 되며, 결과를 어떤 근거로 제출해야 하는지 빠져 있어요. 반대로 전체 대화를 복사하면 관련 없는 결정이나 이미 끝난 시도까지 전달하게 돼요.

AGS의 위임 지침은 목표, 담당 범위, 제외 사항, 입력, 권한, 기대 결과, 완료·검증 기준을 포함하도록 해요. 이를테면 “오류 응답의 HTTP 상태가 요구사항과 맞는지 최종 diff와 테스트로 확인하고, 코드는 수정하지 말고 재현 가능한 문제를 전달해 주세요”처럼 요청할 수 있어요.

이 정도로 충분한지는 작업마다 달라요. 과거 결정의 배경이 없으면 정확히 판단할 수 없는 일이라면 그 근거도 전달해야 해요. 맥락을 적게 주는 것 자체가 목표는 아니에요. 맡긴 일을 정확하게 끝낼 수 있는 범위로 줄이는 것이 목표예요.

병렬 구현과 독립 검토를 구분하기

구현을 여러 사람이 나누는 이유는 작업을 동시에 진행할 수 있기 때문이에요. 독립 검토의 목적은 작성자가 놓친 문제를 다른 관점에서 찾는 데 있어요. 그래서 배포처럼 실패 영향이 큰 작업에 검토자를 두는 판단이 곧 구현도 여러 에이전트에게 나눠야 한다는 뜻은 아니에요.

AGS는 고위험 변경의 감사자를 구현자와 분리하고, 요구사항과 최종 변경, 검증 근거를 직접 보도록 해요. 구현 담당자의 “문제없음”이라는 요약만 읽는 것으로는 충분하지 않아요. 감사 뒤 대상이 바뀌면 영향받는 부분을 다시 확인해야 해요.

별도 에이전트라는 이름만으로 검토의 독립성이 완성되는 것도 아니에요. 작성자의 결론을 먼저 강하게 전달하면 같은 결론을 반복할 수 있어요. 어떤 자료를 전달했고 실제로 어떤 부분을 확인했는지까지 봐야 해요. AGS의 역할 분리는 이런 검토를 수행할 절차를 마련하지만, 모델의 모든 판단 편향을 제거했다고 볼 수는 없어요.

통합은 조정 담당자의 작업으로 남아요

여러 결과를 받았다고 전체 작업이 끝난 것은 아니에요. 각각 다른 코드 상태를 대상으로 검토했을 수 있고, 한쪽의 수정이 다른 쪽의 테스트를 무효로 만들 수도 있어요. 최종 통합 상태에서 요구사항을 다시 확인해야 해요.

AGS의 완료 규칙도 각 담당의 결과를 회수하고, 수행한 검증이 실제로 통과했는지 확인하며, 관련 없는 사용자 변경을 덮어쓰지 않고 통합하도록 해요. 마지막 보고에는 실행한 검사와 남은 제약을 구분해요.

이 글에서 확인한 것은 공개된 위임·통합 지침이에요. 에이전트 수에 따른 속도나 품질의 우열을 입증한 실험은 아니에요. 실제 적용에서는 같은 파일의 중복 수정, 빠진 입력, 통합 후 테스트 실패, 검토 대상 변경 같은 사례로 절차가 작동하는지 확인할 수 있어요.

다음 글과 소스

마지막 글에서는 다른 AI의 메시지가 사용자 승인이 아닌 이유를 다뤄요. 일을 나눈 뒤에는 결과를 전달해야 하는데, 메시지가 도착했다는 사실과 그 메시지를 실행할 권한이 있다는 사실도 나눠야 해요.

• 위임의 적용 조건과 완료 규칙
• 독립 작업, 단일 수정 담당, 통합과 감사 기준