먼저 결론

Claude의 정액제 플랜에서 Fable 5를 사용할 수 없게 됨(종량제 과금으로 이행)에 따라, "그렇게까지 하면서 계속 비용을 지불할 가치가 정말 있는가"를 확인하고 싶어졌습니다. 그래서 Fable 5와 정액제로 사용할 수 있는 Opus 4.8을 동일한 조건에서 제대로 벤치마크(성능 비교)해 보려는 것이 출발점이었습니다. 소재로 삼은 것은 1년 반 정도 전에 만들어서 최근까지 개선해 온 개인 개발 프로덕트입니다.

결론을 먼저 말씀드립니다.

Fable 5는 요청하지 않아도 스스로 "공격자라면 어떻게 파괴할 것인가"라는 관점에서 코드를 의심하여, 120건 이상의 버그를 찾아냈습니다. 순수한 Opus 4.8은 동일한 요청을 받았을 때 일반적인 버그 찾기 단계에서 멈추며, 이 정도로 깊게 파고들지 않습니다. 자발적인 공격적 감사(Offensive Audit)는 Fable의 확실한 강점이었습니다. -
하지만 그 강점은 "절차"를 통해 메워질 수 있었습니다. 공격자 관점을 절차로서 부여하는 audit 스킬을 Opus에 갖추어 비교해 본 결과, 찾아낸 버그의 수는 거의 막상막하였습니다. 오히려 오탐(False Positive)을 의심해야 하는 정밀도 면에서는 Opus가 앞서는 장면도 있었습니다. -
결론: 사용법은 이렇습니다. "강력한 Fable에게 감사의 '형식(Template)'을 만들게 하고, 그 형식을 정액제 Opus로 돌린다". 실제로 이 기사의 audit 스킬도 Fable에게 "같은 일을 Opus로 하려면 어떻게 해야 할까?"라고 상담하여 만든 것입니다. 강력한 모델은 "절차 만들기"에 한 번만 사용하고, 일상적인 실행은 저렴한 정액제 모델에 맡긴다 ── 이렇게 하면 대부분의 상황을 커버할 수 있습니다. 그 와중에 가장 사업 임팩트가 큰 1건을 찾아낸 것은 Fable뿐이었기에, 출시 전 등 승부처에서만 Fable로 한 번 더 돌립니다. 종량제 과금이라 하더라도 이 방식이라면 충분히 본전을 뽑을 수 있습니다.

이하, 이 결론에 도달하기까지의 과정을 순서대로 적어 나가겠습니다. 우선 발단 ── Fable에게 무심코 감사를 부탁했더니, 상상 이상의 결과가 돌아왔다는 부분부터 시작합니다.

1. "완성되었다고 생각한" 코드에서 버그가 대량으로 발생하다

저는 개인적으로 몇 가지 SaaS를 개발 및 운영하고 있습니다. 결제가 포함된 모바일 앱과 Laravel로 제작된 CRM입니다. 둘 다 AI 오케스트레이터(AI Orchestrator, 후술)로 개발하였고, 테스트도 정비되어 스토어에 공개된 상태입니다. 1년 반 정도 전에 만들어 최근까지 기능 개선을 지속해 왔습니다. 즉, "새로 대충 만든 것"이 아니라 나름대로 공을 들여온 코드입니다.

수행한 작업은 단순했습니다. Fable에게 "버그나 리팩터링(Refactoring)할 수 있는 부분을 찾아줘"라고 부탁했을 뿐입니다. 특별한 지시는 하지 않았습니다.

그런데 돌아온 결과물이 일반적인 버그 찾기의 범위를 넘어섰습니다. 타인의 ID를 일부러 지정하면 어떻게 될까? 결제 알림이 의도적으로 늦게 도착한다면? 같은 버튼을 동시에 두 번 누르면? ── 이런 "시스템을 숙지한 공격자라면 어디를 찌를 것인가"라는 관점에서의 지적이 요청하지도 않았는데 계속해서 나왔습니다. 취약점 진단이나 침투 테스트(Penetration Test)에 가까운 발상으로, 이 기사에서는 이를 "공격적 감사"라고 부릅니다. 어쨌든, 저는 그저 "찾아줘"라고 부탁했을 뿐인데, 공격자 관점의 결점 찾기는 Fable이 알아서 수행했다는 것이 포인트입니다 (이 "알아서 한다"는 점이 나중에 효과를 발휘합니다).

미리 말씀드리자면, 여기까지의 테스트를 자체적으로 수행하는 개발 현장은 많지 않습니다. 통상적인 개발은 기능 테스트(사양대로 동작하는지 확인)까지가 표준이며, 이런 종류의 취약성은 외부 보안 전문 회사에 진단을 의뢰하고 나서야 비로소 발견되는 경우가 많습니다. 실제로 다음에 나올 IDOR(타인의 데이터에 ID 지정으로 접근할 수 있는 접근 제어 미비)는 OWASP Top 10이라는 세계적인 취약점 랭킹에서 1위로 꼽힐 정도의 "전형적인 허점"입니다. 전 세계 전문가들이 만든 시스템에서도 여전히 1위입니다. 즉, 앞으로 나올 버그들은 "제가 특별히 부주의했다"는 이야기가 아니라, 전문적인 감사를 거치지 않은 시스템에는 평범하게 잠들어 있는 것들이라고 생각하고 읽어주시기 바랍니다.

결과적으로 두 프로덕트 합계 120건 이상의 지적이 나왔습니다. 생생한 내용이라 상세한 내용은 생략하지만, "유형"으로 나누면 다음과 같습니다.

버그 유형	내용 예시
인가·보안 (IDOR)	타인의 ID를 지정하여 해당 데이터에 접근할 수 있음
...

테스트는 모두 통과했음에도 불구하고 말입니다.

2. 왜 "테스트를 통과한 코드"에서 버그가 나오는가

이유는 세 가지가 있습니다.

첫 번째. "사양대로 작동하는가"를 확인하는 테스트에서는 "악의적인 사람이 조작했을 때 보안(Secure)이 유지되는가"가 드러나지 않습니다.

일반적인 테스트는 "올바르게 사용하면 제대로 작동하는가"를 확인합니다. 하지만 공격자는 올바르게 사용해주지 않습니다. 이 부분이 맹점입니다.

오해를 없애기 위해 덧붙이자면, 일반적인 보안 코딩 (Secure Coding) (비밀번호를 해시화하거나, SQL에 값을 전달할 때 플레이스홀더(Placeholder)를 사용하여 SQL 인젝션(SQL Injection)을 방지하는 것 등)은 현재의 AI가 상당히 잘 해냅니다. 문제는 그게 아닙니다. "일부러 공격하지 않으면 나타나지 않는" 타입의 취약성이 남는다는 것입니다. 예를 들어,

• 순서를 추측할 수 있는 URL을 생성하는 경우 (예: /order/1001 다음이 /order/1002가 되어 타인의 주문을 볼 수 있는 등)
• 화면에는 보이지 않는 형태로 심겨 있는 ID를 공격자가 수정하여 다른 요청을 보내는 경우 (이것이 IDOR입니다)

이런 것들은 "정상적으로 사용하는" 테스트를 아무리 통과해도 모습을 드러내지 않습니다. 직접 공격자의 입장이 되어 일부러 이상한 조작을 시도해 보아야 비로소 나타납니다. 이러한 관점은 일반적인 테스트에는 애초에 포함되어 있지 않습니다.

두 번째. 테스트를 작성한 AI와 구현을 담당한 AI가 동일한 설계서에서 출발하기 때문입니다. 설계서에 "알림이 늦게 도착한다면" 또는 "같은 버튼을 동시에 두 번 누른다면"과 같은 내용이 적혀 있지 않다면, 구현에서도 테스트에서도 동시에 누락됩니다. 테스트를 통과했다는 것은 "설계서대로 작동한다"는 증명은 될 수 있어도, "설계서 범위를 벗어난 상황에서도 망가지지 않는다"는 증명은 되지 않습니다.

세 번째. AI 주도 개발(AI-Driven Development)에서는 "작동하는 것처럼 보이지만 알맹이가 비어 있는" 버그가 양산되기 쉽습니다.

예를 들어, 결제가 끝난 뒤에 호출되는 프로세스가 함수로는 준비되어 있지만, 정작 내부 내용은 비어 있는 케이스가 있었습니다. 내용이 비어 있어도 해당 함수는 정상적으로 호출되고 정상적으로 종료됩니다. 에러도 발생하지 않습니다. 프로그램 입장에서는 "성공"입니다. 하지만 실제로는 해야 할 처리 (계약을 데이터베이스에 기록하는 것 등)가 아무것도 일어나지 않습니다. 실패한 것이 아니라, 실패해야 할 상황에서 묵묵히 성공하는 척을 하고 있는 것입니다. 게다가 에러가 발생하지 않기 때문에, 그 내부를 굳이 검사하는 테스트가 없다면 아무도 알아차릴 수 없습니다.

AI는 "일단 돌아가는 형태"를 만드는 데 매우 능숙합니다. 뒤집어 말하면, 이러한 "껍데기만 준비하고 알맹이는 나중으로 미루는" 방식이 에러를 내지 않은 채 운영 환경에 남기 쉽습니다. 흔히 말하는 "돌아가면 OK인 구현"의 정체가 대개 이것입니다.

3. AI 오케스트레이터에서 누락되었던 "공정"

저는 Claude Code를 사용하여 "AI 오케스트레이터"라는 개발 플로우를 구축하고 있습니다. 대략적으로 말하면 설계 $\rightarrow$ 리뷰 $\rightarrow$ 구현 $\rightarrow$ 리뷰 $\rightarrow$ 테스트라는 공정을 기능별로 AI가 수행하도록 하는 메커니즘입니다. 혼자서 SIer와 같은 개발을 하기 위해 만들었습니다 (자세한 해설은 지난번 Qiita 기사, 실물은 GitHub에 MIT 라이선스로 공개되어 있습니다 $\rightarrow$ orchestrator-skills. 이 글에서 만드는 audit 스킬도 여기에 포함되어 있습니다).

이를 도입한 시점에서 코드의 품질은 상당히 올라갔습니다. 실제로 도입했을 때도 "설계와 구현의 괴리"와 같은 버그를 많이 발견하고 해결할 수 있었습니다.

보안 측면도 완전히 무방비했던 것은 아닙니다. AI 주도 개발 특유의 대책 ── 라이선스 오염을 방지하거나 소스 코드 및 비밀 정보가 외부로 유출되지 않도록 하는 것 ── 은 마련해 두었으며, 다른 기사에서 소개한 "레벨 2 보안 도구군" (시크릿 스캔, 의존성 취약점 점검(SCA), 정적 분석(SAST), DAST, 라이선스 스캔 등을 무료 도구로 구성한 것)도 이 프레임워크에 통합되어 있습니다. 이 도구들은 CVE와 같이 이름과 번호가 붙어 세상에 공개된 "기존의 취약성(Known Vulnerabilities)"을 탐지하는 데 매우 특화되어 있으며 상당히 강력합니다.

하지만 이번에 새삼 깨달았습니다. 이 플로우에는 "공격적 감사(Offensive Audit)" 공정이 포함되어 있지 않았다는 것을 말입니다.

자동화 도구가 잘하는 것은 어디까지나 "기존의 (이름이 붙은) 취약성 패턴"의 탐지입니다. 그러나 이번에 대량으로 발생한 IDOR나 "가짜 성공"과 같은 버그는 "이 기능과 저 기능의 조합이기 때문에 망가진다"는, 해당 시스템 고유의 일회성 로직 결함이었습니다. 아직 아무도 이름을 붙이지 않은 결함이기에 패턴 매칭으로는 잡아낼 수 없습니다. 도구를 갖추고 있었음에도 이 글의 버그가 발생한 이유는 바로 이 때문입니다.

참고로 말씀드리자면, 저는 정보처리안전확보지원사 자격을 보유하고 있어 "공격자라면 어떻게 공격할 것인가"라든가, 보안 코딩 (Secure Coding)의 사고방식은 당연한 관점으로 알고 있었습니다. 제 손으로 직접 코드를 작성하던 시절에는 의식하지 않아도 자연스럽게 그런 눈으로 바라보았을 것입니다.

그런데 AI에게 개발을 맡기는 구조로 전환했을 때, 그 공정이 쏙 빠져버렸습니다. 머리로는 알고 있는데, 플로우 (Flow)에 적용할 때 실수로 누락해 버린 느낌입니다. 이것이 AI 주도 개발 (AI-Driven Development)에서 상당히 무서운 지점이라고 생각합니다. 인간이 직접 할 때는 무의식적으로 하던 일이, AI에게 맡기는 구조로 바꾸는 순간 명시적으로 포함하지 않으면 사라지는 것입니다.

실제로 저의 리뷰 공정이 보고 있었던 것은 줄곧 "설계대로 만들어졌는가"였습니다. 설계서와 구현을 대조하며 차이점을 찾는 것. 이것도 중요하지만, 뒤집어 말하면 "설계서에 적혀 있지 않은 것"은 처음부터 시야 밖에 있다는 뜻입니다. "공격자라면 어떻게 망가뜨릴 것인가"는 설계서에 적혀 있지 않습니다. 그래서 리뷰에서도 테스트에서도 아무도 (AI도 저도) 그 부분을 보지 않았습니다.

정답 맞히기(설계대로인가)는 하고 있었지만, 반증 찾기(어떻게 망가뜨릴 수 있는가)는 하지 않았습니다. 이것이 최근까지 계속 개선해 온 코드에서 120건 이상이 튀어나온 근본적인 원인이었습니다.

4. Fable은 "요청하지 않아도" 공격자의 시선으로 의심하러 왔다

여기서 흥미로운 일이 일어났습니다.

평소 사용하는 순수한 Opus 4.8에게 감사 관련 작업을 시켜도, 요청하지 않는 한 공격적 감사 (Adversarial Audit)를 스스로 수행하지는 않았습니다. "설계대로인지 확인해 줘"라고 하면 설계대로인지 확인합니다. 성실하지만, 지시받은 범위 내에서 멈춥니다.

그런데 Fable 5로 전환했더니, 요청하지 않았는데도 스스로 "공격자라면 어떻게 공격할 것인가"를 의심하러 간 것입니다. 타인의 ID를 지정하면 어떻게 될까? 이 실패 경로 (Failure Path)는 무엇인가? 라며 이쪽에서 지시하지 않아도 알아서 반증을 찾기 시작했습니다. 그리고 거기서 대량의 버그가 나왔습니다.

이것이 단 한 번의 우연인가 싶었지만, 두 개의 프로덕트에서 각각 Fable을 실행해 보았고, 둘 다 동일한 동작을 보였습니다. 자발적으로 공격적 감사를 수행한 것은 Fable뿐이었습니다. 재현성이 있었던 것입니다.

덧붙여, 버그 찾기나 리팩터링 (Refactoring) 작업에 관해 Fable 자신에게 "Opus와의 차이점은?"이라고 물으니 "공격적 감사의 관점이 있다는 것"이라고 알려주었으며, 관찰된 동작과도 정확히 일치했습니다.

참고로 Fable은 최상위 모델인 "Mythos"와 내부 내용이 같으며, 위험한 용도에 대한 안전장치가 붙어 있는 것이 Fable, 그것을 제거한 것이 Mythos라는 관계입니다 (이는 Anthropic이 공식적으로 설명하고 있습니다). 소문이 아니라 사실로서, Fable의 실제 실력은 톱 모델과 같다는 뜻입니다.

5. 그렇다면 그 "태도"를 절차로 부여할 수 없을까 ── audit 스킬

여기서 발상이 바뀌었습니다.

Fable의 강점이 "공격자의 시선으로 스스로 의심하는 태도"라면, 그 태도를 "절차"로서 써 내려가 Opus에게 전달하면, Opus도 똑같은 일을 할 수 있지 않을까? 모델의 성격에 의존할 수 없다면 체크리스트로 대체하면 됩니다.

흥미로웠던 점은 여기서부터입니다. 정보를 공유하지 않은 두 프로젝트의 Claude Code에게 각각 별도로 "같은 일을 Opus로 하려면 어떻게 해야 할까?"라고 상담해 보았습니다. 그러자 둘 다 독립적으로 audit (공격적 감사)이라는 스킬을 준비해 왔습니다. 서로 교류하지 않은 두 개가 별개로 동일한 설계에 도달한 것입니다.

그렇게 생각하여, AI 오케스트레이터 (AI Orchestrator)에 audit (공격적 감사)이라는 역할의 스킬을 추가했습니다. 목표는 "정액제인 Opus를 최대한 Fable에 가깝게 만드는 것"입니다. 내용은 단 4가지뿐입니다.

찾을 대상을 리스트로 전달한다. "버그를 찾아줘"가 아니라 "이 리스트(IDOR / 실패 무시 / 병행 처리 / 데드 코드 등)를 바탕으로 하나씩 확인해 줘"라고 한다. 모호하게 부탁하면 결과가 흔들리지만, 리스트로 부탁하면 안정됩니다.

영역을 나누어 병렬로 "전부" 읽게 한다. 담당 영역을 통째로 읽게 하여 리스트와 대조시킨다. 우연히 눈에 띈 것만 보고하는 상태를 없앱니다.

발견한 지적 사항을 다른 에이전트에게 의심하게 한다. "그 코드, 정말로 실행되는 위치에 있어?", "그 기능, 애초에 사용되고 있어?"라고 반대 심문을 하게 한다. 보고서만 번지르르한 오탐 (False Positive)이 이로 인해 사라집니다.

새로운 발견이 나오지 않을 때까지 반복한다.

요컨대, Fable이 「성격(Personality)"으로 수행하던 것을, Opus에게는 「절차(Procedure)"를 통해 강제적으로 수행하게 만드는 전략입니다.

6. 실측: 동일한 조건에서 Opus 4.8과 Fable 5를 비교

그렇다면 절차를 부여받은 Opus는, 자발적으로 움직이는 Fable을 어디까지 따라잡을 수 있을까요? 실험을 통해 확인했습니다.

조건은 다음과 같이 맞추었습니다.

• Fable이 감사(Audit)한 것과 동일한 상태의 코드를 준비한다 (찾아낸 버그를 기록하기 전 상태로 되돌린다. 기록이 남아 있으면 정답이 보이기 때문)
• 감사하는 AI에게는 해당 코드 이외의 읽기 및 변경 이력(Change History) 참조를 금지한다 (이력에 수정 사항, 즉 정답이 있기 때문)
• audit 스킬의 절차는 그대로 유지하되, 담당하는 AI를 전부 Opus 4.8로 설정하여 실행한다 (16체의 에이전트가 분담, 약 35분 소요)
• Fable이 찾아낸 버그를 세부 단위로 나누어 정답 확인용 리스트를 만든다

결과입니다.

지표	값
Opus가 Fable과 동일한 것을 찾아냄	21건 중 10건
Opus가 놓침	8건
Opus만이 찾아낸 새로운 버그	13건 (그중 9건은 현재 코드에도 남아 있었음)
Fable의 「오탐 (False Positive)」을 Opus가 간파함	1건

「절반밖에 재현하지 못한 건가」라고 생각하실지도 모릅니다. 하지만 이 채점은 단방향이며, 「Opus가 Fable을 얼마나 재현했는가」만을 보고 있습니다. 반대로 보면, Fable 역시 Opus가 찾아낸 13건을 놓치고 있었다는 뜻입니다. 서로 비슷하게 놓치고 있습니다. 즉, 찾아낸 수로 보면 거의 막상막하였습니다. 절차를 부여하자 Opus는 자발적으로 움직이는 Fable과 어깨를 나란히 했습니다.

오히려 Opus가 더 신중했던 장면도 있습니다. Fable이 「메일 인증의 남은 시간이 48시간이나 더 길게 표시되는 버그」를 보고하고 수정안까지 내놓았으나, Opus는 「프레임워크의 사양상 해당 코드에서는 버그가 발생하지 않을 것」이라며 거부했습니다. 저 스스로도 어느 쪽이 옳은지 실기(Real device)로 확인한 것은 아니기에 단정 짓지는 않겠습니다. 다만, 다른 지적을 그대로 받아들이지 않고 일단 「정말로 이것이 버그인가?」라고 의심하는 자세는 Opus 쪽이 더 강하게 나타났습니다. 「틀림을 의심하는 정밀함」에 있어서는 Opus가 빛을 발하는 장면도 있었다는 뜻입니다.

하지만 놓친 내용의 "내용물"에는 차이가 있었습니다. 이번 전체 버그 중 가장 타격이 큰 1건 ── 「결제는 통과되는데, 결제 후에 "계약 성립"을 앱에 기록하는 처리가 비어 있는」 버그 (2장에서 언급한 "작동하는 것처럼 보이지만 내용물이 비어 있는" 실제 사례입니다) ── 를 놓친 쪽은 Opus였습니다. Opus는 「이 문제는 기지(Known issue)」라는 라벨을 보고 거기서 파고드는 것을 멈췄습니다. 반면 Fable은 「그렇다면 실제로 작동하는 쪽의 처리는 무엇을 하고 있는가?」라며 한 걸음 더 들어가, 내용이 비어 있음을 밝혀냈습니다. 수는 막상막하였지만, 「기지의 바로 옆을 한 단계 더 파고드는」 끈기에는 차이가 있었습니다 (1회씩만 비교했으므로 운의 차이일 수도 있습니다).

7. 이 실험의 약점 (솔직하게)

수치를 제시한 이상, 약점도 솔직하게 적어두겠습니다.

• 단 1회씩만 실행했습니다. 나타난 차이가 「모델의 차이」인지 「우연」인지는 구분되지 않았습니다.
• 채점한 심판이 Fable 자신입니다. 원래는 제삼자가 채점해야 했습니다. 다만, 가장 논란이 되었던 판정(방금 전 오탐 관련 건)에서는 Fable이 「이것은 버그」라고 보고한 것에 대해 Opus가 반론을 제기했으므로, Fable이 자신에게 불리한 지적을 은폐했을 가능성은 낮아 보인다는 느낌을 받았습니다. 따라서 채점이 극단적으로 Fable에게 관대했을 걱정은 적다고 생각합니다.
• Fable 런(Run)의 일부는 사양상 Opus가 답변했을 가능성이 있습니다. Fable은 보안 관련 주제일 경우 자동으로 Opus로 전환되는 사양이기 때문에 (전환 시 알림이 뜹니다), 「Fable의 성적」에 Opus의 분량이 섞여 있을 수 있습니다. 다만 이는 사양이므로, 「Fable을 사용한다」는 것은 「그러한 동작을 포함하여 사용한다」고 간주해도 무방한 부분입니다.

덧붙여, 「자발적으로 공격적인 감사를 수행한다」는 Fable의 동작 그 자체는 두 가지 프로덕트에서 재현되었으므로, 이 부분은 어느 정도 확실하다고 생각합니다.

8. 결론: 「Fable이라서」 지불하는 것이 아니라, 「이 사용법에」 지불하는 것

• 버그를 찾아내는 능력 그 자체는 Opus + audit 스킬로 거의 재현할 수 있었습니다. 모델의 "성격"에 의존하지 않더라도, 공격자 관점(attacker perspective)을 절차로 녹여낸다면 대체 가능하다 ── 이것이 이번의 가장 큰 수확입니다.
• 추천하는 사용법은 「역할 분담」입니다. 먼저 Fable(강력한 모델)에게 감사(audit) 절차 그 자체를 설계하게 하여 스킬로 정립합니다. 그 후 일상적인 감사는 정액제인 Opus로 해당 스킬을 사용하여 돌립니다. 강력한 모델은 "틀 만들기"에 한 번 사용하고, 반복적인 실행은 저렴한 모델에 맡기는 방식입니다. 이번 audit 스킬도 Fable에게 "같은 일을 Opus로 하려면 어떻게 해야 해?"라고 상담하여 만들게 한 것이었습니다.
• 승부처에서만 Fable로 한 번 더 돌리기. 사업 임팩트가 가장 큰 1건을 찾아낼 수 있었던 것은 Fable뿐이었습니다. 출시 전이나 돈이 얽힌 코드는 마지막에 Fable로 한 번 더 검토할 가치가 있습니다. 이중 신용 부여(double credit)나 IDOR를 운영 환경 전에 단 한 건이라도 잡아낼 수 있다면, 종량제 과금액은 오차 범위 수준입니다.
• 덤으로 발견한 사실: 모델을 교체하며 돌리는 것 자체가 감사가 된다. 이번 Opus 런(run)은 결과적으로 「한 번 더 수행한 감사」로서 13건의 새로운 버그를 찾아냈습니다. 동일한 모델로 횟수를 거듭하는 것보다, 모델을 교체하며 돌리는 편이 놓친 부분을 메울 수 있습니다.
• 「며칠 동안 계속 달리는 자율성」은 이번에 측정하지 않았습니다. 35분간의 런으로는 측정할 수 없기 때문입니다 (다만 그 편린은 보았습니다. 다음에 쓰겠습니다).

자율성을 측정하지 않았다고 말했지만, 사실 그 편린은 확실히 보았습니다. 이번에 Fable와 Opus의 AB 테스트(두 모델로 감사를 돌려 비교하는 작업)를 지시하고 그대로 잠들었습니다. 그랬더니 아침에 일어났을 때는 비교 검증 리포트까지 완성되어 있었습니다. 감사하고, 집계하고, 비교하고, 쓰는 ── 라는 공정을 여러 단계 거치는 일을, 아무도 보지 않는 밤 동안 스스로 끝까지 연결해 놓은 것입니다. Opus라면 중간에 "이렇게 하면 될까요?"라고 확인을 요청하며 멈추기 쉬운 부분들을, Fable는 방치 상태로 끝까지 달려 나갔습니다. 「장시간 자율적으로 움직이며 지속된다」는 셀링 포인트의 편린을 가장 체감한 순간이었습니다.

다만 이번에 시도한 것은 어디까지나 「버그 찾기·품질 향상」이라는 한 장면입니다. 실제로 프로덕트를 처음부터 만드는 공정에서 이 자율성이 어떤 차이를 만들어낼지는 아직 알 수 없습니다. 그 부분은 향후 다시 한번 시험해 보고 싶습니다.

「낼 것인가, 말 것인가」라는 이지선다형 질문에 대한 답은, "강력한 모델로 틀을 만들고, 저렴한 모델로 돌린다"였습니다. 그리고 또 하나, 자신의 개발 플로우에서 "공격자의 관점"이 빠져 있었다는 사실도 깨달을 수 있었습니다. 모델을 선택하기 전에, 먼저 「어떤 관점으로 의심할 것인가」를 메커니즘에 포함시키는 것 ── 이는 어떤 모델을 사용하는지와 관계없이 유효합니다.

감사 방법(audit 스킬)을 포함한 프레임워크는 GitHub에 공개되어 있습니다: orchestrator-skills

프레임워크 전체 해설은 여기에서 확인하세요: Claude Code로 1인 SIer를 실현하는 AI 주도 개발 프레임워크

Discussion