“왜 그렇게 짰나요?” 실리콘밸리는 이렇게 묻는다.

코딩 실력보다 ‘문제를 푸는 사람’을 보는 기술 면접 이야기

미국에 온 지 얼마 되지 않았을 때 실리콘밸리의 한 스타트업 CTO와 저녁식사를 한 적이 있다. 이런저런 이야기를 나누다가 대화주제가 '채용'으로 옮겨갔다. 그는 사람 뽑기 참 힘들다고 했다. 지원자는 넘쳐나는데 적합한 사람이 눈에 띄지 않는다는 것이다.

“우린 코딩만 잘하는 사람을 뽑지 않아요. 코드를 왜 그렇게 짰는지, 어떤 선택지를 고민했고 왜 그 선택이 최선이라 판단했는지를 말할 수 있는 사람을 뽑죠.”

처음엔 말장난처럼 들렸다. 하지만 그의 말은 진심이었다. 그 이후 내가 면접을 보거나, 면접관으로 수차례 참여하면서 그 말의 의미를 조심씩 깨닫게 되었다. 실리콘밸리의 기술 면접은 ‘실력’으로만 평가하지 않는다. '문제를 푸는 능력'을 넘어 '문제를 풀어내는 사람'을 본다.

이 코드가 최선입니까?

한국에서 수석급 엔지니어가 될 때까지 업무시 코드 리뷰라는 것을 하거나, 받은 적이 거의 없었다. 내 커리어 경로가 SW 업계에 있지 않았기 때문이다. 물론 업무상 코딩은 하긴 했다. 하지만 내가 짠 코드는 프로세서, HW의 모델인 아키텍처 시뮬레이터였다. 즉 코드 자체가 서비스나 상품으로 배포되는 일은 없었던 것이다. 시뮬레이터는 아키텍처 설계하기 위한 최적의 구조를 찾아내는 것이 주목적이기 때문이다. 시뮬레이터의 미덕(?)은 코드의 실행시간 성능이 아니라, 얼마나 아키텍처를 정확하게 모사하는지에 있다. 

인텔로 이직을 한 뒤, 전업 리서치 사이언티스트로 근무하면서도 동료 간 코드 리뷰는 그다지 하지 않았다. 연구원들은 각자만의 연구 프로젝트를 진행했다. 논문 작성 시 실험을 위한 응용을 구현하기 위해 코딩을 했지만 코드를 상호 공유하는 경우는 그다지 많지 않았다. 동료의 코드에 대해 이러쿵저러쿵 관여할 필요가 없었던 것이다.

AMD로 이직 후 본격적으로 실리콘밸리식 코드 리뷰 환경에 직면했다. 각 엔지니어들이 작성한 코드들은 커밋되기 전에, 자동화된 스모크, 유닛 테스트를 통과해야 하고, 엄격한 동료 리뷰를 거쳐 승인을 받아야 비로소 메인 저장소에 병합될 수 있었다. 

그동안 독고다이(?)식으로 코딩을 하던 터라, 동료들의 리뷰를 받는 것이 처음엔 꽤 낯설었다. 동료들은 남의 코드를 읽고 평가하는 일에 이미 익숙해 보였다. 아키텍처 팀 성격상 대부분이 다양한 업계에서 경험을 쌓은 프린시펄 엔지니어들이었기 때문이다. 

그들이 남긴 리뷰 의견에서 가장 많은 질문이 'Why'로 시작했다. "왜 이 코드는 이렇게 작성되었는가?' 즉 코드에 담긴 의도가 무엇인지를 묻는 질문이었다. 하지만 리뷰 의견이 달린 코드에 솔직히 의도 따위 1도 없는 경우가 많았다. 굳이 이유를 대자면 '내 스타일이니까', '코딩의 편의성 때문', 심지어 '귀찮아서'였을 수도 있다. 

그의 의도드립은 실리콘밸리에서도 요구되는 만고의 진리, 사진출처 = 흑백요리사

업계에서 오랫동안 코딩을 하면서, 내가 가장 추구했던 가치는 '코딩의 신속성'과 '결과의 정확성'이었다. 쉽게 말해 '돌아가는 코드를 빠르게 작성하는 것'이다. 늘 스케줄에 쫓기며 결과를 내야 했기에 어느샌가 그런 스타일이 굳어져 버린 것이다. 

하지만 실리콘밸리에서 코딩으로 먹고살려면 적어도 이런 식의 일처리는 지양해야 했다. 즉 자신이 작성한 모든 코드 한 줄 한 줄에는 그 '이유'가 있어야 하는 것이다. 그리고 그 이유는 항상 '최선'이어야 한다. 즉 정확한 결과가 나오는 것만큼이나, 그 결과를 도출하는 과정에서 '효율성'을 추구하는 것이 무엇보다 중요하다. 그것이 곧 엔지니어의 진짜 실력이고, 면접 시 중점적으로 확인하는 역량이다. 그 이후로는 코딩할 때마다 ‘정말 이것이 최선인가?’를 스스로에게 묻는 습관이 생겼다.

문제 해결 능력의 본질

흔히들 실리콘밸리의 기술 면접 시 가장 중요하게 보는 것이 후보자의 '문제 해결 능력(Problem Solving)'이라고 한다. 하지만 이는 단순히 주어진 문제를 빠르게 푸는 것을 의미하는 것이 아니다. 가장 '효율'적인 과정을 거쳐 문제를 해결했는지가 더 중요하기 때문이다. 이것이 앞에서 말한 '문제를 풀어내는 것'이다.

출간한 책에서도 언급했지만, 이는 실리콘밸리에서는 사람을 채용할 때 한 분야의 전문가를 찾기 때문이다. 팀원 한 명 한 명은 모두 자신만의 전문성을 갖고 있다. 따라서 신입이라고 해서 사수-부사수처럼 도제식으로 일일이 일을 가르치지 않는다. 각자에게 주어지는 문제에 대해서는, 최선의 결과를 최선의 과정을 거쳐서 알아서 도출해야 한다. 팀은 팀원 모두가 이렇게 업무에 임할 것이라는 암묵적인 믿음을 갖는다. 

주어진 문제를 풀어내기 위해 '최선의 과정'을 거치기 위해서는 스스로 다양한 방법을 찾아야 한다. 혼자 해결하기 어려운 상황에 직면하면, 문헌을 찾거나, 나보다 나은 팀원을 찾아가 조언을 구해야 한다. 이 과정에서 협업과 소통 능력이 절대적으로 필요하다. 내가 누군가의 도움을 받기 쉬운 사람이 되기 위해서는, 평소 누군가 내게 도움을 구할 때 (내 시간을 잘 활용하여) 잘 도와줘야 한다. 

바쁜 누군가의 도움을 받기 위해서는 '질문'에도 기술이 필요하다. 질문을 잘한다는 것은 단지 '모른다고 말하는 것'이 아니다. 한국에서 이직한 경력자가 실리콘밸리 엔지니어 커리어를 쌓아가며 가장 먼저 마주하게 되는 딜레마 중 하나가 바로 '질문하기의 어려움'이다. 코드를 짜다 막혔을 때, 동료의 코드가 이해되지 않을 때, 미팅 중 요구사항이 명확하지 않을 때 질문은 언제나 머릿속에 맴돈다. 하지만 아무 때나 아무 식으로 던질 수는 없다. 특히 실리콘밸리 문화에선 '질문을 잘하는 사람'이 바로 좋은 동료로 여겨진다. 왜일까?

실리콘밸리에서는 협업이 곧 생산성이기 때문이다. 개인의 똑똑함보다 중요한 건, 내가 어떻게 질문을 던지고, 그 질문이 얼마나 효율적으로 문제를 좁혀나가는 가다. 이를 위해서는 질문에 1) 충분한 배경(맥락), 2) 구체적인 목적, 3) 상대의 시간에 대한 존중이 담겨야 한다. 이렇게 엔지니어가 질문을 잘하면 문제를 피하지 않고, 맥락을 이해하려 노력한다는 인상을 줄 수 있다. 그리고 덤으로 '이 사람에게 도움을 주면, 나도 언젠가 도움을 받겠구나'라는 긍정적인 평판까지 얻을 수 있다.

결국 문제 해결 능력의 본질은 최선의 답을 찾는 과정에서 동료들과 잘 소통할 수 있는가다. 그리고 원활한 소통을 위해서는 '질문 능력'이 뒤따라야 한다. ‘질문도 실력이다’라는 말은 단지 수사적 표현이 아니다. 좋은 질문은 깊은 고민에서 나온다. 진짜 궁금한 것이 무엇인지 스스로 구조화해 본 사람만이 명확하게 물을 수 있기 때문이다. 

그것이 실리콘밸리 전 엔지니어 직군의 기술 면접에서 후보자에게 공통으로 확인하는 문제 해결 능력이다. 결국 실리콘밸리의 기술 면접은, “무엇을 아는가”보다 “어떻게 풀고, 왜 그렇게 했는가”를 말할 수 있는 사람을 고른다. 실리콘밸리의 기술 면접은 결국 묻는다.

 “당신은 문제를 어떻게 바라보고, 어떻게 풀어낼 사람인가요?”

- 예나빠

* 차주에는 출장관계로 업로드가 없음을 말씀드립니다. 꽃피는 4월에 다시 찾아뵙겠습니다.

표지 이미지 출처 = unsplash

글로벌 엔지니어 커리어 안내서 <실리콘밸리가 원하는 사람>을 지금 온라인 서점에서 만날 수 있습니다.

Yes24: https://www.yes24.com/Product/Goods/141895946

실리콘밸리가 원하는 사람 - 예스24

알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=356547658

교보문고: https://product.kyobobook.co.kr/detail/S000215622588

엔지니어 커리어에 관해 질문 있으시면 언제든 아래 글에 댓글 남겨주시기 바랍니다.

질문받겠습니다.