일단, 오전 발표 전체보다는 발표에 앞서 김창준씨가 Kent Beck을 소개하면서 했던 이야기 중 개인적으로 생각해볼만한 부분이 있었다. "단순성에 대한 집착" 이라는 얘기였는데, "단순한 아이디어를 극단적으로 적용하는 실험"을 언급했다. 내 경우는 트레이드오프에 대한 계산을 상당히 일찍 하는 편이라서, 그러한 무식함(?)으로부터 얻을 수 있는 통찰을 종종 놓치기도 했다. (생계형 프로그래머의 비극일까) 하지만 서비스 코드에 극단적(?) 실험을 하는 것이 바람직한 일이라는 생각은 들지 않는다. 그래서 항상 머릿속으로 충분히 납득할 수 있을때까지 상상해보는데, 역시 현실은 언제나 상상과 다르다. 그 과정에서 많은 것을 배우긴 하지만.
오전의 이야기는 듣다가 잠시 졸아버렸는데, 별 특별한 얘긴 없었다. '자신이 어떻게 하는지를 관찰' 하는 것에 대한 얘기 정도가 주목할만한 내용이었다. 그는 자신이 디자인을 추가할 때 했던 생각들을 카드에 적어놓고 그것을 다시 분류해서 4가지 정도의 디자인 전략으로 정리를 했다고 한다. 이 얘기는 오후에 자세히 다루어졌다.
오후에 발표된 내용들은 오전보다는 나았다. 그 중 개인적인 통찰을 얻은 것들을 정리하면 다음과 같다.
Latency, Throughput, Varience 중 어디에 초점을 맞출 것인가 하는 질문은 나름 유익했다. 어쩌면 당연한 답이기도 한데, 해당 분야의 성숙도나 기회비용에 따라 다르다. 지역 최적이 전체 최적이 아니라는 얘기는 이미 많이 다루어진 바 있다.
바둑의 사례를 들면서 Ambiguity, 즉 모호성을 수용하는 것의 중요함을 이야기했다. 무언가를 어떻게 해야 할지 알 수 없다면, 일단 그대로 두라는 것. 이미 지나치게(?) 하고 있던 부분이라 별 걱정은 되지 않는다. 명료한 디자인은 해결해야 할 문제 집합 속에서 드러나므로 당연한 얘기이기도 하다. 오히려 더 많은 이들에게 중요한 문제는, 모호성 속에서 명쾌하고 간결한 해답이 드러난 시점에 이를 전체 디자인에 반영할 시간을 조직적 합의속에서 어떻게 이끌어낼 수 있을까 하는 부분이 아닐까. 의지를 가진 사람들이 개개인의 노력과 헌신으로 진행하다가 지쳐서 쓰러지는 지점이기도 하다.
디자인에 대한 정의는 아주 명료하고, 곱씹을만했다. 항상 그렇듯 너무나 당연한 단어들의 집합인데, 명료하게 드러난 정의는 역으로 그 정의를 실현하는데 상당한 도움을 주기 때문에 매우 유익하다.
Kent Beck은 디자인을 이렇게 정의했다.
< Beneficially Relating Elements >
결국 Design이란 서로 이익이 되도록 요소들을 관계짓는 것이라는 이야기이다. 디자인상의 고민에 부딪혔을 때, 이 화두를 다시 꺼내들고 곱씹어볼만한 가치는 충분하다는 생각이 들었다.
좀 더 정확히는 아래와 같이 얘기했다.
Design is beneficially relating elements.
Designing is beneficially relating elements.
이 두 문장을 이야기 했습니다. 첫번째에서 beneficially relating은 elements를 꾸며줍니다.
elements가 relating의 주어인 셈이죠. 즉, 결과로서의 디자인은 이로운 관계의 요소들이라는 말입니다. 두번째에서
elements는 relating의 목적어입니다. 과정으로서의 디자인은 요소들을 이롭게 관계 맺는 행위이다 라는 말입니다.
- 김창준님의 Xper group의 토론 내용 답변 중에서
결합과 응집에 대한 얘긴 특별히 새롭지 않으므로 패스.
그 후에 다루어진 것이 이번 발표의 중심 내용인 디자인 추가의 4(+1)가지 전략이다. 디자인을 추가할 때는 다음 4(+1)가지 중 한가지 패턴을 따르게 된다고 한다.
- Leap - 도약
- Parallel - 병렬
- Stepping Stone - 징검다리
- Simplification - 단순화
- ( Add it anyway - 어쨌거나 일단 구현하기 )
각각을 설명한 뒤 자신이 최근에 경험했던 4가지 패턴에 해당하는 사례들을 각자 논의해보라고 했다. 그리고 자신이 어떤 디자인을 할 때, 저 네가지 중 어느쪽에 속하는지를 생각하는 연습을 해보라고 했다. (잘 못 들은 게 아니라면) 하지만 잘 납득되지 않는 것이, 저 네가지 전략은 선택한 다음 파악하는 게 아니라, 현실적 요구에 의해 저 네가지 전략 중 하나를 선택하는 것이다.
디자인 패턴을 쓸 때도 이 패턴을 써야지 해서 쓰는 게 아니라, 현실에 존재하는 문제의 여러 측면을 고려한 결과로 어떤 패턴을 쓸지가 결정된다. 그게 순서다. 그럼 자신이 현재 쓰고 있는 패턴을 명확하게 인지해야 한다는 것은 무슨 장점이 있을까? 잘 납득이 가지 않아 쉬는 시간에 회사 분들과 얘기를 하면서, 각각의 패턴이 가지는 Pros/Cons 정도를 다시 검토해볼 수 있다는 정도가 아닐까... 라는 추측을 했지만, 썩 납득이 가는 결론은 아니었다.
그리고, Stepping Stone에 대해서는 주변 여러 사람들이 혼란스러워했다. 아마 메타포가 적절하지 않았던 것이 이유가 아닐가 싶은데, 패턴 사용 조건에 대해서는 이렇게 소개했다.
If
- You can't imagine exactly what you want to build but
- You can imagine what would make to the end easier / safer to reach
Build a platform from which your goal is easier to reach
그러면서 framework-first 전략의 사례를 다루었다. 간단히 요약하자면, 정확히 뭐가 필요할지는 장담할 수 없지만, 뭔가 필요할거라고 생각되는 것들을 먼저 만들어놓고 일을 하는 패턴을 말한다. (잘 못 이해했나?) 그런데 Stepping Stone이라는 메타포와 이 설명과는 아무래도 좀 괴리가 있지 않나 싶은 생각이 들었다. 징검다리라 하면 한 발자국씩 디뎌 가는 장면을 떠올리게 마련이어서가 아닐까 싶다.
덧1(@2009-09-06 01:58). Stepping Stone은 징검돌, Stepping Stones는 징검다리이다(김창준님의 지적). 안습인 영어실력 덕분에 둘을 분간하지 못하고 이해해버렸다. orz. 곱씹어 생각하면 역시 좀 느낌이 다르긴 하다. 그래도 역시 좀 더 좋은 메타포가 있을거란 생각은 든다. (나만 헷갈렸던 게 아닌지라.)
그리고 마지막 시간에는 리팩토링에 대해서 다루었다.
extract 와 inline은 항상 역이 존재하므로, 어느 방향으로도 리팩토링 할 수 있어야 한다. 풀어헤쳐서 다시 엮는 과정을 거칠 수 있다. (이 얘기는 좀 뒤에 나왔다.)
변경할 부분을 먼저 고립시켜야 한다. 사실, 구체적인 테크닉으로서는 가장 유용했다. 변경할 라인이 있을 경우, 먼저 그 부분을 extract method를 한 뒤, (그러면 전후관계가 정리되고, 변경 범위가 고립된다) 해당 부분을 수정하고 그 다음에 다시 inlining 할 것인지 말 것인지를 결정한다.
그리고 가장 중요한 원칙 "어려운 변경은 하지 않는다". 이건 확실히 지킬만한 가치가 있다는 생각이 들었다.
그 외에, "객체의 field들은 동일한 수명주기를 가져야 한다. 그렇지 않은 field가 존재한다면 bad smell로 볼 수 있고, 그 field는 다른 곳에 있어야 하는 것이 아닌가 생각해볼 필요가 있다"는 얘기도 유익했다.
감상.
소문난 잔치에 갔다가 굶어죽을 뻔 했다. 오전 9시부터 저녁 5시까지면 책을 2권은 읽을 수 있는 시간이다. (뭐 그렇다고 그 시간을 주면 책을 읽느냐... 라고 하면 그건 음;; )
감상2.
전날 저녁에 Kent Beck과의 만남이라는 모임이 있었는데, 외쿡인 모셔놓고 재롱잔치 한 것 같아서 맘이 심히 불편했다. 뻔히 어떤 대답이 나올지 알 것 같은 얘기들과, 그나마도 연극이라는 형식을 취하는 바람에 심각히 전달력을 잃어버렸다. 덕분에 뻔한 주제와 뻔한 대답이 반복되었다.