완성도를 높이는 기술
AI와 더 잘 일하는 방법들입니다. CLAUDE.md와 메모리로 기억력을 주고, 계획 모드로 방향을 먼저 잡고, 서브에이전트로 일을 나누고 검토받고, 이 둘을 합친 하이브리드로 계획 자체를 전문가에게 검토시킵니다.
오늘의 여정 — 지금 여기에 있습니다
AI가 나를 기억하게 하는 두 가지 방법
내가 직접 적어두는 규칙(CLAUDE.md) + Claude가 스스로 쌓는 기억(메모리)
# CLAUDE.md
## 브랜드 스타일
- 메인 컬러: #5D8A80 (청자)
- 배경: #FBF9F5 (아이보리) / 글자: #3C372F (먹)
- 폰트: 명조 계열 (Noto Serif KR)
- 톤앤매너: 차분하고 정제된, 갤러리처럼
## 규칙
- 모바일/태블릿/PC 자동 대응
- 한국어 UI
이 파일을 프로젝트 폴더에 넣으면, Claude가 매번 자동으로 읽고 따릅니다
AI에게 매번 같은 말을 반복하는 게 제일 지치는 일이죠. 이걸 없애는 방법이 두 가지예요. 헷갈리기 쉬우니 먼저 딱 갈라둘게요:
CLAUDE.md — 내가 쓰는 규칙서
내가 직접 “이 프로젝트에선 이렇게 해줘”를 파일에 적어두는 거예요. 브랜드 색, 말투, 하지 말 것 같은 규칙·취향. 내가 손으로 씁니다.
메모리 — Claude가 쌓는 기억
대화하면서 알게 된 나에 대한 사실을 Claude가 스스로 기억해두는 거예요. 내가 파일을 안 써도, “기억해둬” 한 마디면 다음 대화에서도 이어집니다.
한 줄로: CLAUDE.md는 내가 적는 설명서, 메모리는 Claude가 알아서 쌓는 노트예요. 둘 다 “다음에 또 설명 안 해도 되게” 만들어주지만, 쓰는 방법이 달라요.
1. CLAUDE.md — 내가 정해주는 규칙
CLAUDE.md는 프로젝트 폴더에 넣어두는 메모 파일입니다. Claude Code가 작업을 시작할 때 이 파일을 자동으로 읽어서, 매번 같은 말을 반복하지 않아도 규칙을 지킵니다.
CLAUDE.md가 뭔가요?
프로젝트 최상위 폴더에 CLAUDE.md 파일을 만들면, Claude Code가 매번 자동으로 읽고 지시사항을 따릅니다.
마치 “이 프로젝트에서 일할 때 이것만은 꼭 지켜줘”라고 적어두는 메모장이에요.
처음엔 /init으로 시작해 보세요
/init을 입력하면 프로젝트를 훑어보고 CLAUDE.md 초안을 만들어줘요. 다만 짧을수록 잘 지켜요. 공식 안내도 200줄 안쪽으로 간결하게 쓰라고 해요.실전 예시: 내 소개 페이지 스타일 저장
예를 들어 오늘 만드는 내 소개 페이지라면, 이렇게 적어두면 됩니다:
# CLAUDE.md
## 프로젝트 소개
내 작업과 나를 소개하는 페이지.
## 브랜드 스타일
- 메인 컬러: #5D8A80 (청자) — 제목, 포인트, 버튼
- 배경: #FBF9F5 (아이보리) / 글자: #3C372F (먹)
- 폰트: 명조 계열 (Noto Serif KR)
- 톤앤매너: 차분하고 정제된, 갤러리처럼
## 규칙
- 모바일/태블릿/PC 화면 크기에 맞게 자동 대응
- 한국어로 UI 텍스트 작성
- 이미지는 /public/images 폴더에 저장이후 “새 섹션 만들어줘”라고만 해도 자동으로 청자+아이보리, 명조, 반응형으로 만들어줍니다. 프롬프트에 색상이나 폰트를 다시 말할 필요가 없어요.
내 프로젝트에 맞게 바꾸기
위 예시는 이 가이드의 스타일이지만, 여러분이 만드는 프로젝트에 맞게 자유롭게 바꾸면 됩니다. 핵심은 색상을 # 코드로 정확히 적는 것이에요.
“파란색 써줘” → 매번 다른 파란색이 나옴
“#0055A7 써줘” → 100번 시켜도 같은 색
색상 코드를 모르겠으면 Claude에게 “깔끔한 파란색 추천해줘”라고 물어봐도 됩니다. 추천받은 코드를 CLAUDE.md에 적어두면 끝!
그런데 — CLAUDE.md에 다 때려넣으면 안 돼요
CLAUDE.md는 Claude가 작업할 때마다 통째로 다시 읽어요. 그래서 여기에 이것저것 길게 쌓아두면, 매번 그 긴 내용이 같이 실려서 대화가 무거워지고 토큰(사용량)도 그만큼 더 들어요.심지어 정작 중요한 지시가 긴 내용에 묻혀서 잘 안 지켜지기도 해요. 그래서 원칙은 — CLAUDE.md는 짧고 핵심만.
그럼 나머지 반복 작업이나 긴 규칙은 어디에 둘까요? 두 군데로 나눠 빼면 됩니다:
CLAUDE.md
항상 지켜야 하는 짧은 규칙·취향.“한국어로 써”, “디자인은 design.md 따라” 같은 한두 줄. 매번 읽혀도 부담 없을 만큼만.
별도 .md
가끔만 필요한 긴 참고자료·기준.디자인 시스템(design.md), 브랜드 가이드, 용어 정리 등. CLAUDE.md가 “필요하면 이거 봐”로 가리켜서, 그 작업을 할 때만 펼쳐 읽혀요.
스킬
순서가 정해진 반복 ‘작업’.자막 추출, 미팅 정리처럼 “이 순서로 처리해”가 있는 것. /명령어로 불러 쓰고, 필요할 때만 실행돼요.
구분이 헷갈리면 이렇게: “지켜야 할 규칙”이면 문서(CLAUDE.md/별도 md), “해야 할 작업 순서”면 스킬.길고 가끔 쓰는 문서는 별도 md로, 짧고 항상 쓰는 규칙만 CLAUDE.md에.
사실 제일 쉬운 방법 — AI에게 물어보세요
어디에 둘지 혼자 고민하지 말고, 상황을 그대로 말하고 추천받으면 돼요:
내가 매번 이걸 반복해서 시켜: [상황 설명]. 이걸 CLAUDE.md에 넣는 게 나아, 별도 md로 빼는 게 나아, 아니면 스킬로 만드는 게 나아? 이유랑 같이 추천해줘
디자인 규칙은 CLAUDE.md 말고 design.md로 빼세요
색·폰트·간격 같은 디자인 규칙이 많아지면 CLAUDE.md에 다 넣지 마세요.CLAUDE.md는 매번 통째로 읽히기 때문에, 디자인과 상관없는 작업을 할 때도 그 긴 규칙이 같이 실려서 무거워져요. 대신 이렇게 나눕니다:
CLAUDE.md (짧게)
“디자인은 design.md를 따른다” — 이 한 줄만.
design.md (자세히)
실제 색·타이포·컴포넌트 규칙은 여기에. 디자인 작업할 때만 펼쳐 읽혀요.
이러면 컨텍스트도 가볍고, design.md만 떼서 다른 프로젝트에 재사용하거나 팀에 공유하기도 쉬워요. 배포에 쓰는 Vercel도 한때 자사 디자인 시스템 ‘Geist’를 design.md 파일 하나로 공개했어요. 아래는 그 파일로 해본 실험이에요.
실측: Vercel이 공개한 진짜 design.md로 실험했습니다 — 서로 다른 세 주제가 한 브랜드로 묶입니다
왼쪽은 “미니멀하고 세련되게”만 준 결과 — 주제마다 제각각입니다. 오른쪽은 전부 같은 파일 하나를 읽었을 뿐인데, 세 페이지가 같은 회사 제품처럼 보입니다. 이게 디자인 시스템을 파일로 갖는다는 것의 의미예요. 실험에 쓴 파일 (Vercel 공개 원본, vercel.com/design.md)
design.md 안에는 보통 뭐가 들었나
“디자인 시스템을 파일로”가 막연하죠. 잘 만든 design.md를 열어보면, 디자이너가 머릿속에 갖고 있는 걸 AI가 그대로 따라 할 수 있게 숫자·이름으로 적어둔 거예요. 크게 여섯 덩어리예요:
색 (colors)
회색 10단계(gray-100~1000), 파랑·빨강·주황 등 색마다 100~1000 명암 단계, 반투명 단계까지 — 전부 이름과 # 코드로
글자 (typography)
heading-72부터 copy까지 크기별로 이름을 붙여둠. 폰트는 Geist Sans, 굵기는 600/500/400만
간격·모서리 (spacing·rounded)
여백과 둥근 정도를 정해진 값에서만 고르게 — 아무 숫자나 안 씀
컴포넌트 (components)
버튼(주요/보조/삭제)·입력창의 색·크기·호버/포커스 상태까지 규격화
말투 (voice & content)
버튼은 '동사+명사'(Deploy Project), 에러는 '무슨 일 + 어떻게'까지. 'successfully' 금지 같은 카피 규칙
해도 되는 것 / 안 되는 것
본문 대비 4.5:1 지켜라, 색만으로 상태 표시하지 마라, 모서리 둥근 거·각진 거 섞지 마라 등
design.md 쓰는 법 — 두 가지
남의 design.md를 그대로 쓰지는 마세요
CLAUDE.md가 내 design.md를 가리키게 하기
내 프로젝트 폴더에 design.md를 두고, CLAUDE.md엔 그걸 따르라고 한 줄만 적어두는 정석 구조예요:
# CLAUDE.md
## 디자인
- 모든 디자인은 design.md의 색·타이포·컴포넌트 규칙을 따른다.
- design.md에 없는 건 임의로 정하지 말고 나에게 물어본다.내 design.md 만들기 — Claude에게 시키면 돼요
직접 표를 짤 필요 없어요. 마음에 드는 사이트나 화면, 내 브랜드 색을 참고로 주고 만들어달라고 하세요:
한 번 만들어두면 “design.md대로 새 페이지 만들어줘” 한 마디로 매번 같은 톤이 나와요. 그리고 나중엔 이 파일을 ‘남의 작업 평가 기준’으로도 쓸 수 있어요 — “이 화면이 design.md를 잘 지켰는지 검토해줘”처럼요.
매번 5줄씩 반복 입력
CLAUDE.md 없이: 매번 색상, 폰트, 스타일을 반복 입력해야 합니다
동일한 프롬프트, 다른 CLAUDE.md — 결과물이 이렇게 달라집니다
AI한테 "AI 영어회화 캠프 수강 신청 페이지 만들어줘"라고만 한 결과. 보라색 그래디언트, 시스템 기본 폰트, 동그란 pill 버튼 — 전형적인 AI 기본 출력입니다.
CLAUDE.md 없음
아무 지시 없이 AI가 자기 재량으로 만든 결과입니다
프롬프트: "AI 영어회화 캠프 수강 신청 페이지 만들어줘" — 이게 전부입니다
Claude의 기억력 구조 — 3단계 레이어
대화 기억
이번 대화에서만 유효
“아까 말한 버튼 색 빨간색으로 바꿔줘” → 이번 채팅에서만 기억
프로젝트 CLAUDE.md
이 프로젝트에서만 적용
브랜드 색상, 코딩 규칙, 파일 구조 등
글로벌 설정
모든 프로젝트에 적용
선호 언어, 기본 톤앤매너, 공통 규칙
안쪽 레이어가 바깥쪽을 덮어씁니다 — 프로젝트 설정이 글로벌보다 우선
2. 메모리 — Claude가 알아서 기억하는 것
CLAUDE.md가 내가 손으로 적는 규칙서였다면, 메모리는 내가 파일을 안 써도 Claude가 대화하면서 알아서 기억해두는 기능이에요. “나 채식해”, “우리 회사 이름은 OO야” 같은 걸 한 번 말해두면, 다음에 새 대화를 열어도 기억하고 있어요.
기억시키기 — 그냥 말하면 돼요
대단한 설정 필요 없어요. 기억해두면 좋겠다 싶은 걸 그냥 말하세요:
확인·정리하기
Claude가 나에 대해 뭘 기억하고 있는지 궁금하면 “나에 대해 기억하는 거 보여줘”라고 물어보세요. 틀린 게 있으면 “그건 잊어줘”, 바뀌었으면 “이걸로 바꿔줘”라고 하면 됩니다. (Claude 설정 화면의 Memory 메뉴에서 직접 켜고 끄고 지울 수도 있어요. Claude Code에서는 /memory를 입력해서 확인하고 고칠 수 있어요.)
언제 뭘 쓸까 — CLAUDE.md vs 메모리
- 프로젝트에 딱 붙는 규칙(이 사이트 색·폰트·구조)은 → CLAUDE.md. 팀원과 파일로 공유되고 버전 관리돼요.
- 나라는 사람에 대한 사실·취향(말투·직업·반복 습관)은 → 메모리. 새 대화를 열어도 이어져요.
- 단, Claude Code의 자동 메모리는 프로젝트별·컴퓨터별로 따로 저장돼요. 다른 프로젝트나 다른 컴퓨터에는 따라가지 않아요.
헷갈리면 이렇게: “이 프로젝트”에 관한 거면 CLAUDE.md, “나”에 관한 거면 메모리.
민감한 정보는 넣지 마세요
초보자용 한 줄 요령
토큰·모델 다스리기
대화가 끝나면 Claude는 잊습니다 — 그러니 적어두게 하세요
새 대화를 열 때마다 Claude가 프로젝트를 처음부터 다시 파악하면, 그 탐색에만 사용량(토큰)이 뭉텅 나갑니다. 알아낸 것을 파일로 적어두게 하면 됩니다.
지금까지 알아낸 걸 PROJECT-NOTES.md에 정리해줘. 다음부터는 그 파일 먼저 읽고 시작해줘
다음 세션은 노트부터 읽고 시작하니 훨씬 적게 씁니다. CLAUDE.md에 규칙을 적어두는 것과 같은 원리 — 기억은 파일에, 대화는 가볍게.
같은 실수를 반복하면 — AI 말고 환경을 고치세요
AI가 같은 실수를 반복할 때 매번 “왜 그랬어, 다시 해”를 반복하면 시간과 사용량만 나갑니다. 대신 그 규칙을 CLAUDE.md에 한 줄 적어두면 반복이 끊깁니다.
방금 그 실수, 다시 안 하도록 CLAUDE.md에 규칙으로 적어줘
같은 Claude인데 결과가 다르다면 — 다이얼이 두 개라서예요. 모델 선택과 effort(작업 강도)는 완전히 다릅니다:
모델 — 품질 상한선
올릴수록 애초에 더 똑똑한 모델이 답함 (읽기 전용 — 프롬프트로 못 바꿈)
effort — 작업 강도
모델 = 품질 상한선을 정함 · effort = 그 상한선 안에서 얼마나 공들이는지(토큰↑)를 정함
틀렸을 때 뭘 올릴지: 몰라서 틀렸으면 더 큰 모델로, 덜 노력해서(파일 건너뛰기·검증 생략) 틀렸으면 effort를 올리세요. effort 단계는 low · medium · high · xhigh · max 다섯 가지예요. 평소엔 Sonnet이 가성비 좋은 기본값이고, Fable은 가장 어려운 일에만 쓰세요.
산출물 퀄리티 올리기
계획 모드, 서브에이전트, 그리고 둘을 합친 하이브리드
3. 계획 모드 — 만들기 전에 생각하게 하기
AI에게 바로 만들어달라고 하면 일단 뭐든 만들어내긴 합니다. 근데 방향이 틀리면 고치는 데 훨씬 오래 걸려요. 잘못된 계획을 되돌리는 데는 몇 초면 되지만, 이미 잘못 만들어진 결과물을 고치는 데는 훨씬 오래 걸립니다. 계획 모드에서 AI는 파일을 읽고 코드를 살펴볼 수는 있지만, 실제로 뭔가를 쓰거나 실행하지는 못해요 — 안전하게 둘러보기만 하는 상태라고 생각하면 됩니다.
계획 모드는 보통 이런 모습입니다
프롬프트 하나로 시작해서, 관련 파일부터 읽고, 계획이 뜨고, 애매한 부분은 AI가 되물어서 확인받고, 승인하면 그제서야 실행으로 넘어갑니다. 실제로 이 사이트에 다크모드 토글을 붙인다면 나올 법한 계획으로 흐름을 보여드릴게요 — 지금 이 사이트엔 다크모드가 없거든요.
여러 파일을 건드리는 중간 복잡도 예시예요 — 실제로는 계획이 이보다 짧을 수도, 훨씬 길 수도 있어요
켜는 법 세 가지
Shift + Tab 반복해서 누르기
입력창에서 Shift + Tab을 계속 눌러 보세요. 모드가 차례로 바뀌다가, 화면 아래에 “plan mode on”이 뜨면 켜진 거예요. 버전마다 누르는 횟수가 달라서 “몇 번”이 아니라 “표시가 뜰 때까지”로 기억하세요. 데스크톱 앱에는 모드 선택 메뉴가 있으니 거기서 계획 모드를 고르면 돼요.
/plan 입력하기
입력창에 /plan이라고 치면 계획 모드로 들어가요. 단축키가 잘 안 먹을 때 가장 확실한 방법이에요.
세션 시작부터 계획 모드로
터미널에서 세션을 시작할 때 옵션을 붙이면, 그 세션은 처음부터 계획 모드로 시작해요. 반복 작업을 스크립트로 자동화할 때 특히 유용해요.
claude --permission-mode plan
언제 쓰고, 언제 생략할까
이럴 때 쓰세요
- - 여러 파일에 걸친 큰 변경
- - 되돌리기 어려운 작업(배포·데이터 관련)
- - 지시가 애매해서 AI가 어떻게 이해했는지 먼저 보고 싶을 때
- - 처음 다뤄보는 낯선 코드베이스
이럴 땐 생략해도 돼요
- - 오타 수정 같은 한 줄짜리 변경
- - 빠르게 이것저것 시도해보는 중일 때
- - 그냥 코드를 읽고 질문만 할 때
- - 이미 뭘 할지 다 정해져 있을 때
실전에서 이렇게 써보세요
구체적으로 요청하기
그냥 “계획해줘”보다, 무엇을 계획에 넣어야 하는지 먼저 말해주면 훨씬 나은 계획이 나옵니다.
이 변경을 계획해줘. 어떤 파일들을 건드릴지, 각 파일에서 뭘 바꿀지, 순서는 어떻게 되는지까지 계획에 넣어줘.
계획을 약속처럼 다루기
계획을 승인했는데 진행하다 보니 상황이 계획과 달라지면, 그냥 즉흥적으로 넘어가게 두지 말고 다시 계획 모드로 돌아가서 계획 자체를 고치고 재승인하세요. 계획과 다르게 흘러가는 걸 방치하면 계획 모드를 쓴 의미가 없어집니다.
계획을 파일로 남겨두기
대화가 길어져서 내용을 정리하거나 세션이 끊겨도, 계획을 마크다운 파일로 저장해두면 그 파일을 다시 열어서 이어갈 수 있어요. “기준을 파일로 만들면 없어지지 않는다”는 원리가 계획에도 그대로 적용됩니다.
4. 서브에이전트 — 혼자가 아니라 팀으로
지금까지는 계획을 세운 다음 혼자 실행했어요. 근데 계획이 좋은지 판단하는 것도, 결과물을 검토하는 것도 계속 혼자 하면 한계가 있습니다. 다음은 그 일을 나눠 맡기는 법이에요 — 이게 있어야 뒤에 나올 하이브리드가 완성됩니다.
하나의 Claude가 여러 명의 Claude를 부립니다
지금까지는 Claude와 1:1로 대화했습니다. 그런데 일이 커지면 — 조사할 것도 많고, 검토도 필요하고, 정리도 해야 하면 — Claude는 서브에이전트를 만들어 일을 나눠 맡길 수 있습니다. 별도 설치나 설정 없이, Claude Code에 이미 들어 있는 기능입니다.
나
“이 셋을 조사·검토·정리해줘”
Claude
팀장 — 일을 나누고 결과를 모음
조사 담당
자료를 뒤져서 요약만 가져옴
검토 담당
결과물의 문제점만 찾아냄
작성 담당
정리된 재료로 초안을 씀
나
“이 셋을 조사·검토·정리해줘”
Claude — 팀장
일을 나누고 결과를 모음
조사 담당
자료를 뒤져서 요약만 가져옴
검토 담당
결과물의 문제점만 찾아냄
작성 담당
정리된 재료로 초안을 씀
대화가 안 어질러져요
서브에이전트가 자료 100개를 뒤져도, 본 대화에는 요약 한 장만 돌아옵니다.
역할을 좁히면 잘해요
“검토만 해, 고치지는 마” — 일이 좁을수록 결과가 깊어집니다.
여럿이 동시에 일해요
다섯 가지 조사를 다섯 에이전트가 동시에 — 기다리는 시간이 줄어듭니다.
가장 좋은 첫 사용법 — 전문가 검토자 붙이기
내가 만든 결과물을 나 혼자 보면 문제가 안 보입니다. 만든 Claude와 다른 눈에게 검토를 시켜보세요. 이때 성능이 확 올라가는 핵심은 두 가지 — 누구인지, 뭘 봐야 하는지를 명확히 알려주는 거예요.
1. 누구인지
어떤 분야의 전문가 역할인지 알려주기
“UX 디자이너 역할로”
2. 뭘 봐야 하는지
구체적인 리뷰 기준을 제시하기
“모바일 사용성 관점에서”
깃허브 스타 10만 개가 넘는 "UI UX Pro Max"라는 스킬은 업종별로 161개 디자인 룰을 미리 정해뒀어요. 같은 항목인데 업종마다 기준이 정반대가 되는 게 핵심이에요:
은행 앱
장난스러운 그라디언트 ❌
럭셔리 브랜드
빠른 애니메이션 ❌ (느림 = 고급스러움)
키즈 학습 앱
차분한 색 ❌ (반대로 원색·채도가 정답)
은행 앱
장난스러운 그라디언트 ❌
럭셔리 브랜드
빠른 애니메이션 ❌ (느림 = 고급스러움)
키즈 학습 앱
차분한 색 ❌ (반대로 원색·채도가 정답)
“모바일 사용성 관점에서”보다 “이 업종에서는 이게 금지”처럼 구체적으로 줄수록 서브에이전트 리뷰 품질이 올라갑니다
실전 예시
UX 리뷰
“서브에이전트를 만들어줘. UX 디자이너 역할이고, 이 랜딩 페이지를 사용자 동선, CTA 배치, 모바일 사용성 관점에서 리뷰해줘”
카피라이팅 리뷰
“서브에이전트를 만들어줘. 마케팅 카피라이터 역할이고, 이 페이지의 헤드라인과 설명 문구를 전환율 관점에서 리뷰하고 개선안을 줘”
고객 관점 리뷰
“서브에이전트를 만들어줘. 이 서비스를 처음 보는 고객 역할이고, 뭘 파는 건지 바로 이해되는지, 신뢰가 가는지, 가격이 비싸 보이진 않는지 리뷰해줘”
여러 전문가를 동시에
한 번에 여러 관점으로 리뷰를 받을 수도 있어요:
이렇게 하면 서브에이전트가 병렬로 동시에 리뷰하고, 결과를 합쳐서 보여줍니다. “서브에이전트에게 시켜줘”, “나눠서 동시에 해줘” 정도의 표현이면 Claude Code가 알아서 팀을 꾸립니다. 명령어를 외울 필요가 없어요.
판단은 언제나 내가
검토 결과를 보고 나서 “1번과 3번만 고쳐줘”라고 하면 됩니다. AI는 제안하고, 사람이 결정해요.
이 교재도 그렇게 만들어졌습니다
지금 보고 계신 심화 페이지들은, 싣기 전에 ‘코딩이 처음인 수강생’ 역할과 ‘깐깐한 강사’ 역할의 서브에이전트에게 먼저 읽혔습니다. 어렵다·불친절하다는 지적이 나온 부분을 고친 뒤에 실었어요.
수업 준비 자료조사도 다섯 갈래로 나눠 서브에이전트들이 동시에 했습니다. 혼자였으면 며칠 걸릴 일이 한나절로 줄어듭니다.
.claude/agents/ — 역할을 파일 하나로
매번 “깐깐한 검토자 역할로…”라고 설명하는 게 번거로우면, 역할을 파일로 저장해 둘 수 있습니다. 프로젝트 폴더의 .claude/agents/ 안에 파일 하나 = 전문가 한 명입니다. 점(.)으로 시작하는 폴더라 평소엔 눈에 안 보이지만, 직접 찾아 들어갈 일은 없어요 — 이 파일도 Claude에게 만들어달라고 하면 됩니다:
디자인 검토 전문 서브에이전트를 만들어줘. 이름은 design-reviewer. 역할: 결과물을 보고 잘한 점과 아쉬운 점을 근거와 함께 지적만 하고, 직접 고치지는 않는다
Claude가 이런 파일을 만들어줍니다:
# .claude/agents/design-reviewer.md
---
name: design-reviewer
description: 디자인 결과물 검토 전문. 검토만 하고 고치지 않는다.
---
결과물을 보고 잘한 점 2가지, 아쉬운 점 3가지를
근거와 함께 지적한다. 직접 수정하지 않는다.이후로는 “design-reviewer에게 검토시켜줘” 한 마디면 됩니다. 기준이 파일이 되는 순간, 내 감각이 반복 가능한 도구가 됩니다 — 스킬 만들기에서 배운 것과 같은 원리예요.
5. 하이브리드 — 계획을 전문가에게 검토시키기
계획 모드와 서브에이전트, 이제 둘 다 손에 익었을 거예요. 이 둘을 합치면 어떻게 될까요 — 계획이 나왔을 때 바로 승인하지 않고, 그 계획 자체를 전문가 페르소나 서브에이전트에게 검토시키는 방법이에요. 서브에이전트가 짚어준 걸 계획에 반영해서 보완한 다음에야 승인하고 실행합니다. 계획 하나로 끝내는 것보다, 실행 전에 한 번 더 걸러내는 거예요.
프롬프트
원하는 걸 말로 시킴
계획 생성
계획 모드로 방향부터
전문가 리뷰
서브에이전트가 검토
프롬프트
원하는 걸 말로 시킴
계획 생성
계획 모드로 방향부터
전문가 리뷰
서브에이전트가 검토
계획 보완
피드백을 계획에 반영
승인 · 실행
그제서야 진행
계획 보완
피드백을 계획에 반영
승인 · 실행
그제서야 진행
검토에서 큰 문제가 나오면 이 계획→검토 구간을 다시 반복할 수도 있어요
실제로 이런 흐름입니다
앞서 본 다크모드 토글 계획을 이어서, 승인 전에 UX 전문가 서브에이전트에게 검토를 맡기면 이렇게 진행돼요.
검토에서 나온 지적(그림자·포커스 링 대비)이 계획에 그대로 새 항목으로 추가된 걸 보세요
이렇게 말하면 됩니다
이 계획을 [UX / 보안 / 성능] 관점에서 검토하고, 놓친 게 있으면 계획에 추가해줘.
언제 특히 좋은가