인프콘 2023에서 주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드라는 긴 제목의 발표를 준비하면서 이건 꼭 별도의 글로 정리해서 남겨야겠다고 다짐했다. 내가 욕심을 부려 정보 밀도가 너무 높아진 탓에, 메인 타겟이었던 주니어가 발표 내에서 흡수하기 무척 어려웠을 것이기 때문이다. 그래서 시간을 고려하지 않고 만들었던 최초의 가장 긴 버전, 발표 직전까지 더 나은 가독성과 이해를 위해 수정된 버전, 그리고 발표 후 느낀 바가 있어 주니어를 위해 새로 준비한 것 3가지를 섞어 일종의 시리즈물을 기획했다. (추가: 회사 테크 블로그에 올리는 버전을 만들면서 다시 쓴 문장들도 섞였다)

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

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

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

소개

안녕하세요. 배휘동입니다. 이렇게 많은 분들 앞에서 발표를 하려니 떨리네요.

우선 제 소개를 간단히 하겠습니다. 저는 대학원 다니면서 창업을 했다가 금방 접고, 친구들이랑 인디게임을 하나 만들었고요. 7년 전부터는 모바일 광고 도메인에서 개발자로 근무하기 시작해, 소프트웨어 교육 도메인과 금융/소상공인 도메인에서 일했습니다.

작년 초부터는 XL8에서 프론트엔드 팀 리드로 일하고 있어요. MediaCAT이라는 인공지능 미디어 컨텐츠 현지화 서비스의 PO 역할도 어느정도 겸하고 있고요.

제 가장 소중한 취미는 글쓰기입니다. 블로그도 재밌게 하고 있고, 블로그에 쓴 글 중 일부를 뉴스레터로 발행하기도 합니다.

여러 중소규모 스타트업 CTO의 고민

이렇게 제 생각을 얘기하다 보니, 프론트엔드 엔지니어 채용, 팀 빌딩, 커리어 설계 등을 주제로 스타트업의 C 레벨 분들과 대화를 나눌 기회가 꽤 생겼습니다. 그러면서 느꼈던 게, 많은 조직에서 좋은 시니어 프론트엔드 엔지니어를 원하지만 찾기가 참 어렵다는 것이었습니다. 여러 CTO와 기술 리드들이 비슷한 고민을 하시더군요.

• 프론트엔드에 요구하는 기술 수준이 그다지 높지 않아 엔지니어의 역량 발전 동기가 적음
• 프론트엔드 엔지니어 출신으로 좋은 커리어를 쌓은 롤모델이 주변에 별로 없어서 커리어 설계가 어려움
• 조직 내 시니어 프론트엔드 엔지니어의 부재로 미들급에게 리더십이 더 많이 요구됨

물론 이런 고민을 덜어주는 엔지니어링 래더나 기술 키워드 로드맵 같은 좋은 자료들이 있지만, 주니어의 입장에서는 커리어의 큰 그림을 어떻게 그리고, 구체적인 전문성을 어떻게 키울 것인지에 대한 답을 찾는 데는 큰 도움이 되지 않는다고 생각했습니다. 시니어 엔지니어나 팀 리드의 입장에서도 상황이 비슷해 보였고요.

엔지니어링 래더는 너무 넓고, 기술 키워드 로드맵은 너무 좁아서 그렇습니다.

프론트엔드 엔지니어 커리어 로드맵, 그리고 아쉬움

그래서 이 둘의 중간 수준이 있으면 좋겠다고 생각해서 작년 말에 쓴 게 프론트엔드 엔지니어 커리어 로드맵: 주니어를 위한 3가지 전문성 트랙이라는 글이었습니다.

그런데 글을 올린 후 도움을 되었다는 댓글과 연락은 많이 받았지만, 일말의 아쉬움이 있었습니다. 제 글이 기존 자료들보다는 여러모로 도움이 되었을 순 있어도, 여전히 ‘그래서 내 일상에서는 어떻게 노력하면 되는거지?’ 에 답을 하기에는 모호한 부분이 많다고 봤기 때문입니다.

마침 이번 인프콘이 이 아쉬움을 어느정도 해소할 기회가 될 수 있겠다고 생각했습니다.

발표 목적

그래서, 오늘 1부에서는 작년 말에 썼던 글을 좀 더 보강해서 설명하고요. 2부에서는 문제 해결과 역량 향상을 위해 구체적으로 어떻게 하면 될지 이론과 예시를 소개해드리고자 합니다.

참고로 저한테 코치 자격증 같은 게 있는 건 아니고요. 저는 <함께 자라기>의 저자인 김창준님의 교육 AC2를 10년 전에 들었습니다.

AC2는 나의 변화, 타인의 변화, 조직의 변화를 다루는 교육과정이자 커뮤니티고, 제 삶과 커리어에 굉장히 큰 영향을 끼쳤습니다. 지금도 저에게 가장 소중한 커뮤니티고요. 여기서 목표, 학습, 교육, 습관, 코칭 등 변화를 만드는 것과 관련된 다양한 개념을 연구 기반으로 배우고 실습하며 익혔습니다.

특히 올해 들어서는 AC2에서 소개한 여러 논문을 직접 읽고, 커뮤니티에서 공유하는 자리도 몇 번 가졌는데요. 이러한 배움을 제 삶의 경험과 엮어 여러 1:1과 멘토링, 코칭에서 다루기도 했습니다. 오늘 소개드릴 여러 프레임워크와 코칭 사례도 제가 올해 배운 것들을 풀어내는 연장선상에 있다고 볼 수 있습니다.

⚠️ 주의 ⚠️

그런데 본론으로 들어가기 전에 하나 말씀드리고 싶은 게 있어요.

오늘 발표의 제목에 주니어, 그리고 프론트엔드라는 단어가 언급되어 있지만, 이 발표가 주니어에게 쉬운 내용일 거라고 생각하진 않습니다. 주니어 분들이 처음 듣는 단어와 개념이 아주 많이 나올 거라서요. 정작 저 자신도 주니어 때 이런 방법들을 알고 있진 않았습니다. 나중에 알고 보니 제가 성장하고 공부한 방법 중 제법 괜찮았던 게 많았다는 건 깨닫게 됐지만요.

사실 저는 주니어든 시니어든, 그리고 프론트엔드든 아니든, 성과와 역량을 향상하는 비결이 따로 있다고 생각하지는 않습니다. 그러니 좀 어렵더라도 오늘 발표에서, '내가 일상에서 조금 다르게 해볼 수 있는 팁을 딱 하나만 얻어가겠다'는 마음으로 들어보시면 좋겠네요. 그리고 시니어로 성장해나가시면서, 이 발표를 종종 참고하시게 된다면 저는 만족합니다.

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

그럼 시작해볼게요. 저는 Divide & Conquer 를 아주 좋아합니다. ‘탁월한 시니어 프론트엔드 엔지니어가 되고 싶다’는 문장도 이렇게 한번 쪼개볼게요.

• 탁월한 (시니어 프론트엔드) 엔지니어가 되고 싶다.
• 탁월한 (시니어) 프론트엔드 엔지니어가 되고 싶다.
• 탁월한 시니어 (프론트엔드) 엔지니어가 되고 싶다.

여기서 첫번째가 가장 기본이고, 가장 중요하겠죠. 여기 계신 많은 분들이 원하는 목표이기도 할 거고요. 그러면 탁월한 엔지니어라는 건 대체 어떤 사람일까요?

저 말고도 궁금한 사람이 참 많았는지, 구글 학술검색에 great software engineer라고 치면 결과가 287만개 나옵니다. 그리고 그 중 맨 위에 있는 게 2015년에 나온 Li Paul Luo의 <What Makes a Great Software Engineer?> 라는 논문입니다.

300페이지짜리 박사학위 논문이라서 내용이 아주 구체적이고 방대한데, 이걸 오늘 좀 파헤쳐보겠습니다.

탁월한 개발자의 특성을 찾자

이제부터는 편의상 '소프트웨어 엔지니어'를 '개발자'로 칭할게요.

논문의 저자는 개발자에게 필요한 교육, 역량, 행동 등에 대한 수많은 기존 연구를 분석하고, 마이크로소프트에서 레벨 2 이상인, 즉 어느정도 역량을 인정받은 개발자 59명을 심층 인터뷰하여, 개발자가 가져야 할 만한 개인적인 특성(성격, 지식, 행동 등)의 후보 54개를 도출해냈습니다.

그리고 MS의 개발자 2,000여명을 대상으로 설문조사하여 이 항목들의 중요도를 이렇게 평가하게 했죠.

(특성에 대한 자세한 묘사 후) 만약 숙련된 개발자가 이 특성을 가지고 있지 않다면, 당신은 그가 탁월한 개발자라고 평가할 것인가?

라고 말이죠. 참고로 답변은 다음 중 하나를 선택하는 것이었습니다.

1. 이것 없이는 탁월한 개발자가 될 수 없다
2. 이것 없이 탁월한 개발자가 되는 게 불가능하진 않으나 굉장히 어렵다
3. 이것 없이도 탁월한 개발자가 될 수는 있겠으나, 있으면 도움이 된다
4. 이것은 탁월한 개발자가 되는 것과 관계가 없다
5. 탁월한 개발자에게는 이게 있어서 안 된다
6. 잘 모르겠다

(참고로 저자는 의도적으로 설문조사에서 ‘소프트웨어 엔지니어’ 대신 ‘개발자’라는 용어를 썼습니다. 엔지니어링 팀에 속하지만 코드를 작성하지 않는 사람을 구분하기 위해서였습니다. 일관성을 위해 저도 ‘개발자’로 통일해서 쓰겠습니다.)

MS만을 대상으로 한 건 연구의 한계점이기도 했으나, MS에는 여러 나라에서 여러 분야의 소프트웨어 팀이 있었고 MS만의 용어와 문화에 익숙한 것이 분석의 일관성을 더해주는 이점이 더 크다고 봐서 MS만을 대상으로 했다고 하더군요.

설문조사 결과

설문조사 결과는 이랬습니다. (출처: What Makes a Great Software Engineer, Table 4.4. Attributes of great software engineers, ranked and with ratings distributions)

자세히 보시면 1, 2위는 코딩 디테일에 주의를 기울이고, 복잡성을 관리하는 마음가짐입니다. 3위는 꾸준히 스스로를 개선하는 것이고요. 4, 5위는 정직함과 열린 마음에 대한 것이고 6위는 분석하느라 실행 못하는 게 아니라 실천할 줄 아는 것에 대한 것이네요.

이런 식으로 쭉 내려가는데, 저자는 최하위였던 2개, 즉 '초과근무'와 '개인적 신뢰자산을 쌓아 호의를 주고받는' 것은 '탁월한 개발자는 이러면 안 된다'는 비율이 상당히 높았던 것에 놀랐다고 합니다(유이하게 5%가 넘음). 숙련된 개발자들을 심층 인터뷰해서 뽑은 특성들이니, 해가 되는 특성이라는 답이 나올 줄 몰랐다는데요.

그래서 후속 인터뷰로 원인을 분석해봤더니 이 특성들이 본질적으로 개발자에게 안 좋은 특성이라기보다는, 개발자가 이래야만 하는 상황에 처해있다는 것 자체가 안 좋다는 뜻에 가까웠습니다.

• 초과근무가 필요하다는 건 설계가 잘못됐거나, 지속 불가능한 실천법을 따르는 상황이라는 뜻일 수 있고,
• 호의를 주고받아야만 한다는 건 의사결정이 합리적 근거보다는 주관적 의견을 따르는 문화라는 뜻일 수 있다는 거죠.

이는 탁월한 개발자라면 이런 상황을 피할 수 있도록 조직과 문화를 바꾸는 노력을 해야 한다는 의미로 읽을 수도 있습니다. 물론 XL8에서도 열심히 일하고 호의를 주고받는 것이 당면한 문제에 대한 해결책이 될 수 있음을 잘 알고 있습니다만, 이들에 의존하지 않고도 효과적으로 일할 수 있는 환경을 조성하도록 노력합니다.

탁월한 개발자의 5가지 필수 역량 - 저자의 해석, 나의 해석

설문조사 결과를 분석하고, 또 이 결과를 가지고 개발자의 주된 협력 대상자들(아티스트, 컨텐츠 기획자, 데이터 과학자, 디자이너, 전기공학자 등 40명)을 추가로 인터뷰해서, 저자는 탁월한 개발자의 필수 역량 다섯 가지를 다음과 같이 뽑아냈습니다.

1. 유능한 코더가 된다(Be a competent coder)
2. 작업의 현재 가치를 극대화한다(Maximize current value of your work)
3. 근거 기반 의사결정을 연습한다(Practice informed decision-making)
4. 동료의 효율적 의사결정을 돕는다(Enable others to make decisions efficiently)
5. 꾸준히 학습한다(Continuously learn)

그런데 저는 순서를 조금 바꾸고, 해석을 살짝 다르게 하는 게 이 항목들을 평가하거나, 이 지식을 통해 변화를 이끌어내는 데 더 효과적이라고 생각해서 이렇게 바꿔봤어요.

1. 훌륭한 코드를 짠다
2. 근거 기반 의사결정을 연습한다
3. 동료의 효과적 의사결정을 돕는다
4. 작업의 현재 가치를 극대화한다
5. 효과적으로 꾸준히 학습한다

그러면 이제 각 역량에 대한 저자의 해석과, 제 생각을 설명해보겠습니다. 특히 주니어 개발자의 입장에서 각 역량을 어떻게 이용할지를 염두에 두었습니다. 핵심 메시지를 요약하면 다음과 같습니다.

• 훌륭한 코드를 기반으로 하여, 근거 기반 의사결정을 연습하고 동료의 효과적 의사결정을 도움으로써 작업의 현재 가치를 극대화하라.
• 효과적으로 학습하는 법을 꾸준히 학습하라. 더 훌륭한 코드를 짜는 방법을, 근거 기반 의사결정을 더 잘 연습하는 방법을, 동료의 효과적 의사결정을 더 잘 돕는 방법을, 작업의 현재 가치를 더 높이는 방법을 학습하라.
• 주니어 개발자라면 훌륭한 코드 짜기, 그리고 효과적이고 꾸준한 학습을 최우선 목표로 삼아라.
• 이 모든 것은 현실의 구체적 문제에 대한 이해와 관심을 바탕으로 해야 한다.

1. 훌륭한 코드를 짠다

주니어에게 가장 우선시되는 역량

훌륭한 코드를 짠다는 건 저자에 따르면 '단순히 작동하는 걸 넘어 훌륭하게 만들 디테일에 주의를 기울인다'는 걸 뜻합니다. 저자는 이러한 디테일의 예시로 에러 핸들링, 메모리, 성능, 보안, 스타일 등을 꼽았습니다.

다른 모든 역량이 뛰어나더라도 그 사람이 생산해내는 코드의 품질이 좋지 않다면 탁월한 개발자라고 칭하기 어렵습니다. 오히려 다른 역량이 정말 뛰어난 게 맞는지 다시 한 번 확인하게 되죠. 실제로 이 연구뿐 아니라 다른 많은 연구에서도 ‘훌륭한 코드 짜기’는 주니어가 가장 먼저 갖춰야 할 역량으로 뽑혔습니다.

그러나 이 훌륭함의 기준이 아주 높지는 않습니다. 저자는 훌륭한 코드가 베이스라인에 불과하며, 이것만으로는 탁월한 개발자가 될 수 없다고 말합니다. 일정 수준을 넘어가면 다른 역량을 키우는 노력이 더 효율적이라는 뜻이죠. 그러면 그 일정 수준은 어느 정도를 말하는 걸까요?

훌륭함의 기준은 어느 정도인가

저도 정량적인 기준을 말씀드리긴 어렵습니다만, 조금 더 구체적으로 묘사해보겠습니다. 저는 코드 리뷰어에게 의문이 덜 생기게 하는 사려깊은 코드를 봤을 때 품질이 높다고 느낍니다. 예를 들어:

• 전체적으로 언어의/프레임워크의/팀의 베스트 프랙티스와 컨벤션을 잘 따르고 있음 (성능, 보안, 스타일 등)
• 변수/함수/클래스/파일 등이 왜 이런 이름으로 왜 이 위치에 존재하는 것인지 납득이 됨 (납득이 안 될 만한 부분에는 주석이 잘 작성되어 있음)
• 다양한 구현 방식이 가능했을 때 최종적으로 선택한 결정의 근거가 잘 명시되어 있으며(e.g., 대안은 무엇이고 트레이드오프는 무엇이었는지), 이후의 상황 변화에 비교적 유연하게 대처할 수 있는 구조로 만들어져 있음
• 버그 수정을 위한 PR이라면, 어떤 사용자가 어떤 상황에서 맞닥뜨리는 어떤 버그를 어떻게 고쳤는지, 리뷰어는 버그 수정 여부를 어떻게 테스트할 수 있는지 명시되어 있음
• 신규 피처를 위한 PR이라면, 어떤 고객의 어떤 요구사항을 만족시키기 위해 어떻게 구현했는지, 이후 그 임팩트를 어떻게 확인할 수 있을지 명시되어 있음
• PR에 이번 변경이 기존 기능에 부정적 부수효과를 발생시키진 않았는지 확인하기 위한 코드와 설명이 포함되어 있음

이는 실제로 XL8 개발자들이 지키기 위해 노력하는 것이기도 하고, 주니어 개발자들에게도 같은 노력을 기울일 것을 권장하는 것이기도 합니다. 물론 이러한 세심함을 발휘하려면 어느정도는, 특히 단기적으로는 속도가 느려질 수밖에 없습니다. 결국에는 ‘문제의 어려움 + 희생한 세심함 대비 문제를 해결하는 데 걸린 시간이 충분히 짧았는지’를 종합적으로 판단하여 그게 허용 가능한 수준인가를 가늠하게 됩니다.

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

의사결정 결과보다는 과정을 개선하라

그 다음은 의사결정입니다. 의사결정 역량을 기르려면 의사결정의 결과보다는 과정을 개선하는 데 집중하는 게 더 유리합니다. 결과는 내 의지와 상관없이 정해질 수 있으니까요.

데이터에 기반해 의사결정하되 편견과 성급함을 피하라

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

몇 달 전의 일인데요. 제가 매주 수요일에 정기적으로 운전할 일이 생겼는데, 그 시간이 아까워서 AC2에서 전화 코칭을 받으실 분을 모집했습니다. 신청자가 빠르게 쌓이는 가운데 어떤 분이 조심스럽게, “스피커폰을 쓰더라도 운전 중 통화는 음주운전에 준하는 주의 분산 효과가 있다”는 얘기를 해주셨습니다. 순간적으로 반발심이 들었지만, 새로운 정보를 얻었다면 기존의 의사결정을 돌이켜봐야 한다는 생각이 들었습니다. 그래서 저도 직접 찾아보니 말씀하신 게 맞더군요. 점점, 아무리 시간이 아까운들 제 목숨만 하겠냐는 생각이 들었습니다. 결국 그 날 바로 코칭 신청 받는 걸 중단했죠.

또 다른 좋은 예는 디버깅입니다. 디버깅할 때 판단에 필요한 재료는 대부분 이미 있음에도 불구하고, 문제의 원인을 섣부르게 판단하여 그 원인이 외부에 있다고 생각하는 경우가 꽤 있습니다. 주니어만 그런 게 아니라 경험 쌓인 시니어에게도 이런 일을 많이 목격했습니다. 제 경험상으로는 내 문제가 아니라고 생각하면, 예를 들어 라이브러리나 브라우저 문제라고 생각하면 대부분 틀리더군요. 만약 브라우저 문제가 맞았다 한들, 그와 유사한 모든 문제를 브라우저 탓으로 치부해버리면 가끔씩 정말 내 실수로 벌어진 치명적인 문제도 무시해버릴 수 있으니 조심해야 합니다.

여유를 가지고 다양한 외부 관점을 받아들여라

이러한 편견이나 성급함을 피하는 한가지 방법은 여유를 가지고, 다양한 외부 관점을 열린 마음으로 받아들이는 것입니다. 사실 정말로 지금 당장 해야 하는 건 생각보다는 많지 않거든요. 잠깐 숨을 돌리고 친구, 동료, 고객, 경쟁자, 상사 등 다양한 사람들이 사안을 어떻게 해석하는지 보면 나의 편견이 유지되기 어렵습니다.

물론 사람이 마음이 급해지고 스트레스를 받으면 (아드레날린과 코르티졸이 분비되기 때문에) 이성적으로 행동하기 어렵습니다. 조직도 마찬가지죠. 그래서 현명한 조직들은 일부러 일정과 리소스에 여유를 두고, 현명한 개인은 스트레스를 관리하는 방법을 익힙니다.

• 조직에서의 결핍과 여유에 대해서 더 알아보고 싶으시다면 <결핍의 경제학>을,
• 개인의 스트레스 관리에 대해서 더 알아보고 싶으시다면 (요즘 유명해진) 스탠포드 신경과학 교수 Andrew Huberman의 명상 관련 팟캐스트를 추천합니다. 유튜브에 Huberman이 직접 녹음한 10분짜리 영상도 있고요.

다양한 양질의 정보가 내 주변에서 지나가게 하는 시스템을 구축하라

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

• ‘다양한’은 내 취향에 맞는 정보만 들어오게 하지 말라는 것이고 (e.g., 간신들로 둘러싸인 왕)
• ‘양질의’는 뉴스레터와 같은 큐레이션을 적극 활용하되, 그러한 필터에도 의도가 담겨있다는 걸 기억하라는 것이고
• ‘지나가게’는 정보를 받아들이는 것뿐 아니라 내보내기도 하라는 뜻입니다. 나의 생각을 공유하고 발표할 때 학습이 엄청나게 일어나기 때문입니다.
• 그리고 ‘시스템’은 내가 너무 큰 의식적 노력을 들이지 않더라도 반자동으로 이 체계가 유지되게 하라는 뜻입니다. 예를 들어 스터디모임에 내가 잘 보이고 싶은 사람을 끌어들여두면 스터디 빠지고 싶은 마음이 없어지겠죠. 인프콘에 발표자로 참여하면 자연스럽게 다른 사람 발표를 들으며 배우게 될 거고요.

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

주니어는 질문으로 성장하는 게 조직과 동료를 돕는 것이다

이번에는 5가지 역량 중 유일하게 직접적으로 협력과 관계된 역량입니다. 하나밖에 없지만 저도 이게 협력의 핵심이라고 생각해요.

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

그러면 주니어는 어떻게 할까요? 주니어는 질문으로 동료를 돕습니다. 주니어는 당장의 ‘성과’보다는 ‘성장’을 해야 조직에 도움이 되기 때문입니다. 자기가 모르는 걸 드러내고 질문을 해야 성장할 수 있으니, 저평가와 거절과 민폐의 두려움을 이겨내 고맥락 질문을 해주시면 좋습니다.

취약성을 먼저 고맥락으로 드러내 신뢰를 쌓아라

보통은 신뢰를 쌓아야 이러한 취약성을 드러낼 수 있다고 생각하는데, 실제로 연구를 보면 거꾸로입니다. 서로 약점을 보이고 용기있게 위험을 감수할 때 신뢰의 토대가 빠르게 형성되는 것입니다.

• 취약성의 힘에 대해서는 제가 무척 좋아하는 Brene Brown의 짧은 TED 영상을 추천합니다.
• Daniel Coyle의 <최고의 팀은 무엇이 다른가>라는 책도 좋고요.

그런데 취약성도 잘 드러내는 방법이 있습니다. 맥락과 함께 취약성을 드러내야 해요. 디자인 업계의 고전 중 하나로 <Don't Make Me Think> 라는 책이 있습니다. 이 책의 핵심은, 유저가 기능에 대해 이건 뭐지? 저건 뭘 위한 거지? 하며 제품의 의도를 추측하게 하지 말라는 것입니다.

협력할 때도 마찬가지입니다. 저는 보통 ‘A-B-C 문제’라고 부르는데요.

• 주니어들은 보통 A라는 문제가 있어서 B를 시도해보고는, 그 안에서 C가 잘 안 되면 C만 물어봅니다. HTML 엘리먼트를 최상단에 고정시키려면 어떻게 해야 하죠? 같은 걸 다짜고짜 묻는 거죠.
• 이렇게 하면 대개는 굉장히 지엽적인 대답만 얻고, 그 대답을 얻어도 문제 해결이 잘 안 됩니다.
• 그래서 내 맥락을 잘 공유하는 게 중요합니다. 저는 A를 제대로 설정하고 나면 B가 자동으로 나와서 C가 필요없어지는 걸 자주 봤습니다. 알고 보니 엘리먼트를 상단 고정하는 게 디자이너의 의도가 아니었을 수도 있거든요.

XL8의 커뮤니케이션 가이드라인 문서에서도 첫 페이지부터 컨텍스트 공유의 중요성을 강조합니다. 누군가가 컨텍스트 공유를 잊었다면, 그에게 컨텍스트가 무엇인지 묻는 게 절대 무례한 게 아니며, 오히려 권장되는 행동이라는 것이죠.

디폴트값을 이용해 조직 차원에서 취약성과 투명성에 큰 가치를 두는 문화를 구축하라

물론, 아무리 내가 질문을 하려고 한들 조직 내 문화가 뒷받침해주지 않으면 쉽지 않은 게 사실입니다. 그래서 질문을 장려하려면 취약성과 투명성에 큰 가치를 두는 문화를 마련해야 합니다.

이런 문화를 구축하는 데 조직 내 디폴트값을 뭘로 두느냐가 상당히 중요합니다. 디폴트값이 사람의 인지와 행동에 굉장히 큰 영향을 주기 때문입니다.

• 2003년 발표된 논문에 따르면 호주의 사후 장기 기증률이 100%에 가깝고 스웨덴은 86%인 반면, 독일은 12%, 덴마크는 4%에 불과했는데요. 이 거대한 차이는 알고 보니 단순한 정책 차이에서 온 것이었습니다.
• 호주와 스웨덴은 장기 기증을 안 하려면 체크박스에 표시해야 했고, 독일과 덴마크는 장기 기증을 하려면 체크박스에 표시해야 했거든요.

Slack vs. Email, Notion vs. Google Docs

• 이 도구들의 차이가 보이시나요? 좌측은 기본이 public이고, 우측은 기본이 private입니다. 좌측은 숨기려면 액션을 해야 하고, 우측은 공유하려면 액션을 해야 하죠.

Do Not Disturb vs. Open Hours

• 또, "언제든지 말을 걸어도 되는데 이 때만 피해달라"는 문화, 즉 Do Not Disturb 시간이 있을 때랑, “이 때는 자유롭게 와서 말 걸어도 된다”는 Open Hours가 있을 때, 어느 쪽이 더 질문과 대화가 많이 일어날까요?
• 저는 전자일 거라고 생각합니다. 여기에 대학생 시절, 교수님 오픈 오피스 시간에 질문하러 자주 가신 분들이 얼마나 많을지는 모르겠는데, 적어도 저는 안 갔거든요.

아무리 판을 깔아줘도 질문하는 사람은 적습니다. 그보다는 평소에 질문하기 쉬운 분위기를 만드는 게 더 낫죠.

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

탁월한 개발자에게는 시스템적 사고와 당장 움직이기 둘 다가 요구된다

근거 기반으로 동료와 함께 의사결정함으로써 만들어진 좋은 코드는 결국 모두 ‘가치’를 만들어내야 의미가 있습니다. 그리고 작업의 현재 가치를 극대화하려면, (‘좋은 코드를 짜는’ 역량에서 이미 언급했지만) 세심함과 속도 둘 사이를 적절하게 조율할 줄 알아야 합니다. 다음 두 가지가 모두 중요하다는 뜻이죠.

• 나중에 문제가 될 만한 부분이나, 요구사항이 어떻게 변할지 예측하여 장기적 관점에서 구현하기
• 분석하느라 멈춰있지 말고, 불확실성이 두려워도 일단 뛰어들어 실행하여 피드백 받기

둘 중 스타트업에서는 후자가 더 유리하지만, 그렇다고 극단에 치우치면 불리해집니다.

빠른 실행을 하면서도 적은 노력으로 큰 이득을 가져다주는 습관을 들이자

그러니 빠른 실행에 주력하되, 조금만 노력해도 큰 이득을 주는 행동을 습관으로 만들어두면 좋습니다.

예를 들어 미시적으로는,

• 값이 하나더라도 하드코딩해두지 말고 변수로 빼놓는다거나
• 값이 지금은 두개밖에 없더라도 그게 한 컴포넌트를 넘어서는 종류의 옵션이라면 Boolean 값 대신 Mode를 사용하는 습관을 들여봅시다.

그리고 거시적으로는,

• 내가 어떤 가설을 검증하기 위해 실행하는 건지 생각해보고,
• 검증을 어떤 데이터로 할지 생각해본 뒤 실행해봅시다.

요약하면, 현재 상황에 맞춰 시스템적 사고와 당장 움직이기 둘 사이를 유연하게 오갈 때 작업 가치가 극대화된다고 할 수 있습니다.

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

효과적 학습법을 학습하여 복리이득을 누려라

마지막으로 5번. 이건 원래는 그냥 꾸준히 학습하는 거였는데, 제가 '효과적으로'를 덧붙였습니다.

효과적으로 학습하는 법을 학습하는 게 모든 성장의 시작이라고 보기 때문입니다. 일찍 할수록 좋은 거죠.

정보를 수집해 지식을 주기적으로 갱신하되, 소음과 신호의 비율에 주의하라

학습이란, 결국 나의 지식을 넓혀 삶을 변화시키기 위한 것입니다. 그런데 n년 전의 지식이 지금도 유효하리라는 보장이 없으니 언제나 새로운 정보를 이용해 업데이트하는 노력이 필요하죠.

그러나 정보가 많다고 무조건 좋은 건 아닙니다. 어떤 정보들은 있으면 방해만 됩니다. 정제되지 않은 빅데이터가 쓰레기더미에 불과한 것처럼요. 있어봤자 해가 되거나, 부정확하거나, 내 문제와 관련 없는 소음 대신 신호의 비율을 높여야 합니다. 정보를 사실, 해설, 예측 3가지로 구분해보는 것도 신호의 비율을 높이는 좋은 습관입니다.

저는 본인의 전문 도메인이 아닌 곳에서 내 기존 지식과의 연결점을 만들어주는 통찰, 또는 내가 특정 조건에서 틀렸을 수 있다는 증거들이 좋은 신호의 예시라고 생각합니다.

찰스 다윈이 비글호 탐사를 마치고 진화론을 확신한 건 1836년이었지만 <종의 기원>을 발표한 건 23년 뒤인 1859년이었습니다. 다윈의 자서전에 따르면 본인이 내린 결과에 반대되는 정보가 보일 때마다 즉시 메모를 하는 습관이 있었다고 합니다. 이런 정보가 본인에게 유리한 정보보다 훨씬 쉽게 기억에서 사라진다는 걸 알았기 때문이죠. 20여년간 이런 사례를 모은 덕분에, <종의 기원>을 발표한 뒤 제기된 여러 반론에 다윈이 답변하지 못한 게 거의 없었다고 합니다.

매일 조금씩 더 효과적으로 자라는 방법

효과적인 학습에 대해서는 2부에서 더 다루겠습니다만, 결국 핵심은 ‘어떻게 하면 내가 매일 조금씩 더 효과적으로 자랄 수 있을까?’ 라는 질문으로 요약할 수 있습니다.

• 지금 당장 현실에서 내게 필요한 걸 찾아보고,
• 관련된 이론적 근거를 딱 필요한 만큼만 학습하고,
• 배우자마자 즉시 써먹어 셀프 피드백 받는 걸 반복하는 거죠.

그럼 지금 당장 현실에서 내게 필요한 건 어떻게 알까요?

일기를 써서 일상에서 내가 겪는 문제를 발견할 수도 있고요. 내가 지난 한주간 어디에 많은 시간을 썼는지 기록해보고, 그걸 더 잘 하기 위해 노력해볼 수도 있겠죠. 예를 들어 취준생이라면 스터디를 엄청 할텐데, 스터디를 효과적으로 하는 법을 연구하면 도움이 될 겁니다.

내가 자주 하는 것일수록, 내가 잘 하고 있는지 셀프 관찰하면서 피드백 받기에도 유리합니다. 학습 기회도 더 많아지고, 개선시 삶의 질 상승폭도 더 커지겠죠.

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

조금 전 효과적 학습의 핵심으로 ‘배우자마자 즉시 써먹어보고 셀프 피드백’을 이야기했죠. 바로 해봅시다.

탁월한 개발자의 5가지 필수 역량이 무엇인지에 대해 새로운 지식을 얻었지만, 아직 이것만으로는 변한 게 하나도 없습니다. 뭔가 다르게 행동을 해서 제 삶을 변화시켜야 의미가 있겠죠. 이 지식을 어떻게 써먹으면 될까요?

주니어: 학습과 성장에 써먹기

주니어는 이 목표들 하나하나를, 특히 "훌륭한 코드 짜기"와 "효과적으로 꾸준히 학습하기"에 묘사된 지식과 행동에 본인이 얼마나 부합되는지 체크해보면 좋습니다. 그리고 부족한 역량을 집중해서 계발하는 거죠. 예를 들어 내가 근거 기반 의사결정을 하고 있지 않았다면, 내가 일상적으로 내리는 결정이 뭐였는지, 근거는 뭐였는지 기록해보는 습관을 들여볼 수 있을 거예요.

시니어: 채용 평가와 성과 평가에 써먹기

그리고 시니어라면 이것들을 채용 평가와 성과 평가에 쓸 수 있습니다. 지원자가 이 역량을 충분히 가졌는지를 어떤 신호로 판별할지 고민해보는 거죠. 만약 이 신호를 판별하기 어렵다? 그러면 채용 평가 방식 자체를 바꾸거나, 효과적인 인터뷰 기법을 공부해야 할 수도 있습니다.

아무튼 평가를 해보고 기록해서 내가 제대로 평가했는지 나중에 돌이켜보면 도움이 되겠죠. 주니어의 역량을 높이기 위해 리드할 때에도 비슷하게 써먹을 수 있을 거고요.

XL8: 채용과 온보딩에 잘 써먹는 중

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

활용시 주의할 점

다만, 이렇게 활용할 때 염두에 둘 게 몇가지 있습니다. 우선 이 연구는 여타 연구들과 마찬가지로 절대적 진리가 아닙니다. 당연히 한계가 있고, 논문 저자의 해석과 저의 해석을 거쳤다는 것도 감안해야 합니다.

예를 들어 이 연구에서 논하는 ‘의사결정’은 Herbert Simon의 이성적 의사결정(Rational decision-making) 프레임워크를 기반으로 하고 있습니다. 이것이 직관에 의존하는 Gary Klein의 자연주의적 의사결정(Naturalistic decision-making)보다 더 소프트웨어 엔지니어링의 맥락에 어울린다고 판단했다고 하더군요. 저는 여기에는 100% 동의하지 않습니다만, 이 연구가 실제 개발자의 행동을 관찰하기보다는 설문조사와 인터뷰에만 의존했기 때문에 저자가 그런 판단을 내린 게 아닌가 싶습니다. 어쨌든 여전히 가치있는 기준이라고 생각해서 그대로 사용했습니다.

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

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

드디어 개론이 끝났습니다. 이제 또 다른 써먹기의 차례인데요.

이 5가지 역량에 대한 지식을 프론트엔드 개발의 맥락에서는 어떻게 활용하면 좋을까요? 그리고 활용하려면 무엇이 필요할까요? 예를 들어 이런 질문들을 던져볼 수 있겠네요.

• 훌륭한 프론트엔드 코드란 무엇일까?
• 프론트엔드에서 더 나은 의사결정이 뭐지?
• 프론트엔드 개발자가 동료를 어떻게 도울 수 있지?
• 프론트엔드에서 가치 극대화가 뭐지?
• 프론트엔드 지식 학습은 어떻게 하지?

이런 질문에 대해 일부라도 답하는 방법을 고민하다 보니, 프론트엔드 개발자에게 조직이 기대하는 역할이 무엇인가, 부터 시작해야겠다는 생각이 들었습니다.

저는 크게 3가지 역할이 요구된다고 봤고, 이걸 커리어 패스로 간주하여 각각 웹, 제품, 운영 특화 트랙이라고 이름붙였습니다. 그리고 트랙별로 주요 특징과 장단점, 역량 향상 방법, 이후 가능한 커리어를 설명하고자 했죠.

요약하면 이렇게 되겠습니다. (인프콘 발표에서는 이 내용을 그냥 ‘글을 읽어보라’고 말씀드렸지만, 이번 시리즈물의 3부에서 좀더 제대로 보강과 해설을 해볼 예정입니다.)

이번에도 결국 중요한 건 아까와 마찬가지로, 이 지식을 어떻게 써먹을 것인가 하는 것이겠죠.

주니어로서: 구직과 이직에 써먹기

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

시니어로서: 채용과 리딩에 써먹기

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

주의할 점

다만 여기서도 아까와 똑같이 염두에 둘 게 있습니다.

우선 트랙별 차이를 드러내기 위해 편의상 3개로 분리해두었지만, 실제로는 대부분의 시니어들이 한 트랙만 끝까지 밟기보다는 세 트랙 모두에서 어느정도 역량을 갖췄을 확률이 높습니다. 하나만 계속 파는 것도 당연히 가능하지만, 그러면 결국 임팩트를 내는 데 한계 효용을 느끼게 될 거예요. 각 트랙은 상호보완하기 때문에, 한 전문성이 충분히 있는 사람은 다른 트랙의 전문성을 쌓기 훨씬 쉬워지며, 당연히 각 트랙에서 시니어로서 가능한 커리어도 일부 겹칩니다.

또, 연구를 거쳐 나온 '탁월한 개발자의 필수 역량'과 달리 이 전문성들은 그냥 제 경험에서 비롯된 걸 정리한 것 뿐입니다. 절대적 진리와는 거리가 한-참 멀죠. 그러니 이 갭은 감안하셔야 하고요.

마지막으로 이것들만 갖추면 탁월한 프론트엔드 개발자가 될 수 있다, 라기보다는 거쳐가는 지점, 가이드 정도로 생각해주시는 게 좋겠습니다.

탁월한 시니어 개발자 되기

제 작년 글에는 탁월한 시니어 개발자가 되는 방법에 대한 제 생각도 간단히 언급했습니다.

기본에 충실하고자 노력한다

5가지 필수 역량 계발을 지속하는 사람이 좋은 시니어가 됩니다.

명시적 리더가 아니더라도 리더처럼 행동한다

때론 동료의 모범적 행동 하나가 명시적 리더의 수많은 말보다 더 큰 영향을 끼칠 수 있죠. 리더 역할이 아닐 때에도 리더십을 보여주는 사람에게 리더 역할이 주어지게 마련입니다.

어떤 상황에서든 큰 임팩트를 낸다

위와도 비슷한데, 작은 일을 맡아도 큰 임팩트를 만드는 사람들이 이후 더 큰 일을 맡게 됩니다.

탁월한 시니어는 작은 버그를 고칠 때에도 뭔가가 다릅니다.

• 버그의 근본 원인을 파악하고,
• 비슷한 버그가 다른 곳에 존재하진 않는지 확인하고,
• 운영 환경별로 다르게 적용할 만한 예외 케이스는 없는지 살피고,
• 다음에 비슷한 버그가 생기기 어렵도록 개발환경을 개선(린터 룰 추가, 테스트 추가, 구조 변경 등)하고,
• 만약 생기더라도 일찍 인지할 수 있는 장치를 추가합니다.

그리고 이 모든 걸 혼자가 아니라 동료들과 의사소통하고 위임하여 함께 해결함으로써 조직 전체의 역량을 높입니다.

자, 여기까지가 1부였습니다. 잠깐 숨 좀 돌리고 2부로 넘어갈게요.

파트 1을 맺으며

돌이켜보면, 이 글에 주니어에 대한 많은 조언을 담았지만 저 또한 주니어 시절부터 이렇게 행동했던 건 아니었습니다. 항상 제 주변의 구체적인 현실의 문제에 관심을 가지고, 열심히 풀려고 노력하면서 수많은 시행착오를 거쳤기 때문에 비로소 이런 지식도 받아들일 수 있게 된 것 같아요.

꼭 최신 인공지능 기술을 활용할 때가 아니더라도, 연구논문은 개인과 조직에서 만나는 고민을 덜어주는 데 큰 도움이 될 수 있습니다. 논문에서 배운 ‘탁월한 개발자의 5가지 필수 역량'은 저 스스로뿐 아니라 XL8에서 새로운 동료를 채용하고, 주니어를 성장시키는 데 귀중한 가이드라인이 되었습니다. 이 글이 당신 조직에서도 개발자를 채용하고 평가할 때, 그리고 탁월한 개발자로 스스로 성장하고자 할 때 좋은 힌트가 되길 기대합니다.

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