1주차
팀 구성 및 애자일 특강과 멘토링 진행에 관한 이야기를 좀 해보려고 합니다.
# 📘 [마스터 노트] 소프트웨어 개발 방법론 ABC & 애자일 실전 가이드
본 노트는 SK(주) AX 전사 방법론 담당 한정헌 아키텍트의 '개발 방법론 ABC' 강의 전체 내용을 완벽 정리한 자료입니다.
## 01. 개발 프로세스 기초 & AI 시대의 변화
### 1. 개발 프로세스의 본질
정의: 소프트웨어를 함께 만들 때 필요한 공통의 룰이자, 여러 명이 협업할 때 필요한 표준화된 일하는 방식입니다. 소프트웨어 개발의 구조를 잡아주는 기초 뼈대 역할을 합니다.
기술 트렌드 vs 개발 프로세스
빠르게 변하는 것: 언어, 프레임워크, 클라우드 서비스, AI 도구 및 라이브러리.
잘 안 변하는 것 (본질)**: 분석, 설계, 개발, 테스트로 이어지는 기초 체계와 협업 방식, 코드 리뷰 및 요구사항·테스트 원칙.
핵심: 좋은 프로세스를 아는 개발자는 새로운 기술이 나와도 빠르게 적응할 수 있습니다.
### 2. AI 도입 후 팀 개발이 무너지는 4가지 패턴
> 💡 생산성 도구의 역설: AI는 개인의 타이핑 속도를 높여주지만, 프로세스가 부재한 팀의 방향성까지 보장하지는 않으며 오히려 혼란을 증폭시킵니다.
01) 방향 충돌 (Direction Drift): 팀원들이 각자 AI에게 요구사항을 다른 해석으로 주입하면, AI는 각자의 버전을 최선으로 구현합니다. 결국 결과물을 합칠 때 치명적인 충돌이 발생합니다.
02) 중복 개발 (Duplication): 팀원 간 백로그(할 일 목록)가 실시간으로 공유되지 않으면, 팀원 A가 이틀 동안 고생해서 만든 기능을 팀원 B가 전혀 모른 채 처음부터 다시 개발하는 낭비가 발생합니다.
03) 기술부채 폭발 (Tech Debt Surge): AI가 생성한 코드는 개별적으로 빠를지 몰라도 전체적인 일관성이 떨어집니다. 팀의 명확한 아키텍처 기준 없이 마구잡이로 합치면 유지보수가 불가능한 코드가 됩니다.
04) 책임 공백 (Accountability Gap): 문제가 생겼을 때 "AI가 만든 거라 저는 잘 모릅니다"라며 코드의 소유자가 사라집니다. 버그 발생 시 아무도 전체 시스템 구조를 이해하지 못하는 블랙박스 상태가 됩니다.
### 3. 통계 데이터로 보는 현실
45%: AI 생성 코드에서 발견된 품질 및 보안 결함 비율 (GitClear 2024).
31%: AI가 전격 도입된 후에도 변하지 않는 소프트웨어 프로젝트 성공률 (CHAOS Report 2023).
80%: SDLC(개발 생명주기) 실패의 80%는 단순 코딩 단계가 아닌, 코딩 이후의 분석·설계·테스트·조율 단계에서 발생 (Harness Survey 2025).
### 4. 개발자 역할의 대전환 (Before & After)
전통적 개발자 (BEFORE): 요구사항을 수동적으로 받아 코드를 직접 작성하는 사람, 언어·프레임워크 문법을 암기하고 숙달하여 Stack Overflow 검색으로 문제를 해결하던 '구현자' (생산성 = 분당 타이핑 속도).
AI 시대의 개발자 (AFTER):
Spec Writer: AI에게 비즈니스의 정확한 의도와 맥락을 전달하는 정밀한 명세 작성자.
Orchestrator: 여러 AI 에이전트의 작업 흐름(Workflow)을 유기적으로 설계하고 조율하는 사람.
Reviewer / Architect: AI가 생성한 결과물의 품질, 보안, 일관성을 최종 검증하고 시스템 전체 구조와 인터페이스 계약을 설계하는 자.
Judgment Caller: 기술의 트레이드오프(장단점)와 릴리즈 기준을 최종적으로 판단하고 책임을 지는 사람.
실무 트렌드:
Harness Engineering 사례: 단 3명의 개발자가 AI를 활용해 100만 줄의 코드를 생산하였으며, 인간 개발자는 환경 설계, 검증, 방향 설정만 담당.
AWS의 AI-DLC (AI-Driven Development Lifecycle): 기존 SDLC를 AI-native하게 전면 재설계한 방법론으로, AI가 스펙을 받아 계획·구현·검증을 주도하고 인간은 승인과 최종 판단만 내리는 'Spec-Driven' 방식이 핵심 역량으로 부상 중입니다.
---
## 02. 전통적 관리 프로세스 (Waterfall 모델)
### 1. 프로젝트 관리의 4대 제약요소 (Iron Cross)
4대 요소: 일정(Time), 품질(Quality), 범위(Scope), 비용(Cost).
상호 작용: 네 가지 요소는 독립적이지 않고 철저한 트레이드오프(Trade-off) 관계에 있어, 하나를 무리하게 줄이거나 늘리면 반드시 다른 요소가 희생됩니다.
범위가 늘어나면 일정과 비용이 증가하고, 일정을 억지로 당기면 품질이 가장 먼저 파괴됩니다.
### 2. 폭포수(Waterfall) 모델의 본질
특징: 위에서 아래로 물이 흐르듯 분석 → 설계 → 개발 → 테스트 → 배포 및 유지보수 단계가 엄격하게 순차적·단계적으로 진행됩니다.
진행 원칙: 이전 단계의 산출물이 다음 단계의 기초 입력물이 되며, 각 단계가 완벽히 종료되고 검증(Progress Review)을 통과해야만 다음 단계로 진입할 수 있습니다.
장점: 구조가 명확하여 관리가 용이하고, 단계별 산출물이 철저히 남으므로 책임 소재가 분명하며, 초기 예측 가능성이 높습니다.
단점: 초기에 수집한 요구사항에 오류가 있을 경우 후반부 테스트 단계에서 발견되어 전체를 뜯어고치는 재작업 비용이 폭증합니다. 또한, 프로젝트가 완전히 끝나기 전까지는 고객이 직접 만져보고 동작하는 시스템이 존재하지 않습니다.
적합한 상황: 요구사항이 명확히 고정되어 변경이 거의 없는 프로젝트, 정부·공공기관 등 세부 산출물 문서가 계약상 필수적이거나 엄격한 규제 및 인증이 필요한 대규모 도메인.
### 3. 진척관리의 함정: '80% 완료'의 착시
문제점: 워터폴 진척관리는 구두 보고와 작업자의 '믿음·의지치'에 의존하기 때문에 심각한 착시를 유발합니다.
"80% 다 됐어요" 보고의 실제 내막 예시:
개발자가 10개 기능 중 9개를 건드렸다고 생각하여 80% 진척률을 보고하지만, 실제 확인해 보면 다음과 같은 상태인 경우가 많습니다(이를 죽음의 행진 - Death March라 부름).
5개: 코드는 작성되었으나 테스트가 전혀 안 됨.
2개: 화면 레이아웃만 나왔고 백엔드 API 연동이 미완성됨.
2개: 외부 API 연동 대기 상태로 작업이 차단됨.
1개: 아예 손도 못 댐.
결론: 서류상, 구두상으로는 순항하는 것처럼 보이지만 프로젝트 막판 테스트 단계에서 연동 오류와 미완성 기능이 쏟아지며 마감이 붕괴됩니다.
### 4. 워터폴 WBS (Work Breakdown Structure) 실무 예시
| 코드 | 작업 항목 | 담당자 | 시작일 | 종료일 | 핵심 산출물 |
| 1.0 | 프로젝트 착수 | PM | 03-24 | 03-27 | Kick-off 회의록, 요구사항 리스트 |
| 2.1 | 요구사항 분석 | BA | 03-28 | 04-01 | 기능 정의서, 유스케이스 명세서 |
| 2.2 | 시스템 아키텍처 설계 | 아키텍트 | 04-02 | 04-06 | 아키텍처 다이어그램, DB 설계서 |
| 2.3 | UI/UX 설계 | 디자이너 | 04-02 | 04-07 | 와이어프레임, 프로토타입 |
| 3.1 | 프론트엔드 개발 | FE 개발자 | 04-08 | 04-18 | 화면 소스코드, UI 문서 |
| 3.2 | 백엔드 개발 | BE 개발자 | 04-08 | 04-19 | API 소스코드, DB 연결체 |
| 3.3 | 시스템 통합 개발 | 개발팀 전원 | 04-20 | 04-23 | 연동 및 통합 완료된 시스템 |
| 4.1 | 단위 테스트 | QA | 04-24 | 04-26 | 테스트 결과 리포트 |
| 4.2 | 통합 테스트 | QA | 04-27 | 04-29 | 통합 테스트 보고서 |
| 5.1 | 운영 서버 배포 | DevOps | 05-03 | 05-04 | 가동 중인 운영 서버 시스템 |
| 5.2 | 프로젝트 종료 보고 | PM | 05-05 | 05-06 | 최종 종료 보고서, 회고 정리 |
---
## 03. 애자일(Agile) & 스크럼(Scrum) 핵심 전략
### 1. 왜 애자일인가? 데이터 기반의 범위 조절
전통적 방식의 한계: 요구사항을 모르는데도 의지와 희망사항만으로 초기에 분석 2달, 설계 2달 식으로 근거 없는 뼈대를 잡고 일정을 고정합니다.
애자일의 접근법: 소프트웨어 개발의 불확실성을 100% 인정합니다. 비즈니스 출시 일정(Time), 예산(Cost), 품질(Quality)은 타협할 수 없는 고정 값으로 두고, 대신 기능의 범위(Scope)를 전략적으로 유연하게 조정하며 대응합니다.
파레토 법칙 (80/20 법칙): 제품의 핵심 기능 20%가 전체 비즈니스 가치의 80%를 만들어 냅니다. 애자일은 이 핵심 20%를 먼저 완벽히 완성(100% 완료)하여 시장에 내보내고, 나머지 우선순위가 낮은 기능은 다음 스프린트 데이터에 따라 순차적으로 구현하거나 과감히 쳐냅니다.
### 2. 애자일 선언문 (Agile Manifesto, 2001)
> 💡 2001년 미국 유타주 스노우버드 리조트에 모인 세계적인 개발 전문가 17명이 워터폴의 구조적 실패를 타파하기 위해 정립한 4대 핵심 가치입니다.
1. 프로세스와 도구보다 ➡️ 개인과 상호 작용을!
2. 포괄적인 문서보다 ➡️ 작동하는 소프트웨어를!
3. 계약에 대한 협상보다 ➡️ 고객과의 협력을!
4. 계획을 고수하기보다 ➡️ 변화에 대응하기를!
왼쪽의 항목도 가치가 있지만, 애자일은 오른쪽의 항목에 더 높은 가치를 둡니다.
12대 원칙 핵심**: 짧은 주기마다 결과물 출시, 팀의 자율성 보장, 현업과 개발자의 지속적 협업, 단순성 추구, 번아웃 방지를 위한 지속 가능한 속도(Sustainable Pace) 유지.
### 3. 신뢰와 책임을 위한 권리장전
애자일의 자율성은 무책임한 방임이 아닙니다. 권리와 책임을 동등하게 부여합니다.
고객 권리장전: 전체 계획(무엇을, 언제, 얼마에)을 명확히 알 권리, 매 반복주기마다 작동하는 시스템으로 진척도를 검증하고 가치를 얻을 권리, 과도한 비용 추가 없이 우선순위를 바꿀 권리, 언제든 프로젝트를 취소할 권리.
개발자 권리장전**: 명확한 우선순위가 담긴 요구사항을 요구할 권리, 언제나 높은 품질의 결과물을 만들 권리, 동료나 고객에게 도움을 요청할 권리, 자신만의 작업 추정치를 스스로 만들고 갱신할 권리, 할당된 업무를 거절하거나 수락할 권리.
⚠️ 주의: 개발자가 업무를 '수락'한 순간부터는 전문가로서 끝까지 완수해야 할 책임을 집니다.
### 4. 스크럼(Scrum) 프레임워크 3대 철학
반복 (Iteration): 2~4주 단위의 짧은 스프린트를 돌며 제품 기능을 완성하고 즉시 피드백을 수용합니다.
협업 (Collaboration): '내 일, 네 일'의 경계를 허물고 팀 전체의 목표 달성을 최우선으로 삼으며 투명하게 소통합니다.
적응 (Inspect & Adapt): 작업 결과를 끊임없이 점검하고, 데일리 스크럼·리뷰·회고를 통해 발견된 문제점을 다음 주기에 즉시 반영하여 체질을 개선합니다.
---
## 04. 프로덕트 백로그 & 스프린트 계획 수립
### 1. 프로덕트 백로그 (Product Backlog) 관리
개념: 프로젝트 전체에서 구현해야 할 모든 기능, 개선 사항, 아이디어, 버그 리포트를 담은 리스트입니다. 고정된 문서가 아니라 시장 상황과 피드백에 따라 실시간으로 수정되는 살아있는 문서입니다.
핵심 규칙: 백로그의 모든 항목에는 반드시 우선순위(High / Medium / Low)가 매겨져 있어야 하며, 가치가 높은 기능이 항상 상단에 위치해야 합니다.
### 2. 사용자 스토리 (User Story) 작성 표준
단순 기능 나열식 기획을 지양하고, 누구에게 어떤 가치를 주는지 목적성을 명확히 정의합니다.
표준 템플릿:
[사용자 역할]로서, [어떤 기능/목표]를 하여, [어떤 이익/가치]를 얻고 싶다.
(As a <role>, I want <goal>, So that <benefit>)
실무 작성 예시:
`[화물 차주]`로서 `[운송하는 구간의 오더를 받기 위해]` `[본인의 주 운송 구간을 등록]`하기를 원한다.
스토리 필수 포함 항목: 구체적 설명, 우선순위, 추정치(Story Points), 수락 조건(Acceptance Criteria / 완료 기준).
### 3. 스토리 포인트 추정 (Estimation) 및 기법
작업의 절대적 시간을 예측하지 않습니다. 작업의 소요 시간은 개발자의 숙련도와 환경에 따라 다르기 때문에, 팀 전체가 느끼는 '상대적 복잡도 + 노력의 양 + 리스크'를 기준으로 삼습니다.
피보나치 수열 (1, 2, 3, 5, 8, 13, 21, ∞): 숫자가 커질수록 불확실성이 커짐을 표현합니다.
추정 기법 01 - T-shirt 기법: 빠른 초기 분류를 위해 XS, S, M, L, XL, XXL 크기로 일의 덩어리를 나눕니다. 모두에게 익숙한 기본 작업을 M(예: 3pt)으로 잡고 나머지를 상대 비교합니다.
추정 기법 02 - 플래닝 포커 (Planning Poker): 팀원들이 각자 생각하는 포인트 카드를 숨겼다가 동시에 오픈하여 특정 개인에게 편향되는 것을 막습니다. 만약 개발자 A는 2pt, 개발자 B는 8pt를 냈다면 평균을 내지 않고 "왜 서로 다르게 생각했는지" 심층 토론을 진행합니다. 이 대화 과정에서 기획의 구멍과 예외 케이스가 완벽히 도출됩니다.
### 4. 스프린트 계획 수립 (Sprint Planning)
스프린트 주기: 통상 2주 기간을 강력히 권장합니다. (1주는 소규모 팀의 빠른 피드백, 3~4주는 대규모 기능 및 복잡 도메인에 적합)
계획 메커니즘: 기획자(PO)가 이번 스프린트에서 달성할 명확한 스프린트 목표(Sprint Goal)를 제안하면, 개발팀은 정제된 프로덕트 백로그의 상단(고우선순위)부터 팀의 평균 속도가 허용하는 범위까지만 스프린트 백로그로 끌고 옵니다.
### 5. 속도 (Velocity) 기반의 일정 예측
정의: 팀이 한 스프린트(2주) 동안 완벽하게 '완료'한 스토리 포인트의 합산 수치입니다. 희망 회로가 아닌 철저히 '과거 실적 데이터'를 기반으로 합니다.
예측 공식:
전체 프로덕트 백로그 남은 포인트 ÷ 팀의 평균 속도 = 필요한 스프린트 수
⚠️ 철칙: 경험상 3~4회 스프린트를 수행한 후에야 속도 데이터가 유의미한 신뢰도를 가집니다. 또한, Velocity는 팀의 고유 성향 데이터이므로 절대 개발자 개인 평가용이나 타 팀과의 비교 목적으로 악용해서는 안 됩니다.
---
## 05. 스프린트 실행 및 스크럼 미팅 (Scrum Events)
### 1. 태스크 분해 (Task Breakdown)
스프린트 계획 단계에서 가져온 하나의 유저 스토리를 그대로 보드에 두면 진척 관리가 안 됩니다. 개발팀은 이를 시간 단위(h)로 세부 태스크(Task)로 잘게 쪼개야 합니다.
쪼개는 이유: 당장 오늘 아침에 무엇부터 시작할지 명확해지고, 스크럼 마스터가 진척률을 시각적으로 확인(예: "개발 중"이 아니라 "6개 태스크 중 3개 완료")할 수 있으며, 병목 문제를 조기 발견할 수 있습니다.
#### 📋 [실무 템플릿] 로그인 유저 스토리의 태스크 분해 예시
> User Story: 사용자는 이메일과 비밀번호로 로그인할 수 있어야 한다 (스토리 포인트: 5pt)
| 태스크 ID | 세부 작업 설명 | 담당자 | 예상 시간 | 현재 상태 | 완료 인정 기준 (DoD) |
| T1 | 로그인 API 사양 및 에러 코드 설계 | 백엔드 A | 4h | 완료 | API Spec 문서 작성 및 프론트 공유 완료 |
| T2 | JWT 발급 로직 및 로그인 API 구현 | 백엔드 A | 8h | 진행중 | 로컬 환경에서 JWT 정상 발급 확인 |
| T3 | 로그인 화면 UI/UX 디자인 | 디자이너 | 6h | 완료 | Figma 디자인 시안 최종 승인 |
| T4 | 로그인 폼 및 입력값 유효성 검증 개발 | 프론트 B | 6h | 진행중 | 컴포넌트 구현 및 밸리데이션 동작 |
| T5 | 프론트-백엔드 연동 및 예외 처리 테스트 | 프론트/QA | 4h | 대기 | 테스트 케이스(TC) 전수 통과 |
| T6 | 토큰 갱신 및 자동 로그인 세션 유지 구현 | 백엔드 A | 4h | 대기 | Access/Refresh 토큰 정상 갱신 |
⚠️ 주의: 하위 6개 태스크가 100% 완료되어 수락 조건을 만족해야만 해당 유저 스토리의 포인트(5pt)가 팀의 실적으로 인정됩니다. 99% 완료는 애자일에서 0% 완료와 같습니다.
### 2. 데일리 스크럼 (Daily Scrum)
운영: 매일 아침 같은 시간, 같은 장소에서 최대 15분 이내로 서서(Stand-up) 빠르게 진행합니다.
핵심 원칙: 이 자리는 팀장에게 업무를 지시받거나 어제의 근무 태도를 '보고'하는 자리가 아닙니다. 팀원 전체가 스프린트 목표 달성을 위해 동기화를 진행하는 '정렬(Alignment) 미팅'입니다.
3대 질문:
1. 스프린트 목표 달성을 위해 내가 어제 완료한 작업은 무엇인가?
2. 스프린트 목표 달성을 위해 내가 오늘 집중할 작업은 무엇인가?
3. 내 작업의 진행을 가로막는 장애물이나 리스크(Blocker)는 무엇인가?
### 3. 스프린트 도중 백로그 변경 처리 원칙
철칙: 스프린트가 시작되면 개발팀의 몰입을 위해 외부의 요구사항 추가나 백로그 변경은 원칙적으로 차단됩니다.
긴급 예외 상황 발생 시: 크리티컬한 운영 버그나 긴급 변경 요건이 발생하면 개발자가 임의로 처리하지 않습니다. PO, 스크럼 마스터, 개발팀이 한자리에 투명하게 모여 논의를 진행합니다. 새 작업을 스프린트에 추가 전원 합의하는 대신, 그 작업의 크기(포인트)만큼 기존 스프린트 백로그 하단에 있던 작업을 다음 스프린트로 이월(범위 조정)하는 트레이드오프를 명확히 해야 일정이 무너지지 않습니다.
### 4. 스크럼 보드 vs 칸반 보드
스크럼 보드 (Scrum Board): 정해진 '스프린트 기간(2주)' 동안 팀이 약속한 목표의 시작과 끝을 시각적으로 관리합니다. 스프린트가 시작될 때 새 보드가 생성되고, 종료되면 소멸합니다.
칸반 보드 (Kanban Board): 스프린트라는 시간의 인위적 단절 없이, 업무가 들어오고 나가는 '지속적인 흐름(Workflow)' 자체를 시각화하고 최적화합니다. 보드는 영구적으로 유지되며, 병목 현상을 막기 위해 각 단계별로 동시에 진행할 수 있는 최대 작업 개수를 제한하는 WIP(Work In Progress) Limit 관리가 핵심입니다.
### 5. 스프린트 리뷰 (Sprint Review)
목적: 스프린트 종료 시점에 기획자, 이해관계자, 개발팀이 모두 모여 개발된 산출물을 검증하고 피드백을 수집합니다.
진행 원칙:
* PPT 장표나 정지된 이미지 보고는 엄격히 금지됩니다. 실제 가동되는 소프트웨어로 직접 시연(Demo)해야 합니다.
* 완료 기준(DoD)을 완벽히 통과한 기능만 시연하며, 개발 중인 미완성 기능은 시연 목록에서 제외합니다.
* 생산성이나 팀 내 이슈를 논의하는 자리가 아니며, 오직 '제품의 비즈니스 가치와 피드백'에만 집중합니다.
### 6. 스프린트 회고 (Sprint Retrospective)
> 💡 "애자일은 어제보다 나은 오늘을 만드는 것" (린다 라이징). 스크럼 이벤트 중 가장 중요한 시간으로, 스프린트 직후 팀원들이 솔직하게 일하는 방식, 협업 프로세스, 도구를 되돌아보고 개선점을 도출합니다.
성공 조건: 심리적 안전감(Psychological Safety)이 필수적입니다. 특정 개인에 대한 비난, 방어적 태도, 책임 떠넘기기는 절대 엄금하며, 철저히 '프로세스와 시스템의 문제'를 찾아내야 합니다.
KPT 회고 프레임워크 실무 예시:
Keep (유지할 점): 이번 스프린트에서 효과적이어서 계속 유지하고 싶은 문화나 방식.
예: 데일리 스탠드업 10분 이내로 타이트하게 유지한 점, PR 머지 전 1인 필수 리뷰 문화 정착.
Problem (문제점)**: 아쉬웠거나 업무 진행을 방해하여 반복되면 안 되는 실책.
예: 백엔드 API 배포가 늦어져 FE 개발팀의 QA 테스트가 막판에 몰림, Jira 상태 업데이트 누락.
Try (개선안): Problem을 해결하기 위해 다음 스프린트에서 바로 시도해 볼 구체적인 변화.
예: 다음 스프린트 초반에 백엔드 Mock API 사양서 먼저 작성 및 Mock 서버 배포.
⚠️ 액션 아이템(Action Item) 연동: 회고가 단순 말잔치로 끝나지 않으려면, Try에서 나온 도출안을 반드시 [담당자, 기한, 명확한 목표]를 지정하여 다음 스프린트 백로그에 강제로 포함시켜야 팀이 진화합니다.
---
## 06. SDLC 생명주기 4단계별 실전 웹 개발 프로세스 & AI 협업 가이드
### 1단계: 분석 (Analysis) ── "WHAT: 무엇을 만들 것인가?"
주요 활동: 도메인별 기능 요구사항 정의, 사용자 시나리오 및 스토리 작성, 핵심 기능의 우선순위 트리아지.
🤖 AI 실행 가속**: 회의록 자연어 텍스트를 분석하여 도메인별 요구사항 목록 자동 정리, 사용자 스토리 및 예외 케이스 초안 생성.
👨💻 사람의 책임**: 비즈니스 가치에 따른 최종 범위 경계(Scope Boundary) 획정, 이해관계자 간 상충하는 요구사항 조율 및 최종 승인.
#### 💬 [요구사항 정리 AI 프롬프트 표준]
[PROMPT]
당신은 숙련된 비즈니스 분석가(BA)입니다. 다음 개발팀 회의록을 바탕으로 온라인 쇼핑몰 시스템의 요구사항을 도메인 기준으로 구조화하여 정리해 주세요.
- 대상 도메인: 회원, 상품, 주문, 결제, 보안
- 출력 형식 명세:
### [도메인명]
- 요구사항 세부 설명
- 비즈니스 우선순위 (높음/중간/낮음)
- 완료 인정 기준 (Acceptance Criteria) 조언
[회의록 텍스트 데이터 입력]
1) 사용자는 이메일로 가입하고 로그인할 수 있어야 한다.
2) 관리자는 상품을 등록, 수정, 삭제할 수 있어야 한다.
3) 결제는 카드와 카카오페이 2가지를 지원해야 한다. 실패 시 결제 도중 롤백되어야 한다.
4) 비밀번호는 BCrypt 알고리즘으로 암호화해서 저장해야 하며 평문 저장은 절대 안 된다.
5) 주문 내역은 사용자가 마이페이지에서 조회할 수 있어야 한다.
```
---
### 2단계: 설계 (Design) ── "HOW: 어떻게 구조화할 것인가?"
주요 활동: 소프트웨어 아키텍처 스타일 결정, UI/UX 와이어프레임 설계, 데이터베이스 스키마(ERD) 및 REST API 인터페이스 계약 명세 작성.
🤖 AI 실행 가속: 모노리스 vs MSA vs 이벤트 기반(EDA) 아키텍처 특성 트레이드오프 비교 보고서 자동화, 기획 기반 PlantUML 이나 dbdiagram.io용 데이터베이스 설계 코드 및 REST API 명세 초안 작성.
👨💻 사람의 책임**: 팀 전체가 공유할 기술 스택 옵션 최종 의사결정, 프론트엔드와 백엔드 간의 인터페이스 '계약(Contract)' 문서 확정 및 승인.
#### 🌐 주요 아키텍처 스타일 요약 가이드
레이어드 아키텍처 (Layered): Presentation ➔ Application ➔ Domain ➔ Infrastructure로 계층이 격리되어 직관적이고 소규모 MVP 개발 및 빠른 온보딩에 유리하지만 대규모 시스템에서는 유연성이 떨어집니다.
마이크로서비스 아키텍처 (MSA): 비즈니스 도메인 단위로 서비스를 완전히 쪼개어 독립 배포 및 장애 격리가 가능하고 기술 스택이 자유로우나, 분산 트랜잭션 데이터 일관성 제어 및 인프라 운영 비용이 매우 높습니다. 각 서비스는 반드시 자신의 DB를 독립적으로 보유해야 합니다.
이벤트 기반 아키텍처 (EDA): Publish ➔ 이벤트 채널(Kafka, AWS SQS 등) ➔ Subscribe 구조의 비동기 통신으로 시스템 간 결합도가 가장 낮고 실시간 대용량 처리에 유리하지만, 데이터 흐름 추적이 어려워 디버깅과 트래킹이 매우 복잡합니다.
#### 📊 회원 도메인 REST API 표준 명세서 예시
| Method | URI 경로 | 기능 설명 | 응답 코드 (Status) | 인증 필요 여부 |
| POST | /api/auth/join | 이메일 기반 신규 회원 가입 | 201 Created | No |
| POST | /api/auth/login | 로그인 및 JWT 토큰 쌍 반환 | 200 OK | No |
| POST | /api/auth/logout | 로그아웃 처리 및 토큰 서버 무효화 | 200 OK | Yes |
| GET | /api/users/{id} | 특정 회원 상세 프로필 조회 | 200 OK | Yes |
| PUT | /api/users/{id} | 회원 정보 수정 (이름, 프로필 이미지 등) | 200 OK | Yes |
| DELETE | /api/users/{id} | 회원 영구 탈퇴 처리 | 204 No Content | Yes |
| GET | /api/products | 상품 전체 목록 조회 (검색 필터 및 페이징 포함) | 200 OK | No |
| POST | /api/products | 신규 상품 등록 (어드민 전용 기능) | 201 Created | Yes (ADMIN) |
---
### 3단계: 개발 (Development) ── "DO: 실제로 구현하기"
주요 활동: Sprint 0 (초기 공동 기반 개발환경 구축), 코딩 표준 및 커밋 컨벤션 수립, 비즈니스 엔지니어링 구현 및 CI/CD 자동화 파이프라인 연동.
🤖 AI 실행 가속: GitHub Copilot, Cursor 도구를 활용한 코드 자동 완성 및 생성(개발 생산성 약 55% 향상), 가독성 향상을 위한 최적화 리팩터링 제안, Git PR(Pull Request)용 본문 명세서 자동 생성.
👨💻 사람의 책임: 코드 충돌을 방지하기 위한 브랜치 전략(Git Flow / Trunk-based) 설계 및 역할 분담, 팀의 공동 코드 품질 기준 수립 및 동료 코드 리뷰 피드백 실행.
#### 🛠️ Sprint 0: 본격 개발 전 수립해야 할 팀 공통 표준
로컬 개발환경 통일: 팀원 간 개발 환경 차이로 인한 에러를 방지하기 위해 공통 Node.js / Java 버전을 확정하고, Docker 컨테이너 환경으로 통일하며, 공통 .env 템플릿과 README.md를 기재합니다.
코딩 컨벤션 (Naming 표준):
변수 및 함수: camelCase (예: getUserList, handleClick)
클래스 및 컴포넌트: PascalCase (예: UserService, LoginForm)
글로벌 상수: UPPER_SNAKE_CASE (예: API_BASE_URL, MAX_RETRY)
데이터베이스 컬럼: snake_case (예: user_id, created_at)
Git 커밋 컨벤션 표준 양식**: <type>(<scope>): <subject> 형태로 통일합니다.
feat(auth): 로그인 API 구현 (새로운 기능 추가)
fix(user): 프로필 이미지 null 예외 처리 추가 (버그 수정)
refactor(order): 주문 서비스 결제 로직 비동기 분리 (코드 구조 개선)
chore: 외부 라이브러리 의존성 버전 업그레이드 (설정 및 기타 빌드 작업)
코드 품질 핵심 게이트: 단일 함수의 길이는 30줄 이내로 제한하며, 매직 넘버는 반드시 상수로 선언하여 사용하고, 하나의 PR은 코드 리뷰어의 몰입을 위해 500줄 이내 작성을 적극 권장합니다.
#### 💻 [AI 활용 Spring Boot Auth 로직 구현 프롬프트 예시]
[PROMPT]
Spring Boot 3.x 환경에서 동작하는 로그인 비즈니스 로직(AuthService.java)을 자동 생성해 주세요.
[요구 조건 명세]
1) 입력 데이터: 이메일(email), 평문 비밀번호(password)
2) 출력 데이터: 로그인 성공 시 JWT 토큰 문자열 반환
3) 보안 처리: DB에 저장된 암호화 비밀번호와 입력된 평문 비밀번호를 BCryptPasswordEncoder를 사용하여 매칭 검증
4) 예외 제어: 이메일이 존재하지 않을 경우 404 RuntimeException("NOT_FOUND") 발생, 비밀번호 불일치 시 401 RuntimeException("UNAUTHORIZED") 발생
5) JWT 발행: 서명 알고리즘은 HS256을 사용하며 JwtUtil.generateToken(email) 메서드가 이미 구현되어 있다고 가정하고 호출할 것.
---
### 4단계: 테스트 (Test) ── "CHECK: 품질 검증 및 디버깅"
주요 활동: 테스트 피라미드 전략 수립, CI/CD 자동화 파이프라인 연동, 테스트 커버리지 모니터링 및 버그 재현·수정.
🤖 AI 실행 가속: 정상 케이스 및 엣지 케이스를 포함한 JUnit5 / Jest 단위 테스트 코드 전면 자동 작성, 자연어 시나리오 기반의 Playwright / Cypress E2E 브라우저 자동화 스크립트 빌드, 에러 로그(Stack Trace) 분석 및 원인 추적 코드 제안.
👨💻 사람의 책임: 코드 품질 최종 통과 조건인 팀의 완료 기준(DoD) 합의 및 준수, 비즈니스 사용성 관점에서의 최종 인수 테스트 수행 및 배포 승인.
#### 📐 엔지니어가 반드시 알아야 할 테스트 피라미드 5대 유형
1. 단위 테스트 (Unit Test): 함수나 클래스 하나가 다른 외부 의존성 없이 단독으로 올바르게 작동하는지 검증합니다. Mock 객체를 적극 활용하며 실행 속도가 가장 빠르므로 코드 작성 즉시 상시 수행합니다 (도구: JUnit5, Jest, Vitest).
2. 통합 테스트 (Integration Test): 여러 컴포넌트나 레이어가 결합되어 함께 흐를 때의 상호작용을 검증합니다. 실제 데이터베이스나 외부 서비스 연동을 포함하므로 주로 Git PR 생성 시점에 자동 실행됩니다 (도구: Spring Test, Testcontainers).
3. API / 계약 테스트 (Contract Test): REST API의 요청과 응답 구조가 사전에 프론트엔드팀과 합의한 명세대로 일관성 있게 동작하는지 검증합니다 (도구: Postman, RestAssured).
4. E2E 테스트 (End-to-End Test): 실제 브라우저 환경에서 사용자의 실재적인 사용 흐름 전체를 로봇으로 자동화하여 검증합니다. 가장 현실적이지만 실행 속도가 매우 느리므로 배포 전 스테이징 환경에서 수행합니다 (도구: Playwright, Cypress).
5. 성능 / 부하 테스트 (Performance Test): 대규모 동시 사용자가 몰릴 때 시스템의 한계 응답 속도, TPS(초당 처리량), 에러율 지표를 측정합니다. 정기 릴리즈 직전에 대규모로 가동합니다 (도구: k6, JMeter).
#### 🚀 Fail Fast 정책 기반 CI/CD 테스트 파이프라인 표준
코드가 Git 커밋되는 순간부터 운영 서버 배포까지 완벽한 릴리즈 게이트를 구축하여 품질을 강제합니다.*
1단계: Git Push (<30초) ➔ 코드 문법 오류 검사(Lint) 및 코드 포맷팅 자동 수정 수행.
2단계: CI 빌드 실행 (<5분) ➔ 전체 단위 테스트 전수 가동 및 코드 커버리지 정밀 측정.
3단계: API 검증 단계 (<10분) ➔ 통합 테스트 및 프론트-백엔드 간 API 규격 상호 검증.
4단계: 스테이징 배포 (<20분) ➔ 격리된 인프라 환경에서 Playwright 기반 핵심 시나리오 E2E 및 회귀 테스트 수행.
5단계: 운영 배포 (배포 직후) ➔ 시스템 정상 구동 여부를 가리는 스모크 테스트 및 실시간 헬스 체크 모니터링 작동.
⚠️ 코드 커버리지 품질 통과 하한선: 핵심 비즈니스 로직이 몰려 있는 도메인 및 서비스 레이어는 최소 80% 이상, 컨트롤러 레이어는 60% 이상의 커버리지를 충족해야만 머지(Merge)가 가능하며, 단 하나라도 테스트가 깨지거나 기준치 미달 시 빌드를 즉시 중단(Fail Fast)시킵니다.
## 07. 고급 애자일 고도화: XP(Extreme Programming) 실천법
> 💡 핵심 메시지: 대부분의 실패한 개발팀들이 애자일의 데일리 스크럼, 스프린트 계획 회의 같은 '외형적인 프로세스(형식)'만 도입하고 코드 품질과 엔지니어링 역량을 가꾸지 않아 프로젝트를 망칩니다. 진짜 강력한 애자일 팀이 되려면 스크럼의 관리 체계 위에 XP의 엔지니어링 기술 프랙티스가 반드시 융합(프로세스 + 기술 = 진짜 애자일)되어야만 합니다.
### 1. 실전 팀 프랙티스 (Team Practices)
공동 소유 (Collective Ownership): 특정 소스코드나 시스템 모듈을 담당자 한 사람에게만 종속시키지 않습니다. 팀 전원이 전체 리포지토리의 모든 코드를 수정할 수 있는 권한과 책임을 공유하여 지식 파편화를 막고 휴먼 리스크를 제거합니다.
지속 가능한 속도 (Sustainable Pace): 무리한 단기 야근과 주말 근무로 팀을 갈아 넣는 방식을 거부합니다. 마라톤을 뛰듯 일정한 리듬과 속도를 유지하여 개발자의 심리적 안정감을 지키고 휴먼 에러로 인한 코드 오염을 원천 차단합니다.
정보 시각화 (Information Radiator): 팀원뿐 아니라 지나가는 이해관계자 누구나 프로젝트의 현재 건강 상태를 한눈에 볼 수 있도록 가시화합니다. 대형 모니터에 칸반 보드, 스프린트 번다운 차트, 빌드 성공 여부 대시보드를 항시 띄워두는 문화입니다.
### 2. 실전 기술 프랙티스 (Technical Practices)
TDD (테스트 주도 개발): 실제 기능을 구현하는 소스코드를 짜기 전에 이를 검증할 '실패하는 테스트 코드'를 먼저 작성합니다. Red(실패하는 테스트) ➔ Green(테스트를 통과하는 가장 단순한 코드 구현) ➔ Refactor(동작은 유지한 채 코드 구조 최적화) 사이클을 돌려 완벽한 품질을 담보합니다.
짝 프로그래밍 (Pair Programming): 두 명의 개발자가 하나의 모니터와 키보드 앞에 앉아 한 명(Driver)은 실시간 코드를 타이핑하고, 다른 한 명(Navigator)은 전체 구조를 보며 실시간 코드 리뷰 및 예외 처리를 짚어냅니다. 지식 공유가 극대화되며 별도의 사후 코드 리뷰 단계를 완전히 대체하는 효과가 있습니다.
리팩토링 (Refactoring): 이미 외부적으로 올바르게 동작하고 있는 소프트웨어의 기능은 절대 바꾸지 않으면서, 내부적인 코드의 가독성, 유지보수성, 유연성을 높이기 위해 구조를 끊임없이 다듬고 개선하는 일상적인 습관입니다.
단순 설계 (Simple Design): 켄트 벡이 주창한 원칙으로, 코드 구현 시 4대 기준을 준수합니다.
1. 작성된 모든 자동화 테스트 코드를 100% 통과할 것.
2. 코드 작성자의 설계 의도가 명확히 드러나 가독성이 높을 것.
3. 시스템 내에 중복 코드가 단 한 줄도 존재하지 않을 것.
4. 클래스, 메서드, 의존성 등 시스템을 구성하는 요소를 최소한으로 유지할 것.
## 08. 소프트웨어 장인정신 (Software Craftsmanship)
> 애자일이 폭포수 모델의 프로세스적 비효율을 깨뜨렸다면, 소프트웨어 장인정신은 단순히 동작하는 쓰레기 코드를 양산하는 것을 넘어 개발자 스스로 전문가로서의 의식과 헌신을 다하는 마인드셋 혁명입니다.
### 📜 소프트웨어 장인정신 선언문 (2008, 시카고)
우리는 애자일 선언을 넘어, 아래의 가치를 추구하는 진정한 소프트웨어 전문가의 커뮤니티를 지향한다.*
단순한 동작을 넘어 ➡️ 정밀하고 정교하게 잘 만들어진 소프트웨어 (Well-Crafted Software)!
변화에 대응하는 것을 넘어 ➡️ 꾸준히 비즈니스에 가치를 더하는 것 (Steadily Adding Value)!
개인과 상호작용을 넘어 ➡️ 전문가 공동체/커뮤니티의 육성 (Community of Professionals)!
고객 협업을 넘어 ➡️ 서로 상생하는 생산적인 동반 관계 (Productive Partnerships)!
🎨 최종 결론: 진짜 애자일을 완성하는 것은 화려한 도구나 방법론의 형식이 아닙니다. 불확실성을 통제하는 유연한 스크럼 스피릿, 코드 품질을 극대화하는 **XP의 엔지니어링 기술, 그리고 전문가로서의 명예와 가치를 전달하고자 하는 소프트웨어 장인정신이 삼위일체로 결합될 때 비로소 위대한 개발 팀이 탄생합니다.
애자일 강의는 팀으로서 이 여러 방법들을 어떻게 접목시켜야할지 많은 생각이 들게하는 유익한 시간이었다.
멘토링 과정
일단 멘토링을 진행하기 전 모든 팀원들이 멘토님이 어떤 성격이실지 모르는 상태라 상당히 긴장을 하고 계셨는데 그래도 막상 멘토님을 만나고 조금 시간이 지나고 나니 긴장도 풀어지고 여러모로 유익한 시간들이었다고 생각합니다
자기소개
먼저 자기소개 시간이 있었습니다 멘토님의 대략적인 어떤 생활을 해오셨는지 경력과 저희들이 어떤 사람인지에 대해서 간략하게
자신을 소개하고 ,어떤 배경을 가졌는지 이 프로젝트는 왜 참여하게 되었는지에 대해서 이야기 해보았습니다 저도 멘토님과 다른 팀원들이 어떤 생각을 가지고 있었는지 알게되는 시간들이었습니다.
주제 설명
멘토님께서 최종 프로젝트 계획서를 통해서 어떤 프로젝트를 계획하셨던건지에 대한 간략한 설명들을 그리고 앞으로의 진행방향이 어떤식으로 나아갔으면 좋겠다는 이야기들을 해주셨습니다 그러한 과정속에서 우리들이 가지고 있던 생각들이 얼마나 얕은건지 라는 생각이 좀 들었고 사고가 넒어지는 이야기들을 해주셨습니다
주제 선정과정
그러한 과정속에서 저희가 가져왔던 여러 주제들과 다른 의견들을 많이 보여드리고 저희 또한 주제에 대한 고도화가 필요하다는 생각이 들어서 딮페이크와 관련된 여러 이야기들을 나누었고 여러 주제들이 나왔지만 최종적으로는 아직 미정인 상태가 되었습니다.
마무리 및 느낀점
일단 팀원들과도 많은 대화가 필요하다는것을 다시한번 느끼게 되었고 우리가 아는 지식만으로는 불안한 요소들이 많다는것과 조금 더 시야를 멀리 보는 능력을 길러야겠다는것을 다시 한번 알게되는것 같았습니다.
'sk 쉴더즈 루키즈' 카테고리의 다른 글
| [ForenShield] 2차 멘토링 회의록 — 서비스 구성도 재정의 & RTM 매핑 (0) | 2026.06.13 |
|---|---|
| [Rookies 개발 5기] AWS 인프라 구조 다이어트 & Jira 칸반보드를 통한 스프린트 세부 계획 수립 (0) | 2026.06.04 |
