|
|
| 2006년 새로운 개발자 문화를 만드는데 적극적으로 활동하는 것을 목표로 삼았다. 새로운 개발자 문화가 무엇일까? 먼저 현재의 개발자 문화를 한번 살펴보자. 현재의 개발자의 위상부터 살펴보자. 개발 조직 또는 운영 조직 모두 개발자를 단순히 몇개월 정도 교육시키고 프로젝트 1 ~ 2개 경험하면 아무나 하는 것으로 여기고 있다. 필자의 경험은 10년이다. 10년 동안 주어진 프로젝트, 운영 업무만 수행한 것이 아니라 나름대로 많은 책을 읽고 공부도 했다. 여러 세미나를 쫗아다니며 공부했다. 이런 필자도 아직 제대로 된 개발을 하고 있는지 의문이 든다. 공부하면 할수록 어렵기만 하다. 회사의 경영진은 이런 사실을 아는지 모르는지 궁금하다. XP 창시자인 켄트벡은 20년 이상 경험을 가지고 있다. 마틴파울러 역시 20년 이상이다. XP Installed의 저자인 론 제프리는 40년이다. 그들은 새로운 개념을 만들어내고 이렇게 만들어진 개념을 업계에서는 제품화 하는 선순환 고리가 만들어져 있다. 국내에는 새로운 개념을 만들어 낼 만큼 풍부한 경험을 가진 개발자가 없다. 국내 소프트웨어의 역사로 봤을때 20년 이상은 어려울 것이다. 하지만 지금부터라도 20년, 30년, 40년 경험한 개발자가 나올 수 있는 사회적 문화를 만들어 가야 한다. 하지만 지금의 경영진 또는 의사결정자들은 그렇게 생각하고 있지 않은 것 같다. 물론 그들이 현장에서 뛸 때에는 프로그래머는 아주 단순한 업무만 했을 수 있다. 그때에는 시스템의 복잡도가 지금에 비하면 아주 단순했기 때문이다. 메인프레임에서 COBOL로 프로그램을 만들거나, 4GL 툴을 이용하여 C/S 프로그램을 만들거나 하는 것은 지금의 시스템 개발에 비하면 너무나도 단순한 시스템이라고 할 수 있다. 그때는 DB 또는 File System과 하나의 프로그래밍 언어만 알면 된다. 동시 접속에 대한 문제, 성능에 대한 문제, 동기화, 클러스터링, 아키텍쳐, UML 등과 같은 현재의 개발자가 알아야 하는 것들에 비하면 너무 단순했다. 만일 경영진이 지금의 개발자를 바라보는 시각이 과거 자신들이 경험했던 수준의 잣대나 그것보다는 조금 더 어렵지만 그래도 프로그램 개발하는데 뭐 그렇게 많이 변했겠냐라는 관점에서 보고 있다면 정말로 잘못 보고 있다라고 외치고 싶다. 회사의 인사 정책이나 선배들은 필자를 보면서 아직도 프로그램하고 있냐는 식으로 보고 있다. 필자는 아직도 프로그램을 제대로 이해하지 못했는데 말이다. 그러면서 이들은 어느 시기가 되면 업종 전문가니 하면서 업종에 IT를 접목시킨 컨설팅을 해야 한다고 주장한다. 이것이 현재의 개발자가 처한 현실이고 위상이라 할 수 있다. 이것에 대해 필자는 다음과 같은 주장을 하고 싶다. 프로그램은 소프트웨어 관련 조직에서 가장 기본이다. 프로그램은 코딩으로서의 의미가 아닌 소프트웨어 전체를 이해하는 가장 기본적인 단위이기 때문이다. 프로그램 잘 하는 사람은 IT 관련된 모든 분야의 지식을 잘 이해하며 자기 것으로 잘 소화한다. 반면 프로그램을 못하는 사람은 IT의 다른 분야에서도 이해력이 떨어진다. 프로그램을 잘하기 위해서는 사물을 논리적으로 분해하고 이를 다시 조합하고, 창조하는 능력을 갖추고 있어야 하는데 IT의 다른 분야도 이런 것들이 동일하게 적용되기 때문이라 생각한다. 프로그램에 대한 탄탄한 기술력을 보유하지 않는 한 모든 새로운 기술, 시장에 대한 진입은 모래위에 쌓는 성이라고 주장하고 싶다. 많은 회사들이 새로운 선진 프로세스나 CMM 레벨과 같은 인증을 따고자 노력한다. 이것 역시 개발자 개인의 실력이 없는 상태라면 모두 부질없는 짓이다. 개발 조직에서는 CMM이라고 하여 소프트웨어 개발 조직의 성숙도에 대한 인증을 받고 있으며, 시스템 운영 조직인 ITO 에서는 ITSM이라는 선진 프로세스를 도입하고 있다. 하지만 개발 조직의 성숙도를 좌우하는 것은 개발 조직을 구성하는 개발자 개개인의 역량을 기본으로 하여 그 위에 표준 프로세스, 혁신 프로세스 등이 지원되어야만 진정한 CMM 레벨 인증이 될 것이다. 조직 구성원 대부분은 CMM1,2 인데 조직은 CMM 3을 획득하고 있는 것이 현실이다. ITO 역시 형상관리 도구에 대한 최소한의 이해(Check In, Check Out)도 없는 구성원이 대부분인데 이 조직을 관리하는 관리자는 우리는 ITSM 프로세스를 도입하여 적용하고 있다고 말하고 있다. CBD(Component Based Development)도 마찬가지이다. 프로젝트의 개발자 대부분은 컴포넌트는 커녕 객체지향에 대한 개념이나 구현 경험도 없는데 CBD 방법론으로 프로젝트를 하고 있다. 단순히 CBD 방법론을 사용하고 EJB, .NET 기술을 이용하였다고 해서 CBD로 프로젝트가 구축된 것이 아닌 것은 누구나 알 수 있다. 이런 문제점을 많은 개발자들이 알고 있고 술자리에서 푸념을 늘어 놓고 있다. 하지만 공식적으로 언급하거나 경영진에게 말하지 않는다. 이것이 현재의 개발자 문화가 아닌가 생각한다. (물론 문제를 해결하기 위해 적극적으로 노력하고 있는 개발자들이 있는 것도 알고 있다.) 그러면 이런 현재의 개발자 위상을 어떻게 높일 수 있을까? 개발자의 기술이 단순 기술이 아닌 아주 높은 수준의 숙련된 기술을 요구하고 있는 분야라고 경영진을 설득시킬 수 있을까? 프로젝트에서 단순 개발자들이 해야 하는 역할과 숙련된 개발자가 해야할 역할이 다르며 모두 필요하다는 것을 이해 시킬 수 있을까? CMM - Level 1: 초기(Initial) 이 단계에서는 사전에 정의된 프로세스가 거의 없으며, 프로젝트의 진행 도중에 절차가 정의되고 변경된다. 1단계 조직에서는 문제가 발생되면, 프로젝트는 계획된 절차를 버리고 코딩과 시험에 집중하게 된다. 또한 대부분의 프로젝트는 비용과 개발 기간이 초과되는 경향이 있으며, 프로젝트의 성공은 뛰어난 개발자에 전적으로 의존한다. 즉, 1단계에서의 능력은 조직이 아닌 개인인 것이다. - Level 2: 반복 (Repeatable) 1단계에서와 같이 프로세스에 대한 가시성이 전혀 없는 상태에서 개선되어야 하는 가장 중요한 것은 프로젝트 관리이다. 2단계에서는 기본적인 프로젝트 관리 프로세스가 설정되어 소프트웨어의 크기, 비용, 일정 등을 추적하고 기록한다. 2단계에 도달한 조직은 성공한 프로젝트에서 얻어진 자료를 기본으로 새로운 프로젝트를 계획하고 관리하기 때문에 프로젝트의 성공을 반복시킬 수 있다. - Level 3: 정의(Defined) 2 단계에서는 프로젝트 단위로 프로세스를 설정하여 이를 시험하고 수정하는 작업을 반복한다. 3단계에서는 그 중 효율적이고 조직과 잘 맞는 프로세스들을 선택하여 조직 차원의 표준 프로세스로 정의한다. 조직에서 수행되는 개별적인 프로젝트들은 이미 정의된 “조직의 표준 프로세스”를 프로젝트의 특성에 맞추어 조정하여 적용한다. 이렇게 조정된 프로세스를 “프로젝트에서 정의된 소프트웨어 프로세스”라고 한다. 이를 위해 조직 내에 SEPG(Software Engineering Process Group)를 구성하여, 조직에 관련된 모든 프로세스 활동을 전담하게 한다. - Level 4: 관리 (Managed) 4단계에서는 소프트웨어 제품과 프로세스에 대한 정량적인 품질 목표를 설정하고 관리한다. 이 단계에서는 조직 차원의 소프트웨어 프로세스 데이터베이스가 구축되어“프로젝트 정의 소프트웨어 프로세스”로부터 얻을 수 있는 데이터를 수집하고 분석하는데 사용한다. 모든 프로젝트에 대한 중요한 소프트웨어 프로세스 활동의 생산성과 품질이 측정되며, 성과의 변동을 수용 가능한 정량적인 범위 내로 최소화하여 제품과 프로세스에 대한 통제를 수행한다. - Level 5: 최적(Optimizing) 조직이 5단계에 이르렀다고 해서 프로세스 개선이 끝난 것은 아니다. 5단계에서는 프로세스 개선이 모든 조직구성원으로 확대되고, 지속적인 프로세스 개선을 위해 노력한다. 새로운 기술이 조직에 적용될 수 있는가를 판단하고, 필요하면 이를 수용하는 방향으로 프로세스를 개선시키며, 조직의 구성원들은 자신의 영역에서 계속해서 프로세스의 개선방안을 제안하고 전체적으로 이를 반영하여 프로세스를 개선한다. 그리고 발견된 결함의 형태가 다시 발생하지 않도록 소프트웨어 프로세스가 평가되고 얻어진 교훈이 전 조직에 확산된다. |
댓글 없음:
댓글 쓰기