업무 프로그램을 만들 때 Claude Code 서브에이전트와 에이전트 팀을 쓰는 곳

Claude Code에는 일을 다른 Claude에게 나눠 맡기는 기능이 두 가지 있다. 서브에이전트는 범위를 정해 일을 맡기고 결과만 받는 조수이고, 에이전트 팀은 여러 팀원이 각자 조사한 것을 서로 대조하고 반박하는 팀이다. 처음에는 이 정도로 구분하면 충분하다.

나는 Claude Code로 업무 프로그램 시제품을 만들었다. 만드는 과정은 비개발자가 AI로 업무 프로그램 시제품을 만드는 법에 정리했다. 이 글은 그때 겪은 일 네 가지를 예로, 어떤 일을 서브에이전트나 에이전트 팀에 맡기면 되는지 정리한 것이다. 에이전트 팀은 그때 쓰지 않았고, 이 글에서는 쓰는 방법만 안내한다.

이 글의 기능은 모두 Claude Code에서 쓴다. Claude 채팅창이나 ChatGPT에서는 되지 않는다. 채팅, Cowork, Claude Code가 각각 어떤 일에 맞는지는 채팅과 일 맡기기와 코딩 도구를 고르는 기준에 정리했다.

여러 화면에 걸친 곳을 찾을 때는 서브에이전트

시제품에서 저장 버튼을 누를 때마다 다른 메뉴로 넘어가는 불편이 있었다. 같은 문제가 다른 화면에도 있는지 확인해 달라고 하자, AI는 화면이 넘어가는 곳 15군데를 찾아 12군데는 문제가 없다고 보고한 뒤 3군데를 고쳤다.

이런 찾기는 서브에이전트에게 따로 시키면 좋다. 15군데를 찾느라 읽은 파일 내용은 서브에이전트 쪽에 남고, 내 대화에는 결과 표만 돌아온다. Claude Code를 오래 쓰면 앞에서 정한 내용이 흐려지는데, 찾느라 읽은 내용이 대화를 채우는 것이 원인 중 하나다.

서브에이전트로 버튼을 누른 뒤
다른 메뉴로 넘어가는 곳을
전부 찾아줘.
고치지는 말고
화면, 버튼, 넘어가는 곳을
표로만 정리해줘.

찾기와 고치기를 나눠서 시킨다. 표를 먼저 보면 어디까지 바뀌는지 알 수 있고, 고칠 곳만 골라 다음 요청을 한다.

표에서 접수 화면이랑 발송 화면만
저장 뒤 그 자리에 머물게 고쳐줘.

넘기기 전 점검은 서브에이전트 여럿에게 동시에

외주 업체에 시제품을 압축 파일로 넘기기 전에 파일을 줄이다가, 데이터 파일 하나가 빠진 적이 있다. 주문은 남아 있어서 겉보기에는 멀쩡했지만 발송 기록과 처리 기록이 비어 있었다. 따로 열어 보지 않았다면 빈 발송 서류가 나오는 시제품을 넘길 뻔했다.

넘기기 전 점검은 항목끼리 서로 기다릴 필요가 없다. 이럴 때는 서브에이전트 여러 개에 나눠서 동시에 시킨다.

업체에 넘길 압축본을
서브에이전트 셋으로 나눠서
점검해줘.
- 데이터가 빠진 게 없는지
- 실행 파일로 잘 열리는지
- 기능정리서가 화면과 맞는지
고치지는 말고,
직접 열어 본 것과 파일만 읽고
판단한 것을 나눠서 알려줘.

직접 확인한 것과 짐작한 것을 나눠 달라고 하면 결과를 믿어도 되는 곳과 내가 다시 볼 곳이 구분된다. 반대로 앞 결과를 보고 다음을 정해야 하는 일은 나누지 않고 순서대로 시킨다.

같은 실수를 막으려면 점검용 서브에이전트를 만들어 둔다

시제품은 처리 단계에서 물품을 쓸 때 재고를 한 번 빼고, 발송할 때 한 번 더 뺐다. 실제로 쓴 양은 0.7인데 1.7이 빠졌다. “재고는 처리 단계에서 쓸 때만 뺀다”로 규칙을 정한 뒤로 숫자가 맞았다.

문제는 다음 수정이다. 화면을 고치다가 이 규칙이 다시 깨질 수 있다. 수정할 때마다 같은 점검을 설명하고 있다면 점검용 서브에이전트로 만들어 둔다.

재고 규칙 점검하는
서브에이전트 만들어줘.
재고가 줄어드는 곳이
처리 단계 한 곳뿐인지
확인하는 역할이야.
읽기만 하고 고치지는 못하게.

다음부터는 수정한 뒤에 이름을 넣어 부른다. 이름은 만들 때 Claude Code가 알려 준다.

재고 점검 서브에이전트로
방금 고친 거 확인해줘

점검용은 읽기만 하게 만든다. 지시문에 “고치지 마”라고 쓰는 것과 고치는 도구를 아예 주지 않는 것은 다르다. 만든 뒤 “읽기 전용으로 만들었어?“라고 한 번 확인한다. 처음 만든 서브에이전트를 못 찾으면 Claude Code를 껐다 켠다.

여러 입장에서 봐야 하는 검토는 에이전트 팀

디자인 안을 여러 개 받았을 때, 처음 일곱 안은 색과 카드 모양만 다르고 골격은 같았다. 접수 화면은 다 만든 뒤에야 “한 주문에 제품이 여러 개일 수 있다”는 문제가 드러났다. 이런 문제는 만들기 전에 여러 입장에서 따져 봐야 드러난다.

에이전트 팀은 이럴 때 쓴다. 개발, 디자인, 실제 쓰는 사람처럼 입장을 나눠 맡기고 서로의 의견을 반박하게 한다. 서브에이전트는 나에게만 보고하지만, 팀원은 팀원끼리 직접 의견을 주고받는다.

접수 화면을 만들기 전에
팀원 3명에게 검토받고 싶어.
- 개발: 데이터 구조가 나중에
  안 바뀌어도 되는지
- 디자인: 화면 배치와 입력 순서
- 현장 담당자: 실제 주문을 넣을 때
  불편한 곳
서로 의견을 반박해 보고,
합의한 것과 의견이 갈린 것을
나눠서 정리해줘.
코드는 고치지 마.

의견이 갈린 것도 이유와 함께 남기게 한다. 억지로 합의하게 하면 확인하지 않은 생각이 결론처럼 보인다. 팀원은 내가 앞에서 나눈 대화를 모르니, 무엇을 만드는 화면인지 한두 줄 같이 적어 준다.

팀원에게 화면을 동시에 만들게 하는 것은 권하지 않는다. 같은 파일을 둘이 고치면 나중에 고친 쪽이 덮어쓴다. 처음에는 이렇게 코드를 고치지 않는 검토부터 맡긴다. 보고서처럼 자료 모으기, 쓰기, 검토하기가 차례로 이어지는 일도 팀보다 한 사람이 순서대로 하는 편이 낫다.

에이전트 팀은 아직 실험 기능이라 켜야 쓸 수 있고, 터미널(명령어를 글자로 입력해 프로그램을 실행하는 창)에서 실행하는 Claude Code(CLI)에서만 된다. 데스크톱 앱에서는 쓸 수 없다. 켜려면 설정 파일(settings.json)이나 환경 변수에 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 을 넣고, 터미널에서 Claude Code를 새로 시작한다.

공식 문서

2026년 9월 Claude Code 공식 문서 기준이다. 이 기능들은 버전마다 메뉴와 명령이 바뀌어 왔다.

• 서브에이전트: code.claude.com/docs/en/sub-agents (새 창)
• 에이전트 팀: code.claude.com/docs/en/agent-teams (새 창)