밝혀두건데, 이번 “SW개발자들이여, ‘람보’가 되라” 사건(?)의 폭풍의 핵이신 김대환 사장님과 병특으로 2년째, 프리랜서까지 포함하면 3년째 같이 일하고 있습니다.

‘람보’라는 마초적인 단어가 내포하고 있는 의미는 영화에서 처럼 무식하게 혼자 일을 다 해치우는 슈퍼 울트라 히어로 메가톤급 개발자를 의미하는 것은 아니라고 생각합니다. 소프트웨어 분야는 분명, 소프트하며 이런 특성은 한명의 인력이 해낼 수 있는 것이 10인분 많게는 100인분이라고 볼 수 있지요. 코드의 미적 요소 (건축과 비견되는 것입니다. 웹디자인 생각하지 마세요.), 효율성, 매일 부딪히는 수학문제들(주로 Complexity지요.)과 같은 두뇌의 회전 방향에 의해 결정되는 것들이 많은 것이 소프트웨어 산업의 현장입니다.

물론, 원천적인 이야기입니다. 실제로는 코드의 미적요소, 효율성, Complexity등의 핵심적인 것들은 바라보지도 못한 채, Feature들을 일일이 Copy & Paste로 붙여넣어 고쳐서 구현하기에 바쁜 것이 우리네 개발자의 현 주소입니다. 이렇게 작업하다 보면, 결국 개인의 능력이 아무리 뛰어나도 크레믈린이 되는 것이고, 복잡해진 것들을 덮어버리기 위해 전문용어를 이용해 화려하게 설명해버리지요. 또한, 다른 핑계를 대며 일을 돌리게 됩니다.

람보가 되라는 것은 자신을 바꾸라는 이야기와 같습니다. 흡사 “능력을 키워라” 처럼 보일 수 있는 부분입니다만, 사실 단순한 부분입니다. 다른 부서와의 인터페이스 능력을 좀 키워주고, (즉, 주로 영업팀을 잘 달래라는 이야기입니다.) 자신이 하는 일을 공개해서 인정 받고, (크레믈린 타파, 문서라면 더 좋겠지요.) 인터페이스 능력과 공개를 통한 인정은 바로 시스템으로 이어집니다.

많은 분들이 시스템을 먼저 바꾸어야 하지 않느냐! 라고 이야기 하십니다. 하지만, 저는 이렇게 묻고 싶습니다. 왜 시스템을 바꾸려 하지 않느냐라구요. 대부분의 현장에서는 크레믈린화가 되어있을 것이고, 이 크레믈린화는 다시 말하면 일시적인 권력이라고 볼 수 있습니다. 이 일시적인 권력을 이용해 다른 부서를 납득시키고, 여러 괜찮은 책들을 권해보시는 건 어떨까요? eXtream Programming Explored나, 프로젝트 데드라인 같은 좋은 책들 많습니다.

사람들은 모릅니다. 개발이 어떻게 진행이 되고, 개발이 얼마나 힘든 작업인지. 그리고, 얼마나 고도의 집중력을 요구하며, 얼마나 많은 고민이 필요한지를 다른 부서의 사람들은 모릅니다. 어쩌면, 옆자리에 앉은 동료도 모를지도 모릅니다. 혼자 10인분을 하려면, 이런 것들을 어필하고 이해시키고, 술 한잔 하면서 우는 소리도 하며, 주변의 양해도 구해내야 합니다. 이런 기본 준비가 완성되어야, 비로소 10인분의 람보 개발자가 될 수 있는 것이지요. (사실 아직도 pair-programming 같은 경우는 도입 실패…)

다른 부서와 파워게임을 하란 소리는 아닙니다. 양해와 납득, 이해와 동조를 얻어내라는 이야기입니다. 저런 상황을 만들어 낼 수만 있어도, 못해도 3인분은 할 수 있을 겁니다.

또다른 많은 분들은 팀단위의 경쟁력을 논하십니다. 하지만, 개인적인 공부와 관조를 통해 얻어낸 직관력과 실력으로 문제를 풀어내는 뛰어난 개발자가 있는 것과 없는 것은 팀단위 경쟁력에서 엄청난 차이가 납니다. 문제를 해결할 실마리, 번득이는 아이디어는 그냥 나오는 것이 아니지요. 어려운 수학문제 하나를 놓고 그저 그런 학생 100명이 브레인 스토밍 해도 답은 안나옵니다. 팀단위 경쟁력은 그 아이디어들을 얼마나 빨리 verify할 수 있느냐이지 그 아이디어를 얼마나 빨리 만들 수 있느냐가 아닙니다. verify를 빨리 해봐야 아이디어가 없으면 말짱 도루묵이지요.

그래서, 개인적인 노력과 발전이 엄청나게 요구됩니다. 꾸준히 다른 패러다임을 흡수 (주로 다른 언어를 공부하는 것으로 채우지요.) 하고, 새로운 경향과 새로운 기법들의 철학을 공부해야 겨우 뒤쳐지지 않을 수 있습니다. 대표적인 툴킷인 MFC를 봐도 그렇습니다. UI쪽의 대안인 AWT/Swing, GTK, QT, wxWidget, Tcl/Tk, Motif등 다들 철학도 다르고 구현 컨셉도 다릅니다. 자신이 하고있는 MFC만 알고 있다면, 저런 다른 프로젝트에서 하고 있는 철학은 평생 모르고 가겠지요. 자료구조 쪽에서 보면 아름다운 STL과 섹시한 Boost는 만나지도 못한채 답답하고 지저분한 MFC에 묶여 살게 될겁니다.

“나는 이걸로 밥벌이가 되니까 상관 없어” 라는 것 만큼 자신에게 해가 되는 생각은 없습니다. 특히나 싸이클이 엄청나게 빠른 IT분야. 그중에서도 소프트웨어 산업에서는 더욱 심합니다. 넓게 공부하고, 깊게 이해한 개발자가 되어야 팀의 능력이 살아납니다. 그리고, 팀동료를 배려하고 지식을 공유해야, 자신이 편합니다. 팀이니까요.

당연한 이야기들입니다. 하지만 어려운 이야기들 입니다. 누구나 할 수 있지만, 누구나 어려워 하는 일들입니다. 개발자들이 될 수 있는 것에 대한, 할 수 있는 것에 대한 제안입니다. 시스템은 누가 바꾸라고 해서 후딱 바뀌는 것은 아닙니다. R&D에서는 훨씬 심하지요. 결국은 생산자의 입장에서 바꾸어 나갈때 가능해 질 일들입니다.

개발자는 갖추어지지 않은 시스템에 의한 피해자이며, 그 시스템에 대한 가해자이니까요.

+ 그러는 너는 잘했느냐? 라고 물으신다면, 그럭저럭 힘들지만 해나가고 있습니다. 라고 답하겠습니다.

왜 람보 개발자인가?

왜 람보 개발자인가?”에 대한 1개의 생각

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.