인터뷰 엔진에 데이터를 먹이는 올바른 방법: Ouroboros의 data_context lane 설계 풀어보기
“질문을 잘하려면 데이터가 필요하다”의 함정
Ouroboros의 심장은 인터뷰입니다. 코드를 만들기 전에 소크라테스식 질문으로 숨은 가정을 파내고, 답이 모이면 불변 스펙(seed)으로 굳히죠. 그런데 지금까지 이 인터뷰에는 태생적 한계가 있었습니다 — 백지 상태에서 묻는다는 것.
“이 기능의 주 사용자는 누구인가요?”라고 물을 때, 인터뷰 엔진은 당신의 실제 사용자 데이터를 모릅니다. 지난달 어떤 기능이 많이 쓰였는지, 어떤 에러가 반복됐는지도 모릅니다. 사용자의 기억에만 의존하는 인터뷰는 사용자의 착각도 그대로 스펙에 넣습니다. 그래서 자연스러운 욕심이 생깁니다 — 인터뷰 엔진에 메모리/데이터 레이어를 연결하자.
문제는 이 욕심을 순진하게 구현하면 아키텍처가 무너진다는 겁니다. 최근 Ouroboros 쪽에서 진행 중인 data_context lane 논의는 이 문제를 꽤 우아하게 푸는 설계라, 쉽게 풀어서 정리해봅니다.
순진한 방법: 엔진에게 열쇠를 다 주기
가장 쉬운 구현은 인터뷰 엔진에 MCP 도구 접근권을 직접 주는 겁니다. 질문을 만들다가 필요하면 엔진이 직접 DB를 조회하고, 메모리를 뒤지고, 그 결과를 질문에 섞는 거죠.
이게 왜 나쁜가? 한 컴포넌트가 너무 많은 것을 소유하게 됩니다. 질문 생성 로직과 데이터 접근 권한과 사용자 데이터가 한 덩어리로 섞입니다. 그 순간부터:
- 인터뷰 상태를 저장하면 원본 사용자 데이터가 함께 저장될 수 있고 (프라이버시 문제)
- 엔진이 어떤 데이터를 언제 읽었는지 추적이 어려워지고 (감사 불가능)
- 데이터 조회가 실패하면 인터뷰 자체가 죽습니다 (결합도 문제)
에이전트 시스템에서 반복해서 배우는 교훈이 여기서도 나옵니다 — 능력과 권한을 같은 곳에 두지 마라.
제안된 구조: 네 개의 역할, 네 개의 경계
data_context lane 설계는 역할을 이렇게 자릅니다.
인터뷰 엔진 → 질문·상태·게이트만 소유. 도구 접근 없음(one-shot 질문 생성기로 유지)
호스트 런타임 → 서브에이전트 실행·MCP 접근·권한을 소유
data_context lane → "데이터 근거 요약"만 오가는 통로
사용자 확인 게이트 → 인터뷰 상태에 들어가기 전 마지막 경계
흐름으로 보면: 인터뷰 엔진은 “이 질문엔 실제 데이터 근거가 필요하다”고 lane을 선언만 합니다. 직접 조회하지 않습니다. 그러면 호스트 런타임이 권한 있는 서브에이전트를 소환해 읽기 전용 MCP 조회를 수행하고, 그 결과를 lane_id로 엔진에 돌려줍니다. 이때 돌아오는 것은 원본 데이터(raw rows)가 아니라 집계/요약 + 어떤 도구·쿼리로 얻었는지의 출처(provenance)입니다.
식당에 비유하면: 주방장(엔진)은 “토마토 재고 확인 필요”라는 주문서(lane 선언)만 씁니다. 창고 열쇠는 지배인(호스트)이 갖고 있고, 지배인이 확인하고 돌아와 전하는 건 토마토 상자 전체가 아니라 “3상자, 어제 입고, 창고 B에서 확인”이라는 요약과 출처입니다. 주방장은 요리에 집중하고, 창고 접근 기록은 지배인 장부에 남습니다.
핵심 개념: raw memory 삽입이 아니라 ‘advisory evidence layer’
이 설계에서 제일 곱씹을 문장은 이겁니다 — 메모리 레이어가 들어오는 좋은 형태는 raw memory 삽입이 아니라, 근거 있는 자문형 증거 레이어(advisory evidence layer)라는 것.
차이는 이렇습니다.
| raw memory 삽입 | advisory evidence layer | |
|---|---|---|
| 전달물 | 원본 데이터/기억 덩어리 | 집계·요약 + 출처(provenance) |
| 역할 | 컨텍스트를 채움 | 질문의 근거를 제공 |
| 저장 시 | 원본이 인터뷰 상태에 박제 | 요약만 남고 크기·PII 통제 가능 |
| 성격 | 데이터가 답을 밀어붙임 | 데이터는 조언, 결정은 인터뷰가 |
“advisory”라는 단어가 중요합니다. 데이터는 인터뷰를 대체하지 않고 보좌합니다. “지난달 결제 실패가 12% 증가했습니다(출처: metrics DB, 쿼리 X)”라는 근거를 들고 “그럼 이번 기능에서 결제 재시도 정책을 어떻게 할까요?”라고 묻는 것 — 데이터가 질문을 날카롭게 만들지만, 스펙을 결정하는 건 여전히 인터뷰와 사용자입니다.
이건 Ouroboros 생태계의 일관된 철학이기도 합니다. rlm-forge의 TraceGuard가 “자식 증거 없는 부모 주장은 리젝”이라면, 이 설계는 같은 원칙을 질문 쪽에 적용한 겁니다 — 근거 없는 질문보다 출처 달린 질문이 낫고, 출처 없는 데이터는 인터뷰에 못 들어온다.
출하 전에 단단해야 할 세 가지
논의에서 명시된 선결 조건 세 개가 있는데, 셋 다 “잘 될 때”가 아니라 “잘못될 때”를 위한 설계라는 점이 눈에 띕니다.
- read-only 강제 — 데이터 조회 서브에이전트가 어떤 경로로도 쓰기를 못 하게. “읽기만 할게요”라는 약속이 아니라 구조적 강제여야 합니다. 인터뷰가 사용자 데이터를 변조할 수 있는 순간 이 기능은 자산이 아니라 부채가 됩니다.
- evidence size / PII scrub — 인터뷰 상태는 저장(persist)됩니다. 그 안에 들어가는 증거의 크기를 제한하고 개인정보를 씻어내지 않으면, “인터뷰 기록”이 곧 “개인정보 저장소”가 되는 사고가 납니다. 요약만 전달하는 lane 설계가 여기서 실질적 방어선이 되고요.
- 안전한 성능 저하(graceful degradation) — 데이터가 없거나 lane이 실패해도 인터뷰는 계속되어야 합니다. 근거가 없으면 “근거 없이 묻는 예전 방식”으로 자연스럽게 내려앉으면 됩니다. 데이터 레이어는 인터뷰의 강화제이지 의존성이 아니어야 한다는 것.
이 세 가지가 잡히면, 메모리 레이어는 Ouroboros 철학(증거·게이트·불변 스펙)을 훼손하지 않고 그 위에 얹힙니다.
하네스 관점에서: 경계 설계가 곧 신뢰
하네스 시리즈 내내 반복한 주제가 여기서 다시 나옵니다. 에이전트 시스템의 품질은 능력이 아니라 경계에서 나옵니다.
이 설계가 아름다운 이유는 “무엇을 할 수 있게 하느냐”보다 “무엇을 섞이지 않게 하느냐”에 공을 들였기 때문입니다. 질문 생성과 데이터 접근의 분리, 원본과 요약의 분리, 자동 조회와 사용자 승인의 분리. 각 분리선이 하나씩의 사고를 예방합니다. 그리고 마지막 경계가 사람의 확인 게이트라는 것 — 아무리 근거가 좋아도 인터뷰 상태에 들어가기 전 최종 관문은 사용자라는 것 — 이 이 설계의 가장 보수적이고, 그래서 가장 옳은 선택입니다.
맺으며
“드디어 메모리 레이어가 들어온다”는 문장은 설레는 말이지만, 이 논의의 진짜 교훈은 들어오는 방식에 있습니다. 데이터를 많이 아는 인터뷰가 아니라, 아는 것의 출처를 댈 수 있고, 모를 때 안전하게 모른다고 하는 인터뷰. 에이전트에 기억을 붙이려는 모든 시스템이 참고할 만한 경계 설계입니다.
참고: 이 글은 Ouroboros 프로젝트의 data_context lane 관련 논의(메인테이너 코멘트 및 GitHub Discussion)를 바탕으로 재구성한 해설입니다.