오늘은 너무 훌륭한 기사를 발견하여 포스팅하는데 의미를 두고 11-1편이라 이름지었다.
국방일보의 국방과학연구소에서 K-200 장갑차를 만들당시의 기사에서 발췌하였다.

“선행개발 단계의 기술시험과 운용시험에서 우리는 2000여 항목 이상의 결함을 발견해야 한다고 각오하고 시험을 실시했다.”

　시험평가를 주관하는 군의 목소리가 아니었다. 연구개발(R&D)을 주도한 국방과학연구소(ADD) 연구원들의 톤 높은 목소리였다. 시험평가란 구성품을 잘 제작해 제대로 종합했는지, 그 과정과 결과의 잘잘못을 따지는 절차는 아니다. 연구개발 단계에서 발견되는 결함이나 오류는 정식 생산 단계 즉, 양산을 통해 나온 최종 제품의 그것이 아니므로 해결만 되면 문제될 것이 없다. 오히려 시험평가를 통해 결함을 많이 찾아 해결할수록 최종 제품의 완성도는 높아지는 것이다.

　‘한국형 장갑차’의 선행 시험평가에서는 204개 항목의 결함을 발견해 해결했다. 이 2000여 항목의 결함 발견 의지와 발견한 204개의 결함! “장갑차 모델 이름을 왜 ‘K200’이라고 지었을까?”라는 의아심이 든다면 그 답은 여기에서 찾아야 한다. 200은 바로 결함 발견 목표 2000개를 상징하고 있는 것이다.

나는 애자일을 방법론이라 정하지 않는다.
애자일은 개발 철학이며 그 중심에는 "회고"라고 하는 일련의 "성과평가"와 TDD 즉, 자동화된 Unit TEST를 통한 반복개발이 자리잡고 있다.

현재 내가 리딩하고 있는 개발조직 역시 SVN으로 소스 형상관리 정도에 만족하고 있는 조직이었고 이러한 개념을 이해시키고 시간예측과 품질예측, 요구사항 형상관리 부분에 있어서는 개발자 스스로 거부하는 조직이다.
이러한 조직에 맞춤으로 리딩할 필요성은 언제나 상존한다.

그럼에도 TDD를 포기하기 힘든 이유는 바로 국방과학 연구소에서 1984년에 (무려 26년전에) 저러한 모토로 개발에 임했다는 것이다.

개발자가 개발과정에서 오류를 범하는 것은 실력과 관계없는데도 불구하고 오류가 사전에 들어나는것을 부끄러워 한다는 것이 Mind의 문제 그리고 가장 중요한 "질책"이라는 책임의 문제이기 때문일까?

Software개발자들은 우리 나라에서 그것도 26년전에 했던 것을 못한다하면 무엇이 문제일까?