태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

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

2014.11.02 17:17 by 전규현


잠시 후 Google blogger로 이동됩니다.







'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여야 한다. 그럼 어떻게 회의를 줄일 수 있을까? 
 
물론 개인 혼자서 회의를 줄이려고 노력한다고 해서 되는 것은 아니다. 직원들이 회의를 줄이는 것이 왜 중요하고 어떻게 줄여야겠다는 방법도 서로 공유를 하고 노력을 해야 한다. 일단 회의가 얼마나 비싼 활동인지 생각해보자. 
 
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에 기고한 칼럼입니다.


저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 회의

  1. Blog Icon
    김소유

    초대장 부탁 드립니다.
    soyu2808@naver.com

  2. 이미 초대되었다고 나오네요. 다른 분이 초대를 한 것 같습니다.

  3. Blog Icon
    flash2875

    초대장 부탁 드립니다. 꼭 가입하고 싶어요.
    kei09125@naver.com

한국의 개발자는 쓸데없이 바쁘다

2014.10.14 09:45 by 전규현


잠시 후 Google blogger로 이동됩니다.







한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

 

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

 

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

 

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

 

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.


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

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 기반시스템, 집중, 프로세스

  1. 안녕하세요? 정성들여 쓰신 글 잘 보았습니다. 저도 IT와 관련하여 블로그를 개설해보고 싶습니다. 초대해주시면 안될까요? :)

  2. 제가 초대해드려요?

  3. Blog Icon

    비밀댓글입니다

  4. Blog Icon
    윤남기

    글 잘 보고 있습니다. 최근에 많이 읽게 됐는데 이렇게 좋은 글 올려주셔서 감사합니다.

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

2014.09.30 23:05 by 전규현


잠시 후 Google blogger로 이동됩니다.





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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


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

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발문화, 글로벌, 마케팅, 전략

  1. 잘 보고 갑니다. 오늘 하루 좋은 일 가득 하세요. ^^

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

2014.08.30 15:38 by 전규현


잠시 후 Google blogger로 이동됩니다.






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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발문화, 유지보수, 휴가

  1. 잘 보고 가요. 좋은 하루 되세요. ^^

  2. 글을 읽고 나니 생각이 바뀌는군요 ㅎㅎ

  3. 나 없으면 회사가 안 돌아간다는 자신있게 얘기한 제가 부끄러워지네요^^;;

편한 개발환경이 가져온 부작용

2014.08.16 13:40 by 전규현


잠시 후 Google blogger로 이동됩니다.





필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 

 

숫자를 문자로 변환한다든지, 숫자 몇 개를 정렬하는 등 아주 단순한 문제다. 코딩 테스트에서 확인하는 것은 개발자의 논리적인 사고, 창의력, 문제 해결 능력이다. 그리고 문제를 해결하기 위해서 면접관과 어떻게 커뮤니케이션을 해나가는지 보는 것도 중요한 요소다. 문법은 중요하게 보지 않고 개발언어는 아무거나 선택해도 된다. 

 

실제로 여러 지원자에게 코딩 테스트를 실시하면 안타깝게도 코딩 테스트를 통과하는 비율은 매우 낮다. 경력은 화려하게 잘 얘기하는데 코딩 및 논리적인 사고는 어처구니 없이 형편없는 경우가 많다. 그래서 서류 심사를 통과한 지원자를 대상으로 온라인 코딩 테스트를 먼저 실시하곤 한다.

 

온라인 코딩 테스트는 약간 난이도가 있는 문제를 주고 24시간 안에 코딩을 해서 제출하게 하는 것이다. 컴파일이 되어야 하고 실행이 되어야 하며 알고리즘의 효율성을 보기 위해서 실행 제한 시간도 있다. 이런 온라인 코딩 테스트는 어차피 인터뷰에서 탈락할 지원자를 걸러줌으로써 인터뷰 시간과 비용을 절약하는데 도움이 된다. 

 

얼마 전 온라인 코딩 테스트를 실시하는데 어처구니 없는 일이 발생했다. 온라인 코딩 테스트는 꼭 본인이 작성해야 한다는 규칙이 있다. 하지만 온라인의 특성상 주변 지인들에게 약간의 힌트성 도움을 받는 것은 어쩔 수 없다고 생각하고 있다. 출제한 문제는 유명한 코딩 테스트 사이트에서 가져온 문제다. 

 

하지만 지원자는 문제를 받자마자 본인이 풀 생각을 하지 않고 바로 인터넷을 검색하여 해당 사이트를 찾아냈다. 그리고 해당 문제를 푼 사람을 찾아서 소스코드를 보내달라는 이메일을 보낸 것이다. 그런데 이메일을 받은 사람은 프로 개발자가 아니라 초등학생이었던 것이다. 전문 개발자를 채용하려고 실시하는 코딩 테스트에서 자신이 못 풀겠다고 초등학생에게 소스코드를 요청하는 일이 발생한 것이다. 

 

인터넷을 검색해서 알고리즘을 참고한다 던지 아이디어를 구하는 것은 가능하지만 소스코드를 달라고 하는 것은 명백한 속임수(Cheating)이라고 생각한다. 이런 개발자는 실력을 떠나서 채용할 수가 없다. 

 

다른 사례다. 온라인 코딩 테스트를 훌륭하게 통과해서 인터뷰를 진행한 개발자 얘기다. 그런데 칠판 코딩 테스트에서 이상한 일이 발생했다. 온라인 코딩 테스트 문제는 개발자의 논리력, 창의력이 없으면 풀기 어렵기 때문에 칠판 코딩 테스트에서 좋은 결과를 보여줄 것으로 예상했는데 인터뷰 현장에서 형편 없는 결과를 보여줬다. 

 

혹시 긴장해서 원래 실력을 보여주지 못하는 것이 아닐까 생각해서 여러가지 질문을 해봐도 원래 실력이 없었다는 것이 확인이 되었다. 그렇게 탈락을 한 후 이상한 생각이 들어서 온라인 코딩 테스트에서 제출한 답안을 인터넷에 검색을 해보니, 해당 문제를 미국에서 자바로 풀어 놓은 답안과 한 글자도 틀리지 않고 동일한 것을 확인했다. 

 

그 뒤 온라인 코딩 테스트를 세상에 없는 문제로 새로 만들어야 고민을 했지만 지원자가 속임수를 쓰는지 확인할 수도 있으므로 그냥 진행하기로 했다. 단, 지원자에게는 본인이 직접 풀어야 한다고 꼭 당부를 하고 있다. 

 

이런 일이 발생하는 이유는 무엇일까? 요즘 개발자들은 과거에 비해서 훨씬 개발하기 편한 환경에 있다. 개발하다가 필요한 모듈이나 알고리즘은 인터넷을 검색해보면 다 찾을 수 있다. 그러다 보니 원리는 생각하지도 않고 본인이 이해도 하지 않고 그냥 인터넷에서 소스코드를 가져다가 사용하는 경우가 매우 많다.

 

과거에 인터넷(웹)이 없을 때나 초창기 까지는 소스코드를 구할 곳은 책을 제외하고는 별로 없었다. 그래서 개발자들이 책을 많이 보고 본인이 이해를 해서 직접 구현을 해야 했고, 그러다 보니 소프트웨어 이론에 대해서 속속들이 잘 알아야 했다. 과거에 뛰어난 개발자가 더 많았던 이유는 이런 환경에 기인한 것이 아닌가 생각된다. 

 

요즘은 쉽게 소스코드를 구할 수 있다 보니 깊게 생각하는 습관을 가지기는 어렵다. 개발자들의 고충을 이해하지 못하는 것도 아니다. 촉박한 시간 안에 빨리 구현을 해내야 하고 누가 설계를 잘 해주는 것도 아니고 서로 리뷰를 통해서 내가 작성한 코드를 누가 잘 봐주는 경우도 흔치 않다. 

 

그러다 보니 부랴부랴 인터넷에서 구한 소스코드를 이해도 못하고 그대로 사용하기 일쑤다. 요즘 개발자들을 만나보면 소프트웨어 이론을 속속들이 잘 모르는 경우가 많다. 메모리의 기본 구조도 잘 모르고 기본적인 자료구조와 알고리즘도 잘 모르곤 한다. 대학에서 이런 기본 이론을 철저히 가르쳐야 하는데 이런 이론보다 실무를 가르치는 것이 아닌가 의구심이 들기도 한다. 모든 대학이 그런 것은 아니지만 이론보다 실무를 가르친다면 학원과 다를 것이 없다. 그래서 실무 중심 사관학교라는 대학의 광고를 듣다 보면 안타까운 생각이 든다. 

 

이렇게 개발하기 좋은 환경이 오히려 개발자들의 실력을 떨어뜨리고 있는 것이 아닌가 걱정이 되고 있는 사례들이다. 현재 소프트웨어 공부를 하고 있는 학생이라면 실전 코딩보다도 소프트웨어 기초 이론을 철저히 익히라는 얘기를 하고 싶다. 실전 경험도 중요하지만 기초가 약하다면 언제든지 문제가 될 수 있다. 

 

회사에서는 개발자에게 이론, 경험을 전파하는 수단은 코드리뷰, 설계리뷰다. 선배 또는 동료가 소스코드나 설계서를 보고 리뷰를 하면서 서로의 경험과 이론, 노하우를 전달하는 것이다. 서로 리뷰를 통해서 개발자는 같이 성장해나가는 것이다. 피어리뷰(동료검토)를 하지 않거나 형식적으로 하지 않는 회사에서는 개발자들의 성장이 몇 배 느릴 수 밖에 없다. 

 

개발자는 구글을 믿고 개발을 할 것이 아니고 믿어야 할 것은 자신의 두뇌와 동료들이다. 구글은 단지 거들뿐이다.


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

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발문화, 개발환경, 구글, 알고리즘, 코딩테스트

  1. Blog Icon
    Library

    좋은 글 잘 보고 있습니다.

  2. 글 잘보고 갑니다 저도 후배 사원과 코드리뷰를 하는데. 말로 다시 코드를 설명하다보면 오류나 비 논리적인 부분도 발견하고 일의 능률도 오르더 군요.

개발자에게 재택 근무가 필요한 이유

2014.06.17 22:51 by 전규현


잠시 후 Google blogger로 이동됩니다.







과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

 

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

 

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.


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

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 시스템, 재택근무, 프로세스

  1. Blog Icon
    김한준

    항상 좋은 글 잘 읽고 있습니다. 특히 공유와 문서화의 힘이 언급될 때 많이 공감합니다.

  2. Blog Icon
    박경호

    좋은 글 잘 읽었습니다. 나름 제 상황과 비교하면서 읽게 되네요.

    글 처음부터 끝까지 읽으면서 계속 남아있던 한가지 질문은 '어떻게 믿지'입니다.
    물론 이 질문도 받아보셨겠지만 신뢰에 대한 얘기도 해주셨으면 합니다.

    지방 중소기업은 인력 구하기가 힘듭니다. 좋은 인재와 같이 일한다면 좋지요.
    허나 그 사람의 실력이 어떻든간에 멀리 떨어져 있는 사람을 재택근무로 채용한다는건 쉬운 일이 아닙니다.

    나름 깊은 고민입니다. 글쓴이님의 글에 해답이 있었으면 하는 바람입니다.

  3. 단순히 믿음의 문제는 아니고 시스템, 프로세스, 문화가 뒷받침이 되어야 합니다.
    일하는 시간으로 일하는 것을 측정하는 것이 아니고 해야할 일이 명확하고 결과로 측정되며 해야할 일은 시스템에 모두 기록되고 모든 사람이 온라인으로 일하는 것을 지켜봅니다. 이런 형태의 업무가 자연스러워지려면 상당한 시간 투자와 의식의 변화가 필요합니다.

  4. Blog Icon
    jYou

    맞는 말입니다..
    다만 사무실에 나오면 열심히 일하는지 안하는지 알 수 있는 방법이 있습니다.
    바로 자리에 엉덩이 깔고 잘 있고 윗사람의 되도 않는 질문에 굽신대면 일을 잘 열심히 한다고 생각들 하죠 ㅎㅎ
    이런 좀 안좋은 문화가 바뀌고 문서화와 공유라는 문화가 정착되기 전까지는 진짜 어려울 것 같다는 생각이 듭니다.. 그런 이유의 끝에는 고용주가 고용한 사람을 그저 나의 이득을 위해 부리는 사람이라는 인식만 갖고 있지 같이 달려나간다는 공동체(?)의식 같은게 없는 상명하복의 갑질 마인드가 제일 근본이라고 생각됩니다 : )

  5. 좋은 글 잘보고 갑니다.^^

  6. 좋은 글 잘 봤습니다. 개발자 입장에서, 사실 재택근무도 근무지만, 탄력 근무제가 먼저 자리를 잡았으면 좋겠습니다. 시스템이나 프로세스의 정립이 어느 정도 이루어질 것이며 또, 시간이 아닌 TASK로 관리되는 초석이 될 수도 있다고 생각합니다. 하지만 그래도 우리나라를 봤을 때 회의적인 것은, 특히 SI/SM의 을 관계일때에는...어느 고객사가 좋아할것이며 어느 고객이 이해할것인지... 휴.

  7. Blog Icon
    csh7963

    기본적으로 재택근무에 관한 필요성은 이해합니다. 다만 회사의 관점에서 보면 재택근무는 재택근무자에 의해서 저작된 회사 자산에 관한 보안 취약성에 관한 문제가 있습니다. 이러한 부분에 대한 대안을 어떻게 생각하시는지 궁금합니다. 재택근무와 관련해서 기업 측이 가장 중요하게 생각하는 문제가 그것인데 여기에 대한 언급은 없네요.

  8. Blog Icon
    지젝

    정확히 기억은 안나지만, 김익환님의 글로벌 소프트웨어를 말하다에 보면 이런 말이 있더군요. 기본적으로 실리콘밸리는 정보 유출에 대한 법이 엄청나게 강하기 때문에, 개인이 정보유출을 할 생각을 하지도 않는다구요. 우리나라도 그런 기반 법제화가 필요할 것 같습니다.

    그리고 우리나라 소스코드는 보안에 힘 쓸 정도로..대단하지도 않다고 하는 이야기도 하시더군요 ㅋㅋ 어느정도 동감합니다.

  9. Blog Icon
    csh7963

    소스 코드가 보안에 힘쓸 정도로 대단한지...에 관한 이야기는 보안이라는 주제와는 다른 주제입니다. 이 부분은 별도로 다루는 것으로 하고... 기업의 보안 및 자산관리에 관한 시스템화 대책은 재택 근무 이전에 반드시 해결되어야 합니다.

  10. 보안은 별도의 광범위한 주제라서 간단히 얘기할 주제는 아니라고 생각합니다. 단적으로 국방부 프로젝트를 회사는 관련 자료를 집에도 가져갈 수도 없고 집에서 인터넷으로 관련 정보에 접근할 수도 없어서 재택근무를 할 수도 없고 해서도 안됩니다.

    매우 개방적인 회사도 보안은 철저해야 합니다. 소스코드야 그렇다 쳐도 회사의 전략이나 수많은 문서들은 대부분이 공개되어서는 안됩니다. 시스템적으로 VPN을 사용하거나 철저한 회사는 요즘 가상화 솔루션을 쓰기도 하지만 시스템으로 모두 해결하는 것은 불가능하고 보안 및 저작권에 대한 교육도 철저히 해야 합니다. 자칫하면 형사 사건이 되는데 그 심각성을 잘 인식시켜야 합니다.

    회사마다 필요한 보안의 수준이 달라서 획일적으로 얘기할 수는 없고 회사에 알맞게 잘 대비를 해야겠습니다.

  11. Blog Icon
    csh7963

    글세요. 일부 답변의 접근 방식은 좀 잘못된게 아닌지 싶네요. 재택근무라는 주제의 논의가 진행되는한 보안이라는 키워드는 별도의 주제가 아닌 재택근무의 전제조건이 되어야 한다고 생각합니다. 국방 분야고 어떤 분야고를 떠나서... 어떠한 기업주가 되었건, 자신이 급여를 지급해서 개발한 산출물이 직원들의 재택에 있는 개인 PC에 저장되고 있는 상황을 과연 기업주가 원할까요? 기업 보안의 수준이 어떠하든 간에 해당 기업주는 같은 요구를 할 것입니다. 회사 직원이 아닌 프리렌서라면 다른 조건의 계약을 하겠지만, 회사에 고용된 직원이 보안을 무시하면서까지 재택근무를 논한다는 것 자체가 어불 성설입니다.

SW업계에는 망치를 만드는 사람이 많다

2014.06.06 11:54 by 전규현


잠시 후 Google blogger로 이동됩니다.





누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

 

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

 

첫째, NIH(Not Invented Here)신드롬이다. 

 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

 

셋째, 우리는 다르다고 생각하는 것이다. 

 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

 

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.



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

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 CTO, NIH, 개발문화

  1. 안녕하세요~ 오랫만에 방문하게 되네요 ^^;
    확실히 개발하다 보면 학습에 대한 부담도 있어서 차라리 만들어서 쓰고 말지 라는 결정을 내리는 경우도 꽤 자주 있는것 같긴 합니다만...
    장기적으로 그 툴에 대한 유지보수나 검증 비용이 더 큰데 그걸 자꾸 잊게 되는것 같습니다.

  2. 안녕하세요. 구차니님 오랫만입니다.

    그동안 잘 계셨죠? ^^ 절대적인 기준은 없으며 직접 해보는 것도 학습이나 경험 차원에서 꼭 필요하고 도움이 많이 됩니다. 물론 직접 해봐야 남을 시킬 수도 있고, 상용 소프트웨어를 고를 때도 필요합니다. 균형을 잘 유지하는게 어렵겠죠.

실리콘밸리 개발자 눈에 비친 한국 SW회사

2014.01.22 16:44 by 전규현


잠시 후 Google blogger로 이동됩니다.





얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. 

 

B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국 개발자들과 같이 개발을 해왔다고 한다. 그 과정에서 A사에 대해서 느낀 점을 필자에게 얘기를 해줬는데 A사 뿐만 아니라 우리나라 여러 회사에 공통적으로 해당하는 내용이 있어 소개할까 한다. 

 

B씨는 일단 처음에 A사가 어떻게 돌아가는지 파악했다.  그런데 이상한 생각이 들었다고 한다. 규모가 꽤 큰 서비스인데 시스템에 버그가 너무 많고 문제가 자주 발생한 것이다.

 

직원들의 야근도 너무 잦았다. 또 스크럼을 도입해 개발한다고 하는데 제대로 효과를 보는 것 같지는 않아 보였다. 그런만큼 B씨는 A사가 스크럼이든 설계든 개발 절차에 담긴 진의를 파악하지 못하고 형식만 흉내를 내는 것이 아닌가 생각이 들었다고 한다. 

 

이에 나는 B씨에게 “설계에서 제일 중요한 것이 무엇인가?”라고 질문했다. B씨는 “설계에서 제일 중요한 것은 콤포넌트를 잘 나누는 것”이라는 당연한 얘기를 했다.

 

B씨는 계속 얘기를 했다. 설계에 UML을 사용했는데 보통 UML은 필요가 없다. 우리는 대부분 칠판에 설계를 하다가 고치기를 반복한 후 사진을 찍어서 문서에 포함한다. 툴을 이용해서 다시 그리는 것은 시간 낭비다. 마지막 버전을 툴로 그리기도 하는데 정해진 툴도 없다. UML을 이용해서 쓸모도 없는 다이어그램을 잔뜩 만든 문서는 개발에 도움이 안되고 오히려 방해가 된다. 툴을 이용하면 칠판보다 고치기가 어렵고 다이어그램을 많이 그릴수록 고치는데 시간이 많이 들어가 바로 고칠 수가 없다. 또 A사 설계는 콤포넌트가 명확히 구분되어 있지 않아서 나눠서 협업하기 어려웠고 반대로 설계 내용은 너무 상세해서 오히려 비효율적이었다. 

 

나도 동감을 했다. 개발자가 알아서 할 부분까지 설계를 할 필요는 없다. 겉보기에는 A사의 설계서가 실리콘밸리의 한 개발자가 칠판에 끄적거린 설계서보다 멋져 보이고 전문적인 것 같지만 실전에선 훨씬 비효율적이다.  

 

설계를 어떻게 해야 하는지는 소프트웨어 성격에 따라 다르지만 설계 원리와 진의를 모르고 많은 다이어그램과 상세한 설계서는 식제 개발을 할때는 별로 도움이 되지 않는다. 많은 회사들이 UML 등을 이용해 완벽한 설계서를 만들려고 하는 경우가  많은데 그런 시도가 성공적이었는지 생각해볼 필요가 있다. 

 

B씨가 A사에 대해 또 이상하게 생각한 것은 애자일(Agile)을 적용한 방식이다. 실리콘밸리 스타트업은 거의 대부분 애자일 개발 방법론을 적용하고 있다고 보면 된다. 애자일은 특별한 것이 아니다. 과거부터 해오던 방식과 비슷하다. XP를 도입한 회사도 있고 스크럼을 쓰는 회사도 있는데 회사마다 필요한 것을 활용하고 있다. B씨 회사는 XP의 페어 프로그래밍(Pair programming)과 TDD를 사용중이다. 

 

과거 프로젝트에서는SRS를 썼는데 지금은 TDD로 바꿨다. 테스트는 거의 자동화 되어 있고 별도 테스터가 없어도 시스템에 버그는 거의 없다. A사의 경우 컨설팅을 받아 애자일을 적용했는데 들어보면 별로 애자일스럽지 않아 보인다. 마케팅적으로 요구사항이 신속히 바뀔 뿐인 것 같다. 

 

시스템이 복잡하여 야근도 잦은 것 같다. 또 개발자의 자유도도 낮아 보인다. 쓸데없는 문서도 많이 만들어야 하고 테스트도 오래 걸린다. 그러다 보니 시스템에는 항상 버그가 잔뜩 있다. 

 

이상한 점은 또 있다. 비싼 툴을 너무 많이 쓴다는 것이다. 그 친구는 실리콘밸리에서 주로 스타트업 에 많이 다녔는데, 한국 회사처럼 툴을 그렇게 많이 사용하지는 않았다고 한다. 지금 다니는 회사는 서브버전(Subversion)과 트랙(Trac)만 쓰고 있는데 회사를 지금 시작했다면 Git를 선택했을 것이라고 한다. 그렇다고 굳이 지금 서브버전을 Git로 바꿀 생각은 없다. 

 

나머지 필요한 툴은 간단한 스크립트로 만들어서 쓰고 있다. 그에 비해 A사를 비롯해서 많은 한국 회사들은 일단 툴을 많이 사용한다.  비싼 툴을 사는 경우도 상당히 많다. 회사 역량에 비해서 툴을 과도하게 사용하는 것은 그렇게 효율적이지 않다. 툴은 하나를 쓰더라도 제대로 사용해야 한다. 

 

그리고 A사는 직원들에게 노트북을 지급했다고 하는데 직원들이 노트북을 집에 가져가서 일을 하지 않는 점이 이상하다. 실리콘밸리에서 스타트업에 다니는 개발자들은 거의 노트북을 집에 가져가서 장소를 구분하지 않고 일을 한다. 개발자마다 다르지만 그 친구는 늦게 출근하고 일찍 퇴근하지만 노트북을 가지고 다니면서 장소에 구애 받지 않고 하루에 10시간 이상 일을 한다고 한다. 

 

A사는 야근도 꽤 많이 하지만 집에 가서는 일을 하지 않는 것이 이상해 보였다. 한국의 모든 개발자가 그런 것은 아니지만 재택근무가 일상화된 실리콘밸리와 한국은 좀 다른 것 같다. 

 

물론 한 개인이 한 회사를 보고 느낀 점을 얘기한 것이기 때문에 우리나라의 모든 회사가 그렇다는 것은 아니다. 그렇지만 B씨와 나눈 얘기들에서 생각해 볼 요소는 많다. 국내 여러 기업이 실리콘밸리의 개발문화와 개발방식을 적용하려고 노력하고 있지만 대부분 원리와 의미는 파악하지 못하고 수박 겉핧기 식으로 형식만 흉내를 내고 있다. 

 

설계는 하지만 설계를 왜 하는지를 잘 모르고 애자일을 적용하면서 그 원리를 모르고 남들은 어떻게 하는지 보고 흉내를 내는 것이다. 원리는 같지만 회사마다 적용하는 방식이 다르기 때문에 남들을 보고 흉내 내거나 인터넷이나 책을 보고 적용하면 이런 현상이 벌어진다. 

 

단순 흉내에서 벗어나려면 무엇을 하나 하더라도 그 진의를 파악하는데 노력해야 한다. 주변에서 흔히 "남들은 어떻게 하나요?", "템플릿(Template)을 가져다 주면 해볼께요.", "샘플을 보여주세요."와 같은 얘기를 한다. 남들이 만들어 놓은 설계서 샘플을 가져다가 흉내를 내면 자칫 아니 한만 못한 경우도 많다. 샘플이 득보다는 독이 되는 경우가 많다. 

 

샘플보다는 이걸 왜 하는지 원리를 파악하려고 노력해야 한다. 스스로 진의를 파악하기 어렵다면 주변에 멘토가 될만한 사람에게 물어보고 도움을 받는 것이 좋다.


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

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발문화, 실리콘밸리

  1. 좋은내용 잘 보고 갑니다~*

  2. Blog Icon
    수유산장

    좋은 글 잘 읽었습니다 본문에 툴을 많이 쓴다고 했는데 예를 들면 어떤 툴들을 말하시는 건가요?

  3. 회사마다 적절한 툴이 다르기는 하지만 좀 과도하게 사용하거나 비싼 툴을 쓰는 회사들이 많이 있습니다. 소스코드관리시스템이나 이슈관리시스템도 과거에는 ClearCase, ClearQuest를 쓰는 회사가 꽤 있었으나 요즘은 많이 줄어 들었습니다. 그리고 요구사항관리툴, 프로젝트관리, 태스트관리 등 여러 툴을 쓰지만 그만한 역량이 안되는 경우도 많습니다. 요구사항 관리와 프로젝트 관리는 그 자체를 잘 못하는데 툴을 쓴다고 더 잘되는 것이 아닙니다. 오히려 방해가 됩니다.

개발 프로세스 관료화의 함정

2014.01.18 09:38 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다.

 

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

 

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

 

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

 

첫째, 현실성이 부족한 프로세스다. 

 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

 

둘째, 너무 상세하고 획일화된 프로세스다. 

 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

 

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

 

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

 

넷째, 벌칙만 잔뜩 담은 프로세스다.

 

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

 

다섯째, 점점 복잡해지는 프로세스다. 

 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

 

여섯째, 관료화된 프로세스다.

 

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.


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

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 관료화, 프로세스

제대로 된 코드리뷰가 힘든 이유(개발문화 시리즈10)

2013.12.29 10:13 by 전규현


잠시 후 Google blogger로 이동됩니다.







두달넘게 소프트웨어 개발문화에 관련된 칼럼을 쓰고 있다. 문화란 한쪽이 일방적으로 잘못되었다기 보다는 서로 다른 부분이 많은 것이다. 그러한 우리 문화 중 소프트웨어 개발에 불리한 부분을 짚어보고 같이 고민해보자는 의미로 칼럼을 쓰고 있다.

 

문화란 공동체의 비슷한 생각과 행동이다. 공동체에 속한 사람은 당연히 하는 행동도 다른 문화를 가진 사람들은 지식적으로는 알고 있어도 쉽게 따라하기 정말 어렵다. 개인의 습관은 개인의 의지로 고칠 수 있지만 집단의 문화는 바꾸기가 훨씬 어렵다. 

 

그래서 개발문화는 우리가 흔히 알고 있는 것도 제대로 정착시키기가 힘들다. 그중에서 대표적이고 중요한 것이 '리뷰 문화'다. 

 

소프트웨어 개발에 있어 가장 중요한 문화 중 하나인 “리뷰문화”가 제대로 정착된 회사를 우리나라에서 찾기란 그렇게 쉬운 일이 아니다. 다들 그 중요성은 알고 있지만 대부분은 시도해보고 포기하기를 반복하곤 한다. 

 

왜 그렇게 리뷰가 어려울까? 

 

가장 흔히 하는 얘기는 리뷰할 시간이 없다는 것이다. 물론 이것은 단기적으로는 오해지만 이해가 안가는 것은 아니다. 매일 일정에 쫓겨서 간신히 구현만 하기에도 허덕인다. 통계 상으로는 적절한 리뷰를 하는 것이 총 개발시간 및 비용을 절약해 준다고는 하지만 이것은 손에 잡히지 않는 이상의 세계와도 같다.

 

많은 회사들이 리뷰를 특히, 코드리뷰를 강제화하곤 하는데 그 결과 효율적인 리뷰가 되기보다는 의무적인 리뷰로 변질되면서 리뷰에 대한 나쁜 기억만 쌓이게 된다. 그러다보면 리뷰문화가 제대로 정착하지 못하고 포기하거나 강제화 덕에 비효율적이지만 명맥만 유지하게 된다. 

 

리뷰문화는 어렵다고 포기해도 될만큼 사소하지 않다. 

 

리뷰에는 여러가지 목적이 있다. 오류검출외에 공유, 교육의 목적도 있다. 품질 향상을 위해 리뷰를 하지만 리뷰를 통해서 지식 및 정보가 공유되고 노하우가 전달되며 개발자들이 서로 성장하게 된다. 지식공동체가 리뷰를 통해서 성장하게 되는 것이다. 사실 리뷰를 통하지 않고서는 개발자들의 핵심 역량이 성장하기는 어렵다.

 

리뷰가 활발하지 않다면 혼자서 책보고 인터넷보고 피아노를 배우는 것과 비슷하다. 더 많은 시행착오를 겪어야하며 느리게 성장하거나 좌절하게 된다. 자칫 우물안 개구리가 되거나 자아도취에 빠지기 쉽다. 이런 환경에서는 아마추어가 될 수는 있지만 프로가 되기는 어렵다. 

 

그럼 리뷰를 제대로 하려면 어떻게 해야 할까? 리뷰 문화가 잘 정착된 곳에서는 어떻게 리뷰를 하고 있을까? 

 

What, When, Who, How 4가 측면으로 살펴보자. 

 

What, 무엇을 리뷰하는가? 

 

'리뷰'하면 흔히 코드리뷰를 생각한다. 하지만 소스코드만 리뷰를 하는 것은 그렇게 효율적이지 못하다. 설계가 다 된 빌딩을 만들면서 벽돌 쌓는 것만 검토하는 것이다. 설계가 잘못되었다면 이미 되돌릴 수가 없다. 그리고 스펙과 설계가 공유가 안된 상태라면 소스코드를 봐도 리뷰할 것이 별로 없다. 기껏해야 코딩 규칙이나 문법 등 밖에 못본다. 

 

코드리뷰보다 더 중요한 것은 스펙과 설계 리뷰다. 스펙과 설계리뷰가 더 어려운 이유는 스펙과 설계를 제대로 작성하지 않기 때문이다. 아무리 스펙과 설계가 없어도 소스코드는 있기 때문에 코드리뷰는 항상 할 수 있다. 스펙과 설계를 제대로 작성하고 충분히 리뷰를 해야 한다. 코드리뷰 때보다 스펙과 설계 리뷰 시에 더 다양하고 중요한 것을 배우고 공유할 수 있다. 

 

When, 언제 리뷰하는가? 

 

코드리뷰를 포함해 리뷰의 실패로 이어지는 대표적인 방법은 나중에 몰아서 리뷰를 하는 것이다. 

 

피어데스크체크부터 인스펙션까지 코드리뷰의 종류도 여러가지가 있지만 별다른 전략없이 1주나 2주에 한번씩 개발자들이 모여서 지금까지 작성한 코드를 놓고 끝장 리뷰를 하곤 한다. 사전에 검토하지 않고 참석해서 내용을 파악하지도 못하고 장시간 모여 리뷰를 하게 되면 집중력이 떨어지고 형식적인 일이 되기 쉽다. 이렇게 잔뜩 개발을 해 놓고 검토를 한들 고치기도 어렵다.

 

성공적인 리뷰를 하려면 그때 그때 바로 해야 한다. 코드리뷰에서 가장 쉽게 성공할 수 있는 방법중 하나는 소스코드를 등록하기 전에 동료와 모니터를 보면서 5분~10분 정도 검토를 하는 것이다. 고칠 것이 있으면 바로 고칠 수 있다. 이것을피어데스크체크(Peer desk check)라고 하는데 가장 쉽게 적용할 수 있는 방법 중 하나다. 

 

이외에도 소스코드를 등록하고 나서 고친 내용을 이메일을 통해서 리뷰를 할 수도 있고 소스코드 리뷰시스템을 이용하면 좀더 수월하게 할 수 있다. 원격지에 있는 개발자와도 리뷰가 가능하다. 중요한 것인 코딩을 하고 즉시 리뷰를 하는 것이다. 물론 몇 시간의 시간 간격이 있지만 다시 고치기에 부담이 없는 시간이다. 

 

스펙을 작성하거나 설계를 할 때도 마찬가지다. 다 작성하고나서 한꺼번에 리뷰를 하는 것이 아니라 중간 중간 필요할 때마다 리뷰를 계속 하면서 작성해야 한다. 너무 자주는 아니지만 적절할 때 리뷰를 하는 것이 요령이다. 

 

Who, 누가 리뷰하는가? 

 

흔히 리뷰를 프로세스로 생각하고 승인을 받도록 한다. 그래서 팀장이나 고참 개발자들이 리뷰를 의무적으로 하도록 한다. 물론 내용적인 검토를 하기 위해서는 그렇게 해도 되지만 팀장이나 고참이 항상 리뷰를 할 수 없을 수도 있고 시간이 안될 수도 있다.

 

리뷰는 목적에 따라 다양한 사람들이 할 수 있다. 코드리뷰는 주로 고참개발자들이 진행하지만 개발자들끼리 서로 리뷰를 할 수도 있다. 내용에 따라서 어려운 것은 특별히 고참개발자를 지정해서 리뷰를 요청할 수도 있고 일반적인 것들은 동료와 같이 리뷰를 해도 공유의 목적을 달성하는 것이고 동료들끼리도 서로 배울 수 있는 것도 많다. 

 

스펙과 설계를 작성할 때는 각 분야의 전문가와 리뷰를 한다. 마케팅팀, 영업팀, QA팀 등과 해당 팀과 관련된 내용을 리뷰한다. 특히 설계를 할 때는 아키텍트들의 도움을 받고 특정 기술에 대해서는 해당 기술의 전문가의 리뷰를 받으면서 도움을 얻는다. 

 

따라서 리뷰자를 프로세스에 강제로 지정하면 비효율적인 리뷰가 될 수도 있다. 리뷰 내용과 목적에 따라서 적절한 사람이 리뷰를 할 수 있도록 해야 한다. 

 

How, 어떻게 리뷰하는가? 

 

리뷰는 감사(Audit)가 아니다. 리뷰를 하라고 하면 귀찮아하고 부담스러워하지만 리뷰는 누군가가 나를 도와준다고 생각하면 좋다. 또, 누군가가 나에게 리뷰를 부탁하면 나의 전문성을 가지고 누군가를 도와줘야 하는 일이므로 꼼꼼히 검토를 하고 최선을 다해야 한다.

 

고참이 될 수록 리뷰어(Reviewer)인 경우가 많다. 따라서 고참들은 리뷰를 할 수 있는 시간을 충분히 확보를 해야 한다. 이것을 일은 적게한다고 생각하면 안된다. 코딩 한줄 더 하는 것보다 리뷰를 해주는 것이 전체적으로 이익이기 때문에 그렇게 하는 것이다. 

 

리뷰를 하려면 우선 문서가 있어야 한다. 소스코드, 설계문서, 스펙문서가 있어야 한다. 바로 만나서 가볍게 하는 리뷰도 있지만 대부분은 미리 배포가 되고 검토를 한 후에 리뷰를 진행하는 것이 더 효율적이다. 또 항상 만나야 리뷰를 할 수 있는 것도 아니다. 온라인으로도 충분히 리뷰를 진행할 수 있다. 

 

가끔은 모여서 하는 리뷰가 훨씬 효율적일 때도 있다. 아키텍처 리뷰와 같은 회의가 그중 하나다. 하지만 많은 리뷰는 온라인으로도 충분히 진행할 수 있다. 

 

가끔은 체크리스트를 만들어서 리뷰를 하곤 하지만 체크리스트는 그렇게 효율적이지 못하다. 피아노를 잘 치는 방법 체크리스트 1천개가 있어도 별로 도움이 안된다. 전문가는 10초만 봐도 피아노 치는 방법을 어떻게 바꿔야 하는지 안다. 

 

대부분은 경험을 기반으로 리뷰를 하는 것이다. 자신의 경험과 전문적인 지식을 토대로 리뷰를 하고 도움을 주는 것이다. 체크리스트는 간접적인 도움이 될지는 몰라도 체크리스트를 잘 만든다고 해서 누가나 리뷰를 할 수 있도록 하게 할 수는 없다. 

 

만약에 리뷰를 잘하고 있는 회사에 개발자가 처음으로 입사를 했다면 자연스럽게 습관으로 익혔을 것이다. 그런데 그렇지 않은 회사에서 3,4년 일하다보면 리뷰를 안하는 것이 완전히 몸에 베이게 된다. 그리고 습관을 바꾸기가 정말 어렵다. 

 

세살버릇 여든간다고 하듯 개인적으로도 바꾸기 어렵지만 회사차원에서는 더욱 어렵다. 자율에 맡겨 놓으면 대부분 실패한다. 그렇다고 포기할 수는 없고 프로세스로 강제화하는 것이 시작하는 방법 중 하나다. 이미 리뷰 문화 정착에 실패한 경험이 있는 회사들은 실패의 원인을 잘 찾아야 한다. "이 산이 아닌가보다”가 반복되면 직원들의 거부감만 가득차게 된다.

 

리뷰를 강제화하되 벌칙보다는 포상으로 정착을 유도하는 것이 좋다. 제약사항을 너무 많이 만들어 놓는 것도 좋지 않다. 직원들의 적응 상태를 봐가면서 아주 천천히 한발씩 나가야 한다. 


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


image from http://davidwalsh.name/code-review

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 코드리뷰

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..