이 페이지는 영어 문서의 번역입니다. 명령, 식별자, 예제는 그대로입니다. 런타임 7.24.4 · SDK 2.6.7. 영어 원문

AX Code를 쓰는 이유

상태: 활성 범위: 현재 상태 최종 검토: 2026-08-25 담당: AX Code 유지관리자

대부분의 코딩 에이전트는 코드를 쓰는 순간을 최적화합니다. AX Code는 그다음 순간을 최적화합니다. 에이전트가 만든 결과를 남길지 결정하는 순간입니다.

AX Code가 최적화하는 것

에이전트 출력은 만들기는 싸고 검토하기는 비쌉니다. 에이전트가 세 모듈에 걸쳐 스무 개 파일을 건드리면, 검토자의 문제는 “이 줄이 맞습니까”가 아닙니다. “실제로 무엇을 했는가, 통과하는가, 되돌려야 하면 어떻게 되는가”입니다.

AX Code는 그 문제를 중심으로 만들어졌습니다.

증거. 모든 세션은 형식이 있는 이벤트 로그로 기록됩니다. 라우팅 결정, 모델 활동, 단계, 도구 호출, 도구 결과, 그리고 실행 중에 찍은 파일 스냅샷입니다.
검증. 게이트를 강제할 수 있는 곳에서는 저장소 자신의 검사가 결정합니다. Arena 후보와 게이트가 있는 리팩터 적용은 결과를 받아들이기 전에 typecheck, lint, 테스트를 실행합니다.
되돌릴 수 있음. 스냅샷 지점은 세션 단위만이 아니라 단계마다 복구할 수 있습니다. 같은 작업 디렉터리의 중첩 세션에 위임한 변경도 포함합니다.
사용자의 결정. AX Code는 순위를 매기고, 점수를 매기고, 보고합니다. 사용자를 대신해 병합하지는 않습니다.

누구를 위한 제품인가

주 대상:

영향이 큰 변경을 하는 시니어와 스태프 엔지니어
오픈 소스와 내부 플랫폼의 유지관리자
중간 규모에서 큰 Git 저장소를 운영하는 팀
리팩터, 마이그레이션, 모듈을 넘는 수정을 평가하는 엔지니어
사람이 나중에 감사해야 하는 무인 작업이나 예약된 에이전트 작업을 실행하는 사람

주 대상이 아님:

인라인 자동 완성을 원하는 사람
한 번의 짧고 버려도 되는 수정을 하는 사용자
완전히 관리되는 클라우드 위임을 우선하는 팀
Git을 쓰거나 저장소 검사를 실행할 생각이 없는 사람

그런 경우에는 더 가벼운 편집기 도우미가 정말로 더 나은 도구입니다. 이 페이지는 과장하기보다 그 사실을 말합니다.

어떻게 다른가

시간이 지나면 낡는 기능 목록 대신, 각 범주가 무엇을 최적화하는지를 적습니다.

범주	최적화 대상	AX Code가 다른 점
자사 모델 에이전트	한 모델의 경험을 처음부터 끝까지	AX Code는 모델에 얽매이지 않으며 기록을 로컬에 둡니다
편집기 에이전트	IDE 안의 대화형 흐름	AX Code는 입력 단계가 아니라 검토와 감사 단계를 겨냥합니다
가벼운 터미널 에이전트	속도와 단순함	AX Code는 검사할 수 있는 기록을 위해 개념을 더 받아들입니다
클라우드 에이전트	관리형 위임과 자율성	AX Code는 실행과 증거를 사용자 기계에 두며, 라이선스는 Apache-2.0입니다

AX Code가 제공하는 여러 능력은 2026년 현재 다른 곳에서도 널리 쓸 수 있습니다. 샌드박스, 체크포인트와 복원, MCP, 훅, 스킬, 서브에이전트, 워크트리 격리, 예약, 공급자 선택, 하나의 프롬프트를 여러 모델에서 실행하는 일입니다. 그 가운데 하나만으로는 AX Code를 고를 이유가 되지 않습니다.

다른 곳에서 모으기 더 어려운 조합은 다음과 같습니다. 격리된 후보 구현, 저장소 자신의 검사에 걸린 게이트, 검증을 우선하는 순위, 로컬에 남고 내보낼 수 있는 전체 실행 기록, 그리고 자동 병합이 없음입니다.

주장하지 않는 것

포지셔닝은 제품과 맞닿아도 버틸 때만 쓸모가 있습니다. 명시하면 다음과 같습니다.

replay는 재구성합니다. 다시 실행하지는 않습니다. 기록된 이벤트 스트림을 다시 조립하고 검증합니다. 모델, 도구, 바깥 세계를 다시 실행하지는 않습니다.
risk는 결정론적 휴리스틱입니다. 변경량, 검증 상태, 도구 실패, 건드린 경로, 보안에 민감한 파일 패턴으로 계산합니다. 확률도, 보정된 신뢰도도, 보안 보증도 아닙니다.
branch는 세션 상태를 분기합니다. Git 브랜치나 워크트리가 아닙니다. Arena가 Git 워크트리 구현 경로입니다.
compare는 실행을 비교합니다. 소스 코드가 아닙니다. 위험, 결정 경로, 이벤트 수를 보고합니다. 코드 diff 뷰어가 아닙니다.
검증 게이트는 보편적이지 않습니다. Arena 후보와 게이트가 있는 리팩터 적용에 해당합니다. 일반적인 대화형 편집은 자동으로 검증되지 않습니다.
AX Wiki 산문은 인용된 소스에서 모델이 생성합니다. 그 주변의 계획, 검증, 점진적 갱신, 보호된 구역의 프레임워크는 결정론적입니다.
CLI 브리지의 가시성은 부분적입니다. AX Code는 자신의 도구 실행을 전부 기록합니다. 벤더 CLI 프로세스 안에서 일어나는 작업은 그 브리지의 출력을 통해서만 보입니다.
일부 능력은 선택입니다. workflow 런타임에는 AX_CODE_WORKFLOW_RUNTIME=1가 필요합니다.

출처를 있는 그대로

AX Code는 MIT 라이선스의 OpenCode 코드베이스에서 시작했습니다. 그 사실은 NOTICE에 보존되어 있고, 묻어두지 않고 README에도 적혀 있습니다.

DEFAI가 그 기반 위에 만든 것이 이 페이지의 주제입니다. 실행 증거 계층, 섀도 워크트리 검증이 있는 결정론적 디버그와 리팩터 엔진, 코드 인텔리전스 그래프와 영향 분석, council과 arena 실행 모드, AX Wiki 컴파일러, OS 수준 샌드박스, AX Code Desktop입니다.

프로젝트와 통합하는 것은 그 프로젝트에서 파생하는 것이 아닙니다. README의 출처 절과 NOTICE는 Apache-2.0 4(d)절의 라이선스 의무를 전달하기 위해 있습니다. AX Code가 실제로 복사하고 재배포하는 업스트림만 나열합니다. AX Code가 단지 대화하는 프로젝트는, 브리지를 만들면서 아무리 자세히 살펴보았더라도 거기에 나열되지 않습니다. CLI 공급자가 가장 분명한 경우입니다. Claude Code, Codex CLI, Grok Build CLI, Muse Code CLI는 AX Code가 그 로컬 바이너리를 호출하고 로그인 세션을 재사용하기 때문에 공급자 표에 이름이 있습니다. 그 코드가 여기에 실리기 때문이 아닙니다. packages/ax-code/src/provider/ 안의 모델 ID 패턴, 능력 표, 벤더별 구문 분석은 AX Code 자신의 상호 운용 논리입니다. 정말로 그대로 파생된 파일에는 업스트림의 이름을 적는 한 줄짜리 출처 머리글이 있으므로, 감사에서 의도적인 재사용과 놓친 정리를 구분할 수 있습니다.

실행 증거 — 실행을 검토할 수 있게 하는 명령
검증된 다중 모델 변경 — council과 arena
여기서 시작 — 제품의 사고 모델