아카이브

최근에 전직장 멘토님과 이야기를 하면서, 전 직장에 AI 플로우가 도입되고 있다는 것을 알게되었다. 이야기 중에 PRD(Product Requirements)와 WRD(Work Requirement Document)를 먼저 정의해놓고 개발을 진행하신다는 이야기를 듣게 되면서, PRD와 WRD가 대체 무엇인지 그리고 이 두가지 문서를 사용하게 되면 어떤 이점들이 있는지 알아보고자 한다. 처음엔 에이전트에게 "기능 만들어줘"라고 입력하는 것으로만 기능 구현을 할 수 있었지만, 프로젝트가 커질수록 담고있어야하는 컨텍스트 크기 뿐만 아니라 기능에 대한 정의가 이전 대화 기록으로 남아있어 사용자는 기억하기 쉽지 않았다. 만약 컨텍스트가 초기화되면 이전 요청한 기능들을 다시 기억하게 해줘야하는 순간들도 생각보다 많다 ^,^.. AI가 앞에서 했던 맥락을 잊어버리거나, 같은 기능을 요청했는데 매번 다른 구조로 짜주거나, 토큰이 터져서 대화 자체가 중단되는 순간들도 빈번하다. AI 기반 개발 방식이 자리를 잡으면서, 프롬프트 한 줄로 코드를 생성하는 것 이상의 체계가 필요해졌다. 그 중심에 PRD(Product Requirements Document)와 WRD(Work Requirement Document)를 먼저 작성하고, 이를 기반으로 AI가 구현하게 만드는 흐름, 일명 "플로우(Flow)" 방식이 있다. 왜 이 방식이 사용되고 있을까? AI 코딩 도구가 처음 나왔을 때, 대부분의 사용법은 단순했다. 프롬프트로 함수 하나를 만들고, 수정하고, 반복하는 식이었다. 그런데 GPT-4 급의 모델이 대화 컨텍스트를 길게 유지하면서 더 복잡한 작업을 하게 되자, 기존 방식의 한계가 드러났다. AI에게 프로젝트 전체를 설명하려면 대화 초반부터 엄청난 토큰을 소모하게 된다. 매 세션마다 같은 배경을 반복 설명해야 하고, 맥락이 흐릿한 상태에서 생성된 코드는 전체 구조와 맞지 않는 경우가 많다. 그 대안으로 나온 것이 문서를 먼저 작성하고, 그 문서를 AI의 참고 자료로 삼는 방식이다. 소프트웨어 개발에서 PM이 작성하던 PRD의 개념을 AI 개발 워크플로우에 끌어들인 것이다. WRD는 그보다 한 단계 더 내려가서, 실제로 어떤 기능들을 만들 것인지를 정리한 문서다.

글을 시작하며 사내에서 백오피스 프론트엔드 프로젝트에 타입스크립트가 적용되면서 내부 컨벤션이 정의되며, 구조에 대해 한번 더 생각할 기회가 있었다. 이 과정에서 초기 사내 백오피스 프론트엔드 프로젝트의 폴더 구조는 아래와 같이 도메인 별 1:1 매핑되는 구조로 가져고 있었다. 프로젝트를 진행하다보니 이 구조가 기능 도메인이 점차 커질수록 많은 문제점을 야기한다는 것을 알게되었다. 위에 코드는 실제 프로젝트로 기존에 구성되어있던 구조이다. 초기에는 프로젝트 도메인 별로 구분이 되어있다는 느낌을 받으면서 직관적이고 모든 API는 api/ 폴더 안에, 그리고 모든 페이지를 구성하는 뷰(페이지)는 views/ 폴더 안으로 구성하면되니 일관성을 확보할 수 있었다. 다만 점차 프로젝트의 기능 별 도메인이 많아지면서 백오피스에서 관리해야하는 영역들이 많아지고 있음을 느꼈다. 그리고 이런 문제점들이 발생했다. 기능 별 도메인이 추가될 때마다 views 폴더 안에 관련 폴더를 만들어주고, api , components , composable 과 관련된 폴더들에서도 동일한 이름으로 만들어줘야한다. 이 과정에서 네이밍 규칙이나, lookAlike 라는 기능 도메인을 lookAlikeDomain 과 같이 자유분방한 이름으로 통일성이 지켜지지 않는 경우가 있다. components , util 과 같은 우리가 평소 쓸만한 폴더 명이 아니기도 하면서, 익숙하지 않기 때문이다. 기능이 2~30개 정도가 되면 한 views 폴더 안에서 해당 컴포넌트를 찾기 위해서 여러 파일들을 탐색해야하는 경우가 생기는데, 이 과정이 점점 오래 걸리기 시작한다. 기능을 수정할 때도 동일하다. views 폴더에서 컴포넌트로 이동을 했다가 또 views 파일로 이동을 하는 반복적인 과정들이 생긴다. 레이어(기술 중심) 폴더로 설계를 하다보니, 각 폴더를 "무엇을 하는가" 에 따라 분류하면서 낮은 응집도와 확장성, 그리고 네이밍 중복에 대한 문제가 발생한다. 어떻게 해결할 수 있을까? 처음 백오피스 구조를 살펴보면 여러 컴포넌트들과 컴포저블들은 궁극적으로 views 폴더 안에 존재하는 기능 도메인 파일을 위해 구성되는 여러 요소들이다. 이 목적성에 따라 views 를 기점으로, 그러니까 각 기능 별 도메인을 기준으로 폴더를 구성한다.