이 글의 검증 대상은 ayghri의 i-have-adhd 공개 저장소와 그 안의 README 및 SKILL.md입니다. 여기서 확인되는 핵심 단위는 모델 자체가 아니라 스킬 파일입니다. 따라서 i-have-adhd Claude Code 스킬은 코드 품질을 자동으로 높이는 도구가 아닙니다. 개인 개발자는 낮은 위험으로 시험할 수 있지만, 팀은 규칙 충돌과 결과 재현성을 먼저 확인해야 합니다. 클라우드 작업 공간도 지속 실행과 환경 통일을 해결할 뿐, 작업 방식 자체를 대신 설계하지는 못합니다.
마지막 업데이트: 2026년 9월 23일. 공개 저장소와 Claude 관련 공식 안내를 기준으로 내용을 다시 확인했습니다. 저장소 이름이 바뀌거나 같은 이름의 프로젝트가 새로 등장하면 판단도 달라질 수 있습니다.
이 글이 필요한 사람
Claude Code를 쓰면서 답변이 길고 다음 행동이 늦게 나와 답답했던 개발자에게 적합합니다. 인기 있는 스킬을 단순히 설치하는 대신, 자신의 코딩 방식에 맞는지 확인하려는 AI Coding 콘텐츠 독자도 대상입니다. 개인 설정을 팀 규칙이나 공유 클라우드 환경으로 옮기려는 소규모 팀 책임자라면 뒤의 충돌과 회귀 조건을 특히 확인해야 합니다.
i-have-adhd의 실제 위치
i-have-adhd는 출력 순서와 상호 작용 방식을 조정하는 스킬에 가깝습니다. 답변에서 결론이나 실행 가능한 다음 행동을 앞에 두고, 불필요한 설명을 줄이는 방향으로 사용 경험을 바꿀 수 있습니다. 반면 다음 기능을 모두 제공하는 Agent Harness로 보면 안 됩니다.
- 작업을 자동으로 쪼개고 우선순위를 관리하는 작업 관리 도구
- 장기 프로젝트의 상태와 기억을 보존하는 컨텍스트 시스템
- 터미널 세션과 여러 에이전트를 운영하는 실행 관리자
- 테스트, 검토, 배포까지 보장하는 코드 품질 도구
Anthropic도 Skills, CLAUDE.md, Hooks, Subagents를 서로 다른 역할로 설명합니다. 각 구성 요소의 역할을 구분한 공식 안내를 보면, 출력 스타일을 정하는 규칙과 실행 권한을 다루는 장치는 같은 문제가 아닙니다. 그러므로 i-have-adhd를 적용한 뒤 답변이 더 읽기 쉬워졌다고 해서 버그가 줄거나 설계가 좋아졌다고 결론 내릴 수 없습니다.
Claude의 Skills 안전 사용 안내처럼, 저장소의 내용과 실행 범위를 먼저 검토해야 합니다. 특히 개인 취향으로 만든 규칙을 프로젝트의 필수 정책으로 오해하지 않는 것이 중요합니다.
사용자별 도입 판단
개인 개발자: 답변 마찰 줄이기
혼자 작은 기능을 구현할 때는 긴 배경 설명보다 바로 실행할 명령, 변경 파일, 확인 방법이 필요한 경우가 많습니다. 이때 i-have-adhd는 다음 행동을 먼저 보여 주도록 유도해 대화의 왕복을 줄이는 데 도움을 줄 수 있습니다.
다만 다음 상황에서는 효과가 제한적입니다.
- 요구 사항이 모호해 먼저 질문해야 하는 작업
- 여러 파일의 의존 관계를 조사해야 하는 작업
- 이전 결정과 테스트 결과를 계속 기억해야 하는 프로젝트
- 터미널 세션, 브랜치, 권한을 따로 관리해야 하는 환경
이 경우에는 출력 스타일보다 CLAUDE.md, 작업 분할 방식, 세션 관리가 먼저입니다. Claude의 컨텍스트 파일과 더 나은 프롬프트 설명을 읽고 프로젝트의 목표, 금지 사항, 테스트 명령을 분리해 적는 편이 더 직접적인 해결책입니다.
소규모 팀: 공유 규칙의 부작용
팀에서 공유 스킬을 쓰면 개인의 답변 선호가 팀 표준처럼 굳어질 수 있습니다. 프로젝트의 CLAUDE.md가 상세한 설명과 확인 절차를 요구하는데 i-have-adhd가 짧은 결론을 우선하면, 두 규칙이 충돌할 수 있습니다. 다른 Skills가 안전 확인이나 출력 형식을 요구하는 경우에도 결과가 달라집니다.
| 확인 영역 | 개인 시험에서 볼 것 | 팀 도입 전 판단 |
|---|---|---|
| 출력 방식 | 다음 행동이 더 분명해지는가 | 설명이 필요한 검토 업무를 생략하지 않는가 |
| 프로젝트 규칙 | CLAUDE.md 지시를 따르는가 |
저장소별 규칙과 우선순위를 문서화했는가 |
| 결과 재현 | 같은 요청에서 비슷한 구조가 나오는가 | 다른 구성원도 같은 기준으로 검토할 수 있는가 |
| 유지 관리 | 규칙을 쉽게 끌 수 있는가 | 변경 담당자와 되돌리기 절차가 있는가 |
| 보안 범위 | 민감한 명령을 임의로 실행하지 않는가 | 권한과 로그를 별도로 확인했는가 |
팀에 적용할 때는 먼저 한 저장소와 비민감한 작업만 선택합니다. 기준이 될 요청을 정하고, 스킬을 켠 결과와 끈 결과를 같은 테스트와 코드 검토로 비교합니다. 그다음 팀원이 읽을 수 있는 규칙 문서로 내용을 옮기고, 프로젝트 규칙과 Skills의 적용 순서를 기록합니다. 문제가 생기면 파일을 삭제하는 대신 비활성화된 사본으로 되돌려 원인을 분리합니다.
Claude Code의 공식 명령줄 사용 문서는 실행 선택지를 설명하지만, 팀이 어떤 출력 형식을 채택해야 하는지 결정해 주지는 않습니다. 그 판단은 저장소의 테스트와 코드 검토를 통해 내려야 합니다.
주의: 커뮤니티에서 많이 언급된다는 사실은 생산 환경에서 검증됐다는 뜻이 아닙니다. 같은 이름의 i-have-adhd 프로젝트가 여러 개 존재할 수 있으므로, 도입 전에 저장소 주소와 최근 파일 내용을 고정하십시오.
플랫폼 관리자: 클라우드 이전의 경계
AI Coding 워크플로를 클라우드로 옮겨야 하는지는 스킬의 인기보다 운영 요구로 결정해야 합니다. 지속 실행이 필요하거나, 팀이 같은 개발 환경에 원격으로 접속해야 하거나, 작업 기록을 보존해야 한다면 클라우드 작업 공간이 의미를 가질 수 있습니다. 환경을 다시 만들 때 생기는 차이를 줄이고, 권한을 사용자별로 분리하기도 쉽습니다.
그러나 스킬 파일을 복사했다고 세션 상태와 프로젝트 데이터가 함께 안전하게 옮겨지는 것은 아닙니다. 다음 항목은 별도로 이전하고 검증해야 합니다.
- 저장소와 브랜치 상태
- 환경 변수와 비밀 키의 보관 위치
- 세션 기록과 로그의 접근 권한
- 네트워크 허용 범위와 외부 도구 권한
- 작업 종료 뒤 남는 임시 파일과 캐시
클라우드 인프라와 원격 개발 환경 안내를 검토할 때도, 지속 실행 여부만 보지 말고 로그 보존과 권한 분리 조건을 함께 확인해야 합니다. 원격 환경이 필요한 이유가 단순히 답변을 짧게 만들기 위해서라면, 먼저 로컬 규칙을 정리하는 편이 비용과 관리 부담이 적습니다.
클라우드 맥을 실제 개발 환경으로 비교하려면 Kvmjet의 서비스 구성 안내에서 원격 접근 방식과 제공 범위를 먼저 확인하십시오. 스킬 파일을 옮기는 일과 개발 환경을 운영하는 일은 별개의 검토 항목입니다.
시험 유지 중단을 가르는 조건
다음 조건 목록으로 결정하면 커뮤니티 열기에 휩쓸릴 가능성을 줄일 수 있습니다.
- 출력이 길어서 작업을 시작하기 어렵고, 짧은 다음 행동이 실제로 도움이 되면 개인 시험을 선택합니다. 효과가 없으면 기본 설정으로 돌아갑니다.
CLAUDE.md와 스킬의 지시가 충돌하지 않고, 팀원이 결과를 쉽게 검토하면 제한된 팀 파일럿을 선택합니다. 충돌이 한 번이라도 중요한 배포 작업에 영향을 주면 공유 적용을 멈춥니다.- 같은 요청을 다른 구성원이 실행해도 테스트와 변경 범위를 재현할 수 있으면 유지를 검토합니다. 결과가 사람마다 크게 달라지면 개인 설정으로 남깁니다.
- 세션 지속, 환경 통일, 원격 접근이 실제 운영 요구라면 클라우드 이전을 검토합니다. 단지 인기 스킬을 계속 실행하고 싶다는 이유뿐이면 먼저 로컬 작업 흐름을 정리합니다.
- 비밀 키, 프로젝트 자료, 실행 권한을 분리해 기록할 수 없으면 이전을 중단합니다. 스킬 파일만 옮기는 것은 안전한 마이그레이션이 아닙니다.
- 유지 관리 담당자와 되돌리기 방법을 정할 수 없으면 도입하지 않습니다. 개인 취향을 팀의 의무 규칙으로 만들 이유가 없습니다.
지속 가능한 AI Coding 워크플로
i-have-adhd는 대화의 표현과 순서를 다루는 도구입니다. 프로젝트 규칙은 저장소의 맥락과 금지 사항을 알려 줍니다. Skills 관리는 반복 작업의 지시를 버전으로 관리하는 역할을 맡습니다. 클라우드 작업 공간은 실행 환경과 접근 방식을 통일하는 역할을 합니다. 코드 검토는 최종 결과가 요구 사항과 테스트를 만족하는지 확인합니다.
이 네 층을 하나로 묶으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 먼저 개인 환경에서 스킬을 시험하고, 다음으로 프로젝트 규칙과 충돌 여부를 확인하십시오. 팀으로 넓히기 전에는 원격 환경 운영 조건을 확인하고, 클라우드로 옮길 때는 비밀 정보와 로그의 경계를 별도로 설계해야 합니다.
현재 로컬 방식은 익숙하지만, 장시간 실행이 끊기고 환경이 사람마다 달라지며, 세션과 로그를 팀 기준으로 보존하기 어렵다는 단점이 있습니다. 반대로 클라우드 맥 환경은 지속 실행과 원격 접근, 구성 통일에 유리하지만 권한 설계와 데이터 관리가 추가됩니다. 따라서 i-have-adhd 하나만으로 이전을 결정하지 말고, 먼저 작은 저장소에서 출력 규칙을 시험한 뒤 지속 실행이나 원격 협업이 실제로 필요할 때만 Kvmjet의 클라우드 맥 환경을 비교하는 순서가 안전합니다.
다음 단계는 작은 실험부터 시작합니다
먼저 별도의 시험 저장소에서 스킬을 적용하고 코드 품질과 작업 시간을 비교해 보시기 바랍니다.
프로젝트 규칙과 지시가 충돌할 때를 대비해 우선순위와 검토 절차를 정리한 기술 안내를 이어서 확인하시기 바랍니다.