The Last Mind

Captain's Log

Monthly Archives: December 2008

Flex

18 December 2008 by Joseph Jang

Silverlight  2에 관한 글에서, 팀 내에서 Flex를 사용해 개발된 애플리케이션이 있다고 언급한 적이 있다. 이 후로, 팀 내에서 복잡한 데이터를 보여 주기 위한 애플리케이션을 만들 때 Flex를 사용하기 시작했고, 추가적으로 무려 3개의 애플리케이션이 더 만들어 졌다.

이렇게 팀 내에서 많이 사용하기 시작한 기술이기도 하지만, Silverlight 2의 경쟁 상대가 Flex이다 보니 그 동안 Flex에 대해 자세히 알고 싶은 바램이 있었다. 운이 좋게도, 얼마 전 회사에서 Flex에 대한 교육이 추가로 실시된다는 소식을 듣고 바로 신청해 들을 수 있었다.

첫 번째 느낌은 Silverlight와 Flex은 본질적인 차이라고 말할 만한 것이 거의 없다고 말할 수 있을 정도로 유사한 기술 스택과 기능 들을 가지고 있다는 것이다.

  • Markup과 Programming Language, 공통적으로 배포되는 런타임을 통한 애플리케이션 구현
  • Container 개념과 기본적으로 제공되는 Control들
  • Layout 메커니즘
  • Event 개념
  • Style 개념
  • 기존의 Control을 확장하는 메커니즘과 Custom Control 작성
  • 외부 데이터를 사용하기 위한 라이브러리 지원
  • 웹 애플리케이션과 데스크탑 애플리케이션 작성

두 번째 느낌은 Silverlight나 Flex 모두 전통적인 UI 프레임워크로서의 방식을 따르고 있다는 것이다. 아마 HTML과 XML이 성공한 후에 도입되기 시작한 사용자가 작성하는 UI Markup 개념은 제외해야겠다. 이 외의 개념들은 모두 GUI가 보편화된 이후에 생긴 MFC, Swing 등의 프레임워크와 같은 방식과 요소들에서 익숙하게 봐 왔던 것들이다.

Silverlight나 Flex 자체는 하위 수준의 프레임워크로서 Document-Model이나 MVC와 같은 방식을 강제하는 정도의 수준은 아니다. 그러한 상위 수준의 프레임워크는 외부에서 착실히 만들어 지고 있다.

NHN의 사내 기술 교육은 아직 다양하지는 않지만, 경험이 많은 실무자가 교육을 하다 보니, 교육의 만족도가 상당히 높은 편이다. 단순히 웹에서 문서를 보거나 책을 보고 따라 하는 수준을 넘어서는 경험에서 우러나오는 지식이나 팁과 같은 것을 얻을 수 있다.

강사 분도 말씀하셨지만, Silverlight나 Flex나 전반적으로 어떠한 요소들을 가지고 있는지 이해하는 것이, 이 기술들을 배우기 시작하는 데에 중요한 요소다. 세부적인 사항들은 단기간에 배우기 보다는 실제로 사용해 보면서 익힐 수 밖에 없기 때문이다.

웹 시대를 살아가는 개발자로서, Silverlight든 Flex든 튜토리얼이나 책, 좋은 강의로부터 배울 기회가 생긴다면 간단한 애플리케이션을 만들 수 있을 정도로는 익혀 두는 것이 좋다고 생각한다.

Comments Off | Categories: Software Development

Dreyfus Model

03 December 2008 by Joseph Jang

모든 관리자의 이상

관리자의 입장에서 가장 예뻐 보이는 동료는 누구일까?

여러 가지 답이 있을 수 있겠지만, 그 중 하나는 아마도, ‘주어진 업무를 수행할 때, 업무의 목표가 무엇인지 정확히 이해하고 수행하는 사람’이다. ‘상위 조직의 목표까지 고려해서, 원래 업무의 방향을 수정하거나, 업무의 우선순위를 조정하거나, 적절한 새로운 업무를 추진할 수 있는 사람’이라면 더할 나위 없을 것이다. 역설적이게도, 어떻게 보면 관리가 필요하지 않은 사람이 바로 관리자의 이상형이다.

세상은 완벽하지 않다. 모든 동료들이 위에서 얘기한 조건을 만족하기란 어려운 일이다.

관리자 M이 보기에 동료 A는 지시하지 않은 세부 사항까지 알아서 척척 처리해, 손이 닿지 않는 곳의 가려움에서 벗어나는 기쁨을 안겨 주는 반면,  동료 B는 완료했다는 일이 처음부터 업무를 처리할 방식을 세세하게 다시 설명해 주어야 할 정도로 엉망이어서, 그 사람 얼굴만 보면 짜증이 나고, 잠도 안 올 정도로 고민거리다.

왜 그럴까? 동료 B는 멍청해서? 게을러서? 여자 친구랑 헤어져서? 에어컨이 고장 나서?

그런 것은 아닌 듯 하다. 동료 B는 업무 시간에 집중해서 성실하게 일하며 책임감도 높다. 여자 친구가 없으니 헤어질 일도 없다. 관리자 M의 옆자리니까 에어컨이 고장 난 것도 아니라는 것을 안다.

업무 경험이 많고 세심한 관리자 M이 보기엔, 한마디로 딱 잘라 말할 수는 없지만, 동료 A와 동료 B와 얘기를 해보면, 둘 사이에는 업무를 대하고 처리하는 방식에는 본질적인 차이가 있다.

관리자 M이 한마디로 딱 잘라 말할 수 없는 것을, 어떤 똑똑한 사람이 딱 잘라 말한 것 중 하나가 바로 Dreyfus Model이라는 것이다.

드라이퍼스 모델 (Dreyfus Model)

드라이퍼스 모델은 철학자 드라이퍼스 (Hubert L. Dreyfus)가 그의 저서 Mind Over Machine의 도입부에서 제안한 기술 습득의 5단계 모델이다1. 요즘 읽고 있는 Andy HuntPragmatic Thinking & Learning의 2장에 소개되어 있다. 이 책의 내용과 Mind Over Machine의 발췌 부분, 전문가 시스템 비판이란 글을 이용해서, 핵심적인 내용만 간단하게 요약해 보자.

Stage 1: Novices

경험이 없기 때문에, 상황에 상관 없이 적용할 수 있는, 다시 말하면, 상황에 따라 적절하지 않을 수 있는, 조리법(recipes) 즉, context-free한 규칙이 주어졌을 때 효과적으로 과업을 수행할 수 있다.

Stage 2: Advanced Beginners

여러 가지 상황에서 의미를 가지는 요소에 대해 인지하게 되고, 이러한 요소를 context-free한 규칙에 더해서 활용하게 된다.

Stage 3: Competent

경험이 쌓이면서, 고려해야 할 요소들이 폭발적으로 증가한다. 불가피하게, 상황 하에서 어떤 요소를 중요하게 고려해야 할 지를 선택한다. 이러한 상황에 대한 모델 하에서, 상황을 분석하고 규칙에 따라 행동을 선택한다. 자신이 선택한 결과 – 성공이나 실패에 대해 책임감을 느낀다.

결과적으로 스스로 문제를 해결(troubleshoot)할 수 있다.

Stage 4: Proficient

Competent 단계에서 경험한 성공과 실패를 바탕으로, 상황에 따라 어떤 요소를 중요하게 고려해야 할 지를 결정한다.

어떤 요소들이 더 중요하고, 어떤 요소들이 무시해도 되는가는 경험이 추가됨에 따라 직관적으로 변화한다. 반면에, 실제로 어떤 행동을 해야 할 것인가에 대해서는 분석적인 사고를 필요로 한다.

Stage 5: Expert

의식적인 사고나 규칙의 필요 없이, 직관적으로 어떤 요소를 중요하게 고려해야 할 지와 어떤 행동을 해야 할 것인가를 안다.

드라이퍼스 모델의 적용

드라이퍼스 모델이 실제로 적용된 것은 간호(Nursing) 분야였고, 자신이 간호사였던 간호 연구자 Patricia Benner가 1984년에 From Novice to Expert: Excellence and Power in Clinical Nursing Practice라는 책으로 정리해 내놓으면서였던 것 같다.

프로그래밍 분야에서 드라이퍼스 모델의 적용에 관한 좀 더 구체적인 예는 Debugging: From Novice to Expert라는 논문에 정리된 다음 표를 참고하면 좋을 듯 하다. (via 드라이퍼스 모델)

debugging

Closing

동료 A와 동료 B의 ‘본질적인 차이’란 무엇인가? 동료 A는 아마도 Competent 이상일 테고, 동료 B는 Advanced Beginner 이하일 것이다. 이것이 ‘본질적인 차이’에 대한 본질적인 대답은 아니다.

드라이퍼스 모델이 제시하는 것은 겉으로는 5단계의 구분이지만, 마치 무협지의 주인공처럼 Novice가 어느 날 갑자기 기연을 얻어서 Expert가 될 수 없다는 사실을 내포하고 있다. 즉, 한 단계 높은 숙련도에 이르기 위해서는 충분한 경험과 고민, 트레이닝, 그리고 그것들을 위한 시간이 필요하다는 것이다.

드라이퍼스 모델이 5단계의 구분에서 제안하는 중요한 요소는 바로 직관이라는 요소다. 인간은 구체적인 경험으로부터 직관을 얻을 수 있고, 이것은 컴퓨터와 같은 기계로 추론해 내는 것은 대단히 힘들다는 것이다. 물론 이것은 인간에게도 쉽지는 않으며, 위에서 언급한 것들을 필요로 한다.

대학교 CS 과정에서 프로그래머의 생산성은 10배 이상까지 차이 날 수 있다는 사실을 배운다. 이러한 사실은 프로그래머라면 누구나 현장에서 느낄 수 있다.

하지만, 관리자로서 그러한 사실을 접하는 것은 완전히 다른 경험이다. 프로그래밍 과업의 결과물의 양적 또는 질적인 차이에서 뿐만 아니라, 업무를 얼마나 깊이 이해하고, 어떤 목표를 추구하는가, 그에 따라 어떤 과정을 선택하는가와 같은 일하는 방식의 문제로까지 확장되는 것이다.

당연하기도 하지만, 실제로 그렇다는 것을 깨닫고 나서 놀랐던 사실들이 있다.

  • 일하는 방식에 있어서의 Competent 이상의 능력을 가진 사람은 정말로 소수에 불과하다.
  • 특정 스킬, 이를테면 코딩 스킬이 뛰어나다고 해서, 반드시 커뮤니케이션 방식에 있어서 뛰어난 것은 아니다.
    즉, 스킬에 따라 숙련도는 다르다.
  • 경력이 오래 되었다고 해서, 반드시 일하는 방식에 있어서 뛰어난 것은 아니다. 반대로, 경력이 짧아도 일하는 방식이 뛰어난 경우가 있다.

개인 간의 차이는 생각보다 컸고, 기대하는 스킬과 실제 스킬의 차이의 간극도 역시 생각보다 컸다.

이제 나의 고민은, 관리자로서, 어떻게 하면 동료들이 한 단계 더 높은 스킬 숙련도에 이를 수 있도록 도와 줄 수 있는 가이다2. 우선, 자신과 함께 일하는 동료들의 주요 스킬의 숙련도가 어느 단계인가 파악해보자.


1 그의 저서나 이 모델에 관한 권위 있는 텍스트를 접해 본 적은 없으므로, 정확히는 알 수 없지만, 이러한 모델은 과학적인 검증을 거쳤다기 보다는, 인공 지능의 한계를 지적하기 위한 논의를 진행하기 위한 개념적인 모델일 뿐인 것으로 보인다.

2 Andy Hunt의 책에서도 언급하고 있지만, 모든 팀원이 Competent 이상의 단계가 되어야 할 필요는 없다. Andy Hunt는 숲을 보는 사람이 있으면, 나무를 보는 사람도 있어야 한다고 얘기한다. 나도 그러한 생각에 동의한다.

Comments | Categories: Management, Software Development