i-have-ADHD, 코딩 에이전트 답변도 UX다
코딩 에이전트의 품질은 정답률만으로 끝나지 않는다. 사용자가 바로 다음 행동을 할 수 있게 만드는 출력 프로토콜이 실제 생산성 차이를 만든다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
작은 스킬이 큰 병목을 겨냥했다
i-have-ADHD GitHub 저장소는 코딩 어시스턴트가 답을 장황한 설명 속에 묻지 않도록 만드는 스킬이다. README는 "Action first", "Steps numbered", "No Hope this helps" 같은 규칙을 제시한다. 기술적으로는 거대한 모델이 아니라 출력 형식 프롬프트에 가깝지만, 이 신호가 중요한 이유는 코딩 에이전트의 병목이 점점 인간의 작업 기억으로 이동하고 있기 때문이다.
개발자는 이미 터미널, 브라우저, IDE, 이슈 트래커, 문서를 오간다. 에이전트가 긴 맥락 설명 뒤에 정작 실행할 명령을 숨기면 사용자는 한 번 더 파싱해야 한다. Claude의 하중 지지 단어, AI 문체는 UX 문제가 됐다가 지적한 것처럼 AI 문체는 취향 문제가 아니라 작업 속도 문제다.
접근성은 생산성 기능이다
이 저장소는 이름에 ADHD를 걸었지만, 핵심은 특정 진단을 가진 사용자만이 아니다. README도 "No ADHD diagnosis needed"라고 적는다. 작업 기억이 작고, 시작이 어렵고, 다음 행동이 모호하면 일이 멈춘다는 사실은 거의 모든 지식 노동에 적용된다. Web Content Accessibility Guidelines가 웹 접근성을 구조, 예측 가능성, 명확성으로 다루는 것처럼 에이전트 응답도 접근성 기준이 필요하다.
Microsoft Inclusive Design은 일시적, 상황적 제약까지 포괄한다. 야근 후 피로한 개발자, 장애 대응 중인 SRE, 모바일로 코드를 확인하는 팀장은 모두 "짧고 실행 가능한 답"을 원한다. 그래서 i-have-ADHD는 개인화 플러그인이 아니라 에이전트 제품 설계의 최소 단위를 보여준다.
| 출력 요소 | 사용자가 겪는 문제 | 스킬이 주는 해결 |
|---|---|---|
| 첫 줄 | 무엇부터 할지 모름 | 바로 실행할 행동 제시 |
| 단계 | 긴 문장 속 절차 누락 | 번호 목록으로 작업 분리 |
| 상태 | 이전 맥락을 잊음 | 현재 단계 반복 표시 |
| 마무리 | 다음 행동이 흐림 | 하나의 다음 단계만 남김 |
코딩 에이전트 시장의 차별화 포인트
모델 회사들은 더 큰 컨텍스트와 더 높은 벤치마크를 강조한다. 하지만 현장에서는 "정확하지만 읽기 어려운 답"도 비용이다. 코딩 에이전트가 고르는 도구가 시장을 정한다는 도구 선택권을 다뤘고, 이번 사례는 출력 선택권을 보여준다. 어떤 팀은 상세한 사고 과정을 원하고, 어떤 팀은 첫 줄 명령과 실패 시 대응만 원한다.
Claude Code 문서나 OpenAI Codex 안내 같은 도구 문서가 아무리 좋아도, 최종 사용자가 받는 한 턴의 형식이 흐리면 효과는 줄어든다. 국내 SaaS와 SI 조직이 에이전트를 도입할 때도 "우리 회사 답변 스타일"을 정의해야 한다. 보고 문화가 강한 팀과 장애 대응팀의 최적 형식은 다르다.
한국 팀을 위한 적용법
가장 현실적인 시작점은 에이전트 응답 규칙을 팀 플레이북으로 만드는 것이다. 예를 들어 장애 대응 에이전트는 첫 줄에 영향 범위와 다음 명령을, 코드 리뷰 에이전트는 첫 줄에 가장 위험한 변경점을, 기획 보조 에이전트는 첫 줄에 결정이 필요한 선택지를 둔다. 좋은 문화가 AI보다 큰 생산성 해킹이라는 주장과 이어지는 지점이다. 도구가 아무리 좋아도 팀의 실행 습관과 맞지 않으면 생산성은 새지 않는다.
GitHub Copilot 문서와 ADHD 관련 CDC 자료를 함께 보면, 개인의 인지 차이를 고려한 소프트웨어 설계가 점점 일반 생산성 설계로 흡수되고 있음을 알 수 있다. AI 에이전트도 같은 길을 갈 가능성이 높다.
자주 묻는 질문
Q1: 이 스킬은 모델 성능을 높이나요?
A: 정답률 자체를 높인다기보다 사용자가 답을 실행하는 마찰을 낮춥니다. 실제 생산성에는 이 차이가 큽니다.
Q2: 모든 답변을 짧게 만들면 손해 아닌가요?
A: 설명이 필요한 작업은 설명해야 합니다. 핵심은 다음 행동과 상태를 먼저 보여주고, 긴 설명은 뒤에 두는 것입니다.
Q3: 팀 전체에 적용해도 될까요?
A: 가능합니다. 다만 장애 대응, 코드 리뷰, 문서 작성처럼 업무별로 다른 출력 규칙을 두는 편이 좋습니다.
Q4: 한국어에서도 효과가 있나요?
A: 효과가 있습니다. 특히 존댓말과 완곡한 표현이 명령을 흐리게 만들 때, 첫 줄 행동 규칙이 도움이 됩니다.
Q5: 제품화 기회는 어디에 있나요?
A: 에이전트별 응답 템플릿, 팀 규칙 관리, 업무별 상태 표시, 실패 시 다음 행동 추천 같은 얇은 UX 계층입니다.
관련 토픽 더 보기
📰 원본 출처
github.com이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.