소개
스터디 3주차에서 Claude의 서브에이전트와 에이전트 팀에 대해 배우고 직접 실습했다.
이번에는 단순히 배운 내용을 다시 따라 해보는 대신, 실제 회사 업무에 적용해보기로 했다.
마침 회사에서 공장 설비 매뉴얼을 준비하는 프로젝트를 진행하고 있었다.
기존 한글 자료는 외주 업체에서 사내 자료와 우리가 구매한 여러 설비 업체의 자료를 취합하고 정리하고 있었다. 나는 그 자료를 영문화하고 최종본을 검토하는 업무를 지원하고 있었다.
그런데 막상 자료를 들여다보니 단순한 번역 문제가 아니었다.
생각보다 어려웠던 문제들
용어 일관성
부서마다 사용하는 용어가 다름
작업자마다 표현이 다름
도면과 설비 사양서의 용어가 다른 경우도 있음
어느 하나가 틀렸다기보다 둘 다 맞지만 하나로 통일해야 하는 경우도 있음
전문용어의 문제
한국어를 영어로 바꾸는 과정에서도 전문 설비 용어에 대한 판단이 필요함
AI를 활용하더라도 내가 도메인을 충분히 이해하지 못하면 잘못된 답을 그럴듯하게 받아들일 수 있음
누구를 위한 영어인가?
영어 원어민이 읽는 문서가 아님
중동이나 유럽의 담당자들이 읽게 될 문서
미국식 영어냐 영국식 영어냐의 문제가 아니라, 누구나 이해하기 쉬운 일반적인 비즈니스 영어와 글로비쉬(Globish)의 관점이 필요함
일반 담당자가 읽는 부분과 전문 설비 담당자가 읽는 부분의 난이도도 달라야 함
자료 자체의 불일치
기본 로데이터부터 표현이 서로 다른 경우가 있음
설비가 여러 업체에서 각각 들어오다 보니 서로 다른 표현과 기준이 계속 추가됨
자료가 늘어날수록 혼동할 수 있는 경우의 수도 함께 늘어남
결국 이 업무는 단순히
"한국어를 영어로 번역해줘."
라고 AI에게 맡길 수 있는 일이 아니었다.
자료를 먼저 구조화하고, 무엇을 판단해야 하는지 정리한 뒤, 그 다음에 AI에게 어떤 역할을 맡길 것인지 결정해야 하는 일이었다.
진행 방법
1. 일단 에이전트부터 만들지 않고, 구조부터 잡았다
처음에는 Claude 하나와 대화하면서 전체적인 구조를 잡았다.
중요했던 것은 자료가 완벽하게 정리될 때까지 기다리지 않았다는 것이다.
오히려 현재 가지고 있는 자료를 최대한 모았다.
기존 한글 자료
설비 업체에서 받은 자료
도면
사양 자료
기존에 정리된 내용
아직 불일치가 남아 있는 로데이터
자료가 완벽하지 않더라도 일단 모으고, 그 안에서 구조를 잡기 시작했다.
특히 나중에 내용이 업데이트되거나 수정되었을 때 어디서 변경되었는지 역추적할 수 있는 구조가 중요했다.
그래서 첫 단계에서는 AI에게 많은 일을 시키기보다는,
"지금 내가 가진 자료로 무엇을 확인해야 하고, 어떤 구조로 정리해야 하는가?"
를 같이 보는 데 집중했다.
2. 여기서 3주차 복습 내용을 연결해봤다
그러다 문득 스터디에서 배웠던 구조가 생각났다.
① 혼자
→ ② 서브에이전트
→ ③ 에이전트 팀
그렇다면 지금 진행하고 있는 설비 매뉴얼 프로젝트도 이 순서대로 넘어가면 되는 것일까?
Claude에게 현재 상황을 설명하고 물어봤다.
"지금 내 설비 프로젝트에서 서브에이전트를 붙이고, 그 다음 에이전트 팀으로 넘어가는 게 맞을까?"
Claude의 답은 의외로 간단했다.
②는 지금이 맞고, ③은 아직이다.
3. 서브에이전트는 지금 붙여도 되는 단계였다
현재 작업 중 일부는 서로 독립적으로 수행할 수 있는 작업이었다.
예를 들어,
각각 독립적으로 분석할 수 있고
서로의 작업 결과에 의존하지 않으며
읽기 전용으로 처리할 수 있고
결과가 하나의 표처럼 명확하게 끝나는 작업
이었다.
이런 작업은 서브에이전트에게 맡기는 것이 효과적이었다.
반면 판정표를 만들거나 용어를 최종적으로 결정하는 작업은 쉽게 위임하지 않았다.
왜냐하면 이런 판단에는 여러 자료와 앞뒤 맥락을 동시에 봐야 하기 때문이다.
자료의 근거를 충분히 이해하지 못한 상태에서 시작한 에이전트가 그럴듯한 답을 내놓는다고 해서 그것을 바로 신뢰할 수는 없었다.
4. 그렇다면 에이전트 팀은 왜 아직 이른가?
여기서 이번 복습에서 가장 재미있었던 부분이 나왔다.
처음에는 에이전트 팀을 붙이면 여러 AI가 서로 토론하면서 더 좋은 답을 만들어줄 것이라고 생각했다.
하지만 지금 단계에서는 토론 자체가 문제를 해결해주지 못하는 상황이었다.
예를 들어 어떤 설비의 특정 내용이 맞는지 판단하려면,
제작사 도면에 실제로 무엇이라고 적혀 있는지
실제 설비에 어떤 구성요소가 붙어 있는지
원본 자료에 어떤 근거가 있는지
등을 확인해야 했다.
이런 상황에서 에이전트 여러 개에게 토론을 시키면?
근거가 부족한 상태에서 그럴듯한 결론을 만들어낼 가능성이 있다.
오히려 현재 프로젝트에서 해결하려고 하는 문제를 에이전트 구조가 그대로 재현할 수도 있었다.
서로 다른 자료를 충분히 참조하지 않는 에이전트들을 여러 개 만들어 놓고
서로 토론시키는 것만으로는 정확성이 올라가지 않는다.
5. 그래서 에이전트 팀의 첫 적용 지점을 다시 생각했다
그렇다면 에이전트 팀은 언제 쓰는 것이 좋을까?
이번 프로젝트에서는 검증 단계가 적절하다고 판단했다.
특히 판정표의 초안이 어느 정도 만들어지고, 앞단의 로데이터와 근거가 충분히 준비된 뒤에 반박 전용 에이전트, 즉 레드팀을 붙이는 방식이다.
역할은 단순하다.
"이 판정이 정말 이 근거에서 나오는가?"
를 공격적으로 검증하는 것이다.
이렇게 하면 에이전트 팀을 단순히 여러 명의 AI를 동시에 돌리는 용도가 아니라,
내가 만든 결과물을 검증하는 동료 집단처럼 활용할 수 있다.
6. 실제로 서브에이전트를 돌려봤다
그래서 일단 서브에이전트 3개를 실행해봤다.
컴퓨터 화면의 스크린샷
서브에이전트들이 각각의 작업을 받아서 동시에 돌아가기 시작했다. (토큰이 녹아난다는 이야기가 이것을 말하는 구나...)
그런데 예상하지 못한 일이 발생했다.
얼마 지나지 않아 오전 세션 리밋에 걸렸다.
한국어 코딩 언어의 스크린샷
😅
"여러 개를 동시에 돌리면 일이 빨라지겠지"라고 생각했던 것과 달리, 실제 환경에서는 에이전트를 몇 개 붙이 는 것 자체도 비용과 리소스를 고려해야 하는 작업이었다.
이 경험을 통해 또 하나 알게 됐다.
에이전트는 무조건 많이 붙이는 것이 능사가 아니다.
결과와 배운 점
이번 3주차 복습을 실제 업무에 붙여보면서 가장 크게 배운 것은 에이전트의 종류보다 '언제 붙일 것인가'가 더 중요하다는 것이었다.
1. 먼저 구조를 설계하고, 그다음 에이전트를 결정한다
처음부터
"이번에는 에이전트 팀을 써봐야지."
라고 시작하면 안 된다는 것을 알게 됐다.
먼저 해야 할 것은,
자료를 모으고
전체 구조를 잡고
어떤 문제가 있는지 파악하고
어떤 작업이 독립적인지 확인하고
그 다음에 서브에이전트인지 에이전트 팀인지 결정하는 것
이었다.
즉,
에이전트가 업무를 설계하는 것이 아니라, 내가 업무를 설계한 뒤 에이전트를 적절한 위치에 배치하는 것에 가깝다.
2. 서브에이전트와 에이전트 팀의 역할은 다르다
이번 경험을 통해 내가 이해한 차이는 이렇다.
구분
서브에이전트
에이전트 팀
역할
독립적인 업무 수행
서로 주고받으며 검토·토론
적합한 작업
분리 가능한 분석 업무
검증, 반박, 논의가 필요한 업무
전제
업무가 명확하게 분리되어 있어야 함
공유할 충분한 근거와 데이터가 있어야 함
이번 프로젝트
지금 활용 가능
뒤쪽 검증 단계에서 활용
결국
서브에이전트 = 일을 나눠서 시키는 것
이라면,
에이전트 팀 = 일을 나누는 것을 넘어 서로 검증하고 부딪히게 하는 것
이라고 이해하게 됐다.
3. 에이전트 팀은 '레드팀'으로 활용할 때 특히 의미가 있다
이번 경험에서 가장 인상적인 부분이다.
에이전트 팀을 처음부터 여러 명의 직원처럼 만들어서 일을 시키는 것보다,
내가 어느 정도 결과물을 만들고 → 다른 에이전트가 그것을 공격적으로 검증하도록 하는 구조
가 훨씬 명확했다.
특히 이번처럼
전문용어가 중요하고
여러 업체의 자료가 섞여 있고
원본 근거를 확인해야 하고
잘못된 판단이 최종 매뉴얼에 들어가면 안 되는
업무에서는 더욱 그렇다.
그래서 앞으로는 에이전트 팀을 사용할 때 이런 질문을 먼저 해보려고 한다.
"지금은 일을 더 많이 해야 하는 단계인가?"
그렇다면 서브에이전트.
"아니면 이미 만들어진 결과를 서로 검증하고 반박해야 하는 단계인가?"
그렇다면 에이전트 팀.
그리고 그보다 먼저,
"검증할 만큼 앞단의 로데이터와 근거가 준비되어 있는가?"
를 확인해야 한다.
4. 이번 복습에서 얻은 나만의 기준
이번 경험을 한 문장으로 정리하면 이렇다.
에이전트를 많이 붙이는 것이 중요한 게 아니라, 업무의 구조를 먼저 보고 어떤 단계에 어떤 에이전트를 붙일지를 판단하는 것이 중요하다.
특히 앞으로는 다음과 같은 순서로 생각해보려고 한다.
① 혼자 구조 설계
↓
② 독립적인 업무 → 서브에이전트
↓
③ 로데이터와 근거가 충분히 준비됨
↓
④ 검증·반박이 필요함 → 에이전트 팀 / 레드팀
이번에는 세션 리밋이라는 작은(?) 시행착오까지 겪었지만 😂, 오히려 실제 업무에 붙여보니 스터디에서 배운 개념이 훨씬 명확해졌다.
"에이전트 팀을 어떻게 만드는가?"보다 "에이전트 팀이 필요한 순간은 언제인가?"
앞으로는 이 질문을 먼저 해보려고 한다.
도움 받은 글
3주차 스터디 — Claude 서브에이전트와 에이전트 팀 실습
이번 프로젝트에서 Claude와 함께 진행한 업무 구조화 및 판단 과정
