핵심은 아키텍트다

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

​

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

​

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

[사진=Pixabay]

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

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

​

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

​

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

​

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

​

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

​

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

​

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

​

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

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

​

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

​

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

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

​

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

​

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

​

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

​

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

​

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

share with abctech.software

이우소프트에 대한 오해와 진실

가끔은 “이우소프트가 개발자에게 그렇게 좋은 회사라면서요?”라는 말을 종종 듣는다. 이 말은 맞기도 하고 틀리기도 하다.

입사지원자에게 듣기도 하고 지인들에게 듣기도 한다. 몇몇 얘기를 듣고 과도하게 확대해석하기도 하고 오해하기도 한다. 모든 현상이 그렇듯이 몇줄의 글을 통해서 상황을 정확히 설명하기란 매우 어렵다. 하지만 내 블로그의 글을 보고 많은 개발자들이 이우소프트에 지원을 하기 때문에 좀더 정확한 설명이 필요하다.

일단 이우소프트는 “개발자가 일하기 좋은 회사”를 만드는 것이 목적인 회사는 아니다.

이우소프트의 비전은 “글로벌 경쟁력을 갖추고 세계 1등의 Software를 만들어 내는 것”이다. 거의 모든 것은 여기에 맞춰져 있다. 이를 위해 행해지는 것들이 개발자에게 좋을 수도 있고 나쁠 수도 있다. 또한 어떤 개발자에게는 좋은 것이 어떤 개발자에게는 나쁜 것이 될 수도 있다. 

퇴근 후 개인 시간이 거의 보장된다.

퇴근 후 개인 시간을 보장해야 하는 이유는 생산선 향상 때문이다. 어차피 하루 8시간 이상은 몰입이 어렵다. 또한 퇴근 후에 영어, 운동, 신기술습득, 문화활동 등 장기적으로 성장하기 위한 활동을 해야한다. 그리고 야근이 없다는 오해도 있는데 야근은 있다. 최대한 합리적으로 프로젝트를 진행하려고 하지만 야근에 내몰리는 경우도 종종 있다. 또한 자발적으로 야근을 하는 개발자도 있다.

개발일정은 개발자가 정한다.

기본적으로 맞다. 하지만 여유로운 개발일정을 정하는 것은 절대 아니다. 프로젝트마다 일정의 중요도가 다르기 때문에 프로젝트마다 다른 기준에 따라서 일정이 정해진다. 개발자가 산정한 일정을 가장 우선시하지만 가끔은 고정된 일정에 개발자가 맞춰야 할 때도 있다. 이때는 합리적으로 조정하려고 노력한다. 부족한 일정만큼 개발자를 더 투입하거나, 외주를 투입하거나, 기능을 축소하거나, 단계별로 기능을 제공하거나, QA를 더 투입하거나, 상용 라이브러리를 구매하는등 여러 수단을 동원한다. 스펙을 철저히 쓰고 그렇게 합리적으로 진행하더라도 예상치 못한 Task가 추가로 생기는 등의 변수로 인해서 어려움에 봉착하기도 한다. 이를 해결하기 위해서 PM(Project Manager)과 TL(Technical Leader)은 머리를 맞대고 해결책을 고민한다. 최대한 합리적으로 계획을 세우고 해결책을 수립해도 프로젝트에는 어려움이 닥친다.  PM과 TL은 노하우를 쌓아서 이런 상황을 최소화 해나가고 있다.

개발자 캐리어는 확실히 보장한다.

개발자는 확실히 개발만 하게 한다. 그래야 효율성이 높기 때문이다. 전문 PM이 별도로 있어서 관리는 PM이 전담한다. PM 또한 대단한 전문성을 요구한다. 개발자에게는 개발만 요구하기 때문에 개발자로서 확실한 실력을 보여줘야 한다. 끊임없이 공부하고 노력해서 연차에 걸맞는 실력을 보여줘야 한다. 그렇지 않으면 신입 개발자들에게 밀리는 일이 발생한다. 사람들과의 관계와 공력으로 버티는 개발자들은 살아남기 힘든 환경이다. 야근이 별로 없다고 하더라도 퇴근 후에 해야 할 공부가 많다. 개발자는 평생 공부해야 한다고 하지만 성향에 따라서는 쉬운 일이 아니다. 나조차도 종종 고3때보다 공부를 더 하는 것 아닌가 생각할 때가 있다.

모든 것을 공유해야 한다.

공유하지 않는 것은 거의 없다고 보면 된다. 오늘 내가 한 모든 것이 온라인 시스템을 통해서 공개되고 공유된다고 보면 된다. 서로 만나서 말로 논의하고 끝나는 경우가 없다. 10분짜리 회의라도 Wiki 시스템에 기록이 남고 ITS(Issue tracker system)을 통해서 모든 이슈(버그, 개선, 신기능, Task 등)는 시스템에 기록되고 온라인으로 논의한다. 개발외에도 모든 업무가 온라인을 통해서 진행된다. 모든 직원이 당장 떨어져서 일해도 전혀 어려움이 없는 상황이다. 글로 적는 습관과 실력이 없는 사람들은 보통 곤역스러운 일이 아니다.

이것은 회사에게는 큰 장점이다. 직원이 하나 갑자기 빠져나가도 회사는 문제 없이 돌아간다. 하지만 개발자에게는 좋기도 하고 나쁘기도 하다. 열심히 일한 개발자는 자신이 과거해 해놓은 일에 발목을 잡혀서 새로운 일을 못하지 않는다. 언제든지 다른 사람들에게 유지보수를 맡기도 새로운 일을 할 수 있다. 하지만 의도치 않게 자신의 지식과 정보를 숨겨서 이를 자신의 존재가치로 삼는 개발자에게는 아주 안좋은 환경이다. 이런 회사는 개발자가 중요한 자산이기도 하지만 Risk가 되기도 한다.

자연스럽게 모든 정보를 시스템에 남기는 형태로 일하는 것은 습관이 되기 전에는 매우 곤역스러운 일이다. 따라서 모든 개발자에게 꼭 좋은 환경이라고 볼 수는 없다.

개발을 위한 신입사원 교육이 없다.

신입사원 교육이 있기는 하지만 회사의 일반에 관련된 내용이고 개발을 하기 위한 신입사원 교육이 없다. 이는 좋기도 하고 나쁘기도 하다. 신입사원은 입사하자마자 이슈(버그, 신기능, 개선 등)를 할당 받기 때문에 알아서 개발을 해야 한다. 단, 시스템에 거의 모든 정보가 있기 때문에 정보를 찾아가면서 개발을 해야 하고 멘토나 팀장이 가끔 가이드를 해준다. 하지만 옆에 끼고 가르치는 것은 없다. 고참들은 신입사원이 많이 들어와도 이들을 가르치기 위해서 시간을 빼앗기지 않는다. 신입들은 아무도 가르쳐주는 사람이 없어서 막막하겠지만 시스템을 검색해보면 필요한 정보가 거의 다 있기 때문에 본인의 능력여하에 따라서 훨씬 빨리 배울 수 있다. 또한 자연스럽게 본인들도 공유하는 습관을 가지게 된다.

이렇게 어떤 개발자에게는 좋은 환경이기도 하고 어떤 개발자에게는 매우 나쁜 환경이 되기도 한다. 하지만 이런 과정을 통해서 모든 프로젝트는 일정을 지키며 개발자들의 생산성은 매우 높다. 개발자는 글로벌 회사의 개발자들과 다를바 없는 수준으로 꾸준히 회사와 같이 성장할 수 있도록 노력하고 있다.

막연히 좋은 점만 상상을 했다면 이우소프트는 그런 모습은 아니다. 회사가 글로벌 회사들과 경쟁하는 것이 목표이며 이를 위해 필요한 모습을 갖추고 있을 뿐이다. 성향이나 적성이 일치하다면 좋은 환경이지만 그렇지 않다면 적응하기가 쉽지 않다. 물론 신입개발자들은 대체로 적응을 잘한다. 백지에는 무엇이든지 잘 써지기 때문이다.

이우소프트에는 이것이 있다 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% 이상을 리뷰에 할애한다.

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

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

즉석 라면이 있다.

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

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

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

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.

그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.

완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

 

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.

모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.

SW회사에는 왜 수평적인 조직문화가 필요한가?

한국 소프트웨어 개발 환경이 이렇게 열악하고 기업의 소프트웨어 경쟁력이 미천한 이유의 핵심은 글로벌 소프트웨어 회사와는 엄청나게 다른 개발문화, 기업문화 때문이라고 생각한다. 그래서 필자는 지속적으로 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례도 공유하고 있다.

​

이번에는 소프트웨어 회사에 왜 수평적인 조직문화가 꼭 필요한지 설명하려고 한다.

​

한국 대기업을 다니는 외국인 직원이나 외국에 있는 한국 회사에 다니는 외국인들의 한국 회사에 대한 평가는 인터넷에 많이 올라온다. '글래스도어'도 그 중에 하나고 필자는 대기업에서 일하고 있는 외국인 개발자들을 인터뷰하기도 했었다.

​

좋은 얘기도 많지만, 문제를 찾아야 하는 입장에서 문제점으로 지적된 것을 봐야 한다. 그 중에 대표적인 것은 한국 기업은 '군대'와 비슷하다는 것이다. 군대식 상하 조직이 한국 사람들에게는 상당히 자연스러운데 이런 조직 문화는 소프트웨어를 개발하는데 있어서는 심각한 걸림돌이 된다. '까라면 까라'로 대표되는 군대식 상명하복 문화를 가지고는 글로벌 회사들과 경쟁하기 어렵다. 어렵사리 글로벌 시장에 진출하여 세계 상위권에 올라섰다고 하더라도 곪은 문제는 언젠간 터지게 마련이고 나락으로 떨어지는 것은 한 순간이다.

​

소프트웨어는 인류가 만들어 낸 가장 복잡한 지식 산업이다. 물론 상명하복식 조직 문화가 매우 효과적인 산업 분야도 있다. 하지만 창의적인 지식 산업인 소프트웨어 분야에서는 상명하복식으로 성장할 수 있는 데는 한계가 있다.

​

상급자가 모든 것을 알 수는 없다. 경영자도 소프트웨어 개발에 대한 모든 것을 알 수가 없다. 그런데도 경영이나 영업 관점으로 목표를 제시하고 '까라면 까라는 식'으로 일을 추진하면 시한폭탄을 계속 심는 것과 다를 바가 없다. 개발에 1년이 걸릴 프로젝트를 시장 상황 때문에 6개월안에 개발을 하려면 전문가들이 머리를 맞대고 합리적인 단축 방법을 찾을 수도 있다. 하지만 합리적인 해결책은 무시하고 명령식으로 압박을 하면 프로젝트는 어찌어찌 진행이 되지만 중요한 핵심 프로세스들이 생략될 수밖에 없다.

​

코딩은 빼먹을 수가 없으니, 스펙을 대충 정하거나 분석도 하지 않고 코딩을 시작해야 하며, 설계도 없거나 부실하고, QA도 대충할 수 밖에 없다. 어떻게든 결과가 나왔다고 하더라도 출시 후에 더 큰 비용을 치르거나 또 하나의 시한폭탄을 심어 놓은 상황이 된다.

​

이런 일이 벌어지는 이유는 상하관계가 확실하고 윗사람이 거의 생사여탈권에 가까운 평가권과 인사권을 가지고 있고 아랫사람은 윗사람과 특히 최고 경영자의 눈치를 심하게 봐야 하는 기업 문화 때문이다. 이런 조직에서 성장해온 관리자들은 어렵게 획득한 막강한 권한을 내려 놓기는 쉽지 않다. 자신 혼자 내려 놓을 수 있는 것도 아니다. 그래서 기존 조직, 특히 대기업이나 중견기업이 수평적인 조직으로 바뀌는 것은 거의 불가능하다.

​

수평적인 조직이란 모든 직원이 평등하다는 것을 말하는 것이 아니다. 각자 전문가로서 역할을 할 수 있어야 하며, 전문가로서 목소리를 낼 수 있어야 하며, 전문가로서 제시한 의견을 존중 받아야 한다는 의미다. 이때 직급, 나이, 경력은 의미가 없다. 상하 관계가 아닌 전문가로서의 의견이 잘 조율돼서 조직이 할 수 있는 최선의 결정을 내릴 수 있어야 경쟁력을 갖출 수 있다.

​

그럼 필자가 CEO로 있는 이우소프트의 수평적인 조직문화에 대해서 소개를 하겠다.

​

수평적인 조직문화는 다른 모든 조직 문화를 떠받치는 기초와 같다. 자율, 토론, 차근차근, 전문가 존중 등 이우소프트가 지향하는 기업 문화는 상명하복 문화가 철저한 조직에서는 잘 작동하지 않는다. 그래서 수평적인 조직 문화를 정착하기 위해서 많은 노력을 했다.

​

첫째, 모두 영어 이름을 부른다.

​

영어 이름을 부르는 것은 단순히 유행을 따르는 것은 아니다. 호칭은 사람의 생각을 지배하고 존칭과 하대가 섞인 대화에서는 상하 관계가 떠오를 수밖에 없다. 그래서 많은 회사들이 호칭 개혁을 하려고 '~님', '~프로' 등 다양한 시도를 하지만 제대로 정착된 곳이 많지는 않다. 하지만 영어 이름을 부르는 것은 이미 검증된 방법이다. 영어이름을 부르면 직급을 부르지 않아도 되고, 제3자가 보더라도 상하 관계를 읽을 수가 없다.

​

그래서 이우소프트에서는 서로 영어 이름을 부르고 있고 영어 이름을 부를 때 존칭을 사용하는 것은 금지되어 있다. 모든 사람이 서로 존대를 하되 '~께서'라고 부르는 것도 금지되어 있다. 내 영어 이름은 레이몬드(Raymond)인데, "레이몬드께서 그렇게 말씀 하셨습니다."는 금지된 표현이고 "레이몬드가 그렇게 말했습니다."가 허용된 표현이다.

​

직책을 부르는 것도 금지되어 있다. 팀장님, 대표님과 같은 호칭도 부르지 못하도록 되어 있다. 적응하는데 시간이 꽤 걸렸고, 한국 이름을 부르거나 직책을 부르면 1,000원씩 벌금을 내야 하고, 이제는 완전히 정착이 되었다. 그렇게 모인 벌금은 연말에 불우이웃 돕기를 하기로 되어 있다.

​

특히, 신입 사원들은 가장 빨리 적응을 했다. 각자 직급은 나눠져 있기는 하지만 부르지 않기 때문에 서로의 그레이드(Grade)를 잘 모르고 있다. 회사에 외국인 개발자는 점점 늘고 있고, 영어 사용이 늘고 있어서 영어 호칭이 도움이 되고 있다.

​

둘째, 상하 관계로 의사 결정을 하지 않는다.

​

즉, 전문가를 존중한다. 수평적으로 나뉜 역할에 의해서 대부분의 결정을 한다. 소프트웨어 회사에는 수많은 전문 역할이 있다. 소프트웨어 엔지니어(Software Engineer), 소프트웨어 아키텍트(Software Architect), CTO, 프로젝트 매니저(Project Manager), 프로덕트 매니저(Product Manager), 리스크 매니저(Risk Manager), 빌드 엔지니어(Build Engineer), 테크니컬 라이터(Technical writer), 마케터(Marketer), UI 디자이너, QA 엔지니어, 형상 관리자(Configuration Manager) 등 여러 역할이 있다.

​

물론 작은 회사는 한 사람이 여러 역할을 하며 이 모두를 다하기도 한다. 하지만, 회사가 조금만 커져도 역할을 나누며 각각 전문성을 높여 나간다. 그리고 전문가의 의견을 최대한 존중하고 상하 관계로 의사결정의 뒤엎지 않는다. 자신의 전문 역할이 아니라도 의견을 제시할 수는 있고 토론을 할 수는 있지만 무리하게 남의 전문영역에 침범을 하면 안 된다.

​

"전권을 주면 내가 프로젝트를 성공시켜보겠다"라고 말하는 사람들이 있다. 이우소프트에서는 이런 말은 통하지 않는다.

​

제품의 기능을 결정할 때는 세일즈, 마케팅, 개발팀, 경영진의 의견은 대부분 상충된다. 이때 직급의 힘으로 의사 결정을 하지 않는다. 각자 전문가로 역할을 수행하며 논쟁을 하고 경영진은 회사의 비전과 프로젝트의 목표에 알맞게 균형을 맞추고 조율하는 일을 주로 한다. 직원을 채용할 때도 신입이나 주니어 급 직원은 상관없지만 경험이 많은 직원을 채용할 때는 권위의식이 있는지 상명하복에 익숙한지 잘 살핀다.

​

셋째, 허락 받고 일하기 보다는 자율적으로 일한다.

​

상사가 일을 시키고 하급자는 시키는 일을 하는 구조가 아니다. 대부분은 스스로 일을 찾고, 스스로 할 일을 정해서 한다. 물론 시켜서 하는 일도 있다. 하지만 능동적으로 스스로 일을 찾아서 하는 것을 권장하고 있고, 하는 일은 모두 시스템에 등록을 하기 때문에 팀장이나 동료들이 모두 모니터링을 할 수 있다. 가끔 일이 잘못 진행되거나 우선순위 조절에 문제가 생기기도 하지만 모니터링을 하다가 바로 잡아주면 된다.

​

업무의 자율성을 높이기 위해서는 뭔가 잘못되었을 때 처벌을 강조하면 안 된다. 처벌이 강할수록 수동적으로 바뀐다. 그리고 문제가 생겼을 때는 여러 사람의 공동책임이다. 시스템에 일을 너무 늦게 공유를 했거나, 모니터링을 소홀히 했을 수가 있다. 프로세스를 잘못 이해하고 있을 수도 있다. 처벌보다는 원인을 찾아서 개선을 해야 한다. 고의로 잘못을 한 것이 아니라면 직원의 일방적인 책임은 아니다.

​

이런 방식이 허락 받고 일하거나 시키는 것 위주로 일하는 것보다는 훨씬 생산성이 높다. 기본적으로 시키는 일보다는 자신이 선택한 일이 더 재미있고 집중도도 높다. 또한 자율성, 창의성이 향상되므로 업무 효율성은 훨씬 높아진다. 물론 모든 직원이 다 적극적이고 능동적인 것은 아니다. 여러 성격의 직원들이 섞여 있지만, 능동적인 직원들의 발전이 더 빠르다. 시키는 일만을 위주로 회사가 돌아간다면 창의적인 지식산업이 소프트웨어가 노동 산업으로 전락할 수가 있다.

​

이우소프트가 이렇게 수평적인 조직문화를 잘 정착한 데는 이유가 있다. 실리콘밸리에서 20년동안 개발을 한 CTO와 수평적인 문화를 당연하게 받아들이는 경영진이 있어서 가능했다. 오히려 직원들이 수평적인 조직문화에 적응하는데 시간이 걸렸다. 한국 대기업들이 수평적이고 자율적인 문화로 조직문화를 탈바꿈하는 것이 쉽지 않은 이유다. 마음만 먹는다고 바뀌는 것도 아니고 경영진은 여전히 무소불위의 권력을 행사하면서 직원들끼리 수평적인 조직문화를 만들 수는 없다. 문화란 대물림이 되고 바뀌기 매우 어렵기 때문에 외국인을 채용하거나 외국 회사를 흡수 합병해도 그들의 문화는 사라지고 기존의 상명하복 문화에 억지로 적응해야 하는 상황이 벌어진다.

​

수평적인 조직문화는 다른 문화의 기반이 되기 때문에 특히 더 중요하다. 수평적인 조직문화 하에서 공유와 협업이 더 잘되며 전문가로서 캐리어를 꾸준히 유지하기도 쉽다. 사규를 만든다고 되는 것도 아니다. 모두의 생각이 바뀌어야 한다. 경영진들이 먼저 수평적인 조직문화에 완전히 적응을 해야 직원들이 따라 올 수 있다.

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

소프트웨어 회사에서 경영자가 하면 안되는 것들

필자는 23년 경력의 개발자이며 이우소프트의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다.

오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서 사람에 따라서는 괴리감을 있을 수 있다. 문화란 원래 경험하지 않은 사람은 괴상하다고 생각할 수도 있고 현실성이 없다고 느낄 수도 있다. 하지만 우리 회사에서는 당연하게 생각되는 것들이고 이런 문화가 글로벌 소프트웨어 기업들과 경쟁하기 위해서 필요하고 생각하기 때문에 소개를 한다. 

첫째, 개발자들의 개발 기간 예측(Estimation)을 무시하기

많은 회사에서 벌어지고 있는 일이고 일방적으로 경영자의 잘못으로 치부하기도 힘들다.

사례는 워낙 많지만 개발자들이 1년 이하로는 도저히 개발할 수 없다고 주장하는 프로젝트를 경영자가 6개월안에 무조건 끝내라고 하는 경우는 매우 흔하다. 이유도 여러 가지다. 개발자의 주장을 믿지 않기도 하고, 프로젝트가 늦어질 것을 감안하여 필요 일정보다 무조건 당겨서 끝내라고 하기도 한다. 또한, 이렇게 개발자를 강하게 압박하지 않으면 개발자들이 야근도 안하고 열심히 일을 안 한다고 생각하는 경영자도 많다. 

당장은 이렇게 해서 몇몇 프로젝트가 성공할 수도 있고 개발 일정도 당겨지고 이익을 보기한다. 하지만, 이런 행위가 관행처럼 굳어지면 결국에는 개발자, 경영자 모두가 손해를 본다. 또한 회사의 개발 문화도 한참 후퇴한다. 경영자가 일정을 무조건 줄이면 개발자는 다음부터 어쩔 수 없이 예상보다 조금씩 늘려서 얘기를 하곤 한다.

개발자도 경영자가 납득할만한 근거를 가지고 적절한 개발 기간을 제시하지 못하는 문제도 벌어진다. 그래서 경영자는 개발자가 제시한 일정을 납득하지 못하고 무조건 일정을 줄이고 본다. 이 싸움은 누구도 승자가 될 수 없는 싸움이다. 개발자는 아키텍처가 망가지는 고통 속에서 야근을 거듭하고 경영자는 프로젝트의 예측 가능성이 낮아져서 비즈니스를 수시로 그르치게 된다.

먼저, 개발자는 잘 분석된 스펙을 바탕으로 납득할 수 있는 일정을 제시해야 한다. 그리고 경영자는 개발자가 예측한 일정을 믿어주는 신뢰관계가 필요하다. 그래야 개발자는 항상 최선을 다해서 정확한 일정을 산정하려고 노력한다. 개발자가 제시한 일정을 단축해야 하는 경우에는 합리적인 수단을 사용해야 한다. 야근도 하나의 방법이기는 하지만 습관적인 야근은 이익보다 손실이 큰 방법이다. 합리적인 수단이란 기능 축소, 핵심 기능에 집중, 단계별 개발, 전문 컨설턴트 투입, 일부 상용 모듈 구매 등 여러 가지가 있다. 

이런 개발자와 경영자 간의 신뢰 관계는 개발 방법론과 상관없이 필요하며 정착하는데 상당한 기간이 필요하다. 그리고 이렇게 개발하는 방법이 소프트웨어를 가장 빨리 개발하는 방법이라는 것을 깨달아야 한다.

둘째, 합의된 요구사항을 경영자의 취향대로 바꾸기

우리나라 회사들은 경영자가 무엇이든지 뒤집을 수 있는 막강한 권력을 가진 경우가 많다. 출시 임박한 제품의 모양을 경영자가 갑자기 바꾸거나, 취향대로 색깔을 바꾸기도 한다. 소프트웨어 분야에서도 흔히 벌어진다.

프로젝트에서 경영자의 역할은 프로젝트마다 다르다. 하지만 경영자가 프로젝트에서 절대 권력자는 아니다. 한 명의 Stakeholder일 뿐이다. 대부분의 프로젝트에서 경영자의 역할은 비전과 전략을 담당한다. 빌게이츠는 초창기 프로젝트의 기술적인 내용까지 깊숙이 간섭을 했는데 이는 경영자로서가 아니고 Chief Architect로서의 역할을 한 것이다.

프로젝트에서 경영자는 경영자 관점에서 비전과 전략 요구사항을 전달해야 한다. 그것도 초기에 제시해야 한다. 전략이 바뀌면 프로젝트는 엄청나게 바뀌는 것이므로 가능하면 초기의 전략이 유지되는 것이 좋다. 전략이 바뀌더라도 합리적인 변경을 해야 한다.

경영자가 프로젝트 막바지에 뒤늦게 관여를 해서 감 놔라 대추 놔라 하는 것은 금기사항이다. 이런 일이 벌어지면 아키텍처는 완전히 엉망이 되고 개발자들의 사기는 땅에 떨어지면 신뢰관계는 금이 간다. 우리 회사에서는 스펙이 Close 된 후에는 경영자가 요구사항을 바꾸려고 해도 Change Control Process를 통과해야 한다. Change Control Board에서 변경이 거부되면 아무리 경영자가 요구한 내용이라고 변경이 불가능하다. 

이래야 경영자도 프로젝트에서 자신의 역할을 제대로 수행하기 위해서 최선을 다한다. 뒤늦게 아무 때나 간섭할 수 있다는 생각은 하지 않게 된다.

셋째, 개발자에게 아무 때나 가서 말을 시키거나 지시하기

우리 회사에서는 경영자뿐만 아니라 누구도 개발자에게 아무 때나 말을 걸고 개발을 방해하지 않는다. 개발자가 개발에 집중을 하고 있는 경우에 중간에 방해를 하면 엄청난 손해가 발생한다. 피플웨어에서는 30분 정도의 손실이 발생한다고 한다. 이런 방해가 하루에 3,4번 벌어지면 하루를 망친다.

개발자와 면담을 할 것이 있으면 몇 시간 전이나 하루 전에 미리 시간을 Arrange해야 한다. 급하게 할 얘기가 있으면 개발자가 집중을 하고 있는지 조심스럽게 살핀다.

그래서 우리 회사에는 메신저도 금지되어 있고 근무 중에는 카카오톡도 무음 설정을 해야 한다. 개발자가 집중해서 일을 하고 있는데 메신저가 부르거나 "까똑" 거리면 집중해서 일할 수가 없다. 개발자에게 전화를 거는 일도 거의 없다. 대신에 근무 시간에 최대한 집중을 하고 야근은 되도록 하지 않는다. 

넷째, 수시로 보고서를 요구하기

공유 문화가 잘 정착되어 있는 회사에서는 진행되는 거의 모든 일이 온라인 시스템에 잘 기록되어 있다. 그래서 별도의 보고서가 없어도 경영자는 거의 모든 내용을 실시간으로 모니터링이 가능하다. 그래서 특수한 경우가 아니면 시스템에 있는 정보를 다시 정리해서 보고하라고 하지 않아야 한다. 보고서는 경영자의 시간을 약간 절약해 주지만 직원들은 수십, 수백 배의 시간을 소모해야 한다. 일보다 보고서 작성에 더 많은 시간을 쏟기도 한다. 또한 보고서만으로 업무를 파악하면 가공과정을 거치면서 내용이 왜곡되곤 한다. 시간이 허용하는 한 최대한 많은 정보를 직접 보는 것이 좋다. 보고서는 꼭 필요한 경우에만 작성해야 한다. 이것이 가능 하려면 공유 문화가 완전히 정착되어 있어야 한다. 

지금까지 네 가지 경영자가 하면 안 되는 일을 소개했다. 그럼 경영자는 별로 할 일이 없는가? 경영자는 회사의 비전, 전략을 정하고 목표를 설정해야 한다. 인재를 채용하고 직원을 코칭, 육성해야 하며 회사의 규칙을 만들고 문화를 만들어가야 한다. 이외에도 경영자가 해야 할 일은 수없이 많다. 

필자는 CEO일 뿐만 아니라 아키텍트의 역할도 일부 수행하며 또한 소프트웨어 국제화 전문가이다. 그래서 소프트웨어 공학, 아키텍처, 국제화 관련 이슈에도 전문가로서 직접 관여를 한다. 하지만 그 외의 것은 위에서 얘기한 것처럼 Stakeholder로서 의논에 참여를 하고 의견을 제시하지만 결정에 과도한 압력을 가하거나 합의된 결정을 뒤집지는 않는다. 합의를 바꾸려면 정해진 절차를 따른다. 

글로벌 수준의 개발 문화 속에서 경영자와 개발자가 각자의 전문 역할을 충실히 수행할 때 글로벌 소프트웨어 회사들과 비로소 경쟁을 시작할 수 있을 것이다.

개발 문화는 후진적인데 개발자 하나하나가 선진적이고 뛰어나다고 해서 소프트웨어가 경쟁력을 갖출 수 없다. 개발 문화라는 것이 반바지를 입는다고 공짜 점심을 준다고 좋은 공학툴이나 방법론을 도입한다고 해서 제대로 정착되는 것은 아니다. 모든 구성원의 마음과 습관을 바꾸는 것이 핵심인데 매우 어려운 과정이며 경영자부터 바뀌지 않으면 안 된다. 

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

개발자가 입사 첫날 버그를 고칠 수 있어야 하는 이유

회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다. 회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 6개월까지 걸린다. 6개월은 내가 인터뷰 한 회사 중에 있었다. 알아야 할 지식과 법규가 많아서 6개월은 공부를 해야 개발에 투입된다고 한다. 

그러다 보니 입사 후 빨리 업무에 투입될 수 있는 동일직종 경력자를 선호하곤 한다. 이런 회사가 많을수록 개발자들은 이직 시 선택의 폭이 좁아지게 된다. 개발자들이 주로 같은 분야로만 옮겨 다니다 보니 이직도 어렵고 업계간 개발자 순환이 잘 안 된다.  

여기 가상의 A, B, C, D 회사가 있다. 

A사는 김부장이 개발 전반의 내용을 다 꿰뚫고 있어서 신규 개발자가 입사하면 김부장이 1주일 정도 교육을 해줘야 한다. 김부장은 다른 어떤 직원보다 개발 내용을 많이 알고 있어서 웬만한 이슈는 다 김부장을 통해야 해결이 된다. 개발자가 입사를 할 때마다 김부장이 교육을 하기 때문에 개발자들이 김부장에게 많이 의존하고 김부장은 회사의 경영진에게도 신망이 두텁다. 

B사는 개발자 입사 시 개발에 필요한 기본적인 제품에 대한 지식이나 기술을 교육 시키기 위해서 선배들이 돌아가면서 며칠 동안 교육을 해야 한다. 물론 교육을 받자마자 신규 개발자들이 개발을 제대로 하지는 못한다. 사수에게 꾸준히 개발 내용을 전수 받아야 한다. 

C사에서는 업무를 잘 알지 못하면 개발을 하기 어렵기 때문에 업무를 모두 파악하는데 6개월 이상이 걸리고 그때까지는 신규 개발자는 허드렛일 밖에 못한다. 고참이 10분이면 할 수 있는 일을 신규 개발자는 몇 시간이 걸리고 잘못될 위험성도 높아서 신규 개발자에게는 일을 제대로 시키지 못한다. 그러다 보니 신규 개발자가 많이 입사를 해도 고참들은 여전히 바쁘다. 

D사에서는 고참들이 기존 제품의 유지보수에 매달려 있어서 신규 개발자에게 업무를 제대로 전달하지 못한다. 그러다 보니 신규 프로젝트는 신규 개발자들이 담당하게 되었고 기존의 개발자들은 여전히 유지보수에 매달리고 있다. 

A~D사 모두 신규 개발자가 입사하마자 스스로 일할 수 있는 체계를 갖추고 있지 못하고 있다. 이런 구조의 회사는 작은 규모였을 때는 문제가 안보이지만 회사가 커질수록 문제가 급속도로 드러나서 개발 효율은 바닥을 치게 된다. 이런 회사에서는 기존의 고참 개발자들은 신규 개발자들의 무능함과 열정 부족을 탓하게 되고 신규 개발자들은 정보 공유 부족으로 개발하기 어려운 환경을 탓하게 된다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 신규 개발자가 입사 후 개발에 투입되어서 버그를 고치는데 시간이 얼마나 걸리는지 물어본다. 그리고 그 과정에서 고참 개발자들이 얼마나 업무를 가르쳐 주기 위해서 시간을 투자해야 하는지 물어본다. 이 질문에 대한 대답을 통해서 그 회사의 개발체계와 개발 문화의 성숙함을 알 수 있다. 대부분의 회사가 일주일 이상 걸리고 몇 달까지 걸리는 회사도 있었다. 또한 많은 회사들이 사수/부사수 제도를 이용하여 고참들이 많은 시간을 투자하여 가르쳐주고 있다. 

내가 생각하는 가장 이상적인 답변은 고참 개발자들의 시간은 거의 투자하지 않고 신규 입사 개발자가 입사 첫날 또는 둘째 날까지 스스로 버그를 고치는 것이다. 고참들은 코드 리뷰를 해주는 정도면 충분하다. 이렇게 할 수 있는 회사는 자세히 물어보지 않아도 성숙한 개발 체계와 개발 문화를 갖추고 있다는 것을 알 수 있다. 불행히도 필자가 접한 우리나라의 수십 개의 회사 중에서 그런 회사는 없었다. 

미국에 취업을 해본 개발자들은 알겠지만, 개발자가 입사했을 때 선배들이 뭘 자세히 가르쳐주는 회사는 많지 않다. 이슈를 할당해주면 알아서 고쳐야 하고 개발 프로세스대로 코드 리뷰 등을 진행할 뿐이다. 물어보면 가르쳐주기는 하는데 먼저 나서서 가르쳐 주는 경우는 별로 없다. 회사는 학교가 아니기 때문이다. 

필자가 CEO로 있는 이우소프트에서도 신규 개발자에게는 이슈를 그냥 할당해주고 개발자는 하루 이틀 안에 이슈를 해결하고 코드리뷰를 진행한다. 물론 여기에 약간의 문제가 있다. 이제부터 어떻게 해야 이렇게 할 수 있고 문제가 무엇인지 얘기를 해보고자 한다. 그럼 시간 순서대로 따라가보자. 

• 2주일 전 - 신규 개발자용 개발 PC를 준비한다.
• 1주일 전 - 신규 개발자가 입사하기 며칠 전에 PM이 미리 신규 개발자가 해결할 수 있을만한 쉬운 버그 몇 개를 할당 해 놓는다.
• 3일 전 - 신규 개발자용 개발 PC에 개발환경을 구축한다. 이미지 백업 받아 놓은 것을 이용해서 한번에 구축한다. 
• 입사 당일 9시 - PM이 개발자에게 이슈관리시스템 URL을 알려주고, 신규 입사자들이 봐야 하는 가이드가 적혀 있는 사이트 URL을 알려준다. (Wiki 등)
• 10시 - 가이드대로 소스코드관리시스템에서 소스코드를 내려 받아서 Build script를 이용해서 Full build를 수행한다.
• 11시 - Build가 진행되는 동안 PM이 알려준 이슈관리시스템의 URL에 접속해서 내가 할당 받은 버그(이슈)를 확인한다. 첫 번째로 고칠 버그를 선택한다.
• 12시 - 식사
• 13시 - 개발 프로세스 문서를 통해서 기본적인 개발 프로세스를 확인한다.
• 14시 - 첫 번째 버그를 고친다. 첫 번째 버그는 간단한 버그라서 스펙/설계 문서 도움 없이 고칠 수 있다.
• 15시 - 소스코드를 commit하고 코드리뷰를 등록한다. 회사에 따라서 코드리뷰를 종료하고 commit하는 회사도 있다.
• 16시 - 리뷰어가 코드리뷰를 진행하고 Confirm을 한다.
• 17시 - 해당 버그 이슈가 close 된다.
• 이제 좀더 빠른 속도로 다른 버그들을 고쳐나간다.
• 개발자의 역량을 확인하고 좀더 어려운 버그와 신규 기능을 할당한다. 

이렇게 진행하기 위해서는 몇 가지 전제조건이 있다. 

• 개발 시스템이 제대로 구축되어 있어야 한다. 이슈관리, 소스코드관리, 빌드 등이 잘 시스템화 되어 있어야 한다.
• 스펙, 설계, 개발 가이드, 개발 프로세스 등의 개발 정보가 Doc, Wiki, Issue 등에 문서로 충분히 기록되어 있어야 한다.
• 신규 입사자가 이와 같은 개발환경에 익숙해서 입사하자 마자 일을 할 수 있어야 한다.

하지만 현실적으로 마지막 조건에 문제가 발생한다. 대학에서 소프트웨어를 전공한 개발자도 이슈관리시스템을 한번도 써보지 못하고 입사를 하는 경우가 대부분이다. 기껏해야 Subversion이나 Git의 기본기능을 써본 것이 개발 시스템을 써본 것의 전부인 경우가 많다. 그래서 회사에서 아무리 준비가 잘 되어 있다고 하더라도 입사 첫날 버그를 고치기는 어렵다. 그래서 기본적인 개발 프로세스와 개발 시스템에 대한 교육을 먼저 시키고 진행을 해야 한다. 이 때문에 하루, 이틀 지연이 될 뿐이지 그 이후에 개발을 하는 것은 별 문제가 없다. 

이런 환경에 개발을 한다면 본인도 자연스럽게 공유를 중심으로 한 개발 문화를 자연스럽게 익히고 대부분의 지식과 경험은 선배들이 남겨놓은 문서를 통해서 습득하게 된다. 그래서 선배 개발자들은 신규 개발자가 입사를 하면 시간을 더 빼앗기는 것이 아니라 귀찮았던 일을 덜어주게 되고 선배 개발자들은 더 어려운 일을 하게 되고 새로운 일을 할 수 있다. 물론 문서로 모든 지식이 공유되는 것은 아니고 선배에게 물어봐야 하는 시간이 상당히 줄어드는 것이다. 공유를 하고 후배 개발자들이 일을 하기 쉽게 만들어 놓는 것은 바로 자신이 앞으로 나아갈 수 있게 만드는 것과 같다. 

신입 개발자가 입사를 하면 아무 것도 가르쳐주지 말고 버그만 달랑 할당해보자. 그리고 무슨 일이 벌어지는지 보자. 선배를 귀찮게 하지 않고 스스로 첫날 버그를 해결하면 문제가 없는 것이고 2,3일 넘어가도 버그를 못 고치면 뭔가 문제가 있는 상황이다. 어떠한 문제 때문에 신입 개발자가 버그를 고치지 못하는지 잘 분석해보자. 거기에 회사의 만들어 나가야 할 개발체계, 개발문화가 있다. 

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

개발자 야근문화를 고쳐야 하는 이유

“월화수목금금금”은 지금도 회자되는 유명한 이야기다. 그리고 모 회사 대표는 신제품 발표회에서 개발기간 동안 개발자가 집에 못 들어가서 이혼을 했다고 자랑 아닌 자랑을 한적도 있다. 개발자들을 연구소에 가둬놓고 밖에서 자물쇠로 잠궈 놓고 주말에도 집에 못가게 했으며 기혼자만 일주일에 하루씩 집에 보내 줬다고 자랑을 하는 경영자도 있다.

자신이 직원들을 얼마나 혹사시켰는지 그렇게 자랑을 하는 이유를 모르겠다. 그래서 한국에서 개발자라는 직업이 유난히 인기가 없고 3D 직종으로 폄하를 하는 모양이다.

많은 경영진이 야근의 효과를 맹신하고 자랑하는 이유는 몇몇 전설적인 성과들이 실제로 있었기 때문이다. 또한 자신들도 초기에 그런 경험을 하기도 했다.

스타트업 초기에 모험심과 열정으로 빠른 시제품 제작과 시장 진입을 위해서 잠도 안자고 일을 하기도 하고 명확한 목표를 가진 어려운 프로젝트를 전직원이 끊임없는 도전을 통해서 결국에 성공을 해내는 기적적인 멋진 성공 스토리가 종종 있다. 여기서 공통점은 명확한 목표와 열정, 자발적인 노력이 있었다는 것이다. 물론 이렇게 해서 성공한 회사도 계속 그렇게는 못한다. 전력질주를 계속하며 마라톤을 할 수는 없다.

그럼에도 많은 경영자들이 야근의 효과를 맹신하는 이유는 야근 말고는 뚜렷한 성과측정 방법이나 생산성 향상 방법을 잘 모르기 때문이다. 세일즈는 숫자로 평가를 하기 때문에 쉽다. 하지만 개발조직은 개발자들이 노는지 열심히 하는지 알기가 어렵다. 개발자들의 프로젝트가 6개월 걸린다는 말도 믿기가 어렵다. 좀더 열심히 하면 4개월이면 끝낼 수 있을 것 같고 과거에도 그렇게 밀어 붙이니 개발 기간을 단축한 적이 있었기 때문에 무조건 압박을 하게 된다. 개발자들도 6개월 걸린다고 주장은 하는데 근거를 가지고 주장을 하지 못하기 때문에 경영자의 신뢰를 얻지는 못한다.

결국 경영자의 유일한 수단은 무조건 일정을 줄이고 직원들을 압박하는 것이다. 물론 압박이 단기적인 효과가 있는 것은 확실하다. 하지만 회사는 100m 달리기를 하고 있는 것이 아니고 마라톤을 하고 있는 것이다. 이를 아는 개발자는 일정을 미리 늘려서 말하곤 한다. 절대로 경영자가 이길 수 없는 싸움이다. 기업문화만 망가진다.

이런 야근 압박의 부작용은 매우 크다. 장기적으로 제품의 품질은 떨어지고 아키텍처는 엉망이 된다. 직원들의 창의력은 사라지고 사기는 저하되며 로열티는 없어진다. 직원들은 사생활을 포기해야 하며 자기계발을 못하고 소모품으로 전락하게 된다. 직원들이 현재 가지고 있는 것을 한 5년 뽑아먹다 보면 그냥 부품이 되어서 직원도 발전이 없고 회사의 미래도 불투명해진다.

소프트웨어는 '창의적인 지식 산업'이며 개발 조직은 '지식공동체'이다. 생산성이 근무시간에 비례를 하는 것도 아니다. 적정 근무 시간이 넘어 가면 생산성은 떨어진다. 공유와 협업에 신경 쓸 겨를이 없어지고 '지식공동체'가 무너져서 각자 따로 노는 조직이 되기 때문이다. 프로세스로 강제해서 '지식공동체'를 만들기는 어렵다. 그렇게 할수록 효율은 더 떨어진다.

SI나 용역을 주로 하는 회사나 재정이 악화되어서 억지로 버티는 회사는 지식 산업에서 점점 멀어지고 있고 단기 수익이 너무 중요하기 때문에 이런 얘기는 모두 공염불일 뿐이다.

야근을 줄이는 가장 좋은 방법은 업무를 계획적으로 하는 것이다. 필자가 CEO로 있는 이우소프트에서는 개발 계획을 세울 때 개발자는 하루에 6시간을 기준으로 계획을 세우며 매우 정확하게 일정을 수립하려고 노력한다. 고참 개발자는 하루 4시간을 기준으로 한다. 나머지 시간은 동료를 위한 시간이다. 스펙, 코드 리뷰도 하고 물어보면 답변도 해준다. 하루에 두뇌를 6시간 풀가동하는 것도 쉬운 일은 아니다. 설렁설렁 일하면 12시간도 가능하다. 물론 너무 재미있는 일이라면 18시간도 몰입할 수 있다. 필자도 어렸을 때는 프로그래밍 재미에 빠져서 하루 18시간씩 개발을 한 적도 있다. 하지만 보통의 경우는 하루 6시간 몰입도 쉽지 않다.

그리고 프로젝트 관리도 제대로 해야 한다. 프로젝트는 리스크(Risk)로 가득 찬 가시밭길이다. 수시로 터지는 리스크는 일정을 꼬이게 만들고 아키텍처를 엉망으로 만들기도 한다. 프로젝트 관리를 제대로 해서 프로젝트가 항상 통제 범위 안에 있어야 한다. 그래야 돌발적인 야근이 줄어 들며 프로젝트 성공 확률도 높아진다. 그리고 이 방법이 프로젝트를 가장 빨리 끝내는 방법이다. 그럼 직원들은 거의 매일 저녁 6시에 퇴근할 수 있다. 그럼 6시 이후에는 무엇을 해야 하나? 물론 6시 이후 시간은 직원의 자유지만 이우소프트에서는 6시 이후에 해야 할 것에 대해서 가이드를 하고 있다.

첫째는 자기계발이다. 영어공부, 운동 등을 규칙적으로 자기 발전을 위해 노력하기를 권장하며 미래의 업무에 필요한 지식 및 기술을 익혀야 한다. 학원을 등록했다가 수시로 발생하는 야근 때문에 포기하는 경우가 많다. 야근이 많은 회사에서는 무엇 하나 계획적으로 할 수가 없다. 무엇을 공부할지는 자율에 맡기기는 하지만 회사에서는 그 내용을 파악하고 상담, 관리, 지원하고 있다. 이것이 직원이 부품이 안되고 5년 후, 10년 후 더 발전된 모습이 되는 방법이다. 그래야 회사도 직원과 같이 발전할 수 있다. 건강을 유지하기 위한 운동은 회사에 피트니스 시설을 만들고 뛰어난 코치를 정직원으로 채용하여 골프, 요가/필라테스, 웨이트 트레이닝을 지원하고 있다.

둘째는 가능하면 가족과 시간을 보내기를 권장한다. 야근을 안했다고 친구들과 술 마시는데 시간을 보내는 것은 가급적 줄이고 가족과 시간을 많이 보내야 한다. 열심히 일하는 목적이 여기에 있기 때문에 굳이 이유가 무엇인지 설명할 필요가 없을 것이다. 회사에서 '이우아이'라는 어린이집을 운영하고 있어서 초등학교 이전까지는 회사에서 보육을 최대한 도와준다.

회사에서 철저히 관리를 하는 것은 프로젝트다. 정해진 시간 안에 프로젝트 목표는 꼭 달성을 해야 한다. 그 외 개발자들의 활동은 회사에서 거의 통제하지 않는다. 스스로 일을 찾고, 만들고, 준비도 한다. 시키는 일만 하는 소수의 직원도 있지만 대부분은 시간과 장소를 가리지 않고 스스로 뭔가를 찾아서 한다. 물론 그 내용은 대부분 공유가 된다. 야근의 유무는 무의미하고 직원의 자율성과 로열티를 높이는데 집중해야 한다.

야근을 100% 없애는 것은 불가능하며 그런 노력을 할 필요도 없다. 강요 없이 자율에 맡겨 놓으면 된다. 업무 절대 시간이 평가에 어떠한 영향도 주지 않는다는 확신을 직원들에게 심어 줘야 한다. 야근 자체가 나쁘다, 좋다 말할 수 없다. 경영진의 야근에 대한 잘못된 맹신이 문제일 뿐이다. 야근을 없애야 하는 이유는 "우리 회사는 야근이 없는 멋진 회사에요"라는 우스운 얘기를 하기 위해서가 아니다. 습관적이고 강압적인 야근 문화의 부작용은 상상 외로 크며 회사의 경쟁력을 서서히 좀먹기 때문이다. 야근 자체가 화제도 문제도 안되는 자율적인 문화가 필요하다.

이 글은 ZDNet Korea와 바텍블로그에 게재되었습니다.