이 개발 방법론의 목표는 다음과 같다.

• 개인 사이드프로젝트를 실제 소프트웨어(SW) 회사의 개발 방식과 유사하게 운영
• 단순 기능 구현이 아닌 **제품 관점(Product Thinking)**을 기르기
• 포트폴리오 및 면접에서 **“실무에 바로 투입 가능한 개발자”**로 보이게 하기

이 방법론은 애자일(Scrum) 기반으로 진행하며, JIRA를 중심으로 관리한다.

전체 흐름:

1. 문제 정의 및 MVP 설정
2. JIRA Space 구성
3. Epic / Story / Task 설계
4. Sprint 기반 개발
5. Sprint Review & Retrospective
6. 반복 개선 및 확장

가장 먼저 다음 질문에 답한다.

• 이 프로젝트는 어떤 문제를 해결하는가?
• 사용자는 누구인가?
• 기존 방식의 불편함은 무엇인가?

예시: “여행 중 예약 정보와 일정을 자연어로 관리하기 어렵다”

MVP는 **“핵심 가치를 검증할 수 있는 최소 기능 집합”**이다.

MVP 정의 기준:

• 반드시 사용자가 실제로 사용할 수 있어야 한다
• 기술 데모가 아닌 사용 흐름이 완성되어야 한다

여행 AI Assistant 예시 MVP:

• 자연어로 일정/호텔 정보 입력
• AI가 intent를 파악
• Local DB에 저장
• 자연어 질문으로 정보 조회 가능

Scrum 프로젝트 선택

개인 프로젝트라도 Sprint 단위로 운영

• Sprint 기간: 1~2주
• 상태(Status): To Do / In Progress / Done

Epic은 큰 기능 단위 또는 목표이다.

예시 Epic:

• 여행 일정 AI Assistant MVP
• AI 고도화 및 안정성 개선

Story는 사용자 관점의 요구사항으로 작성한다.

Story 작성 규칙:

As a [사용자],
I want [무엇을],
so that [왜 필요한지]

예시:

• 사용자는 자연어로 여행 일정을 등록할 수 있다
• 사용자는 예약한 호텔 정보를 자연어로 조회할 수 있다

Story를 실제 개발 가능한 단위로 쪼갠다.

Task 예시:

• DB schema 설계
• AI API 연동
• 자연어 → intent 분류 로직 구현
• Frontend ↔ Backend API 연동

실무에서는 기능만큼 비기능 요구사항(비기능 Task)이 중요하다.

예시 비기능 Task:

• AI hallucination 방지 (조회 시 DB only)
• 응답 시간 3초 이내
• 잘못된 자연어 입력 예외 처리
• API Key 보안 처리

Sprint 시작 시:

• 이번 Sprint에서 완료할 Story 선정
• “Done의 기준” 명확히 정의

• 완벽보다 완료
• 기능 + 안정성 최소 기준 충족
• 필요하면 다음 Sprint로 이월

초기 MVP: 단일 intent만 처리

확장 단계:

• 한 문장에서 여러 intent 분리
• intent별 처리 후 결과 통합

예: “호텔 알려주고 내일 일정도 정리해줘”

AI는 결과 생성자이며, 진실의 원천(Source of Truth)은 DB이다.

• 조회는 DB 기반으로 수행
• AI는 해석, 요약, 사용자 프레젠테이션 역할만 수행

• 무엇을 만들었는지 시연
• 목표 대비 달성 여부 검토
• 실제로 사용 가능한지 확인

다음 질문을 기준으로 기록한다.

• Keep: 잘된 점
• Problem: 문제점
• Try: 다음 Sprint 개선점

예시

Problem: 멀티 intent 입력 시 응답 품질 저하

Try: intent 분리 로직을 AI 호출 전 단계로 이동

👉 JIRA 코멘트나 별도 문서로 기록하여 공유

이 방식으로 개발한 프로젝트는:

• 단순 토이 프로젝트 ❌
• 제품 개발 경험 ✅
• 애자일 + AI 활용 경험 ✅
• JIRA 실무 경험 ✅

면접에서 설명 예시:

“개인 프로젝트지만 실제 제품 팀과 유사하게 JIRA 기반 Scrum으로 운영하며 MVP → 개선 사이클을 반복했습니다.”

• 개인 프로젝트라도 항상 실무처럼 운영
• 결과물보다 과정과 판단 근거를 남긴다
• JIRA는 단순 관리 툴이 아니라 사고 방식의 증거다