🌞

타카

안녕하세요!

뮤팟에서 프론트엔드 개발자 및 UI/UX 디자이너 로 근무 중인 타카입니다. 23년 동안의 기업 내 경험을 돌아보며 제 활동과 생각들을 가볍게 공유하고자 합니다.

어느덧 24년이 되어버렸다. 23년에는 무엇을 보내왔을까… 뮤팟의 포쉐어드(4Shaerd)같은 무료 사이트 외모를 ㅋㅋㅋ 21년에 풀체인지 해주어 사실상 서비스가 그때부터 본격적으로 시작되었고, 나 또한 올챙이 시절이 있었기에 그 당시 개발하고 디자인했던 작품이 더 강화되어야 하는 고픔을 매우 느꼈다. 매번 3차 작업을 진행해야 한다고 외친 나인데 드디어 때를 맞이하게 된 해가 23년이었던 것 같다.

Ruby on Rails에서 → Next.js로 이사가자~

현재 뮤팟 서비스의 코드는 이전 ROR(Ruby on Rails)로 작성되어 케빈이 할아버지라 보면 되고 이후로 씨앗을 받아 탄생 하게된 Next.js 프레임워크. 이 Next.js 프레임워크의 부모는 곧 나와 이노이다.

그렇다면 왜 Next를 선택했느냐

타카 본인은 애초부터 React 라이브러리 SPA(Single Page App)를 꿈꿔왔다. 원래 순수 Vanilla JS만을 이용하고 추구하던 편인데 학습하다 보니 상태(State) 관리를 맛본 후 코드량이 훨씬 줄고 가독성, 유지보수까지 극대화 되는 체험기를 느꼈다.

하지만 순수 React만으로는 DX(Developer Experience)만 강화되는 편이 컸고 CSR(Client Side Rendering) 위주라 웹 사업을 진행하는 측면에서는 포털사이트의 스파이더 검색엔진(SEO) 봇에게 크롤링 되지 못하는 현상이 발생하여 아무리 내부에서 잘해도 간판이 세워지지 않아 고객들이 들어오지 못하는 약점이 있었다.

이것을 우리만 느꼈겠느냐? 당연히 프론트엔드 트렌드 속도는 다르다. 시기가 지나면서 React에 날개가 달린 Next.js라는 프레임워크가 등장하였고, SSR(Server Side Rendering)로 위 약점들을 모두 날릴 수 있으며, (더 있지만 중략…) 빌드 후 속도 마저 최강인 내 애정의 프레임워크가 생겼다.

자, 이 프레임워크가 생긴 입장에서 생각을 해보자.

왜 유저가 건물을 자꾸 옮겨 다녀야하는가? Rails는 유저가 페이지를 옮겨다닐 때 건물을 나가기 위해 대문을 열고 이동하고 싶은 건물로 직접 걸어가 도어락을 입력하고 대문을 여는 랜더링 과정을 거쳤다면

현재 Next의 경우에서는 한 건물 안에서 엘레베이터 층만 눌러주면 단번에 끝이다.

뭐 이 점은 정확히 말하면 Next가 아닌 React의 이야기지만 이에 더하여 검색 유입까지 강화하여 애시당초 SSR을 통한 HTML을 Hydrate 랜딩해주기 때문에 위에서 말했듯 SEO 봇 입장 크롤링이 되게 쉬워진다. 이 뿐이랴... Rails는 흔하지 않은 코드라 모두에게 러닝커브가 필수적으로 발생하여 국내에서 단독 인원으로 나갈 사업이 아니면 좋지가 않았다. 우리는 회사의 확장성까지 생각해야한다. 요즘 개발자가 무엇으로 코드 작성을 하느냐, 인력을 데려와 호환시킬 수 있느냐, 확장시킬 수 있느냐 이것 또한 강점이였다.

내 업무 만족도까지 상승했다. Rails때는 고작 바닐라(Vanilla)적인 순수 HTML(.erb), CSS, JS와 MVC 패턴 중 V(View)와 C(Controller)만 조작하는 수준밖에 없었다. 정적인 하드코딩 위주인 느낌 또한 강했다. (동적인 코드들은 이미 만들어져있기도 했고, 디자인만 변형하는 수준이라... 사업 속도는 맞춰야하고…)

디자이너 타카, 너만 좋아했지
개발자 타카, 나는 싫었다.
Plain Text
복사

비록 나는 웹앱 UI/UX 디자인 전문성도 갖춰져있지만 디자이너 타카로써는 충족이 될지라도 프론트엔드 개발자 타카로써는 씅에 차지않았다.

그러한 개발자 타카는 곧이어 프론트 환경, 즉 본인 입맛에 맞게끔 Next를 최대한 커스텀하여 디자인 패턴과 디렉토리 아키텍처까지 구성하였고 다른 패키지 마저도 본인 구성에 맞게 연구하고 실험하는 과정을 모두 거쳐 설계된 이 건물에 대한 애착이 매우 큰 상황이다.

마이그레이션 하는 김에 디자인 리뉴얼까지~

자, 여기서 디자이너 타카는 다시한번 리뉴얼을 시작한다. (21년의 감각이 아닌 23년의 감각으로!) 뮤팟의 프론트 코드 베이스가 바뀌어서 어차피 새로 만들어야 하는 판인데 이전에 후진 디자인을 똑같이 개발하라고?.. No.. No 여기서의 후지다는 단지 예술성을 말하는 것이 아니다. UX(User Experience)입장에서 플로우 복잡도가 컸고, 컴플레인, 유저 피드백까지 이미 다 경험해온 나는 코드 판을 바꾸는 김에 디자인 판(유저 경험)도 제대로 변경하기 시작했다.

로그인, 회원가입 페이지 부터 시작하자!

이전의 유저는 회원가입시 너무 많은 단계를 거치는 느낌을 제공하는 UX였으며, 본인 역할을 선택하는 단계에서 혼란되는 문제점을 개선하여 관련한 CS 문의량을 감소시켰다.

블로거 A쁘리님께서 이런 칭찬을 해주셨다고 블루가 전달해주셨다. 나는 고객에게 칭찬을 전달받으면 뿌듯해하는 입장이다. 직원보단 고객에 직면하는게 내 작품의 성향인지라…ㅋㅋㅋ 그리고 이 쪽은 보통 유저들이 로그인, 회원가입하기에 급급할텐데 이런 면을 캐치하는 유저가 있다는게 좀 신기한 것도 있었다.

드디어 우리의 핵심인 음원사이트 개편!

이 곳은 디자인보다, 개발이 무척 애를 먹었다. 스포티파이, 멜론 오디오 플레이어처럼 (웹앱)을 자체적으로 만드는 수준이기 때문이다. 이전에는 페이지 곳곳에 비효율적으로 코드들이 따로 놀고있었고… 페이지가 전환되면 음원 재생이 유지되지 않았다. (즉 플레이어인척 하는 플레이어가 아닌 셈) 나중에 웹앱을 생각할 것이면 미리 작업해야겠지요~?

음원 파형이 참 골치가 아팠는데 React 환경에 맞게 기존 Peak.js 패키지가 아닌 Waveform.js 패키지를 채택하였다. Waveform.js로 파형의 Real DOM을 그려주는 형식이라 곡이 중복이 되거나, 파형이 중복이 될시에 문제 또한 발생했다… (이보다 훨씬 더 많다…) Virtual DOM을 조작하는 것을 좋아하는 나로써 최대한 Docs를 파헤치고 Atom들을 활용하여 모든 것이 호환되고, 같은 곡이 존재하던, 파형이 중복이 되던, 진도도 맞지 않던…

그냥 어떠한 확장이 되어도 무적이 되게끔 연구하여 완벽한 결과를 이루어내었다. 이로써 Rails의 경우 사용자에게 노출되는 홈페이지의 모든 로드가 완료되면 5.17s 의 속도가 나왔지만 Next의 경우 1.48s의 속도로 보다 빠른 결과가 나와버렸지 뭡니까~~ 유저들이 오디오가 답답하고 느린 속도라고 자꾸 문의가 꾸준히 오고있는 상황이었는데 바로 말끔히 해결해버리고 잠잠해졌지요. (아직 연구중이라 완벽하지도 않은 코드를 CS 막기 위하여 빨리 배포하자고 외쳤던 케빈…)

이제 글로벌 진출을 진행해볼까요?

솔직히 국내 진출도 미흡한데 이 소규모 인력에 글로벌..? 너무 현실과 맞지 않은 로망적인 상상이라고 생각한 나긴 하다. 뭐 그래도 어차피 처음에 말했듯 3차 업뎃에 대한 리뉴얼이 필요한 시점이기에 마침 Next 건물도 지어졌겠다~ 추가 방향을 잡는 것도 나쁘진 않아서 힘내고 진행해 보았다.

무채색의 다크 테마가 요청으로 들어와 작업을 진행하였다. 기존 기획과 디자인 안이 완벽하지 않고 모호한 면이 있어 (관련 직무자가 없어서 어쩔 수 없다고도 생각한다.) 역시나 작업자인 내가 투입될 수 밖에 없었다. 디자인도 원하는 뉘앙스에 맞게 리뉴얼 하느라 힘좀 썼다. 지니 왈.. 공기업에서 테마를 4억주고 사고싶다고ㅎ… 그치만 에이전시나 SI기업이 될 수는 없다. ㅋㅋㅋ

글로벌 페이지의 테마는 일본과 미국만 확장되었고 추후 한국도 이에 맞게 매칭할 예정이다. 한국은 아직 소스가 너무 많아 개발이 더 필요한 상황이다.

탈출하자 유지보수도 안하는 페이스북 Recoil

개인적으로 상태를 조작하는데 다른 Flux 패턴의 Redux나 Zustand보다 Atomic 패턴을 좋아하는 나로써 순수 React때 부터 Recoil을 제안하고 사용했던 나다. 무엇보다 페이스북이 창조하였고, 그 당시 소소한 인기도 있는 편이었는데… 아니 이 자식은 발전할 기미가 안보이고 Git의 Discussions까지 확인해보니.. 무슨 관련 업자가 퇴사했다는 둥… 그리하여 같은 패턴의 일본의 유령같은 Jotai를 채택하였다. 번들 용량이 Recoil보다 무려 1/6로 3KB이고, 타입스크립트 지향적이며, 무엇보다 데브툴이 너무 마음에 들었다. (Recoil은 이또한 없었고, 커스텀 업체가 있었는데 걔네도 너무 무겁고 망ㅋㅋㅋ) Storage 활용 및 다양한 유틸 및 레시피들이 존재하여 너무 마음에 들어 클라이언트의 Recoil을 모두 Jotai 코드로 변환하였다.

국제화를 위하여 잡아오신 그 쥐…

우리는 국제화(I18n)가 필요해서 정적 YML로 NEXT_DATA 용량을 겁나게 차지하고 있던 상황이며 국가가 자꾸 확장됨에 따라 개발자가 언어를 수작업으로 일일이 넣기에 매우매우 비효율적이었다. 그래서 이 엄청난 공수를 줄이기 위한 쥐를 잡아오셨는데

이노와 케빈이 참으로 잘 잡아와 주셨다. (애초에 잡았으면 모두가 좋았을 텐데!) Tolgee라는 쥐 자식인데ㅋㅋㅋ 서버에 안정적인 장착을 해주셨고, 클라이언트에 약간의 샘플을 이노가 초기작업 해주셨다. 단순 톨지를 도입하여 텍스트를 치환만 하면 된다는 상상은 그만…

우리의 회사는 작지만, 코드는 어느 큰기업 뺨치는 느낌이다. 각종 SSR로 이루어지는 Atom 그리고 UseCase, View, ViewModel 등에서 사용되는데 Next만의 Hydrate 에러가 발생하는 현상 또한 있었고, 이 쥐의 Key값을 우리만의 컨벤션으로 구상하고 컴포넌트로 조작하는 공수도 필요했다.

이 뿐이랴! 문자열 내부에 HTML 태그가 들어가는 것과 Tolgee만의 폭없는 비접합자 (&zwnj) 이 자식들 때문에 프론트 입장에서 커스텀하는데 애를 먹을 때가 많았다. (Docs에도 없어서 node module 뜯어봄…) 반환하는 타입도 React.element냐 String이냐에 따른 경우가 필요할 때가 많았고… 많은 생각과 연구 끝에 이 또한 완벽한 정착을 시행했다. 이럴때 오는 쾌감이 참 좋긴하다ㅎㅎ (등산 후 막걸리 느낌인가~)

마케팅 및 프로모션 활성화 지원

주로 관리자의 요청, 관련 프로젝트의 시행으로 필요한 상황에 지원을 하였다. 기획 이후 만들어내야 하는 것이 디자인과 프론트기 때문에!

- 바우처 확장 (비대면, 클라우드, 데이터)
- 유토이미지 프로모션
- 5주년 할인 프로모션
- 코바 전시회 관련물 제작
- 링크드인 이미지 제작
- 구독해지 내용 업데이트
- 크리에이터 고객사례 추가
- 콜라보 한 크리에이터 프로모션 쿠폰 플로우 및 특정 노출
- 유저 트래킹 분석 도구 관련 세팅 (NA, GA, GTM 등)
Plain Text
복사

마케팅 의도에 부합하도록 발판을 형성해 주었고, 미흡한 사항 같은 경우는 보완하는 데 공수를 들여 피드백을 주고 완성도를 높였다.

마무리

아무래도 유저의 무의식을 디자인하고 개발하는 사람이라 당연히 관련 전문성이 없거나 직접 겪어보지 않으면 노고를 몰라주는 영역같아 독고다이 느낌이 없지않아 있지만…ㅎ

나뿐이 아닌 모두의 수고스러움을 인지하고 존중하는 회사가 되었으면 하는 바램이 있다. 23년도 모두 고생 많으셨습니다. 연이어 뮤팟 사업에 참여하고, 한 배를 탄 마당에 앞으로도 힘차게 티키타카하며 화이팅 넘치게 달려봅시다~ 이상 뮤팟(티키) 나(타카) 였습니다!~