검색엔진이라고 하면 가장 먼저 떠 오르는 것은 내 블로그 방문자를 기준으로 할 때 '구글'과 '네이버'일 것이다. 중국이나 일본의 인터넷 사용자라면 또 다른 검색 엔진을 떠 올릴 수 있다. 구글이 수집하여 저장하고 그리하여 검색 가능한 웹 페이지의 숫자는 10억 개니 15억 개니 하는 말이 많지만 누구 하나 직접 숫자를 세어본 바 없으니 그저 '엄청나게 많다'고 알고 있다. 구글은 지난 7월 페이지가 아닌 URL 기준으로 1조 개의 URL을 수집하고 있다고 이야기한 바 있다.




구글이 압도적으로 우수한 검색 엔진의 소유 업체라는데 이견이 있는 사람은 별로 없을 것이다. 구글의 검색 결과와 네이버의 검색 결과에서 특히 '한글로 검색했을 때' 그 결과의 신빙성에 대해 의심하는 사람은 많지만 그럼에도 불구하고 전 세계의 웹 문서를 검색하는데 있어서 구글의 압도적 우위를 의심하는 사람은 적다. 구글은 정말 위대하다고 말해도 무방할 정도로 기술적으로, 양적으로 압도적 우위를 차지하고 있는 2008년 현재 세계 최고의 검색 서비스 업체다. 맞다, 인정할 수 밖에 없다. 그런데...

한국에서 태어나 2바이트 문자인 한글을 사용하는 내게 있어서 구글보다 네이버 검색 서비스가 더 실효성 있는 정보를 제공하고 있었다는 현실을 무시할 수는 없다. 어떤 사람은 이것을 부정하고 싶겠지만 네이버는 나름의 노력으로 한글로 작성된 많은 웹 문서를 수집하려 노력해 왔고 심지어 스크랩(펌)을 자연스럽게 조장하는 많은 장치를 만드는 무리수를 두면서 이 노력을 멈추지 않았다. 때문에 구글 검색 서비스에 "청담동 뉴욕 스타일 신상"이라고 입력하면 이상한 결과가 나오지만 네이버는 청담동의 관련 옷집 정보를 노출한다. 예를 들어 그렇다는 말이다. 내가 예를 든 이런 식의 예제를 통해 많은 사람들은 구글과 네이버가 무슨 차이가 있고 누가 더 우월하고 누가 더 열등한가에 대해 열띤 토론을 해 왔다. 그런 토론을 흥미진진하게 지켜봤던 입장에서 오늘 내가 경험한 한 가지 사건은 그 토론이 얼마나 무가치한 것이었는지 재삼 깨닫게 하는 계기가 되었다.


나는 몇 주 동안 굉장히 몸이 좋지 않았고 몇 주 입원도 했었다. 좀 더 요양이 필요하다고 판단하여 여러 곳을 고려하던 중 경상남도 합천의 해인사 근처에서 요양을 하는 게 좋겠다고 생각하게 되었다. 이런 상태에서 다른 사람들이 그렇듯 나 또한 네이버를 비롯한 몇몇 검색 엔진에 합천 해인사 주변의 숙박 시설에 대한 정보를 조회하기 시작했다. 나는 이전에 이미 몇 번 해인사에 가 본 적 있었기 때문에 매우 구체적인 정보가 필요했다. 해인사 주변에 있는 여관과 민박의 숙박 요금과 시설에 대한 정보, 장기 투숙할 경우 요금 조정 여부, 3식을 숙박 기관에서 해결할 경우 요금에 대해 알고 싶었다. 그리고 해인사 주변의 수 많은 숙박 시설 중 가장 조용하고 시설이 훌륭한 곳도 알고 싶었다. 수 없이 많은 검색을 반복한 결과는 무엇이었을까?

내가 원하는 결과는 웹에 없었다.

아마도 내가 잘못된 검색어를 입력했을 지 모른다. 내가 몇 시간 동안 입력한 수 백개의 검색어가 잘못되었을 수 있다. 전 세계에서 1조 개에 달하는 URL을 수집하고 있다는 구글도 내가 원하는 검색 결과를 보여주지 못했고 한국에서 10년 동안 콘텐츠를 수집해 왔다는 네이버도 내가 원하는 결과를 보여주지 못했다. 그래도 나는 여전히 내가 잘못된 검색어를 입력했기 때문에 문제에 대한 대답을 얻지 못했다고 생각하고 있다. 그래서 나는 아침이 밝아 오면 해인사에 전화를 하고 해인사 주변의 민박이나 여관, 호텔에 전화를 해서 내 사정을 설명한 후 가격과 조건에 대해 알아 볼 생각이다.

만약 내가 전화를 통해 얻은 결과를 내 블로그에 공개한다면 어떻게 될까? 아마 언젠가, 누군가 나와 똑같은 조건으로 해인사 주변에 머물려 할 때 내 글이 구글이나 네이버의 검색 결과 첫 페이지에 나온다면 그 사람은 그 검색 엔진이 매우 훌륭한 결과를 보여준다고 생각할 것이다. 그러나 내가 그런 결정, 즉 내 블로그를 통해 검색 엔진이 내 경험을 수집하도록 허락하지 않는다면 혹은 그 결과를 공개된 웹 페이지에 쓰지 않거나 누군가 내가 쓴 글을 퍼가지 못한다면 어떻게 될까? 누군가 나와 같은 문제에 대한 대답을 온라인에 공개하기 전까지 여전히 그 대답은 존재하지 않을 것이다.아니면 여러 개로 나눠진 대답을 힘들게 수집하여 종합하여 판단해야 할 것이다.

나는 가끔 검색 엔진이 수집하고 있는 데이터가 내가 질문하려는 대답을 갖고 있는 것인지 혹은 내가 질문하려는 것의 일부만 갖고 있는 지 의심스러울 때가 있다. 1조 개의 URL이 아니라 그보다 훨씬 많은 문서를 수집하고 있더라도 사람이 질문하는 것에 대해 제대로 대답하지 못한다면 그것은 그리 만족스러운 검색 엔진이 아닐 것이다. 그리고 또 다른 생각을 한다. 내가 제대로 질문을 한다면, 내가 제대로 키워드를 선정하여 검색 엔진에 질문한다면 제대로 답을 얻을 수 있지 않을까? 문제는 계속 진화하고, 계속 더 많은 리소스를 수집하고 있는 검색 엔진이 아니라 제대로 질문하지 못하는 나 자신의 문제는 아닐까?

멍청한 키워드만 입력하고 제대로 된 답을 원하는 나라는 인간의 문제는 아닐까?

참으로 애매한 문제다. 훌륭한 검색 엔진이라고 인정하는 것은 그 속에 반드시 답이 있다고 인정하는 것과 같은데 그럼 결국 질문하는 사람의 한계는 누가 극복하게 만드는 것인가? 검색 엔진이 앞으로 10년 후 전 인류의 의미있고 의미없는 모든 지식을 수집하게 된다면 그 속에 우리가 궁금하게 생각하는 모든 것에 대한 대답이 있는 것일까? 그럼 결국 우리가 제대로 질문하기만 하면 모든 질문에 대한 대답을 얻을 수 있는 것인가? 그렇지 않다고 말한다면 우리는 왜 검색 엔진이 매일 수 억 개의 웹 페이지를 추가로 수집하도록 내버려두는 것인가. 그렇게 수집해봐야 더 나은 대답을 찾을 수 없는데 말이다. 참으로 모순된 현상 아닌가?

검색 엔진은 '더 나은 대답'을 위해 끝없이 수집하고 있고 우리는 '더 나은 대답'을 위해 검색 엔진에 여러가지 키워드를 입력하며 질문하고 있다. 그런데 기계가 데이터를 수집하는 목적과 우리가 검색하는 목적의 궁극적인 의미가 서로 다르다면 어떤 일이 벌어질까? 내가 묻는 질문의 외연은 "가장 저렴한 숙박 시설"이지만 본질은 "심신의 안정"이었다는 걸 검색 엔진이 이해할 수 있을까? 만약 그 결과가 없다면 검색 엔진은 또 다른 대안을 제시할 수 있을까?

사람과 사람의 관계에서 우리는 스스로 대안이 없더라도 그 사람의 고민을 들어주는 자체로 의미를 갖기도 한다. 검색 엔진이 그런 역할을 할 시대가 도래할까? 영화 <A.I>처럼 사람들이 기계에게 고해성사를 하는 그런 시절이 오게 될까? 우리는 도대체 무엇을 근거로 검색 엔진이 내놓는 결과를 신뢰하는 것일까?

우리의 멍청함에 대해, 우리가 신뢰하고 있는 것들의 멍청함에 대해 다시 생각해 본다. 내가 앞으로 30년을 더 살더라도 더 훌륭한 뇌를 가질 가능성은 적지만 앞으로 10년 동안 검색 엔진이 지금보다 훨씬 더 다양하고 많은 웹 문서를 수집할 가능성과 그것을 사람들이 질문하는 유형에 따라 훌륭하게 분류할 가능성은 매우 높다. 그렇다면 앞으로 발생할 인간이 하는 질문에 대해 적절한 대답을 제시하지 못하는 검색 엔진의 문제는 멍청한 사람으로 인한 것인가?

이 멍청한 질문을 정말 멍청한 것이라고 생각하는 사람이 바로 당신이라면 스스로 이런 질문을 해보라, "당신은 왜 컴퓨팅의 결과를 그토록 신뢰하는가?" 인간에 대한 배신감 때문일 수 있겠지만 그보다 당신 스스로 매번 기계적 연산 결과나 함수의 결과에 대해 과신했기 때문은 아닐까? 나는 '공식'을 신뢰하며 스스로 그것을 과학적이라 자부하는 사람들이야말로 가장 비과학적인 사람이라고 생각한다. 과학이야말로 현대의 새로운 종교 아니던가. 백년 쯤 지나면 현재 우리가 믿고 있는 그 '과학'이라는 것이 얼마나 신화적이었음이 밝혀질 것이다. 그 때면 우리가 지금 신뢰하고 있는 검색의 결과라는 것도 어떻게 변할 것 같은가?

미래를 두려워하지 않는다면 현재는 허구일 뿐이다.

지위가 사람을 규정한다는 말이 있다. 심리학적인 관점이든 경영학적 관점이든 지위에 따라 똑같은 사람의 생각과 행동 양식이 달라진다는 것은 익히 알려진 사실이다. 이것은 웹 서비스 개발팀의 팀장에게도 똑같이 적용된다.




이야기를 시작하기 전에 '웹 서비스 개발팀의 팀장'은 프로그래머를 지칭하지 않음을 분명히 해야겠다. 개발팀의 팀장이라면 대개 프로그래머이거나 프로그래머 경력이 있는 사람일 가능성이 매우 높지만 '웹 서비스 개발팀'은 그렇지 않은 경우도 있다. 여기서 '개발팀'은 특정 웹 서비스를 만들기 위해 모인 사람들 모두를 말한다. 개발팀은 프로그래밍을 하는 사람과 디자인을 하는 사람, 기획을 하는 사람을 지칭한다. 마케팅이나 고객 지원, 프로모션 팀도 포함될 수 있겠지만 이렇게 될 경우 개발의 범주가 '비즈니스 개발'로 확대된다.


거부

새로운 웹 서비스를 개발하기 위한 프로젝트가 시작되었고 팀이 구성될 시점이다. 누군가 이 팀을 총괄할 팀장 역할을 수행해야 한다. 팀장 대신 PM(Project Manager)이라고 부르는 곳도 있고, 팀장과 PM이 각각 존재하는 경우도 있다. 어쨌든 팀장을 뽑아야 한다. 서로의 장점과 한계를 잘 알고 있는 작은 조직의 경우 자연스럽게 팀장이 정해 진다. 어떤 작은 조직은 누구도 팀장 경험이 없었고 팀장의 역할이 무엇인지 제대로 의논하지도 않았지만 그 사람이 팀장이 되어야 한다는데 아무런 이견이 없었다. 왜냐면 그 사람이 팀을 만든 사람이고 회사의 사장이기도 했기 때문이다.

그러나 조직의 규모가 커지면 팀장을 선정하는 문제는 복잡해진다. 어떤 조직은 팀장이 되려는 사람이나 될 수 있는 사람이 너무 많아서 문제고, 또 다른 조직은 팀장이 되려는 사람이 아예 없거나 팀장이 되지 않으려는 사람이 너무 많아서 문제다. 큰 조직은 실제로 팀장의 역할 수행에 대한 문제보다 누구도 팀장이 되지 않으려는 문제가 더 자주 나타난다. 그 이유도 다양하다. 큰 조직에서 일하는 사람들이 팀장이 되길 거부하는 이유는 대개 이런 것이었다.

- 시간이 없다
- 바쁘다
- 다른 일을 해야 한다
- 그가 훨씬 잘 할 것이다, 난 바쁘다

자신이 팀장이 될 수 없는 수 천 가지의 이유를 들어 봤지만 대개 위 이유를 벗어나는 경우는 없었다. 웹 서비스를 제대로 만들기 위해 회사는 제대로 된 인재를 개발팀에 포함시켜야 하는데 인력 배치에 있어서 가장 중요한 첫번째 선정 작업은 바로 '팀장'이다. 누군가 나서서 자신이 팀장이 되겠다고 하는 아름다운 광경은 보기 매우 힘들다. 특히 누구도 다루기 힘든 뜨거운 감자와 같은 프로젝트의 개발팀장을 뽑는 것은 꽤 까다로운 일이어서 이것 때문에 프로젝트 시작이 지연되기도 한다.

몇 년 전 한 회사가 처한 상황도 비슷했다. 벌써 1개월 전에 프로젝트에 돌입해야했지만 개발팀장이 뽑히지 않은 상태였다. 회사에서 개발팀장 후보자에 오른 사람은 3명이었다. 회사는 3명 중 누군가 반드시 팀장이 될 것이라 확신했던 것 같다. 그러나 3명 모두 개발팀장이 되길 거부했다. 3명이 거부한 이유는 흥미롭게도 3가지였다. 3명을 만나서 거부의 이유를 들어 봤다,

A씨 : "현재 업무가 과중해서 새로운 업무를 맡을 수 없어요."
B씨 : "프로젝트에 처음부터 제가 개입한 것도 아니고 제가 잘 할 수 없을 것 같아요."
C씨 : "그동안 제가 했던 일과 관련이 많기는 하지만 저는 곧 회사를 그만 둘 것입니다."

맙소사! 회사에서 그렇게 믿고 있던 개발팀장 후보자 3 명은 모두 그럴싸한 이유를 대며 프로젝트를 담당하지 않겠다고 선포하고 있었다. 이 사태를 어떻게 받아들일 것인가. 내부 후보자 대신 새로운 외부 인력을 뽑아야 할까? 아니면 경험이 부족하더라도 적극적으로 프로젝트에 개입하고 싶어하는 보다 경력이 적은 사람을 다시 후보자로 물색해야 할까? 고민이 꼬리를 물고 있을 때 문득 세 명이 내게 정말 정확히 거부의 이유를 밝힌 것인지 궁금해졌다.


진실

나는 3 명의 후보자의 평판을 알아 보기 위해 그들과 친근하거나 그들과 현재 업무를 함께 진행 중인 사람들을 만나가기 시작했다. 후보자들의 회사 동료와 친구, 상사를 만나서 그들의 최근 상황과 프로젝트에 대한 입장을 수집하기 시작했다. 며칠 지나지 않아 놀라운 사실을 발견할 수 있었다. 3 명의 후보자 중 두 명은 동일한 시기에 다른 회사에서 현재 회사로 이직한 사람이었고 매우 절친한 사이였다. 또 다른 한 명은 조금 늦게 입사했는데 두 사람과 관계가 그렇게 좋지 못한 편이었다. 놀라운 사실은 새로운 프로젝트가 시작되기 전에 이미 세 사람이 모여서 이 프로젝트의 팀장으로 누가 적절할 지 의논한 적이 있다는 것이었다. 그 자리에서 A씨는 B씨를 추천했다고 한다. C씨는 자신이 이 프로젝트의 적임자라고 생각했지만 별 다른 의견을 제시하지 못했다고 한다.

그런데 회사는 이런 관계를 잘 모른 상태에서 세 명의 후보자들을 공정하게 평가하여 팀장으로 임명하겠다고 공지를 했다. 회사 측에서는 C씨가 가장 적절한 후보자라고 내부적으로 평가하고 있었다. 문제는 회사 측의 생각을 이미 세 명의 팀장들이 알고 있었다는 점이다. 이렇게 되자 세 명의 후보자들은 위와 같은 태도를 취하기 시작했다. C씨가 회사를 그만두겠다고 말한 것은 A씨와 B씨가 만약 B씨가 아닌 다른 사람이 개발팀장이 된다면 팀원 차출이나 프로젝트 협력에 문제가 있을 것이라고 주위에 이야기를 하고 다녔기 때문이다. C씨는 이런 식이라면 더 이상 회사에 다닐 이유가 없다고 생각하고 있었다.

이 3류 소설과 같은 이야기를 알게 되었을 때 내 심정은 오히려 편안했다. 최소한 모든 후보자들이 프로젝트에 무관심한 상태는 아닌 것이 분명했기 때문이다. 그들은 하나같이 자신이 프로젝트를 맡으면 잘 할 수 있을 것이라고 생각하고 있었던 것 같다. 비록 작은 권력 암투가 벌어지고 있었지만 프로젝트에 대해 무관심한 것보다는 훨씬 낫다. 그 따위 권력 암투를 벌인 대가는 나중에 프로젝트가 시작된 후 '완결성 낮은 웹 서비스'가 나왔을 때 100배로 복수하면 될 일이다.

프로젝트 개발팀장을 선정하지 못하는 주요한 이유를 알아 냈다. 회사의 대표자와 이런 상황에 대해 이야기를 하고 그의 의견을 듣기로 했다. 그는 그런 상황이 있다는 걸 대충 짐작은 했다고 말했다. 그도 이 문제를 어떻게 해결해야 할 지 난감한 상황이라고 말했다. 나는 세 명 중 한 명을 회사에서 떠나게 할 수 있는지 물었다. 결론은 어떻게 되었을까. 프로젝트는 진행되었고 아무도 회사를 떠나지 않았다. 대신 프로젝트는 새로운 팀장을 영입하여 새롭게 구성된 팀에서 진행하게 되었다. 비록 프로젝트는 2개월 가량 더 지연되었지만 회사의 내부 권력 싸움에서 자유로울 수 있었다. 기존 팀장들은 회사의 도움으로 새로운 교육 과정에 들어가거나 다른 업무를 부여 받는 식으로 갈등을 해결해 나갔다.


이 이야기는 개발팀의 팀장에 대한 수 많은 이야기 중 극히 작은 이야기일 뿐이다. 우리는 프로젝트의 팀장을 선정할 때 그들이 가진 기술적 가치로 판단하려는 경우가 많다. 그의 생각이나 상황에 대해 이해를 하지 못하고 단지 그가 가진 기술과 경험에 의해 팀장을 선정하게 된다면 그 결과물을 확신할 수 없게 된다. 사람이 중요하다는 뻔하고 뻔한 이야기는 그 가치가 분명하지만 '사람들의 관계'에 대해 잘 알지 못하면 그저 쓸모없는 분란을 오랫동안 보존할 뿐이다.

웹 사이트를 만들 때 만약 어떤 페이지가 동적으로 자동 구성되게 만들려면 반드시 어떤 정책(policy)이 필요하다. 자동화 시스템은 대부분 매우 간단하다. 그러나 본질적인 측면에 접근하면 자동화 시스템은 필연적으로 복잡해 진다. 대부분의 시스템은 더 복잡해지려는 속성이 있고, 그 시스템을 사용하는 사람들의 요구에 의해 더 복잡해지기도 한다. 더 많은 '조건'이 있을수록 보다 '신뢰할 수 있다'고 많은 사람들이 생각하기 때문이다.






2001년 즈음에 한 웹 사이트를 만들며 메인 페이지에 <오늘의 인기 글>을 포함시킬 계획을 세웠다. 회사 경영진은 웹 사이트 운영을 위한 인건비를 최소화하길 바랬다. 때문에 매일 <오늘의 인기 글>을 선정하는 것이 아니라 자동으로 이 부분이 구성되어야 한다고 지시했다. 나는 몇 가지 이유를 들며 그런 구성이 바람직하지 않다고 지적했지만 일단 지시한 것을 구현하기로 했다.


정의

<오늘의 인기 글>이라는 것에 대해 정의를 먼저 해야 했다. 개념적 정의지만 이 정의 때문에 멍청한 짓을 반복할 수도 있고 그렇지 않을 수도 있다. 내가 <오늘의 인기 글>을 정의하는 토론을 하자고 제안하자 일부 사람들이 "다 알고 있는 걸 왜 정의해야 하죠?"라고 의문을 제기했다. 최초의 반발에 대해 우리가 알고 있는 정의가 일치하지 않을 수 있고, 설령 일치하더라도 틀렸을 수 있으니 한 번 검토해 보자고 이야기했다. 못마땅한 표정을 짓는 몇 명과 함께 회의실에서 그들이 생각하는 <오늘의 인기 글>에 대해 이야기를 시작했다.

화이트 보드에 커다랗게


이라고 적었다. 그리고 사람들에게 지금부터 우리가 해야 할 토론 주제는 5가지인데 각각 "오늘", "의", "인기", "글"이며 끝으로 "오늘의 인기 글"에 대해 토론할 것이라고 말했다. 회의에 참석한 사람들이 웅성대기 시작했다.

"도대체 무슨 소리하는 거야?"
"바빠 죽겠는데 뭘 하자는 거지..."
"저게 프로그램 개발과 무슨 관계가 있어!"

이런 수근거림이 회의실을 가득 메웠다. 그러나 단 한 명은 조용히 이야기를 듣고 있었다, 2주일 전에 입사한 프로그램 팀장이었다. 그는 이전 회사에서 커뮤니티 소프트웨어를 5년 간 개발한 경험이 있는 사람이었는데 내 이야기에 매우 흥미있어 하는 표정이었다. 웅성거림 속에서 그가 이야기를 했다,

"저 주제는 이야기해 볼만 한 것 같습니다. 오늘에 대해 누가 정의해 볼 사람이 있나요?"

순간 회의실은 조용해졌다. 머뭇거리던 사람 중 하나가 대답했다,

"24시간을 기준으로 볼 때 00:00:00에서 23:59:59까지를 오늘이라고 말할 수 있겠죠."

그가 물었다,

"그럼 오늘의 인기 글은 그 하루를 기준으로 해야겠네요?"

다른 사람이 대답했다,

"그렇죠, 오늘의 인기 글이니까요."

그는 고개를 갸웃거리며 말했다,

"그렇다면 00:00:01에 웹 사이트에 접속한 사람은 1초 사이에 선정된 오늘의 인기 글을 봐야 할텐데 1초 사이에 아무런 글이 올라와 있지 않으면 어떻게 되죠?"

회의실은 순간 매우 조용해졌다. 나는 그 팀장에게 감사의 눈빛을 보낸 후 바로 그런 이유 때문에 토론이 필요한 것이라고 말했다. 우리가 '오늘'을 어떻게 정의하는 가에 의해 <오늘의 인기 글>을 개발하는 방식이 매우 달라진다. 우리가 알고 있는 '오늘'과 웹 사이트에서 정의한 '오늘'은 다른 경우가 흔하다. '오늘'의 정의에 대해 토론하는 과정에서 우리는 시스템과 사람들의 인지 사이에 존재하는 부조화를 알게 되었다. 그 결과 '오늘'은 다음과 같이 정의되었다.

- '오늘'을 4개로 나눈다
- 시스템은 6시간 간격으로 새로운 '오늘'을 정의한다
- 24시간 기준의 '오늘'은 새로운 데이터로 저장한다

위와 같이 '오늘'에 대한 정책을 정하게 되었다. 이 정책에 의해 <오늘의 인기 글>은 6시간 간격으로 업데이트되고 하루치 모든 글을 수집하고 통계하는 대신 6시간 간격으로 업데이트된 글만 따로 데이터베이스를 구성하기로 했다. 또한 <어제의 인기 글>이라는 데이터베이스는 24시간을 기준으로 저장되어 보여주기로 했다.

우리는 이어서 "인기"와 "글"에 대한 토론을 했고 각각을 새롭게 정의했다. "의"는 시스템의 시간과 사용자가 인지하는 시간에 대한 토론이었다. 끝으로 "오늘의 인기 글"이라는 통합 개념에 대해 토론했다. 모든 토론을 끝내는데 3시간이 걸렸다. 그러나 이 토론을 통해 시스템을 개발하는 과정에서 만날 수 있는 대부분의 문제를 발견할 수 있었고 실제 개발을 하는 과정에서 추가로 발견되는 문제는 없었다.


한계

이렇게 정의를 하자 <오늘의 인기 글>이라는 시스템의 한계가 드러났다. 만약 00:00:01초에 업데이트된 글이 있다면 이 글이 아무리 인기 있는 글이 올라왔더라도 <오늘의 인기 글>에 반영되는데 최소한 6시간 지연된다. 이 문제를 해결하는 방법으로 "실시간 인기 글을 만들자"는 주장이 있었고 "지연 시간을 1시간으로 줄이자"는 의견도 있었다. 그러나 그렇게 할 경우 시스템이 불필요하게 동작하여 과부하를 발생시키는 문제와 인기 글이 너무 자주 바뀌어 인기 글에 대한 주목을 떨어 뜨리는 문제가 있었다.

한계를 어떤 식으로 극복할 것인지 고민하던 우리는 갑자기 이런 질문에 부딪치게 되었다,

"6시간 업데이트가 과연 적절한가?"

왜 우리는 6시간 간격으로 인기 글을 업데이트하기로 정의한 것일까? 아직 웹 사이트가 서비스를 시작하지도 않았기 때문에 과거에 우리가 경험했던 어떤 웹 사이트에 대한 서로 다른 경험에 기초하여 6시간이라는 지연 시간을 선택했다. 우리는 그 경험 즉 우리들이 경험했던 다양한 웹 사이트의 사례에 대해 이야기했다. 2시간 동안 그 이야기를 더 한 후 우리는 다음과 같은 결론에 이르렀다.

- 하루에 업데이트되는 글이 1백 개 미만일 때까지 6시간 유지
- 3백 개 미만일 때 3시간으로 조정

하루에 새로운 글이 3백 개 이상 올라올 경우 전반적인 하드웨어 추가와 웹 사이트의 질적 업그레이드가 필요하다며 <오늘의 인기 글>에 대한 정책 또한 전반적으로 변화해야 한다고 판단했다. 초기에 곧장 1백 개 이상의 글이 올라 올 가능성은 매우 낮았다. 당시 우리가 기획하던 웹 사이트는 블로그나 BBS와 같은 형태가 아니었기 때문이다. 만약 사용자 제작 콘텐츠에 의해 구성되는 웹 사이트였다면 처음부터 이 정책에 포함된 숫자는 매우 달랐을 것이다.

이렇게 한계에 대해 정의를 했음에도 여전히 문제는 있었다. 매우 중요한 글이나 사용자에 의해 주목받는 글이 갑자기 나타났을 경우 대응책이 없었기 때문이다. 이 부분에 대해 기술적인 시도를 계속하려는 것은 무의미하다고 생각했다. 지금까지 토론하고 정의한 부분으로 기술적인 과제는 충분히 나온 상태이며 완벽히 프로그램에 의해 돌아가는 웹 사이트를 만들 생각은 없었기 때문이다. 나는 "운영자 당번제"를 실시하자고 제안했다.

운영자 당번제는 여러 운영자가 돌아가면서 웹 사이트에서 갑자기 주목받는 글을 <오늘의 인기 글>에 임의로 등록하는 것을 말한다. 이것을 위해 다음과 같은 정책을 정했다

- 해당 글의 조회수가 급등할 경우 해당 운영자 휴대 전화로 문자 메시지 자동 발송
- 급등의 기준은 1시간 이내 100회 이상의 히트수 증가가 있는 경우

SMS로 문자 메시지를 자동 발송하는 소프트웨어는 이미 존재하고 있었기 때문에 어려울 것이 없었다. 급등 기준은 시스템 관리 메뉴에서 임의로 수정할 수 있도록 했다. 나중에 이 시스템은 고의적으로 게시글의 히트수를 증가시키는 어뷰징(abusing) 관리 시스템으로 동작하기도 했다. 자동화를 위해 기술적인 측면으로 접근하는데 몰입했다면 한계는 여전히 한계로 남아 있었을 것이다.



자동화의 현실

웹 사이트를 만드는 사람 대부분은 '자동화'라는 것이 '코드없는 프로그래밍'만큼 비현실적인 이야기임을 잘 알고 있다. 앞서 이야기한 <오늘의 인기 글>의 경우도 결국 자동화의 한계에 부딪치고 말았다. 앞서 이것을 자동화시켜 달라는 경영진에게 반대 이유를 이야기했다고 말한 바 있다. 내가 자동화에 반대한 이유는 세 가지 였다.

첫째, <오늘의 인기 글>은 웹 사이트 운영에 있어서 매우 주요한 요소이며 변동성이 크기 때문에 매일 사람에 의해 '편집되는 것'이 맞다
둘째, 편집하는 행위를 통해 웹 사이트의 현재 상태를 정기적이며 타이트하게 파악할 수 있다. 웹 사이트 운영 회의와 기획 회의를 동시에 진행할 수 있다
셋째, 우리 웹 사이트에 어떤 글이 '인기 글'로 올라 올 지 추측할 수 있을 뿐 정확히 알 수 없다. 추측으로 자동화시킨 시스템은 사람을 더 힘들게 할 뿐이다.

이런 세 가지 이유로 <오늘의 인기 글>은 운영자에 의해 선정되고 편집되는 것이 옳다고 주장했다. 자동화 시스템은 웹 사이트를 연 후 계속 사용되긴 했지만 실제로 그 웹 사이트가 살아 있는 동안 대부분의 <오늘의 인기 글>은 운영자에 의해 편집되었다. 웹 사이트의 많은 부분은 현재도 사람의 판단에 의해 편집되고 있다. 어떤 사람들은 잘 만들어 둔 로직(logic)과 코드(code)에 의해 웹 사이트가 자동으로 구성되어 운영될 수 있다고 이야기한다. 웹 사이트는 많은 하드웨어와 소프트웨어에 의해 움직이지만 그렇다고 웹 사이트 자체가 로직이나 코드로 구성된 소프트웨어는 아니다. 아직까지 인간이 입력한 콘텐츠를 인간답게 완벽히 이해하는 소프트웨어는 존재하지 않는다.

웹 사이트에 게시판을 만들었다는 것은 어떤 종류의 콘텐츠가 올라올 지 예측할 수 있을 뿐 반드시 그 결과가 예측과 일치하는 것은 아니다. 이런 불확실성을 극복하기 위해 게시판의 이름을 '브라우저에 대한 이야기'라고 정하는 대신 "매킨토시에서 동작하는 오페라 브라우저에서 CSS를 구현하는 표준화에 대한 5년차 C++ 프로그래머의 라이브러리에 대한 질문과 대답"이라고 정할 수도 있을 것이다. 그런 게시판을 만들어 보라. 누군가 그 게시판에 "오늘 점심 메뉴는 뭐가 좋을까요?"라는 질문을 하지 않을 것이라고 확신할 수 있는가? 그런 게시물을 다른 게시판으로 옮기는 자동화 소프트웨어를 만드는 것이 무슨 의미가 있겠는가?

그러나 웹 사이트 자동화 시스템에 대한 관점을 조금 바꾼다면 지금보다 훨씬 행복하게 웹 사이트를 만들 수 있다. '귀찮은 것', '반복되는 것', '사람으로 할 짓이 아닌 것'을 코드로 바꿔서 소프트웨어가 반복하도록 만드는 것을 자동화라고 정의해 보면 어떨까. 그렇게 생각을 바꾼다면 웹 사이트를 자동화할 수 있는 요소는 분명히 존재한다. 사람이 해야 할 '마땅한 일'을 자동화하려는 멍청한 시도보다 사람이 하지 않아도 되는 '멍한 일'을 자동화하는 게 아름답다.

어떤 사람은 일년에 책을 200권을 읽는다고 한다. 다독하는 사람들은 책을 통해 지식을 섭취하기 보다는 책을 읽으며 '생각한다'. 만약 책을 읽는 과정에서 지식과 정보를 습득하겠다는 목적이 강하다면 결코 한 해에 200권의 책을 읽을 수 없다. 다독하는 사람들은 책을 읽으면서 자신의 생각을 겹쳐 생각하는 방식이 대부분이다. 믿을 수 없다면 다독하는 사람들에게 이런 질문을 하면 된다,



"왜 그렇게 많은 책을 읽습니까?"


내 주변 사람들 중 한 해에 50권 이상의 책을 읽는 사람들의 공통적 특징은 책을 통해 정보를 습득하는 게 목적이 아니라 책을 읽음으로써 자신의 생각을 정리하는데 있다는 것이다. 한 해에 읽는 책이 50권이라고 해도 대략 일주일에 한권을 읽는 셈인데 평범한 사람으로는 감당하기 힘들다. 하물며 200권을 읽는다는 사람은? 이렇게 책을 많이 읽는 사람들은 우리가 흔히 아는 책에 대한 관점과 또 다른 관점에서 책을 읽는 사람들이다.

그런데 나는 한 해에 200권의 책을 읽는 것만큼 한 해에 한 권의 책을 쓰는 사람도 중요하다고 생각한다. 책을 쓰는 입장인 '나'로서는 200권의 책을 읽는 것보다 한 권의 책을 쓰는 게 훨씬 의미있다. 200권의 책을 읽는 사람이 갖는 목표가 있다면 한 권의 책을 쓰는 사람의 목표도 있다. 전자의 목표가 더 많은 이야기에 대한 공감이라면 후자는 내가 하는 이야기에 대한 공감이다. 누가 더 목숨 걸었냐고 물어 본다면 당연히 후자다. 개인적인 입장에서 한 해에 10권 정도의 책을 읽고 한 권의 책을 쓸 수 있는 사람이 되길 원한다.

내 1년은 10권 정도의 책을 읽으며 온통 바쳐 버리고 그 결과에 대해 한 권의 책을 쓸 수 있다면 자본 투입 대비 성과가 꽤 좋은 편이라고 생각하기 때문이다. 모니터 옆에 쌓여 있는 40여 권의 책을 보며 이렇게 위로를 해야할 것 같다. 좋은 책을 쓰려면 좋은 글을 많이 읽어야 한다. 나도 안다. 그건 한 해에 10권 정도의 책은 아닐 것이다. 그렇다고 200권의 책은 정말 아니다. 읽느라 쓸 시간도 없을 것이니까.


책을 읽는 자는 세상을 이해하고
책을 쓰는 자는 세상을 바꾼다.
이해하는 자가 많아야 바꾸기 쉽다.

아는 분만 알고 있는 제 책쓰기 관련 역사가 있습니다. 벌써 햇수로 3년 넘게 질질 끌고 있는 책이 한 권 있는데 목록 잡기만 수십 번은 한 것 같습니다. 초안을 썼다 버린 적은 수도 없습니다. 바로 "웹 서비스 기획"에 대한 책입니다.






책을 쓰지 않고 오죽 질질 끌었으면 작년 7월에는 8월 탈고를 하겠다고 편집 기획자에게 약속하는 글을 공개적으로 쓰기도 했습니다. 물론... 잘 안되었죠. 그 후에 몇 가지 글쓰기를 막는 일이 정리되자 몇 개월 전 올해 6월 말에 탈고를 하겠다는 약속을 했습니다. 그런데 이번엔 정말 탈고를 할 수 있을 것 같습니다. 왜냐면 책에 포함될 가장 중요한 현업에서 실험이 마무리되었기 때문입니다.

웹 서비스를 기획하는데 필요한 요소를 나열하고 어떤 식으로 만들면 된다는 이야기를 하는 책은 몇 권 있습니다. 그런데 실제로 현업에서 적용 가능한 '방법'에 대해 세세하게 다루는 책은 없었던 것 같습니다. 또한 어떤 문제가 얼마나 중요한 가에 대해 가중치 없이 기획 일반에 대해 다루는 경우도 많았던 것 같습니다. 어떤 '문제'는 가쉽이나 기획자 개인의 성향으로 치부되기도 한 것 같습니다. 또한 웹 2.0 서비스를 만들기 위한 특별한 방법에 대해 언급한 경우는 별로 없었던 것 같기도 합니다.


웹 서비스 기획의 기술

이번 책은 지난 10년 간 웹 서비스를 기획하면서 우리가 정말 중요하게 다뤄야 할 문제인데 가볍게 넘어 가거나 연구 가능한 주제가 아니라고 생각했던 문제에 대해 부각시킬 생각입니다. 예를 들어 '인터뷰(interview)'의 중요성에 대한 이야기입니다.


- 인터뷰 기술

웹 서비스를 기획할 때 그 사람의 직종이 뭐든 간에 - 기획자든, 개발자든, 디자이너든, 마케터든, 아니면 창업자든 - 반드시 인터뷰를 해야 합니다. 그런데 현업에서 웹 서비스 기획을 위한 인터뷰는 기껏해야 2가지 종류 뿐입니다. 우리가 잘 알고 있는 인터뷰의 형태는 이런 것입니다.

1. 내부 인터뷰 : 현업에서 웹 서비스 제작과 관련한 사람들을 만나는 일
2. 외부 인터뷰 : 그 서비스를 쓸 사용자를 만나는 일

물론 큰 범주에서 인터뷰는 두 가지 종류로 나눌 수 있습니다만 기획을 하려는 사람에게 필요한 인터뷰의 종류는 훨씬 많습니다. 또한 인터뷰는 한 차례 행위로 끝나는 것이 아니라 웹 서비스를 제작하는 과정 전체에서 반복해야 합니다. 서비스를 기획하는 사람은 인터뷰를 통해 현재 진행하고 있는 일에 대해 '알려 주고' 의견을 청취하여 서비스에 반영한 후 다시 '알려 줘야' 합니다. 그런 과정을 통해 현업에서 협력할 수 있는 사람을 구하고 그런 사람들과 함께 해야 하는 일을 구조화해야 합니다.

인터뷰 기술은 또 다른 몇 가지 기술과 함께 웹 서비스를 기획하려는 사람이라면 오랜 시간 동안 훈련하고 학습해야 하는 필수적인 기술입니다. 이 책은 그런 이야기를 구체적인 사례와 함께 구체화하고 실제 적용 시 발생하는 현업의 상황에 따른 대안을 제시하려고 합니다.


- 웹 서비스 기획자의 평판

이 책에서 다룰 또 다른 주제도 있습니다. 바로 웹 서비스 기획자에 대한 평판입니다. 많은 사람들이 '성공적인 웹 서비스 기획의 요건'을 알고 싶어 합니다. 저도 많은 강좌에서 이 이야기를 한 적 있는데 강좌의 후반부에 이런 이야기를 하곤 했습니다.


여러 회사에서 웹 서비스 기획을 위한 일을 진행하며 매우 많은 경우 기획자 자신에 대한 주변의 평판이 웹 서비스의 성공과 직결된다는 것을 알게 되었습니다. 그럼 평판이 나쁜 기획자가 추진하는 프로젝트는 반드시 실패하는 걸까요? 아닙니다. 그러나 실패의 가능성이 높고, 불필요한 논쟁이 발생하거나, 일정 지연, 퇴사자, 조직 변화 등이 발생할 수 있습니다.

이 문제에 대해 그동안 웹 서비스 기획을 논할 때 '매우 중요하지만 개인적으로 처리할 문제'라는 식으로 언급하는 경우를 많이 봤습니다. 그럴 수도 있겠지만 저는 여러 프로젝트를 진행하며 이런 사람에 대한 문제를 처리하지 않고 프로젝트가 제대로 진행되는 경우를 보지 못했습니다. 규모가 작건 크건 기획 주체가 이런 문제 즉 자신에 대한 평판으로 인해 프로젝트에 문제가 발생하는 경우 대응하는 방법을 이야기할 필요를 느낍니다.

우리 나라의 문화적 특성과 기업이 흔히 하는 사람과 일에 대한 오해 때문에 이 문제는 아직 업계에서 구체적으로 다뤄진 적 없습니다. 대개는 "일은 일이고 사람은 사람"이라는 식으로 문제를 구체화하지 않고 넘어 갑니다. 그리고 결정적인 상황에서 사람 문제가 터집니다, "당신과 도저히 일하지 못하겠어!"

이 책에서 이런 문제를 해결하는 모든 방안을 이야기하지는 못할 것입니다. 그러나 이 문제가 매우 중요하다고 말할 것이며 그런 문제가 발생했을 때 프로젝트를 중단하지 않고 문제를 해결해 나가는 방법을 제시할 것입니다.


도움 주실 분을 찾습니다

이 책은 "웹 서비스를 기획하려는 사람"을 위한 책입니다. 그러나 웹 서비스 기획자를 위한 책은 아닙니다. 직업이나 직종에 관계없이 웹에 관심이 있고, 웹을 통해 뭔가를 만들고 싶어 하는 사람들을 위한 가이드입니다. 또한 웹 2.0이라고 불리는 내용이 녹아 들어간 웹 서비스를 만들고 싶어하는 사람들을 위한 실무적 '방법'을 이야기할 것입니다.

그런데 걱정이 있습니다. 제 게으름 때문에 매일 써야 할 글을 미루거나 너무 욕심을 내서 글이 어려워질까 걱정입니다. 블로그에 글을 공개하여 평가를 요청할 수도 있지만 그러기엔 아직 준비 정도가 미흡하기도 합니다. 평소에 웹 서비스를 기획하거나 웹에서 뭔가를 만들고 그걸 통해 사람들과 만나고 사업을 추진하는데 관심이 있는 분이 제가 쓴 글을 미리 읽어 주셨으면 합니다.

이런 분들의 도움을 기다리고 있습니다,


신청하실 때 직종이나 직업의 제한은 없습니다. 다만 죄송한 말씀이지만 '웹 기획을 배워 보고 싶다'는 분들은 신청을 자제해 주시면 좋겠습니다. 이 책은 분명히 웹 기획 혹은 웹 서비스 기획에 대해 알고 싶어하는 분을 위한 것이지만 나중에 책이 나오면 읽어 보시면 좋을 듯 합니다. 또한 책을 쓰는 과정에서 틈틈이 이 블로그에 내용을 공개할테니 그 때 읽어 보시면 좋을 것 같습니다.


신청 방법

아래와 같은 제목과 내용으로 2008년 5월 24일까지 bluemoonkr@gmail.com으로 이메일을 보내 주세요,

1) 제목 : <파트너 신청 - 웹 서비스 기획>

2) 내용
   - 신청자 성함
   - 현재 근무처와 직책과 직급
   - 현재 업무에 대한 설명
   - 경력 사항 (실제 수행하신 업무 중심으로)

3) 향후 진행 내용
신청하신 분들께 2008년 5월 25일 경 글을 읽을 수 있고 대화할 수 있는 블로그 주소를 알려 드리겠습니다.