시니어+ 엔지니어를 다른 사람들과 구분 짓는 핵심 역량은 모호함을 줄이는 능력이며, 그로부터 다른 역량들이 따라온다.
사람들은 시니어 엔지니어를 거대한 체크리스트로 설명하길 좋아한다: 아키텍처, 커뮤니케이션, 오너십, 리더십 등.
하지만 직함, 연봉, 그리고 경력을 걷어내고 보면, 시니어+ 엔지니어를 다른 모든 사람과 갈라놓는 핵심 기술은 하나다: 모호함을 줄이는 것. 나머지 모든 것은 거기서 흘러나온다.
내가 말하는 바는 이렇다. 미드레벨 엔지니어는 잘 정의된 문제를 정말로 멋지게 해낼 수 있다. 명확한 스펙과 합리적인 제약을 주면, 탄탄한 결과물을 만들어낸다. 오해하지 말자, 그건 분명 가치가 있다.
하지만 그들에게 “성능을 개선해야 해”, “온보딩 플로우에 대해 사용자들이 불평하고 있어” 혹은 “스케일링을 좀 생각해봐야 할 것 같아” 같은 흐릿한 것을 건네는 순간, 그때 차이가 드러난다. 미드레벨 엔지니어가 일을 못해서가 아니라, 모호한 문제는 그 이상의 무언가를 요구하기 때문이다.
시니어 엔지니어는 크고, 지저분하고, 추상적인 것을 보고 파고들기 시작한다:
이것이 시니어 엔지니어가 그 연봉의 값어치를 하는 이유 중 하나다. 그들이 단지 좋은 코드를 쓰기 때문만은 아니다(물론 자주 그렇긴 하지만!). 그보다 프로젝트의 리스크를 줄이기 때문이다. _“이게 뭔지도 모르겠어”_를 _“작은 프로젝트 두 개와, 잘라내야 할 한 가지가 있어”_로 바꿔놓는다.
그리고 재미있는 점이 있다. 시니어 엔지니어가 이 일을 잘하면, 겉으로는 쉬워 보인다. 마치 아무것도 하지 않은 것처럼. 프로젝트가 그냥… 매끄럽게 굴러간다. 놀랄 일도, 프로덕션 화재도, 긴급 미팅도 줄어든다. 하지만 실제로는 누군가가 초반에 엄청난 ‘보이지 않는 일’을 해둔 것이다.
예를 들어, 시니어+ 엔지니어가 던지는 질문 몇 가지는 이런 것들이다:
다시 말해, 그들은 먼저 문제를 명확하게 만든다. 그리고 그때에야, 오직 그때에만, 그것을 해결하러 간다.
답답한 점 하나는 많은 회사가 여전히 이런 역량을 기준으로 채용하는 데 끔찍할 정도로 서툴다는 것이다. 채용 공고는 기술 스택과 경력 연차를 나열한다. 면접은 LeetCode에 집중한다. 하지만 그런 것들로는, 모호한 제품 요구사항을 받아서 배포 가능한 계획으로 바꾸는 능력을 제대로 측정할 수 없다.
그래서 화이트보드에서 이진 트리를 뒤집을 수는 있지만, 스펙이 반쯤만 익었을 때는 얼어붙는 “시니어” 엔지니어가 나오곤 한다.
다른 것들이 중요하지 않다고 말하는 건 아니다. 아키텍처는 중요하다. 커뮤니케이션도 중요하다. 하지만 그런 것들은 당신이 실제로 무엇을 만들고 있는지 알아낸 뒤에야 훨씬 더 가치가 커진다. 모호함을 줄일 수 없다면, 당신의 다른 기술은 그저 ‘틀린 문제’를 우아하게 푸는 방법들일 뿐이다.
그러니 당신이 시니어+ 수준으로 일하고 있는지 궁금하다면, 여기 한 가지 테스트가 있다: 누군가가 추상적/흐릿한/복잡한 것을 건넸을 때 당신은 어떻게 하는가? 다른 누군가가 명확히 해주길 기다리는가? 곧바로 코딩을 시작하고 운에 맡기는가? 아니면 초반에 시간을 들여, 당신과 팀이 자신 있게 실행할 수 있을 만큼 구체화하는가?
마지막이라면, 당신은 아마 이미 거기에 와 있다. 아니라면, 좋은 소식은 이게 재능이 아니라 연습이라는 점이다. 다음에 당신에게 할당되는 모호한 티켓부터 시작해보자.
