Archon: AI 코딩을 결정론적 워크플로우로 바꾸는 하네스 빌더

Archon GitHub OpenGraph

AI 코딩 에이전트를 써보면 금방 느끼는 문제가 있다. 같은 질문을 던져도 매번 결과가 다르다. 어떤 날은 계획을 잘 세우고, 어떤 날은 바로 수정에 들어가고, 어떤 날은 테스트를 빼먹는다. 결국 사람은 매번 결과를 검토해야 하고, 에이전트는 편하지만 운영은 불안정해진다.

Archon은 이 문제를 정면으로 건드린다. README는 Archon을 “AI coding workflows를 위한 harness builder”라고 설명한다. 핵심은 모델을 더 똑똑하게 만드는 게 아니라, 개발 과정을 워크플로우로 고정해서 결과를 반복 가능하게 만드는 것이다.

1. Archon이 겨냥하는 문제

Archon이 노리는 대상은 단순히 “코드를 잘 쓰는 에이전트”가 아니다. 더 정확히는 에이전트가 매번 제멋대로 움직이는 운영 문제다.

README에 나온 문제의식은 꽤 분명하다.

계획을 건너뛴다
테스트를 빼먹는다
PR 설명이 템플릿을 무시한다
실행할 때마다 흐름이 달라진다

이건 AI의 지능이 부족해서가 아니다. 프로세스가 모델 내부에 숨어 있기 때문이다. Archon은 그 프로세스를 밖으로 꺼낸다. 사람이 YAML로 과정을 정의하고, AI는 각 단계에서만 지능을 발휘한다.

Archon 워크플로우 개념도

2. Archon의 핵심은 세 개다

제가 보기엔 Archon은 결국 세 가지로 요약된다.

구성요소	역할	비유
Command	단일 작업을 수행하는 markdown 지침	함수
Workflow	여러 command를 연결하는 YAML DAG	스크립트
Isolation	각 실행을 별도 worktree로 분리	샌드박스

README와 문서를 같이 읽으면 이 구조가 반복해서 드러난다.

Command: 한 번에 한 일만 한다

Command는 .archon/commands/ 아래의 markdown 파일이다. 즉, 코드가 아니라 문서로 된 작업 지시서다.

예를 들면 이런 식이다.

이 GitHub issue를 조사하라
관련 코드를 읽어라
결과를 artifact 파일로 남겨라

중요한 건 command가 앞뒤 단계 전체를 알 필요가 없다는 점이다. 한 단계만 잘하면 된다.

Workflow: command를 DAG로 묶는다

Workflow는 YAML 파일이다. nodes: 아래에 계획, 구현, 검증, 리뷰, PR 생성 같은 단계를 정의한다.

name: build-feature
nodes:
  - id: plan
    prompt: "Explore the codebase and create an implementation plan"

  - id: implement
    depends_on: [plan]
    loop:
      prompt: "Read the plan. Implement the next task. Run validation."
      until: ALL_TASKS_COMPLETE
      fresh_context: true

  - id: run-tests
    depends_on: [implement]
    bash: "bun run validate"

  - id: review
    depends_on: [run-tests]
    prompt: "Review all changes against the plan. Fix any issues."

여기서 중요한 건 AI가 아니라 그래프 구조다. 순서, 조건, 병렬성, 반복 조건이 명시된다. 그래서 같은 워크플로우는 같은 순서로 돈다.

Isolation: worktree가 실행 단위를 분리한다

Archon은 각 워크플로우 실행에 별도의 git worktree를 할당한다. 이건 꽤 큰 차이다.

작업끼리 충돌하지 않는다
병렬 실행이 가능하다
메인 브랜치를 덜 더럽힌다
실행 단위가 파일 시스템 레벨에서 분리된다

즉, Archon은 “에이전트에게 자유를 주는 도구”가 아니라 자유를 제한해서 결과를 안정화하는 도구에 가깝다.

3. 실제 동작 방식은 생각보다 단단하다

Archon 문서의 How Archon Actually Works를 보면 철학이 더 선명해진다.

Command는 원자, Workflow는 분자

문서는 command를 원자(atom), workflow를 **분자(molecule)**에 비유한다. 이 비유가 꽤 적절하다.

command = 한 가지 작업만 하는 최소 단위
workflow = command를 DAG로 조합한 실행 그래프
artifact = 단계 간 정보를 전달하는 파일

예를 들어 조사 단계는 investigation.md를 남기고, 구현 단계는 그 파일을 읽는다. 리뷰 단계는 implementation.md를 읽는다. 즉, 세션의 기억 대신 파일이 상태를 전달한다.

이건 AI 작업에서 굉장히 중요한 포인트다.

컨텍스트를 계속 누적시키는 대신, 필요한 정보를 artifact로 남기고 다음 노드는 fresh context로 시작한다.

fresh context는 노이즈를 줄인다

문서에서 반복해서 보이는 설정이 context: fresh다. 이건 다음 단계를 이전 단계의 긴 컨텍스트에서 분리한다.

좋은 점은 분명하다.

이전 단계의 잡음이 다음 단계에 섞이지 않는다
각 단계의 역할이 선명해진다
장기 실행에서 문맥 폭발을 줄인다

대신 trade-off도 있다.

앞 단계의 암묵적 맥락이 사라진다
중요한 정보는 반드시 artifact로 써야 한다
설계를 대충 하면 단계 간 손실이 생긴다

Archon은 이 trade-off를 숨기지 않는다. 오히려 파일로 명시하게 만든다.

4. 왜 이게 일반적인 에이전트와 다르게 느껴지나

한 줄로 말하면, 일반 에이전트는 “대화형 작업자”에 가깝고 Archon은 작업 공정 운영체계에 가깝다.

항목	일반적인 에이전트	Archon
실행 방식	프롬프트 중심	YAML 워크플로우 중심
상태 전달	대화 컨텍스트	artifact 파일
격리	종종 느슨함	git worktree 분리
반복성	높지 않음	높게 설계됨
사람 개입	수시로 필요	approval gate로 명시
배포면	단일 UI인 경우 많음	CLI / Web / Slack / Telegram / GitHub

이 비교에서 중요한 건 Archon이 “더 똑똑한 에이전트”를 약속하지 않는다는 점이다. 대신 같은 일을 같은 방식으로 반복하는 능력을 약속한다.

그 차이가 실무에선 훨씬 크다.

5. 실제로 어떤 일을 잘하나

README와 문서를 기준으로 보면 Archon이 잘 맞는 작업은 꽤 명확하다.

GitHub issue를 조사하고 수정하는 흐름
기능 아이디어를 구현해서 PR로 만드는 흐름
PR을 리뷰하고 수정하는 흐름
merge conflict를 정리하는 흐름
코드베이스 질문에 답하는 흐름

기본 워크플로우 예시도 이런 방향이다.

archon-fix-github-issue
archon-idea-to-pr
archon-pr-review
archon-resolve-merge-conflicts

즉, Archon은 범용 에이전트라기보다 소프트웨어 개발 절차를 자동화하는 레시피 엔진에 가깝다.

그리고 그 레시피를 CLI, Web UI, Slack, Telegram, GitHub에서 같은 구조로 돌린다. 이건 단순한 편의 기능이 아니라, 워크플로우를 플랫폼 독립적으로 유지하려는 설계다.

6. 기술적으로 눈여겨볼 지점

Archon에서 흥미로운 부분은 “AI가 뭘 하느냐”보다 “시스템이 AI를 어디에만 쓰느냐”다.

1) AI와 bash를 섞는다

워크플로우 노드는 prompt, command, bash를 모두 지원한다. 즉, 모든 걸 AI에게 맡기지 않는다.

계획은 AI에게
테스트는 bash에게
검토는 AI에게
승인 게이트는 사람에게

이 조합이 꽤 중요하다. 결정론적 작업은 결정론적으로, 추론이 필요한 부분만 AI가 맡는다.

2) 기본 워크플로우를 번들로 제공한다

문서에 따르면 Archon은 기본 워크플로우를 번들로 제공하고, repo 수준의 .archon/workflows/가 이를 덮어쓴다.

이건 사용성 면에서 좋다.

처음부터 설계하지 않아도 된다
기본값을 복사해서 커스터마이즈할 수 있다
팀 단위 표준 워크플로우를 버전 관리할 수 있다

3) 서버와 CLI의 파일 관점이 다르다

가이드에 따르면 CLI는 현재 작업 디렉토리의 파일을 보고, 서버는 workspace clone을 본다. 즉, 어디서 실행하느냐에 따라 관측 가능한 워크플로우 상태가 달라질 수 있다.

이건 사소해 보여도 중요하다. 운영 도구는 결국 이 차이 때문에 엇갈린다.

7. 그래도 그대로 믿으면 안 되는 부분

Archon은 방향이 좋지만, 만능은 아니다.

워크플로우 저작 비용이 있다

YAML과 command 파일로 과정을 명시해야 한다. 처음엔 귀찮다. 하지만 이 귀찮음이 없으면 결과도 매번 흔들린다.

fresh context는 장점이자 부담이다

컨텍스트를 비우는 건 좋지만, 정보 전달을 파일로 엄격하게 해야 한다. 설계가 허술하면 단계 간 정보 유실이 생긴다.

운영은 결국 사람의 책임이다

approval gate가 있어도, 누가 언제 승인하고 어떤 기준으로 검증할지는 팀이 정해야 한다. Archon은 그 책임을 없애지 않는다. 명시하게 만들 뿐이다.

모델 품질 문제는 사라지지 않는다

워크플로우가 좋아져도, 모델이 엉뚱한 판단을 하면 품질은 흔들린다. Archon은 지능을 대체하지 않는다. 지능의 사용 순서를 통제할 뿐이다.

8. 누구에게 맞는가

Archon은 모든 팀에 필요한 도구는 아니다. 하지만 아래 상황이라면 꽤 설득력이 있다.

에이전트 작업을 반복 가능한 공정으로 만들고 싶다
리뷰, 테스트, PR 생성이 항상 같은 순서로 돌게 하고 싶다
여러 프로젝트에서 같은 개발 절차를 재사용하고 싶다
CLI와 메시징 플랫폼을 같은 운영면으로 묶고 싶다
AI를 “대화 상대”가 아니라 “작업 엔진”으로 다루고 싶다

반대로 이런 경우라면 과할 수 있다.

단발성 PoC만 필요하다
워크플로우를 정의할 사람이 없다
사람 개입 없이 완전 자동화를 기대한다
팀이 아직 테스트/리뷰 규율을 갖추지 못했다

Archon은 자유분방한 에이전트보다 절차를 존중하는 팀에 더 잘 맞는다.

9. 한 줄 평가

내 평가는 이렇다.

Archon은 AI 코딩 에이전트를 더 똑똑하게 만드는 도구가 아니라, AI 코딩을 운영 가능한 공정으로 바꾸는 도구다.

그 차이는 작아 보이지만 실전에서는 크다.

prompt는 매번 다르다
workflow는 버전 관리된다
artifact는 추적된다
worktree는 격리된다
approval는 명시된다

결국 Archon이 보여주는 건 단순한 제품 하나가 아니다. 앞으로의 AI 코딩 경쟁은 모델 성능만이 아니라 작업을 어떻게 구조화하고 검증하느냐로 이동한다는 신호다.

🔗 관련 정보

GitHub: https://github.com/coleam00/Archon
README: https://github.com/coleam00/Archon/blob/dev/README.md
Docs: https://archon.diy
Architecture: https://archon.diy/docs/reference/architecture/
Workflow Guide: https://archon.diy/docs/guides/authoring-workflows/
How It Works: https://archon.diy/docs/book/how-it-works/