Claude Code 답변을 읽기 쉽게 만드는 3가지 방법: 인지 부하를 줄인 개선점
요약
Claude Code의 답변을 구조화하고 가독성을 높이는 세 가지 방법을 제시합니다. 'i-have-adhd' 스킬 사용, 라벨이 붙은 도표 활용, 목록 및 표를 이용한 정리 등은 인지 부하를 줄여 핵심 정보를 빠르게 파악하도록 돕습니다.
핵심 포인트
- 'i-have-adhd' 스킬로 결론과 다음 행동을 먼저 제시받기 용이합니다.
- 라벨이 붙은 도표는 복잡한 처리 과정 간의 흐름 이해에 도움을 줍니다.
- 목록, 표, 번호 순서를 활용하여 필요한 정보를 쉽게 찾고 구조화할 수 있습니다.
Claude Code가 작업을 마친 후, 그 답변을 읽는 데 코드를 리뷰하는 것만큼 집중력을 사용해야 할 때가 있었습니다.
반복적으로 확인했던 것은 다음 세 가지였습니다.
- 결론은 무엇인가?
- 각 처리 과정들은 어떻게 연결되어 있는가?
- 내가 해야 할 일은 무엇인가?
이것들을 찾기 쉽게 만들기 위해, i-have-adhd 스킬, 도표를 사용한 설명, 긴 문장을 피하고 구조화된 답변이라는 세 가지 개선점을 적용하기 시작했습니다.
※본 기사는 영어 원문을 ChatGPT를 사용하여 일본어로 번역한 것입니다.
| 읽기 어려웠던 이유 | 도입한 방법 | 읽기 쉬워진 점 |
|---|---|---|
| 긴 설명 속에 결론이 묻힘 | i-have-adhd 스킬 | 결론과 다음 행동을 처음에 알 수 있음 |
| 처리 과정 간의 연결고리를 상상하기 어려움 | 라벨이 붙은 작은 도표 | 상세 내용을 읽기 전에 흐름을 파악할 수 있음 |
| 필요한 정보를 찾기 위해 단락을 반복해서 읽음 | 목록(Bullet Point)・표・번호 순서 |
판단 사항, 변경점, 작업을 방해하는 문제 등을 쉽게 찾을 수 있습니다.
이해에 필요한 설명은 남깁니다. 모르는 용어는 답변이 길어져도 설명을 요청합니다.
아래 예시는 실제 작업에서 받은 Claude Code의 답변입니다. 프로젝트명과 테이블명은 변경되었습니다.
인용 부분은 한국어로 번역했습니다. 분량은 영어 원문 기준입니다.
계기는 Claude Code 플러그인으로 사용할 수 있는 i-have-adhd라는 스킬이었습니다.
이 스킬에는 바로 행동에 옮길 수 있는 답변을 먼저 제시하고, 순서에 번호를 매기며, 불필요한 서론을 생략하는 등의 규칙이 있습니다.
답변을 다 읽고 나서 '그래서 뭘 해야 하는지'를 다시 생각해야 하는 부담을 줄여줍니다.
같은 질문에 대한 두 가지 답변입니다. 왼쪽이 원래의 답변이고 오른쪽이 정리된 답변입니다. 둘 다 Markdown 형식으로 표시되어 있습니다.
| 원래 답변 (430단어) | 정리된 답변 (40단어) |
|---|---|
관련 없는 진행 보고는 사라졌습니다.
시험해 보려면 터미널에서 다음 명령을 실행하고, Claude Code에 /i-have-adhd를 입력합니다. 자세한 내용은 프로젝트 설치 절차를 참조하세요.
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd
매번 명령어를 입력하지 않고 모든 세션에서 스킬을 로드하려면, 다음 파일을 만듭니다.
touch ~/.claude/.i-have-adhd-always
누가 요청을 보냈고, 서버가 무엇을 반환하며, 화면에 무엇이 표시되는지. 여러 요소를 관련지어 이해해야 하는 설명도 있습니다.
그럴 때는 먼저 작은 도표를 그리도록 요청합니다.
예를 들어, HTML 폼과 JavaScript의 fetch()를 비교한 답변은 다음 도표로 시작했습니다.
HTML 폼으로 전송 fetch()로 전송
────────────────────────── ──────────────────────────
[문의 페이지] [문의 페이지]
...
왼쪽은 다른 페이지로 이동하고, 오른쪽은 현재 페이지의 표시를 업데이트합니다.
요청 헤더나 응답 형식에 대한 설명을 읽기 전에, 그 차이점을 알 수 있습니다.
규칙은 간단합니다.
흐름이나 관계를 설명할 때는 라벨이 붙은 작은 도표를 먼저 하나 제시한다.
단순한 답변이나 값을 하나만 답하는 경우에는 도표를 사용하지 않는다.
표시 환경이 지원하면 Mermaid를 사용한다.
...
제목이 달려 있어도, 필요한 정보를 찾아야 하는 답변들이 있습니다.
그래서 질문에 맞춰 답변의 형식을 바꿔달라고 요청했습니다.
| 질문 | 답변 형식 |
|---|---|
| 이거 할 수 있나요? | 결론 → 조건이나 제약 |
| ... | |
| 실제로 SQL 쿼리 하나 앞뒤로 6개의 단락이 있고, 전체가 183단어에 달하는 답변이 있었습니다. |
'너무 많은 산문(too much prose)'이라고 응답하자, 다음 답변은 72단어가 되었습니다.
내용은 제 프로젝트 고유의 것이므로, 여기서는 답변의 형태만 봐주세요.
| 원래 답변 (183단어) | 정리된 답변 (72단어) |
|---|---|
저는 이것을 'no-prose' 규칙이라고 부릅니다. 개발 중 보고에서는 단락보다 목록(Bullet Point)・표・순서를 우선하도록 요청하는 규칙입니다.
이런 형태라면, 답변 전체를 다 읽지 않아도 필요한 부분을 찾을 수 있습니다.
글의 양을 줄여달라고 요청한 결과, 오히려 이해하기 어려워지는 경우도 있었습니다.
제2절의 HTML 폼과 fetch()에 대해 실제로 받은 세 가지 답변을 비교해 보면 다음과 같습니다.
| 답변 | 단어 수 | 읽은 감상 |
|---|---|---|
| 첫 번째 답변 | 896 | 글이 너무 많다 |
| ... | ||
| 이해하기 쉬웠던 답변은, 세 개 중 가장 길었습니다. |
새로운 개념마다 제목(見出し)이 있었고, 용어를 사용하기 전에 그 의미가 설명되어 있었습니다. 또한, 제목의 수도 첫 번째 답변의 2개에 비해 11개나 되었습니다.
제2절의 그림도 이 상세한 설명 안에 포함되어 있었습니다.
지금은 다음과 같이 요청하고 있습니다.
- 이미 이해하고 있는 주제라면, 짧게 답할 것.
- 학습 중인 주제라면, 새로운 개념마다 절(節)을 나눌 것.
- 전문 용어가 처음 나올 때는, 쉬운 말로 의미를 설명해 줄 것.
제가 사용하고 있는 지시사항을 간단히 요약하면 다음과 같습니다.
## 답변 스타일
- 결론, 판단 또는 현재 작업을 방해하는 문제부터 작성하기.
- 조사 결과는 목록(Bullet Point), 절차는 번호가 매겨진 목록(Numbered List), 비교는 표(Table)를 우선하기.
...
이것들은 모델에 대한 지시사항이며, 매번 반드시 이 형식으로 될 것이라고 보장하는 것은 아닙니다. 이러한 차이는 Claude Code의 지시 파일 관련 문서에서도 설명되어 있습니다.
'결론부터', '그림으로', '글이 너무 많다'. 여러 번 입력했던 수정 요청을, 먼저 하나로 명확한 규칙처럼 작성해 보세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기