아마 개발자라면 누구나 잘 갖춰진 환경에서 개발 하고 싶을 것이다. 잘 갖춰진 환경이란 개발프로세스 또한 포함할 것이면 그것은 결과적으로 결과물도 좋게 만들리라 생각할 것이다.
어떤 일이든 간에 잘하고 싶다면 나보다 나은 사람에게 배우는 방법이 가장 빠른 방법일 것이다. 특별한 몇몇은 다를 수도 있겠지만 보통 사람이라면 혼자서 어떤 것을 진정 그것이 의미하는 것을 알아가는 것은 많은 시간이 필요하다. 하지만, 어떤 것은 시간을 많이 들여도 불가능한 것도 있다. 그래서 사람들은 더 빨리 잘해지기 위해서 책을 읽는다든지 하는 방법으로 나보다 더 잘하는 사람들에게 배우려고 노력하고 있다.
개발에서도 마찬가지이다. 개발하기 좋은 환경을 갖추고 싶다면 먼저 그런 환경을 겪었던 사람들에게 배우는 것이 가장 효과적이다. 하지만, 일부 사람들같이 맹목적으로 그것을 모두 수용하다가는 오히려 부작용을 낳을 것이다. 가장 중요한 것은 그것들의 ‘의도’를 제대로 파악하는 것이 중요하다.
‘의도를 파악하라’라는 말을 그토록 강조해서 처음 들어본 곳은 예전에 개인적으로 참가했던 이봉석님의 세미나에서였다. 이봉석 님은 하제 소프트 대표이사이시고 디바이스 드라이버와 관련해 우리나라에서는 어느 정도 권위 있는 분이다. 그분 세미나는 물론 주제의 내용도 좋았지만, 그것보다 개인적으로 더 좋았던 것은 어떤 것을 보더라도 항상 그것의 의도를 파악하려고 노력해야 한다는 학습방법(?) 같은 것을 깨 닳은 것이다. 책에 그려진 삽화 같은 것이 그런 예가 될 수 있을 것이다. 단순히 그어진 선일지라도 저자가 분명히 말하고 싶은 내용이 있을 것이고 그것을 파악하는 사람만이 그것의 진정한 의미를 알 수 있다.
나는 그 후부터 어떤 그림 하나를 보더라도 저자의 의도를 파악해 보려고 많이 노력하고 있다. 저자의 의도를 이해하려는 노력 없이 내 생각대로만 읽는다면 아마 내용의 오인으로 말미암아 오히려 독이 될 수도 있을 것이다. 핑계이긴 하지만 때문에 요즘 나는 많이 읽기보다는 하나를 봐도 좀 천천히 보는 편이고 기술서적 독서량은 좀 줄은 편이 되었다.
요즘 나는 한참 관심을 두고 있었던 부분은 현재 개발하는 프로젝트의 인지도 향상에 관한 부분이었다. 나는 개발자이기 때문에 개발 이슈에서부터 이런 인지도 향상의 방법을 찾고자 노력했었는데 그것 중 한 가지가 CMMI(Capability Maturity Model Integration, 역량 성숙도 모델 통합)에 대한 부분이었다.
물론 우리 팀이 CMMI 5단계의 인증을 받는다면 하면 인지도 향상 및 프로젝트를 내다 팔 수 있는 시장이 엄청나게 확대될 수도 있을 것이다. 하지만, 실제 프로세스 개선을 위해 만들어진 이것이 프로젝트의 인지도를 향상시키는 데 얼마나 도움이 될 것인지는 의심해볼 만하다. 심지어 그런 의도를 가지고 접근한 기업이 CMMI의 인증을 받기 엄청난 비용(컨설팅 비용까지 1억~1억 5천만 원 정도)의 소요와 CMMI 1.2의 유효기간 3년의 제약조건을 버텨낼 수 있을 지가 의문스럽다. 원래 의도대로 프로세스 개선을 위한 방향 지침 정도로 생각했어야 했다. 이것을 오인해 대박을 내게 해주는 만능 도구로 생각했던 것이 잘못 이였던 것이다.
개발 세계에서는 그것의 의도를 파악하지 못해 잘못 해석하고 그 때문에 오류를 발생시키는 일들은 엄청나게 많다. 비단 CMMI에 대한 내 생각에 대해서만 예를 들었지만 이렇게 의도를 파악하지 못하는 곳에서 발생하는 오류는 수없이 많을 수 있다. 기술적으로 가장 기본적인 스킬인 언어 문법의 의도와 API 함수와 클래스의 의도, 시스템 구성의 미들웨어(middleware) 및 각각 프로그램들, 데이터베이스 스키마(schema)의 의도를 먼저 잘 파악하는 것이 가장 중요한 부분이 될 것이다. 더 나아가서는 상사나 동료 직원과의 의사소통이나 기타 업무 처리 능력도 의도를 얼마나 잘 파악했는지에 달렸다고 말할 수 있을 것이다.
