- 대부분의 웹사이트는 "정보는 여기 있습니다"라고만 하고 나머지는 고객이 찾게 둡니다. 찾기 싫은 사람은 창을 닫고 경쟁사로 갑니다.
- 새로운 웹사이트는 유능한 안내 직원처럼 일합니다. 두세 가지를 물어 고객이 원하는 것을 이해하고, 일이 끝날 때까지 안내합니다.
- 준비할 것은 기술 쪽보다 회사의 정확한 답 쪽에 더 많습니다. 가격, 조건, 실제로 해 줄 수 있는 일입니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
고객이 매장에 들어왔는데 아무도 인사하지 않는다고 상상해 보십시오. 어느 진열대에 무엇이 있는지 알려 주는 안내판만 있습니다. 원하는 것을 이미 아는 사람은 걸어가서 집어 들지만, 아직 확신이 없는 사람은 어리둥절하게 서 있다가 나가 버립니다. 정보 페이지와 "문의하기" 버튼만 있는 웹사이트는 딱 직원 없는 매장처럼 움직입니다.
고객은 모든 페이지를 읽고 싶어 하지 않습니다. 제품이 자기에게 맞는지, 무엇을 준비해야 하는지, 대략 얼마인지, 다음 단계가 무엇인지 알고 싶어 합니다. 기존 메뉴와 검색창은 이 질문들에 따로따로 답합니다.
웹사이트에 정보가 부족해서 문제가 생기는 것만은 아닙니다. 정보를 다 갖춘 회사도 많지만, 그 정보가 부서와 내부 조직 기준으로 정리되어 있습니다. 실제 상황을 안고 들어온 고객은 자기 문제를 회사의 서비스 이름에 맞춰 스스로 번역해야 합니다. 찾지 못하면 사이트를 떠나거나, 전화로 묻거나, 막연한 메시지를 보냅니다. 그러면 영업팀은 요구 사항을 처음부터 다시 모아야 합니다.
그래서 AI 웹사이트는 화면 구석에 떠 있는 채팅창으로 볼 것이 아니라, 의도를 이해하고 여정(Journey) 내내 맥락을 이어 가는 경험 계층으로 봐야 합니다. 기존 콘텐츠 페이지는 참고 자료로서 여전히 가치가 있습니다. AI는 그중에서 정보를 고르고, 빠진 부분만 묻고, 상황에 맞는 화면이나 액션(Action)으로 사용자를 안내합니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 키워드 검색, FAQ 표시, 모든 고객에게 같은 입력 폼 | 맥락을 모으는 대화, 승인된 정보 검색, 사례별 맞춤 추천, 그리고 예약, 서류 요청, 요약을 붙인 리드(잠재 고객) 생성 같은 워크플로 실행 |
기술 면에서는 대화가 웹 페이지, 백엔드 시스템과 상태를 유지한 채 연결되어야 합니다. 그래야 고객이 질문으로 시작해 정보를 보러 갔다가, 돌아와서 요구 사항을 고치고, 예약 버튼을 눌러도 맥락이 사라지지 않습니다. 모든 도구는 실제로 영향을 주기 전에 권한과 데이터를 다시 확인해야 합니다.
기업이 쓸 수 있는 새로운 기능
달라진 점은 웹사이트가 유능한 안내 직원처럼 일하기 시작했다는 것입니다. 몇 가지 질문으로 고객이 원하는 것을 파악하고, 시스템에서 실제 가격과 조건을 가져와 답하고, 예약이나 견적 요청 단계까지 안내합니다. 고객은 다음에 어느 페이지를 눌러야 할지 짐작할 필요가 없습니다.
프로젝트의 모습
이 프로젝트는 웹 페이지와 함께 움직이는 디지털 컨시어지(Digital Concierge)를 만드는 일이며, 사용자에게 글로만 대화하라고 강요하지 않습니다. 고객은 화면에서 목표를 고르는 것으로 시작해 대화로 세부 사항을 알려 주고, 비교표를 본 다음, 입력 폼으로 돌아가 정보를 고칠 수 있습니다. 그동안 맥락은 사라지지 않습니다. 대화와 익숙한 인터페이스가 섞인 경험인 셈입니다.
눈여겨볼 기능
시스템은 요구를 선별하고, 승인된 정보에서 답을 찾고, 패키지를 비교하고, 가격대를 추정하고, 서비스 지역을 확인하고, 예약을 잡고, 서류를 받고, 이를 리드 브리프(Lead Brief)로 요약할 수 있습니다. 또 하나 중요한 기능은 각 정보를 왜 묻는지 이유를 알려 주고, AI와 대화하고 싶지 않을 때 질문을 건너뛰거나 직원을 부를 수 있게 하는 것입니다.
뒤에서 돌아가는 기술
주요 구성 요소는 보통 정보를 찾는 Knowledge Retrieval, 언어를 이해하는 Language Model, CRM과 캘린더, 가격 시스템을 연결하는 Tool Calling, 맥락을 기억하는 Session Memory, 권한을 정하는 Policy Layer입니다. 모든 답변과 액션은 로그로 남겨야 나중에 되짚어 볼 수 있고, 잘못된 사례를 다시 테스트할 수 있습니다.
사용자와 기업이 얻는 가치
고객은 어느 페이지를 열어야 할지 짐작하지 않아도 되고, 같은 이야기를 여러 번 반복하지 않아도 됩니다. 영업팀은 구조화된 정보를 받고 다음에 무엇을 할지 압니다. 기업은 웹사이트가 정말로 답하지 못하는 질문이 무엇인지 보게 되어, 그 정보로 서비스, 콘텐츠, 영업 절차를 개선할 수 있습니다. 채팅 건수가 줄어드는 것과 함께, 하려던 일을 끝까지 마치는 고객의 비율이 올라갑니다.
- 질문은 꼭 필요한 만큼만 하고 고객을 캐묻지 않는 AI 컨시어지
- 고객의 의도에 맞춰 질문과 화면을 바꾸는 가이드형 여정(Guided Journey)
- 캘린더, CRM, 가격, 서비스 지역과 연결되는 도구 호출(Tool Calling)
- 대화 내용과 근거를 직원에게 넘겨 고객이 다시 설명하지 않아도 되는 인계(Handoff)
가상 사례
실제로 쓰이는 모습
한 B2B 서비스 기업은 고객이 목표, 예산, 일정, 제약 조건을 말하게 합니다. AI는 요구 사항을 요약하고, 실제 데이터로 패키지를 비교하고, 상담 가능한 시간을 제안합니다. 특수한 경우는 요약 브리프와 함께 전문가에게 넘어갑니다.
새 시스템을 설치하려는 건물 관리자가 패키지 이름은 모른 채, 사용 지점 수, 건물 유형, 예산, 서비스를 시작해야 할 날짜만 알려 준다고 해 봅시다. 시스템은 서비스 지역을 확인하고, 아직 빠진 정보를 목록으로 보여 주고, 선택지 두 가지를 이유와 함께 제시한 뒤, 요약을 첨부해 영업 엔지니어와의 미팅을 잡습니다.
직원 화면에는 대화 기록 외에도 고객이 확인한 사실, 받은 서류, 시스템이 세운 가정, 아직 답이 없는 질문이 표시됩니다. 고객이 다음 날 다시 오면 같은 여정을 처음부터 시작하지 않고 이어 갈 수 있습니다. 챗봇과 실제 업무를 책임지는 제품은 여기서 갈립니다.
의도별 액션 맵(Intent-to-Action Map)
고객의 주요 의도 10가지를 적고, 의도마다 답변, 데이터, 도구, 승인 지점, 성공의 기준을 정합니다.
자주 발생하고, 측정할 수 있고, 되돌릴 수 있는 의도부터 시작합니다.
범위, 위험, 성과 측정 방법
답변-액션 매트릭스(Answer-to-Action Matrix)를 만들어 어떤 질문은 어느 출처로 답할 수 있는지, 어떤 액션은 바로 실행해도 되는지, 어떤 액션은 확인이 필요한지, 어떤 액션은 AI가 해서는 안 되는지 분명히 나누십시오. 프로젝트별 가격 보증이나 계약상 납기 약속이 AI가 해서는 안 되는 액션의 예입니다. 성과는 정확도와 액션 이후의 영향을 함께 봐야 하며, 답변이 자연스럽게 들리는지 점수만 봐서는 부족합니다.
에이전트가 기준 원본 데이터(Source of Truth)를 읽지 않은 채 가격, 조건, 작업 일정을 약속하게 두지 마십시오. 필요 이상의 데이터도 수집하지 마십시오.
추적할 지표: Task Completion, Qualified Lead, Time-to-Handoff, Answer Citation, Abandonment
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
에이전트가 참고 자료 밖의 정보를 내놓거나, 정보가 빠진 리드를 만들거나, 직원이 고객에게 같은 질문을 자주 다시 해야 한다면 멈추거나 한 단계 물러나십시오. 여정과 데이터 계약(Data Contract)이 아직 더 많은 액션을 감당할 준비가 되지 않았다는 신호입니다.
BUSINESS & PRODUCT READINESS
AI 컨시어지를 만들기 전에 답변과 고객 여정을 어떻게 정리해야 할까
대화 인벤토리(Conversation Inventory)부터 시작합니다. 채팅, 이메일, 영업팀이 받은 질문을 모아 고객이 입력한 단어 대신 의도를 기준으로 묶습니다. 한 가지 의도도 "가격 알려 주세요", "이 예산으로 뭘 할 수 있나요", "작은 패키지도 있나요"처럼 여러 표현으로 나옵니다. 그다음 확인된 답변, 추가로 물어야 할 정보, 웹사이트에서 할 수 있게 열어 둘 액션을 정합니다. 실제로 도움이 되는 에이전트와, 말은 잘하지만 고객을 같은 페이지로 계속 돌려보내는 봇은 이 기초에서 갈립니다.
자주 간과되는 부분은 불확실성을 설계하는 일입니다. 정보가 오래된 문서에서 나왔을 때, 답이 추정치일 뿐일 때, 전문가가 필요한 경우일 때 시스템이 그 사실을 보여 줘야 합니다. 대표는 상품 규칙, 서비스 지역, 가격 조건, SLA(서비스 수준 협약), 답할 수 없는 질문의 예시를 준비해야 합니다. "추측하면 안 되는 답"을 분명히 정해 두는 편이 프롬프트를 계속 늘리는 것보다 빨리 오픈하는 길입니다.
개발에 들어가기 전에 데이터 세트마다 책임자와 업데이트 방법을 정해야 합니다. CRM의 가격과 웹사이트 PDF의 가격이 다르면, 시스템은 어느 쪽이 진짜인지 알아야 합니다. 담당자가 콘텐츠를 고치고, 버전을 승인하고, 데이터가 바뀔 때 어떤 답변이 영향을 받는지 볼 수 있는 관리자 워크플로도 있어야 합니다.
안전한 오픈 계획은 검색과 요약만 하는 읽기 전용 컨시어지에서 시작합니다. 다음으로 예약 초안 만들기처럼 되돌릴 수 있는 액션을 열고, 그다음에야 고객이나 실제 자원에 영향을 주는 액션을 엽니다. 단계마다 실제 대화에서 뽑은 테스트 질문 세트와, 품질이 정해 둔 기준 아래로 떨어지면 되돌아가는 규칙을 두어야 합니다.
자주 발생하고 가치가 큰 의도는 무엇입니까?
진짜 데이터는 어느 시스템에 있습니까?
되돌릴 수 있는 액션은 무엇입니까?
즉시 직원에게 넘겨야 하는 경우는 무엇입니까?
메뉴 구조 대신 고객의 대화에서 출발하는 웹사이트를 설계합니다
DNA Maker는 고객과 영업팀 또는 서비스팀 사이에서 실제로 오간 대화를 듣는 데서 시작해, 고객사 팀과 함께 의도 맵(Intent Map), 고객 여정(Customer Journey), 액션 경계(Action Boundary)를 만듭니다. 지식 베이스에서 답할 것, CRM이나 가격 시스템에서 읽어 와야 할 것, 사람에게 물어야 할 것을 나누는 일도 돕습니다. 제품과 예외에 대한 지식은 여전히 고객사 팀의 것입니다. 저희는 그 지식을, 고객이 회사의 내부 구조를 몰라도 쓸 수 있는 흐름으로 바꿉니다.
설계 단계에서는 대화 프로토타입과 비교표, 입력 폼, 캘린더, 문서 업로드 같은 보조 화면을 만들어 고객이 질문에서 결과까지 실제로 갈 수 있는지 시험합니다. 큰 시스템을 만들기 전에 문구, 인계 지점, 최소 필요 데이터를 일반 사례와 답할 수 없는 사례 모두로 테스트합니다.
아키텍처는 업무에 맞춰 고릅니다. 모델 하나가 모든 질문에 답할 필요는 없습니다. 어떤 의도에는 고정된 규칙이 맞고, 어떤 의도에는 검색이 맞으며, 어떤 의도는 API를 호출해야 합니다. 저희는 액션마다 가치와 위험에 맞춰 모델 라우팅(Model Routing), 지식 인덱스, 권한, 감사 로그, 비용 통제를 설계합니다.
그래서 첫 단계의 결과물에는 보기 좋은 화면과 함께 여정 프로토타입, 의도 카탈로그, 데이터·도구 맵, 가드레일, 평가 세트, 그리고 현업 팀이 검토할 수 있는 시범 운영 계획이 들어갑니다. 오픈한 뒤에는 DNA Maker가 사용 데이터를 읽고 막다른 지점을 찾아 UX, 지식, 워크플로를 고칩니다. 시스템은 감이 아닌 근거를 바탕으로 나아집니다.
방향이 검증되면 DNA Maker는 웹사이트나 고객 포털, AI 컨시어지, CRM·캘린더 연동, 도구 승인, 분석 기능, 지식을 업데이트하는 관리자 화면을 개발하고, 오픈 후 평가와 모니터링까지 맡습니다. 팀이 매번 새 개발을 기다리지 않고 콘텐츠와 규칙을 고칠 수 있도록 설계합니다.
웹사이트에 트래픽은 있는데 고객이 여전히 같은 질문을 하려고 전화한다면, 실제 질문 30~50개를 가지고 이야기해 보십시오. 어떤 여정을 AI 대화로, 어떤 여정을 가이드형 입력 폼으로, 어떤 여정을 사람에게 넘길지 평가하고, Task Completion을 잴 수 있는 시범 운영을 설계해 드립니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
웹사이트 운영자가 고객의 의도부터 액션, 사람에게 넘기는 일까지 개발팀과 이야기할 때 쓰는 용어입니다. 마지막 열의 질문으로 프로젝트가 실제 결과를 재고 있는지, 대화 능력만 재고 있는지 확인해 보십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Intent | 사용자가 이루려는 목표. 설계 단계에서는 질문 분류에 이름만 붙이지 말고, 의도마다 필요한 데이터, 다음 단계, 성공의 정의를 연결해야 합니다. | 검색창에 "survey"를 입력한 고객이 실제로 원하는 것은 현장 조사 예약입니다. | 주요 의도를 실제 데이터로 파악했습니까, 아니면 짐작했습니까? |
| Tool Calling | AI가 시스템 기능의 호출을 요청하게 하는 방식. 도구 사용을 요청하는 쪽은 모델이지만, 실제로 실행하기 전에 소프트웨어가 매개변수, 권한, 결과를 확인해야 합니다. | 시간을 제안하기 전에 예약 일정을 확인합니다. | 모든 도구에 승인이 필요합니까? |
| Handoff | 맥락과 함께 AI에서 사람으로 일을 넘기는 것. 좋은 인계는 사실, 근거, 이미 시도한 일, 넘기는 이유를 모두 전달해 이어받는 사람이 바로 판단할 수 있게 합니다. | 영업팀이 고객에게 다시 묻지 않고도 요약을 받습니다. | 어떤 조건이면 즉시 사람에게 넘겨야 합니까? |
| Guardrail | 작업을 검사하거나 멈추는 규칙. 실행 전 규칙, 실행 후 결과 검사, 멈추고 사람을 부르는 조건이 모두 가드레일이 될 수 있으므로, 위험에 따라 여러 겹으로 설계해야 합니다. | 가격표에 없는 가격은 제시하지 않습니다. | 규칙의 책임자는 누구이고, 언제 다시 검토합니까? |
| Conversion Event | 사업 성과로 인정하는 사건. 채팅 열림이나 클릭 수만 세지 말고, 예약 완료나 정보 제출 완료처럼 실제 결과를 나타내는 이벤트를 정해야 합니다. | 예약 완료 또는 서류 제출 완료 | 우리는 대화를 재고 있습니까, 실제 성과를 재고 있습니까? |
더 읽을거리(원문 자료): https://openai.github.io/openai-agents-js/