Someone to inspire us

“If our job teaches us anything, it’s that we don’t know what the next President’s gonna face. And if we choose someone with vision, someone with guts, someone with gravitas, who’s connected to other people’s lives, and cares about making them better; if we choose someone to inspire us, then we’ll be able to face what comes our way and achieve things we can’t imagine yet. Instead of telling people who’s the most qualified, instead of telling people who’s got the better ideas, let’s make it obvious. It’s going to be hard.” – Toby Ziegler, West Wing Season 4 Episode 1: ’20 Hours in America’

Software Complexity

생물학자 줄리언 헉슬리(Julian Huxley)는 1912년에 복잡성을 ‘부분들의 이질성’이라고 정의했는데, 이는 일종의 기능적 불가분성을 뜻한 것이었다. 만들어진 신, 리처드 도킨스

어떤 일을 할 때는 항상 그 일에 맞는 ‘생각의 틀’이 필요하다. 최근 4개월 가량 소프트웨어 개발에서 완전히 손을 떼고 있었고, 그 생각의 틀을 조금씩 회복하는 중이다. 그러던 중 읽은 복잡성에 관한 정의는 내가 지금 겪고 있는 소프트웨어 복잡성의 문제를 떠올리게 해주었다.

복잡성에 관한 얘기를 할 때, 소프트웨어의 복잡성은 흔히 생물의 복잡성과 함께 취급되곤 한다. 물론, 생물의 복잡성은 소프트웨어의 복잡성에 비교할 수 없을 정도지만, 소프트웨어의 복잡성에 대한 일반인들의 관용은 생물의 복잡성에 대한 관용보다 높지는 않을 듯하다. 하지만, 소프트웨어 엔지니어 입장에서 복잡한 소프트웨어를 바라보았을 때 ‘손을 댈 수도 없다’는 그 심정은 생물을 다루는 연구자나 중환자의 몸을 다루는 의사의 심정과 크게 다르지 않으리라고 생각한다.

소프트웨어 복잡성의 문제는 다른 과학이나 공학과 마찬가지로, 환원, 특히 기능적 환원으로 해결하는 것이 기본이다. 복잡한 소프트웨어는 하나의 부분을 이해하거나 고치기 위해서는 그 부분과 기능적 불가분의 관계에 있는 여러 부분들을 동시에 이해하고 고쳐야한다. 환원 과정을 통해 프로그래머가 신경써야할 거리를 분리함(separation of concern)으로써, 프로그래머는 한번에 하나의 부분만을 다른 부분과 관계없이 신경쓸 수 있다. 소프트웨어에 있어서는 이러한 과정을 decomposition또는 모듈화(modulization)이라고 부른다. 소프트웨어가 만들어지고 나서 수행하는 decomposition을 특히 리팩토링(refactoring)이라고 부르기도 한다.

생물과 소프트웨어의 또다른 유사성은 바로 계속 변화한다는 것이다. 그리고, 생물이 진화할 수록 그 복잡성이 높아지는 것처럼 (진화의 방향이 항상 복잡도가 높아지는 방향인 것은 아닐테지만, 적어도 현재까지의 생물사에서는 그러했던 것 같다.) 소프트웨어도 성장할될 때마다 복잡성이 높아진다. 생물의 진화는 인위적인 것이 아니므로 복잡성을 ‘해결’할 필요가 없지만, 소프트웨어의 변화에는 (아직은) 인간의 지적인 능력이 필수적이므로, 복잡성은 소프트웨어가 더이상 성장하는 것을 막는 요인이 되고, 심지어는 소프트웨어의 생명을 짧게 만드는 요인이 되기도 한다. 따라서, 소프트웨어가 오랫동안 성장하기 위해서는 복잡성을 일정 수준 이하로 항상 유지시켜야 하고, 이를 위해서는  decomposition에 더욱 많은 시간을 들이고 자주 해야한다.

소프트웨어 복잡성을 해결하는 과정 못지않게 그것을 인지하는 과정도 중요하다. 복잡성을 인지하지 못하면, 해결하려는 노력을 할 수도 없다. 또한, 복잡성을 인지하지 않고 decomposition을 하려는 노력은 무의미하거나 적어도 비용-효율적이지 못할 수 있다.

소프트웨어 복잡성은 소프트웨어를 만드는 과정 뿐만 아니라 소프트웨어의 결함들을 해결하는 과정 또는 그 원인을 분석하는 과정에서도 인지될 수 있다. 그러한 과정에서 프로그래머가 ‘너무 복잡하다’고 느끼는 것은 복잡성의 첫번째 징표다.

  • 결함 해결 과정에서 너무 많은 부분들이 결함 가능성을 안고 있고 어느 부분에 결함이 있는지 가늠하기 어렵다면 그 소프트웨어는 복잡한 것이다.
  • 결함의 원인이 한 부분만의 결함이 아니라 많은 부분들이 서로 영향을 주면서 발생한 결함이라면 그 소프트웨어는 복잡한 것이다.

복잡성을 훌륭하게 해결한 시스템들을 보면 항상 기능적 분화 뿐만 아니라 발생 가능한 결함 자체를 격리한다. 복잡한 시스템들은 그 부분들간에 너무 많은 기능을 서로 의존하고 있을 뿐만 아니라, 설령 기능은 분리되어있다고 하더라도, 발생가능한 결함들은 분리되어있지 않다.

가만히 생각해보면 소프트웨어 디자인이 해결하고자 하는 주요 문제는 결국 복잡성의 해결이다. 성능과 같은 비기능적 요소들은 제약조건에 불과하다. 이를테면, ‘성능 요건을 xxx만큼 만족시키면서 복잡성을 yyy만큼 해결하는 것’의 문제란 것이다. 대규모 소프트웨어를 높은 수준에서 바라보는 사람은 복잡성에 관한 생각이 반드시 그의 ‘생각의 틀’에 담겨있어야한다.

Monopoly and Innovation

플랫폼이든 데이터든 독점하는 것은 사회적으로 바람직하지 못하다는 생각을 가지고 있고 많은 사람들도 그렇게 (또는 그들은 악하다고) 생각하고 있지만, 현실적으로, 플랫폼 또는 데이터의 독점이 창출하는 수익을 포기하고 불확실한 수익에 리스크를 걸 정도로 멍청하거나 용감한 경영진은, 그리고 그것을 용납할만한 주주들은 드물 것이다. 그리고, 그것이 바로 혁신은 다른 곳에서 이루어지는 (Innovation Happens Elsewhere) 이유일 것이다.

Digital Information Production in 2006

BusinessWeek.com의 기사 ‘So much data, relatively little space’에 따르면, IDC는 2006년에 인류가 생산한 디지털 정보는 161 exabytes라고 추정했다고 한다. Berkeley의 연구에서 추정된 2003년의 수치는 5 exabytes 이었던 반면, IDC는 2010년의 추정치를 988 exabytes (~1 zettabyte)로 보고 있다고 한다.

저장 용량 대비 저장 장치의 가격은 쉬지 않고 떨어지고 있지만, 저장할 정보의 크기도 커지고 있다. 이러한 추정치와 저장 장비들의 가격을 통해서 정보의 저장에 관한 단기적인 예측이 가능할 것이다. 이를테면, 다음의 문제를 생각해보자. 정보의 크기는 커지고 있지만, 당연하게도 그 가치가 크기에 비례하는 것은 아니다. 저장 기술을 발전시켜서 모든 정보를 저장할 것인가, 아니면, 정보의 가치를 측정할 수 있는 기술을 발전시켜서 불필요한 정보를 저장하지 않을 것인가. 이러한 거시적인 저장 전략은 저장 기술의 진로에 따라 영향 받을 것이다.

물론, 이러한 종류의 예측들은 여러 기관들에서 내놓고 있지만, 공짜는 아니어서 접근하기가 용이하지 않다. 한편으로는, 이러한 예측들을 기관에 의존해야만 하는가 하는 생각도 든다. 이런 종류의 예측을 위해 정보를 수집하려면, 필연적으로 시간에 따른 정보의 조회가 필요한데, 아직 웹과 같은 공공 정보는 시간에 따른 정보의 조회에 적합하게 구조화되어 있지 않다. 대중을 위한 웹기반 정보 서비스는 일반적으로 시간에 따른 정보 제공이 불필요하다. 필연적으로 시간에 따라 구조화된 정보를 소비하고자 하는 사람은 초기에는 어느 정도의 비용을 치루어야만 할 것이다. 하지만, 모든 산업이 그렇듯이 정보의 소비비용은 점점 저렴해질 것이고, 시간에 따라 구조화된 정보의 소비도 오늘날의 웹과 같이 공짜로 개방될 것이다.

Read The Fucking Manual

예전엔 매뉴얼에서 쉽게 찾아볼 수 있는 단편적인 사실을 물어볼 땐 RTFM이라고 대답하는 것이 일종의 농담처럼 여겨졌지만, 사실은 옳은 방식이다. RTFM을 알고 있어도 그것을 자신의 습관으로 굳히기에는 쉽지 않아보인다. 그것이 바로 단편적인 사실을 물어보는 것에 RTFM이라고 ‘대답해주어야’ 하는 이유다.

같은 이유로 신입자의 문제를 도와줄 때는 모든 답을 제공해주어서는 안된다. 물론, 그렇다고 해서 영원히 시지프스의 노역을 하고 있는 것을 두고보라는 얘기도 아니다. 문제를 해결할 수 있는 길을 보여주고 조용히 지켜봐주는 것이 바로 멘터의 중요한 역할이다. 물론 그 첫걸음은 바로 RTFM이다. (요즘은 ‘Google it’이지만.) 또는, 키가 되는 중요한 사실 하나만을 알려줄 수도 있을 것이다. 이런 식으로, 신입자에게 문제를 해결하는 방법을 익히게 해줄 수 있을 뿐만 아니라, 신입자의 능력 또는 지식을 파악하고 무엇을 가르칠 것인가를 알 수 있다.

사람들이 배우는 방식은 사람들마다 차이가 있다. 어떤 사람들은 단편적인 사실을 배우는 것에만 집착하고, 그것을 어떻게 배워야하는가는 신경쓰지 않는다. 어떤 사람들은 어떻게 배워야하는가를 알려주면, 나머지는 스스로 알아서 배우려고 한다. 단순히 열정의 문제가 아니다.

A Conversation Interrupted

일반적으로 인간은 Context Switching에 익숙하지 못하며, 그렇게 해야만 하는 경우, 실수를 하거나 비효율적이 되기 쉽다. 회사에서 있었던 일이다. (내게 회사 말고 달리 심각한 사회적 관계가 있겠는가) A와 업무를 대화를 하고 있던 중에 대뜸 B가 자신의 업무를 해결하기 위해 다가와서 A와 대화를 시도한다. 덕분에 나는 멀뚱멀뚱 가만히 있어야하는 상황이 되어버린다. 나는 다른 업무로 돌아갈 수도 없다. 아니, 이메일, 메신저와 같은 비동기적인 통신 방법은 두었다가 무엇하는가.

한국 IT 블로거스피어의 비생산적인 추측

최근 들어, 한국 IT 관련 블로거스피어(blogosphere)에서 소위 어피년 리더 (opinion leader)라고 할 수 있는 사람들마저, IT 업계에 대한 비생산적인 추측을 블로그 글로 쏟아내고 있는 것 같다. 블로그 글은 기존 대중매체 상의 언론에 비해, 정확성 등에서 느슨해질 수 있기 때문에 얻어질 수 있는 이익도 많지만, 그 반대도 확실히 존재한다. 이런 문제의 해결은 어디까지나 블로거 개개인의 규범(indivisual discipline)에 호소할 수 밖에 없다.

덧붙여, PR에는 별로 관심이 없지만, 회사의 입장에서는 회사에 불리하면서도 잘못된 추측이 돌아다니는 것에 대해서 어떻게 대응할까 궁금하다. 아마도 회사 또는 그 회사 PR 부서의 문화에 따라 그 방식이 많이 달라질 것 같다.

궤변론자의 합리성

바보를 속이는 일은 쉽다. 지혜롭지 못한 사람을 속이는 일도 어렵지 않다. 설령 어떤 사람의 주장이, 얼마간은 진리에 의존하고 상당히 합리적인 논증 과정을 가지고 있다고 하더라도, 참인 것은 아니다. 지혜로운 사람은 그러한 주장에서 잘못된 전제들과 가정, 비합리적인 논증을 발견해낼 수 있지만, 그렇지 못한 사람들은 자신의 무지함과 무능력은 보지못하고, 궤변론자의 합리성을 시종처럼 뒤따를 뿐이다.