엘레베이터에 낀 남자

장인은 도구를 탓하지 않는다. 도구를 만든다.

눅눅한 피부 — Thu, 5 Mar 2026 20:26:06 +0900

https://jonghakseo.github.io/posts/craftsman-makes-tools/

또 잔뜩 늦은 2025년 회고

눅눅한 피부 — Sun, 1 Mar 2026 18:34:55 +0900

오랜만에 글을 쓰려고 블로그에 들어오니 세 번째로 최신글이 '사내 AI 챗봇 서비스 구축하기'이고, 네 번째 최신글은 2024년 회고글이라니, 내가 한동안 글을 안 쓰긴 했구나 싶다.

요즘엔 글을 쓰고 싶은 주제들이 휙휙 스쳐지나가기만 하고, 실제로 쓸 시간을 갖지는 못하는 것 같다. 돌아보면 남는건 다 글인데...

거두절미하고, 또 잔뜩 늦었지만 2025년 회고를 해보려고 한다.

AI Platform 구축기

24년도 그랬지만 25년도 AI 이야기를 안 할 수가 없다. 25년은 단순히 AI 사용 뿐만 아니라, 조직 전체가 AI를 쓸 수 있게 플랫폼과 워크플로우를 설계하고 구축하는 해였다.

특히 25년 초에는 사내 AI Platform 구축에 많은 에너지를 쏟았다. 사실 AI Platform은 누가 시켜서 만들거나 회사에서 리소스를 받아서 구축한 서비스가 아니다. 내 퇴근 후의 시간과 주말을 갈아넣은 프로젝트였고 구축하면서 구성원들에게 AI 리터러시 함양, 구독비용 절감, 사내 데이터 가시성 확보 등 여러 성과가 있었다고 자평하지만, 사실 내가 얻은 게 제일 많았다.

현재 AI Platform은 사내 모든 부서(기획, CX, 마케팅, 개발)가 모든 창구(Slack, Web) LLM을 활용할 수 있는 허브가 되었고, 자체 MCP 서버 제공으로 Jira, Google, Slack, Notion, Figma 등의 모든 업무 도구를 쉽게 제공하고 있다.

젠데스크에 들어가는 AI 익스텐션을 만들었는데, 이후 CX팀은 채용 계획을 백지화 했다.

구현하면서 LLM과 관련된 애플리케이션을 만들 때의 어려움이나, 도구를 어떤 식으로 설계해야 하는지, LLM의 비결정성을 어떻게 평가하고 검증해야 하는지, 그게 얼마나 어려운지 등등... 배운 경험이 정말정말 많다.

덕분에 5월(Claude Code 1.0 출시 즈음)에는 자체적으로 구축한 ReasoningLoop를 사용한 DataAgent로 원하는 데이터를 높은 정확도로 가져올 수 있는 환경도 구축했다. DataAgent는 빅쿼리 도구를 들고 있는 AI Platform 내 일종의 서브에이전트다. 지금은 GitHub, DataAgent, BrowserAgent 등 여러 개의 특화 에이전트들이 플랫폼 위에서 잘 동작하고 있다.

브라우저 에이전트를 만들(깎을) 때의 고난의 시간도 새삼 생각이 난다. AI Platform은 기본적으로 AWS에서 돌아가고, 브라우저 에이전트는 헤드리스 크로미움을 쓰기 때문에 봇 탐지 등으로 실제 접근이 어려운 리소스들이 참 많았다. 우회하기 위한 여러 가지 해키한 작업들도 많이 했던 것 같다. 요즘엔 로컬 브라우저의 프로필을 그대로 써서 사실상 봇 탐지가 의미가 없어지는 추세이긴 하지만.. 그땐 그랬지.

12월에는 이 플랫폼이 보안 공격을 당하는 사고도 있었다. RSC 취약점을 통해 크립토마이닝 코드가 심어졌고, 대응 이후 유출 가능성이 있는 환경변수들을 교체하는 작업을 했다. 내가 직접 만든 시스템이 뚫린다는 건 꽤 충격적인 경험이었고, 자책도 많이 했던 것 같다. 그래도 정신을 빠르게 부여잡고 보안패치는 빠르게 해야한다는 뼈저린 교훈을 새겼다.

개발팀 리드, AI 시대의 엔지니어?

나 스스로 AI Platform을 구축하면서 AI의 도움을 많이 받긴 했지만(프롬프트나 도구 가시성에 대한 제어, 루프 설계 등 중요한 부분은 내가 하긴 했다) 이 경험이 나한테만 머무르면 안 되겠다는 생각을 했던 것 같다. 개발팀의 방향성에 대해서도 이야기를 많이 하고 의견도 많이 내게 되었다. 그러면서 자연스럽게 개발팀 리드를 해야겠다는 생각을 했다.

그 당시엔 비단 프론트엔드뿐만 아니라 우리 팀의 모든 엔지니어들이 어떤 방향을 향해 가야 하는지가 명확하다고 생각했다. 겪어본 바, 내년에는 개발자가 코드를 작성하지 않게 될 것이 너무나도 자명했고, 심지어는 거의 안 읽게 될 것이라고 생각했다. 엔지니어의 직무적 경쟁력이라는 것이 여러 가지가 있지만, 그중 큰 부분 중 하나가 요구사항을 코드로 옮기는 스킬이었다는 것은 부정할 수 없을 것이다.

나는 엔지니어들이 양극화될 것으로 생각했다. 코어 레벨에서 LLM이 알고 있는 기존의 패턴으로는 해결할 수 없는 문제들을 정말 고도의 집중력과 사고력으로 풀어내는 개발자들과, 프로덕트 관점의 엔지니어.

https://blog.pragmaticengineer.com/the-product-minded-engineer/

The Product-Minded Software Engineer

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a go

blog.pragmaticengineer.com

자연스럽게 후자의 방향을 생각했다. 전자는 LLM과 경쟁을 해야 하고, 후자는 그래도 사람들과 경쟁해야 하는 영역이라고 생각했으니까. 그런 관점에서 이런저런 이야기를 많이 했던 것 같다.

늘 고민이 많은 요즘입니다. 오늘은 부끄럽지만(...) 제가 저희 엔지니어 팀 슬랙 채널에 공유했

늘 고민이 많은 요즘입니다. 오늘은 부끄럽지만(...) 제가 저희 엔지니어 팀 슬랙 채널에 공유했던 글을 나누려고 합니다. --- 안녕하세요 크리에이트립 엔지니어 여러분 저는 요즘 새 시대의 엔

kr.linkedin.com

채용, 팀 리빌딩

채용 과제도 AI를 적극적으로 쓰고, 대신 프롬프트를 첨부해달라고 나름 그 당시엔 파격적으로 진행해봤는데 굉장히 경험이 좋았다. 결국 우리가 알고자 하는 건 같이 일하는 구성원이 어떤 사고를 하며 일을 하는지인데, 그게 프롬프트에 다 드러나더라. 사실 기술 수준이나 그 사람의 기준 같은 것도 다 프롬프트에 드러났던 것 같다.

[크리에이트립 프론트엔드 채용 과제를 살짝 공개(?)합니다] 크리에이트립의 이번 프론트엔드

[크리에이트립 프론트엔드 채용 과제를 살짝 공개(?)합니다] 크리에이트립의 이번 프론트엔드 채용 과제에는 큰 변화가 있었는데요, 문제 해결에 LLM 사용을 적극적으로 권장하고, 제출 폼에 사

kr.linkedin.com

지금 생각해도, 덕분에 새 시대에 맞는 정말 훌륭한 프론트엔드 엔지니어분들을 채용해서 참 다행이라고 생각한다.

개발자분들에게는 계속 프로덕트를 더 많이 사용해보고, 타 팀과 이야기해서 병목을 적극적으로 찾아보라고 이야기를 했다. 부끄러운 이야기지만 우리 프로덕트 팀은 도그푸딩을 거의 하지 않았다. 내가 있었던 4년간의 시간 동안 프로덕트의 탐색-예약-구매-리뷰 사이클을 돌려본 구성원이 거의 없었으니까... 변명이지만, 한국을 여행하는 외국인 여행객을 위한 플랫폼이라는 점이 뭔가 좋은 핑계거리가 되었던 것 같다.

아무튼 개발 리드라는 자리에서 좀 더 발언권이 생긴 참에, 개발자분들을 이끌고 프로덕트의 도그푸딩을 진행했다. 사실 정량적인 결과로 나온 프로덕트 개선안들보다 더 중요한 건, 그 경험 자체라고 생각한다. 내가 만드는 프로덕트가 어떻게 사용되고, 어떤 문제를 해결하고, 어떤 지점이 불편한지에 대한 감각. 새 시대의 엔지니어에겐 그런 감각이 필요하다고 생각했다.

한편 매번 채용에서 겪는 어려움을 타파하고자, 개발팀 자체의 브랜딩에 대해서도 노력을 쏟았던 것 같다. 그 일환으로 개발팀의 3, 4분기 예산과 일부 엔지니어들의 노력을 통해 Dev Talk라는 이름의 개발 밋업도 진행했다.

Creatrip Dev Talk - 이벤터스

크리에이트립 개발팀 밋업

event-us.kr

이후 채용에서의 지원이 소폭 늘어난 것과, 크리에이트립 개발팀의 인지도 향상이라는 성과에 비해서 생각보다 더 리소스가 많이 들어갔던 것 같아서.. 미래에 한 번 더 진행이 될지는 모르겠다.

프로덕트 엔지니어로의 전환

하반기에는 개발팀의 프로덕트 엔지니어 전환에 대한 구상도 했다. AI을 사용하면서 생산성이 늘어나도, 결국 백엔드-프론트엔드라는 소통 지점이 병목이 되는 것을 꾸준히 느꼈다. 내가 5년차 프론트엔드 개발자로 하는 것들의 90%를 AI가 해주는 것 같은데, 나머지 10%를 위해 나라는 사람의 리소스를 써야 하나? 엔지니어들은 그 나머지 10%를 메꿔주는 시스템을 구축하는 데 신경 쓰고, 그냥 모든 엔지니어가 직군에 갇히지 않는 기능 구현을 하면 안 되나? 아니 더 나아가서 모든 PM들이 기능을 구현할 수 있는 시스템을 엔지니어들이 만들고 유지보수하는 게 레버리지가 더 높지 않을까?

하는 생각이 강하게 들어 관련 작업들을 했다.

프로덕트 레포에서 암묵지를 발견할 때마다 ESLint 룰로 만들어서 잠갔고, 룰로 잡기 어려운 건 가이드라인 문서로 남겨 동적으로 참조할 수 있는 구조를 만들었다.. 돌아보니 한 해 동안 커스텀 ESLint 규칙만 30건 넘게 추가했다. 최근에 다른 글들을 보니 비슷한 경험을 하는 사람들은 비슷한 결론에 도달하는구나 싶다.

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

Effective harnesses for long-running agents

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

www.anthropic.com

https://openai.com/index/harness-engineering/

Harness engineering: leveraging Codex in an agent-first world

By Ryan Lopopolo, Member of the Technical Staff

openai.com

한편 엔지니어분들도 타 직군의 익숙하지 않은 기술에 대해 빠르게 이해도를 높이고 AI에 대한 제어 혹은 감사 능력을 갖기 위해 매주 세미나를 진행했다(지금도 하고 있다).

그래도 사실 나는 코드가 좋다

이것들과 별개로 나는 우리 프로덕트팀에서 아직도 제일 많은 커밋과 PR을 올리는 개인 기여자이기도 하다. 나 스스로가 문제 해결에 대한 감각을 놓치지 않아야 팀의 방향성을 가늠할 수 있는 감각이 유지되기 때문이기도 하고, 애초에 나는 일을 하는 게 즐겁다.

AI와 함께하는 생산성 향상?

올해도 굵직한 작업들이 많았다. styled-components에서 TailwindCSS로의 전사 마이그레이션을 AI 자동화 파이프라인까지 만들어가며 10개월에 걸쳐 완주했고, 지도 도메인이라는 완전히 새로운 서비스를 Phase별로 쪼개서 1.5개월 만에 릴리즈하기도 했다.

3년 전 리액트 소스코드를 보고 공부한 지식을 바탕으로 다른 팀원들이 감을 못 잡는 복잡한 버그를 여러 종류의 렌더 페이즈의 호출 순서를 설명하며 해결해낼 때도 짜릿했고, 2년 전 크롬 devtools를 눈 빠지게 보며 프론트엔드 KR이었던 코어 웹 바이탈을 90%까지 끌어올릴 때에도 짜릿했고, 작년 AI Platform을 구축하고 내가 원하는 워크플로우를 자동화하고, 회의록, 프로젝트, 마켓플레이스, 스킬, 전용 익스텐션 등을 만들어서 구성원들이 사용하는 모습을 볼 때도 짜릿했다. 요즘은 내 모든 LLM 사용 기록을 분석한 결과를 바탕으로 pi agent를 내 생산성이 최대로 나올 수 있는 구조로 커스텀해서 쓰고 있는데, one-shot 프롬프트 하나로 수십 개의 에이전트가 뚝딱뚝딱 거리면서 내가 했을법한 퀄리티의 결과물을 내는 걸 보면 또 짜릿하다.

업무로서 나에게 주어진, 다소 일상적인 태스크들도 참 많았는데 그런 것들도 다는 아니어도 대부분은 재미있게, 퀘스트를 깨듯 재미있게 했다.

AI 시대, 나의 입장

엊그제 출근하면서 그런 생각을 했다.

사실 AI 시대에 대해서 나 개인의 입장에서는 걱정이 크게 없는데, 이유는 내가 소프트웨어를 사용해서 어떤 문제든 푸는 걸 즐기는 사람이라는 점 때문이다. 아무리 대 딸깍 시대에 AI가 다 해줘도, 나는 '다 해주는 AI들을 어떻게 묶어서 퀄리티를 극대화할 수 있을까', '에이전트 워크플로우를 어떻게 설계하면 더 저렴한 모델로 동일한 결과가 나오게 할 수 있을까' 등을 재미있게 고민하면서 할 사람이기 때문이다.

기본소득 시대가 와서 모든 사람들에게 동일한 보상이(아무것도 하지 않더라도) 주어진다고 해도 난 아마 재미를 느끼면서 이런저런 문제를 풀어보려고 하고 있을 테니까.

아 그리고, 결혼도 했다

올해 6월6일6시(666), 아주 특별하고 재미있는 결혼식을 했다. 신랑이 마법사 지팡이를 들고, 신부가 쌍검을 들고 들어오는...

https://dasom-jonghak.wedding/

다솜이와 종학이의 결혼식에 초대합니다

25년 6월 6일 금요일 오후 6시 명동 온즈드롬

dasom-jonghak.wedding

신혼여행은 몽골을 2주 정도 다녀왔는데, 자연을 좋아하는 나에게는 너무나도 즐거운 시간이었다. 해발 2000m 고원을 달리는 차 안에서도 코딩은 할 수 있어서 좋았다.

홉스골 가기 전

기준의 간극

눅눅한 피부 — Sun, 12 Oct 2025 17:01:29 +0900

올해에는 유독 참 많은 사람들과 이런 저런 계기를 통해 대화를 많이 나눌 기회가 있었는데, 어느샌가 대화하면서 느끼게 되는 부분이 있어 글로 남겨둔다.

우리는 대화를 통해서 타인과의 '기준'을 가늠할 수 있게 되는데, 보통은 그 기준의 차이에서 흥미를 느끼기도 하고 거리를 느끼기도 한다. (여기서의 기준은 특정 이슈나 주제에 대한 개인의 '당연함의 선'이나 '중요도의 우선순위'를 나타내는 말로 사용했다)

개인의 기준이란 어디에서 비롯되는가?

경험의 밀도에서 나온다. 교통사고를 당해본 사람은 안전벨트를 당연하게 매고, 사기를 당해본 사람은 계약서를 꼼꼼히 읽는다.

계급의 위치에서 나온다. 알바를 해본 사람과 안 해본 사람이 '최저임금 인상'을 다르게 본다. 집을 사본 사람과 전세만 살아본 사람이 '부동산 정책'을 다르게 본다. 실업급여를 받으며 어려운 시기를 이겨낸 사람과 실업급여를 받아본 적 없는 사람의 입장은 다르다.

정보의 출처에서 나온다. 유튜브로 뉴스를 보는 사람과 신문으로 보는 사람의 '심각함'이 다르다. 의사 친구가 있는 사람과 없는 사람의 '의료 정책'에 대한 관심도가 다르다.

소속감의 방향에서 나온다. 자녀가 있는 사람은 교육 정책에, 부모를 모시는 사람은 복지 정책에 더 민감하다. 내가 보호해야 할 사람이 기준의 우선순위를 만든다.

대화에서 서로의 기준에 대한 간극이 매우 크게 느껴지는 순간, 기준의 근원이 되는 요인들이 다시 한 번 상기되며 어색한 순간이 찾아온다.

나는 내 기준을 설명할 때 "당연하다"는 말 대신 "나에게는"이라는 말을 의식적으로 붙이곤 한다. "당연히 그런 것"이 아니라 "나에게는 그런 것", "누구나 알 수 있는 일이야"가 아니라 "내 경험으로는" 혹은 "내 입장에서는 그래".

다소 자신감이 없어보이려나 싶은 생각도 들고... 작은 전치사 하나가 이 간극을 줄여줄지는 모르겠다.

먼저 온 미래 | 장강명

눅눅한 피부 — Sun, 3 Aug 2025 17:09:25 +0900

2016년 3월, 알파고와 이세돌의 대국이 있었다.

9년 후, 이 때의 충격을 바둑계는 어떻게 소화했을까?

ChatGPT를 위시한 수많은 LLM이 우리의 일상과 일자리에 섞여드는 지금, 우리보다 먼저 그 미래를 마주했던 바둑계의 감상과 대응이 퍽 흥미롭다.

우리는 기계와 과학의 시대에 살고 있기에 무슨 일이 있어도 '진보'는 계속되어야 하고 지식은 절대로 억제되어선 안 된다는 관념에 감염되어 있다. 우리는 말로는 기계가 사람을 위해 만들어졌지 사람이 기계를 위해 만들어진 건 아니라고 한다. 하지만 실제로는 기계의 발달을 제어하려는 시도는 지식에 대한 공격이며 곧 일종의 불경으로 간주되는 것 같다.

- 조지 오웰, 『위건 부두로 가는 길』

내가 이 일을 시작하던 시점인 5년 전에는 업무에서 AI를 사용한다는 것을 상상하기 어려웠다. 알파고 이전의 바둑계와 마찬가지로 업무 영역에서 AI가 대체하기 어렵다고 생각했고, 소위 말하는 소프트웨어 공학에 어떤 '예술적 특성'이 있기 때문에 더 그렇다고 생각했다.

'아름다운 코드', '코드에서 악취가 난다', '보기 좋은 코드가 유지보수하기 좋은 코드다' 등등... 프로그래밍에서도 암묵지에서 비롯된 모호한 용어들이 많았고, 이런 모호함과 다의성(多義性)은 인간의 고유한 영역이라고 생각했으니까.

불과 2~3년 후에 Github copilot이 나왔고, 마치 내 생각을 읽는 듯한 자동완성과 코드 추천 기능을 보면서 크게 놀랐다. 개인적으로는 공부를 시작할때부터 달고 살았던 손목 통증이 사라지는 계기가 되어 매우 기쁘기도 했고...

그리고 작년 말부터 지금까지, 특히 최근에는 코드를 직접 작성하거나 수정하는 일이 극적으로 줄어들었다. Cursor, Windsurf, Kiro등 AI IDE에게 내 의도를 정확하고 자세하게 설명하거나, 그 과정에서 함께 논의하고 세부 구현을 맡기는 일이 나의 (개발쪽 업무에서는)대부분의 업무 방식이 되었다. 최근에는 어떻게 하면 Claude Code를 비롯한 Agent AI에게 내 업무의 맥락을 위임할 수 있을지, 암묵지를 문서화 할 수 있을지에 대한 방법을 계속 고민하고 있다. 맥락이 충분히 담겼다고 판단되면 Agent에게 계획 수립부터 구현까지 전부 맡기기도 한다.

바둑계와 마찬가지로, 프로그래밍 업계도 AI와의 업무에 대한 반응은 어느정도 나뉘는 것 같다. 나는 개인적으로 내가 속한 업계가 이러한 변화에 빠르게 인지할 수 있는 업계이며 때문에 패러다임의 변화를 어느정도 예측하고 한 발 앞서 적응할 수 있는 환경이라 다행이라고 생각하는 편이다.

몇 달 전, CX팀의 불편함을 해소시켜줄 수 있는 작은 프로그램을 AI로 구현한 적이 있다. AI의 도움을 받아 매우 적은 나의 리소스로 구현했다는 점에서도 의의가 있지만, 해당 프로그램을 사용한 이후 CX팀의 생산성이 올라 채용 계획이 백지화 되었다는 이야기를 들었을 때에는 기분이 참 묘했다. 그만큼의 비즈니스 임팩트를 짧은 시간에 냈다는 점에서 개인적으로는 고무적이었지만, 어쩌면 우리 회사에서 함께 일할 수 있었던 그 직원분들에게는 개인이 감당 혹은 인지할 수 있는 영향이 아니었을 것이라는 점에서 그렇다.

최근 주니어 개발자 채용을 하는 회사를 보기가 정말 힘들어졌는데, 각 기업들의 현장에서 이러한 일이 일어나고 있을 것으로 예측된다. 아직까지는 AI가 시니어 개발자 만큼의 풍부한 경험과 맥락에서 오는 포괄적 구현, 커뮤니케이션 능력이 없으니까. 현재 수준의 AI를 잘 사용할 수 있는 사람들은 주니어 개발자들을 데리고 개발하던 시니어 개발자일 테니까. 주니어 개발자 정도의 구현은 시니어 개발자들이 추가로 지출하는 월 $200정도면 충분하니까.

빅테크 기업들이 앞다투어 프로그래밍 AI를 개발하는 이유는 그 시장이 돈이 되기 때문이다. 즉, 프로그래머들이 몸값이 높기 때문이다. 몸값이 훨씬 비싼 시니어 개발자들도 대체하려고 최선을 다 하겠지. 그 때 기업은 어떤 선택을 할까?

뻔한 질문은 그만두고, 앞으로의 시대에 개발자들은 어떤 역량을 키워야 할까?

AI의 역량에 대해 무엇 하나 장담할 수 있는 시대는 아니지만, 나는 '주도성'이 우리가 갖춰야 할 핵심 역량이라고 믿는다. 문제 발견과 해결책 수립, 그리고 구현이라는 3단계 과정은 비단 개발 영역 뿐만 아니라 비즈니스에서 본질적인 프로세스라고 생각하는데, 이미 문제 발견과 해결책 수립에서 AI의 도움을 받을 수 있고, 구현은 거의 비용이 들지 않을 정도로 AI가 이미 잘 하는 영역이다. 하지만 어떤 문제를 발견하려고 하는지, 본질적으로 문제 자체를 해결하고 싶은지는 오롯이 인간의 주도성(문제 해결에 대한 의지라고 치환해도 될 것 같다)이 기여한다.

책에서 던지는 질문들이 참 많은데, 저자와 나를 포함해서 현 시점에는 누구도 자신있게 대답할 수 없는 것들 투성이다. 예술은 무엇인가. 예술성은 무엇인가. 우리가 하는 업무에서 AI의 도움을 받는것과 AI에 의존하는 것의 차이는 무엇인가. 가치에 대한 평가 주체는 누가(무엇이) 될 것인가. 우리가 잃게 될 것, 얻게 될 것들은 무엇일까.

여담이지만, 저커버그가 말하는 개인화된 초지능의 시대가 와도 우리 모두가 행복해지진 않을게 분명하다. 제 2의 1984를 누가 집필해줬으면 좋겠다. 2084같은 제목으로...

먼저 온 미래 | 장강명 - 교보문고

먼저 온 미래 | 나는 바둑계에 미래가 먼저 왔다고 생각한다. 2016년부터 몇 년간 바둑계에서 벌어진 일들이 앞으로 여러 업계에서 벌어질 것이다.2016년 이세돌-알파고 대국 이후 바둑계에 먼저

product.kyobobook.co.kr

이 책의 저자이신 장강명씨의 부인이자 그믐 대표이신 김새섬님의 건강을 기원합니다.

사내 AI 챗봇 서비스 구축하기

눅눅한 피부 — Thu, 20 Feb 2025 12:29:18 +0900

https://medium.com/creatrip/%EC%82%AC%EB%82%B4-ai-%EC%B1%97%EB%B4%87-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-a4fab54f898d

사내 AI 챗봇 서비스 구축하기

안녕하세요. 크리에이트립(Creatrip) FE 개발자 서종학입니다.

medium.com

5년차 프론트엔드 개발자의 2024년 회고

눅눅한 피부 — Sun, 2 Feb 2025 14:38:43 +0900

2023년 회고를 작성했던 기억이 엊그제 같은데 벌써 2025년의 첫 달도 훌쩍 지나갔다.

2023년에는 내가 스스로 어떤 사람인지 좀 더 깊이 이해하고 내면의 성장을 이뤘다면 2024년에는 내면의 성장을 바탕으로 보다 즐겁고 의미 있게 한 해를 보냈다.

파트 리더

재작년 말, 프론트엔드 파트 리드를 맡게 되었다. 한 해를 돌아보며 나름대로 성공적인 파트 리더 업무 수행이었다고 자평하지만 그 과정에서의 고민과 갈등도 참 많았다.

구성원들의 동기부여를 위해 꾸준히 1:1 면담을 진행하며 이런저런 팀 단합 시간을 만들었고, 소통에서의 오해를 줄이고 합리적으로 커뮤니케이션을 하기 위해 신경을 많이 기울였다. 6개월 간격으로 리더십에 대한 익명 설문을 통해 내가 잘못된 방향으로 가고 있지는 않은지 돌아보았고, 나태해지지 않기 위해 노력했지만 그래도 1년 내내 같은 텐션으로 임하지는 못했던 것 같다. 어쨌든 파트원들과 함께 생산성을 개선하고 한 명의 이탈자도 만들지 않았던 부분은 성공이었다고 자평하고 싶다.

성장에 대한 욕구가 크고 주도적인 인원들이 모이는 스타트업의 특성상 구성원들에게 성장하고 있다는 감각을 주는 것이 유지에 매우 중요하다고 생각하는데, 구성원들의 성장을 위한 여러 스터디(리액트 소스 코드, 라이브러리 소스 코드 탐구, 기술 서적 함께 읽기)를 성공적으로 진행했던 것이 큰 도움이 되었다고 생각한다. 그 밖에도 정비 스프린트에서 구성원들이 자율성을 갖고 진행한 태스크들로 업무 성취감을 얻는다든지, 페어 프로그래밍을 통한 업무 유대감 증진 등도 도움이 되었을 것 같다.

KR 초과 달성

작년 프론트엔드 파트의 KR이었던 웹 바이탈 개선 목표를 초과달성하며 큰 효능감을 느꼈다.

https://nookpi.tistory.com/209

지난 1년간의 웹 바이탈 개선기 1편 - 다국어 동적 로드

올해 회고를 쓰기 앞서 지난 1년간, 정확히는 지난 약 8개월간의 웹 바이탈 개선을 위한 작업들을 기록해보려고 한다. 먼저 결과부터 보자면 코어 웹 바이탈 기준으로도 많은 개선이 있었다. 5

nookpi.tistory.com

기존 웹 바이탈이 워낙 오랫동안 좋지 않았기에 '이게 될까?' 싶은 부분들도 있었지만 여러 시도와 노력으로 드라마틱하게 개선을 할 수 있었다. 무엇보다도 즐거운 일은 관련 작업들(SWR 캐싱 등)이 단순 웹 바이탈 지표 개선에 머무르지 않고 실제 유입량의 증가와 유저 체감 속도에도 큰 영향을 주었다는 점이다.

유저페이지 자체의 성능 향상과 이로 인한 고객 경험 개선이라는 측면에서 스스로에게도 매우 보람찬 일이었다.

이력서/포트폴리오 정리

https://ahead-vanilla-49e.notion.site/Jonghak-Seo-1475b8aea39380889f81ea588df0d1c7

서종학 (Jonghak Seo) | Notion

포트폴리오

ahead-vanilla-49e.notion.site

https://ahead-vanilla-49e.notion.site/Jonghak-Seo-1475b8aea3938087be04e874eb76d6e1

서종학 (Jonghak Seo) 포트폴리오 | Notion

상세한 경력 기술서는 이력서에서 확인해주세요.

ahead-vanilla-49e.notion.site

올 한 해를 정리하면서 이력서와 포트폴리오를 한 번 정리했다. 웹 바이탈 개선 작업의 지표가 잘 나와서, 이력서를 정돈한 지 너무 오래되어서 한 해 회고를 겸하여 이번 기회에 다시 작성해보았다. 개인적으로는 만족스럽게 잘 작성한 것 같아 기쁘다. :)

오픈소스

크롬 익스텐션 보일러플레이트 오픈소스는 상반기에 아키텍처를 갈아엎어 새로 만들다시피 한 이후로 하반기에는 주로 유지보수와 버그 대응 위주로 대응했다.

Stars 2K를 달성하여 8월에 블로그 포스팅을 올렸는데 곧 3K가 될 것 같다.

https://jonghakseo.github.io/posts/until-2k-stars/

Open source to 2K stars.

What I've learned from reaching 2000 Stars on GitHub.

jonghakseo.github.io

9월에는 디스코드에서 기여해주시는 분들과 팀 미팅을 가지면서 앞으로의 발전 방향에 대해서 논의하는 시간도 가졌는데, 영어 울렁증으로 덜덜 떨면서 시작했으나 다들 제1언어가 영어가 아닌 유럽인들이어서 편하게 이야기를 나눌 수 있었다.

참고로 논의한 내용들은 아직 시작도 못 하고 있다... 올해에는 힘내서 하기로 한 내용들을 다 해봐야지.

영어공부

2024년 한 해 꾸준히 영어공부를 했는데 성과가 상당히 있었다. 앞서 언급한 유럽 개발자들과의 팀 미팅은 재작년만 해도 상상할 수 없는 일이었다. 나는 예전부터 영어를 잘하지 못했는데, 개발을 본격적으로 시작하기 전에는 영어 때문에 개발을 제대로 할 수 있을지 고민할 정도였다. 그러니 더더욱 회화는 한 마디도 하지 못했다.

재작년 중순, 미국에 있는 스타트업 팀과 협업할 수 있는 좋은 기회가 있었고, 좋은 제안도 받았지만 언어 장벽과 내가 원하는 도메인의 업무가 아니라는 이유로 거절했다. 그때, 개발자로서 앞으로 좋은 기회가 왔을 때 영어 때문에 발목이 잡히면 안 되겠다는 생각이 들어 재작년 말에 영어 과외를 시작했다.

약 10개월 동안 영어 과외를 하면서 열심히 하거나 많은 시간을 투자하지는 않았지만 꾸준히 했던 것 같고, 영어 회화 실력이 늘어가는 것을 느끼면서 더욱 재미있게 공부했던 것 같다. 작년 말부터는 링글이라는 원어민 대화 플랫폼을 통해 유럽과 미국 등의 튜터들과 대화를 하고 있는데, 꽤 재미있게 잘하고 있다

1년 넘게 영어 공부를 하면서 실력도 많이 늘었지만 (기존에 워낙 못했으니), 무엇보다도 영어 회화에 대한 두려움이나 망설임이 없어진 것이 가장 큰 자산인 것 같다. 올해도 영어 공부를 열심히는 아니어도 최소한 꾸준히 계속할 생각이다.

2024 총평

5년차 프론트엔드 개발자라는 타이틀은 참 무서운 것 같다. 3년차, 4년차에는 그렇게 생각하지 않았던 것 같은데... 햇수로 5년이라는 시간 동안 일을 했다면 내가 지금 아는 것, 할 수 있는 것이 높은 수준에 해당하는지 의구심이 든다.

이력서와 포트폴리오를 다듬으면서 한 해를 돌아보니 나름 뭔가 많이 그리고 잘한 것 같은데 내가 느끼는 내 성장 곡선은 예전만큼 가파르지 않은 것 같다. 솔직히... 더 많이, 잘할 수 있었는데 나 스스로 '이 정도면 잘했는데?'라는 생각에 빠져 다소 게을렀다고 생각한다.

올해는 이런 게으름을 걷어내고 작년의 성장 곡선 이상의 각도를 만드는 한 해가 되도록 노력해봐야겠다.

지난 1년간의 웹 바이탈 개선기 3편 - SWR 적용

눅눅한 피부 — Wed, 20 Nov 2024 23:42:58 +0900

지난 2편의 글에 이어서 웹 바이탈 개선을 위해 했던 세 번째 작업에 대해 이야기해보려고 한다.

https://nookpi.tistory.com/209

지난 1년간의 웹 바이탈 개선기 1편 - 다국어 동적 로드

올해 회고를 쓰기 앞서 지난 1년간, 정확히는 지난 약 8개월간의 웹 바이탈 개선을 위한 작업들을 기록해보려고 한다. 먼저 결과부터 보자면 많은 개선이 있었다. 5월 초, 5%까지 내려갔던 Good

nookpi.tistory.com

https://nookpi.tistory.com/210

지난 1년간의 웹 바이탈 개선기 2편 - SSG 제거, SSR 전환

지난 1편에 이어 웹 바이탈 개선을 위해 했던 작업에 대해 이야기해보려고 한다. 2. SSG 제거, SSR 전환두 번째 작업은 Nextjs 환경에서의 기존의 SSG(ISR)를 모두 제거하고 SSR로 전환한 것이다.언뜻

nookpi.tistory.com

3. SWR 적용

https://datatracker.ietf.org/doc/html/rfc5861

RFC 5861: HTTP Cache-Control Extensions for Stale Content

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.

datatracker.ietf.org

먼저 SWR 이란 stale-while-revalidate의 약자로 프론트엔드 생태계에는 vercel에서 만든 동명의 라이브러리가 있다. 참고로 같은 SWR이 맞다.

https://swr.vercel.app/ko

데이터 가져오기를 위한 React Hooks – SWR

SWR is a React Hooks library for data fetching. SWR first returns the data from cache (stale), then sends the fetch request (revalidate), and finally comes with the up-to-date data again.

swr.vercel.app

HTTP [RFC2616]는 캐시가 "요청에 적합한 가장 최신의 응답으로 응답해야 한다"고 요구하지만, "신중하게 고려된 상황"에서는 오래된 응답을 반환하는 것이 허용된다고 명시하고 있습니다. 이 문서는 이러한 제어를 가능하게 하는 두 개의 독립적인 Cache-Control 확장, stale-if-error와 stale-while-revalidate를 정의합니다.

stale-if-error HTTP Cache-Control 확장은 오류가 발생했을 때, 예를 들어 500 Internal Server Error, 네트워크 세그먼트, 또는 DNS 실패가 발생했을 때, "심각한" 오류를 반환하는 대신 오래된 응답을 반환할 수 있도록 캐시에게 허용합니다. 이는 가용성을 향상시킵니다.

stale-while-revalidate HTTP Cache-Control 확장은 캐시가 백그라운드에서 응답을 재검증하는 동안 즉시 오래된 응답을 반환할 수 있도록 하여, 클라이언트로부터 네트워크 및 서버의 지연을 숨길 수 있게 합니다.

어렵게 생각할 필요는 없고, SWR은 그냥 캐싱 전략이라고 이해하면 된다. 데이터를 최신화 하는 동안, 일단 들어온 요청에 대해 먼저 오래된 데이터를 주는 패턴이다. 같은 말로 '데이터를 재검증하는 동안에, 예전 데이터가 있으면 일단 그걸 준다' 는 말이다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control#%ED%99%95%EC%9E%A5_cache-control_%EB%94%94%EB%A0%89%ED%8B%B0%EB%B8%8C

개발새발

이전 편에서 CDN 캐싱을 위해 SSR 응답에서 Cache-Control 헤더에 s-maxage를 넣었듯이, SWR을 사용하기 위해서는 Cache-Control 헤더에 stale-while-revalidate 헤더를 넣고 시간을 적어주면 된다.

export const setCDNCacheHeader = (
  res: ServerResponse,
  sMaxAge: number,
  staleWhileRevalidate?: number,
) => {
  // 1초 이내 요청은 캐시를 사용하고, 1초 이후에는 CDN 캐시를 사용한다.
  // 디스크 캐싱으로 발생할 수 있는 문제를 회피하고 컨텐츠의 최신화 여부를 CDN에 위임하는 방식.
  const cacheValue = [];
  cacheValue.push('public');
  cacheValue.push(`max-age=1`);
  cacheValue.push(`s-maxage=${sMaxAge}`);
  if (staleWhileRevalidate) {
    cacheValue.push(`stale-while-revalidate=${staleWhileRevalidate}`);
  }
  res.setHeader('Cache-Control', cacheValue.join(', '));
};

//...

// getServerSideProps 내부
setCDNCacheHeader(
  res,
  REVALIDATE_INTERVAL_SECONDS.THIRTY_MINUTES, // 30분
  STALE_WHILE_REVALIDATE_SECONDS.ONE_WEEK, // 1주일
);

위 코드는 다음과 같다.

1. 30분 이내의 페이지는 최신으로 간주하여 CDN에서 캐싱된 페이지를 제공한다.

2. 30분 이내의 페이지가 없다면, 1주일 이내의 페이지를 반환하고 내부적으로 새 페이지를 갱신한다.

3. 1주일 이내의 페이지가 없다면 새 페이지를 생성하길 기다렸다가 반환한다. (생성된 페이지는 캐싱)

SWR 헤더 적용은 단일 작업으로는 유저 경험에 가장 큰 임팩트를 준 작업이었다. 그야말로 가성비 최강! 9월에 프로덕션에 머지되었는데 이 시기 이후로 프로덕트의 전반적인 체감 속도가 크게 개선되었다. 실제 유저 경험에서도 응답속도가 개선되었다는 의견이 많아 개인적으로 매우 만족스러운 작업이었다.

지난 1년간의 웹 바이탈 개선기 2편 - SSG 제거, SSR 전환

눅눅한 피부 — Wed, 20 Nov 2024 23:25:50 +0900

지난 1편에 이어 웹 바이탈 개선을 위해 했던 작업에 대해 이야기해보려고 한다.

2. SSG 제거, SSR 전환

두 번째 작업은 Next.js 환경에서의 기존의 SSG(ISR)를 모두 제거하고 SSR로 전환한 것이다.

언뜻 생각하면 SSG는 빌드 시점에 생성된 HTML이고, SSR은 유저의 요청이 있을 때 렌더링을 해서 제공하기 때문에 SSG가 SSR보다 더 빠를 수 없는데 무슨 소리지? 라는 생각이 든다.

이 작업의 배경에 대해 설명하자면 프로덕트의 배포 환경에 대한 부연 설명이 좀 필요한데, 간단하게 말해 프론트엔드 서버는 esc에 로드밸런싱이 되는 컨테이너들로 떠 있는 상황이었다. 이러한 환경에서의 SSG는 치명적인 문제가 있었으니... 유저의 매 요청이 ELB를 거쳐 각 인스턴스에 배분되다보니 우리가 기대한 ISR의 동작이 제대로 이뤄지지 않았다.

그럴 수 밖에 없는게 캐싱 단위가 Next.js 인데 App이 여러개 떠있으니 캐시가 제대로 적중할리가...

이 문제를 해결하기 위해 별의별 트리키한 해결책(노드 클러스터링으로 한 인스턴스에 여러 앱을 띄우기, shared storage를 만들어서 SSG 자원을 각 앱에서 공유하기)을 고민하던 중, 불현듯 깨달음을 얻었으니,

"그냥 더 앞단(CDN)에서 캐싱하고 인스턴스에서는 SSR로 주면 되는거 아녀?!"

그렇다. 어차피 본질이 캐싱이라면 Next.js 내부에서 하려고 눈물의 차력쇼를 할 필요가 없던 거였던 것이다.

SSG를 싹 다 날리고 cloudfront 캐싱을 위한 캐시 헤더(s-maxage)를 붙이고 배포를 하니... 아주 신세계였다.

export const setCDNCacheHeader = (res: ServerResponse, maxAge: number) => {
  // 1초 이내 요청은 로컬 캐시를 사용하고, 1초 이후에는 CDN 캐시를 사용한다.
  // 로컬 캐싱으로 발생할 수 있는 문제를 회피하고 컨텐츠의 최신화 여부를 CDN에 위임하는 방식.
  res.setHeader('Cache-Control', `public, max-age=1, s-maxage=${sMaxAge}`);
};

//...

export const getServerSideProps: GetServerSideProps = async ({ res }) => {
  //...
  setCDNCacheHeader(res, 60); // 1분 동안 cloudfront에 캐싱된다.
  //...
}

이 작업을 하면서 깨달음을 하나 얻었는데, 문제에 대한 해결책을 눈 앞의 틀에만 갇혀서 생각하지 않고 좀 더 거시적으로 바라봐야겠다는 것이었다. 캐싱 레이어를 CDN으로 옮기는 비교적 간단한 작업으로 유저들에게 많은 이점을 줄 수 있었는데, SSG의 최적화 자체에만 너무 매몰되어 있었던 것 같아 반성을 많이 했다.

지난 1년간의 웹 바이탈 개선기 1편 - 다국어 동적 로드

눅눅한 피부 — Wed, 20 Nov 2024 22:58:17 +0900

올해 회고를 쓰기 앞서 지난 1년간, 정확히는 지난 약 8개월간의 웹 바이탈 개선을 위한 작업들을 기록해보려고 한다.

먼저 결과부터 보자면 코어 웹 바이탈 기준으로도 많은 개선이 있었다.

드라마틱하게 상승

이랬던 아이가

이렇게...

5월 초, 5%까지 내려갔던 Good 비율은 11월인 현재 80~90%를 넘나들며 준수한 수준으로 유지되고 있다.

위 지표는 모바일 기준인데, 모바일 서비스 사용자가 많은 우리 서비스의 특성과 모바일의 점수 기준이 더 짜다는 점을 고려하여 모바일 지표만 고려하여 대응하고 있다. 물론 당연히 데스크탑 지표는 더 잘 나온다. (Good 비중이 95% 수준)

그렇다면 이런 지표 향상을 위해 기울인 나름의 노력들은 무엇이 있을까?

1. i18n 데이터 동적 로드

코어 웹 바이탈 개선을 위해 했던 작업 중에서도 TBT(INP)를 줄이는데 가장 큰 기여를 한 태스크라고 생각한다.

구조적으로 App Router 전환이 어려운 지금의 서비스 구조에서 나름의 대응으로 메인 스레드의 병목을 완화한 태스크였다.

기존 구현에서는 다국어를 지원하기 위해 특정 언어에 해당하는 모든 다국어 파일을 한 번에 불러오는 방식을 사용하고 있었다. TBT 개선을 위해 하이드레이션 과정에서의 메인스레드 병목을 찾았고, 해당 파일의 큰 용량으로 인한 JSON.parse, decodeURLComponent 동작이 생각보다 큰 영향을 주고 있음을 알게 되었다.

실제 퍼포먼스 탭에서 확인 결과 단순히 JSON.parse 만으로도 약 5ms의 리소스가 든다는 것을 알 수 있다.

이때 문제 분석과 해결을 위한 가설 수립을 위해 스레드에 끄적인 내용들이 있는데 대략 이런 식이다.

해결을 위한 구현 컨셉을 대략적으로 설계했고

SSR/SSG 단계에서 렌더링에 사용되는 i18n key를 체크하여 해당 키값에 해당하는 값만 내려주도록 개선했다.

나머지 바로 사용되지 않는 다국어 데이터는 하이드레이션 이후 천천히 가져온다.

이 작업을 하면서 두 가지 효과가 있었는데, 하나는 하이드레이션 자체에 대한 부하를 줄인 것,

또 하나는 네트워크 페이로드에 불필요한 다국어가 실리지 않게 되면서 첫 html의 용량이 비약적으로 다이어트가 되었다는 점이다.

TBT뿐만 아니라 전반적인 지표에 긍정적인 영향을 줬던 작업이라고 생각한다.

모노레포에서 HMR 지원하기

눅눅한 피부 — Sat, 16 Nov 2024 13:09:11 +0900

우리 회사의 프론트엔드 레포는 모노레포 환경으로 동작하고 있다. 작년 9월쯤 터보레포 기반의 모노레포로 전환했고, 올해 3월에 pnpm을 적용했다.

모노레포를 적용하면서 패키지로 추출한 ui, animation 의 경우 해당 패키지의 진입점이 빌드 후 결과물로 명시되어 HMR 동작에 어려움을 겪게 되었다. 사실 일반적인 개발 환경에서는 문제가 없지만, ui 패키지 등을 수정하면서 작업해야 하는 Storybook과 같은 환경에서는 치명적이다.

예를 들어 다음과 같은 경우를 생각해보자.

1. Storybook - dev 실행

2. ui 패키지의 Button 스타일 변경

3. ui 패키지 re-build

4. Storybook 에서 ui 패키지의 변경사항 감지

5. Full Reload

vite의 react plugin 내부에 꼭꼭 숨어있는, 보통은 캡슐화되어 숨겨져있는 HMR 기능의 동작은 대략적으로 다음과 같다.

1. 모듈의 의존관계를 파악

2. 모듈의 의존성 트리를 조회하면서 변경사항을 감지하고 외부에 알리는 HMR 스크립트를 inject

3. 특정 모듈에 변경사항이 생기면 HMR 스크립트에서 감지 후 해당 모듈만 리로드 + 캐시 무효화

2번 항목에서 외부 의존성에 해당하는 모듈인지 내부 소스코드인지 판별 후 inject를 하게 되는데, 문제는 모노레포 환경에서는 특정 패키지가 외부 의존성인지 아닌지를 꼼꼼하게 발라낼 정도로 해당 로직이 똑똑하지 않다는 점이다.

이 문제를 빠르게 해결할 수 있는 방법이 무엇일까?

개발 환경에서는 외부 모듈이 아닌 내부 의존성임을 HMR 로직에 알려주면 된다. 그걸 어떻게?

import { type AliasOptions, defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'node:path';

const isDev = process.env.NODE_ENV === 'development';

const devAliases = {
  // 개발 환경에서 패키지들의 HMR을 지원하기 위해 로컬 경로를 통해 참조
  '@ui': path.resolve(__dirname, '../../packages/ui/index'),
  '@icon': path.resolve(__dirname, '../../packages/icon/index'),
  '@style': path.resolve(__dirname, '../../packages/style/index'),
} satisfies AliasOptions;

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: isDev ? devAliases : undefined,
  },
});

심플하게 이렇게 알려주면 된다!

예시에서는 vite의 resolve.alias 를 사용했지만 webpack 등 다른 설정 환경에서도 유효한 해결책이다.

로컬 경로를 통해 참조할때 명시적으로 index.ts 등의 진입점을 꼭! 명시해줘야 한다. 그렇지 않으면 해당 패키지에 있는 package.json의 진입점을 통해 모듈을 파악하기 때문에 의도와 달리 HMR이 제대로 동작하지 않는다.

HMR의 기본적인 동작에 대해 살펴본 경험, JS 환경에서 모듈 리졸버에 대한 기본적인 로직을 알고 있다면 다음과 같이 간단한 해결책으로 모노레포 환경에서의 HMR 지원을 추가할 수 있다. :)

Leptos 후기

눅눅한 피부 — Sat, 2 Nov 2024 16:39:28 +0900

https://leptos.dev/

Home - Leptos

Your favorite language Leptos makes it easy to integrate Rust backend code with your user interface in a few lines of code. #[server] functions let you cross the client-server boundary without the boilerplate of setting up a new API endpoint, making it eas

leptos.dev

Counter 컴포넌트는 못참지

한동안 무심했던 rust 공부도 할 겸, Leptos를 사용해서 간단한 SPA를 만들어봤다.

https://github.com/Jonghakseo/leptos-study

GitHub - Jonghakseo/leptos-study

Contribute to Jonghakseo/leptos-study development by creating an account on GitHub.

github.com

뭔가 실무적인 유즈케이스를 상상하면서 구현을 해보려고 했는데, 결론부터 말하자면 앞으로 굳이 rust로 웹 프론트엔드 개발을 하게 될 일이 있을까? 싶은 기분이 들었다.

생각보다 Leptos 내에 구현된 브라우저 JS 환경과의 접점 인터페이스가 꼼꼼하게 작성되어서 놀랐는데, 그와 별개로 NativeJS 객체를 rust로 다루는게 너무 번거로웠달까.

JSX style의 렌더링 코드나 props 바인딩을 보니 새삼 React 진영의 최고의 발명품은 JSX라는 생각도 들고...

확실히 rust가 재미있긴 하다. rust 에서의 closure 명시 문법이 꼼꼼하다며 감탄하다가도 참조 카운터(RC)로 만든 시그널이 해당 제약 우회하는걸 보며 편의성도 느꼈다.

이번 공부때는 copilot이 아닌 gpt를 좀 적극적으로 사용하면서 이것저것 물어보고 공부하면서 진행하니 더 도움도 되고 재미있었다. rust를 꾸준히 공부하려면 rust로 뭔가 만들어야 할 것 같은데 web은 생산성 측면에서 큰 재미가 없고 알고리즘도 좀 애매하고.

결국 성능적으로 이점이 큰 CLI를 만드는게 좋을 것 같은데 문제는 지금 만들고 싶은게 없다.

useQuery의 흐름 끄적끄적

눅눅한 피부 — Sun, 13 Oct 2024 17:37:24 +0900

아폴로 클라이언트를 사용하면서 가장 많이 사용하는 훅은 useQuery일 것이다.

선언한 graphql 규격에 맞춰, ApolloClient는 어떻게 데이터를 요청할까? 소스코드 흐름을 보며 따라가보자.

useQuery.ts

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/react/hooks/useQuery.ts

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/react/hooks/useQuery.ts#L155

function _useQuery<
  TData = any,
  TVariables extends OperationVariables = OperationVariables,
>(
  query: DocumentNode | TypedDocumentNode<TData, TVariables>,
  options: QueryHookOptions<NoInfer<TData>, NoInfer<TVariables>>
) {
  const { result, obsQueryFields } = useQueryInternals(query, options);
  return React.useMemo(
    () => ({ ...result, ...obsQueryFields }),
    [result, obsQueryFields]
  );
}

useQuery 훅은 _useQuery 구현체의 wrapper이고, _useQuery 구현체는 useQueryInternals의 반환값에 대한 메모이제이션임을 알 수 있다.

useQueryInternals

export function useQueryInternals<
  TData = any,
  TVariables extends OperationVariables = OperationVariables,
>(
  query: DocumentNode | TypedDocumentNode<TData, TVariables>,
  options: QueryHookOptions<NoInfer<TData>, NoInfer<TVariables>>
) {
  const client = useApolloClient(options.client);

  const renderPromises = React.useContext(getApolloContext()).renderPromises;
  const isSyncSSR = !!renderPromises;
  const disableNetworkFetches = client.disableNetworkFetches;
  const ssrAllowed = options.ssr !== false && !options.skip;
  const partialRefetch = options.partialRefetch;

  const makeWatchQueryOptions = createMakeWatchQueryOptions(
    client,
    query,
    options,
    isSyncSSR
  );

  const [{ observable, resultData }, onQueryExecuted] = useInternalState(
    client,
    query,
    options,
    renderPromises,
    makeWatchQueryOptions
  );

  const watchQueryOptions: Readonly<WatchQueryOptions<TVariables, TData>> =
    makeWatchQueryOptions(observable);

  useResubscribeIfNecessary<TData, TVariables>(
    resultData, // might get mutated during render
    observable, // might get mutated during render
    client,
    options,
    watchQueryOptions
  );

  const obsQueryFields = React.useMemo<
    Omit<ObservableQueryFields<TData, TVariables>, "variables">
  >(() => bindObservableMethods(observable), [observable]);

  useRegisterSSRObservable(observable, renderPromises, ssrAllowed);

  const result = useObservableSubscriptionResult<TData, TVariables>(
    resultData,
    observable,
    client,
    options,
    watchQueryOptions,
    disableNetworkFetches,
    partialRefetch,
    isSyncSSR,
    {
      onCompleted: options.onCompleted || noop,
      onError: options.onError || noop,
    }
  );

  return {
    result,
    obsQueryFields,
    observable,
    resultData,
    client,
    onQueryExecuted,
  };
}

여러 설정과 옵션이 얽혀 실제 요청이 어디서 되는지 명확하진 않지만, useObservableSubscriptionResult 훅을 먼저 살펴보자. onError, onCompleted 등의 콜백도 해당 훅으로 넘어가는 것을 볼 수 있다.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/react/hooks/useQuery.ts#L321

function useObservableSubscriptionResult<
  TData = any,
  TVariables extends OperationVariables = OperationVariables,
>(
  resultData: InternalResult<TData, TVariables>,
  observable: ObservableQuery<TData, TVariables>,
  client: ApolloClient<object>,
  options: QueryHookOptions<NoInfer<TData>, NoInfer<TVariables>>,
  watchQueryOptions: Readonly<WatchQueryOptions<TVariables, TData>>,
  disableNetworkFetches: boolean,
  partialRefetch: boolean | undefined,
  isSyncSSR: boolean,
  callbacks: {
    onCompleted: (data: TData) => void;
    onError: (error: ApolloError) => void;
  }
) {
  const callbackRef = React.useRef<Callbacks<TData>>(callbacks);
  React.useEffect(() => {
    // Make sure state.onCompleted and state.onError always reflect the latest
    // options.onCompleted and options.onError callbacks provided to useQuery,
    // since those functions are often recreated every time useQuery is called.
    // Like the forceUpdate method, the versions of these methods inherited from
    // InternalState.prototype are empty no-ops, but we can override them on the
    // base state object (without modifying the prototype).
    callbackRef.current = callbacks;
  });

  const resultOverride =
    (
      (isSyncSSR || disableNetworkFetches) &&
      options.ssr === false &&
      !options.skip
    ) ?
      // If SSR has been explicitly disabled, and this function has been called
      // on the server side, return the default loading state.
      ssrDisabledResult
    : options.skip || watchQueryOptions.fetchPolicy === "standby" ?
      // When skipping a query (ie. we're not querying for data but still want to
      // render children), make sure the `data` is cleared out and `loading` is
      // set to `false` (since we aren't loading anything).
      //
      // NOTE: We no longer think this is the correct behavior. Skipping should
      // not automatically set `data` to `undefined`, but instead leave the
      // previous data in place. In other words, skipping should not mandate that
      // previously received data is all of a sudden removed. Unfortunately,
      // changing this is breaking, so we'll have to wait until Apollo Client 4.0
      // to address this.
      skipStandbyResult
    : void 0;

  const previousData = resultData.previousData;
  const currentResultOverride = React.useMemo(
    () =>
      resultOverride &&
      toQueryResult(resultOverride, previousData, observable, client),
    [client, observable, resultOverride, previousData]
  );

  return useSyncExternalStore(
    React.useCallback(
      (handleStoreChange) => {
        // reference `disableNetworkFetches` here to ensure that the rules of hooks
        // keep it as a dependency of this effect, even though it's not used
        disableNetworkFetches;

        if (isSyncSSR) {
          return () => {};
        }

        const onNext = () => {
          const previousResult = resultData.current;
          // We use `getCurrentResult()` instead of the onNext argument because
          // the values differ slightly. Specifically, loading results will have
          // an empty object for data instead of `undefined` for some reason.
          const result = observable.getCurrentResult();
          // Make sure we're not attempting to re-render similar results
          if (
            previousResult &&
            previousResult.loading === result.loading &&
            previousResult.networkStatus === result.networkStatus &&
            equal(previousResult.data, result.data)
          ) {
            return;
          }

          setResult(
            result,
            resultData,
            observable,
            client,
            partialRefetch,
            handleStoreChange,
            callbackRef.current
          );
        };

        const onError = (error: Error) => {
          subscription.current.unsubscribe();
          subscription.current = observable.resubscribeAfterError(
            onNext,
            onError
          );

          if (!hasOwnProperty.call(error, "graphQLErrors")) {
            // The error is not a GraphQL error
            throw error;
          }

          const previousResult = resultData.current;
          if (
            !previousResult ||
            (previousResult && previousResult.loading) ||
            !equal(error, previousResult.error)
          ) {
            setResult(
              {
                data: (previousResult && previousResult.data) as TData,
                error: error as ApolloError,
                loading: false,
                networkStatus: NetworkStatus.error,
              },
              resultData,
              observable,
              client,
              partialRefetch,
              handleStoreChange,
              callbackRef.current
            );
          }
        };

        // TODO evaluate if we keep this in
        // React Compiler cannot handle scoped `let` access, but a mutable object
        // like this is fine.
        // was:
        // let subscription = observable.subscribe(onNext, onError);
        const subscription = { current: observable.subscribe(onNext, onError) };

        // Do the "unsubscribe" with a short delay.
        // This way, an existing subscription can be reused without an additional
        // request if "unsubscribe"  and "resubscribe" to the same ObservableQuery
        // happen in very fast succession.
        return () => {
          setTimeout(() => subscription.current.unsubscribe());
        };
      },

      [
        disableNetworkFetches,
        isSyncSSR,
        observable,
        resultData,
        partialRefetch,
        client,
      ]
    ),
    () =>
      currentResultOverride ||
      getCurrentResult(
        resultData,
        observable,
        callbackRef.current,
        partialRefetch,
        client
      ),
    () =>
      currentResultOverride ||
      getCurrentResult(
        resultData,
        observable,
        callbackRef.current,
        partialRefetch,
        client
      )
  );
}

뭔가 긴 코드가 나왔지만... 두려워 말고 한 부분씩 살펴보자.

  const callbackRef = React.useRef<Callbacks<TData>>(callbacks);
  React.useEffect(() => {
    // Make sure state.onCompleted and state.onError always reflect the latest
    // options.onCompleted and options.onError callbacks provided to useQuery,
    // since those functions are often recreated every time useQuery is called.
    // Like the forceUpdate method, the versions of these methods inherited from
    // InternalState.prototype are empty no-ops, but we can override them on the
    // base state object (without modifying the prototype).
    callbackRef.current = callbacks;
  });

전반적으로 주석도 친절하게 적혀있고, 패턴 자체도 생소하진 않아서 살펴보는게 어렵진 않다.

useRef로 onCompleted, onError 콜백을 callbackRef에 저장하고, 매 렌더링마다 callbackRef에 보관된 콜백들을 최신화하기 위해 deps가 없는 useEffect를 사용했다.

onError, onCompleted로 주입받은 콜백을 최신화 시켜주지 않으면 해당 콜백에서 이전 상태를 참조하고 있는 경우 예상치 못한 사이드 이펙트가 발생할 수 있다. 해당 코드를 보니 불현듯 useEvent RFC가 생각이 난다.

그 다음 resultOverride ~ currentResultOverride 코드는 생략. 살짝 보자면 ssr 여부, skip 여부 등에 따라 기본 반환 데이터의 타입을 덮어씌우는 코드로 보인다.

클라이막스인 반환부의 useSyncExternalStore + useCallback 코드로 넘어가자.

  return useSyncExternalStore(
    React.useCallback(
      (handleStoreChange) => {
        // reference `disableNetworkFetches` here to ensure that the rules of hooks
        // keep it as a dependency of this effect, even though it's not used
        disableNetworkFetches;

        if (isSyncSSR) {
          return () => {};
        }
        // ...

뜬금없이 disableNetworkFetches 를 적어두는 재미있는 코드가 보인다. 호출도 아니고, 사용도 아니고, 할당도 아닌 말 그대로 참조만 한다. 주석을 보니 disableNetworkFetches의 단순 참조로 해당 훅이 disableNetworkFetches에 대한 의존성을 가지는 것을 강제하는 코드라고 한다.

만약 훅의 컨텍스트가 disableNetworkFetches를 참조할 수 있는 범위를 벗어나게 되면 참조 에러를 발생시키려는 의도로 보인다! 재미있고 해키한 구현이다. 만약 useCallback으로 선언된 해당 함수가 현재 컨텍스트에 바인딩 되지 않았다면 에러가 날 수도? 근데 이게 어떤 상황에서 발생하는 것인지 유즈케이스까지는 리뷰 코멘트를 봐도 알기가 어려웠다…

해당 변경사항에 대한 리뷰 코멘트
https://github.com/apollographql/apollo-client/pull/11869#discussion_r1664889946

아래로 내려가서 onNext 콜백 선언부를 보자.

        const onNext = () => {
          const previousResult = resultData.current;
          // We use `getCurrentResult()` instead of the onNext argument because
          // the values differ slightly. Specifically, loading results will have
          // an empty object for data instead of `undefined` for some reason.
          const result = observable.getCurrentResult();
          // Make sure we're not attempting to re-render similar results
          if (
            previousResult &&
            previousResult.loading === result.loading &&
            previousResult.networkStatus === result.networkStatus &&
            equal(previousResult.data, result.data)
          ) {
            return;
          }

          setResult(
            result,
            resultData,
            observable,
            client,
            partialRefetch,
            handleStoreChange,
            callbackRef.current
          );
        };

onNext 메소드의 이름을 정확한 컨텍스트에서 이해하려면 옵저버 패턴과 Observable 객체에 대한 이해가 필요하다. 간단하게 말하면 옵저버 패턴은 공급자(Provider or Observable)가 관찰자들(Observers)에게 알림을 보내는 디자인 패턴이라고 할 수 있는데, 관찰자들은 onNext, onError, onComplete 등의 이벤트 수신 콜백 메소드를 구현해서 제공되는 이벤트에 대한 처리를 어떻게 할 지 선언한다. 즉, 이 맥락에서 onNext 메소드는 쿼리의 응답 따위를 수신한 상황이라고 할 수 있다.

이전에 이미 가져온 결과가 있고, 이전 결과와 현재 상태의 로딩이 같으면서, 네트워크 status도 동일하고, 그 결과까지 같다면 아무것도 하지 않고 return을 해준다. 렌더링이 추가적으로 필요하지 않은 상황이라고 간주하는 것으로 보인다.

그 외의 경우에는 setResult 를 호출해서 현재의 결과를 저장하는 것으로 보이는데, setResult 구현은 다음과 같다.

function setResult<TData, TVariables extends OperationVariables>(
  nextResult: ApolloQueryResult<TData>,
  resultData: InternalResult<TData, TVariables>,
  observable: ObservableQuery<TData, TVariables>,
  client: ApolloClient<object>,
  partialRefetch: boolean | undefined,
  forceUpdate: () => void,
  callbacks: Callbacks<TData>
) {
  const previousResult = resultData.current;
  if (previousResult && previousResult.data) {
    resultData.previousData = previousResult.data;
  }

  if (!nextResult.error && isNonEmptyArray(nextResult.errors)) {
    // Until a set naming convention for networkError and graphQLErrors is
    // decided upon, we map errors (graphQLErrors) to the error options.
    // TODO: Is it possible for both result.error and result.errors to be
    // defined here?
    nextResult.error = new ApolloError({ graphQLErrors: nextResult.errors });
  }

  resultData.current = toQueryResult(
    unsafeHandlePartialRefetch(nextResult, observable, partialRefetch),
    resultData.previousData,
    observable,
    client
  );
  // Calling state.setResult always triggers an update, though some call sites
  // perform additional equality checks before committing to an update.
  forceUpdate();
  handleErrorOrCompleted(nextResult, previousResult?.networkStatus, callbacks);
}

현재의 응답 데이터를 internalStore의 previousData로 저장한 후, 현재 응답에 에러가 있다면 ApolloError 객체를 생성하여 error 필드에 넣어준다. 이 에러는 handleErrorOrCompleted로 넘겨서 처리된다.

forceUpdate() 는 setResult 호출시 전달된 handleStoreChange 메소드이다. 해당 메소드는 useSyncExternalStore의 첫 번째 인자로 넘긴 useCallback 함수의 인자에 해당하는 함수인데, 코드로 보면 헷갈리지만 useSyncExternalStore의 시그니처를 보면 쉽게 이해가 가능하다.

    export function useSyncExternalStore<Snapshot>(
        subscribe: (onStoreChange: () => void) => () => void,
        getSnapshot: () => Snapshot,
        getServerSnapshot?: () => Snapshot,
    ): Snapshot;

바로 저 onStoreChange 부분이 handleStoreChange 라는 이름으로, 그리고 forceUpdate 라는 이름으로 전달된 부분이다.

useSyncExternalStore는 subscribe 함수를 통해 전달한 onStoreChange 를 호출할 때, Snapshot 간의 비교를 통해 렌더링 여부를 결정하게 되니 렌더링을 트리거하는 역할을 한다고 볼 수 있겠다. 그러니 엄밀히 말하면 반환된 Snapshot에 대한 동등성 비교 이후 렌더링 여부를 리액트에서 결정하는 셈이니 forceUpdate는 아니다.

잠깐 밖으로 새서 handleErrorOrCompleted도 살펴보자.

function handleErrorOrCompleted<TData>(
  result: ApolloQueryResult<TData>,
  previousNetworkStatus: NetworkStatus | undefined,
  callbacks: Callbacks<TData>
) {
  if (!result.loading) {
    const error = toApolloError(result);

    // wait a tick in case we are in the middle of rendering a component
    Promise.resolve()
      .then(() => {
        if (error) {
          callbacks.onError(error);
        } else if (
          result.data &&
          previousNetworkStatus !== result.networkStatus &&
          result.networkStatus === NetworkStatus.ready
        ) {
          callbacks.onCompleted(result.data);
        }
      })
      .catch((error) => {
        invariant.warn(error);
      });
  }
}

컴포넌트 렌더 중 handleErrorOrCompleted 메소드가 호출될 경우, 바로 콜백들을 호출하지 않고 렌더링을 기다리기 위해 한 틱을 보내는 Promise.resolve()를 사용해준 부분이 흥미롭다.

https://github.com/apollographql/apollo-client/pull/9801

Delay execution of callback functions to fix React errors by dylanwulf · Pull Request #9801 · apollographql/apollo-client

As described in #9794, calling a setState function (or dispatching a redux action) from inside of onCompleted will sometimes cause React errors to be printed to the console. This appears to be due ...

github.com

다시 useObserverbleSubscriptionResult 훅으로 돌아와 이어서 살펴보자.

        const onError = (error: Error) => {
          subscription.current.unsubscribe();
          subscription.current = observable.resubscribeAfterError(
            onNext,
            onError
          );

          if (!hasOwnProperty.call(error, "graphQLErrors")) {
            // The error is not a GraphQL error
            throw error;
          }

          const previousResult = resultData.current;
          if (
            !previousResult ||
            (previousResult && previousResult.loading) ||
            !equal(error, previousResult.error)
          ) {
            setResult(
              {
                data: (previousResult && previousResult.data) as TData,
                error: error as ApolloError,
                loading: false,
                networkStatus: NetworkStatus.error,
              },
              resultData,
              observable,
              client,
              partialRefetch,
              handleStoreChange,
              callbackRef.current
            );
          }
        };

onError에 대한 콜백이 보인다. 좀 전에 onNext 내부의 setResult에서도 에러에 대한 처리를 하고 onError 콜백을 실행했던 것 같은데... onNext에서 받았던 result 내부의 error와 onError 콜백을 통해 받는 error의 차이는 뭘까?

일단 에러가 발생하면 subscription을 끊어주고, resubscribeAfterError 메소드를 통해 재구독을 해주는 모습이 보인다. resubscribeAfterError 내부 구현을 보니 마지막 데이터를 지우고 새로 구독을 하는 단순한 동작이다.

Graphql에러가 아닌 경우에는 throw error를 하는걸 보니 GraphqlError인 경우에 onError 콜백이 실행되는 것인지? 의심을 해본다. 다시 한 번 렌더링이 필요한지 확인하는 로직이 있고(여기서는 onNext와 달리 AND 연산자가 아니라 OR 연산자를 사용하는데 단순 가독성의 이유인지?) 마찬가지로 setResult를 통해 렌더링을 트리거한다.

바로 아랫 부분을 추가로 살펴보면

        // TODO evaluate if we keep this in
        // React Compiler cannot handle scoped `let` access, but a mutable object
        // like this is fine.
        // was:
        // let subscription = observable.subscribe(onNext, onError);
        const subscription = { current: observable.subscribe(onNext, onError) };

        // Do the "unsubscribe" with a short delay.
        // This way, an existing subscription can be reused without an additional
        // request if "unsubscribe"  and "resubscribe" to the same ObservableQuery
        // happen in very fast succession.
        return () => {
          setTimeout(() => subscription.current.unsubscribe());
        };

subscription에 대한 컴파일러의 평가 문제로 current 객체로 바꾼 부분의 확인이 필요하다…는 주석이 있고, subscribe 함수의 반환 함수인 구독 해제 함수를 setTimeout으로 감싸두었다.

무슨 말인지 살펴보니, 일부러 짧은 지연시간을 두어 '구독 취소 → 재구독 → 구독취소' 와 같이 짧은 간격으로 구독 취소와 재구독 이벤트가 발생하는 경우, 구독 취소를 지연시켜 곧 제거될 subscription 이지만 아직 제거되지 않은 subscription을 재사용하기 위함으로 보인다.

정확한 유즈케이스는 모르겠지만 subscription 구독과 동시에 불필요한 네트워크 요청이 발생할 수 있으니 이러한 부분을 방지하기 위한 것 같다.

getSnapShot 부분에 해당하는 코드는 간단하다.

    () =>
      currentResultOverride ||
      getCurrentResult(
        resultData,
        observable,
        callbackRef.current,
        partialRefetch,
        client
      ),

특정 조건에 오버라이드 되어야 하는 응답이 있는게 아니라면 getCurrentResult를 사용해서 현재 상태를 가져온다. getCurrentResult는 resultData.current 와 같다.

여기까지의 대략적인 흐름을 정리해보면 다음과 같다.

useQuery 훅은 _useQuery 구현체의 wrapper이고, _useQuery 구현체는 useQueryInternals의 반환값에 대한 메모이제이션이다.
useQueryInternals 에서 의심스러운 부분들을 보다보니 쿼리 결과를 반환하는 useObservableSubscriptionResult 훅이 있었다.
useObservableSubscriptionResult 훅을 보니 useSyncExternalStore 훅을 사용해서 쿼리 결과에 대한 구독과 onNext, onError 콜백을 가진 옵저버 구현체로 이어진다.
결국 요청을 보내는 곳을 찾으려면 observable을 구독하는 곳이 아니라 만드는 곳을 봐야 한다.

다시 생각해보니 이미 useObservableSubscriptionResult 라는 훅 이름 자체가 구독을 관리하고 결과를 통해 콜백 호출과 상태 업데이트를 하는 곳이라는 이름이 명확하다! 그렇다면 실질적인 요청을 보내는 곳은 인자로 전달되는 observable 객체를 만드는 부분일 것이다. 이를 명심하고 다시 한 번 useQueryInternals 훅을 살펴보니 의심스러운 곳이 보인다.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/react/hooks/useQuery.ts#L271

  const [{ observable, resultData }, onQueryExecuted] = useInternalState(
    client,
    query,
    options,
    renderPromises,
    makeWatchQueryOptions
  );

useInternalState 라는 훅의 이름만 대충 보고 내부 상태만 관리하는 줄 알고 넘겼는데 자세히 보니 반환값에 observable이 있다. 세부 구현을 살펴보니 훅 구현체에서 observable을 선언해주는 곳을 확인 할 수 있다!

     observable:
        // See if there is an existing observable that was used to fetch the same
        // data and if so, use it instead since it will contain the proper queryId
        // to fetch the result set. This is used during SSR.
        (renderPromises &&
          renderPromises.getSSRObservable(makeWatchQueryOptions())) ||
        client.watchQuery(
          getObsQueryOptions(void 0, client, options, makeWatchQueryOptions())
        ),

SSR 환경에서 renderPromises에 이미 보관된 SSR Observable이 있는지 확인하고, 있다면 해당 Observable을 반환한다. 클라이언트 기준으로는 client.watchQuery 를 호출하면 Observable이 반환되는 모양이다.

ApollocCient.watchQuery는 QueryManager의 watchQuery의 wrapper이다.

https://github.com/apollographql/apollo-client/v3.11.8//main/src/core/QueryManager.ts#L723

  public watchQuery<
    T,
    TVariables extends OperationVariables = OperationVariables,
  >(options: WatchQueryOptions<TVariables, T>): ObservableQuery<T, TVariables> {
    const query = this.transform(options.query);

    // assign variable default values if supplied
    // NOTE: We don't modify options.query here with the transformed query to
    // ensure observable.options.query is set to the raw untransformed query.
    options = {
      ...options,
      variables: this.getVariables(query, options.variables) as TVariables,
    };

    if (typeof options.notifyOnNetworkStatusChange === "undefined") {
      options.notifyOnNetworkStatusChange = false;
    }

    const queryInfo = new QueryInfo(this);
    const observable = new ObservableQuery<T, TVariables>({
      queryManager: this,
      queryInfo,
      options,
    });
    observable["lastQuery"] = query;

    this.queries.set(observable.queryId, queryInfo);

    // We give queryInfo the transformed query to ensure the first cache diff
    // uses the transformed query instead of the raw query
    queryInfo.init({
      document: query,
      observableQuery: observable,
      variables: observable.variables,
    });

    return observable;
  }

드디어 observable을 실질적으로 만들어주는 코드를 만났다!

    const observable = new ObservableQuery<T, TVariables>({
      queryManager: this,
      queryInfo,
      options,
    });

생성자 코드를 빠르게 살펴보면...

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/ObservableQuery.ts#L111

  constructor({
    queryManager,
    queryInfo,
    options,
  }: {
    queryManager: QueryManager<any>;
    queryInfo: QueryInfo;
    options: WatchQueryOptions<TVariables, TData>;
  }) {
    super((observer: Observer<ApolloQueryResult<TData>>) => {
      // Zen Observable has its own error function, so in order to log correctly
      // we need to provide a custom error callback.
      try {
        var subObserver = (observer as any)._subscription._observer;
        if (subObserver && !subObserver.error) {
          subObserver.error = defaultSubscriptionObserverErrorCallback;
        }
      } catch {}

      const first = !this.observers.size;
      this.observers.add(observer);

      // Deliver most recent error or result.
      const last = this.last;
      if (last && last.error) {
        observer.error && observer.error(last.error);
      } else if (last && last.result) {
        observer.next && observer.next(last.result);
      }

      // Initiate observation of this query if it hasn't been reported to
      // the QueryManager yet.
      if (first) {
        // Blindly catching here prevents unhandled promise rejections,
        // and is safe because the ObservableQuery handles this error with
        // this.observer.error, so we're not just swallowing the error by
        // ignoring it here.
        this.reobserve().catch(() => {});
      }

      return () => {
        if (this.observers.delete(observer) && !this.observers.size) {
          this.tearDownQuery();
        }
      };
    });

ObservableQuery 객체는 zen-observable 구현체를 상속받아 구현되어 있는데, 그에 따른 처리들이 되어 있는 것을 볼 수 있다.

아래로 좀 내려오면...

      const first = !this.observers.size;
      //...

      // Initiate observation of this query if it hasn't been reported to
      // the QueryManager yet.
      if (first) {
        // Blindly catching here prevents unhandled promise rejections,
        // and is safe because the ObservableQuery handles this error with
        // this.observer.error, so we're not just swallowing the error by
        // ignoring it here.
        this.reobserve().catch(() => {});
      }

observable을 구독하는 observers가 아직 없다는 것은 해당 쿼리를 이제 막 구독하기 시작했다는 의미와 동일하다. 이 경우에 this.reobserve 가 호출된다. catch에 대한 처리가 없는것처럼 보이지만 안심하라는 주석이 있다.

reobserve 메소드는 reobserveAsConcast 의 wrapper이다. as TODO 타입 단언이 재미있었다.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/ObservableQuery.ts#L1005-L1011

Concast라는 용어가 생소했는데 Concast 객체 선언부에 주석으로 설명이 잘 되어 있었다.
https://github.com/apollographql/apollo-client/blob/v3.11.8/src/utilities/observables/Concast.ts#L22-L50

Concast<T> 옵저버블은 주어진 소스들을 하나의 겹치지 않는 T 시퀀스로 연결하고, 자동으로 모든 프로미스를 풀어내며, 그 시퀀스의 T 요소들을 여러 구독자에게 방송합니다. 이 과정에서 중간 옵저버블 래퍼 객체를 많이 생성하지 않습니다.

Concast에는 여러 옵저버가 구독할 수 있지만, 각 소스 옵저버블은 최대 한 번의 구독 호출만 보장받으며, 그 결과는 모든 옵저버에게 멀티캐스트됩니다.

이 Concast는 모든 다음/오류 메시지를 this.observers에 방송하는 것 외에도, 가장 최근의 메시지를 this.latest를 사용해 저장합니다. 따라서 새로운 옵저버는 과거에 전달된 메시지라도 즉시 최신 메시지를 받을 수 있습니다. 이 동작은 this.observers에 있는 모든 활성 옵저버가 동일한 최신 메시지를 받았음을 보장합니다.

이 최신 메시지 재생을 제외하고, Concast는 "핫" 옵저버블입니다. 이는 새로운 옵저버마다 과거의 결과를 처음부터 재생하지 않는다는 의미입니다.

기존의 RxJS 클래스를 사용할 수 있었을까요? Concast<T>는 BehaviorSubject<T>와 유사합니다. 왜냐하면 멀티캐스트되고 새로운 구독자에게 최신의 다음/오류 메시지를 다시 전달하기 때문입니다. Subject<T>와 달리, Concast<T>는 옵저버<T> 인터페이스를 노출하지 않습니다(this.handlers는 의도적으로 비공개입니다). Concast<T>는 연결된 소스에서 입력을 받기 때문입니다. 만약 우리가 RxJS로 전환하게 된다면 그들의 코드를 재사용하는 데 가치가 있을 수 있지만, 현재로서는 Subject 구현을 포함하지 않는 zen-observable을 사용하고 있습니다.

reobserveAsConcast 를 살펴보자.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/ObservableQuery.ts#L895

const { concast, fromLink } = this.fetch(options, newNetworkStatus, query);

뭔가 요청으로 보이는 fetch 코드가 reobserveAsConcast 함수 내부에서 보이는데...? 호출 결과로concast, fromLink 를 반환한다.

fetch 메소드는 queryManager의 fetchConcastWithInfo 함수를 호출하는데

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/QueryManager.ts#L1242

해당 함수에서는 앞서 살펴본 Concast 객체를 생성하고 fetchQueryByPolicy 를 호출해주는 역할을 하고 있다.

대체 실제 fetch는 언제쯤 하는걸까? fetchQueryByPolicy 구현체를 퀵하게 보니, 여러 fetchPolicy에 따른 실질적인 요청부분을 볼 수 있었다. (그 와중에 switch 최상단 default: 로 cache-first를 기본 설정으로 세팅하는 디테일)

  private fetchQueryByPolicy<TData, TVars extends OperationVariables>(
    queryInfo: QueryInfo,
    {
      query,
      variables,
//...
    switch (fetchPolicy) {
      default:
      case "cache-first": {
        const diff = readCache();

        if (diff.complete) {
          return {
            fromLink: false,
            sources: [resultsFromCache(diff, queryInfo.markReady())],
          };
        }

        if (returnPartialData || shouldNotify) {
          return {
            fromLink: true,
            sources: [resultsFromCache(diff), resultsFromLink()],
          };
        }

        return { fromLink: true, sources: [resultsFromLink()] };
      }

      case "cache-and-network": {
        const diff = readCache();

        if (diff.complete || returnPartialData || shouldNotify) {
          return {
            fromLink: true,
            sources: [resultsFromCache(diff), resultsFromLink()],
          };
        }

        return { fromLink: true, sources: [resultsFromLink()] };
      }

이름을 보니 느낌이 온다.

resultsFromCache 는 캐시에서 쿼리 결과를 조회하는 동작으로 보이고, resultsFromLink 는 실질적인 요청을 통해서 데이터를 가져오는 것으로 보인다. resultsFromLink는 QueryManager의 getResultsFromLink로 이어진다.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/QueryManager.ts#L1154

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/core/QueryManager.ts#L1169-L1183

   return asyncMap(
      this.getObservableFromLink(
        linkDocument,
        options.context,
        options.variables
      ),

      (result) => {
        const graphQLErrors = getGraphQLErrorsFromResult(result);
        const hasErrors = graphQLErrors.length > 0;
        const { errorPolicy } = options;

        // If we interrupted this request by calling getResultsFromLink again
        // with the same QueryInfo object, we ignore the old results.
        if (requestId >= queryInfo.lastRequestId) {

asyncMap의 첫번째 인자는 observable, 두 번째 인자는 map function 으로, Observable의 결과를 맵핑하는 함수이니 사실상 콜백이라고 러프하게 생각해도 된다. 그렇다면 getObservableFromLink를 살펴보자.

https://github.com/apollographql/apollo-client/blob/v3.11.8 /src/core/QueryManager.ts#L1082

뭔가 요청단의 코드와 점점 가까워진다고 느껴진다.

    const { serverQuery, clientQuery } = this.getDocumentInfo(query);
    if (serverQuery) {
      const { inFlightLinkObservables, link } = this;

      const operation = {
        query: serverQuery,
        variables,
        operationName: getOperationName(serverQuery) || void 0,
        context: this.prepareContext({
          ...context,
          forceFetch: !deduplication,
        }),
        extensions,
      };

슬슬 실제 요청에 필요한 document와 operationName 등을 가져오기 시작한다.

import { execute } from "../link/core/index.js";
//...
const concast = new Concast([
  execute(link, operation) as Observable<FetchResult<T>>,
]);

execute! 뭔가 의미심장한 메소드 이름이 등장했다 .심지어 link에 대한 의존성을 가지고 있으니 기대가 된다.

https://github.com/apollographql/apollo-client/blob/v3.11.8 /src/link/core/ApolloLink.ts#L65-L77

  public static execute(
    link: ApolloLink,
    operation: GraphQLRequest
  ): Observable<FetchResult> {
    return (
      link.request(
        createOperation(
          operation.context,
          transformOperation(validateOperation(operation))
        )
      ) || Observable.of()
    );
  }
  //...
  public request(
    operation: Operation,
    forward?: NextLink
  ): Observable<FetchResult> | null {
    throw newInvariantError("request is not implemented");
  }

드디어 도착했다…!

ApolloLink의 request 인자로 query 오퍼레이션을 payload 형태로 변환해주는 프로세스가 있고, 실질적인 요청은 이 곳에서 이뤄진다.

요청 코드에서 fetch api 혹은 axios, XMLHttpRequest 등을 찾을 필요는 없다. 아폴로 클라이언트는 http 요청에 필요한 구현체들을 자유롭게 주입할 수 있는 구조로 되어 있으며 이러한 구현체는 아폴로 클라이언트 초기화시 설정하는 httpLink 구성에서 자유롭게 정의할 수 있기 때문이다.

물론 이러한 부분을 쉽게 하기 위해 ApolloLink를 상속한 HttpLink와 같은 객체 프리셋들도 이미 제공하고있다.

예시 코드

import fetch from 'cross-fetch';
//...

const httpLink = new HttpLink({ uri: ENV.APOLLO_API_END_POINT, fetch });

const authLink = setContext((_, { headers }) => {
	//...
});

const link = ApolloLink.from([authLink, httpLink]);

//...

export const initializeApollo = () => {
  return new ApolloClient({
    link,
    cache,
    //...

HttpLink는 createHttpLink를 통해 생성되는데,

https://github.com/apollographql/apollo-client/blob/v3.11.8 /src/link/http/HttpLink.ts

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/link/http/createHttpLink.ts#L29-L48

const backupFetch = maybe(() => fetch);

export const createHttpLink = (linkOptions: HttpOptions = {}) => {
  let {
    uri = "/graphql",
    // use default global fetch if nothing passed in
    fetch: preferredFetch,
    print = defaultPrinter,
    includeExtensions,
    preserveHeaderCase,
    useGETForQueries,
    includeUnusedVariables = false,
    ...requestOptions
  } = linkOptions;

  if (__DEV__) {
    // Make sure at least one of preferredFetch, window.fetch, or backupFetch is
    // defined, so requests won't fail at runtime.
    checkFetcher(preferredFetch || backupFetch);
  }

httpLink 생성시 fetch를 명시적으로 주입하지 않으면 각 환경의 backupFetch를 사용한다.

https://github.com/apollographql/apollo-client/blob/v3.11.8/src/link/http/createHttpLink.ts#L179-L216

    return new Observable((observer) => {
      // Prefer linkOptions.fetch (preferredFetch) if provided, and otherwise
      // fall back to the *current* global window.fetch function (see issue
      // #7832), or (if all else fails) the backupFetch function we saved when
      // this module was first evaluated. This last option protects against the
      // removal of window.fetch, which is unlikely but not impossible.
      const currentFetch = preferredFetch || maybe(() => fetch) || backupFetch;

      const observerNext = observer.next.bind(observer);
      currentFetch!(chosenURI, options)
        .then((response) => {
          operation.setContext({ response });
          const ctype = response.headers?.get("content-type");

          if (ctype !== null && /^multipart\/mixed/i.test(ctype)) {
            return readMultipartBody(response, observerNext);
          } else {
            return parseAndCheckHttpResponse(operation)(response).then(
              observerNext
            );
          }
        })
        .then(() => {
          controller = undefined;
          observer.complete();
        })
        .catch((err) => {
          controller = undefined;
          handleError(err, observer);
        });

      return () => {
        // XXX support canceling this request
        // https://developers.google.com/web/updates/2017/09/abortable-fetch
        if (controller) controller.abort();
      };
    });
  });

마침내 실질적인 fetch 요청을 보내는 곳을 발견했다. currentFetch의 평가에 대해 재미있는 부분이 있는데,

linkOptions.fetch(preferredFetch)가 제공된 경우 이를 사용하고, 그렇지 않으면 현재 전역 window.fetch 함수를 사용합니다(문제 #7832 참조). 만약 이것도 불가능하다면, 모듈이 처음 평가될 때 저장된 backupFetch 함수를 사용합니다. 이 마지막 옵션은 window.fetch가 제거되는 상황에 대비한 것으로, 가능성은 낮지만 완전히 배제할 수는 없습니다.

fallback으로 전역 window.fetch를 사용하는 것은 놀랍지 않았는데, window.fetch가 없어지는 상황까지 고려하여 backup용으로 모듈 평가 시점의 backupFetch를 가져와서 사용하는 점이 재미있었다. currentFetch 를 평가하는 시점의 전역 fetch를 살펴보고, 만약 존재하지 않는다면 backupFetch가 선언되어 해당 코드를 브라우저에서 읽고 평가하는 순간에 캡쳐된 fetch를 참조하는 세심함이 있었다.

이렇게 했을 때, 설령 `createHttpLink` 호출 시점의 전역 fetch가 어떠한 이유로든 전역 참조에서 제거되더라도 평가 시점에 참조한 fetch 메소드를 사용할 수 있다.

소감

개인적으로 ApolloClient 코드들이 읽기 쉬운 편이라고 생각하는데, 그 중에서도 쉬운 useQuery를 골랐음에도 참 읽을게 많아 후반부엔 좀 지치는 감이 있었다. 그래도 전체적인 흐름이나 Observable 패턴의 구현체들을 봐서 새로웠고, Concast 같은 새로운 개념들도 알게 되어 좋았다.

참고

useQuery의 인자는 왜 객체 형태가 아닌걸까?

https://github.com/apollographql/apollo-client/pull/11869#discussion_r1665511736

refactor useQuery to not use an internal class by phryneas · Pull Request #11869 · apollographql/apollo-client

After #11890, I'm fairly confident in this now. This needs to be reviewed commit-by commit, although a bunch of merges added additional commits at the start and end - I'm really sorry for t...

github.com

근황

눅눅한 피부 — Sat, 12 Oct 2024 21:31:12 +0900

0. 시간이 어떻게 가는지 모르겠다... 눈 깜빡이면 한 달 단위로 지나는 것 같다.

1. 최근까지 진행하던 영어 과외를 그만뒀다. 졸업이라기엔 뭐하지만... 과외로 얻을 것들을 충분히 많이 얻은 것 같아 Next step으로 가보려고 한다.

2. 회사에서 오픈소스 소스코드 톺아보기 스터디를 진행중인데 재미있는 포인트가 많아서 좋았다. lodash 코어 로직이라던지 vercel/next 레포지토리 세팅 파일에서의 인사이트라던지...

3. 오픈소스는 디스코드 채널과 컨트리뷰터들의 과도한(?) 열정으로 내 몸에 부하가 걸려 잠시 쉬어가고 있다. 최근에는 스위스, 폴란드에서 기여해주시는 개발자분들과 팀 미팅도 가졌다. 영어로 진행해서 두근두근 했는데 나름 잘 해냈다...! 그리고 왠지 2k가 넘는 별을 받고 나니 다른 오픈소스를 해보고 싶다는 욕심도 생긴다.

https://github.com/Jonghakseo/chrome-extension-boilerplate-react-vite

GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

Chrome Extension Boilerplate with React + Vite + Typescript - Jonghakseo/chrome-extension-boilerplate-react-vite

github.com

4. react-code-finder 사용자가 소리없이 500명을 넘었다. 은근슬쩍 많이 쓰는 이유를 잘 모르겠지만... 오늘 생각난김에 기능 추가(props 조회)도 해놨다.

https://chromewebstore.google.com/detail/react-code-finder/bbidpgoneibefablhfcnaennjkfbflmk

React code finder - Chrome 웹 스토어

Chrome extension for React Developer

chromewebstore.google.com

5. 회사에서 CDN 캐싱 + SWR 적용 등 파트 KR 개선을 위한 작업들의 성과가 나름 눈부셔서 기분이가 좋다.

6. 7월에는 조직문화 관련된 간단한 소개?를 해달라는 요청을 받아 타 회사에 방문해서 개발팀 조직문화를 소개하는 자리를 가지기도 했는데, 좋은 조직 문화란 무엇인지 돌아볼 수 있는 좋은 기회였다.

전반적으로 심신이 안정되어 있다. 11월에 이사라는 나름 큰 이슈가 있어서 그것만 잘 넘기면 올해는 선방한게 아닐까 싶다.

올해 회고는 언제 또 쓰지?

코드 리뷰의 원칙

눅눅한 피부 — Wed, 31 Jul 2024 02:11:36 +0900

https://soojin.ro/review/standard

개발팀 문화

눅눅한 피부 — Sat, 27 Jul 2024 00:30:34 +0900

많은 조직에서는 좋은 개발팀을 갖고 싶어 한다.

좋은 개발팀이라는 것은 개발자들의 생산성이 높고 리텐션이 유지되며 팀 자체가 성장하고 있어 조직의 문제 해결 능력에 지속적으로 큰 기여를 할 수 있는 팀을 말한다. 이런 팀은 외부로부터의 인재 유입도 비교적 수월하며 새로운 아이디어와 혁신에도 비교적 열려있다.

좋은 개발팀을 갖고 싶은 조직은 좋은 개발 문화를 통해 현재의 팀을 좋은 개발팀으로 만들고 유지하길 원한다. Stackoverflow의 서베이나 개발자들을 대상으로 한 여러 조사에서도 나타나듯 개발팀의 문화는 개발자들이 해당 조직에 머무는 이유 중 큰 비중을 차지한다.

좋은 개발 문화란 무엇일까?

모든 조직에 들어맞는 법칙은 없겠지만 일반적으로는 다음과 같은 것들이 물망에 오른다.

1. 서로에 대한 신뢰

2. 지속적인 학습

3. 실수에 관대하고 실수를 통한 성장을 할 수 있는 환경

4. 자기 주도적인 업무

자 좋다. 이제 매니저의 관점에서 위 4가지를 만들기 위해 노력해 보자.

'서로에 대한 신뢰? 이건 시간이 해결해 줄 일이니까 패스.'

'지속적인 학습? 다음 주까지 팀원들에게 '모던 자바스크립트 Deep Dive'를 읽어오라고 해야겠다.'

'실수에 관대하고 실수를 통한 성장을 할 수 있는 환경? 이제 버그 낸 사람한테 조금 덜 뭐라고 해야겠다.'

'자기 주도적인 업무? 이건 당연히 알아서 잘해야지.'

웃자고 적어놓은 내용이지만 실제로 위 항목들을 보고 실제로 비슷하게 생각하는 사람이 있을까 두렵다.

위 항목들은 누군가 시켜서 되는 일이 아니다.

각 팀원이 본인의 업무에 대해 책임감 있는 모습을 보인다면 상호 간의 신뢰가 쌓일 것이고 성장하고자 하는 욕구가 있다면 지속적인 학습을 위해 자발적으로 스터디 그룹 등을 만들 것이며 실수에 관대하고 실수를 통한 성장을 할 수 있는 환경은 코드 리뷰, 테스트 코드, 건강한 장애 부검과 같은 건설적인 프로세스를 통해 갖춰지는 것이며 자기 주도적인 업무 역시 본인의 성장 욕구와 인정 욕구, 산출물에 대한 자부심 등을 바탕으로 스스로 해 나가는 것이다.

조직/매니징의 관점에서는 이러한 문화를 조성하기 위해 어떤 일을 할 수 있을까?

가장 중요하고 또 중요한 첫 번째는 바로 '채용'이다. 실력 있고 책임감 있으며 성장 욕구가 있는 개발자를 채용하는 것이 좋은 개발 문화를 만드는 데 기여하는 비중은 90%가 넘는다고 생각한다. 그다음으로 해볼 수 있는 것들은 앞서 말한 프로세스의 도입, 그리고 그러한 프로세스를 도입하는데 필요한 지원일 것이다. 스터디 그룹을 만든다고 하면 리소스에 대한 지원 등을 해주고 업무에 대한 새로운 툴 도입이나 변화에 대한 시도를 응원해 주는 것이다.

'공부는 좋습니다. 그런데 업무 시간에는 좀... 형평성이...' 굳이 이런 이야기를 하며 기껏 잘 채용한 개발자들의 의욕을 꺾는 조직을 실제로 본 기억이 있다. 현명한 선택이 아니라고 생각한다.

물론 조직 내에서 개인으로서 비관적인 이야기와 부정적인 이야기들로 동료 개발자들의 의욕과 사기를 꺾는 사람들도 있다. 또한 발전 의지가 없고 실력이 낮아 동료 개발자들에게 부정적인 영향을 미치는 사람들도 있다. 이러한 사람들은 조직의 관점에서는 빠르게 털고 갈 수 있다면 털고 가는 게 좋다.

말은 쉽다. 현실은 뛰어난 개발자 한 둘, 비관적인 개발자 한 둘, 애매한 개발자 한 둘이 모여 개발팀이 만들어진다. 그리고 지금 저 사람을 내보내면 대체할 인력도 없다. 자, 이런 상황에서 당신이 매니저라면 어떤 것을 해볼 수 있을까?

첫 번째. 이러니 저러니 해도 인사가 만사다. 좋은 사람을 채용하기 위해 꾸준히 노력하고 발품을 팔아야 한다. 100점짜리 개발자를 데려올 생각은 하지 말자. 뚜렷한 장점이 있고 현재의 개발팀에 좋은 자극을 줄 수 있는 포인트가 있다면 적극적으로 고려해 보자.

두 번째. 조직 내에서의 건설적인 프로세스를 구축하기 위해 노력해야 한다. 코드 리뷰, 테스트 코드, 회고 문화, 장애 부검 등 소위 좋은 개발 문화를 만드는 데 도움이 된다고 알려진 것들은 시중에 널리고 널렸다. 현실적으로 조직에 도입할 수 있고 필요하다고 생각되는 것부터 하나씩 차근차근 도입해 보자. 이 과정에서의 반발이 있다면 최대한 점진적으로 도입해 보고 설득력이 부족하다면 본인의 신뢰자산을 레버리지로 사용하자. 끌어다 쓸 신뢰자산이 없다면 전적으로 본인의 책임이다.

세 번째. 비관적인 태도를 가진 팀원과 적극적으로 소통하자. 고민이 있다면 들어주고 개선이 필요하다고 생각하는 부분에 대해 그렇게 생각한 이유와 함께 솔직하게 피드백을 해야 한다.

네 번째. 본인이 목표로 하는 개발팀의 비전과 이상향에 대해서 끊임없이 구성원들에게 이야기해야 한다. 뛰어난 개발자들은 공감할 것이고 애매한 개발자들은 다소 귀찮아 할 수 있지만 그래도 맞는 방향이라고 생각할 것이다. 비관적인 개발자들은 투덜대다 조직을 떠나거나 적극적으로 합류(전향?)할 것이다.

개발자들이 행복하다고 좋은 개발팀은 아니지만 좋은 개발 문화를 구축하면 그 결과로 개발자들은 더 행복해져야 한다. 그것이 인류 보편적인 가치에 부합해서가 아니라 좋은 개발 문화로 개개인이 행복한 상태가 되어야 그것이 지속 가능하기 때문이다.

이런저런 사족이 길었지만 결국 돌고 돌아 제일 중요한 건 사람이다. 물질의 기본 단위가 원자이듯 조직은 그 조직을 구성하는 사람들의 구성에 따라 성질이 완전히 달라진다. 나는 '사람은 바꿀 수 없지만 스스로 바뀔 순 있다.'라고 생각한다. 사람을 바꾸려고 노력하기보다는 바뀔 수 있는 환경과 분위기를 제안하고 구축하는데 집중하는 것이 조직 관점에서도 개개인의 관점에서도 경제적인 선택일 것이다.

React에서의 Modal

눅눅한 피부 — Thu, 4 Jul 2024 21:53:50 +0900

리액트의 모달 컴포넌트는 다양한 방식으로 사용된다.

모달 렌더링에 대한 책임을 버튼 컴포넌트에 넘기는 방식. 모달의 열림/닫힘 상태를 버튼에서 관리하여 보일러 플레이트 코드를 줄이기 좋다. Props에 대한 타입 전달이 자연스러럽게 되는 장점도 있다.

<ModalControlButton Modal={ShareModal} modalProps={{ url }}>Share!</ModalControlButton>

모달의 열림/닫힘 상태를 제어하면서 모달 컴포넌트를 렌더링하는 방식. 가장 일반적인 방식이고 러닝커브가 없다.

const modal = useModal();
//...
<Button onClick={modal.open}>Share!</Button>
<ShareModal isOpen={modal.isOpen} close={modal.close} url={url} />

모달을 함수 호출 시점에 렌더링하는 방식. 호출부와 렌더링 코드가 붙어있어 응집도가 높은 편이다.

const { openModal } = useModal();

const handleClick = () => openModal(ShareModal, { url });
//...
<Button onClick={handleClick}>Share!</Button>

모달을 함수 호출 시점에 렌더링하고 JSX구조를 유지하는 방식. 위의 방식과 유사하다.

import modal from "@~";
//...
const handleClick = () => modal.open((isOpen, close) => <ShareModal isOpen={isOpen} close={close} url={{ url }} />, );
//...
<Button onClick={handleClick}>Share!</Button>

모달 구현체는 일반적으로 Portal을 사용하거나 전용 Provider를 통해 렌더링 위치를 제어한다.

`createRoot().render()`를 직접 호출해서 전용 FiberTree를 만들어 제어하는 방식도 가능하다.

이 중에서 개인적으로 편하게 사용하고 있는 ModalControlButton의 구현체를 살펴보자

import { FC, useCallback, useState } from 'react';
import { Button, type ButtonProps } from '@/compoents/Button';

type PropsFrom<TComponent> = TComponent extends FC<infer Props> ? Props : never;

type WithModalProps<ModalRenderer> = {} extends RemoveOptional<
  Omit<PropsFrom<ModalRenderer>, 'close'>
>
  ? { modalProps?: Omit<PropsFrom<ModalRenderer>, 'close' | 'isOpen'> }
  : { modalProps: Omit<PropsFrom<ModalRenderer>, 'close' | 'isOpen'> };

type ModalControlButtonProps<ModalRenderer> = {
  ModalRenderer: ModalRenderer;
} & WithModalProps<ModalRenderer> &
  Omit<ButtonProps, 'onClick'>;

export default function ModalControlButton<
  ModalRenderer extends FC<any & { close: () => unknown }>,
>({ ModalRenderer, children, modalProps, ...restProps }: ModalControlButtonProps<ModalRenderer>) {
  const [isOpen, setIsOpen] = useState<boolean>(false);

  const open = useCallback(() => {
    setIsOpen(true);
  }, []);

  const close = useCallback(() => {
    setIsOpen(false);
  }, []);

  return (
    <>
      <Button onClick={open} {...restProps}>
        {children}
      </Button>
      <ModalRenderer {...(modalProps as any)} isOpen={isOpen} close={close} />
    </>
  );
}

/**
 * 타입 T의 키 K를 조건부로 포함하는 맵 타입을 작성합니다.
 * {}가 타입 T에서 K 키를 가진 속성을 Pick한 것에 확장할 수 있는 경우 never를 반환하고, 그렇지 않으면 K를 반환합니다.
 * 결국 필수 속성만 K로 선정됩니다.
 */
type RequiredKeys<T> = {
  [K in keyof T]-?: {} extends Pick<T, K> ? never : K;
}[keyof T];

/**
 * 주어진 타입 T에서 선택적 속성을 제거한 새 타입을 생성합니다.
 * 필수 속성들로만 이루어진 타입을 반환합니다.
 */
type RemoveOptional<T> = Pick<T, RequiredKeys<T>>;

Shout out from Medium

눅눅한 피부 — Tue, 21 May 2024 14:47:58 +0900

Star 8.5K, 3.2K 녀석들... 딱 기다려라... 내가 간다....

https://tamfocus.medium.com/my-journey-to-the-best-chrome-extension-boilerplate-8b0ae65b95c1

My journey to the best Chrome Extension boilerplate

Introduction

tamfocus.medium.com

네이버 사다리와 함께 했던 워크숍 (3)

눅눅한 피부 — Thu, 28 Mar 2024 22:32:10 +0900

저번 편에서 사다리를 원하는 대로 그리기 위해 minified 된 js 파일을 파헤쳐봤다.

https://nookpi.tistory.com/198

이번 편에서는 기존 사다리 게임 js 파일을 내가 수정한 js 파일로 교체하는 방법에 대해 알아보자.

원래는 네이버 검색으로 노출되는 사다리 게임 페이지 자체를 클론코딩(...)하려고 했으나, 동료분의 조언으로 크롬 익스텐션을 통해 주입하는 방법으로 선회했다. 이 방법이 훨씬 간단할 뿐 아니라 눈치채기도 어렵다...!

유일한 단점이라면 익스텐션이 사전에 설치되어 있어야 한다는 점인데 어차피 클론코딩으로 제공하는 페이지 역시 동일한 이슈가 있기 때문에 망설일 이유는 없었다.

내가 누구? 크롬 익스텐션 보일러 플레이트 오너

GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

Chrome Extension Boilerplate with React + Vite + Typescript - Jonghakseo/chrome-extension-boilerplate-react-vite

github.com

바로 포크 후 익스텐션을 만들어보자.

유저가 보는 페이지에서 실행이 되어야 하기 때문에 실행 컨텍스는 콘텐츠 스크립트로 제한된다.

불필요한 다른 페이지들은 다 지우고, content 폴더만 남겨둔다.

1편 마지막에 파악했듯, 새로운 사다리 게임을 호출하기 위해서는 전역 객체인 window에 있는 require 메서드를 사용해야 한다. 콘텐츠 스크립트의 실행 환경은 "ISOLATED"와 "MAIN"으로 나눠지는데, 각 환경에서 접근 가능한 리소스의 범위가 다르다.

"ISOLATED" 환경에서는 chrome api에 접근이 가능하지만, 타 모듈에서 선언한 전역 객체 등에 접근할 수 없다.

반면, "MAIN" 환경에서는 전역 객체에 접근이 가능하지만 chrome api에 접근이 불가능하다.

chrome.scripting | API | Chrome for Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. chrome.scripting 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 설명 chrome.scripting API를 사용하여 다양한

developer.chrome.com

동적으로 특정 js 파일의 경로를 얻기 위해서는 chrome.runtime.getURL api를 사용해야 하니 "ISOLATED"환경이 필요하고, 그 스크립트를 로드하려면 "MAIN" 환경에서 실행되는 스크립트가 필요하다.

둘 다 사용하고 postMessage를 통해 소통하면 되잖아라고 생각했다면? 정답이다.

매니페스트 설정에서 한 스크립트의 world를 "MAIN"으로 바꿔준 다음, "ISOLATED" 환경에서 사다리 파일의 경로를 메시지로 쏴주자.

https://github.com/Jonghakseo/injected-sadari/blob/main/src/pages/content/ui/app.tsx#L12C1-L20C7

window.postMessage(
  {
    type: 'LADDER_URL',
    url: chrome.runtime.getURL('ladder.js'),
    victim,
    target,
  } satisfies InitMessage,
  '*',
);

받는 곳에서는 url을 받아서 실행만 해주면 간단하다.

https://github.com/Jonghakseo/injected-sadari/blob/main/src/pages/content/injected/index.ts#L2-L12

window.addEventListener('message', event => {
  if (event.data.type === 'LADDER_URL') {
    const message: InitMessage = event.data;
    window.__injected_sadari_victim = message.victim;
    window.__injected_sadari_target = message.target;
    window._nx_js_load(message.url, function () {});
  }
});

참고로 _nx_js_load 메서드는 require([url]) 과 동일한 역할을 한다.

사다리 파일도 살짝 수정이 필요했는데, 아래와 같이 타깃을 초기화하는 로직과 기존 캠버스를 삭제하고 새 캠버스를 생성하는 로직을 넣었다.

//! 전역으로 공유
let VICTIM = window.__injected_sadari_victim;
let TARGET = window.__injected_sadari_target;

//! 기존 캔버스 삭제
document.getElementById('ladders_canvas').remove();
//! 새로운 캔버스 생성
const newCanvas = document.createElement('canvas');
newCanvas.id = 'ladders_canvas';
newCanvas.width = 580;
newCanvas.height = 320;
document.getElementById('ladders').appendChild(newCanvas);

// 아래는 기존 사다리 코드 + 원하는 결과 나오도록 수정한 부분 포함
// ...

완성..!

이후 고도화를 통해 로컬 서버를 띄워놓고 실시간으로 타깃과 키워드를 바꿀 수 있게 추가로 구현했으나... 아쉽게도 그 기능을 쓸 상황은 나오지 않았다...ㅋㅋㅋ

저녁 식사 설거지에 당첨된 부대표님이 주섬주섬 고무장갑을 끼는 모습이 안타까워 조작된 사다리라는 걸 다 실토해 버렸다. 역시 장난은 준비하면서 키득거리는 시간이 더 즐거운 것 같다. :)

그래도 덕분에 워크샵에서 부대표님 노래도 듣고... 근래 했던 장난 중에 재일 재미있었다.

네이버 사다리와 함께 했던 워크숍 (2)

눅눅한 피부 — Sun, 24 Mar 2024 16:28:37 +0900

지난 1편에 이어 계속 진행...!

https://nookpi.tistory.com/197

본격적으로 사다리게임 핵심 로직이 들어있는 js 파일을 분석해 보자.

https://ssl.pstatic.net/sstatic/fe/sfe/ladder-game/ladders_230912.js

내가 개인적으로 minify 로직을 통해 난독화된 코드를 볼 때 염두에 두는 부분은 다음과 같다.

난독화 된 코드는 기본적으로 읽고 해석하기 어렵기 때문에, 상수와 같이 바꿀 수 없는 지점을 찾는 게 우선이다.
IDE의 도움을 받아 코드의 형태를 정리하는 것은 큰 도움이 된다.
어떤 역할을 하는 변수/함수인지 유추되었다면, 이름을 바꿔두는 것이 좋다.
class 혹은 prototype 메서드의 이름은 난독화 대상에서 빠지는 경우가 많아, 메소드 명을 참고하는 것이 도움이 된다.

코드를 복사해서 IDE에 넣고 줄 바꿈을 해보니 7000줄이 넘는 코드가 나온다.

겁먹지 말고 상수부터 찾아보자. 우리가 알 수 있는 상수는 뭐가 있을까? 우선 1편에서 확인했듯, 모듈의 동작 방식은 특정 id를 가진 캔버스를 찾아 렌더링을 하는 것으로 유추된다.

그렇다면 캔버스의 아이디를 먼저 찾아보자.

    var t = (window.LadderGame = function () {
        (o = document.getElementById('ladders_canvas')),
          (nhn.search.ladders.images = nhn.search.ladders.images || {}),
          (nhn.search.ladders.ss = nhn.search.ladders.ss || {}),
          this.handleComplete();
      }),

'laddeers_canvas'로 찾은 캔버스 객체는 o라는 변수에 할당되고 있다.

o의 이름을 canvasElement로 바꾸고 사용하는 곳을 찾아보자.

canvasElement를 사용하는 코드들을 보니 익숙한 네이밍의 함수들이 보이는데? 살짝 함수들을 접어서 네이밍을 살펴보자.

아주 직관적이다

네이밍이 이렇게 중요하다. C는 유저의 클릭 이벤트를 받고 사다리를 실질적으로 그리는 등, 코어 로직을 담고 있는 것으로 보인다.

내 이목을 끄는 부분은 사다리를 실질적으로 그리는 drawladder 함수였다. 카멜 케이스가 아닌 부분은 오타인 것 같다.

사다리를 만들 때 내가 원하는 대로 만들 수 있으면 그다음 로직은 굳이 건드릴 필요도 없다.

사다리 시작시 빈 텍스트가 없으면 사다리를 그린다

makeLoadder? 이것도 makeLadder의 오타인가? 아무래도 사람이 하는 일이다 보니 오타가 없을 수 없다. 일단 눈에 거슬리니 함수 이름을 makeLadder로 바꿔주고 내부 로직을 보자.

제대로 찾은 것 같다! 그런데 여기서 사다리 결과를 어떻게 확인하지...?

위에서 찾은 메서드 중 handleViewResultClick을 확인해 보자.

handlerViewResultClick: function (t) {
  d(0, a), (b = !0), I && I.remove(), (I = null);
  const e = u.ladderItems.length;
  T = [];
  for (let i = 0; i < e; i++) T.push(u.ladderItems[i].itemLineNum);
  u && (u.remove(), u.destroy(), (u = null)), (c = new k());
}

좋아... 딱 보니 모르겠다...

그래도 중요한 힌트가 몇 가지 있는 것 같은데, 일단 결과를 보여주는 페이지로 이동하는 버튼이니 만큼 cleanup 로직들이 섞여있는 것이 보이고 T = []에 결과를 넣는 부분이 눈에 띈다.

사다리의 줄 개수만큼 반복문을 돌면서 결과를 넣어주는 것 같다.

그렇다면 ladderItems 내부에 결과가 있을 가능성이 높다. 디버거로 테스트를 해보자.

일단 몇 번째 줄에 해당하는지 보이고

itemTargetText.text 에는 사다리 아래쪽 텍스트가 보이고, nameTargetText.text에는 사다리 위쪽의 텍스트가 보인다.

실제 사다리 결과와 동일하다

이제 laddersItems에 결과를 넣어주는 부분만 찾으면 된다!

해당 코드는 아까 봤던 drawladder 메서드 안에 위치해 있는데, 전체 코드는 다음과 같다.

사다리 게임이 어떻게 동작하는지 핵심 로직에 대해 파악했으니 이제 수정 방법도 간단하다.

const success = this.ladderItems.some(item => {
  const name = item.nameTargetText.text;
  const target = item.itemTargetText.text;
  return name === "목표 이름" && target === "목표 키워드";
});

// 목표 이름이 목표 키워드에 할당되는 사다리 조합이 나올때까지 실행

if (!success) {
  this.drawladder();
  return;
}

좋아! 다 좋은데... 이걸 어떻게 티가 안 나게 적용하지?

사다리 게임을 하자고 네이버를 켜서 소스 탭에서 끄적끄적 수정할 수는 없는 노릇이다.

다음 편에서 계속.

네이버 사다리와 함께 했던 워크숍 (1)

눅눅한 피부 — Sat, 23 Mar 2024 17:55:58 +0900

얼마 전 1박 2일로 회사 워크숍을 다녀왔다.

워크숍 운영진으로서 재미있는 워크숍을 위해서는 뭐가 필요할지 고민했는데, 네이버 사다리 타기 결과를 조작해서 친애하는 부대표님에게 설거지와 노래 부르기(ㅋㅋ)를 몰아주면 재미있을 것 같았다.

그래서 네이버 사다리 결과를 원하는 대로 만들기 위한 작업에 착수했다.

('네이버 사다리'는 네이버 PC에서 '사다리 타기 게임' 등의 키워드를 통해 검색해서 즐길 수 있는 사다리 게임을 말한다.)

네이버 사다리 게임. 모바일과 PC가 다르다.

구현 요구사항은 아주 심플하다.

타깃의 이름과 목표로 하는 키워드(당첨)가 일치하게 출력되는 것

기술적으로 가능한지를 먼저 검토하기 위해 네이버 사다리 구현을 살펴보자.

사다리 게임은 캔버스를 통해 렌더링이 되고 있다.

캔버스를 그리는 로직이 있길 바라면서 dom을 살펴보니 바로 아래에 매우 의심스러운 script가 하나 보인다.

아주 많은 단서를 주는 코드

(function () {
  const ua = jindo.$Agent().navigator();
  if (!(ua.ie && ua.version < 10)) {
    const sJavascriptFile = 'https://ssl.pstatic.net/sstatic/fe/sfe/ladder-game/ladders_230912.js';
    const fnCallback = function () {};
    nhn.common.load_js(sJavascriptFile, fnCallback, true, 150);
  }
})();

유저 에이전트 확인하는 코드는 건너뛰고, 누가 봐도 사다리게임 핵심 로직이 담긴 js 파일이 보인다. 파일명으로 보아하니 23년 9월 12일에 마지막으로 수정한 코드인 듯...?

전역에 선언된 nhn.common.load_js를 통해 해당 스크립트가 로드되는 방식인 것 같고... nhn.common.load_js에 들어가는 두 번째 인자는 빈 함수로 되어있는 걸 보니 onLoad 혹은 onFail, onError 콜백인 듯싶다.

세 번째 네 번째 인자는 뭔지 모르겠으니 nhn.common.load_js를 찾아보자.

콘솔창을 열어 nhn.common.load_js를 출력해 보니 다음과 같은 난독화된 함수가 나온다.

프론트는 이게 참 좋아...

뭔지 모를 저 텍스트를 더블클릭하면? 쨔잔

그래서 이게 뭔데...

load_js로 명명된 함수의 모습이 보인다.

사다리 게임 js 파일을 호출할 때에는 4개의 인자를 사용했는데, 로직을 보니 5개의 인자를 받을 수 있는 것 같다.

void 0 === r 은 r === undefined가 축약된 형태이다.

!0은 ture의 축약된 형태, !1은 false의 축약된 형태이다.

(우리의 코드를 1byte라도 아끼려는 처절한 노력)

위의 3줄은 인자에 대한 기본값 처리로 보이고, 우리가 신경 써야 할 부분은 첫 번째 t가 어떻게 처리되고 있는지에 대한 부분이다.

"string" == typeof t ? o ? r ? v(t, n) : d(t, n) : r || !h() ? v(t, n) : d(t, n) : o ? r ? v(void 0, n) : n() : r || !h() ? v(void 0, n) : n(), m = ""

... 정신이 나갈 것 같지만 정신을 붙들고 이럴 땐 chatgpt한테 if문으로 바꿔달라고 해보자

if (typeof t == 'string') {
  if (o) {
    if (r) {
      v(t, n);
    } else {
      d(t, n);
    }
  } else {
    if (r || !h()) {
      v(t, n);
    } else {
      d(t, n);
    }
  }
} else {
  if (o) {
    if (r) {
      v(undefined, n);
    } else {
      n();
    }
  } else {
    if (r || !h()) {
      v(undefined, n);
    } else {
      n();
    }
  }
}

브라우저 디버거에서 본 모습

브라우저 디버거에서 찍어본 input에 따라 실행 코드를 찾아보니 몇 줄 위의 함수가 실행되고 있었다.

스크립트를 지연 로드하는 코드로 보인다

결국 실행되는 구문은 window.require(["사다리 게임.js"], 빈 함수)라는 부분을 확인이 가능하다.

궁금해서 전역에 선언된 require 함수를 살펴보니 requirejs@2.3.5 구현체가 나왔다.

https://requirejs.org/

RequireJS

/* --- RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your c

requirejs.org

requirejs는 대략 10년 전에 활발히 사용되던 모듈 로드를 위한 라이브러리로, 의존성 처리와 비동기 모듈 로드를 통해 각 모듈의 성능 최적화를 돕는다.

window.require 호출을 통해 내가 원하는 사다리 로직을 주입해서 실행시킬 수 있을까? 검증을 위해 다음과 같이 테스트를 해보자.

1. 기존 캔버스 엘리먼트를 복사한다.

2. 기존 캔버스 엘리먼트를 삭제한다.

3. window.require(["사다리 게임.js"])를 콘솔에서 수동으로 트리거한다.

사다리 게임이 새 캔버스에서 정상적으로 동작하면 PoC는 성공이다!

대충 어떻게 돌아가는지, inject를 통해 기존 게임을 날리고 새로 시작할 수 있다는 사실도 알았으니 이제 사다리 게임.js을 살펴보고 내부 로직을 고쳐보자...

다음 편에서 계속.

useInjectedProps

눅눅한 피부 — Wed, 20 Mar 2024 14:58:53 +0900

컴포넌트의 Props를 일부 오버라이드하면서 인터페이스를 바꾸고, 컴포넌트가 동일한 ref를 갖게(re-render 가능하게) 해주는 훅을 만들어보자.

Implementation

export default function useInjectedProps<
  C extends React.FC<any>,
  I extends Partial<Record<keyof ComponentProps<C>, any>>,
>(_Component: C, injectedProps: I) {
  // 훅의 인자로 받은 컴포넌트를 저장합니다.
  const Component = useRef<any>(_Component);

  // 상태 변경이 일어나면서 컴포넌트 호출이 일어날 경우 injectedProps가 컴포넌트로 자연스럽게 주입 될 수 있게 합니다.
  Component.current = (props: Omit<ComponentProps<C>, keyof I>) => {
    return <_Component {...props} {...injectedProps} />;
  };

  // 컴포넌트의 ref를 고정시키기 위해 빈 배열의 useCallback 훅을 사용합니다.
  return useCallback((props) => Component.current(props), []) as React.FC<
    Omit<ComponentProps<C>, keyof I>
  >;
}

Use Case

type ButtonProps = {
  onClick: Function;
};

const Button = ({ onClick }: ButtonProps) => {
  return <button onClick={onClick}>Hello World</button>;
};

type ButtonWithTextProps = ButtonProps & {
  text: string;
};

const ButtonWithText = ({ onClick, text }: ButtonWithTextProps) => {
  return <button onClick={onClick}>{text}</button>;
};

const Renderer = ({ RenderButton }: { RenderButton: React.FC<ButtonProps> }) => {
  return <RenderButton onClick={() => alert('Hello World')} />;
};

const UseCase = () => {
  const RenderButton = useInjectedProps(ButtonWithText, {
    text: 'World Hello',
  });
  
  return <Renderer RenderButton={RenderButton} />;
};

//===> <button>World Hello</button>

reference

https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md

세상은 이야기로 만들어졌다

눅눅한 피부 — Sat, 2 Mar 2024 17:50:29 +0900

https://product.kyobobook.co.kr/detail/S000209670832

세상은 이야기로 만들어졌다 | 자미라 엘 우아실 - 교보문고

세상은 이야기로 만들어졌다 | 원시 시대 동굴 속에서 나누던 이야기에서부터 디즈니의 애니메이션까지, 『일리아드』와 같은 고전에서부터 정치인 트럼프의 거짓말까지. 강력한 이야기는 삶

product.kyobobook.co.kr

이야기에 대한 구조적인 분석은 해 본 적이 없는데 이 책을 읽으면서 자연스럽게 인기 있는(소위 잘 팔리는) 이야기의 공통적인 구조에 대해 알 수 있었다.

책은 인기 있는 이야기의 구조적인 공통점에서 시작해서, 시대의 변화에 따라 이야기가 나아가는 방향을 충분히 살핀 다음, 빈부 격차와 기후 위기 등 인류의 위기에 필요한 새로운 이야기의 형태는 무엇인지에 대한 질문을 던진다.

재미있게 읽었는데 뒷부분에서 개인적으로 좀 아쉬웠다.

이야기가 인류 내면의 가치를 탐색하기 위한 수단으로 사용될 정도로 중요하다는 이야기를 하고, 영웅 서사에 '예방'이라는 키워드가 없다는 이야기까지는 공감이 되고 있었다. 우리 앞에 닥친 위기의 해결책으로서 어떤 내러티브를 제시할지 흥미진진하게 따라가고 있었는데 마무리에서 '그냥 좀 더 우리가 신경 쓰고 더 노력하자'라는 느낌을 받았다.

서양과 동양에서 이야기를 풀어나가는 관점이 다르다는 이야기가 중간중간 나와서 뭔가 그쪽으로 풀어나가지 않을까? 기대했던 것 같기도 하고, 기존의 영웅 서사가 가진 견고하고 강력한 구조에 대해 말했으니 그런 구조를 사용해서 매력적인 내러티브를 만드는 방식을 제안하려나? 싶었는데 김이 새는 느낌이었다.

저자가 좀 더 용기를 내봤다면 좋았을 것 같다.

만약 용기가 부족한 게 아니었다면? 그럼 다른 사람들과 마찬가지로 안일하게 생각하고 있는 건가?

모르겠다.

Nextjs 12.3.4 -> 13.5.6 버전업 후 정적파일 CORS 에러

눅눅한 피부 — Wed, 28 Feb 2024 01:16:03 +0900

금일 정기배포 이후 www.creatrip~ 에서 요청하는 js chunk 파일에 대한 CORS 에러가 발생했다.

이 얼마 만에 보는 CORS 에러란 말인가...!

우리 회사에서는 nextjs 빌드 후 생성된 정적 파일은 s3 - cloudfront를 통해서 캐싱 후 제공하고 있는데, 배포 전 후로 설정을 바꾼 부분은 없는 상황이었다.

일단 cdn에서 제공하는 정적 파일에 대한 응답 헤더에 정책을 생성하고, 해당 정책에서 www가 붙은 도메인, 붙지 않은 도메인에 대해 모두 오리진을 추가해서 대응해 주었다.

빠르게 대응은 했는데, 대체 왜 갑자기 문제가 생긴 것인지 파악을 하기가 여간 쉽지 않았다.

처음에는 해당 이슈가 배포 직후에 발생한 문제인지에 대한 확신도 서지 않았고, SSG 등으로 생성된 정적 페이지에서는 해당 이슈가 없는 부분도 의아했다.

가장 먼저 발견한 차이점은 Origin 헤더의 유무였는데, CORS 문제가 생기는 자원들은 모두 요청 헤더에 Origin 값을 보내고 있다는 점이 달랐다.

대체 원인이 뭔지 끙끙대던 중, 훌륭하신 팀원 한 분이 관련 이슈를 찾아주셔서 사건의 전말을 파악할 수 있었다.

https://github.com/vercel/next.js/issues/34225#issuecomment-1804831899

^11.1.2 - Using cdn for assets results in CORS error only for some css files not all · Issue #34225 · vercel/next.js

Run next info (available from version 12.0.8 and up) "next": "^11.1.2", What version of Next.js are you using? "next": "^11.1.2", What version of Node.js are you using? 15.0.1 What browser are you ...

github.com

요점만 정리하자면 다음과 같다.

이번 정기 배포 전의 next 버전은 12.3.4였다.
해당 버전에서는 CSR 페이지들의 script 태그에 crossorigin 속성이 없었다.
12.3.4 버전의 코드에서 crossOrigin을 선언하는 곳과 넘기는 곳을 보면 next.config 내부의 crossOrigin 값이 없는 경우 undefined를 그대로 넘기는 것을 알 수 있다.
그런데 버전업 이후 Next 13.5.6에서는 next.config의 crossOrigin이 없을 경우 빈 문자열을 넣어준다...!
그리고 이렇게 들어간 crossOrigin 값은 script 렌더링시에 사용되는데, 이 버그를 수정하기 위해 이 PR에서 작업되었다. 따라서 config의 crossOrigin 값이 없는 경우, getRequiredScripts 로직을 통해 생성되는 script tag에는 무조건 crossOrigin이 붙게 되는 버그(?)가 생긴 것이다. (그리고 해당 버그는 13.5.4-canary.10에 머지되었다)
crossOrigin attribute는 일부 동적 스크립트에 사용되며 element의 리소스 요청 시 CORS 요청을 사용할 수 있게 만드는 속성이다.
crossorigin 속성이 아예 없는 경우에는 CORS 요청을 하지 않지만, 빈 문자열일 경우 기본값인 anonymous를 사용하게 되며 anonymous에서는 CORS 요청의 credentials flag가 ‘same-origin’으로 지정되면서 CORS 요청이 발생한다.
즉, 버그다.

renderOpt라는 속성을 리팩토링 하면서 crossOrigin에 대한 기본값을 빈 문자열로 넣어버렸고, 추후 버그를 수정하면서 해당 옵션의 crossOrigin 값을 script의 속성으로 그대로 사용해 버린... 버그인 것이다.

nextjs에 기여할 수 있는 기회인가? 싶어서 살펴봤는데 벌써 수정 PR이 작년 11월에 올라와 있었다.

왜 머지가 안 되고 있는지는 모르겠다.

비슷한 이슈를 마주한다면 일단 cdn에서 응답 헤더 정책에 SimpleCORS 혹은 커스텀 정책으로 도메인에 해당하는 origin을 allow 해서 해결해 보자.

https://medium.com/creatrip/next-js-%EB%B2%84%EC%A0%84%EC%97%85-%EC%9D%B4%ED%9B%84-%EC%85%80%ED%94%84-%ED%98%B8%EC%8A%A4%ED%8C%85-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-cors-b7f7192bb9c4

Next.js 버전업 이후 셀프 호스팅 환경에서의 CORS

오늘은 Next.js 13 버전업 이후 겪었던 CORS 이슈에 대한 경험을 공유하려고 해요.

medium.com

Signals

눅눅한 피부 — Wed, 21 Feb 2024 15:53:58 +0900

2023.12.23 개발팀 세미나

https://jonghakseo.github.io/posts/signals/

Signals

시그널은 무엇이고 프론트엔드 생태계에서 주목을 받는 이유는 무엇일까?

jonghakseo.github.io

React 근황

눅눅한 피부 — Mon, 19 Feb 2024 22:35:46 +0900

https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024

React Labs: What We've Been Working On – February 2024 – React

The library for web and native user interfaces

react.dev

RSC에서 실험적으로 테스트중인 cache

https://react.dev/reference/react/cache

cache – React

The library for web and native user interfaces

react.dev

https://youtu.be/LL4V8CcEhIo

- 메타 친구들은 자사 서비스에서 테스트 후 stable로 배포하는게 참 든든하다.

- memo, useCallback, useMemo로 이어지는 고통이 끝나려나...?

- 나는 Solid 접근법이 더 맞는 것 같다.

- 오픈소스는 생태계가 깡패다.

4년차 프론트엔드 개발자의 2023년 회고

눅눅한 피부 — Sat, 17 Feb 2024 20:36:04 +0900

2023년. 작년 한 해도 쏜살같이 지나갔고, 정말 많고 많은 일이 있었다.

2022년의 내가 새로운 환경에서 크게 성장했다면 2023년의 나는 내면의 갈등과 안정, 그리고 내가 무엇을 추구하는지 스스로를 들여다보는 일에 많은 시간을 쏟았던 것 같다.

상반기

새로운 시도와 열정, 동시에 좌절과 고민이 많았던 상반기였다.

숙소... 애증의 숙소

2022년 말부터 신규 사업인 숙소 도메인 개발을 위해 숙소 스쿼드에 합류하여 개발을 진행했다.

스쿼드 내에 자리 잡은 무기력함(?)을 타파하기 위해 내 나름대로의 encouraging에 열과 성을 다했다. 스쿼드 체제 내부에서 구성원들의 자율성과 독립성, 추진력을 바탕으로 더 나은 결과를 만들 수 있을 거라는 믿음이 있었고, 애자일 관련 도서들을 읽으면서 여러 시도를 녹여내 보려 노력했던 시기이다. ('함께 자라기'는 정말 정말 좋았다)

지금 생각해보면 프론트엔드 개발자인지 스크럼 마스터인지 스스로의 정체성에 혼동이 올 정도로 스쿼드 내부에서 여러 시도와 노력을 했던 것 같다.

결론적으로 나름 파이팅 넘치게 숙소 도메인이 론칭되었고... 결과는? 비즈니스적으로 기대 이하의 성적표를 마주하면서 무력감이 생겨버렸다. 팽팽한 고무줄이 끊어진 기분으로 번아웃과 함께 여러 가지로 힘든 시기가 찾아오고 말았다.

내가 했던 노력과 결정이 더 큰 의사결정으로 인해 무용지물이 될 수 있다는 사실은 나로 하여금 이전에 겪어본 적 없는 무기력감을 느끼게 만들었고, 이어진 수습 과정에서의 추가적인 피드백과 의사결정 또한 아쉬움이 남았다.

나는 일에 스스로를 투영하지 않으려고 노력하는 편인데... 이 시기에는 온몸을 다해 열정을 쏟으며 일에 나 자신을 투영해 버린 게 아닌가 싶다.

AI

연초부터 ChatGPT를 위시한 LLM의 범람과 LLM 기반의 AI 서비스들이 우후죽순으로 발표 및 출시되었다. 나는 AI라는 키워드가 이 정도로 우리의 삶에 빠르게 그리고 직접적으로 영향을 끼칠 줄은 전혀 상상하지 못했다. 대체 어떤 일이 일어나고 있는지 알아내기 위해 주의를 기울이고 새로운 정보의 홍수에 허우적거리며 시간을 보냈다.

프롬프트 엔지니어링, 파인 튜닝 등을 통해 비즈니스와 연계하려는 여러 시도들이 눈에 띄었는데, 사실상 연계 서비스의 출시 속도보다 기술의 원천인 OpenAI의 신규 제품 발표 속도가 더 빨라 큰 임팩트를 기대하기에는 어려워 보였다.

LLM을 활용한 서비스들이 어떤 가치를 줄 수 있는지는 아직도 고민 중인 포인트인데, 내 생각은 '원래 잘하는 것이 있는 기업이 LLM을 접목하면 더 큰 가치를 만들 수 있지만, 타사의 LLM과 프롬프트 엔지니어링 만으로는 고유한 비즈니스 가치를 창출하기 어렵다'로 수렴되었다.

회사에 있는 어학당 도메인에 CX비용을 줄이고자 컨텐츠 전처리 + 벡터 임베딩 + 프롬프트 엔지니어링을 통한 챗봇 서비스를 시도해 본 것도 굉장히 새로운 경험이었다. (RAG 개념이 어렴풋하게 정립되려던 시기로 기억한다)

크리에이트립, GPT-3 기반 챗봇 '어학당 지니' 출시 : 크리에이트립 공식 블로그

[더구루=최영희 기자] 종합 한국 정보 플랫폼 크리에이트립이 GPT-3를 기반으로 한국어학당 정보 제공을 위한 챗봇 ‘어학당 지니’를 출시했다고 25일 밝혔다. 어학당 지니는 한국으로 유학

creatrip.co.kr

초기 PoC 및 구현 방향의 설계를 하고 진행했는데 결과적으로 아쉬운 부분들도 있었지만 좋은 시도였다고 생각된다. 프로덕트 팀을 비롯해 사내에 AI 리터러시가 좀 더 확산되는 계기였고, 이때의 경험은 추후 전체 도메인의 자동 번역을 LLM 기반의 번역으로 전환하는 데에 도움이 되었다.

Slack에서 사용할 수 있는 chatgpt 봇도 만들어서 배포했다

오픈소스

GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

Chrome Extension Boilerplate with React + Vite + Typescript - Jonghakseo/chrome-extension-boilerplate-react-vite

github.com

기존 보일러 플레이트는 꾸준히 유지보수를 하고 있었고, 그 과정에서 새롭게 배우는 것들이 정말 많았다.

내 오픈소스 레포를 보며 기여하거나 이슈를 남기는 다른 개발자들이 때때로 내 스승이 되어주기도 하고, 내가 그들에게 뭔가 인사이트를 주는 경험도 있었다.

원하는 프롬프트 + 드래그 후 클릭으로 ChatGPT를 호출하면 편할 것 같아 오랜만에 익스텐션도 만들었다.

https://nookpi.tistory.com/166

DragGPT chrome extension 개발기

배경 최근 ChatGPT 열풍이 거세다. 연구 영역에 있던 생성 AI의 위치를 대중에 가깝게 옮기면서 대중들로 하여금 급격한 기술 발달이 이뤄지고 특이점이 왔다(?)는 생각을 하게 만드는 것 같다. 기

nookpi.tistory.com

이때 익스텐션을 개발하면서 처음으로 유한상태머신의 js 구현체인 XState를 사용했는데, 사용 경험이 매우 좋아서 개발팀 내부에도 공유하는 시간을 가졌다.

https://nookpi.tistory.com/177

React + xState

2023.03.20 개발팀 세미나

nookpi.tistory.com

CS 스터디

4월부터 8월까지 프로덕트 팀원들과 매주 CS스터디를 진행했다.

대표적인 디자인 패턴들과 OS, 네트워크 관련 기본 지식들을 다지는 시간이었고 기대 이상으로 매우 알찼다.

특히 OS 쪽에서 멀티 프로세싱과 스케줄링 부분을 공부하며 핵심 구현체와 그 컨셉은 추상화 Layer가 올라가더라도 활용할 수 있는 기본기로 남겠다는 생각이 많이 들었다.

굉장히 즐겁게 공부했던 시기였다.

하반기

감정이 널뛰던 상반기와는 다르게 전반적으로 차분한 하반기를 보냈다.

숙소 도메인의 여파가 상반기 초입까지 이어졌고, 의사결정에 대한 불신도 남아있었으나 차츰 체념하면서 내가 할 수 있는 범위에서 최선을 다 하자는 마음을 먹게 된 시기였다.

특히 하반기에 새로운 목표를 세우면서 또 다른 원동력도 생기기 시작했다.

오픈소스

미국의 한 스타트업에서 내 보일러 플레이트를 관심 있게 봤다는 연락과, 해당 보일러 플레이트를 사용해서 가장 최근에 만든 DragGPT 익스텐션을 기반으로 크롬 익스텐션 프로덕트를 만들고 있다는 연락을 받았다.

Hello JongHak,

I'm a big fan of the Chrome extension boilerplate repo you've developed! We are developing ~ and have decided to use your boilerplate for our Chrome extension.

추가 기능 구현에 도움이 줄 의향이 있다면 시간 단위 계약으로 일을 맡기고 싶다는 연락과 함께...

첫째로 내 성과물을 지구 반대편의 회사에서 인정해 준다는 점이 날 고양시켰고, 그들이 제시한 시간당 임금도 마음에 들었다.(역시 미국...?)

직장생활을 하고 있었고 업무에 지장이 생기길 원치 않았기 때문에 주말마다 적은 시간을 할애할 수 있다고 답했고 그들이 기꺼이 이해해 준 덕분에 미국에 있는 스타트업에 원격으로 조인해서 함께 업무를 해보는 귀중한 경험을 해 볼 수 있었다.

감사하게도 그 이후에도 여러 좋은 제안을 해주셨고, 최근에는 크롬 익스텐션 관련 업무의 니즈가 적어 내가 하는 일은 거의 없지만 이때를 계기로 아직 좋은 인연을 이어 나가고 있다.

https://nookpi.tistory.com/188

오픈소스 1K Stars 를 달성하며 느낀 것들

vite를 사용해보고자 했던 단순한 마음으로 시작했던 오픈소스가 어느덧 1K Stars를 돌파했다. GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript Chrome Extens

nookpi.tistory.com

10월이 되면서 오픈소스 레포의 Stars가 1000개를 넘겼는데, 이때 내 경험을 공유하면 좋을 것 같아 그간의 기록과 나의 감상을 블로그 글로 남겨두었다.

실리콘 밸리에서 일하시는 리크루터였다...ㅎㄷㄷ

최근에는 딱히 관리하지 않는 링크드인 계정으로 이런 메시지도 받아봤다. 이게 다 오픈소스 덕분이다...!

고민

9월~10월 즈음에 내 인생의 가치와 앞으로의 방향성에 대해 고민이 많아졌다.

미국 스타트업의 정규직 제안도 받고, 모 기업의 테크 인터뷰도 통과하면서 솔직히 내가 지금 결정하는 것은 무엇이든 이룰 수 있을 것 같은 자신감으로 가득 차 있었다.

하지만 반대로 내가 뭘 하고 싶은지는 제대로 정리되지 않았고, 어떤 방향성을 가지고 살아야 하는지 고민을 거듭하게 되었다.

남들처럼 평범한 인생의 궤적을 원하기도 하면서 동시에 남들처럼 평범하게 살기는 싫었다.

한국에 있는 남들 다 아는 기업에서 주변 사람들의 인정을 받고 평범하게 결혼 후 가정을 꾸리고 살고 싶기도 했지만, 동시에 모든 걸 내려놓고 해외에 나가 맨땅에서 새로운 도전을 해보고 싶기도 했다.

사실 지금도 내가 진실로 원하는 게 무엇인지 잘 모르겠다. 아니 애초에 둘 중에 하나를 원하는지도 모르겠다.

최근 읽은 '어른의 중력'에서 이러한 구분을 '안정형'과 '의미형'으로 구분하던데, 인간은 결국 두 개의 가치가 조화로워야 행복해진다나 뭐라나...

의지력

하반기에는 스스로의 의사결정에 있어 내 조악한 의지력을 이겨내기 위한 도구를 만들었다. 그 도구는 3개의 질문을 통해 몸을 강제로 움직이는 프로세스에 가깝다.

1. 하면 좋은 일인가?

2. 할 수 있는 일인가?

3. 하지 못하는 이유가 있는가?

하면 좋고, 할 수 있고, 딱히 하지 못하는 이유가 있는 것들은 내 생각에 정말 해야 되는 것, 안 하면 바보 같은 것이다.

스스로에게 위 3개의 질문을 하면서 게으른 몸을 조금 더 움직이고 나태함과의 싸움에서 승리의 경험을 만드는 것은 험난했지만 그 무엇보다도 큰 성취감을 가져다주었다.

회사

10월 즈음에는 회사 동료들과 좀 더 사적인 자리를 많이 가졌다.

영종도, 양평 등 주말에 카페 및 맛집 투어를 다니면서 즐거운 시간을 보냈다. 편하고 친한 사람들이어서 그런지 즐거움이 참 많았다. 오픈소스 프로젝트도 같이 진행하는 등 회사 동료분들과 더 친해지는 계기였다.

이맘때의 활동은 근황 글에 자세히 남겨둔 관계로 해당 글로 갈음한다.

https://nookpi.tistory.com/187

근황

0. 직장 동료들과 함께 주말에(!) 영종도에 유명한 카페에 가고 을왕리 해수욕장에도 갔다. 주말에 직장 동료들과 사적인 시간을 보내는게 처음이라서 어색했으나 굉장히 즐거운 시간을 보냈다.

nookpi.tistory.com

파트 리드

12월 초부터 프론트엔드 파트 리드를 맡게 되었다. 여러 우여곡절이 있었지만, 가장 큰 부분은 스스로의 심경 변화였다.

나는 지금 회사에서 자율과 책임의 원칙 아래 좋은 피드백을 받으며 큰 성장을 이뤘다고 생각한다. 그리고 이런 성장은 동료들의 피드백과 지지 없이 스스로 절대 이룩할 수 없었던 부분이라고 진심으로 생각하며 팀에 감사하고 있다. (말로 다 표현 못하지만 늘 감사합니다...)

그런 이유로 나는 팀에 일종의 채무감을 늘 가지고 있었다. 새로 합류한 프론트엔드 파트원들이 내가 받은 것과 동일한, 혹은 더 뛰어난 피드백과 격려, 지지를 받아 스스로 만족할 수 있을 만큼 성장하게 도와드려야 한다고 생각했다.

쉽게 말해 받은 만큼 돌려주고 싶다는 마음이었던 것 같다.

하지만 죄송하게도 그렇게 하지 못하고 있다는 느낌을 늘 받고 있었고, 누군가 총대를 메고 이 부분을 개선해야 한다고 생각하고 있었다. 골치 아픈 일을 피하고 싶은 나의 욕심과 방황에 밀려 크게 신경 쓰지 못했던 것도 죄송하고...

"그걸 왜 네가 해?"라고 누군가 물어본다면... (다소 건방지게 들릴지 모르지만) '내가 매니징을 하는 것 자체를 귀찮아하는 것과 별개로 잘할 자신은 있다'라고 대답할 수 있겠다.

파트 리드를 맡고 제일 먼저 한 것은 파트원들과의 1:1이었다. 제대로 진행되지 않던 1:1을 다소 촘촘한 간격으로 진행하면서, 파트원 개인이 가지고 있는 각자의 니즈와 만족하는 부분에 촉각을 곤두세웠다.

각자가 원하는 것에 대해 알아내는 것은 정말 어려운 일이었지만, 모두의 니즈를 충족시킬 수 있는 나의 스탠스를 정립하는 것은 그 이상으로 힘든 일이었다. 회사의 비즈니스 방향성과 파트원 개인의 니즈를 일치시켜 윈윈 할 수 있는 구조를 만들기 위해 노력했고 스쿼드 재배치, 업무 분장의 정리 등으로 구성원의 만족도도 올리면서 아웃풋도 개선되는 성과를 거뒀다.(고 생각한다)

두 번째로 한 일은 모든 Pull Request에 대한 코드 리뷰였다. 파트 리드에게 요구되는 역량은 조직마다 조금씩 다르겠지만, 우리 팀에서는 프로덕트의 방향성과 코드 퀄리티 등 개선안에 대해 자신감 있게 의견을 낼 수 있는 기술적인 역량도 크게 요구되었다. 더불어 파트 전체를 관통하는 컨텍스트의 공유를 위해 나 스스로가 일종의 허브가 되기로 결심했다.

파트원들의 생산성을 높이고 바퀴를 재발명하는 일이 없게끔 시작한 전체 코드 리뷰였지만, 초반에는 정말 쉽지 않았다. 열심히 일하는 파트원분들 덕분에 하루에 10개에 달하는 코드 리뷰를 보는 날도 있었다. 9시에 출근해서 3시까지 코드 리뷰만 본 날도 있었다.

한 편으로는 모든 PR을 리뷰하기 정말 잘했다는 생각이 들었는데, 리뷰를 하면서 자연스럽게 파트원 5명의 업무 진행 방식이나 진척도 등 업무 진행에 대한 정보도 알게 되었고 각 스쿼드 간에 존재하는 비효율 등을 찾아 생산성을 개선할 수 있었다. 무엇보다도 리뷰어가 없이 소외되는 PR이 생기지 않았고 양질의 리뷰와 성장에 초점을 둔 리뷰 코멘트를 남기려고 노력했다.

추후 구성원들로 하여금 업무에 대한 피드백이 이뤄지고 있으며 이로 인한 성장이 업무 만족도에 영향을 준다는 부분을 알게 되어 뿌듯했다. 궁극적으로는 성장을 통한 자아효능감이 팀원들의 리텐션에도 좋은 영향을 주지 않을까...?

세 번째로 한 일은 파트 내부의 유대감을 만드는 일이었다. 파트 내부의 유대감을 빠르게 형성하는 게 신규 입사자에게도 중요하고, 기존 구성원들에게도 심리적인 안정감을 제공해 줄 수 있다고 생각했다.

파트원들의 접점이 적고 대화의 시간 자체가 절대적으로 부족하다고 판단해서 매주 금요일에 1시간씩 '기술 잡담' 시간을 만들었다. '기술 잡담'이라는 이름에서 드러나듯이 구성원들이 부담 없이 기술에 대한 이야기를 할 수 있는 공간이면서 동시에 기술 이야기를 하지 않고 잡담만 해도 되는 시간을 만들었다.

첫 주에는 다소 어색한 분위기에서 기술적인 이야기보다는 잡담 위주로 시간을 보냈지만, 매주 이러한 시간이 지속되니 점차 편한 분위기에서 기술적인 고민을 나누거나 아젠다를 준비해 오는 빈도가 늘어나기 시작했다.

또한 기존 슬랙 프론트엔드 채널에서 업무 이야기를 함께 나누다 보니 가벼운 일상을 공유하기 어렵고, 업무 관계자들이 이미 채널에 많이 들어와 있어 부담스럽다는 건의가 있었다. 이를 수용하여 프론트엔드 파트원들만 수다를 떨 수 있는 편한 채널을 개설해서 외부 인원의 유입을 막고 소소한 일상을 나눌 수 있게 했고, 지금은 파트원들이 해당 채널에서 여행 경험이나 사진 등 활발하게 일상을 공유하고 있다.

그 밖에도 퇴근 후 회식이나 번개의 빈도도 늘려 좀 더 친하게 지내려고 많이 노력했던 것 같다.

매니저로서도 동료 개발자로서도 좋은 자극을 주고받으며 행복하게 일할 수 있는 환경을 만들기 위해 나름 최선을 다 했다고 생각한다. 물론 모든 부분에서 완벽하진 못했지만 2024년 초 현재까지는 체감적으로는 프론트엔드 파트의 분위기가 상당히 좋아진 것 같아 뿌듯하다.

2023 총평

'비 온 뒤에 땅이 굳는다'라고 한다.

비가 온 직후, 땅은 걷기도 힘들고 보기에도 안 좋은 진창이 되지만 시간이 지나 물이 마르면 적당히 단단하고 폭신폭신한 걷기 좋은 흙길이 된다.

작년 한 해가 나에게는 그런 과정이었다고 생각한다.

상반기에는 많은 비가 나를 진창에서 허우적대게 만들었고 실제로 내 모습도 썩 보기 좋지 않았다. 다행히 하반기에 이르러 비가 적당히 마르고 내 스스로의 날도 어느 정도 벼려진 보기 좋은 모습으로 마무리했다고 생각한다.

올해는 또 다른 큰 도전을 해보려고 한다.

걷지 않은 길은 늘 두렵지만, 또 늘 그렇듯이 걷고 나서 뒤돌아보면 정말 별거 아니었다.

용기는 낭떠러지 앞에서 꽉 쥐는 주먹이 아니라, 낭떠러지까지 걸어 올라온 두 발에 숨어있다고 생각한다... 내년에도 잘 해보자!

근황

눅눅한 피부 — Wed, 14 Feb 2024 14:20:21 +0900

0. 작년 말 즈음부터 프론트엔드 파트 리드를 맡게 되었다. 정신없고 바빠졌지만 그래도 생각했던 범위 안쪽이라 잘 적응해 나가고 있다.

1. 2023 회고를 써야 하는데 자꾸 미루고 있다. 너무 많은 일들이 있어서인지 엄두가 안 나는 것 같기도 하고...? '부담을 내려놓고 편하게 써야지'라고 50번째 생각만 하는 중.

2. 오랜만에 React 소스코드 톺아보기 스터디를 진행하고 있는데 역시 재미있다. 처음 React 소스코드를 보면서 배우는 점이 참 많고 재밌었는데 그 기분을 동료들과 다시 나누니 더 즐거운 것 같다.

3. React 소스코드 스터디를 하기 전에 'React 소스코드의 동작을 이해하면 이런 것들도 할 수 있어요!'와 같은 동기부여 용도로 익스텐션 POC를 하나 만들었다. 개발 환경에서 컴포넌트를 클릭하면 해당 소스코드의 위치로 IDE를 열어주는 기능인데, 생각보다 반응이 좋고 생산성에도 도움이 되는 느낌이라 각 잡고 개발 중이다.

당연하겠지만 나중에 찾아보니 비슷한 프로젝트들이 있길래 쬐~끔 더 발전시켜서 만들고 있다.

4. 뭔가 책을 꾸준하게 읽는 게 어려워서 고민이다. 진득하게 활자에 집중하는 능력이 상당히 떨어진 기분...

5. 삶의 방향성과 가치에 대해 고민하는 날이 많은데, 누구도 날 대신해 결정해 줄 수 없는 문제라는 것을 알기에 살짝 외롭다.

6. 처음으로 실리콘밸리 테크 리크루터에게 링크드인으로 연락을 받았다. 대단한 내용은 아니고 github가 흥미로워 포트폴리오를 받을 수 있냐는 내용이었는데 기분이 매우 좋았다.

HMR의 작은 비밀

눅눅한 피부 — Sun, 12 Nov 2023 18:36:23 +0900

개발자의 생산성은 무엇에 달려있을까?

바로 input과 output 간의 이어지는 사이클을 극단적으로 줄여 빠른 피드백을 반복적으로 얻을 수 있는 환경이다.

빌드에 2분이 걸리는 프로젝트가 있고, 코드 변경의 결과물을 확인하기 위해서는 꼭 다시 빌드를 해야 한다고 생각해 보자.

내 코드의 변경사항이 어떤 결과로 나타내는지를 알기 위해서는 2분이라는 시간이 필요하다. 만약 실수했다면? 다시 수정 후 빌드를 하는 2분을 기다려야 한다.

이 시간들은 당신을 좀 더 여유롭게 살 수 있게 해 줄 수 있을지도 모르지만, 적어도 생산적인 사람으로 만들진 못할 것이다.

모든 개발 환경은 이러한 잉여 시간을 줄이고 빠른 피드백을 주기 위해 발전해 왔다. 테스트 코드, HMR(Hot Moudle Replacement), JetPack과 Flutter의 Hot Reload 등등...

특히 프론트엔드 개발 생태계에서는 웹팩에서 주도했던 HMR가 큰 영향을 미쳤다.

HMR의 기능을 한 문장으로 요약하면 '로컬 파일의 변경사항이 생기면 해당 모듈을 빠르게 교체' 하는 것이다.

내 오픈소스에서도 해당 기능을 아주 살짝? 비슷... 하게 구현하고 있는데, 특정 파일만을 교체하는 것이 아니라 전체 파일을 다시 빌드 후 익스텐션을 새로 로드하는 방식을 사용한다. (그래서 이름도 Hot Rebuild Reload/Refresh인 HRR로 지었다)

로컬 파일의 아웃풋이 필요한 크롬 익스텐션의 특성상 이러한 방식으로 구현이 되었는데, vite 크롬 익스텐션 플러그인의 경우 빌트인 개발서버를 후킹 해서 개발서버에서 서빙되는 모듈을 로컬 파일에 그때그때 쓰고 reload 하는 방식을 사용하고 있다. 후덜덜...

어쨌거나 이런 이유로 반쪽짜리인 HRR만을 운영하던 내 오픈소스 레포에 이런 이슈가 올라왔다.

https://github.com/Jonghakseo/chrome-extension-boilerplate-react-vite/issues/261

manifest.json file listens for compilation issues · Issue #261 · Jonghakseo/chrome-extension-boilerplate-react-vite

The manifest.ts file has added listening, but the contents modified after starting local development are not updated in the compiled dist file It is hoped that the contents of the manifest.ts file ...

github.com

내 보일러 플레이트에서는 manifest.ts 파일의 내용을 바탕으로 maifest.json을 생성해 주는데, manifest.ts 파일의 변경사항이 rebuild는 발생시키지만 정작 생성된 manifest.json을 보면 최초의 내용을 그대로 가지고 있어서 아무것도 업데이트되지 않는 문제가 있었다.

즉, manifest 파일을 수정하고 그 내용을 반영하려면 pnpm dev를 다시 하고 익스텐션도 수동으로 reload를 해줘야 하는 불편함이 있었다.

대체 왜 manifest.ts 파일의 변경사항은 빌드 시에 반영되지 않는 건지 궁금해서 알아보니, 아니 글쎄 한 번 가져온 모듈은 리소스 낭비를 위해 캐싱을 한다는 게 아닌가?

NodeJS 공식 문서를 보니 require를 통해 가져온 모듈의 경우 require.cache에 캐싱된 내용이 저장되고, delete require.cache['<moduleName>']을 통해 캐시 무효화를 할 수 있었다.

ESM을 사용하는 나의 경우에는 어떤 식으로 해결할 수 있을지 찾아보니 일단 import()를 통한 동적 모듈 로딩은 수동으로 캐시 무효화가 불가능했다.

하지만 방법은 있었으니... 바로 모듈 뒤에 쿼리 URL을 붙이는 것이다. 이게 무슨 뜬금없는 소리지?

https://ar.al/2021/02/22/cache-busting-in-node.js-dynamic-esm-imports/

Cache busting in Node.js dynamic ESM imports

I’m porting JSDB to EcmaScript Modules (ESM) and one of the issues I had to look into was module cache invalidation. JSDB is my little in-memory native JavaScript Database that writes JavaScript operations to append-only JavaScript logs that have UMD hea

ar.al

뜬금없다고 생각했으나 공식문서를 살펴보니 정말로 그러한 내용이 있었다.

Modules are loaded multiple times if the import specifier used to resolve them has a different query or fragment.

vite에서도 해당 내용이 반영된 소스코드를 찾을 수 있었는데, `t=${timeStamp}` 형태로 cache busting과 해당 모듈이 어떤 시점에 로드되었는지 식별이 가능한 형태로 구현하고 있다는 것을 알게 되었다.

https://github.com/vitejs/vite/blob/main/packages/vite/src/node/server/middlewares/indexHtml.ts#L132

결론적으로는 나도 동일한 방식을 통해 구현했는데, manifest 파일의 변경 시 rebuild를 하게 되면, 캐시가 무효화된 manifest.js를 가져와 그때그때 새로 manifest.json을 생성하도록 했다.

결과적으로 위 이슈를 해결하면서 배운 것들은 다음과 같다.

1. require, import와 같이 JS에서의 모듈 로드 시스템은 최적화를 위해서 기존 모듈을 캐싱한다.

2. require의 경우 직접 캐시 객체를 수정하여 cache bursting을 달성한다.

3. import의 경우는 직접 캐시 객체를 비울 수 없어 모듈 이름 뒤의 인자를 수정해줘야 한다. 이 경우 모듈을 다시 로드한다.

4. windows 환경에서는 import() 인자에 file schema가 강제된다. 따라서 url.pathToFileURL 사용이 강제된다.

사실 이슈를 봤을 때 이렇게 재밌는 사실을 많이 알게 될 줄은 몰랐는데, 참 이런 경험이 새로운 것들을 재미있고 자연스럽게 익힐 수 있는 계기인 것 같아 기록용으로 남겨준다.

enhance: Modify to let the plugin do the build completion detection not file system. by Jonghakseo · Pull Request #265 · Jongh

Fixed #184

github.com

fix: windows dynamic import protocol issue by Jonghakseo · Pull Request #268 · Jonghakseo/chrome-extension-boilerplate-react-v

Fixed #266 (comment)

github.com

오픈소스 1K Stars 를 달성하며 느낀 것들

눅눅한 피부 — Fri, 10 Nov 2023 07:47:37 +0900

vite를 사용해보고자 했던 단순한 마음으로 시작했던 오픈소스가 어느덧 1K Stars를 돌파했다.

GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

Chrome Extension Boilerplate with React + Vite + Typescript - GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

github.com

누군가에게는 사소한 1K일 수 있지만, 1000명이 넘는 개발자들이 내 프로젝트를 '볼 가치가 있다'라고 생각해 준 점이 나에게는 큰 감동으로 다가왔다.

내가 운영 중인 오픈소스는 이전에 블로그에서도 몇 번 소개했던 크롬 익스텐션 제작을 위한 보일러플레이트이다.

크롬 익스텐션을 몇 개 만들면서 개발환경 구성이 어렵고 문서를 찾기 어렵다는 점을 느껴, 그 당시 사용해보고 싶었던 vite를 활용해서 얼기설기 만든 것이 시작이었다.

https://nookpi.tistory.com/140

프론트엔드 주니어의 오픈소스 기웃대기

들어가기 전에... 이 글은 경력 2년도 채 되지 않은 주니어 프론트엔드 개발자가 오픈소스를 기웃거린 경험을 다루고 있습니다. 오픈소스에 기여에 대한 의욕만을 가지고 후안무치(厚顔無恥)의

nookpi.tistory.com

https://nookpi.tistory.com/147

오픈소스를 통해 후원을 받은 후기

이전 글인 프론트엔드 주니어의 오픈소스 기웃대기라는 글의 마지막 부분에서 링크드인을 통해 후원 의사가 있는 분의 연락을 받았다는 내용을 적은 적이 있었다. 그분은 github sponsor 기능을 통

nookpi.tistory.com

해당 오픈소스 레포는 2022년 4월 10일에 처음 만들어져서, 지금까지 1년 반이라는 시간 동안 지속적으로 유지보수를 진행하고 있다.

레포를 처음 만든 이후부터 현재까지 운영하는 과정에서 희노애락과 여러 기회들이 많이 생겼다. 열정 넘치게 유지보수를 하던 시기도 있었고, 때로는 살짝 심드렁해져 한 두 달 동안 방치되는 시간도 있었다.

이 과정에서 경험하고 느낀 재밌는 부분들을 주로 소개하려고 한다.

초기 홍보가 중요하다?

vite 관련 오픈소스가 상대적으로 적었던 작년 4월, 보일러 플레이트를 만들고 나서 얼마 지나지 않아 awsome vite에 내 오픈소스 레포를 추가했다. awsome vite는 vite로 만들어진 오픈소스를 리스트업 하고 사람들로 하여금 쉽게 찾을 수 있게 제공하는 곳인데, awsome 시리즈는 언어, 프레임워크, 라이브러리 등 굉장히 많아서 익숙하신 분들이 많을 거라 생각한다.

그 당시 awsome vite 목록에 chrome extension 키워드가 들어간 레포는 내 오픈소스가 유일했으므로 초기 유입에 굉장히 도움이 되었을 것이라고 추측하고 있다.

사실 그 이후 별다른 홍보는 하지 않았지만, 이때 확보한 초기 이용자들(~100 Stars)로 인해 SEO도 더 잘 되었다고 생각한다.

생각보다 기여해 주시는 분들이 많다.

부끄럽게도 나는 스스로의 오픈소스를 운영하기 전부터 지금까지도 다른 오픈소스 생태계에 적극적으로 기여하지 않았다. 물론 실력이 부족한 문제도 있었지만 귀찮음도 한몫을 했다.

사실 애정이나 관심이 없으면 issue를 올리는 것 자체도 쉬운 일이 아니다. 더군다나 PR로 기여를 하기 위해서는 해당 프로젝트를 포크하고, 로컬에서 수정 후 기여하려는 레포의 브랜치를 base로 설정하고 PR을 올리는 과정을 거쳐야 한다.

지난 시간을 돌이켜보면, 이런 귀찮음을 감수하고 오픈소스에 기여를 해주시는 분들이 참 많았던 것 같다.

단순히 issue 생성이나 PR뿐 아니라 타인의 issue를 보고 내 대신 더 좋은 해결방법이나 아예 다른 관점에서의 해결책을 제시해 주시는 분들도 많았는데 이분들이 내게 큰 동기부여가 되었다.

기여는 너무 감사하지만 검토는 잘해야 한다.

초기에는 PR 등의 기여가 발생하면 일단 기여를 해줬다는 사실 자체가 너무 감사해서(?) 믿고 Approve 후 머지를 하는 경향이 있었다.

내가 maintainer로써 책임감을 더 가지고 크로스체크 이후에 머지를 하는 게 맞았는데, 어느 날 버그가 있는 PR을 머지하는 경험을 하고 나서야 정신을 차렸다.

기여의 선한 의도와는 별개로, 프로젝트의 맥락과 구조를 제일 잘 이해하고 있으며 유지보수의 책임이 있는 내가 더욱 꼼꼼히 검토하는 태도가 필요하다는 사실을 깨달았다. (이상한 PR이 가끔 있다.)

Issue와 PR의 비율은 체감상 9:1

실제로는 그렇지 않지만, maintainer인 내가 느끼는 두 기여의 비율은 9:1 정도였다. 많은 사람들은 쉽게 생성할 수 있는 issue를 생성해서 아이디어에 대해 건의하거나 버그를 제보했지만, 발견한 버그나 개선점에 대해 작업 후 PR을 올리는 사람들의 비율은 매우 낮았다.

당연한 일이라는걸 알았지만 가끔 그 부분에서 힘듦을 느꼈던 것 같다.

한창 다른 관심사에 빠져 유지보수를 게을리하다 보니, 동시에 열려있는 issue가 20개 가까이 되던 시기가 있었다.

issue가 쌓이면서 체력과 시간, 그리고 의욕에 한계가 느껴진다는 생각이 들었고 누군가가 도와줬으면 하는 생각이 많이 들던 시기였다. 그 당시 나는 '왜 이 사람들은 이 정도의 이슈라면 스스로 해결하지 않지? 혹은 PR로 직접 해서 제안하지 않지?' 하는 다소 배부른 생각도 가지고 있었다. 사실 issue건 PR이건 기여해 주는 것 자체가 감사한 일인데...

최근에는 좋은 아이디어와 훌륭한 디버깅 능력, 엄청난 적극성으로 도와주시는 분이 생겨서 큰 동기부여가 되고 이런 생각은 더이상 하지 않지만, 한창 동기부여가 안 되던 시기에 시간을 충분히 내지 못해 미안하다던 내게 '나도 시간이 없어. 빨리 해결해줘야 해' 라는 코멘트를 남긴 사람도 있었다. 당시에는 해당 글을 보고 회의감이 심하게 왔었다.

물론 이런 회의감을 지우고 다시 동기부여가 되게끔 도와주는 다른 훌륭한 개발자분들이 있기에 지금도 꾸준히 유지보수를 할 수 있다고 생각한다.

1K Stars가 넘으면 후계자(successor)를 정해 달라는 배너가 노출된다.

1K가 넘어가는 순간, 레포 상단에 후계자를 지정하라는 배너가 노출되었다.

농담이 아니라 정말로 내가 사망하면 사망 진단서(...)등의 서류를 보내 해당 레포를 이어받을 수 있는 후계자를 지정하라는 내용이었다.

버스팩터 관리를 해야 할 정도의 소스라고 github 측에 인정받은 것 같아 재미있었다. :)

재밌는 연락들이 종종 온다.

1년 반 정도 오픈소스를 운영하다 보니, 재미있는 연락들이 종종 오곤 한다.

외국인에게 한글로 감사인사를 받아보기도 하고

아주아주 작은 국위선양?

너 유지보수 안 하니? 하는 넛지 메일도 받아보고

이후 기여를 엄청 해주셨다.

순수한 감사의 메시지도 받아보고

랜선 허그

본인의 오픈소스를 소개해주는 메일도 받아보고

크롬 익스텐션계의 Next.js를 꿈꾸시는 분

일을 같이 하자는 메일도 받고

너 나랑 일 하나 같이하자

다 기록하진 못했지만, 이런 재미있는 메일들이 종종 오곤 한다. 기재하지 않은 메일 중 하나는 실제 오프라인 모임으로도 인연이 이어진 계기가 되기도 했다. 무엇보다도 기쁘고 보람이 느껴지는 반응은 '덕분에 시간을 아꼈다'는 내용인데, 내가 쏟은 시간과 노력이 그 이상 누군가의 시간과 노력을 아끼는 계기가 되었다는 건 참 짜릿한 일인것 같다.

지난 1년 반 동안, 참 특별하고 기억에 남는 경험을 했던 것 같다.

내가 블로그를 쓰기 시작한 계기는 누군가가 적은 문장을 보았기 때문이다.

"한 달에 블로그 글 하나씩 꾸준히 작성하면, 들인 시간과 노력의 제곱 이상으로 나중에 크게 보상받는 순간이 온다."

이 말을 차용해서 나는 이렇게 말해보려고 한다.

"오픈소스에 꾸준히 기여하면, 들인 시간과 노력의 제곱 이상으로 특별한 경험과 보상을 얻을 수 있다."

오픈소스 활동은 개발자 커뮤니티에 보은(?) 하며 동시에 유대감과 보람까지 느낄 수 있는 특별한 활동이라고 생각한다.

이번 주말에 당장 작은 기여라도 시도해보는게 어떨까? 여러분들에게도 적극적으로 권해드리며 이만 글을 마친다.

근황

눅눅한 피부 — Sat, 7 Oct 2023 00:04:18 +0900

0. 직장 동료들과 함께 주말에(!) 영종도에 유명한 카페에 가고 을왕리 해수욕장에도 갔다. 주말에 직장 동료들과 사적인 시간을 보내는게 처음이라서 어색했으나 굉장히 즐거운 시간을 보냈다. 술 한 잔 마시지 않고 11시간을 넘게 같이 있었다... 수다만 엄청 떨었다.

1. Astro Page Transition을 써보려고 블로그를 새로 만들었다. 각잡고 글 올리는 용도의 블로그로 사용할까 생각중... 아마 티스토리는 편하게(?) 무게감 없이 이것저것 적는 용도로 사용할 것 같다.

Home

Jonghak Seo's blog

jonghakseo.github.io

2. 프론트엔드 다이빙 클럽에 다녀왔다. 내가 방문한 회차에는 프론트엔드 테스트 관련한 짧은 세션을 2개 들었는데, 새삼 다들 비슷한 고민들을 하고 있다는 사실을 알게 된 것 같다. 개발자간의 교류? 커뮤니케이션 활동은 처음이었는데 나쁘지 않았던 것 같다. 평소 토스에 궁금한 점 두 세 가지를 물어볼 기회가 있어서 재미있었다. (yarn berry 의존성 소스코드 확인할때 불편하진 않은지, 인터널 프로덕트의 인터페이스 정의는 어떤 절차로 하고 있는지 등등)

뱃지랑 스티커랑 콜드브루를 줬당

놀러오세요! 프론트엔드 다이빙 클럽

프론트엔드에 관한 깊은 이야기를 나눌 수 있는 오프라인 커뮤니티, 프론트엔드 다이빙 클럽을 소개합니다.

toss.tech

3. 추석 연휴를 맞아 싱가폴에 방문했다. 참 더운 나라다.

4. 내가 멘탈이 참 약하다는걸 느낀다. 기분 상한게 바로바로 얼굴에 드러나고(정작 본인은 티가 안 난다고 생각하는게 코메디) 별거 아닌 말이나 행동에도 속쓰려한다. 관리하는 오픈소스 레포에 시간을 충분히 쏟지 못해서 시간이 없어 신경쓰지 못해 미안하다고 코멘트를 달았는데 답변으로 '나도 시간이 없어' 라는 식의 댓글이 달려서 현타가 찐하게 왔다...ㅎㅎ

5. 직장 동료와 kitchen table(가제)이라는 오픈소스(로 발전시키려는) 프로덕트를 만들어보고 있는데 재미있다. 해보고 싶었던 프로덕트라서 동기부여가 잘 된다.

6. 의뢰(?)가 들어와서 unified.js 생태계에서 retext를 보고 있는데 자연어 Node 파싱을 통해 뭔가 하는게 되게 노가다 같다는(?) 생각이 든다. 앵간한 요구조건은 정규식으로 처리하는게 더 유용해보이는...크흠

unified

Content as structured data: unified compiles content and provides hundreds of packages to work with content

unifiedjs.com

7. 여전히 불확실한게 많고 두려운게 참 많다. 그래서 고민도 많고... 내 욕심에 비해 능력이 따라가지 못한다고 느낀다. 나한테도 열심히 산다고 말해주는 사람들이 있지만 나는 늘 내가 해내는 것들이 불만족스러운 것 같다. 세상엔 왜 이렇게 잘해야 하는 일이 많을까?

AST (Abstract Syntax Tree)

눅눅한 피부 — Sat, 16 Sep 2023 17:48:20 +0900

2023.09.07 개발팀 워크샵 세션

메타프로그래밍 (MetaProgramming)

눅눅한 피부 — Fri, 15 Sep 2023 22:40:30 +0900

https://jonghakseo.github.io/posts/metaprogramming/

Metaprogramming

This post is about metaprogramming. What is meta programming?

jonghakseo.github.io

동기부여

눅눅한 피부 — Sun, 13 Aug 2023 23:30:05 +0900

돈을 많이 벌게 되면 삶의 질과 미래를 계획할 수 있는 범위가 늘어난다. 또 한편으로는 사회 구성원으로서 나의 기여를 인정받는 기분이 들어서 기쁘다.

하지만 나는 돈보다 강력한 동기부여가 있다고 믿는다.

따뜻한 격려의 말 한마디

동료로부터 인정받는다는 기분

내 공헌이 누군가에게 도움이 되었다는 것을 내가 인지했을 때

이 모든 순간이 돈으로는 얻을 수 없는 큰 동기부여가 되는 것 같다.

시간을 들여 격려의 말을 해준 지구 반대편의 한 개발자에게 나도 허그를 보내며...

Proxy로 MockData 관리하기

눅눅한 피부 — Sun, 13 Aug 2023 16:58:01 +0900

회사의 스토리북 유지보수 업무를 하면서 Footer와 같은 공통 컴포넌트를 스토리북에 넣어줘야 하는 일이 있었다.

큰 문제없이 작업을 완료하고 원격 저장소에 push를 하니, 로컬에서 빌드되던 스토리북의 배포가 실패하고 있었다.

원인을 살펴보니, Footer 내부에 graphql codgen으로 생성된 typescript 파일에 대한 의존성이 있어서 codegen을 하지 않는 배포환경에서의 스토리북 빌드가 실패하던 것이었다.

정적인 데이터를 위주로 회사의 기본적인 정보를 보여주는 Footer였기 때문에 어째서 서버 타입의 의존성이 있는지 이해하지 못했으나, 자세히 살펴보니 서버 데이터를 기반으로 codgen을 해서 사용하는 일부 enum 값에 대해서 상수처럼 사용하고 있었다.

예를 들어 대표적으로는 다국어 서비스를 하는 우리 회사에서 지원하는 언어와 화폐에 대한 값들이 그에 해당한다. 사실상 상수로 사용되지만 데이터의 출처가 graphql enum인 경우이다.

import { CurrencyType, LanguageType } from 'graphql/types';

export enum LanguageType {
  Chinese = 'CHINESE',
  English = 'ENGLISH',
  Hongkong = 'HONGKONG',
  Japanese = 'JAPANESE',
  Korean = 'KOREAN',
  Taiwan = 'TAIWAN',
  Thai = 'THAI',
  Vietnamese = 'VIETNAMESE'
}

이러한 상수 enum에 대해 의존성을 가지고 있는 코드들이 Footer 내부에도 존재했고, 이 때문에 빌드가 실패했던 것이다.

배포 환경에서 스토리북 빌드 전에 codegen을 하는 방법도 있었지만, 디자인 시스템을 보여주려는 원래 목적과 다르다고 생각했고, 이러한 상수 값들이 아닌 서버 의존성이 존재한다면 해당 컴포넌트를 스토리북에 등록할 상황 자체가 생기지 않는 게 맞다고 판단했다.

결론적으로 몇 가지 대표적으로 사용되는 상수들에 대해서만 모킹을 하기로 결정했고, 모킹 자체는 스토리북 웹팩 설정에서 간단하게 해줄 수 있었다.

import type { StorybookConfig } from '@storybook/core-webpack';

const config: StorybookConfig = {
  // ...
  webpackFinal: (config) => {
    if (config.resolve?.alias) {
      config.resolve.alias['graphql/types'] = require.resolve('./__mocks__/graphqlTypes.ts');
    }
    return config;
  },
};

export default config;

모킹 파일은 대략 아래와 같이 모킹이 필요한 대표적인 enum 값들만 기재해두었다.

// .storybook/__mocks__/graphqlTypes.ts
enum LanguageType {
  Chinese = 'CHINESE',
  English = 'ENGLISH',
  Hongkong = 'HONGKONG',
  Japanese = 'JAPANESE',
  Korean = 'KOREAN',
  Taiwan = 'TAIWAN',
  Thai = 'THAI',
  Vietnamese = 'VIETNAMESE',
}

LanguageType enum을 export 하는 순간 프로젝트의 모든 경로에서 모킹 파일에 있는 LanguageType을 참조할 수 있기 때문에 한 객체에 모아서 export를 해준다.

module.exports = {
  LanguageType,
  CurrencyType,
};

javascript에서는 export 예약어를 사용할 경우 모듈을 내보낼 범위에 대해서 명시적으로 나타낼 수 없기 때문에 아래와 같은 문제가 흔하게 발생한다.

모킹 객체를 만들어서 모킹을 했지만, 직접 모킹하지 않은 프로퍼티 접근을 감지하고 에러 메시지를 출력해주기 위해 Proxy를 사용하기로 결정했다.

방법은 다음과 같다.

proxy 객체를 만들어서 모킹하지 않은(하지 않을) prop 접근을 감지해서 에러를 발생시킨다.
proxy 객체를 module.exports로 내보낸다.

const mockTypes = {
  LanguageType,
  CurrencyType,
  CountryType,
  CountryCallingCodeType,
};

const mockingProxy = new Proxy(mockTypes, {
  get: (target, prop) => {
    if (prop === '__esModule') {
      return;
    }
    if (Reflect.has(mockTypes, prop)) {
      return Reflect.get(mockTypes, prop);
    }
    throw Error(
      `모킹되지 않은 enum값이 사용되었습니다. 서버 의존성이 있는 컴포넌트를 스토리북에서 사용하는걸 자제해주세요. [${prop.toString()}]`,
    );
  },
});

module.exports = mockingProxy;

천천히 살펴보자. 먼저 mockTypes 객체의 프로퍼티에 접근하는 요소들을 다루기 위해 get Handler를 커스터미아징 했다.

'__esMoudle' 프로퍼티는 bebel의 트랜스파일 과정에서 해당 파일의 모듈 시스템에 따라 선택적으로 추가되는 값이다. 번들링 과정에서 babel이 ESM과 CommonJS 모듈 모두 동일한 인터페이스로 사용할 수 있게 하기 위해 ESM 기반의 모듈에 '__esModule'이라는 프로퍼티를 true로 할당하여 일종의 flag로 사용한다.

babel에서 확인

'__esModule'은 다음과 같이 모듈을 불러오는 과정에서 같은 식별 함수를 통해 동일한 인터페이스로 처리될 수 있게 된다.

function esModuleInterop(module) {
  return module.__esModule ? module : {default: module};
}

트랜스 파일 과정에서의 CommonJS, ESM 처리는 아래 글에서 자세히 볼 수 있다.

https://ui.toast.com/weekly-pick/ko_20190418

따라서 babel을 통해 트랜스파일링 된 코드에서 '__esModule' 프로퍼티에 대한 접근은 필연적으로 발생할 수밖에 없으니 해당 프로퍼티의 접근에 대해서는 에러를 던지지 않도록 처리를 해 둔다.

최종적으로 이러한 처리를 통해 만들어진 Proxy 객체를 CommonJS 방식으로 내보내고 webpack 설정에서 require를 통해 가져오면 된다.

참고

Proxy - JavaScript | MDN

The Proxy object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.

developer.mozilla.org

You don't know JS module

자바스크립트 개발을 하다 보면 다양한 모듈 정의 방법을 마주치게 된다. ES 모듈, CommonJS 모듈, AMD 모듈 등 자바스크립트에는 다양한 모듈 시스템이 공존하는데, 각 모듈은 모두 다른 방식으로

ui.toast.com

함께 자라기 - 컴퓨터로 대체되기 힘든 일

눅눅한 피부 — Tue, 1 Aug 2023 19:58:44 +0900

옥스퍼드 대학교에서 발표한 <고용의 미래> 논문을 참고하여, 직무 역량 DB에 속하는 702개 직종의 컴퓨터 대체 확률을 계산

컴퓨터화에 병목이 되는 주요 역량은 대표적으로 다음과 같음

1. 독창성: 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법들을 만들어내기
2. 사회적 민감성: 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
3. 협상: 사람들을 화해(조율)시키고 서로 간의 차이를 조정하려고 노력하기
4. 설득: 다른 사람들의 마음이나 행동을 바꾸게 설득하기
5. 타인을 돕고 돌보기: 개인적 도움, 치료, 감정적 지지, 혹은 동료, 고객에게 기타 개인적 도움을 제공하기

논문에서는 프로그래머와 소프트웨어 개발자를 아래와 같이 정의

프로그래머 (스펙대로 코드를 만드는 사람)
소프트웨어 개발자 (사용자의 요구사항을 분석하고 그에 대한 솔루션을 설계하는 것을 포함)

컴퓨터 대체 가능 확률을 계산

소프트웨어 개발자: 0.042 (4.2%)
컴퓨터 프로그래머: 0.48 (48%)

컴퓨터 프로그래머는 다른 사람이 준 스펙대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 크게 필요하지 않음.

반면, 소프트웨어 개발자는 소프트웨어로 뭘 만들지 고민하고 설계하는 과정이 포함되며, 그 과정에서 타인과 상호작용 하는 업무가 많음

즉 개발자에게는 더 높은 수준의 협상 능력이 필요하다는 뜻

내가 실제로 매일 하는 일이 어떤 성격인지 돌이켜 볼 필요가 있음

직책이 선임 개발자가 되었다고 해서 안심할 일이 아니라, 자신이 주로 하는 일이 남들이 시킨 대로 혼자 프로그램을 만드는 일인지, 창의적으로 의견을 나누며 다른 사람과 협력하는 일인지를 진지하게 생각해 볼 필요가 있음

웹 성능 최적화 끄적끄적

눅눅한 피부 — Tue, 1 Aug 2023 19:41:17 +0900

브라우저에서의 렌더링 최적화

DOM 최적화

HTML 구문 오류 최소화 (CPU 리소스 절약)
HTML 중첩 완화 (depth 깊을수록 layout 계산 리소스 증가)
<script> 지연 로드 (async, defer)
- GTM(Google Tag Manager) 스크립트 기본값은 async=true
- GTM 실행 시점을 defer로 미뤄 병목을 방지해야 할까?
  - 트레이드오프 고려 필요
  - 로드 속도를 빠르게 할 수 있지만, 그 효과가 크지 않고 GTM 로드 시점이 늦춰지면서 조기 이탈한 사용자에 대한 정보 누락 가능
  - https://stackoverflow.com/questions/72531926/defer-attribute-for-the-google-tag-manager

async, defer

실무에 써먹을 만한 DOM 최적화

windowing

라이브러리 사용, 혹은 직접 구현

content-visibildity css

.content-block {
  content-visibility: auto;
  contain-intrinsic-size: 1000px; /* Explained in the next section. */
}

display:none 대안으로 content-visibility: hidden 고려

Compare it to other common ways of hiding element's contents:

display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new element with the same contents. visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it (and it's subtree) still takes up geometric space on the page and can still be clicked on. It also updates the rendering state any time it is needed even when hidden.

content-visibility: hidden, on the other hand, hides the element while preserving its rendering state, so, if there are any changes that need to happen, they only happen when the element is shown again (i.e. the content-visibility: hidden property is removed).

Some great use cases for content-visibility: hidden are when implementing advanced virtual scrollers, and measuring layout. They're also great for single-page applications (SPA's). Inactive app views can be left in the DOM with content-visibility: hidden applied to prevent their display but maintain their cached state. This makes the view quick to render when it becomes active again.

In an experiment, Facebook engineers observed an up to 250ms improvement in navigation times when going back to previously cached views.

지원 브라우저

그렇게 많지는... 않다

@supports selector로 fallback 처리 가능

    @supports (content-visibility: hidden) {
      content-visibility: hidden;
    }
    @supports not (content-visibility: hidden) {
      display: none;
    }

IE 컷

참조

https://web.dev/content-visibility/

content-visibility: the new CSS property that boosts your rendering performance

The CSS content-visibility property enables web content rendering performance benefits by skipping rendering of off-screen content. This article shows you how to leverage this new CSS property for faster initial load times, using the auto keyword. You will

web.dev

https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports_static

CSS: supports() static method - Web APIs | MDN

The CSS.supports() static method returns a boolean value indicating if the browser supports a given CSS feature, or not.

developer.mozilla.org

https://d2.naver.com/helloworld/59361

짜릿해

눅눅한 피부 — Tue, 25 Jul 2023 22:45:03 +0900

DragGPT 익스텐션을 만들어서 너무 알차게 쓰고 있다 보니 쓸 때마다 짜릿하다.

제일 많이 사용하는 기능은 번역인데, 구글 번역 익스텐션이 자체적인 dom manipulation을 해버리다 보니 <code> 나 <strong> 태그 사이에 있는 문자들은 이상하게 번역되는 등 귀찮은 이슈들이 있었다.

window.getSelection()으로 정직하게 드래그 한 텍스트만 긁어오는 DragGPT에선? 그런 이슈가 없지 후후...

빠른 대화 모드나 gpt4 토글등의 기능도 추가하고서 유용하게 쓰고 있어서 매우 좋다.

대화 기록을 options 창에서 볼 수 있도록 하는 기능은 진행 중인데, 아직까지 큰 필요성을 못 느껴서 진전이 없는 것 같기도 하다.

DragGPT 소스코드는 깃헙에 모두 공개되어 잇는데, 신기하게도 미국의 한 스타트업에서 해당 레포를 Fork 해서 프로덕션을 구성한다는 연락을 받았다. 자기만족 코드가 많아 프로덕션에서 사용한다고 하니 좀 찔리지만... 이런 순간들은 참 보람차다.

내가 자주 사용하는 슬롯들

드래그 GPT - 드래그로 쉽게 AI를 시작해보세요!

드래그 후 버튼 클릭만으로 간단하게 선택한 내용을 ChatGPT에게 물어보거나 요청할 수 있어요!

chrome.google.com

사람은 변한다

눅눅한 피부 — Sat, 15 Jul 2023 14:23:36 +0900

나는 예전부터 피드백이 고팠다.

특히 나를 성장시킬 수 있는 양질의 피드백에 큰 갈증이 있었다.

첫 회사에서 CTO님께 종종 여쭤봤던 것 같다. 제가 뭘 더 하면 성장할 수 있을까요? 어떤 점을 채워나가야 할까요?

CTO님은 무리하지 말고, 페이스 잃지 말고, 성장에 대한 욕구를 변치 않게 지금처럼만 하면 된다고 말했다.

지금처럼만 해서 될까요? 그리고 성장에 대한 욕구 변할것 같지 않은데...

사람은 생각보다 금방 변하더라구요.

씁쓸하게 말씀하시던 CTO님의 그 말이 오래도록 잊혀지지 않는다.

지금 생각해보면 그 말을 듣고 오기가 생겼던 것 같다.

남들은 다 변하더라도 나는 변하지 말아야지.

늘 치열하게 노력해야지. 진짜 잘해져야지.

주말 내내 놀지는 말아야지. 최소한 하루는 뭐라도 의미있는 일을 해야지.

내 주변 사람들에게 도움을 주고 꾸준히 인정받는 사람이 되어야지.

내 실력을 숫자로, 수준으로 계산하지 말아야지. 늘 벡터로 계산해야지.

CTO님의 그 말을 들은지도 2년이 훌쩍 넘었다.

사람은 변한다. 맞는 말인 것 같다.

그래도, 더 좋은 방향으로 변하기 위해 하루하루 발버둥을 쳐본다.

즐겁기도 고통스럽기도 하지만 어차피 세상 만사가 다 그런걸 뭐.

React + xState

눅눅한 피부 — Sat, 15 Jul 2023 00:37:02 +0900

2023.03.20 개발팀 세미나

Typescript의 공변성과 반공변성

눅눅한 피부 — Fri, 14 Jul 2023 20:16:43 +0900

공변성과 반공변성

'공변성(Covariance)'과 '반공변성(Contravariance)'은 Typescript를 다루는 개발자라면 누구나 매일매일 접하고 또 사용하는 개념이지만, 나를 포함해서 해당 개념을 매번 의식하고 인터페이스를 설계하는 사람은 많지 않을 것이다.

공변성과 반공변성이 타입스크립트에서 가지는 의의를 이해하기 전에, 먼저 공변성이 뭔지, 반 공변성이 뭔지부터 이해하고 가보자.

공변성

더 많이 파생된(더 구체화된) 형식을 사용할 수 있다.

I<T'> 인스턴스 타입을 I<T> 형식의 변수에 할당할 수 있다.

반공변성

덜 파생적인(더 제네릭한) 형식을 사용할 수 있다.

I<T> 인스턴스를 I<T'> 형식의 변수에 할당할 수 있다.

쉽게 풀어서 설명하려고 해도 되지 않으니 예시를 들어서 한 번 살펴보자.

다음과 같은 타입 A,B,C가 있다.

type A = string
type B = string | number
type C = string | number | null

이제 함수 Foo라는 타입을 선언해보자.

type Foo = (b: B) => B;

이제 이 함수의 타입을 지키면서 안전하게 호출할 수 있는 함수는 다음 중 어떤 함수일까?

const foo1: Foo = (a: A) => {
  return {} as A;
};

const foo2: Foo = (a: A) => {
  return {} as C;
};

const foo3: Foo = (c: C) => {
  return {} as C;
};

const foo4: Foo = (c: C) => {
  return {} as A;
};

A는 B의 서브타입이며, B는 C의 서브타입이다. 그러므로 A는 C의 서브타입이다.

(반대의 관계는 슈퍼타입)

foo1부터 살펴보자. 해당 함수는 안전한가?

인자로 받는 A는 B의 서브타입으로, B에서 number가 빠져있다. foo1을 호출하는 곳에서는 Foo의 인터페이스에 맞게 인자로 number를 넘겨줄 수 있을텐데, 그에 대한 처리가 되어있지 않아 위험해보인다.

같은 이유로 같은 인자를 받는 foo2 역시 위험해보인다.

foo3을 살펴보자. 해당 함수는 안전할까?

인자로 받는 C는 B의 슈퍼타입으로, B에서 null이 추가된 타입이다. foo3을 호출하는 곳에서는 Foo의 인터페이스에 맞게 string | number를 넘겨줄 수 있다. 이 경우 안전하다고 할 수 있겠다.

이제 반환값을 보자. 반환값인 C는 B에서 null이 추가된 타입이다. foo3을 호출하는 곳에서는 Foo의 인터페이스에 맞게 반환값인 string과 number에 대한 처리를 하게 될 것이다. 예상치 못한 null이 반환될 수 있으니 위험해보인다.

foo4를 살펴보자. 해당 함수는 안전할까?

인자로 받는 C는 foo3에서 살펴봤듯 안전하다고 할 수 있고, 반환값을 살펴보자. 반환값인 A는 B에서 number가 제거된 타입이다. foo4를 호출하는 곳에서는 Foo의 인터페이스에 맞게 반환값인 string | number에 대한 처리를 하지만, 실제로 반환되는 타입은 string일 것이다.

그러므로 foo4는 인자와 반환값 모두 안전한 함수이다!

뭔소리야?

직관적으로 이해하기 쉽지 않아서 설명도 실제 호출을 기준으로 했지만, 설명을 듣고 나서도 쉽사리 이해되지 않는다.

하지만 위 예시를 통해서 두 가지의 규칙을 발견할 수 있었는데,

1. 함수의 파라미터는 더 좁은 타입을 사용할 수 있다. (반공변성 - 더 구체적인 타입을 사용할 수 있다)

2. 함수의 반환값은 더 넓은 타입을 사용할 수 있다. (공변성 - 더 일반적인 타입을 사용할 수 있다)

타입스크립트에서 함수의 타입은 위의 규칙으로 동작한다.

단, 위 가정은 타입스크립트의 strict flag, 정확히는 strictFunctionTypes flag를 활성화 했을때의 동작이며, 해당 flag가 off인 경우 함수의 파라미터는 공변성과 반공변성을 모두 갖도록 동작한다. 이 경우에는 이변성(Bivariance)을 갖고 있다고 한다.

왜?

사용 사례에서 살펴보았듯, 파라미터가 반공변성을 가지는 것이 안전한데 왜 타입스크립트의 기본 설정은 그렇지 않은걸까?

사실 모든 사용 사례에서 파라미터가 반공변성을 가지는 것이 적절한 것은 아니다.

Array.push 메소드의 시그니처를 살펴보자.

interface Array<T> {
    //~~~~
    /**
     * Appends new elements to the end of an array, and returns the new length of the array.
     * @param items New elements to add to the array.
     */
    push(...items: T[]): number;
	//~~~~
}

Array<string | number> 에 string을 하나 넣고 싶다면 push 메소드를 사용하게 될 것이다.

이 경우 push()의 타입은 (...items: Array<string | numebr>) => number 가 된다.

함수 파라미터의 반공변성에 의거하면, push 메소드에 (...items: Array<string>) => number를 할당할 수 없다.

이제 뭔가 또 논리적으로 이상하다.

숫자와 문자로 이루어진 배열에 문자를 추가하는 동작이 위험하지 않기 때문에 이 경우에는 함수의 파라미터가 공변성을 가지는 것이 맞다는 결론이 나오게 된다.

--strict 환경에서도 Array.push() 문제 없던데?

맞다. 나를 포함한 많은 타입스크립트 개발자들이 TypeSafe한 개발 환경을 위해 strict flag를 켜두지만, Array.push를 사용하면서 반공변성으로 인한 곤란함을 겪지는 않는다.

비밀은 메소드를 선언하는 형태에 있는데,

interface Array<T> {
    push(...items: T[]): number;
}

interface Array<T> {
    push: (...items: T[]): number;
}

위의 방식의 선언과, 아래 방식의 선언이 다르게 동작하는(...) 것이다.

https://github.com/microsoft/TypeScript/pull/18654

The stricter checking applies to all function types, except those originating in method or construcor declarations. Methods are excluded specifically to ensure generic classes and interfaces (such as Array<T>) continue to mostly relate covariantly.

정말 미묘하면서 알기 힘든 포인트로 공변성을 다룰 수 있는 길을 열어둔 것이다.

By the way, note that whereas some languages (e.g. C# and Scala) require variance annotations (out/in or +/-), variance emerges naturally from the actual use of a type parameter within a generic type due to TypeScript's structural type system.

C#이나 Scala 혹은 Kotlin처럼 이러한 개념을 드러내는게 좋았을까?

적어도 인지하기 어려운 미묘한 문법 차이로 공변성을 제어하는 것 보다는 확실한 예약어를 추가하는게 낫지 않았을까...? 하는 생각이 든다.

추가

typescript 4.7 부터 타입 제네릭에 공변, 반공변에 대해 명시적으로 표기가 가능해졌다.

type Getter<out T> = () => T;

type Setter<in T> = (value: T) => void;

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html#optional-variance-annotations-for-type-parameters

Documentation - TypeScript 4.7

TypeScript 4.7 Release Notes

www.typescriptlang.org

참고

https://learn.microsoft.com/ko-kr/dotnet/standard/generics/covariance-and-contravariance

제네릭의 공 분산과 반공 분산

.NET 제네릭에서 파생된 형식을 더 많이 사용할 수 있는 공변성(Covariance) 및 파생된 형식을 더 적게 사용할 수 있는 반공변성(Contravariance)에 대해 알아봅니다.

learn.microsoft.com

https://seob.dev/posts/%EA%B3%B5%EB%B3%80%EC%84%B1%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/

공변성이란 무엇인가 / seob.dev

TypeScript의 공변성과 --strictFunctionTypes 옵션에 대해서 알아봅니다.

seob.dev

https://edykim.com/ko/post/what-are-covariance-and-contravariance/

공변성과 반공변성은 무엇인가?

Stephan Boyer의 What are covariance and contravariance?을 번역한 글이다. 공변성과 반공변성은 무엇인가? 서브타이핑은 프로그래밍 언어 이론에서 까다로운 주제다. 공변성과 반공변성은 오해하기 쉬운 주

edykim.com

https://github.com/microsoft/TypeScript/pull/18654

Strict function types by ahejlsberg · Pull Request #18654 · microsoft/TypeScript

With this PR we introduce a --strictFunctionTypes mode in which function type parameter positions are checked contravariantly instead of bivariantly. The stricter checking applies to all function t...

github.com

TCP/IP 인터넷(네트워크) 계층

눅눅한 피부 — Thu, 22 Jun 2023 20:29:30 +0900

TCP/IP 인터넷(네트워크) 계층

역할 세 줄 요약

IP 프로토콜을 사용하여 호스트 간의 통신에 필요한 주소 관리와 경로 제어를 수행한다.
패킷을 라우팅하여 수신 호스트까지 전달한다.
데이터의 오류 확인 및 수정을 위한 ICMP 프로토콜을 제공한다.

주요 프로토콜

프로토콜이란?

패킷 교환 과정에서 정보를 주고받는 데 사용하는 규약이며, 송/수신 호스트의 주소 지정과 패킷 분할 및 조립 기능을 담당

= 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 쓰이는 통신규약

IP 프로토콜 (Internet Protocol)

대표적인 프로토콜 (IP가 이미 인터넷 프로토콜의 약자인데 왜 IP 프로토콜이라 부르는지...?)

송/수신 호스트가 패킷 교환 네트워크(PSN: 패킷 스위칭 네트워크)에서 정보를 주고받는데 사용

일명 아이피

IP의 정보는 패킷이라는 단위로 쪼개져서 나누어 전송

특징

비신뢰성: 패킷이 전송되는 과정에서 유실, 중복, 섞임 등이 발생할 수 있으며, 이러한 문제는 인터넷이라는 분산 구조에서 기인함. 이러한 문제에 대해서 IP 프로토콜은 보장해주지 않는다. 왜냐? 속도를 위해서.

이런 문제를 대응하고자 한다면 상위 프로토콜인 TCP등에서 구현을 하면 된다. 아마 수신자 입장에서 버퍼를 두고 순서를 정렬해서 받기 + 빠진 부분 체크하는 등의 구현이 이뤄지지 않을까 싶다.
비연결성: IP 프로토콜은 데이터 전송 전에 송신자와 수신자가 미리 약속을 하거나 연결을 설정해두지 않고도 패킷을 전송할 수 있다. 인터넷이 유연하고 확장성 높은 구조를 갖출 수 있게 하지만, 전송 과정에서의 제어나 예측 가능성은 포기한다.

쉽게 말해서 아빠와 아들이 하는 캐치볼이 아니라는 뜻. 보낸다? 같은 이야기 없이 다짜고짜 보낸다.

상위 프로토콜에서 preflight나 TLS handshake 등의 기술이 약간 결은 다르지만 본격적인 연결 전에 먼저 확인 과정을 거친다는 점에서 일종의 비연결성을 보완하는 수단이라고 볼 수 있지 않을까?

ICMP 프로토콜 (Internet Control Message Protocol)

데이터 전송 과정에서의 오류 메시지 등을 다루는 데 주로 사용된다고 한다.

데이터가 대상에 도달했는지, 그리고 도달 시간이 적절한지 등을 확인하는데 사용되며, 네트워크의 건강상태를 확인한다고 보면 된다.

DDoS 공격에도 사용할 수 있다.

통신을 하는 경우 ICMP를 사용하여 일부 데이터가 누락된 경우 수신자 → 송신자로 전송되는 에러 메시지를 생성할 수 있다.

주요 역할

에러 보고: 지나치게 크기가 큰 데이터 패킷이 전송되는 경우 라우터는 해당 패킷을 폐기하고 ICMP 메시지를 발신자에게 전송해서 네트워크 전송에 문제가 생겼음을 알려준다.
네트워크 진단: trace route(패킷 전송 경로 추적 명령어), ping 모두 ICMP를 사용한다.
네트워크 성능 저하(공격):
1. ICMP Echo 요청을 담은 ping을 대량으로 보내 서비스를 다운시키는 공격
2. ICMP Redirect 메시지를 수정하여 목적지 주소를 조작하는 중간자 공격
3. ICMP Echo 요청을 대량으로 브로드캐스팅 하여 네트워크 상의 모든 호스트가 ICMP Reply 응답을 하도록 유도한다. 이 때 공격 대상이 되는 서버를 Reply 메시지의 수신자로 하여 대량의 트래픽을 유도하는 공격

ARP 프로토콜 (Address Resolution Protocol: 주소 결정 프로토콜)

IP 주소를 물리적인 네트워크의 주소(MAC 주소)로 바인딩 시키는 데 사용된다.

ARP의 구조

송신자의 MAC/IP 주소, 그리고 수신자의 MAC/IP 주소가 모두 기재되어 있다.

호스트 A가 호스트 B에게 IP를 통한 패킷을 전송하려고 한다면? MAC 주소를 모르는데 어떻게 전송을 하게 될까?

A와 B가 같은 네트워크에 있는 경우

A는 같은 네트워크 대역에 B의 IP주소에 해당하는 단말기가 있는지를 광역으로 물어봄(ARP 요청 브로드캐스팅)
A는 B의 MAC 주소를 모르기 때문에 ARP 내부의 타겟 MAC 주소는 기본값인 게이트웨이의 MAC 주소(FF:FF:FF:FF:FF:FF)로 기록해서 일단 전송
네트워크 스위치는 A의 MAC 주소를 자신의 MAC 주소 테이블에 기록(기존에 없었다면)
네트워크 스위치는 B의 IP주소에 해당하는 MAC 주소가 테이블에 있는지 확인
1. B의 MAC 주소가 테이블에 있으면 A에게 해당 MAC 주소를 알려줌
2. B의 MAC 주소가 테이블에 없다면, A가 보낸 ARP 요청이 B에게도 전달됨. B는 ARP요청을 받고 자신의 MAC 주소를 알려주는 응답을 보냄. 스위치는 B의 응답에 있는 MAC 주소를 테이블에 저장
A는 전달받은 MAC 주소를 통해 마침내 B와 통신 시작

A와 B가 다른 네트워크에 있는 경우

같은 네트워크에 IP에 해당하는 B가 존재하는지 확인
마찬가지로 일단 ARP 내부의 타겟 MAC 주소는 기본값인 게이트웨이의 MAC 주소(FF:FF:FF:FF:FF:FF)로 기록된 상태
내부 네트워크에서 B를 찾지 못했다면 ARP 요청은 게이트웨이(라우터)로 전달
ARP 패킷은 게이트웨이를 거치면서 최종적으로 B의 IP 주소를 가진 네트워크에 도달. 이 과정에서 ARP target MAC 주소는 계속 변경되지만 IP 주소는 유지
최종적으로 B를 찾고, B는 자신의 MAC 주소를 담아 ARP 응답을 A에게 전송. 요청인지 응답인지 구분하는 방법은 ARP 패킷 구조에 있는 Operation 값으로 판별. 1은 요청, 2는 응답
이제 A와 B는 MAC 주소를 통해 통신 시작 (ARP cache)

ARP를 통한 공격?

대표적인 공격은 ARP 스푸핑.

공격자는 공격하려는 대상의 네트워크에 접근하여 ARP 프로토콜로 모든 장치의 MAC 주소를 확인
그 후에, 가로채려는 IP 주소에 해당하는 MAC 주소를 자신의 MAC 주소로 교체 (ARP 요청을 통해 ARP cache 테이블에 데이터를 수정한다고 보면 됨)
사용자가 전송하려는 데이터 혹은 요청이 공격자가 설정한 MAC 주소로 오게 됨

사용자는 전혀 다른 곳에 접속하는 셈인데 위화감을 느끼지는 않을까?

중간자 공격을 통해 트래픽을 원래 보내려던 곳으로 리다이렉트 → 응답도 본인이 먼저 받은 후 사용자게에 다시 보내는 방식을 사용하기 때문에 아무 일도 일어나지 않은 것처럼 보이게 할 수 있다.

그 외 프로토콜…

RARP 프로토콜 (Reverse ARP)

MAC 주소에서 IP 주소를 찾는 데 사용
IP주소에서 MAC 주소를 찾는 ARP 프로토콜의 정 반대(Reverse)

IGMP 프로토콜

다중 캐스트 그룹 관리를 위해 사용

IPsec 프로토콜 (Internet Protocol Security)

TCP/IP에서 사용되는 인증과 암호화 방법을 제공하는 보안 프로토콜. IPsec은 두 종류의 프로토콜로 구성된다.
- AH(Authentication Header) 프로토콜 IP 패킷의 출발지 정보와 패킷 데이터에 대한 인증을 제공해준다. 이를 통해 패킷의 위변조 여부를 검사할 수 있음
- ESP(Encapsulating Security Payload) 프로토콜 IP 패킷 전체를 암호화. 이를 통해 패킷의 내용을 해독할 수 없게 만듦
주로 VPN이나 원격 액세스, 안전한 네트워크를 위해 사용하며 일반적으로 기밀성과 무결성을 보장하기 위해 사용된다.

참조

인터넷 프로토콜

인터넷 프로토콜 스위트

인터넷 제어 메시지 프로토콜

ICMP(인터넷 제어 메시지 프로토콜)란? | Fortinet

Address Resolution Protocol

[이해하기] ARP (Address Resolution Protocol) 프로토콜 | STEVEN J. LEE

[Network] ARP(주소 결정 프로토콜)에 대하여

Ubiquiti Help Center

Address Resolution Protocol (ARP) Parameters

IPsec

나는 무엇을 하고 싶은가

눅눅한 피부 — Sun, 11 Jun 2023 18:35:44 +0900

정말로 내가 하고 싶은게 무엇일까?

돈을 많이 버는 것?

얼마가 내가 만족할만한 많은 돈인가?

말 그대로 나는 무엇을 하고 살고 싶은지, 앞으로 5년 후, 10년 후에 어떤 일을 하고 싶은지에 대한 고민이 많다.

학창 시절에는 성인이 되고 직장인이 되면 진로고민(?)은 더 이상 하지 않을 줄 알았는데, 나름 획일화된 평가 시스템과 방향성이 제시되던 학창 시절과는 다르게 지금은 어떤 길이 후회가 적은 길일지에 대해 예측하기가 더욱 어렵다.

인생에 있어서 좋은 기회라는 것은 내 선택과 노력으로 어느정도 이끌어낼 수 있는 것이라고 생각하면서도, 찾아온 그것이 기회인지 아닌지를 판단하는 것이 너무나도 어렵다. 정말 좋은 기회인지 아닌지 판단하기 어려우면 기회라고 볼 수 없는게 아닌가? 싶은 생각도 들고...?

짧은 인생에서 여러 선택을 했고, 결과를 통해 얻은 귀중한 교훈까지 고려한다면 실패한 선택은 없었다고 감히 생각한다.

향후 나의 3~5년 삶의 행태와 그 이후의 커리어, 그리고 내 주변 사람들에게도 모두 영향을 미칠 수 있는 선택의 분기라서 더 고민이 되는 것 같다.

프로세스 스케줄링(Process scheduling)

눅눅한 피부 — Sun, 11 Jun 2023 18:02:59 +0900

Scheduler?

기본적으로 모든 프로세스는 크게 두 가지 단계로 이루어져 있다. 하나는 CPU만 사용하는 CPU burst 단계, 다른 하나는 I/O(input/output) 작업만 하는 I/O burst 단계이다.

각 프로세스는 CPU에 할당되어 작업을 하게 되고, 해당 CPU의 자원을 점유하여 하고자 하는 동작을 실행한다. 문제는 I/O busrt 단계에서는 CPU가 놀게 된다는 점이다.

CPU가 노는 시간을 줄이기 위해 고안된 방법이 바로 스케줄링, 이러한 동작을 하는 모듈을 스케줄러라고 한다.

목적

프로세스 스케줄링은 다음 두 가지 목적을 위해 존재한다.

CPU의 성능을 높인다
프로그램의 성능을 높인다

CPU 입장에서의 성능이란? 다음과 같이 나타낼 수 있다.

CPU 이용율: 전체 시간 중 쉬지 않고 CPU가 일한 시간
처리량: 시간당 수행 완료한 프로세스의 수

즉, CPU는 이용률과 처리량이 높아야 성능이 높다고 할 수 있다.

프로세스 혹은 프로그램 입장에서의 성능이란 무엇일까?

소요 시간: 프로세스가 대기 큐 > 작업 완료까지 걸리는 시간
대기 시간: 프로세스가 대기 큐에서 대기한 시간
응답 시간: 프로세스가 CPU를 할당받는 데까지 걸린 시간

즉, 소요시간, 대기시간, 응답시간이 낮아야 프로그램의 성능이 높다고 할 수 있다.

알고리즘

일단 아래와 같은 가정을 하고 살펴보자

모든 프로세스가 동일한 런타임(수행시간) 가진다
모든 프로세스는 동일하게 도착한다
모든 프로세스가 CPU burst만 한다
이미 프로세스의 런타임이 정해져 있고 cpu가 알고 있다

FCFS Scheduling (First Come First Served)

CPU에 오는 순서대로 할당하는 방식. (매우 심플)

FIFO 방식의 큐(Queue)와 동일한 방식이라고 이해해도 좋다.

사실 위의 전제조건에서는 어떤 방식을 사용하던 성능상의 차이가 없다.

여기서 1번 전제조건인 모든 프로세스가 동일한 수행시간을 가진다 는 조건이 변경된다면?

P1는 즉시 실행, P2, P3은 각각 20,25의 대기 시간을 갖게 되므로 평균 대기 시간이 15가 되어버린다.

어떻게 하면 효율적으로 배치할 수 있을까?

런타임이 짧은 P2, P3를 앞에 배치했더니 쨔잔! 평균 대기시간이 5로 짧아졌다.

위에서 본 바와 같이 하나의 긴 런타임을 가진 프로세스(P1)로 인해 CPU효율성이 낮아지는 문제는 Convoy Effect라고 한다.

이런 문제가 생길 수 있기 때문에 딱 봐도 FIFO 방식의 스케줄러는 한계가 명확하게 드러난다.

SJF Scheduling (Shortest Job First)

위에서 본 런타임이 짧은 프로세스를 앞에 배치해서 먼저 실행하는 방식이 바로 SJF 스케줄링이다.

이 방식의 장점은, 항상 주어진 프로세스에 대해 최소의 평균 대기 시간을 보장한다는 것이다.

최고의 알고리즘이고 항상 이 방식을 쓰면 좋겠지만… 두 가지 문제가 있다.

런타임이 긴 프로세스(P1)는 계속 뒤로 밀려나는 문제가 생긴다. 마치 백로그에 있는 우선순위(중) 태스크처럼… 이러한 현상을 기아(starvation) 현상이라고 한다.
앞서 했던 4번 전제조건 ‘이미 프로세스의 런타임이 정해져 있고 cpu가 알고 있다’는 상황은 이상적인 상황으로, 일반적으로는 과거의 런타임을 통한 추정만 가능하다.

SJF 스케줄링을 자세히 쪼개보면 두 가지 방식이 있다.

Non-preemptive SJF (비선점 방식)

2번 전제조건 ‘모든 프로세스는 동일하게 도착한다’의 조건이 만족되지 않는다면 무슨 일이 일어날까?

도착 시간이 다르다면, 현재 도착한 프로세스 중 가장 런타임이 짧은 프로세스(P1)가 CPU에 할당된다.

한 번 프로세스가 실행되면 완료까지 CPU를 점유하기 때문에 평균 대기시간은 4가 된다.

Preemptive SJF(선점 방식)

프로세스를 나누어서 실행할 권한이 CPU에게 있다면 다른 방식을 사용할 수 있는데, 이 방식이 바로 선점 방식이다.

이렇게 프로세스를 잘게 쪼개서 실행할 경우 평균 대기 시간은 3이 된다.

도착 시간 0에 실행 가능한 가장 짧은 런타임을 가진 프로세스 P1을 실행하다가, 시간 2가 되었을 때 더 짧은 남은 런타임을 가진 P2를 실행한다. (이 시점에 P1의 남은 런타임은 5) 시간 4가 되었을 때 도착한 P3을 실행한다. (이 시점에 P2의 남은 런타임은 2)

이 방식을 SRTF(Shortest Remaining Time First) 혹은 STCF(Shortest Time-to-Completion First)라고도 부른다.

눈치챘을지도 모르지만, P1는 가장 먼저 도착하고 7의 런타임을 가졌으나 가장 마지막에 완료된다. 앞서 말했던 기아 현상이 발생한 것이다.

Round Robin (RR) scheduling

세 번째 방식은 각 프로세스가 언제 끝나는지보다 언제 시작되는지를 중요하게 여기는 방식이다.

각 프로세스가 동일한 할당 시간(Time quantum)을 갖고 실행되며, 할당 시간이 끝나면 다시 Ready queue의 뒤로 가서 줄을 선다.

이미지로 보면 이해가 바로 된다.

도착 순서대로 할당 순서를 돌려가며 큐에 다시 넣기 때문에 기아 현상이 발생하지 않으며, 응답 속도가 빠르다. 다만 평균 소요 시간(Average Turnaround Time)은 길어지는데, 무슨 말인가 하니 P1는 13에, P2는 14에, P3은 15에 끝나는 것이다.

FCFS(FIFO) 혹은 SJF 방식이라면 각각 5,10,15 시점에 끝날 동작이 평균적으로 엄청 늦게 끝나게 된다.

이 문제는 할당 시간(프로세스를 쪼개는 시간 단위)을 늘려서 보완할 수 있으나 할당 시간의 크기가 커질수록 FCFS 방식과의 차이점이 사라지고, 할당 시간의 단위가 작아질수록 컨텍스트 스위칭의 오버헤드가 커지기 때문에 적절한(?) 할당 시간 배분이 매우 중요해진다.

Priority Scheduling

특정 기준으로 프로세스에 우선순위를 부여하고, 우선순위가 높은 프로세스를 CPU 할당하는 방식이다.

역시 우선순위가 낮은 프로세스는 계속 기다리기만 하는 기아 문제가 생길 수 있는데, 이를 방지하기 위해 오래 대기한 프로세스일수록 점점 우선순위를 올려주는 에이징 기법을 사용한다.

에이징 기법은 백로그에 쌓인 우선순위 Low 태스크들이 쌓이는 일을 방지하기 위해 적용해 보면 좋은 방법이지 않을까...?

독자적인 스케줄링 방식보다는 다른 스케줄링 알고리즘과 결합하여 사용하는 경우가 많다.

Multi-Level Queue Scheduling

Multi-Level Queue는 Ready Queue를 여러 개로 분할한 것이다. 각 큐는 독립적인 스케줄링 알고리즘을 가진다.

예를 들어, foreground에서 돌아가는 프로그램(메모장 + 그림판)은 응답 시간이 중요하기 때문에 Round Robin 스케줄링으로 동작시키고, background에서 돌아가는 batch task(업데이트, 다운로드 등) 등의 프로그램은 총 소요시간이 중요하기 때문에 FCFS(FIFO) 스케쥴링을 사용하는 것이다.

당연한 말이지만 이렇게 만들어진 각 큐에 대해서도 스케줄링이 필요하다.

유저가 당장 상호작용하는 foreground 큐의 우선순위를 항상 먼저 둘 수도 있고(이 경우 background 태스크에 대한 기아 현상 발생), Time Slice 방식을 통해 80%는 foreground, 20%는 background에 할당할 수도 있다.

프로세스 스케줄러를 보면서 얻은 인사이트

자바스크립트는 단일 스레드이다.(자바스크립트 런타임을 총괄한다면 멀티 쓰레드이지만 콜 스택 자체만 놓고 본다는 전제 하에)

React에서는 자바스크립트를 힘들게 쓰는 동작이 있는데, 바로 가상 돔(VDOM)의 diff를 계산하는 작업이다. React 화면 렌더링의 핵심 개념이며 모든 리액트 개발자들은 이 diff를 계산하는 한 사이클이 16ms를 넘지 않게 하기 위해 렌더링 최적화를 한다.

diff를 계산하는 로직이 무거워져 16ms를 넘기는 순간, 60 프레임을 보장할 수 없으며 브라우저에서 유저에게 버벅거림을 야기하기 때문이다.

무거운 프로젝트일수록 이러한 버벅거림이 심해질 위험성도 늘어나고, 개발자들이 신경 써야 하는 포인트도 늘어난다. React에서도 이러한 문제점을 인지하고 있고, 그래서 React18에서는 내부 구현체를 거의 새로 개발하는 수준의 변경사항을 통해 diff 비교에 사용되는 알고리즘을 스케줄링 방식으로 바꿨다.

변경이 즉시 필요하지 않은 일부 상태 변경에 대해서는 별도의 훅(useTransition, useDeferredValue)을 사용해 업데이트에 들어가는 계산을 마치 우선순위 스케줄링 방식과 같이 미룰 수 있다.

react18의 소스코드 변경사항 중 가장 큰 변경사항은 기존에 없던 Lane이라는 개념이 추가된 것인데, 이 Lane은 실제 차선을 예시로 들어 만들어진 개념이다.

(1차선은 추월차선으로 제일 빠른 속도이며, 2,3차선 순으로 속도가 느려진다.)

리액트는 몇 개의 Lane을 가지고 있을까?

export const TotalLanes = 31;

export const NoLanes: Lanes = /*                        */ 0b0000000000000000000000000000000;
export const NoLane: Lane = /*                          */ 0b0000000000000000000000000000000;

export const SyncHydrationLane: Lane = /*               */ 0b0000000000000000000000000000001;
export const SyncLane: Lane = /*                        */ 0b0000000000000000000000000000010;

export const InputContinuousHydrationLane: Lane = /*    */ 0b0000000000000000000000000000100;
export const InputContinuousLane: Lane = /*             */ 0b0000000000000000000000000001000;

export const DefaultHydrationLane: Lane = /*            */ 0b0000000000000000000000000010000;
export const DefaultLane: Lane = /*                     */ 0b0000000000000000000000000100000;

export const SyncUpdateLanes: Lane = /*                */ 0b0000000000000000000000000101010;

const TransitionHydrationLane: Lane = /*                */ 0b0000000000000000000000001000000;
const TransitionLanes: Lanes = /*                       */ 0b0000000011111111111111110000000;
const TransitionLane1: Lane = /*                        */ 0b0000000000000000000000010000000;
const TransitionLane2: Lane = /*                        */ 0b0000000000000000000000100000000;
const TransitionLane3: Lane = /*                        */ 0b0000000000000000000001000000000;
const TransitionLane4: Lane = /*                        */ 0b0000000000000000000010000000000;
const TransitionLane5: Lane = /*                        */ 0b0000000000000000000100000000000;
const TransitionLane6: Lane = /*                        */ 0b0000000000000000001000000000000;
const TransitionLane7: Lane = /*                        */ 0b0000000000000000010000000000000;
const TransitionLane8: Lane = /*                        */ 0b0000000000000000100000000000000;
const TransitionLane9: Lane = /*                        */ 0b0000000000000001000000000000000;
const TransitionLane10: Lane = /*                       */ 0b0000000000000010000000000000000;
const TransitionLane11: Lane = /*                       */ 0b0000000000000100000000000000000;
const TransitionLane12: Lane = /*                       */ 0b0000000000001000000000000000000;
const TransitionLane13: Lane = /*                       */ 0b0000000000010000000000000000000;
const TransitionLane14: Lane = /*                       */ 0b0000000000100000000000000000000;
const TransitionLane15: Lane = /*                       */ 0b0000000001000000000000000000000;
const TransitionLane16: Lane = /*                       */ 0b0000000010000000000000000000000;

const RetryLanes: Lanes = /*                            */ 0b0000111100000000000000000000000;
const RetryLane1: Lane = /*                             */ 0b0000000100000000000000000000000;
const RetryLane2: Lane = /*                             */ 0b0000001000000000000000000000000;
const RetryLane3: Lane = /*                             */ 0b0000010000000000000000000000000;
const RetryLane4: Lane = /*                             */ 0b0000100000000000000000000000000;

export const SomeRetryLane: Lane = RetryLane1;

export const SelectiveHydrationLane: Lane = /*          */ 0b0001000000000000000000000000000;

const NonIdleLanes: Lanes = /*                          */ 0b0001111111111111111111111111111;

export const IdleHydrationLane: Lane = /*               */ 0b0010000000000000000000000000000;
export const IdleLane: Lane = /*                        */ 0b0100000000000000000000000000000;

export const OffscreenLane: Lane = /*

리액트 내부에는 총 31개의 Lane을 가지고 있으며 각 Lane은 비트 연산을 통해 실제 로직에서 활용된다.

export function getHighestPriorityLane(lanes: Lanes): Lane {
  return lanes & -lanes;
}

export function pickArbitraryLane(lanes: Lanes): Lane {
  return getHighestPriorityLane(lanes);
}

function pickArbitraryLaneIndex(lanes: Lanes) {
  return 31 - clz32(lanes);
}

function laneToIndex(lane: Lane) {
  return pickArbitraryLaneIndex(lane);
}

export function includesSomeLane(a: Lanes | Lane, b: Lanes | Lane): boolean {
  return (a & b) !== NoLanes;
}

export function isSubsetOfLanes(set: Lanes, subset: Lanes | Lane): boolean {
  return (set & subset) === subset;
}

export function mergeLanes(a: Lanes | Lane, b: Lanes | Lane): Lanes {
  return a | b;
}

export function removeLanes(set: Lanes, subset: Lanes | Lane): Lanes {
  return set & ~subset;
}

export function intersectLanes(a: Lanes | Lane, b: Lanes | Lane): Lanes {
  return a & b;
}

useTransition 등의 훅을 활용해서 특정 동작을 동시성 렌더링(Concurrency Feature Render)으로 바꾸게 된다면, 해당 동작은 TransitionLane으로 들어가게 된다.

리액트의 내부 구현체에서 렌더링을 하며 TransitionLane은 늘 SyncLane 내부에 스케줄링된 업데이트 동작이 끝난 이후에 실행되게 된다.

사실 React18 구현에 대한 코드를 예전에 본 적이 있는데, Lane 개념에 대해서 와닿지 않는 부분이 있었다. 그런데 프로세스 스케줄링에 대해 학습을 하는 과정에서 React 개발자들이 어떤 콘셉트에서 영감을 받았는지 짐작할 수 있었다. 각 Lane은 결국 이름만 다른 하나의 Queue로, Multi-Level Queue Scheduling에서 영감을 받아 동시성 기능을 구현했다고 생각한다.

참조

https://johngrib.github.io/wiki/jargon/convoy-effect/

Convoy effect

수송대 효과, 호위 효과

johngrib.github.io

https://www.tutorialspoint.com/operating_system/os_process_scheduling.htm

Operating System - Process Scheduling

Operating System Process Scheduling - This tutorial covers concepts like overview of Operating System, Types, Services, Properties, Process Scheduling, CPU Scheduling algorithms, Deadlock, Multi-Threading, Memory Management, I/O, Disk Management, Interrupt

www.tutorialspoint.com

https://zoomkoding.github.io/os/2019/04/28/os-5.html

줌코딩의 코딩일기

Zoom in Coding from the Basic.

zoomkoding.github.io

https://rebro.kr/175

[운영체제(OS)] 5. 프로세스 스케줄링(Process Scheduling)

[목차] 1. CPU Scheduling 2. Scheduling Criteria 3. Scheduling Algorithm 4. Multiple-Processor Scheduling 참고) - https://parksb.github.io/article/9.html - KOCW 공개강의 (2014-1. 이화여자대학교 - 반효경) - Sogang Univ. Operating System Lec

rebro.kr

[디자인 패턴] 커맨드 패턴, 팩토리 메서드 패턴, 상태 패턴

눅눅한 피부 — Sun, 28 May 2023 18:00:17 +0900

커맨드 패턴

세 줄 개념

실행 기능 단위로 캡슐화 함으로써 여러 기능을 실행할 수 있는 재사용성 높은 클래스 설계
기능 자체를 캡슐화 하기 때문에 Invoker와 Reciver간의 의존성 자체를 제거(기능 자체의 세부구현 변경이 Invoker와 Reciver의 수정 없이 이뤄질 수 있음)
기능 자체를 다루는 로직이 필요할 때 사용(되돌리기, 히스토리 기록 등)

유용한 사례

실행 취소가 가능한 명령들을 다양하게 다뤄야 하는 텍스트 에디터
보상 트랜잭션
공유 리소스를 바탕으로 병렬 처리를 원할 때(ex. 커맨드 단위로 멀티 스레드에서 동작)

느낀 점

처음에 커맨드 패턴을 코드상에서 봤을 때 마치 side effect를 적극적으로 사용하는 패턴으로 보였음

excute()의 반환 타입이 실질적인 응답 데이터를 가지지 않는다는 점 + 매개변수를 넘기는 방식이 아니라는 점에서 그렇게 보았음

그러나 예제 코드를 자세히 보니 명령 자체를 캡슐화해서 그렇게 보이는 것 뿐이고, 매개변수 혹은 반환값에 대한 처리는 커맨드 객체 내부 구현 및 어플리케이션에서 커맨드를 바인딩 할 때 넘겨준다는 사실을 알았음

예시코드(refactoring.guru)

작성에 필요한 보일러 플레이트 코드가 있으며, 복잡성이 증가하는 단점은 있으나, 상기 커맨드 패턴이 유용한 사례에서 도입한다면 단점보다는 장점이 더 많은 좋은 패턴으로 보임

다만 각 커맨드의 인터페이스 설계를 잘 하지 않을 경우 커맨드 기능에 필요한 인터페이스 외에 너무 많은 컨텍스트의 정보를 들고 있게 될지도? (ex. 커맨드 호출 시점에 권한(로그인 여부)등의 확인이 필요하다면? 로그인 여부를 확인할 수 있는 기능을 커맨드 초기화시 주입해줘야함)

Command pattern

[Design Pattern] 커맨드 패턴이란 - Heee's Development Blog

커맨드 패턴

팩토리 메소드 패턴

팩토리 패턴과의 차이점

Simple Factory Pattern

단순히 인스턴스 생성 로직을 노출하지 않고 팩토리를 통해 객체 생성

SimpleFactory simpleFactory = new SimpleFactory();
IAnimal dog = simpleFactory.CreateDog(); // Create dog
IAnimal tiger = simpleFactory.CreateTiger(); // Create tiger

Factory Method Pattern

팩토리에 대한 인터페이스를 정의하고, 해당 인터페이스를 지킨 팩토리에서 어떤 인스턴스를 생성할지 결정(위임)

AnimalFactory dogFactory = new DogFactory(); 
IAnimal dog = dogFactory.CreateAnimal(); // Create dog

AnimalFactory tigerFactory = new TigerFactory();
IAnimal tiger = tigerFactory.CreateAnimal(); // Create tiger

조금 다른 예시

Simple Factory Pattern

Factory Method Pattern

Nokia Factory에 현재 클라이언트에서 사용하지 않는(호출되지 않는) 메소드가 추가될 경우

class NokiaFactory {
    // old code
    public void Foo() { ... }
}

Simple Factory Pattern에서는 MobileFactory 구현과 클라이언트에 영향을 주지 않고 구현할 수 없음

Factory Method Pattern에서는 NokiaFactory 구현만 바꾸면 클라이언트는 변경사항을 몰라도 됨

Simple factory vs Factory method

Design Patterns: Factory vs Factory method vs Abstract Factory

상태 패턴

세 줄 개념

객체의 현재 (유한)상태에 따라 동작을 제한하여 복잡성을 낮추는 것
전이(transition)를 통해 상태간의 변경을 일으킴
유한 상태 기계(finite state machine)의 개념에 가까움

유용한 사례

명확하게 상태별로 가능한 action들이 나눠진 경우 각 상태별 관심사 분리
조건문과 분기처리가 많은 복잡한 로직 단순화
컨텍스트의 상태 폭발 제어

XState

XState로 js+ts 진영에서 간단하게 상태 패턴 사용 가능

createMachine({
  initial: "waiting",
  states: {
    "waiting": {
      on: {
        "leave home": "on a walk",
      },
    },
    "on a walk": {
      initial: "walking",
      states: {
        walking: {
          on: {
            "speed up": "running",
          },
        },
        running: {
          on: {
            "slow down": "walking",
          },
        },
      },
      on: {
        "arrive home": "walk complete",
      },
    },
    "walk complete": {
      type: "final",
    },
  });

What are state machines and statecharts? | Stately Docs

State pattern

상태 패턴

[디자인 패턴] 싱글톤, 데코레이터

눅눅한 피부 — Sun, 28 May 2023 17:46:53 +0900

싱글톤 패턴

세 줄 개념

클래스의 인스턴스화를 단일 인스턴스로 제한하여 하나의 객체 사용을 강제하는 패턴
두 개 이상의 인스턴스화를 방지하는 게 핵심 구현 방법
메모리 사용에서의 이점 + 하나의 데이터 출처를 강제하는 용도로 사용

유용한 사례

Logger

많은 곳에서 사용되며 사이드 이펙트가 없고 인스턴스를 재활용했을 때의 효용이 높음

공유 리소스에 대한 동시 엑세스 제어
리소스에 대한 엑세스를 전역에서 요구
하나의 객체만 존재해야 하는 경우

위 세 개의 조건을 모두 만족하는 경우 고려해 볼 수 있음(무조건 사용해야 하는것이 아님)

문제점

싱글톤은 SRP를 위반한다
싱글톤 객체는 자기 자신의 인스턴스를 감시하는 책임 + 스스로의 구성정보를 제공하는 책임. 두 개의 책임을 가지고 있는 객체
메모리 관리에 좋지 않다
인스턴스를 하나로 제한하기 때문에 메모리 관리에 효율적일 수 있으나, 전역 객체로 유지되기 때문에 아무 일도 하지 않는 상황에서도 여전히 메모리를 점유하고 있음
싱글턴 내부의 데이터는 곧 전역상태
전역 상태의 사이드 이펙트로 인해 유닛 테스트의 난이도가 올라가고, 소프트웨어의 복잡성을 늘림
싱글톤은 OCP를 위반한다
전역 함수로 이루어져 서브 클래스 확장을 통한 추가 기능 구현이 어려움. 기능 수정에 따른 사이드 이펙트가 전역으로 전파

해결법

단일 인스턴스로 사용하고 싶은 객체는 그대로 일반 객체로 선언

해당 객체를 생성하는 팩토리를 선언해서 SRP를 지키도록 만들 수 있음

class House {
  private final Kitchen kitchen;
  private final Bedroom bedroom;
  private boolean isLocked;
 
   public House(Kitchen kitchen, Bedroom bedroom) {
    this.kitchen = kitchen;
    this.bedroom = bedroom;
  }
 
  private boolean isLocked() {
    return isLocked;
  }
 
  private boolean lock() {
    kitchen.lock();
    isLocked = true;
  }
}

class HouseFactory {
  House build() {
 
     Sink sink = new Sink;
     Dishwasher dishwasher = new Dishwasher;
     Refrigerator refrigerator = new Refrigerator;
     Kitchen kitchen = new Kitchen(sink, dishwasher, refrigerator);
 
		 Bed bed = new Bed;
     Dresser dresser = new Dresser;
     Bedroom bedroom = new Bedroom(bed, dresser);
 
		 House house = new House(kitchen, bedroom);
 
     return house;
  }
}
 
class Main {
  public static void(String...args) {
    House house = new HouseFactory().build();
    house.lock();
  }
}

Singleton I love you, but you're bringing me down (re-uploaded)

Root Cause of Singletons

데코레이터 패턴

세 줄 개념

클래스의 다른 객체의 동작에 영향을 주지 않고 동적으로 개별 객체에 원하는 동작을 하게끔 추가하는 디자인 패턴
상속을 통한 클래스 확장의 대안으로 컴파일 타임이 아닌 런타임에 새로운 동작 추가 가능
객체에 동적으로 추가적인 책임을 부여하기 위해 사용

유용한 사례

런타임 시점에 기존 객체의 동작을 변경하거나 확장하는 경우

기존 코드를 훼손하지 않으면서 런타임에 추가 행동을 할당해야 하는 경우

상속을 사용해서 객체의 행동을 확장하는 것이 어색하거나 불편한 경우

단점

데코레이터 선언을 위한 보일러 플레이트 코드 증가

데코레이터 행위가 다른 데코레이터의 동작에 영향을 받지 않도록 구현하기가 어려움 (데코레이터 스택 내의 순서에 의존하지 않게 구현해야 함)

의문점

decorator pattern 과 hoc의 차이점?

데코레이터 패턴이 하는 일을 들여다 보면, 리액트에서 자주 사용하는 HOC(Higher-Order Component)와 개념이 거의 동일해 보임

찾아보니 동일한 의문을 가진 stackoverflow 질문이 있었고, 동일한 개념이라는 의견 존재

다만, 타입스크립트의 데코레이터 와 데코레이터 패턴 은 다른 개념을 나타내는 용어라는 점에 주의

함수형 프로그래밍에서의 함수 합성 개념과 정확하게 일치하는 것으로 보이며, 데코레이터 Wrapper들의 평가 및 실행 순서도 함수의 합성과 동일

함수 합성

interface Sum {
  (num: number): number;
}

const sum2: Sum = (num) => num + 2;
const sum3: Sum = (num) => num + 3;
const sum5: Sum = (num) => sum2(sum3(num));
const sum10: Sum = (num) => sum5(sum5(num));

HOC(High Order Component)

const withLabel = <P>(Component: ComponentType<P>) => (props: P) => {
    return <label><Component {...props} /></label>;
};

const Button = ({ children }: ComponentPropsWithRef<'button'>) => {
  return <button>{children}</button>;
};


const ButtonWithLabel = withLabel(Button);

styled-components 내부 구현도 데코레이터 패턴을 통해 구현된 게 아닐까? 하는 추측

(나중에 확인해보니 대략적인 줄기는 비슷했음)

추측성 내부 구현 의사코드

const styled = {
  div: (templateStrings: TemplateStringsArray) => {
    const [css] = templateStrings;
	const styleClassName = hash(css);
    const styleElement = document.createElement('style');
    
    styleElement.innerHTML = `
      .${styleClassName}{
        ${css}
      }
    `;
    
    document.head.appendChild(styleElement);

    return function <P extends ComponentPropsWithRef<'div'>>({ className, ...restProps }: P) {
      return (
        <div
          className={className ? `${className} ${styleClassName}` : styleClassName}
          {...restProps}
        />
      );
    };
  },
};

// 실제 사용코드
const Container = styled.div`
  display: flex;
  margin: 3px;
`;

Understand the "Decorator Pattern" with a real world example

데코레이터 패턴

타입스크립트로 작성된 데코레이터 / 디자인 패턴들

React js - What is the difference betwen HOC and decorator

DragGPT + Stream

눅눅한 피부 — Sun, 28 May 2023 17:19:09 +0900

DragGPT 익스텐션이 기본적으로 non-stream으로 동작하다 보니, 응답을 다 받기까지의 로딩 속도가 매우 답답하게 느껴지는 부분이 있었다.

고쳐야지... 하고 매번 생각만 하며 게으름을 피우다 보니 이제야 작업을 하게 되었다.

기존에 DragGPT를 만들며 재미있게 개발했던 포인트 중 하나는 XState였는데, 사실 이번에 코드를 오랜만에 보는 만큼 XState가 낯설게 느껴지지 않을까 하는 걱정이 있었다. 그러나 실제 개발 단계에서는 걱정을 무색하게 만들 정도로 편하게 작업할 수 있었다.

기존 채팅 상태머신에 receiving 상태를 하나 추가해서 작업하는 것만으로도 관심사를 많이 좁혀서 작업할 수 있었는데, state 패턴의 장점을 극한까지 느낀 것 같았다.

작업을 하면서 알게 된 사실인데, openai chat completion api에는 steam 모드에서 요청을 취소하는 기능이 없었다;;

물론 클라이언트 입장에서는 chunk 단위로 유저의 stop 지점에서 끊어서 저장하는 등의 작업을 할 수는 있었으나, api 서버 컴퓨팅 자원의 불필요한 사용을 막기 위해 중단 요청을 보낸다거나 하는 기능은 끝내 찾지 못했다.

그 밖에도 chrome.port를 사용한 에러 전달 과정에서 겪은 이상한 이슈(?)도 있긴 한데 아직 파악이 되지 않아 어떻게 공유를 해야 할지 모르겠다.

뭐 어쨌든... 미뤄왔던 숙원 사업을 하고 나니 이번 연휴를 너무 무익하게 보내는 것 같지는 않아서 기분이 좋다.

https://nookpi.tistory.com/166

DragGPT chrome extension 개발기

nookpi.tistory.com

많이 늦은 2022회고

눅눅한 피부 — Sun, 30 Apr 2023 18:17:24 +0900

연 초에 회고를 6시간 동안 쓰다가 날려먹은 이후... 회고를 다시 쓸 엄두가 나지 않아 하염없이 미루고 있었다.

문득 이러다가 2년치 회고를 쓰겠다는 생각이 들어 빠르게 압축본으로 적어보려고 한다.

상반기

재작년 말에 이직을 한 후, 작년 상반기에는 새로운 조직에 적응하며 배우는 게 참 많았다.

개발팀의 학습 문화나 코드 리뷰 문화에서 얻은 것들을 체화하고, 그 과정에서 사용하지 않았던 근육을 사용하는 듯한 고통과 짜릿함을 동시에 느꼈던 시기였다.

테스트 코드

React 유닛테스트 코드 작성을 시작하면서 테스트란 무엇이고 왜 해야 하는지, 그리고 유지보수 가능한 테스트 코드 작성을 위해 무엇을 고려해야 하는지에 대한 고민과 인사이트를 많이 얻은 시기이다.

역설적으로 테스트 코드를 작성하다가 잘못된 컴포넌트 설계와 구현에 대해 깨닫는 경험이 정말 많았다.

지금 와서 돌이켜보면 그 당시 내가 한 고민들과 그로 인해 얻은 것들이 비단 테스트 코드 작성에만 적용되는 것들이 아니었다는 점에서 아주 값진 시간을 보낸 셈이다.

회사

https://nookpi.tistory.com/136

이러한 개발팀의 문화에 매력을 느껴 블로그에 '내가 우리 팀을 좋아하는 이유'라는 글을 남겼는데, 이 글을 보고 왔다고 하셨던 분들이 면접 시에 많아 정말 부끄러웠지만 한 편으로는 좋았다. 아무리 좋은 문화와 내실을 가져도 알리지 않으면 아무도 모르지 않겠는가...?

어학당 서비스를 런칭하고 어학당 담당자가 되어 유지보수와 기능 고도화를 담당했다.

회사는 연초부터 스쿼드 제체를 통해 도메인별 커뮤니케이션 비용을 줄이고 목적조직으로의 개편을 시도했다.

성공했는지는...? 아직도 잘 모르겠다.

오픈소스

https://nookpi.tistory.com/140

뭐라도 기여해보겠다는 포부를 늘 가지고 있었고, 운이 좋게 내가 자주 사용하는 라이브러리에 기여할 기회가 있었다.

이를 바탕으로 욕심을 좀 더 내서 평소 관심 있던 크롬 확장 프로그램을 vite로 개발할 수 있는 보일러 플레이트를 만들었는데 굉장히 재미있는 경험이었다.

특히 내가 만든 오픈소스 프로젝트에 PR혹은 issue로 기여해 주는 다른 개발자들, 그리고 issue 내에서 서로 답변하고 이슈를 해결해 주는 모습을 보는 기분이 참 각별했다. 모바일 게임의 자동사냥을 돌려둔 기분...?

하반기

스쿼드 조직으로 나뉘면서 업무 방식에 대해 혼란이 생겼고 전체적으로 정신이 없었다.

프론트 파트 내부적으로는 컨벤션을 정리하고 리소스를 효율적으로 사용하기 위해 업무에 자동화할 수 있는 것들을 많이 찾아냈던 시기이다.

오픈소스

꾸준히 레포에 올라오는 이슈를 해결해나갔는데, 생각보다 여간 번거로운 게 아니었다.

크롬 익스텐션에서 동작하는 짝퉁 HMR을 구현하기 위해 끙끙댔고, 생각한 대로 해내긴 했지만 지금도 반쪽짜리라고 생각한다.

사람들이 원하는건 많은데 내 역량으로는 개인 시간을 내서 해결하는데 확실히 한계가 있었다.

QA프로세스도 빈약해서 가끔은 a문제를 해결한 PR이 기존에 잘 되던 b에 문제를 낳는 경우도 있었다.

그래도 처음으로 오픈소스로 후원도 받고(30유로!) 이슈를 하나하나 줄여나가는 재미가 또 있었다.

은근히 Stars가 꾸준하게 올라서 그 부분도 동기부여가 되었던 것 같다.

JSConf 2022

노들섬에서 열린 JSConf2022를 팀원들과 함께 참석했다.

jest preview를 만든 흥 비엣 응우옌의 세션을 들었는데, 두 달 만에 stars 1600개를 받았다고 자랑하길래 부러웠다.

운영이라던지 세션들의 퀄리티는 전반적으로 실망스러웠지만, 그중에도 재미있는 세션들이 있어서 만족했다. 회사 돈이 아니라 내 돈을 내고 참석했다면 속상했을지도...?

함수형 프로그래밍

https://nookpi.tistory.com/149

함수형 프로그래밍 패러다임에 꽂혀 프로덕트 내부에서 이런저런 시도들을 해봤다.

함수형 프로그래밍이 주려는 핵심 가치(action을 제어하고 data, calc를 적절하게 추출하여 소프트웨어의 안정성을 높이는 것)를 알게 된 좋은 계기였고, 실무에 적용하면서 잘 한 부분도 있었고 잘 못 한 부분도 있었던 것 같다.

실제로 코드를 pipe로 체이닝하고, 이터레이터에서 map을 돌리는 게 함수형이 아니라는 걸 알게 되어서 좋았다.

2022 총평

새로운 회사에 적응하고, 훌륭한 동료들에게 자극받아 공부하고 논쟁하며 또 한 번 크게 성장한 시기였다.

모든 환경과 프로덕트를 관통하는 정해진 프로그래밍 규칙 혹은 베스트 프랙티스 같은 것은 존재하지 않는다는 것을 알았다.

하지만 동시에 다양한 환경에 적용 가능한 일반적인 법칙과 철학이 있다는 점을 알게 되었고, 그것들을 체화시킨 이후에 작게는 내 코드 퀄리티가 어떻게 개선되는지를 느끼면서 또 굉장히 뿌듯했으며 크게는 일을 대하는 관점에서도 마찬가지의 법칙을 적용하려고 노력했던 것 같다.

발전속도가 미쳤다

눅눅한 피부 — Wed, 29 Mar 2023 00:55:51 +0900

하루하루 AI관련 생태계의 확장과 새로운 기술에 대한 뉴스가 쏟아진다.

따라가기가 벅차다. 아니, 사실 못 따라간다...

사내 콘텐츠를 바탕으로 한 챗봇을 만들어 보려고 주말 동안 PoC를 했다.

스프린트에 정식으로 반영되어 이번 스프린트부터 타 스쿼드에서 시범적으로 작업에 들어간다.

콘텐츠 텍스트를 임베딩해서 vector store에 갱신하고, 유저 쿼리시 콘텍스트를 함께 제공하는 방식이다.

유저에게 꼭 필요한 정보들이 제대로 전달되지 않는 이슈가 있던 스쿼드에 먼저 도입된다.

할 수 있는게 너무 많아서 질식할 것 같다.

하나씩 꾸준히 놓치지 않고 따라가야지.... 너무 격변의 시기다

DragGPT chrome extension 개발기

눅눅한 피부 — Sat, 18 Mar 2023 18:35:24 +0900

배경

최근 ChatGPT 열풍이 거세다. 연구 영역에 있던 생성 AI의 위치를 대중에 가깝게 옮기면서 대중들로 하여금 급격한 기술 발달이 이뤄지고 특이점이 왔다(?)는 생각을 하게 만드는 것 같다.

기존에 ChatGPT에게 회사 면접 질문을 몇 개 해봤다는 글도 올린 적이 있는데, ChatGPT의 이슈몰이와 함께 조회수가 꾸준히 올라가고 있다.

https://nookpi.tistory.com/156

ChatGPT에게 회사의 면접 질문 몇 개를 던져보았다

질문과 답변을 번역기로 돌려서 어색한 부분이 다소 존재합니다 Q: 유지보수 가능한 코드란? A: 유지 관리 가능한 코드는 이해하고 수정하기 쉬운 코드입니다. 여기에는 일반적으로 깨끗하고 잘

nookpi.tistory.com

개인적으로는 ChatGPT를 위시한 텍스트/이미지 생성 AI들의 사용 자체에 익숙하고 또 능숙해져야만 하는 시대가 오고 있다고 생각한다. 마치 2007년의 아이폰 공개, 2010년을 전후한 스마트폰 대중화와 같이 우리의 일상은 또다시 큰 변곡점을 만나게 될 것이다.

그런 맥락에서 회사 내 아직도 ChatGPT를 사용해본 경험이 없는 분들이 있다는 것이 아쉬웠다. 더 많은 팀원들이 AI리터러시가 중요해질 새 시대에 적응하길 바라는 마음이 있었다.

사내 슬랙에 ChatGPT 봇을 만들어서 배포한 이유도 그러한 마음에서였다. ChatGPT에 쓰이는 언어 모델에 요청하기 위한 api도 이미 공개가 되어있고, 호출 자체도 간단하기 때문에 후딱 만들어서 배포했다.

그럴듯하게 설명해주는데 당연하지만 늘 정답은 아니다

에러 로깅 미들웨어에 붙여두면 이런 식으로 간단히 요약해줄 수 있지 않을까?

흥미

ChatGPT에게 역할을 부여하고, 해당 역할에 맞게 행동해 달라고 했을 때 답변의 퀄리티나 방향성이 완전히 달라진다는 이야기를 들었다. 실제로 테스트를 해보니 단순 '번역해 줘'라는 요청보다 '이제부터 번역가처럼 행동하고 주어지는 텍스트를 맥락에 맞게 번역해 줘'라는 프롬프트가 더 나은 결과를 반환한다는 것을 알았다.

요약 전문가(?)의 역할을 부여하고 BBC 등 영어 기사의 내용을 요약했을 때 결과의 퀄리티가 아주 좋았다. 나에겐 이런 특정 프롬프트가 정말 유용하다는 생각이 들었는데 다른 사람들은 각자 유용한 프롬프트가 있겠지? 하는 생각이 들었다.

좀 더 많은 사람들이 웹에서 쉽게 사용하기 위해서 크롬 익스텐션을 만들면 재밌겠다는 생각이 들어서 바로 착수했다.

다행히 나에겐 웹 익스텐션 개발을 위해 만들어둔 보일러 플레이트가 있었는데, 정작 보일러 플레이트는 만들어두고 아직까지 해당 보일러 플레이트를 활용해서 익스텐션을 만들어 게시하지 않았었다. 이번 기회에 보일러 플레이트도 한 번 제대로 써보고... 하는 마음도 있었다.

구상

컨셉 자체는 간단했다.

1. 사전에 어떤 요청을 할지 미리 정해둔다.

2. 텍스트를 드래그해서 요청하고 싶은 영역을 선택하고,

3. 마우스 근처에 있는 버튼을 눌러서 요청!

4. 결과는 바로 화면에서 확인

텍스트 선택 후 ChatGPT에게 사전 프롬프트 세팅에 따라 요청을 보내서 결과를 받는 POC를 만들었다.

요기까지 만드는데 4시간 정도 소요되었다

직접 사용해 보니 뭔가 써먹을 수 있겠다는 확신이 들었다. 일단 나부터가 유용하게 쓰겠다는 생각이 들어 이후 며칠 동안 몇 가지 기능을 추가하였다.

1. 답변 결과에서 이어서 대화하는 기능 (ex. 답변을 한 줄로 요약해줘, 번역해 줘 등)

2. 사전 프롬프트 없이 빠른 대화

3. 프롬프트 생성 기능

4. 다국어 지원

5. 기타 편의기능

디자인은... 역량 부족으로 아예 포기했다

현재 크롬 익스텐션 웹스토어에 올려둔 상태이다.

피드백은 언제든 환영!

드래그 GPT - 드래그로 쉽게 AI를 시작해보세요!

드래그 후 버튼 클릭만으로 간단하게 선택한 내용을 ChatGPT에게 물어보거나 요청할 수 있어요!

chrome.google.com

개발 경험

Boilerplate

보일러플레이트를 세팅하고 ChatGPT 요청을 보내서 받는데까지 순식간에 끝났다. 버전 0.1.0이 나오는 데 4시간도 채 걸리지 않았으니 나름 빠르게 개발한 셈이다. 물론 빠르게 작성하면서 곳곳에 날림 코드가 있어 이후 리팩토링에 시간을 쏟았고 테스트 코드도 보강했다.

내가 만든 보일러플레이트라서 사용하기에 익숙한 부분도 있었고, 실제로 개발에 있어 불편함이 없게끔 많은 부분이 개선된, 나름 좋은 보일러플레이트라고 생각한다. hmr을 좀 야매로 구성해서 정말 큰 익스텐션을 만드는데 적합한지는 모르겠지만, 간단한 앱 정도 만드는 데에는 충분하다는 생각이 들었다.

요 레포도 벌써 Star 400개 Fork 60개가 넘었는데, 이슈를 남겨주시는 분들과 대신 답변 해주시는 분들에게 늘 감사하다.

https://github.com/Jonghakseo/chrome-extension-boilerplate-react-vite

GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

Chrome Extension Boilerplate with React + Vite + Typescript - GitHub - Jonghakseo/chrome-extension-boilerplate-react-vite: Chrome Extension Boilerplate with React + Vite + Typescript

github.com

XState

컨텐츠 스크립트 코드는 리액트로 구현되었는데, 상태에 따른 컨텍스트의 얽힘이 코드의 가독성을 매우 떨어뜨렸다. 코드 정리를 위해 어떤 패턴을 써볼까 고민하다가 이번 기회에 게임 개발에 많이 사용되는 유한상태기계(FSM) 패턴의 JS/TS 구현체인 XState를 사용했다. 결론부터 말하자면 굉장히 만족도가 높았다.

https://xstate.js.org/docs/

XState Docs

JavaScript state machines and statecharts (opens new window) JavaScript and TypeScript finite state machines (opens new window) and statecharts (opens new window) for the modern web. Read the documentation (opens new window) Explore our catalogue

xstate.js.org

사용성이 너무 좋았고, 특히 시각화를 통한 Flow 검증이 신세계였다.

contentScript 내부의 drag-state에 처음 사용해보았다.

상태 간 이벤트를 통한 전이, 사용하기 편한 액션과 가드 덕분에 기존 코드가 깔끔하게 정리되었고, 유지보수에 대한 자신감도 가질 수 있었다.

이번 기회에 유한상태머신(FSM) 이론에 대한 관심도 생겨서, 사내 세미나 순서를 새치기해서 FSM 관련 세미나를 할 예정이다.

너무 딱딱한 이론보다는 사용 경험과 실제 코드에 접목했을 때의 관심사 분리에 대해 간단히 진행해보려고 한다.

다국어 지원

크롬 익스텐션에서 다국어 지원은 처음 해봤는데, 다른 i18n 관련 라이브러리등의 지원 방식과 크게 다르지 않아 쉽게 적용할 수 있었다. 크롬에서 익스텐션의 다국어 기능을 내장하고 있어(chrome.i18n) 별도의 의존성 추가는 필요하지 않았고, 공식문서도 잘 나와있었다.

충격받았던 부분은 번역 그 자체였는데, 4개 국어(영어/중국어/일본어/한국어) 지원을 위해 영어로 작성한 i18n json 파일 내용을 그대로 긁어다가 ChatGPT에게 메시지만 번역해 달라고 하니 포맷 그대로 메시지만 번역해 줬다!

기존의 기계 번역이 하지 못하던 일을 너무도 쉽게 하는 모습을 보고 감명받았는데, 마찬가지로 html 내부의 텍스트도 딱 텍스트만 골라서 번역하는 모습을 보고 참... 여러 생각이 들었다.

앞으로의 계획

일단은 익스텐션 자체를 홍보하고 사용자를 늘리는 것을 목표로 하고 있다.

또한 현재는 프롬프트에 단순 텍스트를 넣어 지시문을 작성하고 있지만, 추후 고급 설정을 통해 temperature 등의 매개변수도 수정할 수 있게 만들 예정이다.

api 요청 자체가 큰 비용이 드는 게 아닌 만큼 라이트 유저를 위해 일정 요청은 무료로 가능하게 할지도 고민 중이다. 광고 배너 등의 수익화가 가능하다면 자체 서버를 띄우고 무료 요청이 가능하도록 할 수 있을 텐데 아쉽게도 크롬 익스텐션은 광고를 달 수 없다 ㅎㅎ

함께 자라기 - 자기계발

눅눅한 피부 — Sat, 25 Feb 2023 14:51:37 +0900

자기 계발이 중요한 이유는? 현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다.

올해 내가 인정을 받고 성과를 거뒀다면, 1~2년 전에 열심히 자기 투자를 했을 것이다.

반면 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제가 없으나, 내년 혹은 내후년에 분명 추락을 경험하게 된다.

직장인들의 약 50%가 하루 평균 1~2시간의 자기계발에 투자하고, 약 30%는 1시간 미만의 시간을 투자한다. 즉 하루 평균 1시간도 투자하지 않는 사람은 자기 계발의 측면에서는 하위 30%라는 것을 인지하고 있어야 한다.
이 시간은 점차 복리로 축적되어 나중에는 엄청난 차이를 만들게 된다.

빨리 자라고 싶다면 다음과 같은 것들을 고민해야 한다.

어떻게 이율을 높일 것인가
지속적으로 나에게 현명한 투자를 하려면 어떻게 할 것인가

이율을 높이기 위한 몇 가지 힌트

자신이 이미 갖고 있는 것들(지식 등)을 잘 활용하라
- 새로 받아들인 지식을 얼마나 활용하고 있는지 확인하라
- 이미 가지고 있는 지식들을 촘촘히 연결하고 시너지가 나게 하라
- 새로운 것이 들어오면 이미 갖고 있는 지식과 충돌을 시도하라
외부 물질을 체화하라
- 주기적인 외부 자극을 받아 재빨리 자기화 해야 한다
자신을 개선하는 프로세스에 대해 생각하라
- 나의 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 구축하라
피드백을 자주 받아라
- 피드백의 사이클을 줄여라. 새로운 시도를 작게라도 빠르게 해 보는 것이 좋다
- 일찍, 그리고 자주 실패하여 실패에서 학습하라