애자일(Agile) 방법론
📌 들어가며
안녕하세요! 멀티캠퍼스 유레카 3기 백엔드 과정을 수강 중인 개발자 지망생입니다.
오늘은 코딩이 아닌 소프트웨어 개발 방법론을 배웠어요. 처음엔 "방법론이 뭐 그리 중요해? 그냥 코드 짜면 되는 거 아냐?"라고 생각했는데, 수업을 듣고 나니 완전히 생각이 바뀌었습니다.
특히 선배 개발자분이 이런 말씀을 하셨어요.
"실무에서는 애자일(Agile) 방법론을 많이 쓰는데, 이걸 모르면 팀 협업이 정말 힘들어. 취업 전에 공부해두면 큰 도움 될 거야!"
그래서 오늘은 애자일 방법론이 무엇인지, 왜 실무에서 중요한지, 그리고 개발자의 코드와 어떤 연관이 있는지 깊이 공부해봤습니다! 😊
🎯 Today I Learned
✅ 소프트웨어 개발 방법론이란?
✅ 폭포수(Waterfall) 모델의 특징과 한계
✅ 애자일(Agile) 방법론의 핵심 철학
✅ 스크럼(Scrum) 프레임워크 이해
✅ 애자일이 코드에 미치는 영향 (TDD, CI/CD)
✅ 칸반(Kanban) 보드와 실무 적용
✅ 애자일의 한계와 극복 방법
🤔 개발 방법론, 왜 필요할까?
방법론 없이 개발하면 생기는 문제들
개발을 시작하면 보통 이렇게 생각하죠.
"요구사항 받았으니까 → 설계하고 → 코딩하고 → 테스트하면 끝!"
간단해 보이지만, 실제로는 이런 문제들이 발생해요:
❌ 개발 중간에 고객이 "이거 아닌데..." 라고 함
❌ 몇 달 개발했는데 시장 트렌드가 바뀜
❌ 마지막에 테스트했더니 처음부터 다시 만들어야 함
❌ 팀원들이 누가 뭘 하는지 몰라서 일이 겹침
❌ 마감 전날까지 아무것도 안 하다가 몰아서 함...
바로 이런 문제들을 해결하기 위해 개발 방법론이 필요한 거였어요!
📊 전통적인 폭포수(Waterfall) 모델
폭포수 모델이란?
물이 위에서 아래로 떨어지는 것처럼, 단계별로 순차적으로 진행하는 방식입니다.
1️⃣ 요구사항 분석 (2개월)
↓
2️⃣ 설계 (1개월)
↓
3️⃣ 구현 (3개월)
↓
4️⃣ 테스트 (1개월)
↓
5️⃣ 배포 및 유지보수
폭포수 모델의 장단점
장점 단점
| ✅ 계획이 명확함 | ❌ 변경이 매우 어려움 |
| ✅ 일정 관리가 쉬움 | ❌ 고객이 결과물을 늦게 봄 |
| ✅ 문서화가 체계적 | ❌ 리스크를 후반에 발견 |
| ✅ 이해하기 쉬움 | ❌ 초기 요구사항 파악의 어려움 |
폭포수 모델의 치명적 문제
# 6개월 개발 후...
def show_result_to_client():
client.review(final_product)
if client.feedback == "이게 아닌데...":
# 😱 처음부터 다시...
redesign_everything()
develop_again() # 또 6개월...
실제로 이런 일이 자주 발생했고, 이를 해결하기 위해 애자일이 등장했습니다!
🚀 애자일(Agile) 방법론의 등장
애자일은 프로세스가 아니라 사고방식이다
2001년, 17명의 소프트웨어 개발자들이 모여서 만든 애자일 선언문:
📜 우리는 다음을 가치있게 여긴다:
✨ 프로세스와 도구보다 → 개인과 상호작용을
✨ 포괄적인 문서보다 → 작동하는 소프트웨어를
✨ 계약 협상보다 → 고객과의 협력을
✨ 계획을 따르기보다 → 변화에 대응하기를
중요한 건, 애자일은 단순히 "짧게 개발하고 자주 배포하자"가 아니라는 거예요. 사람 중심의 사고 전환이 핵심입니다!
애자일의 핵심 개념
1. 반복적 개발 (Iterative Development)
# 폭포수 방식
def waterfall_development():
plan_for_6_months()
develop_for_6_months()
release_once() # 6개월 후 출시
# 애자일 방식
def agile_development():
for week in range(1, 13): # 2주마다
plan_sprint()
develop()
get_feedback() # 🔄 지속적 피드백
adjust_direction()
장점: 매번 고객 피드백을 받아 개선할 수 있어요!
2. 점진적 개발 (Incremental Development)
// Sprint 1 (2주)
const mvp = {
login: true,
logout: true
// 최소 기능만 구현
};
release(mvp); // ✅ 동작하는 제품!
// Sprint 2 (2주)
const version2 = {
...mvp,
createPost: true,
viewPost: true
};
release(version2); // ✅ 기능 추가!
// Sprint 3 (2주)
const version3 = {
...version2,
comments: true,
likes: true
};
release(version3); // ✅ 계속 개선!
한 번에 완벽한 걸 만들려고 하지 않고, 조금씩 추가해나가요!
🏃 스크럼(Scrum) 프레임워크
애자일을 실제로 적용하는 방법 중 가장 유명한 게 **스크럼(Scrum)**이에요!
스크럼의 핵심 요소
1. 역할 (Roles)
🎯 Product Owner (제품 책임자)
- 무엇을 만들지 결정
- 우선순위 관리 (Product Backlog)
- 고객과 소통
👥 Development Team (개발팀)
- 실제 개발 담당
- 자기 조직화된 팀
- 5~9명 권장
🎪 Scrum Master (스크럼 마스터)
- 스크럼 프로세스 지원
- 장애물 제거
- 팀 코칭
2. 스프린트 (Sprint)
📅 스프린트란?
→ 정해진 기간(보통 1~4주) 동안
→ 동작하는 제품 증분을 만드는
→ 짧은 개발 주기
보통 2주 단위로 진행하며, 각 스프린트마다 실제 동작 가능한 기능을 배포 가능한 형태로 완성합니다.
3. 스크럼 이벤트
① Sprint Planning (스프린트 계획)
- 언제: 스프린트 시작할 때
- 무엇: 이번 스프린트에 뭘 할지 결정
- 시간: 2주 스프린트 기준 4시간
② Daily Scrum (데일리 스크럼)
- 언제: 매일 같은 시간, 같은 장소
- 무엇: 15분 동안 진행 상황 공유
- 질문 3가지:
- 어제 뭘 했나?
- 오늘 뭘 할 건가?
- 어떤 장애물이 있나?
③ Sprint Review (스프린트 리뷰)
- 언제: 스프린트 마지막
- 무엇: 완성된 결과물 시연
- 고객/이해관계자에게 피드백 받기
④ Sprint Retrospective (회고)
- 언제: 스프린트 끝날 때
- 무엇: 프로세스 개선점 찾기
- 질문:
- 잘한 점 (Keep)
- 개선할 점 (Problem)
- 시도할 것 (Try)
💻 애자일이 코드에 미치는 영향
1. TDD (Test-Driven Development)
애자일에서는 테스트를 먼저 작성해요!
// 1. 테스트 먼저 작성 (RED)
@Test
public void 회원가입_성공() {
// given
UserDto user = new UserDto("test@test.com", "1234");
// when
UserResultDto result = userService.register(user);
// then
assertEquals("success", result.getResult());
}
// 2. 테스트를 통과하는 최소한의 코드 작성 (GREEN)
public UserResultDto register(UserDto user) {
if(userDao.insert(user) > 0) {
return new UserResultDto("success");
}
return new UserResultDto("fail");
}
// 3. 리팩토링 (REFACTOR)
2. CI/CD (지속적 통합/배포)
'빠른 피드백과 잦은 배포'를 실현하려면 기술적 기반이 필요해요!
# GitHub Actions 예시
# 코드를 푸시할 때마다 자동으로 테스트하고 배포!
name: CI/CD Pipeline
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
# 자동 테스트
- name: Run Tests
run: mvn test
# 테스트 통과하면 자동 배포
- name: Deploy
if: success()
run: |
./deploy.sh
CI/CD의 장점:
- CI (지속적 통합): 여러 개발자가 동시에 코드를 병합해도 문제 없도록 자동 빌드 및 테스트 수행
- CD (지속적 배포): 검증된 코드를 스테이징 또는 운영 서버에 자동 배포
3. 작은 단위로 커밋하기
# ❌ 나쁜 예
git commit -m "기능 추가"
# ✅ 좋은 예 (애자일 방식)
git commit -m "feat: 사용자 로그인 API 구현"
git commit -m "test: 로그인 테스트 케이스 추가"
git commit -m "refactor: UserService 메서드 분리"
git commit -m "fix: 비밀번호 검증 버그 수정"
4. 리팩토링을 두려워하지 않기
// Sprint 1: 일단 동작하게 (Working Code)
public String login(String email, String pw) {
User user = db.query("SELECT * FROM users WHERE email='" + email + "'");
if(user != null && user.getPassword().equals(pw)) {
return "success";
}
return "fail";
}
// Sprint 2: 리팩토링 (Clean Code)
public LoginResult login(LoginRequest request) {
return userRepository.findByEmail(request.getEmail())
.filter(user -> passwordEncoder.matches(
request.getPassword(),
user.getPassword()
))
.map(user -> LoginResult.success(user))
.orElse(LoginResult.fail());
}
📋 칸반(Kanban)과 지속적 개선
칸반 보드란?
스크럼이 주기 중심의 방식이라면, **칸반(Kanban)**은 흐름 중심의 방식입니다.
┌──────────┬──────────┬──────────┬──────────┐
│ To Do │ Doing │ Review │ Done │
├──────────┼──────────┼──────────┼──────────┤
│ 회원가입 │ 로그인 │ │ │
│ 게시판 │ │ │ │
│ 댓글기능 │ │ │ │
└──────────┴──────────┴──────────┴──────────┘
칸반의 핵심
- 작업의 흐름을 투명하게 공유
- 병목 구간을 실시간으로 파악하고 개선
- 지속적 개선(Kaizen)
실무에서 사용하는 도구
- Jira: 전문적인 프로젝트 관리 도구
- Trello: 간단하고 직관적
- Notion: 문서 + 칸반보드 통합
- GitHub Projects: 코드와 함께 관리
📊 폭포수 vs 애자일 완벽 비교
구분 폭포수 (Waterfall) 애자일 (Agile)
| 개발 주기 | 긴 주기 (수개월) | 짧은 주기 (1~4주) |
| 접근 방식 | 순차적, 선형적 | 반복적, 점진적 |
| 요구사항 | 초기에 고정 | 계속 변경 가능 |
| 고객 참여 | 초기 + 마지막 | 전 과정 지속적 |
| 결과물 | 마지막에 완제품 | 주기마다 동작하는 버전 |
| 문서화 | 매우 상세 | 필요한 만큼만 |
| 테스트 | 마지막에 | 지속적으로 |
| 위험 관리 | 후반에 발견 | 조기 발견 가능 |
| 변경 비용 | 매우 높음 | 낮음 |
| 적합한 프로젝트 | 요구사항 명확, 변경 없음 | 요구사항 불명확, 변경 많음 |
🌟 실무에서 애자일을 쓰는 이유
1. 빠른 시장 대응
// 2주마다 시장 반응 확인
for(let sprint = 1; sprint <= 10; sprint++) {
const feature = develop();
const feedback = releaseAndGetFeedback(feature);
if(feedback.marketTrend === "changed") {
adjustDirection(); // 방향 수정!
}
}
// 폭포수라면?
// 6개월 개발 → 출시 → "이미 유행 지남..." 😭
2. 리스크 조기 발견
// Sprint 1에서 이미 발견!
@Test
public void 성능테스트() {
long startTime = System.currentTimeMillis();
userService.getUsers();
long endTime = System.currentTimeMillis();
assertTrue("응답시간 초과!", (endTime - startTime) < 1000);
// ⚠️ 성능 문제 발견! → 바로 개선
}
3. 팀 생산성 향상
Daily Scrum 효과:
"나 어제 로그인 API 만들었는데,
비밀번호 암호화 어떻게 하셨어요?"
"아! 제가 BCrypt 라이브러리 썼는데,
코드 공유해드릴게요!"
→ 중복 작업 방지 ✅
→ 지식 공유 ✅
→ 빠른 문제 해결 ✅
⚡ 애자일의 한계와 극복
애자일은 완벽한 방법론이 아닙니다. 오히려 개발팀의 성숙도가 낮을수록 혼란을 초래할 수 있죠.
한계
❌ 명확한 문서화 부재
- 인수인계나 유지보수 시 문제 발생
❌ 과도한 회의
- 생산성 저하
❌ 우선순위 잦은 변경
- 일정 예측 어려움
극복 방법
✅ Jira / Confluence / Notion 등을 통한 명세 자동화
✅ 회의 시간 최소화, 비동기 커뮤니케이션 강화 (Slack, Notion 댓글)
✅ CI/CD + 테스트 자동화로 품질 보증
결국 도구와 문화의 균형이 중요합니다!
💡 오늘 나는 무엇을 배웠는가
1. 애자일은 '빠른 개발'이 아니다
처음엔 "애자일 = 빨리빨리 개발"인 줄 알았는데, 전혀 아니었어요!
애자일의 진짜 의미 "변화에 유연하게 대응하면서, 고객에게 가치를 지속적으로 전달하는 것"
속도보다는 방향이 더 중요해요!
2. 완벽함보다 동작하는 것
폭포수 사고방식:
"완벽하게 설계하고, 완벽하게 개발하고, 완벽하게 테스트하자!"
→ 6개월 후 출시했는데 시장이 변함 😭
애자일 사고방식:
"일단 동작하는 최소 기능(MVP)을 2주 만에 만들자!"
→ 고객 피드백 받고 개선
→ 또 피드백 받고 개선
→ 시장 변화에 맞춰 방향 수정 ✅
이게 바로 "Done is better than perfect"!
3. 커뮤니케이션이 핵심
애자일에서 가장 중요한 건 사람과 소통이에요.
- Daily Scrum으로 매일 소통
- Sprint Review로 고객과 소통
- Retrospective로 팀 내부 소통
문서보다는 대화, 계획보다는 실행과 피드백!
😊 좋았던 점 & 😅 아쉬웠던 점
좋았던 점
👍 실무 지향적인 수업
단순히 이론만 배운 게 아니라, CI/CD, TDD 같은 실무 기술과 연결해서 이해할 수 있었어요. 특히 선생님이 실제 회사에서 어떻게 스크럼을 운영하는지 경험담을 들려주셔서 생생했습니다!
👍 개발자의 사고방식 변화
"완벽하게 만들어야 해"에서 "일단 동작하게, 그 다음 개선하자"로 마인드가 바뀌었어요. 이게 훨씬 현실적이고 효율적이더라고요!
👍 애자일 철학에 공감
"계획을 따르기보다 변화에 대응하기를"이라는 문장이 계속 머릿속에 맴돌아요. 처음 짠 계획대로 안 되더라도, 유연하게 대응하면서 계속 앞으로 나아가는 것. 이게 애자일의 핵심이고, 개발자로서 가져야 할 마인드셋인 것 같아요.
아쉬웠던 점
😢 실습 시간 부족
이론 위주로 진행되다 보니 실제로 칸반보드를 만들어보거나 Jira를 직접 만져보는 시간이 부족했어요.
😢 대규모 프로젝트 적용 사례
4~5명 소규모 팀은 이해가 되는데, 실제 회사에서 수백 명이 일할 때는 어떻게 애자일을 적용하는지 궁금해요.
😢 실전 경험 부족
이론으로만 배워서 실제로 스크럼을 돌려본 경험은 없어요. 개인 프로젝트나 다음 협업 프로젝트에서 한번 적용해봐야겠습니다!
🎓 학습 팁
1. 애자일은 '실천'으로 배운다
책이나 강의로만 배우면 이해가 잘 안 돼요. 직접 해봐야 합니다!
개인 프로젝트 실천 계획:
- ✅ 2주 단위 스프린트로 목표 설정
- ✅ GitHub Projects로 칸반보드 만들기
- ✅ 매주 일요일 회고 노트 작성
- ✅ 커밋 메시지 규칙 지키기
2. 완벽한 계획보다 작은 실행
❌ 나쁜 예:
"칸반보드를 완벽하게 설계하고,
규칙을 완벽하게 정하고,
역할을 완벽하게 분담하고...
→ 결국 시작도 못 함
✅ 좋은 예:
"일단 Notion에 To Do, Doing, Done 컬럼 만들고,
내일부터 해보면서 필요한 거 추가하자!"
→ 실행하면서 개선
3. 용어에 겁먹지 말기
스크럼, 스프린트, 백로그, 번다운 차트... 용어가 어려워 보이지만 사실 당연한 이야기들이에요.
- Sprint = 짧은 개발 기간
- Daily Scrum = 매일 모여서 얘기하기
- Backlog = 해야 할 일 목록
- Retrospective = 회고
우리말로 바꿔서 이해하면 쉬워요!
4. GitHub Projects로 혼자서도 애자일
나만의 2주 스프린트:
✅ Week 1-2: 로그인/회원가입만 완성
✅ Week 3-4: 게시판 CRUD 추가
✅ Week 5-6: 댓글 기능 추가
매주 일요일: 회고 노트 작성
- 잘한 점
- 개선할 점
- 다음 주 목표
🚀 다음 학습 목표
📌 단기 목표 (이번 주)
✓ 스크럼 관련 책 1권 읽기 (추천: "스크럼" by Jeff Sutherland)
✓ GitHub Projects로 개인 프로젝트 칸반보드 만들기
✓ TDD로 간단한 기능 구현해보기
📌 중기 목표 (이번 달)
✓ Jira, Trello 같은 도구 써보기
✓ CI/CD 파이프라인 직접 구축해보기
✓ 개인 프로젝트를 2주 스프린트로 진행
📌 장기 목표 (부트캠프 기간)
✓ 애자일 방식으로 프로젝트 경험 쌓기
✓ 회고(Retrospective) 문화 습관화
✓ 포트폴리오에 "애자일 프로젝트 경험" 강조
🎬 마치며
오늘 수업을 듣기 전에는 "개발 방법론? 그냥 코드 잘 짜면 되는 거 아냐?"라고 생각했어요.
하지만 수업을 듣고 나니, 어떻게 일할 것인가가 무엇을 만들 것인가만큼이나 중요하다는 걸 깨달았습니다.
"계획을 따르기보다 변화에 대응하기를"
특히 소프트웨어 개발에서는 빠르게 변하는 시장에 대응하는 게 생존의 열쇠예요. 애자일은 단순한 개발 방법론이 아니라, 유연하게 사고하는 마인드셋이라는 걸 배웠습니다.
"단순히 '유연한 개발 방식'으로만 이해했던 애자일을, CI/CD와 코드 리뷰, 협업 문화까지 아우르는 하나의 시스템으로 바라볼 수 있었다."
앞으로 개인 프로젝트를 할 때도 2주 단위 스프린트로 쪼개서 진행해봐야겠어요. 완벽한 계획보다 작은 실행이 더 중요하니까요! 💪
좋은 프로세스는 존재하지만, "그 프로세스를 따르는 개발자의 습관"이 더 중요하다는 사실을 잊지 말아야겠습니다.
여러분도 애자일 방법론, 한번 공부해보세요. 분명 개발자로서 한 단계 성장하는 계기가 될 거예요! 🚀