편한 개발환경이 가져온 부작용

필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 

숫자를 문자로 변환한다든지, 숫자 몇 개를 정렬하는 등 아주 단순한 문제다. 코딩 테스트에서 확인하는 것은 개발자의 논리적인 사고, 창의력, 문제 해결 능력이다. 그리고 문제를 해결하기 위해서 면접관과 어떻게 커뮤니케이션을 해나가는지 보는 것도 중요한 요소다. 문법은 중요하게 보지 않고 개발언어는 아무거나 선택해도 된다. 

실제로 여러 지원자에게 코딩 테스트를 실시하면 안타깝게도 코딩 테스트를 통과하는 비율은 매우 낮다. 경력은 화려하게 잘 얘기하는데 코딩 및 논리적인 사고는 어처구니 없이 형편없는 경우가 많다. 그래서 서류 심사를 통과한 지원자를 대상으로 온라인 코딩 테스트를 먼저 실시하곤 한다.

온라인 코딩 테스트는 약간 난이도가 있는 문제를 주고 24시간 안에 코딩을 해서 제출하게 하는 것이다. 컴파일이 되어야 하고 실행이 되어야 하며 알고리즘의 효율성을 보기 위해서 실행 제한 시간도 있다. 이런 온라인 코딩 테스트는 어차피 인터뷰에서 탈락할 지원자를 걸러줌으로써 인터뷰 시간과 비용을 절약하는데 도움이 된다. 

얼마 전 온라인 코딩 테스트를 실시하는데 어처구니 없는 일이 발생했다. 온라인 코딩 테스트는 꼭 본인이 작성해야 한다는 규칙이 있다. 하지만 온라인의 특성상 주변 지인들에게 약간의 힌트성 도움을 받는 것은 어쩔 수 없다고 생각하고 있다. 출제한 문제는 유명한 코딩 테스트 사이트에서 가져온 문제다. 

하지만 지원자는 문제를 받자마자 본인이 풀 생각을 하지 않고 바로 인터넷을 검색하여 해당 사이트를 찾아냈다. 그리고 해당 문제를 푼 사람을 찾아서 소스코드를 보내달라는 이메일을 보낸 것이다. 그런데 이메일을 받은 사람은 프로 개발자가 아니라 초등학생이었던 것이다. 전문 개발자를 채용하려고 실시하는 코딩 테스트에서 자신이 못 풀겠다고 초등학생에게 소스코드를 요청하는 일이 발생한 것이다. 

인터넷을 검색해서 알고리즘을 참고한다 던지 아이디어를 구하는 것은 가능하지만 소스코드를 달라고 하는 것은 명백한 속임수(Cheating)이라고 생각한다. 이런 개발자는 실력을 떠나서 채용할 수가 없다. 

다른 사례다. 온라인 코딩 테스트를 훌륭하게 통과해서 인터뷰를 진행한 개발자 얘기다. 그런데 칠판 코딩 테스트에서 이상한 일이 발생했다. 온라인 코딩 테스트 문제는 개발자의 논리력, 창의력이 없으면 풀기 어렵기 때문에 칠판 코딩 테스트에서 좋은 결과를 보여줄 것으로 예상했는데 인터뷰 현장에서 형편 없는 결과를 보여줬다. 

혹시 긴장해서 원래 실력을 보여주지 못하는 것이 아닐까 생각해서 여러가지 질문을 해봐도 원래 실력이 없었다는 것이 확인이 되었다. 그렇게 탈락을 한 후 이상한 생각이 들어서 온라인 코딩 테스트에서 제출한 답안을 인터넷에 검색을 해보니, 해당 문제를 미국에서 자바로 풀어 놓은 답안과 한 글자도 틀리지 않고 동일한 것을 확인했다. 

그 뒤 온라인 코딩 테스트를 세상에 없는 문제로 새로 만들어야 고민을 했지만 지원자가 속임수를 쓰는지 확인할 수도 있으므로 그냥 진행하기로 했다. 단, 지원자에게는 본인이 직접 풀어야 한다고 꼭 당부를 하고 있다. 

이런 일이 발생하는 이유는 무엇일까? 요즘 개발자들은 과거에 비해서 훨씬 개발하기 편한 환경에 있다. 개발하다가 필요한 모듈이나 알고리즘은 인터넷을 검색해보면 다 찾을 수 있다. 그러다 보니 원리는 생각하지도 않고 본인이 이해도 하지 않고 그냥 인터넷에서 소스코드를 가져다가 사용하는 경우가 매우 많다.

과거에 인터넷(웹)이 없을 때나 초창기 까지는 소스코드를 구할 곳은 책을 제외하고는 별로 없었다. 그래서 개발자들이 책을 많이 보고 본인이 이해를 해서 직접 구현을 해야 했고, 그러다 보니 소프트웨어 이론에 대해서 속속들이 잘 알아야 했다. 과거에 뛰어난 개발자가 더 많았던 이유는 이런 환경에 기인한 것이 아닌가 생각된다. 

요즘은 쉽게 소스코드를 구할 수 있다 보니 깊게 생각하는 습관을 가지기는 어렵다. 개발자들의 고충을 이해하지 못하는 것도 아니다. 촉박한 시간 안에 빨리 구현을 해내야 하고 누가 설계를 잘 해주는 것도 아니고 서로 리뷰를 통해서 내가 작성한 코드를 누가 잘 봐주는 경우도 흔치 않다. 

그러다 보니 부랴부랴 인터넷에서 구한 소스코드를 이해도 못하고 그대로 사용하기 일쑤다. 요즘 개발자들을 만나보면 소프트웨어 이론을 속속들이 잘 모르는 경우가 많다. 메모리의 기본 구조도 잘 모르고 기본적인 자료구조와 알고리즘도 잘 모르곤 한다. 대학에서 이런 기본 이론을 철저히 가르쳐야 하는데 이런 이론보다 실무를 가르치는 것이 아닌가 의구심이 들기도 한다. 모든 대학이 그런 것은 아니지만 이론보다 실무를 가르친다면 학원과 다를 것이 없다. 그래서 실무 중심 사관학교라는 대학의 광고를 듣다 보면 안타까운 생각이 든다. 

이렇게 개발하기 좋은 환경이 오히려 개발자들의 실력을 떨어뜨리고 있는 것이 아닌가 걱정이 되고 있는 사례들이다. 현재 소프트웨어 공부를 하고 있는 학생이라면 실전 코딩보다도 소프트웨어 기초 이론을 철저히 익히라는 얘기를 하고 싶다. 실전 경험도 중요하지만 기초가 약하다면 언제든지 문제가 될 수 있다. 

회사에서는 개발자에게 이론, 경험을 전파하는 수단은 코드리뷰, 설계리뷰다. 선배 또는 동료가 소스코드나 설계서를 보고 리뷰를 하면서 서로의 경험과 이론, 노하우를 전달하는 것이다. 서로 리뷰를 통해서 개발자는 같이 성장해나가는 것이다. 피어리뷰(동료검토)를 하지 않거나 형식적으로 하지 않는 회사에서는 개발자들의 성장이 몇 배 느릴 수 밖에 없다. 

개발자는 구글을 믿고 개발을 할 것이 아니고 믿어야 할 것은 자신의 두뇌와 동료들이다. 구글은 단지 거들뿐이다.

이 글은 ZDNet Korea에 기고한 글입니다.

인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는 제대로 달릴 수 없었다. 

어린 마음에 참 대단하다는 생각을 했고 운전자 없이 도로를 달리는 차들을 상상해 보기도 했다. 그러나 그 뒤에 어떻게 되었는지는 알 수가 없다. 

하지만 현재 구글은 이미 실용적인 수준의 무인 자동차를 개발했다. 시중에 운전자가 없는 자동차가 굴러다니는 것을 볼수 있기 일보직전이다.  둘의 차이는 무엇일까? 

20년전 필자가 다니던 H사는 전국적으로 뛰어나다는 소프트웨어 개발자들이 모여들었다. 필자가 참여했던 프로젝트 중 하나는 팀원이 4명이었다. 그런데 같은 종류의 제품을 만드는 미국의 경쟁회사인 C사는 프로젝트 팀원이 400명이었다. 4대400으로 경쟁하는 것이었다. 그때는 내심 부러워했지만 그때 만약 400명의 개발자가 있었다면 미국 회사 정도 제품을 만들어 낼 수 있었을까? 나는 프로젝트 팀원이었는데 스펙을 본 적도 없다. 스펙이 없기 때문이었다. 나는 팀장이 구두로 설명하면 일을 하곤 했는데 400명의 개발자가 추가 됐어도 크게 다르지 않았을 것이다.

그 당시 H사를 다니던 뛰어난 개발자들은 전국 각지의 회사들로 흩어져서 일당백의 개발자로 일하고 있고, 들으면 알만한 수많은 소프트웨어를 개발했다. 하지만 안타깝게도 글로벌 시장에서 성공한 소프트웨어를 개발한 사례는 내 기억에는 없다. 돈을 많이 번 사례로는 게임회사를 운영한 경우가 있지만 게임의 핵심 경쟁력이 소프트웨어는 아니기 때문에 예외로 해야 할 것이다. 작은 회사를 유지하면서 건실하게 유지하고 있는 회사도 있지만 큰 회사로 성장한 경우 소프트웨어 역량은 형편없어지는 사례를 자주 보았다. 

한국에서 개인 또는 소수 개발팀이 소프트웨어를 알차게 만들어서 꽤 인기를 끄는 경우를 종종 보게 된다. 규모가 꽤 큰 외국 개발팀에서 생산하는 소프트웨어보다 괜찮은 경우도 있다. 이런 굉장한 효율을 보여주는개발팀은 대부분 10명이하의 소규모팀이다. 

하지만 개발팀이 수십, 수백명이 넘어가면 효율은 점점 떨어진다. 개발자가 1000명이 넘는 회사를 가보면 거대한 개발조직이 가지고 있는 장점을 별로 찾아볼 수가 없다. 개발자는 1000명이지만 개발자 10명짜리 회사가 100개 모여있는 것처럼 느껴진다. 팀간에 지식은 공유가 잘 안되고 협조하기도 쉽지 않다. 하나의 거대한 지식 공동체라기보다는 조직적으로 잘나눠지고 관리되는 팀일 뿐이다. 

이런 현상은 현재 일하고 있는 개발자들 탓은 아니다. 한국 개발자들도 지식 공동체가 잘 구축되어있는 회사에서 처음부터 개발을 시작했다면 어떻게 서로 지식을 공유하고 협업하는지 자연스럽게 몸에 익혔을 것이다. 그런 문화속에서 대규모 프로젝트를 이끌 수 있는 아키텍트가 탄생하기 마련이다. 하지만 그런 문화가없는 조직에서는 기업의 문화를 그대로 배울 수 밖에 없다. 

비싼 툴을 쓴다고 프로세스를 강화한다고 해서 지식공동체가 만들어지는 것은 아니고 오히려 점점 멀어지게 된다. 

지식을 공유한다고 이슈관리시스템을 쓰고 위키, KMS를 도입하지만 골프채를 바꾼다고 골프를 잘치게 되는 것은 아니다. 툴은 필요하지만 먼저 문화를 익혀야 한다. 문화는 사회에 나와서 갑자기 익히기도 어렵다. 학교에서부터 공유, 토론, 협업문화를 익힐 수 있는 수업을 위주로 문화를 구축해 나가야 한다. 

한국에서 미국에 이민을간 중학생이 미술 수업시간에 그림을 그리는데 반에서 가장 잘그렸다. 하지만 B 학점을 받았다. A 학점을 받은 학생은 자신보다 그림을 못그렸지만 그림에 대해서 설명을 훨씬 잘했다고 한다. 

미국에서는 대학수업 대부분의 과목에 토론수업이 병행되고 있다. 강의를 받고 끝나는것이 아니라 그만큼의 토론수업이 또 진행된다. 토론이 항상 몸에 베이게 되는 것이다. “토론, 까짓별거야? 우리도하면되지”라고 생각하면 오산이다. 

십여년을 토론수업을 하면서 배워온 사람들과는 문화적인 차이는 명백히 드러난다. 토론을 몸으로 익혀온사람들은 소프트웨어를 개발할 때도 적절한 커뮤니케이션과 공유, 협업이 자연스럽게 이루어진다. 

대규모 프로젝트의 성공은 뛰어난 아키텍트에 달려있다. 한국에 뛰어난 프로그래머는 많지만 뛰어난 아키텍트는 절대적으로 부족한 이유가 이런 환경에 기인한 것이라고 생각한다. 개발자 10만 양병설, 초등학생 SW 교육을 외치기 전에 문화를 바꾸는데 더 노력을 해야 한다. 

SW교육, 프로그래밍이 핵심 아니다

메르세데스벤츠의 CEO 디터는“이제 자동차는 기름이 아닌 소프트웨어로 달린다”고 말했다. 앞으로의 산업에서 소프트웨어가 차지하는 중요도를 단적으로 나타내는 말이다. 과거 전세계 제조업시장에서 1등자리를내주었던 미국이 세계 최고의 소프트웨어 기술을 기반으로 제조업 부활을 위한 용트림을 시작했다. 

우리나라 전자 회사들이 그 짧은 기간에 외국의 세계 1등 기업들을 제치고 매출에서는 세계 최고가 되었지만 점점 넘지 못할 벽으로 점점 뚜렷하게 다가오는 것이 바로 소프트웨어의 역량 차이다. 개별적인 근면 성실함과 똑똑한 머리와 치열한 의지로 외국에서 100년 넘게 이룩한 산업기반을 몇 십 년 만에 앞지른 분야도 있지만 소프트웨어 분야에서는 차이를 좁히기는커녕 점점 더 뒤쳐지고 있는 듯하다. 

과거 소프트웨어라고 하면 워드프로세서나 스프레드시트, 게임 같은 것을 먼저 떠올렸다. 하지만 사실 하드웨어에 장착되는 임베디드 소프트웨어의 시장도 만만치 않게 컸고 규모는 점점 커지는 양상이다. 소프트웨어가 제조업의 기반을 뒤흔들 정도가 됐다. 옛날에는 소프트웨어는 제조업 즉, 하드웨어의 보조적인 역할에 불과했으나 지금이나 앞으로는 소프트웨어가 오히려 기반산업이 되어가고 있으며 소프트웨어 역량이 제조업 경쟁력의 핵심이 되어가고 있다. 

세상은 소프트웨어를 중심으로 바뀌어 가고 있는데 필자가 접한 대기업을 비롯한 수많은 회사들의 대응은 무신경하기 그지없다. 몇몇 기업은 소프트웨어의 중요성을 외치고는 있지만 그 대책이 소프트웨어를 전혀 모르는 탱크 같은 추진력을 가진 경영자에게 모든 것을 맡기고 기껏해야 개발자들을 끊임없는 밤샘 작업으로 내몰고 오히려 불편한 비싼 툴을 사주고 프로세스는 과도하게 복잡하게 해서 품질을 올린다고 한다. 

경영자가 소프트웨어를 모르니 잡상인에 현혹되는 것은 당연하다. 이런 식으로 소프트웨어 경쟁력을 높인다고 하니 경쟁력이 오히려 떨어지는 것이 이상할 일이 아니다. 

다행히 몇몇 기업은 소프트웨어 전문가를 경영진으로 채용해서 진정한 소프트웨어 역량 발전에 힘을 쓰고 있지만 기업의 정치 역학 구조에서 소프트웨어 전문가들이 힘을 제대로 못쓰는 경우가 많아서 안타까움을 더하고 있다. 즉, 소프트웨어 전문 경영자들이 실력은 있는데 정치에서 밀리는 것이다.

지금 당장 기업들은 소프트웨어 역량 부족으로 발등에 불이 떨어졌지만 더 중요한 것은 미래다. 전체 산업에서 차지하는 소프트웨어의 비중은 향후 10~20년 동안 폭발적으로 증가할 것이 확실시 되고 있다. 즉, 20년 후에는 엄청난 수의 소프트웨어 개발자가 필요하게 된다. 

소프트웨어 개발자가 많이 필요하다고 해서 착실한 준비없이 급하다고 학원 같은 곳에서 개발언어 약간 가르쳐서 저급 개발자를 양산해서는 소프트웨어 경쟁력을 가질 수 없다. 급하게 부족한 인력을 보충할 수는 있겠지만 지금과 같이 열악한 소프트웨어 환경을 더 악화시키는 역할을 할 것 같은 우려가 된다. 

소프트웨어가 산업이 중심이 되는 미래를 대비하기 위해서는 초, 중, 고 모든 과정에서 필수적으로 소프트웨어를 대비한 교육을 해야 한다. 소프트웨어 교육이라고 하면 개발 언어를 가르쳐야 한다고 생각하면 눈감고 코끼리의 뒷다리를 만지는 격이다. 현재 우리나라 소프트웨어 역량이 뒤쳐지는 이유가 코딩을 잘 못해서는 아니기 때문이다. 개발 문화와 환경을 바꿀 수 있는 교육을 해야 한다. 

먼저 소프트웨어에 기초가 되는 지식을 좀더 많이 가르쳐야 한다. 수학, 논리학, 과학 등 논리적인 사고를 좀더 많이 하게 하고 뛰어난 논리력을 가지고 있는 학생들에게 좀더 많은 기회와 동기를 부여해야 한다. 

다음으로는 소프트웨어 문화를 바꿀 수 있는 교육을 해야 한다. 소프트웨어 개발에서 가장 중요한 것이 협업이다. 그러기 위해서 토론, 협동, 발표를 위주로 한 교육을 해야 한다. 과거에는 한 반에 학생이 60~70명이나 되어서 토론식 교육이 불가능했지만 지금은 20~30여명의 학생이라서 토론식 교육이 충분히 가능하다. 학교에서도 토론식 교육을 점점 증가시키고 있지만 너무 더디다. 자칫 배 떠난 뒤에 손 흔드는 격이 될 수도 있다. 좀더 과감히 비중을 늘려야 한다. 

뻔하고 당연한 얘기 같지만 학부모로서 아이들의 교육과정을 지켜보면 급격한 변화에 대응하여 무신경하고 느리기 그지없다. 

암기 잘하는 학생도 공부를 잘한다고 할 수 있겠지만 토론을 잘하고 발표를 잘하는 학생에게 좀더 높은 점수를 주고 이런 학생들을 많이 키워내야 한다. 소프트웨어 개발의 핵심 역량은 토론과 협업이다. 어릴 때부터 몸에 베어 있지만 않으면 성인이 되어서 갑자기 잘 할 수는 없다. 

학생들에게 프로그래밍을 가르치는 것은 그 후순위가 될 것이다. 이런 조건 없이 프로그래밍만 가르치고 사지선다식 시험을 본다면 지금보다 나아질 것은 전혀 없다. 프로그래밍도 토론, 협업, 발표를 융합한 교육이 되어야 한다. 

필자는 지금 우연한 기회에 영재 초등학생에게 프로그래밍을 가르치고 있다. 그 결과 초등학생들이 절대 학습시간이 부족하여 프로그래밍 실력은 성인에 비해서 떨어지지만 논리력은 성인 못지 않게 뛰어나다는 것을 알게 되었다. 사실 웬만한 개발자보다 논리력이 뛰어나기도 하고 이런 초등학생들이 개발 문화를 몸에 익히고 프로그래밍 실력까지 갖춘다면 미래에 뛰어난 소프트웨어 아키텍트로 성장할 것으로 확신한다. 우리나라는 이런 미래의 소프트웨어 아키텍트가 수천명, 수만명이 필요하다. 우리나라가 2등국가로 떨어지지 않으려면 꼭 필요하다. 

이것이 당장 학생들에게 제대로 된 소프트웨어 교육이 필요한 이유다. 

이글은 ZDNet Korea에 기고한 글입니다.

한국에는 가짜 CTO가 많다

소프트웨어 회사에서 가장 중요한 한 사람을 꼽으라고 하면 단연 CTO다. 회사 전체 기술의 총 책임자이며 기술 비전과 로드맵을 이끄는 핵심이다. 회사 비즈니스 전략을 기술에 녹여내는 중추 역할을 한다. 회사 기술을 속속들이 알며 개발에 관련된 프로세스와 문화를 발전시켜나가는 사람이다. 

뛰어난 CTO가 없는 소프트웨어 회사는 기술의 바다에서 선장 없이 헤매는 배와 같다.소프트웨어 회사가 아니어도 요즘 웬만한 회사는 소프트웨어 분야가 상당히 중요하기 때문에 소프트웨어 부문 CTO가 필요하다. 자동차 회사나 전자 회사도 소프트웨어를 이끌기 위해서는 소프트웨어 CTO가 필요하다. 

그러나 한국에서 뛰어난 소프트웨어 CTO을 접하기란 하늘에 별따기와 같다. 많은 회사들은 CTO가 아예 없다. CTO의 필요성을 모르거나 CTO를 할 만한 사람이 없는 경우가 많다. CTO가 정확하게 무슨 역할을 해야 하는지 모르는 경우도 있다. 이런 회사는 개발팀장이나 연구소장이 이런 저런 기술 이슈에 관여를 하기는 하지만 CTO의 역할을 대체하지는 못한다. 

회사에 CTO가 있어도 하는 일은 CTO가 아닌 경우가 많다. 즉, 가짜 CTO인 경우다. 명함을 받아보면 CTO라고 되어 있는데 하는 일을 보면 CTO가 아니고 연구소장 등 관리자의 역할을 하는 경우다. 주로 하는 일은 전체 개발 조직을 관리하고 여러 프로젝트의 진행을 챙기는 등의 관리 일을 많이 한다. 또 경영자에게 보고를 하기 위한 보고서를 만드는데 시간을 쓰기도 한다. 이런 일을 하면서 기술을 챙기기란 시간적으로도 불가능하다. 

원래 CTO를 할 수 없는 사람이 회사의 권유로 CTO를 하는 경우도 많다. CTO가 되려면 Technical career path에서 벗어나지 않고 꾸준히 개발자로 성장을 해왔어야 한다. 또한 아키텍트 역할을 꾸준히 해서 회사의 최고 아키텍트가 되어 있어야 한다.

그러나 우리나라에서 개발자의 경력을 꾸준히 유지하기란 여간 어려운 일이 아니다. 우리나라에서 개발자 경력을 보장해주는 회사는 몇% 안된다. 설령 개발자 경력을 보장해 주는 회사도 진짜로 개발자 경력 보장의 의미를 알고 보장해 주는 회사는 또 몇% 안된다. 그러다 보니 진짜 개발자로서 경력을 보장 받으면서 꾸준히 성장하는 비율은 내 생각에 1%도 안된다. 

이런 환경에서 진짜 CTO의 자격과 실력을 갖춘 개발자가 나오기란 거의 기적과도 같은 일이다. 

B사는 CTO의 필요성을 인지하고 C사의 연구소장을 CTO로 모셔왔다. 하지만 C사에서 연구소장의 역할은 관리자였던 것이다. 그러다보니 B사에서 CTO가 제대로 CTO 역할을 하기란 어려웠다. 그 뒤에 CTO를 다시 바꿨지만 새로운 CTO도 경영자 출신으로서 진짜 CTO역할을 하기에는 적합하지 않았다. 

가짜 CTO들은 회사의 기술을 속속들이 모른다. 개발자 출신인 경우도 있지만 관리와 개발을 넘나들다 보니 이제는 기술을 속속들이 모르고 피상적인 결정밖에 못하는 경우가 많다. 이 정도의 기술 리더십으로 본인이 CTO인줄 착각하는 경우도 있다. 역할은 CTO인데 실제로는 관리를 시키는 회사도 많다. 관리란 대단히 많은 시간과 노력을 필요로 하기 때문에 관리를 하면서 기술을 제대로 챙기기란 쉽지 않다. 

한국에서 뛰어난 CTO를 만나보기 힘든 현실은 한국 소프트웨어 개발 환경이 이렇게 열악한 이유 중 중요한 하나다. 소프트웨어를 제대로 개발하기 위해서 개발 문화의 발전보다는 프로세스의 강화로 접근하는 이유도 CTO의 부재인 경우가 많다. 

소프트웨어를 잘 모르는 경영자나 관리자는 문서화를 잘하고 엄격한 프로세스를 철저히 지키면 소프트웨어가 제대로 개발 될 것으로 착각한다. 공장에서 제품 조립하는 것처럼 생각하는 것이다. 뛰어난 소프트웨어 CTO가 있다면 회사에 어떤 프로세스와 문화를 도입해야 회사의 현실에서 가장 소프트웨어를 효율적으로 개발할 수 있을지 판단하고 이끌어갈 수 있다. 

CTO가 필요하고 지금 당장 아무나 CTO로 임명을 할 수는 없다. 외부에서 뛰어난 CTO 후보를 찾는 것도 한 방법이지만 한국에서 개발자로 20~30년 꾸준히 성장한 개발자를 찾기란 매우 어렵기 때문에 이 또한 쉽지 않다. 시간이 걸리더라도 회사 내부에서 개발자들의 경력을 보장해주고 뛰어난 개발자일수록 관리로 시간을 빼앗기지 않고 개발자로서 성장을 해서 미래의 CTO가 될 수 있도록 여건을 만들어 줘야 한다. 외국에서 CTO를 데려오는 방법도 있지만 언어적인 장벽과 문화적인 괴리 때문에 적응하기 쉽지는 한다. 

벤처투자자들도 소프트웨어 회사에 투자를 할 때 가장 중요하게 보는 인력은 CTO다. 뛰어난 CTO는 회사의 성공에 중요한 열쇠다. 지금이라도 회사에서 가장 뛰어난 개발자들이 개발팀장이다 연구소장이다 해서 관리에 메어 있다면 이들이 미래와 기술 조타수가 없는 회사의 미래를 걱정해 봐야 한다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

SW개발, 착한 리더보다 독한 리더가 낫다

몇년전 A사에서 이슈관리 시스템 도입에 대해서 경영자와 의논한 적이 있다. A사는 이슈관리시스템을 사용하고 있지 않았고 버그만 엑셀 파일로 관리하고 있었다. 

이슈관리시스템이 꼭 필요한 상황이었고 당장이라도 도입해야 했었다. 하지만 경영자는 결단력있게 결정을하지 못하고 일단 모든 직원들이 공감을 할 수 있도록 설득을 해야한다는 것이었다. 그렇게 직원들을 설득하는데 시간이 소요되고 결정을 해야할 시점에는 다수결로 결정해야한다고 했다.

얼핏들으면 경영자가 독선적이지 않고 직원들의 마음을 헤아린다고 생각할 수 있다. 이런 경영자는 직원들이 싫어하는 일은 안하려고 한다. 직원들이 싫어하는 것을 하게될 경우 직원들의 호응도 떨어질 것이고 결국 실패할것이라는 것이다. 그렇게 다수결에 의한 결정으로 이슈관리시스템 도입에 실패한다면 과연 회사에 잘된 결정일까? 잘못된 결정일까? 

사회가 민주화 되다 보니 민주화를 해야할 것과 그렇지 않은 것이 헷갈리는 경우가 발생한다. 개혁에 대한 중요한 결정을 다수결로 결정하는것은 어리석은 짓이다. 그 이유는 대부분의 직원은 변화를 싫어하기 때문에 회사에 필요한 결정이 다수결로 통과되기는 어렵다. 통찰력을 가지고 있는 경험이 많은 리더가 과감하게결정해야 한다. 직원들 90%가 반대한다고 해도 회사에 꼭 필요하다고 생각하면 결단을해야 한다. 

소프트웨어 회사에서 민주적인 경영자는 두 부류가 있을 수 있다. 

첫째, 소프트웨어 개발에 대해서 잘모르는 경영자다. 

소프트웨어 개발에 대해서 잘 모르기 때문에 팀장들이 하는 얘기를 그대로 들어줄 수 밖에 없는 경우가 많다. 결국 개발자들이 편한대로 회사를 이끌다가 주먹구구식 개발에서 못벗어나게 된다. 변화는 꼭 필요하나적응하기 전까지는 불편하고 거북한 것이기 때문에 누가 강요를 하지 않으면 변화하기 어렵다. 

반대로 개발도 잘 모르면서 독재적인 경영자도 있다. 이런 경영자는 개발팀에 대한 신뢰도 부족하고 본인이개발팀을 뜯어고쳐보려고 다양한 시도를 한다. 

그러면서 개발팀에 진짜로 필요한 변화가 무엇인지 잘모르고 엉뚱한것을 강요하기 시작한다. 엉뚱한 기법을 도입하기도 하고 황당하게도 비싼시스템을 구축하기도 한다. 회사역량으로는도저히 쫓아가기 어려운 복잡하고 무거운 프로세스를 도입하기도 한다. 대기업에서 흔히 이런 일들이 벌어진다. 알지도 못하면서 독선적인 개발자는 모르면서 민주적인 경영자와 똑같이나쁘다. 

둘째, 과거에 주먹구구식으로 개발 꽤나 해본 경영자다. 

이 경영자는 코딩은 좀 해봐서 개발에 관련된 얘기를 하면 대충 알아 듣기는 하나 정작 회사의 미래를 위해서 무엇이 필요한지는 잘모른다. 과거 독재형 경영자에 대한 나쁜 기억도 있고 개발자들의 얘기를 잘 들어주는 마음씨 좋은형과 같은 경영자가 된 경우다. 

개발자들이 이런저런 고충이 있다고할 때 내용을 꽤나 잘 이해한다. 그래서 개발자들의 불만은 무시하지 않고 들어주려고 한다. 그러다보니 정작 필요한 개혁은 못하고 사사건건 개발자들을 설득하려고하고 다수결로 결정을 하려고 한다. 개혁을 통해서 앞으로 나아가지 못하고 주먹구구식 개발에 머물러 있거나 기형적인개발 형태로 발전하기 쉽다. 

경영자는 독해야 한다. 독재를 말하는것은 아니고 통찰력이 있어야 하고 과감히 추진을 해야 한다. 마음씨좋은 동네형 같은 경영자가 되어서는 안 된다. 보통의 경영자는소프트웨어 개발을 잘 알기 어렵다. 그래서 CTO가 필요한 것이다. 소프트웨어 개발과 기술에 관련된 결정은 CTO가 하는 것이다. 

필자가 만나본 소프트웨어 회사는100여개가 넘는데 그중에서 진짜 CTO가 있었던 소프트웨어 회사는 한손가락을 꼽고도 손가락 몇개가 남는 정도였다. 그만큼 CTO에 대한 인식도 부족하고 CTO급 역량을 가진 개발자가 부족한 것이 우리나라의 현실이다. 

이슈관리시스템 도입에 주저하고 다수결 결정을 시도했던 A사는 수년이 지났지만 여전히 과거의 개발방식에 머물러 있고 어려움을 겪고 있다. 이제는 회사 내부구조가 과거보다 몇 배 복잡해져서 변화를 하기는 점점더 어려워지고 있다. 

회사는 성장하는 과정에서 변화를 해야하는 결정적인 순간이 온다. 그 시기를 놓치면 기회는 또 다시 오지않는다. 개발자가 30명일때 개발 방식과 프로세스를 바꾸지 못하면 개발자가 100명이 되고 고객이 몇배로많아진 시점에서는 바꾸기 더 어렵다. 

결정적인 시기를 놓치면 영원히 좋은 시기는 오지 않거나 몇배의 고통을 감내해야 한다. 

이런 다수결 결정은 개발할 때도 종종 벌어진다. 소프트웨어 개발은 수많은 결정의연속이다. 아키텍처를 결정할때도 많은 결정을 해야 한다. 예를들어서 자바로개발할까 C++로 개발을 할까 팽팽히 맞서있는 경우 개발자들이 자신들이 좋아하는 개발언어를 주장하면서 한치도 물러서지 않는다고 하자. 이때 다수결로 결정하는 경우가 있다. 

다수결은 점심메뉴 결정할 때나 쓰면 된다. ,자바로 개발해야 하는 이유와 C++로 개발해야 하는이유를 제대로 설명하고 끝장을 보더라도 토론을 해서 결정해야 한다. 이때 회사의 경영전략과 비전 등을 모두 고려해야한다. 끝까지 결론이 안나면 CTO가 결정하면 된다. 

경영자에게 민주적 행동을 기대해서는 안 된다. 그만큼 경영자는 자신의 결정에 책임이 따른다. 이런 책임을 피하려고 민주적으로 행동한다면 죽도 밥도 안 된다. 자신의 결정을 책임지지 못하고 직원들의 결정을 따라야할 만큼 무능하다면 경영자 자리에서 물러나는게 낫다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

첫째, NIH(Not Invented Here)신드롬이다. 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

셋째, 우리는 다르다고 생각하는 것이다. 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 

대부분의 개발자들은 경력이 쌓이면서 자연스럽게 관리 업무를 겸하거나 아예 관리자로 전환된다. 관리와 개발업무를 동시에 하는 개발자들도 관리하랴, 회의하랴 바빠서 본인이 가장 잘하며 좋아하는 개발 업무와는 점점 멀어지게 된다. 또 관리를 하지 않으면 회사에서 파워가 줄어들거나 대우도 안 좋기 때문에 자연스럽게 그리고 본의 아니게 관리 쪽 진로를 선택하지 않을 수 없게 된다. 종종 자신은 끝까지 개발만 하겠다고 고집하는 개발자들은 관리 능력, 커뮤니케이션 능력이 떨어지는 괴짜라고 생각하는 이상한 시각도 존재한다. 

S사의 예를 보자. 이 회사는 오래 전부터 개발자 경력을 보장해주고 있다. 제도적으로는 개발자 트랙을 선택한 사람들은 관리를 하지 않고 개발만 계속 할 수가 있다. 하지만 속을 보면 개발자 트랙을 선택하나 그렇지 않으나 큰 차이는 없다. 개발자 트랙을 선택한 경우에도 개발 일에만 집중할 수 없고 그렇지 않은 경우에도 개발과 관리를 겸하게 된다. 개발과 개발이 아닌 일을 명확하게 구분하지 않고 두루뭉술하게 일을 해서 대부분은 개발 경력이 쌓일수록 개발에 집중할 시간은 점점 줄어들게 된다. 

T사의 경우 10년차 이상이 되면 팀장이 되고 파트장을 맡는다. 대부분 회사에서 가장 뛰어난 개발자들이다. 하지만 관리를 조금이라도 맡은 이상 낮에는 개발에 집중할 시간이 거의 없다. 보고서 작성에 회의 참석, 다른 부서와 의견 조율, 이런 일로 하루를 보내다가 저녁이 되어서야 개발 일을 시작한다. 이런 생활을 몇 년 하다보니 자연스럽게 개발 일에서 손을 놓게 되었다. 

이런 회사에 경영자들에게 왜 회사의 가장 뛰어난 개발자들이 개발을 거의 못하는 관리 일을 시키냐고 물어보면 다음과 같은 얘기를 한다. 

“당연한 것 아닌가? 소프트웨어 개발은 워낙 특수해서 개발을 속속들이 잘 알아야 개발 조직을 관리할 수 있다. 그가 우리 회사에서 소프트웨어 개발을 가장 잘아는 사람이다. 그래서 그에게 개발 조직 관리를 맡기고 있고 본인도 그 자리를 원하고 있는 것으로 알고 있다.” 

주변에서 소프트웨어 업계의 유명했던 롤모델들을 보면 지금도 개발을 하고 있는 사람들은 그렇게 많지 않다. 왕년에 개발을 좀 했던 실력자이지만 현재도 개발을 하고 있는 엔지니어는 만나기 힘들다. 왠만한 뚝심으로는 개발자로 남아 있기가 어렵다. 당사자들이 환경에 순응해서 개발에서 손을 놓게 된 경향도 크다 

우리는 각 기업의 최고 개발자였지만 지금은 관리자인 사람들을 종종 만나게 된다. 이들은 대부분 본부장, 센터장, 부서장, 연구소장 등과 같은 직함을 가지고 있다. 이들 대부분은 과거에는 개발자였을지 모르지만, 그리고 지금도 코드를 잘 읽을 수 있을지 모르지만, 관리자로 몇년만 지나면 더 이상 개발자가 아니다.

개발도 잘하고 관리도 잘한다는 것은 착각이다. 관리자가 된 이상 개발에 대해 특히 아키텍처나 구체적인 기술에 대해서 이러쿵저러쿵 참견하는 것은 매우 위험하다. 관리를 잘하는 것이 본인의 업무이고 그것만도 매우 어렵다. 

나는 블로그를 통해서 자신의 회사에서 개발자 경력을 보장하고 있는지 설문 조사를 한적이 있다. 과거 4년동안의 통계를 보면 개발자 경력 보장 제도가 있는 회사는 14%이다. 물론 제도는 있어도 형식적이거나 현실적으로 개발자로 남기 불가능 회사가 많기 때문에 실제 개발자가 경력을 보장받을 수 있는 비율을 훨씬 떨어지게 된다. 한마디로 20년, 30년 개발자로 남아 있기는 낙타가 바늘 구멍 통과하기만큼 어렵다. 

우리나라는 장인정신보다는 관료주의적인 전통이 자리잡고 있어서 전문가보다는 관리자가 더 높은 자리로 인식된다. 그러다 보니 개발자도 분위기에 순응해서 자연스럽게 관리 쪽으로 슬금슬금 넘어가게 된다. 팀장, 부서장이 되어서도 개발에 집중하고 싶어도 주간보고, 월간보고, 업무 분배, 진척확인, 부서간 소통, 보고서 작성, 채용, 사업계획, 평가, 경영자에게 보고 등등 이런 일이 점점 늘어가고 그러다 보면 점점 관리자로 탈바꿈한다. 

개발자가 개발 일에서 떠나는 이유가 또 하나 있다. 개발 프로젝트가 대부분 합리적이지 못하고 무리한 경우가 많아서 몇 년 구르다 보면 야근과 각개전투가 난무하는 전투현장에서 벗어나고 싶게 된다. 개발이 진짜 즐겁고, 개발자로 충분히 대우도 받고 보장을 받을 수 있다면 관리자가 되려고 할까? 개발이 합리적이고 즐겁고 비전이 있어서 개발자들이 남아 있으려고 할 것이다. 

이렇게 고급 개발자들이 떠나게 되면 소프트웨어 생산성은 극도로 낮아진다. 이것은 회사적으로도 국가적으로도 큰 손해다. 뛰어난 개발자들이 관리를 잘 해준다고 해도 소프트웨어 생산성에는 별로 도움이 안된다. 그럼 소프트웨어 개발이 그렇게 관리가 많이 필요한가? 사실 개발팀은 관리할게 별로 없다. 

관리가 많이 필요한 개발팀은 비효율적 팀이라는 것을 단적으로 나타낸다. 단, 프로젝트 관리는 필요하고 전문 프로젝트 관리자가 있을 수 있다. 큰 조직이나 큰 프로젝트는 이보다 더 많은 전문 관리자가 있을 수 있다. 프로젝트 매니저(Project Manager), 리스크 매니저(Risk Manager), 프로덕트 매니저(Product manager), 프로그램 매니저(Program Manager) 등 다양한 전문 업무로 세분화 되기도 한다. 

외국 소프트웨어 회사와 같이 일해본 개발자들은 종종 할아버지 개발들을 만나게 된다. 이들은 50세가 넘어서도 가끔은 60세가 넘어서도 개발을 한다. 코딩도 직접 한다. 

왜 할아버지 개발자가 중요할까? 소프트웨어 개발자는 물론 예외도 일부 있지만 보통 경력이 쌓일수록 실력이 늘어간다. 그래서 회사의 개발자 층은 피라미드 구조를 이룬다. 그런데 가장 뛰어난 늙은 개발자가 관리를 하고 있으면 개발자 피라미드의 중간부터 꼭대기가 아예 없는 사다리꼴 피라미드가 된다. 이런 회사에서 개발 경쟁력을 기대하기는 어렵다.

개발자 본인은 어떨까? 나도 마찬가지지만 대부분의 개발자들은 관리를 극도로 싫어하고 잘하지도 못한다. 개발자들은 개발을 할 때 가장 행복하다. 행복한 일을 하면서 세상을 바꿀 수 있는 개발자라는 직업은 얼마나 멋진 직업인가? 하지만 40, 50세를 넘은 개발자를 찾아보기 어려운 현상은 개발자의 미래를 불투명하게 하고 직업 안정성을 해치고 있다. 

올림픽 금메달을 딴 선수가 20대 중반에 은퇴한 후 직장의 조직에서 불안해하는 것과 별반 다를게 없다. 이런 현상이 개발자 직업 선호도를 낮추는 원인이 되고 있다. 성공한 소프트웨어 회사에서 사장이나 연구소장이 나와서 브리핑하는 것이 아니고 백발의 진짜 개발자가 나와서 개발 이야기를 들려주는 일들이 뉴스에 자주 나와야 한다. 

소프트웨어 개발자의 경력을 보장하는 일은 개인, 회사, 사회적으로 매우 중요하다. 우리나라 소프트웨어 미래의 사활이 걸려있다고 봐도 과언이 아니다. 여기서 가장 중요한 역할은 회사가 해야 한다. 회사에서 개발자의 경력보장이 왜 중요한지 먼저 인식해야 한다.  왜? 거기에 회사의 소프트웨어 개발 경쟁력의 핵심이기 때문이다. 

먼저 개발자와 비 개발자의 트랙을 명확하게 나눠야 한다. 좋은게 좋은 거라고 두루뭉술해서는안된다. 개발자는 철저하게 관리 업무와 잡무에서 보호를 해야 한다. 

앞에서 언급한 보고서 작성, 사업 계획, 예산, 평가 등에 시간을 허비하지 않도록 해줘야 한다. 이런데 10%라도 시간을 빼앗기면 개발 생산성은 50% 이하로 떨어진다. 관리업무와 잡무는 다른 사람을 시키면 된다. 개발자가 10명 이하인 회사도 업무는 나눌 수 있다. 

회사에 롤모델과 멘토도 만들어야 한다. 내가 지금까지 개발자로 남아 있을 수 있던 이유는 롤모델이 있기 때문이다. 개발자는 어떻게 해야 하는지 보고 따라 할 수 있어야 한다. 눈에 보이지도 않는 요정과 같은 모습은 따라 할 수가 없다. 처음에는 어렵겠지만 개발자 롤모델을 키워내야 한다. 개발자에게 모든 것을 원하는 만능 개발자 위주 정책이 없어져야 한다. 한분야의 전문가라도 개발자로 일할 수 있게 해야 한다. 

회사가 준비가 되었다고 다는 아니다. 개발자 개인들도 생각을 바꿔야 한다. 본인의 성향을 보고 진로를 결정해야 한다. 인간의 두뇌 구조는 개발자와 관리자 모두를 잘할 수 있도록 되어 있지 않다. 물론 사회적 제도적 제한이 있어서 본의아닌 선택을 해야 하는 경우도 있지만 본인의 노력도 매우 중요하다. 개발자로 남고 싶으면 끊임없이 새로운 기술을 익혀야 한다. 시야도 넓혀야 한다. 비즈니스도 잘 알아야 한다. 개발자들이 서로 기술을 공유하고 경험을 나누며 같이 성장하려면 피어리뷰가 필수다. 

최고의 개발자들이 관리자나 다른 분야로 떠나고 신참들만 넘쳐나는 개발현장에서 경쟁력을 기대하기는 어렵다. 이런 관료적인 분위기를 소프트웨어 현장에서 없애지 않으면 우리나라 소프트웨어 미래는 없다. 나는 지금도 소프트웨어 경영자를 만나면 개발자 경력 보장이 얼마나 중요한지 역설 한다. 

물론 말 한마디로 30년차 개발자의 모습이 잘 그려지지 않고 실천하기는 어려울 것이다. 개발자 경력보장의 중요성에 대한 인식이 먼저 필요하다. 생각은 바뀌었는데 방법을 모르는 회사는 얼마든지 도와줄 의향이 있다. 그 중요성을 깨달은 것만으로도 이미 50%는 달성한 것이다. 

우리 주변에서도 할아버지, 할머니 개발자를 흔하게 보는 시기가 되면 소프트웨어 개발자들이 행복하게 일하는 세상이 이미 되어 있을 것이다.

똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.