분야로서의 소프트웨어 아키텍처: 소프트웨어 진화에 대해 더 나은 질문을 던지는 법

이 기사는 Hashnode에 공개한 Software Architecture as a Field: Asking Better Questions About Software Evolution의 일본어판입니다.

AI coding agent에 의해 코드를 작성하는 속도는 빨라졌습니다. 이는 큰 변화입니다.

하지만 코드를 작성하는 속도가 빨라지는 것과 소프트웨어가 건전하게 진화하는 것은 동일하지 않습니다.

변경 사항을 쌓아 올리는 속도가 빨라질수록, 하나하나의 변경이 codebase에 무엇을 남기고, 다음 변경 가능성을 어떻게 변화시키는지 가 중요해집니다.

기존의 tooling은 많은 경우 이미 발생한 것을 봅니다. code state, PR diff, test result, static dependency, runtime error는 모두 중요한 관측 대상입니다.

하지만 AI coding agent가 연달아 PR을 생성하는 시대에는 한 걸음 더 앞선 질문이 필요합니다.

이 변경은 다음에 어떤 변경을 가능하게 하는가.
이 PRD(요구 문서)는 어떤 PR을 만들기 쉽게 하는가.
이 review rule은 어떤 shortcut을 고비용으로 만드는가.
...

이때 우리는 소프트웨어의 현재뿐만 아니라, 소프트웨어의 진화 그 자체를 다루고 싶어집니다.

이 기사에서는 AAT(Algebraic Architecture Theory)와 SFT(Software Field Theory)를 소프트웨어 진화에 대해 질문을 던지기 위한 이론으로서 소개합니다.

먼저, 계속해서 변하는 소프트웨어를 AAT/SFT가 어떻게 바라보려고 하는지, 그 대략적인 지도를 그려보고자 합니다.

소프트웨어는 완성된 후에 조금씩 열화되는 것이 아닙니다.

사용됨으로써 현실 세계와 연결되고, 그 현실 세계가 변함에 따라 끊임없이 어긋나기 시작합니다.

사용자, 업무, 조직, 운용, 규제, 라이브러리, 인프라는 계속해서 변합니다. 그리고 지금은 AI coding agent가 개발 흐름 그 자체를 바꾸고 있습니다.

이러한 관점은 새로운 것이 아닙니다.

Lehman의 소프트웨어 진화 법칙은 현실 세계의 문제에 연결된 소프트웨어, 이른바 E-type software가 계속 사용되는 한 지속적인 적응을 필요로 한다는 관점을 정식화했습니다.

또한, 진화하는 소프트웨어는 복잡성을 억제하는 명시적인 작업 없이는 복잡해져 갑니다.

나아가 그 진화 과정은 단순한 변경 작업의 나열이 아니라, 다층·다중 루프·다수 주체의 feedback system으로 볼 필요가 있습니다.

여기서 중요한 것은 곧바로 처방전으로 넘어가지 않는 것입니다.

"그러니까 리팩터링(Refactoring)을 합시다"도 아니고, "그러니까 설계 리뷰를 강화합시다"도 아니며, "그러니까 AI를 엄격하게 제어합시다"도 아닙니다.

Lehman의 너머에 있는 질문은 조금 더 깊습니다.

소프트웨어가 계속 변한다면,
그 변화에 대해 우리는 무엇을 물을 수 있는가.

AAT/SFT는 이 질문에서 출발합니다.

설계 논의에서는 자주 다음과 같은 질문이 나타납니다.

이 설계는 좋은가.
이 변경은 안전한가.
이 PR은 수락해도 좋은가.
...

모두 자연스러운 질문입니다. 하지만 그대로 두기에는 너무 큽니다.

"좋다"는 것은 무엇을 보존하고 있다는 의미인가요?

"안전하다"는 것은 어느 범위의 미래에 대해 말하고 있는 것인가요?

"위험하다"는 것은 어떤 관측 축에서 어떤 파괴(break)가 보인다는 의미인가요?

"이전해야 한다"는 것은 어떤 변경 경로를 닫고, 어떤 변경 경로를 연다는 판단인가요?

AAT/SFT에서는 질문을 조금 더 분해합니다.

무엇을 대상으로 추출하고 있는가.
무엇을 보존하고 싶은가.
무엇이 깨져 있는가.
...

이것은 설계 리뷰를 체크리스트화하자는 이야기가 아닙니다. 현장에서 암묵적으로 수행하고 있는 판단을, 변화하는 소프트웨어를 다루기 위한 이론적 대상으로 재구성한다는 이야기입니다.

AAT는 소프트웨어 아키텍처를 국소적으로 읽기 위한 이론입니다.

여기서 아키텍처를 codebase 전체 그 자체로 보지는 않습니다. 먼저 질문에 답하기 위한 대상을 추출하고, 그것을 ArchitectureObject라고 부릅니다.

거대한 codebase 전체를 한 번에 다룰 필요는 없습니다. 어떤 경계, 어떤 의존 관계(dependency), 어떤 runtime 상호작용(interaction), 어떤 의미적 계약(semantic contract)에 주목하여 그 부분만을 대상으로 삼습니다.

중요한 것은 무엇을 대상으로 삼았는지를 명시하는 것입니다.

다음으로, 그 대상에 대해 어떤 성질을 보존하고 싶은지를 생각합니다. 이를 Invariant라고 부릅니다.

의존 방향을 지키고 싶은 것인가요?

경계를 지키고 싶은 것인가요?

추상화(abstraction)를 지키고 싶은 것인가요?

교체 가능성(replaceability)을 지키고 싶은 것인가요?

runtime 보호를 지키고 싶은 것인가요?

상태 전이(state transition)의 정합성을 지키고 싶은 것인가요?

"좋은 설계"라는 말 속에는 이러한 여러 개의 invariant가 섞여 있습니다.

AAT에서는 그것들을 일단 분리해서 봅니다.

보존하고 싶은 성질이 깨져 있다면, 그 깨짐을 설명할 증거가 필요합니다. 이를 Obstruction이라고 부릅니다.

obstruction은 단순한 에러가 아닙니다. "왜 그 성질이 성립하지 않는가"를 보여주는 구조적인 증거, 즉 witness입니다.

숨겨진 의존, 경계 침범, 추상화 누출, 가환(commutative)이어야 할 작업 순서의 불일치, runtime 노출(exposure) 등은 모두 obstruction으로 읽을 수 있습니다.

마지막으로, 이러한 관측들을 단일 점수로 뭉뚱그리지 않고 다축(multi-axis)으로 읽습니다. 이것이 ArchitectureSignature입니다.

AAT의 읽는 법을 짧게 쓰면 다음과 같습니다.

이 변경은 어떤 대상에 대한 조작인가.
어떤 invariant를 보존하고 싶은가.
어떤 obstruction이 나타나고 있는가.
...

AAT는 "아키텍처의 좋음"을 하나의 점수로 만들지 않습니다.

설계 판단을 대상, 보존량, 깨짐, 관측 축, 경계로 분해합니다.

그렇다면 왜 이것을 대수적(algebraic)이라고 부를까요?

AAT에서는 아키텍처를 정적인 그림으로 바라보는 것에 그치지 않고, 조작할 수 있는 대상으로 다룹니다.

어떤 architecture object가 있고, 그것에 대해 split, replace, abstract, protect, migrate, repair와 같은 조작이 있습니다.

그 조작이 무엇을 보존하고, 무엇을 파괴하며, 다른 조작과 어떻게 합성(composition)될 수 있는지를 봅니다.

관심사는 다음과 같은 형태를 띱니다.

object
+ operation
+ preservation
...

AAT가 다루는 것은 단순한 평가가 아닙니다. 대상이 있고, 조작이 있고, 보존되는 구조가 있으며, 깨짐이 있고, 조작 열(sequence of operations)이 있습니다.

이 구조를 보기 위해 아키텍처를 대수적으로 다룹니다.

예를 들어, 어떤 변경이 의존 방향을 보존합니다.

다른 변경이 추상화 경계를 보존합니다.

두 변경을 연속해서 적용했을 때, 그 보존성은 합성될까요?

도중에 obstruction이 발생할까요?

결과가 같아 보이는 두 변경 경로, 즉 path는 동일한 signature trajectory(signature의 궤적)를 가질까요?

AAT가 다루고 싶은 것은 바로 이러한 구조입니다.

이러한 관점으로 보면 소프트웨어 엔지니어에게 친숙한 설계 원칙들도 조금 다르게 보입니다.

예를 들어 SOLID는 AAT에서 만능 설계 원리가 아닙니다.

그것은 주로 국소적인 계약을 지키기 위한 원칙군으로 읽을 수 있습니다.

SRP는 책임의 경계를 지키려 합니다.

OCP는 기존의 계약을 깨뜨리지 않고 확장할 수 있는 형태를 요구합니다.

LSP는 추상화에 대해 동일하게 관측될 수 있음을 요구합니다.

ISP는 불필요한 의존을 interface로부터 분리하려고 합니다.

DIP는 구체(concrete)에 대한 의존을 추상(abstract)에 대한 의존으로 옮기려 합니다.

SOLID가 주로 다루고 있는 것은 국소 계약, 추상화, 교체 가능성, interface 분리와 같은 invariant입니다.

반면, Layered Architecture는 다른 층위를 다룹니다.

Layered Architecture가 지키려는 것은 개별 class의 책임이라기보다 시스템 전체의 의존 방향입니다.

상위 계층과 하위 계층의 ranking이 있으며, 의존이 그 방향을 따르고 있는지를 봅니다.

계층을 뛰어넘는 의존이 없는지 확인합니다.

순환(cycle)이 발생하지 않는지 확인합니다.

시스템이 분해 가능한 형태로 유지되고 있는지를 확인합니다.

AAT의 용어로 말하자면, SOLID는 주로 국소 계약 계층(local contract layer)의 불변량(invariant)을 다루고, 계층형 아키텍처(Layered Architecture)는 대역 구조 계층(global structure layer)의 불변량(invariant)을 다룹니다.

SOLID
-> local contract / abstraction / substitutability
Layered Architecture
...

이러한 분류의 장점은 설계 원칙을 단 하나의 정답으로 취급하지 않아도 된다는 점에 있습니다.

SOLID를 준수하더라도 시스템 전체가 깔끔하게 분해되어 있다고 단정할 수 없습니다.

반대로, 계층형 아키텍처(Layered Architecture)를 준수하더라도 개별 추상화가 교체 가능(substitutable)하다고 단정할 수 없습니다.

각각이 준수하는 불변량(invariant)이 다르면, 위반되는 방식도 다르고 관측해야 할 시그니처 축(signature axis)도 다릅니다.

클린 아키텍처(Clean Architecture)라면 경계 보존(boundary preservation), 내향 의존(inward dependency), 추상화 일관성(abstraction integrity)을 봅니다.

이벤트 소싱(Event Sourcing)이라면 리플레이(replay), 프로젝션(projection), 이력과 현재 상태의 관계식을 봅니다.

서킷 브레이커(Circuit Breaker)라면 런타임 보호(runtime protection)나 장애 국소성(fault locality)을 봅니다.

AAT는 설계 원칙을 "어느 것이 옳은가"의 순위 매기기로 만들지 않습니다.

각각이 어떤 불변량 군(invariant family)을 담당하며, 어떤 장애물(obstruction)을 방지하고, 어떤 시그니처 축(signature axis)에 나타나는지를 분류합니다.

AAT에서는 이 사고방식을 한 단계 더 발전시켜 곡률(curvature)이라는 어휘로 표현합니다.

여기서 말하는 곡률이란, 선택한 불변량(invariant)에 대해 남아 있는 장애물(obstruction)을 의미합니다.

보존하고 싶은 구조가 있고, 그 구조를 깨뜨리는 목격자(witness)가 남아 있다면 그곳에는 곡률이 존재합니다.

직관적으로는 다음과 같이 읽을 수 있습니다.

곡률이 있다
= 보존하고 싶은 구조에 대해 어딘가에 위반(break)이 있다
곡률이 제로(zero)이다
...

여기까지는 거의 정의에 가깝습니다. 중요한 것은 그 다음입니다.

AAT가 지향하는 것은 "좋은 설계란 위반이 없는 설계이다"라고 말을 바꾸는 것이 아닙니다.

여기서 말하는 법칙(law)은 보존하고 싶은 성질을 조금 더 명시적인 규칙으로 작성한 것으로 읽을 수 있습니다.

선택한 법칙(law)에 대해 법칙 준수(lawful), 즉 그 규칙을 따르고 있음을 유한하게 관측 가능한 장애물 목격자(obstruction witness)와 아키텍처 시그니처(ArchitectureSignature)의 필수 축(required axis)이 제로(zero)인 상태로 연결하는 것입니다.

selected laws에 대한 lawfulness
<-> 필요한 obstruction witness가 없음
<-> 필요한 signature axes가 zero임

AAT에서는 이 연결을 아키텍처 제로 곡률 정리(Architecture Zero Curvature Theorem)라고 부릅니다.

핵심은 세 가지 계층이 연결된다는 점에 있습니다.

의미론(Semantics):
selected law universe 하에서 lawful함
witness:
...

통상적인 설계 리뷰에서는 "경계가 지켜지고 있다", "책임이 분리되어 있다", "확장하기 쉽다"와 같은 말들이 종종 모호하게 사용됩니다.

제로 곡률 정리가 제공하는 것은, 그러한 판단을 어떤 법칙(law), 어떤 목격자(witness), 어떤 관측(observation), 어떤 시그니처(signature)에 상대화하여 말할 것인가에 대한 가교입니다.

AAT에서의 좋은 설계란 단순히 아름다워 보이는 설계가 아닙니다.

선택한 법칙의 범위 내에서, 보존하고 싶은 성질을 깨뜨리는 장애물(obstruction)이 사라지고, 그것이 시그니처(signature) 상에서도 제로(zero)로 관측될 수 있는 설계입니다.

이 정리의 가치는 "위반이 없으면 좋다"라는 슬로건에 있는 것이 아닙니다.

'좋다'라는 판단을 의미론(semantics), 목격자(witness), 측정 가능한 시그니처 축(signature axis) 사이에서 이동할 수 있게 만드는 데 있습니다.

AAT가 "이 변경은 무엇을 보존하고 무엇을 깨뜨렸는가"를 묻는 이론이라면, SFT는 한 걸음 더 나아가 "그 변경은 다음에 어떤 변경을 자연스럽게 만드는가"를 묻습니다.

AAT로 구축한 국소 대수(local algebra)의 토대 위에, SFT라는 소프트웨어 진화를 다루는 건축물을 세웁니다.

AAT에서 보고 있는 것은 하나의 변경에 대한 국소 구조(local structure)입니다. 그 변경이 어떤 대상에 대한 조작인지, 무엇을 보존했는지, 어디에 위반이 있는지, 어떤 관측 축에서는 무엇을 말할 수 있고 어디서부터는 말할 수 없는지를 봅니다.

SFT에서 보고 있는 것은 그 변경이 놓인 장(場)입니다. 그 변경이 다음 변경을 어떻게 유도하는지, 어떤 path(경로)를 저비용으로 만들고 어떤 path를 보기 어렵게 만드는지, 어떤 feedback(피드백)이 기억으로 남고 어떤 future(미래)를 도달 가능하게 만드는지를 봅니다.

SFT에서는 이 문맥 전체를 field라고 부릅니다.

field란 codebase(코드베이스)뿐만 아니라, 그 codebase에 작용하는 requirements(요구사항), design docs(설계 문서), PRD, issues(이슈), review rules(리뷰 규칙), CI, type checker(타입 체커), runtime feedback(런타임 피드백), AI agent policy(AI 에이전트 정책) 등을 포함하는 전체를 의미합니다.

그것은 어떤 변경이 자연스럽게 보이고, 어떤 변경이 어려워지며, 무엇이 관측 가능해지고, 어떤 feedback이 다음 판단에 남을지를 결정합니다.

field
= codebase
+ artifacts
...

SFT는 codebase만을 대상으로 하는 이론이 아닙니다.

요구사항을 작성하고, 설계하고, issue를 나누고, PR을 만들고, review를 하고, CI를 통과시키고, 운영으로부터 feedback을 받는 개발 조직 전체를 대상으로 하는 이론입니다.

그렇다면, force란 무엇일까요?

이 글에서는 PRD, spec(사양), issue, AI proposal(AI 제안), incident report(장애 보고서) 등의 artifact(아티팩트)가 field에 만드는 업데이트 후보들의 집합을 force라고 부릅니다.

하나의 PRD가 단 하나의 PR만을 결정하는 것은 아닙니다.

하지만 그 PRD는 어떤 issue 분해가 자연스러운지, 어떤 PR이 만들어지기 쉬운지, 어떤 architecture region(아키텍처 영역)에 변경이 전달되기 쉬운지를 변화시킵니다.

force
= artifact가 field에 주는 candidate updates (업데이트 후보)
= operation support / observation boundary / selection policy의 변화

여기서 말하는 operation support는 어떤 조작이 가능하고, 자연스러우며, 저비용으로 보이는지를 나타냅니다. observation boundary는 무엇이 보이고 무엇이 보이지 않는가이며, selection policy는 어떤 선택이 통과되기 쉬운가를 나타냅니다.

field는 상태(state)이고, force는 artifact-mediated change(아티팩트에 의해 매개된 변화)이며, future는 그 field로부터 도달 가능한 path의 집합입니다.

동일한 module graph(모듈 그래프)를 가진 codebase라도, field가 다르면 다음에 자연스럽게 선택될 변경은 달라집니다.

과거의 incident(장애), 오래된 workaround(임시 방편), 암묵적인 ownership boundary(소유권 경계), AI agent가 모방하기 쉬운 local pattern(로컬 패턴)은 미래의 operation support와 selection policy를 변화시킵니다.

여기서 말하는 "계산 가능"이란 소프트웨어의 미래를 한 점으로 예측할 수 있다는 의미가 아닙니다.

명시된 field model, operation support, observation boundary, horizon(지평) 하에서, 도달 가능한 future의 범위를 bounded(유계)한 문제로 다룰 수 있다는 의미입니다.

예를 들어, 어떤 artifact가 field에 들어왔을 때, SFT는 다음과 같은 질문을 계산 문제로 바라봅니다.

입력:
current field
+ artifact
...

이론 측면에서는 이 도달 가능한 path의 집합을 ForecastCone이라고 부릅니다.

실무 측면에서는 그것을 읽을 수 있는 report(보고서)로 정리한 것을 ConsequenceEnvelope라고 부릅니다.

중요한 것은 SFT가 "이 PRD로부터 반드시 이 PR이 태어난다"라고 주장하는 이론이 아니라는 점입니다.

SFT가 보고 싶은 것은 이 field에서 어떤 path가 가까워지고, 어떤 path가 멀어지며, 어떤 obstruction(장애물)이 보이게 되는가입니다.

PRD에서 PR로 이어지는 흐름을 생각하면 SFT의 직관을 파악하기 쉬워집니다.

PRD는 단순한 요구사항 문서가 아닙니다. 미래의 PR 형태를 어느 정도 결정하는 artifact입니다.

같은 "기능 추가"라는 요구사항이라도, PRD가 경계, 책임, 관측해야 할 성질을 명시하고 있는지에 따라 만들어지기 쉬운 PR은 달라집니다.

그리고 PRD는 많은 경우 PdM(Product Manager), designer(디자이너), domain expert(도메인 전문가)와 같이 코드를 직접 작성하지 않는 사람들에 의해 만들어집니다.

엔지니어가 아닌 사람들도 artifact(산출물)를 통해 codebase(코드베이스)에 force(강제력)를 가하고 있습니다.

PRD
-> 가능한 issue decomposition (이슈 분해)
-> 가능한 PR shapes (PR 형태)
...

SFT에서는 이 PRD가 codebase에 어떤 힘을 가하고, 어떤 ForecastCone (예측 원뿔)을 생성하는지를 살펴봅니다.

단, 그 cone은 하나의 결정된 미래를 나타내는 것이 아닙니다.

오히려 일기 예보의 예보 원처럼, 도달 가능한 미래의 범위를 나타냅니다.

이 PRD로부터는 어떤 PR이 태어나기 쉬운가.
그 PR은 어느 architecture region (아키텍처 영역)에 작용할 것인가.
어떤 invariant (불변량)를 지키고, 어떤 obstruction (장애물)을 만들어낼 수 있는가.
...

이 때문에 SFT는 다음과 같은 형태로 질문합니다.

이 field (분야)에서는 어떤 `ForecastCone`이 열리는가.
어떤 path (경로)가 자연스러워지고, 어떤 path가 멀어지는가.
무엇이 관측 가능하고, 무엇이 관측되지 못한 채 남는가.

이런 의미에서 SFT는 소프트웨어 진화를 계산 가능한 대상으로 만들려는 이론입니다.

Conway's Law (콘웨이의 법칙)는 SFT의 어휘로 자연스럽게 다시 읽을 수 있습니다.

잘 알려진 바와 같이, Conway's Law는 "시스템의 설계는 그 조직의 커뮤니케이션 구조를 반영한다"라는 경험칙으로 이야기됩니다.

SFT에서는 이를 단순한 비유가 아니라, organization field (조직 분야)가 architecture future (아키텍처 미래)를 형성하는 현상으로 읽습니다.

조직 구조가 codebase에 직접 아키텍처를 명령하는 것은 아닙니다.

하지만 team boundary (팀 경계), ownership (소유권), review route (리뷰 경로), approval flow (승인 흐름), on-call boundary (온콜 경계), issue decomposition (이슈 분해)은 어떤 변경이 자연스럽게 보일지, 어떤 PR이 저비용이 될지, 어떤 변경이 리뷰를 통과하기 쉬울지를 변화시킵니다.

organization structure (조직 구조)
-> communication paths (커뮤니케이션 경로)
-> ownership boundaries (소유권 경계)
...

조직 구조는 operation support (운영 지원)를 변화시키고, operation support는 일상적인 설계 변경을 변화시킵니다. 그 반복이 아키텍처로서 codebase에 침착됩니다.

예를 들어, Frontend Team, Backend Team, Data Team, Infra Team과 같이 조직이 나뉘어 있다면, issue나 PR도 그 경계에 따라 형성되기 쉽습니다.

결과적으로 아키텍처 또한 그 경계를 따라 나뉘기 쉬워집니다.

반면, Search, Checkout, Billing과 같이 product capability (제품 기능) 단위로 조직되어 있다면, 그 capability 경계를 보존하는 변경이 자연스러워지기 쉽습니다.

SFT의 언어로 말하자면, Conway's Law는 다음과 같이 읽을 수 있습니다.

organization field (조직 분야)
-> recurrent PR shape (반복되는 PR 형태)
-> recurrent architecture operation (반복되는 아키텍처 동작)
...

바람직한 architecture를 자연스러운 미래로 만들고 싶다면, 그 architecture를 보존하는 변경이 저비용으로 반복 가능하도록 organization field를 설계해야 합니다.

Conway's Law는 조직 구조와 시스템 구조가 우연히 닮는다는 이야기가 아닙니다.

조직이 일상적인 변경의 용이성을 형성하고, 그 반복이 아키텍처로서 침착된다는 이야기입니다.

AAT/SFT를 현실의 개발에 연결하기 위해서는 관측층이 필요합니다.

이를 위한 구상이 ArchSig입니다.

AAT는 아키텍처를 국소 대수 (local algebra)로 만든다.
ArchSig는 아키텍처를 관측 가능하게 만든다.
SFT는 소프트웨어 진화를 계산 가능하게 만든다.

ArchSig는 codebase, PR, issue, review, incident trace 등의 artifact로부터 어떤 signature axis가 변화하고, 어떤 obstruction이 나타나며, 어떤 field update의 입력이 되는지를 읽어내기 위한 렌즈입니다.

ArchSig에 대해서는 별도의 기사에서 다시 다룰 예정입니다.

여기서는 AAT/SFT가 관측(observation)과 툴링(tooling)으로 연결되는 이론이라는 점만 짚고 넘어가고자 합니다.

SFT 내에서 특히 중요해지는 개념이 바로 어트랙터 엔지니어링 (attractor engineering)입니다.

여기서 말하는 attractor란, 특정 field 내에서 반복적으로 선택되기 쉬워지는 변경의 방향을 의미합니다.

좋은 설계 판단, 좋은 추상화 (abstraction), 좋은 테스트 (test), 좋은 리뷰 규칙 (review rule), 좋은 PRD는 다음의 좋은 변경을 불러들이기 쉽게 만듭니다.

반대로, 안이한 shortcut, 모호한 책임 (responsibility), 깨진 경계 (boundary), 보이지 않는 runtime coupling은 다음의 안이한 변경을 불러들이기 쉽게 만듭니다.

codebase에는 "다음에 어떻게 변경되기 쉬운가"라는 편향 (bias)이 존재합니다.

SFT는 그 편향을 field의 성질로 간주합니다.

어트랙터 엔지니어링이란 바로 이 편향을 설계하는 것입니다.

좋은 변경이
찾기 쉽고
쓰기 쉽고
...

이는 AI agent에게 단순히 강력한 제약을 부과한다는 발상과는 조금 다릅니다.

물론 금지 규칙이나 가드레일 (guardrail)은 필요합니다.

하지만 그것만으로는 바람직하지 않은 field 위에 금지 규칙을 계속해서 쌓아 올리는 꼴이 됩니다.

어트랙터 엔지니어링이 목표로 하는 것은, 좋은 path가 자연스럽게 선택되고, 나쁜 shortcut은 비용이 높으며, 관측 가능하고, 리뷰 (review)를 통해 검출되는 그러한 field를 만드는 것입니다.

AI coding agent의 시대에는 이 사고방식이 더욱 중요해집니다.

AI agent는 기존의 codebase나 주변 artifact로부터 가장 자연스러워 보이는 path를 선택하기 쉽습니다.

이런 의미에서 codebase는 단순한 구현체가 아니라, AI agent에게는 프롬프트 (prompt)이기도 합니다.

field가 바람직하지 않다면, AI agent는 나쁜 local pattern을 고속으로 증폭시킵니다.

반대로 field가 잘 설계되어 있다면, AI agent는 좋은 구조를 고속으로 증폭할 수 있습니다.

SFT의 언어로 말하자면, 어트랙터 엔지니어링이란 미래의 operation support를 설계하는 것입니다.

어떤 변경이 자연스럽게 보일 것인가?

어떤 변경이 저비용이 될 것인가?

어떤 위반 (violation)이 관측 가능해질 것인가?

어떤 피드백 (feedback)이 다음의 field에 남을 것인가?

이 질문은 단순한 품질 관리가 아닙니다.

그것은 소프트웨어 진화의 방향을 설계하는 것입니다.

AAT/SFT가 지향하는 바는 크게 세 가지입니다.

첫 번째는 질문을 바꾸는 것입니다.

이 설계는 좋은가?

라는 질문을 그대로 다루는 것이 아니라, 다음과 같이 분해합니다.

무엇을 대상으로 하고 있는가?
무엇을 보존하고 싶은가?
무엇이 깨져 있는가?
...

이는 현장의 설계 판단을 가볍게 만들기 위함이 아닙니다. 암묵적으로 수행하던 판단을 더 다룰 수 있는 형태로 만들기 위함입니다.

두 번째는 이론의 핵심을 정형 검증 지원 시스템인 Lean으로 형식화 (formalization)하는 것입니다.

AAT/SFT의 모든 것을 한꺼번에 형식화할 필요는 없습니다. 우선 AAT의 국소 대수 (local algebra), invariant, obstruction, signature, 영곡률 정리 (zero curvature theorem)와 같은 기초적인 부분들을 Lean에서 검증 가능한 형태로 만듭니다.

architecture object
+ operation
+ invariant
...

이 핵심이 형식화되면, 어떤 전제로부터 무엇이 도출되는지, 어디서부터는 도출되지 않는지를 기계적으로 확인할 수 있게 됩니다.

세 번째는 그 이론을 실용적인 tool이나 method에 연결하는 것입니다.

AAT는 설계 판단을 invariant와 obstruction의 언어로 읽습니다.

ArchSig는 codebase, PR, issue, review, incident trace로부터 그것들을 관측 가능하게 만듭니다.

SFT는 그 관측을 사용하여 어떤 ForecastCone이 열리고, 어떤 path가 자연스러워지는지를 다룹니다.

AAT
-> 이론의 핵심
Lean
...

최종적으로 목표하는 것은 요구사항(requirement), 설계(design), 이슈(issue), PR(Pull Request), 리뷰(review), CI(Continuous Integration), 운영 피드백(operational feedback), AI 에이전트(AI agent)의 동작을 동일한 이론 위에서 관측하고, 다시 질문하며, 개선하기 위한 도구 모음입니다.

Lehman은 소프트웨어가 계속해서 변화한다는 것을 목격했습니다.

현실 세계와 연결된 소프트웨어는 사용되는 한 환경과 계속해서 어긋나게 됩니다.

그 어긋남을 메우기 위해 변경되고, 변경됨으로써 복잡성(complexity)이 증가하며, 이는 다시 새로운 피드백 루프(feedback loop)를 생성합니다.

AAT/SFT는 이러한 문제 의식의 연장선상에 있습니다.

AAT는 그 변화의 국소 구조(local structure)를 질문합니다. 무엇을 대상으로 하고, 무엇을 보존하며, 무엇이 깨지고, 어떤 축으로 관측할 수 있는지를 고민합니다.

SFT는 그 변화가 다음 변화를 어떻게 형성하는지를 질문합니다. 요구사항, 설계, 이슈, PR, 리뷰, CI, 운영 피드백, AI 에이전트가 어떤 미래(future)를 가깝게 만들고, 어떤 미래를 멀어지게 하는지를 살펴봅니다.

좋은 이론이 즉시 모든 정답을 내놓는 것은 아닙니다. 하지만 좋은 질문을 만들어내고, 그 질문에 어디까지 답할 수 있는지를 알려줍니다.

Lehman이 보여주었듯이, 소프트웨어는 계속해서 변합니다. 그렇다면 우리는 그 변화를 단순히 받아들이는 것에 그치지 않고, 하나의 질문으로서 다룰 수 있도록 만들고자 합니다.

AAT/SFT는 계속해서 변하는 소프트웨어에 대해 질문을 정의하기 위한 시도입니다.

AAT/SFT의 수학적 정의나 정리 경계(theorem boundary), SFT와의 연결에 대해 자세히 알고 싶다면 다음 웹사이트를 참조하십시오.

어트랙터 엔지니어링(Attractor Engineering)의 실천 사례로서, 또한 코드베이스(codebase)를 자동으로 유지보수하는 멀티 에이전트 시스템(multi-agent system)의 사례로서, 고탄다식(Gotanda-style)에 대한 해설 기사도 참조하십시오.