무엇이 탁월한 개발자를 만드는가

며칠 전 열렸던 인프콘 2023을 위해 주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드라는 긴 제목의 발표를 준비하면서 이건 꼭 별도의 글로 정리해서 남겨야겠다고 다짐했습니다. 제가 지나치게 욕심을 부려 정보 밀도가 너무 높아진 탓에, 메인 타겟이었던 주니어가 발표 내에서 흡수하기 무척 어려웠을 것이기 때문이죠.

그래서 시간을 고려하지 않고 만들었던 최초의 가장 긴 버전, 발표 직전까지 더 나은 가독성과 이해를 위해 수정된 버전, 그리고 발표 후 느낀 바가 있어 주니어를 위해 새로 준비한 것 3가지를 섞어 일종의 시리즈물을 기획했습니다.

파트 1 - 무엇이 탁월한 개발자를 만드는가는 인프콘 발표의 1부를 토대로 합니다. 탁월한 개발자가 되기 위해 어떤 노력을 하면 될까요? 2015년 논문 <What Makes a Great Software Engineer?>를 자세히 파헤치면서 탁월한 개발자의 5가지 필수 요건에 대해 설명합니다. 그리고 이 지식을 주니어와 시니어, 프론트엔드의 관점에서 어떻게 써먹을지 논합니다.

파트 2 - 문제 해결과 역량 향상을 위한 이론과 사례는 인프콘 발표의 2부를 토대로 합니다. AC2와 책, 논문 등에서 배운 지식을 바탕으로 제가 효과적 문제 해결과 역량 향상을 위해 코칭할 때 써먹고 있는 각종 프레임워크의 이론적 기반을 실제 사례와 함께 설명합니다.

파트 3 - 날마다 성장하고픈 주니어를 위한 ‘프론트엔드 엔지니어 커리어 로드맵’ 해설은 새로 구상한 것입니다. 어쩌면 가장 원 발표 제목에 어울리는 내용이었을지도 모르겠는데요. 파트 1과 파트 2, 프론트엔드 엔지니어 커리어 로드맵을 토대로 주니어들이 압축성장을 위해 일상적 활동을 구체적으로 어떻게 다르게 해볼 수 있을지, 어떤 시스템을 구축하면 좋을지 사례 위주로 설명할 예정입니다. 장기적으로는 탁월한 개발자가 되는 데에, 단기적으로는 내 눈앞에 닥친 일을 더 잘 해내게 되는 데에 도움이 되길 기대합니다.

이번 레터는 파트 1의 요약본입니다. 요약인데도 상당히 기네요. 전문은 블로그에서 보실 수 있습니다.

탁월한 엔지니어는 어떤 사람일까?

Li Paul Luo는 2015년 논문 <What Makes a Great Software Engineer?>에서 탁월한 엔지니어를 만드는 5가지 필수 요건을 제안했다. 연구 방법은 다음과 같았다.

저자가 제안한 5가지 필수 요건의 순서와 해석을 조금 달리 하여, 내 생각을 덧붙여 정리해봤다.

1. 훌륭한 코드를 짠다(Be a competent coder)

‘유능한 코더’보다는 ‘훌륭한 코드’가 더 목표로 삼기 좋다.

코딩 실력은 주니어에게 가장 중요한 역량이다. 그러나 일정 수준을 넘어가면 다른 역량을 키우는 노력이 더 효율적이다. 이 ‘일정 수준’은 사람마다, 조직마다 다르다.

나는 주니어의 코딩 실력을 판가름하는 기준을 ‘1) 코드 품질에 대한 자신만의 일관된 관점을 갖고, 2) 고객 요구사항을 만족하는 코드를, 3) 빠른 속도와, 4) 적은 버그로, 5) 가독성 있게 작성한다’ 로 보고 있다.

2. 근거 기반 의사결정을 연습한다(Practice informed decision-making)

의사결정 역량을 기르려면 의사결정의 결과보다는 프로세스를 개선하는 데 집중하는 게 더 유리하다. 결과는 내 의지와 상관없이 정해질 수 있기 때문이다.

그리고 근거 기반이란, 데이터에 기반하되 데이터를 편견에 빠져 해석하거나 성급하게 결론내리지 않는 걸 뜻한다. 특히 새로운 정보를 얻었다면 마음이 내키지 않더라도, 합리화하지 말고 기존의 판단을 재고하는 게 좋다.

특히 디버깅할 때, 내가 아니라 라이브러리나 브라우저가 문제라고 생각하면 대부분 틀린다. 만약 브라우저 문제가 맞았다 한들, 그와 유사한 모든 문제를 브라우저 탓으로 치부해버리면 정말 내 실수로 벌어진 치명적인 문제도 무시해버릴 수 있으니 주의해야 한다.

편견이나 성급함을 피하는 한가지 방법은 다양한 외부 관점을 열린 마음으로 받아들이는 것이다. 잠깐 숨을 돌리고 친구, 동료, 고객, 경쟁자, 상사 등 다양한 사람들이 사안을 어떻게 해석하는지 보면 나의 편견이 유지되기 어렵다.

물론 사람이 스트레스를 받으면 이성적으로 행동하기 어렵다. 조직도 마찬가지. 그래서 현명한 조직들은 일부러 일정과 리소스에 여유를 두고, 현명한 개인은 명상 등을 통해 스트레스를 관리하는 방법을 익힌다.

근거 기반 의사결정을 평소에 연습하려면 좋은 근거를 많이 가지고 있어야 한다. 다양한 양질의 정보가 내 주변에서 지나가게 하는 시스템을 구축해두면 좋다. 뉴스레터를 구독하고, 커뮤니티에 소속되고, 스터디 모임에 참여하는 식으로.

3. 동료의 효과적 의사결정을 돕는다(Enable others to make decisions efficiently)

탁월한 개발자는 정보와 경험을 공유하여 동료를 성장시키고, 팀의 생산성을 높이고, 결과적으로 조직이 더 나은 의사결정을 할 수 있도록 돕는다.

그러면 주니어는 어떻게 할까. 주니어는 당장 성과를 내기보다는, 질문하여 성장하는 게 동료를 돕고 조직을 돕는 것이다. 저평가와 거절과 민폐의 두려움을 이겨내 고맥락 질문을 하라. 보통은 신뢰를 쌓아야 이러한 취약성을 드러낼 수 있다고 생각하는데, 실제 연구를 보면 거꾸로다. 서로 약점을 보이고 용기있게 위험을 감수할 때 신뢰의 토대가 빠르게 형성된다.

취약성도 잘 드러내는 방법이 있다. 맥락을 잘 포함해야 한다. 주니어들은 보통 A라는 문제가 있어서 B를 시도해보고는, 그 안에서 C가 잘 안 되면 C만 물어본다. 이렇게 하면 대개는 굉장히 지엽적인 대답만 얻고, 그 대답을 얻어도 문제 해결이 잘 안 된다. 거꾸로, A를 제대로 설정하고 나면 B가 자동으로 나와서 C가 필요없어지는 걸 자주 봤다.

질문을 장려하려면 취약성과 투명성에 큰 가치를 두는 조직문화를 마련해야 한다. 이 때 조직 내 디폴트값을 뭘로 두느냐가 상당히 중요하다. 디폴트값이 사람의 인지와 행동에 굉장히 큰 영향을 주기 때문.

이런 면에서는 숨기려면 액션을 해야 하는 Public by Default 도구(Slack, Notion)가 공유하려면 액션을 해야 하는 Private by Default 도구(Email, Google Docs)보다 낫다. "언제든지 말을 걸어도 되는데 이 때만 피해달라(Do Not Disturb)"가 “이 때는 자유롭게 와서 말 걸어도 된다(Open Hours)”보다 낫다.

4. 작업의 현재 가치를 극대화한다(Maximize current value of your work)

탁월한 개발자에게는 시스템적 사고(나중에 문제가 될 만한 부분이나, 요구사항이 어떻게 변할지 예측하여 장기적 관점에서 구현)와 당장 움직이기(분석하느라 멈춰있지 말고, 불확실성이 두려워도 일단 뛰어들어 실행하여 피드백 받기) 둘 다가 요구된다.

특히 스타트업에서는 후자가 더 유리하지만, 극단에 치우치면 불리해진다. 빠른 실행에 주력하되, 조금만 노력해도 큰 이득을 주는 행동을 습관으로 만들어두면 좋다.

미시적 예시는 값이 하나더라도 하드코딩해두지 말고 변수로 빼놓는다거나, 값이 지금은 두개밖에 없더라도 그게 한 컴포넌트를 넘어서는 종류의 옵션이라면 Boolean 값 대신 Mode를 사용하는 게 있다. 거시적 예시는 내가 어떤 가설을 검증하기 위해 실행하는 건지 생각해보고, 검증을 어떤 데이터로 할지 생각해보고 실행해보는 습관이 있다.

결국 내 의지로 시스템적 사고와 당장 움직이기 둘 사이를 유연하게 오갈 수 있을 때 작업 가치가 극대화된다.

5. 효과적으로 꾸준히 학습한다(Continuously learn)

효과적으로 학습하는 법을 학습하는 게 모든 성장의 시작이다. 일찍 할수록 좋은, 복리 이득을 주는 행위다.

학습이란 결국 나의 지식을 넓혀 삶을 변화시키기 위한 것이다. 그런데 오래된 지식이 지금도 유효하리라는 보장이 없으니 언제나 새 정보로 갱신하는 노력이 필요하다.

그러나 정보가 많다고 무조건 좋은 건 아니다. 정제되지 않은 빅데이터처럼, 어떤 정보들은 있으면 방해만 된다. 따라서 부정확하거나 내 문제와 관련 없는 ‘소음’ 대신 ‘신호’의 비율을 높여야 한다. 나의 전문 도메인이 아닌 곳에서 내 기존 지식과의 연결점을 만들어주는 통찰, 또는 내가 특정 조건에서 틀렸을 수 있다는 증거들이 좋은 신호의 예시라고 본다.

효과적 학습은 ‘어떻게 하면 내가 매일 조금씩 더 효과적으로 자랄 수 있을까?’ 라는 질문으로 요약할 수 있다. 그 답은 1) 지금 당장 현실에서 내게 필요한 걸 찾아보고, 2) 관련된 이론적 근거를 딱 필요한 만큼만 학습하고, 3) 배우자마자 즉시 써먹어 셀프 피드백 받는 걸 반복하는 것이다.

그럼 지금 당장 현실에서 내게 필요한 건 어떻게 알까? 일기를 써서 일상에서 내가 겪는 문제를 발견할 수도 있고, 지난 한주간 많은 시간을 쓴 활동을 더 잘 하기 위해 노력해볼 수도 있다. 예를 들어 취준생이라면 스터디를 자주 할테니 스터디를 효과적으로 하는 법을 연구하면 도움이 된다. 자주 하는 걸 것일수록 학습 기회도 더 많고, 개선시 삶의 질 상승폭도 더 크다.

어떻게 써먹을 것인가 - 주니어와 시니어의 관점

주니어는 이 목표들 하나하나를, 특히 "훌륭한 코드 짜기"와 "효과적으로 꾸준히 학습하기"에 묘사된 지식과 행동에 본인이 얼마나 부합되는지 체크해보면 좋다. 그리고 부족한 역량을 집중해서 계발한다.

그리고 시니어라면 이것들을 채용 평가와 성과 평가에 쓸 수 있다. 지원자가 이 역량을 충분히 가졌는지를 어떤 신호로 판별할지 고민해본다. 주니어의 역량을 높이기 위해 리드할 때에도 비슷하게 써먹을 수 있을 것이다.

그리고 이 역량들은 ‘훌륭한 코드 짜기’만 특정 도메인의 전문성으로 교체하면 어떤 직군을 평가하더라도 좋은 기준이 되어준다. 그래서 실제로 XL8에서는 PM이든, 디자이너든, 개발자든 사람을 채용하고, 온보딩해서 피드백할 때 최대한 이것들을 기준으로 역량 평가를 하고 있고, 상당히 큰 효과를 보고 있다.

활용시 주의할 점

이 5가지 역량들은 모두 상호보완적이다. 다 엮여있기 때문에 하나만 잘 키우기 위한 목표를 삼는 건 그리 효과적이지 않을 수 있다. 거꾸로 말하면, 하나만 잘해도 다른 것들을 더 잘하게 되기 수월해질 수도 있지만.

그리고 이 연구는, 여타 연구들과 마찬가지로 절대적 진리가 아니다. 당연히 한계가 있고, 논문 저자의 해석과 나의 해석을 거쳤다는 것도 감안해야 한다.

또한 논문의 제목이 '무엇이 탁월한 개발자를 만드는가?' 였기 때문에, 다섯 가지 역량을 갖추면 탁월한 개발자가 될 것이라는, 즉 충분조건이라는 생각을 할 수도 있다. 그러나 실제로 연구된 건 '이게 없으면 탁월한 개발자라고 할 수 없다', 즉 필요조건이다. 따라서 이것들을 좋은 목표이자 지향점, 또는 경유지로 삼는 것은 괜찮지만 최종 목적지로 볼 필요는 없다.

어떻게 써먹을 것인가 - 프론트엔드 개발자의 관점

이 5가지 역량을 프론트엔드 개발의 맥락에서 활용하기 위해 이런 질문들을 던져볼 수 있다.

이런 질문에 대해 답하는 방법을 고민하다가 나온 게 프론트엔드 엔지니어 커리어 로드맵이다. 프론트엔드 개발자에게 조직이 기대하는 역할을 웹/제품/운영 특화 트랙으로 구분하여 트랙별 주요 특징과 장단점을 설명한 것이다. (인프콘 발표에서는 이 내용이 완전히 빠졌는데, 이번 시리즈물의 3부에서 좀더 제대로 보강하여 해설 예정입니다.)

이 로드맵 또한 주니어와 시니어의 맥락에서 써먹어볼 수 있다.

예를 들어 프론트엔드 주니어들은 사전 조사 또는 면접 질문으로 해당 회사의 상태를 파악 한 뒤, "내가 가고 싶은 이 조직에서는 이런 전문성을 원하는구나. 이 전문성을 내가 잘 키우고, 잘 드러내면 채용될 가능성이 높아지겠네."와 같이 구직할 때 써먹을 수 있을 것이고,

시니어라면 "우리 조직에는 이런 전문성을 가진 사람이 부족한 상태다. 그러니 이 친구가 이 전문성을 계발할 수 있게 돕자. 그리고 이 전문성을 가진 사람을 잘 판별해서 채용해보자."와 같이 이렇게 구성원을 성장시키고 채용할 때 써먹을 수 있다.

물론 위의 논문과 마찬가지로 3가지 트랙이 상호보완적이며, 절대적 진리도 아니고, 최종 목적지도 아니라는 건 염두에 두어야 한다.

탁월한 시니어 개발자 되기

프론트엔드 엔지니어 커리어 로드맵에서는 탁월한 시니어 개발자가 되는 방법에 대한 내 생각도 간단히 언급했다.

(‘파트 2 - 문제 해결과 역량 향상을 위한 이론과 사례’ 에서 이어집니다.)