top of page

EP2. 기획자에게 PRD란 무엇일까? : Air Cloud의 PRD를 공유해드립니다.

  • Aieev
  • 7월 7일
  • 3분 분량

안녕하세요! AIEEV의 비즈니스 팀에서 서비스기획자로 열심히 성장 중인 윤아입니다. 🐥

지난 글에서는 Air Cloud의 기획 출발점과 핵심 기능 설정에 대한 고민을 담아 공유드렸는데요,

오늘은 그 다음 단계인 서비스 구체화와 실제 PRD 작성 과정에 대해 이야기해보려고 합니다.

“이게 진짜 고객이 원하는 기능일까?”

“지금 구현 가능한가? 그런데 이걸 안 하면 서비스가 안 되잖아...”

기획자라면 누구나 한 번쯤 겪는 이런 고민들, 저 역시 마찬가지였습니다. 이 글에서는 그런 고민들을 어떻게 해결해 나갔는지 모두 공유드리려 합니다.

이 글이 AI 모델을 구성·활용하는 스타트업 실무자분들, 그리고 서비스 흐름을 설계하는 기획자분들께 작은 참고와 공감이 되기를 바라며, Air Cloud가 실제 기능으로 구현되기까지의 기획 여정을 지금부터 풀어보겠습니다🙂


1. 서비스 구체화 : 사용자가 이 플랫폼을 실제로 어떻게 사용할까?

1탄에서 공유드린 것처럼, Air Cloud는 ‘초기 AI 스타트업/SME/개발자’의 GPU 클라우드 운영 Pain Point에서 출발한 서비스입니다. 앞선 페르소나 정의와 핵심 기능 도출 이후, 가장 먼저 고민한 건 “사용자가 이 플랫폼을 실제로 어떻게 사용할까?”였습니다.

고객 인터뷰를 통해 얻은 인사이트를 기반으로, DevOps 인력이 부족하거나, 클라우드 설정에 매우 익숙하지 않은 사람도 사용할 수 있도록 최대한 진입장벽이 낮은 사용 흐름을 설계하는 것을 목표로 하였습니다.

그래서 초기 기획 회의에서 다음과 같은 질문을 중심으로 사용자 흐름을 그려나갔습니다.

  • 처음 접속 시 어떤 정보부터 보여주는 것이 자연스러울까?

  • GPU 컨테이너를 배포하기까지 몇 단계를 거치면 부담이 없을까?

  • 과금과 관련된 정보를 어디에서 어떻게 보여줘야 할까?

이를 바탕으로 Onboarding → 컨테이너 설정 → 배포 완료 → 모니터링이라는 전체 시나리오를 도출하고, 각 단계에 필요한 UI 요소와 주요 기능을 정리했습니다. 개발/사업팀과 수차례 피드백을 하면서 아래와 같이 최종적으로 구성하였습니다.




최종적으로 설계한 정보 구조(Information Architecture)는 실제 개발에 반영될 수 있도록 문서화 작업을 수행했고, 각 페이지의 세부 Depth별 포함해야 할 정보와 기능을 정의했습니다.

이후에는 기획자 ↔ 개발자 간 원활한 커뮤니케이션을 위해 전달 문서의 포맷을 고도화하여 PRD(Product Requirements Document) 문서를 본격적으로 시작하게 됩니다!




  1. PRD 작성

PRD(Product Requirements Document)는 서비스 개발을 위한 기능 정의서로, 기획 의도와 기술 요구사항이 명확하게 전달될 수 있도록 구성하고자 노력하였습니다. 특히, 이번 PRD 작성 프로세스를 참고하기 좋은 글이 있습니다:

Air Cloud 역시 단순히 기능을 나열하기보다는, GPU 사용 고객들의 비용 효율성과 편의성 질문에서 출발한 제품이기 때문에, 해당 템플릿의 구조(Overview → Problem → Requirements → Success Metrics)는 실제 저희 PRD 작성에도 직접적인 참고가 되었습니다.

PRD의 각 기능은 구현 우선순위에 따라 다음과 같이 구분했습니다.

  • P0: 반드시 구현되어야 할 핵심 기능 (예: GPU 컨테이너 배포, Auto Scaling 설정, 실시간 모니터링)

  • P1: 구현되면 사용성이 크게 향상되는 기능 (예: 팀원 초대, 프로젝트 관리 기능)

  • P2: 현재는 제외되지만, 추후 업데이트 시 고려할 수 있는 기능 (예: 다중 리전 설정, API 키 암호화 설정)

  • P?: 구현 여부가 유동적인 기능 또는 실험적인 기능

정보구조(Information Architecture)에서 정의한 각 페이지 단위를 기준으로, 필요한 세부 기능들을 위 우선순위 체계에 따라 구체적으로 정리했습니다. IA는 단순 메뉴 구조가 아니라, 각 페이지에 어떤 기능과 정보가 배치되어야 하는지를 중심으로 작성하였고, 이 구조를 토대로 기획/개발/디자인팀와의 커뮤니케이션을 진행했습니다.

기획–디자인–개발 간 커뮤니케이션을 위해 Figma와 Notion을 함께 사용했고, 화면 단위로 주석(comment)을 달며 기획자의 의도를 명확하게 전달했습니다.

  • 빨강: 수정 요청 / 초록: 반영 완료

이렇게 시각적으로 표시하면서 피드백을 주고받고, PRD에서 정의된 기능에 대한 화면 흐름과 레이아웃을 지속적으로 개선해 나갔습니다.



PRD 작성 중에 느낀 가장 큰 고민은 정말 이 기능이 지금 필요한가?를 스스로에게 끊임없이 되묻는 것이었습니다. 기획 초반에는 기능을 최대한 많이 담고 싶었지만, 실제 개발 리소스는 한정되어 있었기 때문에 ‘무엇을 지금 구현하고, 무엇은 나중으로 미룰지’에 대한 결정이 필요했습니다.

예를 들어,

  • 실시간 지표 모니터링은 꼭 필요하지만, 과도한 커스터마이징 UI는 P2로 배정

  • GPU Saving Plan은 설계는 완료했지만, 정책 정리가 덜 되어 있어 P?로 유보함

이러한 판단을 빠르게 정리할 수 있었던 건, 고객 인터뷰 내용이 명확했기 때문이었습니다.

결국 PRD는 고객의 문장, 고객의 맥락에서 출발해야 진짜 살아있는 문서가 된다는 점을 다시 한 번 느낄 수 있었습니다.



3. 결론 : Air Cloud의 현재 기능은?

이러한 과정을 통해, 실제 출시된 Air Cloud에는 다음과 같은 흐름이 구현되어 있습니다.

  1. 진입장벽 최소화: 회원가입 후 즉시 기본 세팅 완료 → GPU 컨테이너 생성

  2. 5단계 배포 설계: 이미지 선택 → 환경 변수 입력 → 오토스케일링 여부 → 저장소 연동 → 배포

  3. Serving URL 제공: 외부 API 연동을 위한 URL 자동 생성

  4. 실시간 대시보드: GPU 사용률, 과금 예측, 성능 지표 등 시각화 제공

이를 통해 기술 인력이 부족한 초기 AI 스타트업도 DevOps 경험 없이 AI 모델을 배포하고, 성능/비용을 안정적으로 운영할 수 있는 구조를 갖추게 되었습니다.


4달간 많은 시행착오 끝에 탄생한 Air Cloud의 기획 과정을 공유해 보았습니다. 이 기획기를 통해 저처럼 기획자로서 고민 중이신 분들, 또는 AI 서비스를 준비 중인 스타트업 실무자분들에게 작은 도움이 되었기를 바랍니다.

지속적으로 AIEEV의 Air cloud는 다양한 CS를 반영하여 지속 고도화해 나갈 예정입니다. 제품도 저도 한 단계씩 성장해, 더 나은 모습으로 찾아뵐 수 있도록 앞으로도 노력하겠습니다 💪


이 글을 보시고 제가 기획에 참여한 Air Cloud를 사용해보시고 싶으신 고객분들에게는 2주 무료 PoC검증과 클라우드 최적화 컨설팅/교육을 제공하는 프로모션을 특별히 제공해드릴게요 !

10초안에 작성하시면, https://www.aieev.com/contact  하루 이내 개별적으로 연락을 드립니다.








Edited by Biz & Strategy Team

Author: Yuna

 
 
 

Comments


bottom of page