Claude Fable 5 필드 가이드 후기: AI에게 답보다 미지를 찾게 하라

읽는데 5분 소요

Claude Fable 5 필드 가이드 후기: AI에게 답보다 미지를 찾게 하라

GeekNews에 올라온 “Fable 필드 가이드”를 읽고 가장 크게 남은 문장은 단순했다. 좋은 AI 사용자는 명령을 잘 쓰는 사람이 아니라, AI와 함께 자신이 모르는 것을 빨리 발견하는 사람이다.

목차 1. 이 글의 핵심 2. 왜 중요한가 3. 내가 바로 적용할 방식 4. 실사용 테스트 5. 조심할 점 6. 실전 프롬프트 7. FAQ

이 글의 핵심

원문은 “지도는 영토가 아니다”라는 오래된 비유로 시작한다. 여기서 지도는 프롬프트, 스킬, 컨텍스트처럼 우리가 Claude에게 주는 설명이다. 영토는 실제 코드베이스, 제품의 제약, 사용자 반응, 조직의 맥락이다. 둘 사이의 차이가 바로 unknowns, 즉 미지다.

강한 모델일수록 이 차이가 더 중요해진다. 모델이 간단한 일만 하는 단계에서는 “정확히 시키기”가 중요했다. 하지만 장기 작업을 맡기면 모델은 작업 중 수많은 갈림길을 만난다. 사용자가 미지를 정리해두지 않으면, 에이전트는 그럴듯한 추측으로 빈칸을 채운다.

▲ GeekNews가 정리한 핵심 요약. 출처: GeekNews

내가 느낀 핵심: 이 글은 “프롬프트를 더 자세히 써라”가 아니다. 오히려 “내가 무엇을 모르는지 AI에게 먼저 찾게 하라”에 가깝다. 답을 받기 전에 질문의 지형을 그리는 습관을 만들라는 이야기다.

왜 중요한가

글에서 가장 설득력 있었던 부분은 unknown을 4가지로 나눈 대목이다. 이미 아는 것, 모른다는 사실은 아는 것, 알지만 말로 안 적은 것, 모르는 줄도 모르는 것. 실제로 AI 작업이 틀어지는 이유는 대부분 마지막 2가지에서 나온다.

▲ 원문과 GeekNews 요약을 바탕으로 재구성한 unknowns 4분면. 참고: 원문 Article

예를 들어 “대시보드를 예쁘게 만들어줘”라고 하면 AI는 업계 평균의 답을 낸다. 하지만 내가 원하는 것은 조용한 운영 콘솔일 수도 있고, 임원 보고용 한 장짜리 화면일 수도 있다. 이 차이는 내가 보기 전까지 말로 못 할 때가 많다. 그래서 글에서 말하는 프로토타입, 인터뷰, 레퍼런스가 중요해진다.

기존 방식	글이 제안하는 방식	효과
바로 구현 요청	먼저 blindspot pass 요청	질문 자체가 좋아진다
취향을 문장으로 설명	여러 프로토타입을 보고 반응	암묵지가 언어가 된다
결과만 확인	구현 중 노트와 사후 퀴즈	결과 이해도가 남는다

내가 바로 적용할 방식

이 글을 읽고 가장 써먹고 싶은 루틴은 5단계다. 작업을 시작하기 전에 미지를 찾고, 구현 전에 볼 수 있는 것을 만들고, 작업 중 판단을 기록하고, 끝난 뒤 설명과 퀴즈로 내 이해를 확인한다.

▲ “구현 전·중·후”를 학습 루프로 바꾼 도표. 참고: Know your unknowns 예제

특히 마음에 든 것은 implementation-notes.md 개념이다. AI가 작업 중 계획과 달라진 지점을 적어두면, 사용자는 “결과가 왜 이렇게 됐는지”를 뒤늦게 추적하지 않아도 된다. 실패하더라도 다음 시도는 더 똑똑해진다.

▲ 원문이 함께 제공한 예제 아티팩트 페이지. 출처: thariqs.github.io

내 작업 습관으로 옮기면

개인적으로는 이 방법이 공부와 제작을 동시에 바꾼다고 느꼈다. 보통 새로운 주제를 만나면 우리는 바로 요약을 요구하거나, 정답처럼 보이는 실행안을 달라고 한다. 그런데 이 글의 방식은 순서가 반대다. 먼저 내가 초보자인 지점, 언어가 없는 지점, 판단 기준이 흐릿한 지점을 드러낸다.

이렇게 하면 AI가 내 부족함을 덮어주는 도구가 아니라, 부족함을 보이게 하는 도구가 된다. 그 차이가 크다. 부족함이 보이면 질문이 좋아지고, 질문이 좋아지면 결과물이 좋아진다. 더 중요한 것은 결과물이 끝난 뒤에도 내 안에 기준이 남는다는 점이다.

상황	바꿔볼 질문
새 기술을 배울 때	“내가 초보자라서 놓칠 개념 지도를 먼저 그려줘.”
글이나 기획을 시작할 때	“독자가 궁금해할 반론과 빈칸을 먼저 찾아줘.”
개발 작업을 맡길 때	“구현 전에 결정해야 할 데이터, UX, 실패 조건을 정리해줘.”

결국 이 루틴은 “일을 맡기는 기술”보다 “내가 더 좋은 의사결정자가 되는 기술”에 가깝다. AI가 똑똑해질수록 사람에게 남는 가치는 더 정확한 방향 설정, 더 좋은 기준, 더 빠른 복기일 가능성이 높다. 그래서 이 글은 Fable 사용법이면서 동시에 앞으로 AI 시대에 일하는 태도에 대한 짧은 안내서처럼 읽혔다.

실사용 테스트

이 방법이 추상적인 조언에 그치지 않는지 보려고, 내가 거의 묻지 않던 주제인 브이로그·일상 영상 제작으로 테스트했다. 질문은 3단계로 나눴다. 먼저 blindspot pass로 놓칠 리스크를 꺼내고, 그다음 유튜브 대본으로 구조화하고, 마지막에 CapCut 편집 패키지로 바꿨다.

단계	질문 방식	나온 결과
1	바로 기획하지 말고 blindspot부터 찾기	촬영·기록·건강·편집·블로그·유튜브 흐름의 빈칸 정리
2	조건을 고정하고 8~10분 대본 요청	8개 장면, 내레이션, 자막, B-roll, Shorts 후보 생성
3	대본을 편집 도구 기준 산출물로 변환	CapCut 타임라인, 파일명 규칙, BGM, 썸네일, 재활용 구조 생성

▲ 첫 질문은 “기획안을 바로 달라”가 아니라 내가 놓칠 가능성이 큰 미지부터 찾아달라는 형태로 잡았다.

▲ 답변은 촬영 컷, 기록 항목, 건강상 주의점, 편집 포인트로 나뉘며 Day 1 비포 컷과 실패 컷처럼 나중에야 깨닫기 쉬운 항목을 먼저 건드린다.

▲ 두 번째 질문에서는 8~10분 영상, 톤, 구조, 촬영 컷, 내레이션, 자막, B-roll, Shorts 구간까지 조건으로 고정했다.

▲ 세 번째 질문은 편집자가 바로 작업할 수 있게 타임라인 표, 파일명 규칙, B-roll, 자막, BGM, Shorts, 썸네일 문구까지 요구했다.

▲ 결과물은 단순 조언이 아니라 시간대별 컷, 원본 파일명, 자막, 편집 지시가 들어간 작업 문서로 변환됐다.

써보니 핵심은 “답변 품질”보다 “질문이 다음 산출물로 이어지는가”였다. 첫 질문에서 실패 컷, Day 1 비포 컷, 하루 기록 시간 제한 같은 blindspot이 잡히니, 이후 대본과 편집표도 훨씬 현실적인 방향으로 흘렀다. 내 경우 웹개발·요리·운동·다이어트를 취미 콘텐츠로 묶을 때, 개발자다운 데이터 기록과 영상 제작 루틴을 동시에 설계하는 쪽이 가장 잘 맞았다.

조심할 점

다만 이 방법을 “AI가 틀리면 내가 미지를 덜 줬기 때문”으로만 받아들이면 위험하다. 모델은 여전히 사실을 잘못 읽고, 코드 경로를 오해하고, 과한 일반론을 적용할 수 있다. 그래서 미지 찾기와 함께 검증 기준도 있어야 한다.

내 결론: 좋은 흐름은 “AI에게 더 많이 맡기기”가 아니라 “AI가 추측하는 지점을 더 빨리 보이게 만들기”다. 강한 모델을 쓸수록 자유도는 커지고, 그만큼 경계·출처·검증도 더 중요해진다.

독자로서 좋았던 점은 글이 추상적인 원칙에서 멈추지 않는다는 것이다. blindspot pass, 인터뷰, 프로토타입, 구현 노트, 퀴즈처럼 바로 실행할 이름을 붙여준다. 이름이 붙으면 습관으로 옮기기 쉽다. “다음에는 더 잘 물어봐야지”가 아니라 “시작 전에 blindspot pass부터 하자”가 된다.

아쉬운 점도 있다. 글은 강한 모델과 숙련된 사용자 사이의 협업을 전제로 한다. 초보자는 AI가 찾아준 unknown이 정말 중요한지 판단하기 어려울 수 있다. 그래서 처음에는 작은 작업에서 써보는 편이 좋다. 짧은 글, 작은 기능, 간단한 리서치처럼 실패 비용이 낮은 곳에서 루프를 익히면, 나중에 큰 작업에서도 부담 없이 적용할 수 있다.

▲ Fable 5의 장기 작업, 검증, 경계 설정을 다루는 공식 문서. 출처: Claude Platform Docs

실전 프롬프트

이 글을 읽은 뒤 가장 먼저 저장해둘 프롬프트는 아래 3개다. 핵심은 “바로 답하지 말라”는 문장을 붙이는 것이다. 그 한 줄이 AI를 실행자에서 사고 파트너로 바꾼다.

▲ 후기 관점에서 정리한 실전 프롬프트 3종. 참고: GeekNews 요약

바로 답하지 말고, 먼저 blindspot pass를 해줘.
내가 이 문제에서 모를 가능성이 큰 unknown unknowns를 찾아주고,
더 좋은 질문을 하기 위해 내가 답해야 할 질문을 정리해줘.

모호한 부분을 한 번에 하나씩 인터뷰해줘.
내 답이 아키텍처, UX, 데이터 모델, 비용을 바꿀 질문을 우선해줘.

작업 중 implementation-notes.md를 유지해줘.
계획과 달라진 지점, 발견한 제약, 보수적으로 선택한 이유를 남기고 계속 진행해줘.

후기로 정리하면, 이 글은 프롬프트 기술 글처럼 보이지만 사실은 메타인지 글이다. 더 좋은 답을 얻는 법이 아니라, 내가 몰랐던 것을 발견하는 속도를 높이는 법이다. 그리고 이 능력은 AI 도구가 바뀌어도 오래 남을 가능성이 크다. 앞으로의 차이는 “누가 AI를 더 많이 쓰느냐”보다 “누가 AI와 함께 더 빨리 자기 빈칸을 발견하느냐”에서 날 것 같다. 작은 작업부터 이 루틴을 반복하면, 결과물보다 먼저 질문하는 감각이 자란다. 이 감각이 쌓이면 협업의 질도 같이 올라간다.

출처

• GeekNews: Fable 필드 가이드 요약
• Thariq: A Field Guide to Fable: Finding Your Unknowns
• Know your unknowns 예제 아티팩트
• Claude Platform Docs: Prompting Claude Fable 5

FAQ

Q1. 이 글은 결국 프롬프트 엔지니어링 이야기인가요?+

반은 맞고 반은 다릅니다. 문장 기술보다 중요한 것은 내가 모르는 전제, 제약, 취향, 리스크를 AI와 함께 찾아내는 과정입니다.

Q2. blindspot pass는 언제 쓰면 좋나요?+

낯선 코드베이스, 처음 해보는 디자인, 새 도메인 조사처럼 질문 자체를 잘 모를 때 가장 좋습니다. 바로 실행하기 전에 쓰면 시행착오 비용을 줄입니다.

Q3. 너무 많이 물어보면 작업이 느려지지 않나요?+

작은 작업에서는 느려질 수 있습니다. 하지만 되돌리기 비싼 작업에서는 초반 5분의 미지 정리가 후반 2시간의 수정 비용을 줄일 수 있습니다.

Q4. 구현 노트는 꼭 파일로 남겨야 하나요?+

파일이 가장 좋지만, 대화 중간 요약도 가능합니다. 중요한 것은 “왜 계획이 바뀌었는지”와 “다음 시도에 반영할 교훈”이 사라지지 않는 것입니다.

Q5. 이 방법은 Claude에만 해당하나요?+

아닙니다. 글은 Fable을 중심으로 하지만, 미지 찾기·프로토타입·검증 루프는 Codex, ChatGPT, 다른 에이전트형 AI에도 그대로 적용할 수 있습니다.