AI 기반 데이터 아키텍처, 파트 1: 프롬프트만으로는 부족한 이유

AI 기반 데이터 아키텍처, 파트 1: 프롬프트만으로는 부족한 이유

AI 기반 데이터 아키텍처가 나에게 의미하는 바와, 내가 이를 고통스럽게 배운 과정

다음 편: 파트 2 — 설계도 (The Blueprint)

이번 글을 통해 얻게 될 내용

만약 여러분이 채팅 데모 단계를 넘어섰다면, 저와 똑같은 벽에 부딪혔을지도 모릅니다. 모델은 세 세션 전에 했던 말을 잊어버리고, 검색된 컨텍스트 (retrieved context)는 무작위처럼 느껴지며, 번역된 용어들은 어긋나고, 아무도 git 히스토리를 읽으며 요행을 바라지 않고서는 _"이 사실이 어디서 왔는가?"_라는 질문에 답할 수 없는 상황 말입니다.

이 2부작 시리즈는 동일한 벽과 싸우고 있는 빌더 (builders)들을 위한 것입니다. 이것은 표준 가이드나 프롬프트 요리책이 아닙니다. 이것은 제가 하나의 빌드를 통해 도달한 모델이며, 여러분이 이를 빌려 쓰거나, 적응시키거나, 혹은 어디서 문제가 발생하는지 저에게 알려줄 수 있도록 기록한 것입니다.

파트 1을 마칠 때 여러분은 다음을 얻게 될 것입니다:

• 제가 사용하는 용어로서의 **AI 기반 데이터 아키텍처 (AI-driven data architecture)**에 대한 작동 가능한 정의 (그리고 이것이 "LLM + 데이터베이스"와 어떻게 다른지에 대한 설명)
• 여러분 자신의 제품 도메인에 매핑해 볼 수 있는 8계층의 렌즈 (eight-layer lens)
• 이론이 아닌 실제 프로젝트를 통해 경험한, 왜 나의 "2주 만에 출시"라는 추정치가 함정이었는지에 대한 솔직한 기록

파트 2에서는 이 렌즈를 **패턴 (patterns)**으로 전환합니다: 계층화된 단일 진실 공급원 (SSOT, Single Source of Truth), 생성→추출→검색 (generate→extract→retrieve) 플라이휠, 엔지니어링으로서의 검색 (retrieval as engineering), 그리고 여러분이 "절반쯤 완료된" 상태일 때 자신의 위치를 파악하기 위한 성숙도 루브릭 (maturity rubric) (스포일러: 그것은 정상입니다).

저는 이 패턴들을 단 하나의 도메인(소설)에서만 검증했습니다. 하지만 AI가 진화하는 소스 자료에 근거를 두어야 하는 곳이라면 어디든 동일한 형태가 익숙하게 보일 것입니다:

• 지원 티켓 (Support tickets) — 원시 스레드 → 추출된 의도 → 승인된 매크로 → 에이전트 답변
• 법률 검토 (Legal review) — 계약서 → 추출된 의무 사항 → 사람이 승인한 조항 라이브러리 → 초안 작성 보조
• 내부 위키 (Internal wikis) — 문서 → 추출된 엔티티 (entities) → 큐레이션된 용어집 → 검색 기반 채팅

하지만 소설 이외의 분야에서 이것들은 아직 출시된 결과가 아닌 가설로 남아 있습니다. 창의적 글쓰기는 연속성(continuity) 문제가 가장 눈에 띄게 고통을 주는 분야일 뿐입니다.

저는 제가 구축해 온 다국어 소설 워크플로우 플랫폼(LoreWeave)에서 실제 운영 중 나타난 패턴을 가끔 언급할 것입니다. 이 블로그는 해당 플랫폼 언급 없이도 독립적인 내용을 다룹니다.

환상: 프롬프트 + 컨텍스트 = 제품?

AI 제품 개발에서 가장 유혹적인 계획 — 저 또한 믿었던 계획 — 은 다음과 같습니다:

1. 사용자 콘텐츠(문서, 티켓, 챕터, 계약서)를 수집합니다.
2. 관련 있는 부분을 프롬프트(prompt)에 집어넣습니다.
3. 모델을 호출합니다.
4. 출시합니다.

저는 그 계획을 냅킨 위에 적었습니다. 예상 일정은 2주였습니다. 제품은 작가들이 LLM(대규모 언어 모델)의 도움을 받아 소설을 쓰고 번역하는 것을 도울 것이었습니다 — 채팅, 아마도 일괄 번역(batch translation) 정도면 충분했습니다.

데모는 그 환상을 강화했습니다. 단 한 권의 책, 시스템 프롬프트(system prompt)에 붙여넣은 설정(lore), 친숙한 UI — 그것은 작동했습니다. 이해관계자들은 박수를 쳤습니다. 저도 박수를 쳤습니다. 그러고 나서 저는 그 시스템 안에서 실제로 살아보려 했습니다.

연속성(continuity)이 가장 먼저 무너졌습니다. 모델이 3장에 대한 지속적인 기억(durable memory)이 없었기 때문에, 12장에서 캐릭터의 경칭(honorific)이 바뀌었습니다. 번역은 단순한 문자열 치환(string replacement)이 아니었습니다. 동일한 고유명사가 언어 간에 세 가지의 허용 가능한 표현으로 나타났고

저는 **AI 기반 데이터 아키텍처 (AI-driven data architecture)**라는 용어를, 명시적인 소유권, 측정, 그리고 개선 루프 (improvement loops)를 갖춘 상태에서 원시 입력값(raw inputs)을 AI 기능들이 소비할 수 있는 **근거가 있고(grounded), 추적 가능하며(traceable), 재사용 가능한 지식(reusable knowledge)**으로 변환하는 구조와 파이프라인의 집합이라는 의미로 사용합니다.

제가 사용하는 의미는 다음과 같은 것들이 아닙니다:

• "RAG"라고 이름만 바꾼 벡터 데이터베이스 (vector database)
• embeddings 컬럼이 포함된 단일 Postgres 스키마 (schema)
• 프롬프트 로더 (prompt loader)가 읽어들이는 JSON 파일 폴더

그것은 시스템의 역할이 컨텍스트 (context)를 준비하고, 소유하며, 제공하는 것이라는 약속이며, LLM은 중심점이 아니라 (채팅, 배치 작업, 에이전트, 번역 파이프라인 등) 여러 소비자 중 하나라는 약속입니다. 그 약속은 제가 초기에 계속해서 지키지 못했던 것이었습니다.

두 가지 사고방식 — 저의 이전과 이후

이것은 다른 사람의 작업에 대한 성적표가 아니라, 저 자신의 전/후 비교입니다:

시작 단계	어려운 과정이 저를 밀어붙인 지점
프롬프트 엔지니어링 (Prompt engineering)이 핵심 기술이다	데이터 계약 (Data contracts)과 SSOT 경계가 핵심 기술이다
...

이 변화는 미묘했고, 저에게는 느리게 찾아왔습니다. 저는 _"프롬프트에 무엇을 써야 할까?"_라고 묻는 것을 멈추고, _"이 사실의 소유자는 누구인가, 이것이 어떻게 여기에 도달했는가, 그리고 검색 (retrieval)이 제대로 작동했다는 것을 어떻게 알 수 있는가?"_라고 묻기 시작했습니다.

8계층의 렌즈

이것들을 조직도상의 칸이 아니라, AI 네이티브 아키텍처 (AI-native architecture)가 조만간 답해야만 하는 질문들이라고 생각하십시오. 이것들은 제가 첫날부터 물었어야 했던 질문들입니다.

계층 (Layer)	답변하는 질문	이를 건너뛴다면…
Ingest (수집)	가공되지 않은 진실(raw truth)은 어디에 있는가?	Ground truth(실제 정답)가 없음; 모든 것이 프롬프트에 의한 허구(prompt fiction)가 됨
...

저에게 가장 큰 비용을 치르게 했던 통찰: 이것은 단 하나의 데이터베이스가 아닙니다. 이는 오히려 **파이프라인 문화 (pipeline culture)**에 가깝게 작동합니다. 계층들은 물리적 저장소(physical stores)를 공유할 수 있지만

• 실제 원고나 코퍼스(corpora)로부터 대규모로 수행되는 자동 추출 (Automatic extraction)
• 인간이 작성한 정전(canon)과 기계가 추출한 후보군 사이의 소유권 분할 (Split ownership)
• 측정 가능한 검색 (Retrieval I could measure) (단순히 "청크를 임베딩했다"가 아닌 방식)
• 새로운 글쓰기가 내가 요약본을 복사하여 붙여넣지 않아도 구조화된 지식을 업데이트하는 폐쇄 루프 (closed loop)

연구 프로토타입들은 종종 다른 원형(archetype)을 보여줍니다. 즉, 얇은 데이터 기반 위에서 인상적인 **멀티 에이전트 오케스트레이션 (multi-agent orchestration)**을 보여줍니다. 그것은 대개 연구를 위한 올바른 트레이드오프(trade-off)입니다. 논문은 하나의 새로운 능력을 격리하여 증명하는 것이지, 1년 뒤 운영 환경에서 지식 그래프(knowledge graph)를 소유하려고 시도하는 것이 아니기 때문입니다. 사실, 검색(retrieval)과 그래프 기반 생성(graph-grounded generation)에 관한 학술적 연구는 제가 이러한 아이디어들을 가장 많이 빌려온 곳입니다. 파트 2의 패턴들은 GraphRAG나 HippoRAG와 같이 발표된 시스템들의 메아리를 담고 있습니다. 저는 진공 상태에서 발명하는 것이 아니라, 한 분야의 연구 성과를 현장에서 테스트하고 있는 것입니다.

따라서 이 중 어느 것도 누군가의 잘못이 아닙니다. 이것은 출시 가능한 것처럼 느껴지는 — 저에게는 출시 가능한 것처럼 느껴졌던 — **아키텍처의 중단점 (architecture stopping point)**이며, 그러한 요구사항들이 닥치기 전까지는 그랬습니다. 제 사례를 통해 얻은 교훈의 솔직한 버전은 다음과 같습니다: 처음에는 AI가 시스템이 아니라 UI였습니다. AI를 인프라(infrastructure)로 전환하는 것이 제가 과소평가했던 부분이었습니다.

하나의 빌드에서 얻은 일곱 가지 교훈

법칙은 아니며 현장 노트(Field notes)일 뿐입니다. 하지만 제가 배우는 데 가장 큰 비용을 치른 것들입니다.

1. 프롬프팅은 소비이지, 기반이 아니다.

프롬프트는 호출 시점에 컨텍스트(context)를 조립합니다. 프롬프트는 인제스트(ingest), 단일 진실 공급원(SSOT), 또는 추출(extraction)을 대체하지 않습니다. 프롬프트 템플릿을 소유한 데이터에 대한 **뷰 (views)**로 취급하십시오.

2. SSOT 경계 설정이 모델 선택보다 중요하다.

인간이 큐레이션한 용어집(glossary) 항목과 기계가 추출한 엔티티(entities)가 동일한 사고 영역에 머물렀을 때, 미묘한 오염이 발생했습니다. UI 테스트에서는 괜찮아 보였지만, 운영 환경에서는 "조용한 데이터 손실 없음" 원칙을 위반하는 병합(merges)이 발생했습니다. 작성된 (authored) 지식과 추출된 (extracted) 지식을 조기에 분리하고, 승격 경로(promote path)를 정의하십시오.

3. 파생 저장소(Derived stores)는 재구축 가능해야 합니다.

그래프(Graph) 및 벡터 인덱스(vector indexes)는 **투영(projections)**입니다. 추출 상태(extraction state)와 원본 콘텐츠(raw content)로부터 이를 다시 유도(re-derive)할 수 없다면, 의도치 않게 두 번째 진실의 원천(second source of truth)을 만든 셈입니다.

4. 측정(Measurement)은 단계가 아니라 레이어(layer)입니다.

우리는 수동 테스트에서 "작동하는" 하이브리드 검색(hybrid search)을 출시했습니다. 하지만 검색 평가 하네스(retrieval eval harness)(골든 쿼리(golden queries), 재현율(recall), NDCG)를 통해 통합 테스트가 놓쳤던 재현율 버그를 발견했습니다. SQL이 평면적인 행 제한(flat row limit)을 반환하면서 광범위한 용어들이 몇 개의 챕터로 뭉쳐지는 문제였습니다. 수치는 고통스러웠지만, 동시에 몇 주간의 추측을 줄여주었습니다.

5. 지능(intelligence)보다 이벤트(events)가 우선입니다.

신뢰할 수 있는 변경 알림(change notification)(아웃박스(outbox), 스트림(streams), 큐(queues))은 "스마트"한 기능보다 앞서야 합니다. 사용자가 최신성(freshness)을 기대하기 시작하면, 야간 크론(nightly cron) 작업보다는 저장(save)에 의해 트리거되는 추출(extraction) 방식이 더 효과적입니다.

6. 에이전트(Agents)는 데이터 계약(data contracts) 이후에 옵니다.

도구 호출(Tool-calling) 에이전트에는 시스템 프롬프트(system prompt)에 4만 토큰의 JSON을 넣는 방식이 아니라, 도구로서 노출된 **소유권이 있고 범위가 지정된 데이터(owned, scoped data)**가 필요합니다. 에이전트 아키텍처는 소비 레이어(consumption-layer) 설계이며, 이는 하위 레이어들이 이미 존재함을 전제로 합니다.