Claude Code의 플러그인 「i-have-adhd」를 설치하면, 답변이 「결론 1줄 → 번호가 매겨진 판단 기준 → 다음 단계」라는 구조로 바뀝니다. Reddit에서 크게 화제가 되었기에 실제로 도입하여, 동일한 질문을 플러그인이 없는 상태와 있는 상태로 각각 던져 비교해 보았습니다.

계기는 r/ClaudeAI의 이 스레드입니다. 제가 확인했을 시점에 2,830 upvotes, 댓글은 439건이었습니다.

i-have-adhd는 답변의 서론이나 맺음말 인사를 금지하고, 정답부터 쓰게 만드는 플러그인입니다. 이름은 ADHD 환자를 위해 만들어진 것에서 유래했습니다. 다만, 정답부터 쓰게 한다는 방침은 당사자 여부와 관계없이 도움이 되는 것이라고 느꼈습니다.

바로 설치해 보겠습니다. 먼저 marketplace를 추가합니다.

claude plugin marketplace add ayghri/i-have-adhd

실행하면 다음과 같은 로그가 나왔습니다. SSH가 설정되어 있지 않아도 HTTPS로 자동 폴백(fallback) 해줍니다.

SSH not configured, cloning via HTTPS: https://github.com/ayghri/i-have-adhd.git
Refreshing marketplace cache (timeout: 120s)…
Cloning repository (timeout: 120s): https://github.com/ayghri/i-have-adhd.git
...

이어서 설치합니다.

claude plugin install i-have-adhd@i-have-adhd

✔ Successfully installed plugin: i-have-adhd@i-have-adhd (scope: user)

여기까지 진행하며 막힌 부분은 딱히 없었습니다. 사용할 때는 세션에서 /i-have-adhd를 호출하기만 하면 됩니다.

「Web 앱 테스트는 어디까지 E2E로 작성해야 할까?」라는 질문을 순수 Claude Code와 플러그인을 통한 방식 양쪽 모두에 던졌습니다. 주목해야 할 점은 답변의 내용이 아니라, 답을 나열하는 방식입니다.

먼저 순수 Claude Code의 답변입니다.

결론부터 말하자면, 크리티컬한 사용자 플로우(중요한 수익 경로)에만 집중하는 것이 정석입니다. 회원가입, 로그인, 결제, 주요 구매 동선 등 「이 부분이 고장 나면 사업이 중단되는」 경로만 E2E로 커버하고, 그 외의 분기나 에지 케이스(edge case)는 unit/integration 테스트로 돌립니다. E2E는 실행이 느리고 flaky(불안정)해지기 쉬우며, 테스트 수에 비해 유지보수 비용이 비선형적으로 증가하기 때문에, 포괄성을 추구하다 보면 오히려 테스트 스위트 전체의 신뢰성이 떨어집니다.

보충하자면, 최근 주류는 고전적인 「피라미드(unit 위주)」보다 Kent C. Dodds의 Testing Trophy(integration 위주, E2E는 소수 정예, unit은 최소한)라는 개념으로, 「사용자의 사용법에 가까운 테스트일수록 가치가 높다」는 발상입니다. 기준으로는 E2E를 전체 테스트 수의 5~10% 정도로 억제하고, 그 외에는 컴포넌트 단위의 integration 테스트로 구현 상세에 의존하지 않고 동작을 검증하는 밸런스가 실무에서 다루기 쉽습니다.

만약 이 판단에 있어 고민 중인 구체적인 프로젝트(테스트 프레임워크나 CI 시간의 제약 등)가 있다면, 그에 맞춰 조금 더 구체적인 경계선을 함께 생각할 수 있습니다.

내용은 충실합니다. 다만, 밀도 높은 산문이 3단락 이어집니다.

다음은 /i-have-adhd:i-have-adhd (/i-have-adhd의 완전 수식 형태)로 동일한 질문을 던진 결과입니다.

결론: 크리티컬 패스만 E2E. 그 외에는 유닛/인테그레이션으로 돌림.

판단 기준:

• E2E로 설정한다 — 사용자가 실제로 밟는 주요 플로우(로그인 → 구매 → 완료, 회원가입, 검색 → 상세 → 액션 등). 망가지면 사업이 중단되는 것만 해당. 기준은 약 5~15개 시나리오.
• E2E로 설정하지 않는다 — 유효성 검사(Validation)의 분기, 에러 메시지의 문구 차이, 권한 패턴의 모든 조합, UI 외관의 세부 사항. 이것들은 유닛/인테그레이션(Unit/Integration) 테스트로 커버하는 것이 더 빠르고 안정적이다.
• API/로직은 인테그레이션 테스트로 해결한다 — E2E에서 백엔드의 분기망을 모두 포괄하려고 하면 실행 시간과 플래키(Flaky) 비율이 급증한다. 로직의 정확성은 API 레벨의 테스트로 담보하고, E2E는 "화면이 연결되어 작동하는가"를 확인하는 데 집중한다.
  이유: E2E는 하나당 실행이 느리고(수 초 ~ 수십 초), 환경 의존성 때문에 플래키(Flaky)해지기 쉽다. 테스트 개수를 늘릴수록 CI가 무거워지며, 유지보수 비용이 선형 이상으로 증가한다. 테스트 피라미드(Test Pyramid: 유닛 다수 · 인테그레이션 중간 · E2E 소수)는 지금도 기본적으로 옳다.

다음 단계: 현재 앱에서 "이것이 작동하지 않으면 치명적이다"라고 판단되는 사용자 플로우를 3가지 작성한다. 그것이 E2E의 대상 리스트다.

서론도 결론 인사도 없습니다.

Reddit 스레드에는 "짧고 간결해졌다"라는 의견도 있었습니다. 다만, 비교해 보며 알게 된 점은, 짧아진다기보다 정보가 정리된다는 것입니다. 원본 답변도 결론부터 시작하긴 하지만, 마무리는 "함께 생각해 볼 수 있습니다"라는 역질문이었습니다. 플러그인 버전은 역질문 대신, 지금 바로 해야 할 일을 구체적으로 지정해 줍니다. 훑어 읽으면서도 요점을 파악할 수 있다는 점이 고마운 부분입니다.

한편으로 신경 쓰이는 점도 있습니다. 원본 답변에 있었던 Kent C. Dodds의 Testing Trophy와 같은 보충 설명은 플러그인 버전에서는 나오지 않았습니다. 배경 정보나 세부적인 경위가 누락될 수도 있습니다. 배경부터 차근차근 이해하고 싶은 상황에서는 원본 Claude Code가 더 적합해 보입니다.

Claude Code의 답변이 길다고 느끼는 사람, 혹은 무심코 읽어 넘겨버리는 사람은 명령어 두 개로 설치되니 가볍게 시도해 볼 수 있습니다. 참고로 이번 검증은 단 한 질문에 대한 비교이며, 플러그인의 내부 구조까지는 살펴보지 않은 가벼운 검증입니다. 질문의 종류에 따라 효과가 달라지는지까지는 알 수 없습니다.

Reddit 댓글란에는 Skill로서 매번 호출하기보다 output style로서 설정하는 것이 더 정착되기 쉽다는 취지의 의견도 있었습니다(이 부분은 미검증입니다).

플러그인을 늘려가다 보면 관리가 신경 쓰이게 되지만, 정리는 /doctor에 맡길 수 있습니다. 이전에 작성한 글이 있으니 함께 참고해 주세요.

AI 주도 개발(특히 Claude Code)의 노하우나 팁(Tips)을 자주 발신하고 있습니다!