Claude Managed Agents로 「먼저 엔지니어에게 물어보자」를 「먼저 bot에게 물어보자」로 바꾸다

서론

Dinii에서는 개발 팀 앞으로 오는 질문(사내에서는 dev-help라고 부릅니다)이 하루에 8건 정도 들어옵니다. 건당 10분이라도 쌓이면 한 달에 수십 시간이 사라집니다. 지난 기사에서는 과거의 dev-help 티켓을 RAG(과거 문서를 의미 검색으로 가져오는 메커니즘)로 검색하여 관련 사례를 스레드에 붙여주는 bot을 만들어, 리드 타임 중앙값을 10일에서 5시간까지 단축했습니다.

하지만 구조상 도저히 포착할 수 없는 영역이 남아 있었습니다. 「현재의 데이터·로그·코드를 사람이 직접 읽으러 가지 않으면 답이 나오지 않는」 타입의 문의입니다.

이번에 만든 @ask-anything는 이 영역을 포착하기 위해 설계한 Slack bot입니다. 실제 스레드를 하나 먼저 보여드리겠습니다. 이전 같았으면 「먼저 엔지니어에게 물어보자」라며 dev-help가 생성되었을, 매장 운영 담당자의 조작 로그 확인 요청입니다.

@ask-anything 어제 ◯◯점의 객수를 알려줘

라고 던지면, bot이 BigQuery를 구성하여 결과를 반환합니다. 에러 조사라면 Cloud Logging을 읽고, 코드 조사라면 Dinii의 monorepo를 grep 하여 근본 원인에 대한 가설까지 반환합니다. 구현은 Anthropic Claude Managed Agents가 중심입니다.

본 기사는 **「무엇을 할 수 있게 되었고, 개발 조직에 어떤 효과가 나타났는가」**를 다루며, 기술적인 상세 내용은 별도의 기사(곧 공개 예정)로 나누어 두었습니다.

1. ask-anything가 할 수 있게 된 것

ask-anything가 포착하는 것은 과거 사례의 검색이 아니라 **「현재의 시스템을 read-only로 조사하는 태스크」**입니다. 구체적으로는 다음 3가지 유형으로 나뉩니다.

1.1 데이터 조사

예: 「◯◯점의 어제 객수를 알려줘」「최근 7일간의 재방문율은?」「특정 매장의 shopId를 알려줘」

이전에는 → 엔지니어가 BigQuery를 열고, 테이블 정의를 확인하고, SQL을 작성하여 실행하기까지 건당 10~15분이 소요되었습니다.

도입 후 → 스레드에 질문을 던지면, bot이 SQL을 구성하고, dry-run으로 비용을 체크한 뒤, 실제로 실행하여 결과를 Slack에 정형화하여 반환합니다. 건당 1~2분 내에 완결될 수 있게 되었습니다.

1.2 로그·이력 조사

예: 「◯◯점의 레지 개폐 기록을 CSV로 줘」「매장에서 『△△ 조작이 안 된다』는 문의가 왔는데, 무슨 일이 일어났지?」「결제가 가끔 실패한다는 보고가 들어왔는데, 원인은?」

이전에는 → 매장 운영 / Customer Success 담당자가 엔지니어에게 요청을 전달하면, 엔지니어가 Cloud Logging을 열어 filter를 구성하거나, BigQuery에서 조작 로그를 SQL로 추출하여 CSV로 만드는 작업이 필요하여 건당 15~30분 + 대기 시간이 소요되었습니다.

도입 후 → bot이 Cloud Logging / BigQuery를 직접 호출하고, 시계열로 읽어 들여, 필요하다면 CSV로 만들어 Slack에 upload 해주기 때문에 건당 1~3분 내에 완결될 수 있게 되었습니다.

1.3 사양·버그 확인

예: 「이 기능, 현재 사양은 어떻게 되어 있어?」「매장에서 『◯◯하면 △△가 발생한다』고 하는데, 이게 버그야? 아니면 사양대로야?」「이 버튼을 눌렀을 때의 동작을 알려줘」

이전에는 → PdM / CS / 매장 운영 담당자가 엔지니어에게 질문을 전달하면, 엔지니어가 IDE에서 관련 코드를 grep 하고, 의존 관계를 따라가며 사양과 구현을 대조합니다. 답변까지 수십 분~수 시간(엔지니어의 업무 여유가 생길 때까지의 대기 시간 포함)이 걸렸습니다.

도입 후 → bot이 Anthropic 측의 작업 환경에 Dinii의 monorepo를 read-only로 배치하고, 내부에서 rg로 grep 합니다. 스레드에 관련 파일·해당 처리의 요약 + 「사양대로 / 버그 가능성 있음」의 판단 근거가 반환됩니다.

모두 「과거 사례의 검색」이 아니라, 도구를 여러 번 사용하며 조사를 완수하는 타입의 업무입니다. RAG 기반의 bot이 커버할 수 없었던, 인력 대행이 길게 남아있던 영역이었습니다.

2. Claude Managed Agents의 개요

2.1 왜 자체 오케스트레이션(Orchestration)을 버렸는가

이전의 RAG bot은 Mastra(TypeScript 기반의 AI orchestration framework)로 구축했습니다. Anthropic SDK를 직접 호출하여, "LLM의 출력 → 도구 호출 (Tool Call) → 실행 결과를 LLM에 다시 전달"하는 루프를 직접 100줄 정도 작성하는 구성입니다.

하지만, ask-anything에 필요한 도구의 종류와 수는 이전과는 비교할 수 없을 정도입니다.

BigQuery (쿼리 실행 · dry-run · CSV 내보내기)
Cloud Logging (필터 구성 · 시계열 읽기)
Dainy의 monorepo (세션별로 clone 하여 grep)
Notion (회의록 · 운영 문서 · dev-help 과거 사례 DB)
GitHub / Sentry / Slack / channel-talk (외부 SaaS 데이터 참조)

이 모든 것에 대해 "직접 어댑터(Adapter)를 작성한다", "직접 자격 증명(Credential)을 로테이션한다", "직접 재시도(Retry) / 스트림 끊김 핸들링을 작성한다"는 방침을 세울 수도 있습니다. 하지만 그렇게 되면 본래 프롬프트 (Prompt) 설계에 할애하고 싶은 시간이 정형화된 "연결" 코드를 작성하는 데 흡수되어 버립니다.

2.2 Claude Managed Agents란

Claude Managed Agents는 Anthropic이 제공하는 Claude API의 상위 기능입니다.

간단히 말하면, "몇 가지 도구를 등록한 Claude"를 Anthropic 측에서 호스팅해 주는 메커니즘입니다. 사용자는 Slack 등의 이벤트를 Anthropic에 중계하기만 하면, 에이전트 (Agent)가 자율적으로 도구를 호출하여 답변을 구성해 줍니다.

중요한 포인트는 3가지가 있습니다.

기능	이점
Anthropic 측에 sandbox(에이전트가 스스로 코드 및 명령어를 실행할 수 있는 작업 환경)가 준비되어 있음	"직접 코드를 작성하여 실행한다", "파일을 저장해 둔다"를 에이전트 단독으로 수행할 수 있으므로, 직접 실행 환경을 준비할 필요가 없음
...

2.3 직접 작성하는 코드는 3종류로 줄었다

ask-anything를 Claude Managed Agents로 다시 구축한 결과, Dainy 측에서 계속 작성하고 있는 코드는 3종류로 수렴했습니다.

Slack으로부터 이벤트를 받는 얇은 HTTP handler
Claude Managed Agents의 세션(Session)을 생성하고 이벤트를 중계하는 relay
에이전트로부터 호출되는 커스텀 도구 (Custom Tool)의 구현 본체 (BigQuery 실행, Cloud Logging 실행, CSV 업로드 등)

"Dainy만의 비즈니스 로직 (Business Logic)"이라고 부를 수 있는 것은 3번째뿐이며, 1번과 2번은 거의 디스패처 (Dispatcher)입니다. 지난번 Mastra로 작성했던 오케스트레이션 (Orchestration) 코드 중, 체감상 70% 정도가 불필요해졌습니다.

구현의 세부 사항이나 함정(GCP 자격 증명을 sandbox에 전달할 수 없는 문제, MCP server URL의 trailing slash 하나 때문에 자격 증명을 찾지 못하게 되는 함정 등)은 별도의 기사(곧 공개 예정)에 작성해 두었습니다.

3. 실제로 어떻게 변했는가 (KPI로 확인)

ask-anything는 2026년 4월 말부터 본격 가동을 시작했습니다. 사내 KPI 대시보드를 통해 주간 트렌드를 관찰하고 있습니다.

3.1 ask-anything가 답변하는 스레드 수

bot이 답변한 스레드 수의 주간 추이입니다.

주차	bot 참여 스레드 수
4/27 주 (본격 가동 시작)	24
...

도입 직후 주간 24건에서 4주 만에 약 4.5배까지 성장했습니다. 스킬 (Skill) / 프롬프트 (Prompt)의 시행착오를 거듭하며 대응 가능한 유스케이스 (Use Case)의 범위를 넓혀온 결과입니다.

3.2 dev-help 티켓 생성 수

dev-help는 "개발 팀에 대한 정식 문의"를 관리하는 Notion DB입니다. 여기에 생성되는 건수(= 개발 팀 멤버가 확인하고 대응해야 하는 문의 건수)의 추이를 보면 변화를 쉽게 알 수 있습니다.

기간	dev-help 티켓 생성 수 / 주
도입 전 4주 (3/30~4/20)	36~49건 (평균 약 45건)
...
ask-anything 본격 가동 후에는 주 20~~30건대로 낮아졌습니다. 도입 전의 주 40~~50건과 비교하면, 거의 절반으로 감소했다는 결과입니다.

질문의 절대수가 줄어든 것이 아니라 (Slack의 질문 총수는 오히려 늘어나고 있습니다), "개발 팀에 정식 티켓화되기 전에 bot이 답변을 제공하고 있는" 양이 늘어났다는 의미입니다.

3.3 에스컬레이션율 (Escalation Rate)

"ask-anything가 답변한 스레드 중, 결국 dev-help 티켓으로 전환된 비율"을 에스컬레이션율 (Escalation Rate)로 관찰하고 있습니다. 이는 bot의 답변 품질 (사람의 개입 없이 완결되었는지 여부)을 측정하는 지표입니다.

주	에스컬레이션율
4/27 주 (도입 직후)	100% (거의 전 건 티켓화)
...
도입 직후에는 아직 bot의 답변 정밀도가 낮아, 사람이 팔로업하여 dev-help를 생성하는 것이 거의 매번 필요했습니다. skill 정비 및 custom tool의 정밀도 향상을 진행한 결과, 5/18 주에는 "ask-anything가 답변한 스레드 중 약 80%는 추가적인 티켓화가 불필요"한 상태까지 도달했습니다.

4. 요약 및 다음 기사

ask-anything 운영 4주 동안 확인된 성과를 정리하면 다음과 같습니다.

bot이 처리하는 스레드 수: 0 → 주 109건까지 급격히 상승
dev-help 티켓 생성 수: 주 40~~50건 → 주 20~~30건 (거의 절반 감소)
에스컬레이션율: 100% → 22% (bot 단독 완결률 개선)

개발 팀에 대한 문의가 절반으로 줄어들면, 엔지니어가 본래의 구현 업무에 집중할 수 있는 시간이 늘어납니다. Claude Managed Agents의 구체적인 구현 패턴에 관심이 있는 분들은 꼭 후속 기사도 기다려 주시기 바랍니다.