ECC

Claude Code 같은 AI 코딩 에이전트에 "계획 → 테스트 → 구현 → 리뷰 → 검증 → 기억"이라는 개발 절차를 한 번 설치해 두고, 매 프롬프트마다 다시 설명하지 않아도 에이전트가 그 절차대로 일하게 만드는 오픈소스 하네스 확장 시스템입니다.

• 절차를 설치물로 만든다: 계획·TDD·리뷰 같은 개발 습관을 프롬프트가 아니라 파일(Agent, Skill, Hook)로 고정합니다.
• 컨텍스트를 아낀다: 항상 필요한 것(Rule)과 필요할 때만 부르는 것(Skill, Agent)을 분리해 컨텍스트 창을 절약합니다.
• : Hook은 모델의 기억력에 기대지 않고, 도구 실행 직전·직후에 스크립트로 규칙을 강제합니다.

AI 코딩 에이전트에게 일을 시키다 보면 비슷한 말을 계속 반복하게 됩니다.

• "구현하기 전에 계획부터 보여줘."
• "테스트 먼저 작성하고 실패하는 걸 확인한 다음 구현해."
• "다 했으면 처음 보는 사람 입장에서 다시 리뷰해줘."
• "rm -rf나 git reset --hard는 함부로 실행하지 마."
• "어제 하던 작업 이어서 해줘."

ECC는 이런 요청을 매번 말로 하는 대신, 에이전트가 원래 그렇게 일하도록 미리 설치해 두는 도구입니다. 숙련된 개발자의 작업 습관을 "에이전트용 설정 파일 묶음"으로 만들어 둔 것이라고 생각하면 됩니다.

기술적으로 정의하면, ECC는 에이전트 하네스(agent harness) 위에 얹는 워크플로 계층입니다. 하네스란 모델을 감싸서 파일 읽기·쓰기, 셸 실행, 서브에이전트 호출 같은 도구를 제공하는 실행 환경을 말합니다. Claude Code, Codex CLI, Cursor, OpenCode가 모두 하네스입니다. ECC는 이 하네스가 이해하는 확장 형식(서브에이전트 정의, SKILL.md, 규칙 파일, Hook 설정)으로 68개의 Agent, 293개의 Skill, 94개의 명령 shim, 언어별 Rule, Hook 런타임, 메모리 시스템, 보안 스캐너를 제공합니다.

ECC가 다루지 않는 영역도 분명합니다. 어떤 모델을 쓸지, API 키와 인증을 어떻게 설정할지는 각 하네스가 그대로 관리합니다. ECC는 그 위에서 "일하는 방식"만 담당합니다.

프로젝트가 내세우는 원칙은 한 문장입니다.

Optimize the context window. Persist everything else.

컨텍스트 창에는 지금 필요한 것만 올리고, 나머지(규칙, 학습한 패턴, 세션 기록)는 파일로 남겨 두라는 뜻입니다.

참고로 이 프로젝트는 처음에 everything-claude-code라는 이름으로 알려졌고, 지금은 저장소·플러그인·패키지 모두 ECC로 이름을 정리했습니다. 검색하다가 옛 이름의 글을 보면 같은 프로젝트입니다.

주요 사용 사례

• 기능 개발: /ecc:plan으로 구현 계획을 먼저 만들고 확인받은 뒤, tdd-workflow Skill로 실패하는 테스트부터 작성하게 합니다.

요구사항: AI 에이전트가 팀의 개발 절차(계획, TDD, 리뷰, 안전 수칙)를 지키며 일하게 하고 싶다
 ↓
일반적인 구현: 프롬프트나 CLAUDE.md에 규칙을 계속 적어 넣는다
 ↓
문제 발생: 규칙이 길어질수록 컨텍스트를 잡아먹고, 모델은 긴 지시를 종종 잊으며, 강제할 방법이 없다
 ↓
ECC로 해결: 상시 규칙 / 필요 시 Skill / 격리된 Agent / 모델 밖 Hook으로 역할을 나눠 설치한다

상황 예시

세 명이 일하는 스타트업에서 Claude Code로 결제 서비스 백엔드를 개발하고 있습니다. 팀에는 이런 약속이 있습니다.

• 새 기능은 계획을 먼저 공유한다.
• 결제 로직은 반드시 테스트를 먼저 작성한다.
• 머지 전에 보안 관점 리뷰를 한 번 거친다.
• 운영 DB에 닿는 명령이나 git push --force는 사람이 직접 실행한다.

일반적인 구현 방식

가장 먼저 떠올리는 방법은 프로젝트 루트의 CLAUDE.md에 모든 규칙을 적는 것입니다.

<!-- CLAUDE.md : 모든 규칙을 한 파일에 몰아넣은 경우 -->
# 프로젝트 규칙

## 작업 절차
- 기능 구현 전에 반드시 계획을 먼저 보여주고 승인을 받을 것
- 테스트를 먼저 작성하고, 실패를 확인한 다음 구현할 것
- 구현이 끝나면 보안 관점에서 스스로 리뷰할 것 (SQL Injection, 인증 우회, 비밀값 노출...)

## 금지 사항
- rm -rf, git reset --hard, git push --force 실행 금지
- .env 파일 읽기 금지

## TypeScript 규칙
- any 금지, 함수 반환 타입 명시, ...(200줄)

## Python 규칙
- ...(150줄)

## React 규칙
- ...(150줄)

## 리뷰 체크리스트
- ...(100줄)

이 방식에서 발생하는 문제

• 컨텍스트 낭비: 백엔드 작업 중에도 React 규칙 150줄이 매 턴 로드됩니다. 규칙 파일은 대화가 길어질수록 같은 자리를 계속 차지합니다.
• 지시가 강제되지 않음: "git push --force 금지"는 부탁일 뿐입니다. 긴 세션 중 모델이 이 줄을 놓치면 막을 장치가 없습니다.
• 자기 리뷰의 한계: 코드를 작성한 컨텍스트가 그대로 리뷰까지 하면, 작성할 때의 가정과 맹점을 리뷰에서도 그대로 공유합니다.
• 기억이 남지 않음: 세션을 닫으면 "이 프로젝트에서는 금액을 항상 정수(원 단위)로 다룬다" 같은 학습 내용이 사라집니다.

ECC는 2026년 1월 공개 이후 GitHub Star 27만 개, Fork 4만 개를 넘겼습니다(2026년 10월 기준). 숫자보다 중요한 것은 왜 이런 도구가 필요해졌는가입니다.

모델보다 하네스가 결과를 좌우하는 시기가 왔습니다. 코딩 모델의 기본 실력이 충분히 올라오면서, 같은 모델이라도 어떤 절차와 규칙 위에서 일하느냐에 따라 결과 품질 차이가 커졌습니다. "프롬프트 엔지니어링"에서 "하네스 엔지니어링"으로 관심이 옮겨 간 흐름에 ECC가 정확히 들어맞습니다.

하네스가 확장 지점을 열어 주었습니다. Claude Code가 서브에이전트, Skill, Hook, 플러그인 마켓플레이스를 제공하면서 "에이전트 작업 방식"을 파일로 배포할 수 있게 되었습니다. ECC는 이 확장 지점을 가장 넓게 채운 카탈로그입니다.

컨텍스트 비용 문제에 정면으로 답합니다. 규칙을 많이 넣을수록 컨텍스트가 줄어드는 문제를 Rule(항상)과 Skill(필요할 때)의 분리, 세션 시작 컨텍스트 상한(ECC_SESSION_START_MAX_CHARS), 신뢰도 기반 Instinct 주입 같은 장치로 다룹니다.

모델의 기억력에 기대지 않는 강제 장치가 있습니다. Hook은 모델 밖에서 실행되므로 "잊어버림"이 없습니다. 에이전트에게 셸 권한을 주는 일이 많아질수록 이 차이는 커집니다.

하네스를 가리지 않으려 합니다. 저장소 루트 하나를 원본으로 두고 Claude Code, Codex, Cursor, OpenCode, Kimi Code, Gemini 등으로 변환합니다. 팀원마다 다른 도구를 써도 같은 절차를 공유할 수 있습니다.

CLAUDE.md만 쓸 때와의 항목별 차이는 장단점과 대안 비교에 정리했습니다.

• AI 에이전트로 매일 상당량의 코드를 작성하는 경우: 같은 지시를 반복하는 비용이 매일 쌓이므로, 절차를 한 번 설치해 두는 효과가 큽니다.
• 결제·인증·데이터 마이그레이션처럼 실수 비용이 큰 코드가 있는 경우: 계획 확인, 테스트 선작성, 별도 컨텍스트 리뷰라는 단계가 사고를 줄이는 안전장치가 됩니다.
• 에이전트에게 셸 권한을 넓게 주는 경우: 프롬프트로 하는 금지는 잊힐 수 있지만 Hook은 잊히지 않습니다.
• 팀원마다 다른 하네스를 쓰는 경우: 하나의 원본에서 Claude Code, Codex, Cursor 등으로 같은 워크플로를 배포하고, Memory Vault로 맥락을 공유할 수 있습니다.
• 에이전트 활용 방식을 배우고 싶은 경우: 293개의 Skill과 68개의 Agent 정의 자체가 "좋은 에이전트 워크플로를 어떻게 작성하는가"의 예제 모음입니다. 설치하지 않고 읽기만 해도 얻는 것이 많습니다.

• 일회성 스크립트나 빠른 프로토타입: 계획 확인과 TDD 단계가 오히려 속도를 늦춥니다. 버릴 코드라면 절차의 이득이 없습니다.

  예: 데이터 한 번 변환하는 50줄짜리 Python 스크립트를 만드는데 planner와 code-reviewer를 거칠 필요는 없습니다.

• 에이전트를 일주일에 몇 번만 쓰는 경우: 설치와 학습 비용이 반복 지시를 줄이는 이득보다 큽니다.
• 잘 정리된 CLAUDE.md 하나로 충분한 팀: 규칙이 수십 줄 이내이고 위험 명령 걱정이 적다면, 단순한 규칙 파일 하나로 필요한 효과의 대부분을 얻습니다.
• 컨텍스트 창이 작은 로컬 모델: 전체 카탈로그와 세션 시작 주입은 작은 모델을 흔들 수 있습니다. 쓰더라도 minimal 프로필, ECC_SESSION_START_CONTEXT=off, 프로젝트에 맞는 Skill 몇 개로 줄여야 합니다.
• 이미 Hook 기반 도구를 쓰고 있는 경우: 다른 Hook 도구와 겹쳐 켜면 같은 이벤트에서 충돌하거나 중복 실행될 수 있습니다. 하나를 정하거나 ECC_DISABLED_HOOKS로 겹치는 부분을 꺼야 합니다.
• 설정 변화에 민감한 환경: ECC는 릴리스가 잦고 구성 요소가 많습니다. 사내 보안 검토를 거친 설정만 써야 하는 조직이라면 전체 설치보다 검토한 Skill 몇 개만 가져오는 편이 관리하기 쉽습니다.

한 문장으로

ECC는 AI 코딩 에이전트가 매번 잊어버리는 개발 절차와 안전 수칙을 상시 규칙·필요 시 로드되는 Skill·격리된 Agent·모델 밖 Hook으로 나눠 설치해서 해결하기 위한 하네스 확장 시스템입니다.

이것만 기억하기

1. 왜 사용하는가?

   • "계획 먼저, 테스트 먼저, 리뷰는 따로, 위험 명령은 금지"를 매 프롬프트로 반복하지 않고 에이전트의 기본 작업 방식으로 만들기 위해서입니다.

2. 어떤 문제를 해결하는가?

   • 규칙이 컨텍스트를 낭비하는 문제, 규칙이 강제되지 않는 문제, 작성자가 자기 코드를 리뷰하는 문제, 세션이 끝나면 맥락이 사라지는 문제입니다.

3. 어떻게 동작하는가?

   • Rule은 항상, Skill은 필요할 때 로드되고, Agent는 별도 컨텍스트에서 위임 작업을 처리하며, Hook은 도구 실행 전후에 모델 밖에서 검사합니다. 세션 요약과 Instinct가 다음 세션으로 맥락을 넘깁니다.

4. 실제 프로젝트에서는 어디에 사용하는가?

   • 결제·인증처럼 실수 비용이 큰 기능의 TDD, PR 전 리뷰와 보안 점검, CI 빌드 복구, 팀 저장소의 공통 에이전트 설정, 하네스 간 작업 인계에 씁니다.

5. 언제 사용하지 않는가?

   • 버릴 코드, 가끔 쓰는 에이전트, 짧은 규칙 파일로 충분한 팀, 컨텍스트가 작은 로컬 모델에서는 오히려 부담이 됩니다.

ECC를 이루는 Agent, Skill, Rule, Hook, Instinct·Memory, 설치 프로필이 각각 무엇이고 어떻게 맞물려 동작하는지 다룹니다.

용어 한눈에 보기

1. Agent (서브에이전트)

쉽게 설명하면

설치 방법을 고르는 기준, 기본 설정, 가장 간단한 첫 실행, 설치할 때 자주 겪는 충돌을 다룹니다.

설치

필요 조건은 Node.js 18 이상, Git, Claude Code 2.1 이상입니다.

방법 1. 안내형 설치(권장)

npx ecc-universal@2.2.3 setup

pnpm dlx ecc-universal@2.2.3 setup

bunx ecc-universal@2.2.3 setup

마법사는 기존 설치 범위(user / project / local)를 먼저 조사한 뒤, ecc@ecc 플러그인을 선택한 범위에 설치하거나 옮깁니다. 같은 명령을 다시 실행하면 업데이트, 범위 변경, Hook 프로필 변경도 할 수 있습니다.

방법 2. Claude Code 네이티브 플러그인 명령

/plugin marketplace add affaan-m/ECC
/plugin install ecc@ecc

방법 3. 여러 하네스를 한 번에

npx ecc-universal@2.2.3 install --guided \
  --harness claude --harness codex \
  --claude-scope local --claude-hooks standard \
  --profile core --yes

한 하네스에는 한 가지 방법만 사용해야 합니다. 플러그인을 설치한 뒤 ./install.sh --profile full을 또 실행하면 Skill, Hook이 중복 등록되어 같은 Hook이 두 번 실행됩니다. 이미 겹쳤다면 uninstall --dry-run으로 확인한 뒤 정리하고 한 방법으로 다시 설치합니다.

기본 설정

Rule은 플러그인이 자동 배포하지 않으므로 직접 설치합니다.

git clone https://github.com/affaan-m/ECC.git
mkdir -p ~/.claude/rules/ecc
cp -R ECC/rules/common ~/.claude/rules/ecc/
cp -R ECC/rules/typescript ~/.claude/rules/ecc/   # 실제로 쓰는 언어로 교체

필요하면 Hook 동작을 환경 변수로 조절합니다.

export ECC_HOOK_PROFILE=standard            # minimal | standard | strict
export ECC_SESSION_START_MAX_CHARS=4000     # 세션 시작 시 주입할 요약 크기 상한
export ECC_DISABLED_HOOKS="post:edit:typecheck"  # 특정 Hook만 끄기

설치 상태는 언제든 점검할 수 있습니다.

npx ecc-universal@2.2.3 list-installed
npx ecc-universal@2.2.3 doctor
npx ecc-universal@2.2.3 repair

가장 간단한 예제

결제 재시도 기능을 계획 → TDD → 리뷰 → 검증 흐름으로 만드는 과정과, 깨진 빌드를 최소 변경으로 복구하는 과정을 다룹니다.

예제 1. 결제 재시도 기능을 TDD로 추가하기

요구사항

PG사 결제 승인 API가 일시적으로 실패(HTTP 503, 타임아웃)하면 최대 3회까지 지수 백오프로 재시도한다. 단, 같은 주문이 두 번 결제되면 안 되므로 멱등성 키를 반드시 사용한다. 카드 한도 초과 같은 영구 실패는 재시도하지 않는다.

구현

/ecc:plan "PG 결제 승인 API 일시 실패 시 최대 3회 지수 백오프 재시도. 멱등성 키 필수. 영구 실패는 재시도 금지"

planner가 계획을 제시하면 확인 후 tdd-workflow로 진행합니다. 에이전트는 구현 전에 다음과 같은 실패하는 테스트부터 작성합니다.

// src/payments/approve-with-retry.test.ts
import { describe, it, expect, vi } from 'vitest';
import { approveWithRetry } from './approve-with-retry';
import { PgError } from './pg-client';

describe('approveWithRetry', () => {
  it('일시 실패(503)는 최대 3회 재시도 후 성공하면 결과를 반환한다', async () => {
    const approve = vi
      .fn()
      .mockRejectedValueOnce(new PgError(503))
      .mockRejectedValueOnce(new PgError(503))
      .mockResolvedValueOnce({ status: 'APPROVED' });

    const result = await approveWithRetry({ approve, orderId: 'order-1', sleep: async () => {} });

    expect(result.status).toBe('APPROVED');
    expect(approve).toHaveBeenCalledTimes(3);
  });

  it('모든 재시도에서 같은 멱등성 키를 사용한다', async () => {
    const approve = vi.fn().mockRejectedValueOnce(new PgError(503)).mockResolvedValueOnce({ status: 'APPROVED' });

    await approveWithRetry({ approve, orderId: 'order-1', sleep: async () => {} });

    const keys = approve.mock.calls.map(([req]) => req.idempotencyKey);
    expect(new Set(keys).size).toBe(1);
  });

  it('영구 실패(한도 초과)는 재시도하지 않는다', async () => {
    const approve = vi.fn().mockRejectedValue(new PgError(402, 'LIMIT_EXCEEDED'));

    await expect(approveWithRetry({ approve, orderId: 'order-1', sleep: async () => {} })).rejects.toThrow();
    expect(approve).toHaveBeenCalledTimes(1);
  });
});

테스트가 실패하는 것(RED)을 확인한 뒤에 구현합니다.

// src/payments/approve-with-retry.ts
import { PgError, type ApproveRequest, type ApproveResult } from './pg-client';

const RETRYABLE = new Set([502, 503, 504]);
const MAX_ATTEMPTS = 3;

type Options = {
  approve: (req: ApproveRequest) => Promise<ApproveResult>;
  orderId: string;
  sleep?: (ms: number) => Promise<void>;
};

export async function approveWithRetry({
  approve,
  orderId,
  sleep = (ms) => new Promise((r) => setTimeout(r, ms)),
}: Options): Promise<ApproveResult> {
  // 주문 단위로 고정된 키: 재시도해도 PG가 같은 요청으로 인식한다
  const idempotencyKey = `approve:${orderId}`;

  for (let attempt = 1; ; attempt++) {
    try {
      return await approve({ orderId, idempotencyKey });
    } catch (error) {
      const retryable = error instanceof PgError && RETRYABLE.has(error.status);
      if (!retryable || attempt === MAX_ATTEMPTS) throw error;
      await sleep(200 * 2 ** (attempt - 1)); // 200ms, 400ms
    }
  }
}

개발자 한 명의 로컬 하네스에서 React·Next.js 작업에 ECC의 Skill과 Agent를 쓰는 방법을 다룹니다.

ECC는 브라우저나 앱에서 실행되는 클라이언트 라이브러리가 아니므로, 여기서는 "개발자 한 명의 로컬 환경"을 클라이언트 관점으로 봅니다. 그중에서도 프론트엔드 작업에 쓸 수 있는 구성 요소가 많습니다.

활용할 수 있는 기능

• React·Next.js Skill: react-patterns(훅 규칙, 서버·클라이언트 컴포넌트 경계, Suspense), react-performance(워터폴, 번들 크기, 리렌더 등 우선순위별 규칙), nextjs-turbopack, frontend-patterns
• 테스트 Skill: react-testing(React Testing Library + Vitest/Jest, MSW, 접근성 단언), e2e-testing(Playwright Page Object Model)
• 접근성·디자인: frontend-a11y, accessibility(WCAG 2.2 AA), design-system
• 리뷰·복구 Agent: react-reviewer, typescript-reviewer, react-build-resolver(Vite, webpack, Next.js 빌드 실패, 하이드레이션 불일치), performance-optimizer
• 확인·공유: browser-qa(배포 후 실제 화면 확인), (Playwright로 데모 영상 녹화)

팀 저장소, CI, 사내 LLM 게이트웨이와 ECC를 연결하는 방법과, 작은 서비스에 실제로 도입하는 과정을 다룹니다.

팀·CI·서버 환경에서의 활용

ECC는 서버 런타임에서 import하는 라이브러리가 아닙니다. 대신 서버 코드를 개발하는 과정과 팀 단위 운영에서 다음과 같이 쓰입니다.

활용 사례

• 팀 표준 공유: 프로젝트 로컬 범위(.claude/)에 Rule과 필요한 Skill을 설치하고 저장소에 커밋해서, 팀원 모두의 에이전트가 같은 규칙으로 일하게 합니다.
• 백엔드 프레임워크별 워크플로: springboot-tdd, django-tdd, laravel-tdd, quarkus-tdd 같은 프레임워크별 TDD·보안·검증 Skill과 java-reviewer, python-reviewer, go-reviewer, database-reviewer Agent를 사용합니다.
• 에이전트 설정 보안 감사: CI에서 AgentShield로 저장소의 에이전트 설정(Hook, MCP 설정, 권한, 비밀값)을 검사합니다.
• 자체 호스팅 모델·게이트웨이 연결: ECC는 Anthropic 전송 설정을 하드코딩하지 않으므로, 회사 LLM 게이트웨이나 자체 호스팅 모델을 붙여도 워크플로는 그대로 동작합니다.
• 하네스 간 인계: Memory Vault로 Claude Code에서 하던 작업 맥락을 Codex 세션으로 넘깁니다.

애플리케이션 구조

ECC가 "서버 코드의 어느 계층에 들어가느냐"가 아니라, 서버 개발 흐름의 어느 단계에 개입하느냐로 보는 것이 맞습니다.

ECC의 장점과 단점, 그리고 CLAUDE.md·Superpowers·Spec Kit 같은 대안과 비교해 상황별로 무엇을 고를지 다룹니다.

CLAUDE.md만 쓸 때와 무엇이 달라지나

Skill·Agent·Rule과 Hook이 어떻게 다른지, 그리고 Hook이 어떤 파일로 이루어져 있고 한 번의 도구 호출에서 어떤 순서로 실행되는지 다룹니다.

Skill·Agent·Rule과 Hook은 무엇이 다른가

한 줄로 구분하면

Skill, Agent, Rule은 모델이 읽는 글이고, Hook은 하네스가 실행하는 프로그램입니다.

Skill·Agent·Rule은 모두 Markdown으로 작성되어 모델의 컨텍스트에 들어갑니다. 모델은 그 내용을 읽고 따르려고 하지만, 따를지 말지는 결국 모델의 판단입니다. 반면 Hook은 모델의 컨텍스트 밖에서 하네스(Claude Code)가 직접 실행하는 스크립트입니다. 모델이 무엇을 기억하든, 어떻게 판단하든 정해진 이벤트가 오면 반드시 실행되고, 결과에 따라 도구 호출을 막을 수도 있습니다.

비유하면 Rule·Skill·Agent는 신입 사원에게 주는 업무 매뉴얼, 업무 절차서, 담당자 지정입니다. Hook은 출입문의 보안 게이트입니다. 매뉴얼은 읽고 잊을 수 있지만, 게이트는 출입증 없이는 열리지 않습니다.

항목별 비교

운영하면서 신경 써야 할 컨텍스트·비용·보안·플랫폼 문제와, 처음 쓸 때 자주 헷갈리는 질문을 다룹니다.

사용할 때 주의할 점

컨텍스트(성능) 설치한 것이 많을수록 모델이 실제 작업에 쓸 수 있는 컨텍스트가 줄어듭니다. /context-budget으로 사용량을 확인하고, Rule은 공통 + 쓰는 언어 하나로 제한하고, MCP 서버는 필요한 것만 켭니다. 세션 시작 주입은 ECC_SESSION_START_MAX_CHARS로 줄일 수 있습니다.

비용 서브에이전트와 병렬 실행은 모델 호출을 늘립니다. 특히 비싼 모델에서 여러 Agent를 동시에 돌리면 비용이 배로 늘어납니다. 리뷰 같은 단계는 더 저렴한 모델로 돌리도록 Agent의 model을 지정하는 것을 고려합니다.

보안

• 공식 채널(GitHub affaan-m/ECC, npm ecc-universal·ecc-agentshield, 플러그인 ecc@ecc, GitHub App, ecc.tools)에서만 설치합니다. 비공식 재업로드본은 검토되지 않으며 악성 코드가 섞여 있을 수 있다고 프로젝트가 직접 경고합니다.
• 버전 고정(ecc-universal@2.2.3)은 재현성을 위한 것이지 보안 감사가 아닙니다. 고정한 버전의 릴리스 소스는 직접 확인해야 합니다.
• Hook은 사용자 권한으로 셸 명령을 실행하므로, 설치하는 Hook이 무엇을 하는지 알고 있어야 합니다.
• GateGuard는 모든 위험 명령을 막지 못합니다. 되돌리기 어려운 작업은 하네스의 권한 설정으로도 함께 제한합니다.

설치 충돌 설치 방법 중복, Hook 중복 실행, Skill 경로 문제는 설치와 첫 사용에 정리했습니다.

플랫폼 제약

• 네이티브 Windows에서는 continuous-learning v2 관찰 데몬과 메모리 볼트 쓰기에 알려진 결함이 있습니다. WSL을 쓰면 Linux 경로를 따릅니다.

affaan-m/ECC