2020년 2/3 회고

작년에는 6개월 단위로 회고하는 글을 블로그에 올렸었는데 이미 올해의 2/3가 지났지만 그래도 한 번 적어보려고 한다.

회사 이야기

작년보다는 도메인지식 + 처음보는 코드가 줄어듬 때문에 상대적으로 수월했으나 그래도 기억에 남는 프로젝트들이 좀 있었다.

가장 기억에 많이 남는 일은 기존 JSP 페이지와, CRA를 eject한 프로젝트 기반의 Node+React 페이지들을 싹 다 yarn workspace + Next.js 기반의 모노리포로 옮기는 일이다. 어려운 일 (= Next.js가 안해주는데 우리한테 필요한 일)은 다른 팀원 분들이 하시고 나는 실제 컴포넌트와 로직 옮기고, 그거 빌드해서 회사 클러스터에 띄우고 모니터링 하는 부분을 주로 작업했지만 그래도 모노리포 환경이 구성되는 것을 바닥부터터 지켜보면서 node 모듈이 무엇일까?랑 빌드되고 돌아가는 과정에 대해서 좀 더 이해할 수 있는 계기가 되었다. 또한 기존에 잘 돌아가는 코드에 피처 추가하는 일을 주로 하다가 새로 보일러플레이팅을 해서 트래픽을 받아보는 경험 자체가 되게 소중했다. Next.js를 써도 될까…하고 처음에 걱정이 많았는데 다행히 서비스는 잘 돌아가고 있고, 계속해서 우리에게 필요했던 기능이 많이 추가되어서 선택을 되돌려야 하는 일은 벌어지지 않았다. 설령 이슈가 있더라도 이미 다 report 된 이슈라서 커뮤니티의 힘을 느꼈다.

여전히 Spring / JSP / jQuery로 돌아가는 프로젝트를 유지보수 할 일도 있었는데 처음에는 정말 코드 읽기가 힘들었지만 적응이 되고나니 나름 웹페이지를 만들어가는 또다른 방법을 경험하게 된 것 같아서 남는게 없지는 않았다. 물론 최근의 트렌드와는 맞지 않지 않지만 디자인 시스템이 잘 갖춰져 있고, 필요한 컴포넌트를 거의 조합만 해서 쓰는 경우가 아니라면 오히려 FE와 BE 사이에 API가 있는 것보다 객체가 바로 템플릿에 들어가는 것이 작업이 더 빠른 경우가 있다고 느꼈다 (중간에 레이어가 하나 없어지는 것이니 당연히 코드가 간단해지는 대신에 반대로 결합도가 강해지고 재사용이 힘들어진다). HEY같은 서비스는 그냥 rails로 html을 그리고 plain javascript로 인터랙션을 넣는다고 쓴다고 트위터 에서 봤는데 현재의 FE 스택들이 과하게 복잡하다고 느껴지는 경우에 좋은 대안이 될 수 있다고 생각한다.

프로젝트 외적으로는 마크업을 안하고 컴포넌트랑 BFF를 만드는 개발자의 롤에 대해서 좀 고민을 많이 했다. 지금 팀처럼 BFF를 FE가 만들면 확실히 API 디자인/스펙에 관한 소통 비용은 주는 대신에 컴포넌트랑 마크업이 엮여서 브라우저에서 어떻게 돌아가는지에 대한 이해도가 떨어지게 되는 단점이 있다. 후자의 영역은 보통 데이터나 비즈니스 로직만 바꿀 때는 신경 쓸 일이 없는데 인터랙션이 좀 복잡하다던가, 페이지를 개편한다던가 할 때 예상치 못한 지점에서 이슈로 만나는 경우가 많았다. 사실 이건 내가 마크업 개발자 분들이 전달해주시는 결과물을 좀 더 꼼꼼히 보고 이해를 하면 해결되는 일이지만 일정이 급하다는 핑계로 그렇게 못하는 경우가 많았다. 현재 보편적인 프론트엔드 개발자에 비해서 마크업 지식/경험이 좀 약하고, 인프라나 로그 처리 쪽 지식/경험이 많은 상태인데 앞으로 어떤 방향으로 경험을 쌓아가야 할지 진지하게 고민을 해봐야 될 것 같다. 회사에 처음왔을 때는 딱 2년만 닥치는대로 일을 해보자 했는데 생각보다 2년이 빠르다.

QA에 대한 고민도 좀 많이 들었다. 지금은 전담 QA도 계시고, 기획자 분도 좀 꼼꼼히 이런저런 케이스를 찾아서 봐주시는 편인데 반대로 말하면 내가 처음에 개발한 코드는 프로덕션에 나갈 수 없는 상태인가..?는 고민이 조금씩 생기기 시작했다. 만약 도와주시는 분들이 없다고 가정하면 스스로 이 코드가 어떤 케이스에서 어떻게 돌아가야 하는지 쭉 리스트 업을 할 수 있어야 하고 그걸 트래킹하기 제일 좋은 형태가 자동화된 테스트인 것은 맞다. 하지만 케이스가 외부 데이터에 의존적이고 꼭 내가 기대하는 상태로 데이터가 들어오지 않는 경우도 많아서 꼭 테스트만이 답일까 하는 고민이 들었다. 오히려 문제를 빨리 파악하고 빨리 고칠 수 있는 가벼운 구조로 코드와 인프라를 구성하는 것이 ROI가 더 나올 수도 있다고 생각하는데 적절한 선을 잘 모르겠다 (한가지 확실한건 sentry가 가성비가 좋은 투자라는 것). 이 고민에 대해 답을 할 수가 있을 때 한 단계 성장했다고 느낄 것 같다.

마지막으로 노가다를 경계하려고 노력을 많이 했다. 업무로 하는 일이 너무 단순 반복 노가다이면서 성장에 도움이 되지 않는다고 느껴지는 순간들이 종종 찾아오기 마련이다. 이 때 다소 냉정하게 말하자면 내가 정말 일을 잘하는 개발자면 노가다를 자동화 할 수 있는 방법을 찾는 것이 맞는데 그건 또 버거우니까 바쁘다는 핑계로 그냥 반복적으로 일을 하게 되는 경우가 많다. 생산성을 올리지 못할 것이면 몸값이 올라가는 것도 기대를 하면 안된다.

개인 공부

올 상반기에는 리트코드를 좀 열심히 풀고자 했는데… 그러지 못한 점이 좀 아쉽다. 이게 꼭 미국 대기업을 가고 싶다기보다는 제너럴 SWE라면 기본적으로 갖춰야 할 알고리즘 지식과 그걸 구현하는 능력이 있고, 글로벌한 그 기준이 최소 리트코드 미디움을 쓱쓱 풀 정도라고 생각해서 리트코드를 풀기 시작했다. 이게 익숙한 유형이면 하루에 2~3개도 풀겠는데 (어차피 코드가 길지는 않으니) 그렇지 못할 때 슬럼프에 빠져서 길게는 한 달 동안 손을 안대는 경우가 많았다. 어렸을 때 수학문제 풀면서 답을 보기 싫어하는 것과 비슷한데…문제는 그때는 하루 종일 공부할 수가 있었고 지금은 에너지를 쪼개서 문제를 푸는 입장이라는 차이가 있다 (트위터에서 어떤 분께서 직장인의 공부는 학생과 달라서 자존심 버려야한다고 해주셨는데 정말 울림이 컸다). 그래도 그동안 깨달음이라면 유형을 정하고 그게 익숙해질 때까지 그 영역 문제를 푸는 것이 이것저것 푸는 것보다 뭔가 쌓이는 느낌이 더 든다는 것.

리트코드를 풀지 않는 시간에는 개발 책을 읽거나 관심있는 도구들 튜토리얼을 따라했었는데 사실 내가 들어봤을 법한 도구 중에서 튜토리얼 레벨에서 잘 안 돌아가는 도구가 없기 때문에 그냥 책보거나 리트코드 푸는 것이 남는 장사라고 느꼈다. 읽은 책들에 대해서는 연말에 한 번 정리를 따로 하려고 한다.

개인의 삶

좀 덜 먹고 더 움직이려고 신경을 썼더니 다행히 올해는 체중이 연초에 비해 거의 늘지도 않고 줄지도 않아서 전환의 시작인가 싶다. 차량 출퇴근 or 재택근무를 하니 평일에도 어느정도 개인적으로 쓸 수 있는 체력과 여유가 생겨서 좋았다.