검색어 프로젝트/커뮤니케이션에 대한 글을 날짜를 기준으로 정렬하여 표시합니다. 관련순 정렬 모든 글 표시
검색어 프로젝트/커뮤니케이션에 대한 글을 날짜를 기준으로 정렬하여 표시합니다. 관련순 정렬 모든 글 표시

2020년 9월 18일 금요일

진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 


툴, 시스템


재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.


문서 관리


비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 


문서 작성 역량


비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.


보고


진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.


화상 회의 빈도


가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.


회의 결과 관리


가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.


메신저 사용


가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 


업무 만족도


가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.


재택근무 가능 여부


가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.


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

2020년 7월 10일 금요일

코로나19 시대에 비대면 소프트웨어 개발이 필수

코로나19가 우리의 일상을 바꾸고 일하는 방식도 변화 시키고 있다. 그러면서 여러 분야에서 직접 만나지 않고 일을 하는 비대면 방식으로의 업무 방식을 도입할 수 밖에서 없게 되었다.

이러한 비대면으로 일하는 방식은 소프트웨어 개발에 있어서 긍정적인 측면이 있다. 비대면 방식의 개발이 글로벌 수준의 소프트웨어 개발 방식과 일맥상통한다. 또한 비대면 방식은 소프트웨어 개발 비용의 감소와 효율적인 개발과도 맞닿아 있다. 그동안은 이런 비대면 방식의 개발이 많은 기업에서 도입이 어려웠다. 그동안 해오던 방식을 바꾸기 쉽지 않는 것이 한 이유인데, 이제는 필수적으로 비대면 방식을 도입해야 한다. 따라서 비대면 방식이 소프트웨어 개발에 어떠한 영향이 있는지 짚어보고자 한다.

그럼 소프트웨어를 비대면 방식으로 개발해야 하는 가장 큰 이유는 무엇일까?

개발 비용이 적게 들기 때문이다.


가장 큰 이유는 개발 비용이 적게 들기 때문이다. 믿기 어렵겠지만, 사실이다. 프로젝트가 점점 커지고, 복잡해지고, 유지보수까지 감안하면 그 비용의 차이는 점점 커진다. 

좀더 나아가 비대면 개발 방식을 재택 근무까지 확장하면 회사 입장에서는 거주지에 상관없이 개발자를 채용하는 이득이 있고, 꼭 하루 8시간 일하는 개발자를 채용할 필요도 없고, 개발자 채용이 훨씬 유연해진다. 또한 사무실 임대비용도 감소하여 많은 장점이 생긴다.

직원 입장에서도 개발 외의 시간을 덜 뺏기게 되어 업무 집중도가 높아지고, 감정 소모가 감소하는 장점이 있다. 전체적으로 개발 생산성도 향상된다. 하루 4시간 밖에 일하지 못하는 개발자에게도 취업의 기회가 생기고, 생활의 질도 올라갈 것이다. 

사회적으로는 회사들이 몰려있는 수도권의 집값도 떨어지는 효과도 생길 것이다. 회사, 직원, 사회 모두가 이익이 된다.

문제는 얼굴을 보지 않고 일을 할 수 있냐는 것이다. 게다가 일을 열심히 하고 있는지 믿을 수 있냐는 것이다.

이제부터 사례를 비교해보고 어떻게 해야 비대면 방식으로 소프트웨어를 개발할 수 있는지 알아보자.

먼저, 미국의 경우를 보자.

미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다.


미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다. 대부분의 회사에서 개발자로 입사를 하면 재택근무를 선택할 수 있는 옵션이 있다. 코로나19 이후 재택근무는 훨씬 더 증가하고 있다. 즉, 미국에서는 이미 비대면으로 개발하는 방식에 익숙해져 있고, 비대면 개발에 별 문제가 없다.

미국에는 비정규직 포함 1200명의 직원이 모두 재택근무를 하고 있는 소프트웨어 회사가 있다. 바로 GitLab이다. GitLab의 모든 프로세스는 온라인으로 진행할 수 있도록 되어 있고, 문서를 통해서 개발이 이루어진다. GitLab은 급속도로 성장하고 있다.

Facebook은 개발자가 입사한 첫날 버그를 고친다. 이렇게 고친 버그는 전세계 서비스 된다. 개발자가 입사를 하면 버그관리시스템에서 버그를 할당해주고, 개발자는 온라인으로 주어진 정보를 바탕으로 소스코드를 내려 받고, 수정 후, 온라인으로 코드리뷰를 받고 소스코드를 등록한다. 한 사무실에 있는 동료들의 얼굴을 볼 수 있지만, 얼굴을 보지 않아도 일하는 방식은 똑같다.

최근 실리콘밸리의 소프트웨어 회사들은 대대적인 재택근무를 선언하고 있다. Facebook은 향후 5~10년에 걸쳐 직원 절반이 영원히 원격근무를 할 것이라고 한다. 이로 인해서 실리콘밸리 집값도 떨어지고 있다고 한다.

하지만 국내의 회사들은 전면적인 재택근무는 엄두를 내지 못하고 있다. 특정 직군만 재택근무를 시행하거나 일주일에 며칠만 재택근무를 시도하곤 한다. 아예 비대면으로는 일을 하기 어려운 상황이다.

그럼 우리나라 회사의 사례를 살펴보자.

스펙 문서를 보고 개발자가 개발을 못한다.


A사는 공공 프로젝트를 위주로 사업하던 회사다. 공공 프로젝트에서 업무를 분석하는 것은 가장 중요한 일이다. 그래서 업무 분석가가 핵심이다. 업무 분석가가 소프트웨어 스펙을 작성해서 개발자에게 넘겨주면 문서를 보고 개발하는 것이 목표였지만, 실제는 업무 분석가가 개발 기간 내내 옆에서 기능을 설명해줘야 했다. 업무 분석가는 프로젝트가 끝날 때까지 프로젝트에 묶여서 다른 프로젝트를 수행할 수가 없다. 회사 입장에는 수주할 수 있는 프로젝트가 줄어 들기 때문에 손해가 아닐 수 없었다. 하지만, 몇 년을 노력해도 스펙 문서를 전달해서 개발자들이 스펙 문서를 보고 개발한다는 목표는 달성하지 못했다.

B사는 신입 개발자가 입사를 하면 사수를 정해주고 이거 저거 가르쳐줘야 하는 것이 많다. 신입개발자는 최소 한달은 되어서 실제 개발에 투입이 될 수 있다. 사수인 고참 개발자도 시간을 많이 빼앗기고, 신입개발자도 월급 값을 하려면 시간이 오래 걸린다. 개발자가 입사할 때마다 이런 일은 반복된다. 신입 개발자에게 문서를 전달해주고 알아서 개발을 하게 하고 싶지만, 고참 개발자는 이를 위해서 문서를 따로 만들 시간이 없다.

왜 대면 개발이 문제인가? 대면으로 밖에 개발을 못하면 진짜 문제인가?

대면 위주로 개발하면 초기에는 뭔가 더 효율적인 것 같지만, 효율은 점점 떨어진다. 시간이 흐를수록 더 많은 개발자가 필요하고 초기 개발자가 유지보수에 더 매달려야 하고, 업그레이드 할수록 개발 비용이 증가한다. 

비대면 개발은 시스템, 문서 위주로 개발이 진행되기 때문에 자연스럽게 기록이 남고 혼선이 줄어들며 유지보수 준비가 된다. 

위기가 곧 기회


일본의 수출규제가 우리 부품 산업이 자립도를 높였듯이 위기가 곧 기회가 될 수 있다. 어쩔 수 없이 바뀌어야 하겠지만, 한국인의 저력과 맞물려서 소프트웨어 개발 역량이 몇 단계 업그레이드 될지도 모른다. 그러기 위해서 방법을 알아야겠다.

비대면 소프트웨어 개발을 하기 위해서는 크게 3가지가 필요하다.

첫째, 비대면 개발을 위한 시스템, 툴이 준비되어야 한다.

작은 툴부터 시스템까지 10~20여가지의 시스템이 도입되어서 내재화되어야 한다. 많은 것 같지만 적응해서 사용하다 보면 하나하나 필수적인 것이고 이것들 없이는 개발을 못할 것 같은 생각이 들것이다. 여러 회사를 살펴본 필자의 경험에 의하면 비대면 개발 프로세스를 위한 시스템, 툴을 촘촘히 전부 도입하고 있는 회사는 드물다. 일부 시스템만 사용하고 있어서 프로세스 중간중간 비대면 프로세스가 끊어지는 경우가 많다. 필수 시스템 중 몇가지만 예로 들면 문서관리시스템, 지식관리시스템, 소스코드관리시스템, 이슈관리시스템, CI시스템, 코드리뷰시스템 등이다. 추후 하나씩 자세히 알아보려고 한다. 이렇게 비대면 프로세스가 끊어지면 지속적으로 비대면 개발을 할 수 없고, 중간중간 얼굴을 보고 일하지 않으면 안된다.

둘째, 문서작성 역량이다.

단순히 워드 문서 같은 것을 말하는 것은 아니다. 온라인 시스템을 사용하려면 모든 것을 다 적어야 한다. 말로 하는 커뮤니케이션보다 글로 적는 커뮤니케이션에 익숙해져야 하고, 문서를 통해서 의사를 전달하고 문서를 보고 개발할 수 있는 수준의 문서를 작성할 수 있어야 한다. 그렇다고 자세하게 적는 것이 능사는 아니다. 최소한으로 문서를 적는 것이 더 중요하다. 이런 역설적인 말을 이해해야 한다. 개발에 관련된 문서는 많다. 기획문서, 스펙문서, 백서, 설계문서, 테스트 관련 문서 등 여러 문서를 온라인 프로세스를 통해서 작성하고 리뷰하고 확정하고 변경 관리를 해야 한다. 

셋째, 개발 문화다.

그중 대표적인 것이 수평 문화다. 온라인으로 비대면 개발을 하면 업무가 수평적으로 진행된다. 프로젝트에서 자신의 역할이 존재할 뿐이고 수직 관계가 없어져야 한다. 그래야 제대로 개발이 된다. 온라인에서도 수직관계가 여전히 존재한다면 일이 잘 진행 안될 것이다. 각자 자신이 맡은 일을 전문적으로 처리하는 것이다. 연공서열, 장유유서, 상명하복 이런 것들이 점점 희박해지고, 전문성이 강조되는 문화로 바뀌어 나가야 한다. 얼굴 안보고 일하면 이런 문화가 바뀔 가능성이 더 높아진다.

코로나19는 우리에게만 닥친 것이 아니다. 전세계가 동일한 환경에 처했다. 전세계가 비대면 방식으로 업무를 바꾸고 있고, 우리가 조금이라도 더 빨리 적응해 나가야 한다. 승부는 2,3년 안에 나게 되었다. 여기서 뒤쳐지면 따라잡기 어렵다.

비대면 방식이 소프트웨어 개발은 이제 선택이 아니고 필수가 되어가고 있다. 오늘은 비대면 방식의 개발에 대해서 간단히 소개만 했는데, 앞으로 하나씩 자세히 소개를 할까 한다. 하루아침에 습득할 수 있는 것은 아니지만, 차근차근 알고 익혀 나가는 것이 가장 빠른 길 일 것이다. 

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



2017년 4월 10일 월요일

이우소프트에는 이것이 있다 vs. 없다


개발자 캐리어 보장이 있다.

  • 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
  • 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

  • 남여에 따른 역할,대우의 차이가 전혀 없다.
  • 100% 역량에 따른 차이 밖에 없다.
  • 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

  • SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
  • 무조건 고참이라고 아키텍트가 되는 것은 아니다.
  • 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
  • 아키텍트는 사원부터 수석 연구원까지 있다.
  • 여자 아키텍트도 있다.

관리만 하는 개발팀장이 없다.

  • 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
  • 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

  • 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
  • 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
  • 비전문가가 감놔라 대추놔라 하지 못한다.

영어 이름이 있다.

  • 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
  • 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
  • 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

  • 개발자들은 직급이 아무것도 말해주지 않는다.
  • 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
  • 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

  • 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
  • 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.

운동 시설이 있다.

  • 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
  • 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.


파티션이 없다.

  • 파티션이 전혀 없이 책상들끼리 붙이 있다. 
  • 모든 직원이 한눈에 보인다.

어린이집이 있다.

  • 직원에게는 무료로 제공되는 어린이집이 있다.
  • 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
  • 자녀와 같이 출퇴근을 할 수 있다.



회의록이 있다.

  • 모든 회의가 하나도 빠짐없이 기록이 된다.
  • 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
  • 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
  • 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

  • 회의시간이 1초도 늦는 직원은 없다.
  • 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
  • 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

  • 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
  • 억지를 부리지 않는다.
  • 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

  • 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
  • 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
  • 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
  • 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

  • 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

  • 강요된 야근이 없다.
  • 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
  • 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
  • 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
  • PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

  • 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
  • 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
  • SRS가 완료되면 모든 Stakeholder의 대표들이 서명을 한다.
  • 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
  • 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정이 지연되는 프로젝트가 없다.

  • 지연되는 프로젝트가 하나도 없다.
  • 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
  • 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
  • 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

  • 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

  • 개발자에게 보고서 강요가 없다. 주간보고도 없다.
  • 개발자는 개발만 하면 된다.
  • 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

  • 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
  • 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

서울에도 스마트워크 센터가 있다.

  • 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.


E-mail이 없다.

  • 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
  • E-mail은 주로 외부인과만 주고 받는다.
  • 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

  • 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
  • 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
  • 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

  • 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
  • 더 중요한 것은 스펙, 설계 리뷰다.
  • 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
  • 시니어 개발자는 20% 이상을 리뷰에 할애한다.

마시고 죽자는 회식이 없다.

  • 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.


즉석 라면이 있다.

  • 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
  • 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

꼭 지켜야 하는 문화가 있다.

  • 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
  • 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.




2015년 5월 3일 일요일

나쁜 프로그래머가 되는 18가지 방법

소프트웨어 개발자는 끊임없이 변화하면서 성장한다. 스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은 점점 잃어가는 경우도 있다. 아무리 사회가 어떻고, 회사가 열악하다고 불평을 해봤자 남는 것은 자신의 개발자로서의 실력밖에 없다. 

이번 글에서 나쁜 프로그래머가되는 18가지 방법을 소개한다. 물론 본의 아니게 주변의 환경이 나를 이렇게내모는 경우도 있지만 이를 반대로 해보는 노력을 해보자. 내가 대단한 사람이라서 이런 얘기를 하는 것은 결코 아니다. 나도 독자들과 똑같은 개발자로서 18가지 중에서 잘 안되는 항목도 있다. 단지 20년 넘게 개발을 하면서 느끼는 바를 공유하고자 함이다. 

1. 익숙한 기술만 고집한다
대부분의 사람들은 변화를 싫어한다. 익숙한 것을 사용할 때 업무의 효율도 높다. 하지만 지식노동자인 개발자는 익숙한 기술만 고집한다면 한계에 다다른다. 물론 환경이 그렇게 만들기도 하고, 다른 분야의 기술을 익힐 만한 시간과 여유가 없는 경우도 많다. 그러다 보면 새로운 기술이 필요한 상황에서도 익숙한 기술을 고집하는 고집쟁이가 되기도한다. 

2. 공유를위해 노력하지 않는다
현재 내가 하고 있는 일은 나만 안다. 내가 퇴사하면 당장 이 일은 마비된다. 지금은 내가 하는 일에 다들 관심들이 별로 없지만 내가 없는 빈자리는 매우 클 것이다. 내 업무에 관련된 지식의 90%는 내 머리속에 있다. 주변의 다른 개발자들도 비슷한 상황인데 굳이 내가 깃발들고 공유를 위해 나설 필요가 있을까?  

3. 후배에게 시키지 않고 직접 처리하는 것이 속편하다
후배들이 많이 있지만 실력도 부족하고 일을 시키면 답답하다. 내가 하면 한시간이면 할 수 있는 일을 신입사원을 시키면 하루종일해도 못끝낼 뿐만 아니라 신입사원이 해놓은 것을 검토하고 고치고 가르치는데 몇시간이 소모된다. 그러니 차라리 내가 빨리 끝내버리는 것이 낫다. 그래서 우리 회사는 신입 개발자보다 고참 개발자가 훨씬 바쁘다. 

4. 후배나 동료들이 작성한 소스코드를 봐주지 않는다
회사에서 코드리뷰를 하라고는 하는데, 내 할 일이 바빠서 다른 사람 코드를 봐줄 시간이 없다. 나 뿐만 아니라 다들 이런 상황이다 보니 코드리뷰는 유야무야되었다. 과거에도 코드리뷰를 몇번해 봤지만 바쁜 와중에 잠깐시간내서 봐주기는 했는데 제대로 봐주지도 못했다. 그냥 코딩 스타일을 가지고 트집을 잡는 정도다. 그러다보니 이제 코드리뷰는 모두들 꺼려 한다. 

5. 남이 내 코드를 보는 것을 꺼려 한다 리뷰가 활성화된 조직에서는 지위고하를 막론하고 소스코드를 리뷰한다. 고참의 소스코드를 신입사원이 리뷰하고 지적할 수도 있다. 이런 거북함이 싫고, 귀찮고, 바쁘다. 내가 작성한 코드는 충분히 정상동작하는데굳이 다른 사람이 내 코드를 보고 지적을할 필요가 있을까? 개발할 시간도 부족하다. 

6. 문서화를 꺼려한다
문서작성은 무조건 싫다. 귀찮기도하고 잘 작성하지도 못한다. 하지만 회사에서 꼭 문서를 만들고 개발을 하라고는 한다. 그러면서 개발시간은 턱없이 부족하게 준다. 그래서 문서는 개발 다 끝나고 형식적으로 문서를 만든다. 한달동안 개발하고 나면 문서는 하룻밤 세워서 대충 문서를 만든다. 물론 이렇게 만든 문서를 나중에는 보지도 않는다. 

7. 커뮤니케이션 스킬 향상에 관심이 없다 
개발자는 프로그래밍을 잘하면 되지 커뮤니케이션 스킬은 별로 중요하지 않다고 생각한다. 개발자가 아닌 다른 사람들은 기술에 대해 잘 이해하지 못해서 기술에 대한 대화를 하기가 어렵다. 설명을 해도 잘 이해 하지 못한다. 난 컴퓨터와의 커뮤니케이션은 잘 되는 것 같다.

8. 책임지고 자신의 일을 마무리하지 않는다. 벌려만 놓는다
나는 개발을 엄청나게 빠르게 한다. 남들이 일주일 걸려서 하는 일도 나는 하루, 이틀이면 해치운다. 대신 완성도는 좀 떨어진다. 동작하도록 만드는 것은 나의 일이지만 귀찮은 버그를 잡는 일은 후배들을 시킨다.나는 새로운 일을 좋아하지 버그 잡는 것은 싫다. 

9. 소스코드가 주석 하나 없이 깨끗하다
항상 주석 같이 읽기 쉬운 소스코드를 주장하면 주석 하나 없이 깨끗하게 코딩을 한다. 하지만 후배들은 주석이 없으면 이해하기 어렵다고 불평이다. 하지만 프로젝트 일정이 항상 너무 촉박해서 소스코드에 주석을적을 시간이 없다. 

10. 소스코드가 읽기 난해하다
내 소스코드는 정상동작하지만 읽기는 어렵다. 워낙 바빠서 소스코드를 읽기 쉽게 정리할 수가 없다. 한 파일이 너무 크기도 하고 함수 이름도 난해하다. 내 소스코드는 최적화가 많이 되어서 짧은 코드로 어려운 로직을 기가 막히게 처리한다. 내 소스코드를 분석해 본 사람은 감탄을 할 것이다. 

11. 낮에는 집중해서 일하지 않고 주로 밤에만 일한다
회사가 낮에는 집중해서 개발할 수 없는 환경이다. 회의도 많고 시끄럽다. 그래서 밤에만 일을 하다 보니, 낮에는 여건이 되도 개발이 잘 안 된다. 밤에만 일하는 것이 완전히 습관이 되었다. 밤에 개발하는 것이 썩나쁘지는 않지만 나이를 먹어 갈수록 내 생활이 없어지는 것 같아서 걱정이다. 

12. 소프트웨어 공학에는 관심이 없다 
오로지 코딩, 코딩, 코딩만 잘하면 된다. 알고리즘, 알고리즘, 알고리즘은 관심이 많다. 소프트웨어공학이란말은 많이 들어 봤지만 이게 뭔지 설명하라고 하면 애매하다. 

13. 영어는 잘못하지만 공부할 시간은 없다 
원래 영어는 잘못했고 당장 영어공부를 따로 하지 않아도 개발을 하는데 큰 문제는 없다. 가끔 인터넷에서개발 관련 검색을 할 때는 주로 한글사이트만 검색한다. 스택오버플로우(Stack overflow)도 영어로 되어 있어서 잘 안 본다. 외국 소프트웨어 회사에 취업을 하고 싶어도 영어 때문에 포기했다. 

14. 기초, 원리는 잘 모르고 응용만 하려고 한다
시스템의 원리나 깊은 지식은 잘 모른다. 필요한 알고리즘이 있어도 원리는 잘 모르지만 인터넷에서 다운받아 그냥 사용하는 데는 큰 지장이 없다. 바빠서 따로 공부할 시간은 없다. 학교 다닐 때 전공수업 공부 열심히 할 걸 그랬다. 

15. 카피&패이스트(Copy & Paste)는 나의 무기 
소스코드 복사하는 것이 일상이다. 다른 프로젝트에 비슷한 기능이 있으면 복사해서 사용한다. 공통모듈을만들려면 여러 사람하고 얘기하고 조율을 해야 하는데 시간도 없고 내가 깃발들고 나서기는 싫다. 복사가 훨씬 빠르다. 소스코드를 복사해서 써도 지적하는 사람이 없다. 

16. 수학을 못한다. 관심도 별로 없다 
학교다닐 때부터 수학은 관심이 없었다. 잘 하지도 못한다. 소프트웨어를 개발하는데 수학이 왜 필요한가? 코딩만 잘하면 되지. 어려운 알고리즘은 인터넷을 조금만 뒤지면 라이브러리가 다 있다. 

17. 변변한 취미가 하나도 없다 
지난번 건강검진에서 의사가 술을 줄이고 운동을 하라고 했지만 매일 야근에 운동은 꿈도 못꾼다. 그나마 가끔 시간이 날 때 친구, 동료들과 술을 마시는 것이 유일한 낙이다. 숙취 때문에 다음날 일은 망친다. 

18. 개발밖에 모른다
회사가 어떻게 돌아가는지 잘모른다. 회사의 전략이나 경영 상황은 잘 모른다. 그런데 관심을 가질 시간이 별로 없다. 나는 회사일 신경 안 쓰고 내가 좋아하는 개발이나 평생하면 좋겠다. 

나는 소프트웨어 개발자는 참 좋은 직업이라고 생각한다. 물론 본인이 일 자체를 즐긴다면 정말 좋다. 말들도 많지만 대우도 그리 나쁘지 않고 성취도도 높다. 하지만 열악한 환경에서 일하는 수많은 개발자들은 그렇게 느끼지 못하고 있다. 물론 좋은 환경에서 일한다면 만족도도 높아지겠지만 개발자가 오랫동안 즐겁게일하는데 제일 중요한 것은 본인 스스로의 실력이다. 나쁜 개발자가 되는 방법을 한가지씩 지워가면서 좋은 개발자가 되는 노력을 해보자.

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

2014년 8월 15일 금요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2014년 5월 23일 금요일

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

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

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

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%는 달성한 것이다. 

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

2014년 4월 24일 목요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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