Flying Mate

올해 근황을 정리하는 글을 써야겠다고 생각한게 몇 달 전인데 이제서야 키보드를 두드립니다. 작년 말까지 필통넷을 만들었고, 올해 초부터 3월까지 Edufava라는 서비스를 만들었습니다. E-Learning 플랫폼이었는데 David Lee와 이창수님과 함께 단기 프로젝트 성격으로 진행했습니다.

David Lee는 캐나다에서 벤처를 성공시켜 매각한 후 한국으로 돌아와 저의 파트너가 되어 함께 스타트업을 만들어가고 있고, 이창수님은 파프리카랩을 공동창업하신 후 Edufava 프로젝트에 참여하셨다가 현재 일본으로 건너가 게임업체에서 일하고 계십니다. 결과적으로 Edufava는 사내 테스트 후에 개발 중단을 결정하게 되었습니다. 자체평가 하기로는 런칭도 전에 지나치게 복잡해진게 문제였습니다.

--

David와 저(James Lee)는 4월부터 Wetoku를 만들었고, 7월에는 ReadWriteWeb에 기사화되었습니다. Killerstartups나 Makeuseof 등에도 리뷰가 되었습니다. 가이가와사키 인터뷰에도 사용되었습니다. ReadWriteWeb에 기사화 되었을 때는 기분이 들떴었는데 참 자랑하고 싶어도 주변에 RWW를 아는 사람이 거의 없어 David와 저 둘이서만 서로 좋아라 했었던 것 같네요. 이 블로그를 보시는 분들은 RWW와 가이가와사키를 당연히 아시리라 믿습니다 ㅎㅎ

그동안 해외 서비스들을 벤치마킹해오면서 RWW나 Techcrunch, Mashable를 3년 이상 읽어오고 있는데, 이들 미디어에 리뷰되고 나서 망한 서비스들도 많지만, 성공한 서비스들 가운데 여기에 리뷰되지 않은 서비스들 또한 없기 때문에, Wetoku가 리뷰되었을 당시에 '관문 하나는 통과했다' 라는 생각을 했던 것 같네요.

--

Wetoku의 서버사이드는 Ruby on Rails로 만들고 있지만 사실 레일스 쪽 보다는 Flex와 영상 스트리밍 처리 등이 까다로왔고 그 부분이 개발 시간의 대부분을 차지했었는데 이제는 익숙해져서, UI개발(xhtml/css)과 서버개발(Rails)과 RIA개발(Flex)과 시스템 관리(influxis, Amazon EC2/S3, Rackspace Cloud) 각각에 거의 비슷하게 시간을 쏟고 있는 듯 합니다.

예전엔 조직 구조에 대해 고민도 많이 하고, 논리를 믿을 것인가 직관을 믿을 것인가에 대한 고민도 했었는데, 지금은 자연스럽게 1인 개발 체제를 지향하고 있습니다. 거의 직관을 따르고 있구요. 신중한 결정과 충분한 토론보단 섣부른 실행과 지나친 테스트를 더 선호하게 되었습니다.

기본적으로 논리에 빈틈이 많고 경험이 부족한 사람들끼리 토론할 경우 서로 배우는 것도 있을 수도 있고 토론 후에 좋은 결론이 도출될 수도 있다고 보지만, 만약 기본적으로 각자가 충분히 경험을 해왔고 충분히 논리적이고 충분히 직관이 잘 적중하는 사람들 사이에서는 설득과 토론과 결정과정을 통해 뭔가를 포기하고 하나를 취한다는 게 큰 기회 손실일 수도 있고 그런 설득과 논쟁 과정 자체가 시간과 리소스 낭비가 될 수도 있다고 생각합니다.

이게 옳다 저게 옳다 논리적으로 설득하려하기 보다는 네 말이 맞을 수도 있고 내 말이 맞을 수도 있으니 이게 성공할지 저게 성공할지 고민할 시간에 둘 다 만들어서 런칭해보면 된다는 주의가 된거죠. 이런 전략을 사용하려면 당연히 개발 속도가 충분히 빨라야 합니다. 하나의 서비스를 완성하는데 필요한 지식을 1명이 다 알고 있다면 개발 속도는 끝내주게 빨라지죠.

--

Wetoku가 생각보다 오래 걸렸던 이유는 UI, 서버, 시스템 등등의 퍼즐들 중에 Flex라는 퍼즐이 완성되어 있지 않아서 새로 조각을 깎아내느라 시간이 걸렸고, 이제부터는 기대해도 좋을 속도가 나와주리라 생각합니다. 또다른 새로운 퍼즐이 필요하지 않는 한 말이죠. 새 퍼즐을 깎으면서, 칼을 쓰는 법도 익혔기 때문에 안드로이드나 아이폰, 다른 언어 등의 퍼즐들도 처음에 비해 빨리 깎을 수 있겠죠.

1인 개발 체제는 분명 리스크를 앉고 있는데, 만약 이 서비스가 3년 이상 지속적으로 개발이 되어야 하고 개발 속도보다는 안정적인 서비스가 우선시된다면 1인 개발 체제는 지양해야 합니다. 당연한 얘기죠. David가 농담처럼 하는 말이, 만약 제가 교통사고라도 나면 어떡하냐는 겁니다(-_-)

제가 서버 암호나 코드 주석을 아무리 잘 정리해놓는다 하더라도, 이 애플리케이션에 익숙하지 않은 새로운 사람이 이에 익숙해지고 버그를 고치고 기능을 추가하기 위해서는 많은 시간이 걸리죠. 그 과정에서 사용자들이 떨어져나가고 기회를 놓칠 수도 있구요.

이런 상황에서는 나와 비슷하거나 그에 준한 수준의 애플리케이션 이해도를 가진 대체 인력이 있어야 하며, 협업이 서비스 개발에 약간의 비효율을 가져온다 하더라도 리스크를 감소시키기 위해 지향해야 합니다. 그리고 서비스 안정화 단계에서는 비효율보다는 리스크가 상대적으로 더 큰 이슈이기도 하구요.

하지만 빠른 개발이 필요한 상황에서는 이런 과정이 상대적으로 큰 비용이 됩니다. 누가 봐도 알 수 있는 친절한 주석을 작성하는 데는 코드를 작성하는 것보다 오래 걸립니다. 경쟁 업체는 우리 서비스 컨셉을 금방 따라해 기능으로 추가하고 있고, 우리 서비스는 잠깐 이슈를 탔다가 잇다른 기능 추가가 늦어져 이슈에서 멀어져가고 있는 상황에서 내 후임을 고려한 친절함은 그 친절함 자체가 의미없는 상황(서비스를 접어야하는)을 만들 수도 있는거죠. 서버를 내릴건데 주석이 무슨 소용이겠습니까.

즉 경쟁이 급박하게 돌아가는 상황, 유지보수보단 빠른 개선이 필요한 상황에서는 적은 인력일수록 유리하다고 보고, 그게 1명이라면 그 1명이 교통사고(-_-)를 당하거나 여자랑 눈이 맞아 무인도로 도망가거나 하는 등의 리스크를 감수하는 이상 가장 빠른 속도를 낼 수 있다고 생각합니다.

--

디자인은 개발이 1차적으로 완료된 후에 심미적인 측면을 개선시키는 형태로 진행되고 디자이너로부터 받은 PSD는 필요한 부분만 작게 쪼게서 css안에 포함시킵니다. 폰트를 이미지에 포함시키는 대신 가급적 그 이미지의 백그라운드만 사용하고 폰트는 html/css로 포지션을 잡습니다.

심지어 박스 라운딩은 IE에서 제공하지 않는 css 어트리뷰트인 -moz, -webkit로 떼워버리죠. 지금 개발하고 있는 이 페이지가 내일 당장 쓸모 없어질 수도 있고 라운딩 대신 직각으로 바뀔 수도 있고 박스 색깔이 바뀔 수도 있고(그럼 라운딩 이미지들을 모두 바꿔야 하죠, 만약 css 어트리뷰트 대신 슬라이딩 도어나 모퉁이 백그라운드이미지 방식으로 했을 경우)

이런 효율적이면서도 조금은 무책임한 방식으로 디자인을 페이지에 입힐경우 디자인 파일이 나온지 몇 십분 정도면 페이지에 적용이 됩니다. table로 위치를 잡는 대신 html/css를 사용하니 수정도 쉽고 재미도 있고요. css작업은 레고블럭 쌓는 재미가 있죠. 사실 따지고 보면 지금 제가 일하는 방식은 제가 그 동안 생각해오고 글로 정리해오고 있던 것들의 실행판이라고 볼 수 잇겠네요.

--

위에서 잠깐 언급했지만, 저희 팀은 한국에서 글로벌 서비스를 만들고 있기 때문에 지역적인 핸디캡이 있을 수도 있었지만, 사실 그렇게 큰 장애물은 없었습니다. 구글신은 세계인에게 평등하고(중국 등은 예외), 플레시 미디어 서버는 influxis에서 필요한 만큼 호스팅하면 되고 미디어파일은 아마존 S3에 올려놓고 Progressive Download로 재생하면 굉장히 저렴하고요(놀랄 정도로 쌉니다). 웹서버나 백그라운드 프로세싱 서버 등을 구성하기 위해서는 Rackspace Cloud나 Amazon EC2에서 클릭 몇 번이면 root권한의 서버를 가질 수 있습니다.

Rackspace Cloud의 경우 사용자가 늘면 CPU와 Ram을 업그레이드 하는데, 서버를 뜯어서 칩을 바꿔 꼽는게 아니라 램 확장을 클릭해놓으면 자동으로 새 서버(가상 서버)를 부팅하고 현재 서버의 이미지(OS, DB 그밖에 모든 것을 그대로 복사한)를 이용해 마이그레이션을 합니다. 다운타임은 몇 분 내외였던 것 같은데 아무튼 많이 편리해졌습니다. 비용은 휴대폰 요금제 변경 때처럼 일할 계산해서 적용됩니다. 합리적입니다.

Amazon EC2가 예전에는 관리자 패널이 아예 없거나 조악했고 root 인증방식도 password가 아닌 key-pair 였기 때문에 왠만한 Geek 아니면 쓰기 어려웠었는데 지금 한 번 계정을 만들어보면, 서버 생성까지 웹 인터페이스로 다 처리할 수 있습니다. 심지어 Putty로 어떻게 접속해야되는지까지 친절하게 알려주네요. Amazon EC2용 자바 콘솔은 설치할 필요도 없구요.

이런 기술적인 부분은 괜찮은데 다만 북미를 타겟으로 한 서비스라 여기와의 시공간의 거리감이 존재합니다. 때문에 David는 최근에 낮밤을 바꿔서 생활하고 있습니다. 네트워킹을 위해 트위팅과 블로깅, 메일링에 매진해야 하는데 아무래도 실시간으로 하려면 그 쪽 시차와 맞춰야 하니까요. 또 물리적인 홍보가 필요할 때는 직접 건너가기도 합니다. 7월에는 David가 홍보차 다녀왔구요, 다음 달에는 저도 New Media Expo에 참가할 계획이구요. 아 처음으로 미국 땅 밟아보나요.

난 개발을 내 손으로 하고 싶다는 열망과 개발을 정말로 내 손으로 할 수 있을까라는 의구심을 동시에 가지고 있었다. 지금은 xhtml/css, Javascript with Prototype.js and jQuery, Ruby on Rails, Action Script with Flex를 가지고 동시에 개발할 수 있다.

2주만 주어지면 기획부터 디자인, 클라이언트/서버 개발, DB, 시스템까지 하나의 웹 서비스를 혼자서 풀스텍으로 만들 수 있다. 하지만 저 열망과 의구심을 갖기 시작했던 것이 불과 만 2년 전, 서론부터 이해가 안 되는 개발책을 펴놓고 에디터도 못 깔아서 헤메던 게 생생하게 기억이 나기 때문에, 내가 지금 개발자 행세를 하고 있다는 사실이 어떨 때는 우스꽝스럽다.

난 영어로 말하고 싶다는 열망과 정말 영어를 내 입으로 말할 수 있게 될까라는 의구심을 동시에 가지고 있었다. 지금도 잘한다고 말하면 완전 뻥이지만, 어쨌든 훈남 외국인들과 함께 일하고 있고 함께 글로벌 서비스들을 개발하면서 하루 중 한글을 쓸 기회가 거의 없고 대부분은 영어로 말하고 읽고 쓰고 듣는다.

외국서 2주이상 체류해 본 적도 유학이나 교환학생을 간 적도 없고 수험시절까지 통털어도 영어학원 3개월 이상 다닌 적도 없다. 처음으로 외국인과 영어로 인사를 나눈 게 불과 만 6개월 전이었고, 메신져로는 그렇게 쉽던 '하이'라는 말이 처음 목구멍 밖으로 나올 때 굉장히 쑥스러웠기 때문에 그 때의 내가 지금의 나를 보면 엄청 부러워 할 것이다. 더 부러워할 만한 것은, 지금의 환경 덕분에 앞으로는 저절로 실력이 늘어날 거라는 사실이다.

그리고 이런 환경에서 일하게 만들어준 기회, 그 기회를 만들어준 기회, 그 기회를 만들어준 기회... 이런 기회 체인의 시작 지점으로 가보면, '샌프란시스코에 가고 싶다'는 작은 꿈을 위해, 읽는 영어가 아닌 말하는 영어 공부를 시작했던 용기가 있었다. 지금은 캘리포니아에서 벤처를 하겠다는 게 거창한 꿈이 아니라 그냥 곧 하게 될 계획의 일부가 되었다. 난 기술이 있고, 영어를 할 수 있고, 목표가 있고, 열정이 있고, 파트너가 있다.

모든 새로운 학습 과제에는 진입 장벽이 있는데, 최초로 그것을 접했을 때는 그것의 진입장벽이 얼마나 높은지 측정이 불가능하기 때문에 정신적인 장벽까지 더해져 실제보다 더 어려워 보인다. 우여곡절 끝에 그 장벽을 넘어서면, 그 기술을 자연스럽게 사용할 수 있는 환경에 처할 수 있게 되고, 그 이후로는 특별히 노력하지 않아도 저절로 실력이 향상된다. 물론 노력을 병행하면 가속도가 붙는다.

이런 장벽을 두 번, 세 번 넘어보게 되면, 학습에서 어떤 패턴을 보게 됨과 동시에 자신에게 어떤 학습 방식이 잘 맞는지도 발견하게 된다. 그러면 실제 학습 장벽도 낮아지고 더불어 새로운 것에 자신감도 생겼기 때문에 정신적인 장벽도 낮아진다. 뭐든 다 배울 수 있다고 믿게 되고 실제로도 뭐든 배울 수 있게 된다.

아주 훈훈한 표현인 Fast Learner가 되어 다른 이들이 수 년 간 쌓아온 노하우를 며칠만에 복사하고 자신의 관점을 더해 발전시키는 단계에 이르면 다른 사람들의 시기와 파트너들의 인정을 동시에 받고 그 분야에서 순식간에 성공한 다음 다른 분야에 도전한다. 캘리포니아에서 이름을 알린 벤처 창업자들은 Fast Learner이다.

그들의 만든 서비스, 그들이 쓴 글들은 날카롭고 빠르다. 그들은 어리지만 학습 능력 측면에서 이미 성공할 준비가 되어 있었다. 준비가 된 사람들이 우리나라 보단 그 나라에 더 많은 건 아마 문화적인 차이이기도 하고 교육의 차이이기도 한 것 같은데 어쨌든 CEO가 Fast Learner이거나 핵심 인력이 Fast Learner가 아니면 투자를 받을 수 있을진 몰라도 서비스를 성공시킬 수는 없다고 난 믿고 있다.

Fast Learner 보다 Fast Talker가 많다. 그건 캘리포니아도 마찬가지지만, Fast Learner의 절대적인 수치 부족, 또는 Fast Learner들이 한 두 분야만 파고드는 것도 문제라고 생각한다. Entrepreneurship을 즐기는 Fast Learner라면 깊이 파기보단 합리적인 깊이를 유지하면서 비즈니스에 필요한 여러 분야를 넓게 팔텐데 상대적으로 국내에 적어 보인다.

그렇다고 제가 Fast Learner라는 건 아니고.. 물론 희망하긴 하지만... 배울 건 아직도 많이 남았고, 그것들을 배웠을 때 어떤 기회들을 갖게 될지 너무나 선명하기 때문에 지체할 수가 없고, 그러느라 글쓸 시간은 없고, 그래서 이 글은 거의 6개월 만의 글이고..

어떤 분야에 대한 정보가 전혀 없는 상태에서는 가리지 말고 무조건 많이 읽어서 익숙해져야 하고, 정보가 쌓여가는 중에는 축적된 정보간에 체계를 잡아주면서 정보의 질을 판단할 수 있는 분별력을 길러야 한다.

정보가 충분히 축적되어 그 분야에 대해 성숙한 관점을 갖게 될 즈음에는 실행의 비중을 높여야하기 때문에 정보 소비를 줄이게 된다. 이 단계에서는 수없이 많은 정보 채널을 알고 있고, 수없이 많은 관심사를 갖고 있기 때문에 정보 소비를 줄이지 않으면 수많은 관심사와 관련된 수많은 정보 채널들로부터 매일 날라오는 피드 폭탄에 질식할 수밖에 없다.

이런 정보의 양을 감당하겠다고 욕심을 부리면 실행할 시간을 빼앗기거나, 다른 분야 또는 다른 관점에 대한 정보/능력 습득의 기회를 놓칠 수도 있다. 완전히 다른 분야를 시작하기 위해서는 충분한 여유시간이 필요하다. 꾸준한 습득은 필요하지만 과한 습득은 다독 또는 다 안다 라는 자기만족 이상도 이하도 아니다.

정보는 끝없이 생산되고 또 시간이 갈수록 생산되는 양도 더 많아지는데 그것을 다 소화할 수는 없다. 끊임없이 읽는데도 읽어야 할 것은 늘어가고, 읽지 않을 딜리셔스 북마킹은 쌓여가고 있다면, 더 중요할 수 있는 다른 것들을 놓치고 있다는 이야기이다.

정보를 습득하는 데는 시간이 필요하기 때문에 정보들간의 우선순위를 파악해서 중요한 것들을 먼저 확인하고 우선순위 뒤에 있는 것들은 무시할 수 있어야 한다. 내가 사용하는 방식은 토픽을 아주 좁게 선택해 일정 기간동안 그것만 파고드는 것인데, 시간을 충분히 들이면 뜬구름 잡는 수준에서 벗어나 꽤 디테일한 파악과 실제 활용까지 해볼 수 있기 때문에 그 주제를 '졸업'했다고 말할 수 있게 된다.

하나를 졸업하면 그 형제뻘 부모뻘 자식뻘 되는 토픽들은 그 패턴과 유사하게 해석할 수 있어서 이해가 쉽다. 그리고 해당 토픽과 관련해 해석, 예측하는 것에 관심을 갖기 보단, 그것이 실제로 어떻게 동작하는지, 어떻게하면 만들 수 있는지, 누가 만들고 있는지에 집중한다.

예를 들면, 안드로이드나 아이폰 앱 스토어에 대해 관심이 있다면, Techcrunch나 CNet을 읽는 것이 아니라 개발문서를 보거나 SDK를 받아서 직접 개발해보는 것이다. Hello World만 찍지 말고 에어로미터와 OpenGL/AL API 사용해서 3~7일 프로젝트로 매달려보는 것이다. 뜬구름 잡는 해석, 과장된 예측, 비장하게 풀이된 경쟁구도 같은 것에 휘둘리지 않고, 아예 제대로 발을 푹 담그는 것이다.

그 토픽에 대한 장미빛 예측이 결과적으로 맞는다면, 발을 담그고 있는 나에게도 좋을 것이고, 사실상 별 것 아닌 것으로 판명난다 해도 난 나름대로 배운 것이 있으면서 다음 번 예측에 필요한 인사이트를 얻은 것이니 역시 나쁘지 않다. 이런 인사이트는 Techcrunch를 매일 읽는다고 해서 생기는 게 아닐 것이다.

지금 당장 발을 푹 담글 것이 아니라면, 아예 관심 끄고 더욱 시급한 것, 바로 지금이 타이밍인 것에 집중하는 것이 낫다. 나중에 진정으로 관심이 생겼을 때, 그것이 폭발하는 시점에 달려들어도 늦지 않다고 생각한다. 세상은 관심을 끄고 보면 빨리 변하지만 관심을 갖고 보면 느리게 변한다.

좀 다른 토픽을 예로 들면. 내가 잠깐 주식에 관심이 있었을 때, 일반적인 개미 투자자가 접할 수 있는 HTS 강좌, 좀 더 낫다 싶은 사람들이 하는 기본적 분석, 기술적 분석, 그리고 수많은 증시와 차트 분석 책들을 거쳤고, 나중에는 워런트나 옵션도 좀 공부했는데, 그리고 나서 얻은 결론은 이렇게 겉만 핥아서는 돈과 시간만 버린다는 것이었다.

주식을 하려면, 아니 금융을 하려면 금융공학을 하고 수치해석을 하고 퀀트들이 하는 모델링 프로그래밍을 해서 통계적 차익거래를 해야 한다. 사실 나도 이게 무슨 말인지 잘 모르겠고 또 지금은 이쪽과 관련해 내가 잘 모르는 것들을 구체적으로 배울만한 좋은 시기가 아니라고 생각한다. 하지만 언젠가 주식이 하고 싶어지면 차트분석책이나 증권뉴스가 아니라 금융공학 책을 들어야 겠다는 확신은 있다.

새로운 웹서비스의 참신한 인터페이스라면, 몇 번 클릭해보면서 테스트하거나 수많은 리뷰들 읽는 데 시간을 쓰기보단(물론 필요한 과정이다. 과하면 안좋다는 뜻), 기획서에 옮겨담아 보면서 그 기획자의 사고방식을 모방해보는 것이 낫고, 프로그램 라이브러리를 사용한다면 API문서를 외우기보단 소스코드를 이해하는 것이 낫다고 생각한다.

핵심을 곧바로 겨냥하면, 중요하지 않은 2차, 3차 정보들은 우선순위 뒤로 밀리면서 나의 시간을 빼앗기지 않을 수 있다. 지금처럼, 정보가 부족해서가 아니라, 정보를 찾지 못해서, 또는 정보가 너무 많아서, 또는 정보의 중요도를 판단하지 못해서 기회를 놓치고 있는 시대에는, 핵심을 보고 실행에 집중할 수 있는 노하우가 필요한 것 같다.

나 스스로에게, 그리고 이 글을 보는 다른 누군가에게 의미가 있는 글만 쓰고 싶다는 욕심이 있다. 그래서 블로그 에디터를 열어놓고 장문의 글을 써내려가다가 임시저장해놓고 영원히 묵혀두는 일이 많다. 내가 이 글을 뭐하러 쓰고 있지? 누군가가 썼을텐데? 이게 나에게 의미가 있나? 보는 사람에게 의미가 있나? 라는 회의감에 젖어.

글이 항상 무거워지고 단락이 늘어나고 포스팅 주기가 길어지는 이유이기도 하다. 의미 있는 글이라.. 과도한 욕심이다. 나도 분명 드라마를 보고 영화를 보고 음악을 듣고 웹툰을 보고 디바이스와 신규 웹 서비스에 관심이 많으니, 많은 취향이 있고 누군가에게 떠들고 싶은 화두도 많다. 그런 주제로 글을 쓰지 못하는 것은 순전히 이런 강박관념 때문이다.

누군가에게 들었던 조언은, 블로그를 컨텐츠로 채우지 말라는 것이었다. 사람들이 블로그 주인장이 아니라 블로그 컨텐츠를 보러 방문하고, 그 컨텐츠를 보고 만남을 요청해서 관계가 시작되면 그 관계조차 서로에게 하나의 컨텐츠 채널이 될 뿐이라는 의미였다.

꼭 그렇다고 생각하지는 않지만, 저널이나 미디어가 되고자 하는 욕구가 생기기 시작하면 얻는 것 만큼 손해보는 게 있다는 사실에는 공감한다. 그래서 프로덕트를 만들 때는 최우선적으로 대중성을 생각하지만, 글을 쓸 때는 대중성을 배제한다. 어려운 주제를 다룬다고 할 순 없지만, 쉬운 문장으로 표현하기 위해 노력하지 않는다.

내가 블로그를 하는 이유는, 아마도 나를 좋아해줄 사람들을 찾기 위해서인 것 같다. 나를 좋아하는 사람은 내가 좋아할 확률이 크다. 지금 내 블로그를 보고 계시고, 덧글을 달아주시는 분들은 거의 100% 내가 좋아하는 타입의 사람이다. 나는 좋아하는 타입과 그렇지 않은 타입이 선명하다. 전자의 타입은 전체 인구 중에 아주 작은 비율일 것이다.

그래서 취향과 관련된 화두로 글을 쓰지 못하는 것일지도. 드라마, 영화, 음악, 애니를 좋아하는 사람은 너무 많아서 내가 좋아할 만한 소수의 사람들을 발견하기 어려워지니까. 그리고 난 나와 같은 취향의 사람들을 발견하기 보단 비슷한 방향의 비전 또는 비슷한 크기의 비전을 가진 사람들을 발견하고 싶다. 성향과 능력은 다양한 사람들을. 언젠간 틀림없이 함께하게 될 거라는 기대가 있다.

나는 26살의 대학생이다. 컴퓨터과학을 전공하고 경영학을 부전공하고 있다. 하고 있다. 휴학 제한 기간을 최대한 활용하고 있는 장기 휴학생이다. 전공, 부전공 수업과 인문학 수업을 청강하고 타 학교의 유명하다는 과목도 종종 청강한다. 학교 도서관의 휴학생 대출을 애용한다. 초면인 사람에게 내가 대학생이라는 사실과 내 나이를 굳이 밝히지 않는다.

나는 26살의 수강생이다. 외국어학당에서 비즈니스 영어를 익히고 매주 개발 스터디, 매월 개발 세미나에 가면 열심히 필기와 토론을 한다. 한 달에 5권의 기획/개발 실무서를 보고 5년 간 하루에 수십 페이지의 포스트와 도큐먼트를 읽었다. 학습 측면에서 타인에게 지는 것을 참지 못한다.

나는 26살의 직장인이다. 휴대폰 판매사원으로 일하기도 했고 주먹밥이나 악세서리도 팔아봤고 돈까스집 알바로, 과외 선생님으로, 어떤 회사에서는 웹 서비스 기획자로, 프로젝트 메니저로, 어떤 회사에서는 창업 멤버로 일했으며, 지금은 서버/클라이언트 개발자로 일한다. 웹표준 디자이너로 일해보고 싶고 '부장님'과 마케터 타이틀을 가져보고 싶기도 하다. 언젠가는 영화 감독과 작곡가, 에니메이터, 시나리오 작가, 회로 설계, 금융 공학, 게임 개발 전문가를 틀림없이 해볼 것이다.

나는 26살의 창업자다. 서버 사이드를 개발하고, 자바스크립트도 개발한다. UI개발을 하고 로고와 버튼 디자인도 한다. 기획서를 그리고 사업계획서와 프리젠테이션을 만든다. 창업회계를 하고 경영과 마케팅을 익혔다. 업계의 굵직한 소식은 공개적/비공개적으로 듣고, 스타트업이나 관심있는 분야의 비즈니스와 관련된 거라면 국내외를 떠나서 자잘한 것까지 알고 있다.

나는 26살의 몽상가다. 시가총액 100조원의 회사를 설립하는 것이 목표이고, 100조 목표가 달성되면 1000조, 1경이라는 새로운 목표들까지 미리 세워두고 있다. 성공할 때까지 무한대로 시도하면 실패 가능성은 제로로 수렴한다고 믿으며, 무한대로 시도할 수 있으려면 비용을 제로에 가깝게 끌어내릴 수 있는 제로 코스트 비즈니스를 해야 한다고 고집을 피우고 있다. 돈을 벌면 비영리 대안교육 재단을 만들고 국내외 소외된 계층의 아이들에게 교육과 양육을 제공할 것이다.

나는 26살의 외동아들이다. 집에 밥이 없으면 쌀을 씻어서 밥을 해놓고, 설거지감이 많으면 고무장갑을 낀다. 어머니가 장 볼 것이 많으시다 하시면 장바구니를 들고 뒤따르고, 계란이나 우유가 떨어지면 알아서 채워둔다. 아버지나 내가 집을 나설 땐 어머니의 포옹을 받는다. 배가 고프면 난폭해지고 갈치나 조기는 알아서 다듬어서 구워먹으며 국이 없으면 국타령을 한다. 집밥이 익숙해 밖에서도 한식이나 급식이 제일 좋다.


요즘 가장 큰 고민은, 변해야 하는가, '아니면 조금만 더 있다가' 변해야 하는가이다. 지난 4년 간, 지식적인 측면을 최대한 끌어올리기 위해 비장하기도 하고 공격적이기도 한 아이덴티티를 유지해왔다. 최근 2년 간 많이 변했다고 스스로 평가해봤지만 따지고보면 기획 베이스에서 개발 베이스로 바뀐 것이었지 성향은 전혀 변하지 않았다. 중간중간 좀 여유로워지기도 하고 사교적인 행세를 해보기도 했는데 결국 다시 치열하고 계산적인 상태로 돌아왔다.

사람을 사귀는 기준도 그에게 배울 것이 있는가, 어떤 모임이나 행사에 시간을 할애하는 기준도 그곳에서 배울 것이 있는가 였다. 솔직히 이런 성향 덕분에 굉장한 이득을 보았다. 하지만 이면에는 (손해를 보았다기 보다는) 얻을 수 있는 다른 이득을 놓쳤다는 느낌. 이득이란 단어도 계산적이다. 행복. 행복을 조금씩 놓쳤다. 그 행복 속의 기회도.

나는 다른 사람의 개인적인 이야기에 잘 감동하고 뭉클해하며 눈물도 잘 맺힌다. 외로움을 잘 타서 사람 만나기도 좋아하고 한 번 누구를 만나면 그와 나누었던 대화들을 곱씹어보느라 잠에 들지 못하고 심지어 그와 이야기를 나누는 꿈까지 꾼다. 그가 내 말을 들어주는 것도, 내가 그의 말을 들어주는 것 모두 좋아한다.

그런 관계, 그런 대화를 의식적으로 제거해왔던 것이 지난 4년 이었다. 여행, 휴가 같은 건 사전에서 지워버렸다. 요즘 문득 비즈니스 이외의 주제로 대화하는 것이 너무나 어색한 스스로를 발견하게 되었다. 주변에는 목표가 커다란 친구들만 남아있고 그들과 만나면 역시나 커다란 목표와 오늘의 성장에 대해 이야기했다.

목표하는 바가 있고, 그것이 다른 사람들의 목표보다 훨씬 큰 것이기에 삶의 여유를 어느 정도 포기해야 한다고 각오해왔다. 포기했던 여유를 되찾을 때인가 아니면 치열함을 아직 유지해야 하는가. 나의 몽상가적인 목표를 유지하면서 지금 벌써 삶의 여유를 탐낼 자격이 있는가 혹은 오히려 그런 여유가 목표 도달에 더 중요한 것은 아닐까, 이런 고민을 하고 있는 요즘이다.

투잡 생활을 두 달째 하고 있다. 하루 4시간은 레일스 개발자로, 하루 6시간은 레일스 창업자로. 이건 정말 흥미로운 체험이다. 4시간과 6시간의 경험을 간단하게 적어볼까. 일단 오늘은 4시간.

10시에 출근해 기획팀 개개인과 개발팀 개개인이 돌아가면서 자신들이 어제 한 일과 오늘 할 일을 브리핑한다. 자신이 할 일은 자신이 정하고 우선순위도 자신이 정한다. 개개인의 역할이 커지고 책임도 커진다.

다 함께 수정할 문서는 위키를 활용하고 기획문서 교환과 피드백은 지메일을 포럼 쓰레드처럼 활용한다. 개발팀은 신중한 작업에는 언제든 페어 프로그래밍을 하고 작업량이 많을 땐 인덱스카드에 테스크를 시간 단위로 분할해서 분담해 작업하고 SVN으로 통합한다.

레일스의 MVC는 커뮤니케이션에 유리하다. 커뮤니케이션에 유리하다는 말은 사고하는 것에도 유리하고 결국 개발하는 데도 유리해지니 다 같은 말이긴 한데, 대화를 하다보면 MVC이기 때문에 소통에 이익을 얻는다는 느낌을 받는다.

'그 코드는 컨트롤러에서 자주 쓰이니 모델로 빼는 것이 좋겠다', '그건 뷰에서 일단 테스트한 다음에 컨트롤러로 옮기자' 등 모델에서 할 작업인지 컨트롤러에서 할 작업인지 뷰에서 할 작업인지를 언급하는 것만으로도 내가 말하는 의도가 전달이 된다.

커밋을 할 때면 내가 수정한 파일이 무엇이고 어떤 내용의 작업이었는지 다른 개발자에게 간단하게 브리핑하고, 업데이트할 때 머지된 부분이 있으면 설명을 요청한다. Trac 등을 사용하면 더 정확한 파악이 가능하겠지만 커밋과 업데이트가 워낙 빈번해서 상대방의 코드를 봐야 할 정도로 큰 수정은 없어서 안 쓰고 있다.

페어는 상황에 따라 이 PC에서 할 때도 있고 저 PC에서 할 때도 있는데 두 PC의 개발 도구가 완전히 달라서(압타나 vs. VI) 극과극의 체험을 빈번하게 할 수 있다. 냉탕과 온탕을 왔다갔다 하는 기분? 페어의 가장 큰 장점은 타인의 습관을 관찰하고 학습할 수 있다는 것이다.

상대방의 코딩을 눈으로 따라가면서 의도를 파악하고 잘 파악되지 않는 부분은 질문을 하거나 다른 방식을 제안하기도 한다. 내가 코드를 작성할 때는 '이렇게 하려고 한다'는 의도를 설명하면서 상대방의 제안을 귀담아 듣고 해결책을 잘 모를 때는 힌트를 요청하기도 한다.

문제를 해결할 수 있는 방법이야 수없이 많지만 가장 좋은 방법을 찾기 보다는 합리적이고 괜찮은 꽤 많은 방법 중에 먼저 떠오른 방법을 택한다. 약간의 타협인데 최고의 코드 보다는 합리적인 수준의 코드와 빠른 속도를 따르자는 암묵적인 합의.

미래의 재사용성을 고려해 메서드를 많이 만들어내기 보다는 가급적 쉽고 단순하게 구현한 뒤 그 코드를 2번 이상 똑같이 반복해야 할 상황이 왔을 때야 메서드로 뽑는다. 모듈화는 코드 재사용을 쉽게 하고, 잘 설계되었다는 인상과 프로그래머로서의 뿌듯함을 주지만, 타인이 코드를 이해하는 데 시간을 많이 걸리게 한다.

언젠가 또 사용하게 될 것 같다고 생각해서 미리부터 설계에 머리를 싸매기 보다는 가장 중요한 기능을 가장 빨리 구현할 수 있는 방법으로 코드를 작성하고, 같은 코드를 여러 번 반복하고 앉아있다는 자각이 일고 나서야 점차 코드를 리팩토링해 나가는 게 좋다고 생각한다.

4시간은 번개같이 지나가지만, 4시간이 지나놓고 보면 만들어 놓은 결과물이 결코 작지 않다. 6명 정도의 작은 팀이고 고개만 돌리면 기획팀과 개발팀이 소통을 할 수 있다. 꼭 필요한 커뮤니케이션을 30분 이내로 하고 간식을 자주 먹는다(중요). 기획팀이든 개발팀이든 하루 동안 많은 일을 한다.

하루동안 내가 작업할 수 있는 시간이 8시간이라면 일단 마음이 느긋해진다. 음악을 듣고 웹툰을 본다. 누군가 강제하지 않는다면 30분 단위로 테스크를 분할하게 되지는 않을 것이다. 아마도 오전에 할 것, 오후에 할 것, 퇴근 전까지 할 것 정도로 나누겠지.

오전 2시간 오후 2시간 사이에 식사 시간이 한 시간 있기 때문에 체감되는 시간은 더 빠듯하다. 화장실 가거나 물 마시는 시간 이외엔 따로 쉬는 시간도 안 챙긴다. 바빠서가 아니라 쉬고 싶다는 생각을 할 틈이 없을 정도로 높은 집중력을 유지할 수 있는 짧은 시간이다.

오늘은 처음으로 초과근무를 해서 총 8시간을 앉아있었는데 5시간 째 이후로는 확실히 집중력이나 작업속도가 절반 이하로 떨어졌다. 일한다는 느낌 보다는 버틴다는 느낌이 들었다. 알찼던 하루가 도로 풀려버리는 듯한. 보통의 개발자들이 이런 느낌으로 일하겠지 싶었다. 다음 글엔 '6시간' 이야기.

국내에서는 디자인 퀄리티 요구 수준이 향상되면서 디자인 및 UI 개발 프로세스가 캘리포니아와 반대로 가고 있는데, 캘리포니아 스타트업들은 가급적 포토샵 터치를 줄이는 방향으로 디자인을 바꾸고 있는 반면, 국내는 국내 포털을 따라해서 포토샵을 많이 사용하는 방향으로 디자인이 이루어지고 있다.

국내외 디자인 방식의 차이를 두고 '국내 사용자들의 눈이 높다'라고 보는 시각도 있지만, 나는 사용자들이 단지 포털식 디자인에 익숙해져 있을 뿐이고 캘리포니아식 디자인도 초반에 겪는 약간의 이질감을 넘어서면 더 '깔끔한, 세련된' 것으로 인식하게 될거라고 생각한다. 이런 방식으로 디자인하는 습관을 버리지 못했거나, 그렇게 디자인하는 사람들을 해고할 수 없는 것 뿐일 수도 있다.

국내의 디자인 방식은 UI 개발(코더) 과정을 필수적인 것으로 만들어버리고, 클라이언트 또는 서버 개발직군의 선택권을 제한한다. 가령 UI개발자의 손을 거쳐 나온 html과 css파일은 나름의 id와 class값을 가지고 있는데 자바스크립트 개발자는 동작 의도와 맞지 않는 이름의 id를 억지로 사용하거나 일일이 id값을 수정(그 id값이 위치한 css도 수정)해야 한다.

또 서버 개발자는 빌더 형태의 뷰 템플릿(레일스의 경우 HAML)을 사용할 수 없게 되고 프레임워크에서 제공하는 헬퍼 메서드(link_to 등), 코드 조각(Partial) 사용에 제한을 받거나 성가신 수정 작업을 해야 한다. 또 별도의 UI개발자가 작성한 CSS는 스타일 모듈화 보다는 엘리먼트간 스타일 간섭 최소화를 우선하고 있어서 CSS 코드 분량도 많고 재사용도 어렵고 개발한 본인이 아니면 수정도 어렵다.

나는 서버 개발자를 위한 UI개발 도우미(HAML이나 BluePrint) 사용을 반대하는 쪽이지만 어쨌든 국내 디자인 트렌드가 가져온 UI개발 프로세스가 서버 개발자들의 여러 선택권을 제한하는 것은 좋지 않은 것 같다. 물론 해외에도 UI개발 직군 및 UI 개발 프로세스가 있지만 국내의 UI개발과 해외의 UI개발은 목적과 전문성에서 차이가 있다.

내가 느끼는 캘리포니아의 UI개발 직군은 (myspace UI와 디자인을 컨설팅한 adaptive path처럼) 정말 UI 개발만을 '전문적'으로 하거나 컨설팅을 해주는 수준으로 고급화되었고, 국내는 개발자 대신 성가신 작업을 대신 해주는 코더 개념에서 크게 향상되지 못했다고 보는 것이다. 국내 디자인 형태가 그것을 조장했다고 보고. CSS를 얼마나 효율적으로 모듈화해서 사용하느냐가 아니라, 잘게 쪼개진 테두리 이미지들을 어떻게 하면 오차 없이 끼워 넣을 수 있는지를 고민해야 하는 것이다.

포토샵 작업이 중심이 아니라, CSS 스타일과 레이아웃이 디자인의 중심으로 올라오면, 디자인 프로세스 및 UI개발 프로세스의 순서가 클라이언트/서버 개발의 이전이 아닌 이후로 바뀔 수 있다. 실제로 UI/클라이언트/서버 개발을 혼자서 진행하게 될 경우 UI 개발은 앞쪽이 아니라 뒤쪽에 오게 된다. 뷰 코드를 다 작성하고 난 후에 id/class를 추가하면서 css를 작성하는 것이다.

클라이언트/서버 개발자는 디자인과 UI개발 결과물이 나올 때까지 기다리는 것이 아니라, 주요 골격을 미리 완성해놓고 UI개발자와 디자이너의 '도움'을 받는 형태가 된다.

팀의 협업 방식

프로젝트에서 팀원들의 역할을 어떻게 나누어야 할까. 가장 효율적인 팀 구성과 작업 방식은 무엇일까. 이 질문 자체만 가지고는 우문을 벗어날 수 없다. 작업 환경에 따라 프로젝트 목표에 따라 팀원들의 능력, 경험, 성향에 따라 효율성은 천차만별로 달라지기 때문이다. 그래서 환경과 목표와 사람을 좀 한정시켜보겠다.

환경은 Environment 내지는 Restriction으로서 경영진의 지원이나 사내 분위기, 자원, 복지 등이며, 목표는 Goal 내지는 Mission으로서 프로젝트의 카테고리와 타겟 마켓, 엔터프라이즈인지 컨슈머인지, 매출 목표나 UV/PV 목표 또는 퀄리티 목표 등이 있을 수 있고, 마지막으로 사람은 Team 또는 Human Resource으로서 팀원 간의 신뢰, Self-Motivating, Passion, 학습 능력, 숙련도, 협업 경험 등이 될 것이다.

이들 세 가지 조건(환경, 목표, 사람)을 특정 케이스로 한정시켜서 그 케이스 내에서 가장 효율적인 협업 형태는 무엇일지를 고민해보고자 한다. 아래 서술되는 내용은 그에 대한 가정(Assumption)들이다.


세 가지 가정

우선 환경(Environment)은 대표이사와 경영진이 변화와 학습, 소통, 수평적인 프로세스를 전폭적으로 지원하고 메니저는 통제(Control)나 관리(Management)가 아닌 퍼실리테이터(Facilitator: 촉매자)의 역할을 하도록 되어 있다고 가정한다. 퍼실리테이터 역할은 좀 복잡한데 William G. Dyer의 Team Building에서 서술하는 형태라면 적당하다고 본다. 팀원 개개인의 경험 수준보다 약간 더 높은 수준까지 책임을 위임하여 매 프로젝트마다 팀원이 더 큰 스케일의 책임감을 학습 및 경험할 수 있도록 장려한다.

그 다음으로 목표(Mission)는 신규 컨슈머 웹 서비스를 만드는 것으로 한다. 대중 사용자를 타겟으로 하며 1million UV/Month 서비스를 만드는 것이 목표라고 가정한다. 데스크탑 애플리케이션이나 위젯이 아니라 특정 카테고리 내에서의 플랫폼을 지향하는 웹 애플리케이션이며, 엔터프라이즈가 아니라 소비재 서비스라고 가정한다. 따라서 개발 생산성과 기획의 섬세함을 무기로 사용자 이용 패턴에 빠르게 반응해 사용자 볼륨을 신속하게 키우는 것이 핵심이다.

마지막으로 사람(Team) 부문에서, 팀원 개개인은 매우 이성적이고 학습 지향적이며 기존에 서로간에 협력했던 경험이 있고. 자발적이고 끊임없는 소통을 통해 서로를 신뢰하고 있다고 가정한다. 자신이 담당해왔던 직군(3년 이상)에 대해서는 높은 숙련도를 가지고 있으며 그렇지 않은 부분에 대해서도 기본적인 이해와 더불어 적극적인 학습 의지를 가지고 있다. 더불어 내가 전문 직군으로 가지고 있는 부분을 팀원에게 적극적으로 교육시킬 의지가 있다(Environment가 이를 지원한다)


가정의 한계

이 세 가지의 가정은 통계적으로 따지면 전혀 일반적이지 않다. 모두 충족시키는 경우는 굉장히 희소하다고 보는 것이 맞을 것이다. 목표 부분만 봐도, 우리가 한 번이라도 들어본 벤처나 중소기업은 소비재 상품을 만드는 경우가 많지만(그래야 귀에 익으니깐), 실제로 전체 벤처 및 중소기업 비중에서 소비재 기업의 수는 하청 전문이나 B2B(에이전시, SI, 자체 서비스가 있지만 매출의 대부분이 외주개발에서 발생하는 업체 등) 전문 업체에 비해 훨씬 적다.

사람과 환경 부분에서도 저런 케이스는 꿈의 회사라 불릴 법 하다. 다니면 다닐수록 경험과 학습이 축적되어 내 몸값이 저절로 오르는 회사. 효율성과 동기부여, 즐거운 분위기를 장려하는 신뢰 중심의 회사. 그런 회사 어디 없냐고 모두가 찾고 있는 유토피아 같은 회사다. 그럼에도 이런 가정을 하는 이유는, 이런 세 개의 가정을 충족시키는 조직 형태를 지향하기 때문이기도 하고 창업자와 경영진이 창립 초기부터 이런 방향에 대한 공감대와 의지와 운영능력를 갖고 있다면 충분히 가능한 목표라고 보기 때문이기도 하다.


기존의 협업

이런 가정들 하에 어떤 협업 형태가 가장 효율적일지를 한 번 생각해보자. 우선 하나의 프로젝트에서 각각의 팀원에게 일을 할당하는 방법은 Function별 분류와 Product별 분류가 있다. 서비스 개발 조직 내에서 Function별 분류를 해보면 기획, 개발, 테스트, 디자인, 운영 레이어로 분할할 수 있다. (서비스 개발 조직 밖으로는 마케팅, 재무, HR, 전략기획 등이 있겠다) Product별 분류를 하면 팀원의 역할 분배를 서비스 기능(Feature)별로, 함수별로, 페이지별로, 메뉴별로 쪼개는 것을 예로 들 수 있다.

스타트업에서는 창업자 둘~다섯이 필요한 걸 닥치는 대로 하기도 하고, 좀더 체계적이라면 이슈 트레커에서 우선순위가 높은 티켓을 개발자들이 번갈아 맡아서 해결해나가기도 할 것이다. 포털이 진행하는 큰 프로젝트도 하위 레벨로 가면 이와 유사하겠지만, 전체적으로는 직능별 분류 하위에 서비스별 분류로 나뉘어있거나, 서비스별 분류 하위에 직능별 분류로 나뉘어져 있어 체계가 더 잡혀 있다. Function별 분류와 Product별 분류를 조합하는 것이다. 외부 컨설팅을 받아 잦은 조직 개편을 하고 적당한 타협점을 찾아간다.

조직행동론에서는 이런 조직 구조를 '매트릭스 구조'라는 용어로 포괄해버리지만 소비재 서비스를 만드는 IT기업에서는 매트릭스 형태가 당연한 것이어서 매트릭스냐 아니냐가 별 의미가 없고 개발 최전선에서 어떤 방식으로 소통하고 협업하는 지가 더 중요한 요소라고 생각된다. 조직 구조와 더불어 TFT도 중요한 요소 중 하나이다. 고정된 구조와 상관없이 필요에 따라 TFT가 구성되고 직능별 그룹에서 인력이 차출되어 한시적으로 운영되곤 한다. 경영진 직속 조직도 대게 TFT 형태이다.

IT뿐만 아니라 모든 분야에 걸쳐서 시급하고 중요한 일에는 TFT가 결성되지만 새로운 것을 계속 만들어내야 하는 컨슈머 웹 프로덕트의 경우는 운영그룹과 유지보수그룹을 제외한 나머지는 거의 항시 TFT 체제라고 볼 수도 있으며 초기 서비스 개발기간에는 별도의 운영/유지보수 그룹이 필요없기 때문에 전사적 TFT 체제 상태가 된다. 일단 서비스가 자리잡힌 후에는 기존 서비스에 새로운 기능이 추가되는 것을 유지보수로 볼 것이냐 개편으로 볼 것이냐에 따라 고정적인 형태(조직 구조)에 무게중심을 두느냐 가변적인 형태(TFT)에 무게중심을 두느냐가 달라질 것이다.


진짜 고민

TFT가 좋으냐 매트릭스가 좋으냐 고정적인 것이 좋으냐 가변적인 것이 좋으냐는 내가 당장 답을 내야 할 부분은 아니다. 인력이 20명~50명이 넘어가면 점차 고민을 시작해야 할 문제일 것이다. 당장 필요한 결정은 2~5명의 팀이 어떻게 일을 할 것인가이고, 이런 2~5명의 팀이 여러 개가 되었을 때는 또 어떻게 일을 할 것인가이다. TDD나 버전관리, 이슈트레커, 그룹위키 등 효율성 향상 측면에서 의심의 여지가 없는 것들은 당연히 기본사항이다. 고민이 필요한 부분은 예를 들면 이런 것이다.

두 명이 작업하는 데 한 명이 클라이언트 개발자고 다른 한 명이 서버 개발자인 것이 나을까 아니면 각각이 서버와 클라이언트를 다뤄서 기능별로 분담하는 것이 나을까. html/css나 데이터베이스, 시스템은 또 어떻게 분담해야 할가. Product별 분류와 Function별 분류는 '조직'이라는 거시적인 차원 보다는 '역할'이라는 미시적이고 개인적인 차원에서 더 중요한 문제라고 생각한다. 특히 서비스 제작자가 2명인지 20명인지 여부가 서비스 성공 여부와 큰 관련이 없는 컨슈머 웹 서비스의 경우에는 더욱 중요한 문제다.

또 소통 방식과 소통 빈도를 어떻게 해야 할까. 소통 방식을 예로 들면 이슈트레커를 포함한 문서 지향적인 방식이 좋은가 아니면 메신저와 구두를 포함한 속도 지향적인 방식이 좋은가. 그 둘의 비율과 적용 형태는 어떻게 해야 할까. 소통 빈도를 예로 들면 개발자의 집중 시간을 보장하기 위해 정기적으로 정해진 시간(가령 1시간 마다 호출이 있을 때)에만 소통하는것이 나은가 아니면 신속한 소통과 반영을 위해 수시로 빈번하게 이야기를 나누는 것이 나은가.

언어와 프레임워크에 대한 이해도나 코딩 스타일의 차이를 어떤 방식으로 줄이는 것이 좋을까. 코드 리뷰나 페어 프로그래밍 만으로 충분할까. 페어 프로그래밍을 한다면 전체 업무 내에서 페어 프로그래밍의 비중은 어느 정도로 할까. 다양한 문제 해결 방식의 습득(중급자들 간의 페어), 개발 진입장벽 낮춤(중급자와 입문자 사이의 페어), 상대방의 코딩 스타일에 익숙해지고 일치시키는 것 등 페어의 목적 중 어느 것을 중시할 것인가.

기획을 전담하는 인력을 고용할 것인가. 아니면 개발 인력이 기획적 사고 방식을 가질 수 있도록 교육 환경과 시간적 여유, 페어 스토리보딩 기회를 제공할 것인가. UX/디자인 단계를 분리할 것인가 개발이나 기획 안에 포함시킬 것인가. 서비스 개발 프로세스상에서의 디자인 레이어는 기획과 개발을 단절시키는 경향이 있어서 절차적인 방식의 진행에는 디자인 분리가 잘 어울리지만 기획과 개발이 밀접하게 붙어있는 경우는 디자인 단계를 아예 개발 이후로 빼거나 기획자 또는 개발자의 역할 중 일부로 포함시키는 것이 낫다고 본다.


분할 보단 통합

나는 역할 분할 보다는 역할 통합을 지향한다. 팀이 소수여서 어쩔 수 없이 다양한 역할을 감당하는 것이 아니라, 조직 규모가 커지더라도 통합적인 역할을 유지하면서 5명 내외의 팀 구조가 마치 프렉탈처럼 분포해있는 형태를 구상하고 있다. 여기서 말하는 '통합적인 역할'은 팀 개개인이 각자의 분야(예를 들면 기획, 서버 개발, 데이터베이스)를 유지한 체 협력하는 것이 아니라 팀 개개인이 프로덕트 제작에 필요한 모든 분야(기획, 클라이언트 개발, 서버 개발, 디자인, 시스템, 블라블라)를 숙지할 수 있도록 페어로 작업하도록 유도하고 궁극적으로는 개개인이 담당하는 분야와 책임을 확대시키는 것이다.

그래서 페어(페어 프로그래밍이든 페어 디자이닝이든 페어 스토리보딩이든 페어 벤치마킹이든)테스킹이 매우 중요하고 그것의 비중과 목적을 명확히 해야 한다. 코딩 스타일을 일치시키는 것보다는 특정 분야에 대한 선임자가 그 분야에 대한 후임자에게 사고력과 숙련된 습관을 전이시키는 것을 페어의 중요한 목적으로 삼는다. 개발 백그라운드의 팀원과 기획 백그라운드의 팀원이 프로덕트 하나에 대해 기획부터 개발, 배치까지 페어로 함께 작업하도록 하는 것이다. 더불어 디테일한 지식과 정보를 개인적으로 보완하도록 업무시간 내 학습시간을 보장하고 근무시간도 줄여가는 것이 목표다.

최근 포털 조직은 상위 기획 이후에 디테일한 기획이 들어가는 단계에서 개발자가 붙어서 개발 이슈를 함께 검토하는 형태로 효율성을 높이고 있는데 그것과 유사한 점이 있다. 차이점은 내가 언급한 페어 테스킹의 주 목적은 프로젝트의 단기적인 효율성 보다는 팀원 개개인의 효율성을 끌어올려 장기적인 측면에서 조직이 역동성을 갖도록 만든다는 점이다. 개개인의 역할 통합이 이루어지면 결국 개별적인 프로젝트 효율성은 자동으로 달성될 것으로 기대한다.


우려

통합을 지향했을 때의 몇 가지 우려는, 페어를 통한 학습이 개개인의 역할 효율성을 거쳐 프로젝트 효율성, 비즈니스 효율성으로 연결되는 데 얼마나 걸릴 것인가, 프로젝트 완성과 학습을 동시에 지향했을 때 당장의 개발 효율성이 떨어지는 것을 감수할 것인가, 기존의 직능 분리와는 비교할 수 없는 개개인의 학습 요구량을 팀원들이 감당할 수 있는가, 이런 학습을 팀원들이 하려고 하겠는가 등등이다.

솔직히 이런 우려에 대한 명쾌한 대안이 있는 것은 아니다. 이런 것들이 실제로 우려할만한 것들인지 그렇지 않은지도 가봐야 알 수 있다. 그래서 이 글 서론에 환경과 목표와 사람에 대한 가정이 필요했다. 팀원 개개인이 학습지향적이고 회사가 그것을 지원하며, 프로젝트 성격이 학습지향적인 구조가 가장 효과를 발휘하는 컨슈머 프로덕트라고 가정했다. 그 가정들을 적용하면 이런 우려들은 희석된다.


분할의 이유

나는 조직이 커진다고 해서 역할이 세분화되어야 한다고 생각하지 않는다. 직능 세분화는 전문화를 노리고 수행하는 것인데 전통적인 산업의 '생산' 시스템에서는 세분화가 전문화를 이끌어낼 수 있었고 컨베이어 벨트 위에서 꽤 효율적으로 돌아갔다. 반면 소프트웨어 개발은 '생산'이 아니라 '창조 및 개발'이며, 레시피대로 요리를 만드는 것이 아니라 레시피 자체를 매번 새롭게 만드는 지식근로산업이다. 분리된 직무 하나하나를 효율적으로 진행한다고 해서 전체 프로젝트가 효율적으로 진행되는 것이 아닌 산업이다.

공장에서는 병목 지점의 효율성을 끌어올리기 위해 시간 당 작업량을 증가시키거나 인력을 투입하면 되지만 기획과 개발에서는 기획서를 많이 그리고 코드를 많이 작성한다고, 추가 인력이 많이 투입된다고 좋은 서비스가 나오지 않는다. SI, 에이전시, 엔터프라이즈는 생산의 측면을 어느 정도 갖고 있지만 컨슈머 웹 프로덕트는 이들과 비교하면 완전히 창조에 치우쳐 있다. 창조적 프로덕트를 다루는 분야에서는 분할을 통한 세분화, 전문화가 업무 효율성은 물론 동기부여와 목표 도달률을 오히려 끌어내린다고 본다.

웹 프로덕트 제작 과정을 생산 시스템으로 본다면 크게는 기획(UI, UX, 전략, 요구 분석, 운영 포함)과 개발(클라이언트, 서버, UI개발, 테스팅, 시스템)로 분리했을 때 기획 생산성과 개발 생산성, 기획 전문화와 개발 전문화가 달성될 수 있을지 모른다. 빠르게 스토리보드를 만들어내고 빠르게 소스코드를 늘려가는 것은 가능할지 모른다. 하지만 이 과정을 창조 시스템으로 보고 분할된 산출물의 개별적인 퀄리티가 아니라 전체적인 비즈니스 성과(사용자 만족도나 수익모델 발굴, 새로운 킬러 카테고리 발굴 등)로 측정하게 된다면 이야기가 달라진다.

전통적인 시스템에서 기획자는 평소에 서비스들을 벤치마킹하고 내 서비스에 대한 아이디어를 짜고 회의를 하고 스토리보드를 작성하며 어느 정도 정리가 되면 개발팀과 협의를 해서 개발 이슈를 찾아내 기획에 반영한다. 합의가 이루어지면 디자인 팀(또는 UX센터)을 거쳐 최종 인터페이스가 디자인과 함께 도출되고 개발팀에 넘겨져 페이지로 완성된다. 버그를 잡고 서버에 배치된다. 정도의 차이는 있겠지만 일반적으로 이런 과정을 거친다. (너무 당연한 프로세스라 이렇게 정리하기도 민망하다)

기획자는 개발자가 어떤 라이브러리를 사용하는지 데이터베이스가 오라클인지 MySQL인지 알 필요가 없고 개발자는 기획자가 어느 서비스를 벤치마킹 하고 있는지 장기적으로 어떤 플랜을 갖고 있는지 굳이 묻지 않는다. 직능이 분리되어 있으면 내 영역만 알면 되기 때문에 다른 직능의 영역에 간섭하지 않고, 내 직능에 영향을 미치는 부분(개발 이슈에 의해 기획이 변경되거나 개발 로드가 심각하게 많이 걸리더라도 전략상 중요도가 높으면 구현한다던가)에 대해서만 검토를 요청한다.


분할의 비용 - 커뮤니케이션

통합적인 구조를 경험해보지 못했다면 세분화 구조에서 발생하는 비용을 눈치채지 못한다. 세분화의 비용은 커뮤니케이션 비용과 책임 분산에 따른 비용, 비즈니스 기회 상실의 비용, 학습 효율성 상실의 비용, 분야 추종의 비용 등이 있다. 커뮤이케이션 비용은 세분화에 의해 문서작업이 늘어나는 것만을 의미하지 않는다. 기획과 개발 사이의 선이 명확할수록 기획서는 사전에 완벽에 가깝게 정의되어야 하며 더 상세해져야 하고, 프로젝트 메니저와 나머지 실무자 사이의 선이 명확할수록 스케쥴링은 빈틈이 없어야 하고 맨먼스에 대한 기준이 정확해야 하며, 아키텍트와 개발자의 선이 명확할수록 개발 명세가 명확해져야 하는 문제가 있지만 그보다 더 큰 문제는 종합적인 판단이 느려지고 판단의 정확도가 떨어진다는 점이다.

모든 개발 작업에는 비용과 효과 요소가 있는데 비용이 커도(시간이 오래 걸리고 어렵고 불확실성이 크고 개발자가 많이 필요) 효과도 그만큼 크다면(그 서비스로 인한 기대 수익이 100억이라던가) 그것은 개발되어야 하는 합리적인 근거가 있는 것이고, 그렇지 않다면 개발 할지 여부를 다시 판단해야 하는 것이다. 그런데 이때 개발 파트에서 그 기능의 중요도를 판단하는 근거는 기획자의 의지(고집 또는 취향)에 의존해야 하고 기획 파트에서 그 개발의 비용을 산출하는 근거는 개발자의 예측(고집 또는 취향)에 의존해야 한다. 서비스 기능의 중요도와 개발 난이도를 양팔 저울에 놓고 비교해야 하는데 실제로는 합리적인 비교가 아니라 두 파트 가운데 영향력이 큰 쪽을 따르게 될 가능성이 있는 것이다. 기획 파트에서 해야 한다고 하면 무조건 하게 되는 조직이 있고 개발 파트에서 못한다고 하면 절대 못하게 되는 조직이 있다.

반대의 경우도 문제다. 기획 파트에서는 가볍게 제안한 기능인데 구현이 까다로웠음에도 개발 파트가 기획 파트의 의견을 존중해서 그것을 구현해 내게 되면, 이제 이 기능에는 감정적인 요소가 포함되어 일종의 매몰 비용임에도 쉽게 제거할 수 없게 된다. 파생되는 부수적인 문제점은 이런 경험이 쌓여 기획 파트에서 개발 파트에 기능 제안을 할 때 심리적인 부담감을 느끼게 되거나 개발 파트에서 기획 파트의 이야기를 들을 때 방어적 또는 냉소적으로 변할 수 있다는 점 등이 있다. 물론 이런 문제는 잦은 커뮤니케이션과 서로의 능력과 의도에 대한 신뢰를 통해 극복할 수 있다.


분할의 비용 - 학습과 비즈니스 기회 상실

책임 분산의 비용은 쉽게 알 수 있듯이, 기여도가 분산되어 성과 측정이 어렵다거나 동기 부여 측면에서 불리하다는 점, 개발 파트에서 매출 등에 대해 무관심할 수 있다는 점 등이 있다. 학습 효율성 상실이나 비즈니스 기회 상실 비용은 일반적으로 비용으로 생각하지 않을텐데도 개인적으로는 가장 지불하고 싶지 않은 비용이다. 이 둘은 연결지어 볼 수 있다. 기획자가 기획자들 물에서만 놀면 제한된 관점만 갖게 된다. 개발자 역시 개발자들 물에서만 놀면 제한된 관점을 갖게 된다. 자신의 페러다임 안에 갖히는 것이다. 이 두 직군이 PC를 사용하는 방식, 웹서핑하는 방식, 그리고 읽는 글의 종류는 극단적으로 다르다. 서로간의 경험이 완전히 배타적이어서 서로가 상대방의 영역에서 얻을 수 있는 인사이트를 완전히 놓치고 있다.

기획자가 취미로 구글 앱 엔진을 써보고 오픈 API 메뉴얼을 읽고 오픈소스 커뮤니티를 돌아다녔을 때, 개발자가 취미로 UX서적을 읽고 IT칼럼을 읽고 새로운 웹서비스의 UI를 캡쳐하고 다녔을 때, 이 둘의 사고의 폭은 기존의 '기획 전문가', '개발 전문가'와 어떻게 달라질까. 더 나아가 학습하는 기획자 출신이 잘 교육받아 개발까지 하고 학습하는 개발자 출신이 잘 교육받아 기획까지 했을 때 무슨 일이 일어날까.

기획적인 인사이트를 갖게 된 개발자는 앞으로 어떤 오픈소스 프로젝트나 라이브러리를 보더라도 비즈니스와 연결지어서 사고할 수 있는 능력을 갖게 되었다. 개발 인사이트를 갖게 된 기획자는 새로운 서비스를 보게 되면 어떤 자바스크립트 라이브러리를 썼는지 어떤 메시업이 사용됐는지 파악할 수 있게 되었다. 서비스를 벤치마킹할 때 개발 이슈를 동시에 검토해버리는 것이다. 개발 커뮤니티에서의 이슈와 기획 커뮤니티에서의 이슈 사이의 시간차를 좁히는 회사가 역사상 비즈니스 승자가 된 사례가 많다. 또 무엇을 경험하든 종합적으로 보고 종합적으로 배울 수 있다. 페러다임 안에 갖힌 특정 직군과 비교해 놀라운 학습 효율성을 얻게 된다. 더불어 생산 효율성과 전체적인 비즈니스 안목도. 이제 이들은 기획자, 개발자로 불리기 애매한, 단지 '서비스 제작자'일 뿐이다.


분할의 비용 - 분야 추종

사용자 경험이든 리팩토링이든 데이터베이스 튜닝이든 모든 기획/개발 업무의 가장 중요한 목표는 사용자 만족이고 비즈니스로서의 성공이다. 세분화의 장점은 전문적인 지식의 습득이라고 했는데 전문화가 지나치게 진행되면 이것이 오히려 시야를 좁혀 자신의 업무를 비즈니스에 연결짓지 못하게 될 수 있다. 가령 인터페이스 설계의 극단으로 가면 사용자의 화면에 대한 인지적 반응속도를 계산한다거나, Eye Tracking를 기준으로 화면을 설계한다거나, input/output 데이터의 비율로 UI적합도를 측정한다거나, 버튼들의 위치좌표와 입력창을의 관계를 로그함수에 넣는다거나..

이런 것들이 '사용자 만족'이나 '비즈니스 성과'에 얼마나 밀접할지 장담할 수 없다 . 그리고 심지어 이런 고려들은 커뮤니케이션을 더 많이 만들어내고, 업계의 버즈워드에 휘둘리고, 다른 세분화된 직능의 의사결정에도 영향을 미쳐서 전체 프로젝트 생산성과 효율성을 오히려 끌어내릴 것 같다. 오늘 어떤 업무를 하더라도 이것을 왜 하는 것인지, 이 일이 어떤 효과가 있을지, 최종 목적으로 향하는 끈을 놓치 않고 있어야 하는데 업무가 점차 세분화의 극단으로 갈수록 그것이 어렵게 된다. 학창시절에 왜 공부해야 하는지 모를 경우 공부가 잘 안 되고 하기 싫었던 것과 비슷하다.

또 다른 예로 개발자의 관점에서(기획자의 관점에서도 어느 정도) 기존의 판도라TV는 비판 거리가 많았는데, 문제는 그런 비판 요소들이 대부분 제거된(앞단 광고 제외) 지금까지도 그 비판 기조를 유지하고 있다는 점이다. 파이어폭스에서 화면이 깨져보이면 엉망인 서비스라고 판단해버리거나 사파리에서 깨끗하게 보인다고 너무 심한 호감을 갖는다던지 하는 점도 서비스를 객관적으로 벤치마킹하는 데 방해가 된다. 사용자 입장에서 불만을 표시하고 호감을 표시하는 것은 문제될 것이 없지만, 서비스를 벤치마킹 하거나 내 서비스를 만드는 입장이라면 감정적, 취향적 관점을 배제하고 통계적, 비즈니스적 관점으로 관찰해야 한다.

전문화에 대한 지나친 추종이, 정해진 직능 내에서 아무런 발전도 하지 않는 것보다는 낫겠지만 통합적인 협업을 통해 다른 직능에 대한 이해를 지향하게 되면 내가 속한 직능에 대해 편향된 애착을 갖지 않고 전체 요스들을 수평선상에 놓고 합리적으로 평가할 수 있다고 기대한다. 사용자 만족과 비즈니스 성과라는 목표에 좀더 가까운 중요한 요소들을 우선순위 상위에 놓고 집중할 수 있다.


서버 개발과 클라이언트 개발의 통합

기획자 내에서도 전략기획, 상위기획, 하위기획, 사용자 요구 분석 등 직군이 다양하고 개발자도 클라이언트, 서버, 시스템, 데이터베이스, QA 등 다양한데 기획자 내에서의 업무 이동이나 개발자 내에서의 업무 이동 및 통합은 기획자-개발자 간 업무 이동 및 통합에 비해 수월한 편이다. 하지만 개발 파트 내에서도 특히 클라이언트 개발과 서버 개발 만큼은 이동과 통합이 어려운 편이다.

서버 프로그램과 데이터베이스까지는 프레임워크와 라이브러리 등이 적극적으로 지원하는 추세이고 시스템은 호스팅도 좋아지고 OS도 간편해지고 있어서, 이 세 가지는 통합이 용이하다. 그런 반면, 서버 측과 클라이언트 측은 아직까지 분리된 상태로 남아있다. 뷰 템플릿이 아무리 발전해도, 서버 프로그램 언어로 자바스크립트를 메타 프로그래밍 해주는 라이브러리가 제공되어도, html, css, javascript는 결국 새로 습득해야 되는 영역이다.

기술적으로 많이 다르다는 것도 한 몫 하지만 심리적인 장벽도 높은 것 같다. 서버 개발자는 가볍고 불안해보이는 자바스크립트를 적극적으로 배우고 싶지 않고, 자바스크립트 개발자는 자바스크립트 기교를 서버 프로그래밍에 활용할 수 없다는 점 때문에 지루해한다. 서버 측의 고민은 주로 시스템이나 데이터와 관련된 반면 클라이언트 측 고민은 인터페이스나 크로스브라우징, 룩엔필 등과 관련되어 있으니 관심사도 다르다. 이렇게 기술적 장벽과 심리적 장벽이 분명 존재하지만 그럼에도 나는 둘의 통합을 지향하는 편이다.

대부분의 서버 프로그램 개발 에디터는 자바스크립트와 html, css 개발도 지원한다. 코드 힌트가 제공되고 메서드, 변수, 주석 등의 폰트 처리를 해준다. Aptana만 해도 자바스크립트 개발 최고봉 에디터(논란의 여지 많음)이면서 레일스 개발 최고봉인(이것도 논란) RadRails가 통합되어 있다. 넷빈즈 루비 패키지를 비롯해 서버와 클라이언트를 통합하기위한 에디터 조건은 갖춰져 있다.

기술적으로는 다르지만 개발 작업 시에 둘은 심하게 밀접하다. 클라이언트 사이드를 개발할 때 특히 서버 사이드의 개발자와 빈번하게 소통해야 한다. 자바 스크립트를 객체지향으로 작성한다고 가정하면, 어떤 객체는 브라우져 내에서만 놀지만 어떤 객체는 주기적으로 서버와 소통을 하는 XHR 객체를 관리하기도 한다. 서버의 어떤 스크립트가 이 객체의 요청을 처리할지, 반환되는 데이터는 JSON으로 할지 텍스트로 할지 XML로 할지 HTML로 할지 그리고 이들의 넘겨받는 파라미터와 넘겨주는 파라미터 항목은 무엇으로 할지 등등 두 사이드가 분리되어 있을 경우 서로 협의해야 할 부분이 많고 빈번하다.

자바 스크립트와 서버 개발은 어차피 동시에 하지 않는다(물론 일정 부분은 동시에 진행할 수 있다). 기본적인 데이터 뷰잉을 서버 사이드에서 처리해준 후에 UI나 비동기 데이터 처리부분을 자바스크립트로 Unobtrusive하게 덮어 씌우는 것을 장려한다. 덮어 씌우는 과정에서 서버 사이드에서 제공할 부분, 즉 데이터를 넘겨 주거나 받는 것에 대해 협의한다.

Ajax 요소가 많을수록 협의는 더 빈번해지는데 이 때 협의되는 내용은 중요한 결정사항이라기 보다는 단지 요청의 응답과 전달 방식을 정하는 것이 전부이기 때문에 그렇게 생산적인 토론이 아니다. 내가 두 사이드를 다 개발하면서 느낀 점은 두 사이드가 두 개발자로 분리되어 있을 때 상당한 비효율이 발생하고 더 좋은 처리 방법을 놓칠 수 있다는 점이다.

서버에서 처리할 수 있더라도 어떤 부분은 클라이언트에서 처리하는 것이 트래픽 비용 절감이나 서버 자원 절감을 위해 유리한 경우가 있고, 사용자가 페이지 로딩 시의 지체를 느끼지 못하도록 일부를 먼저 표시하고 나머지를 비동기로 가져온다던가 할 경우가 있다. 이런 트릭을 구상해 내고 큰 어려움 없이 쉽게 적용할 수 있으려면, 무엇보다 이렇게 하겠다는 결정을 내리려면 두 사이드에 대한 프로그래밍 경험이 있어야 한다. 물론 경험 뿐만 아니라 실제로 둘 다 하고 있는 것이 더 좋다고 보고.

서버 사이드 개발자에게 클라이언트 사이드 지식을 교육시키고 클라이언트 사이드 개발자에게 서버 사이드 지식을 교육시키는 방법은 심플하다. 그 둘을 페어로 작업하도록 해서 클라이언트와 서버를 함께 개발하게 하는 것이다. 기술적인 차이는 있지만 어쨌든 둘다 프로그래밍이기 때문에 일단 진입 장벽만 낮추어주면 우려보단 쉽게 학습할 수 있다고 기대하고 있다. 아참, 클라이언트 사이드에서도 UI개발이라 불리는 html/css는 물론 통합에 포함되고 페어에도 포함된다.


디자인의 통합

그렇다면 디자인 작업은 언제 어떤 방식으로 이루어지느냐는 질문을 종종 받는다. 디자인은 크게 html/css에 해당되는 '코드' 부분과, 로고나 버튼, 메뉴, 배경 이미지 등의 '이미지' 부분이 있다. 코드 부분은 클라이언트 사이드를 개발할 때 동시에 진행되고, 이미지 부분은 코드가 완성된 후에 프로그래밍 흐름을 끊지 않는 선에서 투입된다. 기존의 디자인 프로세스와 가장 큰 차이점은 기획과 개발 사이에 디자인 '프로세스'가 떡하니 자리잡고 있지 않다는 점인데, 디자인은 프로세스가 아니라 '요소'로서 중간중간에 작업한다.

이런 게 가능한 이유는 기존처럼 테이블 테그로 와꾸를 잡지 않아서이다. 기존처럼 테이블 테그로 골격을 잡고 셀 안에 이미지 조각들을 채워넣는 방식으로 디자인을 하면 인터페이스 변경에 의해 픽셀 사이즈가 달라졌을 때 디자이너가 고쳐야 할 부분이 한두가지가 아니다. 그래서 디자이너는 기획서의 정확성 및 변경 불가를 요구하고 이 과정에서 기획자는 가뜩이나 서비스 아이디어로 복잡한 머리속에 픽셀 규격까지 밀어넣어야 한다. 디자인 작업에서 실제 브라우져 표시되기까지의 간극이 길기까지 하다. 디자인 작업 안에 html 코딩이 포함되고, 디자인으로 덮어씌워진 html 코딩을 받아야 개발자가 마무리(또는 이제 시작)를 지을 수 있다.

이제는 웹표준의 시대이니 만큼 서버 개발자가 뷰 템플릿 안에서 html 테그를 직접 다루고, 클라이언트 개발자(방금 언급한 서버 개발자이면 더 좋음)는 html 페이지의 레이아웃과 폰트, 백그라운드 컬러 등을 css로 잡는다. 레이아웃 위치나 가로세로 픽셀은 언제든지 코드 한 줄 수정해서 변경할 수 있고, 파이어버그를 통해 변경 전에 프리뷰를 할 수도 있다. 그리고 페이지의 모든 부분을 이미지로 채우지 않고, 필요한 부분을 정해 이미지를 백그라운드로 삽입하거나, 버튼, 아이콘, 로고 등 부각되어야 하는 요소만 간단하게 이미지 작업(직접 하든 친구에게 부탁을 하든)을 해서 채워 넣는다.


마무리

개개인의 효율성을 향상시켜 직능을 통합하는 것은 지금 시작하는 조직, 변화에 능동적인 작은 조직이 해봄직한 것이지, 규모가 커져서 조직 구조가 어느 정도 고착화되어 있는 조직에 적용하기에는 리스크가 너무 크다. 경영진의 입장에서는 이런 통합이 효율성을 담보할 수 있더라도 근로자 입장에서는 통합에 적응하는 학습 지향적인 소수만 남고 나머지에게는 구조조정 대란이 올지 모른다. 서론에서 언급한 세 가지 조건에 해당될 때만 시도해보기!

Flying Mate는 Running Mate에서 따온 단어다. 미 대선에서 대통령 후보자가 지명하는 차기 부통령 후보를 러닝 메이트라고 한다. 둘은 한 배를 탄 파트너가 되어 서로의 정책과 노선을 보완하며 대선을 치른다. 예를 들면, 현재 경선 결과가 오바마 쪽으로 기울면서 힐러리가 러닝 메이트로 지목될 가능성이 거론되고 있다.

이런 헤프닝도 있었다. 자신에 대한 지지발언을 하는 82세 노인에게 자신의 러닝 메이트가 되어줄 생각이 없느냐고 물어 훈훈(?)한 분위기를 연출했다. 힐러리는 이미 몇 개월 전부터 자신이 경선에서 승리했을 경우(이미 상황은 불리해져 가고 있었음) 오바마를 러닝 메이트로 지목할 가능성을 시사했었다. (발음할 때마다 느끼는 거지만 오바마의 이름은 참 운율감있다)

러닝 메이트는 정치적인 의미도 담고 있지만 일반적인 의미의 파트너, 동반자라는 뜻으로도 사용된다고 한다. 경마에서는 출전하는 말의 연습상대가 되어 함께 뛰어주는 말을 러닝 메이트라 한다는데 국내에서 만들어진 말인지 실제로 영어권에서도 그렇게 쓰는지는 모르겠다.

러닝 메이트라는 단어가 특별히 강렬하게 꽂혔던 경험은 미드 '24'의 시즌 6 에피소드 9편을 보면서였다. 스포일러 자제를 위해 상황만 간단히 말하면, 웨인 파머 대통령과 다니엘스 부통령 사이에 심각한 의견차가 생겼을 때 부통령은 러닝 메이트 시절을 언급하면서 대통령의 신념을 비판했다. 아래에 그 비판 내용.

Mr. President... You approached me to be your running mate because you knew I could deliver voters who questioned your... experience, who were afraid that your Presidency would be too weak on national defense, and I... assured them otherwise, but now you're proving them right. There's a thin line between conviction and stubbornness. You can stand firm, but just know that... you're standing alone.

대통령 각하.. 당신이 나를 러닝 메이트로 지목한 이유는, 각하의 경험에 의심을 품고 국방력 약화를 우려하는 사람들의 표를 제가 모을 수 있다는 걸 아셨기 때문이죠. 그리고 전 그들을 안심시켰습니다. 하지만 당신은 그들이 옳았다는 걸 보여주시는 군요. 신념과 완강함은 종이 한 장 차이입니다. 당신이 굳건할 수는 있지만 홀로 남게 된다는 것을 알아두세요.

자국 내 테러 사건이 산발적으로 발생하고 있고 그 배후에 이슬람 세력이 있다는 증거가 발견되는 상황에서, 파머 대통령은 온건 정책으로 이슬람 세력이 자발적으로 테러범 색출에 도움을 주기를 기대했다. 반면 부통령은 이슬람 민족의 격리수용 등 적극적인 보안 정책을 펴 테러를 예방하자고 주장했다.

두 사람의 정책은 옳고 그름의 잣대로 평가할 수 없고, 어떤 정책이 더 좋은 결과를 가져올지도 알 수 없으며, 인권이나 형평성 문제에 대해서도 가치관에 따라 우선순위 판단이나 결과 평가가 달라지기 때문에 참으로 결정하기 어려운 문제이다. 둘은 모두 자신의 신념에 의해 움직이고 있다. 서로 미워서 논쟁하는 것이 아니다. 성향의 차이, 그리고 중요시하는 가치의 차이, 자국민의 범주를 어디까지로 할 것인가에 대한 정의의 차이가 있을 뿐이다.

이렇게 해서 내가 받아들인 러닝 메이트는 차가우면서도 뜨거운 단어가 되었다. 목표와 과정을 공유하는 파트너이지만 서로 견제하기도 하고 자극하기도 하고 협력하기도 한다. 친구나 가족처럼 마냥 편들어 주거나 감싸주는 것도 아니고 그렇다고 적이나 경쟁자처럼 공격하거나 방해하는 것도 아닌, 그 중간쯤의 역할을 한다.

러닝 메이트가 나와 반대되는 관점에서 자신의 신념을 주장해주기 때문에 나 역시 나의 관점에서 내 신념을 주장할 수 있고, 그가 나에게 없는 능력을 발휘해주기 때문에 나 역시 내가 가진 능력을 발휘하는 데 집중할 수 있다. 함께 달리기도 하고 누가 더 빨리 달리나 내기하기도 한다. 그래서 Flying Mate는 Running Mate의 비교급 내지는 최상급 이랄까. 나는 것이 뛰는 것보다 더 멋진 일이니까.

난 함께할 Flying Mate를 찾고 있다. 그리고 나 역시 누군가의 Flying Mate가 되기를 바라고 있고 그것을 위해 노력하고 있다. 사실 그 동안 도약했던 순간마다 그 순간의 Flying Mate가 있었다. 그 순간 나 역시 그의 Flying Mate였을 것이다. Flying Mate 감이라고 생각했는데 성급한 판단이었던 적도 있고, 나를 그렇게 생각했는데 역시 성급한 판단이었다고 아쉬워한 사람도 있을 것이다. 그 동안 Flying Mate에 대한 기준이 많이 높아져 버렸다.

찾을 수 있을까? 찾을 수 있을 것이다!

스타트업 웹 서비스는 벤처를 지향할 수도 있고, 그렇지 않을 수도 있다. 스타트업이라는 어휘 자체가 닷컴 버블 무렵에 나오기 시작한 것이라서 벤처의 뉘앙스를 어느 정도 내포하고 있긴 하다. 하지만 만약 스타트업이 일반적인 신생 서비스를 포괄적으로 의미한다고 가정하면, 모든 스타트업이 벤처가 될 필요는 없다고 말할 수 있다.

벤처라는 어휘의 정의는 기본적으로 실패의 위험성을 포함하고(involves the risk of failure) 있다. 어떤 새로운 회사가 만드는 새로운 웹 서비스가 만약 매우 큰 리스크를 포함하지 않는다면 그 서비스를 만드는 회사는 벤처 회사가 아니라 단지 새로 시작하는 회사일 뿐이다.

벤처와 스타트업의 구분은 너무나 당연한 이야기이면서도 쉽게 망각하는 부분이다. 레일스의 창시자이자 Profitable한 서비스 포트폴리오를 구축하고 있는 37signals의 DHH(David Heinemeier Hansson)는 프리젠테이션을 통해, 그런 스타트업들이 너무 벤처만을 지향하는 트렌드를 꼬집고 있다. (링크를 공유해주신 험블님께 감사드립니다!)

나 역시 그런 성향을 저번 포스트에 첨부한 PPT에 담았었다(DHH가 꼬집는 바로 그 성향). B2B 서비스(에디터, 오피스, 그룹웨어 등)가 아니라면 For Free를 기본으로 하고 사용자 기반과 페이지뷰로부터 디지털 컨텐츠, 광고, 판매 중개 등을 최적화해 비용을 상쇄하는 전략을 세우고 있다.

DHH가 말한데로 사용자 타겟을 합리적인 수치(100~1000)로 잡고 적절한 Price 전략으로 Profitable($1M+)한 서비스 포트폴리오를 구축하는 것은 좋은 전략이다. 37signals의 서비스들은 내가 위에서 언급한 B2B 중 그룹웨어에 속한다고 볼 수 있다(좀더 캐쥬얼한). 하지만 그 이외의 전략을 모 아니면 도(Billion or Die)나 허상(Next Facebook, Next Myspace, Next Youtube)이라고 몰아세웠다는 느낌이 들어서 고개를 조금 갸우뚱 하게 된다.

그 이외의 전략이란, 위에서 말했던 '벤처'라고 볼 수 있는데 VC(벤처 캐피털)나 외부 차입금을 등에 엎고 초반 적자를 감당하며 사용자 기반을 빠르게 확장시키는 전략을 말한다. DHH가 이것 대신 제안한 전략은 밀리언 달러 정도의 기대치를 세우고 1/10~1/100 정도의 성공 확률로 작은 서비스들을 시도하는 것이다.

성공 확률이 십분의 일이라. 오프라인 점포 사업에 비하면야 낮은 확률이지만(아닐지도) 100명에서 1000명 정도를 만족시킬 서비스 하나를 만드는 데 드는 비용은 매장 하나 임대하는 비용보다도 저렴할 것이다. 시간과 비용 조절을 잘 하면 여러 번 시도할 수 있기 때문에 기대치만 높게 잡지 않는다면 합리적인 전략이 될 수 있다.

반면 벤처라고 불릴 수 있는 비즈니스는 성공 확률이 1/10,000~1/100,000로 급격하게 감소하지만 빌리언 달러를 기대할 수도 있기 때문에 성공확률과 수익기대치의 곱(million * 1/10 == billion * 1/10,000)은 결국 위의 비즈니스와 같아진다. 진짜로 같진 않겠지만 어쨌든 낮은 성공확률만큼 높은 기대수익이 있다는 관점에서 보자는 것이다.

둘 사이에 장단점이 있는데 DHH가 전자의 비즈니스에 무게중심을 두는 것은, 자신의 경험(37signals를 일으키는 데에 외부 자금의 도움을 받지 않았다)에 기반한 것이기도 하고, 리스크를 싫어하는 본래의 성향 때문이기도 할 것이다. 나는 그런 의견의 반대 측면을 살펴보기 위해 37signals에 대해 곰곰이 생각해봤다.

일단 37signals의 서비스 포트폴리오는 위에서 언급한데로 B2B 그룹웨어이다. 꼭 기업단위로 사용하지는 않을지라도 주요 타겟은 비즈니스 용도로 사용하는 직장인/개발자/팀이며, 그렇지 않은 일반인이 사용하는 경우도 있지만 일반인에게서 의미있는 Subscription 수익이 발생할 것 같진 않다. 사용자는 Customer처럼 가입해서 사용하지만 실제로 사용자는 Customer 보다는 Client에 가까운 그런 서비스다.

37signals는 개발 팀원 개개인의 명성과 오픈소스 참여 실적, 출판과 블로깅 및 컨퍼런스 강연 활동 등으로 PR 효과를 보았다. 이런 활동들로 인해 잠재 Client들(개발자들, 기업 고객)에게 널리 알려졌고 그렇게 사용자를 확대해 현재 꽤 큰 매출 규모(multi-million)를 갖고 있다. 물론 애플리케이션도 유용하면서도 캐쥬얼하게 잘 설계되어 있다.

별다른 투자도 리스크도 없이 사업을 궤도에 올려놓은 DHH가 한 주장이니 일리가 있다. 그런데 생각해보면 일반적인 회사는 37signals가 성공한 방식으로 성공하기가 더 어려울 수도 있다. 37signals는 애플리케이션 사용료로서 Subscription을 받는데, 커스터마이징되지 않은 웹 애플리케이션 사용료로 돈을 지불할 클라이언트는 많지 않다.

실물을 구매/임대한다는 인식을 주지 못하면 지갑 열기 힘들다. 그래서 Subscription 수익모델의 서비스들은 대게 스토리지나 네트워크 사용량에 따라 돈을 받는다. 사용자들은 실물 자원(서버, 스토리지, 트래픽)에 대한 지불은 합리적이라고 생각하지만, 애플리케이션에 대해서는 지불하기 전에 대체제를 먼저 찾으며 대게 무료로 제공되는 대체제가 존재한다.

DHH가 예로 든 온라인 팩스 서비스와 소프트웨어 다운로드 서비스 역시 애플리케이션 기반 사업이 아니라 실제 통신 비용을 소비하는 팩스와 실제 가격이 있는 소프트웨어의 유통에 마진을 얹는 사업이며, 애플리케이션 사용료를 받을 수 있는 서비스 모델은 37signals처럼 그룹웨어, 에디터 등을 포함한 B2B 솔루션 정도밖에 없다.

그런 카테고리 가운데 시장이 남아있는 것은 별로 없고, 더군다나 MS와 경쟁해야 하며, 수많은 무료 경쟁 서비스들과 비교해 경쟁 우위를 유지해야 한다. 37signals는 MS나 무료 서비스들과 경쟁해서 나름의 마켓 쉐어를 확보한 것인데, 이것이 벤처가 성공하는 것 만큼 확률이 낮은 일은 아닐까. 또 양적으로 수천명의 클라이언트를 확보하지 못하면 질적으로 소수의 클라이언트에게 커스터마이징해 고객 당 수익률을 높이려 들 것인데, 그러면 결국 SI로 간다.

DHH가 하고 있는 사업이나 DHH가 제안하는 사업은 서비스와 SI 중간의 어디쯤인 것 같다. SI가 나쁘다는 것이 아니라, SI 사업이 의미가 있는 만큼 반대편에 있는 벤처도 의미가 있다는 이야기를 하려는 것이다.

37signals의 천재 인력들이 뭉쳐서 저런 다방면의 활동으로 PR효과를 유발시켜서 얻은 수익이 멀티 밀리언, 우리 돈으로 연 매출 수백억이다. 레일스는 현재 업계 최대의 이슈 중 하나인데, 그런 레일스의 PR 효과가 그 정도 매출이다. 레일스가 없었다면 37signals, GettingReal이나 Signal vs Noise가 알려지기나 했을까.

그 레일스를 이용해 다른 업체(Slideshare 등)가 개발한 애플리케이션들은 이미 멀티 밀리언 투자를 받아 빌리언 단위의 매각을 향해 달려가고 있는 것과 대조해볼 수 있다. 37signals의 전략은 잘 먹혔고 의미가 있었지만, 어쩌면 그들이 VC를 끼고 자신들의 서비스를 다른 방법으로 붐업했다면 지금 벌써 빌리어네어가 되었을지도 모른다. 뭐 일어나지 않은 일이라 알 수 없는 일이니.

Subscription 수익모델의 애플리케이션과 페이지뷰를 기반으로 한 수익모델의 애플리케이션은 설계가 다르다. 또 Subscription을 기반으로 하더라도 무조건 결제가 아니라 기본 서비스는 무료, 프리미엄 서비스일 때 결제해야 하는 결제 구조를 가지고 있는 경우 어느 정도 리스크를 포함할 수밖에 없지만 무조건 결제 보다는 사용자 기반이 빨리 성장할 수 있다.

사용자 기반이 어느 정도 이상에 도달하기 전에는 적자가 나는데, DHH가 For Free의 반대 개념으로 말한 Price(유료 결제 서비스 또는 Subscription) 전략은 VC의 자본력을 활용하는 벤처에게도 유효하다. VC가 하는 역할이 바로 어느 정도 적자에 사업 전략이 휘둘리지 않고 사용자 기반을 과감히 늘리도록 총알을 대주는 것이다. For Free든 Subscription이든 손익분기에 도달하기 전까지 초반 적자는 필연적이다. 자기자본은 부족한데 VC는 싫다면 차입금으로 부채율이 높아지는 것을 감수해야 한다.

37signals처럼 파트타임 작업만으로(초반) 사용자가 결제할 용의가 있는 서비스를 만들 수 있는 팀은 거의 없다. 그럴 수 있는 능력이 있는 팀은 차라리 VC에게 프로토타입을 보여주고 지분 희석해서 밀리언 달러를 모은 다음 1~2년 정도 풀타임으로 2~3개의 서비스 개발에 매달리는 것이 성공 확률이 더 높을 것 같다. 그리고 37signals가 Subscription할 수 있는 가장 기본적인 카테고리(그룹웨어, Chat, ToDo, Calendar, Project 등)를 이미 점령했다(반은 농담이다).

VC가 참여했다는 것은 이미 밀리언 달러의 투자를 받아 회사 가치가 멀티 밀리언 달러 이상이 되지 않으면 투자 수익률이 나오지 않는 다는 것을 의미한다. 가령 비공개 베타중인 검색엔진 Powerset을 MS가 $100M 정도 선에서 비딩(bidding)할 의사가 있다고 하는데 Powerset은 세 투자자로부터 $12.5M의 Series A 펀딩을 받았다.

만약 펀딩의 대가로 12.5% 이하의 지분(그 이상일 가능성이 크지만)이 희석되었다면 그 딜은 일어나지 않을 가능성이 크다. 만약 일어난다면 차익 회수가 아니라 청산이 되는 것이다. MS의 bidding으로부터 Powerset의 시장 가격을 일단 알았으니 VC들은 이제 Powerset의 가격을 올리기 위해 구글, 야후 등에게 bidding을 제안하기도 하고 서비스 공개를 서두르거나 유명 인사 영입, Series B 펀딩 유치 등 다양한 조치를 취할 것이다.

이 점이 벤처와 스타트업이 다른 점이다. DHH는 벤처가 아닌 스타트업을 이야기하고 있고 그가 우려한, VC를 등에 엎은 스타트업은 벤처의 길을 간다. 전자는 금전적인 리스크를 피해 기회 상실의 리스크를 감수하고, 후자는 기회 상실의 리스크를 피해 금전적인 리스크를 감수한다.

일단 투자를 받았으면 금전 부분은 벤처 회사의 리스크가 아니라 VC의 리스크이며, VC는 Risk Hedge를 위해 포트폴리오 관리에 많인 리소스를 투입한다. 투자 받은 회사는 성공 가능성을 높이기 위해 즉 주주(자신과 VC)수익률을 높이기 위해 전력투구하고 리스크 관리는 VC의 전문성을 믿는 것이다.

그렇게 익숙하고 흔하게 사용해왔던 벤처의 의미를, 곰곰이 되짚어보니 느낌이 새롭다. 1/10,000 이하의 확률을 감수하지 않으면 벤처가 아닌 것이다. 우리가 만들려는 것은 벤처인가 그냥 스타트업인가. 스타트업에 적합한 성향의 사람과 분야가 있고, 벤처에 적합한 성향의 사람과 분야가 있는 것 같다. 나는 어느 쪽일까.