주니어 개발자일 때 알았으면 좋았을 것들
3년 차 해외 개발자로서 체득한 일잘러가 되기 위한 5가지 팁
내년(2024년) 초가 되면 해외 개발자로 일한 지 꽉 찬 3년이 된다.
© cgower, 출처 Unsplash코로나 시국에, 특히 유학생 신분으로 해외에서 불안정한 취업 준비의 시기를 거쳤다. 그래서 무지하게도 취업만 성공하면 올림픽 금메달 선수처럼 내 목표는 다 이룬 것이라고 착각했다. 특히 첫 개발자라는 직무를, 입사 초부터 코로나로 인해 재택으로 시작하게 되면서 아직까지 팀원 전체를 대면으로 만난 적이 없다. 아무래도 팀원들이 캘리포니아, 시애틀, 그리고 인도 각지에서 근무하고 있는 것도 한 몫했다. 그렇기에 직접 얼굴을 맞대고 일을 시작했으면 더 수월하고 빨리 알았을 것들을 조금 늦게, 혼자서 부딪혀가며 깨닫게 되었다. 그래서 개발자 한정 직업적 내용보다는 전체적인 업무에 대해 내가 미리 알았으면 좋았을 태도들에 대해 포괄적으로나마 적었다. 혹시 직군이 겹치지 않더라도 필요한 부분만 편하게 읽으면 좋을 것 같다.
| 1. 업무일지를 무조건 기록으로 남기기
하루 동안 내가 한 일, 그날 새롭게 배운 내용, 에러가 생겼다면 어느 부분에서 막혔으며 어떻게 해결했는지에 대하여 적는다. 이때 에러 발생과정과 해결방법을 적는 것이 중요하다. 나중에 비슷한 문제가 생겼을 때 디버깅 하는 시간을 단축하고 다른 팀원이 도움을 구할 때도 바로 알려줄 수 있다.
이걸 뼈저리게 깨닫게 된 것은, 처음 업무를 시작하는 날 외계어 마냥 들린 네트워크 관련 용어들을 미팅 자리에서 들었을 때였다. 실제 업무와 학교, 또는 영상으로 배운 데이터 구조와 코딩 지식은 아예 그 근본부터가 달랐다. 특히 대학교에서 Computer Science(컴퓨터 학과) 전공으로 졸업했음에도, 나는 조기졸업을 위해 필수과목 그 이상을 더 수강하진 않았다. 그래서 학부 때도 제대로 공부한 적 없는 네트워크와 distirbuted system, 마이크로 서비스 관련 일을 하려 하니, 자신감이 없어지는 매일이었다.
그러나 당장 옆에 어깨를 툭툭 치며 물어볼 팀원은 없었다. 슬랙으로 메시지를 보내거나 다른 시니어 개발자들의 미팅 시간이 괜찮을 때까지 기다려야 했다. 그렇기에 내가 주도적으로 공부하는 연습이 필요했다. 나 같은 경우, 초반에는 모르는 내용들을 그때 그때 구글링하며 수박 겉핡기 식으로 공부했는데 워낙 기억력이 안 좋아 이전에 찾았던 내용을 또 찾는 나를 발견하게 됐다. 즉, 기록을 하며 언제 무엇을 찾았고 똑같은 내용을 또다시 알아보는 시간을 줄여야 된다.
| 2. 한 주의 기록일지를 복기하고 체계화하기
기록으로 남기는 것보다 더 중요한 것은 내가 그걸 제대로 이해했는지와 혹시 나중에 참조사항으로 필요할 때 쉽게 찾을 수 있게 정리를 해 뒀느냐다. 특히 업무 기록을 다시 섹션별로 내가 한 주요 성과들로 나열하면,
나중에 이직이 필요해서 새롭게 레쥬메를 업데이트시켜야 할 때 큰 도움이 된다. 그때 한꺼번에 기억 저 뒤편으로 사라진 내용들을 끄집어내기보다 그날 그날 정리한 내용들이 있으면 레쥬메 업데이트와 인터뷰 준비가 훨씬 수월해진다.
| 3. 질문을 할 때는 똑똑하게
어느 직군에나 그렇겠지만 개발자에게 특히 필요한 능력은 "디버깅 실력"이다. 왜 에러가 발생했는지 그 원인을 분석해 나가고 트랙킹 하는 것이 업무의 대부분이라고 해도 과언이 아니다. 그리고 주니어 개발자라면, 당연히 처음에는 에러를 어디에서부터 어떻게 해결해 나가야 할지 감이 안 잡힐 때가 많다. 결국 시니어 개발자에게 질문을 할 수밖에 없는데, 이때 질문을 하기 전에 다음과 같은 작업들을 미리 하면 좋다.
- 해당 에러에 대해 구글링/팀에서 사용하는 메시지 앱에서 미리 검색을 해 보았는가? 거기에 나오는 방법들로 시도를 해보았는가?
- 시도를 해 보았다면 어디에서 막혔나?
- 어디에서 막혔는지까지 알았다면, 질문은 두괄식이 좋다. 예를 들어, "~라는 에러에 대해 또 다른 방법이 있나? "라는 질문을 시작으로 불렛 포인트로 자기가 직접 해본 방법을 나열하는 식이다.
시니어 개발자들도 본인들의 일이 많기에 질문이 길거나 많으면 제대로 읽지 않은 경우가 많다. 그래서 요점만 간결하게, 그리고 이전에 자신이 할 수 있는 최대한의 방법으로 디버깅했음을 보여주는 사례와 태도가 필수요건이다.
| 4. 여유가 된다면 시스템 디자인 공부도 미리 하는 걸 추천한다
아직 풀타임 경험이 없는 주니어 개발자를 뽑을 때, 보통은 세 개의 라운드에 걸쳐 보는 코딩(coding) 인터뷰와 함께 행동 면접(behavioral question)이 전부인 경우가 많다. 그러나 연차가 쌓이면 앞에서 말한 2가지 유형의 인터뷰 외에도 더 물어보게 되는 것이 있는데, 바로 시스템 디자인(system design)이다. 경력을 가진 개발자들의 시스템 설계 역량을 판단하는 질문이다.
아직 현재 회사에서 이직을 해 보진 않았지만, 굳이 이직이 아니더라도 미리 이걸 공부했으면 얼마나 좋았을까, 하는 아쉬움이 있다. 그때 그때 구글링하며 알음알음했던 내용들이 시스템 디자인 책에 다 나와있었기 때문이다. 취업해서 일만 하면 될 줄 알았는데, 역시 배움은 끝이 없다.
| 5. 회사의 큰 구조와 틀을 익히기
자체 팀 서비스가 잘 된 회사에 들어가면 팀 내에서 쓰는 특정 툴들이 있다. CLI(Command Line Interface)라던가, DevOps와 같이 에러가 생겼을 때 모니터링 하는 툴들, CI(Continuous Integration)/CD(Continuous Delivery)를 위해 쓰는 툴들은 어떤 것들이 있는지 재빠르게 흡수하는 능력이 필요하다. 처음엔 이 모든 것들이 생소해서 많이 버벅거렸는데, 입사 초기에 시간을 더 내서라도 마치 온라인 홈쇼핑몰에서 옷 고르듯이 이것저것 알아봤으면 더 쉽게 적응하지 않았을까라는 생각이 든다.
개발자라는 직업으로 연차가 쌓일수록 더 간절해지는 소망이 있다면 "실력 있는 개발자"가 되었으면 좋겠다는 것이다. 즉, 일잘러가 되고 싶다. 이 직군에서 일하면 일수록 매번 자잘 자잘한 실수를 하고 부족한 것 투성이임을 더 느끼기에 그런 게 아닐까 싶다. 모쪼록 이 글이 이제 막 개발자로 일을 하는 분들에게 도움이 되었으면 좋겠다.
p.s.: 아마 실력있는 개발자 분들은 이런 글을 쓰고 있지도 않겠지?
