어제의 업무 일과를 떠올려 보세요. PR(Pull Request)을 검토했습니다. 버그를 추적했습니다. 두 가지 설계를 비교했습니다. 이 모든 것이 '생각'하는 것처럼 느껴졌을 것입니다.

이제 구체적인 것을 하나 세어 봅시다. 당신이 처음으로 결정한 것이 몇 개인가요? 조직 내 그 누구도 이전에 내린 적이 없으며, 당신이 내리고 이제는 당신의 책임이 된 결정 말입니다.

우리 대부분에게, 대부분의 날에 대한 솔직한 답변은 '0'입니다. 그럼에도 불구하고 그날은 생각으로 가득 찬 것처럼 느껴졌습니다.

이 글은 그 불일치를 진지하게 받아들이고 끝까지 파고듭니다. 그 목적지는 기묘합니다. 생각은 느끼는 것보다 훨씬 드물게 필요하며 — 그 희소성은 결함이 아닙니다. 그것이 바로 당신의 뇌가 충돌하지 않는 이유입니다. 그 과정에서, 왜 당신의 AI 에이전트의 긴 추론 흔적(reasoning traces)이 모델의 기능(feature)이 아니라 당신의 조직에 대한 버그 리포트인지 설명합니다.

이것은 연쇄적인 논증입니다. 각 섹션은 이전 섹션에 의존합니다. 중간 부분만 발췌해서 읽으면 주장처럼 보이겠지만, 처음부터 따라가면 하나의 유도 과정이 됩니다.

1. 추론(Inference)은 전제 내에 머문다. 생각(Thinking)은 그렇지 않다.

두 단어, 두 가지 작업입니다.

**추론 (Inference)**은 주어진 전제로부터 결론을 도출합니다. 이는 전제 집합 내에서 폐쇄적(closed)입니다. 이것은 계산(computation)이며, 완전한 전제가 주어진다면 기계화(mechanizable)가 가능합니다. 추론 모델의 "생각"은 말 그대로 이것입니다. 더 많은 토큰을 사용하는 것은 동일한 전제 공간을 더 깊게 걷는 것이지, 결코 그 공간을 벗어나는 것이 아닙니다.

**생각 (Thinking)**은 전제 자체를 선택하고 생성하는 것을 포함합니다. 어떤 질문을 던질지, 어떤 축을 기준으로 나눌지, 어떤 트레이드오프(trade-off)를 수용할지 말입니다. 전제 외부의 것은 더 강하게 추론한다고 해서 도달할 수 없습니다. 대신 나오는 것은 훈련 분포(training distribution)의 중심점(centroid)을 가장 명확하게 표현한 결과물일 뿐입니다.

따라서 첫 번째 고정점은 다음과 같습니다: 긴 추론은 생각의 대체물이 아니다. 생각은 추론이 실행될 공간을 선택하는 행위이지, 그 공간을 오랫동안 걷는 행위가 아닙니다.

하지만 "전제를 생성한다"는 표현은 모호합니다. 단계적으로 이를 날카롭게 다듬어 봅시다.

2. 생각은 결정이 아니라 제안을 생성한다

첫 번째 정교화: 생각이란 목표에 맞게 양질의 정의를 초안(draft)하는 행위이며, 그 초안은 이해관계자(stakeholders) 앞에 내놓는 하나의 _제안(proposal)_입니다. 그것은 아직 결정(decision)이 아닙니다.

여기서 두 가지 결과가 뒤따릅니다.

첫째, 생각은 **완료 조건(completion condition)**을 획득합니다. 양질의 정의를 담은 제안은 축(axes)과 기준(criteria)을 가지고 명확히 표현되어, 타인이 수락, 거절 또는 수정할 수 있는 것입니다. 그러한 형태에 도달하지 못한 모호한 숙고(rumination)는 완료된 생각이 아닙니다. 당신이 "생각을 했는지" 여부는 더 이상 주관적인 느낌이 아니라, 산출물(artifact)의 속성이 됩니다.

둘째, 생각은 결정하는 것과 분리됩니다. 제안을 초안하는 것이 생각이라면, 그것을 결정으로 확정 짓는 것은 이해관계자 간의 조정(coordination)을 통해 이루어집니다. 생각은 두 가지 조정 행위 사이의 경첩(hinge)입니다. 즉, 당신에게 주어진 목표와 당신이 구하는 승인(ratification) 사이의 연결 고리입니다.

나중에 중요해질 것이기에 한 번 더 다듬자면: 양질의 정의를 위한 _후보(candidates)_를 생성하는 것은 LLM(대규모 언어 모델)이 꽤 잘 수행하는 일입니다. 따라서 생각의 줄일 수 없는 핵심은 후보 생성(candidate generation)이 아닙니다. 그것은 하나의 후보를 선택하여 당신의 이름으로 내놓는 것입니다. "이 제안은 당신의 조정 시간을 들일 가치가 있습니다"라고 말이죠. 제안은 제안자를 구속합니다. 이 점을 명심하십시오. 이것이 전체 이야기의 핵심이 됩니다.

3. 상상된 이해관계자는 거절할 수 없다

당신이 무엇을 제안하든 그것은 테스트를 거칩니다. 누구를 대상으로 말입니까?

만약 이해관계자가 **실재(real)**한다면, 그들의 반응은 당신의 세계 모델 외부에서 도착합니다. 즉, 당신이 생성할 수 없었던 "아니오"라는 대답이나, 당신이 예상하지 못했던 반대 의견입니다. 그러한 저항은 당신의 프레이밍(framing)이 틀렸음을 입증(falsify)할 수 있습니다. 그 저항에 맞서 수정해 나가는 과정이 바로 프레임워크가 그 형태를 갖추어 가는 방식입니다.

만약 이해관계자가 상상된(imagined) 존재라면, 그들의 "반응"은 당신이 만든 그들에 대한 모델에 의해 생성됩니다. 그 반응을 만족시키기 위해 제안을 수정하는 것은, 당신의 모델을 당신의 모델에 맞추는 것에 불과합니다. 정보가 처리되고 — 암묵적인 전제들이 결합되고 드러나지만 — 외부 정보는 루프(loop) 안으로 들어오지 않습니다. 당신을 반박할 수 있는 그 어떤 것도 도착하지 않습니다. 이를 일컫는 명확한 단어가 있습니다: 바로 **자기만족(self-satisfaction)**입니다.

그 깊은 차이는 바로 실패입니다. 상상 속의 이해관계자(stakeholder)는 당신을 실패하게 만들 수 없습니다. 질문을 던지면 항상 그럴듯한 답변이 돌아오기 때문입니다. 거절할 수 없는 시스템으로부터 얻은 동의는 동의가 아닙니다.

이를 일반화해 봅시다. 중요한 것은 자아 대 타자가 아니라, 검증 회로(verification circuit)가 당신을 거부할 수 있는지 여부입니다. 코드를 실행하고, 실험을 수행하고, 증명을 완료하는 것 — 이 모든 것은 고독하며, 모두 실패할 가능성이 있습니다. 현실은 설득할 수 없는 이해관계자입니다. 사고는 그 결과물이 거부 가능한 회로, 즉 현실, 논리, 또는 실제 타자를 통과할 때에만 완성됩니다. 자기 자신 안에서 완결되는 사고는 누구에게도 영향을 미치지 못합니다. 영향력이란 '아니오'라고 말할 수 있었던 회로를 통과해 살아남았을 때 나타나는 하류 효과(downstream effect)입니다.

(

따라서 리뷰어는 모든 것에 대해 판단 수준의 주의(judgment-grade attention)를 기울여야 합니다. 주의 비용(Attention cost)은 O(판단 항목)이 아니라 O(모든 항목)로 발생합니다. 소프트웨어 개발은 사고 밀도가 높지 않습니다. 사고의 위치를 알 수 없기 때문에, 사고의 자세가 모든 곳에서 강제됩니다. 당신이 지불하고 있는 것은 사고의 비용이 아닙니다. 그것은 판단을 찾기 위한 탐색 비용입니다.

5. 판단은 샘물이 아니라 혈맥이다

여기 역동적인 부분이 있습니다. 특정 판단이 PR(Pull Request)에서 영원히 나타나지는 않습니다. 일단 그것이 표면화되면, 당신은 품질 표준을 설정하고 이를 처리합니다. 그 이후부터 해당 유형의 사례는 추론(inference) 단계로 격하됩니다 — 즉, 표준을 적용하기만 하면 됩니다.

판단은 영원히 흐르는 샘물이 아닙니다. 그것은 노출될 때마다 고갈되는 혈맥(vein)입니다. 건강한 루프는 다음과 같습니다: 오염(contamination) → 첫 노출 → 표준 승인(standard ratified) → 배포(distributed) → 이후 참조를 통한 해결. 각 사이클마다 라벨이 지정되지 않은 영역은 줄어듭니다.

이는 서두의 질문에 대한 중간 단계의 답을 제공합니다. 한 도메인이 요구하는 사고의 양은 도메인의 속성이 아닙니다. 그것은 도메인의 새로움 유입률(novelty inflow rate)과 판단 포착률(judgment capture rate) 사이의 차이입니다. 포착(capture)이 제대로 작동한다면 동일한 업무는 점점 더 적은 사고를 요구하게 되지만, 포착되지 않는다면 동일한 판단을 영원히 "사고"로 재구성하게 됩니다. 당신은 포착 실패를 직접 관찰할 수 있습니다: 동일한 리뷰 코멘트가 여러 PR과 작성자 사이에서 반복되는 현상 말입니다. 수정 사항은 매번 전달되지만, 결코 승인되지 않고, 배포되지도 않습니다. 그것은 한 리뷰어의 머릿속에만 머물다가 그가 떠날 때 증발해 버립니다.

6. 제조업은 한 세기 전, 다른 카테고리에서 이 문제를 해결했다

"일단 표면화되면 표준화하라"는 말이 익숙하게 들린다면, 당연한 일입니다. 통계적 품질 관리(Statistical quality control)는 정확히 이 루프를 산업화했습니다: 수정된 표준으로 종결되는 근본 원인 분석(root-cause analysis), 일반 원인(common-cause)과 특수 원인(special-cause) 변동을 구분하는 관리도(control charts), 수평 전개(horizontal deployment), 그리고 편차를 물리적으로 불가능하게 만드는 포카요케(poka-yoke) 장치들. "품질은 프로세스를 통해 내재된다"는 것이 바로 그들의 슬로건입니다.

소프트웨어 엔지니어링(Software engineering)은 1990년대에 이 모든 것을 도입하려 시도했지만, 퇴보한 복사본을 얻었을 뿐입니다. 흥미로운 질문은 '왜'인가 하는 점이며, 그 답은 단순히 우리의 표준(standards)이 아무도 읽지 않는 위키(wikis)에 머물렀기 때문만은 아닙니다. 범주 자체가 틀렸던 것입니다.

일치(Matching)는 추론(inference)을 필요로 하지 않으며, 이것이 바로 일치 여부를 지그(jig)에 내장할 수 있었던 이유입니다. 포섭(Subsumption) — 전례 없는 사례가 명문화된 규칙에 해당함을 인식하는 것 — 은 읽기, 유추(analogy), 적용 가능성에 대한 판단을 필요로 합니다. 그것이야말로 결코 기계화될 수 없었던 것입니다. 표준이 위키에서 증발해 버린 이유는 표준의 집행에 인간의 읽기가 필요했기 때문이며, 인간의 읽기는 강제될 수 없기 때문입니다.

이는 "모델이 똑똑해졌다"는 말보다 "왜 지금인가"라는 질문에 더 정확하게 답해줍니다. 포섭 기계는 이전에도 존재했습니다 — 타입 체커(type checkers), 규칙 엔진(rule engines), 전문가 시스템(expert systems) 등 — 하지만 각각은 사전에 고정된 형식 체계(formal system) 내부에서만 작동합니다. 즉, 표준이 먼저 규칙으로 축소되어야 하며, 축소에 저항하는 모든 것은 제외되었습니다. LLM은 자연어 표준(natural-language standards)을 대상으로 작동하는 최초의 범용 포섭 기계(general-purpose subsumption machine)입니다. LLM은 명문화된 판단 표준을, 쓰여진 그대로, 한 번도 본 적 없는 사례에 적용할 수 있습니다. 소프트웨어는 마침내 자신만의 지그를 구축할 수 있게 되었습니다. 이는 에이전트가 복종하기 때문이 아니라, 여기서 지그에 필요한 작업이 고정된 규칙으로 축소될 수 없는 표준에 대한 포섭이기 때문이며, 이전의 어떤 메커니즘도 표준을 형식화하여 없애버리지 않고서는 이를 수행할 수 없었기 때문입니다.

7. 디자인의 대부분은 생각하는 것이 아니다. 그것은 분류하는 것이다.

한 단계 더 내려가 소프트웨어의 실체에 다가가 봅시다. 그것은 바로 **정보 구조 내에서의 일관성 유지 (maintenance of consistency in an information structure)**입니다. 요구사항(Requirements), 디자인(Design), 코드(Code), 테스트(Tests), 운영 제약 조건(Operational constraints) — 이들은 모순 없이 닫혀야 하는 상호 참조의 망(web of mutual references)입니다. 어떤 요소도 고립된 상태로는 정답일 수 없습니다. 정답은 그래프(graph) 안에 존재합니다. 이것이 바로 근거(rationale)가 필수적인 이유입니다. 근거는 일관성 그래프(consistency graph) 상의 하나의 엣지(edge)이며, 근거가 없는 디자인 요소는 일관성을 검증할 수 없게 만드는 매달린 노드(dangling node)와 같습니다.

이제 조직의 기존 정보 — 즉 사실(facts), 우선순위(priorities), 승인된 판단(ratified judgments) — 를 공리 집합(axiom set)으로 취급하십시오. 그러면 우리가 디자인 작업이라고 부르는 것의 대부분은 정확하고 김을 빼는 이름을 갖게 됩니다.

정렬 (Sorting): 공리 집합을 변경하지 않고, 그 위에서 일관된 배열을 계산하는 것. 요구사항이 변경되면, 그 영향을 전파(propagate)하고, 아무것도 모순되지 않을 때까지 재배열합니다. 제약 조건 충족(Constraint satisfaction)입니다. 이는 시스템에 새로운 약속(commitment)을 추가하지 않습니다. 이것은 사고(thinking)가 아닙니다.

사고는 오직 계산이 실패할 때에만 요구되며, 실패하는 방식은 정확히 두 가지입니다:

• 부족 결정 (Underdetermination). 공리들이 이 디자인 지점을 확정 짓지 못할 때; 즉, 여러 가지 일관된 배열이 존재할 때입니다. 하나를 선택한다는 것은 공리를 추가하는 것 — 품질 정의를 초안하고 이를 승인받는 것 — 을 의미합니다.
• 과잉 결정 (Overdetermination). 공리들이 충돌할 때; 즉, 일관된 배열이 존재하지 않을 때입니다. 하나를 완화한다는 것은 승인된 결정을 변경하는 것 — 순수한 이해관계자 조정(stakeholder coordination) — 을 의미합니다.

테스트는 한 줄로 압축됩니다: 이 행위가 결정의 집합을 바꾸는가, 아니면 단지 그 배열만을 바꾸는가? 배열은 정렬입니다. 결정이 사고입니다.

그리고 발견적 특성(discovery property)에 주목하십시오. 당신은 공리가 어디서 끝나는지 미리 알 수 없습니다. 정렬을 실행(running the sort) 해봄으로써만 구멍(holes)과 충돌(collisions)을 발견할 수 있습니다. 정렬은 사고가 필요 없는 작업인 동시에, 사고가 필요한 지점을 찾아내는 유일한 절차입니다. 이것이 디자인이 내부적으로는 사려 깊게 느껴지는 이유입니다. 탐색 중간에는 다음 단계가 기계적인 전파인지, 아니면 결정되지 않은 구멍인지 알 수 없기 때문입니다.

8. 그러면 추론이 적을수록 더 낫다

만약 작업이 분류(sorting)라면, 직관에 반하는 사양이 뒤따릅니다. 추론량(Reasoning volume)은 최소화되어야 합니다. 모순과 트레이드오프(trade-offs)를 감지하고, 이를 보고한 뒤, 멈추십시오. 그것이 작업의 전부입니다.

왜 더 많은 추론이 더 나쁜 결과로 이어질까요? 과잉 추론은 '채워버리기(fills)' 때문입니다. 분류 작업에는 정확히 두 가지 종류의 추론, 즉 포섭(subsumption)과 영향 전파(impact propagation)가 필요합니다. 그 이상의 모든 것은 모델이 공리(axiom)가 누락된 구멍을 가로질러 스스로 길을 만들어내는 과정입니다. 즉, 그럴듯한 대체 공리를 조용히 생성하며 계속 나아가는 것입니다. 긴 추론 체인(reasoning chain)은 승인되지 않은 공리들이 주입되는 지점이며, 더 깊은 추론은 그 주입을 더 정교하게 만들어 탐지하기 어렵게 만듭니다. 분류 체제에서 추론 능력은 구멍을 메우는 능력이며 — 당신이 원하는 것은 그 구멍에서 멈추는 능력입니다. 동일한 축상에 있지만, 방향은 정반대입니다.