안녕하세요! 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다 :)

AI 챗봇을 서비스에 도입하면 고객 문의가 줄고, 사용자 경험이 좋아질 거라고 생각하기 쉽습니다. AI 기술은 이미 충분히 발전했기 때문에, API 하나만 연결하면 되는 거라고 생각하기 쉬운데요! 저희도 B2B 영업 SaaS인 플러그(pluuug)에 AI 챗봇 '콘센트'를 붙이면 고객 응대 효율이 올라갈 거라 확신했습니다.

하지만 몇 달간 개발해서 출시한 콘센트의 성적표는 참담했습니다. 이 글에서는 콘센트 V1의 실패 원인을 분석하고, V2에서 어떤 구조적 변화를 시도하고 있는지 정리하겠습니다. 똑똑한개발자 내부 'AI 활용 방식 공유회'에서 pluuug팀의 프론트엔드 개발자 박우현 님이 발표한 내용을 바탕으로 구성했습니다.

출시 후 첫 피드백: "버튼 위치 좀 바꿔주세요"

콘센트를 내놓고 가장 먼저 들어온 고객지원 요청은 챗봇 답변 품질과는 전혀 관계없는 UI 문제였습니다. 플러그의 새 AI 챗봇인 콘센트를 여는 버튼 위치가 불편하다는 것이었습니다.

챗봇 내부에 마련해둔 답변 평가 버튼은 출시 이후 한 번도 눌리지 않았고, 질문도 하지 않고 이탈하는 비율이 예상보다 훨씬 높았습니다. 가장 아이러니한 것은, 그나마 콘센트를 가끔 쓰던 고객이 "이 기능 없애주세요"라고 요청했다는 것입니다. 기능의 존재 자체가 사용자에게는 사실상 무의미했던 거죠.

AI 챗봇 콘센트 V1이 실패한 세 가지 원인은

1. 범용 AI 챗봇은 아무것도 잘 못한다

콘센트 V1 설계의 출발점은 이랬습니다.

“pluuug의 비즈니스 도구를 전부 AI에게 노출하고, AI가 알아서 골라 쓰게 하자”

어떤 상황에 어떤 도구를 써야 하는지 기준도 없이, 일단 다 붙여보려고 시도했습니다. 당연하게도 이 구조는 금세 무너졌습니다.

사용자가 견적서 수정 방법을 자연어로 물으면, AI가 도메인 데이터를 파악하고 맞는 도구를 호출해 단계별로 안내해주길 기대했습니다. AI 에이전트의 스킬 아키텍처에서 아이디어를 얻어 비즈니스 로직을 도구 단위로 쪼개는 방식까지 구상했는데, 이론과 현실은 너무나도 달랐습니다.

2. 비용이 감당이 안 됐다

로컬 테스트 환경에서는 고품질 모델에 넉넉한 컨텍스트를 제공하는 게 문제가 되지 않습니다. 하지만 전체 사용자 대상으로 서비스하면 비용이 급격히 올라갑니다. 허용된 토큰 안에서 정확한 답변을 뽑아내려면 고려해야 할 변수가 계속 늘어났습니다.

3. AI에게 줄 정보의 기준이 없었다

AI가 정확히 답하려면 비즈니스 플로우, 채팅 기록, 현재 화면 상태, 도구 응답까지 파악해야 합니다. 그런데 어떤 정보를 어디까지 전달해야 하는지 기준 자체가 없었습니다. 구현 과제만 기준 없이 쌓여갔고, 출시 전날에는 기능 개선 대신 API 차단, 내부 ID 제거, 토큰 제한 같은 보안·비용 방어에 매달리게 됐습니다. 방향이 잘못됐다는 건 알았지만, 출시 일정을 늦출 수는 없었습니다.

챗봇 개발 실패 경험에서 배운 두 가지 교훈

첫 번째, AI에 과하게 기대면 판단력이 흐려진다

잘 모르는 부분을 AI로 동작하는 것처럼 만드는 것과, 신뢰할 수 있는 프로덕트로 내놓는 것은 완전히 다른 문제입니다. AI에 기대다 보면 지금 가고 있는 방향이 맞는지 스스로 점검하기가 어려워집니다. 보안 정책이나 아키텍처 결정처럼 중요한 판단까지 AI에 맡겨선 안 됩니다.

두 번째, 스코프를 좁게 잡아야 한다

충분한 준비 없이 "모든 걸 해결하는 AI 챗봇"을 목표로 삼은 것 자체가 실패의 시작이었습니다. 처음부터 범위를 너무 넓게 설정했고, 감당이 되지 않았습니다.

AI 챗봇 콘센트 V2, 뭐가 달라질까요?

V1 실패를 거치며 내린 결론은 이렇습니다.

"한꺼번에 다 하려는 대신, 특정 기능 하나를 확실히 잘하는 AI를 먼저 만들고, 검증이 끝나면 다음으로 넘어가자."

도메인을 하나씩 검증한다

V2에서는 전체 도메인을 한 번에 다루지 않습니다. 하나를 선택하고, 실제 사용자 흐름 기준의 블랙박스 회귀 테스트로 품질을 검증합니다. 일관된 결과가 나오면 그때 다음으로 확장합니다.

도구 선택을 단계적으로 좁힌다

AI에게 한꺼번에 너무 많은 도구를 보여주면 추론 정확도가 떨어집니다. V2에서는 도메인 선택 → 해당 도메인 툴 목록 제시 → 툴 선택 → 스키마 확인이라는 단계를 밟아 선택지를 점진적으로 좁혀갑니다.

컨텍스트를 선별해서 전달한다

V1에서는 대화 로그와 도구 기록을 그대로 넣어줬고, AI가 맥락을 혼동하는 일이 잦았습니다. V2에서는 정리된 대화 로그, 스키마, 제약 조건처럼 AI에게 진짜 필요한 정보만 골라서 전달합니다. 잘못된 응답이 나오면 런타임 후처리 대신 AI가 직접 수정하도록 하는 방식도 도입합니다.

기존 기능 보조를 넘어선 역할

견적서 변환이나 고객 데이터 마이그레이션 제안처럼, 고객이 실제로 필요로 하는 것을 직접 해결하는 특화 기능이 V2의 다음 목표입니다.

예측 불가능한 AI 개발, 어떻게 다뤄야 할까요?

기존 코딩은 같은 입력에 같은 결과가 나옵니다. 하지만, AI는 다릅니다. 같은 프롬프트에도 응답이 천차만별이고, 이 비결정성이 AI 코딩 초기에 느끼는 불편함의 핵심입니다. 프롬프트 엔지니어링 같은 접근이 이를 보완하는 새 패러다임으로 자리 잡고 있지만, 올바른 판단은 여전히 사람의 몫입니다.

저희 똑똑한개발자에서는 AI 프로덕트를 직접 만들면서 부딪힌 경험들을 조직 전체의 노하우로 만들어가고 있습니다. AI 도입이나 AX 전환을 고민 중이시라면, 똑똑한개발자에게 편하게 문의해 주세요.

감사합니다 :)

[🔗 비즈니스 AX 컨설팅 문의하기]