[ContentOps Agent #2] 요구사항 정의

[ContentOps Agent #2] 요구사항 정의

1. 시작하며

지난 글에서는 ContentOps Agent 프로젝트를 시작한 이유와 학습 목표를 정리했다.

이번에는 실제 구현에 들어가기 전에 ContentOps Agent가 어떤 데이터를 가지고 어떤 질문을 처리해야 하는지 요구사항을 정의해보려고 한다.

이번 프로젝트의 목적은 기능이 많은 AI 서비스를 만드는 것이 아니다.

핵심은 다음과 같은 문제를 직접 확인하는 것이다.

Vector Search만으로 충분한가?

Chunk 크기에 따라 검색 결과가 달라지는가?

정확한 Keyword가 필요한 질문은 어떻게 처리해야 하는가?

정답 문서를 찾았는데도 LLM이 틀릴 수 있는가?

검색 품질이 실제로 좋아졌다는 것을 어떻게 판단할까?

질문에 따라 문서 검색과 DB 조회를 구분할 수 있을까?

Agent가 필요한 Tool을 제대로 선택할까?

따라서 처음부터 Hybrid Search, Reranker, LangGraph 같은 기능을 모두 넣지 않는다.

먼저 가장 단순한 RAG를 구현하고 평가 Dataset을 이용해 실제 실패 Case를 확인한 뒤 필요한 기능을 하나씩 검토한다.

---

2. 서비스 범위

ContentOps Agent는 OTT 콘텐츠 운영자가 자연어로 질문하면 운영 문서와 콘텐츠 데이터를 검색하고, 검색된 정보를 근거로 답변하는 AI Backend다.

기본적으로 두 종류의 데이터를 사용한다.

운영 문서
+
콘텐츠 데이터

운영 문서에는 다음과 같은 정보가 있다고 가정한다.

콘텐츠 등록 정책

연령 등급 정책

공개 상태 정책

Metadata 작성 가이드

운영 FAQ

Error Code 가이드

콘텐츠 Database에는 다음과 같은 정보가 존재한다.

콘텐츠 ID

제목

장르

연령 등급

공개 상태

공개 예정일

서비스 지역

Metadata 상태

운영자가 질문하면 질문의 종류에 따라 적절한 정보를 찾아 답변한다.

예:

"15세 콘텐츠 공개 조건이 뭐야?"

↓

운영 문서 검색

또는:

"8월 공개 예정 액션 콘텐츠 알려줘."

↓

콘텐츠 DB 조회

두 정보가 모두 필요한 질문도 존재할 수 있다.

"콘텐츠 100번이 왜 공개되지 않는지 정책 기준으로 설명해줘."

↓

콘텐츠 상태 조회
+
운영 정책 검색
+
결과 조합

실제 콘텐츠 등록이나 수정 같은 Write 기능은 이번 프로젝트의 핵심 범위에서 제외한다.

---

3. 주요 구성 요소

ContentOps Agent는 최종적으로 다음 구성 요소를 가질 수 있다.

3.1 Question API

사용자가 자연어 질문을 전달하는 API다.

예:

POST /api/v1/questions

요청을 받으면 현재 Phase의 처리 구조에 따라 RAG 또는 Agent Workflow를 실행한다.

---

3.2 Policy Document

콘텐츠 운영자가 참고하는 내부 정책 문서다.

예:

age-rating-policy.md

content-status-policy.md

metadata-guide.md

publishing-guide.md

operations-faq.md

실제 회사 내부 문서를 사용하는 것이 아니라 프로젝트용 Sample Document를 직접 구성한다.

---

3.3 Document Chunk

운영 문서는 검색을 위해 여러 Chunk로 나누어 저장한다.

예:

age-rating-policy.md

↓

Chunk 1
연령 등급 정의

Chunk 2
15세 콘텐츠 공개 조건

Chunk 3
18세 콘텐츠 공개 조건

각 Chunk는 원본 문서와 위치를 추적할 수 있어야 한다.

---

3.4 Embedding

각 Document Chunk를 Embedding Vector로 변환한다.

Document Chunk

↓

Embedding Model

↓

Vector

질문 역시 동일한 Embedding 방식으로 Vector로 변환한다.

---

3.5 Vector Store

Embedding된 Document Chunk를 저장하고 유사도 검색을 수행한다.

초기에는:

PostgreSQL
+
pgvector

구조를 사용한다.

---

3.6 Content Database

OTT 콘텐츠 Metadata를 저장한다.

예:

Content

id
title
genre
ageRating
status
releaseDate
serviceRegion
metadataStatus

초기 단순 RAG 단계에서는 콘텐츠 DB 조회 기능을 사용하지 않는다.

Agent 단계에서 Tool로 사용한다.

---

3.7 LLM

검색된 Context를 이용해 최종 답변을 생성한다.

LLM은 검색되지 않은 내부 정책이나 콘텐츠 정보를 알고 있다고 가정하지 않는다.

가능한 한 전달된 Context를 근거로 답하도록 구성한다.

---

3.8 Evaluation Dataset

RAG와 Agent의 품질을 반복적으로 측정하기 위한 평가 데이터다.

이번 프로젝트에서 매우 중요한 구성 요소다.

예:

질문기대 문서기대 Tool

15세 콘텐츠 공개 기준은?	age-rating-policy.md	Policy Search
M-03 오류가 뭐야?	metadata-guide.md	Policy Search
8월 공개 콘텐츠는?	-	Content Search
콘텐츠 100 상태는?	-	Content Detail
콘텐츠 100이 왜 공개 불가야?	content-status-policy.md	Content Detail + Policy Search

Baseline부터 Final까지 가능한 한 동일한 Dataset을 이용한다.

---

4. 운영 문서 구조

프로젝트에서는 검색 품질을 실험할 수 있도록 서로 비슷하지만 역할이 다른 문서를 준비한다.

예:

documents/

├── age-rating-policy.md
├── content-status-policy.md
├── metadata-guide.md
├── publishing-guide.md
├── youth-protection-policy.md
└── operations-faq.md

검색이 지나치게 쉬운 Dataset만 만들지 않는다.

예를 들어:

질문

"15세 콘텐츠 공개 기준은?"

문서

15세 콘텐츠 공개 기준.md

처럼 질문과 문서 제목이 거의 동일하면 Retrieval 전략의 차이를 확인하기 어렵다.

따라서 일부 문서는 의미가 겹치도록 구성한다.

연령 등급 정책

청소년 보호 정책

콘텐츠 공개 정책

또한 정확한 Keyword 검색이 필요한 데이터를 포함한다.

OPS-101

CONTENT_BLOCKED

M-03

AGE_REVIEW_REQUIRED

이를 통해 Semantic Search와 Keyword Search의 차이를 실제로 확인할 수 있도록 한다.

---

5. 콘텐츠 데이터 모델

Agent 단계에서 사용할 콘텐츠 데이터는 다음 정도로 단순하게 구성한다.

예:

{
  "id": 100,
  "title": "Sample Action Movie",
  "genre": "ACTION",
  "ageRating": 15,
  "status": "BLOCKED",
  "releaseDate": "2026-08-25",
  "serviceRegion": "KR",
  "metadataStatus": "INCOMPLETE"
}

주요 필드는 다음과 같다.

필드의미

id	콘텐츠 ID
title	콘텐츠 제목
genre	장르
ageRating	연령 등급
status	공개 상태
releaseDate	공개 예정일
serviceRegion	서비스 지역
metadataStatus	Metadata 상태

실제 OTT의 복잡한 콘텐츠 Domain을 재현할 필요는 없다.

Agent가 구조화된 데이터 조회 Tool을 사용하는 실험이 가능할 정도만 구현한다.

---

6. 기능 요구사항

FR-01. 자연어 질문 수신

사용자는 자연어 질문을 전달할 수 있어야 한다.

POST /api/v1/questions

예:

{
  "question": "15세 콘텐츠의 공개 조건이 뭐야?"
}

질문이 없거나 비어 있다면 요청을 거절한다.

---

FR-02. 운영 문서 등록

RAG에 사용할 운영 문서를 시스템에 등록할 수 있어야 한다.

초기에는 관리자 UI를 구현하지 않는다.

다음과 같은 방식이면 충분하다.

Application Startup

또는

CLI / Batch

또는

Test Fixture

중요한 것은 같은 문서를 반복적으로 적재하고 실험 환경을 다시 만들 수 있어야 한다는 것이다.

---

FR-03. 문서 Chunk 생성

등록된 문서를 검색 가능한 단위로 나눌 수 있어야 한다.

Chunk에는 최소한 다음 정보가 존재해야 한다.

chunkId

documentId

documentName

content

section

chunkIndex

초기 Chunking 방식은 단순한 전략으로 시작한다.

Chunk Size나 Overlap 최적화는 Baseline 이전에 하지 않는다.

---

FR-04. Embedding 생성

각 Chunk를 Embedding Vector로 변환할 수 있어야 한다.

Chunk

↓

Embedding Model

↓

Vector

질문 역시 동일한 Embedding Model을 사용하여 Vector로 변환한다.

---

FR-05. Vector 저장

생성된 Embedding은 PostgreSQL + pgvector에 저장할 수 있어야 한다.

Chunk 원문과 Metadata 역시 검색 결과와 함께 확인할 수 있어야 한다.

---

FR-06. Vector Similarity Search

사용자 질문을 이용해 관련성이 높은 Document Chunk를 검색할 수 있어야 한다.

초기 Baseline에서는 Vector Search만 사용한다.

예:

Question

↓

Embedding

↓

Vector Similarity Search

↓

Top K Chunk

Top K 값은 초기 설정값을 사용하고 이후 평가 결과에 따라 변경할 수 있다.

---

FR-07. RAG 답변 생성

검색된 Chunk를 Context로 LLM에게 전달하고 사용자 질문에 대한 답변을 생성할 수 있어야 한다.

Question
   ↓
Retriever
   ↓
Top K Context
   ↓
LLM
   ↓
Answer

LLM이 내부 문서 내용을 자신의 사전 지식만으로 답하지 않도록 가능한 한 검색 Context를 기준으로 응답하게 한다.

---

FR-08. 근거 문서 제공

최종 답변에는 어떤 문서를 근거로 사용했는지 확인할 수 있어야 한다.

예:

{
  "answer": "15세 콘텐츠는 연령 등급 검수가 완료된 이후 공개할 수 있습니다.",
  "sources": [
    {
      "document": "age-rating-policy.md",
      "section": "3.2 공개 조건"
    }
  ]
}

사용자는 AI의 답변과 함께 원본 근거를 확인할 수 있어야 한다.

---

FR-09. 검색 결과 확인

Evaluation 또는 Debug 목적으로 Retriever가 어떤 Chunk를 검색했는지 확인할 수 있어야 한다.

최소한 다음 정보를 확인한다.

Rank

Document

Chunk

Similarity

Metadata

사용자용 응답에 모든 Debug 정보를 노출할 필요는 없다.

---

FR-10. Retrieval 평가

미리 정의한 Evaluation Dataset을 이용해 Retrieval 품질을 반복적으로 측정할 수 있어야 한다.

최소한 다음 지표를 확인한다.

Hit Rate@K

Recall@K

MRR

평가 Dataset과 검색 조건은 기록되어야 한다.

---

FR-11. Chunking 비교

동일한 문서와 동일한 Evaluation Dataset을 이용해 서로 다른 Chunking 전략을 비교할 수 있어야 한다.

예:

Chunk Size A

vs

Chunk Size B

또는:

Fixed Size

vs

문서 Section 기반

Chunking 전략을 바꿨다고 무조건 개선된 것으로 판단하지 않는다.

동일 Dataset으로 재평가한다.

---

FR-12. Keyword Search

Vector Search에서 정확한 식별자나 Keyword 검색 실패가 확인될 경우 Keyword Search를 사용할 수 있어야 한다.

예:

OPS-101

M-03

CONTENT_BLOCKED

단, Baseline에는 Keyword Search를 포함하지 않는다.

실제 Retrieval 실패 Case가 확인된 이후에만 적용 여부를 결정한다.

---

FR-13. Hybrid Retrieval

Vector Search와 Keyword Search가 서로 보완적인 결과를 만든다면 두 검색 결과를 조합할 수 있어야 한다.

Vector Search
      +
Keyword Search
      ↓
Combined Result

구체적인 결합 방식은 실험 결과를 기반으로 결정한다.

---

FR-14. 검색 결과 Fusion

서로 다른 Retriever의 결과를 결합해야 할 필요가 확인되면 순위 기반 Fusion 전략을 적용할 수 있어야 한다.

RRF는 후보 중 하나다.

Vector Ranking

+

Keyword Ranking

↓

RRF

↓

Combined Ranking

RRF 사용 자체가 요구사항은 아니다.

최종 요구사항은 서로 다른 검색 결과를 필요하면 일관된 Ranking으로 결합할 수 있어야 한다는 것이다.

---

FR-15. Reranking

1차 Retrieval 결과의 순위 품질에 문제가 확인되면 별도의 Reranking 단계를 적용할 수 있어야 한다.

Retriever Top N

↓

Reranker

↓

Final Top K

Reranker 역시 Baseline에는 사용하지 않는다.

품질 개선 효과와 추가 Latency를 함께 측정한다.

---

FR-16. Generation 평가

정답 문서를 검색했는지와 별개로 최종 답변이 검색 Context를 제대로 사용했는지 평가할 수 있어야 한다.

최소한 다음 내용을 평가한다.

Context에 근거한 답변인가?

Context에 없는 내용을 추가했는가?

질문의 핵심 내용을 포함했는가?

Source가 실제 답변 근거인가?

Retrieval 실패와 Generation 실패를 구분할 수 있어야 한다.

---

FR-17. 콘텐츠 검색

Agent 단계에서는 콘텐츠 DB를 조건에 따라 검색할 수 있어야 한다.

예:

"8월 공개 예정 액션 콘텐츠 알려줘."

조건:

releaseDate
genre
ageRating
status
serviceRegion
metadataStatus

Agent가 직접 자유 SQL을 생성하도록 할 필요는 없다.

정해진 Tool Interface를 통해 조회한다.

---

FR-18. 콘텐츠 상세 조회

특정 콘텐츠 ID를 이용해 상세 정보를 조회할 수 있어야 한다.

예:

"콘텐츠 100번 상태 알려줘."

결과:

Content ID
Title
Status
Age Rating
Release Date
Metadata Status

---

FR-19. Tool 선택

Agent 단계에서는 사용자 질문에 따라 필요한 Tool을 선택할 수 있어야 한다.

최종적으로 최소한 다음 Tool을 제공한다.

search_policy_documents

search_contents

get_content_detail

예:

"15세 콘텐츠 공개 규칙 알려줘."

↓

search_policy_documents

"이번 달 공개 콘텐츠 알려줘."

↓

search_contents

---

FR-20. 여러 Tool 조합

하나의 질문을 해결하기 위해 여러 정보가 필요하다면 Agent가 필요한 Tool을 순차적으로 사용할 수 있어야 한다.

예:

"콘텐츠 100이 왜 공개 불가인지 정책 기준으로 설명해줘."

↓

get_content_detail
        ↓
현재 상태 확인

+

search_policy_documents
        ↓
관련 정책 검색

↓

정보 조합

↓

Answer

처음부터 복잡한 Planner나 Multi-Agent 구조를 구현하지 않는다.

---

FR-21. Tool 선택 평가

Evaluation Dataset을 이용해 Agent가 적절한 Tool을 호출했는지 평가할 수 있어야 한다.

예:

QuestionExpected

15세 콘텐츠 정책	Policy Search
8월 공개 콘텐츠	Content Search
콘텐츠 100 상세	Content Detail
콘텐츠 100 공개 불가 이유	Content Detail + Policy Search

최종적으로 Tool 선택 결과를 실제 값으로 비교할 수 있어야 한다.

---

FR-22. Agent Workflow 상태 관리

Tool 호출이 여러 단계로 이어질 필요가 확인되면 Agent Workflow의 상태를 명시적으로 관리할 수 있어야 한다.

예:

userQuery

retrievedDocuments

contentData

selectedTools

toolResults

finalAnswer

구체적인 Workflow Framework는 설계 및 실험 단계에서 결정한다.

LangGraph는 후보 중 하나이며 요구사항 자체는 아니다.

---

7. 초기 RAG 처리 흐름

Baseline은 최대한 단순하게 구성한다.

POST /api/v1/questions
        ↓
Question Validation
        ↓
Question Embedding
        ↓
Vector Search
        ↓
Top K Chunk
        ↓
Context 생성
        ↓
LLM
        ↓
Answer + Source

초기에는 다음 기능을 사용하지 않는다.

Keyword Search

Hybrid Search

RRF

Reranker

Query Rewrite

Multi Query

Agent

Tool Calling

LangGraph

Memory

Multi-Agent

이 기능들은 실제 Baseline 평가에서 문제가 확인된 이후에만 검토한다.

---

8. Baseline에서 처리할 질문

초기 RAG에서는 운영 문서만으로 답할 수 있는 질문을 처리한다.

예:

"15세 콘텐츠 공개 기준은?"

"M-03 오류가 발생하는 이유는?"

"CONTENT_BLOCKED 상태는 언제 사용해?"

"Metadata 등록 시 필수 항목은?"

"콘텐츠 공개 전에 어떤 검수가 필요해?"

다음 질문은 초기 Baseline의 대상이 아니다.

"8월 공개 예정 콘텐츠 알려줘."

"콘텐츠 100번 현재 상태 알려줘."

"콘텐츠 100이 왜 공개되지 않는지 설명해줘."

이 질문들은 이후 Agent / Tool Calling 단계에서 처리한다.

---

9. 비기능 요구사항

NFR-01. Retrieval 품질 측정 가능성

검색 품질을 사람의 느낌만으로 판단하지 않는다.

동일한 Evaluation Dataset을 이용해 최소한 다음 지표를 측정한다.

Hit Rate@K

Recall@K

MRR

각 실험은 같은 질문과 정답 기준으로 반복할 수 있어야 한다.

---

NFR-02. Retrieval과 Generation 분리 평가

최종 Answer가 틀렸을 때 원인을 구분할 수 있어야 한다.

정답 문서를 찾지 못함
→ Retrieval Failure


정답 문서는 찾음
하지만 Answer가 틀림
→ Generation Failure

RAG 전체를 하나의 Black Box로 평가하지 않는다.

---

NFR-03. Grounding

최종 답변은 검색된 Context와 가능한 한 일치해야 한다.

Context에 없는 내부 정책이나 사실을 근거 없이 생성하지 않아야 한다.

---

NFR-04. Source 추적 가능성

답변에서 사용한 정보의 출처를 추적할 수 있어야 한다.

최소한:

Document Name

Section

Chunk

정보를 확인할 수 있어야 한다.

---

NFR-05. 재현 가능한 평가

같은 Retriever와 같은 Dataset을 사용했을 때 가능한 한 동일한 조건으로 평가할 수 있어야 한다.

다음 조건을 기록한다.

Document Dataset

Evaluation Dataset

Embedding Model

Chunk Strategy

Top K

Search Strategy

Reranker

Prompt

LLM Model

조건이 다르면 Before / After 비교에서 명확하게 표시한다.

---

NFR-06. 품질 변경의 측정

다음과 같이 기술 적용 자체를 개선으로 판단하지 않는다.

Hybrid Search 적용
→ 개선

이 아니라:

Baseline

↓

Hybrid Search

↓

동일 Dataset 평가

↓

Metric 비교

결과로 판단한다.

품질이 동일하거나 나빠질 수도 있으며 그 결과도 그대로 기록한다.

---

NFR-07. Latency 관측

각 단계에 걸리는 시간을 확인할 수 있어야 한다.

최소한 다음 값을 확인한다.

Embedding Latency

Retrieval Latency

Reranking Latency

LLM Latency

End-to-End Latency

현재 사용하지 않는 단계의 Metric은 필요하지 않다.

---

NFR-08. 비용 관측

상용 LLM 또는 Embedding API를 사용하는 경우 다음 정보를 확인할 수 있어야 한다.

Input Token

Output Token

요청당 Token

평가 전체 Token

예상 비용

로컬 Model을 사용한다면 비용 대신 실행 시간과 Resource 사용량을 기록할 수 있다.

---

NFR-09. Tool 선택 정확성

Agent 단계에서는 질문에 필요한 Tool을 올바르게 선택했는지 측정할 수 있어야 한다.

예:

Expected Tool
vs
Actual Tool

가능하면 다음 값을 산출한다.

Tool Selection Accuracy

---

NFR-10. 불필요한 Tool 호출 최소화

최종 답변이 맞더라도 필요하지 않은 Tool을 반복적으로 호출하는 구조는 좋은 결과로 판단하지 않는다.

예:

필요 Tool

Policy Search


실제

Policy Search
Content Search
Content Detail
Policy Search

와 같은 경우 Agent 품질 문제로 볼 수 있어야 한다.

---

NFR-11. 데이터 분리

운영 문서 검색과 구조화된 콘텐츠 조회는 역할을 구분한다.

정책 / Guide
→ RAG

콘텐츠 Metadata
→ Database Tool

모든 데이터를 Vector DB에 넣거나 모든 질문을 SQL로 해결하지 않는다.

---

NFR-12. 실패 안전성

근거가 충분하지 않은 경우 LLM이 임의로 답을 만들어내는 대신 정보가 부족함을 표현할 수 있어야 한다.

예:

관련 정책 문서를 찾지 못했습니다.

또는:

현재 제공된 데이터만으로는 판단할 수 없습니다.

실제 서비스처럼 완전한 정확성을 보장한다는 표현은 사용하지 않는다.

---

NFR-13. 동일 조건 비교

검색 구조나 Prompt를 변경할 때 가능한 한 동일한 평가 조건을 유지한다.

동일 Document Dataset

동일 Evaluation Dataset

동일 Embedding Model

동일 LLM

동일 Top K

하나의 변수를 비교하는 실험에서는 가능하면 다른 조건을 변경하지 않는다.

---

NFR-14. 관측 가능성

최종 Answer만 저장하는 것이 아니라 필요 시 다음 흐름을 추적할 수 있어야 한다.

Question

↓

사용된 Retriever

↓

검색된 Document

↓

검색 Ranking

↓

선택된 Tool

↓

Tool Result

↓

LLM Context

↓

Final Answer

이를 통해 왜 잘못된 답이 나왔는지 분석할 수 있어야 한다.

---

10. Evaluation Dataset 요구사항

이번 프로젝트에서는 Evaluation Dataset을 부가적인 테스트 데이터로 취급하지 않는다.

Baseline 구현의 일부로 본다.

Dataset에는 최소한 다음 유형의 질문을 포함한다.

Semantic Question

문서와 질문의 표현이 다르지만 의미가 같은 경우다.

문서:
연령 등급 검수 완료 후 공개 가능

질문:
15세 영화 서비스하려면 어떤 검수가 끝나야 해?

---

Exact Keyword Question

정확한 Code나 상태명이 중요한 경우다.

OPS-101

M-03

CONTENT_BLOCKED

---

Similar Document Question

여러 문서가 비슷한 내용을 포함하는 경우다.

연령 등급 정책

청소년 보호 정책

콘텐츠 공개 정책

정답 문서가 Ranking에서 어디에 위치하는지 확인한다.

---

No Answer Question

현재 문서에 답이 없는 질문이다.

"해외 판권 계약 담당자는 누구야?"

이 경우 LLM이 존재하지 않는 답을 만들어내는지 확인한다.

---

Agent Tool Question

Agent 단계에서는 다음 종류도 추가한다.

Policy only

Content Search only

Content Detail only

Policy + Content Detail

---

11. Baseline 완료 조건

초기 RAG 단계에서는 다음 조건을 만족하면 Baseline 구현이 완료된 것으로 판단한다.

Document

운영 문서를 반복적으로 적재할 수 있다.

문서를 Chunk로 나눌 수 있다.

Chunk Metadata를 확인할 수 있다.

Embedding / Vector Store

Chunk Embedding을 생성할 수 있다.

pgvector에 저장할 수 있다.

질문 Vector를 생성할 수 있다.

Top K Vector Search가 가능하다.

RAG

Question API가 존재한다.

Vector Search 결과를 LLM Context로 전달한다.

최종 Answer를 생성한다.

답변 Source를 확인할 수 있다.

Evaluation

Evaluation Dataset이 존재한다.

Hit Rate@K를 측정할 수 있다.

Recall@K를 측정할 수 있다.

MRR을 측정할 수 있다.

실패 Query를 확인할 수 있다.

Test

문서 적재 Test

Vector Search Test

RAG Integration Test

Evaluation 실행 Test

README

이번 프로젝트에서는 Baseline 완료 시점부터 최소한 다음 내용을 README에서 확인할 수 있어야 한다.

프로젝트 실행 방법

PostgreSQL / pgvector 실행 방법

문서 적재 방법

질문 API 호출 방법

테스트 실행 방법

Evaluation 실행 방법

이 단계에서는 Retrieval 품질이 좋을 필요는 없다.

측정 가능한 Baseline이 존재하는 것이 완료 조건이다.

---

12. Baseline에서 의도적으로 해결하지 않을 문제

초기 구현에서 다음 문제를 발견하더라도 바로 해결하지 않는다.

정확한 Keyword 검색 실패

관련 문서 Ranking 문제

Chunk가 너무 크거나 작음

Context에 불필요한 문서 포함

LLM Hallucination

복잡한 질문 처리 실패

콘텐츠 DB 질문 처리 불가

Tool 선택 기능 없음

먼저 Evaluation 결과에 실제 실패 Case로 남긴다.

그 후 실험 단계에서 문제별로 접근한다.

---

13. 이후 실험에서 확인할 문제

Baseline 이후에는 대략 다음 흐름으로 진행한다.

Baseline Vector RAG
        ↓
Retrieval 평가
        ↓
실패 Query 분석
        ↓
Chunking 실험
        ↓
Keyword Search 필요성 확인
        ↓
Hybrid Search / Fusion 검토
        ↓
Ranking 문제 확인
        ↓
Reranking 검토
        ↓
Generation / Grounding 평가
        ↓
콘텐츠 DB Tool 추가
        ↓
Tool Calling
        ↓
Agent Workflow
        ↓
Tool Selection 평가
        ↓
최종 비교

여기서 중요한 점은:

Phase 도달
=
해당 기술 반드시 도입

이 아니라는 것이다.

예를 들어 Vector Search만으로 Exact Keyword Query까지 충분히 처리된다면 Keyword Search를 추가하지 않을 수도 있다.

Hybrid Search 결과가 Baseline보다 나쁘다면 최종 구조에서 제거할 수도 있다.

Reranker가 품질을 거의 올리지 못하면서 Latency만 크게 증가시킨다면 사용하지 않을 수도 있다.

LangGraph 없이 단순한 Tool Calling만으로 요구사항을 만족한다면 LangGraph를 사용하지 않는 것도 가능하다.

---

14. 이번 프로젝트에서 제외할 기능

ContentOps Agent의 학습 목적과 직접 관계없는 기능은 구현하지 않는다.

다음 기능은 제외한다.

회원가입

로그인 UI

실제 콘텐츠 등록 CMS

실제 콘텐츠 수정 기능

실제 회사 내부 문서 연동

Google Drive / Notion 연동

실제 운영 권한 체계

추천 시스템

영상 Streaming

DRM

CDN

관리자 Dashboard

Frontend UI

Voice Interface

또한 처음부터 다음 기술을 사용하지 않는다.

Elasticsearch

OpenSearch

Redis Vector Store

Pinecone

Weaviate

Milvus

Knowledge Graph

Multi-Agent

Long-term Memory

Fine-tuning

실제 문제가 확인되고 프로젝트 학습 범위 안에서 필요성이 생긴 경우에만 후보로 검토한다.

---

15. AI 기능을 어떻게 성공으로 판단할 것인가

이 프로젝트에서 가장 피하고 싶은 결과는 다음과 같다.

질문 몇 개 해봄

↓

그럴듯한 답변 나옴

↓

RAG 성공

대신 성공 기준을 여러 단계로 나눈다.

Retrieval

정답 문서를 찾았는가?


Ranking

정답 문서가 충분히 높은 순위인가?


Generation

검색된 내용을 기반으로 답했는가?


Grounding

없는 사실을 만들지 않았는가?


Agent

적절한 Tool을 선택했는가?


Efficiency

품질 개선에 비해 Latency와 비용이 과도하지 않은가?

하나의 숫자로 모든 AI 품질을 설명하려고 하지 않는다.

---

16. 정리

ContentOps Agent의 초기 구조 자체는 단순하다.

운영 문서
   ↓
Chunk
   ↓
Embedding
   ↓
pgvector


Question
   ↓
Vector Search
   ↓
Context
   ↓
LLM
   ↓
Answer + Source

하지만 실제 학습은 이 구조를 평가하는 시점부터 시작된다.

앞으로는 다음 질문에 답해볼 예정이다.

Vector Search는 어떤 질문에서 실패할까?

Chunk 크기를 바꾸면 Recall과 Ranking은 실제로 달라질까?

Exact Keyword가 포함된 질문에서는 Keyword Search가 더 나을까?

Hybrid Search를 적용하면 모든 Query가 좋아질까?

정답 문서가 Top K 안에 있어도 순위가 낮으면 Answer 품질에 영향을 줄까?

Reranker를 추가할 만큼 품질 차이가 발생할까?

Retrieval은 성공했는데 LLM이 틀리는 경우는 어떻게 구분할까?

문서에 없는 질문에서는 Hallucination을 줄일 수 있을까?

콘텐츠 DB가 필요한 질문을 Agent가 구분할 수 있을까?

여러 Tool이 필요한 질문에서 올바른 순서로 호출할 수 있을까?

그리고 이번 프로젝트에서는 이전 프로젝트보다 한 가지를 더 중요하게 본다.

AI가 잘 동작하는 것처럼 보이는 것이 아니라, 실제 평가 Dataset과 Metric을 통해 무엇이 좋아졌고 무엇이 여전히 실패하는지를 설명할 수 있어야 한다.

다음 단계에서는 이 요구사항을 기반으로 ContentOps Agent의 개발 Harness와 Phase별 실험 전략을 정리해보려고 한다.