지난 4일 애자일컨설팅과 (주)STA컨설팅의 주최로 켄트 벡(Kent Beck)의 초청 세미나가 한국과학기술회관에서 있었습니다. 켄트벡은 XP(Extreme Programming)와 TDD(Test Driven Development)로 유명하신 분으로 한국에는 처음 오신 것으로 알고 있습니다.

켄트벡의 유명세가 있는데 초반에 반응이 좀 뜸하길래 회사 분위기도 살피고 여유있게 있다가 보니 허락받고 신청하니까 대기자로 들어가서 하마터면 못 갈뻔했습니다. 흔치않은 기회였는데... 대기자가 너무 많아서 1일에 추가 세미나로 200명을 더 개최하고 2일전에 대기자차례가 돌아와서 참여하게 되었습니다. 지원은 받기 힘든 상황이라 약간 세기는 했지만 과감히 자비로 비용을 부담하고 갔다왔습니다.


세미나는 켄트벡이 최근에 연구중이라는 "Responsive Design: Wehn, How, and What(반응적 설계: 언제, 어떻게, 무엇을)"에 대해서 진행되었습니다. 말자체로 살짝 느껴지기는 하지만 좀 생소하기는 한 말입니다. Responsive Design.... 켄트벡의 수준이 높기도 하고 그전에 들리는 얘기로도 켄트벡의 세미나는 약간 추상적인 얘기도 많이하고 공부해놓고 가야된다고 해서 어느정도 이해를 할 수 있을지 가기전에 좀 고민되기도 했습니다.




켄트벡 소개 : 내가 보는 켄트벡(김창준)

세미나는 애자일 컨설팅의 김창준님가 켄트벡을 간단히 소개하는 시간으로 시작되었습니다.
먼저 동양과 서양 사람들의 생각하는 방식의 차이가 있다는 얘기를 하셨는데 강아지, 소, 풀 3가지중에서 다른 것을 하나 고르라고 하면 동양사람들은 맥락적인 행위로 판단을 하고 서양사람들은 존재론적으로 생각하기 때문에 동양사람들은 강아지를 고르고 서양사람들은 풀을 고른다는 얘기였습니다. (저는 강아지를 고르게 되더군요. 흠....)

켄트벡이 스스로 꼽은 자신의 키워드는 아래 3가지였습니다.

• 개발자가 작성하는 TEST
• 패턴
• XP (Extreme Programming)
  

TEST는 에릭감마와 같이 만든 소위 xUnit이라고 말하는 테스트 유닛으로 대표되고 최근에는 개발자들에세 테스트프레임워크의 지원이 언어를 선택하는 기준중 하나가 되어가는 분위기라고 합니다. 김창준님은 켄트벡이 GoF보다 더 패턴의 선구자라고 생각하고 있으며 크리스토퍼 알렉산더의 책을 보고 87년 UI패턴에 대한 논문을 썼으며 GoF의 패턴책은 어려운 감이 있는데 켄트벡의 책은 이해하기가 쉬운 편이라 서로 보완적인 관계에 있다고 생각한다고 하였습니다. 마지막으로 XP는 1판과 2판이 책의 내용이 상당히 다른데 1판은 선언문 같은 느낌이 있으면 커뮤니티에서도 "니가 틀렸다"라는 식의 대응을 많이 하였으나 2판부터는 친근해지고 겸손해 졌으며 "내가 잘못한 것 같은데 어떻게 하면 더 잘할수 있을까?"의 식으로 대응하는 경우가 많아졌다고 합니다.


김창준님이 본 Kent Beck는 2가지였습니다.
단순성에 대한 집착 : 터무니 없이 단순한 생각에서 멍청할 정도로 극단적으로 적용합니다.
인간적 성숙을 위한 노력 : 이부분은 XP책의 2판부터 나타나기 시작했으면 "책임감 있는 개발"이란 말을 많이하기 시작했다고 합니다.

마지막으로 세미나를 열린 괄호와 닫힌 괄호에 비교하셨습니다. 닫힌 괄호는 단편(?)적인 지식을 쌓는 것이고 열린 괄호는 명확히 지식적으로 얻은 것은 없는 것 같지만 무언가 해봐야 겠다는 생각이 들게 되는 세미나인데 켄트벡의 세미나는 이런 에너지와 실험으로 이어지는 열린괄호에 가깝다는 것이었습니다.
(30분정도의 짧은 시간이었지만 생각해 봄직한 말들이었습니다. 김창준님은 2년전 P-Camp때 처음 뵈었었는데 그때도 느꼈지만 참 말씀 잘하시더군요.... 부럽;;; ㅎ)





오전 세션
켄트벡의 오션세션이 이어졌습니다.
반응적 설계(Responsive Design)은 책으로 나올 예정인데 "Structured Design"이란 책은 보고 많은 영감을 받았고 여기서 기본적인 내용을 잡았다고 합니다. 이 책의 저자들과 얘기해서 기본적인 것을 바탕으로 내용을 업데이트하고 켄트벡의 생각을 넣어서 새로 만드려고 하는 것이 Responsive Design의 시작이라고 합니다.

디자인이 왜 중요한가 하면 여러가지 증상(Symptom)들이 근본적으로 디자인인 경우가 많습니다. 예를 들어서 테스트하기가 어려워서 더 복잡한 것을 해결할 수 있는 테스트툴을 만들수 있지만 표면적인 증상만 보지 말고 한걸음 물러나서 디자인을 보게 되면 근본적으로는 디자인의 문제인 경우가 많습니다. "어떤 디자인이면 이 문제를 해결할 수 있을까?"라는 고민을 하게 되면 쉽게 증상을 해결할 수 있는 경우가 많습니다. 또한 팀작업의 경우에도 같은 파일의 수정에 대한 문제같은 경우 팀웍의 문제일 수도 있지만 왜 같은 파일을 수정해야 되게 되었는가에 대한 고민을 할 필요가 있습니다. 쉽지 않고 어려운 문제지만 할 필요가 있습니다.


디자인 공부는 아래의 3가지의 초점을 맞추어서 합니다.

Introspectively : 자기반성적으로 내면을 봅니다. 나는 어떻게 하는지... 어떤걸 해보았는지...
Empirically : 경험적으로 잘된 것과 잘안된 것은 인식해야 합니다.
Quantitatively : 정량성

SW에 대해서 생각하기에 적합한 시기인지에 대해서 생각해 볼 필요가 있습니다. 현재 SW 디자인에서 큰 변화가 일어나고 있습니다. 기존에 적용되었던 것이 이제 통하지 않고 있기 때문에 차세대 SW 디자인에 대한 스킬이 필요한 때입니다.

디자인 스킬은 큰 변화가 왔을 때 큰 능력을 발휘합니다.

현재 큰 변화로는

• 무어의 법칙의 종료 : 여태는 SW개발자가 HW성능향상에 중독되어 HW가 향상되기를 기다리면 퍼포먼스문제가 해결되었으나 이제는 그렇지 않습니다.
• Scale : 스케일이 점점 커지고 있어서 디자인으로 해결해야 합니다.
• Cloud : 클라우드로의 이동이 이루어지고 있어서 쉬웠던 것들이 어려워지고 어려웠던 것들이 쉬워지고 있습니다.
• PC-Client : 과거에는 모든 것이 Server에 들어가고 Client는 조악했지만 이제는 상황이 바뀌었습니다.

켄트벡이 개발을 배울때는 마감일에 모든 기능이 완료되면 되는 분위기였습니다. 초기 설계에 70%정도를 투자하지만 실제 사용되는 것은 10%정도에 불과하고 이런 상황은 지금도 꽤 있습니다. 50주짜리 프로젝트면 다 만들어서 50째주에 한번에 모두 Delivery하는데 이것은 좋지 않다. 기능의 꾸준한 흐름(Steady flow of Features)을 유지하면 변경이 용이하고 피드백이 가능합니다.(당연한 얘기이겠지만 이런 부분은 애자일에서 얘기하는 것들과 일맥상통한 부분이죠.) 시간이 지나면 디자인은 달라지게 마련이고 SW에서 제약사항들은 한꺼번에 해결하는 것이 불가능합니다.




효율성
디자인은 효율적이어야 합니다. 효율성은 작은 Scale로 볼수도 있고 큰 Scale로 볼 수도 있습니다. 공장으로 본다면 공장전체는 효율적이지만 기계단위 별로는 효율적일 때도있고 아닐때도 있을 수 있습니다. 효율성외에 초기에 얼마만큼의 디자인 비용이 드는가에 대해서도 고려해야 합니다. 그리고 또하나의 큰 비용은 변화에 대한 비용이기 때문에 이에 대한 부분을 줄이려고 노력해야 합니다. 반응적 설계는 변화에 대한 비용을 줄일 수 있습니다.

설계는 모든 환벽한 정보에 기반해서 하지 않기 때문에 실수에 대한 비용도 있습니다. 또한 현재 하는 일때문에 하지 못하는 것에 대한 기회비용도 있습니다. 프로젝트 초기에는 해당프로젝트의 가능성을 잘 모르기 때문에 기회비용이 클 수 있는데 초기투자를 줄여서 프로젝트가 진행되면서 확실해 졌을때 더 많이 투자함으로써 기회비용을 줄일 수 있습니다. 반응적 설계는 효율은 높이고 비용은 줄이는 것입니다.

디자인할 때는 아래 3가지의 균형이 중요합니다.

• Latency (지연)
• Throughput (처리량)
• Variance (변화)

처리량은 높지만 지연율이 많을 수 있습니다.


어떤 부분에 너무 깊게 관여되어 있으면 시야가 좁아지기 때문에 한걸음 물러나서 큰그림을 봐야합니다.



글이 길어져서 글을 나누어야 겠습니다.
켄트 벡(Kent Beck) 초청 세미나 #2