(센치한 느낌으로) 주니어 개발자를 벗어나며 내가 배운 것들, 3년 6개월의 회고록

2024년 7월, 1년6개월의 창업과 2년의 회사 생활을 거치며 4년차 프론트엔드 개발자가 되었다. 회사마다 주니어 개발자를 나누는 기준이 조금 모호하지만 4년차부터 미들급으로 분류되는 경우도 있기에 년차로만 따진다면 나는 주니어 개발자의 끝자락 혹은 그 너머에 서있을 것이다. 개발 직군만큼 실력으로 스스로의 가치가 대변되는 직군은 드물다고 생각한다. 스스로 의심하고 노력하며 정진했던 지난 시절이라 자부할 수 있지만 아직 앞으로 나아갈 기간이 더 많이 남아있음을 알고 있다. 지금 이 시점에 스스로에 대한 객관적인 평가를 공고히 하고, 훗날 시니어 개발자가 되었을 때 내 성장 지표로 삼기 위해 이때까지 내가 배웠던 것에 대해 회고해보고자 한다.

“개발”을 잘하는 것만이 “일”을 잘하는 것은 아니다.

나는 첫 번째 회사에 프론트엔드 디벨로퍼로서 합류했다. 그리고 맡은 업무도 새롭게 시작되는 프로젝트의 개발이었고, 운이 좋게도 창업 경험을 제외하고 신입 개발자임에도 불구하고 프로젝트의 전반적인 설계에 직접적으로 관여할 수 있었다. 당시를 회고하자면 정말 열심히 개발했고 더 좋은 구조를 위해 고민했으며 어떠한 기술 스텍을 도입할지 동료 개발자들과 토론을 하며 시간을 보냈었던 것 같다. 그 때 PM분이 나에게 늘 해주셨던 말씀이 있는데 “우리 업무는 개발이지만 우리 일은 개발이 아니다.” 였다.

처음 들었을 땐 이를 이해하지 못했는데 지금은 어렴풋이 그 뜻을 알 수 있을 것 같다. 회사마다 다른 목적이 있겠지만 결국 서비스를 운영한다는 것은 각자의 목표에 걸맞는 성과를 이루기 위함으로 귀결될 것이다. 어떠한 목표를 정할지 고민하고, 그 목표를 이루기 위해 어떠한 것을 도입하면 좋을지 혹은 개선하면 좋을지 기획하고, 그 기획한 바를 이루기 위한 수단으로 나의 업무인 개발이 투입되는 과정으로 회사의 일은 진행된다. 결국 내가 추구해야 하는 것은 “우리의 KPI에 맞는 성과 달성”이고 나는 그 목표에 맞게 개발자로서 개발을 도구로 삼아 기여하는 업무를 담당한 것이다. 여기서 PM분은 나에게 조금 더 넓은 시야를 볼 수 있기를 바랬던 것 같다.

성과 달성의 목표가 새로운 개발로만 이루어지는 것은 아니다. 기획의 방향성이 변경하거나 새로운 정책을 도입하거나, 다른 시각에서 문제를 바라보거나 문제를 새롭게 정리하는 것도 당면에 떨어진 과제를 해결하는 방법 중 하나다. 개발만으로 문제를 해결하고자 하는 것은 비즈니스를 바라보는 나의 시야를 좁게 만들었었다. 개발 업무에 정진하는 것도 당연히 중요하지만 내 일은 “좋은 비즈니스를 만들어 높은 성과를 내는 것”이다. 보다 다른 도메인에 종사하는 다른 코워커들의 이야기를 귀담아 듣고, 그들이 어떤 목적으로 목소리를 내는지, 나에게 정말 바라는 것이 무엇인지 되돌아 보는 법을 배웠다. 그 당시 PM님은 요구사항을 받아들였을 때 코드를 짜지 않고 그 요구사항을 충족할 수 있었다.

나에게 중요한 것이 회사에 중요한 것은 아닐 수 있다.

나는 개인의 성장이 곧 회사의 성장이라 믿는다. 지금도 그 생각은 변치 않지만 생각의 방향성을 조금 달리하는 계기가 있었다. 첫번째 회사에 1년 1개월 정도 시간을 보내고 두번째 회사로 이직한 후 이사님이자 서비스 개발팀의 프로젝트 리딩을 담당하시는 개인적으로 존경해 마지 않는 PM분에게 배운 점이다. 1년 전쯤의 나는 아마 흔히 얘기하는 ‘우매함의 봉우리’를 열심히 등반했을 때라고 생각한다. 그리고 1년 만에 나는 말하는 감자에 가깝단 걸 깨닫는 중이다. 프론트엔드 개발자로서 3년 정도면 주로 사용하는 기술 스텍에도 익숙해졌고 새로운 요구사항이 생겼을 때 적절한 라이브러리 혹은 적절한 해결책을 제시할 수 있으며, 프로젝트 구조를 잡는 경험까지 겪어봤으니 어쩌면 당연하게 자만에 빠질 법도 했다.

그 당시 나는 한창 욕심을 내며 조금 더 좋은 성능, 구체적으로는 조금 더 빠른 렌더링 그리고 더 높은 웹 퍼포먼스를 구축하기 위해 많은 시간을 할당했었다. 그리고 이 블로그의 첫번째 게시물에서도 짧게 언급한 것 처럼 내가 중요하다고 생각한 웹 성능이란 지표가 지금의 우리 회사에선 큰 관심사로 여겨지지 않는단 것을 깨달았다. 첫번째 회사는 B2C였고 두 번째 회사, 지금의 회사는 B2B 비즈니스 모델을 가지고 있다. 그리고 B2B 비즈니스 모델에선 “빠른” 서비스보다 “안전한” 서비스를 더욱 추구했다. 당연히 웹 성능이란 것이 높을 수록 좋은 것은 맞지만 유저가 체감하는 부분은 일정 수준부터는 미미하게 느껴질 수 있다. 내가 구조를 변경하고 리랜더링 최적화를 고려하여 설계를 하여 랜더링 속도를 0.1초 앞당겼다고 가정해보자. 나 스스로는 한 단계 더 성장한 발걸음이지만 회사 입장에서는 크게 체감할 수 없는 변경사항이고 개발 업무를 담당하고 있지 않은 다른 사람들의 시각에선 변경사항이 없었다고 느껴질 수도 있다.

나는 이 글을 통해 프론트엔드에서 퍼포먼스는 일정 수준부터 의미가 없다고 말하고 싶은 것이 아니다. 좋은 퍼포먼스를 낼 수 있도록 프로젝트 구조, 컴포넌트 구조를 설계하는 것은 매우 중요한 일이고 해당 능력이 있다면 실력이 있는 프론트엔드 개발자임은 틀림없다. 다만 현재 우리 회사가 현재 그것이 필요없다고 판단된다면 그 모든 것들은 성과로 인정받기 어려울 것이다. 개인의 성장이 회사의 성장으로 이어질려면 개인은 회사가 부여한 롤에서 회사가 기대하고 있는 업무의 방향성을 지녀야 한다. 나는 이제 업무를 받을 때 그 의도와 배경을 살펴보는 법을 안다.

성장을 체감하긴 어렵다. 하지만 성장하지 않는 것은 아니다.

4년차가 되기 이전에 내가 배운 바를 글로 남겨야겠다고 다짐했을 때부터 어떠한 배움을 얻었나를 스스로에게 물어봤을 때 앞의 두 항목이 제일 먼저 떠올랐다. 그 다음으로 떠오르는 것들은 ‘기술 스텍에 대한 이해를 공고히 했다’, ‘새로운 기술을 익혔다’, ‘새로운 환경에서 개발 환경을 구축하는 법을 배웠다’등이 꼬리를 물었다. 그리고 단순히 기술의 숙련도가 올랐다는 것을 글로 남길 필요성을 느끼지 못했다.

확실히 친구들과 우당탕탕 창업을 시작했을 때 나의 코드를 들여다보면 만족스러운 구석을 찾아보기 어렵다. 굳이 그런 먼 과거까지 가지 않아도 한 달 전의 나의 코드를 봐도 좋은 평가는 내릴 수 없다. 나는 코드를 구축하는 측면에서 많은 성장을 이뤘다. 단순히 프론트엔드 코드만 짜는 것이 아니라 배포 환경을 구성하고, DNS를 설정하여 도메인을 연결하고, 새로운 라이브러리가 기존의 환경에서 충돌이 발생했을 때 이를 극복해나갈 수 있다. 또, 스스로 문제를 찾아보고 그 문제를 해결하기 위해 고민하며 주위 동료를 설득할 수 있도록 문서를 작성하는 법을 배우는 중이다. 다만 이러한 모든 것들을 이 글을 통해 정리하고 작성하기 전까지 스스로 자각하지 못하고 있었다. 물론 아직 배운 점보다 배워야 할 점이 더 많은 것도 안다.

언젠가 프론트엔드 개발자들이 직장을 선택할 때 가장 중요하게 여기는 것이 무엇인지를 묻는 설문조사 결과를 본 적이 있다. 20대 개발자들을 대상으로 진행했던 설문으로 기억하는 데 놀랍게도 연봉과 워라벨을 제치고 “개인이 성장할 수 있는 회사”가 1등으로 선정되어 기억 한 켠에 남아있다. 나 역시 이와 대동소이한 생각이며 나와 비슷한 대부분의 개발자들도 위 결과에 공감할 것이다. 내가 평생의 업으로 결정한 직업인만큼 스스로의 전문성을 언제나 보다 공고히 다질 수 있길 바란다. 이런 마음 때문에 조급해지기 쉽다. 하지만 내가 노력한다면 알게 모르게 나는 착실히 나아가고 있다. 보다 스스로를 믿으며 정진해야 할 시기이다.

결론

좋은 프론트엔드 개발자란 무엇일까? 나아가서 좋은 개발자란 무엇일까? 혹은 실력있는 개발자란 무엇일까? 개발자의 역량을 평가한다면 그 기준과 잣대는 무궁무진할 것이며 그 중 어느것에 중점을 두냐에 따라 사람에 대한 평가가 달라질 수 있다. 나를 모든 사람이 좋아해줄 수 없듯이 모두가 나를 보고 좋은 개발자라 말할 수 없음을 안다. 예전에 개발에 입문하면서 한국에서 제일가는 프론트엔드 개발자가 되는 것을 꿈으로 삼았었는데, 아직은 그 꿈이 오글거리게 느껴지지 않는 것을 보면 스스로 썩 잘해왔다고 평가해도 될 것 같다. 그럼에도 자만하지 말고 꾸준히 정진하는 개발자가 되길 소원한다. 1년 뒤에 이 글을 스스로 돌아봤을 때 한 단락을 더 추가할 수 있도록.