개요

AI를 활용한 코딩 절차를 개인적으로 어느정도 문서화 해보려고 한다.

단계

코드 리서치

무지한 변경을 막아준다.

데이터 모델러 시스템을 깊이 매우 상세히 연구하고
동적 속성 조회가 어떻게 작동하는지 모든 세부사항을 담은
260315_01_BASE.md를 작성해줘.
아직 구현하지마
이러이러한한 기능을 만들고 싶어. 
개발을 위한 기존 기능이 어떻게 작동하는지 관련된 소스를 탐색하고 컨벤션, 스니펫, 계획을 제외한 모든 기능 목적, 세부사항과 배경지식을 담은 {DATE:yyyymmdd}_{SEQ:00}_BASE.md를 .claude/work-log 하위에 작성해줘.
아직 구현하지마.

계획

계획이 잘못된 변경을 막아준다.

동적 타입의 동적 속성 Detail에 대한 full 정보 반환을 위한 api를 구현하기위해
260315_01_RESEARCH.md과 소스 파일을 읽고 실제 코드 베이스를 기반으로 다른 코드들에서 어떻게 이미 작업되고있는지 파악하고 컨벤션을 맞추고 코드 스니펫도 포함해서 상세 260315_01_PLAN.md에 계획을 작성해줘.
아직 구현하지마
이러이러한한 기능을 구현하기위해
{DATE:yyyymmdd}_{SEQ:00}_BASE.md과 소스 파일을 읽고 실제 코드 베이스를 기반으로 다른 코드들에서 어떻게 이미 작업되고있는지 파악하고 컨벤션을 맞추고 코드 스니펫도 포함해서 상세 {DATE:yyyymmdd}_{SEQ:00}_PLAN.md에 계획을 .claude/work-log 하위에 작성해줘.
아직 구현하지마.

계획 피드백 주석달기(반복)

주석 달기가 내 판단을 주입한다.

계획은 md파일 에디터에서 확인하고 지속적으로 주석 및 가이드 수정을 진행한다.
주석에는 왜 그 계획이 수정 되어야하는지, 틀렸는지 이유를 알려줄 것.
추가적인 계획 개선 명령에서는 반드시 “아직 구현하지마” 라는 명령을 포함할 것.

주석 예시

  • 이 재시도 로직은 앞쪽에서 이미 걸러지고 있어. 중복이야. 제거하고 그냥 실패하게 둬
  • 이 부분 제거해. 여기는 캐싱이 필요 없어.
  • 아니 이건 PUT이 아니라 PATCH여야해.
  • visibility 필드는 개별 아이템이 아니라 리스트 자체에 있어야 해
  • 리스트가 공개면 모든 아이템이 공개야. 스키마 세션을 그에 맞게 재 구조화해.

계획 피드백

문서에 몇 가지 메모를 추가했어.
모든 메모를 반영하고 문서를 업데이트 해
아직 구현하지마.

구현

구현 명령이 방해 없이 실행된다.

260315_01_PLAN.md를 전부 구현해라.
작업이나 단계를 완료하면 계획 문서에서 완료로 표시해라
모든 작업과 단계가 완료될 때까지 멈추지 마라
any나 unknown 타입을 쓰지 마라
지속적으로 typecheck를 실행해서 새로운 문제를 만들지 마라
.claude/work-log 하위에 {DATE:yyyymmdd}_{SEQ:00}_PLAN.md를 전부 구현해라.
작업이나 단계를 완료하면 계획 문서에서 완료로 표시해라
모든 작업과 단계가 완료될 때까지 멈추지 마라.
지속적으로 컴파일 오류를 확인하고 새로운 문제를 만들지 마라. 불필요한 주석을 남기지 말고 AI 작업의 흔적없이 처리해라. 내가 확인해야할 애매한 사항이 있으면 계획 문서 마지막에 작업 중 특이사항 이라는 제목으로 목록으로 정리해라.

피드백

  • 잘못된 방향으로 가고있는 것 같으면 거기서 조금씩 바꾸려고 하는 것 보다 범위를 좁히는게 더 효율적임. git 변경을 통째로 되돌리고 범위를 재설정한다.
    • 전부 이전커밋 되돌려
    • 이제 목록뷰를 더 심플하게 만드는것만. 그것 외엔 아무것도 하지마.
  • 실행은 맞겨도 뭘 만들지에 대한 결정권은 절대 넘기지 않는다.
  • 적극적인 방향 조정은 대부분 plan.md에서 해결한다.
  • 좋은 건 취하고 나머진 버리기
    • 첫번째 방법은 async로 깔끔하게 가자 괜히 복잡할 필요 없어
    • 세번째는 읽기 쉽게 함수로 분리해줘
    • 네번째랑 다섯번째는 노력대비
  • 과감하게 쳐내기
    • 다운로드 기능은 계획에서 빼. 지금 안만들거야
  • 건드리면 안되는 선 긋기
    • 이 세 함수의 시그니쳐는 절대 바꾸면 안돼.
    • 라이브러리가 호출자한테 맞추는 게 아니라 호출자가 맞춰야 하는 거야.
  • 기술 선택은 내가 하기
    • 그 모델 말고 이 모델 써
    • 그거 직접 만들지 말고 라이브러리에 이미 있는 메서드 갖다 써

커맨드화

어차피 자주쓰는 문구가 될 예정이라 클로드에게 해당 작업의 반복 명령을 줄이면서도 명령이 유지되도록 하는 효율적인 명령방법이 있는지를 물어봤다.
이 방식은 클로드 응답을 그대로 차용한거라 언제 또 클로드 기능 업데이트가 되면서 바뀔 방식인지는 모르나 일단 커맨드화를 추천받아서 세팅해보았다.
변경되는 문구를 Arguments로 뺀 후 반복적인 문구는 커맨드화 했고 아래는 커맨드화 결과와 간단한 사용법이다.

워크트리

클로드에서 워크트리 사용 기능을 간단하게 추가해줘서 작업 디렉토리 분리를 위해 워크트리를 사용하기 시작했는데, 내가 사용하는 방식에서는 조금 헷갈리는? 불편함이 있어서 작업지시 방식을 기억하기 위해 문서화 해둔다.

1. 클로드에게 작업 요청
2. "feature/xxx 브랜치로 워크트리에서 작업해줘" 명시
3. 클로드가 feature/xxx 브랜치에 직접 커밋
4. 중간중간 IntelliJ에서 feature/xxx 체크아웃 → 빌드/테스트
5. 커밋 메시지 마음에 안들면 worktree에서 rebase
6. 완료되면 push → MR 생성 → squash merge
7. 워크트리 + 로컬/원격 브랜치 정리
8. 클로드에게 작업 로그 작성 요청