내가 Fable을 프롬프트하는 법

https://simplemarkdowneditor.com/pub/IbaCrTjLJT?key=uQOQ2NPO3TTUSXyYDjyLf

이 링크를 여러분의 에이전트에게 보내보세요. 프롬프트 작성을 도와줄 겁니다!

Fable로 만든 걸 보여줄 때마다 똑같은 질문을 받습니다. "저는 이런 결과가 안 나오던데요." "어떻게 하신 거예요?" "이게 진짜일 리가 없어요."

그리고 다들 하나하나가 엄청나게 복잡한 프롬프트에서 나왔거나, 실제보다 훨씬 많은 공이 들었을 거라고 짐작합니다. 보통은 그 반대입니다. 데모는 보기보다 단순합니다. 저는 그저 대부분의 사람들과 다른 방식으로 모델을 쓰고 있을 뿐입니다.

Fable은 진짜 차세대 모델입니다. 지금 모델들에게 하듯 프롬프트하면 지금 모델 수준의 결과가 나옵니다. 프롬프트하는 방식, 그리고 이 모델이 감당할 수 있는 일의 범위에 대한 생각을 바꾸면, 그때 비로소 문이 열립니다.

제가 실제로 쓰는 방법은 이렇습니다.

단계가 아니라 목표를 주세요

가장 큰 변화는, 일하는 방법을 일일이 설명하는 걸 그만뒀다는 겁니다. 예전 모델들은 어떻게 할지 지정해주지 않으면 엉뚱한 길로 새기 일쑤였습니다. Fable은 정반대입니다. 여지를 많이 줄수록 더 잘합니다.

그래서 저는 크고 광범위하고 덜 구체적인 일을 통째로 맡깁니다. 신뢰하는 뛰어난 사람에게 목표만 건네고 최선의 길은 알아서 찾게 하는 것처럼요. 다만 Fable은 그 "어떻게"를 찾아내는 데 저보다 나을 때가 많습니다. 제가 지시하는 단계 하나하나는 결국 모델의 판단을 제 판단으로 덮어쓰는 것인데, 대개는 제 판단이 더 나쁩니다.

세부 사항을 직접 통제하는 데 익숙하다면 처음엔 이게 위험하게 느껴집니다. 이걸 안전하게 만들어주는 게 다음 이야기입니다.

믿고 맡길 수 있도록 기본 규칙을 정하세요

덜 구체적인 목표가 통하려면, 넘어서는 안 되는 규칙 몇 개로 울타리를 쳐줘야 합니다. 기본 규칙(house rules)이란 Fable이 목표에 어떤 식으로 도달하든 항상 지켜지길 바라는 몇 가지를 말합니다.

예를 들어 제가 에이전트를 만들 때, 모델들은 과잉 설계를 무척 좋아합니다. 특정 케이스 하나를 잡겠다고 정규식 필터부터 꺼내 드는데, 제가 정말 원하는 건 원하는 동작을 프롬프트로 설명하고 모델이 알아서 처리하게 하는 겁니다. 그래서 제 상시 규칙 중 하나는 대략 이렇습니다. 특수 케이스를 하드코딩하지 말 것, 원하는 바를 에이전트의 시스템 프롬프트에 설명하고 에이전트가 추론하게 할 것.

여기에 안전장치를 하나 더 두자면, Fable이 항상 서브에이전트 하나에게 딱 한 가지 일만 맡기게 할 수 있습니다. 무엇이든 푸시하기 전에 작업물이 기본 규칙에 어긋나지 않는지 검사하는 일이죠. 이렇게 하면 Fable이 목표를 향해 마음껏 내달리게 두면서도, 여러분이 중요하게 여기는 것들을 깨뜨린 채 내보내는 일은 없다고 안심할 수 있습니다.

"완료"의 기준을 제대로 세워주세요

Fable에게 "고품질"로 만들어달라고 하면, 모델은 자기 나름의 "이 정도면 됐다" 수준에서 멈추는데, 그 수준은 대개 여러분 기대보다 낮습니다. 그래서 저는 형용사를 쓰지 않습니다. 스스로 검사해볼 수 있는 기준을 주고, 그 기준을 빡빡하게 잡습니다.

테스트를 직접 쓸 때도 있습니다… "모르는 사람이 우리 렌더링과 실제 사진을 구분하지 못한다"처럼 구체적인 걸로요. 어떤 때는 원하는 걸 어떻게 측정해야 할지조차 모르는데, 그럴 땐 그 문제까지 Fable에게 넘깁니다.

예를 들어 한 친구가 컴포넌트 라이브러리를 클론하려다 전혀 진척이 없었습니다. 문제는 두 가지였습니다. 첫째, shadcn 위에서 shadcn 기반으로 컴포넌트를 클론하려 하고 있어서, Fable이 컴포넌트를 만드는 데 집중하지 못하고 shadcn의 온갖 관례와 씨름하고 있었습니다. 둘째, 언제 끝난 건지 말할 방법이 없었습니다. 그냥 "이거 클론해줘"라고만 하고 있었거든요.

그래서 두 가지를 했습니다. 먼저 shadcn을 버리고 맨바닥에서 시작했습니다. 컴포넌트 라이브러리는 아무것도 없는 상태에서도 얼마든지 만들 수 있고, 기존 코드는 짐만 될 뿐이었으니까요. 그다음, "원본과 일치하는가"를 어떻게 측정할지 둘 다 몰랐기에 그걸 Fable에게 알아내라고 했습니다. Fable은 실제 컴포넌트가 쓰이는 모습을 화면 녹화로 뜨고, 모든 요소가 어디서 어떻게 움직이는지 히트맵으로 바꾼 뒤, 자기 버전이 그와 일치할 때까지 계속 작업했습니다. 그렇게 하라고 알려준 적은 없습니다. "완료"가 무슨 뜻인지 알려주고, 측정 잣대는 스스로 발명하게 했을 뿐입니다.

여기서 제가 절대 어기지 않는 규칙이 하나 있습니다. 무언가를 만든 쪽이 그것을 채점하게 두지 않는 것입니다('빌드' 에이전트는 편향되기 쉽고, "내가 왜 이런 결정을 했는가"라는 자기 이력이 통째로 있어서 그걸로 일을 다 했다고 정당화할 수 있습니다). 저는 항상 새 컨텍스트 윈도우를 가진 별도의 Fable 서브에이전트를 띄워서, 실제 결과물(실제 픽셀, 실제로 돌아가는 앱 등)을 직접 보게 하고, 그것이 기준을 통과하지 못한다는 걸 증명해보라고 시킵니다.

기준을 통과할 때까지 반복시키세요 (특히 창작 작업이라면)

기준이 생기면, 저는 Fable을 그 기준에 맞춰 루프에 올려놓고 그냥 둡니다. 만들고, 스스로 검사하고, 가장 큰 격차를 찾아 메우고, 다시 시작하고… 몇 시간, 때로는 며칠씩요. 저는 이때 /loop를 입에 달고 사는데, 특히 창작 작업에서 그렇습니다. 실제로 도달할 때까지 계속 견줘볼 구체적인 무언가가 늘 있는 분야니까요.

이 루프의 핵심은 Fable이 스스로 끝났다고 결정할 수 없다는 데 있습니다. 다음 격차는 언제나 있습니다. 제가 끝났다고 말할 때, 아니면 정말로 더 고칠 게 남아 있지 않을 때(제대로 세팅했다면 드문 일입니다) 멈춥니다.

긴 작업마다 쓰는 요령이 하나 있습니다. Fable이 진행 상황을 Simple Markdown Editor에 올리게 하는 겁니다(바로 이 사이트입니다! 이미지, 동영상, HTML 등 무엇이든 지원하는 마크다운 에디터이고, 처음부터 에이전트 우선으로 만들어졌습니다). Fable은 일하면서 스크린샷이든 메모든 현재 상태를 보여주는 것들로 문서를 계속 갱신합니다. 그러면 저는 휴대폰을 슬쩍 보는 것만으로 어디까지 왔는지 정확히 알 수 있고, 에이전트의 방향을 조정하고 싶을 때 언제든 코멘트를 달 수 있습니다.

이 에디터를 쓰는 또 다른 방식도 있습니다. 여러 Fable을 동시에 돌릴 때 공유 작업 공간이 되어줍니다. Simple Markdown Editor에는 트렐로식 보드와 슬랙 같은 채팅 컴포넌트가 내장돼 있어서, 에이전트들이 서로에게 작업을 올리고, 가져가고, 질문하고, 충돌을 알릴 수 있습니다. 에이전트 팀이 같은 코드베이스에서 일할 때는 그 문서 하나가 조율 계층이 되고, 저는 그 대화 전체를 지켜볼 수도, 직접 끼어들 수도 있습니다.

이미 해놓은 것 위에 쌓게 하세요

Fable은 여러분이 이미 해놓은 게 많을수록 그 일을 더 잘하게 됩니다. 과거의 작업이 새 작업의 연료가 되는 셈이죠.

Fable이 나왔을 때 제가 처음으로 제대로 만든 건 실사에 가까운 3D 숲이었습니다. 그 프롬프트는 이후 어떤 것보다도 공들여 썼습니다. 참조점이 전혀 없었으니까요… 원하는 품질을 보여줄 예시도 없었고, 거기 도달할 방법도 아직 몰랐습니다. 첫 프롬프트를 제대로 잡는 데는 정말 손이 많이 갔습니다.

하지만 훌륭한 3D 장면이 하나 생기고 나니 그다음은 전부 쉬워졌습니다. 호그와트 데모를 만들 때는 Fable에게 숲을 가리키기만 하면 됐습니다. 여기 코드가 있고, 여기 품질 기준이 있으니, 이만큼 맞추고 그 이상으로 가라. 아무것도 다시 설명할 필요가 없었습니다.

코드 재사용에서 그치지 않습니다. Fable은 제 예전 Claude Code 세션의 트레이스를 읽을 수 있습니다… 숲을 만들면서 실제로 뭘 시도했는지, 뭐가 통했고 뭐가 안 통했는지를요. 그래서 "장면의 오브젝트마다 별도 서브에이전트를 써라"라고 말하는 대신 "숲 트레이스를 읽고 뭐가 통했는지 배워라"라고만 하면 됩니다. 접근법은 알아서 익힙니다. 호그와트가 숲보다 훨씬 빨리 완성된 건 대부분 그 덕분입니다.

길을 비켜주세요

Fable이 멈춰서 뭔가를 물어봐야 할 때마다 시간을 잃는 겁니다. 그래서 저는 장애물을 미리 치워둡니다. 예를 들어 돈이 드는 실제 서비스에 연결할 때는, 쓸 때마다 허락을 구하게 하는 대신 예산을 줍니다. 키와 자격 증명이 어디 있는지 알려줍니다. 그리고 판단은 스스로 내리고, 정말 막혔거나 저만 결정할 수 있는 문제에 부딪혔을 때만 저를 찾아오라고 글로 못 박아둡니다.

단 하나의 예외는 계획 수립입니다(그것도 아주 크고 파급이 큰 일에 한해서요). 정말 큰 빌드라면 코드를 한 줄이라도 쓰기 전에 계획부터 받고, 확신이 없는 부분은 전부 미리 저에게 물어보게 합니다. 계획이 확정되면 그다음엔 멈추지 않고 달립니다.

제가 돌리는 두 가지 방식

위 내용은 기능을 출시하든 세계를 만들든(다른 어떤 창작이든) 똑같이 적용됩니다. 달라지는 건 그 주변의 세팅입니다.

엔지니어링에서는 팀을 돌립니다. 여러 Fable 세션이 동시에 일하면서 어디서든 작업을 가져옵니다… 목록에서든, Linear 보드에서든, Simple Markdown Editor의 트렐로식 보드에서든, 아니면 제가 그냥 나눠주든요. 각 세션은 자기 작업을 마치고, 서브에이전트로 자기 작업물을 몇 겹으로 검증한 뒤, 앞서 말한 증거를 첨부해 PR을 엽니다. 그리고 Fable 하나가 더 붙어 통합만 전담합니다. PR을 머지하고, 전부 돌려보고, 실제 사용자처럼 테스트하고, 전체가 계속 초록불이게 유지합니다. 두 기능이 겹칠 때는 한 Fable에게, 다른 쪽이 만들어지는 동안 그쪽 트레이스를 지켜보며 호환성을 유지하라고 시킵니다… 병렬로 일하고 있으니 문서의 채팅에서 서로 조율할 수 있고… 한쪽이 다른 쪽을 주시하다가 충돌이 생기는 대로 알리고, 완성되는 대로 통합합니다.

창작 작업에서는 추진력과 디테일에 기댑니다. 루프도 같고 빡빡한 기준도 같지만, 보통은 Fable 하나에게 전부 시키는 대신 서브에이전트를 여럿 펼쳐서 개별 조각들을 완성시킵니다… 예컨대 숲의 나무 종류마다 서브에이전트 하나가 붙어 다듬는 식이죠. 완전히 별개인 시도 몇 개를 동시에 돌린 다음 제일 나은 걸 남기고, 통했던 것들을 다음 라운드로 가져가기도 합니다.

이 방식들은 얼마든지 섞어 써도 됩니다. 뭘 만드느냐에 달렸습니다.

ultracode에 돈을 써야 할 때

ultracode라는 훨씬 무거운 모드가 있는데, 비용이 상당히 더 듭니다. 저는 거의 안 씁니다. 충분히 야심 찬 목표에 잘 짜인 루프면 그것 없이도 원하는 데까지 갈 수 있거든요.

이 모드가 제값을 하는 곳은 기반 작업입니다. 앞으로 몇 달을 붙들고 있을 새 시스템을 맨바닥부터 만들 때(예컨대 비즈니스나 코드베이스의 핵심이 될 무언가), 저는 첫날부터 기반이 제대로이길 원합니다. shadcn을 버린 것과 같은 이유입니다. 기반이 좋으면 그 위에 쌓는 모든 게 쉬워지고, 기반이 나쁘면 모든 게 영원히 어려워집니다. 그런 종류의 일에는, 그리고 사실상 그런 일에만, 추가 비용이 아깝지 않습니다.

한 가지 더

이걸 다 머리에 담아두기 벅차다면, 그럴 필요 없습니다. 이 글 전체를 여러분의 Fable에게 건네고, 앞으로 프롬프트 쓰는 걸 도와달라고 하세요. 알아서 잘 써먹을 겁니다.

복잡한 건 하나도 없습니다. 누구나 쓰는 그 모델 그대로입니다. 제 결과물이 달라 보이는 건, 제가 떠먹여주지 않고, 말로 빠져나갈 수 없는 기준을 들이대고, 이미 만들어놓은 모든 것 위에 쌓게 하기 때문입니다. 거기서 시작하세요.