미국 일잘러 시니어 개발자가 되기 위한 팁
23년 10월, 이웃집 주민 Principal Engineer와 커피챗
최근에 우연한 계기로 이웃집 주민 Principal Engineer 분과 카페에서 얼굴을 마주하며 커피챗을 나누게 되었다. 곧 타주로 이사를 가게 되셔서 기존의 가구들을 아파트 이메일을 통해 팔고 계셨는데 그 목록에 있던 가구들 중 하나를 우리 집에 들이게 되면서 얘기를 나누다가 이 분도 개발자라는 것을 알게 됐다.
현재 직장에서 일을 시작한 이후 지금까지 계속 재택으로 근무하다 보니 사실 같은 직종에 일하는 분들을 만나뵙는 게 하늘의 별 따기였다. 그래서 약 30 년이 넘는 시간을 개발자와 매니저의 일을 오가며 이 직종에 종사하신 이웃 주민분을 만나게 되어 너무 반가웠다.
특히 여러 일적인 고민들이 한 겹 한 겹 쌓이고 있던 터라, 이때가 기회다 싶어 이 분에게 타주로 이사 가기 전 커피챗이 가능한지 여쭤봤다. 문자 메시지를 보낸 지 10분도 채 안 되어, 'Sounds good!'이라는 쿨한 답장을 받았다. 흔쾌히 수락해 주신 Principal Engineer 이웃분 덕분에 평소에 듣기 어려운 개발자로서 필요한 자질들과 일에 관한 조언을 많이 듣게 되었다.
아래는 그중에 기억에 남았던 대화 내용 정리.
Q. How to become a "good" engineer?
A.
: You need to think "What kind of influence you give to your team"
: Bring ideas to the organization to make the product better, team's life better
‘좋은’ 개발자란 무엇인가-,라는 고민이 있었다. 똑같은 개발 일을 하더라도 사람마다 특화된 분야가 다 달랐다. 어떤 사람은 다른 사람들보다 월등히 디버깅에 능숙하고, 또 다른 사람은 아키텍처 디자인 리뷰나 코드 리뷰를 숲을 보는 시선으로 해 주는 반면, 누군가는 재빠르게 새로운 언어나 시스템에 온보딩하는 능력이 탁월했다.
그래서 오랜 기간 이 일에 종사한 개발자분에게는 어떤 사람이 좋은 개발자인지에 대한 질문을 하게 됐다. Principal engineer분이 말씀하신 건 간단명료했다. “우리 조직의 프로덕트를 더 좋게 만들고, 팀원들의 일(work)상을 더 개선시키는 것.”
위의 대답에 대해 누군가는 이렇게 질문할 수도 있을 것이다. “도대체 어떻게 그런 걸 알아낼 수 있냐”라고. 특히 수동적으로 주어진 업무만 완료하면 능동적으로 생각하는 게 힘들 수도 있다. 이렇게 떠오르는 질문에 대해 조언해 주신 말씀은 다음과 같다.
Think beyond the feature
: Question to ask yourself frequently
: Ask to yourself "Why that feature is important?" for at least five times, which also gives you a broader understanding
: Go all the way back as much as you can, towards your organization or towards your inner motivation
어떤 기능을 구현하기 전에 더 멀리 생각해 보라
: 스스로에게 ‘왜 기능이 꼭 필요한가?’라는 질문을 적어도 5번 이상해라. 이렇게 질문하면서 그 기능에 대해 더 넓은 폭으로 이해할 수 있을 것이다.
: 기능을 구현하기 전에 너의 조직과 너의 내적 동기까지 자세히 들여다보며 왜 꼭 이걸 해야 하는지를 물어보라.
그리고 어떤 특정한 업무에 대해 확신이 든다면 그다음은 구현을 직접 하는 것뿐만 아니라 매니지먼트 레벨에까지 왜 이게 꼭 필요한지를 설명하고 설득하는 단계가 포함된다. 막 일하기 시작한 주니어 개발자일 때는 이런 일이 별로 없지만 시니어가 되고 Principal 레벨이 되기 위해선 꼭 필요한 능력이다. 다음은 그에 대한 질문.
Q. When you find some feature is good, and you want to bring to your org, how you can convince your upper level engineer/manager?
(답변으로 자신이 만난 주니어 엔지니어를 예로 들어 말씀해 주셨다)
A : He talked it thorough why that is important, tried to understand the implication of the action, and demonstrated by himself, and then of course, brought that data in demo meeting
즉, 누군가를 설득하기 위해선 언제나 그에 알맞은 조사와 데이터를 가지고 함께 발표해야 된다. 당연한 얘기이면서도 일을 할 때면 주어진 업무를 기한 안에 빨리 해야 된다는 생각 때문에 분명히 다른 엔지니어들에게 뒤에 이어질 예상 질문이 있을 것임에도 불구하고 불충분한 내용으로 물어볼 때가 있다. 언제나 유념해야 되는 부분.
그 외에 대화 중간중간 잊지 않기 위해 정리한 노트 테이킹 내용들도 정리했는데 뻔한 내용인 것 같으면서도, 실제 밀접하게 일하는 분에게 들으니 새롭게 와닿았다.
1."Take notes for word document. You create your own cheat sheet"
언제나 워드닥에 노트 테이킹 할 것. 그렇게 노트 테이킹한 내용으로, 너만의 칫싯을 만들어라.
노트 정리를 항상 할 것. 이건 어디에서든 빠지지 않고 등장한다
2. "If you care about what others care about you, it’s not gonna help you. You are a continuous learner."
다른 사람에 대해 너무 신경 쓰는 순간, 너에게 도움이 되는 건 아무것도 없다. 언제나 꾸준히 배워나가라.
이건 개발자가 아니더라도 모든 삶의 전반에서 와닿는 말. 일에서 부족한 부분이 스스로가 너무 잘 보일 때, 위축될 필요 없이 그저 꾸준히 배워나가기.
3. "I tried to leverage anything I can get from any industry"
내가 이 산업에서 배우고 얻을 수 있는 모든 것을 레버리지 해라.
개발자도 요즘엔 정말 직종이 세분화되어있다. DevOps를 전문적으로 맡는 사람, deploy를 전문적으로 맡는 사람, AI, microservice, platform 등등. 그래도 언제나 새로운 기술에 항상 열려있고 그걸 레버리지 할 수 있는 능력이 있어야 된다는 것.
여담으로, 나와 함께 자리에 있었던 J에게도 openAI 쓰는 거 회사에서 허용하는지 물어보셨다. 그래서 우리가 회사 vpn 쓰면 막혀있지만 누구나 다 쓴다고 말하면서 서로 웃었다.
4. "You solve their problem, you will be successful."
다른 사람의 문제를 해결해 주는 순간, 네가 성공할 것이다
다른 사람의 문제를 해결해 주면 오히려 그게 나의 성공으로 이어진다. 팀의 일의 효율성을 늘리기 위해 어떤 점을 향상할 수 있는지 항상 능동적으로 생각할 것.
5. You have the integrity for yourself (I got a recognition after 2 years later for what I'd contributed)
'Integrity'는 단어를 회사 일을 하면서 많이 접하게 됐다. 이전에 매니저와의 1:1 면담에서도 들었다가 이분의 입을 통해서 또 이 단어를 들으니 integrity가 미국 회사에서 꼭 유념해야 되는 부분이라는 것을 다시금 알게 됐다.
특히 Principal Engineer 분의 개인적인 경험담이 나에게 뜻밖의 위로가 됐다. 지금 당장 일에서의 성과를 인정받지 못한다고 해도 너무 조급해할 필요 없다는 것. 2년 뒤에 인정받을 수도 있으니, 언제나 그 자리에서 묵묵히 자신의 일을 계속 발전시켜 나갈 것.
(매니저가 이전에 나한테 말해준 integrity 관련 대화 내용 ▼)
미국 직장인 개발자 일지: 믿고 맡길 만한 사람이 되기 & 어떻게 하면 일을 좀 더 잘할까 (feat. 세이노의 가르침)
*Integrity란?
말과 행동, 생각이 일치하는 상태. 즉 자신이 옳다고 믿거나 생각하는 것을 말과 행동을 통해 일관성 있게 실천하는 것.
리드 엔지니어 분이 조언하신, 일할 때 가장 중요한 것:
Measure the quality and the time (업무 완료의 질과 얼마나 걸리는지를 측정하기)
Cycle time: how fast it is to be done - the ability to write code in a less time, can we get 10 times better? (효율적인 방법 구축하기: 코드를 더 빨리 작성할 순 없는가? 10배 더 개선시킬 수 있는 방법은 없는가?)
약 2시간의 시간 동안 시간 가는 줄 모르며 얘기했던 어느 날. 신기한 건, 당시 내가 온콜(Oncall)을 하며 고민하고 내린 깨달음과 대화 내용이 비슷했다는 것이었다.
일주일 간 온콜을 하는 동안 매일 오후 10시에 느지막이 노트북을 닫으며 다음과 같은 메모를 했었다.
| 메모를 정말 잘하자
일과 관련된 메모를 잘해 놓자. 그리고 이 모든 게 어느 정도 분류된 메모여야 된다.
예를 들면,
에러/디버깅과 관련된 것들 따로, 어떤 logging message들로 분류해서 디버깅하는지 정리
회사 아키텍처 디자인 내용도 따로 정리
북마크 (자주 쓰는 CLI 들은 북마크 해서 효율성을 높여야 함. 그때 그때 찾지 말 것.)
매니저가 부탁한 내용들은 랩탑 앞에 스티커 메모지로 붙여놓고 제일 우선순위로 끝낼 것
그날 못다 한 일들은 메모지로 적어놓고 다음날 리마인드 해서 끝낼 것.
| 똑같은 실수를 반복하지 말자
그 전의 PR 들에서 교훈을 얻고 절대 같은 실수를 반복하지 말자.
항상 염두해 들어야 할 것:
NPE check
String을 null로 check 하기보다는 StringUtils.isEmpty로 체크할 것
add general error log
code change에 대한 exception이 모두 다 핸들 되었는가
we should not recreate new variable in each reconciliation. We should store the map as a class-local variable.
| 어떤 task가 주어졌을 때 확장해서 생각하기
특정 코드 체인지 업무가 주어지면 항상 고려해야 될 것:
Unit test도 포함돼 있나?
metrics/alarms 가 필요한 PR인가? (그렇다면 이것도 주어진 기한 안에 함께 끝낼 수 있는 건가?
runbook을 만들어야 되나?
별도의 다른 팀 dependency가 들어간 테스팅이 들어가나? 그렇다면 어떤 테스팅을 해야 하나? 그 테스팅과 관련된 pre-requisite change는 이미 다 만들어진 상태인가? 아니라면 어떤 change를 만들어야 되고 며칠을 잡아야 하나?
Integration testing이 필요한가?
| 배워가는 과정을 소중히 여기자
일의 결과/성취에 집중하다 보니 더 내가 못하는 부분에 주목하게 되고 가끔 자신감이 떨어질 때가 있었다.
내가 개선해야 할 부분의 피드백을 받을 때 한동한 혼자 '나는 왜 바보지'라며 속상해했다.
그러나 개선해야 할 점은 개선해야 할 점이고, 아직 개선할 게 있다는 것에 감사하고 조금 더 보완하는 그 과정을 소중히 감사히 여기자.
곧 다시 매니저로 새로운 곳에서 일을 시작하신다는데 타 주에서도 안전히 잘 도착하고 지내시기를 바라며, 링크드인(LinkedIn) 친구를 맺었다. 이 날의 기록들도 매일매일 책상 앞에 붙여두고 생각하며 일해야지.
효율성,
남을 도우면서 나를 성장시키기,
언제나 10배의 더 잘할 수 있는 방법은 없는지 고민하고 실천할 것.
