올 한해에도 돌아보면 상당히 많은 일들은 했던것 같다.

<h1>2023 을 돌아보며 2024</h1>
<p>올 한해에도 돌아보면 상당히 많은 일들은 했던것 같다.</p>
<p>2023 에서는 둘 보다는 셋을 목표로 했지만 달성하지 못하였고 여전히 둘이다.</p>
<p>둘이서 지내는것도 나쁘지는 않다. 어느 정도 둘의 생활 패턴에 익숙해졌고, 서로 싫어하는것과 좋아하는것을 잘 알게 되었으며 이로 인해 큰 다툼은 잘 일어나지 않았다.</p>
<p>(물론 여전히 작은 투닥투닥은 있지만 장난반 진심반 이다)</p>
<p>올 한해는 플렉스팀의 온전히 있던 한 해였다.</p>
<p>작년의 목표를 한번 돌아 봤다.</p>
<pre><code>1. 둘 보다는 셋
2. 하루 일과를 충실히
    1. 모닝 아티클 (~ 30 분)
    2. 운동 (주짓수 or 크로스핏)
    3. 독서
    4. 하루를 기록하기
3. 진짜 Rust 를 배워볼까?
    1. 근데 무엇을 해야할지 모르겠네
4. 글을 좀 자주 써보기
    1. 한달의 한번? 두달에 한번?
</code></pre>
<p>나름 하루 일과를 충실히 했던것 같다. 아티클을 읽지 못했고, 어느날(겨울이 되고) 부터는 아침운동을 가지는 못했다. 그러나 나름 주짓수도 매일 가고, 독서도 꾸준히 했고, 하루를 기록하는 나만의 방법도 찾아서 꾸준히 기록 하였다.</p>
<p>다른 언어를 배우지도 못했고, 글도 못썼다. 생각해보니 4가지 중에 1가지 대략 0.8 가지 정도 한것 같다.</p>
<h1>일기</h1>
<p>하루를 기록 하는 방법도 확인해보니 07/31 부로 변경 된것 같다.</p>
<p>기존에는 task 단위로 기록을 남기다가, 하루하루의 기록을 남기는 방법을 변경했다.  또한 하루하루의 기록을 남기고 일주일에 마지막에 task 단위로 정리하는 방법을 사용하기로 했다.</p>
<p>주말에 뭔가를 정리해야한다는 부담감이 있지만, 기억에 많이 남으려면 노력해야한다.</p>
<p><img src="https://github.com/eomttt/eomttt-log/assets/22593217/3c374f15-3e04-41cb-9942-9b83ee307a12" alt="스크린샷 2024-01-01 오전 11.20.14.png"></p>
<p><img src="https://github.com/eomttt/eomttt-log/assets/22593217/8b300f6c-cf29-432b-8bd4-e8e2d32ece2a" alt="스크린샷 2024-01-01 오전 11.20.23.png"></p>
<h1>책</h1>
<p>책은 1년을 돌아보니 한달의 한권 정도 읽었다.</p>
<p>기억의 남은 책은 제로투원, 유난한 도전, 넷플릭스 - 규칙 없음, 훅 정도이다.</p>
<p>제로투원의 반 통념 질문은 고민을 많이 하게 한다.</p>
<p><code>정말 중요한 진실인데 남들이 당신한테 동의해주지 않는것은 무엇인가요?</code></p>
<p>과연 무엇이 있을까? 이것에 대한 통찰을 얻으면 상당히 많은 일들을 할 수 있을것 같다. 이 책에서 추가로 이와 비슷하게 알려주는 팩트니풀니스 라는 책도 있다. 세상은 우리가 알고 있는것과 많이 다르다. 라는 것을 알려주는 책인데, 초반에는 흥미로웠으나 갈 수록 비슷한 내용들을 이야기하는 방식이라 살짝 지루했다. 그러나 세상을 보는 관점을 다시금 일깨워주는 책이였다.</p>
<p>유난한 도전에서는 우리나라에도 대단한 기업이 나올 수 있겠구나 라는 재미있는 스토리였다. 토스 팀의 성장 스토리로서 스타트업을 좋아하는 나에게는 유난하게 가슴 떨리는 내용이였다.</p>
<p>넷플릭스 - 규칙 없음 책에서는 위대한 기업에 기업 문화를 옅볼 수 있었다. 인간에게 자율과 책임을 주었을 때 얼마나 성장 할 수 있는지 알 수 있는 책이였고, 그 뒤에 읽어 보았던 파타고니아 기업 문화 책도 이와 비슷했다.</p>
<p>훅 이 책은 정말 스타트업을 하게 되면 꼭 읽어봐야할 책이라고 생각이 든다. 사람들을 어떻게 끌어들이고, 이 사람들이 반복적으로 다시금 사용하게 하는 습관을 만드는 제품에 대하여 이야기하고 있다. 트리거 → 행동 → 보상 → 투자 로 이어지는 4가지 모델을 설명해서 사람들이 어떻게 이 제품을 습관 처럼 사용할 수 있을까? 하는 방법을 잘 알려주고 있다. 현재 있는 플렉스팀에서 사용 할 수 있는 방법인지는 잘 모르겠으나, 추후 창업을 하게 된다면, 꼭 다시 한번 읽어보고 고민하면서 제품을 만들어 가보고 싶다.</p>
<h1>일</h1>
<p>올 한 해 했던 일이 무엇인가를 돌아보았다.</p>
<p>시작은… 아직 플로우 스쿼드였다. 플로우 업무를 진행 했다. 문서 목록 디자인 개편을 진행했다. 기존에 문서가 열릴 때에  fx (flex 디자인 시스템) 모달이 열였었는데, 이를 사이드픽으로 열리도록 개선했다. 추가로 VOC 에서 문서가 너무 작다고 해서 큰 모달로 만들었던 기억이 난다.</p>
<p>사이드픽으로 만들면서 fx 에 기여 할 수 있도록 사이드픽을 좀 추상화 해서 만들었는데, 지금 시점에 사람들이 잘 쓰고 있어서 매우 기쁘다.</p>
<p>또한 모달 ↔ 사이드픽 ↔ 전체 모달 로 이어지는 인터페이스를 개발 했는데, 각 컴포넌트들이 독립적으로 동작할 수 있도록 만들고 뷰 전환 컨텍스트로 감싸면 뷰 전환이 될 수 있도록 레이어를 분리했는데, 그 당시에는 잘한 결정이라고 생각이 들었는데, 돌이켜 보니 뭔가 복잡도가 더 올라간 느낌이 든다.</p>
<p>뭔가 기록에는 없지만, 엔진 스쿼드로 옮기고 할 일을 개편했다. 기존 할 일을 사용할때에 VOC 들이 많이 있었다. 할 일을 보냈을 때 받은 사용자들이 완료를 하지 못하면 마음대로 할 일을 지우지도 못하고, 그저 남아있어야한다는 단점이 존재했다. 이는 많은 VOC 들로 이어졌고 할 일을 지워주세요 같은 요청 사항이 많았다.</p>
<p>뭔가 요즘 일을 하면서 사용자들이 아얘 하지 못하는 것은 큰 문제라고 생각한다.. 우리가 주는 방향이 아니더라도 다른 방향으로 라도 사용자들은 제품을 통해 하고 싶은 일을 마무리 할 수 있어야하는것 같다. 쉽게 예를 들어서 인스타그램 피드에 삭제기능이 없다고 가정을 해보면 사용자들을 불만이 많아질 것이다. 대신에 인스타그램에서는 피드 비공개 기능이 있다. 그럼 사람들은 삭제 대신에 비공개 기능을 사용해서 그들의 니즈를 충족 시킬것인데, 제품에 이정도의 대안은 있어야 한다는 이야기를 하고 싶었다.</p>
<p>플렉스의 할 일은 그런것들이 없었고, 결국 VOC 로 들어오고 결국 운영 이슈를 많이 쓰게 만들었다. 따라서 할 일을 개편하면서, 할 일의 상태를 만들었고, 상태를 통해 사용자들이 자신의 할 일 상태를 컨트롤 할 수 있게 만들었다.</p>
<p>할 일을 만들면서는 거의 다되었던 할 일에서 찜찜한 부분을 이야기해서 다시 처음 부터 만들었던 기억이 난다. 결국 거의 3~4개월을 할 일만 만들었다. 결과적으로 원하는 바를 달성하고 찜찜한 부분은 많이 없앴다.</p>
<p>플렉스는 여전히 진화하고 있고 빠르게 가고 있으며 어느 것이 제일 최선인지 늘 고민하고 만들고 있다. 이런점이 그 당시에는 힘들지만 돌아보면 매우 재미있던 지점이고, 아직은 흥미로운 지점인것 같다. 처음부터 잘 하려면 어떻게 해야할지 회고도 많이하고 이런 실수(?) 를 두번 다시 반복 안하기 보다는, 이런 일이 있을 때에 잘 대처하는것이 훨씬 현명한것 같다.</p>
<p>그 외에도 다양한 것들을 진행했다.</p>
<ul>
<li>체크리스트 개선 (이는 다시금 만들게 되었지만)</li>
<li>토픽 기반의 수신함 개선
<ul>
<li>알림을 좀 더 고도화 하고 싶어졌다.</li>
</ul>
</li>
<li>통합검색이 가능한 Spotlight 개선
<ul>
<li>빠른 검색을 좀 더 고도화 하고 싶어 졌다.</li>
<li>요즘에 Cmd+k 라고 일컫는 빠른 검색이 여러가지 소프트웨어 제품에 많이 보이는데 한번 잘 사용하면 끊을 수가 없다.</li>
<li>플렉스도 이러한 개선을 좀 더 해서 사용자들에게 더욱 편리한 기능을 주고 싶다.</li>
</ul>
</li>
<li>헬프센터 개발
<ul>
<li>기존에 찾기 힘든 도움말을 빠르게 찾을 수 있도록 만들었다.</li>
</ul>
</li>
<li>코어 제품의 설정 이관작업 도움
<ul>
<li>도움이 필요할 때에는 플렉스 팀 내에서 충분히 다른 스쿼드를 도와서 일을 진행 할 수도 있다.</li>
</ul>
</li>
<li>캘린더 개선
<ul>
<li>느렸던 캘린더를 빠르게 만들고, 디자인도 개편했다.</li>
<li>이때부터 동료가 생겼다.</li>
<li>조금 더 구글캘린더와 인터그레이션을 강화해서 플렉스 캘린더를 자주 쓸 수 있도록 하면 더 좋을것 같다.</li>
</ul>
</li>
</ul>
<p>은근 이것저것 많이 했고 지금은 승인 개선의 초점을 맞추고 있다.</p>
<p>8월 말 부터 지금 까지 승인 개편에 초점을 맞추고 있다. FE 보다는 BE 에 작업량이 훨씬 크고 많지만, FE 도 승인 컴포넌트를 새로 만들어야해서 만만치 않게 작업이 있었고, 현재는 크로스 스쿼드 이슈로 인해서 여러가지 커뮤니케이션 비용을 지불하면서 일을 진행하고 있다.</p>
<p>또한 그 전과는 다른 방식으로 마음 가짐을 가지고 있는데, 아무래도 공통 플랫폼 역할을 하는 팀에서 여러가지 모듈들을 제공하는 팀처럼 일하고 있으니, 유연하게 대응하는 방법, 미래를 내다 보는 방법 등을 고민하면서 만들어 가고 있다. 특히 이번년도에 꽂힌 말은 <strong>목표는 확실히 하면서 방법은 유연하게 가져간다</strong>는 말이 꽂혔는데, 이는 넷플릭스의 악동뮤지션 이찬혁씨가 낙화 뮤직비디오를 만들면서 여실히 보여주고 있다.</p>
<h1>운동</h1>
<p>여전히 몇해가 지나도 주짓수를 하고 있으며 앞으로도 큰 문제가 없다면 계속 할 예정이다.</p>
<p>추가로 웨이트를 좀 해야겠다는 니즈가 있고, 더운 여름날에는 웨이트를 하러 아침에 갔지만 요즘같은 겨울에는 도저히 엄두가 안난다. 주짓수 끝나고 한 30분 정도만 두가지 웨이트를 하고 집에가는 루틴을 좀 넣어야할것 같다.</p>
<p>아내와 같이 운동을 하려고 연초에 크로스핏을 대담하게 끊었지만, 골반 인대 쪽 이슈가 생겨서 나혼자 낙오 되었고, 아내는 <strong>여전히 열심히 아주 잘</strong> 하고 있다.</p>
<h1>목표</h1>
<p>2023 과 크게 바뀐 것은 없을것 같다.</p>
<pre><code>1. 여전히 둘보다는 셋을 원한다.
2. 하루 일과를 충실히 보내야한다.
    1. 아침에 일어나서 회사를 좀 일찍 가야겠다.
    2. 주짓수 + 웨이트를 하고 집에온다.
    3. 책을 읽고 일찍 잠에 든다.
3. 새로운 언어, 프레임워크를 배우는 일은 늘 재미있다.
    1. 사이드 프로젝트를 하나 해볼 때가 된것 같다.
    2. 노션에 적고 있는 todo + task 를 합친 무언가?
</code></pre>
<p>올 한해도 재미있게 사람들과 위대한 제품을 잘 만들어 가고 싶다. 스쿼드 내에서 일하는 방식도 고민을 많이하고 이야기도 많이 하고 있는데, 커뮤니케이션이 매우 중요한것 같고, 잘 만든 라이브러리 (특히 우리가 자주 쓰는 tanstack query, radix) 들이 어떻게 인터페이스를 만들고 고민하는지도 많이 찾아보면서 우리 스쿼드에서 만드는 여러가지 제품 또한 다른 사용자 (타 스쿼드) 사람들에게 유용한 가치를 제공하고 싶다.</p>
<p>또한 엔드유저에게는 일관된 사용성을 가진 제품을 주고싶은게 작은 소망이다.</p>


2023 을 돌아보며 2024

왜 플렉스팀인가? 일단 앞서 서론에서 말했던것 같이 제품 위주의 B2B SaaS 쪽을 가보고 싶었다. 그런 의미에서 플렉스팀은 정말 매력적인 제품을 만들고 있었고 조직 구성도 제품위주였다.

<h1>플렉스팀에서의 3개월...</h1>
<h1>이직</h1>
<p>사람들은 이직하는 이유가 다양하다. 쉽게 봐서 돈을 더 받고 싶어서, 같이 일하는 사람이 마음에 들지 않아서, 회사의 정책이 마음에 들지 않아서 등 다양한 이유가 있을것 같다.</p>
<p>이번에 내가 이직한 케이스는 조금 달랐다. 깊은 이야기 까지는 하지 못하겠지만 여러 어른들의 사정으로 회사가 분리 되었다 합병 되면서 살짝 이슈가 생기고 거기에 힘이 쫌 빠지면서 새로운 미래를 찾기 위해 떠나게 되었다.</p>
<p>이번에 이직하면서는 확실하게 두가지 노선을 정했다.</p>
<p>먼저 그동안 이커머스는 짧게, 컨텐츠 업계에는 대략 짧으면 짧다 할 수 있는 2년 정도 있었고 거기에서 오는 회의감이 조금 있었다.</p>
<p>나는 제품 개발자고 제품을 아무리 잘만들어도 좋은 컨텐츠, 좋은 상품을 가져오지 못하면 결국 회사가 성장 할 수 없다는 것이였다.</p>
<p>특히 마지막 회사에서 크게 느꼈는데 우리는 열심히 제품을 만들고 정말 빠르고, 새로운 기술을 도입해서 만들었지만 막상 고객들은 전혀 신경쓰지 않고 거기에 있는 컨텐츠 하나로 좌지우지 되는 모습을 보면서 회의감이 살짝 들었던것 같다.</p>
<p>따라서 정말 제품을 잘만들고 제품으로서 고객들을 설득시키는 분야를 찾고 싶었다.</p>
<p>그래서 찾았던 쪽이 바로 B2B SasS 를 만드는 회사들이였다.</p>
<p>두번째는 일단 스타트업 쪽에 오래 있었기도 했고 실제 창업을 해보기도 했기 때문에 이번에는 이와 완전 정반대에 있는 대기업을 다녀보고 싶었다.</p>
<h1>결론</h1>
<p>결론부터 말하자면 최종 합격 3군데 중에 플렉스 팀을 선택하였다.</p>
<p>왜 플렉스팀인가?</p>
<p>일단 앞서 서론에서 말했던것 같이 제품 위주의 B2B SaaS 쪽을 가보고 싶었다. 그런 의미에서 플렉스팀은 정말 매력적인 제품을 만들고 있었고 조직 구성도 제품위주였다.</p>
<p>실제로 조직 구성이 프로덕트 그룹 / 서포팅 그룹으로 나뉜다. 이런것만 보아도 프로덕트 위주로 돌아가고 있구나 라는 생각을 할 수 있다.</p>
<p>또한 그동안 해왔던 비즈니스와 달리 UI 자체가 복잡하고 쉽게 풀리는 제품이 아니다. 단적으로 큰 그림을 보면 사실 이커머스나 컨텐츠에 UI 는 목록/상세로 구분 할 수 있다. (위험한 발언 일 수도 있지만…저의 작은 생각임으로 이해 부탁드려요 ㅎㅎ)
대부분 아이템들이 목록에 있고 목록에서 아이템을 클릭하면 상세로 들어가는 구조가 많다. 하지만 FLEX 라는 제품은 그렇지 않다.</p>
<p>일단 HR 에서 다루는 도메인들이 그런식으로 풀기가 쉽지는 않다. 예를 들어 조직도, 근태관리, 휴가 승인, 전자결제 이러한것들이 목록/상세로 딱 구분 되지는 않기 때문이다.</p>
<p>마지막으로 메이커의 입장에서 제품을 정말 잘만들면 사람들이 제품의 매력을 느끼고 쓸 수 있을것 같았다. 이것은 처음 말한 것과 비슷한 맥락인데 사람들이 우리의 제품을 쓰는 이유는 딱 하나이다. 좋은 컨텐츠? 좋은 상품? 이것이 아니라 FLEX 를 사용하면 편하다, FLEX 를 사용하면 머리아픈 일들을 잘 해결 할 수 있다 이런 마음을 가지고 제품을 사용하기 때문에 우리가 잘만들면 정말 많은 사람들이 매력을 느끼고 사용하게 될것 같았다.</p>
<p>지금 대략 합류한지 3개월이 지난 시점에 글을 써보는데 플렉스팀을 선택한 후회는 전혀 없고 오히려 이런 팀에서 함께 할 수 있어서 고마울 따름이다.</p>
<p>대략 3개월 동안 느꼈던 플렉스팀은 예상했던것과 마찬가지로 제품의 욕심이 많은 사람들로 구성되어있었다. 실제로 대부분 사람들은 어떻게 하면 더 좋은 제품을 고객들에게 줄 수 있을까 고민하고 Killer use case 를 만들고 싶어했다.</p>
<p>또한 정보들이 상당히 투명하였다. 실제로 사람들이 많아지고 조직이 커지면 정보가 불투명 해지고 특히 특정 집단에만 정보가 공유되는 경우가 있는데 플렉스팀은 그러하지 않았다. 내부 100 이라는 원칙을 가지고 원한다면 언제든지 정보의 접근할 수 있었다.</p>
<p>성장하는 회사인 만큼 언제든지 나의 의견을 낼 수 있었다. 어떠한 틀이 있진 않고 아직 말랑말랑한 구조이면서 내가 욕심내서 하겠다고 하면 말리는 사람 하나 없었고 만약 벅차다면 언제든 도와주는 유능한 동료들이 주변에 있었다.</p>
<p>언제든 회사를 고르는 나만의 원칙이 있는데 <code>용의 꼬리</code> 가 되는 것이다. <code>용의 꼬리</code> 가 된다면 배울점이 너무 많고 그러한 점 때문에 재미있게 회사를 다닐 수 있기 때문이다. 그러한 점에서 플렉스팀은 나에게 있어서 충분이 <code>용의 꼬리</code> 가 될 수 있는 부분이 충분하였고 상당히 매력적으로 다가왔다.</p>
<p>그동안은 여러 스타트업들을 다니고 창업도 해보면서 작은 제네럴리스트같이 일을 했다면 여기에서 만큼은 유능한 동료들을 믿고 날카로운 스페셜리스트가 되고 싶다.</p>
<p>일단은 앞으로도 오랫동안 이 팀에서 1인분 이상을 해가며 함께 일하고픈 구성원이 되고싶은 마음뿐이다.</p>
<p>마지막으로 이런 매력적인 팀에 합류하고 싶으신 분들은 언제든 환영한다. (급하게 마무리한 경향이 있는데 일단 자야한다)</p>
<p><a href="https://career.flex.team/recruit">플렉스 팀</a></p>


플렉스팀에서의 3개월...

최근에 이직을 준비하면서 내가 했던 일들에 대하여 정리해보고 예상 질문도 스스로 해보고 하는 시간을 가졌었다. 결론부터 말하자면 이직에 성공 하였고 요즘 뜨고 있는 B2B 서비스를 하는 회사로 결정 하게 되었다.

<h1>이직</h1>
<p>최근에 이직을 준비하면서 내가 했던 일들에 대하여 정리해보고 예상 질문도 스스로 해보고 하는 시간을 가졌었다. 결론부터 말하자면 이직에 성공 하였고 요즘 뜨고 있는 B2B 서비스를 하는 회사로 결정 하게 되었다.</p>
<p>먼저 프로덕트가 마음에 들었고, 테크 면접, 동료 면접, 대표님 면접 3가지를 진행 하게 되었는데 각 면접 마다 특별히 불편하다는 점이 없었고 면접 보다는 내가 했던 일에 대하여 토론하고 앞으로 이 개발 또는 일하는 방법, 회사에 대하여 어떻게 생각하는지 핏을 맞춰 보는 자리라고 해두는 것이 더 바람직해 보였다.</p>
<p>특히 이 회사는 아직 베일에 쌓여져 있어서 정보들이 없었는데 개발자인 만큼 프로덕트 위주에 사업, 조직 역시 프로덕트 위주로 조직이 구성된 점이 매력적으로 느껴졌고 프로덕트 위주인 곳에서 개발자가 프로덕트를 만들려면 어떻게 해야하고 많은 노력들이 필요한가에 대하여 궁금하기도 했고 약간 설레기도 해서 결정을 하게 되었다. (간만에 사업했던 열정이 불타오르는...)</p>
<p>무튼 서론이 길었지만 면접을 준비하는데 가장 어려운 점은 내가 알고 있는 것을 얼마나 정리하냐였다. 물론 알고 있는 개념인데 무언가 뜬구름 처럼 내 머리속을 해짚고 다니는데 정확하게 정리가 안되면서 면접에서 대답 못한 것들도 분명 있었기 때문이다.</p>
<p>먼저 나는 기본적으로 3가지 방법으로 내가 아는 분야에 대하여 정리하고 기록한다.</p>
<ol>
<li>블로그</li>
<li><a href="https://github.com/eomttt/read-contents">github read-contents</a></li>
<li><a href="https://github.com/eomttt/tip-til">github tip-til</a></li>
</ol>
<h1>기록</h1>
<h2>1. 블로그</h2>
<p>당연하게도 velog 외에는 쓰지 않고, 기본적으로 진행한 토이프로젝트나 사실 회사에 들어가면 회사에 기술 스택을 미니멀하게 따라서 구성해보기도 하는데 그런것들을 기록해본다.
하지만 블로그다 보니 써야할 내용도 많고 정리해야할 내용도 많아서 사실 쫌 습관적으로 쓰기란 힘들다.</p>
<h2>2. github read-contents</h2>
<blockquote>
<p><a href="https://github.com/eomttt/read-contents">github read-contents</a></p>
</blockquote>
<p>여러가지 뉴스레터 또는 카톡방, 슬랙 등 다양하게 인사이트를 얻으려고 노력하고, 인사이트를 얻는 부분에 대해서는 github 에 짤막한 요약과 함께 기록한다.
월별로 기록하고 기록하다가 조금 감명 깊거나 오래보고 싶은 내용이 있으면 README 로 올리게 된다.</p>
<h2>3. github tip-til</h2>
<blockquote>
<p><a href="https://github.com/eomttt/tip-til">github tip-til</a></p>
</blockquote>
<p>이부분은 어디에 쓰기도 애매하고 짤막하게 개발하다가 얻은 지식들을 기록하기 위함인데, 어디선가 보고 나도 해봐야 겠다 싶어서 따라서 해보고 있다.
뭐 나름 괜찮고 정리도 잘 되어가는듯 하다.</p>
<h1>문제</h1>
<p>그런데 위와 같이 3가지를 진행 하다보면 여러가지 문제들이 생긴다.
content 를 읽다가 엇 이게 뭐지? 하는 부분이 나오면 찾아 본 다음에 tip-til 에 기록 하기도 하는데 아 그런거구나 하면서 넘어가는 부분도 있다. 그럼 기억속에 잊혀지고 나중에 다시 찾기가 어려워진다.</p>
<p>또한 개발하다가 모르는 개념들이 나오면 기록은 하지만 개발 특성상 연관된 개념들이 있다. 이런것들 까지 따로 기록 하다보면 정보가 너무 산발적이라 내 머리속에 정리가 안되는 경향이 있다.</p>
<p>이렇게 정리가 되지 않은 문제들은 나중에 면접을 보거나 대화를 할때 자신감 있게 나오지 못하게 되고 개발을 할때에도 나에 온전한 지식이 아니기 때문에 바로 사용할 수 가 없다 (흔히 말하는 LTM 에 저장 되어있지 않기 때문에 바로 적용 할 수 없다)</p>
<p>또 책도 읽게 되는데 그럼 책을 읽고 나면 어디다가 정리해야하지? 이런 생각이 들기도 한다. 지금은 노션을 이용하고 있긴 하지만 사실 공개된 부분은 아니기 때문에 적진 않았다.</p>
<p>그러다가 우연하게 같이 일했던 팀 동료에게 <code>제텔카스텐</code> 이라는 것을 알게 되었다.
내가 정말 원하고 찾던 것이였다. 그래서 이 <code>제텔카스텐</code> 을 간략하게 소개해보려고 한다.</p>
<h1>해결</h1>
<p>모든 문제가 그렇듯 만능 해결책은 없다.</p>
<p>하지만 <code>제텔카스텐</code> 은 개발자에게 정말 많은 도움이 되는 메모 방법론? 정도라고 할 수 있겠다.</p>
<p>먼저 <code>제텔카스텐</code> 에 대한 배경 지식은 따로 정리하지 않겠다.
<a href="http://www.yes24.com/Product/Goods/99475214">제텔카스텐</a> 이라는 책도 있고 검색해보면 수많은 블로그글들 있다.</p>
<p>물론 글을 쓰기 위한 메모 방법론이라고 하지만 어차피 개발자들도 글을 쓰는 사람이고 대부분의 사람들이 글을 쓴다. (흔히 말하는 일기라고도 할지라도...)</p>
<p>하지만 일단은 글을 쓰기 위해서는 상당한 정리가 필요한데 이 정리 부분을 잘 이야기해주고 있고 이 정리부분이 개발과 정말 잘 맞는다 라는 생각이 들어서 한번 해보는 중이다. (역시 개발자인 만큼 똥인지 된장인지 먹어봐야 적성에 풀린다)</p>
<p>간략하게 방법을 설명해 보겠다. (물론 나만의 방법이 살짝 섞여있다)</p>
<blockquote>
<ol>
<li>책을 읽거나 다양한 곳에서 얻는 지식에서 필요한 부분은 <code>임시 메모</code> 에 메모한다.</li>
</ol>
</blockquote>
<ol start="2">
<li>2 ~ 3 일 내외에 이 <code>임시 메모</code> 를 바탕으로 <code>영구 보관용 메모</code> 를 작성해야한다.</li>
<li><code>영구 보관용 메모</code> 는 <strong>반드시</strong> 나의 글로 작성해야하고 단순히 글을 복사하거나 해서는 안되고 나의 생각과 나의 의견으로 한 문단이 되도록 작성해야한다.</li>
<li><code>영구 보관용 메모</code> 를 작성하고 나면 기존에 있던 <code>영구 보관용 메모</code> 와 관련되어있는 메모이면 이 메모들을 <strong>연결</strong> 시켜준다.</li>
</ol>
<p>여기서 핵심은 <strong>나의 글</strong> 과 <strong>연결</strong> 이다.</p>
<p>일단 <strong>나의 글</strong> 이란 단순히 어떤 내용을 보고 옮겨 적는것이 아니라 이 주제가 어떤 의미를 가지고 있지? 이 주제가 어떤 부분과 연관 되어있지? 라고 생각을 하면서 나의 글로 적는 것이다. 책에서도 어떤 강의를 들을때 메모하는 방법에서 타이핑과 글쓰기를 예로 들고 있는데 두가지 방법다 단기적인 이해도에는 차이가 없지만 나중에 기억속에 오래 남는건 글쓰기라고 이야기하고 있다.</p>
<p>그 이유는 단순히 글을 써서가 아니라 타이핑은 속도가 빠르기 때문에 강의의 내용을 온전히 다 받아 적을 수 있지만 단순히 그 역할 만 할 뿐이고, 손으로 글을 쓰게 되면 아무래도 나의 의견, 나의 생각이 들어가기 때문에 그 글이 온전히 나의 것이 될 확률이 높아지기 때문이라고 이야기하고 있다.</p>
<p>이 이야기에 많이 공감을 하였고, 그동안 나또한 어떤 개념에 대하여 검색하여 찾아내면 단순히 복붙을 통해서 기록을 한 경험이 많았다. 물론 <code>임시 메모</code> 를 작성 할때에는 그래도 되지만 <code>영구 보관용 메모</code> 를 작성 할 때에는 <strong>나의 글</strong> 로 작성하는 것이 핵심이다</p>
<p>두번째 핵심은 <strong>연결</strong> 이다. 어떤 특정한 주제에 관해서 <strong>나의 글</strong> 로 작성 했다면 이 글이 기존에 작성된 글과 어떤 연관성이 있을까를 고민 한 후에 <strong>연결</strong> 시켜야 한다고 한다.
즉, <strong>연결</strong> 이 되면 어떤 개념에 대하여 다시 찾을때 그와 연관된 여러가지 개념들을 볼 수 있게 되고, 이를 통하여 새로운 사고? 또는 잘못 기록된 메모들을 수정 할 수 있는 기회가 된다고 한다.</p>
<p>특히, 이 <strong>연결</strong> 이라는 부분에 대하여 고민을 좀 하고 있었다. 실제로 <a href="https://github.com/eomttt/tip-til">github tip-til</a> 여기서는 tag 를 통하여 비슷한 개념들 끼리 묶고 있었는데 실제 연결을 하면 더 보기 편하고 개념을 쉽게 찾아갈 수 있을거란 생각이 든다.</p>
<p>마지막으로 이건 온전히 개인적인 생각인데 어떠한 지식이 온전히 나의 것이 되려면 적당한 시간을 두고 반복해야 한다고 한다. 그런데 이 제텔카스텐은 <code>임시 메모</code> 를 통하여 빠르게 내용을 메모하고 <code>영구 보관용 메모</code> 를 작성 할 때 또 그에 대한 개념을 다시한번 보게 되고 이 메모들을 <strong>연결</strong> 시키려고 할 때에 또 그와 연관된 메모를 찾기 위해 메모들을 다시 보게 되니 엄청난 반복이 반복되고 있는 셈이라고 생각한다. 그렇게 되면 기억도 오래 남을 거라고 감히 예상해 본다.</p>
<p>실제로 나는 <code>임시 메모</code>는 관리하기 편하고 사용하기 쉬운 <code>노션</code>을 이용하고 있고 <code>영구 보관용 메모</code>는 이번에 알게된 <code>옵시디언</code>을 이용하고 있다.
<img src="https://velog.velcdn.com/images/eomttt/post/bb540491-1da0-4955-818f-d67ac8315a82/image.png" alt="">
<code>옵시디언</code>에 장점은 다음과 같이 시각적으로 <strong>연결</strong>을 볼 수 있다는 것이다.
<img src="https://velog.velcdn.com/images/eomttt/post/6fdfea50-c39b-4bdd-aff2-c956d4b9fef8/image.png" alt=""></p>
<p>실제로 <code>제텔카스텐</code> 을 만든 루만 교수는 이러한 툴들이 없었기 때문에 각 메모마다 인덱스를 부여하여 <strong>연결</strong>을 시켰다고 하는데 우리는 너무 많은 툴들을 사용할 수 있기 때문에 루만 교수 보다는 좋은 환경에 처했다고 생각한다.</p>
<p>단지 우리가 할것은 <strong>실행</strong> 일 뿐이다.</p>
<p>이런식으로 내가 어떠한 개념에 대하여 온전히 생각하고 연결 짓는 다면 나중에 큰 자산이 될거라고 생각하고 책에서는 <strong>두번째 뇌</strong> 라고 표현하고 있다.</p>
<p>물론 기억은 휘발성이지만 최대한 오랫동안 기억속에 남겨 놓아야 개발을 할 때에 쉽게 꺼내쓸 수 있고, 이런 기억들을 바탕으로 다양한 인사이트를 얻을 수 도 있을거라고 생각한다.</p>
<p>그렇기 때문에 단순히 내가 보고 기억해야할 것들을 기록하기 보다는 이 방법론을 한동안 써보려고 한다.</p>


개발자의 이직, 기록 그리고 글쓰기 - 부제(제텔카스텐)

요즘 여러군데에서 `react-query` 를 많이 사용하고 있는듯 하다. 나 또한 `react-query` 를 계속 사용해 왔고 `react-native`, `NextJS` 에서 많이 사용했었다. 그러다가 문득 `Next JS` 에서 SSR 시에 `react-query` 가 어떻게 동작하는지 궁금증을 가지게 되었다.

<p>요즘 여러군데에서 <code>react-query</code> 를 많이 사용하고 있는듯 하다.
나 또한 <code>react-query</code> 를 계속 사용해 왔고 <code>react-native</code>, <code>NextJS</code> 에서 많이 사용했었다.
그러다가 문득 <code>Next JS</code> 에서 SSR 시에 <code>react-query</code> 가 어떻게 동작하는지 궁금증을 가지게 되었다.</p>
<p><a href="https://react-query-v2.tanstack.com/guides/ssr#using-nextjs">Using NextJS</a> 에서 보면 <code>NextJS</code> 에서 크게 2가지 방법으로 SSR 에서 사용할 수 있는것으로 보인다.</p>
<h1>React Query 에서 NextJS SSR</h1>
<h2>1. Using <code>initialData</code></h2>
<p>내용 그대로 <code>getStaticProps</code> 나 <code>getServerSideProps</code> 에서 원하는 API 를 요청하고 그에 대한 응답을 <code>page</code> 에 <code>props</code> 로 내려주고 그 값을 <code>react-query</code> 에 <code>initialData</code> 로 넣어주는 방법이다.
이 방식은 간단하지만 만약 중첩된 컴포넌트에서 <code>react-query</code> 를 사용하고 있다면 그 컴포넌트 까지 props drilling 해주어야하고, 또한 같은 응답을 원하는 query 가 여러개인 경우 다 넣어줘야한다.
그래서 간단하지만 여러가지 문제들이 존재한다.
따라서 <code>react-query</code> 에서도 두번째 방법을 추천한다.</p>
<h2>2. Using <code>hydrate</code></h2>
<p><code>hydrate</code> 방식인데 동일하게 <code>getStaticProps</code> 나 <code>getServerSideProps</code> 여기에서 <code>prefetch</code> 를 통해 데이터를 요청한뒤 <code>queryClient</code> 를 <code>dehydrate</code> 하여 <code>page</code> 에 <code>props</code> 에 <code>dehydratedState</code> 로 내려주면 끝이다.</p>
<pre><code> // pages/posts.jsx
 import { dehydrate, QueryClient, useQuery } from 'react-query';
 
 export async function getStaticProps() {
   const queryClient = new QueryClient()
 
   await queryClient.prefetchQuery('posts', getPosts)
 
   return {
     props: {
       dehydratedState: dehydrate(queryClient),
     },
   }
 }
 
 function Posts() {
   // This useQuery could just as well happen in some deeper child to
   // the "Posts"-page, data will be available immediately either way
   const { data } = useQuery('posts', getPosts)
 
   // This query was not prefetched on the server and will not start
   // fetching until on the client, both patterns are fine to mix
   const { data: otherData } = useQuery('posts-2', getPosts)
 
   // ...
 }
</code></pre>
<p>대신 <code>_app.js</code> 에서 설정이 조금 필요한데 다음과 같다.</p>
<pre><code> // _app.jsx
 import { Hydrate, QueryClient, QueryClientProvider } from 'react-query'
 
 export default function MyApp({ Component, pageProps }) {
   const [queryClient] = React.useState(() => new QueryClient())
 
   return (
     &#x3C;QueryClientProvider client={queryClient}>
       &#x3C;Hydrate state={pageProps.dehydratedState}>
         &#x3C;Component {...pageProps} />
       &#x3C;/Hydrate>
     &#x3C;/QueryClientProvider>
   )
 }
</code></pre>
<p>위와 같이 설정하면 중첩된 컴포넌트에서도 <code>prefetch</code> 했던 query key 와 같은 query key 로 <code>useQuery</code> 하고 있다면 서버사이드 렌더링 시에 데이터를 유지한다.
위의 예제에서 보면 <code>posts</code> 가 같은 query key 로 사용된것을 볼 수 있다.
자세한 내용은 <a href="https://react-query-v2.tanstack.com/guides/ssr#using-hydration">Using hydrate</a> 에서 확인 하면 된다.</p>
<h1>궁금증</h1>
<h2>Hydrate 란</h2>
<p>대략적으로 다음과 같이 2가지 방법인데, 이것이 어떻게 동작하는지 궁금해졌다.
먼저 이에 대하여 알아보려면 <code>hydrate</code> 라는 것에 대한 지식이 필요하다.
<code>hydrate</code> 란 간단하게 말하면 다음과 같다. (사실 <code>NextJS</code> 개념은 아니고 <code>React</code> 개념이다)</p>
<blockquote>
<p>DOM 요소에 자바스크립트 속성을 매칭 시키기 위한 목적</p>
</blockquote>
<p>즉, <code>NextJS</code> 에서는 서버사이드에서 pre rendering 한 html 파일들을 서버사이드 렌더링 형식으로 해서 보내주고, 클라이언트사이드에서 React 코드를 통해 <code>hydrate</code> 진행한다.
또한 <code>hydrate</code> 를 진행해도 단순히 DOM 에 JS 속성을 매칭시키는 일이라서 paint 가 다시 일어나진 않는다.
서버사이드에서 내려주는 HTML은 자바스크립트 이벤트 리스너들이 붙어있지 않은데, Hydrate 단계에서 이런 부분들을 다시 붙여주게된다.</p>
<blockquote>
<p><a href="https://narup.tistory.com/230">[Next.js] Hydrate란?</a></p>
</blockquote>
<h2>그래서...?</h2>
<p>그래서 최종적으로 <code>react-query</code> 가 위와같은 상황에 대하여 어떻게 동작하는지 궁금해서 알아보고 기록을 남기기 위하여 글을 쓴것이다. (이글의 목적!)</p>
<ol>
<li>뭔가 <code>NextJS</code> 가 pre rendering 한 html 파일을 넘겨주고 클라이언트에서 <code>hydrate</code> 하는 것은 이해가 되었는데 어떠헥 서버사이드 렌더링 시에 prefetch 된 데이터를 바탕으로 그려줄까 하는것이 궁금했다.</li>
<li>또한 만약 내가 prefetch 후에 <code>dehydrate</code> 를 안해주면 서버사이드 렌더링 시에는 prefetch 때문에 쿼리가 캐싱되어서 데이터를 넘겨주고, 클라이언트에서 <code>hydrate</code> 할 시에는 <code>dehydrate</code> 된것이 없기 때문에 클라이언트에서 <code>hydrate</code> 시 서버사이드에서 pre rendering 한 html 구조가 달라서 <code>다음과 같은 에러</code>가 생기지 않을까?</li>
</ol>
<blockquote>
<p><a href="https://fourwingsy.medium.com/next-js-hydration-%EC%8A%A4%ED%83%80%EC%9D%BC-%EC%9D%B4%EC%8A%88-%ED%94%BC%ED%95%B4%EA%B0%80%EA%B8%B0-988ce0d939e7">다음과 같은 에러</a> -> NextJS 에서 서버사이드렌더링 한 html 과 hydrate 하는 과정에서 만들어낸 html 과 구조가 다르면 에러가 발생한다.</p>
</blockquote>
<p>하지만 2번은 완전 내 생각과 달랐다. prefetch 후에 <code>queryClient</code> 를 <code>dehydrate</code> 하지 않고 <code>dehydratedState</code> 로 <code>props</code> 를 넘겨주지 않으면 서버사이드에서 pre rendering 했을 시에도 <code>useQuery</code> 에 <code>data</code> 가 존재하지 않았고 클라이언트에서 <code>hydrate</code> 진행 할때에도 구조가 달라지지 않아 에러가 나진 않았다.</p>
<p>먼저 <code>queryClient</code> 를 <code>dehydrate</code> 하면 다음과 같다. 실제로 보면 단순 serialize 한것이다.</p>
<ul>
<li><code>dehydrate</code> 된 <code>queryClient</code></li>
</ul>
<pre><code>{
  mutations: [],
  queries: [
      { state: [Object], queryKey: [Array], queryHash: '["user"]' },
      { state: [Object], queryKey: [Array], queryHash: '["event",1]' }
    ]
}
</code></pre>
<p>그래서 코드를 뒤져보기로 했다!</p>
<h3>1. useQuery</h3>
<pre><code>// useQuery.js
function useQuery(arg1, arg2, arg3) {
  var parsedOptions = (0, _utils.parseQueryArgs)(arg1, arg2, arg3);
  return (0, _useBaseQuery.useBaseQuery)(parsedOptions, _core.QueryObserver);
}
</code></pre>
<p><code>useQuery</code> 를 보면 <code>useBaseQuery</code> 를 통해서 동작을 한다. 따라서 <code>useBaseQuery</code> 를 보았는데, 크게 SSR 이나 hydrate 같은건 찾아 볼 수 없었다. 대신에 <code>result</code> 란 값을 return 하는데 그 값에 쿼리에 대한 return 값들이 들어있었다.
그래서 <code>result</code> 가 어떻게 초기화 되는지 찾아보았는데 <code>observer</code> 란 친구였다.</p>
<pre><code>// useBaseQuery.js
var _React$useState2 = _react.default.useState(function () {
  return new Observer(queryClient, defaultedOptions);
}),
    observer = _React$useState2[0];

var result = observer.getOptimisticResult(defaultedOptions);
</code></pre>
<h3>2. observer - QueryObserver</h3>
<p>그래서 다시 <code>useQuery</code> 함수로 돌아가면 <code>_core.QueryObserver</code> 란 친구를 넣어주는것을 볼 수 있다.
그래서 <code>QueryObserver</code> 란 파일을 보면 다음과 같은 메소드를 발견 할 수 있는데, 여기서 <code>this.client</code> 는 위에 서 <code>queryClient</code> 이다.</p>
<pre><code>// queryObserver.js
_proto.getOptimisticResult = function getOptimisticResult(options) {
  var defaultedOptions = this.client.defaultQueryObserverOptions(options);
  var query = this.client.getQueryCache().build(this.client, defaultedOptions);
  return this.createResult(query, defaultedOptions);
};
</code></pre>
<p><code>createResult</code> 를 먼저 확인해봤는데 단순히 <code>hydrate</code> 나 SSR 관련된 로직은 전혀 없었고 옵션과 query 만 비교하여 결과를 반환하고 있었고, 딱히 큰 옵션이 없는 이상 그저 받아온 <code>query</code> 데이터를 반환하고 있었다.
여기서 <code>state</code> 는 <code>query.state</code> 이고 <code>query</code> 는 위에서 <code>createResult(query)</code> 에 <code>query</code> 였다.</p>
<pre><code>// queryObserver.js
// Use query data
data = state.data;
</code></pre>
<p>즉, <code>queryClient</code> 에서 <code>getQueryCache()</code> 를 통해 <code>query</code> 데이터를 가져오고 이를 통하여 데이터를 반환하는것 같았다.</p>
<h3>3. queryClient</h3>
<p>그래서 <code>queryClient</code> 파일에 <code>getQueryCache</code> 를 보니 단순히 <code>queryCashe</code> 를 return 하는 메소드였다.</p>
<pre><code>// queryClient.js
_proto.getQueryCache = function getQueryCache() {
  return this.queryCache;
};
</code></pre>
<h3>4. queryCashe</h3>
<p>그 다음 <code>queryCashe</code> 를 찾아보았는데, 여기서 눈에 띄는 점이 있었다.</p>
<pre><code>// queryCashe.js
_proto.build = function build(client, options, state) {
  var _options$queryHash;

  var queryKey = options.queryKey;
  var queryHash = (_options$queryHash = options.queryHash) != null ? _options$queryHash : (0, _utils.hashQueryKeyByOptions)(queryKey, options);
  var query = this.get(queryHash);

  if (!query) {
    query = new _query.Query({
      cache: this,
      queryKey: queryKey,
      queryHash: queryHash,
      options: client.defaultQueryOptions(options),
      state: state,
      defaultOptions: client.getQueryDefaults(queryKey),
      meta: options.meta
    });
    this.add(query);
  }

  return query;
};
</code></pre>
<p>바로 <code>state</code> 를 넣어주는 것이였다. 이 <code>state</code> 를 언제 넣어주느냐에 따라서 <code>queryCashe</code> 에 대한 값을 셋 해주고 이에 대한 값을 반환하는것 같았다.
하지만, 단순히 <code>useQuery</code> 에서는 <code>state</code> 를 넣어주지 않고 있었다.</p>
<pre><code>// queryObserver.js
var query = this.client.getQueryCache().build(this.client, defaultedOptions);
</code></pre>
<p>그래서 언제 이에대한 값 (<code>state</code>) 를 찾던 와중에 <code>hydrate</code> 시에 값을 넣어주는것을 확인 할 수 있었다.</p>
<h3>5. hydrate</h3>
<p>다음 코드는 <code>react</code> 에서 <code>&#x3C;Hydrate state={dehydrateState}></code> 에 사용되는 코드인데 다음과 같이 <code>dehydrateState</code> 를 <code>state</code> <code>props</code> 로 넣어주면 <code>_core.hydrate</code> 함수를 호출 하는것을 볼 수 있다.</p>
<pre><code>// Hydrate.js
function useHydrate(state, options) {
  var queryClient = (0, _QueryClientProvider.useQueryClient)();

  var optionsRef = _react.default.useRef(options);

  optionsRef.current = options; // Running hydrate again with the same queries is safe,
  // it wont overwrite or initialize existing queries,
  // relying on useMemo here is only a performance optimization.
  // hydrate can and should be run *during* render here for SSR to work properly

  _react.default.useMemo(function () {
    if (state) {
      (0, _core.hydrate)(queryClient, state, optionsRef.current);
    }
  }, [queryClient, state]);
}

var Hydrate = function Hydrate(_ref) {
  var children = _ref.children,
      options = _ref.options,
      state = _ref.state;
  useHydrate(state, options);
  return children;
};

</code></pre>
<p><code>_core.hydrate</code> 함수 중 일부인데 여기서 보면 <code>var queries = dehydratedState.queries || [];</code> 를 확인 할 수 있는데 이것은 맨처음 <code>queryClient</code> 를 <code>dehydrate</code> 한 값이랑 동일 했다.</p>
<pre><code>// hydration.js
var queries = dehydratedState.queries || [];
queries.forEach(function (dehydratedQuery) {
  var _options$defaultOptio2;

  var query = queryCache.get(dehydratedQuery.queryHash); // Do not hydrate if an existing query exists with newer data

  if (query) {
    if (query.state.dataUpdatedAt &#x3C; dehydratedQuery.state.dataUpdatedAt) {
      query.setState(dehydratedQuery.state);
    }

    return;
  } // Restore query


  queryCache.build(client, (0, _extends2.default)({}, options == null ? void 0 : (_options$defaultOptio2 = options.defaultOptions) == null ? void 0 : _options$defaultOptio2.queries, {
    queryKey: dehydratedQuery.queryKey,
    queryHash: dehydratedQuery.queryHash
  }), dehydratedQuery.state);
});
</code></pre>
<ul>
<li><code>dehydrate</code> 된 <code>queryClient</code></li>
</ul>
<pre><code>{
  mutations: [],
  queries: [
      { state: [Object], queryKey: [Array], queryHash: '["user"]' },
      { state: [Object], queryKey: [Array], queryHash: '["event",1]' }
    ]
}
</code></pre>
<p>그렇기 때문에 무조건 <code>getServerSideProps</code> 나 <code>getStaticProps</code> 에서 <code>queryClient</code> 를 <code>dehydrate</code> 시킨 다음 <code>dehydratedState</code> <code>props</code> 로 값을 넘겨주어야지 <code>queryCashe</code> 에 세팅이 되고 서버사이드 렌더링시 <code>useQuery</code> 를 만나면 캐싱된 값을 반환해서 그려주는것을 확인 할 수 있었다.
또한 클라이언트에서 <code>hydrate</code> 시에도 <code>dehydrate</code> 된 <code>query</code> 를 찾아서 각각 <code>hydrate</code> 시켜주는것을 알 수 있었다.</p>
<h1>결론</h1>
<p>결론적으로 정리하자면 스텝은 다음과 같다.</p>
<ol>
<li>prefetch 해서 queryClient 를 dehydrate 함</li>
<li>서버사이드 렌더링시 prefetch 할 때와 같은 key 를 가지는 query 를 만나면 캐싱된 데이터를 반환하고 이에 따라 렌더링을 진행함</li>
<li>서버사이드 렌더링을 진행한 html 파일을 클라이언트로 보내줌</li>
<li>클라이언트에서 hydrate 진행시 queryClient 에서 dehydrate 했던 데이터를 바탕으로 hydrate 함</li>
</ol>
<p>이렇게 한가지 의문점을 가지고 라이브러리를 따라가면서 보다 보니 조금 더 이친구와 친숙해지는 느낌이였고 react query 동작방식에 대략 느낌만 가지고 있었을 때 보단 조금 더 논리적으로 이해할 수 있게 되었다.<img src="https://velog.velcdn.com/images/eomttt/post/bb0fb66c-963b-4346-b92a-b0be705f6863/image.png" alt=""></p>


React Query 와 SSR - React Query 라이브러리 코드보며 이해하기

3/16 일에 새로운 회사인 RIDI에 입사하게 되었다. 새로운 환경에 적응하는 일은 늘 어려운 일이다. 특히 나 같은 경우는 먼저 다가가서 친해지는 성격도 아니고 은근히 내성적이기 때문에 약간 새로운 환경을 두려워하기도 한다. 무튼 그러나 회사는 회사기 때문에 최대한 빠르게 적응하여 1인분을 하고싶은게 현재 마음이다.

<h1>들어가며...</h1>
<p>3/16 일에 새로운 회사인 RIDI에 입사하게 되었다.
새로운 환경에 적응하는 일은 늘 어려운 일이다. 특히 나 같은 경우는 먼저 다가가서 친해지는 성격도 아니고 은근히 내성적이기 때문에 약간 새로운 환경을 두려워하기도 한다.
무튼 그러나 회사는 회사기 때문에 최대한 빠르게 적응하여 1인분을 하고싶은게 현재 마음이다.</p>
<p><img src="https://images.velog.io/images/eomttt/post/0570a6eb-31f2-4c63-a951-b8fe3662737b/ridi_logo.png" alt=""></p>
<p>RIDI 에 입사하게 되면 팀바이 팀에 따라 다르겠지만, 내가 속한 팀에서는 입사자 과제를 내주었다. 전자책 파일을 가지고 만드는 간단한 웹뷰어이다.
말이 간단하지 살면서 전자책을 다뤄보지 못한 나에게는 정말 막막했다.
그렇게 대략적으로 전자책에 대한 설명을 보고, @ridi/epub-parser 를 연구해보면서 개발을 시작하였다.</p>
<ul>
<li><a href="http://www.tta.or.kr/data/androReport/ttaJnal/136-6.pdf">epub 이란</a></li>
<li><a href="https://github.com/ridi/content-parser/tree/master/packages/epub-parser">@ridi/epub-parser</a></li>
</ul>
<p>일단 프로젝트 스펙은 그 전 회사에서 다루었던 Next 기반으로 구성하기로 하였다.</p>
<pre><code>- TypeScript
- Next JS
- Express JS
- Styled-component
- Redux
- GraphQL
- React Apollo
</code></pre>
<p>요 정도가 내가 미니뷰어 프로젝트에 사용한 스펙이다.</p>
<p>일단 프로젝트를 진행해나가면서 고민하고 생각했던 점은 다음과 같다.</p>
<h1>고민...</h1>
<h2><strong>1. epub파일은 도데체 무엇이고 어떻게 다루어야하나?</strong></h2>
<p>질문에 대한 대답은 생각보다 간단하였다. epub 파일은 전자책 파일이라고 이해하면 쉽다. 출판사에서 전자책을 만들 수 있게 책에 필요한 정보들을 코드화 해서 만든 파일이라고 생각하면된다.
따라서 <a href="https://github.com/ridi/content-parser/tree/master/packages/epub-parser">@ridi/epub-parser</a> 바탕으로 epub 파일을 압축을 해제하고, read 를 하게 되면 spine이라고 불리우는 책의 각 챕터? (html 형식으로 되어있다), ncx 라고 불리우는 목차정보, title, author, description, meta 정보 등 epub을 바탕으로 전자책을 그릴 수 있는 다양한 정보드를 가져올 수 있게 된다. 이를 바탕으로 단순히 viewer를 그리기만 하면된다.</p>
<h2><strong>2. 책 넘김 효과는 어떻게 해야하나?</strong></h2>
<p>두번째 질문이 생각보다 많은 고민을 하게 되었다. 결국 epub파일을 read 해서 spine 쭉 나열하면 되지만 당연하게도 세로로 나열이 된다. 하지만 책은 가로로 넘기는게 일반적이다.
그래서 사용한게 column-width 속성을 사용하였다. 책이 보여지는 큰 틀을 만들고 거기에 width 를 바탕으로 각각 spine에 column-width 속성을 먹였다. 그렇게 되면 가로로 쭉 정렬이 되고 전체 스크롤 / column-width 하여서 한 spine이 몇개의 page 로 나오는지 계산하여 사용하게 되었다.
<img src="https://images.velog.io/images/eomttt/post/012efc1a-c963-4ff5-ab86-ef4066056825/paging-1.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/123ed285-7727-4d74-bf09-0048ef2c9e14/paging-2.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/b186c585-5f3a-4f94-bfa4-b70a487b5d1c/paging-3.png" alt="">
위와 같이 한 뒤 scrollLeft 속성을 이용하여 스크롤이 이동하는 방식으로 구현하게 되었다.</p>
<h2><strong>3. pageCount 계산</strong></h2>
<p>viewer 에서 현재 page를 변경할 수 있는 방법은 총 3가지라고 생각이 들었다.</p>
<ol>
<li>좌/우 버튼 클릭</li>
<li>목차정보를 바탕으로 page 이동</li>
<li>slider 를 가지고 이동
이를 이용하여서 pageCount속성을 store에 저장해놓고 pageCount 변경시 각각의 현재 보여지는 spine index, spine position 을 변경하여서, 스크롤을 이동시키는 방식으로 구조를 잡고 진행하였다.</li>
</ol>
<blockquote>
<ul>
<li>spine position: column-width 속성을 사용하여 나누어진 spine에 pagination이라고 하면 좋을것 같다. 위에 그림에서 spine_1 이 두개의 나뉘었는데 첫째 spine_1을 보고있으면 position을 0, 두번째 spine_1을 보고있으면 position을 1 이라고 명명하였다.</li>
</ul>
</blockquote>
<p>이를 바탕으로 구성하고 나니 후에는 개발 속도가 붙어서 재미있게 viewer를 만들 수 있었다.</p>
<h2><strong>4. 서재에서 책 순서 변경</strong></h2>
<p>viewer말고도 책이 모여있는 library를 개발했어야하는데, 요구 사항 중에 사용자가 임의로 책의 순서를 변경 할 수 있고, 변경된 순서는 저장 되어야했다. 생각보다 어렵지 않게 개발을 진행하였다. 순서 변경은 drag and drop 방식으로 진행하였고 저장은 localStorage에 각 책의 이름만 저장하여 책을 불러왔을 때에 저장된 sort방식에 따라 책을 다시 재정렬 시켜주었다.
<a href="https://medium.com/free-code-camp/how-to-make-and-test-your-own-react-drag-and-drop-list-with-0-dependencies-6fb461603780">react drag and drop</a></p>
<h2><strong>5. 그래프큐엘 적용</strong></h2>
<p>한달 정도의 시간이 주어졌는데 사실 생각보다 일이 빨리 끝나서 기존에 공부하고 있었던 그래프큐엘을 적용해 보았다. 큰 프로젝트는 아니고 간단한 프로젝트 였기에 한번 해보면 좋을것 같았다.
그래서 책 목록을 가져오는것, 책을 지우는것 이 두가지는 REST API 가 아닌 그래프 큐엘로 적용해 봤는데, 크게 좋은 점은 못느꼈고 그래프큐엘 서버가 적용되어있다면 프론트 입장에서는 상당히 좋을 것 같다고 생각했다. overFetch, underFetch 같은 문제가 정말 손쉽게 해결 될것 같았고, 프론트 입장에서 필요한 데이터만 가져오게 되니 서버 쪽에서 resolver를 잘 구성해 놓으면 정말 좋은 api? 가 될 수 있다고 생각이든다. 하지만 속도면에서는 흐음 딱히 장점은 느끼지 못하였다. 정리하자면 원래 있던 서버에 간단하게 graphql 서버를 만들어 놓으면 프론트 개발자 입장에서는 편하게 작업 할 수 있을것 같다라는 생각이 들었다.
<img src="https://images.velog.io/images/eomttt/post/62b6034d-313e-4a6e-987a-e6edd80eba43/library-1.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/2d255039-96af-4986-8fa7-d4217bdaec39/library-2.png" alt=""></p>
<h2><strong>6. Upload epub</strong></h2>
<p>위에 그림처럼 당연하게도 epub 파일은 업로드는 s3를 이용하였다. 사용자가 epub파일 업로드 시 s3에 올린뒤, express server에서 가져다가 파일을 압축 해제를 하고 압축이 해제된 파일을 다시 s3에 올려놨다. 그러고 viewer를 띄울 때 viewer에 필요한 파일만 가져와서 프론트로 보내주는 방식을 채택하였다. 기존에는 viewer를 띄울 때 마다 epub파일을 가져와서 압축 해제 하여 보내주었는데, 최초 upload시에만 해제를 하고 viewer를 띄울 때는 이미 해제된 파일에서 필요한것만 넘겨주니 viewer를 띄울 때 속도는 확실히 개선된듯 보였다.
물론 웹이 아니라 모바일이나, 앱일 경우 자체 메모리를 사용하여 epub파일 압축 해제를 진행한다면 api없이도 가져올 수 있으니 훨씬 빠르게 될것 같다. 그래서 웹 뷰어 보다는 앱 뷰어가 있다는 생각이 들었다.</p>
<h2><strong>7. 배포</strong></h2>
<p>사실 배포는 ec2 를 이용하여 node를 돌릴 수도 있었겠지만 제일 간단하게 heroku를 사용하였다. 원래는 zeit/now를 사용하려고 했는데, 그 당시에는 upload를 생각하고 있지 않아서 프로젝트 내에 epub파일을 static하게 가지고 있었다. 그런데 zeit/now에서는 어떤일인지 노드 서버 쪽에서 static경로로 접근이 잘 안되어서 애를 쫌 먹었었는데, 그래서 바로 heroku로 갈아탔다. 물론 지금은 static경로 접근할 필요가 없어서 zeit/now를 사용해도 괜찮을지도 모르겠다?</p>
<blockquote>
<p><a href="https://spectrum.chat/zeit/now/fs-readdirsync-dirname-didnt-work~14039a98-56f4-4cd7-8c1a-4e2b2e37008e">zeit/now fs.readdirSync didn't work</a></p>
</blockquote>
<h1>결론</h1>
<p>이렇게 대략 3주? 정도에 시간을 들여서 RIDI에 온보딩 시스템인 입사자 과제를 완료 하였다. 물론 퍼블리시하게 나가기에는 아직 많이 부족하고 실제 사용되는 서비스에 비하면 정말 기본적인 기능들만 있는 뷰어이지만, 그래도 진행하면서 epub에 대하여 조금 친숙하게 되었고 현재 RIDI가 어떤식으로 뷰어를 렌더링하는 지 알게 되었다. 프로젝트를 진행하면서 궁금한게 있을 때에 팀장님과 사수에게 물어보면서 진행을 하였는데 현재 내가 생각하여 적용한 방식이 실제 RIDI에서도 채택한 방식이라고 이야기를 들었을 때에는 안도의 한숨이 나오기도 하였다. 좋은 방향으로 가고 있구나라고 생각이 들었기 때문이다.
RIDI는 내가 입사한 3번째 회사이지만 (사업 제외) 지금 까지 다녔던 회사들 보다 체계적이고 이런 온보딩 시스템이 새로 입사하는 사람에게 정말 많은 도움이 되는것 같다.</p>
<blockquote>
<ul>
<li><a href="https://github.com/eomttt/mini-viewer">github mini-viewer</a></li>
<li><a href="https://mini-viewer.herokuapp.com/">Web viewer</a></li>
</ul>
</blockquote>
<p>마지막으로 입사자 과제를 진행하면서 전에 다니던 회사에서 개발하였던 react-tree-multi-selector 모듈을 npm 에 올렸는데, 필요시 다운받아서 star 도 조금 올려주셨으면 좋겠다... 이글을 읽으시는 분들은... 호호</p>


RIDI 입사자 과제 회고

AWS Lambda를 이용하여 간단한 API 만들기 포스팅을 했었는데 이를 바탕으로 GraphQL를 이용하여 각 API 불러서 서비스를 완성해 보겠습니다.

<p>AWS Lambda를 이용하여 간단한 API 만들기 포스팅을 했었는데 이를 바탕으로 GraphQL를 이용하여 각 API 불러서 서비스를 완성해 보겠습니다.</p>
<blockquote>
<p><a href="https://velog.io/@eomttt/series/AWS-Lambda">- AWS Lambda를 이용한 API 개발</a></p>
</blockquote>
<p>원래는 GraphQL 프로젝트 자체를 AWS Lambda에 올려 완벽한 Serverless를 구축해보려 했으나, 50MB 이상은 올라가지 않는 AWS Lambda에 정책으로 가볍게 크롤링 하는 프로젝트만 올리고 이를 API화 시켜서 저의 GraphQL 프로젝트에 붙이려고 노선을 바꿨었죠.</p>
<p><img src="https://images.velog.io/images/eomttt/post/4845b71c-3342-4a56-9f57-2b2d441676d5/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.32.05.png" alt=""></p>
<p>위와 같은 구조로 잡고 오늘은 Node server -> AWS Lambda API 를 콜해보는 프로젝트를 작성해보았습니다.</p>
<p>먼저 <strong>scheme.graphql</strong>를 정의합니다.</p>
<pre><code>type Query {
  timeTable(type: String!, theaterInfo: String!): [MovieTimeTable]!
}

type MovieTimeTable {
  title: String!
  timeInfo: [MovieTimeInfo]!
}

type MovieTimeInfo {
  time: String!
}

</code></pre>
<p>그 다음 <strong>resolvers.js</strong>를 정의해 보았습니다.</p>
<pre><code>const { getTimeTable } = require('../controller/movie.controller');

const resolvers = {
    Query: {
        timeTable: (_parent, { type, theaterInfo }) => getTimeTable(type, theaterInfo),
    }
}

module.exports.resolvers = resolvers;
</code></pre>
<p>마지막으로 <strong>controller/movie.controller.js</strong>를 정의해보았습니다.
controller 폴더를 만들고 그 안에 movie.controller.js 를 만들고 각각의 함수를 import 하여 사용하였습니다.</p>
<pre><code>/**
 * Movie crwaling API
 * API: {API_URL}
 * KEY: AWS Key need
 * Query: {
   theater: 'megaBox' | 'cgv' | 'lotte',
   request: 'region' | 'theaters' | 'timetable' | 'box-office' (Only CGV),
   regionIndex: number (Only reqeust is 'theaters')
   theaterLink: string (Only request is 'timetable')
 }
 */

const axios = require('axios');

const BASE_URL = {API_URL};

// This api need key
axios.defaults.headers.common['x-api-key'] = {API_KEY};

const getTimeTable = async (theaterType, theaterInfo) => {
  try {
    const res = await axios.get(`${BASE_URL}?request=timetable&#x26;theater=${theaterType}&#x26;theaterLink=${encodeURI(theaterInfo)}`);
    return res.data;
  } catch (error) {
    const { response } = error;
    console.log('Get timeTable error message.', response.data.message);
  }
};

module.exports.getTimeTable = getTimeTable;
</code></pre>
<p>이를 사용하기 위해서 일단 프로젝트내에 제가 자주 사용하는 <strong>axios</strong> 모듈을 설치해줍니다.</p>
<blockquote>
<p>$ npm i axios</p>
</blockquote>
<p>제가 만든 <strong>API_URL, API_KEY</strong> 를 조합하여 axios.get 를 해줍니다. 각각의 API 는 위에 언급하였던 Lambda를 이용한 API 개발을 통해서 만든 API 입니다.</p>
<blockquote>
<p><a href="https://velog.io/@eomttt/series/AWS-Lambda">- AWS Lambda를 이용한 API 개발</a></p>
</blockquote>
<p>보안상의 이유로 URL, KEY를 가렸습니다.</p>
<p>이제 테스트를 해보겠습니다.</p>
<p>getTimeTable 이라는 쿼리는 인자로 각각 type, theaterInfo를 받게 되는데
type은 3가지 영화관 정보입니다. ('cgv', 'megaBox', 'lotte')
theaterInfo는 각 영화관에 영화관 정보입니다. 예를 들어 'cgv 강남' 이라고 하면 '강남' 이 되겠습니다.</p>
<p>위의 정보들은 제가 정의한거고 이유는 제가 만들었던 크롤링이 위의 두가지 인자를 바탕으로 동작하기 때문입니다.</p>
<h2><strong>CGV</strong></h2>
<p><img src="https://images.velog.io/images/eomttt/post/b759549d-6316-411b-a623-8802bf996d42/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.47.33.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/0cd358dd-c8f7-41c2-bb60-3e11c2e301af/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.49.23.png" alt=""></p>
<h2><strong>MEGABOX</strong></h2>
<p><img src="https://images.velog.io/images/eomttt/post/c601e0ff-b4a8-4bef-9124-b5992b18c520/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.47.48.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/4b1a4404-5ca2-4e99-875d-caba08a4d56c/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.51.40.png" alt=""></p>
<h2><strong>LOTTE</strong></h2>
<p><img src="https://images.velog.io/images/eomttt/post/1cabb125-ef51-4c3d-b5d2-b4072f2edf9a/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.47.40.png" alt="">
<img src="https://images.velog.io/images/eomttt/post/3a4a2abe-cc29-4ddf-bcca-d9457d572471/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202020-03-07%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.49.38.png" alt=""></p>
<p>위 사진 처럼 각각의 영화 제목과 상영시간을 가져오는 것을 확인해 볼 수 있습니다.</p>
<p>단, Lotte Cinema 같은 경우는 AWS Lambda로 접속하면 막혀있는것 같아서 네이버 검색을 이용하였습니다.</p>
<h3>결론</h3>
<blockquote>
<p>무튼 영화 정보를 가져오는 API를 만들고 그 GraphQL를 통하여 API 콜해서 데이터를 가져와보았습니다. 이제 하나 둘 프로젝트가 완성되고 있는 느낌이 나네요.
다음에는 React를 활용해서 실제 GraphQL 서버와 연결을 통해 데이터를 그려보도록 하겠습니다.</p>
</blockquote>
<blockquote>
<p>GraphQL은 정말로 엄청난것 같아요. 이를 구현하기 위해 RESTful한 서버를 만드려면 또 여러가지 일들이 필요하고 실제 어떤 쿼리가 필요한지 정의를 다 해놔야 클라이언트에서 부를 수 있을것 같은데 GraphQL를 스키마를 통한 정의 하나로 쉽게 필요한 파라미터를 넣어줄 수 있고 위처럼 기존에 API 도 쉽게 불러서 서비스에 적용할 수 도 있기 때문이죠.
이러한 장점들이 GraphQL 을 더 발전 시킬 수 있지 않을까 싶네요.</p>
</blockquote>
<h3>참고</h3>
<blockquote>
<p><a href="https://eomtttttt-develop.tistory.com/category/GraphQL">GraphQL에 관하여 정리한 글들</a></p>
</blockquote>
