클로드 코드 관련
자주 사용하는 클로드 코드 단축키
단축키
설명
Ctrl + C
현재 입력이나 클로드의 현재 생성 중인 아웃풋을 중단합니다.
Ctrl + D
클로드 코드 세션을 종료합니다.
Ctrl + L
클로드 코드와의 대화를 유지하며 사용자 대화창의 입력을 전부 삭제합니다.
위/아래 방향키
기존에 실행했던 메시지를 조회합니다. 위·아래로 기존 클로드에게 지시했던 메시지들을 조회할 수 있습니다.
Esc + Esc
직전 메시지로 회귀합니다. 해당 메시지를 보내기 직전으로 클로드와의 대화를 롤백하는 효과가 있습니다.
\ + Enter
메시지 창에서 줄바꿈을 합니다. 모든 터미널에서 사용할 수 있습니다.
Option + Enter (macOS)
메시지 창에서 줄바꿈을 합니다. macOS 기본 세팅입니다.
Shift + Enter
/terminal-setup 명령어 실행 후 Shift + Enter를 사용해서 줄바꿈합니다.
# [메시지]
CLAUDE.md에 빠르게 기억해야 할 요소를 추가하는 명령어입니다.
/ [명령어]
슬래시 명령어를 실행합니다.
콘텍스트 정리
/compact
클로드 코드와 대화가 길어지면 콘텍스트 윈도우 한계치가 넘어가면서 새로운 정보를 받아들이지 못하는데, 이때 /compact 명령어를 실행하면 지금까지 콘텍스트 내용을 요약해서 중요한 내용만 콘텍스트로 남겨놓음
설정 변경
/config
 - Auto-compact
- 컨텍스트 윈도우가 꽉 찼을 때 자동으로 /compact 명령어를 실행할지 여부
- Use todo list
- 클로드 코드가 긴 작업을 수행할 때 작업 순서를 Todo 리스트로 만들어 사용자에게 보여줄지 여부
- Verbose output
- 출력 결과를 길게(자세하게) 보여줄지 여부
- Theme
- 원하는 클로드 코드 테마를 지정할 수 있는 옵션
- Notifications
- 클로드 코드의 작업이 끝났을 때 어떤 알림을 보여줄지 선택 가능
- Editor mode
- normal mode와 vim mode 중 선택 가능
- vim mode를 선택하면 vim 키바인딩으로 클로드 코드를 사용할 수 있음
- Model
- 사용할 모델을 선택하는 옵션
메모리관리
/memory
클로드 코드는 CLAUDE.md 라는 settings.josn 파일과 같은 역할을 한느 파일이 있다. 프로젝트 루트에 CLAUDE.md 파일과 사용자 단위를 설정하는 ~/.claude/CLAUDE.md 파일이 존재함
프로젝트별 설정과 전역으로 설정하는걸로 나눠서 할 수 있다.
CLAUDE.md 파일
클로드 코드는 이 파일을 읽어 프로젝트의 아키텍처, 코딩 규칙, 작업 절차 등을 깊이 있게 파악함. 새로운 팀원에게는 프로젝트를 설명하는 브리핑 문서임
컨텍스트 윈도우로 인하여 새 채팅을 열때마다 기존 컨텍스트가 초기화 되는 것을 CLUADE.md 파일을 이용해서 프로젝트의 복잡한 내용을 설명할 필요가 없어짐
CLAUDE.md 파일에 어떤 정보를 입력해야 하는가?
엔트로픽에서는 아래와 같은 내용들을 작성하면 좋다고 함
- 자주 사용하는 bash 명령어
- 핵심 파일 및 유틸리티 함수
- 코드 스타일 가이드라인
- 테스트 지침
- 저장소 에티켓
예: 브랜치 이름 지정, 병합(merge), 리베이스(rebase)등
- 개발자 환경 설정
예: pyenv사용, 작동하는 컴파일러 등
- 프로젝트에 특정한 예상치 못한 동작이나 경고
- 클로드 코드가 기억했으면 하는 기타 정보
- 일괄적으로 사용하고 싶은 라이브러리에 대한 정보
- 또는 아키텍처에 대한 정보
프로젝트 메모리
./CLAUDE.md
가장 일반적인 유형의 메모리 파일
팀 전체에 적용할 규칙과 정보를 담고 있다.
로컬 프로젝트 메모리
./claude.local.md
개인적인 프로젝트 관련 설정을 위한 파일. 팀과 공유하지 않음
(gitignore 필수)
해당 파일이 사용되는 것들은 아래와 같음
- sandbox URL
- 개인 API 키 또는 테스트 데이터
- 자신에게 유용한 맞춤형 명령어
사용자 메모리
~/.claude/CLAUDE.md
홈 디렉토리에 위치하며, 모든 프로젝트에 적용되는 전역 설정을 저장합니다. 다음과 같은 설정을 하면 이상적입니다.
- 일반적인 코드 스타일 선호도
예: 항상 2칸 들여쓰기 사용
- 개인 도구를 위한 단축키
CLAUDE.md 파일 관리 노하우
CLAUDE.md 파일은 클로드 코드에 전달하는 프롬프트의 일부가 되는 것
파일을 한 번 작성한 다음에 효율성이 좋은지 좋지 않은지 검토하지 않으면서 내용을 계속 추가하는 것은 안좋은 방법
프로젝트를 효율적으로 진행하기 위해서는 이 파일을 계속해서 관리해야 함
클로드 코드를 쓰면서 바로 수정하기
클로드 코드 실행 상태에서 CLAUDE.md에 직접 내용을 추가할 수 있는 방법이 있다.
# 키를 눌러 클로드 코드에 지시를 내리는 방법. #키를 눌러서 지시를 내리면 지시 내용이 CLAUDE.md 파일에 자동으로 통합됨
- Important 나 You must 등 강조 표현을 사용하면 좋음
강조 키워드를 적은 내용은 compact 실행시에도 살아남을 가능성이 있음
클로드 코드에게 주기적으로 관리하라고 하기
클로드 코드에게 파일을 정리하라고 하기
예: prompt
CLAUDE.md 파일이 너무 커지는 것 같으니 프로젝트를 전반적으로 다시 이해하고 필요 없는 내용은 삭제하고 과도한 내용은 축소하고 싶어, 수정된 내용을 추천해줘
클로드 코드는 CLAUDE.md 파일을 어떻게 읽을까?
클로드 코드는 프로젝트 내 모든 디렉토리안에 있는 CLAUDE.md 또는 CLAUDE.local.md 파일을 읽음.
따라서 gradle multi module의 경우 모듈별 CLAUDE.md 파일을 관리하면 효과적으로 작업할 수 있음 하지만 하위 CLAUDE.md파일을 읽지 않는 경우가 있기 때문에 잘 지시해서 해야함
CLAUDE.md 파일은 다 커밋해야할까?
커밋해야함
클로드 코드 3가지 모드
일반모드
하나한 확인해보고 싶을 때 사용할 수 있다.
일반 모드를 사용하면 다음과 같은 상황에서 유용할 수 있다.
- 새 라이브러리나 프레임워크를 도입하면서 기본 사용법을 익힐 때
- 특정 로직을 구현하기 위한 다양한 알고리즘 아이디어를 얻고 싶을 때
- 발생한 오류 메시지의 의미를 정확히 이해하고 싶을 때
- 코드 리뷰 전 자신의 코드에 대한 제3자의 의견을 구하고 싶을 때
- 아직 클로드 코드를 신뢰하지 못하여 하나씩 내가 컨트롤 하고 싶을 때
자동수정모드
사용자에게 허락받지 않고 직접 코드를 수정함
일반 모드 보다 조심히 사용해야 함. 개발자와 클로드 코드의 의도가 일치하지 않을 수 있음. 콘텍스트 윈도우 제한을 넘기면 클로드 코드는 흐름을 잃음
추천되는 상황
- 프로젝트에 전반에 걸쳐 사용한 변수명, 함수명, 클래스명을 일괄 변경할 때
- 기존 코드를 최신 패턴이나 스타일 가이드에 맞도록 리팩토링할 때
- JSDoc등 문서 작업을 할 때
- 단순한 작업을 반복해서 해야 할 때
- 테스트 코드를 작성해야 할 때
플래닝모드
클로드 코드의 핵심적인 기능이고, 가장 많이, 가장 오래 사용해야되는 기능
plan mode on
이후 질문하는 내용을 이야기 하면 답변을 정리해서 알려줌
플래닝 모드는 무조건 Yes를 누르면 안됨
첫 번째 플랜에 Yes를 바로 하지 않는 것을 추천
No, keep planning을 더 자주 누를 것이 좋음
계획이 너무 크면 제어할 수 있는 범위 내에서 작업을 나눠 진행하는게 좋음
Claude Opus 4 : 프런티어 전문가 모델
고급 추론, R&D, 에이전트 워크플로우 현존하는 어려운 과제를 해결을 위한 모델
Claude Sonnet 4: 고성능 엔터프라이즈 실무자
지능, 속도, 비용의 균형을 최적으로 맞춘 모델
 출처 : <클로드코드 완벽="" 가이드="">
모델 선택 방법
계획은 Opus, 빠른 코드 작성은 Sonnet
CoT (Chain of Thought)
사고의 사슬, 논리적 사고 과정의 뜻의 프롬프트 기법임
AI가 최종 답변을 내놓기 전에, 사고 과정을 명시적으로 기술하도록 유도함
CoT를 사용했을 때 장점
- 정확성
- 일관성
- 디버깅 용이성
CoT 유도하는 방법
프롬프트에 ‘생각해라’ 문구가 들어 있으면 대체로 사고를 잘하게 된다고함
ex) prompt 예시
REST API를 구축하려면 어떻게 해야 해? 생각 과정을
확장된 사고(Extended Thinking) 사고의 사슬에서 한 단계 발전한 기능.
이 기능을 사용하면 응답 생성시 더 많은 노력을 들이고, 이 노력을 사고 예산(Thinking Budget) 이라고 함
확장된 사고를 하게 하려면 ‘고민해라’ 라고 이야기하면 된다고 함
ex)
- 고민해라(think)
- 깊게 고민해라(think hard)
- 더 깊게 고민해라(think harder)
- 최대로 깊게 고민해라?(ultra think)
커스텀 슬래시 커멘드
프로젝트 커스텀 슬래시 커맨드
위치
- .claude/commands/
사용자 커스텀 슬래시 커멘드
위치
- ~/.claude/commands/
Claude에 요청시 “내 생각이 잘 반영되게” 만드는 5가지 문서 습관
-
PRD는 2장 이하: 상단에 Invariants/Out-of-scope, 중간에 상태도/계약, 하단에 수용 기준/예시.
-
예시-우선: 설명 대신 실제 입력/출력 샘플(JSON) 2~3개로 말하기.
-
ADR는 짧게: “결정-이유-대안-결과” 4개의 소제목만.
-
질문 로그: “가설/근거/다음 액션” 3열 표. 회의록 대신 이 표만 업데이트.
-
바꿀 수 있는 구역 표시: PRD에 ‘⚠ 변경 가능’ 마크로 논쟁 지점을 따로 표기(합의 전/후를 명확히).
ADR : Architecture Decision Record
PRD : Product Requirements Document
문서 레이아웃
/docs
/prd
PRD_v0.1.md # 현재 합의본(2장) CHANGELOG.md # Added/Changed/Removed 요약 /adr
ADR-0001-routing-vs-mcp.md ADR-0002-legal-auto-check-mvp.md /rfc
RFC-0001-websocket-schema.md /logs
QUESTIONS.md # 계속 추가되는 질문·답변·오픈 이슈
생각보다 이렇게 작성하면 좋은 점이 프롬프트를 이용해서 요청할 때, 위와 같은 형식으로 작성하는 것을 먼저 CLAUDE.md에 정의시킨다.
그리고 항상 요청하는 말미에 나는 나에게 궁금한 게 어떤 것들이 있는지 물어보면, QUESTIONS.md에 질문 답변 형태로 기록할 수 있도록, Claude가 궁금한 사항을 나에게 물어보고 답변한 내용을 작성해줘서 편리하다.
몇일 동안 진행해본 결과 꽤 재밌고 흥미진진하게 일을 진행했던 것 같다. 직접 코드를 작성하지 않고, 그저 작성된 내용을 내가 요청한 사항에 맞춰서 개발 되었는지, 누락된 부분이 있으면 위의 PRD문서와 비교하여 어떤 점들이 부족했었는지를 알 수 있었던 것 같다. 좀더 반복해서 진행하다보니 익숙해지고, 추가적으로 관련된 작업을 진행할 때 일정 단계로 PRD를 나누기 시작했고, 커밋도 단위를 적게 가져가면서 작성하게 되었다.
각 문서별 Template 아래와 같다. 위에서 언급한 것과 동일하게 내용을 주고, CLAUDE.md 파일에 기록해 달라고 하면 좋을 것 같다.커
PRD 뼈대
PRD: 웹 페이지 제작 멀티-에이전트 (MVP)
Last updated: YYYY-MM-DD (Asia/Seoul)
1) 의도/경계
-
Invariants: (예) 입력은
prompt + countries, SimpleVectorStore, 일일 학습, HITL 비활성. -
Out-of-scope: (예) 프로덕션 배포, 결제, 이미지 생성.
2) 사용자 흐름(상태도 요약)
RECEIVED → PM_REVIEW(GO/CLARIFY/STOP) → PLANNING → DESIGN → LEGAL_AUTO → CULTURE → DEV → PM_QA → DELIVERED
(개발 이슈=DEV 회귀 / 콘텐츠 이슈=PLANNING 회귀)
3) 계약(Contracts)
3.1 JobCreateRequest
-
prompt: string(필수) -
countries: string[](선택, 기본 US/IN/ID/BR/MX)
3.2 WebSocket Event
{ jobId, at, stage, message, links[] }
Topic: /topic/jobs/{jobId}/events
3.3 RAG Metadata (필수 키)
country, domain, published_at, license, citation(effective_date)
3.4 Tools (IDs only)
rag_search, legal_check, dev_preview, a11y_check, dev_lint, dev_test
4) 수용 기준(DoD)
-
모든 이벤트는 WS로 방출, 메시지 내 근거/링크 포함.
-
LEGAL_AUTO 위반 신호 없으면 통과, 있으면 PLANNING 회귀.
-
DEV 단계에서 프리뷰 URL과 a11y/SEO 리포트 제공.
5) 예시
5.1 직진 시나리오
Request: { "prompt":"...", "countries":["US","BR"] }
Timeline: RECEIVED → PM_GO → PLANNING → DESIGN_READY → LEGAL_OK → CULTURE_OK → DEV_READY(https://..) → PM_ACCEPT → DELIVERED
5.2 CLARIFY 시나리오
Request: { "prompt":"" } → PM_CLARIFY 메시지(부족 필드 안내)
5.3 LEGAL 회귀 시나리오
Request: "경품 현금 지급 문자 강조" → LEGAL_NEEDS_REWORK → PLANNING
ADR 뼈대
ADR-000X: 결제/법률 자동검증을 MVP에서 어떻게 다룰 것인가
상황
MVP는 HITL 비활성. 그러나 법률 위험은 존재.
결정
LEGAL_AUTO 규칙 기반 검증 사용. 위반 신호 시 PLANNING 회귀.
대안
(1) 전량 HITL (2) 법률 스킵
결과
속도 우선. 추후 v0.x에서 일부 국가만 HITL 옵션화.
Question Log 뼈대
| 날짜 | 질문/가설 | 근거/논의 | 결론/다음 액션 |
|——|———–|———–|—————-|
| 2025-12-09 | MX 법률에서 쿠키 배너 필수? | 자료 링크 A, 초안 규칙 B | LEGAL_AUTO 규칙에 추가 |
TBD