지난 글에서는 OKF로 조직의 지식을 정리하는 방법을 소개했습니다. 이번에는 일반 마크다운을 읽혀 만들던 판매자용 AI 리포트에 적용해 봤습니다. 원문을 그대로 주는 방식, 개념별로 요약하는 방식, 필요한 개념을 자동으로 고르는 방식을 180회 실험으로 비교했습니다.
현재 문서량과 사용 방식에서는, 일반 마크다운을 두고 OKF를 당장 도입할 이유를 찾지 못했습니다. 요약으로 입력이 줄어든 경우는 있었지만, 리포트의 판단이나 필요한 내용의 보존에서 기존 방식을 바꿀 만큼의 이점은 확인하지 못했습니다. 전처리와 조회를 운영할 부담까지 더하면 지금은 일반 마크다운을 유지하는 편이 낫다고 판단했습니다.
다시 시험할 시점은 텍스트가 지금보다 훨씬 길어졌을 때입니다. 문서를 한꺼번에 읽히기 어려워지면, OKF가 필요한 지식의 위치를 찾아가는 인덱스로서 도움이 될 수 있습니다. 그 가능성은 이번 실험으로 확인한 결과가 아니라, 문서량을 늘려 검증할 다음 질문입니다.
01. 같은 파이프라인에 세 가지 입력을 붙였다
리포트는 판매자의 상품·SNS·마켓 상태를 읽고, 무엇을 바꿀지 카드 형태로 제안하는 HTML입니다. 이미 생성 파이프라인이 있었기 때문에, 본체를 세 벌 만들 필요는 없었습니다. 원천을 가져오는 page_sources와 요청 본문을 만드는 page_payload, 두 지점에서 입력만 갈아 끼웠습니다.
페이지별로 지정된 문서 목록을 이어 붙입니다.
생성 프롬프트에 맞춰 요약하고 결과를 캐시합니다.
DB의 개념 인덱스에서 경로를 골라 본문을 전달합니다.
요약 번들은 파일 폴더가 아니라 DB에 담았다
원천 문서와 해당 영역의 생성 프롬프트를 전처리 LLM에 함께 넣었습니다. 돌아온 결과는 {path, content} 배열로 파싱해 DB 한 행에 저장했습니다. 논리적으로는 여러 개념 파일이지만, 실제 파일 트리를 만드는 구현은 아닙니다.
요약을 처음 만드는 데 약 302초가 걸린 사례도 있었습니다. 따라서 입력이 짧아졌다고 전체 비용이 곧바로 줄지는 않습니다. 캐시를 얼마나 재사용하는지가 중요합니다. 캐시 키에는 원천 해시와 전처리 프롬프트 식별자를 넣었지만, 생성 프롬프트 변경은 무효화 조건에서 빠져 있었습니다. 생성 목적에 맞춘 요약인 만큼, 이 부분도 운영에서 관리해야 합니다.
이 구현은 OKF에서 착안해 개념별 요약을 만드는 방식입니다. frontmatter를 쓰도록 지시했지만 규약 준수 검증기는 붙이지 않았습니다. verified·stale_after 같은 신뢰 메타데이터의 활용도 이번 실험에는 포함하지 않았습니다.
개념 조회는 별도 서브시스템이 됐다
조회 방식은 원천을 개념으로 나눠 DB에 적재한 다음, 인덱스를 읽고 필요한 경로를 선택합니다. 원문 보존이 필요한 문서는 변환 없이 저장합니다. 선택 결과를 정답 경로와 비교하고 관리 화면에 지표를 보여 주는 경로도 만들었습니다.
조회 방식은 60회 모두 선택 캐시를 재사용했습니다. 결국 이 실험이 반복 측정한 것은 매번 새로 검색하는 시스템이 아니라, 한 번씩 선택해 둔 여섯 입력으로 생성한 리포트입니다. 캐시를 재사용하면 정답 대조를 건너뛰는 구현 때문에, 조회 정밀도와 재현율은 60회 모두 비어 있었습니다. 출력 반복성은 쟀지만, 조회의 본업은 직접 채점하지 못한 셈입니다.
02. 180회라는 숫자의 안쪽
실험은 2026년 9월 2~3일에 진행했습니다. 판매자 두 곳의 상품·SNS·마켓, 여섯 요청을 각각 세 입력 방식으로 열 번씩 생성했습니다. 같은 요청과 입력 방식의 묶음을 아래에서는 ‘셀’이라고 부릅니다. 총 18셀입니다.
모델과 추론 강도를 고정하고, 추가 정제와 후보 심사를 껐습니다. 원문·요약 비교는 페이지 안에서 방식을 교대로 실행했습니다. 개념 조회는 별도 실행으로 추가했으므로, 세 방식 전체가 한 번에 무작위 배정된 실험은 아닙니다. 조회 6셀 중 3셀은 나머지 방식과 원천 문서의 시점이 달랐습니다.
| 구분 | 개수 | 의미 |
|---|---|---|
| 반복 실험 설계 | 180회 | 2 × 3 × 3 × 10 |
| 저장된 실행 기록 | 182개 | 회수한 여분 결과와 타임아웃 기록 포함 |
| HTML이 있는 기록 | 181개 | 원문 61 · 요약 60 · 조회 60 |
| 안정도 계산에 사용 | 173개 | 여분 1 · 원천 변경 6 · 붕괴 출력 1 제외 |
따라서 글의 ‘180회’는 실험 설계 규모입니다. 안정도 표는 173개, 문자 이상 후보 탐색은 HTML이 남아 있는 181개를 대상으로 합니다. 타임아웃 한 건은 기존 집계의 파일명 패턴에서 빠져 있었습니다. 이를 실패가 없었다고 읽어서는 안 됩니다.
요청 바이트 대조로 확인한 범위
요청을 실제 파이프라인과 같은 규칙으로 재조립하고 호출 로그에 대조했습니다. 저장된 검증 기록은 118건입니다. 이 중 로그가 잘리지 않았고 시스템·사용자 메시지가 모두 일치한 것은 97건, 사용자 로그가 잘린 것은 19건, 사용자 메시지 불일치는 2건이었습니다. 이 장치는 비교 조건을 점검하는 데 도움이 됐지만, 180회 전체의 입력 통제를 완전히 증명한 것은 아닙니다.
03. 비슷한 말을 했는가, 같은 내용을 말했는가
첫 번째 지표는 기계적으로 계산한 단어 집합의 자카드 유사도입니다. HTML 태그를 벗긴 뒤 단어 집합을 만들고, 같은 셀의 모든 출력 쌍을 비교해 평균을 냈습니다. 열 개가 남은 셀이라면 45쌍입니다. 이 쌍들은 출력을 공유하므로 독립적인 45회 실험을 뜻하지는 않습니다.
같은 방식으로 카드 제목 집합도 비교했습니다. 단어 유사도는 어휘의 반복을, 제목 유사도는 화면 구성의 일부를 보여 줍니다. 어느 쪽도 사실의 정확성이나 내용의 완전성을 직접 측정하지 않습니다. 똑같은 항목을 매번 빼먹어도 유사도는 높게 나올 수 있습니다.
두 번째는 내용 검수입니다. 태그·클래스·이미지 URL을 걷어 내고 제목·판정·근거·확인 항목·표 행을 남긴 ‘골격’을 LLM 검수자에게 읽혔습니다. 판정, 제안, 수치, 확인, 구조의 다섯 축을 평가하고, 늘 같은 항목과 달라진 항목을 뽑았습니다. 여기서 나온 불일치 134건은 별도 검증 패스에서 96건 확인, 37건 부분 확인, 1건 미확인으로 분류됐습니다. 사람의 정답지로 전량 검증한 결과는 아닙니다.
계산 방식의 한계
토크나이저는 공백과 일부 구두점으로만 분리합니다. 쉼표·마침표도 분리자여서 숫자가 쪼개질 수 있고, 단어의 순서와 빈도는 보지 않습니다. 제목은 특정 HTML 태그 패턴으로 추출하므로 의미가 같아도 마크업이 바뀌면 결과가 달라질 수 있습니다. 글의 수치는 기존 규칙을 유지해 원본 HTML에서 재계산한 값입니다.
04. 요약을 주면 같은 단어를 더 많이 썼다
단어 유사도에서는 요약 번들이 원문보다 여섯 요청 모두 높았습니다. 셀 평균은 원문 62.4, 요약 72.6, 개념 조회 59.1입니다. 요약과 원문의 평균 차이는 10.2%p였습니다.
이 결과에는 입력 길이, 요약 과정, 표현의 통일 효과가 함께 섞여 있습니다. 내용은 그대로 두고 포맷만 바꾼 실험이 아니기 때문에, 상승분을 OKF 문법 자체의 효과로 분리할 수는 없습니다.
요청 영역별 차이도 컸습니다. 상품의 평균은 86.7, SNS는 60.1, 마켓은 47.2였습니다. 영역별 평균의 폭은 39.6%p, 입력 방식별 평균의 폭은 13.5%p입니다. 이번 여섯 요청에서는 입력 방식보다 요청 영역에 따른 차이가 크게 관측됐습니다.
단어가 비슷해져도 내용까지 보장되지는 않는다
판정 일관성의 평균 점수는 원문 90.0, 요약 89.8, 조회 89.2로 비슷했습니다. 재평가 과정의 점수 변동이 이 차이보다 컸기 때문에, 이 점수로 어느 방식의 판단이 더 안정적인지 가리기는 어려웠습니다. 확인한 효과는 입력이 줄어들고 표현이 비슷해진 것입니다. 이것만으로 현재의 마크다운 방식을 OKF로 바꿀 만큼 결과물이 좋아졌다고 보기는 어려웠습니다.
05. 권고의 방향보다 근거와 구성이 더 자주 달라졌다
점수보다 흥미로웠던 것은 검수자가 뽑은 항목 목록입니다. ‘늘 같았다’고 분류한 312건과 ‘회차에 따라 달랐다’고 분류한 216건을 내용별로 다시 묶었습니다.
판정·제안 항목에서는 고정으로 분류된 항목의 비중이 79.1%, 수치에서는 43.5%였습니다. 이것은 “판정이 열 번 중 여덟 번 재현됐다”는 뜻이 아닙니다. 서로 다른 분모를 가진 항목 목록의 구성비입니다. 한 항목을 얼마나 잘게 나눴는지에 따라 값도 달라집니다.
그래도 리포트를 읽을 때 주목할 위치는 드러났습니다. 권고의 방향이 비슷해 보여도, 근거로 고르는 숫자와 덧붙이는 확인 항목은 달라질 수 있었습니다. 그렇다고 행동이 늘 고정된 것도 아닙니다. 심각 등급 불일치 14건 중 4건은 판정·제안에 관한 것이었습니다.
06. 반복 실험에서 함께 발견한 문제
입력 방식 비교와 별개로 생성 과정의 결함도 눈에 띄었습니다. 한 출력은 753자, 카드 0장이었는데 성공으로 저장됐습니다. 같은 셀의 다른 아홉 출력은 평균 10,371자에 카드가 모두 6장이었습니다.
문장 중간에 ennials 같은 문자열이나 작업 흔적이 끼어 있는 결과도 있었습니다. 전체 HTML 181개에서 드물게 등장하는 라틴 토큰을 찾아보니 재검토 후보가 23개 나왔습니다. 원문 5/61, 요약 10/60, 조회 8/60으로 세 방식 모두에 있었습니다. 드문 정상 어휘도 포함될 수 있어 이 숫자를 곧바로 오염률로 보지는 않았습니다.
이런 결함은 생성 파이프라인에서 따로 다룰 문제입니다. 이번에 지식을 전달하는 방식을 바꿔 봤지만, 그 변경만으로 결과물을 믿고 쓸 수 있게 된 것은 아니었습니다.
07. 지금은 일반 마크다운을 유지한다
요약의 압축 효과는 분명 있었습니다. 상품 영역에서는 입력이 약 60~65% 줄었습니다. 하지만 SNS처럼 원래 짧은 입력에서는 오히려 커졌습니다.
| 요청 | 원문 | 요약 | 변화 |
|---|---|---|---|
| 판매자 A · 상품 | 81,782자 | 32,699자 | -60.0% |
| 판매자 B · 상품 | 87,888자 | 30,563자 | -65.2% |
| 판매자 A · SNS | 24,567자 | 27,155자 | +10.5% |
| 판매자 B · SNS | 24,237자 | 25,483자 | +5.1% |
표는 입력의 문자 수입니다. 요약을 만드는 LLM 호출과 캐시 관리가 추가되므로, 문자 수 감소가 곧 전체 비용 절감을 뜻하지는 않습니다. 무엇보다 입력을 압축할 수 있다는 사실만으로 OKF를 도입해야 하는 것은 아닙니다. 현재 마크다운으로 하던 일을 바꿀 만큼의 이득이 있는지가 기준이어야 합니다.
개념 조회도 전환을 뒷받침하지 못했습니다. 다른 방식의 핵심 출력 항목과 대조했을 때 보존된 항목은 18/46 또는 25/51에 그쳤고, 심각 불일치 14건 중 12건이 조회 방식에서 나왔습니다. 이 수치는 검색 정답지로 잰 재현율이 아니라 출력 항목끼리 비교한 결과입니다.
이번에 만든 조회 구현에는 프로덕션·테스트·DDL 합계 5,820줄, 라우트 20개, 테이블 4개가 들어갔습니다. 이 규모는 OKF 규격 자체의 요구사항이 아니라 제가 만든 구현의 유지 부담입니다. 기존 방식보다 뚜렷한 이점을 얻지 못한 상태에서 이 부담을 운영에 추가할 이유는 없었습니다.
그래서 현재 서비스는 일반 마크다운을 사용하는 방식을 유지하고, OKF 도입은 보류하는 것이 이번 실험의 결론입니다. 요약이나 개념화가 가능하다는 것과, 지금 도입할 필요가 있다는 것은 별개의 판단이었습니다.
08. 문서가 더 길어지면 인덱스로서 다시 시험한다
현재는 요청마다 필요한 마크다운 문서 목록을 정해 전달하고 있습니다. 문서 수와 길이가 계속 늘어나면 이 목록을 관리하거나 원문을 한꺼번에 넣는 방식이 부담스러워질 수 있습니다. 그때는 필요한 개념과 원문 위치를 찾아가는 인덱스가 의미를 가질 수 있습니다.
확인하고 싶은 것은 OKF로 만든 인덱스가 더 적은 입력으로 필요한 지식을 빠짐없이 찾아주는가입니다. 문서량을 단계적으로 늘리면서 일반 마크다운을 직접 전달하는 방식, 마크다운에 간단한 목차를 붙이는 방식, OKF 개념 인덱스를 사용하는 방식을 비교해 볼 필요가 있습니다. 인덱스를 둔 효과와 OKF를 선택한 효과를 구분하기 위해서입니다.
그 비교에서 필요한 항목의 보존, 입력량, 처리 시간과 비용에 실익이 나타난다면 도입을 다시 검토할 수 있습니다. 이번 조회 실험은 선택 결과를 캐시해 반복 사용했기 때문에, 문서가 많아졌을 때 인덱스로 얼마나 잘 찾아가는지까지는 확인하지 못했습니다.
댓글
한글·영문 페이지가 같은 댓글을 공유합니다.
댓글을 불러오는 중…