what-makes-a-great-software-enginner.md

무엇이 탁월한 개발자를 만드는가: 자가 점검해 보기

<2023 인프콘> 주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드 1부, 무엇이 탁월한 개발자를 만드는가를 기록하며 개인적인 생각을 담아 정리한 글입니다.

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

탁월한 엔지니어 되기

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

‘탁월한 시니어 프론트엔드 엔지니어가 되고 싶다’는 문장은 3단계로 해석하면서 언급하셨던 부분이 인상깊었다.

부끄러운 이야기지만, 개발을 시작하며 무작정 '잘하는 프론트엔드 개발자가 되고싶다.'라는 단순하고 섣부른 생각을 가졌던 과거의 내가 떠올랐다. 되짚어보면 나는 '탁월한 엔지니어'가 되기 이전에 '탁월한 프론트엔드 엔지니어가 되고 싶다.'라는 오만한 생각을 했던게 분명하다.

시간이 지나 스스로 깨달은 것은 1) 편향된 견해를 가지는 것의 위험성과, 2) 고민없이 무작정 배우기만 하는 방식의 문제점, 3) 몰라도 되는 개발의 부분은 없다. 는 사실이다. 꾸준히 배우고, 스스로 경계하는 것을 멈추지 않아야한다는 점을 피부로 느끼는 순간들이었다.

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

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

• 단순히 작동하는 것을 넘어 훌륭하게 만들 디테일에 주의를 기울인다.(에러 핸들링, 메모리, 성능, 보안, 스타일)
• 주니어에게 가장 중요한 역량! 그러나 '훌륭함'의 기준이 그리 높지 않음에 주의
• 일정 수준을 넘어가면 다른 역량을 키우는 노력이 효율적

1) 코드 품질에 대한 자신만의 일관된 관점을 갖고, 2) 고객 요구사항을 만족하는 코드를, 3) 빠른 속도와, 4) 적은 버그로, 5) 가독성 있게 작성한다.

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

• 의사결정의 결과보다는 프로세스를 개선하는 데 집중하는 게 유리

  • 문제 정의 ➡️ 현재 가진 정보에 기반해 반증 가능한 가설 수립 ➡️ 추가로 필요한 정보 판단해서 습득 ➡️ 의사결정 및 행동 ➡️ 결과 관찰 ➡️ 피드백

• 데이터에 기반하되 편견에 빠져 해석하거나, 성급하게 결론내리지 않기

  • 새 정보를 얻었다면 불편하더라도 기존 판단을 재고해봐야 함
  • 디버깅할 때 이건 내 문제가 아니라고 생각하면 대부분 틀림 (e.g. 라이브러리, 브라우저, 네트워크, 하드웨어...)

• 여유를 가지고, 열린 마음으로 다양한 외부 관점을 받아들여 큰 그림으로 보기

  • 친구의, 동료의, 고객의, 경쟁자의, 상사의 관점

• 다양한 양질의 정보가 내 주변에서 지나가게 하는 시스템 구축하기 (뉴스레터, 커뮤니티, 스터디...)

  • 다양한 = 고여있지 않기
  • 양질의 = 큐레이션 활용, 정보 잘 판단하는 능력 기르기
  • 지나가게 = 받아들이다 + 내보내다
  • 시스템 = 너무 큰 노력을 들이지 않아도 유지되도록

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

• 탁월한 개발자는 본인이 확보한 유용한 정보와 성공 및 실패 경험을 공유하며 동료를 성장시키고, 팀의 생산성을 높이고, 결과적으로 본인이 속한 조직이 더 나은 의사결정을 할 수 있도록 도움

• 주니어라면 저평가, 거절, 민폐의 두려움을 이겨내 고맥락으로 질문 및 부탁하는 습관을 가지면 좋음

  • 신뢰를 쌓아야 취약성을 드러낼 수 있는 게 아니라, 취약성을 드러내야 신뢰를 쌓게 됨
  • Don't Make Me Think: A-B-C면 C만 물어보지마라.

• 이러한 행동이 촉진되려면 취약성과 투명성에 높은 가치를 두는 문화를 구축해야 함

  • 디폴트의 중요성: Slack vs Email, Notion vs Google Docs
    • Public by Default 도구(Slack, Notion) vs Private by Default 도구(Email, Google Docs)
    • "언제든지 말을 걸어도 되는데 이 때만 피해달라(Do Not Disturb)"가 “이 때는 자유롭게 와서 말 걸어도 된다(Open Hours)”보다 낫다.

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

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

• 특히 스타트업에는 후자가 더 유리하지만, 절대 극단에 치우치면 안 됨

• 적은 노력으로 큰 이득을 가져다주는 습관이 몇가지 있음

  • 미시적: 값이 하나라도 하드코딩 대신 변수로, 값이 둘이라도 Boolean 대신 Mode로
    • isEditing: boolean vs mode: 'EDIT' | 'VIEW'
  • 거시적: 결과를 관찰할 수 있는(=피드백을 받을 수 있는) 명확한 가설을 세워놓고 실행

• 내 의지로 시스템적 사고와 당장 움직이기 둘 사이를 유연하게 오갈 때 작업 가치가 극대화됨

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

• 모든 역량 중 가장 중요, 효과적으로 학습하는 법을 학습하는게 가장 큰 복리 이득을 줌

• 학습 = 나의 지식을 넓혀 삶을 변화시키기 위한 것

  • n년 전에 유효했던 지식이 지금도 유효하리라는 보장이 없음 ➡️ 새로운 정보를 이용해 업데이트 필요
  • 정보 = 사실, 해석, 예측 ➡️ 가치있는 지식은 이 3가지를 버무릴 때 나옴
  • 그러나 정보가 많다고 무조건 좋은 건 아님 (e.g. 정제되지 않은 빅데이터)
  • 소음 대비 신호(관련 있으면서 정확한 정보)의 비율을 높여야 함

• 핵심은 "어떻게 매일 조금씩 더 효과적으로 자랄 수 있을까?"

  • 지금 당장 현실에서 내게 필요한 것 찾기
  • 그에 관련된 이론적 근거를 딱 필요한 만큼만 학습
  • 배우자마자 즉시 써먹어 셀프 피드백, 그리고 반복

• "당장 내 현실에서 필요한 건 어떻게 찾지?"

  • 일기쓰기를 통해 메타인지 높이기
  • 내가 한주간 어디에 많은 시간을 썼는지 기록해보고, 그걸 더 잘하기
  • 자주하는 활동일수록 개선과 셀프 관찰, 피드백 받기에 더 좋음

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

주니어로서

나의 지식과 행동이 여기에 부합되는지 점검. 특히 부족한 역량을 집중해서 계발하기 위해 목표와 계획을 세워 실천.

주의점

위에서 소개한 5가지의 필수 역량들은 모두 상호 보완적이다.
그리고 이 연구는, 여타 연구들과 마찬가지로 절대적 진리가 아니다.
역량들은 충분조건이 아닌 필요조건이다.
따라서 이것들을 좋은 목표이자 지향점, 또는 경유지로 삼는 것은 괜찮지만 최종 목적지로 볼 필요는 없다.

점검하기

개발은 학문의 영역이 아니라 단순히 이 사실을 알고 있는 것이 중요한 것이 아니라 의식적으로 훈련을 하는 것이 중요하다. 라는 요즘IT의 발행 콘텐츠를 접한 기억이 어렴풋이 떠올랐다.

스스로 점검해 봤을 때 2. 근거 기반 의사결정을 연습한다, 특히 5. 효과적으로 꾸준히 학습한다 부분은 매번 부족하다고 느끼는 부분이며 의식적인 훈련이 필요하다는 생각을 자주 해 왔던 부분이다.

• 근거 기반 의사결정이 부족한 이유는 무엇일까?
• 효과적으로 꾸준히 학습하지 못하는 이유는 무엇일까?

작년 한 해를 돌아보며, 근거 기반 의사결정, 효과적인 학습이 부진한 이유에 대해 질문을 던지며 고민해 봤다.
추려보면 아래와 같다.

• 탈선없이 가이드에 따라 학습하려는 습관

  • 처음부터 완벽하게 처리하고 싶다는 너무 이상적인 생각
  • 틀리더라도 스스로 충분한 근거를 생각해보는 대신 정답을 좇으려는 습관
  • 시스템의 부재

• 깊이 있는 학습을 해야한다는 포괄적인 목표로 대중없이 학습하는 습관

  • 학습 시간의 길고 짧음에 상관없이 확실하고 구체적인 학습의 '목표·목적'을 생각하지않는 습관
  • 당장 필요한 이론적 근거들이 충분히 수집되었음에도 불구하고, 눈에 보이는 비슷한 내용의 정보를 모두 읽어보는 습관
  • 한 주간의 학습 시간을 데이터화하고 분석하지 않는 태도

막상 적고 나니 쓰린 것 같다. 그렇다면 어떻게 계발할 것인가?
아래와 같은 가이드라인을 잡아봤다.

• 컴포트존에서 벗어나기
  튜토리얼에 따라 학습하며 따라 완성하는 프로젝트 대신 기능을 덧붙이고 확장하며 진짜 개인의 프로젝트로 만들려는 시도해 보기. 혼자서는 처음 주제를 정하는게 가장 어려워 차선책으로 마련한 방법이다. 도움은 받되 설계와 구현에서 충분한 근거와 고민을 함께 가져가는 것이 목표이다.

• 구체적이고 명확한 목표 수립
  본인 스스로 '개발이 처음이니까', '나는 전공 지식이 부족하니까 오래 걸릴 수밖에.' 라는 핑계로 2년 가까이를 '무한한 시간' 처럼 학습하는 습관을 올해부터는 버리기로 했다. 실제 올해 노션 페이지의 상단에는 목표 수립 규칙이 명시되어 있다.

  목표 수립 규칙

  • 구체적일 것 (specific)
  • 측정 가능할 것 (measureable)
  • 성취할 수 있는 것 (attainable)
  • 현실적일 것 (realistic)
  • 시간이 제한적일 것(time-bound)

• 시스템 구축
  의도적인 큰 노력 없이도 양질의 정보가 내 주변에서 지나가게 하기. 즉, 탁월한 사람들이 많은 곳으로 나를 가져다 놓기.
  작년부터 해당 부분을 구축하기 위해 소심한 태도를 버리려 다양한 노력들을 시도하고 있다. 실패 가운데서 발견한 좋은 기회로 올해는 좋은 시스템을 구축할 수 있을 것 같다는 기대감을 가지고 있다.

  추가적으로 쌓여있던 IT 뉴스레터도 대충 읽고 무시하지 않고, 속독하고 주차별 기록 남기기

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

질문들을 던져보기

• 프론트엔드 도메인에서 훌륭한 코드란 무엇일까? 어떻게 더 좋은 코드를 짤 수 있을까?
• 프론트엔드 도메인에서 더 나은 의사결정을 하려면 어떤 근거를 어떻게 수집해야 할까?
• 프론트엔드 도메인에서 동료의 효과적 의사결정을 돕는다는 건 어떤 의미인가?
• 프론트엔드 도메인에서 내 작업의 현재 가치를 어떻게 측정할까? 어떻게 극대화할까?
• 프론트엔드 도메인의 지식을 꾸준히, 효과적으로 학습하려면 어떻게 해야 할까?

답해보기

• 프론트엔드 개발자에게 조직이 기대하는 역할
  • 웹 특화, 제품 특화, 운영 특화
• 트랙별 주요 특장과 장단점
• 역량 향상 방법
• 이후 시니어로 가능한 커리어

신기하게도 탁월하다라고 인정받는 분들의 말을 관찰하면 비슷한 맥락이 존재한다.
좋은 근거들을 얻기 위해 배휘동님의 개발 블로그에서 '삶의 밀도를 높이는 여정' 뉴스레터를 구독하였다.

논외의 이야기이지만, 탁월한 개발자 글까지 잘쓰는 것일까?

개인적으로는 코드 베이스의 개발 지식에 대해 공유해주시는 분들도 좋지만, 경험에 기반하여 스스로 다시 생각해보기 만드는. 나를 관통하는 충고들을 공유해주는 분들은 뇌리에 깊이 박히는 것 같아 더욱 값지다. 또한 중간 중간 스스로를 돌아보고 점검하고, 정리하는 여유도 필요한 덕목인 것 같다.