단계별 개발 워크플로우 'CRISPY'를 조사하다

최근에는 AI에게 개발을 맡기는 워크플로우가 일반화되었습니다.

Spec-Driven Development (SDD/仕様駆動開発)가 표준이 되어, SDD를 수행하기 전에 조사를 시키는 경우도 많을 것입니다.

이 흐름을 Research / Plan / Implement의 3단계로 나누고, 프롬프트별로 오픈 소스로 배포한 것이 HumanLayer의 Dex Horthy 씨였으며, RPI라고 불렸습니다.

그 본인이 2026년 3월에 'RPI에서 잘못했던 모든 것'이라는 제목으로 강연하고, 반년 만에 재구축한 후속 버전이 나왔습니다.

그것이 CRISPY입니다.

한국어로는 정보가 거의 없어서 여러 자료를 읽으며 정리해 보았습니다.

(잘못된 부분이 있다면 지적 부탁드립니다)

TL;DR

AI에게 기능을 하나 만들게 할 때의 절차서. 질문 → 조사 → 설계 → 구성 → 계획 → 구현 → PR의 7단계로 나누어, 단계별로 끊어서 진행합니다.
각 단계가 끝날 때 에이전트가 markdown을 내보내고, 인간은 그것을 읽고 수정한 후 다음 단계로 넘어갑니다. 코드를 작성하게 하는 것은 설계에서 합의한 후에 이루어집니다.
조사 단계에서는 에이전트에게 '무엇을 만들지'를 입력하지 않습니다.
나온 코드는 사람이 읽습니다. 2~3배의 생산성 향상을 목표로 합니다.

애초에 RPI란 무엇인가

Dex 씨가 2025년 여름경 오픈 소스로 공개한 워크플로우입니다.

요약하자면 다음과 같습니다.

컨텍스트가 채워질수록 정확도가 떨어집니다 (40%를 넘으면 이상해지기 시작한다고 하며, 본인은 Dumb Zone이라고 불렀습니다).
그래서 작업을 Research, Plan, Implement로 나누고, 각 단계의 결과물(markdown)만 다음으로 전달합니다. 코드를 읽으면서 늘어난 컨텍스트는 가져가지 않습니다.
인간은 조사 메모와 계획서를 읽고 수정합니다. 조사의 한 줄 오타가 계획이 되고, 1000줄의 코드가 되기 때문에, 미리 막아두는 것이 비용을 들이지 않는 방법입니다.

즉, '작업을 분리하여 컨텍스트를 작게 유지하면서, 계획을 리뷰한다'라는 것이었습니다.

RPI의 문제점

공개한 지 반년 정도 지나서 문제가 보이기 시작했다고 합니다.

계획을 승인했는데도 나온 코드가 다릅니다.
설계 선택지를 상담해야 할 단계가 멋대로 건너뜁니다.
잘 작동하게 하기 위해, 정형화된 문구를 프롬프트에 추가하게 됩니다.
조사 메모에 의견이 섞여서 사실로 읽기 어려워집니다.
계획이 계층별로 나열되어 끝까지 작동시켜 볼 수 없습니다.

CRISPY의 사상

위와 같은 문제를 해결하기 위해 새롭게 탄생한 것이 CRISPY입니다.

RPI에서는 3단계였던 흐름을 7단계로 재분할했습니다.

순서	명칭	개요
1	Questions	티켓 내용에서 조사해야 할 질문 항목 생성
...

실제 예를 생각해 봤다

제가 생각하기에는 아마 이런 것일 것 같아서 예시를 작성해 보겠습니다.

(예) 설정 화면에 다크 모드 전환을 추가하고 싶다

Questions:
티켓만 보고, 코드를 읽기 전에 '설정 화면은 어디서 렌더링하는가?', '테마 상태는 지금 어디에 가지고 있는가?', '사용자 설정은 어떻게 저장하는가?'와 같은 질문을 생성합니다.
Research:
별도의 새로운 세션이 그 질문만 받아서 코드를 읽고 답변합니다.
'테마는 ~에 가지고 있다'라는 사실만을 적어냅니다.
다크 모드를 추가한다는 이야기는 모릅니다
Design
AI가 티켓 내용을 파악한다- '현황은 이러하고, 하고 싶은 것은 이러하며, 테마 상태는 기존 설정 스토어에 넣고, 전환은 CSS 변수로, OS 설정 추종 여부는 미결'을 200줄 정도로 작성합니다.
마지막에 인간이 읽고 리뷰합니다
Structure:
설계를 받아 작업 내용을 페이즈로 분할해 나갑니다.
새로 추가할 타입이나 함수의 시그니처 등도 여기서 결정됩니다.
강연에서는 C의 헤더 파일에 비유했습니다.
Plan:
페이즈 분할을 받아, 각 페이즈에서의 구현 계획을 세웁니다.
여기까지는 방침이 정해져 있으므로, 인간은 훑어보면서 리뷰합니다.
Implement, Pull Request: 구현하고, 인간이 diff를 읽고 리뷰합니다.

CRISPY가 개선하려 한 것

지금까지의 RPI에서는 3가지로 구분했지만, 실제 이 3가지 안에는 숨겨진 절차가 존재했다고 합니다.

숨겨진 절차는 우리가 명시적으로 요청한 것이 아니라, 그때의 모델이 알아서 처리해 주던 것입니다. 팀 개발 등을 진행할 때 편차가 생겼다고 합니다.

지시 과다 문제

RPI의 플래닝용 프롬프트에는 85개의 지시가 포함되어 있었습니다.

프롬프트가 많을 경우 문제는, 지켜지지 않았을 때 오류가 발생하는 것이 아니라, 무언의 방식으로 지시 사항이 누락되는 것입니다.

RPI의 경우, '설계를 작성하기 전에 설계 선택지를 제시하여 인간과 상담한다'는 가장 중요한 단계가 약 50%의 확률로 건너뛰어졌다고 합니다.

CRISPY에서는 하나의 프롬프트에 들어가는 지시 사항을 40개 미만으로 제한하고 있습니다.

'먼저 질문하고, 다음 조사하고, 선택지를 제시하라'와 같이 하나의 프롬프트 안에서 분기시키는 것을 중단하고, 단계별로 다른 프롬프트, 다른 세션으로 분리했습니다.

단계가 건너뛰어 발생하는 주문(呪文)

위의 원인으로 인해 단계가 지켜지지 않았고, 나아가 그것을 지키기 위한 프롬프트가 돌아다니게 되었습니다. 이를 '주문'이라고 부르며, 기본 동작을 수행하기 위해 필요한 주문이 필요하다는 문제점을 느끼고 있었습니다.

이번 CRISPY에서는 이 주문을 분해하여 제대로 된 단계로 명시적으로 분리했습니다.

계획대로 구현되지 않음

원래의 생각은 '계획을 읽어 리뷰하면 코드를 읽지 않아도 된다'였지만, 결국 계획대로 구현되지 않는 상황이 발생하고 있었습니다.

따라서 CRISPY에서는 인간이 검토하는 부분을 몇 군데 마련하여, 계획 전 Design・Structure 단계에서 방침에 합의하고 Pull Request에서 코드를 읽도록 했습니다.

개발 속도를 10배로 높이는 것보다는, 2~3배 수준으로 유지하면서 더 견실하게 만드는 것을 선택했습니다.

개인적으로 참고해 보고 싶은 부분

제어 흐름을 프롬프트에 쓰지 않기

하나의 거대한 프롬프트에서 '먼저 질문하고, 다음 조사하고, 선택지를 제시하라...'와 같이 조건 분기를 시키지 않고, 플로우가 바뀌면 새로 다른 프롬프트로 전환하는 것입니다.

40 지시 사항 미만이라는 숫자를 조금 의식해 봐야겠다고 생각했습니다.

소개된 내용에 따르면, '프롬프트로 할 필요는 없는 것은 일반 프로그램의 제어 흐름으로 하라'는 것이었습니다.

Research에 목적을 부여하지 않기

Research 단계에서는 무엇을 만들고 싶은지 에이전트에게 알려주지 않고 조사하게 합니다.

AI에게 만들고 싶은 것을 알려준 상태에서 조사하게 하면, '이렇게 하면 만들어 볼 수 있을 것 같다'는 의견이 섞인 결과가 출력된다고 합니다.

작동하는 상태로 진행하기

그대로 AI에게 계획을 맡기면 'DB 전부 변경, 다음 서비스 계층 전체, 다음 API, 마지막 프론트엔드'와 같이 계층별로 제시합니다.

Structure 단계에서 목업(mock) API를 만들고 프론트를 연결한 후, 나중에 실제 버전으로 대체하는 식의 설계/계획을 맡기는 것입니다.

(인간이 평소에 하는 제작 방식을 에이전트에게도 시키는 것이라는 의미인 것 같습니다)

맺음말

이 모든 것을 실제 현장에서 사용하면 상당히 무거운 워크플로우라고 생각했지만, 조사해 보니 흥미로운 관점이 언어화되어 있어 곳곳에서 자신의 워크플로우에 적용할 수 있을 것 같은 느낌을 받았습니다.

여러 가지를 직접 시도해 보고 마음이 안정되면 언젠가 자신의 워크플로우도 소개할 수 있으면 좋겠습니다.