Stray Thoughts

Delegation

기술적인 논의가 항상 최상의 결론을 내리라는 법은 없으며, 차선의 결론 조차도 낼 수 없는 경우도 있다. 모호하고 복잡한 문제가 아닌, 단순한 기술의 사용 여부와 같은 단순한 문제에서도 서로의 논거가 팽팽히 대립하여 논의가 끝이 나지 않는 경우가 있다. 얼굴을 붉히는 이런 상황에서 흔히 사용되는 해결법은 결정권자-책임자의 결정이다. 서로의 논거가 충분히 합당함에도 불구하고, 서로 논거를 인정하지 않는다는 것은 모종의 불확실성 즉, 리스크가 존재한다는 것이고, 이러한 리스크에 대한 책임을 결정권자가 가져가는 이러한 해결법은 일반적으로 옳다.

하지만, 이러한 논의가 결정권자와 비결정권자 사이의 것이였다면 얘기가 조금 다르다. 끝나지 않는 논의의 해결을 위한 결정권자의 결정이 충분히 합리적이었다고 하더라도, 얼굴을 붉힌 상황에서의 결정권의 행사는 공정하지 못하다는 인상을 주게 마련이다. 그렇다면 결정권자는 어떻게 이 상황을 해결해야할까?

우선, 팽팽하게 대립하는 두 의견은 흔히, 어느 것을 택하더라도 리스크가 크지 않은 경우가 많은 듯하다. 이런 경우에 굳이 결정권자의 강제적인 결정을 통해, 상호 불신의 소용돌이로 빠져들 필요는 없을 듯하다. 리스크로 인한 1 man-day 손실보다 상호 불신으로 인한 1 man-month의 손실이 클 수 있다는 얘기다.

리스크의 간극이 커서, 결정권자의 의견을 선택하는 것이 옳다면, 그것을 충분히 납득시켜야 한다고 생각한다. 얼굴을 붉힌 상태에서 강제적으로 결정하는 것은 너무나 폭력적이다. 만약 정말로 결정권자가 옳고, 상대가 충분한 설명에도 납득하지 못한다면, 그것은 상대방의 문제라고 생각된다.

일단, 상호 불신의 싹이 트기 시작하면, 모든 상황이 나빠진다. 애초에 단순한 논의가 대립하는 것 자체가 어느 정도 상호 불신에 근거하고 있다. 논의 주제에 대한 권위자가 존재하지 않는 상황에서는 더욱 더 심하다. 서로의 경험과 기술적인 숙련도에 대해 파악이 제대로 되지 않은 경우도 많다. 하나의 논의에서 나쁜 감정이 배가된 불신이 생기기 시작하면, 이후의 모든 논의에 있어서 서로의 경험과 논거를 믿을 수 없으므로 – 또는 믿으려하지 않으므로, 서로의 의견을 절대 인정할 수 없다. 심해지면, 경험과 논거를 따지기 전에, 서로의 의도와 감정을 부정적으로 해석하기 시작한다. 가장 심한 것은, 한 배에 탄 다른 사람들까지 한꺼번에 상호 불신의 소용돌이로 끌어들이는 것이다.

반대로, 상호 신뢰란 일의 효율과 성과를 위한 마법과도 같은 것이다. 상호 신뢰에서 나오는 가장 바람직한 행위는 바로 위임이다. 위임이란 결정권자가 자신의 결정권을 조금 나누어주는 것이다. 위임이 어려운 이유는 Chaos와 Control 사이의 밸런스를 맞추는 일이기 때문이다. 결정권자는 Chaos에 이르는 것을 두려워하며, 지식노동자는 Control을 싫어한다. 조직의 특성에 따라 Chaos와 Control 사이의 어느 지점을 선택하느냐가 정해지겠지만, 전통적인 조직들보다 지식노동을 필요로 하는 현대의 조직에서는 좀 더 낮은 Control, 즉 위임이 흔히 강조되곤 한다. 어떤 작은 문제에 있어서는 완벽한 Control이 좀 더 효율적일 수도 있다. 하지만 크게 바라보면, 완벽한 Control을 통해 얻는 조그만 이익은 Control로 인한 손해에 비해 아무것도 아닐 수도 있다. ‘결정권자의 강제적인 결정’얘기도 바로 이러한 맥락이다.

Web Search Engine Startups

우리나라에서도 스타트업들의 웹 검색엔진들이 간혹 나오고 있지만, 검색엔진으로서의 기본적인 품질을 만족하는 것은 매우 드문 것 같다. 블로거스피어를 통해서 잠시 회자된다 하더라도 품질이 뒷받침 되지 않은 유명세는 의미없는 것이다.

검색엔진을 만났을 때 맨처음 해보는 쿼리는 두가지다. 바로 매우 일반적인 표제어에 해당하는 쿼리 – 나의 경우 주로 ‘C++’ – 와 최신성을 반영하는 쿼리 – 오늘 같으면 ‘원더걸스 수능’ 이다. 그리고, 이 간단한 쿼리 두 가지도 무난하게 처리하지 못하는 경우가 대부분이다.

검색 엔진이 해야할 일들은 너무나도 많고, 비용도 많이 들며, 경험도 많이 필요해서, 스타트업이 웹 검색 엔진을 제대로 하기란 정말 어려운 일이라고 생각한다. 이해할 수 있다. 하지만, 그 이상은 아니다. 스타트업의 용기를 칭찬하고 북돋아주는 소수의 블로거들을 제외한 나머지 사용자들은, 웹 검색엔진 스타트업의 사정을 어느 정도 이해하는 소프트웨어 엔지니어들보다는, 훨씬 냉정하다.

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와 대화를 시도한다. 덕분에 나는 멀뚱멀뚱 가만히 있어야하는 상황이 되어버린다. 나는 다른 업무로 돌아갈 수도 없다. 아니, 이메일, 메신저와 같은 비동기적인 통신 방법은 두었다가 무엇하는가.