* 당일 PoC는 API 문서·read-only 접근·sandbox/test data 등 기본 조건이 준비된 경우를 기준으로 합니다. 실제 일정은 보안 검토와 적용 범위에 따라 달라질 수 있습니다.
탐색 시간 ↓정책 · SOP · 케이스 근거를 찾느라 여러 화면을 헤매는 시간을 줄입니다.
반복 스트레스 ↓“이게 맞나?”를 매 문의마다 처음부터 고민하는 부담을 Evidence Layer가 나눠 가집니다.
생산성 ↑같은 근무시간을 검색과 복붙보다 실제 고객 응대와 예외 케이스에 사용합니다.
전문성 ↑숙련자의 판단 경로를 시스템화해 신입과 숙련자 사이의 품질 편차를 줄입니다.
Step 01문의가 들어오면
Step 02Copy Evidence
Step 03Paste to AI
Step 04확인하고 전달
속도만 빨라지는 것이 아닙니다. 사람 · 조직 · 고객 경험이 함께 바뀝니다.
ASH는 상담원 개인의 숙련도에 기대던 반복 업무를 Evidence 흐름으로 표준화합니다.
그래서 교육, 업무 적응, 품질 일관성, 고객 커뮤니케이션까지 함께 개선하는 방향으로 설계됩니다.
Onboarding
신입 교육 부담 ↓
정책 위치와 예외 경로를 처음부터 모두 암기시키기보다, ASH가 필요한 근거와 확인 범위를 안내하도록 설계할 수 있습니다.
Ramp-up
빠른 업무 투입
신입도 숙련자의 탐색 경로와 답변 구조를 따라갈 수 있어, 독립적으로 처리할 수 있는 업무 범위를 더 빠르게 넓히는 데 도움이 됩니다.
Retention
이탈 요인 완화
반복 검색, 불확실한 판단, 답변 작성 부담을 줄여 “일이 너무 어렵고 소모적이라 떠나는” 요인을 완화하는 방향을 목표로 합니다.
Customer experience
더 빠르고 더 일관된 응답
필요한 근거를 빠르게 확인하고 동일한 Evidence 흐름으로 답변을 준비해, 처리 지연과 상담원별 품질 편차를 줄이는 데 초점을 둡니다.
Empathy by design
공감 · 이해 문구 누락 방지
답변 템플릿에 고객 상황에 대한 이해와 공감 표현을 필수 구성요소로 넣어, 속도 때문에 사람다운 커뮤니케이션이 빠지지 않도록 설계할 수 있습니다.
Human + AI
AI의 속도 + 사람의 정성
AI가 근거 탐색과 초안 준비를 맡고, 사람은 고객의 맥락을 읽고 마지막 표현을 다듬습니다. 완전 자동화가 놓치기 쉬운 인간적인 배려를 남깁니다.
∞
사람을 빼는 자동화가 아니라, 사람이 더 잘 응대하게 만드는 AI.ASH의 목표는 “AI가 상담원을 대체하는 것”이 아니라, AI의 속도와 정확성 위에 사람의 공감·판단·정성을 얹는 것입니다.
02. BEFORE → AFTER
같은 문의 하나. 상담원이 감당해야 하는 일은 완전히 달라집니다.
기존에는 숙련자의 머릿속에 있던 “어디를 보고, 무엇을 비교하고, 어떤 예외를 의심해야 하는지”가 상담원 개인의 몫이었습니다.
ASH는 그 탐색과 근거 연결을 반복 가능한 Evidence 흐름으로 바꿉니다.
실제 업무 경험에서 확인한 시간 차이기업명은 공개하지 않고, 동일한 유형의 복잡한 상담 검증 업무를 기준으로 비교합니다.
실제 경험 60+분 → 15분 · ASH는 5분 이내 목표
기존 방식
60분+
정책 · SOP · 케이스 이력 · Backend 상태를 사람이 직접 오가며 확인하고, 근거가 맞는지 하나씩 검증했던 실제 처리 경험입니다.
수동 AI 보조
15분
사람이 상황과 화면 이미지를 AI에게 직접 설명하고, 필요한 자료를 하나씩 전달해 함께 검증했을 때 실제로 줄어든 시간입니다.
ASH 방식
< 5분 목표
Evidence 수집 · 정책 연결 · 케이스 검증 · 초안 준비를 하나의 흐름으로 연결해, 사람이 자료를 다시 설명하는 단계까지 줄이는 것이 목표입니다.
※ 60분+ → 15분은 실제 업무 경험 사례입니다. “5분 이내”는 아직 동일 조건에서 측정한 실적이 아니라 ASH 구조 적용 시의 목표치이며, 실제 고객 PoC에서 검증합니다.
답변 작성 단계만 놓고 봐도 차이는 더 커집니다.이미 필요한 사진과 기본 정보가 준비된 상담 상황을 기준으로 한 경험입니다.
5분 → 2분 → 30초 목표
기존 방식
약 5분
준비된 사진과 정보를 직접 확인하고, 상담원이 고객에게 보낼 답변을 처음부터 작성합니다.
수동 AI 보조
약 2분
기존 사진과 정보를 AI에게 직접 전달하고 상황을 설명한 뒤, 고객 답변 작성을 요청하는 방식입니다.
ASH 방식
약 30초 목표
필요한 Evidence와 답변 형식이 이미 연결된 상태에서, ASH가 근거 확인과 초안 준비까지 한 흐름으로 처리하는 것을 목표로 합니다.
사람이 다시 설명하는 단계까지 줄이면 “확인 → 초안 준비” 자체가 수십 초 단위의 작업이 될 수 있습니다.
※ 5분 → 2분은 실제 업무 경험에 기반한 예시입니다. “30초”는 ASH 방식 적용 시 목표치이며, 실제 고객 환경과 상담 유형에 따라 달라질 수 있습니다.
기존 상담 방식
Agent does everything
01
관련 정책을 직접 검색어떤 문서가 최신인지, 이 케이스에 적용되는지부터 판단합니다.
02
SOP · 임시공지 · 예외조건 확인정책만으로 끝나지 않는 운영 규칙을 다시 찾아 비교합니다.
03
Backend와 케이스 이력 확인주문 · 결제 · 상태 · 이벤트 기록을 여러 화면에서 모읍니다.
04
근거가 서로 맞는지 직접 비교정보가 충돌하면 무엇을 더 확인해야 하는지도 상담원이 결정합니다.
05
애매하면 선임에게 질문숙련도에 따라 처리속도와 판단 품질의 차이가 커집니다.
06
답변을 처음부터 작성판단이 끝난 뒤에도 다시 고객용 문장을 만들어야 합니다.
실제 사례 60분+인지부하 ↑스트레스 ↑품질 편차 ↑
ASH 방식
Evidence first
01
질문과 연결되는 지식 범위를 자동 준비회사 지식 · 정책 · SOP · 공개 자료에서 필요한 범주를 먼저 좁힙니다.
02
필요한 Backend Evidence만 연결상담에 필요한 최소 UID · 상태 · 이벤트 · Source reference만 읽습니다.
03
정책과 사건 근거의 일관성 확인어떤 근거를 보고 있는지 추적 가능한 Evidence Packet으로 정리합니다.
04
예외 · 추가확인 · 이관 필요 여부 정리자동으로 끝내면 안 되는 부분은 사람에게 확인 단계로 넘깁니다.
05
고객에게 보낼 완성형 초안 준비상담원은 빈 화면에서 문장을 시작할 필요가 없습니다.
06
사람이 확인하고 전달최종 판단과 고객 커뮤니케이션의 통제권은 상담원에게 남습니다.
5분 이내 목표탐색 부담 ↓일관성 ↑숙련도 장벽 ↓
좋은 복지는, 일하지 않을 때만 느껴지는 게 아닙니다.
매일 수십 번, 수백 번 반복하는 일을 덜 어렵고 덜 소모적으로 만드는 것도 복지입니다.
검색과 복붙에 쓰던 에너지를 고객 응대와 정말 어려운 예외 판단에 쓰게 하세요.
일하기 편한 회사가, 다시 일하고 싶은 회사가 됩니다.
03. REMOTE-FIRST ADOPTION
기존 CS 시스템은 그대로. 도입은 원격으로 시작할 수 있습니다.
✓ 방문 없이 PoC 가능 · ✓ Read-only 우선 · ✓ 기존 Source of Truth 유지
ASH는 새 시스템을 설치하러 현장에 들어가는 방식이 아닙니다.
CS · AI · IT 담당자와 화상 미팅으로 현재 상담 흐름, 필요한 Evidence, 보안 범위를 먼저 정리합니다.
API 문서 · 샌드박스 · read-only 접근이 준비되어 있다면 PoC부터 초기 파일럿까지 원격으로 진행할 수 있습니다.
01
공개 지식은 우리가 먼저 준비
Help Center, 정책, 제품 문서, 공개 API와 공개된 지원 흐름을 먼저 조사해 상담에 필요한 지식 구조와 RAG 기반을 준비합니다.
Help CenterPolicy / SOPDocsPublic APIRAG
02
AI · IT팀과 필요한 Evidence만 매핑
화면 공유와 기술 미팅으로 Case UID, 상태, 사건 요약, Source reference 등 상담 판단에 필요한 최소 read-only 필드만 함께 정합니다.
Remote mappingRead onlyMinimum fieldsNo migration
03
Connector를 연결하고 실제 케이스로 검증
기존 시스템을 Source of Truth로 유지한 채 Plugin / MCP Connector가 필요한 근거만 묶습니다. 실제 상담 케이스로 Case Packet · 판단 보조 · 고객 답변 초안을 함께 검증합니다.
Plugin / MCPEvidence LayerRemote PoCHuman Gate
고객사 환경이 달라도, 필요한 연결 방식만 고르면 됩니다.
모든 고객사에 같은 구축 방식을 강요하지 않습니다.
현재 가진 API·DB·Warehouse·보안 조건에 맞춰 가장 작은 read-only 연결부터 시작합니다.
Scenario A · Fastest
API 문서 + Sandbox + Read-only Credential이 이미 있는 회사
가장 빠른 환경입니다. 필요한 Evidence endpoint만 확인되면 Connector를 바로 붙여 PoC를 시작할 수 있습니다.
고객사가 해주실 일
API 문서 또는 OpenAPI spec 공유
상담 범위에 맞춘 read-only credential 발급
Sandbox / test case 제공
Scenario B · API Partial
API는 있지만 상담에 필요한 정보가 일부 빠진 회사
기존 API는 그대로 사용하고, 부족한 Evidence만 read-only DB view·Warehouse·Export 등으로 보완합니다.
고객사가 해주실 일
현재 API에서 확인 가능한 범위 표시
부족한 필드의 Source System / Owner 확인
가능한 read-only 보완 경로 승인
Scenario C · No API
외부 API가 없지만 DB 또는 내부 데이터 조회가 가능한 회사
Production table 전체를 열 필요는 없습니다. 필요한 필드만 담은 read-only view나 replica를 만들어 연결하면 됩니다.
고객사가 해주실 일
필요 Evidence가 있는 DB / table owner 확인
최소 필드 read-only view 제공
조회 부하·권한 범위 승인
Scenario D · Warehouse / Export
실시간 API보다 Warehouse·CSV·JSON Export가 쉬운 회사
실시간성이 꼭 필요하지 않은 상담부터 시작할 수 있습니다. 데이터 freshness를 명확히 표시하고 적합한 문의 유형부터 PoC합니다.
고객사가 해주실 일
Warehouse dataset 또는 export 형식 공유
Refresh 주기와 history 보존 범위 확인
첫 PoC를 freshness 요구가 낮은 상담으로 제한
Scenario E · Security First
망분리·VPC·외부 반출 제한이 강한 회사
데이터를 밖으로 옮기는 대신 고객사 네트워크 안에서 Connector를 실행하거나, 허용된 필드만 경계 밖으로 전달하는 방식으로 설계합니다.
고객사가 해주실 일
보안팀과 허용 가능한 네트워크 경계 정의
VPC / VPN / PrivateLink / self-hosted 요구 확인
외부 반출 불가 데이터와 허용 필드 구분
Scenario F · Complex CS
CRM·결제·주문·배송 등 여러 시스템을 오가는 회사
ASH가 특히 잘 맞는 유형입니다. 여러 Source를 없애는 대신 필요한 Evidence만 하나의 Case Packet으로 정리합니다.
고객사가 해주실 일
상담원이 실제로 여는 시스템 목록 공유
시스템을 연결하는 Case / Order / User ID 확인
가장 오래 걸리는 상담 유형 1개 선정
핵심은 단순합니다.고객사가 기존 시스템을 바꾸는 것이 아니라, 현재 환경에서 “무엇을 안전하게 읽을 수 있는지”만 정하면 ASH가 그 위에 맞춰집니다.
↯
민감정보는 “마스킹해서 보내는 것”보다, 애초에 받지 않는 것을 우선합니다.
이름 · 이메일 · 주소 · 결제수단처럼 해당 상담 판단에 필요하지 않은 데이터는 Connector 출력에서 제외할 수 있습니다. 필요한 Evidence만 전달하는 구조이므로 전체 고객 원장을 AI 쪽으로 복제할 이유가 없습니다.
방문은 기본값이 아니라, 필요한 경우의 옵션입니다.
Remote-first를 기본으로 합니다. 화상 미팅, 화면 공유, API 문서, 샌드박스 또는 제한된 테스트 계정만으로 기술 검토와 PoC가 가능한 경우 현장 방문 없이 진행할 수 있습니다.
망분리 · 내부망 작업 · 고객사 보안 정책처럼 현장에서만 처리할 수 있는 조건이 있을 때만 On-site 지원을 협의합니다.
CS + AI + IT한 번에 담당자를 모아 상담 흐름과 기술 범위를 함께 정리
SCREEN SHAREBackend 구조와 필드 매핑을 화면 공유로 빠르게 확인
SANDBOX / READ-ONLY제한된 접근으로 실제 케이스를 안전하게 검증
ON-SITE WHEN NEEDED내부망 · 보안 절차 등 원격이 어려운 경우에만 방문 협의
도입 흐름도 원격 기준으로 단순하게.
STEP 01Remote Discovery · CS 담당자와 현재 상담 흐름, 반복 업무, 우선 적용 케이스를 확인합니다.
STEP 02Technical Mapping · AI/IT팀과 API · Backend · read-only 필드 · 보안 범위를 화면 공유로 정리합니다.
STEP 03Remote PoC · 한 가지 상담 유형과 제한된 Evidence로 실제 작동 데모를 만듭니다.
STEP 04Pilot · 실제 상담원과 검증한 뒤 필요한 예외만 추가하고 범위를 단계적으로 넓힙니다.
고객사 AI팀과 바로 기술 미팅해도 됩니다.
HK Solution 팀이 공개 정보와 상담 흐름을 먼저 분석해 필요한 지식과 Backend 필드 후보를 준비합니다.
CS 담당자는 실제 상담 과정과 우선순위를, AI/IT팀은 가능한 read-only 접근 범위와 보안 조건을 확인합니다.
고객사가 처음부터 전체 시스템을 설명할 필요 없이, 실제 케이스에 필요한 부분부터 좁혀갑니다.
기존 CRM · CS · Backoffice UI와 운영 방식은 그대로 유지하고, 원격으로 검증 가능한 범위부터 시작합니다.
Remote PoC부터 시작 · 필요할 때만 On-site실제 진행 속도는 공개자료 범위, 테스트 환경, read-only 접근 준비 상태, 고객사 보안·승인 절차에 따라 달라질 수 있습니다.
04. See the difference
LIVE WORKFLOW DEMO
복잡한 상담 판단은 뒤에서. 상담원 앞에는 Copy → Paste → 확인만.
문의 하나를 처리하기 위해 정책, SOP, Backend를 차례로 뒤질 필요가 없습니다.
상담에 필요한 최소 Evidence를 가져오면 AI가 회사 지식·정책·케이스 상태를 함께 확인하고,
고객에게 보낼 답변 초안까지 준비합니다.
아래 데모에서 복잡했던 상담 준비 과정이 상담원에게 얼마나 단순한 흐름으로 바뀌는지 확인해보세요.
상담에 필요한 Evidence만
회사 지식 · 정책 함께 확인
답변 초안 자동 준비
최종 판단은 사람
왼쪽 노트북 · Backend 필드
ASH Evidence ViewSanitized backend snapshot for support
Refund / cancelled order
상담에 필요한 필드만 정리해 둔 읽기 전용 Snapshot입니다. 원문 전체를 노출하지 않고 응답 준비에 필요한 최소 정보만 보여줍니다.
● Minimum evidence set
Case UID
case_8F21C Open
User UID
usr_84F2A Pseudonymous
Order UID
ord_7842X Cancelled
Refund state
Initiated 3–5 days
Event summary
Cancel → Refund processing → Reply
Policy result
Standard No exception
Source refs
evt_C19 · pay_R72 · pol_v3 Refs
PII status
Excluded Name · Email · Address · Payment
노출 원칙 · PII excluded · UID/status/refs only
복사 대상 · Sanitized evidence only
오른쪽 모니터 · Evidence Intake → AI Draft
ASH Support ComposerEvidence intake → AI review → Final draft
1. Evidence Packet 받기
왼쪽의 최소 Evidence Packet을 붙여넣으면 ASH가 케이스를 구조화하고 필요한 검토 범위를 준비합니다. 답변 초안은 확인이 끝난 뒤 별도로 생성됩니다.
⌘V
Paste backend evidence hereUID · 상태 · 이벤트 요약 · 정책 결과 · Source reference
① 읽기 전용부터AI가 답변을 준비하는 데 원본 Backend를 수정할 권한은 필요하지 않습니다. 사고 가능성이 큰 Write 권한을 기본 요구사항에서 빼는 방향입니다.
② 최소 권한 · 최소 데이터“연결할 수 있는 모든 데이터”가 아니라 “이 상담에 반드시 필요한 데이터”만 정의합니다. 노출 면적 자체를 줄입니다.
③ 공개 지식은 따로Help Center·정책·공개 API는 별도로 조사하고 RAG화합니다. 내부 고객 데이터와 섞어 대규모 지식베이스를 만들 필요가 없습니다.
④ 사람을 마지막 Gate로Evidence가 부족하거나 예외가 있는 케이스는 사람 확인 단계로 넘깁니다. 자동화가 사람의 최종 통제권을 없애지 않습니다.
06. Backend Architecture Advisory
OPTIONAL CONSULTING · SUPPORT DATA ARCHITECTURE
ASH를 연결하는 것에서 끝나지 않습니다. 상담이 더 쉬워지는 Backend 구조도 함께 제안할 수 있습니다.
실제 상담 케이스를 따라가다 보면 “데이터는 있는데 찾기 어렵다”, “현재 상태만 있고 사건 이력이 없다”,
“여러 시스템을 연결할 공통 reference가 없다” 같은 구조적 friction이 보일 수 있습니다.
이때 현재 구조와 제약을 먼저 이해한 뒤, Support 관점에서 더 효율적인 데이터 형태와 최소 개선안을 제안합니다.
↗
기존 Backend가 틀렸다고 말하는 컨설팅이 아닙니다.
레거시 호환성 · 성능 · 보안 · 규제 · 비용 같은 현실적인 이유를 먼저 확인합니다.
원본 DB를 갈아엎기보다 projection, read model, lookup endpoint, derived field처럼
현재 구조를 유지하면서 상담 효율을 높일 수 있는 최소 변경부터 우선합니다.
01 · Observe
현재 구조와 실제 업무를 함께 봅니다.
상담원이 어떤 화면을 오가고, 어떤 값을 비교하고, 어떤 데이터가 늦거나 흩어져 있는지 실제 케이스 기준으로 확인합니다.
“현재 Backend가 어떻게 생겼는가”보다 “어디에서 Support friction이 생기는가”를 먼저 봅니다.
02 · Compare
현재 구조와 더 효율적인 형태를 비교합니다.
가능한 데이터 형태를 여러 개 열어두고, 판단 충분성 · 조회 효율 · provenance · 시간축 · correlation · privacy를 기준으로
Support/Operations에 가장 효과적인 구조를 AI Recommended 형태로 제시합니다.
03 · Improve
가장 작은 개선부터 제안합니다.
전체 schema 재설계보다 실제 처리시간·오류·탐색 부담을 줄일 수 있는 최소 변경을 우선합니다.
고객사의 기술팀이 검토할 수 있도록 Current → Friction → Recommendation → 기대효과 → 고려사항 순서로 정리합니다.
흩어진 대화 기록원본 저장소는 유지하고, Case 기준 conversation timeline / read model을 추가하는 방식
현재 상태만 있고 사건 이력이 부족한 경우status 하나보다 reason · actor/source · occurredAt · reference가 포함된 event 구조를 제안
여러 시스템 연결이 어려운 경우Case / Order / User / Event 간 correlation ID와 source reference를 명확히 하는 방식
상담원이 매번 직접 계산하는 경우원본값의 provenance를 유지하면서 decision-oriented derived field / projection을 추가
한 케이스를 보기 위해 조회가 너무 많은 경우Support 전용 lookup endpoint 또는 aggregation view로 필요한 Evidence를 한 번에 제공
민감정보가 너무 넓게 노출되는 경우Scenario → Required Evidence mapping으로 상담 목적별 최소 필드만 읽는 구조를 제안
SOP나 공개 자료가 부족해도 괜찮습니다. 무엇을 공개 지식과 Public API로 만들지부터 함께 설계할 수 있습니다.
실제 문의 케이스, 현재 Help Center·문서·API 상태, 그리고 업계의 공개된 지원 구조를 비교해
어떤 정보는 고객과 상담원이 읽을 수 있는 공개 지식으로 두고,
어떤 정보는 시스템이 안정적으로 조회할 수 있는 Public API / Webhook으로 제공하는 편이 좋은지 제안합니다.
Knowledge Design
“무엇을 SOP / 공개 지식으로 만들 것인가?”
반복 문의, 정책 해석, 자주 발생하는 예외를 분석해 Help Center·FAQ·정책 문서·상담원 가이드 중
어떤 형태로 공개·정리하는 것이 가장 효과적인지 우선순위를 제안합니다.
Public API Design
“무엇을 API로 제공하는 것이 더 나은가?”
사람이 문서를 읽는 것보다 시스템이 현재 상태를 정확히 확인해야 하는 정보는
Public API·Webhook·structured endpoint 후보로 분리합니다.
상태·이벤트·reference·timestamp처럼 기계가 검증해야 하는 정보가 대표적입니다.
Public Benchmark
다른 회사의 공개 구조와 비교해 개선 방향을 제안
다른 기업의 공개 Help Center, 개발자 문서, API, Webhook, 상태 페이지처럼
외부에서 확인 가능한 패턴을 벤치마킹해 “이 회사라면 무엇을 더 공개하면 Support가 쉬워지는가”를 비교합니다.
벤치마킹은 공개 정보만 사용합니다.
다른 고객사의 비공개 Backend·SOP·운영정보를 공유하는 방식이 아니라,
공개된 문서·API·지원 패턴과 고객사의 실제 문의 흐름을 함께 분석해 회사별 권장안을 만듭니다.
최종 기준은 “많이 공개하는 것”이 아니라 Support 판단에 필요한 정보가 사람과 시스템에 가장 적절한 형태로 제공되는가입니다.