얼핏 비슷한 것 같은 말, 경쟁심, 승부욕. 둘다 많은 사람들에게 열정을 불어 넣는 동기로 작용한다. 하지만 이 둘은 차이가 있다. 경쟁심은 일반적으로 상대가 제한적이다. "나는 누구는 꼭 이겨야 해" 이런 게 경쟁심이다. 내가 반에서 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년 간 저 사람은 구제불능의 단점을 가졌다고 생각한 사람이 아무도 없었다. 물론 다시 상종하기 싫은 사람은 여럿 있었지만;;

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

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

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

 

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

---

 

블로그 소프트웨어 개발

 

P-Camp는 Project, Process, People 등의 기치를 내건 소규모 컨퍼런스였다. 오전은 세션, 오후는 참가 단체의 방법론(?)에 대한 간략한 소개와 이어지는 OST가 있었다. 중간에 소프트웨어 진흥원측의 생뚱맞은 PT가 약간 에러였지만 대체로 상당히 만족스러운 행사였다. 얼마 전 웹앱스콘이 안겨준 대실망과도 오버랩되었다.

세션은 비폭력대화를 들었다. 평소 폭력대화-_-를 많이 하는 나에겐 도움이 될 것 같았기 때문에 신청했다. 비폭력 대화라는 제목은 마치 대화에서 폭력적인 요소를 제거하고 대화하는 방법 같은 이미지를 주었는데 웬지 그런 식상한 내용은 아닐 것 같았다. 역시나, 예상과는 많이 달랐는데 비폭력 대화라는 것이 비폭력적 대화라기보다는 상황을 비폭력으로 이끌고 가는 대화를 말하는 것 같았다. 보면서 이너게임과 3FS가 오버랩되었다. 간단히 요약해보자면, 일련의 대화 모델을 활용하는 것이다. 다음 네 가지 요소를 활용해서 대화를 진행한다.

• 관찰
• 느낌
• 필요
• 행동

관찰은 이너게임에서 말하는 '비평가적 인지'와 비슷하다. 보통 사람들이 대화할 때 표현에 평가나 판단을 많이 담아서 쓰는데 그러면 듣는 사람에게 거부감을 일으키기 때문에 가급적이면 사실 그대로를 이야기하라는 것이다. 예를 들어 누군가에게

라고 말했다고 하자. 당연히 기분이 나쁠 것이다. 반박의 말을 할 수 있는 상황이라면 이런 말을 하기 십상이다.

그럼 보통 이런 대답을 듣게 된다.

이럴 때 비폭력 대화의 방식은 이런 것이다.

이런 식으로 대응한다. 먼저 관찰한 사실 있는 그대로를 이야기한 후 그로 인한 자신의 감정 변화를 드러낸다. 그리고 그런 감정 변화가 일어난 것은 자신이 필요로 하는 무언가가 만족되지 못했음을 말해주는 것이다. 이렇게 표현 속에 평가적인 요소를 제거하고 좀더 자신의 감정에 충실하게 이야기하면 오히려 상대방의 폭력적인 반응이 줄어들게 된다는 것이다. 위의 예는 약간 빈약한 감이 있는데 세션에서 접했던 참가자들의 예를 비폭력 대화로 풀어내는 모습은 상당히 설득력이 있었다.

그리고 마지막으로 행동을 요구하게 되는데 이건 두 가지로 나뉜다. 하나는 상대방에게 지금까지 자기의 말을 어떻게 생각하느냐고 물어보는 것이다. 상대방에게도 판단할 권리를 주는 것이다. 이를테면 이런 것이다.

또 다른 방법은 구체적인 어떤 행동을 부탁하는 것이다. 예를 든다면 다음과 같다.

어쨋든 선택권 자체는 상대방에게 주는 것이다. 이런 것도 이너게임과 아주 비슷한 측면이 있다. 일단은 나에게 집중해서 내 마음의 소리에 충실하게 되면 다른 사람들이 그에 반응해줄 수도 있고 아닐 수도 있지만 보통은 반응해줄 확률이 높고 또 반응해주지 않더라도 크게 폭력적인 사태(?)는 일어나지 않는다는 것이다.

생각해보면 난 꽤 비폭력 대화를 자주 활용하는 편이었다. 팀내에서 회고할 때나, 혹은 프로젝트의 방향성 같은 것에 대해 이야기할 때 이런 방법을 많이 썼었고 ECUS 프로젝트를 하는 동안은 꽤 효과가 있었던 것 같기도 하다. 근데 난 이에 못지 않게 폭력 대화도 많이 한다. 선화랑도 폭력적인 대화를 하는 경우가 적지 않게 있다. 가족하고도 그렇고. 가까운 사람과의 관계에서 더 중요한 대화법인 것 같다.

오후에 요약 세션은 그럭저럭 괜찮앗다. 그 중 김창준씨의 애자일 프로세스 소개도 아주 인상적이었다. 애자일 프로세스를 모르는 사람에게 10분 동안 소개를 하는 것인데 이런 식의 짧은 세션에서 이미 애자일 프로세스에 익숙한 사람들에게까지 깊은 인상을 남긴다는 것은 정말 대단한 일이다. 그 요약은 이랬다. "고객에게 매일매일 가치를 전하라" 짧은 한 문장이지만 단어 하나하나를 곱씹어보면 많은 의미를 발견할 수 있다. 그래서 한동안 이것을 일일 회고 포맷으로 써보기로 햇다. 오늘도 우리는 고객에게 가치를 전했는가? 아주 훌륭한 회고가 될 것 같다.

또 하나 유용했던 이야기는 마지막에 나온 사람이 해준 [:밝은 곳에서 동전 찾는 오류]

OST의 백미는 근무시간 줄이기가 아니었을까 싶다. 즐겁게 일하기 쪽 스페이스에서 이야기하다가 문득 적게 일하기에 대해서 스페이스를 열고 싶어서 열었더니 의외로 많은 사람들이 모였고 많은 이야기가 오고갔다. 처음에는 계속 눌러 있다가 나중에는 오며 가며 조금씩 끼어들었는데 참 여러 가지 생각이 들었다. 대체로 적게 일하기를 하고 싶어는 했지만 "그게 가능하냐"라든지, "경영진을 어떻게 설득할 것이냐", "조삼모사 아니냐" 등의 의문을 제기했다. 이에 대해 실제로 적게 일하고 있는 사람들(나도 어느 정도는 적게 일하기를 실천하고 있는 편이었다.)이 경험을 나누고 질문에 대한 의견을 표시했다. 근데 이 과정에서 확연하게 느낀 것은 적게 일하고 있는 사람들은 말투가 확신에 차 있고 그런 말을 하는 표정 자체도 즐거워 보였다는 것이다. 나 역시 그렇게 보였을 것이다.

김창준씨가 일주일에 4시간 일한다는 사람의 이야기도 해주었다. 책도 있댄다. 정말 놀랍다. 하지만 또 한 편으로는 최근에 읽은 책들이 스치고 지나가기도 했다. 전 세계의 금융계를 쥐고 흔들었던 J.P. 모건도 하루에 2~3시간 이상 일하지 않았다고 하고 백만장자 마인드에서도 백만장자들이 하루 6시간 일하는 사람은 많지 않았다고 한다. 어쨋든 일하는 시간과 성공과의 상관 관계는 별로 없는 게 확실한 것 같다. 사실 열심히 일해서 누구나 부자가 될 수 있다면 세상에 왜 이렇게 가난한 사람이 많겠는가.

대안언어축제 모임 때문에 끝까지 못 보고 나온 게 좀 아쉽다.

---

 

블로그 / 소프트웨어 개발

 

그루폰이나 티켓몬스터 같은 서비스를 소셜 커머스라고 부르는데, 여기에 어떤 사람들은 그건 소셜 커머스가 아니라 Group Buying이라고 이야기한다. 하지만 난 보는 시각에 따라 맞을 수도 있고 아닐 수도 있다고 보는데, 일단은 Group Buying도 소셜 커머스라는 관점을 이야기해본다.

소셜 커머스라는 것은 사람들의 사회적 관계(소셜)을 판매(커머스)에 도움이 되게 만들자는 것이다. 사실 이런 관점에서 본다면 소셜 커머스의 시작은 입소문 마케팅이다. 그런데, 이 입소문 마케팅에 관해서 아주 심각한 오해가 있다. 블로그에 글 쓰고 트위터에 올리고 페이스북에 올리는 것 등이 입소문 마케팅을 촉진한다고 생각하는 것이다. 하지만, 사실 입소문 마케팅은 마케팅으로서 존재하는 것이 아니다. 입소문 마케팅의 이론은 좋은 제품은 소비자가 알아서 소문을 내준다라는 것이고, 오히려 마케팅보다는 제품을 잘 만들고, 좋은 서비스를 제공하는데 집중하라는 것이다. 그런데 한국에서 웹 2.0 바람과 함께 입소문 마케팅 열풍이 불면서 괜히 블로그만 오염시켜버렸고, 기대했던 효과를 거둔 곳은 아무도 없다. 오히려, 한국에서 가장 입소문 마케팅이 잘 되는 것은 웹 1.0스러운 사이트의 대표격인 네이버와 지마켓이다. 네이버가 시대에 뒤쳐지고 어쩌고 하지만 어쨋든 누가 뭔가를 물어볼 때 "네이버에 검색해봐", "지마켓에서 사면 되"라고 말한다는 것은 입소문 마케팅이 아주 잘 되고 있다는 것이다. 어쨋든 입소문 마케팅은 마케팅으로서는 실체가 없다.

그럼 과연 소셜 커머스는 실체가 있는 것인가? 티켓몬스터의 Group Buying 역시 그냥 싸니까 사람들이 입소문을 내는 것 뿐이지 소셜 성격을 가진다고 할 수 있는가? 여기서 그래도 yes인 이유가 하나 있다. Group Buying의 deal은 최소 인원수를 넘겨야 성사된다. 그럼 구매자들은 최소 인원수가 넘어가지 않은 상황을 보고 deal을 성립하게 만들기 위해 직접 마케팅에 나서게 된다. 친구한테 사라고 하는 것이다. 알아서 자기들의 네트워크에서 입소문을 내게 된다. 소셜 네트워크가 윈윈으로 작용하면서 단순 입소문 이상의 효과를 내기 때문에 소셜 커머스로서 차별성이 있는 것이다.

이건 굳이 시스템으로 지원할 필요도 없다. 티켓몬스터도 그렇고 Group Buying 사이트들 중에 이런 걸 시스템으로 잘 제공하는 곳은 흔치 않다. 그럼에도 불구하고 공동구매라는 성격이 개인의 소셜 네트워크를 활용하게 유도하는 것이다. 그래서 소셜 커머스다.

그렇지만, 요즘은 이런 의미가 좀 퇴색하고 있다. 역설적이게도 Group Buying이 잘 되면서 최소 인원수를 못 넘기는 경우는 드물게 되버렸고, 이제는 그냥 싸고 경쟁력 있는 제품이 올라오기 때문에 그 자체로 소비자가 몰린다. 물론, 이건 더 긍정적인 신호다. 소셜을 이용하지 않아도 될 만큼 좋은 비즈니스 모델이라는 이야기니까. 하지만, 이로 인해서 소셜의 연결고리가 다시 끊어지만 다시 소셜은 사라지고 Group Buying만 남는다. 이것이 아마 현재의 소셜 커머스의 선두 업체들이 직면한 문제일 것이다.

여기서 단지 시스템적으로만 소셜을 강화한다고 소셜 커머스가 되지는 않을 것이다. 티켓몬스터에 트위터 연결하고 페이스북 연결해서 소비자들끼리 deal에 대한 커뮤니케이션을 하기 쉽게 시스템으로 제공할 수는 있다. 하지만 지금의 비즈니스 모델 하에서라면 입소문 마케팅이 조금 강화되는 것 이상의 효과를 얻기 힘들 것이고, 오히려 블로그 마케팅이 블로그를 변질시켜 블로그의 신뢰도를 떨어뜨린 것처럼 스팸으로 소셜 생태계를 위협할지도 모른다. 소셜 네트워크 게임이 보여준 페이스북 스팸을 아직 잊지 않았을 것이다. 마찬가지로 상품 추천으로 가득한 페이스북을 상상해보라. 이것이 내가 소셜 커머스를 조심스럽게 접근하고 싶은 이유다.

요컨대, 소셜 커머스로 출발한 Group Buying이 성장하고 주목받으면서 오히려 소셜이 희미해지고 있다는 얘기다. 물론 이것은 문제라기보다는 가능성의 관점에서 봐야 한다. 현재의 소셜 커머스는 아직 소셜의 잠재성을 제대로 발굴해내지 못했는데도 이만큼 성장했다. 그러니까 소셜을 제대로 파보면 더 큰 가능성이 숨어 있지 않을까?

---

 

블로그 / 스타트업

 

의사소통을 잘한다는 건 뭘까? 단순히 말을 잘하고 잘 듣는 건 아닐 것이다. [미국 최고의 교수들은 어떻게 가르치는가]를 읽으면서 가장 크게 다가온 것은 학습자 중심의 사고다. 잘 가르치는 것보다 학습자가 잘 배우는 것이 더 중요하며 그것이 좋은 교수인지 아닌지를 가르는 기준이라는 이야기였다. 의사소통에도 똑같이 적용할 수 있다. 의사소통을 잘하는 것은 단지 청산유수처럼 설득력 있게 말하는 것만이 아니다. 그보다 더 중요한 것은 말하는 내용이 상대방에게 잘 전달되는 것이다. 핵심 키워드 다 빼먹고 대명사만으로도 내용을 다 전달할 수도 있고 흠 잡을 때 없는 완벽한 연설로도 의사소통에 실패할 수 있다. 그렇다면 좋은 의사소통의 조건은 무엇일까?

이런 말이 있다. 재능 있는 자는 열심히 하는 자를 이길 수 없고 열심히 하는 자는 즐기는 자를 이길 수 없다. 학습에 관해서도 비슷하다. 좋은 학습이 이루어지기 위해 가장 중요한 것은 학습에 대한 흥미를 유지하는 것이 무엇보다 중요하고 효과적이다. 그런 면에서는 의사소통도 마찬가지일 것이다. 좋은 의사소통이 이루어지려면 화자와 청자 모두 대화에 흥미를 유지하는 것이 중요하다. 길고 지루한 연설을 하면서 청자에게 단지 열심히 집중해서 듣기를 요구하는 것은 좋은 의사소통이 될 가능성이 낮다. 물론 공부를 좋아하지 않지만 단지 열심히 하기만 하는 사람도 좋은 대학 가는 걸로 봐서 지루함을 극복하는 능력이 좋은 사람들은 일장연설에서도 충분히 내용을 흡수할 수 있을 것이다. 하지만 단지 열심히만 하는 사람이 공부에 흥미를 느껴서 즐겁게 하는 사람을 이길 수는 없다. 그리고 세상에는 지루함을 견디는 능력이 부족한 사람이 아주아주 많이 존재한다.

그래서 길고 장황한 연설은 그 자체로 나쁠 수 있다. LongSpeeches 에서도 이 점을 지적하고 있다. 아무리 조리 있는 연설이라도 길어지면 청자를 지루하게 만든다. 사람들이 무언가 자신의 주장을 펼칠 때는 주장만 내세우는 것보다는 부연 설명을 꼼꼼하게 하는 것이 더 설득력 있을 꺼라는 기대를 하는 경향이 있다. 그래서 모든 반론의 가능성을 미리 생각해서 조심스럽게 주장을 펼치고 논리적 허점이 없는 완벽한 연설을 하려 애쓴다. 하지만 부연 설명 한 마디 할 때마다 조금씩 청자는 지루함의 부담을 느끼기 시작한다. 서로에 대한 신뢰가 부족한 조직이라면 상대방의 말을 쉽게 끊을 수 없기 때문에 이 부담은 더 커진다.

이런 현상은 의사소통을 보다 길게 보면 극복할 수 있다. 한 번의 발언으로 내 모든 뜻이 전달되기를 바라는 것은 욕심이다. 의사소통도 incremental하게 할 수 있고 또 그것이 효과적인 경우가 많다. 양쪽 모두 화제에 대해 이해가 깊고 생각이 비슷하다면 긴 의사소통은 필요 없다. 염화미소만으로도 의사소통이 가능하다. 물론 화제에 대한 이해의 정도가 다르거나 생각이 다르다면 한 번의 발언으로는 의사가 충분히 전달되지 않을 것이다. 하지만 오히려 짧고 부족한 발언은 청자의 발언을 유도한다. 이해가 가지 않는 부분에 대한 질문, 동의하지 않는 내용에 대한 반론. 그래서 청자에게 추가적으로 필요한 정보를 다시 화자가 줄 수 있게 유도한다. 화자가 모든 반론의 경우를 다 예상해서 부연 설명으로 가득 채우면 청자는 자신이 원하지 않는 정보까지 들어야 하지만 짧은 주장만 나온다면 청자는 자신이 원하는 부연 설명을 요청할 수 있다. 말하자면 CommunicationOnDemand 같은 것이 될 것이다. 이런 방식으로 의사소통에서 생기기 쉬운 지루함을 쉽게 줄일 수 있다. 필요한 말만 하면 되기 때문에 의사소통 비용도 줄어든다. 또한 완벽한 연설을 해야 한다는 부담을 떨치면 화자도 좀더 편안하게 하고 싶은 말을 할 수 있다.

이 방식의 또다른 장점은 서로의 코드를 맞춰나가기 쉽다는 것이다. 일방적인 연설이 아니라 짧은 대화가 오가다 보면 서로의 생각의 차이가 금방 드러난다. 긴 연설 중에는 서로의 생각의 차이가 청자에게만 노출되고 또 그 차이가 여러 개일 경우 다 기억하기도 어렵지만 짧은 대화가 오가면 생각이 비슷한 화제는 금방 종결될 것이고 생각이 다른 부분이 금방 드러나고 거기에 집중할 수 있다. 그래서 그 충돌의 해소에 빨리 접근할 수 있다.

Communication은 의사전달이 아니라 의사소통이다. 대화가 일방으로 흐른다면 그건 의사소통이 아니라 그냥 의사전달일 뿐이다. 그런 면에서 회의에 발언하지 않는 사람이 있다는 것은 팀에 심각한 문제가 있다는 뜻이다. 회의는 철저하게 그 회의에 흥미를 느끼는 사람으로만 구성되어야 한다. 회의에서 한 사람이 오랫동안 발언하는 것도 마찬가지다. 그것 뿐 아니라 한 사람씩 돌아가면서 말하는 것도 좋지 않은 경우가 많다. 돌아가면서 말을 하게 되면 흥미가 생기는 주제에 대해 말하는 것이 아니라 자신이 할 말을 생각해서 하게 되기 때문에 다른 사람의 말을 듣지 않게 된다. 말하면서 다들 뿌듯함을 느낄 수도 있겠지만 과연 끝나고 나서 무엇이 남는가는 고민해 봐야 할 것이다.

나는 이제 이런 문제를 많이 극복한 것 같다. 예전에는 완벽하게 머리 속에서 논리가 완성되지 않으면 발언하지 않는 경우가 많았는데 팀웍이 잘 맞는 사람들과 한동안 일을 하게 되면서 speech의 필요성이 극도로 줄어들었고 그러다보니 필요한 말만 하는 습관이 생겼다. 처음에는 그런 습관이 코드가 안 맞는 사람들에게도 유효할지 의문이었는데 이제는 유효하다는 결론을 내려도 될 것 같다.

그리고 창희형에게 배운 아주 훌륭한 표현, '멍'. 이것도 정말 훌륭한 CommunicationTrigger인 것 같다.

---

 

블로그