디버깅, 리팩터링, 아키텍처 리뷰를 위한 Claude 코딩 프롬프트 팩

아래 모든 프롬프트를 작동하게 만드는 네 가지 제약 조건

프롬프트를 소개하기 전에, 이들이 공유하는 규칙부터 살펴보겠습니다. 이 규칙을 어떤 코딩 프롬프트에 추가하든, 모델을 바꾸는 것보다 결과물이 더 좋아집니다.

버전을 명시하세요. 학습 데이터는 가장 많이 다뤄진 메이저 버전 쪽으로 치우치는데, 그것이 여러분이 쓰고 있는 버전이 아닌 경우가 많습니다. We are on [framework] [version], [language] [version]라고 명시하면 대부분의 구식 답변을 막을 수 있습니다.

변경 범위를 제한하세요. 수정을 요청하면 리팩터링이 돌아오는 경우가 많습니다. 가능한 한 적게 변경하고, 기존 구조와 이름을 유지하고, 변경한 모든 줄을 한 줄짜리 이유와 함께 나열해줘가 이 문서에서 가장 쓸모 있는 한 문장입니다.

해결책 전에 가설을 요청하세요. 무엇이 잘못됐는지 묻기만 하면 모델은 추측을 결론처럼 내놓습니다. 순위가 매겨진 원인과 저비용 확인 방법을 요청하면 모델은 디버깅 계획을 내놓습니다.

실패 모드를 요구하세요. 이 변경이 무엇을 망가뜨릴 수 있고, 원인을 고치는 건지 증상을 고치는 건지 말해줘는 가장 비용이 큰 AI 지원 유형, 즉 결함은 그대로 둔 채 증상만 사라지게 만드는 변경을 잡아냅니다.

디버깅

1. 순위가 매겨진 가설

여기 오류, 관련 코드, 그리고 이미 배제한 원인이 있어. 아직 해결책은 주지 마. 가능성이 높은 순서로 원인 네 가지를 나열하고, 각각에 대해 확인하거나 배제할 수 있는 가장 저렴한 확인 방법을 하나씩 알려줘. 오류: [paste]. 코드: [paste]. 이미 배제한 것: [list]. 스택: [language, framework, versions].

2. 간헐적으로 발생하는 버그

이건 대략 [frequency] 빈도로, [conditions] 조건에서 간헐적으로 실패해. 이 구체적인 증상을 일으킬 수 있는 간헐적 실패의 범주를 나열해줘. 타이밍, 순서, 리소스 고갈, 외부 의존성, 실행 간 상태 누수, 시계나 시간대, 캐싱. 각각에 대해 코드에서 무엇이 이를 뒷받침하거나 반박하는지, 그리고 이들을 구분하기 위해 정확히 무엇을 로그로 남겨야 하는지 알려줘. 코드: [paste].

3. 로컬에서는 잘 되는 경우

이건 로컬에서는 잘 되는데 [environment]에서는 실패해. 이 구체적인 증상을 일으킬 수 있는 환경 차이의 모든 범주를 나열해줘. 설정, 환경 변수, 버전, 파일 시스템과 대소문자 구분, 시간대와 로케일, 네트워크와 DNS, 권한, 리소스 제한, 빌드나 번들링 차이. 증상을 기준으로 가능성 순으로 정렬하고, 각각에 대한 진단 명령어를 알려줘.

4. 적용하기 전에 수정 내용을 설명하기

이 수정이 왜 작동하는지, 무엇을 고치지 못하는지, 그리고 무엇을 망가뜨릴 수 있는지 설명해줘. 만약 진짜 원인이 다른 곳에 있고 이게 증상만 고치는 패치라면 솔직하게 말해줘.

코드 리뷰

5. 디프 리뷰하기

이 디프를 까다로운 리뷰어처럼 검토해줘. 우선순위 순서는 정확성 버그, 보안 문제, 처리되지 않은 실패 모드, 경쟁 조건, 그다음 스타일이야. 발견 사항마다 심각도, 정확한 줄, 그리고 일반론이 아니라 이 코드베이스에서 왜 중요한지 알려줘. 포맷팅에 대해서는 언급하지 마. 디프가 문제없다면 억지로 지적하지 말고 그렇다고 말해줘. 컨벤션: [describe]. 디프: [paste].

6. 보안 점검

이 코드를 보안 문제 관점에서 구체적으로 검토해줘. 인젝션, 인증과 권한 부여의 허점, 안전하지 않은 역직렬화, 코드나 로그에 남은 비밀 값, 민감한 작업에 도달하는 검증되지 않은 입력, 의존성 위험. 각각에 대해 범주 이름만 대지 말고 구체적인 공격 경로를 알려줘. [deployment, auth layer, data sensitivity]를 보지 않고는 평가할 수 없는 부분은 명확히 밝혀줘.

7. 실패 모드 점검

이 코드의 외부 호출마다 느릴 때, 실패할 때, 예상치 못한 데이터를 반환할 때, 부분적으로만 성공할 때 각각 무슨 일이 일어나는지 말해줘. 그중 현재 처리되지 않은 것은 무엇이고, 조용히 넘어가는 것은 무엇이야?

마지막 항목은 아무도 테스트를 작성하지 않은 경로를 묻기 때문에, 일반적인 리뷰보다 실제 프로덕션 문제를 더 많이 찾아냅니다.

리팩터링과 아키텍처

8. 리팩터링 계획

[description]을 리팩터링하기 위한 단계별 계획을 제안해줘. 제약 조건은 [x]의 퍼블릭 API는 변경할 수 없고, 우리는 지속적으로 배포하니 각 단계는 독립적으로 배포 가능해야 하며, 각 단계 후에 테스트가 통과해야 한다는 거야. 각 단계마다 변경 내용, 위험, 검증 방법, 롤백 방법을 알려줘. 위험이 낮은 순서부터 정렬해줘. 아직 코드는 작성하지 마.

9. 반대 입장 주장하기

나는 [context and constraints]에서 [approach B] 대신 [approach A]를 선택하려고 해. B를 위한 가장 강력한 주장을 펼쳐줘. B가 옳으려면 우리 제약 조건에 대해 무엇이 사실이어야 하고, 그중 여기서 실제로 사실인 게 있어? 둘 다 타당하다는 식으로 결론짓지는 마.

10. 물려받은 코드 파악하기

여기 주요 소스 파일이 있어. 다음을 만들어줘. 진입점, 요청부터 응답까지의 데이터 흐름, 공유되는 상태와 그것이 변형되는 위치, 외부 의존성과 각각을 사용할 수 없을 때 일어나는 일, 복잡도와 결합도를 기준으로 버그가 있을 가능성이 가장 높은 세 영역. 내가 제공한 정보만으로는 판단할 수 없는 부분은 명확히 밝혀줘.

마지막 지시가 중요합니다. 모델은 붙여넣지 않은 파일의 동작도 이름만으로 추론해서 설명하려 듭니다. 알 수 없는 부분을 명시적으로 나열하게 하면 무엇을 읽어야 할지 알 수 있습니다.

테스트

11. 여러분이 작성하지 않았을 테스트

이 함수의 테스트 케이스를 작성해줘. 내가 아마 고려하지 못했을 입력에 집중해줘. 경계값, 빈 값과 null, 유니코드, 매우 큰 값, 동시 호출, 그리고 구현에 담긴 암묵적 가정. 테스트마다 어떤 가정을 확인하는지 명시해줘. 함수: [paste].

12. 테스트 스위트를 테스트하기

여기 함수와 기존 테스트가 있어. 어떤 동작이 커버되지 않았어? 구체적으로 오류 경로, 경계값, 매개변수 간 상호작용, 그리고 어떤 테스트도 검증하지 않는 구현의 동작을 알려줘. 기존 테스트는 다시 작성하지 마.

두 번째가 더 가치 있는 프롬프트인데도 거의 쓰이지 않습니다. 커버리지 퍼센트는 어떤 줄이 실행됐는지 알려줄 뿐, 어떤 동작이 실제로 검증됐는지는 알려주지 않습니다. 그 둘 사이의 간극에 리그레션이 숨어 있습니다.

세컨드 오피니언 패턴

이 팩 전체에서 가장 효과가 큰 습관이며, 모델을 하나 이상 요구하는 유일한 습관입니다.

한 모델에게서 답을 받으세요. 그다음 모델을 바꿔서 넘겨주세요.

다른 엔지니어가 이 문제에 대해 이 해결책을 제안했어. 무엇이 잘못됐는지 찾아줘. 엣지 케이스에서의 정확성, 동시성, 오류 처리, [scale]에서의 성능, 아니면 놓친 더 단순한 접근 방식. 정말로 문제없다면 억지로 반론을 만들지 말고 솔직히 그렇다고 말해줘. 문제: [paste]. 제안된 해결책: [paste].

결과는 둘 중 하나고 둘 다 유용합니다. 두 번째 모델이 진짜 허점을 찾아내면 병합하기 전에 알게 되고, 반박하도록 유도했는데도 동의한다면 그것은 의미 있는 확인이 됩니다. 같은 모델과 반복하면 둘 다 얻지 못합니다. 자기 결과물을 검토하는 모델은 대부분 스스로에게 동의하기 때문입니다.

틀리면 비용이 큰 결정, 즉 스키마 변경, 동시성 수정, 인증이나 금전과 관련된 무엇이든에 이 패턴을 쓰세요. 일상적인 작업에는 쓰지 마세요. 전체 워크플로우를 한곳에서 보려면 모델을 나란히 비교하기, 대화 중간에 모델 전환하기, 여러 모델로 코드 작성하고 디버깅하기를 참고하세요.

주의해야 할 점

존재하지 않는 API. 존재하지 않는 메서드 이름, 매개변수, 설정 키를 자신 있게 제시합니다. 특히 최근에 바뀐 라이브러리일수록 그렇습니다. 시그니처는 그럴듯해 보일 것입니다. 익숙하지 않은 것을 기반으로 작업하기 전에는 실제 문서를 확인하세요.

확신의 신호가 없음. 정확한 수정과 미묘하게 틀린 수정이 똑같은 확신을 담고 나옵니다. 말투는 아무것도 알려주지 않습니다.

조용한 범위 확대. 이것이 바로 제약 조건 두 번째가 존재하는 이유입니다.

보안 연극. 코드에서 취약점 유형을 나열하는 것은 유용한 첫 단계입니다. 하지만 이는 감사가 아니며, 모델은 여러분의 위협 모델, 배포 환경, 데이터 민감도를 알지 못합니다.

매주 쓰는 프롬프트는 바로 붙여넣을 수 있는 곳에 보관하고, 고정적인 제약 조건은 프로젝트의 안내사항에 넣어 그 프로젝트의 모든 채팅에 자동으로 적용되게 하세요.