사내 문서를 찾아 답하는 기능, 고객 문의를 분류하는 기능, 보고서 초안을 만드는 기능을 검토하다 보면 곧 업체를 찾아야 하는 순간이 옵니다. 이때 많은 담당자가 “어느 모델을 쓰나요?” 또는 “비슷한 프로젝트를 해봤나요?”부터 묻습니다. 참고할 질문이지만, 그것만으로 우리 회사에서 쓸 수 있는 결과를 가리기는 어렵습니다.
AI 잘하는 개발사는 기술 이름을 먼저 늘어놓기보다, 업무가 멈추는 지점과 자료의 상태, 사람이 남아야 할 판단을 함께 좁힙니다. 첫 상담 전에 완성된 요구사항 문서를 만들 필요는 없습니다. 대신 작은 업무 하나를 설명할 수 있으면, 업체의 제안 방식과 프로젝트 운영 역량이 훨씬 선명하게 드러납니다.
기능 요청보다 먼저, 바꿀 업무 한 장을 만든다
“사내 문서 기반 챗봇이 필요합니다”는 아직 제품 요구사항이 아닙니다. 누가 언제 어떤 질문을 하는지, 지금은 답을 어떻게 찾는지, 틀린 답이 나왔을 때 어떤 일이 벌어지는지가 빠져 있기 때문입니다. 예를 들어 운영 담당자가 계약 조건을 찾는 데 시간이 걸린다는 문제와, 고객에게 즉시 안내할 답변이 필요하다는 문제는 같은 문서를 써도 다른 방식으로 시작해야 합니다.
상담 전에는 아래 내용만 한 장에 적어도 충분합니다. 이 문서는 업체에 기능을 지시하는 명세서가 아니라, 함께 첫 범위를 정하기 위한 출발점입니다.
- 누가 어떤 반복 업무에서 시간을 쓰는가
- 현재 입력으로 쓰는 문서나 데이터는 어디에 있는가
- 자료가 최신인지, 접근 권한에 제약이 있는지
- AI가 답한 뒤 사람이 확인하거나 결정해야 하는 지점은 어디인가
- 이번 단계에서 하지 않을 일은 무엇인가
가령 “제한된 운영 매뉴얼에서 답을 찾고, 담당자가 확인한 후 고객에게 전달한다”까지 정리됐다면 첫 검증의 형태가 잡힙니다. 반대로 모든 문서를 연결해 전 업무를 자동화해 달라는 요청만 있다면, 화면은 만들 수 있어도 업무 효과와 오류 범위를 판단하기 어렵습니다. 좋은 개발사는 이 빈칸을 숨기지 않고 조사할 일과 개발할 일을 나눠 제안합니다.
업체의 실적보다 제안 과정에서 봐야 할 장면
공공·금융 분야 납품 이력, 고객사 로고, 특정 기술 파트너십은 업체를 알아보는 단서가 될 수 있습니다. 다만 다른 산업의 자료 품질, 승인 절차, 사용자 습관까지 보장하지는 않습니다. 우리 회사에 맞는 업체인지 보려면 “무엇을 만들었는가”보다 “불완전한 요청을 어떻게 첫 실험으로 바꾸는가”를 확인하는 편이 낫습니다.
첫 미팅에서는 세 가지 질문을 던져 보십시오. “우리 업무 중 어디부터 확인해 볼까요?”, “이 자료를 실제로 쓸 수 있는 상태인지 어떻게 확인하나요?”, “잘못된 답이 나오면 누가 무엇을 보고 고치나요?”입니다. 답변이 모델명과 화면 구성에만 머문다면, 운영 조건은 아직 제안에 들어오지 않은 상태일 수 있습니다.
반대로 신뢰할 만한 제안은 작은 범위를 권합니다. 사용자 한 유형, 제한된 문서 묶음, 자주 나오는 질문 몇 가지를 고르고, 답할 수 없는 질문은 담당자에게 넘기는 방식입니다. 이때 업체는 “이번에는 하지 않을 것”도 말할 수 있어야 합니다. 자료 정리나 권한 확인이 먼저라면 그것을 별도 단계로 두는 편이, 개발 뒤에 예상치 못한 지연을 맞는 것보다 낫습니다.
검증 결과를 운영에 넘길 수 있어야 프로젝트가 끝난다
작은 검증 단계의 산출물은 시연 화면만이 아닙니다. 어떤 질문에는 잘 답했고 어떤 질문에는 답하지 못했는지, 사람이 확인한 뒤 어떤 오류를 발견했는지, 자료가 바뀌면 누가 반영할지를 남겨야 다음 단계의 투자 판단이 가능합니다. 정확도 하나의 숫자로 업체를 비교하기 어려운 이유도 여기에 있습니다. 고객 안내 업무는 틀린 답을 막는 일이 중요할 수 있고, 내부 초안 작성은 속도와 수정 편의가 더 중요할 수 있습니다.
운영으로 넘어갈 때는 일상적인 상황 하나를 기준으로 대화를 마무리하면 좋습니다. 예를 들어 매뉴얼이 개정됐는데 이전 규정을 답한다면, 누가 자료를 교체하고 어떤 답변이 영향을 받았는지 확인할 수 있어야 합니다. 민감한 자료가 포함된다면 자료가 어느 단계에서 누구에게 전달되는지와 접근 가능한 사람을 미리 정해야 합니다. 이는 특정 국가의 규정을 그대로 적용하자는 뜻이 아니라, 나중에 서로 다른 이해로 문제를 키우지 않기 위한 실무적 준비입니다.
첫 AI 프로젝트에서 업체를 고르는 일은 가장 화려한 기능을 고르는 일이 아닙니다. 상담 전에 한 업무, 한 자료 범위, 한 사람의 판단 지점을 적어 보십시오. 그 조건에서 무엇을 시험하고 무엇을 남길지까지 설명하는 개발사라면, 막연한 AI 요청을 운영 가능한 프로젝트로 바꿀 가능성이 높습니다.
