요약(TL;DR): 이 글은 소프트웨어 장 이론(Software Field Theory, SFT)의 ForecastCone에서 시작하여 모듈성(modularity), 기술 부채(technical debt), 리뷰(review), 거버넌스(governance), 그리고 학습(learning)을 하나의 연구 프로그램의 일부로 읽어냅니다. 목표는 간단합니다. 어떤 변화가 어떤 미래를 열어주는지 확인하고, 위험한 미래를 조기에 차단하며, 좋은 미래에 더 쉽게 도달할 수 있도록 개발 환경을 형성하는 것입니다. 만약 이 정리 형태의 프로그램이 작동한다면, 아키텍처(architecture), 기술 부채, 리뷰, 거버넌스, 그리고 AI 코딩 안전성(AI coding safety)은 모두 ForecastCone이라는 동일한 객체를 중심으로 다시 읽힐 수 있습니다. 또한 우리는 ForecastCone 및 ConsequenceEnvelope와 같은 개념들을 작은 레코드(records)와 정리 패키지(theorem packages)로 분해함으로써 Lean을 통해 이 방향을 공식화하고 있습니다. 더 큰 AAT / SFT 그림을 위해, 저는 여기서 더 넓은 AAT / SFT 프레임워크를 소개했습니다: 소프트웨어 필드로서의 소프트웨어 아키텍처: 소프트웨어 진화에 대해 더 나은 질문 던지기, 대수적 아키텍처 이론(Algebraic Architecture Theory), 소프트웨어 장 이론(Software Field Theory). 문제: 빠른 코드가 곧 건강한 진화는 아니다. AI 에이전트에게 코드베이스(codebase) 그 자체는 가장 큰 프롬프트(prompt)입니다. 만약 기존 코드에 많은 지름길(shortcuts)이 포함되어 있다면, 에이전트는 그러한 패턴을 쉽게 학습할 수 있습니다. 만약 경계(boundaries)가 모호하다면, 에이전트는 자연스럽게 그 모호한 위치에 다음 변경 사항을 추가할 것입니다. 좋은 구조는 좋은 변화를 끌어들입니다. 나쁜 구조는 나쁜 지름길이 자연스러워 보이도록 반복적으로 만듭니다. 제품 요구 사항 문서(PRDs), 이슈(issues), 리뷰 정책, 그리고 CI 규칙은 단지 "이 변경 사항"만을 결정하는 것이 아닙니다. 그것들은 다음 PR이 어떤 모습이 될지, 어떤 모듈을 건드리는 것이 자연스럽게 느껴질지, 어떤 경계를 놓치기 쉬울지, 그리고 어떤 지름길이 통과될 가능성이 높은지를 형성합니다. 예를 들어, 바이브 코딩(vibe coding)에서 AI 에이전트는 명세가 불충분한 PRD로부터 그럴듯한 구현을 빠르게 만들어낼 수 있습니다. 단지 "쿠폰을 사용할 수 있게 만드세요"라고만 적힌 PRD는 결제 흐름(checkout flow) 내부의 작은 if 문으로 변할 수 있습니다. 첫 번째 데모는 작동합니다. 하지만 그 변경 사항이 가격 정책, 환불, 사용 제한, 감사 로그(audit logs)를 모호한 경계로 남겨둔다면, 다음 PR은 종종 동일한 지름길을 기반으로 구축될 것입니다. 문제는 AI가 나쁜 코드를 작성한다는 것이 아닙니다.

문제는 모호한 산출물(artifacts)과 빠른 생성 속도가 결합될 경우, 나쁜 미래의 경로를 매우 빠르게 열어젖힐 수 있다는 점입니다. 잘못된 필드는 AI에 의해 더 큰 기술 부채 (technical debt)로 증폭될 수 있습니다. 전통적인 리뷰 (review), CI, 그리고 지표 (metrics)는 종종 현재의 차이 (diff)나 이미 발생한 결과만을 살펴봅니다. AI 시대에는 그것만으로는 충분하지 않습니다. 이제 질문은 더 이상 "이 PR이 지금 당장 통과하는가?"에 그치지 않습니다. 더 깊은 질문은 다음과 같습니다: "이 PRD, 이 에이전트 (agent), 이 코드베이스 (codebase), 그리고 이 리뷰 규칙이 다음에 어떤 미래를 여는가?" SFT가 이 질문을 던지기 위해서는 ForecastCone이 필요합니다. 이는 소프트웨어 진화 (software evolution)를 단순한 변경 사항의 연속이 아니라, 도달 가능한 미래의 공간으로서 계산 가능하게(computable) 만드는 객체를 제공합니다.

거대 정리 (The Grand Theorem): 소프트웨어 진화의 근본 정리 (A Fundamental Theorem of Software Evolution)

• 모듈성 (Modularity) = ForecastCone 하강 (descent)
• 기술 부채 (Technical debt) = 하강 장애 (descent obstruction)
• 리뷰 (Review) = 최소 결정 보존 포락선 (minimal decision-preserving envelope)
• 거버넌스 (Governance) = 원하는 원뿔 보존 장애물 절단 (desired-cone-preserving obstruction cutting)
• 학습 (Learning) = 폐쇄 루프 경계 명시적 고정점 (closed-loop boundary-explicit fixed point)

이 글에서 저는 이 정리 형태의 그림을 소프트웨어 진화의 근본 정리 (Fundamental Theorem of Software Evolution)라고 부를 것입니다. 일상적인 엔지니어링 언어로 표현하자면 다음과 같습니다: 좋은 아키텍처 경계 (architecture boundary)는 팀과 AI 에이전트가 별도로 작업한 뒤, 나중에 그들의 변경 사항을 안전하게 결합할 수 있게 해줍니다. 기술 부채 (technical debt)란 통합이 왜 계속 같은 지점에서 깨지는지를 구체적인 원인과 함께 설명할 수 있는 능력입니다. 리뷰 (review)에서 우리는 모든 diff 라인이나 가능한 모든 미래를 원하는 것이 아닙니다. 우리는 결정에 중요한, 위험한 미래를 원합니다. 거버넌스 (governance)는 단순히 개발을 막는 규칙을 추가하는 것이 아니어야 합니다. 그것은 나쁜 지름길을 차단하고, 좋은 구현 경로를 선택하기 더 쉽게 만들어야 합니다. 학습 (learning)이란 실제 PR, 장애 (incidents), 그리고 리뷰 결과를 사용하여 다음 예측과 다음 규칙을 업데이트하는 것을 의미합니다.

더 수학적인 언어로 표현하자면: 좋은 아키텍처 경계는 단순히 정적인 의존성 절단 (dependency cut)이 아닙니다. 그것은 미래의 진화 경로를 국소적으로 계산할 수 있고, 호환성 조건 하에 전역적인 미래로 접착(glue)될 수 있는 경계입니다.

기술 부채 (Technical debt)는 그러한 접착 (gluing)이 실패할 때 나타나는 장애물입니다. 리뷰 (Review)는 ForecastCone 전체를 보는 행위가 아닙니다. 그것은 의사결정에 필요한 구분을 보존하는 포락선 (envelope)을 보는 행위입니다. 거버넌스 (Governance)는 원하는 미래를 보존하면서 나쁜 미래를 제거하는 지원적 변환 (support transformation)입니다. 학습 (Learning)은 PR (Pull Request), 인시던트 (incidents), 리뷰 (reviews), 그리고 운영 결과 (operational outcomes)를 사용하여 필드 추정치 (field estimate)를 경계가 명시된 고정점 (boundary-explicit fixed point)으로 이동시키는 폐쇄 루프 업데이트 (closed-loop update)입니다. 만약 이러한 정리가 증명될 수 있다면, 우리가 소프트웨어 진화에 대해 추론하는 방식이 바뀔 것입니다. 아키텍처가 좋은지, 기술 부채가 어디에 위치하는지, 리뷰어가 무엇을 보아야 하는지, 어떤 거버넌스 규칙이 효과적인지, 그리고 다음번에 필드 모델 (field model)을 어떻게 업데이트해야 하는지를 동일한 계산 가능한 객체 (computational object)를 통해 연구할 수 있습니다. 그 객체가 바로 ForecastCone입니다.

ForecastCone: 도달 가능한 미래의 범위

SFT는 개발 환경을 하나의 필드 (field)로 읽습니다.
codebase + artifacts + practices + agents + governance + feedback -> 도달 가능한 소프트웨어 미래 (reachable software futures)

해당 필드 하에서 도달 가능한 미래의 범위가 바로 SFT가 ForecastCone이라고 부르는 것입니다. ForecastCone은 예언이 아닙니다. SFT는 "이 PRD (Product Requirements Document)는 반드시 이 PR을 생성할 것이다"라고 말하지 않습니다. 대신 다음과 같이 질문합니다: "이 필드 모델, 운영 지원, 정책, 관측 경계 (observation boundary), 그리고 지평 (horizon) 하에서, 어떤 미래 경로들이 도달 가능한가?"

한 이커머스 서비스가 "한정 시간 쿠폰 추가"라는 PRD를 받았다고 가정해 봅시다. 그 PRD는 단 하나의 미래만을 여는 것이 아닙니다. 어떤 미래는 결제 흐름 (checkout flow)에 작은 분기를 추가합니다. 어떤 미래는 가격 책정 서비스 (pricing service)에 할인 정책을 추가합니다. 어떤 미래는 독립적인 쿠폰 도메인 (coupon domain)을 도입합니다. 어떤 미래는 캠페인 규칙 (campaign rules)과 감사 로그 (audit logs)로 확장됩니다. 어떤 미래는 일단 데이터베이스 컬럼을 추가하고 정리는 나중으로 미룹니다. 이 모든 것들은 어떤 의미에서 "쿠폰 지원"입니다. 하지만 이들은 매우 다른 다음 미래들을 엽니다. ForecastCone은 우리가 그 차이를 바라볼 수 있게 해주는 객체입니다.

동일한 제품 요구 사항 문서 (PRD)라 할지라도 현재의 코드베이스 (codebase), 모듈 경계 (module boundaries), 과거의 임시방편 (workarounds), 리뷰 규칙 (review rules), 지속적 통합 (CI), 그리고 AI 에이전트의 동작 방식에 따라 도달하기 쉬운 미래가 될 수도, 어려운 미래가 될 수도 있습니다.

모듈성 = ForecastCone 하강 (Modularity = ForecastCone Descent)
모듈성 = ForecastCone 하강 (Modularity = ForecastCone descent)
직관적인 개념은 다음과 같습니다: 소프트웨어 시스템의 전역적 미래 (global future)는 호환 가능한 지역적 미래 (local futures)들을 결합함으로써 계산될 수 있습니다. 전통적인 모듈성 (modularity)은 종종 API, 의존성 방향 (dependency direction), 그리고 책임 분리 (responsibility separation)의 관점에서 설명됩니다. SOLID, 계층형 아키텍처 (Layered Architecture), 클린 아키텍처 (Clean Architecture), 그리고 디자인 패턴 (Design Patterns)은 인간이 책임을 이해하고, 변경 사항을 국소화하며

Review = Minimal Decision-Preserving Envelope

Review = 최소한의 의사결정 보존 엔벨로프 (Minimal Decision-Preserving Envelope)

ForecastCone은 거대할 수 있습니다. 리뷰어는 모든 미래의 경로를 살펴볼 수 없습니다. 하지만 diff(차이점)만으로는 종종 너무 작습니다. 만약 AI 에이전트가 다음과 같은 PR (Pull Request)을 생성한다고 가정해 봅시다:

if coupon_code.present? total = total - discount end

diff는 작습니다. 하지만 리뷰어는 단지 이 세 줄에만 관심을 두는 것이 아닙니다. 이것이 환불 경로에 관찰되지 않은 분기(branch)를 추가하게 될까요? 사용 제한이 재시도 동작 (retry behavior)과 충돌할까요? Pricing과 Checkout 사이의 세금 경계 (tax boundary)가 여전히 정의되지 않은 상태인가요?

우리에게 필요한 것은 ForecastCone 전체가 아니라, 리뷰 결정을 내리는 데 필요한 부분입니다. SFT는 이를 ConsequenceEnvelope (결과 엔벨로프)라고 부릅니다. 리뷰 도구의 목표는 모든 것을 보여주는 것이 아닙니다. 결정에 필요한, 미래와 관련된 차이점만을 더도 말고 덜도 말고 보여주는 것입니다.

Governance = Desired-Cone-Preserving Obstruction Cutting

Governance = 원하는 콘을 보존하는 장애물 차단 (Desired-Cone-Preserving Obstruction Cutting)

위험한 미래가 나타날 때, 가장 단순한 대응은 또 다른 규칙을 추가하는 것입니다. '쿠폰과 관련된 모든 사항은 시니어 엔지니어가 리뷰해야 한다'와 같은 규칙 말입니다. 그것은 가드레일 (guardrail)입니다. 하지만 이는 종종 무겁고, 실제로 어떤 미래를 차단하고 있는지 명시하지 못할 수도 있습니다.

SFT가 원하는 종류의 거버넌스 (Governance)는 더 구체적입니다: 원하는 미래는 보존하면서 나쁜 미래를 차단하는 것입니다.

Pricing / Checkout 경계 전반에 걸쳐 별도의 DiscountedTotal 및 FinalCharge 타입을 도입하십시오. 쿠폰 사용 업데이트를 멱등 (idempotent)하게 만드십시오. 환불 경로를 건드릴 때는 쿠폰 불변식 (invariant) 체크를 요구하십시오. AI 에이전트가 Checkout 하위의 임시적인 (ad hoc) 할인 분기로 향하지 않고 정책 객체 (policy objects)를 향하도록 유도하십시오.

우리는 할인 로직이 Checkout 전반에 퍼지는 미래를 차단하고 싶습니다. 동시에 쿠폰 정책이 독립적으로 진화할 수 있는 미래는 여전히 보존하고 싶습니다. 그 차이가 바로 거버넌스 합성 정리 (Governance Synthesis Theorem)가 다루는 핵심입니다. 이것은 단순히 가드레일을 추가하는 것에 관한 것이 아닙니다. 그것은 지형을 형성하는 (shaping the field) 것에 관한 것입니다.

Learning = Closed-Loop Boundary-Explicit Fixed Point Learning = 폐쇄 루프 경계 명시적 고정점 학습 (closed-loop boundary-explicit fixed point SFT)은 단 하나의 ForecastCone을 계산하고 멈추는 이론이 아닙니다. 예측된 미래 경로들은 실제 PR (Pull Requests), 인시던트 (incidents), 리뷰 코멘트 (review comments), CI 실패, 그리고 런타임 관측값 (runtime observations)과 비교됩니다. 예측이 틀렸을 때, 그것은 단순한 실패가 아닙니다. 그것은 모델을 업데이트하기 위한 증거가 됩니다. 필드 추정치 (field estimate)가 너무 거칠었는가? 관측 경계 (observation boundary)가 너무 좁았는가? 정책 모델 (policy model)이 실제 리뷰 동작을 표현하는 데 실패했는가? 알려지지 않은 나머지 (unknown remainder)를 명시적으로 만들어야 했는가? 이 폐쇄 루프 (closed loop)가 진행됨에 따라, SFT 워크벤치 (workbench)는 단순한 분석기 그 이상이 됩니다. 그것은 소프트웨어 진화의 필드 모델 (field model)을 지속적으로 보정하는 시스템이 됩니다.

Attractor Engineering 및 ArchSig
이 거대 정리 (grand theorem)는 AAT 및 ArchSig와 연결될 때에만 실용적이 됩니다. AAT는 변경 사항이 무엇을 보존하고 무엇을 깨뜨리는지를 읽기 위한 국소 이론 (local theory)을 제공합니다. ArchSig는 리포지토리 (repositories), PR, 리뷰, CI, 그리고 인시던트로부터 보존과 파괴를 관찰하기 위한 시그니처 레이어 (signature layer)를 제공합니다. SFT는 이러한 관측값들을 사용하여 도달 가능한 미래 (reachable futures)를 계산하고, 이를 거버넌스 (governance) 및 학습과 연결합니다.

AAT -> 국소 법칙 (local laws) / 불변량 (invariants) / 방해 증거 (obstruction witnesses)
ArchSig -> 관측된 시그니처 (observed signatures) / 측정된 축 (measured axes) / 증거 경계 (evidence boundaries)
SFT -> ForecastCone / ConsequenceEnvelope / 거버넌스 업데이트 (governance update)

Attractor Engineering 또한 여기에 부합합니다. 좋은 아키텍처는 좋은 변경을 끌어당깁니다 (attracts). 나쁜 아키텍처는 동일한 지름길 (shortcut)이 자연스러워 보이도록 반복적으로 만듭니다. SFT의 언어로 말하자면, 이는 도달 가능한 미래의 형태가 변한다는 것을 의미합니다. 거버넌스 개입 (governance interventions)은 나쁜 미래 경로를 차단하고, 타입 경계 (type boundaries)는 좋은 국소 진화 (local evolution)를 더 자연스럽게 만들며, 리뷰 규칙 (review rules)은 위험한 경로를 관찰 가능하게 만듭니다. Attractor Engineering은 ForecastCone을 형성하는 실천입니다. ArchSig는 그러한 변화를 관찰하기 위한 도구입니다. SFT는 이러한 관측값들을 다시 정리 (theorem) 제품군으로 연결합니다.

미래 개발 워크플로우의 스케치 (A Sketch of a Future Development Workflow)

SFT는 개발자를 대신하여 미래를 결정하는 시스템을 구축하려는 것이 아닙니다. 대신 개발자, AI 에이전트 (AI agents), 리뷰 (reviews), 그리고 CI가 변경 사항에 의해 열리는 미래를 동일한 지도 위에서 볼 수 있는 개발 환경을 만들고자 합니다. 모호한 PRD (Product Requirements Document)가 도착합니다. AI 에이전트가 구현 방안을 빠르게 제안합니다. 동시에, 워크벤치 (workbench)는 해당 변경 사항이 열어주는 것으로 보이는 미래들을 스케치하고, 리뷰에 필요한 차이점 (differences)만을 보여줍니다.

PRD -> 구현 후보군 (implementation candidates) -> 도달 가능한 미래 범위 (reachable future range) -> 리뷰 관련 차이점 (review-relevant differences) -> 리뷰 / CI / 거버넌스 (governance) -> 관찰된 결과 (observed outcome) -> 다음 예측 업데이트

리뷰어는 diff의 모든 줄을 읽기 전에 어떤 미래가 위험해 보이는지를 확인합니다. CI는 단순히 테스트가 통과하는지뿐만 아니라, 우리가 제거하고자 했던 리스크가 여전히 존재하는지까지 확인합니다. AI 에이전트는 단순히 가장 가까운 지름길을 복사하는 대신, 더 나은 미래를 여는 구현 후보군을 우선적으로 선택합니다. 실제 PR (Pull Requests), 인시던트 (incidents), 그리고