개요

클로드 코드 사용기

CLAUDE.md

효율을 좌지우지 하는 파일, 루트 폴더에 생성되며 이 파일을 읽어 프로젝트의 절차를 파악하고 만듬
LLM에서 새 대화를 하는것은 새로운 팀원과 협업하는것과 같음
#로 구분해서 제목별로 적당한 지시를 해두면 됨
- 자주 사용하는 bash 명령어
- 핵심 파일 및 유틸리티 함수
- 코딩 컨벤션
- 테스트 지침
- 저장소 룰
- 개발자 환경설정
이 파일의 목적은 프로젝트를 이해시키는 것에 있지만 3가지로 분류할 수도 있음
- 프로젝트 메모리 (./CLAUDE.md) : 프로젝트 루트에 위치하며 전체에 적용할 규칙
- 로컬 프로젝트 메모리 (./claude.local.md) : 샌드박스나 개인 API 키 같은 것
- 사용자 메모리 (~/.claude/CLAUDE.md) 홈 디렉토리에 있음 전역설정
계속해서 관리를 해야함
- 지금까지의 대화를 기반으로 CLAUDE.md에 추가할 만한 내용을 추천해줘
- CLAUDE.md 파일이 너무 커지고 있는 것 같아. 프로젝트를 전반적으로 다시 이해하고 CLAUDE.md에 필요없는 내용은 삭제하고 과도한 내용은 축소하고 싶어. 수정된 내용을 추천해줘.
상위 폴더는 처음 실행할 때 재귀적으로 읽음. 하위는 들어갈 때 읽음

모드

총 3가지가 있음

일반 모드

새 라이브러리나 프레임워크를 도입하면서 기본 사용법을 익힐 때
특정 로직을 구현하기 위한 다양한 알고리즘 아이디어를 얻고 싶을 때
발생한 오류 메시지의 의미를 정확히 이해하고 싶을 때
코드 리뷰 전 자신의 코드에 대한 제 3자의 의견을 구하고 싶을 때
하나씩 내가 컨트롤하고싶을 때
클로드 코드가 수정 사항을 보여줌주 그리고 수정할 지를 물어봄

자동 수정 모드

클로드가 알아서 판단하고 알아서 수정하는 모드
컨텍스트 윈도우 제한을 넘기면 클로드는 흐름을 잃음
프로젝트 전반에 걸쳐 사용한 변수명, 함수명, 클래스명을 일괄 변경할 때
기존 코드를 최신 패턴이나 스타일 가이드에 맞도록 리팩토링할 때
문서작업할 때
단순 반복 작업할 때
테스트 코드 작성할 때

플래닝 모드

구조와 개발 계획 수립 단계에서 활용
어떤 기술 스택을 사용하고 파일 구조는 어떻게 가져가야 할까와 같은 것

모델

계획은 Opus, 빠른 코드 작성은 Sonnet
- Opus는 추상적인 생각과 어려운 문제를 해결하는 것
- 계획이 명확하고 상세한 목적이 있는 것은 소넷으로 ㄱㄱ(뭐 만들어줘 구현해줘 같은것)
작업 시간
- 세션은 첫 요청이 온 뒤로부터 5시간동안 유지
- 8~13시 13~18시 이런식으로 매크로 하나 돌려놓음

CoT (Chain of Thought)

LLM은 좋은 데이터를 학습하는 것을 넘어 주어진 과제를 얼마나 깊이 있게 사고하는지.
사고 과정을 명시적으로 기술하도록 유도함. 각단계를 검증하며 진행하므로 신뢰도 상승, 체계적인 프로세스로 일관성높임, 디버깅 용이성
생각해라 : 각 단계를 나누고 체계적이게 해달라
고민해라 : 예상치 못한일까지 생각해봐라
예를들어 REST API를 어떻게 설계 할 수 있는지 단계별로 생각하고 답변해줘를 했을때
- REST API를 구축하려면 어떻게 해야돼? 생각 과정을 태그에 입력해주고 생각한 과정을 분석하고 그를 기반으로 태그에 답변해줘
Think: ~~, Think hard: ~~, Think harder: ~~, Ultra think: ~~
- 이 프로젝트에 테스트 코드를 작성하려고 하는데 프로젝트를 분석하고 고민한 다음 테스트 코드를 작성해줘

PRD와 실행 계획

Product Requirements Document - 프로젝트의 방향성
- 어떤 사용자를 위해 만드는가
- 어떤 문제를 해결해주는가
- 비즈니스 측면에서 어떤 이득이 있는가
- 어떤 기능과 경험을 제공해야 하는가
- 사용자는 어떤 경험을 하게 되는가
- 우리는 무엇을 왜 만드는가
실행 계획 - 구체적인 기술적 디테일
- 어떤 기술 스택을 사용할 것인가
- 아키텍처를 어떻게 구성할 것인가
- 데이터를 어떤 모델로 저장할 것인가
- 어떤 함수와 클래스를 작성할 것인가
- 어떤 작업을 먼저 수행할 것인가

prd 작성 방법

문제 정의 : 해결하려는 문제가 무엇인지 명확한 수치와 정확한 정의를 통해 제시
타깃 사용자 및 사용 사례 : 제작할 서비스의 핵심 사용자가 누구인지 정의
제안 해결책 : 문제를 해결하기 위해 어떤 해결책을 제시할 지
목표 및 성공 지표 : 서비스 기능을 성공으로 볼 정확한 수치
경쟁사 분석 : 현재 다른 서비스는 어떻게 하고있는지
MVP 요구사항: 문제 해결을 위한 최소한의 기능에 대해 정의
PRD-instruction.md를 생성한 뒤 위의 내용을 정의 ```
문제 정의

오프라인 매장을 운영하는 소상공인 중 약 70%가 온라인 판매를 원하지만, 기존 쇼핑몰 플랫폼은 평균 30개 이상의 불필요한 기능과 10%에 달하는 수수료때문에 진입장벽이 높음

타겟 사용자 및 사용 사례

이 제품을 사용할 핵심 사용자

자신만의 개성 있는 상품을 판매하는 30~40대 소상공인. SNS는 익수하지만 코딩이나 웹사이트 제작 경험은 없는 사람

이 서비스/기능을 사용하는 목표

매장에서 신상품이 입고되었을 때 즉시 스마트폰으로 사진을 찍어 상품을 등록하고 싶을 때 고객의 주문이 들어오면 앱 푸시 알림을 받고 바로 주문을 확인하고 배송처리를 하고싶을때

제안 해결책

스마트폰 앱 하나로 상품등록부터 주문 관리, 결제까지 모든 것을 해결할 수 있는 올인원 모바일 쇼핑몰을 제공 직관적인 ui로 누구나 1시간 안에 자신만의 온라인 쇼핑몰을 열수 잇음

목표 및 성공 지표

소상공인의 온라인 커머스 진입 장벽을 낮춘다. 런칭 후 6개월 내에 활성 스토어 500개 확보 연 누적 거래액 10억 달성

위의 내용을 적고

너는 이제부터 dq라는 회사의 PM이야. @PRD-instruction.md 파일에 적힌 내용을 기반으로 PRD를 작성해줘. 결과물을 PRD.md에 저장해주고 실행계획은 따로 작성할 계획이니 PRD에서는 서비스에 대한 오버뷰에 집중해줘.

<br />

## 실행 계획 작성 방법

-   작업 분해
-   기술 명세
-   의존성 파악
-   산출물 및 일정
-   execution_plan.md 생성 후 아래와 같이 작성

실행 계획 제작 커맨드

너는 지금부터 복잡한 개발 작업을 아규먼트로 받아서 독립적이고 관리 가능한 태스크로 분해하고 실행계획을 작성하는 실행계획 설계 전문가야.

실행

작업은 아래 순서대로 실행해줘.

태스크 분석
태스크 분해
분해된 이슈 출력
사용자가 확인할 수 있도록 모든 분해된 이슈를 콘솔에 출력

핵심 목적

제시된 개발 태스크를 다음과 같이 변환하기

적절하게 태스크 분류(백엔드/프론트엔드/풀스택/기타)
서로 독립적이고 영역을 침범하지 않는 태스크
서로에게 의존해야 한다면 “의존성”으로 해당 태스크 등록
200k 단일 컨텍스트 내에 완료할 수 있는 분량의 태스크

실행방법

태스크 분석 프로세스

[태스크 분석 프로세스 상세히 설명]

태스크 분해 프로세스

[태스크 분해 프로세스 상세히 설명]

분해된 이슈 출력 프로세스

[분해된 이슈를 어떤 포맷을 출력해야 하는지 상세히 설명]

prd를 바탕으로 실행계획을 만들어줘

<br />

---

#   병렬로 실행하기

역할

너는 지금부터 다국어 번역 전문가야. 웹사이트에서 홈페이지를 영어, 일본어, 중국어, 아랍어로 번역하는 걸 도와줘

작업순서

번역해야할 텍스트를 전부 찾아줘
찾은 텍스트를 영어, 일본어, 중국어, 아랍어로 번역해줘
각 언어별로 subagent 4개를 동시에 생성해서 동시에 평행으로 (parallel) 작업해줘
subagent에게 “너는 지금부터 다국어 번역 전문가야. 이 위치의 문장들을 ${언어}로 번역해줘”라고 프롬프팅해줘
번역 외에 다른 작업은 절대 하지마
모든 작업이 끝났다면 테스트, 린트 ,빌드를 실행하고 에러가 없는 지 확인해줘
Todo 리스트를 생성해서 어떤 작업을 하고 있는 지 알 수 있게 해줘 ```

직렬로 실행하기

테스트를 subagent에서 독립적으로 실행하고 subagent에게 
"pnpm run test를 실행해서 테스트를 실행하고 에러가 있다면 에러를 해결해줘. 커버리지는 80%이상이 될 수 있도록 테스트가 추가로 필요하다고 생각하는 곳에 테스트를 더 작성해줘"라고 전달해줘

개요