어린 아이가 어두운 골목에서 동전을 잃어버렸다. 근데 이 아이는 골목에서 나와서 밝은 큰 길에서 동전을 찾고 있다.

• 지나가던 이 얘야, 뭘 잃어버렸니?

• 아이 동전이요.

• 지나가던 이 어디서 잃어버렸는데?

• 아이 저기 어두운 골목에서요.

• 지나가던 이 -_-;;; 근데 왜 여기서 찾고 있니?

• 아이 거긴 잘 안 보이잖아요.

유명한 이야기이지만 많은 사람들이 잊고 있는 이야기다. 이 이야기를 통해서 말하고 싶어하는 것은 사람들이 관리해야 하는 것을 관리하지 않고 관리할 수 있는 것을 관리하려 한다는 것이다. 이건 사실 아주 많은 회사에서 나타나는 현상이다. KPI 같은 걸 잡을 때도 정말 측정해야 하는 중요한 지수를 측정하는 것이 아니라 그냥 측정할 수 있는 것 중 아무 거나 찝어서 측정하고는 그걸로 성과를 잰다. 프로젝트 관리도 마찬가지다. 정작 중요한 고객에게 가치를 전하고 있는지는 전혀 측정하지 않고 쉽게 측정할 수 있는 일정이라든지, Man Month따위나 측정한다. 실제 이런 수치와 성공과의 상관 관계는 거의 없는대도 말이다.

---

 

블로그

 

머리에 너무 생각이 많이 차서 CPU 사용율이 100%에 달했다고 느낄 때가 있다. 그러면 버벅거리면서 응답 속도가 느려지고 효율이 떨어진다. 다시 CPU 사용율을 떨어뜨려야 한다. 생각할 꺼리가 쌓여 있을 땐 의식적으로 머리를 비우려고 해도 좀처럼 CPU 사용율이 떨어지지 않는다. 한 태스크를 강제 종료 해도 다른 태스크가 금방 CPU를 차지한다. 이럴 때 좋은 방법은 IO bound job을 실행하는 것이다. IO bound job을 실행하면 IO의 속도가 CPU의 속도보다 훨씬 늦기 때문에 그 속도 차이만큼 CPU가 쉴 수 있다. IO bound job은 대화일 수도 있고 무언가 단순하지만 약간 머리를 써야 하는 일, 혹은 산책도 될 수 있다. 대화도 분명 CPU를 많이 쓰지만 생각의 속도는 말의 속도보다 훨씬 빠르기 때문에 똑같은 태스크라도 대화를 하면 CPU 사용율이 좀 내려 간다. 운동도 확실하게 CPU 사용율을 떨어뜨리는 방법이다. 운동의 종류에 따라 다르지만 운동은 그 자체가 CPU를 어느 정도는 사용하지만 높은 점유율을 필요로 하진 않는다. 인간의 대뇌는 싱글 태스킹 밖에 안되기 때문에(내부적으로 멀티 쓰레드라 하더라도) 운동처럼 IO가 많으면 다른 생각은 하기 어렵다. 그래서 운동 태스크에만 CPU를 쓰게 되고 운동 태스크는 IO bound기 때문에 CPU가 쉬는 것이다. 마찬가지로 설겆이도 이렇게 보면 그렇게 시간 낭비로 느껴지지 않을 것이다. 오히려 마음이 편안해지는 느낌도 받을 수 있다.

산책은 좀 특별하다. 산책할 때는 선택이 가능하다. 산책하면서 다른 생각을 하는 건 그다지 어렵지 않다. 운동의 강도가 높지 않고 워낙 자연스럽게 하는 동작이라서 그런 것 같다. 그래서 딱히 IO bound가 되는 것 같진 않지만 산책이라는 행위 자체가 CPU를 오버클럭하는 효과가 있다. 그래서 throughput은 유지하면서 CPU 사용율을 떨어뜨릴 수 있다.

또, 산책을 할 때는 눈앞의 풍경이 바뀌기 때문에 다른 생각을 몰아 내기가 비교적 쉽다. 사람은 CPU 자원을 [시간당 흥미의 밀도]에 따라 할당한다. 그런데 시각적인 자극은 그냥 생각만 하는 것에 비해 [시간당 흥미의 밀도]가 높다. 그래서 대기 중인 생각에 CPU를 빼앗기지 않고 쉴 수 있다. 이 두 가지가 내가 산책을 그토록 중요하게 생각하는 이유다.

그런 면에서 휴식이 가만히 앉아서 쉬는 것이 되어서는 곤란하다. 대기 중인 생각이 많다면 가만히 앉아서 쉬어 봤자 금방 CPU가 잠식 당하고 원하는 휴식은 이루어지지 않는다. 실상 지식 노동자에게 필요한 휴식은 육체적 휴식이 아니라 뇌의 휴식이다. 휴식 시간에는 무조건 돌아다녀야 한다.

좌뇌와 우뇌를 번갈아 가면서 사용하는 것도 좋은 방법이다. 대화는 아마도 우뇌를 많이 사용하기 때문에 좌뇌의 사용율이 떨어지는 것이리라. IO bound job이란 것도 결국 뇌의 다른 부분을 사용하는 것이다. 고등학교 때 공부할 때도 이런 전력이 꽤 효과가 있었다. 공부 시간표를 수학 물리 화학 국어 영어 이런 식으로 잡는 것보다는 수학 국어 물리 영어 화학 이런 식으로 섞어주는 것이 훨씬 집중력이 오래 가고 효과가 있다. 아마도 뇌가 부분적으로나마 쉴 시간을 가질 수 있기 때문일 것이다.

그렇지만 사실 인생을 그렇게 빡빡하게 살 필요는 없다. 굳이 뇌의 최대 효율을 발휘하려고 애쓰기보다 그냥 제대로 쉴 수 있는 방법을 하나 쯤 갖는 것으로도 충분할 것이다. 나에게는 그것이 산책이다.

---

 

블로그

 

자원봉사자의 부담

대안언어축제 2006이 끝났다. 사실 준비하면서 정말 힘들었었고 중간에 때려 치고 싶은 생각이 수도 없이 들었었다. 앞으로 두 번 다시 이런 건 안하겠노라는 생각도 했었다. 하지만 정작 행사가 끝나고 나니 힘들었던 기억은 흐릿해지고 뿌듯함이 남는다. 이것이 내가 찾았던 자원봉사의 모티브일까? 아니, 그렇다고 하기엔 부족하다. 작년 대안언어축제의 자원봉사자들도 축제가 끝나고 나서 이런 뿌듯함을 느꼈을 것이고 좋은 경험이라는 이야기도 했었다. 그런데 왜 작년 자원봉사자들은 단 한 명도 이번에 자원봉사로 나서지 않았는가. 왜 하나같이 올해는 일반 참가자로 참가해보고 싶었다고 하는가? 이번 대안언어축제를 준비하면서 내가 저지른 가장 큰 잘못은 이 점을 처음부터 깊이 생각해보지 않았다는 것이다. 처음부터 이 문제를 고민해보았다면 절대 이렇게 진행하지 않았을 것이다. 나름 좋은 분위기로 끝난 축제에 찬물을 끼얹는 것 같지만 대안언어축제의 성공은 자봉들의 희생을 발판으로 삼고 있다.

자봉들이 희생하게 되는 것는 크게 세 가지로 볼 수 있다. 하나는 관심. 직장인들은 기본적으로 회사일이 우선일 수 밖에 없고 회사일 외의 문제에 많은 관심을 쏟기가 어렵다. 자봉 회의에서 결정된 내용들은 대개 근무시간에 해야 하는 일들인데 근무 시간에 대안언어축제에 관한 일을 하기는 쉽지 않다. 나는 그나마 우리 팀이 후원하는 일이라 어느 정도는 업무로 인정 받을 수 있는 일이었음에도 불구하고 근무 시간에 대안언어축제에 관련된 연락을 돌리고 하는 일들이 마음 편한 일이 아니었다.

다른 하나는 축제의 준비에 잡일이 많다는 것. 준비과정의 절반 이상이 별로 즐겁지 않은 사소한 잡일들로 채워져 있었다. 메일 한 통 쓰는 것조차도 간단한 일 같지만 잘 모르는 사람에게 메일 보낸다는 것이 그리 간단한 일은 아니다. 서론도 좀 집어 넣어야 하고 문구도 다듬어야 하고 답장도 확인해야 한다. 전화는 그런 종류의 부담은 적지만 안 받는 경우 기억했다가 나중에 다시 걸어야 하는 경우도 많고 전화번호 찾기 힘든 경우도 많아 역시 부담이다. 이런 일들을 즐겁게 해내려면 어떻게 해야 할까? 이건 아직도 답을 발견하지 못했다.

마지막으로 행사 당일. 일이 몰리기 때문에 축제를 즐길 수가 없다는 것. 왜 일부러 발표자들이 자봉을 위한 자리까지 만들어줬는데 자봉들은 오지 못하는가. 왜 밤에 술자리를 하는데도 내일 일 걱정을 해야 하는가.

희생이라는 표현에 거부감을 느끼는 사람이 있을지도 모르겠다. 자기가 좋아서 자원한 일인데 무슨 희생이냐고 할지도 모르겠다. 하지만 대안언어축제를 잘되게 하는데 자원하고 싶었던 사람은 있을지 몰라도 행사 당일 하루 4시간도 제대로 못 자면서 혹사당하고 싶었던 사람은 없을 것이다. 행사 준비에 참여하고 싶었던 사람은 많겠지만 매주 월요일을 고정 약속으로 정하고 싶었던 사람도 별로 없었을 것이다. ExtremeProgrammingExplained2ndEdition의 이야기를 끌어온다면 MutualBenefit이 잘 되지 않았다고 할 수 있을 것이다.

이 문제를 어떻게 풀 수 있을까? 내가 이 문제를 깨달은 것은 4주 전이다. 학생 자봉이 참가하면서 일의 진행이 빨라지는 것을 보면서, 그리고 작년 자봉이 왜 아무도 다시 참여하지 않았을까를 고민해보면서 무언가 느끼는 것이 있었다. 그 때부터 고민하면서 행사가 1주일 남았을 때쯤 잠정적인 결론을 내릴 수가 있었지만 이런 저런 제약조건들로 이번 행사에는 그 고민을 반영할 수 없었다. 이것이 내가 다음 대안언어축제의 스타트업에 참여하려는 이유이다. 자봉들이 희생하는 것을 당연한 것으로 여겨서는 안된다.

어쨋든 내가 내린 해답은 이런 것이다. 학생, 자봉, 발표자의 구분이 없는, 모든 참가자가 자봉이고 발표자인 그런 축제를 만드는 것이다. 생각해보면 자봉이 했던 일 중에 참가자가 직접 하면 안될 일은 아무 것도 없었다. 신뢰라는 전제조건에 모두 합의하기만 한다면 말이다. 이미 대안언어축제에 오는 사람들은 자발성이 높은 사람들이다. 책상 옮기고 의자 옮기는 건 다 참가자들이 직접 하는데 과일 씻는 거라고 못할 이유가 있을까? 마이크 고장나면 굳이 자봉이 뛰어가야 할 이유가 있을까? 스티커를 자봉이 지켜야 하는 것은 스티커 나눠주는 룰을 자봉이 정했기 때문이다. 참가자 모두가 함께 정한 룰이라면 그냥 어딘가에 놔두고 자유롭게 가져가도록 해도 룰을 어기지 않을 것이다. 신뢰는 신뢰할 수 있는 상황이 되어야 생기는 것이기도 하지만 또한 신뢰해야 신뢰할 수 있는 상황이 되는 것이기도 하다. 사실 현재의 대안언어축제만 해도 다른 컨퍼런스에 비하면 참가자들에 대한 아주 높은 신뢰를 기반으로 하고 있다. 하지만 우린 더 나아갈 수 있다.

물론 이상적인 이야기로 들릴 수도 있을 것이다. 하지만 위키가 바로 그런 이상적인 상황을 현실에서 보여주고 있지 않은가. CollectiveIntelligence, 바로 대안언어축제에 필요한 것이다. 축제 시작 6개월 전부터 메일링 리스트를 개설하고 메일링 참가자들이 모두 참가자 및 자봉이 된다면 충분히 가능할 것이다. 행사에 카메라가 필요하면 메일링에서 카메라 가져올 사람을 모집하면 된다. 장소 답사를 가야 한다면 메일링에서 답사 갈 사람을 모집하면 된다. 무슨 일을 해야 할지는 무슨 일을 해야 할까요?라는 메일 한 통에서 시작할 수 있을 것이다. 그러다가 한 달에 한 번쯤 오프라인 모임을 갖는다. 아이디어들을 실험해보기도 하고 머리를 맞대고 브레인스토밍도 한다. 물론 몇몇 사람은 facilitator 역할을 할 필요가 있을 것이다. 하지만 그 사람들이 희생하지는 않아도 될 것이다. 행사 당일에도 참가자 각자가 자신의 필요를 해결할 수 있다면, 먹거리는 알아서 챙겨 오고, 멀티탭 모자라면 알아서 사무실 가서 빌려오고 없으면 사오고, 시간 되면 알아서 모이고 세션 장소 알아서 찾아가고 한다면 자봉은 따로 필요 없다.

정말 내 생각처럼 이렇게 잘 될지는 아직 모르겠다. 그래서 다음 대안언어축제의 스타트업에는 꼭 참여해서 이렇게 끌고 가보고 싶고 만약 그렇게 된다면 스타트업 뿐 아니라 끝까지 참여할 것이다.

리더십

이번 축제에서 또 하나 느낀 것은 리더의 역할에 대한 것이다. 난 원래 일반적인 관리자의 역할을 좋아하지 않는다. 일 챙겨서 사람들에게 분배하고 확인하고 그런 매니저의 역할이 필요한가에 늘 의문을 갖고 있었다. 그래서 이번에 대자봉을 맡았지만 관리는 하지 않으려고 했다. 그저 facilitator 역할만 하고 그 외에는 다른 자봉과 같이 해왔다. 막판에는 일이 좀 몰리면서 어쩌다보니 관리하는 형국이 된 경우가 몇 가지 있지만 대체로 이번 대안언어축제는 대자봉 한 사람의 지휘 하에 자봉들이 일사불란하게 움직이는 그런 모습과는 거리가 멀었다. 그보다 자봉 각자가 셀프 리더십을 갖고 움직였다. 특히 행사 당일에는 정말 신기할 정도였다. 처음에는 다들 우왕좌왕하면서 일 분담도 제대로 되지 않고 그랬는데 특별히 내가 뭔가 조치를 취한 것도 아닌데 시간이 좀 지나면서 다들 자기 할 일을 잘 찾아서 했고 일정이 제대로 굴러가기 시작했다. 자봉들 소감 발표하는 시간에 과일 씼었다는 이야기를 들으면서 그걸 깨달았다. 난 과일을 씼어야 한다는 사실조차 깨닫지 못하고 있었는데 이미 알아서 다 하고 있었던 것이다. 그걸 깨닫고 생각해보니 정말 내가 신경쓰지도 않았던 일들이 다 잘 되고 있었다.

어쩌면 이건 챙겨야 할 일을 챙기지 못한 대자봉의 변명일지도 모른다. 사실 그래서 MS와의 커뮤니케이션도 구멍이 나서 MS 스폰서도, C# 발표도 제대로 안되었고 좀 안타까웠었다. 하지만 과연 내가 다 챙길 수 있긴 했을까? 원래 이런 일을 골고루 다 챙길 수 있는 역량을 가질 사람만이 리더를 할 수 있는 걸까? 이런 질문들을 던져보면 내가 선택한 방향 자체는 옳았다는 생각이 든다.

스티커

이번 행사 최고의 아이디어는 단연 스티커다. 여기에 이의를 제기할 사람은 아무도 없을 것 같다. [뿌듯 이펙트]를 통해 막강한 언어교환의 어포던스를 제공한 것 같다. 이 아이디어도 누구 한 사람의 아이디어로 이루어진 것이 아니다. 원래 발의는 김창준씨의 팔찌에서 시작해서 포도송이, 티셔츠, 띠 등의 아이디어로 이어졌다가 몇 번의 프로토타입을 거쳐 이름표로 결정되었다. 붙이는 모양도 여러 가지로 하다가 빙고 아이디어가 나와서 정사각형 배열로 하고 또 단순히 글자만 쓰면 재미 없다고 이왕 붙이는 거 해당 언어의 로고를 붙이자는 아이디어가 나왔다. 거기에 이름표 밑판을 흑백으로, 스티커를 칼라로 찍자는 의견이 채택되었다. 채택된 후 실행 과정에서도 여러 사람이 로고를 찾고 디자인했다. 이번 행사 준비 과정 중 가장 많은 사람들이 참여했고 가장 활발하고 즐겁게 준비한 것이고 그만큼 효과도 좋았던 것 같다. 스티커가 넘 맘에 들어서 세트별로 한 30장씩 챙겨왔다. 나눠줘야지.

세션

대안언어축제 2006의 공식 세션은 16개, 자바 컨퍼런스에서 하루에 하는 세션 수랑 같은 수를 2박 3일간 소화한다. 세션만 놓고 보면 대안언어축제의 진가를 알 수 없다. 중요한 것은 참가자들간의 커뮤니케이션이다. 다행히도 대안언어축제의 참가자들은 대부분 이것을 알고 있었고 그것이 이번 축제를 성공으로 평가할 수 있는 이유일 것이다. 이 점에서 본다면 사실 세션은 더 줄여야 할지도 모른다. 아니, 아예 없애는 게 바람직할지도 모르겠다. 많은 사람들이 세션을 들었는데도 뭘 배웠는지 모르겠다는 소감을 토로했다. 튜토리얼이 아무리 친절하게 준비된다고 해도 모든 사람의 학습 속도를 맞출 수는 없다. 그러다보니 어떤 사람들에게는 지루하고 어떤 사람들에게는 따라가기 힘들게 된다. 그런 면에서 맨투맨 언어교환은 위력적이다. 궁금한 걸 바로 물어볼 수 있고 가르치는 사람도 더 잘 배울 수 있다. 나도 간만에 파이썬을 가르치는 쪽으로 언어교환을 했는데 파이썬은 제대로 알지도 못하면서 가르쳤는데도 그 과정 중에 많이 배운 것 같다. BOF도 세션 형태로 하는 것보다는 OST로 하는 것이 더 나은 것 같다. 세션과 BOF를 줄이고 OST와 언어교환을 늘리는 것이 더 나았을 것 같다.

물론 그래도 씨앗이 될 만한 무언가는 필요하다. 전혀 배경지식이 없는 사람들이 언어교환을 잘할 가능성은 별로 높지 않다. 하지만 그 씨앗이 꼭 세션이어야 할 필요는 없을 것 같다. 사람 그 자체가 씨앗이 될 수 있다. 그런 면에서 이번에 통사라는 역할이 좀더 드러날 필요가 있는 것 같다. 20명의 발표자와 각각의 세션보다 40명의 통사가 더 좋은 씨앗이 될 수 있을 것이다.

인간

믿어야 하는 것은 기계가 아니라 인간이라는 것을 다시 한 번 느꼈다.

자봉

자봉끼리 행사 전에 좀더 친해지는 자리가 필요했다. 원래 계획했던 술자리를 한 번 했었더라면 좋았을 것 같다. 다만, 자봉끼리 너무 친밀하면 새로운 멤버가 자봉으로 참여하기 힘들다는 문제는 있을 것이다.

---

 

블로그

얼핏 비슷한 것 같은 말, 경쟁심, 승부욕. 둘다 많은 사람들에게 열정을 불어 넣는 동기로 작용한다. 하지만 이 둘은 차이가 있다. 경쟁심은 일반적으로 상대가 제한적이다. "나는 누구는 꼭 이겨야 해" 이런 게 경쟁심이다. 내가 반에서 1등은 못할 지라도 내 짝지는 이겨야 한다고 생각하는 게 경쟁심이다. 반면 승부욕은 상대보다 승부 자체를 이기고 싶어하는 욕망이다. 게임에서 상대는 계속 바뀌지만 난 계속 이기고 싶은 것이다.

경쟁심은 때때로 팀원 간에도 나타난다. 하지만 그렇다고 꼭 팀웍을 저해하는 것은 아니다. 강백호와 서태웅은 서로에 대한 경쟁심이 강하다. 그래서 경기 중에서도 서로 패스도 안하고 협력하지 않을 때도 많다. 하지만 정말 중요한 승부가 눈앞에 걸리면 달라진다. 승부가 중요해지면 상대와 협력해야 이길 수 있다는 사실을 인정하게 되고 협력하기 시작한다. 승부욕이 더 강하기 때문이다.

반대로 승부욕은 강하지 않은데 경쟁심이 강하다면 좋지 않은 결과가 나타날 수 있다. 대개 팀의 성공은 팀원의 성공도 이끌지만 팀이 실패한다고 개인이 실패하는 것은 아니기 때문이다. 프로 스포츠에서 흔히 나타나는 현상이다. 꼴찌팀의 농구 선수가 매일 팀이 지더라도 혼자 활약해서 40점을 올리면 그 선수가 팀이 원하는 플레이를 하지 않더라도 몸값이 올라가고 주목을 받을 수 있다. 하지만 그런 선수는 우승 반지를 낄 수는 없을 것이다.

간혹 스타크래프트로 FreeForAll을 할 때도 비슷한 경우가 나타난다. FreeForAll에서 승자는 한 사람 뿐이므로 이기고 싶다면 한 상대에만 힘을 쏟아 부을 게 아니라 자기가 강해지는 것이 중요하다. 하지만 대부분의 사람은 자기가 한 번 공격당하면 자기를 공격했던 상대만 물고 늘어진다. 그러면 그 상대와 둘이서 치고 박는 사이 다른 상대가 어부지리를 얻는다. 아주 쉬운 이야기지만 자기 눈앞에 닥치면 깨닫지 못하는 경우가 많다.

그렇다고 승부욕만 있고 경쟁심이 약한 것도 그리 좋은 것은 아니다. 경쟁심은 지속성이 강하지만 승부욕은 그렇지 않기 때문이다. 눈앞에 닥치는 승부에는 최선을 다하지만 그 사이 다른 상대가 앞서 가는 것을 방관하게 되기도 한다.

나는 경쟁심보다 승부욕이 강한 편이다. 대체로 경쟁심보다 승부욕이 강한 사람은 오만한 성격이 많은 것 같다. 자기가 최고라고 생각하니까 라이벌 같은 걸 인정하지 않는 것이고, 최고니까 당연히 승부에서 이겨야 한다고 생각하는 것이다. 그래서 강한 상대를 만나도 그냥 내가 넘어야 할 많은 산 중 하나일 뿐이라고 생각하게 된다. 어쨋든 나쁜 스타일은 아닌 것 같다. 한 때 들었던 초우주거만도 별반 듣기 싫은 표현이 아니었고.

머, 어쨋든 이번에는 우리 팀에 경쟁 상대가 있다. 이것이 나의 열정에 지속성을 가져다 줄 것 같다. 화르르~

---

 

블로그

내가 개발자를 채용해야 할 때 중요하게 생각하는 원칙과 면접 방법들을 정리해본다.

우선 내가 생각하는 채용의 대원칙을 한 마디로 정리하면, 장점이 뚜렷한 사람이다. 현재의 팀에 부족한 장점을 갖고 있으면 더더욱 좋고, 장점이 많으면 더 좋다. 하지만 약한 장점이 여러 개인 사람보다는 하나의 장점이 확실한 사람을 더 선호한다. 단점은 전혀 고려하지 않는다. 정말로 단점은 고려하지 않는다. 아, 물론 흉악 범죄를 저지를 것 같은 사람이라거나 그러면 안되겠지만, 그런 사람은 한 번도 면접에서 본 적이 없기 때문에 별로 생각할 필요 없다.

단점을 고려하지 않는 이유는 고려할 필요가 없기 때문이다. 팀의 성과는 개개인의 장점이 모여서 나오는 것이다. 개개인의 단점은 팀이 보완하면 된다. 세 명 이상 모인 팀에서 개개인의 단점을 보완 못할 상황은 거의 발생하지 않는다. 만약 팀을 이끄는 팀장이 명확하게 있는 상황이라면 개개인의 단점을 보완하는 것은 팀장의 책임이다. 나는 내가 팀장이면 다른 사람의 단점이 뭐든 보완할 자신이 있기 때문에 자신 있게 장점이 뛰어난 사람을 뽑는다. 나는 운이 좋아서 늘 좋은 팀원만 만나왔다고 생각할 수도 있겠지만, 난 충분히 일반화해도 좋을 만큼 대부분의 단점이 별 것 아니라고 생각한다.

물론 나 역시 단점이 아주 뚜렷하고 단점의 종류도 여러 가지다. 하지만 나 자신에게도 같은 기준이 적용된다. 난 내 단점을 극복하기 위한 노력은 전혀 하지 않는다. 내 노력은 내 장점을 강화하는데 집중된다. 단점에 관해 내가 하는 노력은 단 두 가지. 늘 내 단점을 보완해줄 수 있는 사람이 있는 팀에서 일하려고 하는 것. 그리고 내 단점을 커버할 수 있는 시스템을 만드려고 노력하는 것. 나 뿐 아니라 난 내 팀원들이 다 장점을 강화하기 위한 노력을 더 많이 했으면 좋겠다.

 

장점이 뚜렷한 사람을 뽑는 것이 목표라면 채용 과정은 장점을 발견하는 과정이다. 장점의 발견은 서류 전형에서부터 시작되지만, 아직 서류에서 걸러야 할 정도로 지원자가 많은 상황은 별로 겪어본 적이 없어서 눈에 띄는 점 하나만 있으면 대부분 서류 전형은 합격이었다. 정말 중요한 건 면접에서 장점을 발견하는 방법이다.

원래 이 문서는 면접에서 물어보기 좋은 질문들을 정리하기 위한 용도로 시작했다. 하지만, 여러 번 채용 면접을 하다보니 사전에 정해진 질문은 의미가 없었다. 중요한 건 그 질문에 대한 답을 듣고 두번째, 세번째 깊이 파고드는 질문을 하는 것이다. 간혹 보면 유용한 면접 질문으로 널리 퍼져 있는 질문을 기계적으로 하는 경우를 본다. 이를테면 이런 것들이다.

• 가장 최근에 읽은 책은 무엇인가요?
• 개발자 커뮤니티에서 활동을 하시나요?
• 집에서 취미로 개발을 하나요?

질문 자체는 나쁘지 않다. 첫번째 질문도 "자기 계발을 열심히 하시나요?" 같은 질문에 비하면 좀더 구체적인 답을 이끌어내기 좋은 질문이다. 하지만, 이 질문의 한계는 닫힌 질문이라는 것이다. 닫힌 질문은 뭐고 그럼 열린 질문은 뭔가? 닫힌 질문은 알고 싶은 정보가 정해져 있는 상태에서 던지는 질문이다. 첫번째 질문은 이 개발자가 공부를 열심히 하는 사람인지 아닌지 알기 위해서 던진 질문이다. 하지만 이 질문으로 정말 이 개발자가 공부를 열심히 하는지 아닌지 알 수 있을까? 공부를 하는 방식은 여러 가지가 있다. 책은 이미 낡았다고 생각해서 전혀 안 읽지만 인터넷에서 문서를 열심히 찾아보면서 직접 실험해보는 개발자는 어떨까? 혹은 각종 논문을 열심히 탐독하는 개발자는? 코드가 최고라고 생각해서 오픈소스 코드를 깊이 파고드는 개발자는? 이처럼 다양한 공부 스타일이 있는데, 후보자가 공부를 열심히 하는지 아닌지 알기 위해서 이 모든 가능성에 대해 질문을 던질 것인가?

집에서 취미로 개발을 하냐고? 나도 이 질문 몇 번 받았다. 그 때는 마침 집에서 불꽃 코딩 할 때라서 당연히 yes라고 대답했지만 이콜레모를 주로 하던 동안에는 집에서 일과 분리된 개발을 따로 한 적이 없다. 당연히 회사 일이 가장 재미있었기 때문이다. 그런데 이런 질문을 던져서 과연 이 사람이 geek인지 아닌지 알 수 있을까? 이것이 닫힌 질문의 함정이다.

물론 닫힌 질문도 좀더 잘할 수는 있다. 이를테면 이렇게 해볼 수 있다.

• Q: 기술적인 공부를 많이 하는 편인가요?
• A: 네.
• Q: 그럼 최근에 어떤 공부를 했었는지 말씀해주실 수 있나요?
• A: 최근에 실용주의 사고와 학습을 읽었습니다.
• Q: 그게 언제였나요?
• A: 재..재작년이군요.
• Q: 최근에 다른 건 없었나요?
• A: 아, 지난 주에 Dynamo 관련 논문을 하나 읽었네요.
• Q: 그 논문을 간단히 요약해서 말씀해주실 수 있나요?

이런 식이면 공부하는 스타일인지 아닌지 좀더 파고들어볼 수는 있다. 그런데, 만약 공부는 별로 열심히 하지 않지만, 데이터베이스 성능 튜닝을 기가 막히게 해내는 사람이라면 어떨까? 장점은 수십 수백가지가 있다. 닫힌 질문은 말하자면 수십 수백 가지의 장점의 리스트를 뽑아놓고 하나씩 물어보면서 체크 표시를 하는, 그런 방식이다. 물론 이렇게 세상에 존재하는 개발자의 모든 장점을 체크해볼 수 있으면 더할 나위 없이 좋겠지만, 우리의 면접 시간은 제한되어 있다. 그래서 나는 확인할 장점의 리스트를 미리 가지고 가지 않는다.

그보다 더 좋은 방법은 열린 질문을 하는 것이다. 열린 질문이라고 해서 엄청 고급스러운 질문이 아니라, 그냥 특정한 답을 기대하지 않고 그 사람의 경험을 더 깊이 끄집어낼 수 있는 질문이다.

예를 들면 다음과 같은 식이다.

• Q: 아이폰 애플리케이션 강의를 하신 적이 있네요? 아이폰 개발하는 건 다른 것에 비해 어땠나요?
• A: 지랄 같았습니다.
• Q: ㅎㅎㅎ, 어떤 점이 어려웠나요?
• A: 제일 골치아픈 건 앱이 자꾸 죽는 겁니다. 지금은 자동으로 메모리 해제를 해주는 그...
• Q: ARC 말이군요?
• A: 네, 그게 있어서 괜찮은데, 예전엔 수동으로 해제를 해줘야 했었거든요.
• Q: 그래서 그 문제를 결국 완전히 정복했나요? 아니면 아직도 어려움을 겪으시나요?
• A: 예전보단 적게 겪습니다만, 아직 완전히 그 문제를 이해했다고는 할 수 없네요.

이 정도면 이 사람은 어려운 문제를 만났을 때 그럭저럭 헤처 나가기는 하지만 완전한 개념 이해를 하려고 하는 타입은 아니다. 이쯤에서 면접관도 iOS 개발을 잘 알아서, autorelease와 release의 차이를 이해하는지에 대해 물어볼 수 있으면 더 확실하게 확인할 수 있다. 만약 이런 차이를 정확하게 이해하고 설명할 수 있다면 이 사람은 어려운 문제를 만났을 때 개념을 깊이 이해하고 해결하는 장점을 가졌다는 것을 발견한 것이다.

예를 몇 개 더 들어보자.

• Q: 최근에 node.js를 사용하셨었네요? node.js 써보니까 어떻던가요?
• A: 편한 점도 있는데, 실행 결과를 콜백으로 받아야 되는 건 좀 불편하더군요.
• Q: 최근 커뮤니티에서 node.js의 CPS 스타일에 대해 논쟁이 있었다는 것을 아시나요?
• A: 네, 관심 있게 지켜봤었습니다.
• Q: 그 논쟁에 대해 어떻게 생각하시나요?
• A: 저도 CPS 스타일은 나쁘다고 생각합니다.
• Q: 그럼 그 문제를 해결하기 위해 어떤 노력들을 해보셨나요?
• A: 처음에는 step 같은 라이브러리를 도입해서 써봤는데, 크게 도움이 되진 않더군요. 그러다가 node-fibers를 알게 되어서 써봤는데, 이게 정말 좋더군요.
• Q: 어떤 점이 좋던가요?
• A: node-fibers를 쓰면 그냥 일반적인 절차적 코드처럼 코드를 짤 수 있어요. 그래서 콜백을 신경쓰지 않고 코딩을 하는데, 비동기의 장점은 그대로 살릴 수 있어서 좋았습니다.
• Q: node-fibers를 쓰면서 어려움은 없었나요?
• A: 아, node 버전에 따라 실행 시 에러율이 높아지기도 해서 좀 고생했는데, 잘 되는 버전을 찾아서 빌드했습니다.
• Q: 잘 되는 버전은 어떻게 찾았나요?
• A: 에러 메세지로 검색을 하다보니까 github에서 issue가 나오더군요. 그래서 그 이슈가 해결된 버전을 찾았습니다.

이쯤 되면 이 사람은 커뮤니티의 흐름도 보고 있으면서 당장의 문제 해결 뿐 아니라 코드 품질에 대한 고민도 하는 사람이고(CPS는 코드 품질 문제), 문제를 해결하기 위해 끝까지 추적하는 끈기도 가진 사람이다. 단 하나의 경험을 집중적으로 파고 들어도 여러 가지 장점이 나오는 것이다. 경력이 많다고 해서 그 사람의 여러 가지 경력에 대해 다 붙잡고 물어볼 필요가 없다. 하나만 끈질기게 물고 늘어지면 여러 가지 장점이 발굴되는 것이다.

이건 면접관도 node.js 경험이 있어서 저렇게 질문을 던질 수 있다고 볼 수도 있지만, 또 질문을 자세히 뜯어보면 대부분 node.js를 몰라도 파고들 수 있는 질문이다.

물론, 후보자가 경험한 기술에 대해 면접관이 잘 알고 있다면 좀더 쉽고 편한 방법들이 많다. 이를테면, 데이터베이스 성능 문제를 많이 다룬 후보자를 만났다고 해보자. 그럼 이런 질문을 던져볼 수 있다.

• Q: 데이터베이스 성능 튜닝의 핵심을 한 문장으로 말하라면 어떻게 표현할 수 있을까요?
• A: 그야 물론 인덱스죠.

꼭 인덱스가 정답인 건 아니지만, 이런 문제에 대해 주관이 정리되어 있다면 깊이 있게 고민해왔을 가능성이 높다. 물론 인덱스라고 답했으니 인덱스에 대해서 좀더 깊이 물어봐야 한다. 이를테면 인덱스를 타지 않는 게 더 좋은 건 어떤 경우인가, MySQL에서 결합 인덱스는 어떤가, 힌트는 어떨 때 사용하는가 등등. 이것도 정답을 확인하기 위한 것이 아니다. 예를 들어 MySQL 결합 인덱스는 개판이죠하고 답했다면 왜 개판인지 또 한 번 더 물어봐야 한다.

기술을 잘 알고 있을 때는 짤막한 닫힌 질문을 여러 개 해보는 것도 도움이 될 때가 있다. 이를테면, HTML/CSS 개발자에게 블록 엘리먼트와 인라인 엘리먼트의 차이점을 설명하라고 했는데 잘 못한다면 실격 사유가 될 수 있다. 대답하면 높은 점수를 줄 수 있지만 대답 못해도 감점요인이 아닌 질문들도 있다. 이를테면 해당 기술을 깊이 있게 공부했으면 알 법한 것들을 물어보는 것이다. 내가 기술면접이라는 걸 처음 면접자로 경험한 게 NHN 입사할 때였는데, 그 때 Java의 int와 C의 int가 어떻게 다르냐는 질문을 받았다. 몰라도 별 지장 없는 것이지만 알고 있으면 아 이 사람이 제법 디테일하게 공부하는 사람이구나 하는 걸 알 수 있다.(물론 난 정확하게 대답했지 하하)

만약 어려운 문제를 해결해간 경험이 있다면 더없이 파고들기 좋은 소재다.

• Q: 온라인 결제 붙일 때 뭐가 제일 어려웠나요?
• A: 환불 프로세스 적용하는 게 제일 어려웠어요. 운영팀에서 접수를 받았을 때 주문 내역에 대한 확인도 간편해야 하고, 쉽게 취소를 할 수 있어야 하지만, 또 매니저의 승인을 받아야 하거든요. 절차가 복잡해서 뭔가 하나 놓치기가 쉬웠어요.
• Q: 그래서 어떻게 해결했나요?
• A: 처음에는 그냥 구현한 다음 운영팀 담당자 찾아가서 매번 테스트를 부탁했어요. 그런데, 처음에는 열심히 해주더니 점점 짜증을 내는 거예요. 한 번에 잘 되는 걸 들고 오길 바라나봐요. 근데 프로세스를 정확하게 설명해주는 것도 아니고, 설명할 때마다 조금씩 다른 거예요. 너무 힘들었어요.
• Q: 그래서 운영팀 담당자와의 갈등은 어떻게 해결했나요?
• A: 그림으로 정리를 해보기로 했어요. 이것도 같이 그리면 산으로 갈 것 같아서 제가 미리 지금까지 들은 이야기를 바탕으로 초안을 그렸어요. 그래서 그 초안을 들고 찾아갔죠. 그랬더니 여기저기 수정을 해주더라구요. 그리고 그 수정된 그림을 다른 운영팀 사람들에게도 보여줬어요. 그렇게 피드백을 받아서 그림을 개발팀으로 가져왔죠. 그리고는 그 그림대로 selenium으로 테스트 케이스를 만들었어요.
• Q: 테스트 케이스를 만든 이유는요?
• A: 프로세스가 복잡하다보니 테스트가 없으면 뭐 하나 놓칠 것 같아서요.
• Q: 테스트 케이스를 만들고 나니 잘 되던가요?
• A: 일단 테스트가 있으니 개발이 다른 건 괜찮았는데, 결제 모듈까지 엮어서 자동 테스트를 돌리기가 어렵더군요.
• Q: 그건 왜 어려웠어요?
• A: 아, 결제 취소를 하려면 결제를 먼저 해야 되는데 그건 ActiveX 때문에 selenium으로 자동화가 안되거든요.
• Q: 그럼 어떻게 해결했어요?
• A: 결제 모듈의 실행파일에 전달하는 인자를 봤어요. 그래서 그 인자를 정확하게 전달하면 결제 및 결제 취소가 된 것으로 볼 수 있도록 결제를 흉내내는 코드를 만들어서 테스트하기 전에 injection을 시켰어요. 그리고 그 mock 코드가 실제 결제와 동일하게 동작하는지는 매뉴얼 테스트로 확인했구요.

이 대화에서는 이 사람이 상황에 맞는 커뮤니케이션 수단을 선택할 수 있다는 것, 거듭된 수정 요구에 화를 내지 않고 애자일하게 접근해갈 수 있다는 것, 테스트 자동화에 대한 고민이 깊다는 것을 확인할 수 있다.

 

장점을 많이 발견하려면 결국 후보자가 자신의 경험에 대해 깊이 있게 말할 수 있도록 해야 한다. 단편적인 질문에 그치면 후보자의 답변도 단편적으로 흐르고 만다. 간혹 말하는 걸 좋아해서 장광설을 늘어놓는 후보자도 있지만, 대개 그런 장광설은 깊게 들어가기보다는 넓게 퍼지는 경향이 있기 때문에 적절한 질문으로 깊게 들어가도록 유도해야 한다. 파고들되 닫힌 질문이 아니라 열린 질문을 해야 후보자 스스로 깊게 들어갈 수 있는 것이다.

약간 사족을 넣자면, 내가 기술을 선택하는 기준은 이와 정반대다. 기술을 선택할 때는 장점이 뚜렷한 기술보다 단점이 적은 기술을 선호한다. 이것이 내가 파이썬과 장고를 선택한 이유이기도 하다. 사람과 기술은 다르다. 보완할 수 없는 치명적인 단점을 가진 사람은 생각보다 아주 드물다. 적어도 내 경력 13년 간 저 사람은 구제불능의 단점을 가졌다고 생각한 사람이 아무도 없었다. 물론 다시 상종하기 싫은 사람은 여럿 있었지만;;

팀웍을 해치는 사람 이런 것도 난 안 믿는다. 내 지론은 이거다. 팀웍이 나쁜 팀원은 없다. 팀웍이 나쁜 팀이 있을 뿐이다. 팀웍의 실패는 팀장의 책임이지 개별 팀원에 돌릴 일이 아니다. 물론 나 역시 팀장으로서 팀웍에 실패한 경험이 있지만, 적어도 난 그게 내 책임이라는 정도는 안다. 게다가 면접 자리에서 팀웍을 검증하는 건 불가능한 일이다.

커뮤니케이션 스킬도 그다지 중요하게 생각하지 않는다. 내가 오픈마루에 있을 때 어떤 팀장은 커뮤니케이션 스킬도 능력의 일부이기 때문에 기술려과 커뮤니케이션을 따로 떼서 생각할 수 없다고 주장하는 사람도 있었는데, 내 생각은 전혀 다르다. 커뮤니케이션도 팀의 역할이다. 내가 경험한 개발자 중에는 개발은 잘하는데 표현은 잘 못하는 사람도 많았다. 그런 사람이 팀에 기여하게 만들 방법은 얼마든지 있다.

목적이 장점을 발견하는 것이니만큼, 압박 면접 같은 건 안한다. 물론 내가 티몬에서 채용 면접을 했을 때 그걸 압박 면접이라고 느낀 사람도 있었는데, 솔직히 그 때는 후보자의 입장을 충분히 배려하지 못했다. 깊이 파고드는 질문을 많이 해야 하는 만큼, 그 집요함에 불쾌감을 느낄 가능성도 꽤 있다. 그래서 처음부터 긴장을 잘 풀어주고, 부드러운 톤으로 대화를 이어가야 한다. 그래도 그 때 두어 번 실수한 이후로는 잘 해온 것 같다.

 

한줄 요약. 채용 면접은 장점을 발견하는 과정이고, 장점을 끄집어내기 위해서는 단편적인 질문이나 닫힌 질문이 아니라, 열린 질문으로 깊이 파고들어야 한다.

---

 

블로그 소프트웨어 개발