외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.”

“B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.”

“C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할 수도 없다.”

얼마 전 모 신문 기사에 나온 외국인들이 한국의 기업들에 대해 느낀 점을 얘기한 것이다.

국내에서 소프트웨어 개발에 한계를 느낀 대기업들은 해외에 여러 형태의 소프트웨어 조직을 설립하고 현지의 외국인 개발자를 채용하고 있다. 국내 개발자들의 소프트웨어 개발 실력이 떨어져서 소프트웨어를 제대로 개발하지 못했다고 착각하고 있는 것이 아닌가 생각된다.

그런데 우리나라 회사들의 조직 문화와 분위기는 외국에도 이미 소문이 많이 났다. 우리나라 기업문화 자체가 나쁘다고 볼 수는 없으나 소프트웨어 개발자들이 선호하는 문화는 아니다. 소프트웨어 전문가라고 하더라도 이런 조직 문화와 개발 환경에서 소프트웨어를 제대로 개발하기는 어렵다. 그래서 우리나라 회사에서 설립한 외국의 현지 소프트웨어 개발 센터에 들어가기를 꺼려하는 현상이 일어나는 것이다.

이렇게 소프트웨어 개발에 불리한 기업문화를 가지게 된 이유는 여러 가지가 있지만 중요한 이유 중 하나가 우리나라 회사의 경영진들은 소프트웨어 대한 개념이 없기 때문이다. 여기에 상명하복의 “까라면 깐다”는 조직 문화가 더해져서 소프트웨어 산업을 망치는 주범의 역할을 하고 있다.

A사의 사례다. 회사의 사활이 걸리는 매우 중요한 프로젝트가 있었다. 개발자들이 대충 예상을 해도1년반 이상 걸리는 프로젝트였다. 하지만 소프트웨어에 대한 개념이 없는 경영진들은 자신의 재임기간에 성과를 내기 위해서 6개월안에 완성하라고 했다. 기업의 분위기가 까라면 까야 하기 때문에 아키텍처가 완전히 망가지는 것을 감수하고 6개월 안에 완수를 했다. 하지만 그로 인한 피해는 심각했다. 제대로 아키텍처를 완전히 수정해서 개발을 했으면 기간과 비용이 2배 이상 들었지만, 급하게 6개월 안에 완성함으로써 미래에 드는 비용은 수십 배가 증가 했으며 이로 인해서 회사는 망하는 길로 들어섰다.

프로젝트를 완료했을 당시에는 경영진은 1년이 넘게 걸릴 프로젝트를 자신의 리더쉽과 독려로 6개월안에 완성했다는 것을 자랑하지만 이로 인해서 회사가 망하는 길로 들어섰다는 것은 전혀 몰랐다.

개발팀의 아키텍처에 대한 의견은 치기 어린 엄살로 간주하고 탱크같이 밀어붙이는 경영진을 능력 있는 경영진으로 간주하는 것이 현실이다. 이런 무모한 독선은 단기적인 효과는 거둘 수 있어도 미래에는 그로 인해 얻은 이익의 몇 배의 비용을 지불하게 되어 있다.

B사의 경영진은 개발자들이 6개월째 집에도 못 들어가고 프로젝트를 하고 있는 것을 자랑스럽게 얘기한다. 야근을 하면 야근 한 시간만큼 생산성이 비례해서 늘어난다는 착각에 빠져 있는 경영진은 정말로 많다. 야근 강요는 소프트웨어 개발을 지식 산업이 아닌 육체 노동 산업으로 내모는 결과를 가져온다. 야근은 대출과 같아서 단기적인 효과는 있어도 장기적으로는 생산성이 더 떨어진다. 자발적인 야근은 효과가 크지만 강압적인 야근은 생산성과 창의력을 점점 낮추게 된다. 지금도 암암리에 야근을 많이 해야지만 인정 받는 분위기 때문에 어쩔 수 없이 경영진의 기대에 맞추기 위해서 수많은 개발자들이 야근을 하고 있다.

야근은 생산성 저하 외에도 개인 생활과 가족과의 시간을 희생해야 하기 때문에 일을 위해 가족과의 시간을 희생을 감수하는 우리나라 개발자에 비해서 외국인 개발자들에게는 꺼려지는 문화가 아닐 수 없다.

국내의 한 회사에서는 간부들에게는 제품의 아키텍처와 디자인에 절대로 간섭하지 못하도록 최고 경영자의 지시가 있었다. 회사 초창기에는 간부들의 통찰력이 어느 정도 통했지만 회사가 커지고 제품이 복잡해지면서 더 이상 간부들의 간섭은 통하지 않고 오히려 망치는 길이라는 것을 경험적으로 깨달은 것이다.

우리나라 대기업의 경영진들은 자신들이 척박한 환경에서 그 짧은 시간에 기적적으로 회사를 성장 시켰듯이 소프트웨어 역량도 순식간에 따라 잡을 수 있다고 생각한다. 하지만 이는 대단한 착각이다.언뜻 보기에는 간단해 보이는 소프트웨어가 인류가 만들어낸 지식 산업 중에서 가장 복잡하고 어렵다는 것이다.

그 동안 기존 산업에서 익혀온 성공 방정식을 소프트웨어에도 적용하다 보니 잠깐의 반짝 성공은 있었을지 몰라도 급한 한발 내딪음으로 인해서 두발 더 뒤쳐지게 되었다.

외국인 개발자들이 꺼려하는 이러한 환경은 국내 개발자들도 똑같이 꺼려하는 환경이다. 단지 국내에 태어났기 때문에 다른 선택이 어려워 그런 환경이라도 꾹 참고 일을 하고 있는 것이다. 그래서 요즘은 처음부터 외국 기업을 찾는 개발자자도 많다.

외국인들을 위해서 외국인에게 인기가 있는 회사를 무조건 만들라는 것은 아니다. 외국인 개발자에게 인기가 없는 회사가 소프트웨어 개발에 불리한 환경이라는 것이다. 외국인 개발자들에게 인기가 있는 회사가 된다면 국내 개발자들도 일하기 좋은 환경이 될 뿐만 아니라 소프트웨어 산업 전체의 경쟁력도 증가할 것이다.

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

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여야 한다. 그럼 어떻게 회의를 줄일 수 있을까? 
 
물론 개인 혼자서 회의를 줄이려고 노력한다고 해서 되는 것은 아니다. 직원들이 회의를 줄이는 것이 왜 중요하고 어떻게 줄여야겠다는 방법도 서로 공유를 하고 노력을 해야 한다. 일단 회의가 얼마나 비싼 활동인지 생각해보자. 
 
10명이 1시간동안 회의를 하면 얼마의 비용을 쓴 것일까? 회사마다 다르겠지만 적게 잡아도 100만원쯤 쓴 것으로 생각하면 된다. 개발자는 1인당 회사에서 사용하는 비용은 급여와 부대비용을 계산하면 알 수 있다. 여기에 개발자가 그 시간 동안 다른 일을 했을 때의 기회비용까지 계산하면 최소한 한 시간에 10만원은 생각해야 한다. 이보다 낮다고 주장하는 개발자가 있을 수도 있지만 평균 이 정도는 생각해야 한다. 
 
30명이 참석하는 회의에 몇 사람이 늦게 와서 10분 늦게 시작하면 50만원은 그냥 손해를 본 것이다. 이렇게 회의에 직접적으로 소모하는 비용과 회의에 참석하기 위해서 준비를 하거나 자료를 읽는 시간, 회의 참석에 이동하는 시간, 앞뒤로 어영부영 지나가는 시간을 합치면 훨씬 많은 시간을 소모하게 되고 그 비용은 상당하다. 
 
이렇게 비싼 회의는 꼭 필요한 경우에만 효율적으로 해야 한다. 그렇지 않고 회사의 생산성을 높일 수는 없다. 그럼 어떻게 회의를 줄일 수 있는지 알아보자. 회의를 줄이기 위해서는 아래 3가지 원칙을 지키면 된다. 
1. 회의를 하지 않는 것이다. 
2. 회의에 참석하지 않는 것이다. 
3. 회의 시간을 줄이는 것이다. 
 
첫째, 안해도 되는 회의는 하지 않는다. 회의를 전혀 안할 수는 없다. 특히 의사결정은 문서나 시스템으로 하기 어렵고 대부분은 회의를 통해야 한다. 하지만 회의를 하지 않거나 대규모 회의로 하지 않아도 되는데 무신경하게 또는 일상적으로 회의를 하는 경우가 많다. 
 
정보를 단순 공유하거나 브리핑을 위한 회의는 줄일 수가 있다. 일상적으로 시스템을 통해서 공유가 잘 되는 회사는 이런 단순 공유 회의는 거의 하지 않는다. 단, 시스템을 잘 쓴다는 전제하에 이런 회의는 거의 하지 않아도 되는 것이다. 이를 위한 가장 중요하고 유용한 시스템은 이슈관리시스템이다. 이슈관리시스템은 소프트웨어 회사에서는 없어서는 안될 중요한 시스템이다. Trac, Jira, Mantis, Redmine과 같은 시스템이다. 
 
하지만 필자의 블로그에서 시행하고 있는 수년간의 설문 통계를 보면 약 40%의 회사는 아직도 이슈관리시스템을 사용하고 있지 않다. 이메일과 엑셀 등으로 이슈를 주고 받거나 관리를 하는데 그렇게는 효율적인 소통이 어렵다. 게다가 이슈관리시스템을 사용하고 있는 회사도 정말 효율적으로 잘 쓰고 있는 회사는 10%가 안된다. 
 
회의를 줄일 수 있을 정도로 이슈관리시스템을 잘 쓰는 방법은 책 한권으로 설명해도 부족하겠지만 요약하면 다음과 같다.
 
모든 공식적인 요청은 이메일, 전화, 말로 하지 않고 이슈관리시스템에 등록해야 한다. 나머지는 보조수단이다. 전 임직원이 예외 없이 규칙을 따라야 한다. 이슈관리시스템에 대시보드를 자신에게 맞게 잘 만들어서 적어도 하루에 한번 이상 대시보드를 확인하고 처리를 해야 한다. 이슈관리시스템에 이슈를 등록하고 상태를 변경하며 댓글을 다는 등의 행동은 성의껏 해야 한다. 
 
내가 남긴 한 줄의 문장을 수많은 사람이 읽고 공유가 되며 대화와 회의를 대신하고 오랫동안 남아서 여러 사람에게 정보를 제공할 것이기 때문에 엉터리 문장으로 적으면 안된다. 10년 후에 후배가 봤을 때 알아 볼 수 있도록 잘 적어야 한다. 물론 이렇게 사용하려면 무신경하게 엉터리로 사용하는 것보다 약간의 노력이 더 필요하지만 충분히 그럴 가치가 있다. 
 
둘째, 내가 참석하지 않아도 되는 회의는 참석하지 않는다. 
 
회의는 참석자가 적을수록 효율적이다. 내가 참석하지 않아도 되는 회의는 참석하지 않아야 한다. 그리고 회의에 똑 필요한 인원만 초청을 해야 한다. 
 
회의 참석의 목적은 여러가지가 있지만 의사결정을 하기 위한 것이거나, 전문가로서 의견 제시하거나 정보를 습득하려는 등의 목적이 있다. 
 
가끔 회의 요청을 받으면 이런 단순 정보 공유 회의에 내가 왜 참석해야 하는지 의문이 들 때가 있다. 특히 내게 당장 필요하지는 않지만 알면 좋은 정도로 애매한 경우도 있다. 이런 때는 내가 지금 이 시간을 투자해서 참석할 필요가 있는 회의인지를 판단해야 한다. 물론 이런 회의에 무조건적으로 참석하라고 하면 안된다. 누구나 들으면 좋은 회의라고 참석자를 잔뜩 늘려서 초청을 하면 수백만원의 비용을 지불하는 것이라는 생각을 잊으면 안된다. 
 
내가 전문가로서 의견을 제시해야 하는 경우라면 회의 내용을 사전에 꼭 숙지를 하고 참석해야 한다. 이런 회의에 전문가가 아닌 사람을 여러명 불러 놓고 난상토론을 하는 것은 정말로 시간 낭비다. 회의 때마다 잘 알지도 못하지만 그냥 이슈를 마구 던지거나 자신의 취향이 전문적인 의견인양 얘기하는 사람들이 있다. 이런 회의의 참석자는 꼭 필요한 사람으로 잘 꾸려야 한다.
 
리뷰 회의가 대표적이다. 교육적인 목적으로 내용을 익히려고 참석하는 경우도 있지만 각 분야의 가장 전문가가 미리 내용을 한 글자, 한 글자 꼼꼼히 읽어보고 빠르게 의견을 제시해야 한다. 그래서 고참이 될수록 이런 리뷰 회의에 참석하는 일이 많아지게 된다. 
 
셋째, 회의 시간은 최소화 해야 한다. 
 
회의 시작 전에 회의 아젠다를 미리 공유하고 회의 자료나 문서를 미리 배포해야 한다. 회의는 시작 시간과 종료 시간을 미리 정해야 하며 무작정 길게 시간을 잡는 것은 삼가야 한다. 회의에 따라서 다르지만 대부분의 배포된 문서를 꼼꼼히 읽고 와야 한다. 경영진이라고 하더라도 미리 꼼꼼히 읽어야 한다. 회의시간에 자료를 다시 브리핑하는 것은 여간 낭비가 아니다. 
 
따라서 회의 공지는 자료를 충분히 검토할 시간이 필요하므로 충분히 미리 해야 한다. 회의 1,2시간 전에 갑자기 공지를 하면 준비할 시간이 부족하게 된다. 
 
회의시간에는 회의에 집중해서 계획한 시간 안에 꼭 내도록 노력해야 한다. 쓸데 없이 경영진이 교장선생님처럼 이런 저런 얘기를 하는 것은 좋지 않다. 회의 주제에 집중해야 한다. 
 
개발자들과 아침에 하는 5분 회의는 효율적인 회의의 대표적인 예다. 자료는 이슈관리시스템에 있고 대시보드를 확인하며 주요 이슈만 확인을 하고 꼭 공유해야 할 내용을 얘기하면 개발팀 일일회의는 5분에서 10분안에 끝나게 된다. 
 
그 외에 스카이프나 구글행아웃을 이용한 원격회의도 회의를 효율적으로 하게 해준다. 회의를 위해서 먼거리를 이동하지 않고 원격으로 회의를 할 수 있고 요즘은 스마트폰으로 회의를 하기도 한다. 코드리뷰시스템을 사용하는 것도 좋은 방법이다. 온라인으로 코드리뷰를 할 수 있도록 하여 코드리뷰 자체의 효율성도 높아지고 코드리뷰 때문에 모여야 하는 시간을 줄여주고, 코드리뷰 내용을 모든 사람과 공유할 수 있어서 좋은 정보가 된다. 
 
마지막으로 회의를 했다면 가능하면 빠른 시간에 회의록을 정리하여 회의 참석자와 참석하지는 않았지만 관련된 모든 사람에게 회의록을 배포해야 한다. 이슈관리시스템 등의 시스템을 활용해서 회의록을 배포, 관리하는 방법도 좋다. 
 
다시 한번 회의가 얼마나 비싼 활동인지 명심하자. 하루에 회의 3,4번이면 개발자는 다른 일은 거의 못한다. 개발자뿐만이 아닐 것이다. 회의는 지금의 10분의 1로 줄인다는 마음으로 회의를 줄여보자.

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