기존 프로젝트 유지보수에서 Claude Code를 쓸 때 가장 중요한 건 “얼마나 똑똑한 프롬프트를 쓰느냐"가 아닙니다. 더 중요한 건 Claude Code가 실수하기 어려운 작업 흐름 을 먼저 고정하는 것입니다. 기존 서비스는 새 기능을 밀어 넣는 속도보다, 현재 동작을 안전하게 읽고, 필요한 부분만 좁게 바꾸고, 바로 검증하는 리듬이 훨씬 중요합니다. Claude Code는 CLAUDE.md 기반 프로젝트 메모리, 커스텀 서브에이전트, 스킬, 훅, 프로젝트 설정을 모두 지원합니다. 그래서 유지보수용 환경을 만들 때도 “AI가 알아서 잘하겠지"에 기대기보다, 분석 → 최소 수정 → 검증 → 리뷰 순서를 문서와 자동화로 고정하는 편이 훨씬 안정적입니다. 더보기

모노레포에서 CLAUDE.md 를 하나만 두면 금방 복잡해진다. 프런트엔드 규칙, 백엔드 테스트 명령, 워커 금지 사항이 한 파일에 섞이기 시작하면, 결국 “항상 읽히지만 대부분 지금 작업과는 무관한 지침"이 된다. 그래서 실무에서는 루트에는 공통 규칙만, 하위 폴더에는 그 서브프로젝트 전용 규칙만 두는 쪽이 훨씬 잘 맞는다. 이 글은 그 구조를 어떻게 나누면 좋은지, 그리고 frontend/, backend/, worker/, apps/*, packages/* 같은 폴더를 스캔해서 각자에 맞는 CLAUDE.md 를 생성하는 init-subproject-claude 스킬은 어떻게 설계하면 좋은지를 한 번에 정리한 글이다. 더보기

Claude Code를 쓰다 보면 큰 작업을 진행하는 중간에 “이 함수 어디서 더 쓰이지?”, “이 옵션 타입이 정확히 뭐였지?” 같은 옆길 질문이 자꾸 생깁니다. 많은 사람이 이때 새 터미널을 열어 별도 세션을 띄우는데, 이 영상이 지적하는 문제는 바로 그 습관 자체가 생각보다 비싸다는 점입니다. /btw 는 이 작은 옆길 질문을 위해 메인 흐름을 버리지 말라고 제안하는 기능입니다.12 더보기

justopen.ai의 짧은 Threads 포스트는 Claude Code를 잘 쓰는 순서를 아주 날카롭게 뒤집습니다. 많은 사람이 먼저 “무슨 기능이 있지?“를 묻지만, 이 포스트의 요지는 그 질문 자체가 이미 늦었다는 데 있습니다. 먼저 해야 하는 일은 기능 탐색이 아니라 누가 어떤 판단을 맡고, 그 판단이 어떤 문서로 남아야 하는지 를 정하는 것입니다. 더보기

Claude Code를 오래 붙잡고 있으면 어느 순간부터 똑똑한 페어 프로그래머가 아니라 방금 본 코드도 잊어버리는 인턴처럼 느껴질 때가 있습니다. 이 영상은 그 현상을 모델 품질 저하가 아니라 컨텍스트 관리 실패 로 해석하고, 상태 표시줄, 서브에이전트 오케스트레이션, 사고 확장 도구, 최신 문서 소스, 그리고 모바일 원격 터미널까지 한 번에 묶은 작업 환경을 제안합니다.12 더보기

최근 Reddit의 r/ClaudeAI에 올라온 GSD(Get Shit Done) 업데이트 글은 단순한 “기능 추가 안내"에 가깝지 않습니다. 오히려 AI 코딩 워크플로우가 어디에서 무너지기 쉬운지, 그리고 GSD가 그 지점을 어떤 구조로 다루려는지를 짧은 글 안에 압축해서 보여줍니다. 핵심은 같습니다. 사용자가 보는 인터페이스는 더 단순하게 유지하면서, 내부에서는 연구-계획-실행-검증-디버깅을 더 강하게 분리한다 는 점입니다. 더보기

왜 이 조합인가 Claude Code 생태계에는 다양한 스킬과 플러그인이 존재합니다. 그중에서도 GSD + pm-skills + Superpowers 조합이 강한 이유는, 셋이 같은 일을 두 번 하지 않기 때문입니다. pm-skills 가 무엇을 만들지 를 정리하고, GSD 가 어떤 phase 순서로 밀지 를 고정하고, Superpowers 가 각 phase 안에서 어떻게 생각하고 계획하고 검증할지 를 붙입니다. 더보기