이 글은 ShipStation Global의 Kenneth Salmon, Edward Boswell, Jack Armstrong, Robert Bahn, Nick Ciubotariu와 공동으로 작성했습니다.
동일한 IT 질문에 답변하고 일상적인 티켓을 처리하는 일은 IT 팀이 다른 곳에 쓸 수 있는 시간을 소모시킵니다. 이 시간을 되찾기 위해 ShipStation 글로벌 엔지니어링 팀은 다음을 구축했습니다 갑판원(Deckhand)", Slack용 AI 기반 IT 헬프데스크 에이전트를"], Amazon Bedrock AgentCore.
ShipStation 글로벌 중소 화주를 위한 선도적인 지능형 배송 및 물류 플랫폼으로서, 팀이 효율적일수록 고객에게 더 나은 서비스를 제공할 수 있다는 간단한 믿음 위에서 운영됩니다. Deckhand는 그 믿음을 실천합니다. 선별된 지식 베이스에서 일상적인 IT 및 회사 관련 질문에 답하고, 오류 메시지 스크린샷을 읽으며, Jira Service Management 티켓을 생성하고 업데이트합니다.
이 글에서는 ShipStation이 Deckhand를 어떻게 설계했는지 다룹니다. 그 결과로 들어오는 채널 문의의 97.5 퍼센트를 해결했고 직원들로부터 96 퍼센트의 긍정적 피드백 평점을 받았습니다(그림 1).
그림 1: 3개월 채널 커버리지 및 긍정적 피드백
비즈니스 과제
Deckhand가 해결하는 문제는 모든 IT 팀이 공감할 수 있는 것입니다. 즉, 똑같은 질문이 반복적으로 제기되고, 업무 시간 이후에 오류 메시지가 게시되며, 여러 팀으로부터 정보를 수집해야 하는 상황입니다. ShipStation Global에서는 이러한 대화들이 분주한 헬프데스크 Slack 채널에서 이루어졌고, 직원들이 질문하면 IT가 한 스레드씩 답변했습니다. 답변은 대개 Confluence 사용 방법 문서, 회사 인트라넷 페이지, 또는 8개월 전의 스레드에 이미 존재했습니다. 그것을 찾아내는 것이 어려운 부분이었습니다.
이 채널 데이터는 그 규모를 구체적으로 보여주었다. 출시 전 12개월 동안:
- 직원들이 1,500개가 넘는 스레드를 게시했고, 게시량은 계속 증가했습니다.
- 미국, 영국, 스페인, 폴란드, 호주, 필리핀에 직원들이 있어서 질문의 5분의 1 이상이 미국 업무 시간 외에 접수되었습니다.
- 답변이 여러 곳에 흩어져 있었습니다: Confluence 문서, 인트라넷 페이지와 PDF, IT에서 관리하는 가이드, 그리고 해당 채널 자체의 기록 등이 그곳이었습니다.
- 반복적인 질문들이 구조화된 셀프서비스 단계로 처리할 수 있었던 시간을 소모했습니다.
“저희는 도움을 받는 일이 티켓 양식을 해독하거나 허공으로 이메일을 보내는 것이 아니라 Slack에서 질문을 던지는 것만큼 간단해야 한다고 생각해서 Deckhand를 만들었습니다. 저희는 티켓이 업무 생산성이 아니라 운영상의 마찰을 나타내는 지표라고 믿습니다. Deckhand는 일반적인 질문을 그 자리에서 해결하고, 해결하지 못할 때는 클릭 한 번으로 대화를 완전한 맥락을 갖춘 티켓으로 전환하여 직원 경험을 개선하고 저희 팀이 ‘티켓을 제출해 주세요.’라는 말을 끝없이 반복하는 일에서 벗어나게 해 줍니다.”
— Chris Collins, ShipStation Global 수석 IT 디렉터
솔루션 개요
Deckhand는 Slack에서 팀원처럼 작동합니다. 채널에 참여하고, 대화를 읽고, Slack 프로필에서 맥락을 파악하여 IT 관련 질문을 그 자리에서 답변합니다. 우리는 Amazon Bedrock AgentCore, 즉 모든 프레임워크나 모델을 사용해 대규모로 에이전트를 구축, 연결, 최적화할 수 있는 플랫폼에서 이를 운영합니다. Amazon Bedrock AgentCore의 기능인 AgentCore runtime은 격리된 세션에서 에이전트를 호스팅하므로, 우리는 서버나 컨테이너를 직접 운영하지 않아도 됩니다.
이 솔루션은 그림 2에 표시된 네 가지 주요 구성 요소로 이루어져 있습니다:
- Slack 서비스: FastAPI와 Slack Bolt 애플리케이션으로, 다음에서 호스팅됩니다: AWS App Runner. Slack 이벤트를 수신하고, 봇이 응답해야 하는지 판단하며, 요청자의 Slack 프로필에서 이름, 이메일, 시간대, 상사를 포함한 사용자 컨텍스트 페이로드를 구성합니다.
- 에이전트 서비스: Strands 에이전트로, 컨테이너로 배포되어 Amazon Bedrock AgentCore 런타임에서 Anthropic의 Claude를 사용하여 다중 턴 도구 에이전트 루프를 관리합니다. Amazon Bedrock.
- 도구 및 지식: 하나의 AWS Lambda 기능이며, Model Context Protocol(MCP) 도구로 노출됩니다. AgentCore GatewayAmazon Bedrock AgentCore의 기능인 는 요청을 분류하고, Jira 티켓을 생성·업데이트하며, 이미지를 분석합니다. An Amazon Bedrock 지식 베이스 Confluence, 사내 인트라넷, Slack, 마케팅 페이지의 콘텐츠를 색인하여 다음에 저장합니다: Amazon Simple Storage Service (Amazon S3).
- 운영 및 피드백. Amazon DynamoDB 피드백을 저장하며, AWS X-Ray OpenTelemetry를 사용하여 요청 경로를 추적하며, 서비스들은 다음에 로그를 기록합니다 Amazon CloudWatch.
그림 2: Slack 이벤트가 Slack 서비스 및 Amazon Bedrock AgentCore 런타임으로 들어가고, Amazon Bedrock 지식 기반, AgentCore Gateway 기반 Lambda 도구, Jira Service Management, DynamoDB 피드백으로 각각 별도의 경로가 이어지는 것을 보여주는 아키텍처 다이어그램.
직원이 Deckhand가 속해 있는 채널에 게시하면 Slack 서비스가 전체 스레드 기록과 사용자 컨텍스트를 취합합니다. 그런 다음 AgentCore 런타임 API를 통해 에이전트를 호출합니다. 에이전트는 지식 베이스를 검색하고 필요에 따라 도구를 호출합니다. 답을 찾으면 최종 응답을 반환하고(그림 3), 찾지 못하면 명확히 하는 질문을 하거나 티켓 생성을 제안합니다(그림 4).
그림 3: Deckhand가 셀프 서비스 단계로 응답함
Figure 4: Deckhand가 티켓 생성을 제안하는 모습
갑판원 워크플로우
이 섹션에서는 전제 조건부터 실제 배포까지 Deckhand가 구현되는 방식을 단계별로 살펴봅니다.
필수 조건
이 패턴을 구현하려면 다음이 필요합니다:
- Amazon Bedrock, AgentCore 런타임, AgentCore Gateway에 액세스할 수 있는 AWS 계정.
- 이벤트 구독, 서명 시크릿, 그리고 사용 사례에 맞게 범위가 지정된 봇 토큰을 갖춘 Slack 앱.
- Amazon Elastic Container Registry(Amazon ECR)와 같은 컨테이너 이미지 레지스트리.
- Amazon S3 버킷과 Amazon Bedrock 지식 기반이 필요합니다.
- 각 런타임 및 도구에 범위가 지정된 AWS Identity and Access Management(IAM) 역할과 서드파티 자격 증명을 위한 AWS Secrets Manager 항목입니다.
Strands Agents와 AgentCore로 에이전트 구축하기
이 에이전트는 의도적으로 가볍게 설계되었습니다. 오픈 소스 Strands Agents SDK, 에이전트는 모델, 도구 집합, 시스템 프롬프트로 구성됩니다. SDK는 추론 루프를 관리하여 모델이 도구를 선택하고, 결과를 처리하고, 답을 산출할 때까지 반복할 수 있도록 합니다. Deckhand의 에이전트 서비스는 몇 줄의 Python으로 구현되어 있습니다.
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client
model = BedrockModel(
model_id=MODEL_ID,
max_tokens=2048,
temperature=0.3,
)
gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))
agent = Agent(
model=model,
tools=[gateway, retrieve],
system_prompt=SYSTEM_PROMPT,
)모델 ID는 환경 변수를 통해 설정되며, 이를 통해 애플리케이션 코드를 수정하지 않고도 모델을 전환할 수 있습니다.
도구는 두 가지 방식으로 에이전트에 통합됩니다. Amazon Bedrock Knowledge Bases 검색은 단일 임포트로 지식 베이스 검색을 지원하는 네이티브 Strands 도구입니다. 분류, 티켓 관리, 사용자 확인, 이미지 분석을 포함한 다른 기능들은 AgentCore Gateway에 등록된 Lambda 함수로 처리됩니다. Gateway는 이들을 MCP 도구로 노출하며, Lambda는 도구 이름별로 각 호출을 라우팅합니다. 이러한 분리를 통해 도구 로직을 독립적으로 업데이트할 수 있으며, 에이전트는 재빌드 없이도 Gateway에서 새로운 도구에 접근할 수 있습니다.
AgentCore 런타임은 에이전트를 컨테이너로 호스팅하여 서버나 세션 관리의 필요를 없애줍니다. Slack 서비스는 각 메시지마다 에이전트를 동기적으로 호출하여 스레드 대화 기록과 사용자 컨텍스트를 전달하고, 최종 응답을 게시합니다. 직원 프로필을 포함한 컨텍스트가 모든 요청에 함께 포함되므로, 에이전트는 티켓 세부 정보를 자동으로 완성할 수 있습니다.
지식 베이스 설계 및 답변 라우팅
Deckhand은 핵심 S3 기반 데이터 소스를 갖춘 단일 Amazon Bedrock 지식 기반에서 답변을 제공합니다:
- Confluence에서 동기화된 문서입니다.
- 회사 인트라넷에서 동기화된 내부 페이지, PDF 및 이벤트입니다.
- 다음 섹션에서 다루는 Slack에서 수집된 해결된 지원 스레드입니다.
각 문서에는 제목, 원본 URL, 콘텐츠 유형, 행사 날짜 등의 메타데이터가 포함되어 있습니다. 이를 통해 에이전트는 콘텐츠를 필터링할 수 있습니다. 예를 들어 사용자가 다가오는 행사나 Austin 사무실의 주간 점심 메뉴에 대해 질문할 때 유용합니다.
RLM(Recursive Language Models, 재귀 언어 모델)로 Slack 히스토리 마이닝하기
가장 가치 있는 데이터 소스는 해결된 지원 스레드의 아카이브입니다. Deckhand가 존재하기 전에는 Slack이 문제가 해결되던 곳이었습니다. 직원들이 수년간 문제를 설명하고 IT가 해결 방법을 안내한 기록이 쌓여 있었죠. 그 히스토리는 최고의 검토자, 즉 문제가 해결된 당사자가 검증한 유기적인 지식 베이스입니다. 하지만 동시에 잡음도 많습니다. 원본 내보내기에는 잡담, 자동 알림, 실제로는 해결되지 못한 스레드가 뒤섞여 있습니다. 검증되지 않은 해결책이나 엉터리 요약을 인덱싱하면 지식 베이스가 잘못된 답을 올바른 답과 동일한 신뢰도로 제시하게 되므로, 추출 과정은 정밀해야 합니다.
마이닝 프로세스는 3단계 파이프라인을 따릅니다(그림 5):
- 스크립트가 Slack API를 통해 채널의 전체 히스토리를 내보내며, 모든 스레드의 전체 답글을 가져와 스레드 마커, 타임스탬프, 답글 수가 포함된 구조화된 덤프를 작성합니다.
- Amazon Bedrock에서 Claude를 구동하는 DSPy의 Recursive Language Model(RLM)은 그 내보내기를 단일 프롬프트가 아니라 샌드박스 처리된 Python read-eval-print loop(REPL) 안에서 탐색 가능한 메모리 공간으로 취급합니다. 데이터를 반복적으로 처리하면서 각 스레드를 해결됨, 미해결, 에스컬레이션으로 분류하고 공지와 질문이 아닌 항목을 걸러냅니다. 엄격한 기준이 품질을 높게 유지합니다. 스레드 자체 안에 완전하고 실행 가능한 해결책이 보이는 경우에만 해결됨으로 간주됩니다.
- 해결된 스레드마다 RLM은 재귀적으로 sub-LLM(대규모 언어 모델) 호출을 오케스트레이션하여 구조화된 필드를 추출하며, 각 필드는 Pydantic 모델로 검증됩니다. 필드에는 이슈 요약, 원래 질문, 해결 내용이 포함됩니다. 또한 수정이 셀프 서비스로 가능한지 티켓이 필요한지, 셀프 서비스 절차, 관련 애플리케이션과 시스템, 오류 메시지, 태그를 기록합니다. sub-LLM 호출이 스키마에 맞지 않는 결과를 반환하면 RLM의 코드 기반 루프가 인터프리터에서 검증 오류를 잡아 재시도합니다. 결과는 이슈별로 정리된 markdown 문서로 작성됩니다. 파이프라인은 이 문서를 Amazon S3에 업로드하여 지식 베이스가 인덱싱하도록 합니다.
Figure 5: Slack 대화의 내보내기 분류 및 추출 워크플로
우리는 RLM 을 선택했습니다. RLM은 전체 Slack 기록을 지속적인 샌드박스 변수 공간에 유지하므로 내보내기 데이터에 대한 반복적 추론과 일관된 출력 구조가 가능하기 때문입니다. 그 결과, 직원이 동료가 이전에 해결한 문제에 부딪히면 Deckhand가 검증된 해결책을, 종종 실행 가능한 번호가 매겨진 단계 형태로 제공합니다.
답변하지 말아야 할 때 아는 법
공유 채널의 AI 봇은 기술적으로 실패하기 전에 사회적으로 실패합니다. Deckhand의 가장 정교한 로직은 언제 조용히 있을지 결정합니다:
- 에이전트는 모든 메시지에 대해 첫 번째 결정으로 그것이 공지, 소셜 메시지, 또는 사람들 간의 대화인지 판단합니다. 그렇다면 “SKIP”을 출력하고 Slack 서비스가 답장을 억제합니다.
- 스레드에서는 원래 작성자에게만 답장합니다.
- 마지막 답장이 다른 사람 helper로부터 온 것이라면 조용히 있습니다. 사람이 이미 처리를 맡았기 때문입니다.
- 답장이 @멘션으로 특정 사람을 지정하며 시작한다면 그 메시지는 봇을 위한 것이 아닙니다.
피드백 수집
각 답변에는 피드백 버튼이 포함됩니다. 좋아요는 바로 기록되며, 싫어요는 간단한 “무엇이 잘못되었나요” 필드를 요청합니다. 평점은 원래 질문과 봇의 응답과 함께 DynamoDB에 저장됩니다.
부정적 피드백은 시스템 프롬프트와 에이전트 행동을 개선하고 잘못된 지식 베이스 정보를 갱신하는 데 사용되는 귀중한 데이터셋입니다.
보안 및 검증
프롬프트 규칙은 행동을 강화하지만 접근 제어를 대체하지는 않습니다. 강제 적용은 코드와 인프라를 통해 관리됩니다:
- 티켓 생성에는 명시적인 확인이 필요합니다. Deckhand가 티켓 생성을 제안하면 Slack 서비스가 Create Ticket 버튼을 추가하고, 이를 선택하면 에이전트를 통해 확인이 전송됩니다. 티켓 업데이트는 헬프데스크 프로젝트 패턴과 일치하는 유효한 키만 허용하고 빈 댓글은 거부합니다.
- 분류는 실행 전에 검증됩니다. 요청 분류는 별도의 Amazon Bedrock Converse API 호출로 실행되어 구조화된 티켓 필드를 반환하며, Jira에 도달하기 전에 Pydantic으로 검증됩니다.
- 이미지 도구는 Slack의 파일 호스트에서만 다운로드하도록 제한됩니다. 봇 토큰으로 인증하고, 각 요청을 최대 5 MB 크기의 이미지 5개로 제한하며, Converse API를 사용해 파일을 비전 모델로 전송합니다.
- 자격 증명은 코드 밖에 유지됩니다. Slack 토큰, 서명 시크릿, Jira 자격 증명은 AWS Secrets Manager에 보관되며, 각 서비스와 도구는 자체 범위의 IAM 역할로 실행됩니다.
- 프롬프트는 행동 안전장치를 강제합니다: 비밀번호나 다단계 인증(MFA) 코드를 절대 요청하지 않고, 티켓 댓글에 자격 증명을 절대 작성하지 않으며, 티켓 필드에 사용되는 프로필 메타데이터를 절대 노출하지 않습니다.
성과
Deckhand는 2026년 4월에 출시되었습니다. 하루 약 30개의 메시지로 시작하여 초여름까지 100개에 도달했습니다. 첫 3개월 동안 1,935개의 메시지를 처리하고, 1,221개의 에이전트 대화를 시작했으며, 409개의 Jira 티켓을 생성했습니다. 메시지의 97.5 퍼센트에 답장했습니다. 질문의 3분의 1은 IT 팀에서 아무도 일하지 않는 시간 이후에 들어왔고, Deckhand는 그중 94 퍼센트에 답했습니다. 다음 날 아침까지 기다렸을 사람들은 그날 밤에 답변을 받았습니다.
팀이 개선 작업을 진행하면서 피드백도 좋아졌습니다. 사람들이 불만을 제기한 부분을 수정하기 위해 시스템 프롬프트와 지식 베이스를 개정한 후, 긍정 평점이 4월의 82 퍼센트에서 6월의 96 퍼센트로 올라갔습니다.
가장 뚜렷한 성과는 티켓 감축이었습니다. 에이전트 대화란 원래라면 Jira 티켓이 되었을 질문입니다. 1,221개의 대화 중 409개만 티켓으로 전환되었습니다. 나머지 812개는 채팅으로 처리되었습니다. 티켓을 제출하고 처리 후 종료하기까지 약 30분이 걸립니다. 그 812개의 대화는 3개월 동안 약 406시간, 1년으로 환산하면 약 1,600시간에 해당합니다. 직원들은 그 시간을 자신의 업무에 쓸 수 있었고, IT는 접수에 소모하지 않았습니다.
결론
Deckhand는 반복적인 IT 질문을 직원들의 부담에서 덜어내고 그 시간을 직원들과 IT 팀에 돌려주었습니다. 스택의 각 구성 요소가 하나의 역할만 담당하고 관리형 서비스로 실행되기 때문에 작동합니다. AgentCore runtime이 에이전트를 호스팅하고, AgentCore Gateway가 Lambda 함수를 에이전트가 호출할 수 있는 MCP 도구로 변환하며, Amazon Bedrock Knowledge Bases가 검색을 처리합니다. 팀은 서버를 구축하거나 오케스트레이션 코드를 유지 관리하지 않고도 이를 출시했습니다.
유사한 솔루션을 구축하려면 잘 관리된 지식 소스와 명확하게 정의된 액션으로 시작하십시오. 에이전트 개발에 대한 내용은 Amazon Bedrock AgentCore 문서 및 Strands Agents SDK 를, 콘텐츠 소스 연결에 대한 내용은 Amazon Bedrock Knowledge Bases 문서 를 참조하십시오.
조직을 위한 에이전틱 AI 사용 사례에 대해 논의하려면 AWS 계정 팀에 문의하십시오.