_0422의 생각

2025 회고

_0422 — Fri, 2 Jan 2026 20:02:19 +0900

들어가며

연말엔 굉장히 정신이없었어서 어쩌다보니 년도를 넘겨 회고를 쓰게 됐다.
2025년은 굉장히 도전적이었고, 그만큼 얻은 것도 많고, 잃은 것도 있는 한 해였다.
그러나 돌이켜보면 그만큼 많은 경험을 했다는 뜻인것 같다.

돌아보면 이번 년도는 대부분 회사와 함께 했다.
1월 24일에 인턴 합류소식을 듣고 2월 3일부터 일하기 시작한게 지금까지 이어졌고, 정규직으로 전환되며 내년에도 함께할 수 있게 되었다.

지난 목표로 돌아보기

24년도 회고에서 세웠던 목표는 졸업준비, 앱 더 출시하기, 개발도서 읽기 였다.

졸업준비

마지막 학기도 잘 마무리했고, 졸업시험도 통과했다.
이제 정말 졸업식만을 눈앞에 두고 있다.

앱 더 출시하기

Dev-Feed를 홍보하고, 감정구슬일기라는 앱을 하나 더 내면서 도전해보고자 했다.
Dev-Feed는 광고비만 왕창 소진했고, 감정구슬일기는 아직 기능이 많이 부족한데, 너무 오랜기간 방치되었다...

개발 도서 읽고 개발 철학에 대해 고민해보기

작년에 개발자 원칙, 실용주의 프로그래머. 쏙쏙 들어오는 함수형 코딩 세권을 읽는 것이 목표였다.
실용주의 프로그래머, 쏙쏙들어오는 함수형 코딩을 읽었고, 지금 일하는데 굉장히 많은 도움이 되었다.(~~개발자 원칙은 못읽었다.~~)

추가로 이펙티브 엔지니어 라는 책을 읽었는데, 더 좋은 프로덕트를 만들기 위해서는 생산성을 높혀야한다는 점에서 굉장히 많은 공감을 할 수 있었다.

성장

돌아보면 많은 부분에서 성장했던 한해였다.

Local Jobs(당근알바) 팀

거의 10월까지 알바팀에서 일했다.
25년 이웃알바의 대부분의 신기능들에 대해 기여했다.
일하면서 당근알바의 큰 기능들을 도맡아서 사용자들에게 새로운 기능을 제공하고, 개선하는 작업들이 재미있었다.
알바팀에서는 일하면서 성장하는 방법과 일을 더 잘하는 방법, 그리고 알바 팀의 생각과 일하는 방식을 배울 수 있었다.
나만의 일하는 방식도 확립할 수 있었다.

5월에 했던 이웃알바 캠페인은 회사에서 홀로 프로젝트를 온전히 개발한 첫번째 경험이었고,
7월의 당근이네는 귀여운 프로덕트로 유저의 반응을 이끌어 냈던 정말 기억에 남을 경험이었다.

캠페인을 하면서 전반적인 하나의 프로덕트에서의 유저 경험을 고민할 수 있었고
당근이네에서 UX 시스템을 설계하며 인터페이스에 대해 고민하면서 좀더 좋은 추상화를 고민할 수 있게된 것 같다.
이외에도 크고 작은 기능들을 개발하고 실험하면서 데이터에서 인사이트를 공유해 개선해 나가는 과정이 굉장히 즐거웠다.

9월쯤 커머스팀으로 이동할때쯤에는 당근 알바의 주요 화면들 대부분에 내가 작성한 코드들이 들어가 작동한다는 점이 엄청나게 뿌듯함을 느끼게했다. 일은 많아도, 일하는게 참 재밌었다.

이전에 엘리스에서 일할 때는 단순히 좋은 코드를 작성하는 것을 목표로 했다면,
이제는 유저의 경험을 생각할 수 있게 되었고, 데이터를 바라보는 방법을 알게되었다. 그리고 왜 좋은 코드를 작성해야하는지를 몸소 느끼게 되었다.
알바팀에서 일하면서 프론트엔드 개발자에서 프로덕트 엔지니어로, 하고싶은 것이 좀더 명확해졌던 것 같다.

커머스팀

커머스 팀은 얼리스테이지의 프로덕트를 만들어야하는 팀이다.
항상 마음 한켠에 창업을 생각하고 있었기에, 그리고 추천을 받았기에 팀을 이동해서 일하게 되었다.

일하면서는 나 홀로 프로덕트 메인테이닝을 하게 되며 기존에 알바팀의 세팅들이 얼마나 많은 고민들을 통해 나온 것들인지를 새롭게 느낄 수 있었다. 폴더 구조부터 에러 로깅과 핸들링까지.. 전반적인 세팅과 최신 라이브러리로 마이그레이션을 진행하면서 기술적으로 성장할 수 있었다.

이후에는 전반적인 프로덕트에 대한 기획, 논의, 개발, 개발 후 개선까지 이어지는 전 과정에 나의 생각이 담기고 배포되는 것들을 보면서 이전보다 더 재밌게 일하고 있다. 그리고 생산성이 얼마나 중요한 것인지를 계속해서 상기하면서 반복되는 것들을 개선해 좋은 프로덕트를 만들어 나가고자 노력하고 있다.

AI

23년도 초쯤에 gpt를 코딩하는데 써보면서 농담으로 깡통이라고 놀렸었던 기억이 난다.
어느새 일하는데 자연스럽게 ai를 사용하고 있다보니, 돌아보면 새삼 참 놀라울 따름이다.
cursor의 tab 자동완성을 보고 놀랐던 기억도 나고, mcp가 뭔지 찾아보며 놀랐던 기억도 난다.
그러다 클로드가 만든 결과를 보고, 이제 내가 설자리는 없나? 고민했는데, 이 모든게 이번 년도에 경험한 것들이라니 믿기지가 않는다.
열심히 공부해서 따라잡아야지... 계속해서 배우고 적용해나가면, 더 높은 생산성을 가진 메이커로 성장할 수 있을거라고 믿는다.

작년에 36588번 tab을 눌렀다.

도전

나에게 이번 년도의 가장 큰 도전은 인터뷰였다. 약한 인터뷰때문에 빈번히 좋은 기회를 놓쳤었다.
이런 부분들 만회하기위해 주변 분들의 조언을 받아 부딪혀보자는 식으로 실제로 면접을 진행하면서 훈련했다.
과정에서 꽤나 많은 인사이트를 얻을 수 있었고, 덕분에 정규직으로도 전환할 수 있었다.
어느정도 자신감도 가질 수 있게된 것 같다.

좋은 동료 분들

이 모든 것은 주변 분들이 정말 많이 도와주셔서 이룰 수 있었다고 생각한다.
정말 중간에 좀 쉬어야하나 생각도 했었지만, 주변에 많은 분들이 도와주셨고 덕분에 버티고, 해낼 수 있었다.
이 글을 통해 다시 한 번 감사하다는 말씀을 전하고 싶다.
그리고 나 역시 그런 힘이 되는 좋은 동료가 되고 싶다.

2026년에는

2026년에는 지금까지 배운 것들을 기반으로 한발짝 더 나아가서 도전하고, 경험들을 좋은 결과로 전환해내고 싶다.

커머스

우선 당근 커머스팀의 프로덕트를 잘 키우고 싶다.
이전부터 해보고 싶었던 초기 상태의 프로덕트 개발이다.
이용자를 늘리고, 매출을 늘려 프로덕트를 잘 성장시키고싶고, 이번 년도는 정말 여기에 온 힘을 다하고 싶다.
그러기 위해서는 타팀과의 소통도 잘해야하고, AI를 통해 부족한 리소스를 채워나갈 수 있어야한다.
소통을 잘 하기 위한 방법을 고민하고, 생산성을 높이기 위한 방법들(AI)을 더욱 리서치하고, 실험해봐야한다.
이런 것들은 일을 하면서 여러가지를 시도해볼 생각이다.

또, 초기 프로덕트를 성공시키기위한 인사이트들도 학습해나가고자 한다.
현재는 린 분석을 읽고 있다. 우선 린시리즈를 다 읽는게 상반기 목표이다.

건강

진짜 정말 운동해야한다. 건강검진 결과를 보니 정말 운동이 필요하다.
헬스를 다니고는 있으나 이걸로는 부족하다.
주말에 가끔 하던 3km(~5km) 달리기를 루틴에 넣고 꼭 수행해야겠다.

취미로의 독서

이번년도는 민음사 소설을 한권도 읽지 못했다. (읽은 소설이 자몽살구클럽 한권...)
하지만, 소설이라는 글의 형태로 된 간접 경험이 주는 교훈을 놓치고 싶지 않다.
내년에는 꼭... 몇권이라도 읽으리라. 우선 설국을 샀다.

마무리

어떤 대상을 추구한다면, 그것에 가치를 부여하는 사람은 나이다. 그래서 내가 생각을 바꾸면 그 대상은 언제라도 무가치해질 수 있다. 따라서 인간이 혼자서 독립적으로 지향하는 대상은 언제라도 무의미로 사라져버릴 수 있다.

하지만, 나에 의해 유일하게 가치를 잃지 않는 것이 하나 존재한다. 그건 바로 타인이다. 타인은 나처럼 주관적 판단을 하며, 이에 따라 의미를 부여한다. 그래서 타인은 내가 의미 없다 생각하는 것들에 의미를 부여할 수 있다. 그러면 내가 추구했던 것들은 더이상 무의미의 혼돈으로 빠지지않고 의미를 유지할 수 있게 된다.

내게 모든 것이 무의미해져도, 타인만큼은 독자적으로 발휘하는 자유로 내린 가치판단으로, 그 의미를 지킨다.
그러므로 안정적인 가치란 타인에게까지 연장될 수 있는 가치, 타인이 스스로 동의할 수 있게 하는 가치다.
노인과 바다에서 노인이 보여준 의지는 청세치를 잡겠다는 의지이기도 하나, 자신을 걱정하는 소년을 생각하는 마음에서 나온 의지이기도 했다.

그래서 우리는 서로가 서로를 무의미의 혼돈속에서 지켜주는 연인, 친구, 동료가 되어야한다

24년도 회고 글을 쓰며, 노인과 바다의 소년과 같은 사람이 되겠다는 생각을 가졌었고, 그래서 당근에서 마놀린이라는 이름을 사용하게되었다.

글에는 적지 않았지만 작년과 비슷하거나 그 이상으로 중간 중간 많은 일들이 많은 1년이었다.
이전의 경험들과 생각들, 그리고 주변 사람들이 없었다면 정말 해낼 수 없었을 것이다.
주변 분들에게 감사함을 전하며 앞으로도 마놀린으로 남을 수 있어 기쁘다.

2026년은 정말 하고 싶은 것도 많고, 기대되는 해이다.
새해복 많이 받으시길!

내가 프로덕트 팀에서 일하는 방법

_0422 — Sat, 13 Sep 2025 14:18:48 +0900

당근알바 팀에서 인턴으로 일한지도 어느덧 7개월이 넘었다. 이제 정말 퇴사까지 한달 정도를 앞두고, 정리를 하나씩 해보고 있다.

이 기간은 정말 많은 것들을 배우고 느낄 수 있는 시간이었지만, 누군가 나에게 이 과정에서 가장 큰 수확이 무엇이냐 묻는다면

프로덕트 팀에서의 나만의 워크플로우를 확립한 것이라 대답할 것이다.

요즘은 특히 여러 이슈를 동시에 처리하는 과정에서 내가 잘 챙기지도 못하고 있는 것 같아 글로 쓰면서 다시 한번 되새기고자 한다.

프로덕트 팀의 특성과 요구되는 역량에 대해

어떤 팀이냐에 따라 다를 수 있겠지만 내가 느낀 프로덕트 팀의 특성을 정리해본다.

프로덕트 팀은 사용자에게 제품을 전달한다. 따라서 사용자가 잘 사용하고 좋아하는 제품을 만들어야 한다.

하지만 사용자가 어떤 것을 좋아할지는 사용자조차도 모른다!

어떤 것을 좋아하는지는 인터뷰를 통해 얻을 수도 있지만, 제품을 사용하는 과정에서 데이터로 드러나기도 한다.

따라서 메이커들을 데이터를 기록하고, 확인하고, 결정해야한다.

로그에 대해

이런 관점에서 프론트엔드 개발자는 꽤 중요한 역할을 한다.

기능을 봤을 때 어떤 것을 기록해야 더 발전시킬 수 있을 것인가는 논의를 통해 결정하기도하지만,

특수한 경우를 제외하고는 프론트엔드 개발자가 설계하거나 결정해야하는 경우가 많다.

개발에 대해

이렇게 데이터를 모으고, 변경하고 제품을 발전시키기위해서는 개발의 속도가 빨라야한다.

하지만 그것이 작업물의 퀄리티를 낮춘다는 것도, 코드의 퀄리티를 낮춘다는 것을 의미하지는 않는다.

복잡하거나 대규모 기능의 경우 QA를 진행하고 배포하게되지만, 대부분 작업의 퀄리티는 개발자가 보증할 수 있어야 한다.

대부분은 QA 맥락 공유 자체가 리소스가 되기에 이런 경우가 많다.

코드 퀄리티도 잘 챙겨야한다. 여기서 퀄리티란 어떤 복잡한 설계라기보단 읽기 쉬움에 가까운 것 같다.

자주 변경되므로, 더 읽기 쉬운 코드를 작성해야 한다. (Easy To Change!)

코드만으로 맥락을 담지 못한다면 그것은 이후에 반드시 나나 다른 사람의 실수로 이어진다.

사람은 실수를 한다.

빠르고, 정확하게, 그리고 데이터를 적절히 수집하도록.

그것이 프로덕트 팀의 기능을 구현하는 개발자에게 요구되는 역량이라 생각한다.

내가 일하는 방법

짝 프로그래밍이 효과적인 이유 중 하나는 한명은 큰 관점에서 문제를 바라보고, 한 명은 작은 코드 관점에서 문제를 바라보기 때문이다.

하지만, 시간과 자원의 문제로 일을 나눠서 하는 것은 힘들다.

나의 워크플로우는 개발하기전의 나와 개발하는 나와 이후 확인하는 내가 일종의 짝 프로그래밍을 하는 형태로 수행하는 방식이다.

개발하기 전에

1. 스펙에 대한 올바른 이해

이 스펙이 왜 필요한 것인지, 어떤 것들이 추가되는 것인지 명확하게 이해한다.

이 과정에서 유저에게 더 좋은 경험을 줄 수 있는 부분이 있다면 의견을 제시하고, 개선한다.

2. 파악하면서 누락된 것은 없는지

피그마를 읽으면서 어떤 것이 변경되는지 추가되는 것인지를 문서로 작성하고

완료되면 피그마와 비교하면서 한 번 더 확인한다.

3. 더 필요한 것들에 대해

자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. 프로그래머는, 즉 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는다. 이게 우리의 가치가 가장 빛나는 부분이다.

- 실용주의 프로그래머

피그마와 지라 이슈를 보면서 빠진 엣지케이스나 조건, 상황에 대해 생각해보고 팀원과 소통해서 스펙에 필요한 것들을 챙긴다.

4. 데이터 기록을 위한 고민

이 기능이 배포되고 사용자의 데이터를 수집한다고 했을때

얻을 수 있는 인사이트는 어떤게 있을지 고민하고, 적절하게 로그를 설계한다.

5. 개발을 위한 이정표 작성하기

이 시점의 나는 짝 프로그래밍의 네비게이터로써 미래의 드라이버인 내가 코드 작성에만 집중할 수 있도록 돕는다.

공통 기능을 만든다면 과도하게 열린 인터페이스보다는 추상화된 간소한 인터페이스를 지향한다.

코드를 들여다보며, 설계와 방향성에 대해 고민하고 이에 대한 것들을 문서로 작성한다.

6. 태스크 체크리스트 작성하기

스펙에 대한 문서를 작성완료했다면, 기능이 올바르게 동작하기위한 체크리스트들을 작성한다.

최대한 많은 케이스에 대해 대응할 수 있도록 작성한다.

자세하게 작성하면 작성할수록 체크리스트 확인이 끝났을때 자신감을 갖고 배포할 수 있게된다.

개발할 때

개발하기전에 설계나 구성에 대한 고민은 이미 완료했으므로

개발할 때는 드라이버로서 작은 관점의 문제들을 주로 해결한다.

1. 엣지케이스

단순히 타입상의 엣지케이스를 넘어 스키마나 api상 데이터에서 문제가 발생할 수 있는 경우를 생각하고 처리한다.

2. 코드의 일관성

코드의 일관성을 지킨다는 것은 단순히 팀 컨벤션을 지키는 것을 넘어, 컨벤션이 정해지지 않은 부분에 대해 자신만의 일관성을 지키는 것이다.

더불어 코드를 수정하는 경우에는 수정 파일에 대한 지역적인 일관성을 맞춰서 개발한다.

변수 이름을 넘어 한 줄의 띄어쓰기에 대해서도 코드를 작성하는 일관성을 지키기위해 노력한다.

개발을 마치고

코드 작성이 끝났고, 올바르게 동작하는 것 같다면 이제 50% 완료된 것이다.

1. 테스트와 검수

이정표를 작성할때 작성한 체크리스트를 하나씩 체크해가며 추가된 모든 기능에 대해 테스트한다.

기능에 대한 테스트를 개발자가 하지 않으면, 테스트는 유저가 하게된다.

UI에 대해서는 pixel pro와 같은 브라우저 확장 프로그램으로 figma에서 export한 이미지를 overlay해서 검수한다.

이렇게 하면 패딩, 마진 등 육안으로 체크하기 어려운 부분들을 직관적으로 확인할 수 있다.

2. 셀프리뷰

스스로 작성한 코드를 PR을 살펴보며 어떤 것들을 내가 변경했는지 확인하며

일관성이 잘 챙겨졌는지, 더 개선할 수 있는 부분들은 없는지 확인한다.

Github pull requests extension을 사용하면 IDE에서도 보기 쉽게 확인할 수 있다.

그냥 속으로 살펴보기보다는 코드에 대해 직접 말로 설명하면서 확인하면 더 놓치는 것 없이 체크할 수 있다.

또한 이 과정을 녹화를 한다면 셀프피드백과 AI피드백이 가능하게된다.

기능 개발이 끝나고

1. 회고

이상까지의 과정을 되돌아보고 더 개선할 수 있는 점이 없는지 확인한다.

셀프 피드백을 통해 워크플로우를 개선하며 성장한다.

2. 자동화

개발하면서 불편했던 것들을 자동화 할 수 있다면, 이슈로 만들고 다양한 방식으로 자동화한다.

단순한 스크립트부터 어드민 DevTool, eslint custom rule, webpack plugin등 방법에 종속되지 않고 다양한 시도를 해본다.

발전 방향에 대해

요즘은 AI가 도입되면서 개발할때의 과정, 자동화과정을 더 잘 챙겨줄 수 있게 된 것 같아서,

우선은 AI 도구를 사용해보면서 개발할때의 과정을 대체해보는 과정을 수행해보고 있다.

아직 시행 착오가 많지만, 이 부분에 대해서도 학습을 통해 발전시켜볼 것이다.

당근 인턴 회고 - 6월 회고 (18 ~ 21주차)

_0422 — Sat, 28 Jun 2025 15:12:59 +0900

내용에 문제가 있는 경우 삭제, 수정 조치 하겠습니다.

6월이 끝났다. 4주간 회고글을 못썼는데 한 번에 정리해보고자한다.

되돌아보기

기존에 목표로 했던 것들을 기반으로 작업했다.

업무별 시간을 작성하고, 각 작업별 분류를 통해 인지-개선하는 과정을 이어가고자 쭉 이어왔는데,

점점 챙겨야 하는 부분들이 생기게 되면서, 전환이 잦아졌고 로우 데이터를 작성하는 것이 어려워지게 되었다.

작성 자체가 하나의 컨텍스트 전환이 되어서 어려워진 부분도 있는 것 같다.

지금까지 데이터를 봤을때는 구현이 초기에는 60%였으나 50%대로 내려온 상태이고, 이전의 과정을 통해서 워크플로우를 확립하게 되어 이제 데이터 작성은 작성함을 통해 얻는 것보다, 그로 인해 몰입이 깨지는게 더 크다고 생각하여 이 부분은 더이상 유지하지 않게 될 것 같다.

잘한 것

워크플로우를 기반으로 작업

일전의 과정을 통해 확립한 워크플로우를 유지하면서 작업에 대한 속도와 퀄리티를 어느정도 잘 챙길 수 있었다.

설계문서를 먼저 작성하고, 이후 실제 코드를 작성하는 과거의 나와 페어 프로그래밍 하는 과정과 셀프리뷰시에 말을 하면서 하는 과정을 통해 챙겨지는 부분이 많아서 코드 퀄리티 개선에 많은 도움이 되었던 것 같다.

더불어 설계 문서 작성시에 어떤 데이터를 수집해야할지를 고민하고, 이를 배포 이후에 확인하는 과정을 통해 의사결정에 도움이 되는 데이터를 확보할 수 있게 되었다.

데이터에 대한 관심

요즘 그로스 해킹을 읽으면서 어떻게 하면 더 나은 제품을 만들 수 있을지,

어떻게 데이터를 해석해야할지 등을 학습하고 있다. 아직은 데이터 분석에 어려움이 있지만 계속해서 발전시켜나갈 것이다.

개선이 필요한 점

사이드 이펙트 고려하기

일전에 작업한 부분에서 사이드 이펙트가 발생해서 제품에 영향을 미친 케이스가 있었다.

어떤 부분이든 작성/변경한 코드가 있다면, 그것이 사이드 이펙트를 불러오지는 않을지 고민하는 과정이 필요하다.

이전까지의 워크플로우에서는 내가 작성한 코드가 잘 동작하는지에 대한 테스트케이스를 작성하고, 확인하는 과정만을 거쳤다면,

이제는 이 과정을 수행하기전에 내가 바꾼 코드로 인해 발생하는 사이드 이펙트가 있지는 않는지 확인하는 과정이 필요하다는걸 느꼈다.

셀프 코드리뷰 후에 작성한 코드가 어떤 것이고, 이것들로 인해 사이드 이펙트가 발생하지는 않는지 확인하는 과정이 더 필요하다고 느꼈다.

스펙 분석 단계에서 누락되는 케이스 제거하기

이전까지는 피그마를 읽는 방향을 신경쓰지 않고 스펙을 분석하다보니 UI 흐름에 따라 읽게 되었고, 이로 인해 놓치는 부분이 발생했다.

이런 부분을 최대한 없애기 위해 스펙 문서에 What's Changed 항목을 추가했다.

피그마의 모든 변경과 조건을 한번 정리하고, 놓친 것은 없는지 모두 확인한 후에 설계단계로 넘어가는 형태로 방향을 잡았다.

후속 대응도 똑같이 챙기기

하나의 스펙이 배포된 후 후속 대응을 챙길때 첫 개발할때보다, 워크플로우가 단순화되는 경향이 있었다.

후속 대응도 하나의 스펙으로 생각하고 첫 개발과 마찬가지의 워크플로우로 설계문서를 작성하고 진행해야한다.

마무리

이전까지의 목표들을 워크플로우로 만들어서, 목표를 간소화시켰다.

워크플로우를 준수하기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기
코드 작성시 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분씩 CSS학습
기능에 대한 논의는 모두 기록할 것/기능 논의는 가능한 경우 한번에 처리할 것

Safari의 iframe은 부모와 같은 스레드를 사용한다. (Lottie 스레드 블로킹)

_0422 — Tue, 3 Jun 2025 14:35:35 +0900

배경

스크롤 랜딩과 같은 페이지를 구성하고 있는데, 이 페이지의 섹션1은 무한 재생돠는 로띠를 갖고 있고, 섹션2는 iframe으로 임베드된 유튜브 영상을 보여주고 있는 형태다.

문제

이상하게도, 처음 페이지에 들어왔을 때 safari에서 로띠가 잠깐 버벅거리는 현상이 자꾸 발생했다.

도대체 이유가 뭘까 고민하다가 아래 섹션을 처음에 숨김처리했더니 버벅이지 않는 것을 확인했다.

Lottie 동작원리

https://github.com/airbnb/lottie-web/blob/bede03d25d232826e0c9dca1733d542d8a7754fb/player/js/animation/AnimationManager.js#L190

lottie-web/player/js/animation/AnimationManager.js at bede03d25d232826e0c9dca1733d542d8a7754fb · airbnb/lottie-web

Render After Effects animations natively on Web, Android and iOS, and React Native. http://airbnb.io/lottie/ - airbnb/lottie-web

github.com

Lottie는 requestAnimationFrame으로 부드러운 애니메이션을 제공한다.

따라서 버벅이는 것은 rAF가 제대로 실행되지 않는 것이라 할 수 있고, 스레드 블로킹이 발생했다는 가설을 세우게 됐다.

performance 탭으로 확인

크롬과 safari모두 스크립트 평가로 63 ~ 80ms동안 작업을 수행함을 볼 수 있다.

그런데 이 작업이 스레드를 블로킹하는가?는 여전히 의문이었다.

그래서 실험 환경을 구성해주었다.

실험

Child.html

10초뒤에 스레드를 블로킹하도록 스크립트를 구성했고, 이걸 vercel로 배포했다.

<!DOCTYPE html>
<html>
<head>
  <title>Child Frame</title>
</head>
<body>
  <h1>  iframe 문서</h1>
  <p>10초 뒤 무한 루프를 실행합니다.</p>

  <script>
    setTimeout(() => {
      console.log("  [iframe] 무한 루프 시작!");
      while (true) {
        // 아무 작업도 하지 않는 무한 루프
        Math.random(); // Safari에서 최적화 제거 방지용
      }
    }, 10000); // 10초 후 실행
  </script>
</body>
</html>

Parent.html

자식요소를 iframe으로 열어주는 html을 구성해주었다.

<!DOCTYPE html>
<html>
<head>
  <title>Parent Page (localhost:3000)</title>
</head>
<body>
  <h1> ‍  부모 문서</h1>
  <p>이 페이지는 1초마다 로그를 찍습니다.</p>

  <script>
    setInterval(() => {
      console.log("✅ [부모] 인터벌 실행됨", new Date().toISOString());
    }, 1000);
  </script>

  <!-- iframe은 다른 오리진의 child.html -->
  <iframe src="parent.html의 주소" style="width:600px; height:200px; border:1px solid #ccc;"></iframe>
</body>
</html>

결과

사이트가 같은 경우 (localhost)

둘다 localhost로 수행한 경우에는 크롬과 safari모두 block되었다.

<!DOCTYPE html>
<html>
<head>
  <title>Parent Page (localhost:3000)</title>
</head>
<body>
  <h1> ‍  부모 문서</h1>
  <p>이 페이지는 1초마다 로그를 찍습니다.</p>

  <script>
    setInterval(() => {
      console.log("✅ [부모] 인터벌 실행됨", new Date().toISOString());
    }, 1000);
  </script>

  <!-- iframe src를 localhost의 child.html로 변경 -->
  <iframe src="http://localhost:4000/child.html" style="width:600px; height:200px; border:1px solid #ccc;"></iframe>
</body>
</html>

사진처럼 스레드가 블록되어서 더이상 인터벌이 수행되지 않는다.

site가 다른 경우 (child 배포)

child.html을 vercel로 배포한뒤에 iframe으로 열었더니 크롬과 safari에서 다른 결과가 발생했다.

크롬은 스레드가 블록되지 않지만, safari는 블록된다.

결론

Chrome vs Safari

크롬은 정책상, iframe으로 사이트를 열 때 새로운 스레드를 할당한다.

https://www.chromium.org/developers/design-documents/site-isolation/#requirements

Site Isolation Design Document

Site Isolation Design Document This design document covers technical information about how Site Isolation is built. For a general overview of Site Isolation, see https://www.chromium.org/Home/chromium-security/site-isolation. Chrome's multi-process archite

www.chromium.org

하지만 사파리는 그렇지 않고, 같은 스레드를 사용해 js를 실행한다.

이로 인해서, embed된 유튜브 스크립트를 평가할때 크롬의 경우에는 블로킹이 발생하지 않고, safari는 블로킹이 발생하는 것이다.

해결

SPA의 특성을 활용해서 임베드 스크립트를 이전 페이지에서 미리 받아와서 평가하도록 만들어서 해결했다.

당근 인턴 회고 - 이웃알바 캠페인 회고 (16주차, 17주차)

_0422 — Tue, 3 Jun 2025 13:57:21 +0900

16주차,17주차가 끝났다.

이전 주에는 캠페인으로 바빠서 작업을 하느라 회고글을 작성하지 못했다.

어쨌든 캠페인이 라이브되었다!

https://daangn-jobs-campaign.karrotwebview.com/indvjobsBDC/opt

당근 이웃알바

도움이 필요했던 순간 알려주고 1만원 받기

daangn-jobs-campaign.karrotwebview.com

단독으로 개발한 것중 가장 많은 사람들에게 전달된 프로젝트다!!

3000명이 넘는 사람이 이벤트에 참여했고, 페이지에 들어온 사람은 100배 이상 더 많다.

느낀점

두려움

당근에서 처음, 혼자 모든 클라이언트 개발을 다 해야하는 프로젝트였기에, 나의 미숙함으로 인해 프로젝트 진행에 문제가 생기지는 않을까 두려움을 가졌었다.

그래서, 일단 나온 스펙에 대해 구현해두고 이후에 수정하는 형태로 진행을 하게 됐는데,

이것이 결과적으로 풀지 않아도 되는 문제들을 많이 풀게 만들었다.

물론 과정에서 많은 학습을 할 수 있었지만... 다 지나고 보니 비효율적으로 개발을 한 것 같아 아쉬움이 남는다.

영웅이 되려하지말고 프로가 되어라

소프트웨어 장인에는 영웅이 되려하지 말고 프로가 되어라는 말이 있다.

이것을 꽤나 실감했던 2주가 아니었나 싶다. 마감일이 명확하면 명확할 수록 기한을 맞추는 것은 매우 중요하다.

될 것 같은데? 가 아니라 확실히 된다 일때 된다고 말하는게 좋다.

더 좋은 퀄리티의 프로덕트가 나오면 너무나 좋지만, 그것을 이유로 마감일을 맞추지 못하는 것은 프로가 아니다.

안된다고 말하는 것도 책임감이다.

적어도 될 것 같은데? 라면 어떠한 경우에 이러한 이유로 문제가 생길 수 있음을 사전에 팀원과 공유하고, 이를 기반으로 의사결정을 이어가야한다.

확실히 된다는 것

확실히 된다는 특정 디바이스/내 디바이스에서만 정상적으로 작동하는 것을 말하는 것이 아니다.

적어도 iOS Safari와 Chrome에서는 둘다 정상적으로 동작해야한다.

그리고 이것은 상당한 경험을 요한다는 것을 느꼈다.

예를들어 이번 캠페인에서는 영상과 Lottie에서 문제가 발생했다.

safari는 loop 영상을 재생할때 처음과 끝부분이 뚝 끊기는 문제가 있다.

또한 iOS 저전력 모드에서는 자동재생이 되지 않는 문제가 존재한다.

이러한 것들을 사전에 고려하여 의사결정해야 사용자에게 잘 전달되는 프로덕트를 효율적으로 만들 수 있음을 느꼈다.

기한 산정의 함정

기한을 잡을 때 주말에라도 하면 된다는 생각으로 소요시간을 잡다보니 더욱 타이트해짐을 느꼈다.

실제로는 QA시에 생각도 못한 이슈들이 터져나오기에, 이를 위한 시간을 고려해야한다.

스티브가 중간에 이 문제에 대해서 말씀해주셨었는데, 금요일 QA에서 나온 문제들을 해결하다보니, 이게 얼마나 잘못된 추정인지 실제로 체감할 수 있었다.

욕심과 부작용

욕심

마케팅 프로젝트를 하면서도 계속해서 프로덕트 개발을 하고 싶었기에, 캠페인쪽은 저녁으로 미루고 오전/오후시간대에는 프로덕트 개발에 집중하고자했다.

더 많은 작업으로 더 뛰어난 퍼포먼스를 보여주고 싶었다.

결과적으로는 2주간 3개의 피쳐 개발과 함께 캠페인 프로젝트를 잘 이뤄냈지만, 이로 인해 잃는 부분들도 분명히 있었다.

체력

저녁, 때로는 새벽까지 작업을 이어가고 아침에 다시 프로덕트 작업을 이어가다보니 중간쯤부터는 체력/잠이 부족함을 느꼈다.

절대적으로 수면시간이 모자라기보다는 성격상 문제를 풀기전까지는 잠을 잘 못자는 스타일이라 홀드하고 있는 문제가 많아지면 많아질수록 수면 시간과 품질이 떨어져갔다.

학습과 회고

여러 작업들을 스위칭해가면서 이어가다보니, 이번 2주동안은 어떤 활동을 했는지에 대한 daily 문서 데이터 작성이 많이 누락되었다.

더불어 체력이 부족해지고, 주말에도 QA항목을 처리하려다보니 회고를 위한 체력이 부족해졌다.

온전히 한 주를 돌아볼 시간이 줄어듦을 느꼈다. 회고/피드백이 없으면 일은 정말 일로만 끝나버리기 쉽다.

또한 이전부터 이어가고 있는 css학습을 할 수 없었다.

물론 경험을 통해 학습하는 내용도 많았지만, 이렇게 시간을 내서 학습하는 것을 통해 얻는 것도 그것만큼 중요하다고 생각한다.

계속해서 이런 방식을 이어가는 것은 지속가능성이 없다.

작업상의 비효율을 제거하고, 체력을 기르고, 그래도 안된다면 욕심을 줄여야한다.

마케팅 프로젝트 전에는 이러한 일이 없었고, 체감상 워낙 비효율적으로 개발한 부분이 있어서

우선은 다른 프로젝트를 할때도 기능 분석과 확정을 통해 비효율을 제거하는 것으로 방향을 잡아보려고 한다.

UX의 의도와 관계없이 퍼널이 길어질수록 전환율은 감소한다

캐릭터와 상호작용하는 UX를 제공하고자 했는데, 이 의도와 관계없이 목표로 하는 액션이 뒤에 있으면 뒤에 있을수록 전환율은 감소한다는걸 알게 됐다.

화면 전환을 위한 버튼 하나가 들어갈때마다 이탈율은 눈에 띄게 증가한다. 다음 플로우를 위한 버튼 하나당 유저가 거의 반토막이 난다.

마무리

이제 다음주부터는 별 일이 없다면 프로덕트 개발에 집중할 수 있을 것 같다.

따라서 목표는 이전과 동일하다. daily data 작성에 조금 더 신경을 쓰자!

스펙에 대한 이정표 만들기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기
UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 검증시 파괴에 집중해서 검증할 것
기능에 대한 논의는 모두 기록 할 것 + 기능 논의는 모아서 한번에 처리하기

당근 인턴 회고 -15주차

_0422 — Sun, 18 May 2025 17:27:38 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

15주차가 끝났다.

이번주에는 프로젝트 하나를 온전히 맡게되어 대부분 그 부분에 시간을 쏟았다.

되돌아보기

목표로 했던 것들은 이제 어느정도 대부분 체화가 되어 잘 이뤄지고 있는 것 같다.

이번주에는 아침 CSS 학습은 거의 하지 못한 것 외에는 목표로 잡은 것들을 잘 챙기고 있다.

UI 검증으로 얻는 신뢰감

pixel pro를 사용한 검증을 통해 팀 내에서 신뢰를 얻을 수 있다는 것을 알게 됐다.

사람이 하는 일은 늘 실수가 발생한다. 이걸 방지하기 위한 시스템, 루틴이 필요하다.

앞으로도 이 검수 과정을 꼭 유지할 필요가 있다고 느낄 수 있었다.

말하기 셀프리뷰

역시 말로 설명하는 것과 속으로 살펴보는 것은 좀 차이가 있는 것 같다.

돌아보면 두가지 방법이 그렇게 시간이 차이가 나지도 않는다. 당분간은 이 방식으로 계속 진행할 것이다.

느낀점

크로스 브라우징 (스크롤, 다중 동영상)

이번 스펙 중 이중 스크롤이나 다중 동영상에 대한 연속 재생 처리가 있었는데, 이런 부분이 브라우저마다 동작이 달라서 굉장히 많은 시간을 사용해야했다. 다양한 환경에서 실행되어야하는 프로젝트의 경우, 이런 부분이 존재할 수 있다는 것을 인지하고 시간 산정시에 고려해야한다는 것을 크게 느꼈다. 특히 마감일이 정해진 경우는 더더욱...

개선할점

스펙이 많이 바뀔것 같다면...

스펙이 계속해서 바뀔 것 같다면 완전히 결정되기까지 적절하게 미루는 것도 방법이라는 것을 느꼈다.

물론 과정에서 고정될 부분들에 대해 챙길 필요는 있겠지만, 바뀌는 부분에 대해 계속해서 빠르게 대응한다면 그만큼 리소스를 소모하게 되므로 효율적이지 못하다.

스펙 이정표를 작성하기 전에

이정표에 너무 매몰되는 경향이 있었던 것 같다.

이로 인해 개발하던 도중에 소통을 하게되고, 크지는 않지만 비효율적인 시간/자원 낭비가 발생하게 되는 것을 경험했다.

이정표를 작성하기에 앞서 스펙에 대해 이해할때 놓친 부분은 없는지 확인할 필요가 있다고 느꼈다.

현재 작성된 스펙 자체에서 발생할 수 있는 엣지케이스가 있는지, 혹은 사용자의 UX를 좀더 개선할 수 있는지를 먼저 고민해야한다.

사용자 경험에 대해 좀 더 생각하고 스펙에 대해 왜를 던져볼때 좀더 기능이 개선될 수 있다.

아침 CSS 학습

이번주뿐아니라 아마 다음주까지도 CSS 학습은 어려울 수 있을 것 같다.

이후에 좀더 집중하는 형태나 주말에 부족한 부분을 학습해야겠다.

마무리

스펙에 대한 이정표 만들기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기
UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 검증시 파괴에 집중해서 검증할 것
기능에 대한 논의는 모두 기록 할 것 + 기능 논의는 모아서 한번에 처리하기

당근 인턴 회고 - 12, 14주차

_0422 — Sun, 11 May 2025 19:43:10 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

12, 14주차가 끝났다.

13주차는 워크샵을 다녀오면서 거의 1주일간 일을 하지 않아서 따로 회고에 넣지 않았다.

되돌아보기

이번주와 다음주까지 마케팅 프로젝트를 맡게 되면서 혼자 개발해야하는 양이 많아짐따라 구현 비중이 높아졌다.

스펙에 대한 이정표 만들기

이제 이게 어느정도 체화가 된 것 같다. 이렇게 상세히 분석하면 회색 영역이 거의 없이 개발할 수 있어서 좋고,

분석 시에 작성한 체크리스트만 확인하면, 개발 내용에 대한 확신을 가질 수 있게된다.

메모하는 습관

이제 싱크미팅뿐만 아니라 스키마 논의나 스펙논의에도 가끔씩 참여하게 되었는데, 이럴때 특히 메모하는게 중요한 것 같다.

이렇게 해야 회의에서 나온 내용들을 놓치지 않고 챙길 수 있게 된다.

UI 검증은 한번에

pixel pro를 사용해서 개발-검증 1회로 시간을 낭비하지 않고 검수하는 것을 유지해가고있다.

코드 작성시 일관성과 정확성에 대해 의식을 갖고 챙기기

여전히 잘 챙기려고 노력했고, 이번주에 새로운 방법을 찾은 것 같아서 뒤에 좀 더 작성해보려고 한다.

추측하지 말고 실험할 것

추측이 아니라 실험을 이어가고 있다.

아침 CSS학습

잘 진행하지 못했다. 출근하면 뭔가 자연스럽게 일하게되면서 놓치게 됐다.

아침에 좀더 의도적으로 시간을 배분해서 학습해야겠다.

기능에 대한 논의는 모두 기록할 것

노션 댓글과 피그마 댓글을 통해 변경된 부분을 모두 표기할 수 있도록 했다.

느낀점

새로운 셀프리뷰 방법

12주차에 스티브와 리뷰를 대면으로 진행했는데,

이때 나의 코드를 말로 설명할 때, 코드의 일관성이나 엣지케이스들이 더 잘 보이게된다는 것을 알게 됐다.

그래서 실험적으로 기능이 어느정도 복잡한 개발에 대해 말하면서 셀프리뷰하는 방법을 적용해보았다.

결과는 다른사람과 대면으로 리뷰하는 것과 거의 비슷한 느낌을 받을 수 있었다.

더불어 이걸 녹화를 해서 ai에게 전달하여 피드백을 받아보려고했는데, 아직은 영상에 대한 처리는 어려웠다.

대신에 음성파일을 텍스트로 변환하고, 이걸 전달해서 피드백을 받아볼 수 있었다.

아직까지는 좀 부실하지만, 뭔가 더 좋은 방법을 찾아볼 예정이다.

피드백은 부가적인 것이고, 말하기 셀프리뷰를 통해 보다 좋은 퀄리티의 코드를 보장할 수 있게 될 것 같다.

코드를 넘어서 제품을 개선하기 위해

이제 인턴생활도 3개월이 됐고, 어느정도 맥락도 쌓였다보니

다음 3개월은 코드를 넘어서 제품에 대한 고민도 해보라는 조언을 받게 됐다.

일단은 로그를 추가할때, 어떻게 하면 로그로부터 더 효과적인 인사이트를 얻어낼 수 있을지를 고민해서 적용해보고

배포 후에 데이터를 분석하면서 인사이트를 공유하고 있다.

개선이 필요한 점

엔지니어가 아닌 분들과 소통하는 방식

이번 주에는 특히 엔지니어가 아닌 분들과 소통할 일이 많았다.

과정에서 어떻게 소통해야할지, 이 기능이 원활하게 개발 가능하다고 말할 수 있는 것인지 고민을 많이 했다.

돌아보는 과정에서 이 글을 읽게 됐는데, 공감이 많이 됐다.

어떻게 보면 암묵적 가정이나 추론을하지말고, 시험한다와 같은 의미이기도 하다.

다만, 그 암묵적 가정이나 추론을 해야하는 경우가 생기기 때문에 어려운 것 같다.

엔지니어들과 비엔지니어들의 커뮤니케이션 방법 2가지

가끔 엔지니어와 비엔지니어가 커뮤니케이션하는 것을 보면 아쉬운 점들이 있다. 내 경험상 이 두 그룹의 사람들이 커뮤니케이션할때 중요한 것 2가지를 얘기해 본다.

medium.com

확실하게 아는 것, 확실하게 모르는 것, 추론한 것 세가지를 분류하고 이게 어떤 것인지 알려줘야하는데 마케팅 레포지토리를 처음 다뤄보기도 하고 하다보니 확실하게 안다고 할 수 있는 부분이 거의 없었고, 그래서 소통하는데 더 어려움이 있었던 것 같다.

앞으로 이런경우네는 이 부분은 추측한 부분(혹은 모르는 부분)이라고 말해두고 전부 리스트업해서 이후에 체크하는 비동기 형태로 가는게 효율적일 것 같다.

마무리

목표를 정리하면 아래와 같다.

스펙에 대한 이정표 만들기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기
UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것 + 추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 리뷰는 말하면서 진행할 것
기능에 대한 논의는 모두 기록 할 것 + 기능 논의는 모아서 한번에 처리하기

당근 인턴 회고- 11주차

_0422 — Sun, 20 Apr 2025 21:06:40 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

11주차가 끝났다.

이번주는 크게 느낀 것은 따로 없으나,

이전주에 느낀바로 사이클을 잃으면 성장하기 어렵기 때문에 계속해서 지속한다는 관점에서 작성하였다.

되돌아보기

이번 주는 구현뿐 아니라 데이터 분석도 했었어서 전반적으로 구현의 비율이 많이 낮아지게 되었다.

스펙에 대한 이정표 만들기

이 부분은 잘 된 것 같다.

스펙을 분석하고 작성하고, 또 뭔가 변경되었을때 문서를 수정하면서 놓치는 부분이 없도록 할 수 있었다.

다만, 변경이 되거나 의사결정이 필요한 부분이 생기는 경우, 이런 부분을 좀 한번에 처리할 수 있지 않을까? 라는 생각도 했다.

물론 빨리 처리하는 것도 너무 중요하지만, 급하게 처리하려다보니 모아서 처리할 수 있는 부분도 나눠서 논의하게 된 것 같아서 아쉬움이 남았다.

메모하는 습관 유지하기

사소한 것이라도 적으면 놓칠 확률이 줄어드는 것을 느낄 수 있었다.

UI 검증은 한번에

개발-검증 1회로 전반적으로 시간을 낭비하지 않고 검수하는데 성공했다.

다만, 스펙이나 결정사항에 변경점이 생기는 경우 다시 검수해야하는 시간이 필요해졌고, 위에서 말한 것처럼 나눠서 논의하게 되면서 이 부분에서 불필요하게 늦어지는 부분이 있었던 것 같다.

코드 작성시 일관성과 정확성에 대해 의식을 갖고 챙기기

이 부분은 챙기려고 많이 노력했고, 잘 챙겨 졌다고 생각한다.

가정과 사실 기록하고, 암묵적 가정을 하지 말 것

소통시에 가정과 사실을 분리해서 전달하는 것을 항상 염두에 두고 진행했다.

이런 부분은 데이터 분석시에 좀더 주의를 필요로하는 것 같다.

추측하지말고 실험할 것

추측이 아니라 실험을 통해 확인했다.

아침 CSS학습

잘 진행중이다!

기능에 대한 논의는 모두 기록할 것

노션에 정리하고, 변경이 있을때 댓글로 변경되었다는 것을 표기하는 방식으로 진행했다.

개선이 필요한 점

한번에 논의하기

위에서 작성한 것처럼 논의사항이나 결정사항이 필요한 경우 웬만하면 모아서 한번에 처리하는 것이 좋다고 느꼈다.

물론 슬랙기반의 비동기 통신이지만, 하나씩 논의하다보니 전체적으로 속도가 느려지는게 느껴졌기 때문이다.

마무리

목표를 정리하면 아래와 같다.

스펙에 대한 이정표 만들기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기
UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 검증시 파괴에 집중해서 검증할 것
기능에 대한 논의는 모두 기록 할 것 + 기능 논의는 모아서 한번에 처리하기

당근 인턴 회고 - 8,9,10주차

_0422 — Sat, 12 Apr 2025 16:28:51 +0900

내용에 문제가 있는 경우, 삭제, 수정조치하겠습니다.

8,9,10주차가 끝났다.

휴일, 휴가로 며칠씩 쉬다보니 모아서 써야지 하다보니 벌써 3주가 지나버렸다.

사실 3주(15일)동안 실제 일한건 11일정도라 사실상 2주차 회고가 아닌가... 싶기도하다.

그나저나 역시 흐름이 끊기면 글을 쓰기가 참 어려운 것 같다.

되돌아보기

UI 검증은 반복적이지 않도록 되도록 한번에 할것

3주간 진행했던 기능 개발이 이전보다 간단했어서 그런 것도 있겠지만

이 부분은 잘 되었다고 생각한다. 마지막에 한번 체크하는 형태로 전환하면서 UI에 대한 검증 시간이 크게 감소했다.

코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것

이 부분도 이전보다는 훨씬 나아지지 않았다 싶다.

pull request extension을 통해 1차로 셀프 검증하고, cursor agent를 통해 git commit을 넣어 확인하는 형태로 챙길 수 있었다.

불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것

요것도 이전보다 좀더 나아졌다.

다른 사람과 공유할때는 excalidraw를 사용해서 공유하고, 혼자 정리할때는 메모장에 그려보는 형태로 정리할 수 있었다.

이런 과정에서 조금더 자신감을 가질 수 있었고, 코드에 대한 품질을 높힐 수 있었다고 생각한다.

가정과 사실을 기록하고, 암묵적 가정을 하지 말 것/추측하지 말고, 시험할 것 + 기능에 대한 논의 기록

이 부분은 좀더 챙겨야할 것 같다. 추측하지 말고 시험하는 형태로 검증은 하고 있지만, 이걸 기록하는건 잘 챙기지 못했다.

전반적으로 기록하는게 잘 안되고 있다고 느꼈다.

문서에 좀 더 잘 남겨야겠다.

아침에 30분씩 CSS학습

CSS완벽가이드를 통해 학습하고 있다.

매일 30페이지씩 읽는 걸 목표로 하고 있으며, 업무일 11일 모두 읽어 330페이지를 읽고 있다.

생각보다 아침에 공부하는게 유효하다고 느낄 수 있었다.

학습한 것을 바로 사용해봄으로써 진짜 나의 지식이 되는 느낌이다.

잘한 점

메모하기

메모장을 챙기고, 무엇이 됐든 손으로 적는 습관을 들이려고 노력했는데 이게 상당히 도움이 됐다.

검증할때는 하나의 체크리스트가 되었고, 다양한 문맥을 오가며 업무를 진행해야할때도 어디까지 했는지 알 수있게 하는 일종의 메모리처럼 동작할 수 있었다.

설계/문서화 시간

지난 3주간 그래도 이전보다는 설계/논의, 문서화 비율이 많이 올라왔다.

스펙을 좀 더 분석하고, 노션문서를 더 상세하게 적으면 적을 수록,

코드를 짜는동안 의식적으로 코드 품질에 대해 생각할 수 있게 되고, 결과적으로 품질을 더 보증할 수 있게 된다는걸 느꼈다.

더불어 시간도 덜 걸리게 되었다.

개선이 필요한 점

회고를 지속하기

지난 3주간, 절대적인 업무시간이 적었기에 몰아서 해야지하고 넘겨왔다.

이로 인해서 피드백 사이클이 늦어지고, 목적 의식이 흐릿해지는 부분이 있다고 느꼈다.

이러면 이전에 학습했던 것들이 이어지지 않게되고, 개선되지 않는다.

항상 의식적으로 챙겨할 부분들을 생각하고, 셀프 피드백하면서 더 개선해야한다.

그 주에 별 내용이 없더라도 피드백 주기는 지켜야한다.

느낀 점

설계도가 아닌 이정표

이전까지는 스펙 문서를 쓰는게 설계도를 만든다는 느낌으로 작성했다.

하지만, 설계도 형태로 "여기에는 이것" 보다는,

이정표를 만든다는 생각으로 "이거 다음은 이것" 형태로 쓰는 게 좀더 효과적이라고 느꼈다.

방향성을 잡는 이정표를 만들고, 세부적인 것들은 노트에 메모하며 체크리스트로 챙기면 더 효과적이었다.

머릿속에 있는 것을 밖으로 빼놓는 것이 생각보다 아주 강력하다고 느낄 수 있었다.

가치가 전달된다는 뿌듯함

업무와 별개로, 내가 만들어낸 가치가 사용자에게 전달되고 사용된다는 점이 정말 즐거운 것 같다.

어떤 문제를 분석하고 해결하는 것도 정말 즐겁지만 누군가에게 내가 만든 가치가 전달된다는 것보다 즐거운건 없구나 새삼 느꼈다.

더 좋은 가치를 전달하기위해 더 좋은 개발자가 되어야지.

마무리

목표를 정리하면 아래와 같다.

스펙에 대한 이정표 만들기
메모장을 준비하고, 메모하는 습관 유지하기
내용이 없어도 회고하는 사이클 지키기

기존 목표도 여전히 지켜나갈 것이다.

UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 검증시 파괴에 집중해서 검증할 것
기능에 대한 논의는 모두 기록 할 것

당근 인턴 회고 - 6,7주차

_0422 — Sun, 23 Mar 2025 14:39:46 +0900

내용에 문제가 있는 경우, 삭제, 수정조치하겠습니다.

6,7주차가 끝났다.

6주차 주말에는 너무 정신이 없어서 작성하지 못해서 이번주에 한번에 회고하고자 한다.

되돌아보기

도구를 통해 UI정확성 확인하고, 수치값으로 한번 더 확인하기

우선 PixelParallel보다 좋은 Pixel Perfect Pro라는 확장 익스텐션으로 변경했고, 작업중에 지속적으로 확인했다.

완전히 UI에 대한 정확성을 100% 챙길수는 없었지만 그런 부분이 줄어들었다.

100%가 될 수 없었던 이유는, Figma와 브라우저 렌더링 방식이 100% 동일하지 않았기때문이다.

좀더 정확하게 써보자면 원인은 다음과 같다.

1. 폰트크기가 같아도 브라우저와 피그마간에 미묘한 크기차이가 발생하고, 이로 인해 줄바꿈이 발생하는 경우 확인하기가 어려워진다.

2. border의 경우 1px이 들어가고 빠지고에 따라 뒷부분에 렌더링되는 요소들이 1px밀리기도 한다.

동시에 이 도구를 사용함으로써 시간이 낭비되는 문제도 있었다.

UI 퍼블리싱 -> 익스텐션으로 확인 하는 사이클이 반복됨에 따라 계속해서 확인-수정하는 과정이 중첩적으로 수행됐고, 시간을 많이 소요시켰다.

의식적으로 설계에 대한 시간 늘리기

이 부분에 대해서 좀더 개선이 필요하다고 느꼈다.

자꾸만 건물을 짓는 것처럼 한번에 설계하고, 한번만에 개발을 하려고 하는 경향이 있는 것 같다.

한번만에 설계를 하고 바로 작업에 들어가고, 변경된 설계에 대한 문서화를 놓치고 있다고 느꼈다.

또한 너무 큰 부분에 대해 설계해서 디테일한 부분에 대한 설계가 부족했고, 이러한 부분들때문에 디테일하게 놓치는 부분들이 발생했다. DBC가 잘 안이뤄졌다는 증거이기도 하다.

잘한 점

6,7주차에 잘한 점이라면.... 어떻게든 포기하지 않고 맡은 테스크에 대해 책임감을 갖고 개발을 했다는 점이랄까...

잘한점 보단 개선할 점을 왕창 느낄 수 있었던 두 주였다.

Cursor rule 및 MCP도입

멀게만 느껴졌던 cursor rule과 MCP를 도입해봤다.

figma mcp와 browser tools mcp, sequential thinking을 도입했고 아래와 같이 사용해봤다.

figma UI가 코드로 잘 구현되었는지 검증
코드 일관성/엣지케이스 검증

아직 경험이 부족하긴 하지만, 지금까지의 결론은 아래와 같다.

figma UI 검증 : 뭔가 리뷰를 해주긴 하지만, 유효하지는 않다.

코드 일관성 검사 : 생각보다 유효했다.

엣지케이스 검증 : 그렇게 효과가 있진 않지만, 그래도 안하는 것 보단 낫다.

개선이 필요한 점

6,7주차에는 신규 기능 개발을 하게됐고, 개선할 점들을 너무나도 많이 느낄 수 있었던 주차였다.

우연에 맡기는 프로그래밍, 그로 인한 불안감

우연에 맡기는 프로그래밍

코드를 작성하다보면 무의식에 빠지는 경우가 있다.

몰입이라고도 말 할 수도 있겠지만, 이로 인해서 코드 스타일의 일관성, 그리고 정확성을 놓치게 된다면 그건 몰입이 아니고 무의식적인 행동에 불과하다.

적극적으로 내가 무슨 코드를 작성했는지 생각하고, 개선하자.

돌아본 결과 뭘하고 있는지 놓치는 경우는 잘 모르는 것에 대한 문제를 해결해야하는 경우였다. (복잡한 타입 다루기, CSS디버깅 등)

모르는 것에 대해 해결을 어떻게든 해내긴하지만, 과정에서 이전 작업에 대한 맥락을 잃는다.

큰 맥락에서 뭘 하고 있는지 잊게 된다.

동시에 문제를 해결했다는 그 효용감이 큰 맥락에서 디테일을 잃게 만든다.

불안감

6,7주차 동안, 계속해서 내면의 불안감과 싸워야했다.

주중에는 규모가 있는 신규 기능 개발이라는 미지의 영역이기때문이라고 생각했고, 단순히 내 코드에 대한 버그가 발생할까에 대한 불안감인줄로만 알았다.

실용주의 프로그래머를 읽으면서 이 근본적인 원인이 우연에 맡기는 프로그래밍때문임을 알게 됐다.

무엇인가 잘못 됐다면, 그것을 말로 설명할 수 없다 하더라도 불안하고 초조함을 느끼게 된다.
본능이 반응하고 있다는 것을 인지해야한다. 그리고 왜 그런 느낌이 드는지 알아야한다.

암묵적 가정과 상황적 우연에서 패턴 찾기

작업시 암묵적 가정을 갖고 작업한다는 걸 느꼈다.

또한 상황적 우연에서 패턴을 찾아 상관없는 부분에 대한 디버깅을 하기도 했다.

하지만

잘되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르며,

확고한 사실에 근거하지 않은 가정은 프로젝트에서 재앙의 근원이 된다.

개선방안

실용주의 프로그래머에서는 불안감이 느껴진다면, 아래의 방법을 통해 어떤 일을 하고 있는지 자세하게 정리해보라 제안한다.

코드에 대한 그림을 그려보라.
가정을 항상 기록해라. (문서화) -> 근거를 신뢰하기 어렵다면 최악의 상황을 가정하라
추측만 하지말고 직접 시험하라.

이 요소들을 내 개발 환경에 적용해볼 것이다.

또, 맥락을 잃지 않기 위해 어려운 문제를 줄여나가야한다.

적어도 CSS문제는 공부해서 해결할 수 있다.

아침에 30분씩이라도 CSS 책을 통해 이론을 쌓아 CSS에 대해 확인하고 디버깅하는 시간을 줄이려고한다.

셀프 검증시의 문제

이상하리만큼 셀프 검증시에는 보이지 않던 문제들이 코드리뷰나 QA시에서는 나타났다.

"개선" 에 초점을 맞추면 문제가 보려하기보다는 잘 되는 코드를 더 나아지게 만들려는 경향성을 갖게 되기 때문에 문제를 찾기가 어렵다고 느꼈다.

이에 코드 검증시 DBC기반으로 입력/출력에 대해 생각해보되 방향성 자체를 내 코드를 개선한다가 아니라,

남이 쓴 코드라고 생각하고, 이걸 박살내려면 어떻게 해야하지? 를 고민해볼 필요가 있다고 느꼈다.

무엇보다 기능개발이 완료됐다고 작업이 완료된 것이 아니라는 것을 명심할 필요가 있다고 느꼈다.

그건 10%만 완료된 것이다. 나머지 90%는 그것을 검증하는 것이다.

맥락을 기록하기

신규 기능은 꽤나 많은 경우가 있는 기능이었고, 이에 따라 많은 논의가 필요했다.

이 맥락을 기록하지 않아서 혼란이 생기는 경우가 있었는데, 앞으로는 이런 부분이 없어야한다고 느꼈다.

기능에 대한 논의는 구두로 하더라도 반드시 문서를 남기자.

마무리

6,7주차에는 있는 기능을 유지/보수하는 것과 신규 기능 개발을 하는 것이 얼마나 많은 차이가 있는지를 느낄 수 있는 주였다.

동시에 부족한 부분도 많이 느낄 수 있었다.

이런 부분들을 개선할 때 더욱 성장할 수 있을 것이다.

목표를 정리해보면 아래와 같다.

UI 검증은 반복적이지 않도록 되도록 한번에 할 것
코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
추측하지 말고, 시험할 것
아침에 30분(+)씩 CSS 학습
셀프 검증시 파괴에 집중해서 검증할 것
기능에 대한 논의는 모두 기록 할 것

당근 인턴 회고 - 5주차

_0422 — Sun, 9 Mar 2025 21:48:11 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

5주차가 끝났다. 이번 주는 대체 휴일로 하루를 쉬어서 4일동안 일했기도했고 저번주에 설계한 것들을 바탕으로 리팩터링을 하거나 코드보다 스펙에 대해 이해하고 설계하는 시간이 대부분 이었어서 뭔가 따로 세운 목표를 적용해볼 기회가 좀 적었던 것 같다.

되돌아보기

뽀모도로 휴식시간에 다음 계획 더 잘 작성해보기

이 부분은 좀 더 개선된 것 같다. 여전히 가끔은 놓치기도 하지만....

어떤 테스크를 한다 -> 어떤 테스크중에 어떤 부분을 한다 형태로 좀 더 구체적으로 작성하려고 노력했다.

그리고 GPT사용해서 자체적으로 만든 업무 기록표를 넣으면 보고서를 만들도록 프롬포트를 만들어뒀는데, 이게 생각보다 유용해서 좀더 정확한 정보/인사이트를 얻기 위해서 앞으로 더 잘 작성하기위한 동기부여가 되는 것 같다.

UI 퍼블리싱시 정확성을 위해 설계-코드작성-확인을 작은 단위로 진행하여 정확성 향상시키기

이 부분은 노력은 했지만, 결과적으로는 잘 되지 않았다.

특히 개발 중간에 스펙이 바뀌는 경우가 있었는데, 이때 이전 사용하던 스펙을 그대로 쓸 수 있었기에 이것들을 다시 확인하지 않게 되어 문제가 발생했다.

이전주에 느낀 것처럼, 상황이 바뀌면 다시 다 확인해봐야하는데 그 부분을 놓쳤다.

이건 개선할 점에서 좀더 작성해볼 것이다.

화면 기반의 추상화를 진행하고 간단 명료한 인터페이스 짜기

이번주에는 로직관련 작업을 따로 하지는 않아서 코드로 짜지는 못했다. 하지만, 설계시에 고려해서 설계를 할 수 있었다.

CSS 이론 학습하기

이 부분은 mdn문서를 시간남을때마다 보고는 있지만, 조만간에 책 한권을 전부 읽는 형태로 진행해볼 생각이다.

AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기

GPT를 통해서 내 업무 데이터를 기반으로 얻을 만한 것들을 챙겨보게 됐다!

잘한 점

개발 작업 환경 개선

이번주에도 개발 작업 환경 개선을 위해 작업을 진행했다.

이번주엔 개발자 디버깅 도구에 간단한 검색기능을 추가해서 테스트를 하기 좀더 쉽게 개선해보았다.

또한 index.html이 굉장히 복잡하다는 문제가 있었는데, next처럼 동작하는 프레임워크를 만들었을 때의 경험을 살려서 이러한 문제를 index.html을 빌드하는 형태로 개선을 진행했다.

이런 것들을 지속적으로 찾고, 개선해가는 경험을 계속 쌓아가고 싶다.

개선이 필요한 점

UI 정확성

UI 정확성이 문제다. 개선이 너무나 필요하다.

이전주에서 세운 루틴을 적용해서 수행했지만 처음 작업을 할때 정확성을 맞췄다고 해서 스펙이 변경됐을 때도 맞춰져 있는 것은 아니다.

요구사항은 계속해서 변하고, 확정되어있는 것은 없다.

요구사항이 변했다면 다시 모든 것을 확인해야한다.

작업했다가 디자인 스펙이 바뀌어서 다시 작업을 해야했는데, 요소가 추가되면서 패딩값이 달랐던 문제가 있었다.

이런 문제가 지속되면 나의 생산성은 물론, 팀의 생산성이 낮아질 수 있다.

다음 주에는 UI작업시 PixelParallel이라는 chrome extensions을 도입해서 UI에 대한 정확성을 높이고자 한다.

이 도구를 사용하면 피그마 작업물을 png로 export하고, 이걸 브라우저에 띄워서 겹쳐서 확인할 수 있다.

가장 직관적이고 시각적으로 확인할 수 있는 부분이라, 이걸로 1차적으로 확인하고, 값을 확인하면서 2번 검수해보려고한다.

느낀 점

주변을 잘 살피기

번들사이즈/폴리필 관련 최적화 작업을 진행했는데, 메인 작업에서는 할 수 있는 모든 걸 해봤지만, 번들사이즈를 줄일 수 는 없었는데

번들을 분석하다 이슈와 관련없는 다른 곳에서 불필요한 것들을 찾을 수 있었다.

전반적으로 내가 뭘 하고 있는지 인지하고, 조금 더 넓게 바라보면 더 많은 해결방법을 찾을 수 도 있겠다는 교훈을 얻을 수 있었던 것 같다.

데이터와 AI

데이터가 있다면 어찌됐든 AI를 활용할 수 있다.

인사이트를 얻어낼수도 있고, 데이터를 좀 더 활용할 수도 있다.

업무 일지에 대한 리포트를 만들어내는 걸 보고 더 많은 곳에 사용할 수 있을 거라고 생각하게 됐다.

마무리

이번주에는 저번주 목표를 제대로 적용하기는 어려웠으므로 이전주의 목표를 유지하되, 추가로 몇 가지를 더 가져가려고 한다.

우선 이전주 목표는 아래와 같다.

1. 뽀모도로 휴식시간에 다음 계획 더 잘 작성해보기

2. UI 퍼블리싱시 정확성을 위해 설계-코드작성-확인을 작은 단위로 진행하여 정확성 향상시키기

3. 화면 기반의 추상화를 진행하고 간단 명료한 인터페이스 짜기

4. CSS 이론 학습하기

5. AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기 -> 테스크 쪼개기/시간관리 쪽으로

이번주에는 여기에 더해 몇 가지를 더해보려고하는데 AI리포트 기반으로 얻은 것을 적용해보고자한다.

우선 내 기록을 돌아보면 현재, 구현의 비중이 높고, 설계/논의 비중이 낮은 편이다.

설계시간을 조금 더 높히면 재구현이나 리팩터링 하는 시간을 좀 더 줄일 수 있지 않을까? 라는 생각이 들어서

의도적으로 설계에 대한 시간을 늘려보고자한다.

어느정도 마무리되었다고 생각했을때,

엣지케이스가 없는지, 더 나은 방법은 없는지에 대해 30분정도를 더 고민해보고,

또한 설계시에 DBC(Design By Contract) 에서 사용하는 것들을 일부 적용해볼 생각이다. (feat. 실용주의 프로그래머)

유효한 입력 범위는 무엇인가?
경계 조건은 무엇인가?
함수가 뭘 전달한다고 약속하고, 무엇을 약속하지 않는가?

그래서 추가적으로 잡은 목표는 두가지다.

1. PixelParallel를 통해 UI 정확성 확인하고, 수치값으로 한번 더 확인하기

2. 의도적으로 설계에 대한 시간 늘리기 (30분 더 고민해보기/ 설계시 DBC 개념 일부 적용해보기)

패키지 업데이트를 위한 yarn.lock에 대한 이해

_0422 — Mon, 3 Mar 2025 17:59:32 +0900

이전까지 패키지 관리에 대해서는 뭔가 부분적으로 이해하고 있었다.

왜냐하면 경험 자체가 패키지를 설치하거나, 만든 패키지를 배포하기 위한 버전 관리였기 때문이다.

이런 경험은 버전에 대해 심화적으로 살펴볼 필요가 없다.

그래서 버전정보와 관련한 것들은 틸드, 캐럿에 대해서만 어느정도 이해하고 있었다.

그러나 이번에 Typescript를 비롯한 여러 패키지의 버전을 업그레이드하는 경험을 할 수 있었고, 이때 학습한 것들을 글로 남기고자 한다.

yarn.lock파일

package.json은 어떤 패키지를 사용하는지 대략적인 정보만을 가지고 있다.

yarn.lock파일은 package.json에 기록된 라이브러리가 실제로 어떤 버전으로 설치된 것인지를 기록한 파일이다.

덕분에 여러 개발자가 같은 프로덕트를 개발할때 동일한 라이브러리를 설치할 수 있게 된다.

딱 여기까지가 알고 있던 내용이었다.

하지만 뭔가 버전 업데이트를 한다고 하면, lock파일을 좀더 깊게 살펴볼 필요가 있었다.

왜 package.json에 정확한 버전을 표기하지 않을까?

package.json을 들여다보면, 버전 정보를 정확하게 고정하지 않고 ^와 ~를 통해 버전을 정의한다.

참고로 ~(틸드)는 패치 버전에 대한 하위호환성을, ^(캐럿)은 마이너버전에 대한 하위호환성을 보장한다.

그런데 왜 이런식으로 설계 됐을까?

그냥 정확한 버전으로 package.json에 정의해버리면 어떤 문제가 있을까?

1. 의존성 충돌/중복번들링

아래와 같이 패키지를 사용한다고 가정하자.

"dependencies": {
  "packageA": "1.2.3",
  "packageB": "1.3.0"
}

여기서 packageA의 react는 16를 사용하고, packageB의 react는 18을 사용한다면 참조시 충돌이 일어나서 제대로 동작하지 않을 수 있다.

2. 중복 설치

1번 상황처럼 메이저 버전이 아니라, 패치버전만 다르다고 가정해보자.

패치버전은 그렇게 큰 변경이 아니므로 내용이 거의 같다. 하지만, 버전을 정확하게 고정시키면 같은 내용을 두 번 받아와야하므로 속도가 느려지게된다. 이런 문제를 ~나 ^를 사용해서 계산하는 형태로 하나로 통일할 수 있다.

그래서 두번 받아올걸 한번만 받아오게 하여 속도를 개선하는 것이다.

또한, 두 패키지를 모두 사용한다면, 거의 같은 내용의 두 가지 버전이 모두 번들에 포함되게 되어 번들사이즈가 커지게 된다.

3. 버전 업데이트의 용이성

yarn upgrade를 하면 하위호환성을 지키는 형태로, 업그레이드가 진행된다.

보통 패치나 마이너 업데이트는 인터페이스를 변경하지 않고, 버그를 잡는 업데이트이기 때문에 한번에 자동으로 업그레이드 할 수 있다면 한번에 관리하기 용이할 것이다.

하지만 고정된 버전으로 관리한다면, 일일히 해당 패키지를 확인하고 마이너버전, 패치버전에 맞게 하나씩 고정 버전으로 올려줘야한다.

별게 아닌 것 같지만 수십개라면 굉장히 비용이 드는 작업이다.

yarn.lock 살펴보기

이제 다시 yarn.lock파일을 살펴보자. yarn.lock은 아래와 같이 구성된다.

@some-package@^1.0.0: //package.json에 정의된 버전
version: "1.0.0" // 실제 설치된 버전
resolved "some url/HASH_VALUE" // 패키지가 다운된 URL+해시값
integrity "hash value" // 해시값
dependencies: 
	"의존 패키지": "^3.0.0" //some-package의 package.json에 정의된 버전"

첫번째 이름이 package.json에 정의된 버전이다.

이건 틸드와 캐럿을 통해 표기한 버전으로, 정확히 어떤 버전이 설치됐는지를 보기위해서는 version필드를 살펴보아야한다.

resolved필드는 해당 패키지를 설치한 URL+SHA-1해시값을 표기하는데, 뒤의 해시값이 해당 파일이 변조되지 않았는지를 검사한다. 해당 URL에서 .tgz파일을 받아오는데, 이 파일의 내용을 해시한 값이다.

integrity도 동일하게 .tgz를 해시한 값을 나타내는데 sha-512으로 해시한 값이다. 취약점이 개선된 해시함수를 써서 더 강력하다.(SHA-1은 취약점이 있어서 취약한 해시함수다.)

그래서 실질적인 해시값 검증은 integrity가 하고, resolved는 하나의 url이라고 볼 수 있다.

그리고 이 패키지가 사용하는 패키지들이 dependencies에 표기되어있다.

이 dependencies들은 @some-package@^1.0.0이 의존하고 있는 패키지들의 목록이며, 해당 패키지 package.json에 정의된 버전 정보가 기록되어있다. 따라서 이 버전은 정확한 버전이 아니다.

정확한 버전을 보려면 의존 패키지@^3.0.0으로 기록된 부분을 재귀적으로 확인하면된다.

만약 같은 라이브러리의 다른 두 가지 메이저 버전이 설치됐다면?

yarn.lock에서는 아래와 같이 표기되게 된다.

some-dash@^5.17.20:
  version "5.17.20"
  resolved "https://registry.yarnpkg.com/some-dash/-/some-dash-5.17.20.tgz"
  integrity sha512-xxxx
  dependencies:
    other-lib "^1.2.3"

some-dash@^4.18.0:
  version "4.18.0"
  resolved "https://registry.yarnpkg.com/lodash/-/some-dash-4.18.0.tgz"
  integrity sha512-yyyy
  dependencies:
    other-lib "^1.3.0"

이걸 의도했다면 다행이지만, 이 상황 자체가 의도하지 않은 경우 일 수 있다.

보통은 의도하지 않았을 것이다. 의존성 자체는 하나를 바라보게 하는게 장기적으로 봤을 때 안정적이다.

이러한 경우 해결하는 방법은 두 가지로 볼 수 있다.

해당 메이저 버전을 사용하는 라이브러리 탐색하여 그 라이브러리를 업데이트하는 방법

some-dash를 5버전으로 통일한다고 하면, 아래와 같이 진행할 수 있다.

1. some-dash@4.18.0을 dependencies로 가지는 패키지를 yarn.lock에서 탐색

2. 찾은 패키지가 some-dash 5버전을 사용하는 버전이 있는지 확인

3. 그 버전으로 업데이트

package.json의 resolutions 필드 사용

yarn.lock이 아닌, package.json의 resolutions필드에 버전정보를 강제해서 모든 패키지가 이 버전을 사용하게 하는 방법이 있다.

{
  "dependencies": {
    ...
  },
  "resolutions": {
    "some-dash": "5.18.0"
  }
}

당근 인턴 회고 - 4주차

_0422 — Mon, 3 Mar 2025 14:56:34 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

벌써 한달차가 끝나버렸다.

돌아보기

우선 이전 주 목표를 기반으로 돌아보고, 느낀 것들을 적어보려고 한다.

1. 뽀모도로 유지 및 좀 더 잘 작성하기

이전 주와 비슷하게 유지되었다. 다만, 좀더 익숙해져서 다음 일을 계획하거나 기록하는 것은 조금 개선됐다.

아직까지 완벽하게 일하다가 돌아와서 5분간 다음 할일을 계획하는 수준은 아니어서 이 부분에 대해서는 계속해서 의식적으로 인지해서 개선할 필요가 있다.

2. 문제가 안풀릴 땐 다시 상단부터 다시 좁혀나가기 + 코드/맥락 파악시 그림을 적극 이용하기

이번 주에 리팩토링을 진행할때 적극적으로 활용할 수 있었던 부분이다.

추상화 방식 자체가 잘못되었을 수도 있겠다는 생각에 좀더 상단으로 돌아가 생각을 했고, 보다 나아진 추상화 인터페이스를 생각해낼 수 있었다.

또한 이에 대한 그림을 그리면서 좀더 설계가 명확해지고, 설명하기 좋아지는 부분이 있었다.

3. 문제에 새로운 상황이 더해졌을 때 확인해보고 기존 뷰를 빠르게 버리고 새로 시작하기

마찬가지로 리팩토링할때 적극적으로 사용할 수 있었던 방법이다. 이전에 진행할때는 데이터 자체에 집중했어서 그렇게 중요하지 않은 부분에 대한 추상화를 했고, 결과적으로 복잡해지고 읽기 어려워지는 문제가 발생했다.

하지만, 대부분의 프론트엔드 코드에서 추상화된 인터페이스를 소비하는 것은 UI다.

결국 데이터를 다룬다고 해도 컴포넌트에서 해당 코드를 소비한다면 인터페이스 자체는 UI에 맞춰져 있어야한다.

4. AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기 -> 테스크 쪼개기/시간 관리 쪽으로

이 부분은 아직까지 깊게 고민해보지 못했다.

노션 AI를 사용해서 오늘 하루 어떤 일을 했는지 요약하는 정도로 도입했다.

이외에는 여러 사람들이 사용하는 방식을 살펴보고있는 상태다. 더 조사할 필요가 있다.

잘한점

개발자 작업 환경 개선을 위해

전반적으로 더 나아진 개발자 작업 환경을 구성하기 위해 노력한 점이다.

더 나은 타입 추론을 해서 코드량을 줄이기위해 typescript를 업데이트하고, 반복되는 컨벤션에 대해 lint룰을 만들고, 관리되기 어려운 코드를 다루는 방식을 변경하는 등 진행하면서 팀의 생산성을 높히기 위해 노력했다.

이런 경험은 코드베이스가 작은 환경에서는 하기 어려운 경험이기에 너무나도 소중한 경험이 아닌가 싶다.

또한 이런 경험을 하면서 배우는 것들도 꽤 되어서 누군가가 해야하고, 그것이 모두에게 도움이 된다면 내가 한다는 태도를 갖고 이어나가고자 한다.

사용자 경험 개선을 위해

네트워크로 너무 무거운 리소스를 반복해서 받아오는 부분을 개선하기 위해 라이브러리를 도입해서 해결했다.

몇 부분 없었지만, 프로덕트에 이런 식으로 기여하고 사용자 경험을 개선할 수 있었다는게 참 뿌듯했다.

UX자체를 개선하는 것도 중요하지만, 이런 식으로 자원이나 환경을 개선하는 것도 유의미할 수 있겠다는 생각을 하게한 경험이었다.

개선이 필요한 점

이번 주에 생각보다 내가 부족한 부분들을 많이 느꼈던 것 같다.

정확성

이전까지 tailwind로 개인 프로젝트를 진행하거나, 이미 잘 만들어진 디자인 컴포넌트를 사용해서 퍼블리싱을 해서 일까, 스펙과 동일하게 UI를 구성했다고 생각했으나 마진이나 패딩이 다른 부분들이 꽤 많이 있었다.

리뷰가 아니었다면, 전혀 인지하지 못했을 것이다. 이런 부분은 다시는 일어나서는 안되는 일이라고 생각한다.

무엇이 잘못 됐는 지를 몰랐다. 그건 너무 큰 일이다.

지금까지 나는 다른 부분은 부족할지 몰라도, UI 퍼블리싱에 있어서는 정확하게는 완벽하지는 않더라도 어느 정도는 맞출 수 있다고 자신했다. 그래서 따로 UI퍼블리싱을 할때 설계를 하지도 않았고, 좀 더 빠르게 만들어 내는 것에 집중하려했지만, 그렇지 않다는 것을 알게 됐다.

그래서 이번 주에는 정확하게 에 좀 더 집중을 해보려고한다.

하지만 UI를 모두 체크하기란 쉽지않은 일이다.

그래서 이런 부분을 개선하기 위해서 UI자체를 작은 단위로 설계한 뒤에 만들고 한번 확인할 때 완벽하게 끝낸다는 생각으로 임하려고 한다.

UI를 설계하고 코드로 작성하고, 확인하는 과정을 하나의 사이클로 만들고, 이 과정을 반복하면서 UI퍼블리싱에 대한 정확성을 가져가고자한다.

CSS 지식

리뷰를 받으면서 또 느낀 것이, CSS를 이론적으로 정말 잘 모르는구나를 느꼈다.

스펙대로 화면을 구현할 수는 있으나, 좀더 최적화되고 나은 방식으로 CSS를 만드는 방식을 모른다.

그래서 css코드에 필요 없는 스타일링 코드가 많이 들어가게 됐다.

이런 문제는 단순히 이렇게 바라보면 별개 아닌 것 처럼 느껴질 수 도 있지만, 이게 잘 안되면 js로 코드를 짜게되고, 이러면 실제 사용자 환경에서 프로덕트가 리소스를 더 잡아먹는 작업을 하게 만든다.

이런 부분을 개선하려면 CSS에 대한 이론 지식을 공부할 필요가 있다고 느꼈다.

느낀 점

이번 주엔 작성한 것 처럼 크게 UI퍼블리싱과 CSS에 대한 부분, 그리고 추상화에 대한 부분을 다시 고민할 수 있었다.

추상화에 대한 부분은 특히 좀 크게 배운 부분이라고 생각한다.

데이터를 받아오기는 하지만, 데이터를 소비하는 곳은 UI다.

추상화는 사용자에게 어떤 것을 원하는 지에 따라 간단 명료하게 제공되는 것이 가장 좋다.

따라서 프로덕트 화면에서 추상화는 데이터 기반이 아닌 UI기반으로 이뤄져야한다.

그래서 전반적으로 이번주 목표를 정리하자면

1. 뽀모도로 휴식시간에 다음 계획 더 잘 작성해보기

2. UI 퍼블리싱시 정확성을 위해 설계-코드작성-확인을 작은 단위로 진행하여 정확성 향상시키기

3. 화면 기반의 추상화를 진행하고 간단 명료한 인터페이스 짜기

4. CSS 이론 학습하기

5. AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기 -> 테스크 쪼개기/시간관리 쪽으로

이렇게 회고글을 적는 것은 나의 성장을 위한 것도 있겠지만

팀의 목표를 달성하기 위해서이고, 팀 내부에서도 나의 역할을 다하기 위해서이다.

나의 역할은 여러가지가 있을 수 있겠지만 최우선은 주어진 테스크들을 빠르고, 정확하게 이해하고, 이를 효율적으로 해결해내는 것이라고 생각한다. 이 역할은 가장 기초적인 역량이다. 어디에서나 필요하다.

따라서 목표들은 이런 역할을 효과적으로 수행하기 위해서 세우는 것이다.

그래서 이렇게 세운 목표는 한주 달성하고 끝이 아니라 계속해서 이어져야한다.

하지만 한달쯤 되어가다보니 이전 주에 세웠던 목표들을 제외하면 이전 목표들이 흐릿해져가는 경향이 있는 것 같다.

이 글에서 다시 새겨보며 맥락을 계속해서 가져가고자한다.

아래의 것들은 계속해서 지속해 나가야하는 목표이자 하나의 교훈이라고 생각한다.

목표

1. 문제가 무엇인지 정확히 파악할 것 (그 전까지 코드를 보기보다는 문제를 더 잘 정의할 것)

2. 문제를 파악할때, 문제 해결에 필요한 것들이 무엇이 있을지 생각해볼 것

3. 시간 측정에 대한 정확도를 높힐 것(뽀모도로 방법론 - 계획시간을 더 잘 쓸 것)

4. 코드 컨벤션을 파악해서 쪼갠 문제 푸는 시간을 줄일 것

5. 어떤 것이 확인이 필요한지 생각을 문서로 정리하고, 마친 뒤 빠진 것은 없는지 다시 확인할 것

6. 할 수 있는 것과 없는 것을 빠르게 확인하고, 할 수 없는 부분에 대해 물어봐서 낭비되는 시간을 줄일 것

7. 문제가 안풀릴 때, 새로운 상황이 추가됐을 때는 빠르게 전체적으로 확인해보고 필요 시 기존 뷰를 빠르게 버리고 새롭게 시작할 것

8. 코드/맥락 파악시-소통시에는 그림을 적극적으로 사용할 것

9. AI를 활용해서 생산성을 높히기 위한 방법/툴 도입할 것

10. UI 퍼블리싱시 정확성을 위해 설계-코드작성-확인을 작은 단위로 진행하며 정확성 향상

11. 프로덕트 컴포넌트에서는 화면 기반의 추상화, 간단명료한 인터페이스를 구성할 것

12. CSS이론을 학습해서 최적화할 것

당근 인턴 회고 - 3주차

_0422 — Sun, 23 Feb 2025 18:55:38 +0900

내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.

점점 시간이 빨리 간다. 3주차가 지나갔다.

돌아보기

쪼갠 문제를 푸는 시간

이 기능을, 이 코드를 여기에 두는게 맞는가? 고민하는 시간을 줄이고자 했는데, 관련해서 직접 물어보고 한번 정리를 해서 시간을 조금 단축 시킬 수 있지 않았나 싶다. 사실, 이번 주에는 새롭게 컴포넌트를 짤 일이 거의 없었어서 그렇게 느끼는 것일 수도 있다.

아마 이 목표는 다음 UI작업을 하게될 때 한번 더 되돌아볼 필요가 있다.

그래도 하다보니 5번 중에 한번은 맞게 예측하는 경우도 생기는 것 같다.

사실 예측이라는게 기존 데이터가 있어야 가능한건데, 이전에 본격적으로 측정한 경험이 없어서 어려운 것도 있는 것 같다.

우선 이건 한 주만에 해결되는 문제는 아니다. 우선은 측정을 꾸준히 잘 해볼 필요가 있다.

보다 꼼꼼하게

필요한 것들, 체크해봐야 할 것들을 노션이나 PR에 쓰면서 이해하고 체크하니 확실히 효율성이 올라갔다.

역시 뇌에 두기보다는 밖으로 내놓을 때 효율성이 올라간다.

또한 만들어야 하는 기능 Figma가 있다면 그 부분을 정확하게 캡처하고, 개발한 내용을 캡처해서 표로 비교해보는게 직방이라는 것을 알게 됐다. 간편하되, 꼼꼼함도 챙길 수 있는 방법이다.

또 개발하면서 드는 생각들도 챙기면 더욱 꼼꼼함을 챙길 수 있다!

도움을 빨리 구하기

이전 주보다 물어보기까지 걸리는 시간 낭비가 많이 줄었다. 혼자 할 수 있는 것들과, 판단할 수 없는 context가 필요한 것들을 어느 정도 구분할 수 있게 됐다. 또, history를 따라가야하는 경우, 관련 용어 등을 미리 물어보고, 확인해서 commit이나 PR을 확인하면 좋다.

잘한 점

뽀모도로 타이머 도입

시간 측정을 위해서 25-5 뽀모도로를 도입했다.

다만, 5분 쉬는게 아니라(화장실은 가기도하지만), 5분간 다음 뭐할지를 생각하고 작성한다.

물론 완벽하게 지키지는 못했지만, 그래도 하루가 끝나고 일주일이 지났을 때 내가 무엇에 얼마만큼의 시간을 투자했는지 확인할 수 있게 됐다. 이게 시간 예측의 첫 발판이 아닐까 싶다.

꾸준히 이어가자.

그림그리기

이전 주보다 그림을 그리는 시간이 늘었는데, 이건 두 가지 측면에서 굉장히 좋았다.

1. 내 의견을 전달하기 위해서

그냥 말로 설명하는 것보다 그림을 그려서 설명하면 훨씬 직관적이고 의사소통이 간결해진단 걸 느꼈다.

그림을 그려서 설명하면 시간이 더 걸리는 것 같지만, 사실은 소통 문제를 해결해주기 때문에 시간을 훨씬 아껴주는 방법이다.

2. 빠른 이해를 위해서

역시 머릿속에서 하는 것보다는 손으로 그리고 써야 효율이 좋아진다. 보통 복잡한 기능을 만들 때, 먼저 그림을 그리고 만들고는 한다.

이미 작성되어 있는 코드도, 이전에 누군가 고민해서 작성한 코드다. 그러므로, 코드란건 이미 누군가 그린 그림이다.

따라서 기능을 유지보수하거나 고칠때는 그 고민을 따라가며 그림으로 시각화하다보면 거의 3배는 빨리 이해할 수 있게 된다.

빠른 이해는 추가적인 고민을 할 수 있게 만들고, 더 다양한 조건을 체크할 수 있게한다. 결국은 프로덕트의 완성도를 올릴 수 있게 된다.

개선이 필요한 것들

문제가 안풀릴 땐, 차분하게 돌아보기

보통 문제를 풀때 좁히면서 풀게된다. 마치 깔데기처럼.

깔데기식으로 접근하면 점차 좁혀가면서 시간을 줄일 수 있지만, 좁힌 상태에서 다음 스텝으로 나아가지 못하고 있는 경우 정말 많은 시간을 허비하게 된다는걸 느꼈다.

이런 상황은 크게 두 가지가 있었다.

1. 윗단계에서 잘못 분류한 경우

물론, 정확하게 분류해서 좁혔다면 그럴 일은 없겠지만, 사람인지라 윗 단계에서 고려하지 못한 것들이 있을 수 있다는 것을 항상 생각해야한다.

좁힌 상태에서 생각하는 것은 다른 것을 생각하지 못하게 만든다.

너무 많은 시간을 썼다 싶다면, 가설을 폐기하고 다시 구조를 잡고 다른 조건은 없는지 재접근해볼 필요가 있다.

빠르게 전환해서 확인해야 효율성을 높힐 수 있다.

2. 새로운 상황이 추가된 경우

기존 상태에서 새로운 것이 추가되었다면, 기존 뷰를 위에서부터 다시 바라봐야한다.

좁힌 상태에서 고쳐나가려고 하다보면 하나를 고치면 다른 문제가 생긴다.

예를들어 유틸 함수를 위한 타입 설계를 할때 사용하는 곳에 맞춰서 타입을 좁혀 놓았는데, 사용하는 곳이 더 넓은 타입을 요구하는 경우, 파일마다 대응하려고 하면 아래와 같은 상황을 맞이할 수 있게 될 것이다.

이건 위에서부터 바라보지 않으면 절대로 풀 수 없는 문제다. 그림과 마찬가지로 시간이 더 오래걸릴 것 같아도, 좁혀진 뷰를 버리고 다시 넓은 뷰를 바라봐야 할 때 다.

느낀점

이번 주에 AI관련해서 팀원분들이나 다른 분들이 어떻게 사용하고 계시는지를 어깨너머로 알 수 있었는데 AI툴을 좀 더 잘 써봐야겠다는 생각이 들었다.

얼마나 쓰느냐가 아니라 어떻게 쓰느냐가 중요하다. (우선 gpt를 유로로 전환했다...)

나는 거의 리서치나 코드 품질, 공식문서 대신읽히기로 쓰고있는데

외에도 시간 측정이나, 업무 테스크 분류/체크에 AI를 도입할 수도 있을 것 같다.

이건 이번주에 좀 더 고민해봐야겠다.

마무리

저번주에 굉장히 바보같이 일했다면, 이번주는 점점 줄어들고 있는 것 같긴 하다.

물론 이건 환경에 적응해가면서 개선되는 것도 있어서, 위의 문제 해결 과정처럼 좀더 본질적인 것들을 고쳐나가면서 효율적으로 일할 필요가 있다.

그래서 생산성을 향상시키기 위한 이번주 목표를 정리하자면...

1. 뽀모도로 유지 및 좀 더 잘 작성하기 (예측의 시작이 될 수 있는 부분이다.)

2. 문제가 안풀릴 땐 다시 상단부터 다시 좁혀나가기

3. 문제에 새로운 상황이 더해졌을 때 확인해보고 기존 뷰를 빠르게 버리고 새로 시작하기

4. 코드/맥락 파악시 그림을 적극 이용하기

5. AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기 -> 테스크 쪼개기/시간 관리 쪽으로

당근 인턴 회고 - 2주차

_0422 — Sun, 16 Feb 2025 20:58:24 +0900

내용에 문제가 있는 경우 삭제, 수정조치하겠습니다.

순식간에 2주차가 지나갔다.

첫주차는 주저리주저리 다 적었다면 이제는 좀 간결하게 작성해볼 예정이다.

돌아보기

전주에 개선이 필요한 것들부터 돌아보자.

문제가 무엇인지 정확히 파악할 것 (섣불리 코드를 먼저 살펴보지 말 것)

이전보다 확실히 문제를 파악하는 시간이 단축된 것 같다.

이 과정에서 가장 도움이 됐던 두 가지는

이걸 해결해서 어떤 것이 나아지는가를 생각해보는 것, 그리고 그것이 완료되면 문제를 잘게 쪼개는 것이었다.

내가 하는 작업이 어떤 것을 개선시키고 어떤 가치를 가져오는지 파악하고자 할때 문제를 좀더 잘 정의할 수 있게 됐다.

그리고 테스크에서 주어지는 문제들을 다시 잘게 쪼개어 개발 단위로 쪼갰을 때, 확실히 시간이 단축되는 것을 느꼈다.

Context Switch 비용 아끼기 (문제를 파악하기전, 문제 해결 전에 무엇이 필요한지 생각해볼 것)

그렇게까지 명확하게 작성하고 들어간 것은 아니지만, 그래도 어느정도 배치형태로 이뤄질 수 있었다.

그리고 대부분의 세팅을 이번주에 완료해서일까, 아니면 익숙해져서일까?

이건 의도한 것은 아니지만 이전 주보다 확실히 환경구성이나 탐색하는 속도가 빨라졌다.

어쨌든 결과적으로 이슈를 해결하는 시간은 단축되고 있으니...

사실 Context switch만 잘된다면, 굳이 배치형태로 해결할 필요가 없으므로 이건 좀더 두고 봐야 할 것 같다.

시간 측정 정확도 높이기

타이머를 사용해서 시간 측정을 진행하고 있으나, 딱 30분 단위로 진행했더니 다음 어떤 것을 할지 결정해야하는 시간이 들어서 명확하게 시간 측정이 어려웠다.

아침에 모든 것을 기록하고 해볼까도 중간에 시도해봤지만, 사실 중간에 일이 생길 수도 있기에 이런건 어렵다고 느꼈다.

그래서 다음주에는 25-5형태로 25분 몰입하고 5분 다음 할 일을 계획하는 형태로 전환해 볼 예정이다.

또 직접 이걸 타이머로 관리하려니 가끔 놓치는 경우가 있어서, Flow라는 맥북 앱을 사용해볼 것이다.

느낀 것들

말하기

이번주에 주로 느낀 것은 말하기를 좀더 많이 연습 해봐야 한다는 것이다.

내가 어떤 생각을 하든, 글을 어떻게 쓰든, 어쨌든 소통은 말하기에 의해 이뤄지므로 내가 생각한 것을 올바르게 전달할 수 있어야 한다.

예전 면접볼 때 부터 말하기에 약하다는 것을 느끼고 있었는데 밥을 먹거나 커피챗을 할때 그런 말씀을 해주셔서 좀 더 필요성을 느끼게 됐다.

세 분과 관련해서 이야기를 나눴는데 공통적으로 하시는 말씀이 어쨌든 발화량을 늘려나가면서 익숙해지는 수 밖에 없다는 것이다.

업무관련해서 요점을 중심으로 말하는 연습은 물론이고, 스터디에서도 관련된 토론을 하거나 하는 식으로 좀 더 연습을 해서 더 익숙해져야겠다는 생각을 하게됐다.

잘한 것 들

DX에 대한 의견 제시

이전주와 마찬가지로 계속해서 의견제시를 지속하고 있다. 다만 이번주는 DX에 관한 의견제시를 꽤 했고, 거절도 몇 번 있었다.

하지만 나는 거절이 더 중요하다고 생각하고, 이런 경험을 꼭 하고 싶었다.

거절에 대한 근거를 이해하고, 나의 경험으로 만들어갈때, 더 넓은 관점을 갖고, 앞으로 성장할 수 있다.

거절의 근거를 학습하고, 계속해서 더 나은 방향이라 생각하는 의견을 제시하자.

개선이 필요한 것들

쪼갠 문제를 푸는 시간

생각보다 쪼갠 문제를 푸는 시간이 오래걸린다.

이 기능을 여기에 두는게 맞는가? 고민하는 시간이 많았다.

결과적으로 추산시간을 2시간으로 잡았는데 5시간씩 잡고 있게 되는 경우가 있었다.

이건 점차적으로 개선되겠지만, 컴포넌트나 함수를 어디에 둘지 고민하는 시간을 줄일 필요가 있다.

다시말해 컨벤션을 좀더 명확하게 이해할 필요가 있다.

물론 이건 익숙해지면 해결되는,

시간이 해결해줄 문제라고 할수도 있겠지만 인지하고 있는 것과 인지하지 못하고 있는 것은 큰 차이를 가져올 것이다.

추가로, 코드를 작성하는 시간, 진짜 말 그대로 타이핑하는 시간을 줄일 수 있다는 것을 알게 되서, 앞으로는 좀 더 빠르게 문제를 해결할 수 있을 것 같다. (cursor는 신이구나)

보다 꼼꼼하게

내가 생각한 것보다 더 꼼꼼하게 확인할 필요가 있다는 걸 느꼈다.

이건 그냥 피처를 개발할때도 마찬가지고, 나아가 패키지를 바꾼다거나 업데이트하면, 고려해야할 것들이 무수히 많다.

이런 일을 할때는 생각 이상의 세심함과 꼼꼼함이 필요하다.

나는 세심함이 체화된 사람은 아니므로, 세심함을 하나의 형식으로 관리해야한다고 느꼈다.

어떤 것이 변하는지, 어떻게 변하는지, 어떻게 확인할 지를 작성하고, 스스로 체크해야 내 작업의 퀄리티를 보증할 수 있게 된다.

사실 어떤 것을 확인할지,어떻게 변할지를 한눈에 파악하기란 어렵다.

그래서 우선은 과정에서 생각한 것들을 내 머릿속에서 다른 곳으로 이동시킬 필요가 있다고 느꼈다.

그리고 그 기록을 다시 확인하면서, 혹시 다른 경우는 없는지 파악하는 형태로 관리 방법을 바꿔볼 것이다.

도움을 빨리 구하기

괜히 이거 이렇게 하면 되려나? 아니면 물어보는게 더 빠르려나? 하지말고

물어보면 더 빠를 것 같다하더라도 혼자 할 수 있다면 빠르게 시도해보고, 안되는 부분을 정확히 체크해서 물어보는 과정을 빠르게 진행해야 생산성이 올라간다.

물어봐도 되나? 아닌가? 고민하고 코드 확인하고, 하다보면 그게 다 낭비되는 시간이라는 걸 알았다.

결단력 있게 빠르게 실행하고 진행해야 낭비되는 시간이 줄어든다.

마무리

저번주에 양으로 승부해볼 작정이라고 했었는데, 이번주는 정말 양으로 승부했던 것 같다.

꽤 바보같이 일하고 있다고 느끼기도 한다.

뭐 어떻게 보면 바보같이 일하고 있다고 느끼는 것 자체가 나아지는 과정일 수도 있겠지만

어쨌든 계속해서 어떻게 하면 더 개선할 수 있을지 고민해야할 필요가 있다.

그래서 생산성을 향상시키기 위한 이번주 목표를 정리하자면...

1. 시간 측정 25-5 뽀모도로 형태로 전환

2. 코드가 위치해야하는 곳 파악 (컨벤션 파악)

3. 확인해야하는 것들을 작업을 하면서, 떠오르는 대로 문서로 정리하고, 작업을 마친 뒤 빠진 것은 없는지 다시 확인

4. 할 수 있는 부분 빠르게 확인하고, 할 수 없는 부분에 대해 물어보기

당근 인턴 회고 - 1주차

_0422 — Sun, 9 Feb 2025 02:02:48 +0900

내용에 문제가 있는 경우 삭제, 수정조치하겠습니다.

드디어 당근에서 일해보다

나에게 당근은 꼭 일하고 싶은 회사였다.
기술적인 부분도 분명 있지만, 무엇보다 프로덕트 자체가 로컬 플랫폼이기에, 삭막해져가는 사회에 동네라는 가치를 만들고 사람들과 사람들을 이어준다는 가치에 크게 공감하고 있기 때문이다. 이건 있다 설명할 당근에서의 이름인 Manolin과도 이어진다.

또한, 내가 유튜브, 인스타 다음으로 많이 사용하는 앱이기도 하기 때문에 제품에 대한 애정과 오너십을 가질 수 있겠다는 생각에서 재작년 12월부터 계속해서 공고가 올라올때마다 도전하고 있었다.

세 번의 면접 불합격

그래서 그전까지 인턴 포지션이 열릴 때마다 지원했다.
아마 이번에 떨어졌어도 또 적었을 것이다.

하지만 되돌아보면 불합격도 하나의 피드백이었던 것 같다.
면접과 서류를 복기하고 어떤 것들이 부족했는지 스스로 되돌아보며 부족한 점들을 채워갔다.

첫번째 탈락에서는 경험의 부족을 느꼈고
두번째 탈락에서는 왜? 에 대한 근본적인 물음이 부족하단 것을 알게 됐다.
세번째 탈락에서는 코드 작성에 대한 원칙이 부족하구나를 알게 됐다.

그리고 이것들을 채워가기위해 노력했다.

합격

3개월 체험형 인턴이었지만 합격했을 때, 대학 합격 했을 때 보다 기뻤다.
당근에서 일 해 볼 수 있다는 사실과 더불어 그간의 노력이 헛되지 않았음이 증명된 것 같아서 너무 기뻤다.

Manolin

지금까지 영어 이름을 가져본적이 없어서 새로 이름을 지어야했다.

항상 당근에 들어오게 된다면 노인과 바다에서 이름을 따오고자 다짐했었다.

노인과 바다는 불합리, 부조리에 맞서는 인간의 의지를 다루고 있는데,

노인이 청새치를 잡으려는 과정이 마치 사람의 인생 그 중에서도 창업과도 비슷하다고 느꼈다.

생각하지 못했던 것들에서 문제가 생기고, 내 뜻과 다르게 일어나는 이해하기 힘든 불행한 일들이 많이 있다.

청새치는 잡기 힘들고, 과정에서 손이 다 망가지기도 한다.

그렇게 힘들게 잡은 청새치라 해도, 상어가 나타나면 뼈만 남게될 수도 있다.

그럼에도 우리는 다시 사자 꿈을 꿀 수 있는 존재다.

그래서 이런 불합리 속에서도 강한 의지를 보여주는 두 사람 중 한 명을 고르고자 했다.

이중에서 노인(Santiago)이 아닌, 소년(Manolin)을 선택한 이유는 두가지 이유가 있다.

첫째로는 당근에서 다른 분들께 많은 것들을 배우고자 했다. 일하는 방식도 있겠지만, 제품에 대한 의지와 그것들이 표현되는 방법들을 배워가고싶었다.

두번째는 마놀린이야 말로 노인이 강한 의지를 유지할 수 있는 이유였기 때문이다.

어떤 대상, 의미, 가치를 추구한다면, 그것에 가치를 부여하는 사람은 나이다.

그래서 내가 생각을 바꾸면 그것은 언제라도 무가치해질 수 있다.

내가 중요하다고 생각하는 것들은 언제라도 내가 중요하다고 생각하지 않게 되면 중요하지 않은 게 된다.

따라서 인간이 혼자서 독립적으로 지향하는 대상은 언제라도 무의미로 사라져버릴 수 있다.

하지만, 나에 의해 유일하게 가치를 잃지 않는 것이 하나 존재한다.

그건 바로 타인이다.

타인은 나처럼 주관적 판단을 하며, 이에 따라 의미를 부여한다.

그래서 타인은 내가 의미 없다 생각하는 것들에 의미를 부여해줄 수 있는 유일한 존재다.

그래서 나의 의미가 타인에게 전달되고 공감을 이끌어낼 수 있다면,

내가 추구했던 것들은 더 이상 무의미하지 않은 것이 되어 의미를 유지할 수 있게된다.

나의 의미가 타인에게 전달되고, 공감이 있는 순간 그 의지는 더욱 강해지고 함께 나눌 수 있는 것이 된다.

그래서 나는 사람들이 서로가 서로의 마놀린이 될 때, 허무주의가 사라지고 더 따뜻한 세상이 될것이라 믿는다.

추가로

당근은 동네 이웃을 연결한다는 점에서 이웃들이 서로가 마놀린이 될 수 있도록 하는 서비스라고 생각한다.

그래서 그런 서비스를 만드는 과정을 꼭 경험하고 싶었다.

꼭 일해보고 싶었다.

첫 일주일

일주일동안 팀원들과 이야기도 나누고, 필요한 것들을 배우고, 나에게 배정된 일들을 수행했고, 그 과정을 돌아보려 한다.

팀

우선 팀에 조금씩 적응해 나가고 있다.
영어이름으로 부르는게 처음엔 정말 어색했지만, 이젠 좀 많이 익숙해졌다.

스몰토크를 잘하지 못해서... 걱정이었는데 잘 챙겨 주셔서 다행이었다. 특히 밥 먹으면서 보드게임을 했던게 재밌어서 기억에 남는다.
스카우트라는 보드게임이었는데 굉장히 재밌었다!

문화

문화에 대한 세션도 들었는데, 토론식으로 진행했어서 당근이 현재에 이르기까지 문화에 대해 어떤 고민을 해왔는지 짧은 시간동안 간접적으로 고민할 수 있었다.

이전까지는 항상 지원자 입장에서 회사 문화에 대해 생각했다면, 회사입장에서 문화에 대하 고민할 수 있게 됐다.
무엇보다 한국 it회사들의 기본적 문화가 어디에서 왔는지도 알 수 있어서 너무 의미 있는 경험이었다.

https://www.slideshare.net/slideshow/freedom-responsibility-culture/49159844

넷플릭스의 문화 : 자유와 책임 (한국어 번역본)

넷플릭스의 문화 : 자유와 책임 (한국어 번역본) - Download as a PDF or view online for free

www.slideshare.net

업무 회고

첫날은 온보딩 문서를 읽고, 세팅을 하느라 정신이 없어서 뭔가 하진 못했던 것 같다.
두번째날부터 싱크를 통해 이슈를 할당받기 시작했고, 자잘한 것들을 포함하면 6개정도의 이슈를 해결했다.

과정에서 느낀 것들, 잘한 것들, 개선이 필요한 부분들을 되돌아 보려고한다.

느낀 것들

1. MAU 2000만인 앱의 서비스를 배포한다는 책임감, 자부심

내가 방금 작성한 코드가 MAU 2000만인 앱의 일부로 배포된다는 점이 엄청난 책임감을 갖게 만들었다.

할당된 테스크를 한다는 건 인턴이 할 수 있는 일이지만, 테스크로 만들어진 결과, 즉 서비스는 모든 이용자에게 전달된다.

지금까지 했던 어떤 개발 작업물보다 많은 사람들에게 전달된다.

나의 테스크가 사용자 경험을 좌우하고, 서비스와 팀에 대한 인식으로 이어진다.

그래서 첫 이슈를 해결하는데 작동 되는지를 20번도 넘게 확인했다.

덕분에 마지막에 문제가 있다는걸 찾아낼 수 있었고, 고쳐서 배포했다.

정말 다행이었다.

지금까지 가져본 어떤 것보다 무거운 책임감을 가질 수 있었고, 앞으로도 가져야 한다.

이런 경험들을 인턴인데도 할 수 있음이 굉장히 좋았다.

무거운 책임감 덕분에 첫 배포 후 에러 없이 잘 작동할 때의 만족감과 자부심도 이전까지와는 비교할 수 없었다.

굉장히 즐거웠다.

2. 오너십(팔로워십)

당근에서는 대부분의 정보에 자유롭게 접근할 수 있고, 위클리를 통해 많은 정보와 교훈을 얻을 수 있다.

이렇게 획득되는 정보들이 하는 일에 대한 오너십을 갖게 만들어 준다는 걸 느꼈다.

첫 회사에서 일할 때는 특수한 상황이라 가끔 내가 무엇을 개발하는지를 하는지 파악하기 어려울 때가 있었다.

이건 뭐랄까... 야구 룰을 모르는 상태로 도루를 하는 상태와 같다고 생각한다.

이 일을 왜 해야하는지 아는 것이 오너십을 갖게 한다.

그리고 팔로워의 오너십이야말로 팔로워십이 아닐까 라는 생각도 하게 됐다.

왜 이 테스크를 해야하는지 이해하고, 테스크에 대해 더 나은 의견과 방향을 제시하는것

이것이야말로 팔로워십이 아닐까?

3. 자동화/ 코드베이스

대부분의 관리가 필요한 작업들이 스크립트를 통해 자동화되어있었다.

대부분의 것들이 연동되어있고, 아주 편리하게 사용할 수 있었다.

코드베이스를 봤을 때도 역시 얼마나 많은 고민이 담겼는지 느낄 수 있었다.

나도 다른 분들이 봤을 때 빠르게 이해할 수 있고, 유지보수하기 좋은 코드를 작성하기위해 노력해야겠다 다짐할 수 있었다.

또 추가로 자동화 할 수 있는 것들이 생긴다면 꼭 기여해보고싶다고 느꼈다.

잘한 것들

조금 더 빠른 적응

이전 인턴 경험 덕분에 이전보다 훨씬 빠르게 이슈를 이해하고,

보다 나은 코드를 작성할 수 있었던 것 같다.

이슈에 대한 개선 의견 제시

이슈를 그냥 해결하기보다는 도메인이나 UX에 대한 질문, 의견을 제시했고,

결과적으로 이런 행동들이 조금 더 향상된 결과를 가져왔던 것 같다.

개선이 필요한 것들

프로덕트를 위해 기여하는 방식은 여러가지가 있겠지만,

가장 중요하고 핵심이 되는 기여 방식은 팀이 나에게 기대하는 것을 해내는 것이다.

물론 뭔가 일을 찾아서 개선해내는 것도 중요하지만, 우선 나에게 주어진 일을 잘 해내는 것이 우선이다.

그리고 그 프로세스를 더 빠르게 해낼 필요가 있다.

문제가 무엇인지 정확히 파악할 것 (섣불리 코드를 먼저 살펴보지 말 것)

이슈를 해결하다보면 어느 정도 조건이 정리됐다면, 아 이제 코드를 보면 더 빨리, 그리고 더 잘 이해할 수 있겠지?

라는 생각에 코드를 봤었다.

그러나 이때는 사실 도메인 조건을 완벽하게 이해하지 못했을 때가 더 많았던 것 같다.

이건 문제를 정확히 파악하지 못한 것이다.

즉, 안다고 생각했지만, 실제로는 알지 못하는 상태가 됐던 것이다.

문제가 뭔지 정확히 모르는데, 문제를 해결하려 하는 건 말도 안되는 욕심이다.

이러한 과정을 겪으며 테스크 해결에 걸리는 시간이 지체된다고 느꼈다.

그래서 코드를 보기전에 내가 풀려는 문제가 무엇인지 정의해보고, 이를 위해 필요한 도메인에 대한 것들, 배경지식들을 완전히 글이나 그림으로 정리할 필요가 있다고 느꼈다.

Context Switch 비용 아끼기 (문제를 파악하기전, 문제 해결 전에 무엇이 필요한지 생각해볼 것)

분석 중이나 개발 중에 추가적인 셋팅이 필요하다거나, 새로운 라이브러리를 학습할 필요가 있다거나 하는 경우가 있었는데, 이때 많은 시간이 지체되는 것을 느꼈다.

나는 멀티테스킹이 안되는 사람인가보다.

위 상황이 일어날때마다 context 전환이 일어나며 맥락을 잃었고, 다시 돌아왔을 때 어디까지 했었는지 까먹어서 다시 수행하기도 했었다.

특히 모르는 상황, 라이브러리가 등장할 때 이런 맥락 손실을 크게 느꼈다. (모든 맥락 정보 손실...)

그래서 현재 생각으로는 작업이나 분석전에 필요한 것들을 미리 생각해보고, 최대한 모아서 batch 형식으로 쳐내는 것을 떠올렸다.

다음 주에는 이런 방식을 도입해보고, 좀 더 빠르게 문제를 해결하기 위해 노력해볼 것이다.

시간 측정 정확도 높이기

이슈 해결에 대한 예측도도 높이기위해 추산시간과 실제 시간을 대략적으로 측정하고는 있지만,

나는 위에서 쓴 것처럼 맥락 전환시 모든 정보를 잃기 쉬운 사람이라....

다음 주에는 시간 측정을 위해 휴대폰 타이머를 사용해볼 생각이다.

마무리

1주차에 세운 개인적인 목표를 적으며 마무리 해보고자 한다.

최대한 많은 일을 해보고, 경험 쌓기

정말 힘들게 얻은 기회이고, 한정된 3개월이라는 인턴 기간동안 당근을, 그리고 당근 알바팀을 최대한 많이 경험해 보고 싶다.

경험은 양이 될 수 도 있고 질이 될 수 도 있지만, 현재로써는 어떤 것이 질 좋은 경험인지 알 수 없다.

그래서 일단 양으로 승부해볼 작정이다. 일하는게 생각한 것보다 더 즐겁기도 하고...

최대한 많은 일들을, 빠르게 해내고 싶다.

시간이 되는 한 많이 일하고 싶다.

2024 회고

_0422 — Tue, 31 Dec 2024 15:12:39 +0900

벌써 2024년의 마지막날이다.
되돌아보면 이번년도는 꽤 많은 일이 있던 1년이었다.
연초부터 창업 프로젝트가 좌초되고, 수 많은 탈락을 겪기도하고
하필 내가 인턴을 시작했을때 업무강도나 역대급으로 강해지거나... 하는 식이었다.

상반기 목표로 하반기 돌아보기

회사/팀/프로덕트에 기여하기

이 부분은 정말 잘해냈다고 생각한다. 짧은 기간이었음에도 불구하고, 많은 양의 업무를 해낼 수 있었다.
더불어 회사의 lint룰이나, multi-starter cli를 만들어 생산성을 향상시키는 등의 기여를 할 수 있었고, 덕분에 좋은 피드백도 받을 수 있었다.

회사에서 한 경험을 잘 기록하기

이 부분은 완전히 잘한 것은 아니지만, 휘발되지 않을 정도의 정보는 기록해두어서 나의 경험으로 만들어내는데에는 성공한 것 같다. 경험을 블로그에 작성해보기도했고....
다만, 다음 인턴이나, 직무에서는 직무 경험을 좀 더 잘 기록해보고자 한다.
문서화를 좀 더 잘해 보고 싶다.

전체적인 흐름잡기

실무에서 어떤 프로세스로 일하는지를 잘 파악할 수 있었다.
다만, 이 프로세스를 익혀가는 과정이 처음이었고, 잘못 이해해서 시간이 꽤 걸렸었는데, 이 부분은 더 개선이 필요하다.
이 시간을 단축시킬 수록 내가 기여할 수 있는 부분이 커지게 된다.

개발자로 처음 일하는 것이다보니 처음에는 코드가 중요하고, 배포과정이 중요하다고 생각했었는데, 이러한 부분보다는 회사 서비스 도메인에 대한 이해가 훨씬 중요하다는걸 알게됐다.
팀에서 팀원들이 어떤 용어를 어떤 용도로 사용하는지 파악하고, 서비스 도메인에서 이게 얼마나 중요한지를 파악하는게 가장 우선순위가 높다는 것을 알 수 있었다.

독서량 유지하기

하반기 독서량은 두 권으로 얼마되지 않는다.
하지만, 물고기는 존재하지 않는다가 굉장히 많은 가치를 나에게 전달해 주었고, 덕분에 2024년의 혼란스러운 일들을 마음 속으로 정리해낼 수 있었다. 정리해낸 내용은 아래에 좀더 적어보려고한다.

하반기 돌아보기

새로운 도전

회사에서 학습한 것들, 지금까지의 React 경험을 살려 React Native로 관광데이터 활용 공모전에 참여했다.
새로운 부분도 굉장히 많았지만, 이전까지의 경험을 잘 살릴 수 있었고, 프로젝트 관리도 어느정도 잘 해내서 최우수상이라는 굉장히 좋은 결과를 얻어낼 수 있었다.

사실 최우수상이라는 결과보다는 이것을 이뤄내는 과정에서의 성장이 더욱 컸다고 생각한다.
과정에서 프로젝트를 이전보다 더 잘 관리할 수 있었고, React Native로 앱개발을 하고, 원스토어지만 배포까지 해보면서 많은 것들을 학습하고, 성장했다.

나아가 이 경험을 살리고 조금 더 발전시켜서 이전부터 만들고 싶었던 개발자 블로그 앱을 만들어낼 수 있었다.

Dev-Feed

Dev-Feed를 기획, 디자인, 개발, 배포까지 전 과정을 혼자서 진행해보면서 많은 경험과 학습을 할 수 있었다.

아이폰과 안드로이드 유저의 UX차이(바텀시트 등)를 고려해서 어떻게 해야 사용자에게 좀더 나은 경험을 제공할 수 있을까부터
Velog에서의 전환율을 기반으로 인스타그램 광고를 진행하고, GA를 사용한 인스타그램 광고 전환율을 확인해보기도했다.
또 유저 피드백을 받고, 어떻게 개선할지 고민해본 첫 프로젝트기도했다.

결과적으로 Dev-Feed는 나의 첫 100명이 사용하는 앱이 되었고, 2.5달러라는 정말 작은 돈이지만, 첫 매출을 낸 나의 프로덕트가 되었다.
이것 역시 끝이아닌, 또 다른 시작이 될 것이다.

내년 목표

졸업준비

우선은 졸업을 해야한다. 1학기를 남겨두고 있어서 졸업을 준비해야한다. 졸업시험을 봐야해서 준비할 생각이다.
기회가 된다면 남은 한학기도 인턴 대체를 하면서 경험을 더 쌓아가고 싶다.

앱 더 출시하기

Dev-Feed를 출시하면서 앱을 만들어 내는 능력을 꽤 많이 키울 수 있었다.
또한 나는 개발 하는 행위 자체를 굉장히 좋아한다. 그래서 취미활동을 하듯이 개발할 수 있다.
그래서 그냥 취미로 앱을 더 많이 개발하고자한다.

프로그래밍 좀비님을 보면서 사용자가 엄청 많지는 않아도, 작은 앱들을 많이 개발하다보면 용돈 벌이 정도도 할 수 있다는 것을 알게 됐다.
다른게 아닌 취미활동으로 이걸 꾸준히 하다보면 언젠간 좋은 결과가 나올 것이라고 믿는다.
https://soulduse.tistory.com/138

개인앱 300개 만들고 퇴사합니다.

23년 2월 7일 작성한 포스팅 끝자락에 작성한 글이 현실이 되었습니다. 그리고 어찌 운이좋아서 수익이 폭증하게 되면 웃으며 회사를 졸업하는 시기가 더 빨라질수도 있지 않을까? 이

soulduse.tistory.com

또한 과정에서 기술적으로나, 소프트적으로나 더 많이 성장할 수 있을 것이라고 믿는다.
그래서 이번년도 하반기에 2개를 냈으니 내년에는 총 4개의 앱을 더 출시 해볼 생각이다.

개발 도서 읽고, 개발 철학에 대해 고민해보기

엘리스 인턴십을 하고, 어떤게 좋은 코드인지 고민하고 나만의 결론을 내리기까지 굉장히 많은 시간이 걸렸다. (https://0422.tistory.com/375)

이러한 결론이 내려지지 않으면, 혼란스럽기에 코드를 제대로 작성하기 어렵고, 속도를 늦춘다.
개발 도서를 좀더 많이 읽다보면 이런 고민들을 더 빨리 해결할 수 있이다.
또한, 읽다보면 더 다양한 고민들을 하고, 나만의 답변들을 쌓아갈 수 있을 것이라고 생각한다.
이런 답변들은 더 많고 다양한 문제를 해결할때, 큰 도움이 될 것이라 믿는다

그래서 상반기까지 아래 책을 읽을 생각이다.

1. 개발자 원칙
2. 실용주의 프로그래머
3. 쏙쏙들어오는 함수형 코딩

2024년 정리하기

정말 2024년은 다사다난했고, 어려운 일들이 많았고, 마음이 꺾일뻔 한적도 꽤 많았다.
하지만, 덕분에 그럼에도 버텨내는 법을 알게되었다. 어떻게 보면 2024년은 어려움에도 버텨내는 방법을 알려준 해다.
과정에서 읽은 책들이 정말 많은 도움이 되었다.
그래서 이 책들로 2024년을 마무리하고자한다.

인간은 파괴될지언정, 패배하지 않는다 - 노인과 바다

인생의 뜻하지않는 불행, 부조리를 이겨내는 방법은 그럼에도 해내겠다는 강한 의지다.
의지를 가진 인간은 파괴될지언정 패배하지 않는다. 무엇이든, 이겨낼 수 있다.
의지를 잃지 않는다면, 인생의 부조리는 잠깐의 문제일 뿐이다.

의미를 지키기위한 방법 - 물고기는 존재하지 않는다.

물고기는 책의 인물이 한 생을 바쳤던 하나의 분야이자, 관심대상이다. 전 생을 바쳐 연구했다. 하지만 어류라는 종은 사실 존재하지도 않았고, 이런 의지가 우생학으로 이어져 잘못된 길로 나아가게된다. 물고기는 인물에게 하나의 의미이자, 의지였다. 하지만 그것으로 인해 완전히 잘못된 방향으로 나아가게되었다.

노인과 바다를 읽으면서 강력한 의지는 안정감을 주니까. 행복할 수 있을 것이라고, 그것이 행복이라 믿었다.
의미는 여러가지가 있지만, 나는 언젠가부터 자연스럽게 한 개인의 주관적 삶이 하나의 의미로 유지될 수 있고, 그것이 더욱 강력한 의지를 줄 수 있을 것이라 믿었던 것 같다.

하지만 개인의 인생에서 강력하고도 완벽한 하나의 의미란 존재하지 않으며, 추구해서도 안된다.
상대적으로도 절대적, 객관적인 진실은 없지만, 주관적으로도 그런 하나의 절대적 의미는 존재하지 않는다.

개인에게 강력한 절대적 의미가 없다면, 강력한 의지도 얻을 수 없다.
물론 순간순간 좋은 것들, 하겠다는 의지가 생길 순 있지만 그것은 언제라도 사라질 수 있는 휘발성 짙은 것들이다.
그렇다면 인간은 패배할 수 밖에 없는가?

어떤 대상을 추구한다면, 그것에 가치를 부여하는 사람은 나이다. 그래서 내가 생각을 바꾸면 그 대상은 언제라도 무가치해질 수 있다.
따라서 인간이 혼자서 독립적으로 지향하는 대상은 언제라도 무의미로 사라져버릴 수 있다.

하지만, 나에 의해 유일하게 가치를 잃지 않는 것이 하나 존재한다. 그건 바로 타인이다. 타인은 나처럼 주관적 판단을 하며, 이에 따라 의미를 부여한다. 그래서 타인은 내가 의미 없다 생각하는 것들에 의미를 부여할 수 있다. 그러면 내가 추구했던 것들은 더이상 무의미의 혼돈으로 빠지지않고 의미를 유지할 수 있게 된다.

내게 모든 것이 무의미해져도, 타인만큼은 독자적으로 발휘하는 자유로 내린 가치판단으로, 그 의미를 지킨다.
그러므로 안정적인 가치란 타인에게까지 연장될 수 있는 가치, 타인이 스스로 동의할 수 있게 하는 가치다.
노인과 바다에서 노인이 보여준 의지는 청세치를 잡겠다는 의지이기도 하나, 자신을 걱정하는 소년을 생각하는 마음에서 나온 의지이기도 했다.

그래서 우리는 서로가 서로를 무의미의 혼돈속에서 지켜주는 연인, 친구, 동료가 되어야한다.
새해 복 많이 받으시길!

로깅과 관심사 분리

_0422 — Thu, 21 Nov 2024 10:09:03 +0900

배경

여러 번의 리젝과 끝없는 기다림 끝에 개인 프로젝트인 dev-feed을 playstore와 appstore에 배포하는데 성공했다...!

그러나 배포가 끝이 아니다.
나는 앞으로도 컨텐츠를 추가할 생각이다.
그중에 하나가 인기 블로그를 제공하는 것인데, 우선 데이터를 모아보고 싶어 analytics로 해당 데이터들을 모으고자 했다.

dev-feed는 react-native로 만들었기에 @react-native-firebase/analytics를 사용하여 google-analytics를 통해 어떤 블로그를 구독했는지를 수집하기로 했다.

그런데, 조금 있다가, 인기 글도 제공하고 싶어졌다.
그래서 뒤늦게 코드를 추가하려다보니, 글조회, 구독 등등... 전반적인 앱의 핵심 기능과 로깅이 붙어있는걸 발견할 수 있었다.
이렇게 관리해서는 이후에 다른 로깅을 추가하고 싶어질때, 추가하는 속도가 현저히 떨어지는 것이 불보듯 뻔했다.

이전 로직

관심사 분리와 레스토랑

관심사 분리는 레스토랑과 비슷하다고 생각한다.
내가 요리를 잘하고, 몸이 컴퓨터 연산속도 만큼 날래서 혼자서 1인 레스토랑을 오픈했다고 했을때,
물론 나혼자 요리를 다하고, 서빙도하고, 테이블 정리도 하고, 계산도 할 수 있을 것이다.

하지만, 더 많은 요리가 추가되고, 요리가 서빙나갈때, 챙겨야하는 것들, 테이블 정리시에 주의해야할것들, 계산시 할인, 단골 혜택 부여 등등...
점점 신경써야하는 것들이 많아지게되면 혼자서는 실수가 많아지고,레스토랑이 아무리 잘되어도 레스토랑을 더 확장하기 어려울 것이다.
특히나 그런 절차가 조금씩 바뀌기 시작하면... 실수를 할 수 밖에 없게된다.

그래서 보통 규모가 있는 레스토랑은 직원들에게 역할을 부여하고, 직원들은 그 역할을 잘 수행한뒤, 다른 역할을 지닌 사람에게 일을 넘긴다.
예컨데 요리사는 요리만한다. 계산을 하지도 않고, 테이블을 치우지도 않는다.

코드도 마찬가지다. 많은 로직을 다짜내고 어떻게든 성공적으로 돌아가면 그 코드 덩어리 하나로 애플리케이션이 동작할 수 있다.
하지만 요리사도 사람이고, 프로그래머도 사람이다. 더 많은 기능, 수정사항을 반영하기 시작하면 실수를 할 수 밖에 없다.
이런 문제를 해결하기위해서는 관심사를 분리하고, 해당 코드가 걸맞는 역할만을 하게 만드는 것이 옳다고 할 수 있다.

의존성 문제

또한 로깅의 의존성 문제도 있었다. GA4를 내가 잘 사용하지 못하는 것일 수 도 있지만, 아무리 탐색탭을 통해 보고서를 만들어도,
기간별 데이터를 쉽게 조회하거나, 로우데이터 자체를 얻기는 힘들었다.

GA4 사용법을 배워나가고는 있지만, 정말 안되겠다 싶을때, 로그서버로 대체해볼 생각도 있다.
그러려면 퍼져있는 analytics코드를 한곳에 모아줄 필요가 있다.

코드 작성하기

type설계하기

우선 로깅할 이벤트를 타입으로 작성해주었고, 이벤트마다 필요한 파라미터를 정의해주었다.
LogEvent를 통해 params에 정의된 key값을 이벤트 종류로 받아올 수 있다.

의존성 모으기

analytics를 사용해서 로깅하는 코드를 log.ts 모두 모아주었다.

그리고 이렇게 만든 함수를 객체 하나에 묶어 내보내주었다.

이러면 로깅 플랫폼을 GA4에서 자체 로그서버로 바꿨을때, analytics부분만 변경해주면 쉽게 변경할 수 있다.

관심사 분리하기

이게 고민했던 부분이다.
로깅과 비즈니스 로직을 어떻게 구분할까?

페이지 전환

페이지 전환의 경우 root의 NavigationContainer에 이벤트를 주고, 이전 경로와 변경이 일어났을때, 로깅하게 만들면 페이지 전환은 더이상 신경쓸 필요가 없다.

다른 로깅

그런데, 앞서 로깅하려고 했던 블로그 구독 로깅, 글 조회로깅은 어떻게 비즈니스 로직과 구분할 수 있을까
이런 로깅은 공통적으로 사용자의 상호작용, 그중에서도 클릭에 의해 발생하는 이벤트를 기록하는 것이다.
따라서나는 이를 LogClick이라는 컴포넌트로 만들고, 이벤트 종류에 따라 다르게 동작하게 만들어줄 것이다.

이전에 설계한 타입을 기반으로 LogClick에 전달해줄 props타입을 정의해준다.
간단하게 로깅할 이벤트 종류를 뜻하는 logType과 그 타입에 맞는 data를 props로 받도록 해주었다.
type으로 정의해두었기에, typescript에 의해 추론이 가능해진다.

export type LogParamsType = {
  subscribe: string;
  unsubscribe: string;
  viewPost: Article;
  screen: {
    screenName: string;
    screenClass: string;
  };
};

export type LogEvent = keyof LogParamsType;

//여기까지 이전에 설계한 type

interface LogClickProps<T extends LogEvent> {
  logType: T;
  data: LogParamsType[T];
}

이제 LogClick을 만들어주었다.
중요한 것은 어떤 컴포넌트인지와 관계없이, children을 그대로 내보내주되, onPress에 로깅 이벤트를 추가해주어야 한다는 것이다.
cloneElement를 통해 children을 복사하고, onPress이벤트를 추가해주는 형태로 구현해주었다.

export default function LogClick<T extends LogEvent>({
  logType,
  data,
  children,
}: PropsWithChildren<LogClickProps<T>>) {
  if (!isValidElement(children)) {
    return children;
  }

  const childWithPress = cloneElement(children as ReactElement, {
    onPress: () => {
      children?.props.onPress();
      Log[logType](data);
    },
  });
  return childWithPress;
}

정리

이제 비즈니스 로직과 로깅로직이 분리되었다.
에러처리는 Errorboundary를 통해 분리되어있으므로,
이제 비즈니스 로직은 성공한 경우에 대해서만 다루게되고, 오류는 Errorboundary에 의해, 로깅은 LogClick에 의해 관리되게 된다.
요리사가 더이상 서빙과 계산을 하지 않게 되는 것이다.

Android
https://play.google.com/store/apps/details?id=com.devfeed

Dev-Feed - Google Play 앱

개발 블로그 RSS 구독 서비스

play.google.com

iOS
https://apps.apple.com/kr/app/dev-feed/id6737579223

‎Dev-Feed

‎개발 블로그, 이제 한 눈에 확인하고, 구독해보세요. Dev-Feed로 나만의 기술블로그 피드를 만들어봐요 Dev-Feed는 사용자가 쉽게 RSS를 구독하고, 구독한 블로그로 접속할 수 있게 돕는 어플리케이

apps.apple.com

좋은 코드를 작성한다는 것, 그를 위한 노력에 대한 고민

_0422 — Mon, 18 Nov 2024 18:24:37 +0900

고민의 시작

이전부터 좋은 코드란 무엇인지 고민해왔다.

이런 고민은 팀원과 함께 협업하여 개발해야했던 인턴을 진행하면서 좀 더 심해졌고, 정리되지 않은 상태였다.

이번 글로 하여금 생각을 정리해보고자한다.

좋은 코드를 작성하는 방법이라기보다는, 조금 더 근본적인 이해와 내가 해야하는 노력에 대한 글이다.

좋은 코드?

좋다라는건 참 모호하다.

좋은 사람은? 좋은 인생은? ~에가 빠진 좋다 라는 가치판단은 머리를 점점 혼란스럽게 할 뿐이다.

목적을 따져보기

목적을 따져보자. 코드는 왜 쓰는가?

코드는 불편한 문제를 해결하고, 자동화하여 가치를 제공하기 위해 만들어진다.

이런 관점에서는 좋은 코드를 따질 필요는 없다. 왜냐하면 완벽한 제품을 한번 만들면, 더이상 바꿀 필요가 없기때문이다.

하지만, 현대 사회에서 불편한 것들, 수요는 빠르게 생기고 사라진다.

그래서 제품을 한번 만들고 마는 것이 아니라, 지속적으로 관리하고, 새로운 것들을 추가해야한다.

코드를 통해 개발자는 제품에서 존재하던 오류는 없애고, 이를 통해 지속적으로 가치를 제공하며 새로운 것들을 추가할 수 있어야한다.

그래서 보통 좋은 코드라 함은 유지보수하기 좋은 코드를 말한다.

물론 여기까지도 혼자 개발을 한다면, 그다지 중요하지 않다.

일기장에 글씨체를 어떻게 쓰던, 글을 어떻게 쓰던,

어쨌든 일기장은 나만 알아볼 수 있다면 아무 상관 없는 것 처럼 미래의 내가 알아볼 수 만 있다면 괜찮다.

하지만 규모가 몹시 큰 제품을 혼자서 유지보수하는 것은 물리적으로 불가능하다.

모듈이 10만갠데, 제품에서 발생한 모든 오류를 혼자서 고치고, 새로운 기능을 추가한다는건, 정말 물리적으로 불가능하다.

따라서 여러 명이 유지보수 할 수 있어야한다.

그렇다면 나말고도 다른 사람이 잘 읽을 수 있어야한다.

그렇다면 좋은 코드란, 다른 사람이 잘 읽을 수 있고, 기능을 추가하기 좋은 코드를 말한다.

이 기능을 추가하기보다는 잘 읽을 수 있어야 한다에 집중해볼 것이다.

잘 읽을 수 있다.

추상화와 개념

아래 두 가지 글 중 어떤 것이 바로 이해가 되는가?

1. 민수는 동쪽으로 100m 이동한 후 우회전하여 200m를 이동하고, 다시 좌회전 하여 20m이동하여 다수의 사람들과 함께 학습할 수 있도록 마련된 장소에 가는 중이다.

2. 민수는 학교에 가는 중이다.

아무래도 두번째가 곧바로 이해된다. 그렇다면 두번째가 옳은가?

실제 코드에서는 아마 아래처럼 코드를 짤 수 있을 것 같다.

function 학교로가기(학생){
	학생.동쪽전환()
    학생.이동(100)
    학생.우회전()
    학생.이동(200)
    학생.좌회전(20)
}

const 민수 = new 학생()
학교로가기(민수)

하지만 여기서 문제는 학교가 뭔지, 민수가 무엇인지 모두가 알고 있어야한다.

이건 일상에서 자주 사용하는 개념이기에 이런 것들이 바로 와닿지는 않는다. 개념을 조금 더 극단적으로 바꿔보자.

AWS CLI SDK로 S3버킷에 빌드된 웹서버 번들파일을 업로드한다.

AWS를 자주 사용한 사람이라면, 익숙한 문장일 수 있겠지만 AWS사용을 한번도 해보지 않은 사람은 이 문장이 의미하는 것을 바로 파악할 수 없다. 이건 추상화된 문장이다.

CLI, SDK, S3버킷, 웹서버, 빌드, 번들파일이라는 단어는 일상에서 자주 사용되지 않는 단어다.

이런 단어로 추상화된 문장을 배경지식이 없는 사람이 이해하는 것은 어렵다.

즉, 추상화는 일반적으로 알 수 있는 배경지식을 통해 이뤄져야한다.

또는 함께 코드를 작성하는 사람들이 가진 배경지식을 기반으로 진행되어야한다.

같은 배경지식을 갖기위해서는 계속해서 제품과 코드에 대해 의견을 나누어야 한다.

그렇지 않으면 점차적으로 파편화된 배경지식을 갖게되어 특정 사람, 특정 집단만 이해하는 추상화가 될 수 있다.

추상화의 정도

사용자가 접하는 추상화와 개발자가 다뤄야하는 추상화의 정도는 다를 수 있다.

엘리베이터를 예시로 들어보자.

사용자

엘리베이터 사용자는 추상화된 버튼을 눌러 목적지에 도착하면 된다.(2층을 눌러 2층으로 이동)

엘리베이터 사용자는 엘리베이터가 어떻게 동작하는지 알 필요가 없다. 그냥 버튼을 누르고 기다리고, 내리면 된다.

설계자/유지보수자

엘리베이터 설계자/유지보수자는 2층 버튼을 눌러 도착하는 추상화를 제공하는 사람이다.

2층이 몇 미터인지, 어떻게 층을 나눴는지, 도르레를 얼마나 움직여야 하는지, 최대 하중이 얼마인지를 알 필요가 있다.

하지만, 엘리베이터 설계자는 도르레가 어떻게 설계되었는지는 알 필요가 없다. 물론 알면 더 튼튼한 엘리베이터를 만들 수 있을지도 모른다.

혼란

엘리베이터 사용자에게 엘리베이터 설계자만큼의 추상화를 제공하는 것은 엘리베이터 사용을 어렵게 한다.

엘리베이터 설계자에게 엘리베이터 사용자에게 제공하는 버튼만 제공하는 것은 엘리베이터 설계를 어렵게 한다.

그러나 개발자는 제품의 복잡성이 올라감에따라 코드를 작성함과 동시에 소비하기도한다.

코드를 작성하는 사람 입장에서 만들어진 함수와 라이브러리를 사용한다면, 엘리베이터 사용자의 입장이 될 것이고,

핵심 로직을 작성하거나 유지보수하게된다면 엘리베이터 설계자의 입장이될 것이다.

따라서 제품을 만드는 개발자는 이 둘을 동시에 만족시켜야 하는 것이다.

추상화의 위치

개인적인 경험

이 두 가지 관점을 오가다가 헤매게 되면 주화입마에 빠지게 되는 것 같다.

어떻게 추상화된 영역을 분리할지가 모호함에 따라 주장이 약해졌고, 어찌됐던 컨벤션을 따르긴하는데 만족스럽지는 않은? 그런 상태가 됐었던 것 같다.

로직 부분을 컴포넌트에서 작성하는 경우가 많았는데, 해당 부분이 추상화가 되지 않았다고 느꼈다.

그렇다고 로직을 모두 분리하자니 파일이 어디에 무엇이 있는지 정리되기가 어려워진다고 느꼈다.

빠른 개발을 위해서 추상화 하지 않고, 공통 컴포넌트로 분리하려고 하니 불가능한 일에 가까웠다.

결과적으로 혼란을 가져왔다.

영역을 분리하기

명확하게, 설계 부분, 사용 부분을 분리하고 지킬 필요가 있다.

모든 설계부를 모두 라이브러리로 분리하면 좋겠지만

오류가 발생했을 때 매번 고쳐서 배포하고, 버전을 올리는것은 다양한 사람들이 유지보수하는 것을 더 어렵게 만든다.

정말 공통적으로 사용되는 부분, 완전히 분리가 된 책임을 지는 기능들만 분리하여 라이브러리로 배포하면 된다. 혹은 모노레포로 관리할 수 있을 것이다.

예를 들어, React는 선언형으로 UI를 업데이트한다는 역할을 수행한다.

물론 직접 함수형 컴포넌트를 호출하는 것도 가능하지만, React는 컴포넌트가 설명만 반환하기를 원하고, 이것을 지켜야 React가 원하는 사용자의 코드를 줄인다라는 목표를 달성할 수 있게된다.

https://ko.legacy.reactjs.org/docs/design-principles.html

그러나 공통적이지 않은 부분은? 어떻게 처리하는 것이 좋을까?

이 부분은 개발을 하는 사람들이 약속해야 한다. 컨벤션을 정해야한다.

그리고 나처럼 새롭게 신입개발자로 회사에 합류하려는 사람은 무작정 회사의 컨벤션을 따르는 것이아니라, 컨벤션에 물음을 던지고 어디가 사용부분이고, 설계부분인지 이해할 필요가 있다.

핵심적인 부분에 대해 물음을 던지지 못하고, 제대로 이해하지 못한다면 이제까지 개발했던 컨벤션과 충돌한다고 느끼게 될 것이고 나처럼 혼란에 빠지게 될것이다.

정리

정리하면, 팀과 함께 유지보수하기 좋은 코드를 작성하기 위해서는

일반적인 개념으로 추상화할 필요가 있다.
불가능하다면, 팀 내부에서 모두가 공유하고 있는 배경지식을 기반으로 추상화 해야한다.
설계자와 사용자에게 적절한 추상화정도는 다르다.
개발자는 코드의 설계자임과 동시에 사용자가 될 수 있다.
어디서 설계할지, 어디서 사용할지를 컨벤션으로 정하고 지키는 것이 매우 중요하다.

좋은 코드를 작성하기위해 회사에 들어가서 내가 해야할 것은

팀 내부에서 공유하고 있는 배경지식, 도메인지식을 빠르게 학습하여 추상화를 이해할 것
팀 내부의 컨벤션의 의도를 제대로 이해하기 위해 계속해서 물음을 던지고, 올바른 의도를 이해하여 지킬 것 (무작정 지키지 않을 것)
추상화 정도와 위치를 항상 고민할 것

위와 같이 정리할 수 있겠다.

웹 브라우저 이벤트루프는 왜 그런 우선순위로 작업을 실행시킬까 (feat. CPU 스케줄링)

_0422 — Tue, 12 Nov 2024 17:54:00 +0900

요즘 OS수업을 듣고 있는데, 프로세스 스케줄링 관련 부분을 배우고 있다.

그러다가 문득, 최근 면접에서 받은, 그리고 제대로 답하지 못했던 이벤트루프는 왜 그런 우선순위로 작업을 실행시킬까? 라는 질문이 떠올라 지금에라도 작성해본다.

서론

동시성

Concurrency(동시성)와 Parallelism(병렬성)

동시성과 병렬성은 같은 단어 같지만, 분명히 다른 단어이다.

동시성은 동시에 실행되는 것 같이 보이는것

병렬성은 실제로 여러 작업이 동시에 처리되는 것이다.

동시성에 대해 말할 것이다.

과거, 코어가 하나인 CPU에서 동시성을 해결하는 것은 매우 중요했다.

안그러면, 하나의 프로세스만 돌릴 수 있을테니까.

JS도 마찬가지다.

Javascript는 싱글 스레드이다. 코어가 하나인 CPU인 것이다.

여기서 우리는 로직 수행도 하고, 네트워크 요청도하고, UI업데이트 명령도 내려야한다.

그리고 모든 작업이 동시에 실행되는 것처럼 보여야한다.

이 두가지 요소를 우선순위라는 같은 관점에서 바라보고, 왜 이렇게 설계되었는지 나름의 답변을 내고자한다.

스케줄링, 우선순위

그래서 CPU는 시분할로 작업을 작게 쪼개고, 이걸 작업을 할당해서 순환시켜가며 실행하는 방식으로 동시성을 제어했다.

이걸 어떻게 할당하냐?가 바로 스케줄링이다.

동시성을 구현하기 위해서는 아이러니하게도 순서가 중요하다.

이때 더 빨리 실행될 필요가 있는 것들, 더 늦게 실행되도 되는 것들, 그리고 총 실행 시간, 스위칭 시간 등등... 수많은 목적들을 고려해서, 목적에 맞게 만들 수 있다.

우선순위에 대해 한가지 예시를 살펴보자.

한가지 예로 time slice형태의 스케줄링에서 throughput을 개선시키기위해서는 CPU Intensive 프로세스와 I/O Intensive 프로세스에 따른 우선순위를 고려할 수 있다.

CPU Intensive 프로세스는 CPU사용률이 높고, I/O 작업량이 적은 프로세스다.

I/O Intensive 프로세스는 CPU사용률이 낮고, I/O 작업량이 많은 프로세스다.

I/O Intensive한 프로세스는 CPU에서 많이 작업될 필요가 없다.

그렇다면 I/O Intensive한 프로세스는 CPU에 할당되어도 빨리 Block상태가된다.

즉 context switch를 줄일 수 있고, 전반적인 대기시간을 줄일 있어 throughput을 증대시킬 수 있다.

따라서 먼저 실행해버리는게 좋을 수 있다. 따라서 이런 관점에서, 우선순위가 높아진다

반대로 CPU Intensive한 프로세스는 CPU에서 많이 작업되어야한다.

그렇다면 이 프로세스는 CPU에서 많이 실행되어야한다. 이건 I/O Intensive한 프로세스의 대기시간을 늘려 throughput을 악화시킬 수 있다. 따라서 우선순위가 낮아진다.

이처럼 어떤 목적에 따라 만들어진 것인가?를 이해하면 우선순위를 이해할 수 있다.

본론

Microtask, Macrotask, rAF

먼저 우선순위를 작성하자면

microtask > rAF >macrotask가되겠다.

왜 그럼 이런 우선순위가 나오게된걸까?

왜 이런 우선순위가 나오게된걸까

왜 그런가에 대해 생각해보려면, 이 관점에서 브라우저가 무슨 일을 주로 하는지 생각해볼 필요가 있다.

CPU스케줄링처럼 동시성을 구현함으로써 얻을 목적을 이해할 필요가 있다.

브라우저는 정말 다양한 일들을 해주지만, 여기서 살펴보아야 할 것은 아래 두 가지일 것이다.

사용자에게 완성된 화면을 보여주어야한다.
초기에 완성된 화면을 업데이트하여 다시 보여주어야한다.

또한, javascript가 실행되는 경우이므로, 1번도 제외된다.

즉, 이 관점에서 브라우저가 하는 가장 중요한 할 일은 업데이트된 화면을 보여주는 것이다.

그리고 세가지 작업의 종류를 간단하게 살펴보자.

Microtask Queue

Promise와 MutationObserver가 이 작업에 속한다.

requestAnimationFrame

request Animation Frame은 브라우저가 리페인트 바로 전에, 애니메이션을 업데이트할 지정될 함수를 호출하도록 요청하는 것이다.

MacrotaskQueue

setTimeout, setInterval이 이에 속한다.

중요한 것을 생각해보기

여기서 사용자의 액션에 따라 업데이트된 화면을 보여줄때 가장 중요한 것은 무엇일까?

보여준다는 부분에서 requestAnimationFrame이 가장 우선순위가 높을 것 같다.

하지만, 업데이트 된에 집중해보자.

그리고 "업데이트"와 "된" 두 가지를 고려해서 생각해보자.

업데이트

화면의 업데이트는 count값을 올리는 것처럼 동기적일 수도 있지만, 서버 데이터를 받아오는 것처럼 비동기적인 작업이 될 수 도 있다.

된

되었다라는 것은 작업이 끝났다는 것이다.

즉, 가장 최신의 데이터를 가져오는 것을 끝내고, 화면을 그려야(업데이트해야) 사용자는 문제없이 제대로된 데이터를 보게될 것이다.

그런데 만약 업데이트의 우선순위보다 그리는 것의 우선순위가 더 높다면?

비동기 업데이트의 경우, 데이터가 최신이 아닌데도, 브라우저는 화면을 그리게 될 것이고, 그럼 유저가 보는 화면에는 문제가 생길 것이다.

그럼 화면을 한번 더 그려야, 제대로 보이게 될 것이다. 이건 효율적이지도 않고, 제대로 작동하지 않을 가능성이 있다.

따라서 그리는 것(requestAnimationFrame)보다 업데이트(microtask)의 우선순위가 높아진다.

또한 자연스럽게 그리는것도, 업데이트라고 보기도 어려운 MacroTask는 자연스럽게 우선순위가 낮아지게된다.

결론

업데이트된 것을 보여준다 라는 목적에 의해,

업데이트된을 담당하는 microtask의 우선순위가 가장 높고,

보여준다 를 담당한다 볼 수 있는 requestAnimationFrame의 우선순위가 다음이고,

이런 목적과 조금 거리가 있는 macrotask의 우선순위가 가장 낮다.

결론으로부터 비롯되는 몇가지 사실

그렇다면

무한히 많은 microtask가 있다면 macrotask는 starve상태에 빠질 수 있다.
무한한 재귀를 가진 requestAnimationFrame이 있어도, repaint시점 직전에 1회 실행되는 것이 보장된다.따라서 requestAnimationFrame은 macrotask를 block시킬 수 없다.

React native Code Push 적용 및 인앱 업데이트시 UX 개선하기

_0422 — Sat, 12 Oct 2024 11:25:15 +0900

배경

2024 관광데이터 활용 공모전에 프론트엔드 개발자로 참여하여 프로젝트를 진행중이다.
앱을 1차적으로 릴리즈하고, 다음 업데이트를 한번 해보니, 스토어 심사를 진행하는 것이 생각보다 시간이 걸리고 불편한 일이라는 것을 느낄 수 있었다.
이런 부분들은 이미 알고는 있었으나, 실제로 경험해보니 더욱 체감이 되었다.

원스토어는 빠른편이다.

웹뷰를 사용하면 해결할 수 있었겠지만, 초기에 웹뷰를 사용하지 않고, RN으로만 진행하기로 하였기때문에, 다른 방법을 탐색해야했다.
그러다 찾은 것이 Code push다.

어떻게 가능한가?

이것을 이해하기 위해서는 RN의 원리에 대해 간단하게 나마 알아보아야한다.

React native의 스레드

React native는 메인스레드, JS스레드, 백그라운드 스레드(Shadow 스레드)로 구성된다.

1. 메인스레드

메인스레드는 UI그리기, 사용자입력처리, 네이티브 이벤트 처리 등 네이티브에서 일어나는 작업들을 수행하는 스레드이다.
애니메이션 전환 역시 메인스레드에서 처리된다.

2. Shadow 스레드

shadow 스레드는 레이아웃 계산을 맡아 컴포넌트 레이아웃을 계산한다. 그리고, 이걸 메인스레드에 전달한다.
Yoga라는 오픈소스 레이아웃 엔진을 사용한다고 한다.

3. JS스레드

이 스레드가 JS번들을 실행한다. 즉, RN으로 작성한 코드가 직접적으로 실행되는 스레드이다.
다만, 이 스레드의 특이한 점은 Hermes라는 JS엔진을 사용한다는 것이다.
Hermes는 다른 엔진과 다르게 JS 코드를 미리 바이트코드로 컴파일한다. 그래서 인터프리터가 컴파일을 하지 않는다. 따라서 이게 성능을 개선하는데 도움을 줄 수 있다.
그리고 스레드들은 Bridge라는 개념을 통해 필요한 정보를 직렬화하여 비동기 통신한다.(non block)

그림으로 그리면 이런 형태로 작동하게되는 것이다.

React native 앱이 실행되는 과정

1. 앱이 시작하며 메인 스레드가 실행된다. 이때 JS번들을 로드한다.
2. JS번들의 로드가 완료되면 메인스레드는 JS번들을 JS스레드로 보낸다.
3. React렌더링이 시작된다.
4. Shadow 스레드가 레이아웃 계산을 마치면 레이아웃 결과물을 메인스레드로 보낸다.
5. 메인 스레드는 Shadow 스레드가 보낸 레이아웃을 렌더링한다.

그렇다면 결국, JS번들과 앱의 메인 스레드 코드는 분리되어있다는 것을 알 수 있다.
그리고, 보통 RN개발자가 작성하는 코드는 JS번들로 결과물이 나오게된다.
그렇다면, JS번들파일을 네트워크를 통해 전달받을 수 있다면, 실시간으로 업데이트 할 수 있게 된다.

환경 구성 및 기본 설정

설정은 공식 문서와 github 레포를 확인하는게 가장 좋다.
특히 공식문서가 매우몹시 친절하게 되어있으므로 따라하기만 하면 적용할 수 있을 것이다.

안드로이드 기준 바꿔준 파일들

배포설정

원래는 appcenter에서 커맨드를 지원해서 이렇게 설정해주면된다.

appcenter codepush release-react -a {user name}/{앱 이름} -d {type(Production or Staging)}

그러나 현재 우리 프로젝트는 yarn workspace를 사용한 모노레포의 형태를 취하고 있기에, 이렇게 사용할 수 없었다.
appcenter 레포와 이슈들을 확인했으나, 번들 entry를 설정해주는 args가 없었다.
그래서 따로 쉘파일을 만들어 주었다.

mkdir CodePush

# 번들 생성
npx react-native bundle \
--entry-file=./index.js \
--bundle-output=./CodePush/index.android.bundle \
--assets-dest=./CodePush/ \
--dev=false \
--platform=android

# codepush 업로드
# t에 타겟 버전(android build)
appcenter codepush release \
-a 유저네임/프로젝트 \
-c ./CodePush \
-d 프로덕션 \
-t 타겟버전
``

rm -rf CodePush

번들을 직접 만들고, codepush로 해당 번들 폴더를 업로드하고, 삭제하는 것이다.
이걸 script에 등록해서 yarn run codepush:android형태로 쓸수 있게 했다.

기본설정

기본설정은 매우 간단하다
App.tsx에서 전체 앱을 CodePush로 감싸주면 된다.

...
import CodePush from 'react-native-code-push';

function App() {
  return (
    ...
  );
}
export default CodePush(App);

이렇게 설정해주면 Codepush는

앱이 실행될때, 번들 업데이트가 있는지 확인하며
있다면 다운받고
다음번에 앱이 재실행 됐을때 업데이트되게 된다.

하지만, 나는 앱이 즉시 업데이트되기를 원했다. 계속해서 개선할 점이 보이고, 그런 부분이 즉시 개선되었으면 했기때문이다.

설정 옵션

Codepush(options)(App)의 형태로 코드 푸쉬가 어떻게 동작할 것인지 옵션을 정해줄 수 있다.

deploymentKey, installMode, mandatoryInstallMode, minimumBackgroundDuration, updateDialog, rollbackRetryOptions, checkFrequency의 옵션이 존재한다.

Codepush 의 d.ts를 읽어보면 내용을쉽게 알 수 있다.

그중 installMode를 변경해주고 싶었는데, 왜냐하면 default가 ON_NEXT_RESTART, 즉 다음번에 앱이 실행될때 업데이트 하는 방식이었기때문이다.

그래서 이런식으로 옵션을 주고

const codePushOptions: CodePushOptions = {
  checkFrequency: CodePush.CheckFrequency.ON_APP_START,
  installMode: CodePush.InstallMode.IMMEDIATE,
};

이렇게 적용해주었다.

export default CodePush(codePushOptions)(App);

이렇게 처리하면, 이제 문제없이 잘 작동할 것이라 생각했다.

문제 발생

그러나 문제가 발생했다.

그것은 바로... 회원가입을 할때 앱 업데이트로 강제 재시작이 되어버리는 것...
이걸 어떻게 풀어낼지 고민했다. 회원가입을 한다 하더라도, 최신 업데이트 버전의 앱은 보여주고 싶었기 때문이다.

CodePush에서 제공하는 함수들

다행히 CodePush는 컴포넌트를 Wrapping하는 방식 뿐만 아니라, 직접 세부 동작을 지정할 수도 있게 만들어져 있었다.
업데이트가 필요한지 확인하는 함수, 번들을 받아오는 함수, 번들을 기기에설치하는 함수 모두 제공한다.

그렇다면 로직은

앱시작시 바로 업데이트가 있는지 확인
있는지 없는지에 따라 최신버전인지 분기
최신버전이 아니라면 번들 다운로드 + 최신 번들 기기에 설치
앱 재시작

이 될 것이다.
그리고 그 과정에서 로딩화면을 보여주면 된다!

아래와 같이 작성할 수 있다.

import { useEffect, useState } from 'react';
import CodePush from 'react-native-code-push';

export default function useCodePush() {
  const [isRecent, setRecent] = useState<boolean>();

  const checkUpdate = async () => {
    const update = await CodePush.checkForUpdate(); //업데이트가 있는지 확인
    setRecent(!update); //최신 상태 변경
    if (update) { 
      const newPackage = await update.download(); //번들 다운로드
      await newPackage.install(CodePush.InstallMode.IMMEDIATE); //즉시 번들 설치
      CodePush.notifyAppReady(); //CodePush에 해당 기기가 최신 버전으로 설치했다고 알림
      CodePush.restartApp(); // 앱 재시작
    }
  };

  useEffect(() => {
    checkUpdate();
  }, []);

  return {
    isRecent,
  };
}

그런데 download메서드가 굉장한걸 지원한다.

바로 번들의 totalBytes와 receivedBytes를 보여주는 것이다.
이걸 활용하면 로딩 프로그래스바를 만들어줄 수 있다.

최종코드

import { useEffect, useState } from 'react';
import CodePush from 'react-native-code-push';

export default function useCodePush() {
  const [isRecent, setRecent] = useState<boolean>();
  const [downloadProgress, setDownloadProgress] = useState(0);

  const checkUpdate = async () => {
    const update = await CodePush.checkForUpdate();
    setRecent(!update);
    if (update) {
      const newPackage = await update.download(
        ({ receivedBytes, totalBytes }) => {
          setDownloadProgress(receivedBytes / totalBytes);
        },
      );
      await newPackage.install(CodePush.InstallMode.IMMEDIATE);
      CodePush.notifyAppReady();
      CodePush.restartApp();
    }
  };

  useEffect(() => {
    checkUpdate();
  }, []);

  return {
    downloadProgress,
    isRecent,
  };
}

이걸 이제 App에 적용해주자.

function App() {
  const { isRecent, downloadProgress } = useCodePush();

  if (!isRecent)
    return (
      <UpdateLoading isRecent={isRecent} downloadProgress={downloadProgress} />
    );

  return (
   ...
  );
}
export default Sentry.wrap(App);

UpdateLoading컴포넌트는 SPOT 레포 github를 참고하면 좋을 것 같다.

엘리스 인턴십 회고

_0422 — Mon, 2 Sep 2024 10:51:50 +0900

엘리스에서 현장실습으로 프론트엔드 인턴십을 진행했다.

중간에는 정리하지 못했으나, 끝난 지금 제대로 정리해보고자 한다.

진행한 일들

팀원들께서 말씀하시기를... 나는 역대급으로... 바쁠때 들어왔다고 한다.

일이 굉장히 많았고(거의 쏟아졌던...), 그래서 밤을 새워가며 개발을 하기도 했지만, 그래도 그만큼 압축적인 경험을 통해 성장할 수 있었다고 믿는다.

나는 크게 네 가지 일들을 진행했다.

1. 기존 프로젝트의 우선순위가 높은 버그 픽스들

2. 커뮤니티 기능 및 UI개선 스프린트, 버그 픽스

3. 커뮤니티 신규 기능 개발

4. 디지털 교과서를 위한 클래스룸 신규기능 개발

2달간 도합 172개의 이슈를 해결했다!

느낀 점

규모가 다르다.

가장 크게 느낀 부분은 규모가 다르다..! 라는 것이었다.

모듈이 10만개가 넘어가는 거대한 레포지토리에서 작업한다는 것은 토이프로젝트나 신규프로젝트만 진행해서는 절대로 얻을 수 없는 경험이다.

그러다보니 하나의 기능을 구현하기 위해, 보통은 바로 구현하지만, 이경우에는 기존에 구현되어 있는 공통 함수가 있을 수 있었다.

새로운 모듈을 만들어 utils에 추가하는 것이 좋을지, 혹은 파일에서 간단하게 구현할지도 고민해야했다.

공통 함수, 컴포넌트는 없는 것보다 관리가 되지 않는 것이 더 나쁠 수 있다.

빨라빨라빨라...

생각보다 현업의 스프린트는 매우 몹시 빨랐다.

https://youtube.com/shorts/cYhJsz2MibY?si=UQRZjEGfyiLPgoiq

빨라빨라빨라빨라...

정말 이례적으로 바쁜 시기였기에, 2-3일단위, 때로는 하루 단위의 스프린트도 해내야 했다.

하지만, 레포지토리나 코드 컨벤션을 온전히 숙지하지 못한 레벨에서는 그렇게 하기가 꽤 힘들었다.

문제 해결과 문제 해결의 근본적 방법도 중요하지만, 그 속도 역시 절대 무시할 수 없는 것이라는 것을 크게 느꼈다.

언제나 이상적으로 개발할 수는 없는 법이다 .

개발 하는 속도 자체를 높힐 필요가 있다고 느꼈다.

새로운 기술

규모가 워낙 크다보니 프로덕트를 쪼개서 런타임에 합치는 Module federation기술이 적용되어있었다.

이런 부분은 거의 처음 보았기에 상당히 신기했고, 시간이 될때마다 회사 코드의 설정 파일을 하나씩 까보며 이해하려고 노력했다.

나중에 규모가 작더라도 토이플젝으로 활용해볼 예정이다.

솔직한 피드백

엘리스에서 근무하며, 즐겁게 일할 수 있었던 이유였던 것 같다.

지금까지 코드를 짜고 리뷰를 받는 경우, 직접적인 피드백을 받기는 어려웠는데, 사수분께서 정말 솔직하고 명확하게 피드백을 해주셔서 한층 더 발전할 수 있었던 것 같다.

에를 들어, 이전까지는 이렇게 변경하면 어떨까요? 라고 했을 때, "아니오, 이런 부분에서 변경하지 않는게 좋을 것 같아요 " 라는 피드백을 받기는 어려웠다. 이런 피드백은 자칫하면 공격으로 받아들여질 수 있기 때문에 나도 하기 어려운 피드백이고, 다른 분들에게서는 받아본 적 없는 피드백이었다.

하지만, 공격으로 느껴지지 않으면서도 정말 솔직하고 명확하게 근거를 들어 설명해주셔서 나의 생각의 한계를 인지할 수 있었다.

덕분에 미처 생각하지 못한 부분들, 부족한 부분들을 되짚고, 더 넓게 바라보는 방법을 완전히는 아니지만, 얕게 나마 얻을 수 있었다. 그래서 굉장히 좋았다.

좋은 팀원들

개발하는 데 있어, 좋은 팀원분들을 만난다는게 굉장히 중요하다는 것을 알게 됐다.

일정이 빡빡하다보니 다들 힘들텐데도 불구하고 항상 긍정적으로, 재미있게, 함께 해쳐나가는 분위기를 만드는 팀원분들에게서 많은 힘을 얻었던 것 같다. 팀원분들에게 감사하다고 전하고 싶다.

잘했던 부분

개선을 위해

multi-starter

앞서 이야기했듯, Module Federation이 적용되어 있어 빌드시간을 단축시킬 수 있었지만, 문제도 있었다.

바로 5개 가량되는 각각의 레포지토리를 개발시에 모두 켜줘야한다는 것이었다.

속도도 속도지만, 터미널을 5개 켜야한다는 것이 많이 불편했다.

회사 코드를 통해 기여하고 싶었지만,,,

어떤 구조인지 정확히 파악하기에는 시간이 없었기에 회사 의존성과 관계없이 이런 문제를 해결해보고자 했다.

그래서 multi-starter라는 cli를 만들어 npm에 배포했고, 이런 문제를 해결할 수 있었다.

https://www.npmjs.com/package/multi-starter

multi-starter

runner for multirepo with js. Latest version: 1.1.5, last published: 2 months ago. Start using multi-starter in your project by running `npm i multi-starter`. There are no other projects in the npm registry using multi-starter.

www.npmjs.com

lint룰

처음 새로운 컴포넌트를 작성할때, 컨벤션 관련 리뷰를 거의 20개가량 받은 것 같다.

이런 부분은 신경을 써도 처음에는 놓치는 부분이 많아 사수분의 시간을 너무 많이 잡아먹는 것 같다고 느꼈다.

그래서 컨벤션과 일치하는 lint룰을 issue를 통해 제시하고, 실제로 프로젝트에 반영시켰다.

과반수가 동의해야해서 원했던 모든 것들을 적용시키진 못해 아쉽지만, 그래도 기여했다는 부분에서 의미가 있다고 생각한다.

리팩터링

빠른 개발이었지만, 그래도 시간이 남을때마다 리팩터링을 진행하였다.

그래서 복잡한 라우팅 선언과 라우팅 처리를 상수 객체 형태로 관리할 수 있게 만드는 등 개선을 이뤄낼 수 있었다.

과정에서 util타입을 만들고, 선언하는 실력이 많이 개선되었다.

이런 활동들은 직접적으로 프로덕트에 도움이 된다고 보기는 어렵지만, 프로덕트를 만드는 사람들에게 도움이 되는 활동들이다.

나는 이런 활동이 바로 눈에 보이지 않지만 궁극적으로는 프로덕트 개발에 도움을 줄 수 있다고 생각한다.

이게 내가 바로 실행할 수 있는 작게나마 성장하는 조직으로 가게 만드는 방법이라 믿는다.

함께자라기의 부트스트래핑

그리고 이번 인턴십을 통해 이러한 활동들이 팀원분들께 좋은 영향을 미칠 수 있겠다고 느낄 수 있었고, 계속해서 해나가야겠다고 다짐하게 되었다.

조건을 놓치지 않기 위해...

내가 작업한 커뮤니티/클래스룸은 사용자의 권한에 다른 기능 제한이 꽤 있었다.

그래서 상당히 복잡한 조건문 처리를 통한 기능 제한을 했어야 했는데, 이러한 부분이 처음에 제대로 되지 않는다는 문제가 있었다.

이건 그냥 개발을 하는 것이라면 크게 문제가 되지 않지만, 위에서 말했듯 규모가 크기 때문에 이건 굉장한 시간 낭비를 야기한다.

결론부터 이야기하면 if 조건문 하나 잘못쓴 것이 15분~최대 30분가량의 시간을 소비시킨다.

개발->QA서버->프로덕션 배포 이렇게 이어지는 큰 프로세스 중, 마지막 단계, 혹은 QA서버에서 버그가 발생하는 경우, 프로세스를 처음부터 진행해야한다.

조금 더 자세히 쓰면

개발: 규모가 크다보니 개발 서버 빌드시간이 굉장히 오래걸린다.

QA서버: QA서버가 올라가기 전에 프로덕트가 build가 되어야하는데, 이 과정에서 15분가량이 소요된다.

프로덕션: 혹시라도 프로덕션에서 문제가 발생하면, rollback 배포를 한 후, 다시 배포해야하므로 시간이 거의 30분 가량 소요된다.

그래서 하나라도 꼼꼼하게 개발하는 것이 중요했다.

물론 테스트코드를 작성하고, 이를 통해 확인하면 무엇보다 좋겠지만, 마감이 얼마 남지 않은 빠른 개발, 스프린트가 필요한 과정에서 그러한 부분을 적용시키기는 어렵다.

따라서 나는 부스트캠프에서 진행했던 체크리스트를 활용했다.

1. 기능에 대한 구현 조건을 작성한다.

2. 기능을 구현 할 때마다 체크한다.

3. 모든 조건을 완전히 구현한 뒤에, 모든 구현 조건을 다시 확인하고, 빠진 것이 있다면 다시 1번부터 진행한다.

이렇게 진행했더니, 실수나, 빼먹는 조건들로 인해 발생하는 시간 낭비를 많이 줄일 수 있었다.

개선해야할 부분

체력 체력 체력...

사실 이렇게 까지 크게 다가올 문제가 아니라고 생각했는데, 굉장히 타이트한 일정이 이어지다보니 체력이 부족한게 너무 크게 체감되었다.

부스트캠프 - 창업 - 인턴십으로 이어지는 과정에서 운동을 거의 하지 않고 개발만 했더니 체력이 떨어진게 너무 느껴졌다.

일과가 늦어지면, 자는 시간이 줄어들고, 이게 다음날 영향을 미치거나, 밤샘을 한번만 해도 그 다음주까지 영향을 미치는 등...

체력이 부족해서 야기되는 문제들이 많았다.

체력이 부족하다보니 위에서 말한 피드백을 온전히 피드백으로 받아들이는 것도 어려웠고, 좋은 코드와 구조를 고민하는데도 영향을 미쳤다.

마지막엔 코로나까지... 체력을 높히는게 무엇보다 시급하다고 느꼈다.

지속가능한 개발자는 체력이 필수다.

좋은 코드란.... 뭘까

규모가 다르기 때문일까?

회사 코드와 내가 작성해왔던 코드는 스타일도 다르고, 중시하는 부분도 다소 다르다고 느껴졌다.

나의 코드는 최대한 추상화해서 나를 포함한 코드를 사용하는 개발자가 더 쉽게 사용할 수 있게 하자 가 최우선이었다면,

회사의 코드는 누가 봐도 이 코드의 맥락과 구조를 이해할 수 있게 하자 가 더 우선으로 느껴졌다. (물론 내가 전반적으로 느낀 것이고, 실제로 추구하는 것은 아닐 수 있다.)

아무래도, 어디에 무엇이 있는지 모든 팀원이 파악하기 어렵기때문에 코드를 이해하기 쉽게 파악하는게 더 중요해진 느낌...?

누군가 코드를 읽었을때, 빠르게 이해할 수 있게 코드를 작성하는 느낌이었다.

빠르게 이해해야 확장하거나 변경할 수 있기 때문이다.

그래서 내가 제안한 것들이 많이 리젝되기도 했다.

그렇다보니 어떤게 좋은 코드인가? 하는 코드에 대한 고민이 커지게 되었다.

더불어 코어한 webpack 플러그인이나 계정을 불러오는 부분 등, 사수분들과 리드분께서 작성한 코드를 보고 있다 보니,

지금까지 내가 작성한 코드들이 네이밍이나, 맥락을 파악하는 부분에서 많이 부족하다고 느껴지기도 했다.

그래서 좋은 코드란 무엇이냐?에 대한 대답을 명확하게 하기가 어렵다.

더 잘 추상화된 것일까?

다른 사람이 읽기 쉬운 것일까?

어떤게 우선순위가 더 높은지는 상황에 따라 다른 것이겠지만, 나는 아직 그 기준이 명확하게 잡혀있지 않다.

그러나 분명한 것은, 사이드 프로젝트의 규모와 이렇게 대규모의 프로젝트의 규모 차이에서 오는 기준의 변화가 분명히 있다는 것이다.

그래서 더 많은 경험이 필요하다고 느낀다.

더 다양한 환경에서, 다양한 코드를, 더 많은 사람들과 의견을 나누며 작성해보고 싶다.

조금 더 고민하고 고민해보자.

마치며

엘리스의 인턴십은 시기적으로 바쁜시기에 진행하게되어 체력적으로 많이 힘들긴했지만, 그만큼 정말 유의미한 경험을 쌓을 수 있었다.

한편으로는 내가 믿는, 팀을 위한 문제해결과 개선에 대한 믿음이 강해지기도 했고,

한편으로는 거대한 규모에서 오는 새로운 고민들을 갖게하는 좋은 기회였다.

지속 가능한 개발자가 되기 위해서는 개발 외적으로도 많은 노력이 필요하구나라고 느낀 계기이기도 했다. (운동하자.)

언제나 처럼 좋은 점은 더 살리고, 부족한 부분들은 개선하자.

다행히 나는 졸업까지 아직 1년이 남은상태다. 이건 그만큼 더 많은 경험을 쌓고, 위의 과정을 겪으며 성장할 수 있다는 말이다.

더 다양한 경험을 하고, 고민을 해나가야한다.

짧았지만 지금까지 정말 잘 대해준 팀원분들,

그리고 특히 바쁘실텐데도 바로 질문에 대답해주시고, 항상 좋은 피드백을 주시던 사수분께

감사하다는 말씀을 전하며 글을 마무리하고자한다.

yalc로 로컬환경에서 패키지 테스트하기

_0422 — Sat, 13 Jul 2024 22:16:45 +0900

배경

여러가지 라이브러리를 만들어보며, 지금까지 항상 npm에 임의로 버전을 올리고, 패키지를 다운받은 이후에 테스트했었다.

그런데 인턴을 하다, eslint룰을 추가하고 잘 적용됐는지 확인해볼 일이 생기게 됐고, 회사 사내의 라이브러리였기에 이때도 이렇게 진행할 수는 없었다.

yarn link

설명하기에 앞서, 로컬에서 수정하여 프로젝트에 적용시키고자하는 것을 패키지, 실제로 변경된 패키지를 테스트되는 곳을 프로젝트라고 하겠다.

yarn link를 사용해서 패키지와 프로젝트를 연결하면 프로젝트의 node_modules/<package> 와 실제 로컬의 <package>폴더 간의 심볼릭 링크가 생성된다.

이 말인 즉슨, 수정한 패키지를 프로젝트에 추가하기 위해 추가적인 배포나 설치과정이 필요하지 않다는 것이다.

그러나 이 때 두 가지 패키지 같은 패키지를 의존하는 경우, 두 가지 패키지의 같은 의존성이 테스트 하고자 하는 곳에 두 번 설치될 수 있다.

자세한 문제는 이 링크를 참고하면 좋을 것 같다.

yalc

yalc는 yarn link와 다르게 node_modules까지 연결시키는게 아니라, 중복 설치, 동일하지만 다른 경로에 있는 패키지 문제가 발생하지 않는다.

yalc는 yalc publish명령어를 통해서 로컬에 해당 파일을 배포하고, 프로젝트에서 yalc add 패키지@버전의 형태로 배포된 로컬 파일을 의존성으로 정해줄 수 있다.

npm i -g yalc
yarn global add yalc

시작해보기

준비

세가지 프로젝트를 구성했다.

yalc-project1
yalc-project2
yalc-final

일부러 중첩되는 의존성을 갖도록 yalc-project2가 yalc-project1을,

yalc-final이 yalc-proejct2를 의존성으로 갖도록 구성하였다.

yalc-project1 구성/배포

간단하게(npm init -y) index.js에서 변수를 하나 export하도록 패키지를 만들어 주었다.

이렇게 구성해주고, yalc publish를 통해 로컬에 배포해주었다.

로컬 배포 파일 확인

이렇게 하면 프로젝트명@버전 형태로 로컬 저장소에 배포된다.

실제로 배포된 파일을 보자.

yalc를 통해 배포된 파일은 ~/.yalc/packages에 저장이된다.

위의 경우에는 yalc-project1프로젝트가 1.0.0버전으로 배포되었으므로 아래와 같은 폴더 구조로 배포가 된다.

이제 이렇게 배포된 패키지를 yalc-project2에 적용시켜줄 것이다.

yalc-project2

마찬가지로 npm init -y로 패키지를 만들어주었고, yalc-project1패키지에서 사용하는 변수를 사용할 것이다.

이를 위해서 yalc를 통해 yalc-project1를 yalc-proejct2의 의존성에 추가해줄 것이다.

yalc를 통한 의존성 추가/설치

아까 yalc를 통해 yalc-project1을 배포했을때의 결과 문자열을 통해 yalc-project2에 의존성을 추가할 수 있다.

yalc-project1의 배포 결과 문자열

즉 아래와 같이 사용한다.

yalc add yalc-project1@1.0.0

이렇게 추가하게되면, 아래와 같이 .yalc폴더와 yalc.lock, node_modules가 생기게된다.

이때 package.json을 잘보면 file:./yalc/yalc-project1 과 같이 파일에 직접적인 의존성을 갖는다는 걸 알 수 있다.

즉, 현재 디렉토리의 .yalc디렉터리 내부의 프로젝트로 연결되는 것이다.

index.js

이번에는 yalc-project1의 변수를 출력하는 함수를 하나 만들어 export했다.

yalc 로컬 배포

마찬가지로 yalc publish를 통해 로컬 파일에 배포하자.

~/.yalc/packages에 잘 배포됐다

yalc-final

이제 최종 프로젝트에 yalc-project2를 적용시키자.

마찬가지로 npm init -y를 통해 만들었다.

yalc add를 통해 의존성을 추가해주자.

그럼 이제 .yalc에 yalc-project2가 생기고, yalc-project2 프로젝트에 .yalc/yalc-project1이 추가된 것을 확인할 수 있다.

이러고 index.js를 실행시키면...?

이는 node_modules/yalc-proejct1이 없기때문이다.

현재는 node_modules/yalc-project2/.yalc/yalc-project1의 형태로 의존성이 들어가있다.

이 상태에서 yarn 또는 npm install을 해주게되면 node_modules/yalc-project1디렉토리가 생성되며, node_modules에 병합을 해주는 파일(.package-lock.json, yarn-integrity)이 생성된다.

왼쪽은 package-lock.json, 오른쪽은 .yarn-integirity

이러면 이제 node index.js가 잘 작동한다.

2024 상반기 회고

_0422 — Sun, 7 Jul 2024 17:26:58 +0900

되돌아보기

2024년이 반이나 지나갔다.
세상에,이번 6개월은 눈 깜짝할 새에 지나갔다.

2023 하반기 목표 돌아보기

독서량 늘리기

2023하반기에서 책을 많이 읽는 것을 목표로 세웠었는데, 운 좋게도 책읽기와 상상력이라는 교양수업을 들을 수 있었고 덕분에 많은 책들을 읽을 수 있었다. 덕분에 최근에는 새로운 취미로 민음사 책들을 모으고 있다.

이번 상반기를 통해 책은, 특히 민음사 전집과같은 고전은 때로는 약으로, 때로는 예방주사로 작용할 수 있다는걸 알게 됐다.
지식의 전달이라는 관점보다는 경험과 가치를 보다 온전한 형태로 전달받는다는 점에서 더 좋다고 느끼게 됐다.

운동하기

근력운동은 아니지만, 틈날 때마다, 한강도로 근처라면 따릉이를 빌려서 타고있다.
사실 운동해야한다는 마음가짐보다는 좀 여유를 느끼고, 자전거를 타고 싶어서 탔는데 꽤나 건강에 좋았을 지도...?

창업과 개발

작년말에 마지막으로 창업에 도전한다고 했었다.
그래서 정말 그 어느때보다 열심히, 진심으로 임했고, 정말 런칭 직전까지 갔었지만, 프로젝트가 엎어졌다.
열심히 관리해보려했지만, 역부족이었다. 상상도 못한 이유로 프로젝트가 엎어졌고, 정말 마음이 아팠다.
그것도 그것이었지만, 개발 관련한 인턴이나 직무 결과도 처참하기 그지없었다.

면접탈도 아닌, 모두 서류탈락
계속 이 일을 해야할까?, 그리고 할 수 있을까? 라고 생각하기도 했다.
그때 읽은 노인과 바다가 나를 다시 일으켜 세웠다.

언제나, 무슨 일이든 일어날 수 있다.
10번 시도해서 10번 다 잘 안 될 수도 있다.
하지만 결과가 어찌됐든 나의 의지와 선택이 중요한 것이다.

내가 좋아하고, 내가 잘 할 수 있는건 다른 무엇이 아닌, 개발이다.
무언가 만들고, 개선하는 것이 내가 좋아하고, 잘 할 수 있는 일이다.

결과가 어찌 됐든 나는 이 일을 할 것이다.

과도기를 넘어서기

이전 당근마켓 인턴십 불합격 회고를 적을 시절, 나는 꽤나 과도기에 있었다.
그래서 내가 개선시키기 위해 할 일들을 적었었다.

https://0422.tistory.com/331

다 하지는 못했지만, 생각보다 해낸 것들이 많았다.
자잘한것들보다는 큰 것만 적어보았다.

오픈 소스 만들고 배포하기

npm에 2개의 패키지를 만들어서 배포했다.
이 작업들을 통해서 굉장히 많은 고민들을 할 수 있었고, 많은 지식들(특히 ts와 모듈시스템!)을 쌓을 수 있었다.
프로덕트든 툴이든, 내가 만들어낸 걸 누군가가 쓴다는건 너무나도 의미있는 경험이다.

학습하는 과정에서 TS공식문서 한글화에 참여해보기도 했다. (레포가 방치된 것 같기는 하다.)

오픈소스 기여하기

토스의 slash 라이브러리에 기여해보기도 했다. (이젠 deprecated됐지만)
과정에서 토스의 박서진님게 리뷰를 받았었는데, 꽤나 놀랐다.
나는 그전까지 편리한 기능을 더한다가 기본 생각이었다. 이런걸 추가하면 더 좋지 않을까? 라는 생각으로 항상 개발에 임했었던 것이다.

불필요한 기능을 빼는 것이 얼마나 중요한 것인지를 알게 해준 소중한 경험이었다.

더 높은 퀄리티의 블로그 글쓰기

결과적으로 실패가 더 많긴하지만, 그래도 굉장히 많은 기술적 경험을 쌓을 수 있었기에 올해 블로그 작성 글 수(43개, 작년은 6개월당 66개)는 줄었어도 전반적인 퀄리티는 올라갔다고 생각한다.

창업 프로젝트를 진행하면서 경험했던 웹뷰의 작업 경험, 문제를 해결하기위한 툴을 만든 경험을, 그리고 당근마켓의 사전질문이었던 피드 관련 기능을 직접 구현하며 블로그에 녹여낼 수 있었다. 더불어 라이브러리를 만들며 학습한 모듈 시스템과 ts, rollup, 그리고 Next만들어보기까지. 덕분에 전체적인 블로그 퀄리티는 이전보다 향상되었다.

앞으로

변화

많은 실패가 있었지만, 계속해서 개선하고자 노력하고, 많이 도전하고, 운이 꽤나 따라준 결과, 학교 현장실습을 통해 인턴 근무를 할 수 있게 되었다.

정말 많이 도전한 끝에 얻어낸 결과이니만큼 진심을 다해 열정적으로 임해볼 것이다. 그래서 지금까지 했던 코딩학원 강사 알바도 그만두게 되었다.

그렇다보니 아무래도 이번 하반기 목표는 회사와 팀, 프로덕트에서 최대한 많은 것들을 경험하고 배워보자이다.

목표

회사/팀/프로덕트에 기여하기

프로덕트던, 팀에 대한 것이건 개발을 통해 유의미한 성과를 내고, 기여하는 것을 최우선으로 생각하고 있다.

지금까지의 경험을 살려서 무엇이 됐던 더 좋게 개선하고, 더 빠르게 만드는 유의미한 경험을 회사에서 얻어가고 싶다.

과정에서 많이 성장할 수 있을 것이라 생각한다.

회사에서 한 경험을 잘 기록하기

이렇게 경험한 것들을 휘발시키지 않고, 온전히 나의 경험으로 만들고 싶다.

그래서 시간 날때마다 잘 메모해두려고 한다.

그리고 코드나 이런 것들이 문제가 되지 않는 선에서 가능하다면 유의미한 것들을 블로그에도 적어 보고 싶다.

전체적인 흐름 잡기

여러번 프로젝트를 진행해보긴 했지만, 실제로 프로덕트를 만들때 회사에서 어떤 식으로 프로젝트를 관리하고, 진행하는 지를 알기란 어려웠다. 이번 기회를 통해 전반적으로 프로젝트를 어떻게 관리하는지, 팀에서는 어떻게 소통하는지를 제대로 배워가고 싶다.

배운 것을 잘 적용하기

관광 관련 프로젝트 공모전을 준비하게되어, 평일에는 일을 하고, 주말이나 저녁에는 공모전을 준비하게될 것 같다.

위에서 얻은 지식과 경험들을 공모전 프로젝트에 잘 적용시켜서 전반적인 프로젝트 결과물은 물론 과정도 크게 개선시켜 보고 싶다.

매니징이라던가 소통 방식도 개선할 수 있을 것이라 생각한다.

독서량 유지하기

뭔가 생각해보면 전반적인 독서량이 중요하다기보다는 독서를 통해 가치를 얻어내는게 더 중요하다고 생각한다.

억지로 읽기보다는, 정말 유의미한 가치를 얻어가는 양을 상반기와 비슷하게 가져가고 싶다.

물론, 그러려면 비슷한 양을 읽어야겠지만... 어쨌든 목표는 책의 수가 아니라, 얻어가는 가치의 양이다.

하반기에도 많은 것들을 배우고, 얻어가고싶다.

마무리

사실 정말 정신없고, 제대로 되는게 없다고 느꼈던, 엉망진창이었던 6개월이었다.

그렇지만 이렇게 되돌아보니 생각보다 목표로 한 것들을 잘 하고 있고

제자리라 생각한 것들조차도 많이 성장해있었음을 알 수 있었다.

이번 6개월은 노력한 것 대비 성과는 그리 좋지 않았지만,

나는 내가 진심인 것에 어느 때보다 열심히 했고, 적어도 쉬지는 않았다.

그거면 됐다.

문득 생각나서 첨부하는 하루키의 에세이

꾸준히 목표를 잡고 하나씩 달성해나가자.

Next를 만들어보면서 이해해보자 (JSX기반 MiniNext) - pages기반 라우팅 (+중첩라우팅)

_0422 — Fri, 7 Jun 2024 13:26:01 +0900

pages 파일 기반 라우팅

지금까지는 pages에 App.tsx만 있어서 하나의 파일에 대해 html을 만들어서 전송했었다.

하지만 Next에서는 pages에 있는 모든 파일이 라우팅되어, 해당 경로로 접근하였을때 페이지를 제공해준다.

이러면 /와 /gallery 경로가 생성된다.

이번에는 이 기능을 구현해 볼 것이다.

pageFiles찾기

우선 이를 위해서는 pages의 파일이름들을 가져올 수 있어야한다. 그래서 바벨로 트랜스파일링된 dist/pages내부의 모든 tsx파일을 찾아올 것이다.

const PAGES_PATH = 'dist/pages';

export const getPagesFiles = async (pagesPath = PAGES_PATH) => {
  const files: string[] = await new Promise((resolve, reject) => {
    readdir(pagesPath, (err, files) => {
      if (err) reject();
      resolve(files);
    });
  });
  return files;
};

이전의 getServerSideProps함수를 모두 가져오는 함수와 똑같다. 이걸 통해서 이후에 Page 컴포넌트를 동적으로 가져올 수 있게 된다.

const { default: Component } = require(
      path.resolve(`${PAGES_PATH}`, fullFileName) //getPagesFiles를 통해 가져온 파일이름
);

그런데 이러면 이때 각 Page의 hydration에 필요한 js파일도 달라지게된다. 즉, 클라이언트에서 받을 번들파일을 만들어줘야하는데, 이 역시 페이지마다 동적으로 생성되어야 한다.

이전의 index의 경우 아래와 같은 클라이언트 js파일이 있었고, createHTML에서 이 코드를 번들링한 결과를 <script>태그로 넣어주었었다.

//이전의 public/index.tsx -> rollup을 통해 번들링되어 /dist/public/index.js가 된다.
import * as Page from '@/pages/index';
import { hydrate } from '@core/render';

hydrate(Page.default, document.getElementById('_miniNext'));

//createHTML
export const createHTML = (
  element: MiniReactNode,
  initialServerProps?: Record<string, string>,
) => {
  const root = `
  <html>
  ...
  <body>
  <div id="_miniNext">${_createHTML(element)}</div>
  </body>
  ...
  <script src='index.js'></script> //여기서 번들링한 index.js를 보내준다.
  </html>`;
  return root;
};

createHTML의 수정

따라서 이걸 동적으로 처리해주도록 createHTML에서 fileName을 받도록 수정했다.

export const createHTML = (
  element: MiniReactNode,
  initialServerProps?: Record<string, string>,
  fileName: string
) => {
  const root = `
  <html>
  <head>
    <title>MiniNext</title>
  </head>
  <body>
  <div id="_miniNext">${_createHTML(element)}</div>
  </body>
  <script>
    window._miniNextData=${JSON.stringify(initialServerProps)}
  </script>
  <script src='${fileName}.js'></script>
  </html>`;
  return root;
};

이걸 활용해서 서버 응답을 만들어줄 것이다.

페이지마다 번들파일 생성하기

페이지별로 번들 엔트리파일 생성하기

그런데 createHTML의 script태그를 통해 보내줄 페이지별 번들 엔트리 파일이 없다.

이건 public에 정적으로 작성했었는데, 이제는 정적으로 작성할 수 없으므로 동적으로 생성되게 해주어야한다.

이렇게 작동하게 만들 것이다.

 import { existsSync, mkdirSync, writeFile } from 'fs';
import path from 'path';
import { getPagesFiles } from './routeMapper';

export const createClientFiles = async () => {
  const files = await getPagesFiles('src/pages'); // src/pages를 전부 읽어온다.
  
  if (!existsSync(path.resolve(`public`))) //root 디렉토리에public폴더가 없으면 만든다.
    mkdirSync(path.resolve(`public`)); //런타임 이전에 실행되므로 블로킹을 고려하지 않았다.
  
  files.forEach((fullFileName) => {
    const [fileName] = fullFileName.split('.tsx');

    writeFile( //번들 엔트리 파일을 생성한다.
      path.resolve(`public/${fileName}.tsx`),
      `import * as Page from '@/pages/${fileName}';
import { hydrate } from '@core/render';

hydrate(Page.default, document.getElementById('_miniNext'));
  
  `,
      (err) => {
        console.log(err);
      }
    );
  });
};

createClientFiles();

rollup.config.js

rollup에서 만들어준 pulic경로의 파일들에 대해서 번들을 만들도록 처리해줄 것이다.

const babel = require('@rollup/plugin-babel');
const resolve = require('@rollup/plugin-node-resolve');
const extensions = ['.js', '.jsx', '.ts', '.tsx'];
const path = require('path');

const fs = require('fs');

const files = fs.readdirSync('public'); //public의 모든 파일을 읽어온다.
// 이 파일은 런타임 전에 실행될 것이므로 블로킹을 고려하지 않았다.

가져온 파일을 바탕으로, 번들링 엔트리 포인트를 만들어줘야한다.

const createConfigFile = (fullFileName) => {
  const [fileName] = fullFileName.split('.tsx');
  return {
    input: `./public/${fullFileName}`, //찾아온 파일
    output: {
      file: `./dist/public/${fileName}.js`, //dist/public을 통해 정적파일로제공한다.
      format: 'es',
    },
    plugins: [
      babel({
        babelHelpers: 'bundled',
        presets: ['@babel/preset-env', '@babel/preset-typescript'],
        plugins: [
          ...
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
    ],
  };
};

그리고 이렇게 만든 함수를 통해 config 배열을 생성해서 반환해주도록 했다.

module.exports = files.map((fullFilename) => createConfigFile(fullFilename));

라우팅 경로 설정하기

이제는 getPagesFiles를 통해 찾은 모든 경로에 대해 get메서드에 대한 응답 데이터를 만들어주면 된다.

const getRoutingPath = (fileName: string) => {
  //확장자 없는 파일이름에 따라 라우팅 경로를 만들어준다.
  if (fileName === 'index') return '/'; //index인경우
  return `/${fileName.toLowerCase()}`; //아닌경우
};


export const routeMapper = async (app: Express) => {
  const files = await getPagesFiles(); // dist/pages내부의 .js파일을 가져온다.
  
  //가져온 모든 pages내부의 파일에 대해서
  files.forEach((fullFileName) => {
    const [fileName] = fullFileName.split('.js'); //.js를 뜯은 파일이름을 기반으로 라우팅을 해줄 것이다.

    app.get(
      getRoutingPath(fileName),

      async (req: Request, res: Response) => {
      	//ServerSideProps와 Component를 가져와서 html을 생성하고, hydration을 해준다.
        const serverSideFunctions = await getServerSidePropsFunction();
        const serverSideFunction = serverSideFunctions[fullFileName];
        const serverSideProps = serverSideFunction?.().props;
        const { default: Component } = require(
          path.resolve(`${PAGES_PATH}`, fullFileName)
        );
        const html = createHTML(
          <Component {...serverSideProps} />,
          serverSideProps,
          fileName //동적으로 js파일을 넘겨준다.
        );
        res.send(html);
      }
    );
  });
};

서버 스크립트 수정하기

이제 이렇게 작성한 로직을 순서대로 작동할 수 있게 만들어주자

build.sh

babel src --extensions .ts,.tsx --out-dir dist //babel 트랜스파일링
node dist/core/createClientFiles.js //pages기반으로 public폴더, 파일 생성
rollup --config rollup.config.js //dist/public 파일 번들링

정리

정리하면 이렇게 그려볼 수 있다.

결과

이제 단일한 Pages 폴더 요소에 대해서 잘 작동하는 것을 볼 수 있다.

중첩 라우팅으로 업그레이드하기

getPagesFiles

이제는 pages에 폴더가 들어갈 수 있다.

이런 폴더 구조에서 getPagesFiles가 수행되면 이렇게 나와야 한다.

따라서 readdir에서 폴더를 읽은 경우, 재귀적으로 getPagesFiles를 호출해서 경로를 만들어주어야한다.

처음에는 이를 재귀함수로 직접 구현했지만, 찾다보니 readDir의 recursive옵션을 통해 해결할 수 있었다.

import { readdir } from 'fs';
import path from 'path';
const PAGES_PATH = 'dist/pages';

export const getPagesFiles = async (pathString = PAGES_PATH) => {
  return await new Promise<string[]>((resolve, reject) => {
    readdir(path.resolve(pathString), { recursive: true }, (err, files) => {
      if (err) reject(err);
      //확장자가 없는 경우를 무시한다
      resolve((files as string[]).filter((file) => file.match('(.js)|(.tsx)')));
    });
  });
};

이제 이렇게 만든 getPagesFiles를 적용시켜주자.

getPagesFiles를 쓰는 곳은 createClientFiles, routeMapper, getServerSidePropsFunctions이다.

createClientFiles

중첩적으로 폴더를 만들어주는게 핵심이다.

import { existsSync, mkdirSync, writeFile } from 'fs';
import path from 'path';
import { getPagesFiles } from './getPagesFiles';

export const createClientFiles = async () => {
  const files = await getPagesFiles('src/pages'); //src/pages를 모두 읽어옴
  //프로젝트 루트에 public 폴더가 없는경우 만듦
  const isExists = existsSync(path.resolve('public')); 
  if (!isExists) mkdirSync(path.resolve('public'));

  files.forEach((fullFileName) => {
  //읽어온 파일에서 src/pages와 tsx제거
    const fileName = fullFileName
      .replace(/src\/pages\//, '')
      .replace(/\.tsx/, '');
      
	//중첩라우팅인경우
    if (fileName.match('/')) {
      const filePaths = fileName.split('/');
      //파일 이름을 제외한, 디렉토리만을 가져온다.
      const dirPath = filePaths.slice(0, -1).join('/');
      //해당 디렉토리가 없다면, 중첩적으로 폴더를만들어준다.
      const isExists = existsSync(path.resolve('public', dirPath));
      if (!isExists) {
        mkdirSync(path.resolve('public', dirPath), {
          recursive: true,
        });
      }
    }
    
    writeFile(
      path.resolve(`public/${fileName}.tsx`),
      `import * as Page from '@/pages/${fileName}';
import { hydrate } from '@core/render';

hydrate(Page.default, document.getElementById('_miniNext'));
  
  `,
      (err) => {
        if (err) console.log(err);
      }
    );
  });
};

createClientFiles();

getServerSidePropsFunction

import path from 'path';
import { getPagesFiles } from './getPagesFiles';

type ServerSideFunction = Record<string, Function>;

export const getServerSidePropsFunction = async () => {
  const result: ServerSideFunction = {};

  const files = await getPagesFiles();
  files.map((file) => {
    const { getServerSideProps } = require(path.resolve('dist/pages', file));
    result[file] = getServerSideProps;
  });
  return result;
};

routeMapper

const PAGES_PATH = 'dist/pages';
import { readdir } from 'fs';
import path from 'path';
import { Express, Request, Response } from 'express';
import { getServerSidePropsFunction } from './getServerSidePropsFunction';
import { createHTML } from './createHTML';
import { getPagesFiles } from './getPagesFiles';

const getRoutingPath = (fileName: string) => {
//index 단일 경우에는 /를, 아닌 경우에는 /와 소문자로 구성된 경로를 반환한다.
  if (fileName === 'index') return '/';
  if (fileName.match('index')) return `/${fileName.replace('index', '')}`;
  return `/${fileName.toLowerCase()}`;
};

export const routeMapper = async (app: Express) => {
  const files = await getPagesFiles();

  files.forEach((fullFileName) => {
  //dist/pages와 .js를 제거한다.
    const fileName = fullFileName
      .replace(/dist\/pages\//, '')
      .replace(/.js/, '');
    app.get(
      getRoutingPath(fileName),

      async (req: Request, res: Response) => {
        const serverSideFunctions = await getServerSidePropsFunction();
        const serverSideFunction = serverSideFunctions[fullFileName];
        const serverSideProps = serverSideFunction?.().props;
        const { default: Component } = require(
          path.resolve('dist/pages', fullFileName)
        );
        const html = createHTML(
          <Component {...serverSideProps} />,
          serverSideProps,
          fileName
        );
        res.send(html);
      }
    );
  });
};

rollup.config.js

rollup.config.js도 재귀적으로 public폴더를 탐색해서 파일 번들링 entry포인트를 찾을 수 있도록 구성해야한다.

const babel = require('@rollup/plugin-babel');
const resolve = require('@rollup/plugin-node-resolve');
const extensions = ['.js', '.jsx', '.ts', '.tsx'];
const path = require('path');

const fs = require('fs');

const files = fs
  .readdirSync('public', { recursive: true })
  .filter((fileName) => fileName.match(/.tsx/));

const createConfigFile = (fullFileName) => {
  const [fileName] = fullFileName.split('.tsx');
  return {
    input: `./public/${fullFileName}`,
    output: {
      file: `./dist/public/${fileName}.js`,
      format: 'es',
    },
    plugins: [
      babel({
        babelHelpers: 'bundled',
        presets: ['@babel/preset-env', '@babel/preset-typescript'],
        plugins: [
          [
            '@babel/plugin-transform-react-jsx',
            { importSource: '@core', runtime: 'automatic' },
          ],
          [
            'module-resolver',
            {
              alias: {
                '@core': path.resolve(__dirname, 'src/core'),
                '@/utils': path.resolve(__dirname, 'src/utils'),
                '@/pages': path.resolve(__dirname, 'src/pages'),
              },
            },
          ],
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
    ],
  };
};

module.exports = files.map((fullFilename) => createConfigFile(fullFilename));

결과

실존은 본질에 앞선다. (feat. 노인과바다, 사피엔스, 이기적 유전자)

_0422 — Thu, 6 Jun 2024 11:42:43 +0900

의자는 앉기 위해 만들어진다. 침대는 자기 위해 만들어진다. 옷은 입기 위해 만들어진다.

본질이 실존에 앞서는것이다.

그렇다면 사람은 무엇을 위해 만들어졌는가? 꽃과 동물은 무엇을 위해 만들어졌는가?

이런 질문에 대답하기 위해 많은 철학, 종교가 탄생했다.

하지만, 과학이 발전함에따라 종교의 힘은 점차 축소되고, 결국 남는 건 무의미다.

우리는 그냥 존재할 뿐이다. 본질은 아직 존재하지 않는다.

최근의 경험에 관하여

나는 꽤나 창업에 관심이 많다. 새로운 가치를 만들어 내고, 이것을 사람들에게 알려 세상을 더 개선하는 것이 나의 꿈, 최종목표이다.

그래서 이번 년도 초에 시작한 창업프로젝트에 앱 개발자이자 창업 멤버로 참여해서 3개월간 정말 밥 먹고 일만 할 정도로 일을 했다.

규모가 꽤나 컸음 에도, 팀원들이 열정적으로 임해 주었기에 프로덕트는 거의 런칭 직전이었다. 하지만, 정부지원프로그램 지원서에 팀원의 이름을 뺀 것, 사업계획서를 보여주지 않고 부당한 계약을 요구하여 프로젝트는 좌초되고 말았다.

더불어 저작권을 언급하며 블로그 글들을 다 지우라고 요구해왔다. 이러한 법적인 부분을 잘 몰랐기에 무료 법률상담까지 알아보며 정말 속이 타 들어가는 경험을 했다.

이때 정말 화가 나기도 하고, 육체적으로나 정신적으로나 너무나도 지치게 되었다. 이렇게 창업에 대한 꿈을 접어야 하나, 이 꿈을 접으면 어떤 목표를 가지고 살아야 할까?를 진지하게 고민하게 되었는 데, 대학 교양 수업을 통해 마침 읽게 된 책이

노인과바다였다.

저녁에 기분전환용으로 짧게 읽어볼 생각으로 구매한 노인과 바다를 읽기 시작했는데, 몇 번이나 새어 나오는 눈물을 참아야만 했다. 청새치와 고군분투하는 노인에게 너무나도 감정이입이 됐던 것이다. 노인이 청새치를 잡으려 노력하는 장면들, 계속해서 한번 더를 외치며, 청새치와 싸우는 장면은 지금 생각해도 감동이 밀려온다.

덕분에 책에는 포스트잇이 덕지덕지 붙게 됐다.

그렇게 책을 읽고, 나 역시 나를 응원해주는 마놀린이 곁에 있다는 것, 끝까지 투쟁하는 노인의 모습이 얼마나 아름다운지를 알게 되어 다시한번 의지를 갖고, 다시 일어서서 나아갈 수 있었다.

사람은 파괴될지 언정, 패배하지 않는다.

감동받은 경험들

이렇게 노인과 바다를 읽은 후 생각해보니 내가 영화나 책을 보고 “이거 참 명작이다” 라고 생각하는 것들은 대부분 인간의 의지를 보여주는 작품이 많았다는 것을 알게 됐다. 예를 들어, 영화 중에는 어벤져스의 캡틴아메리카가 타노스의 수많은 무리들에 홀로 맞서는 장면, 최근에는 매드맥스의 퓨리오사가 고통뿐인 세상속에서 아무도 희망을 믿지 않을 때, 홀로 희망을 찾아 계속해서 도전하는 모습에 감동을 받았다.

경험들의 공통점

이 작품들의 공통점은 주인공이 운명, 부조리에 대항한다는 점이다.

부조리는 인간이 통제할 수 없는 예측불가한 현상으로, 이는 다양한 형태로 우리의 삶에 다가온다.

이러한 맥락에서 운명이라는 단어보다는 부조리라는 단어를 선택했다.

이해할 수도, 납득할 수 도 없는, 하나의 현상이기 때문이다.

노인과 바다에서는 상어가, 어벤져스에서는 타노스, 퓨리오사는 아포칼립스 세계관 자체가 부조리다.

하지만, 노인은, 캡틴은, 퓨리오사는, 이런 부조리에 대항해 자신의 신념을 갖고 맞서 싸운다.

앞서 소개한 인물들은 운명과 부조리에 대항한다는 공통된 선택을 했지만, 그 결과는 모두 달랐다. 노인은 상어에게 청새치를 빼앗겨 뼈만 남았고, 퓨리오사는 열심히 찾아간 고향에 아무것도 없었지만 캡틴은 타노스를 물리쳤다.

그럼에도 나는 동일한 감정을 그들에게서 받을 수 있었고, 공감할 수 있었다.

왜 나는 감동받았는가

그렇다면 왜?

왜 나는 일면식도 없는 인물들에게 공감하고, 부조리에 대항하는 인물에게 감동을 받고, 그들처럼 되어야겠다 다짐하는 것일까? 나는 그것의 이유를 이기적 유전자와 사피엔스를 연결 지어 찾을 수 있었다.

불안에 관하여

대부분 이기적 유전자의 유전자에 꽂히기 마련이지만, 나는 안정이라는 단어에 꽂혔다.

우리는 안정을 향해간다.

소금의 결정은 물론이고, 심지어 태양계 한가운데에 위치한 무지막지하게 큰, 지구상의 모든 생물을 먹여 살리는 태양조차도 수소보다는 헬륨으로, 점진적으로 자신만의 안정을 향해 나아간다.

이기적 유전자의 등장에 안정이 있었듯, 우리는 근본적으로 안정을 추구한다.

모든 생명체를 넘어서, 모든 물질이 안정을 추구하는 것이다.

하지만 안정을 추구한다는 것은 반대로 이야기하면 현재 상태가 불안정하기도 하다는 것이다.

불안정은 인간에게 불안으로 다가온다.

불안을 이겨내는 방법

불안, 불안정을 이겨내는 방법은 두 가지라고 생각한다.

실제로 안정 상태가 될 것
안정되었다고 믿을 것

우리는 결코 안정상태가 될 수 없다.

기술적으로는 물론이고, 안정상태가 된다고 한들, 그것보다 더 나은 안정상태가 항상 존재하기 마련이기 때문이다.

즉, 안정에 도달할 수 없다.

하지만 우리는 인지 혁명으로, 허구를 믿을 수 있다. (사피엔스)

강력한 의지

그렇다면 왜 그들에게서 감동을 느끼고, 매력을 느끼는가?

그들은 강력한 의지로, 옳다고 믿는 신념을 지키기 위해 때로는 죽음조차 불사한다.

무슨 일이 있어도 그것을 지킬 것이라는 의지는 변하지 않는 것이다.

변하지 않는다는 것은 곧 안정과도 같다.

나는 그들에게서 존경심은 물론, 안정을 느끼기 때문에, 감동을 받는 것이다.

강력한 의지는 곧 안정이다.

어떻게 살 것인가

이제 본질을 찾아낼 때다.

최후의 확정된 부조리

인생이 도대체 어떻게 흘러갈지는 모르겠지만, 현재로써 가장 확실하게 정해져 있는 것은 나는 죽는다 라는 사실이다.

따라서 최종적이고, 절대적인 상태의 안정은 불가능하다.

그렇다면, 계속해서 안정이라 믿을 수 있게 하는 강력한 의지가 필요하다.

즉 본질은 변하지 않을 강력한 의지를 찾아내는 것, 그것을 지켜나가는 것에 있다.

의지를 채우기

그렇다면 어떻게 의지를 찾아낼 수 있을까

나는 내가 좋아하는 일, 자신에게 의미와 가치가 있는 일들을 지속적으로 찾아가는게 좋다고 생각한다.

꼭 하나로 한정 지을 필요 없이 다양한 의미를 찾아보면 자연스럽게 다양한 의지로 가득 채워진다.

그것이 목표든, 꿈이든, 가족이든, 사랑이든 아니면 진심으로 좋아하는 하나의 분야든.

마놀린이 될것

이 사실을 모든 사람에게 적용시키면 진실된 공감을 할 수 있게 된다.

이런 사실을 알게 되면 타인의 의지와 그로 인해 발현된 것들(취향, 선택)을 존중할 수 있게 된다.

예컨데, 나는 스포츠와 서브컬쳐에 그렇게 열정적이지 않다.

하지만 그것에 열정적인 사람들을 존중할 수 있다.

그들의 진심과 의지를 이해할 수 있게 된다.

나아가 누군가가 진심을 다했지만, 부조리로 인해 잘 되지 않았을 때, 그들의 진심과 의지를 인식하고, 진정으로 공감할 수 있게 된다.

이때 나는 누군가의 진정한 마놀린이 된다. 또한 누군가의 소중한 사람, 즉 의지가 되기도 한다.

마무리

지난 6개월은 정말 다양한 일이 있었고, 지쳐가기도 했다.

하지만, 그런 경험을 쌓고, 그로 인한 생각들을 하나로 연결시킬 수 있었다.

이 글은 경험을 먼저 작성하고, 이후에 결론이 나왔다. 도입부는 맨 마지막에 적었다.

결론을 도출한 후에 찾아보니 내가 생각하는게 완벽하게 실존주의와 일치한다는 것을 알게됐다.

나는 실존주의자구나.

노인과 바다의 일부를 첨부하며 글을 마친다.

Next를 만들어보면서 이해해보자 (JSX기반 MiniNext) - getServerSideProps, hydration

_0422 — Fri, 31 May 2024 11:06:40 +0900

이전에 동일한 JSX를 갖고 html과 React App을 렌더링하고, 이 둘을 연결시켜보았다.

이번에는 Next(12버전)의 핵심 기능중 하나인 getServerSideProps를 구현하고, 이걸 클라이언트와 연동시켜보고자 한다.

getServerSideProps

아래는 Next docs에서 가져온 사진이다.

이걸 어떻게 사용하는지는 이미 알고있다고 가정하고, 이 코드들의 특성을 분석해보자.

https://nextjs.org/docs/pages/building-your-application/data-fetching/get-server-side-props

이 코드를 보면 네가지를 알 수 있다.

getServerSideProps는 page컴포넌트에 작성되어야한다.
함수 이름은 getServerSideProps이며, export되어야한다.
page컴포넌트에 getServerSideProps에서 반환된 값을 props로 넘겨준다.
page컴포넌트 자체는 default export되어야한다.

무작정 적용하기

일단 위의 예시처럼 App과 Content에 Server Side Props를 넘겨주고, 이걸 useState의 초기값으로 넘겨보자.

App.tsx

import Content from '../components/Content';
import Header from '../components/Header';

interface AppProps {
  number?: number;
}
export const getServerSideProps = () => {
  return {
    props: {
      number: 100,
    },
  };
};

export default function App({ number }: AppProps) {
  return (
    <div style={{ width: '100%' }}>
      <Header />
      <Content serverNumber={number} />
    </div>
  );
}

Content

import { useState } from '@core/useState';

export default function Content({ serverNumber }: { serverNumber?: number }) {
  const [number, setNumber] = useState<number>(serverNumber || 0);

  return (...)
}

구현하기

이제 이걸 어떻게 적용시킬지 고민해보자.

getServerSideProps를 가져오기

이제 앞에서 생각했던 네가지를 고려할때다.

getServerSideProps는 page컴포넌트에 작성되어야한다.
함수 이름은 getServerSideProps이며, export되어야한다.
page컴포넌트에 getServerSideProps에서 반환된 값을 props로 넘겨준다.
page컴포넌트 자체는 default export되어야한다.

이걸 활용해보자.

getServerSideProps와 page default 함수는 모두 pages 안에 작성되어야한다.

따라서 pages의 파일을 읽어와서, require를 통해 동적으로 모듈을 가져올 수 있다.

동적으로 getServerSideProps를 가져와보자.

import { readdir } from 'fs';
import path from 'path';

const PAGES_PATH = 'dist/pages';

type ServerSideFunction = Record<string, Function>;

export const getServerSidePropsFunction = async () => {
  const result: ServerSideFunction = {};
  const files: string[] = await new Promise((resolve, reject) => {
  //runtime에 pages 디렉토리를 훑게되므로 블로킹을 고려한다.
    readdir(PAGES_PATH, (err, files) => {
      if (err) reject();
      resolve(files); //파일목록을 읽어온다. ex) files=["index.js"]
    });
  });

  files.map((file) => {
    const { getServerSideProps } = require(
      path.resolve(`${PAGES_PATH}/${file}`) //ex) dist/pages/index.js
    );
    result[file] = getServerSideProps; //객체에 함수를 등록한다.
  });
  /**
  result= {
	"App.js":getServerSideProps;
  }
  **/
  return result;
  
};

pages 내부의 모든 파일을 가져와서 그중에 getServerSideProps라는 모듈을 찾아온다.

이후에 이걸 fileName프로퍼티의 값으로 붙여서 내보내주게 되면, 해당 객체내부의 함수만 호출하면 serverProps를 가져올 수 있게 된다!

이러면 이제 serverProps를 내려줄 수는 있는데 serverProps가 적용은 되지 않은 것을 확인할 수 있다.

값이 0이다.

왜냐하면 클라이언트에서 hydrate할때 serverProps가 적용되지 않기때문이다.

public/index.tsx

이 함수가 클라이언트가 받게되는 js파일이된다.

import App from '../src/components/App';
import { hydrate } from '@core/render';

hydrate(<App />, document.getElementById('_miniNext'));

이전 hydrate함수

export const hydrate = (content: MiniReactNode, container: HTMLElement) => {
  console.log('hydrate 완료');
  const element = makeDOM(content);
  root = container;
  prev = content;
  container.innerHTML = '';
  container.appendChild(element);
  callEffects(); // DOM이 생성된 이후에 useEffect를 실행시킨다.
};

여기서 보면 content가 App함수를 호출한 결과인데, public/index.tsx에서 호출할때 따로 ServerProps를 전달해주지 않고 있기 때문이다.

hydrate (ServerSideProps)

그렇다면 ServerProps를 클라이언트 파일도 접근할 수 있게 만들면된다.

how?

나는 서버사이드에서 html을 생성할때, script에서 window객체에 serverSideProps를 담아서 보내주도록 했다

그렇다면 createHTML의 인자로 serverSideProps를 받을 수 있어야한다.

createHTML

export const createHTML = (
  element: MiniReactNode,
  initialServerProps?: Record<string, string> //serverProps를 인자로 받았다.
) => {
  const root = `
  <html>
  <head>
    <title>MiniNext</title>
  </head>
  <body>
  <div id="_miniNext">${_createHTML(element)}</div>
  </body>
  <script>
    window._miniNextData=${JSON.stringify(initialServerProps)} //window._miniNextData에 저장한다.
  </script>
  <script src='index.js' type="module"></script>
  </html>`;
  return root;
};

app.tsx

따라서 app.tsx도 아래처럼 바뀌게 된다.

app.get('/', async (req, res) => {
  const serverSideObject = await getServerSidePropsFunction();
  const serverSideProps = serverSideObject["App.js"]().props

  const html = createHTML(App(serverSideProps), serverSideProps);
  res.send(html);
});

그럼 이제 window._miniNextData에 넣어준 데이터를 miniReact의 hydrate과정에서 props로 넣어주면된다.

hydrate

export const hydrate = (Component: Function, container: HTMLElement) => {
  const content = Component(window._miniNextData); //ServerSideProps연동
  console.log('hydrate 완료');
  const element = makeDOM(content);
  root = container;
  prev = content;
  container.innerHTML = '';
  container.appendChild(element);
  callEffects();
};

원래는 <App/>처럼 호출이 완료된 함수 객체, miniReactNode를 인자로 받았지만, props를 hydrate함수에서 넣어주기위해서 인자 타입을 변경해주었다.

여기서 window._miniNextData의 값을 App의 props로 넣어주게된다.

public/index.tsx

import App from '../src/pages/App';
import { hydrate } from '@core/render';

hydrate(App, document.getElementById('_miniNext')); //<App/>에서 App으로 함수 객체자체를 넘긴다.

결과

내려준 ServerSideProps가 잘 적용된 모습이다!

export const getServerSideProps = async () => {
  const number = await new Promise((resolve) => {
    resolve(100);
  });
  return {
    props: {
      number,
    },
  };
};

요런식으로 getServerSideProps함수를 변경해도 잘 동작하는 모습이다.

+) 실제 Next

__NEXT_DATA__에 데이터를 담아서 보내준다. 비슷하게 동작한다고 추론할 수 있다.

Next를 만들어보면서 이해해보자 (JSX기반 MiniNext) - createHTML, 기본 hydrate 구현하기 (feat. miniReact)

_0422 — Tue, 28 May 2024 18:14:23 +0900

이전 게시글에서 호환 가능한 JSX 컴포넌트를 만들었다.

이제는 JSX를 사용해서 SSR에서 반환할 HTML과 클라이언트에서 hydrate, 업데이트할 코드를 작성해볼 것이다.

이번 게시글에서 할 일

jsx함수로 부터 반환된 miniReactNode객체를 서버에서 HTML String으로 변환할 것이다.(클라이언트로 js파일을 여기서 보내 줄 것이다.)
jsx함수로 부터 반환된 miniReactNode객체를 클라이언트에서는 DOM으로 변환할 것이다.
1. 클라이언트에서는 이전에 만들어둔 miniReact를 활용하여 useState을 통해 update할 것이다.
2. update는 VDOM을 비교하여 바뀐부분만 업데이트한다.
받은 클라이언트는 js파일을 통해 hydrate를 하여 miniReact로 동작하는 어플리케이션을 조작할 수 있게될 것이다.

HTML생성하기

이제 만든 JSX를 통해 HTML String을 생성해주자.

MiniReactNode

type DefaultProps = Record<string, string>;
type Props = DefaultProps & {
  children?: MiniReactNode[];
};

export interface MiniReactNode {
  tagName: string;
  props: Props;
}

이 자료구조를 활용해서 props.children을 재귀적으로 돌면서 HTML 문자열을 생성할 것이다.

_createHTML

const _createHTML = (element: string | MiniReactNode) => {
  if (typeof element === 'string' || typeof element === 'number') {
    //element가 text거나 number인 경우 그냥 내보낸다.
    return element;
  }


  let HTMLString = `<${element.tagName} `;  // 태그 열기
  let styleProps = ``;
  if (element.props) { //props를 HTML attribute로 붙인다.
    Object.keys(element.props).forEach((key) => {
      if (key === 'style') { //style의 경우 여러개가 붙을 수 있어서 따로 처리
        const styleObject = element.props[key];
        Object.entries(styleObject).forEach(([key, value]) => {
          styleProps += `${key}: ${value}; `;
        });
        HTMLString += `style= "${styleProps}"`;
      } else if (key !== 'children') { //children은 붙이지 않고 이후에 재귀적으로 만들어 붙인다.
        HTMLString += `${key}= "${element.props[key]}" `;
      }
    });
  }
  HTMLString = HTMLString.trimEnd(); //'<tagName ...attribute '<- 마지막 공백을 제거한다
  HTMLString += '>'; //태그를 닫아준다.
  if (element.props.children) {
    //children에 대해 재귀적으로 HTML을 생성해 붙인다.
    element.props.children.forEach((child) => {
      HTMLString += _createHTML(child);
    });
  }
  HTMLString += `</${element.tagName}>`; //태그를 완전히 닫아준다.
  return HTMLString; //최종 생성된 HTML을 반환한다.
};

createHTML

그리고 이렇게 나온 결과물에 html, head, body와 hydrate를 위한 루트요소(_miniNext)를 추가해주었다.

여기서 rollup으로 번들링 완료한 클라이언트 js파일을 보내준다.

export const createHTML = (element: MiniReactNode) => {
  const root = `
  <html>
  <head>
    <title>MiniNext</title>
  </head>
  <body>
  <div id="_miniNext">${_createHTML(element)}</div>
  </body>
  <script src='index.js'></script> //클라이언트로 보내줄 js파일 (rollup으로 번들링해준 결과물)
  </html>`;
  return root;
};

app.tsx

이제 이렇게 변경해주고 npm run dev로 서버를 실행시켜주자.

app.get('/', (req, res) => {
  const html = createHTML(<App />);
  res.send(html);
});

이제 접속하면 작성한 컴포넌트대로 화면이 잘 보인다!

VDOM과 업데이트

이건 이전에 만들었던 miniReact코드를 활용했다.

따라서 이전 글을 첨부하고, 자세한 설명은 하지 않겠다.
https://0422.tistory.com/318

https://0422.tistory.com/319

https://0422.tistory.com/320

createDOM

마찬가치로 jsx함수를 통해 반환된 MiniReactNode에 대해서 수행하는데, 이번에는 실제 DOM요소를 만든다.

import { MiniReactNode } from './jsx-runtime';

export const makeDOM = (element: string | MiniReactNode) => {
  if (typeof element === 'string' || typeof element === 'number') {
    //element가 text거나 number인 경우 textNode로 만든다.
    return document.createTextNode(String(element));
  }

  const DOMElement = document.createElement(element.tagName);
  if (element.props)
    //props를 실제 DOM요소에 적용시킨다.
    Object.keys(element.props).forEach((key) => {
      if (key === 'style') {
        const styleObject = element.props[key];
        Object.entries(styleObject).forEach(([key, value]) => {
          (DOMElement as any).style[key] = value;
        });
        return;
      }
      if (key !== 'children') (DOMElement as any)[key] = element.props[key];
    });
  if (element.props.children) {
    //children에 대해 재귀적으로 DOM요소를 만들어 현재 요소에 붙인다.
    element.props.children.forEach((child) => {
      DOMElement.appendChild(makeDOM(child));
    });
  }
  element.ref = DOMElement;
  return DOMElement; //최종 생성된 DOM요소를 반환한다.;
};

useState, useEffect

여기서는 miniReact 코드를 사용했으므로 훅을 직접 구현해주었다.

구현에 대한 설명은 https://0422.tistory.com/320 를 참고하면 좋을 것 같다.

useState에 대한 설명밖에 없으나, useEffect도 동일한 원리다. 둘다 index기반으로 작동하며, 따라서 rerender시 index를 초기화시켜주어야한다.

useState

import { rerender } from './render';

const states: any[] = []; //배열 형태의 states
let stateIndex = 0;

export const useState = <T>(initialValue: T) => {
  const indexBind = stateIndex;
  stateIndex++;
  if (states[indexBind] === undefined) {
    states.push(initialValue);
  }

  const setState = (updateValue: T) => {
    states[indexBind] = updateValue;
    rerender();
  };
  return [states[indexBind], setState];
};

export const initializeIndex = () => {
  stateIndex = 0;
};

useEffect

type EffectCallbacks = {
  func: () => void;
  deps: any[];
  haveToCall: boolean;
};

const effectCallbackArray: EffectCallbacks[] = [];
let effectIndex = 0;

export const useEffect = (callback: () => void, deps: any[]) => {
  const indexBind = effectIndex; 
  effectIndex++;
  if (effectCallbackArray[indexBind] === undefined) {
    effectCallbackArray.push({
      func: callback,
      deps,
      haveToCall: true,
    });
    return;
  }
  const isChange = deps.some(
    (deps, index) => effectCallbackArray[indexBind].deps[index] !== deps
  );
  if (isChange) {
    effectCallbackArray[indexBind].deps = deps;
    effectCallbackArray[indexBind].haveToCall = true;
  }
};

export const getEffectArray = () => effectCallbackArray;
export const initializeEffectIndex = () => (effectIndex = 0);

hydrate

hydrate는 앞서 craeteHTML에서 만들어줬던 _miniNext div요소 내부요소를 만들어준 DOM으로 교체해주는 역할을 한다.

기존의 miniReact에서의 최초의 render대신 hydrate가 이뤄지는 것이다.

export const hydrate = (content: MiniReactNode, container: HTMLElement) => {
  console.log('hydrate 완료');
  const element = makeDOM(content);
  root = container;
  prev = content;
  container.innerHTML = '';
  container.appendChild(element);
  callEffects(); // DOM이 생성된 이후에 useEffect를 실행시킨다.
};

update, rerender

update의 경우 VDOM을 비교해서 DOM을 업데이트하는 함수다.

여기서 다루기에는 내용이 너무 많으므로 이전 게시글을 참고해주면 될것 같다.

약간 코드가 수정되었는데, github 링크를 참고하면 좋을 것 같다.

rerender는 이런식으로 구성해주었다.

let prev: MiniReactNode; //이전의 virtual DOM
let root: Element; //최상단 root요소

export const rerender = () => {
  initializeIndex(); //리렌더시 useState의 index를 초기화
  initializeEffectIndex(); //useEffect index 초기화
  const updateElement = <App />;
  updateDOM(root, prev, updateElement);
  callEffects(); //useEffect콜백 호출
  prev = updateElement; //업데이트가 끝나면, 요소 업데이트
};

컴포넌트 수정하기

이렇게 컴포넌트를 수정해주었다.

App.tsx

export default function App() {
  return (
    <div style={{ width: '100%' }}>
      <Header />
      <Content />
    </div>
  );
}

Header.tsx

export default function Header() {
  return (
    <header>
      <h1
        style={{
          fontSize: '35px',
          textAlign: 'center',
        }}
      >
        MiniNext
      </h1>
    </header>
  );
}

Content.tsx

여기서 useState를 통해 컴포넌트를 업데이트 할 것이다.

import { useState } from '@core/useState';

export default function Content() {
  const [number, setNumber] = useState<number>(0);

  return (
    <div
      style={{
        ...
      }}
    >
      <div
        style={{
          ...
        }}
      >
        <div>Your Number : </div>
        <div style={{ fontWeight: 700 }}>{number}</div>
      </div>
      <button
        onclick={() => setNumber(number + 1)}
        style={{
          ...
        }}
      >
        Click This!
      </button>
    </div>
  );
}

hydrate적용하기

이제 public/index.tsx에 hydrate를 적용하자.

public/index.tsx

import App from '../src/components/App';
import { hydrate } from '@core/render';

hydrate(<App />, document.getElementById('_miniNext'));

결과

hydrate가 정상적으로 완료되었고, state 도 잘 바뀌는 것을 확인할 수 있다!

Next를 만들어보면서 이해해보자 (JSX기반 MiniNext) - 호환 가능한 JSX(feat. Rollup, nodemon, Babel)

_0422 — Tue, 28 May 2024 00:38:18 +0900

구성하기

내가 원하는 것

app.get('/', (req, res) => {
  const html = createHTML(<App />);
  res.send(html);
});

바로 이런 그림이다. 클라이언트와 동일한게 <App/>을 렌더링하고, 이걸 초기 HTML로 전송해주는 것이다.

그리고 클라이언트에서는 이렇게 App을 렌더링해줄 것이다.

import App from '../src/pages/App';
import { hydrate } from '@core/render';

hydrate(<App/>, document.getElementById('_miniNext'));

이러면 클라이언트와 서버에 대해서 동일한 App컴포넌트를 통해 따로 따로 코드 해당 환경에 맞는 코드를 작성할 필요없이 통합적으로 관리해줄 수 있다.

따라서 필요한 것들을 준비할 것인데, 이렇게 동작하려면 몇 가지 준비가 필요하다.

JSX코드를 서버에서 트랜스파일링할 수 있어야한다.
클라이언트에서도 역시 JSX가 최종적으로는 일반적인 JS 파일형태로 변환되어 잘 실행될 수 있어야한다.

언어는 Typescript를 사용할 것이다.

서버 구동을 위해 Express, nodemon을 사용할 것이다.

JSX, typescript 트랜스파일링은 babel을 통해 구성할 것이다.

클라이언트의 JSX트랜스파일링은 번들링을 통해 해결할 것인데, index.html이 필요하지 않으므로 Rollup을 통해 구성해줄 것이다.

npm init -y
npm i typescript nodemon -D
npm i express

babel과 rollup은 구성하면서 설치할 것이라 일단 이렇게 설치한다.

Babel

바벨을 통해 서버 코드를 트랜스파일링 해줄 것이다. (JSX사용을 위해)

npm i @babel/cli @babel/core @babel/plugin-transform-react-jsx @babel/preset-env @babel/preset-typescript

plugin-transform-react-jsx: JSX를 함수로 변환시켜주는 플러그인이다.

preset-typescript: babel이 typescript도 읽을 수 있게 해주는 플러그인이다. tsc말고 babel을 통해 바로 트랜스파일링 할 수 있게 구성할 것이다.

plugin-transform-react-jsx

원래는 react/jsx-runtime에서 jsx함수를 import하지만, babel.config.js를 통해 이 함수를 커스텀 할 수 있다.

나같은 경우 src/core에 핵심 함수들을 작성해두었다.

babel.config.js

따라서 babel.config.js를 아래와 같이 구성해주었다.

module.exports = {
  presets: ['@babel/preset-env', '@babel/preset-typescript'], //typescript 트랜스파일링
  plugins: [
    [
      '@babel/plugin-transform-react-jsx', //jsx 트랜스파일링
      { importSource: '@core', runtime: 'automatic' },
    ],
  ],
};

<App/>과 같이 JSX를 호출하면 jsx()함수가 호출되게 되는데, 이 함수를 어디서 import할지를 결정해주는 것이다.

원래는 import { jsx, jsxs} from react/jsx-runtime 이나 importSource를 통해 react대신에 다른 문자를 지정해줄 수 있다.

위처럼 설정하면 import { jsx, jsxs} from @core/jsx-runtime 으로 소스가 변경된다.

또, runtime을 automatic으로 설정하면 jsx가 ,아니라면(classic) React.createElement가 호출된다.

나는 automatic으로 설정해주었다.

JSX

JSX는 babel을 통해 어떻게 변환될까?

<div className="flex">내용</div>

위와 같은 JSX가 있다면, babel은 이렇게 변환한다.

jsx("div", {
    className:'flex',
    children: '내용',
});

이걸 나는 어쨌던 최종적으로 HTML과 VDOM요소로 변환해주어야하기때문에, 객체형태로 관리해야한다.

그리서 이런식으로 객체 타입을 짜주었다.

type DefaultProps = Record<string, string>;

type Props = DefaultProps & {
  children?: MiniReactNode[];
};

export interface MiniReactNode {
  tagName: string;
  props: Props;
}

그리고 jsx와 jsxs함수가 설계한 타입을 반환하도록 구현해주었다.

간단하게 작성하면, 입력으로 들어온 것을 객체에 담아만 주면 되므로 매우 간단하다.

export const jsx = (tagName: string, props: Props) => {
  return {
    tagName,
    props,
  } as MiniReactNode;
};

export const jsxs = jsx;

하지만 여러가지 경우의 수가 존재한다.

tagName이 함수인 경우는 재귀적으로 호출해서 중첩된 객체를 내보내야한다.
children이 중첩 배열일 수 있다.
children이 빈 문자열을 포함할 수 있다.
children이 없을수도 있다.

이러한 경우를 고려하여 최종적으로 이렇게 짜주었다.

src/core/jsx-runtime.ts

//src/core/jsx-runtime.ts

//어쨌던 children은 배열로 동작하게 만든다.
//이후에 VDOM diffing과 HTML render를 위해서는 배열로 구성하는게 용이하다.
const getChildren = (props: Props) => {
  if (Array.isArray(props.children)) return [...props.children]; 
  if (props.children === undefined) return [];
  return [props.children];
};

export const jsx = (tagName: Function|string, props: Props) => {
  props.children = getChildren(props);

  if (typeof tagName === 'function') return tagName(props); // tagName이 함수면 재귀적으로 호출한다.
  props.children = props.children.flat(); // 2차원 배열인 경우 flat시켜 1차원으로 만든다.
  props.children = props.children.filter((child: any) => {
    if (typeof child === 'number') return true; //빈문자열을 필터링한다. 다만, child가 0인 경우를 고려한다.
    return Boolean(child); ./
  });

  return {
    tagName,
    props,
  } as MiniReactNode;
};

export const jsxs = jsx;

서버쪽 JSX 테스트

src/pages/App.tsx

이렇게 한 뒤, JSX컴포넌트인 App.tsx를 pages에 만들어주자.

export default function App() {
  return <div style={{ width: '100%' }}>테스트</div>;
}

src/app.tsx

서버의 메인 코드인 app.tsx를 작성해주자.

//src/app.tsx

import express from 'express';
import App from './pages/App';
const app = express();
const port = 3000;

app.get('/', async (req, res) => {
  console.log(<App />);
});

app.listen(port, () => {
  return console.log(`Server Start at http://localhost:${port} ☺️`);
});

현재 폴더구조는 아래와 같다.

이제 babel을 통해 dist폴더에 트랜스파일링하고, 이를 node 명령어를 통해 실행시켜볼 것이다.

npx babel src --extensions .ts,.tsx --out-dir dist

dist결과물

경로 이슈

그리고 node dist/app.js로 실행시키면 오류가 발생한다.

이는@core/jsx-runtime 경로를 찾을 수 없기 때문이다.

Babel은 트랜스파일러라 module resolve를 해주지는 않는다. 해주려면 플러그인을 추가해주어야한다.

npm i babel-plugin-module-resolver -D

이를 통해 트랜스파일링시 경로를 바꿔줄 수 있게된다.

babel.config.js

최종적으로 babel.config.js를 구성해주었다.

module.exports = {
  presets: ['@babel/preset-env', '@babel/preset-typescript'],
  plugins: [
    [
      '@babel/plugin-transform-react-jsx',
      { importSource: '@core', runtime: 'automatic' },
    ],
    [
      'module-resolver',
      {
        alias: {
          '@core': './dist/core', //jsx-runtime의 경로 찾기 모든 ts파일에 대해
          //  트랜스파일링 하기때문에 dist의 core경로에도 jsx-runtime이 생기게 된다.
          '@': './dist', //절대경로도 지정해주었다.
        },
      },
    ],
  ],
};

이러면 잘 실행되어 console이 잘 찍히는 것을 확인할 수 있다!

nodemon, package.json설정

nodemon을 이렇게 설정하였다.

{
  "watch": ["src"],
  "ext": "ts,tsx",
  "exec": "babel src --extensions .ts,.tsx --out-dir dist && node dist/app.js"
}

이러면 src내부의 ts,tsx가 변경될때마다 트랜스파일링, 서버 재실행이 이뤄질 것이다.

이걸 package.json의 dev에 달아주었다.

{
	...
   "scripts": {
   ...
   "dev": "nodemon",
   },
}

클라이언트 JSX

그럼 이제 클라이언트에서도 동일한 JSX파일을 사용할 수 있는지 확인해야한다.

클라이언트에서 js파일을 확인할 수 있도록 public폴더를 만들어주고, static설정을 해주었다.

app.tsx

const app = express();
const port = 3000;
//==================여기를 추가했다!=================
app.use(express.static('dist/public')); 
//=================================================

app.get('/', async (req, res) => {
  console.log(<App />);
});

이러면 이제 dist/public은 정적파일 폴더로 작동한다. localhost:3000/index.js를 찾는경우 dist/public/index.js가 생긴다는 것이다.

그럼 public에 index.js파일을 만들고, 클라이언트에 보내줄 html을 만들고 script를 통해 index.js를 실행시키면 된다.

이때 번들링에 사용될 index.tsx에서 JSX를 사용하고, 이게 최종적으로 잘 작동하는지 확인해 보면 JSX컴포넌트는 서버와 클라이언트에서 모두 호출가능한 형태인 것이 된다.

public/index.tsx (src외부다)

import App from '../src/pages/App';

console.log(<App />);

서버에서와 동일하게 App을 가져와 jsx함수로 호출해주었다.

Rollup

이걸 babel로만 트랜스파일링 하게되면 @core/jsx-runtime이 public에서도 접근가능해야한다.

이러한 설정을 해줄 수는 있겠지만, 이것보다는 번들러를 사용해서 하나의 번들을 구성해주는게 더 합리적이라 판단했다.

index.html대신 app.tsx에서 HTML string을 보내줄 것이므로, 다른 번들러가 아니라 rollup을 통해 번들을 구성해주었다.

npm i -D rollup @rollup/plugin-babel @rollup/plugin-node-resolve

@rollup/plugin-babel : babel을 사용해서 JSX를 트랜스파일링 해줄 것이다. 따라서 babel을 사용할 수 있도록 구성해야한다.

@rollup/plugin-node-resolve: 번들링시 module의 의존성문제를 해결해준다.

없으면 이런 오류가 발생한다.

public/index.tsx를 entry로 하여 번들링하면 되므로 이렇게 구성해주었다.

rollup.config.js

const babel = require('@rollup/plugin-babel');
const resolve = require('@rollup/plugin-node-resolve');
const extensions = ['.js', '.jsx', '.ts', '.tsx'];
const path = require('path');

module.exports = [
  {
    input: './public/index.tsx',
    output: {
      file: './dist/public/index.js',
      format: 'es',
    },
    plugins: [
      babel({
        babelHelpers: 'bundled',
        presets: ['@babel/preset-env', '@babel/preset-typescript'],
        plugins: [ //babel.config.js와 동일하다.
          [
            '@babel/plugin-transform-react-jsx',
            { importSource: '@core', runtime: 'automatic' },
          ],
          [
            'module-resolver',
            {
              alias: {
                '@core': path.resolve(__dirname, 'src/core'),
              },
            },
          ],
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
    ],
  },
];

이제 rollup으로 클라이언트 파일을 번들링해보자.

rollup --config rollup.config.js

이렇게 dist에 public과 index.js가 생기는 것을 확인할 수 있다.

이제 이걸 app.tsx에서 클라이언트로 보내주기만 하면된다!

nodemon 수정

rollup커맨드를 같이 실행시켜준다.

{
  "watch": ["src"],
  "ext": "ts,tsx",
  "exec": "babel src --extensions .ts,.tsx --out-dir dist && rollup --config rollup.config.js && node dist/app.js"
}

src/app.tsx

이제 '/'에 GET요청을 보내면 index.js를 실행시키는 html문자열을 생성해서 보내보자.

import express from 'express';
import App from './pages/App';

const app = express();
const port = 3000;
app.use(express.static('dist/public'));

app.get('/', async (req, res) => {
  console.log(<App />);
  const html = `<html>
  <head>
  <title>miniNext</title>
  </head>
  <body>
    <div>miniNext!</div>
  </body>
  <script src="index.js" ></script>
  </html>`;
  res.send(html);
});

app.listen(port, () => {
  return console.log(`Server Start at http://localhost:${port} ☺️`);
});

결과

둘다 잘 작동하는 것을 확인할 수 있다.

감격스러운 순간이다.

전체 코드

https://github.com/d0422/learning-by-making/tree/main/apps/miniNext

learning-by-making/apps/miniNext at main · d0422/learning-by-making

✅ 직접 만들면서 학습하는 과정을 담은 레포지토리. ⚛️miniReact(useState구현), JS EventLoop Visualizer, miniNext(SSR,ISR) 직접구현하고, 이를 모노레포(pnpm+turborepo) 형태로 관리합니다. - d0422/learning-by-making

github.com

Next를 만들어보면서 이해해보자 (JSX기반 MiniNext) - 무엇을, 어떻게 만들것인가?

_0422 — Mon, 27 May 2024 15:11:32 +0900

시작하며

이전에 리액트가 어떻게 동작하는지, 이해하기 위해서 리액트처럼 동작하는 어플리케이션을 만들어보았었다.

https://0422.tistory.com/317

리액트를 만들면서 이해해보자 (1) - JSX와 React.createElement

이 글을 읽기에 앞서 이 게시글은 리액트처럼 동작 하는 코드를 작성해보는 것이지 리액트와 100% 동일한 코드를 작성하려 하는 것이 아닙니다. JSX jsx는 javascript + xml의 줄임말이다. 이걸 쓰면 html

0422.tistory.com

이번에도 마찬가지다. 이번에는 Next의 SSR과 hydrate과정을 직접 만들어보면서 이해해보고자 한다.

배경 : SSR과 CSR

SSR이란 Server Side Rendering의 줄임말으로, 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 페이지를 보여주는 방식이다.

여기서 모두 구성이란걸 한 번 눈여겨 볼 필요가 있다. 그럼 원래는 부분적으로 구성을 해서 보내주기도 한다는건가?

그렇다. React기반의 웹 어플리케이션에서 useEffect를 통해 데이터 패칭을 통해 화면을 보여주는 경우 아래와 같은 순서로 작동하게 된다.

서버로 부터 HTML수신
script태그를 통해 리액트 및 어플리케이션 번들파일 수신
js실행하여 컴포넌트 실행(렌더링) 및 root에 컴포넌트 결과물 붙이기
useEffect를 통해 데이터 패칭
컴포넌트 리렌더링

이러면 반드시 네트워크 통신이 2회 일어날 수 밖에 없고, (2번과 4번) 완벽한 페이지 하나를 보내주는게 아니라, 페이지를 조각내고, 완성되지 않은채로, 부분적으로 보내주는 꼴이 된다.

애초에 첫 HTML파일은 root밖에 없거나, 혹은 아예 아무것도 없는 상태이다.

그러면 뭐가 문젠데요?

번들사이즈가 커지게되면 3번과정이 일어나는데까지 시간이 걸리게된다.

그말인즉슨, 흰 화면을 보게되는 것이다.

엥 그러면 한번에 다 받아오는게 더 이득아닌가요?

물론 그렇다. 하지만 그럴수가 없었다.

CSR이전의 웹 개발에서는 페이지 이동이란 html 파일의 교체를 의미했다. 마치 책의 페이지를 넘기듯, index.html에서 login.html으로, 다른 파일을 받아오고, 화면에 그리는 것이다. 실제로 HTML은 하나의 문서(document)다.

그래서 새로운 데이터를 받아오려면 새로운 문서를 받아와야만 했다.

그러면 새 화면 데이터를 불러오는 동안 또다시 흰화면(이번엔 깜박임)을 보게된다! 어쩌면 클라이언트는 흰화면과의 싸움일지도 모르겠다.

그러면 유저별 HTML 파일을 전부 만들어두는 건가요?

매번 맞춤형 HTML을 만들어놓을 수는 없는 법이다. 그래서 이전의 웹서버와 WAS들은 PHP, JSP와 같은 언어를 통해 동적으로 서버에서 HTML을 만들어서 전송해주도록 구성되었다. 지금도 많은 사이트들이 구성되어 있는데, 이러한 언어와 프레임워크들이 최초의 SSR 되시겠다.

main.do와 같은 형태로 도메인이 끝난다면, JSP, PHP으로 구성되어있다고 볼 수 있다.

정리

이전의 PHP,JSP를 사용한 SSR을 전통적인 SSR이라 이름붙이면, 이렇게 정리할 수 있다.

여기서 말하는 데이터란, 유동적으로 변할 수 있는, 네트워크에 저장된 데이터를 말한다.

	전통적 SSR	CSR
데이터 패칭	데이터를 서버에서 받아오며, 서버에서 데이터로 만든 결과물을 클라이언트에서 받아옴	빈 HTML을 받아, 화면을 구성하는 것을 포함한 번들파일과 실제 데이터를 모두 클라이언트에서 받아옴
장점	1번의 통신을 통해 데이터를 가져옴	한번 번들을 받아오면 정적파일을 다시 받아올 필요가 없음
단점	페이지 이동마다 깜빡임이 있고, 하나의 페이지마다 정적파일을 한번씩 받아와야하기에 속도가 느림	번들이 커지면 첫 화면을 그리는데 많은 시간이 필요함. 총 2회의 통신을 통해 모든 데이터를 가져옴

Home화면에서 Feed로 이동하는 흐름을 CSR과 SSR에서 비교하면 이렇게 그릴 수 있다.

Next: 두마리 토끼를 다 잡을수는 없을까?

결론에서 만든 표와 그림을 합쳐서 표기하면 이렇게 표시할 수 있게된다.

과연 이런 장단점을 합칠수는 없을까?

Next는 이 상황에 대해 여러가지 방법을 제공한다.

초기 렌더링에 보여질 HTML을 미리 만들어두고, 요청이 오면 그걸 보여줘서 초기에 흰화면을 보여주지 않는 방법 (SSG, ISR)
페이지 이동시 클라이언트에서 흰화면을 보여주지 않고 SPA처럼 보이게 하는 방법(SSR)

이렇게하면 둘의 장점만 뽑아서 쓸 수 있게 된다.

How?

그런데 어떻게 이런게 가능할까? 나는 이번 프로젝트를 통해 이러한 고민들중 일부를 직접 해결해보고, 이후에는 Next 코드를 살펴보며 이해해보고자 한다.

생각해보기

위의 방법을 사용하려면 간단하게 생각해도 크게 세 개가 필요하다.

서버에서 HTML을 미리 만들어 두는 기능
서버에서 만든 HTML을 클라이언트에서 상호작용 가능하도록 만들어주는 기능 (Hydration)
클라이언트에서 동작할 기능

서버에서 동작하는것, 클라이언트에서 동작하는 것

서버에서 동작할 코드, 클라이언트에서 동작할 코드가 있는 것을 볼 수 있는데, 생각해보면 Next를 사용하면서 한번도 따로 작성한 적이 없다. 사실 그럴거였으면 Next가 이렇게 커지지도 않았을 것이다.

그래서 내가 떠올린 답은 JSX다.

JSX는 객체로 변환되고, 이를 통해 하나의 코드로 HTML을 생성할수도 있고, VDOM에 들어갈 ReactNode를 생성할 수도 있다.

HTML과 클라이언트의 상호작용 (Hydration)

이건 JSX를 떠올리니 자연스럽게 떠올랐다. 바로 React의 리렌더링을 활용하는 것이다.

어차피 HTML이니 DOM은 그대로 있고, 초기에 React VDOM이 생성될때, 기존 HTML을 업데이트 해주면 끝이다!

만들 것

따라서 나는 JSX와 React like(이전에 만들어둔 함수들을 활용해볼 예정이다.)를 통해 Next like를 만들어 볼 것이다.

크게는 ServerSideProps, ServerSideRendering, Hydration이 될 것 같다.

환경설정부터 진행해보자.

라이브러리를 만들어보자 - (3) Rollup+babel로 ESM과 CJS모두 대응되게 만들기

_0422 — Sat, 11 May 2024 16:52:31 +0900

이전 게시글에서 TS는 내부 코드의 확장자를 변경하지 않는다는 것을 알 수 있었다.

그렇다면 tsconfig.json 두개로 cjs와 esm 모두 대응되게 만든다는 것은 어려운 일이라는 것을 알 수 있다.

하지만, 시작한 이상 여기서 포기하고 싶진 않았다. 그래서 번들러로 코드를 번들링한 결과를 npm에 배포하도록 했다.

왜 Rollup?

Webpack과 Vite, Rollup등 다양한 번들러가 있으나 Rollup을 택했다.

이유는

1. 라이브러리 번들링이기에 HMR이나 개발서버가 필요하지 않았다. (결과물 테스트는 Jest와 Storybook을 활용하여 확인한다)

2. Rollup은 ES6형태로 번들링 결과를 반환해서 ESM코드에 대해서 트리쉐이킹을 지원한다.

3. 사실 2번은 웹팩도 지원하지만, rollup이 빌드속도면에서 더 빠르기도하고, 써보고싶기도 했다.

Rollup 구성하기

일단 Rollup을 전역으로 깔아주었다.

npm install --global rollup

Rollup은 rollup.config.js를 통해 설정할 수 있다.

한가지 특징이라면, 한번 번들링을 할때 여러번의 번들링을 할 수 있다는 것이다.

rollup.config.js에서 배열 형태로 객체를 구성하여 가능하다.

ESM, CJS 번들링 구성

export default [
  {
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js', //결과파일 경로
      format: 'es', //ESM으로 번들링
    },
  },
  {
    input: './src/index.ts',
    output: {
      file: './dist/cjs/index.cjs', //결과파일 경로
      format: 'cjs', //CJS로 번들링
    },
  },
];

위와 같이 번들링 구성을 해주었다. 각 객체마다 한번씩 번들링이되어서 결과물이 dist/esm, dist/cjs 두개로 나오게 되는 것이다.

그런데 이걸 실행(rollup --config rollup.config.js)시키면 오류가 발생한다.

index.ts를 읽는중에 ./useDragIndexCarousel/useDragIndexCarousel을 가져오는걸 실패했기때문이다.

이게 왜 실패했는가? ts파일이라 확장자가 생략되어서 그렇다.

일단 확장자를 해결하기 위해서는 @rollup/plugin-node-resolve을 사용할 수 있다.

npm i @rollup/plugin-node-resolve -D

rollup.config.js

import resolve from '@rollup/plugin-node-resolve';

const extensions = ['.js', '.jsx', '.ts', '.tsx'];
export default [
  {
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js',
      format: 'es',
    },
    plugins: [
      resolve({ 
        extensions, //모듈 확장자를 읽어오고, 추가로 외부 모듈도 읽어올 수 있게 된다.
      }),
    ],
  },
  ...
];

그리고 다시 rollup을 실행시키면... 다시 오류가 발생한다!

이건 진짜 ts문법을 그대로 읽으려고 했기때문이다.

그렇다면 ts를 읽어줄 필요가 있다.

이때 선택지가 몇 가지 존재한다.

rollup에서 typescript을 읽을 수 있도록하기
다른 트랜스파일러를 통해 typescript를 읽고, 그걸 rollup이 번들링하도록 하기
tsc한 뒤에 rollup하기

3번은 rollup에서 plugin을 제공하기때문에 굳이 그렇게 구성할 필요가 없다.

따라서 처음에는 1번을 택해서 @rollup/plugin-typescript를 사용해서 구성했었다.

import typescript from '@rollup/plugin-typescript';
export default [
  {
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js', //결과파일 경로
      format: 'es', //ESM으로 번들링
      plugins: [typescript()] //ts 플러그인 적용
    },
  },
  {
    input: './src/index.ts',
    output: {
      file: './dist/cjs/index.cjs', //결과파일 경로
      format: 'cjs', //CJS로 번들링
      plugins: [typescript()] //ts 플러그인 적용
    },
  },
];

하지만, 이왕 ESM과 CJS를 고려하는거, 다양한 브라우저도 다 고려하여 구성하기로 마음먹게되었다.

그래서 babel을 통해 ts파일을 js로 트랜스파일링 하도록 처리해주었다. 어떤 상황에서든 라이브러리를 사용할 수 있었으면 하는 마음이다.

따라서 babel설정을 해주었다.

npm i @babel/core @babel/preset-env @babel/preset-react @babel/preset-typescript @rollup/plugin-babel

plugin설정을 통해 babel을 설정해주었다.

import babel from '@rollup/plugin-babel';

const extensions = ['.js', '.jsx', '.ts', '.tsx'];

export default [{
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js',
      format: 'es',
    },
    plugins: [
      babel({
        babelHelpers: 'bundled',
        presets: [
          '@babel/preset-env',
          '@babel/preset-react',
          '@babel/preset-typescript',
        ],
        extensions,
      }),
    ],
  },
  ...
  ]

이러면 babel이 ts를 js로 트랜스파일링한 후에, rollup이 번들링을 하게된다.

d.ts도 각 모듈 시스템에 대해 만들어 주기위해 dts plugin을 설치해주었다.

npm i rollup-plugin-dts -D

또한 peerDependencies를 빌드에 포함시키지 않기위해 peerDepsExternal도 설치해주었다.

npm i rollup-plugin-peer-deps-external -D

rollup.config.js

이런식으로 구성해주었다.

순서대로 esm, esm에 대한 index.d.ts, cjs, cjs에 대한 index.d.cts이다.

import babel from '@rollup/plugin-babel';
import { dts } from 'rollup-plugin-dts';
import resolve from '@rollup/plugin-node-resolve';
import peerDepsExternal from 'rollup-plugin-peer-deps-external';

const extensions = ['.js', '.jsx', '.ts', '.tsx'];
export default [
  {
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js',
      format: 'es',
    },
    plugins: [
      peerDepsExternal(),
      babel({
        babelHelpers: 'bundled',
        presets: [
          '@babel/preset-env',
          '@babel/preset-react',
          '@babel/preset-typescript',
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
    ],
  },
  {
    input: './src/index.ts',
    output: [{ file: 'dist/esm/index.d.ts', format: 'es' }],
    plugins: [dts()],
  },
  {
    input: './src/index.ts',
    output: {
      file: './dist/cjs/index.cjs',
      format: 'cjs',
    },
    plugins: [
      peerDepsExternal(),
      babel({
        babelHelpers: 'bundled',
        presets: [
          '@babel/preset-env',
          '@babel/preset-react',
          '@babel/preset-typescript',
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
    ],
  },
  {
    input: './src/index.ts',
    output: [{ file: 'dist/cjs/index.d.cts', format: 'cjs' }],
    plugins: [dts()],
  },
];

압축으로 용량줄이기

번들 사이즈를 최대한 줄이기 위해 압축도 해주었다.

uglify vs babel-minify vs terser

압축도 여러가지 선택지가 있었는데 uglify의 후속버전이 terser이고, rollup과 함께 사용하기때문에 추가적인 설정이 필요하지 않은 terser를 선택하게되었다. (babel-minify는 babel설정 파일이 또 필요한 것 같아 보인다.)

npm i @rollup/plugin-terser -D

최종 rollup.config.js

import babel from '@rollup/plugin-babel';
import { dts } from 'rollup-plugin-dts';
import resolve from '@rollup/plugin-node-resolve';
import peerDepsExternal from 'rollup-plugin-peer-deps-external';
import terser from '@rollup/plugin-terser';

const extensions = ['.js', '.jsx', '.ts', '.tsx'];
export default [
  {
    input: './src/index.ts',
    output: {
      file: './dist/esm/index.js',
      format: 'es',
    },
    plugins: [
      peerDepsExternal(),
      babel({
        babelHelpers: 'bundled',
        presets: [
          '@babel/preset-env',
          '@babel/preset-react',
          '@babel/preset-typescript',
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
      terser(),
    ],
  },
  {
    input: './src/index.ts',
    output: [{ file: 'dist/esm/index.d.ts', format: 'es' }],
    plugins: [dts()],
  },
  {
    input: './src/index.ts',
    output: {
      file: './dist/cjs/index.cjs',
      format: 'cjs',
    },
    plugins: [
      peerDepsExternal(),
      babel({
        babelHelpers: 'bundled',
        presets: [
          '@babel/preset-env',
          '@babel/preset-react',
          '@babel/preset-typescript',
        ],
        extensions,
      }),
      resolve({
        extensions,
      }),
      terser(),
    ],
  },
  {
    input: './src/index.ts',
    output: [{ file: 'dist/cjs/index.d.cts', format: 'cjs' }],
    plugins: [dts()],
  },
];

비교해보기

terser 적용전후

42.2kb에서 32.1kb로 압축된 것을 확인할 수 있다!

https://bundlephobia.com/package/@rapiders/react-hooks@1.2.2

bundlephobia에서 비교한 것은 거의 차이가 나지 않는다.

아무래도 용량 자체가 작아서 효과가 미미한 것도 있는 것 같다.

후기

꽤나 쉽지는 않았지만, 그리고 React-hooks라 보통 번들러와 함께 사용될 것이기때문에 별로 중요하지는 않지만... 어쨌던 목표했던 CJS, ESM을 모두 지원하는 라이브러리를 만들어보았다.

당연하게 사용하는 것들이 전혀 당연하지 않다는 것을 다시 한 번 알게된 경험이었다.

과정에서 typescript의 모듈 시스템을 깊게 학습할 수 있었고, rollup의 구성과 다양한 플러그인, 번들사이즈와 트리쉐이킹 등 다양한 것들을 학습할 수 있어 뜻깊었다.

typescript 컴파일러와 모듈 시스템에 대한 이해

_0422 — Fri, 3 May 2024 21:50:16 +0900

이전 게시글에서 확장자 문제에 부딪혔고, 이런 문제를 해결해보고자 했다.

이를 이해하기 위해서는 이 문서를 읽는게 직빵이었는데, 이 글에 해당 내용을 담으려고 읽다가 보니 그냥 번역해서 오픈소스에 기여해보는게 좋을거란 생각이 들어서 해보았다.

https://github.com/microsoft/TypeScript-Website-Localizations/pull/224

#6 Translate module-reference/Theory.md to korean by d0422 · Pull Request #224 · microsoft/TypeScript-Website-Localizations

en Theory 리뷰 요청합니다 : @yeonjuan @bumkeyy ref #6 감사합니다. 처음 해보는거라 잘 모르는 부분이 많습니다...! 혹시 이상한 부분이나 잘못된 부분이 있다면 가감없이 말씀해주세요!!!

github.com

이 글은 위 PR의 번역파일에 추가 설명을 더하고, 내용을 요약한 것이다.

typescript 컴파일러는 모듈에 대해 도대체 무슨 일을 하는가?

typescript의 주요목표는 컴파일시 런타임 오류를 미리 파악하여 방지하는 것이다.

이걸 생각해보면 typescript는 컴파일타임에 런타임 환경에 대해 알아야한다는 것을 알 수 있다.

그래서 모듈이 포함된 코드를 프로젝트에서 작성하게되면, ts컴파일러가 그냥 코드를 변환하는 작업을 수행하기에는 모호한점들이 발생하게된다.

예를들어 아래 코드를보자.

import sayHello from "greetings";
sayHello("world");

이 코드만을 봤을때 그냥 변환시키기에는 여러가지 모호한 점이 있다는 것을 알 수 있다.

1. greeting에 대한 타입스크립트 파일을 직접 로드할까(greeting.ts)? 아니면 TS컴파일러가 생성한 결과물 JS파일을 불러올까(greeting.js)?

2. greeting이라는건 파일이름인가? 아니면 디렉토리+파일의 별칭인가?

3. greeting 모듈은 ESM일까? CJS일까?

4. 이 코드 자체는 ESM으로 변환시킬까? 아니면 CJS로 변환시킬까?

5.greeting모듈이 분석됐을때, greeting의 어느부분이 어떻게 sayHello로 바인딩되는가?

이건 비단 typescript혼자서 결정하거나 대답할 수 있는게 아니다.

이 코드를 결국 사용하는게 node.js인지, 번들러인지, 혹은 브라우저인지에 따라 이게 달라지게 되는 것이다.

타입스크립트 docs는 트랜스파일링된 코드를 최종적으로 사용하는 곳을 호스트라고 정의했다.

호스트의 종류

트랜스 파일링된 결과 코드가 Node.js와 같은 런타임에서 직접 실행되는 경우 런타임이 호스트가 된다.
런타임이 TypeScript 파일을 변환업이 바로 사용하거나,"트랜스파일링된 JS 코드"가 없는 경우에도 런타임이 호스트이다.
번들러가 TypeScript 입력 또는 출력을 소비하고 번들을 생성하는 경우, 번들러가 호스트이다.
다른 트랜스파일러, 옵티마이저 또는 포맷터가 TypeScript의 트랜스파일링 결과를 실행하는경우에는 imports와 exports를 바꾸지 않는한 TypeScript가 신경 쓰는 호스트가 아니다.
TypeScript 컴파일러 자체는 다른 호스트를 모델링하는 것 외에 모듈과 관련된 어떠한 동작도 제공하지 않으므로 호스트가 아니다

typescript 컴파일러가 하는 일

import sayHello from "greetings";
sayHello("world");

다시 돌아와서 이런 코드를 트랜스파일링할때 타입스크립트는 호스트를 고려해서 아래의 일을 수행한다고 정리할 수있다.

파일을 유효한 모듈 형식(ESM, CJS)으로 변환해준다.
결과 코드에서 import가 실제로 잘 되는지 확인한다. (import한 코드 조각이 유효한지)
import한 요소의 타입을 할당한다. (ex) sayHello에는 string타입의 인자가 하나 들어오는구나!)

이번 게시글 및 docs에서는 module관련한 내용만 다루기때문에 3번에 대한 내용은 다루지 않는다.

1, 2번을 알아가보자.

1. typescript 컴파일러는 파일을 유효한 모듈 형식(ESM, CJS)으로 변환해준다.

tsconfig의 module필드

우리는 기본적으로 tsconfig의 module옵션을 통해 typescript컴파일러에게 어떤 형태의 모듈로 ts코드를 js로 트랜스파일링할 것인지를 변경시킬 수 있다.

이 module 옵션은 ESM이냐 CJS냐, ESM이면 몇 버전이냐만을 결정하는것 뿐만 아니라, moduleResolution방식에도 영향을 미친다.

예를들어 module옵션이 CommonJS인데, moduleResolution을 Bundler로 설정할 수는 없다.

또한 설정한 module버전에따라 ESM의 경우에는 top-level await와 같은 기능에도 영향을 미친다.

typescrit 컴파일러의 모듈 종류 자동 감지

typescript 컴파일러는 tsconfig뿐만 아니라 해당 파일의 파일확장자와 package.json을 읽어서 모듈 종류를 자동으로 감지하기도 한다.

그런데 이건 NodeJS와 동일한 방식으로 이뤄지므로, NodeJS의 모듈 종류 감지 방법을 먼저 이해해야한다.

NodeJS는 ESM과 CJS를 모두 이해한다. 하지만 어떻게 구성하냐에 따라 오류가 발생할 수 있다.

1. package.json의 type필드

package.json의 type필드를 module로 설정하면 근처 파일은 ESM으로 인식한다.

그게 아니라면, 즉, type필드의 값이 module이 아니거나 비어있다면 CJS가 되는 것이다.

2. .cjs, .mjs으로 설정하기

두번째는 package.json보다 우선순위가 높다. 바로 파일확장자를 통해 설정하는 방법이다.

파일 확장자를 cjs로 설정하거나, mjs로 설정하면 각각 CJS, ESM모듈로 해석한다.

typescript 컴파일러는?

타입스크립트 컴파일러는 tsconfig의 module이 node16이나 nodenext로 되어있을때, package.json의 type필드를 확인해서 모듈 종류를 파악한다.

또한, 파일 확장자가 .mts,.cjs 인경우 NodeJS와 동일하게 ESM, CJS로 이해하며 각각 트랜스파일링시 확장자가 .mjs, .cjs로 변경되게 된다.

2. typescript 컴파일러는 결과 코드에서 import가 실제로 잘 되는지 확인한다

이 부분이 가장 핵심이다. 얼핏 생각하기로는 ts컴파일러는 타입체크와 모듈 종류를 바꾸는 것에 특화되어있다고 오해하기가 쉬운데, 되돌아보면 import를 잘못하는 경우, tsc를 했을때 ts는 바로 화를 내준다.

ts컴파일러는 모듈이 실제로 있는지, import가 잘되는 것인지를 확인해주는 것이다.

예시는 직접 tsc를 실행한 것은 아니지만, 화를 낸다는 것을 확인할 수는 있어서 가져왓다.

모듈의 식별자(경로, 이름, 확장자)는 변환되지 않는다.

컴파일러 옵션의 module은 import, export 등을 CJS, ESM과 같은 다양한 모듈 종류로 변환할 수 있지만, 모듈의 경로, 이름, 확장자를 변환하지 않는다.

예를들어 아래와 같은 파일이 있다고 가정하자.

import { add } from "./math.mjs";
add(1, 2);

이걸 CJS로 변환해버리면 이렇게 변환이 된다.

const math_1 = require("./math.mjs");
math_1.add(1, 2);

모듈의 식별자(이름, 경로, 확장자)가 유지된 것이다.

즉, 모듈의 식별자는 컴파일러 옵션에 관계없이 항상 입력파일, 즉 ts파일에서 사용된 것 과 동일하다.

모듈 식별자를 변환, 대체, 또는 재작성할 수 있는 타입스크립트 컴파일러 옵션은 없다.

왜 변환해주지 않는가?

모듈을 실제로 import하여 소비하는 것인 호스트

모듈을 실제로 import하여 소비하는 것인 호스트이기 때문이다. 타입스크립트는 확인만 해줄 뿐이다.

ts코드 -> js코드 -> 소비의 흐름인데, ts코드에서 js코드로 넘어갈때 모듈의 식별자가 바뀌어버린다면, 최종 소비자는 예상치 못하게 오류를 맞이할 수 있고, 이는 타입스크립트의 제작 의도와는 정말 정 반대의 결과가 되어버린다.

따라서 변환해주지않는다.

모듈의 체크방식

ts는 어떻게 import "모듈"이 정상적인 구문인지 확인하는걸까?

아래와 같은 코드가 있다고 하자

// @Filename: math.ts
export function add(a: number, b: number) {
  return a + b;
}
// @Filename: main.ts
import { add } from "./math";
add(1, 2);

이러면 ./math가 유효한지 확인하는 방식을 생각해볼 수 있다.

이렇게 되는게 아닐까? 라고 하면 완전히 틀린건 아니지만 ,실제로는 이렇게 작동한다고한다.

실제로는 변환된 js파일을 통해 확인하는 것이다.

이걸 이해하면 이런 경우도 이해할 수 있다.

// @moduleResolution: node16
// @rootDir: src
// @outDir: dist
// @Filename: src/math.mts
export function add(a: number, b: number) {
  return a + b;
}
// @Filename: src/main.mts
import { add } from "./math.mjs";
add(1, 2);

main.mts파일에서 add함수를 math.mjs 에서 꺼내서 쓰고 있다...?

원래라면 뭔가 이상하다 느껴야 하지만, 위의 그림으로 이해하면 충분히 이해할 수 있다.

이런식으로 작동하는 것이다.

자 그럼 이 중간에 파일의 확장자를 마구 바꿔버린다면?

ts컴파일러가 제대로 import구문의 유효성을 검사할 수 없게된다.

따라서 확장자를 바꾸지 않는것이다.

그럼 라이브러리 코드는 어떻게 유효성 검사함?

라이브러리 코드는 tsc를 할수가 없다. 보통은 ts파일형태로 배포하지 않기때문이다.

그럼 ts컴파일러는 어떻게 라이브러리 코드에 대한 import문이 유효한지 확인할 수 있을까?

d.ts가 등장할때.

지금이 바로 d.ts가 활약할 때다.

d.ts는 수동으로 쓰기도하지만 보통은 tsc --declaration을 통해 만들어진다.

해당 명령어를 수행시키면 js파일과 d.ts파일이 하나 나오게된다.

이렇게 해서 만들어지는 d.ts파일이기때문에 d.ts파일이 있으면 typescript 컴파일러는 해당 d.ts에 해당하는 .js파일이 있다고 가정해버린다.

모든 module resolution에서 typescript는 d.ts파일을 찾고, 이걸 먼저 찾으면 더이상 .js파일을 찾지않는다. 왜냐하면 둘다 tsc를 통해 만들어지기 때문이다.

+) 라이브러리를 위한 컴파일 옵션

라이브러리 제작자라면, 어찌됐던 많은 곳에서 작동되기를 원한다.

moduleResolution을 bundler나 node10, esnext으로 설정해버리면, 확장자가 안붙는다. (ts 컴파일러는 확장자를 변환하지 않는다.)

따라서 번들러가 없으면 작동하지 않는것이다.

그래서 tsdocs에서는 moduleResolution을 nodenext로 설정하는걸 권장한다.

이를 통해 라이브러리 코드에 확장자를 붙여주면, 확장자가 들어가기때문에 번들러가 없는 nodeJS환경에서도 잘 작동되는 것을 확인할 수 있다.

후기

라이브러리를 만들다가 컴파일 결과에 도대체 왜 확장자가 안붙는건가? 고민하다가 여기까지 오게되었다.

꽤나 딥다이브해서 ts의 컴파일러에 대한 이해도를 높힐 수 있었고, 번역해서 최초로 오픈소스에 PR도 해볼 수 있어서 굉장히 시간은 많이 들었지만, 그만큼 많이 성장할 수 있었다.

라이브러리를 만들어 배포해보자 - (2) tsconfig와 ESM,CJS

_0422 — Thu, 2 May 2024 01:24:56 +0900

배경

이전 게시글에서 라이브러리를 tsc만으로 컴파일해서 배포했다.

그랬더니 아래와 같은 일이 발생한다.

번들러 없이는 아무것도 작동되지 않는...

CJS방식으로 require했을때도, ESM으로 import했을때도 잘 작동되지 않는다.

왜 이런일이 발생했을까?

모듈 시스템

그전에, 모듈 시스템 중 CJS와 ESM에 대해 살펴보자.

CJS

require와 module.exports를 통해 동작한다. 동기적으로 실행된다.

또한, 메인스레드를 블로킹한다. 즉, 모듈의 코드 실행까지 다음 진행이 차단되는 것이다.

exports되는 항목을 마치 object처럼 취급한다.

아래와 같은 코드가 있다고 하자.

//module.js
let num=20;
function setNum(n){
	num=n;
}

function getNum(){
	return num;
}

module.exports={
	num,
    setNum,
    getNum
}


//main.js
let {num, setNum} =require("./module.js");
let {num:num2} =require("./module.js);

위코드는 CJS에서 아래코드와 동일하게 동작한다.

let num=20;
function setNum(n){
	num=n;
}

function getNum(){
	return num;
}

let obj={
	num,
    setNum,
    getNum
}

let {num,setNum}={...obj};
let {num:num2}={...obj};

ESM

import, export를 통해 동작하며, 비동기적으로 실행될 수 있다.

비동기적 실행이란, 가져온 스크립트를 바로 실행하는게 아니라 import구문을 찾아서 스크립트를 파싱한다는 것이다.

ESM은 구성 -> 인스턴스화 -> 평가의 단계를 거쳐 수행된다.

구성

엔트리를 기준으로 import를 쭉 타고 올라가며 트리를 만들어낸다.

그리고 이를 통해 모듈 레코드라는 데이터 구조를 만들어낸다.

모듈 레코드에 대한 그림

요 과정에서 fetch url과 모듈 레코드를 매핑한다.

그래야 한번 fetch가 완료된 모듈을 다시 다운로드 받지 않기 때문이다.

인스턴스화

export되는 값을 저장할 메모리 공간을 찾아놓고, export하는 코드와 import하는 코드가 모두 같은 메모리 공간을 가리키도록 연결한다.

이그림을 가져왔는데 코드와 함께보면 이런식으로 된다는 것이다.

평가

이제 위 그림에서 검정색 부분에 1을 채워 넣는다.

또한, import로 접근한 메모리 값을 바꿀수는 없다.

결론

이 둘이 동작하는 방식은 너무나도 다르다.

둘이 호환될 수 없는 것이다.

왜?

이제 다시 돌아와서 이전에 설정한 것들을 기반으로 안되는 이유를 분석해보자.

package.json

우선, 이전 게시글에서 살펴본 package.json을 다시 보자.

{
  "name": "@rapiders/react-hooks", //패키지의 이름
  "version": "0.0.9",
  "description": "react hooks for fast development",
  "main": "dist/index.js", //entry point
  "types": "dist/index.d.ts", //entry point의 타입
  "homepage": "https://github.com/d0422/react-hooks",
  "scripts": {
    ...
  },
  "keywords": [
	...
  ],
  "author": "d0422 <rlfehd2013@naver.com>",
  "license": "MIT",
  "peerDependencies": { 
	...
  },
  "devDependencies": {
    ...
  }
}

여기 보면 type 필드가 빠져있는 것을 확인할 수 있다.

type 필드가 빠지게 되면 프로젝트는 CJS를 따르게된다.

https://nodejs.org/api/packages.html

npm배포된 결과, 즉 다운로드되는 라이브러리도 package.json을 통해 엔트리포인트에 접근하기 때문에 dist 내부의 모듈들은 CJS방식을 따라야한다.

그러나...

dist내부의 index.js를 보면 ESM방식으로 트랜스파일링 됐다는 것을 확인할 수 있다.

이 원인은 ts파일이 ESM방식으로 트랜스파일링됐기 때문이다.

원인 파악

아하...! 그럼 이제 현상을 정리할 수 있다.

라이브러리를 CJS 형태로 읽으라고 package.json에 적어둠
근데 라이브러리 트랜스파일링을 ESM으로 해둠
따라서 CJS로도, ESM으로도 읽을 수 없는 코드가 되어버림

해결을 위한 분석

그렇다면.... 이젠 tsconfig.json을 다시 살펴볼때이다.

tsconfig.json

tsconfig의 module과 moduleResolution이 트랜스파일링시 모듈방식을 결정한다.

{
  ...
  "compilerOptions": {
    "module": "ESNext", 
    "moduleResolution": "Bundler" 
  }
}

따라서 바로 여기가 문제인 것이다.

여기서 module이 ESNext로 되어있는데, 이래서 ESM방식으로 트랜스파일링됐던 것이다.

따라서 module필드의 값을 CJS, CommonJS로 변경해줘보았다.

CommonJS로 변경해주면 moduleResolution이 불같이 화를 내는 것을 확인할 수있다.

번들러 옵션은 module이 preserve나 es2015이상일때만 쓸수있다고한다.

왜 이런것일까? 이걸 생각하다보니 tsconfig의 module, moduleResolution에 대한 이해도가 굉장히 떨어진다는 것을 알 수 있었다.

module, moduleResolution

tsconfig의 module은 ts파일이 js로 변환될때 어떤 형태로 변환될 것인지를 말한다.

moduleResolution은 모듈 해석으로, 컴파일러가 모듈 이름을 읽을때, 어떻게 모듈을 가져올지를 정해주는 것을 말한다.

module

module이 바로 ESM과 CJS를 결정하는 필드다.

ES6, ES2015, ES2020, ESNest가 ESM방식이고

CommonJS가 CJS이다.

NodeNext/Node16

이중 Node16과 NodeNext가 무엇인지 헷갈렸었는데, 이는 nodejs환경에서 ESM을 지원하기위한 옵션이다.

package.json의 type필드가 무엇이냐에 따라 트랜스파일링방식이 바뀐다.

이러면 import시 확장자가 반드시 붙어야한다.

package.json의 type필드를 바꿔가면서 tsc시켜보면 결과가 다르다는 것을 알 수있다.

왼쪽이 module, 오른쪽이 type필드가 비었을때의 tsc결과이다.

moduleResolution 방식

이러한 방식이 있는 것을 확인할 수 있다.

https://www.typescriptlang.org/tsconfig/#moduleResolution

1. node16, nodenext는 require(CJS), import(ESM)을 모두 지원한다.

2. node10은 이전에는 node라는 이름이었는데, CJS만 지원한다.

3. bundler는 번들러와 함께 사용할때 사용한다. 가져오기시 상대 경로에 파일 확장자를 요구하지 않는다고한다.

4.Classic은 ts1.6버전 이전에 쓰이던거라서 사용하지말라고한다.

따라서 NodeNext를 사용하면 ESM을 지원하게 만들 수 있다.

결론

두가지 방향이 있다.

CJS로 통일
ESM으로 통일

package.json이 CJS이므로, CJS형태로 통일해주었다.

{
  ...
  "compilerOptions": {
    "module": "CommmonJS", 
    "moduleResolution": "Node10" 
  }
}

ESM으로 통일하려면 package.json에 type필드를 module로 변경해주면된다.

CJS와 ESM가 모두 지원되는 라이브러리를 만들 수는 없을까?

그러던 중 토스의 아래 글을 보게되었고, package.json의 exports필드를 사용하면 호환가능한 라이브러리를 만들 수 있다는 것을 알게 되었다.

https://toss.tech/article/commonjs-esm-exports-field

CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field

Node.js에는 두 가지 Module System이 존재합니다. 토스 프론트엔드 챕터에서 운영하는 100개가 넘는 라이브러리들은 그것에 어떻게 대응하고 있을까요?

toss.tech

요걸 보고 아이디어를 얻어서 tsconfig를 두개 만들어서 두번 트랜스파일하는 방식을 구성했다.

package.json

type을 module로 바꾸어 ESM을 기본으로 사용하게 했다.

그리고 exports필드를 사용해 dist/esm, dist/cjs에 각각 빌드 결과를 배치시키고 cjs확장자를 통해 require시 CJS가 지원되도록 만들어주었다.

{
  "name": "@rapiders/react-hooks",
  ...
  "main": "dist/esm/index.js",
  "types": "dist/esm/index.d.ts",
  "exports": {
    ".": {
      "require": "./dist/cjs/index.cjs",
      "import": "./dist/esm/index.js"
    }
  },
  "scripts": {
    "build": "sh build.sh",
	...
  },
  ...
  "type": "module"
}

tsconfig.json

{
  "include": ["src"],
  ...
  "compilerOptions": {
    "outDir": "./dist/esm", //esm폴더에 트랜스파일링 결과를 둔다
    "module": "ESNext", //ESM
    ...
  }
}

그리고 tsconfig.cjs.json을 만들어서 CJS로 트랜스파일링 할 수 있도록 해주었다.

tsconfig.cjs.json

{
  "include": ["src"],
  ...
  "compilerOptions": {
    "outDir": "./dist/cjs", //cjs폴더에 트랜스파일링 결과를 둔다
    "module": "CommonJS", //CJS
    "moduleResolution": "Node10",
  }
}

build.sh

빌드 스크립트가 너무 길어지는 것 같아서 빌드용 파일을 따로 분리해주었다.

rm -rf ./dist 
mkdir dist 
tsc --project tsconfig.cjs.json 
tsc --project tsconfig.json

이러면 CJS와 ESM 파일을 모두 지원하는 라이브러리 구성이 된...줄 알았으나....

확장자 문제

이제 다 해결됐나 싶었지만, 여전히 작동이 안된다... 확장자가 없기 때문이다.

그렇다... 생각해보니 번들러 없이는 ESM에서는 확장자 생략이 안되는게 당연하다.

그렇다면 트랜스파일링 결과에 확장자를 달아줄 수는 없을까?

이걸 이해하려면 이 문서를 읽는게 직빵이다.

결론은 안된다다.

이 내용을 번역해서 작성하면 글이 너무 길어지므로, 이 부분은 다음게시글에 작성을 하도록 하겠다.

참고

1. [javascript] 모듈시스템 -CJS, ESM 동작원리 - https://blog.naver.com/pjt3591oo/222834625061

2. 내가 보려고 정리한 tsconfig(2) - https://velog.io/@milkboy2564/%EB%82%B4%EA%B0%80-%EB%B3%B4%EB%A0%A4%EA%B3%A0-%EC%A0%95%EB%A6%AC%ED%95%9C-tsconfig2#module

3. Module - Theory - https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-bundlers-typescript-runtimes-and-nodejs-loaders

4. ES modules:A cartoon deep-dive - https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/

5. CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field - https://toss.tech/article/commonjs-esm-exports-field

라이브러리를 만들어 배포해보자 - (1) tsc만으로 기본 설정하기

_0422 — Tue, 30 Apr 2024 21:33:39 +0900

배경

아직 대학생이기에, 아직 취업을 하지 못하기에 최근에 용돈벌이용으로 외주를 시작했다.

첫 외주를 진행하다가 문득, 보통 외주를 통해 개발하는 웹페이지는 구성, 기능들이 어느 정도 비슷할 수 있다 생각하게되었다. 특히 랜딩페이지와 같이 사용자 UI를 신경써야하는 부분은 더욱 그런 기능이 겹치기 마련이다.

그래서 이런 부분들을 빠르게 개발하기위해 자주 반복되는 로직을 react-hook형태로 모아보자는 다짐을 하게되었다.

이번 글에서는 기본적인 설정만 간단하게~~(아무생각없이...)~~ 하기에 간단하게 살펴보고, 이로인해 발생한 문제들을 다음 게시글에서 해결해 볼 것이다.

기본 설정

package.json

아래와 같이 구성해주었다.

{
  "name": "@rapiders/react-hooks", //패키지의 이름
  "version": "0.0.9",
  "description": "react hooks for fast development",
  "main": "dist/index.js", //entry point
  "types": "dist/index.d.ts", //entry point의 타입
  "homepage": "https://github.com/d0422/react-hooks",
  "scripts": {
    "test":"jest",
    "prepare": "npm run build", //npm publish전에 수행된다.
    "build": "rm -rf ./dist && tsc", //기존의 dist를 지우고 tsc로 최신 ts를 js로 트랜스파일링한다.
    "storybook": "storybook dev -p 6006",
    "build-storybook": "storybook build"
  },
  "keywords": [
    "react",
    "hooks"
  ],
  "author": "d0422 <rlfehd2013@naver.com>",
  "license": "MIT",
  "peerDependencies": { 
	//React와 React-dom을 번들에 포함시키지 않되, 해당 라이브러리를 사용하는 라이브러리이기때문에 
	//아래와 같이 작성한다.
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@types/react": "^18.2.75",
    "@types/react-dom": "^18.2.24",
    "typescript": "^5.4.4"
  }
}

tsconfig.json

타입스크립트를 사용하여 구성하였기때문에 tsconfig를 설정해주었다.

{
  "include": ["src"], //src내용만 트랜스파일링한다.
  "exclude": ["node_modules"], //node_modules는 포함하지 않음
  "compilerOptions": {
    "outDir": "./dist", //결과파일을 dist에 둔다.
    "module": "ESNext", //다음게시글에서 더 자세하게 알아보자
    "target": "ES2020", //트랜스파일링완료한 js의 문법
    "lib": ["ES2020", "DOM", "DOM.Iterable"], //js로 컴파일할때 사용할 lib
	//Promise등의 문법을 사용하려면 ES2015이상이 되어야한다.
	//DOM API를 사용하려면 DOM이 필요하다.
    "jsx": "react", //jsx 해석을 React.createElement로 해석
    "sourceMap": true,
    "declaration": true, //index.d.ts
    "esModuleInterop": true, //commonJS모듈을 ESM형태로 가져올 수 있도록
    "typeRoots": ["index.d.ts", "node_modules/@types"],
    "strictNullChecks": true,
    "moduleResolution": "Bundler" //moduleResolution은 모듈을 가져오는 방식을 말한다.
  }
}

이렇게 처리한 뒤에, index.ts에서 모든 파일을 import해서 객체형태로 내보내주었다.

//index.ts
import useInput from './useInput/useInput';
import useAnimation from './useAnimation/useAnimation';
import useFocusAnimation from './useFocusAnimation';
import { useDragCarouselIndex } from './useDragIndexCarousel/useDragIndexCarousel';
import useDragIndexCarousel from './useDragIndexCarousel/useDragIndexCarousel';
import useCarousel from './useCarousel/useCarousel';
import useScrollRatio from './useScrollRatio';

export {
  useInput,
  useAnimation,
  useFocusAnimation,
  useDragCarouselIndex,
  useDragIndexCarousel,
  useCarousel,
  useScrollRatio,
};

빌드

이제 빌드를 해보면 dist내에 tsc를 통해 컴파일된 js파일이 생기는 것을 확인할 수 있다.

테스트 환경 구성

jest와 testing-library를 활용해서 테스트를 구성해주었다.

//jest.setup.ts
import '@testing-library/jest-dom';

//jest.config.ts
import { compilerOptions } from './tsconfig.json';
import { pathsToModuleNameMapper } from 'ts-jest';

module.exports = {
  testEnvironment: 'jsdom', //jsdom으로 설정해야 DOM없이도 렌더링이 가능하다 (진짜 렌더링은 아님)
  transform: {
    '^.+\\.tsx?$': 'ts-jest', 
  },
  preset: 'ts-jest',
  rootDir: '.',
  testMatch: ['**/?(*)+(test).ts', '**/?(*)+(test).tsx'],
  setupFilesAfterEnv: ['./jest.setup.ts'],
  resetMocks: true,
  // tsconfig의 compilerOptions의 paths를 그대로 넘겨주는 것을 확인할 수 있다.
  // 이를 통해 tsconfig에서 지정한 절대경로를 사용할 수 있게된다.
  moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths, {
    prefix: '<rootDir>',
  }),
};

storybook 구성하기

라이브러리 Docs용으로 storybook을 사용하기로 결정했다.

https://rapiders.github.io/react-hooks

@storybook/cli - Storybook

rapiders.github.io

github pages를 통해 main에 push시 자동으로 배포되도록 구성해주었다.

미리 구성된 actions들이 많아서 쉽게 구성할 수 있엇다.

# Workflow name
name:   Storybook 배포

on:
  push: //푸시될때
    branches:
      - 'main' //main브랜치에
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: ✅ 코드 체크 아웃
        uses: actions/checkout@v3

      - name: ✅ 노드 세팅
        uses: actions/setup-node@v3
        with:
          node-version: '20.x'

      - name:   빌드
        run: |
          npm ci
          npm run build-storybook

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v2.0.0
        with:
          path: storybook-static //storybook-static파일을 업로드

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.build-publish.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name:   스토리북 배포
        id: deployment
        uses: actions/deploy-pages@v3 //해당 actions를 사용해서 github page로 배포한다.
        with:
          token: ${{ github.token }}

.npmignore

npm배포시 배포되지 않을 파일을 명시해주면된다!

// .npmignore
node_modules/
src
.gitignore
tsconfig.json
.git
.storybook
jest.config.ts 
jest.setup.ts
build-storybook.log
storybook-static
.github

배포를 해보자

npm publish

이제 npm publish를 해서 배포를 해주면 된다!

npm login을 해주고 , npm publish를 해주면 배포가 된다!

겪은 이슈

나 같은 경우 @rapiders/react-hooks라는 organization형태로 배포를 시도했기때문에 organization이 없기때문에 발생한 오류였다.

npm에서 organization을 만들어주고 npm publish --access public을 통해 배포해주면된다!

이렇게 배포를 해보았다!

이렇게 하여 최근 외주 받은 프로젝트에 적용시켜보았다

문제 발생

이렇게 구성한 라이브러리는 번들러가 들어간 환경에서는 매우 잘 작동했으나...

번들러 없는 환경에서는 잘 작동하지 않는 문제가 발생했다.

처음에는 아하~ package.json에서 type을 module로 줘서 그렇구나~ 라고 생각해서 해당 설정을 바꾸고 다시 실행시켰는데...

이것도 안되고 저것도 안된다는 것을 알 수 있다.

다음 게시글에서 이러한 문제를 해결해서 라이브러리를 CJS와 ESM에서 모두 동작하도록 만들어 볼 것이다.

불굴의 의지로 살아내기 - 노인과 바다

_0422 — Mon, 1 Apr 2024 16:25:13 +0900

130페이지정도의 짧은 이 소설이 왜 세기의 명작인지 알 수 있게 되었다. 정말 추천한다.

삶은 꽤나 허무하고, 무의미하다. 결과적으로 노인이 잡은 물고기는 앙상한 뼈만을 남겼다.

그러나, 그 고기를 잡기까지의 고통, 그리고 그것을 견뎌내는 노인의 의지는 너무나도 아름답다.
한번만 더...! 한번만 더..! 를 속으로 외치며 삶과 투쟁하는 모습을 보며 정말 숭고함을 느낄 수 있었다.

내가 견디지 못할 것 같아. 아냐, 그럴 리가 없어, 하고 그는 스스로에게 타일렀다. 난 언제까지나 끄떡없을 거야....머리를 맑게 해야해. 머리를 맑게 해서 어떻게 하면 인간답게 고통을 견딜 수 있는지를 알아야 해. 아니면 고기처럼 말이지.

하지만 한 번만 더 시도해 봐야지.
(...)
노인은 다시 한 번 시도해 보았다.
(...)
다시 한 번 해 봐야지 하고, 노인은 마음속으로 다짐했다.
(...)
그는 다시 한 번 시도해 보았지만 역시 마찬가지였다.
(...)
또 한 번 시도해보자.
(...)
노인은 모든 고통과 마지막 남아있는 힘, 그리고 오래전에 사라진 자부심을 총 동원해 고기의 마지막 고통과 맞섰다.

하지만, 그가 살라오(스페인어로 가장 운이 없는 사람)인 탓일까, 삶은 부조리하고, 안 좋은 일은 계속해서 일어난다.
어렵게 잡은 물고기의 피는 상어를 불러오고, 그들에 의해 뼈만 남게 된다.

그 과정에서도 노인은 희망을 버리지 않고, 도망치지도 않으며, 상어와 끝까지 싸운다.

결국 뼈만 남았지만, 아무것도 남지 않았지만, 노인은 끝까지 싸웠다.

인간은 파괴당할 순 있지만, 패배 당할수는 없다.

결과는 아무래도 좋다. 삶 자체의 의미보다는 내가 삶을 대하는 태도가 중요한 것이다.

그리고 자신의 일과 자신의 태도를 믿어주는 사람이 있다는 것도 굉장히 중요한 것 같다.
마놀린은 노인을 걱정하고, 그가 지지 않았다고 응원한다.

그는 노인이 끝까지 싸웠다는 것을 알고, 믿고 있는 것이다.

최근 부조리한 일들을 많이 겪고 있다. 정말 되는 일이 없다고 느낄 정도다. 이때 노인과 바다를 읽게 되어 참 다행이라고 생각했다.

나의 마놀린에게 감사를 표하며 글을 마친다.

모노레포 Vite 경로의 마법사를 해부해보자 - vite-tsconfig-paths

_0422 — Sun, 24 Mar 2024 00:04:38 +0900

어떻게? 왜 작동하는가?

자 이전글에서 모노레포에서 tsconfigPath의 마법 같은 경로문제 해결 기능을 보았다.

하지만, 개발자라면 마법과 같은 일은 없으리라는 것을 알고 있을 것이다. 결국 왜? 를 알아야 내 것이 되는 것이다.

어떻게 tsconfigPath가 경로문제를 해결했는지 확인해보자.

바쁜 분은 결론만 보아도 이해에 도움이 될 수 있을 것 같다.

viteFinal

.storybook/main.ts의 viteFinal은 vite-builder를 통해 storybook을 구성하는 경우에 사용되는 옵션이다.

추가적인 플러그인을 적용시키는게 가능하다.

즉 아래 코드는 기존 storybook vite의 config를 가져와서 tsconfigPath plugin을 적용시킨 후에 merge하고, 이를 return하는 것이다.

  viteFinal: async (config) => {
    return mergeConfig(config, {
      plugins: [tsconfigPath()],
    });
  },

tsconfigPath는 어떻게 경로를 가져오는가?

오랜만에 소스코드를 뜯어봤다.

https://github.com/aleclarson/vite-tsconfig-paths/blob/master/src/index.ts

vite-tsconfig-paths/src/index.ts at master · aleclarson/vite-tsconfig-paths

Support for TypeScript's path mapping in Vite. Contribute to aleclarson/vite-tsconfig-paths development by creating an account on GitHub.

github.com

27번째 줄부터 우리가 사용했던 tsconfigPath 함수의 선언부이다.

이걸 읽기위해서는 vite Plugin의 양식에 대해 알아야한다.

결국 이 함수를 통해 반환된 객체가 vitePlugin으로써 적용되는 것이기 때문이다.

enforce

https://ko.vitejs.dev/guide/using-plugins.html#enforcing-plugin-ordering

enforce는 Vite코어 플러그인보다 먼저 실행할지, 이후에 실행할지를 결정지어준다.

즉, 이 플러그인은 'pre'로써 Vite의 코어 플러그인보다 먼저 실행된다.

configResolved

https://ko.vitejs.dev/guide/api-plugin.html#configresolved

이 메서드의 첫번째 인자를 통해 지금까지 설정된 config값을 읽어올 수 있다.

그럼 이제 코드를 읽어보자.

    async configResolved(config) {
      let projectRoot = config.root //config에서 vite.config.ts가 있는 경로를 가져옴
      let workspaceRoot!: string

      let { root } = opts //opts는 tsconfigPath함수를 호출할때 넣어주는 인자이므로, 우리는 undefined이다
      if (root) { //따라서 root도 undefined이므로
        root = resolve(projectRoot, root)
      } else {
       //여기가 수행된다.
        workspaceRoot = searchForWorkspaceRoot(projectRoot)//이건 vite의 api다.
      }

https://ko.vitejs.dev/guide/api-javascript.html#searchforworkspaceroot

자 여기서 searchForWorkspaceRoot를 찾아보면 모노레포의 최상단 root를 가져온다는 것을 알 수 있다.

그럼 이제 workspaceRoot는 모노레포의 최상단이된다.

      const tsconfck = await import('tsconfck') // tsconfck라이브러리를 사용해서

      const projects = opts.projects //opts가 undefined이므로 삼항연산자의 뒤쪽을 본다.
        ? opts.projects.map((file) => {
           ...
          })
          
          //여기를 봐야한다.
        : await tsconfck.findAll(workspaceRoot, { 
            configNames: opts.configNames || ['tsconfig.json', 'jsconfig.json'],
            skip(dir) {
              return dir == 'node_modules' || dir == '.git'
            },
          }) //findAll메서드를 찾아봐야한다.

tsconfck의 findAll을 찾아보자.

https://github.com/dominikg/tsconfck/blob/main/docs/api.md

findAll은 해당 디렉토리에서 tsconfig.json파일을 죄다 찾아서 절대 경로를 반환한다.

그런데 workspaceRoot를 넣었으니 전체 모노레포에서 tsconfig.json의 절대경로를 모두 찾아오는 것이다.

그럼 이제 projects 변수는 모노레포의 모든 tsconfig.json의 절대경로를 갖게된다.

계속 진행해보자.

let hasTypeScriptDep = false

... //중간에 hasTypeScriptDep가 바뀌는 조건문이 있으나 우리 상황하고는 다른 상황이라 뺐다.

const parsedProjects = new Set( //새로운 집합 객체를 만듦
await Promise.all(
  projects.map((tsconfigFile) => {//모든 tsconfigFile경로에 대해
    if (tsconfigFile === null) {
      debug('tsconfig file not found:', tsconfigFile)
      return null
    }
    return (
      hasTypeScriptDep //false이다.
        ? tsconfck.parseNative(tsconfigFile, parseOptions)
        : tsconfck.parse(tsconfigFile, parseOptions) //이 친구가 수행된다. parse함수를 찾아보자
    ).catch((error) => {
         ...
    })
  })
)
)

parse는 어떤함수인가?

https://github.com/dominikg/tsconfck/blob/main/docs/api.md

위 사진을 보면 parse의 반환값은 TSConfckParseResult이다.

반환값이 tsconfigFile, tsconfig, solution, referenced, extended을 가진 객체라는걸 알 수 있다.

이제 parsedProjects는 위의 요소를 가진 유일한 객체의 집합이라는 것을 알 수 있다.

resolversByDir = {}
parsedProjects.forEach((project) => { //아까 가져온 객체들의 집합을 순회한다.
if (!project) {
  return
}
if (project.referenced) { // project의 tsconfig에 있는 referenced를 읽어서 있다면
  project.referenced.forEach((projectRef) => { 
    parsedProjects.add(projectRef) //tsconfig의 referenced인 tsconfig을 다시 project에추가한다. 
  }) //이래서 Set자료형을 사용한 것이다.
  parsedProjects.delete(project) //오버라이딩을 막기위해 지웠다가 다시 추가한다고한다.
  parsedProjects.add(project) //(코드 주인 피셜, 영어주석은 가독성을 위해 지웠다.)
  project.referenced = undefined
} else {
  ...
}
})
},

자 이렇게 referenced가 있는 tsconfig파일은 재귀적으로 Set객체 내부에 쫙 펴지게 된다.

그러면 referenced가 없는 tsconfig만 Set에 남게되기때문에 반드시 else문과 만나게된다.

그럼 else문을 살펴보자.

const resolver = createResolver(project) 
//실제로 파일을 가져오는 resolver를 만들어주는 것 같다. 함수를 좀더 자세히 살펴보자.

if (resolver) { //resolver를 성공적으로 만들었다면
const projectDir = normalizePath(dirname(project.tsconfigFile)) //tsconfigFile의 정규화된 경로를 얻어옴
const resolvers = (resolversByDir[projectDir] ||= []) 
// 얻어온 tsconfigFile경로로 resolversByDir객체에서 얻어와서 이걸 resolvers에 할당함
// 근데 해당 tsconfigFile경로에 해당하는 resolversByDir의 값이 없다면 빈배열을 resolverByDir[projectDir]에 할당하고
// 그걸 resolvers에 할당함
resolvers.push(resolver) //resolvers에 방금 만들어진 resolver를 push함
}

그림으로 그려보면 아래와 같이 정리할 수 있다.

createResolver

자 이제 위 객체의 value 배열에 들어갈 resolver를 어떻게 만들어 내는지 확인해보자.

  function createResolver(project: TSConfckParseResult): Resolver | null {
    const configPath = normalizePath(project.tsconfigFile)
   //tsconfigFile의 절대경로위치를 정규화해서 가져온다.
    const config = project.tsconfig as { //tsconfig파일의 내용을 가져온다.
      files?: string[]
      include?: string[]
      exclude?: string[]
      compilerOptions?: CompilerOptions
    }

    const options = config.compilerOptions || {}
    const { baseUrl, paths } = options //compilerOptions에서 제공한 baseUrl과 path다!

드디어 작성한 절대경로에 접근할 수 있는 baseUrl과 paths 가 등장했다! 계속 가보자.

    type InternalResolver = (
      viteResolve: ViteResolve,
      id: string,
      importer: string
    ) => Promise<string | undefined>

    const resolveWithBaseUrl: InternalResolver | undefined = baseUrl
      ? (viteResolve, id, importer) => viteResolve(join(baseUrl, id), importer)
      : undefined 
      //여기서 viteResolve는 vite의 함수이고,
      // id는 해석할 모듈의 경로, importer는 해당 모듈을 가져오는 파일의 경로이다.
      
      //baseUrl값이 없다면 resolveWithBaseUrl은 undefined가 되고,
      //아니라면 함수, id, importer를 받아서 해당 함수를 baseUrl+id한 경로, importer와 함께
      //인자로 해서 호출하는 함수를 할당한다.
     

    let resolveId: InternalResolver
    if (paths) { //지정한 path가 있다면
      const pathMappings = resolvePathMappings(
        paths,
        baseUrl ?? dirname(configPath) //baseUrl이 있으면 그값을
        // 없다면 tsconfig가 있는 디렉토리를 넘긴다.
      )

resolvePathMappings이 중요해 보인다. 코드를 읽어보자.

export function resolvePathMappings(
  paths: Record<string, string[]>,
  base: string
) {
  const sortedPatterns = Object.keys(paths).sort(
    (a: string, b: string) => getPrefixLength(b) - getPrefixLength(a)
  ) //패턴을 Prefix 길이 별로 정렬한다.
  const resolved: PathMapping[] = []
  for (let pattern of sortedPatterns) {
    const relativePaths = paths[pattern] //해당 패턴의 상대경로를 가져온다.
    //ex) @/*: ["src/*"]인경우 relativePaths는 ["src/*"]이 된다.
    pattern = escapeStringRegexp(pattern).replace(/\*/g, '(.+)')
    resolved.push({
      pattern: new RegExp('^' + pattern + '$'),
      //key에 해당하는 값을 정규식 패턴으로 저장한다.
      paths: relativePaths.map((relativePath) => resolve(base, relativePath)),
      //base에 붙여서 상대 경로를 반환한다.
    })
  }
  return resolved //전체 tsconfig에서 지정한 절대 경로 가 pattern, paths를 가진 객체 배열로 변환된다.
}

여기부분이 tsconfig에서 지정한 절대경로를 객체형태로 변환해서 읽는 부분이다.

이렇게 얻어온 pathMappings를 어떻게 사용하는지 보자.

// -------------------읽은 부분이다.---------------
if (paths) {
      const pathMappings = resolvePathMappings(
        paths,
        baseUrl ?? dirname(configPath)
      )
      //여기까지 pathMappings을 가져왔다.
// -------------------읽은 부분이다.---------------

      const resolveWithPaths: InternalResolver = async (
        viteResolve,
        id,
        importer
      ) => {
        for (const mapping of pathMappings) {
          const match = id.match(mapping.pattern) 
          //인자로 받은 id가 아까 pathMapping안에 있던 패턴과 일치하는 지 확인한다.
          if (!match) {
            continue
          }
          for (let pathTemplate of mapping.paths) {
            let starCount = 0
            const mappedId = pathTemplate.replace(/\*/g, () => {
              const matchIndex = Math.min(++starCount, match.length - 1)
              return match[matchIndex]
            }) //mappedId를 통해 와일드 카드를 실제 경로로 치환해준다
            //ex) src/* -> src/components
            const resolved = await viteResolve(mappedId, importer)
            if (resolved) {
              return resolved
            }
          }
        }
      }

여기까지 resolveWithPaths라는 함수가 와일드카드가 포함된 패턴을 실제 경로로 매칭시켜주는 일을 한다는 것을 알 수 있다. 계속 가보자.

  if (resolveWithBaseUrl) { //baseUrl이 있어서 undefined가 아닌상태라면
        resolveId = (viteResolve, id, importer) =>
        //선언한 resolveWithPaths를 통해 경로를 가져온다.
          resolveWithPaths(viteResolve, id, importer).then((resolved) => {
          //resovled되지 않았다면, baseUrl에서 찾아온다.
            return resolved ?? resolveWithBaseUrl(viteResolve, id, importer)
          })
      } else {
        resolveId = resolveWithPaths //위에 선언한 resolveWithPaths를 resolveId에 할당한다
      }
    } else {
    	//여기의 else는 path가 없는 경우이다.
      resolveId = resolveWithBaseUrl! //기본 resolveWithBaseUrl을 할당한다.
    }

여기까지보면 resolveId에 resolveWithPaths나 resolveWithBaseUrl을 통해서 viteResolve를 호출할 함수를 할당해주고있다는 것을 알 수 있었다.

이후에도 많은 부분이 있었지만 주요 골자가 아니므로 return부로 넘어가자

 return async (viteResolve, id, importer) => { //잘보면 함수를 반환한다는걸 알 수 있다.
       ...

      importer = normalizePath(importer)
	  ...
      
      path = await resolveId(viteResolve, id, importer)
      //path를 절대경로를 통해 viteResolve함수를 실행시키는 resolveId함수로 얻어온다.
 
      return [path && suffix ? path + suffix : path, true]
      //suffix는 Vite의 접미사인데, 요부분은 신경쓰지 않고 코드를 따로 보지 않았다.
      // return [path,true] 라고 봐도 현재 읽고 있는 관점에서는 무방하다고 생각한다.
    }
  }
}

이렇게 createResolver를 호출하면 path가 담긴 array를 반환하는 resolver함수가 반환된다는것을 확인할 수 있었다.

자 여기까지가 configResolved함수가 호출됐을때 일어나는 일이었다.

configResolved 정리

위 과정을 통해 모노레포에서 configResolved가 호출되었을때 아래와 같이 작동한다는 것을 알 수 있다.

그런데 이건 Vite값이 확정된 후 호출되는 훅이다.

이렇게 만든 resolversByDir는 어디서 사용하는가?

바로 resolveId이다. 마지막으로 resolvedId메서드를 보자.

resolveId

이 메서드가 모듈을 불러올때마다 호출되어, 실제로 그 역할을 해내게 된다.

 async resolveId(id, importer, options) {
      if (importer && !relativeImportRE.test(id) && !isAbsolute(id)) {
        ...
        //여기가 바로 위에서 그토록 썼던 viteResolve의 본체다
        const viteResolve: ViteResolve = async (id, importer) =>
          (await this.resolve(id, importer, resolveOptions))?.id 
          //vite의 this객체에서 resolve메서드를 사용하는 것으로 보인다.

        let prevProjectDir: string | undefined 
        let projectDir = dirname(importer) //import하려는 모듈의 디렉터리

        loop: while (projectDir && projectDir != prevProjectDir) { 
        //tsconfig과 만날때까지 폴더를 거슬러 올라가며 경로를 탐색한다.
          const resolvers = resolversByDir[projectDir] //미리만들어둔 객체에서 resolvers를 가져온다.
          if (resolvers)
            for (const resolve of resolvers) {
              const [resolved, matched] = await resolve(
                viteResolve,
                id,
                importer
              )
              if (resolved) {
                return resolved //모듈을 resolve시킨다.
              }
              if (matched) {
                // Once a matching resolver is found, stop looking.
                break loop
              }
            }
          prevProjectDir = projectDir //이전경로를 현재경로로
          projectDir = dirname(prevProjectDir) //현재 경로 폴더의 경로를 얻으므로 한단계 상위로 올라가게 된다.
        }
      }
    },
  }

resolveId정리

위 코드를 통해 모노레포에서 어느 곳에서든 vite를 통해 특정 모듈을 요청할때마다 아래와 같이 작동한다는 것을 알 수 있다.

정리

1. Vite 서버가 실행되면 configResolved가 수행되며, 이때 아래의 그림 과정을 통해 모노레포에서 tsconfig에 따라 모듈 상대/절대경로를 정해주는 resolversByDir 객체를 만들어둔다.

2. 모듈이 요청되면 resolveId가 수행되며 해당 모듈이 있는 디렉토리부터 상위 디렉토리로 이동하며 tsconfig이 있는 디렉토리까지 이동한다. 그러면 resolversByDir 에 resolver함수가 존재하므로 resolve가 되고 모듈이 가져와진다.

모노레포에서 Storybook 통합으로 UI배포 시간 단축시키기 (6min -> 2min)

_0422 — Sat, 23 Mar 2024 21:49:49 +0900

이전 게시글에서 UI테스트를 하기 위해 Storybook을 도입했다.

각각의 프로젝트마다 각각의 컴포넌트 테스트를 해볼 수 있어서 좋을것이라 판단했다.

하지만 문제가 있었다. 배포가 너무 많다.

3개의 배포

3개의 레포에 대해서 chromatic을 통해 storybook을 각각 배포하다보니 두가지 문제가 발생했다.

테스트하기 힘들다.

배포 완료된 링크가 3개라 일일히 들어가서 테스트해봐야한다는 단점이 있다.

속도가 느리다.

프로덕션 배포보다 느린 Storybook배포

위 사진처럼 순차적인 형태로 각각의 레포 storybook을 배포하다보니 2분씩, 총 7분가까이 걸리는 문제가 발생했다.

심지어 이 CI는 pull_request마다 돌아야하므로 더 자주, 더 많이 호출되어야한다. 또 우리 레포는 현재 4개의 프로젝트로 구성되어있고, 추후에 더 추가될 수도 있었기 때문에 이런 문제를 반드시 해결해야만 했다.

Storybook 통합하기

프로젝트 생성

apps내부에 storybook을 위한 프로젝트를 vite를 기반으로해서 만들어주었다.

(참고로 우리는 turborepo를 통해 프로젝트를 생성했다.)

Stories이동시키기

그리고 각 레포에 있던 모든 stories파일을 apps/storybook/src/프로젝트 명으로 옮겨주었다.

그러면 이제부터 문제가 발생하기 시작한다.

이제 tsconfig.json이 달라졌기때문에 해당 경로를 찾을 수 없다.

상대경로로 변경시켜주었다.

이러고 Storybook 서버를 실행시켜보면

이건 마치 stories.tsx파일을 못가져오는 것 처럼 보이지만, 실제로 서버가 돌고있는 터미널을 보면

위와 같이 Stories.tsx에서 import해온 절대경로 모듈때문에 해당 모듈을 가져오지 못하여 발생한 문제라는 것을 알 수 있다.

절대 경로 문제 해결하기

이걸 도대체 어떻게 해결해야할까 고민했다. 3개의 절대경로를 각각 다르게 매칭시켜주어야했는데, 이걸 런타임에 해주려니 정말 쉬운일이 아니었다.

그러다가 이 질문글과 답변글을 보게 되었다.

https://github.com/storybookjs/builder-vite/discussions/411

Absolute Imports in Storybook Vite · storybookjs builder-vite · Discussion #411

I was able to setup Vite TS React project, and I was able to enable absolute imports by adding baseUrl/rootDir in tsconfig.json, and using vite-tsconfig-paths vite plugin, in React app. Sadly this ...

github.com

이 글의 주요 내용은 아래 코드를 .storybook/main.ts에 집어넣으면 된다는 것이다.

...
const config: StorybookConfig = {
  ...
  viteFinal: async (config) => {
    return mergeConfig(config, {
      plugins: [tsconfigPath()],
    });
  },
};
export default config;

이 설정을 추가하고 실행하면... 마법과 같이 경로 문제가 해결된다.

해당 파일이 있는 프로젝트의 tsconfig.json의 내용을 통해 경로를 설정해주는 것으로 보인다.

이러면 잘 작동하는 것을 확인할 수 있다!

yml수정하기

이제 yml을 통해 단일배포로 변경해주자.

name: storybook-deployment

on:
  pull_request:
    branches: ['dev']

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: ✅ 코드 체크아웃
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: ⬇️ 의존성 설치
        run: npm install

      - name:   storybook 배포
        uses: chromaui/action@latest
        with:
          workingDir: apps/storybook
          projectToken: {{   }}
          token: ${{ secrets.GITHUB_TOKEN }}

결과

7분가량에서 2분초반대로 약 70%가량의 속도개선이 생겼다!

그러나 이게 어떻게 동작하는지는 아직 정확하게는 알아보지 않았다.

다음 게시글에서 tsconfigPath라이브러리가 어떻게 동작하는지 알아보자.

다음게시글 : https://0422.tistory.com/358

모노레포 Vite 경로의 마법사를 해부해보자 - vite-tsconfig-paths

어떻게? 왜 작동하는가? 자 이전글에서 모노레포에서 tsconfigPath의 마법 같은 경로문제 해결 기능을 보았다. 하지만, 개발자라면 마법과 같은 일은 없으리라는 것을 알고 있을 것이다. 결국 왜? 를

0422.tistory.com

UI테스트를 위해 Storybook을 도입하게 된 이야기

_0422 — Sat, 16 Mar 2024 14:58:38 +0900

이제 프로젝트는 앱 런칭을 앞두고 QA를 진행하고있다.

139개의 QA를 진행했다...

이렇게 QA를 진행하다보니 알게된 것은 생각보다 다양한 기기에서 테스트하다보니 UI가 깨지는게 많다는 점이었다.

그러나 의외로 UI 깨지는 것을 쉽게 해결하기가 쉽지않았다.

아래와 같은 이유들 때문이었다.

특정 사이즈에서만 깨진다.

아래와 같이 화면이 좁아지면 UI가 깨진 다던가... 문제가 있었다.

반응형 사이즈 테스트를 해볼 수가 없다.

서버 API호출을 줄여 운영 비용을 줄이기 위해 네이티브 DB를 사용하기로 결정했었다.

사용자가 쓴 글, 좋아요 누른 글 등을 앱 내부 DB에 저장하게 하고, 로그인시 서버와 1회 통신을 통해 동기화하는 형태로 서비스를 구성했다.

이렇게 앱 내부 DB를 사용하는 곳이 늘어나다보니 이제는 브라우저로 배포된 서비스 URL을 열었을때는 제대로 앱이 기능하지 않았다.

사실 애초에 로그인시 들어오는 토큰을 webview로 전송해주기때문에 배포 URL로 접근하면 로딩화면만 보이게 된다.

이러면 아예 디버그가 안된다는 문제가 있다. 이는 chrome://inspect를 통해 해결했다.

USB디버깅을 통해 안드로이드에서 열린 chrome 화면을 분석할 수 있다.

하지만 이게 정말 모바일 뷰를 미러링하는 기능에 가까워서 화면 리사이징은 되지않는다.

따라서 반응형 UI 테스트를 해볼 방법이 없었다.

디버깅을 위한 대기시간이 매우 매우 길다.

안드로이드 기기에서 로컬 웹서버를 웹뷰로 열고, 이걸 테스트하려면 아래와 같은 과정을 거쳐야한다.

모노레포에 접근해서 npm run dev를 통해 4가지 프로젝트에 대한 로컬 서버를 띄운다.
reactNative 프로젝트에 접근해서 WebView uri를 열린 로컬 서버 주소로 변경한다.
usb를 안드로이드 기기에 연결한다.
npm run start를 통해 reactNative를 실행시킨다.

위의 일련의 과정을 수행하는데에 매우 많은 시간이 소모되었다.

특히 4번은 첫 빌드하는데 10분가량의 시간이 걸린다. 위 과정을 매 디버그마다 겪으며 우리 팀 프론트엔드 개발자는 피로감을 느끼게 되었다.

StoryBook

그래서 어떻게 위의 과정을 거치지 않고 컴포넌트를 시각화하고 테스트해볼까 고민하다가 이쪽으로 가장 유명하다는 ~~홍박사님을~~ storybook의 도입을 고려하게 되었다.

이전까지는 항상 " 뭐 이렇게 까지 해야해? " 라는 생각이 있었는데, 이렇게 직접 UI문제를 마주하고, 일관된 사용자 경험을 제공할 수 없겠다는 문제가 예상되자 스토리북이 절실해졌다.

시작하기

프로젝트 루트 경로에 가서 아래 명령어를 실행시키면 알아서 기본 세팅을 다해준다.

npx sb init

추가 세팅하기

storybook을 도입하자 생긴 가장 큰 문제점이 우리 프로젝트는 디자인시스템이 따로 없고, 아토믹 디자인도 사용하지 않았다. 그래서 각 컴포넌트에서 외부 라이브러리의 훅을 사용하는 경우가 빈번했고, 이에 따라 추가 설정이 필요해졌다.

Context Provider 세팅하기

Context Provider로 감싸진 상태에서 렌더링 되는 경우에 문제가 발생했다.

대표적인 예시로 우리 프로젝트는 react프로젝트라 react-router-dom을 사용했다.

이 라이브러리는 Provider를 통해 구현되었기때문에 useNavigate, useLocation등 이 라이브러리에서 제공되는 훅들을 사용하려면 RouterProvider로 감싸주어야한다.

이는 decorators라는 옵션을 통해 설정할 수 있다.

예를들어 ToastProvider를 사용하고 싶은 경우 SomeComponent.storeis.ts에 아래와 같이 작성하면된다.

const meta = {
  ...
  decorators: [ 
    (Story) => (
      <ToastProvider>
        <Story />
      </ToastProvider>
    ),
  ],
  ...
  } satisfies Meta<typeof Person>;
  
export default meta;

그런데 react-router-dom 의 Provider는 라우팅 설정이 된 객체를 router value로 주어야한다.

이걸 매번 설정하기 귀찮고, 컴포넌트 하나를 테스트하자고 이걸 다 설정할 필요도 없다.

내가 필요한건 그냥 문제없이 라이브러리 내부의 훅이 수행되는 것이다.

storybook-addon-remix-react-router

내부 훅이 잘 작동하게 해주는 addon이 있다. storybook-addon-remix-react-router이다.

이걸 사용하면 복잡하게 설정해줄 필요없이 해당 라이브러리의 withRouter만 적어주면된다.

import { withRouter } from 'storybook-addon-remix-react-router';

const meta = {
  ...
  decorators: [withRouter],
  ...
}

배포하기

우리는 turborepo를 활용하여 4개의 react 프로젝트를 구성했다.

물론 내부 package를 통해 공통 컴포넌트를 구성하긴했지만, 스토리북을 도입한 이유는 네이티브 기기없이 UI테스팅을 하기 위함이었으므로 각 프로젝트마다 storybook을 구성해주었다.

이제는 이 storybook을 배포해서 디자이너/기획자분들도 어렵지 않게 컴포넌트를 직접 보고, UI 엣지 케이스를 테스팅할 수 있게 있게 만들고 싶었다.

배포 자체는 아래 url을 참고하면 된다.

https://storybook.js.org/tutorials/intro-to-storybook/react/ko/deploy/

CI구성에서 생긴 문제점 (secrets 변수를 가져오지 못하는 문제점)

pull request시에 storybook을 빌드해서 배포하고, chromui를 통해 이전 빌드와 시각적으로 달라진 부분을 확인하는 형태로 세팅을 하려고 했다.

하지만 이게 죽었다 깨어나도 secrets의 변수를 가져오지 못하는것이었다.

그러다가 엄청난걸 찾았다.

https://github.com/pypa/gh-action-pypi-publish/discussions/49

upstream 레포지토리에 pull_request를 fork된 레포지토리에서 쓴 경우 github actions은 untrusted mode로 돌아가서 secrets를 못 가져온다는 것이다.

나의 4시간은 날아갔다.

push이벤트로 변경했고, merge시에 비교할 수 있도록 변경했다.

완료된 예시 이미지

이제 네이티브 기기 없이도 시각적 테스트를 할 수 있고, 더불어 dev에 머지될때마다 자동으로 배포되어 팀과 함께 UI를 확인할 수있다!

노르웨이의 숲

_0422 — Sat, 9 Mar 2024 17:30:41 +0900

무라카미 하루키의 소설을 처음 읽어보았다.

하루키의 문장들

처음 접한 하루키의 책은 달리기를 말할 때 내가 하고 싶은 이야기였다.

이 책은 에세이였어서 하루키의 문체를 제대로 경험하지 못했다는 걸 이번 책을 읽으면서 알게 됐다.

하루키의 문체는 정말... 뭐랄까... 모네의 그림같은 느낌이다.

푸르빌 절벽 위 산책은 2년째 내 노트북 배경화면이다.

나는 모네의 그림을 좋아한다. 분명 현실을 담았음에도 그 순간의 기억, 기분, 냄새까지 담겨 있는, 한순간의 추억을 담아내기때문이다.

하루키의 문장에서도 비슷한 느낌을 받을 수 있었다.

하늘은 더할 나위 없이 새파랗고 가늘게 흩뿌려진 구름은 마치 시험 삼아 페인트를 슬쩍 칠한 것 처럼 하늘 천장에 희뿌옇게 달라붙었다.

때로 머리에 깃털 장식 같은 것을 단 빨간 새가 눈앞을 가로질렀다. 푸른 하늘을 배경으로 날아가는 그 모습이 무척 선명했다. 주변 초원에는 하얗고 파랗고 노란 꽃들이 흐드러지게 피었고 여기저기서 벌의 날갯짓 소리가 들렸다. 나는 그런 주위 풍경을 바라보며 아무 생각 없이 오로지 한 걸음 한 걸음 앞으로 나아갔다.

아래 문장들에서는 뭔가 수련같은 느낌을 받았다.

봄의 어둠 속 벚꽃은 마치 피부를 찢고 튀어나온 짓무른 살처럼 보였다. 정원은 그렇게 많은 살들의 달콤하고 무거운 부패로 가득했다.
...
나는 방으로 들어와 창의 커튼을 닫았지만 방 안에도 봄의 향기가 가득했다. 봄의 향기는 모든 지표면에 가득 차있었다. 그러나 지금 그것은 나에게 부패를 연상시킬 따름이었다.

백사장에는 폭죽을 터뜨린 뒤 남은 종잇조각들이 흩어졌고 파도는 미친듯 굉음을 울리며 모래 끝자락에서 부서졌다. 비쩍 마른 개가 꼬리를 흔들며 다가와 뭐 먹을거 없나 하고 내가 피운 조그만 모닥불 주위를 어슬렁거리다가 아무것도 없다는 걸 알고는 체념한듯 발길을 돌렸다.

상실에 관하여

어떤 진리로도 사랑하는 것을 잃은 슬픔을 치유할 수는 없다.
어떤 진리도,
어떤 성실함도,
어떤 강인함도,
어떤 상냥함도,

그 슬픔을 치유할 수 없다.
우리는 그 슬픔을 다 슬퍼한 다음 거기에서 뭔가를 배우는 것뿐이고,
그렇게 배운 무엇도 또다시 다가올 예기치 못한 슬픔에는 아무런 소용이 없다.

상실을 통해 뭔가를 배웠다고 생각한 적이 있다. 그리고 다음번 상실에는 그렇게 힘들지 않을 것이라, 함부로 단정지었었다. 그치만 다시금 다른 상실이 찾아온다면 이전의 배운 것들은 아무런 소용이 없을 것이란 걸 이 소설을 통해 배웠다.

상실은 삶 전반에 걸쳐있다.

언젠가 상실을 만나게 된다면 우리는 불합리하지만 이것을 애도하고, 이후에 다음 만날 상실과는 아무런 관계가 없는 것들을 배워갈 뿐이다.

+) 별로였던점

책에 스토리와 별개로 외설적인 장면이 매우 몹시 많다.

반드시 필요한 장면이면 괜찮은데 뜬금없이 그런 장면이 많아서 좀 그렇다.

별개로 하루키의 문체와 문장의 흡입력은 엄청나서 하루키의 다른 작품을 읽고 싶으면서도, 이 이유 때문에 다음 책을 고르기가 꺼려진다.

React-ReactNative Webview통신을 Event-Driven에서 Request-Response형태로 확장하기

_0422 — Wed, 28 Feb 2024 13:40:55 +0900

이전 게시글들에서 React Webview와 ReactNative의 통신을 시켜보았고, 추가적인 데이터도 주입시켜보았다.

이때의 통신은

ReactNative->React 통신의 경우 onLoad시 React Webview에서 필요한 데이터를 한번에 주입시켜주는 형태 하나였고

React->ReactNative 통신이 대다수여서 불편함이 있지 않았었다.

하지만 프로젝트가 커지고, 서버 API호출을 줄이고자 내활동을 저장하는 부분에 대해 네이티브 기기의 DB를 사용하는 부분을 적용시켰고, 이에 따라 Webview가 열린 후에 데이터를 요청해야하는 부분이 점점 커져갔다.

기존의 방식

처음에는 native DB에 있는 하나의 데이터만이 필요하여 ReactNative의 WebView컴포넌트가 열린 후, onLoad함수로 모든 데이터를 한번에 집어넣는 형태였다.

이전 게시글을 참고하면 좋다.

문제상황

예를 들어, 내가 신고한 게시글의 경우에 문제가 있었다.

신고한 게시글을 또 신고하게 해서는 안됐다. 해당 부분을 네이티브 DB에 저장해 뒀다가 신고 유무를 확인해주어야했다.

이러한 기능을 구현하려면 아래와 같은 흐름이 구성되어야한다.

신고를 누름
네이티브 DB에서 해당 글 신고했는지 확인
신고했다면 신고하지 못하게 처리 / 신고하지 않았다면 신고
신고했다면, 네이티브 DB에 해당 데이터 추가

그런데 문제는 내가 이전에 설계했던 CustomWebView에서는 신고 DB데이터를 딱한번, 웹뷰를 열때 받아오게 만들었다는 것이다.

이러면, 새롭게 신고를 한 경우를 확인할 수가 없다.(연속적으로 동일한 게시글에 신고를 하는 경우)

이런 부분이 매우 많아지기 시작했다. (내가 작성한 글/내가 좋아요누른 글/댓글을 작성한 글, 알림 피드 등등...)

해결방안 두가지

이에 두가지 방법을 생각했다.

onLoad로 받아온 DB데이터를 전역상태로 관리한다.
WebView-Native통신을 WebView컴포넌트가 열린 후에도 가능하게 만든다.

처음에는 전역상태로 관리해볼까? 했으나, 상태가 점점 많아지고, 관리하기 힘들어지는 부분이 있어서 후자를 택했다.

기존 통신의 문제점

기존 통신의 문제점은 바로 WebView와 Native가 Event Driven이라는 점이었다.

결국은 EventListener를 통해 동작하기에 Request-Response형태로 확장시켜 주어야했다.

설계하기

요청하기

WebView에서 Request하기 위한 방법을 만들었다.

하나의 요청에 하나의 eventListener를 등록하는 형태로 만들었다.

그러나, 요청에 대한 응답이 온 후에도 이게 남아있으면 callback함수가 여러번 수행되게 되므로, 응답을 받게되면 eventListener를 제거해주었다.

export default function webViewRequest<T>(callback: () => void) {
  const promise = new Promise<T>((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error('Timeout')), 3000); //3초가 지나면 reject된다.

    const handler = (event: MessageEvent) => {
      clearTimeout(timer);
      const data = JSON.parse(event.data);
      resolve(data);
      document.removeEventListener('message', handler as EventListener);
      window.removeEventListener('message', handler);
    };

    document.addEventListener('message', handler as EventListener);
    window.addEventListener('message', handler);
    callback();
  });

  return promise;
}

응답하기

RN에서는 onMessage 함수를 통해 React로 부터 받은 메시지를 확인할 수 있다.

하지만 이 모든 로직을 여기서 해결하기엔 너무나도 많은 통신이 생길 것 같아 로직을 분리해주어야했다.

현재 RN이 백엔드 처럼 작동하기에 express코드와 유사하게 코드를 작성해보았다.

이러면 onMessage에서는 router로 넘겨주기만 하면된다.

  const onMessage = async (event: WebViewMessageEvent) => {
    const {nativeEvent} = event;
    const customWebViewEvent: CustomWebViewEventType = JSON.parse(
      nativeEvent.data,
    ); //타입에 대해서는 아래에서 더 설명하겠다.
    if (webViewRef.current) {
      router(
        customWebViewEvent,
        webViewRef.current,
        navigation,
        deviceToken,
        dispatch,
      );
    }
  };

동시에 다수의 요청을 하는 경우

다수의 요청이 있는경우가 문제였다.

위와 같이 연속적으로 3개의 다른 요청을 하게되면, native의 postMessage가 한번만 수행되도 모든 이벤트 리스너가 수행되고, 해당 이벤트 리스너가 제거된다.

이러한 문제를 막기위해서 통신에 type이라는 구분자를 만들어주었다.

React에서 A이벤트를 보낼때 type을 담아서 보내고, RN에서 응답시에 동일한 type을 보내주는 것이다.

그럼 이제 type을 설계하면된다.

Request-Response type설계하기

RN이 응답을 해주기때문에 RN에서 먼저 타입을 설계해주었다.

요청시에 data body가 있는지에 따라 WebViewCommonEventType, WebViewDBEventType으로 나누어주었다.

export interface WebViewCommonEventType {
  type: WebViewEventTypeCategory | WebViewDBGetEvent;
}

export interface WebViewDBEventType {
  type:
    | WebViewDBSaveEvent
    | WebViewDBDeleteEvent
    | WebViewDBModifyEvent
  data: {[key: string]: unknown};
}

세부 타입을 아래와 같다.

type WebViewEventTypeCategory =
  | 'BACK'
  | 'LOGOUT';

type WebViewDBGetEvent ='GET_SOME_DATA';

export type WebViewDBSaveEvent ='SAVE_DATA'


type WebViewDBDeleteEvent = 'DELETE_DATA'

type WebViewDBModifyEvent = 'MODIFY_DATA';

RN에서 타입기반으로 작동하게 만들기

router->controller->service를 통해 메시지가 전달되고, 반대로 응답이 오는 구조다.

postMessage를 단순화하기

문제는 postMessage가 WebView.current에 붙어있는 함수라는 것이다.

이걸 분리해줄 필요가 있었다.

일단 WebView를 받는 postMessage함수를 만들고, 이후에 이 함수에 WebView객체를 바인딩시켜줄 것이다.

import WebView from 'react-native-webview';
import {CustomWebViewEventType} from './type';

export default function postMessage(
  webView: WebView<{}>,
  type: CustomWebViewEventType['type'],
  data?: unknown,
) {
  webView.postMessage(
    JSON.stringify({
      type,
      data,
    }),
  );
}

이 함수를 bind를 통해 router에서 인자로 받는 WebView컴포넌트를 고정시켜주었다.

export default function router(
  ...
  WebView: WebView<{}>,
  ...
) {
  const send = postMessage.bind(null, WebView);
  }

이걸 Controller로 전달해주자.

Controller 설계

Controller에서 DB만 조회하는 것이아니라 native의 특정 함수를 수행시키는 경우도 있어 commonController와 DBPostController로 만들어주었다.

commonController는 다양한 인자를 받아야 하기에 switch를 사용하는 함수형태로, DBPostController는 객체로 만들어주었다.

export default function router(
  customWebViewEvent: CustomWebViewEventType,
  WebView: WebView<{}>,
  navigation: NativeStackNavigationProp<StackNavigationType>,
  deviceToken: string,
  dispatch: any,
) {
  const send = postMessage.bind(null, WebView);
  const IS_DB_POST_EVENT = 'data' in customWebViewEvent;

  if (IS_DB_POST_EVENT) {
    const {type, data} = customWebViewEvent;
    return DBPostController[type](data, send);
  }

  return commonController(
    customWebViewEvent,
    send,
    navigation,
    deviceToken,
    dispatch,
  );
}

DBPostController의 타입설계

아래와 같이 위에서 설계한 CustomWebVIewEventType을 key로 갖고, value로 data와 send를 인자로 받는 함수를 갖는 객체형태로 Controller를 만들어주었다.

send는 위에서 바인딩한 send다.

export type Controller<T extends string> = Record<
  T,
  (
    data: unknown,
    send: (type: CustomWebViewEventType['type'], data?: unknown) => void, //postMessage를 바인딩한 send
  ) => Promise<void>
>;

이제 아래와 같이 작성해 줄 수 있다. (타입을 지정했기에 자동완성이 되어 편하다.)

const DBPostController: Controller<WebViewDBEventType['type']> = {
  SAVE_DATA: async (data, send) => {
    await InsertService.data1(data);
    send('SAVE_DATA');
  },

  SAVE_DATA2: async (data, send) => {
    await InsertService.data2(data);
    send('SAVE_DATA2');
  },
}

React에서 요청시 type적용하기

RN과 타입을 맞춰주기 위해 객체를 하나 만들어주었다.

export default {
  TOKEN: 'TOKEN',
  BACK: 'BACK',
  LOGOUT: 'LOGOUT',
  IDENTITY_VERIFY: 'IDENTITY_VERIFY',
  SAVE_DATA: 'SAVE_DATA',
  DELETE_DATA: 'DELETE_DATA',
  MODIFY_DATA: 'MODIFY_DATA',
  NOTIFICATION: 'NOTIFICATION',
};

기존의 WebViewRequest에서 type이 같을때만 eventListener를 제거하도록 처리해주자.

import { WEBVIEW_EVENTS } from '@repo/constants';

interface WebViewResponse<T> {
  type: keyof typeof WEBVIEW_EVENTS;
  data: T;
}

export default function webViewRequest<T>(callback: () => void, type: keyof typeof WEBVIEW_EVENTS) {
  const promise = new Promise<T>((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error('Timeout')), 3000);

    const handler = (event: MessageEvent) => {
      clearTimeout(timer);
      const { data, type: responseType }: WebViewResponse<T> = JSON.parse(event.data);
      if (responseType === type) { //responseType과 기존 요청의 type이 같아야만 제대로 동작
        resolve(data);
        document.removeEventListener('message', handler as EventListener);
        window.removeEventListener('message', handler);
      }
    };

    document.addEventListener('message', handler as EventListener);
    window.addEventListener('message', handler);
    callback();
  });

  return promise;
}

이렇게 하면 이제 webViewRequest가 아래와 같이 동작하게 된다.

이제 RN에 특정 데이터를 받고싶다면 이렇게 보내면된다.

const data = await webViewRequest(() => window.ReactNativeWebView.postMessage(JSON.stringify({ type:"GET_DATA" })), "GET_DATA");

그리고, RN에 특정 데이터를 추가하고싶다면 이렇게 사용하면 된다.

 webViewRequest(() => window.ReactNativeWebView.postMessage(JSON.stringify({ type:"INSERT_DATA",data:"some data..." })), "INSERT_DATA");

그치만 이렇게 사용하기에는 너무나도 길고 복잡하다.

또한, RN에서 응답데이터를 주는 경우 어떤 데이터인지 타입으로 확인하기도 어렵다.

따라서 이 함수를 래핑해주자. 동시에 제네릭을 통해 반환타입을 지정할 수 있게 만들었다. (axios처럼)

const fireEvent = <T>(type: string) =>
  webViewRequest<T>(() => window.ReactNativeWebView.postMessage(JSON.stringify({ type })), type as keyof typeof WEBVIEW_EVENTS);
const fireEventWithData = <T>(type: string, data: unknown) =>
  webViewRequest<T>(() => window.ReactNativeWebView.postMessage(JSON.stringify({ type, data })), type as keyof typeof WEBVIEW_EVENTS);

음 하지만, 여전히 복잡하다.

객체를 통해 특정 WEBVIEW_EVENTS에 대한 함수를 미리 정의해두자.

const nativeEvent = {
  TOKEN: () => fireEvent<{ accessToken: string; refreshToken: string }>(WEBVIEW_EVENTS.TOKEN),
  GET_DATA: <T>() => fireEvent<T>(WEBVIEW_EVENTS.GET_DATA),
  BACK: () => fireEvent(WEBVIEW_EVENTS.BACK),
  LOGOUT: () => fireEvent(WEBVIEW_EVENTS.LOGOUT),
  SAVE_DATA: (data: unknown) => fireEventWithData(WEBVIEW_EVENTS.SAVE_DATA, data),
  DELETE_DATA: (data: unknown) => fireEventWithData(WEBVIEW_EVENTS.DELETE_DATA, data),
  MODIFY_DATA: (data: unknown) => fireEventWithData(WEBVIEW_EVENTS.MODIFY_DATA, data),
};

이렇게 하면 native.특정이벤트()형태로 바로 데이터를 얻어올 수 있다!

이제 아래와 같이 깔끔하게 사용할 수 있다

export default function useSomeQuery() {
  const getSomeData = async () => {
    const result = await nativeEvent.GET_DATA<UserActionResponse[]>();
    const likes = await nativeEvent.GET_LIKE_DATA<UserActionResponse[]>();

    const feed: Feed[] = result.map((article) => ({ ...article, liked: likes.some((like) => like.id === article.id) }));
    return feed;
  };

  return useQuery({ queryKey: [REACT_QUERY_KEYS.SOME_DATA], queryFn: getSomeData, staleTime: 0 });
}

다하고나니 새삼 http요청/axios/express가 얼마나 잘 만든 라이브러리인지 알 수 있었다.

타입을 맞추고, 확장 가능하게 하는게 정말 보통일이 아니다...

Promise 지연평가로 비동기 문제 해결하기

_0422 — Wed, 28 Feb 2024 11:18:16 +0900

이전 게시글에서 React Webview와 ReactNative의 통신을 시켜보았다.

이때의 방식은 WebView가 onLoad되었을때, React Webview에서 필요한 토큰을 주입하게 하는 형태였다.

하지만, 프로젝트가 커지고, 다양한 API요청이 많아짐에 따라 우리팀은 자연스럽게 비용문제가 발생할 수 있을거라는 걱정을 하게되었고, 이에 서버 API호출을 줄이고자 데이터를 받아오는 부분에서 네이티브 기기의 DB를 사용하기로 하였다.

문제상황

기기 DB에 저장된 데이터를 받아와서, 웹뷰에서 보여줘야했다.

이때의 DB테이블은 우리팀원이 이미 만들어 둔 상태였기에, 나는 이것을 조회해서 웹뷰에 넣어만 주면 됐다.

그런데 DB조회는 비동기적으로 일어난다. Promise를 resolve시켜야 실제 데이터를 얻어올 수 있다.

그러나, 컴포넌트 함수 실행은 동기적으로 일어난다.

어떻게 해야 이 데이터를 효과적으로 웹뷰에 전달 할 수 있을까? 를 고민했다.

CustomWebView

우리 서비스는 여러개의 웹뷰 화면을 보여주기때문에 CustomWebView를 구성해주었었다.

따라서 여기에 data를 주입시킬 수 있어야했다.

export default function CustomWebView({uri}: {uri: string}) {
  const webViewRef = useRef<WebView>(null);
  const onLoad = async () => {
    const accessToken = await storageGetValue('accessToken'));
    const refreshToken = await storageGetValue('refreshToken');
    if (webViewRef.current) {
      webViewRef.current.postMessage(
        JSON.stringify({accessToken, refreshToken}),
      );
    }
  };
  
  ...
  return <WebView
        uri={{uri}}
        ref={webViewRef as any}
        onLoad={onLoad}
      />
  }

현상 파악하기

원하는 것을 정리해보자.

DB데이터를 비동기적으로 조회한다.
웹뷰 컴포넌트가 동기적으로 실행된다.
onLoad될때 데이터를 주입시킨다. 이때, 데이터는 Promise면 안된다.

그러면 WebView로 전달할때가 아니라 onLoad시에 Promise를 resolve시켜주면된다!

CustomWebView props추가하기

일단 주입받을 데이터를 props로 받아주었다.

이때의 데이터는 그냥 객체가 아니라 Promise형태의 객체를 받게하여, onLoad시에 Promise를 평가하도록 만들었다.

interface CustomWebViewProps {
  uri: string;
  additionalData?: AdditionalData;
}

export default function CustomWebView({
  uri,
  additionalData,
}: CustomWebViewProps) {
...
}

따라서 additionalData의 데이터 타입을 이렇게 설계해주었다.

interface AdditionalData {
  [key: string]: Promise<unknown>;
}

그리고 onLoad에서 해당 Promise를 resolve시킨 후에, webViewRef.current.postMessage로 WebView에 주입시켜주었다.

  const onLoad = async () => {
    setLoading(false);
    const accessToken = (await storageGetValue('accessToken')) || '';
    const refreshToken = await storageGetValue('refreshToken');

    if (additionalData)
      await Promise.all(
        Object.entries(additionalData).map( //객체 value를 resolve시키고, value를 resolve된 값으로 변경한다.
          async ([key, value]: [any, Promise<any>]) => {
            additionalData[key] = await value;
          },
        ),
      );

    if (webViewRef.current) {
      webViewRef.current.postMessage(
        JSON.stringify({accessToken, refreshToken, ...additionalData}),
      );
    }
  };

사용하기

이제 화면단에서 웹뷰를 열때 아래와 같이 다양한 데이터를 객체로 묶어서 주입해줄 수 있다.

const Page = () => {
  const data = {
    schools: getSchools(), //Promise를 반환하는 비동기 DB조회 함수 호출
  };

  return (
    <CustomWebView
      uri="http://uri..."
      additionalData={data}
    />
  );
};

React에서 받기

아래와 같이 Provider를 통해 데이터를 받도록 처리했다.

import { ReactNode, useEffect, useState } from 'react';
import { School, SchoolInfo } from '@/hooks/useSchoolData';

export default function SchoolProvider({ children }: { children: ReactNode }) {
  const [schoolData, setSchoolData] = useState<SchoolInfo[]>([]);

  const schoolDataHandler = (event: MessageEvent) => {
    const { schools } = JSON.parse(event.data);
    setSchoolData(schools);
  };

  useEffect(() => {
    document.addEventListener('message', schoolDataHandler as EventListener);
    window.addEventListener('message', schoolDataHandler);
  }, []);

  return <School.Provider value={schoolData}>{children}</School.Provider>;
}

무기여 잘 있거라

_0422 — Tue, 13 Feb 2024 16:03:11 +0900

이번 년도에는 정보성 글, 자기계발서들에서 의도적으로 벗어나 소설을 읽어 보려 하고 있다.

그러던 중 서점에서 민음사코너를 보게 됐다. 쭉 훑다가 눈에 들어온 것이 무기여 잘있거라였다.

어니스트 헤밍웨이가 그렇게 대가로 유명하다는데 나는 그의 글을 한 번도 읽어본 적이 없었다는걸 알게 됐다.

과연 이 사람은 어떤 내용의 글을 어떻게 적었을지 궁금하여 선택하게 된 책이다.

인간은 죽는다. 그것이 무엇인지 몰랐어. 그것에 대해 배울 시간이 없었던 거야. 경기장에 던져 놓은 뒤 몇 가지 규칙을 알려 주고는 베이스를 벗어나는 순간 공을 던져 잡아 버리거든. 아이모처럼 아무 까닭 없이 죽이거나, 또는 리날디처럼 매독에 걸리게 하지. 하지만 결국에는 모두 죽이고 말지. 그것만은 분명해. 결국 살아남는다 해도 종국에는 죽임을 당하는 거야.

내가 지금까지 읽었던 고전 소설들은 대부분 어떤 메시지를 담으려고 했다.

인생은 자신만의 양탄자 무늬를 짜는 것 이라던가... 이상적 자아로 나아가기 위한 과정을 담는다던가...

그런데 무기여 잘있거라는 정말 사실만을 담았다.

사람은 죽는다. 어찌됐던, 다양한 이유로.

더 이상의 수식도, 미사여구도, 교훈도 없이 이게 끝이다.

둘이 함께 오래오래 행복하게 살았답니다는 동화속의 이야기다. 인간으로 태어난 이상, 인간이 맞을 수 있는 결말은 단 하나다.

이러한 주제를 작가 특유의 하드보일드 문체로 풀어내니 여운이 정말 엄청나다.

지금까지 주인공, 캐릭터들의 감정을 묘사한 작품들은 캐릭터의 감정에 집중하게 되어 오히려 제 3자의 입장에서 주인공의 감정에 공감했었다면, 이 작품은 사실만을 전달하여 오히려 내가 그 현장에 있는 것과 같은 경험을 할 수 있었다.

캐서린은 계속해서 출혈을 하는 모양이었다. 의사는 그것을 멎게 하지 못했다. 나는 방 안으로 들어가서 캐서린이 죽을 때까지 같이 있었다. 캐서린은 줄곧 의식이 없었고, 죽는 데 시간이 오래 걸리지도 않았다.

나는 지금까지 소중한 사람을 잃어본 경험이 그렇게 많지 않다. 그래서일까 캐서린의 죽음이 마치 지인의 죽음처럼 느껴졌다. 보통 책을 덮으면 생각이 어느정도 정리되어 하나의 주제로 남기 마련이었는데, 이 책을 덮고나서는 정말, 정말 많은 생각을 했지만 온전히 하나로 정리해내지 못했다.

주인공 헨리와 똑같은 입장에서 파시니가, 아이모가, 캐서린이 죽었다는 사실을 겨우, 받아들이는게 전부였다.

전쟁의(Arms) 전우들, 캐서린의 품(Arms)에 작별을 고하며, 잘 있으라 말해주는게 전부였다.

무한 스크롤 (3) - 피드 데이터 최신화하기

_0422 — Sun, 28 Jan 2024 19:48:23 +0900

이전 글에서 useInfinityQuery를 사용하여 무한 스크롤 피드를 구현해보았다.

하지만 두가지 문제가 존재했다.

새롭게 글을 작성/수정/삭제 하는경우 피드데이터는 어떻게 최신화 되어야 하는가?
세부 글보기에서 좋아요/댓글을 추가/삭제하는 경우 피드데이터는 어떻게 최신화 되어야 하는가?

이번에는 이 두 가지 문제를 해결해보자.

이 문제 중 두번째 문제가 당근마켓 그룹플랫폼 인턴직무의 사전 질문이었다...!

이걸 직접 해결해 볼 수 있는 기회가 이렇게나 빨리 오게 될 줄이야....

https://0422.tistory.com/331

당근마켓 윈터테크 인턴십 그룹플랫폼 직무면접 불합격 회고

그룹 플랫폼 팀에 지원 이번 윈터테크 인턴십은 프론트엔드가 코어, 광고, 그룹플랫폼 3가지 형태로 구성되어있었다. 나는 이 중 광고와 그룹플랫폼에 지원했다. 그 중, 그룹플랫폼에 조금 더 신

0422.tistory.com

글을 새롭게 작성하거나 수정/삭제하는 경우

우선, 글을 새롭게 작성하거나/수정/삭제하는 경우다.

사용자입장에서 글을 쓰고,수정하고, 삭제를 한다면 그 사용자의 목적은 내 글이 어떻게 되었는가, 잘 업데이트 되었는가이다.

따라서 피드 데이터를 처음부터 받아오고, 최신 피드데이터를보아야 하므로 최상단으로 이동시켜야 한다고 생각했다.

그렇다면 queryKey의 데이터를 무시하고 새롭게 피드데이터를 받아와야 한다.

이는 invalidateQueries 메서드로 가능하다.

invalidateQueries

React-query에서는 queryClient의 invalidateQueries 메서드를 통해 캐시데이터를 무효화한다.

이러면 해당 쿼리가 마운트된 상황일때 queryFn을 통해 데이터를 다시 받아오게된다.

  queryClient.invalidateQueries({ queryKey: [무효화할 query Key] });

한줄 요약하면 QueryKey에 저장된 데이터를 다시 받아오게 만드는 것이다.

예시로 글을 삭제하는 경우, mutate가 성공적으로 수행되면 무한 스크롤 데이터의 캐시 데이터를 무효화시켜주었다.

import { useToast } from '@repo/toast';
import { useMutation, useQueryClient } from '@tanstack/react-query';
import { useNavigate } from 'react-router-dom';
import REACT_QUERY_KEYS from '@/constants/REACT_QUERY_KEYS';
import useAuthAxios from '@/hooks/useAuthAxios';

export default function useDeleteArticleMutation() {
  const openToast = useToast();
  const queryClient = useQueryClient();
  const navigate = useNavigate();
  const authAxios = useAuthAxios();

  const deleteThread = (id: number) => {
    return authAxios.delete(`/apiURL/${id}`);
  };

  return useMutation({
    mutationFn: deleteThread,
    onSuccess: () => {
      openToast({ type: 'information', content: '삭제 완료' });
      navigate(-1);
      queryClient.invalidateQueries({ queryKey: [REACT_QUERY_KEYS.ENTIRE_THREADS] });
    },
  });
}

이러면 글 작성/수정/삭제시, 진행중이던 무한스크롤에서 최상단으로 이동하게 되며 최신 데이터를 받아올 수 있게 된다.

좋아요/댓글/답글을 추가/삭제 하는 경우

그렇다면, 단일 글에서 좋아요, 댓글, 답글을 다는 이벤트가 일어났을때는 어떻게 해야할까?

이 때는 글작성/수정/삭제와 달리 사용자의 의도가 피드 탐색에 더욱 초점이 맞춰진 상태라고 생각했다.

따라서 캐시 데이터를 무효화하면 탐색하던 페이지로 돌아오는게 아닌, 최상단으로 올라가게 될 것이므로 사용자가 불편함을 느끼게 될 것이다.

따라서 다른 방법이 필요하다.

setQueryData

React Query에서는 queryKey내부 데이터를 변경할 수 있는 메서드도 제공한다...!

아래와 같이 이전의 쿼리데이터도 가져올 수 있고, 새롭게 쿼리 데이터를 지정할 수 도 있다.

queryClient.setQueryData([querKey], (이전 쿼리 데이터) => (새롭게 지정할 쿼리 데이터));

자 그럼 새로운 데이터만 제대로 가져올 수 있다면 피드데이터를 수정해줄 수 있다.

단일 글 데이터를 활용하기

우리 프로젝트는 피드에서 단일 글을 눌러 해당 글로 이동할 때, 단일 글 요소의 id를 통해 서버에서 데이터를 받아온다.

그리고, 댓글, 좋아요 등 사용자의 actions이 있을 시 해당 글의 캐시를 무효화 하는 형태로 단일 글의 데이터를 최신상태로 유지했다.

단일글 받아오기(useThreadQuery)

export default function useThreadQuery(threadId: number) {
  const authAxios = useAuthAxios();

  const getThread = async () => {
    const result = await authAxios.get<ArticleRawData>(`/apiURL/${threadId}`);
    return result.data;
  };

  return useQuery({ queryKey: [REACT_QUERY_KEYS.THREAD, threadId], queryFn: getThread });
}

좋아요 클릭시 캐시 무효화 (useLikeArticleMutation)

export default function useLikeArticleMutation() {
  const queryClient = useQueryClient();
  const authAxios = useAuthAxios();

  const likeThread = async (threadId: number) => {
    await authAxios.post(`/likeApiURL/?id=${threadId}`);
    return threadId;
  };

  return useMutation({
    mutationFn: likeThread,
    onSuccess: (threadId) => {
    //mustate가 제대로 일어나면 해당 id 글의 캐시를 무효화한다.
      queryClient.invalidateQueries({ queryKey: [REACT_QUERY_KEYS.THREAD, threadId] });
    },
  });
}

그럼 최신데이터를 받아왔을 때, 피드데이터를 동기화 시켜주면 된다.

어떻게 동기화 할 것인가?

단순하게 모든 페이지를 순회하면서 해당 글 id를 통해 요소를 찾을 수도 있을 것이다.

하지만 그것보다는 요소 클릭시 해당 요소의 무한 스크롤 페이지 index를 기록하고, 해당 페이지 내에서 탐색하는 것이 효과적이라고 판단했다.

export default function Threads() {
  const { data, isFetchingNextPage, fetchNextPage } = useThreadsQuery();
  // 특정 글 클릭시 전역상태 변경하는 함수
  const setPageIndex = usePageIndex((state) => state.setPageIndex);
  ...
  return (
  	...
        {data.pages.map((page, pageIndex) =>
          ... // 클릭시 전역상태 변경
              <FeedArticle data={feedData} onLinkMove={() => setPageIndex(pageIndex)} />
          ...
          )),
        )}
    ...
    );
}

그럼 이제 단일글을 불러올때, 전역 pageIndex를 기반으로 해당 글을 탐색한 후, 최신 값으로 변경시켜주면 된다.

export default function useThreadQuery(threadId: number) {
  const authAxios = useAuthAxios();
  const queryClient = useQueryClient();
  const pageIndex = usePageIndex((state) => state.pageIndex);
  
  //최신화한 피드데이터 얻기
  const changeFeedArticleData = (feedData: InfiniteData<FeedData>, newThreadData: ArticleRawData) => {
    const newPage = [...feedData.pages];
    const articleData = newPage[pageIndex].posts.find((post) => post.id === threadId); //해당 페이지에서 현재 글 찾기
    if (articleData) { // 데이터 갱신
      articleData.liked = newThreadData.liked; //좋아요 여부
      articleData.likeCount = newThreadData.likeCount; //좋아요 수 갱신
      articleData.commentCount = newThreadData.commentCount; //댓글 개수 갱신
      ...
    }
    return newPage;
  };

  const getThread = async () => {
    const result = await authAxios.get<ArticleRawData>(`/apiURL/${threadId}`);

    if (queryClient.getQueryState([REACT_QUERY_KEYS.THREADS]))
      queryClient.setQueryData([REACT_QUERY_KEYS.THREADS], (feedData: InfiniteData<FeedData>) => ({
        pages: changeFeedArticleData(feedData, result.data), //기존 피드데이터에서 새로운 피드데이터로 갱신
        pageParams: feedData.pageParams,
      }));
    return result.data;
  };

  return useQuery({ queryKey: [REACT_QUERY_KEYS.THREAD, threadId], queryFn: getThread });
}

이러면 단일 글 보기에서 좋아요,댓글 입력시 피드에 반영이 된다!

무한스크롤 (2) - 데이터 요청과 캐시 처리 (react-query)

_0422 — Sun, 28 Jan 2024 17:44:17 +0900

이전글에서 무한스크롤에 필요한 두가지 조건을 정리했다.

사용자가 페이지 하단에 도달했을때
콘텐츠가 계속 로드

첫번째 조건은 이전글에서 완료했으니, 2번째 미션을 해결할 차례다.

어떻게 콘텐츠가 계속 로드되게 만들 수 있을까?

데이터를 페이지네이션 형태로 제공하는 방법은 크게 cursor 기반과 offset 기반, 두가지 방법이 존재한다.

하지만 그것은 백엔드 개발자의 일이구요... 라고 하면 큰일나니 간단하게 알아보자.

offset 기반
- 페이지단위로 구분해서 구현이 간단하나 데이터 중복문제(중간에 글이 써지는경우)가 발생한다.
- offset값이 커지면 앞의 데이터를 모두 읽어야해서 DB상 성능문제가 발생할 수 있다.
cursor 기반
- cursor라는 사용자에게 마지막으로 응답해준 마지막 데이터 식별자 값을 기억하여 페이지네이션을 구현한다.
- offset에서 1억 +10번달라고 하면 1억 10개의 데이터를 읽지만, 커서기반에서는 1억번부터(cursor 데이터에 기록) 10개의 데이터만 읽게된다.

성능상의 이점때문에 우리 프로젝트는 cursor기반을 택했다.

useState + useEffect로 간단하게 구현

기존에 데이터 패칭을 하는 형태로 간단하게 구현해보자.

next가 true면 다음 cursor를 set하고 요소가 보일때 리패칭 해줄 것이다.

interface FetchData {
  posts: { id: number; title: string; content: string }[];
  cursor: string;
  next: boolean;
}

받아온 데이터, 커서, refetch유무, next정보를 state로 구성해주자.

각각 다른 state로 구성했다.

export default function FetchingComponent() {
  const [data, setData] = useState<FetchData['posts']>();
  const [cursor, setCursor] = useState('');
  const [refetch, setRefetch] = useState(true);
  const [next, setNext] = useState(true);
  ...
}

그리고 내부적으로 fetch할 함수를 만들어주자.

useCallback으로 cursor정보가 바뀔때만 함수가 재선언되도록 만들어주었다.

  const getFeed = useCallback(async () => {
    const result = await axios.get<FetchData>(`/post${cursor && `?cursor=${cursor}`}`);
    return result.data;
  }, [cursor]);

그리고 useEffect를 통해 refetch가 true고 next가 있을때 데이터를 패칭되도록 했다.

  useEffect(() => {
    if (refetch && next)
      getFeed().then((res: FetchData) => {
        if (data) setData([...data, ...res.posts]); //데이터 이어붙이기 
        else setData(res.posts); //첫 데이터 받아오기
        if (!res.next) setNext(false); //받아온 데이터가 next가 없으면 setNext를 false로
        setCursor(res.cursor); //cursor정보 업데이트
        setRefetch(false); //모든 작업이 끝나면 refetch를 false로 변경
      });
  }, [refetch]);

이제 요소가 화면에 들어오면 refetch를 true로 만들어 주면된다.

이전 게시글에서 만들어둔 useRefFocusEffect를 사용하자

export default function FetchingComponent() {
  ...
  const [refetch, setRefetch] = useState(true);
  const { elementRef } = useRefFocusEffect<HTMLDivElement>(() => setRefetch(true), []);
  ...

  if (data)
    return (
      <div>
        {data.map((article) => (
          <div className="mt-10">
            <div>제목: {article.title}</div>
            <div>내용: {article.content}</div>
          </div>
        ))}
        <div ref={elementRef}>이게 보이면 리패칭</div>
      </div>
    );
}

이러면 잘 작동한다!

문제점

하지만 이 방식에는 문제점이 있다. 단일글에 대해서 라우팅처리를 따로 해주게되면 단일 게시글로 이동할때 컴포넌트가 언마운트되고, 뒤로가기로 무한 스크롤로 돌아오게되면 첫 cursor 요청부터 다시 시작해야한다는 점이다.

사용자 입장에서 매우 답답해지고, api요청수도 증가하게된다.

그렇지 않으려면, 전역상태로 서버데이터를 저장하고, 이를 관리해주어야한다.

전역상태가 있다면, fetch 하지 말것
특정 상황에 데이터를 다시 fetch해올 것
이 데이터를 cursor별로 관리할 수 있어야할 것

하지만, 전역상태로 서버데이터를 저장해주는 라이브러리가 이미 존재한다. 바로 리액트 쿼리다.

이에 나는 리액트 쿼리를 도입하여 피드데이터를 관리하고자 했다.

React-Query

리액트 쿼리는 서버로 부터 받아온 데이터를 전역 상태 형태로 관리할 수 있게 도와주는 라이브러리이다.

Query Key별로 데이터를 저장해둘 수 있다.

즉, 언마운트 될때도 상태정보가 유지가 되므로, api호출을 줄일 수 있게 된다.

자세한 원리는 이미 분석해둔 글이 있어서 가져왔다.

https://www.timegambit.com/blog/digging/react-query/01

[React Query] useQuery 동작원리(1)

Tanstack Query(React Query)의 useQuery의 동작원리를 분석했습니다. 이 포스트에서는 중요한 객체들간의 관계와 QueryObserver의 생성에 대해 다룹니다.

www.timegambit.com

useQuery사용해서 구성하기

useQuery를 간단하게 설명하자면, 아래와 같이 사용한다.

const result=useQuery({queryKey:쿼리키, queryFn:패칭함수});

여기서 queryKey에 패칭해온 데이터를 저장한다.

그럼 cursor 정보마다 queryKey를 구성해주면 된다...!

만 cursor정보는 런타임에 결정되므로 useQuery 훅을 동적으로 호출해야한다는 문제가 생긴다.

하지만 훅을 특정 상황에 동적으로 호출할 수는 없으므로 (React Fiber객체의 훅 연결리스트 순서보장 문제), 쿼리키에는 피드 전체 데이터를 저장하되, cursor별로 페이지를 분리하여 저장하면 될 것이다.

interface FeedPageData{ 
	id: number; 
    title: string; 
    content: string 
};

type Cursor=string;

interface FeedData{
	pages:<Cursor,FeedPageData[]>[],
}

이런식으로 구성하고, useQuery에서 데이터를 패치하는 형태로 구성할 수 있을것이다.

하지만, React-Query에서는 이미 무한스크롤을 위한 Query를 제공한다. 바로 InfinityQuery다.

useInfinityQuery

useInfiityQuery는 지금까지 우리가 고민했던 모든것을 담아놓은 훅이다.

아래와 같은 기능을 제공한다.

queryKey에 데이터 캐싱
데이터 페이지별로 관리
초기 cursor param
다음 데이터를 불러올 fetch함수를 만들기

아래와 같이 설정하여 호출하면 된다.

useInfiniteQuery({
    queryKey: //쿼리키,
    initialPageParam: //초기 param,
    queryFn: ({ pageParam}) => getParamThread(pageParam), //param을 받아서 queryFn에게 넘겨주는 형태
    getNextPageParam: (queryFn으로 받아온 데이터)=>다음 param을 return하도록 구성
  });

return 값은 data, isFetchingNextPage, fetchNextPage등을 제공한다.

data는 page와 pageParams로 구성되며 실제 데이터는 page내부에 배열형태로 들어가있다.

fetchNextPage를 통해 다음 fetch함수를 실행시키고, page를 추가할 수 있다.

나같은 경우 전체 피드를 받아오는 useInfinityQuery를 훅으로 래핑해서 사용했다.

import { useInfiniteQuery } from '@tanstack/react-query';
import REACT_QUERY_KEYS from '@/constants/REACT_QUERY_KEYS';
import useAuthAxios from '@/hooks/useAuthAxios';
import { FeedData } from './type';

export default function useThreadsQuery() {
  const authAxios = useAuthAxios();

  const getParamThread = async (param?: string) => {
    const result = await authAxios.get<FeedData>(`/apiURL${param && `?cursor=${param}`}`);
    return result.data;
  };

  return useInfiniteQuery({
    queryKey: [REACT_QUERY_KEYS.ENTIRE_THREADS],
    initialPageParam: '',
    queryFn: ({ pageParam = '' }) => getParamThread(pageParam),
    getNextPageParam: (lastPage) => (lastPage.next ? lastPage.cursor : undefined),
  });
}

이렇게 받아온 데이터를 아래와 같이 컴포넌트를 구성해 렌더링해주었다.

import { FeedArticle, Loading } from '@repo/components';
import useEntireThreadsQuery from '@/apis/useEntireThreadsQuery';
import useRefFocusEffect from '@/hooks/useRefFocusEffect';
import InfiniteLoading from './InfiniteLoading';

export default function EntireFeed() {
  const { data, isFetchingNextPage, fetchNextPage } = useEntireThreadsQuery();
  const { elementRef } = useRefFocusEffect<HTMLDivElement>(fetchNextPage, [data]);

  if (!data) return <Loading />;
  return (
    <>
      {data.pages.map((page) =>
        page.posts.map((feedData, feedIndex) => (
          <div className="border-b border-[#232636] py-2" key={feedIndex}>
            <FeedArticle data={feedData} />
          </div>
        )),
      )}
      <div className="w-full justify-center flex items-center py-2">
      {// 여기가 보이면 다음 cursor로 요청한다}
        <InfiniteLoading ref={elementRef} isLoading={isFetchingNextPage} />
      </div>
    </>
  );
}

이렇게 하면 잘 작동되는 것을 확인할 수 있다!

새로운 문제 - 피드 데이터 최신화

하지만 이게 끝이 아니다.

두가지 문제가 있다.

첫번째는 새롭게 글을 작성/수정/삭제하는경우이다.

두번째는 세부글에서 좋아요/댓글을 추가/삭제하는 경우이다.

피드에서 세부 게시글을 눌러서 세부 글을 볼때, 댓글이나 좋아요를 남긴후, 피드로 돌아가게되면 피드에는 전혀 반영이 되지않은 것을 볼 수 있다...!

어떻게 하면 이러한 문제들을 해결 할 수있을까?

다음 게시글에서 이 두가지 문제를 해결해 볼 것이다.

무한 스크롤 (1) - 하단 감지하기 (Scroll Event vs Intersection Observer)

_0422 — Sat, 27 Jan 2024 12:58:35 +0900

배경

커뮤니티 서비스를 만들고 있는데, 피드를 만들어야 했다.

이전에 당근마켓 인턴십의 사전 질문이기도 했던 세부 글보기 에서 좋아요/댓글이 추가/삭제된 경우 어떻게 피드에 반영할 것인가?라는 질문에 직접 구현해보며 답할 수 있는 좋은 기회라고 생각해서 구현하게 됐다.

무한스크롤에 필요한 것들을 하나씩 확인해보면서 구현할 것이다.

필요한 것 알아내기

무한 스크롤은 사용자가 페이지 하단에 도달했을때 콘텐츠가 계속 로드되는 사용자 경험 방식이다.

그럼 구현에 필요한 두가지 필수 조건을 알 수 있다.

사용자가 페이지 하단에 도달했을때
콘텐츠가 계속 로드

이 두 가지 미션을 해결하면 무한스크롤이 되는 것이다.

이 게시글에서는 1번 항목에 대해 어떻게 구현할 것인지를 고민해보았다.

사용자가 페이지 하단에 도달했음을 감지하기

Scroll Event (onScroll)

간단하게 생각했을때, scroll Event가 일어났을때마다 최하단에 도달했는지를 확인한다면 해결되는 문제다.

scrollHeight, scrollTop, clientHeight 세가지 속성을 사용해서 페이지 하단에 도달했음을 확인할 수 있다.

scrollHeight, scrollTop, clientHeight

이해하기 쉽게 그림을 그려왔다.

clientHeight은 요소의 보이는 높이값이다.

그리고 scrollTop은 스크롤바의 위치를, scrollHeight는 scrollBar가 없을때(요소를 쫙 폈을때) 요소의 높이값이다.

그럼 이 세가지 요소를 조합해서 맨 아래에 도착했는지 확인할 수 있다.

최대스크롤 가능요소까지 스크롤하게되면 scrollHeight-scrollTop이 clientHeight와 같아지는 것이다.

그럼 이걸 활용하면 이렇게 작성할 수 있다.

const scrollTop=document.documentElement.scrollTop;
const scrollHeight=document.documentElement.scrollHeight;
const clientHeight=document.documentElement.clientHeight;

if(clientHeight===scrollHeight-scrollTop){
    fetch();
}

그런데 사파리 브라우저에서는 오버스크롤이 된다고한다.

https://www.smashingmagazine.com/2018/08/scroll-bouncing-websites/

이러면 clientHeight보다 scrollHeight-scrollTop한 크기가 더 작아진다.

부등호를 넣어주자.

const scrollTop=document.documentElement.scrollTop;
const scrollHeight=document.documentElement.scrollHeight;
const clientHeight=document.documentElement.clientHeight;

if(clientHeight>=scrollHeight-scrollTop){
    fetch();
}

그럼 이걸 window.onScroll에 달아주면된다.

  useEffect(() => {
    window.addEventListener(() => {
      const scrollTop = document.documentElement.scrollTop;
      const scrollHeight = document.documentElement.scrollHeight;
      const clientHeight = document.documentElement.clientHeight;

      if (clientHeight >= scrollHeight - scrollTop) {
        fetch();
      }
    });
  }, []);

문제점

onScroll의 콜백함수는 스크롤이 일어날때마다 호출된다.

알다시피 JS는 싱글스레드 언어이다.

즉, 스크롤 할때마다 콜스택이 계속 쌓이게되는 것이다.

이러면 무의미한 함수호출을 계속하는 것 뿐 아니라 이론적으로는 CallStack이 쌓이면서 다른 함수 호출, 비동기 처리에도 문제를 일으킬 수 있다. (실제 성능 비교 실험 글을 읽어보면 이론에 그치지 않는다는 것을 알 수 있다.)

이런 문제를 해결하기 위해서 쓰로틀링, 디바운싱을 걸 수 있다...만 우리가 원하는건 마지막 부분에 왔을 때만, fetch시키는 것이다.

결국 디바운싱이든, 스로틀링이든 무의미한 호출을 하게되는 것이다.

무의미한 호출을 하지 않는 것이 BEST라고 할 수 있다.

유의미한 호출을 하기위한 방법이 있다.

바로 Intersection Observer API이다.

Intersection Observer API

Intersectin Oberserver API는 특정 요소가 다른 요소의 교차에 관한 API다.

즉, 교차되는 것과 관련한 일이 일어났을때 콜백함수를 호출시킬 수 있는 것이다.

간단한 사용법을 알아보자. (자세한 사용법은 mdn을 참고하면된다)

IntersectionObserver는 다음과 같이 새로운 인스턴스를 만들고, 요소를 관찰할 수 있다.

const observer = new IntersectionObserver(콜백함수, 옵저버옵션);
const element=관찰할요소;
observer.observe(element); // 해당 요소 관찰 시작

옵저버 옵션

여기서 옵저버 옵션으로 다양한 값을 줄 수 있는데

가장 중요한게 root와 threshold다.

const observer = new IntersectionObserver(콜백함수, {
	root: "관찰할 요소의 상위요소",
    threshold: "관찰 요소가 얼마나 보여야하는가?" //1 -> 100%다.
});

이때 root 값이 없으면 브라우저 뷰포트가 된다.

콜백함수

콜백함수는 지정된 형태를 갖는데 두개의 인자를 갖는다.

entries는 해당 옵저버가 관찰하고 있는 대상 전체를 말한다. (여러개의 대상을 관찰하고 있을 수 있으므로)

observer는 옵저버 객체다.

let callback = (entries, observer) => {
  entries.forEach((entry) => {
    // 각 엔트리는 observe하고있는 요소 하나의 교차 변화를 설명한다.
  });
};

이 entry에서 다양한 정보를 얻어올 수 있다.

boundingClientRect: 관찰 대상의 사각형 정보(DOMRectReadOnly)
intersectionRect: 관찰 대상의 교차한 영역 정보(DOMRectReadOnly)
intersectionRatio: 관찰 대상의 교차한 영역 백분율(intersectionRect 영역에서 boundingClientRect 영역까지 비율, Number)
isIntersecting: 관찰 대상의 교차 상태(Boolean)
rootBounds: 지정한 루트 요소의 사각형 정보(DOMRectReadOnly)
target: 관찰 대상 요소(Element)
time: 변경이 발생한 시간 정보(DOMHighResTimeStamp)

이중 isIntersecting을 사용하면 무한스크롤을 구현할 수 있다.

useRefFocusEffect

이걸 활용해서 ref요소가 화면에 들어왔을때(focus) 콜백함수가 수행되는 훅을 만들어주었다.

import { useEffect, useRef } from 'react';

export default function useRefFocusEffect<T extends HTMLElement>(onFocusCallback: () => void, deps?: React.DependencyList) {
  const ref = useRef<T>(null);

  useEffect(() => {
    if (ref.current) {
      const observer = new IntersectionObserver((entries) => entries.forEach((entry) => entry.isIntersecting && onFocusCallback()), {
        threshold: 1,
      });
      observer.observe(ref.current);
      return () => {
        if (ref.current) observer.unobserve(ref.current);
      };
    }
  }, [deps]);

  return { elementRef: ref };
}

그럼 요소에 ref만 달아주면 ref가 화면에 보일때 콜백이 수행된다.

...
const { elementRef } = useRefFocusEffect<HTMLDivElement>(fetch, [data]);

return <div ref={elementRef}>이 요소가 보이면 fetch</div>
}

이렇게 하면 해당 요소가 화면에 100%보일때 fetch가 일어나게 할 수 있다.

즉, 이전 onScroll처럼 무의미하게 호출을 하지 않고 필요할때만 콜백을 호출할 수 있는 것이다.

다음 게시글에서는 피드 데이터를 어떻게 받아오고, 관리할 것인지를 알아보자.

웹뷰 + 모노레포 환경에서 자동 토큰 갱신 훅으로 개발자 경험 개선하기 (feat. axios, zustand)

_0422 — Fri, 26 Jan 2024 18:25:38 +0900

https://0422.tistory.com/347

React, RN 환경에서 WebView 통신하기 (react-native-webview)

배경 웹뷰를 사용하여 앱을 구성하고 있다. 웹뷰는 마치 HTML의 iframe 태그처럼, 내부적으로 하나의 화면을 띄우는 형태이다. 그런데 우리 서비스의 로그인 로직은 앱에 있어서, 웹에서 따로 로그

0422.tistory.com

위 글에서 이어진다.

이전 게시글을 통해 앱-웹간 통신으로 토큰을 받아오고 이벤트를 발생시키는 것까지는 완료했다.

하지만 이제부터 시작이다. 받아오기전에는 어떻게 하고, 받은 토큰을 어떻게 관리할 것인가?

토큰을 받아오기 전에는?

토큰은 앱의 onLoad를 통해 주입되지만, 이 이벤트가 동기적으로 작동하지는 않는다.

따라서 웹 화면은 로드되었으나, 토큰이 없는 시점이 분명하게 존재한다.

이때 api호출이 되면 무조건 401에러가 발생하므로 이러한 일이 일어나지 않도록 방지해주어야 했다.

간단하면서도 명확한 방법이 있었다.

최상단 App.tsx에서 access나 refresh 토큰이 없는경우 Loading컴포넌트를 보여주는 것이다.

function App() {
  const { setAccess, setRefresh } = useSetToken();
  const { access, refresh } = useToken();

  const tokenHandler = (event: MessageEvent) => {
    const { accessToken, refreshToken } = JSON.parse(event.data);
    setAccess(accessToken);
    setRefresh(refreshToken);
  };

  useEffect(() => {
    document.addEventListener('message', tokenHandler as EventListener);
    window.addEventListener('message', tokenHandler);
  }, []);

  if (!access || !refresh) return <Loading />;
  ...
}

받은 토큰 관리하기

이제 이 토큰을 어떻게 관리해야하는지가 고민이다.

크게 두 가지 고민이 생긴다.

웹 사용중에 access token이 만료되는 경우 access token 갱신을 어떻게 해줄 것인가?
- 웹에서만 access token 토큰을 갱신한다 vs 앱에서도 access token을 갱신한다.
웹 사용중에 refresh token이 만료되면 어떻게 처리해줄 것인가?
어떤 방법을 사용하여 토큰을 관리할 것인가?
1. 쿠키
2. localStorage
3. 전역상태

이 두가지 고민에 대해서 우리 팀은 아래와 같은 결론을 냈다.

웹 사용 중에 access token이 만료되는 경우 access token 갱신을 어떻게 해줄 것인가?
- 앱에서 JWT토큰을 웹으로 넣어주면, 웹에서는 내부적으로 토큰을 갱신하고, 관리한다.
- 굳이 앱과 웹의 토큰 수명 주기를 맞춰줄 필요성을 느끼지 못했기 때문이다.
웹 사용중에 refresh token이 만료되면 어떻게 처리해줄 것인가?
- 웹 사용중에 refresh token이 만료되는 경우 앱에서 로그아웃 처리하고, 재로그인 시킨다.
- 이건 웹 내부에서 다시 재로그인을 시킬 수는 없기때문에 이 방법밖에 없다고 판단했다.
어떤 방법을 사용하여 토큰을 관리할 것인가?
1. 쿠키 : 로그인 자체를 웹환경에서 하지 않기때문에 Set-Cookie를 통해 httpOnly쿠키를 받아올 수 없다. 즉, 쿠키로 관리하는 장점이 없다.
2. localStorage: 매번 웹뷰가 열릴때 토큰을 주입받으므로 localStorage를 사용할 이유가 없다.

따라서 전역상태로 토큰들을 관리하기로 했다. 전역상태 라이브러리는 번들 사이즈가 작은 Zustand를 택했다.

또한 토큰 에러 핸들링을 직접 api마다 해주면 매우 반복되는 작업이 많아지고 힘들어지기에 자동 갱신이 되도록 axios interceptor를 활용해줄 것이다.

더불어 우리는 모노레포로 Turborepo를 사용하고 있다. 여러 apps에서 사용할 수 있어야한다.

여러 레포에서 사용할 수 있는 자동 토큰 관리 시스템을 만들어줄 것이다.

구현하기

package/hooks 만들기

공통 훅들을 여기에 모아줄 것이다.

axios와 zustand를 설치해주었다.

//package.json
{
  "name": "@repo/hooks",
  "version": "1.0.0",
  "description": "common hooks",
  "main": "./index.ts",
  "types": "./index.ts",
  "private": true,
  "keywords": [],
  "author": "",
  "license": "ISC",
  "scripts": {
    "lint": "npx prettier --write src & eslint src"
  },
  "devDependencies": {
    "@repo/eslint-config": "*", //lint공통 설정
    "@repo/typescript-config": "*", //ts공통설정
    "@types/axios": "^0.14.0",
    "typescript": "^5.3.3"
  },
  "dependencies": {
    "axios": "^1.6.5",
    "zustand": "^4.4.7"
  }
}

전역상태 만들기

AuthStore를 만들어주었다.

import { create } from 'zustand';

interface AuthState {
  access: string;
  refresh: string;
  setAccess: (value: string) => void;
  setRefresh: (value: string) => void;
}

const useAuthStore = create<AuthState>((set) => ({
  access: '',
  refresh: '',
  setAccess: (value: string) => set((state) => ({ ...state, access: value })),
  setRefresh: (value: string) => set((state) => ({ ...state, refresh: value })),
}));

export default useAuthStore;

토큰을 쓰는 곳과 set하는 곳이 다를 수 있을거라 생각해서... 두개의 훅으로 분리시켜주었다.

// useToken.ts
import useAuthStore from '../stores/useAuthStore';

export default function useToken() {
  const access = useAuthStore((state) => state.access);
  const refresh = useAuthStore((state) => state.refresh);
  return { access, refresh };
}


// useSetToken.ts
import useAuthStore from '../stores/useAuthStore';

export default function useSetToken() {
  const setAccess = useAuthStore((state) => state.setAccess);
  const setRefresh = useAuthStore((state) => state.setRefresh);
  return { setAccess, setRefresh };
}

axios interceptor 를 활용한 useAuthAxiosInstance

access token이 만료되면, refresh한후에 재요청을 보내는 axios인스턴스를 만들어서 내보내는 훅을 만들어주었다.

함수가 아닌 훅을 택한 이유는 여기서 전역상태 토큰을 알아서 관리해줄 것이기 때문이다.

baseURL과 onError 함수를 받아 각 프로젝트별로 다른 URL를 base로 사용할 수 있게 했고, refresh가 만료된 경우에도 각각 다른 Action을 일으킬 수 있게 만들었다.

export default function useAuthAxiosInstance(baseURL: string, onError: () => void) {
  const { access, refresh } = useToken();

  const authAxios = axios.create({
    baseURL, 
    headers: {
      Authorization: `Bearer ${access}`,
    },
  });
  
  ...
 
}

baseURL과 access token을 알아서 넣어서 요청하는 인스턴스를 만들었다.

이제 401인경우 refresh를 통해 토큰을 갱신시켜주자.

authAxios.interceptors.response.use(
    (res) => res, //응답이 okay면 그냥 결과를 내보낸다.
    async (error) => {
      const {
        config,
        response: { status },
      } = error;
      if (status !== 401) return Promise.reject(error); //401이 아니면 Promise를 reject시킨다.
      try { //아니라면(401이면) 토큰을 재발급하여 재요청보낸다.
        const { accessToken: newAccessToken, refreshToken: newRefreshToken } = await getNewToken(baseURL, refresh); //새로운 토큰을 발급받는다.
        setAccess(newAccessToken); 
        setRefresh(newRefreshToken); 
        
        config.headers.Authorization = `Bearer ${newAccessToken}`; //기존 요청의 헤더를 재설정한다.
        const response = await axios.get(config.url, config); //기존 요청을 한번 더 보낸다.
        return await Promise.resolve(response); //결과를 내보낸다.
      } catch (err) {
        onError(); //재발급에서 오류가 나면 주입받은 onError 함수를 수행한다.
        return Promise.reject(err);
      }
    },
  );

위 로직을 그림으로 그리면 아래와 같다.

이러면 사용자는 만료가 된줄도 모르고 그냥 정상적인 요청처럼 응답을 받게된다.

더불어 개발자는 여기서 만든 authAxios를 통해 요청하면 토큰에 대해서 전혀 신경쓰지 않아도 된다.

전체코드

import axios from 'axios';
import useToken from './useToken';
import useSetToken from './useSetToken';

const getNewToken = async (baseURL: string, refresh: string) => {
  const { data } = await axios.get(`${baseURL}/token`, { headers: { Authorization: `Bearer ${refresh}` } });
  return data as { accessToken: string; refreshToken: string };
};

export default function useAuthAxiosInstance(baseURL: string, onError: () => void) {
  const { access, refresh } = useToken();
  const { setAccess, setRefresh } = useSetToken();

  const authAxios = axios.create({
    baseURL,
    headers: {
      Authorization: `Bearer ${access}`,
    },
  });

  authAxios.interceptors.response.use(
    (res) => res,
    async (error) => {
      const {
        config,
        response: { status },
      } = error;
      if (status !== 401) return Promise.reject(error);
      try {
        const { accessToken: newAccessToken, refreshToken: newRefreshToken } = await getNewToken(baseURL, refresh);
        setAccess(newAccessToken);
        setRefresh(newRefreshToken);
        config.headers.Authorization = `Bearer ${newAccessToken}`;
        const response = await axios.get(config.url, config);
        return await Promise.resolve(response);
      } catch (err) {
        onError();
        return Promise.reject(err);
      }
    },
  );
  return authAxios;
}

사용하기

최초 토큰 초기화

토큰이 app에서 넘어왔을때, 딱 한번 set해줄 필요가 있다.

function App() {
  const { setAccess, setRefresh } = useSetToken();
  const { access, refresh } = useToken();

  const tokenHandler = (event: MessageEvent) => {
    const { accessToken, refreshToken } = JSON.parse(event.data);
    setAccess(accessToken);
    setRefresh(refreshToken);
  };

  useEffect(() => {
    document.addEventListener('message', tokenHandler as EventListener);
    window.addEventListener('message', tokenHandler);
  }, []);

  if (!access || !refresh) return <Loading />;

  ...
}

useAuthAxios

레포에서 useAuthAxiosInstance를 import해서 useAuthAxios로 한번 래핑해주자.

import { useAuthAxiosInstance } from '@repo/hooks';

export default function useAuthAxios() {
  const onError = () => {
    window.ReactNativeWebView.postMessage(JSON.stringify({ type: 'LOGOUT' })); //refresh가 만료되면 로그아웃 처리
  };
  return useAuthAxiosInstance(import.meta.env.VITE_API_URL, onError);
}

이후에 사용해주면 토큰 신경쓸 필요없이 api요청이 가능해진다.

import { useQuery } from '@tanstack/react-query';
import REACT_QUERY_KEYS from '@/constants/REACT_QUERY_KEYS';
import useAuthAxios from '@/hooks/useAuthAxios';

export default function useSomeQuery() {
  const authAxios = useAuthAxios(); //요 훅만 사용하면 알아서 토큰이 담긴다!

  const getMyPosts = async () => {
    const result = await authAxios.get('/apiUrl');

    return result.data;
  };

  return useQuery({ queryKey: [REACT_QUERY_KEYS.MY_POSTS], queryFn: useSomeQuery });
}

결론적으로 위의 이미지 처럼 작동하게 되고, 각 프로젝트에서는 token에 대해 신경쓸 필요없이 api요청을 할 수 있게 된다.

React, RN 환경에서 WebView 통신하기 (react-native-webview)

_0422 — Fri, 26 Jan 2024 17:20:27 +0900

배경

웹뷰를 사용하여 앱을 구성하고 있다.

웹뷰는 마치 HTML의 iframe 태그처럼, 내부적으로 하나의 화면을 띄우는 형태이다.

그런데 우리 서비스의 로그인 로직은 앱에 있어서, 웹에서 따로 로그인/로그아웃을 구현하지 않고, 앱 내부의 JWT토큰을 웹으로 전달할 수 있어야 했다. 또한 웹내에서 JWT토큰이 만료되는 경우 로그인 페이지로 이동시켜줄 필요가 있었다.

우선 Web과 App환경의 통신 방법에 대해 알아보고, 이후에 토큰을 내부적으로 관리해볼 것이다.

기본 구성하기

기본적으로 react-native-webview 라이브러리를 사용해서 WebView 화면을 띄워주었다.

https://www.npmjs.com/package/react-native-webview

react-native-webview

React Native WebView component for iOS, Android, macOS, and Windows. Latest version: 13.6.4, last published: 24 days ago. Start using react-native-webview in your project by running `npm i react-native-webview`. There are 950 other projects in the npm regi

www.npmjs.com

해당 라이브러리는 웹뷰 컴포넌트를 지원한다.

요런식으로 uri만 집어넣으면 해당 웹 사이트를 앱 내부에서 브라우저로 띄워주는 것이다.

import React, { Component } from 'react';
import { StyleSheet, Text, View } from 'react-native';
import { WebView } from 'react-native-webview';

// ...
const MyWebComponent = () => {
  return <WebView source={{ uri: 'https://reactnative.dev/' }} style={{ flex: 1 }} />;
}

이벤트 핸들러 알아보기

react-native-webview에서 제공하는 WebView컴포넌트는 다양한 이벤트 핸들러를 제공한다.

그중 onLoad와 onMessage를 사용해서 웹 화면과 앱이 통신하게 만들 것이다.

onLoad는 웹뷰 화면이 불러와졌을때를, onMessage는 웹으로 부터 메시지를 받은 경우, 콜백함수를 수행시킨다.

postMessage

웹뷰와 웹 모두 postMessage라는 메서드를 통해 통신한다.

웹의 경우에는 window.ReactNativeWebView.postMessage 를 통해, 앱에서는

WebView컴포넌트.postMessage형태로 사용한다. (ref를 활용해야한다.)

다만, 이 두가지 상에서 오고갈 수 있는 것은 string데이터여서 객체를 보내기 위해서는 JSON.stringify를 통해 string으로 변환하여 넘겨야하고, 받을때는 JSON.parse를 통해 객체로 변환해주어야한다.

양방향 통신 간단하게 살펴보기

앱 (RN) -> 웹 (React)

앱에서 토큰 넘겨주기

그럼 이제 onLoad됐을때 WebViewRef.current.postMessage를 통해 웹화면으로 token을 넘겨주면된다.

export default function CustomWebView({uri}: {uri: string}) {
  const webViewRef = useRef<WebView>(null);
  const onLoad = async () => {
    const accessToken = await storageGetValue('accessToken'));
    const refreshToken = await storageGetValue('refreshToken');
    if (webViewRef.current) {
      webViewRef.current.postMessage(
        JSON.stringify({accessToken, refreshToken}),
      );
    }
  };
  
  ...
  return <WebView
        uri={{uri}}
        ref={webViewRef as any}
        onLoad={onLoad}
      />
  }

웹에서 토큰 받기

App.tsx 최상단에서 window의 onmessage 이벤트에 대한 콜백함수를 등록해주자.

onmessage이벤트는 여기를 참고하면 좋다. (이렇게 등록하는 것으로 보아 WebViewRef.currentMessage.postMessage는 Window.postMessage를 활용한다는 것을 유추해 볼 수 있다.)

//App.tsx 
  const tokenHandler = (event: MessageEvent) => {
    const { accessToken, refreshToken } = JSON.parse(event.data);
    console.log(accessToken, refreshToken);
  };

  useEffect(() => {
    //안드로이드와 iOS의 차이때문에 두개를 달아준다.
    document.addEventListener('message', tokenHandler as EventListener);
    window.addEventListener('message', tokenHandler);
  }, []);

웹(React) -> 앱(RN)

웹에서 앱으로 일으키는 이벤트는 window.ReactNativeWebView.postMessage메서드를 통해서 발생시킬 수 있고, 앱에서는 WebView컴포넌트의 onMessage props를 통해 콜백을 등록할 수 있다.

웹에서 이벤트 일으키기

window.ReactNativeWebView.postMessage를 통해 일으킨다.

ts를 사용중인 경우 global declare를 통해 타입을 추가해주자.

나같은 경우에는 vite를 사용하기에 vite-env.d.ts에 Window interface를 추가하여 타입문제를 해결했다.

/// <reference types="vite/client" />
interface Window {
  ReactNativeWebView: {
    postMessage: (value: string) => void;
  };
}

예시로 type이 Back인 객체를 전송해보겠다.

export default function MyPageHeader({ children }: { children: string }) {
  const back = () => window.ReactNativeWebView.postMessage(JSON.stringify({ type: 'BACK' }));
  return <Header onClick={back}>{children}</Header>;
}

헤더에서 뒤로가기를 누르면 앱에서 뒤로가기를 하게 만들 것이다.

앱에서 이벤트 받기

앱에서는 onMessage 핸들러를 추가해서 이벤트 data를 받아올 수 있다.

  const onMessage = async (event: WebViewMessageEvent) => {
    const {nativeEvent} = event;
    const {type} = JSON.parse(nativeEvent.data); //받은 string을 객체로 변환하고, type을 가져옴

    if (type === 'BACK') navigation.goBack(); 
    if (type === 'LOGOUT') logoutApi();
  };

위의 코드들을 통해서 웹뷰와 웹 환경의 양방향 통신을 방법에 대해 알아보았다.

다음 게시글에서는 여기서 받은 JWT를 통해 어떻게 웹에서 토큰을 관리했는지 작성해볼 것이다.

React로 라이브러리 없이 Carousel 만들기 (2) - Indexed Carousel

_0422 — Sat, 20 Jan 2024 14:23:01 +0900

Indexed Carousel

이제 Index 기반의 Carousel을 구현해보자.

사실 로직은 이전 글과 거의 동일하다. 시작 터치 위치를 기억하고, 움직일때 transX를 변경하고, transX를 기반으로 translateX를 통해 스크롤을 구현한다.

여기서 Index를 추가하고, 특정 scroll값을 넘으면 인덱스를 변경시켜 주고, translateX값을 Index기반으로 작동하도록 만들어주면된다.

그래서 handleTouchStart와 handleTouchMove콜백함수는 Non-Indexed와 동일하다.

// Non-Indexed와 동일하다.
const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    setTouchStartX(e.touches[0].clientX);
  };

  const handleTouchMove = (e: React.TouchEvent<HTMLDivElement>) => {
    const moveWidth = e.touches[0].clientX - touchStartX;
    setTransX(moveWidth);
  };

Index State를 추가해주자.

  const [index, setIndex] = useState(0);

이제 끝났을때와 translateX가 문제다.

어떻게 이걸 인덱스 기반으로 작동시킬 수 있을까?

내가 어떻게 작동하기 원하는지, 기대하는 것을 작성해보자.

임계값보다 많이 scroll했다면, 오른쪽으로 scroll했다면 index를 하나 늘리고, 왼쪽으로 scroll했다면 index를 하나 줄인다.
index*각 요소 너비만큼 스크롤을 이동시킨다.

여기서 1번은 handleTouchEnd시에, 2번은 translateX에서 일어나야한다.

즉, handleTouchEnd에서 조정해준 index를 기반으로 translateX값을 변경하면된다.

인덱스마다 얼마나 이동시켜 줄 것인가?

인덱스 기반으로 이동시키다보니 인덱스 한칸의 너비를 어떻게 주어야 요소가 중앙에 올것인가?를 고민하게됐다.

그러나 요소 배치를 어떻게 하냐에 따라 어떻게 중앙에 배치시킬 수 있을지가 달라진다.

요소를 순서대로 그냥 나열

첫번째로 아래와 같이 요소의 너비와 관계없이 요소를 주르륵 배치했을때다.

이때는 정확한 자식 요소들의 width값을 알아야 중앙에 위치시킬 수 있다.

하지만 내가 원하는 IndexCarousel은 children을 받아서 어떤 요소든 Carousel로 배치시킬 수 있도록 만들 것이기 때문에 정확한 값에 의존하게 만들고 싶지는 않았다.

내부 요소를 스크롤 요소의 보이는 너비와 동일하게 맞추기

요소를 기본적으로 스크롤 요소가 화면에 보이는 너비와 동일하게 맞춰주고, 내부에서 padding을 줘서 중앙에 맞추면 스크롤은 스크롤 요소가 화면에 보이는 만큼만 줘도 된다.

전체 화면너비가 아닌, 스크롤한 요소의 화면너비로 맞춰준 이유는, 스크롤 요소의 보이는 영역은 줄어들 수 있기 때문이다.

그러면 index*스크롤wrapper요소의 너비 로 index기반의 슬라이드를 구현할 수 있다.

그래서 아래와 같이 style을 주었다.

 export default function IndexCarousel({ children }: { children: ReactNode }) {
   const getSliderWidth = () => {
    if (ref.current) {
      return ref.current.clientWidth; //스크롤 wrapper의 화면에 보이는 너비를 가져온다.
    }
    return 0;
  };
 ...
  return (
    <div className="overflow-hidden">
      <div
        ref={ref}
        className="flex"
        style={{
          transform: `translateX(${-index * getSliderWidth() + transX}px)`, //transX를 주지 않으면 중간 스크롤 중에 이동하지 않는다.
          transitionDuration: '300ms',
          transitionTimingFunction: 'ease-out',
        }}
        onTouchStart={handleTouchStart}
        onTouchMove={handleTouchMove}
        onTouchEnd={handleTouchEnd}
      >
        {children}
      </div>
    </div>

그러면 터치가 끝났을때 index와 transX값을 조정해주기만 하면된다.

  const handleTouchEnd = () => {
    const limitPage = Children.count(children) - 1; //children의 갯수-1만큼 스크롤 가능하게 만든다.
    if (transX > MIN_MOVE) { //지정한 최소값보다 큰 경우만 index를 조정한다.
      setIndex((prev) => (prev > 0 ? prev - 1 : prev));
    } else if (transX < -MIN_MOVE) {
      setIndex((prev) => (prev < limitPage ? prev + 1 : prev));
    }
    setTransX(0); //translateX에서 준 +transX때문에 0으로 지정해주어야 인덱스에 딱 맞게 지정이 된다.
    setTouchStartX(0); //터치 위치를 초기화한다.
  };

그럼 이제 인덱스 기반의 Carousel이 동작한다.

전체 코드

import { Children, ReactNode, useRef, useState } from 'react';

const MIN_MOVE = 60;

export default function IndexCarousel({ children }: { children: ReactNode }) {
  const [touchStartX, setTouchStartX] = useState(0);
  const [transX, setTransX] = useState(0);
  const [index, setIndex] = useState(0);
  const ref = useRef<HTMLDivElement>(null);

  const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    setTouchStartX(e.touches[0].clientX);
  };

  const handleTouchMove = (e: React.TouchEvent<HTMLDivElement>) => {
    const moveWidth = e.touches[0].clientX - touchStartX;
    setTransX(moveWidth);
  };

  const getSliderWidth = () => {
    if (ref.current) {
      return ref.current.clientWidth;
    }
    return 0;
  };

  const handleTouchEnd = () => {
    const limitPage = Children.count(children) - 1;
    if (transX > MIN_MOVE) {
      setIndex((prev) => (prev > 0 ? prev - 1 : prev));
    } else if (transX < -MIN_MOVE) {
      setIndex((prev) => (prev < limitPage ? prev + 1 : prev));
    }
    setTransX(0);
    setTouchStartX(0);
  };

  return (
    <div className="overflow-hidden">
      <div
        ref={ref}
        className="flex"
        style={{
          transform: `translateX(${-index * getSliderWidth() + transX}px)`,
          transitionDuration: '300ms',
          transitionTimingFunction: 'ease-out',
        }}
        onTouchStart={handleTouchStart}
        onTouchMove={handleTouchMove}
        onTouchEnd={handleTouchEnd}
      >
        {children}
      </div>
    </div>
  );
}

문제점

문제는 우리 디자인은 양 옆의 요소가 약간 보여야 하고, 중앙에 온 요소가 다른 요소보다 커야한다는 것이다.

효과보다 index에 집중해서 보면 어디까지 요소가 있는지 전혀 알수가 없다.

Index Carousel을 훅으로 만들기

기존의 IndexCarousel로직을 그대로 사용하되, 약간만 바뀌기 때문에 IndexCarousel 컴포넌트를 useIndexCarousel로 변경해줄 것이다.

import { useRef, useState } from 'react';

export default function useIndexCarousel(pageLimit: number, minMove = 60) {
  const [touchStartX, setTouchStartX] = useState(0);
  const [transX, setTransX] = useState(0);
  const [index, setIndex] = useState(0);
  const ref = useRef<HTMLDivElement>(null);

  const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    setTouchStartX(e.touches[0].clientX);
  };

  const handleTouchMove = (e: React.TouchEvent<HTMLDivElement>) => {
    const moveWidth = e.touches[0].clientX - touchStartX;
    setTransX(moveWidth);
  };

  const getSliderWidth = () => {
    if (ref.current) {
      return ref.current.clientWidth;
    }
    return 0;
  };

  const handleTouchEnd = () => {
    const limitPage = pageLimit;
    if (transX > minMove) {
      setIndex((prev) => (prev > 0 ? prev - 1 : prev));
    } else if (transX < -minMove) {
      setIndex((prev) => (prev < limitPage ? prev + 1 : prev));
    }
    setTransX(0);
    setTouchStartX(0);
  };

  const style = {
    transform: `translateX(${-index * getSliderWidth() + transX}px)`,
    transitionDuration: '300ms',
    transitionTimingFunction: 'ease-out',
  };

  return { style, ref, handleTouchStart, handleTouchMove, handleTouchEnd, index };
}

이걸 사용해서 중앙에 온 요소가 커지고, 양 옆요소가 살짝 보이는 ScaleCarousel을 만들어 줄것이다.

기본 아이디어

기존의 요소 배치는 아래 그림과 같았다.

중앙요소가 다른 요소보다 더 크게 보여야하므로 요런식으로 처리하면 된다.

이걸 하려면 자식요소에서 index값을 받아서 transform 처리를 해주어야한다.

그런데 내가 만든 Carousel은 children props을 통해서 자식요소를 렌더링하기때문에 그냥 렌더링해서는 자식요소에서 index를 받을 수 없다는 문제가 있다.

이를 해결하기 위해서 ScaleCarouselProvider를 통해서 자식요소에 index를 내려주었다. 그리고 Wrapper.tsx를 작성해주었다.

context.ts

import { createContext, useContext } from 'react';

export const ScaleCarouselIndex = createContext<number>(0);

export const useScaleCarouselIndex = () => {
  return useContext(ScaleCarouselIndex);
};

Wrapper.tsx

import { Children, ReactNode } from 'react';
import { useIndexCarousel } from '@repo/hooks';
import { ScaleCarouselIndex } from './context';

const MIN_MOVE = 60;

export default function Wrapper({ children }: { children: ReactNode }) {
  const pageLimit = Children.count(children) - 1;
  const { index, ref, style, handleTouchStart, handleTouchMove, handleTouchEnd } = useIndexCarousel(pageLimit, MIN_MOVE);

  return (
    <div className="overflow-hidden">
      <div
        ref={ref}
        className="flex"
        style={style}
        onTouchStart={handleTouchStart}
        onTouchMove={handleTouchMove}
        onTouchEnd={handleTouchEnd}
      >
        <ScaleCarouselIndex.Provider value={index}>{children}</ScaleCarouselIndex.Provider>
      </div>
    </div>
  );
}

이제 자식요소에서 useScaleCarouselIndex를 통해 자신의 map인덱스와 중앙에 위치한 인덱스를 비교하여

중앙 인덱스 양옆에 있는 요소의 경우 scale과 translate를 통해 중앙으로 당겨와주면 된다.

import { ReactNode } from 'react';
import { useScaleCarouselIndex } from './context';

const getTransform = (mapIndex: number, scaleIndex: number) => {
  const MOVE_VALUE = 8.5;
  const SCALE_POINT = 0.8;
  if (mapIndex === scaleIndex) return '';
  if (mapIndex === scaleIndex + 1) return `scale(${SCALE_POINT}) translate(-${MOVE_VALUE}rem)`;
  if (mapIndex === scaleIndex - 1) return `scale(${SCALE_POINT}) translate(${MOVE_VALUE}rem)`;
};

export default function Card({ index, children }: { index: number; children: ReactNode }) {
  const scaleIndex = useScaleCarouselIndex();
  return (
    <div
      className="flex-shrink-0 w-full"
      style={{
        transform: getTransform(index, scaleIndex),
        transitionDuration: '300ms',
      }}
    >
      <div className="px-10 w-full">{children}</div>
    </div>
  );
}

이러면 이제 옆요소가 잘 보이게된다!

문제 발생

하지만.. Ipad 같이 화면 너비가 넓어지면 양옆 요소가 제대로 보이지 않게된다는 문제가 발생했다.

이는 화면 너비가 넓어짐에 따라 스크롤 Wrapper의 너비가 커지게 되고, 이에따라 scale하는 정도도 같이 커져서 tranlate고정값으로는 요소를 제대로 가져올 수 없기 때문이었다.

translate하는 정도가 같아서 제대로 가져오지 못한다

translate %로 주기

translate를 %로 주면 해결될 일이라고 생각했다...만

translate의 %비율이 scale처리가 완료된 요소의 %로 들어가면서... 예상한대로 translate되지 않았다.

Scale Value에반응형 적용

화면 너비 500을 기점으로 보이지 않아서 500을 기준으로 scale을 화면너비에 따른 반응형으로 처리해주었다.

const getTransform = (mapIndex: number, scaleIndex: number) => {
  const MOVE_VALUE = 8.5;
  const SCALE_POINT = window.screen.width > 500 ? 0.9 : 0.8;
  if (mapIndex === scaleIndex) return '';
  if (mapIndex === scaleIndex + 1) return `scale(${SCALE_POINT}) translate(-${MOVE_VALUE}rem)`;
  if (mapIndex === scaleIndex - 1) return `scale(${SCALE_POINT}) translate(${MOVE_VALUE}rem)`;
};

이제 화면너비 1200까지 대응이 된다! 1200까지 대응한 이유는 가장 큰 테블릿의 화면너비가 1200이기 때문이다.

합성 컴포넌트로 마무리

이제 이걸 index.ts로 묶어서 합성 컴포넌트로 만들어주자.

import Card from './Card';
import Wrapper from './Wrapper';

export default { Card, Wrapper };

이제 야무지게 쓰면된다.

import { Loading } from '@repo/components';
import useVoteListQuery from '@/api/useVoteListQuery';
import ScaleCarousel from './ScaleCarousel';
import Vote from './Vote/Vote';

export default function TodayVote() {
  const { data } = useVoteListQuery();

  if (!data) return <Loading />;

  return (
    <ScaleCarousel.Wrapper>
      {data.todayVoteList.map((vote, index) => (
        <ScaleCarousel.Card key={vote.voteListId} index={index}>
          <Vote data={vote} />
        </ScaleCarousel.Card>
      ))}
    </ScaleCarousel.Wrapper>
  );
}

React로 라이브러리 없이 Carousel 만들기 (1) - Non-Indexed Carousel

_0422 — Sat, 20 Jan 2024 12:12:47 +0900

문제상황

Teengle 프로젝트는 웹뷰프로젝트로, 모바일 기기에서 실행되어야하다보니, 여러 정보를 작은 화면에서 조회하기위해서 상당히 많은... Carousel이 필요했다.

Non-Indexed Carousel

첫번째 Carousel은 커뮤니티 피드에서 마치 스레드처럼 여러개의 사진을 볼 수 있는 기능에 필요했다.

이 Carousel은 아래 사진 처럼 스크롤한 만큼 자유롭게 이동이가능해야했다.

그냥 overflow scroll로 구성해서는 스크롤 속도가 너무 빨라서 사용할 수 없었다.

overflow-scroll만 적용한 모습(너무빠르다)

Indexed Carousel

두번째 Carousel은 투표기능에서 여러 투표를 슬라이드를 통해 확인하기 위해 필요했다.

이 Carousel은 스크롤시에 요소를 중앙으로 배치시켜주어야 했기에 Non-Indexed와 로직은 비슷하지만, 약간은 다른 형태가 필요했다.

결론적으로 Indexed와 Non-Indexed 각각 두개의 Carousel이 필요한 상황이다.

라이브러리 도입을 하지 않은 이유

라이브러리를 사용할까 고민했다.

사실 이전까지 애용하던 js 애니메이션 라이브러리는 framer-motion이라는 라이브러리였는데, 번들사이즈를 확인해보니 놀라지 않을 수 없었다. (물론 이건 트리쉐이킹은 적용되지 않은 용량이긴하고 framer-motion의 번들사이즈를 줄일 수도 있긴하다 하지만.. 그래도 크다)

framer-motion의 번들사이즈

특히 우리 서비스는 모바일 환경이다보니 느린 3G환경에서 사용하는 사용자도 충분히 많을 것이다. (~~나도 데이터를 다써서... 느린 3G를 쓰고있다...~~)

초기 렌더링시에 라이브러리를 다운받다보면 거의 1초가 걸리게된다는 점에서 라이브러리 없이 직접 구현하는게 좋겠다는 생각을 하게됐다.

전역 상태 관리 도구인 zustand와 번들사이즈가 거의 40배정도 차이가 난다.

이 두가지 Carousel을 라이브러리 없이 리액트 환경에서 하나씩 구현해보자.

구현하기

TouchEvent vs MouseEvent

그렇다 둘은 다른 이벤트이다. 하지만, 우리 서비스는 웹뷰 서비스이므로, 데스크톱에 대해서는 대응을 하지 않을 것이다.( 배포접근자체를 막을 생각이다.)

따라서 이 게시글에서는 TouchEvent만을 다룬다.

기본 개념 생각하기

스크롤이란 무엇인가....

사실 이번에 구현을 하면서 정말 많은 것들을 무의식적으로 사용하고 있구나 라고 느꼈다.

모바일환경에서 스크롤이란 무엇일까?

터치가 처음 시작해서 끝날때까지 끊기지 않고 이어지는 것이다. 그리고 터치가 끝나면, 스크롤이 끝난다.

그말은 스크롤을 구현하려면 처음 터치가 시작된 위치를 기록하고, 이동하는 만큼 요소를 이동시켜주면 된다는 것이다.

구현에 필요한 것들 찾기

그럼 구현에 필요한 것들을 어떻게 얻을 수 있을지 생각해보자.

이벤트에 대한 정보이므로 TouchEvent 핸들러에 제공되는 콜백에 event객체로 얻을 수 있으면 베스트다.

그래서 TouchEvent MDN을 살펴봤다.

TouchEvent는 event객체에 touches를 담고있다. 이는 Touch Object의 집합이다.

그리고 Touch Object는 clientX라는 프로퍼티를 갖는데 이 프로퍼티를 통해서 브라우저 기준으로 터치가된 위치 정보를 가져올 수 있게된다. (스크롤은 포함하지 않는다.)

그리고 터치 이벤트로 touchStart, touchMove, touchEnd이벤트가 있다고 한다. 이거 세개면 충분히 구현할 수 가 있다.

Non-Index Carousel 구현하기

그럼 위의 정보들을 써서 인덱스 없는 스크롤 한 그대로 유지되는 Carousel을 만들어보자.

정리해보면 주요로직은 아래와 같다.

Touch가 시작되면, 시작 지점을 기록한다.
Touch가 이어지는동안 시작지점에서 현재 터치되는 요소까지의 거리를 스크롤할 요소의 스크롤 값에 더한 뒤, 스크롤 값으로 넣어준다. 그리고 시작값을 현재 터치가 일어나는 값으로 바꿔준다.(중첩해서 적용되지않도록)

이 과정에서 신경써야 할 것은, 스크롤 할 요소의 총 너비를 벗어나지 않게 할 것 이다.

이건 스크롤 요소의 총너비- 화면너비를 통해서 구할 수 있다.

전체 기본 코드

import { ReactNode, useRef, useState } from 'react';


export default function Carousel({ children }: { children: ReactNode }) {
  const [touchStartX, setTouchStartX] = useState(0);//터치 시작위치
  const [transX, setTransX] = useState(0); //스크롤 값
  const ref = useRef<HTMLDivElement>(null);
  
  const mediateScroll = (scrollValue: number) => {
  //스크롤 값이 스크롤 요소를 넘어가지 않도록 처리
    if (scrollValue > 0) return 0;

    if (ref.current) {
      const maxScroll = ref.current.scrollWidth - ref.current.clientWidth; //최대 스크롤 너비는 요소의 스크롤 너비 - 화면너비다

      if (maxScroll > -scrollValue) return scrollValue;

      return -maxScroll;
    }

    return 0;
  };
  
  const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    // 실제 이동에 사용할 시작점을 기록
    setTouchStartX(e.touches[0].clientX);
  };

  const handleTouchMove = (e: React.TouchEvent<HTMLDivElement>) => {
  //터치 중에 시작값과 스크롤 값을 갱신
    const moveWidth = e.touches[0].clientX - touchStartX;
    setTransX((prev) => mediateScroll(prev + moveWidth));
    setTouchStartX(e.touches[0].clientX);
  };

  return (
    <div className="overflow-hidden"> //tailwind를 사용했다.
      <div
        ref={ref}
        className="flex gap-2"
        style={{
          transform: `translateX(${transX}px)`, //여기서 스크롤을 이동시킨다.
          transitionDuration: '300ms',
          transitionTimingFunction: 'ease-out',
        }}
        onTouchStart={handleTouchStart}
        onTouchMove={handleTouchMove}
      >
        {children}
      </div>
    </div>
  );
}

이러면 잘 동작한다!

스크롤 속도 적용하기

그러나... 스마트폰에서 빠르게 스크롤하면, 더 많이 스크롤된다는 것을 우리는 본능적으로 알고 있다.

또한, 이게 처리가 안되어있으니 스크롤 모션이 너무 뻑뻑해 보이기도 한다.

위의 로직만으로는 이게 불가능하다. 그래서 나는 조금이나마 이런 사용자 경험을 높혀보고자 스크롤 속도에 따른 추가 스크롤을 구현해보았다.

핵심은 최초로 터치가 시작된 때부터 터치가 끝난시점까지 적은 시간동안 얼마나 많이 이동했느냐이다.

그래서 최초 좌표와 터치가 시작된 시점의 스크롤 정보 데이터를 저장해주었다.

 const [startInformation, setStartInformation] = useState({ value: 0, time: new Date(Date.now()) });
 
   const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    // 실제 이동에 사용할 시작점을 기록
    setTouchStartX(e.touches[0].clientX);
    // 가속 구현을 위해 touch 최초의 스크롤 정도와, 시간을 기록한다.
    setStartInformation({
      value: transX, 
      time: new Date(Date.now()),
    });
  };

그리고 터치가 끝난 시점에, 끝난 스크롤 위치-시작한 스크롤 위치 / 터치 과정에서 소요된 시간을 통해서 한번의 슬라이드 과정에서 움직인 이동거리를 구해준다.

그리고 가속 값을 곱해서 최종 스크롤 값을 변경시켜주면 터치가 끝났을때 추가 이동거리를 적용하고 이것이 transition이 적용되어 부드럽게 이동하게된다!

const handleTouchEnd=() => {
      const moveDistance = (transX - startInformation.value) / (new Date().getTime() - startInformation.time.getTime());
      setTransX((prev) => mediateScroll(prev + moveDistance * ACCELERATION_VALUE));
}

아주 부드러워졌다!

이렇게 Non-Indexed Carousel을 구현할 수 있었다.

완성된 전체 코드

import { ReactNode, useRef, useState } from 'react';

const ACCELERATION_VALUE = 30;

export default function Carousel({ children }: { children: ReactNode }) {
  const [startInformation, setStartInformation] = useState({ value: 0, time: new Date(Date.now()) });
  const [touchStartX, setTouchStartX] = useState(0);
  const [transX, setTransX] = useState(0);
  const ref = useRef<HTMLDivElement>(null);

  const mediateScroll = (scrollValue: number) => {
    if (scrollValue > 0) return 0;

    if (ref.current) {
      const maxScroll = ref.current.scrollWidth - ref.current.clientWidth;

      if (maxScroll > -scrollValue) return scrollValue;

      return -maxScroll;
    }

    return 0;
  };

  const handleTouchStart = (e: React.TouchEvent<HTMLDivElement>) => {
    // 실제 이동에 사용할 시작점으로,
    setTouchStartX(e.touches[0].clientX);
    // touch 최초의 시작점, 시간을 기록한다.
    setStartInformation({
      value: transX,
      time: new Date(Date.now()),
    });
  };

  const handleTouchMove = (e: React.TouchEvent<HTMLDivElement>) => {
    const moveWidth = e.touches[0].clientX - touchStartX;
    setTransX((prev) => mediateScroll(prev + moveWidth));
    setTouchStartX(e.touches[0].clientX);
  };

  return (
    <div className="overflow-hidden">
      <div
        ref={ref}
        className="flex gap-2"
        style={{
          transform: `translateX(${transX}px)`,
          transitionDuration: '300ms',
          transitionTimingFunction: 'ease-out',
        }}
        onTouchStart={handleTouchStart}
        onTouchMove={handleTouchMove}
        onTouchEnd={() => {
          const moveDistance = (transX - startInformation.value) / (new Date().getTime() - startInformation.time.getTime());
          setTransX((prev) => mediateScroll(prev + moveDistance * ACCELERATION_VALUE));
        }}
      >
        {children}
      </div>
    </div>
  );
}

Turborepo를 도입하게 된 이야기

_0422 — Sat, 13 Jan 2024 14:24:11 +0900

배경

새로운 프로젝트는 많은 사용자들이 모바일 환경에서 사용할 수 있도록 앱 형태를 택했다.
또, 플레이스토어/앱스토어에서의 업데이트 없이, 실험을 통해 앱을 지속적으로 빠르게 업데이트해보고자 그 중에서도 웹뷰를 선택하게 되었다.

사실 웹뷰는 토스/당근에서 다양한 실험/빠른 업데이트 때문에 사용한다는 이야기를 들은 뒤부터 사용자에게 정말 유효한 가치를 전달하려면 꼭 필요한 기술이라고 생각해서 꼭 한번 도전해보고 싶었다.

문제

웹뷰 화면 설계를 이야기 하지 않을 수가 없다.
웹뷰, 아니 앱의 문제점중 하나라고 한다면, 바로 스토어 리젝이다.
https://orangebrother.dev/blog/app_why_reject

iOS / Android 앱 심사 시에 발생하는 Reject 사유들

앱을 배포하기 위해서는 각 플랫폼에서 심사를 거쳐야 합니다. 그리고 이 심사는 길고 까다로운 일이 될 수 있습니다. 여러가지 사유들로 출시, 혹은 업데이트가 반려되기 때문입니다.

orangebrother.dev

여러가지 리젝 사유가 있지만, 가장 신경써야할 부분은 우리가 웹뷰 서비스라는 것이다.
웹뷰인 경우 리젝 확률이 기하급수적으로 상승한다.
왜 웹이 아니라 앱을 사용하냐에 대한 대답이 명쾌해야한다고 한다.

특히 푸시알림, 결제, 카메라 연동 등 네이티브 기능이 없이, 정말 웹화면과 동일한 앱이라면 거의 100% 리젝이 된다.
따라서 어떻게 하면 이러한 기능을 넣을지 고민했다.

예시 사진이다.

결과적으로 네비게이팅, 푸시알림, 소셜 로그인 기능을 앱단에서 처리하고, 위 사진처럼 네비게이팅시 결과 화면을 웹뷰로 보여주는 형태로 네이티브 기술을 사용하면서, 동시에 웹뷰도 사용할 수 있도록 구현하기로 했다.
즉 둘을 적절하게 섞는 것이다.

그러면 각 네브바 하나마다 하나의 웹뷰 배포가 필요해진다.

역시 예시사진이다.

그래서 우리 프로젝트는 위 예시 사진처럼 5개의 배포가 필요했다.
이렇게 배포 단위가 쪼개지면서, 자연스럽게 여러가지 고민거리들이 생기기 시작했다.

프로젝트 환경(ts, vite, jest, tailwind, eslint)을 5번 각각 구성해줘야함
tailwind config에서 5번 스타일을 지정해줘야함
공통된 타입/유틸/훅/컴포넌트가 동일해도 두 번 만들어 써야함
배포 CICD도 각각 따로, 5회 구성해야함

해결책

이러한 고민들을 바로 해결해줄 수 있는게 모노레포였다.

모노레포

모노레포란, 다수의 프로젝트를 한 개의 레포지토리 내에서 관리하는 소프트웨어 개발전략이다.
공통으로 사용하는 것들을 묶어서 하나의 패키지로 만들고, 이를 다른 프로젝트에서 사용할 수 있게 된다.

이를 통해 위에서 생겼던 5가지 고민을 모두 해결할 수 있다.

문제 : 프로젝트 환경(ts, vite, jest, tailwind, eslint)을 5번 각각 구성해줘야함 / tailwind config에서 5번 스타일을 지정해줘야함
해결 : tsconfig/jest/tailwind/eslint/ 공통 패키지 파일을 하나만 만들어서 다른 프로젝트에서 참조한뒤, 상속시키면 단 한번의 구성으로 모든 내부 프로젝트가 동일한 구성을 갖게할 수 있음

문제 : 공통된 타입/유틸/훅/컴포넌트가 동일해도 두 번 만들어 써야함
해결 : 공통된 타입/유틸/훅/컴포넌트를 따로 패키지로 분리하여 각 프로젝트에서 참조하여 사용가능

문제: 배포 CICD도 각각 따로, 5회 구성해야함
해결:

CI는 전체 레포에서 1회 테스트/빌드시키는 형태로 구성이 가능
CD는 각 프로젝트 폴더별로 구성하여 배포브랜치를 통해 독립적인 자동화 배포를 구성할 수 있음

이렇게 바로 우리가 겪었던 문제를 해결할 수 있기에 모노레포를 도입하기로 했다.

어떤 도구를 사용할 것인가?

대표적인 모노레포 구성을 위한 도구로는
Yarn, Lerna, Nx, Turborepo 4가지가 존재했다.

이중에 하나를 골라야 했는데 우리 팀의 결정 기준은 다음과 같았다.

프로젝트 마감/런칭이 3월까지는 완료되어야함 -> 학습 비용이 적어야함
Private repo를 사용하기에 github actions 제한시간이 2000분임 -> CI/CD 스크립트를 실행시키는데에 드는 시간을 감소시켜야만함

우선적으로 Yarn은 직접적으로 모노레포를 지원하지는 않는다. 직접 구성을 해야하는데, 학습 비용이 높으며, 따로 CI/CD과정에서 최적화도 직접 진행해야했다. 첫번째, 두번째 조건 모두 만족하지 않는다.

Lerna는 직접적으로 모노레포를 지원하지만, 캐시나 스크립트 병렬 실행/관리에 최적화되어있지는 않다. 즉 두번째 조건에서 탈락이다. (https://fromundefined.com/posts/2022-08-ultimate-monorepo/)

Nx vs Turborepo

마지막으로 남은게 Nx와 Turborepo인데, 이 둘 중에서 어떤것을 사용할지를 고민했다.

좌 - 병렬실행이 되지않는경우, 우 - 병렬실행이 되는경우

두 도구 모두 스크립트 병렬 실행을 지원해서, 병렬적으로 린트-테스트-빌드를 진행할 수 있다.

병렬 실행이 되지않으면 상단 좌측 이미지처럼 실행전 대기시작때문에 CI/CD에 소요되는 시간이 늘어나게 된다.

하지만 병렬실행이된다면? 상단 우측이미지처럼 소요되는 시간을 감소시킬 수 있다.

더불어 Turborepo와 Nx 둘다 클라우드 캐시를 지원하여, CI/CD환경에서 이미 빌드/테스트한 파일을 다시 빌드/테스트하지 않을 수 있어 CI/CD에 드는 시간을 더욱더 감소시킬 수 있었다.

실제로 사용하는 방법(https://d2.naver.com/helloworld/7553804#ch4)을 찾아보니 Turborepo가 설정하기에 더 간단하고, ~~Vercel에 인수되었으며~~ 간편하게 쓸수 있다고 판단하여 Turborepo를 선택하게 되었다.

구성하기

터보레포 설정은 공식문서(https://turbo.build/repo/docs/getting-started/create-new) 를 참고하기바란다.
여기서는 공식문서에 없는 내용들을 위주로 작성해보려고한다.

우리 프로젝트의 패키지 구성이다.

작업하게 되는 부분은 apps와 packages로 나뉜다.
apps는 프로젝트, packages는 공통으로 사용할 요소들로 구성해주었다.

공통 환경 구성하기

tailwind.config를 예시로 들겠다.
packages/tailwind-config/package.json에 이렇게 작성해주었다

{
  "name": "@repo/tailwind-config",
  "version": "0.0.0",
  "private": "true",
  "exports": {
    ".": "./tailwind.config.ts"
  },
  "devDependencies": {
    "tailwindcss": "^3.4.1"
  }
}

그리고 tailwind.config.ts는 아래와 같이 작성한다.

import type { Config } from 'tailwindcss';

//공통 tailwind.config.ts설정
const config: Omit<Config, 'content'> = {
  theme: {
    extend: {
	...
  },
};

export default config;

이렇게 하면 패키지 구성은 끝이다!

이걸 사용하는 apps에서 사용해보자.
apps/home/package.json이다.

{
  "name": "home",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    ...
  },
  "dependencies": {
    ...
  },
  "devDependencies": {
    "@repo/tailwind-config": "*",
    "@repo/typescript-config": "*",
    ...
    "autoprefixer": "^10.4.16",
    "postcss": "^8.4.32",
    "tailwindcss": "^3.4.0",
  }
}

그리고 이제 apps/home/tailwind.config.ts에서 공통파일을 import해서 상속해주면된다.

import type { Config } from 'tailwindcss';
import sharedConfig from '@repo/tailwind-config';

const config: Pick<Config, 'content' | 'presets'> = {
  content: ['./src/**/*.tsx'],
  presets: [sharedConfig],
};

export default config;

이러면 공통 tailwind.config만 바꿔도 home에서 변경된 custom 스타일을 사용할 수 있게 된다!

패키지 구성하기

이번에는 공통 패키지이다.
예시로 toast패키지를 들자면, packages/toast/package.json을 이렇게 구성해주었다.

{
  "name": "@repo/toast", //import할때 이 이름으로 import하면 된다.
  "version": "1.0.0",
  "description": "toast package",
  "main": "./index.tsx", //export 할 파일
  "types": "./index.tsx",
  "private": true,
  "license": "ISC",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "scripts": {
    "lint": "npx prettier --write src & eslint src",
    "test": "jest"
  },
  "devDependencies": {
    "@repo/eslint-config": "*",
    "@repo/jest-config": "*",
    "@repo/typescript-config": "*",
    "@testing-library/jest-dom": "^6.2.0",
    "@testing-library/react": "^14.1.2",
    "@types/jest": "^29.5.11",
    "jest": "^29.7.0",
    "jest-environment-jsdom": "^29.7.0",
    "ts-jest": "^29.1.1",
    "ts-node": "^10.9.2",
    "typescript": "^5.3.3"
  }
}

그리고 index.tsx를 아래와 같이 구성했다.

import ToastProvider from './src/ToastProvider';
import useToast from './src/hooks/useToast';

export { ToastProvider, useToast };

사용할 apps의 package.json에서 아래와 같이 등록해주면 된다.

그러면 이제 @repo/toast를 사용할 수 있게된다. ToastProvider로 App을 감싸주었다.

import ReactDOM from 'react-dom/client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { ToastProvider } from '@repo/toast';
import App from './App';
import './index.css';

const queryClient = new QueryClient({ defaultOptions: { queries: { staleTime: Infinity } } });

ReactDOM.createRoot(document.getElementById('root')!).render(
  <QueryClientProvider client={queryClient}>
    <ToastProvider>
      <App />
    </ToastProvider>
  </QueryClientProvider>,
);

빌드/테스트

이렇게 등록한 패키지, 앱들을 실행시키거나, 빌드하거나, 테스트하려면 해당 패키지의 package.json에 script를 작성해주고, 그 커맨드를 turbo.json에 등록해주면된다.

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "pipeline": {
    "build": { //전체 빌드
      "outputs": ["dist/**"]
    },
    "lint": { //전체 lint
      "dependsOn": ["^lint"]
    },
    "test": {}, //전체 테스트
    "dev": { //전체 개발 모드로 실행
      "cache": false,
      "persistent": true
    },
    "type-check": {} //tsc
  }
}

캐시 처리

파일이 변경되지 않으면 캐시가 사용되어 606ms만에 빌드가, 542ms만에 테스트가 끝난 모습이다.
만약 파일이 변경되면, 해당 부분에 대해서만 재빌드/테스트를 하기때문에 굉장히 효율적이다.

클라우드 캐싱

그러나 위의 캐시처리는 로컬 환경에서 파일을 통해 캐시하기때문에 github actions에서 빌드/테스트를 하는 경우에는 이를 쓸 수 가 없다.
그래서 vercel에서는 클라우드 캐싱과 github actions에서의 캐싱을 지원한다.
우리의 경우 github actions에서 사용하므로 공식문서의 두번째를 따라 진행했다. 굉장히 간단하게 설정할 수 있었다.
https://turbo.build/repo/docs/ci/github-actions

Using Turborepo with GitHub Actions – Turborepo

How to use GitHub Actions with Turborepo to optimize your CI workflow

turbo.build