Anthropic 일본 BDR, Claude 에이전트 팀으로 하루 업무를 꾸리는 방법

저는 Anthropic 일본 팀에서 사업개발 담당자(BDR)로 일합니다. 일본 기업이 Claude로 업무 흐름을 단순화하고 자동화하도록 돕는 것이 제 역할인데, 정작 제 업무 대부분은 올해 초까지도 수작업이었습니다. 매일 아침 두어 시간을 리드를 분배하고 검증하는 데 썼고, 그다음에는 일본어나 영어로 이메일을 썼습니다. 남은 시간에 CRM을 갱신했지만, 반영이 하루 이상 늦어지는 일이 잦았습니다. 지금은 제 하루가 시작되기 전에 에이전트가 이 작업 대부분을 준비해 두고, 저는 검토만 합니다.

Claude로 처음 만든 워크플로는 꽤 허술했지만 제 몫은 했습니다. 업무를 한 번에 하나씩 Claude에게 맡기고, 틀린 부분은 바로잡고, 그 수정 내용을 저장해 두었습니다. 이 과정이 쌓이면서 각자 다른 일상 업무를 맡은 에이전트 몇 개로 늘어났습니다.

소문은 금방 퍼졌고, 팀원들이 자기도 만들어 보겠다며 제 프롬프트와 스킬을 달라고 하기 시작했습니다. 하지만 제가 보낼 수 있는 것은 스킬을 담은 zip 파일과 지식 베이스에서 꺼낸 Markdown 파일 몇 개뿐이었습니다. 받은 사람은 이를 Claude에 업로드하고 설정 질문에 줄줄이 답해야 비로소 쓸 수 있었습니다. 제 설정도 점점 관리하기 어려워졌습니다. 에이전트 하나가 스킬, 예약 작업, 공유 폴더로 이루어져 있었는데, 저는 열려 있는 아무 채팅에서나 Claude에게 부탁해 수정했습니다. 그러다 보니 같은 스킬이 여러 대화에서 제각각 수정되고 있었습니다.

저는 각 에이전트를 한곳에서 한 번만 정의하고, 그동안 바꾼 내용을 모두 확인할 수 있기를 원했습니다. 그래서 Claude Platform의 관리형 에이전트 인프라인 Claude Managed Agents(베타)를 써 보기로 했습니다.

처음에는 망설였습니다. 문서에는 스케줄, 도구, 자격 증명 보관소(credential vault) 같은 말이 나오는데, 저는 영업 담당자라서 Managed Agents는 필요한 인프라를 직접 구축하고 운영할 수 있는 개발자를 위한 것이라고 생각했습니다. 그래도 시도해 본 이유는 에이전트가 이미 있어서 옮기기만 하면 됐기 때문입니다.

결과적으로 개발자일 필요는 없었습니다. 각 에이전트가 하는 일을 평범한 말로 설명하면 Claude가 짧은 설정 스크립트 몇 개를 작성했고, 저는 그것을 노트북 터미널에서 실행했습니다. (처음부터 시작한다면 Console에도 에이전트 템플릿이 준비된 퀵스타트가 있습니다.) 그 뒤로는 제가 따로 관리할 인프라가 없습니다.

이 글에서는 에이전트 팀을 어떻게 설계하고 프로토타입으로 만들었는지, 왜 Managed Agents로 옮겼는지, 정해진 루틴을 벗어나는 일을 Claude Tag가 어떻게 이어받는지, 그 덕에 제 한 주가 어떻게 달라졌는지를 다룹니다. 마지막으로, 반복적인 수작업을 자동화할 에이전트를 직접 만들고 싶은 영업 담당자분들께 드릴 조언도 정리했습니다.

에이전트 팀 설계하기

저는 업무 흐름을 여러 에이전트로 나누고, 에이전트마다 명확한 역할을 하나씩 맡겼습니다. 역할이 하나면 각 에이전트의 동작을 이해하고 추적하기 쉽고, 문제가 생겼을 때 특히 유용합니다. 에이전트들이 주로 일본어로 일하기 때문에 이름도 모두 일본어로 지었습니다. 이들을 통틀어 Nakama라고 부르는데, '동료'라는 뜻이고 더 문자 그대로는 함께 일하는 짝이라는 의미입니다.

• Furiwake('분류')가 가장 먼저 움직입니다. 매일 들어오는 인바운드 큐를 읽고, 리드 수와 우선순위의 균형을 맞추고 그날 근무하는 사람을 확인해서 팀의 알맞은 담당자에게 각 리드를 배정합니다. 덕분에 우리가 하루를 시작하기 전에 모든 리드에 담당자가 정해집니다. 실행이 끝날 때마다 전용 Slack 채널에 리포트(들어온 리드 전체와 배정 결과)를 올려서 저는 인수인계 상황을 확인합니다.
• Sabaki ('처리')는 제게 배정된 리드를 선별합니다. 리드를 검증하고 미리 정해 둔 기준에 따라 분류한 뒤, 분류별로 정해진 다음 단계(셀프서비스를 안내하는 답장 초안 작성, 맞춤형 첫 이메일 작성 등)를 수행하고, Salesforce의 리드 레코드를 갱신하고, 첫 접점 이메일 초안을 씁니다. 초안 내용은 모든 에이전트가 읽고 쓰는 메모리 스토어인 Nakama의 공유 지식 베이스에서 가져옵니다(아래에서 자세히 설명합니다).
• Henji ('답장')는 매시간 제 받은편지함에서 답이 필요한 고객 이메일을 찾아, 스레드에 맞춰 일본어나 영어로 답장 초안을 준비합니다. Sabaki와 같은 지식 베이스를 활용합니다. 저는 초안을 검토하고 수정한 뒤 보내면 됩니다.
• Shoudan('商談', 영업 기회)은 최근 고객과 나눈 대화를 읽고 Salesforce에 업데이트를 반영합니다. 덕분에 직접 데이터를 입력하지 않아도 영업 기회 레코드가 최신 상태로 유지됩니다.
• Nokori ('남은 것')는 하루가 끝날 때 실행됩니다. 제 캘린더를 훑어 미팅에 첨부된 녹취록을 읽고, 미팅별로 요약하고, 후속 이메일 초안을 씁니다. 이때도 같은 지식 베이스를 사용합니다.

각 에이전트는 스케줄에 따라 실행됩니다. 여섯 번째 에이전트인 Nakama의 코디네이터는 이 팀의 운영 관리자입니다. 실행과 실행 사이에 에이전트들의 지침과 공유 지식 베이스를 갱신합니다. 에이전트의 동작을 바꾸고 싶으면 Nakama의 Slack 채널에 원하는 내용을 평범한 말로 적습니다. 에이전트의 지침과 시스템 프롬프트 변경 요청은 저만 올릴 수 있습니다. 코디네이터는 15분 간격으로 이 채널을 확인하고, 요청을 발견하면 업데이트합니다.

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

시작할 때 Managed Agents가 꼭 필요한 것은 아닙니다. 저도 먼저 Claude에서 전체 팀의 프로토타입을 만들었고, 구성 요소는 다음과 같습니다.

• 에이전트별 스킬: 한 가지 업무에 대한 지침입니다.
• 스킬별 예약 작업: 직접 실행하지 않아도 되도록 합니다.
• 노트북의 공유 폴더: 모든 스킬이 배운 내용을 다시 기록하는 지식 베이스입니다. 초안과 제가 실제로 보낸 내용의 차이, 그리고 그 과정에서 새로 알아낸 정보가 담깁니다.

Managed Agents에서는 스킬이 에이전트의 시스템 프롬프트가 되고, 예약 작업은 에이전트 배포(deployment)에 붙은 스케줄이 되고, 공유 폴더는 메모리 스토어가 되었습니다. 변경을 평범한 말로 요청하는 방식은 그대로지만, 이제는 모든 요청을 Slack 채널 하나에서 하고, 에이전트 지침을 바꿀 때마다 새 버전으로 저장되어 에이전트별로 번호가 붙은 지침 이력이 남습니다. 먼저 Claude에서 시작하고, 에이전트가 늘어 한눈에 관리하기 버거워질 때 Managed Agents로 옮기시길 권합니다.

Claude Managed Agents로 에이전트 팀 운영하기

Managed Agents에서 얻은 것 중 제 업무에 가장 중요했던 세 가지입니다.

에이전트가 백그라운드에서 실행됩니다

노트북이 켜져 있든 꺼져 있든, 오프라인이든 에이전트는 스케줄대로 실행됩니다. 스케줄은 각 에이전트 배포의 일부입니다. Claude에서도 스킬을 예약할 수는 있었지만, 그 스케줄은 모두 제 앱에 설정한 작업이었습니다. Managed Agents에서는 Console에서 배포된 에이전트의 지침과 도구 바로 옆에 실행 주기와 시간대를 설정하므로, 따로 관리할 cron 작업이 없습니다. 실행에 문제가 생기면 Console에서 열어 에이전트가 거친 단계를 하나씩 볼 수 있습니다. 또 에이전트를 수정해 보는 동안에도 예약 실행은 배포된 버전을 계속 쓰기 때문에, 작업 중인 수정본이 내일 실행에 섞여 들어가지 않습니다.

Nakama는 메모리 하나를 공유하며 제 수정에서 배웁니다

모든 에이전트가 같은 메모리 스토어를 읽고 쓰기 때문에, 어느 에이전트든 다른 에이전트가 배운 내용을 활용할 수 있습니다. 에이전트들은 자기가 쓴 초안과 제가 실제로 보낸 이메일을 비교해서, 차이를 '제가 이렇게 표현한다'는 메모로 저장합니다. 사내 문서와 공식 웹사이트에서 답변을 조사하다 알게 된 새 정보도 함께 저장합니다. Henji의 초안에서 표현 하나를 고치면 Sabaki와 Nokori도 같은 실수를 하지 않습니다.

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

제 에이전트들은 이메일과 Salesforce 레코드에 접근할 수 있습니다. 하지만 고객과의 대화와 회사 레코드인 만큼 이 접근을 통제하고 싶었습니다. 자격 증명은 관리형 보관소(managed vault)에 저장됩니다. 이 보관소는 에이전트가 외부 서비스에 로그인할 때 쓰는 OAuth 액세스·리프레시 토큰, API 키, 개인 액세스 토큰 같은 자격 증명을 보호합니다. 각 에이전트의 배포는 자기 업무에 필요한 보관소만 사용하고 자격 증명 자체는 볼 수 없으며, 저는 한 번에 접근 권한을 회수할 수 있습니다.

다음 단계는 Claude Tag에 넘기기

Nakama가 만들어 내는 결과물 대부분은 받은편지함의 초안을 읽고 보내거나, 갱신된 Salesforce 레코드를 훑어보는 정도면 충분합니다. 하지만 업그레이드 경로나 구매 경로를 찾아야 하거나 다른 팀에 이슈를 에스컬레이션해야 하는 등, 후속 조치가 필요한 건도 있습니다.

이런 건은 에이전트가 멈춰서 제 응답을 기다리지 않고 Claude Tag(베타)에 넘깁니다. Claude Tag는 Claude를 Slack 워크스페이스의 구성원으로 설정한 것입니다. Claude가 참여한 채널에서는 사람이든 제 에이전트든 누구나 @Claude를 태그해 요청할 수 있고, Claude는 그 요청을 받아 스레드에서 처리합니다. 워크스페이스에 설정만 해 두면 새로 배울 것은 없습니다. 동료를 태그하듯 Claude를 태그하면 됩니다.

제 설정에서는 이렇게 동작합니다. 에이전트가 Nakama의 Slack 채널에 처리할 항목을 올리고 Claude를 태그합니다. Claude는 스레드를 읽고, 사내 규정과 적용되는 약관을 확인하고, 선택지를 정리하고, 필요한 초안을 작성합니다. 제 검토나 승인이 필요한 단계에서는 저를 태그합니다. 고객이나 다른 팀의 답변이 먼저 필요하면 Claude가 정해진 날에 다시 확인하도록 스스로 리마인더를 설정합니다. 아래 스레드에서는 화요일에 고객이 답장했는지, 딜 데스크가 티켓에 답했는지 확인하도록 리마인더를 설정했습니다. 리마인더 시점이 되면 Claude는 두 가지를 확인하고 같은 스레드에 진행 상황을 올립니다. 누군가에게 재촉이 필요하면 메시지 초안을 쓰고 저를 태그해 제가 보내게 합니다.

Claude는 제품과 가격 업데이트를 정리한 모닝 브리프도 올립니다. Nakama 코디네이터가 이 브리프를 읽고 필요한 변경 사항을 공유 지식 베이스에 반영합니다.

제 한 주는 어떻게 달라졌나

이제 Claude가 인바운드 답장을 준비하고 CRM 레코드를 (대부분) 제 손을 거치지 않고 최신 상태로 유지하므로, 제 역할은 사람의 판단이 필요한 건을 검토하는 것입니다. 문서화된 규칙집이 에이전트별 담당 범위를 정하고, 가격 문의나 민감한 고객사, 모호한 요청 같은 건은 제게 넘어옵니다. Henji, Sabaki, Nokori가 쓴 이메일 초안에는 모두 맨 위에 상황 요약이 짧게 붙어 있어서, 맥락을 알려고 스레드 전체를 거슬러 올라갈 필요가 없습니다. 요약을 읽고, 확인하고, 수정해서 보내면 됩니다.

Nakama가 처리한 일을 주간 로그로 보고, 각 작업을 제가 직접 했다면 걸렸을 시간으로 환산해 보면 이 팀은 제 업무 시간을 약 60시간 절약해 줍니다. 이렇게 생긴 시간은 에이전트가 (아직) 효과적으로 하지 못하는 일에 씁니다. 고객과의 대화, 아웃바운드 전략, 부서 간 프로젝트, 그리고 팀원이 자기 에이전트 팀을 만들도록 돕는 일입니다.

더 효율적으로 에이전트 설계하기

스케줄로 실행되는 에이전트는 제가 보든 말든 매일 돌아가므로 비용과 안정성 면에서 낭비가 쌓일 수 있습니다. 흔한 실수로는 기존 지침을 고치지 않고 계속 덧붙이는 것, 작업에 필요한 것보다 많은 컨텍스트를 주는 것, 모든 작업을 가장 큰 모델에서 가장 높은 effort 수준으로 돌리는 것이 있습니다.

에이전트의 효율을 지키는 요소는 대부분 팀 설계에서 나옵니다. 에이전트마다 업무가 하나라서 지침이 그 업무에 집중되어 있고, 실제 작업을 하는 에이전트는 스케줄에 따라 깨어나 한 번 일하고 멈추며, 에이전트끼리 메모리를 공유하므로 한 번 한 수정이 모든 곳에서 재사용됩니다.

또 하나의 큰 요소는 에이전트마다 어떤 모델을 쓰느냐입니다. 업무가 잘 정의되어 있으면 가장 성능 좋은 모델이 필요 없을 수도 있습니다. Furiwake와 Shoudan은 문서화된 규칙집을 따르므로 작은 모델인 Sonnet으로 실행합니다. Sabaki, Nokori, 코디네이터는 더 많은 판단이 필요한 일이라 큰 모델인 Opus로 실행합니다. 특히 코디네이터는 다른 에이전트의 지침을 수정하는데, 잘못된 수정 하나가 모든 에이전트에 영향을 주기 때문에 판단력이 가장 중요합니다. Henji도 고객마다 이메일이 달라서 Sabaki만큼 판단이 필요합니다. 하지만 근무 시간 내내 다른 어떤 에이전트보다 자주 실행됩니다. 매번 Opus로 돌리면 비용이 가장 많이 들기 때문에, Managed Agents의 어드바이저 전략을 씁니다. Henji는 Sonnet으로 실행하다가 혼자 결정하기 어려운 지점에 이르면 Opus에게 조언을 구합니다. 어드바이저는 Henji가 지금까지 한 작업을 읽고 계획, 수정 사항, 중단 신호 중 하나를 돌려보내고, Henji는 이를 바탕으로 초안을 마무리해 제 검토를 기다립니다. 에이전트별 effort 수준(모델이 답하기 전에 생각하는 시간)도 모델과 따로 설정하며, Henji의 답장처럼 추론이 어려운 곳에서만 높입니다.

제가 배운 것

자기만의 에이전트 팀을 만들려는 분께 전하고 싶은 세 가지입니다.

1. 매번 상세한 프롬프트가 필요하지는 않습니다. 업무를 한 번 설명하고, Claude가 초안을 쓰게 하고, 초안을 고친 뒤, 그 수정을 Claude가 기억하게 하세요.
2. 프롬프트보다 지식 베이스가 더 중요합니다. 모든 수정 사항과 과거 상호작용을 모든 에이전트가 읽고 쓸 수 있는 곳에 저장해 두면, Claude는 긴 프롬프트 대신 거기서 컨텍스트를 가져옵니다. 초안이 제 말투처럼 들리게 하려면 초안 작성, 수정, 저장을 값싸게 수백 번 반복해야 했습니다.
3. Claude에게 더 빨리, 더 많은 재량을 주세요. 처음에는 제가 해야 한다고 생각한 작업을 계속 직접 했습니다. 지식 베이스를 갱신하거나 각 에이전트의 지침을 손으로 편집하는 일이었습니다. 이 둘은 손을 놓고 나니 아무 문제 없이 잘 돌아갔습니다. 이제 에이전트가 배운 내용을 직접 지식 베이스에 기록하고, 코디네이터는 제가 평범한 말로 요청하면 다른 에이전트의 지침을 갱신합니다. 에이전트에게 맡겨도 될 일을 너무 조심스럽게 쥐고 있었던 셈입니다.

Claude Managed Agents 시작하기