어트랙터 가이드 엔지니어링 (Attractor Guided Engineering)이 AI 에이전트 기술 (Skill)로 격하될 수 없는 이유

에이전트 기술 (Agent Skill)은 이미 AI 에이전트 엔지니어링 (AI Agent engineering)에서 가장 널리 받아들여지는 관행 중 하나입니다. 즉, 반복 가능한 작업들을 발견 가능하고, 호출 가능하며, 컨텍스트 (context)에 주입할 수 있는 능력 패키지 (capability packages)로 캡슐화하는 것입니다.

이는 분명 가치가 있습니다. 버그를 진단하는 것은 기술 (skill)이 될 수 있습니다. 코드를 리뷰하는 것도 기술이 될 수 있습니다. 슬라이드를 생성하는 것도 기술이 될 수 있으며, 파일을 변환하는 것도 기술이 될 수 있습니다. 기술 (skills)은 에이전트 (Agent)가 검증된 작업 방식에 더 빠르게 진입할 수 있게 하며, 팀이 경험을 재사용 가능한 작업 명세 (work specifications)로 추출할 수 있게 해줍니다.

하지만 격언에 있듯이, "당신에게 망치만 있다면 모든 것이 못으로 보일 것이다"라는 말이 있습니다. 기술 (skills)도 마찬가지입니다. 사람들이 유용한 관행을 발견하자마자, 그들의 첫 번째 본능은 종종 "이를 재사용 가능한 기술 (reusable skill)로 감싸자"가 됩니다.

어트랙터 가이드 엔지니어링 (Attractor Guided Engineering, AGE)은 만약 모든 AI 엔지니어링 관행이 기술 (skill)로 변환된다면, AI 중심의 소프트웨어 엔지니어링 (software engineering)에서 가장 중요한 질문을 놓치게 된다고 지적합니다: 지속적인 섭동 (continuous perturbation) 하에서 시스템이 어떻게 통제되고 수렴 (convergent) 상태를 유지할 것인가?

기술 (Skills)은 능력 호출 (capability invocation)의 문제를 해결합니다. AGE는 저장소 (repository)의 장기적인 진화 과정에서 도메인 구조 (domain structure)가 어떻게 보존되는지, 그리고 궤적 드리프트 (trajectory drift)가 어떻게 억제되는지의 문제를 해결합니다.

이것은 또한 왜 AGE가 기술 (skill)로 격하될 수 없는지를 설명합니다. 기술 (skills)을 AGE 관행의 주요 수단으로 만드는 것은 저장소 수준의 수렴 메커니즘 (repository-level convergence mechanisms)을 일회성 호출 능력 (one-shot invocation capabilities)으로 붕괴시켜, AGE의 목적을 무색하게 만들기 때문입니다.

1. 기술 (Skill)의 본질은 시맨틱 수준의 해시 맵 (Semantic-Level Hash Map)이다

많은 사람들이 기술 (skills)을 생각할 때, 가장 먼저 파일 형태를 떠올립니다: SKILL.md, 설명, 트리거 단어 (trigger words), 지원 파일, 스크립트, 템플릿 등입니다.

하지만 이것들은 단지 껍데기에 불과합니다. 기술 (skill)이 실제로 작동하는 곳은 에이전트 런타임 (Agent runtime)이 이를 **시맨틱 수준의 조회 테이블 (semantic-level lookup table)**로 구성할 때입니다:

작업 의도 (task intent) -> 매칭된 기술 (matched skill) -> 절차 번들 (procedure bundle)

다시 말해, 에이전트 (Agent)는 단순히 파일 이름이 SKILL.md라고 해서 능력을 얻는 것이 아닙니다. 현재의 작업 의도 (task intent)가 기술 설명 공간 (skill description space) 내에서 로드 가능한 작업 명세 (work specification)와 매칭될 수 있기 때문에 능력을 얻는 것입니다.

여기서 해시 (hash)는 문자열 해시가 아닙니다. 키 (key)는 고정된 문자열이 아니라 작업 의도 (task intent), 문맥적 단서 (contextual clues), 트리거 단어 (trigger words), 그리고 설명 (descriptions)의 조합이며, 값 (value)은 단일 파일이 아니라 컨텍스트 (context)에 주입될 수 있는 지침 (instructions), 스크립트 (scripts), 템플릿 (templates), 그리고 예시 (examples)의 집합입니다.

이 구조는 다음이라는 질문에 답하기에 이상적으로 적합합니다:

나는 이런 종류의 작업을 해야 하는데 — 어떤 관행 세트 (set of practices)를 로드해야 할까?

따라서 기술 (skills)은 버그 진단, 디프 (diff) 리뷰, 도구 호출 (calling tools), 보고서 생성, 체크리스트 실행과 같은 로컬 능력 (local capabilities)을 캡슐화(encapsulating)하는 데 매우 적합합니다. 기술의 조직 축 (organizing axis)은 호출 의도 (invocation intent)이며, "무엇을 할 것인가"를 "어떤 능력 패키지를 로드할 것인가"로 매핑합니다.

2. 정보 형식은 핵심이 아니다

기술의 실제 메커니즘은 의미론적 매칭 (semantic matching)이기 때문에, 우리는 기술의 파일 형식 (file format)에 집착해서는 안 됩니다.

지능형 에이전트 (intelligent agent)에게 정보가 작성되는 형식은 필수적이지 않습니다. AI는 마크다운 (Markdown)을 읽을 수 있으며, XML 및 기타 형식도 읽을 수 있습니다. 데이터베이스 모델 (database models), API 모델 (API models) 등도 DSL (domain-specific languages, 도메인 특화 언어)로 충분히 표현될 수 있습니다.

AGENTS.md와 docs/index.md는 정보 라우터 (information routers)로서 완벽하게 역할을 수행할 수 있으며, 심지어 더 나은 성능을 낼 수도 있습니다. 파일 링크를 통해 도메인 구조에 따른 계층적 라우팅 (hierarchical routing)을 제공할 수 있기 때문입니다. AI는 먼저 압축된 진입점 (entry point)을 읽은 다음, 작업 요구 사항에 따라 점진적으로 더 구체적인 소유자 문서 (owner docs), 모델 파일 (model files), 테스트 (tests), 그리고 소스 코드 (source code)를 열어볼 수 있습니다.

따라서 질문은 "이 지식이 기술 (skill)로 작성되었는가?"가 아닙니다.

질문은 이것입니다: 정보가 형태를 바꾼 후에도, 원래의 구조가 여전히 존재하는가?

지능의 핵심 역량 중 하나는 정보를 다양한 형태로 자유롭게 변환하는 능력입니다. 만약 구조가 유지된다면, Markdown, XML, 테스트, DSL/스키마(schema), 또는 소스 코드 앵커(anchor)로 작성된 지식 모두 AI에 의해 사용될 수 있습니다. 만약 구조가 상실된다면, 아무리 정교한 기술 (skill)로 이를 감싸더라도 구조가 사라진 후에는 그 파편들을 호출하기 더 쉽게 만들 뿐입니다.

3. 동역학계 (Dynamical Systems)가 구조 보존에 주목하는 이유

수학과 물리학에서의 동역학계 (Dynamical systems)는 유용한 직관을 제공합니다. 시스템을 설명하는 변수들은 변할 수 있지만, 시스템의 진화 (evolution)를 지배하는 핵심 구조는 함부로 버려져서는 안 됩니다.

진자 시계를 상상해 보십시오. 이를 각도와 각속도로 설명할 수도 있고, 위치와 속도로 설명할 수도 있으며, 혹은 에너지와 위상 (phase)으로 설명할 수도 있습니다. 표현 방식은 변할 수 있지만, 진자의 핵심 구조는 상실될 수 없습니다. 즉, 위치와 속도가 어떻게 결합(coupled)되어 있는지, 에너지가 어떻게 변하는지, 감쇠 (damping)가 에너지를 어떻게 소산(dissipate)시키는지, 외부 힘이 어디에서 유입되는지 등이 그러합니다.

만약 어떤 알고리즘이 이러한 구조들을 보존하지 않은 채 오직 "다음 위치가 대략적으로 맞는지"만을 추구한다면, 각 단계에서는 아주 작은 오차만을 발생시킬지 모르나, 장기적으로는 진자가 이유 없이 점점 더 높게 흔들리게 하거나 갑자기 멈추게 만들 수 있습니다. 국소적인 출력 (local output)은 비슷해 보일지라도, 장기적인 시스템은 더 이상 원래의 시스템이 아닙니다.

전기 회로를 생각해 보십시오. 노드 전압 (node voltages)으로 설명할 수도 있고, 가지 전류 (branch currents)로 설명할 수도 있으며, 커패시터와 인덕터에 저장된 에너지를 상태 변수 (state variables)로 취급할 수도 있습니다. 변수의 형태는 변할 수 있지만, 몇몇 구조는 반드시 유지되어야 합니다. 즉, 전하 보존 (charge conservation), 전압과 전류 사이의 결합 관계, 부품에서의 에너지 저장 및 소산, 그리고 외부 전원이 에너지를 주입하는 지점 등이 그러합니다.

만약 어떤 알고리즘이 이러한 구조들을 보존하지 않은 채, 단지 서로 가까워 보이는 몇몇 샘플링 지점에서의 전압 값만을 추구한다면, 장기적인 시뮬레이션은 자발적으로 에너지를 생성하거나, 에너지를 소산(dissipate)해야 할 시스템을 끝없이 진동하는 시스템으로 변질시킬 수 있습니다. 국소적인 곡선은 진실과 닮아 보일지 모르나, 시스템의 물리적 의미는 이미 잘못된 상태가 됩니다.

이것이 바로 구조를 보존한다는 것의 의미입니다:

표현 방식은 변할 수 있지만, 핵심적인 제약 조건(constraints), 결합 관계(coupling relationships), 그리고 보존/소산 구조(conservation/dissipation structures)는 반드시 상실되지 않아야 합니다.

제어된 시스템이 장기적으로 수렴하는 이유는 각 단계가 합리적으로 보이기 때문이 아니라, 반복적인 변환(transformations)과 섭동(perturbations)을 통해서도 이러한 구조들이 보존되기 때문입니다.

4. 상태 공간(State Space)은 소스 코드 공간(Source Code Space)이 아니다

만약 우리가 소프트웨어 엔지니어링을 동역학계(dynamical systems)의 관점에서 관찰한다면, 저장소(repository)는 더 이상 정적인 폴더가 아니라 반복적으로 섭동을 받는 하나의 시스템이 됩니다. 모든 요구사항 명확화, 계획 생성, 코드 수정, 테스트 추가, 리뷰, 그리고 로그 업데이트는 저장소를 새로운 상태로 밀어넣습니다.

전통적인 소프트웨어 엔지니어링은 암묵적인 가정에 기반하고 있습니다. 즉, 인간의 뇌가 시스템 진실의 장기적인 암묵적 적분기(implicit integrator) 역할을 할 수 있다는 가정입니다. 소스 코드, 요구사항, 아키텍처 상의 트레이드오프(trade-offs), 과거의 버그, 그리고 명문화되지 않은 맥락들은 궁극적으로 진화의 방향을 결정하는 소수의 핵심 엔지니어들에 의해 완전히 이해될 수 있다고 믿어집니다.

AI가 깊이 관여하게 되면서, 이러한 근본적인 가정은 흔들리고 있습니다. AI는 높은 빈도로 생성하고, 큰 진폭으로 수정하며, 여러 모듈에 걸쳐 확산할 수 있는 반면, 각 세션은 지속적인 방향성을 결여하고 있습니다. AI가 상태 공간 (State space)에 도입하는 확장력은 소수 인간의 정보 처리 능력을 훨씬 초과합니다. 이 시점에서, 만약 우리가 AI의 속도를 인간이 지속적으로 통합할 수 있는 리듬으로 강제로 늦추지 않는다면, 시스템 진화의 진실의 원천 (Source of truth)은 더 이상 누군가의 머릿속에 있는 기억이 될 수 없습니다. 다음 세션이 다시 읽을 수 있는 것은 저자의 마음속에 있는 완전한 의도가 아니라, 저장소 (Repository)에 있는 코드, 디프 (diffs), 로그 (logs), 테스트 (tests), 문서 (docs), 모델 (models), 그리고 감사 증거 (audit evidence)입니다.

nop-chaos-flux의 역사는 이미 이러한 종류의 드리프트 (drift)를 여러 차례 기록했습니다. docs/plans/436-deep-audit-2026-05-24-full-remediation-plan.md의 워크스트림 8 (Workstream 8)은 활성 문서 드리프트 (active-doc drift)를 수정했습니다. 즉, 문서는 component:open/close/toggle, component:refresh, 이전 패키지 분할, 이전 소스 앵커 (source anchors), 그리고 구식 컴포넌트 인벤토리 (component inventory)를 현재의 사실로 기술하고 있었으나, 실제 저장소는 더 이상 그와 같지 않았습니다. docs/logs/2026/05-26.md는 증명 드리프트 (proof drift)를 기록했습니다. E2E 테스트는 여전히 스프레드시트의 30개 행 헤더가 동시에 마운트된다고 단언하고 있었으나, 실제 스프레드시트 셸 (shell)은 이미 가상화되어 있었기에, 올바른 증명은 가시적인 행 헤더만이 마운트된다고 단언할 수 있을 뿐이었습니다. 코드, 문서, 테스트는 각각 국소적으로는 타당할 수 있지만, 그들 사이의 소유자/증명/우선순위 (owner/proof/precedence) 관계는 이미 드리프트되었습니다.

따라서, AGE의 기본 전제는 다음과 같습니다:

Repository = Source of Truth (진실의 원천)
Chat = Transient work surface (일시적 작업 표면)

이 전제하에, 핵심 질문은 다음과 같습니다:

이번에 에이전트 (Agent)가 올바른 스킬 (skill)을 호출했는가?

가 아니라:

많은 에이전트 섭동 (Agent perturbations) 이후에도, 저장소가 도메인 구조 (domain structure)를 따라 통제된 방식으로 여전히 수렴하는가?

AGE의 기본 구조는 다음과 같습니다:

State space (상태 공간) -> Attractor (어트랙터) -> Trajectory (궤적) -> Control (제어)

여기서의 상태 공간 (State space)은 "소스 코드 상태 공간 (source code state space)"이 아닙니다. 소스 코드는 현재 구현이 무엇인지에 대해서는 답을 줄 수 있지만, 시스템이 어디로 수렴해야 하는지, 왜 특정 설계가 유효한지, 어떤 동작이 검증되었는지, 왜 특정 편차가 허용되었는지, 그리고 다음번에 AI가 어디로부터 문맥 (context)을 복구해야 하는지에 대해서는 단독으로 답할 수 없습니다.

AGE는 전체 리포지토리 엔지니어링 실체 (engineering reality)의 상태를 다룹니다. 즉, 소스 코드, 테스트, 소유자 문서 (owner docs), 요구사항, 계획, 로그, 버그 노트, 스키마, XML 모델, 데이터베이스 모델, XDSL, AGENTS.md, docs/index.md, CI 설정, 그리고 감사 증거 (audit evidence)가 함께 하나의 상태를 구성합니다.

이것들은 분리 가능한 여러 재료가 아니라, 동일한 세트의 의미론적 약속 (semantic commitments)이 서로 다른 매체 (carriers)에 분산되어 있는 것입니다. 코드는 구현 사실 (implementation facts)에 대한 권위 (authority)를 가지며, 소유자 문서는 수렴 방향 (convergence direction)에 대한 권위를, 테스트는 검증된 동작 (proven behavior)에 대한 권위를, 로그/버그 노트는 진화 궤적 (evolution trajectory)에 대한 권위를, 계획/감사는 현재의 변경 사이클이 종료되었는지 여부에 대한 권위를 가집니다. AGE가 유지해야 하는 것은 이러한 권위들 사이의 관계이지, 특정 파일 형식을 신성시하는 것이 아닙니다.

스킬 (Skill)은 다른 위치를 차지합니다. AGE는 리포지토리 자체를 조직하며, 스킬은 리포지토리에 작용하는 외부 능력 (external capabilities) 또는 제어 입력 (control inputs)입니다.

외부 능력은 시스템을 변경할 수는 있지만, 시스템의 내부 구조를 대체할 수는 없습니다. bug-diagnosis 스킬은 많은 리포지토리, 많은 도메인, 많은 버그 유형에서 사용될 수 있습니다. 그 조직 논리는 일반적인 작업 능력이지, 특정 리포지토리 내부의 도메인 개념들의 위상 (topology)이 아닙니다.

리포지토리 내부에 진정으로 보존되어야 하는 것은 소스 코드, 문서, 테스트, 모델, 계획, 로그, 그리고 감사 증거 사이의 관계, 즉 소유권 (owner), 증명 (proof), 선행 관계 (precedence), 최신성 (freshness)과 같은 관계들입니다. 스킬은 이러한 것들을 수정하는 데 도움을 줄 수는 있지만, 관계 그 자체를 대체할 수는 없습니다.

이 시점에서 우리는 스킬(skill)의 시맨틱 해시(semantic hash)만으로는 이 문제를 해결하기에 불충분하다는 것을 깨닫습니다. 스킬이 저장하는 것은 다음과 같습니다:

작업 의도 (task intent) -> 역량 패키지 (capability package)

AGE가 보존해야 하는 것은 다음과 같습니다:

도메인 개념 (domain concept) -> 시맨틱 약속 (semantic commitment) -> 구현 위치 (implementation location) -> 증거 입증 (proof evidence) -> 감사/메모리 (audit/memory) -> 후속 의무 (subsequent obligations)

이 두 구조는 서로 다릅니다. 스킬은 에이전트(Agent)에게 검토하는 방법을 알려줄 수는 있지만, 어떤 소유 문서(owner doc)가 현재의 시맨틱 사실(semantic fact)을 보유하고 있는지는 자동으로 알 수 없습니다. 스킬은 에이전트에게 테스트를 작성하는 방법을 알려줄 수는 있지만, 이 테스트가 어떤 도메인 약속(domain commitment)을 보호하는지는 자동으로 알 수 없습니다. 스킬은 에이전트에게 문서를 업데이트하는 방법을 알려줄 수는 있지만, 특정 정보가 소유 문서(owner doc), 버그 노트(bug note), 로그(log), 교훈(lesson), 참조(reference), 또는 스킬(skill) 중 어디로 들어가야 하는지를 자동으로 결정할 수는 없습니다.

이러한 판단은 호출 능력(invocation capabilities)이 아닙니다. 이것들은 저장소(repository)의 시맨틱 권한 구조(semantic authority structure)입니다.

5. age-skill이 잘못된 추상화인 이유

AGE를 age-skill로 만드는 것은 표면적으로는 유혹적입니다. AGE의 규칙, 절차, 체크리스트, 그리고 문서 템플릿을 가져와 호출 가능한 역량 패키지(capability package)로 작성하는 것입니다. 에이전트가 AGE를 필요로 할 때, 이 스킬을 로드하면 됩니다.

하지만 이는 AGE를 정확히 잘못된 계층에 위치시키는 것입니다. 스킬은 작업이 발생한 후 매칭되고 로드되는 역량 패키지입니다. 반면 AGE는 작업이 시작되기 전부터 이미 존재해야 하는 저장소 구조(repository structure)여야 합니다. AGE는 작업이 어떻게 이해되는지, 정보가 어디에서 읽히는지, 충돌 시 누구의 목소리가 우선하는지, 그리고 완료 후 어떻게 종결(closure)이 입증되는지를 결정합니다.

AGE는 특정 스킬이 선택된 이후에만 나타나도록 기다릴 수 없습니다. AGE는 이미 다음 요소들에 구현되어 있어야 합니다: