Claude Fable 5를 더 잘 쓰는 법: Thariq의 조언과 코딩 전략

안녕하세요, 개발팀 피터입니다.

요즘 Claude Fable 5가 핫한데요. 이 모델을 이용하는 데 도움이 되는 내용을 Claude Code 기술 스태프인 Thariq Shihipar가 공유해, 해당 내용을 번역해 소개하려고 합니다.

원본 : https://x.com/trq212/article/2073100352921215386

글쓴이 소개

Thariq Shihipar는 Anthropic에서 Claude Code를 만드는 팀의 엔지니어입니다. Claude를 그냥 써본 사람이 아니라, 도구를 직접 만드는 내부자예요. 그래서 “이렇게 쓰면 좋더라”는 더 신뢰성이 느껴집니다.

그가 소개해주는 내용을 쉽게 풀어서 작성 했습니다.

핵심 한 줄: “내가 머릿속에 그린 그림”과 “실제 코드”는 다르다

지도는 영토가 아니다.

그가 계속 강조하는 말입니다. 쉽게 말하면 이렇습니다.

내가 Claude에게 주는 프롬프트, 설명, 컨텍스트는 지도입니다. 내가 그린 계획서죠. 그런데 실제 코드베이스, 현실의 제약, 진짜 하고 싶었던 의도는 영토입니다. 실제 땅이죠.

문제는 이 둘이 항상 어긋난다는 겁니다. 내 계획서, 즉 지도에 안 적힌 부분이 나오면 Claude는 “이 사람이 뭘 원하는 거지?” 하고 알아서 추측해서 진행합니다. 작업이 클수록 이렇게 추측해야 하는 지점이 많아지고요.

그가 던지는 가장 중요한 얘기는 이겁니다.

예전 모델은 시켜도 제대로 못 해서 문제였는데, Fable 5는 실력이 너무 좋아져서 이제 병목이 모델이 아니라 “내가 뭘 원하는지 제대로 설명 못 하는 것”이 됐다.

즉, 못 하는 게 아니라 내가 설명을 못 해서 결과가 어긋나는 시대가 됐다는 거죠.

내가 모르는 걸 4가지로 나눠보자

그는 Claude에게 일을 맡기기 전에 “내가 뭘 알고 뭘 모르는지”를 4칸으로 나눠봅니다.

잘하는 개발자들은 이 “모르는” 칸이 애초에 작습니다. 원하는 걸 세부까지 알고 있거든요. 하지만 그들도 미지가 있을 거라고 항상 가정합니다.

그가 하는 말은, 이 미지를 줄이고 대비하는 게 곧 실력이고, 이건 Claude랑 같이 하면서 늘릴 수 있다는 겁니다.

너무 자세해도, 너무 대충 해도 망한다

Claude에게 지시하는 건 줄타기입니다.

• 너무 자세하게 시키면 → 방향을 트는 게 나은 상황에서도 Claude가 내 지시를 고집합니다.

• 너무 대충 시키면 → Claude가 “보통 이렇게들 하니까” 하고 내 상황엔 안 맞는 일반적인 방식대로 해버립니다.

그래서 그가 하는 말이 “내가 뭘 모르는지 파악 안 하면 양쪽 다 망한다”입니다.

다행히 Claude는 코드베이스랑 인터넷을 엄청 빠르게 뒤질 수 있고 웬만한 주제는 나보다 많이 알아서, 내가 모르는 걸 찾는 걸 도와줄 수 있습니다. 이때 제일 중요한 건 Claude에게 “나는 지금 여기까지 알고, 이 부분은 초보다” 하고 내 출발점을 솔직하게 알려주는 거예요. 동료한테 물어보듯이요.

코딩 시작 전에 하는 것들

1. 사각지대 찾기

낯선 영역에 들어갈 땐 뭘 모르는지조차 모릅니다. 그럴 때 Claude에게 대놓고 “내 사각지대 좀 찾아줘”라고 시킵니다.

예: “새 인증 기능을 붙여야 하는데 이 코드베이스의 인증 쪽을 하나도 몰라요. 내가 뭘 놓치고 있는지 찾아서 알려주고, 내가 질문을 더 잘하게 도와줘.”

2. 브레인스토밍 + 대충 만들어보기

“보면 아는데 말로는 설명 못 하는” 것들, 특히 디자인은 코딩 다 하고 나서 “이거 아닌데” 하면 고치기가 비쌉니다. 그래서 백엔드 연결도 안 하고 가짜 데이터로 화면만 툭 만들어서 미리 반응을 봅니다.

예: “이 데이터로 대시보드를 만들고 싶은데 디자인 감각이 없어요. 완전히 다른 느낌 4개를 HTML 한 장에 만들어줘. 보고 고를게.”

3. 나를 인터뷰 시키기

그래도 애매한 게 남으면 Claude한테 거꾸로 나를 인터뷰하게 합니다.

예: “애매한 부분을 한 번에 하나씩 질문해줘. 내 대답에 따라 구조가 바뀔 만한 질문부터.”

4. 레퍼런스는 코드가 최고

원하는 걸 말로 설명 못 할 땐, 비슷하게 구현된 코드를 그냥 가리키는 게 제일 낫습니다. 언어가 달라도 상관없어요.

예: “vendor/rate-limiter에 있는 이 Rust 코드가 딱 내가 원하는 동작이에요. 읽어보고 똑같이 TypeScript로 다시 만들어줘.”

5. 계획서는 ‘바뀔 것 같은 것’ 먼저

구현 전에 계획을 짜달라고 하되, 나중에 내가 손댈 가능성이 높은 것, 예를 들면 데이터 구조나 화면 흐름을 맨 앞에 두게 합니다. 그래야 미리 고칠 걸 발견하죠.

예: “HTML로 계획서 만들어줘. 내가 제일 만질 것 같은 것부터: 데이터 구조, 화면에 보이는 부분. 단순 정리 작업은 맨 밑에 둬, 그건 믿고 맡길게.”

코딩 중에 하는 것

작업 노트 쓰게 하기

아무리 계획을 잘 짜도 코딩하다 보면 예상 못 한 게 튀어나옵니다. 그래서 Claude Code한테 implementation-notes.md 파일을 만들어서 “계획이랑 다르게 결정한 것들”을 기록하게 합니다. 다음에 배우려고요.

예: “implementation-notes.md 파일 만들어서 써줘. 계획이랑 어긋나는 상황이 나오면, 안전한 쪽으로 선택하고, ‘Deviations’에 기록하고, 계속 진행해.”

코딩 끝나고 하는 것

1. 설명 자료 만들기

다 만들면 팀의 승인을 받아야 하죠. 이때 Claude한테 프로토타입·스펙·노트를 한 문서로 묶게 하면, 검토하는 사람도 이해가 빠르고 승인도 빨라집니다.

예: “프로토타입, 스펙, 작업노트를 Slack에 올릴 문서 하나로 묶어줘. 데모 GIF부터 보여줘.”

2. 퀴즈 내게 하기

이게 재밌는데, 긴 작업 후엔 Claude가 나도 모르는 새 엄청 많은 걸 해놨을 수 있습니다. 코드 diff만 봐선 감이 잘 안 오죠.

그래서 Claude한테 변경 내용을 정리한 리포트랑 퀴즈를 만들게 하고, 퀴즈를 다 맞혀야만 머지합니다. 내가 이해 못 한 코드는 병합 안 하는 거죠.

예: “이번 변경을 내가 확실히 이해하고 싶어. 뭘 왜 했는지 맥락까지 담은 HTML 리포트 만들고, 맨 밑에 내가 꼭 통과해야 할 퀴즈도 넣어줘.”

결론

정리하면 이렇습니다. 모델이 좋아질수록, 제대로만 시키면 더 많은 걸 해냅니다. 긴 작업이 엉뚱하게 돌아온다면, 대개 내가 뭘 모르는지 정의하는 데 시간을 덜 쓴 것입니다.

설명 자료, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 전부 “나중에 고치면 비싸질 것을, 지금 싸게 미리 알아내는” 방법이다.

그러니 다음 프로젝트는 코드부터 짜지 말고, “Claude야, 내가 뭘 모르는지 먼저 찾게 도와줘”로 시작해보라는 게 그의 핵심 조언입니다.