2년 차 프론트엔드 개발자 상반기 회고

Photo by neom - https://unsplash.com/ko/@neom

요즘 일이 많아져서 정말 바쁘다. 개발팀 내 부장님, 대리님과 소통하는 것은 물론, 디자인팀과 기획팀과도 더 자주 소통하며 바쁘게 다니고 있다. 개발자로 취업하기 전에 들었던 얘기 중에 프론트엔드 개발자는 '중간 다리' 역할을 잘 해야 한다는, 즉 양쪽 모두와 원활하게 소통해야 한다는 것이 생각난다.

업무에 대한 압박감

의사소통엔 큰 어려움을 느끼지 않았다. 그런데 문제는 서비스 출시 마감일이 너무 빨라서 어려움을 겪고 있다. 이렇게 큰 프로젝트를 처음부터 만드는 일이, 특히 2년 미만의 경력으로 프론트엔드 개발을 모두 소화하기엔 너무 벅찬 일정인 것 같다. 얼마나 압박감이 심했냐하면, 프로젝트 생각만해도 식은땀이 나고 괜히 몸에 열이 올라왔다. 머리까지 아파와서 같이 식사하는 동료들에게 이야기해보니, '직장인 화병'이라고 하더라.

이직과 성장에 대한 고민

지금 하고 있는 프로젝트와는 별개로, 이직 생각이 자주 들었다. 나는 아직도 개발자로서 성장에 대한 욕구가 크다. 하지만 여기서는 개발만 할 수는 없었다. 다른 업무들도 포함되어 '반쪽짜리 개발'을 하는 느낌이었다. 그 기간에 내가 생각한 것과 잘 맞는 도메인의 스타트업, 어느 교육 플랫폼의 멘토 제안이 오기도 했었다. 하지만 회사에서 나를 챙겨주는 동료들이 있었고, 좋은 사람들이 있었기 때문에 나름 회사에서 성장할 수 있는 방법들을 찾으려고 노력했다.

 

가장 간단한 방법은 개발 시간을 최대한 확보하는 것이었다. 불규칙한 업무들을 오전, 오후로 나눠 정해진 시간에 같이 처리하자고 제안하였고, 타부서와 불필요한 의사소통 비용을 줄이기 위해 회사 업무앱에 자주묻는 질문(FAQ) 게시글을 만들었다. 또한 고객사와의 의사소통도 가끔 있었기 때문에, 새로운 가이드 문서를 정성껏 만들었다. 단축키를 외우고, 레이캐스트와 같은 도구를 활용하기도 했다. 이렇게 확보한 시간들은 개발에 투자했다.

 

나는 "물 흐르듯이 일이 되게하고, 그레이 영역을 채워주는 사람"이 되고 싶었다. 그래서 회사를 다니는 동안 그레이 영역을 채워주기 위해 노력했고, 스스로 성장하기 위해 일의 난도를 높여 일했다. 위에서 얘기한 행동들의 결과로 나는 나름 인정을 받고, 연봉도 크게 올랐으며, 에이스란 소리를 듣기도 했다.

개발자의 역량

Photo by neom - https://unsplash.com/ko/@neom

회사일에 익숙해지고 전문성이 생겨, 이런 일들은 잘 처리하고 있다고 생각한다. 하지만 개발자로서 내 역량이 어떤지에 대해서는 계속해서 의구심이 들었다. 하조은님의 개발자의 역량 글을 보면서 많은 생각이 들었다.

개발자에게 있어 역량이란 '요구 사항을 안정성과 확장성의 균형을 맞춰 제시간에 개발하는 능력'이다. 요구 사항을 받아 든 순간부터 역량이 드러난다. 기획자, 디자이너와 요구 사항에 대해 함께 논의하고 구체적인 사항을 정리한다. 때론 제시간에 개발하기 위해 요구 사항을 줄이는 제안을 하기도 한다. 코드를 작성하는 순간에는 안정성과 확장성 사이에서 균형을 맞춘다. 상상하고 싶지 않은 에러 상황들을 하나씩 상상해 가며 세심하게 코드를 써 내려간다. 변수명 하나에도 분명한 이름을 붙여 동료와 미래의 내가 이해할 수 있는 환경을 갖추기 위해 노력한다. 약속한 시각을 지켰다면 제품을 내보낸다. 만약 시간을 맞추기 어렵다면 미리 상황을 공유하고 시간을 다시 정한다. 일이 마무리된 이후에는 시간을 맞추지 못한 이유에 대해 회고한다. 다시 요구 사항을 받아 드는 순간에 어떤 부분을 다르게 행동할지 정리해 둔다.

해당 글에 따르면, 역량이 뛰어난 개발자는 요구 사항을 분명히 정리하는 것으로 일을 시작하고, 안정성과 확장성의 균형을 맞추며, 제시간에 개발하는 것이다. 나는 이번 프로젝트가 나의 첫 프로젝트는 아니지만, 처음으로 기획, 디자인, 개발 팀이 모두 참여하는 제품 개발의 전체 사이클을 경험하고 있다. 게다가 부장님의 배려 덕분에 지금은 내가 가장 원하던 순수 개발 작업에만 몰두하고 있다.

 

나는 요구 사항에 대해 정확한 이해를 하지 못했던 것 같다. 부족한 이해를 기반으로 논의를 하였고, 처음으로 프론트 개발 일정에 대해 얘기가 나왔을 때는 충분히 할 수 있다고 생각했다. 피그마에 올라온 디자인을 보고선, UI에 필요한 라이브러리를 찾아보고 나머지는 직접 구현하는 정도까지만 생각했던 것 같다.

 

이러한 이해를 바탕으로 하다 보니, 첫 단추부터 잘못 낀 느낌이 들었다. 시행착오를 정말 많이 겪었고, 어드민 앱을 새로 만드는 만큼 작업할 페이지가 정말 많았기 때문에, 일정에 대한 논의를 많이 했어야 했다. 여기서 나는 요구 사항부터 구체적이고 자세하게 정리하여, 내가 필요한 부분을 적극적으로 어필하고 말해야 한다는 것을 배웠다.

 

뒤늦게라도 기획이나 디자인 부분에서 줄일 수 있는 부분은 최대한 줄이려고 노력했다. 생소한 UI는 관련 레퍼런스를 요청했고, 구현이 어려운 부분은 상황을 최대한 구체적으로 설명해서 이해시키려 노력했다. 그럼에도 불구하고 나는 일정에 쫓겨 개발에 대한 재미를 느낄 틈이 없었다. 문제 해결을 했다는 것에 대한 뿌듯함, 재미를 느끼고 더 깊게 파볼 겨를 없이 일단 '구현'했다는 것에 중심을 두고, 바로 다음 작업을 이어가야 했다. 맛있는 음식을 먹지만, 맛을 느낄 틈도 없이 바로 다른 음식을 욱여넣는 것 같았다. 기계처럼 결과물을 만들어 흥미는 떨어지고, 코드의 안정성과 확장성의 적절한 균형 또한 맞추지 못했다.

 

게다가, 리액트로 개발을 하던 작업을 제이쿼리가 함께 하게 되면서 더욱 혼란스러웠다. 같은 기술 스택이 아니다 보니 나는 나대로 개발하고, 프론트 개발을 도와주시는 부장님은 부장님대로 개발을 하셔서, 더 힘들었던 것 같다.

 

물론, 이러한 상황이 이해되지 않는 것은 아니었다. 회사에서는 가치 창출 즉, 서비스 출시가 최우선 과제일 것이다. 그러나 이것이 내 개인적인 희망과는 다르게 느껴졌고, 이로 인해 더 많은 스트레스를 받았다. 서비스가 출시된 후에는 결국 내가 기존에 있던 제이쿼리 코드를 리액트 코드로 점진적으로 바꿔야 했는데, 며칠 후에 생긴 하나의 파일에, 1만 8천 줄의 코드가 있는 걸 보고 앞길이 막막하기도 했다.

어떻게 해결할 수 있을까?

Photo by neom - https://unsplash.com/ko/@neom

첫 번째 방법은 이 상황을 받아들이는 것이다. 어쨌든 이 힘든 시기를 버티고 나면 성장을 할 것이다. 내 경력이 짧은 만큼, 각종 업무와 프로젝트에서 얻을 수 있는 모든 경험은 소중하다. 실제로 도움이 되는 부분도 많다. 부정적인 생각은 접어두고, 이 상황을 해결할 방법에 몰두한다. 집이건 회사건 밤낮으로 일하면 일정을 맞출 수 있을 것 같다.

 

두 번째 방법은 이직이겠다. 내게 더 맞는 회사를 찾아 떠나는 것이다. 이 방법은 내가 정말로 확신이 들 때 해보는 것이 나을 것 같다. 생각은 해볼 수 있지만 아직 확신이 드는지는 모르겠다. 아마 더는 개발자로서 회사에 많은 영향력을 끼칠 수 없다고 느낄 때가 이직을 결심하는 시기가 아닐까 싶다.

 

결국 내 역량을 키우는 것에 집중하기로 결론이 난 것 같다. 이제는 개발자 역량을 높이는 것에 더 집중하는 시기가 되지 않을까. 기술적인 도전을 많이 해보고, 부족한 부분들을 채우다 보면, 길이 더 명확해지겠지.