Stakeholder를 일단 분류 해보면 어떨까요?
크게
1. 발주자측과 수주자측
2. 비즈니스관련, 프로젝트관련, 개발관련
그러면 2 x 3 = 6종류의 Stakeholder의 종류가 나오는 군요.

첨부된 그림을 참조 바랍니다.

위의 최교수님의 분류 방식으로 구분해 생각하는 것은 절대적으로  필요한 일이라고 생각합니다.
위의 방식을 기준으로 여러가지 의견을 서로 나누는 것이 분류 없이 진행하는 것보다 훨씬 효과적일테니까요...

다만 위의 방식은 발주와 수주를 명확히 구분하는 소프트웨어 개발 프로젝트일때는 유용하지만 그렇지 않은 프로젝트, 예를 들어 포탈, 게임, 임베디드 개발 프로젝트에서는 헛갈릴 소지가 있을 것 같습니다.

물론 위의 프로젝트들도 굳이 발주와 수주를 나눠보면 다 그 카테고리 내에 들어가겠지만 불특정 다수 일반일을 대상으로 하는 B2C 소프트웨어 개발 프로젝트에서는 발주자가 곧 수주자가되는 경우가 많아서 혼란 스러울 수 있을 것 같습니다.

제가 여기서 말씀드리고 싶은 소프트웨어 아키텍트의 가장 중요한 Stakeholders는 상품(혹은 서비스) 기획자입니다.

게임이나 포탈이나 임베디드 시스템에 항상 존재하는 중요한 Stakeholder 중에 한명이지요...

다들아시겠지만 이 팀에서는 특정 상품, 서비스를 사용할 고객의 Needs를 조사하여 개발해야할 상품을 정의하는 곳 입니다. (UI 기획도 이 부분에 속하지요. 아시겠지만 UI에 대한 기획은 소프트웨어 개발에 아주 중요합니다. 때론 구조에도 큰 영향을 미치지요..)

굳이 구분하자면 SI 프로젝트를 하기 전에 요구사항과 프로젝트의 RFI, RFP를 만들 수 있도록 도와주는 ISP 프로젝트 팀이라고 할 수 있겠죠... (교수님의 분류로 보면 프로젝트 발주자가 맞겠네요..)

SI 프로젝트에서는 ISP 프로젝트 팀과 구분되어 프로젝트가 진행됩니다. ISP 프로젝트의 결과물을 그대로 수용한 상태에서 SI 프로젝트를 진행하게되지요... 따라서 ISP 컨설턴트 분들과 같이 요구사항을 정의하거나 하는 일은 없습니다. (그래서 솔직히 말도 안되고 쓸데없는 내용의 ISP 결과물을 볼 때가 많지만...)

하지만 제가 하는 도메인에서는 이들과 Communication할 기회가 많습니다. 또 아주 중요합니다. 

이 팀에서는 사용자의 needs를 충분히 파악하고 시나리오와 스토리보드, 경우에 따라서는 간단한 프로토타입을 만들어 개발팀에 제공합니다.  (여기서 기능 요구사항과 품질 수준의 일부를 파악할 수 있습니다. 이렇게 보면 이 분들은 비지니스 발주자가 되는건가????)

이 때 가장 중요한 것은 이 분들의 요구사항을 조율하는 것 입니다. 

예를 들어 간단한 Notification 하나를 만들어야 하는데 개발하려면 엄청난 비용이나 기간이 들어가는 경우가 있었습니다.

이럴 경우, 이것을 개발하려면 대략 이런저런 일을 해야하는데(이 때 미리 만들어 놓은 아키텍처를 이용함) 그 때 발생하는 비용이 이정도이다. 그런데도 이 기능을 꼭 넣어야 하는 것이냐.... 하고 협의를 합니다.

그 기획자분도 그 요구사항이 그렇게 과한 것인지 몰랐다고 하면서 다른 기능으로 대체하겠다고 하거나 아니면 비용을 감수하고라도 꼭 해야 한다고 얘기합니다. 이 대화의 결과에 따라서 어떤 경우에는 아키텍처를 수정하고 개발 비용을 늘려서 개발해야하는 경우도 있고 기능이 수정되는 경우도 있습니다. (이 때 서로에 대한 이해를 바탕으로 하는 대화가 꼭 필요하지요)

이렇듯 이 도메인에서 소프트웨어를 개발할 경우에는 상품 기획자와 많은 communication을 하여 사용자가 정말 좋아하는 소프트웨어를 개발해야 합니다. (기존에 아키텍트가 없는 프로젝트에서는 개발 리더가 이 역할을 하는데 개발 리더는 너무 엔지니어 마인드로 기술적 대화를 하기 때문에 기획자가 잘 이해를 못했었다고 합니다.)

정리하자면 소프트웨어 아키텍트와 상품 기획자(Stakedholder) 사이에 주고받는 정보는 다음과 같습니다.

기획자 -> 아키텍트
1. 개발해야 할 소프트웨어 인텐시브 시스템의 사용자 시나리오, 스토리보드, 프로토타입 일부(기능 요구사항, 품질 속성 일부 추출 가능)
아키텍트 -> 기획자
1. 개발할 기능이 구현되는 모습의 아키텍처 문서 및 아키텍처 소개 세션 별도 진행 ->기능 요구사항 구현 방법 소개
2. 개발 일정 소개 및 milestone 별 데모 진행 (to 기획자) -> 사용성등 품질 속성 측정

어떤 Stakeholder와 Communication하더라도 가장 기본이 되는 것은 상대방의 마음을 이해하는 것이지요.

마찬가지로 아키텍트가 기획자랑 얘기할 때는 그 분의 마음을 잘 이해해야 합니다. 그러기 위해서 아키텍트는 상품 기획에 대한 지식이 필요합니다. 물론 내가 만든 상품의 사용자의 needs가 무엇인지 명확히 알기 위해서라도 기획자와 충분한 대화를 해야합니다.

이 부분에서 균열이 가서 아키텍트(혹은 개발 리더)가 기획자랑 맨날 싸우고 개발 기술에만 우선시 한다면 엔지니어를 위한 소프트웨어 제품이 나오겠지요.. (실제로 이런 일이 아주 많이 일어납니다.)

 그것을 매꿔줄 수 있는 사람은 역시 현안이 있는 소프트웨어 아키텍트겠지요. (모르긴 몰라도 아이폰에 들어간 소프트웨어 제품의 아키텍트는 고객의 needs가 뭔지 명확히 알고있는 사람이 아닐까요? 아님 뭐 스티브 잡스가 개발자를 막 밀어부쳤던지.... ㅋㅋㅋ)

고객의 Needs를 정확히 파악하고 제품을 기획하는 것이 기획팀의 일이라고 이것을 구현하는 사람, 그 중에서도 아키텍트가 그것을 이해하려 하지 않고 개발만 우선시 한다면 그 제품을 누가 쓰겠습니까??? 

SI 아키텍트를 할 때는 크게 고민하지 않아 제가 반성하는 부분입니다.  

제가 지금 하고 있는 아키텍트 업무에서 가장 중요한 Stakeholder는 상품 기획팀의 기획자 분들입니다.