애자일 프랙티스를 읽고.....

"애자일".. 이전 부터 애자일 개발 방법론에 대해서 간간히 들어왔던 터라 낯선단어는 아니였다. 더 효율적인 프로젝트 개발에 나름 고민하던 중, 애자일이라는 것을 만나게 되었다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.
전체의 큰 프로젝트 혹은 시스템을 하나의 덩어리로 보는 것이 아니라, 작은 단위로 쪼개서 생각하는 것그리고 이 작은 단위들을 빠른 주기로 실행하는 것이 애자일의 핵심이다.

* 애자일 프로세스 란 : 보기

사례중심의 애자일 관련 책을 찾다가, "애자일 프랙틱스"라는 책을 찾게 되었다.
이 책을 읽고 많이 공감이 가고, 꼭 한 번 생각해봐야 하는 부분에 대해서 정리해 본다.

* 땜질은 늪을 만든다.
* 단위 테스트를 이용해라.
* 코드의 결합도를 낮추어라.
* 코드로 소통하라.
* 다른 사람에게 계속 알리기.
* 짧은 반복을 사용하여, 점진적으로 배포하라.

* 땜질은 늪을 만든다.
버그가 있고, 시간 압박을 받았다. 땜질을 해도 잘 돌아가는 것 같았다. 리스트 마지막에 한 줄을 덧 붙이거나, 무시해도 당장엔 잘 동작을 했다. 그러나 다음의 대처 방법이 좋은 프로그래머와 서투른 프로그래머를 구분하는 방법이다. 서투른 프로그래머는 위와 같은 상황이 있은 후 다른 일로 넘어가 버리고, 좋은 프로그래머는 이 일로 인해 다른 것들이 영향을 받지 않는지 확인을 한다.

우리도 위와 같은 일이 많았다. 나도 그랬다고 생각한다. 나중에 위와 같은 임시 방편적인 땜질을 많이 한 후에, 기능을 추가하거나, 수정하는 일은 머리를 잡아 뜯는 악몽이 되기도 한다.

- 위와 같은 일이 벌어지지 않게 하려면 -
우선 프로세스에 대해 최소한의 이해를 하려고 노력을 해야 한다. 누군가가 나에게 이일을 시켰기 때문에, 나는 이 부분만 하겠다라고 생각하는 것은 잘못된 생각이다. 단위 테스트를 활용하는 것도 큰 도움이 된다.

* 단위 테스트를 이용하라
코드의 특정 부분, 혹은 특정 모듈을 개발하는 경우에는 이를 테스트하기 위해 print문으로 찍거나, 결과 값들을 확인해보는 테스트를 필연적으로 실행하게 된다. 이 부분들을 따로 모아 두어서 나중에 유닛 단위로 테스트하는데 활용을 한다면, 그리고 이 테스트들이 자동적으로 이루어 지도록 하자.
이를 통해 메일로 피드백을 받아보게 한다거나, 자동화를 시키는 것은 품질 관리에 있어서 우리에게 큰 짐을 하나 덜어주는 일이라 할 수 있겠다.

* 코드 결합도를 낮추자.
특정 프로젝트를 진행하다 보면 다른 프로젝트와 필연적으로 공통되는 부분들이 있다. 이렇게 공통되는 부분들을 나중에 사용하려고 해도, 코드내의 특정 부분이 다른 파일 혹은 다른 파일내의 변수와 강하게 결합이 되어있어서, 활용하기 어려운 경우를 종종보기도 한다.

이 내용은 단위 테스트와도 연결 될 수 있다. 단위 테스트(모듈 단위 테스트)가 가능하다는 것은 코드의 유연성이 있다는 이야기와도 연결이 될수 있다. 또 한 코딩 스타일도, 확장성, 유연성을 갖을 수 시작 단계에서 생각을 해보는 것이 좋다.

* 코드로 소통하라.
Enki 프로젝트를 진행하면서, Core에서 UI로 알려주는 API에 대한 문서를 따로 만들어서 관리를 했었다. 헌데, 이런 식의 문서들이 하나 둘 늘어가게 되고 필연적으로 설계 및 API등이 변경되게 되는데, 이들 변경된 부분들을 다시 문서에 적용을 하는 것이 굉장히 번거롭고 귀찮은 작업으로 느껴진다.

문서가 꼭 필요한 것들은 제외를 하고, 코드와 관련된 부분에서는 코드로 위 문서들을 대신하는 것이 현명한 방법이다. 예를들어 python을 이용한다면, pydoc 문서등을 활용해서 코드로 의사 소통을 하자.
또한 코드에서 변수명이나 메소드명에 명확하고 이해하기 쉬운 이름을 붙여주어서 코드로 다른사람을 이해시키자. 이도 어려운 상황이라면.. 부가 적인 설명을 달은 주석을 많이 활용하자.
우리는 주석을 많이 활용하고 있는가?

* 다른 사람에게 계속 알리기
프로젝트를 진행하면서, 제시간에 작업을 끝내는 것이 당연한 일이다. 그러나, 문제에 부딪쳐서 지연되는 일은 늘 있다. 데드라인이 다가오고 있고, 이 나쁜 소식을 전하는데, 데드라인까지 상급자나 고객이 기다린다면, 자신의 사소한 사항까지 관리해 달라고 관리자나 기술 리더에게 요청하는 것이나 다름없다.

위와 같은 문제에 부딪혔을 때, 다른 사람에게 계속 알려서 당황스러운 상황을 없애고, 이로 인해다른 이들은 진행 상황을 알기 때문에 편안해진다. 프로젝트 진행이 지연되고 있다면, 왜 늦어지고 있는지, 문제가 무엇인지를 다른 사람들에게 알리고 의논하자. 다른 사람이 일의 상황을 물을 때까지 기다리지 말자.

* 짧은 반복을 사용하여, 점진적으로 배포하라.
이 책의 핵심이다. 분석, 설계, 구현, 테스트, 피드백 구하기 등을 주기적으로 계속 적으로 반복하는 것이다.

최소한의 유용한 기능 단위로 묶어서 제품을 릴리스하라. 각 추가 기능의 개발에 1~4 주 정도의 반복 주기를 사용하라.

* 지금까지 프로젝트를 진행하면서 느낀점.
지금까지 프로젝트를 진행하면서, 소프트웨어의 특성 자체가 계속 적인 기능의 수정, 추가라고 생각을 한다. 이와 같이 진행되면서 소프트웨어의 수정이 자주 일어나는 것은 당연한 일이고 오히려 처음 계획된데로 100% 진행이 되는 프로젝트가 있다면 프로젝트 자체를 의심해야 하지 않을까? 자주 수정이 된다고 해서 스트레스 받지 말자... 차라리 이런 고민을 하는 시간에 어떻게 하면 더 유연하고 수정된 내용들을 잘 반영할 수 있는지에 대해 고민하는 편이 더 낮다고 생각한다.