본문이 DB에 들어가 있더라

무인 완주 한 번 해 보고, Postgres 컬럼을 버리고 md 파일 2층으로 엎은 이유

무인으로만 끝까지 한 바퀴 돌려 보고 싶었다. 중간에 끼어들면 흐름이 끊기고, 에이전트에게 “알아서 해”라고 맡긴 실험이 어디까지 가는지 보고 싶었다. 돌려 보니 위키 본문이 Postgres 컬럼에 들어가 있었다.

말해 둔 줄 알았다. 세컨드처럼 마크다운 파일로 가고, 폴더를 읽고 검색할 수 있어야 한다고. 그런데 무인 완주 결과물을 열어 보니 문서 본문이 DB에 새 들어가 있었다. 파일 쪽을 말한 것 같은데 오해가 있었나, 아니면 내가 분명히 안 짚고 넘겼나. 둘 다일 수 있다. 중요한 건 중간 확인 없이 끝까지 가면 이런 걸 못 잡는다는 사실이었다.

무인으로 다 만든 다음에야 고칠 산이 보였다 쪽에서도 비슷한 말을 했다. 그때는 리뷰 누적과 컨텍스트 쪽 이야기였고, 이번엔 저장 구조다. 같은 버릇의 다른 얼굴이다. 무인 완주를 “한 번”은 해보고 싶었다. 그 한 번으로 무인은 체크포인트 없이 말이 안 된다는 걸 몸으로 알았다.

방향은 처음부터 세컨드였다

마이위키를 만들 때 머릿속에 있던 그림은 내가 쓰는 세컨드 위키였다. 원문 층에 소스가 쌓이고, 위키 층에 정리된 md가 남고, git으로 이력을 남긴다. AI가 개인 위키를 통째로 다루려면 그 위키가 폴더여야 한다. 본문이 DB 컬럼이면 에이전트가 폴더를 읽고 검색하기 어렵고, git으로 되돌리기도 어렵고, 세컨드와 머릿속 그림이 갈라진다. 그게 AD-15의 출발점이었다.

그런데 무인 루프 안에서는 “문서 저장”이 편하게 Postgres로 흘러갔다. 메타도 DB, 본문도 DB. 말하면 구현되고, 스펙 문장과 구현이 어긋나도 중간에 사람이 안 보면 끝까지 간다. 확인 없이 완주하면 남는 건 그런 오해다.

그래서 엎었다. 문서 본문은 파일과 git이 정본이고, DB에는 메타·채팅 메타·미터링·잡 큐만 둔다. bodyMarkdown 같은 본문 컬럼은 없애고, 파일 저장소가 읽고 쓰게 했다. 한 번 방향을 고치면 연쇄가 온다. 본문만 파일로 빼고 대화·업로드는 DB에 두면 또 같은 질문이 생긴다. 원천이 어디 있나, 안 보이면 답답하지 않나.

원문과 위키, 두 층

세션 제목 그대로 남아 있는 말이 있다. 「로우 파일도 관리하게 해야하나 아예안보이니까 좀 답답하네」. 위키만 파일로 빼고 채팅·업로드가 휘발되거나 DB 안에만 있으면, 원천이 안 보인다. 그래서 AD-18에서 대화와 업로드도 원문 파일로 옮겼다. 세션 md를 파일이 관리하고, 본문 내용은 DB에 정본으로 남기지 않는다. 로드할 때 파일을 읽어 채우고, 저장도 파일 쪽이다.

폴더 이야기도 같이 왔다. 「폴더구조는 좀 바꾸자 깃여러개인건 좀 아닌거 같아서 raw 안에 여러 공간이 있고… wiki 폴에 깃 하나로」. 처음엔 공간마다 git을 둘 수도 있다고 생각했는데, 문서를 공간 사이로 옮기면 레포 간 이식이 되고 이력이 끊긴다. AD-19에서 위키는 유저당 단일 git 레포로 두고, 이동은 git mv로 맞췄다. 멀티 업로드도 「흠 파일 업로드 멀티로 되어야 할거 같음~」 쪽으로 같이 정리됐다.

지금 목표 레이아웃은 대략 이렇다.

data/users/{userId}/
  raw/{spaceId}/
    chats/
    uploads/
  index/
    structured/
    wiki-map/
  wiki/                 # 유저당 단일 git
    {spaceId}/{docId}.md

세컨드는 1인 로컬 위키고, 마이위키는 멀티유저 서비스라 모든 경로가 users/{userId}/ 아래로 격리된다. 그 차이만 빼고 원문·분류 지도·위키 층은 세컨드와 같은 말로 말할 수 있게 맞춘 셈이다. 분류가 몇 층인지, “위키 목차”가 어느 파일이냐는 나중에 또 헷갈렸다. 「아하 인덱스는 db에서 관리한다고?」 같은 질문이 오고, AD-20·21 쪽으로 정리했다. 그 이야기는 이 글에서 깊게 안 간다. 여기서 말할 건 바닥이 파일로 바뀐 이유다.

왜 엎었는지 한 줄로

본문이 DB에 있으면 AI가 위키를 폴더처럼 다루지 못한다. 검색도, 되돌리기도, 옵시디언 같은 파일 도구와의 접점도 약해진다. 세컨드에서 이미 검증한 쓰는 방식을 제품에 옮기려면 저장이 먼저 같아야 했다. 무인 완주가 그 어긋남을 드러냈고, 드러난 김에 Postgres 본문 경로를 걷어 냈다.

AD를 15부터 20까지 하나씩 나열할 필요는 없다. 흐름은 하나다. 본문 파일화 → 대화·업로드 원문화 → 위키 단일 git → 그 위에 분류 지도. 구현 시리즈 이름이나 스모크 개수보다, “말해 둔 줄 알았던 파일 위키가 DB에 들어가 있었다”는 장면이 먼저다.

이 바닥 위에서 나중에 비용 이야기, 분류 이야기, 정리를 언제 돌릴지 이야기를 한다. 어떻게를 길게 쓰기보다, 왜 한 번 엎었는지만 남기면 된다. 무인으로 끝까지 가 보고 나서야 알았다. 확인 없이 가면 오해가 제품 안에 남고, 그 오해를 고치는 비용은 바닥을 바꾸는 일이다.