Day 3 — 진짜 애자일을 위한 첫걸음 및 팀 협업 표준화 세팅

서론

"팀이 더 잘 협업할 수 있도록 애자일의 핵심 가치를 배우고, 우리 프로젝트에 맞는 작업 규칙을 정했습니다."

오늘은 개발·관리 프로세스와 스크럼을 정리하고, AI 시대에도 협업 규칙이 왜 더 중요한지 배웠습니다. 이어서 1차 멘토링 질문을 팀 단위로 맞춰 보고, 개발·문서·회의 가이드라인을 정리하기 시작했습니다.

1. 왜 지금 개발 프로세스를 배워야 하는가?

강사님이 수년간 주니어 개발자들을 멘토링하면서 반복적으로 발견한 문제가 하나 있었다고 합니다. 바로 코드 실력은 있는데 함께 일하는 법을 모른다는 점입니다. 회사에서도, 학교에서도 아무도 체계적으로 가르쳐주지 않아서, 입사 후 협업 방식을 처음 접하면 혼란에 빠진다는 점을 짚어주셨습니다.

기술 트렌드는 빠르게 변하지만, 협업 방식의 본질은 잘 변하지 않습니다. 잘 안 변하는 것이 본질이며, 개발 프로세스 이해가 기술 적용의 기초가 된다는 것이 이 강의의 핵심 출발점입니다.

AI 시대에도 프로세스가 더 중요한 이유

강의에서 매우 현실적인 시나리오를 소개해 주셨습니다.

"당신은 4인 팀의 팀장이다."

Day 1: 각자 AI로 빠르게 개발해와. (ChatGPT, Cursor, Claude 기동)

Day 3: 팀원 A의 API와 팀원 B의 프론트엔드가 연결되지 않는다. (서로 다른 데이터 구조, 다른 인증 방식)

Day 5: 팀원 C가 이미 구현된 기능을 모르고 처음부터 다시 만든다. (중복 개발 3일치 발생)

Day 7: 마감 전날 밤, 팀장인 당신 혼자 모든 걸 붙들고 밤을 지새운다.

AI는 코드를 빠르게 만들었지만, 팀은 더 빠르게 무너졌습니다.

AI가 코드 생성 속도를 4배 넘게 높여주더라도 방향 설정, 역할 조율, 품질 기준은 여전히 프로세스와 사람의 몫입니다. 강의에서 소개된 지표도 함께 확인했습니다.

AI 생성 코드에서 발견된 품질·보안 결함: 45% (GitClear 2024, 강의 인용)
AI 도입 후에도 소프트웨어 프로젝트 성공률: 31% (CHAOS Report 2023, 강의 인용)
SDLC 실패의 원인: 80%는 코딩이 아닌 이후 단계(설계·테스트·관리)에서 발생 (Harness Survey 2025, 강의 인용)

2. 개발 프로세스 vs 관리 프로세스

소프트웨어 개발에는 두 가지 흐름이 있으며, 둘이 잘 맞아야 제대로 된 시스템을 만들 수 있습니다.

개발 프로세스 — 무엇을, 어떤 순서로 만드는가

분석 → 설계 → 개발 → 테스트의 4단계로 이루어집니다.

분석 (Analysis): WHAT? 무엇을 만들지 정의하고 합의. (산출물: 요구사항 정의서, 사용자 스토리)
설계 (Design): HOW? 어떻게 만들지 구조 설계. (산출물: 아키텍처 문서, ERD, API 명세서)
개발 (Implementation): DO. 실제로 구현. (산출물: 소스 코드, Docker 이미지)
테스트 (Testing): CHECK. 동작 검증 및 버그 수정. (산출물: 테스트 결과서, 버그 리포트)

관리 프로세스 — 언제까지, 어느 수준으로, 어떤 위험을 감수하며

일정 관리, 범위 관리, 품질 관리, 비용 관리로 구성되며 개발 전 단계에 걸쳐 적용됩니다.

3. 전통적 관리 프로세스(Waterfall)의 특징과 함정

폭포수(Waterfall) 모델의 특징

각 단계가 완전히 끝난 후에야 다음 단계로 진행하는 방식으로, 흐르는 물처럼 위에서 아래로만 수직 이동합니다. 앞 단계의 산출물이 다음 단계의 필수 입력물이 되는 일방향 구조입니다.

장점: 구조가 명확하고, 문서화가 잘 되고,, 대규모·공공 프로젝트처럼 계약 기반 산출물이 명확한 환경에 적합합니다.
단점: 요구사항 변경이 발생하면 재작업 비용이 폭발적으로 늘어나고, 프로젝트 후반부 전까지는 실제로 동작하는 결과물을 전혀 볼 수 없습니다.

WBS와 진척관리의 함정 — 80% 됐어요의 내막

워터폴 방식에서는 WBS(Work Breakdown Structure)로 일정을 세분화하고 간트 차트로 진척을 관리합니다. 하지만 여기에는 심각한 착시 현상이 숨어 있습니다.

구현 태스크 10개 중 9개를 완료했다고 보고하여 언뜻 90% 진척된 것처럼 보이지만, 실제 내막을 들여다보면 다음과 같은 경우가 다반사입니다.

5개: 코드만 짜여 있고 테스트는 전혀 안 됨
2개: 화면(UI)만 나왔고 백엔드 기능 연동 미완성
2개: 외부 API 연동 대기 중으로 동작 불가능
1개: 손도 못 댔음

이것이 바로 속은 텅 비어가는데 겉으로만 진행되는 것처럼 보이는 진척률 착시입니다. 겉은 초록(진행 중)인데 속은 빨강(미완)인 상태를 흔히 watermelon status라고도 부릅니다. 이런 착시가 쌓이면 일정만 소진되고 결과물은 없는 죽음의 행진(Death March) 으로 이어지기 쉽습니다.

Iron Cross — 4가지 제약요소의 트레이드오프

모든 프로젝트는 일정(Time), 범위(Scope), 비용(Cost), 품질(Quality)이라는 4가지 제약이 팽팽하게 대립합니다.

선택지	결과 및 특징
일정 변경	거의 불가능. 마케팅·영업·비즈니스 계약 전체에 영향을 줌.
인력 추가	역효과 발생 가능. (브룩스의 법칙: 지연된 프로젝트에 인력을 추가하면 프로젝트는 더 늦어진다.)
품질 포기	최악의 선택. 기술 부채가 폭발하여 결국 장기적으로 속도가 더 느려짐.
범위 조정	실무에서 가장 현실적인 선택지. 파레토 법칙(80/20 법칙)에 따라 핵심 20% 기능이 전체 80%의 가치를 만들기 때문에, 우선순위가 낮은 범위를 먼저 조정하는 편이 낫다. (일정·비용이 이미 고정인 경우도 있어, 항상 유일한 정답은 아님.)

애자일은 이 트레이드오프를 감과 희망이 아닌 데이터 기반(Velocity)으로 다룹니다. 매 스프린트마다 완료된 스토리 포인트를 측정하여 예측 가능성을 확보합니다.

주요 SDLC 모델 비교

Waterfall: 순차적 단계 진행. 앞 단계 완료 후 다음 단계 이동하는 전통적 방식.
Prototyping: 시제품을 먼저 만들어 사용자와 요구사항을 사전 검증. 요구사항이 불명확할 때 유용.
Incremental: 우선순위 높은 기능부터 Build 단위로 점진 완성. (100% 기능의 80% 완성보다, 80% 기능의 100% 완성이 낫다)
Evolutionary: 분석/설계/개발 사이클 자체를 진화적으로 반복하며 변경 사항을 수용. 애자일·스크럼의 모태.
Spiral: 위험 분석을 반복 수행하며 프로토타입을 점진적으로 발전시키는 방식.

4. 애자일 선언과 스크럼(Scrum) 프레임워크

애자일 선언문 (Agile Manifesto, 2001)

공정과 도구보다는 개인과 상호작용을, 포괄적인 문서보다는 작동하는 소프트웨어를, 계약 협상보다는 고객과의 협력을, 계획을 따르기보다는 변화에 대응하기를 더 가치 있게 여긴다. 워터폴이 의지와 희망으로 일정을 잡는다면, 애자일은 누적된 실제 데이터로 관리한다는 차이가 있습니다.

스크럼의 핵심 가치 & 3가지 역할

공식 Scrum Guide는 투명성(Transparency) · 점검(Inspection) · 적응(Adaptation) 이라는 경험주의를 강조합니다. 강의에서는 이를 실무 감각으로 풀어 반복(Iteration, 2~4주 주기), 협업(Collaboration, 팀 목표 우선), 적응(Inspect & Adapt) 으로 정리했습니다.

Product Owner (PO): 제품 백로그의 우선순위를 결정하고 비즈니스 가치를 책임지는 1인 관리자.
Scrum Master (SM): 팀의 장애물을 제거하고 스크럼 규칙을 촉진하는 조력자(퍼실리테이터).
Development Team: 스프린트마다 실제 작동하는 제품을 납품하는 자율적(Self-organizing)·다기능(Cross-functional) 개발 팀원들.

제품 백로그와 스토리 포인트

제품 백로그는 단순한 Task 리스트가 아닌, 제품이 나아갈 전략적 우선순위 리스트입니다. 주로 사용자 스토리 형식으로 작성합니다.

As a [역할], I want [목표], so that [가치/이유]
(예: 화물 차주로서, 내 주 운송 구간을 등록하여, 해당 구간의 오더를 받기를 원한다.)

업무량 추정 시 시간이 아닌 상대적 복잡도 점수인 스토리 포인트를 사용하며, 팀원이 다 함께 피보나치 수열(1, 2, 3, 5, 8…)로 점수를 매기는 과정에서 요구사항이 명확해집니다. 팀이 한 스프린트당 처리하는 평균 점수인 Velocity가 쌓이면 향후 일정 예측이 매우 정교해집니다.

스크럼의 5대 이벤트 및 2주 리듬

Sprint (1~4주): 계획부터 회고까지 일어나는 애자일의 기본 심장박동 주기.
Sprint Planning: 스프린트 백로그를 생성하고 스토리를 세부 Task로 분해.
- 예시 (로그인 기능): T1 API 설계(4h) → T2 API 구현·JWT(8h) → T3 UI 디자인(6h) → T4 로그인 폼(6h) → T5 연동 테스트(4h) → T6 자동 로그인(4h)
Daily Scrum: 매일 15분 동기화. 전통적으로는 “어제 한 일, 오늘 할 일, 장애물” 3질문을 썼고, 최근 Scrum Guide는 스프린트 목표 진척을 중심으로 이야기하도록 권합니다. (기술 토론 자리는 아님)
Sprint Review: 스프린트 종료 후, PPT가 아닌 실제 Done 기준을 충족해 동작하는 제품을 시연하고 피드백을 받음.
Retrospective (회고): 제품이 아닌 일하는 방식의 개선점을 찾는 자리. KPT 기법(Keep, Problem, Try)으로 반드시 구체적인 액션 아이템(담당자, 기한 명시)을 도출해야 함.

5. 진짜 애자일: 프로세스 + 기술 역량

강사님께서 강하게 짚어주신 흔한 오해 중 하나는 애자일은 설계를 생략하고 문서 없이 막 짜는 것이라는 점입니다. 과도하고 형식적인 문서를 지양할 뿐, 설계 자체는 필수이며 매 스프린트마다 지속적으로 진화(Evolutionary)시키는 것입니다. 공식 스크럼 용어는 아니지만, 실무에서 흔히 쓰는 Sprint 0에서 기초 인프라, 기술 스택, 컨벤션을 견고히 잡아 둔 뒤 리팩토링해 나가는 방식이 도움이 됩니다.

또한 스크럼은 “어떻게 일할지”를 잡는 프레임워크라, 코드 품질까지 자동으로 보장하진 않습니다. 그래서 XP(eXtreme Programming) 같은 엔지니어링 프랙티스를 함께 쓰는 편이 실무에서 훨씬 안정적입니다.

팀 프랙티스

공동 소유 (Collective Ownership): 전원이 코드 책임
지속 가능한 속도 (Sustainable Pace): 야근 없는 일정한 리듬
정보 시각화 (Information Radiator): 칸반보드 / 번다운차트
고객 현장 참여

기술 프랙티스 (XP 중심)

TDD: 테스트 코드를 먼저 작성 후 기능 개발 (Red → Green → Refactor 사이클)
짝 프로그래밍 (Pair Programming): 두 명이 함께 코딩하며 실시간 코드 리뷰 및 지식 공유
리팩토링 (Refactoring): 외부에 노출되는 동작은 유지한 채, 내부 코드 구조만 지속 개선
지속적 통합 (CI): 코드를 빈번하게 통합하고 자동화 테스트로 에러를 조기 발견 (빌드는 절대 깨지지 않아야 함)

이와 별도로, 객체 지향 설계에서는 SOLID 원칙이 자주 함께 언급됩니다. 스크럼이 일하는 방식을 정한다면, SOLID는 코드를 어떻게 나눌지에 가깝습니다.

6. AI 시대 개발자의 역할 변화 및 소프트웨어 장인정신

McKinsey 조사에 따르면 AI 도입 팀 개발자의 40%가 코드 작성보다 설계와 리뷰에 더 많은 시간을 쓰고 있다고 합니다. 정밀한 명세 작성 능력인 Spec-Driven Development가 핵심 역량으로 부상하고 있습니다.

BEFORE (전통적 개발자)	AFTER (AI 시대 개발자)
코드를 직접 작성	Spec Writer — AI에게 정확한 의도와 맥락 전달
문법을 암기하고 숙달	Orchestrator — 여러 AI 에이전트의 흐름을 설계 및 조율
Stack Overflow 검색	Reviewer — AI가 생성한 결과물의 품질 및 보안성 검증
타이핑 속도 = 생산성	Architect — 시스템 전체 구조와 인터페이스 설계
코드를 잘 짜는 사람	Judgment Caller — 기술 트레이드오프 최종 판단 및 의사결정

소프트웨어 장인정신 (Software Craftsmanship)

2008년 선언된 소프트웨어 장인정신은 애자일 선언을 한 단계 더 개선한 개념입니다. 단순히 코드를 짜는 개발자를 넘어 가치를 지속적으로 연마하는 소프트웨어 전문가로의 인식을 강조합니다.

작동하는 소프트웨어 → 잘 만들어진 소프트웨어
변화에 대응하기 → 꾸준히 가치를 더하기
개인과 상호작용 → 전문가 커뮤니티
고객과의 협업 → 생산적인 동반 관계

7. 1차 주간 멘토링 질문 공유 및 의도 싱크업

애자일 수업이 끝나고 팀원들끼리 모여, 첫번째 멘토링을 더 의미 있게 보내기 위해 전원이 작성한 질문지를 취합하고, 각자 어떤 의도로 질문을 만들었는지 공유하는 시간을 가졌습니다.

질문 방향은 대략 이렇게 갈렸습니다.

아키텍처·인프라: AWS 구성, SQS 워커, CI/CD 파이프라인의 현실적인 범위
도메인·API: 소유권 인증, 스캔 상태 모델, 도메인 간 경계
일정·협업: 스프린트 단위로 어디까지를 Done으로 볼지, 문서/회의 리듬

의도를 먼저 맞추니, 멘토링에서 “질문만 던지고 끝나는” 대신 피드백을 어디에 반영할지가 더 분명해졌습니다.

8. 개발 및 협업 표준화 가이드라인 수립

풀스택 트랙과 인프라 트랙이 잘 협업하고, 겉으로만 진척되는 것처럼 보이는 진척률 착시·Death March를 막기 위해 3개의 공통 가이드라인을 정리하기 시작했습니다.

개발 환경 가이드라인: 팀원 간 코드 호환성 보장 및 빌드 오류 최소화를 위한 환경 설정 완료
문서 작성 가이드라인: 요구사항 정의서, 아키텍처 정의서 등 기술 문서의 포맷·용어 규칙 통일 완료
회의 진행 가이드라인: 핵심 안건 집중과 생산적 의사결정을 위한 시간 관리·소통 규칙을 정리 중

오늘은 애자일·스크럼 핵심을 팀 전체가 공유하고 위 작업 규칙까지 합의했습니다.

9. 다음 단계: 멘토링 및 피드백

오늘은 애자일·협업 규칙과 멘토링 질문 의도를 맞춰 둔 상태입니다. 이어지는 작업은 피드백을 문서·일정에 바로 녹이는 쪽입니다.

첫번째 멘토링: 아키텍처·인프라 범위, 도메인/API 경계, 스프린트 Done 기준을 중심으로 질문하고 답을 기록
피드백 반영: 나온 내용을 아키텍처 정의서·요구사항·WBS에 바로 수정
개발 착수 준비: Spring Boot / Vite 보일러플레이트와 공통 컨벤션을 팀 저장소에 맞춰 두기
가이드라인 마무리: 회의 진행 가이드라인 초안을 확정해, 이후 일일·주간 리듬에 적용