AI 리서치 엔지니어가 자신의 전체 워크플로우와 프롬프트를 공개하다

Fable 5는 나타났다가 사라졌습니다. 그리고 너무 빨리 사라졌기 때문에, 개발자들은 그것을 더욱 간절히 원하게 되었습니다. 희소성은 사물을 더 가치 있게 만드는 경향이 있습니다.

짧은 재임 기간 동안의 리뷰들은 매우 유능하며, 오래 지속되는 모호한 작업들을 처리하는 데 뛰어난 모델이라고 설명했습니다. 하지만 비용이 너무 많이 들었습니다. 또한 이 모델은 지능이 충분히 높아서, 대규모 작업이나 전면적인 개편을 수행할 때 과도하게 생각하는 (overthink) 경향이 있었습니다. 아마도 모델의 크기 때문일 가능성이 높습니다. 기능을 구현하거나 변경하는 것과 같은 반복적인 작업의 경우, Fable 5는 GPT 5.5와 정면 승부를 벌여도 대등한 수준이었으나, Fable 5는 10배 더 오래 실행되었습니다. 즉, 더 큰 모델, 더 많은 과도한 생각, 그리고 더 많은 시간이 소요되었습니다. 또 다른 문제는 폴백 (fallback) 동작이었습니다. 만약 모델이 폴백 모델인 Opus를 호출해야 하는 상황에 직면하면, 사용자는 그것이 발생했다는 사실을 반드시 알 수 없으며, 더 높은 요금이 청구되었습니다.

그럼에도 불구하고, 이는 기존 모델들과 비교했을 때 눈에 띄는 변화였습니다. 특정 목표 지향적인 문제를 처리하는 데 유능했습니다. 예를 들어, 반복적인 프로파일링 (profiling), 호출 지점 추적 (tracing call sites), 핫 루프 (hot loops) 최적화, 그리고 회귀 예산 (regression budget) 검증을 통해 느린 경로를 최적화하는 작업 등이 그러합니다. 아키텍처 설계 (architecture design) 측면에서는 여전히 놀라운 수준은 아니었습니다. 따라서 목표 지향적인 추진력에는 좋았지만, 그 안에서도 원하는 결과를 얻으려면 세션 단위로 실행하고, 코드를 검토하며, 조종(steer)하거나 압축(compact)해야 했습니다.

이 모델은 제가 채택했던 방식인 계획, 연구, 그리고 검토를 위해 사용하기에 좋은 모델입니다. 저는 실제적인 이점을 확인했습니다. 하지만 오케스트레이션 (orchestration)이나 워크플로우 (workflows)를 실행하는 문제에 있어서는, 여전히 GPT 5.5가 토큰과 시간 측면 모두에서 더 낫고 비용 효율적이라고 믿습니다. 개인적으로 저는 토큰 지출도 신경 쓰지만, 제 시간은 훨씬 더 중요하게 생각합니다.

Fable 5가 드러낸 더 큰 문제

모델의 능력(Model capability)과는 별개로, 저는 여전히 우리가 더 큰 문제를 놓치고 있다고 생각하며, Fable 5는 그 능력의 특성 때문에 이 문제를 돋보기로 비추듯 드러냈습니다. 코딩 에이전트(coding agents)의 파워 유저들이 어떻게 프롬프팅(prompting)을 하고, 워크플로우(workflows)를 실행하며, 결과물을 검토(reviewing)하고, 조치를 취하는지에 대한 좋은 사례가 충분하지 않기 때문에, 조직 내 AI 도입은 여전히 많은 개발자에게 도전 과제로 남아 있습니다.

그래서 저는 제 프로세스를 공개적인 워크플로우 플레이북 (workflow playbook)으로 전환하고 있습니다. 제가 어떻게 프롬프팅을 하는지, 어떻게 워크플로우를 실행하고 제어(steer)하는지, 그리고 에이전트가 실제 작업을 수행할 때 발생하는 예외 상황(edge cases)을 어떻게 처리하는지를 담았습니다.

다음은 제가 코딩 에이전트에게 실행하도록 요청한 프롬프트입니다:

워크플로우 사용 가이드 생성기 (Workflow usage guide generator)

개인적인 워크플로우 사용 내역을 공개적인 개발자 가이드로 변환하기 위한 개인정보 보호 프롬프트.

<prompt>
당신은 저의 개인적인 Atomic 워크플로우 사용 내역을 공개적이고 개발자 지향적인 가이드로 변환하는 것을 돕고 있습니다.

...

최종 결과물은 여러분의 코딩 에이전트에게 전달할 수 있는 워크플로우 플레이북입니다. 이는 제가 범위를 정의하고, 완료 기준(done criteria)을 설정하며, 막힌 단계(blocked stages)를 제어하고, 결과를 검증(verify)하며, 워크플로우가 경로를 벗어났을 때 복구(recover)하는 방법을 포함하여, 제가 어떻게 워크플로우를 실행하고 효과적으로 프롬프팅하는지를 오픈 소스로 공개합니다.

워크플로우 플레이북 (Workflow playbook)

워크플로우는 단지 제 프로세스를 반복 가능하게 만든 것일 뿐입니다

제가 실행하는 워크플로우는 Claude Code, Codex /goal, 또는 Hermes Agent에서 볼 수 있는 동적인 워크플로우나 루프(loops)가 아닙니다. 그것들은 말 그대로 제가 이미 수행하고 있는 작업의 프로그래밍 방식 자동화(programmatic automations)이며, 인간 참여형(human-in-the-loop) 체크포인트, 검토 게이트(review gates), 그리고 실행 중간에 에이전트를 제어(steer)할 수 있는 능력을 갖추고 있습니다.

저는 더 이상 수동으로 프롬프팅을 많이 하지 않습니다.

A 좋은 예로, 여러분이 리팩터링(refactor)을 하고 있다고 가정해 봅시다. 아마도 프롬프트를 실행한 다음, /compact를 하고, 다시 동일한 프롬프트를 실행하는 자신을 발견할 것입니다. 이를 세 번 반복하고, 다시 컴팩트(compact)하고, 계속 진행하는 식이죠. 여러분은 아마도 이 작업을 매우 빈번하게 수행하고 있을 것입니다.

그것이 하나의 워크플로우 (workflow)가 될 수 있다는 사실이 밝혀졌습니다. 인간의 자율성 (human autonomy)을 포기하지 않으면서도, 반복적인 작업을 줄이고 마이크로매니징 (micromanage)을 덜 할 수 있습니다. 또한 워크플로우 설계가 파이프라이닝 (piping)을 처리하기 때문에 슬롭 (slop, 불필요한 결과물)도 줄어듭니다. 즉, 무엇이 앞으로 전달될지, 무엇이 검토될지, 무엇이 거부될지, 그리고 인간이 어디에서 결정을 내려야 하는지를 워크플로우가 관리합니다.

비용, 시간, 그리고 품질

비용 측면에서, 저는 일반적인 Codex를 사용할 때보다 더 많은 비용을 쓰지만, Claude Code를 사용하는 것보다는 현저히 적게 씁니다. 실행 시간 측면에서는 언뜻 보기에 Codex와 거의 비슷하며, Claude Code보다는 훨씬 적게 걸립니다.

결과물의 품질이야말로 이 방식이 빛을 발하는 지점입니다. 워크플로우 접근 방식은 동일한 문제에 대해 Codex 및 Claude Code 모두를 상대로 75%의 승률을 기록했습니다. 이는 제가 Codex만 단독으로 사용할 때보다 실제로 훨씬 적은 시간을 소비한다는 것을 의미합니다.

저는 과포화된 벤치마크 (benchmarks)가 아니라 실제 문제를 해결해 보려 노력했습니다. 실제 코드베이스 (codebase)에서 마이그레이션 (migration), 새로운 기능 추가 (new feature), 버그 수정 (bug fix) 등 다양한 종류의 작업을 수행하도록 요청했습니다. 핵심은 코딩 에이전트 (coding agent)가 좋아 보이는 특정 사례 하나를 골라내는 것이 아니었습니다. 워크플로우 우선 (workflow-first) 접근 방식이 다양한 형태의 소프트웨어 작업 전반에 걸쳐 유용하게 유지되는지 확인하는 것이 목적이었습니다.

마이그레이션 작업은 기존의 latin1 지향적 청크 (chunk) 형식에서 임베디드된 PNG 메타데이터를 레거시 폴백 (legacy fallback) 동작을 유지하면서 UTF-8 호환 형식으로 이동하는 것을 요구했습니다. 새로운 기능은 UI에서 협업 연결 실패를 드러내는 작업으로, 이는 일시적인 연결 상태 (transient connection state)를 추적하고, 라이프사이클 이벤트 (lifecycle events)를 연결하며, 리스너 (listeners)를 정리하고, 접근성 (accessibility)을 유지하며, 테스트를 추가하는 것을 의미했습니다. 버그 수정은 해당 도형 외부의 예상 동작을 변경하지 않으면서 닫힌 도형 내부의 화살표 곡선 (arrow-curve) 동작을 수정하는 작업이었습니다.

마이그레이션 및 신규 기능 이슈 전반에 걸쳐, 워크플로우(workflow)로 생성된 PR(Pull Request)은 Claude Code 및 Codex의 PR과 비교했을 때 기술적으로 가장 안전하고 정확한 변경 사항을 일관되게 반영했습니다. PNG 메타데이터 마이그레이션의 경우, Workflows PR은 명세(spec)에 부합하는 UTF-8 iTXt를 작성했고, Excalidraw 키 기반의 메타데이터를 선택했으며, 기존의 tEXt 폴백(fallback)을 보존하고, 이모지 및 디스크 상의 청크(chunk) 동작을 검증했습니다. 반면 다른 PR들은 관련 없거나 잘못된 형식의 iTXt 청크가 유효한 기존 메타데이터를 가릴 수 있는 미묘한 호환성 버그를 가지고 있었습니다. 협업 상태(collaboration-status) 기능의 경우, Workflows PR은 가장 우수한 일시적 비지속 상태(transient non-persistent state) 모델, Socket.IO 생명주기(lifecycle) 처리, 리스너(listener) 정리, 접근성 및 타겟팅된 테스트를 보여준 반면, 대안들은 공유된 에러 지표 상태(error-indicator state) 버그를 가졌거나 생명주기 및 UI 커버리지가 더 좁았습니다.

버그 수정 사례에서도 동일한 패턴이 나타났습니다. Workflows PR은 가장 좁고 안전한 동작 변경을 통해 실제 화살표 곡선(arrow-curving) 버그를 해결했습니다. 이는 동일한 시작 경계 도형 내부에서 그리는 동안 조기 자동 완성(auto-finalization)을 방지했고, 다른 대상에 대한 일반적인 바인딩(binding) 및 완성을 보존했으며, 의미 있는 회귀 테스트(regression) 커버리지를 추가했습니다. 거절된 Claude Code 및 Codex 대안들은 단순 클릭으로 생성된 화살표가 바인딩 가능한 대상에서 더 이상 자동 완성되지 않는 심각한 수준의 회귀(regression)를 유발하거나, 바인딩 간극, 다른 대상 도형, 완성의 엣지 케이스(edge case)에 대한 커버리지가 더 취약했습니다. 전반적으로 워크플로우는 경쟁 관계인 에이전트 생성 PR들보다 범위가 더 좁고, 호환성에 더 안전하며, 테스트가 더 잘 되어 있고, 엣지 케이스 동작에 더 신중한 변경 사항을 생성함으로써 AI 슬롭(slop, 저품질 결과물)을 줄였습니다.

이것이 제가 단순히 아이디어에 대해서만 쓰는 대신 워크플로우 플레이북(playbook)을 공유하는 이유입니다. 목표는 다른 개발자가 저의 개인적인 컨텍스트(context)를 필요로 하지 않고도, 이 패턴을 복사하고 프롬프트를 조정하여 자신의 코드베이스에 유사한 워크플로우 우선(workflow-first) 프로세스를 실행하는 것입니다.

개인적으로 저는 개발자를 배제하는 것이 아니라, 개발자가 루프 안에 머물게(keep the developer in the loop) 할 때 신뢰성과 향상된 모델 성능이 기대치를 상회하는 것을 목격합니다. 저는 매일 이 논제를 실천하며 살고 있습니다.

이것을 공유하는 이유

저는 코딩 에이전트(coding agents)와 협업하는 방법에 대한 좋은 사례들이 필요하다고 생각합니다. 즉, 각 개인의 워크플로우(workflow)가 어떤 모습인지, 어떻게 프롬프팅(prompting)을 하는지, 어느 지점에서 개입하는지, 어디에서 자동화(automation)를 신뢰하고 어디에서 제어권을 포기하기를 거부하는지에 대한 사례 말입니다.

이 플레이북(playbook)은 이를 구체화하기 위해 만들어졌습니다. 이 플레이북은 실무에서 중요한 워크플로우 단계들을 다룹니다: 명확한 목표(objective) 설정부터 시작하여, 수락 기준(acceptance criteria) 추가, 특정 단계의 방향 재설정, 차단된 에이전트(blocked agents)에 대한 대응, 실패한 검증(validation) 처리, 일시 중지 또는 재실행 시점 결정, 그리고 최종 합성(synthesis) 결과를 구현 단계(implementation steps)로 전환하는 과정 등을 포함합니다.

핵심은 업무의 신비감을 제거하여 모든 개발자가 더 쉽게 구축할 수 있도록 만드는 것입니다. 좋은 결과를 얻기 위한 진입 장벽을 최대한 낮춰 봅시다.

참고 문헌

• Workflow playbook
• Atomic