태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

2014/07/17 23:11 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


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

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

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/350 관련글 쓰기
  1. Blog Icon
    C사 직원

    좋은 글 잘 읽었습니다.

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

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

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

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

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

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

몇 년 전 C사에서 있었던 일이다. C사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다. 경영진이 보고서를 매우 까..

한국에는 가짜 CTO가 많다

소프트웨어 회사에서 가장 중요한 한 사람을 꼽으라고 하면 단연 CTO다. 회사 전체 기술의 총 책임자이며 기술 비전과 로드맵을 이끄는 핵심이다. 회사 비즈니스 전략을 기술에 녹여내는 중추 역할을 한다. 회사 기술을 속속들이..

SW개발, 착한 리더보다 독한 리더가 낫다

몇년전 A사에서 이슈관리 시스템 도입에 대해서 경영자와 의논한 적이 있다. A사는 이슈관리시스템을 사용하고 있지 않았고 버그만 엑셀 파일로 관리하고 있었다. 이슈관리시스템이 꼭 필요한 상황이었고 당장이라도 도입해야 했었다...

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

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

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

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서..

평등한 토론이 SW혁신 만든다

소프트웨어에서 창의적인 혁신은 천재 한 사람의 머리에서 나오는 것이 아니다. 여러 직원들의 격 없는 평등한 토론에서 탄생하는 것이다. 이런 토론 문화 없이 혁신적인 소프트웨어가 탄생하기는 어렵다. 이는 비단 소프트웨어만의 문..

할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 대부분의 개발..

똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계..

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다...

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발..