문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.

다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."

물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.

예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.

절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.

문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.

아래에 문서를 만드는 4가지 경우가 있다.

• 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당) 
• 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우 
• 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
• 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
• 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)

이중에서 당연히 권하는 것은 1번이고 다음은 2번이다.
3,4,5번 보다는 차라리 2번이 낫다.

문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.

일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.

SVN보다 Git가 더 좋을까?

요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.

1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
2. Github를 써야 한다면 Git를 써라.
3. 그외에는 모두 SVN을 써라.

기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 

CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 

일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.

• Folder공유 타입 - RCS, SCCS
• Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
• 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs

폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.

또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.

• Offline에서 자주 개발을 해야 할 때
• Git 기반의 Open source를 이용한 개발을 해야 할 때
• Git 기반의 Open source 프로젝트에 참여할 때
• Github을 써야 할 때

이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.

SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.

SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용

이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

• 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
• 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
• 그외에는 모두 Git을 써라.
• 회사를 새로 시작한다면 Git을 써라.
• SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
• SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.

SW개발자 블랙홀

중소기업, 심지어는 중견 기업들도 SW개발자를 뽑기 정말 힘들다.

신입은 물론 경력직도 구하기 어렵다.

몇년전부터 소프트웨어 경쟁력이 이슈화되면서 대기업들이 SW개발자들을 블랙홀처럼 빨아드리고 있는 것이 그 중요한 원인 중 하나이다.

이러한 현상은 비단 중소기업 뿐만 아니라 장기적으로 보면 SW생태계에도 좋은 영향을 끼치지 못하고 SW개발자들에게도 별 도움이 안된다.

그 이유는 대기업들이 SW 경쟁력 확중을 인원 확충과 같은 것으로 착각하고 있기 때문이다. 심지어는 중소기업 밥그릇을 뺏기 위해서 중소기업들이 주력하던 분야에 진출해서 관련된 개발자들을 데려가서 중소기업을 고사시켜서 시장을 뺏어 오기도 한다. 

중소기업, 중견기업을 다니는 많은 개발자들은 어려운 근무여건과 불안한 미래 때문에 대기업으로 옮기기를 선호하는 경향이 많다. 또한 대기업에 가면 체계적인 프로세스와 뛰어난 방법론 등 SW 개발에 대해서 뭔가 더 배울 수 있지 않을까 착각들을 한다.
하지만 막상 대기업으로 자리를 옮겨보면 자신들의 기대는 큰 착각이었다는 것을 깨닫곤 한다. 대부분의 대기업 SW조직은 작은 회사가 여러개 있는 것과 별반 다르지 않고 SW공학적인 능력은 중소기업보다 뒤쳐지는 경우도 많다. 

따라서 제대로된 소프트웨어 회사에서 10명이면 할 수 있는 일을 100명이 하는 경우도 있다. 이렇듯 대기업은 많은 개발자들을 빨아들이지만 개발자들을 효과적으로 활용하지도 못하고 개발자들의 역량을 제대로 키워주지도 못하고 있다. 그렇다고 딱히 다시 돌아갈 작고 좋은 SW회사들이 많지도 않다.
SW산업에 있어서 좋은 생태계는 다음과 같은 것이라고 생각한다.

좋은 토양에서는 대기업에서 체계적인 개발 방법을 배우고 좋은 아이디어가 생기면 창업을 하던지 작은 기업으로 옮겨서 자신의 생각을 펼쳐 보는 것다. 이 과정에서 대기업과 중소기업이 서로 협력하고 전체 파이를 키워야 서로 상생할 수 있다.

이 소스는 건들지마

소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.

• 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
• 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
• 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
• 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
• v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
• 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다. 

위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.
기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다. 

그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.

• 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다. 
• 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
• 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
• 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
• 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.

Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.

아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.

주석을 달기 어려운 이유

코딩을 하면서 주석을 적절히 잘 달아야 한다는데는 이견이 없을 것이다. 하지만 현실은 주석이 제대로 달린 코드를 찾아보기 어렵다.

"주석이 제대로 달렸다"의 애매한 기준을 명확하게 정리해보면 다음과 같습니다.

• 과도한 주석은 나쁘다. 비용이 너무 많이 들어간다.
• 소스코드를 활용하고 유지보수하는데 어려움이 없어야 한다.
• 업데이트가 되어서 소스코드와 일치되어야 한다. 
• 전체적으로 일관된 표준을 지켜야 한다.  

주석하나 없이 깨끗한 소스코드나 있어도 소용없는 주석은 개발에 보통 어려움이 있는 것이 아니다. 약간의 시간을 투자해서 주석을 달게 되면 투자대비 몇배의 효과를 볼 수 있다.

그럼 가장 효과적으로 주석을 다는 방법에 대해서 알아보자.

회사의 주석 표준을 정한다.

Doxygen이나 Javadoc등의 표준 주석 Notation을 따르면 여러 툴의 많은 도움을 받을 수 있고 가독성이 높아진다. 신입사원이 들어와도 널리 알려진 표준이므로 쉽게 따라할 수 있게 된다.

주석은 소스코드보다 먼저다.

주석은 코딩하면서 짬짬히 다는 것이 아니다. 코딩 이전에 설계 시 Public function을 정의하면서 주석을 먼저 작성한다. 이렇게 설계를 해서 완벽할 때 구현(코딩)에 들어가면 된다.
코딩을 하면서 Public interface가 자주 바뀌면 주석도 바꾸기 매우 귀찮아지게 된다.
하위 설계는 코드와 주석을 적당히 이용하게 되면 문서로 작성할 필요가 없이 대부분 소스코드로 작성할 수 있다.

Public function 위주로 주석을 단다.

모든 소스코드에 주석을 달아야 한다고 하면 헬스클럽 1년 끊어 놓고 일주일 운동하고 포기하는 사태가 발생하게 된다. 당장 바쁜데 언제 시간을 내서 주석을 달 수 있겠는가? 
Public function은 다른 개발자들이 가장 빈번하게 참조를 해야 할 함수들이다. 같은 시간에 주석을 달아서 가장 효율성이 높다. 
하지만 모든 함수가 Public function이라면 효과도 없고 프로그램은 뒤죽박죽이 된다. 미리 Public function을 정하게 되면 최소화를 할 수 있다. 가능하면 거의 모든 함수를 속으로 숨기고 밖으로 최소한의 Interface만 open할 경우 프로그램도 간결하게 되고 유지보수도 쉬워진다. 
Doxygen이나 JavaDoc을 이용하면 API 메뉴얼이 근사하게 나오게 된다. 이 문서만 봐도 개발자들이 개발하는데 대단히 큰 도움을 준다.
이는 소스코드와 주석/설계문서를 지속적으로 일치 시키는데 지대한 도움을 준다.

주석같은 소스코드가 좋다.

복잡한 소스코드를 작성하고 주석으로 설명하는 것보다는 약간 효율이 떨어져도 가독성 높게 소스코드를 풀어서 쓰는 것이 좋다. 따라서 함수의 크기는 작게 유지하면서 읽어 내려가기 쉽게 작성하는 것이 좋다.
성능에 목숨거는 알고리즘을 개발하는 것이 아니라면 가독성 높은 소스코드를 작성하는 것을 높은 우선순위로 두는 것이 좋다. 왜냐하면 소스코드는 개발비보다 유지보수비가 몇배 더 들기 때문이다.

Prototyping 시에는 주석이 필요없다.

Prototyping한 소스코드는 버려야 한다. Prototype은 주석도 없고 에러처리도 안하고 가장 빠르게 검증을 해보는 것이다. 제품화 할 코드는 이것보다 몇배의 시간이 더 걸린다. 따라서 Prototyping을 한 소스코드는 꼭 버리고 제대로 설계를 해서 다시 만들어야 한다. 단, 참조는 가능하다.

처음에는 강제화가 필요하다.

강제화를 위해서는 리뷰가 필수이다. 코드 리뷰보다는 설계 리뷰가 중요하다. 설계 단계에서 대부분의 Public interface의 주석을 미리 완성하고 코딩에 들어가면 협업도 원활하고 재작업도 줄어든다. 그리고나서 코딩단계에서의 주석은 크게 강조하지 않아도 될 것이다.
규칙으로 무조건 주석을 달라고 강제하는 것보다는 정공법으로 분석/설계 리뷰를 통해서 설계가 끝났을 때 주석이 이미 달린 소스코드 헤더가 나오는 것이 좋다.


무조건 코딩부터 달려드는 것보다는 한번 더 생각해보고 Public interface를 먼저 정의하고 주석을 작성해서 리뷰하고 코딩을 하는 것이 전체 개발시간을 현저하게 단축 시켜준다. 시간이 없어서 주석도 없는 코딩만 마구 해대는 것은 핑계에 불과하다. 

효과적으로 주석을 다는 습관을 가지고 있다면 여러 동료들에게 사랑을 받고 후배들의 존경을 받을 것이다.

사업부의 한계

우리나라 많은 기업들이 선택하고 있는 사업부제는 단기적인 성과를 내기에는 유리하나 장기적인 관점으로 보면 문제가 많다.

물론 사업부제 자체의 문제를 말하는 것은 아니다. 우리나라에서 사업부가 어떻게 동작하는지를 보면 된다. 

사업부는 사업부내에 모든 기능 조직을 포함하여 마치 하나의 회사처럼 동작을 하며 모든 전략, 매출 등을 책임지고 물론 그 성과에 대한 보상도 사업부가 누리는 것이다.

얼핏 들으면 아주 그럴듯 하지만 사업부의 이익과 회사의 이익이 상반되는 경우는 대단히 많다. 이런 경우 사업부에서는 회사 전체의 이익을 따르지 않는다.

그럼 소프트웨어 쪽으로 포커스를 해보자. 사업부제에서 소프트웨어 개발을 담당한 부서가 쪼개져서 각 사업부로 흩어지게 된다. 그러면서 전사적으로 소프트웨어 역량이 많이 떨어지게 된다.

• 전사적으로 일관된 소프트웨어 전략을 구사할 수 없다.
• 사업부간 소프트웨어 지식이 공유되지 않는다.
• 사업부간 인력의 왕래가 자유롭지 않다.
• 소프트웨어는 하드웨어의 부속물로 전락하는 경우가 많다. 특히 사업부의 장이 하드웨어 출신인경우이다.
• 단기적인 이익에 급급해서 소프트웨어 아키텍처는 크게 신경쓰지 못한다.
• 전사적인 큰 그림은 그리지 못한다.

이런 체제에서는 위에서 지시하면 뭘 빨리 만들어 내기는 하지만 흉내만 낼뿐 금방 밑천이 드러나게 된다.
사실 기업의 경영자들이 이러한 것을 모르는 것이 아니다. 그래서 기업의 조직 구조는 수시로 바뀌지만 인내심이 부족한 경영자들은 금방 다시 사업부제로 돌아온다. 그래도 그럴 것이 대기업의 최고 경영자들도 6개월, 1년안에 눈에 띄는 성과를 내지 못하면 자리를 보존하기 어려운 환경에서 그렇게 하기란 쉬운 일이 아니다.

많은 대기업들이 소프트웨어 역량을 향상하고 싶다면 소프트웨어 조직을 분리를 해야 한다. 사업부에서는 반대를 하겠지만 우선 가능한 부분부터 소프트웨어 조직을 통합하여 좀더 전문적이고 장기적인 관점으로 투자를 해야한다. 단기적인 성과에 집중하는 전략의 폐해는 이미 드러났다. 

이것이 변화가 가능한 중소, 중견 기업에 기대를 거는 이유이다. 

왜 소프트웨어에서 실패를 할까?

많은 회사들인 하드웨어보다는 소프트웨어에서 더 실패를 많이 한다. 사실 우리나라의 여러 산업분야에서 하드웨어는 이미 세계최고 수준에 이르렀다. 그런 회사들 조차 낙후된 소프트웨어 역량 때문에 경쟁력을 잃곤 한다.

그 이유는 무엇일까?

첫째, 하드웨어는 제대로 설계를 하면서도 소프트웨어 설계는 아예 없거나 엉성하기 그지 없다. 

소프트웨어는 인류가 만들어낸 모든 지식 산업 중에서 가장 복잡하다고 한다. 그럼에도 불구하고 우리나라에서는 소프트웨어 만큼 엉성하게 만드는 것도 없다. 
작은 집을 만들던, 빌딩을 만들던간에 설계 없이 만드는 것은 없다. 하다못해 작은 장난감도 잘 만들어진 설계가 필요하다. 그럼에도 소프트웨어는 설계없이 만드는 경우가 허다하다.

사실 하드웨어는 제대로 설계를 하지 않으면 아예 동작하지 않는다. 하지만 소프트웨어는 대단히 소프트하다는 착각에 대충 만들어서 통합이 안되거나 동작을 잘 안하면 조금씩 고쳐서 해결 할 수 있을 것으로 생각한다. 하지만 이는 대단한 착각이다. 하드웨어는 만들어 놓고 쓰다가 망가지면 버리면 되지만 소프트웨어는 한번 만들어 놓은 아키텍처가 생각보다 오래가고 나중에 발목을 잡게 된다.

또한, 하드웨어는 고객이 원하는대로 마음대로 변경해주지 않는다. 하지만 소프트웨어는 쉽게 바꿀 수 있다는 착각하에 고객마다 다른 제품을 만들어서 제공하는데, 이런 회사들은 대부분 미래에 유지보수를 감당하지 못하게 된다. 
공공 입찰의 경우 제대로된 스펙과 설계서를 요구하긴 하지만 대부분 페이지 수만 채운 형식적인 것이고 실제 개발에 제대로 쓰이지 않는다. 결국 개발자들이 머리 속으로 설계를 해서 개발하는 것이 일반적이다.

이렇게 해서는 당장 제대로 만드는 것을 떠나서 미래에 벌어지는 수많은 문제들을 점점 키우게 된다.

둘째, 소프트웨어는 완전히 다른 기업 문화를 요구한다.

하드웨어는 몇몇 천재가 기가막힌 물건을 만들어 낼 수 있다. 물론 하드웨어 분야도 수많은 사람들의 협업으로 돌아가지만 소프트웨어와는 사뭇 다르다.

소프트웨어 개발은 거의 모든 단계에서 대단한 협업이 필요하다. 또한 수평적인 조직 문화가 필요하다.

윗사람이 지시하고 이를 따르고 보고하고 통제하는 문화로는 절대로 소프트웨어를 제대로 개발할 수 없다.
자율적으로 판단하고 공유하고 리뷰하고 능동적으로 대처하는 문화가 필요하다. 관리자가 철저히 통제하고 관리하는 문화는 이를 저해하게 된다.

세째, 소프트웨어를 잘아는 경영자가 필요하다.

많은 사람들이 소프트웨어는 하드웨어를 동작하는데 도움을 주는 부수적인 부품으로 생각한다. 이런 하드웨어적인 마인드로는 소프트웨어를 절대로 잘 개발할 수 없다. 소프트웨어를 담당하고 있는 경영자라면 소프트웨어를 매우 잘 알고 제대로 된 소프트웨어 경험이 많아야 한다. 그래야 소프트웨어 전략을 수립할 수 있다. 

축구를 해본적도 없는 관중 수준의 사람에게 축구 감독을 맡길 수는 없다. 

안타까운 것은 우리나라는 소프트웨어 분야에 있어서는 너무나 갈길이 멀다는 것이다.
다행인 것은 많은 사람들이 소프트웨어에 관심을 가지기 시작했다는 것이다. 냄비처럼 확 끓었다가 식는 것이 반복하지만 않았으면 좋겠다.