2021년 회고

2021년은 지금까지의 내 삶을 통틀어 손에 꼽을 정도로 위기가 많았던 해였다. 그리고, 동시에 기회도 많았던 해였다. 그렇기에 나 스스로 2021년의 사자성어를 정하자면, 전화위복이 아닐까 싶다. 다른 말로는 ”오히려 좋아”.

위기1

2020년 4분기부터 2021년 1분기에 걸쳐 v3.0 개발이 진행되었다. 기존에 없던 구독형 멤버십과 커머스 기능이 도입되는 제법 큰 프로젝트였다. 당시 갓 3개월 수습기간을 마치며 백엔드 개발자 포지션으로 마음을 굳혔던 것으로 기억한다. 그리고 여느 신입이 그렇듯 ‘내가 이걸 어떻게 하지?’라는 부담감과 ‘프로답게 어떻게든 결과를 내야만 한다’ 라는 의욕으로 프로젝트에 돌입했다.
본격적인 백엔드 업무는 대부분 처음이라 대표님의 도움을 많이 받았다. 기획을 바탕으로 제작된 와이어프레임을 보며 엔터티를 뽑아내 DB 모델링을 진행하고, 전체적인 프로세스를 시퀀스 다이어그램으로 그려보며 필요한 API를 정리했다. 아직 MySQL에도 익숙해지기 전이라 노트에 테이블을 하나 하나 적고, 선으로 이어보며 감을 익혀야 했다.
그리고, API를 만들기 시작할 즈음 위기가 찾아왔다. 지극히 개인적이며, 다시 떠올리고 싶지 않은 일이기에 자세히 적을 수는 없지만, 그동안의 내 삶을 통틀어 정신적으로 가장 힘든 시기였다.

기회1

서비스의 방향성이 바뀔 수도 있는 큰 프로젝트인 만큼 끝까지 마무리하고 싶었으나, 출근이 어려운 상황이었다. 정확하고 긴밀한 커뮤니케이션이 요구되는 이때, 나만 재택근무를 한다는 게 말도 안 되는 일이었다. 그럼에도 모두의 배려 속에 재택근무를 할 수 있었고, 역설적으로 이 기간동안 개인적인 성장을 이뤘다고 생각한다. 다행스럽게도 나는, 큰 압박 속에서 혼자 결과를 내야하는 상황에 처하면 극도로 몰입할 수 있게 되는 체질인 것 같다. 여담이지만 나의 MBTI는 INTP.


약 2개월 가량 재택근무를 하며, v3.0의 모든 API를 만들었다. 특히, 커머스의 ‘장바구니’, ‘결제’, ‘배송조회’는 내게 가장 큰 고통을 안겨준 동시에 가장 큰 성장의 발판이 되었다. 시간이 넉넉하지 않은 스타트업의 특성 상 이미 만들어진 다른 서비스의 도움을 받아야 하는 게 불가피할 때가 있다. 마찬가지로 물류, 결제, 배송조회가 각각 다른 외부 API로 이원화되어 있었고, 여기서 오는 고민이 있었다. 예를 들어 다음과 같은 내용이다.

1. 풀필먼트 업체의 API를 통해 상품정보를 받아와 우리 DB에 저장하고 그 정보를 앱에서 보여주는데, 재고현황의 싱크를 언제 어떻게 맞출 것인가? 싱크를 맞추는 타이밍 직전에 주문을 하여 우리 DB에는 재고가 있는 것으로 표시되었으나, 실제로 풀필먼트 업체 측에는 재고가 없는 상황이라면 어떻게 할 것인가?
2. PG사 API를 사용하여 결제요청을 한 후 결제 결과에 따라 풀필먼트 업체 API를 통해 주문요청을 하게 되는데, 이때 고려해야 하는 예외상황들은 무엇이 있는가?
3. 풀필먼트 업체의 주문조회 API에는 출고까지의 상태만 존재하기 때문에 배송조회는 Delivery Tracker를 이용하여 조회하기로 했다. 그런데 유저가 앱 내에서 배송조회 액션을 취했을 때 해당 API들을 엮어서 보내주는 것은 문제가 없지만, 배송이 시작되었을 때 자동으로 알림메시지를 보내줘야 한다. 이것을 어떻게 해야 할까?
   

물론 이외에도 문제는 많았고, 고민은 끝이 없었지만 지금까지도 ‘이게 최선인가?’ 싶은 문제들은 위의 내용들인 것 같다. 커머스는 특히 금전거래와 직접적으로 연관되어 있다 보니 신경 쓰이는 부분이 한두가지가 아니었다. 이 과정에서 batch라는 놀라운 방법이 존재한다는 사실을 알게 되었고, 상당히 많은 부분의 고민들을 batch로 해결할 수 있었다.

프론트엔드만 하고 있었을 때에는 알지 못했던 백엔드의 고충을 실전으로 겪게 되었던 기간이었다.
단순히 데이터를 내려주는 게 API라고 생각했던 내 자신이 부끄러워질 정도로 하나의 액션에서 이어지는 서버의 작업들이 뭐 하나 단순한 게 없었다. 특히, 클라이언트에서 처리하기에는 보안적으로 위험한 내용들이 대부분이기에 부담감도 적지 않았다. 말 그대로 우리 서비스를 하루 아침에 재기불능 상태로 만들 수도 있는 권한이 내 손에 있는 것이다. 그 사실을 깨닫고는 책임의 무게를 느끼게 되었다.

위기2

개인적인 문제들이 정리된 후 복귀를 하게 된 것이 2021년 2분기 쯤이었다. 이때, 통제할 수 없는 변수로 인해 삶이 흔들리는 일이 더는 없었으면 좋겠다는 생각에 영끌을 하여 작은 아파트를 매수했고, 큰 프로젝트를 마친 후 마치 시간과 정신의 방에서 막 나온 손오반 마냥 자신감에 차있었다.

그런 내가 다시금 겸손을 되찾게 되기까지는 그리 오래 걸리지 않았다. 구독 기능과 커머스에 밀려 미뤄졌던 추가기능을 개발해야 했기 때문인데, 그 이름도 생소한 WebRTC… 이것을 사용해 실시간 영상통화 기능을 구현해야 했다. 특히, UDP 기반의 기술이라는 점에서 네트워크 공부가 불가피했다.
‘UDP는 대략 네트워크 패킷이 쏟아지는 수도꼭지와 같아서 레버를 열고, 닫는다는 느낌이며, 이러한 배경 위에서 동작하는 WebRTC는 P2P로 양방향의 데이터가 지속적으로 교환되도록 돕는다’ 정도의 개념을 갖고 개발을 시작하게 되었다.

영상이 실시간으로 교환되는 핵심 기능은 이미 구글에서 제공하는 레퍼런스로 어렵지 않게 구현할 수 있었다. 문제는 네트워크에 대한 이해가 부족했던 부분이었다. 생각보다 쉽게 구현 되었던 것은 테스트 환경이 로컬 네트워크였기 때문이었다. 각 peer의 public ip를 알아야 하는 실제 환경에서는 NAT가 필수였으며 WebRTC는 그것을 stun 또는 turn 서버라는 형태로 중계한다.

MDN에서 제공하는 WebRTC 문서를 수차례 보았지만 여전히 이해하기 쉽지 않은 기술이다. 애초에 네트워크를 비롯한 컴퓨터공학 지식이 빈약하기에 일어난 문제라는 점을 직시해야만 했다. 그렇다고 해서 내가 충분히 공부를 마칠 때까지 기다려줄 만큼 현실은 녹록치 않기에 수시로 구글링을 하며 구현해야만 했다. 이 과정에서 특히 도움이 됐던 책은 ‘네트워킹과 웹 성능 최적화 기법’이라는 OREILLY 책이다. 기초적인 네트워크 용어들부터 WebRTC 공식문서 번역본까지 수록되어 출퇴근 길에 수시로 읽었던 기억이 난다.

그나마 다행이라고 해야 할지는 잘 모르겠지만, turn 서버의 구현과 연결 과정에서의 결제 프로세스, 연결 실패 시의 예외처리 등 백엔드의 업무는 비교적 많지 않았고 바로 이어서 페이백 신청 기능과 어드민 페이지에서의 페이백 심사 기능 구현에 돌입했다. 혼란과 자괴감으로 점철되었던 WebRTC를 겪은 이후여서 상대적으로 수월하고 빠르게 구현할 수 있었다.

기회2

벌써 1년

WebRTC라는 한 차례 폭풍이 지난 뒤 여러가지 이벤트가 있었다.
우선, 8월 18일은 내가 개발자라는 타이틀로 현재의 직장에서 커리어를 시작한 지 1년이 되는 날이었다. 1년이라는 짧지 않은 시간을 보내며 습관이나 사고가 제법 개발자스럽게 변했다는 점에서 개인적으로는 기뻤으나, ‘기술적으로 역량이 늘었는가?’ 혹은 ‘1인분을 하는 개발자가 되었는가?’라는 의문이 들었다. 대표님은 감사하게도 “수영님은 좋은 개발자가 될 수 있는 자질을 갖추고 있다”, “평균 이상의 성장속도를 보여주고 있다” 등의 말씀을 해주셨지만, 그와는 별개로 나의 현위치를 스스로 확신할 수 없다는 점이 불안했다.

새로운 동료

그런 와중에 1년 가까운 시간 동안 리액트 네이티브 개발을 맡아주셨던 시니어 개발자 분이 퇴사를 하셨고, 새롭게 리액트 네이티브를 맡아주실 주니어 개발자 분이 합류하셨다. 단순히 경력 기간만 보면 나와 큰 차이가 없었지만, 뒤늦게 WebRTC 프로젝트를 인수인계 받았음에도 기술에 대한 이해가 빠르고, 먼저 접했던 나보다도 이해의 깊이가 깊었다. 게다가 개발자로서 존경할만한 생활습관을 지닌 분이어서 배울 점이 많겠다는 생각이 들었다.
그리고, 얼마 지나지 않아 추석연휴가 지난 뒤 신입 프론트엔드 개발자가 또 한 분 합류하셨는데, 놀랍게도 위코드 후배였다. 꼭 한 번 해보고 싶었던 “몇 기냐?”를 하고 싶었지만, 초면이기도 하고 존댓말로 조심스럽게 여쭤보았다. 약 1년 정도 차이가 날 것 같은 기수였고, 나 혼자 내적 친밀감을 키웠다. 위코드를 마치고 바로 왔기에 당연히 모든 것이 낯설고 모르는 것 투성이일 것이다. 나 역시 그랬다. 그렇기에 질문에 최대한 친절하게 답하고자 노력하고 있다.

사이드 프로젝트

v4.0 개발을 앞두고 있던 시점에 대표님께서 사이드 프로젝트를 제안하셨다. 실시간 성형상담 서비스를 만들어보자는 것이었는데, 이미 WebRTC를 한 번 경험해봤기에 일주일이면 가능하지 않겠냐고 하셨다.
실시간 영상통화 기능 하나만 주력으로 하는 MVP이며, 보일러플레이트를 비롯한 기술스택은 기존의 것과 동일하게 한다면 가능하겠다…라고 생각했다. 그리고, 3주가 더 걸렸다.
확실히 한 번 다뤄봤던 기술이라 구현은 빨랐는데, 한 번 다뤄봤기 때문에 기존에 구현했던 방식에 문제가 있다는 사실 또한 여실하게 눈에 띄었던 것이다. 문제가 있다는 것을 알면서도 그대로 구현하는 것은 있을 수 없는 일이기에 보다 나은 프로세스와 구조로 바꾸며 진행하다 보니 기간의 연장은 불가피한 일이었다. 결과적으로는 이전에 구현했던 방식보다 구조적으로 확연하게 단순해지며 사용성이 크게 증대되었다.
현재는 앱스토어와 구글플레이에 코디톡이라는 이름으로 출시되었다.

팀장? 제가요?

사이드 프로젝트를 개발하던 어느 날 저녁, 사무실에 대표님과 둘이 남아 야근 중이었다. 전혀 예상하지 못한 타이밍에 내게 개발팀의 팀장을 맡아보지 않겠냐는 제안을 주셨다. 나를 포함하여 세 명뿐인 개발팀이지만, 팀은 팀인지라 부담스러운 제안이었다. 세 명 모두 주니어 개발자이며, 1년 이내의 경력 차이는 사실상 무의미하다는 것을 잘 알고 있기에 더욱 그랬다. 그도 그럴 것이 팀장이라 하면 기술적으로는 방향성을 제시하고, 기술 뿐만 아니라 비즈니스 측면까지 고려해야 하며, 무엇보다도 개인의 성장보다 팀의 성장을 우선시 해야하는 위치라고 생각하기 때문이다.
그런데 나는, 방향성을 제시할만큼 많이 알지 못하고, 비즈니스는 둘째 치고 내가 당면한 문제를 해결하기에 급급하며, 당장 1년 뒤, 2년 뒤에도 개발자로서 충분한 역량을 갖추지 못하면 어쩌나 불안한 주니어 개발자다. 이러한 이유를 대며 “저보다는 다른 분이 팀장에 걸맞지 않겠습니까”라고 말했더니, 대표님은 그렇게 생각하지 않는다며 다음과 같이 말을 이어갔다.

“CTO나 팀장은 기술적으로 가장 뛰어난 사람이 맡는 게 아니다. 서비스를 가장 깊이 이해하고 있는 사람이 맡아야 한다. 단순히 기술적인 이해가 아니라 서비스의 철학, 히스토리를 가장 잘 알고 있어야 하며, 당면한 문제를 기술적으로만 해결하려고 하면 안 된다”

현재의 나는 대표님이 말한 인재상에 부합하지 않지만, 내가 도달하고 싶은 모습과는 크게 다르지 않기에 수락했다. 자리가 사람을 만든다는 말이 내게도 적용되길 기대한다.

총평

지난 2021년은 정말 1월부터 12월까지 인상적이지 않은 달이 없었다. 늘 긍정적인 방향으로 인상적인 것은 아니었지만, ‘이 또한 지나가리라…’의 정신으로 버티고 버텼더니 2022년이 되었다. 개중에는 내일을 떠올리기 힘들 정도로 절망적인 순간도 있었지만, 이렇게 정리를 하고 보니 의외로 위기보다 기회가 많았던 것 같다.
위기의 순간에 무너지지 않고 다음 기회를 찾았던 2021년의 내가 대견하다. 다만, 무의식적으로 ‘힘들었으니 조금은 쉬어도 되겠지’라는 안일한 생각을 가졌던 것 같다. 그 동안 방치되었던 깃헙과 블로그가 그 증거다.
또한, 업무가 바쁘다는 핑계로 공부에 소홀했다. 물론 업무가 우선이긴 하지만, 업무에서 얻어진 실전경험에 추가적인 이론공부가 더해지지 않으면 진짜 내 것이 되지 않는다는 사실을 이제는 잘 알고있다. 1년여간 제법 많은 기능을 구현했음에도 무엇 하나 확실하고 쉽게 설명할 수 없는 내 상황을 보니 그것은 명제다.
아쉬움이 컸던 2021년의 내 모습을 반면교사 삼아 보다 성숙한 2022년을 보낼 수 있기를 기대해본다.