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에 참가할 계획이구요. 아 처음으로 미국 땅 밟아보나요.