이제 막 2년차 개발자가 된 사람의 2020년 회고

2019년 12월 16일, 퀄슨이라는 회사에 프론트엔드 개발자로 입사를 했고 벌써 1년이 지났다. (1주년 이라니! 🎉) 작년에는 몰랐는데 입사일이 연말, 즉 회고 시즌이다보니 한 해 동안 내가 무슨 일을 했고 어떤 것을 배웠는지 그리고 무엇을 느꼈는지 돌아보기 참 좋은 타이밍이라는 생각이 든다.

사실 올해는 참 많은 사람들에게 너무나 힘든 시간이였어서, 성장이니 뭐니 하는 이야기들을 길게 늘어 놓는게 조금은 조심스럽다. 그럼에도 계속 나아가고자 하는 개인의 이야기를 용기내어 기록해 보려고 한다. 성취의 결과 보다는 과정과 희로애락을 담을 수 있으면 좋겠다. 요즘에는 모든 일에 기쁨과 슬픔이 있다라는 사실을 받아들이고 있어서 그렇다.

1년 동안 두 개의 큰 프로젝트를 진행했고, 그 기간을 기준으로 삼아 Chapter1과 Chapter2를 구분했습니다. 개인적인 경험을 담은 글로 회사의 입장이나 생각과 전혀 무관합니다.

Chapter1

12-1월. 입사 첫 한 달 반

회사의 서비스 특성 상 연말 연시가 성수기이기 때문에 다른 개발자분들이 모두 바빠 보이셨다. 그 당시에는 지정된 사수나 가이드를 해주시는 분이 없어서, 혼자 회사 슬랙에 있는 채널에 이것저것 들어가보고, 여러개의 서비스마다 담당자가 누군지 파악하려고 물어보면서 레포지토리를 세팅했던 기억이 난다.

난 jQuery의 시대가 저문 이후로 프론트엔드 분야를 공부했기 때문에 HTML + CSS + Javascript + React 밖에 모르는데 당시 내가 클론 받았던 프로젝트 중 하나의 코드가 Thymeleaf + jQuery 등으로 되어 있었다. 모든게 처음 보는 것들이다 보니 local server를 띄우는 방법과 build 하는 방법도 감이 안왔다. 그렇게 헤매고 있던 중 프로모션 페이지의 UI를 수정해달라는 첫 업무를 받았다. 가격표를 수정하는 일이였는데 내 기준에서 기획서가 명확하지 않아서(직접 모든 케이스를 다 계산을 해봤는데 값이 틀렸었다), 표를 다시 작성한 뒤 담당 기획자분을 찾아가 이게 맞는지 여쭈어봤고, 얽혀있는 여러 파일들을 뒤적여서 수정한 뒤 첫 커밋을 했다. 이대로… 괜찮나?

2월. 갑작스럽게 신규 프로젝트에 involve 되다

이 당시 회사에서는 기존 서비스를 유지 보수하는 동시에 신규 프로젝트를 준비하고 있었다. 앱과 태블릿으로 영어 학습을 하는 서비스여서 웹사이트는 로그인, 회원가입, 결제, 서비스를 설명하는 페이지(ex. 과정 소개, 레벨 테스트 등)를 만들면 되었다. Next.js + Typescript + styled-components 스펙으로 거의 초기 세팅 및 일부 페이지만 개발 되어 있는 상태였고 런칭까지의 일정은 타이트했다. 아무래도 웹 위주의 서비스가 아니다보니, 웹 개발 시작 자체를 앱과 태블릿 개발보다 늦게한 것 이다.

React + styled-components 로 토이 프로젝트를 해봤지만 Next.js 와 Typescript 는 처음이었다. UI 개발은 생각보다 순조로웠지만 Typescript 는 익숙하지 않았고 props에 interface 를 정의하며 타입을 체크, enum 으로 정의하여 값을 체크하는 것 부터 시작했다. (가끔 타입을 어떻게 정의해야 할지 몰라 any 를 썼다.. holy shit…) 그래도 내가 알고 있는 지식으로 코드를 짜나갈 수 있는게 기뻤고 새로운 것을 배우는게 재미있었다.

신규 프로젝트이다 보니 기존에 유지보수 하던 서비스들에 비해 최신 기술 스택을 선택해서 만들 수 있었고(최신 기술이 무조건 좋다는 의미는 아니다), 1~2주에 한 번씩 진행하던 개발팀 세미나에서 다른 동료분들께 Next.js 와 Typescript를 어떻게 쓰고 있는지 설명드리는 프리젠테이션도 준비해서 발표했다.

💡 당시 고민 했던 것들

1. api를 통해 받은 response를 기반으로 UI 를 그려야 할 때, 첫 렌더링 시에는 null 값인데 이걸 어떻게 처리할까?

• 처음에는 response의 type과 동일하게 initial state 를 만들어 두어서 처리하다가, -1 같은 초기값이 보였다가 사라지는게 별로여서 typescript의 optional chaining을 활용했다. -> 현재는 loader를 적절히 넣어두었고 그 다음 개선은 skeleton UI 를 도입하는 것이라고 생각한다.

1. 반복적으로 쓰는 api call 코드를 어떻게 만들까?

• 난 별다른 라이브러리 없이 순수 fetch 함수로 useFetch() 라는 custom hook을 만들어서 사용했었다. hook이기 때문에 api call 할 때마다 useEffect를 반복적으로 사용하지 않아도 되었지만, api 종류가 늘어나면서 여러 종류의 api를 한 곳에 모아 관리하거나 type 정의를 어떻게 할지 까지는 고려하지 못했다.

• 이 때 동료분이 token 이 필요없는 Public API 와 token이 필요한 Private API를 axios를 활용한 utils 함수로 만들어서 제안해주셨고, 이걸 사용하기로 했다. useEffect는 반복적으로 사용해야 했지만 가독성이나 사용성 측면에서 훨씬 좋았다.

3-4월. 인생 첫 실서비스 런칭을 하다

프로젝트 런칭이 4월 중순 쯤이였고, 프론트엔드는 나 포함 2명 이었다. 한 달 반 동안 동료는 UI 작업/로그인/회원가입/쿠폰 관련 로직을 담당했고, 난 UI 작업/결제 페이지 및 결제 모듈 연결/GTM(google tag manager) 적용 을 맡았다.

결제 구현은 1) 이름과 휴대번호와 같은 기본 정보는 User 데이터에서 가져오고 2) 주소 등을 입력 받아 상품 정보를 PG사 결제창을 띄울 때 함께 넘긴 뒤, 3) 결제 결과에 따라 페이지 분기 처리를 하는 방식 으로 동작한다.

구현 자체가 엄청 복잡하지는 않았지만 필수 정보 입력 여부에 따라 유효성 검사를 하거나, 비회원 유저가 결제 페이지에 접근 했을 때 어떻게 처리할지, 쿠폰 유효시간 계산, 무통장 입금 또는 카드를 선택했을 때 UI가 어떻게 달라져야 하는지 등의 세부적인 기능도 꽤 많았다.

보통 결제 모듈에서 실패를 알리는 error code를 받으면 실패 페이지로 곧장 리다이렉트 시키는데 ‘잔액 부족’ 이나 ‘체크 카드로 할부를 시도했을 때’, 즉 유저가 다른 카드로 결제를 재시도할 의지가 있어 보이는 error code 일 때는 다시 결제 페이지로 리다이렉트 시키는 기능을 제안했다. (그리고 실제로 많은 유저들이 재결제를 시도했다! 난 코드가 비즈니스에 직접적으로 도움이 될 때 보람을 느낀다라는걸 이 때 깨달았다.)

또한 실서비스 개발이 처음이다 보니 api의 endpoint가 dev, stage, live 마다 달라지는 것도 처음 배웠고 이 시점에서 본격적으로 백엔드 개발자분들과 협업을 시작했던 것 같다.

3월에는 코로나로 재택 근무를 했는데, 4월에는 상황이 좀 나아졌다. 우리는 아주 종종 밤 12시까지 일하고, 새벽 3시까지 술 마시며 git flow와 같은 온갖 기술/일 적인 토론을 하다 집에 가곤 했다. 이 기간 때 팀 자체의 텐션이 높았고 합이 좋았는데 한꺼번에 너무 많은 것을 배우다 보니 정신이 없었지만 일하는게 정말 재미있었다.

• 런칭했던 프로젝트(Homeglish) 링크
  
• 첫 서비스 런칭 후기 youtube 영상 링크

💣 당시 가장 힘들게 느껴졌던 일

1. 프론트엔드가 끝나야 일이 끝난다.

• 프론트엔드의 업무는 백엔드의 api, 기획과 디자인이 모두 완료 되어야 완전히 마무리 할 수 있다. 즉, 매듭을 짓는 사람이다. 어떻게 보면 당연한건데 일을 시작하기 전에는 이것에 대해 크게 생각해보지 않았던 것 같다. 마감 기한은 변하지 않는데 나보다 먼저 끝나야 하는 앞단의 업무들에서 계속 변경이 일어나 일정이 밀리기 시작하니까, 내가 촉박하게 마무리 해야 한다는게 큰 스트레스로 다가왔다. 하반기에 진행한 두 번째 프로젝트 런칭 때도 같은 문제가 반복 되었지만 이 때의 경험으로 유연하게 업무적, 심리적으로 대응할 수 있었다.

1. 결제 테스트... 빡셌다...

5월. 런칭 후 이슈 핸들링 기간

서비스 런칭 직후로 기존에 놓치고 있었거나 발견되는 이슈들을 처리했다. 가장 크게 배웠던 것은 코드가 다른 브라우저 환경마다 다르게 동작한다는 사실 을 경험하고 이해한 것이다.

인앱 브라우저: 브라우저 앱이 아닌 일반 앱(인스타...) 등에서는 새 창, 새 탭 자체가 아예 안 뜸. 후 이 놈들아.... iframe 같은걸로 해결 필요. 아님 안띄우는 방법으로 기획을 다시 해야함

— 개발화라리 (@devhwarari) May 15, 2020

여유가 좀 있을 때는 중복해서 사용하던 interface를 통일 시키거나 extends 하는 등 리팩토링을 진행했다. 동시에 이 기간에는 꽤 무력함을 느끼기도 했다.

코드에서 로직적으로 문제가 있을 때는 시간을 두고 살펴보면 대부분 해결할 수 있었지만 인프라 관련 지식이 아예 없었기에 docker에서의 build 과정이나 aws의 eb 등 배포 환경에서 문제가 발생하면 도저히 손을 댈 수 없었다. 이 때의 경험이 트리거가 되었는지 하반기에 진행했던 프로젝트의 dev 서버 배포 세팅을 제가 해보겠다고 했고, 성공했다! 도와주신 서버 개발자분 고맙습니다.

6월. 프론트엔드 업무를 혼자 하게 되다

나와 붙어서 일하던 프론트엔드 동료 개발자분이 퇴사를 해서 혼자가 되었다. 배울점이 많았던 동료여서 많이 아쉬웠지만, 아이러니하게도 혼자가 되니 책임감이 커져 일에 더 몰두할 수 있었다. 6월 말에 비용이 큰 마케팅 이벤트가 잡혀 있어서 BM 변경 및 프로모션 페이지 UI의 전반적인 업데이트 를 진행했다. 런칭을 준비하던 기간만큼 업무가 많지는 않았지만 혼자서 웹페이지와 관련된 기획, 디자인, 운영, 마케팅, QA 분들과의 모든 협업을 담당해야 했기에 하루하루 긴장하며 보냈던 것 같다. 주말에 기획, 디자인의 모든 리소스를 파악하고 평일에 코딩하는 나날을 반복했다.

7월. 다시 혼자에서 둘로. 개발자지만 광고도 찍습니다

리더님이 하반기에는 지금보다 일이 많아질 것 (실제로 어마어마했다..) 이라고 하셔서 동료 한 명을 다시 뽑기로 했다. 나랑 같이 공부하던 코드를 잘 짜는 친구를 추천했고, 서류와 면접을 잘 통과해 함께 일하게 되었다!

자잘한 이슈들을 처리하면서 모바일에서 webview로 띄우는 학습 리뷰를 작성하는 페이지 를 하나 만들기도 했는데 다른 디바이스(모바일과 PC)끼리 통신을 해본 적이 없어서 협업하는 모바일 개발자분과 서툴게 커뮤니케이션 했던 기억이 난다. 뭐랄까 아무리 webview로 띄운다고 하더라도 웹에 붙어있는 버튼을 모바일에서 조작할 수 있다는 컨셉이 익숙하지 않았다.

이 과정에서 나의 부족한 점도 깨닫게 되었고 지금도 항상 염두하면서 일하고 있다.

1. 차근차근 디버깅 하기. 뭐가 잘 동작하지 않으면 이게 왜 예상대로 동작하지 않는지 몇 가지 가설을 세우고 가능성이 높은 가설부터 하나씩 확인해보면 된다. 여러가지 이유로 문제를 무작정 빠르게 해결하려고 했는데, 그보다 정확히 알고 해결하는 연습을 하는게 훨씬 좋다는 것을 배웠다.

2. 같이 일하는 동료가 헤매고 있을 때 재촉하기 보다는 더 부드럽게 이야기하기. 힘든 상황에서는 함께 해결하려고 노력하는 태도가 시너지가 되며(심지어 내가 답을 알고 있더라도), 이게 곧 해결의 씨앗이다.

👯‍♀️ 번외

• 에릭남이 회사 서비스 중 하나의 모델이여서 함께 광고 촬영을 했다. 촬영 직후, 회사의 서비스 모델에 큰 변화가 있어서 퍼블리싱 되지는 못했지만.. (재밌게 촬영 잘했는데 너무 아쉽다 헝헝) 올해 즐거웠던 기억 중 하나. 촬영하던 날 이슈 때문에 바쁘기도 했고 연예인에 기대나 로망(?)이 없어서 같이 셀카도 안찍고 사인도 안받았다. 그 후 돌아오던 주말에 에릭남 영상을 하나 찾아봤다가, 주말 내내 에릭남 유투브 채널만 봤다고 한다.. 과거의 쿨한 척 했던 나 어디로…?

Chapter2

7월 중순에 회사에서 큰 의사결정을 내려졌다. 많은 사람들이 알고 있는 리얼 클래스, 그리고 각자 다른 컨셉을 가지고 있는 3개의 영어 학습 서비스(브릿 잉글리쉬, 닥터뮤지, 홈글리쉬)도 별도로 운영하고 있었는데 이 3개의 영어 학습 서비스를 리얼 클래스에 합치기로 한 것! 기존 리얼 클래스에 merge만 시키는게 아니라 아예 다시 만들기로 했다.

컨텐츠로 영어 공부를 하는 플랫폼을 만드는 것 을 목표로 하는 결정이었다. new 리얼 클래스의 런칭 목표는 12월 중순 으로 주어진 시간은 거의 4-5달 밖에 없는셈.

앞서 상반기에 진행했던 프로젝트와 달리 결제까지만 가능한 웹사이트가 아니라 1) 웹에서도 학습이 가능해야 했고 2) 모바일&태블릿에서의 학습도 모두 webview 로 구현 하기로 했다. 구현의 난이도와 양이 상당했기 때문에 이 시점부터 회사에 있던 모든 웹프론트엔드 개발자 5명이 하나의 팀이 되었다.

8월.

이 시점에는 아래와 같은 일을 했다.

- 기획 & 디자인 리뷰
- 개발 환경 세팅 및 구현 방향 설정
  - 폴더 구조, eslint & prettier, git branch 규칙 논의
  - 4벌의 디자인(web, mobile web, tablet webview in app, mobile webview in app)이 주어질텐데 코드 관리를 어떻게 효율적으로 하지? 적응형으로 할지 반응형으로 할지
  - 상태관리는 어떻게?
  - style 단위는 무엇으로 할지?
- 공통 컴포넌트 리스트(ex. modal, dropdown, selector, accordion, tooltip...) 를 뽑아서 미리 구현
- 핵심 기능(학습)의 skeleton code 미리 구현

기획, 디자인이 완료되기만을 기다리지 않고 이 당시에 우리가 할 수 있는 일을 찾아서 했다. 지금 다시 돌아보면 저 당시에 미리 논의하고 작업한 것들이 본격적인 구현을 시작할 때 얼마나 큰 도움이 되었는지 신기할 정도다. 이런 기술적 의사 결정을 내리는 과정에 함께하며 동료들한테 참 많이 배웠다.

또한 나는 이 시즘에 ‘공통 컴포넌트(Playlist, Selector, Accordion)’를 구현해보면서 한 단계 성장했다고 생각한다. 이전까지는 일회성으로 사용하는 컴포넌트만 만들었는데 핵심 기능은 공통적으로 동작하게 하고 어떻게 스타일만 커스텀하게 만들지? 고민하는 과정에서 상태값의 위치는 어디에 두어야 하는지, 어떤 값과 함수들을 노출 시킬지 등을 고려하기 시작했다.

기획과 디자인 리뷰도 꼼꼼히 참여했는데 이 페이지의 맥락상 해당 기능이 정말 필요한지 토론했고, 조금 더 나은 사용성을 개선 시키는 UI를 직접 그려서 (조심스럽게) 다시 제안하기도 했다.

9월-10월. 두 달만에 서비스 로직을 모두 개발하다

• 9월

우리의 핵심 기능은 당연히 ‘학습’ 으로 강의를 재생 시키고, 강의에 맞는 자막과 해설을 play time에 맞게 보여주고, 사용자가 문장을 담을 수 있게 하고, 문장을 반복해서 트레이닝 시키는 동작 등을 구현해야 했다. 8월 중에 이 동작에 관련된 Base 코드를 동료분이 작성해주셨는데 9월 초부터 더미 api, 기획 및 디자인 등이 차례차례 완료되어 난 api를 연결하고, 기능과 디자인을 붙이는 작업을 진행했다. (PR을 살펴보니 정확히는 학습 1단계, 2단계, 정주행에 관련된 기능을 구현함) 아무래도 앞으로 계속 사용할 핵심 코드에 대한 구조를 잡는 시점이였어서 모든 팀원들이 함께 치열하게 토론했던 시기이기도 하다.

중순부터는 실데이터를 response 로 받을 수 있었는데 또 실데이터를 연결하다보니 코드를 수정 해야 할 일이 많았다. 새로운 기능 구현 시에도 디테일한 부분들은 기획서에 정의 되지 않아서 기획자분들과 실시간으로 논의를 진행하며 코드를 붙였다. 모든 팀원이 말도 안되는 속도와 에너지로 일을 했고, 10월 초 쯤에는 웹에서 대부분의 핵심 기능이 돌아가게 했다.

💡 당시 고민 했던 것들

1. Player의 State를 어떻게 가져갈까? 어떤 값은 redux store에 공통으로 두고 어떤 값은 컴포넌트의 local state나 hook으로 관리할까?
2. 학습에 필요한 static한 summary 데이터와 detail 데이터, 사용자의 학습 log 데이터를 어떻게 관리할까?

• 10월

10월은 웹을 Base로 구현해 둔 코드를 tablet, mobile UI 로도 변환하는 작업을 진행하는 동시에 웹에서 구현이 안된 디테일한 기능들을 잡아갔다. 이전까지 나는 반응형 처리를 해본적이 없었는데 web UI 를 table, mobile UI 로 변환하는 작업을 맡으며 디바이스 크기나 스타일에 대한 단위에 대해 이해 할 수 있게 되었다. 추가로 내가 짰던 학습쪽 코드를 동료분이 리팩토링 해주셨는데, 개선된 코드를 보며 custom hook 이 어떻게 중복되는 로직을 분리하게 도와주는지도 배울 수 있었다.

11월-12월 중순. 프로모션 페이지 작업과… 런칭! ✨

런칭이 한 달 반 정도 남은 시점이였고 남은 일은 계정/결제쪽 구현, admin, 서비스 QA, 프로모션 페이지 작업이었다. 그 중 나와 동료 1분이 같이 프로모션 페이지 작업을 맡았다. 프로모션 페이지란 사용자가 상품을 구입하기 전까지 웹사이트에서 보는 모든 페이지를 말한다.

사실 이 일은 UI 작업이 많다보니 서비스 로직 개발에 비해 구현의 난이도가 높지는 않다. 하지만 아무래도 구매를 하러 웹사이트에 들어온 사람들에게 우리의 서비스가 매력적으로 보여야 하니 기획이랑 디자인이 쉴새없이 변경되기도 하며, 개발팀을 제외한 거의 모든 타팀들과 협업을 해야 하기 때문에 커뮤니케이션을 많이 해야해서 피로도가 정말 크다. (앞서 상반기에 런칭한 첫 프로젝트에서 나를 가장 힘들게 했던 일이라고 말했기도 하다)

이번에도 런칭 직전까지 변경이 많았고, 관련된 유관 부서(거의 모든 팀)에게서 오는 피드백을 대응해야 했다. 전사 QA 다보니 진입 장벽이 높은 Jira 사용을 강요할 수 없다고 판단했고 Notion 으로 문서를 만든 후 QA 방법 및 범위, 일정과 담당자를 명확히 공유했는데 꽤 성공적으로 진행 되었다. 기획과 디자인을 그냥 개발하는 것이 아닌 UX를 고려하여 개선할 점을 계속 제안했던 것도 만족스러웠던 부분 중 하나이다.

12월 17일 새벽 1시, 최종 배포를 완료했고 런칭을.. 진짜 했다. 리더님이 해주신 말씀을 빌려쓰자면… 지금 있는 개발팀의 모든 멤버가 아니였다면 불가능 했을거다. 런칭 직후에도 (좋은 의미로) 정신 없은 나날들을 보내고 있다.

그리고 남은 이야기들

올해는 어떤 회사에 있어도 이보다 더 압축적으로 성장하고 경험할 수 없었을 것이라고 생각한다. 운이 좋게도 상황적으로 배울 수 있는 환경이 계속 주어졌고, 뛰어난 팀원들과 함께 일할 수 있었다. 스스로에게도 정말 잘했고 고생 많았다고, 토닥여주고 싶다. 그럼에도 생각이 많은 나는 여전히 머리속이 가득차있다.

나라는 개발자의 정체성은 뭘까?

하반기에는 기술적으로도 정말 많이 배운 시기였지만 동시에 나라는 사람이 어떻게 일하는지 다시금 알 수 있는 시기이기도 했다. 그리고 이게 날 뿌듯하게 하기도 힘들게 하기도 했다.

돌아보면 대학생 시절의 프로젝트, 개발 커뮤니티 활동에서도 내가 가장 중요하게 생각하는 것은 ‘일이 되게 하는 것’ 이였다. 이번 프로젝트에서도 누가 시키지도 않았는데 런칭 일정을 맞추려면 우리가 지금 어떤 일을 해야 하는지 우선 순위를 조정하고, 이를 기반으로 논의를 진행하고 적용했다. 같이 일하다 보니 팀원마다 고유한 장점이 눈에 보였고 리소스를 나눌 때 그걸 기준으로 삼았다. 타임라인 마다 내렸던 주요한 의사결정은 아래와 같다.

- 8월: 공통 컴포넌트를 계속 만드는 것을 멈추고, 기획/디자인이 아직 완료되지 않았더라도 페이지 단위의 개발을 시작해야한다.
- 9월: 두가지 기준(개발 공수가 많은지, 서비스 측면에서 반드시 필요한지)을 기반으로 drop 시킬 수 있는 기능을 리스트업
- 10월: 코드 리뷰에 소요되는 시간이 너무 많아서 이제 멈춰야 한다. 공유가 필요한 코드는 별도로 리뷰
- 11-12월: 프론트엔드팀의 리소스 분배 및 돌아가는 모든 일의 진행 상황 f/w와 리더 공유

나도 코드를 잘 짜고 싶은 개발자이기에 ‘동작하는 코드 리팩토링은 그만하고 남아있는 피쳐를 개발해야 한다’ 거나 ‘지금 일정상 코드 리뷰를 멈춰야 한다’ 라는 식의 말은 당연히 하고 싶지 않다. 그럼에도 내 머리에서는 지금은 이게 맞는 판단이라고 생각하고 수면 위로 논의를 꺼낸다. 비슷한 몇 가지의 일을 통해서 내가 동료 개발자분들과 다른 관점을 가지고 있구나 라는 생각을 자주 했는데 그 과정에서 종종 외로움을 느꼈다.

요즘은 장점이 곧 단점이라는 생각을 많이 한다. 이게 나라는 사람의 개성이고 상황적으로 다르게 판단될 수 있다고 말이다. 그 때, 이전에 윤태호 작가님이 했던 말이 떠올랐다.

꿈이라고 하는 게 단순히 만화가, 과학자, 연예인 이게 꿈이 아니라 ‘00한 만화가’가 꿈이다.. 라고 할 수 있어야 한다. 그 직업을 어떤 태도로 수행하는 내가 있어야 하는 거고 중요한 건 그냥 만화가가 아닌 어떤 만화가가 되느냐이다.

내가 아름답고 우아한 코드를 짜는 것도 좋지만 그보다 (코드를 포함하여 종합적인 것들을 고려했을 때) 최고의 프로덕트를 만드는 개발자가 되고 싶다. 는 것을 어렴풋이 확인할 수 있는 한 해였다.

이렇게 긴 글을 쓴 이유

(올해 했던 일을 잘 정리해두고 싶은 것도 있지만 그와 더불어)

살면서 중요하게 생각하는 가치 중 하나는 ‘서로의 다양성을 받아들이는 것’ 이다. 많은 사람들이 개발자는 이래야해~ 라는 스테레오 타입을 머리속에 가지고 있다. geek 스러워야 한다던지, geek 스러워야 한다던지, geek 스러워야 한다던지... 같은 것들 말이다. 난 geek 스럽지 않았고(외모와 성격 모두) 이런 편견이 과거에 내가 개발자라는 직업을 선택할 때 망설이는 이유가 되었었다. 그래서 이제는 같은 이유로 망설이는 사람들에게 말할 수 있고, 말하고 싶다. 디자인적 감각이 뛰어난 개발자던, UX를 중요하게 생각하는 개발자던, 교육을 중요하게 생각하는 개발자던 그냥 본인이 원하는 모습의 개발자가 되면 된다고. 팀의 구성원들이 각자 고유한 장점을 가지고 있으면서 서로의 단점을 메꾸어 주는 것이 최고의 팀이라고 생각하며, 난 그걸 우리가 증명했다고 믿는다. 서로에게 매순간 배울 수 있었던 1년 이었다. 그리고 워커홀릭이지 않아도 괜찮다.

현업에 있는 프론트엔드 개발자는 무슨 일을 하나요? 라는 질문을 꽤 많이 받는데, 이 글이 그에 대한 대답이 되었으면 좋겠기도 하다.

내년의 목표들

올 한해는 신규 프로젝트를 런칭하는데 거의 모든 시간을 쏟았다. 내년에는 빠르게 무언가를 만들어내는 일을 반복하기 보다 런칭한 서비스를 잘 다듬어가고, 프로덕트를 성공적으로 develop 시키는 방향으로 시간을 쏟고 싶다. 사용자 볼륨도 꽤 큰 서비스여서 재밌는 일들을 많이 할 수 있지 않을까 기대가 된다.

특히 하반기에는 말도 안되게 일을 많이 했는데 팀의 속도를 어떻게 조절할지도 관건이다. 타올랐던 불을 한 번에 꺼뜨리는게 아니라, 잔불이 남아 있으면서도 필요할 때는 다시 장작을 넣어 불을 세게 붙이기도 하고 또 다시 서서히 줄어드는 그런 자연스러운 속도로 말이다. 팀원들과 함께 우리가 어떤 팀을 만들어 가고 싶은지 이야기를 나누면서 성숙하고 안정적인 팀으로 가꾸어 가고 싶다.

기술적으로 좀 더 성장하기

• 모든 공통 컴포넌트 UI 만들어보기(ex. modal…)
• redux, redux-saga 관련 코드를 잘 알고 쓰기
• javascript와 typescript를 더 자유롭게 쓸 수 있으면 좋겠다. (ex.array와 object converting, generic… )
• 프로그래밍 바이블 같은 책 3권 읽기

etc

• 유투브 구독자 3000명 만들기
• 리더쉽을 키우기 (더 좋은 동료 되기)
• 육체적, 정신적으로 모두 건강하기
• 좋아하는 사람들과 지금보다 많은 시간을 보내기

제 곁에 있어주시는 모든 동료와 친구들에게 감사와 사랑을 전합니다. 우리 모두가 항상 건강하기를 바라요. 3월에 무지개 다리를 건넌 나의 털복숭이 강아지 🐕 에게도 무한한 마음을 보내.

Table of contents