고탄다 방식: 스티그머지를 응용한 자율형 멀티 에이전트 시스템【일본어 번역】

본 기사는 Hashnode에 공개한 AI Agents Don't Need Meetings: Gotanda Style for Stigmergic Software Maintenance의 일본어 번역본입니다.

AI 코딩 에이전트에 의해 코드를 작성하는 속도는 크게 높아지고 있습니다.

이는 멋진 변화입니다. 하지만 코드를 작성하는 속도가 2배가 되면, 유지보수 운영의 부하 또한 증가합니다. 더 많은 코드가 더 짧은 기간 내에 운영 환경(Production)에 진입하며, 더 많은 변경 사항이 모니터링, 디버깅, 리팩터링(Refactoring), 테스트, 설계 개선의 대상이 됩니다.

AI 주도 개발(AI-driven development)에서는 구현 속도만 높이는 것으로는 충분하지 않습니다. 구현 속도에 걸맞은 유지보수 운영 메커니즘도 강화해야 합니다.

LLM을 사용한 멀티 에이전트 시스템(Multi-agent system)에서는 여러 에이전트를 어떻게 협조시킬지가 어려운 문제가 됩니다.

흔히 쓰이는 설계는 에이전트끼리 대화하게 하거나, Supervisor 역할을 하는 에이전트가 전체를 관리하는 방식입니다. 이는 직관적이고 다루기 쉬운 반면, 에이전트 수가 늘어날수록 통신량, 문맥 관리(Context management), 합의 형성, 토큰 소비가 방대해집니다.

우리는 다른 방식을 시도하고 있습니다.

대신, 각 에이전트는 관측한 사실이나 우려 사항을 공유 환경에 "흔적(페로몬)"으로 남깁니다. 다른 에이전트는 그 흔적을 나중에 읽어 들여 통합하고, 필요하다면 이슈(Issue)화하며, 나아가 또 다른 에이전트가 PR(Pull Request)을 생성합니다.

이와 같이 개체끼리 직접 통신하지 않고, 환경에 남긴 흔적을 통해 협조하는 메커니즘은 **stigmergy (스티그머지)**라고 불립니다. 이 사고방식을 소프트웨어 유지보수 운영을 위한 LLM 멀티 에이전트 워크플로우(Workflow)에 응용했습니다.

우리는 이 방식을 **고탄다식 에이전틱 워크플로우 (Gotanda-style agentic workflow)**라고 부르고 있습니다.

이는 단순한 이론상의 아이디어가 아닙니다. 우리는 이 방식을 이미 20만 행 규모의 Python 리포지토리(Repository) 유지보수 운영에 사용하고 있습니다. Sentry 알람이나 Datadog 메트릭스(Metrics)를 기점으로 페로몬을 침착시키고, 집약된 시그널로부터 이슈를 만들며, 나아가 자동 구현 가능한 것을 개선 PR로 변환하는 단계까지 실제로 작동하고 있습니다.

왜 유지보수 운영에 주목하는가

AI 에이전트는 새로운 코드를 작성하는 작업을 강력하게 지원합니다.

하지만 소프트웨어 개발 비용은 "코드를 작성하는 것"만이 아닙니다. 오히려 장기적으로는 다음과 같은 유지보수 운영 비용이 커집니다.

• 운영 환경 에러를 조사한다
• 성능 저하를 감지한다
• 테스트 부족을 보완한다
• 설계의 허점을 찾아낸다
• 의존 관계나 경계의 무너짐을 바로잡는다
• 작은 개선을 지속적으로 PR로 변환한다

AI가 코드를 작성하는 속도를 높일수록 이러한 유지보수 대상도 늘어납니다. 즉, AI 주도 개발을 진정으로 스케일(Scale)시키려면, 코드 생성의 자동화뿐만 아니라 유지보수 운영 그 자체를 에이전트화해야 합니다.

고탄다식 에이전틱 워크플로우는 이러한 문제 의식에서 탄생한 워크플로우입니다.

신기능의 의사결정을 AI에 전면 위임하는 것이 아니라, 유지보수 운영처럼 반복적이고 관측 가능한 영역을 여러 AI 에이전트로 지속적으로 뒷받침하는 것을 목표로 합니다.

왜 대화형 멀티 에이전트는 스케일하기 어려운가

멀티 에이전트라고 하면, 여러 전문 에이전트가 대화하며 문제를 해결하는 모습을 상상하기 쉽습니다.

예를 들어, 다음과 같은 구성입니다.

• Planner agent가 태스크를 분해한다
• Research agent가 조사한다
• Coding agent가 구현한다
• Reviewer agent가 리뷰한다
• Supervisor agent가 전체를 판단한다

이 구성은 작은 태스크에서는 잘 작동합니다. 실제로 현재의 많은 에이전트 프레임워크(Framework)도 Supervisor, handoff, router, subagent와 같은 패턴을 중심으로 설계되어 있습니다.

하지만 소프트웨어 유지보수 운영처럼 지속적이고, 비동기적이며, 대상 범위가 넓은 문제에서는 대화 중심의 협조에 몇 가지 약점이 있습니다.

• 에이전트 수가 늘어날수록 통신 그래프가 복잡해진다
• 각 에이전트가 다른 에이전트의 문맥을 읽어야 하므로 토큰 소비가 증가한다
• Supervisor에 정보가 집중되어 단일 장애점(Single point of failure)이 되기 쉽다
• 대규모 코드베이스에서는 모두가 동일한 정보를 읽는 것이 비효율적이다
• 일시적인 판단이나 노이즈가 대화 이력에 남아 후속 판단을 오염시키기 쉽다

인간 조직도 마찬가지입니다. 모든 구성원이 항상 회의를 통해 동기화하며 일하는 조직은 인원이 늘어날수록 느려집니다.

LLM 에이전트 (LLM Agent)에서도 모든 구성원을 대화하게 만드는 설계는 일정 규모를 넘어서면 협업 그 자체가 비용이 됩니다.

고탄다 방식 에이전틱 워크플로우 (Agentic Workflow): 대화가 아닌 환경을 통해 협업하기

고탄다 방식 에이전틱 워크플로우 (Agentic Workflow)의 기본 방침은 심플합니다.

에이전트끼리 대화하지 않고, 공유 환경에 남겨진 흔적(페로몬)을 바탕으로 연계한다

각 에이전트는 자신의 담당 영역만을 관측합니다. 그리고 발견한 시그널 (Signal)을 공유 환경에 기록합니다.

우리는 이 공유 환경을 pheromone field라고 부릅니다. 일본어로는 「페로몬 장」입니다.

예를 들어, 다음과 같은 에이전트들이 있습니다.

• Sentry worker: 실행 시 에러를 관측함
• Datadog worker: 느린 요청, 느린 SQL, 5xx, 비용 급증 (Cost spike) 등을 관측함
• Quality worker: 레이어링 위반, 예외 처리 누락, 테스트 부족, API 계약 불일치 등을 탐색함
• Refactor worker: 페로몬 장을 읽고, 여러 관측 결과를 통합하여 이슈 (Issue)화함
• Code worker: Gotanda 라벨이 붙은 이슈를 구현하고 PR (Pull Request)을 생성함

중요한 점은 관측 계열의 worker가 직접 이슈를 난립시키지 않는 것입니다.

Sentry worker는 "이 파일에서 에러가 발생하고 있다"라는 흔적을 남깁니다. Datadog worker는 "이 엔드포인트가 느리다"라는 흔적을 남깁니다. Quality worker는 "이 함수에는 예외 처리 문제가 있을 것 같다"라는 흔적을 남깁니다.

이것들을 직접 대화로 조정하는 것이 아니라, Refactor worker가 나중에 집약된 페로몬 장을 읽습니다.

이 흐름은 다음 3단계로 나뉩니다.

• Observer: 외부 세계나 코드베이스를 관측하고 페로몬을 침착시킴
• Integrator: 페로몬 장을 읽고, 여러 시그널을 통합하여 이슈화함
• Implementer: 자동 구현 가능한 이슈를 PR로 변환함

Sentry worker ----+
Datadog worker ----+--> Pheromone field --> Refactor worker --> GitHub Issue --> Code worker --> Pull Request
Quality worker ----+

페로몬이란 무엇인가

페로몬은 에이전트가 공유 환경에 남기는 구조화된 시그널 (Signal)입니다.

최소한의 모델은 다음과 같습니다.

(scope, location, worker, strength, half_life, metadata)

각각의 의미는 다음과 같습니다.

• scope: 시그널의 입도 (Granularity). file, function, endpoint, sql 등
• location: 실제 위치. 파일 경로, 함수명, API 경로, SQL fingerprint 등
• worker: 어떤 에이전트가 침착시켰는가
• strength: 얼마나 강한 시그널인가
• half_life: 어느 정도의 시간 동안 약해지는가
• metadata: 에러 유형, 환경, 근거, 분류 등의 추가 정보

예를 들어, Sentry worker가 운영 에러를 발견했을 경우 다음과 같은 페로몬을 침착시킵니다.

{
"scope": "file",
"location": "app/services/invoices.py",
...
}

Quality worker가 동일한 파일에서 테스트 부족을 발견했을 경우, 다른 페로몬을 침착시킵니다.

{
"scope": "file",
"location": "app/services/invoices.py",
...
}

Refactor worker는 개별적인 침착이 아니라, 집약된 페로몬 장을 읽습니다.

동일한 장소에 여러 worker로부터 시그널이 모여 있다면, 그곳은 우선적으로 살펴봐야 할 핫스팟 (Hotspot)입니다.

양의 페로몬과 음의 페로몬

고탄다 방식 에이전틱 워크플로우에서는 페로몬이 양수 값만 존재하는 것은 아닙니다.

양의 페로몬은 "이곳을 봐야 한다"라는 유인 시그널입니다.

반면, 음의 페로몬은 "이곳은 한 번 검토했지만, 지금은 추적하지 않는다"라는 억제 시그널입니다.

예를 들어, Refactor worker가 어떤 후보를 조사하고 "이것은 설계상 허용된다", "지금은 수정하지 않는다"라고 판단한 경우, 음의 페로몬을 침착할 수 있습니다.

{
"scope": "fingerprint",
"location": "layering_violation:abc123",
...

이를 통해 동일한 후보가 반복해서 Issue화되는 것을 방지할 수 있습니다.

단, 음의 페로몬은 영구적으로 남는 것이 아닙니다. 시간이 흐름에 따라 감쇄합니다. 만약 훗날 Sentry나 Datadog으로부터 강한 시그널이 다시 침착된다면, 그 장소는 다시 주목받게 됩니다.

이 "한 번 Won't Fix로 처리했지만, 상황이 변하면 다시 부상한다"라는 성질은 유지보수 운영에서 매우 중요합니다.

왜 이 방식은 스케일하기 쉬운가

1. 에이전트 수를 늘려도 통신량이 폭발하기 어렵다

대화형 설계에서는 에이전트 수가 늘어날수록 누가 누구에게 무엇을 전달할지가 문제가 됩니다.

고탄다 방식의 에이전틱 워크플로우 (Agentic Workflow)에서는 각 에이전트가 다른 에이전트를 알 필요가 없습니다. 공유 환경에 대해 정해진 형식으로 시그널을 기록할 뿐입니다.

새로운 worker를 추가할 때도 필요한 것은 "어떤 페로몬을 침착할 것인가"라는 계약입니다.

이는 플러그인 방식과 같습니다.

Security worker를 추가하고 싶다면 보안 관점의 시그널을 침착하면 됩니다. Performance worker를 추가하고 싶다면 성능 관점의 시그널을 침착하면 됩니다.

Refactor worker는 그것들을 동일한 페로몬 장(field)의 일부로서 읽을 수 있습니다.

2. 대규모 코드베이스를 효율적으로 탐색할 수 있다

대규모 코드베이스에서는 매번 모든 파일을 읽는 것이 현실적이지 않습니다.

중요한 것은 한정된 탐색 예산을 어디에 사용할 것인가입니다.

페로몬 장이 있으면 탐색은 완전한 랜덤도, 단순한 최근 파일 (recent files) 편중도 아니게 됩니다.

• 최근에 변경된 파일을 본다
• 무작위로 일부를 본다
• Sentry나 Datadog이 나타낸 핫스팟 (hotspot)을 본다
• 과거에 음의 페로몬이 강했던 곳은 우선순위를 낮춘다
• 여러 worker가 같은 장소에 침착하면 우선순위를 높인다

이와 같이 관측 결과에 따라 탐색 예산을 동적으로 배분할 수 있습니다.

이는 대규모 코드베이스에 대한 "AI에 의한 지속적인 유지보수 탐색"과 궁합이 좋습니다.

3. 토큰 효율이 좋다

에이전트끼리 긴 대화를 나누지 않기 때문에, 타 에이전트의 상세한 사고 과정이나 대화 이력을 읽을 필요가 없습니다.

공유되는 것은 구조화된 작은 시그널입니다.

{
"scope": "endpoint",
"location": "GET /api/reports",
...

이는 수천 토큰의 대화 로그보다 훨씬 저렴합니다.

필요할 때만 Integrator가 코드나 로그를 심층 분석합니다.

4. 비동기로 동작시킬 수 있다

모든 worker가 동일한 타이밍에 동작할 필요는 없습니다.

Sentry worker는 10분마다, Datadog worker는 하루에 한 번, Quality worker는 야간에, Code worker는 5분마다와 같은 운용이 가능합니다.

각 worker는 자신의 페이스에 맞춰 환경을 관측하고 페로몬을 침착합니다.

이는 실운영에서 큰 이점입니다. 외부 API, CI, GitHub, Sentry, Datadog 등은 각각 레이트 리밋 (rate limit)이나 실패 특성이 다릅니다. 각 worker를 독립적으로 동작시킬 수 있으면 장애가 국소화되기 쉽습니다.

5. 노이즈를 시간으로 감쇄시킨다

LLM 에이전트의 판단에는 노이즈가 있습니다.

어떤 worker가 단 한 번 약한 시그널을 냈다고 해서, 그것이 즉시 Issue가 되어야 하는 것은 아닙니다.

고탄다 방식의 에이전틱 워크플로우에서는 페로몬이 시간과 함께 감쇄합니다.

단 한 번의 약한 시그널은 자연스럽게 사라집니다. 여러 번 관측되는 시그널, 여러 worker로부터 모이는 시그널, 운영 환경에 영향을 주는 시그널은 강하게 남습니다.

이러한 성질 덕분에 단발성 노이즈보다 지속적인 문제를 우선시하기 쉬워집니다.

단순한 합계만으로는 부족하다

여기서 주의가 필요합니다.

페로몬을 단순히 합산하기만 하면 중요한 정보를 잃을 수 있습니다.

예를 들어, 어떤 장소에 다음과 같은 두 가지 시그널이 있다고 가정해 봅시다.

sentry-worker: +2.0
refactor-worker: -2.0

단순 합계는 0입니다.

하지만 이것은 "아무 일도 일어나지 않는 장소"가 아닙니다.

실제로는 "운영 환경에서 에러가 발생하고 있지만, 과거에는 Won't Fix(수정하지 않음)로 판단된 사례도 있는" 충돌 상태입니다.

이 두 가지를 동일한 0으로 취급하면 중요한 후보를 놓치게 됩니다.

따라서 고탄다 방식의 에이전틱 워크플로우 (Agentic Workflow)에서는 양(+)의 성분, 음(-)의 성분, 총 변동량, 충돌률을 나누어 다룹니다.

current_strength : 순수 강도 (Net strength)

• positive_strength : 양의 시그널 양
• negative_mass : 음의 시그널 양
• total_variation : 양과 음을 상쇄하지 않은 총량
• conflict_ratio : 양과 음이 어느 정도 충돌하고 있는가

수학적인 상세 내용은 부록으로 넘기겠지만, 실무적인 의미는 단순합니다.

침묵과 충돌을 구분한다.

이를 통해 Refactor worker는 다음과 같은 판단을 할 수 있습니다.

• 강한 양의 시그널만 있는 경우: 자동 구현 후보일 수 있음
• 강한 음의 시그널만 있는 경우: 지금은 추적하지 않음
• 양과 음이 강하게 충돌하는 경우: 인간 리뷰 (Human Review)로 넘겨야 할 수도 있음
• 아무것도 없는 경우: 탐색 우선순위를 낮춤

고탄다식 에이전틱 워크플로우에서의 Issue화에 대한 사고방식

고탄다식 에이전틱 워크플로우에서는 관측 worker가 직접 Issue를 만드는 것을 가급적 피합니다.

이유는 관측 시점에는 문맥 (Context)이 부족한 경우가 많기 때문입니다.

Sentry worker는 에러를 알고 있습니다. 하지만 그것이 국소적 수정으로 끝날 문제인지, 설계 변경이 필요한지, 혹은 이미 알고 있는 허용 사례인지까지는 판단할 수 없습니다.

Datadog worker는 느린 SQL을 알고 있습니다. 하지만 그 SQL이 정말 문제인지, 배치 처리로서 허용되는 것인지, 상위의 업무 요구사항까지 포함하여 판단하는 것은 어렵습니다.

Quality worker는 레이어링 위반 (Layering violation) 같은 것을 찾아냅니다. 하지만 예외적으로 허용된 설계일 수도 있습니다.

따라서 관측 worker는 원칙적으로 페로몬을 침착시키는 역할만 수행합니다.

Issue화는 Integrator로 집약합니다.

Integrator는 여러 개의 페로몬, 현재의 코드, 기존 Issue, 과거의 Won't Fix 판단을 보고 종합적으로 판단합니다. 이를 통해 모순된 Issue 생성이나 중복된 생성을 피할 수 있습니다.

Issue는 다음과 같이 분류합니다.

분류	의미	전달 대상
A	문제 없음, 또는 이미 알고 있는 허용 사례	생성하지 않음
...	...	...

Code worker에게 흘려보내는 것은 B1뿐입니다.

이는 안전성을 위해서입니다. 자동 구현 에이전트에게 전달하는 Issue는 의도가 명확하고, 수정 범위가 한정되어 있으며, PR (Pull Request)로부터 Issue의 의도를 역으로 읽어낼 수 있는 입도 (Granularity)를 가져야 합니다.

큰 설계 판단은 인간이 수행합니다. 인간이 한 번 방침을 결정하면, 그 이후의 국소적인 적용 작업은 Code worker로 분해할 수 있습니다.

실제 운용

고탄다식 에이전틱 워크플로우는 20만 행 규모의 Python 리포지토리 유지보수에 적용하고 있습니다.

AWS EC2 위에 구축하였으며, 각 에이전트는 Docker 컨테이너 위에서 동작합니다.

페로몬 장 (Pheromone field)은 Postgres를 사용하여 에이전트가 읽고 씁니다.

에이전트로부터의 보고는 Slack으로 통지되도록 하여 인간이 언제든 볼 수 있게 하고 있습니다.

Issue나 PR을 생성하면 담당 인간에게 멘션합니다.

Code Worker가 생성한 PR은 단순히 생성하는 것에 그치지 않고, CI 실행이나 bot 리뷰까지 모니터링하며, CI가 완전히 통과하고 bot 리뷰 지적 사항이 모두 해결될 때까지 대응합니다. 이를 통해 인간이 PR을 리뷰할 때는 일정 수준의 품질이 유지되도록 하고 있습니다.

모든 것은 자율적이며, 인간의 손을 거치지 않고 유지보수 루프가 돌아가도록 설계되었습니다.

과제

물론 이 방식에도 어려움은 있습니다.

가장 큰 과제는 페로몬 장의 품질입니다.

페로몬 장이 노이즈로 가득 차게 되면 시스템 전체가 노이즈에 끌려가게 됩니다. 반대로 억제력이 너무 강하면 정말 중요한 문제를 놓치게 됩니다.

특히 어려운 점은 다음과 같습니다.

location의 정규화

같은 장소를 가리키고 있음에도 worker마다 서로 다른 location으로 침착해 버리면 시그널이 집약되지 않습니다.

예를 들어, 동일한 API를 다음과 같이 각각 다르게 표현하는 경우입니다.

GET /api/users/{id}
/api/users/:id
app/api/users.py:get_user

이것들을 어디까지 동일시할 것인가는 설계상 매우 중요합니다.

strength의 교정

Sentry의 운영(Production) 에러 +2.0

과 Quality worker의 낮은 신뢰도에 대한 우려 +0.5

는 같은 가중치를 갖지 않습니다.

worker별 신뢰도, 카테고리별 중요도, 환경별 영향도를 어떻게 가중치에 반영할지는 지속적인 조정이 필요합니다.

부(負)의 페로몬의 의미론

부의 페로몬은 편리하지만 위험하기도 합니다.

'지금은 쫓지 않는다'와 '영구히 무시한다'는 다릅니다.

따라서 부의 페로몬에는 이유, 대상 fingerprint, 반감기, 재부상 조건이 필요합니다.

감사성 (Auditability)

자동화가 진행될수록, 왜 그 Issue가 생성되었는지, 왜 그 PR이 생성되었는지를 추적할 수 있어야 합니다.

페로몬의 침착 이력, worker run, 관련 Issue, 관련 PR을 따라갈 수 있도록 하지 않으면 운영에서 신뢰받을 수 없습니다.

에이전트를 관리하는 관리 화면도 향후 정비할 필요가 있을 것입니다.

사활 감시 (Liveness Monitoring)

자율형 에이전트가 올바르게 작동하고 있는지, PR 생성 도중에 중단되거나, 토큰 만료로 인해 멈추지는 않았는지.

감시를 수행하는 메커니즘을 만들고, 크래시 복구 (Crash Recovery) 방법도 갖추어야 합니다.

향후 하고 싶은 것

고탄다 방식의 에이전틱 워크플로우 (Agentic Workflow)는 아직 발전 단계에 있습니다.

향후 특히 중요하다고 생각하는 영역은 다음과 같습니다.

• worker별 신뢰도 가중치
• 카테고리별 가중치
• location alias의 정규화
• run_id에 의한 감사 로그
• self-stop 조건
• 카나리 (Canary) 운용
• human-in-the-loop의 경계 설계
• 페로몬 장 (Pheromone field)을 사용한 탐색 대상의 재배분

특히, 페로몬 장을 '읽는' 것뿐만 아니라, 다음 탐색 범위 그 자체에 반영하는 것이 중요합니다.

예를 들어, Quality worker가 완전히 무작위로 탐색하는 것이 아니라, 다음과 같이 탐색 예산을 분배합니다.

• recent files: 40%
• random files: 30%
• pheromone hotspot: 20%
• cooling follow-up: 10%

이렇게 하면 탐색은 무작위성을 유지하면서도 과거의 관측 결과에 적응할 수 있습니다.

요약

LLM 멀티 에이전트 시스템에서는 에이전트를 어떻게 협조시킬 것인가가 본질적인 과제입니다.

대화형 협조는 이해하기 쉽지만, 에이전트 수, 코드베이스 규모, 운용 기간이 커질수록 통신 비용과 문맥 관리 (Context Management) 비용이 무거워집니다.

고탄다 방식의 에이전틱 워크플로우에서는 에이전트끼리 직접 대화하게 하지 않습니다.

대신, 각 에이전트는 공유 환경에 페로몬을 침착합니다. 다른 에이전트가 그것을 읽고, 통합하고, Issue화하며, 자동 구현 가능한 것만을 PR로 변환합니다.

우리는 이 방식이 소프트웨어 유지보수 운용에 있어 AI 에이전트의 유력한 설계 패턴이 될 가능성이 있다고 생각합니다.

AI 에이전트에 의해 개발 속도가 올라간다면, 그에 비례하여 유지보수 운용도 강력해져야 합니다. 코드를 쓰는 에이전트뿐만 아니라, 코드베이스를 관측하고, 이상을 감지하며, 개선 후보를 통합하고, 안전한 입도의 Issue를 만들어 PR로 변환하는 에이전트 군단이 필요해집니다.

향후 더 많은 에이전트가 코드베이스를 지속적으로 관측하고, 개선하고, PR을 만들게 되면, 대화 중심이 아닌 협조 모델의 중요성은 더욱 커질 것입니다.

보충: 스티그머지 (Stigmergy)란 무엇인가

스티그머지는 생물학이나 군집 지능 (Swarm Intelligence)의 문맥에서 사용되는 개념입니다.

전형적인 예는 개미가 환경에 페로몬을 남기고, 다른 개미가 그 흔적을 따라감으로써 집단으로서 경로를 발견하는 현상입니다.

중요한 점은 개체들끼리 직접 상담하지 않는다는 것입니다.

개체는 환경을 읽고, 환경을 바꿉니다. 그 변경이 다른 개체의 행동을 바꿉니다.

고탄다 방식의 에이전틱 워크플로우에서는 코드베이스, 모니터링 데이터, Issue, PR, 페로몬 DB가 이 '환경'에 해당합니다.

보충: 어트랙터 엔지니어링 (Attractor Engineering)으로서

고탄다 방식의 에이전틱 워크플로우는 다르게 말하면, 코드베이스가 나쁜 어트랙터 (Attractor)를 향하지 않도록 하기 위한 실천적인 접근법입니다.

여기서 말하는 어트랙터란, 변경이 반복되는 동안 코드베이스가 자연스럽게 끌려가게 되는 구조나 상태를 의미합니다.

좋은 책임 경계, 좋은 타입, 좋은 테스트, 좋은 구현 사례가 있는 코드베이스에서는 다음 변경도 좋은 방향으로 수렴하기 쉽습니다. 반대로, 거대한 common

、모호한 service, 지나치게 편리한 helper, 나쁜 기존 구현이 근처에 있으면 변경 사항은 그쪽으로 끌려가기 쉽습니다.

AI 에이전트는 이러한 역학을 더욱 강화합니다.

AI는 진공 상태에서 코드를 작성하는 것이 아닙니다. 기존 코드, 주변 파일, 명명 규칙 (Naming), 테스트, 과거의 구현 사례, 문서를 읽고 그것들을 단서로 다음 패치 (patch)를 생성합니다. 즉, 코드베이스 전체가 AI에게는 프롬프트 (prompt)가 됩니다.

따라서 코드베이스에 나쁜 국소 문법이 있으면, AI는 그것을 자연스러운 해답으로 재생산하기 쉽습니다. 개발 속도가 빨라질수록 나쁜 어트랙터 (attractor)로 떨어지는 속도도 빨라집니다.

어트랙터 엔지니어링 (Attractor Engineering)이란, 이 "미래의 변경이 어디로 끌려갈 것인가"를 설계하는 사고방식입니다.

고탄다 방식의 에이전틱 워크플로 (Agentic Workflow)에서는 페로몬 장 (pheromone field)을 사용하여 다음과 같은 시그널을 관측합니다.

• 어떤 파일이나 엔드포인트 (endpoint)에 운영 에러가 집중되어 있는가
• 어디에서 성능 저하가 나타나고 있는가
• 어디에 테스트 부족이나 책임 경계의 붕괴가 있는가
• 어느 지점이 여러 워커 (worker)로부터 반복적으로 지적되고 있는가
• 어떤 후보가 과거에 Won't Fix로 판단되었는가
• 어느 지점에서 정(+)과 부(-)의 시그널이 충돌하고 있는가

이는 단순한 알람 집계가 아닙니다.

코드베이스가 어느 방향으로 흐르고 있는지, 어느 지점이 나쁜 **basin (끌림 영역)**이 되어가고 있는지를 관측하고, 필요에 따라 이슈 (Issue)나 PR (Pull Request)로서 궤도를 수정하는 메커니즘입니다.

codebase field
-> AI / human PR force
-> pheromone observation
...

이런 의미에서, 고탄다 방식의 에이전틱 워크플로는 "AI에게 코드를 많이 쓰게 하는 메커니즘"이 아닙니다.

AI가 고속으로 가하는 변경의 힘을, 나쁜 어트랙터가 아니라 유지보수 가능하고 관측 가능한 코드베이스로 향하게 하기 위한 운영 설계입니다.

보충: 수학적인 관점

페로몬 장은 직관적으로 (scope, location)별 가중치 시그널입니다.

보다 형식적으로는, 각 워커 (worker)가 (worker, scope, location)에 부호가 있는 가중치를 침착하고, 그것을 (scope, location)으로 집약합니다.

양(+)의 가중치는 유인, 음(-)의 가중치는 억제입니다.

시간 경과에 따라 각 가중치는 지수적으로 감쇠합니다.

current = strength * 0.5 ^ (elapsed / half_life)

단순 합계만으로는 정(+)과 부(-)가 상쇄된 충돌 상태를 놓치게 됩니다.

따라서 양의 성분, 음의 성분, 총 변동량, 충돌률을 유지합니다.

net = positive - negative
total_variation = positive + negative
conflict_ratio = 1 - abs(net) / total_variation

이 보조량을 통해 "아무것도 없는 곳"과 "강한 찬반이 충돌하고 있는 곳"을 구별할 수 있습니다.