Agile 방법론 및 MSA 개발

컴퓨터 구조와는 다르게 사람은 뉴런으로 동작한다. 

클라우드가 나오면서 사람수준의 학습이 가능해지기 시작했다. -> 딥러닝이 생겨났고 

사람의 뇌를 흉내내는 것이 잘 작동하지 않다가, 사로나온 것이 딥러닝 (예측형 AI 가 생겨나기 시작) 

2017년도에 

말을 잘 알아듣고 흉내내는 건 잘 안 돼. 

딥러닝 방식의 한계가 있더라 어텐션 is all you need 라는 논문이 나옴. -> 통째로 삼키고 문법을 스스로 해서 2살 3살 때 중요한 것을 찍은 다음에 학습하는 거를 흉내내는 것. 이 나옴

이렇게 접근한 것이 -> 생성형 AI (예측형 ai + 생성형 ai )

이걸 구현할 때 잘 맞는 방법론이 agile 방법론이다.

 

1. Agile 개요

왜 필요한가

전통적인 방식. -> 요구사항이 setup 되어 있음. 이럴 땐 agile 쓰면 안됨. 
= waterfall (순차적인 방식)
요구사항이 변경되면 다시 가야된다. -> waterfall 단점

수율 = 양품이 나올 확률 
재료가 투입되면 양품이 나와야 파는데 그 확률 -> 제조 반도체에서는 제조 공장의 미세한 차이 온도변화 다 영향받음 하이닉스가 95다 되게 높은 편이다. 중국업체 75퍼야 25% 별로 아닌 거 같죠 이거 엄청 큼. 
그래서 셋업된 업무대로 그대로 해야된다. 이럴 떄는 agile 을 사용하면 안되는 것. 
근데 ai 서비스는 이해관계자에게 가치를 주기 위한 게 붙어. 그래서 이해관계자의 painpoint 가 계속 들어온다. 이걸 대응해주는 게 ai 서비스의 특성인데 그래서 요구사항 변경이 잦고 실험저긍로 만들어보고, 의미있으면 확산하는 형식의 개발 패턴이 반복적이다. 
mvp - > minimun viable product (최소 핵심 기능을 담은 프로덕트) 를 많이 만들게 됨. 
그렇기 때문에 agile 이 잘 맞는다. 

Agile이 필요한 상황은 요구사항 변동성이 크고, 빠른 피드백이 중요하며, 점진적 가치 전달이 필요한 경우다.
시장·고객 요구가 빠르게 변화해 초기에 요구사항을 100% 확정하기 어렵고, Waterfall은 후반 단계에서 결함이나 변경이 발견되면 수정 비용이 매우 크다는 점이 배경으로 제시된다.
Agile이 잘 맞는 상황은 신규 서비스·스타트업형 프로젝트, 출시 후 사용자 반응을 보며 방향을 조정해야 하는 제품, 기능 단위로 쪼개 순차 릴리즈할 수 있는 구조, PO와 개발팀 간 상시 커뮤니케이션이 가능한 협업 밀도 높은 소규모 팀이다.

Waterfall과 Agile의 차이는 다음과 같이 정리된다.

구분	Waterfall	Agile
개발 방식	순차적(설계→개발→테스트) 단계 진행	반복적·점진적(짧은 Sprint 단위 반복)
요구사항	초기에 상세히 확정, 변경 최소화 지향	지속적으로 수집·재우선순위화(Backlog)
고객 피드백	프로젝트 종료 시점에 주로 확인	매 Sprint마다 Review로 상시 확인
산출물 확인 시점	최종 단계에 통합 결과물 확인	매 Sprint마다 동작하는 Increment 확인
변경 대응	변경 비용이 크고 절차가 무거움	변경을 전제로 유연하게 재계획
팀 구조	역할별 분업, 문서 기반 전달	교차기능팀, 상시 협업·짧은 피드백 루프

 

도입 프로세스와 흔한 실패 패턴

Agile 도입은 현황 진단 → 파일럿팀 선정 → Sprint 0 준비 → 첫 Sprint 실행 → 확산·정착의 5단계 로드맵을 따른다. 핵심 원칙은 처음부터 전사 적용을 시도하지 않고, 전체 영향이 없는 단위(1~2개 소규모 팀)에서 시작해 검증한 뒤 성공 사례를 바탕으로 확산하는 것이다.

실제 적용 시 흔히 나타나는 문제와 대응 방안은 다음과 같다.

문제 상황	증상	대응 방안
무늬만 Agile	Sprint라는 이름만 쓰고 기존 Waterfall 방식 그대로 진행	이벤트·산출물을 형식이 아닌 목적에 맞게 실제로 운영
역할 겸직 병목	PO가 다른 업무와 겸직하여 의사결정이 지연	PO 전담 배치, 또는 일부 의사결정 권한을 팀에 위임
회고 없는 반복	Sprint만 반복하고 프로세스 개선이 없음	Retrospective 액션 아이템을 다음 Sprint에 반드시 반영
과도한 문서화	Waterfall식 문서 프로세스를 Agile과 병행 유지	꼭 필요한 산출물만 유지, 대화·시각화 중심으로 전환
진행상황 미가시화	Sprint Board 없이 진행 상태를 아무도 모름	Sprint Board·Burndown Chart로 매일 가시화

우리 팀의 Agile 전환 체크리스트는 시점별로 나뉜다. Sprint 0 이전에는 PO/SM/Dev 역할 확정, Definition of Done 초안 합의, Product Backlog 최소 10~15개 항목 확보 여부를 점검한다. Sprint 0에서는 Sprint Goal을 한 문장으로 정의했는지, Sprint Backlog(Task 단위)를 구성했는지, Sprint Board를 셋업했는지를 확인한다. 첫 Sprint 종료 후에는 Retrospective로 액션 아이템을 도출했는지, Velocity 기록을 시작했는지, 도출된 개선사항을 다음 계획에 반영했는지를 점검한다.

 

2. Scrum 핵심 요소

역할, 프로세스, 산출물

Scrum의 역할(Role)은 세 가지다.

• Product Owner는 제품 백로그 관리와 우선순위 결정, ROI 책임을 지고
• Scrum Master는 프로세스 촉진과 장애물 제거, 팀 보호를 담당하며,
• Development Team은 기능 설계·구현·테스트와 Increment 완성을 책임진다.
• Sprint는 Sprint Planning → Daily Scrum → Sprint Review → Retrospective 순으로 반복되는 프로세스다.

Scrum 산출물(Artifacts)은 세 가지로, 

• Product Backlog(제품에 필요한 모든 요구사항의 우선순위화된 목록, PO가 소유·관리하며 지속적으로 정제됨),
• Sprint Backlog(이번 Sprint에서 완료하기로 선택한 백로그 항목과 이를 구현하기 위한 Task 계획),
• Increment(Sprint 종료 시점까지 완료된 모든 백로그 항목의 합, '완료' 기준 충족 필요)다.
• Definition of Done은 Increment가 '완료'로 인정받기 위한 팀 공통 기준으로, 모의 프로젝트 실습에서도 실습 시작 전 합의가 필요하다.

이벤트별 실전 진행 가이드

이벤트권장 소요시간참석자핵심 아젠다

Sprint Planning	2시간(2주 Sprint 기준)	전체 팀	목표 합의 → Backlog 선택 → Task 분할
Daily Scrum	15분	Dev팀 + SM	어제 한 일 / 오늘 할 일 / 장애물 공유
Sprint Review	1시간	전체 + 이해관계자	동작하는 결과물 데모, 피드백 수집
Retrospective	45분	전체 팀	Keep / Problem / Try 회고

타임 박스(Timebox)를 정하고 지키는 것이 핵심이며, 논의가 길어지면 별도 회의로 분리해 해당 이벤트 시간을 지킨다.

2주 Sprint 캘린더 예시는 Day 1(Sprint Planning), Day 2~4·5~8(개발+Daily Scrum), Day 9(마무리+Daily Scrum), Day 10(Review+Retro) 구조를 가진다. 하루 일과는 09:30~09:45 Daily Scrum, 09:45~12:00 개발 집중, 14:00~17:00 개발 집중+Backlog Refinement, 17:00~17:15 Sprint Board 업데이트로 짜인다.

Daily Scrum 실전 대화는 "어제는 로그인 API 개발을 완료했고, 오늘은 토큰 갱신 로직을 진행합니다. 특별한 장애물은 없습니다"처럼 한 일·할 일·장애물을 짧게 공유하는 형식이다. 장애물이 언급되면(예: Kafka 연동 관련 논의 필요) Daily Scrum에서는 발견만 하고, 실제 논의는 종료 후 별도 시간에 진행하는 것이 원칙이다.

실무 SI 프로젝트에서는 Scrum 프로세스를 커스터마이징해 본격 실행 단계 전에 착수·준비 단계(Sprint #0)를 추가로 지원하는 Agile Delivery 공정으로 확장해서 쓴다.

3. User Story와 백로그

정의와 작성 원칙

요구사항이 구현 단위로 구체화되는 흐름은 비즈니스 요구 → Epic → User Story → Task 순이다. Product Backlog는 Epic/User Story 단위로 구성되며, Sprint에 들어온 User Story가 Task로 쪼개져 Sprint Backlog가 된다. 작성 템플릿은 "As a [사용자 유형], I want [원하는 기능/행동], So that [얻고자 하는 가치/이유]"이며, 예로 "As a 회원, I want 비밀번호를 재설정하고 싶다, So that 계정 접근 권한을 다시 얻을 수 있다"가 제시된다.

User Story 작성 원칙은 INVEST로 요약된다.

원칙의미

Independent	다른 스토리와 독립적으로 개발 가능
Negotiable	세부 구현은 협의 가능(계약이 아닌 대화)
Valuable	사용자 및 고객에게 명확한 가치 제공
Estimable	팀이 규모를 추정할 수 있을 정도로 명확
Small	한 Sprint 내 완료 가능한 크기
Testable	완료 여부를 검증할 수 있는 기준 존재

실전에서 얼마나 상세히 쓰는지는 시점마다 다르다. 백로그 초기 등록 시에는 제목+한 줄 가치 정도로 개략적으로 기록(Epic 수준)하고, Backlog Refinement 시점에는 Sprint 진입 후보로 좁혀지면 팀과 함께 세부 조건·인수기준을 논의하며, Sprint Planning 직전에는 INVEST 기준을 충족하도록 Task 분할이 가능한 수준까지 상세화한다. 필요 이상으로 앞서 상세화하지 않는 Just-in-time 원칙이 강조된다.

백로그 그루밍(Refinement)

백로그 그루밍은 Sprint 시작 전 제품 백로그 항목을 정리·구체화·우선순위화하는 사전 준비 활동이다. Sprint 중반 1회, 1시간 이내로 PO 필수 참석에 Dev팀 일부가 순환 참석하며, 목표는 다음 1~2 Sprint 분량의 Story를 'Ready' 상태로 유지하는 것이다. 진행 순서는 우선순위 재정렬(PO가 비즈니스 가치 기준으로 재검토) → 상위 항목 상세화(세부 조건·인수기준 논의) → INVEST 체크 → Story Point 추정(Planning Poker 등)이다.

Before/After 비교와 백로그 채우기 가이드

모호한 작성("로그인 기능 개발")은 누가·왜·완료 기준이 불명확해 팀마다 다르게 해석할 위험이 크다. INVEST를 적용하면 "As a 회원, I want 이메일/비밀번호로 로그인하고 싶다, So that 내 계정에 안전하게 접근할 수 있다"처럼 사용자·가치가 명확해지고, 인수 기준("올바른 이메일/비밀번호 입력 시 메인 화면으로 이동", "잘못된 정보 입력 시 오류 메시지 표시", "5회 연속 실패 시 계정 일시 잠금")까지 붙는다.

팀 Backlog를 채우는 실전 가이드는 다섯 단계다. 기능 브레인스토밍(Epic 단위로 큰 기능 덩어리 나열) → Epic을 User Story로 분해 → MoSCoW로 우선순위 태깅(Must/Should/Could/Won't) → 상위 10개 INVEST 체크 및 상세화 → Planning Poker로 Story Point 추정 순서다.

제품 백로그와 완료 기준

제품 백로그는 개발할 제품 요구사항인 User Story 집합이며 우선순위로 관리된다. User Story는 과거의 요구사항 명세와 달리, 개발자 입장이 아니라 사용자 관점에서 어떤 가치를 제공할 것인지 설명하는 방식이다. PO는 이 기능이 누구에게 어떤 가치를 제공하는지 설명하고, 개발자는 그 가치를 제공하기 위한 기술적 역할과 책임을 진다. 완료 기준(Definition of Done)과 인수 기준(Acceptance Criteria)은 User Story를 완료시키기 위한 조건 명세(Given, When, Then 형식)다. 요구사항 ≒ 사용자 스토리 ≒ 백로그 ≒ 일감이며, 팀이 일하는 근거와 모든 커뮤니케이션·성과 측정이 백로그를 중심으로 이뤄진다.

Release Planning

릴리즈 계획은 백로그의 우선순위에 기반해 제품의 출시 계획과 스프린트 일정을 수립하는 과정이다. 비즈니스 우선순위 정의(MoSCoW 기법 또는 사용자 행동 기법 참고) → Release Roadmap 수립(Release별 Epic 배치) → Sprint 일정 수립(Sprint 주기 결정, 보통 2~4주) 순으로 진행된다. 예를 들어 Product Backlog의 User Story들을 Must Have/Should Have/Could Have로 나눠 Release #1.0, #2.0에 배치하고, 각 Release를 다시 여러 Sprint(#1~#5 등)로 쪼갠다. 이해관계자와 공유하는 Release Plan에는 착수보고·Demo-day·통합Test·1차/2차 Release 같은 마일스톤과 Sprint별 주요 작업이 함께 표기된다.

Sprint Planning과 Daily Scrum(공정 관점)

Sprint Planning Meeting에서는 스프린트 목표를 수립하고, 목표에 필요한 제품 백로그를 선정한 뒤, 목표 달성을 위한 작업(Task/Activity)을 상세화한다. 개발팀 구성원은 각자의 역량에 따라 작업을 할당받고, Sprint 주기와 일감 크기를 고려해 완료 일정을 계획한 다음 팀원들과 Sprint Backlog 및 일정을 공유한다. 스크럼 팀은 주도적·자율적으로 일감을 선택하며, 작업량이 맞지 않으면 개발팀이 PO와 백로그 항목을 재협상할 수 있다. Sprint Planning 시간은 Sprint 주기(2~4주)에 따라 4~8시간을 넘지 않는 것이 원칙이다.

백로그 내용이 충분하지 않으면 PO와 함께 User Story를 먼저 구체화해야 한다. 예로 "HTML 편집 기능"이라는 같은 제목의 스토리라도 Definition of Done이 다르면(HTML5 지원+Tag 자동완성+저장 시 Syntax 체크 vs Preview 제공+Preview 시 HTML5 지원+Tag 자동 선제공) 서로 다른 Backlog Item으로 분리된다.

일일 스크럼(Daily Scrum)은 스크럼 팀의 집중도를 높이고 팀원 간 유대와 신뢰를 형성하는 것을 지원한다. 매일 같은 시간에 15분을 넘지 않게 진행하며, Time Box를 지키기 위해 서서 진행(Stand-Up Meeting)한다. 한 사람이 발언권을 독점하지 않고, 특정 이슈에 해결책 논의가 필요하면 별도 회의(SoS Meeting)를 요청한다.

4. 모의 프로젝트 소개(MSA 아키텍처)

2챕터(Day2)에 구현할 MSA 시스템의 핵심 컴포넌트는 인증서버(Auth), 유레카(Eureka), API Gateway, Kafka 기반 서비스다. 요청 흐름은 다음과 같다. ① Client가 API Gateway로 요청을 전송(모든 요청의 단일 진입점) → ② Gateway가 Eureka에서 대상 서비스 위치를 조회 후 라우팅 → ③ 인증이 필요한 요청은 인증서버에서 JWT 토큰을 검증 → ④ 비즈니스 서비스 처리 후 상태 변경 이벤트를 Kafka로 발행하면 다른 서비스가 비동기로 구독한다.

컴포넌트별 역할과 통신 방식은 다음과 같다.

컴포넌트역할통신 방식

인증서버(Auth)	로그인 처리, JWT 토큰 발급·검증	REST(동기)
Eureka	서비스 등록 및 위치 탐색(Discovery)	REST 등록, 클라이언트 조회
API Gateway	모든 요청의 진입점, 라우팅·인증 필터	REST(동기)
Kafka	서비스 간 이벤트 기반 비동기 통신	Producer/Consumer, Topic 기반

동기(REST)와 비동기(Kafka)의 선택 기준은 명확하다. 즉시 응답이 필요하면 REST를, 서비스 간 느슨한 결합과 이벤트 전파가 목적이면 Kafka를 사용한다.

Day1에서 작성한 User Story는 Day2 구현 컴포넌트로 그대로 이어진다. "As a 회원, I want 로그인하고 싶다"는 인증서버 API 구현으로, "As a 서비스, I want 다른 서비스를 찾고 싶다"는 Eureka 등록/조회 연동으로, "As a 사용자, I want 주문 상태 변경을 실시간으로 알고 싶다"는 Kafka 이벤트 발행/구독 구현으로 연결된다. Day1에 작성한 User Story의 인수 기준이 Day2 구현의 테스트 기준이 되므로, 인수 기준이 상세할수록 Day2 실습이 원활해진다.

5. 모의 프로젝트 가이드와 설계 실습

팀 구성과 역할 배분

역할은 Product Owner(1명, 팀 내 우선순위 결정 경험자 또는 자원자, User Story 우선순위 결정과 인수기준 확정 책임), Scrum Master(1명, 프로세스 진행을 도울 수 있는 인원, 타임박스 관리와 진행 촉진, 장애물 정리), Development Team(나머지 전원, Task 수행과 추정 참여, 상호 리뷰)으로 나뉜다. 역할은 실습 중 고정하지 않아도 되며, 다음 Sprint(Day2)에서는 다른 역할을 경험해보는 것이 권장된다.

담당 컴포넌트별 샘플 User Story 예시는 다음과 같다. 인증 관련은 "As a 회원, I want 이메일/비밀번호로 로그인하고 싶다, So that 내 계정에 접근할 수 있다", Gateway 관련은 "As a 시스템 운영자, I want 모든 요청이 Gateway를 거치게 하고 싶다, So that 인증을 한 곳에서 일관되게 처리할 수 있다", Kafka 관련은 "As a 사용자, I want 주문 상태 변경을 실시간 알림으로 받고 싶다, So that 진행 상황을 바로 알 수 있다"이다. 팀별로 담당 컴포넌트(인증서버/Eureka/Gateway/Kafka)별로 최소 2개 이상의 User Story를 작성한다.

가이드 세션은 팀 킥오프(10분, 역할 배분) → 도메인 이해(15분) → Epic 도출(15분, 컴포넌트 단위로 큰 기능 나열) → User Story 작성(15분, Epic별 최소 2개 이상) → 팀 내 리뷰(5분, INVEST 기준 상호 점검) 순서로 70분에 진행된다.

설계 실습: Sprint Planning과 Board 운영

설계 실습은 두 단계로 나뉜다. STEP 1(Sprint Planning 실습)에서는 팀별로 작성한 User Story에 Story Point를 부여하고 Sprint Backlog를 구성하며, Task 단위로 분할한다(예: "인증서버 API 구현", "Kafka 메시지 발행 구현"). STEP 2(Daily Scrum 시뮬레이션+Board 구성)에서는 Task를 칸반보드(To Do/In Progress/Done)에 배치하고 팀별 Daily Scrum 형식을 데모로 시연한 뒤 Day2 작업 분배를 논의한다.

Sprint Planning 실전 진행 순서는 목표 합의(20분, PO가 제안하고 팀이 합의) → Backlog 선택(30분, 우선순위 상위 항목 중 이번 Sprint에 넣을 것 선택) → Task 분할(50분) → 추정+배분(20분, 담당자·예상 소요시간 배분)이며, 실습에서는 이 시간 배분을 절반으로 축소해 총 60분 내외로 진행한다.

Task 분할과 Story Point 추정 예시는 다음과 같다.

User StoryTaskPoint

로그인 API 구현	인증서버 엔드포인트 개발	3
	JWT 토큰 발급 로직 구현	2
	단위 테스트 작성	1
Kafka 메시지 발행	주문 상태 변경 이벤트 Producer 구현	3
	Topic/Consumer 그룹 설정	2

Story Point는 절대적 시간이 아닌 상대적 난이도(피보나치 수열: 1, 2, 3, 5, 8 등)로 추정하며, 팀 내 기준을 먼저 합의해야 한다.

Sprint Board 운영과 Daily Scrum 시나리오 예시는 칸반보드에 "Kafka Topic 설정", "단위 테스트 작성"은 To Do에, "로그인 API 구현", "JWT 토큰 로직"은 In Progress에, "Gateway 라우팅 설정"은 Done에 배치하고, "어제 Gateway 라우팅 설정을 완료해서 Done으로 옮겼습니다. 오늘은 로그인 API 구현을 시작하는데, JWT 관련 라이브러리 버전 확인이 필요해서 In Progress에 유지하겠습니다" 같은 대화로 진행된다.

실행 로드맵과 마무리

Day1에서 만든 산출물이 실제로 어떻게 실행되는지는 백로그 도출 → Sprint 분할 → Scrum 진행의 세 단계로 연결된다. Day1(Sprint 0)에서는 Epic → User Story 작성, MoSCoW 우선순위화, Story Point 추정으로 Product Backlog를 확정하고, Day1→Day2 경계에서 확정된 Backlog를 Sprint 단위로 나눠 Sprint Goal/Backlog를 확정(Sprint Planning)하며, Day2(Sprint 1)에서는 Sprint Backlog를 기준으로 Daily Scrum → 구현 → Sprint Review(데모) → Retrospective 순으로 실행한다. Day1에서 완성한 Sprint Backlog가 Day2 MSA 개발 실습의 기반이 된다.

마지막으로 Agile 적용이 실패하는 사유로는 Agile의 가치와 철학을 실현하려는 조직·팀의 의지와 지원 부족이 꼽히며(State of Agile Report 2016, 2018 인용), Agile을 제대로 적용하려면 자율적이고 주도적인 팀 구성이 필요하다는 점이 Boss와 Leader의 차이에 비유되어 마무리된다.