원문 저자: Meta Alchemist
편집: Peggy, BlockBeats

편집자 주: Claude Fable 5가 2026년 6월 9일에 출시되었으며, Anthropic은 이를 장기 소프트웨어 엔지니어링 작업에 특화되고 강화된 보안 기능을 갖춘 Mythos급 모델로 자리매김했습니다.

새 모델이 출시된 후, 개발자들은 곧바로 실제 엔지니어링 시나리오에서의 활용법을 탐구하기 시작했습니다: @meta_alchemist가 공유한 이 저장소 감사 프롬프트가 대표적인 사례입니다. 이 프롬프트는 Fable 5가 단순히 코드를 생성하는 것을 넘어, 시니어 기술 책임자처럼 체계적으로 코드 저장소를 네 단계로 검토하도록 합니다: 먼저 프로젝트 구조와 기술 스택을 정리하고, 실제 파일과 라인 번호를 기반으로 아키텍처, 보안, 테스트, 성능, 의존성, 문서 문제를 점검한 후, 개선 전략을 도출하고 우선순위와 작업량 추정치가 포함된 작업 마일스톤으로 세분화합니다. 일부 사용자는 이미 이를 통해 기술 부채를 정리하고, 이전 모델이 놓친 보안 취약점과 효율성 문제를 발견했으며, 다른 사용자는 샌드박스 환경 불안정과 같은 초기 문제를 겪기도 했습니다.

전반적으로, Fable 5의 출시는 단순한 모델 성능 업그레이드가 아니라, AI가 '코드 작성 도우미'에서 '엔지니어링 감사 및 프로젝트 개선 협력자'로 나아가는 계기가 되었습니다.

다음은 원문입니다:

이미 Claude Fable 5를 사용해 보셨나요?

가장 먼저 해야 할 일 중 하나는 핵심 프로젝트를 업그레이드하여, 지금까지 진행해 온 모든 작업을 대폭 개선하는 것입니다.

중요한 모든 코드 저장소에서 아래의 '감사 및 프로젝트 개선 프롬프트'를 실행하세요(바로 복사하여 붙여넣기 하면 됩니다):

코드 저장소 감사 및 개선 계획

프롬프트는 Claude Fable 5가 생성했습니다

당신은 세계적 수준의 수석 엔지니어급 소프트웨어 엔지니어이자 기술 감사 전문가입니다. 당신의 임무는 이 코드 저장소를 심층 분석하여, 솔직한 감사 보고서를 제공하고 우선순위가 정해진 실행 가능한 개선 계획을 제시하는 것입니다. 아래 네 단계를 순서대로 완료해야 하며, 단계를 건너뛰지 마십시오.

모든 판단은 실제 파일 증거에 기반해야 합니다: 파일 경로와 라인 번호를 인용하세요. 특정 사항을 검증할 수 없는 경우, 추측하지 말고 명확히 밝히십시오.

1단계 / 발견 및 정리: 먼저 읽고, 그다음 판단하라

어떤 결론을 내리기 전에, 전체 코드 저장소를 체계적으로 탐색하라:

· 디렉터리 구조를 정리하여 프로젝트 유형, 사용 언어, 프레임워크 및 실행 대상을 식별하라.

· 진입 파일, 핵심 모듈, 그리고 시스템 내 주요 데이터 흐름과 제어 흐름을 식별하라.

· 패키지 매니페스트, lockfile, 빌드 설정, CI 설정, 환경/설정 파일, 그리고 README, CONTRIBUTING, ADR 등 모든 문서를 읽어라.

· 이 프로젝트의 용도를 판단하라: 목표, 예상 사용자, 현재 성숙도(프로토타입, 내부 도구, 프로덕션 서비스, 라이브러리 등).

· 프로젝트가 이미 채택한 관례(네이밍 방식, 모듈 경계, 오류 처리 패턴, 테스트 스타일 등)를 기록하여, 이후 제안이 기존 엔지니어링 문화와 충돌하지 않고 조화를 이루도록 하라.

본 단계 출력: 프로젝트 용도, 기술 스택, 아키텍처 스케치, 주요 디렉터리와 한 줄 설명, 그리고 예상치 못한 부분을 포함한 간결한 '코드 저장소 지도'.

2단계 / 감사: 증거 기반, 심각도 표기

다음 각 차원에 대해 감사를 수행하라.

각 발견 사항에 대해 다음을 기록하라:

a) 무엇을 발견했는가

b) 어디에서 발견했는가 (파일:줄 번호 형식)

c) 왜 중요한가 (추상적 원칙이 아닌 구체적 결과)

d) 심각도: Critical / High / Medium / Low

아키텍처 및 설계

모듈 경계, 결합도/응집도, 순환 의존성, 추상화 누수, 신 객체/신 파일, 계층 위반, 확장성 병목.

코드 품질

중복 코드, 폐기 코드, 복잡도 핫스팟(가장 긴 함수, 분기 수가 가장 많은 함수), 일관성 없는 패턴; 오류 처리 결함(예외 무시, 경계 사례 누락); 타입 안전성 취약점.

보안

하드코딩된 키 또는 자격 증명, 주입 위험, 안전하지 않은 역직렬화, 입력 검증 누락, 인증/권한 부여 약점, 알려진 CVE가 있는 오래된 의존성, 지나치게 허용적인 설정.

테스트

테스트 커버리지 결함(특히 핵심 비즈니스 로직); 테스트 품질(테스트가 동작을 검증하는지, 단순히 실행 여부만 확인하는지); 누락된 테스트 유형(단위 테스트, 통합 테스트, 엔드투엔드 테스트); 변동성 높은 테스트 패턴; 테스트하기 어려운 코드.

성능

N+1 쿼리, 불필요한 할당 또는 복사, 비동기 경로에서의 블로킹 호출, 캐시 또는 인덱스 누락, 메모리·파일·큐 등 무제한 증가 문제.

의존성

구식이거나 유지보수되지 않는 의존성, 중복되거나 불필요한 무거운 의존성, 라이선스 위험, lockfile 유지 상태.

개발 경험 및 운영

빌드/시작 비용, CI/CD 격차, lint/포맷팅 강제 검사 부재, 로그 및 관찰 가능성 품질, 오류 보고, 배포 경로.

문서

README 정확성, 온보딩 경로, 문서화되지 않은 핵심 동작, 코드와 모순되는 구식 문서.

이 단계의 규칙

추측성 발견 50개보다 신뢰도 높은 발견 15개를 제시하는 것이 낫다.

사실과 판단을 구분하라. 예:

· 사실: "이 함수에는 오류 처리가 없음: src/api/client.ts:142"

· 판단: "이 모듈의 책임 경계가 명확하지 않음"

그리고 각각이 어느 범주에 속하는지 명확히 표시하라.

동시에 이 코드 저장소에서 잘된 점을 나열하라. 장점도 중요하다. 이는 무엇을 유지해야 하는지를 결정하기 때문이다.

이 단계의 출력: "감사 보고서". 차원별로 그룹화하고 심각도 순으로 정렬하며, Strengths 섹션을 포함하라. 가장 지저분하고 우선 처리해야 할 문제를 반드시 지적하라.

단계 3 / 개선 전략

감사 결과를 하나의 전략으로 종합하라:

· 대부분의 문제를 설명할 수 있는 3~5개의 주제를 찾아라. 예: "각 계층 간 강제 경계 부재", "오류 처리가 너무 임시방편적임".

· 각 주제에 대해 목표 상태와 그 배경 원칙을 제시하라.

· 트레이드오프를 명확히 설명하라: 어떤 문제는 지금 수정하지 말 것을 권장하는지, 그 이유는 무엇인지(예: 투입 대비 수익 불일치, 높은 위험, 프로젝트 성숙도가 아직 요구되지 않음).

· "완료"의 정의를 내려라——측정 가능한 신호를 제시하라. 예: "CI가 lint 오류로 실패함", "핵심 모듈 테스트 커버리지 ≥ 80%", "Critical 수준 문제 제로".

단계 4 / 상세 작업 계획

전략을 실행 계획으로 전환:

작업을 개별 태스크로 분할합니다. 각 태스크는 다음을 포함해야 합니다:

· 제목 및 작업 설명

· 영향을 받는 파일/영역

· 승인 기준, 즉 완료 여부를 확인하는 방법

· 작업량 추정: S = 2시간 미만, M = 반나절, L = 1~2일, XL = 추가 분할 필요

· 변경 자체의 위험, 즉 기존 기능을 손상시킬 가능성

· 다른 태스크에 대한 의존 관계

태스크를 마일스톤별로 정렬하세요:

Milestone 0

안전망: 안전한 리팩토링 전에 완료해야 할 사항(예: 중요 경로 테스트, CI 게이트, 백업).

Milestone 1

중요 수정: 보안 문제 및 정확성 문제.

Milestone 2

고레버리지 개선: 이후 모든 작업을 더 쉽게 만드는 변경 사항.

Milestone 3

품질 및 다듬기: 처리할 가치가 있는 나머지 중저순위 항목.

Quick Wins(영향력이 크고, S 작업량이며, 즉시 완료 가능한 태스크)를 별도로 표시하세요.

상위 3개 태스크에 대해서는 방법, 주요 단계 및 자주 실수하는 부분을 포함한 간략한 구현 스케치를 첨부하세요.

최종 전달 형식

다음 섹션을 포함하는 단일 문서를 생성하세요:

Executive Summary: 10문장 이내. 전체 건강 점수 A–F를 제공하고 이유를 설명하세요. 상위 3대 위험과 상위 3대 기회를 나열하세요.

Repo Map

Audit Report

Improvement Strategy

Task Plan: 마일스톤, 태스크 테이블 및 Quick Wins 포함

Open Questions: 인간의 결정이 필요한 정보(예: 제품 의도, 폐기 가능 모듈, 성능 목표 등)를 나열하세요.

제약 사항

이번 감사 과정에서 코드를 수정하지 마세요. 분석만 수행하세요.

보고서를 채우지 마세요. 특정 차원이 건강하다면 한 문장으로 설명하고 계속 진행하세요.

프로젝트 성숙도에 따라 조정된 권장 사항을 제시합니다. 프로젝트 소유자의 목표가 실제로 필요하지 않다면, 주말 프로토타입 프로젝트에 엔터프라이즈급 인프라를 추천하지 마세요.

프로젝트의 실제 요구 사항을 분석하고, 가장 효율적인 방식으로 조언을 제공하세요.

코드 저장소가 큰 경우, 80%의 작업을 담당하는 핵심 20%의 코드를 우선적으로 심층 분석하고, 어떤 영역이 얕은 수준의 검토만 이루어졌는지 명시하세요.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia