2주 만에 Strands SDK와 Amazon Bedrock AgentCore로 구현한 어스얼라이언스의 CS 환불 자동응답 에이전트 시스템

이번 블로그는 AWS DEVCRAFT 2026 (2026.3.26 ~ 4.9, AWS 코리아 오피스) 해커톤 프로그램에 참여하여 진행한 프로젝트를 기반으로 작성되었습니다. DEVCRAFT는 AWS SA와 고객사 개발팀이 함께 실제 비즈니스 과제를 2주간 집중 개발하는 프로그램입니다.

어스얼라이언스 (US Alliance)는 크리에이터 기반 금융 콘텐츠·커뮤니티 플랫폼 ‘어스플러스(US PLUS)’를 운영하는 기업입니다. 본 블로그에서는 어스얼라이언스가 Amazon Bedrock AgentCore 기반으로 약 2주 만에 구축한 CS 환불 문의 자동 응답 에이전트의 개발 경험을 공유합니다.

이번 2주 간의 DEVCRAFT 프로그램 기간동안, 어스얼라이언스는 CS팀이 유저의 문의에 답변하기 위해 내부 어드민에서 정보를 조회하고 매뉴얼에 맞게 답변을 작성하는 과정을 에이전트로 자동화했습니다. 고객 문의가 접수되면 에이전트가 필요한 정보를 조회하고 답변 초안을 작성해 채널톡 내부 대화로 전송하며, CS팀은 해당 초안을 확인한 뒤 바로 고객에게 발송할 수 있습니다.

그림 1. AI Agent를 통한 환불 문의 응대 예시 

상담 자동 응답 AI를 개발하게 된 이유

어스얼라이언스 개발팀은 사내 업무 효율성을 높이기 위해 CS팀의 문의 대응을 자동화하기로 결정했습니다. 신규 상품 출시 등으로 특정 기간에 문의가 급증하면 업무 부담이 커지고, 채널톡을 통한 문의 유형에는 반복적인 패턴이 있는 만큼 에이전트 도입을 통한 효율화 가능성이 있다고 판단했기 때문입니다.

에이전트 도입을 위해 해결해야 했던 병목 중 하나는 답변에 필요한 정보가 여러 시스템에 파편화되어 있다는 점이었습니다. 하나의 환불 문의에 답하기 위해서도 매니저는 어드민에서 고객 정보·결제 이력·이용 기록·환불 내역을 여러 화면에 걸쳐 수동으로 조회해야 했습니다. 결과적으로 답변 자체가 복잡해서가 아니라 정보를 모으는 과정에 대부분의 시간이 소요되고 있었습니다.

채널톡 대화를 분석하는 과정에서 가장 중요한 발견은 “유저 메시지만으로 답변 유형을 판단하기 어렵다”는 점이었습니다. 예를 들어 “해지하려고요”라는 동일한 메시지도 고객의 결제 이력·이용 기록·환불 내역에 따라 서로 다른 답변 유형으로 분기됩니다. 즉 Agent는 메시지를 이해하는 것을 넘어 필요한 데이터를 조회하고, 조회 결과를 기반으로 답변을 결정하는 구조여야 했습니다.

또한 같은 데이터 상태에서도 담당자마다 답변이 다를 수 있어, 에이전트 도입은 단순히 답변을 자동화하는 프로젝트가 아니라 기획팀·CS팀·개발팀이 함께 답변 기준을 합의하고 명시화하는 과정이 되었습니다.

설계 단계에서 환불이라는 금전·정책 리스크가 민감한 도메인 특성상 에이전트의 정확성과 안정적 운영을 설계의 중심 축으로 삼았고, 이를 위해 초기 도입단계에서 자동 발송에 앞서 내부 검수 초안 방식을 선택했습니다. Agent가 생성한 답변은 채널톡의 ‘내부 대화'(매니저에게만 보이는 메시지 영역)로 전달되고 매니저가 검수한 뒤 고객에게 발송하며, 품질 지표가 일정 기준을 충족하면 대응 범위 및 효율성 증대를 위한 다른 방식으로의 확장을 검토할 계획입니다.

또한 내부 대화 영역에서는 Agent가 답변 생성을 위해 조회한 근거 데이터(결제 이력·이용 여부·환불 금액 계산 결과 등)가 함께 포함되어 전달되기 때문에, 매니저는 여러 어드민 화면을 직접 돌아다니지 않고도 한 곳에서 근거와 답변을 동시에 검토하고 필요 시 수정/보완해 답변할 수 있습니다.

솔루션 개요

고객 상담 AI 에이전트는 다음과 같은 흐름으로 동작합니다.

그림 2. 채널톡 문의 Webhook에서 답변까지의 전체 파이프라인 시각화

고객이 채널톡으로 메시지를 보내면 즉시 답변을 생성하지 않고 2분 동안 추가 메시지가 오는지 대기합니다. 실제 데이터 분석 결과 고객은 보통 한 번에 완성된 문의를 보내지 않고 “안녕하세요” → “환불해주세요” → “건강이 안 좋아서요” 와 같이 여러 메시지로 끊어서 보내기 때문입니다. 메시지가 도착할 때마다 Agent를 호출하면 같은 대화에 여러 번 답변하게 되어 문맥이 분실되고 비용도 낭비될 수 있습니다.

2분의 대기 후 Agent가 호출되면 해당 대화의 모든 메시지를 병합해 하나의 맥락으로 처리하고, 의도 분류 → 데이터 조회 → 답변 유형 결정 → 답변 생성 단계를 거쳐 초안을 만들어냅니다. 생성된 초안은 답변 텍스트와 조회 근거 데이터를 함께 채널톡 내부 대화 영역으로 전달되며, 매니저는 초안을 그대로 발송하거나 필요 시 수정한 후 고객에게 전달합니다.

솔루션 아키텍처

에이전트는 Agent 실행 계층을 Amazon Bedrock AgentCore Runtime으로 분리하고, 메시지 수신·Debounce·답변 전달은 AWS 서버리스 컴포넌트로 구성했습니다. Runtime에서 실행되는 Agent에는 AgentCore Memory와 Bedrock Guardrails를 함께 연결하여 멀티턴 맥락 관리와 안전성 검증을 같은 실행 흐름 안에서 처리합니다.

그림 3. AgentCore Runtime을 중심으로 구성된 서버리스 아키텍처

Agent 로직 외의 파이프라인은 모두 AWS 서버리스 서비스로 구성해 운영 부담을 최소화했습니다.

• API Gateway + Webhook Lambda: 채널톡 Webhook 엔드포인트로, 인증과 throttling을 처리하고 메시지를 저장합니다.
• DynamoDB: 대화 단위로 메타 정보와 메시지 기록을 함께 조회할 수 있도록 저장 구조를 구성했습니다.
• Processor Lambda: 스케줄 만료 시 실행되어 해당 대화의 메시지를 병합하고 AgentCore Runtime에서 Agent를 호출합니다.
• EventBridge Scheduler: 예약 시점 갱신이 가능한 구조로, 사용자의 연속 메시지에 대해 타이머를 리셋하는 debounce 처리에 활용했습니다.

그림 4. Debounce 시퀀스 시각화 (메시지 도착 시마다 2분 타이머 리셋)

에이전트 구조 및 구현 상세

Agent 5단계 내부 동작

Agent 내부 동작은 의도 분류(Pass 1)와 실행(Pass 2)을 분리하는 2-Pass 오케스트레이션으로 구성되어 있으며, 하나의 대화 턴을 처리하는 과정은 다음 5단계로 이어집니다.

그림 5. Agent 5단계 내부 동작 흐름

반복 문의 중에서도 금전이 직접 연관되어 답변 품질이 가장 중요한 환불 도메인을 우선 적용 대상으로 선정하고, 비환불 문의는 Knowledge Base 검색과 상담사 이관으로 처리하는 구조로 시작했습니다. 환불 CS 도메인은 API 조회 → 조건 분기 → 답변 생성이 반복되는 흐름이라 단일 Strands Agent의 tool-use 루프로 구성했으며, 추후 Agentic AI 활용 범위가 확대되면 역할 분리 기반의 멀티 에이전트 구조 전환도 선택지로 두고 있습니다.

이 구현에서는 추론이 필요한 작업은 LLM이 담당하고, 환불 금액 계산·답변 유형 결정·PII 마스킹처럼 결정론적 보장이 필요한 작업은 코드와 규칙으로 처리하도록 역할을 나누었습니다. 이를 통해 응대의 유연성은 유지하면서도, 응답 품질과 안전성을 함께 확보하고자 했습니다.

Tool 카탈로그

Agent에 연결한 Tool은 크게 세 그룹으로 나뉘며, 주요 예시는 다음과 같습니다.

• 데이터 조회: 내부 어드민 API를 호출해 고객 정보·결제 이력·환불 내역을 조회합니다. 답변 유형에 따라 필요한 것만 LLM이 호출하도록 구성하여 사전 조회(pre-fetch) 방식 대비 API 호출 수를 크게 줄였습니다.
• 계산·렌더링: 환불 금액 계산과 템플릿 기반 답변 렌더링을 담당합니다.
• 대화·폴백: Knowledge Base 검색(search_faq)과 상담사 이관(handoff_to_human) 등을 담당합니다.

같은 메시지, 다른 답변

앞서 살펴본 것처럼 같은 메시지도 데이터 상태에 따라 답변 유형이 달라지기 때문에, 라우팅 결정은 LLM 판단이 아니라 명시적인 규칙으로 관리합니다. 유저 메시지만으로는 답변 유형 정확도가 매우 낮지만, 의도와 데이터 조합을 기반으로 한 라우팅을 통해 내부 검수 기준의 답변 정합성을 안정적인 수준까지 끌어올릴 수 있었습니다.

AgentCore Memory를 활용한 멀티턴 대화 지원

실제 채널톡 고객 대화는 대부분 여러 턴에 걸쳐 이어지며, 이전 턴의 답변 내용에 따라 다음 답변이 결정됩니다. 예를 들어 하나의 환불 요청이 아래처럼 여러 턴에 걸쳐 전개됩니다.

• Turn 1: “환불해주세요” → Agent: 결제 이력 조회 → 환불 규정과 예상 환불 금액 안내
• Turn 2: “네, 해주세요” → Agent: AgentCore Memory에서 이전 턴 참조 → 의도를 “환불 확정”으로 분류 → 환불 접수 완료 안내
• Turn 3 (3일 후): “환불 언제 되나요?” → Agent: Memory에서 3일 전 대화 참조 → 환불 처리 상태 안내

어스얼라이언스 팀이 AWS 기술을 선택한 이유

어스얼라이언스의 환불 CS 에이전트는 금융 콘텐츠 서비스라는 도메인 특성상 리스크 통제와 측정 가능한 품질 기준을 동시에 만족해야 했습니다. 본 팀은 이 요구사항을 기준으로 Runtime·Memory·Evaluation·Guardrail을 각각 실행 격리, 멀티턴 맥락 관리, 평가 자동화, 안전성 검증 용도로 조합해 사용했습니다.

법적 리스크 주제 차단을 위한 Bedrock Guardrails 활용

금융 콘텐츠 서비스에서는 투자 종목 추천처럼 에이전트가 임의로 답해서는 안 되는 리스크 주제가 존재합니다. 이런 주제는 프롬프트로 “하지 말라”고 지시하더라도 LLM이 항상 따른다는 보장이 없기 때문에, 모델과 독립된 레이어에서 강제로 차단할 수 있는 구조가 필요했습니다.

본 프로젝트에서는 Bedrock 모델 호출 경로에 Guardrail ID를 연결하여, 사용자 입력과 모델 응답 양쪽에 금지 주제(denied topics) 차단·PII 마스킹이 필터 레이어로 적용되도록 구성했습니다. 프롬프트와 별도의 안전성 검증 레이어가 작동하기 때문에, CS 에이전트가 답변을 생성할 때 금지 주제가 답변 경로에서 자연스럽게 차단됩니다.

멀티턴 대화 맥락 유지를 위한 Bedrock AgentCore Memory

환불 상담은 대부분 2턴 이상으로 이어집니다. 한 대화 내에서 “환불 규정 안내 → 고객 동의 → 환불 금액 확정”과 같이 이전 턴의 맥락이 다음 답변을 결정하고, 며칠 뒤 같은 대화방에서 “환불 언제 되나요?”와 같은 후속 문의가 이어지기도 합니다. 이 맥락이 끊어지면 답변 품질과 고객 경험이 동시에 떨어지기 때문에, 대화방 단위로 턴 간 맥락을 지속 관리할 수 있는 구조가 필요했습니다.

본 프로젝트에서는 채널톡의 대화방 식별자를 AgentCore Memory의 세션 ID로 그대로 매핑하고, Strands Agents SDK가 제공하는 AgentCoreMemorySessionManager를 Agent 인스턴스에 주입해 턴 간 맥락 관리를 위임했습니다. 같은 대화가 이어지는 동안의 이전 턴 메시지가 다음 호출에 자동 포함되기 때문에, Processor Lambda는 매 호출에서 별도의 세션 상태 저장 로직 없이 session_id만 전달하는 방식으로 대화방 단위의 맥락 연속성을 유지할 수 있도록 구성했습니다.

고객 세션 격리와 에이전트 안전 배포를 위한 Bedrock AgentCore Runtime

채널톡으로 들어오는 여러 고객 대화가 동시에 흐르는 환경에서는, 한 고객의 실행 이상이 다른 고객의 세션에 영향을 주지 않도록 세션 단위의 격리가 필요했습니다. 본 프로젝트에서는 Agent를 AgentCore Runtime에 배포했습니다. AgentCore Runtime은 각 세션을 독립된 microVM에서 실행하고 세션 종료 시 해당 microVM을 정리하는 구조이기 때문에, 별도의 격리 로직을 구현하지 않고도 고객 대화 간 상태가 섞이지 않도록 할 수 있었습니다.

또한 Agent 로직을 Runtime 이미지로 분리함으로써 Lambda가 메시지 수신과 Runtime 호출만 담당하도록 역할을 나눴고, Agent 코드 변경과 Lambda 배포 파이프라인도 분리했습니다. 세션별 실행 확장과 자격 증명 관리는 Runtime 계층 기준으로 운영해, Lambda 측 구성은 최소한으로 유지했습니다.

도메인 지식 통합 관리를 위한 Bedrock Knowledge Bases (RAG)

CS 에이전트는 환불 도메인 외에도 서비스 이용 FAQ·정책서·운영 매뉴얼처럼 여러 도메인 지식을 참조해야 합니다. 도메인별로 별도의 Knowledge Bases를 운영하면 정책이 각기 드리프트할 위험이 있었기 때문에, 단일 Knowledge Base에 문서를 통합하고 검색 범위만 분리하는 구조가 필요했습니다.

본 프로젝트에서는 환불 FAQ·매뉴얼·시나리오 문서를 하나의 Bedrock Knowledge Base에 통합하고, source 메타데이터 태그로 검색 범위를 도메인별로 분리했습니다. 문서 청킹·임베딩·인덱싱 파이프라인을 직접 구축하는 대신 관리형 구성으로 가져가면서, 초기 단계에서는 Bedrock 모델 호출에 knowledge_base_id만 지정해 Agent 호출 흐름에 RAG를 연결하는 방식으로 구현 범위를 제한했습니다.

에이전트 품질 평가·보정 체계 구축을 위한 Strands SDK와 AgentCore Evaluation

에이전트 답변 품질의 지속적 검증과 회귀 감지를 위해, 본 프로젝트에서는 strands-evals, 커스텀 평가자 3종, Shadow 파이프라인, 주간 보정 사이클을 하나의 평가 체계로 묶었습니다. Agent 실행 span은 Strands Agents SDK의 OTEL 계측으로 수집하고, 단계 단위 평가는 AgentCore Evaluation에 연결하여 평가와 관측이 같은 실행 기록을 참조하도록 구성했습니다.

본 프로젝트의 검증은 세 층위로 나뉩니다. 결정론적으로 동작하는 코드 로직(환불 금액 계산·라우팅 규칙)은 pytest로 검증하고, 같은 입력 데이터가 주어졌을 때 LLM이 생성한 답변이 기대하는 유형·금액·PII 기준을 충족하는지는 strands-evals가 측정하며, 의도 분류 → 데이터 조회 → 답변 생성으로 이어지는 Tool 호출 흐름 자체가 설계대로 흘러갔는지는 AgentCore Evaluation이 담당합니다.

strands-evals는 골든셋 시나리오에 대해 type_accuracy, amount_accuracy, pii_compliance 평가자를 동시에 실행하고 결과를 점수(0.0~1.0)로 반환합니다. 테스트 코드로는 pass/fail만 확인 가능한 LLM 응답 품질을 지표 단위로 추적·비교할 수 있어 최종 응답 품질 평가 계층으로 배치했습니다.

AgentCore Evaluation은 OTEL span 기반으로 실행 단계를 개별 검증하기 때문에, 빌트인 ToolSelectionAccuracy 평가자로 Tool 호출 흐름의 정합성을 측정해 “결과는 맞더라도 과정이 잘못된 경우”까지 포착합니다.

운영 루프와는 두 축으로 결합됩니다. Shadow 파이프라인으로 프로덕션 실행 결과와 매니저가 실제로 발송한 답변, 그리고 에이전트가 참조했던 데이터 조회 결과를 함께 보존해 재현 실행이 가능하도록 설계했고, 이 기록이 회귀 테스트용 골든셋으로 자동 축적됩니다. 주간 보정 사이클에서는 자동 리포트(답변 유형 일치율·금액 정확도·정책 오류)를 기반으로 불일치 원인을 분류한 뒤 과거 골든셋으로 회귀 검증을 수행합니다.

동일한 OTEL trace는 Langfuse로 실시간 전송되어 의도 분류 오류·Tool 누락·답변 템플릿 불일치 중 어느 단계에서 품질 문제가 발생했는지 추적할 수 있고, Lambda 에러·지연·DynamoDB throttling 같은 인프라 레벨 이상은 Amazon CloudWatch로 분리해 모니터링하도록 구성했습니다.

마무리

현재 솔루션은 Agent의 답변 초안이 채널톡의 ‘내부 대화’로 전달되고 매니저가 검수한 후 고객에게 발송되는 방식으로 운영되고 있습니다. 다음의 품질 기준이 2주 연속 충족되는 시점에 단순 유형부터 순차적으로 자동 발송으로 전환할 계획입니다.

• 답변 유형 정답 일치율 ≥ 90%
• 환불 금액 정확도 100% (±1원 이내)
• 정책 오류 0건
• PII 미노출 100%

현재는 초기 도입 단계로 정량적 운영 효과는 측정 중이나, 내부 검수 초안 방식 운영을 통해 매니저가 백지 상태에서 답변을 작성하는 대신 Agent 초안을 검수·보정하는 형태로 전환되면서 응답 준비 시간과 검수 부담이 줄어드는 효과를 확인하고 있습니다. 자동 발송 전환 이후에는 응답 준비 시간 단축률, 매니저 검수 시간 절감, 처리 문의량 등의 지표를 정량적으로 측정해 성과를 관리할 계획입니다.

이후에는 Bedrock Knowledge Base의 metadata tag 전략을 활용해 환불 외 도메인(FAQ·상품 문의·서비스 이용)으로 확장하며, 도메인별 답변 품질을 같은 평가 파이프라인으로 관리할 계획입니다. 장기적으로는 Agent가 정책 기반으로 확실하게 대응 가능한 범위를 자동 발송으로 넓혀가고, 사람은 예외 판단이나 복잡한 상황 대응처럼 사람이 맡아야 하는 영역에 집중할 수 있도록 운영 구조를 잡아가는 것이 목표입니다.

본 프로젝트에서는 환불 문의 대응에 필요한 Agent 파이프라인을 설계·구현하고, 내부 검수 초안 방식으로 운영 가능한 수준까지 정리했습니다. Agent 실행·평가·관측을 초기 단계에서 함께 설계하여 개발 단계의 구현과 운영 단계의 보정 루프를 같은 흐름으로 연결할 수 있었습니다.

Agent 도입은 “사람을 대체하는 것”이 목표가 아니라, 반복 가능한 부분은 Agent가 처리하고 사람은 판단이 필요한 영역에 집중할 수 있는 환경을 만드는 것이 목표입니다. 본 프로젝트는 그 방향으로의 한 걸음이며, 앞으로도 CS팀과 함께 지속적으로 보정해 나갈 계획입니다.