애자일 소프트웨어 개발 방법론에 대한 고찰과 정리. 협업이 중요한 소프트웨어 개발에서 관리자와 팀원, 팀원과 팀원이 신뢰를 바탕으로 개발 프로세스를 어떻게 잡아나가야 하는지 제 나름대로의 생각을 정리해봤습니다.

1. 애자일 하라
dev@koriel.kr
https://koriel.kr

2. 애자일(Agile)이란?
• 소프트웨어 개발 방법론
• 민첩하고 기민하다는 사전적 의미
• 특정 개발방법론을 의미하는 것이 아니다
= 민첩하고 기민하게 소프트웨어를 개발할 수 있는 방법론을 통칭
ex) 익스트림 프로그래밍, 스크럼, 칸반, TDD 등등 많기도 하다
Key Point: 상호 배타적이지 않고 엄격성을 가진 것이 아니다.
즉, 회사의 개발 환경과 제품에 맞게 다듬어야 한다.

3. 그래서 왜 애자일해야하지?
• 회사에선 혼자 개발하는 게 아니다.
• 유지보수가 가능해야 하고 가독성이 좋아야 한다.
• 버그를 추적하고 체계적으로 관리해야 한다.
• 소프트웨어의 위기 관리, 원인 분석
이런 걸 제한된 비용과 시간안에 해야 한다.
Key Point: 나중에 귀찮지 않고 소프트웨어를 똥으로 만들지 않기 위해 미리
정해진 프로세스에 따라 정갈하게 개발하자!

4. 결국 우리한테 좋은 건 뭔데?
• 소프트웨어 품질이 올라간다.
 But… 이건 회사 사정이지 난 대충 코드만 치고 월급만 받으면 돼!
Oh no no… 결코 그렇지 않다. 대충 코드만 치고 어떻게든 되겠지라는
마음으로 상쾌하게 귀가하던 중, Winnie에게 전화가 왔다.
“TSL에서 MODI Studio가 안된대!”
“근데 코드가 개판이라 어디서부터 손을 대야할 지 감도 안와!”
OH MY GOD!  철야
Key Point: 우리 자신을 위해서라도 애자일 해야 한다.

5. 애자일한 방법론들
• 익스트림 프로그래밍
• 스크럼
• 칸반
• 크리스털 패밀리
• Feature-Driven Development
• Adaptive Software Development
• 익스트림 모델링
= Process, != Practice like TDD(Test-Driven Development)

6. 스크럼(Scrum)
• 각 이슈들에 우선순위 부여
• 개발 주기는 30일 정도이고 주기마다 실제로 동작하는 코드를
제공
• 개발 주기마다 포함할 Feature, Bug fix 목록 제공
• 매일 15분 회의
• 팀 단위로 생각
• 구분없는 열린 공간  물리적 공간을 의미
개발 주기 = Sprint, 특정 주기의 할일 목록 = Sprint backlog

7. 스크럼(Scrum)

8. 스크럼: pros and cons
• Pros:
• 신속한 위기 대응
• 주기마다 작동하는 제품이 나오기 때문에 고객이랑 말싸움하기 편함
• Cons:
• 고객이나 PM에게 테스트 환경을 별도로 마련
• 끊임없이 반복되는 개발 주기
• 쓸데없이 길어지는 아침 회의
• 시간에 쫓김
Key Point: 개발자도 사람이다.

9. 스크럼 요약
덩치가 큰 회사에서 장기적인 계획을 가지고 만드는 제품보다는
소규모 팀에서 단기간에 만드는 작은 프로젝트에 적합
OR
소프트웨어의 위기 상황으로 재빠르게 몇 달동안 품질을 향상시
켜야 하는 경우

10. 칸반(Kanban)
• 이슈는 큐에 쌓이고 개발 프로세스를 단계로 나눔.
• 한번에 진행되는 이슈를 제한
• 이슈의 우선순위를 수영 레인에 비유
• 지속적인 배포에 초점
• 칸반 보드로 시각화
• 오른쪽 이슈가 왼쪽 이슈보다 더 중요
한번에 처리하는 이슈의 수를 제한함으로써 일의 효율성을 증대

11. 칸반(Kanban)

12. 칸반에 대한 우려
• 데드라인이 없다.
데드라인이 있다고 생산성이 증대되는 건 아니다. 일을 늘어뜨리자는 것
이 아니다. 속도는 여전히 중요하다. 하지만 팀원들에게 데드라인으로 압
박하면, 그들은 번아웃된다. 그건 곧바로 생산성 저하와 코드 품질의 저하
로 나타난다.
• 한번에 여러일을 못하네?
 멀티태스킹이 생산성을 증대시킬 것이라고 착각하지 마라. 대부분은 일
의 혼선을 빚고 헷갈리게만 만든다. 이미 진행되었고 우선순위가 높은 일부
터 차근차근 진행해라.

13. 칸반의 장점
• 오버헤드의 최소화
• 앞으로 필요한 작업이 무엇이고 어디서 병목이 발생했는 지 알 수 있다.
• 소프트웨어 품질에 초점
• 언제 얼마나 빨리 끝내는 지가 중요한 게 아니다. 품질을 올리자!
• 행복한 팀
• 규범적이지 않다. 유연하다.
• 우선순위의 변동이 없다.
• To Do는 사업부가 소유, 나머지는 기술팀이 소유한다. 사업부가 To Do
에서 야생 동물처럼 날뛰게 할 순 있지만, 다음 단계부턴 그들이 그것
을 마음대로 바꿀 수 없다. 기술팀의 몫이다. BDD(Business-Driven
Development)를 막자.

14. 칸반 보완점
• 동기 부여의 함량 미달
• 적당한 속도감과 압박은 팀을 건강하게 유지하게 해준다. 하지만 이것
을 제도와 도구에 의지하지 마라. 관리자의 몫이다.
• 도구의 미흡
• Atlassian JIRA엔 칸반과 칸반 보드가 정말 훌륭하게 구현되어 있다. 하
지만 완전히 커스터마이징하는 건 무리가 있다.

15. Practices
• TDD  Development
• Gerrit  Code Review
• GitLab  Back log, Code Review
• Jenkins  CICD

16. TDD
1. 실패하는 테스트를 작성
2. 작성된 테스트를 통과하는 코드 작성
3. 작성된 코드를 리팩토링

17. TDD

18. TDD: 실패하는 테스트 작성
int add(int& a, int& b) {
return 0;
}
test_add() {
int a = 10;
int b = 20;
static_assert((a + b) == add(a, b), “fail!!!”); // Compile time
}

19. TDD: 작성된 테스트를 통과하는 코드 작성
int add(int& a, int& b) {
return 30;
}
void test_add() {
int a = 10;
int b = 20;
static_assert((a + b) == add(a, b), “fail!!!”); // Compile time
}

20. TDD: 리팩토링
int add(int& x, int& y) {
return 30;
}
void test_add() {
int x = 10;
int y = 20;
static_assert((x + y) == add(x, y), “fail!!!”); // Compile time
}

21. TDD: 작성된 테스트를 통과하는 코드 작성
int add(int& x, int& y) {
return x + y;
}
void test_add() {
int x = 10;
int y = 20;
static_assert((x + y) == add(x, y), “fail!!!”); // Compile time
}

22. TDD의 장점
• 코드의 품질 향상
• 필요한 코드만 작성
• 테스트를 통과한 코드만 존재하므로 디버깅 시간 절약
• 리팩토링 용이
• 테스트 코드 문서화
• 내 코드에 대한 자신감

23. TDD의 단점
• 빠른 프로토타이핑에는 부적함
• 개발 시간이 길어짐
• 보통은 품질이 개발 시간보다 중요하다. 그리고 장기적인 안목에선
TDD가 개발 시간을 결코 늘리지 않는다. 디버깅과 리팩토링을 용이하
게 함으로써 오히려 개발 시간을 줄인다.

24. Three rules of TDD
1. GIVEN = 테스트의 전제 조건
2. WHEN = 테스트하는 코드가 주는 결과
3. TEHN = assertion

25. TDD Tools (Unit test)
• C++
• Google.Test
• Boost.Test
• Visual Studio
• Node.js
• Jest(Facebook)

26. Unit test vs Integration Test
Unit Test: 단일 코드 블록에 대한 테스트하는 것. 다른 코드 블록
과 통합되었을 때 전체적으로 어떻게 동작하는 지 테스트 하지
않는다.
Integration Test: 코드 블록들이 모여 구성한 전체 코드, 즉 프로
그램으로써 잘 작동하는 지 테스트하는 것이다. UI 테스트가 여기
에 속하고 주로 QA 엔지니어가 전문적으로 하는 일이다. 난이도
가 높은 작업.

27. Gerrit
• Git 기반의 코드 리뷰 시스템
• 일정 점수 이상의 리뷰를 얻어야 코드 변경 사항을 푸시할 수
있도록 강제

28. Gerrit
• 서로 감시하고 지적질하는 시스템이 아니다.
• 서로 토론하는 시스템.
• 다른 관점에서 코드를 바라보고 계속 개선시킬 수 있다.
• 잠재적인 오류 가능성 제거

29. Jenkins

30. 정리
• 시스템에 너무 기대지 말자.
• 이런 시스템이 잘 작동할 수 있는 전제 조건은 관리자와 팀간의
신뢰, 팀원간의 신뢰이다.
• 우리는 우리만의 것을 쌓아가야 한다.
• 어차피 목적은 효율성과 품질의 향상이다. 시스템에 얽매히다
보면 정반대의 결과를 낳는다.

31. Q&A
• 코드 리뷰는 몇 명이서 하면 좋을까요?
• 같은 코드를 최소 3명은 봐야한다.
• 이걸 어떻게 다 하죠?
• 다 할 필요없습니다. 회사의 규모에 맞게 차근차근 도입하면 됩니다.
• 지금 우리가 당장 해야할 것 하나만 고른다면?
• TDD!