brunch

You can make anything
by writing

C.S.Lewis

by 이경종 Oct 16. 2019

마우스 개발자(Mouse Engineer)

허영심은 말을 많이 하게 하고 자존심은 침묵하게 한다
-쇼펜하우어

개발자(Developer)라는 말은 이 업계에 있는 사람들에게는 통상적인 단어지만, 보통의 사람들에게는 생소하게 다가올수 있다. IT업계에서나, 이 책에서 언급되는 개발자나는 통상 소프트웨어 개발자를 이야기하지만 사실 개발자라 함은 소프트웨어 개발자일수도 있고 하드웨어 개발자일수도 있고 이 둘을 아우르는 시스템 개발자일수도 있다. 개발자를 포괄할 수 있는 상위 개념의 명칭으로는 엔지니어(Engineer)가 있고, 그 위로 과거만 하더라도 신성치 못한 단어 취급을 받았던 공돌이라는 호칭이 있다. 이 글에서는 소프트웨어 개발자를 세 가지 유형으로 분류해서 이야기하려 한다.

첫번째 개발자 유형은 이론가이다. 이들은 박학다식한 이론으로 중무장하고 있으며, 이 이론들을 현업에 적용하고자 항상 노력한다. 이론과 실천이 조화를 이루면 두말할 나위 없이 좋은 개발자라고 할 수 있겠지만, 이론을 강조하는 개발자들 중 우리가 흔히 얘기하는 '마우스(Mouth) 엔지니어'들이 많다. 마우스 엔지니어들은 어설프게 알고 있는 지식들 – 특히 학교에서 배웠던 원론적 이론 –을 본인이 잘 알고 있는 것으로 착각하는 경우가 많다. 또한 이 지식들과 현업에서의 괴리에 대해 그리 심각하게 고민하지 않는다. 그로 인해 어설픈 이론들을 억지로 현업에 끼워 맞추려는 시도를 마다하지 않는다. 이론가들은 고지식한 사람들이 많으며 원칙론자들인 경우가 많다. 일관성 있는 개발과 정도를 벗어나지 않는 일 처리가 장점이 되기도 하지만, 때론 그런 장점들이 융통성이 없음이라는 단점으로 바뀌는 경우 개발 유연성의 부족, 개발 일정지연 등의 문제를 야기하기도 한다. 소프트웨어 코딩의 분야에서 이론가들이 싫어하는 최악의 개발자들은 땜빵코드를 남발하는 개발자들이다. 그들은 땜빵코드로 전체코드가 지저분해지는 것을 경멸한다. 땜빵코드 그 자체는 물론 좋지 않지만 때로는 땜빵코드가 필요악이 되기도 한다는 사실을 그들은 결코 용납할 수 없다. 땜빵코드로 인해 일시적이나마 문제 해결을 하고 비즈니스적인 위기를 모면할 수 있음에도, 엔지니어의 자존심 하나로 이를 용납치 못 하고 어물쩡거리다 회사나 조직에 손실을 입히기도 한다. 필자가 지금까지 보아온 바, '어설픈 이론가'들 역시 현업에 적응(?)하고 나면 끝내는 땜빵코드의 유혹에서 자유롭지 못하다.

어설픈 이론가들은 현업에 잘 적응하지 못 하는 경우가 많고, 특히 제조업체와 같이 컨슈머 디바이스(Consumer Device)를 직접 개발하고 생산하는 조직에서는 특히 더 적응을 잘하지 못 하는 경향이 있다. 거꾸로 이들은 직접적인 결과물을 바로 내놓지 않아도 되거나 이론적인 연구비중이 높은 연구소나 선행개발조직에서는 그 실력이 들통나지 않은 채 비교적 순탄한 개발자 생활을 하기도 한다. 마우스 엔지니어들은 겉으로는 많이 알고 있는 것처럼 보이고 이론의 중요성을 강조하지만, 실상 개발업무에 있어 뛰어난 결과를 내는 경우는 드물다.

소싯적에 '명문대학 졸업 후 유수의 회사에서 다양한 경력을 쌓은 한 고참개발책임자'와 일한 적이 있었다. 그는 이론과 원칙을 중시하고, 아름답지 못한(?) 코드에 대한 극도의 혐오증을 가지고 있었다. 그는 경력만큼이나 아는 것이 많았으며, 실제로 현업 프로젝트에서 하나의 소프트웨어 플랫폼(Platform)을 도입하기도 했다. 하지만 그가 도입한 소프트웨어 플랫폼은 현업에 적용 결과 많은 문제점과 막대한 금전적, 시간적 손실만을 남긴채 사장되고 말았다. 그렇게 된 이유를 살펴 보면, 해당 플랫폼은 사실 그가 처음부터 설계한 것이 아니라, 어디서 써본적 있는 그럴듯한 플랫폼을 가져온 것이었다. 원본 플랫폼은 근본적으로 매우 훌륭한 구조를 지니고 있었음에도 불구하고 프로젝트는 결국 실패하게 된다. 해당 플랫폼 자체가 프로젝트에서 필요로 하는 소프트웨어와 맞지 않기도 했지만, 근본적인 실패의 원인은 결국 그가 해당 플랫폼을 제대로 알지도 못 한 상태에서 현업 프로젝트에 적용하였기 때문이였다. 그조차도 완벽하게 이해하고 있지 못 하는데, 해당 플랫폼을 처음 접한 같은 팀 개발자들은 어떻했겠는가? 원본 플랫폼에 존재하지 않는 확장부분을 개발하는 과정에서 비정상적인 구현부분들이 생겨나게 되었고, 결국은 더 이상 수습이 불가능한 기형적인 소프트웨어 플랫폼이 되고 말았다.

문제의 본질은 개발책임자가 자기가 아는 바를 너무 과신했고, 본인 역량 밖의 일을 시작한 것에 있다. 계속하여 문제가 되는 상황을 그는 하나도 수습하지 못 했다. 입으로는 소프트웨어 플랫폼이 지향해야 하는 원론적인 이론들과 해당 플랫폼의 우수성에 대해 떠들어대고, 결국 경영진이 혹해서 프로젝트에 투자하게 만드는데 성공했지만, 그조차도 일이 막장으로 치닫게 될 것을 예상하지 못 했던 것 같다. 이후 그는 다른 프로젝트에서도 좋은 성과를 거두지 못 하고 결국 회사를 떠났다. 얼마전 지인의 결혼식장에서 우연히 그와 다시 만났다. 아는 사람 몇명과 함께 조그만 벤처회사를 하고 있다고 했다. 그가 하고 있는 사업은 주로 정부과제라고 했다. 말을 좀 나눠보니 여전했다. 그 정도의 지식과 간판, 그리고 포장실력이라면 상용화가 필요없는 소규모 정부과제가 천직이 될 수도 있겠다는 생각이 들었다. 눈 먼 세금이 그의 월급으로 들어가고 있다는 생각에 그리 기분이 유쾌하진 않았다.

어설픈 이론가와 마우스 엔지니어들의 특징은 처음 시작은 거창하고 그럴 듯 하다는 것이다. 조금 코드가 어설퍼보이더라도 이미 검증된 코드를 쓰는 편이 바람직함에도 불구하고, 기존 코드를 날려버리고 새로운 코드를 작성하곤 한다. 이론적인 고급지식 및 기술들을 많이 차용하여 상급자가 보기에도 뭔가 그럴 듯 하게 보일 수 밖에 없다. 위에 보고하기에 딱 좋은 경우다. 프로젝트가 진행되면 될수록 개발은 산으로 가기 시작한다. 여기서 진정한 이론가와 어설픈 이론가(마우스 엔지니어)의 차이가 드러나기 시작한다. 어설픈 지식은 저주가 되어 결국 프로젝트의 실패로 이어지고, 조직의 패망까지 초래할 수 있다.

두번째 개발자 유형은 테크니션(Technician)이다. 이들은 개발에 있어 툴(Tool)이나 장비와 같은 도구들에 많이 의존하는 경향이 있다. 천성이 공돌이인 개발자들에게 이런 경향이 많다. 테크니션들은 도구를 잘 다루고, 문제 해결에 적절히 활용할 수 있는 능력을 가지고 있다. 하지만 어설픈 테크니션들은 좋은 툴과 고가의 장비를 가지고 있으면 마치 본인이 슈펴 개발자가 된 듯한 착각에 빠지기도 한다. 소프트웨어 코딩의 경우, printf만을 가지고 쉽게 접근할 수 있는 디버깅 문제를 굳이 현란한 그래픽을 제공하는 디버깅 툴을 사용하는 오버헤드도 마다하지 않는다. 이런 부류의 개발자들은 기법(Technic)을 중시한다. UML을 잘 다루는 것을 소프트웨어 설계를 잘 하는 것이라고 생각한다. GDB를 잘 다루는 것을 본인의 디버깅 능력과 동일시 한다. 리눅스 vi 단축키를 많이 알고 있는 것을 본인의 코딩실력으로 착각한다.

테크니션이 빠지기 쉬운 함정은 도구 자체에 집착해서 일의 목적를 망각하는 것이다. 고가의 툴과 장비에 과하게 의존하는 경우도 있다. 굳이 사용이 필요하지 않는 경우가 있음에도 불구하고, 너무 도구들에 의존하다 보니 가끔씩은 불필요한 삽질을 하느라 아까운 시간을 날려버리기도 한다. 본인이 일을 잘 하지 못하는 이유를 좋은 도구를 가지고 있지 않은 회사 탓으로 돌리기도 한다. 테크니션들은 대부분 얼리어답터들이다. 새로운 도구가 나오면 기존 도구를 사용하는데 문제가 없음에도 불구하고 새로운 도구를 기어코 사용해봐야 직성이 풀린다. 이들은 개발자가 천직이므로 일도 즐겁게 하고, 변화에 대한 거부감도 적어서 새로운 기술을 받아들이는데 있어 저항도 적다. 이런 일하는 태도 덕분에 회사에서는 이들을 선호하게 된다. 도구를 선호하고 잘 활용하는 것 자체는 문제가 되지 않는다. 마우스 개발자가 테크니션인 경우는 상황이 심각해진다. 고도의 지식적 허영을 갖춘 고가의 도구 수집가가 된다.

마지막 유형은 '그냥 개발자'이다. 마지막 유형을 특정한 단어로 분류하는 것은 쉽지 않다. 이들은 지식도 좀 부족해 보이고(자신의 지식을 떠벌리지 않으므로), 도구를 그리 많이 사용하지도 않는다. 얼핏 노가다처럼 개발하는 것처럼 보이기도 한다. 외부에서 봤을때는 가장 뭔가 없어보이는 개발자라고 할 수 있다. 그러나 이들의 문제해결능력은 뛰어나다. 여기서 말하는 문제해결능력은 디버깅과 같은 제품 결함에 대한 해결능력만을 말하는 것이 아니다. 이들은 문제를 바라봄에 있어 궁극적인 최종 목적을 항상 염두에 둔다. 이것이 구체적으로 어떤 문제인지, 미 해결시 발생하게 될 연쇄적인 문제들은 무엇인지부터 정리한다. 그리고 어떤 형태로 언제까지 해결을 해야 하는지 최종적인 목표에 대한 명확한 정의를 한 이후 최선책과 차선책, 그리고 현실적인 절충안등을 마련한다. 본인이 할수 있어도 다른 개발자가 하거나 개발 외적인 도움을 받는 것이 전체적인 프로젝트에 있어 최선이라면 굳이 본인이 문제를 해결하지 않는다. 한마디로 어떻게 일해야 하는지 아는 개발자들이다. 업무에서 성과를 내지 못하는 다른 개발자들의 경우 좁은 안목을 가지고 있는 경우가 많다. 굳이 본인이 디버깅을 하지 않아도 더 쉽게 문제를 해결할 수 있는 방안이 있는데도(다른 개발자들의 도움 내지는 개발 외적인 해결), 공돌이답게 그냥 문제를 후벼 파며 다른 가능성에 고개를 돌리지 않는 외골수들이 의외로 많다. 본인이 해결해야 하는 문제에 대해 밤을 새워가며 버그를 찾아내서 해결하고 유레카를 외치는 것만이 진정한 개발자의 특성은 아니다.

진정한 개발자들은 빠르고 효율적이다. 어이없는 슛을 남발하지 않는다. 최단의 시간에 최선의 결과를 만들어낸다. 비록 이론은 좀 부족하고, 최신의 도구들은 잘 다루지 못 해도 본인이 맡은 일에 대해서는 언제나 최고의 결과를 보여준다. 단언하자면, 개발자는 결과로 이야기하는 프로라고 할 수 있다. 입으로 본인의 지식을 떠벌리지도, 현란한 도구 사용능력을 자랑하지도 않는다. 진정한 개발자의 특징들은 전형적인 공돌이의 특징들과는 무관하다. 오히려 전략적인 사고와 효율을 강조하는 경영자의 모습에 가깝다. 다시 말해 진정한 개발자는 경영적 사고를 통한 문제해결능력이 탁월한 사람이라고 할 수 있다.

통상적으로 개발자들에게는 위에서 언급한 세가지 부류의 특징이 혼재되어 있다. 가장 좋은 경우는 풍부한 이론을 가지고, 꼭 필요한 개발도구들을 잘 다루면서 문제해결능력이 뛰어난 개발자라고 할 수 있겠지만, 어느 한 부분이 두드러져야 한다면 단연 마지막 유형의 개발자 유형이 바람직하다. 궁극적으로는 이런 개발자가 성공하고 조직에서 환영받는다. 그들은 처음에는 두드러지지 않는다. 주목받지도 않는다. 하지만 최종적인 결과는 항상 그들의 편이다. 자신이 어떤 유형에 가까운지 냉정하게 생각해볼 필요가 있다.

keyword