Google을 이끄는 힘

아이디어 내면 "네가 한번 만들어봐"

소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다.

Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다.

소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다.

하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경우도 있죠.

안 그래도 바쁜데 아이디어만 내며 그 책임이 나에게 돌아오고 지금 하고 있는 일에 지장을 초래할 수 있기 때문에 좋은 아이디어가 있어도 쉽사리 얘기하기도 힘들어 집니다..

그러다 보니 자연스럽게 지금 하고 있는 일이나 열심히 하지 "생각은 무슨 생각" 그냥 아무 생각 없이 일이나 하게 됩니다.

아이디어가 나오면 아이디어를 더 발전 시키는 일은 회사에서 할 일입니다.

물론 아이디어를 내놓은 사람이 아이디어를 Follow up하는 일을 맡을 수도 있지만, 이를 위한 배려는 해야 합니다. 안 그래도 바쁜데 언제 그러고 있냐고요? 그러다 보면 지금 하고 있는 업무에 지장이 있다고요? 그런 회사는 어차피 현재 일에만 치여서 미래는 준비 못하는 겁니다. 즉 R&D에 투자를 못하는 것이고 미래가 없는 것이죠.

SW 회사의 중요한 자산은 개발자의 시간이기 때문에 개발자의 시간을 사용하는 것은 중요한 투자 수단의 하나 입니다. 공짜가 아니죠.

아이디어가 나오면 일단 공론화 할 수 있는 창구가 필요합니다.

그래서 누구나 볼 수 있고 토론을 할 수 있어야 합니다. Wiki를 이용하는 것도 좋은 방법이고 주기적으로 아이디어를 발표하게 하는 것도 좋습니다. 사소한 아이디어 하나가 여러 사람의 머리를 거치면서 훨씬 더 멋진 아이디어로 발전하는 경우는 흔합니다.

아이디어를 많이 생각해 낼 수 있는 수단이 필요합니다. 간단한 포상을 해도 되고, 평가에 반영할 수도 있습니다. 또 아이디어가 실현되어서 수익을 내게 되면 그 수익의 일부를 지급하는 방법도 있습니다.

꾸준히 아이디어를 내지 않는 SW회사는 용역회사밖에 될 수 없을 겁니다. 

아이디어는 10개 나오면 그 중에 하나 쓸만하고, 그 쓸만한 아이디어 10개 수행하면 한 개 정도 성공하고 그 성공한 아이디어 10개 중에서 한 개 정도 대박이 터질까 말까 합니다.

즉, 아이디어가 1,000개는 나와야 대박이 나올까 말까 한다는 겁니다.

999개의 아이디어가 없으면 대박 아이디어 1개가 나오지 않습니다. 그래서 꾸준히 아이디어를 고민하지 않고 몇 명이 머리 맞대고 대박 아이디어 고민하는 것은 확률이 너무 낮습니다.

아이디어는 어느날 갑자기 계시를 받듯이 하늘에서 뚝 떨어지는 것이 아닙니다. 업계 동향도 꾸준히 살펴야 하고, 신기술도 열심히 익혀 놓고, 새롭고 창의적인 생각을 장려하는 기업 문화가 있지 않으면 아이디어가 생기지 않습니다. 좋은 아이디어라고 하더라도 시장의 상황과 맞지 않는 다면 별 효과를 발휘하지 못할 수도 있습니다. 이런 시기 적절하지 못한 아이디어라고 하더라도 잊혀지지 않도록 꾸준히 관리할 수 있는 도구도 필요합니다. 

아이디어를 먹고 살 수 밖에 없는 Software회사가 아이디어 발굴에 소홀히 한다면 지금은 그럭저럭 살아남을 수 있어도 지속적으로 성장하는 회사가 되기는 어려울 겁니다. 아이디어 없이 영업으로 성장한 회사의 개발자들은 참 고될 수 밖에 없습니다. 그런 회사에서 일하는 개발자를 흔히 "앵벌이"라고 하죠. 

끊임 없이 아이디어 발굴에 투자하는 기업문화가 개발자들을 더욱 즐겁게 일하고 건전하게 성장하는 소프트웨어 회사를 만들어 줍니다.

CEO 가장 자주 하는 거짓말은 뭘까?

CEO 가장 자주 하는 거짓말 '회사 여러분 것' 직장인들이 뽑은 최고경영자(CEO)의 가장 흔한 거짓말은 ‘이 회사는 여러분의 것’이라는 조사결과가 나왔다. 취업포털 스카우트는 최근 직장인 1천26명을 대상으로 설문 조사한 결과 CEO들이 가장 자주 하는 거짓말은 ‘이 회사 다 여러분들 것입니다’가 25.2%(216명)로 가장 많았다고 27일 밝혔다. 이어 ‘내년 한 해만 더 고생하자’(21.1%), ‘연봉 못 올려줘서 늘 미안해’(13.9%), ‘우리 회사는 미래가 있다, 다른 생각하지 말게’(12.3%), ‘사람 하나 더 뽑아줘야 하는데’(8.9%) 등이 있었다. 후략... Copyrights ⓒ 연합뉴스. (출처:조선일보)

흥미 있는 기사가 있어서 소개도 하고 의견을 좀 올려볼려고 합니다.

아직도 "회사는 여러분 것"이라는 거짓말을 믿고 있는 분들은 없으시겠죠? 회사의 주인이 되려면 CEO의 말만 믿지 말고 "주식"을 사세요. 비록 소액 주주이지만, 주인이 될 수 있습니다.

그럼 회사와 나의 관계는 무엇일까요? 

"주종의 관계"일까요?

먼저 회사의 목적과 나의 목적의 차이를 알아야 합니다.

회사의 목적은 "돈"을 버는 것이고 그 목적에 가장 충실한 사람이 CEO입니다. 충실한 정도가 아니고 그 목적을 달성하지 못하고 파리 목숨이죠. 물론 Owner라면 다르겠지만요.

회사가 "돈"을 많이 버는 방법은 "매출"을 많이 올리고, "비용"을 줄이는 겁니다. 위에서 CEO들이 즐겨하는 거짓말들은 다 이 목적을 이루기 위해서 하는 것들입니다. 직원들이 좀더 열심히 일하게 만들면서 인건비는 최대한 줄여야 합니다.

그럼 내가 회사를 다니는 목적은 무엇일까요?

"돈", "사회적기여", "자아성취", "경력개발" ???

여기서는 정답이 없는 것 같네요. "돈"이 가장 중요하다고 생각하는 사람도 많지만, 회사를 다니는 목적의 비중은 서로 다 다릅니다.

하지만, 중요한 것은 내가 회사를 다닌 기록은 사라지지 않는 다는 것입니다.

내가 다녔던 회사가 지금 훨씬 잘 나간 다면 나에 대한 평가도 후해집니다. 하지만, 내가 몸담았던 회사가 처참하게 망해 사라졌다면 나 또한 그 책임에서 자유롭지 못하고 취업 인터뷰 시 죄인을 바라보는 듯한 시선을 받을 수도 있습니다.

즉, 나와 회사는 회사를 다닐 때나 그만둔 후에나 모두 "상생의 관계"일 수 밖에 없습니다.

또한, 다른 직업도 마찬가지 일 수 있지만, 소프트웨어 개발자라면 더욱더 회사가 자신의 몸값을 높이는 중요한 역할을 합니다. 소프트웨어 개발자는 학교에서보다 회사를 다니면서 익히고 배우는 것이 훨씬 많습니다. 똑같은 학교를 졸업해서 주먹구구식으로 개발하는 우리나라 소프트웨어 회사에서 10년 일한 개발자와 Google에서 10년 일한 개발자는 간판만 다른 것이 아니라, 경험한 내용과 실력에서도 엄청난 차이를 보입니다. 그래서 월급이 적더라도 더 많은 것을 배울 수 있고, 미래의 자신의 몸값을 높일 수 있는 회사라면 주저하지 않고 선택할 수 있겠죠. 

즉, 개발자가 회사를 다니는 중요한 목적 중의 하나는 자신의 실력을 만들어나가는 겁니다. 이런 마인드를 가지고 있으면 회사 생활이 달라집니다.

맨날 코딩에 매달리면서 자신의 업무만 처리하는데 열심히 개발자의 10년 후 미래는 그리 밝지 않습니다.

몸값이 높은 개발자는

"비즈니스 마인드가 있어야 합니다."

"가치가 낮은 코딩에만 매달리기 보다는 가치가 더 높은 분석/설계 업무에 더 치중해야 합니다."

"창의적인 생각을 해야합니다."

"넓은 View를 가지고 있어야 합니다."

"커뮤니케이션 능력이 뛰어나야 합니다."

또한, "코딩도 잘해야 합니다."

이렇게 변화를 하려면 문서를 잘 작성하기 위해서 노력을 해야 하고, 넓은 View를 가지기 위해서 자신의 프로젝트 뿐만 아니라 수많은 타 팀의 프로젝트의 리뷰에도 참석하여 기여도 하고 많은 것을 배워야 합니다.

또한 "코딩" 뿐만 아니라 소프트웨어 개발 전반의 지식 영역을 고루 공부하고 경험해야 합니다.

업계 동향과 새로운 기술에 뒤쳐지지 않기 위해서 끊임 없이 공부해야 합니다. 

이러한 자세는 회사의 목적인 "돈"을 버는 것과 어긋나지 않습니다.

개발자들의 이러한 자세가 "회사"와 "개발자" 모두가 성공하는 "상생"의 길입니다.

하지만, 이를 절대 용납하지 않는 환경의 회사를 다니고 있다면, 회사를 왜 다니는지 한번 생각해 봐야 합니다. "돈"을 많이 주는지? 나의 "경력"을 장식해 주는지? 많은 것을 배우게 해주는지?

이도 저도 아니라면 이직을 차근차근 준비해야 할 때가 아닐까요?

내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ...

재미 있는 유머입니다.

My Boss & I

직장 상사와 나
When I take a
long time, I am slow.
When my boss taking a long time, he is thorough.

내가 일을 오래 끌면 일 처리 속도가 느린 것이고,
나의 상사가 일을 오래 끌면 일을 철저히
하는 것이다.

When I don't do it, I am lazy.
When my boss doesn't do it, he is too
busy.

내가 그 일을 하지 않으면 게으른 것이고,
나의 상사가 그 일을 하지 않으면 너무 바쁜
것이다.

When I do something without being told, I am trying to be smart.   

When my boss does the same, that is initiative.  

내가 시키지 않은 일을 하면 잘난척하는 것이고,
나의 상사가 시키지 않은 일을 하면
솔선수범하는 것이다.

When I please my boss, I am apple-polishing. 
When my boss pleases his
boss, he's co-operating.  

내가 상사를 기쁘게 하면 아첨하는 것이고,
나의 상사가 자신의 상사를 기쁘게 하면 협력을
잘하는 것이다.

When I do well, my boss never remembers.  
When I do wrong, he never
forgets.  

내가 잘한 일은 상사가 절대 기억하지 못하고,
내가 잘못한 일은 상사가 절대 잊지
않는다.

출처:이찬승영어등대

SW개발과 Teamwork, 그리고 Review

거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 

그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.

하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.

이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.

팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.

Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처

에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.

물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야

하는 것들은 어떤 것이 있는지 알아보겠습니다.

1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)

제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝

날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다. 

2. SW아키텍처 리뷰 (중요도 : 높음)

웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍

처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.

3. 소스코드 리뷰 (중요도 : 중간)

소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.

소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.

우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다. 

좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.

개발자 부품화 vs. 만능 개발자

개발 프로세스를 너무 따지만 개발자가 부품화 되고 창의성이 줄어든다고 합니다.

또 분석, 설계, 구현, 테스트를 나눠서 하게 되면 부품화되고 비인간적이라고 하기도 합니다.

그래서 개발자가 이것 저것 다하는 만능의 역할을 수행하게 합니다.

투수는 공만 던지고, 골키퍼는 골만 막는 것은 부품화일까요?

이렇게 전문화되지 않고 모두 만능으로 잘하는 동네 축구를 해서 어떻게 세계적인 소프트웨어와 경쟁할 수 있을까? 잘 하고 싶어도 동네축구를 계속 하는 이유는 제대로 된 방법을 경험해 본적이 없어서 그렇습니다. 개발자가 한명인 회사나 개발자가 50명인 회사가 개발하는 방법은 크게 다르지 않습니다. 개발자가 개발 전반의 모든 일을 다 알아서 하고 프로젝트는 개발자의 역량과 의지에 달려있습니다. 

동네 축구를 벗어나기 위해서는 소프트웨어를 개발하는 전체 프로세스를 이해해야 합니다. 이에 따라서 프로세스를 체계화 하고 각 역할별 전문화된 조직을 갖춰나가고 설령 인원이 매우 적어서 한명의 개발자가 여러가지 일을 수행하더라도 업무의 구분이 필요합니다. 나중에 조직이 커지면 일을 떼어 줄 수 있어야 합니다.

만능 개발자는 자칫하면 정작 개발자로서의 가치 있는 성장에 지장을 초래할 수 있습니다. 

우리는 다르다.

"우리는 다르다"

"우리는 너무 바빠서 문서를 쓸 시간이 없다."

"우리는 고객이 요구사항을 너무 자주 바꿔서 스펙을 작성할 필요가 없다."

"우리가 개발하는 시스템의 업무는 너무 복잡해서 문서로 만들 수도 없고 개발자도 몇 년 일해야 제대로 일할 수 있다."

"우리 고객은 문제가 생기면 당장 고쳐주지 않으면 큰일 난다."

"우리의 기술은 너무 어려워서 설명할 수가 없다."

"우리 소스코드는 너무 중요해서 아무에게도 보여 줄 수 없다."

"우리 제품의 시장은 너무 경쟁이 치열해서 고객이 원하는 것은 다 들어 줘야 한다."

"우리 프로젝트는 항상 너무 촉박해서 제대로 된 프로세스를 밟을 수 없다."

"우리는 도저히 리뷰할 시간이 없다."

"우리는 프로젝트 기간이 항상 너무 짧아서 테스트는 대충하고 출시해야 한다."

"우리 시스템은 너무 복잡해서 설계자가 구현까지 하지 않을 수 없다."

"우리 시스템은 너무 복잡해서 개발자가 테스트를 해야 한다."

다들 가장 까다로운 고객을 가지고 있고, 너무 어려운 기술이고, 업무도 너무 복잡하고, 항상 시간이 없다라고 말합니다. 

이 얘기는 거의 모든 SW회사들에게서 듣는 별로 특별할 것도 없는 얘기들입니다.

결국 SW 회사들의 근본은 별반 다를 것이 없습니다. 소프트웨어를 제대로 개발하기 위해서 거쳐야 할 프로세스, 문서 작성, 리뷰 등은 크게 차이가 없습니다. Detail한 부분은 서로 다를 수 있지만, 기본 원리는 같습니다. 하지만 자신의 회사는 대단한 도전을 하는 것과 같은 착각을 하고 있는 경우가 너무나 많습니다. 오히려 제대로 하고 있지 못하고 있기 때문에 환경이 더욱 열악하게 느껴지는 것을 알고 있지 못하는 경우가 더 많습니다.

세상에 시간이 너무 넉넉한 SW프로젝트는 거의 없습니다. 

세상에 마음 착하게 문제 해결을 개발회사가 원하는 만큼 넉넉하게 기다려 주는 고객은 거의 없습니다.

대부분의 회사가 다루고 있는 기술은 크게 특출 날 것도 어려운 것도 별로 없습니다. 대단히 소수의 SW회사들만 그런 어려운 기술을 다루고 있습니다.

결국 현재의 문제를 자신의 부족함에서 찾지 않고 환경의 열악함으로 돌리는 것은 나아질 수 있는 기회를 잃어버리는 결과를 초래할 수도 있습니다.

정말 열심히 일하고 있는데, 개발은 점점 복잡해지고, 야근은 점점 늘어가고, 고객의 요구는 점점 까다로워 진다면 내부를 돌아봐야 합니다. 회사가 제대로 SW를 개발하고 있는 것인지 심각하게 고민해 봐야 합니다.

거짓말쟁이 개발자

의도적이던, 의도적이지 않던 간에 개발자의 거짓말은 개발자 스스로의 신뢰를 떨어뜨릴 뿐만 아니라 회사의 중요한 결정을 잘못된 방향으로 이끌기도 합니다.

거짓말쟁이 개발자들은 거짓말을 하면서도 본인이 거짓말을 하고 있다는 것을 자각하지 못하거나 온갖 합리화를 할 수 있는 핑계로 무장을 하여 진실을 말하고 있는 자기 최면에 빠지기 도합니다.

사람들은 계속 속아주지는 않습니다. 결국 신뢰도 떨어지는 개발자가 될 수 있습니다.

모르는데 아는 것처럼 말하는 것

이름 한번 들어본 기술 또는 샘플 코드 한번 돌려본 것 가지고 아는 척하는 경우를 흔히 볼 수 있습니다. 이때는 자신이 어느 정도 아는지 정확하게 밝혀야 합니다. "들어는 봤다", "프로젝트에 적용해 봤다", "남을 가르칠 수 있다"

중요한 의사 결정에 있어서 자신이 잘 아는 기술을 유리하게 주장하는 경우

자신이 잘 아는 기술을 계속 고집하여 자신의 지식이 계속 유용하게 하려는 주장은 흔히 들을 수 있습니다. 이로 인해서 회사가 잘못된 결정을 내리면 자칫 회사의 존폐가 위태로울 수도 있습니다. 또한 이런 개발자들은 다양한 기술을 접할 기회가 줄어들어서 결국 자신의 몸값을 낮추게 됩니다.

자신의 파워를 유지하기 위하여 그릇된 정보를 사실인 것처럼 말하는 경우

회사를 다니는 직원이라면 자신의 힘을 유지하고 키우는 것이 중요하지 않을 수는 없습니다. 하지만 이를 위하여 거짓된 정보로 잘못된 결정을 유도한다면 결국 자신의 도끼로 자신의 발등을 찍는 일이 될 수도 있습니다.

사실, 의견, 정보를 혼동하는 경우

가장 흔한 거짓말입니다. 말을 하면서도 이것이 자신의 의견인지? 공식화된 사실인지? 누구의 의견인지? 정확하게 밝히지 않는 것입니다. 이 이야기를 듣고 결정을 하는 사람들은 의견을 사실로 오해해서 중요한 의사 결정을 할 수도 있습니다. 그런 다음에 "누가 그렇게 얘기했다"라고 변명하는 것은 통하지 않습니다.

자신의 성과를 과대 포장하는 경우

자신이 개발한 SW를 마치 대단한 성과물인양 광고를 하고 심지어는 Open source를 가져다가 뚝딱뚝딱 만든 것을 자신의 창작물인 것처럼 속이는 경우도 많습니다. 자신을 전혀 홍보하지 못하는 것도 문제지만, 이렇게 너무 과대 포장하는 것은 자칫 회사도 과대 포장이 되고 결국 다른 개발자들의 시기의 대상이 되기도 합니다.

자신의 실력을 과대평가하여 불가능한 일을 할 수 있는 일처럼 말하는 경우

개발자는 자신의 실력의 한계를 잘 알아야 합니다. 자신의 실력을 뛰어넘는 일이라면 사실대로 밝혀서 회사의 지원을 받아야지, 거짓말로 일에 뛰어 들어서 프로젝트를 크게 망친다면 누구를 탓할 수는 없습니다. 이 거짓말은 마치 거짓말이 아닌 것처럼 생각되기도 하지만, 아주 흔한 거짓말 중 하나이며, 자신이 자신을 몰랐다는 핑계는 진짜 핑계일 뿐입니다.

결국 이런 거짓말들을 일삼는 개발자들은 거짓말이 또 거짓말을 낳게 되고, 적당한 핑계에 익숙해 지게 됩니다. 결국 제살을 깎아먹는 일이 됩니다. 또, 이런 개발자들이 더 대우받고 활개 치는 회사라면 같이 일하는 개발자들은 참 피곤한 노릇이 아닐 수 없습니다.

자칫하면 이런 개발자들의 많은 거짓말들이 거짓말이 아닌 것처럼 묻혀버리는데, 항상 커뮤니케이션을 할 때는 모든 것을 확실히 하여 특히 위 예와 같은 것들은 단단히 확인을 받아서 거짓말에 대한 책임을 지게 해야 항상 더 올바른 정보로 정확한 커뮤니케이션이 일상화 됩니다.