몇 년 전 이 업계에 '인사이트(insight, 직관 혹은 통찰력)'라는 단어가 유행한 적이 있었다. 이 단어가 가장 흔하게 쓰였던 경우는 인재에 대한 이야기를 하는 경우였다. 예를 들어 이런 식의 문장이다,


당시에 나도 몇몇 기업에서 '직관적인 기획'에 대해 강의를 한 적 있다. 강의 말미에 나는 직관적인 기획을 하려면 머리가 터지도록 연구해야 하고 발바닥에서 땀나도록 조사해야 한다고 주장하곤 했다. 그런데 사람들은 내 이야기를 그리 진지하게 듣지 않았던 것 같다. '직관적인 기획'에서 자신들이 듣고 싶어 하는 것만 받아 들이고 나머지 이야기의 중요성은 진지하게 받아들이지 않은 것 같았다. 그들 대부분은 직관적인 기획이 "은빛탄환(silver bullet)"과 같은 것이라고 생각하는 것 같았기 때문이다. 직관적인 기획은 천재적 기획을 의미하는 것이 아니고, 직관적인 기획이 아무런 노력없이 나올 가능성은 제로라는 걸 받아들이고 싶지 않은 사람이 많았다.

직관적인 기획을 위해서는 어떤 종류의 노력이 필요한데 그 중 하나가 적절한 방법론이다. 잘 알려진 방법론을 학습하고 그것에 의해 자료를 수집하는 것도 있고 그저 자신의 경험을 끊임없이 반복 성찰하는 방법도 있다. 전형적인 혹은 학술적인 방법을 무시하고 10여년 가까이 자신과 주변의 경험만 수집하는 사람도 있다. 무엇이든 간에 장기간에 걸친 노력이 존재할 때 직관적인 기획이 가능하다. 그저 면벽 수련을 한다고 직관력이 툭 튀어 나오는 건 아니라는 말이다.

또 다른 측면에서 방법론의 중요성은 일관성과 증명 가능성이 있기 때문이다. 게임에 대해 연구하는 한 블로거를 알고 있는데 그는 주로 웹 서핑과 웹 사이트 연구, 그리고 주변 게이머들의 행동 방식을 연구하며 그것을 기초로 앞으로 일어날 어떤 일에 대해 예측하곤 한다. 그의 통찰력은 날카롭고 매우 흥미롭고 그럴싸하다. 그러나 믿음직하지는 못하다. 그의 주장을 그저 경청할 때는 발생하지 않는 문제가 그의 주장대로 사업을 해 보려고 할 때는 매우 자주 나타나기 때문이다. 바로 '근거'에 대한 문제다. 꽤 오랜 시간 동안 자신 나름의 방식으로 연구를 진행했더라도 실제 사업을 집행하는 단계에서는 또 다른 형태의 믿을만한 데이터가 필요하다. 이 '믿을만한 데이터'는 소위 '믿을만한 방법론'을 통해 나오기 마련이다. 그런데 그 방법론이 자신이 창조했거나 검증 받지 못한 것이라면?


한 기업의 웹 서비스 전략을 재정비하는 컨설팅을 의뢰 받은 후 연구 조사 과정에 2개월의 시간이 걸리고 그 결과물로 "웹 비즈니스 장기 모델"을 구축하겠다고 제안한 바 있다. 그러자 담당자는 "시간이 별로 없으니 연구 조사 시간을 줄여 달라"고 요청했다. 나는 이렇게 말했다, "조사 연구는 연료통에 연료를 채우는 것과 같은 일입니다. 어디를 얼마나 어떤 속도로 달려야 할 지 알지도 못하고 일단 달려 보자는 건 결국 끝까지 가지 않겠다는 소리와 같습니다" 이야기를 신중히 듣고 있던 담당자가 말했다, "그렇게 시간을 쓸 거면 왜 당신에게 요청했겠습니까? 우리는 즉시 답을 원합니다."


현실에서 '방법론'은 합법적인 비용 추가의 변명처럼 들리나 보다.

1995년 웹을 처음 접한 이후 13년 간 웹과 관련된 일을 하며 나를 부르는 호칭이 여러 번 바뀌었다. 그런데 그 이름 중 내 마음에 드는 것은 하나도 없었다. 웹에 관심을 갖던 초창기 학생이었던 나는 웹이라는 새로운 인터페이스와 브라우징을 통한 손쉬운 콘텐츠 입수에 흥분해 있었고 그것을 전문 잡지나 신문 등에 기고를 하기도 했다. 이와 관련하여 책을 두 권 쓰기도 했는데 그 이후 더 많은 잡지에 글을 썼다. 당시 나와 같은 일을 하는 사람을 '테크라이터'라고 불렀다.





몇 년 후 졸업을 하고 웹 서비스를 전문으로 하는 회사에 들어갔는데 그 회사에서 새로운 웹 서비스를 기획하고 운영하는 일을 했다. 사람들은 그런 일을 하는 나를 '웹 마스터'라고 불렀다. 이후 전망을 다소 수정하여 신규 사업에 걸맞는 웹 서비스를 발굴하고 조직하는 일을 했는데 사람들은 나를 '신규사업기획자'라고 불렀다. 또 몇년이 지났고 나는 두 군데 정도의 회사에서 새로운 웹 서비스를 만들었다. 그 회사의 사장과 협의를 하여 새로운 사업에 필요한 웹 서비스를 총괄 기획, 개발하는 역할을 했는데 그 때 나에 대한 호칭은 따로 없었다. PM(Project Manager)라고 부르는 사람도 있었지만 실제 PM은 따로 있었다. 대개의 사람들은 '사업본부장'이라고 불렀는데 그것도 적절하지 않았던 것이 새로운 웹 서비스를 관리할 뿐만 아니라 실제 개발의 핵심적인 부분에 개입하고 있었기 때문이다.

그리고 최근 3년 간 나는 새로운 웹 서비스를 만드려는 사람들을 돕고 조언하며 개발의 방향을 제시하는 '웹 서비스 컨설턴트'라는 이름으로 불리고 있다. 그런데 이것도 제대로 된 호칭은 아닌 것 같다. 컨설턴트라는 직업의 정의를 따르자면 조언과 교육의 역할이 중요한데 나는 실제로 새로운 서비스의 개발을 핵심 위치에서 지도했기 때문이다. 오랜 시간 동안 웹과 관련된 일을 하고 있지만 어떤 순간도 나의 정체성을 정확히 표현하는 호칭을 들어 본 적 없다. 바보같이 들릴 지 모르겠지만 이 글을 쓰고 있는 지금도 내 직업의 정체성이 뭔가 고민하고 있다.


10여년 전 '웹 마스터'라고 불리는 사람들의 모임에 참석한 적 있다. 그들은 웹 마스터라는 직업의 정의와 해야 할 일, 미래에 대해 심도 깊은 토론을 했다. 그런데 토론 중 이상한 느낌을 받았다. 웹 마스터 모임이라서 그런 것인지 모르겠지만 참석자들은 웹 마스터에 대해서 이야기하고 있을 뿐이었다. 웹 사이트 개발도 웹 마스터 중심이어야 하고, 운영도 웹 마스터 중심이어야 하고, 마케팅도 그렇고, 프로모션도 그렇고... 모임이 끝나고 뒷풀이 자리에서 발표자들에게 질문을 했다, "혹시 이 모임이 수퍼 히어로 모임이었나요?" 그 모임에 다시 나가지 않았다.

당시 웹 마스터라고 하면 웹의 모든 것을 알고 있는 사람이었다. 프로그래밍도 하고 디자인도 하고 운영도 하는 그런 역할의 사람이었다. 그런데 당시에도 프로그래머가 있었고, 디자이너도 있었고, 기획자도 있었고, 마케터도 있었고, 프로모터도 있었고, 경영진도 있었다. 그럼 웹 마스터는 무엇인가? 시간이 흐른 후 '웹 마스터'라는 직종은 완전히 사라졌다. 그리고 그 시절을 돌이켜 볼 때 웹 마스터에 대한 정의를 다시 내릴 수 있었다. 소규모 영세 웹 사이트를 운영하는 신생 기업에서 웹과 관련한 전반적인 사항을 해결할 수 있는 능력을 가진 사람을 '웹 마스터'라고 불렀던 것이다. 웹의 초창기에는 하나의 웹 사이트를 만드는 것을 한 개인이 해 낼 수 있는 환경이었다. 나 또한 몇몇 웹 사이트를 혼자 만들었고 혼자 운영했다. 야후!와 구글의 초기 버전도 마찬가지다. 그 당시에는 혼자 혹은 소수의 뛰어난 능력을 가진 사람들이 만든 웹 사이트나 웹 서비스가 매우 많았다.

그러나 웹이 산업화되고 웹 서비스의 규모가 커지면서 혼자 만들 수 있는 웹 서비스는 점점 줄어들기 시작했다. 웹이 산업화된다는 것은 한 사람의 능력 이상이 필요한 영역이 점점 늘어간다는 소리며 하나의 웹 서비스를 만들기 위해 여러 분야의 전문가들이 필요하다는 말이기도 하다. 그러나 웹을 기반으로 사업을 하려는 모든 회사가 웹 서비스 개발 인원을 충분히 확보하고 있는 경우는 드물다. 기존에 다른 사업을 하고 있는 회사가 웹을 기반으로 사업을 확대하려는 경우도 매우 많았다. 이런 회사의 경우 웹에 대한 전문 인력이 부족한 상태였다. 그렇다고 새로운 인력을 뽑자니 웹과 자기 회사의 사업적 관계를 확신하기 힘들었다.

이런 요구에 의해 웹 사이트나 서비스를 대신 만들어 주는 웹 에이전시 산업이 부흥하기도 했다. 웹 서비스가 정교화되고 복잡하며 보다 높은 기술적 수준을 요구할수록 애매한 직종인 웹 마스터는 설 자리를 잃었고 현재 웹 마스터라는 호칭은 아예 사라져 버렸다. 대신 웹 기획자나 웹 마케터, 웹 개발자, 웹 디자이너와 같은 신규 업종이 생겨났다. 새로운 직종들의 접두사는 모두 '웹'이다. 때문에 이 직종들에 대한 정의는 아주 간단하다. 웹 기획자는 "웹이라는 환경에서 기획을 하는 사람"을 말한다. 웹 마케터는 "웹이라는 환경에서 마케팅을 하는 사람"을 말한다. 그런데 "웹"은 도대체 뭐지?

"웹은 도대체 뭐지?"라는 질문에 대해 정확히 대답하는 사람은 없었다. '인터넷의 한 프로토콜로써 브라우저를 통해 접근할 수 있는 네트워크'라고 멋지게 정의해 버릴 수 있지만 그것으로 불충분했다. 하지만 충분한 논의가 없는 상태에서 웹은 급격히 산업화되었고 이미 웹의 사용자와 웹을 통해 장사를 하는 사람들은 수억 명을 넘어서고 있었다. 개념 따위가 뭐가 중요하겠는가, 온 천지에 돈 벌 수 있는 기회가 널려 있는데! 그렇게 시간이 흘러갔고 닷컴 버블이 닥쳐왔다. 닷컴 버블이 꺼지면서 웹에 기반한 많은 사업자가 도산하거나 파산했고 투자자들은 원금을 회수하기는커녕 쪽박을 차는 경우가 발생했다. 몇년의 암흑기가 흐르는 동안 일부 사람들이 웹에 대해 다시 생각하기 시작했다. 그리고 드디어 '웹 2.0'이라는 횃불이 밝혀졌다. 웹은 여전히 유의미하다고 주장하며 - 투자할만한 가치가 있다는 말을 점잖게 하는 말이다 - 웹에 기반하여 성공한 사업자들의 성공 신화를 널리 퍼뜨리기 시작했다. 웹은 다시 생명을 얻었다. 그런데 "웹은 도대체 뭐지?"

웹에 대한 정의는 매우 간단하다. 다만 웹은 시스템으로 이해하는 수준이 아니라 산업적으로 이해를 해야 하기 때문에 그 정의가 복잡해진다. 게임 산업에서 이야기하는 웹과 탄광 산업에서 이야기하는 웹은 전혀 다르다. 게임 산업에서 웹은 새로운 게임을 배포하고 가입자를 확보하는 가장 유력한 채널이지만 탄광 산업에서 웹은 탄광 산업에 대한 이해도를 높여주는 웹 페이지 몇 개를 의미할 뿐이다. 게임 산업에서 웹은 모바일, IPTV, 임베디드 디바이스 등 다양한 영역으로 게임 콘텐츠를 확대할 수 있는 멀티 플랫폼이다. 탄광 산업에서 웹은 그런 의미가 없다. 게임 산업에서 웹에 대해 연구하고 개발하는 수 많은 인력이 존재한다. 탄광 산업에서 웹과 관련한 인력은 사업장의 컴퓨터 수리를 함께 하는 사람일 수 있다. 웹과 관련한 업무에 종사하는 사람들은 '웹'이라는 큰 개념에서 공통점이 있지만 그보다 훨씬 큰 산업 부문에서 개별성이 있다. 그 개별성 때문에 웹과 관련한 일을 하는 사람들은 과거 10년 전보다 훨씬 많아졌지만 공통점을 찾기 점점 힘들어지고 있다.


웹 기획자를 대상으로 한 강연을 자주 했었는데 가장 난감한 경우가 이런 제목의 강연을 할 때다,

"성공적인 웹 사이트 운영을 위한 노하우"

이런 제목은 매우 매력적이다. 강연을 의뢰하는 기업은 항상 이런 식으로 매력적인 제목을 뽑아서 많은 사람을 모으려고 한다. 그 제목에 반대하며 좀 더 실질적인 제목을 제안하기도 했다. 이를테면,

"온라인 신문 사이트의 구독자 확대를 위한 부가 서비스 기획 방안"

그 러나 이런 제안은 받아들여지지 않았다. 너무 구체적이어서 올 사람이 별로 없다는 것이다. 어쨌든 제목은 매력적인 것으로 정해지고 시간이 흐르고 사람들이 모인다. 나는 부담스러운 마음으로 강연장에 입장해서 인사를 하고 강연을 시작한다. 시간이 지나면 내 강연은 주제를 잃고 헤매기 시작한다. 강연장에 앉은 사람들과 눈을 맞추는 것이 점점 힘들어진다. 시간이 지날수록 구석에서 졸고 있는 사람들도 보이고 불만에 가득찬 표정으로 낙서를 하고 있는 사람들도 보인다. 주제 자체가 잘못된 것이니 이미 강연은 끝장난 것이다. 이런 강연을 몇 번 하고 나면 누구도 다시는 강연을 하고 싶지 않은 마음이 든다.

아마 10년 전이라면 애매한 제목의 강연이 성공적이었을 것이다. 그저 웹 마스터라고 개념도 제대로 잡히지 않은 직종이 존재했을 무렵엔 이렇게 이야기해도 먹히고 저렇게 이야기해도 먹히는 '일하는 방법'에 대해 공감하는 사람이 많았을 것이다. 그러나 그것은 과거 이야기다. 이미 웹은 충분히 산업화되었고 산업의 개별적 특성에 따라 웹이 적용되는 범위와 형태는 세분화되어 버렸다. 웹 마스터라는 직종이 사라져 버린 것처럼 이제 웹은 산업 부문에 따라 세분화되고 전문화되어 있기 때문에 더 이상 "웹의 공통적 제어 방법" 따위를 이야기하는 것은 허구다. 만약 다음과 같은 단어가 포함된 웹과 관련한 강연이나 컨퍼런스가 있다면 절대 참석하지 말아야 한다.

- '모든',  '절대적인', '성공하는', '실패하지 않는', '최신의'


이 즈음이면 웹의 기원이 무엇인가 고민하는 사람이 있을 것이다. 웹의 기원을 알고 싶다면 창안자의 이야기를 듣는 게 바람직하다. 해설서보다 원본을 먼저 보라는 조언을 또 할 필요는 없을 것이다. 웹(World Wide Web)의 개념을 제안한 사람은 누구인가 검색해 보라. 검색에서 실수를 하지 않았다면 두 사람의 이름을 찾을 수 있을 것이다. 만약 팀 버너스 리라는 이름만 찾았다면 할 수 없다. 하긴 역사는 가장 뛰어났던 사람만 기억하는 법이다. 사람들은 토머스 앨바 에디슨이 1000개가 넘는 특허를 등록했다는 것만 기억하지 그의 특허를 위해 헌신했던 수천 명의 다른 연구자들은 전혀 모르지 않나. 에디슨의 발명 중 대부분은 다른 연구자들이 최초 발견했던 것일 수도 있는데 말이다. 어쨌든 웹의 개념을 최초 제안한 사람은 팀 버너스 리라고 해 두자. 그게 아니라고 생각했다면 근처에서 프로젝트를 함께 진행했던 다른 학자들이 소송을 걸었을텐데 아무런 이야기가 없으니 그냥 그렇게 인정하자. 팀 버너스 리가 1990년에 CERN에서 일할 때 웹의 개념을 세우고 그 다음 해인 1991년 유즈넷의 뉴스그룹인 "alt.hypertext"에 웹에 대해 처음 소개한 글은 이런 것이었다. 고리타분한 내용이지만 이것이야말로 웹의 근본을 이해할 수 있는 것이니 반드시 읽어야 한다.



이 쉬운 문장을 굳이 번역할 생각은 없다. 이 문장에 대한 번역은 일종의 신성 불가침이다. 팀 버너스 리가 뉴스그룹에 올린 글의 내용은 일종의 종교 창시자가 내린 10계명과 같다. 그가 내린 계명은 모두 이뤄졌다,

- 웹의 콘텐츠는 읽기만 할 게 아니라 검색도 될 것이다 : 구글이 최선봉에서 구현했다
- 여러가지 포맷의 문서가 있을텐데 어쨌든 똑같이 읽을 수 있을 것이다 : 브라우저와 OS의 합작으로 해결되었다
- 그냥 클릭만 하면 모든 데이터을 읽을 수 있다 : 물론이다
- 다른 프로토콜(FTP, NNTP)의 데이터도 읽을 수 있다 : 물론이다
- 웹 페이지를 만드는 것도 정말 쉽다 : 매일 수백만 개의 새로운 웹 페이지가 만들어지고 있다, 블로그를 보라!
- 모든 형태의 데이터를 공유하려면 애플리케이션의 표준이 필요하다 : Flex를 보라
- 이게 끝이 아니다 : 나도 안다

그 는 이런 계명 뿐만 아니라 1991년 시점에서 브라우징할 수 있는 알파 버전의 브라우저와 테스트 서버와 테스트 파일까지 공개해 두고 있다. 이런 노력을 했으니 팀 버너스 리는 웹의 창시자라고 불려도 손색이 없을 듯 하다. 나머지 몇 명은 대충 넘어가도 좋다. 팀 버너스 리의 뜻을 따라 수 많은 사람들이 웹이라는 공간에 뛰어 들어 개발과 개선과 혁신을 거듭했다. 그리고 지금의 웹이 존재하고 있다. 이제 웹의 근본을 알았으니 다시 웹에서 일하는 사람 이야기로 넘어가 보자.


웹기획자란 무엇인가? 1999년 쯤 이 직종을 처음 들었는데 지금도 여전히 '웹 기획자'라는 표현에 대해 매우 안타까운 느낌이다. 웹을 뭐 어떻게 기획하겠다는 것인가? 웹에 대해 연구하는 사람인가? 팀 버너스 리의 연구 과제를 이어 받아 웹을 좀 더 개선하려는 사람들인가? 아니다. 현실에서 '웹 기획자'는 '웹 사이트 기획자'를 의미한다. 그럼에도 불구하고 여전히 웹 기획자라는 단어에 뭔가 더 큰 굉장한 의미가 있다고 착각하는 사람들이 있다. 이 착각은 그들의 잘못이 아니다. 오히려 자신이 하는 일을 뭔가 그럴싸하게 포장하고 의미를 부여하고 싶었던 초창기 웹 기획자라는 단어를 만든 몇몇 개념없는 사람들에 의해 만들어진 허튼 착각이 계속되는 게 문제일 뿐이다.

웹 기획자는 학술적인 측면에서 천체 물리학자나 상담 심리학자나 해양 생물학자와 비슷한 것이다. 기획자라는 범주에서 '웹'이라는 전문 분야를 갖고 있는 사람이라는 말이다. 만약 자신을 '웹 기획자'라고 부르는 사람이 있다면 이 사람은 팀 버너스 리처럼 웹이라는 프로토콜이나 시스템에 대해 기획하는 사람이 되어야 한다. 대학원으로 가는 게 바람직하다.

현재 스스로 '웹 기획자'라고 부르는 사람들 대부분은 '웹 사이트 기획자'다. HTTP 프토토콜로 접근할 수 있는 웹 페이지를 기획하는 사람이다.

<html> 안녕! </html>

이 런 HTML 문장을 쓸 수 있는 사람이면 모두 웹 사이트 기획자다. 저 한 문장을 저장하고 확장자를 html로 바꾼 후 웹 서버에 올리면 바로 웹 페이지가 되기 때문이다. 웹 사이트 기획자는 이런 식으로 HTML을 이해하고 그것을 웹이라는 공간에 노출시킬 수 있는 방법을 아는 사람을 말한다. 웹 사이트에 대한 요구가 더 복잡해지면 더 많은 HTML 코드를 알아야 할 것이다. 스크립트가 들어갈 수도 있고, 데이터 전달 포맷이 들어갈 수도 있고, 플래시와 같은 리치 미디어가 들어갈 수도 있지만 결국 웹 사이트 기획자는 '출력'에 관계된 일을 기획하는 사람이다. 잡지로 치면 레이아웃 기획자다.

그런데 많은 웹 기획자들은 이 정도의 일이 자신이 할 바는 아니라고 생각한다. 많은 웹 기획자들은 웹 사이트에 대한 콘셉트와 형식과 사용자 편의성과 운영에 대한 기획을 해야 한다고 생각한다. 만약 당신이 그런 생각을 갖고 있다면 당신의 정체성은 '웹 콘텐츠 기획자'다. 웹 사이트의 콘셉트와 형식과 편의성과 운영은 '콘텐츠'에 의해 지배받기 때문이다. 여기서 고개를 갸우뚱하는 사람이 있을 것이다. 자신은 콘텐츠 기획과 함께 새로운 형태의 서비스도 기획하고 있다고 생각하는 사람 말이다. 예를 들어 사용자들이 올린 사진 이미지를 조합하여 동일한 취미를 갖는 사람을 친구로 엮어 주는 서비스를 기획하는 웹 기획자도 있을 것이다. 이들의 정체성은 무엇인가?

이런 새로운 서비스를 기획하는 사람들은 '웹 서비스 기획자'라고 부를 수 있다. 서비스의 개념을 소프트웨어적인 개념으로 생각하지 말아야 한다. 여기서 말하는 서비스는 소프트웨어의 일부분으로써 동작하는 서비스이기도 하지만 근본적으로 사용자들이 참여하여 만족하고 반복 사용하는 웹 페이지 전반을 이야기한다. 웹 서비스는 소프트웨어를 활용하여 웹에서 이용할 수 있도록 하는 것이기도 하지만 웹 페이지 자체가 새로운 콘텐츠를 생산하는 것을 의미하기도 한다. 웹 서비스 기획자는 이 둘 중 하나를 선택하면 된다. 그런 결정권을 가지고 선택할 수 있는 사람이 웹 서비스 기획자다. 웹 서비스 기획자는 사용자의 사진 이미지를 저장하고 공유하는 방법으로 파일 업로드 도구를 직접 개발하도록 기획할 수도 있고, 이미 개발된 모듈을 구매할 수도 있고, 플리커나 네이버와 제휴하여 그들의 서비스를 이용할 수도 있다. 어떤 것이 가장 '합리적'인가 선택하는 권한이 있으며 그런 선택을 하는 것이 웹 서비스 기획자다.


웹 기획자는 허망한 단어다. 웹에 대한 개념이 산업적으로 너무나 세분화되었기 때문에 이제 웹 기획자라는 말은 의미가 없다. 자신이 원하는 바에 의해 웹 사이트 기획자가 될 수도 있고, 웹 콘텐츠 기획자가 될 수도 있고, 웹 서비스 기획자가 될 수도 있다. 각각에 대해 산업이 요구하는 역량와 경험과 지식은 매우 큰 차이가 있다. 어떤 웹 사이트 기획자도 모든 웹 사이트에 대한 기획을 할 수 없다. 이 평범한 진리를 웹 기획을 하려는 사람들은 자주 잊는다. 웹 사이트든 웹 콘텐츠든 웹 서비스든 우리는 제한된 부분에 대하여 기획을 할 수 있을 뿐이다. 모바일 웹 사이트를 성공적으로 기획한 기획자가 모든 웹 사이트를 성공적으로 기획할 수 있는가? 게임 웹 콘텐츠를 성공적으로 기획한 기획자가 모든 웹 사이트를 성공적으로 기획할 수 있는가? 커뮤니티 웹 서비스를 성공적으로 기획한 기획자가 모든 웹 사이트를 성공적으로 기획할 수 있는가? 모두 NO라고 대답하는 것에 대해 우리는 왜 항상 '그럴 수도 있다'라고 거짓말하는가?


그렇다면 모든 웹 기획자들은 자신이 성공한 한 분야에 머물러야 하는가라는 질문이 생긴다. 커뮤니티 웹 사이트를 성공적으로 만든 기획자가 상거래 사이트에서 성공할 가능성은 0%인가? 이 질문에 대한 대답은 간단하다, "개념의 혁신"

지 금까지 우리는 어떤 회사에 소속된 '기획자'라는 관점에서 웹 기획자에 대한 이야기를 했다. 이 개념 속에서 웹 기획자는 늘 자기 한계의 그늘을 벗어날 수 없다. 무엇을 하든 어떤 일을 하든 누구와 만나든 늘 '회사'와 그 회사의 '목표'에 제약되는 생각과 행동을 할 수 밖에 없다. 내가 아는 어떤 기획자는 한 회사에서 10년을 일하고 있다. 그는 매년 회사에서 수 없이 많은 제안을 하지만 늘 회사의 주 수익 모델인 웹 사이트의 기획만 하고 있다. 그의 연봉은 계속 높아지고 있고 회사의 매출은 늘어가고 있지만 그는 오늘도 자신의 기획 역량이 회사 내부에 머물러 있음에 침통해한다. 그는 무슨 잘못을 하고 있는 걸까? 내가 생각하는 그의 유일한 잘못은 현재의 위치를 떠나지 못하는 것이다. 안정적이며 편안하고 미래가 보장되는 위치를 유지하는 것은 곧 변화하는 미래를 스스로 제거하는 것이다. 그는 웹 기획자로서 변화를 거세하며 변화를 바라는 딜레마에 빠져 있다.

웹 기획자가 경쟁의 정글에 스스로 던져 버릴 각오가 있다면 이제부터 자신을 '웹 서비스 디렉터(Web Service Director)'라는 이름으로 불러야 한다. 내가 만들고 싶은 새로운 서비스가 있는가? 그 서비스를 어떻게 만들 것이며 얼마의 비용이 필요하며 얼마의 기간이 소요되며 어떤 사람이 있어야 하며 어떻게 성장할 것이며 누구를 만나야 첫 시작을 할 수 있을 것인지 알고 있는가? 그렇다면 지금부터 웹 서비스 디렉터의 길을 걸어야 한다. 웹 서비스 디렉터는 자신이 회사이며 자신이 자본이고 자신이 원동력인 1인 기업이다. 영화로 치자면 감독이다. 감독 중에도 독립 영화 감독 쯤 될 것이다. 선택은 자신의 몫이다. 웹 기획자라는 애매하고 이런 저런 일에 언제든 얽힐 수 있는 일을 하든 웹 콘텐츠 기획자가 되든 웹 서비스 기획자가 되든 웹 서비스 디렉터가 되든 어떤 선택을 하든 자신의 몫이다. 그러나 선택 뒤의 결과에 대해 분명히 알아야 한다. 어떤 선택이든 결과는 제각각이지만 한 가지는 분명히 말할 수 있다. 좀 더 복잡한 일을 하려고 할수록 고통은 깊고 댓가는 값지다.

이 글을 읽는 사람들은 아마도 내가 '웹 서비스 디렉터'를 가장 추천하고 있다고 생각할 지 모르겠다. 그러나 달리 생각해 보라. 가장 힘들고 어렵고 추천하기 힘든 일을 가장 끝에 이야기하는 게 인지상정 아닐까? 세상 어디에도 쉽고 빠르게 최고의 경지에 도달할 수 있는 방법은 없다. 오래 전에 경보 경주를 본 적 있는데 멀쩡한 사람이 그 경주에 끼어들었는데 상위 등수에 들지 못했다. 신체 장애자들은 목숨을 걸고뛰었고 그 사람은 그냥 열심히 뛰었다. 토끼와 거북이의 이솝 우화와 같은 이야기다. 세상 어디에도 한 번에 최고의 경지에 이를 수 있는 경우는 없다 .심지어 병신들과 함께 뛰는 경주에서 자칭 정상인이라는 자가 일등을 하지 못했다. 당시 그는 한 쪽 다리 뿐인 사람들을 우습게 보았고 심지어 그들과 뛰며 농담도 했다. 문제는 그 경주의 길이가 12km였다는 것이다. 그는 5km부터 뒤지기 시작했고 장애인들은 느리지만 꾸준한 레이스를 펼쳤다. 그는 결국 8km 지점에서 기권을 했다. 경기에 참여한 장애인들은 모두 결승선에 도달했다. 가장 마지막에 도달한 장애인은 11시간이 걸렸다.

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




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


거부

새로운 웹 서비스를 개발하기 위한 프로젝트가 시작되었고 팀이 구성될 시점이다. 누군가 이 팀을 총괄할 팀장 역할을 수행해야 한다. 팀장 대신 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++ 프로그래머의 라이브러리에 대한 질문과 대답"이라고 정할 수도 있을 것이다. 그런 게시판을 만들어 보라. 누군가 그 게시판에 "오늘 점심 메뉴는 뭐가 좋을까요?"라는 질문을 하지 않을 것이라고 확신할 수 있는가? 그런 게시물을 다른 게시판으로 옮기는 자동화 소프트웨어를 만드는 것이 무슨 의미가 있겠는가?

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

지난 주 한 웹 사이트의 스토리보드를 검토하다 발견한 사소하지만 모든 웹 사이트에 공통으로 적용할 수 있는 두 가지 사항을 이야기하려 한다. 주제는 상품 신청에서 '약관 동의'에 대한 인터페이스 처리다.







고객사의 경우 구매할 상품을 선택한 후 '결제하기' 버튼을 누르면 현재 신청 상품에 대한 긴 페이지가 나타난다. 과거에 여러 페이지를 거쳐서 결제가 처리되던 것을 편리하게 만들긴 했지만 페이지의 길이가 길어지는 문제가 발생했다. 이 문제는 그냥 내버려둬도 상관없다. 어차피 사용자가 다 읽어야만 하는 내용으로 구성되어 있기 때문이다. 링크나 스크립트로 내용을 숨기면 오히려 더 많은 문제 - 도대체 그 내용이 어디 있는거죠!라는 항의에 직면할 가능성이 높다.

이렇게 길게 페이지 스크롤이 발생해도 문제없다고 내가 보장했다. 내 경험에 의할 때 이런 결제 페이지에서 일부 내용을 링크나 스크립트로 짧게 만들면 더 많은 문제에 처한다. 그런데 이 페이지에서 뭔가 문제가 있는 게 있었는데 '구매 약관 동의' 체크 버튼이 그것이었다. 첫번째 문제는 위치였다.

최초 스토리보드에서는 "결제" 버튼 뒤에 구매 약관 동의 체크 버튼이 붙어 있었다. 그래서 '결제하기' 버튼을 클릭하면 "구매 약관에 동의하셔야 합니다"라는 에러 메시지가 뜨도록 되어 있었다. 아마 웹 사이트에 이렇게 구현이 되어 있었다면 금세 바보 같은 인터페이스라는 걸 알아차렸을 것이다. 그러나 파워포인트로 작성된 스토리보드로는 그런 현상을 발견하기 힘들다. 실제 동작하는 것을 상상하며 문서를 읽어야 하기 때문에 발생하는 문제다.

그래서 약관 동의 부분을 결제 버튼 앞으로 옮겨 놓았는데 비록 '결제하기'까지 이동하는 페이지의 길이는 더 길어졌지만 어쨌든 사용자가 "이제 다 끝났고 돈만 내면 된다"고 생각하고 버튼을 클릭했을 때 "약관에 동의하라"는 멍청한 에러 메시지를 보내지 않게 되었다. 그런데 내가 발견한 또 다른 문제는 이 약관 동의에 대한 체크 버튼이다. 두 버튼은 '약관에 동의함'과 '동의하지 않음'이다. 라디오 버튼 대신 체크 버튼을 둔 것은 사용자가 약관의 내용을 모두 읽도록 강제하기 위함이다. 실제도 다 읽지 않더라도 라디오 버튼으로 둘 경우 그냥 '결제하기'를 클릭해도 되기 때문에 체크 버튼으로 처리한 것이다.

그런데 라디오 버튼이 되었든 체크 버튼이 되었든 둘 중 '약관에 동의함'을 선택하지 않으면 어차피 '결제하기' 버튼을 선택할 수 없다. 왜냐면 결제를 하려면 결제 약관에 무조건 동의해야 하기 때문이다. 이것은 마치 웹 사이트 회원 가입 시 사용자 약관에 동의하지 않고 회원 가입을 할 수 없는 것과 같은 이치다. 그렇다면 왜 '약관에 동의함'과 '동의하지 않음'을 선택할 수 있도록 한 것인가? 그냥 "약관에 동의하며 결제합니다"라는 버튼 하나만 존재하면 그만 아닌가? 약관에 동의하지 않으면 어차피 결제도 할 수 없으니 그냥 페이지를 닫고 나가면 그만이다.

이 부분에 있어서 법률적 문제가 있는 지 확인해 봤는데 전혀 문제가 없다. 우리는 종종 웹 사이트를 만들며 사용자에게 많은 선택의 여지를 주는 게 좋다고 착각하는 경우가 있다. 꽤 많은 경우 소위 '사용자의 선택'은 실제 불필요한 선택인 경우다. 사용자 약관에 동의하지 않으면 회원 가입을 할 수 없는 회원 가입 페이지, 구매 약관에 동의하지 않으면 결제할 수 없는 결제 페이지, 개인정보 이용 약관에 동의하지 않으면 참여할 수 없는 이벤트 페이지 등등 사용자에게 선택을 요구하는 것 같지만 실제로 선택할 수 없는 인터페이스가 너무 많다.

흔히 사용자가 잘못된 데이터를 입력했을 때 웹 사이트는 에러 메시지를 돌려 준다. 대개의 에러 메시지는 아무런 고려 없이 프로그래머의 성향에 따라 만들어진다... 이 부분에 대해 8년 전에 기획자들에게 이야기를 한 것이 있다. 기억 나는 것을 옮기면 이렇다.





"사용자가 잘못된 URL을 입력했을 때 어떤 메시지가 나타나야 할까요? Apache 서버에서 기본으로 나타나는 기술적인 메시지가 있습니다. 현재 대부분의 웹 사이트는 이걸 그대로 노출하고 있습니다. 그런데 이 부분 즉, 404 error를 나타내는 메시지를 적절하게 만든다면 좀 더 친절한 웹 사이트가 되지 않을까요?"

내가 인덕이 없었던 것인지 이 이야기를 들은 기획자들은 다들 '바빠 죽겠는데 그런 메시지 고칠 시간은 없다'고 대답했다. 나는 지금도 웹 기획자들에게 404 error 메시지와 같은 디폴트 페이지를 사이트에 맞게 바꾸라고 요구하곤 한다. 그런 사소한 에러 메시지를 고려하지 못하는 웹 기획자라면 기획의 기본이 되어 있지 않다고 믿기 때문이다. 기획의 기본은 이런 것이다,

"내가 할 수 있는 모든 것에 관심을 갖는다"

그 관심을 기술적인 영역으로 옮길 수 있는 사람이 진정한 웹 기획자다. 아래 3개 사이트의 404 에러 메시지를 보라. 뭐 느끼는 게 있어야 비로소 웹 기획자의 기본 마인드는 가진 것이다. 아무런 느낌이 없었다면 전업을 생각해 보는 게 좋다.





3개 웹 사이트는 몇 년 전까지도 404 error 페이지에 대해 무심했다. 그러나 이런 고민 - 할 수 있는 한 모든 곳에 관심을 가져야 한다 - 을 통해 현재 404 error 페이지는 기본 값을 쓰지 않고 사이트에 맞게 수정되었다. 물론 여전히 하위 페이지로 가면 아무런 대안 없이 기본 에러 페이지가 나오는 경우는 있다.

모든 곳에 대한 관심. 이것이 현재를 사는 웹 기획자들에게 필요한 기술이다. 태도나 자세가 아니라 왜 기술이냐고 물을 수 있을 것이다. 웹 기획자들은 태도와 자세를 기술을 통해 증명해야 한다. 훌륭하고 성실한 태도와 자세만 갖고 기획한다고 바뀌는 것은 아무것도 없기 때문이다. 보이는 무엇을 만들어내야 비로소 웹 기획자라고 할 수 있다.

아는 분만 알고 있는 제 책쓰기 관련 역사가 있습니다. 벌써 햇수로 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일 경 글을 읽을 수 있고 대화할 수 있는 블로그 주소를 알려 드리겠습니다.

웹 2.0에 대한 이야기를 할 때 거의 빠지지 않고 등장하는 주제가 '위치와 정보'를 다루는 지도 서비스다. 대표적인 예제가 구글어스나 구글 맵스 같은 것이다. 내가 이런 주제에 대해 고민할 때 참조하는 블로그가 한 군데 있다.






<웹 2.0과 인터넷 지도>


이 블로그는 제목 그대로 웹 2.0에 대한 관심을 지도 서비스에 집중하여 이야기를 풀어 내고 있다. 이 블로그의 글을 읽어 본다면 - 제목 리스트를 보거나 - 웹 2.0과 관련한 지도 서비스의 몇 가지 이슈를 이해할 수 있다.

지도 서비스는 연구하기에 매우 흥미로운 주제지만 깊이 파고 들기엔 일반인의 접근성이 낮고 때문에 이런 주제의 블로그를 계속 유지하려면 업무상 관련성이 있거나 깊은 개인적 비전이 연관되지 않으면 힘들다. 발견하기 힘든 종류의 블로그니 북마크 해 두는 것이 좋다.


내가 웹 2.0 서비스를 기획할 때 지도 관련 정보를 고민하게 되는 이유는 세 가지 정도다. 첫번째는 익숙한 비주얼이고 두번째는 개별화된 경험의 통합 인지이며 세번째는 검색 가능성이다. 이 세가지 요소가 기획에서 중요한 의미를 갖게 될 때 지도 서비스의 도입을 구체적으로 고려하게 된다. 그런데 실제로 지도 서비스를 새로운 웹 2.0 서비스에 도입하려면 걸리는 문제가 하나 둘이 아니다. 가장 흔한 문제는 특별한 콘텐츠에 대한 착각이다. 많은 고객사나 서비스 개발사가 자신들이 '특별한 콘텐츠'를 '아주 많이' 보유하고 있다고 생각한다. 그러나 막상 지도 위에 그 콘텐츠 혹은 데이터를 펼쳐 놓으면 정말 별 것 아닌 정보가 되어 버린다.


리크루팅 서비스의 예

지도 서비스는 기본적으로 지리 관련 정보를 담고 있다. 이런 지도 위에 뭔가 특별한 정보를 얹는 것이 필요한데, 문제는 지도라는 광대한 프레임을 제대로 덮을 수 있는 정보를 마련하기 쉽지 않다는 것이다. 일례로, 한 리크루팅 기업이 지도라는 비주얼을 통해 각 지역에 업데이트되는 구인 정보를 구현하려고 했다. 이 기업은 하루에 수 천 건의 새로운 정보가 올라오기 때문에 충분히 지도 서비스를 이용할 수 있을 것이라 '예측'했다.

그러나 막상 서비스를 구현하려고 지도에 구인 정보를 매핑해 보니 아뿔싸, 서울 경기 지역에만 붉은 점(구인이 필요한 곳)이 가득 모여있고 다른 지역은 텅텅 비어 버리는 것이다. 좀 더 정확히 말하자면 서울 지역에 붉은 점의 80%가, 경기 지역에 10%가 그리고 나머지 10% 또한 경상남도 지역에 집중되어 있었다. 이 붉은 점은 정확히 그 리크루팅 업체의 고객 분포와 일치했다. 이런 상황에서 지도 서비스를 도입하는 건 무의미한 일이었다. 나는 어떻게 이 문제를 해결했을까?

세 가지 솔루션을 제안했다. 하나는 지도 서비스를 하지 않는 것이다. 고객이 지도 서비스를 계속 주장하고 있었기 때문에 포기하게 만드는 것도 좋은 선택 중 하나였다. 또 다른 하나는 서울 지역 지도 서비스만 여는 것이었다. 대신 서울 지역에 대한 지도 서비스는 구직자의 집과 구인 회사의 위치를 파악하여 이동 거리(도보, 대중교통, 자전거, 자동차)가 나타나게 하여 서비스 특성화를 해야 한다고 제안했다. 우리가 조사한 바에 의하면 구직자가 직장을 선택하는 가장 중요한 요건 중 상위 요건이 "출퇴근 거리"였다. 끝으로 사용자가 참여하여 지도의 나머지 부분에 구인 구직 정보를 매핑하는 방법을 제안했다. 구인사는 서울, 경기 지역에 집중되어 있지만 구직자는 전국에 분포되어 있었다. 구직자의 데이터는 임의로 매핑할 수 없었기 때문에 사용자 참여 형태의 서비스를 제안했다.


지도 서비스 도입 시 고려할 것

지도 서비스를 자신의 웹 사이트에 도입하려면 여러가지 고민이 필요하다. 앞서 이야기한 사례에서 고객사는 자신의 비즈니스가 전국적이니 '전국적 지도 서비스'를 제공하면 좋겠다는 순진한 생각만 했다. 아마 그런 생각으로 서비스를 만들었다면 고가로 지도 서비스를 사와 붙인 후 아무도 사용하지 않는 상황이 발생했을 것이다.

지도 서비스를 잘 이해하려면 정보 공학적 관점과 사용성에 대한 검토 그리고 '창조적으로 문제를 해결하려는 노력'이 필요하다. 웹 2.0 서비스를 구현할 때 지도 서비스를 고려하는 것은 "지리 정보"에 대한 고민이 아니라 지도라는 프레임 위에 자신만의 독특한 정보와 콘텐츠를 제공하는 것이 되어야 한다. 이 이야기가 너무 상식적이라고, 그래서 별로 도움이 되지 않는 조언이라고 생각하는 사람도 있을 것이다. 정말 그럴까?

그저 껍데기만 바라보고 판단하면 <11번가>의 지도 서비스같은 것이 나오게 된다. 이것이야말로 지도 서비스를 함부로 도입하면 어떤 결과나 나올지 보여주는 대표적인 사례다.

전  세계적으로 이메일을 통해 회원 가입을 받는 웹 사이트가 대세인 상황이다. 물론 한국의 경우는 여전히 주민등록 번호로 실명 인증을 하는 경향이 훨씬 강하다. 한국형 웹 비즈니스의 특징과 한국의 법률적 환경 때문에 소규모 웹 사이트나 web 2.0을 표방하는 일부 웹 사이트에서 이메일을 통한 회원 등록을 받고 있다.




이런 웹 사이트, 즉 이메일을 통해 본인 확인을 하는 웹 사이트의 경우 페이스북의 회원 가입 단계의 화면을 주목할 필요가 있다.



이메일을 통해 회원 식별을 하기 때문에 '회원 가입 확인 이메일'에 포함된 '승인 링크'를 클릭해야 회원 가입이 완료된다. 많은 웹 사이트는 이런 경우 "이메일을 확인하세요"라는 텍스트를 뿌려 줄 뿐이다. 페이스북을 비롯한 몇몇 웹 사이트는 위 그림에서 보는 것처럼 사용자의 이메일 주소 뒷 부분을 참조하여 "Go to Gmail now"와 같은 링크를 만들어 뿌려 준다. 간단한 기능을 구현함으로써 좋은 접근성을 제공하는 것이다.

이 기능을 구현하는데 매우 특별한 기술적 조건이 있는 것은 아니다. 프로그래머가 아니더라도 등록된 이메일 주소의 도메인 주소로 연결시켜주면 된다는 정도를 알 수 있을 것이다. 좀 더 생각을 한다면 도메인의 MX 레코드를 참조하여 이메일 도메인으로 연결할 수 있을 것이다. 조금 더 생각하면 잘 알려진 몇 천 개의 도메인 주소를 미리 입력해 두고 - 예를 들어 xxx@naver.com으로 등록했다면 mail.naver.com으로 연결되도록 해야 할 것이다 - 나머지는 자동 처리가 되도록 할 수 있을 것이다. 물론 이것보다 훨씬 훌륭한 방법을 프로그래머라면 제안할 수 있을 것이다.

매우 사소한 부분으로 보이지만 이메일을 통해 본인 확인을 하는 과정에서 발생하는 사용자의 인지 단절 - 새로운 브라우저를 열어서 가입 프로세스를 진행하거나 브라우저를 통한 화면 전환이 발생하는 것 - 을 어느 정도 해결할 수 있다. 이런 기능은 선택적으로 받아 들일 수 있는 기능 중 하나며 사실 큰 고민없이 받아 들여야 하는 기능이기도 하다.

내일 웹 기획 관련 강연이 있습니다. 제가 주최한 강연은 아닙니다. 그런데 참석자 숫자가 매우 적습니다. 몇 달 전에 제안이 들어 온 것이라 이제와서 거부할 수는 없지만 매우 저조한 참석자 때문에 강연에 대한 부정적인 생각이 듭니다. 이왕이면 많은 사람 앞에서 이야기를 하고 싶은 게 강연자의 심정입니다.



문득 한 가지 생각이 났고 오래전부터 했던 생각이라 이번 기회에 한 번 물어 보기로 마음 먹습니다. 만약 제가 웹 서비스 기획에 대한 유료 강연을 한다면 이 블로그를 찾아 오시는 분 중 몇 분이나 참석을 할까 궁금합니다. 여러분의 생각이 궁금합니다. 굳이 자신의 정체를 밝히기 싫으면 익명으로 댓글을 남겨도 좋습니다.

만약 아래와 같은 주제로 발표를 하고 참석 금액이 10만원이라면 여러분은 참석하시겠습니까?

1. 웹 서비스 기획 개론 (20분)
 - 웹 서비스 기획, 과거와 현재
 - 합리적 기획과 혁신적 기획

2. 웹 2.0 서비스 기획이란?
 - 도대체 그게 뭐야?
 - 웹 2.0의 현황과 적용할 수 있는 서비스 영역
 - 웹 2.0은 존재하는가? 아니면 그냥 그렇다고 생각하는가?

3. 웹 서비스 기획 그 이상의 문제
 - 사업 기획이 필요한 웹 서비스 기획
 - 누구에게 도움을 청할 것인가?
 - 아무도 도와주지 않을 경우

4. 성공적인 웹 서비스 기획
 - 웹 서비스 기획의 기본 요건
 - 혁신적이어야만 하나?
 - 내부에 대해 응대하는 방법은?

5. 웹 서비스 기획의 10가지 지침


만약 이런 주제로 3시간 가량 강연을 하고 그 비용이 10만원 정도라면 여러분은 강연을 들으러 오시겠습니까? 이 강의는 실전의 경험과 사례를 중심으로 진행될 것입니다. 서울에서 이 강연이 진행된다면 여러분은 들으러 오시겠습니까?

오늘 강연 자료를 쓰다 문득 이런 내가 제안하는 주제로 강연을 하면 더 많은 사람이 관심있을까 궁금했습니다. 그래서 이런 질문을 했습니다.