Fable과 Opus는 직접 코드를 작성하며 배운 엔지니어들에게 가장 편안한 도구가 아닐 수도 있습니다.

저는 Simon Willison의 최근 노트를 읽고 이 점에 대해 생각하기 시작했습니다. 그의 요점은 간단합니다. Fable과 같이 강력한 코딩 에이전트 (Coding Agent)가 있다면, 모든 조건을 직접 상세히 설명하기보다 모델이 스스로 판단하도록 하는 것이 더 나을 수 있다는 것입니다.

"규모가 큰 기능에 대해서는 테스트를 실행하되, 작은 문구 변경에는 실행하지 말고, 디자인 변경은 제외하고..."와 같이 상세한 규칙을 작성하는 대신, 단순히 "적절한 곳에 테스트를 작성하고 실행하세요"라고 말할 수 있습니다.

비용 문제도 마찬가지입니다. 어떤 작업을 어떤 모델에 할당할지 수동으로 결정하는 대신, 에이전트에게 적절한 저비용 모델을 선택하고 작업을 하위 에이전트 (Subagent)에게 위임하도록 요청할 수 있습니다.

수동 변속기 자동차와 자동 변속기 자동차

이것은 거친 비유이지만, 자동차를 운전하는 것과 비슷하게 느껴집니다.

운전을 즐기는 사람들은 종종 수동 변속기 (Manual) 자동차를 좋아합니다. 그들은 스스로 기어를 선택하고 싶어 합니다. 엔진 속도를 느끼고 자동차가 자신의 의도에 직접 반응하기를 원합니다.

단순히 목적지에 도착하고 싶은 사람들에게는 자동 변속기 (Automatic)가 더 쉽습니다.

소프트웨어 엔지니어들도 비슷합니다. 오랫동안 전문적으로 코드를 작성해 왔다면, 보통 자신만의 작업 방식이 있습니다. 먼저 타입을 정확하게 맞추고 싶을 수도 있습니다. 작은 차이 (Diffs)를 선호할 수도 있습니다. 테스트가 얼마나 세밀해야 하는지에 대한 특정한 감각이 있을 수도 있습니다. 심지어 익숙하지 않은 코드베이스를 읽는 자신만의 순서가 있을 수도 있습니다. (적어도, 저는 그러기를 바랍니다.)

그런 스타일을 가진 사람에게 Fable이나 Opus와 같이 고도로 자율적인 모델은 너무 자동적이라고 느껴질 수 있습니다.

모델이 강력할수록 작은 지시사항들이 방해가 된다

이것은 인간 조직의 관리 구조와 동일합니다.

주니어 구성원에게는 구체적인 지시가 필요합니다: 이 문서를 이 관점에서 읽고 이 형식으로 요약하세요.

시니어 구성원은 더 거친 과업을 맡을 수 있습니다: "이 문제를 해결하고 싶으니, 조사하고 구현 계획을 세워서 진행하세요."라고 말이죠.

물론 이것이 업무를 그냥 떠넘긴다는 뜻은 아닙니다. 여전히 목표, 제약 조건, 그리고 성공 조건을 제시해야 합니다. 다만 과정의 모든 단계를 일일이 지시하지 않을 뿐입니다.

Fable과 Opus에 대한 지시 방식은 두 번째 사례(시니어 구성원에게 맡기는 방식)에 점점 더 가까워지고 있다고 생각합니다.

단순히 성능이 아니라 위임 수준에 따라 코딩 에이전트를 선택하세요

까다로운 점은 가장 강력한 모델이 항상 최선의 선택은 아니라는 것입니다.

지능(intelligence)이 아니라 위임 수준(delegation level)에 따라 모델을 선택하세요.

만약 개발이 진행되는 방식에 대해 이미 확고한 선호도가 있다면, 모든 프로세스를 완전히 자율적인 플래그십(flagship) 모델에 맡기는 것보다 Sonnet과 같은 중간 단계(mid-tier) 모델을 직접 조종하는 것이 더 낫게 느껴질 수 있습니다.

• 개발 프로세스를 직접 결정하고 싶다면, Sonnet과 같은 중간 단계 모델을 밀접하게 제어할 수 있는 도구로 사용하세요.
• 구현 방식 자체를 위임하고 싶다면, Opus나 Fable과 같이 높은 자율성을 가진 모델을 사용하세요.
• 본인의 개발 스타일이 아직 정해지지 않았다면, 플래그십 모델에 폭넓게 위임하는 것이 더 쉬울 수 있습니다.
• 기존 코드베이스의 유지보수 작업이나 작은 수정 사항의 경우, 중간 단계 모델과 짧게 상호작용하는 것이 종종 더 효율적입니다.

Fable과 Opus의 가치는 단순히 코드를 더 빨리 작성한다는 점에만 있지 않습니다. 개발이 진행되는 방식 자체를 위임할 수 있다는 점에 있습니다.

이것이 바로 사람들이 이른바 '바이브 코딩 (vibe coding)'이라고 부르는 방식과 잘 어울리는 이유이기도 합니다.

바이브 코딩이란 모델에 모호한 프롬프트를 던져놓고 결과가 잘 나오길 막연히 바라는 것을 의미하지 않습니다. 대신 "대략 이런 느낌의 것을 원한다"와 같은 목표를 모델에 부여하고, 모델이 더 큰 결정들을 처리하도록 하는 것을 의미합니다: 작업 분해 (task decomposition), 조사 범위, 테스트 작성 여부, 하위 에이전트 (subagents)로의 위임 여부, 그리고 최종 결과물의 일관성 유지 등이 그것입니다.

만약 이러한 결정들을 직접 내리고 싶다면, 모델이 그 정도로 자율적일 필요는 없습니다.

공정하게 말하자면, 때로는 자동화가 승리합니다

오해는 하지 마세요. 설령 당신이 직접 제어하는 것을 좋아하더라도, Fable이나 Opus가 단순히 적절한 도구인 순간들이 있습니다. 익숙하지 않은 코드베이스 전체를 대규모로 리팩터링 (Refactoring) 해야 할 때, 접근 방식에 대해 아직 의견이 정립되지 않은 탐색적 작업(Exploratory work)을 할 때, 혹은 내일 당장 버릴 수도 있는 프로토타입(Prototype)을 만들 때 말입니다.

논점은 "수동이 더 낫다"가 아닙니다. 핵심은 위임 수준 (Delegation level)이 하나의 선택지라는 것입니다. 만약 당신이 항상 가장 자율적인 모델을 기본값으로 선택한다면, 당신은 깊은 고민 없이 그 선택권을 건너뛰고 있는 것입니다.

수동인가 자동인가?

Fable이나 Opus와 같은 플래그십 (Flagship) 모델들이, 직접 코드를 작성하던 시대에 성장한 엔지니어들에게 항상 최고의 파트너인 것은 아닙니다.

만약 당신만의 스타일이 있고 직접 핸들을 잡고 싶다면, Sonnet과 같은 중간 단계 (Mid-tier) 모델을 당신의 손을 확장하는 도구로 사용하는 것이 더 나을 수 있습니다. 반면, 개발 프로세스 자체를 위임하고 싶다면 Fable과 Opus가 진정한 가치를 발휘하기 시작합니다.

요약하자면, 지능 (Intelligence)이 아니라 위임 수준에 따라 모델을 선택하세요.

수동 변속 차량을 좋아하는 사람에게는 아무리 최고의 자동 변속 차량이라도 항상 가장 즐거운 선택은 아닐 수 있습니다. 하지만 단순히 목적지에 도착하는 것이 목표라면, 자동 변속 차량이 승리합니다.

Fable과 Opus는 아마도 그런 종류의 도구일 것입니다.

당신은 코딩 에이전트 (Coding agent)를 어떻게 선택하시나요? 지능에 따라 선택하시나요, 아니면 얼마나 위임하고 싶은지에 따라 선택하시나요? 그리고 만약 당신이 직접 코드를 짜며 프로그래밍을 배웠다면, 실제로 전체 프로세스를 통째로 넘겨주는 것이 편안하신가요?

참고: 이 기사는 원래 일본어로 작성되었으며, GPT를 통해 영어로 번역되었습니다.