How ShipStation Global built an AI IT help desk on Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

ShipStation Global은 Amazon Bedrock AgentCore 기반 Slack IT 지원 에이전트 Deckhand를 구축해 유입 채널 문의의 97.5%를 해결하고 직원 피드백에서 96%의 긍정 평가를 얻었다고 보고했다.

📌 핵심 요약

• ShipStation Global의 도움말 Slack 채널에는 출시 전 12개월 동안 1,500개 이상의 스레드가 올라왔고, 질문의 5분의 1 이상이 미국 업무시간 밖에 접수됐다. Confluence, 인트라넷, PDF, IT 가이드, 과거 Slack 대화에 흩어진 답변을 찾는 일이 주요 부담이었다.
• Deckhand는 Slack에서 IT·회사 관련 질문에 답하고 오류 메시지 스크린샷을 분석하며 Jira Service Management 티켓을 생성·수정한다. AWS App Runner의 Slack 서비스, Amazon Bedrock AgentCore runtime의 Strands 에이전트, AgentCore Gateway로 노출한 AWS Lambda 도구, Amazon Bedrock 지식 기반이 핵심 구성이다.
• Amazon Bedrock 지식 기반은 Confluence, 인트라넷, 해결된 Slack 지원 스레드 등을 활용한다. Slack 이력은 DSPy의 Recursive Language Model(RLM)과 Amazon Bedrock의 Claude로 처리하며, 스레드 안에 완전하고 실행 가능한 해결책이 보이는 경우만 해결된 것으로 인정하고 Pydantic으로 추출 결과의 구조를 검증한다.
• Deckhand는 공지·사교적 메시지·사람 간 대화에는 SKIP을 반환하고, 스레드에서는 최초 질문자에게만 응답한다. 다른 사람이 마지막으로 도움을 제공했거나 메시지가 특정인을 @지목하며 시작하면 침묵하며, 티켓 생성에는 명시적 확인이 필요하다.
• 원문은 Deckhand가 유입 채널 문의의 97.5%를 해결하고 직원에게서 96%의 긍정 피드백을 받았다고 보고하며, 관련 그림은 3개월간의 채널 커버리지와 긍정 피드백을 제시한다. 부정적 피드백은 DynamoDB에 질문·응답과 함께 저장해 프롬프트, 동작, 지식 기반 개선에 활용하지만, 보안·검증 절은 티켓 생성 확인 설명 도중 잘려 있다.

🧩 주요 포인트

1. 분산된 지식과 미국 업무시간 밖의 문의 → Slack 대화 안에서 답변하고 필요하면 Jira Service Management 티켓으로 이어지는 지원 방식이 반복 응대 부담을 줄이는 핵심이다.
2. RLM의 엄격한 해결 판정과 Pydantic 구조 검증 → 과거 Slack 대화를 재사용 가능한 지식으로 바꾸되, 불완전한 해결책이나 잘못 요약된 답변이 검색되는 위험을 줄이려는 설계다.
3. SKIP 규칙·사람의 개입 존중·명시적 티켓 생성 확인·부정적 피드백 활용 → 응답 범위와 실행 경계를 통제하면서 운영 중 오류를 개선하는 구조이며, 97.5%와 96%라는 성과 수치의 세부 산정 방식은 제공된 본문만으로 확인하기 어렵다.

🧠 상세 정리

1. 반복 문의와 분산된 정보가 만든 지원 부담

ShipStation Global은 중소 규모 발송업체를 위한 배송·물류 플랫폼으로, 내부 팀의 효율성이 고객에게 제공하는 서비스에도 연결된다는 관점에서 Deckhand를 개발했다. 출시 전 12개월 동안 도움말 Slack 채널에는 1,500개 이상의 스레드가 게시됐고 문의량도 계속 증가했으며, 미국·영국·스페인·폴란드·호주·필리핀에 직원이 있어 질문의 5분의 1 이상이 미국 업무시간 밖에 들어왔다. 답변은 이미 Confluence 문서, 인트라넷 페이지와 PDF, IT 가이드, 오래된 Slack 스레드에 존재하는 경우가 많았지만 이를 찾아 연결하는 일이 어려웠다. IT 선임 이사 Chris Collins는 티켓을 생산성보다 운영 마찰의 신호로 보고, Slack에서 질문하는 것만으로 도움을 받고 해결되지 않으면 맥락이 담긴 티켓으로 전환하는 경험을 지향했다고 설명했다.

2. Deckhand의 역할과 보고된 성과

Deckhand는 Slack 채널에 참여해 대화를 읽고 직원 프로필의 맥락을 활용하는 AI IT 지원 에이전트다. 선별된 지식 기반으로 일상적인 IT·회사 질문에 답하고, 오류 메시지 스크린샷을 읽으며, Jira Service Management 티켓을 생성하거나 수정한다. 답변을 찾으면 셀프서비스 절차를 제시하고, 찾지 못하면 추가 질문을 하거나 티켓 생성을 제안하므로 모든 문의를 즉시 해결할 수 있다고 전제하지 않는다. 원문은 유입 채널 문의의 97.5%를 해결했고 직원 피드백의 96%가 긍정적이었다고 보고하며, 해당 그림을 3개월간의 채널 커버리지와 긍정 피드백으로 소개한다. 다만 제공된 본문에는 해결 여부의 구체적인 판정 기준, 각 지표의 표본 수와 세부 산정 방식이 설명돼 있지 않아 이 수치의 해석에는 정보상 한계가 있다.

3. Slack에서 에이전트와 도구로 이어지는 구성

전체 구성은 Slack 서비스, 에이전트 서비스, 도구와 지식, 운영과 피드백이라는 네 부분으로 나뉜다. AWS App Runner에서 실행되는 FastAPI·Slack Bolt 애플리케이션은 Slack 이벤트를 받고 응답 필요 여부를 판단하며, 요청자의 이름·이메일·시간대·관리자를 포함한 사용자 맥락을 구성한다. Amazon Bedrock AgentCore runtime에 컨테이너로 배포한 Strands 에이전트는 Amazon Bedrock의 Anthropic Claude를 사용해 여러 차례 도구를 호출하는 추론 과정을 관리하고, 단일 AWS Lambda 함수는 AgentCore Gateway를 통해 MCP 도구로 노출된다. 지식 자료는 Amazon S3에 저장해 Amazon Bedrock 지식 기반에서 색인하며, 운영 측면에서는 DynamoDB가 피드백을 저장하고 AWS X-Ray가 OpenTelemetry로 요청 경로를 추적하며 각 서비스가 Amazon CloudWatch에 로그를 남긴다.

4. Strands 에이전트 구현과 요청 처리

구현 전제에는 Amazon Bedrock·AgentCore runtime·AgentCore Gateway 접근 권한이 있는 AWS 계정, 이벤트 구독과 서명 비밀값·봇 토큰을 갖춘 Slack 앱, 컨테이너 이미지 레지스트리, S3 버킷과 지식 기반이 포함된다. 각 런타임과 도구에 범위를 맞춘 IAM 역할, 외부 서비스 자격 증명을 위한 AWS Secrets Manager 항목도 필요하다. 에이전트 자체는 Strands Agents SDK의 모델·도구·시스템 프롬프트로 간결하게 구성하며, 예제 모델 설정은 max_tokens 2048과 temperature 0.3이고 모델 ID는 환경 변수로 지정해 애플리케이션 코드 변경 없이 교체할 수 있다. 지식 검색은 Strands의 기본 검색 도구로 연결하고 분류·티켓 관리·사용자 식별·이미지 분석은 Gateway 뒤의 Lambda로 분리하므로 도구 로직을 독립적으로 수정하고 에이전트를 다시 빌드하지 않고도 새 도구에 접근할 수 있다. Slack 서비스는 매 메시지마다 전체 스레드와 사용자 맥락을 전달해 runtime API를 동기 호출하고 최종 응답을 게시하며, 관리형 runtime은 서버와 세션 관리 부담을 줄이고 직원 프로필은 티켓 세부 정보의 자동 완성에 쓰인다.

5. 단일 지식 기반과 문서 메타데이터

Deckhand는 단일 Amazon Bedrock 지식 기반을 사용하며, 주요 S3 기반 자료원은 Confluence에서 동기화한 문서, 인트라넷의 내부 페이지·PDF·이벤트, 해결된 Slack 지원 스레드다. 전체 구성 설명에는 마케팅 페이지도 색인 대상으로 언급되지만, 지식 기반 설계 절에서는 앞의 세 자료원을 중심으로 설명한다. 각 문서에는 제목, 출처 URL, 콘텐츠 유형, 이벤트 날짜 같은 메타데이터가 포함돼 에이전트가 질문의 맥락에 맞게 자료를 필터링할 수 있다. 원문은 그 사례로 예정된 행사나 Austin 사무실의 주간 점심 메뉴에 관한 질문을 제시한다. 이는 IT 문제 해결뿐 아니라 회사 내부 정보 탐색도 지원한다는 의미이며, 여러 위치에 흩어진 자료를 하나의 검색 경로로 연결하면서 문서의 출처와 시간 정보를 함께 활용하는 구성이다.

6. Slack 이력의 가치와 엄격한 해결 판정

원문은 해결된 지원 스레드의 아카이브를 가장 가치 있는 자료원으로 본다. 직원이 문제를 설명하고 IT 담당자가 해결을 도운 대화에는 실제로 적용된 해결책이 남아 있지만, 원시 내보내기에는 잡담·자동 알림·미해결 스레드도 섞여 있다. 검증되지 않은 해결책이나 왜곡된 요약을 색인하면 잘못된 답변도 올바른 답변과 같은 확신으로 제시될 수 있으므로, 추출의 정확성을 핵심 조건으로 둔다. 첫 단계에서는 스크립트가 Slack API로 채널 전체 이력과 각 스레드의 모든 답글을 가져와 스레드 표식·타임스탬프·답글 수가 포함된 구조화 자료를 만든다. 다음 단계에서 Amazon Bedrock의 Claude를 사용하는 DSPy RLM이 공지와 질문이 아닌 내용을 제외하고 스레드를 해결·미해결·상위 지원으로 이관된 경우로 분류하며, 완전하고 실행 가능한 해결책이 스레드 자체에 나타날 때만 해결된 것으로 인정한다.

7. RLM의 재귀 추출과 구조 검증

RLM은 전체 Slack 내보내기를 하나의 프롬프트에 넣는 대신, 샌드박스 Python REPL 안에서 탐색할 수 있는 메모리 공간으로 취급한다. 전체 이력을 지속되는 변수 공간에 유지하며 반복적으로 살펴볼 수 있다는 점과 일관된 출력 구조를 확보할 수 있다는 점이 선택 이유로 제시된다. 해결된 스레드에서는 재귀적인 하위 LLM 호출로 문제 요약·원래 질문·해결책을 추출하고, 셀프서비스 가능 여부와 티켓 필요 여부, 실행 단계, 관련 애플리케이션·시스템, 오류 메시지, 태그도 구조화한다. 각 결과는 Pydantic 모델로 검증하며, 스키마를 충족하지 못하면 코드 기반 반복 과정이 인터프리터에서 검증 오류를 포착해 재시도한다. 최종 결과는 문제별로 정리한 Markdown 문서로 작성해 S3에 업로드하고 지식 기반이 색인하므로, 이후 비슷한 문제를 겪는 직원에게 과거 해결책을 번호가 매겨진 실행 단계로 제공할 수 있다.

8. 공유 채널에서 응답을 자제하는 규칙

원문은 공유 채널의 AI 봇이 기술적으로 실패하기 전에 사회적으로 실패할 수 있다고 보고, 언제 답하지 않을지를 결정하는 로직을 특히 정교하게 다듬었다고 설명한다. 에이전트는 각 메시지가 공지·사교적 메시지·사람 사이의 대화인지 먼저 판단하고, 해당하면 SKIP을 출력해 Slack 서비스가 응답을 게시하지 않도록 한다. 스레드에서는 최초 질문자에게만 답하고, 마지막 답변을 다른 사람이 제공했다면 사람이 지원을 맡은 것으로 보고 침묵한다. 메시지가 특정인을 @지목하며 시작하는 경우에도 봇에게 보내는 요청이 아니라고 판단한다. 이 규칙들은 질문의 내용에 맞는 답을 생성하는 능력과 별개로, 대화 상대와 사람의 개입 여부를 기준으로 응답 범위를 제한하며 Deckhand가 기존 Slack 지원 대화에 끼어드는 문제를 줄이려는 설계다.

9. 피드백을 통한 개선과 보안 설명의 한계

각 답변에는 피드백 버튼이 붙고, 긍정 평가는 바로 기록되며 부정 평가에는 무엇이 잘못됐는지 짧게 적는 입력란이 추가된다. 평가는 원래 질문과 봇의 응답을 함께 DynamoDB에 저장하므로, 부정적 피드백을 시스템 프롬프트와 에이전트 동작을 개선하고 잘못된 지식 기반 정보를 수정하는 자료로 활용할 수 있다. 보안·검증 절에서는 프롬프트 규칙이 행동을 개선해도 접근 통제를 대체하지 못하며, 실제 강제는 코드와 인프라가 담당한다고 명시한다. 이어 티켓 생성에는 명시적 확인이 필요하다고 설명하지만, 제공된 원문은 그 다음 문장 도중에 끝난다. 따라서 티켓 생성 확인이라는 요건은 확인할 수 있으나, 구체적인 확인 절차와 그 밖의 보안 통제가 어떻게 구현되는지는 이 자료만으로 판단할 수 없다.

🧾 핵심 주장 / 시사점

• Deckhand 사례는 답변 생성 모델뿐 아니라 분산된 내부 자료를 연결하고 실제 해결된 대화를 엄격하게 선별하는 과정이 지원 품질의 중요한 기반임을 보여준다.
• 공유 Slack 채널에서는 응답 정확성과 함께 응답 시점도 중요하다. SKIP과 사람의 개입을 존중하는 규칙은 에이전트가 기존 지원 관계 안에서 작동하도록 하는 설계 요소다.
• Pydantic 검증은 추출 결과의 구조를 확인하는 장치이며, 해결책의 내용 품질은 별도의 엄격한 해결 판정에 의존한다. 보고된 성과를 평가할 때도 이 구분과 지표 산정 정보의 한계를 함께 고려할 필요가 있다.

✅ 액션 아이템

• 97.5%의 문의 해결률과 96%의 긍정 피드백을 평가할 때 표본 수, 해결 판정 기준, 세부 산정 방식 확인이 필요함.
• Slack 이력 활용 시 RLM의 완전하고 실행 가능한 해결책 기준과 Pydantic 구조 검증을 함께 적용하는 방식 검토.
• Deckhand의 운영 범위 검토에 SKIP 규칙, 사람의 개입 시 침묵, 티켓 생성의 명시적 확인을 반영하고, 부정적 피드백을 프롬프트·동작·지식 기반 개선에 활용.

❓ 열린 질문

• 97.5%의 문의 해결률과 96%의 긍정 피드백은 각각 어떤 표본과 판정 기준으로 산정됐는가?
• RLM은 Slack 스레드에 완전하고 실행 가능한 해결책이 있다는 기준을 실제로 얼마나 정확하게 적용했는가?
• Deckhand의 티켓 생성에 필요한 명시적 확인은 어떤 절차로 구현됐는가?