개인적인 견해이지만, 프로젝트 실패 요인의 99% 는 개념 설계의 부재에서 온다고 본다. 만약, 회계 관련 프로그램을 제작한다고 가정하자. 해당 프로그램 개발을 가장 잘 할 수 있는 방법은 무엇일까? 그냥 상식선에서 생각해보자. 아마도 회계사이면서 프로그래밍적 지식이 높은 사람이 개발하거나... 프로그래머이면서 회계에 대하여 많은 경험을 가지고 있는 사람이 개발하는 것일 거다. 바로 여기에 프로젝트 성공의 핵심 열쇠가 숨어있다.
만약, 의뢰자인 회계사가 프로그래밍에 대한 이해가 높거나 혹은 프로그래머가 회계에 대한 이해가 높다면 분명 프로젝트는 성공할 가능성이 높다. 하지만 그런 경우는 드물다. 그렇다면 차선으로 할 수 있는 일은 무엇일까? 아마도 그것은 의뢰자에게 프로그래밍에 대한 이해와 프로그래머에게 회계에 대한 이해를 높이는 과정을 마련하는 일일 것이다.
이때, 회계는 의뢰자의 도메인 영역이 되고... 프로그래밍은 개발자의 도메인 영역이 되는 것이다. 흔히들 하는 소리로 설계가 전체 개발 영역의 반 이상이라는 소리는 그냥 프로젝트 초기에 놀고 먹으라는 소리가 아니라 이 도메인 영역에 대한 상호간 학습 기간을 가지라는 뜻이다.
상호간 학습을 위해서 필요한 것은 무엇일까? 그것은 바로 커뮤니케이션이다.
초기에 발생하는 의뢰자 개발자간, 소위 개발 회의가 이에 속할 수 있다. 하지만 대부분 이 단계를 요식적이거나 비절차적으로 넘어가는 경우가 다반사다. 그리고 그로인해 서로의 불신을 키워나가는 과정이 발생하고~ 만약, 이런 단계가 지속적으로 발생하고 있다면 프로젝트는 거의 100% 실패하고만다. 설령, 결과물이 나오더라도 마지못해 사용할 수 밖에없는 결과물이 될 것이다.
프로젝트 막바지에 이르러 의뢰자의 마음이 바뀌고 개발자의 생각이 '아, 이것 보다는...' 이라는 아쉬움이 발생한다면 그건 그 막바지 단계에 이르러서야 서로 양자간의 도메인 영역에 대한 이해가 되었기 때문이라고 볼 수 있다.
즉, 되돌릴 수 없는 단계에 이르기 전에 최대한 서로의 도메인 영역에 대한 이해를 높여두는 것이 반드시 필요하다. 그리고 그것이 개념 설계이다.
커뮤니케이션에 대해서 좀 더 살펴보자.
먼저, 시작은 의뢰자의 도메인 영역을 파악하는 것에서 시작한다. 이때 해당 도메인에서 사용되는 전문 용어를 꼼꼼하게 기록해두고 그 의미를 반드시 되물어 확인해보아야한다. 형식은 자유롭게하고 본인이 편한 형태로 메모하거나 혹은 녹취하여도 좋다. 이렇게 1차적인 만남 혹은 인터뷰에서 본인이 파악한 내용을 다이어그램으로 작성한 뒤, 2차 인터뷰를 잡아 관련 내용을 의뢰자에게 검증 받는다. 이러한 중간 결과물은 매우 중요한데 왜냐하면 자칫 소모적인 행위로 보여질 수 있는 이러한 커뮤니케이션 과정에 중간 결과물은 의뢰자에게 신뢰감(개발자가 자신의 도메인 영역에 대한 이해가 점증적으로 높아져감을 느끼게 됨)을 주기 때문이다.
개념 설계의 초기 단계에서 주로 사용되어지는 다이어그램은 UseCase 와 Activity 인데, 주로 용어 분석은 UseCase 로 업무 분석은 Activity 로 정리하면 좋다. 두 다이어그램은 초기 5분 정도의 설명만으로 처음 다이어그램을 접하는 사람에게 원리를 이해시킬 수 있어 이러한 분석에 생소한 의뢰자에게 거부감을 덜어줄 수 있다.
사례1
2006년경 창업관련 홈페이지를 두고 영업, PM 간 문제 프로젝트로 분류된 건이 있었다. 내용인즉슨 견적대비 과도한 개발비용이 산출된다는 것이었고, 각자의 의견으로 설왕설래하며 결론이 나지 않았다. 해당 프로젝트를 이관받게 되어 1차적으로 개념설계 작업에 들어갔다. 일단 영업 사원과 PM 이 의뢰자에게 넘겨받은 자료들을 우선적으로 분석하고 UseCase 를 그려보았다.
상기 다이어그램은 제일 먼저 그려본, 프로그램을 사용할 엑터들을 정리한 것이다.
헬퍼라는 단어는 평소 사용하지 않는 의뢰자의 도메인 영역에 속하는 용어이다. 이러한 용어를 접하였을 때 절대 유추하거나 임의로 결론내려서는 안된다. 해당 용어의 의미를 반드시 의뢰자에게 확인하여야한다. 다이어그램에서 붉은색으로 표기한 "가맹점 헬퍼"의 의미는 무엇일까? 처음 자료를 받고 분석하였을 때 "대표 가맹점 헬퍼"는 대리점을 의미하고 "가맹점 헬퍼"는 유추하였을 경우 개인 조직일 가능성이 커보였다. 이 경우 개인에 대한 각종 정산관련 업무 프로세스가 발생할 것이다. 개인조직이 있고 없고에 따라 프로젝트의 크기가 2배 커질 수있는 소지가 있는 것이다. 결국 영업자와 PM 간 충돌은 이 지점에서 발생하고 있었다.
유즈케이스를 모두 뽑은 후에 고객과의 인터뷰를 추진하였다. 계속 되는 회의에 다소 심드렁한 반응을 보일 수 있던 상황이었지만 프로젝터로 다이어그램을 투사하고 하나 하나 의미를 짚어가니 호기심을 보이며 이내 적극적으로 회의에 참여하였다. 결론부터 말하자면 "가맹점 헬퍼" 는 "대리점에서 일하는 직원" 이라고 하였다. 애초 PM 이 예상한 작업의 1/2 이 사라져버린 것이다.
이렇게 용어에 대한 상호간 공유가 이뤄지고난 후에 의뢰자의 도메인영역에서 사용되는 용어로 회의를 진행해나가면 의뢰자에게 신뢰감을 줄 수 있다. 보통의 경우, 아는 척하고 넘어가거나 혹은 '뭐 모르면 물어보겠지' 와 같은 서로간의 귀찮음이 문제의 불씨를 키워나가게되는 것이다.
사례2
2005년경 직원 30명 규모의 웹에이전시 회사의 인트라넷 구축 프로젝트를 진행하였을 때의 일이다. 일단, 전산 계열이라 상호간 용어는 큰 문제가 되지 않았다. 다만, 상황에 따라 도입한 업무 프로그램들이 여기저기 섞여있어 해당 작업자 외엔 관련 업무 처리를 진행할 수 없는 상황이었다. 그래서 해당 작업자들을 만나 각 작업별로 업무 처리를 들은 다음 Activity 다이어그램으로 정리한 후에 다시 해당 작업자와 검증을 하고 절차상 수정되어야할 부분이 있다면 다시 수정처리한 후 최종적으로 정리하였다. 다음은 오버추어 광고 대행에 대한 인바운드 영업 절차이다.
인터뷰 초기에 "아... 일이 참 복잡한데..." 와 같은 반응을 보였던 해당 업무 직원도 그려진 산출물을 보고 "이게 정리가 되는군요?" 와 같은 반응을 보이고는 이후 상당히 협조적으로 인터뷰에 응했던 기억이 난다. 이 산출물에 대한 구구절절한 설명은 하지않도록 하겠다. 아무튼 이런 식으로 모든 부서의 모든 직원들에 대한 업무를 파악한 다음... 제안할 만한 업무 프로세스를 마찬가지로 Activity 다이어그램으로 그려 해당 담당자들과 함께 토의를 진행한다.
그리고 이 과정에서 미처 생각하지 못한 문제점들을 해당 직원들이 지적해주고 그런 점들을 지속적으로 피드백하며 다이어그램을 완성시켜나간다. 물론, 이 과정에서 업무 단계를 효율적으로 바꿀 수 있는 "역제안"들이 개발자에게서 나올 수 있다. 이러한 역제안은 또한 의뢰자에게 개발자의 도메인 영역에 대한 이해를 증가시켜주며, 해당 개념 설계가 이제 마무리 단계에 접어들었음을 알 수 있는 중요한 지표가 된다. 즉, 개발자가 역제안을 할 수 있다는 것은 의뢰자의 도메인 영역에 대한 분석이 마무리되었으며 해당 분석에 대한 자신감을 가지고 있음을 의미하기 때문이다.
이렇게 최종 완성된 다이어그램을 토대로 프로그램의 구성 및 물리 설계 단계에 들어가면, 작업을 진행하다 발생할 수 있는 수정 사항들이 거의 대부분 정리되었음을 느낄 수 있다. 결국, 수정 사항은 개념설계 단계에서 충분히 줄일 수 있는 것이다.
끝으로 상기 UML 다이어그램들이 커뮤니케이션의 수단으로 활용되었음을 상기할 필요가 있다. 개념 설계에 있어 UML 은 수단이지 목적이 아닌 것이다. 아울러 각종 업무 플로우를 그리는 여러가지 다이어그램들이 존재할 수 있으나 개인적으로는 UML 을 사용할 것을 권한다. 애초 커뮤니케이션이란 것은 많은 사람들이 사용하고 또 권장하는 것을 토대로 성립하는 것이 옳기 때문이다. 커뮤니케이션의 수단이 자발적으로 선택되어야지 누군가에 의해 강요되는 것은 바람직하지 않다고 생각한다.
과거 플로우 차트를 대신하여 한국형 순서도 쎄크(SEC)가 소개되던 때가 생각난다. 만약, 글로벌한 환경에서 쎄크를 가지고 공조 작업을 할 수 있을까? 물론, 가치와 의의면에서 해당 차트를 폄훼할 생각은 없다. 하지만 커뮤니케이션으로서의 수단으로 적합한지의 여부와 그 선택에 있어서는 고민해 볼 필요가 있다고 생각한다. 어떤 차트도 국제표준이 되지 못하는 이상 그 의미는 크게 퇴색될 수 밖에 없다고 생각하기 때문이다. 그런 의미에서 UML 1.4.2 의 경우 ISO/IEC 19501 로 인증되어있어 어느 곳에서 사용함에 있어 문제가 될 부분이 없다.(사실 UML 2.0 은 이런 부분 때문에 적용하지 않고 있다.)
각 산출물에 대한 자세한 설명은... 책을 출판할 것도 아니고해서 그냥 이 정도 수준에서 마무리할까한다. ^^ 다음 글은 초기 물리 설계에 대한 이야기를 해볼까한다.
만약, 의뢰자인 회계사가 프로그래밍에 대한 이해가 높거나 혹은 프로그래머가 회계에 대한 이해가 높다면 분명 프로젝트는 성공할 가능성이 높다. 하지만 그런 경우는 드물다. 그렇다면 차선으로 할 수 있는 일은 무엇일까? 아마도 그것은 의뢰자에게 프로그래밍에 대한 이해와 프로그래머에게 회계에 대한 이해를 높이는 과정을 마련하는 일일 것이다.
이때, 회계는 의뢰자의 도메인 영역이 되고... 프로그래밍은 개발자의 도메인 영역이 되는 것이다. 흔히들 하는 소리로 설계가 전체 개발 영역의 반 이상이라는 소리는 그냥 프로젝트 초기에 놀고 먹으라는 소리가 아니라 이 도메인 영역에 대한 상호간 학습 기간을 가지라는 뜻이다.
상호간 학습을 위해서 필요한 것은 무엇일까? 그것은 바로 커뮤니케이션이다.
초기에 발생하는 의뢰자 개발자간, 소위 개발 회의가 이에 속할 수 있다. 하지만 대부분 이 단계를 요식적이거나 비절차적으로 넘어가는 경우가 다반사다. 그리고 그로인해 서로의 불신을 키워나가는 과정이 발생하고~ 만약, 이런 단계가 지속적으로 발생하고 있다면 프로젝트는 거의 100% 실패하고만다. 설령, 결과물이 나오더라도 마지못해 사용할 수 밖에없는 결과물이 될 것이다.
프로젝트 막바지에 이르러 의뢰자의 마음이 바뀌고 개발자의 생각이 '아, 이것 보다는...' 이라는 아쉬움이 발생한다면 그건 그 막바지 단계에 이르러서야 서로 양자간의 도메인 영역에 대한 이해가 되었기 때문이라고 볼 수 있다.
즉, 되돌릴 수 없는 단계에 이르기 전에 최대한 서로의 도메인 영역에 대한 이해를 높여두는 것이 반드시 필요하다. 그리고 그것이 개념 설계이다.
커뮤니케이션에 대해서 좀 더 살펴보자.
먼저, 시작은 의뢰자의 도메인 영역을 파악하는 것에서 시작한다. 이때 해당 도메인에서 사용되는 전문 용어를 꼼꼼하게 기록해두고 그 의미를 반드시 되물어 확인해보아야한다. 형식은 자유롭게하고 본인이 편한 형태로 메모하거나 혹은 녹취하여도 좋다. 이렇게 1차적인 만남 혹은 인터뷰에서 본인이 파악한 내용을 다이어그램으로 작성한 뒤, 2차 인터뷰를 잡아 관련 내용을 의뢰자에게 검증 받는다. 이러한 중간 결과물은 매우 중요한데 왜냐하면 자칫 소모적인 행위로 보여질 수 있는 이러한 커뮤니케이션 과정에 중간 결과물은 의뢰자에게 신뢰감(개발자가 자신의 도메인 영역에 대한 이해가 점증적으로 높아져감을 느끼게 됨)을 주기 때문이다.
도메인 영역 분석 = 용어(혹은 기능) + 업무
개념 설계의 초기 단계에서 주로 사용되어지는 다이어그램은 UseCase 와 Activity 인데, 주로 용어 분석은 UseCase 로 업무 분석은 Activity 로 정리하면 좋다. 두 다이어그램은 초기 5분 정도의 설명만으로 처음 다이어그램을 접하는 사람에게 원리를 이해시킬 수 있어 이러한 분석에 생소한 의뢰자에게 거부감을 덜어줄 수 있다.
사례1
2006년경 창업관련 홈페이지를 두고 영업, PM 간 문제 프로젝트로 분류된 건이 있었다. 내용인즉슨 견적대비 과도한 개발비용이 산출된다는 것이었고, 각자의 의견으로 설왕설래하며 결론이 나지 않았다. 해당 프로젝트를 이관받게 되어 1차적으로 개념설계 작업에 들어갔다. 일단 영업 사원과 PM 이 의뢰자에게 넘겨받은 자료들을 우선적으로 분석하고 UseCase 를 그려보았다.
상기 다이어그램은 제일 먼저 그려본, 프로그램을 사용할 엑터들을 정리한 것이다.
헬퍼라는 단어는 평소 사용하지 않는 의뢰자의 도메인 영역에 속하는 용어이다. 이러한 용어를 접하였을 때 절대 유추하거나 임의로 결론내려서는 안된다. 해당 용어의 의미를 반드시 의뢰자에게 확인하여야한다. 다이어그램에서 붉은색으로 표기한 "가맹점 헬퍼"의 의미는 무엇일까? 처음 자료를 받고 분석하였을 때 "대표 가맹점 헬퍼"는 대리점을 의미하고 "가맹점 헬퍼"는 유추하였을 경우 개인 조직일 가능성이 커보였다. 이 경우 개인에 대한 각종 정산관련 업무 프로세스가 발생할 것이다. 개인조직이 있고 없고에 따라 프로젝트의 크기가 2배 커질 수있는 소지가 있는 것이다. 결국 영업자와 PM 간 충돌은 이 지점에서 발생하고 있었다.
유즈케이스를 모두 뽑은 후에 고객과의 인터뷰를 추진하였다. 계속 되는 회의에 다소 심드렁한 반응을 보일 수 있던 상황이었지만 프로젝터로 다이어그램을 투사하고 하나 하나 의미를 짚어가니 호기심을 보이며 이내 적극적으로 회의에 참여하였다. 결론부터 말하자면 "가맹점 헬퍼" 는 "대리점에서 일하는 직원" 이라고 하였다. 애초 PM 이 예상한 작업의 1/2 이 사라져버린 것이다.
이렇게 용어에 대한 상호간 공유가 이뤄지고난 후에 의뢰자의 도메인영역에서 사용되는 용어로 회의를 진행해나가면 의뢰자에게 신뢰감을 줄 수 있다. 보통의 경우, 아는 척하고 넘어가거나 혹은 '뭐 모르면 물어보겠지' 와 같은 서로간의 귀찮음이 문제의 불씨를 키워나가게되는 것이다.
사례2
2005년경 직원 30명 규모의 웹에이전시 회사의 인트라넷 구축 프로젝트를 진행하였을 때의 일이다. 일단, 전산 계열이라 상호간 용어는 큰 문제가 되지 않았다. 다만, 상황에 따라 도입한 업무 프로그램들이 여기저기 섞여있어 해당 작업자 외엔 관련 업무 처리를 진행할 수 없는 상황이었다. 그래서 해당 작업자들을 만나 각 작업별로 업무 처리를 들은 다음 Activity 다이어그램으로 정리한 후에 다시 해당 작업자와 검증을 하고 절차상 수정되어야할 부분이 있다면 다시 수정처리한 후 최종적으로 정리하였다. 다음은 오버추어 광고 대행에 대한 인바운드 영업 절차이다.
인터뷰 초기에 "아... 일이 참 복잡한데..." 와 같은 반응을 보였던 해당 업무 직원도 그려진 산출물을 보고 "이게 정리가 되는군요?" 와 같은 반응을 보이고는 이후 상당히 협조적으로 인터뷰에 응했던 기억이 난다. 이 산출물에 대한 구구절절한 설명은 하지않도록 하겠다. 아무튼 이런 식으로 모든 부서의 모든 직원들에 대한 업무를 파악한 다음... 제안할 만한 업무 프로세스를 마찬가지로 Activity 다이어그램으로 그려 해당 담당자들과 함께 토의를 진행한다.
그리고 이 과정에서 미처 생각하지 못한 문제점들을 해당 직원들이 지적해주고 그런 점들을 지속적으로 피드백하며 다이어그램을 완성시켜나간다. 물론, 이 과정에서 업무 단계를 효율적으로 바꿀 수 있는 "역제안"들이 개발자에게서 나올 수 있다. 이러한 역제안은 또한 의뢰자에게 개발자의 도메인 영역에 대한 이해를 증가시켜주며, 해당 개념 설계가 이제 마무리 단계에 접어들었음을 알 수 있는 중요한 지표가 된다. 즉, 개발자가 역제안을 할 수 있다는 것은 의뢰자의 도메인 영역에 대한 분석이 마무리되었으며 해당 분석에 대한 자신감을 가지고 있음을 의미하기 때문이다.
이렇게 최종 완성된 다이어그램을 토대로 프로그램의 구성 및 물리 설계 단계에 들어가면, 작업을 진행하다 발생할 수 있는 수정 사항들이 거의 대부분 정리되었음을 느낄 수 있다. 결국, 수정 사항은 개념설계 단계에서 충분히 줄일 수 있는 것이다.
끝으로 상기 UML 다이어그램들이 커뮤니케이션의 수단으로 활용되었음을 상기할 필요가 있다. 개념 설계에 있어 UML 은 수단이지 목적이 아닌 것이다. 아울러 각종 업무 플로우를 그리는 여러가지 다이어그램들이 존재할 수 있으나 개인적으로는 UML 을 사용할 것을 권한다. 애초 커뮤니케이션이란 것은 많은 사람들이 사용하고 또 권장하는 것을 토대로 성립하는 것이 옳기 때문이다. 커뮤니케이션의 수단이 자발적으로 선택되어야지 누군가에 의해 강요되는 것은 바람직하지 않다고 생각한다.
과거 플로우 차트를 대신하여 한국형 순서도 쎄크(SEC)가 소개되던 때가 생각난다. 만약, 글로벌한 환경에서 쎄크를 가지고 공조 작업을 할 수 있을까? 물론, 가치와 의의면에서 해당 차트를 폄훼할 생각은 없다. 하지만 커뮤니케이션으로서의 수단으로 적합한지의 여부와 그 선택에 있어서는 고민해 볼 필요가 있다고 생각한다. 어떤 차트도 국제표준이 되지 못하는 이상 그 의미는 크게 퇴색될 수 밖에 없다고 생각하기 때문이다. 그런 의미에서 UML 1.4.2 의 경우 ISO/IEC 19501 로 인증되어있어 어느 곳에서 사용함에 있어 문제가 될 부분이 없다.(사실 UML 2.0 은 이런 부분 때문에 적용하지 않고 있다.)
각 산출물에 대한 자세한 설명은... 책을 출판할 것도 아니고해서 그냥 이 정도 수준에서 마무리할까한다. ^^ 다음 글은 초기 물리 설계에 대한 이야기를 해볼까한다.
반응형
'개발일지 > 아키텍트' 카테고리의 다른 글
| GoF, Command 패턴 (0) | 2012.02.08 |
|---|---|
| POSA, Forwarder-Receiver 패턴 (0) | 2012.01.31 |
| POSA, Whole-Part 패턴 (0) | 2012.01.30 |
| 나의, UML 객체지향 설계 - 3 - (0) | 2011.12.20 |
| 나의, UML 객체지향 설계 - 1 - (0) | 2011.12.16 |
댓글