Claude Code 사용에 대한 솔직한 경험담

claude code를 꽤 많이 써봤고, 구독도 여러 개 돌리면서 매주 제한까지 꽉 채워가며 쓰고 있어. 그래서 몇 가지 공유하고 싶은 점들이 좀 생겼네. 나도 여기저기서 나오는 하이프나 베스트 프랙티스들 다 따라 해보고, 직접 새로운 것들도 시도해 보는 중이야. 내가 잘못하고 있는 걸 수도 있으니까 너희들 경험도 궁금하다. '바이브 코딩' 말고, 엔터프라이즈급 실무 소프트웨어 엔지니어링 관점에서 말이야.

- 재사용 가능한 베스트 프랙티스들을 저장해두는 프로젝트를 하나 시작해 봐. 마치 스킬(skills)처럼 말이지. 대신 경로(path)를 써서 작은 섹션들로 나눠야 해. 각 섹션은 폼 유효성 검사, 백엔드 API 정제, CSS 디자인 토큰, 프론트엔드, 백엔드, 인프라, 데이터베이스 프로젝트 아키텍처 같은 작은 작업들을 담당하게 해. 그리고 shadcn 같은 거 쓰지 말고, 직접 커스텀 디자인 시스템을 만들어 보는 걸 추천해. 그래야 어떻게 돌아가는지 제대로 이해할 수 있고, 컴포넌트 이름도 확실히 외우게 되거든. 기본(primitive) 컴포넌트랑 커스텀 컴포넌트를 확실하게 구분해 둬.

- turborepo나 nx(모노레포)를 써서 여러 애플리케이션이랑 패키지를 관리해. 디자인 시스템은 애플리케이션에서 재사용할 수 있는 패키지로 만들고, 특정 앱에서만 쓰는 컴포넌트는 그 앱 안에, 여러 앱에서 공통으로 쓰는 건 packages/ui나 packages/components에 두는 식이지. 각 애플리케이션마다 고유한 디자인 토큰을 갖게 하고.

- claude.md는 심플하게 유지해. design.md나 product.md도 마찬가지고. 문서화 폴더를 따로 만들어서 AI가 읽을 수 있는 정보를 더 많이 넣어둬. 옵시디언(Obsidian)이 좋니 어쩌니 하는 건 듣기엔 재밌어 보이는데, 규모가 커지면 딱히 실질적인 이득이 없어. 저장하기엔 좋을지 몰라도, 나중에 꺼내 쓰기도 힘들고 데이터 최신 상태 유지하는 게 진짜 일이야. 개발하다 보면 계속 바뀌는데, 그걸 옵시디언에 다 때려 박는 건 악몽이지. 파일만 엄청나게 쪼개지고 서로 연결하느라 시간 다 가거든. 차라리 문서화 폴더 안에 기능별로 파일 하나씩만 만들어 둬. 그래야 AI가 어디서 찾아야 할지 정확히 알지.

- 프로젝트 아키텍처만 잘 짜여 있으면, 굳이 스킬(skills) 기능 안 써도 돼. 지금까지 네가 어떻게 코딩했는지 AI가 다 파악하거든. 혹시라도 일관성 없는 부분이 보이면 그때그때 스킬을 업데이트해 줘. AI가 짜는 코드가 평소 네 스타일이랑 똑같게 만드는 게 핵심이야. 일관성은 디자인, 소통 방식(텍스트 스타일), 객체 이름 짓는 법, 네이밍 컨벤션, 프로퍼티 이름 정하는 법 등 여러 형태로 나타나니까.

- handoff, cavemen, gstack, superpowers, frontendskills, impeccable, grill me 같은 것들은 실용성보다는 그냥 하이프가 심해. superpowers 대신 그냥 plan 모드를 써. handoff는 괜찮긴 한데, 모델이나 계정 바꾸거나 세션 닫아야 할 때 말고는 거의 쓸 일이 없어. Frontend skills나 impeccable은 시작할 때 쓰기엔 괜찮지만, 결과물이 너무 AI가 찍어낸 티가 많이 나. 차라리 claude한테 아티팩트(artifact)로 각 섹션이나 페이지 디자인을 여러 개 만들어 달라고 하고, 그중에서 마음에 드는 걸 골라. 디자인 합치고 싶으면 그렇게 하라고 프롬프트 넣고. Grillme는 유용하긴 한데, 질문을 너무 많이 던져서 사람 미치게 만들어. 요즘 AI는 그런 질문들 스스로 답할 만큼 똑똑하니까, 그냥 "네가 생각하기에 제일 좋은 걸로 골라서 이유랑 추천 사유까지 같이 보여줘"라고 시켜.

- 리팩토링 크게 할 때마다 일관성 체크를 꼭 해. AI한테 코드를 분석하게 시키고 더 나은 방법을 찾으라고 해. 테스트 코드는 좋긴 한데, 메모리를 너무 많이 잡아먹어. 특히 세션마다 매번 돌리면 그냥 오버킬이야. 테스트 코드 짜라고는 하되, 매번 실행하지는 마. 그래야 렉 안 걸리고 세션 여러 개 띄울 수 있거든. 특히 e2e 테스트는 시간도 메모리도 엄청 잡아먹어. 그리고 claude가 브라우저 여는 꼴은 절대 보지 마. 짜증 나고 집중력 다 깨지니까. 그냥 헤드리스(headless)로 돌리게 해.

• 브랜치나 워크트리 만드는 건 피해라. 세션 여러 개 돌리면... 관리하는 거 진짜 지옥이다. 브랜치의 경우엔 꼬여버려서 다른 세션까지 같은 브랜치로 강제 전환돼 버림. 워크스페이스는 애플리케이션 확인하고 실행하기 전까진 괜찮은데, 막상 실행하려고 하면 새 포트 열어야 하고, 이 포트들 관리하는 게 진짜 골치 아프다. 게다가 메모리도 엄청 잡아먹음. 제일 좋은 방법은 그냥 한 브랜치에서 작업하고 겹치는 일 안 만드는 거다. 세션끼리 서로 통신도 가능하니까, 다른 세션이 작업 중인 걸 발견하면 "야, 다른 세션이 이거 건드리고 있는데, 그쪽 끝날 때까지 기다릴까?" 같은 질문도 던져준다. 만약 세션이 다른 에이전트들이 만든 최신 변경 사항을 알게 하고 싶다면, 특히 플랜 모드일 때 이렇게 물어봐라: "야, 코드 좀 수정했는데 네 계획 아직 유효한지 확인 좀 해줘."