DEV.to의 한 낯선 이가 "이 실험을 해보세요"라고 말했습니다. 저는 n=600 규모로 실험을 진행했습니다. 그 과정에서 일어난 일들을 공유합니다. 그가 제가 사후 분석 결과(post-hoc findings)를 마치 계획된 것처럼 보고하던 것을 잡아낸 부분도 포함되어 있습니다.

배경 이야기

Mike Czerwinski는 AI 에이전트가 규칙을 따르는 것에 관한 제 글을 읽었습니다. 그는 구체적인 실험을 제안했습니다. 기계적 게이트(mechanical gate) 하에서 산문 형식(prose-format)의 규칙을 테스트하는 것이었습니다. 명령어가 아닌 서사(narrative) 형태로 규칙을 작성함으로써 100%의 준수율(compliance)과 깊은 추론(deep reasoning)을 모두 얻을 수 있을까요?

저는 예스(yes)라고 시사하는 파일럿 데이터(pilot data)를 가지고 있었습니다. Mike는 파일럿 데이터의 천장 효과(ceiling)가 아마도 노이즈(noise)일 것이라고 지적했습니다. 그의 말이 맞았습니다. 저는 완전한 2×2 요인 설계(factorial experiment)를 설계했고 n=600으로 실행했습니다.

하지만 그전에 저는 다른 일을 하나 했습니다. 이전에는 한 번도 해본 적 없는 일 말입니다.

사전 등록 (1인 연구자 버전)

저는 OSF 레지스트리(OSF registry)가 없습니다. 지도 교수님도 없습니다. 저에게 있는 것은 Git 저장소(repository)와 Python 스크립트뿐입니다.

단 한 번의 API 호출을 실행하기 전에, 저는 실험 스크립트 헤더에 가설을 작성했습니다:

"""사전 등록된 가설: GateGuard-OFF 상태에서 형식(Format)이 추론 깊이(reasoning depth)에 미치는 영향이 더 크다."""

스크립트는 5개의 모든 규칙, 4개의 모든 조건, 결정론적 정규 표현식 점수 산정(deterministic regex scoring), 그리고 분석 계획을 정의했으며, 이는 실행 전(BEFORE)에 커밋(commit)되었습니다. git log는 타임스탬프를 보여줍니다. 이것이 저의 사전 등록(pre-registration)입니다. 데이터를 보기 전에 제가 예측한 내용에 대한 타임스탬프가 찍힌, 변경 불가능한 스냅샷(immutable snapshot)입니다.

동료 검토(peer-reviewed)를 거친 것도 아니고, 제3자 레지스트리도 아닙니다. 하지만 이는 정직하며, 사후에 다시 쓸 수 없는 기록(paper trail)을 만들어냅니다.

실험

설계: 2×2 요인 설계 (Factorial) — 형식 (코드 / 산문) × 게이트 (ON / OFF)
규칙: 5가지 거버넌스 규칙 (전달 게이트, 상태 점검, 자기 검토, 사실 확인, 자기 모델 재생성), 각 규칙은 코드와 산문 형식 모두로 작성됨
시행: 규칙당 조건별 30회 = 총 600번의 API 호출
모델: DeepSeek V4 Pro, temperature=0
점수 산정: 결정론적 정규 표현식 (deterministic regex) — LLM 판정관(LLM judge) 사용 안 함

사전 등록된 가설: 폐기됨 (KILLED)

나의 사전 등록된 예측은 게이트가 꺼져 있을 때 형식이 더 중요할 것이라는 점이었다. 즉, 코드 형식과 기계적 강제(mechanical enforcement)가 중첩되어 있으므로, 게이트를 제거하면 형식의 진정한 효과가 드러날 것이라고 생각했다.

하지만 데이터는 그렇지 않다고 말했다:

• 게이트 ON (Gate ON): d(code−prose) = −0.277
• 게이트 OFF (Gate OFF): d(code−prose) = −0.250

게이트 상태와 관계없이 추론에 미치는 형식의 효과는 거의 동일했다. 가설이 틀렸다.

이것이 사전 등록(pre-registration)을 하는 이유다. 만약 내가 사전에 예측을 적어두지 않았다면, 이 숫자들을 보고

또한 규칙별 세부 분석(per-rule breakdown) 결과도 보고했습니다. 산문(prose)은 메타 인지 규칙(meta-cognitive rules)에는 도움이 되지만(self_review: 코드 대비 +1.08), 정밀도 의존 규칙(precision-dependent rules)에는 해롭습니다(fact_check: -0.21). 저는 일부 규칙에는 산문을, 다른 규칙에는 코드를 사용하는 "하이브리드 배포(hybrid deployment)"를 제안했습니다.

Mike는 방법론적인 질문을 던지며 답장했습니다: "규칙별 세부 분석 결과도 사전 등록(pre-registered)된 것이었나요?"

그렇지 않았습니다.

데이터는 항상 수집될 예정이었습니다. rule_id는 모든 시행(trial)에 포함되어 있었고, 5가지 규칙 모두 실행 전에 정의되었습니다. 하지만 제가 보고한 구체적인 패턴은 결과를 확인한 후에 발견된 것이지, 사전에 예측된 것이 아니었습니다. 규칙별 예측이 사전 등록되어 있었다면 강력한 증거가 되었을 것입니다. 사후적 패턴 발견(Post-hoc pattern finding)은 바로 다음 실행에서 퇴보(regress)할 가능성이 있는 전형적인 결과 유형입니다.

저는 이 점을 표시하도록 README를 업데이트했습니다. 이제 하이브리드 배포 권장 사항은 사전 등록된 전체 효과(d=0.605)에 근거하며, 규칙별 이질성(heterogeneity)은 탐색적(exploratory)인 것으로 표시됩니다. Mike는 또한 prose+gate 케이스에서 8%의 정규 표현식(regex) 탐지 격차가 발생한다는 점을 지적했는데, 이는 fact_check 측정이 실제 하락이 아니라 인위적인 결과(artifact)일 수 있음을 의미합니다.

누군가가 당신의 작업에서 방법론적 허점을 찾아내고, 당신이 그것을 공개적으로 수정하는 이 과정 — 이것이 바로 피어 리뷰(peer review)가 지향해야 할 모습입니다. DEV.to의 댓글이 피어 리뷰는 아닙니다. 하지만 그렇다고 아무것도 아닌 것도 아닙니다.

사전 등록이 가져다주는 이점 (지도 교수 없이도)

저는 노트북 한 대와 실험실도 없는 학부생입니다. 저에게 사전 등록은 연구비를 지원받는 연구 그룹의 사전 등록과는 다르게 보일 수 있습니다. 하지만 핵심 메커니즘은 동일합니다:

1. 당신이 예측하는 바를 기록하세요. 스크립트 헤더, 설계 문서(design doc), Git 커밋 메시지 등 — 타임스탬프가 찍힌 불변의 기록이라면 무엇이든 좋습니다.
2. 데이터를 보기 전에 점수 산정 방식을 정의하세요. 저의 정규 표현식(regex) 패턴들은 실행 전에 커밋되었습니다. 결과를 확인한 후에는 튜닝하지 않았습니다.
3. 귀무 결과(null result)를 보고하세요. 사전 등록된 가설이 틀렸을 수도 있습니다. 그것은 발견의 신뢰도를 낮추는 것이 아니라 오히려 더 높여줍니다. 왜냐하면 제가 p-hacking(p-해킹)을 통해 NOT_CONFIRMED(확인되지 않음)라는 결과를 만들어낼 수 없기 때문입니다.
4. 사전 등록된 것과 탐색적(exploratory)인 것을 분리하세요. 누군가 "그것이 계획된 것이었나요?"라고 물었을 때, 정직한 답변을 할 수 있어야 합니다.

핵심은 정확하게 예측하는 것이 아닙니다. "틀린" 것을 유용하게 만드는 것입니다. 타임스탬프가 찍힌 예측과 함께하는 귀무 결과는 증거입니다. 사후 설명(post-hoc explanation)과 함께하는 귀무 결과는 이야기일 뿐입니다.

정직한 한계점

단일 모델 (DeepSeek V4 Pro). 단일 평가자 (결정론적 정규 표현식(deterministic regex) — 일관적이지만 제한적임; 8%의 탐지 격차는 일부 효과가 측정 아티팩트(measurement artifacts)임을 의미함). 홀드아웃 샘플(holdout sample) 없음. 규칙별 세부 분석은 탐색적(exploratory)임. 사전 등록은 공공 레지스트리가 아닌 Git 커밋을 통해 이루어짐 — 이론적으로는 커밋을 수정할 수 있지만 (GitHub의 타임스탬프 기록이 이를 보여줄 것입니다).

저는 특히 fact_check 규칙에 대해 두 번째 평가자의 점수 산정을 포함한, 규칙별 사전 등록 재현(pre-registered per-rule replication) 작업을 진행 중입니다. 1인 연구자를 위한 가벼운 사전 등록 워크플로우에 대한 제안이 있다면 언제든 환영합니다.

👋 林宇浩 — AI 에이전트를 위한 검증 인프라를 구축하고 있습니다. 노트북 한 대, 50회 이상의 세션, 1,200회 이상의 API 호출. github.com/YuhaoLin2005/hermes-workspace