주니어 개발자 분들께 전하는 경험과 조언
저는 처음에 몇 번 좌초 당했습니다. 사수 분들이 친절히 체크 포인트로 환생시켜 주시고 다시 좌초 시키셨습니다.
설레는 마음으로 개발자 커리어를 시작한 저는 첫 번째 회사에서 2년의 재직 기간 중 첫 1년을 거의 의사 선생님들의 인턴 기간처럼 모든 직군을 하나씩 찍먹(?) 해 보는 기간을 가졌습니다. 4년차가 된 지금, 주변 개발자 분들께 이 이야기를 들려 드리면 대다수의 분들이 ‘?????’, 혹은 ‘도대체 어떻게 버티셨어요..?’, ‘나였으면 바로 퇴사했다’ 와 같은 반응들을 보여 주셨어요.
그래서 입사하고 처음 1년 동안 제가 얼마나 다양한 직군을 경험해 봤는지 한 번 정리해 봤습니다.
🤔 QA & Android 개발 3개월 → QA & 웹 퍼블리싱 2개월 → 웹 퍼블리싱 & 백엔드 개발 (Spring Boot & PHP 기반 API 개발 및 유지보수) 5개월 → Front-end 개발 (2개월 + a)
위에 적혀 있는 다양한 직군들을 그냥 ‘체험만’ 해 봤다면 제 첫 1년 동안의 커리어는, 아니 어쩌면 저는 개발에 대한 흥미를 복구조차 안 될 정도로 잃어 버렸을 것 같습니다. 첫 1~2년 때 어떤 환경에서 어떻게 일하고 증명하고 배우는지가 미래에 어떤 개발자로 성장하고 나아갈지 정해지는 데 정말 큰 영향을 끼친다고 믿어요.
하지만 제가 몸담고 있던 개발팀의 리더 분들은 감사하게도(?) 저를 편하게 지내게 하실 마음이 전혀 없었습니다. 모든 직군을 해당 업무 담당자 분께 스파르타 식으로 배우면서 바로 실무에 참여하도록 하셨습니다. 매주 정기 배포가 이루어지는 앱부터 서버, 그리고 QA 과정에서 조금이라도 실수를 했다간 바로 라이브 서비스 장애였고, 프로덕트에 막대한 영향을 주기 때문에 모든 힘과 정신을 끌어모아 집중할 수 밖에 없었습니다.
새로 접한 직군의 업무를 실수 없이 바로 진행하려면 공부를 엄청 해야 할 텐데 공부는 언제 해? 라고 궁금해 하실 수 있는데, 퇴근하자마자 다음 날 출근하기 직전까지 미친듯이 공부하고 아침에 담당 시니어 개발자 분께 확인 받고 토의하는 나날을 반복했습니다. 덕분에 힘들었던 대학교 시절보다도 훨씬 많은 공부량을 이뤄낼 수 있었습니다.. 🥲
1년 간의 지옥 훈련 덕분에 Front-end 개발에 정착한 후 사수 없이 혼자 개발을 하고, 프로젝트에 필요한 Flutter 앱을 함께 개발하는 상황에서도 당황하지 않고 빠르게 학습해서 문제를 해결할 수 있었습니다. 혼자 자바스크립트를 공부하면서 백엔드 개발자 분들과 프로젝트를 진행하다 보니, 지금은 상상할 수 없는 Vanilla JS 와 Kendo UI Framework 만으로 SPA (Single Page Application) 방식의 프로젝트를 모두 구현했습니다.
이 때 Vanilla JS 로 웹 애플리케이션 내부에서 지속적으로 변하는 데이터와 UI를 관리하는 방법에 대해 계속해서 고민하고 다양한 방법을 시도해봤었는데요, 이러한 경험은 Front-end 개발자로 이직을 시도할 때 React, Vue와 같은 모던 웹 프론트엔드 기술 스택을 실무에서 전혀 다뤄본 적이 없음에도 불구하고 대부분 회사의 서류 전형을 통과하고 기술 인터뷰에서도 면접관들의 흥미를 끌어내는 좋은 소재였습니다.
이직에 성공하여 재직 중인 지금 회사에서는 React, Next.js와 TypeScript를 비롯한 다양한 기술을 활용해 Front-end 개발을 하고 있습니다. 메인 업무와 함께 Python을 활용한 PR 리마인더 슬랙 봇, JavaScript, Selenium WebDriver를 활용한 점심 메뉴 크롤링 슬랙 봇 등을 개발하거나 인프콘 2023 기업 부스 기획 및 운영, 사내 프로덕트 세미나 기획, 발표와 같은 DevRel 활동, 개발 커뮤니티에서의 네트워킹을 함께 하며 개발을 다양한 분야로 확장시켜 나가는 “개발자스럽지 않은 개발자”로 열심히 앞으로 한 발자국씩 나아가고 있습니다 ✨
신입 개발자로 개발자 커리어를 시작한 이후 한 치 앞을 예측할 수 없는 주니어 개발자 생활과 이직을 겪으면서 느끼고 배웠던 부분들을 종합하여 지금 무럭무럭 자라나고 계신 주니어 개발자 분들께 몇 가지 조언을 드려 보고자 합니다.
문제 해결에 있어서 코드로 구현하는 건 가장 마지막 단계다
일반적으로 프로덕트를 개발할 때 우리는 새롭게 만들어야 하는 기능에 대해 기능의 필요성, 목적 등에 대해 전달 받고 기획자, 디자이너 분들로부터 화면 설계서, 기능 정의서, Figma 와 같은 문서를 전달 받게 됩니다. 그리고 이러한 문서를 분석해 요구 사항을 정의하고 구조를 설계해 기능을 구현합니다.
이 때, 전달받은 문서 그대로 개발을 진행하는 걸 우리는 Waterfall 방식이라고 부릅니다. 클라이언트(고객이 될 수도 있고 사내의 PM, 디자이너, 기획자가 될 수 있음) 가 원하는 대로 개발로서 구현해 줄 수 있다면 개발자로서의 역할을 다 했다고 볼 수 있습니다.
하지만, 개발자는 단순히 개발을 잘 하는 사람이 아닌 팀에서 기술에 강점을 가지고 있는 “프로덕트 메이커”의 일원입니다. 새롭게 만들어야 하는 기능에 대해 비즈니스 적으로 함께 고민해보고, 전달받은 문서를 보고 디자이너, 기획자와 함께 유저의 입장에서 더 나은 UI / UX 를 제공할 수 없을지 끊임없이 의견을 제시해야 합니다. 개발자의 강점을 살려 의견을 제시하는 과정에서 관련된 데이터(Database에서 추출한 관련 데이터, Clarity 등을 통해 얻은 서비스 내 유저 히트맵 등) 를 공유해 더 나은 의사 결정을 이뤄내는 데 일조할 수도 있겠죠. 이렇게 제품에 대해 끊임없이 학습하고 이해하며 이해 관계자들이 더 나은 프로덕트를 만들기 위해 소통하고 함께 일하는 프로세스를 Agile 방식이라고 부릅니다.
이렇게 의사소통을 하면서 굳이 개발로 풀어내지 않더라도 기획을 변경하거나 디자인, 플로우를 일부 수정하는 식으로 문제를 해결할 수도 있습니다. 정말 개발과 기술로 풀어내야 하는 문제들을 정제해서 가장 마지막 단계에서 코드를 구현하는 것이 좋은 프로덕트를 만들어 내고 개발 리소스를 효율적으로 활용할 수 있는 길이라고 생각합니다.
모든 개념을 일반화(추상화) 해 보자
위에 적혀있듯이, 저는 첫 회사에서 Front-end 개발을 JavaScript ES7, jQuery, Kendo UI Framework 로만 경험했었습니다. React, Vue, TypeScript와 같은 모던 웹 프론트엔드 기술은 개인적으로 조금씩 공부만 해 봤을 뿐, 실무에서는 한 번도 다뤄보지 못했습니다. 하지만 이직을 위해 여러 회사에 지원했을 때 서류 전형은 거의 다 통과했고, 기술 인터뷰에서도 좋은 평가를 받았습니다. 어떻게 가능했던 걸까요?
바로, 특정 기술에 집중하지 않고 기술들이 가지고 있는 근본적인 배경과 원리에 집중했기 때문이라고 저는 생각합니다. React를 비롯해 최근에 모던 웹 프론트엔드 개발에 쓰이고 있는 기술들은 . 하지만 결국 이러한 기술들이 왜 나왔을까 에 초점을 두고 생각을 해 보면 “지속적으로 변화하는 데이터에 따라 미리 만들어 둔 디자인 (컴포넌트)를 보여주는 과정을 편하게 관리하자” 라고 생각합니다.
저는 <script type=”template”> 이라는 태그 안에 정적인 컴포넌트 디자인을 구성하고 내부에 동적으로 표현해야 하는 데이터는 {value} 와 같이 일정한 정규식을 구성했어요. 그리고 동적으로 컴포넌트를 렌더링해야 할 때, template의 내부 코드를 가져와 API 응답값 등을 정규식 코드에 replace 해서 DOM Tree에 Node로 추가했었습니다. 이렇게 하다 보니 자연스럽게 DOM 구조에 영향이 가면서 reflow가 많이 발생했고, 자연스럽게 React의 Virtual DOM이라는 개념이 어떤 배경에서 탄생했을 지 이해하고 공감할 수 있었습니다.
이런 식으로 최근에 정말 많은 언어와 라이브러리, 프레임워크가 시장에서 활용되고 있지만, 결국 왜 이 기술이 탄생하게 됐고 어떤 특징을 가지고 있는지 분석하다 보면 모두 비슷한 고민과 문제를 해결하기 위해 시작되었다고 느낍니다. 따라서, 핵심적인 원리를 이해하고 있으면 이러한 기술은 개념을 확장해 나가는 식으로 빠르게 공부하고 이해할 수 있다고 믿습니다.
(실제로 이직을 진행하던 중 모 대기업의 면접관 분께서 본인도 jQuery에 Redux를 활용해 상태관리를 하면서 Front-end 개발을 하신 경험이 있는데, 결국 다 똑같은 개념이기 때문에 React로 개발하는 건 공부해서 충분히 할 수 있을 것 같다고 하셨습니다. 그리고 최근에 이렇게 개발을 한 사람을 또 볼 줄은 몰랐다고 신기해하셨습니다)
회사는 최고의 샌드박스다
(주의) 자유롭게 사고쳐도 된다는 뜻은 절대 아닙니다.
‘모래 상자’라는 뜻을 가지고 있는 샌드박스는 ‘자유롭게 실험하고 배울 수 있는 공간’을 의미하는 용어입니다.
평소에 책과 다양한 자료를 통해 개발적인 지식을 공부하고 나면 이를 실제로 활용해 보면서 내 것으로 만들 기회가 많지 않습니다. 하지만, 회사 프로젝트를 개발하면서 자신이 공부한 내용을 직접 구현해보고, 그 결과를 유저들이 사용하는 것을 보며 어떤 부분이 잘 작동하고 어떤 부분이 개선되어야 하는지 직접 확인할 수 있습니다. 단, 새로운 시도를 실제 라이브 중인 서비스에 적용할 때에는 항상 장애가 발생할 여지가 없는 지, 함께 개발을 하는 동료, 이해 관계자들과 충분히 이야기 해 보고 진행해야 합니다.
추가로, 간단한 사이드 프로젝트나 토이 프로젝트를 구현해 사내 구성원들에게 배포하는 것도 좋습니다. 저는 업무 시간 외에 개인적으로 회사 생활에 도움이 될 만한 점들을 추려내 슬랙 봇 등을 개발했었는데요. 평소에 해 보고 싶었던 슬랙 봇 개발과 웹 크롤링을 공부해보고 사내 구성원들의 좋은 반응을 보면서 뿌듯함도 느낄 수 있었습니다.
즉, 회사라는 샌드박스에서 자신만의 방식으로 실험하며 성장하되 주변 동료와 협력하여 서비스 안정성 등 필수적인 요소도 항상 유지할 수 있어야 합니다. 이런 경험이 바탕이 되어 앞으로 다양한 문제 상황에서 대처할 수 있는 능력을 키우게 될 것입니다. 이런 식으로 회사라는 샌드박스를 잘 활용해 나와 회사 모두 성장하는 경험을 축적하면, 개발자로서의 역량을 한 단계 더 향상시킬 수 있습니다.
기회는 예고 없이 찾아온다. 왔을 때 잡는 건 실력이다
‘받은 만큼만 일을 하면 된다’ 라는 문장에 저는 개인적으로 동의하지 않는 편입니다. 틀렸다는 건 절대 아니에요. 바라보는 관점에 따라 충분히 일리 있는 이야기입니다.
제가 첫 회사에 입사한 후 팀장님께 들은 이후로 개발자 커리어 내내 좌우명으로 새기고 있는 문장이 있습니다.
💡“돈 받고 일을 하는 순간 우리는 모두 프로다. 1군, 2군과 같이 실력에 따라 레벨이 나누어질 수 있어도 우리는 프로의 자세로 최선을 다 해야 한다”
이러한 좌우명에 따라 항상 제 능력으로 이뤄낼 수 있는 최대한의 결과물을 얻기 위해 노력하고 놓친 부분은 없는 지 끊임없이 의심하고 체크하다 보니 자연스럽게 일을 하는 데 소모되는 에너지도 많아지고 야근도 적게 하는 편은 아닙니다.
누구에게든 예고 없이 생각하지도 못했던 기회들이 찾아 옵니다. 평소에 정말 해 보고 싶었던 프로젝트에 참여할 기회를 제공 받거나, 해 보고 싶었던 업무를 “한 번 해 볼래?” 라는 식으로 말이죠. 이렇게 행운이 찾아왔을 때 본인이 미리 준비가 되어 있고 사전에 충분한 공부가 이루어져 있어야 확실하게 잡아서 내 커리어를 한 단계 발전시킬 수 있다고 생각합니다. 그렇기 때문에, 평소에 본인에게 주어진 업무가 작은 사이즈 이더라도 최선을 다해 완성하고 어떻게 확장시켜 나갈 수 있을 지, 다른 부분에 영향을 주는 포인트는 없을 지 고민하는 등의 노력을 시도하다 보면 좋은 결과로 돌아올 거에요.
동료들과 잘 지내자. 좋은 관계는 새로운 기회를 열어준다
이동욱 님의 ‘기억보단 기록을’ 블로그의 ‘인연은 어디서나’ 라는 글의 말미에 다음과 같은 구절이 있습니다.
지금 내가 내린 선택은 수많은 인연들 속에서 발생한 우연들의 결과라는 생각을 많이 한다.
함께 일하는 동료들은 자연스럽게 서로 어떤 사람인지 이해하게 됩니다. 코드 리뷰를 하면서, 평소에 이야기를 나누면서, 업무적으로 회의를 하고 가끔 정신없고 힘든 시간을 공유하며 각자가 어떤 사람인지, 함께 일하고 싶은 사람인지 판단할 수 있는 데이터가 쌓입니다.
동료와 함께 일하는 과정에서 성격 충돌이나 의견 차이 등 문제가 발생할 수 있습니다. 그러나 이럴 때 오히려 프로페셔널함을 유지하며 상황을 해결하는 모습을 보여주면 그것만으로도 크게 인상적일 것입니다. 받은 피드백도 개인적으로 받아 들이기 보다는 업무와 관련된 부분에서 성장하기 위한 자극으로 받아들여야 합니다.
더 나아가 동료와 잘 지내는 것은 단순히 현재 일하는 환경을 좋게 만드는 것 뿐만 아니라 앞으로 커리어에 있어서도 크게 도움이 됩니다. 서로 다른 경로로 나아갔다 해도 그간 쌓아온 인간관계와 네트워크는 여러분에게 새로운 기회를 제공할 수 있습니다. 그것이 새로운 프로젝트일 수도, 좋은 회사의 내부 추천일 수도 있습니다.
외부 네트워킹을 조금씩 도전해보자
모든 개발자 분들이 그러신 건 아니지만, 꽤 많은 개발자 분들이 네트워킹에 대해 두려움을 조금씩 가지고 계십니다. 주니어 개발자 분들의 경우 ‘나 같은 주니어가 갔다가 할 이야기도 없고 이야기 수준 못 따라가는 거 아니야..?’ 라는 걱정이 있다는 이야기를 주변에서 많이 들었던 기억이 납니다.
하지만 실제로 네트워킹 모임에 나가거나 외부 컨퍼런스에서 다른 개발자 분들과 이야기를 나누어 보면 오히려 서로 모르기 때문에 함께 고민을 하며 답을 찾기도 하고, 개발뿐만 아니라 다양한 회사 이야기, 새로운 트렌드 등 정말 다양한 이야기를 나누고 인사이트를 공유하게 됩니다.
개발자로서 개발을 잘 하는 것도 중요하지만 현재 IT 시장의 트렌드를 파악하고 이슈를 파악하는 것도 꾸준히 롱런하기 위해 중요한 요소 중 하나라고 저는 생각합니다. 네트워킹을 통해 최신 정보도 빠르게 습득하고 개발적으로 서로 도움을 주고 받으면서 향후 특정 기업의 공고가 열렸을 때 추천을 받을 수도 있기 때문에 저는 조금씩이라도 네트워킹 모임을 찾아 참석해보거나 링크드인과 같은 커리어 플랫폼을 관리해 보는 것을 추천드립니다.
네트워킹을 하면서 좋은 점은 유명 IT 기업들의 오피스를 둘러 볼 수 있다는 겁니다 (오피스 덕후 행복)
Epilogue
본문에 나와 있듯이, 저는 운이 정말 좋았습니다. 소프트웨어를 전공하고 있었음에도 개발적인 능력이 뛰어나지 않았던 저에게 개발자 커리어를 시작할 수 있게 기회를 주신 팀장님부터 정말 좋은 분들을 많이 만나고 도움을 받을 수 있었어요.
하지만, 어쩌면 이렇게 예고 없이 찾아온 행운을 놓치지 않고 잡아서 저에게 또 다른 기회를 만들어 줄 수 있도록 발전시키는 연습을 꾸준히 하고 있었기 때문에 저만의 개발자 커리어를 쌓아올 수 있었다고 생각이 됩니다.
어떻게 개발자 커리어를 시작하고 어떻게 쌓아가는 게 정답이다 라고 말할 수 없습니다. 최선을 다해 개발자로서 성장하고 본인만의 성과물을 만들어 내고 있다고 느끼고 만족하고 앞으로 더 나아가는 게 중요한 것 같아요. 그리고 성공 여부와 관계 없이 나만의 경험을 다른 개발자들에게 공유하고 개선해 나가다 보면 모두가 정말 훌륭한 시니어 개발자가 되어 있으실 거라 믿습니다.
요즘 같은 채용 시장 한파에 개발자를 꿈꾸는 꿈나무 분들부터 주니어 개발자 분들까지 모두 파이팅하세요! 긴 글 읽어 주셔서 감사합니다.
[김테디의 기술 블로그 – 개발자스럽지 않은 개발자의 커리어 이야기 읽으러 가기] (https://blog.teddy-kim.com/junior-developer-career)
주니어 개발자 분들께 전하는 경험과 조언
저는 처음에 몇 번 좌초 당했습니다. 사수 분들이 친절히 체크 포인트로 환생시켜 주시고 다시 좌초 시키셨습니다.
설레는 마음으로 개발자 커리어를 시작한 저는 첫 번째 회사에서 2년의 재직 기간 중 첫 1년을 거의 의사 선생님들의 인턴 기간처럼 모든 직군을 하나씩 찍먹(?) 해 보는 기간을 가졌습니다. 4년차가 된 지금, 주변 개발자 분들께 이 이야기를 들려 드리면 대다수의 분들이 ‘?????’, 혹은 ‘도대체 어떻게 버티셨어요..?’, ‘나였으면 바로 퇴사했다’ 와 같은 반응들을 보여 주셨어요.
그래서 입사하고 처음 1년 동안 제가 얼마나 다양한 직군을 경험해 봤는지 한 번 정리해 봤습니다.
🤔 QA & Android 개발 3개월 → QA & 웹 퍼블리싱 2개월 → 웹 퍼블리싱 & 백엔드 개발 (Spring Boot & PHP 기반 API 개발 및 유지보수) 5개월 → Front-end 개발 (2개월 + a)
위에 적혀 있는 다양한 직군들을 그냥 ‘체험만’ 해 봤다면 제 첫 1년 동안의 커리어는, 아니 어쩌면 저는 개발에 대한 흥미를 복구조차 안 될 정도로 잃어 버렸을 것 같습니다. 첫 1~2년 때 어떤 환경에서 어떻게 일하고 증명하고 배우는지가 미래에 어떤 개발자로 성장하고 나아갈지 정해지는 데 정말 큰 영향을 끼친다고 믿어요.
하지만 제가 몸담고 있던 개발팀의 리더 분들은 감사하게도(?) 저를 편하게 지내게 하실 마음이 전혀 없었습니다. 모든 직군을 해당 업무 담당자 분께 스파르타 식으로 배우면서 바로 실무에 참여하도록 하셨습니다. 매주 정기 배포가 이루어지는 앱부터 서버, 그리고 QA 과정에서 조금이라도 실수를 했다간 바로 라이브 서비스 장애였고, 프로덕트에 막대한 영향을 주기 때문에 모든 힘과 정신을 끌어모아 집중할 수 밖에 없었습니다.
새로 접한 직군의 업무를 실수 없이 바로 진행하려면 공부를 엄청 해야 할 텐데 공부는 언제 해? 라고 궁금해 하실 수 있는데, 퇴근하자마자 다음 날 출근하기 직전까지 미친듯이 공부하고 아침에 담당 시니어 개발자 분께 확인 받고 토의하는 나날을 반복했습니다. 덕분에 힘들었던 대학교 시절보다도 훨씬 많은 공부량을 이뤄낼 수 있었습니다.. 🥲
1년 간의 지옥 훈련 덕분에 Front-end 개발에 정착한 후 사수 없이 혼자 개발을 하고, 프로젝트에 필요한 Flutter 앱을 함께 개발하는 상황에서도 당황하지 않고 빠르게 학습해서 문제를 해결할 수 있었습니다. 혼자 자바스크립트를 공부하면서 백엔드 개발자 분들과 프로젝트를 진행하다 보니, 지금은 상상할 수 없는 Vanilla JS 와 Kendo UI Framework 만으로 SPA (Single Page Application) 방식의 프로젝트를 모두 구현했습니다.
이 때 Vanilla JS 로 웹 애플리케이션 내부에서 지속적으로 변하는 데이터와 UI를 관리하는 방법에 대해 계속해서 고민하고 다양한 방법을 시도해봤었는데요, 이러한 경험은 Front-end 개발자로 이직을 시도할 때 React, Vue와 같은 모던 웹 프론트엔드 기술 스택을 실무에서 전혀 다뤄본 적이 없음에도 불구하고 대부분 회사의 서류 전형을 통과하고 기술 인터뷰에서도 면접관들의 흥미를 끌어내는 좋은 소재였습니다.
이직에 성공하여 재직 중인 지금 회사에서는 React, Next.js와 TypeScript를 비롯한 다양한 기술을 활용해 Front-end 개발을 하고 있습니다. 메인 업무와 함께 Python을 활용한 PR 리마인더 슬랙 봇, JavaScript, Selenium WebDriver를 활용한 점심 메뉴 크롤링 슬랙 봇 등을 개발하거나 인프콘 2023 기업 부스 기획 및 운영, 사내 프로덕트 세미나 기획, 발표와 같은 DevRel 활동, 개발 커뮤니티에서의 네트워킹을 함께 하며 개발을 다양한 분야로 확장시켜 나가는 “개발자스럽지 않은 개발자”로 열심히 앞으로 한 발자국씩 나아가고 있습니다 ✨
신입 개발자로 개발자 커리어를 시작한 이후 한 치 앞을 예측할 수 없는 주니어 개발자 생활과 이직을 겪으면서 느끼고 배웠던 부분들을 종합하여 지금 무럭무럭 자라나고 계신 주니어 개발자 분들께 몇 가지 조언을 드려 보고자 합니다.
문제 해결에 있어서 코드로 구현하는 건 가장 마지막 단계다
일반적으로 프로덕트를 개발할 때 우리는 새롭게 만들어야 하는 기능에 대해 기능의 필요성, 목적 등에 대해 전달 받고 기획자, 디자이너 분들로부터 화면 설계서, 기능 정의서, Figma 와 같은 문서를 전달 받게 됩니다. 그리고 이러한 문서를 분석해 요구 사항을 정의하고 구조를 설계해 기능을 구현합니다.
이 때, 전달받은 문서 그대로 개발을 진행하는 걸 우리는 Waterfall 방식이라고 부릅니다. 클라이언트(고객이 될 수도 있고 사내의 PM, 디자이너, 기획자가 될 수 있음) 가 원하는 대로 개발로서 구현해 줄 수 있다면 개발자로서의 역할을 다 했다고 볼 수 있습니다.
하지만, 개발자는 단순히 개발을 잘 하는 사람이 아닌 팀에서 기술에 강점을 가지고 있는 “프로덕트 메이커”의 일원입니다. 새롭게 만들어야 하는 기능에 대해 비즈니스 적으로 함께 고민해보고, 전달받은 문서를 보고 디자이너, 기획자와 함께 유저의 입장에서 더 나은 UI / UX 를 제공할 수 없을지 끊임없이 의견을 제시해야 합니다. 개발자의 강점을 살려 의견을 제시하는 과정에서 관련된 데이터(Database에서 추출한 관련 데이터, Clarity 등을 통해 얻은 서비스 내 유저 히트맵 등) 를 공유해 더 나은 의사 결정을 이뤄내는 데 일조할 수도 있겠죠. 이렇게 제품에 대해 끊임없이 학습하고 이해하며 이해 관계자들이 더 나은 프로덕트를 만들기 위해 소통하고 함께 일하는 프로세스를 Agile 방식이라고 부릅니다.
이렇게 의사소통을 하면서 굳이 개발로 풀어내지 않더라도 기획을 변경하거나 디자인, 플로우를 일부 수정하는 식으로 문제를 해결할 수도 있습니다. 정말 개발과 기술로 풀어내야 하는 문제들을 정제해서 가장 마지막 단계에서 코드를 구현하는 것이 좋은 프로덕트를 만들어 내고 개발 리소스를 효율적으로 활용할 수 있는 길이라고 생각합니다.
모든 개념을 일반화(추상화) 해 보자
위에 적혀있듯이, 저는 첫 회사에서 Front-end 개발을 JavaScript ES7, jQuery, Kendo UI Framework 로만 경험했었습니다. React, Vue, TypeScript와 같은 모던 웹 프론트엔드 기술은 개인적으로 조금씩 공부만 해 봤을 뿐, 실무에서는 한 번도 다뤄보지 못했습니다. 하지만 이직을 위해 여러 회사에 지원했을 때 서류 전형은 거의 다 통과했고, 기술 인터뷰에서도 좋은 평가를 받았습니다. 어떻게 가능했던 걸까요?
바로, 특정 기술에 집중하지 않고 기술들이 가지고 있는 근본적인 배경과 원리에 집중했기 때문이라고 저는 생각합니다. React를 비롯해 최근에 모던 웹 프론트엔드 개발에 쓰이고 있는 기술들은 . 하지만 결국 이러한 기술들이 왜 나왔을까 에 초점을 두고 생각을 해 보면 “지속적으로 변화하는 데이터에 따라 미리 만들어 둔 디자인 (컴포넌트)를 보여주는 과정을 편하게 관리하자” 라고 생각합니다.
저는 <script type=”template”> 이라는 태그 안에 정적인 컴포넌트 디자인을 구성하고 내부에 동적으로 표현해야 하는 데이터는 {value} 와 같이 일정한 정규식을 구성했어요. 그리고 동적으로 컴포넌트를 렌더링해야 할 때, template의 내부 코드를 가져와 API 응답값 등을 정규식 코드에 replace 해서 DOM Tree에 Node로 추가했었습니다. 이렇게 하다 보니 자연스럽게 DOM 구조에 영향이 가면서 reflow가 많이 발생했고, 자연스럽게 React의 Virtual DOM이라는 개념이 어떤 배경에서 탄생했을 지 이해하고 공감할 수 있었습니다.
이런 식으로 최근에 정말 많은 언어와 라이브러리, 프레임워크가 시장에서 활용되고 있지만, 결국 왜 이 기술이 탄생하게 됐고 어떤 특징을 가지고 있는지 분석하다 보면 모두 비슷한 고민과 문제를 해결하기 위해 시작되었다고 느낍니다. 따라서, 핵심적인 원리를 이해하고 있으면 이러한 기술은 개념을 확장해 나가는 식으로 빠르게 공부하고 이해할 수 있다고 믿습니다.
(실제로 이직을 진행하던 중 모 대기업의 면접관 분께서 본인도 jQuery에 Redux를 활용해 상태관리를 하면서 Front-end 개발을 하신 경험이 있는데, 결국 다 똑같은 개념이기 때문에 React로 개발하는 건 공부해서 충분히 할 수 있을 것 같다고 하셨습니다. 그리고 최근에 이렇게 개발을 한 사람을 또 볼 줄은 몰랐다고 신기해하셨습니다)
회사는 최고의 샌드박스다
(주의) 자유롭게 사고쳐도 된다는 뜻은 절대 아닙니다.
‘모래 상자’라는 뜻을 가지고 있는 샌드박스는 ‘자유롭게 실험하고 배울 수 있는 공간’을 의미하는 용어입니다.
평소에 책과 다양한 자료를 통해 개발적인 지식을 공부하고 나면 이를 실제로 활용해 보면서 내 것으로 만들 기회가 많지 않습니다. 하지만, 회사 프로젝트를 개발하면서 자신이 공부한 내용을 직접 구현해보고, 그 결과를 유저들이 사용하는 것을 보며 어떤 부분이 잘 작동하고 어떤 부분이 개선되어야 하는지 직접 확인할 수 있습니다. 단, 새로운 시도를 실제 라이브 중인 서비스에 적용할 때에는 항상 장애가 발생할 여지가 없는 지, 함께 개발을 하는 동료, 이해 관계자들과 충분히 이야기 해 보고 진행해야 합니다.
추가로, 간단한 사이드 프로젝트나 토이 프로젝트를 구현해 사내 구성원들에게 배포하는 것도 좋습니다. 저는 업무 시간 외에 개인적으로 회사 생활에 도움이 될 만한 점들을 추려내 슬랙 봇 등을 개발했었는데요. 평소에 해 보고 싶었던 슬랙 봇 개발과 웹 크롤링을 공부해보고 사내 구성원들의 좋은 반응을 보면서 뿌듯함도 느낄 수 있었습니다.
즉, 회사라는 샌드박스에서 자신만의 방식으로 실험하며 성장하되 주변 동료와 협력하여 서비스 안정성 등 필수적인 요소도 항상 유지할 수 있어야 합니다. 이런 경험이 바탕이 되어 앞으로 다양한 문제 상황에서 대처할 수 있는 능력을 키우게 될 것입니다. 이런 식으로 회사라는 샌드박스를 잘 활용해 나와 회사 모두 성장하는 경험을 축적하면, 개발자로서의 역량을 한 단계 더 향상시킬 수 있습니다.
기회는 예고 없이 찾아온다. 왔을 때 잡는 건 실력이다
‘받은 만큼만 일을 하면 된다’ 라는 문장에 저는 개인적으로 동의하지 않는 편입니다. 틀렸다는 건 절대 아니에요. 바라보는 관점에 따라 충분히 일리 있는 이야기입니다.
제가 첫 회사에 입사한 후 팀장님께 들은 이후로 개발자 커리어 내내 좌우명으로 새기고 있는 문장이 있습니다.
💡“돈 받고 일을 하는 순간 우리는 모두 프로다. 1군, 2군과 같이 실력에 따라 레벨이 나누어질 수 있어도 우리는 프로의 자세로 최선을 다 해야 한다”
이러한 좌우명에 따라 항상 제 능력으로 이뤄낼 수 있는 최대한의 결과물을 얻기 위해 노력하고 놓친 부분은 없는 지 끊임없이 의심하고 체크하다 보니 자연스럽게 일을 하는 데 소모되는 에너지도 많아지고 야근도 적게 하는 편은 아닙니다.
누구에게든 예고 없이 생각하지도 못했던 기회들이 찾아 옵니다. 평소에 정말 해 보고 싶었던 프로젝트에 참여할 기회를 제공 받거나, 해 보고 싶었던 업무를 “한 번 해 볼래?” 라는 식으로 말이죠. 이렇게 행운이 찾아왔을 때 본인이 미리 준비가 되어 있고 사전에 충분한 공부가 이루어져 있어야 확실하게 잡아서 내 커리어를 한 단계 발전시킬 수 있다고 생각합니다. 그렇기 때문에, 평소에 본인에게 주어진 업무가 작은 사이즈 이더라도 최선을 다해 완성하고 어떻게 확장시켜 나갈 수 있을 지, 다른 부분에 영향을 주는 포인트는 없을 지 고민하는 등의 노력을 시도하다 보면 좋은 결과로 돌아올 거에요.
동료들과 잘 지내자. 좋은 관계는 새로운 기회를 열어준다
이동욱 님의 ‘기억보단 기록을’ 블로그의 ‘인연은 어디서나’ 라는 글의 말미에 다음과 같은 구절이 있습니다.
지금 내가 내린 선택은 수많은 인연들 속에서 발생한 우연들의 결과라는 생각을 많이 한다.
함께 일하는 동료들은 자연스럽게 서로 어떤 사람인지 이해하게 됩니다. 코드 리뷰를 하면서, 평소에 이야기를 나누면서, 업무적으로 회의를 하고 가끔 정신없고 힘든 시간을 공유하며 각자가 어떤 사람인지, 함께 일하고 싶은 사람인지 판단할 수 있는 데이터가 쌓입니다.
동료와 함께 일하는 과정에서 성격 충돌이나 의견 차이 등 문제가 발생할 수 있습니다. 그러나 이럴 때 오히려 프로페셔널함을 유지하며 상황을 해결하는 모습을 보여주면 그것만으로도 크게 인상적일 것입니다. 받은 피드백도 개인적으로 받아 들이기 보다는 업무와 관련된 부분에서 성장하기 위한 자극으로 받아들여야 합니다.
더 나아가 동료와 잘 지내는 것은 단순히 현재 일하는 환경을 좋게 만드는 것 뿐만 아니라 앞으로 커리어에 있어서도 크게 도움이 됩니다. 서로 다른 경로로 나아갔다 해도 그간 쌓아온 인간관계와 네트워크는 여러분에게 새로운 기회를 제공할 수 있습니다. 그것이 새로운 프로젝트일 수도, 좋은 회사의 내부 추천일 수도 있습니다.
외부 네트워킹을 조금씩 도전해보자
모든 개발자 분들이 그러신 건 아니지만, 꽤 많은 개발자 분들이 네트워킹에 대해 두려움을 조금씩 가지고 계십니다. 주니어 개발자 분들의 경우 ‘나 같은 주니어가 갔다가 할 이야기도 없고 이야기 수준 못 따라가는 거 아니야..?’ 라는 걱정이 있다는 이야기를 주변에서 많이 들었던 기억이 납니다.
하지만 실제로 네트워킹 모임에 나가거나 외부 컨퍼런스에서 다른 개발자 분들과 이야기를 나누어 보면 오히려 서로 모르기 때문에 함께 고민을 하며 답을 찾기도 하고, 개발뿐만 아니라 다양한 회사 이야기, 새로운 트렌드 등 정말 다양한 이야기를 나누고 인사이트를 공유하게 됩니다.
개발자로서 개발을 잘 하는 것도 중요하지만 현재 IT 시장의 트렌드를 파악하고 이슈를 파악하는 것도 꾸준히 롱런하기 위해 중요한 요소 중 하나라고 저는 생각합니다. 네트워킹을 통해 최신 정보도 빠르게 습득하고 개발적으로 서로 도움을 주고 받으면서 향후 특정 기업의 공고가 열렸을 때 추천을 받을 수도 있기 때문에 저는 조금씩이라도 네트워킹 모임을 찾아 참석해보거나 링크드인과 같은 커리어 플랫폼을 관리해 보는 것을 추천드립니다.
네트워킹을 하면서 좋은 점은 유명 IT 기업들의 오피스를 둘러 볼 수 있다는 겁니다 (오피스 덕후 행복)
Epilogue
본문에 나와 있듯이, 저는 운이 정말 좋았습니다. 소프트웨어를 전공하고 있었음에도 개발적인 능력이 뛰어나지 않았던 저에게 개발자 커리어를 시작할 수 있게 기회를 주신 팀장님부터 정말 좋은 분들을 많이 만나고 도움을 받을 수 있었어요.
하지만, 어쩌면 이렇게 예고 없이 찾아온 행운을 놓치지 않고 잡아서 저에게 또 다른 기회를 만들어 줄 수 있도록 발전시키는 연습을 꾸준히 하고 있었기 때문에 저만의 개발자 커리어를 쌓아올 수 있었다고 생각이 됩니다.
어떻게 개발자 커리어를 시작하고 어떻게 쌓아가는 게 정답이다 라고 말할 수 없습니다. 최선을 다해 개발자로서 성장하고 본인만의 성과물을 만들어 내고 있다고 느끼고 만족하고 앞으로 더 나아가는 게 중요한 것 같아요. 그리고 성공 여부와 관계 없이 나만의 경험을 다른 개발자들에게 공유하고 개선해 나가다 보면 모두가 정말 훌륭한 시니어 개발자가 되어 있으실 거라 믿습니다.
요즘 같은 채용 시장 한파에 개발자를 꿈꾸는 꿈나무 분들부터 주니어 개발자 분들까지 모두 파이팅하세요! 긴 글 읽어 주셔서 감사합니다.
[김테디의 기술 블로그 – 개발자스럽지 않은 개발자의 커리어 이야기 읽으러 가기] (https://blog.teddy-kim.com/junior-developer-career)
Related Posts
