일기장/2011-04-12


Youngrok Pak at 12 years, 3 months ago.

티몬에서의 생활을 정리해가면서 그동안 내가 티몬에서 개발실 실장 및 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명 채워지면서 그야말로 막강 드림팀 되는 건데. 물론 그렇게 리크루팅이 순조로웠으리라는 보장은 없지만 뭔가 자신이 있었는데, 정말 아쉽다.

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


Comments




Wiki at WikiNamu