마이위키 저장을 원문·위키 파일 두 층으로 맞출 때, 머릿속에는 second 메커니즘이 있었다. 모으고(수집), 칸에 올리고(분류), 정리해 위키에 남기고(요약), 필요할 때 조회한다. 그 루프만 앱 기능으로 옮기면 되겠다고 생각했다. 스킬 파일이나 터미널에서 한 번에 굴리는 운영 묶음까지 이식할 필요는 없었다. 메커니즘이면 충분하다고 봤다.
차이는 과금 방식이었다. second는 내가 구독·로컬 CLI 쪽에서 돌리는 쪽에 가깝고, 제품은 API 키로 매 호출이 원장에 쌓인다. 그 차이를 나중에야 몸으로 알게 됐다.
다 읽고 종합하면 안 됐다
정리 파이프라인이 생기자 위키처럼 느껴지지 않았다. 원문 하나 들어오면 입구에서 새 문서를 만들지(create), 기존에 붙일지(reflect) 보고, 곧바로 본문을 썼다. 애매하면 새 문서 쪽으로 기울었다. 문서 수가 원문에 거의 1:1로 붙었다.
그때 내가 한 말이 남아 있다. 「소화가 너무 1:1인데 통합되어야할거같은데」. 이어서 「소화할때 바로 편집하는게 아니고 종합해서 편집해야할거같은데」. 분류 지도도 보고, 여러 원문을 한 번에 맞춰 본문을 다시 쓰는 그림이었다. second에서 가끔 하던 그 감각. 파일을 넓게 읽고 한 번에 정리하는 쪽.
API 키로 돌아가는 제품에서는 그게 바로 비용 폭발이었다. 후보 본문과 지도 메타를 통째로 넣으면 입력만으로 커지고, 종합 편집 출력이 또 길다. 실사용 원장에서도 비용의 대부분은 채팅이 아니라 정리 쪽이었다. 플래그십 모델에 큰 입력을 얹으면 누적이 보였다. 구체 단가 표는 여기 안 적는다. 감각은 분명했다. 제품이 매 턴 세컨드식 풀 분석 요약을 흉내 내면 안 된다.
그래서 요약 기준을 바꿨다. 원문은 일단 짧게 압축하고, 그걸 위키 문장으로 정리하는 게 1차다. 통째 종합 분석은 빼기로 했다. 입구에서는 공간 지도의 제목·요약·태그·경로 같은 메타만 넣고 본문 전체는 넣지 않았다. 기존에 붙이기를 우선하고, 새 문서는 정말 새 주제일 때만. 같은 문서에 붙일 때도 본문을 모델이 다시 쓰게 두지 않았다. 기계적으로 섹션을 이어 붙인다. 입구 판정 한 번 정도의 비용으로 예측 가능하게 만드는 쪽이었다.
분류 지도도 줄였다. second에는 핀·시간순·구조적 축이 겹쳐 있지만, 앱에서는 반응과 비용을 보고 구조적 축과 채팅용 위키 목차 쪽으로 좁혔다. 시간순 캐시나 원문 목차 비슷한 층은 걷어냈다. 핀은 문서를 만들지 않는 신호로만 남겼다. 분류 끝이 곧 위키 쪽 지도에 가깝게 붙었다. 지도가 얇아지니 조회는 단순해졌고, 대신 문서 파일이 잘게 늘어나기 쉬웠다.
파일이 늘면 병합이 온다
1:1 느낌이 줄어도 문서는 쌓였다. 업로드 배치, 세션 델타, 새 문서 억제가 덜 먹히는 공간일수록 카드가 많아졌다. 그때 관리 화면의 합치기가 중심이 됐다. 이미 쪼개진 문서를 나중에 묶는 도구.
처음 쪽은 본문까지 모델이 다시 쓰는 병합에 가깝게 가져가 봤다. 묶음마다 호출이 늘고, 문서 쓸 때마다 지도를 다시 그리는 식으로 느려졌다. 요약 한 번에 병합 호출까지 태우면 파일 몇 개만으로도 호출이 배가됐다. 시간 폭탄이자 토큰 폭탄이었다. 나는 문서화가 빠른 쪽이 낫다고 선을 그었다. 붙이기는 기계로 하고, 정교한 다듬기는 나중에.
합치기 계획 단계도 한동안 무거웠다. 지시문에 「sasame 병합」이라고 적어 뒀는데 전체 문서 병합 계획이 나온 적이 있다. 요약·태그·본문 쪽 메타를 너무 많이 넣으니 모델이 “다 묶어라” 쪽으로 기울었다. 그래서 「그리고 계획 너무 느려 제목만 보고 계획 잡게 수정해줘」가 바로 이어졌다. 계획 입력을 id와 제목 중심으로 줄였다. 지시가 있으면 그 키워드로 후보를 먼저 좁히고, 그 범위 안에서만 묶음 번호를 받게 했다.
그래도 함정은 남았다. 문서가 수백 개 쌓인 공간에서 계획을 한 번에 돌리면 입력이 대략 4.7만 토큰 근처까지 커지고, 출력 상한이 1200에 잘려 clusters: []만 돌아온 적이 있다. 빈 계획. 나중에 후보 축소와 분할 계획, 출력 상한을 손봤지만, 교훈은 단순했다. 계획조차 “전부 한 방에”면 잘린다.
최종 형태는 이렇게 고정됐다. 모델에는 제목과 짧은 요약, 그리고 무엇을 몇 번 묶음에 넣을지만 묻는다. 승인 뒤 본문은 순차로 붙인다. 대표 문서 아래에 나머지를 제목 단위로 이어 붙이는 스티치. 본문 재작성 호출은 그 경로에서 뺐다. 모듈도 계획과 적용, 순수 헬퍼로 갈라 두었다. 계획만 느리면 계획만 보면 되고, 적용은 결정적으로 돌린다.
한동안은 분류 지도만 보는 쪽이 더 깔끔하다고 느꼈다. 「오그래도 주제 합치는게 오히려 인덱스만 보는게 더 깔끔하네」. 실제로는 제목 목록을 모델에 한 번 넘기는 단계가 남았지만, 본문을 안 주는 선택은 유지했다. 주제 합치기의 품질은 서가와 키워드 쪽 제약으로 더 다듬게 됐다. 그건 다음다음 이야기에 가깝다.
빈도도 레버다
단가만 깎은 게 아니다. 안 돌리면 0원이다. 예전에는 채팅 마지막 답 뒤 유휴 몇 분이 지나면 자동으로 위키화를 걸었다. 편해 보였는데, 대화만 이어가도 잡이 쌓였다. 07-18에 그 제품 경로를 제거했다. 지금은 사람이 직접 남기기, 원천을 다시 돌리기, 관리 쪽 정리가 기본 경로다. 자동을 다시 켠다면 간격만 늘리는 것보다, 새 글자가 얼마 안 되면 모델 호출 자체를 건너뛰는 쪽이 맞다고 적어 두었다. 빈도는 단가와 같은 줄에 있는 레버다.
공식 API 단가를 원장에 넣는 작업도 했다. 「토큰비용 api검색해서 계산해서 넣어줘 일단 공식 api 비용으로」. 숫자의 출처를 맞추려는 요청이었다. 이 글에 표로 옮기진 않는다. 중요한 건 측정이 생기자 정리가 어디서 커지는지 보이게 됐다는 점이다.
포기가 설계가 됐다
남는 건 세 줄이다. 세컨드처럼 한 번에 다 읽고 종합하는 요약은, API 키로 과금되는 제품의 기본 경로에 두지 않았다. 원문 압축과 위키 문장 정리, 얇은 구조 지도가 남았다. 파일이 늘면 병합이 오고, 병합에서도 본문 재작성을 빼고 제목·요약으로 묶음만 받아 순차로 붙였다. 유휴 자동 요약은 끄고 사람이 켤 때만 돌리게 했다.
위키가 두껍지 않은 대신, 비용이 예측 가능한 쪽으로 기울었다. 완벽히 한 장으로 녹인 지식 베이스가 아니라, 빠르게 쌓고 나중에 묶는 서재에 가깝다. 그 묶기와 다시 나누기, 잘못 합친 걸 되돌리는 쪽이 관리의 시작이다. 제목만 고치려다 본문이 사라진 이야기부터 이어진다.