👩🏻‍💻 Claude Fable 5 x Agentic Coding

Unknowns......

제가 이 아티클을 보고 되게 좋았어요. 좋은 가이드..

왜냐면 Fable 5로 대규모 작업을 할 때, 왜 계획만으로는 부족한지와 실제로 unknowns를 어떻게 빠르게 발견하는지에 대한 학습에 대한 얘기도 같이 있었거든요.

어떤게 우리의 병목으로 작용하고 있을까.

↓

💭 왜 Unknowns가 중요한 걸까요?

프롬프트, 스킬, 컨텍스트 = 이게 바로 Claude에게 주는 지도

Unknowns = 그런데 실제 작업이 일어나는 코드베이스와 현실의 제약

결국 Fable 결과물의 품질은 내가 unknowns를 얼마나 잘 찾아내고 명확히 하는지에 따라 결정됩니다. 저도 많이 느껴요.

중요한건 미리 계획만 세운다고 끝나지 않는다는 점. 구현 중간에 발견되는 unknown도 있고, 때로는 그 unknown 자체가 "사실은 다른 방향으로 풀어야 함!" 이런 신호일 수도 있으니까요.

↓

🗺️ 네 가지 Unknowns 유형

The Rumsfeld Matrix.. 문제를 이렇게 네 가지로 정리해요.

• Known Knowns:
  이미 프롬프트에 적힌 것들. 내가 원하는 게 무엇인지 명확히 전달한 부분.

• Known Unknowns:
  아직 모르지만, 모른다는 사실은 알고 있는 것들.

• Unknown Knowns:
  너무 당연해서 적지 않았지만, 보면 바로 알아차릴 수 있는 것들.

• Unknown Unknowns:
  아예 생각조차 못 했던 것들. 얼마나 좋은 결과물이 가능한지조차 모르는 상태.

에이전트 코딩을 잘하는 사람들은 이 unknowns를 상대적으로 적게 가지고 있어요.

동시에 unknowns가 존재한다고 가정하고, 그것을 줄이는 과정을 반복하는 게 바로 에이전트 코딩의 진짜 스킬..

↓

💡 Pre-implementation 단계에서 unknowns 찾기

구현 전에 unknowns를 미리 드러내는 몇 가지 패턴을 얘기합니다.

1. Blind Spot Pass:

"blindspot pass"와 "unknown unknowns"라는 표현을 그대로 써서, 내가 모르는 부분을 Claude가 먼저 찾아주도록 요청하는 방법. 새로운 코드베이스 영역이나 익숙하지 않은 작업을 시작할 때 특히 유용해요.

2. Brainstorm & Prototype:

Unknown Knowns가 많을 때, 여러 방향의 프로토타입을 HTML로 만들어 반응을 보는 방식. 시각적 판단이 필요한 경우 특히 효과적이에요.

3. Interview:

충분히 브레인스토밍을 한 뒤, Claude에게 한 번에 한 질문씩 물어보며 모호함들을 파헤치는 방법. "내 답변이 아키텍처를 바꿀 만한 질문"을 우선순위로 두라고 지시하면 좋아요.

4. Reference:

설명하기 어려운 것은 소스 코드나 실제 모듈을 직접 가리키는 게 가장 정확해요. 다른 언어여도 상관없고, 웹사이트 모듈을 가리키는 것만으로도 Claude가 마크업과 구조를 이해할 수 있어요.

5. Implementation Plan:

구현 계획을 세울 때, 특히 변경 가능성이 높은 부분(데이터 모델, 타입 인터페이스, UX 흐름)을 앞에 배치하고, 기계적인 리팩토링은 뒤로 미루는 방식.

↓

♾️ During & Post implementation

구현 중에도 unknown unknowns는 계속 나타나요.

그래서 Claude에게 임시 implementation-notes.md 파일을 유지하게 해서, 계획에서 벗어난 결정이나 edge case를 기록하게 하는 팁도 공유하고 있어요.

작업이 끝난 후에는..

• Pitch와 explainer 아티팩트를 만들어 팀의 buy-in을 빠르게 얻기

• 변경 사항에 대해 Claude가 quiz를 내게 해서, 내가 정말 이해했는지 확인한 뒤 머지하기

이 모든 과정이 Fable 런치 비디오 편집 같은 새로운 도메인 작업에서도 실제로 어떻게 쓰였는지 구체적인 사례도 함께 보여주고 있네요. 그것도 멋졌어요.

💭

계획만으로는 부족하고, 구현 중에도, 구현 후에도 계속 unknowns를 찾아가는 반복적인 과정이라는 관점이 좋네요.

강력한 모델일수록, 내가 무엇을 모르는지.. 이걸 저렴하게 발견하는 과정이 가장 중요해집니다.

모든 brainstorm, interview, prototype, reference, quiz는..

나중에 토큰 많이 들여 비싸게 고치는 것보다 미리 unknowns를 발견하는 저렴한 방법이겠죠.

결국엔 습관, 실행..