어느새 11월이 되어 입사 후 6개월을 꽉 채우고 7개월차에 접어드는 시기가 되었다. 반년 그리고 2분기라는 의미있는 시간이 지나간 만큼 지난 일들을 회고해보려 한다.
물류 시스템 개발
신입에겐 감사한 그린필드
새로운 물류 시스템을 개발하게 되었다. 내가 합류했을 땐 기본적인 레이아웃과 로그인 페이지 정도만 개발된 완전한 그린필드 프로젝트였기 때문에 감사하게도 레거시 코드를 볼 일은 없었다. 부트캠프를 이수하고 프로젝트를 2개 만든 후 입사하였기 때문에, 기본적인 조회 페이지를 만드는건 어렵지 않아 첫 한두달 정도는 마치 공장에서 찍어내듯 페이지를 찍어내었다. 당연히(?) 그 과정에서 잘 못했던 부분도 있는데, 이와 관련해서 반성문를 업로드 하였다.
테스트 코드 도입
면접 때 테스트 코드를 작성하냐 여쭤봤을 때, '당연히 작성한다'라는 답변을 들었기에 당연히 테스트 코드가 있을 줄 알았는데 없었다. (이제 막 만든 프로젝트였기 때문..) 어쨌든 당시 면접을 보신 팀장님은 테스트 코드를 당연히 작성한다고 말씀하실 정도로 테스트 코드에 우호적이셨기 때문에, 적극적으로 테스트 코드를 도입하였다.
제일 처음엔 jest와 testing library를 이용하여 페이지 단위 통합테스트를 작성하였는데 개발 경험이 좋지 않았다. userEvent와 expect에 await을 붙이냐 마냐에 따라 테스트 결과가 달라졌는데 이유를 파악하기 매우 어려웠다. 테스트에 실패할 때 터미널에 출력된 디버깅 로그만으로는 원인을 찾기가 어려웠다. 테스트 코드를 잘 작성하지 못한 내 탓도 있겠지만, 변경사항이 생길 때마다 테스트가 깨졌는데, CI/CD에 테스트 코드 검증이 빠지니 깨진 테스트를 유지보수하는 개발자가 없어 테스트 코드가 점점 방치되고 있었다. 이러한 이유로 나중에는 간단한 조회 페이지에는 테스트 코드를 작성하지 않았으면 좋겠다고 테스트 코드를 도입한 내가 설득해야 했다.
물론 테스트 코드가 아주 유용하게 사용된 경우도 있었다. 자세한 내용은 다음 파트에 이야기하겠다. 일단 cypress를 사용하니 jest를 사용할 때보단 테스트 코드 작성하기가 훨씬 수월했다. 지금 진행하는 프로젝트에는 cypress-cucumber-preprocessor를 활용하여 BDD를 도입할 예정인데, 아직 진행된게 없으므로 후기는 TO BE CONTINUE.
저울 그리고 프린터와의 사투
물류 시스템에서 주로 개발한 부분은 '개별 포장' 서비스였는데, 저울을 통해 포장 무게를 입력받고 프린터로 송장을 출력하는 기능이 필요했다. 처음 이 일을 맡게 되었을 때 조금 당황스러웠다. 취직 전까지만 해도 키보드, 마우스 외의 입출력장치를 다루게 될 거란 상상을 하지 못했기 때문이다.
저울은 Web Serial API를 활용해 브라우저와 연결시켰고 프린터는 제조사인 Zebra에서 제공하는 모듈을 활용하였다. Serial API를 리액트 커스텀 훅으로 감싸는 과정에서, 리액트 컴포넌트의 라이프사이클과 Serial Port의 라이프사이클을 매치시키는 것이 너무 어려웠었다. 또한 상태와 effect를 잘 활용하지 못해 고생했던 기억이 난다. 이 때 프론트엔드 팀원들과 react beta docs의 escape hatches 위주로 스터디하였던 것이 도움이 되었다.
테스트 코드는 개별 포장을 개발할 때 빛을 발했다. 개별 포장 서비스를 한창 개발할 때 쯤 사무실에 코로나가 퍼졌다. 어쩔 수 없이 재택근무를 해야 했는데 개별포장 페이지를 직접 테스트 하려면 사무실에 있는 프린터와 저울이 필요했다. 이 때 미리 만들어둔, 저울과 프린터를 모킹해놓은 테스트 코드가 매우 유용했다. 재택근무가 아니어도 '포장 무게가 너무 클 때', '예상 무게가 측정 무게의 오차가 클 때' 등의 예외 케이스에 대한 UI를 개발할 때 유용하게 사용하였다.
역시나 어려운 건 협업
워터폴과 애자일 사이에서
사실 제일 어려웠던건 개발이 아닌 협업 프로세스였다. 우리 회사는 원래 전면 워터폴 방식으로 일을 했으나 애자일 방식으로 변하는 과도기에 있는 상태였다. 팀원 중 누군가는 애자일을 추구했고 누군가는 워터폴을 추구하였는데 나는 뭐가 애자일이고 뭐가 워터폴인지 구분을 못해 갈팡질팡했다. 뒤늦게야 워터폴 조직과 애자일 조직의 차이를 알게 되었다.
이미지 출저: 기획자 데이먼
우리 팀은 사실 워터폴 조직이었다. 그런데 나는 애자일 방식으로 일하려다보니, 상처를 받기도 하였고 또 내가 상처를 줬을지도 모른다. 아마 경력이 좀 쌓인 상태에서 일을 했다면 좀 더 유연하게 대처할 수 있지 않았을까? 하는 생각이 든다.
갈등 상황을 몇번 겪다보니 퇴근 후에도, 주말에도 계속 우울한 기분이 들었다. 이대로 계속 일할 수는 없다는 생각이 들었다. 팀이 일하는 방식을 바꾸는건 내 포지션에선 역부족, 사람을 바꾸는 건 더더욱 불가능, 내가 팀을 옮기는게 최선이라는 판단이 들었다. 그래서 CTO님께 원온원을 신청하여 내 생각과 상황을 전달하기로 결심하였다. 매우 긴장되는 순간이었다.
우리 팀에 정말 프론트엔드 개발자들이 필요한가요?
CTO님께 말씀드리려고 곰곰히 생각해보니, 사실 사람만의 문제는 아니었다.
몇 가지 이유로 개발 본부의 모든 프론트엔드 개발자가 물류시스템 개발팀에 몰려있었다. 그러다보니 백엔드에서 할 일을 프론트엔드에서 하기도 했고, 기획자와 UX 디테일에 대해 논의하다가 시간과 감정을 소모하기도 했다. 그 과정에서 중요하지 않은 일에 많은 시간을 쓴다는 현타가 오기도 했었다. 물론 사용자 경험도 중요하지만, 그보다는 자동화 시스템을 빨리 출시하여 물류센터 직원의 고충을 덜어내는 것이 중요했기 때문이다. 사용자 경험이 상대적으로 덜 중요한 제품에 모든 프론트엔드 개발자가 배치된 것은 회사 차원에서도 좋지 않은 일이라는 생각이 들었다.
이제 나도 풀스택 개발자?!
사실 원래부터 백엔드를 해보고 싶다는 생각이 있었다. 다만 적어도 1, 2년후가 될거라 생각했는데, 이왕 팀을 옮기는거 포지션도 바꿔보자!라는 생각이 들었다.
회사 입장에선 프론트엔드로 채용한 신입을 백엔드로 옮겨주는게 쉽지 않을 것 같아 내 생각을 정리한 노트도 따로 준비했다. 떨리는 마음으로 CTO님과의 원온원을 요청했는데, 준비한 노트가 무색하게 너무나 쉽게 허락해주셨다.
이렇게 입사 6개월만에, 나는 백엔드 개발자로 전직(?)하게 되었다. '백엔드 개발자'라는 말을 붙이기 민망하게 아직 제대로 된 개발을 한게 없지만... 일단 좋은 점 하나는 컴포트 존에서 확실히 벗어난 느낌이 드는 것이다.
백엔드 업무를 시작한 이후에는 그래도 같은 웹개발이니까 비슷하지 않을까?라는 생각이 아주 안일했다는 사실을 깨닫고 있다. 너무 모르는게 많고, 내가 이렇게 바보라는 사실을 들킬까봐 불안하다. 하지만 이렇게 불안한 기분이 들 때마다 확실히 성장한단걸 알기에 일단은 즐기려고 노력하고 있다.
마무리
사실 6개월이나 지난 것 치고는 너무 한게 없다고 생각을 했는데 정리해보니 꽤 많은 일이 일어난 것 같다. 햇병아리 신입에도 불구하고 하고 싶은 말, 하고 싶은 일을 자유롭게 하게 해준 동료와 리더 분들 덕이라는 생각이 든다. 기억에 강하게 남은 일들을 쓰다보니 힘들고 어려웠던 것 위주로 쓰게 되었는데, 사실 좋은 분들을 만나 참 감사하다는 생각을 하며 매일 매일 퇴근한다.
쌩신입이 자유롭게 활개(?)를 치도록 허락해주신 프론트엔드 팀장님, 아무것도 모르는 내가 백엔드에 연착륙 할수 있도록 하나 하나 떠먹여주는 백엔드 팀장님, 내 이야기를 잘 들어주시고 좋은 조언도 많이 해주시는 CTO님, 한 분에게만 질문을 해도 어느 새 두 세명씩 모여 대답해주는 동료 개발자분들, 정말 정말 감사합니다~! (수상소감인가? ㅋㅋㅋ)
