RFTCR - 에이전트 주도 소프트웨어 개발을 위한 새로운 SDLC 프레임워크
2025년 05월 11일 작성TL;DR
- 바이브 코딩은 에이전트 개발 방법의 한가지 실행방법이고, 에이전트 개발 방법은 SLDC (Software Development Life Cycle) 을 전체 커버하는 더 큰 개념이다.
- 에이전트 기발 개발은 비즈니스 요구사항을 코드로 정확히 변환하는 게 가장 어려운 부분이다. 일정 수준의 지식 수준이라면 누구나 동일한 코드를 생성할 수 있게끔 프레임워크가 필요하다.
- RFTCR (Requirement-Feature-Task-Code-Reflect) 프레임워크가 현재까지 알려진 가장 효과적인 프레임워크이다. (이름은 내 맘대로 지었지만 흐름은 그냥 알려진 내용들을 정리만 한 거다)
- 이 프로세스의 실행에는 프로덕트 오너/기획자와 개발자 두 가지 역할의 긴밀한 협업이 필수적이다.
- C4 모델처럼 단계별 입력/출력의 추상화 수준을 명확히 정의해야 프로세스가 표준화되고 재현 가능하다. 그렇지 않으면 개인 역량에 의존해 일관성을 잃게 된다.
시작하며
소프트웨어 개발에서 AI 에이전트의 역할이 커지면서, AI가 코드를 주도적으로 생성하고 사람이 이를 평가하는 에이전트 주도 개발 패러다임이 등장했다.
이런 방식에서는 개발자가 코드를 직접 작성하기보다, LLM 기반의 AI가 코드를 만들고 개발자는 이를 검토하고 조율한다. 하지만 초기 경험자들은 AI에게 우리가 원하는 코드를 안정적으로 만들어내도록 가이드하기 어렵다 는 핵심 문제에 부딪힌다.
한두 번의 프롬프트만으로 완벽한 결과를 얻기 힘들고, 요구사항이 조금만 모호해도 AI가 엉뚱한 방향으로 코드를 생성하기 일쑤다. 이런 어려움을 해결하기 위해서는 AI 가 단계별로 문제를 풀어나갈 수 있는 (Plan and Solve) 가이드라인이 필요하다.
현재 알려진 여러 파편화된 지식을 합쳐보면, Requirement → Feature → Task → Code → Reflect 순으로 진행되는 5단계 프로세스의 RFTCR이라는 SDLC(Software Development Life Cycle) 프레임워크를 자연스럽게 도출하게 된다.
실제 커뮤니티에서도 에이전트 기반 IDE 활용을 위해 위의 순서를 권장하는 글을 쉽게 찾아볼 수 있고, 다양한 도구들도 나온고 있다.
RFTCR은 에이전트에게 명확한 가이드라인을 제시해서 혼선 없이 원하는 결과물을 얻기 위한 베스트 프랙티스 를 찾는 과정에서 나온 결과물이며, 본 글에서는 이 프레임워크 각 단계의 구체적인 실행과정과, 왜 이런 구조가 에이전트 주도 개발에 효과적인지 살펴본다.
RFTCR 개요: 단계와 역할 분담
RFTCR 프로세스는 요구사항 → 기능 → 태스크 → 코드 → 리플렉션 순으로 진행된다.
이때 각 단계를 수행하는 데 두 가지 역할이 관여하는데, 바로 프로덕트 오너(또는 기획자) 와 개발자다.
- 기획자는 비즈니스 관점에서 무엇을 만들어야 하는지 정의하는 역할이고,
- 개발자는 기술적 관점에서 어떻게 만들지를 책임지는 역할이다.
RFTCR에서는 이 둘이 단계마다 명확한 산출물(artifact)을 주고받으며 협업한다. 일반적인 소프트웨어 개발에서도 기획자와 개발자의 협력이 중요하지만, 에이전트 주도 개발에서는 이들이 만들어내는 산출물이 곧 AI 에이전트의 프롬프트가 되어 코드 생성 품질을 좌우하기 때문에, 역할 분담이 더욱 체계적이어야 한다.
각 단계별로 누가 주도권을 가지는지는 다르지만, 모든 단계에 두 역할의 관여가 일부씩은 있다. 예를 들어 요구사항 단계에서는 기획자가 주도적으로 문서를 작성하지만, 개발자도 초기 기술 검토나 피드백을 통해 관여한다. 반대로 코드 단계에서는 개발자가 에이전트와 함께 코드를 생성하지만, 기획자가 큰 그림에서 우선순위를 조정하거나 산출물을 검증할 수 있다. 결국 RFTCR의 핵심은 “한 단계에 한 역할만 일방적으로 일하는 것이 아니라, 주관 역할이 있더라도 상대 역할의 관점을 함께 고려한다”는 것이다. 이를 통해 추후 단계에서 뒤늦게 요구사항 미스매치나 기술적 문제를 발견하는 일을 줄이고, 처음부터 역할 간 요구사항 충족과 기술 구현의 정합성을 높일 수 있다.
현업에서는 기획자가 매번 개발자를 불러서 기획의 기술 검증을 할 수는 없다. 따라서 기획자가 사용하는 도구에서 기술 검증을 어느정도 해줄 수 있는 능력이 반드시 필요하다.
이제 RFTCR의 각 단계를 순서대로 살펴보고, 각 단계마다 어떤 일을 하고 어떤 산출물을 만들며 어떤 도구 지원이 필요한지, 그리고 기획자와 개발자가 어떻게 협업하는지를 약간 더 구체적으로 확인해본다.
1. 요구사항 단계 (Requirement)
첫 번째 단계는 요구사항을 명확히 정의하는 것이다.
기획자가 중심이 되어 제품 또는 기능의 요구사항을 자연어로 작성한다. 여기에는 비즈니스 목표, 사용자 스토리, 기능적/비기능적 요구사항, 제약 조건 등이 포함된다.
설명
에이전트 주도 개발에서 요구사항 문서는 곧 PRD (Product Requirement Document) 역할을 하며, 이후 AI 에이전트에게 지침서로 제공된다.
경험상 초반의 요구사항 정의가 얼마나 구체적인지에 따라 이후 개발 속도와 방향이 크게 좌우된다.
불확실한 부분(변수)을 얼마나 상수처럼 명확하게 바꿔놓는지가 관건이며, RFTCR 프로세스에서도 이 단계에 충분한 시간을 투자해야 한다. 요구사항을 잘 정의해두면 이후 단계에서 AI가 혼동을 일으킬 여지를 줄이고, 사람 간 커뮤니케이션 부담도 줄어든다.
산출물
이 단계의 주요 산출물은 정형화된 요구사항 명세서(PRD)다. 일반적인 PRD보다 한 단계 진화한 문서로 볼 수 있는데, 비즈니스 요구뿐만 아니라 주요 기술 요구사항(TSD), 아키텍처 결정(ADR)도 함께 담긴 포괄적인 사양서다.
이렇게 하는 이유는 에이전트에게 맥락을 충분히 제공하여, 나중에 코드 생성 시 불필요한 질문이나 혼선을 줄이기 위함이다. 또한 프론트엔드/백엔드 등 여러 영역이 있다면 UI/UX 요구까지 포함해, 개발에 필요한 정보를 최대한 사전에 명시한다.
요구사항 단계에서 또 다른 중요한 점은 산출물의 표준화다. RFTCR를 적용하려면 PRD의 형식과 상세 수준이 일정 기준을 따라야 한다.
각 요구사항에는 식별자나 우선순위, 수용 기준(AC) 등이 명확히 표시되고, 문장도 애매모호함 없이 구체적으로 작성되어야 한다. 이렇게 해야 이후 단계(예: 기능 목록 도출 시)에서 AI나 사람이 혼선을 겪지 않는다.
만약 이 단계의 산출물이 사람마다 제각각이라면, 에이전트에게 올바른 프롬프트를 주기 어렵고 결국 결과도 들쭉날쭉할 것이다.
C4 모델이 아키텍처 다이어그램의 계층별 내용과 범위를 표준화하여 팀간 소통을 원활하게 하듯이, RFTCR의 요구사항 산출물도 일정한 추상화 레벨과 형식을 따라야 한다. 다음 단계인 기능 설계로 넘어갈 때, 이 명세서가 팀의 공통 언어 (DDD 로 치면 유비쿼터스 언어) 역할을 하도록 만드는 것이 이 단계의 목표다.
도구지원
요구사항 단계에서는 AI 기반의 PRD 작성 보조 도구[^1] 가 큰 도움이 된다. 예를 들어 AI가 자동으로 질문을 던져 기획자가 생각하지 못한 요구사항을 이끌어내고, 정해진 템플릿에 따라 문서를 완성해주는 에이전트 기반 툴을 활용할 수 있다.
일반적으로 PRD 는 어떤 질문을 해야 하는지 막막함과 어디까지 작성해야 충분한지 모호함 문제를 가지고 있다. 그리고 당연하게도 결과물은 작성자의 역량에 따라 편차가 너무 심하다.
AI 를 기반으로한 PRD 작성도구를 통해서, AI 가 문서작성의 주체가 되고 사용자가 답변을 하도록 책임을 역전 하면 작성사의 역량에 덜 영향을 받고, 항상 일정한 수준의 문서를 생성할 수 있게 된다.
또한 이 때, 문서의 템플릿을 고정함으로써 문서의 완료 기준이 명확해지고, 작성자의 숙련도에 따라 품질이 들쭉날쭉해지는 현상도 줄일 수 있다. 이처럼 PRD Writer와 같은 도구는 기획자에게는 체계적인 가이드가 되고, 개발자에게는 일관된 형태의 요구사항을 제공하여 이후 단계를 수월하게 한다.
나아가 PRD 작성 도구의 에이전트는 개발자의 관점도 일부 겸비하고 있어서, 설령 기획자가 기술 배경이 부족하더라도 최소한의 품질과 일관성을 유지해주는 장점이 있다.
2. 기능 단계 (Feature)
두 번째 단계는 추려낸 요구사항을 구현할 기능 단위로 묶고 설계하는 과정이다. 이 단계에서는 기획자와 개발자가 접점을 가지며 협업한다.
설명
요구사항 명세를 검토하면서, 관련된 요구사항들을 하나의 기능(Feature)이나 모듈로 그룹화하고, 각 기능에 대한 개략적인 설계를 도출한다. 여기서 말하는 설계란 상세한 코드 설계가 아니라, 그 기능을 만족시키기 위한 구성 요소와 동작 흐름을 정의하는 것이다.
마치 에픽(Epic)이나 사용자 스토리 수준에서 시스템의 동작을 서술하듯, 각 기능에 대해 “이 기능은 무엇을 하고 대략 어떻게 동작할 것이다”를 서술한다. 이를 통해 요구사항과 구현 간의 중간 다리를 놓는 셈이다.
산출물
주요 산출물은 각 기능별 기능 명세서 또는 기술 스펙이다.
만약 요구사항 단계에서 만든 PRD가 전체 프로젝트에 대한 상위 문서라면, 기능 단계에서는 그것을 쪼개어 여러 개의 하위 문서를 만드는 과정이라고 볼 수 있다.
실제 현업에서도 방대한 요구사항을 하나의 문서에 담지 않고, 도메인이나 기능별로 구분하여 여러 문서로 관리하는 것이 효율적이다.
RFTCR 프로세스에서는 요구사항 -> 기능 단계 전환 시 이러한 분할이 일어나며, 각 기능 문서는 특정 요구사항 집합을 구현하기 위한 청사진 역할을 한다.
예를 들어 “사용자 회원가입”이라는 기능에는 해당 기능과 관련된 요구사항(예: “이메일로 회원가입 가능해야 함”, “비밀번호 정책 준수” 등)을 모두 포함하고, 이를 충족시키기 위한 화면 흐름, API 개요, 데이터 모델 등의 설계 내용이 담길 수 있다.
개인적으로 가장 중요한 요소 중 하나는 수직적으로(Vertically sliced) 구성된 기능 명세라고 생각한다. 각 기능 명세는 이후 작업으로 변환되게 되는데, 다양한 팀의 토폴로지에 따라 자유롭게 사용되려면 레이어 형태의 수평적 기능 명세보다 수직적인 기능 명세가 유리하다. (예를 들면, 프론트엔드, 백엔드 팀이 나눠진 경우와 투피자 팀 같은 자율화된 팀 모두에서 공통적으로 사용하기 위함)
도구 지원
기능 단계에서는 기능 설계 보조 도구나 자동 스펙 생성기를 활용할 수 있다.
요구사항 문서를 입력하면 AI가 알아서 관련 요구들을 클러스터링해 기능 목록을 제안하고, 각 기능에 대한 설계 초안을 작성해주는 식이 될 것이다.
앞서 언급한 PRD가 여러 개의 문서로 나뉘는 과정도 에이전트를 활용해 자동화할 수 있다. 기능이 추가될 때마다 새로운 스펙 문서를 만들고 이를 최신 상태로 유지하는 작업을 에이전트에게 맡기는 것이 권장된다. 이를 위해 템플릿 기반으로 기능 문서를 생성하고, AI 리즈닝 모델로 문서의 모호한 부분을 검수한 뒤 보완하는 접근도 제안된다.
요컨대 Feature 단계의 도구는 요구사항을 입력받아 표준화된 기능 설계서들을 출력함으로써, 개발자가 바로 구현 계획을 세울 수 있는 발판을 제공한다. 이러한 도구는 기획자에게는 요구사항이 실제 구현 기능으로 맵핑되는 과정을 투명하게 보여주고, 개발자에게는 이후 태스크를 뽑아낼 수 있는 구조화된 자료를 제공한다.
기능 단계의 핵심은 요구사항을 구현 관점으로 재구조화하는 것이다. 이때 각 기능 설계는 너무 추상적이어도 안 되고, 너무 세세해서는 더 안 된다.
추상화 수준은 각 기능이 독립적으로 이해되고 개발 착수 결정을 할 정도면 충분하다. 만약 이 단계를 건너뛰고 바로 요구사항에서 태스크로 옮겨가면, 태스크들이 산발적으로 쏟아져 나와 개발 우선순위 설정이나 영향 범위 파악이 어려워진다.
기능 단위로 한 번 구조화해두면, “어느 기능부터 개발할 것인가”, “기능 간 의존성은 무엇인가”를 논의할 수 있고, 에이전트에게도 한 번에 한 기능씩 초점을 맞춰 개발하도록 지시할 수 있다.
이는 마치 C4 모델에서 Container 수준의 그림을 그려놓고 컴포넌트 작업으로 들어가는 것과 유사하다 - 큰 그림을 그린 후 세부 작업을 나누는 원리이다.
3. 태스크 단계 (Task)
각 기능을 실제로 구현하기 위한 세부 태스크를 도출하는 것이다. 여기서부터 개발자가 주도권을 가지며, 기획자는 보조적인 역할로 참여하거나 참여하지 않는 것이 권장된다.
설명
기능 명세서를 기반으로 “이 기능을 만들기 위해 어떤 일들이 수행되어야 하는가?”를 구체적인 작업 목록으로 정리한다.
태스크는 일반적으로 개발자 관점의 할 일 목록이며, 하나의 태스크는 하나의 함수 구현, 하나의 데이터베이스 변경, 또는 하나의 화면 구성처럼 작은 단위로 쪼개지는 것이 이상적이다.
이렇게 쪼갠 이유는, 각 태스크를 AI 에이전트가 한 번에 하나씩 처리할 수 있게 하여 오류 발생 시 그 범위(블라스트 반경)를 최소화하기 위함이다. 작은 단위로 격리하면 실패해도 영향이 제한적이고 디버깅이 쉽기 때문에, 시스템의 안정성이 높아진다.
실제로 잘 설계된 시스템은 장애가 발생해도 국소적인 영향에 그치도록 blast radius를 제한하는데, 장애를 AI 의 오동작으로 매핑하면, RFTCR의 태스크 분할 동일한 맥락으로 볼 수 있다.
산출물
주요 산출물은 정리된 태스크 목록이다. 이 목록은 우선순위, 예상 난이도, 담당자(사람 또는 에이전트), 그리고 태스크 별로 참조해야 할 세부 요구사항이나 설계 요소를 매핑해 놓은 형태일 것이다.
예를 들어 “회원가입 API 개발” 기능 내에 “DB에 사용자 테이블 생성”, “회원가입 API 엔드포인트 구현”, “입력값 유효성 검증 로직 추가” 등의 태스크들이 나열된다. (기능은 하나 이상의 유저스토리로 표현될 수 있으며 이 경우 기능 - 유저스토리 - 작업 의 구조를 가지게 된다.)
각 태스크는 가급적 독립적으로 실행 가능하도록 작성되어야 하며, 이를 위해서는 각 태스크간의 의존성을 파악하는 것이 필요하다. 태스크 간의 의존성을 알아야 병렬로 작업하거나 순차 진행 시에도 큰 간섭이 없도록 한다.
도구지원
태스크 단계에서는 태스크 매니저(Task Manager) 혹은 AI 태스크 플래너 도구가 활용될 수 있다.
이러한 도구는 기능 명세를 입력받아 자동으로 세부 작업들을 생성하거나, 개발자가 작성한 태스크 목록을 이해하여 다음 단계를 에이전트가 수행하기 쉽게 포맷팅해주는 역할을 한다.
예를 들어, Claude Taskmaster와 같은 전문화한 에이전트를 사용할 수 있다.
이 TaskManager 에이전트는 체인-오브-소트(chain-of-thought) 방식으로 “먼저 무엇을 하고, 다음에 무엇을 해야 하는지”를 단계별로 출력해주거나, 생성된 태스크들 사이의 의존 관계를 표시해준다.
태스크 단계의 중요 포인트는 세분화와 순서 결정이다. 태스크를 적절히 쪼개지 않으면 AI 코딩 단계에서 한 번에 너무 많은 것을 시도하게 되어 오류 가능성이 커진다. 반대로 지나치게 잘게 쪼개면 전체 맥락이 분산되어 효율이 떨어질 수 있다.
경험적으로는 “한 번에 하나의 기능에 대해 PR 하나 또는 커밋 하나를 만들 수 있을 정도”의 크기가 적당하다. 그리고 태스크 사이의 순서를 정해서 에이전트 작업 플로우를 설계해야 한다.
예컨대 데이터베이스 스키마 설정 태스크가 API 구현 태스크보다 먼저 실행되도록 순서를 배치하고, UI 개발 태스크는 API 완료 후에 진행하는 식이다. 이러한 순서도 AI에게 지시할 때 명시하거나, 또는 TaskMaster 에이전트가 자동으로 태스크 처리 순서를 관리하도록 할 수 있다.
이러한 태스크 단계는 개발자가 주도적으로 진행하며 코드와 밀접하므로, Cursor IDE 같은 에이전트 기반 IDE 와 MCP 형태로 제공될때 가장 효과적이다.
실제로 Claude TaskMaster 도 CLI 로 작성된 도구를 MCP 형태로 사용할 수 있게 함으로써 개발자들의 편의성을 극대화하고 있다.
4. 코드 단계 (Code)
네 번째 단계는 실제 코드 구현 단계이다. 개발자가 중심이 되어, 앞서 정리된 태스크들을 하나씩 처리하면서 코드를 작성한다.
설명
여기서 “개발자”는 인간 개발자와 AI 코딩 에이전트의 혼합된 형태라고 볼 수 있다.
RFTCR의 코드 단계는 전통적인 개발에서 코딩하는 것과 역할은 비슷하지만, 에이전트 주도 개발의 맥락에서는 AI가 코드를 생성하고 개발자는 이를 검토 및 수정하는 방식으로 진행된다.
즉, 각 태스크마다 개발자는 AI에게 프롬프트(맥락과 지시)를 주고 코드 생성을 요청하며, AI가 내놓은 코드를 리뷰하고 필요시 수정하거나 재프롬프트하는 과정을 거친다. 이 때 잘 준비된 이전 단계의 산출물들(PRD, 기능 설계, 태스크 정의)은 AI에게 정확한 컨텍스트를 제공하여, 가능한 한 처음부터 올바른 코드가 나오도록 돕는다.
산출물
주요 산출물은 말 그대로 소스 코드이다. 구현된 기능별로 코드가 작성되고, 버전 관리 시스템(git 등)에 커밋된다.
에이전트 개발 과정 전반은 에이전트 주도적으로 작성한 결과물이 더 신뢰할 수 있는 코드 가 되는 것과, 잘못된 코드를 에이전트 주도적으로 수정 시 더 적은 위험부담으로 코드를 수정 하는 데 목적을 두고 있다.
에이전트는 크게 두 종류의 컨텍스트(Static, Dynamic) 를 입력으로 받으며, 정적인 컨텍스트 정보(예: API 스펙, 데이터 모델, 비즈니스 규칙)는 이미 이전 단계 산출물에 충분히 있으므로, AI가 부정확한 상상력을 발휘할 여지를 줄이며, 디버깅시에도 무관한 코드를 보지 않고, 수정하지 않도록 가이드한다 .
예를 들어 “회원가입 API 엔드포인트 구현” 태스크를 수행할 때, 이전 단계의 기능 설계서에 “이메일 중복 검사 로직”이나 “비밀번호 해싱 방식”이 명시돼있다면, AI는 그 지침에 따라 코드를 바로 작성할 수 있으며, “비밀번호 변경 API” 와 관련된 코드 부분들은 수정하거나 참조하지 않을 가능성이 커진다.
만약 이런 명세가 없다면 AI는 추측으로 구현하거나, 코드베이스 전체를 읽은 뒤에 관련된 부분을 판단해서 코드를 작성하게 되며, 컨텍스트가 길어질수록 앞서 본 정보를 잊고 오작동할 가능성도 올라간다. 따라서 코드 단계 이전의 치밀한 준비가 코드 단계의 효율과 정확도를 결정한다고 해도 과언이 아니다.
도구 지원
코드 단계에서는 에이전틱 IDE 또는 코드 생성 에이전트의 도움이 절대적이다.
앞서 언급한 Cursor, Windsurf 등 다양한 에이전트 개발 도구들이 여기에 속한다.
이러한 도구는 IDE 환경에서 개발자 대신(혹은 보조하여) 코드를 생성하고, 대화형으로 수정 명령을 받아들이며, 필요한 경우 외부 문서를 참조해가며 코딩을 진행한다.
예를 들어, Cursor와 같은 에이전틱 IDE에서는 PRD, Rule 등의 주요 정적 컨텍스트를 미리 등록해두고, 에이전트 기능으로 “다음 태스크를 구현해줘”라고 지시하면 AI가 관련 코드를 작성해주는 시나리오가 가능하다.
개발자는 생성된 코드를 읽어보고 논리나 스타일을 검토하며, 부족한 부분은 추가 프롬프트를 통해 개선하거나 직접 수정한다. 또한 코드 단계에서는 버전 관리 통합 도구도 고려되는데, 에이전트가 너무나 많은 수정을 한번에 하는 경우, 그리고 그 수정이 잘못된 경우 돌아갈 수 있는 체크포인트를 git 을 통해서 만들어두는 것이 좋기 때문이다.
핵심은, 도구가 자동화를 제공하더라도 최종 의사결정은 개발자가 쥐고 있는 것이다. 에이전트의 코드 제안을 수용할지 말지, 어느 부분을 수정할지는 개발자의 판단이며, 이때 기획자는 산출물이 요구사항에 부합하는지 확인하는 데 집중한다. 에이전트가 코드를 이해하는 과정도 도와줄 수 있기 때문에, 이상적으로는 개발자가 이해하지 못한 어떠한 코드도 코드베이스에 반영하지 않는 것을 목표로 해야 한다.
코드 단계에서 중요한 것은 안정성과 일관성이다. 앞 단계에서 정의된 태스크 하나를 구현할 때, 해당 범위 이외의 코드는 변경하지 않도록 관리하는 것이 바람직하다.
예를 들어 “사용자 테이블 생성” 태스크를 수행하면서, 사용자와 무관한 다른 테이블에 영향을 주는 변경을 하면 안 된다. 이를 위해 자연스럽게 하나의 태스크 – 하나의 커밋 원칙을 따르게 되며, 에이전트도 그 범위를 벗어나지 않도록 프롬프트를 세심히 구성해야 한다. 이러한 원칙이 지켜지면 만약 버그나 문제가 생겨도 영향 범위(Blast Radius)가 작아져, 문제 해결에 걸리는 시간도 단축된다.
또한 코드 스타일이나 아키텍처 결정 사항은 프로젝트 전반에 일관되게 적용되어야 한다. 만약 에이전트가 일관성 없는 코드를 생성하면 오류 코드를 더 자주 생성하게 되기 때문이다. 실제로 에이전틱 IDE 에서는 린트가 대부분 활성화되어 있으며 에이전트는 가능하면 린트 에러도 항상 수정하려고 한다.
이를 위해 코딩 표준이나 아키텍처 원칙도 에이전트에게 규칙으로 제시될 수 있다 (예: “리포지토리 패턴을 따를 것”, “컨트롤러에서는 비즈니스 로직 최소화” 등). 결국 코드 단계는 RFTCR의 다른 모든 단계가 합쳐져 결실을 보는 단계이며, 잘 추상화되어 중복이 최소화된 정적/동적 컨텍스트를 에이전트에게 제공함으로써 에이전트가 안정적으로 코드를 생산해내는 것을 목표로 한다.
5. 리플렉션 단계 (Reflect)
다섯 번째이자 마지막 단계는 리플렉션(Reflect) 단계이다.
개발 과정과 생성된 코드를 기반으로 모든 정적 / 동적 컨텍스트를 업데이트 하는 과정이다. 이 과정을 통해 항상 모든 컨텍스트를 최신으로 유지하여, 이상적으로는 현재의 비즈니스 로직을 (코드단위가 아니라) 동일하게 생성할 수 있는 블루프린트(컨텍스트)를 코드베이스에 항상 유지하는 것을 목표로 한다.
도구 사용
물론 이 과정도 에이전트를 통해 진행되며, Cline MemoryBank 같은 도구들이 유용하다.
마치며
에이전트 주도 개발은 소프트웨어 엔지니어링의 새로운 지평을 열고 있다.
그러나 AI 에이전트의 능동적 참여가 아무리 혁신적이라도, 이를 이끌어가는 것은 여전히 사람의 몫이다. RFTCR 프레임워크는 사람(기획자와 개발자)이 AI를 효과적으로 통제하고 협업하기 위한 과정(Process)의 역할을 한다.
요구사항에서 코드에 이르는 다섯 단계의 명확한 가이드 레일을 제공함으로써, 우리는 AI의 창의성을 통제 가능한 형태로 끌어내고 비즈니스 가치를 정확히 실현하는 코드를 얻을 수 있다.
각 단계 산출물이 표준화되고 축적될수록 프로세스는 반복할수록 더 빨라지고 견고해질 것이다.
물론 RFTCR도 초기에는 팀의 문화 정착과 도구 지원의 미비 등 넘어야 할 산이 있을 수 있다. 그러나 애자일이나 DevOps가 그랬듯이, 한 번 효과를 체감하면 돌아가기 힘들 정도의 생산성 향상과 품질 안정화를 가져올 것이다.
중요한 것은 추상화 수준을 맞춘 올바른 도구의 조합과 팀원들의 합의된 작업 방식이다. 이를 갖춘 RFTCR 프로세스는 에이전트 시대의 소프트웨어 개발을 한층 표준화되고 예측 가능하며, 협업 친화적인 활동으로 만들어줄 것이다.