AI가 모르는 것을 찾아라 - Fable 필드 가이드 (Thariq Shihipar, Anthropic)

By on July 22, 2026

들어가며

Anthropic의 Claude Code 팀 엔지니어 타릭 시히파(Thariq Shihipar) 가 AI Engineer World’s Fair에서 발표한 “Field Guide to Fable(Fable 필드 가이드)” 는 공개 3일 만에 200만 뷰를 기록하며 큰 화제가 되었습니다.

이 발표가 흥미로운 이유는 흔한 “프롬프트 잘 쓰는 법” 강연이 아니기 때문입니다. 핵심 메시지는 이것입니다.

AI 프로젝트의 병목은 “AI가 얼마나 똑똑한가”가 아니라, “AI가 무엇을 모르고 있는가”다.

즉, 좋은 개발자는 AI에게 답을 묻는 사람이 아니라 AI가 모르는 것(Unknowns)을 먼저 찾아 줄여주는 사람이라는 것입니다. 이번 글에서는 발표의 핵심 개념과, 백엔드 개발 업무에 어떻게 적용할 수 있는지 정리해 보겠습니다.

1. 모델은 설계되는 것이 아니라 길러진다 (Grown, not Designed)

기존에는 모델을 하나의 프로그램처럼 생각했습니다. 입력이 같으면 출력이 같고, 스펙대로 동작하는 존재로요. 하지만 타릭은 Fable을 “설계된(designed) 것이 아니라 길러진(grown) 것” 이라고 표현합니다. 물리학 공식처럼 다루지 말고, 생물학처럼 경험적으로 관찰하며 다루라는 것입니다.

여기서 중요한 관점의 전환이 나옵니다.

모델 자체는 이미 엄청난 능력을 가지고 있다. 실제 성능을 제한하는 것은 우리의 프롬프트, 하네스(harness), 워크플로우다.

한 줄로 요약하면 이렇습니다.

성능 = 모델의 능력 × 사용자의 활용 능력

실제로 Anthropic이 Claude Code의 시스템 프롬프트를 오히려 크게 줄인 이유도 여기에 있습니다. 너무 많은 규칙으로 모델을 묶어두는 것보다, 자율성을 주는 것이 더 잘 동작하는 경우가 많다는 것입니다. 타릭은 이렇게 모델의 발목을 잡는 제약을 걷어내는 작업을 언호블링(unhobbling) 이라고 부릅니다.

2. 지도는 영토가 아니다 : Unknowns

발표에서 가장 강조되는 개념입니다.

우리가 AI에게 주는 것들 — 프롬프트, 요구사항, 설계 문서, CLAUDE.md — 은 모두 지도(Map) 입니다. 하지만 실제 작업이 일어나는 곳은 영토(Territory) 입니다.

[ Map ]                          [ Territory ]

프롬프트                          실제 코드
요구사항          ≠               운영 환경
설계 문서                         DB / API
CLAUDE.md                        예외 상황, 과거 장애

지도와 영토 사이의 이 간극이 바로 Unknowns 이고, AI가 만든 코드가 운영에서 터지는 대부분의 이유가 여기서 나옵니다. AI는 멍청해서 실패하는 것이 아니라, 몰랐기 때문에 실패합니다.

3. Unknown의 4가지 종류

Unknowns는 “나”와 “AI”가 각각 아는지 모르는지에 따라 4분면으로 나뉩니다.

구분	나는 안다	나는 모른다
AI가 안다	Known Known	Unknown Known
AI가 모른다	Known Unknown	Unknown Unknown

① Known Known — 나도 알고 AI도 안다

예) “이 프로젝트는 Spring Boot 3를 쓴다”
문제 없는 영역입니다.

② Known Unknown — 내가 모른다는 것을 안다

예) “Redis Cluster의 failover 동작은 잘 모르겠다”
이건 간단합니다. AI에게 질문하면 됩니다.

③ Unknown Known — AI는 아는데 나는 모른다

예) Spring 내부 구현, GC 알고리즘, JVM 튜닝 옵션
AI가 먼저 알려줄 수 있는 영역입니다. AI를 인터뷰하면 여기서 배울 수 있습니다.

④ Unknown Unknown — 나도 모르고 AI도 모른다

예) 운영 환경의 특수 설정, 문서화되지 않은 사내 정책, 과거 장애 이력
가장 위험한 영역이고, 대부분의 장애가 여기서 발생합니다.
이 영역을 얼마나 빨리 Known으로 끌어내리느냐가 AI 협업의 품질을 결정합니다.

4. 구현시키기 전에 해야 할 일 : Unknown부터 줄여라

보통 우리는 이렇게 일합니다.

요구사항 → 구현

Fable 필드 가이드가 권하는 순서는 이렇습니다.

요구사항 → Unknown 찾기 → 계획 → 구현

구현에 들어가기 전에 Unknown을 먼저 줄일수록 구현 품질이 올라갑니다. “빨리 코드부터 뽑는 것”이 아니라 “모르는 것부터 드러내는 것”이 먼저입니다.

발표에서는 이를 위한 구체적인 기법들을 소개합니다.

① Blindspot Pass (사각지대 점검)

가장 인상적인 기법입니다. AI에게 “구현해줘”라고 하기 전에 이렇게 먼저 시킵니다.

이 설계에서 빠진 부분을 찾아줘

숨겨진 위험은?

운영에서 문제될 부분은?

테스트가 부족한 부분은?

즉, AI를 개발자보다 리뷰어로 먼저 사용하는 것입니다. AI는 코드를 생성하는 능력만큼이나 설계의 구멍을 찾아내는 능력이 뛰어납니다.

② AI와 인터뷰하기

AI를 코더가 아니라 기술 토론 상대처럼 계속 인터뷰합니다.

왜 그렇게 구현했어?

다른 방법은 없어?

더 단순한 방법은?

운영에서 위험한 점은?

이 과정에서 위 4분면의 Unknown Known(AI는 아는데 나는 모르던 것)이 드러납니다.

③ 구현 노트 (Implementation Notes)

AI는 세션이 끝나면 대화를 잊습니다. 그래서 구현하면서 다음을 계속 기록합니다.

왜 이렇게 설계했는지
왜 이 API를 선택했는지
어떤 Trade-off를 선택했고 왜 그랬는지

이 노트가 있으면 다음 세션에서 AI가 컨텍스트를 다시 이해하는 속도가 매우 빨라집니다. 지도(Map)를 영토(Territory)에 가깝게 계속 갱신하는 작업인 셈입니다.

④ Quiz 기법

구현이 끝난 후에는 AI에게 자기 결과물을 시험하게 합니다.

내 코드를 시험해봐

이 코드의 약점은?

동시성 문제는?

보안 문제는?

일종의 셀프 코드 리뷰입니다. 생성한 AI와 검증하는 AI의 역할을 분리하면 효과가 더 좋습니다.

5. AI는 “생각”보다 “행동”을 잘한다 : Capability Overhang

발표에 나온 재미있는 예시입니다.

질문: 이름이 “aw”로 끝나는 포켓몬은?

일반 챗봇에게 물으면 틀리거나 모른다고 합니다. 모든 포켓몬 이름을 알고 있는데도요. 하지만 같은 모델이 Claude Code 안에서는 이렇게 동작합니다.

포켓몬 목록 다운로드
  ↓
필터링 스크립트 작성
  ↓
실행
  ↓
정답 출력 (Croconaw, Drednaw)

같은 모델인데 결과가 완전히 다릅니다. 차이는 지능이 아니라 도구를 사용할 수 있느냐입니다. 타릭은 이것을 Capability Overhang(능력 과잉) 이라고 부릅니다. 모델은 이미 우리가 쓰는 것보다 훨씬 많은 능력을 갖고 있고, 그 능력은 도구와 워크플로우를 통해서만 발현된다는 것입니다.

머릿속으로 답하게 하지 말고, 행동(검색, 스크립트 작성, 실행, 검증)하게 만드는 것이 핵심입니다.

백엔드 개발 관점에서 적용해보기

Spring Boot 기반의 백엔드, 특히 금융·결제처럼 운영 리스크가 큰 시스템에 적용해보면 이렇게 바뀝니다.

기존 방식:

"이 기능 구현해줘."

Fable 방식:

이 요구사항의 Unknown을 찾아줘.
운영에서 위험한 부분을 찾아줘.
동시성 이슈를 찾아줘.
장애 포인트를 찾아줘.
테스트해야 하는 케이스를 모두 나열해줘.
그 후 구현 계획을 세워줘.
마지막에 코드를 작성해줘.

코드 생성은 7단계 중 마지막 한 단계일 뿐입니다. 앞의 여섯 단계는 전부 지도와 영토의 간극, 즉 Unknown을 줄이는 작업입니다.

배치 개발이라면 “재실행 시 멱등성은?”, 외부 기관 연동이라면 “타임아웃과 재시도 정책에서 빠진 것은?”, MR 리뷰라면 “이 diff가 건드리지 않았지만 영향받는 코드는?” — 이런 질문을 구현 전에 먼저 던지는 것입니다.

이 접근은 단순히 코드를 빨리 뽑는 것보다 설계 품질과 리뷰 품질을 높이는 데 초점을 맞추며, Unknown Unknown이 곧 장애로 이어지는 복잡한 운영 시스템에서 특히 효과적입니다.

마치며

발표의 핵심을 한 문장으로 요약하면 이렇습니다.

좋은 개발자는 AI에게 답을 묻는 사람이 아니라, AI가 무엇을 모르는지를 먼저 찾는 사람이다.

모델은 이미 충분히 똑똑하다. 병목은 우리의 활용 방식이다.
지도(프롬프트·문서)는 영토(실제 코드·운영환경)가 아니다. 그 간극이 Unknown이다.
구현 전에 Blindspot Pass로 사각지대를 먼저 찾고, AI를 인터뷰하고, 구현 노트를 남기고, 끝난 뒤 Quiz로 검증하라.
생각하게 하지 말고 행동하게 하라. 모델의 능력은 도구를 통해 발현된다.

AI 코딩 도구가 상향 평준화되는 지금, 결국 차이를 만드는 것은 “무엇을 시킬 것인가”가 아니라 “무엇을 모르는지 어떻게 드러낼 것인가” 라는 점에서 곱씹어볼 만한 발표였습니다.