Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

소프트웨어를 개발하다 보면 소스코드의 브랜치가 일어나고 이를 Merge(머지)하는 일은 피하기가 어렵습니다.

이 Merge(머지)과정을 자동화 툴을 이용하면 상당히 많은 시간을 절약할 수 있습니다.

특히 Merge의 자동화를 위해서는 3way-Merge가 필수적인데, 시중에서 3way머지가 지원된다고 하는 툴 4가지와 SVN에서 지원하는 Unified diff, 이렇게 총 5가지를 비교해봤습니다.

그 결과는 아래와 같이 평가를 하였습니다. KDiff3, P4Merge와 Araxis Merge가 우수하게 나왔습니다.

2way merge툴은 같은 레벨에서 비교 대상이 되지 않기 때문에 비교하지 않았습니다. 2way merge툴보다는 꼭 3way merge툴을 쓰기를 권장합니다.

3way merge툴은 실무에 있어서 2way merge툴보다 10배에서 100배까지 더 효율적입니다. 직접 이해를 하고 써보기 전까지는 짐작하기 어려울 정도입니다.

제 책(소프트웨어 개발의 모든 것)에서 3way merge에 대해서 자세히 설명하고 있으니 참조하기시 바랍니다.

총점

비교 데이터

비교 방법은 일부러 Conflict가 일어나는 상황을 만들어서 각 Merge툴이 얼마나 손쉽게 Conflict를 해결하는지 비교하였습니다.

제가 분석을 위해서 사용한 파일은 다음과 같습니다.

위에서 자동으로 Merge가 가능한 부분은 노란색으로 칠했고, Conflict가 나는 부분은 보라색으로 칠했습니다.

이렇게 Conflict를 일으켜서 SVN에서 자동 Merge를 실패하게 한 후에 각각의 Merge툴로 비교를 해 봤습니다.

실행

KDiff3와 Araxis Merge는 Conflict가 났을 때 SVN에 떨궈주는 파일 3개를 선택해서 쉽게 해당 툴을 실행할 수 있습니다. 그래서 Merge하는 시간을 절약할 수 있습니다.

KDiff3

Araxis Merge

비교 화면

비교는 Orginal File(Base)과 Trunk File(Working)과 Branch File 3개를 비교했습니다.

그 화면은 다음과 같습니다. 이미지를 클릭하면 큰 이미지를 볼 수 있습니다.

언뜻 보기에는 각각의 화면이 크게 차이가 나지 않는 것처럼 보입니다. 각 툴마다 다른 부분, Conflict가 나는 부분을 다른 방법으로 표시를 하고 있습니다. KDiff3는 한글이 깔끔하게 나오는 것이 눈에 좀 거슬리지만, 기능에는 문제가 없습니다.

비교 화면에서는 Araxis Merge가 가장 직관적이고 깔끔한 화면을 보여줍니다.

KDiff3

P4Merge

Araxis Merge

Beyond Compare

Ultra Compare

Merge시 Conflict를 알려주는 다이얼로그

KDiff3와 Araxis Merge는 의미있는 Conflict 정보를 Merge시 알려줍니다. 둘다 자동 Merge를 하면서 Conflict가 난 2건을 표시해 줍니다.

P4Merge는 가장 직관적인 화면을 보여주며 마찬가지로 Conflict 2건을 표시합니다.

KDiff3

 

P4Merge

Araxis Merge

 

Merge 화면

Merge를 실행하게 되면 KDiff3, P4Merge와 Beyond Compare는 원래 파일 3개는 그대로 두고 새로운 Merge파일 창이 새로 생깁니다. 하지만, Araxis Merge와 Ultra Compare는 기존의 파일을 수정하도록 되어 있네요.

P4Merge가 가장 직관적입니다.

KDiff3

P4Merge

Araxis Merge

 

Beyond Compare

 

Ultra Compare

 

Conflict 해결

Conflict는 각각 어떻게 해결을 할 수 이나 비교를 해 봤습니다.

KDiff3 - Merge화면에서 Conflict가 난 줄은 <Merge Conflict>라고 표시가 됩니다. 원래 비교 대상인 3개의 파일 중에서 하나를 마우스나 키보드를 이용해서 선택할 수 있습니다.

 

P4Merge - Merge창에서 Conflict가 난 부분은 붉은 표시가 되어 있습니다. 오른쪽에 있는 버튼을 클릭해서 원하는 부분은 클릭하면 쉽게 Conflict가 해결됩니다.

Araxis Merge - Conflict가 난 줄들은 줄 앞에 빨간 동그라미가 나옵니다. 해당 줄에서 >>, << 버튼을 이용해서 선택을 하면 됩니다.

 

Beyond Compare - Conflict가 일어난 줄은 붉은 바탕으로 표시가 됩니다. 이 줄에서 마우스 버튼을 이용해서 원하는 파일을 선택하면 적용이 됩니다. 테스트 시 라인 단위로 정교하게 선택이 안되고 뭉쳐서 선택이 되는 바람에 원하는대로 Merge를 하는데 시간이 좀 걸렸습니다.

 

Ultra Compare - Conflict는 표시가 안됩니다. 그냥 서로 다른 줄을 찾아서 ->, <-버튼을 이용해서 선택하면 됩니다. 자동 Merge가 안되서 수동으로 일일이 선택을 해줘야 합니다.

Unicode 지원

KDiff3 - Unicode를 지원하나 Auto detect가 잘 안되네요.

P4Merge - Unicode를 완벽하게 지원합니다.

Araxis Merge - 지원한다고 하는데, View에서 깨져 보임,  Merge는 됨 

Beyond Compare - View, Merge 모두 지원

Ultra Compare - View, Merge 모두 지원

총평

기능면에서는 약간 부족함은 있으나, 기본적인 Merge기능에 충실하고 가격이 무료인 KDiff3와 모든 기능이 우수하지만 가격이 좀 부담스러운 Araxis Merge에 높은 점수를 주었습니다.

그리고 P4Merge는 Merge 기능이 가장 직관적인고 편리합니다. 

실제로 Merge결과 원하는 결과대로 바로 Merge가 되면서 Conflict를 몇 초만에 해결할 수 있었던 것은 KDiff3, P4Merge와 Araxis Merge밖에 없었습니다.

Branch와 Merge가 빈번하고 회사에 경제적인 여유가 된다면 Araxis Merge가 적당할 것 같고, 그렇지 않은 경우라면 다른 유료 툴보다도 KDiff3와 P4Merge가 좋을 것으로 생각합니다.

Build Script를 C언어로 작성하기

Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까?

저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요? 

누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다.

물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요.

Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다.

• C언어는 기가 막히게 잘 아는 Script언어는 잘 모른다.
• Build Logic이 복잡하여 Script언어로는 작성하기 어려울 것 같다.
• Build 과정에서 다른 시스템과 연동하는 등 인터페이스가 많다.

Script언어를 하나도 모른다면 어쩔 수 없겠지만, Script언어로도 빌드에 필요한 정도의 모든 기능은 쉽게 구현할 수 있습니다. 오히려 Build를 위해서 만들어진 Ant같은 경우는 더 효율적입니다. Script언어에 아직 익숙하지 않다면 간단하게 Batch 파일로 작성할 수도 있습니다. 그리고 C언어와 유사한 Python을 이용하면 Python을 아주 잘하지 않더라도 간단한 Build Script 정도는 만들어 낼 수 있습니다.

Build Script는 처음부터 모든 원하는 기능을 다 자동화 할 필요는 없습니다. 우선 기본적인 빌드 기능부터 구현을 한 다음에 사용을 해보면서 자동화가 필요한 부분을 차례차례 추가해 넣으면 무난히 효율적인 Build Script를 만들 수 있습니다.

소스코드 관리 방법 조사 결과

그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다.

현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다.

이번 소스코드관리 설문의 질문은 다음과 같습니다.

소스코드는 어디에 보관하세요?  (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)

약 3주간의 설문 결과 아래와 같은 분포가 나왔습니다.

0%	27%		54%	COUNT	PERCENT
						COUNTRY	OVERALL
Subversion					302	54.41%	54.41%
CVS					38	6.85%	6.85%
Visual SourceSafe					28	5.05%	5.05%
Team Foundation Server					16	2.88%	2.88%
IBM Rational ClearCase					16	2.88%	2.88%
RCS					2	0.36%	0.36%
Git					38	6.85%	6.85%
Mercurial					13	2.34%	2.34%
SVK					0	0%	0%
Bazaar					1	0.18%	0.18%
BitKeeper					0	0%	0%
FileServer에 보관					14	2.52%	2.52%
개인 PC에 보관					41	7.39%	7.39%
공용개발서버에 보관					26	4.68%	4.68%
실운영서버에 보관					6	1.08%	1.08%
Other:

일단, 예산대로 소스코드관리시스템중에서는 Subversion이 압도적인 1위를 차지했습니다.

그리고 CVS가 2위, VSS가 3위입니다.

하지만 소스코드관리시스템을 사용하지 않고, 일반 서버나 개인PC에 보관한다는 응답도 꽤(25%) 많았습니다.

아래 수치는 내가 컨설팅을 하면서 보아온 비율과 크게 다르지 않습니다. 하지만, 소스코드관리시스템을 사용하는 방법에 있어서는 많은 차이들이 있기 때문에 소스코드관리시스템을 얼마나 잘 활용하고 있는지에 대해서는 또다시 조사를 하는 것도 의미가 있다고 생각합니다.

그중에서도 특히 개인 PC에 많이 소스코드를 보관하고 있는 것으로 조사가 되었습니다. 다음은 소스코드관리시스템이 아닌 장소에 소스코드를 보관하는 방법중에서의 비율입니다.

위와 같이 소스코드관리시스템을 사용하지 않고 개발을 하는 방법은 대단히 불편하며, 쓸데 없는데 시간과 노력을 빼앗기는 정말 비효율적인 방법이 아닐 수 없습니다. 설령 소스코드관리시스템을 사용하고 있다고 하더라도, 소스코드의 기준이 개인 PC나 서버에 보관된 소스코드라면 소스코드관리시스템을 사용하고 있는 것과 크게 다르지 않습니다.

소스코드관리시스템을 사용하지 않으면 당장 겪는 어려움은 다음과 같습니다.

• 최신 소스코드를 쉽게 파악하기 어렵고 이게 정말 최신 소스인지 확인이 어렵다.
• 소스코드 공유가 불편하다.
• 소스코드를 동시에 수정하는 등의 협업이 불편하다.
• 소스코드를 안정적으로 백업 받을 수가 없다.
• 소스코드의 변경에 대한 히스토리를 파악하기 어렵다.
• 소스코드에 베이스라인 설정이 불편하다.
• 소스코드의 변경과 버그의 연관성을 파악하기 어렵다.

이정도는 아주 기본적인 불편함에 속합니다. 좀더 나아가면 엄청나게 복잡해집니다. 왠만한 규모의 회사도 소스코드의 관리는 꽤 복잡하며 이률 효율적으로 관리하지 않으면 생산성을 높이기가 어렵습니다. 다음과 같은 일들이 벌어지는 상황에서는 더욱더 소스코드관리시스템이 필요합니다.

• 동일 제품이 신규 개발과 유지보수가 동시에 진행되고 있다.
• 여러 개발팀이 동일한 소스코드를 동시에 수정한다.
• 서로 릴리즈 시기가 다른 기능들을 동시에 서로 다른 팀에서 구현하고 있다.
• 특정 회사의 긴급한 요구에 의해서 소스코드 브랜치가 일어났고, 곧 머지(Merge)할 계획이다.
• 미국과 중국에 있는 개발자와 동시에 개발을 진행하고 있다.

소스코드관리시스템없이 소프트웨어 개발을 하고 있다면 이는 한마디로 "기적"이며 정말로 쓸데없는 낭비를 하고 있는 겁니다. 소스코드관리시스템없이 소프트웨어를 개발한다는 것은 상상할 수도 없으며, 이미 소스코드관리시스템을 사용하고 있는 화사는 과거로 돌아가서 소스코드관리시스템 없이 개발하라고 하면 그런 상황은 상상하기도 싫을 겁니다.

소스코드관리시스템은 일단 설치해서 사용하는 것은 쉽게 할 수 있지만, 제대로 사용해서 생산성을 극대화하는 것은 상당히 어렵습니다. 앞으로 이에 대한 설문도 진행해 볼 계획이고, 블로그 글도 작성을 해보려고 합니다.

소프트웨어 개발의 극과 극

꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다.

소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다.

여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다.

완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다.

그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다.

극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.

개발자도 문서를 잘 작성할 수 있어야 한다.

개발자(엔지니어)들이 문서를 잘 작성하지 못한다는 것은 익히 알려져 있는 사실입니다.

 

개발자에게 프로그래밍 실력이 더 중요하지 문서 작성 기술이 얼마나 중요하겠냐?라고 생각하는 사람이 있을 수도 있겠지만, 개발자가 성장할수록 문서 작성 능력의 중요도는 점점 더 커집니다.

 

문서를 잘 작성하지 못하는 개발자는 협업을 하는데 있어서 치명적인 결함을 가지고 있다고 할 수 있습니다.

 

그럼 문서를 잘 작성하는 것은 무엇이고? 문서를 잘 작성하지 못하는 것은 무엇일까요?

잘 작성되지 못한 문서의 특징을 한번 살펴보죠.

 

• 문서의 내용이 쉽게 이해가 되지 않는다. 외계어로 작성된 것 같다.
• 여백 없이 빽빽이 작성되어서 읽는데 너무 피곤하다.
• 문법이 많이 틀려서 내용도 신뢰가 가지 않는다. 주어도 없고 문장의 앞뒤가 전혀 맞지 않는다.
• 주변 얘기만 빙빙돌려서 하고 있고 핵심이 뭔지 잘 모르겠다.
• 내가 관심있는 내용은 없고 작성자의 관심거리만 적혀있다.
• 사용하고 있는 단어들이 너무 전문적이고 어렵다.
• 분량이 너무 많아서 읽기 힘들고 주제 파악이 힘들다.

 

물론 개발자라면 개발에 필요한 핵심문서를 잘 작성할 수 있어야 합니다. 하지만, 이같이 기본적인 문서작성 기술도 없다면, 개발문서라고 해서 잘 작성할 수는 없습니다.

 

"조엘온소프트웨어"의 저자인 조엘 스폴스키는 개발자를 뽑을 때 글을 잘 쓰는 사람을 뽑는다는 원칙이 있다고 합니다. 글 쓰기 능력을 키우는 것은 프로그래밍 실력을 키우는 것보다도 더 어려울 수 있습니다. 그래서 아예 글을 잘 쓰는 사람을 뽑는 것이 더 합리적으로 보이기도 합니다.

 

개발자들은 문서를 잘 작성하지 못한다는 얘기는 어디서나 통하는 말이지만, 특히 우리나라의 개발자들은 단순 주입식 교육 환경 때문에 읽고, 외우는 것은 잘하지만 자신의 의견을 남들에게 쉽고 조리있게 전달하는데는 익숙하지 못합니다. 그렇다고 문서작성을 포기할 수는 없죠. 평생 혼자서 개발할 것이 아니라면 문서는 점점 더 필요하게 되죠. 아니 혼자서 개발을 하더라도 문서를 잘 작성하는 것이 필요합니다.

 

그럼 문서 작성 실력을 키우기 위해서 어떻게 해야 할까요? 역시 훈련이 필요합니다. 단순히 여러 번 작성해 본다고 되는 것이 아니라 제대로 작성하기 위해서 노력해야 합니다. 이제, 문서 작성 실력을 향상하기 위한 몇 가이드를 하려고 합니다. 그 출발점은 다음과 같습니다.

 

"문서작성 기술이 필수 기술이라는 것을 먼저 인식해야 합니다."

 

필요성을 못 느끼면 발전도 없습니다. 그리고 문서를 잘 작성하려면 다음과 같은 것을 고려해야 합니다.

 

• 문서를 작성하는 목적은 내가 일기 위한 것이 아니고 남이 읽기 위한 것이다. 읽는 사람의 눈높이에 맞춰서 적절한 단어를 사용해야 한다.
• 주제를 직설적으로 전달해야 한다. 문서를 읽는 사람은 친절하게 문서를 처음부터 끝까지 다 읽어 줄만큼 한가하지 않다. 주제를 먼저 전달함으로써 문서를 읽는 사람이 문서를 계속 읽을지 말지 결정할 수 있도록 해야 한다.
• 필요한 내용을 쓴다. 문서 작성의 목적을 달성할 수 있도록 문서를 읽는 사람이 기대하는 내용을 충분히 적어야 하며 자신만 관심 있어 하는 필요 없는 내용은 쓰지 않는다. 이런 내용들은 문서의 양만 늘리고 문서의 가치를 떨어뜨린다.
• 사실과 의견을 확실히 구분하여 작성한다. 사실과 의견의 혼동은 수많은 오해를 불러일으키게 된다. 심지어는 중요한 비즈니스에서 잘못된 결정을 유도할 수도 있다.
• 쉬운 표현을 써야 한다. 복합문장은 이해하기 어려운 경우가 종종 있다. 가능하면 문장은 작게 잘라서 하나의 문장에 하나의 논리만 포함하도록 하는 것이 좋다.
• 맞춤법이 맞아야 한다. 맞춤법이 틀리면 문서의 내용 및 문서 작성자에 대한 신뢰가 떨어질 수 있다.
• 읽기 편하게 화면을 구성해야 한다. 화면에 적당한 여백을 두고 자간, 행간을 조절하고, 적절한 그림이나 표를 사용해서 문서를 읽는 사람이 지루해 하지 않고 문서의 내용을 빨리 파악할 수 있도록 해야 한다.
• 화면 꾸미기에 시간을 허비 하지 않는다.

 

다시 한번 강조를 하지만 개발자는 문서를 잘 작성할 줄 알아야 합니다. 구슬이 서말이라도 꿰어야 보배이듯이 머리 속에 아무리 좋은 정보를 담고 있어도, 이를 문서로 잘 작성할 수 없다면, 고급 개발자는 될 수 없습니다. 꾸준히 문서를 작성하고 읽는 사람으로 부터 평가를 받아야 합니다. 문서를 잘 작성해야 한다고 깨닫는 것이 문서를 잘 작성하기 위한 과정의 시작입니다.

개발자 윤리 장전

소프트웨어 개발자라는 직업은 특수성이 많은 것 같습니다.

• 뭘 좀 잘못해도 쉽게 눈에 안띄고, 
• 문제가 되어도 딱히 누가 잘못한지도 잘 모르겠고, 
• 맘 먹고 동료들이나 경영자를 속이고 있어도 쉽게 알아차리기 힘들고,
• 자신의 실력보다 과대포장을 해도 눈치채기 어렵습니다.
• 또 하루종일 일을 하고 있어도 정말 열심히 하는 것인지 노는 것인지 알아내기 어렵고,

이러한 소프트웨어 개발자들이 빌딩을 만들거나 비행기를 만든다면 빌딩이 무너지거나 비행기가 추락하겠죠. 하지만 소프트웨어 필드에서는 그러한 오류가 종종 숨겨지고, 원인을 밝히기 어려운 경우가 태반입니다.

결국 소프트웨어 개발자들은 스스로의 발전을 위해서도 윤리의식을 가지고 있어야 합니다. 이러한 자세는 개발자 스스로에게도 도움이 된다는 것을 강조하고 싶습니다.

이렇게 개발자들이 지켜야할 윤리의식에 대한 저의 생각을 나열해봤습니다.

나의 시간의 일정부분은 Peer Review에 사용하겠다. 나의 지식과 업무 성과는 문서화하여 동료들과 공유하겠다.  소프트웨어 설계 시 미래의 변경을 염두 하겠다.  소프트웨어 개발 시 유지보수 개발자들을 배려하겠다.  아키텍처를 구상할 때 회사의 비즈니스를 고려하겠다.  나의 편협한 지식으로 동료와 경영자를 현혹시키지 않겠다.  오만에 빠지지 않고 꾸준히 공부하겠다.  동료들과 같이 정한 개발 규칙을 따르겠다.

이 외에도 개발자들이 지켜야 할 윤리의식에 대한 의견 있으신 분들은 댓글 남겨 주세요.

요구사항 분석의 출발점

소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다.

2008/11/19 SRS(Software Requirements Specification)의 중요성

2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?

요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요?

"왜 이 프로젝트를 하려고 하는가?"입니다.

프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다.

이걸 누구나 다 알고 있다고요?

제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적에 대해서 서로 다른 얘기를 합니다. 프로젝트의 목적이 공유가 안되어 있거나 심지어는 심각하게 고민도 해보지 않은 경우 입니다. 그렇다면 프로젝트는 산으로 가는 경우가 많습니다. 수많은 의견 충돌 시 프로젝트의 목적에 맞게 합리적인 결정이 이루어지지 않습니다.

지금 프로젝트를 하고 있다면 프로젝트의 목적이 정확하게 공유되고 같은 생각을 하고 있는지 확인해보세요.

개발자끼리가 아닙니다. 개발자, PM, PL, QA, 영업, 마케터 등 프로젝트 관련자 모든 사람이 같은 프로젝트 목적을 공유하고 있는지 입니다.

그럼, 서로 팀워크가 착착 맞아서 눈빛만 보면 서로 다 안다고 하면 서로 같은 생각을 할까요? 이런 경우에도 프로젝트 목적이 뭔지 명확하게 정의해서 공유하지 않으면 각기 다른 생각을 하는 일은 매우 흔합니다. 요구사항 분석 산출물의 맨 앞에는 프로젝트 목적을 명쾌하게 정리해서 모두 공유할 수 있도록 해야 합니다. 물론 모든 관련자가 동의를 하는 내용이어야 합니다.

프로젝트를 시작하면 왜 이 프로젝트를 하는지 명확하게 알아내고, 정의하고, 공유해야 합니다.