티몬 정리 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 수치를 보면서 조금씩 높여나가는, 그런 일들을 해보고 싶었다.

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

티몬에서의 생활을 정리해가면서 그동안 내가 티몬에서 개발실 실장 및 CTO 역할을 하면서 생각했던 것, 의사결정하면서 염두에 두었던 것들을 정리해본다.

오늘의 주제는 팀.

내가 티몬에 들어가서 제일 먼저 해야겠다고 생각한 일은 팀을 구축해야겠다는 것이었다. 당시 레거시를 넘겨받은 종훈씨 혼자서 힘겹게 버텨내고 있던 상황이었다. 레거시에는 갖가지 문제가 무수히 많았고, 비즈니스가 빠른 속도로 성장하면서 그 문제들의 악영향은 눈덩이처럼 불어갔다. 나도 참여는 했지만 아직 안 끝난 letscc로 인해 풀타임 참여는 불가능한 상황이라 문제 하나하나를 잡는 것보다 일단 팀을 구축하는 것이 급선무였다.

팀을 구축하면서 염두에 둔 것 중 가장 첫번째는 채용은 함께 일할 사람을 뽑는 과정이라는 것이다. 회사가, 혹은 내가 일 시킬 사람을 뽑는 것이 아니라 팀원들과 어울려서 함께 일할 사람을 뽑는 것이다. 그래서, 채용 과정은 늘 팀원들과 함께 진행했다. 서류 전형은 팀원 전체가 함께 검토해서 검토자의 과반수 이상이 찬성하면 합격, 면접은 코딩 테스트 통과한 경우 전원이 찬성하면 합격이다.

그 다음으로 염두에 둔 것은, 단점이 없는 사람보다 장점이 확실한 사람, 현재의 팀이 가지지 못한 능력을 가진 사람을 우대한다는 것. 프로페셔날의_조건에도 나오듯, 사람은 오로지 장점을 통해서 성과를 만든다. 그래서, 장점이 없는 사람은 되도록 채용하지 않는다. 단점은 팀이 보완하면 된다. 모난 사람, 사회성 없는 사람 등등도 장점이 뚜렷하면 별로 문제가 되지 않는다. 난 근본적으로 팀웍이 나쁜 팀은 있어도 팀웍을 해치는 팀원은 없다고 생각한다. 그런 사람이 있다면 팀이 그렇게 만든 것 뿐, 그런 사람이 또 자신에 맞는 팀에 가면 활약하게 마련이다. 히키코모리도 환경에 따라 얼마든지 팀웍을 이루며 성과를 낼 수 있다.

그렇지만, 내가 선호하는 타입이 있긴 있다. 그건 이런 사람이다.

• 스스로 생각하고 문제를 해결하려 노력하되, 필요할 때 도움을 요청할 줄 아는 사람
• 비즈니스의 요구사항을 이해하려고 노력하는 사람
• 다른 분야의 동료들과 원활하게 의사소통할 수 있는 사람
• 기술적 깊이를 추구하되, 실용적인 선택을 할 줄 아는 사람
• 요구사항에 휘둘리기보다 문제를 분석하고 근본적인 해결책을 찾으려는 사람

그리고, 아키텍트형, 매니저형은 가급적 배제하고 실무 능력이 뛰어난 사람 중심으로 채용한다. 개발자를 채용하는 것이니만큼 개발을 잘해야 하는 것은 당연한 것이다. 난 개발 못하는 아키텍트는 믿지 않는다. 개발 못하는 매니저도 좋은 매니저가 되기 어렵다고 본다. 내가 선호하는 타입의 매니저는 기술과 비즈니스에 대한 이해를 겸비한 도요타의 heavyweight project manager, 혹은 린의 챔피언 같은 사람이다. 사람만 관리하는 일이 필요하다고 느낀다면, 채용을 잘못한 것이다. 그래서, 매니저 류의 인력은 늘리지 않으려 했고, 실제 코딩 능력을 더 중시했다. 하지만 이 점은 최근에 생각이 좀 바뀌긴 했는데 이건 다음 편에.

코딩 능력을 볼 방법은 실제로 코딩하는 것을 보는 방법 뿐이다. 그래서 문제를 간단하게 만들었다. 당시에는 APM을 썼기 때문에 APM으로 간단한 웹 애플리케이션을 만드는 과제를 내었다. psuedo code가 아니라 실제 동작하는 코드를 작성하는 것이다. 그냥 PHP로 DB 데이터 쌓는 정도만 하려다가, 그러면 너무 변별력이 떨어질 것 같아 Ajax 요소를 하나 추가했다. Ajax 자체가 장애가 되지 않도록 Ajax를 모르는 경우는 jQuery나 Prototype을 쓰면 된다고 알려주었고, 검색, 라이브러리 활용 등은 물론 자유다. 머리가 좋고 나쁘고를 떠나서 말로만이 아니라 실제로 코딩을 할 수 있는지를 본 것이다.

문제를 만든 당시에는 너무 쉽지 않나 걱정을 많이 했다. 하지만 의외로 정말 강력한 필터링이 되었다. APM을 다년 간 해왔고 Ajax도 해왔다는 사람들도 못 푸는 사람이 부지기수였다. 문제의 크기는 Rails 스크린캐스트 15분 짜리에 나오는 내용의 3분의 1도 안되는데도 그걸 못 푸는 사람이 많았다.

물론, 코딩 테스트라는 걸 거의 접해보지 않은 사람들이 대부분이라 현장에서 당황하기도 했을 것이고, 개발 환경이 익숙하지 않은 경우도 있었을 것이고, 여러 가지 어려운 점이 많았을 것이다. 그래서, 사실 제한 시간은 1시간으로 주었지만 그 이상도 얼마든지 쓸 수 있게 했는데, 중간에 포기하는 사람도 많았다. 간혹 현장 테스트의 부담감을 호소하는 사람들은 집에서 숙제로 해오고, 대신 코딩에 투자한 시간을 기록해서 보내달라고 했는데, 숙제를 해오는 사람도 아주 드물었다. 그래서, 그닥 좋은 문제는 아님에도 불구하고 꽤나 좋은 필터 역할을 해왔다.

하지만, 요즘에는 이 테스트를 아슬아슬하게 통과하면서 면접에서도 깊은 인상을 주지 못하는 사람이 많아져서 좀 골치가 아파졌다. 뭔가 커트라인 근처에 아슬아슬하게 걸쳐 있는 것이다. 그래서, 테스트도 조금 개선하고 면접도 구체화해야겠다는 생각이 든다.

그리고 면접. 면접 볼 때 염두에 둔 것은 크게 두 가지. 하나는 지원자의 능력을 스스로 보여주리라 기대하지 말고 면접관이 철저하게 파헤쳐서 장점을 찾아내야 한다는 것이다. 대부분의 사람은 자신의 능력을 어필하는 기술이 서투르다. 가만 앉아서 어디 한 번 자기 능력을 보여주시오~ 하면 제대로 그 능력을 알아볼 수 없다. 면접자의 경력, 성격, 사고 방식 등에 맞게 적절한 질문을 하면서 파고 들어야 한다. 하지만, 나 스스로도 이 점은 많이 아쉬웠다.

또 하나는 면접자의 말이 의견인지 사실인지 구분하고, 의견일 경우 그 의견에 기반한 사실, 혹은 논리가 무엇인지 파악해야 한다는 것. 새로운 것을 배우는 것을 좋아한다고 하면 최근에 새로 배운 것이 무엇인지를 물어본다. 프레임워크가 유익하다고 주장한다면 구체적으로 어떤 점들에서 이득을 주는지를 물어본다. 좋은 코드, 나쁜 코드에 대해서 이야기한다면 구체적으로 어떤 코드가 좋고 나쁜지 따져본다. 이렇게 구체적인 경험을 파고 들다보면 장점을 찾아낼 기회가 온다.

이 점에서는 내가 비교적 다양한 경험을 했다는 것은 장점으로 작용한 것 같다. 지원자가 이야기하는 기술적 경험을 더 깊이 파고들어서 물어볼 수 있다면 그 경험이 얼마나 깊이 있는 경험이었는지 가려내는데 도움이 된다.

그리고, 이콜레모에서 쓰던 것인데, 면접은 회사가 사람을 보는 과정이기도 하지만 사람이 회사를 보는 과정이기도 하다는 것이다. 그래서, 최대한 상호 면접이 될 수 있도록 많은 기회를 주려고 애썼다. 합격은 하고 연봉 협상하고 입사 딱 했는데 첫날 맞이한 현실이 기대와 다르다면 얼마나 짜증이 나겠는가. 미리 회사에 대해 충분히 알고 올 수 있도록 해야 한다. 물론 그렇게 기회를 줄 때 어떤 질문을 던지느냐도 평가 요소가 된다. 자신이 능력 발휘를 할 수 있는 조건을 잘 알고 있느냐 아니냐도 중요하니까.

아쉬운 것도 많은데, 매일매일의 업무에 시달리다가 갑자기 면접을 맞이하는 경우가 많아서 차분하게 생각하고 정리할 시간이 부족한 상태인 경우가 많았다는 것이다. 괜찮은 개발자 두어 명 정도는 놓쳤을 수도 있겠다는 생각이 든다. 역시 마찬가지 이유로 지원자에 대한 예의를 다하지 않은 경우가 많았던 것, 열악한 환경에서 면접과 테스트를 보게 한 것은 정말로 미안한 일이다. 지금은 그나마 좀 개선되었는데, 초기에는 정말 실례를 많이 범한 것 같다.

이렇게 구성된 팀이 굴러가면서 내가 신경썼던 것은 실무자 중심의 의사결정이다. 어떤 일을 할지 말지, 하면 누가 할지, 어떤 방법으로 할지 등등 최대한 실무자의 의견을 중시하려고 애썼다. 결국 일을 하는 사람은 실무자이므로 실무자의 판단이 가장 중요하다. 어차피 놀려고 회사 나오는 사람은 없고, 환경만 갖추어지면 사람들은 알아서 일한다. 내가 시시콜콜 지시할 필요도 없다. 그래서, 내가 하는 일은 다른 부서 및 경영진의 요구, 비즈니스 상황 등을 팀에 전달하되, 그 일을 어떻게 할지에 대해서는 외부의 압박에 휘둘리지 않고 스스로 판단하고 행동하기를 주문했다.

기술적으로도 되도록 많은 자율을 부여하려 했다. 물론 내가 보기에 잘못되었다고 생각하는 일들도 많이 일어나지만 그런 일을 내가 지시해서 고치는 것은 크게 의미가 없다고 생각하기 때문에 논쟁으로 이겨서 바꾸기보다 조언만 하고 최종 결정은 실무자가 하도록 했다. 그리고, 내가 옳다고 생각하는 방식은 코드를 통해서 보여주려 애썼고. 그래서 실질적으로 팀에서 내가 뭔가 강제한 것은 딱 두 가지 뿐이다. 서버에서 직접 수정 & 테스트 못하게 하고 로컬에서 테스트한 후 Subversion에 커밋하고 테스트 서버 거친 후 deploy하게 한 것. 그리고 deploy 하기 전에 항상 test 돌리게 한 것. 이슈 트래커도 썼지만 여러 가지 이유로 강제하지 않았고, 리팩토링, 개발 패턴, HTML & CSS의 패턴, 이미지 파일 naming convention 등도 선례를 보이려 했을 뿐 강제하지 않았다. 많은 룰의 강제로 인해 얻는 이득보다 개발자 개개인의 자율로 얻는 이득이 훨씬 크다고 보기 때문이다. 물론, 그렇게 해도 팀원들이 서로의 코드를 존중해서 맞춰가리라는 믿음과, 자율로 인해 높은 생산성을 낼 것이라는 믿음이 있었기 때문이다.

개개인과 면담을 하면서 피드백을 주고 받으려는 계획도 몇 번 했었는데 재수가 없었는지, 의욕에 넘쳐서 그런 마음을 먹고 출근할 때마다 뭔가 기분 상하는 일이 터졌다. 그래서 미루고 미뤄 결국 개인 면담은 한 번도 하지 못했다. 아쉬운 부분이다.

팀 전체에 영향을 미치는 의사 결정을 할 때도 최대한 내 의견은 마지막에 이야기했다. 우리 팀원들이 모두 실장이라는 권위에 눌리는 사람들은 아니긴 하나, 그래도 실장이 먼저 의견을 이야기하면 거기에 휘둘릴 수 있기 때문이다. 숫자를 이야기하거나 투표를 할 때도 각자 마음 속으로 정하기를 기다린 후 한 명씩 꺼내놓게 했다. 누가 먼저 이야기하면 거기에 영향을 받기 때문이다.

물론, 내가 옳다고 생각하는 방향이 있으면 팀원들을 설득하려고 애를 쓴다. 하지만 설득에 실패하면 결국 판단은 실무자의 몫이다.

또, 이런 식으로 결정을 실무자에게 미룰 수 있으려면 실무자에게 책임을 지워서는 안된다. 책임은 권한을 가진 사람이 지는 것이 아니라 권한을 준 사람이 지는 것이다. 팀원이 제대로 해낼 수 있는 일을 맡기고, 해낼 수 있도록 제반 여건을 조성해주어야 한다. 그러지 못하면서 결정만 미룬다면 직무유기다.

그러나, 실제로 내가 책임을 져주진 못했다. 여력이 없던 탓도 있었고, 팀원들 스스로가 책임감이 강해서 스스로 어떻게든 책임지려 한 것도 있었다. 뭐, 솔직히 여기도 나 자신에 대한 과대평가로 인한 실수들이 많았다는 점 인정. 물론, 내가 그렇게 못한 책임은 대표가 져야지. ㅎㅎ 어쨋든 위에서 일 저지르고 실무자들이 책임지는 구조가 안되게 하려고 참 노력은 많이 했는데 잘 안된 것 같아 안타깝다.

다른 부서와의 커뮤니케이션에서는 두 가지 어쩌면 모순적인 것을 조화시키려고 애를 썼다. 하나는 실무자끼리 직접 소통하는 것. 괜히 팀장 실장 거치면 말만 와전되고 비효율적이 되기 쉽다. 굳이 날 통과해야 할 이유는 많지 않았기에 되도록 실무자들끼리 채널을 뚫도록 했다. 또 하나는 개발실 전체가 하나의 묶음처럼 커뮤니케이션할 것. 개발에 관련된 이슈면 개발실 누구에게 전달하든 되도록 하려고 했다. truck number도 낮추고 다른 부서에서 개발실 누구에게 말해야될지 몰라서 고민하지 말고 개발실 아무에게나 이야기해도 되도록 만들기 위해서다. 하지만 현실적으로 개발실 멤버들이 인터럽트에 시달리다보니 다른 부서와의 커뮤니케이션에서 친절해지기 어려워서 후자는 잘 달성되지 않았다. 그래도 한 가지 잘된 부분은 다른 부서에서 메일 보낼 때 늘 개발실 그룹메일주소로 보내도록 유도한 것이다. 다른 부서에도 개발실 메일주소가 잘 각인되었고 이슈 공유 효과가 꽤 좋았던 것 같다.

근무시간의 경우도 이콜레모의 자율 출퇴근제를 도입하려 했으나 잘 되지 않았다. 현실적으로 일이 산처럼 쌓여 있는 상황에서 재택 근무를 하거나 자기 편한 시간에 출퇴근한다는 게 큰 의미가 없었던 것 같다. 결국 이 제도의 혜택을 본 사람은 나 혼자다-_-

마지막까지 제대로 성공하지 못했던 것은 인터럽트를 통제하고 집중할 수 있는 환경을 만들어주는 것. 개발자는 오로지 집중할 때만 성과를 낸다. 방해를 한 번 받으면 다시 집중하기까지 최소 20분이 걸린다. 하루는 480분이므로 24번 방해를 받는 개발자의 하루 생산량은 0이다. 하지만 초기에는 24번이 아니라 50번쯤 인터럽트를 받았던 것 같다. 인터럽트를 통제하기 위한 방법을 여러 가지 하긴 했는데, 뭔가 강제하기 싫어하는 성격상 과감한 방법을 시행하진 못했다. 지금 다시 티몬에 애정을 갖고 한다면 좀더 파격적인 방법을 쓸 것 같다. 이를테면 팀원들 전부 데리고 사무실 따로 하나 내달라고 해서 거기서 2주간 일하기 같은 방법. 전화도 메신저도 차단하고.

이슈 트래커를 제대로 활용하지 못한 것도 아쉬움으로 남는다. 초기부터 redmine을 도입하려고 했으나 다른 부서가 redmine을 써야 우리의 인터럽트가 줄어드는 건데 그게 안되니까 별 소용이 없었다. 그래서 지금은 구글 앱스에 연동되는 zoho를 써보기로 한 상태인데, 이게 그나마 나은 것 같다. 여기서 좀더 아쉬운 점 하나는 zoho를 사실 세 달 전부터 도입할 수 있었는데 검토를 차일피일 미루다가 이제야 도입했다는 것이다. 세 달 전부터 적극적으로 도입하고 다른 팀에도 쓰게 했으면 훨씬 상황이 좋았을 것 같다.

그런데, 사실 팀에서 가장 아쉬운 것은 드림팀을 구축할 기회를 내버렸다는 것이다. SE & DBA 역할을 제대로 해줄 수 있는 다즐링 들어오고 개발 생산성 팍팍 내줄 수 있는 건전한 아저씨와 코딩의 신 데려오고 소셜커머스 아이디어 하고 싶어하는 인동 살살 꼬셔서 프론트엔드 엔지니어로 데려오고, 유저 분석가로 Thoughtworks 다니던 분 이콜레모로 합류하고, 데이터 엔지니어도 채용하고 그러면 12명 채워지면서 그야말로 막강 드림팀 되는 건데. 물론 그렇게 리크루팅이 순조로웠으리라는 보장은 없지만 뭔가 자신이 있었는데, 정말 아쉽다.

뭐, 괜찮아. 이콜레모에는 또 기회가 있을 테니까.

티몬에서 일한지 벌써 5개월이 되어 가는데, 그 동안 이뤄놓은 게 별로 없다. 내 10년 경력을 통털어 최악의 실패를 경험하는 중이다. 그만둘려고 하다가 일단 2주 휴가 다녀와보기로 한 상태. 실질적으로 쉬진 못했지만 그동안 갖지 못했던 여유가 생겨서 이것저것 생각을 많이 해보면서 그동안의 회고를 해보았다.

처음 접했던 티몬의 상태는 이야기로 듣던 것보다는 나쁘지 않았다. 소스 코드의 수준은 심각했지만 내가 본 것 중 최악은 아니었기 때문이다.(최악은 물론 NHN에서 경험한 대마왕이고 이 정도 상황은 앞으로 영영 접할 기회가 없을 것이다.) 소스 코드만 보면 C는 충분히 줄 수 있었다. 개판인 점이 많았지만, 그래도 군데군데 고민의 흔적들이 보이고, 복잡도가 무한대로 증가하는 그런 코드도 아니었다. 충분히 리팩토링하면서 개선해나갈 수 있는 수준으로 보였다. 그래서, 일단은 점진적인 개선이라는 방법이 가능하다고 판단했다.

이것이 나의 첫번째 멍청한 판단이었다. 웹이라는 분야는 개발이 쉽기 때문에 일견 쉬운 분야로 보이고, 개발자들 사이에서도 RoR 등이 퍼지면서 쉬운 분야로 인식되곤 한다. 하지만 웹에는 운영이라는 커다란 부분이 있다. 그래서, prototype으로 돌아가는 사이트를 만드는 것과, 실제 돌아가는 사이트를 만드는 것 사이에는 넘사벽이 있다. 이 넘사벽을 처음부터 내가 망각하고, 소스 코드만 보고 판단한 것이다. 솔직히 이 판단은 지금도 좀 쪽팔린다. 내가 이렇게 단순하게 사고했다는 걸 믿고 싶지 않다 ㅠ.ㅠ

아뭏든, 그래서 실제로 업무에 들어가면서부터 나날이 더 많은 문제점들이 드러나기 시작했는데, 이 때도 내가 판단을 수정하는 반응 속도가 느렸다. 한 번 갈아엎자는 판단을 내렸다가 철회한 것도 매일매일 쏟아지는 일들을 처리하는 것이 개선 작업보다 더 중요하다고 생각했었기 때문이다. 지금 생각해보면 아산스파비스 사태 때 바로 꺠달았어야 했다. 그랬다면 갈아엎자는 결정에 방해가 들어와도 굳건하게 추진했을 것이고, 개발 속도는 빠르지 않았겠지만 지금 쯤이면 많은 진도가 나가 있었을 것이다.

상황 판단에 실수를 했던 이유를 조금 더 파고 들면, 과거의 성공 경험이 내 눈을 가린 것이다. 내가 간혹, 작은 성공을 이룬 사람들은 같은 방법으로 성공을 재생산하려고 한다면서 비판하곤 했었는데, 이번엔 내가 그 꼴이었다. 난 NHN에서 새로운 프레임웍 도입 및 각종 시스템 개선 작업을 기존 레거시와 조화시키면서 해낸 경험이 있었다. 그 때는 내가 2년 차였을 떄고 지금은 그 때보다 훨씬 많은 경험이 쌓이고 다양한 시스템을 다루어본 상태 아닌가. 당연히 할 수 있다고 자만했다.

하지만, 상황이 달랐다. 그 때는 NHN의 막강한 SE들과 DBA들이 떠받치고 있었고, 운영도 안정되어 있었고, 모든 사람들이 엔지니어링의 중요성을 인지하고 있었다. 개발자 수도 많아서 내가 개선 작업을 하는 동안 기존 시스템을 유지할 인력이 있었다. 하지만, 여긴 엔지니어링이 중요하다는 것을 인지하는 사람이 아무도 없었고(경영진 포함, 다들 말로만 중요하다고 하는 상황) 인프라도 없었고 인력도 부족했다. 하지만 스마트패스원 프로젝트에서 말도 안되는 스케쥴을 소화해낸 자신감이 어느새 자만심으로 변해 있었던 나에겐 그런 것들이 보이지 않았다. 스마트패스원 프로젝트이 10할의 승리였던 셈이다. 이번 일이 나에게 다케다의 도이시성 전투처럼 새겨지길 바랄 뿐이다.

그래도, 이후에는 좋은 스텝을 많이 밟았다. 벤더 페이지를 먼저 공략해서 개선하면서 패턴을 잡아냈고, 그 패턴을 메인 사이트에 적용하면서 많은 부분 개선이 되었다. 그러면서 시스템의 이해도가 높아져서 드디어 갈아엎기를 발동할 수 있게 되었다. 성능도 많이 개선했고.

하지만, 자잘한 실수는 계속 저질렀다. 양지리조트 사태, 파파이스 사태, 티몬스퀘어, 신한카드 모두 나의 멍청한 판단 때문에 일어난 일들이다. 양지리조트는 그냥 하지 말았어야 하는 일인데, 중요도 판단을 냉정하게 하지 못했다. 무엇보다, 그 때 석천씨, 종훈씨와 함께 셋이서 회고를 했는데, 그 대책을 제대로 실천하지 못했던 것이 가장 큰 실수였다. 그 대책 중 가장 중요한 것은 외부의 요구사항을 들어줄 때 그 리스크에 대해 요청자가 체감할 수 있게 해주자는 것인데, 실질적으로 거의 성공하지 못했다. 이 부분은 조금 더 구체적인 대책을 세워야 할 것 같다.

파파이스 사태는 일종의 책임 떠넘기기 심리가 발동했다. 파파이스 딜 2주 전 회의 때 이대로 진행하면 서버는 죽을 꺼고, CS 폭탄 터질 꺼라고 경고했고, 광고 다 중지시키자는 이야기까지 했었다. 그러고 나서 난 경고했으니까 이제 내 책임 아냐라는 심리로 있었던 것 같다. 하지만 그게 내 잘못이든 아니든 책임져야 하는 건 결국 개발실과 CS였다. 이것 역시 진작부터 깨달았어야 하는 일이다.

책임 떠넘기기 심리가 발동한 또 다른 이유는 이미 내 감정 상태가 좋지 않았기 때문이다. 사실 난 티몬의 삼성스런 비즈니스 마인드가 싫다. 삼성의 전략을 칭찬하는 발언도 많이 했지만, 내가 그런 회사에서 일하고 싶지는 않다. 그러다보니 될 대로 되라는 식의 상태에 있었던 것 같다. 이 문제는 사실 해결 불가능한 문제 같아보이지만, 일단 사람 하나 믿고 한 달 정도는 더 판단을 유보하기로 했다.

티몬스퀘어와 신한카드에서 멍청한 판단을 한 것도 감정적인 이유가 작용했는데, 이건 좀 다른 이유다. 사실 2월부터는 계속 품질 개선의 시급성을 느끼고 있었기 때문에 품질 개선에 역행하는 요청들은 단호하게 막자고 생각하고 있었다. 하지만, 계속 사람들에게 No라고 말하다보니 나도 스트레스를 받았고 뭔가 좀 해줘야 할 것 같은 압박감을 느꼈다. 거기다가 외부 업체가 엮여있다보니 더 거절하기 어려웠다. 그래서, 신한카드는 거절할 수 있는 방법이라고 생각해서 낸 안인데, 협상력 좋은 사람이 가서 관철시켜버리는 바람에 결국 하게 되버렸고, 티몬스퀘어는 물리적으로 도저히 할 수 없는 상황인데, 단지 며칠 미루는 걸로 할 수 있다고 생각했다.

여기서 내가 범했던 오류는, 이게 그냥 내가 단호하게 마음을 먹기만 하면 되는 일이라고 생각한 것이다. 하지만 다른 사람들이 절실하게 이야기하는 것을 외면하는 것도 그 자체로 커다란 스트레스인데, 그걸 내가 그냥 이겨낼 수 있다고 생각한 것은 착각이었다. 좀더 체계적으로 대응할 방법을 마련해야 한다. 어쨋든 그 사람들도 티몬 망하라고 그러는 것은 아닐 터. 부분 최적화에 몰두해 있는 사람들이 전체 그림을 볼 수 있게 해야 한다.

그리고, 이젠 정말 회고를 해야겠다. 스마트패스원 때도 미친 듯이 바빴고, 40일 연속 야근도 하고 그러느라 팀 회고는 못했지만, 적어도 내 개인 회고는 꾸준히 했고, 그 덕에 결정적인 개선들을 몇 번 이뤄낼 수 있었다. 하지만, 티몬에서는 어쩐 일인지 그 회고가 잘 안되었다. 일단 이게 왜 안되었는지도 좀 분석이 들어가야 할 것 같고, 휴가 끝내고 복귀하면 주간 회고부터 정착시켜야겠다.

어쨋든, 좋은 경험이긴 한 것 같지만, 사실 이런 종류의 좋은 경험은 그닥 더 하고 싶지 않다.

간만에 정치 이야기. 왜 한국은 인터넷 세상이 되서 한나라당과 조선일보의 악행이 만천하에 드러난 오늘날까지도 굳건한 권력을 유지하고 있는가? 예전에는 단지 정보의 문제라고 생각했다. 정보가 흐르지 않던 시절에는 언론에 의지할 수 밖에 없었고, 그 언론과 정권이 결탁하면 국민들을 천년 만년 속일 수가 있었지만, 정보가 흐르고 흘러, 한나라당이 내 이익에 눈꼽만큼도 도움이 안된다는 것을 깨닫는다면 바로 떠날 것이라고, 그렇게 생각했다. 모든 국민이 자신의 이익을 진실로 대변하는 정당을 뽑는다면, 부자들은 그냥 한나라당 찍고, 나같은 서민 사업가는 대충 아무렇게나 찍고, 서민들은 민노당이나 진보신당 찍으면 되겠지.

하지만, 이건 착각이었다. 물론, 정보의 흐름이 정치 지형을 어느 정도 바꾸기는 했고, 노무현을 만든 것도 3분의 1쯤은 인터넷이다. 하지만, 인터넷이 세상을 바꾸고 사회를 바꾸었지만 한나라당 조선일보 연합은 끝끝내 뒤엎지 못했다. 그 이유는 무엇일까.

하나는 한나라당이 정말 강력한 이념조직이라는 것이다. 여기서의 이념조직은 BUILT_to_LAST에 나오는 그 이념조직이다. 한나라당을 찬찬히 뜯어보면 BUILT_to_LAST의 비전 기업의 조건을 거의 다 갖추고 있다. 기득권의 유지라는 핵심 이념을 향해 정말 강하게 align되어 있고, 접대 문화, 성추행, 상명하복 등의 차별화된 문화가 있다. 대권과 총선이라는 BHAG가 알아서 4~5년마다 나타나며, 시행착오를 두려워하지 않고 온갖 개소리를 늘어놓은 다음, 국민들에게 까이는 건 덮고 먹히는 것만 밀어준다.

이에 비해 민주당은 이념이 뭔지 도통 알수가 없고, 무슨 문화가 있는지도 알 수 없다. 국민참여당은 이념은 있지만 조직 전체에 align되어 있는지는 의심스러우며, BHAG를 제대로 추구하고 있지도 않고, 무슨 시도를 하고 있는지 소식도 없다. 진보정당들은 이념 때문에 싸우다가 분당한 걸 보면 하나의 이념으로 align되어 있지 않은 것은 확실하다. 다만, 이념이 달라서 분당한 만큼 앞으로는 자신들의 이념을 깊이 있게 추구할 것이라는 기대는 할 수 있겠다.

이처럼, 정당간 실력차가 큰 것이 중요한 요인이다.

또 하나는, 정당이 국민들의 이익이 아니라, 국민들의 생각을 대변해야 한다는 것을 한나라당이 정확하게 파악하고 있다는 것이다. 한나라당이 대변하고 있는 대한민국 국민들의 생각은 뭘까? 자식들에게 안정적인 직장 구하라는 말 밖에 할 줄 모르는 부모, 부동산으로 어떻게 돈 좀 벌어봤으면 하고 바라는 수많은 서민들, 어떻게 공돈 좀 먹어볼까 달려드는 날파리 기업인들, 가난한 사람 힘 없는 사람 등쳐먹는 사기꾼, 돈 잘 버는 남자 만나서 팔자고치려는 여자들, 돈 있는 척 여자 꼬시려는 남자들. 이런 사람들의 머리 속에 들어 있는 생각이다. 대한민국의 평균적인 사람들의 뇌 구조를 그리면 아마도 3분의 2는 돈일 것이다. 이걸 한 마디로 요약하는 단어가 있다. 천민 자본주의.

모든 것을 돈으로 재단하려 하고, 돈이 목표고 추구해야할 가치의 전부인 사람들. 한나라당은 이 천민 자본주의를 완벽하게 대변하고 있다. 그래서, 국민들은 한나라당이 자신들의 이익을 대변해주고 있지 않음에도, 아니 심지어 자신들의 이익을 뺏어가서 기득권층의 배를 불려주고 있음에도 불구하고, 자신들을 대변해주고 있다고 착각하게 된다.

이 착각은 생각보다 정말 깨기 힘든 것이다. 사람들한테 너 착각하고 있어! 한다고 깨질 것도 아니고, 백만 민란 한다고 깰 수 있는 것도 아니다. 돈보다 중요한 가치들이 이 세상에 많다는 것을 사람들이 알아갈 때 조금씩 깨지는 것이다. 꼭 배가 불러야 다른 가치들을 돌아볼 수 있는 것은 아니다. 대한민국은 배고팠던 수십년 전보다도 오히려 더 돈을 밝히는 사회가 되었다. 잘 살아야 그런 여유가 생긴다는 말은 역으로 현재 상황을 계속 악화시킬 뿐이다. 배고플 때 가질 수 있는 여유, 그것이 세상을 바꿀 수 있다.

최근 개발자를 채용하기 위해 면접을 많이 봤다. 사실 지금과 같은 상황에서의 면접은 거의 처음이다. 이전까지 다른 회사 다닐 때 면접관으로 들어간 것은 결정권자로서가 아니라 그냥 면접관 중 한 명으로 들어갔던 것이고, 이콜레모에서의 면접은 이콜레모의 이념에 공감하고 사업의 무게를 함께 짊어질 수 있는지를 보는 것이었다. 프리랜서를 채용할 때는 그냥 즉시전력감이 될 수 있는지만 보면 되는 것이어서 또 쉬웠고. SW 마에스트로에서의 면접은 좀 힘들었지만 학생들 수준 차이가 현격해서 또 쉬운 점이 있었다. 하지만 이번에는 티켓몬스터의 비전에도 공감하면서, 현재의 실력도 어느 정도 있고, 발전 가능성도 높은 사람을 채용해야 하는 상황이라 가장 어렵다.

그래도 지금은 어느 정도 원칙을 정해가는 중이다. 제 1원칙, 프로그래머는 프로그래밍을 잘해야 한다. 이상하게도 면접 보는 사람 중에 프로그래밍 능력에 대한 이야기가 나오면 자신이 프로그래밍은 잘 못하지만 여러 가지 다른 능력이 좋기 때문에 팀에 도움이 될 꺼라고 하는 사람이 많았다. 특히 나이 많은 사람일수록 그런 빈도가 높았다. 마치 나는 요리사인데 요리는 못하지만 다른 능력이 있어서 보탬이 될 수 있다고 말하는 격이다. 뭐, 정말 다른 능력이 좋아서 요리는 못하지만 음식점 장사가 잘 되게 만들 수 있겠지. 하지만, 그러면 요리사 말고 다른 포지션으로 지원해야 하지 않겠는가.

그래서, 프로그래밍 실력을 보기 위해 두 가지를 한다. 하나는 코딩 테스트. 아주 간단한 테스트라 변별력이 있을까 하는 생각을 했었는데, 의외로 아주 높은 변별력이 있었다. 또 하나는 경력에 대한 기술적인 질문을 하는 것. 경험한 기술의 특성, 기술들간 비교 등등 최대한 깊이 있고 구체적인 질문들을 던진다. 이런 질문을 던져보면 자신이 경험한 기술을 얼마나 깊이 이해하고 있는지를 알 수 있다.

이런 질문에 제대로 대답을 못하는 사람은 기술을 깊이 파보지 않는 사람이다. 특히 다양한 기술을 배우는데 거리낌이 없다고 이야기하는 사람 중에 그런 사람이 많다. ASP를 하다가 Java를 하고 PHP를 하면 사실 그다지 깊이 이해하지 않아도 어떻게든 구현해내는 것은 가능하다. 그래서, 많은 사람들이 이것을 "학습했다"라고 착각한다. 하지만 이런 수준에 머무른다면 어찌 생산성 높은 프로그래머가 되겠는가. ASP와 ASP.NET의 어떤 차이가 생산성에 어떻게 영향을 주는지도 설명하지 못한다면 뭐하러 ASP.NET으로 옮겨타는가. 다양한 것을 해본다고해서 다 얕게 알아야 하는 것은 아니지 않은가. 나는 깊이와 넓이를 다 요구하지만, 넓이만 있는 경우보다는 깊이만 있는 쪽을 훨씬 선호한다. 그냥 할 줄만 안다면 프로페셔널이라고 부를 수 없다. Ajax를 하면 Ajax 전문가가 되고, Django를 하면 Django 전문가가 되고, 아이폰을 하면 아이폰 전문가가 되어야 한다. 이게 뭐 천년 만년 배워야 하는 기술도 아니지 않은가.

객체지향의 경우도 대부분의 지원자가 객체지향에 대해 이야기했는데, 객체지향이 왜 좋냐고 물어보면 제대로 대답하는 사람이 없었다. 심지어, 틀린 대답을 하는 사람조차 많지 않았고, 대부분 잘 모르겠다는 이야기를 했다. 잘 모르는데 왜 좋다고 생각할까?

또 하나 신기한 것은 애자일이다. 이번에 면접본 사람 전원이 애자일에 대한 이야기를 했다는 신기한 사실. 이력서에 간단하게 적혀 있는 경우도 있었고, 면접 때 말하는 경우도 있었는데, 모두 애자일을 이야기하는 것이 도움이 된다고 생각하는 것 같았다. 애자일이 buzzword로서는 참 한국에서도 많이 퍼졌구나 싶은 생각이 들기는 하지만, 깊이 있는 이야기를 해보면 역시 아직은 실망스럽다. 심지어 워터폴의 특성들을 꼽으면서 이래서 애자일이 좋다고 말하는 사람도 있고.

아뭏든 그래도 쉽사리 땡이라고 말하지는 못하고 있다. 뭔가 요즘 용기가 좀 줄었다. 예전엔 내가 느낀 생각들을 그대로 말하고 결정했는데, 요즘은 내가 생각하지 못한 게 뭔가 있지 않을까. 저 사람의 숨겨진 능력을 내가 찾아내지 못한 건 아닐까 하는 생각들이 자꾸 결정을 방해한다. 채용에 대한 전권을 위임받았다는 것도 오히려 결정을 망설이게 한다. 전권을 위임받았다는 것은 결국 그 결과에도 책임져야 한다는 뜻일 테니까.

티켓몬스터 일이 생각보다 어렵다는 생각이 요즘 많이 든다. 처음에는 그저 좋은 비즈니스 모델을 찾아냈지만 기술력이 부족한 회사이기 때문에 내가 기술력을 잘 채워주면 앞으로 쭉쭉 나갈 수 있을 것이라는 생각을 했었는데, 지금은 꼭 그런 것 같지는 않다. 뭔가 그 이상의 역량을 발휘해야 할 것 같은 느낌이랄까. 나도 AC2를 한 번 받아볼까 하는 생각이 들기도...