인프런 커뮤니티 질문&답변
작성한 질문수
PRD 등의 문서 생성 시 의문점
작성
·
49
0
안녕하세요. 해당 PRD 생성 강의를 듣고 나서 세부적으로 깊은 질문이 몇 가지 생겨서 질문드리고자 합니다.
서브에이전트 문서를 여러 개 강사님께 받아서 진행했습니다. 다만 이전에도 질문 드린 적 있지만 세부적으로 프론트엔드, 백엔드, AI 등의 개인 프로젝트가 아닌 팀프로젝트 단위에서의 서브 에이전트 구성이나 이런 부분은 수강생이 스스로 학습해나가야 하는 부분도 있지만 어떤 식으로 만들어야 되고 참고하면 좋다라고는 말씀하셨지만 실질적으로 개인/팀 단위일 때의 에이전트 및 PRD가 어떤 식으로 차이가 나는 지 알고 싶습니다. (강사님께서 올려주신 소스 코드에 있는 것이 기본적인 틀이 될 수 있다는 점은 알겠지만 응용 단계에서 헷갈리는 부분이 발생한 부분입니다!)
PRD에 API, DB 구조 등이 들어가있어 약간의 틀로 보이는데 실제 대형 프로젝트 등을 진행했을 때에는 API, ERD 구조 및 각종 사용자/관리자 명세서 등을 일일이 구분해서 만들었던 경험이 있었습니다. 이러한 것을 세분화해서 각각 자세하게 만들지 않고 PRD 하나로 뭉쳤을 때의 장점 및 단점, 향후 저를 포함한 수강생들이 어떤 방향성을 가지고 활용을 하면 좋을 지 아직까지는 감이 잘 오지 않습니다 ㅠㅠ
답변 2
1
안녕하세요
질문 의도를 제가 정확히 파악한 건지 확신이 없어서, 이해한 대로 나눠서 답변드려볼게요.
질문 1) 개인 서브에이전트 vs 팀 서브에이전트 차이
솔직히 말씀드리면, "개인이냐 팀이냐"로 서브에이전트 구성이 달라지는 건 아니에요. 서브에이전트를 어떻게 구성할지는 "무엇을 만드느냐"와 "본인 역량"에 따라 달라집니다. 프론트만 하는 사람, 풀스택 하는 사람, AI까지 다루는 사람이 각각 필요한 에이전트가 다르겠죠. 팀이라고 특별히 다른 게 아니라 프로젝트 요구사항과 개인 역량에 맞춰 구성하시면 돼요. 참고로 저도 강의에서 말씀드린 방식대로 실제 작업을 진행하고 있습니다.
예를 들어 수영 애플리케이션을 만든다면 수영 도메인 관련 서브에이전트가 필요할 수 있고, Spring Framework로 개발한다면 Spring 관련 서브에이전트가 필요할 수 있어요. 이처럼 프로젝트 특성에 따라 자연스럽게 정해지는 부분입니다.
질문 2) 개인 PRD vs 팀 PRD 차이
이것도 마찬가지예요. PRD 형식이 개인/팀에 따라 정해진 게 아닙니다. 차이가 생기는 건 "누가 이 문서를 읽느냐"의 문제예요. 혼자 보는 문서는 본인이 이해하면 되고, 여러 명이 보는 문서는 다른 사람도 이해할 수 있게 써야 해요. 팀이라서 PRD가 달라지는 게 아니라, 협업 상황에서 자연스럽게 더 명확한 문서가 필요해지는 거죠.
이 강의에서 중요한 건 클로드 코드의 스펙을 학습하고 개발 워크플로우에 녹여내는 방법이에요. 만약 팀에 속해 계시다면 팀원들과 회의를 통해 구성을 정하시면 되고, 아직 팀이나 프로젝트가 정해지지 않은 상황이라면 지금 단계에서 미리 고민하실 필요는 없을 것 같아요
안녕하세요 🙂
결론부터 말씀드리면, 문서를 통합할지 분리할지는 정답이 없고 상황에 따라 다릅니다.
질문이 상황에 따라 방법이 다른 것들을 질문해 주셔서요. 이를 표준화해서 답변드리기가 어렵고, 그런 정확한 방법을 제가 알 고 있지 않으며 알게되어도 정말 그 범위가 방대하여 충분한 이해를 돕기위해서는 강의 1개 출시 분량이 나올 것 같아요.
저도 큰 프로젝트에서 협업(팀원 간 또는 타팀 간)을 해야 하는 경우에는 API, ERD뿐만 아니라 소스코드, 서버 인프라 등 다양한 문서를 쪼개서 관리하는 경험을 쌓았습니다. 하지만 스타트업에서는 효율과 빠른 피드백을 중요시하기에 그 반대로 하는 경우도 많았어요.
이 강의에서 중요한 건 클로드 코드의 스펙을 학습하고 이러한 스펙을 개발 워크플로우에 녹이는 방법이에요. 그리고 그 과정에서 프로젝트 구축을 위해 PRD, ROADMAP을 생성했는데요. 여기서 생성한 PRD는 말씀하신 것처럼 다양한 문서에서 관리되던 정보를 하나의 문서로 정리한 거예요. 그 이유는 하나의 문서로 관리해도 될 정도의 정보량이었고, 이 프로젝트는 혼자서 학습하며 개발하는 경우이기 때문입니다.
만약 정보가 많아져서 제대로 관리하고 싶다면 그때 분리하셔도 돼요.
그리고 이러한 문서 관리가 익숙하지 않으실 수 있어요. 당연한 거예요. 저도 익숙하지 않습니다. 실제 업무에서 개발할 때 대부분 이러한 문서를 개발자들이 직접 작성하지 않을 테니까요. 익숙하지 않은 게 당연한 거지 이상한 건 아닙니다.
만약에 지금 있는 회사에서 PRD를 아주아주아주아주 혹시라도 작성해야 하는 상황이 온다면 경험을 통해 익숙해지시면 돼요. 그리고 효과적으로 작성할 때 이 강의에서 배운 클로드 코드를 활용해서 문서에 작성할 정보를 수집하고, 계획하고, 작성 요청 등 다양한 작업을 진행하시면 됩니다.
0
안녕하세요, 인프런 AI 인턴입니다. 로로로도로로님.
클로드 코드의 PRD 생성과 관련하여 팀 프로젝트와 개인 프로젝트에서 어떻게 서브 에이전트를 구성해야 할지 궁금증을 가지신 것 같습니다. 여러 가지 다양한 상황에서 PRD 및 서브 에이전트를 어떻게 세분화하고 활용할지에 대한 문의는 아래 관련 답변을 통해 해결할 수 있습니다.
1. 개인 및 팀 프로젝트의 서브 에이전트 구성
강사님의 강의 내에서는 서브 에이전트를 사용하여 어떻게 프로젝트를 조직화할 수 있는지에 대한 지침이 제공됩니다. 특히, 팀 프로젝트는 개인 프로젝트와 달리 여러 사람의 협업이 필요하며, 서브 에이전트는 아래와 같이 조직화할 수 있습니다:
- 프론트엔드와 백엔드 에이전트의 분리: 각자의 역할에 맞추어 작업을 분담하며, 공통 모듈의 인터페이스나 API 명세에 대한 서브 에이전트를 따로 두어 효율성을 높일 수 있습니다.
- 자원 공유: 특정 자원(예: 공통 UI 컴포넌트, 데이터베이스 연결 등)을 별도의 서브 에이전트로 만들어 중복 코드를 줄이고 팀 내 표준화를 이룰 수 있습니다.
이와 관련하여 더 많은 예시와 설명을 얻고자 한다면, 기존 질문과 답변에서 유용한 인사이트를 얻을 수 있습니다:
2. PRD 하나에 모든 것을 포함했을 때의 장점 및 단점
대형 프로젝트에서 PRD 문서는 모든 기능 요구 사항, API 명세, 데이터 모델을 포함할 수 있습니다. 이를 통합 관리함으로써 얻을 수 있는 장점과 단점은 다음과 같습니다:
- 장점: 하나의 문서에서 전체 시스템을 이해할 수 있어 가시성과 추적성이 높아지며, 변경 사항을 통합 관리하여 일관성을 유지할 수 있습니다.
- 단점: 문서가 방대해짐에 따라 관리가 어려워질 수 있으며, 각 모듈이나 서비스의 독립성이 떨어질 수 있습니다. 이를 보완하기 위해서는 적절한 문서 구조와 카테고리화를 필요로 합니다.
PRD에 대한 방향성과 활용 방법에 대한 좀 더 구체적인 안내를 얻고 싶다면, 아래의 게시글도 참고하실 수 있습니다:
이 게시물이 PRD와 에이전트를 어떻게 잘 활용할 수 있을지에 대한 좋은 예시를 제공해줄 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
음 유동적으로 PRD를 변경해야된다는 건 알겠습니다. 그럼 이 답변을 참고해서 위의 질문과 했을 때 추가적인 정확한 의도를 담아서 추가적으로 질문 드리겠습니다!
PRD와 MVP ROADMAP 안에 API, ERD 명세서까지 포함되어서 매우 긴 문서가 나오는데 API, ERD 문서도 따로 뽑아내는 방식이 있는지 (보통의 프로젝트에서는 API, ERD, 기능 명세서를 따로 분리해서 뽑아내는 것으로 배웠고 지금까지 그렇게 해왔는데 하나의 문서로 통합해서 뽑는다는게 익숙하지 않아서 드는 의문입니다!)