AI 코딩 도구를 쓰고 있는데도 결과가 들쑥날쑥하다면, 문제는 모델 성능보다 사용 방식일 가능성이 큽니다.

이번 글은 메이커 에반님의 영상 **“클로드 이렇게 쓰면 100배 차이 납니다”**를 참고해, Claude Code를 단순 챗봇이 아니라 재현 가능한 작업 시스템으로 쓰는 방법을 정리한 포스팅입니다.

핵심 요약

영상의 중심 메시지는 아래 네 줄로 압축할 수 있습니다.

  1. 막연한 요청(“잘해줘”)은 거의 효과가 없다.
  2. 세션 메모리를 신뢰하지 말고, 중요한 규칙은 파일에 먼저 고정해야 한다.
  3. 설정은 “부탁"이고, 훅은 “강제"에 가깝다.
  4. 프로젝트 구조 자체가 AI가 이해하기 쉬워야 생산성이 올라간다.

즉, 성능 차이를 만드는 건 프롬프트 한 줄이 아니라 운영 방식의 시스템화입니다.

문제 정의: 왜 같은 Claude Code인데 결과가 크게 갈릴까?

영상 초반부에서 강조하는 포인트는 “도구 사용 숙련도의 격차"입니다.

  • AI 도구를 쓰는 것 자체는 이제 진입장벽이 낮아졌고
  • 실제 차이는 반복 가능한 규칙을 갖고 운용하느냐에서 벌어진다는 주장입니다.

발표자는 30일 동안 대규모 코드 작업을 하며 같은 문제를 반복해서 겪었고, 결론적으로 “클로드는 도구가 아니라 시스템으로 다뤄야 한다"는 관점을 제시합니다.

원칙 1) 설정 파일은 추상 문장 대신 “상황 -> 행동” 규칙으로 작성하기

영상에서 가장 먼저 지적한 안티패턴은 이런 문장입니다.

  • “친절하게 답해줘”
  • “좋은 코드 써줘”
  • “잘해줘”

이런 지시는 해석 폭이 너무 넓어 모델이 일관되게 따르기 어렵습니다.

대신 아래처럼 조건과 행동을 묶어 써야 한다고 설명합니다.

  • 코드가 30줄을 넘으면 분리하기
  • 에러 가능 구간에는 방어 로직 추가하기
  • 새 파일 상단에 파일 역할 1줄 명시하기

핵심은 감각적 지시가 아니라 검증 가능한 규칙 문장입니다.

원칙 2) “기억할게요"를 신뢰하지 말고, 파일 기반 메모를 기본값으로 두기

영상에서 반복 언급되는 문제는 세션 경계입니다.

  • 대화창을 닫거나 새 세션으로 넘어가면 이전 맥락이 유지되지 않는 상황이 생김
  • 중요한 규칙이 구두 지시로만 남아 있으면 다음 작업에서 재설명 비용이 커짐

해결책은 단순합니다.

  1. 중요한 규칙/결정사항은 먼저 파일로 기록
  2. 이후 대화는 파일을 기준으로 진행

이렇게 하면 매번 “처음부터 다시 설명"하는 시간이 크게 줄어듭니다.

원칙 3) 설정만으로 부족할 때는 훅으로 자동 검증 파이프를 만들기

영상에서 말하는 핵심 구분은 이렇습니다.

  • 설정 파일: 권고/요청 성격
  • 훅(Hooks): 조건 충족 시 자동 실행되는 강제 장치

예시로는 “기록했다"고 답했지만 실제 메모 파일 갱신이 없을 때, 훅으로 차단/재요청을 걸어 누락을 줄이는 흐름을 설명합니다.

결국 훅의 목적은 모델을 더 똑똑하게 만드는 것이 아니라, 사람이 정한 프로세스를 안정적으로 집행하는 데 있습니다.

원칙 4) Claude를 바꾸기 전에 프로젝트를 Claude 친화적으로 구성하기

영상 후반부에서 실전 팁으로 제시한 항목은 프로젝트 구조 최적화입니다.

4-1. 저장소를 한곳에서 보이게 정리하기

  • 프론트/백/스크립트가 과하게 분산되면 전체 맥락 파악이 느려짐
  • 모노레포처럼 구조를 한 번에 읽기 좋게 맞추면 맥락 연결이 쉬워짐

4-2. 한 파일에 기능을 과밀하게 넣지 않기

  • 거대한 파일은 관련 없는 맥락까지 끌어와 수정 실수를 늘림
  • 기능 단위 분리로 탐색 비용과 오수정 가능성을 낮춤

4-3. AI가 많이 본, 안정적인 기술 스택 우선하기

  • 지나치게 최신이거나 레퍼런스가 적은 조합은 출력 정확도가 흔들릴 수 있음
  • 검증된 버전/패턴이 유지보수성과 예측 가능성을 높임

4-4. 폴더/파일 단위 가이드 문서와 헤더 설명 넣기

  • 폴더별 규칙 문서(어떤 스타일/규칙을 따르는지)
  • 파일 상단 1줄 설명(이 파일의 역할)

이 두 가지는 사람이 읽기 편할 뿐 아니라, AI가 빠르게 의도를 파악하는 데도 직접적인 도움을 줍니다.

원칙 5) 데이터 접근과 계획 수립에도 운영 규칙을 넣기

영상에서 함께 제시된 실무 팁은 아래 두 가지입니다.

  • 데이터베이스는 우선 읽기 전용 연결로 진단/탐색 안정성 확보
  • 구현 전에 계획 생성과 리뷰에 충분한 시간 투자

특히 “빨리 만들기"보다 “좋은 계획을 먼저 만들고 검토하기"가 결과 품질을 더 크게 좌우한다는 점을 강조합니다.

관통 메시지: 바이브 코딩보다 바이브 리뷰

영상의 마지막 키워드는 vibe coding이 아니라 vibe review입니다.

  • 코드 생성은 AI에게 맡겨도
  • 무엇을 만들었는지 이해하고 검토하는 책임은 사람에게 남아 있어야 함

이 검토 루프가 없으면 생산성은 잠깐 올라가도 품질이 무너지고, 장기적으로는 오히려 속도가 느려집니다.

바로 적용할 체크리스트

오늘 내용 기준으로, 바로 실행 가능한 최소 체크리스트를 정리하면 다음과 같습니다.

  1. 규칙을 추상 문장이 아니라 조건/행동 문장으로 바꿨는가?
  2. 중요한 지시를 대화창이 아니라 파일에 먼저 기록했는가?
  3. 반복 누락 항목에 훅 기반 자동 검증을 붙였는가?
  4. 프로젝트 구조를 AI가 탐색하기 쉽게 분리/정리했는가?
  5. 폴더/파일 가이드 문서로 맥락 설명 비용을 줄였는가?
  6. 생성 이후 리뷰 기준(정확성/안전성/일관성)을 운영하고 있는가?

마무리

Claude Code의 성능은 모델 스펙보다 운영 체계에 더 크게 좌우됩니다.

이번 영상을 실무 관점으로 요약하면, “잘 쓰는 사람"은 프롬프트를 잘 꾸미는 사람이 아니라 규칙, 기록, 자동 검증, 구조화를 통해 실수 가능성을 시스템적으로 줄인 사람입니다. 당장 하나만 적용한다면, 오늘부터는 중요한 의사결정을 대화창이 아니라 파일에 먼저 남기는 습관부터 시작해 보세요.

참고