코딩 에이전트의 경쟁 축 변화와 Alysis Code의 설계

코딩 에이전트의 경쟁 축이 '단발성 코드 생성'에서 '계획 → 병렬 구현 → 검증 → 리뷰까지를 동일한 CLI로 닫는 것'으로 이동함에 따라, 샌드박스 기본 설정과 권한 모델이 신뢰의 분수령이 된다. — 그 설계를 BYO(Bring Your Own) 모델을 사용하는 로컬 CLI 형태로 두껍게 구현해 놓은 것이 Alysis Code (AlysisAi/alysis-code)이다. 영어 X에서는 작게 언급되었고, 일본어 독립 기사는 아직 거의 없다.

이번에 접한 Alysis Code는 'Everyone's coding agent'를 내세우는 로컬 CLI 코딩 에이전트다. README에는 계획을 검토된 코드 및 PR 준비 단계의 코드로 구현한다고 쓰여 있다. 모델은 직접 가져와 사용(Bring Your Own)하며, 샌드박스는 기본적으로 활성화되어 있다. Athens(그리스)의 독립 연구소 Alysis AI의 첫 제품으로, 개인 스크립트부터 팀 서버, CI까지 동일한 에이전트를 사용하는 위치를 점하고 있다.

검증 메모 (공개 README · Docs · Releases · GitHub 화면 · 검색 결과의 상대적 관측)

• 핵심은 Forge Mode. 요구사항을 받으면 모호할 경우 1~3개의 확인 질문을 한다. plan.json에 작업(task), 의존성(dependency), 쓰기 범위(write scope)를 저장하고, /execute plan으로 준비된 작업을 워커에게 병렬 분배한다. 작업별로 검증하며, 실패는 이슈(issue)로 다음 시도에 계승된다. 검증된 변경 사항은 시작 브랜치에 통합된다. 증적은 .alysis/runs/<run_id>/에 계획 · 로그 · 패치 · 검증 · 리뷰 형태로 남는다.
• **병렬 처리 (swarm)**는 Git worktree 또는 스냅샷 분리를 사용한다. write_scope나 estimated_files가 정확하고 상호 배타적일 때만 병렬화하기 쉽다고 명시했다. 디렉토리나 모호한 glob 패턴의 경우 단독 실행이 되기 쉽다고 밝히고 있다.
• PR 모드는 로컬의 브랜치 · 커밋 · 리뷰 · 검증 · 머지까지를 다룬다. 원격으로 푸시(push)하거나, 호스트형 PR을 생성하거나, 보호된 브랜치에 머지하는 것은 수행하지 않는다. 예: alysis forge swarm --parallel 3, alysis forge exec T01 --pr --review --verify strict.
• 권한은 readonly / review / auto / fullaccess가 있다. review가 안전한 기본값이며, 쓰기 작업과 shell 실행 전에 확인을 거친다. fullaccess에서도 denylist와 감사 로그(audit log)는 남는다. 페르소나는 code / architect / ask / debug이다.
• 샌드박스 기본 설정은 strict, backend=auto, network=off, 환경 변수 클리어, Git 메타데이터 보호를 한다. Linux는 Bubblewrap, macOS/Windows는 Docker 사용을 권장한다. sandbox가 사용할 수 없으면 호스트 shell로 폴백(fallback)하지 않고 fail-closed된다. rm -rf /, curl | sh, sudo 등은 fullaccess에서도 상시 거부된다. 검증 역시 strict sandbox가 기본이다.
• 주의점으로, sandbox의 대상은 shell/verification에 중점을 둔다. 커스텀 Python 도구의 subprocess는 자동으로 sandbox화되지 않는다고 한다. 또한, sandbox가 부정 코드를 안전하게 만드는 것은 아니라고 명시했다.
• 확장성은 Skills (SKILL.md), Plugins (alysis-plugin.toml), Hooks (PreToolUse / PostToolUse / PostWrite / SessionStart / SessionStop 등 11개 이벤트), 커스텀 Python tools (.alysis/tools/*.py, 프로젝트 도구는 파일 해시의 명시적 신뢰(trust) 필요), MCP (stdio와 Streamable HTTP)를 통해 가능하다. MCP는 시작 시점에 도구 카탈로그를 스냅샷하고 세션 중에는 고정된다. swarm worker · subagent · conflict resolver에게는 MCP를 공개하지 않는다.
• 모델 계층은 OpenAI / Anthropic / DeepSeek / Qwen / Gemini / Mistral / Xiaomi MiMo / OpenRouter / xAI 등이다. 로컬 환경에서는 Ollama / LM Studio / vLLM을 사용하며, 완전 오프라인 운영을 주장한다. API 키, Alysis 계정, 대응 AI 구독 서비스를 선택할 수 있다.

• 도입은 Python 3.11+에서 가능합니다. pipx install alysis-code → alysis-code (약칭 alysis) → chat / run / setup을 사용합니다. README는 macOS, Linux, Windows를 지원하지만, 공식 웹사이트 쪽은 Windows via WSL(Windows Subsystem for Linux)로 더 제한적입니다.
• 아키텍처는 Typer CLI, workspace binding, session runtime, model provider, tool assembly, approval/sandbox, local artifacts 등으로 구성되어 있습니다. 작업 디렉터리가 root 외부로 벗어날 수 없도록 workspace root를 고정하는 설계입니다. 긴 대화에서는 tool-output offload와 conversation compaction이 사용됩니다.
• 문서의 불일치: README는 기존의 /plan 채팅 기능을 삭제했다고 설명하는 반면, Docs 쪽에는 여전히 /plan <task> 등이 남아 있습니다. main 페이지에는 'Release v0.14.4 with IDE integrations…'(9/29)가 있지만, Releases의 최신 태그는 아직 v0.14.3입니다. 급속하게 개발 중인 흔적이 보입니다.

수치 (GitHub HTML · 공개 README · Releases · 검색 결과. API 미사용)

• 리포지토리: AlysisAi/alysis-code
• Stars: 166 / Forks: 19 / Watching: 0 / Open Issues: 3 / PRs: 5 / Commits: 67 / Contributors: 3 / Releases: 25
• 최신 릴리스: v0.14.3 (2026-09-28). Sonnet 계열의 네이티브 Messages, streaming, signed reasoning, hosted account의 prompt caching 자동 기본 설정 등이 포함되었습니다. prerelease가 아닌 안정 버전인 0.14.x입니다.
• 최신 커밋: 2026-09-29 23:55 JST 'Isolate checkpoint data-policy tests from worker startup timing'
• 언어: Python 약 85.5% / TypeScript 약 10.6% / JS · HTML · CSS · Shell 등
• 라이선스: Apache-2.0
• 공식 웹사이트와 연구소(Athens, Greece)를 공개하고 있습니다. 월 50 free credits를 게재했습니다. SWE-bench 등의 공개 승률/속도 비교는 README/Docs에서 찾을 수 없으며,
• 상대적 참여도 (로그인 없이 볼 수 있는 영어 X의 Google 색인): pengsonal의 소개가 70+ likes를 기록했으며, 공식 AlysisAI는 70+ 팔로워 규모입니다. 그 외에는 몇 개의 좋아요만 받은 소규모 게시물이 산발적으로 있습니다. 절대적인 폭발적 인기는 아니지만, 작은 계정 대비 두터운 초기 반응을 보이고 있습니다.
• 일본어 지연: Qiita / Zenn / note / はてな 계열의 exact-name 기사는 검색상 0건입니다. 상위는 공식 GitHub 및 공식 웹사이트 중심입니다. 독립적인 일본어 리뷰 공급은 거의 형성되지 않았습니다.

주의사항

• 'PR-ready', 'plans, builds, and ships'는 제품 설계상의 주장입니다. 공개 벤치마크가 없는 단계에서는 성능 실증보다는 워크플로우 구현으로 읽어야 합니다.
• sandbox는 shell/verification 중심입니다. 커스텀 도구나 모델 출력 자체를 안전하게 만드는 것은 아닙니다. fullaccess와 network 개방은 별개의 것으로 취급해야 합니다.
• Windows의 경우 README와 공식 웹사이트의 표현이 다릅니다. 실제 기기는 WSL을 전제로 시도하는 것이 더 안전합니다.
• Alysis 계정의 월별 크레딧은 호스트 측 과금 경계입니다. BYO key(Bring Your Own Key) 운영과 혼동해서는 안 됩니다.
• Docs의 /plan 설명이나 v0.14.4 미태그 등, 문서와 릴리스 간에 드리프트가 있습니다. 검증은 README + 최신 릴리스 노트를 기준으로 하는 것이 좋습니다.
• Stars가 세 자릿수 초반대이고 기여자(Contributors)가 3명입니다. 설계는 탄탄하지만, 커뮤니티 성숙도와 재현 실험의 깊이는 아직 얕습니다.

다음 액션 / OpenClaw

1. Python 3.11+ 환경에서 pipx install alysis-code를 실행합니다. 먼저 readonly 또는 review 모드로 alysis-code setup을 진행한 후, chat만 통과시킵니다.
2. sandbox backend(Bubblewrap / Docker)이 실제로 작동하는지 확인합니다. 작동하지 않으면 fail-closed가 되므로, 호스트 실행으로 넘어가지 않도록 설정된 상태를 유지하며 중단시킵니다.
3. 작은 실패 테스트 수정은 alysis-code run을 통해 단 한 번만 진행합니다. Forge / swarm / --pr 옵션은 write_scope를 좁게 제한한 후에 사용합니다.
4. MCP, 커스텀 Python tools, hooks는 명시적으로 trust 처리한 후에 적용합니다. swarm worker 측에 MCP가 올라가지 않는다는 전제하에 권한 경계를 설계합니다.
5. OpenClaw나 기존 CLI 에이전트가 있다면, Alysis를 '계획 및 병렬 검증의 실행 계층'으로, 상주 UI 또는 별도 에이전트를 '진입점(Entry)'으로 역할을 분할합니다. 모델은 처음부터 로컬(Ollama 등)이거나 단일 프로바이더로 고정하여 과금 경계를 섞지 않습니다.
6. 일본어 독립 기사가 나오기 시작하고 Stars가 급증하면 초기 단계에서는 한 발 물러섭니다. 현재의 우위는 '설계의 깊이 × 일본어 리뷰 공백'에 있습니다.

GitHub
AlysisAi/alysis-code

단발성 채팅으로 파일을 수정하는 단계를 넘어, '계획 - 병렬 - 검증 - 로컬 통합'까지 동일한 CLI에서 닫고 싶은 사람들에게 — Alysis Code는 BYO 모델과 fail-closed 사내 격리 환경(sandbox)을 전제로 한 Forge 구현을, Apache-2.0의 낮은 스타 수라는 여유로운 조건 속에서 먼저 접할 수 있는 주제가 됩니다. 영어권에서의 상대적 급증은 작고, 일본어 독립 공급이 비어있는 지금이야말로 검증의 기회입니다.