개요
LangChain이 6월 16일 공개한 글에서 Fleet의 설계 의도를 처음으로 정리해 풀어 놨습니다. 핵심 주장은 단순합니다. 에이전트는 일의 모양에 맞춰 두 종류로 나뉘어야 한다는 것이죠. 일회성 질문에는 범용 채팅(General Purpose Chat)이 맞고, 같은 절차로 매주 도는 일에는 전문 에이전트(Specialized Agents)가 따로 필요하다는 이야기입니다. 두 갈래를 한 채팅창에 욱여넣으면 매번 프롬프트를 다시 쓰게 되고, 결국 채팅 스레드가 운영 매뉴얼 역할까지 떠맡게 된다는 진단이 출발점입니다.
핵심 요약
- 두 종류 에이전트: 일회성·즉흥 업무는 General Purpose Chat, 반복 업무는 Specialized Agents가 담당.
- 메모리가 핵심 차이: 범용 채팅은 스레드 한정, 전문 에이전트는 작업 단위로 기억을 누적·갱신.
- 전문 에이전트 구성 요소: 지침, 도구, 모델, 서브에이전트, 스킬, 트리거/스케줄, Computer Access.
- 승격 경로: 채팅에서 한 번 잘 풀린 작업을 그대로 전문 에이전트로 묶어 영구 자산화.
- 모델 분할: 메인은 강한 모델, 좁은 서브태스크는 작은 모델 — 비용·속도·품질을 분리 최적화.
일회성 업무는 채팅으로
휴가 다녀온 월요일 아침을 상상해 보면 이해가 빠릅니다. 슬랙 스레드, GitHub PR, Linear 티켓, 캘린더 초대를 한꺼번에 따라잡아야 하죠. 도구가 여러 개고, 판단이 필요하고, 결과물도 그때그때 다릅니다. 다음 주에 같은 작업을 또 돌릴 일도 없습니다.
이 모양의 일은 General Purpose Chat이 맡습니다. 어떤 도구·프롬프트·스킬을 미리 세팅할지 정할 필요가 없습니다. 워크스페이스 통합으로 들어오는 자료에 접근하고, 파일 시스템으로 맥락을 관리하고, 코드나 데이터 분석이 필요하면 가상 컴퓨터(Computer Access)를 켜서 실행합니다. 일이 끝나면 스레드도 같이 닫히면 됩니다.
반복 업무는 전문 에이전트로
문제는 매주 같은 모양으로 돌아오는 일입니다. 주간 계획 정리, 인박스 분류, 고객 리서치 브리프, 백로그 관리 같은 작업이죠. 이런 걸 매번 “이번에도 같은 형식으로 정리해 줘"라고 다시 설명하면 안 됩니다. Specialized Agents는 이 반복 업무에 안정적인 자리를 만들어 주는 쪽입니다.
예를 들어 계획 에이전트는 월요일마다 Linear를 훑고, 출시된 항목을 요약하고, 막힌 일을 표시한 뒤 팀이 쓰는 양식대로 초안을 뽑아 줍니다. 인박스 에이전트는 새 메일을 분류하고 답장 초안을 만들고, 고객 이슈는 에스컬레이션하고, 내가 직접 처리하고 싶은 메일은 따로 둡니다.
설정은 두 가지 방식 중 하나로 합니다. 지침·모델·도구·스킬·서브에이전트·트리거까지 직접 정의해도 되고, 평어로 “이런 일을 하는 에이전트가 필요하다"고 말해 Fleet이 구조를 잡아 주게 해도 됩니다.
전문 에이전트가 다루는 7가지 슬롯
Specialized Agents가 일회성 채팅과 갈리는 지점은 결국 고정된 슬롯이 있다는 것입니다.
- 지침(Instructions): 역할, 의사결정 규칙, 출력 형식, 에스컬레이션 기준, 경계선까지 박아 두는 프롬프트.
- 도구(Tools): 그 일에 꼭 필요한 것만. 풀어 두지 않고 좁혀 둡니다.
- 모델(Models): 메인은 검토·계획에 강한 모델, 서브태스크는 작은 모델로 비용·속도를 분리.
- 서브에이전트(Subagents): 맥락이 무거운 작업을 떼어내는 호출형 전문가. 메인 컨텍스트를 더럽히지 않습니다.
- 스킬(Skills): 워크스페이스 공용 스킬과 그 에이전트 전용 스킬을 섞어 씁니다. 모든 지침을 모든 에이전트에 노출하지 않는 방식이죠.
- 트리거·스케줄(Triggers and schedules): Slack·Gmail·Outlook·Teams 이벤트, 또는 정해진 시간에 자동 실행.
- Computer Access: 코드·파일·분석이 필요할 때 켜는 실제 실행 환경. 전문 에이전트는 스레드 사이에서도 Computer를 공유할 수 있습니다.
가장 큰 차이는 기억의 결
글이 가장 강하게 못 박는 부분이 여기입니다. General Purpose Chat은 스레드 안에서만 기억합니다. 임시 업무에 맞춰진 설계니까요. 반면 Specialized Agents는 일에 매인 기억(memory scoped to the job) 을 갖습니다. 사실을 기억하고, 시간이 가면서 갱신하고, 다음 실행 때 그 기억을 가져와서 씁니다.
Linear 티켓을 관리하고 GitHub PR을 지켜보는 PM 에이전트를 떠올려 보면 됩니다. 시간이 지나면서 이 에이전트는 “A 엔지니어는 백엔드 이슈를 선호한다”, “B 엔지니어는 티켓을 잘게 쪼개 받고 싶어 한다”, “릴리스 블로커 버그는 즉시 에스컬레이션해야 한다” 같은 사실을 작업 기억(working memory)으로 누적합니다. 매주 누군가가 같은 프롬프트를 다시 쓰는 구조가 아닙니다.
지침은 고정돼 있어 일관성을 만들고, 기억은 일이 굴러가면서 진화한다 — 저장된 채팅과 전문 에이전트가 갈라지는 결정적 지점은 여기입니다.
채팅에서 전문 에이전트로 승격
흥미로운 부분은 승격 경로가 같이 설계돼 있다는 점입니다. 어떤 일을 General Purpose Chat에서 한 번 풀어 봤는데 잘 굴러갔다면, Fleet은 그걸 그대로 Specialized Agent로 묶어 줍니다. 지침, 도구, 스킬, 메모리, 실행 방식을 다 가져갑니다. 빈 설정 화면에서 처음부터 짜지 않아도 된다는 뜻이죠.
이게 실무에 중요한 이유는 단순합니다. 잘 푸는 사람에게 묶여 있던 일이 에이전트로 이전되면, 팀은 더 이상 “그 사람 휴가 갔는데 이건 어떻게 하지” 상태에 빠지지 않습니다. 작업이 주인을 갖게 된다는 표현이 글에 나오는데, 이게 핵심입니다.
어느 쪽을 골라야 하는가
글이 친절하게 하나의 기준을 제시합니다. 난이도가 아니라 모양입니다. 복잡해도 한 번 끝나면 일회성이고, 단순해도 반복이면 반복입니다.
| 상황 | 추천 |
|---|---|
| 휴가 후 따라잡기, 문서 요약, CSV 분석, 초안 작성 | General Purpose Chat |
| 매주 같은 양식의 보고, 인박스 분류, 트래픽 모니터링 | Specialized Agents |
| 한번 잘 풀린 채팅이 반복 업무가 됨 | 그 채팅을 그대로 전문 에이전트로 승격 |
실무자가 볼 핵심 포인트
- 에이전트 분기 기준: 같은 일을 또 돌릴 가능성이 있는지 먼저 보세요. 1회면 채팅, 2회 이상이면 전문 에이전트 후보.
- 메모리 설계가 자산: 사람마다 다른 선호·예외 케이스·블로커 규칙을 프롬프트에 다시 적지 말고, 전문 에이전트의 메모리에 누적시키세요.
- 모델 분할 최적화: 서브에이전트마다 모델을 따로 잡을 수 있다는 점이 큽니다. 계획·검토는 강한 모델, 좁은 분류·요약은 작은 모델로 비용을 떨어뜨릴 수 있습니다.
- 트리거 자동화: Slack/Gmail 이벤트나 스케줄 트리거가 붙으면 “에이전트를 매번 깨우는 사람"이 사라집니다. 운영 관점에서 차이가 큽니다.
- 승격 동선 설계: 팀에서 자주 쓰는 채팅 프롬프트가 있다면, 그게 전문 에이전트 후보입니다. Fleet은 채팅→에이전트 승격을 명시적으로 지원합니다.
- Computer Access 범위: 채팅에서는 스레드 단위, 전문 에이전트에서는 스레드 사이 공유까지 가능합니다. 장기 실행 작업에서 차이가 큽니다.
정리
요약하면 한 줄입니다. 모양이 다른 일에 같은 모양의 에이전트를 강요하지 말 것. 일회성 업무는 채팅으로 가볍게, 반복 업무는 전문 에이전트로 묶어 자산으로 남긴다. Fleet이 두 종류를 함께 두는 이유는 결국 팀에 두 가지 일이 늘 같이 있기 때문입니다. 채팅과 전문 에이전트 사이에 승격 경로가 뚫려 있다는 점만 잘 활용해도 운영 비용이 한 단계 떨어집니다.