실습에서는?

문제 정의
    ↓
서비스 기획
    ↓
Sprint로 우선순위 결정
    ↓
API를 연결해 실제 동작 증명

1. 누구의 문제를 해결하는가?
2. AI가 그 문제를 어떻게 해결하는가?
3. 여러 기능 중 무엇을 먼저 만들 것인가?
4. 그 기능을 어떤 Microservice/API가 담당하는가?
5. 진짜 호출해서 동작하는가?

하면 안 되는 것

• Eureka 내부 코드 분석
• OAuth2 내부 구현 분석
• JWT 서명 알고리즘 분석
• JPA Mapping 전체 분석
• Kafka Producer/Consumer 코드 전체 분석
• Spring 코드 한 줄씩 읽기
• 화려한 프론트엔드 디자인

진정으로 해야 하는 것

MSA는 정답이 아니다.

신청 → 이벤트 발생 → 결제 → 상태 변경이라는 결과 흐름

STEP 1. 우리 팀 서비스의 고객을 하나 정하기

Pain Point 정의

이해관계자: 취업 교육을 제공하는 기업

기업은 교육생마다 어떤 강의를 추천해야 하는지 판단하기 어렵다.

교육생의 기존 수강 기록
교육생의 관심 직무
교육생의 학습 수준
    ↓
AI 분석
    ↓
다음 강의 추천

문서에서도 발표의 첫 번째 항목을 이해관계자의 Pain Point, 두 번째를 이를 해결하는 AI Solution

STEP 2. 기존 교육 플랫폼을 우리 도메인으로 치환

• 강사
• 과목
• 수강신청
• 결제
• 추천

STEP 3. Sprint 1을 딱 하나의 사용자 흐름으로 잡기

Walking Skeleton

사용자 로그인
    ↓
상품 조회
    ↓
상품 선택
    ↓
신청

로그인 → 상품 조회 → 신청이 100% 동작

Sprint 1에서는 회원, 과목, 수강신청으로 최소 기능 MVP를 완성하고 Sprint 2에서 결제와 이벤트 연동을 확장

왜 Sprint를 이렇게 나누는가?

이 기능이 없으면 사용자에게 가치가 전달되지 않는가?

YES라면 Sprint 1.

없어도 일단 서비스가 돌아가면 Sprint 2.

자료에서도 정확히 이 기준을 사용. 회원가입, 상품, 신청 같은 필수 기능은 Sprint 1에 두고, 결제 자동화와 이벤트 연동 같은 확장 기능은 Sprint 2로 미룬다

Sprint 1

• 로그인
• 상품 조회
• 신청

Sprint 2

• 결제
• Kafka 이벤트
• 상태 자동 변경
• AI 추천

STEP 4. 그다음 Swagger를 본다

우리 Flow에서 어떤 API가 필요한가?

Try it out
    ↓
Request 작성
    ↓
Execute
    ↓
Response 확인

• 아이디어 확정 및 Domain Mapping
• 필요한 API만 리스트업
• Swagger Try it out
• Frontend 연결
• Token 연결
• Sprint 2에서 결제 후 상태 변화 확인

API에서 네가 이해할 수준

POST /api/users/login

{
  "email": "test@test.com",
  "password": "1234"
}

{
  "token": "xxxxx"
}

로그인
    ↓
Token 획득
    ↓
sessionStorage 저장
    ↓
다른 API 호출
    ↓
Authorization: Bearer Token

STEP 5. Frontend에서 실제 API를 연결

[로그인 버튼]
    ↓ fetch
POST /api/users/login
    ↓
Token
    ↓
sessionStorage
    ↓
강의 조회 페이지
    ↓
GET /api/courses

자료에서도 Swagger에서 Method, Path, Request Body, Response를 확인하고 그대로 fetch로 옮기라고 안내

Sprint 1에서 나와야 하는 결과

로그인
    ↓
데이터 조회
    ↓
사용자가 항목 선택
    ↓
신청
    ↓
DB 상태 변경

즉 발표하면서 다음 내용을 보여줄 수 있어야 합니다.

여기 버튼 누르면 이렇게 됩니다.

코드 설명 20분보다 이 데모 30초가 훨씬 중요

Sprint 2에서는 무엇을 추가하는가?

사용자가 신청
    ↓
PENDING
    ↓
결제
    ↓
payment.completed
    ↓
Kafka
    ↓
enrollment-service
    ↓
APPROVED

결제 전: PENDING
    ↓
결제 수행
    ↓
결제 후: COMPLETED

상태가 실제로 바뀌었는가?

최종 결과물 6개

자료에 발표 산출물이 아주 명확하게 적혀 있습니다.

1. Pain Point

• 누가 무슨 문제를 겪고 있는가?

2. AI Solution

• AI가 그 문제를 어떻게 해결하는가?

3. Sprint 구분

그리고 왜 그렇게 나눴는가?

4. Architecture

Client
    ↓
Gateway
    ↓
A Service
    ↓
B Service
    ↓
Kafka
    ↓
C Service

5. API 명세

Request와 Response까지 정리합니다.

6. 동작 Screenshot / Demo

신청 전
    ↓
신청
    ↓
결제
    ↓
상태 변화
    ↓
추천 결과

교수님 문서도 발표 결과물을 정확히 이 여섯 단계로 요구하며, 왜 → 무엇을 → Sprint → Architecture/API → 실제 결과 순서로 논리가 이어져야 한다고 설명합니다.

그래서 내일 실제로 해야 할 순서

1. 팀 Pain Point 확정
2. AI가 제공할 가치 한 문장 정의
3. Domain Mapping 작성
4. 사용자 End-to-End Scenario 작성
5. Sprint 1, Sprint 2 분리
6. 필요 API 3~5개 선정
7. Swagger Try it out 성공
8. Frontend와 API 연결
9. Sprint 1 End-to-End Demo
10. Payment, Kafka, Recommend 확장
11. 통합 테스트
12. Screenshot, Architecture, API 명세 정리

서브노트

필요 API

POST /login
GET /courses
POST /enrollments