문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 

어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서 발전해 온 것이기 때문에 교수가 실전적으로 잘 아는 분야는 아니다. 교수는 이론적으로는 잘 알고 있지만 실전은 상대적으로 약하기 때문이다. 특히 우리나라에서 쌓은 실전은 더욱 약할 수 있다. 또한 국내 개발자들을 데리고 일한다는 가정을 하고 얘기를 하는 것이라면 더욱도 그렇다.

물론 문서를 작성하면서 개발을 해야 한다고 생각한다. 그래야 제대로 개발을 할 수 있다.

하지만 문서를 작성하면서 개발을 하면 개발 기간이 거의 2배로 들어간다고 한다.

우리는 시간이 촉박하므로 문서를 작성하지 않고 개발해야 한다고 한다.

이 생각은 국내 회사의 대부분의 개발자와 경영자가 생각하고 있는 바와 크게 다르지 않다.

일부분은 맞는 측면이 있다.

문서를 어떻게 작성해야 하는지 잘 모르는 개발자를 데리고 개발을 하면서 문서까지 잘 작성해달라고 하면 시간이 훨씬 더 걸리는 것이 당연하다.

그럼 소프트웨어를 개발하면서 문서를 작성하는 이유는 무엇일까?

바로 소프트웨어를 더 빨리 개발하기 위한 것이다. 

이말을 진정으로 이해하고 있는 개발자를 만나는 것은 쉬운 일이 안다. 

그런데 왜 이렇게 다들 다르게 생각하고 있는 것일까? 

첫째, 앞에서 언급했다시피 역량 문제가 있다. 역량이 떨어지면 문서를 잘 적지도 못하고, 문서에 무슨 내용을 적어야 하는지도 모른다.

둘째, 국내 교수, 경영자, 개발자 모두 문서를 작성한다고 하면 세계적인 유명한 방법론을 기준으로 생각하는 경향이 있다.

세계적인 방법론은 수십가지가 있고, 대부분은 수십가지의 문서를 만들어야 한다. 하지만 대부분의 실리콘밸리의 SW회사들은 이런 방법론을 따르지 않는다. 회사의 규모, 성격에 따라서 매우 다르다. 국방부 프로젝트 또는 대규모 프로젝트를 주로 하는 회사는 상당히 많은 문서를 만들지만 그렇지 않은 회사들은 꼭 필요한 문서 몇가지만 만는다.

셋째, 우리나라에서는 문서를 나중에 만드는 문제가 있다. 문서는 개발을 빨리하기 위해서 만드는 것인데 다 개발해 놓고 문서를 만들면 시간만 추가로 들어갈뿐만 아니라 문서의 내용도 충실히 작성할 수가 없다. 이렇게 작성한 문서는 나중에 효용성도 떨어진다. 문서는 다음단계를 진행하기 위해서 앞서서 만드는 것이다.

넷째, 문서를 얼마나 자세히 적어야 하는지 잘 모르고 있다. 대부분 문서를 너무 상세히 적어야 하는 것으로 생각하고, 처음에는 의욕적으로 적기 시작하는데 점점 지쳐가고 나중에는 업데이트도 잘 안된다. 문서는 상황에 맞게 최소화 해서 만들어야 한다. 그래야 중복이 줄어들고 낭비가 줄어든다.

문제점을 정리하면 다음과 같다.

• 개발자 역량의 차이
• 수십개의 문서를 만들어야 하는 것으로 착각
• 문서를 나중에 추가로 만든다.
• 문서를 너무 자세히 적으려고 한다. 

소프트웨어를 개발하면서 문서를 제대로 작성하는 이유는 개발을 빨리 하기 위해서이다. 

• 문서는 필요한 만큼만 최소한으로 작성을 하고 
• 문서를 작성해야 리뷰를 할 수 있고, 
• 일을 효율적으로 나눠서 할 수 있고,
• 각 부서가 문서를 가지고 병행해서 전문적인 업무들을 진행할 수 있다.

역량이 떨어지고 인식이 안바뀌어서 계속 주먹구구식 개발에 머문다면 경험이 쌓이지도 않는다. 당장은 역량이 떨어져도 스펙을 제대로 작성하고 설계를 작성하고 리뷰하는 경험을 꾸준히 쌓아야 한다. 그래야 문서를 작성하는 것이 진짜로 소프트웨어를 빨리 개발하는 것을 경험하게 될 것이다. 

그리고 이렇게 빨리 소프트웨어를 개발하는 것을 경험해본 사람들은 다시 옛날로 돌아가지 않는다.

"문서를 작성해보자"라고 생각을 굳혔으면 "스펙"(SRS) 문서를 먼저 작성해보라고 권한다. 스펙문서만 제대로 작성해도 80%는 해결 된 것이다. 그리고 역량이 좀더 늘면 다른 문서들을 하나씩 작성해보기 바란다.

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다.

복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다.

기초적인 것이 해결이 안된 상태에서 너무 어려운 것을 적용할 수 없다.

기초적인 것들이 여러가지가 있지만 회사의 이슈들을 한군데로 모으는 것만도 정말 어렵다.

이슈(버그)관리시스템을 사용하는 회사는 많지만 이슈관리시스템에 회사의 모든 이슈를 다 모아서 개발자는 오로지 이슈관리시스템만 보고 개발을 할 수 있는 회사는 드물다.

이슈관리시스템을 통하지 않고 전화, Email, 메신저를 통해서 여전히 개발 요청을 하는 경우가 많다.

어려운 시도를 하기보다는 먼저 이슈관리시스템에 모든 이슈를 모으는 일을 먼저 해보기를 권한다. 이것만 해도 회사에 제대로 정착되는데 1년이 넘게 걸리곤 한다. 그것도 잘 되었을 경우이다.

 버그, 개발요청, 업무요청, 협업관련정보 등 개발 이슈는 무조건 다 모아야 하고, 그외에 업무 이슈들도 모으면 좋다.

개발자는 하나의 시스템에서 모든 개발 요청을 다 볼 수 있고 관리할 수 있어야 한다.

전화, Email을 통한 요청을 일부라도 허용하는 예외를 둬서는 안된다. 예외는 전체 문화를 망가뜨릴 것이다.

시스템은 많아질수록 개발자가 귀찮아지고 비효율적으로 변한다.

경영자가 관리가 잘 안된다고 생각하고 자꾸 관리하는 시스템을 늘리면 관리가 잘되는 것이 아니고 빠져나갈 구멍만 늘어간다. 중심이 되는 이슈관리시스템 하나라도 제대로 사용하는 것이 중요하다. 

개발에 투입할 절대 시간은 정해져 있으니 최대한 개발에 집중할 수 있도록 시스템은 간소화 하고 집중화 해야 한다. 시스템이 많아지면 시스템 때문에 개발 시간을 빼앗기게 된다. 

하지만 이슈관리시스템으로 모을 수 없는 것들이 있다. 원래 전문 시스템이 있는 고객요요청, 재고관리, 인사, 재무, QA관련, 프로젝트 관리, 비용처리등은 ServiceDesk, ERP, HR, MIS, QMS, PMS 등의 시스템을 사용해야 한다. 일부는 이슈관리시스템과 연동할 수 있지만 대체는 안된다. 

작은 회사에서 전문 시스템이 없을 경우 이슈관리시스템으로 대충 관리를 할 수 있지만 이는 임시이다. 나중에 회사가 커지면 전문 시스템을 도입해야 한다.

이슈관리시스템 하나만 보더라도 회사의 역량이 얼마나 되는지 대충 알 수 있다. 어디 끝내주는 방법이 없을까 고민하지 말고 이슈관리시스템 하나라도 제대로 쓸 수 있도록 하자.

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다.

보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속 하기를 원한다. 따라서 수많은 고정관념을 가지고 변화를 거부한다. 이를 극복하지 않으면 변화는 성공할 수 없다.

물론 제대로된 변화를 시도해야 한다는 전제조건이 필요하다. 어설픈 변화의 시도로 직원들만 고생하고 더 비효율적으로 변하는 변화도 수두록하다. 이러한 시도들이 쌓여 가면서 고정관념이 쌓인 것도 사실이다.

이러한 고정관념에는 어떠한 것들이 있는지 알아보고 극복해보도록 하자.

1. 전에 안해본줄 알아?

대부분은 과거의 잘못된 경험으로 인해 누적된 불신감이 변화에 거부감을 유발한다. 어설프게 시도한 과거의 경험은 잊어버리고 제대로 다시 해야 한다.

2. 어디 얼마나 잘되나 보자

회사에서 시도하는 변화를 무조건적으로 냉소적인 비판을 하는 경향이 있는 사람들이 있다. 이런 경우 강제로 따라오게 하던가 강제로도 안되는 직원들은 내보내는 것이 좋다.

3. 나는 바쁘니가 잘되면 따라갈께

누구나 나는 바빠서 변화할 시간이 없다고 하는데 그렇게 변화를 미루면 가치없는 일을 하는데 계속 더 바빠질 뿐이다. 적절한 시기에 결단을 해서 변화를 모색하지 않으면 안된다. 

4. 어차피 하가다 안되서 원래대로 돌아갈텐데

과거에 변화의 시도들이 여러차례 실패하여 원래대로 회귀했던 경험이 쌓여서 새로운 변화의 시도도 불신하며 따라가는 척만 하는 경향들이 있다. 직원들의 적극적인 참여 없이는 실패하기 쉽다. 무조건적인 외형적 변화보다 먼저 인식의 변화를 시키는 것이 필요하다.

5. 우리 회사가 하는일이 어련할려구

그동안 회사가 직원들에 신뢰를 주지 못하여 직원들의 믿음을 갖지 못하는 경우가 많다. 회사는 직원들의 신뢰에 대해서 소홀히 생각하는 경우가 많은데 이런 경우 변화의 흐름에 직원들을 동참시키기가 어려워진다.

6. 구관이 명관이다.

자신이 오랫동안 해왔던 방법을 무조건적으로 맹신하는 것이다. 그 방법이 지금까지 성공하는데 큰 역할을 했어도 앞으로 회사가 더욱 성장하는데는 큰 걸림돌이 되는 것이 일반적이다. 회사에서는 무조건적으로 위기 의식을 심어주기 보다는 변화가 필요한 실상을 직원들에게 제대로 이해 시키고 변화에 동참시키는 것이 필요하다.

7. 문서로 보고하라니까

주먹구구식으로 오랫동안 일을 하다가 체계적으로 바꾸려고 하면 무조건 모든 것은 문서로 작성하고 문서로 처리를 하려고 한다. 문서는 꼭 필요하지만 필요한 만큼보다 더 만들면 무조건 손해이다. 가장 좋은 것은 문서를 꼭 필요한 만큼만 최소로 만드는 것이고 회사의 규모에 맞게 가능하면 적게 만들어야 한다. 문조건 문서로 보고하라는 문서 지상주의는 오히려 변화를 방해한다.

8. 프로세스대로 해야지

프로세스를 핑계로 일을 제대로 진행하지 않는 경우가 있다.

프로세스는 일을 효과적으로 하기 위한 방법이지 일을 방해해서는 안된다. 프로세스를 너무 엄격하게 만들어 놓으면 오히려 부담이 되고 프로세스를 지키려고 효율이 더 떨어지게 된다. 프로세스는 현재의 역량에 알맞게 감당할 수 있게끔 만들어야 하고 효율적으로 적용해야 한다. 프로세스를 기계적으로 따라서 일이 진행될 수 있으면 직원들은 모두 로봇으로 바꿔도 될 것이다. 하지만 그런 일을 발생하지 않는다. 프로세스는 부담이 아니고 일을 효과적으로 처리하기 위한 방법이라는 것을 잊으면 안된다. 

9. 우리 회사는 다르다.

우리 회사는 매우 독특해서 다른 회사들이 하는 방법은 적용이 안되고 지금하고 있는 방법을 바꿀 수 없다고 생각하곤 한다. 그 예로 고객이 요구사항을 자꾸 바꾸고, 개발 기간이 너무 짧다는 등의 예를 든다. 하지만 그렇게 생각하는 대부분이 수많은 회사들이 이미 겪고 있는 것들이고 그렇기 때문에 이러한 환경에 좀더 효율적으로 대처하고자 하는 것이다. 우리 회사는 다른 것이 아니고 다르다고 착각하는 것이다.

변화가 어려운 것은 확실하다. 하지만 변화하지 않고는 성장하기 어렵다. 스스로 변화를 시도하가 실패하기보다는 전문가의 도움을 받는 것도 좋은 방법이다. 

가장 중요한 것은 경영자의 의지와 직원들의 동참이다.

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다.
2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다.
3. 문제 해결 능력을 키워야 한다. 개발자의 가장 중요한 핵심 역량이다.
4. 창의적인 사람이 되라. 대부분의 좋은 해결책은 창의력에서 나온다.
5. 다른 사람의 코드를 이해할 수 있는 능력을 키워야 한다. 다른 사람의 코드에서 배운다.
6. 수학을 잘 해야 한다. 수학을 못하면 값싼 쉬운 개발 밖에 못한다.
7. 좋은 커뮤니케이션 스킬을 갖도록 노력해야 한다. 프로그래밍은 컴퓨터와 얘기하는 것이 아니고 사람들과 얘기하는 것이다. 
8. 협업 능력을 키워라. 다른 사람과 일을 나눠서 할 수 있어야 내 몸값이 비싸진다.
9. 논쟁(debate) 능력을 키워야 한다. 고급 개발자가 될 수록 토론하는 일이 늘어날 것이며, 좋은 토론이 좋은 소프트웨어를 만든다.
10. OOP를 완전히 이해해야 한다. 협업이 더욱 원활해질 것이다.
11. 남이 이해할 수 있는 문서를 작성할 수 있어야 한다. 문서 작성은 평생 따라다니는 중요한 업무이다.
12. 적어도 한가지의 개발언어는 완전히 마스터를 해야 한다. 마스터한 언어로는 어떠한 문제도 풀 수 있어야 한다.
13. 적어도 한가지의 스크립트 언어를 구사할 수 있어야 한다. 간단한 툴은 쉽게 만들어 쓸 수 있다.
14. 비즈니스를 이해해야 한다. 훌륭한 아키텍트가 될 것이다.
15. 주변에 나보다 훨씬 뛰어난 프로그래머를 둬라. 끊임 없이 배울 수 있다.
16. 끊임 없이 새로운 기술을 익혀라. 전쟁에서 쓸 무기가 많아질 것이다.
17. 습관적으로 주석을 달아야 한다. 주석은 남을 위해서 다는 것이 아니고 프로그래밍의 일부이다.
18. 남이 이해하기 쉬운 코드를 작성해야 한다. 나중에 내 발목을 잡지 않을 것이다.
19. 리뷰와 친해져야 한다. 평생 리뷰를 하며 사는 것이 프로그래머의 인생이다. 리뷰를 하지 않으면 발전하기 어렵다.
20. 건강을 유지해라. 건강을 잃으면 실력이고 뭐고 다 필요 없다.
21. 좋은 의자를 사라. 건강을 지켜주고 효율을 높여준다.
22. 인생을 즐길 줄 알아야 한다. 프로그래머로 오래 지속하고 싶으면 인생 자체를 즐기는 다양한 방법을 익혀야 한다.
23. 소프트웨어 공학을 익혀라. 주먹구구식 개발에서 벗어나게 해주고 개발을 즐겁게 해줄 것이다.
24. 높은 연봉을 받일 수 있도록 꾸준히 노력하라. 위 23가지 방법이 도움이 될 것이다.

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다.

Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을 한 적도 있지만 최근 동향에 대해서 여러가지 정보를 들을 수 있었다.

시간이 많이 흐르고 새로운 테크놀로지는 많이 나왔지만 소프트웨어를 개발하는 방식은 바뀌 것이 거의 없었다.

그 핵심을 요약해보면 다음과 같다.

• 소프트웨어를 개발할 때 가장 중요한 것은 스펙이다.
• 스펙을 작성하는데 가장 노력을 많이 들이고 고급엔지니어가 투입된다.
• 전체 개발 기간 중에서 스펙을 작성하는 분석 기간이 가장 길다.
• 스펙을 작성할 때 마케팅이 아주 중요하게 참여를 하고 모든 관련자와 스펙을 여러차례 철처하게 리뷰한다.
• 스펙이 완성되면 스펙에 모든 관련자가 사인을 한다.
• 스펙이 바뀌는 경우는 매우 드물다. 
• 예외적인 케이스에서만 스펙이 변경되고 스펙 변경시에는 프로세스를 따른다.
• 스펙을 바꾸면 개발자들이 어려워하고 프로젝트 기간이 늘어나기 때문에 다들 스펙을 바꾸면 안된다는 것을 잘 안다.
• Agile을 적용할 때도 스펙을 잘 작성한다. 대신 주기를 줄이고 빠르게 개발한다.
• 여러 사람이 개발을 나눠서 하기 위해서는 스펙을 잘 작성하고 컴포넌트를 잘 나눈다.

물론 한 개인의 의견이 실리콘밸린 전체 상황을 대변하는 것은 아니지만 다른 회사들도 크게 다르지 않을 것이다. 이러한 근본 원리는 10년전이나 크게 다르지 않다. Agile등의 새로운 기법들이 나와도 회사에 알맞게 적용을 할 뿐이고 근본은 바뀐 것이 하나도 없다.

한국 기업과도 일을 한 적이 있는데 대단한 불만을 토로하면서 다시는 한국 기업과는 일을 하지 않겠다고 한다.

한국 기업과 일을 할 때는 이러한 일들이 일어 났다고 한다.

• 요구사항을 문서로 달라고 하는데 주지 않고 몇마디로 설명만 해준다.
• 스펙을 작성해서 검토해 달라고 하는데 검토를 안해준다.
• 스펙을 완성해서 사인을 하라고 하는데 사인을 안한다.
• 스펙대로 다 만들었는데 UI를 보고 바꿔달라고 한다.
• 계약을 제대로 하지도 않는다.

대부분의 우리나라 소프트웨어 업체들의 부족한 부분도 10년 전이나 지금이나 크게 바뀌지 않았다. 분석 능력 등을 비롯한 기초역량이 부족한 것이다. 물론 기반과 경험이 부족한 상태에서 기초역량을 갖추는 것이 쉬운 일은 아니라는 것은 잘 알고 있다. 하지만 그 상태로 계속 발전해서 Global 경쟁에서 살아 남을 수 없다는 것도 알아야 한다.

우리를 현혹하는 신기한 기법보다 근본에 충실할 때다.

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다.

조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다.

경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하기 쉽다. 

전문가를 우대하는 조직에서 조직의 장은 전문가들이 일을 잘 할 수 있도록 도와주는 관계이다. 전문가가 시간이 흐르고 승진을 한다고 해서 관리자가 되지 않는다. 

최고 경영층도 사장, 전무, 상무 등의 체제에서, CEO, CTO, CFO, CIO, COO 등의 전문가 체제가 일반화되었다. 일단 용어는 다 익숙한 것으로 보아서 많은 회사에서 전문가 시스템을 시도는 하고 있는 것이다. 물론 형식적으로 그렇게 이름만 따서 하는 경우가 허다하기는 하다.

공무원들도 외국에서는 한 분야에서 몇십년을 일해서 공무원들도 전문가가 되는데 우리나라는 고인물은 썩는다고 하여 비리를 줄이려고 공무원을 몇년마다 뺑뺑이를 돌린다. 몇년에 한번씩 지역과 보직을 바꾼다. 그래서 비리는 좀 줄었을지 모르지만 전문가를 양성하기는 어려운 상황이다.

Software 분야도 마찬가지이다.

개발을 잘하는 개발전문가들이 주도하여 일하는 것이 아니고 조직의 장이 책임을 지고 일하는 방식 위주이다. 여기서 전문성을 별로 존중되지 않는다.

그래서 개발자들은 개발을 적당히 하다가 관리자가 되기도 하고 다른 분야로 마음대로 왔다 갔다. 한다.

이러는 과정에서 가장 큰 손실을 입는 분야가 개발 분야이다. 그래서 우리나라에서는 Guru 급의 개발자들이 매우 부족하다. 모기업에서는 S급의 개발자에게는 사장보다 연봉을 많이 주겠다고는 하지만 찾기도 어렵다. 최고의 Software 전문가가 박사학위를 받은 개발자는 아니다.

Software 프로젝트도 여러 전문가들 이끌어간다. 마케터, 프로젝트매니저, 분석가, 아키텍트, UI전문가, QA전문가, Tech pub. 등등 다양하다. 

이들도 전문가로 성장하려면 분야에 따라서 5년, 10년, 20년 경험이 필요하다. 이들이 전문가로 꾸준히 성장할 수 있는 환경이 별로 없는 것이 문제다.  그렇게 진로를 보장해 주는 회사도 적을 뿐더러 관리자보다 연봉도 적고 조직내에서 영향력도 적기 때문이다. 

경쟁이 그렇게 치열하지 않는 동네 축구 리그에서 전문가가 별로 없어도 그럭저럭 살아남을 수 있다.

즉, 국내 시장에서는 그럭저럭 먹고 살 수 있다는 의미이다. 하지만 Global 시장에서 경쟁하려면 실력 차이가 너무 크게 나타난다.

개발자들이 개발에 매진할 수 있고 Software 전문가로 성장할 수 있는 환경이 꼭 필요하다. 닭이 먼저냐 달걀이 먼저냐 고민스러운 부분이다. 그래도 우선 개발자들이 꾸준히 개발자로 성장할 수 있는 제도와 사회적인 분위기를 만드는 것이 중요하다.

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까?

흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이 소스코드들의 가치는 현저하게 떨어진다.

소프트웨어 회사의 진짜 자산은 문서다. 

정확하게 말하면 문서화 된 지식과 자료들이다. 문서화 되지 않는 정보들은 휘발성으로서 개발자들이 나가면 같이 사라지는 정보들이면 회사의 자산도 아니다.

이런 휘발성 정보와 개발자에 의존하는 회사는 수명이 얼마 남지 않았다.

문서화 된 지식과 자료는 문서 파일 형태로 저장되어 있을 수도 있고 시스템에 남아 있을 수 있다.
버그관리시스템,  Wiki, KMS 등에 남아 있는 정보들을 말한다. 

이런 정보들은 개발 시스템 및 개발 프로세스와 맞물려 원활하게 작성되고 리뷰가 되며 기록이 남는다. 기록된 자료는 사라지지도 않고 누구나 쉽게 접근 할 수 있고 결정적으로 관련된 사람들이 퇴사를 해도 그대로 남아서 가치를 발휘한다.
따라서 이렇게 남는 자료와 문서들은 본인이 퇴사를 해도 가치가 있을 정도로 적혀야 한다. 

반대로 생각해서 제대로 적지 않고 내가 퇴사를 하면 파악하기 어렵게 만들어 놓는다면 자신의 가치가 올라갈 것으로 생각하기도 한다. 하지만 그 효과는 퇴사 후에 나타나지 않고 당장 나타나기 시작한다. 당장 협업이 쉽지 않으면 스스로도 다 기억할 수 없을 뿐만 아니라 본인에 대한 평판도 나빠진다. 물론 회사 전체가 그런 분위기라도 서로 똑같다면 회사가 심각한 상태라서 말할 필요도 없다.

그럼 개발자가 회사의 자산이 아니면 무엇일까?

개발자는 회사의 미래이다. 

과거를 이렇게 잘 만들어 놓은 개발자들에게는 회사의 미래를 맡겨도 된다. 과거의 경험과 지식을 바탕으로 미래에 더 가치 있고 훌륭한 일들을 해낼 개발자들이다. 

그렇지 않고 과거에 망쳐 놓은 개발자들은 과거의 발목에 잡혀서 앞으로 나아가지는 못하고 옛날에 싸 놓은 ?을 치우느라고 세월을 다 보낸다. 가끔 이런 개발자들이 다른 개발자들에게 자신이 싸 놓은 ?을 치우지 않고 자신은 또 새로운 프로젝트를 하곤 하는데, 나아지는 것은 없이 이렇게 계속 저질러 놓으면 점점 치워야 할 ?이 많아질 뿐이고 한계를 넘어가면 회사는 더 이상 못 버티게 된다.

경영자들은 개발자가 문서도 없이 뭔가 뚝딱 만들어 내는 것을 신기하게 생각하지 말고 그런 행동이 얼마나 회사를 망치고 있고 회사의 자산을 축내고 있다는 것을 깨달아야 한다.

개발자가 회사의 자산을 자신의 머리 속에 보관하고 있다가 본인도 기억 못하게 하지 말고 밖으로 꺼내서 모두의 자산이 되도록 해야 한다.