01 · 에이전트 수보다 의존관계를 먼저 본다
멀티에이전트는 여러 모델 실행이 협업하는 방식입니다. 이름을 기획자·개발자·리뷰어로 나누었다고 작업이 자동으로 병렬화되지는 않습니다. 화면이 아직 정해지지 않은 API 응답을 기다린다면 순서 의존성이 있습니다. 서로 같은 설정 파일을 수정한다면 충돌 비용이 생깁니다.
Anthropic의 2026년 8월 연구는 다양한 멀티에이전트 구성을 살피며 조율과 모니터링의 문제를 다룹니다. 실제 시스템의 상호작용을 살펴야 한다는 시사점은 있지만, 에이전트 수가 늘면 품질이 자동으로 좋아진다는 보장은 아닙니다. 다음 분업표는 Devin.KR의 학습용 제안입니다.
02 · 학습 기록 서비스의 세 가지 경계
작업 A는 기록 입력 API, 작업 B는 기록 목록 UI, 작업 C는 사용 시나리오와 접근성 점검으로 나눠 봅니다. 시작 전에 응답 필드, 오류 표현, 날짜 형식, 빈 목록 의미를 한 문서에 합의합니다. UI 담당은 이 계약의 고정 예시를 이용해 먼저 화면을 만들 수 있습니다.
공통 메뉴, 의존성 파일, 데이터베이스 마이그레이션에는 통합 담당을 지정합니다. 각 작업의 수정 경로와 읽기 전용 경로를 구분하면 같은 파일을 덮어쓰는 일을 줄일 수 있습니다. 파일별 담당만으로 부족할 때는 같은 API의 동작 변경도 공유 계약의 변경으로 취급하세요.
03 · 좋은 위임 요청에는 입력과 결과가 있다
“백엔드를 잘 만들어 줘” 대신 “기록 생성 API를 구현하되 빈 제목을 거부하고, 응답 예시와 단위 검증 결과를 제출해 줘”라고 씁니다. 시작 정보에는 현재 구조, 관련 파일, 완료 기준과 금지된 범위를 넣습니다. 결과에는 변경 파일, 테스트 근거, 남은 의존성을 요청합니다.
중간에 응답 형식을 바꿔야 한다면 구현부터 바꾸지 말고 변경안을 통합 담당에게 전달합니다. 승인된 계약 버전이 바뀌면 다른 작업자에게 알려 기존 모의 응답도 갱신합니다. 작업 중 발견한 추측은 확정 사항과 분리해 기록해야 잘못된 가정이 전체로 퍼지지 않습니다.
04 · 합치는 사람이 사용자 흐름을 검증한다
개별 검사가 통과해도 전체 흐름은 실패할 수 있습니다. API는 날짜를 UTC로 반환하고 UI는 현지 날짜 문자열을 기대할 수 있습니다. 통합 담당은 기록 입력부터 조회, 새로고침, 오류 수정까지 직접 이어서 확인합니다. 리뷰는 파일별 성공 보고를 모으는 것에서 끝나지 않습니다.
독립 리뷰에는 변경 의도와 완료 계약을 주되 작성자의 성공 판단을 그대로 정답으로 주지 않습니다. 발견한 문제는 재현 입력과 영향 범위를 포함해야 합니다. 서로 반대되는 제안이 나오면 다수결보다 계약과 실제 실행 결과를 기준으로 결정합니다.
05 · 병렬화가 이득인지 비교하기
연습에서는 동일한 작은 과제를 단일 실행과 세 작업 분담으로 각각 해 봅니다. 완료 시간뿐 아니라 중복 수정 횟수, 통합 실패, 사람이 개입한 횟수를 비교합니다. 자잘한 파일 하나를 고칠 때는 분업 준비 시간이 실제 수정 시간보다 클 수 있습니다.
결과 보고서에는 작업자가 얼마나 많았는지보다 어떤 경계를 독립적으로 만들었고 무엇을 함께 검증했는지 적어 보세요. 이는 서버 개발, 인프라 자동화, 로봇 시뮬레이터처럼 여러 구성 요소가 만나는 분야에 공통으로 적용할 수 있는 협업 훈련입니다.