An Understanding

초등학교나 중학교에 다니던 시절은 차라리 행복했다. 그가 아무것도 하지 않아도 그를 좋아하고 곁을 지켜주는 사람들이 있었다.

전조는 아마도 고등학교 시절부터 였는지도 모르겠다. 가벼운 말다툼 후 둘은 서로 사과하지 않았고, 졸업 후에 만나서도, 가벼운 인사치레만 나눌 수 있을 뿐이었다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그의 미래에 대해 생각하기도 전에 대학교에 다니게 되었다. 대학교 시절에는 고등학교 친구들도 많았는데, 가장 친한 고등학교 친구 한명에게 실소가 나오는 이유로 주먹을 맞고나서, 그는 그 친구에게 핀잔인 듯한 소리를 했고, 그 친구는 사과했지만, 이후로 그도 그 친구도 원래처럼 대하지 못했다. 그래도, 그는 그 친구를 이해할 수 있었다.

그래도 대학시절 동안 그에게는 어울려 술마시고 함께 어깨동무를 하고 노래부를 대학 친구들이 있었다. 하지만, 대학을 졸업하고나자, 그 중 가장 친한 친구는 졸업 후에 점점 바빠지더니, 가벼운 부탁조차도 들어주지 않는 사이가 되었다. 그에게는 그저 가벼운 부탁이란 건 없었는데도 말이다. 그래도, 그는 그 친구를 이해할 수 있었다.

그에게는 특별한 친구 한명이 있었다. 그 친구는 그에게 지적인 자극을 주었으며, 음악의 기쁨을 함께 해주었다. 하지만, 그런 즐거움은 순간일 뿐이었고, 그 친구는 떠나갔다. 그 친구는 필요할 때마다 그를 찾았지만, 역시 자신이 필요할 때마다 떠나갔다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 직장을 가지게 되었다. 대학 친구들 중 몇몇은 그와 같은 일을 하게 되었고, 전문적인 의견을 종종 나누는 친구들도 생겼다. 하지만 그 친구들은 전문적인 의견을 물어보기 위해서 그와 이야기했고, 그가 뭔가 이야기 하고 싶다고 하면 바쁘다고 했다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 일을 하다가 좋은 동료들을 만났다. 동료들은 마치 친구처럼 그에게 관심을 보여주었고, 그도 그들에게 친구와 같이 마음의 문을 열어주었다. 하지만 그런 동료들도 다른 직장으로 옮기게 되어, 더이상 동료가 아니게 되자, 더이상 그에게 관심을 보이지 않게 되었다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그가 말을 걸 수 있는 사람들이 별로 남지않게되자, 네트웍으로 사람들과 이야기하기 시작했다. 네트웍에는 많은 사람들이 있었고, 그들 중 몇몇은 그와 관심사도 생각도 비슷해서 친구처럼 지낼 수 있었다. 하지만, 그와 그들 사이에는 뭔가 친해지기 어려운 벽 같은 것이 있었다. 그들과 조금 친해졌다 싶어도, 자고 일어나면 그 벽은 다시 자라나있었다. 그러다보면 그들은 저절로 그로부터 멀어져갔다. 그래도, 그는 그 친구를 이해할 수 있었다.

그의 주위에 친구라고 할 만한 사람들이 거의 없어지자, 그는 외로웠다. 그에게는 삶의 목적이 있었고 삶에의 열망도 있었지만, 외로운 삶 자체는 너무 고통스러웠다. 그래서, 그는 자살하기로 마음먹었다. 하지만, 삶에의 열망이 매듭을 묶는 그의 손을 배반하여 그 자살은 실패로 돌아갔다. 그는 정신과 의사를 마주하게 되었다. 의사는 정말 그를 이해한 것 같았고, 그가 살겠다는 의지만 있다면, 그를 돕겠다고 약속했다. 그는 성실하게 의사와 정기적으로 면담을 했고 약도 빠뜨리지 않고 먹었다. 의사 친구가 웃으며 더이상 병원에 오지않아도 된다고 얘기했다. 그 날 이후로 의사는 그에게 아무것도 요구하지 않았고, 그가 요구를 해도 아무것도 받아주지 않을 것 같았다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 일과 친구가 되기로 했다. 그 친구는 말은 없었지만 솔직했고 늘 그의 곁에 있었다. 그는 직장에서 인정을 받았고, 직장 내의 누구나 그를 칭찬했다. 이윽고 그는 은퇴할 때가 되었고, 일이란 친구는 더이상 그가 필요하지 않다고 털어놓았다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 병에 걸렸다. 그는 잠시 생각했다. 이 병이 내 새로운 친구가 되어줄 수 있을까. 그는 알 수 있었다. 이 친구도 언젠가 소리없이 나를 떠나가겠지. 병은 그의 생각을 아는지 모르는지 그를 점점 장악하여 쇠약하게 만들고 있었다. 그래도, 그는 그 친구를 이해할 수 있었다.

병과 싸우는 일은 고통스러웠지만, 의외로 끝은 빨리 찾아왔다. 그와 친구가 되고 싶지는 않다는 투로 의사가 그에게는 이제 몇달의 시간밖에 없다는 것을 알려주었다. 삶도 나를 떠나가는구나. 그는 심한 배신감을 느꼈다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그가 죽어가고 있다는 것을 알 수 있었다. 마지막 호흡이 잦아오는 동안 그는 기뻐했다. 죽음이 그의 새로운 친구이며, 그 친구는 그를 절대 배신하지 않을 것임을 깨달았다. 그는 후회했다. 그가 죽음과 친구가 될 수 있었을 때, 왜 삶을 한번 더 믿었던가를. 그가 눈을 감을 때, 그 친구는 속삭였다. 그가 삶을 살지 않았더라면, 나라는 친구가 얼마나 좋은 친구인지를 깨닫지 못했을거라고. 그제서야, 그는 그 친구를 이해할 수 있었다.

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 부서의 문화에 따라 그 방식이 많이 달라질 것 같다.

궤변론자의 합리성

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