메모리 게이트가 실제 아카이브를 만났을 때: 90번의 실험을 통해 배운 저가형 LLM 슬롭(Slop)에 대하여
요약
MICA(Memory Invocation and Context Archive) 프레임워크를 활용하여 저가형 LLM의 슬롭(Slop) 현상을 관리하고 검증하는 실험적 워크플로우를 소개합니다. 90여 차례의 실험을 통해 물리, 생물학, 규제 준수 분야에서 발생하는 데이터 드리프트 문제를 분석하고 이를 방지하기 위한 게이트 메커니즘을 다룹니다.
핵심 포인트
- MICA를 통한 세션 시작 시 규칙 일관성 확인
- EQA, BAV, BSC 세 가지 경로를 통한 데이터 검증
- 프레이밍, 상태 중복, 출처 드리프트 등 슬롭 현상 식별
- 실험 아티팩트의 정적 원장(Static Ledger) 구축 및 공개
서론: MICA 계약의 강제 적용
이 글은 MICA 시리즈의 실무적인 측면을 다룹니다. MICA는 _Memory Invocation and Context Archive_의 약자입니다. 여기서 설명하는 워크플로우에서 MICA는 유지 관리자(maintainer)가 세션 시작 시 로드하는 작은 패키지로, 어떤 코드도 건드리기 전에 활성화된 규칙들을 확인할 수 있게 해줍니다.
파트 6과 7에서 계약(contract)을 설정합니다. 이 글은 실제 과학적 아카이브(archive)에 단일 유지 관리자가 수동으로 감당할 수 있는 것보다 더 많은 영역에서 저가형 슬롭(slop)이 쌓이기 시작했을 때, 그 계약이 어떤 역할을 했는지 보여줍니다.
이 아카이브는 Flamehaven Verification Ledger입니다. 여기서는 세 가지 종류의 기록을 발행합니다.
- EQA (Equation-to-Artifact). 물리 및 수학 재현. 현재
TOE-TEST-0001부터TOE-TEST-0056까지 번호가 매겨진 56개의 기록이 있습니다. 예: 슈바르츠칠트 플랑크 규모 메트릭(Schwarzschild Planck-scale metric) 검증. - BAV (Biomolecular AI Validation). 여러 AI 폴딩 모델(AlphaFold3, AlphaFold2, Chai-1, Boltz-2)에 걸친 단백질 구조 예측(protein-folding) 합의 확인. 현재 34개의 실험이 진행 중이며, 6개의 활성 카드와 26개의 항목으로 구성된 기초 아카이브가 있습니다.
- BSC (Bioscience Compliance). 외부 리스크 분류 체계(MIT AI Risk Repository 및 EU AI Act)에 대한 저장소 준수 감사. 현재 2건의 감사가 진행되었습니다.
총합 약 90개의 실험이 수행되었습니다. 전체 파일 수는 300개를 넘어섰습니다. 모든 기록은 공개됩니다. 이 아카이브는 인용될 것을 목적으로 합니다. 만약 AI 유지 관리자가 표류(drift)한다면, 그 표류는 하류(downstream) 논문 인용으로 이어질 수 있습니다.
이야기를 시작하기 전에 한 가지 범위(scope)에 대한 주의 사항이 있습니다. flamehaven-audit-reports는 이러한 결과들을 계산하는 엔진이 아닙니다. 이는 공개적인 증거 표면(evidence surface)입니다. 상류(upstream) 엔진과 실험 저장소들이 가공되지 않은 아티팩트(raw artifacts)를 생성합니다.
이 저장소는 해당 아티팩트들을 수집하여, 출판을 위해 정제(sanitize)하고, 어떤 종류의 기록인지 분류하며, 다른 사람들이 검사하고 인용할 수 있는 정적 원장(static ledger)으로 렌더링합니다.
세 가지 경로(lanes)는 이미 우리에게 세 가지 다른 형태의 저가형 슬롭(cheap slop)을 가르쳐 주었습니다. EQA는 대규모 환경에서의 프레이밍 드리프트(framing drift, 실제 검사 결과가 없음에도 PASS로 표시되는 기록)에 대해 가르쳐 주었습니다. 포털(portal)은 상태 중복(state duplication, 디스크 파일과 일치하지 않고 어긋나는 인라인 JavaScript 복사본)에 대해 가르쳐 주었습니다.
BAV는 출처 드리프트(provenance drift), 아티팩트 정체성 드리프트(artifact-identity drift), 그리고 실제 실행 결과 주변의 과도하게 깔끔한 프레젠테이션(over-clean presentation)에 대해 계속해서 우리를 가르치려 합니다. 이 글은 이 세 가지 상처를 순서대로 짚어본 뒤, 그 상처들로부터 성장한 게이트(gate)에 대해 설명합니다.
📖 용어 사전 (Glossary)
짧은 목록입니다. 훑어보고 넘어가세요.
- MICA. 유지 관리자가 세션 시작 시 로드하는 작은 패키지입니다. 규칙을 담고 있으며, 쓰기 작업이 시작되기 전 패키지 상태가 일관성(coherent)이 있는지 노출합니다.
- DI (Design Invariant, 설계 불변량). ID가 부여된 규칙입니다. 예:
DI-EQA-001은 수학 실행 시mpmath를 200비트 정밀도 이상으로 사용해야 함을 명시합니다. - Playbook (플레이북). 마크다운(markdown) 파일입니다. 사람들이 읽는 문서이며, 내부의 모든 규칙은 DI를 인용합니다.
- Schema (스키마). 두 개의 기계 판독 가능(machine-readable) 파일입니다.
mica.yaml은 패키지의 형태를 담고 있으며,archive.json은 28개의 DI를 담고 있습니다. - Validator (검증기).
mica_pct.py입니다. 패키지 루트에서 실행될 때,CLOSED CONTRACT또는INCOMPLETE를 출력합니다. - Receipt (영수증). 실행이 실제로 이루어졌음을 증명하는 작은 JSON 블록입니다. 엔진 커밋 해시(commit hash), 실행 명령, 그리고 출력 해시를 고정(pin)합니다.
- EQA / BAV / BSC. 아카이브의 세 가지 경로입니다. 물리 수학, 단백질 구조 예측(protein folding), 컴플라이언스(compliance)를 의미합니다.
나머지를 읽기에는 이 정도면 충분합니다.
1. 우리가 이야기하고 있는 아카이브
이야기에는 구체적인 주인공이 필요합니다. 주인공은 바로 아카이브 그 자체입니다. 서론에서는 세 가지 경로를 명시했습니다. 이 섹션에서는 파일의 형태, 세 가지 실시간 수치, 그리고 글의 나머지 부분에서 계속 언급될 정직한 범위(scope) 라벨을 추가합니다.
주인공은 단일 프로그램이 아닙니다. 그것은 계층화된 출판 시스템(layered publication system)입니다. 상류(upstream) 계산은 엔진 또는 실험 리포지토리(repository)에서 발생합니다. flamehaven-audit-reports는 그러한 출력물들이 공개 기록으로 전환되는 장소입니다.
해당 투영 계층 (projection layer)은 명시적으로 명명되지 않으면 서로 혼동하기 쉬운 네 가지 작업을 수행합니다:
- 상류 아티팩트 (upstream artifact) 수집
- 그대로 게시되어서는 안 되는 모든 항목의 정화 (Sanitize)
- 해당 기록이 실제로 어떤 종류의 증거인지에 따른 분류
- 정적 검사 표면 (static inspection surface)을 통한 렌더링
세 가지 경로 (lanes)가 해당 표면 내부에서 모두 동일하게 작동하는 것은 아닙니다:
- EQA 경로: 결정론적 계산 아카이브 (deterministic computation archive)에 가장 가깝습니다.
- BAV 경로: 파이프라인 및 거버넌스 (governance) 비중이 높습니다. 원장 (ledger)은 실제 재실행 가능한 실험, 런타임 감사 (runtime audit), 그리고 연구 또는 검토 아티팩트 (research or review artifact)를 구분해야 합니다.
- BSC 경로: 리포지토리 상태를 외부 컴플라이언스 분류 체계 (compliance taxonomies)에 직접 매핑합니다.
각 EQA 기록은 최소 두 개의 파일을 포함합니다. 기계 판독이 가능한 internal_data.json은 영수증을 보유하며, 인간이 읽을 수 있는 analysis_report.md는 서사 (narrative)를 보유합니다. 일부 기록은 SPAR 검토 기록도 함께 전송합니다. 현재 가장 강력한 세 가지 기록은 다음과 같습니다:
- Schwarzschild 플랑크 규모 메트릭 검증. 엔진 재실행 결과
Omega = 0.9985를 생성했습니다. - de Sitter 배경 체크.
sqrt_jsd = 0.2722로 기록되었습니다. - OpenAI Erdős Eq.(2.2) 재현. 주장: 발표된 값과 0.014% 일치합니다. 공개된 MIT 리포지토리 및 Zenodo DOI에 고정되어 있습니다.
BAV 경로는 자체 규모에 대해 정직합니다. 6개의 활성 카드 중 단 하나(EXP-031)만이 접을 수 있는 입력 시퀀스 (foldable input sequence)를 포함합니다. 이는 AlphaFold3, AlphaFold2, Chai-1, 그리고 Boltz-2를 대상으로 실행된 52-아미노산 입력값입니다.
나머지 다섯 개의 카드는 거버넌스 및 방법론 실험입니다. 이들은 재실행 스캐폴드 (re-run scaffold)를 제공하지 않습니다. 그 경계는 정직합니다. 우리는 빈 슬롯을 채우기 위해 가짜 폴드 (fake fold)를 만들어내지 않았습니다.
총 파일 수는 300개를 넘어섰습니다. 이 숫자는 중요합니다. 관리자 한 명은 5개의 기록을 수동으로 검토할 수 있습니다. 하지만 아무도 300개를 검토할 수는 없습니다. 슬롭 (Slop)은 파일 수에 따라 확장되지만, 검토는 그렇지 않습니다.
2. EQA 경로가 우리에게 처음으로 가르쳐준 것
첫 번째 상처는 숫자가 아니라 라벨 (labels)에 관한 것이었습니다. 숫자는 정확했습니다. 하지만 그 주변의 라벨들이 틀렸습니다.
2026년 6월, 우리는 물리 및 수학 재현물 (reproductions)을 게시하는 레인(lane)인 EQA 아카이브에 대해 내부 감사 (internal audit)를 실시했습니다. 계획은 계산 결과들을 표본 점검 (spot-check)하는 것이었습니다. 우리는 기록 샘플에 대해 엔진을 다시 실행했습니다. 숫자는 일치했습니다.
슈바르츠실트 지평선 (Schwarzschild horizon) 계산 결과는 Omega = 0.9985로 나왔습니다. 드 시터 배경 (de Sitter background) 확인 결과는 sqrt_jsd = 0.2722였습니다. 수학적 내용은 정직했습니다.
감사 결과는 다른 문제를 발견했습니다.
공개 웹사이트는 56개의 기록 중 51개에 초록색 PASS 배지를 표시하고 있었습니다. 초록색 PASS는 수치 확인 (numerical check)이 실행되었고 그 결과가 임계값 (threshold)을 통과했음을 의미해야 합니다. 하지만 웹사이트는 그렇게 작동하고 있지 않았습니다.
웹사이트는 실제 확인 작업이 실행되었는지 여부와 상관없이, 마크다운 분석 파일 (markdown analysis file)이 있는 모든 기록을 PASS로 취급하고 있었습니다. 거버넌스 노트 (Governance notes), 시나리오 빌드 (scenario builds)
모든 것이 일치할 때 검증기(validator)가 방출하는 계약 상태를 CLOSED CONTRACT라고 부릅니다. 이것이 검증기 자체에 의해 모든 의미론적 규칙(semantic rule)이 자동으로 강제된다는 것을 의미하지는 않습니다.
이는 패키지 구조, 선언된 레이어(layers), 그리고 DI 바인딩(DI bindings)이 일관성을 유지하고 있으며, 유지 관리자(maintainer)가 아카이브를 변경하기 전에 해당 계약 내에서 실행될 것을 기대한다는 의미입니다.
이것은 어떤 CI 게이트(CI gate)나 구문 검사(syntax check)로도 잡아낼 수 없는 종류의 실패입니다. 수학은 정확했습니다. 프레이밍(framing)이 틀렸던 것입니다. 마크다운(markdown) 전용 정책이었다면 모든 파일이 깔끔하게 파싱되었을 것이기에 이를 계속 허용했을 것입니다. 이 규칙이 이러한 종류의 압박 속에서도 살아남을 수 있었던 이유는
이러한 환경에서 살아남아야 하는 객체들은 LLM이 스스로 검증하기에 가장 취약한 것들입니다. SMILES 문자열, DOI, AlphaFold의 pLDDT 값(폴드에 대한 잔기별 신뢰도 점수), 물리적 의미를 지닌 수치 임계값, 그리고 레코드 수준의 출처(provenance) 등이 그러합니다. 이 중 그 어느 것도 맞춤법 검사기나 지속적 통합 (CI) 파이프라인으로는 잡아낼 수 없습니다.
이것이 바로 아카이브에 코드가 수정되기 전에 먼저 로드되는 게이트(gate)가 필요한 이유입니다.
4. 크로스 레인 게이트(Cross-Lane Gate)를 강제하게 만든 실패
두 번째 흉터는 아카이브를 보여주는 웹사이트 내부에 있었습니다.
해당 사이트는 독자의 브라우저에서 실행되는 JavaScript 파일(js/portal.js) 안에 모든 레코드의 폴백 (fallback) 복사본을 포함하여 배포하곤 했습니다. 원래 목적은 해롭지 않았습니다. 일부 독자들은 저장소(repository)를 다운로드한 뒤 홈페이지를 더블 클릭하여 열곤 하는데, 이때 file:// URL 스킴이 사용됩니다. 일부 브라우저는 보안상의 이유로 file:// 환경에서 별도의 JSON 파일을 로드하는 것을 거부하기 때문에, 폴백 방식은 페이지가 어떻게든 렌더링될 수 있도록 해주었습니다. 두 개의 작은 함수가 이 폴백을 담당했습니다. 하나는 특정 레코드에 대한 데이터셋 복사본을 반환했고, 다른 하나는 사람이 읽을 수 있는 보고서의 복사본을 반환했습니다.
디스크 상의 파일들은 계속해서 변경되었습니다. 하지만 JavaScript 내부의 인라인 (inline) 복사본들은 변경되지 않았습니다. 이러한 드리프트 (drift)는 몇 주에 걸쳐 조용히 커져갔습니다.
한 유지 관리자(maintainer)가 작은 드리프트 확인 스크립트를 작성하여 실행했습니다. 이 스크립트는 디스크 상의 모든 레코드를 인라인 쌍둥이와 비교했습니다. 그 결과 두 복사본이 일치하지 않는 지점을 151곳 찾아냈습니다. 가장 충격적인 사례는 Erdős 복제에 관한 레코드였는데, 이 레코드의 schema_id 필드는 두 복사본 사이에서 구조조차 일치하지 않았습니다. AI 유지 관리자가 디스크 파일을 편집하고 있었던 것입니다. 반면 웹사이트는 오래된 인라인 복사본을 렌더링하고 있었습니다. 양쪽 모두 내부적으로는 문제가 없어 보였습니다. 하지만 어느 쪽도 서로 일치하지 않았습니다.
GOVERNANCE.md 파일에는 내내
EQA 프레이밍 감사 (framing audit)와 동일한 형태입니다. MICA 검증기 (validator)가 아닌 사람이 그 편차 (drift)를 포착했습니다. 현재 MICA가 수행하는 작업은 패키지 계약 (package contract) 및 주변 문서에 새로운 규칙을 보존하는 것입니다. 이 규칙을 쉬운 영어로 설명하자면 다음과 같습니다: 어떤 레코드(record)의 인라인 복사본(inline copy)도 브라우저 코드 내부에 포함되어 배포될 수 없습니다. 기존에 인라인 복사본을 반환하던 두 함수는 제거되었으며, 빈 값을 반환하는 스텁 (stub)으로 교체되었습니다. 이 스텁들은 히스토리를 인라인으로 포함하고 있어, 향후 이 파일을 읽는 유지보수자는 규칙과 해당 규칙을 강제하게 만든 사건을 모두 확인할 수 있습니다.
function getFallbackReportText(runId) {
// 제거됨 (v1.13.1): 인라인화된 report-text 폴백(fallback)이 디스크 상의 .md 리포트와 편차(drift)가 발생함
// 단일 진실 공급원 (Single source of truth) = 위에서 가져온 디스크 상의 파일들.
...
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기