●어떤 프로젝트인가?
버스 운행 관리(BMS)를 위한 시스템입니다.
각 버스에 정보 처리 단말기를 설치하여 단말기는 GPS를 이용하여
현재 지나치는 교차로나 정류소에 관련된 정보와 운행 관련 정보를 처리하여
센터로 무선망(CDMA)을 이용해 전송을 합니다.
센터는 그 정보를 바탕으로 출/도착 정보를 공유하고
버스간에는 앞차/뒷차 간의 운행 간격을 제공합니다.
그 중에 버스에 설치되는 단말기의 Software부분 개발이 저희가 작업한 프로젝트입니다.

●몇 명이 몇 개월 작업한 것인가?
총 개발 기간은 3달 정도였고
Firmware 작업에 3명이 투입되었고,
Linux Porting에 2명이 작업하였습니다.
Paper work및 현장 작업을 담당해준 친구도 2명 있었습니다.
지금까지 유지 보수 계약에 따라 1명의 엔지니어가 관리하고 있습니다.

●언어나 플랫폼은?
ARM9을 사용한 단말기이고 언어는 C++을 사용하였고
GTK+위에 wxWidgets을 이용하였습니다.
Database는 SQLite를 이용하였고
UnitTest는 CPPUINT을 이용하였습니다.
CI는 cruisecontrol을 이용하였습니다.

● 전체 라인수는 어느 정도?
전체 라인 수는 23000line정도 입니다.

●테스트 케이스는 몇 개 정도?
테스트 케이스는 총 112개입니다. 좀 부족한 감이 많습니다.

●테스트할 때 어려운 문제는 없었는지. 어떻게 해결했는지?
1. 테스트 케이스를 만들어 낼 때 하나의 김밥 썰기 보다 김밥 해체 하기가 주를 이루게 되어서
함수간 의존성 등이 존재하는 경우가 간혹 발생해
테스트를 통합하여 module을 만들 때 예상치 못한 side effect가 있었습니다.
후반기 들어서는 테스트 케이스를 작성할 때
균형감을 유지하기 위해 많이 노력하였습니다.
균형감을 유지하는 데는 pair만 한 게 없었습니다.
동료와 테스트 케이스를 만들 때부터 수다 떨면서 작업하다 보면 서로에게 많은 영감을 줄 수 있었습니다.

 2. Network단에 적용된 Mock Object를 수정하는 경우
 대량의 test case를 수정해야 하는 상황이 발생해서
 상당히 귀찮은 적이 있었습니다.
 가능한 하나의 단위테스트에 여러 가지가 중복되지 않게 하기 위해 노력했지만
 State pattern같은 순차적 테스트를 해야 하는 경우는
 mock의 변화에 대한 해결책을 아직 못 찾았습니다.

3. 불필요한 Accessor들이 생겨납니다.
최근까지도 고민했던 부분들인데
Private으로 처리되었던 부분들이 Test Case때문에 Public이 된 상황에 대한 이야기입니다.
테스트 케이스를 작성할 때 friend를 이용하여 처리한 경우도 있고(이러면 Class단을 조건부 컴파일로 관리해야 합니다.)
귀찮을 때는 그냥 Public으로 선언하였습니다.
훌륭한 설계자 모임에 가입할 수 없어질지는 모르겠지만
요즘에는 Test를 위한 권한 조정은 설계를 크게 해친다고 생각이 들지는 않습니다.

●비슷한 프로젝트를 하려는 팀들에게 어떤 조언을 해주고 싶은지.
1. 후반기 작업이 바빠지고 다양한 요구사항들이 변경이 되서
약 2주간 1명의 엔지니어가 더 투입이 되었습니다.
결론적으로 이시기에 Test를 작성하지 않고 작업한 내용이 급증하였습니다.
복잡도도 이시기에 작성된 함수들이 전반적으로 높은 점수를 유지하고 있습니다.
인력을 더 투입하는 것 보다 가치가 떨어지는 부분을 약간 뒤로 미루는 것이
좀 더 현명한 것이 아닐까 합니다.

2. 상시적인 Pair를 권해 드립니다.
가능한 많이 떠들면서(프로그래밍과 관련 없는 수다도 상관없습니다.) 작업할 것을 권해드립니다.
Peopleware에서 아저씨들이 조용한 환경을 이야기 했지만
저희의 경우는 조용할 수록 무섭기만(?) 하고 아무런 활기도 느낄 수 없었습니다.
활기가 없을 때의 코드는 황무지 같습니다. 고쳐야 할게 많았습니다.
그러나 떠들면서 Pair를 한 코드는 참으로 예쁩니다.
Refactoring도 더 해주고 싶습니다.
코드만큼 빈익빈부익부가 통하는 게 없는 것 같습니다.
예쁜 코드일 수록 사랑을 많이 받아 더욱더 깨끗해져 갑니다.
Clean code that works의 기본은 Pair로 부터라 생각합니다.

3. TDD는 생각보다 어렵지 않았습니다.
저도 좀 더 공부하고 고쳐 나가야 하지만 크게 어려움을 느끼지는 못했습니다.
테스트 케이스를 만들어 내는 과정도
Pair를 하면서 둘이 자리에 앉았을 때 우리가 하고자 하는 게 뭔지를 Check-in하고 나면
(물론 성숙도는 차이가 나겠지만) 작성에 크게 어려움이 없었습니다.
제가 기간 내내 팀원에게 가장 많이 한 말은 "너의 의도를 밝혀라"였습니다.
참고로 프로젝트 중반 쯤에 설계상의 결함이 발견되어
Event를 중간에서 처리하는 Queue를 통째로 수정해야 하는 경우가 발생했습니다.
Queue를 사용하는 덩치 큰 클래스도 많고
특히 많은 Thread들이 이 Queue를 중심으로 동작하고 있어
수정을 해도 될지 걱정이 많았습니다. 예전의 나였다면 가능한 상태를 유지하고 주변을 바꾸려 했을 겁니다.
하지만 동작하는 테스트 코드가 있다는 것은 생각보다 용기가 됩니다.
결과적으로 총 3시간 정도의 시간으로 성공적으로 수정이 되었고
준공이 끝난 지 1년이 되어가지만 아직 그 부분에서 결함이 발견되고 있지는 않습니다.
이것이 TDD의 힘이라고 생각합니다.

4. 관리자가 Agile을 의심한다면 아닌 척 할 필요도 있습니다.
감리를 담당한 분들이 Agile의 A도 모르는 분들이라 설명하려 해도 받아 들이게 할 수가 없었습니다.
수 십 년 씩 업계에서 폭포수와 함께 해 오신 분들에게
가능한 설계를 뒤로 미룬다는 따위의 이야기는 통할 리 만무합니다.
그래서 굳이 설명하지 않았습니다.
원하는 문서작업은 별도의 인력을 투입해서 낭비된 면이 없지 않지만
최소한 감리나 고객으로부터 일체의 불평을 듣지 않았습니다.
오히려 2주 단위로 나오는 발행에 크게 감동을 받아 프로젝트 말미에는
(Acceptance Test를 진행할 무렵) 새로 뭐 테스트 할게 있냐, 나는 걱정하지 않는다는 말을 고객으로부터 들었습니
다.

5.임베디드 상황이 너무나 다양하지만 환경제약에 너무 고민하는 경우가 많습니다.
하지만 저희는 가능한 Desktop과 같은 환경을 구축하기 위해 많은 노력을 기울였습니다.
OpenEmbedded를 사용해서 CrossCompile대한 부담을 대폭 낮추고
사용하고자 하는 플랫폼은 가능한 풀버전을 쓰기 위해 노력했습니다.
현재 ARM9이나 ARM11정도이면
Appllication 작업을 좀더 compact하게 구성하면 충분히 풀버전의 Framework을
임베디드 환경에서 쓸 수 있음을 경험하였습니다.
참고로 현재 진행중인 프로젝트(ARM11) 중 하나는 wxRuby를 이용하여
임베디드에서 Ruby로 Phone Application을 제작하여 외부 심사위원으로부터 긍정적인 평가를 받았습니다.
이것도 거의 풀버전의 Ruby로 작업이 되었습니다.

●평가는 어떤지?
1. 고객의 평가
위에서도 말했지만 고객의 만족도가 높았습니다.
참고로 저희가 프로젝트를 맡기 전에 다른 회사에서 납품을 했었는데
폭포수 모델의 전형을 보여주어서 준공나기 직전까지도
완성된 배포본이 발행되지 않았을 뿐만 아니라 버스 설치 후에도
잦은 Reset으로 불만이 상당히 높았습니다.
그것과는 상반되게 저희는 매 반복주기마다 실제 단말에서 돌아가는
firmware를 가지고 테스트차량에서 테스트 진행하는 모습이
인상적이었고 신뢰를 심어 주었다는 이야기를 들었습니다.
그리고 고객의 잦은 요구사항에 대한 대응을 유연히 하고
고객이 원하는 동작이 포함된 firmware를 빠르게 배포하는 것에 가치를 집중했더니
나중에는 오히려 고객이 기능 중 일부는 불필요하다면서
기능을 빼주는 실로 경이로운 장면이 연출되기도 했습니다.