지난 글에서 저는 명세(specification)에는 컴파일러가 필요하다고 말했습니다. 즉, 입력이 잘못되었을 때 _실패(fails)_하는 관문이 필요하다는 뜻입니다. 이는 직접 구축하려고 하면 매우 깔끔하게 들리지 않는데, 왜냐하면 즉시 "잘못되었다"라는 단어가 숨기고 있던 질문에 직면하게 되기 때문입니다: "어떻게 잘못되었는가?"

검증(Verification)은 단 하나의 개념이 아닙니다. 명세(spec), 계획, 또는 생성된 코드 뭉치를 확인할 때, 여러분은 실제로는 비슷해 보이지만 서로 다른 최대 세 가지 질문을 던지고 있는 것입니다. 이들을 혼동하는 것은 제가 보는 제품용 AI(AI-for-products) 도구들에서 가장 흔히 발생하는 실수이며, 여기에는 다른 면에서 매우 훌륭한 도구들도 포함됩니다. 따라서 어떤 관문(gate)을 만들기 전에, 렌즈(lens)가 필요합니다. 여기에는 세 가지 축이 있으며, 이들은 서로 직교(orthogonal)합니다.

진실(Truth), 일관성(Coherence), 의도(Intent)

**진실 (Truth)**은 현실에 기반한 근거(groundedness)입니다. 이 주장이 실제로 그러한가? "API는 이 필드를 반환한다." "이 테이블에는 status 컬럼이 있다." "소비자는 추가 파라미터를 허용할 수 있다." 각각은 문서와 독립적으로 존재하는 세계, 즉 코드베이스(codebase), 실행 중인 시스템, 데이터에 비추어 참 또는 거짓이 됩니다. 여러분은 직접 가서 확인함으로써 진실을 체크합니다: 소스를 grep 하거나, 엔드포인트(endpoint)를 호출하거나, 쿼리(query)를 실행하는 식입니다. 진실은 외부 참조 대상(external referent)을 가지며, 바로 그 점 때문에 세 가지 중 가장 기계화(mechanizable)하기 쉽습니다.

**일관성 (Coherence)**은 내부적 일관성입니다. 문서가 스스로 모순되지는 않는가? 공백이 있는가? 어떤 입력에 대해서는 동작이 명시되어 있지만 다른 입력에 대해서는 침묵하고 있는가? 동일한 용어가 두 가지 방식으로 사용되고 있는가? 일관성은 문서 외부의 세계를 필요로 하지 않습니다. 문서를 그 자체와 대조하여 읽음으로써 확인할 수 있습니다. 이것은 대부분의 명세(spec) 도구들이 실제로 도달한 축입니다. Kiro가 모호한 문장이나 동시에 성립할 수 없는 두 가지 요구사항을 찾아내거나, Spec Kit의 체크리스트가 모든 케이스가 커버되었는지 묻는다면, 그것이 바로 일관성 오라클(coherence oracle)입니다. 이는 진정으로 유용하며, 그 가치를 과소평가하고 싶지 않습니다.

**의도 (Intent)**는 실제로 원했던 것과의 일치 여부입니다. "이것이 일관적인가"도 아니고 "이것이 사실인가"도 아닌, "이것이 올바른 것인가"에 대한 문제입니다. 명세서(spec)는 결점 없이 일관적(coherent)이고 현실에 완벽하게 근거(grounded)하고 있더라도, 아무도 필요로 하지 않는 기능이나 잘못된 기능을 설명할 수 있습니다. 혹은 올바른 기능일지라도, 요청한 사람만이 잘못되었다고 인식할 수 있는 미묘하게 잘못된 기본값(default)을 가질 수도 있습니다. 의도는 인간의 머릿속에 존재합니다. 그것은 grep으로 찾아낼 수 있는 외부 참조 대상이 없으며, 문서가 통과할 수 있는 내부 테스트도 존재하지 않습니다.

이 세 가지를 모두 명명하는 이유는 그것들이 서로 분리될 수 있기 때문입니다. 그것이 바로 이 렌즈(lens)가 가진 효용의 전부입니다.

그것들은 분리되며, 그것이 핵심입니다

명세서는 **일관적이지만 거짓(coherent and false)**일 수 있습니다. 모든 요구사항이 서로 일관성을 유지하며 아름답게 결합되어 있지만, 시스템에 대한 주장이 사실이 아닌 경우입니다. 내부의 그 어떤 것도 이를 잡아낼 수 없습니다. 문서는 스스로와 평화로운 상태입니다. 오직 문서 외부로 손을 뻗는 진위 확인(truth check)만이 이를 잡아낼 수 있습니다.

A 명세서는 **사실이지만 비일관적(true and incoherent)**일 수 있습니다. 개별적인 모든 주장은 코드베이스(codebase)와 대조했을 때 문제가 없지만, 두 요구사항이 조용히 서로 모순되거나 입력 공간(input space)의 절반이 명시되지 않은 경우입니다. 근거 확인(grounding)은 주장 하나하나마다 통과하지만, 연결 부위(seams)에서 일관성(coherence)이 실패합니다.

그리고 명세서는 사실이고, 일관적이며, 잘못될(true, coherent, and wrong) 수 있습니다. 이것이 가장 어려운 사례입니다. 아무것도 거짓을 말하지 않고, 아무것도 모순되지 않지만, 원했던 것과는 다른 무언가를 설명하는 경우입니다. 기계적인 오라클(mechanical oracle)은 이를 잡아낼 수 없습니다. 왜냐냐, 그것을 대조하여 확인할 기계적인 대상이 존재하지 않기 때문입니다.

이 축들이 철학적 구분이 아니라 분리 가능하다는 깔끔한 실제 증거가 여기 있습니다: 업계가 멈춘 지점을 보세요. 스펙 레이어(Spec Layer)까지 올라간 모든 사람들(Kiro, Spec Kit 등)은 일관성 오라클(coherence oracle)을 구축하고 깃발을 꽂았습니다. 그들은 당신의 스펙이 스스로 모순된다고 말해줄 수 있습니다. 하지만 그들 중 어느 누구도 당신의 스펙이 API에 대해 _거짓말을 하고 있다_고는 말할 수 없습니다. 왜냐하면 그것은 완전히 다른 축이며, 다른 기계 장치(machinery)가 필요하기 때문입니다: 문서 밖으로 나가서 찾아봐야 하는 무언가입니다. 일관성 게이트(coherence gate)와 진실 게이트(truth gate)는 강도가 다른 같은 게이트가 아닙니다. 그것들은 서로 다른 게이트입니다. 시장이 우연히 실험을 진행했고, 이 렌즈를 확인해 주었습니다.

진실 없이 일관성만 있는 예시

제가 가진 것 중 가장 깔끔한 설명이고 지난주에 저에게 일어났던 것이기 때문에 이 시리즈 제작 과정에서 얻은 것을 하나 알려드리겠습니다.

저는 누군가 이미 Truth/Coherence/Intent 스타일의 분류 체계(taxonomy)를 출판했는지 조사하고 있었습니다. 제 에이전트 중 하나가 완벽한 자료를 가져왔습니다: 2026년 논문이었는데, 그 논문은 정확히 그러한 선을 따라 검증 오라클(verification oracle)을 분리했으며 _의도 일치(intent-matching)는 근본적으로 기계화할 수 없다_고 선언하고 인용구까지 첨부했습니다. 주제에 맞았고, 문장 구성도 좋았으며, 제 논지에 너무 딱 맞아떨어져서 거의 사용하려 했습니다.

하지만 그것은 조작된 것이었습니다. 실제로 PDF를 다시 확인하는 두 번째 과정에서

그 하나의 일화가 바로 이 렌즈(lens)에 대한 논거의 전부입니다. 위험한 오류는 일관성이 없는 오류가 아닙니다. 그런 것들은 틀려 보이기 때문입니다. 위험한 오류는 일관성이 있지만 거짓인 오류입니다. 왜냐하면 그것들은 옳아 보이기 때문이며, 오직 _문서(document)_가 아닌 _세상(world)_을 가리키는 오라클(oracle)만이 이를 막을 수 있기 때문입니다.

강도 구배(strength gradient) — 그리고 기계화할 수 없는 축

세 가지 축은 단순히 종류만 다른 것이 아닙니다. 그것들은 얼마나 기계화(mechanizable)될 수 있는지에 따라 다르며, 그 순서가 여러분이 어디에 노력을 기울여야 하는지를 결정해야 합니다.

진실(Truth)은 가장 기계화하기 쉽습니다. 진실은 외부 참조 대상(external referent)을 가지고 있으므로, grep, 컴파일(compile), 실행(execute), 쿼리(query)와 같이 검증을 자동화할 수 있습니다. 이곳에 가장 어렵고 자동화된 게이트를 구축하십시오. 이것이 스펙 컴파일러(spec compiler)가 제 역할을 하는 지점이며, 시장의 관점에서 볼 때 가장 적게 구축된 영역이기도 합니다.

일관성(Coherence)은 부분적으로 기계화가 가능합니다. 일관성 및 완전성 검사(consistency and completeness checks)는 상당한 수준까지 자동화될 수 있으며, LLM은 모순을 찾아내는 데 꽤 능숙합니다. 수확 체감의 법칙이 적용되지만 다룰 수 있는 영역입니다. 이 분야는 이미 이 단계에 와 있습니다.

의도(Intent)는 기계적으로 오라클화할 수 없으며, 그렇지 않은 척하는 것이 바로 함정입니다. 의도는 외부 참조 대상도 없고 내부 테스트도 없습니다. 그 정답(ground truth)은 종종 그것을 가진 사람에게조차 명확히 규정되지 않은 마음의 상태이며, 결과물을 보았을 때 변하기도 합니다. 여러분은 그것을 _근사(approximate)_할 수는 있습니다. 수락 테스트(acceptance tests)는 그것의 일부를 인코딩하고, 예시(examples)는 그것의 구석진 부분들을 고정하며, 축적된 인간의 판결(이후에 다룰 내용: 판례)은 약하고 표류하는 대리 지표(proxy)를 제공합니다. 하지만 근사는 한계치입니다. 정직한 엔지니어링 방식은 자신감 넘치는 LLM 판사로 의도(Intent) 오라클을 흉내 내는 것이 아닙니다. 의도를 인간이 필요한 축으로 _명명(name)_하고, 인간을 정확히 그 자리에 배치하며, 인간의 희소한 주의력이 기계가 답할 수 없는 질문에만 쓰일 수 있도록 진실(Truth)과 일관성(Coherence)을 충분히 강력하게 기계화하는 것입니다.

그것이 바로 이 렌즈(lens)를 통해 얻을 수 있는 것입니다. 새로운 게이트(gate)를 만드는 것이 아니라, 당신이 구축하는 모든 게이트가 세 가지 질문 중 실제로 어떤 질문에 답하는지를 알 수 있는 방법입니다. 이를 통해 일관성 검사(coherence check)가 진실의 형태를 띤 빈 공간(truth-shaped hole)을 지키게 두거나, 기계가 항상 당신의 영역이었던 단 하나의 게이트를 보유하고 있는 척하게 만드는 일을 다시는 반복하지 않게 됩니다.

시리즈 후속 내용: 진실 게이트(truth gate) 그 자체 — 현실에 대한 명세(specification)의 근거 설정(grounding), 그리고 흥미로운 실패들이 거짓(lies)이 아닌 계층(layers)에 관한 이유.