일기장/2011-04-16

티몬 정리 2탄. 오늘은 내가 티몬에서 이루고 싶었던, 그러나 이루지 못했던 것들.

첫번째는 레퍼런스 확보. 기술력이 부족한 벤처 기업의 기술력을 채워주는 회사로서의 이콜레모를 과시할 수 있는 기회였다. 사실 이콜레모 시작하고 나서 아이디어가 있으니 같이 해보자는 사람들 무수히 찾아왔지만 다 거절했다. 난 아이디어의 가치를 10원이라고 보는 사람이기 때문이다. 중요한 것은 그 아이디어를 실행해서 비즈니스 모델이라는 것을 증명할 수 있는 능력이다. 내 아이디어, 우리 팀원의 아이디어라면 불확실하든 말든 내 몸 던져볼 수 있지만, 불확실한 남의 아이디어를 위해 시간을 쓸 생각은 없다.

그런데, 티몬은 달랐다. 물론 아이디어 자체도 copycat이니만큼 검증되었다고 할 수도 있겠으나, 어쨋든 불확실한 요소가 가득한 가운데 뚝심 있게 추진해서 비즈니스 모델을 증명했다. 심지어 개발자도 없었는데 말이다. 이것만으로도 충분히 걸어볼 가치가 있는 회사였다. 그래서, 난 여기서 이콜레모가 이렇게 성장하는 벤처의 기술력을 책임질 수 있을 만큼 실력이 있다는 것을 보여주고 싶었다. 그래서 용역 계약 형태지만 실장직도 수락했고, 정말 티몬과 한 식구인 것처럼 일했다. 난 솔직히 경영진 중에 대표 말고는 나만큼 진지하게 티몬의 미래를 고민하고 염려한 사람 없다고까지 생각한다. 다들 눈앞의 성과와 경쟁에만 휘둘릴 뿐.

아뭏든, 그동안은 이콜레모가 말도 안되는 일정의 프로젝트를 나름 괜찮은 퀄리티로 완수해낼 수 있는 능력은 몇 번 선보였다고 생각하지만, 종합적으로 회사 하나의 기술력을 책임질 수 있는 기회는 갖지 못했다. 그런 면에서 티몬은 이콜레모에게 정말 대박 기회였다. 이콜레모와 함께하면 적어도 기술력 걱정은 할 필요 없다는 것을 보여주고 싶었다.

물론 성과는 많이 있었다. 파트타임으로 들어갈 때도 다운되던 서버의 문제를 현장에서 바로 짚어내서 해결한 것만도 두 번. 성능 문제에 많은 시간을 쏟진 못했지만 그래도 잠은 잘 수 있을 만큼 되었다. 모니터링도 아직 제대로 하고 있진 않지만 초보적인 수준까지는 준비가 되었고, 시스템 구성도 꽤 안정화되었다. 매일매일 숨쉴 틈도 없이 밀어닥치던 문제 발생도 대폭 줄었다.

하지만 성과를 이루는 속도는 만족스럽지 않았다. 사실 시스템 구성은 1달 안에 정리했어야 하는 문제였는데 아직도 구멍이 많이 있고, 아직까지 성능 문제가 100% 해결되지 않았다는 것도 참 쪽팔리는 일이다. 아직 남아 있는 무수한 결함도, 데이터 무결성도. 그래서 자존심에 상처를 너무 많이 입었다. 스프링노트 때 mantis에 넘쳐나는 오류들을 보면서 상처 입었던 것과는 비교도 안될 만큼. 물론 변명 거리는 많이 있지만 이콜레모의 능력을 광고하고 싶은 건데 변명 거리를 늘어놓을 수는 없는 일 아닌가.

사실 예전에는 오류나고 느리고 완성도 낮은 웹사이트들을 보면 이해를 못했는데, 이제 그 개발자들도 다 저마다의 사정이 있었겠구나 하는 생각이 든다.

뭐, 그래도 아직 죽어가던 티몬 사이트 살려놨다 정도는 이야기할 수 있을 듯.

두번째는 드림팀 구성. 이건 지난 번에 이야기했으니 패스.

세번째는 내부 시스템 개선. 티몬의 각 부서가 일하는 걸 보면 너무 힘들게 일하고 있다. 어드민 시스템도 개판이었고, 부서간 지식 관리, 이슈 관리도 안되고, 기계가 할 일을 사람이 하는 일도 부지기수다. 우리가 조금만 시간을 투자하면 대폭 개선해줄 수 있는 일들이 너무나 많았다. 다 개선해주고 싶었다. 그래서, 갈아엎는 것도 어드민 시스템부터 하려고 했고, 사용성도 개선하려고 했는데, 실질적으로 아직 사용성을 개선했다고 하기는 어렵다. 그래도 잘한 일 몇 개를 꼽자면, 공용 계정 쓰느라 사람 나갈 때마다 비번 바꾸는 짓거리는 안해도 되게 구글 앱스 계정이랑 연동시켜놓은 것, 멀티 파일 업로드 가능하게 한 것, 환불 시스템 만든 것 정도?

딜 관리하는 거나 게시판 관리하는 건 훨씬 편하게 만들어줄 수 있을 것 같은데, 아직 우선순위에 밀려서 못하고 있어서 아쉽다. 그리고 인증 뿐 아니라 권한 관리 기능도 넣고 싶고. 사실 권한 관리는 자칫 사람들이 원하는대로 다 들어주다보면 관리하기도, 사용하기도 어려운 시스템이 나오기 쉬워서 고민 많이 하면서 만들어야되는 부분이라 직접 하고 싶었는데 결국 못하고 말았다.

CTI 도입이나 세일즈포스 도입도 사실 마음 같아서는 다 내가 개발하고 싶었다. 걔네들이 하는 것보다는 훨씬 빨리, 그리고 잘 만들 자신 있었다. 하지만 거기까지 도저히 손이 닿지 않아 어쩔 수 없이 외주 업체 쓰도록 내버려둘 수 밖에 없었다.

위키와 이슈 트래커도 전사적으로 도입하고 싶었다. 이슈 트래커는 사실 부작용이 많아서 좀 조심스럽게 접근하려고 하다가 너무 늦어져버렸는데, 위키는 조금 더 빨리 전사적으로 도입해도 좋지 않았을까 싶다. 하지만 또 그러려고 계정 관리 잘 되고, 일반인(?)도 쓸 수 있는 위키를 찾으려고 하니 그런 위키가 잘 보이지 않았다. 구글 앱스에 들어 있는 아틀라시안을 쓰는 게 답일까? 아니면 그냥 zoho 쓰고 있는 거에 위키도 같이 쓸까 싶기도 하고. 아뭏든 이것도 그날은 오지 않을 듯.

네번째는 Django의 국내 레퍼런스. 갈아엎기가 잘 끝나면 국내 최초로 mass service에 Django 적용 사례를 만들 수 있었다. 뭐 내가 딱히 Django를 좋아하는 건 아니고 별달리 대안이 없어서 쓰고 있긴 하지만 미투데이에 이어 트위터마저 Rails를 버리고 있는 상황에서 생산성 높은 프레임워크로 성능까지 잡을 수 있다는 것을 보여주고 싶었다. 적어도 웹 프레임워크 분야에서는 자바든 PHP든 퇴장해도 된다고.

하지만 사실 Django든 Rails든 윈도우에서 개발하기 골 때린다는 점은 충분히 경험하는 중이다. 이 부분은 아예 cygwin으로 가든 mingw로 가든 어쩌든 해결책이 필요한 듯.

다섯번째는 세련된 UX 구현. 사실 지금 티몬 웹사이트는 UX 문제가 너무 많다. 로그인 위치며 주문하기에 새 창 뜨는 것, 어색한 게시판 위치, 범람하는 이미지, 멀티 플랫폼 지원 안되는 결제 모듈, 어려운 옵션 선택과 주문 과정, 그루폰 갖다 베꼈던 어이 없는 지역 선택, 어색한 지도 연계, 눈을 어지럽히는 공급자 마인드의 몇몇 배너. 말도 안되는 절약 금액.

여섯번째, 다양한 아이디어 실현해보기. 나도 소셜 커머스와 연계된 아이디어를 여러 가지 갖고 있었고, 티몬은 그 아이디어를 해보기에 더없이 좋은 곳이었다. 하지만 결국 똥치우기만 하다가 아무 것도 못해보았다는 슬픈 이야기 ㅠ.ㅠ

일곱번째, 이상적인 시스템 구축 및 오픈소스화 혹은 사업화. NHN에 있을 때 웹 개발자와 SE 중간 쯤 되는 역할을 하면서 시스템 구성에 대해 고민을 많이 했었다. 처음 하니터 보면서 정말 괜찮은 모니터링 시스템이라고 생각했고, 그래서 그거 개선하는 일 하면서 재미있었다. 오픈소스도 보고 상용도 써보고 했지만 하니터만한 모니터링 시스템은 없었다. 그런데 그게 NHN 시스템에 최적화되어 있다보니 범용적으로 적용할 만한 물건은 아니었기 때문에, 나온 다음에 그런 모니터링 시스템을 조금 범용화시켜보고 싶은 욕심이 있었다. 그래서, 여기서 천천히 만들면서 완성되면 오픈소스화 시키려고 했는데 결국 이 계획도 무산되고 말았다.

그래도, 작은 첫발은 디뎠다. 서버 모니터링하다가 죽거나 느려지면 SMS 쏴주는 건 대강 만들어서 오픈소스로 내놨다. 도큐먼트가 하나도 없고 아직 여러 가지 보완점이 많아서 따로 공개는 안했는데 http://code.google.com/p/mechamon/ 이거다. 이거 만들 때는 그래도 재미있었다. 밤중에 몇 시간 만에 만들어서 실 서버에 붙이기까지 성공하고는 역시 내 개발 실력 아직 죽지 않았어 자뻑도 해보고. 이런 거 만들 땐 Django의 계륵 어드민이 나쁘지 않단 말이야. 하지만 여기서 나가면 이걸 업데이트할 동기가 사라지는 거라서 업데이트는 오랫동안 없을 것 같다.

이거 하면서 Mercurial도 써봤는데, 역시 로컬 히스토리가 있는 이클립스 사용자들에게 DVCS는 그냥 순수한 시간 낭비인 것 같다. vi로 개발할 때나 필요한 것 같은.

test 프레임워크에도 좀 기여를 하고 싶었다. 특히 몇 년간 계속 은혜를 입어온 selenium에 뭔가 보답하고 싶었다. selenium IDE의 생산성과 selenium 2.0의 유연함을 결합할 수 있는 방법을 내놓고 싶었는데 아직 답을 찾지 못했다.

Django 쪽도 이것저것 기여하고 싶은 부분이 많다. 사실 Django는 Rails에 비해 덜 완성되어 있다. Rails처럼 커뮤니티의 힘이 강력하지 않고 다들 따로 논다. 파이썬으로 만들면 금방 만드는데 뭐하러 찾아서 다운 받냐 같은 느낌이랄까. 그래서, Rails로 생산성을 잘 내려면 커뮤니티의 흐름을 잘 따라가야 한다면 Django로 생산성을 내려면 개개인이 축적해놓은 라이브러리가 많아야 한다. 개인 라이브러리 쌓아가면서 개발해야 하는 건 터보 파스칼 시대에나 필요한 일인 줄 알았는데 이제 Django로 새 프로젝트 할 때마다 기존 프로젝트에서 내가 만든 코드들을 카피하고 있는 내 모습을 발견한다. 그래서, 이것들을 좀더 일반화시키고 패키징해서 공유하고 싶다. 이건 아마 나가서도 조금씩 해볼 것 같다. 그나저나 setuptools를 밀든 pip를 밀든 교통정리 좀 해달란 말이야! 나도 gem이 부럽다고 ㅠ.ㅠ

여덟번째. 데이터 엔지니어링. 이라고 하기엔 너무 넓고, 하여튼 사람들이 데이터에 기반한 의사결정을 할 수 있게 해주고 싶었다. 사실 티몬은 되게 계산적인 것 같으면서도 정작 데이터가 필요한 의사 결정에서는 경영진의 직관대로 간다. 아마도 제대로 데이터를 뽑아주는 엔지니어를 만난 적이 없었을 테니 그러는 게 이해는 간다. 그래서, 좀 보여주고 싶었다.

구체적으로 하고 싶었던 것 하나는 클릭률 분석. 한게임 때도 했던 건데 화면에서 구성요소 어디를 많이 클릭하는지를 보여주는 것. 로그 분석은 단순히 어느 페이지가 접속이 많고, 어디서 많이 들어오는지를 보여준다면 클릭률 분석은 화면 배치에 도움을 주는 정보다. 그래서 이거 만들어서 붙이고 싶었는데 왠걸, 구글 analytics에서 비슷한 기능을 베타로 붙여버렸다. 하지만 내가 하려던 방식과는 다르고 레퍼러 기준으로 체크하는 방식인 듯해서 데이터의 정확도는 약간 낮을 수도 있는 듯 했는데, 직관적으로 보기는 참 좋은 듯. 덕분에 티몬에서 사용자들이 지역을 순서대로 눌러본다는 사실도 알 수 있었다.

사실 구글 analytics 자료만 가지고도 분석할 내용이 엄청나게 많다. 근데 제대로 분석을 하고 있지 않아서 답답한 점도 많아서 데이터 엔지니어링에 좀 투자를 하고 싶었다.

아홉번째, NPS 측정. 데이터 엔지니어링이랑 같은 맥락인데, 아뭏든 고객 만족을 원한다면 측정해야 한다. 그리고, 티몬은 측정하기 아주 좋은 비즈니스 모델을 갖고 있다. 그래서, NPS 수치를 보면서 조금씩 높여나가는, 그런 일들을 해보고 싶었다.

그냥 생각나는 것만도 이렇게 많은 걸 보면 참 이것저것 하고 싶은 게 많았었나보다. 뭐, 지금은 다 물 건너 갔지만, 그래도 괜찮아, 이콜레모에서 또 기회를 만들 꺼니까. 이제 다른 이의 성공에 업어가지 않겠어.