복잡한 정부 사업 규정을 알려주는 챗봇이 필요하다
정부에서 지원하는 컨설팅 사업에 참여하고 있는 선배가 갑자기 서류 제출 기한을 놓쳤다. 수년간 사업에 참여한 전문가가 이런 실수를 범한 원인은 뭘까? 그건 개인의 부주의가 아닌 매년 바뀌는 복잡한 규정에 있었다. 정부 사업은 가이드북만 100페이지가 넘으며, 챙겨야 할 서류와 증빙 자료만 수십 가지에 달한다.
수행기관에서도 이를 지원하고자 여러 자료를 배포하지만 이는 오히려 컨설턴트가 읽어야 할 자료의 총량만 늘리는 결과를 낳기도 한다. 나 역시 작년부터 일터혁신상생컨설팅 사업의 컨설턴트로 활동하며 이러한 행정적 피로도를 체감했고, 금년에는 이를 해결하기 위해 제미나이 기반의 커스텀 챗봇인 Gems를 활용한 디지털 비서를 구축하기로 했다.
초기 단계에서는 별도의 어플리케이션개발도 검토하였으나, 빠른 적용을 위해 구글 Gems를 선택했다. 한 달을 소요하여 완벽한 시스템을 구축하기보다, 80점짜리 도구를 며칠 내로 만들어 사용하는 것이 컨설팅 현장에서는 더 가치 있기 때문이다. Gems는 코딩 없이도 지식 베이스를 구축하고 기존 워크플로우에 즉각 통합할 수 있는 유연함을 제공한다.
일터혁신 사업을 진행하기 위해서는 규정집, 일정표, 수행 가이드 등 다양한 자료를 봐야 한다. 처음에는 이 자료들을 PDF로 변환하여 업로드하는 것만으로는 Gesm가 제대로 된 답변을 하지 못했다. 왜일까?
PDF 형식은 인간의 눈에는 효율적이지만 AI 모델에게는 시각적 배치만 강조된 비정형 데이터에 불과하다. 텍스트의 계층 구조가 불분명하면 모델은 정보를 제대로 이해하지 못하고 엉뚱한 답을 내놓는다. 이 문제를 해결하기 위해 모든 데이터를 마크다운(Markdown) 형식으로 재구조화하는 전처리 과정을 거쳤다.
마크다운은 해시태그(#)를 활용해 정보의 위계를 명확히 정의한다. 이는 모델이 문서의 구조를 훨씬 정확하게 인덱싱하도록 돕는다. 표와 리스트를 정형화된 텍스트 형태로 유지함으로써 모델이 특정 데이터 사이의 관계를 오인할 확률을 현저히 낮춘다
정제가 필요한 자료는 크게 '규정집'과 '가이드라인'이었다. 이는 각각 아래의 방식을 통해 정제를 진행했다. 규정집은 파이썬 코드를 활용하여 정해진 규칙에 따라 전처리를 진행했고, 가이드라인은 PPT형태로 이미지가 많았기 때문에 멀티모델에 강점이 있는 Gemini Pro에게 가이드라인을 주고 작업을 하게 했다.
64페이지 분량의 규정집(한글 문서)
① 한글 문서를 PDF로 변환
② 파이썬 코드 활용 텍스트 추출
③ 제미나이 API 활용 마크다운 형식 변환
50페이지 분량의 가이드라인(PPT)
① PPT 문서를 PDF로 변환
② 각 페이지를 개별 파일로 분리
③ 제미나이에게 지침 입력
④ 페이지를 업로드하고 마크다운 형식으로 변환
초기 버전의 챗봇은 디테일을 놓치는 경우가 많았다. 이를 해결하기 위해 사고의 사슬(Chain of Thought, CoT) 기법을 활용해 지침을 재설계 했다. 챗봇이 질문을 받자마자 답을 내놓는 것이 아니라, 내부적으로 단계를 나누어 추론하도록 한 것이다.
일반적인 방식이라면 모델이 답을 직접 제시한다. 하지만 여기서는 의도적으로 생각하는 과정을 거치도록 지시했다. 이를 사고의 사슬(Chain of Thought, CoT)이라고 부른다. 이렇게 구성하면 모델의 '환각' 현상(즉, 근거 없이 답을 만드는 것)을 줄일 수 있다. 또한 답변이 틀렸을 때 어느 단계에서 실수했는지 명확히 파악할 수 있다.
제미나이나 지피티 같은 AI모델은 한 대화창에서 계속 대화를 진행하면 캐쉬가 쌓여 점점 응답의 정확도가 떨어진다는 문제가 발생한다. 마치 퇴근을 앞둔 직장인처럼 퇴근에 가까워질수록 점점 일을 대충 처리하는 것이다. 이를 방지하기 위해 과업별로 페르소나를 분리하여 모델의 성능을 극대화하는 하네스 엔지니어링 개념을 적용했다.
각 페르소나의 역할
기획자 페르소나 : 전체적인 로직 설계와 지식 베이스의 위계를 관리하며, 챗봇의 품질을 검증한다.
개발자 페르소나 : 데이터 정제를 위한 코드 검토 및 적성을 담당한다.
자료 정제 페르소나 : 시각 자료를 마크다운으로 변환하는 반복적이고 집중력이 필요한 과업에 집중한다.
챗봇을 만든 이후에는 성능을 끌어올리기 위해 실제 컨설팅 현장의 시나리오를 바탕으로 스트레스 테스트를 진행했다. 기획자 페르소나는 최종 산출물을 학습시킨 후 예상 가능한 날카로운 질문들을 던지며 답변의 정확성을 측정했다. 테스트 과정에서 일정 계산의 미세한 오차나 가이드북 하단의 작은 각주 내용을 놓치는 사례가 발견되었다. 이러한 구멍들은 자주 묻는 질문(FAQ) 파일을 보충하거나 지침을 수정하는 반복 작업을 통해 메워 나갔다.
다수의 자체 테스트와 수행기관 담당자와의 결과 공유를 통해 챗봇의 실효성을 확인했다. 이러한 챗봇은 단순한 규정 확인을 넘어 여러 방식으로 활용 가능하다. 예를 들면 정부 사업 제안(B2G) 시 수십 페이지에 달하는 제안요청서(RFP)를 학습시키고 대화를 통해 필수 서류나 가점 사항을 찾아낸다면 제안팀의 준비 시간을 획기적으로 줄일 수 있다.
하지만 기술적 한계에 대한 명확한 인식이 수반되어야 한다. Gems와 같은 챗봇의 가장 큰 제약은 자료량이 방대해질수록 답변의 디테일이 떨어진다는 점이다. 지침을 통해 이를 보완하려 노력하지만 모델이 모든 문서를 완벽히 훑지 못하고 정보를 누락하는 사례가 여전히 존재한다. 이를 극복하려면 자체 앱 개발과 같은 다른 방법을 탐색해야 한다.
또 다른 한계는 역할의 중복 수행 시 발생하는 오류다. 예를 들어 자료 검색에 특화된 챗봇에게 사업장 안내 메일 작성을 동시에 요청했을 때 잘못된 답변을 내놓는다. 이는 모델이 정보 탐색과 텍스트 생성이라는 서로 다른 층위의 과업을 동시에 처리하며 발생하는 혼선이다. 따라서 사용자는 반드시 단계적으로 접근해야 한다. 먼저 규정을 정확히 탐색하게 한 뒤 결과물을 검증하고, 이를 기반으로 별도의 채팅창에서 메일 양식을 잡는 등 프롬프트를 분리하여 활용해야 한다.
결국 Gems는 특정한 목적을 위해 빠르게 설계하고 사용하는 도구로서 그 장단점이 뚜렷하다. 단순히 PDF 자료를 여러 개 나열하거나 막연한 질문을 던지는 것만으로는 원하는 효과를 얻기 어렵다. 도구의 특징과 한계를 명확히 이해하고, 이를 보완할 수 있는 논리적 구조를 설계할 때 비로소 기술은 전문가의 강력한 파트너가 된다.