프론트엔드 3년차, 2022년 회고

중간점검

2019년 12월 23일, 노리코리아에 입사하고 나서 web dev를 진행하고, 웹 개발이 아닌 프론트엔드 개발 언저리에서 커리어의 한계를 느꼈다.

그래서 나는 2021년 10월 8일, 노리를 퇴사하고 10월 25일에 테크타카에 입사하게 되었다.

이제 어디가서는 쌩 신입도 아니고, 혹자들은 말하는 가장 잘 팔리는 시기 중 하나인 3년차, 그 기간에서 내가 느끼고 계속 고민해오던 것들을 정리하려고 글을 쓴다.

2022년 나의 개발자의 삶

1. 프론트엔드 개발자로 얼마나 알아야 하며, 공부해야 할까?

처음 노리에 입사했을 때, 시간만 주어진다면 너무 어렵지 않은 선에서 무엇이든 다 개발 할 수 있을 것이라 생각했다(코드 퀄리티는 장담할 수 없지만).

지금도 그런 생각은 든다. 다만, 처음 입사 당시에 실력으로 해결할 수 있었던 문제보다 더 깊게, 더 어려운 문제를 해결 할 수 있고, 다양한 문제들을 고려하며 해결 할 수 있을 것 같다(코드 퀄리티는 장담할 수 없지만).

그렇다면 여기서,

나는 무엇을 개발 할 수 있으며 어디 까지 담당할 수 있을까?

프론트엔드 개발 직군으로 커리어를 쌓고 있는 지금, 확실히 말 할 수 있는건, 지금 기준으로 HTML, CSS, JS 와 이를 활용한 기술, 그리고 간단한 호스팅 정도는 할 수 있을 것 같다.

그러나, 향후 커리어를 위해서, 프론트엔드 개발자로써 어떤 것들을 쌓아 올려야 할까에 대한 고민이 들 때가 종종 있었다.

이 고민이 들 때 마다 내가 고려하는 것은 2가지 이다. 프론트엔드 와 개발자, 조금 멋내기 식으로 이야기 해 보자면, Front-end 와 Software Engineer 라고 생각한다.

Front end로써 나는 화면에 나타나는 모든 것들을 담당해야 한다고 생각한다. HTML, CSS, JS 그리고 정적 호스팅과 프론트쪽 자원(이미지, 폰트), 웹 접근성, page metadata 그리고 프론트엔드 개발 환경 구성 및 CI / CD 구축 등 화면 앞단을 위해 필요한 모든 것들. 특히 시니어 개발자가 되기 위해서는 정말 제로 베이스에서 무언가를 쌓아 올리는 경험이 한번쯤은 필요하다고 생각한다.

시니어가 되어 가는 과정에서 나는 얼마나 많은 것들을 쌓아 올려 왔을까? 개인적으로 CI / CD 구축 및 테스트 자동화 까지는 직접 구현을 안해봤기 때문에 미지의 영역이긴 하다. 하지만 이 부분의 경우 향후 스스로 구현을 해봐야지

Software Engineer로 봤을 때 나는 어떨까? 내가 생각하는 소프트웨어 엔지니어는 소프트웨어를 만드는 엔지니어다. 소프트웨어는 하드웨어에 비해 소프트 하다. 변경에 용이하며 끊임없이 변화하는 비즈니스 환경속에서 이에 대한 대응을 할 수 있어야 한다. 변화하는 비즈니스에 유연하게 잘 대응하기 위해, 유지보수하기 쉬워야 한다.

이를 위해 생겨난 많은 개념들과 철학, 프로그래밍 패러다임이 존재한다. 그리고 소프트웨어를 만들기 위해 필요한 또 다른 개념들, 네트워크 데이터베이스, 소프트웨어 공학, 운영체제 등등 정말 다양한 것들이 존재하며 워낙 방대하다 보니 가끔 좌절하게 만들기도 한다.

전에는 내가 모든 것을 다 할줄 알아야 하는 개발자가 되어야 한다고 생각했다. 모든 것을 다 할 줄 알고, 다 알아야 하는 개발자가 되어야 하는건 꽤 도전적인 과제이기도 하지만, 꽤 답답한 과제이기도 했다. 정말 나는 그 모든 것을 다 알아야 할까?

이전에는 잘 몰랐지만, 이제는 여기에 대한 나만의 답변이 준비 되었다. 그건 하고 싶은대로 하면 된다. 였다.

개발은 혼자 하는 것이 아니고, 개발자가 슈퍼 개발자, 원맨쇼를 하고 싶은개발자가 아니라면 굳이 모든 것을 다 알필요는 없다. 알아두면 좋지만, 나만의 강점 하나 둘을 가지고 있는 것 또한 충분히 좋은 길이라 생각하기 때문이다. 그리고 현재 어떤 것을 한다고 해서 향후 그것이 계속 쓰이리란 보장도 없기 때문에, 하고 싶은 공부, 만들고 싶은 소프트웨어를 만드는게 가장 중요한 것 같다는 생각이 들었다.

2. 팀 소속 프론트엔드 개발자의 삶

이 부분은 확실히 개발자가 되기전에는 전혀 알지 못했던 점이다. 그냥 조금만 뭐를 변경하면 화면이 딱딱 바뀌고, 접근성이 좋으며 재미있는 개발을 하기 위해 프론트엔드 개발을 선택했다면, 실제 현업에서는 조금 다를 수 있다.

프론트엔드 개발자로 다른 직군들과 협업을 하게 된다면 알겠지만, 결국 End이다. 화면단의 마지막을 마무리하는 직군이다 보니 가장 마지막에 완료가 되는 직군이며 그만큼 다양한 직군과 소통을 해야 한다. 기획, 디자이너, 백엔드 모두 소통을 해야하며 이 안에서 커뮤니케이션을 이끌어내야 하는 경우가 많다.

프론트엔드 개발자가 프로젝트 내에서 무엇을 결정한다고 말을 하는게 아니다. 다만 기획 또는 백엔드, 디자인 모두 완료가 되어야만 프론트엔드 개발을 마무리 할 수 있는 충분 조건이 이루어졌다고 볼 수 있다. 디자인 없이 간단하게 UI를 구현할 수도 있고, 백엔드 API없이 일단 정해진 스펙을 가지고 Mock API를 구성하여 작업을 한다고 하지만 결국에는 프론트엔드 단에서 마무리가 되어야 무언가를 완료했다고 이야기 할 수 있다.

이렇게 보면 프론트엔드 개발자가 뭐 다하고 가장 중요한거 아니냐? 라는 생각이 들 수도 있으나, 그것을 이야기 하는것은 아니다. 단지 그 모든 것을 아우르기 위한 커뮤니케이션과, 앞에서 딜레이되거나 변경사항이 생겼을 때, 필연적으로 프론트엔드 개발에서는 그 이상의 추가적인 시간이 소모가 되면서, 프로젝트 일정상 프론트엔드가 일정적으로 많은 압박감을 받게 되는 경우도 있다.

그렇기에 개발자로써, 프론트엔드 개발자가 당연히 코드도 잘짜고 프론트엔드 개발에 대한 이해도 중요하지만 그 이상으로 협업 및 일정관리, 회의 및 스펙협의에 대한 문서 기록과 커뮤니케이션을 원활하게 하는 방법도 배워야 한다고 생각한다.

3. 도메인에 대하여

내가 일하는 곳, 일하게 될 곳에 대한 도메인 지식 또한 개발 지식만큼이나 중요하다. 커머스 플랫폼에서 일하는 개발자가 주문 관리 화면을 담당한다고 했을 때, 주문에 대한 이해가 없이 과연 주문 이라는 거대한 비즈니스를 충분히 그려낼 수 있을까? 나는 그렇지 않다고 본다.

우리가 무엇을 만들 것 이라고 기획자가 기획을 한다. 그리고 디자이너는 기획자가 작성한 기획서를 가지고 디자인을 한다. 그러면 프론트엔드 개발자와 백엔드 개발자가 뚝딱뚝딱 무엇인가를 만들어 낸다.

여기서, 우리는 기획 및 디자인 싱크업에 들어가게 된다. 무엇을 기획해서 만드는지 우리는 알아야 한다. 그리고 이것을 기반으로 디자인이 만들어 질 때, 우리에게 주어진 리소스 안에서 개발할 수 있는 녀석인지 아닌지를 판단해야 하며, 우리가 개발할 때 어떤 것들을 고려할지 고민하고, 소통을 하게 된다.

우리는 때로 우리가 개발해야 하는 것들에서 몇몇 부분들을 놓치고 있어서, 우리가 잘 모르고 있어서 수정을 해야 하는 경우가 많다. 특히 개발자는 비즈니스를 코드로 작성하는 직업이기 때문에 그 비즈니스 도메인에 대한 이해가 반드시 필요하다. 특정 비즈니스의 플로우에 대한 이해가 없다면 우리는 비즈니스를 제대로 구현하지 못하게 될 가능성이 있으며 이는 필연코 코드의 수정 및 변동을 야기시키며 때로는 비즈니스에 손실을 야기시킬 수 있다.

그렇기에 담당하게 될 도메인에 대한 이해와 지식이 반드시 있어야 하며, 가장 앞선 것은 도메인에 대한 관심이 될 것이다. 막상 회사를 다니다보면 전혀 관심없던 도메인이 재밌어지기도 하고, 관심없던 도메인이 정말 여전히 노잼일 수 있다. 그렇기에 그 안에서 자신만의 해결 방법을 찾아갈 수 있어야 한다.

4. 일하는 방식에 대하여

일은 하면 된다. 코드는 짜면 된다. 까라고 하면 까면 된다. 그러나 우리는 협업을 하게 된다. 한 팀으로 움직이며 동일한 목표를 향해 나아가야 한다. IT 업계에서, 특히 소프트웨어를 메인으로 하는 회사의 경우 소프트웨어 개발을 위한 방법론으로 애자일을 채택하게 된다.

애자일, 기민한 방법론이라고도 하는데 딱히 기민하다고 표현하기에는 애매한, Adaptive라고 하면 조금더 이해하기 좋은 방법론이 있다. 서양 멋쟁이 형님들 17명이 모여서 만든 방법론이긴 한데 막상 한국에 들어와서 K-agile이 되는 경우가 많다.

수평적이라기엔 애매한, 조금더 수직적인 수많은 조직에서 애자일을 한다고 이야기 하지만 정말 애자일하게 개발하는 곳들이 한국에 존재할까? 워터폴 개발 마인드에 몇몇 애자일 도구들을 채택한 것들이 과연 애자일 방법론을 도입한 모습일까에 대해 수없이 많은 이야기를 하고 싶다.

하지만 나도 애자일 전문가도 아닐뿐 더러, 성공적인 애자일 문화를 겪어보지 않았기 때문에 이도저도 아니게 설명하는 것 보다 애자일 창시자의 직접적인 이야기를 읽어 보는게 좋을 것이다. 특히 K-agile 을 경험한 사람들이라면 정말 눈물없이 볼수 없는 소설 책, Clean Agile(내돈 내산)을 추천한다.

5. 2022년 테크타카 프론트엔드 개발자

정말 많은 경험을 했다. 가장 기억에 남는건, 부사수가 생겼고, 부사수가 퇴사했다.

프론트엔드 한 팀을 이끌게 되었고(나포함 2명 ~ 3명), 그 팀에 속해있는 팀원들이 모두 2022년에 취업한 신입 개발자 분들이다. 그 안에서 조금이나마 경력이 더 있고, 더 빨리 이곳에 들어와서 엣헴 엣헴을 하고 있는데 생각보다 쉽지가 않다.

올해 초, 작년 말에 시작한 모듈이관과 창고 레이아웃 에디터 개발이 완료가 되었다.

1). 올해 초, 모듈 이관

모듈이관의 경우, 태초에 모든 도메인 코드가 하나의 레포지토리에 있었고, 이것이 너무 비대해지고 하나를 배포하면 다른 코드도 배포되다 보니 이래저래 말썽이 많았다.

그래서 각 도메인 별로 레포지토리를 이관하게 되었고, 그안에서 공통적으로 사용하는 UI 컴포넌트와 공통 로직 함수를 git submodule 로 분리하는 작업이 내가 입사하기 전부터 진행되고 있었다.

개인적으로는 이럴때에는 모노레포로 가는게 더 낫지 않았을까 라고 생각했지만, 이미 정해진 것이다 보니 따르게 되었다. 그리고 공통 모듈을 분리해나가며 이를 다른 레포지토리에 열심히 코드를 옮겨 가며 git module로 관리하게 되었다.

이 안에서, 불필요한 코드 및 라이브러리들을 제거하는 작업을 담당하게 되었는데 이때다 싶어 flow 사용하던 것들을 typescript로 변환해보았다. 모든 코드에 대한 이해가 없었기 때문에 모든 flow를 ts로 변환할 수는 없었지만, 주로 사용되는 메인 로직 함수의 경우 ts로 변환할 수 있어서 다행이었다.

기존에 빌드하는데 20분 넘게 걸리던 프로젝트가 옮기고 코드좀 제거하고 라이브러리 삭제를 했더니 5분 ~ 6분만에 빌드가 되었다. 정말 무겁긴 했었나 보다.

그리고 여기서 조금 문제들이 발생하게 되는데, package.json에서 디펜던시 관리를 할 때, 버전 명시를 ^ 또는 ~ , latest 등 다양하게 관리를 하는데 이미 기존에 package-lock.json 때문에 특정 버전이 고정이 되어있어서 문제가 없었다.

하지만 신규 프로젝트를 작성하기 위해 환경 설정을 하고 git module 을 연결하니 의존성 문제들이 터지기 시작했다.

첫 번째 문제는, git module에서 사용하는 라이브러리들에 대한 접근을 어떻게 할 것인가 였다. 기존에는 모든 도메인이 한 레포지토리에 존재하다보니, 모든 라이브러리들이 떡칠이 되어있었고, 그나마 이 모든 라이브러리가 package.json 및 package-lock.json 에 명시가 되어 있었다. 하지만 신규 프로젝트에 git module 에 존재하는 코드가 참조하고 있는 의존성들의 경우 정말 답이 없었고 하나하나 일일이 복사 붙여넣기 하는 것은 더 답이 안된다고 생가했다. 그래서 이를 해결하던 도중 yarn workspace 로 해당 module 디렉토리를 지정시켜서 해결하는 방식을 채택했다. 사실 그렇게 좋은 방법은 아니지만, 현재 코드베이스를 지키면서 가장 시간이 덜 걸리며 문제를 해결 할 수 있다고 생각했기에 이렇게 문제를 해결했다.

두 번째 문제는, 패키지 버전 충돌 문제였다. 왠만한 라이브러리 들은 SemVer에서 patch, 0.0.x 업데이트에서 브레이킹 체인지를 만들지 않는다. 그러나 MUI 의 경우 patch 버전에서 클래스 명을 바꾸게 되는데, 회사내 코드중 MUI의 클래스명을 오버라이드에서 스타일링을 바꾼 것들이 꽤 많았고, 레거시 버전에서 사용하는 MUI의 x.y.z 와 동일한 package.json 버전을 가지고 온 신규 프로젝트의 MUI가 x.y.a로 달랐기에 수없이 많은 것들이 깨지게 되었다. 어디서 부터 손대야 할지 몰라 멘탈이 나가 있던 찰나에, MUI 의 특정 버전을 알게 되었고, 이버전을 명시해서 설치하므로 문제를 해결 할 수 있었다.

세 번째 문제는, 다양한 도메인의 코드가 섞여 있다보니, 불필요한 Provider와 css, polyfill들이 섞여있었고, 진짜 필요한 Provider와 환경 설정 코드들의 경우 방치가 되어 있어서 이를 묶어주는 작업이 필요했었다. 그래서 Provider와 환경 설정을 묶어 버린 HOC를 만들어 이를 공유하게 되었고, 앞으로 다른 프로젝트에서도 이를 기반으로 손쉽게 우리의 module을 사용할 수 있게 되었다.

네 번째 문제는, 신규 입사자의 컴퓨터에서 발생한 문제였다. 신규 입사자들의 경우 금방 따뜻해지지 않는 강철심장의 M1 맥북을 받았다. 그러나 그 강철심장 M1도 node14에 어울리는 node-sass 가 지원이 안되었고, 이를 해결하기 위해서는 node-sass를 지우고 sass를 설치해야 하는데 sass를 설치하는 경우에 font-awesome 라이브러리가 깨지는 이슈가 발생했다.

해당이슈의 경우, font-awesome을 쓰는 코드가 정말 레거시한 코드였고, 불행중 다행(?) 인지 모르겠지만, 내가 담당하는 도메인에서만 font-awesome이 들어간 코드를 사용하고 나머지 도메인에서는 font-awesome을 사용하지 않았다. 그래서 다른 도메인의 코드에서 font-awesome과 관련된 중복된 코드 및 불필요한 코드를 제거하고, 의존성을 날리니 해결이 되었다.

짧지만 정말 강렬한 경험이었고, 생각보다 내가 이런류의 작업을 좋아한다는 것들에 대해 알게 되었던 경험이다.

2). 작년 12월 ~ 올해 4월, 창고 레이아웃 에디터

이전 회사에서도 에디터를 개발하면서 많은 골머리를 썩여왔다. 에디터를 만들던 경험이 여기서도 사용하게 되었다. 이번에는 물리적인 창고를 추상화하게 그려내고, 데이터로 관리할수 있기 위한 용도의 창고 레이아웃 에디터를 개발하라고 한다.

간단하게, 창고 층이 있고, 층을 섹션으로 나누고, 섹션에 렉을 배치하는 것이다.

이 안에서 줌도 만들고, 간격자도 만들고, 줌과 간격자와 멀티 셀렉트와 싱글 셀렉트도 만들고, 회전도 되고 복제도 되고 삭제도 되는 그런 드로잉 툴(?) 같은 에디터도 만들어 보았다.

전회사에서 수학 도형을 그리기 위해 자체 좌표 시스템을 만들고, 이를 브라우저 좌표계 <-> 실물좌표계를 변환해가며 이것저것 마우스 이벤트도 넣고 하다보니 제법 재미있었다. 그리고 성능에 대한 많은 고민도 할 수 있게 되었다.

렉들을 Drag & Drop할 경우에 중복이 될 수 있는데, 이 중복 관련된 처리를 언제 할 것이며, 이 Rack들이 겹친것을 어떻게 판별할 것인가 부터, 멀티 셀렉트된 Rack들을 움직이게 할 때 어떻게 할지, 컨텍스트와 이벤트 핸들링등 정말 미친듯이 고려할 것들이 많았다.

나와 아직 1년이 안되었지만 마음이 맞고, 아주 똑똑한 프론트 개발자분과 함께 해서 즐겁게 개발하긴 했었다. 같이 타입스크립트를 쓰면서 문서화를 하고, 서로의 코드가 이해가 안될 수 있으므로 JS doc을 사용해서 더 명시적으로 표현해보자, 이름과 변수를 더 통일화 해보자등 이런저런 이야기를 하며 개발을 했었다.

한편으로는,아예 에디터 개발 팀이 꾸려져서 이런 에디터 툴을 만들 수 있는 경험을 해보고 싶다는 생각이 들었다. 가끔 사람들이 지나가는 말로 피그마에서는, 다른 에디팅 툴에서는 이런거도 되던데… 라는 이야기를 할 때마다 저도 해드리고 싶어요 ㅠㅠ 라는 생각이 들면서 조금 아쉬운 경험도 있었다.

하지만 에디터를 만드는건 정말 힘들고 어려운 일이며, 그만큼 보람찬 일이었었다. 다음에는 조금더 다양한 사람들과 함께 전문적으로 에디터를 만들어보고 싶다.

3). 어드민 화면 유지보수 및 개발 (5월 ~ )

소프트웨어는 변화에 대응하기 좋아야 한다. 그리고 하나의 소프트웨어는 오래된 역사와 다양한 개발자들의 노고, 땀이 들어가 있다.

가끔은 눈물없이 볼수 없는 코드들도 존재하며, 때로는 와 진짜 만들기 쉽지 않았겠구나… 라는 코드들을 유지보수 해야 할 때도 있다.

나에게 있어서 어드민 화면이 그랬었다. 관리 되지 않은 코드들이 쌓이고 쌓이며 수정에 수정이 올라가지면서 다들 건드리기 싫어하는, 리뉴얼 되어야 하는 화면이라며 특정 버그가 나는 부분만 수정하거나, 신규 피처를 개발해야 하는 경우가 있었다.

여기서 깨진 유리창 법칙에 대해 다시금 이해하게 되었는데, 유리창이 깨지고 나니 그렇게 관리하고 싶어지지 않게 되는 이상한 마음이 들게 된다. 만약 내가 어드민 웹을 유지보수 및 개발만 담당하게 되었다면 매스를 들고 조금씩 수정해보겠지만, 맡은 프로젝트가 많은데 그 안에서 중요도가 덜한 이 프로젝트를 고치기에는 여간 많은 리소스가 들어가서 미뤄두고 있다. 언젠가는 고칠 수 있겠지 라며…

4. 풀필먼트와 온보딩 (6월 ~ )

프론트엔드 개발자로써 처음으로 메인 개발자로, A부터 Z까지 만들어본 경험을 했다. 기술스택 선정부터 어떤 방식으로 만들지, 디렉토리 구조 및 표준까지 내가 다 정하는 거였고, 나와 함께하는 파트너는 내 생애 첫 부사수이자, 올해 2분기에 입사한 신입 프론트엔드 개발자 분이었다.

함께 만들기 위해 많은 것들을 공부했다. 나도 공부를 많이했지만, 개인적인 욕심으로 부사수분께 많은 숙제를 내드렸다. 그리고 힘들어 하셨다(죄송합니다.)

같이 동고동락을 많이 했었다. 어떤 기술 스택을 선택하고, 디자인 컴포넌트들을 만들어 갈지. props는 어떤 이름으로 내릴 것이며 어떤 것들을 기대하며, 우리가 디자인 컴포넌트에서 이와 같은 props를 이런 인터페이스로 공유해서 쓰자고 이야기도 나누어 보았고, react-query 와 recoil 을 사용하면서 기존에 뚱뚱했던 store의 사용방식을 바꿔보는 것에 대해 논의도 해 보았다.

풀필먼트의 경우, 기존 도메인에서 화주들이 주로 사용하는 기능들을 모아, 한 웹에서 간단하고 편리하게 사용하기 위해 리뉴얼된 프로젝트였다. 물론 그안에서 나는 전혀 경험해보지 못했던 도메인과 용어들에 대해 익숙해지기 위해 노력했고, 전혀 사용해보지 않았던 기술스택과 환경변수, 그리고 빌드를 위한 도커파일을 만지며 매일 야근을 했었다.

이와 동시에, B2B2C용 화면이기 때문에 공통적으로 로그인 할 수 있는 화면이 필요했고, 해당 프로젝트에 대한 온보딩도 필요하기에 온보딩 및 공용 로그인 페이지도 함께 제작하며 이런저런 코드들을 작성해보았다.

6월부터 11월 까지 정말 많은 야근과 주말 출근, 공휴일 업무가 존재했다. 그리고 말도 안되는 기간을 산정했기에 이를 지키기 위해서 겁나게 달렸었고, 꽤나 힘들었던 경험이 있다. 물론 여기에 개인적인 중요한 일정까지 겹치다 보니 멘탈이 같이 나가긴 했었었다.

그러나 다행히도, 일정이 밀리기는 했지만 10월 ~ 11월에 런칭 및 오픈 베타 버전을 통해 안정화 되기 시작했고, 아직 큰 문제 없이 돌아가고는 있다.

6. 꼬마 팀장으로써

올해 6월, 새로운 프로젝트를 맡으면서 프로젝트를 같이 수행하게 될 신규 프론트엔드 개발자 분이 입사하셨다. 표면적으로는 수평적이지만 어찌되었던 간 내가 더 오너쉽을 가지게 되는 위치였고, 신규 입사자 분께서 내 부사수 처럼 같이 일을 하게 되었다.

사실 표현을 사수 부사수라고 하는 것도 웃기지만 당시에는 이렇게 생각을 했었고, 지금와서 드는 생각은 그저 함께 일한 동료다. 위계나 그런것의 차이 없이 같은 프로젝트를 만드는 동료와 함께 일하게 되었다.

신규 입사자분의 경우 아무래도 프로젝트를 하다가 현업 코드 및 현업에서 커뮤니케이션이 처음이라 처음에는 많은 것들을 어려워 하셨다. 약간 여기서 짜증 및 신경질도 부리지 않았나 반성해보고, 실제로 사과도 종종하고는 했었다. 그래도 어찌저찌 같이 일하고, 야근도 하면서 전우애를 쌓을 수 있게 되었다.

프로젝트를 처음 시작할 때에는, 이것저것 같이 많이 공유하고, 고민하면서 많은 것들 나누어 갔다. 워낙 똑똑하신 분이라 이해도 금방하시고 잘 적응하셨다.

프로젝트가 점차 진행될 수록 다가오는 마감일을 맞추기 위해 우리는 수많은 야근을 함께하고 이때 다양한 이야기들을 나누게 되었다.

왜 개발자를 하게 되었는지, 어떤 프론트엔드 개발자가 되고 싶은지, 어떤 커리어를 앞으로 가져가고 싶은지, 이전에는 어떤 것들을 했는지 등을 이야기 했었다.

개발 경력 및 개발 지식 정도야 내가 더 많을 수 있겠지만, 커뮤니케이션 능력이나 꼼꼼함 등의 경우 때로는 부사수님께서 더 나은 모습을 보여주기도 하셨다. 그리고 각자 다른 환경에서 다른 삶을 경험했었기 때문에, 프로젝트에서 프론트엔드에 대한 책임은 내가 지지만 함께 개발하는 경험이 더없이 소중했고, 또한 한없이 내가 부족함을 느끼게 되었다.

같은 동료로써 코드에 더 매몰되다 보니 코드리뷰를 충분히 더 하지 못했거나, 코드 가지고 조금더 싸워볼 걸 이라는 생각과 함께, 결국 프로젝트 또한 사람들과 함께 하는 것임을 느꼈고, 같은 팀을 이루는 사람으로써 더 많이 다양한 주제로 이야기 해야 함을 느낄 수 있었다.

이후 프로젝트가 끝날 무렵 신규 입사자분이 한분 더 오셨고, 프로젝트 런칭 이후 내 부사수 님은 퇴사 의사를 밝히셨다. 새로운 도전을 하러 가는 그를 응원하며, 떠나보내는 아쉬움이 정말 컸지만 더 멋진 도약을 통해 앞으로 더 큰 필드에서 만나기로 약속했다.

첫 부사수, 안녕, 언제나 응원합니다.

마무리

이것 저것 속에 있던 이야기들을 꽤나 주저리 주저리 적어 보기는 했다. 어느정도 속 시원한 부분도 있고, 마음속에서 충분히 정리되지 못해 작성하지 못한 부분도 있다.

또한, 나의 부족함을 가감없이 적기에는 또 못난 사람이라 충분히 적지 못하기도 했다.

그러나 한 해를 맞이 하기 전에, 지난 2022년 한해를 돌이켜 보며 그 안에 소소하지만 소중했던 나날들을 돌이켜 보았다.

그나마 다행인 것은, 2021년 보다 더 다양한 경험을 했고, 많은 사람들을 만나 이야기를 했다. 직업적으로, 커리어적으로 더 성장했고, 개인적인 모습과 인간 관계에서도 더 솔직해 질 수 있는 한해였다.

2023년에는 이번에 작성한 것들을 기반으로 앞으로 더 개선되었으면 하는, 성장할수 있는 것들을 기대하며. 글을 마무리 한다.