목요일, 1월 18, 2018

좋은 기술적 결론에 대한 판단 방법

오랜 SW 연구개발 경험 상 나름 이런 감(symptom)의 원칙이 있다.

원래 시스템 소프트웨어란 건 wicked problem이어서 완벽한 정답이란 건 없고 enough한 시점에서 결론을 내려야 한다.
하지만, 좋은 답이란 것은 약간의 징후가 있다.

'계속 고민하던 기술 문제의 직접적인 연장선에서 내려진 결론이라면 창의적인 결론이거나 멋진 결론이 되기는 어렵다. 계속 고민하던 논리의 옆쪽에서 툭 튀어나와 와르르 내려지는 결론이 언제나 아름다운 결론이다'

왜냐하면 직접적으로 추론되는 논리는 아무리 기술적이라 하더라도 누구나 쉽게 추론할 수 있는 것이며 새로운 혁신이 들어가기 어렵다.
straightforward한 건 어려운 기술이라 하더라도 가치가 크지 않다.
그래서 마치 깊이 반복해서 고민하다 옆의 둑이 작은 바늘구멍에서 물이 새어 터지듯 나오는 아이디어가 훨씬 더 나은 답인 경우가 많다.

빅데이터 기술을 처음으로 본격적으로 다루다 보니 근 15년 정도 걸쳐 발전한 기술들을 3주만에 압축적으로 이해하려다 보니 어려움이 많았다.
이 기술들을 들여다보면 놀라운 경우가 많은데 상위 계층으로 갈수록 hype이 섞인 경우가 많다.
새로운 기술을 받아들일 때 나름 스스로 이해의 수준을 판단하는 잣대가 있는데 이것도 일종의 enough와 감이라고 할 수 있다.

'새로운 기술은 그 장점의 이유 뿐만아니라 그 단점까지 볼 수 있을 때 비로소 이해했다고 할 수 있다. 장점만 보이면 그것은 이해한 게 아니라 그냥 시키는 대로 공부한 것이다.'

이것은 critical thinking의 문제이다. 엄밀한 사고란 critical point를 인지할 수 있어야 하고 이 문제를 해결할 때 다른 critical point를 생각할 수 있어야 한다.
이때 system thinking이 중요한데 system이란 layer 간의 혹은 전체와 부분 간의 관계를 유기적으로 파악하는 것이다. 예를 들어 소프트웨어를 시스템적으로 이해한다는 것은 하드웨어 - 운영체제 - 애플리케이션 등의 각 파트를 유기적으로 연결하여 머리 속에서 사고할 수 있다는 뜻이다.
장점만 보일 때는 의사 결정을 할만큼 이해가 된 상태가 아니다. 즉, 공부가 제대로 되지 않은 상태이다. 문제점이 보이고 시스템적 상호 작용 관계들이 이해될 때 비로소 의사 결정에 고려해야 한다.
물론 향후 더욱 기술을 구체적으로 이해하게 될 때 또다른 결론으로 변경될 가능성이 많다. 하지만 의사 결정을 위한 주요한 단계에서는 어느 정도의 변경 가능성을 열어놓을 수밖에 없다. 세부 단계에서 주요 결정 사항이 번복되는 건 어떻게 보면 불가피한 사람의 인지 과정 특성을 반영하는 것이다.

워크샵 도중 가장 놀란 솔루션은 사실 가장 단순한 아키텍처를 가진 Kafka라는 솔루션이었다.
너무 단순하고 너무 잘 알고 있는 기술이었는데 그 단순함을 끝까지 밀어부쳐 새로운 패러다임을 만들었다.
알고 있는 기술에서 아주 작은 변화였는데 말이다.
단점들도 많지만 그것은 사용하는 쪽에서 알고 쓰면 된다는 방식으로 풀어버렸다. 그것 또한 멋진 아이디어라고 받아들였다.

어젯밤 멋진 아이디어를 함께 한 친구가 냈다. 그리고 오늘은 약간의 잔 아이디어들을 붙여 큰 그림을 마무리했다.

이렇게 '아름다운 결론'을 팀웍으로 함께 만들 수 있다.