jaso extends j2ee

개발자들이여 글쓰기를 피하지 마라.

유명한 소프트웨어 공학자인 Steve McConnell 이 쓴 "Professional 소프트웨어 개발" 에는 개발자의 Role 중의 하나로 글쓰기를 지적하고 있다.

최근 개인 블로그가 유행하면서 많은 사람들이 자신만의 글을 쓰고 있지만 대부분 자신이 직접 글을 쓰기 보다는 다른 블로그를 스크랩하여 단순이 의견을 달거나 아니면 해외 블로그에 대한 번역 정도이다.

필자 또한 글쓰기를 잘하는 것은 아니다. 필자 역시 처음 글을 쓸때에는 두려움도 많았다. 내가 쓴 글이 남들이 우습게 생각하지 않을까하는 두려움이 많았던 것이다. 어렸을 때 숙제로 일기를 쓰면서 선생님, 친구들이 보면 어떡하지 하는 것과 같은 심리일 것이다.

글쓰기에 필요한 시간을 만들어라.

국내 개발자가 처한 환경에서 자신만의 글을 쓰기 위해 가장 부족한 것은 시간이다. 하루 18시간 이상 일하고 있는 프로젝트에 투입되어 있으면서 글을 쓴다는 것은 상상조차 할 수 없다. 최근 개발 트렌드를 따라가는 것 조차 어려울 것이다.
필자의 경우에도 처음에는 이 부분이 가장 어려웠는데 이제 조금 생활의 패턴을 찾았다. 회사 내의 직급도 어느 정도 관리의 영역에 있기 때문에 스스로의 시간관리를 할 수 있는 점도 있지만 필자의 패턴은 다음과 같다.(프로젝트 관리자에게는 알리지 말길...)
필자의 개발 속도는 다른 개발자에 비해 다소 빠르다고 할 수 있다. 물론 개발 분야에서 자신만의 글을 쓸 수 있을 정도라면 모두 마찬가지 일것이다. 하지만 개발 속도가 빠르다고 해서 프로젝트에서는 너는 빨리 끝났으니 쉬라고 하는 프로젝트는 없다. 더 많은 일이 온다 ^^
그래서 필자의 경우 매월 조금씩 개발하는 양을 줄여 나갔다. 내가 개발해야할 부분에 대해서는 가능한 빨리 종료 시킨 후 보고는 계속 진행 중으로 보고를 한 후 매일 2시간 정도 개인적인 공부 또는 글쓰기에 할애를 했다. 물론 가능한 관리자에게는 보여주지 않는 것이 좋다. 필자의 경우 주로 출근 후 1시간 정도의 시간과 점심 후 1시간 정도를 투자한다. 이때가 회의도 별로 없으며 대부분 메일을 확인하거나 웹 서핑을 하는 시간이기 때문이다.



물론 프로젝트의 성공이라는 프로젝트 팀의 공동의 목표에서 보면 내부의 적이다. 일반적으로 생각하는 팀워크적인 측면에서도 좋지 않다. 하지만 필자의 생각에 좋은 팀워크라는 것이 먼저 끝난 개발자가 서로 도와 주며 뒤쳐진 개발자의 몫까지 나눠 개발하는 것이라고는 생각하지 않는다. 이것은 모두 무덤으로 가는 지름길이 아닐까 생각한다. 빨리 개발을 끝낸 개발자는 불만이 쌓이고 이것을 본 나머지 개발자들은 생산성을 향상시킬 노력을 하지 않기 때문이다. 최적의 팀워크는 자신의 할 수 있는 최대한의 노력을 기울여 자신의 일을 완수하는 것이다. 이것이 안되었을 때에는 팀내에서 당연히 패널티가 있어야 한다. 물론 정해진 일정내에 종료하는 것은 기본이고 더 빨리 종료한 개발자에게는 인센티브가 있어야 한다. 하지만 국내 프로젝트에서 이렇게 운영되는 프로젝트는 거의 없다. 따라서 필자는 자신만의 인센티브를 만들었다. 여유 시간인 것이다.
또 다른 문제는 실력있는 개발자는 순진하다라는 것이다. 필자는 개발자들이 조금은 영악해지길 바란다. 자신을 위해 투자할 수 있는 시간을 어떤 방법을 동원해서라도 만들어야 한다. 위에서 말한 것도 이런 방법중의 하나이다. 관리자 또는 다른 개발자들에게는 미안하겠지만 최대한 시간을 만들 방법을 강구해보기 바란다. 글을 쓸 수 있을 정도의 개발자라면 자신이 프로젝트에 참여하고 있는 것 만으로도 다른 개발자들보다 더 많이 프로젝트에 공헌하고 있다는 것을 위안으로 삼으면서 말이다.

글쓰는 방법이 두려워 글쓰기를 시작하지 못하는 개발자가 있다면 다음과 같은 충고를 하고 싶다. 글을 쓰지 않고서는 글쓰는 방법을 알지못한다고...
최근에는 테크니컬 글쓰기 등과 관련된 책들이 간혹 출판되고 있는데 이런 책에서 설명하는 많은 내용들에 앞서 가장 먼저 시작해야 하는 것이 바로 글을 쓰기 시작하는 것이다. 개발자가 쓰는 글은 프로일 필요가 없다.

글을 쓰면 다음과 같은 잇점이 있다.

가장 첫번째로 분석/설계 문서를 잘 만들 수 있다는 것이다.
대부분 개발자들이 분석/설계 활동을 복잡한 다이어그램 또는 표, 양식을 이용해서 하는 것으로 알고 있는데 이것은 잘못된 생각이다. 분석/설계의 가장 핵심적인 문서는 유즈케이스라고 할 수 있는데 유즈케이스 다이어그램이 아닌 유즈케이스 정의서가 더 중요하다.
유즈케이스 정의서는 말로써 표현되며 특별한 양식은 없다. 단지 프로젝트 내에서 일정 수준의 포맷을 맞추기 위해 특별한 양식을 제시할 뿐이다. 유즈케이스 정의서 하나를 작성하는데 Alistair Cockburn은 "Writing Effective Use Cases " 라는 책 한권을 할애할 정도이니 얼마나 글쓰기가 어려운지 짐작이 간다.(참고로 이 책의 번역서에는 Alistair Cockburn을 시인으로 소개하고 있다.)
따라서 글을 잘쓰게 되면 분석/설계를 잘할 수 있는 기본 자질은 갖추게 되는 것이다.
(개인적으로는 유즈케이스 보다는 "조엘 온 소프트웨어 : 유쾌한 오프라인 블로그"에서 설명하고 있는 기능명세를 작성하는 사례가 프로젝트에 사용하기에는 더 좋지 않을까 생각한다. 기술적인 이슈 및 화면에 대한 설명 및 전개 등을 작성하도록 하고 있는데 이러한 내용까지 포함하는 것이 그 문서를 읽은 이해관계자들도 해당 유즈케이스에 대해 더 쉽게 이해 할 수 있지 않을까 하는 생각이다.- 조엘도 개발자의 글쓰기를 무지하게 강조하고 있다.)

다음으로 개발자가 글을 쓰게 되는 장점으로는 글을 쓰면 자신도 모르게 조금은 이론적이 된다. 필자의 경우 글을 쓰기 전에는 어떤 기술적인 내용에 대해서 직관으로 인식하고 있는 경우가 많다. 예를 들어 Spring에서 지원하는 AOP에 대해 "음... 메소드 단위로만 AOP를 지원하고 있군..." 까지만 생각하다가, 글을 쓰기 위해서는 "Spring의 소스를 분석한 후 AOP는 Proxy를 이용해서 AOP를 지원하고 있으며 Proxy 클래스를 이용하는 경우 InvocationHandler가 메소드 단위로만 처리할 수 있기 때문에 Spring의 AOP는 메소드 단위로만 지원됩니다."로 바뀌게 된다.

또 생각해 볼 수 있는 장점은 자신의 생각 또는 기법을 전파함으로써 표준으로 만들 기회가 된다. 이것은 비영어권인 대한민국의 슬픈 현실일 수도 있다. 아무리 좋은 기법 개념을 블로그에 올려 놓아도 읽을 수 있는 독자는 국내 개발자들 뿐이라는 것이다. 물론 영어로 블로로그를 쓸 정도의 실력을 갖추고 있는 개발자들도 있지만 극소수일 것이다. 영어권의 경우 유명한 개발 관련 사이트에 자신의 블로그를 개설한 후 자신이 익힌 개발 기법 또는 개념을 블로그에 남김는 것만으로도 그것을 표준으로 만들 기회를 가지게 된다. 이것은 오픈소스의 개념과 비슷한데 Spring, Hibernate 등이 공식적인 표준은 아니지만 개발자들 사이에는 어느 정도 표준으로 자리잡혀 가고 있다. 패턴도 이러한 예이다. 어떤 패턴에 대한 연구결과를 블로그에 올림으로써 자신이 만든 패턴이나 패턴명을 인정 받을 수 있는 기회를 가지게 되는 것이다. 너무나도 유명한 마틴파울러는 자신의 이름을 도메인(http://www.martinfowler.com/)으로 가지고 있으며 꾸준히 글을 올리고 있다.

이것 이외에도 많은 장점이 있겠지만 마지막으로 필자가 생각하는 중요한 장점은 자신의 경험과 지식을 간접적으로나마 다른 후배 개발자들에게 전달함으로써 소프트웨어 개발 업종의 기술 수준이 상향될 수 있다는 것이다. 선배들이 겪은 시행착오, 기술적 이슈들은 아주 소중한 자료로 반드시 기록되어 후배 개발자들에게 전수되어야 한다. 이것이 우리 개발자들이 제대로 대접받을 수 있는 날이 빨리오게 하는 지름길이라고 필자는 믿고 있다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준