역시나 오늘도 겐도형 블로그에는 좋은 글이 올라왔다. (트랙백 따라 가면 글을 읽을 수 있다.) 겐도형 글을 읽다가 갑자기 열의가 생겨서 글을 쓴다.
고객이 요구하는 시스템의 규모는 커짐에 따라, 예측가능한 수준에서 제품을 만들어내기는 점점 어려워지고 있다. 그러다 보니 요새는 각종 방법론이 난무하는 형편이다. 그런데 더 사람을 혼란스럽게 만드는 것은 다양한 방법론이 서로의 장점을 받아들이고 있다는 사실이다. 어쨌든 방법론이라는 것이 그것을 지원해 줄 강력한 도구가 없으면 이론일 뿐, 상용에서 사용될 수는 없다. 결국 도구를 보면, 어느 정도 수준까지는 최신 방법론의 보편적인 경향을 알 수 있다고 볼 수 있을 것이다.
Refactoring
Extreme Programming 또는 Test Driven Development에서 본격적으로 연구됐던 Refactoring은 이제 보편적인 기술이 됐다. JAVA 커뮤니티의 Eclipse나 NetBeans에서는 일찌감치 Refactring 도구가 IDE에 통합되어 있었고, .NET 진영에서는 VS.2005부터 Refactoring을 공식적으로 지원된다. (물론 그 이전에도 .NET 커뮤니티는 각종 상용,비상용 Refactoring 도구(Resharper등)를 사용해왔다.)
Unit Test
이 또한 TDD에서 가장 적극적으로 사용됐다. 시중에서 구할 수 있는 상용, 비상용 단위 테스트 도구만 하더라도 수십, 아니 백여가지에 이른다. (닷넷 쪽에서만도 확인한 것만 10개를 넘는다.)
UML
유명한 CASE 도구를 사용하여 UML으로 디자인하면, 그에 부합하는 코드를 자동생성해 준다.VS.NET 2005에서도 이와 같은 기능이 내장된다. (베타 2 시디가 도착하면 본격적으로 사용해보려 한다.) 프로토타입의 형태라 할지라도 설계가 우선시 되야지, 주먹구구식으로 개발에 들어가면 안 된다고 생각한다. 하지만 제대로 설계할 수 있는 사람이 얼마나 되는지는 의문이다. 개인적으로는 어떤 대기업과 작업을 하는데, 하도 스펙이 엉망이라 욕을 바가지로 한 적도 있다. -_-
Team Project
소프트웨어 개발은 최소한 팀 단위로 이뤄진다. 이를 지원하기 위한 여러가지 도구가 있다.
1. 소스 관리
CVS가 제일 유명하다.
MS사의 Source safe는 그동안 악명을 떨쳤었는데, 이번에 새 버전이 나온다니 두고 볼 일이다.
2. 버그 트랙
음, 버그 트랙에 대해서는 이론으로만 안다. 나중에 회사에 도입하자고 건의하려고 벼르고 있다. 진지하게 검토라도 해주면 좋으련만……
3. 커뮤니케이션 & 프로젝트 일정 관리
이와 관련된 도구 중엔 MS 사의 Project 서버 밖에 모른다. 사실 이 도구마저 내가 쓸 일은 없었다. 다른 팀에서 쓰는 것을 구경하고 있을 뿐이다. 강의를 들었던 모회사 이사의 말로는 여러 제품을 검토했지만, 막상 구입한 제품은 없다고 한다. -_-
결론
이래저래 소프트웨어만큼이나 개발조직의 규모도 커지고 복잡해지고 있다. 수많은 방법론과 도구가 넘쳐나고 있고, 앞으로는 더 심해질 것이 분명하다. 하나도 이해하기 힘든 판에 이 많은 것을 언제 다 익히냐고 고민하지 않을 수 없다.
결국 이제 소프트웨어 개발의 성공 여부는 개인이 아니라 조직에 달렸다고 할 수 있다. 지속적으로 조직을 개선하고, 좋은 Practice을 조직 차원에서 받아들여야 한다. 거기에 경력개발 트리를 확실하게 제시할 필요도 있다. 대체로 시장 상황을 살펴보면, 회사 내부에서 인재를 키우기 보다는 외부에서 데려오려고 한다. 하지만 요즘 아주 잘 나가는 모 회사(CMM 레벨이 몇이더라, 하여간 꽤 높다.)의 이사(위에서 언급한 사람)의 말에 따르면, 조직 차원의 역량을 키우는 것은 최소한 3년이 필요한 작업이다. 그런데 개인이 익힌 Practice가 조직에 흡수되기 전에 회사를 옮기면 아무것도 안 되는 것이다. IT기업의 이직률이 높은 것을 진지하게 문제로 받아들여야 한다.
— 블로그 이전하기 전 트랙백
겐도사마의 재림:
형상관리 03/18 02:09
