핵심은 아키텍트다

우리나라에는 뛰어난 프로그래머가 참 많다. 우리나라에서 연봉 4천만원 받는 개발자의 능력과 하는 일을 보고 외국의 억대 연봉 개발자가 입이 떡 벌어졌다는 우스개 소리가 인터넷에 떠돌고 있다. 전혀 근거가 없는 얘기는 아니다. 우리나라에서는 개발자가 많은 분야의 일을 해야 하고 밤을 지새면서 엄청난 양의 일을 소화하곤 하기 때문에 일단 많이 배우고 매우 빠르고 숙달되어 있다.

​

하지만 이것도 잠깐이다. 세월이 흘러 10년차, 20년차 개발자가 되고 나면 외국의 억대 연봉을 받았던 개발자와 비교해서 분석, 설계 역량에서 많이 뒤떨어지게 된다. 결국 연봉 값을 하게 된다. 이는 개발자들의 기본적인 재능이 아니라 환경차이 때문에 벌어지는 일이다.

​

우리나라에서는 빨리빨리 문화, 상명하복 문화를 비롯해서 여러가지 환경 때문에 아무리 좋은 프로세스를 도입한다고 해도 개발자들에게 분석, 설계 역량이 차근차근 축적이 되어서 10년, 20년 후에 뛰어난 아키텍트로 성장하기가 매우 어렵다.

[사진=Pixabay]

그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.

​

이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.

​

■ 비즈니스 이해해야 좋은 아키텍처 나와

​

소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?

​

한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.

​

누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.

​

좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.

​

우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.

​

왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?

​

개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.

​

개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.

​

설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트

일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.

​

■ "국내엔 축적된 노하우 계승해줄 선배들 부족"

​

그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?

​

빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.

​

소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.

​

아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?

​

대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.

​

이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론

수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.

​

그럼 아키텍트는 어떻게 양성해야 하는가?

​

교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

■ 아키텍트를 양성하는 세 가지 방법

​

첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.

​

둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.

​

셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.

​

막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.

​

조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

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

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

이우소프트에서 개발자를 채용하는 방법

최고의 개발자들이 최고의 소프트웨어를 만든다.

그래서 뛰어난 개발자를 채용하는 것은 소프트웨어 회사에서 가장 중요한 일이다. 그럼, 뛰어난 개발자의 정의는 무엇일까?

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 1년에서 3년 이상 장기적인 관점으로 투자를 해야 하는 것이기 때문에 그 정도의 여유도 없다면 공염불인 이야기다.

필자가 채용한 개발자 중에서 최고의 개발자들은 이전 회사에서 뛰어난 개발자로 인정을 받지 못하고 연봉도 낮은 경우가 많았다. 흔히 얘기하는 중위권 대학 출신이거나 개발 환경이 안 좋아서 능력을 발휘하지 못한 경우들이다. 실리콘밸리에 있는 좋은 환경의 회사에 입사를 했다면 몇 년 안에 뛰어난 개발자라는 평가를 들을 사람들도 좋지 않은 개발 환경에서는 실력 발휘도 못하고 인정도 못 받는다. 잠재력은 프리미어리그 급인데 조기축구에서 볼보이하는 격인데, 사실 축구에서 이런 일이 벌어지지는 않을 것이다. 하지만 소프트웨어 필드에서는 이런 일이 종종 벌어진다.

반대의 경우도 있다. 우리 주변에는 흔히 뛰어나 개발자라고 일컫는 사람들이 있다. 이렇게 뛰어난 개발자라고 칭송 받는 개발자들 중에는 형편 없는 개발자들이 매우 많다. 이러한 개발자들을 “헛똑똑이”라고 부른다. 똑똑하기는 한데 다 헛것이라는 의미다. 지식과 경험은 뛰어나지만 논리적인 사고, 협동심, 인내심, 겸손함 등이 부족하고 오만함과 아집으로 자신만이 옳다고 생각하고 바뀌지 않으려고 하기 때문이다. 이러한 “헛똑똑이” 개발자들은 회사에서 “영웅”으로 불리면서 동료들을 이끌고 구렁텅이로 들어가곤 한다. 이러한 문제 개발자와 진짜 뛰어난 개발자를 잘 구분할 필요가 있다.

개발자의 역량은 크게 세가지로 나뉜다.

- 시간이 흐르면 향상되는 것 : SW 지식, 기술, 경험, 도메인 지식
- 좋은 환경에서 향상되는 것 : 협동심, 커뮤니케이션 능력, 문서 작성 능력, 공유
- 노력해도 크게 바뀌지 않는 것 : 수학적이고 논리적인 사고력, Top-down 사고, 창의력, 겸손함 (인내심, 오만함, 아집)

세가지 모두 뛰어난 역량을 가진 개발자라면 정말 좋겠지만, 그런 사람을 찾기란 쉽지가 않다. 신입이나 쥬니어와 경력이 많은 시니어 개발자를 채용할 때 기준이 다르다.

신입 개발자는 “노력해도 크게 바뀌지 않는 것”을 위주로 판단한다. 특히 수학적, 논리적 사고력을 가장 높게 본다. 나머지는 좋은 환경에서 개발을 하면 자연스럽게 향상되는 것들이다.

경력 개발자는 세가지를 모두 봐야 한다. 경력에 걸맞은 지식과 경험도 본다. 여기서도  “노력해도 거의 바뀌지 않는 것”은 중요하다. 게다가 협업, 커뮤니케이션, 문서 작성 등과 관련하여 나쁜 습관이 있는지도 본다.

그럼 좀더 구체적으로 개발자를 채용하는 방법을 얘기해보자.

필자가 가장 선호하는 채용 방식은 직원 또는 지인에게 소개를 받는 것이다. 일단 직원이나 지인은 문제가 되는 사람은 소개를 하지 않고 역량도 꽤 뛰어난 사람을 소개하곤 해서 경험적으로 성공 확률이 매우 높다.

하지만 소개만으로 모든 개발자를 채용하기는 매우 어렵다. 그래서 채용공고, 홈페이지, SNS, 헤드헌터나 서치펌 등 다양한 경로를 이용해서 개발자를 채용할 수 밖에 없다. 하지만 이렇게 공개적으로 채용을 할 경우 짧은 시간에 개발자의 실력을 측정하고 회사에 적합한 사람인지 알아내기가 쉽지는 않다. 특히 경험이 많은 개발자들의 화려한 언변에 현혹이 되면 실체를 파악하지 못하는 경우도 많다.

그래서 필자가 개발자를 어떻게 채용하는지 설명하려고 한다. 물론 일반적인 관점과 좀 다를 수는 있다. 필자의 회사에서는 개발과 관리가 완벽히 분리되어 있고 개발 체계와 문화도 실리콘밸리의 소프트웨어 회사들과 비슷하다.  채용에 있어서 특이한 것이 2가지가 있다.

첫째, 동일 도메인 경험이 풍부한 개발자를 특별히 선호하지 않는다.

금융회사는 금융회사 출신의 개발자를 선호하고 보안, 게임 등 여러 분야에서 도메인 경험은 상당한 우대 요소로 작용을 한다. 그 이유는 도메인 지식을 익히는데 시간이 오래 걸리고 그때까지는 역량을 제대로 발휘하지 못하기 때문이다. 물론 도메인 경험이 도움이 안되는 것이 아니다. 하지만 도메인 경험보다 개발자 본연의 역량이 훨씬 중요하고 도메인 지식은 시간이 흐르면 익혀지지만 원초적인 개발 역량은 쉽게 바뀌지 않는다. 게다가 도메인 지식으로 개발 후보를 제한하면 좋은 개발자를 채용할 수 있는 범위가 좁아진다. 이렇게 도메인 지식보다 기초 역량을 중요시 하는 것이 중장기적으로 좋다.

둘째, 관리 능력이 뛰어난 개발자를 별로 선호하지 않는다. 오히려 꺼려한다.

우리나라에서 개발자들은 경력이 5년~10년 정도 되면 조금씩 관리 요구를 받게 되고 관리를 하면 할수록 개발에 매진할 시간은 줄어든다. 소프트웨어 개발이 관리도 하면서 짬짬이 해서 실력을 꾸준히 유지하고 발전시킬 만큼 쉽지가 않다. 관리 능력도 뛰어난 개발자를 선호하는 회사도 있지만 우리 회사에서는 개발과 관리가 철저히 분리되어 있기 때문에 개발자는 순수 개발 능력만을 본다. 관리 능력도 있는 개발자라면 관리 능력은 쏙 빼고 개발 능력만 보기 때문에 관리 능력이 뛰어난 개발자가 관리자가 아닌 개발자로 채용되는 경우는 흔치 않다. 축구선수를 뽑는데 농구도 잘하는 경우는 축구선수로 채용되기 어려운 경우와 비슷하다고 할까? 물론 어쩔 수 없이 관리도 했지만 개발역량이 뛰어난 개발자도 있다. 이런 개발자라면 채용에 문제가 없다.

우리 회사도 타사와 채용 절차는 크게 다르지 않다. 서류심사, 온라인 코딩테스트, 전화 인터뷰, 대면 인터뷰 이런 순서대로 진행이 된다. 대면 인터뷰에서는 즉석에서 칠판에 쓰는 코딩테스트를 진행한다. 20년차 개발자를 채용할 때도 코딩테스트는 필수다. 그럼 채용 시 중점을 두는 것에는 어떤 것들이 있는지 알아보자.

첫째, 출신 대학과 전공은 별로 중요하지 않다. 남녀, 국적도 따지지 않는다.

실제로 출신 대학과 무관하게 코딩테스트에서는 매우 뛰어난 결과를 보였고 천재적인 역량을 발휘한 사례도 있다. 학교 성적과 상관없이 논리적인 사고력이나 수학적인 능력이 뛰어난 사람이 소프트웨어 개발에 탁월한 경우도 드물지 않게 있다. 전공도 마찬가지다. 소프트웨어 전공이 아닌 경우에도 뛰어난 개발자를 자주 발견하고 한다. 최근에는 수학, 통계학 등의 전공자를 일부러 찾기도 한다. 야근이 수월한 체력이 좋은 남자를 선호하는 회사도 있지만 성별을 전혀 따지지 않는다. 또한 국적도 따지지 않고 한국어를 못해도 실력만 좋거나 잠재력만 뛰어나도 채용을 한다.

둘째, 온라인 코딩 테스트를 통해서 개발자 기초 역량을 확인한다.

온라인 코딩 테스트는 보통 3문제를 제출하고 24시간 안에 풀도록 한다. 내가 풀었을 때 2시간 정도 소요가 되기 때문에 24시간은 충분한 시간이다. 경시대회 수준의 어려운 문제와 쉽지만 창의력이 필요한 문제를 출제한다. 적어도 하루를 투자해야 하기 때문에 후보자가 얼마나 진지하게 우리회사에 지원한 것인지 확인할 수도 있다. A~F 등급으로 평가를 하며 B 등급 이상이 되어야 통과된다. 온라인 코딩 테스트 서비스 회사는 많이 있지만 우리 회사에서는 손으로 직접 채점을 한다. 정답 도출 여부는 자동 테스트를 하고 코딩 내용은 직접 눈으로 확인한다. 정답을 도출하지 못해도 창의력과 프로그래밍 방식을 평가하여 높은 등급을 주기도 한다. 온라인 코딩 테스트는 다른 사람이 도와줄 가능성도 일부 있기 때문에 100% 신뢰를 하지는 않고 일정 수준으로 거르는 용도로 사용을 한다.

셋째, 인터뷰 시 진행하는 칠판에 하는 코딩 테스트는 개발의 축소판이다.

개발자 채용에서 가장 중요한 절차다. 온라인 코딩 테스트를 통과한 개발자도 인터뷰 시 꼭 코딩 테스트를 또 진행한다. 문제는 매우 쉽지만 제대로 하기는 만만치 않는 문제를 출제한다. 시간은 10~20분 정도 소요가 되며 이 과정에서 개발자의 두뇌, 논리적인 사고력, 문제 해결 능력을 본다. 알고리즘을 1초 안에 머리 속으로 빈틈없이 시뮬레이션 할 수 있는 사람과 수분에 걸쳐서 숫자를 대입해가면서 검증을 해야 로직이 확인되는 사람은 하늘과 땅 차이다. 칠판에 하는 코딩테스트에서는 이 차이가 적나라하게 드러난다. 물론 후자는 탈락한다는 것은 아니다. 물론 전자의 후보가 월등히 높은 평가를 받는다. 또한 진행하는 과정을 보면서 향후 개발자가 어떻게 개발을 할지 추측할 수 있다. 평소에 개발을 하던 습관이 이 짧은 시간에 다 나온다. 또한 말만 번지르르하고 실제로 코딩을 잘 못하는 고참 개발자들도 여기서 걸러진다. 실제 수백 번의 코딩테스트를 통계 내보면 경력에 따른 큰 차이가 없다. 이런 코딩 테스트를 평가하기 위해서는 매우 뛰어난 개발자가 직접 평가를 해야 한다. 그렇지 않고는 후보자의 논리적인 사고력, 두뇌 회전 속도 등을 판단하기 어렵다.

넷째, 개발언어, 도메인은 별로 중요하게 생각 안 한다.

C, C++, Java, C#, Objective C 등 개발 언어 하나는 완전히 마스터한 개발자를 채용하며 우리가 사용하는 개발 언어를 사용해보지 않은 개발자도 채용을 한다. 다른 개발 언어는 필요하면 익히면 된다. 빨리 익힐 수 있는 잠재력을 가지고 있는지가 더 중요하다. 특이한 경우지만 코딩 경험은 거의 없지만 잠재력이 무한한 사람이라면 개발 언어를 잘 몰라도 채용이 될 수도 있다. 보통 뭘 해봤고 무슨 툴, 라이브러리를 써봤는지 보다는 잠재력 확인에 주력한다. 그래서 가장 자신 있는 개발 언어에 대해서 그 특성을 제대로 이해하고 있는지 질문을 하고 OOP의 개념을 얼마나 잘 이해하고 있는지도 질문을 한다. 우리 회사와 동일한 도메인 지식 경험이 있다면 당연히 좋겠지만 그렇지 않더라도 상관하지 않는다. 우리는 Dental 분야지만 보안, 레저, 게임 등 분야를 가리지 않고 채용을 하며 입사 후 능력과 성과는 도메인과 별로 상관이 없다.

다섯째, 좋은 개발 습관을 가진 개발자를 선호한다.

경력이 많은 개발자일수록 자신의 습관을 바꾸기가 어렵다. 그래서 경력이 많을수록 습관을 주의 깊게 파악한다. 신입이라면 백지와 다름이 없기 때문에 거의 잠재 능력 위주로만 평가를 한다. 소프트웨어 공학에 관심이 많은 것은 긍정적인 요소이며 권위 의식이 있는지 협업과 커뮤니케이션에 능숙한지 공유하는 습관이 있고 문서 작성을 제대로 하는지 확인한다. 꾸준히 새로운 기술을 거부감 없이 익히고 공부하는 것을 즐기는 타입이면 좋다. 인터뷰에서는 보통 좋은 모습만 보여주려고 하기 때문에 습관을 숨길 수 없는 핵심적인 질문을 통해서 진짜 습관을 알아내려고 노력한다. 습관은 바뀌기 어렵기 때문에 인재에 투자할 여력이 된다면 잠재력이 뛰어난 신입개발자를 채용하여 좋은 환경에서 훈련시키고 회사의 문화를 습관화 시키는 것이 좋다.

우수한 개발자가 뛰어난 개발자로 성장하고 뛰어난 성과를 내려면 거기에 걸맞은 환경이 필요하다. 그 중에서 가장 중요한 것이 협업이다. 분석, 설계를 제대로 하고 공유를 하며 개발자의 경력을 보장하고 수평적인 조직 문화를 갖추는 등 개발자가 실력을 발휘하고 성장할 수 있는 환경이 필수적이다. 이건 워낙 광범위한 주제이기 때문에 이 글에서는 논외로 하자.

지금까지 회사 관점에서 어떻게 뛰어난 개발자를 채용하는지 알아봤는데 거꾸로 개발자 관점으로 보자. 필자가 걸어온 길이기도 한다.

개발 언어 하나는 일단 도사급이 되어야 한다. 그리고 다양한 개발 언어를 거부감 없이 수시로 익히고 특히 스크립트 언어 한두개도 능숙해져야 한다. 새로 나온 기술도 관심을 꾸준히 가지고 필요한 만큼 익혀 놓아야 한다. 영어는 끝이 없으므로 꾸준히 공부를 해야 한다. 수학과 논리적인 사고를 꾸준히 단련해야 하며 수시로 글을 쓰고 개발 문서를 써야 한다. 소프트웨어 공학이 몸에 익어야 하며 커뮤니케이션, 협업 역량 향상을 위해 노력하고 겸손함과 인내심을 갖추려고 노력한다. 이렇게 좋은 습관과 뛰어난 지식과 경험을 쌓은 개발자라면 대부분의 SW 회사에서 채용하고 싶을 것이다.

이렇게 준비하며 습관을 만들어가기 어려운 환경에서 일하고 있는 개발자도 매우 많다. 그래도 언제든지 이직의 기회는 발생하는 것이고 현재 환경에서 할 수 있는 최선을 다해서 자신을 만들어가면 좋겠다.

이글은 ZDNet Korea와 기업블로그에 기고한 글입니다.

나쁜 프로그래머가 되는 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에 기고한 글입니다.

21C 韓 SW개발자는 16C 조선 陶工 처지

나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선 시대 임진왜란 때 일본으로 납치되어 간 도공들이 다시 조선으로 돌아오기를 거부하고 일본에서 뿌리를 내린 것과 비슷하다. 

임진왜란 당시 어떠한 일이 일어났는지 간단히 알아보자. 그리고 역사는 되풀이 된다는데 현재 우리는 무슨 문제를 가지고 있는지도 생각해보자. 

16세기까지 전세계에서 1천300도 이상에서 구워내야 하는 도자기를 만들어 낼 수 있는 나라는 중국, 한국, 베트남 정도였고 그 중에서 도자기의 최고봉인 백자는 중국과 조선만 만들어 낼 수 있었다. 지금은 도자기가 별 것 아니라고 생각할 수 있었지만  당시에는 최고로 돈이 되는 물건이었다. 유럽의 귀족들은 중국의 도자기에 열광해서 금, 은 그릇보다 비싼 가격에 도자기가 거래되고 있었고 세계 도자기 시장은 거의 중국이 석권하고 있었다. 

임진왜란이 왜 일어 났는지는 여러가지 의견이 있지만 도자기 때문에 일본이 일부러 일으켰다는 주장도 있다. 임진왜란의 근본 목적은 조선의 도자기 제작 기술을 비롯한 여러 가지 공예 기술을 훔쳐오기 위한 것이라는 주장이다. 일찌감치 네덜란드 등과 교역에 눈을 뜬 일본은 유럽에서의 도자기 인기를 알게 되었고 자신들의 도자기 제작 기술보다 월등히 높은 조선의 도자기 제조 기술을 가지고 싶어 했다. 그래서 임진왜란 전에 미리 첩자를 조선에 보내 조선의 도공들의 신상과 소재를 모두 파악한 후 임진왜란, 정유재란 중에 조선의 도공 거의 전부인 약 900명을 납치해 갔다는 것이다.물론 도공들만 납치해 간 것은 아니고 다른 수많은 분야의 장인들을 같이 납치해 갔지만 도자기 장인들이 핵심이었다. 

그렇게 납치해 간 도공들은 일본에서 도자기를 만들 수 있는 흙을 찾아냈고 20년만에 일본도 완벽한 도자기 제작 기술을 보유하게 되었다. 마침 중국의 내부 정세 혼란을 틈타 유럽의 도자기 시장을 석권하고 막대한 자금을 바탕으로 아시아 최대 강대국으로 발돋움 했다는 학설이다. 

그런데 임진왜란 후에는 조선은 도공들을 다시 돌려 받으려고 했지만 많은 도공들은 조선으로 돌아오기를 거부했다고 한다. 일본으로 끌려간 도공들은 조선에서보다 훨씬 나은 대접을 받았다고 한다. 조선에서는 기술은 천시하고 도공뿐만 아니라 대부분의 장인들은 하층민 대접을 받았지만 일본에서는 이들을 극진히 대우를 해줬다고 한다. 땅도 주고 집도 주고 결혼도 시켜주고 마음껏 도자기를 만들 수 있도록 지원을 아끼지 않았다고 한다. 옛날부터 일본은 장인을 존경하는 전통이 있었고 자신들이 가장 높게 사는 최고의 도자기 제작 기술을 가지고 있는 사람들을 존경하고 대우해주는 것은 어쩌면 당연했을지도 모른다. 

그러다보니 임진왜란 후 거의 도자기의 명맥이 끊기고 세계 예술사에서 거의 흔적을 남기지 못한 한국과는 대비되게 일본은 최고의 도자기 명문 국가가 되었고 선진국의 발판이 되었다. 역사에 만약은 없지만 도자기를 기반으로 우리나라가 18,19세기 강대국으로 발돋움 했다면 어떻게 되었을까? 

이 얘기를 하는 이유는 임진왜란 당시의 상황이 지금과 별반 다르지 않기 때문이다. 여전히 기술자는 존경과 대우를 못 받고 그나마 대우를 받으려면 관리자가 되어야 한다. 공부를 잘하는 학생들은 대부분 의사, 공무원이 되려고 한다. 소프트웨어 개발자들은 기회만 되면 외국으로 나가려고 한다. 개인 입장에서는 축하해줄 일이지만 그렇게 고급인력이 다 빠져나가면 우리나라는 어떻게 될까? 

하지만 지금 소프트웨어를 전공하는 대학생이 진로를 문의하면 나도 외국으로 나가라고 충고를 한다. 미래의 먹거리가 소프트웨어에만 있는 것은 아니지만 소프트웨어가 가장 중요한 기술 중 하나인데 개발자에 대한 인식이나 대우, 환경은 너무 열악하다. 드라마에서 잘나가는 사람들은 거의 의사, 경영자, 변호사, 검사다. 엔지니어나 소프트웨어 개발자가 주인공은 경우는 거의 없다. 사회적으로 인식이 매우 낮다는 반증이다. 

제2의 도자기 전쟁은 이미 시작되었고 핵심은 우수 두뇌 확보다. 구글이 3조원이 넘는 금액을 지불하고 네스트를 인수한 주 목적도 인재 확보다. 구글이 네스트에 지불한 금액은 1인당 100억원이 넘는다. 국가나 기업 모두 인재를 확보하기 위해서 혈안이 되어 있지만 우리나라 인재들은 외국으로 나가고 있다. 또는 기회만 되면 외국으로 가고 싶은 엔지니어도 상당 수다. 

외국의 인재도 모셔와야 하는 마당에 우리나라의 인재들이 일하기 힘든 환경을 그대로 놔두고 있는 것은 오랫동안 뿌리깊게 자리잡은 기술자 천시와 관료 우대 인식 때문이 아닐까 생각한다. 이런 기술자를 낮게 보는 인식을 없애지 않으면 구한말에 우리나라가 겪었던 고통을 또 겪어야 할지도 모른다. 나라를 좌지우지 하는 사람들은 국내 상황에 정신을 팔려서 세계의 흐름을 놓치고 있다. 나중에 애국심에 호소해서 외국에서 일하는 우리나라의 인재들에게 들어와서 나라를 다시 일으켜 달라고 해도 돌아오는 사람이 몇 명이나 될까? 

개발자들이 우리나라를 떠나고 싶어하는 가장 중요한 이유가 연봉의 차이는 아니라고 생각한다. 연봉이 높은 나라는 생활비 지출도 많고 세금도 많다. 더 중요한 것은 엔지니어에 대한 전문성의 인정과 사회적인 존경심이라고 생각한다. 창의적 지식 노동에 대한 이해와 좋은 개발환경도 필요하다. 개발자로 30년을 일해도 어린 관리자와 같이 일을 해도 전혀 어색하지 않고 어린 관리자도 늙은 개발자를 어려워하지 않는 문화가 필요하다. 생산성을 높이는 방법을 오직 야근밖에 모르는 회사가 워낙 많다. 이런 회사는 사채를 끌어 쓰는 것과 같아서 갈수록 어려워진다. 이런 환경이 계속 만연한다면 우수한 개발자 인력들은 외국으로 떠나던지 소프트웨어 업계를 떠날 것이다. 이런 환경을 수수방관하면 역사는 되풀이 될 것이다.

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

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 

대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글로벌 기업으로 성장하기를 원하고 있다. 한 두명이 시작해서 세계적인 회사가 된 뉴스를 보면 우리도 그렇게 될 수 있다는 꿈을 가지게 된다. 그러기 위해서 국내에서 일단 인지도를 쌓고 고객을 확보하여 캐시카우를 만든 후에 이를 기반으로 해외 진출한다는 전략을 가지고 있는 경우가 많다. 

하지만 이런 전략은 계획대로 되지 않는 경우가 많다. 그냥 국내 시장에서 허덕대다가 그저그런 기업으로 남거나 문을 닫는다. 

물론 처음부터 해외시장은 거들떠도 보지 않고 국내 시장에서만 승부를 보는 전략도 있고 분야에 따라서 나쁜 전략도 아니다. 국내 소프트웨어 시장이 세계 시장의 2~3%에 불과하지만 지역특성이 강한 분야도 있어서 효과적인 전략이 될 수도 있다. 

하지만 국내를 발판으로 해외로 나가보자는 전략이 잘 먹혀 들어가지 않는 이유를 알아보자. 

A사는 기업용 서비스를 개발하는 회사인데 처음부터 글로벌 서비스를 목표로 시작을 한 회사다. 충분한 자본을 가지고 시작하지 않았기 때문에 먼저 돈을 벌어야 했다. 그래서 국내에서 몇몇 기업과 계약을 맺어 서비스를 제공했고, 상당 기간 고객들이 원하는 기능에 매달리느라고 글로벌 서비스에 필요한 준비를 별로 하지 못했다.

글로벌 서비스는 모든 프로세스가 완전히 자동화 되어 사람의 수동 개입이 거의 없어야 하는데 국내 고객에 대응을 하다 보니 상당 부분 사람의 노력이 들어가야 하는 반자동 서비스가 되었다. 지금은 고객이 100배로 늘어도 큰일이며 시스템의 구조를 바꾸려면 추가로 개발을 매우 많이 해야 한다. 이미 개발해 놓은 것이 많으므로 시스템 복잡도는 점점 증가하게 되었고, 이 모든 것이 미래 개발의 큰 부담이 되고 있다. 

B사는 기업용 웹 솔루션을 만드는 스타트업이다. 국내 시장에서는 어느 정도 인지도를 쌓았다. 그리고 정부 지원을 받아서 해외 진출을 하기 위해 글로벌 버전을 새로 개발하고 있다. 

국내에서 영업이 꽤 잘되어서 매출액이 급격히 늘었다. 하지만 국내 기업을 지원하느라고 개발자를 많이 채용해야 했다. 그러다 보니 많은 개발자의 월급을 주려면 상당한 매출을 계속 일으켜야 했다. 그렇게 계속 국내 고객을 발굴하고 기업들의 요구사항에 매달리다보니 처음에 계획했던 글로벌 솔루션에 투자할 시간이 점점 줄어들었다. 국내 고객이 캐시카우라서 포기할 수도 없고, 이를 위해서 많은 개발자는 계속 필요하고 이런 고리에서 빠져 나올 수가 없다. 

C사는 유럽의 작은 나라 소프트웨어 회사다. 지원수는 30명 정도지만 전세계 수많은 고객을 가진 글로벌 기업이다. 이 회사의 솔루션은 매우 단순하다. 비즈니스 전략도 단순하다. 구매도 온라인으로 이루어지고 모든 정보는 인터넷에 공개가 되어 있다. 고객지원도 온라인으로만 이루어진다. 서비스데스크 시스템을 통해서 기술문의나 사용문의를 처리하고 있다. 

고객이 전세계에 흩어져 있어서 지원을 요청한다고 방문을 할 수도 없고, 전화 지원도 언어 장벽 때문에 어렵다. 따라서 제품에 대한 문서화가 잘 되어 있고, 모든 지원은 자동화된 프로세스가 잘 구축되어 있다. 그래서 적은 개발 인원과 지원 인력으로 수많은 고객을 지원하는 것이 가능하다. 

글로벌 기업이 목표인 회사에게 국내 시장은 우선 공략 전략은 자칫 빠지기 쉬운 함정이 될 수 있다. 지역이 국내라서, 국내 고객들이 괴팍해서 그렇다는 것은 아니다. 로컬 비즈니스 전략으로 고객별 커스터마이징과 오프라인 지원에 매달리는 전략이 문제라는 것이다. 일단 이런 전략으로 시작한 기업은 '개미 지옥'에 빠진 기업과 같다. 처음에는 이렇게 돈을 번 후 멋지게 빠져나가서 성장을 하고 싶지만, 일단 발을 들여 놓으면 처음에 생각한 것과 다르게 점점 더 깊게 빠져 들어가는 '개미 지옥'이 된다. 

기술적으로도 로컬 제품을 먼저 만들었다가 글로벌 제품으로 성장하는 것은 매우 어렵다. 서비스도 마찬가지다. 패러다임을 완전히 달리 해야 하는 것이라서 처음부터 글로벌 시장을 타깃으로 한 제품을 만들지 않으면 어렵다. 

글로벌 제품의 특성은 다음과 같아야 한다. 

첫째, 소프트웨어 국제화가 잘 되어 있어야 한다. 

소프트웨어 국제화란 여러 언어와 국가를 지원할 수 있는 구조로 만든다는 것인데 국제화 전문가의 도움 없이 제대로 국제화를 하기란 거의 불가능하다. 10년 이상의 소프트웨어 국제화 경험이 있어야만 제대로 국제화를 할 수 있다. 

소프트웨어는 처음에 개발을 시작할 때부터 국제를 하는 것이 가장 좋다.국제화가 안된 소프트웨어도 처음에 영어를 기반으로 개발한 소프트웨어는 나중에 국제화가 용이하지만 그렇지 않은 경우 국제화가 힘들어진다. 또한 영어로 개발된 제품은 국제화를 하지 않아도 영어를 받아들이는 전세계 모든 회사에 판매를 할 수가 있다. 

소프트웨어 자체는 훌륭하지만 국제화에 발목 잡혀서 실패한 회사가 꽤 된다. 번역이 잘 못되거나 해당 국가의 문화나 표기 방법을 고려하지 않거나 개발 비용이 너무 과도하게 들어가서 실패를 하게 된다. 

둘째, 유지보수와 고객지원이 용이하며 거의 온라인으로 지원할 수 있도록 해야 한다. 물론 소프트웨어 품질이 높아서 장애와 지원요청이 별로 없어야 한다. 소프트웨어 장애 시 몇 번의 클릭으로 장애 리포트를 전송할 수 있도록 하고, 개발사에서는 자동으로 분석할 수 있는 시스템이 잘 구축되어 있어야 한다. 고객과는 온라인으로 소통하며 모든 이력은 데이터베이스에 기록되어서 미래의 고객 지원에 활용된다. 

요즘은 고객끼리 정보를 공유하는 서비스를 제공해서 고객지원에 들이는 노력을 더욱 절약하는 기업들이 있다. 

셋째, 기업 내부적으로는 개발에 필요한 문서가 잘 작성되어 있고, 고객에게는 충분한 정보를 문서로 제공한다. 개발 시에 꼭 필요한 문서를 충분히 잘 작성하므로 고객에게 제공되는 사용자 매뉴얼, 기술 백서 등의 문서가 자연스럽게 잘 만들어진다. 그래서 고객들은 문서를 통해서 충분히 정보를 제공 받으므로 지원 요청이 줄어든다. 물론 고객에게 정보를 제공하기 위해서 처음부터 문서화를 잘하는 것이 아니다. 개발 시에 필요한 문서를 제대로 만드는 것이 가장 빨리 개발하는 방법이기 때문에 문서를 잘 적는 것이다. 

넷째, 개별 고객의 요구사항에 흔들리지 않고 개발사가 제품의 로드맵을 주도한다. 고객의 요구사항에 귀를 기울이지만 전체를 파악하는데 노력을 하고 한 고객이 원하는 것에는 휘둘리지 않는다. 이 때문에 잃게 되는 10%의 고객보다는 나머지 90%의 고객을 유지하는데 집중한다. 따라서 소프트웨어를 급하게 개발하지도 않는다. 

다섯째, 고객이 아무리 많아도 소스코드는 한벌인 경우가 많다. 국내 소프트웨어 회사들이 가장 많이 빠지는 함정이 슈퍼 고객을 지원하기 위해서 소스코드가 갈라지거나 국제화를 위해서 별도로 개발을 하는 것이다. 눈앞의 이득만 쫓다가 수십배의 손해를 보는 경우가 허다하다. 

글로벌 회사를 계획했지만 캐시카우를 만들기 위해서 로컬 비즈니스와 커스트마이징 또는 SI를 해야 밖에 없는 상황이 있을 수도 있다. 하지만 이런 전략은 "개미 지옥"과 같다는 것을 명심하자. 절대로 빠져오지 못할 만큼 깊게 빠지지는 말아야 한다. 정신을 똑바로 차리고 있지만 않으면 영원히 못 빠져 나온다. 

가장 좋은 방법은 마약에 빠지지 말고 처음부터 글로벌 전략을 펼치는 것이다.

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

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가 잘 안 돌아가도 문제지만 내가 있으나 없으나 회사가 아무 일 없이 잘돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

“유지보수가 어렵게 코딩하는 방법” 이란 책도 있다. 원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 이 책은 조크이지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.

몇 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다. 휴가기간 한달 동안 원격지에서 일을할 수 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가제도를 만든 이유는 어느 직원이던지 그 직원이 없어도 회사가 잘 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달 동안 자리를 비울수 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나보완이 가능하도록 한다. 누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴 수 있다는 불안감을 가져야 할까?

가상의 이야기가 있다. 원자력 발전소에서 일하는 홍길동은 절대로 3일 이상 휴가를 갈 수 없다. 홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자. 홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다. 회사 입장에서는 큰 비용을 투자 하는 것보다홍길동만 잘 유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의교통사고를 당할 수도 있다. 옆 나라의 발전소에서 더 높은 연봉으로 데려갈 수도 있다.

나는 강연이나 세미나를 할 때 자주 묻는다. “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

반대로 “그럼 당장 퇴사하면 회사가 안 돌아가는 사람” 손을 들라고 하면 몇 사람들이 당당하게 손을번쩍 든다. 몇 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈소적인 말도 들려온다. 대부분의 회사에서 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 큰 영향을 받는 회사가 많다. 회사의 경영진은 문서화도 잘되어 있고 공유도 잘 되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에 별 쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는 큰 문제지만“쉬쉬” 하는 경우가 많다. 개발자들도 자신이 없을 때 회사가 잘 안 돌아가는 상황을 그렇게 나쁘게만보지 않기 때문에 별 이슈로 생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그렇게 생각할수 있지만 장기적으로는 얘기가 완전히 달라진다.

나는 “당장 퇴사하면 회사가 안 돌아가는 사람”은 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”은 회사에 꼭 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 안돌아가는 사람”이 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

“지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 한사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 그 동안 해왔던 일들이 문서화가 잘 되어 있고, 공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은회사의 미래의 프로젝트를 위해서 꼭 필요한 사람이다.

반대의 경우는 그 동안 저질러 놓은 일이 많고 자신이 아니면 유지가 안 된다. 뭘 하나 해결하려고 해도 원 개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 원 개발자가 한두 시간이면 뚝딱 해결할 수 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 또 다른 문제를 만들어 냈을까봐 두렵다. 회사입장에서는 큰 리스크가 아닐 수 없없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다. 회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다. 특히나 개발 능력이 뛰어난 개발자들에게서이런 현상이 더 잘 일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 “유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다. 회사의미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게된다. 자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 수 있다. 실제이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 “유지보수가 어렵게 코딩하는 방법”을 잘 공부하기를 바란다.

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를 잘 해야 한다. 문화적으로 성숙되고 프로세스를 잘 갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다. 중간 중간 리뷰 과정을 다 거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다. 이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다. 공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

자신은 어떤가 생각을 해보자. 한달간 휴가를 갈 수 있을까? 회사의 모든 직원이 각자 한달간 휴가를갈 수 있을까? 그렇지 않다면 무엇을 바꿔야 할지 생각해보자.