1. 요구사항이 없는 게 아니라, “우리 스스로가 요구사항을 만들어내야 하는 상황”

• 실제 외부 클라이언트나 “정확히 정의된 사용자 집단”이 없더라도, 프로젝트 목적과 기능은 있습니다.
• 예: “GitHub 커밋을 분석하고, 포트폴리오를 자동 생성하는 기능”이 필수.
• 따라서 “요구사항이 전혀 없다”기보다는, 우리끼리 협의한 목표나 기능 리스트가 곧 요구사항 역할을 합니다.

팁: 처음에 “이 프로젝트로 해결하고 싶은 문제나 목표”를 큰 틀에서 정리하고, 이를 **내부 요구사항(팀이 원하는 기능)**으로 구체화하면 좋습니다.

• 예: “확장프로그램 UI로 GitHub Repo를 입력받고, 커밋/PR/이슈 등을 분석하여 Markdown 포트폴리오를 생성해주는 기능이 필요하다.”

2. 내부 팀이 곧 “제품 오너”이자 “사용자 스테이크홀더”

• Scrum 같은 Agile 방법론에선 흔히 “Product Owner(PO)”가 실제 고객을 대변해 요구사항 우선순위를 결정합니다.
• 이번 졸업작품에서는 우리 팀 내부에서 PO 역할을 맡아, “이런 기능이 중요하다”, “이 부분은 부가적이다” 등을 스스로 결정하면 됩니다.
• 교수님이나 심사위원을 잠재적인 “외부 피드백 제공자” 정도로 생각해서, 중간·최종 발표 시 받은 피드백을 Backlog에 반영해도 좋습니다.

3. 어떻게 개발 방법론을 적용할까?

3.1 Sprint(스프린트) / Iteration 설정

• 실제로는 외부 요구사항이 자주 바뀌진 않겠지만, 우리 팀 내부 아이디어도 진행하면서 달라질 수 있고, 교수님 지적이 들어오면 수정이 생깁니다.
• 따라서 1~2주 단위 스프린트나 이터레이션을 운영하는 “Scrum Lite(간소화된 스크럼)” 또는 “칸반(Kanban)식”도 고려할 수 있습니다.

3.2 백로그(Backlog) 대신 “팀 아이디어 보드” 운영

• 정식 “사용자 스토리” 대신, 구현해야 할 기능과 개선 아이디어를 Trello/Notion/Jira 등에 적어두고 우선순위를 매기면 됩니다.
• 예)
  • Must-have: GitHub API에서 커밋 가져오기, DB 저장, 포트폴리오 문서 생성.
  • Nice-to-have: AI 요약, UI/UX 개선, 추가 통계 시각화, 팀 단위 분석 등.
• 매 스프린트 초기에 “이 기능을 이번에 구현하자” 하고 작업 항목을 확정 → 진행 → 마무리 → 시연(팀 내부 시연).

3.3 일일/주간 회의(데일리 스탠드업) or 협업 툴