Anthropic의 CLI 코딩 에이전트 Claude Code의 실용 TIPS를 정리하고 있습니다.

각 TIPS의 본문은 PaPoo 상의 기사에 두고, 본 페이지에서 링크하고 있습니다 (수시 추가·업데이트).

이 기사는 각 TIPS의 요점을 정리한 색인입니다. 각각의 완전판(절차·요청문 예시·주의점)은 PaPoo의 기사에 있습니다 (원문 = Canonical).

Claude Code를 직접 실행할 수 있게 되면, 코드 수정뿐만 아니라 파일 정리, 불필요한 데이터 추출, 문장 초안 작성까지 동일한 흐름으로 맡길 수 있습니다. Claude Code 입문으로서 가장 먼저 파악해야 할 것은 어려운 설정이 아니라 "터미널을 열고, 사인인(Sign-in)하고, 작업 폴더에서 딱 한 번 지시해 보는 것"입니다. Claude Code 사용법의 입구는 생각보다 훨씬 좁고 짧습니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/df659aeb3c7ebaef

Claude Code는 거칠게 말하면 "터미널 안에 있는 작업 담당자"입니다. 코드를 쓰는 사람만을 위한 도구처럼 보이지만, 실제로는 폴더 정리, 불필요한 파일 추출, 문장 초안 작성, 기존 파일의 해석까지 상당히 폭넓게 사용할 수 있습니다. 다만, 무엇이든 맡겨도 되는 것은 아닙니다. 적합한 업무와 맡기면 위험한 업무의 경계를 미리 알고 있으면 상당히 사용하기 편리해집니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/a262925c8e59c921

Claude Code는 단순히 "작업을 시작하는 도구"가 아니라, 해당 프로젝트에서 무엇을 해도 되는지, 어디까지 건드려도 되는지를 처음에 정리하는 도구이기도 합니다. 이 첫 단계를 거치는 것만으로도 이후의 지시가 잘 통하게 되고, 불필요한 재작업도 줄어듭니다. 개발 안건에서도, 문서 정리에서도, 폴더 청소에서도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/55eb3e43b83794b2

Claude Code를 오래 사용하다 보면, 점점 "지금 이 대화, 이전 이야기를 너무 끌어오고 있네"라고 느껴지는 순간이 있습니다. 그럴 때 효과적인 것이 /clear입니다. 대화 이력을 일단 비우고 컨텍스트 관리 (Context Management)를 다시 하는 것. 단지 그것뿐이지만, 이를 통해 지시의 어긋남이 줄어들고, 불필요한 전제를 가져가지 않으며, 응답도 가벼워집니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/80eb7adbfa5f0247

Claude Code에 긴 파일을 그대로 붙여넣는 대신, "어떤 파일을 보면 좋은지", "어디를 읽으면 충분한지"를 찾게 합니다. 이 요청 방식을 익히면, 거대한 설정 파일, 긴 로그, 어지러운 문서를 마주해도 손으로 복사·붙여넣기(Copy-paste) 하는 양을 상당히 줄일 수 있습니다. 디스크 정리나 안건별 자료 확인에서도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/b898c38e4c2017d0

Claude Code를 사용하기 시작하면 가장 먼저 신경 쓰이는 것이 "이 조작, 어디까지 알아서 해도 괜찮은가"입니다. 파일 읽기만 한다면 안심할 수 있지만, 편집이나 삭제, 외부 커맨드 (External Command) 실행까지 범위를 넓히면 편리함과 사고의 리스크가 갑자기 가까워집니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/540918ab2fea474c

Claude Code를 사용할 때, 갑자기 변경을 실행하기 전에 "먼저 방침만 보여줘"라고 중간에 끼워 넣는 사용법이 있습니다. 이것이 플랜 모드 (Plan Mode)입니다. 파일 정리든, 문서 작성든, 코드 수정이든, 먼저 단계를 확인할 수 있으므로 "생각했던 것과 다르다"는 상황을 상당히 줄일 수 있습니다. 특히 삭제나 이동처럼 되돌리기 어려운 작업에서는 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo 기사로: https://papoo.work/doc/616c7bf6cd99ac3f

Claude Code로 큰 작업을 할 때는 갑자기 전부를 바꾸지 않는 것이 잘 풀립니다. 먼저 범위를 나누고, 그다음 한 단계씩 진행합니다. 이것만으로도 도중에 망가졌을 때 되돌리기 쉬워지고, 리뷰도 하기 쉬워집니다. 비엔지니어(Non-engineer)라면 폴더 정리나 문서의 대량 편집에서도 마찬가지입니다. 1회의 지시를 작게 나누는 것만으로도 결과 확인이 훨씬 수월해집니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/117853b495ea1b05

Claude Code에게 작업을 맡기다 보면, 중간까지는 괜찮아 보여도 방침이 어긋나거나, 편집 범위가 너무 넓어지거나, 건드리지 않았으면 하는 파일까지 손을 대는 경우가 있습니다. 그럴 때는 억지로 그 자리에서 수정하게 하기보다, 일단 작업을 버리고 다시 시작하는 것이 더 빠를 때가 있습니다. 이런 식의 되돌리기 방법을 알고 있으면, 시행착오(trial and error)의 횟수가 늘어나도 두렵지 않습니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/9fee72fce1b24dfd

Claude Code는 파일을 보거나, 고치거나, 정리하는 작업을 터미널(terminal) 안에서 그대로 도와주는 도구입니다. 다만, 첫 번째 장벽은 대개 "무엇을 입력해야 할지 모르겠다"는 것입니다. 그래서 익혀야 할 조작을 정말 최소한으로 줄여서 사용하는 방식에 집중합니다. 본문을 읽고 나면, 실행하기·지시하기·끝내기 이 세 가지만으로도 운영할 수 있을 것입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/85ecba97142be165

Claude Code에게 일을 던질 때, 가장 효과적인 것은 어려운 명령이 아닙니다. "무엇을 고칠 것인가"와 "어디까지 건드려도 되는가"를 미리 좁게 결정하는 것입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/7ee8826295233a8f

Claude Code에게 작업을 부탁할 때, 가장 효과적인 것은 "무엇을 만들 것인가"뿐만 아니라 "무엇을 하지 않을 것인가"까지 미리 전달하는 것입니다. 목표, 제약 사항, 성공 조건, 건드려도 되는 범위를 처음에 맞추면 재작업이 줄어듭니다. 파일 정리에서도, 문서 작성에서도, 코드 수정에서도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/edb2a4e40b75bdaf

Claude Code에게 대충 "고쳐줘"라고만 부탁하기보다, "먼저 조사하고, 그다음에 고쳐줘"라고 나누어 지시하는 편이 재작업(rework)을 줄여줍니다. 특히 기존 코드 수정, 폴더 정리, 중복 파일 찾아내기, 문서 정형화와 같이 먼저 상황 파악이 필요한 작업에서 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/e86b2c7fb62d6767

Claude Code에게 기존 파일을 읽게 하고, "이 프로젝트의 작성 방식에 맞춰줘"라고 부탁하는 것만으로도 나중에 수정하는 수고를 상당히 줄일 수 있습니다. 새로운 기능을 추가할 때도, 문서를 정리할 때도, 파일 정리를 할 때도, 우선 "그 현장의 방식"을 모방하게 하는 것이 지름길입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/ff29391d27bb3904

Claude Code는 부탁하는 방식 하나에 따라 움직임이 상당히 달라집니다. "무엇을 해주길 바라는가"뿐만 아니라, "무엇을 해주지 않았으면 하는가"를 미리 설정하면 불필요한 편집, 불필요한 삭제, 멋대로 하는 정형화를 상당히 줄일 수 있습니다. 파일 정리에서도, 문서 작성에서도, 코드 수정에서도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/a1afddafe9340de7

Claude Code에게 "긴 작업을 그대로 진행해"라고 맡기면, 도중에 헤매거나 어디까지 했는지 파악하기 어려워질 수 있습니다. 미리 작은 할 일 목록(ToDo)으로 나누게 하면 작업의 전망이 서고, 중간 확인도 쉬워집니다. 코드 수정뿐만 아니라 폴더 정리, 중복 파일 찾아내기, 긴 글의 초안 작성에도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/0b1c8b9734c47f81

Claude Code에게 긴 설명을 매번 쓰는 것이 번거롭다면, 미리 "이런 결과물로"라고 예시를 하나만 보여주면 이야기가 훨씬 빨라집니다. 이 방식은 영어권에서 퓨샷(few-shot)이라고 불리기도 하는데, 요컨대 "견본을 하나 전달하고 나머지를 같은 기조로 수행하게 하는" 부탁 방식입니다. Claude Code에서는 세세한 규칙을 전부 말로 나열하는 것보다, 짧은 지시와 실례를 조합하는 것이 의도가 전달되기 쉬운 경우가 많습니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/84601d75d1948ce1

Claude Code에게 요청할 때, 한 문장에 "무엇이 어떻게 되어 있는지 설명해줘"와 "덤으로 고쳐줘"까지 한꺼번에 담으면 돌아오는 작업의 초점이 흐려집니다. 이 TIPS는 요청을 "설명", "수정", "정리"로 나누어 던지는 것만으로도, 주고받는 과정에서의 재작업 (rework)을 줄이기 위한 것입니다. 특히 파일 정리나 문서 작성처럼 코드 이외의 작업에서도 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/b7bc95c2e762f329

Claude Code에게 커밋 메시지 (commit message)를 맡기면, 차이점 (diff)의 요점을 짧게 포착하여 작성 스타일을 통일하기 쉬워집니다. 사람이 매번 처음부터 생각하는 것보다, 우선 "무엇을 바꿨는지"를 안정적인 입도 (granularity)로 출력하게 하는 것이 이력을 읽기 쉽게 만듭니다. 특히 작업의 끊김이 세밀한 날이나, 하나의 수정에 설명이 필요한 날일수록 효과적입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/4491bd91f48d88d9

Claude Code에서 가장 유용하게 쓸 수 있는 방법 중 하나는, 자신이 건드린 차이점 (diff)을 그 자리에서 리뷰받는 것입니다. 작성한 본인은 "무엇을 했는지" 알고 있기 때문에, 누락이나 위험 요소를 알아차리기 어렵기 마련입니다. 이때 Claude Code에게 변경한 파일만 읽게 하고 "이 차이점에서 신경 쓰이는 점을 꼽아줘"라고 요청하십시오. 이것만으로도 로직의 허점, 설명 부족, 불필요한 변경, 실수로 섞인 잡다한 수정 등을 상당히 찾아낼 수 있습니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/255830b7fec4153c

Claude Code로 깨지기 쉬운 코드를 고칠 때는, 갑자기 코드를 새로 쓰는 것에 들어가지 않는 것이 요령입니다. 먼저 "현재의 동작"을 테스트나 확인 절차로 남겨둔 뒤에 손을 대면, 고쳤다고 생각했는데 다른 곳을 망가뜨리는 사고를 크게 줄일 수 있습니다. 코드 정리든, 문서 대청소든, 디스크 용량 절감이든 마찬가지입니다. 먼저 기준을 만든 뒤에 건드리는 것. 이것만으로도 작업의 두려움이 상당히 낮아집니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/eb5c3b25351bd041

풀 리퀘스트 (Pull Request) 설명문은 나중에 다시 보았을 때 "무엇을, 왜, 어떻게 바꿨는지"가 남는 중요한 기록입니다. Claude Code를 사용하면 차이점 (diff)이나 커밋 메시지, 메모를 재료로 삼아 우선 읽을 수 있는 초안을 짧은 시간 안에 만들 수 있습니다. 빈 양식을 앞에 두고 멈춰 서 있는 시간이 줄어들고, 설명이 누락되는 경우도 상당히 억제됩니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/dffb9e3224022a20

Claude Code에게 충돌 해결 (conflict resolution)을 도와달라고 할 때는, 갑자기 "고쳐줘"라고 통째로 맡기기보다, 충돌이 발생한 지점과 되돌릴 수 있는 재료를 함께 전달하는 것이 더 잘 풀립니다. Git의 머지 충돌 (merge conflict)이든, 텍스트 파일의 차이점이든 하는 일은 비슷합니다. 망설여지는 부분을 가시화하고 판단 재료를 조금 곁들이는 것. 이것만으로도 다시 작업해야 하는 수고가 상당히 줄어듭니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/51f7abb6c9cbaa76

오래된 코드나 생소한 삭제를 마주했을 때 가장 필요한 것은 "누가 썼는가"보다 "왜 남아있는가"입니다. Claude Code에게는 대상 파일을 읽으면서 Git의 이력도 단서로 삼아 변경 배경을 문장으로 정리하게 하는 활용법이 있습니다. 단순한 요약이 아니라, "이 줄이 언제 들어갔는지", "직전에 무엇이 망가져 있었는지", "삭제해도 되는지에 대한 판단 재료는 무엇인지"를 찾아내게 하는 것이 요령입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/51e0c451964e5d4a

Claude Code에게 일괄 치환을 맡기면 확실히 빠릅니다. 하지만 일단 생각대로 되지 않은 변경이 섞이면 어디서부터 고쳐야 할지 알 수 없게 됩니다. 이때 효과적인 것이, 작게 고치고, 작게 확인하며, 문제가 있으면 즉시 되돌릴 수 있는 형태로 나누는 방식입니다. 이는 개발에만 국한된 이야기가 아닙니다. 대량의 문서 이름을 통일하거나, 프로젝트 폴더의 내용을 정리하거나, 중복된 표기를 통일하는 등의 작업에서도 마찬가지입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/4aebdab9222d32cb

Claude Code를 동일한 프로젝트에서 반복해서 사용한다면, 처음에 해두면 효과적인 것이 CLAUDE.md

입니다. 이것은 해당 리포지토리(Repository)에서 지켜주었으면 하는 관례나 전제를 정리해 두는 메모로, 간단히 말해 "이 프로젝트에서는 이렇게 동작해 주길 바란다"라는 프로젝트 메모리(Project Memory)의 역할을 부여할 수 있습니다. 매번 "이 폴더는 무엇을 위한 것인가", "무엇을 건드려도 되고 무엇을 건드리면 안 되는가"를 다시 설명해야 하는 수고를 줄여줍니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/2a7780462f0c05a0

Claude Code를 사용한다면, CLAUDE.md는 "매번 반복해서 말하기 귀찮은 전제"를 두는 장소입니다. 잘 작성해 두면 작업할 때마다 같은 설명을 입력할 필요가 없습니다. 반대로, 너무 세세한 지시나 임시방편적인 부탁을 너무 많이 집어넣으면 별로 효과가 없습니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/22544c3267ecd611

Claude Code에서 매번 같은 부탁을 다시 입력하고 있다면, 그것을 슬래시 커맨드(Slash Command)로 만들어 버리면 편합니다. 예를 들어 "이 폴더의 중복 파일 후보를 찾아줘", "이 문장을 쉬운 일본어로 고쳐줘", "변경점을 요약해줘"와 같이 자주 사용하는 요청을 짧은 이름으로 호출할 수 있습니다. 긴 지시를 매번 붙여넣는 수고가 사라지고, 작업 누락도 줄어듭니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/750373545a29d87c

Claude Code를 사용하다 보면, 같은 종류의 확인 작업이 계속 나와서 작업이 멈추는 경우가 있습니다. 예를 들어, 같은 폴더 내의 파일을 수십 번 읽거나, 같은 종류의 수정을 연속해서 작성하거나, 매번 "이 작업을 실행해도 되겠습니까?"라고 물어보는 경우입니다. 이럴 때는 허가 리스트(Allowlist)를 제대로 정비하면, 필요한 확인만 남게 되어 작업 흐름이 끊기지 않게 됩니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/937927cd5c3ec76a

Claude Code에 **훅(Hooks)**을 넣어두면, 사용자가 저장하는 타이밍에 "포맷팅(Formatting)만 먼저 해두는" 흐름을 만들 수 있습니다. 코드의 외관을 맞추고 싶을 때는 물론이고, 문서의 줄바꿈이나 불필요한 공백을 정리하고 싶을 때도 편리합니다. 매번 손으로 정리하는 것보다 작업 마지막에 자연스럽게 처리되는 점이 기분 좋은 부분입니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/7c90877e0657648c

조사 작업을 본래의 대화 흐름에 던져 넣으면 금방 문맥이 흐려집니다. 이는 Claude Code에서도 마찬가지입니다. 서브 에이전트, 영어로는 subagent라고 불리는 사용법을 익히면, 조사 작업만을 별도의 작업으로 분리하여 메인 대화의 가벼움을 유지할 수 있습니다. 코드 수정 도중에 사양 확인을 하고 싶을 때, 중복 파일 추출 기준을 먼저 조사하고 싶을 때, 긴 문서의 참조원을 모으고 싶을 때 등 그런 상황에서 효과적입니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/c4e921de29e4d445

settings.json을 한 곳에 몰아넣으면 정리될 것이라고 생각하는 사람은 대개 나중에 막히게 됩니다. Claude Code는 "자신의 작업 환경으로서 매번 사용하고 싶은 설정"과 "이 프로젝트에만 적용하고 싶은 설정"을 나누어 두는 것이 압도적으로 다루기 쉽습니다. 이곳을 대충 관리하면 다른 프로젝트에서 이상한 동작이 남거나, 반대로 매번 같은 지시를 다시 써야 하는 등 시간과 컨텍스트(Context)를 낭비하게 됩니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/cad2004d4f05af32

"Claude Code가 무엇이든 다 해주길 바라며" 매번 프롬프트에 장문의 글을 붙여넣고 있지는 않습니까? 그곳이 첫 번째 함정입니다. Claude Code는 똑똑하지만, 파일을 읽거나, 검색하거나, 사내 API를 호출하거나, 캘린더를 확인하는 등의 "외부 도구"까지는 단순한 대화만으로는 안정적으로 다룰 수 없습니다. 여기서 사용하는 것이 MCP, 정식 명칭으로는 Model Context Protocol입니다.

▶ 이어지는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/a6e0a0e0c6cae9c0

첫 번째 실패는 대개 정해져 있습니다. "MCP 서버를 늘리면 Claude Code가 갑자기 똑똑해질 것"이라고 생각하여 갑자기 여러 개를 추가하는 것입니다. 그런 방식으로 추가하면 무엇이 효과가 있었는지 알 수 없게 되고, 권한이 넓은 서버를 섞는 순간 판단이 흐려집니다. 우선은 딱 하나만 추가하는 것, 이것이 올바른 시작 방법입니다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/bd5f7425e8981efa

MCP (Model Context Protocol)는 넣으면 넣을수록 편리해지는 것이 아니다. 오히려 반대로, 처음에 너무 많이 채워 넣으면 Claude Code는 "모든 것을 할 수 있지만 아무것도 빠르지 않은" 상태가 된다. 컨텍스트 (Context)는 잡아먹고, 지시는 분산되며, 어떤 도구를 사용해야 할지에 대한 판단마저 모호해진다. 이 부분을 대충 처리하면 나중에 재작업 (rework)이 늘어난다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/6204881096bc81eb

대충 "API 좀 찔러봐", "DB 좀 봐줘"라고 던지면 대개 낭패를 본다. Claude Code는 수중에 있는 파일을 읽고 편집하는 데는 능숙하지만, 외부 API나 데이터베이스를 멋대로 만지게 할 정도로 안전한 것은 아닙니다. 오히려 반대다. 어디까지 하게 할지, 무엇을 절대 하지 못하게 할지를 먼저 결정하는 것이 재작업을 줄이는 길이다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/4176585d6a6bc770

로그를 대충 던지며 "봐주세요"라고 하는 것은 대개 화를 부른다. 원인의 실마리가 희미한 상태에서는 Claude Code든 인간이든 추측에 기반한 수리밖에 할 수 없다. 반대로 말하면, 에러 로그를 내보내는 방식을 조금만 정돈해도 원인 파악 (troubleshooting) 속도는 눈에 띄게 빨라진다. Claude Code에게 "어디가 수상한지", "무엇을 추가로 봐야 하는지", "다음에 시도할 순서는 무엇인지"를 명확하게 출력하게 한다. 이것이 가능해지면 수정 재작업이 줄어든다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/bf515c6b22fad9bb

갑자기 본체를 건드리게 하면, Claude Code는 아무렇지 않게 "그럴싸한 수정"을 하고 끝내버린다. 이것이 대수롭지 않아 보이지만 나중에 가장 큰 대가를 치르게 된다. 먼저 실패하는 테스트를 작성하게 하면 상황이 역전된다. 무엇을 충족해야 하는지가 고정되고, 수정은 그 조건을 통과시키는 작업이 된다. 인간이 입으로 "아마 여기를 고쳐줘"라고 말하는 것보다 훨씬 흔들림이 없다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/87d3821bd7cfa5ed

"고장 났어"라고만 던지는 것은 거의 확실하게 재작업을 부른다. Claude Code는 마법의 수리공이 아니다. 재현할 수 없는 결함은 고칠 방법이 없기 때문이다. 여기서 해야 할 일은 단순하다. 버그 설명을 열심히 하기 전에, "똑같이 고장 나는 절차"를 전달하는 것이다. 이렇게 하면 Claude Code는 원인 파악부터 수정, 확인까지 한 번에 진행하기 쉬워진다. 개발 코드의 버그든, 파일 정리 실패든, 출력 문서의 깨짐이든 마찬가지다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/3b80972097b3b992

매번 같은 일을 손으로 하면서도 "뭐, 익숙하니까"라며 방치한다. 이것이 가장 위험하다. Claude Code는 그런 지루한 반복 작업을 그대로 맡겼을 때 강력하다. 파일 정리든, 문서 밑작업이든, 디스크 청소든, 같은 형태의 작업을 스크립트로 만들어 버리면 수작업은 통째로 사라진다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/8fe0b31710132eae

2026년 6월 말에 Sonnet 5가 나온 이후, 여기저기서 "이제 Opus는 필요 없는 거 아니냐"라는 목소리가 들리기 시작했다. 솔직히 이런 종류의 "신형이 전 세대를 잡아먹는다"는 논쟁은 매번 나오기에 반신반의하며 듣고 있었지만, 이번에는 말하는 사람들의 면면이 다르다. 엔터프라이즈 도입 사례부터 개인 블로거의 생생한 푸념까지, 실제로 Claude Code를 양쪽 모두 돌려본 사람들의 목소리를 수집해 보니 생각보다 해상도 높은 이야기들이 나와서 정리해 본다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/e16269f0eca66047

결론부터 말하자면, 어느 쪽이든 상관없다. 일본어(한국어)로 써도 전혀 문제없다. 인터넷에서 "CLAUDE.md는 영어가 정의다" 같은 글을 보기도 하지만, 그건 절반은 분위기상 하는 말이라고 생각한다. Claude는 평범하게 일본어(한국어) 지시를 읽고 제대로 따른다. "영어가 아니면 정확도가 급락한다" 같은 일은 일어나지 않는다.

▶ 계속되는 내용·구체적인 절차는 PaPoo의 기사로: https://papoo.work/doc/60ecfd7f495a7794

TIPS는 수시로 추가하고 있습니다. 모든 기사 목록은 PaPoo의 프로필(https://papoo.work/u/claudecodejp)에서 확인하실 수 있습니다.