복잡한 제품 정책이 팀을 헤매게 만들 때

SSOT + LLM 챗봇으로 ‘정보 파악 비용’을 줄인 방법

by 일이삼사

제품이 고도화되면서 정책의 수와 복잡도는 빠르게 늘어났다.

하지만 실제 업무에서는 다음과 같은 문제가 반복됐다.

정책 히스토리와 의사결정 맥락을 아는 사람이 제한적이었다.

문서화가 되어 있어도 버전 불일치와 갱신 누락으로 신뢰성이 낮았다.

검색 시 구글 드라이브, 위키, 노션 등 다양한 저장소를 거쳐야 했고, 결과적으로 사람에게 직접 묻거나 코드 확인에 의존했다.


이로 인해 제품 대응 및 개발 단계에서 정책 파악 비용이 과도하게 발생했다.

이 문제를 해결하기 위해 아래의 목표로 프로젝트를 시작했다.

정책 파악 비용을 절감하고, 최신/일관된 정보에 기반한 의사결정 체계를 구축한다.



해결 전략: SSOT × LLM 챗봇

접근 방식은 단순하다.

llm.png


(1) 정책을 SSOT(Single Source of Truth)로 모은다.

(2) 이 데이터를 LLM이 읽기 좋은 구조로 만든다.

(3) 챗봇과 연결하여 팀이 질문하면 즉시 답변할 수 있도록 한다.


이 과정에서 세 가지 요구사항을 정의했다.

table.png




1. Google Sheet로 SSOT 구축

정책을 흩어져 관리하는 대신, 하나의 단일 소스로 모았다.

가장 접근성이 높고 익숙한 Google Sheet를 선택했다.


선택 이유

낮은 진입 장벽: 누구나 브라우저에서 바로 열고 수정이 가능하다.

정책 단위 관리: 정책을 Row 단위로 정의해 추가/수정/비교가 용이하다.

자동화 친화성: API, n8n, Apps Script 등과 쉽게 연동할 수 있다.


운영 방식

정책 하나 = Row 하나를 가진다.

각 Row에는 고유 식별자(policy_id) 부여했다.

주요 항목은 컬럼으로 구분하여 작성한다.


효과
- 산발적으로 퍼져 있던 정책 문서를 한 화면에서 조회할 수 있게 되었다.
- “어디에 최신 정책이 있나?”라는 질문이 줄고, 팀은 항상 같은 출처를 참고하게 되었다.
- 이후 JSON 변환 및 LLM 연동을 위한 기초 데이터베이스 역할을 하게 되었다.



2. 필드 정의 & 템플릿화

필드 설계 예시

SSOT라는 그릇을 만들었더라도, 작성자마다 표현이 다르면 같은 정책도 중복/누락되거나, AI가 해석하기 어려운 데이터가 된다.


그래서 두 번째 단계에서는 필드 체계를 명확히 정의하고, 이를 템플릿으로 고정했다.





운영 방식

모든 작성자는 반드시 정의된 필드에 맞춰 기록한다.

드롭다운/유효값 목록을 적용해 오타나 표현 불일치를 최소화했다.

policy_id 네이밍 패턴 규칙을 정한 뒤 함수로 제약을 걸어 자동으로 생성되게끔 했다.


효과
- 작성자마다 다르게 표현되던 정책이 표준화된 구조로 정리되었다.
- AI가 활용하기 좋은 정형화된 데이터셋을 확보할 수 있었다.
- 정책 변경 시에도 고유 ID 기준으로 손쉽게 추적/비교가 가능해졌다.



3. JSON 변환

구글 시트는 사람이 보기엔 편리했지만, AI가 직접 활용하기에는 서술형 데이터로서 한계가 있었다.

정책 데이터를 LLM이 효과적으로 검색/이해하려면 기계가 읽을 수 있는 구조화된 포맷이 필요했다.

그래서 세 번째 단계에서는 시트 데이터를 JSON으로 변환했다.


왜 JSON인가

구조화된 파싱 가능: Key-Value 형태로 각 필드를 명확히 구분할 수 있다.

검증 가능: JSON Schema를 활용하면 필수값 누락, 포맷 오류 같은 문제를 자동으로 걸러낼 수 있다.

업데이트 효율성: 정책 하나 = JSON 객체 하나로 매핑되기 때문에, 변경된 정책만 추출·교체하기 쉽다.

재사용성: 이후 API 연동, 챗봇 지식베이스, 로그 분석 등 다양한 곳에서 동일한 포맷으로 활용할 수 있다.



4. LLM 연결 & 실시간 동기화

JSON 변환으로 기계가 읽을 수 있는 정책 데이터를 확보한 다음 단계는, 이를 LLM과 연결하고 항상 최신 상태로 유지하는 일이었다. 정책은 수시로 바뀌기 때문에, 단순히 “정적 파일”을 업로드 해두는 방식으로는 곧바로 낡아버린다. LLM 응답의 신뢰성을 확보하려면 연결성과 신선도가 동시에 필요하다.


운영 방식

(1) WebUI 지식베이스 연동

변환된 JSON을 WebUI 지식베이스에 업로드

LLM 프롬프트에 persona/context/action을 강조하여 정책과 질문의 연결성을 높임

응답 포맷에 [policy_id] 인용을 강제하여, 항상 근거를 확인할 수 있도록 설정


(2) 실시간 동기화 (아직 미진행, 아래의 단계를 고려하고 있다.)

Google Sheet 변경 감지 → JSON 자동 변환 → WebUI 업서트(upsert)

스키마 검증 실패 시 슬랙 알림 및 에러 로그 기록

“변경 후 10분 이내 반영”과 같은 신선도 SLA 설정


효과
- 직접 문서를 찾지 않아도 챗봇에게 자연어로 질문해 즉시 필요한 정책을 확인할 수 있다.
- 정책 해석에 불필요한 논쟁이 줄고, 팀이 같은 근거를 공유하게 되었다.




배운 점과 의미

기록은 구조화될 때 비로소 지식이 된다.

문서를 자유롭게 쌓아두는 것으로는 문제를 해결할 수 없었다. 특정인에게 의존하던 기록을 고유 ID, 필드 체계, 자동 검증을 통해 데이터로 전환하자 누구나 필요한 정보를 찾아 활용할 수 있게 되었다.


또한 정책을 데이터 자산으로 쌓아가기 시작하면 활용 범위는 훨씬 넓어진다.

새로운 기능 설계 시 기존 정책과 충돌·중복 자동 탐지

여러 정책을 종합해 더 나은 고객 여정이나 운영 플로우 제안

특정 영역의 정책 브리핑·의사결정 히스토리 자동 생성


즉, 이번 시도는 단순히 정책 파악 비용을 줄이는 데 그치지 않는다.

앞으로는 정책 데이터 기반 의사결정 어시스턴트로 발전할 수 있지 않을까 기대해 본다.




작가의 이전글ChatGPT로 VOC 분석하기