brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 박태웅 Jan 06. 2020

사람을 뽑습니다

동료를 뽑는 기준

푸드테크에서 개발자를 뽑습니다

태도가 능력이다

우리 회사에서는 1차 면접을 부사장인 제가, 2차 면접을 CTO와 해당 팀장이 봅니다. 최종 결정은 함께 일할 동료들이 하는게 좋겠다는게 저희의 판단입니다.

저는 태도(Attitude)를 먼저 봅니다. “태도가 능력이다”라고 저는 생각합니다. 이것은 마치 X제곱과 aX의 관계와도 같은데, 1이 되기 전까지는 aX가 훨씬 먼저 도착하지만, 그 이후에는 시간이 갈수록 비교할 수 없이 격차가 벌어지게 되는 것과 같습니다. ‘기울기를 결정하는 것은 태도’라는 것이지요.

비슷한 의미로 “친절한가?”도 중요한 요소로 판단합니다. 자신에 대한 애정과, 그에 바탕한 타인을 향한 배려가 친절을 만듭니다. 회사라는 조직에서 혼자 하는 일은 사실상 없습니다. 협업은 그래서 모든 일의 기본이 됩니다.

예를 들어 회사 인력의 평균 역량을 100이라고 합시다. 개인 역량이 150인 사람이 있습니다. 그런데 이 사람은 ‘남의 사정’을 잘 헤아리지 못해 커뮤니케이션이 서툴고, 친절하지도 않아 다른 사람들의 역량에 -20%씩 영향을 미칩니다. 이 사람이 다섯명으로 구성된 팀에 들어갔다고 합시다. 그가 들어오기전 이 팀의 평균 역량은 110이었습니다. 이 친구가 들어와서 개인역량으로 +50을 보탭니다. 대신에 나머지 다섯명의 역량에 -20%의 영향을 미칩니다. 110 X 5 X - 0.2 = -110이 됩니다. 둘을 합하면 -60. 개인역량이 150인 사람이 들어왔지만, 조직 전체의 역량은 더 낮아져 버린 것입니다.

개발에 대한 생각도 들여다 봅니다. ‘개발하는 일을 사랑하는’ 사람을 뽑고 싶은건 당연한 일이겠지요.

CTO와 해당 팀장의 면접은 주로 기술면접입니다. 개발을 어떻게 해왔는지, 전문지식과 경험은 어느 정도인지를 확인합니다. 상당한 수준으로 꼼꼼히 묻습니다.

일을 할수록 스마트해진다

‘1년차 일을 10년 한 개발자’라는 말이 있습니다. 10년째 개발을 하고 있지만, 몸에 쌓인 실력은 1년차와 비슷한 경우를 말합니다. 드물지 않게 볼 수 있습니다.

일을 할수록 스마트해지게 할 수가 있습니다. 푸드테크의 R&D센터의 지향점입니다.

소나큐브와 같은 정적분석도구를 제대로 쓴다면 잘못된 습관을 고칠 수 있습니다. 좋은 코딩 컨벤션을 몸에 익힐 수 있지요.

동료들과 코드 리뷰를 하는 습관을 들이면 함께 배울 수 있습니다. 후배들에게서도 배울 점을 찾을 수가 있다는 것도 알게 됩니다.

지속적 통합(CI)과 지속적 배포(CD)를 통해, 고품질의 코드를 생산하고 위험을 사전에 제거하는 방법을 배울 수 있습니다.

아마존의 베조스가 왜 “아마존 내부의 모든 팀들은 오직 서비스 인터페이스로만 소통해야 한다”라고 선언했는지를 이해합니다. 이것만으로도 개발조직을 한단계 업그레이드할 수 있습니다.

https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

핵심내용은 아래와 같습니다.

All teams will henceforth expose their data and functionality through service interfaces.

Teams must communicate with each other through these interfaces.

There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn’t matter what technology they use.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

The mandate closed with:

Anyone who doesn’t do this will be fired. Thank you; have a nice day!

개인적으로는, 제대로 알든 모르든 일단 개발자 블로그를 시작하고, 오픈소스에 기여하면 많은 동료 개발자들로부터 큰 도움을 받을 수 있습니다. 때로 가르치는 것이 가장 좋은 학습법이 됩니다.