겨리의 개발일기

[Vite+tabler/icons-react] 성능 이슈 해결(청크 5,000개+ 요청 현상)

겨리! — Sat, 19 Jul 2025 23:18:38 +0900

Vite 기반의 프로젝트에서 tabler/icons-react 라이브러리를 사용하던 중 마주했던 문제를 정리해보고자 한다.

사내 UI 프로젝트에서 사용하고 있는 tabler/icons-react를 세팅 후 필요한 아이콘 몇 개를 import해서 사용하려고 했다.

그런데..웬걸 로컬 서버를 띄운 후 접속해보니 페이지 진입 속도가 너~~무 느렸다..!

너무 느려서 네트워크 탭을 확인해봤더니, 5,000개가 넘는 아이콘 청크를 전부 요청하고 있었다.

아이콘 몇 개만 사용했을 뿐인데...요청이 5,000개가 넘는다니... 대환장

참고로 내가 사용한 라이브러리의 버전은 아래와 같다.

- Vite v5.4.17

- tabler/icons-react v.3.29

문제 상황

아래는 테스트용 코드인데,

아이콘 하나만 import 해도 전체 아이콘이 개별 청크로 쪼개져 모두 요청되는 이상한 현상이 발생했다.

// App.tsx
import { IconUser } from "@tabler/icons-react";

function App() {
  return <IconUser />;
}

위처럼 세팅한 후 로컬 서버를 띄우고 네트워크 탭을 열어보면, 수많은 요청이 쏟아진다.

아래 사진을 보면 5,854번의 요청이 찍힌 걸 확인할 수 있다..

원인

@tabler/icons-react의 export 구조

Tabler는 아이콘 5,000개가 넘는 아이콘을 다음과 같이 개별 ESM 모듈로 모두 export한다.

정말 많다...!

Vite의 ESM 사전 번들링 분석 방식

Vite는 성능 최적화를 위해 dev 서버 구동 시 ESM 모듈을 사전 분석(pre-bundling)한다.

여기서 index.mjs에서 수천 개의 export가 존재하다 보니, "혹시라도 이 중 하나라도 쓸 수 있으니까"라는 이유로 모든 아이콘을 lazy chunk로 나누고 prefetch까지 해버린다.

위와 같은 이유로 아이콘을 하나만 사용하더라도 모든 .mjs파일을 개별로 요청하게 된다.

해당 현상에 대해 키워드로 구글링해보니

Reddit과 tabler/tabler-icons 이슈 탭에서 관련 글과 해결 방법을 찾을 수 있었다.

~~(모두 극대노하고 있음)~~

✔ raddit

https://www.reddit.com/r/reactjs/comments/1g3tsiy/trouble_with_vite_tablericons_5600_requests/?rdt=50753

✔ tabler-icons 이슈

https://github.com/tabler/tabler-icons/issues/1233

해결 방법

vite.config.ts에 alias 추가하기

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@tabler/icons-react': '@tabler/icons-react/dist/esm/icons/index.mjs',
    },
  },
});

위와 같이 설정하면, Vite가 @tabler/icons-react 전체가 아닌, index.mjs 단일 파일만 참조하게 된다.

이렇게 하면 Vite가 개별 아이콘 파일들을 분석하거나 요청하는 일을 더 이상 하지 않게 된다.

이후 네트워크 탭을 다시 확인했을 때 요청이 20개로 줄어든 것을 확인할 수 있었다.

alias 설정 후 실제로 아이콘 import하면 어떻게 동작할까?

예를 들어 아래처럼 딱 하나의 아이콘을 import했다고 가정해보자.

import { IconUser } from '@tabler/icons-react';

Vite는 이걸 어떻게 처리할까?

✅ alias 설정이 적용되어 있기 때문에,
Vite는 @tabler/icons-react 전체 구조를 분석하지 않고, index.mjs 파일 하나만 번들에 포함시킨다.
그 안에서 내가 import한 IconUser만 추적해서 번들에 포함하고, 나머지 아이콘은 건드리지 않는다.

✅ 결과적으로 IconUser만 포함된 작은 chunk 하나가 생성되고, 5,000개가 넘는 .mjs 요청은 발생하지 않는다.

정리

✅ @tabler/icons-react는 구조상 모든 아이콘을 export하고 있어서 Vite의 번들러가 과잉 분석하게 된다.

✅ 이때 alias를 통해 분석 대상을 index.mjs 하나로 제한해주면, Vite는 더 이상 수천 개의 파일을 청크로 나누지 않는다.

✅ alias 한 줄 설정만으로 .mjs 수천 개 요청을 막을 수 있다..!

[연간회고] 2024년 회고 - 다사다난했던 2024년을 정리하며

겨리! — Mon, 13 Jan 2025 00:33:04 +0900

아니 벌써 2025년이라니...?

지난 2024년은 한 해가 어떻게 흘러갔는지 모를 정도로 정신 없이 보냈다.

바쁘다는 걸 핑계로 반년 이상 방치해둔 블로그를 보니 사알짝 부끄럽고 후회스럽기도 하다.

부끄럽지만 반성하는 마음을 담아 2024년을 돌아보는 회고를 작성해본다!

지난 2024년은 다양한 변화가 있었다.

큰 변화를 중심으로 정리해보자면...

‍ 프론트엔드 개발자로 커리어를 다시 시작하다.

정말 감사하게도 작년 2~3월쯤 두 회사로부터 최종 오퍼를 받았다.

각 회사와 처우 협의를 진행했고, 깊은 고민 끝에 현 회사에 입사하기로 결정했다.

퇴사 후 다시 취업 준비를 하면서 많이 불안하고 힘들었는데,

처우 협의까지 마치고 두 회사를 고민하는 스스로를 보며 왠지 모를 다양한 감정이 들었다. 대견하기도 하고..?

현 회사로 입사를 결정한 후로는 얼른 출근하고 싶다는 생각만 들었던 것 같다.
(길어진 취준 기간 동안 사회생활에 목마른 자가 되어버렸음)

실제로 첫 출근 후 몇 달 동안은 회사를 간다는 사실 자체만으로도 도파민이 나오는 느낌이었다...

아무튼 지금은 회사에 잘 적응한 상태이며 열심히 다니고 있다.

잇츠 스터디 크루 1기 리더가 되다.

작년 4월 서울 우먼잇츠에서 잇츠 스터디 크루 1기 리더를 모집한다는 글을 우연히 보았고,

보자마자 이거다! 싶은 마음에 평소 공부하고 싶었던 부분을 정리해서 지원서를 작성했다.

그 후 리더에 선발이 되었다는 연락을 받았고, 스터디를 시작하게 되었다!

스터디 주제는 모던 자바스크립트 딥다이브였다.

완독해야겠다는 생각은 하지만...완독하지 못한 채 부채감만 가지고 있던 책이었기에...

드디어 이 책을 완독할 때가 됐구나! 하는 마음으로 결정했다.

생각했던 것보다 많은 분들이 지원해 주셔서 팀원을 고르는 과정에도 고민이 많았다.

(5명을 뽑아야 하는데 26명이나 지원을 해주셨다. )

리더를 잘할 수 있을지에 대한 부분도 걱정이 많았는데, 다들 열심히 참여해 주신 덕분에 순조롭게 진행할 수 있었다.

참고로 이때 만난 분들과는 아직도 스터디를 함께하고 있다.

이번이 벌써 3번째 책이라는 것..!

매주 일요일 저녁마다 좋은 에너지를 듬뿍듬뿍 받고 있다.

정말 감사한 분들이고 소중한 인연이라고 생각한다.

너무 귀여운 망곰즈 감사합니다…

자바스크립트로 딥다이브!(24.5.12-24.8.25)

모던 자바스크립트 딥다이브 책 스터디는 약 3개월 동안 진행되었다.

빠르게 내용을 훑고 생각을 공유하는 게 목적이라,

매주 정해진 분량을 읽고 정리한 내용과 느낀 점을 깃헙 레포에 업로드하는 방식으로 진행했다.

발표자가 발표를 진행하고 마지막쯤 서로의 생각을 공유하는 시간을 가졌는데

한 주제에 대해 다양한 경험과 견해를 공유하는 과정을 통해 많은 것을 배울 수 있었다.

스터디 레포 : https://github.com/deep-dive-everything/deep-dive

우아한 타입스크립트 (24.9.8-24.12.15)

자바스크립트 딥다이브 스터디가 끝난 후 우아한 타입스크립트 with 리액트 책으로 넘어갔다.

이해도를 조금 더 높이기 위해 이슈를 사용해서 질문하고 답변을 다는 방식으로 스터디 방식에 변화를 줬다.

이런 방식으로 진행하니 공부한 내용에 대해 한 번 더 들여다보고 생각할 수 있어서 많은 도움이 되었다.

스터디 레포 : https://github.com/deep-dive-everything/typescript-with-react

드디어 방통대 졸업

그동안 미뤄왔던 방통대 마지막 학기를 끝냈다!!!

이직을 핑계로 휴학한 후 복학을 미뤄오며 부채감을 느껴왔는데...이젠 끝이다!

사실 그냥 공부한다는 것에 의미를 두고 스트레스를 덜 받았으면 좋았겠지만..

그런 걸 용납 못하는 성격이라...나중에 후회하지 않기 위해 늘 최선을 다했다.

그래도 덕분에 평점 4.1로 잘 마무리할 수 있어서 나름 뿌듯하다.

다른 공부는 무얼했나?

Next.js 강의 완강

강의만 듣는다고 해서 다 되는 건 아니지만 일단 완강했으니 셀프 칭찬

강의를 들으면서 가장 많이 들었던 생각은

Next.js를 정말 잘 활용하기 위해서는 개발하는 페이지의 특성과 다뤄야하는 데이터의 특성에 대해 제대로 알아야한다는 점이었다.

제공하는 기능이 많고, 옵션도 다양해서 잘 아는 상태로 사용해야 활용할 수 있겠다고 느꼈다.

갈 길이 멀다...계속해서 공부할 것!

개인 프로젝트 진행

업무로 진행중인 프로젝트에서 Fabric.js 라이브러리를 다룰 일이 많다보니 자연스럽게 관련된 기능에 관심이 생겼다.

그래서 Next.js 프로젝트에 Fabric.js 라이브러리를 같이 사용하는 사이드 프로젝트를 진행하고 있다.

사실..작년까지 완성시키는 게 목표였지만 계속해서 미뤄지고 있어서 반성 중이다..

운동 & 건강

작년 하반기쯤 복싱을 배우기 시작했다..!

시작하고 바로 다쳐서 한 달 가까이 쉰 게 함정이지만...

어쨌든 새로운 운동에 도전했고, 나름 열심히 해보려고 노력 중이다.

처음엔 정말 머쓱하고..뭐부터 해야할지 모르겠고..집중도 안 돼서 힘들었는데

그냥 꾸준히 다니다 보니 조금씩 나아지는 게 느껴져서 신기하다.

또 샌드백을 치는 행위를 통해 스트레스를 해소할 수 있어서 정신적으로도 많은 도움이 되는 것 같다.

작년엔 이상할 정도로 잔병 치례가 잦았다.

코로나, 장염, 횡문근융해증, 발목 염좌 등..다양하게 아팠던 것 같다.

넘치는 의욕을 쫓아가지 못하는 체력...

이것이..30대의 체력일까...?

이곳 저곳 아프고 고생하면서 건강관리의 중요성을 다시금 느꼈다.

올해는 꼭 건강하게 이것저것 배우고 도전할 수 있기를 바라본다. (제발)

2024년 목표 다시보기

~~✅ 프론트엔드 개발자로서 경력 이어가기~~

✅ 네트워킹 활동 적극적으로 참여하기

~~✅ 네트워크 스터디 진행하기~~

~~✅ 방통대 복학하고 잘 마무리하기~~

~~✅ 사이드 프로젝트 진행하기~~

~~✅ 헬스 말고 다른 운동 도전해 보기~~

잘 한 점

작년 목표 중 대부분의 목표를 달성했다. 매우 만족스럽다!

네트워크 스터디는 진행하지 않았지만 스터디를 두개나 진행했으니 잘 해냈다고 생각한다.

아쉬운 점

네트워킹 활동에 적극적으로 도전하지 않은 것

이것저것 다양하게 도전했지만 네트워킹 활동 부분은 살짝 미비했다.

2025년은 조금 더 적극적으로 시도해봐야겠다.

주간회고를 가끔씩 빼먹은 것

매주 꾸준히 작성해오던 주간회고를 조금씩 빼먹게 되었다.

길어봐야 이주에 한번이지만...

이게 은근 루틴화가 되어가는 것 같아서 경계해야겠다고 느낌

월간회고도 다시 열심히 작성해야겠다.

2025년의 목표는?

2025년 목표는 만다라트 계획표로 대체한다.

건강하고 알차게 전문성을 쌓는 한 해가 되길 바라며,

이 글을 보는 여러분도 나도 화이팅입니다!

[월간회고] 2024년 2월 - 하면 된다

겨리! — Mon, 4 Mar 2024 02:47:02 +0900

벌써 3월이라니...

지난 한 달은 하루하루 바쁘게 보내느라 시간 가는 줄 몰랐다.

☕ H님과의 커피챗

취준 컴퍼니를 통해 프론트엔드 개발자 H님과 커피챗을 진행했다.

이력서와 포트폴리오에 대한 피드백을 받았고, 앞으로 어떤 부분을 보완하면 좋을지에 대해 많은 조언을 해주셨다.

사실 이때까지만 해도 면접을 바쁘게 보러 다니는 상황은 아니어서 서류에 대한 고민이 많았다.

H님은 서류 합격도 중요하지만 면접까지 잘 끌고 갈 수 있도록 수정 및 보완을 해야 한다고 말씀하셨고,

평소 놓치고 있던 부분을 딱 집어주셔서 다시 한번 방향성을 잡을 수 있었다!

이번 커피챗을 통해 내가 미처 알지 못한 면접관의 입장에 대한 이야기를 들을 수 있어서 좋았다.

나는 여태껏 지원자로서의 경험만 쌓아왔기 때문에 알 수 없었던 부분인데 H님을 통해 여러 얘기를 들으니 시야가 확장된 느낌이었다.

정말 신기하게도 커피챗 이후로 서합 소식이 이어져서 여러 번의 면접 기회를 얻을 수 있었다..

그리고 면접 경험이 쌓일수록 H님의 조언이 더 깊게 와닿았던 것 같다.

H님 감사합니다! ‍♀️ ‍♀️

운동

바빴지만 운동은 소홀히 하지 않았다!

나름 운태기를 극복한 달이었다고 생각한다.

지난번 회고에 적은 것처럼 1월까진 운동에 대한 의욕이 살짝 떨어졌었다.

전반적으로 의욕이 떨어지면서 운동도 부담이 되었고 헬스장에 가더라도 즐겁게 운동할 수가 없었다.

이대로 가다간 운동에 영영 흥미를 잃겠다 싶어 마인드셋을 다시 했다.

1월 회고에 적었던 대로 목표를 작게 잡았고, 운동이 부담스러운 날에는 유산소만이라도 조금 타고 와야겠다는 생각으로 헬스장에 갔다.

부담감을 내려놓으니 오히려 더 의욕이 생겼고,

실제로 유산소만 타러 갔다가 이왕 한 김에 조금만 더 해볼까? 하며 웨이트까지 하고 온 날이 꽤 많았다 ㅋㅋㅋ

2월 내내 저런 식으로 운동했던 것 같다. (나 자신과 밀당하기 성공.. )

마음가짐 하나만 바꿨을 뿐인데 효과가 상당했다!

취준 생활

그동안 커피챗과 멘토링 등을 통해 수많은 피드백을 받았고,

부족한 부분은 채우기 위해 노력해왔는데..노력이 통한 걸까?

정말 감사하게도 이번달은 전보다 많은 면접 기회가 주어졌다.

이번 달은 계속

준비 → 면접 → 복기(후회를 살짝 곁들인...) → 공부 → 다시 준비

이런 식으로 지냈는데...그러다 보니 하루하루가 빠르게 지나갔다.

사실 시간이 어떻게 흘렀는지 모를 정도로 바쁘게 보냈던 것 같다.

면접 경험을 통해 내가 어떤 부분이 부족한지 냉정하게 파악할 수 있었다.

부족함이 많다고 느껴지는 날은 속상하기도 했지만

답변을 하고 나서 후회하는 상황이 반복되지 않도록 다시 공부했다.

기존엔 서합률이 낮았기 때문에 면접 경험 하나하나가 소중한 기회라는 생각이 들었고 최선을 다했다.

(그럼에도 불구하고 면접이 끝나면 늘 후회가 남았다.. )

‍ 위민후코드 서울

위민후코드 서울 신규 운영진에 합류하게 되었다!

개발자가 되기 위해 준비하던 시절부터 지금까지 정말 많은 분들의 도움을 받아왔다.

도움을 받을 때마다 나도 언젠가 누군가에게 도움을 줄 수 있는 사람이 되고 싶다고 생각했다.

또 올해 목표 중 하나가 '네트워킹 적극적으로 시도하기' 였는데

내 가치관과 목표를 고려해 봤을 때 위민후코드 서울이라는 단체와 핏이 맞는다고 느꼈기 때문에 용기를 냈다!

내가 잘할 수 있을까?라는 걱정이 들긴 했지만 내 위치에서 최선을 다해 활동해보려고 한다.

앞으로 위민후코드 서울을 통해 진행할 다양한 활동들이 기대된다!

잘한 점

바빠도 운동을 게을리하지 않은 것

면접에 최선을 다한 것

아쉬운 점

면접 준비하느라 다른 공부를 소홀히 한 것

1월 목표에 프로젝트 성능 개선과 포스팅을 하는 게 있었는데...못했음

3월도 지금처럼 최선을 다해보자! 하면 된다!!!!!!!!!!!!!!!!!!!!!

2년동안 회고를 쓰며 배운 점과 회고 작성법

겨리! — Mon, 19 Feb 2024 03:13:13 +0900

회고 작성을 추천하는 이유

글을 시작하기 전에 간략하게 내 소개를 하자면...

나는 3년 차 개발자로 비전공자+국비학원 출신이다.

중소 SI기업에서 첫 커리어를 시작하였고 퇴사 후 휴식 및 재정비를 마치고 다시 취준생이 되었다.

이력서와 포트폴리오를 작성하면서 그동안 작성해 왔던 회고의 덕을 정말 많이 보았고

많은 사람들에게(특히 신입, 주니어 개발자) 회고 작성을 추천하기 위해 이 글을 쓰게 되었다.

나에 대해 조금 더 설명해 보자면(TMI 주의)

나는 예전부터 단기 계획에 강했다.

여기서 단기 계획이란 벼락치기가 아닌 단기간 동안 어느 정도 계획을 세워 준비하는 것을 뜻한다.

(짧으면 한 달, 길면 사개월 정도의 계획)

성격 자체가 과몰입을 잘하는 편이라 그런지 옛날부터 단기 계획을 세웠을 때 승률이 좋았다.

그동안 내가 달성한 단기 목표들과 달성여부를 보자면

✔ 단기간에 여행자금 모으기 → 알바 미친 듯이 해서 1,300만 원 모아서 유럽 배낭여행감

✔ 대학생 때 중간고사나 기말고사 한두 달 전부터 미리 계획을 세워 공부 → 높은 학점 유지할 수 있었음

✔ 거의 모든 자격증 시험들 웬만하면 한 번에 합격함(컴활1급, 정처기, sqld)

특히 정처기 실기를 준비했을 때 국비 학원 파이널 프로젝트 시기와 겹쳐서 많이 힘들었는데 둘 다 끝이 정해져 있다 보니 마인드컨트롤하며 버틸만했던 것 같다.

이와 반대로 장기 목표를 설정하고 이루는 부분은 다소 취약한 편이다.

6개월 이상 무언가를 꾸준히 공부해야한다거나 장기간 동안 시험을 준비해야 하는 상황에선 집중력이 확 떨어진다.

위와 비슷한 이유로

새해마다 다이어리를 구매하며 꾸준히 일기 쓰기를 다짐하곤 하지만 매번 실패했다...

이런 나의 약점은 회고를 통해 보완할 수 있었다.

이루고 싶은 장기 목표들을 쪼개서 단기 계획에 목표로 세팅했고 회고를 꾸준히 작성하며 계속해서 점검해 왔다.

이와 같은 방법을 통해 장기적인 계획이나 목표도 내가 원하는 방향으로 잘 이룰 수 있었다.

또 회고를 통해 지속적으로 나를 돌아보며 건강한 방식으로 반성할 수 있었다.

여러 가지로 종합해 봤을 때 회고를 작성한 후로 건설적인 목표 세우기와 피드백을 진행할 수 있었고 이는 나에게 긍정적인 변화를 가져다주었다!

회고를 꾸준히 작성할 수 있었던 이유

개인적으로 회고를 꾸준히 작성하기 위해선 장치가 필요하다고 생각한다.

특히 회고를 공유할 수 있는 사람이 있으면 정말 좋다!(강추)

나는 매주 일요일마다 회고를 공유하는 소규모 모임에서 활동하고 있고 이 모임의 덕을 정말 많이 봤다.

솔직히 혼자 했으면 이렇게 꾸준히 지속하기 힘들었을텐데..함께 하니까 할 수 있었다.

이번주는 너무 힘들었으니 생략할까 하다가도 매주 일요일 저녁 누군가가 올린 회고를 보며 각성하게 된다

또 공유된 회고를 읽으며 서로 응원과 위로를 해주는 과정을 통해 힘을 얻기도 한다.

회고 공유 예시

회고 쓰는 방법

나는 주간회고, 월간회고, 연간회고까지 총 세 가지 종류의 회고를 작성하고 있다.

회고마다 조금씩 다른 특징을 가지고 있고 공유 대상도 다르다.

✅ 주간회고

주간회고 기록들

작성 방법

주간회고 양식은 조금씩 업데이트해왔다.

다른 사람들의 회고를 보고 괜찮은 부분은 참고해서 변경해 왔기 때문...

사실 예전 주간회고는 퍼블릭하게 공유할 용도로 작성했었다.

그리고 얼마가지 않아 프라이빗하게 공유하는 방식으로 변경했다.

위와 같이 변경한 이유는 모두가 볼 수 있다고 생각하니 회고를 쓰는데 정제해야 할 부분이 너무 많았고, 이렇게 쓰다 보니 내 생각과 감정에 대해 솔직하게 쓰기 어려웠기 때문이다.

모임에서 소규모 인원들에게 오픈하는 것과 모두가 볼 수 있는 글을 쓰는 것은 부담감이 달랐다.

특히 주간회고는 나중에 참고해서 월간회고와 연간회고를 작성하게 되는데

주간회고부터 조금씩 정제하다 보면 내 생각이나 감정이 배제되는 경우가 많아 생생한 기록으로 참고하기에 어렵다고 느꼈다.

이런 이유로 주간회고는 프라이빗하게 작성하되 회고 모임에서는 공유하는 방식으로 변경했다.

내 감정과 생각에 대해 솔직하게 작성하다 보니 나중에 회고를 다시 읽어봤을 때 해당 기억을 생생하게 떠올릴 수 있었다.

이런 기억이 뭐가 그렇게 중요한가?라고 느낄 수 있지만

이력서와 포트폴리오 작성에 정말!!!!!! 많은 도움이 된다.

어떤 부분을 개발했을 때 내가 어떤 생각을 했고, 고민을 했는지 주간회고에 제대로 녹아있기 때문이다.

tmi지만 난 이력서를 작성하면서 주간회고를 보고 과거의 나에게 따봉을 날린 적이 몇 번 있다ㅋㅋㅋ

위와 같은 경험 후 만나는 사람들마다 회고의 중요성을 강조하며 영업하고 있다ㅋㅋㅋ

아무래도 내가 산증인이니까...

작성 예시

처음엔 어떤 식으로 작성해야 할지 몰라서 회고 공유 모임에 올라온 회고를 보고 참고해서 작성했다.

초반 주간회고 포맷은 업무/공부/생활/잘한점/잘못한점/목표달성여부/다음주목표 이런 식으로 나눠져 있었다.

퇴사 후엔 업무를 없애고 취준과 운동이라는 주제를 추가했다.

또 KPT회고 부분을 추가하며 잘한점, 잘못한점, 목표달성여부 부분을 대신했다.

KPT 포맷을 추가한 후 회고 자체가 확실히 깔끔해졌다. 지금봐도 매우 만족하는 부분..!

✅ 월간회고

작성 방법

월간회고는 블로그에 작성하고 있다.

주간회고를 묶어서 좀 더 컴팩트하게 작성하려고 노력한다.

주간회고를 돌아보며 월간회고를 작성하다 보면

한 달 동안 내가 어떤 생각을 가졌고, 어떤 부분에 몰입을 했는지, 어떤 고민을 했는지가 정리가 되는데

이걸 키워드 중심으로 정리해서 작성하고 있다.

그리고 좀 더 큰 범위에서 잘한 점, 잘 못한점을 돌이켜보며 장기 목표를 세팅할 수 있다.

작성 예시

https://hotdogdev.tistory.com/88

[월간회고] 2024년 2월 - 하면 된다

벌써 3월이라니... 지난 한 달은 하루하루 바쁘게 보내느라 시간 가는 줄 몰랐다. ☕ H님과의 커피챗 취준 컴퍼니를 통해 프론트엔드 개발자 H님과 커피챗을 진행했다. 이력서와 포트폴리오에

hotdogdev.tistory.com

✅ 연간회고

작성 방법

위의 회고들을 묶어서 만드는 게 연간회고이다.

일 년이라는 기간에 대한 회고다 보니 쓸 말이 매우 많다.

그래서 작성하는 데 시간과 정성이 꽤나 들어간다..

앞서 말했듯이 나는 장기계획을 짜는 것에 매우 서투른 사람이다.

연간회고도 월간회고와 마찬가지로 키워드 중심으로 작성하지만

일 년에 대한 회고이기 때문에 키워드 자체가 큰 덩어리가 된다.

주로 1년 동안 내가 꾸준히 해온 것, 아니면 큰 변화, 도전 같은 부분에 대해 정리하고 있다.

작성 예시

https://hotdogdev.tistory.com/78

[연간회고] 2023년 회고 - 중요한 건 꺾여도 그냥 하는 마음

2022년 회고를 작성한 게 엊그제 같은데 벌써 2024년이라니! 한 해가 훌쩍 지나가버렸다. 지난 2023년은 나에게 프론트엔드 개발자로서의 기반을 다진 해가 아닐까 하는 생각이 든다. 다양한 도전을

hotdogdev.tistory.com

회고를 작성하며 느낀 점

매번 회고를 통해 과거의 나를 돌아볼 수 있었다.

지난날의 나를 보며 넌 이렇게 열심히 했구나 이런 생각을 했었구나 하며 위안을 얻기도 하고

이런 쓸데없는 고민을 했구나 하며 반성을 하기도 한다.

이런 경험은 나를 더욱더 강하게 만드는 것 같다.

자기 효능감을 올려준다고 할까?

그냥 꾸준히 작성하고 기록한 것뿐인데 나를 더 좋은 방향으로 이끌어주고, 건강한 사람으로 만들어줬다.

회고 정말 안 쓸 이유가 없다...!

이 글을 읽는 여러분도 시도해 보길 바라며 글을 마친다.

[월간회고] 2024년 1월 - 헤맨 만큼 내 땅!

겨리! — Thu, 8 Feb 2024 16:20:26 +0900

어느덧 2024년 첫 달이 지났다.

2024년을 앞두고 연간 계획을 짠 게 엊그제 같은데 벌써 1월이 끝났다니...

지나간 1월을 한 줄로 요약하면 감정적으로 변화가 컸던 시기라고 표현할 수 있을 것 같다.

⚙️ 프로젝트 개선 도전

반복되는 서탈에 이대론 안 되겠다 싶어 아는 프론트엔드 개발자 D님께 커피챗을 요청했다.

커피챗 중 개인 프로젝트 개선에 대한 조언을 들었고 곧바로 실행에 옮겼다.

내가 참여중인 개발 오픈 카톡방 몇 곳에 피드백을 요청했고, 그 피드백을 가지고 개선을 시도했다.

지금 와서 생각해 보면 너무 잘한 선택이었다.

단순한 테스트 사이트인데도 개선을 진행하며 정말 많은 걸 배울 수 있었기 때문이다.

배운 내용들은 시간이 오래 걸리더라도 블로그에 세세하게 기록했고, 이 과정을 통해 확실하게 학습할 수 있었다.

자세한 내용은 여기에!

개인 프로젝트 개선기록 보러 가기

https://hotdogdev.tistory.com/83

개인 프로젝트 개선 기록

작년 하반기에 개인프로젝트로 진행했던 테스트 사이트의 개선 과정을 기록하고자 한다. 사실 처음에는 리액트를 공부할 겸 만들어본 간단한 프로젝트라 지인들에게만 살짝 보여주고 덮어뒀었

hotdogdev.tistory.com

면접스터디

면접스터디는 꾸준히 진행하고 있다.

1월 초부턴 리액트를 다시 리액트를 다루고 있는데 욕심내서 깊이 있게 보려고 하니 시간이 정말 오래 걸린다.

공식문서, 블로그, 깃허브 레포지토리 뒤져보기

집착하는 사람처럼 다 뒤져보면 안 나오는 개념이 없어서 매번 놀라는 중..

이해가 안 되면 이해가 될 때까지 계속 파고들어 보려고 하는데 이게 맞는 방향인진 모르겠다.

(그렇다고 해서 모두 이해하는 것도 아니기 때문에 )

얼마 전 스터디 주제로 리액트 포탈을 다룰 일이 있었다.

면접 답변을 위해 개념 정도만 살짝 익히고 준비할 수도 있겠지만...

경험상 이런 식으로 개념만 익히면 나중에 아예 까먹어버리기 때문에 시간을 들여서 익히는 게 낫겠다고 판단했다.

직접 사용해 보고 공을 들여야 진짜 내 지식이 된다고 생각했고,

이런 이유로 직접 구현과 테스트를 진행해 보고 관련 내용을 최대한 상세하게 기록했다.

포탈 포스팅 보러가기

https://hotdogdev.tistory.com/85

[React] Portal이란?(w. 모달 구현)

최근 면접스터디를 준비하면서 리액트의 Portal에 대해 공부한 적이 있었다. 백문이불여일타라고... 설명을 여러번 보는 것보단 직접 구현해 보는 것이 도움이 될 것 같아 직접 시도해 봤다! 이

hotdogdev.tistory.com

수학 공부할 때 책만 읽지 않고 많은 문제를 직접 풀어봐야 하듯이

개발도 개념만 눈으로 읽어서 되는 게 아니라 직접 적용해 보고 테스트해보고, 비교해 봐야 진짜 내 지식이 되는 것 같다.

앞으로 시간이 오래 걸리더라도 이런 방식으로 공부해 나갈 생각이다.

취준 생활

커피챗을 통해 받은 피드백을 기반으로 이력서를 싹 뜯어고쳤다.

노션으로 만들었던 이력서를 피그마로 변경했고 포맷도 많이 바꿨다.

그리고 최대한 가독성 좋게 수정했다. (내 눈에만..가독성이 좋을 수도 있음 )

소개 부분의 내용도 아예 바꿨다.

이전엔 프론트엔드개발자에게 어울리는 소개를 찾아서 넣었다면, 이번엔 진짜 나에 대한 내용을 소개에 넣었다.

어느 정도 수정을 거친 후 다시 열심히 지원하고 있다.

두드리면 언젠간 될 것이라는 마음으로..!

운동

운동에 대한 의욕이 떨어졌다.(주 2회는 꼭 운동을 하긴 했지만...)

이놈의 완벽주의 성향은 운동까지 영향을 미친다.

헬스장에 갔으면 워밍업 10분 웨이트 1시간 유산소 40분 도합 두 시간은 채워야 제대로 된 운동이라는 바보 같은 생각 때문에 시간이 조금이라도 애매하면 차일피일 미뤘다.

이런 이유로 헬스장에 많이 못 갔다.

잘못된 걸 알지만 마음을 고쳐먹기가 힘들었다.

여유가 없어지니 운동을 하는 시간도 사치라는 생각이 들었고, 헬스장 가서 소비해야 할 시간에 다른 걸 해야할 것 같았다.

하지만 얼마 전 지인에게 공유받은 동영상을 보고 마인드셋을 다시 해야겠다고 느꼈다.

영상 내용을 대충 공유하자면,

목표를 작게 잡아야 오래 지속할 수 있고, 성공할 확률이 높다는 것인데..

나 같은 게으른 완벽주의자에게 딱 맞는 조언이었다.

헬스장에 가서

무조건 두 시간 이상 운동하고 오겠어 ❌

유산소 30분만이라도 가볍게 타고 오겠어 ⭕

헬스장까지 가는 것조차도! 유산소 운동이긴 하니까 너무 부담 갖지 않기로 했다!

집 나간 의욕 되찾기

사실 1월 중순 전까지 전반적으로 의욕이 떨어진 상황이었다.

모든 취준생이 그렇듯 자신감도 떨어지고, 자꾸만 나를 의심하고 불안감만 커져갔다.

그럼에도 해야 할 일들은 묵묵히 이어갔지만…돌이켜보면 억지로 이어갔다는 표현이 맞는 것 같다.

개인적으로 나는 이런 침울한 시기가 이어지는 걸 몹시 싫어하기 때문에(오랜 기간 땅굴을 파봤자 득이 될 게 없다는 걸 잘 안다.)

이런 시기를 박차고 나오기 위해 스스로에게 동기부여할 만할 거리들을 주는데, 이번엔 그게 D님과의 커피챗이었다.

커피챗을 통해 어느 부분이 부족한지, 어디를 더 채우면 좋을지에 대한 피드백과 격려를 많이 받았다.

이걸 계기로 개인프로젝트 개선을 진행하게 되었고, 덕분에 집 나간 의욕을 되찾을 수 있었다.

늦은 시간까지 커피챗을 진행해 주신 D님께 정말 감사하다...

잘한 점

힘들어도 해야 할 일은 묵묵히 해낸 것

잠깐 무기력했지만 그래도 나름 방법을 찾아 다시 한번 동기부여를 얻은 것

개인프로젝트 피드백 요청을 위해 용기 낸 것

아쉬운 점

이런저런 핑계로 헬스장을 자주 못 간 것

힘들다는 이유로 고양이에게 소홀했던 것

한 가지에 몰입하느라 시간 분배를 잘 못한 것
(특히 리액트 개념, 원리 이해하겠다고 과몰입해서 계획한 걸 종종 놓침)

→ 앞으로 시간을 정해두고 공부를 해야겠다고 느꼈다.

목표

✅ 부담감 내려놓고 운동 꾸준히 하기(주 3회 이상 목표로)

✅ 지원 & 면접준비 꾸준히

✅ 개인 프로젝트 성능 개선 이어서 진행하기

✅ 리액트 관련 포스팅 하기(세 개 이상)

글을 마치며

어느 날 우연히 본 '헤맨 만큼 내 땅'이라는 문구가 가슴에 콱 박혔다.

(유독 그날이 힘들었던 날이라 그랬을까? )

나는 지금 헤매고 있다.

그리고 이왕 헤매는 김에 가고 싶은 길이 있으면 주저하지 않고 도전하고 싶다.

그 덕분에 헤매는 시간이 더 길어질 수도 있겠지만..!

그만큼 값진 경험을 얻고 있으며, 이걸 통해 성장하고 있음을 믿는다.

다가오는 2월도 열심히 헤매보자 아자잣!

[React] Portal이란?(w. 모달 구현)

겨리! — Fri, 2 Feb 2024 19:19:27 +0900

최근 면접스터디를 준비하면서 리액트의 Portal에 대해 공부한 적이 있었다.

백문이불여일타라고...

설명을 여러번 보는 것보단 직접 구현해 보는 것이 도움이 될 것 같아 직접 시도해 봤다!
이에 대한 과정을 정리해보고자 한다.

보통 모달을 생각하면 화면 중앙에 예쁘게 뜨는 창 하나를 떠올릴 수 있을 것이다.

먼저 그런 일반적인 모달을 구현해봤다.

모달 컴포넌트 구현하기

// Modal.tsx
...
const ModalContainer = styled.div`
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  display: flex;
  align-items: center;
  justify-content: center;
`;

const StyledModal = styled.div`
  width: 250px;
  background-color: white;
  padding: 20px;
  border-radius: 4px;
  box-shadow: 0px 0px 8px rgba(0, 0, 0, 1);
`;

const Modal = ({ visible, children }: IModal) => {
  if (!visible) return null;
  return (
    <ModalContainer>
      <StyledModal>{children}</StyledModal>
    </ModalContainer>
  );
};
export default Modal;

모달 컴포넌트 사용하기

// Home.tsx
...
const StyledDiv = styled.div`
  background-color: #a0a0a0;
  width: 400px;
  height: 400px;
`;

const Home = () => {
	...
    <StyledDiv>
      <h3>modal 테스트</h3>
      <Button variant="contained" onClick={onOpen}>
        열기
      </Button>
      <Modal visible={visible}>
        <h1>hello world</h1>
        <h3>it's modal  </h3>
        <Button variant="contained" onClick={onClose}>
          닫기
        </Button>
      </Modal>
    </StyledDiv>
};

export default Home;

결과

위에서 말한 대로 화면 가운데에 예쁘게 떠있는 모달을 확인할 수 있다!

하지만 여기서...모달의 상위 엘리먼트인 div 태그에 transform 속성을 하나 추가해 준다면?

// Home.tsx
...
const StyledDiv = styled.div`
  background-color: #a0a0a0;
  width: 400px;
  height: 400px;
  // transform 속성 추가
  transform: translate(30px, 20px) rotate(10deg);
`;

const Home = () => {
	...
    <StyledDiv>
      <h3>modal 테스트</h3>
      <Button variant="contained" onClick={onOpen}>
        열기
      </Button>
      <Modal visible={visible}>
        <h1>hello world</h1>
        <h3>it's modal  </h3>
        <Button variant="contained" onClick={onClose}>
          닫기
        </Button>
      </Modal>
    </StyledDiv>
};

export default Home;

엥?

의도한 것과 다르게 스타일이 적용된다.

상위 엘리먼트의 스타일에 영향을 받은 모달

원인

나는 모달을 구현하기 위해 모달 쪽 div태그에 position 속성을 fixed로 주었다.

하지만 이 경우 의도하지 않은 스타일이 적용이 될 수 있다!

엘리먼트의 조상 중 하나가 tansform, perspective, filter 속성 중 하나를 가지고 있다면 뷰 포트 대신 해당 조상을 기준으로 삼게 되기 때문이다.

단, 요소의 조상 중 하나가 transform, perspective, filter 속성 중 어느 하나라도 none이 아니라면 (CSS Transforms 명세 참조) 뷰포트 대신 그 조상을 컨테이닝 블록으로 삼습니다. - MDN Web Docs

위 케이스에서 확인할 수 있듯이

CSS는 상속이 된다.

이로 인해 모달 엘리먼트가 상위 엘리먼트와 함께 사용이 되면 상위 엘리먼트의 스타일에 영향을 받을 수 있다.

해결 방법

조상 엘리먼트의 스타일에 영향을 받지 않도록 돔 트리에서 모달의 위치를 옮기면 된다!

즉, 모달이 선언되어 있는 div태그 내부가 아닌(위 사진 자료 중 elements에 선택되어 있는 부분) 외부의 다른 돔에서 렌더링 되도록 처리하면 된다.

이를 위해 리액트 포탈을 사용해 보았다.

리액트 포탈(Portal)이란?

컴포넌트가 종속되어 있는 돔 트리를 벗어나 외부의 다른 돔으로 렌더하는 기능이다.

이를 이용하기 위해선 createPortal API를 사용해야 한다.

createPortal는 react-dom에서 제공하는 함수이며, 사용방법은 다음과 같다

createPortal(children, domNode, key?)

✅ children : domNode의 childrend이 될 컴포넌트 or jsx 문법으로 작성한 html 태그
✅ domNode : children의 부모가 될 domDone(미리 생성되어 있는 돔 노드 정보를 가지고 있어야 함)
✅ key? : 선택인자로. 포탈의 키로 사용할 고유한 문자열 or 숫자

포탈 사용해서 모달 구현하기

index.html 내 root와 같은 레벨에 id가 modal-root인 div 태그 추가

<!-- index.html -->
...
<div id="root"></div>
<div id="modal-root"></div>
...

PortalModal 컴포넌트 구현

// PortalModal.tsx
...
import { createPortal } from 'react-dom';
...
const PortalModal = ({ visible, children }: IModal) => {
  // 부모 요소가 될 요소 정보 찾기
  const modalRoot = document.getElementById('modal-root') as HTMLElement;
  if (!visible) return null;
  return createPortal(
    <ModalContainer>
      <StyledModal>{children}</StyledModal>
    </ModalContainer>,
    modalRoot
  );
};

export default PortalModal;

적용 방식은 변함이 없기 때문에 생략

결과

구현한 모달이 root 내부가 아닌 modal-root 내부로 렌더 되는 것을 확인할 수 있었다!

이벤트

다른 돔트리로 렌더링이 되는 거면 이벤트는 어떤 식으로 처리가 될까?

이벤트 전파가 불가능하지 않을까?라고 생각했으나 틀린 판단이었다!

공식문서에서는 아래와 같이 설명하고 있다.

포탈 내부에서 발생한 이벤트는 리액트 트리에 포함된 상위로 전파될 것입니다.
DOM 트리에서는 그 상위가 아니라 하더라도 말입니다.

포탈이 돔트리의 어디에든 존재할 수 있다 하더라도 모든 다른 면에서는 일반적인 리액트 지식처럼 동작한다.

context와 같은 기능은 포탈이건 아니건 상관없이 같이 동작한다.

이렇게 동작하는 이유는 포탈이 돔트리에서의 위치와 관계없이 리액트 트리에 존재하기 때문이다.

확인해 보기

모달에 버튼을 추가하고 부모 엘리먼트에 이벤트 버블링이 발생하는지 확인해 봤다.

버튼과 핸들러 함수 추가

// PortalModal

const PortalModal = ({ visible, children }: IModal) => {
  const modalRoot = document.getElementById('modal-root') as HTMLElement;
  if (!visible) return null;
  return createPortal(
    <ModalContainer>
      <StyledModal>
        {children}
    	<!-- 이 버튼에서의 클릭 이벤트는 부모로 버블링 된다. 
        'onClick'의 속성이 정의되지 않았기 때문!  -->
        <button>다른 버튼</button>
      </StyledModal>
    </ModalContainer>,
    modalRoot
  );
};

export default PortalModal;

// Home.tsx

const Home = () => {
	const handleClick = (e: React.MouseEvent<HTMLElement>) => {
    	// 버블링이 발생한다면 로그가 출력되겠지!
		console.log(e.target);
	}; 
    
    return(
        <StyledDiv>
          <h3>modal 테스트</h3>
          ...
        </StyledDiv>
    );
};

export default Home;

실제화면과 콘솔창

modal에 있는 버튼을 클릭했더니 이벤트 버블링 때문에 Home.tsx의 handleClick 함수가 실행된다!

(modal에는 버튼만 만들어뒀지 이벤트 처리는 하지 않았다.)

테스트를 통해 엘리먼트가 다른 돔을 사용하더라도 포탈이 어플리케이션 트리 모양대로 이벤트를 전파한다는 것을 확인할 수 있었다.

밑의 사진을 보면 리액트 컴포넌트 트리에서는 포탈 모달 컴포넌트는 여전히 홈의 div 내부에 위치한다.

돔트리와 리액트 컴포넌트 트리 비교하기

결론

✅ 리액트 포탈을 사용하면 css 상속 구조에 유연하게 대처할 수 있다.

✅ 포탈로 만든 엘리먼트는 실제 돔 구조와 달리 리액트 어플리케이션 컴포넌트 트리 구조를 따르며 이벤트 또한 전파된다.

느낀 점

사실 여태껏 포탈을 사용해본 적이 없었다.
가끔씩 프론트엔드 오픈카톡방에서 관련된 질문이 올라올 때 스쳐가듯이 본 적은 있었지만

직접 사용해보지 않았으니..이게 정확히 무슨 기능인지, 어떤 장점이 있어 사용을 하는 건지 알 수 없었다.

특히 CSS 상속과 같은 문제는 실제로 충분히 경험할 수 있는 케이스라고 생각해서 포탈이라는 기능이 굉장히 실용적이라는 생각이 들었다(물론 다른 방법으로 대처할 수도 있겠지만..!)

학습 차원에서 테스트해보느라 대충 만들어서 아쉬운 감이 없지 않아 있는데..

나중에 모달이나 툴팁을 구현할 일이 생긴다면 포탈을 이용해서 구현해 봐야겠다!

Reference

https://react.dev/reference/react-dom/createPortal#reference

createPortal – React

The library for web and native user interfaces

react.dev

https://ko.legacy.reactjs.org/docs/portals.html

Portals – React

A JavaScript library for building user interfaces

ko.legacy.reactjs.org

https://jeonghwan-kim.github.io/2022/06/02/react-portal

리액트 Portal

…

jeonghwan-kim.github.io

개인 프로젝트 개선 기록 - CLS 개선

겨리! — Mon, 29 Jan 2024 18:25:15 +0900

오늘은 커피챗 때 피드백 받았던 CLS 개선에 대한 내용을 정리하고자 한다.

CLS가 뭔지 알아보기 전 비교부터 해보자!

개선 전과 개선 후

첫 번째 이미지를 보면 새로고침 클릭 시 이미지 로딩 전후로 레이아웃이 변경되는 것을 확인할 수 있다.

반면 두번째 이미지는 새로고침을 클릭해도 레이아웃의 변경이 일어나지 않는다.

CLS(Cumulative Layout Shift)란?

레이아웃 변경 횟수로, 화면에서 이동하는 컨텐츠의 양과 정도를 계산한 값이다.

이 지표는 사용자 중심의 성능 지표로서 컨텐츠가 화면에서 이리저리 움직이는 것이 불편을 초래할 수 있기 때문에 제공한다.

✔️ TIP

우수한 사용자 환경을 제공하기 위해선 사이트에서 페이지 방문의 75% 이상에서 CLS가 0.1 이하여야 한다.

솔직히 CLS에 대한 설명을 처음 봤을 땐 이게 그렇게 중요한가..?라고 생각했는데 아래의 예시 자료를 본 후 바로 납득했다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

약간 극단적인 예시이긴 하지만 실제로 있을 수 있는 일이고,

나 또한 비슷한 경험을 했던 적이 있었기에 CLS의 중요성에 대해 이해할 수 있었다.

⚙️ CLS가 좋지 않은 일반적인 원인들

✔️ 크기가 없는 이미지

✔️ 크기가 없는 광고, 삽입, iframe

✔️ 크기가 없는 광고, 삽입, iframe과 같이 동적으로 삽입된 콘텐츠

✔️ 웹 글꼴

본격적인 성능 측정을 위해 라이트하우스를 이용해 진단을 해봤다.

개선 전 성능

CLS가 0.102로 나타난다.

그리고 큰 레이아웃의 변화는 피하라는 경고 문구 또한 확인할 수 있었다.

⚙️ 원인과 개선 방법

나의 경우는 이미지태그에 크기 속성을 지정하지 않은 게 원인이었다.

web.dev 레이아웃 변경 누적 최적화 가이드에 나온 대로 이미지에 width, height 크기 속성을 추가해서 해결했다.

이렇게 하게 되면 이미지가 로드되는 동안 브라우저가 이미지에 맞는 올바른 크기의 공간을 할당할 수 있다고 한다.

이 부분은 내가 놓친 부분인데...사실 이미지 크기는 css로 크기를 설정해 줬기 때문에 상관없을 줄 알았다.

하지만 찾아본 결과..CSS와 HTML의 이미지 태그에서 width와 height를 설정하는 건 아주 큰 차이가 있었다.

HTML 이미지 태그의 width, height를 지정하는 경우

✔️ 브라우저에게 이미지의 원래 크기를 알려주는 역할

✔️ 브라우저는 이 정보를 통해 이미지가 로딩되기 전에 이미지가 차지할 공간을 미리 확보할 수 있다.

CSS에서 width와 height를 지정하는 경우

✔️ 이미지의 실제 표시 크기를 조절하는 역할을 한다.

너무 기초적인 내용인데 크게 착각하고 있음을 깨달았다..!

(~~조금 많이 창피하지만~~) 이제라도 제대로 알아서 다행..

개선 작업을 진행한 후 라이트 하우스를 통해 성능 측정을 다시 한번 시도해 봤다.

개선 후 성능

CLS가 0.102에서 0.001로 개선되었음을 확인할 수 있었다!!
또 기존에 빨간색으로 표시되던 Avoid large layout shift 문구 또한 사라졌다!

느낀 점

모 침대 회사의 흔들리지 않는 편안함이라는 홍보 문구처럼..

프론트엔드 개발자 역시 사용자에게 흔들리지 않는 편안한 레이아웃을 제공하는 것이 중요하다고 느꼈다.

'이 문제가 더 큰 문제는 개발 중인 사이트와 사용자가 경험하는 방식이 크게 다른 경우가 많기 때문입니다. 맞춤설정 콘텐츠 또는 서드 파티 콘텐츠는 개발 단계에서 프로덕션 단계에서처럼 동작하지 않는 경우가 많고, 테스트 이미지가 이미 개발자의 브라우저 캐시에 있는 경우가 많으며, 로컬에서 실행되는 API 호출은 너무 빨라서 지연을 눈에 띄지 않는 경우가 많습니다.'

web.dev에 나와있는 저 설명대로 개발 환경과 실제 운영 환경의 차이로 인해 놓치기 쉬운 부분이라고 생각했다.

놓치기 쉽지만 사용자는 불편함을 느낄 수 있으니 더욱더 신경 써야겠다고 느낌!!! 꼼꼼하게 확인하자!

Reference

https://web.dev/articles/cls?hl=ko

Cumulative Layout Shift (CLS) | Articles | web.dev

이 게시물에서는 레이아웃 변경 횟수 (CLS) 측정항목을 소개하고 이를 측정하는 방법을 설명합니다.

web.dev

https://web.dev/articles/optimize-cls?hl=ko

레이아웃 변경 누적 최적화 | Articles | web.dev

레이아웃 변경 횟수 (CLS)는 사용자가 페이지 콘텐츠의 갑작스러운 변화를 경험하는 빈도를 정량화하는 측정항목입니다. 이 가이드에서는 크기 또는 동적 콘텐츠가 없는 이미지 및 iframe과 같이 C

web.dev

개인 프로젝트 개선 기록

겨리! — Thu, 25 Jan 2024 00:37:09 +0900

작년 하반기에 개인프로젝트로 진행했던 테스트 사이트의 개선 과정을 기록하고자 한다.

사실 처음에는 리액트를 공부할 겸 만들어본 간단한 프로젝트라 지인들에게만 살짝 보여주고 덮어뒀었다.

하지만 최근 진행한 커피챗에서 이왕 배포까지 한 거 사용자한테 피드백을 받아서 개선해 보라는 조언을 들었고 곰곰이 생각해 보니 어차피 내가 만든 건데 부끄러워할 필요가 뭐가 있으며, 부족한 만큼 피드백을 받아 개선해 나가면 오히려 좋은 거 아닌가?라는 생각이 들었다.

또 평소 서비스 운영 경험에 대한 열망(?)이 있는데 내가 만든 프로젝트를 배포해서 사람들이 사용하고, 그들로부터 피드백을 받아 개선해 나가는 것도 어떻게 보면 비슷한 경험이 아닐까 하는 생각이 들었다.
(실제로 비즈니스적인 가치를 창출하는 서비스들과 비교할 수는 없겠지만 그래도 이 경험을 통해 많이 배울 수 있다고 생각했다.)

이러한 이유로 GA 기능을 추가한 후 바로 실행에 옮겼다.

프론트엔트 오픈카톡을 포함한 다양한 커뮤니티와 지인들에게 링크를 공유하며, 피드백을 요청드렸다.

정말 감사하게도 많은 분들이 시간을 내서 피드백을 주셨다.

(여러분의 피드백 덕분에 제가 또 많이 배웠습니다. 감사합니다!)

홍보 메세지

피드백 내용들

피드백을 정리한 후 버그와 중복된 요구사항을 중심으로 개선을 진행했다.

피드백 정리

개선 내용

⚙️ 전체 유형 페이지 추가와 결과 이미지 추가

결과 페이지에 다른 유형 보기 버튼을 추가하여 다른 유형들도 확인할 수 있도록 개선했다.

또 전체유형보기 페이지에서 유형을 클릭하면 해당 결과 페이지로 이동하여 상세내용을 확인할 수 있도록 개발했다.

결과 이미지도 다양하게 추가해 줬다. 그리고 작업하는 김에 png 포맷의 이미지를 webp 포맷으로 변경해 줬다.

여담이지만 최근에 원티드 프리온보딩을 수강하면서 최적화에 대한 걸 배웠고, 거기서 webp 포맷에 대해 알게 됐다.

용량이 적다는 장점이 있다고 해서 시도해 봤는데 진짜 절반으로 줄어드는 것을 확인할 수 있었다..!

png포맷과 webp 포맷 크기 비교

⚙️ 타이틀 깨짐 현상 개선

글자 깨짐 현상 개선 전 후

화면 크기가 줄어들었을 때 하이라이트로 표현한 타이틀 부분이 깨지는 현상이 있었다.

기존엔 하이라이트를 표현하기 위해 mark 태그를 사용해서 구현했었는데 이를 위해 display 속성을 inline-block으로 줘서 생긴 현상이었다.

이를 개선하기 위해 mark 태그를 제거하고 background-image에 linear-gradient를 적용했다.

⚙️ 응답 페이지 개선 - 현재 문항 표시와 홈버튼 추가

개선 후

현재문항/전체문항을 프로그래스바 위에 배치했고, 응답 도중 홈 화면으로 이동할 수 있도록 버튼을 추가했다.

사실 이 부분은 평소 인터넷에서 유행하는 테스트를 진행했을 때 나도 불편하다고 느꼈던 부분들이다.

저런 류의 테스트 사이트는 보통 sns나 카카오톡으로 친구들이 공유해 준 링크를 통해 이용하게 되는데

중간에 응답을 잘못한 경우 아예 껐다가 다시 켜야 해서 불편함을 느낀 적이 종종 있었다.

아무래도 혼자 기획하고 개발하다 보니 저런 부분에선 디테일을 많이 놓친 것 같다.

그래도 이렇게 피드백을 통해 조금이나마 개선할 수 있어 다행이라는 생각이 들었다.

느낀 점

작년에 퇴사한 이유 중 하나가 바로 서비스 운영에 대한 열망이었다.

SI 개발자로 근무를 하며 다양한 사이트에서 여러 신규 개발 프로젝트와 유지보수 프로젝트를 경험했지만
매번 프로젝트 기간이 끝나면 철수를 해야 했고, 개선하고 싶어도 개선할 수 없는 환경에 대한 아쉬움이 많았다.

그런데도 개선은 뭔가 거창한 프로젝트에서나 할 수 있는 그런 중대한 일이라고 생각했기 때문에 시도하지 않았다.

지금 와서 보니 그 생각은 틀린 것 같다. ‍♀️ ‍♀️

어쨌든 이렇게 시도 함으로써 실제 사용자의 피드백을 받아볼 수 있었고, 개선하는 과정을 통해 또 많은 걸 배울 수 있었기 때문이다!

tmi지만 열흘이라는 기간 동안 390명의 방문자수를 기록했다..! 작고 소중한 나의 방문자수!

끝으로 바쁘실 텐데 관심 가져주시고 피드백해 주신 많은 분들께 다시 한번 감사의 인사를 전하고 싶다.

감사합니다

프로젝트 보러 가기

https://find-my-cat.netlify.app

내게 맞는 고양이 찾기!

나와 맞는 고양이는 어떤 유형일까?

find-my-cat.netlify.app

로컬환경에서 메타태그 테스트하기(ngrok 사용)

겨리! — Wed, 24 Jan 2024 16:33:20 +0900

프로젝트를 리팩토링 하던 중 메타태그를 수정할 일이 있었다.

잘 수정되었는지 확인 하기위해 매번 배포를 진행하는 건 리스크가 있다고 생각하여 로컬에서 테스트 할 수 있는 방법을 찾아보았다.

찾아보니 ngrok이라는 서비스를 사용하면 로컬 환경에서도 테스트할 수 있다고 한다!

이번 기회에 ngrok이 뭔지 어떻게 사용하면 되는지 정리해보고자 한다.

ngrok이란?

Webhook을 이용하여 로컬에 떠있는 서버를 방화벽을 넘어 ngrok.com 쪽에 바인딩해주는 서비스

일반적으로 로컬 환경에서 작업을 할 때 웹서버를 로컬호스트에서 실행 후 개발을 진행하는데, 이렇게되면 외부에서 접근이 불가능하다. 이 때 ngrok을 사용하면 로컬개발환경에서 실행중인 웹서버를 외부에 공개적으로 접근이 가능한 URL로 노출시킬 수 있다.

ngrok 시작하기

설치

아래 사이트에서 사용하는 OS에 맞게 다운로드 후 설치한다.

https://ngrok.com/docs/getting-started/

Quickstart | ngrok documentation

This quickstart will use the ngrok agent to put your application on

ngrok.com

인증

ngrok을 사용하기 위해서는 가입 후 인증이 필요하다.

1. ngrok 사이트 회원가입하기

2. Getting Started > Your Authtoken 에서 인증토큰 복사하기

3. ngrok을 실행시켜 인증 토큰 추가하기

ngrok authtoken 인증토큰

ngrok 실행하기

로컬 서버를 실행 시킨 후 ngrok에 아래와 같이 명령어를 실행한다.

ngrok http 포트번호

내 로컬서버의 포트번호는 3000이었기 때문에 ngrok http 3000으로 실행했다.

✔️ 실행화면

정상적으로 실행이 되면 위와 같은 화면이 뜨는데, Forwarding에 나온 주소를 사용하면 된다.

아래와 같이 메타태그 수정 후 테스트가 가능해졌다!

https://ngrok.com/docs

Overview | ngrok documentation

ngrok documentation

ngrok.com

프로젝트에 Open Graph(OG) 설정하기

겨리! — Wed, 24 Jan 2024 03:01:24 +0900

개인프로젝트를 리팩토링 하던 중 링크 공유시 미리보기에 정보가 너무 없다는 생각이 들어 Open Graph를 적용해봤다.

적용하는 과정을 정리해보고자 한다.

적용 전

처음엔 이렇게 아무것도 없어서 이게 무슨 링크인지 확인이 불가능했다. (뭔가 수상함... )

특히 나는 개발자 오픈카톡에 내 프로젝트 링크를 자주 공유하는 편이라 어떤 사이트인지 정보가 잘 나타나있어야 사람들이 조금이나마 더 관심을 가질 것이라고 생각했다.

Open Graph를 적용하기 전에 무엇인지부터 알아보자!

Open Graph(OG)

Open Graph 사이트에 나온 설명은 아래와 같다

오픈그래프 프로토콜은 페이스북에서 처음 만들어졌으며, Dublin Core, link-rel canonical, Microformats, 그리고 RDFa로부터 영감을 받았습니다. 이 페이지의 설계서는 버전 0.9의 Open Web Foundation Agreement 아래에서 사용 가능합니다. 이 웹사이트는 오픈소스이며, 2014년 10월 20일에 최종 업데이트 되었습니다.

Open Graph는 어떤 HTML 문서의 메타정보를 쉽게 표시하기 위해서 메타정보에 해당하는 제목, 설명, 문서의 타입, 대표 URL 등 다양한 요소들에 대해서 사람들이 통일해서 쓸 수 있도록 정의해놓은 프로토콜이며 페이스북에 의하여 기존의 다양한 메타 데이터 표기 방법을 참조하여 만들어졌습니다.

✔️ 참고

RDFa는 웹페이지의 HTML 또는 XML 요소의 속성에 PDF 표현을 삽입하여 정보를 표현하는데 이를 사용하기 위해서는 웹페이지의 <head> 요소 내에 추가적인 <meta>태그를 사용해야한다고 한다.

⚙️ 원리

플랫폼에 URL을 붙여 넣는 순간 미리 해당 웹사이트를 크롤러가 먼저 방문해서 HTML Head의 메타 데이터를 크롤링하여 미리보기 화면을 생성한다.

⚙️ 좀 더 자세한 원리

1. 사용자가 링크를 입력창에 입력한다.

2. 페이스북, 카카오톡은 입력창의 문자열이 링크라는 것을 파악한다(정규표현식으로 해당 문자열이 링크라는 것을 파악)

3. 링크 임을 파악 후 페이스북, 카카오톡 등의 크롤러는 미리 그 웹사이트를 방문해서 HTML head의 오픈 그래프(Open Graph) 메타 데이터를 긁어온다.

4. 메타 데이터 중 og:title, og:description, og:image가 각각 제목, 설명,이미지의 정보를 나타낸다.

5. 그리고 그 정보를 바탕으로 미리 화면을 생성해준다.

✔️ Basic Metadata

우리의 웹페이지를 그래프 개체로 바꾸려면 페이지에 기본 메타데이터를 추가해야한다.

기본적인 메타 데이터로는 title, description, image, url이 있다.

og:title - 그래프 내에 표시되어야 하는 개체의 제목
og:type - 개체의 유형(지정하는 유형에 따라 다른 속성이 필요할 수도 있다.)
og:image - 그래프 내에서 개체를 나타내야 하는 이미지 URL
og:url - 그래프에서 영구 ID로 사용될 개체의 표준 URL

예시

<html prefix="og: https://ogp.me/ns#">
<head>
<title>The Rock (1996)</title>
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="https://www.imdb.com/title/tt0117500/" />
<meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />
...
</head>
...
</html>

이외에도 많은 메타데이터 속성들이 있는데 자세한 정보는 Open Graph 사이트에서 확인 할 수 있다.

적용하기

<!-- index.html -->
<head>
...
<meta
  property="og:image"
  content="https://find-my-cat.netlify.app/images/cat.webp"
/>
<meta property="og:title" content="내게 맞는 고양이 찾기" />
<meta
  property="og:description"
  content="나와 맞는 고양이는 어떤 유형일까?"
/>
...
</head>

적용 후 배포도 정상적으로 됐는데 반영이 안 된다...

이유는 바로 '캐싱' 때문!

✔️ 캐싱(Caching)

반복적으로 호출되는 특정한 데이터를 캐시 메모리의 임시로 저장하여 다음 번에 호출될 때 빠르게 해당 데이터를 공급해주는 것

보통 모든 웹서비스, 앱들에는 이러한 캐싱 시스템이 구축되어 있다.

일반적으로 이런 캐싱에는 TTL(Time-to-Live)라는 소멸시효가 걸려있는데, 이 소멸시효가 지나지 않은 경우 이미 캐싱된 데이터를 참조해서 불러올 수 있다.

이러한 이유로 TTL이 만료되기 전까지는 수정사항이 미리보기에 반영되지 않는다.

이런 경우 때문에 캐싱을 리로드할 수 있는 기능을 지원하는 경우가 있다.

페이스북의 공유디버거 캐싱 초기화 버튼

카카오의 공유디버거 캐시 초기화 버튼

캐시 초기화하기

카카오 디벨로퍼 > 도구 > 디버거 도구 > 공유 디버거 > 캐시 초기화 클릭

초기화 후 테스트해보니 미리보기에 잘 반영되는 것을 확인할 수 있었다.

적용 후

느낀점

어떻게 보면 당연한 얘기일 수 있지만

개발한 서비스가 사용자의 이목을 끌기 위해선 오픈그래프의 이미지나 문구 또한 신경써서 적용해야한다고 느꼈다.

나만 해도 어디선가 링크를 받았을 때 그 링크가 무슨 사이트의 링크인지 알지 못하면 흥미가 떨어지기 때문이다.

프로젝트 보러가기

https://find-my-cat.netlify.app

내게 맞는 고양이 찾기

나와 맞는 고양이는 어떤 유형일까?

find-my-cat.netlify.app

Reference

https://ogp.me/

Open Graph protocol

The Open Graph protocol enables any web page to become a rich object in a social graph.

ogp.me

https://blog.ab180.co/posts/open-graph-as-a-website-preview

AB180 Blog | 링크의 미리보기 제목, 설명, 이미지를 결정하는 open graph 태그

링크의 미리보기 제목, 설명, 이미지를 결정하는 open graph 태그에 대해 알아보자

blog.ab180.co