AI로 SaaS 만들기, 진짜 프로덕트엔 이 워크플로우 쓰더라

날짜:

AI로 SaaS 만들기, 프로토타입이 아니라 실제 프로덕트 수준에서 GPT-5.5·Codex·Composer 2.5를 역할별로 나눠 굴리는 워크플로우를 한 개발자가 공개했어.

배경: "장난감 MVP"는 졸업했는데 AI가 자꾸 방향을 잃어

이 개발자가 만드는 건 전문 어드바이저용 도메인 특화 SaaS야. 고객 관리, 시뮬레이션·계산 플로우, 리포팅, 장기 팔로업까지 들어가는 꽤 복잡한 제품이거든. MVP 단계를 넘어서자 문제가 생겼어. AI가 이전에 내린 결정, 아키텍처 제약, 왜 이렇게 짰는지 이유를 자꾸 까먹는 거야. 이걸 context decay(컨텍스트 소실) 라고 부르는데, 프로젝트가 커질수록 진짜 골치야.

AI로 SaaS 만들기에 쓴 툴과 역할 분리법

세 개 툴을 완전히 다른 역할로 쪼갰어.

  • GPT-5.5 → 전략 레이어. 아이디어 검토, 스프린트 설계, 프롬프트 엔지니어링 담당
  • Codex in Cursor → 코드 분석, 아키텍처 감사, 구현 서포트
  • Composer 2.5 → 실행 에이전트. 범위가 딱 정해진 코드 변경이나 UI 작업만 맡겨

그리고 한 번에 너무 많이 바꾸지 않아. 짧고 통제된 스프린트 단위로 움직여. 스프린트 프롬프트엔 컨텍스트, 범위, 검수 기준, 봐야 할 파일, 검증 단계까지 다 명시해서 넘겨.

컨텍스트 소실을 막으려고 AI 전용 문서를 레포 안에 유지해. AGENTS.md, 스프린트 로그, 의사결정 기록, 도메인 규칙, 기술 부채 목록, 로드맵까지. 큰 변경 전엔 AI한테 이 문서를 먼저 읽히고 시작해.

결과: 코드가 빨라진 게 아니라 아키텍처가 안 무너져

단순히 코드 생성 속도가 빨라진 게 아니야. 아키텍처가 서서히 망가지는 걸 막고, AI가 기존 결정을 존중하면서 작업하도록 만든 게 핵심 성과야. 리뷰 단계에서 변경 파일·추론·테스트 결과·리스크·문서 업데이트까지 AI가 내놓게 해서, 머지 여부를 본인이 직접 판단해.

따라할 수 있는 포인트

  1. AI 역할을 분리해 — 전략용·분석용·실행용을 다른 모델에게 맡겨
  2. 스프린트를 작게 잘라 — 한 번에 하나씩, 범위를 좁게
  3. 레포에 AI용 문서를 넣어 — 대화 기억 말고 파일로 컨텍스트를 관리해
  4. AI 출력물에 체크리스트를 요구해 — 변경 이유, 리스크, 테스트 결과까지

AI로 SaaS 만들기, 빠르게 짜는 게 목표가 아니라 오래 유지할 수 있는 시스템을 만드는 게 진짜 목표더라.

🔗 참고 링크

댓글

댓글 쓰기