Claude Code를 활용한 실제 자동 프로그래밍 사례를 통해 프롬프트 기술 공유

이 글에서는 실제 사례를 통해 Claude Code의 실제 사용 사례를 공유하겠습니다. 공유하기 전에 간단한 설문을 먼저 해보겠습니다.

원래 요구사항: 한 명의 유료 사용자가 제 글에 글의 변경 시간을 추가해 달라고 요청했습니다.

이 요구사항은 언뜻 보기에 구현하기가 다소 어려워 보였습니다. 제 웹사이트의 글들은 데이터베이스에 저장되어 있지 않고, next.js의 SSG를 이용해 빌드되기 때문입니다. 따라서 업데이트 시간이 전혀 없었습니다.

여기서 한 가지 기술은: 문제를 해결할 때 원래 요구사항을 그대로 Claude Code에 입력하지 않는 것입니다. 그 이유는 다음과 같습니다.

1. 원래 요구사항은 상대적으로 모호하여, Claude가 오해할 수 있습니다. 만약 오해한다면, 결국 시간을 추가해 주더라도 그 시간이 신뢰할 수 없을 수 있습니다.

2. Claude Code의 Token 소비는 정말 비쌉니다. 따라서 모호한 요구사항은 많은 Token이 무의미하게 소비되는 결과를 초래할 수 있습니다.

따라서 원래 요구사항을 한 번 분해해야 합니다. 저는 먼저 deepseek에서 상담을 했고, deepseek은 두 가지 해결책을 제시했습니다.

1. 파일 빌드 시간: 매번 빌드할 때 파일의 빌드 시간을 가져와야 하지만, turbopack의 패키징 전략은 조금 다릅니다. 매번 빌드할 때 파일의 hash 값이 변경되므로, 이 빌드 시간은 신뢰할 수 없을 수 있습니다.

2. git 커밋 시간: 제 생각에는 이 방법이 비교적 신뢰할 수 있을 것 같았습니다.

대략적인 해결 방향을 정한 후, 저는 이 간단한 프롬프트를 작성했습니다: git 커밋 시간을 각 .mdx 글의 헤더에 컴파일하세요

Claude Code는 상당히 신뢰할 만합니다. 프롬프트가 비교적 정확하다면, 전반적으로 큰 문제는 없었고, 바로 실행에 옮겼습니다.

7달러의 한도를 소모한 후, 약 20분이 걸려 마침내 실행에 성공했습니다.

예상대로라면 문제가 생겼습니다. Claude가 171개의 파일 변경을 건너뛴 것이었습니다.

여기서 매우 곤란한 점은, 실제로 건너뛴 파일들은 단지 추가로 pass 매개변수 하나만 전달했을 뿐이고, 나머지는 완전히 동일했다는 것입니다.

<PostLayout pass>...

하지만 Claude는 융통성이 없어서, 이 추가로 전달된 매개변수를 완전히 다른 사용자 정의 컴포넌트로 정의했습니다. 그리고는 처리를 건너뛰었습니다 ~ ~

import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
  const gitInfo = getGitFileInfo('src/app/당신의경로/page.mdx');
  return (
    
      {children}
    
  );
}

하지만 실제로 제가 원한 결과는 이렇게 실행되어야 했고, 실행 결과는 완전히 동일해야 했습니다.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    
      {children}
    
  );
}

그리고 이때 저는 프롬프트에서 함정에 빠졌습니다.

다시 프롬프트를 입력했습니다: 위와 같은 방식으로 건너뛴 171개의 파일을 리팩토링하세요

제 표현을 자세히 생각해 보면 약간의 모호함이 있습니다. Claude Code가 이미 제안한 해결책을 주었지만, 저는 그 해결책을 인정하지 않았습니다. 제 본의는 이미 수정된 수백 개의 파일과 같은 방식으로 건너뛴 파일을 수정하는 것이었지만, 실행 과정에서 Claude는 '위에서 제안한 그 해결책'으로 이해했습니다.

이 모호함 때문에 Claude는 제가 원하지 않는 해결책으로 20분 동안 실행했고, 중간에 2번의 오류 자체 수정이 발생하며 제 token을 마구 삼켰습니다. 두 가지 모호함이 충돌하며 오류를 일으켰습니다.

결국 저는 이 실행을 포기하고, 제 의미를 다시 명확히 해야 했습니다.

요약

1. 프롬프트에는 상대적으로 안정적이고 정확한 해결책이 포함되는 것이 좋습니다. AI가 생각을 덜 할수록 환각률을 줄일 수 있습니다.

2. 요구사항 프롬프트에는 모호함이 있어서는 안 됩니다. 모호함은 오류를 초래하기 쉽고, 비록 Claude Code가 최종적으로 수정할 수 있더라도 많은 token 소비를 초래합니다. 또한 LLM은 예측 메커니즘을 기반으로 결과를 생성하기 때문에, 초기의 오해나 모호함 등은 이후의 모든 단계가 잘못된 방향으로 더 멀리 가게 만들며, 논리적 자체 일관성을 시도하여 존재하지 않는 것을 생성할 수도 있습니다. 이는 문제를 더 크게 만들고 개발자의 검토 난이도를 증가시킵니다. 만약 그 환각에 속아 넘어간다면 심각한 결과를 초래할 수 있습니다.

3. 자연어의 제약력은 코드만큼 정확하지 않습니다. 프롬프트에 파일 이름, 코드 변수, 코드 전문 용어, 전문 용어 등을 포함시키면 Cluade Code의 환각을 크게 줄일 수 있습니다.