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

우리나라의 많은 기업들은 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에 기고한 글입니다.

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

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

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

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 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와 기업블로그에 기고한 글입니다.

이 세상에서 가장 먼 길

세상에서 가장 먼 길은 뭘까? 

여기에서 지구 반대 편까지?

김수환 추기경은 “머리에서 가슴까지 내려오는 길”이라고 했다. 여기서 머리는 지식을 말하고 가슴은 마음을 말한다. 즉, 습관을 말한다. 몰라서 못하는 것도 많지만 알아도 행하는데 까지는 긴 시간 동안 수련과 정진이 필요하며 평생 못하기도 한다.

이것이 회사의 기업문화를 바꾸기 어려운 이유 중 한다. 머리로만 알아서 되는 것이 아니라 가슴, 마음이 움직여야 한다. 즉 습관이 되게 해야 한다. 한 개인이 혼자서 습관을 바꾸는 것도 어려운데 많은 사람들이 모여 있는 회사 전체의 습관을 바꾸는 것은 상상을 초월할 정도로 어렵다. 

가장 좋은 것은 좋은 기업문화와 뛰어난 선배들이 많은 회사에 가는 것이다. 혼자서 20년을 정진해도 못 배울 것들을 1,2년 안에 배울 수 있고 그 습관은 평생을 간다. 인위적으로 단기간에 기업문화를 바꾸는 것은 대단한 각오로 추진하지 않으면 어렵다. 

내가 과거에 Survey한 정보에 따르면 10년전만 해도 이슈관리시스템을 쓰는 회사의 비율이 50%가 안되었다. 이제는 80% 이상의 회사가 이슈관리시스템을 쓰고 있는 것으로 추측된다. 하지만 제대로 쓰고 있는 회사의 비율은 10%가 안된다. 제대로 된 방향으로 강력히 드라이브를 해도 3년에서 5년은 걸린다. 하지만 이슈관리시스템을 쓰기만 하는 정도로 제대로 되고 있다고 착각하는 회사가 많다.

예를 들어서 설명하면 스펙은 5년, 빌드는 6개월, 소스코드관리는 1~2년, 공유 협업 문화는 5년 등 기업에서 뭘 하나 바꾸려고 해도 제대로 바꾸는데는 6개월에서 10년이상 걸린다. 이것이 머리에서 가슴으로 내려오는 시간이다. 많은 기업들은 이런 것을 몇개월만에 해치우려고 하고 그렇게 하면 흉내를 내는 것에 불과하고 오히려 부정적인 의식이 팽배해져서 더 손해가 된다.

그럼 가슴으로 내려오기 전까지는 전혀 도움이 안되는가? 그렇지는 않다. 분야에 따라서 다르지만 조금씩 좋아지고 임계점을 넘으면 생산성이 확 올라간다. 하지만 처음에는 생산성이 더 떨어진다. 임계점에 이르는데 짧게는 6월부터 5년이 걸릴 수 있다. Jira나 Redmine 깔았다고 Subversion이나 Git를 쓰고 CI 툴을 이용한다고 생산성이 올라갈 것이라는 생각은 버리자. 골프채 좋은 것 쓴다고 골프를 잘 치는 것이 아니다. 좋은 도구가 꼭 필요하기는 하지만 골프를 잘 치려면 결국에 올바른 훈련법에 따른 오랜 훈련이 필요한 것이다. 

회사가 크면 그만큼 변화가 느리다. 변화를 거부하는 직원이 많으면 실패할 확률이 높다. 

두뇌는 변화를 거부한다. 두뇌는 변화를 위기로 인식하기 때문에 변화를 시도하면 두뇌는 자꾸 원래대로 돌아가라고 명령한다. 작심삼일이 발생하는 이유다. 내가 의지력이 약한 사람이라서 그런 것이 아니라 두뇌의 잠재의식이 명령을 하기 때문이라고 이해하자. 그래서 변화를 거부하는 직원이 있는 것은 당연하다. 그래서 회사가 변화를 하려면 두뇌가 받아들일 수 있을 만큼씩 변화를 해야 하는데 전략이 필요하다. 

변화에 성공하는 회사는 몇% 안된다. 이는 나쁜 일도 아니다. 모든 회사가 변화에 성공해서 다 뛰어나지면 경쟁이 더 치열해질 것이다. 변화에 실패하는 다른 회사와 다른 사람을 탓하지 마라. 그들은 내가 또 우리 회사가 돋보일 수 있는 결정적인 기여자들이다. 

회사에서도 남들에게 영향을 미칠 수 있는 위치에 있다면 “머리에서 가슴까지의 거리”를 생각하자. 직원들이 잘 못한다고 나무라거나 스트레스 받지 말고 습관이 될 수 있도록 꾸준히 가이드를 해야 한다. 6개월에서 10년을 기다릴 각오를 해야 한다.

개발자 입장에서 가장 좋은 자세는 회사나 동료는 생각하지 말고 혼자서 배우고, 바뀌고, 정진하는 것이다. 회사를 바꾸려고 스트레스 받지 말고 스스로 정진하여 좋은 개발자가 되는 것이 좋다.

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

회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다. 회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 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에 기고한 글입니다.

기업문화를 바꾸기 어려운 이유

요즘 테슬라도 GE도 너도 나도 소프트웨어 회사라고 선언을 하고 소프트웨어에 엄청난 투자를 하고 있다.

그 와중에 우리나라 회사들은 소프트웨어에 실패했다고 자성을 하고 있다. Google의 1/100 실력이라고 자수를 하기도 한다. 최근에 대기업들의 대대적인 구조조정으로 수많은 소프트웨어 개발자들이 노동시장으로 쏟아져나 왔다.

우리나라 기업들도 소프트웨어만이 살길이고 소프트웨어 엄청나게 투자를 한다고 한 것이 불과 10여전 밖에 안되었다. 그 동안 수많은 소프트웨어 개발자를 채용하고 교육하고, 기업문화를 바꾸기 위해서 엄청나게 애를 썼다.

그런데 왜 결과가 이런가? 필자는 소프트웨어 개발에 있어서 기업에게 가장 중요한 것은 천재적인 개발자도 아니고, 엄청나게 많은 돈을 투자해야 하는 것도 아니고 바로 "기업문화"라고 생각한다.

물론 우리나라 대기업들이 "기업문화" 개혁에 투자를 하지 않은 것이 아니다. 엄청나게 투자를 했다. 그런데 왜 과거와 별반 다른 것이 없을까? 물론 조직이 너무 크고 기득권 세력이 강해서 쉽게 바뀌지 못하는 한계도 있다.

필자는 여러 기업에서 기업문화를 바꾸겠다고 얘기를 할 때 실패를 할 것이 뻔히 예상된다. "기업문화"를 넘어서 "문화"란 남들이 하는 것을 보고 흉내를 내기는 어렵다. 기껏해야 공짜 점심 같은 것을 흉내낼 뿐이다.

여기에 개들이 다니는 "D"사가 있다. "D"사의 개들은 모두 네발로 걸어 다닌다. 그런데 그들이 배우고 싶은 "H"사의 개들은 두발로 다니고 SW 개발 역량이 D사의 100배이다. 그럼 어떻게 해야 D사는 H사의 문화를 배울 수 있을까? D사의 경영진들은 H사의 개들이 두발로 걸어 다니고 두발로 걷는 것은 SW 개발 역량 향상에 필수적이라는 것은 이미 알려진 사실이므로 D사 직원 모두에게 이제부터 모두 두발로 걷게 한다. 하지만 두발로 걷는 것은 보통 어려운 것이 아니다. D사의 직원들은 남들이 볼 때는 두발로 걷고 안볼 때는 네발로 걷게 된다. 또한 이런 어려움을 아는 관리자들은 형식적으로 점검을 하게 된다. 네발로 걷는 것이 익숙한 관리자들은 말로는 "두발로 걸어야 한다"고 하면서도 어떻게 해야 하는지 잘 모른다. 형식적으로 흉내를 낼 뿐이다.

이 과정에서 D사의 직원들은 죽을 맛이다. 두발로 걷는 방법을 제대로 알려주지도 않고 겉모습만 잔뜩 알려주니 따라할 수가 없다. 겉으로는 두발로 걷는 척해야 하고 실제 일은 네발로 해야 진행이 되므로 일은 두배로 힘들어진다.

D사의 경영진들은 직원들이 모두 두발로 걷는데 왜 여전히 SW 개발 역량이 향상되지 못하는지 한탄을 하게 된다.

내가 생각하는 D사가 바뀌는 방법은 이렇다. 먼저 두발로 걷는 것이 당연한 H사나 비슷한 회사의 전문가들이 D사의 중요 직책으로 들어온다. 이들은 D사의 직원들을 두발로 걷게 하고 같이 일하면서 수백 가지의 노하우를 직원들에게 전수한다. 직원들이 수시로 네발로 걸으려고 할 때마다 그 상황에 맞게 코칭을 계속한다. 이러면서 새로 D사에 입사한 직원들은 두발로 걷는 것이 당연한 환경에서 생활을 하게 된다. 이렇게 10년쯤 일을 하면 D사에서도 개들은 두발로 걷는 것이 당연한 문화가 된다.

그래서 문화가 바뀌려면 적어도 10년은 각고의 노력을 해야 한다고 생각한다. 완전히 정착하려면 세대가 바뀌어야 한다. 기업에서 세대가 바뀌는데는 10년이 걸린다.

SW를 개발하는데 핵심 문화인 "수평적인 조직", "공유", "문서", "리뷰", "토론" 등 여러 문화는 남들이 하는 것을 보고 흉내를 낼 수 없다. Template과 Process를 흉내내면 더 망가질 뿐이다. 또한 전문가를 영입해도 힘이 없으면 고군분투하다가 포기할 뿐이다.

Google의 1/100 실력이라고 하면서 또, 과거와 비슷하게 스스로 열심히 뭔가 개혁을 해보려고 하고 단기간에 성과를 내보려고 한다면 매번 반복되는 현상이 이번에도 반복될 것이다. 

share with abctech.software