처음부터 선택할 수 없었던 제품 선정 과정: 블랙박스 챗봇을 '가시적인 시스템'으로 바꾸고 싶어서
요약
기존의 블랙박스 형태 AI 챗봇은 처리 과정 추적이 불가능하여 문제 해결에 한계가 있었습니다. 필자는 답변 생성, 검색, 질문 식별 과정을 분해하고 단계별 출력을 확인할 수 있는 워크플로우 기반 애플리케이션으로 전환하는 것을 목표로 했습니다. 보안 및 예산 제약으로 인해 Dify를 선택하게 되었으며, 이는 제한적인 기능에도 불구하고 현재 상황 개선에 필요한 첫걸음이었습니다.
핵심 포인트
- 블랙박스 챗봇의 한계: 처리 과정 추적 불가
- 목표 전환: 워크플로우 기반 애플리케이션 구축
- 기술적 제약 극복: Dify를 활용한 현실적 대안 모색
- 현실적인 개발 환경 고려: 보안 및 예산 제약이 주요 변수
그룹사 경리 및 급여 업무를 위탁하는 회사로 이동했을 때, 저를 기다리고 있던 것은 AI 챗봇의 정밀도 개선 프로젝트였습니다.
저희 회사의 주력 개발 방식인 벤더(vendor) 위탁 개발이 아니라 사내 자체 개발이었기 때문에, 저는 그곳에 유일한 기술직 채용 사원으로 배치되었고, 저 스스로가 벤더 포지션으로 움직여야 하는 상황을 맞았습니다. (이것은 좋은 경험을 쌓을 수 있을 거라며 기뻐했던 기억입니다.)
현재의 챗봇은 정밀도 면에서는 80% 이상의 정답률을 보이고 있지만, 어째서인지 '답변할 수 없다'고 응답하는 확률이 60%를 넘어서는 상황이었습니다.
즉, 문의에 대해 절반 이상 답변하지 못하고, 소수의 질문에는 확실하게 답변하고 있다는 미스터리한 상태였습니다.
그래서 저는 사용 중인 제품들부터 순서대로 정리해 나갔습니다.
AI 챗봇의 경우, Azure를 기반으로 한 다른 그룹사의 독자적인 서비스가 사용되고 있었습니다.
이 서비스에는 큰 제약이 있었습니다.
그것은 바로
프롬프트 하나로 모든 것을 통제해야 한다
였습니다.
즉,
- 질문의 종류를 식별하고
- 관련 자료를 검색하며
- 답변을 생성하는
이러한 일련의 처리 과정을 모두 하나의 지시문(프롬프트)에 담아 작성하고, 나머지는 AI에게 맡겨 실행할 수밖에 없었습니다.
프롬프트에는 원하는 처리 순서를 위에서부터 차례로 적어 놓았습니다. 하지만 AI가 실제로 그 순서대로 작동하는지 확인할 방법이 없습니다.
당시 전임자가 1000줄 가까운 지시문을 프롬프트에 작성해 주었습니다. 기술직 사원이 아님에도 불구하고 본업인 결산 업무를 병행하며 이렇게 많은 내용을 작성해 준 것은 고개가 숙여질 정도였지만, 이 1000줄의 지시를 AI가 그대로 해석하고 실행하고 있다고는 도저히 믿기 어려웠습니다.
이 서비스에서는 어떤 처리가 어떻게 잘못되었는지 특정할 수 없었습니다. 모든 과정이 AI에게 맡겨진 블랙박스였기 때문입니다.
고치고 싶어도, 어디를 고쳐야 할지 보이지 않는 것이 가장 큰 벽이었습니다.
(이것이 프롬프트 엔지니어링의 종말인가 실감했습니다...)
그래서 저는 처리 과정을 하나하나 단계로 분해하고, 각각이 어떤 처리를 했으며 무엇을 출력했는지 확인할 수 있는 시스템이 필요하다고 생각했습니다.
즉, 처리 흐름(워크플로우)을 자체적으로 구성할 수 있는 애플리케이션으로 전환하는 것이었습니다.
여기서 큰 제약이 있었습니다.
회사원들 사이에서는 흔히 부딪치는 문제라고 생각합니다.
- 보안 요구 사항이 매우 엄격함(새로운 소프트웨어를 사용하려 하면 보안 진단이나 신청 등으로 막대한 업무가 소요되고, 도입할 수 있다 하더라도 기능이 제한적이어서 좋은 기능을 사용할 수 없음)
- 새로운 툴을 도입할 예산이 없음
따라서 현실적인 선택지는 '이미 보안 심사를 거쳐 도입된 환경에 탑승하는 것'밖에 없었습니다.
그 조건에 맞는 유일한 선택지가 Dify였습니다.
(기능 제한이 많지만, 도입을 위해 노력해 준 사원들에게는 감사할 따름입니다.)
솔직히 말하자면, 처음부터 이상적인 툴을 고른 것은 아닙니다. 'Dify가 최고라서 선택했다'가 아니라, '조건을 충족하는 것이 Dify뿐이었고, 워크플로우를 구성할 수 있다는 목적에도 적합했기 때문'이 실정입니다.
- 사용할 수 있는 기능 블록이 제한적이다
- 파일 다운로드가 불가능하다
처음에는 작은 제약이라고 생각했고 Dify밖에 선택지가 없었기에 이것으로 진행할 수밖에 없는 것이 솔직한 상황이었습니다.
최소한 현재 상황보다는 나아질 것이고, 저의 업무만으로 비용도 들지 않으니 검증 결과에 따라 철수하는 방향을 최악의 수단으로 가지고 있어도 괜찮을 거라고 생각하며 진행했습니다. (회사원의 장점이죠)
이 제약 사항들이 예상보다 큰 벽이 되어 앞으로 등장하게 됩니다.
- 툴의 한계는 '정밀도가 낮은 원인을 알 수 없다'는 형태로 나타났다.
- 필요했던 것은 처리를 단계별로 나누어 출력을 확인할 수 있는 시스템이었다.
- 보안이나 예산 제약으로 선택할 수 있는 범위가 제한된 가운데 최선의 선택을 했다.
- 제약 속에서도 '처리가 보인다'는 목적에 맞는 것을 고른다.
- 프롬프트 엔지니어링의 한계
- 프롬프트 엔지니어링의 종말
- 회사원은 좋은 기술이 세상에 있어도 사용할 수 없는 제약이 많다
다음 기사에서는 이 챗봇의 답변 정밀도를 높이기 위해 했던 일들을 쓸 예정입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기