비교
손으로 유지하는 하니스 구성 및 다른 구성 방식과 비교해 Apothem을 평가하는 방법을 기능 매트릭스와 하니스별 페이지와 함께 설명합니다.
Apothem은 호스트 비종속 AI 하니스 구성 관리자입니다.
~/.config/apothem/profile.yaml에 있는 하나의 공유 프로필이 열일곱 개의
하니스 네이티브 구성 표면으로 머티리얼라이즈됩니다. 이 섹션은 이미 사용 중인
대안과 비교해 Apothem을 평가하는 틀을 제시합니다.
Apothem 비교
이 페이지의 동종 도구 관련 사실은 2026-10-02 기준이며, 각 프로젝트 자체의 README 또는 문서에서 읽은 것입니다(출처 참조). 마이너 릴리스마다 다시 확인하세요.
다른 도구들은 이 문제의 인접한 일부를 해결합니다. chezmoi나 GNU Stow 같은 파일 기반 구성 관리자는 파일을 배치하고, 링크하고, 템플릿화하지만, 하나의 소스를 각 하니스의 네이티브 구성 스키마로 번역하지는 않습니다. 도구 간 동기화 CLI는 하나의 소스에서 도구별 파일을 생성합니다. rulesync는 MCP, 무시 파일, 권한, 리뷰 검사를 추가하는 동기화 단위 전반에 걸쳐 60개 코딩 도구와 두 개의 개방형 표준을 위한 네이티브 구성을 생성하지만, 이 중 어느 것도 Apothem 매니페스트가 동기화하지는 않습니다. Apothem은 MCP 서버를 프로필에서 렌더링하며, 이를 작성하는 어댑터의 머티리얼라이저를 통해 수행합니다. ruler는 하나의 .ruler/ 디렉터리를 33개 대상에 배포하며, 규칙을 각 도구의 지침 파일에 이어 붙이고 MCP 서버, 스킬, 서브에이전트를 네이티브 구성으로 변환합니다. Apothem의 차별점은 동기화와 함께 제공되는 거버넌스 및 라이프사이클 규율입니다. 즉, 기계화된 적합성 게이트, 결정적 파이프라인, 감사 요새, 그리고 되돌릴 수 있고 검증된 라이프사이클입니다.
| 기능 | Apothem | 파일 구성 관리자(chezmoi, Stow) | rulesync | ruler |
|---|---|---|---|---|
| 하나의 소스에서 여러 도구의 네이티브 스키마로 | 예 — 열일곱 개 하니스 어댑터 | 아니요 — 복사, 심볼릭 링크 또는 템플릿, 번역 없음 | 예 — 60개 도구와 AGENTS.md 및 Agent Skills 표준 | 부분적 — 규칙은 각 도구의 지침 파일에 이어 붙이고, MCP, 스킬, 서브에이전트는 네이티브 형식으로 작성 |
| 동기화 단위 | 규칙, 스킬, 서브에이전트, 슬래시 명령, 훅, 출력 스타일, 상태 표시줄, 템플릿, 적합성 검증기, 스키마, 하니스별 지침 템플릿, Claude Code 설정 템플릿 | 임의의 파일 | 규칙, 무시 파일, MCP, 명령, 서브에이전트, 스킬, 훅, 권한, 검사(코드 리뷰 검사 지침) | 규칙, MCP, 스킬, 서브에이전트 |
| 거버넌스 코퍼스(동작 규칙과 기계적 적합성 게이트) | 예 — python -m apothem.conformity.gate | 아니요 | 아니요 — checks 기능은 코드 리뷰 검사를 도구로 동기화하며, 규칙에 대한 적합성 게이트는 없음 | 아니요 |
| 결정적 계획 및 리서치 파이프라인 | 예 — /plan-spec부터 /plan-execute까지, 13단계 /research | 아니요 | 아니요 | 아니요 |
| 탐지하고 시정하는 감사 요새 | 예 — 11개 명령 스윕, /fortress 재감사 루프 | 아니요 | 아니요 | 아니요 |
| 세션 간 영속 메모리 | 예 — 설치 시 생성되는 Apothem 데이터 홈 아래의 memory/records.json 저장소 | 비교하지 않음 | README에 명시되지 않음 | README에 명시되지 않음 |
| 공급망 강화 릴리스 | 예 — SBOM, Sigstore, SLSA, Scorecard 목표 | 비교하지 않음 | README에 명시되지 않음 | README에 명시되지 않음 |
| 가역적이고 검증된 라이프사이클 | 예 — 백업, apothem verify --json, 고아 파일이 남지 않는 제거 | chezmoi: chezmoi verify가 모든 대상을 검사함, Stow: 심볼릭 링크만 | README에 명시되지 않음 | .bak 백업과 ruler revert, README에 검증 명령 없음 |
동종 도구가 더 강한 지점은 이름을 밝혀 적습니다. rulesync는 세 배가 넘는 수의 도구에 도달하고 MCP, 무시 파일, 권한, 리뷰 검사를 동기화하는데, 이는 Apothem 매니페스트가 하지 않는 일입니다. ruler는 거의 두 배의 도구에 도달하며 자체 되돌리기 명령을 갖추고 있습니다. Apothem은 원시 도구 수를 내주는 대신 동기화 주위에 함께 제공되는 거버넌스, 감사, 라이프사이클 규율 — 적합성 게이트, 결정적 계획 및 리서치 파이프라인, 11개 명령으로 이루어진 감사 요새, 영속 메모리, 그리고 가역적이고 검증된 라이프사이클 — 을 택하며, 두 동기화 도구 모두 이를 갖추고 있지 않습니다.
출처
모든 항목은 2026-10-02에, 그날 각 프로젝트의 최신 릴리스를 기준으로 조회했습니다. rulesync와 ruler의 README는 영속 메모리 행을 확인하기 위해 2026-10-15에 다시 읽었으며, 어느 쪽도 메모리 기능을 언급하지 않습니다.
- rulesync(npm
rulesync): README (지원 도구 표: 60개 코딩 도구와 두 개의 개방형 표준)와 파일 형식 레퍼런스 (checks기능). - ruler(npm
@intellectronica/ruler): README (지원 에이전트 표,--backup,revert). - chezmoi: 홈페이지와
chezmoi verify. - GNU Stow: 프로젝트 페이지 ("심볼릭 링크 팜 관리자").
비교 방법
세 가지 축을 따라 비교하세요.
- 진실 공급원. 규칙, 에이전트, 명령, 설정은 어디에 있습니까? Apothem은 하나의 공유 코퍼스를 유지하고 그로부터 각 하니스의 네이티브 형식을 렌더링합니다. 손으로 유지하는 구성은 도구마다 사본을 하나씩 둡니다.
- 드리프트 비용. 규칙을 바꾸면 무슨 일이 일어납니까? Apothem은
apothem update시 설치된 모든 하니스로 변경을 전파합니다. 손으로 유지하는 구성에서는 각 도구의 네이티브 파일을 따로 편집하고 기억에 의존해 서로 맞춰 두어야 합니다. - 검증. 각 하니스가 올바르게 구성되었는지 어떻게 알 수 있습니까? Apothem은
apothem verify --harness <name>과apothem doctor를 제공합니다. 손으로 유지하는 구성에는 내장 검증이 없습니다.
기능 매트릭스
이 매트릭스는 운영자가 가장 먼저 찾는 두 가지 대안, 즉 각 하니스의 네이티브 구성을 손으로 유지하는 방식과 그 파일들을 범용 dotfile 관리자로 관리하는 방식에 Apothem을 대비합니다.
| 기능 | 손으로 유지하는 구성 | dotfile 관리자 | Apothem |
|---|---|---|---|
| 단일 공유 진실 공급원 | 아니요(도구마다 사본 하나) | 아니요(프로필이 아닌 파일을 추적) | 예(프로필 하나) |
| 하니스 네이티브 형식 렌더링 | 수동 | 아니요 | 예(어댑터별 머티리얼라이저) |
| 하니스 간 드리프트 방지 | 수동 정렬 | 파일 동기화만 | 예(apothem update) |
| 하니스별 설치/제거 | 수동 | 부분적(심볼릭 링크/복사) | 예(install / uninstall) |
| 내장 검증 | 없음 | 없음 | 예(verify / doctor) |
| 도구별 형식 번역 | 없음 | 없음 | 예(.mdc, .toml, 임베디드 .md) |
| 하나의 입력에서 열일곱 개 하니스 | 아니요 | 아니요 | 예 |
비교 페이지
- Apothem과 다른 하니스 프레임워크 비교
- 순수 antigravity와 비교
- 순수 claude-code와 비교
- 순수 codebuddy와 비교
- 순수 codex와 비교
- 순수 cursor와 비교
- 순수 gemini-cli와 비교
- 순수 github-copilot과 비교
- 순수 glm과 비교
- 순수 hermes와 비교
- 순수 kimi-code와 비교
- 순수 kiro와 비교
- 순수 open-claw와 비교
- 순수 opencode와 비교
- 순수 qwen-code와 비교
- 순수 trae와 비교
- 순수 windsurf와 비교
- 순수 zed와 비교
하니스별 어댑터 세부 사항은 하니스 어댑터 섹션을 참조하세요.