Agile한 개발자가 되는 방법

원본글은 github에 있습니다.

---

애자일이 무엇인지는 이해하더라도,
실제로 일하는 방식을 어떻게 바꿔야 하는지 알기는 쉽지 않은 것 같다.

내가 생각하는 애자일한 개발자가 되는 구체적인 방법은 다음과 같다.

 

계획보다 대응하기

'계획보다 대응(적응)'은 애자일의 4가지 가치 중 하나다.
관련 원칙은 '요구사항변경 환영'이다. 애자일은 고객의 경쟁 우위를 위해 변경을 활용한다.

 

실천방법: 테스트 코드

요구사항 변경을 수용하는 하는 것은, 개발자의 시간을 빼앗아 간다. 만든 코드를 더럽힌다.
더럽혀진 코드는 시간을 더 빼앗아 간다. 코드는 더 더러워 진다.

요구사항이 변경되지 않는 프로젝트/소프트웨어는 거의 없기 때문에,
일반적으로 개발자는 자신이 만든 코드에 자신이 없다.

이 고통스러운 굴레에서 벗어나는 방법은,
자동으로 실행가능한 테스트 코드를 작성하는 것 이다.

버튼 하나만으로, 몇 초만에 실행되는 테스트가 있다면, 개발자는 요구사항을 적용하는 것에 두려움이 없어지기 시작할 것이다.

변경된 요구사항을 적용하고, 버튼을 눌러 정상작동 됨을 확인한다.
실패하면 수정한다. 성공할때까지 반복한다.

 

실천방법: 리팩토링

리팩토링은 테스트 코드를 전제로 한다.
요구사항 변경도 어려워 안하려고 하는 개발자가, 리팩토링을 하는 것은 거의 불가능하다.

테스트 코드로 정상동작 코드를 얻고나면 지저분한 코드를 단순하게 변경할 수 있다. OOP같은 방법론을 적용할 수 있다.
유닛테스트와 함께 잘 깍아낸 객체/모듈/함수를 만들면, 정상동작이 보장되는 재사용 가능한 코드가 만들어진다.

리팩토링으로 코드를 단순하게 유지 할 수 있다. 변경/추가 되는 요구사항을 적용하기 쉬워진다.
요구사항 변경이 자연스러운 과정으로 여겨진다.

 

문서보다 작동하는 결과물

'문서보다 작동하는 결과물' 역시 애자일의 4가지 가치 중 하나다.
관련 원칙은 '동작하는 결과 수시제공', '동작하는 결과로 진척확인', '꼭 할일만 함'이다.

 

실천방법: 지속적인 통합(CI)

지속적인 통합은 테스트 코드를 전제로 한다.
코드 통합은 요구사항 변경과 마찬가지로 개발자의 시간을 빼앗아 간다.(통합 지옥)

그래서 개발팀은 코드 통합을 두려워하고 최대한 피하려고 한다.
통합을 늦출수록 코드간의 괴리는 커진다.

이 고통스러운 굴레를 벗어나는 방법도 테스트 코드다.
유닛테스트/통합테스트/인수테스트등을 갖추고 실행하여, 통합 전/후 소프트웨어가 정상동작 함을 확인한다.
몇 분안에 통합한 소프트웨어가 정상동작 함을 확인할 수 있다면, 통합을 두려워하지 않게 된다. 수시로 통합하는 것이 더 유리해진다.

CI를 유지하는 팀은 소프트웨어를 쉽게 배포할 수 있다. 동작하는 소프트웨어를 수시로 제공할 수 있게된다.
자주 배포 가능하면, 동작하는 소프트웨어가 진행상황의 기준이 될수 있다.
자주 배포 가능하면, 가장 중요한(하다고 생각하는) 기능을 먼저 구현해서,
사용자가 새로운 기능을 빨리 만날 수 있고, 피드백을 빨리 얻을 수 있다.
불필요한 일을 안하게 될 수 있다.

 

XP

위에 작성한 실천방법들은 익스트림 프로그래밍(XP)에서 제시하는 방법들이다.

개발자 채용공고 등장하는 문구들 - TDD, 테스트코드, CI, 코드리뷰(페어프로그래밍), 리팩토링 등 - 이 책에 등장해서 신기했다.
책의 실천방법들은 회자되는데, 왜 익스트림 프로그래밍은 회자되지 않을까?
애자일한 개발자가 되고 싶은데, 구체적으로 뭘 어떻게 해야되는지 모르겠다면. 나는 익스트림 프로그래밍 책을 보는걸 추천한다.

무엇보다, XP가 애자일의 찐엄마 아닌가!? ...뭐 아니더라도... XP가 애자일의 최대주주 아닐까?

 

프로그래머를 위한 XP의 목표

익스트림 프로그래밍 책 가장 첫페이지의 내용이다.

프로그래머들도 얼마든지 현실 생활에서 온전한 사람이 될 수 있습니다.
XP는 자신을 시험해 보고, 자기 자신이 되어 보고, 또 사실 여러분은 원래부터 괜찮았는데 단지 나쁜 친구들과 어울렸던 것이 문제라는 사실을 깨달을 수 있는 기회입니다.

진짜로 이렇게 쓰여있다(놀람). 당시 개발자들의 참혹한 현실이 느껴지는 듯하다. 책의 17장을 보면 그 냄새를 맡을 수 있다.

 

결론

내가 생각하는 애자일한 개발자가 되는 방법의 첫 단추는 테스트코드 작성이다.
내 경험상 특히 실무에서 테스트코드를 작성하는것은 쉽지 않았다. 하지만 노력해볼만한 가치가 충분하다.

애자일한 개발자가 되면 뭐가 좋을까?
음.. 나의 경우엔, '불안'이 없어졌다. '속도'(속력 아님)가 빨라졌다. 개발이 '즐거워'졌다.

이런 이유로, 알게 된 이상, 알기전에 하던 방식으로 돌아가긴 힘들다.