2014년 7월 17일 목요일

개발 경쟁력과 실속없는 화려한 보고서

몇 년 전 A사에서 있었던 일이다. 

A사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다.  경영진이 보고서를 매우 까다롭게 보기 때문에 보고서의 품질이 완벽해야 하기 때문이라고 한다. 나는 그럴 수 있다고 생각했다. 

하지만 남은 1주일 동안 진행되는 일은 매우 실망스러웠다. 경영진이 까다롭게 보는 보고서의 품질은 보고의 내용이 아니었다. 문서의 외형적인 모습이었던 것이다. 물론 내용도 중요하게 보겠지만 직원들이 특히 신경을 썼던 부분은 문서의 형식이었다. 

일단 보고서가 화려해야 하고 폰트, 정렬, 이미지, 도표 등 한눈에 딱 봐도 멋지게 보이지 않으면 안된다는 것이었다. 이런 모습을 보면서 문서의 외형적인 품질을 높이기 위해서 여러 명의 고급 인력이 허비하는 1주일이 참 아깝다는 생각이 들었다. 잠깐 동안 경영진의 눈을 만족 시키기 위해서 지불하는 비용 치고는 참 비싸다고 생각했다. 어쨌든 A사는 느린 전략 결정과 시대 흐름에 뒤쳐져서 현재 어려운 길을 걷고 있다. 

이에 비해서 내가 만난 G사는 사뭇 다른 문화를 가지고 있다. 

G사는 보고서를 작성하기 위해서 시간을 허비하는 것이 용납되지 않는다. 여기서는 좋은게 좋은게 아니다. 내부 보고 문건이 너무 화려하고 깔끔하게 작성되면 여지없이 질책이 쏟아진다. 간단한 보고를 파워포인트로 만드는 것도 용납이 되지 않는다. 대부분은 이메일 본문에 보고 내용을 간단 명료하게 작성하고 이메일로 검토 및 승인도 받는다. 

전화로 승인을 받기도 한다. 파일을 만들어도 텍스트 파일이나 워드로 핵심만 적어서 간단하게 만든다. 종이나 칠판에 작성한 내용을 사진찍어서 보고를 하기도 한다. 회의시간에 칠판에 그린 그림을 다시 문서로 만드는데 드는 시간을 아까워하는 것이다. 가끔 신입사원이 이런 문화를 모르고 예쁜 문서를 만들기도 하지만 여지없이 질책을 당하기 때문에 금방 적응한다. 

물론 외부로 나가는 문서는 형식도 신경을 쓰지만 내부 문서는 내용에 충실하고 외형을 꾸미는데는 10원도 투자를 하지 않는다. G사는 빠르고 능동적인 결정이 장점이며 시장 점유율을 점점 확대해 나가고 있다. 

나는 소프트웨어 개발 시 스펙을 작성할 때 화려한 문서는 지향하지 않는다. 대부분은 MS-워드로 작성하지만 간단한 프로젝트는 노트패드로 작성한다. 요즘은 간단한 스펙은 에버노트로 바로 작성해서 동료와 공유하기도 한다. 

MS-워드로 작성할 때도 칠판에 그린 다이어그램을 사진 찍어서 첨부하기도 한다. 특별한 규칙이 있는 것은 아니고 가장 효율적으로 작성할 수 있는 방법을 찾아서 시간을 최대한 절약하려고 한다. 규칙은 단순하다. “어떻게 하면 작성된 스펙을 가지고 개발자들이 구현을 할 수 있는가”만 생각하면 된다. 

반면 S사는 스펙, 설계의 규칙이 매우 엄격하다. 템플릿(Template)도 다양하고 UML의 여러 다이어그램을 모두 작성해야 한다. 그 이유는 UML의 표준 표기법을 잘 지켜야 서로 의사 소통이 정확하게 된다는 믿음을 가지고 있기 때문이다. 이러다보니 굳이 개발하는데 불필요한 문서와 다이어그램도 작성해야 하고 비효율적인 방법인지 뻔히 아닌 문서도 형식에 맞춰서 적어야 한다. 그렇게 해도 S사에서도 소프트웨어가 잘 개발되는 것은 아니다. 지금도 문제는 매우 많고 그럴 수록 더 많은 문서와 엄격한 규칙이 추가되곤 한다. 

많은 회사들이 비단 화려한 문서만 추구하는 것이 아니다. 화려한 시스템과 툴에도 많이 현혹된다. 유독 우리나라에서 비싸고 화려한 툴이 잘 팔리는 것을 보면 화려한 문서와 보고서를 요구하는 문화와 관계가 있을 것이다. 

소프트웨어를 가장 효율적으로 잘 개발하려면 실용주의를 추구해야 한다. 겉치레는 버리고 내용에 충실해야 한다. 경영자들이 보고서 내용보다 먼저 형식을 보고 지적한다면 직원들에게 겉치레를 중요시하라는 신호를 보내는 것이다. 

우리나라에서는 담당자들이 여러 경영진을 앉혀 놓고 브리핑하듯이 보고를 하는 모습을 종종 본다. 이런 권위적인 보고 자리에서는 당연히 경영자들이 듣고 싶어하는 얘기로 채워지고 내용도 예쁘게 포장이 된다. 보고를 한 이상 보고를 받은 사람도 결과에 대해서 책임을 지는 것이 당연하지만 이런 보고 자리에서는 결과에 대해서 보고자가 책임을 져야 한다. 

이런 틀에 박힌 보고 방법은 탈피해야 한다. 이런 보고서를 만드느라고 시간 낭비를 해서는 안된다. 이런 브리핑은 보고서를 따로 작성하지 않아도 시스템을 통해서 경영자가 직접 확인할 수 있어야 한다. 게으른 경영자를 위한 브리핑을 제외하고 나면 보고의 자리는 대폭 줄어든다. 

효율적인 보고는 진짜 중요한 내용을 경영진 또는 의사결정자에게 직접 빠르게 얘기하고 결정해야 한다. 내용은 메일이나 시스템으로 먼저 공유하고 얼굴을 보고는 핵심을 빠르게 전달하고 의논하면 된다. 굳이 회의실도 필요 없다. 정보는 이미 공유를 했으므로 최종 의논은 걸어가면서 할 수도 있고 전화로도 가능하다. 시간과 장소는 구애 받지 않는다. 

직원들은 어차피 경영진이 요구하는 보고 방식을 따를 수 밖에 없다. 매 보고 시마다 의자에 앉아서 직원들의 브리핑을 듣고 싶으면 직원들은 몇 배의 시간 낭비를 하고 있다는 것을 기억하자. 직원들이 어떻게 일했고 일하고 있는지 궁금한 것은 시스템을 통해서 모니터링을 해야 하며 직원들과는 진짜 중요한 얘기를 하자.

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

댓글 3개:

  1. 좋은 글 잘 읽었습니다.

    전부 맞는 말씀이고 모두 공감합니다만, 말씀하신 C사가 제가 아는 회사라면 약간의 오해가 있으셨던 것이 아닌가 합니다.

    보고서의 품질을 따졌던 것은 맞습니다만, 그 품질이라는 것이 말씀하신 문서의 외향적인 부분이 아니었습니다.
    당시 C사의 직원들이 보고서에서 중요하게 생각했던 것은 문서의 논리와 그 논리의 전개 과정이었습니다.
    문서의 형식도 따지긴 했습니다만, 그 '형식'이라는 것이 외향을 의미하기 보다는 '문서 구조에 대한 형식'이라고 보아 주셨으면 좋겠습니다. 예를 들어, '결론을 어느 시점에 강조할 것인가?', '이런 이런 내용은 중복이 아닌가?', '어떤 결론에 이르기 위해 사례의 디테일을 어느 정도로 가져갈 것인가" 등등이었습니다.
    즉, 당시 저희는 '어떻게 하면 잘 완성된 보고서를 만들까'를 고민했지, '어떻게 하면 화려하고 거창한 보고서를 만들까'를 고민하지는 않았습니다. 아마 전수석님께서도 그 사실은 충분히 알고 계셨다고 믿고 있습니다. (사실 당시에 완성되었던 보고서는 C사에서 경영진에게 보고하는 보고서 중에 외향적으로는 가장 볼품(?) 없던 문서였습니다)

    컬럼에서 전달하시고자 하는 내용의 극적인 효과를 높이기 위해 약간의 과장을 포함시키셨을 수도 있겠다는 생각은 듭니다만, 좋은 결과를 만들기 위해 몇 달 동안 ABC Tech와 함께 논의하고 같이 고생했던 C사 직원의 입장에서는 어느 정도의 당혹감이 드는 것은 사실입니다.

    어찌되었건, 저희가 그 정도로 실망스럽게 해 드렸다는 사실은 죄송합니다. 당시에 말씀해 주셨으면 좋은 교훈이 되었을 텐데요...

    앞으로도 좋은 컬럼 많이 부탁 드리겠습니다.
    감사합니다.

    답글삭제
  2. 안녕하세요. 정확하게 누구신지는 모르겠지만, 아마 다른 회사인 것 같습니다. 내용을 읽어보니 누구신지 대충 짐작이 갑니다. 확실치는 않지만 S사이신것 같은데 구체적인 내용은 좀 다를 겁니다.

    다른 블로그 글에도 종종 "우리회사 얘기 아냐?"라고 하시는 분들이 많습니다. 심지어는 한번도 본적도 없는 회사에서 그런 메일이 오기도 합니다. 오해를 하셨다면 다른 회사 얘기니 궤념치 마시기 바랍니다.

    사실 내용에서 중요하고 저도 설명하고자 한 회사는 "G"사입니다.

    앞으로도 도움이 되는 글을 쓰도록 노력하겠습니다.

    답글삭제
  3. 굳이 회사명을 영문 이니셜을 맞춰서 쓰려다 보면 종종 오해가 있을 수 있겠죠. 예시를 들 때, 그냥 A사/B사/C사라고 하면 어떨지요? 상당 수의 오해가 방지되지 않을런지요?

    보고서를 볼 때, 어디까지가 내용이고 어디까지가 외형인지 대부분은 구분이 가지만, 약간은 애매한 부분도 있습니다. 이 부분을 보는 시각의 차이때문에 이같은 글을 보고 나서 오해가 생길 수도 있지요.

    개발자들에게 보기 편하다고 모든 사람들이 편하게 생각하는 것은 아니니 이러한 작업은 특히 조직 전체의 합의로 규정되고 공유되는 것이 맞습니다. 너무 개발자들의 관점에서만 일방적으로 정하는 것도 문제입니다. 보고서는 개발자들만 보는게 아니므로 조직적 합의가 더 중요합니다.

    행여 보고서 자체의 관리에 필요한 메타 정보들(기록일시, 보고자, 보고장소... 등)을 일컬어서 외형이라고 표현한 것은 아닌지 모르겠네요. 보고서가 조직 내에서 어떻게 활용되고 어떻게 쓰여지느냐에 따라서 필요한 정보는 늘어날 수도 있다고 저는 생각합니다.

    또한 조직이 커지는 경우도 보고서가 많아질 수 밖에 없습니다. 그러나 이는 보고서 분량의 문제가 아니라 조직이 비대해지는 그 자체가 문제인 경우도 있으니, 이를 혼동해서도 안될 듯. 이는 조직의 구조적 문제 관점의 해결이 필요한 것이니 그것이 해결되면 자동으로 보고서 문제도 해결되겠지요.

    조직 내 의사소통 및 공유의 필요성때문에 보고에 있어서 어느 정도의 형식은 필요합니다. (예: 6하 원칙...) 단순히... 사진을 찍어서 업로드하고 끝 -> 이런 보고에서 그 어떠한 문제도 발견할 수 없을까요? 경우에 따라서는 문제가 될 수도 있습니다. 지나치게 편의주의적 발상을 효율이라고 착각하면, 안됩니다.

    문서란 것은 어느 정도는 공식성을 띨 수도 있습니다. 그런 조직 내의 요구를 모두 천편일률적으로 무시할 수는 없습니다. 현장에서의 사안마다 다른 판단을 할 수 있는 문제이니 조심스레 언급할 내용입니다.

    답글삭제