생성형 AI에게 특정 기능을 만들어달라고 요청하면 바로 구현을 시작하기때문에, 기본적인 설계가 없다면 현재 프로젝트의 상황이나 개발중인 기능의 맥락을 따라가지 못하고 코드를 생성하게되는 경우가 많습니다.
그래서 PlanMode를 이용하여 코드를 실제로 변경하기 전에 먼저 분석하고 계획을 세우고 개발을 시작하는 방법을 사용합니다.
하지만 기능개발의 파이프라인과 규칙을 SKILL을 이용하여 정의해놓고, 이것을 이용하여 AI와 함께 토론하여 기획(설계)서를 만들고 기능 개발을 지시하면, 결과물을 좀 더 신뢰가능하고 기존코드에 잘 병합되도록 만들 수 있습니다.
전체 흐름은 다음과 같이 구성되어있습니다.

첫 단계에서는 오직 조사만 합니다, 이 단계의 핵심은 AI가 프로젝트의 컨텍스트를 이해하도록 하는 것입니다. 위의 항목들을 확인 후 정리하여 사용자에게 보고합니다, 사용자는 확인 후 다음 단계를 진행하도록 승인합니다.
사용자와 질의응답을 주고받으며 기획을 구체화하는 단계입니다, 대화를 통해 기능에 대한 합의를 이끌어내는 단계이며 질의응답->승인 단계를 반복하여 문서를 완성합니다.
사전 조사에서 수집한 정보를 바탕으로 핵심 목표와 선택지를 3가지 정도 사용자에게 제시합니다, 그 다음 구체적인 질문을 주고 받습니다. 한번 질문시에 3개 이하로 제한하여 사용자의 인지적 과부하를 줄입니다.

사용자의 답변을 받아서 설계 방향을 최신화하고 불분명한 부분에 대한 후속 질문을 이어갑니다, 사용자가 명시적으로 승인하지 않을경우 다음 단계로 넘어가지 않도록 합니다.

대화에서 합의된 내용을 바탕으로 PRD / Architecture / ADR 파일을 작성합니다.

PRD - 무엇을 만드는가(What)
기능에 대한 요구사항 문서입니다, 기능을 왜 만드는가를 설명합니다.
Architecture - 어떻게 만드는가(How)
기술 설계 문서입니다, PRD의 요구사항을 어떻게 구현할지 기술합니다.
ADR - 왜 그렇게 결정했는가(Why)
이전 토론에서 Trade-off가 있었던 부분들을 기록합니다, 이것은 나중에 구조 변경 시 기존의 의도를 잃지 않도록 하기 위함입니다.
문서의 핵심 내용과 구현 진행 순서를 요약하여 보고하고, 사용자가 수정 요청시 위의 단계로 돌아가 수정하고 재확인 합니다.
기능 개발을 하기 전 설계 문서 작성을 통해 AI가 잘못된 결과물을 만들거나, 무작정 리펙토링/구현 하는 것을 막을 수 있습니다.
AI시대를 지나면서, "얼마나 빨리 코드를 짜는가"의 가치가 점점 줄어들고, 설계 능력이 더 중요해지고 있습니다. 그리고 AI는 "잘 설계된 프로세스" 안에서 코드를 생성할 때 가장 강력합니다.