Altruistic Programmer's Blog (KR)

올해 하반기 6개월동안 스크럼으로 프로젝트를 진행했습니다. 온라인 게임을 위한 라이브러리를 만드는 프로젝트였고, 개발자는 한국인이 4분, 일본인이 1분 참가했네요.

회사에서는 개인별 성과평가를 원하는데, 스크럼에서는 평가와 관련된 가이드가 적어서 고민이었습니다. 개인별 성과를 평가한다는 것의 의미, 목표, 효과는 스크럼의 철학과는 반대되는 것이었지요. (이 부분은 아래 부록에서 설명) 그래도 왠만한 회사에서는 개인별 성과평가를 원할테니 선배님들의 노하우가 있지 않을까하고 Xper 뉴스 그룹에도 질문을 드렸습니다.

어쨌든 반기가 시작하기 전에는 평가방식을 공유, 합의할 필요가 있었으니, 아래와 같이 정해봤습니다.

모두가 같은 평가를 받는 것은 너무나 아름다운 시나리오라는 생각이 들었습니다. 개발자분들이 싫어하지 않을까 걱정했지만 모두들 아무런 이견없이 잘 받아들여 주셨습니다. 착하고 능력있고 잘생긴 분들을 만난 제 복이라고 생각해야겠지요. ㅎㅎ

MVP를 뽑는 것은 혹시나 있을지 모르는 어뷰징, 혹은 사기저하를 방지하기 위한 장치였습니다. 평가방식의 허점을 노려서 놀고먹는 개발자가 생기거나, 엄청난 공헌을 한 개발자에게 실망을 안겨주는 상황을 막아보자는 의도였습니다.

2009년이 저물고 평가의 시간이 돌아왔습니다. 이제와서 돌이켜보니 모두 동일한 평가를 받기로 한 것은 참 잘한 일이었습니다. 내 일, 네 일 가리지 않고 모두가 다같이 열심히 해왔기 때문이지요. 누가 더 잘했고, 누가 더 못했고를 따지기에는 사람과 사람의 역학관계가 너무나 복잡하다는 생각이 들었습니다.

설사 어뷰징이 일어나서 누군가 팀에 폐를 끼쳤다고 해도, 이런 평가 방식 때문은 아니라는 걸 깨달았습니다. 기존의 평가방식이 반년을 돌이켜보며 누구는 잘했으니까 칭찬해주고 누구는 못했으니까 야단치는 식이었다면, 스크럼의 방식은 잘못한 그 시점에 피드백을 주고 잘 할 수 있도록 격려해주는 식입니다. 다시 말해, 잘못하는 것 지켜보다가 나중에 혼내는게 아니라, 바로 지적해주고 올바른 방향으로 이끌어 주는 식입니다. 반년 후에 모두가 칭찬받도록 만드는 방법입니다.

그래서인지 MVP를 뽑는 것은 괜히했다는 생각이 들었습니다. 다들 열심히 했으니 MVP라고 부를만큼 눈에 띄게 공헌한 개발자도 없을뿐더러, 이런 상황에서 도토리 키재기로 1등을 뽑는게 팀웍을 훼손할 수도 있겠다 싶었습니다.

MVP 선출방식을 미리 정해두지 않았다는 점도 큰 실수였습니다. 평가 시즌이 되어서 평가 기준을 바꾸는 건 말이 안되는 일이니까요. 그래도 어찌어찌 논의를 통해서 선출방식을 정하고 투표를 진행했는데, 신기하게도 5명 모두 동률로 1등이 되어서 모두가 MVP가 되는 사상초유(처음 했으니까요-_-;;)의 사태가 발생했습니다. 다행이 큰 출혈없이 MVP 투표를 마감할 수 있었습니다.

역량레벨은 회사에서 각 개인별 역량을 정의해 놓은 레벨입니다. 회사마다 이름은 달라도 이와 비슷한 시스템이 있어서 연봉 테이블에 영향을 준다던지 하고 있지요.

똑같은 일을 해내더라도 역량레벨이 낮은 사람은 더 높은 평가를 받아야 한다던가, 성과평가가 역량레벨 재조정의 근거자료로 쓰인다던가, 실제 역량에 맞지않는 역량레벨을 가지고 있다던가 하는 복합적인 문제가 있습니다.

스크럼 마스터를 대상으로 작성된 글이지만 스크럼의 철학과 기존의 평가 시스템의 충돌을 이해하는데 많은 도움이 되었습니다. 여기서 간단히 내용을 소개하고, 제 견해를 살짝 붙여보겠습니다.

스크럼 책을 처음 읽고 팀에 소개하기 위해서 만들었던 초간단 PT입니다. 조금 꾸질꾸질하지만 참조해주세요~

[옛날 블로그 글입니다. 2009.05.30]

저번에 구글 테스팅 블로그의 아티클을 소개하는 MVC vs MVP라는 글을 썼는데요. 구글에서 소개하는 MVC와 MVP의 구분이 생각하던거랑 다르기도 하고, 사실 저도 잘 모르겠고 해서 공부를 해봤습니다. 아주 재미있는 공부였구요, 간단한 정리와 참고 자료를 공유하겠습니다.

아, 마틴 파울러 아저씨의 말이 참 공감이 가는데요. 아키텍쳐를 이해하는 것은 어렵다는 점입니다. 이 글도 대략의 이해를 위한 글 정도로 읽어주세요 ^^

UI 관련 패턴으로서 가장 많이 언급되면서도, 가장 많이 오용되는 용어라고 합니다. 우선 역할 정리부터.

Model : 도메인 데이타 및 관련 로직.
View : 도메인 데이타를 화면에 표시하는 담당. UI 컨트롤 및 UI 로직. Model에 직접 접근.
Controller : 사용자의 IO 입력 (마우스/키보드)을 처리하는 담당. Model에 직접 접근.

Smalltalk-80에서 처음 등장했는데요, 이 당시는 화면 표시와 사용자의 입력 처리가 별개의 일이였다고 합니다. MS Windows가 나오면서 UI Control(Widget)이 화면 표시와 사용자 입력 처리를 동시에 해버려서, 원조 MVC를 적용하기 어려워 졌답니다. 그러니 요즘의 프로그래밍 환경에서 MVC를 사용한다는 건 좀 안맞는 말이죠.

우선 MVP를 보고 더 얘기해보죠.

MVP의 원조격인 Taligent MVP는 지금의 모습보다 많이 복잡하더군요. 어쨌든 MVP 패턴이 가장 대중화 된 것은 돌고래 스몰토크에서 구현한 MVP랍니다. 역할을 보면.

Model : 도메인 데이타 및 관련 로직.
View : 도메인 데이타를 화면에 표시하는 담당. UI 컨트롤 및 UI 로직.
           사용자의 입력을 Presenter로 위임.
           모델에 직접 접근할 수도 있음.
Presenter : Model과 View 사이의 중재자. 복잡한 UI 로직. 모델에 직접 접근.

MVC에 비해서 View의 역할이 대폭 줄어드는데, View의 구현방식에 따라 역할의 범위가 달라질 수 있습니다. 최소의 경우라면 Model에 대한 접근을 전혀 하지 않고, 유저의 입력은 바로 Presenter에게 넘겨주기만 합니다. 그리고 Model의 변경사항을 View에 적용하는 것도 Presenter가 모두 합니다. 이것이 마틴 파울러의 Passive View 패턴이랍니다.

반면에 View가 Model의 변경사항을 스스로 적용하는 경우도 있는데, 이것이 마틴 파울러의 Supervising Controller 패턴이랍니다.

하지만 중요한 것은 패턴의 이름이 아니라, 구현방식에 따라서 역할이 조금씩 변할 수 있다는 점이겠죠.

놀라운 사실 한가지는 MVC  패턴이 자주 오해되고 있다는 점입니다. 예를 들어, 돌고래 스몰토크에서 언급되는 MVC는 Smalltalk-80의 MVC가 아니라 VisualWorks의 MVC를 말하는 것인데, VisualWorks에는 Application Model( Presentation Model과 유사 )이라는 개념이 있어서 Model을 감싸는 또 하나의 Model이 있습니다. 원조 MVC와는 좀 다르죠.

Smalltalk-80의 MVC를 기준으로 본다면 크게 '화면 표시와 입력 처리의 분리', 'Observer 패턴을 통한 UI 처리와 도메인 모델의 분리'가 가장 큰 특징이라 할 수 있겠습니다.

돌고래 스몰토크의 MVP를 기준으로 본다면 'Model과 View를 중계하는 Presenter', 'Observer 패턴을 통한 UI 처리와 도메인 모델의 분리' 가 큰 특징이라 할 수 있습니다.

Passive View 패턴의 MVP라면 View가 아무런 로직도 갖지 않고 모든 것을 Presenter에 위임하는데요 테스트의 편의성을 위해 발전된 것이라고 합니다. Presenter를 테스트 하는 것 만으로 충분히 테스트가 되니까요. 구글 테스팅 블로그의 아티클에서 MVP 사용을 권장하는 것도 같은 맥락입니다.

다만 구글 테스팅 블로그의 아티클에 나오는 그림에는 일부 논쟁의 여지가 있기는 합니다. 아티클에 나오는 MVC 그림은 사실 Supervising Controller 패턴의 MVP를 닮았구요,  MVP 그림은 Passive View 패턴의 MVP의 모습입니다. 하지만 MVC 그림의 경우에는 저도 그다지 어색하지 않았는데요, 그런 식으로 왜곡되어서 널리 퍼져있는 것 같습니다.

이번에 MVC와 MVP를 공부하면서 좋았던 점은 관련된 패턴들을 더 알게되었다는 건데요. 지면상(?) 간단히만 소개드리겠습니다.

Application Model( Presentation Model ) : 앞에 한 번 나왔죠. 예를 들어서 말이죠, 리스트 박스의 현재 선택된 아이템의 인덱스는 어디에 보관되야 맞을까요? Model? View?

이런 문제를 해결하기 위해 Model을 래핑하는 Model이 등장했습니다. 이 Model은 UI에 대한 정보도 좀 알고 있기 때문에 Application Model 혹은 Presentation Model이라고 불리는데 조금은 차이가 있답니다.

Hierarchical MVC : MVC가 계층적인 구조를 이루는 것인데요. 일반적인 UI이라면 보통은 계층 구조를 이루게 되죠. 제가 저번 글에서 애플의 코코아가 MVC(MVP)를 잘 쓰는 것 같다고 했는데요, 바로 이 Hierarchical MVC라고 말하는게 맞을 것 같습니다.

하지만, 이름과는 달리 실제로는 MVP 패턴을 사용하구요, 계층적이다보니 Presenter들 간의 통신이 필요해집니다. 바로 이부분이 제가 감명을 받은 부분이기도 하구요 ㅎㅎ

Presentation-Abstraction-Control : 요건 Hierarchical MVC하고 비슷하게 보여서 종종 연관되고는 하는데요, 사실은 근본 동기부터가 틀립니다. UI를 위한 패턴이 아닌 전체 어플리케이션의 아키텍쳐를 다루는 패턴이고, 인간의 인식 구조를 기반으로 구성했다는 것이 존경스럽네요. 저도 잘은 모르니 링크 봐주세요.

'바퀴 재발명 하기'라는 말이 있죠. 누군가 이미 잘 만들어 놓은 것을, 다시 처음부터 만들고 있는 상황을 말합니다. C++ 개발자는 특히나 바퀴를 재발명 할 일이 많은데요, 심지어는 UTF8 형식의 문자열을 다루는 표준 클래스도 없기 때문이죠 -_-;; ( 다음 표준에 생긴답니다 )
(Update. 다음 표준에 UTF8, 16, 32를 위한 리터럴이 생기고, UTF16, 32를 위한 타입이 생긴다고 합니다. UTF8은 여전히 const char* 에 저장한다는 것 같습니다. )

리스트 박스의 현재 선택된 아이템의 인덱스는 어디에 보관되야 맞을까요? 이 고민은 재작년에 한국에서 클라이언트 플랫폼을 만들때 했던 건데, 80년대의 스몰토커들도 하고 있었다니 좀 충격적이면서도 동질감이 형성되는 느낌입니다. 역시 선배님들의 업적을 공부하는 것은 중요하다는 교훈을 얻었습니다. ^^

그럼 오늘도 즐거운 코딩하시고, 위 내용중에 잘못된 것 있으면 알려주시면 감사하겠습니다~

참고 자료
http://ctrl-shift-b.com/2007/08/interactive-application-architecture.html 최고의 아티클입니다.
http://www.martinfowler.com/eaaDev/uiArchs.html 역시 최고의 아티클입니다.
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx MSDN 잡지의 MS식 MVP 소개

[옛날 블로그 글입니다. 2009.05.23]
[이 글은 MVC와 MVP에 대한 명확한 차이를 잘 모르고 쓴 글입니다. -_-;; ]
[MVC와 MVP에 대해 공부를 해서 비교해 놓은 글이 있으니 먼저 봐주세요~ ^^]

제가 좋아하는 구글 테스팅 블로그에 GUI 테스팅의 MVP가 되자라는 글이 있어서요. 좋은 내용이니 한 번씩 읽어보세요. 참 공감가는 얘기입니다.

설명하려면 그림은 하나 있어야겠는데, 구글 블로그에 있는 것 가져오려니 좀 찜찜하고 해서 그려봤습니다.

여기서 화살표는 데이타의 흐름이나 함수 호출이 아닙니다. 의존성이에요. 예를 들어, MVC에서 Model에서 상태 변화 이벤트가 나와서 View까지 갈 수 있지만, Model은 View를 몰라요. 의존성이 없지요. 그런 그림입니다. ( 사실 구글 블로그에 있는 그림이 더 좋아요 ㅎ)

결론은 오른쪽이 좋다는 거구요. 아무래도 의존성이 적으니 좋겠지요. View를 다른데서 재사용할 수도 있고, 유닛 테스트하기도 편하구요. 그런 얘기입니다. 구글 블로그에서 하는 말이요.

저도 참 공감합니다. 한 4년전에 C++로 MVC 기반의 라이브러리를 만들었었는데, 좀 어려웠어요. 자료도 많지 않고, 요새 나오는 언어나 프레임워크처럼 대놓고 MVC(MVP)를 지원하지도 않았구요. 그 이후로도 정답이 뭔지는 잘 몰랐습니다.

그런데, 이번에 애플의 코코아 프레임워크를 보니 MVC(MVP)를 잘 쓰고 있더군요. 그 4년전에 참고했던 돌고래 스몰토크의 구조와 비슷한 느낌이었습니다. 그 때는 잘 몰랐는데 이번엔 좀 알겠더라구요.

이번에 한 생각이 ‘아 View가 생각보다 독립적이어야 겠구나’ 입니다. OS의 커먼컨트롤들 만큼이나 순수하게 독립적이고 재사용하기 쉬운 모습의 View가 되면, MVC에서 겪은 문제들이 많이 없어지겠구나 싶었습니다. 그래서 이제야 MVC를 이해하겠구나라고 생각했었는데, 그게 아니라 MVP라는 이름으로 진화된 녀석이 있었나 봅니다. MVC와 MVP의 비교는 공부좀 해보고 다음 번에 올려보겠습니다~ ^^