클로드 코드 서브 에이전트를 써보며 적어둔 작업 메모
최근 클로드 코드의 서브 에이전트 기능을 테스트하면서, 단일 도구를 쓰는 감각과 일을 위임하는 감각이 꽤 다르다는 점을 다시 느꼈습니다. 이번 글은 Playwright 테스트 작업을 기준으로, 어떤 식으로 역할을 나누면 편했는지 메모처럼 정리한 내용입니다. 제 판단으로는 이 기능의 핵심은 더 똑똑한 답변 하나보다, 작업을 서로 덜 얽히게 만드는 구조를 설계할 수 있느냐에 있습니다.
1. 서브 에이전트를 쓰면 달라지는 점
기존 AI 코딩 도구는 한 세션 안에서 계속 대화를 이어가는 방식이 많았습니다. 작은 작업에서는 편하지만, 범위가 넓어지면 문맥이 길어지고 응답 품질이 흔들릴 때가 있습니다. 서브 에이전트 방식은 이 문제를 조금 다르게 다룹니다. 메인 에이전트가 직접 모든 걸 처리하기보다, 일을 여러 단위로 나눠서 다른 에이전트에 맡기는 구조이기 때문입니다.
그래서 체감상 가장 큰 차이는 속도보다도 문맥 분리였습니다. 작업 단위를 나눠 두면 어떤 에이전트가 어떤 책임을 맡고 있는지 더 선명하게 관리할 수 있었습니다. 제가 보기에는 이 선명함이 있어야 실패 원인을 추적할 때도 사람이 다시 개입하기 쉬워집니다.
2. Planner, Generator, Healer로 나눈 흐름
이번 테스트에서는 역할을 세 가지로 나눠서 봤습니다. 먼저 Planner가 화면을 훑고 어떤 테스트 시나리오가 필요한지 정리합니다. 그다음 Generator가 각 시나리오를 코드로 바꾸고, 마지막으로 Healer가 실패 케이스를 다시 점검하는 식입니다.
이 구조가 편했던 이유는 처음부터 "전체를 한 번에 잘해라"라고 요구하지 않아도 됐기 때문입니다. 기획과 구현, 수정이 분리되면 실패 원인을 보기 쉬워지고, 어느 단계가 막히는지도 비교적 빨리 드러납니다.
실제로 Planner에게는 페이지 URL과 주요 사용자 시나리오만 전달하고, Generator에게는 Planner가 만든 시나리오 목록과 테스트 파일 경로 규칙만 넘기는 식으로 입력을 최소화했습니다. Healer는 npx playwright test --reporter=json의 실패 로그만 받아서 원인을 분류합니다. 이렇게 각 에이전트의 입출력을 명확하게 좁혀두면, 한 단계에서 문제가 생겨도 다른 단계로 오염이 번지지 않습니다. 기존에 하나의 긴 프롬프트로 모든 걸 처리하려 할 때보다, 디버깅에 드는 시간이 체감상 절반 이하로 줄었습니다.
3. 병렬 작업에서 실제로 편했던 지점
병렬 작업이 무조건 빠르다는 식으로 말하긴 어렵지만, 독립적인 테스트 그룹을 동시에 돌릴 수 있다는 점은 분명히 편했습니다. 특히 서로 의존성이 적은 시나리오를 먼저 분리해 두면 대기 시간이 줄고, 한쪽이 실패해도 전체 흐름이 멈추지 않는 장점이 있었습니다.
결국 중요한 건 병렬 실행 자체보다 그룹을 어떻게 나누느냐였습니다. 같은 데이터를 만지는 테스트를 한꺼번에 던지면 오히려 충돌이 생기기 쉬워서, 나눌 기준을 먼저 잡는 쪽이 더 중요했습니다.
4. 원스의 메모: 개발자는 점점 조율자에 가까워진다
이 기능을 써보면서 가장 크게 느낀 점은, 개발자의 역할이 직접 입력하는 사람에서 작업을 설계하고 조율하는 사람 쪽으로 조금씩 이동하고 있다는 점이었습니다. 코드를 한 줄씩 빨리 쓰는 능력만으로는 부족하고, 어떤 단위로 쪼개고 어떤 순서로 맡길지 정하는 감각이 더 중요해지고 있습니다.
그래서 이 글도 생산성 수치를 강조하는 글보다는, 실제로 어떤 식으로 나눠보니 편했는지 남겨두는 메모에 가깝습니다. 도구는 계속 바뀌겠지만, 역할 분리와 조율 감각은 꽤 오래 남는 기준처럼 보입니다.
정리하면, 클로드 코드 서브 에이전트의 핵심은 "더 많이 시킨다"보다 "더 잘 나눈다"에 가까워 보입니다. 작업을 잘게 쪼개고 책임을 분리할수록, 결과를 다시 검토하기도 쉬워집니다. 특히 테스트 자동화처럼 실패 원인을 재현해야 하는 작업에서는, 누가 어떤 단계에서 막혔는지 설명 가능하게 남기는 구조가 생각보다 큰 차이를 만들었습니다.
댓글
댓글 쓰기