문제점: AI 출력은 확률적이며, 프롬프트에는 한계가 있습니다

LLM(Large Language Models)은 확률적인 출력을 생성합니다. 프롬프트가 아무리 훌륭하더라도 환각 (hallucinations), 누락 (omissions), 형식 이탈 (format drift), 그리고 논리적으로 맞지 않는데도 확신에 찬 듯 들리는 합리화와 같은 예외 상황(edge cases)에서 실패할 수밖에 없습니다.

저는 Claude Code를 매일 사용하면서 이 점을 발견했습니다. AI는 "완료되었습니다"라고 말하지만 파일은 작성되지 않았습니다. "로그가 업데이트되었습니다"라고 주장하지만 타임스탬프는 3일 전의 것이었습니다. AI가 거짓말을 한 것이 아닙니다. 확률적 출력은 본질적으로 불안정합니다.

순수한 프롬프트 엔지니어링 (prompt engineering)은 확률로 확률에 맞서 싸우는 것입니다. 궁극적인 방어책은 반드시 결정론적 (deterministic)이고 기계적인 점검이어야 합니다.

해결책: 5단계 중 4단계는 스크립트입니다. 오직 1단계만이 AI를 필요로 합니다.

저는 폐쇄 루프 피드백 메커니즘 (closed-loop feedback mechanism)을 갖춘 에이전트 설정 시스템을 구축했습니다:

self-model.md (현재의 자기 인지)
    ↓
세션 실행 (설정에 따라 AI가 작업 수행)
...

4단계는 기계적인 스크립트입니다: 파일 타임스탬프 점검, 종료 코드 게이트 (exit code gates), JSONL 감사 추적 (audit trails), 플래그 파일 I/O.
1단계는 AI가 필요합니다: 콘텐츠 재생성 — 축적된 성장 데이터를 업데이트된 자기 인지로 합성하는 과정.

기계는 점검을 수행합니다. 인간과 AI는 판단을 수행합니다. 이것은 철학이 아니라 엔지니어링입니다.

주요 설계 결정

1. 의존성 제로, 표준 라이브러리 (stdlib)만 사용

모든 스크립트는 Python의 표준 라이브러리만을 사용합니다. 품질 점검 도구가 새로운 의존성 리스크를 초래해서는 안 되기 때문입니다.

2. 이중 레이어 게이트: 소프트 리마인더(soft reminder) + 하드 블록(hard block)

• 프로세스 레이어 (소프트): 규칙 실행률이 낮은가? 상기시키되, 차단하지는 않습니다.
• 출력 레이어 (하드): 학습 로그가 업데이트되지 않았는가? Exit 2, 하드 블록. 결과물은 반드시 완결되어야 합니다.

경계의 기준은 중요도가 아니라, **"이것을 나중에 수정할 수 있는가?"**입니다.

3. 데이터베이스로서의 파일 시스템

벡터 데이터베이스 (vector databases)를 사용하지 않습니다. 클라우드 서비스도 없습니다. 모든 정체성 데이터, 성장 로그, 감사 기록은 로컬 Markdown + JSON 파일로 관리됩니다. Git으로 감사가 가능하며, 오프라인 작업이 가능하고, 완전히 자기 주권적 (self-sovereign)입니다.

외부 검증: 100K 스타 프로젝트에 제출하기

제 개인 시스템에서 모듈 하나(delivery-gate)를 추출하여 ECC(스타 100K개 이상)에 제출했습니다.

결과: 메인테이너(maintainer) daltino가 이를 검토하고 찬사와 함께 승인했습니다. 메인테이너 affaan-m은 후속 PR(Pull Request) 두 개를 직접 머지(merge)했습니다. 200줄 분량의 Python 스크립트가 커뮤니티 봇(bot) 검토 4회와 인간 메인테이너 검토를 거치며, 제가 자체 테스트에서 발견하지 못했던 4가지 이슈를 잡아냈습니다.

오픈소스 커뮤니티 검토는 당신이 얻을 수 있는 최고의 무료 QA(Quality Assurance)입니다. 이것이 저의 "오픈소스 플라이휠 (open-source flywheel)" 방법론이 되었습니다: 자신을 위해 구축하기 → 모듈 추출하기 → 커뮤니티의 공백 발견하기 → PR 제출하기 → 자신의 시스템에 다시 머지하기.

유사한 작업을 하고 싶다면

1. 먼저 도그푸딩 (Dogfood it) 하세요. 저는 무언가를 제출하기 전에 제 시스템을 50회 이상의 실제 세션에 돌려보았습니다.
2. 프롬프트가 아닌 스크립트를 사용하세요. Python의 if/else 문으로 확인할 수 있다면, 자연어(natural language)로 설명하지 마세요.
3. 작은 PR이 승리합니다. 대규모 프로젝트의 경우, 메인테이너 검토를 받기에 가장 적절한 규모는 100~300줄 사이입니다.
4. 공백 메우기 템플릿을 사용하세요. "이 레포지토리(repo)에는 X와 Y가 있습니다. 하지만 Z가 없습니다. 이 PR은 그 공백을 채웁니다."

진짜 핵심 교훈

저는 학부 3학년생입니다. 저의 순수 코딩 속도는 아마 LeetCode를 아침 식사처럼 해치우는 컴퓨터공학(CS) 전공자들을 이기지 못할 것입니다. 하지만 저는 그보다 더 중요한 한 가지를 배웠습니다:

AI 시대의 핵심 역량은 타이핑 속도가 아닙니다. 무엇을 AI에게 맡길 것인지, 그리고 무엇을 결정론적 규칙 (deterministic rules)으로 강제해야 하는지를 아는 것입니다.