일상 업무에 Claude 관리형 에이전트를 활용하는 Anthropic Japan의 비즈니스 개발 담당자

Anthropic Japan 팀에서 비즈니스 개발을 담당하는 저는 일본 기업에 Claude로 워크플로우를 간소화하고 자동화하는 방법을 소개합니다. 하지만 올해 초까지만 해도 정작 제 업무는 대부분 수작업으로 처리하고 있었습니다. 매일 아침 두 시간 정도 잠재 고객을 담당자에게 배정하고 영업 대상으로 적합한지 판단한 다음, 이어서 일본어나 영어로 이메일을 작성했습니다. 남은 시간에는 회사 CRM을 업데이트했지만, 하루 이상 밀리는 경우가 많았습니다. 이제는 제가 하루 업무를 시작하기 전에 에이전트들이 이런 작업의 대부분을 미리 준비해 두고, 저는 그 결과를 검토합니다.

제가 처음 만든 Claude 기반 워크플로우는 꽤 엉성했지만, 필요한 일은 해냈습니다. 저는 Claude에 업무를 하나씩 맡기면서, Claude가 잘못 처리한 부분을 바로잡은 뒤 그 수정 내용을 저장했습니다. 시간이 지나면서 이 워크플로우는 각각 다른 업무를 처리하는 몇 개의 에이전트로 발전했습니다.

이 이야기는 빠르게 퍼졌고, 팀원들은 각자 에이전트를 만들 수 있도록 제가 쓰는 프롬프트와 Skills를 공유해 달라고 요청하기 시작했습니다. 하지만 제가 보내 줄 수 있었던 것은 제 Skills와 지식 베이스의 Markdown 파일 몇 개가 담긴 zip 파일뿐이었습니다. 팀원들은 이를 Claude에 업로드한 다음, 여러 개의 초기 설정 질문에 답해야 에이전트를 실행할 수 있었습니다. 저 역시 제 에이전트 구성을 파악하고 관리하는 것이 점점 더 어려워졌습니다. 각 에이전트는 Skill 하나와 예약 작업, 공유 폴더로 구성되어 있었습니다. 저는 그때그때 열려 있던 채팅에서 Claude에 수정을 요청했기 때문에, 같은 Skill을 여러 대화에서 편집하고 있었습니다.

각 에이전트를 한 곳에서 한 번만 정의하고, 이후 제가 수정한 내역을 모두 확인할 수 있으면 좋겠다고 생각했습니다. 그래서 Claude Platform의 자사 관리형 에이전트 인프라인 Claude 관리형 에이전트 (opens in new tab)(베타)를 사용해 보기로 했습니다.

처음에는 사용해 보기가 망설여졌습니다. 문서에 스케줄, 도구, 자격 증명 보관소에 관한 설명이 있었는데, 영업 담당자인 저는 관리형 에이전트가 필요한 인프라를 직접 구축하고 유지 관리할 수 있는 개발자를 위한 것이라고 생각했습니다. 이미 만들어 둔 에이전트가 있었기 때문에 옮기기만 하면 되는 상태였습니다. 그래서 저는 일단 써 보기로 했습니다.

막상 써 보니 개발자가 아니어도 괜찮았습니다. 각 에이전트가 할 일을 일상적인 말로 설명하자, Claude가 짧은 설정 스크립트 몇 개를 작성했고, 저는 제 노트북의 터미널에서 이를 실행했습니다. (처음부터 새로 만드는 경우, 콘솔에서 바로 사용할 수 있는 에이전트 템플릿이 포함된 빠른 시작 가이드도 제공합니다.) 그 이후로는 제가 직접 인프라를 관리할 필요가 없었습니다.

이 글에서는 여러 에이전트를 설계하고 프로토타입을 만든 과정과 관리형 에이전트로 이전한 이유를 설명하겠습니다. 또한 정해진 반복 업무에 속하지 않는 일을 Claude Tag가 어떻게 맡아 처리했는지, 이 모든 변화가 제 일주일 업무에 어떤 변화를 가져왔는지도 소개하겠습니다. 마지막으로, 수작업으로 처리하는 반복적인 워크플로우를 자동화하기 위해 직접 에이전트를 구축하려는 영업 담당자들에게 조언을 전하겠습니다.

나만의 에이전트 팀 설계하기

저는 제 워크플로우를 여러 에이전트에 나누어 맡기고, 각 에이전트가 맡을 역할을 하나씩 분명하게 지정했습니다. 역할을 하나로 한정하면 각 에이전트가 어떻게 작동하는지 이해하고 그 과정을 추적하기가 쉬워집니다. 특히 문제가 생겼을 때 도움이 됩니다. 또한 대부분의 작업을 일본어로 수행하는 만큼, 모든 에이전트에 일본어 이름도 붙였습니다. 이 에이전트들을 통틀어 Nakama라고 부릅니다. 이는 '크루'라는 뜻으로, '함께 일하는 동료'를 의미합니다.

• Furiwake('분류')가 가장 먼저 실행됩니다. 매일 유입되어 배정을 기다리는 잠재 고객 목록을 확인하고 담당자별 잠재 고객 수와 각 잠재 고객의 우선순위, 당일 근무 여부를 고려해 팀 내 적절한 영업 담당자에게 배정합니다. 덕분에 팀원 누구나 업무를 시작하기 전에 모든 잠재 고객의 담당자가 정해집니다. 매번 실행이 끝나면, 유입된 모든 잠재 고객과 각 잠재 고객의 배정 결과를 담은 보고서를 전용 Slack 채널에 게시하므로, 저는 인계 과정을 확인할 수 있습니다.
• Sabaki('처리')는 저에게 배정된 잠재 고객을 평가하여 대응 방식을 정합니다. 각 잠재 고객이 영업 대상으로 적합한지 판단하고, 미리 정해 둔 기준에 따라 분류한 뒤, 유형별로 정해진 다음 조치를 수행합니다. 예를 들어 셀프서비스 이용을 안내하는 답장 초안을 쓰거나, 고객에게 맞춘 첫 이메일을 작성합니다. 또한 Salesforce의 잠재 고객 기록을 업데이트하고, 첫 연락에 사용할 이메일 초안을 작성합니다. 초안의 내용은 Nakama의 공유 지식 베이스에서 가져옵니다. 이 지식 베이스는 모든 에이전트가 정보를 읽고 기록하는 메모리 저장소 (opens in new tab)입니다(자세한 내용은 아래 참조).
• Henji('답장')는 매시간 제 받은편지함을 확인해 답장이 필요한 고객 이메일을 찾고, 해당 대화에 맞춰 일본어나 영어로 답장 초안을 작성합니다. 이때 Sabaki가 사용하는 것과 같은 지식 베이스를 활용합니다. 저는 이렇게 작성된 초안을 검토하여 수정한 뒤, 발송할 수 있습니다.
• Shoudan('영업 기회')은 최근 고객과 주고받은 내용을 확인하고, Salesforce에 업데이트 사항을 반영합니다. 덕분에 데이터를 직접 입력하지 않아도 영업 기회 기록이 최신 상태로 유지됩니다.
• Nokori('나머지 사항')는 하루 일과가 끝날 때 실행됩니다. 제 캘린더를 확인하고, 첨부된 회의 녹취록을 읽어 각 회의를 요약합니다. 이어서 같은 지식 베이스를 활용해 후속 연락을 위한 초안을 작성합니다.

각 에이전트는 정해진 일정에 따라 실행됩니다. 여섯 번째 에이전트인 Nakama의 코디네이터는 에이전트 팀의 운영 관리자 역할을 합니다. 한 번의 실행이 끝나고 다음 실행이 시작되기 전까지, 에이전트의 지침과 공유 지식 베이스를 업데이트합니다. 에이전트의 작동 방식을 바꾸고 싶을 때는 Nakama의 Slack 채널에 원하는 내용을 일상적인 언어로 작성합니다. 에이전트의 지침과 시스템 프롬프트에 대한 변경 요청은 저만 게시할 수 있습니다. 코디네이터는 약 15분 간격으로 해당 채널을 확인해 요청을 접수하고, 그에 따라 변경 사항을 업데이트합니다.

Claude에서 에이전트 팀의 프로토타입 만들기

처음부터 관리형 에이전트가 필요한 것은 아닙니다. 저는 먼저 Claude에서 다음 요소를 활용해 에이전트 팀 전체의 프로토타입을 만들었습니다.

• 각 에이전트마다 Skill 하나씩: 한 가지 업무를 수행하기 위한 지침을 담은 Skill을 만들었습니다.
• Skill마다 예약 작업 하나: 매번 수동으로 실행할 필요가 없도록 했습니다.
• 지식 베이스로 사용하는 노트북의 공유 폴더: 각 Skill은 작업하면서 배운 내용을 이 폴더에 기록합니다. 작성한 초안과 제가 실제로 보낸 내용의 차이점은 물론, 작업 과정에서 새롭게 찾아낸 정보가 여기에 포함됩니다.

관리형 에이전트에서 Skill은 에이전트의 시스템 프롬프트로, 예약 작업은 에이전트 배포에 설정하는 실행 일정 (opens in new tab)으로, 공유 폴더는 메모리 저장소로 전환되었습니다. 여전히 일상적인 언어로 변경을 요청하지만, 이제는 모든 요청을 하나의 Slack 채널에서 합니다. 에이전트 지침을 변경할 때마다 새 버전으로 저장되므로, 각 에이전트의 지침 이력이 버전 번호와 함께 보관됩니다. 먼저 Claude에서 시작하고, 에이전트가 많아져 관리에 부담이 생길 때 관리형 에이전트로 옮길 것을 권장합니다.

Claude 관리형 에이전트에서 에이전트 팀 운영하기

관리형 에이전트를 사용하면서 얻은 이점 중 제 워크플로우에 가장 중요했던 3가지는 다음과 같습니다.

에이전트를 백그라운드에서 실행할 수 있습니다.

에이전트는 제 노트북을 열어 두었는지와 관계없이, 심지어 인터넷에 연결되어 있지 않은 상태에서도 정해진 일정에 따라 실행됩니다. 일정은 각 에이전트 배포 구성에 포함됩니다. Claude에서도 Skill의 실행 일정을 예약할 수 있었지만, 그때는 제가 사용하는 앱 안에 예약 작업을 하나씩 설정하는 방식이었습니다. 관리형 에이전트에서는 콘솔에서 배포된 에이전트의 지침과 도구 바로 옆에 있는 설정으로 실행 주기와 시간대를 지정합니다. 별도로 관리해야 할 cron 작업도 없습니다. 실행 중 문제가 발생하면 콘솔에서 해당 실행 내역을 열어 에이전트가 수행한 각 단계를 확인할 수 있습니다. 또한 에이전트의 변경 사항을 테스트하는 동안에도 예약된 실행에는 배포된 버전이 계속 사용됩니다. 따라서 아직 수정이 끝나지 않은 내용이 내일 실행에 반영되지는 않습니다.

Nakama는 하나의 메모리를 공유하며, 제가 수정한 내용을 바탕으로 학습합니다.

모든 에이전트가 동일한 메모리 저장소 (opens in new tab)에서 정보를 읽고 기록하므로, 다른 에이전트가 학습한 내용을 서로 활용할 수 있습니다. 에이전트들은 자신이 작성한 초안과 제가 실제로 보낸 이메일을 비교하고, 차이가 나는 부분을 하나씩 메모해 제가 사용하는 표현 방식을 기록합니다. 또한 답변을 위해 자료를 조사하는 과정에서 당사 내부 문서와 공식 웹사이트에서 새롭게 알아낸 정보도 모두 보관합니다. 제가 Henji의 초안에서 문구를 한 번 수정하면, Sabaki와 Nokori는 동일한 실수를 반복하지 않습니다.

자격 증명은 권한 범위가 지정된 관리형 보안 저장소에 보관됩니다.

제 에이전트들은 제 이메일과 당사의 Salesforce 기록에 접근할 수 있었습니다. 하지만 고객과의 대화와 회사 기록을 다루는 만큼, 접근 권한을 통제하고 싶었습니다. 자격 증명은 관리형 보안 저장소 (opens in new tab)에 보관됩니다. 이 저장소는 OAuth 액세스 토큰과 갱신 토큰, API 키, 개인 액세스 토큰 등 에이전트가 외부 서비스에 로그인할 때 사용하는 자격 증명을 보호합니다. 에이전트의 배포 환경은 각각 업무에 필요한 보안 저장소만 사용하며, 에이전트에 자격 증명을 노출하지 않습니다. 저는 한 단계만으로 접근 권한을 철회할 수 있습니다.

Claude Tag에 다음 단계 맡기기

Nakama가 만든 결과물을 처리할 때 제가 할 일은 대부분 받은편지함의 초안을 읽고 전송하거나, 업데이트된 Salesforce 기록을 간단히 확인하는 정도입니다. 그러나 업그레이드 방법 또는 구매 경로를 알아보거나, 다른 팀에 문제를 이관하는 등의 후속 조치가 필요한 건도 있습니다.

이러한 경우에도 에이전트는 작업을 멈추고 저를 기다리지 않습니다. 해당 건을 Claude Tag (opens in new tab)(베타 버전)에 넘깁니다. Claude Tag는 저희 Slack 워크스페이스의 멤버로 설정된 Claude입니다. Claude가 들어와 있는 채널이라면, 사람도 제 에이전트도 @Claude를 태그해 작업을 요청할 수 있습니다. 그러면 Claude가 요청을 받아 그 스레드에서 처리합니다. 워크스페이스에 설정하고 나면, 새로 배워야 할 것은 없습니다. 동료를 태그하듯 Claude를 태그하면 됩니다.

제가 구성한 환경에서는 다음과 같이 작동합니다. 에이전트가 실행해야 할 일을 Nakama의 Slack 채널에 게시하고 Claude를 태그합니다. Claude는 스레드를 읽고, 당사 규정과 해당 건에 적용되는 조건을 확인한 뒤, 선택지를 정리하고 필요한 내용의 초안을 작성합니다. 저의 검토나 승인이 필요한 단계가 있으면 Claude가 저를 태그합니다. 고객이나 다른 팀의 답변을 먼저 받아야 하는 경우, Claude는 지정된 날짜에 다시 확인하도록 스스로에게 알림을 설정합니다. 아래 스레드에서 Claude는 고객이 회신했는지, 딜 데스크가 해당 티켓에 답변했는지 화요일에 확인하도록 알림을 설정했습니다. 알림 시간이 되면 Claude는 두 가지 사항을 모두 확인하고, 같은 스레드에 현재 진행 상황을 게시합니다. 누군가에게 요청한 일을 상기시켜야 한다면 Claude가 메시지 초안을 작성한 뒤, 제가 보낼 수 있도록 저를 태그합니다.

Claude는 제품과 가격 관련 변경 사항을 정리한 아침 브리핑도 게시합니다. Nakama 코디네이터는 이 브리핑을 가져와 필요한 변경 사항을 공유 지식 베이스에 기록합니다.

일주일 업무에서 달라진 점

이제 Claude가 수신 문의에 대한 답변을 준비하고 CRM 기록을 최신 상태로 유지하므로, 제가 직접 처리할 일은 거의 없습니다. 제 역할은 사람의 판단이 필요한 내용을 모두 검토하는 것입니다. 문서화된 규칙에 따라 각 에이전트의 담당 범위가 정해져 있으며, 가격 관련 질문이나 신중한 대응이 필요한 고객사, 모호한 요청 등은 제게 전달됩니다. Henji, Sabaki, Nokori가 보내오는 모든 이메일 초안에는 현재 상황을 간략히 정리한 요약이 맨 위에 있어, 맥락을 파악하려고 스레드 전체를 읽어 볼 필요가 없습니다. 저는 요약을 읽고 내용을 확인한 뒤, 수정해서 보냅니다.

Nakama가 처리한 업무의 주간 기록을 살펴보고, 각 업무를 제가 직접 처리했다면 걸렸을 시간으로 환산해 보면, 에이전트 팀 덕분에 절약하는 업무 시간이 약 60시간에 달합니다. 이렇게 확보한 시간은 에이전트가 아직 효과적으로 수행하지 못하는 업무에 씁니다. 고객과의 대화, 아웃바운드 영업 전략, 부서 간 협업 프로젝트, 팀원들이 각자의 에이전트 팀을 구축하도록 돕는 일 등입니다.

에이전트의 효율성을 높이는 설계

예약된 에이전트는 제가 지켜보든 그렇지 않든 매일 실행되므로, 불필요한 작업이 누적되면 비용이 늘고 신뢰성에도 영향을 미칠 수 있습니다. 가장 흔한 실수로는 기존 지침을 수정하는 대신 내용을 계속 덧붙이는 것, 에이전트에게 업무에 필요한 것보다 더 많은 컨텍스트를 제공하는 것, 모든 작업을 가장 큰 모델에서 가장 높은 노력 수준으로 실행하는 것 등이 있습니다.

에이전트가 효율적으로 작동하는 데는 제가 에이전트 팀을 설계한 방식이 큰 역할을 합니다. 각 에이전트가 하나의 업무만 담당하므로 지침도 해당 업무에 집중되어 있습니다. 실무를 맡은 각 에이전트는 정해진 일정에 따라 실행되고, 작업을 한 차례 수행한 후 멈춥니다. 또한 에이전트들은 메모리를 공유하므로 한 번 수정한 내용은 팀 전체에서 재사용됩니다.

또 다른 중요한 요소는 각 에이전트가 어떤 모델을 기반으로 실행되느냐입니다. 에이전트의 업무가 명확히 정의되어 있다면, 당사의 최고 성능 모델이 필요하지 않을 수 있습니다. Furiwake와 Shoudan은 문서화된 규칙을 따르기 때문에 규모가 더 작은 모델인 Sonnet에서 실행됩니다. Sabaki, Nokori, 그리고 코디네이터는 업무 수행에 더 많은 판단이 필요하므로, 더 큰 모델인 Opus를 사용합니다. Opus가 가장 필요한 것은 코디네이터입니다. 다른 에이전트의 지침을 수정하는 역할을 맡고 있어, 한 번만 잘못 수정해도 그 영향이 모든 에이전트에 미치기 때문입니다. 고객마다 이메일 내용이 다르므로 Henji에도 Sabaki만큼의 판단 능력이 필요합니다. 하지만 업무 시간 내내 다른 어떤 에이전트보다 더 자주 실행되기도 합니다. Henji를 매번 Opus로 실행하면 비용이 가장 많이 들기 때문에, 저는 관리형 에이전트의 자문 전략 (opens in new tab)을 사용합니다. Henji는 Sonnet으로 실행하되, 스스로 판단하기 어려운 상황에서는 Opus에 자문을 구합니다. 자문 역할을 하는 모델은 Henji가 지금까지 수행한 작업을 살펴보고 계획, 수정 사항 또는 중지 신호를 보냅니다. 그러면 Henji는 제가 검토할 초안을 완성합니다. 또한 각 에이전트의 노력 수준(모델이 응답하기 전에 생각하는 시간)을 모델 선택과 별도로 설정하며, Henji의 답변처럼 추론이 어려운 경우에만 노력 수준을 높입니다.

이 과정을 통해 배운 점

자신만의 에이전트 팀을 만들려는 분들께 다음 세 가지를 말씀드리고 싶습니다.

1. 매번 상세한 프롬프트를 작성할 필요는 없습니다. 할 일을 한 번 설명하고 Claude가 초안을 작성하게 하세요. 그 초안을 직접 수정한 다음, Claude가 그 수정 사항을 기억하도록 하세요.
2. 지식 베이스가 프롬프트보다 더 중요합니다. 모든 수정 사항과 이전 상호작용 기록은 모든 에이전트가 정보를 읽고 쓸 수 있는 위치에 저장됩니다. Claude는 더 긴 프롬프트 대신 그 공간에서 컨텍스트를 가져옵니다. 초안이 제가 쓴 것처럼 읽히기까지, 비용이 적게 드는 초안 작성, 수정, 저장 과정을 수백 번 반복해야 했습니다.
3. Claude가 더 일찍 더 많은 재량을 가질 수 있도록 하세요. 처음에는 제가 직접 해야 하는 일이라고 여겨, 지식 베이스 업데이트나 에이전트별 지침 수정을 계속 직접 처리했습니다. 하지만 두 업무 모두 제가 손을 떼고 맡겨도 문제없이 처리되었습니다. 이제 에이전트들은 학습한 내용을 직접 지식 베이스에 기록하고, 제가 일상적인 영어로 요청하면 코디네이터가 다른 에이전트의 지침을 업데이트합니다. 에이전트를 믿고 맡겨도 되는 업무인데도, 제가 지나치게 조심스러웠던 것입니다.

Claude 관리형 에이전트 시작하기 (opens in new tab)