업무지식 LLM 만들기 - 1차 시도

1. 처음 구상한 화면

화면은 크게 두 영역으로 나누려고 했습니다.

좌측: Chat / AI Agent

• 사용자가 업무 관련 질문 입력

• 관련 업무 문서 검색

• 검색된 문서를 근거로 답변 생성

• 답변에 참고한 문서 표시

• 근거가 부족하면 불확실하다고 안내

우측: Daily Update

• 새로운 업무지식 추가

• 기존 문서 수정

• 날짜별 업무 기록 관리

• Markdown 문서 미리보기

• 문서 분류와 태그 관리

핵심은 지식을 입력하는 화면과 조회하는 화면을 하나의 서비스 안에서 연결하는 것이었습니다.

2. 처음부터 Vector DB를 사용하지 않기로 했다

처음에는 RAG 시스템을 만들기 위해 Vector DB가 필요하다고 생각했습니다.

하지만 MVP 단계부터 임베딩, 문서 분할, 벡터 인덱스, 재검색 등의 기능을 모두 넣으면 구현 범위가 너무 커질 수 있었습니다.

그래서 다음 순서로 확장하는 방향을 검토했습니다.

1. Markdown 파일로 업무지식 저장

2. 파일명, 작성일, 태그 등의 메타데이터 관리

3. 키워드 기반 검색 구현

4. PostgreSQL 메타데이터 및 전문 검색 연결

5. 필요할 때 임베딩과 pgvector 추가

6. 권한 관리와 감사 로그 추가

PostgreSQL은 tsvector, tsquery를 이용한 전문 검색 기능을 제공하며, GIN 또는 GiST 인덱스로 검색 성능을 개선할 수 있습니다. 따라서 초기 단계에서는 별도의 Vector DB 없이 PostgreSQL 검색 기능부터 검토할 수 있습니다.

의미 기반 검색이 꼭 필요한 단계가 되면 PostgreSQL에 벡터 검색 기능을 추가하는 pgvector를 확장 선택지로 사용할 수 있습니다. pgvector는 정확·근사 최근접 이웃 검색과 코사인 거리 등의 검색 방식을 지원합니다.

3. Codex에 전달한 설계 프롬프트

한 번에 전체 코드를 만들어달라고 요청하지 않고, 먼저 MVP의 범위와 구현 순서를 정리하도록 요청했습니다.

너는 내부망 업무지식 AI Agent를 설계하고 구현하는 시니어 풀스택 개발자이자 솔루션 아키텍트다.

나는 회사 내부망 로컬 환경에서 업무지식 AI Agent를 만들고 싶다.

전체 목표:
좌측에는 업무지식에 대해 질문하고 답변받는 Chat / AI Agent 화면을 만든다.
우측에는 업무지식을 매일 추가·수정·관리할 수 있는 Daily Update 화면을 만든다.

회사에서는 일반 외부 LLM 접속이 제한되어 있으므로 EXAONE API를 호출해서 답변을 생성할 예정이다.

초기에는 복잡한 Vector DB보다 Markdown 원문 저장 + PostgreSQL 메타데이터/검색 인덱스 구조를 우선 검토한다.

가능하면 MVP는 Markdown 파일 저장 기반으로 먼저 만들고, 이후 PostgreSQL과 RAG 검색 구조를 붙인다.

중요 제약:
내부망 로컬 환경을 전제로 한다.
외부 SaaS 의존은 최소화한다.
Docker 사용은 우선 제외한다.
EXAONE API endpoint와 인증 방식은 아직 확정되지 않았으므로, 실제 호출부는 별도 client 파일로 분리하고 TODO 처리한다.
처음부터 Vector DB를 필수로 넣지 않는다.
PostgreSQL은 1차 확장 대상으로 설계한다.
답변은 반드시 근거 문서 기반이어야 한다.
근거가 부족하면 “확실하지 않음”이라고 답해야 한다.
업무지식 문서는 Markdown 형식으로 관리한다.
나중에 PostgreSQL, pgvector, 권한, 감사 로그를 붙일 수 있도록 구조를 확장 가능하게 설계한다.

개발 방식:
한 번에 전체 완성품을 만들지 말고 단계별로 진행한다.
각 단계마다 목표, 제외 범위, 파일 구조, 코드, 실행 방법, 검증 방법을 제시한다.
실행 불가능한 코드를 만들지 말고, 최소 실행 가능한 MVP부터 만든다.
확실하지 않은 기술 세부사항은 추정이라고 표시한다.

우선 1단계로, 전체 구현을 시작하지 말고 다음만 해줘.

이 프로젝트의 MVP 범위를 정의해줘.
화면 구조를 정의해줘.
추천 기술 스택을 제안해줘.
Markdown + PostgreSQL 기반 RAG 구조를 설계해줘.
초기 폴더 구조를 제안해줘.
어떤 순서로 구현해야 하는지 단계별 개발 계획을 제시해줘.

아직 코드는 작성하지 말고, 설계와 구현 순서만 먼저 제안해줘.

이 프롬프트에서 중요하게 생각한 부분은 세 가지였습니다.

• 역할 지정: 풀스택 개발자이자 솔루션 아키텍트로 역할을 명확히 지정

• 제약 조건 명시: 내부망, 외부 SaaS 제한, Docker 제외, API 미확정 등을 미리 설명

• 단계적 구현: 바로 코드를 생성하지 않고 MVP 범위와 개발 순서를 먼저 요청

4. 계획한 시스템 구조

[Daily Update]
      ↓
Markdown 문서 저장
      ↓
문서 메타데이터 및 검색 인덱스
      ↓
사용자 질문
      ↓
관련 문서 검색
      ↓
검색 결과를 EXAONE API에 전달
      ↓
근거 기반 답변 생성
      ↓
답변과 출처 문서 표시

초기에는 다음과 같은 단순한 폴더 구조를 생각했습니다.

knowledge-agent/
├─ frontend/
│  ├─ chat/
│  └─ daily-update/
├─ backend/
│  ├─ api/
│  ├─ services/
│  ├─ search/
│  └─ clients/
│     └─ exaone_client.py
├─ knowledge/
│  ├─ systems/
│  ├─ incidents/
│  └─ daily/
├─ metadata/
├─ tests/
└─ README.md

EXAONE 호출 부분은 API 엔드포인트와 인증 방식이 확정되지 않았기 때문에 다른 로직과 분리하는 방향으로 잡았습니다.

# backend/clients/exaone_client.py

def generate_answer(context: str, question: str) -> str:
    """
    EXAONE API를 호출해 근거 기반 답변을 생성한다.
    """

    # TODO: 사내 EXAONE API endpoint 확인
    # TODO: 인증 방식 및 요청 형식 확인
    # TODO: timeout, retry, error handling 추가

    raise NotImplementedError("EXAONE API 연동 정보가 필요합니다.")

현재 결과

아직 정상적으로 동작하는 화면이나 구체적인 데이터베이스 구조, 관리자 화면까지는 만들지 못했습니다.

따라서 이번 시도는 완성된 업무지식 AI 서비스 사례라기보다 다음 내용을 정리한 초기 설계 사례에 가깝습니다.

• 내부망 업무지식 LLM의 목적 정의

• Chat과 Daily Update로 구성된 화면 구상

• Markdown 중심의 초기 저장 방식 검토

• PostgreSQL과 pgvector를 이용한 단계적 확장 방향 정리

• EXAONE API 연동부 분리

• 단계별 MVP 개발 원칙 수립

배운 점 1. LLM보다 업무지식의 관리 방식이 먼저였다

처음에는 어떤 LLM을 사용할지가 가장 중요한 문제라고 생각했습니다.

하지만 실제로는 다음 질문이 더 중요했습니다.

• 어떤 내용을 업무지식으로 저장할 것인가?

• 문서를 누가 작성하고 수정할 것인가?

• 오래된 정보는 어떻게 표시할 것인가?

• 답변에 사용한 근거를 어떻게 보여줄 것인가?

• 잘못된 문서를 기반으로 답변하면 어떻게 할 것인가?

LLM은 저장된 정보를 설명해주는 역할을 할 뿐입니다. 원본 업무지식이 정리되어 있지 않으면 좋은 답변을 만들기 어렵습니다.

배운 점 2. 처음부터 거대한 RAG를 만들 필요는 없었다

업무지식 문서가 많지 않은 초기 단계에서는 Markdown 파일과 기본 검색만으로도 전체 흐름을 검증할 수 있습니다.

처음부터 Vector DB와 복잡한 검색 구조를 넣기보다 다음 과정을 먼저 확인하는 것이 중요하다고 느꼈습니다.

• 업무지식을 꾸준히 기록할 수 있는가?

• 실제 사용자가 질문을 입력하는가?

• 검색 결과가 업무에 도움이 되는가?

• 답변의 근거를 확인할 수 있는가?

이 흐름이 검증된 이후에 벡터 검색과 검색 품질 개선을 추가해도 늦지 않습니다.

배운 점 3. AI에게 코드를 요청하기 전에 범위를 제한해야 했다

AI에게 “업무지식 LLM을 만들어줘”라고만 요청하면 필요 이상의 기능과 복잡한 구조가 한꺼번에 생성될 수 있습니다.

반대로 다음 내용을 명확히 전달하면 결과를 통제하기 쉬워집니다.

• 이번 단계에서 만들 기능

• 이번 단계에서 제외할 기능

• 확정되지 않은 기술 요소

• 실행 환경의 제약

• 검증해야 할 항목

• 다음 단계로 넘어가는 기준

특히 “아직 코드를 작성하지 말고 설계와 구현 순서만 제안해달라”는 조건이 무분별한 코드 생성을 막는 데 도움이 되었습니다.

다음 계획

다음 단계에서는 전체 시스템을 한 번에 구현하지 않고, 가장 작은 흐름부터 확인할 예정입니다.

1. Markdown 업무지식 문서 작성 규칙 정의

2. 샘플 업무 문서 10~20개 작성

3. 문서 목록과 내용을 조회하는 API 구현

4. 키워드 기반 검색 기능 구현

5. Chat 화면에서 질문과 검색 결과 연결

6. EXAONE API 클라이언트 연결

7. 답변과 근거 문서 함께 표시

8. PostgreSQL 메타데이터 및 전문 검색 적용

9. 검색 품질이 부족할 경우 pgvector 검토

10. 권한 관리와 감사 로그 추가

이번 시도를 통해 얻은 가장 큰 교훈은 다음과 같습니다.

업무지식 LLM은 거대한 AI 시스템부터 만드는 프로젝트가 아니라, 업무지식을 작게 기록하고 정확하게 다시 찾는 구조부터 만드는 프로젝트다.

아직 완성된 결과물은 없지만, 구현 범위와 순서를 정리한 것만으로도 무엇부터 검증해야 하는지는 이전보다 분명해졌습니다.

도움 받은 글

• LG AI Research의 EXAONE 공식 소개 페이지에서 EXAONE 모델 계열과 공개 정보를 확인했습니다. 다만 사내에서 사용할 EXAONE API의 엔드포인트와 인증 방식은 별도로 확인해야 합니다.

• PostgreSQL 공식 문서의 전문 검색 구조와 tsvector, tsquery, GIN·GiST 인덱스 관련 내용을 참고했습니다.

• pgvector 공식 저장소에서 PostgreSQL 기반 벡터 유사도 검색의 확장 가능성을 확인했습니다.