2022년 하반기를 보내며

하반기 회고라기에는 상반기 회고를 너무 늦게 작성하는 바람에 뭔가 꼬인 느낌이 있다. 내용 중 하반기에 한 작업이 많았고(8~9월 작업이니) 그 이후로는 대부분 서스테이닝 작업을 진행했기에 기록하기 애매한 내용들이 많다. 이 유지보수성 작업들은 뭔가 하는건 많은데 포트폴리오로 남길만한 내용이(뭔가 있어보이는 내용이) 없는 편이다. 그런데도 오히려 서비스 운영을 위한 근본적인 실력 자체는 늘어난다는게 참 아이러니하다.
어쨌든 사내 평가 시스템에 내용을 작성하며 정리한 김에 블로그에도 정리해두려고 한다.

1. 클라이언트 로그 라이브러리 개발

이곳의 서비스들은 클라이언트 로그(통계 정보) 수집을 위해 aws kinesis를, 사용자의 인증 정보를 획득하기 위해 cognito를 사용하고 있다. 문제는 이 클라이언트 로그라는 것이 주요 로직이 아닐뿐더러, 항상 개발 기간 최후반부에 들어서야 구체적으로 나오기 때문에 신경쓸 겨를이 없다는 것이다. 개인적으로는 이 로그가 프론트엔드 개발에 있어 가장 중요한 업무 중 하나라고 생각하고 있어 찬밥 신세라는게 안타까울 뿐이다. 아무튼 개발 기간이 얼마 남지 않은 상황에서 기존 방식과 유사하게 구현해야 하는 부분이 많다보니 단순하게 코드 copy & paste로 처리하게 된다. 작동 자체에 문제는 없지만, 당연하게도 프로젝트의 필요에 따라 코드 변형이 일어나 관리에 어려움이 있었고 aws-sdk v2를 사용하다 보니 성능 측면에서 아주 큰 문제가 있었다(이 내용은 상반기 회고 글에 적었던 것 같으니 제외하도록 한다)

저 부분 하나만으로 번들 용량이 2MB이상 차이난다

aws-sdk v3로 올리면서 cognito 인증 풀 사용량 초과 장애를 내기도 했고, 코드가 파편화된 문제가 대두되어 이를 해결하기 위해 팀 내 라이브러리로 분리하여 관리하려고 한다. 회사의 C 시리즈들이 바뀌면서 개발 방식도 또 바뀌게 되었는데, design doc을 만들어서 논의하고 개발해야 했다.
라이브러리를 만들게 된 배경과 앞으로 만들게 될 내용을 문서로 작성하고 논의하다보니 구현되어 있는 클라이언트 로그 전송과 관련해 웹과 앱의 차이점도 발견했다. 검색 결과 리스트의 노출 로그 같은 경우, 사용자가 화면을 쭉 내리게 되면 화면에 노출된 컨텐츠를 전송해야 한다. 이 때 전송하는 로그의 수가 굉장히 많으니 곧바로 로그를 전송하지 않고 전송할 데이터(숙소의 이름이나 별점 등)를 모아두고 다른 동작(클릭이나 페이지 이탈)을 할 때 묶어 전송하는 식으로 개발되어 있었다.

이런 화면에서 컨텐츠가 노출될 때마다 로그를 전송하면 전송 횟수가 굉장히 많아진다.

문제가 되는 것은 앱이 비활성화되거나 강제 종료 될 때 정상적으로 전송이 되느냐는 것이다. 앱이나 웹 모두 pause될 때 전송할 수는 있지만 유실 가능성이 높아보인다. 특히 웹에서는 beforeunload 이벤트가 제한적이다 보니 로그가 유실되지 않게 라이브러리 도메인을 따서 사용하는 일종의 shared local storage를 사용해 모아두었다가 전송하자는 의견도 있었는데, 많이 사용하는 방식이 아니다보니 탐탁치가 않다. 현재로써는 개발에 본격적으로 들어가지 못하고 이런 내용들을 확인하고 있다.

2. 서스테이닝 작업들

상반기 회고에 적었던 새로 오픈한 국내숙소 상세 페이지의 서스테이닝 작업들이 있었다.

1. 시인성 개선 프로젝트

단순하게 보자면 스타일시트 변경 작업이다. 문구 수정 같은 간단한 작업들도 있었지만 기능 측면에서의 디자인 수정이 꽤 있었다. 프론트엔드 작업뿐 아니라 백엔드쪽 데이터 자체도 변경할 필요가 있어 한달 이상의 작업 기간이 소요되었다. 내가 느끼기에 프론트엔드에서의 가장 큰 차이는 클릭 가능한 영역의 확대다. 대부분의 개발자들이 신경쓰지 않는 부분이기도 한데, 개인적으로도 서비스들을 사용하다 보면 정말 더럽게 안눌리는 버튼들이 많다. 이런 부분들은 DOM을 추가하여 패딩을 크게 붙이면 되지만 DOM이 깊어지기도 하고 디자인 시안과 다르게 신경써야 하는 부분들이 생기니 귀찮아 대충 넘어가게 된다. 그렇지만 어차피 나중에 수정해달라고 하니 개발자 본인이 처음부터 잘 잡아두거나 의견을 제시하는 편이 낫겠다는 생각이 든다.

2. iOS SwipeBack 기능 지원

큰 기능 추가로 iOS에서 SwipeBack을 지원하는 작업도 있었다. iOS에서는(요즘은 android도) 창을 닫을 때 모서리에서 반대쪽 모서리로 스와이프하는 방식이 있는데, 이게 꽤나 문제가 된다. iOS에서는 보여지는 창을 닫는 도중 스택에 쌓인 하단의 창이 보여지게 되므로(안드로이드에서도 이런 구현이 되는 액티비티가 있지만 특별한 기능이니 논외로) 동작이 아주 어색하게 보이는 경우가 있기 때문이다. 그 중 가장 어색한 부분은 hashbang을 이용해 구현한 모달/팝업이 있는 경우였다. iOS의 스와이프백도 결국 동작 자체는 BF캐시를 기반으로 한 back 버튼 동작이기 때문에 현재 닫는 창은 팝업이 떠 있는 상태이고, 아래에 보여지는 창은 팝업이 닫혀있는 상태이다.

iOS에서 스와이프백을 하면 이런 느낌으로 보여 막아두었었다

이 문제를 해결하기 위해 기본적으로는 SwipeBack을 허용하되, 사용자의 의사를 묻는 역할을 하는(기술적인 문제도 있고) 팝업/모달 등이 떠 있을땐 스와이프백을 하지 못하도록 작업했다. 이미 앱의 인터페이스 콜 용도로 사용되고 있는 팀 내 라이브러리도 있고 실제 구현은 앱에서 해야 하니 구현에 어려운 점은 없었지만 문제를 이해하고 정책을 정해야 하는 과정들이 꽤 재미있던 작업이었다.

3. 코드 리팩토링

리팩토링 역시 계속 진행했다. 처음부터 신경써가며 만들기는 했지만 개발 도중 변경된 정책들이 있었기에 난잡해진 코드가 많았다. 이런 것들을 기능에 따라 커스텀 훅으로 분리하고, 조금 이상하다 싶은 부분은 전부 주석을 달아놓는 등 리팩토링을 주기적으로 진행했다. 리팩토링을 하다보니 API측에서 신경써야 할 것도 새삼스레 보였는데, 응답에 플래그가 필요하다면 '부정적인 값'을 키로 잡아야 한다는 것이다.
"isNormal" 키가 API의 응답에 있는 상태이고, 특정 버전부터 이 값을 제거해야 한다고 가정하자. 이 때 API가 먼저 배포된다면 { isNormal: undefined } 로 응답되게 될 것이고, 프론트엔드는 이 값을 부정적인 값, 그러니까 { isNormal: false }로 판단하고 동작하게 된다. 처음부터 응답의 키가 "isNotNormal" 이었다면 API가 먼저 배포되어 { isNotNormal: undefined }로 응답되더라도 프론트엔드는 정상적으로 동작하게 된다. 여기서는 단순히 배포 타이밍에 대해서만 이야기했지만 다양한 예외상황을 대처하기 위해서 '부정적인 값'을 키로 잡는게 훨씬 나아 보였다.

3. 객실 상세 개발

이건 사실 상반기 작업이 아닌데 개발 기간이 이어지다 보니 상반기 회고에 이미 썼다. 더 추가할 내용은 Google Structured Data이다. JSON-LD 데이터 스니펫인데 이 값을 추가하면 구글 검색에 아래와 같이 '정리된' 데이터가 노출되게 된다.

사용자에게 필요한 데이터를 더 잘 보여주니 진입 확률을 높여주기도 하지만, 서치 콘솔 내에서 이 값에 오류가 있었을 때와 해결되었을 때 검색 노출 순위 차이를 보면 구글 검색 내에서도 순위가 오르는 것으로 보인다. 검색 순위 점수 산정에 대한 상세한 내용들은 공개하지 않아 정확하지는 않지만 점수에 영향을 주는 것은 확실하다. 다만 Vue 환경의 경우 SSR과 엮여 이런 값을 작성하기가 골치아픈 편이니 아무래도 고민할 필요가 있을 것 같다.
컴포넌트 기능 변경으로 고장난 스토리북을 수정하면서도 꽤나 많은 생각이 들었다. 이전에 적었듯 서비스 특성상 컴포넌트를 반복하는 경우가 흔치 않기 때문에 스토리북도 거의 쓰이지 않는다. 특히 서비스 릴리즈 초기에는 변경이 잦아 스토리북에서 오류가 발생해도 우선 넘어가야 하는 경우가 있었다. 매번 신경쓰면 좋겠지만 현실적으로 불가능하다고 생각된다. 무엇보다 스토리북 이거 실행을 거의 안 한다. 다른 개발자가 참여할때는 좀 쓸까 싶다가도 경험 많은 사람들은 대충 모양만 봐도 견적 나와서 실행을 안 한다...

마치며

2022년도 지나갔다. 너무 오랜 기간동안 재택 근무를 하다보니 뭐 하나 제대로 한게 없는 것 같은 기분이 든다. 자기 계발이 되었냐 하면 그것도 아니고, 개인 프로젝트를 열심히 한 것도 아니고. 나는 급하지 않으면 한없이 늘어지는 스타일인 것 같다. 그나마 최근에는 다이어트한다고 신경쓰는게 있으니 조금 활기가 생겼다. 11월 중순부터 시작해서 6키로정도 빠졌는데 예전에 비하면 엄청나게 더딘 수준이다. 예전엔 진짜 먹지도 않아서 그랬던 것 같긴 한데... 아무튼 2023년엔 뭔가 심기일전할 필요가 있다. 이러다가 또 늘어져서 아무것도 안할수도 있지만.
앞서 적었듯 하반기에는 서스테이닝 작업이 많아 포트폴리오 측면에서는 소득이 별로 없었다. 하지만 (자주 하는 이야기이지만) 연차가 찰수록 서스테이닝 작업이 아주 중요하다는 것이 느껴진다. 새로운걸 '만드는' 기술은 대학교에서 충분히 배운 것이고 사회로 나온 이후로는 회사의 서비스를 '운영하는' 기술을 배워나가는 것이 아닐까. 뭐 어찌됐건 연봉 좀 올려줬으면 좋겠다. 요새 업계에 쌀쌀한 바람이 불어오고 있긴 하지만 대충 주위를 살펴보니 나... 이 연봉이 아닌 것 같은데...?