블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'Context'에 해당되는 글 2

  1. 2009.08.20 회색지대에 대해서 아세요? (2)
  2. 2009.07.04 DDD (Domain Driven Design) - Context Continuous Integration (3)
 

회색지대에 대해서 아세요?

IT 이야기 | 2009.08.20 17:13 | Posted by 조대협
회색지대라는 말을 짱가님의 블로그에서 읽었는데
좋은 표현 같아서 인용해 봅니다.

IT 프로젝트에 보면 회색 지대라는 것이 종종 나타납니다.
회색지대란, "무엇인가 문제는 있는데, 그 문제가 명확하지 않고, 서로 책임을 떠넘기면서 해결되어 있지 않은 문제" 정도로 정의할 수 있습니다.
 위험요소이긴 한데 아무도 살펴보지 않고 미루다가 결국에는 프로젝트 오픈시에 큰 문제 요소로 발생되는 경우가 많습니다.
이런한 문제는 기술적인 문제일 수 도 있고, 정치적 또는 사람간의 문제일 수 도 있습니다.

지난번 DDD에 대한 글에서도 언급했듯이 사실 이런 문제는 고객이나 구성원이 프로젝트의 Context(주요 흐름과 상태)를 놓쳐 버림으로써 발생하게 됩니다. 고객이나 내부 구성원이 Context를 다시 잡기란 사실 쉽지 않지요. (왠만한 추진력이 있지 않은 이상, 또 왜 그문제를 꺼내냐? 바쁘다. 등의 면박을 받기 일 수 가 아닐까 싶습니다.) 그래서 프로젝트 바깥의  벤더 엔지니어나 컨설턴트가 이런 역할을 맏는 경우가 많은것 같습니다.

이 회색지대를 가장 잘 해결할 수 있는 사람중의 하나가 "컨설턴트" 가 아닐까 싶습니다.
1. 먼저 정치적으로 중립적일 수 있고
2. 높은 비용을 받거나 벤더의 후광 효과 또는 그만한 명성을 가지고 있거나 해서 발언에 대한 상당한 신뢰성과 영향력을 줍니다.

이 회색지대를 잘 해결하기 위해서는 먼저 
문제를 잘 인지하고 파악하여
문제의 원인을 찾아내고
이에 대한 여러가지 해법을 제시한후
고객에게 고르게 하는겁니다.

회색지대에 대한 정리는 결국 고객의 몫이라는 거지요. 경험상 고객이 회색지대 문제에 접했을때, 자신이 무엇을 해야할지를 모른다는 겁니다. 개발사나 기타 관계자들은 자신의 일이 많아 지는 것을 원하지 않기 때문에 여러가지로 감싸는 경우가 많아서 실제 문제가 이런 장벽에 가려져 있고, 컨설턴트(또는 문제를 해결하는 사람)가 이러한 장벽을 걷어낸후 문제를 표면으로 오픈해서 고객에게 명확하게 보여주고 그에 따른 몇가지 해결안을 주는겁니다.

물론 이 과정에서 장벽을 만들 사람들의 반발또한 만만하지 않습니다. 이때 필요한것이 객관적인 데이타와 프리젠테이션 능력입니다. 일정이 지연되었을 경우, Task에 Time table에 대한 데이타, 성능 저하일 경우 병목 구간에 대한 분석.. 이런 데이타를 잘 정리해서 쉽고 명확하게 만든후 프리젠테이션 자리에서 설명하는 거지요.

 일단 고객이 문제를 파악하고 어떻게 해결해야할지를 알면 그때 부터 칼자루는 고객에게 넘어갑니다.  
 
고객이 항상 묻는 이야기가 이렇습니다. "모가 문제져?" "돈이 얼마나 들까요?" "이게 누구 문제입니까?" 회색지대에 대한 해결 방법은 간단하게 말하면 
안개낀 사격장에서. 안개를 걷어내고 "자 저기 표적 보이시지요. 여기 3종류의 총이 있습니다. 이걸로 골라 쏘세요."라고 해주는게 회색지대를 해결하는 방법이 아닐까요?
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
오전에 우리딸 먹을 아빠표 맘마 만들어놓고, 우리식구 새로운 보금자리를 구입해놓고 인터리어 공사때문에, 아파트 76세대를 돌면서 인테리어 공사 동의서에 싸인을 받으러 다녀왔습니다.
메론 한손에 들고 말이지요. 51세대(70%)에 받아야 한다고 해서 어젯밤부터 부지런히 발품을 팔았습니다.

그런데 와이프가 친구가 화장실 타일을 이쁜것을 무료로 몇달후에 주겠다고 해서, 자재비 아끼기 위해서 화장실 공사를 나중에 다시 또 해야 할것 같습니다. 그래서 다시금 76세대를 돌아야 하는 사태가 생길지도 모르겠습니다.

대충 정리하고 들어오니 12시군요. 와이프는 아직 직장에서 돌아오지 않았고, 15개월된 딸은 기분좋게 낮잠을 자고 있어서 오랜만에 주말오전에 다만 몇십분이나마 개인 시간을 가지고 있습니다. DDD에 관심만 가지고 있다가 우연하게 다른분 포스트에서 Context Continuous Integration 에 대한 개념을 보게 되었습니다.

개념 자체는 프로젝트에 속한 모든 인원들이 Context 를 공유한다는 것이고, 이 Context 에 대한 통합을 지속적으로 한다는 것입니다. Context의 개념은 조금더 공부해 봐야 알겠지만 제가 이해하는 바로는 다음과 같은 내용입니다.

  • 프로젝트의 목표
  • 각 모듈별의 기능
  • 용어 (대외계,대내계,계정계,동기화,분할거래,전달보장,순차거래,서비스 등등)
  • 팀별 역할

한 마디로 정리하자면, "누가 무엇을 언제 어떻게 할것인가"에 대한 공감대를 지속적으로 공유하여 서로 같은 목표와 같은 생각으로 프로젝트를 진행하는 개념입니다.

"아! 이거다" 하는 생각이 들정도로 공감이 가는 내용이었는데, 실제 프로젝트에서도 보면, 서로 딴생각 다른 목표로 진행되는 경우가 많습니다. 그러다 보니 "여기는 A팀 역할 아니었냐?" "우리는 B팀으로 알고 있었다."와 같은 상황속에서 역할의 공백이 생기거나, "이 시스템 이렇게 동작하기로 되어 있는것 아니었어? 여기에 맞춰서 설계했는데..." "그게 아니니라 ABCD로 동작한다고 했었잖아요." 와 같은 문제가 생기게 됩니다. 실제 빈번하게 발생하는 상황이지요. 특히나 다수나 여러팀이 협업하는 경우에 많이 생깁니다.

 이런 문제를 해결하는 방법은 소통이 가장 좋은 방법입니다. 끊임없이 만나서 이야기하고 서로의 생각의 차이점을 조율하고 하나의 Context를 가지는 방법입니다.

 그외에도 Boundary를 정하는 방법이나 비지니스 적으로 시스템을 접근하는 방법등 좋은 내용이 많네요.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&s=books&qid=1246678215&sr=8-1

꼭 시간내서 읽어봐야 겠습니다.
요즘 모 출판사에서 책을 마음것 볼 수 있도록 후원을 해주시고 계셔서 읽어야 하는 책만 쌓여 갑니다. Thomas Erl 의 SOA Design Pattern에도 좋은 내용들이 많던데요.. 조금더 부지런해져서 읽어놔야 겠습니다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.