글을 시작하며

한 해를 마무리하는 회고록으로 각종 커뮤니티가 붐비는 계절이 다가왔습니다. 저도 2023년에는 참 많은일이 있어서 기록으로 남겨둘까 라는 생각을 했는데요. 아무래도 사적인 감상과 감정이 많이 들어가는 글이다보니 올해의 소감은 작게 사내에서 나누는 시간을 가지고 2023년, 나를 성장시킨글들을 되돌아보며 한번 더 동기부여를 하고자 합니다. 🔥

그리고 이 블로그를 읽는분들이 아직 접해보지 못한 글이 소개된다면 개발 분야에 상관없이 꼭 한번 읽어보셨으면 합니다. 어쩌면 그 글이 여러분의 개발 커리어를 바꿀정도의 깨달음을 줄 수 있을것이라는 생각도 들어요. 🫢

그럼 지금부터 개발자인 저에게 큰 영향을 준 글들을 소개해드리겠습니다.

1. 프론트엔드 엔지니어 커리어 로드맵: 주니어를 위한 3가지 전문성 트랙

구독 중인 뉴스레터에서 소개되어 처음 읽게 되었습니다. 이후 2023년 인프콘에서도 해당 주제로 발표를 진행해주셔서 많은 분들이 접해보셨을거에요.

소개

3년차 프론트엔드 엔지니어입니다. 이제 뭘 더 공부해야 할까요?

위와 같은 고민을 하는 프론트엔드 엔지니어들, 그리고 이들을 어떻게 고민하는 리드 혹은 CTO를 생각하며 글을 작성하셨다고 합니다. 저도 마침 3년 차에 접어든 개발자라서 더 와닿는 부분이 많았던 글이었습니다. 글에서는 '탁월한 시니어 프론트 엔지니어 되기의 과정'을 다음과 같이 크게 3가지 주제로 나누어 다루고 있습니다.

1) 탁월한 엔지니어 되기
탁월한 엔지니어가 되기 위해 필요한 기본적인 역량을 강조합니다. 해당 파트에서는 탁월한 엔지니어의 5가지 주요 역량에 대하여 소개하며 덧붙여 Prompt Engineering에 대한 중요성도 함께 강조합니다.

2) 탁월한 프론트엔드 엔지니어 되기
프론트엔드 엔지니어로서의 전문성을 쌓기 위한 구체적인 방향을 제시합니다. 크게 웹 특화, 제품 특화, 운영 특화 등 세 가지 트랙으로 나뉘며, 각각의 트랙에 대한 자세한 설명과 이를 통해 달성할 수 있는 커리어 목표가 제시됩니다.

3) 탁월한 시니어 엔지니어 되기
시니어 엔지니어로서 필요한 역량과 태도에 대해 설명합니다. 이는 기본에 충실함, 리더십 발휘, 그리고 상황에 따른 큰 임팩트 창출을 포함합니다.

이 글을 통해 저와 같은 프론트엔드 개발자들이 자신의 커리어 방향을 명확히 하는 데 도움이 되기를 바랍니다.

나에게 와닿았던 내용

2) 탁월한 프론트엔드 엔지니어 되기

"탁월한 프론트엔지니어가 되기 위해서는 어떤 기술을 배워야 할까?"라는 생각에 사로잡혀있던 제 자신에게 큰 깨달음을 주었던 부분이었습니다. 소프트웨어 엔지니어도 어느 분야에 특화되었는지에 따라 프론트엔드 엔지니어, 백엔드 엔지니어로 나뉘는데 그 안에서 더 나뉠 수 있을것이라는 생각을 이전에는 왜 하지 못했을까요? 이러한 트랙들을 이해하고 나니, 나의 현재 위치와 앞으로 나아가야 할 방향이 명확해졌습니다.

제품 전문가는 아직 시장으로부터 충분한 반응을 얻지 못한 초기 스타트업에서 가장 환영받는 유형의 엔지니어다. 적절한 가설을 설정하고 빈번하게 실험하면서 초기 제품에 유의미한 변화를 만들어내려면 높은 수준의 기술보다는 고객/시장에 대한 이해와 프로덕 센스가 더 중요한데, 제품 특화 프론트엔드 엔지니어가 바로 그런 센스를 갖춘 사람들이기 때문이다.

처음 글을 읽고나서는 커리어에 대한 고민을 많이하며 위의 인용에서 소개하는 것처럼 제품 특화가 된 Product Engineer에 가장 가깝다는 생각을 했어요. 더불어 이 특화가 시장에서 가장 수요가 많고 가치있는 길이라고 생각하기도 했죠. 그래서 탁월한 Product Enginner가 될 수 있는 스킬들을 연마하며 커리어를 꾸려나가는 기간을 거치고 있었는데요. 그 와중에 바로 다음 소개해드릴 글을 읽게되며 생각이 바뀌어 한 단계 더 발전해 "환경에 적합한 탁월한 프론트엔드 엔지니어"가 되도록 노력하는 중 입니다.

Action Item

웹 특화, 제품 특화, 운영 특화 중 어느 쪽에 가장 가까운 개발자인지 고민해본 경험이 없다면 깊게 생각해보고 나의 커리어를 구체화해나가자!

2. 미국가서 중국어 공부하지 않기

회사에서 개발문화의 개선이나 기술부채를 해결하기 위해 고민이 많았던 시기에 동료 서버개발자로 부터 추천받아 읽게 되었어요.

소개

빅테크 회사분들의 시니어분들과 사석에서 만날때와 스타트업으로 이직하신 시니어분들을 만날때 서로 대화의 주제가 다름을 체감한다.
예를 들면, 우리팀의 주니어가 평균 레이턴시 1초인 API를 0.1초로 개선했다 를 이야기한다고 하면
여전히 빅테크에 계신 분들은 그 주니어가 기술적으로 뛰어난 사람임을 이야기하고, 어떻게 개선했는지가 주력이라고 한다면,
스타트업으로 이직하신 시니어분들은 "1초인데 왜 개선하지…?" 라는 이야기를 한다는 것이다.
두 그룹의 시니어분들 다 몇년 전까지는 비슷한 규모의 회사를 다녔음에도 말이다.

빅테크와 스타트업 사이에는 자원적 차이에서 비롯된 의사결정의 차이가 있고, 이런 의사결정이 어떻게 진행되는지에 따라 엔지니어의 역할이 달라지게 된다고 합니다. 그리고 그 역할에서 얻어 가야 할 경험은 분명 차이가 있다는 내용을 다루고 있습니다.

미국 유학가서 중국어 공부하고 있다면 얼마나 이상한가.

단 한 문장으로도 글에서 전달하고 싶은 바를 알 수 있는 이 글은 개발자들에게 많은 존경을 받고 있는 향로님의 글입니다. 많은 분들이 알고 계시듯 스타트업부터 빅테크까지 모든 환경에서 다양한 역할을 수행하신 분이 쓰신 글이기에 더욱 설득력 있게 다가오는 글 입니다.

대부분의 빅테크 기업에서 일하지 않는 개발자분들이 빅테크 기업의 흉내를 내려하지 않고 한정된 자원에서만 얻을 수 있는 최고의 경험을 얻는데 집중하는데 이 글이 도움이 되기를 바랍니다.

나에게 와닿았던 내용

돌이켜보면, 빠른 주기로 MVP를 출시하고 시장의 반응에 따라 제품을 조정하는 과정은 이 단계에서만 경험할 수 있는 귀중한 것이었습니다. 이 과정을 통해 제품의 안정화와 성장을 위한 중요한 교훈을 얻었죠. 이러한 경험 중에, 회사와 관련 없는 기술이나 최신 기술에 맹목적으로 집착하는 것이, 현재 단계에서 얻을 수 있는 소중한 교훈을 놓칠 수 있다는 사실을 깨달았습니다.

실제로, 한 동료는 개인적으로 새로운 프레임워크를 배우는 데 많은 시간을 투자했는데, 이 프레임워크는 빅테크에서 사용하지만 당장 우리 프로젝트에는 적절치 못한 기술이었습니다. 결국, 이러한 학습은 제품의 성장이나 본인의 개발에 크게 기여하지 못했습니다.

이 상황에서, 저는 그 동료에게 '현재의 프로젝트와 환경에서 얻을 수 있는 깊은 이해와 경험에 집중하는 것의 중요성'에 대해 이야기하고 싶었습니다. 향후 이직을 고려한다 해도, 현재의 경험을 충실히 쌓는 것이 더 가치 있고 인정받는 경력으로 이어질 것임을 강조하고 싶었죠. 이는 마치 미국에서 중국어를 배우는 것보다 영어를 배우는 것이 당연하게도 더 좋은 경험이 될 것이라는 것을 말이죠.

Action Item

마찬가지로 내가 속한 회사가 어느 단계에 있는지를 보고, 그 단계에 맞는 경험에 집중하는 것이 좋다.
소규모 스타트업에 있으면서 빅테크에서의 경험을 시도하려고 하거나 빅테크에 있으면서 소규모 스타트업에서의 경험을 시도하려고 한다면 경험치 효율이 좋지 못할 것이다.

나의 환경에 가장 적절한 경험치 효율이 좋은 그런 경험을 하자. 그리고 주변의 동료들도 헤메이지 않도록 마일스톤을 깔아주자.

3. 협업을 잘하는 개발자가 되어보자 - 프로그래머가 아니라 문제 해결사가 되자!

소개

이 글에서는 1) 왜 협업을 잘 해야 하는지, 2) 그래서 어떠한 태도와 관점을 가져야 하는지, 4) 그리고 어떻게 하면 협업을 더 잘 할 수 있는지에 대해서 개인적인 생각을 이야기 드리려고 합니다.

개발자로서 떼어낼 수 없는 협업을 잘하는 방법을 구체적인 경험과 이해하기 쉬운 예시, 그리고 가이드라인을 소개하며 친절히 알려주는 글입니다.
소개 드렸던 글 중에 가장 길어서 간추린 소개보다는 직접 읽어보시는 것을 추천드립니다. 프론트엔드 개발자라면 모두 알고 있을만한 테오님의 글입니다.

나에게 와닿았던 내용

앞에서 소개한 게시글을 통해서 제가 어떤 태도와 마음가짐으로 일하고 있는지에 대해서 정리해 본다면 다음과 같을 것 같아요.

• 제품의 성공에 초점을 두는 Product Developer로서 고객과 시장을 이해하는 Product Sence를 가지는 개발자가 되자.
• 한정된 자원에 가장 적합한 의사결정을 내리고 이 단계에서만 할 수 있는 경험을 좇는 개발자가 되자.

그리고 이 글을 읽으며 한 가지가 추가되었어요.

• 협업을 잘하는 개발자가 되자. 가치에 대한 생각을 바꾸는 것으로 시작해서 주위의 행동을 바꾸는 개발자가 되자.

글을 읽기 전까지는 코드의 품질과 제품의 성공이나 일정에 관련해서는 고민이 참 많았었는데 글을 읽고 나니 그 사이에서 빈번하게 벌어지는 협업의 과정에서도 많은 것을 고치고 개선해 나가야겠다는 생각을 들게 해준 글이었어요. 다행히도 글에서 제시하는 가이드라인 중 잘 지키고 있는 것도 있었지만

'심리적 안전감' 만들어주기 - 마음의 치안

라는 단락에서는 심장이 철렁할 정도로 반성을 하게 되었어요. 코드의 품질을 지켜나가면서 제품을 성공적으로 만들어나가는 협업의 과정에 나는 얼마나 많은 심리적 안전감을 모든 이들에게 주었을까? 하면서 말이죠. 그래서 이 글을 읽은 후로는 '심리적 안전감'을 주기 위해서 가장 가까운 동료들부터 시작해 천천히 유대관계를 만들어나가는 일을 해오고 있어요. 저는 이런 사례를 포함하여 지금은 글에서 알려주는 다양한 가이드라인을 토대로 개발자를 넘어 문제 해결사가 되기 위해 노력하고 있습니다.

Action Item

내 가치를 높이는 과정이 코드 밖에도 있다는 것을 알게되면 훨씬 더 일을 하는 과정에서 주체적으로 일을 할 수 있게 됩니다. 일정의 마감을 지켜줘야 하고 구현을 해줘야 하는 것이 아니라 우리의 문제를 함께 논의하며 풀어나가는 것입니다. 이러한 마인드는 일 자체와 모든 과정을 다 즐겁게 할 수 있게 만들어 줄 것입니다.

당장의 현실은 그렇지 않게 느껴지더라도 생각이 바뀌면 관점이 바뀌고 관점은 태도를 바꿀 수 있습니다. 내 태도는 주위에 반드시 영향을 주게 됩니다.

협업을 잘하는 개발자가 되어보자! 그러기 위해 생각을 바꾸고 관점을 바꾸고 태도를 바꿔나가자.