2023년. 열세번째글. 좋은 엔지니어란 무엇일까
what makes a good engineer
최근에 한 파운더와 이야기를 하는데 나한테 어떤 엔지니어가 좋은 엔지니어라고 생각하냐고 물어본 적이 있었다. 언뜻 보면 되게 간단한 질문인데, 막상 답을 하기는 또 쉽지 않다. 코딩을 잘하는 사람? 사람들과 같이 일을 잘하는 사람? 아니면 성공한 feature 나 프로덕트를 만들어 낸 사람? 아니면 다 잘하는 사람? 사실 모든 테크 회사의 가장 큰 고민 중 하나가 엔지니어들의 performance review인 만큼 “좋은” 엔지니어를 정의한다는 게 결코 쉬운 것은 아니다.
그래도 일을 하다 보면 “저 친구는 진짜 잘한다.” 하는 엔지니어들이 주변에 있는데, 물론 연차와 직급에 따라 기준이 많이 다르지만, 각 레벨마다 잘하는 사람들을 보면 확실히 레벨을 불문하고 공통점들이 있는 것 같다.
1. 일단 코딩을 잘해야된다
결국 코딩, 소프트웨어를 만드는 게 직업인 만큼 먼저 코딩을 잘해야 한다. 일단 코딩을 잘하려면 기본기가 튼튼해야 된다. 물론 대학교 advanced algorithm 클래스에 나올법한 어려운 것들을 다 알아야 한다는 게 아니라, 기본적으로 많이 쓰는 data structure에 대해, 각각 어떤 특징들이 있는 정도는 알고 있어야 한다는 것이다 (꼭 코딩 인터뷰에 어느 정도 알고리즘, 데이터 스트럭쳐에 관한 질문이 나오는 이유가 여기에 있다). 이런 개념이 확실해야 쓸데없는 일을 안 하는 효과적인 코드를 쓸 수 있다.
또 중요한 부분은 코드의 readability이다. 얼마나 코드가 읽기 쉬운지를 말하는 건데, 좋은 코드일수록 다른 사람이 봤을 때 이해하기 쉬워야 하고, 그래야 다른 사람들이 더 쉽게 기능을 추가하고 관리하는 데 어려움이 없다. 간혹 똑똑한 엔지니어는 남들이 흉내 낼 수 없는 코드를 쓴다고 착각하는 경우가 있는데, 그런 코드는 아무리 잘 돌아가도 좋은 코드가 아니다. 나도 주니어 때 이런 착각을 했었던 적이 있다. 예전에 같은 팀 시니어 엔지니어 중 한 명이 Ph.D 출신으로 소위 말하는 ‘천재’였는데, 처음 그 친구가 썼던 코드를 보고 감탄한 적이 있었다. 정말 복잡한 시스템을 구현해 놓았는데 주니어 한 나는 감히 이해하지 못하는 코드였다. 그 당시에는 그 친구가 천재여서 대단하다고 생각했다… 하지만 시간이 지나서 그 친구는 팀을 떠났고 남은 팀원들이 이제 그 부분을 맡는 상황이 왔는데, 봤더니 아무도 그 코드를 제대로 이해하지 못했고 심지어 여러 버그가 나와도 코드가 너무 복잡해서 아무도 쉽게 고치지를 못하고 있었다. 결국 우리는 시간을 들여서 그 부분을 처음부터 다시 만들었어야 했다. 바보같이 간단한 코드가 천재적으로 보이는 코드보다 훨씬 실제에서는 유용하다. 물론 예외는 있지만 99%의 소프트웨어를 만드는 데에 있어서는 쉬운 게 최고다.
마지막으로 ‘좋은’ 코딩의 기준은 스피드인 것 같다. 결국 모든 프로젝트는 타임라인이 있고 제한된 시간 안에서 최대한 많은 것을 만들어야 한다. 아무래도 코드 퀄리티를 생각하고 더 ‘좋은’ 코드를 쓰려면 시간이 더 오래 걸릴 수밖에 없다. 하지만 아무리 좋은 코드라도 주어진 시간 안에 원하는 바를 다 못 만든다면 쓸모가 없을 것이다. 사실 엔지니어로서 항상 고민하는 게, 그냥 있는 데로 만들까, 아니면 시간이 좀 걸려도 refactor를 하면서 더 깨끗한 코드를 만들까인데, 좋은 엔지니어일수록 이 trade-off를 빨리 계산하고 그사이에 balance를 잘 찾는다.
2. 커뮤니케이션
엔지니어 친구들과 항상 하는 얘기가 있는데, 일을 하다 보면 코딩만큼, 아니면 코딩보다 더 중요한 게 사람들과의 커뮤니케이션이라는 것이다. 사실 연차가 쌓일수록 엔지니어로 일하는 데에 코딩이 차지하는 비중보다, 미팅에서 다른 사람들과 얘기하고, design document (주로 어떤 시스템/제품을 왜, 어떻게 만들지에 대한 보고서)를 쓰는 데 드는 시간이 점점 더 많아지는데, 잘하는 엔지니어일수록 이런 커뮤니케이션에서 차이가 확실히 느껴진다. 필요할 때는 미팅에서 직접 사람들과 대화를 통해서 일을 풀어내기도 하고, design document를 사람들에게 보내서 필요한 의견을 받기도 하고. 여기에 사람들 앞에서 presentation 하는 능력까지 뛰어나면 모두 인정할 수밖에 없을 것이다.
그리고 또 한 가지, 잘하는 사람들은 남들에게 자신이 (혹은 자기 팀이) 항상 무엇을 했고, 왜 했고, 어떤 결과가 있었고, 혹은 어떤 것을 새로 배웠는지를 꾸준히 공유한다. 이런 정보 공유가 회사 내 커뮤니케이션의 의미로도 좋지만 어떻게 보면 자기 이름을 계속 알릴 수 있는 최고의 PR이다. 이렇게 자기가 뛰어난 엔지니어라고 어필을 계속하면 나중에 리더들도 중요한 프로젝트가 있을 때 무의식적으로라도 먼저 생각하고 있을 것이다.
3. 영향력
실리콘 밸리 엔지니어들이 입에 달고 다니는 단어가 있는데 바로 “impact”다. 직역하면 영향력이라고 나오는데 주로 어떤 프로젝트나 일을 했을 때 나오는 성과, 혹은 그 성과의 크기를 나타낼 때 하는 말이다. 그래서 좋은 엔지니어 = high impact라고 볼 수 있을 것이다. 엔지니어가 결국 회사안에서 성공하려면 이 영향력을 키워야 되는 것이다.
영향력을 나타내는 데에도 여러 가지 방법이 있다. 단순하게 주어진 프로젝트를 성공시켜 좋은 결과를 통해 impact를 보일 수 있고, 아니면 큰 프로젝트에서 여러 사람을 이끌어나가는 리더쉽을 통해 나타낼 수도 있을 것이다. 좋은 엔지니어들은 코딩할 때도 이 ‘영향력’을 발휘하는데, 단순히 자기 프로젝트만을 위해서 코드를 짜는 게 아니라 어떻게 하면 최대한 많은 엔지니어가 이득을 볼 수 있을까 하는 생각에서 접근할 때가 많다. (예를 들어 사람들이 더 쉽게 test 할 수가 있는 framework을 도입한다든가, 여러 사람이 개발할 때 불편한 점이 있으면 그런 개발환경을 개선한다든지 등등).
실제로 예전에 어떤 회사 리크루터가 인터뷰에서 나한테 ‘회사에서 너의 일이 얼마나 많은 숫자의 엔지니어에게 영향을 끼치냐?’는 질문을 받은 적이 있다. 처음에는 이게 나의 엔지니어로서 능력과 무슨 상관인가 싶었지만 지금 생각해 보면 잘하는 엔지니어는 영향력을 끼치는 엔지니어의 숫자가 많을 수밖에 없고, 그게 좋은 엔지니어의 유용한 척도였던 것 같다.
결국…
결국 엔지니어도 코딩을 잘해야 한다는 것 말고는 의사소통 잘하고, 사람들에 큰 영향력을 끼칠 수 있는, 그냥 ‘일잘러’ 들이 좋은 엔지니어인 것이다. 나를 포함한 많은 엔지니어가 에세이 쓰는 게 싫어서, 정답이 있는 수학이 좋아서 컴퓨터 공학을 전공하고 엔지니어들이 된 경우가 많은데, 결국 엔지니어로서 성공하려면 내가 ‘싫어했던’ 문과적인 능력이 좋아야 한다는 게 참 아이러니한 것 같기도 하다 😂
📺 어쩌다보니 친한 친구의 Youtube에 출연하게 됐습니다!
📰 뉴스레터에서 했던 얘기를 바탕으로 이야기를 풀어봤습니다.
코맹탈출 구독과 좋아요 부탁드려요! 👍🏼