원문: A Field Guide to Fable: Finding Your Unknowns
참고: Know your unknowns — examples
1) 문제는 더 긴 prompt가 아니다
Thariq Shihipar의 글은 “AI에게 일을 잘 시키는 법"처럼 보이지만, 핵심은 단순한 prompt 기술이 아닙니다. 더 정확히는 내가 무엇을 모르는지 AI와 함께 발견하는 법에 가깝습니다.
모델이 약할 때는 결과가 나쁜 이유를 모델 한계로 돌리기 쉬웠습니다. 하지만 Fable처럼 강한 모델에서는 상황이 달라집니다. 모델이 많은 일을 할 수 있기 때문에, 사용자가 남긴 빈칸도 더 멀리 증폭됩니다. 불분명한 요구, 말하지 않은 취향, 코드베이스의 역사적 제약, 실제 사용자 흐름이 모두 결과에 영향을 줍니다.
그래서 좋은 결과의 핵심 질문은 “어떻게 더 자세히 지시할까?“가 아니라 “AI가 어디에서 내 의도를 추측하게 될까?” 입니다.
2) 지도는 영토가 아니다
글의 중심 비유는 간단합니다.
- 지도: 내가 AI에게 주는 prompt, skill, context, 문서
- 영토: 실제 작업이 벌어지는 코드베이스, 제품, 사용자, 운영 환경, 조직의 암묵지
- unknowns: 지도와 영토 사이의 차이
AI는 지도를 보고 영토를 걸어갑니다. 그런데 지도에 없는 지형을 만나면 멈추지 않고 추측합니다. 대부분의 agent 실패는 여기서 생깁니다. 모델이 멍청해서가 아니라, 추측해야 하는 지점이 너무 많았기 때문입니다.
큰 작업일수록 이 차이는 커집니다. 작은 copy 수정은 빈칸이 적지만, 인증 모듈 교체, 제품 flow 재설계, 긴 영상 편집, 복잡한 refactor는 AI가 수십 번의 암묵적 결정을 내려야 합니다.
3) unknowns를 네 칸으로 나누기
Thariq는 문제를 네 가지로 나눕니다.
| 구분 | 의미 | 예시 |
|---|---|---|
| Known knowns | 내가 알고 있고 AI에게 말한 것 | “새 인증 provider를 추가해줘” |
| Known unknowns | 내가 아직 모른다는 사실을 아는 것 | “데이터 모델은 아직 확신이 없어” |
| Unknown knowns | 나는 알지만 말하지 않은 것 | “이 UI는 우리 제품답지 않아” |
| Unknown unknowns | 내가 모른다는 사실도 모르는 것 | “이 모듈에는 오래된 edge case가 있다” |
가장 다루기 쉬운 것은 known knowns입니다. 이미 prompt 안에 들어 있기 때문입니다. known unknowns도 비교적 낫습니다. “여기는 아직 모른다"고 말할 수 있으니 AI에게 탐색을 맡길 수 있습니다.
문제는 unknown knowns와 unknown unknowns입니다. 사용자는 자기 취향, 팀 관습, 코드 냄새, 제품 감각을 너무 당연하게 여겨 적지 않습니다. 혹은 어떤 질문을 해야 하는지조차 모릅니다. AI는 그 부분을 모른 채 합리적인 기본값으로 채웁니다. 그 기본값이 틀리면 결과는 “그럴듯하지만 아닌 것"이 됩니다.
4) 바로 구현하지 말고 먼저 빈칸을 찾기
글에서 가장 실용적인 도구는 blindspot pass입니다. 낯선 코드 모듈이나 익숙하지 않은 작업을 시작할 때, AI에게 바로 구현을 맡기지 않고 먼저 이렇게 요청하는 방식입니다.
지금 내가 모를 가능성이 큰 unknown unknowns를 찾아주고, 더 나은 지시문을 쓰려면 어떤 맥락을 보충해야 하는지 알려줘.
이 한 단계는 구현보다 싸고, 실패한 구현을 되돌리는 것보다 훨씬 싸습니다. 특히 다음 상황에서 유용합니다.
- 낯선 코드베이스 영역에 들어갈 때
- 디자인, 영상, 데이터 분석처럼 “좋은 결과"의 기준을 내가 잘 모를 때
- 팀 내부 관습이나 과거 결정이 결과에 영향을 줄 때
- 문제 자체를 다른 방식으로 풀어야 할 가능성이 있을 때
AI에게 물어볼 일은 “정답을 만들어줘"만이 아닙니다. “내가 빠뜨린 질문을 찾아줘"가 먼저일 때가 많습니다.
5) 구현 전, 중, 후에 계속 발견하기
Thariq가 강조하는 또 하나의 포인트는 planning만으로 충분하지 않다는 점입니다. unknowns는 구현 전에만 있는 것이 아닙니다.
구현 전에는 blindspot pass, brainstorm, prototype, interview, reference가 효과적입니다. 말로 설명하기 어려운 취향이나 판단 기준은 여러 시안을 보면서 더 잘 드러납니다. “이건 아니고, 저쪽이 더 가깝다"는 반응 자체가 unknown knowns를 밖으로 꺼냅니다.
구현 중에는 AI가 계획에서 벗어난 지점을 기록하게 해야 합니다. 실제 파일을 읽고 나서 계획과 코드가 맞지 않는 경우, 그 차이를 그냥 덮고 가면 다음 시도도 같은 곳에서 흔들립니다. 짧은 implementation notes만 남겨도 두 번째 시도는 훨씬 좋아집니다.
구현 후에는 pitch나 quiz가 도움이 됩니다. AI에게 “왜 이렇게 만들었는지 이해관계자에게 설명해봐” 또는 “내가 merge 전에 확인해야 할 질문을 내봐"라고 시키면, 구현 과정에서 숨어 있던 가정이 다시 표면으로 올라옵니다.
6) agentic work의 핵심 능력
이 글이 중요한 이유는 AI 활용을 “prompt 잘 쓰기"보다 넓게 보기 때문입니다. 좋은 agentic work는 명령문 작성이 아니라 문제 공간을 함께 정렬하는 과정입니다.
강한 모델은 단순 실행자가 아니라 탐색 파트너가 될 수 있습니다. 코드베이스를 빠르게 읽고, 분야 지식을 끌어오고, 대안을 만들고, 사용자가 몰랐던 질문을 제안할 수 있습니다. 다만 그러려면 처음부터 “내가 어느 정도 알고 있고, 무엇을 모를 수 있으며, 어떤 종류의 판단을 함께 해주길 원하는지"를 알려줘야 합니다.
결국 고급 사용자는 AI에게 더 많은 일을 시키는 사람이 아닙니다. AI가 추측해야 하는 지점을 줄이고, 추측이 필요한 곳에서는 더 나은 방식으로 탐색하게 만드는 사람입니다.
결론 및 시사점
한 줄 결론: Fable급 모델을 잘 쓰는 능력은 완벽한 지시문을 한 번에 쓰는 능력이 아니라, 작업 전·중·후에 unknowns를 계속 발견하고 줄이는 능력이다.
실무에서는 다음 한 문장부터 적용하면 됩니다.
바로 구현하지 말고, 먼저 이 작업의 blindspot pass를 해줘. 내가 모를 가능성이 큰 unknown unknowns와 더 나은 지시문에 필요한 맥락을 찾아줘.
AI가 강해질수록 결과의 병목은 점점 사람 쪽으로 이동합니다. 하지만 그것이 부담만 뜻하지는 않습니다. 오히려 AI에게 “내가 모르는 것을 찾는 일"까지 맡길 수 있다면, 더 좋은 결과는 더 긴 지시문이 아니라 더 짧고 빠른 탐색 루프에서 나옵니다.