저는 ViKi 의 시작부터 ViKi 개발의 전반을 경험하였고, 지금은 BalmBees 프로젝트에 합류하게 되었습니다. 초기 ViKi 는 php로 CakPHP를 사용하여서 개발되었습니다. CakePHP는 MVC방식을 따르는 프레임워크였기 때문에 html코드와 php코드가 섞여서 알아보기 힘든 문제점을 개선하기는 하였지만, 사이트의 규모가 커짐에 따라 개발 가이드 라인이 부족해서인지 개발자 마다의 코드나 방법이 달랐고, 작성된 코드를 테스트하는 경험도 부족하고 방법도 까다로웠습니다. 나중에는 한부분을 고치면 다른 부분에서 버그가 발생하는 일이 계속 반복되었습니다.레일즈 개발을 도입하게 된 계기는 Pivotal Labs 라는 컨설팅 회사와 함께 일하기 시작하면서 부터였고, 레일즈와 애자일 개발 방법론을 함께 전수 받았습니다. 몇년동안 유지보수해서 커질대로 커진 웹사이트를 새로운 언어와 프레임워크를 써서 다시 만든다는게 처음에는 불가능해 보였지만 일이 진행됨에 따라서 레일즈와 애자일을 함께하는 방법이 더 낫다는 확신이 들었고 지금은 기존에 어떻게 개발을 하였나 하는 생각까지 하게 됩니다.지금까지의 일반적인 개발 방법 하에서는 기획이 나오면 언제까지 개발하겠다는 목표를 세우고 그 기한이 늦어지게 되면 조바심이 생겨서 일을 무조건 많이 하려고만 했었습니다. 하지만 무리한 일정이 지속 되면 얼마 후에는 업무 효율이 떨어져서 개발 속도도 느려지고 버그도 많아 지는 것을 경험하였습니다. 그리고 많은 시간을 들여 기능을 개발하였는데 결과적으로는 기획 의도와 다른 경우도 자주 있었습니다. 반면, 애자일 개발 방법에서는, 기획이 나오면 그것을 몇시간 내에 구현할 수 있는 단위인 스토리로 나눕니다. 그리고 기획자가 스토리들의 우선 순위를 정하고, 개발자가 각 스토리가 얼마나 걸릴지 예측을 합니다. 이러한 과정에서 자연히 기획자와의 대화가 늘어나고 미스커뮤니케이션이 줄어듭니다. 스토리에 소요되는 시간은 저희가 쓰는 툴이 자동으로 계산합니다. 이전 몇주간의 생산성을 계산해서 어떤 기능이 얼마나 걸릴지 예측하고, 이 개발속도는 매주 업데이트 됩니다. 이로써 개발 일정 관리에 대한 부담이 줄고 현재 개발하고 있는 스토리에 집중할 수 있었습니다. 이런 방법이 빠른 결과를 보려는 일반적인 생각에 반대되는 것 같지만 결과적으로는 생산성이 떨어지는 문제를 해결하는 것 같습니다.또한, 레일즈는 수많은 개발자와 프로젝트에서 검증된 개발 가이드 라인을 제공합니다. 오픈소스이고 수많은 개발자들이 사용하고 발전시키고 있기 때문에 여러 프로젝트에 사용되면서 개선된 점이 레일즈 프레임워크에 다시 반영됩니다. 따라서 몇달에 한번씩은 주요한 업그레이드가 나옵니다. 또한 다른 개발자들이 제공하는 가이드 라인만 따르더라도 오랫동안 고민해서 얻은 결과를 바로 적용할 수 있습니다.
● TDD + Pair-Programming + Ruby on Rails 한달 체험기
from 개발자 Tae Kang
TDD + Pair Programming 이라는 것이 책이나 블로그에서 접해볼 수 있는 막연한 것이었고, BalmBees 이전에 국내 회사중 "공식적으로" 그 방식을 이용한다는 곳을 들어본 적은 없습니다. 팀에서 간헐적으로 활용하는 경우가 있기는 하나 대부분의 지속되지 못하고 흐지부지 되는 것 같았습니다.
일단 지금 이곳에 합류하기 전까지의 제 경력은 대략 이렇습니다.
- 모바일 핸드셋 개발 : 하드웨어 제어하는 API 개발 및 폰에 탑재되는 어플리케이션 개발 (스마트폰 아님); C 사용- Back-end 시스템 개발 : 리눅스 상에서 대용량 데이테 처리를 위한 분산시스템 개발 및 유지보수; Hadoop / Xen VM hypervisor / 각종 분산파일시스템 오픈소스를 이것저것 가져다 사용하다보니 언어의 제약은 없었음. C, Java, Python, Shell script 등 닥치는대로 사용.
- 웹 서비스 개발 : Spring 기반으로 collaboration 시스템
- 분산처리 시스템 개발 : 대용량 데이터 처리하는 시스템 Hadoop 이용하여 구축 (Java + Python 조합); Front-end는 Python/Django + mySQL 사용.
보시면 아시겠지만, TDD와 Rails는 접해보지 못했습니다. 물론 Rails와 비슷한 Spring과 Django같은 MVC는 깊게는 아니더라도 어느정도 접해보았죠.
저도 이번에 처음 제대로 TDD + Pair-programming 경험을 해 본건데 현재까지의 느낌은 이렇습니다.
- Pair Programming :
옆 에 누가 있고 컴퓨터 한대로 둘이 함께 작업을 하다보니 딴짓할 겨를이 없다. 사실... 혼자 있으면 딴짓 많이하자나요. 혼자 개발하는게 100명들어가있는 강의실에서 수업받는거라면, Pair-programming은 개인과외 받는 그런 기분입니다. 집중력은 확실히 올라가게 되고, 같이 작업하다보니 코드의 일관성도 생기게되고 어떤 부분에서 어떤코드가 어떤일을 수행하는지 알게됩니다. 만일 따로 작업해야했다면, 나중에 만나서 서로에게 다시 설명해야 하는 성가신 작업에 코드리뷰와 같은 일들이 필요하겠죠. 그리고 대부분의 경우 그 설명하는게 귀찮아서 시간이 지나면 서로 "저인간은 뭐하지?" 아니면 "아니 뭐 코드를 이따구로 짜놨어...?" 그렇게 되는 경우를 많이 보았습니다.
단점이라면... 딴짓할수 없다는것... 옆에 누구 있는데 졸기 어렵다는점 ㅋㅋ 그리고 결정적인건 윗분들이 "아니 혼자하면 되는거 왜 둘이 해서 돈을 두배로 들여야해?" 라고 생각하는 분들이 아직은 많은지라 하고 싶어도 하기 어렵다는것.
- TDD :
TDD 의 경우에는 문제를 단순화할 수 밖에 없게 만듭니다. 왜? 테스트 케이스를 만들어야 하니까요. 그리고 처음에는 속도가 안나는 듯 하지만 이게 손에 익고 테스트 케이스들이 촘촘하게 쌓이면 "마음의 안정" 이 생기게 됩니다. - "기능 변경을 해야하는데, 라이브러리를 새로운거로 갈아끼고 싶은데, 혹시 바꿧다가 맛탱이 가면 어떡하지?" 했을때 코드 변경을 꺼리게 되죠. 하지만 테스트 케이스가 쌓이고 난 후에는 지금까지 만들어놓은 테스트 케이스를 돌려버리면 되니까, 기획자가 새로운 기능 추가하자 하거나 변경하자고 해도 어느정도 할만한것 같습니다. (아직까지는... ^^)
단점이라면, "이게 정말 속도가 나는건가?" 하고 가끔씩 의문이 들때. 마음은 급한데 마음은 빨리 구현해버리고 싶은데... 하는 충동이 들때. 근데 위에서도 언급했듯이 기능상의 변경들이 요구될때 분명히 pay-off가 있을것 같긴 합니다.
- Ruby on Rails :
MVC Framework를 경험해 보았다면 언어만 틀린거지 Java기반의 Spring이나 Python기반의 Django와 유사하다고 할 수 있지만, 확실히 Java기반보다는 "담백함"이 있습니다. Java기반이 화려한 단어와 미사여구로 진입장벽을 높여 많은이들에게 좌절을 준다면 Rails는 그런게 확실히 적고 코딩하고 결과를 볼때의 반응이 즉각적이어서 좋은것 같습니다. 그리고 Java와는 틀린 이런 즉각적인 반응이 TDD나 Pair-programming을 현실적으로 가능하게 만드는게 아닌가 싶습니다. 물론 성능은 Java기반이 더 좋다고는 하지만, 결국 프로그램을 만드는것은 사람이니까, 일하는 사람이 편해야지 기계들 편하자고 일하는건 아니잖아요.
단점은... 아직까지는 좋습니다만, 시스템이 커지면 성능이슈가 있을수 있다고들 하더라구요. 그래서 트위터와 같은 RoR로 개발된 사이트들도 성능이 이슈인 부분들은 Java 기반으로 갈아끼고 있다는 이야기도 있구요. 하지만 그런 고민이 드는 상황이라면 행복한 상황이겠죠 ^^; 그리고 전세계의 해커님들께서 불철주야 노력하고 계시고 시스템적으로도 해결할수 있는 방안이 있어보입니다. (물론 그 상황 되어봐야 알겠죠!)
* 큰 목표, 큰 도전, 큰 성취를 위해 노력과 포기를 할 줄 아는 사람들
--- 이런 문구가 있으면 늘 "가족과 꿈을 포기하고 회사를 위해 헌신 할 줄 아는 사람들"이라는 의미로 들릴까요?