ShipFriend TechBlog https://shipfriend.dev 개인 개발 블로그로, Nextjs로 개발되었습니다. 개발 관련 글을 작성합니다. Sat, 28 Mar 2026 05:48:30 GMT https://validator.w3.org/feed/docs/rss2.html Feed for Next.js ShipFriend TechBlog https://shipfriend.dev/favicon.png https://shipfriend.dev All rights reserved 2026 <![CDATA[FastAPI는 왜 사용하는 걸까?]]> https://shipfriend.dev/posts/fastapi는-왜-사용하는-걸까 https://shipfriend.dev/posts/fastapi는-왜-사용하는-걸까 Sat, 28 Mar 2026 04:45:57 GMT 일반적인 모델 검증 ~17x 빨라졌다고 한다. 현대 프로그래밍에서는 타입 일관성을 지키는게 가장 중요하다고 느꼈다. 타입이 일관적이지 못하면 중간에 생기는 사이드이펙트 디버깅에 들어가는 시간과 공수가 너무 많이 들어간다고 생각했다. 그런 점에서 FastAPI를 사용할 때에는 Pydantic 모델을 미리 정의하고 하는 것을 컨벤션으로 지정해두는 것이 좋겠다. ### 다른 프레임워크에 비해 가지는 장점 사실 이 섹션이 가장 중요할 것 같다. 기술스택을 선택할 때 많은 대체제가 존재하는데 그 중에서 파이썬의 FastAPI를 선택해야하는 이유에 대해서 알아보자. #### Python 언어는 고정일 경우라면? 파이썬 언어를 사용해야만 하는 프로젝트라면 FastAPI를 선택해야할 이유는 명확하다. ##### 1️⃣ 압도적인 성능 - FastAPI는 ASGI + Uvicorn 조합으로 동작해서 nodejs 같은 이벤트루프 기반으로 비동기 방식으로 요청을 처리한다. 다른 프레임워크들(Flask, Django)의 블로킹 WSGI 방식과는 다르다. **ASGI란 무엇인가?** Asynchronous Server Gateway Interface 라는 뜻으로, 비동기 서버를 위한 표준 인터페이스 명세를 의미한다. 다른 인터페이스로는 동기적인 Web Server Gateway Interface, WSGI가 있다. ##### 2️⃣ 자동 문서화 및 검증, 타입 힌트 기반 개발 생산성 - Pydantic 타입 엔진의 강력함이 하나의 무기이다. Pydantic 모델을 한 번만 정의하면 요청 검증, 응답 직렬화, Swagger API Docs 같은 문서를 자동으로 생성해준다. - 별도의 라이브러리가 해주는 일들을 알아서 해주는 부분이 많아 개발 생산성에서 유리하다. ##### 3️⃣ async / await 지원 - 다른 프레임워크 Flask 같은 경우는 별도 설정 후에 비동기 `async/await`을 사용할 수 있지만, FastAPI는 비동기를 네이티브하게 지원한다. ##### 4️⃣ 높은 AI 프로젝트 통합도 - 우리 프로젝트에서는 이 경우에 해당했다. AI기반 프로젝트는 파이썬의 높은 AI 패키지 활용도를 활용하는 것이 좋기 때문이다. - 머신러닝 모델 대부분이 Python으로 개발되기 때문에, 별도 변환 없이 모델을 바로 API 엔드포인트에 연결할 수 있는 점이 강력한 점이다. - 나의 경우에도 AI 패키지를 모노레포로 관리 중인데 이 패키지의 함수들 별도의 어댑터나 브릿지 없이 바로 사용할 수 있기 때문에 편리한 것 같다. #### 다른 생태계를 사용해도 된다면? 다른 생태계 그러니까 Python을 고정적으로 사용해야하는 환경이 아니라면 Nest.js나 Spring Boot 같은 다른 프레임워크 옵션들을 선택해볼 수 있다. 그렇다면 이들과의 비교는 어떨까? | 항목 | Spring Boot | NestJS | FastAPI | | --------- | -------------- | ------------ | -------------- | | 처리량(RPS) | ~11,000–13,000 | ~8,000–9,000 | ~15,000–20,000 | | 평균 응답시간 | ~98ms | ~118ms | ~60–80ms | | 초기 메모리 | ~512MB (JVM) | ~245MB | ~80–120MB | | 빌드/기동 시간 | ~42초 / ~8.7초 | ~15초 / ~2.3초 | ~5초 / ~0.5초 | | I/O 집약 성능 | 멀티스레드 강점 | 비동기 강점 | 비동기 강점 | 실제 프레임워크 비교 표이다. 이 부분은 항상 절대적인 것은 아니다. 하지만 참고만 해본다면, 강점과 약점이 명확하다. 평균 응답시간에서는 다른 프레임워크 보다 우위에 있다는 점에 놀랐고, 초기 메모리도 압도적으로 가볍다는 점도 신기했다. FastAPI라고 자신 할만 한 성능이라고 생각된다. #### 약점 하지만 약점도 명확한데, 바로 **생태계와 그 성숙도의 차이**이다. java와 node 진영은 라이브러리 배포와 사용 생태계가 잘 갖춰져있고 성숙되었다. 하지만 파이썬은 약간은 열받는 버전 별 큰 차이점들과 비동긱를 적극적으로 사용하는 프레임워크지만 생태계 전반에 비동기를 지원하는 라이브러리의 부족과 성숙도 낮음 문제가 명확한 약점이다. Python이 버전 충돌이 많은 근본 이유는 **"격리가 기본값이 아님"** 때문이다. Node.js는 설계부터 프로젝트 단위 격리가 기본이지만, Python은 글로벌 설치가 기본이고 격리는 개발자가 직접 챙겨야 한다. 이렇게 적어보니 명확하게 나오는 것 같다. ## 결론 ### 선택해야하는 경우 - AI / ML 프로젝트이다. - Python을 써야하는데 빠른 성능을 원한다. ### 선택하지 않아도 되는 경우 AI / ML 프로젝트가 아니고, 팀의 주력 언어가 TypeScript나 Java라면 NestJS나 Spring Boot가 생태계 성숙도 면에서 유리하다. 이게 생태계 성숙도를 무시할 수 없는 이유가 있다. FastAPI는 분명 빠르지만, 비동기를 지원하지 않는 라이브러리를 함께 사용하는 순간 비동기의 이점이 사라진다. 예를 들어 동기 ORM이나 동기 DB 드라이버를 그대로 쓰면, 이벤트 루프가 블로킹되어 오히려 성능이 떨어질 수 있다. 최근에 AI 코딩 도구를 활용하면서 개발을 하다보면서 코드레벨에 대한 지식은 점점 활용도를 잃어가고 있다고 느낀다. 그 대신 중요해진 것은 **프레임워크 레벨의 설계 철학과 선택에 대한 이유** 등이 중요해진 것 같다. 설계 철학을 알게되면 전체 애플리케이션의 아키텍쳐를 설계하는데 이유를 뒷받침 할 수 있기 때문이라고 생각했다. > **이번에 새롭게 추가한 콜아웃 UI이다. 🤓 ㅎㅎ** ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[개인 블로그에 Opengraph 카드 UI 만들기]]> https://shipfriend.dev/posts/개인-블로그에-opengraph-카드-ui-만들기 https://shipfriend.dev/posts/개인-블로그에-opengraph-카드-ui-만들기 Sun, 15 Mar 2026 06:50:40 GMT 오픈 그래프(Open Graph)는 웹 페이지가 소셜 미디어에 공유될 때 어떻게 보이는지를 제어하는 메타데이터 프로토콜입니다. Facebook이 2010년에 만들었고, 지금은 카카오톡, 트위터, Slack, Discord 등 거의 모든 플랫폼에서 사용합니다. 해당 사이트의 이름, 설명, 파비콘 (혹은 다른 대표이미지) 등을 미리 보여주는 기능이라 UX적으로 매우 좋다고 생각한다. ![Discord의 Opengraph 렌더링](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1773553576679-image-voWZsrLN3XSY9b5xKTtaXQMi75GGZv.webp) 오픈그래프 태그에는 여러가지가 있는데, 아래 태그들이 있다. 특정 플랫폼 별로 지정할 수도 있다. ```html ``` ### 오픈그래프의 UX 관점 오픈그래프(Opengraph)가 UX적 관점으로 훌륭하다고 생각하는 이유는 간단하다. 개인적으로 원래 옛날부터 잘 모르는 링크는 함부로 클릭하는 것이 아니라고 들어와서 그런 탓일까. 링크만 있으면 잘 클릭하지 않는 편이다. 그렇기 때문에 UX 관점에서 오픈그래프 카드 or 배너가 가지는 의미가 중요하다고 생각한다. 원래라면 링크만 있을 때는 볼 수 없는 해당 사이트의 타이틀, 설명, 썸네일 등을 한눈에 볼 수 있기 때문에 사용자로 하여금 무슨 사이트일지 알 수 있게 해준다. ![와!](https://media1.tenor.com/m/_TySLMd48JIAAAAd/lizard-lizard-lizard-lizard.gif) ## 원리 직접 구현하기 전에는 사실 크롤러가 필요한 줄 몰랐다. `og:` 접두사로 시작하는 태그가 있기 때문에 외부 혹은 web api로 지원을 해주지 않을까라는 막연한 생각을 가지고 있었다. 알아보니 생각보다는 단순한 방법으로 가져오고 있었다. OG 데이터를 가져오는 것은 아래와 같다. - 사용자가 링크를 공유 - 플랫폼의 크롤러가 해당 URL을 직접 방문 - head 태그 내의 og: 태그를 파싱 - UI 렌더링 의 단순한 방법이었다. ### 구현 코드 구현에 필요한 코드는 서버사이드의 외부 사이트 조회 API와 렌더링에 필요한 코드 2가지다.
클릭해서 API 코드보기 ```ts // GET /api/opengraph // HTML 파일로 부터 메타데이터 파싱 const getMeta = (html: string, prop: string): string | null => { const patterns = [ new RegExp( `]+(?:property|name)=["']${prop}["'][^>]+content=["']([^"']*)["']`, 'i' ), new RegExp( `]+content=["']([^"']*)["'][^>]+(?:property|name)=["']${prop}["']`, 'i' ), ]; for (const pattern of patterns) { const match = html.match(pattern); if (match?.[1]?.trim()) return match[1].trim(); } return null; }; // Open Graph API 엔드포인트 export const GET = async (request: Request) => { const { searchParams } = new URL(request.url); const url = searchParams.get('url'); if (!url) return Response.json({ error: 'url required' }, { status: 400 }); try { new URL(url); } catch { return Response.json({ error: 'invalid url' }, { status: 400 }); } try { const res = await fetch(url, { headers: { 'User-Agent': 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', Accept: 'text/html,application/xhtml+xml', }, signal: AbortSignal.timeout(5000), }); if (!res.ok) return Response.json({ error: 'fetch failed' }, { status: 502 }); const html = await res.text(); const urlObj = new URL(url); const title = getMeta(html, 'og:title') || getMeta(html, 'twitter:title') || html.match(/]*>([^<]+)<\/title>/i)?.[1]?.trim() || null; const description = getMeta(html, 'og:description') || getMeta(html, 'twitter:description') || getMeta(html, 'description') || null; const image = getMeta(html, 'og:image') || getMeta(html, 'twitter:image:src') || getMeta(html, 'twitter:image') || null; const siteName = getMeta(html, 'og:site_name') || null; const favicon = `https://www.google.com/s2/favicons?domain=${urlObj.hostname}&sz=64`; return Response.json( { url, title, description, image, siteName, favicon, hostname: urlObj.hostname, }, { headers: { 'Cache-Control': 'public, max-age=86400, stale-while-revalidate=3600', }, } ); } catch { return Response.json({ error: 'fetch failed' }, { status: 502 }); } }; ```

위 캐시 컨트롤에서 캐시 타임을 길게 잡았는데 이는 외부 사이트이기 때문에 해당 사이트의 대략적인 정보만 알려주는 목적이라 새로운 데이터 업데이트 중요도가 낮기 때문이다. --- 그리고 새롭게 알게된 사실이 있다. 원래는 rehypeRewrite 기능을 사용해서 마크다운 -> HTML 변환 과정이 있다. 변환 과정 사이에 rehypeRewrite 플러그인을 추가하여 노드를 순회하면서 원하는 특정 태그에 조작을 하는 방식으로 글 내부 조작을 했었다. 그런데 이렇게 하는 경우 rehypeRewrite 플러그인이 점점 비대해지는 단점이 있었다. 왜냐하면 JSX 방식이 아니라 dom 엘리먼트를 생성하고 하위에 children을 추가하는 식으로 UI를 만들어야했기 때문이다.. 이 방법이 너무 번거롭고 특히 OgCard 같은 어느정도 복잡도를 가진 컴포넌트를 만드려고 하니 코드가 너무 길어지는 문제가 생겼다. 컴포넌트 방식으로 할 수 없나 방법을 찾아보니 MDEditor.Markdown 컴포넌트의 props로 components 로 미리 만들어둔 컴포넌트와 그 컴포넌트를 지칭하는 태그 이름 (여기서는 ogcard)을 매핑하여 전달해주면 rehype 과정에서 간단하게 컴포넌트로 불러올 수 있었다. ```tsx href ? : null, } as any} <-- ogcard를 tagName으로 OgLinkCard 컴포넌트 치환 rehypeRewrite={(node, index?, parent?) => { asideStyleRewrite(node); renderOpenGraph(node, index, parent as Element | undefined); renderYoutubeEmbed( node, index || 0, parent as Element | undefined ); addImageClickHandler(node); addDescriptionUnderImage( node, index, parent as Element | undefined ); }} /> ``` 그런 다음 rehype 함수를 만들어서 p > a 태그가 있다면 ogcard 태그 요소를 추가하는 동작을 작성한다. 여기서 ogcard 태그는 실제 렌더링 때 OgLinkCard로 치환되어 렌더링된다. ```ts /** * 링크를 감지하고 marker 노드로 변환 * 실제 렌더링은 PostBody의 components prop에서 OgLinkCard 컴포넌트가 담당 */ export const renderOpenGraph = ( node: any, index?: number, parent?: Element ) => { if (node.type === 'element' && node.tagName === 'p' && node.children) { const aTag = node.children.find( (node: any) => node.type === 'element' && node.tagName === 'a' ); if (!aTag) return; const href = aTag.properties?.href; if (!href || !(href.startsWith('/') || href.startsWith('http'))) return; const ogNode = { type: 'element', tagName: 'ogcard', properties: { href }, children: [], }; if ( index !== undefined && parent?.children && Array.isArray(parent.children) ) { // 링크 텍스트가 URL 자체인 경우(bare URL, [url](url)) →

대체 // 커스텀 텍스트인 경우([text](url)) →

유지 후 카드 삽입 const linkText = aTag.children?.find((c: any) => c.type === 'text')?.value ?? ''; const isUrlOnlyLink = linkText === href; if (isUrlOnlyLink) { parent.children.splice(index, 1, ogNode); } else { parent.children.splice(index + 1, 0, ogNode); } } } }; ``` ## 결과 결과적으로 원래라면 StoryHelper 다운로드라는 대체 텍스트 링크만 보이던 부분의 아래에 오픈그래프 카드 UI가 렌더링 되는 것을 볼 수 있다. ![결과](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1773556624717-image-BfOaaFmhf2NZS7HNU9g3KHcSwYiXwT.webp) 티스토리 같은 블로그 플랫폼에서는 당연하게 지원되는 기능이지만, 자유도 100%인 개인 블로그에서는 이런 기능을 직접 추가해야 한다는 점이 어떻게 보면 단점이지만 재미있는 포인트가 되는 것 같다. ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[JavaScript의 Map 자료구조에 대해서 자세하게 알아보자]]> https://shipfriend.dev/posts/javascript의-map-자료구조에-대해서-자세하게-알아보자 https://shipfriend.dev/posts/javascript의-map-자료구조에-대해서-자세하게-알아보자 Sat, 14 Feb 2026 13:14:02 GMT console.log(obj); { name: "jeongwoo", location: "Seoul" } */ ``` 자바스크립트 문법에서 가장 기초가 되는 객체 구조이다. 하지만 이 글에서는 이 객체에 대해서 다루고자 하는 것이 아닌 new Map() 구조와의 차이점을 중점적으로 비교해보고자 한다. ## 기본적인 차이점 Object, 객체 자료형은 데이터 저장도 하지만 원래 Object 자료형은 데이터 저장보다는 객체 지향 프로그래밍을 위해 설계되었다. 그렇지만 실제로는 키-값 저장소로 많이 사용되고 있다. Map 구조는 똑같이 키-값 구조이지만, 이 자료구조는 정말 **데이터 저장**만을 목적으로 하는 점이 다르다. ## Map() 에 대해서 > The Map object holds key-value pairs and remembers the original insertion order of the keys. Any value (both objects and primitive values) may be used as either a key or a value. 기본적으로 new Map()으로 생성하는 map 자료구조는 객체와 유사하다. ![MDN](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1771064392643-image-MTPPAqOFXBWTlHYeiUS6aLK9FF6Nrk.webp) 둘 다 값을 지정하는 키를 설정하고, 그에 대한 값을 저장한다. ## Map과 Object의 차이점 차이점은 몇 가지가 있는데 그 중에서 내가 중요하다고 생각하는 성능과 반복에 대해서 더 자세하게 다뤄보겠다. ### 일반적인 차이점, 키의 타입과 순서 보장, 크기 확인, 프로토타입 오염 방지 Object와 Map 구조의 차이점 중 첫째는 **키의 타입이**다. Object의 경우에는 키 값에 string, symobl만 가능하다. 하지만 Map은 다른 타입들도 가능하다는 점이 다르다. 일반적으로 Object에 1이라는 키 값을 사용하면 "1" 같이 string 타입으로 자동 변환되는데, Map의 경우에는 number 타입의 1이 키 값이 될 수 있다. ```js const map = new Map(); map.set(1, 'number key'); ``` 또 **순서 보장**, 이건 공부하면서 새롭게 알게 된 사실이다. map 에 추가하는 데이터의 순서를 보장한다. 정확히 말하면 추가된 키 값의 순서를 보장한다고 한다. ```js map.set('b', 2); map.set('a', 1); console.log(map.keys()); // ['b', 'a'] ``` **크기 계산**, Object에 들어있는 데이터의 키-값의 수를 알려면 `Object.keys(obj).length` 처럼 2번 연산을 해야한다. 하지만 Map의 경우에는 기본 내장 프로퍼티인 `map.size`로 쉽게 값을 받을 수 있다. ### 반복, Iteration 이 글을 쓰려고 했던 핵심 이유이다. Object와 Map 구조는 반복하는 방법에서 차이가 있다. ```js // Object: 메서드를 통해 간접적으로 const obj = { a: 1, b: 2 }; for (const key in obj) { } // for...in Object.keys(obj).forEach(key => {}); // 배열로 변환 후 순회 // Map: iterable이라 직접 가능 const map = new Map([['a', 1], ['b', 2]]); for (const [key, value] of map) { } // 바로 순회 가능 map.forEach((value, key) => {}); // forEach도 지원 ``` ### 성능 최적화 Object를 사용하는 것에 비해 Map 구조를 사용하면 얻을 수 있는 성능적인 이점이 있다. 일반적으로 값을 추가하는 것은 Map이 더 빠르다고 생각하면 된다. 아래에서 10만개의 데이터를 추가하는 테스트를 해봤을 때 생각보다 유의미한 차이가 있었다. > **데이터 삽입 테스트** ```js const iterations = 100000; // Object 삽입 테스트 const obj = {}; console.time("Object insert"); for (let i = 0; i < iterations; i++) { obj[`key${i}`] = i; } console.timeEnd("Object insert"); // Map 삽입 테스트 const map = new Map(); console.time("Map insert"); for (let i = 0; i < iterations; i++) { map.set(`key${i}`, i); } console.timeEnd("Map insert"); console.log(`Object size: ${Object.keys(obj).length}`); console.log(`Map size: ${map.size}`); ``` ``` // 데이터가 100개일 경우 Object insert: 0.305ms Map insert: 0.021ms Object size: 100 Map size: 100 ``` ``` // 데이터가 10만 개일 경우 Object insert: 64.969ms Map insert: 15.67ms Object size: 100000 Map size: 100000 ``` > **이번에는 삭제 테스트를 해보자.** 아래는 Object에서 delete 키워드를 사용하는 것과 Map의 delete 내장 메서드를 사용하는 것의 속도 비교이다. 브라우저 콘솔을 켜서 코드를 복붙해서 테스트해 볼 수 있다. ```js const iterations = 100000; // Object 삭제 테스트 const obj = {}; for (let i = 0; i < iterations; i++) { obj[`key${i}`] = i; } console.time('Object delete'); for (let i = 0; i < iterations; i++) { delete obj[`key${i}`]; } console.timeEnd('Object delete'); // Map 삭제 테스트 const map = new Map(); for (let i = 0; i < iterations; i++) { map.set(`key${i}`, i); } console.time('Map delete'); for (let i = 0; i < iterations; i++) { map.delete(`key${i}`); } console.timeEnd('Map delete'); console.log(`Object size: ${Object.keys(obj).length}`); console.log(`Map size: ${map.size}`); ``` ``` Object delete: 30.201ms Map delete: 24.388ms Object size: 0 Map size: 0 ``` 추가도 Map이 더 빨랐지만, 삭제는 차이가 큰 걸 알 수 있었다. #### 왜 더 빠를까? 삭제나 추가에서 Map이 더 빠른 이유는 Object 구조만의 독특한 설계 때문이다. 이는 JavaScript의 V8엔진과 연관되어 있다. V8엔진은 내부적으로 히든 클래스를 만들어서 저장한다. ```js const obj = { a: 1, b: 2, c: 3 }; // V8 엔진이 내부적으로 이런 "shape"을 만듦 // HiddenClass1: { a: offset 0, b: offset 1, c: offset 2 } ``` 히든 클래스를 사용해서 객체의 전체 데이터가 아닌 **DB의 인덱스 느낌**으로 전체적인 모양을 저장한다. 이런 식으로 데이터 추가가 되거나 삭제가 되면 다시 히든클래스를 생성하는 오버헤드가 존재하기 때문에 삽입, 삭제 연산에서 성능차이가 발생하는 것이다. Map 구조는 단순히 해쉬맵 자료구조의 역할을 위해서 존재한다. 따라서 별도의 히든클래스를 만들어서 저장하지 않고 삭제시 단순히 연결을 끊어버리는 동작을 하기 때문에 더 빠르다. ## Map의 내장 메서드 최근에 기업 코딩테스트를 보는데, MDN 레퍼런스가 제공되지 않는 환경에서 시험을 치뤘다. 해시맵 자료구조를 사용해야 하는데 Object 대신 Map 자료구조를 선택했다. get, set 정도는 익숙해서 기억을 했지만, 전체 Map을 배열로 변환하는 방법이 기억이 나지 않아 메서드 찾기로 삽질을 오래했던 기억이 난다. 그래서 글을 작성하는 겸 메서드들을 숙지해보려고 한다. 물론 다 외울 필요는 없겠지만 핵심적인 메서드는 알아두는게 좋을 것 같아서. | 메서드 | 설명 | 반환값 | 예시 | |--------|------|--------|------| | `set(key, value)` | 키-값 쌍 추가/수정 | Map 객체 (체이닝 가능) | `map.set('name', '정우')` | | `get(key)` | 키로 값 조회 | 값 또는 undefined | `map.get('name')` → `'정우'` | | `has(key)` | 키 존재 여부 확인 | boolean | `map.has('name')` → `true` | | `delete(key)` | 키-값 쌍 삭제 | boolean (삭제 성공 여부) | `map.delete('name')` → `true` | | `clear()` | 모든 항목 삭제 | undefined | `map.clear()` | | `keys()` | 모든 키를 가진 이터레이터 | Iterator | `[...map.keys()]` → `['a', 'b']` | | `values()` | 모든 값을 가진 이터레이터 | Iterator | `[...map.values()]` → `[1, 2]` | | `entries()` | 모든 [키, 값] 쌍 이터레이터 | Iterator | `[...map.entries()]` → `[['a',1], ['b',2]]` | | `forEach(callback)` | 각 항목마다 콜백 실행 | undefined | `map.forEach((v, k) => {})` | 이렇게 보면 어렵지 않은데 시험에서는 Object.entries(map) , Object.keys(map) 별걸 다 시도해봤었다.. ㅋㅋ 이렇게 시도한 이유는 일반적인 Object를 배열로 바꿀 때는 이런 식으로 사용했었기 때문에 당연히 지원이 될 줄 알았다. ```js const map = new Map(); const obj = { A: 3, B: 2, C: 1, }; map.set("A", 3); map.set("B", 2); map.set("C", 1); console.log(map); console.log(Object.entries(map)); console.log(Object.entries(obj)); /** Map(3) { 'A' => 3, 'B' => 2, 'C' => 1 } -> Object.entries(map)은 빈배열 반환 [] [ [ 'A', 3 ], [ 'B', 2 ], [ 'C', 1 ] ] */ ``` 결국에는 메서드를 여러개 시도해보다가 되는 걸 찾아서 시험을 잘 마쳤지만.. 시험을 보고 다음 날 인턴 동료에게 들었던 충격적인 사실은 스프레드 연산자를 활용한 `...map`으로 배열(`[ 'A', 3 ] [ 'B', 2 ] [ 'C', 1 ]`)로 변환된다는 사실이었다. 💀💀 > `console.log(Object.entries(Object.fromEntries(map)));` 이런 방법도 있다. JS는 레퍼런스를 줘야한다고 생각.. ## 그렇다면 무조건 Map이 더 좋은가? 성능을 보면 무조건 Map을 써야할 것처럼 보인다. 하지만 실제로 서비스를 만들거나 프로젝트를 하는 경우에서 Map을 잘 쓰지 않는다는 것을 알 수 있다. Object는 **JSON 직렬화**를 쉽게 할 수 있고, **구현이 간단**하다는 점, **구조 분해 할당**이라는 강력한 문법 지원 등으로 인해 실질적으로는 Map 보다 더 많이 사용된다. ```js // Object - 편리함 const { name, age, email } = user; // Map - 불가능 const name = userMap.get('name'); const age = userMap.get('age'); const email = userMap.get('email'); ``` > **그럼 언제 써요?** Map 구조는 빈번한 데이터 추가와 삭제가 일어날 때 사용한다. 혹은 키 값으로 string이 아닌 다른 타입을 사용할 때 사용한다. Object 구조는 API 응답 데이터, React의 Props나 State, 구조 분해 할당이 필요할 때 사용할 수 있다. ## 결론 생각보다 Map의 장점이 명확히지만, Object의 장점이 더 큰 것 같다. 많은 데이터가 들어가서 성능을 고려해서 Map을 쓰기에는 Object가 너무 편리하다는 점이 크다. 그럼에도 Map이 좋은 점은 조금 더 명시적이라는 점인 것 같다. get과 has를 사용해서 휴먼에러를 방지한다는 점이 장점이라고 생각한다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[FastAPI 동기/비동기 블로킹 이슈 해결하기]]> https://shipfriend.dev/posts/fastapi-동기-비동기-블로킹-이슈-해결하기 https://shipfriend.dev/posts/fastapi-동기-비동기-블로킹-이슈-해결하기 Sat, 07 Feb 2026 07:16:28 GMT **요즘에는 AI 보조 도구가 너무 잘 되어있어서 가끔은 내가 만들고 있는 프로덕트에 대한 이해가 낮아질 수 있겠다는 생각이 들었다.** > > **이런 문제 해결도 결국에는 비동기와 동기, 이벤트루프와 블로킹, 트랜잭션 등의 개념을 알아야하는거구나 하는 생각도 했다. AI가 발전해도 살아남으려면 기본 개념 파악이 우선시 되어야 하는 것 같다.**]]> sjw4371@naver.com (개발자 서정우) <![CDATA[장시간 AI 처리 작업의 실시간 진행률 구현 (SSE)]]> https://shipfriend.dev/posts/장시간-ai-처리-작업의-실시간-진행률-구현-sse https://shipfriend.dev/posts/장시간-ai-처리-작업의-실시간-진행률-구현-sse Fri, 06 Feb 2026 15:25:59 GMT 클라이언트)으로 유저의 최초 연결 후 서버에서 지속적인 데이터 스트림을 받아옴 ![이미지](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1770442883923-Gemini_Generated_Image_bwi41ubwi41ubwi4_clean-hMHDmx240I8RpnUZrdW6O16jN7iDaa.webp) | 구분 | 폴링 (Polling) | SSE (Server-Sent Events) | |------|---------------|--------------------------| | **통신 방향** | 양방향 (클라이언트 → 서버) | 단방향 (서버 → 클라이언트) | | **연결 방식** | 매번 새로운 HTTP 요청 | 단일 HTTP 연결 유지 | | **요청 주체** | 클라이언트가 주기적으로 요청 | 서버가 변경사항 발생 시 푸시 | | **네트워크 오버헤드** | 높음 (매 요청마다 헤더 전송) | 낮음 (초기 연결 후 데이터만 전송) | | **실시간성** | 폴링 간격만큼 지연 | 즉시 전송 (지연 거의 없음) | | **서버 부하** | 높음 (불필요한 요청 다수) | 낮음 (변경 시에만 전송) | | **재연결** | 매번 연결/해제 | 자동 재연결 지원 | | **브라우저 지원** | 모든 브라우저 | IE 제외 모든 모던 브라우저 | | **구현 복잡도** | 낮음 | 중간 | | **적합한 상황** | 간단한 상태 확인 | 실시간 업데이트, 긴 작업 진행률 | ### 예시: 3분 작업, 1초 간격 폴링 기준 | 항목 | 폴링 | SSE | |------|------|-----| | HTTP 요청 수 | 180회 | 1회 (초기 연결) | | 전송 데이터 | ~90KB (헤더 포함) | ~5KB (데이터만) | | 업데이트 지연 | 최대 1초 | 즉시 (<50ms) | ## 왜 SSE인가? 실시간 처리 진행 상황을 보여주는 용도로 폴링 대신 SSE를 사용한 이유는 실시간 업데이트에 더 적합하다고 생각했기 때문이다. 폴링은 클라이언트에서 요청을 해야 응답을 받을 수 있고, 폴링 주기를 짧게 하면 할 수록 성능 부하가 불필요하게 많아지고, 서버에서 처리하고 있는 진행률 자체는 간단한 상태이기 때문에 폴링보다는 SSE가 적합하다고 생각했다. SSE의 강점으로 생각했던 것은 실제로 데이터의 변경사항이 있을 때만 서버가 선택적으로 데이터를 내려줄 수 있다는 점이었다. 그리고 한번의 연결 후 데이터 스트림을 내려주는 방식이어서 폴링에 비해서 오버헤드가 적다는 장점으로 선택하게 되었다. ## SSE 구현 SSE 구현을 위해서는 클라이언트와 백엔드 모두에서 작업이 필요하다. ```tsx import { useEffect, useState } from 'react'; interface ProgressData { progress: number; message: string; status: 'pending' | 'in_progress' | 'completed' | 'failed'; } export const useTaskProgress = (taskId: string | null) => { const [progress, setProgress] = useState({ progress: 0, message: '', status: 'pending' }); const [error, setError] = useState(null); useEffect(() => { if (!taskId) return; const eventSource = new EventSource( `${import.meta.env.VITE_API_URL}/api/tasks/${taskId}/progress` ); eventSource.onmessage = (event) => { try { const data = JSON.parse(event.data); setProgress(data); } catch (err) { console.error('Failed to parse SSE data:', err); } }; eventSource.onerror = (err) => { console.error('SSE error:', err); setError('연결이 끊어졌습니다'); eventSource.close(); }; // Cleanup return () => { eventSource.close(); }; }, [taskId]); return { progress, error }; }; ``` ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[StoryHelper v1.6.2 패치노트]]> https://shipfriend.dev/posts/storyhelper-v1-6-2-패치노트 https://shipfriend.dev/posts/storyhelper-v1-6-2-패치노트 Sat, 03 Jan 2026 14:03:43 GMT sjw4371@naver.com (개발자 서정우) <![CDATA[StoryHelper에 리뷰 요청하기와 삭제시 피드백 수집 기능 만들기]]> https://shipfriend.dev/posts/storyhelper에-리뷰-요청하기와-삭제시-피드백-수집-기능-만들기 https://shipfriend.dev/posts/storyhelper에-리뷰-요청하기와-삭제시-피드백-수집-기능-만들기 Mon, 29 Dec 2025 07:40:12 GMT 💬: ~~링크(확장프로그램 웹스토어, 개인블로그에 작성된 가이드문서) 등을 읽고 이 확장프로그램에 대한 랜딩페이지 기획 문서를 루트 디렉토리에 생성 > 💬: 이 로고를 기반으로 디자인 시스템 문서 생성 -> Sage Green 기반으로 잘 만들어줌 ### 피드백 받는 화면 피드백을 받는 폼도 다른 route에 만들어두었다. 여기서 피드백을 수집할 수 있게 구현했다. ![피드백 폼](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1766992166003-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-12-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.13.15-N9jJHFrxGdugwUQLDd6eg8G0OOnpvC.webp) ## 피드백 데이터 저장하는 곳 결정하기 ![피드백 수집 완료](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1766992166705-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-12-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.13.21-a456XYpLGvCScyJVWWSaF67lmTGTK2.webp) 피드백 데이터를 수집까지는 완성했다. 그렇다면 수집된 데이터를 쌓는 곳을 결정해야한다. 데이터를 저장하는 방법에는 여러가지가 있다. DB, 구글시트, 파일 등등 많은 소스들이 있지만 이 중에 결정한 것은 Notion 이었다. ### Notion에 데이터를 어떻게 쌓아? Notion의 개발자 센터 페이지에 들어가면 API 키를 발급 받을 수 있다. 다행히 무료였다.. 🙈 ![노션 API Integration](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1766992402934-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-12-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%204.13.13-E0fxW4K7oRuK7ATql7N4YZ368RTikE.webp) 여기서 잘 설정해주면 노션의 특정 워크스페이스의 특정 페이지의 특정 데이터베이스에 데이터를 쌓거나 편집하거나 읽기가 가능하다!! notion에서 제공하는 sdk를 사용하면 쉽게 사용이 가능하다. [공식문서](https://developers.notion.com/docs/getting-started)에서 확인 가능하다. 이렇게 수집된 피드백 데이터는 노션 데이터베이스에 저장하도록 했다. 유저 수가 천 단위가 아니기 때문에 DB를 쓰는 건 오버엔지니어링이었기 때문에 이렇게 결정했는데 실시간으로 데이터가 쌓이는게 보이니까 재미있다. ![데이터베이스에 쌓이는 피드백들](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1766992167227-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-12-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.13.33-0sx8XwtpxENmnMIXHiVvAW2B38b0TY.webp) ## 마지막으로 요즘 블로그 생태계가 AI로 도배 되어가는 분위기라 이런 생산성 확장프로그램에 관심을 갖는 사용자가 있을지는 모르겠으나 도움이 되면 좋겠다. 본인은 아주 유용하게 썼기 때문에..]]> sjw4371@naver.com (개발자 서정우) <![CDATA[zod로 유효성 검사를 선언적으로 관리하기]]> https://shipfriend.dev/posts/zod로-유효성-검사를-선언적으로-관리하기 https://shipfriend.dev/posts/zod로-유효성-검사를-선언적으로-관리하기 Sat, 27 Dec 2025 10:04:53 GMT data.password === data.confirmPassword, { message: "비밀번호가 일치하지 않습니다", path: ["confirmPassword"], }); ``` 위 코드는 schema를 정의하는 코드이다. 각 필드명에 대해서 z.email(), z.string() 등 zod 메서드를 사용해서 타입이나 제약조건을 선언적으로 지정할 수 있다. 그리고 또 z.email().min() 형식으로 메서드 체이닝을 활용하면 제약조건을 추가하는 것도 가능하다. zod에는 다양한 메서드가 있는데 자주 쓰이는 건 길이 검증하는 mim, max 그리고 email() 함수로 쉽게 이메일 형식 검증이 가능하다. zod의 장점은 선언적이기 때문에 필드의 제약조건을 파악하기 쉽다. ![선언적 비교](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1766829794231-Gemini_Generated_Image_r63pc1r63pc1r63p_clean-iCI71Osq8hPkzx0bJtuSMMSZhXwB8g.webp) 원래라면 이메일 형식을 검증하기 위해 `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$` 이런 복잡한 정규표현식을 사용하거나 했다. 하지만 이럴 경우 주석처리를 하거나 함수이름을 명확하게 정의하지 않으면 이메일을 검증하는 것인지 바로 인지하기 쉽지 않다고 생각한다. zod에서는 이런 정규표현식을 추상화한 메서드로 형식을 검증할 수 있다. 그리고 zod에 없는 형식을 검증하거나 각 필드 간의 관계를 검증하기 위해서는 .refine 함수를 사용하면 보다 복잡한 유효성 검사를 적용할 수 있다. [다양한 메서드 zod](https://zod.dev/api) ## zod 사용 예시 zod는 아래처럼 사용할 수 있다. ```tsx // 1. 스키마 정의 const userSchema = z.object({ nickname: z.string() .trim() .min(2, "닉네임은 최소 2자 이상이어야 합니다") .max(10, "닉네임은 최대 10자까지 가능합니다"), email: z.string().email("올바른 이메일 형식이 아닙니다"), }); // 2. TypeScript 타입 자동 추론 type UserFormData = z.infer; // 3. React 컴포넌트에서 사용 const UserRegistrationForm = () => { const [formData, setFormData] = useState>({}); const [errors, setErrors] = useState>({}); const handleSubmit = (e: React.FormEvent) => { e.preventDefault(); const result = userSchema.safeParse(formData); if (!result.success) { const formattedErrors: Record = {}; result.error.errors.forEach((err) => { formattedErrors[err.path[0]] = err.message; }); setErrors(formattedErrors); return; } console.log('검증된 데이터:', result.data); // API 호출 등... }; return (

setFormData(prev => ({ ...prev, nickname: e.target.value }))} placeholder="닉네임" /> {errors.nickname && {errors.nickname}}
setFormData(prev => ({ ...prev, email: e.target.value }))} placeholder="이메일" /> {errors.email && {errors.email}}
); } ``` ## zod로 모든 유효성검사를 할 수 있을까? zod로 모든 유효성 검사를 대체할 수 있을까? zod는 많이 사용되는 유효성검사들을 쉽게 재사용할 수 있다는 강점이 있지만 모든 유효성검사를 대체하기에는 한계가 있다. zod가 적합한 경우는 - type을 검증하거나 - 입력 값의 형식, 길이, 패턴 등을 검증하거나 - 필드 간 관계를 검증할 때 zod로 하지 않는게 좋은 것 - 복잡한 비즈니스 로직에 연관된 유효성검사 - 서버에서 검증해야 하는 것 (중복 이메일 검사 등) ## form 코드로 알아보는 로직 분리에 대한 나의 생각 Form 코드를 어떻게 분리하는게 효율적일까? Form 코드는 작성하다보면 매우 쉽게 길어지는 것 같다. Form에 들어가는 여러가지 input 필드들, 복잡한 유효성 검사들, API 요청 코드, 타입 정의 등 많은 부분이 들어가기 때문이다. 일단 나는 Form의 필드 부분은 컴포넌트, 유효성 검사나 submit 핸들러 등 로직 부분을 커스텀 훅으로 분리하는 것을 기본으로 두고 했었던 것 같다. zod를 쓰게 된다면 위 부분에서 필드 유효성 검사와 타입 정의를 zod schema 레벨로 분리를 할 수 있어서 가독성이 더 좋아지는 것 같다. ## 결론 ### Zod는 선언적 유효성 검사의 강력한 도구 TypeScript와의 완벽한 통합으로 타입 안정성 확보 메서드 체이닝으로 복잡한 제약조건도 읽기 쉽게 표현 ### 모든 검증을 Zod로 해결하려 하지 말 것 비동기 검증, 복잡한 비즈니스 로직은 적절한 곳에서 처리 각 검증의 성격에 맞는 방법 선택이 중요 ### 관심사의 분리는 Form에서도 중요 스키마 검증 / 비즈니스 로직 / 서버 검증을 명확히 구분 유지보수 가능하고 테스트하기 쉬운 코드 작성 ## 참고자료 - [zod Docs](https://zod.dev/)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[레거시와 모던의 차이점과 현대화에 필요한 것]]> https://shipfriend.dev/posts/레거시와-모던의-차이점과-현대화에-필요한-것 https://shipfriend.dev/posts/레거시와-모던의-차이점과-현대화에-필요한-것 Sun, 23 Nov 2025 08:22:49 GMT 이렇게 적고 보니 구조화 없는 코드가 분리 부족을 유발하고, 이는 곧 확장성 저하와 유지보수 어려움을 만드는 것 같다..? 물론 너무 많은 분리는 오히려 독이라고 생각하는 편이기는 하다. ![레거시와 모던의 차이점](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1763886061383-Gemini_Generated_Image_cjdzhicjdzhicjdz%20%281%29-NuKDPfOAiXf2XuRnUjJueGRknnS74h.png) ## 현대 프로젝트의 특징 현대에서는 이런 레거시들의 특징이자 문제점을 많이 개선한 모습으로 보인다. - 구조화되어있는 코드 - 프레임워크 단위로 구조화되기도 하는 - 책임 분리가 컨셉으로 잡혀있는 - 이전 프로젝트들보다 최근 웹 프로젝트들에서는 책임 분리를 쉽게 들어볼 수 있게 된 것 같다. 그만큼 책임분리하는 원칙이 표준이 되었다는 의미같다. - 서버와의 결합 약화 - 이전에 JSP나 템플릿 언어를 활용하여 서버에서 모든 것을 처리하고 내려주던 프로젝트가 아니라 서버의 책임을 어느정도 클라이언트에 분리하여 제공하는 것과 필요한 데이터를 API 형태로 요청하고 응답하는 방식으로 해결했다. - 개발 문화와 방법의 발전 - 애자일한 개발 방법론, 쉽게 말하면 자주 보고 자주 고치는 방법론의 도입으로 잠재적인 문제를 좀 더 빠르게 발견하고, 빠르게 해결 할 수 있는 구조가 도입되었다. - CI/CD 등의 도입으로 개발 → 배포 → 테스트 과정의 주기가 짧아져 더 적은 시간 내에 많은 문제를 해결 할 수 있게 되었다. 이렇게 많은 문제가 해결되었지만 이게 정답이라고 생각하는 것은 위험하다고 생각하다. 나는 언젠가 리액트도 레거시가 되는 날이 올 수도 있다고 생각하기 때문이다. ## 레거시에서 현대 프로젝트로의 마이그레이션하려면.. 레거시에서 현대 프로젝트로의 마이그레이션은 정말 어려운 결정이라고 생각이 들었다. 짧고 작은 부분만 보면 현대화하는 것이 어렵지 않다고 느낄 수 있다. 하지만 거대한 프로젝트이고, 이 변경이 다른 곳에도 영향을 크게 미칠 수 있다고 생각하면 버겁게 느껴지기도 한다. - 전략적인 준비와 작은 것부터 천천히 - 점진적이고 안전한 접근 쓰다보면서 생각하니 더 어렵게 느껴진다. 백엔드에서 API 명세를 바꾸면 이 API를 활용하는 프론트엔드에서도 모두 변경을 해줘야한다. 혹은 데이터베이스에선 내려주는 필드명이 변경되거나 타입이 변경된다면? 백엔드, 프론트엔드 모두 영향이 갈 수도 있다. 처음에는 레거시는 그대로 두고, 새로운 프로젝트를 완전히 개발해서 레거시를 100% 대치해서 사용하면 안되나? 이런 생각을 했었다. ![빅뱅과 점진적 마이그레이션](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1763886064322-Gemini_Generated_Image_cjdzhicjdzhicjdz-6dPmNXZKi8RtbS9xpJ5zQPmzYOH24A.png) 여러 정보를 알아보고 직접 과정을 지켜보면서 느낀 점은 말이 안된다는 것이었다. 새로운 프로젝트로 완전히 대치하면 생길 수 있는 많은 문제점에 대해서 알게 되었기 때문이다. 점진적으로 개선하는 경우에는 `ABCD` 앱이 있을 때 `A`에서 발생할 수 있는 문제에 대해서만 조사하고, 대비하고, 문제가 생겼을 때 사용할 수 있는 리소스를 적게 가져갈 수 있다. 하지만, `ABCD`를 한번에 만들어서 대치하는 경우에는? 예상치 못한 문제들이 동시다발적으로 터질 수 있다. 그렇게 되면 모든 리소스가 발생한 문제를 해결하는데 투입이 되어야하고, 서로 영향을 주는 사이드 이펙트가 많이 생길 수 있기 때문에 큰 문제가 된다. (**BigBang** 방식이라고 부르는 것 같다) ## 중요한 것 글을 쓰면서 느낀 점은 단순히 코드레벨에서만 성장을 위해 노력하는 것뿐 아니라 이런 더 큰 관점에서도 계속 생각해봐야겠다고 느꼈다. 레거시를 유발하는 것이 단순히 JSP, JQuery 같은 언어의 문제가 아니라는 점을 다시 한번 생각했고, 개발방법에 대한 고찰과 구조의 설계에 대해서 항상 생각해야겠다고 느꼈다!]]> sjw4371@naver.com (개발자 서정우) <![CDATA[2025년 회고 글을 작성해요]]> https://shipfriend.dev/posts/2025년-회고-글을-작성해요 https://shipfriend.dev/posts/2025년-회고-글을-작성해요 Mon, 10 Nov 2025 02:00:03 GMT 현재 작성 중.. # 2025년 회고를 써보자 ## 4학년 1학기 ## 4학년 2학기 ## 인턴 : 올리브영 ## 스터디 활동 ## 취준하면서 ## 내년 계획 ## 결론 ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[Vanilla Extract에 대해서 알아봅시다]]> https://shipfriend.dev/posts/vanilla-extract에-대해서-알아봅시다 https://shipfriend.dev/posts/vanilla-extract에-대해서-알아봅시다 Wed, 29 Oct 2025 07:43:23 GMT ``` 정말 쉽게 사용할 수 있다. ## 상태를 활용하는 방법 (조건부 스타일) 개인적으로 이게 vanilla extract의 장점이라고 느꼈다. 웹 개발을 하다보면 어떤 상태가 있을 때 해당 상태의 값에 따라 다른 스타일을 렌더링해야 할 때가 많다. 그럴 때 Vanilla extract에서 지원하는 recipe 함수를 사용해보자. ```tsx // 공통 스타일은 base 아래에 작성, 분기하고 싶은 상태를 variants 아래에 작성한다. const box = recipe({ base: { borderRadius: "8px", padding: "16px", fontSize: "24px", backgroundColor: "darkgray", }, variants: { color: { red: { color: "red", }, blue: { color: "blue", }, }, }, }), // 사용은 이렇게
배고프다.
와우
``` 이런 식으로 사용이 가능하다.
![recipe 대박](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1761721815810-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-10-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%204.10.09-eROo6XqE3PC8HbM8dYL4Ic4oxmM2qs.png)
### recipe의 활용, compoundVariants 레시피는 상태를 스타일에 반영할 수 있다는 특징이 있다. recipe에는 단일 상태 뿐아니라 조합 상태에도 스타일링을 할 수 있다. compoundVariants를 사용하면 아래처럼 적용이 가능하다. ```ts 상태가 A 일 때 --> BackgroundColor: white; 상태가 B 일 때 --> BackgroundColor: black; 상태가 A와 B가 둘 다 일 때 --> BackgroundColor: green; ``` ## 재미없는 사용법 외의 장점에 대해서 알아보자 사용하는 것이 매우 쉽고, recipe가 base 덕분에 깔끔하게 스타일을 작성할 수 있는 것 같다. 사용법을 알아봤으니 재미없는 부분에 대해서도 알아보자 ### 개발이 편리하다 💀 일단 작성 자체가 어렵지 않고, recipe를 통한 공통 스타일 분리 등으로 인해서 **개발하기 편리**하다는 장점이 있다. 그리고 기본적으로 `파일이름.css.ts` 형식으로 스타일 파일을 분리하는데, 그만큼 TypeScript 친화적이라는 장점도 있다. ### 제로 런타임 오버헤드다 💀 그리고 **빌드 타임에 변환된다는 장점**이 있다. 변환 방식이 크게 두 가지가 있는데 하나는 런타임에 변환되는 것이고, 다른 하나는 빌드 타임에 생성된다는 점이다. 런타임에 생성되는 경우 성능상의 오버헤드가 존재할 수 있다. CSS를 처리하는데 평소보다 노력이 들어간다는 의미이기 때문이다. 하지만 빌드 타임에 하는 경우 물론 빌드 타임이 늘어나기는 하겠지만, 실제 실행할 때 성능상의 오버헤드는 존재하지 않는다. 일반 .css 파일처럼 변환되어 처리되기 때문이다. 성능에 있어서 다른 라이브러리 대비 우위를 가져갈 수 있음이 특징이다. ![Vanilla Extract로 만든 네온사인](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1762672820866-%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202025-11-09%20160444-9TtQzIOWvEN36rkuAZNKPJANf8DShL.png) ## 내 생각 일단 `TailwindCSS`를 엄청 좋아하는 편이었기 때문에 적응하는데 시간이 조금 필요했다. 물론 Tailwind를 접하기 전에도 CSS Module이나 RN 스타일링 등을 경험했었기 때문에 어렵지는 않았다. Vanilla Extract가 재미있었지만 TailwindCSS의 빠른 개발 경험은 못따라간다고 생각했다. Tailwind에 익숙해지면 간단한 스타일링과 레이아웃은 굉장히 빠르게 구현을 할 수 있는데, Vanilla Extract는 .css.ts 파일을 만들고 export 한 후 className에 넣어주는 과정이 포함되기 때문에 아쉬웠다. 하지만 스타일링과 코드의 명확한 분리가 쉽고, Tailwind의 단점으로 지적되는 횡으로 길어지는 코드에 대해 걱정을 하지 않아도 된다는 것이 특징이다. ### 나만의 결론 TailwindCSS는 아직 좋다고 생각한다. 하지만 `Vanilla Extract`는 어느정도 규모가 있는 프로젝트에서 스타일링에 소요되는 코스트까지 줄이고 싶거나, `테마&팔레트`를 명확하게 정의하고 스타일과 코드를 완벽하게 분리하고 싶다면 선택할 수 있는 좋은 대안이라고 생각이 들었다. ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[Module Federation에 대해서]]> https://shipfriend.dev/posts/module-federation에-대해서 https://shipfriend.dev/posts/module-federation에-대해서 Sun, 19 Oct 2025 06:57:25 GMT ❓ **Federation** 한글로 연맹, 연합이라는 뜻을 가짐 ## 왜 사용하는가? 개념을 알아보면서 느낀 점은 이 기술은 **마이크로 프론트엔드**와 매우 밀접한 연관을 갖고 있다는 것이었다. Module Federation을 사용하는 가장 큰 이유는 대규모의 프로젝트를 소규모의 독립적인 프로젝트로 분리하는데에 있다고 느꼈다. 그렇기 때문에 일반적으로 혼자서 할 수 있는 혹은 2~4인의 소규모 팀에서는 경험해보기 힘든 분야라고 생각이 들었다. 따라서 큰 규모의 프로젝트를 한다고 상상했을 때 이 기술을 왜 쓰는지 이해할 수 있었다. ### 1. 독립적인 스쿼드 운영 혼자서 개발할 때나 팀프로젝트를 한다면 각자 하나씩 기능을 맡아서 구현해도 전혀 문제될게 없고, 기능 간 서로 연관이 깊기 때문에 머지 충돌이 생겨도 금방 해결할 수 있다. 하지만 대규모 프로젝트거나 기업에서의 애플리케이션은 매우 크기 때문에 머지 충돌이 생길 경우 해결에 시간이 더 오래걸리고, 이해 관계가 얽혀있는 경우가 많다. 이럴 때 하나의 레포지토리에서 100명이 넘는 개발자가 개발을 하는 경우에는 효율이 나오지 않을 수 있다. 빌드와 배포에서도 하나의 팀이 중요한 버그 수정사항을 커밋하면 전체 앱을 재빌드 해야하기 때문이다. 하지만 Module Federation과 Micro Frontend Architecture를 사용하면 하나의 앱의 여러 부분을 독립적으로 운영할 수 있게 된다. 나의 블로그로 예시를 든다면, A 팀은 메인페이지를 담당하고, B 팀은 블로그 글 리스트를 담당하는 식이다. ### 2. 점진적 마이그레이션 가장 큰 이유는 위의 독립적인 스쿼드 운영과 마이크로프론트엔드 아키텍쳐이지만, 이 점진적 마이그레이션은 부가적으로 따라오는 장점이라고 생각했다. 마이크로 프론트엔드로 구성하기 시작하면 대규모 업데이트나 대규모 마이그레이션 작업을 점진적으로 하기 좋다. ```tsx const App = () => { return ( <> {/* jQuery */} {/* React - 새로 작성 */} {/* jQuery */} ); }; ``` 각자가 독립적인 앱이기 때문에 마이그레이션 과정 중 생기는 버그도 전체 앱에 영향을 미치지 않고 독립적으로 해결 할 수 있다. ## 핵심 개념 ### Host 호스트는 메인 앱을 지칭, 주로 Remote 패키지들을 로드하는 주체가 되는 애플리케이션 ### Remote 독립적인 마이크로 앱, 다른 앱에서 사용할 수 있도록 엔트리포인트를 만들어 노출시킬 필요가 있음. ## 사용 예시 ```jsx // Host 앱에서 Remote 컴포넌트 사용 import React, { lazy, Suspense } from 'react'; // Remote 앱의 컴포넌트를 동적으로 import const ProductList = lazy(() => import('productApp/ProductList')); const UserProfile = lazy(() => import('userApp/UserProfile')); function App() { return (

메인 애플리케이션

제품 목록 로딩중...
}> 사용자 프로필 로딩중...}> ); } ``` ## 장단점 ### 장점 - 마이크로 프론트엔드 아키텍쳐를 구현하기 위해 사용하는 방법 중 하나로 사용될 수 있음 - 점진적 마이그레이션이 가능하다. - 기존 레거시를 현대화된 프로젝트로 개선하기 위해서는 여러가지 방법이 있다. 하나는 현대화된 프로젝트를 만들고 한번에 레거시를 대체하는 방법, 다른 하나는 Module Federation을 사용해서 점진적으로 일부 앱을 하나하나 현대화하는 방식 - 하나의 공유 컴포넌트 라이브러리로 사용가능 - 여러가지 마이크로 앱에서 사용되는 컴포넌트의 경우 중복을 최소화하기 위해서 common 앱으로 분리해서 동적으로 로드하여 사용. ### 단점 단점들은 어쩔 수 없이 따라오는 부분들이 많은 것 같다. 특히, 대규모 서비스를 운영하게 되면 필연적으로 생길 수 밖에 없는 문제들이 단점이 될 것 같다. #### 내가 생각한 단점 - 어렵다, 러닝커브가 높다고 생각됨 - 마이크로 프론트엔드의 어려움과 결이 같다고 생각함 - host에서 어떻게 remote app들을 사용할지 정의하는 것이 중요할 것 같음 - 각자 remote app을 개발하는 것은 어렵지 않을 것 같지만, 그걸 하나로 합치고, 공통에서 사용해야하는 api를 만드는 것과 각 앱 간의 통신에서 어려움을 느낄 것 같다. #### 실제 단점 **개발 환경의 복잡성** 각 리모트앱과 호스트앱을 모두 실행 필요 **Host-Remote 통합 설계의 중요성** Host에서 Remote 앱들을 어떻게 사용할지 정의하는 것이 매우 중요하다. 잘못 설계하면 독립성의 장점을 잃고 강한 결합이 생길 수 있다. **앱 간 통신과 공통 API 설계** 각 Remote 앱을 개발하는 것은 어렵지 않을 것 같지만, 이를 하나로 합치고, 공통에서 사용해야 하는 API를 만드는 것과 각 앱 간의 통신에서 어려움을 느낄 것 같다. ## 궁금한 점 ### 앱 간의 통신은 어떻게 하는가? 앱 간 통신이 필요한 상황이 있다고 가정해보자. 예를 들어 장바구니 리모트앱, 결제 리모트앱이 나누어져있다고 한다면, 장바구니에서 결제를 클릭했을 때 장바구니에 담긴 상품 데이터를 어떻게 결제 페이지로 보낼 수 있을까? 여러 방법들 있지만, 유용하게 사용할 수 있을 것 같은 방법으로는 네 가지를 뽑아 볼 수 있을 것 같다. - 전역상태 라이브러리 or ContextAPI - URL 쿼리파라미터로 데이터 전달 - 백엔드 동기화 - 이벤트 버스 모든 remote 앱들을 호출하는 주체인 host 앱에서 전역 상태 Provider를 제공하면 그 아래에서 생성되는 리모트 앱들에서도 **전역 상태를 공유**할 수 있다. 이걸 통해 통신하는 방법이 있다. 이벤트 버스는 중앙에서 메시지를 전달해주는 시스템으로, A 앱에서 **특정 이벤트를 emit하면 그 이벤트를 구독하는 B 앱에서 이벤트에 대한 처리를 진행하는 방식**이다. Event Emitter를 생각하면 쉬울 것 같다. 이런 방식으로 remote 앱 간에 메시징이 가능하다. ![이벤트 버스](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1762015747576-unnamed%20%281%29-JE6SBsWoLdZ27rJenTWGf9DK1lYa0R.jpg) ### 웹뷰와의 차이점 런타임에 모듈로 통합되는 것과 웹 뷰의 차이점은 무엇일까? 먼저 웹 뷰는 완전히 독립된 컨텍스트와 메모리를 갖는다는 점이 차이점이다. 하지만 Module Federation은 런타임에 **통합**된다는 것이 결정적인 차이점이다. 개발은 독립적으로 하지만 실제 실행은 하나의 앱과 같이(메모리 공유 등) 동작한다고 볼 수 있다. ## 결론 Module Federation은 마이크로 프론트엔드를 구성하기 위해서도 사용하고, 가독성과 개발 효율성을 위해서 사용하기도 한다. 핵심은 특정 모듈을 런타임에 불러와서 사용하기 위함이다. 마이크로 프론트엔드에서 각 마이크로앱을 구현하고 Module Federation을 사용해서 host 앱에서 합치는 방식을 사용한다. Module Federation이라는 용어에 꽂혀서 글을 작성해봤는데, 작성하면 할 수록 내용이 너무 방대해져서 조금 두서없이 작성한 것 같다. Module Federation은 개념느낌이고, 이걸 설명하려면 Micro Frontend 구조를 설명해야하기 때문에..]]> sjw4371@naver.com (개발자 서정우) <![CDATA[리액트의 Render 함수와 Component 방식의 차이점]]> https://shipfriend.dev/posts/리액트의-render-함수와-component-방식의-차이점을-알아보자 https://shipfriend.dev/posts/리액트의-render-함수와-component-방식의-차이점을-알아보자 Fri, 10 Oct 2025 08:47:53 GMT { switch (currentView) { case 'year': return ; case 'month': return case 'day': return default: return null; } }; ``` 처음 리액트를 배웠을 때도 render 함수를 사용해왔고, 규모가 크지 않다면 render 함수를 자주 사용했다. 예를 들면 아이콘을 렌더링해야하는 경우 같이 작은 규모라면 `const renderIcon = (isChecked: boolean) => isChecked ? : ` 처럼 사용했던 경험이 많다. ## 성능 차이점 ### 리렌더링 사실 두 방식을 이렇다 정해두고 써본 적은 없지만 성능차이가 크지 않을 것이라고 무의식적으로 생각하고 있었다. 하지만 알아보니 꽤 많은 차이가 생길 수 있다는 것을 알게 되었다. 두 방식의 가장 큰 차이점은 렌더 함수의 경우 감싸고 있는 부모 컴포넌트가 리렌더링될 경우 항상 함수가 재생성된다는 점이다. 이때 렌더 함수의 규모가 아이콘을 렌더링하는 정도로 작다면, 큰 상관은 없지만 나의 경우처럼 뷰를 선택적으로 렌더링하는 경우에는 큰 손실이 생길 수 있겠다고 생각했다. **함수 재생성**, 꽤 많이 들어본 용어라고 생각한다. 그렇다면 이 함수 재생성의 비용은 어느정도일까? 함수 재생성이 매번 이루어지면 문제가 되는걸까? 답은 그렇지 않다. 함수 객체를 생성하는 것은 V8 엔진 단에서 매우 최적화되어 있다고 한다. 그래서 함수 재생성에 들어가는 코스트는 크지 않다. 함수 재생성에 들어가는 비용 때문에 문제가 생기는 것이 아니라, 이로 인해 발생하는 사이드 이펙트 때문이라고 한다. 대표적인 예시로 `useEffect`의 의존성배열에 함수가 있을 경우, 컴포넌트가 리렌더링될 때마다 함수의 참조가 새로 생성되어 effect가 다시 실행된다. ### 커스텀 훅 사용 가능 여부 render 함수 내부에서는 커스텀 훅을 사용할 수 없다. 내부에서 사용할 경우 커스텀 훅은 항상 최상위에서 사용되어야 한다는 리액트의 생애주기에 위반하기 때문에 에러가 발생한다. component 내부에서는 커스텀 훅을 사용할 수 있다. ### 메모이제이션 적용 성능 최적화가 꼭 필요한 도메인이거나 규모가 큰 컴포넌트의 경우 React.memo로 컴포넌트를 메모이제이션할 수 있다. 여기서도 Render와 Component의 차이점이 생긴다. Render 방식은 **메모이제이션 불가능**하지만 Component 방식은 **가능하다.** ```ts // Component는 React.memo로 최적화 가능 const YearDateCalendar = React.memo(() => { // 불필요한 리렌더링 방지 }); // Render 함수는 memo 적용 불가 const renderCalendar = () => ; // memo 효과 없음 ``` ## 가독성 차이점 ### 매개변수 > Render 함수 render 함수를 사용하면 매개변수를 최소화 할 수 있다는 것이 장점이다. 보통 render 함수는 컴포넌트 내부에 로직 형태로 작성되기 때문에 컴포넌트에서 사용하고 있는 상태를 전역 변수처럼 사용이 가능하다. 그렇기 때문에 단순히 `render()` 처럼 사용할 수도 있다. > Component 이에 비해 컴포넌트의 경우에는 네이밍과 전달되는 props를 통해서 해당 컴포넌트가 무슨 역할을 수행하는지 간단하게 파악을 할 수 있다는 점이 다르다. ```tsx const Parent = () => { const [date, setDate] = useState(new Date()); // 같은 스코프의 date에 접근 가능 const renderCalendar = () => { return
{date.toString()}
; }; // 하지만 Component는 명시적으로 props 전달 필요 return ; }; ``` ## 결론 결론적으로, 대부분의 경우에 **컴포넌트로 분리해서 사용하는 것이 훨씬 더 좋다.** 성능적인 문제는 크지 않다. 하지만 유지보수성과 가독성 그리고 사이드이펙트를 방지하기 위해서 컴포넌트 방식을 사용해야겠다고 생각했다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[Promise.all 이해하기]]> https://shipfriend.dev/posts/promise-all-이해하기 https://shipfriend.dev/posts/promise-all-이해하기 Fri, 29 Aug 2025 15:01:14 GMT ![ㅏㅏㅏㅏㅏㅏㅏㅏㅏ](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1764748255513-Gemini_Generated_Image_r67rj0r67rj0r67r-X1RVG90z5DCWFZrc9a5ZhnnRaFkwKr.webp) 그래서 이번에 API 최적화 방안에 대한 질문의 대답을 준비하면서 Promise.all의 동작 방식에 대해서 공부해보면 좋겠다고 생각했다. ## Promise Promise는 JS 프론트엔드를 하다보면 무조건 사용하게 되는 개념이다. 비동기 처리에 대한 상태를 가지고 있는 객체로, 비동기 작업의 대기, 완료, 실패 상태에 따른 처리를 할 수 있도록 만든 Wrapper 객체이다. ## Promise.all 프로미스에 .all 이 붙었다. 용어만 봤을 때 프로미스를 전체 실행한다는건가? 싶었다. 처음에 생각했던 것과 비슷하게 Promise.all은 여러 개의 비동기 작업을 동시에 병렬적으로 실행하고, 모든 작업이 완료될 때까지 기다렸다가 최종 결과를 한 번에 배열로 돌려주는 메서드이다. - 모든 작업이 성공하면 각 Promise의 결과가 배열 형태로 한 번에 반환 - 한 개라도 실패하면, 첫 번째로 실패한 이유만 반환하고 나머지는 무시됨 ```jsx const promise1 = Promise.resolve(1); const promise2 = Promise.resolve(2); const promise3 = Promise.resolve(3); Promise.all([promise1, promise2, promise3]) .then((results) => { console.log(results); // [1, 2, 3] }) .catch((error) => { console.error(error); }); ``` ## Promise.race와 Promise.all의 차이점 Promise.all은 모두 성공해야 반환하지만, race는 가장 먼저 완료되거나 실패한 프로미스의 값을 하나만 반환한다. - Promise.all은 전체를 기다림 - Promise.race는 가장 빠른 하나만을 기다림 race는 우리가 아는 레이스와 같은 개념으로 가장 빠르게 실행되는 결과만을 원할 때 사용한다. 언제 쓰이는지 쉽게 이해하기 위한 예제는 아래와 같다. ## Promise의 다른 메서드들 Promise에는 all과 race 말고도 다른 메서드들이 있다. - Promise.all - Promise.race - Promise.allSettled - Promise.any - Promise.resolve - Promise.reject allSettled는 모든 결과를 확인하는 것까지는 Promise.all과 똑같다. 차이점은 실패하는 것까지 다 기다린다는 점이다. Settled의 뜻이 안정된, 정착된의 뜻을 가지고 있는 것을 생각하면 완전히 종료될 때까지 기다리는 메서드라는 것을 알 수 있다. any는 Promise.race와 비교할 수 있다. Promise.any는 가장 먼저 처리되는 결과를 반환하는 것까지는 똑같지만, 가장 먼저 **“성공”**하는 것만 기다린다. 성공 전에 실패가 나오더라도 무시하고, 다음 성공을 기다린다. 만약 모두 실패하는 경우에는 AggregateError를 반환한다. ## Promise.all로 어떤 최적화를 할 수 있을까? Promise.all로는 어떤 일을 할 수 있을까. 일단 코드를 줄일 수 있는 것이 장점이라고 생각된다. 같은 레벨의 API 요청이라면 일일히 요청할 필요없이 한꺼번에 요청해서 코드도 줄이고 속도도 줄이는 것이 좋을 것 같다. 만약 순차적으로 요청해야하는 API라면? A라는 데이터를 불러오고, A를 payload로 하는 B API 요청을 보내기 위해서는 A API가 완수되기 까지를 기다려야한다. 이 경우에는 Promise.all은 사용하지 않아도 된다. ```jsx // 순차 처리(비최적화) const users = await fetchUsers(); // 300ms const products = await fetchProducts(); // 200ms const orders = await fetchOrders(); // 250ms // 총 대기: 약 750ms ``` async / await은 순서가 보장되지 않는 비동기 작업들의 순서를 보장하기 위해서 사용하는 키워드들이다. 즉, 요청 함수 앞에 await을 붙이는 순간에는 그 아래 함수들은 요청이 끝나고 결과가 나오기 전까지는 실행되지 않는다. 그렇다면 같은 레벨이 아닌 함수를 위와 같이 3번 연속으로 동기적으로 실행하게되면 대기 시간이 길어지게 된다. ```jsx // 병렬 처리(최적화) const [users, products, orders] = await Promise.all([ fetchUsers(), // 300ms fetchProducts(), // 200ms fetchOrders() // 250ms ]); // 총 대기: 약 300ms (가장 오래 걸리는 작업 기준) ``` 위와 같이 최적화를 할 수 있다. 이 경우에는 병렬적으로 처리하기 때문에 가장 오래걸린 작업의 시간 만큼만 소요된다. ## 궁금한 점, 여러 요청 중 늦어지는 요청이 있을 경우에는 어떻게 되나 학습을 하다보니 궁금한 점이 생겼다. 만약 마이페이지에서 **유저 정보**와, **유저가 작성한 글 리스트**, **유저가 작성한 댓글 리스트**들을 렌더링한다고 할 때, 세 요청을 Promise.all로 묶어서 병렬로 요청한다. 여기서 두 요청은 10ms로 매우 빨리 받아지지만, 나머지 하나의 요청이 1000ms가 걸릴 경우, 두 요청에 대한 값으로 렌더링을 먼저 진행하고 늦어지는 값은 나중에 렌더링하도록 할 수 있는건가? ![흠](https://i.pinimg.com/1200x/67/c0/17/67c017853ae82f99399c0bae526d47de.jpg) 만약 Promise.all만 사용하면 가장 늦어지는 결과 값이 나올 때까지 나머지 값을 사용할 수 없다고 한다. 개별적으로 사용하고 싶을 경우에는 then이나 await을 사용해서 처리해야한다고 한다. await을 사용하는 코드는 결국에 async를 붙여야하기 때문에 복잡해질 수 있어서 가장 보기 편한 코드는 아래처럼 then을 써서 예약해두는게 좋은 방식인 것 같다. 아래처럼 하면 가장 await을 함수 앞에 붙이지 않았기 때문에 3 요청 모두 병렬적으로(거의) 실행되지만, 값이 받아와지는대로 상태를 변경하고, UI를 렌더링 할 수 있다. ```jsx const MyPage = () => { const [userInfo, setUserInfo] = useState(null); const [userPosts, setUserPosts] = useState(null); const [userComments, setUserComments] = useState(null); useEffect(() => { // 각각 독립적으로 처리 fetchUserInfo().then(setUserInfo); fetchUserPosts().then(setUserPosts); fetchUserComments().then(setUserComments); }, []); return (
{userInfo ? : } {userPosts ? : } {userComments ? : }
); }; ``` ## React Query와 SWR에서는.. 위와 같은 병렬처리와 우선으로 처리되는 값에 대한 렌더링을 편하게 사용하기 위한 방법을 React-query와 SWR 같은 서버 상태 관리 라이브러리에서는 편리하게 지원한다. ### React-query 리액트 쿼리에서는 아래와 같이 useQueries 훅을 지원한다. useQuery를 여러번 써도 블락킹 되지 않아서 병렬적이라고 봐도 된다. ```jsx const MyPage = () => { const queries = useQueries({ queries: [ { queryKey: ['user'], queryFn: fetchUserInfo }, { queryKey: ['posts'], queryFn: fetchUserPosts }, { queryKey: ['comments'], queryFn: fetchUserComments } ] }); const [userQuery, postsQuery, commentsQuery] = queries; return (
{userQuery.isLoading ? : } {postsQuery.isLoading ? : } {commentsQuery.isLoading ? : }
); }; ``` 지금하고 있는 프로젝트에서 한번 적용해봐야겠다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[웹 뷰(Web View)란?]]> https://shipfriend.dev/posts/웹-뷰-web-view-란 https://shipfriend.dev/posts/웹-뷰-web-view-란 Sun, 24 Aug 2025 07:42:44 GMT RN 용 라이브러리 RN용 라이브러리를 사용하는 것의 장점은 빠른 개발과 복잡성이 늘어나지 않는다는 점이 었다. 하지만 이 경우 가장 인기있는 Rechart 같은 라이브러리를 사용할 수 없다는 점이 단점이었다. > 웹 뷰를 사용하는 것 웹 뷰를 사용하면 복잡도가 늘어난다. 앱 개발만 하는 것이 아닌 웹 개발도 같이 해야하기 때문이었다. 하지만 Rechart라는 라이브러리를 사용해볼 수 있다는 점과 웹 뷰 자체에 대한 경험을 쌓을 수 있다는 점이 큰 장점이라고 생각했다. > 결론 웹 뷰와 Rechart 라이브러리 조합을 사용하기로 결정 Inforsion프로젝트를 개발하면서 생기는 문제 해결 경험들도 블로그에 시리즈를 하나 파서 만들어야겠다. ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[티스토리 생산성 확장프로그램 - StoryHelper 사용 가이드]]> https://shipfriend.dev/posts/티스토리-생산성-확장프로그램-storyhelper-사용-가이드 https://shipfriend.dev/posts/티스토리-생산성-확장프로그램-storyhelper-사용-가이드 Wed, 13 Aug 2025 09:58:48 GMT **주의사항** > > 단축키 조정 이후, 새로고침해야 변경된 단축키가 작동합니다. 또한 일부 브라우저 기본 단축키와 호환성 이슈로 작동이 안될 수 있습니다. #### 단축키 적용 기능 목록 단축키를 설정할 수 있는 기능에는 아래 기능들이 있습니다. 모두 자주 사용되는 기능들로 원하는 단축키를 지정해 사용하면 생산성 향상에 도움이 됩니다. - 글 발행 기능 - 이미지 업로드 기능 - 에디터 변환 기능 (HTML <-> 기본) - 이전 글 링크 기능 - 서식 창 기능 ### 🖼 2. SEO 이미지 최적화 도구 - 2가지 이미지 최적화 도구 제공 - 이미지 크기 일괄 조정, 이미지 alt 태그 일괄 입력 기능 본문 내부에 있는 모든 이미지에 대해 일괄적으로 크기를 지정하거나 대체텍스트를 작성할 수 있는 기능입니다. 티스토리 에디터의 상단 버튼 목록에 자연스럽게 추가되어있습니다. ![에디터 상단 도구](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1755078195302-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-08-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%206.43.07-nQWZC6ZzAXWB3R7mbiewLIhYdPVaJF.png) ### 📊 3. 실시간 글자수 카운팅 - 실시간 글자수 확인 UI 제공 - 글 작성 중 언제든지 글자수 체크 가능 - 적정 글 길이 관리에 도움 ![글자 수 카운터](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1755078259444-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-08-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%206.44.09-UNJxuJcMDB81Urgv7kwRc6xRY6Jeu0.png) ### 🔍 4. SEO 검증 기능 (v1.5+) 1.5 버전 이후에 추가된 기능입니다. 기능이 보이지 않는다면 확장프로그램의 버전을 확인해주세요. #### 기능 설명 티스토리 글쓰기에서는 검색엔진 최적화를 위한 글 구조화가 중요합니다. 이때, 내가 작성하고 있는 글이 구조화되어 있는지를 실시간으로 검증하는 기능입니다. - 제목1(H1) 태그 검증: 글에 하나만 존재해야 함 - 이미지 대체 텍스트 검증: 모든 이미지에 alt 텍스트 필수 > **글 내부에 제목1(h1태그)는 하나만 있어야합니다. 아래 경우에서는 제목1이 제대로 작성되었기 때문에 우측 하단 검색엔진 최적화 성공 텍스트가 보입니다.** ![검증 완료](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1755078407409-%E1%84%80%E1%85%B3%E1%86%AF%20%E1%84%80%E1%85%AE%E1%84%8C%E1%85%A9%E1%84%92%E1%85%AA%20%E1%84%80%E1%85%A5%E1%86%B7%E1%84%8C%E1%85%B3%E1%86%BC%20%E1%84%90%E1%85%A9%E1%86%BC%E1%84%80%E1%85%AA-IejfhQojzxDqU71iwmbNHpeXUEZW6Z.png) > **제목1은 하나만 있지만, 이미지의 크기가 auto이고 alt 태그가 작성되지 않았기 때문에 검색엔진 최적화가 되지 않았다고 보입니다.** ![검증 실패](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1755078408258-%E1%84%80%E1%85%B3%E1%86%AF%20%E1%84%80%E1%85%AE%E1%84%8C%E1%85%A9%E1%84%92%E1%85%AA%20%E1%84%80%E1%85%A5%E1%86%B7%E1%84%8C%E1%85%B3%E1%86%BC%20%E1%84%90%E1%85%A9%E1%86%BC%E1%84%80%E1%85%AA%20%E1%84%89%E1%85%B5%E1%86%AF%E1%84%91%E1%85%A2-PQmAXOUWYWfqd66Kqh8IgG9PQIUNTr.png) --- ## v1.6.0 패치노트 ### 변경사항 - 확장프로그램 설정 창 > 크레딧 하단에 버전 표시 추가 - 현재 켜진 기능 시각 오버레이 추가 (좌측 하단) ![스토리헬퍼 시각화 오버레이](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1755078853581-%E1%84%89%E1%85%B5%E1%84%80%E1%85%A1%E1%86%A8%E1%84%92%E1%85%AA%20%E1%84%8B%E1%85%A9%E1%84%87%E1%85%A5%E1%84%85%E1%85%A6%E1%84%8B%E1%85%B5-N3dpyJJPz44SwKZMJ695X9J6y2q1Uh.png) ## 배포 링크 [StoryHelper 다운로드](https://chromewebstore.google.com/detail/storyhelper/inmbdknioncgblpeiiohmdihhidnjpfp?authuser=0&hl=ko) ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[블로그에 유튜브 임베딩하기]]> https://shipfriend.dev/posts/블로그에-유튜브-임베딩하기 https://shipfriend.dev/posts/블로그에-유튜브-임베딩하기 Wed, 30 Jul 2025 11:21:36 GMT 유튜브 링크가 있는지 확인한다 → 동영상 Id를 가져온다. → 유튜브 embed iframe을 생성한다. 과정을 거쳐야 한다. > 다행히 UIW 라이브러리에는 rehypeRewrite 플러그인을 지원한다. 이 플러그인을 통해 마크다운에서 HTML로 변경하는 과정에서 사용자가 원하는 방식으로 렌더링 덮어씌우기가 가능하다. ```tsx { asideStyleRewrite(node); renderOpenGraph(node, index || 0, parent as Element | undefined); renderYoutubeEmbed( node, index || 0, parent as Element | undefined ); }} /> ``` 이전에도 Notion의 콜아웃 스타일을 내 블로그에도 적용하기 위해 사용했었기 때문에 이 방법을 사용하기로 했다. 위 컴포넌트는 MDEditor의 마크다운을 HTML 형식으로 렌더링해주는 컴포넌트이다. rehypeRewrite prop에 각각의 덮어씌우기 플러그인들을 함수 형태로 분리해서 가독성을 높였다. ![왓](https://i.pinimg.com/736x/cf/d1/84/cfd1840c48c555efa6a548b2bde7bcc8.jpg) ## Youtube 링크 찾기 rewrite를 하기 위해서는 youtube 링크가 포함된 a 태그를 발견해야한다. ### Rewrite 함수의 시그니쳐 ```tsx type RehypeRewriteFunction = (node: Element, index: number, parent: Element) => void; ``` 위는 RehypeRewrite 플러그인에 들어가는 함수의 타입 시그니쳐이다. 마크다운에서 HTML의 DOM 트리로 변환하는 과정에서 node를 하나씩 거쳐가며 rehypeRewrite를 적용하는 방식이다. 아래 uiw의 공식 문서에 포함된 예제를 살펴보자. ```tsx { if (node.tagName === "a" && parent && /^h(1|2|3|4|5|6)/.test(parent.tagName)) { parent.children = parent.children.slice(1) } }} /> ``` node의 tagName을 통해 필터링을 하고, 부모 요소의 태그가 헤딩 태그일 경우 부모 요소의 첫번째 자식 요소만 남겨두고 제거하는 코드이다. a 태그를 찾기 위한 플러그인 함수를 만들어보자. 위 예제처럼 하면 링크 발견은 쉽게 할 수 있다. `if (node.tagName === "a")` 를 적용하면 되기 때문이다. **하지만..** ## 링크 발견까지는 했는데 어떻게 다음 줄에 embed하지? 링크를 발견할 경우 해당 a 태그의 parent는 p태그가 된다. 그렇다면 p 태그를 중심으로 요소를 추가해야 하는데 이 경우 다음 줄에 embed하기 어렵다고 판단했다. 그래서 a 태그를 갖는 p 태그를 찾기로 결정했다. ```tsx const renderYoutubeEmbed = (node: any, index?: number, parent?: Element) => { if (node.type === 'element' && node.tagName === 'p' && node.children) { const aTag = node.children.find( (node: any) => node.type === 'element' && node.tagName === 'a' ); } } ``` 이렇게 하면 parent는 문서 전체가 되고 요소의 index를 활용하여 a 태그 다음 줄에 iframe을 삽입할 수 있을 것이다. ## Youtube iframe 생성하기 구현한 플러그인의 전체 코드는 아래와 같다. youtube 링크인지 확인하고, createYoutubeIframe 함수를 통해 iframe 요소를 생성한다. 객체를 만드는 함수를 만들어서 분리하여 가독성을 높였다. 유튜브의 링크는 [youtu.be](http://youtu.be) 형식과 [youtube.com/watch](http://youtube.com/watch) 형식 두 가지가 있어서 두 가지 모두에 대응할 수 있도록 구현했다. `renderYoutubeEmbed 함수의 전체` ```tsx const renderYoutubeEmbed = (node: any, index?: number, parent?: Element) => { if (node.type === 'element' && node.tagName === 'p' && node.children) { const aTag = node.children.find( (node: any) => node.type === 'element' && node.tagName === 'a' ); if (!aTag) return; const href = aTag.properties?.href; const isYoutubeLink = href && (href.startsWith('https://www.youtube.com/watch') || href.startsWith('https://youtu.be/')); if (isYoutubeLink) { const urlType = href.startsWith('https://www.youtube.com/watch') ? 'watch' : 'be'; const videoId = urlType === 'watch' ? new URL(href).searchParams.get('v') : href.split('/').pop(); if (videoId) { const youtubeEmbed = createYoutubeIframe(videoId, 736, 414); // 부모가 존재하고 children 배열이 있는 경우 if (index && parent && parent.children) { // 현재 a 태그 다음 위치에 embed 삽입 parent.children.splice(index + 1, 0, youtubeEmbed); } else return; } } } }; ``` `createYoutubeIframe 함수 코드` ```tsx const createYoutubeIframe = ( videoId: string, width: number, height: number ) => { return { tagName: 'iframe', properties: { src: `https://www.youtube.com/embed/${videoId}`, width: width, height: height, frameBorder: '0', allowFullScreen: true, className: 'youtube-embed', }, children: [], }; }; ``` 위 코드를 통해서 유튜브 임베드를 렌더링하게 된다. 아래 부분 코드를 통해 부모 요소의 index 위치 다음에 유튜브 임베드 iframe을 삽입하는 방식이다. ```tsx if (videoId) { const youtubeEmbed = createYoutubeIframe(videoId, 736, 414); // 부모가 존재하고 children 배열이 있는 경우 if ( index && parent && parent.children && Array.isArray(parent.children) ) { parent.children.splice(index + 1, 0, youtubeEmbed); } else return; } ``` 이제 유튜브 링크가 존재하는 블럭 다음 줄에 이렇게 Youtube Embed Iframe이 생성되는 것을 볼 수 있다. [유튜브 링크](https://www.youtube.com/watch?v=SFA96Nvv0Yg)를 걸면 아래에 자동으로 embed되는 모습이다. 요즘 집중할 때 틀어놓는 앰비언스를 링크해봤다. ㅎㅎ 유튜브에는 시연 영상 위주로 올릴 것 같다. ![끝](https://i.pinimg.com/736x/fd/ff/3e/fdff3ecf99bcaad8a7e056ed98e8f059.jpg)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[HOC 패턴으로 보호된 라우트 레이아웃 컴포넌트 구현]]> https://shipfriend.dev/posts/hoc-패턴으로-보호된-라우트-레이아웃-컴포넌트-구현 https://shipfriend.dev/posts/hoc-패턴으로-보호된-라우트-레이아웃-컴포넌트-구현 Sat, 26 Jul 2025 06:56:48 GMT { return
{children}
} const Page = () => { return

안녕하세요

 } ``` ## 주요 기능 아래는 우리 서비스에서 인증 검증 로직을 분리한 코드이다. 인가 여부 검증을 하는 코드를 하나의 레이아웃 컴포넌트에 분리되어있으며, 이제 재사용하기만 하면 된다. ```tsx import { useEffect } from "react"; import useAuth from "@hooks/useAuth.ts"; import useToast from "@hooks/useToast.ts"; import { useLocation, useNavigate } from "react-router-dom"; interface ProtectedRouteLayoutProps { children: React.ReactNode; } const ProtectedRouteLayout = ({ children }: ProtectedRouteLayoutProps) => { const { isLoggedIn } = useAuth(); const toast = useToast(); const location = useLocation(); const navigate = useNavigate(); useEffect(() => { if (!isLoggedIn) { toast.error("로그인이 필요한 서비스입니다."); navigate("/login", { state: { from: location }, replace: true }); } }, [isLoggedIn]); return <>{children}; }; export default ProtectedRouteLayout; ``` 재사용하는 예시는 아래와 같다. ProtectedRouteLayout을 사용하여 감싸기만 하면 된다. 이제 CreateQuestionPage는 인증해야 접근 가능한 페이지가 된다. ```tsx { element: ( ), path: "/questions/create", }, { element: , path: "/*", }, ``` 이전에 계속 반복되는 로직을 분리했기 때문에 개발 생산성이 크게 올랐다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[비디오 컴포넌트 렌더링 최적화]]> https://shipfriend.dev/posts/webrtc-공감-기능-개발하기 https://shipfriend.dev/posts/webrtc-공감-기능-개발하기 Mon, 30 Jun 2025 14:06:09 GMT { if (senderId === socket.id) { setReaction(reaction); const timeout = setTimeout(() => setReaction(""), 3000); } else { addReaction(senderId, reaction); const timeout = setTimeout(() => { addReaction(senderId, ""); }, 3000); } } ); ``` ### 발생한 문제 공감 기능은 예상했던대로 작동했다. 모든 사용자에게 뿌린 리액션 이벤트를 기반으로 리액션을 날린 사용자 컴포넌트 **우측 상단에 리액션을 띄우도록 구현**했다. 하지만, 리액션 객체를 수정할 때마다 화면이 깜빡거리면서 리렌더링이 되는 문제가 발생했다. - 본인이 리액션을 했을 때, 본인을 제외한 피어 컴포넌트가 리렌더링되면서 깜빡임 - 타인이 리액션을 했을 때, 본인을 제외한 타 피어 컴포넌트가 리렌더링되면서 깜빡임 ![Nov-11-2024 18-15-55.gif](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751292332764-Nov-11-2024%2018-15-55-CWCdjkI7yveyxtgwIyqfTTEBaihfAW.gif) ### 원인 리액션 이벤트가 발생하면 본인이 누른 리액션이라면 setReaction 상태를 변경시키고, 다른 피어가 누른 리액션이라면 peers 상태를 조작하기 때문에 VideoContainer 컴포넌트가 리렌더링되기 때문이다. > 기존 코드 ```tsx { peers.map((peer) => ( { // 비디오 엘리먼트가 있고, 스트림이 있을 때 if (el && peer.stream) { el.srcObject = peer.stream; } peerVideoRefs.current[peer.peerId] = el; }} nickname={peer.peerNickname} isMicOn={true} isVideoOn={true} isLocal={false} reaction={peer.reaction || ""} /> )) } ``` > 개선 코드 ```tsx {useMemo( () => // 상대방의 비디오 표시 peers.map((peer) => ( { // 비디오 엘리먼트가 있고, 스트림이 있을 때 if (el && peer.stream) { el.srcObject = peer.stream; } peerVideoRefs.current[peer.peerId] = el; }} nickname={peer.peerNickname} isMicOn={true} isVideoOn={true} isLocal={false} reaction={peer.reaction || ""} /> )), [peers] )} ``` 개선된 코드에서는 peers와 관련된 변경사항일 때만 다른 피어들의 비디오 컴포넌트를 리렌더링하도록 수정했다. useMemo를 사용해서 peers 배열이 변경될 경우에 리렌더링을 트리거한다. > 성과 이로 인해서 본인 리액션, 마이크 음소거, 비디오 끄기 버튼을 눌러도 다른 사람의 비디오 컴포넌트는 리렌더링이 일어나지 않게 되어 깜빡임 현상이 없어졌다. **하지만, 본인이 누른 리액션이 다른 사람의 환경에서는 peer의 변경사항이다. 따라서 다른 사람의 화면에서는 리액션을 누른 사람의 화면이 깜빡인다.** --- ## 아직 깜빡이는 문제 원인이 무엇일까? 😓 useMemo를 최적화를 해도 결국 peers 정보가 바뀌면 리렌더링이 되는 상황이었다. reaction 값만 바뀐다면 실제 DOM에는 reaction과 관련된 부분만 리렌더링이 되기 때문에 전체가 깜빡이는 현상이 일어나지 않아야한다. 그렇다면 VideoContainer에 ref를 전달하는게 원인일까? 코드를 다시 읽어보면서 ref가 문제일까라고 의심을 해보기 시작했다. 그리고 VideoContainer에서 ref를 함수 형태로 전달하고 있는 것을 찾아냈다. > 기존 코드 > 기존 VideoContainer에는 미디어 스트림을 담은 ref 객체를 전달하고 있다. 그리고 전달되는 ref는 고정된 값이 아닌 함수 형태로 되어있기 때문에 매 렌더링마다 다른 참조를 가지게 된다. (매렌더링마다 함수가 새로 생성) 그래서 의도한 바는 reaction 값만 바뀌는 것이었지만 항상 ref가 같이 생성되고 있었기에 전체 컴포넌트가 리렌더링되었던 것이었다. ```tsx { // 비디오 엘리먼트가 있고, 스트림이 있을 때 if (el && peer.stream) { el.srcObject = peer.stream; } peerVideoRefs.current[peer.peerId] = el; }} /> ``` > 개선 코드 > 단순히 ref 값을 개선하기 보다는 전체적인 개선을 해보는 것이 좋겠다고 생각했다. 왜냐하면 ref값을 Props Drilling으로 전달하기에는 번거로운 작업이 껴있었다. 바로 `forwardRef`로 컴포넌트를 감싸줘야하는 것인데, 이 경우 상위 컴포넌트와 하위 컴포넌트 간의 결합도를 증가시킨다. 결합도 뿐만 아니라 가독성 측면에서도 함수로 감싸는 것이기 때문에 좋지 않다고 판단했다. 그래서 다른 webrtc 예제 코드를 살펴보던 도중 https://codesandbox.io/p/sandbox/react-webrtc-video-chat-b649f 해당 예제 코드를 보게 되었다. 해당 예제에서는 비디오 컴포넌트 내부에서도 `stream을 송출하는 목적` 만을 가지는 컴포넌트를 가지고 있었다. 이 컴포넌트에서 영감을 얻어 stream을 넣은 ref를 전달하는 것이 아닌 stream을 전달해서 하위 컴포넌트에서 ref를 만들어서 사용하는 방식으로 변경하기로 했다. ```tsx ``` ```tsx interface DisplayMediaStreamProps { mediaStream: MediaStream | null; isLocal: boolean; } const DisplayMediaStream = ({ mediaStream, isLocal, }: DisplayMediaStreamProps) => { const videoRef = useRef(null); useEffect(() => { if (mediaStream !== null && videoRef.current) { videoRef.current.srcObject = mediaStream; } else if (videoRef.current && mediaStream === null) { // videoRef.current.srcObject.getTracks().forEach((t) => t.stop()); videoRef.current.srcObject = null; } }, [mediaStream]); return ( sjw4371@naver.com (개발자 서정우) <![CDATA[카메라 인디케이터 라이트 항상 표시되는 오류 해결하기]]> https://shipfriend.dev/posts/카메라-인디케이터-라이트-항상-표시되는-오류-해결하기 https://shipfriend.dev/posts/카메라-인디케이터-라이트-항상-표시되는-오류-해결하기 Fri, 27 Jun 2025 05:02:10 GMT 이 글은 노션에서 마이그레이션된 글입니다. ![섬네일](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751001073266-%EC%A0%9C%EB%AA%A9%EC%9D%84%20%EC%9E%85%EB%A0%A5%ED%95%B4%EC%A3%BC%EC%84%B8%EC%9A%94_-001-6KGw7ZU1aviWmZ8zslVvAPNoh6kGeC.png) **이슈 링크 :** https://github.com/boostcampwm-2024/web27-Preview/issues/111 ## 🚩 문제 상황 카메라를 끄는 버튼은 이미 구현이 되어있다. 해당 버튼을 누르면 videoTrack의 `enabled` 속성을 false / true로 토글하여 비디오를 끄고 켤 수 있다. 그러나 문제는 `enabled`이 false여서 비디오가 꺼졌다고 하더라도, 실질적으로 비디오 트랙의 픽셀을 모두 검은색으로 채운 빈 프레임을 보낸다고 한다. 실질적인 내용이 없지만 결국에 보내지고 있기 때문에 운영체제, 브라우저는 카메라를 사용 중인 것으로 판단하고 인디케이터를 작동시키는 것이다. ***사용자 입장에서는 비디오를 껐음에도 상단에 카메라를 사용 중이라는 인디케이터가 켜져있으면 불안할 것 같다고 생각이 들었다.*** ## 💬 고민 - 그렇다면 어떻게 **인디케이터를 비활성화하는** 비디오 끄기를 지원할까? - `enabled` 속성을 건드리는 것이 아닌 아예 `track.stop()`을 해버리면 인디케이터는 즉시 종료된다. - 문제는 stop 후 restart 같은 메서드가 없다는 점이다. - 즉, 비디오를 끄고 나서 다시 키려면 **스트림을 다시 받아와야한다**는 점이다. ## ✨ 해결 ### 첫 번째 시도: useState 처음에는 getMedia 함수를 리팩토링해서 options 매개변수를 받도록 수정했다. options은 선택적인 매개변수로 있다면 오디오나 비디오 혹은 모든 미디어 장치로부터 스트림을 얻어오는 함수로 만들었다. 하지만 간과하고 있던 문제가 있었다. 바로 stream을 상태로 관리한다는 점이다. ```tsx const [stream, setStream] = useState(); ``` `stream`은 객체이고 스트림에는 각각 트랙들이 존재한다. 비디오 트랙, 오디오 트랙 정도가 있다. 비디오를 끄고 나서 다시 키려고하면 비디오 트랙을 불러와서 해당 stream의 내부 트랙에 넣어줘야한다. 그렇지만 stream은 상태로 존재하기 때문에 setStream으로 아예 새로운 객체를 넣어줄 수 밖에 없게 된다. 이를 통해 `Stream` 객체는 `useState`로 관리하는 것이 아닌 `useRef`로 관리하기로 결정했다. **📌 useState 대신 useRef를 사용하기로 한 이유** - stream 객체의 내부 옵션을 사용해서 내부 객체를 변경하고 싶음 - stream을 useState로 관리하게 되면 setStream으로 값을 지정해주는 것이 리액트가 권장하는 방식이다. ```tsx const Component = () => { const [stream, setStream] = useState(); const handle = (newTrack) => { // 스트림에 트랙을 추가하는 것 stream.addTrack(newTrack) } handle(); useEffect(() => { console.log('stream가 실제로 변경됨'); }, [stream]); }; ``` - 위 코드는 stream에 addTrack을 했을때 useEffect 내부의 코드가 실행되는 것을 의도했지만, stream을 직접 수정하기 때문에 실행되지 않는다. - 직접 수정은 리액트의 렌더링 사이클을 우회하는 것이므로 권장되지 않는 방식이다. - 객체의 내부의 값을 변경해도 객체 자체의 참조가 변경되지 않으므로 useEffect는 실행되지 않는다. - 이런 사이드이펙트들이 직접 수정을 사용하면 안되는 이유를 가르쳐주고 있다. **그래서 stream 객체를 useRef로 관리하기로 결정했다.** - useRef로 할 경우 불필요한 리렌더링이 방지된다. - 미디어 스트림 객체 자체는 UI 렌더링에 직접적인 영향을 주지 않는다. - 무엇보다 useRef로 할 경우 streamRef.current로 조작이 가능하기 때문에 적합하다고 판단했다. ### 두 번째 시도: useRef useRef를 사용하기로 결정했다. 리팩토링에는 오랜 시간이 걸리지 않았다. `useMediaDevices` 훅에서 미디어 스트림과 장치에 대한 책임을 가지고 있도록 했기 때문이었다. 훅 내부에서는 useRef를 사용해 ref 객체를 생성하고 기존에 사용하던 stream 상태는 제거했다. `useMediaDevices`에서는 ref가 아닌 ref가 가진 mediastream 객체를 내보내도록해서 외부에서는 ref 객체에 접근할 수 없게 만들었다. 그결과 useRef를 통한 stream은 되는 것을 확인했다. **하지만 가장 큰 문제**가 하나 있었는데 ref 객체로 만들어졌기 때문에 **mediastream이 생기기 전에 UI 렌더링이 모두 끝났고, 이후 리렌더링이 안되는 문제**였다. 객체가 값을 가지고 있긴 했지만 리렌더링이 일어나지 않은 것이었기 때문에 비디오 토글 버튼을 통해 리렌더링을 트리거해야 스트림이 UI에 반영되는 일이 생겼다. ![image.png](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751000476775-111-XoYkvJmNYD5scvDN8uzPrADwQ9IdBF.png) **📌 그럼 useRef를 사용하면 미디어 스트림 반영이 안되는 것일까?** 한참을 고민 끝에 타협점을 찾았다. useState와 useRef를 모두 쓰는 것이다. 실제로 외부에 노출되는 것은 useState로 선언한 스트림 상태가 될 것이고, useRef로 선언한 객체는 내부 값을 변경하기 위해서 사용할 것이다. ```tsx const [stream, setStream] = useState(); const streamRef = useRef(); // 지양해야하는 방식 stream.addTrack(); // 설계한 방식 streamRef.current.addTrack(); setStream(streamRef.current) ``` 이렇게 하면 상태를 직접 조작하는 방식을 쓰지 않아도 되고, 불변성을 지킬 수 있기 때문에 좋은 방법이라고 생각했다. ### 세 번째 시도: useState와 useRef 모두 사용 `useRef` 와 `useState` 를 모두 사용해서 Hook 외부로 공개하는 것은 state로 만든 stream 객체가 될 것이다. useRef로 만든 ref 객체를 통해 stream 객체 내부 트랙 정보를 수정할 것이고, 수정된 객체를 setStream을 통해 상태를 변경할 계획이다. 이렇게 해서 기대하는 바는 객체 내부를 사이드 이펙트 걱정 없이 수정하고, 수정 완료된 객체를 상태로 업데이트하는 것이다. ```tsx // 미디어 스트림 토글 관련 const handleVideoToggle = async () => { try { // 비디오 껐다키기 if (stream) { for (const videoTrack of stream.getVideoTracks()) { if (videoTrack.enabled) { // 비디오 끄기 videoTrack.stop(); videoTrack.enabled = false; } else { // 새로운 비디오 스트림 생성 const videoStream = await getMediaStream("video"); if (videoStream) { setVideoLoading(true); streamRef.current?.getVideoTracks().forEach((track) => { streamRef.current?.removeTrack(track); }); videoStream?.getVideoTracks().forEach((track) => { streamRef.current?.addTrack(track); console.log("새로운 비디오 트랙을 추가했습니다."); }); } else { console.error("비디오 스트림을 생성하지 못했습니다."); } setStream(streamRef.current); } } } setIsVideoOn((prev) => !prev); } catch (error) { console.error("Error stopping video stream", error); } }; ``` 위 코드는 비디오를 끄고 켜는 동작을 하는 함수인데, 비디오를 끄고 나서 다시 킬때는 새로운 비디오 트랙을 가져와서 기존 스트림에 추가해주는 방식을 사용하고 있다. ## 🚀 결과 세 번째 시도 끝에 **카메라 인디케이터를 비활성화하고 다시켤때 스트림을 다시 얻어오는 작업**을 끝냈다. 비디오를 끄고 켜는데 이전보다 시간이 오래걸리는 것은 어쩔 수 없는 부분인 것 같다. 이전에는 단순히 비활성화를 했다면 이번에는 **스트림을 새로 생성하기 때문에 약간의 지연시간**이 생겼다. 이 부분은 로딩 상태를 추가해서 미디어 스트림이 로딩되기 전에 로딩 현황을 알려주도록 구현해야겠다고 생각했다. **`뿌듯하다.`** ![카메라인디케이터해결.gif](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751000456101-222-vtx2otwcKtSR9b4uh3zITc0uhXeu5O.gif)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[Access Token 만료시 일관적인 401 에러 응답 처리]]> https://shipfriend.dev/posts/access-token-만료시-일관적인-401-에러-응답-처리 https://shipfriend.dev/posts/access-token-만료시-일관적인-401-에러-응답-처리 Fri, 27 Jun 2025 04:59:34 GMT 이 글은 노션에서 마이그레이션된 글입니다. ![섬네일](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751001073266-%EC%A0%9C%EB%AA%A9%EC%9D%84%20%EC%9E%85%EB%A0%A5%ED%95%B4%EC%A3%BC%EC%84%B8%EC%9A%94_-001-6KGw7ZU1aviWmZ8zslVvAPNoh6kGeC.png) ## 배경 및 목적 애플리케이션에서 보호된 리소스에 접근할 때 발생하는 401 인증 에러에 대한 일관된 처리 방식이 필요했다. 특히 액세스 토큰 만료 시 리프레시 토큰을 통한 재발급 과정과 이에 따른 요청 재시도 로직을 효율적으로 구현하고자 했다. ## 해결 과제 기존 방식에서는 다음과 같은 복잡한 프로세스가 필요했다: 1. 보호된 리소스 접근 요청 2. 401 에러 발생 시 리프레시 토큰으로 새 액세스 토큰 발급 요청 3. 원래 요청 재시도 이러한 다중 요청 처리는 마치 데이터베이스의 트랜잭션과 같은 복잡성을 가지고 있어 효율적인 해결책이 필요했다. ## 구현 방안 Axios 인스턴스의 인터셉터 기능을 활용하여 모든 401 에러에 대한 일관된 처리 로직을 구현했다. 주요 처리 절차는 다음과 같다: 1. 401 에러가 발생한 원본 요청을 저장 2. 리프레시 토큰을 사용하여 새로운 액세스 토큰 발급 요청 3. 토큰 재발급 성공 시 원본 요청 재시도 4. 실패 시 세션 만료로 판단하고 로그인 페이지로 리다이렉트 ### axios interceptor ```tsx import axios, { AxiosError } from "axios"; import { refreshAccessToken } from "@/api/user/auth.ts"; import useAuthStore from "@stores/useAuthStore.ts"; export const api = axios.create({ timeout: 5000, withCredentials: true, }); api.interceptors.response.use( (response) => response, async (error: AxiosError) => { const originalRequest = error.config; if (error.response?.status === 401) { try { const response = await refreshAccessToken(); if (response.data.success) { return axios(originalRequest!); } } catch (error) { console.error("토큰 재발급 실패", error); alert("세션이 만료되었습니다. 다시 로그인해주세요."); useAuthStore.persist.clearStorage(); window.location.href = "/login"; return Promise.reject(error); } } return Promise.reject(error); } ); ``` ## 개선 효과 1. 사용자 경험 향상 - 토큰 만료 시에도 서비스 이용의 연속성 보장 - 최소한의 지연으로 자동 토큰 재발급 처리 - 세션 만료 시 명확한 안내와 함께 로그인 페이지로 유도 2. 개발 효율성 증대 - 401 에러 처리 로직의 중앙화로 코드 중복 제거 - 일관된 에러 처리로 유지보수성 향상 - 개별 컴포넌트에서의 토큰 관리 부담 감소 ## 유연성 확보 특정 요청에 대해 다른 방식의 401 에러 처리가 필요한 경우, Axios 인스턴스 대신 일반 Axios를 사용하면 되어 유연하게 응답 처리를 할 수 있다는 점이 좋았다. ## 결론 Axios 인터셉터를 활용한 401 에러 처리 방식은 복잡한 토큰 갱신 프로세스를 효율적으로 처리하며, 사용자 경험과 코드 품질을 동시에 개선하는 효과적인 해결책이 되었다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[WebRTC DataChannel로 실시간 미디어 상태 공유하기]]> https://shipfriend.dev/posts/webrtc-datachannel로-실시간-미디어-상태-공유하기 https://shipfriend.dev/posts/webrtc-datachannel로-실시간-미디어-상태-공유하기 Fri, 27 Jun 2025 04:58:01 GMT 이 글은 노션에서 마이그레이션된 글입니다. ![섬네일](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751001073266-%EC%A0%9C%EB%AA%A9%EC%9D%84%20%EC%9E%85%EB%A0%A5%ED%95%B4%EC%A3%BC%EC%84%B8%EC%9A%94_-001-6KGw7ZU1aviWmZ8zslVvAPNoh6kGeC.png) ## DataChannel이란? DataChannel은 WebRTC의 기능 중 하나로 수립된 RTCPeerConnection 사이에 DataChannel을 열고 해당 채널을 통해 서로 임의의 데이터를 주고받을 수 있게 해주는 기능이다. ### **공부하는 이유** WebRTC 화상회의를 구현했지만, 유저가 비디오를 끄거나 마이크를 끄고 켜는 것에 대한 상태 공유가 이루어지지 않고 있었다. 내가 마이크를 꺼도 상대방은 내가 마이크를 끈건지 말을 안하고 있는건지 분간이 안갈 수 있다고 생각되어 이런 기능을 필수로 구현해야겠다고 생각했다. ### **DataChannel의 주요 특징** - 저지연 데이터 전송 - 신뢰성 있는 전송 모드 지원 (reliable/unreliable) - 양방향 통신 - 다양한 데이터 타입 전송 가능 (문자열, 바이너리 등) ### createDataChannel 데이터 채널을 생성하는 함수로, PeerConnection의 메서드이다. ```tsx const channel = pc.createDataChannel('채널의 라벨', { 여긴 옵션이 들어간다. }); ``` ## 구현하기 dataChannel은 P2P 연결 간에 생성된다. 하지만 비동기 메서드이기 때문에 생성 후 바로 메시지를 보낼 수 없다. state가 open 인 경우에만 메시지를 보낼 수 있다. 그렇기 때문에 열자마자 바로 보내는 것이 안된다. 이를 해결하기 위해서는 peerConnection의 연결 생성과 종료를 위임받은 커스텀 훅에 아래 데이터 채널을 저장하는 ref 객체를 만들었다. 그리고 피어들의 미디어 상태를 저장할 수 있는 useState 상태를 만들어서 각 피어마다 미디어 상태를 저장하도록 했다. ```tsx const dataChannels = useRef<{ [peerId: string]: RTCDataChannel }>({}); const [peerMediaStatus, setPeerMediaStatus] = useState<{ [peerId: string]: { audio: boolean; video: boolean; }; }>({}); ``` 그리고 화상 회의에 다른 유저가 참가하여 PeerConnection을 생성할 때 데이터채널을 열고 dataChannel ref 객체에 저장한다. ```tsx const mediaDataChannel = pc.createDataChannel("media-status", { ordered: true, }); mediaDataChannel.onopen = () => { dataChannels.current[peerSocketId] = mediaDataChannel; }; mediaDataChannel.onclose = () => { console.log("Media data channel closed."); }; // DataChannel 해보자 pc.ondatachannel = (event) => { const channel = event.channel; channel.onmessage = (e) => { const data = JSON.parse(e.data); console.log(data); const { type, status } = data; if (type === "audio") { if (status) { console.log("상대방의 오디오가 켜졌습니다."); setPeerMediaStatus((prev) => ({ ...prev, [peerSocketId]: { audio: true, video: prev[peerSocketId].video ?? true, }, })); } else { console.log("상대방의 오디오가 꺼졌습니다."); setPeerMediaStatus((prev) => ({ ...prev, [peerSocketId]: { audio: false, video: prev[peerSocketId].video ?? true, }, })); } } else if (type === "video") { // 상대방의 오디오가 켜졌을 때의 처리 if (status) { console.log("상대방의 비디오가 켜졌습니다."); setPeerMediaStatus((prev) => ({ ...prev, [peerSocketId]: { audio: prev[peerSocketId].audio ?? true, video: true, }, })); } else { console.log("상대방의 비디오가 꺼졌습니다."); setPeerMediaStatus((prev) => ({ ...prev, [peerSocketId]: { audio: prev[peerSocketId].audio ?? true, video: false, }, })); } } }; }; ``` 이렇게 데이터 채널을 생성한 뒤에 아래 코드로 피어 간 존재하는 모든 데이터채널에 메시지를 보내는 함수를 만들어서 사용했다. 이렇게 하면 위 코드에서 onmessage 이벤트로 수신된 메시지를 처리할 수 있다. ```tsx const sendMessageToDataChannels = (message: DataChannelMessage) => { Object.values(dataChannels.current).forEach((channel) => { channel.send(JSON.stringify(message)); }); }; sendMessageToDataChannels({ type: "video", status: true, }); ``` 메시지를 통해 업데이트된 peerMediaStatus는 피어들의 비디오 컴포넌트를 렌더링할 때 사용되어 실시간으로 마이크나 비디오의 상태를 서버를 경유하지 않고 공유할 수 있게 되었다! ## 결과 WebRTC 데이터채널을 활용하여 화상 스터디를 개선하기, 한번 RTC PeerConnection이 수립되면 DataChannel을 통해 서버 경유 없이도 피어 간 직접 통신이 가능한 점을 활용했다. 이를 통해 팀원들의 비디오/마이크 상태 변경을 실시간으로 공유할 수 있게 되었다! ![미디어온오프 상태공유.gif](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1751000269431-%EB%AF%B8%EB%94%94%EC%96%B4%EC%98%A8%EC%98%A4%ED%94%84%20%EC%83%81%ED%83%9C%EA%B3%B5%EC%9C%A0-uo6PVOHvQIVrCOYlGdeA66y45SmFzG.gif)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[개발, 배포 환경의 Lighthouse 성능 점수 차이 왜 생기는 걸까?]]> https://shipfriend.dev/posts/development-production-환경의-lighthouse-성능-점수-차이-왜-생기는-걸까 https://shipfriend.dev/posts/development-production-환경의-lighthouse-성능-점수-차이-왜-생기는-걸까 Sun, 22 Jun 2025 05:44:45 GMT { throw new Error("버튼 클릭 에러!"); }; // 빌드된 JavaScript 코드 (bundle.js 2847번째 줄) const n=()=>{throw new Error("버튼 클릭 에러!")}; ``` 이 경우 원래 내가 작성한 코드가 변하기도 하고, 소스 라인의 수 조차 달라진다. 만약 특정 코드에서 오류를 발생시키고 있다고 가정할 때, 브라우저에서 실행되는 오류 코드의 위치와 실제 내가 작성한 코드의 위치가 불일치 할 가능성이 생긴다. 이를 해결하기 위해 개발 환경에서는 소스맵이라는 매핑 정보를 관리한다. 소스맵이 있다면 브라우저에서 디버깅을 할 수 있게 되는 것이다. #### 개발용 React React로 개발을 하다보면 한 번쯤 경험해보는 문제가 있다. 바로 React의 Strict Mode이다. 이건 개발할 때 불필요한 요청이나 렌더링 등을 빠르게 캐치하기 위한 목적으로 만들어져있다. 주요 특징으로는 콘솔 로그가 두 번 찍힌다는 특징이 있다. 그 외에도 추가적인 경고 로직, 검증 로직 등이 개발환경에서만 지원된다. #### 최적화되지 않은 번들 이 글에서 가장 중요한 내용이다. 개발 환경에서는 번들이 최적화되어있지 않다. 즉, 압축이나 트리 쉐이킹 같은 최적화 기법이 사용되지 않은 환경이라는 뜻이다. ### 프로덕션 환경 (배포 환경) 개발 환경에서는 주로 디버깅에 치중되어있는 모습을 볼 수 있었다. 그렇다면 성능이 중요시되는 배포 환경에서는 어떨까? #### 코드 압축 성능이 중요하기 때문에 띄어쓰기 한 칸 조차 아끼는 모습을 볼 수 있다. ```ts // 압축 전 (개발 환경) function handleUserAuthentication(username, password) { if (!username || !password) { throw new Error('Username and password are required'); } return authenticateUser(username, password); } // 압축 후 (프로덕션) function h(u,p){if(!u||!p)throw Error('Username and password are required');return a(u,p)} ``` 위 코드처럼 아예 코드를 읽기 힘들게 만드는 코드 난독화 기술도 적용할 수 있다. #### **✨트리 쉐이킹** 개인적으로 가장 중요하다고 생각되는 부분이다. 트리 쉐이킹은 말 그대로 나무를 흔드는 작업이다. 개발 환경에서는 사용하지 않는 코드도 모두 가지고 있지만, 배포 환경에서는 쓰지 않는 코드, 함수, 컴포넌트 등을 모두 제거한다. ```ts // 트리 쉐이킹 예시 추가 import { Button, Modal, Tooltip, DatePicker } from 'antd'; // 실제로는 Button만 사용 // 개발 환경: 모든 컴포넌트 로드 // 프로덕션: Button만 번들에 포함 ``` 이렇게 하면 개발 환경에서는 편의성과 디버깅 용이성을, 배포 환경에서는 성능을 모두 챙길 수 있게 된다. 여담으로 최근에 학교 과제로 유니티 게임을 만들어야 할 일이 있었는데, 욕심으로 3D 게임을 만들기로 했다. 이때, 에셋 포함 프로젝트 파일이 8GB나 되었었다.. (초저퀄 주제에..) 하지만 빌드 후 게임 파일은 400MB 밖에 되지 않았다. 사용하지 않는 에셋 등과 빌드 최적화로 95%나 없어진 것이다. 웹에서도 마찬가지라고 생각이 들었다. #### 번들러 최적화 React 생태계의 번들러는 크게 Webpack, Vite 두가지가 떠오른다. 두 번들러 모두 빌드 과정에서 최적화를 수행하지만 내부적으로 사용하는 기술들이 달라진다. 두 번들러의 차이점에 대해서는 다루지 않지만 모두 코드 스플리팅, 트리 쉐이킹, 코드 압축 등이 최적화를 수행한다. ## 확인해보자 개발 환경에서 블로그 디테일 페이지의 Lighthouse 점수이다. 보다시피 성능 점수가 50점 아래로 떨어져있는 것을 볼 수 있다. ![개발환경](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750523089302-%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202025-06-21%20230421-hTlEklPeK9GZGC0k009pWn8IicJJQw.png) 측정항목도 Total Blocking Time이 1250 ms가 넘어가는 모습이다. ![개발환경 측정항목](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750569520212-%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202025-06-22%20141401-zz64XRMFN4dvwbgtuXiDFikhUwkGJ7.png) 다음은 배포 환경이다. 아직 개선해야 할 것들이 있지만, 전반적으로 성능 점수가 25점 이상 올랐고, 권장사항 점수도 채워진 걸 볼 수 있다. ![배포환경](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750523093815-%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202025-06-22%20012352-YdawiHm9Nb98bBRiC3tZJNlVjjC8jg.png) 개발환경과는 다르게 Total Blocking Time이 크게 줄었고, Speed Index 등 다른 지표들도 같이 감소한 모습이 눈에 띈다. ![배포환경 측정항목](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750569538447-%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202025-06-22%20141516-lCyk20CHTZbJYHYf3yimLWDRpMAYLQ.png) ### 트리맵 비교 위처럼 트리맵도 비교해보자. 트리맵은 웹사이트를 구성하는 JavaScript 번들의 크기를 시각적으로 보여주는 목적으로 사용된다. 큰 사각형일 수록 차지하는 용량을 의미해서 쉽게 확인할 수 있는 구조로 되어있다. 먼저 개발환경 부터 보자, 가장 먼저 눈에 띄는 점은 쪼개지지 않은 사각형과 오른쪽 상단의 44Mb라는 용량이다. ![개발환경 트리맵](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750569674743-%EB%B3%80%ED%99%98%EB%90%9C_%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD%ED%8A%B8%EB%A6%AC%EB%A7%B5-Rkn430rlJV0MhNj36VKQkM6rjtWyn8.webp) 다음은 배포환경의 트리맵이다. 개발환경과는 달리 여러개의 사각형으로 쪼개져있고, 무엇보다 용량의 크기가 2Mb 수준으로 매우 작다는 점이다. ![배포환경 트리맵](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1750569671371-%EB%B3%80%ED%99%98%EB%90%9C_%EB%B0%B0%ED%8F%AC%ED%99%98%EA%B2%BD%20%ED%8A%B8%EB%A6%AC%EB%A7%B5-8ewgx8CHUaDknZovcRGJ3Fna3lEaqs.webp) - 파일 크기 최적화로 전체 번들이 44Mb 수준에서 2Mb 수준으로 약 94% 감소했다. - 코드 스플리팅 최적화로, 기존 코드가 더 작은 여러개의 청크로 분할되어 필요할 때만 로드되도록 만들어졌다. ## 마무리 지금까지 살펴본 개발 환경과 배포 환경의 구조적 차이로 인해 localhost 개발 환경에서 성능 측정을 했을 때와 배포 환경의 차이를 알아볼 수 있었다. Vite 같은 번들러의 도움으로 빌드 설정을 크게 고민해보지 않았던 것 같다는 생각이 들었다. 빌드 과정에서 일어나는 최적화를 공부하면 프론트엔드에 대해서 더 이해할 수 있지 않을까 하는 생각이 든다. 이번 글을 통해 개발 환경에서의 성능 측정이 얼마나 실제와 다를 수 있는지 확인할 수 있었다. #### **핵심 포인트:** - 성능 측정은 반드시 프로덕션 환경에서 - 트리 쉐이킹의 놀라운 최적화 효과 (94% 크기 감소) - 로컬에서도 `npm run build && npm start`로 확인 가능 ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[Schema hasn't been registered for model 문제 해결하기]]> https://shipfriend.dev/posts/schema-hasn-t-been-registered-for-model-문제-해결하기 https://shipfriend.dev/posts/schema-hasn-t-been-registered-for-model-문제-해결하기 Sun, 01 Jun 2025 10:42:48 GMT sjw4371@naver.com (개발자 서정우) <![CDATA[티스토리 블로그 확장프로그램 StoryHelper 개발 회고]]> https://shipfriend.dev/posts/티스토리-블로그-확장프로그램-storyhelper-개발-회고 https://shipfriend.dev/posts/티스토리-블로그-확장프로그램-storyhelper-개발-회고 Sun, 25 May 2025 13:00:29 GMT sjw4371@naver.com (개발자 서정우) <![CDATA[SSG 렌더링으로 Vercel 콜드스타트 문제 해결하기]]> https://shipfriend.dev/posts/직접-해보면서-깨닫는-ssr과-ssg-차이 https://shipfriend.dev/posts/직접-해보면서-깨닫는-ssr과-ssg-차이 Fri, 02 May 2025 06:07:32 GMT ({ slug: post.slug, })); } ``` ## 빌드 로그 확인 빌드하게 되면 아래와 같은 빌드 로그를 얻을 수 있다. route 옆에 직관적인 기호로 어떤 방식이 적용되었는지 보여준다. 잘보면 /posts/[slug]에 색이 칠해져있는 것으로 SSG가 적용되었음을 알 수 있다! ```plain ├ ƒ /portfolio/[slug] 11.9 kB 136 kB ├ ○ /posts 7.96 kB 137 kB ├ ● /posts/[slug] 390 kB 518 kB ├ ├ /posts/next-js로-나만의-블로그-만들기 ├ ├ /posts/블로그-cls-성능-최적화하기 ├ ├ /posts/내가-만드는-블로그로-알아보는-seo-최적화 ├ └ [+13 more paths] ├ ○ /robots.txt 0 B 0 B ├ ○ /rss 0 B 0 B ├ ○ /series 2.36 kB 127 kB └ ○ /sitemap.xml 0 B 0 B + First Load JS shared by all 87.7 kB ├ chunks/7023-0674f41d3955597f.js 31.6 kB ├ chunks/fd9d1056-d060727c397bec1b.js 53.6 kB └ other shared chunks (total) 2.49 kB ○ (Static) prerendered as static content ● (SSG) prerendered as static HTML (uses getStaticProps) ƒ (Dynamic) server-rendered on demand ``` 빌드 시점에 정적인 페이지로 바꿔주는 과정이 필요하기 때문에, 글이 많아지면 필연적으로 빌드 시간이 길어진다고 한다. ## 결과 얼마나 개선이 되었는지를 확인하기 위해 SSG 도입 전 빌드 파일과 도입 후 빌드 파일 간의 로딩 속도를 확인해보자. ### 개선 전 개선 전 데이터로는 1.75초가 걸린다. 로컬 환경에서 production 빌드를 실행시킨 것이기 때문에 성능상으로는 배포환경과 같지만, 다른 점이라면 vercel의 콜드 스타트로 인해 아래 1.75초에 오버헤드가 더 붙는다는 점이다. ![개선 전](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1754902454120-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-08-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.53.50-HTsLGSz3Q3G0u4a3eisdLeKnOWu0Aq.png) ### 개선 후 개선 후 데이터를 보자. 122ms로 거의 15분의 1이 된 모습이다. 확실한 비교를 위해 캐시 없이 비교했다. ![개선 후](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1754902448416-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-08-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.52.25-cCRlAXBpoufcjPV5iBhBa6ZoE7Kwk3.png) 이제 SSG로 서빙이 되기 때문에 이전의 SSR 방식보다 더 빠르게 페이지가 로딩이 되는 것을 확인할 수 있다. 백엔드를 거치지 않기 때문에 콜드 스타트 문제도 없다. --- 답은 **SSG로 빌드된 사이트에 새 콘텐츠를 추가하면 그 콘텐츠는 다음 빌드 시점까지 사이트에 반영되지 않는다.** 그렇지만 NextJS에서는 이런 문제를 해결하기 위해 ISR, On Demanding Revalidation 등의 기능을 지원한다. 이론적으로 SSG만 설정하고 별도의 ISR이나 On-demanding 설정을 하지 않는다면 새로운 컨텐츠에 대한 정적 페이지는 생성이 되지 않아야 한다. *그러나 새로운 글을 발행했을 때 SSG로 문서가 생성되는 것을 확인했다. 찾아보고 여러가지로 생각해본 결과 **Vercel에서 자동으로 ISR을 지원**해주는 것이라고 결론을 지었다.* 왜냐하면 새로운 글에 대해서는 HTML이 생성되었지만(새로운 route가 생겼으므로), 이미 생성된 글에 대한 수정 사항이 반영이 되지 않는 것을 보면 명시적으로 ISR 설정을 안했기 때문에 반영이 안된다고 판단했다. 이걸 해결하기 위해 ISR을 도입하는 것을 고려해야겠다. ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[FingerPrintJS로 조회수와 좋아요 기능 만들기]]> https://shipfriend.dev/posts/fingerprintjs로-조회수와-좋아요-기능-만들기 https://shipfriend.dev/posts/fingerprintjs로-조회수와-좋아요-기능-만들기 Sat, 19 Apr 2025 08:03:46 GMT { const { postId } = await request.json(); const fingerprint = request.headers.get('X-Fingerprint') || ''; if (!postId) { return new Response('postId가 필요합니다.', { status: 400 }); } if (!fingerprint) { return new Response('Fingerprint가 필요합니다.', { status: 400 }); } const existingLike = await View.findOne({ postId, fingerprint }); if (existingLike) { const viewCount = await View.countDocuments({ postId }); return Response.json( { message: '이미 조회한 유저입니다.', viewCount }, { status: 203 } ); } else { const result = await View.create({ postId, fingerprint, }); const viewCount = await View.countDocuments({ postId }); if (result) { return Response.json( { message: '조회수 증가 성공', viewCount }, { status: 200 } ); } else { return Response.json( { message: '조회수 증가 실패', viewCount }, { status: 500 } ); } } }; ``` ### FingerPrint 생성하기 (feat. zustand) fingerprint를 쉽게 만들어주는 [@fingerprintjs/fingerprintjs](https://www.npmjs.com/package/@fingerprintjs/fingerprintjs)를 사용했다. 간편하게 핑거프린트를 생성해주는 라이브러리이다. 이렇게 생성한 핑거프린트는 유저가 여러개의 글을 읽는 경우 매번 생성되는 것은 리소스 낭비라고 판단했다. 그래서 한번 생성하면 전역상태로 관리하고, 유저가 다시 들어와도 사용할 수 있도록 localStorage에 저장되는 persist 미들웨어도 사용하기로 결정했다. ```ts interface FingerprintState { fingerprint: string; isLoading: boolean; error: string | null; initialize: () => Promise; } const useFingerprintStore = create( persist( (set, get) => ({ fingerprint: '', isLoading: true, error: null, initialize: async () => { if (get().fingerprint) { set({ isLoading: false }); return; } try { const fp = await FingerprintJS.load(); const result = await fp.get(); const visitorId = result.visitorId; set({ fingerprint: visitorId, isLoading: false, }); } catch (error) { set({ error: error instanceof Error ? error.message : '알 수 없는 오류', isLoading: false, }); console.error('Fingerprint 생성 오류:', error); } }, }), { name: 'fingerprint-storage', } ) ); ``` 이렇게 만든 전역 상태 store 코드를 사용하는 useFingerprint 커스텀 훅도 하나 더 만들어서, 캡슐화하고 외부에서 사용하는 것들만 노출시키는 방법을 사용했다. fingerprint가 필요하면 아래처럼 쉽게 꺼내 쓸 수 있게 된 것이다. ```ts const { fingerprint } = useFingerprint() ``` 이렇게 하고 나서는 프론트엔드에서 글을 조회할 때, 조회수을 올리는 요청을 fingerprint와 함께 보내고, 서버에서는 중복 조회인지를 체크하고 조회수를 올리거나 유지하는 등의 행동을 취한다. ## 좋아요 기능은 좋아요 기능은 조회수와 대부분 코드가 같다. 다른 점은 좋아요는 delete 메서드를 만들어 좋아요 취소하는 API를 만들어둔 점과 프론트에서 처리하는 방식이 다르다는 점이다. 그 외에 fingerprint를 헤더로 받고 체킹하는 과정은 조회수와 같다. ## 완성된 모습 ![완성본](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1745049754466-%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-04-19%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.02.13-3Ata7805edjMFlZYC85m3ueZcNYhc6.png) 다음에는 댓글도 커스텀으로 만들어봐야겠다고 생각했다. ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[프리뷰 | 네트워크 기반 동적 품질 조절 기능 개발 3편]]> https://shipfriend.dev/posts/프리뷰-네트워크-기반-동적-품질-조절-기능-개발-3편 https://shipfriend.dev/posts/프리뷰-네트워크-기반-동적-품질-조절-기능-개발-3편 Wed, 09 Apr 2025 08:32:23 GMT **필요한 이유?** > > `ideal` 대신 고정 값을 사용하기 위한 `exact` 라는 항목이 존재한다. 하지만 만약 exact로 1920 x 1080 의 FHD 해상도를 지정한다면 어떻게 될까? 유저의 미디어 장치가 FHD 화질을 지원한다면 해당 해상도로 출력이 가능하다. > > 그렇다면 지원하지 않는 장치일 경우? 해본 결과 `OverconstrainedError` 라는 에러를 반환한다. ## 동적으로 조절하기 위 함수만 수정하면 초반에 얻어오는 스트림에만 적용되기 때문에 useEffect를 사용해서 네트워크 품질이 바뀔 때마다 새롭게 적용해주어야한다. 아래 코드는 `useNetworkStore`에서 현재 네트워크 품질 프리셋 정보 (ex: ultra)를 가져온다. 이후 사전 정의된 프리셋을 가져오고 stream 객체의 video 트랙에 `applyConstarints` 메서드를 활용해 적용해준다. ```ts useEffect(() => { // 현재 네트워크 품질이 변경될 때마다 비디오 품질 조정하는 이펙트 const currentQuality = useNetworkStore.getState().currentNetworkQuality; if (currentQuality && streamRef.current) { const videoTrack = streamRef.current.getVideoTracks()[0]; if (videoTrack) { const preset = QualityPreset[currentQuality]; videoTrack .applyConstraints({ width: { ideal: preset.video.width }, height: { ideal: preset.video.height }, frameRate: { ideal: preset.video.frameRate, max: preset.video.frameRate + 5, }, }) .catch((error) => { console.warn("비디오 제약 조건 적용 실패:", error); }); // // WebRTC 비트레이트 설정 (피어 연결이 있는 경우) if (peerConnections.current) { for (const peerConnection of Object.values(peerConnections.current)) { const sender = peerConnection .getSenders() .find((s) => s.track?.kind === "video"); if (sender) { const parameters = sender.getParameters(); if (!parameters.encodings) { parameters.encodings = [{}]; } parameters.encodings[0].maxBitrate = preset.video.videoBitrate * 1000; sender.setParameters(parameters).catch((error) => { console.warn("비디오 비트레이트 설정 실패:", error); }); } } } console.log( `네트워크 품질 변경: ${currentQuality}, 비디오 설정 업데이트됨` ); } } }, [useNetworkStore.getState().currentNetworkQuality]); ``` `applyConstraints`가 있는지 모르고 처음에는 설마 품질 바뀔 때마다 새롭게 트랙 가져와야하나? 라는 절망에 빠질 뻔 했으나 다행히 금방 해당 메서드를 발견했다!! 이제 전역 네트워크 품질 상태를 구독하는 useEffect가 만들어졌다. 네트워크 품질이 달라지면 실행되어 품질을 조절해준다. ## 테스트 테스트에 앞서 내 웹캠은 해상도도 낮고 최대 프레임도 30프레임이라 적용되는지를 확인하기 위해 medium 해상도의 비율을 다르게 설정해서 테스트했다. 테스트 영상은 [링크](https://youtu.be/3pD3di-fKoI)를 통해 볼 수 있다. (youtube 임베드 기능을 만들어야겠다..) 자막이랑 확대 정도 편집을 10분 뚝딱해서 가시성은 좀 안좋은 것 같다.. ㅎ ![테스트 영상 미리보기](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1744186964736-%EB%B3%80%ED%99%98%EB%90%9C_Screenshot%202025-04-09%20at%2017.22.27-u7CowebiIl9YZJIqU8FsTFfEqEu2MM.webp) 미디어 품질이 ultra -> high -> medium -> low -> very-low 로 내려가는데, medium일 때만 해상도 비율이 다른 것을 볼 수 있다. 해상도나 프레임률도 내려가긴 하지만 장치 자체가 좋은 장치가 아니라 티가 잘안나서 해상도 비율로 테스트를 했다. ## 결과와 느낀 점 ### 결과 결과적으로는 사용자의 네트워크 품질이 낮을 때는 일부러 미디어의 품질을 낮추는 방식으로 오디오를 최대한 살리는 것이 중요하다고 느꼈다. **네트워크 품질을 모니터링**하고 이걸 기반으로 어떤 **constraints를 적용**해 **사용자 경험을 향상**시킬 수 있었다. ### 느낀 점 네부캠 프로젝트를 하면서 **멘토님이 기술적으로 고도화한다면 해볼만한 주제**라고 해주셔서 이전부터 계획만 세워뒀었는데 이렇게 다 만들고 나니 정말 뿌듯하다. **다양한 상황을 고려한다**라는 것 자체가 프론트엔드 개발에서 많이 중요한 것 같다고도 느꼈고, 네트워크 지표를 공부하면서 CS가 이렇게 쓰일 수 있겠구나 라는 인사이트를 체득할 수 있어서 좋았다. 이 기능을 만들기 위해서 네트워크 품질 지표 공부도 하고, 나름대로 계획도 세워서 구현했는데 원하는대로 잘 작동이 된 것 같아서 기분이 좋다. 기능을 구현하기 위한 학습을 했지만 네트워크의 다른 부분들도 알아두면 좋을 것 같은 내용들이 많이 있었기 때문에 더 공부해야할 것 같다고 느꼈다. **네트워크 기반 동적 품질 조절 기능 개발 END** ]]> sjw4371@naver.com (개발자 서정우) <![CDATA[리드미용 블로그 최신 글 뱃지 만들기]]> https://shipfriend.dev/posts/리드미용-블로그-최신-글-뱃지-만들기 https://shipfriend.dev/posts/리드미용-블로그-최신-글-뱃지-만들기 Wed, 09 Apr 2025 07:24:56 GMT " width="${width}" height="${height}" fill="none"> 최신 글 | ShipFriend Tech Blog ${escapeXML(title)}`; if (subTitle) { // 부제목이 있는 경우 svg += ` ${escapeXML(subTitle)} ${date}`; } else { // 부제목이 없는 경우 svg += ` ${date}`; } svg += ``; return svg; } ``` 이렇게 생성하고 나서는 아래와 같은 식으로 최신 글을 DB에서 가져오고, SVG를 생성할 때 넣어주고 나서 response로는 `Content-Type`을 image/svg+xml로 해두고 svg를 반환하도록 만들었다. ```ts await dbConnect(); const latestPost = await Post.findOne({}) .select('title subTitle slug date') .sort({ date: -1 }) .limit(limit); const svg = generateBadgeSVG(title, subTitle, dateStr); return new Response(svg, { headers: { 'Content-Type': 'image/svg+xml', 'Cache-Control': 'no-cache, no-store, must-revalidate, max-age=0', }, }); ``` ## 리다이렉트 API 위 처럼 만든 svg는 정말 이미지와 같기 때문에 이미지를 클릭했을 때 이동할 수 있는 기능을 만드려면 항상 최신글로 리다이렉트해주는 api를 만드는 것이 중요하다. 혹시 나중에 블로그 주소를 이전할 수도 있으니 리다이렉트하는 url은 환경변수를 사용하도록 만들었다. 최신 글을 가져와 해당 글에 slug를 사용해서 리다이렉트 url을 만든다. NextResponse 객체의 redirect 메서드를 사용해서 최신 글로 리다이렉트 시킨다. 이 api는 /api/redirect/recent로 만들었고 해당 api에 접근하며 항상 최신 글 주소로 리다이렉트해준다. ```ts await dbConnect(); const pageUrl = process.env.NEXTAUTH_URL; // 최신 글 1개 가져오기 const latestPost = await Post.findOne({}).sort({ date: -1 }).select('slug'); // 최신 글로 리다이렉션 return NextResponse.redirect( new URL(`${pageUrl}/posts/${latestPost.slug}`) ); ``` ### 캬 금방 만들었지만 만들길 잘 한 것 같다. [![최신 글](https://shipfriend.vercel.app/api/posts/recent)](https://shipfriend.vercel.app/api/redirect/recent)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[요청을 캐시해서 돈을 아껴보자]]> https://shipfriend.dev/posts/요청을-캐시해서-돈을-아껴보자 https://shipfriend.dev/posts/요청을-캐시해서-돈을-아껴보자 Sat, 05 Apr 2025 06:48:20 GMT 형식으로 몇초 뒤에 만료될 것인지를 적어준다. s-max-age는 브라우저 캐시가 아닌 공유 캐시에 저장되는 시간을 지정해주는 것이다. 위에서 잠깐 설명한 프록시 캐시, CDN 캐시에 저장되는 시간이다. `max-age=3600` 이렇게 지정하면 3600초, 즉 1시간 동안 캐시에 저장된다는 의미이다. ### 캐싱 검증 `must-revalidate`이나 `proxy-revalidate` 같은 것들은 캐시가 만료되었을 시에 어떤 작업을 할 것인지에 대한 정책이다. `must-revalidate`는 캐싱된 응답의 max-age가 아직 만료되지 않았을 경우에는 그냥 해당 응답을 사용하고 만약 만료되었을 경우에는 무조건 서버에 연결해서 재검증해야한다는 의미이다. `proxy-revalidate`는 브라우저 같은 개인 캐시와는 상관없이 프록시 캐시에 저장된 응답이 만료되었을 경우 재검증 받아야한다는 의미이다. ## 어떻게 바뀌었나 캐시 정책 적용 전에는 항상 새로운 응답을 불러와서 사용한다. ![적용 전](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743835159006-%EB%B3%80%ED%99%98%EB%90%9C_Screenshot%202025-04-05%20at%2015.07.43-Z5DeAFuXUSmv3CRF1dm280Uf3IJQr2.webp) 적용 후에는 응답 헤더에 아까 정한 `Cache Control` 헤더가 적혀있는 것을 볼 수 있다. 그리고 상태 코드에 보면 200 코드 옆에 (디스크 캐시에서)라고 적혀있다. **`캐시에서 응답을 불러온 것이다!!!`** ![적용 후](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743835161900-%EB%B3%80%ED%99%98%EB%90%9C_Screenshot%202025-04-05%20at%2015.08.05-IOH2aSNJ2pKfhtOs3lfLrOAyaZgWUg.webp) ## 캐시를 적용하면 무엇이 좋아지나 ### 장점 캐시를 적용하면 좋은 점이 많다. - 성능 향상, 이전에 받은 리소스를 재활용하기 때문에 페이지 로딩 속도가 빨라진다. - 네트워크 비용 효율성, 돈을 아낀다는 제목이 여기에서 나온다. vercel의 경우 한달 100GB 트래픽을 지원하는데 이미지를 매번 새로 가져온다면 그만큼 대역폭 소모량도 많아질 것이다. 캐시로 이걸 방지할 수 있겠다. - 오프라인 지원, 가끔 인터넷이 끊겨도 유튜브 영상이나 블로그 글을 볼 수 있는 것도 캐시 덕분이다. ### 단점 물론 장점만 있는 것은 아니다. 정책을 잘 지정하지 못한다면 문제가 생길 수도 있다. - 데이터 신선도, `max-age` 같은 옵션을 너무 오래 지정하게 되면 서버에서는 데이터가 이미 다른 데이터로 변경되었음에도 클라이언트에서는 이전 응답을 재활용하게 된다. - 보안, 개인 정보나 로그인해야만 얻을 수 있는 리소스에 대해서 캐시하게 되면 유출 가능성에 대해서도 고려해야한다. - 디버깅 어려움, 이건 개발자에게만 해당되는 일이지만 가끔 개발을 하다보면 예상치 못한 일들이 일어날 때 캐시 초기화를 먼저 해보라고 하는 글들을 흔하게 볼 수 있다. 캐시는 직관적으로 보기 어렵기 때문에 디버깅을 어렵게 할 수 있다는 점이 있다. 이런 단점들에 대해서 생각하면서 캐시 정책을 결정해야 장점만 이용할 수 있을 것 같다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[프리뷰 | 네트워크 기반 동적 품질 조절 기능 개발 2편]]> https://shipfriend.dev/posts/프리뷰-네트워크-기반-동적-품질-조절-기능-개발-2편 https://shipfriend.dev/posts/프리뷰-네트워크-기반-동적-품질-조절-기능-개발-2편 Mon, 31 Mar 2025 13:59:09 GMT { const averageStats = calculateAverageStats(5); if (!averageStats) return null; const { jitter, rtt, packetsLossRate, bandwidth } = averageStats; const bandwidthMbps = bandwidth / 1000 / 1000; const rttMs = rtt * 1000; // 초를 밀리초로 변환 const packetLossPercent = packetsLossRate * 100; const jitterMs = jitter * 1000; // 초를 밀리초로 변환 let qualityScore = 0; if (bandwidthMbps >= 2.5) qualityScore += 40; else if (bandwidthMbps >= 1.0) qualityScore += 30; else if (bandwidthMbps >= 0.5) qualityScore += 20; else if (bandwidthMbps >= 0.25) qualityScore += 10; else qualityScore += 0; if (rttMs < 50) qualityScore += 25; else if (rttMs < 100) qualityScore += 20; else if (rttMs < 300) qualityScore += 15; else if (rttMs < 500) qualityScore += 5; else qualityScore += 0; if (packetLossPercent < 0.5) qualityScore += 25; else if (packetLossPercent < 2) qualityScore += 20; else if (packetLossPercent < 5) qualityScore += 15; else if (packetLossPercent < 10) qualityScore += 5; else qualityScore += 0; if (jitterMs < 10) qualityScore += 10; else if (jitterMs < 30) qualityScore += 8; else if (jitterMs < 50) qualityScore += 5; else if (jitterMs < 100) qualityScore += 2; else qualityScore += 0; if (qualityScore > 80) { return "ultra"; } else if (qualityScore > 60) { return "high"; } else if (qualityScore > 40) { return "medium"; } else if (qualityScore > 20) { return "low"; } else { return "very-low"; } }; ``` 점수를 20 점 단위로 자르고, 각각 ultra, high, medium, low, very-low 의 5단계로 나누었다. 3단계할까 5단계할까 고민했는데, 좀 더 드라마틱한 효과를 보기 위해서 5단계로 쪼개었다. ### 왜 안바뀌지..? 최근 5번의 평균을 내는 로직을 구현했는데 어째선지 최근 5회 보고서에 같은 값만 찍히는 버그가 있었다. 디버깅 후에 알아낸 사실은 ![콘솔 같은거 찍힘..](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743429105805-%EB%B3%80%ED%99%98%EB%90%9C_%EC%BD%98%EC%86%94%20%EA%B0%99%EC%9D%80%EA%B1%B0%EC%B0%8D%ED%9E%98-aPpV6l8OREcq2orKUYjEmMkS4dWBjz.webp) ```tsx const { networkStats, updateNetworkStats, setCurrentNetworkQuality, currentNetworkQuality, } = useNetworkStore(); const recentStats = networkStats.length > count ? networkStats.slice(-count) : networkStats; ``` 이 코드에 있었다. networkStats는 네트워크 데이터가 담기는 배열인데, 이렇게 계산하고 있었다. recentStats를 불러오는 로직은 틀리지 않았는데 이상하게 값이 변경되지 않았다. 그래서 찾아보니 useNetworkStore()를 구조분해해서 가져오는 networkStats는 이 훅이 마운트 될 때 캡쳐되고 바뀌지 않는다고 한다. 그러니까 나는 변경되지 않는 배열을 가지고 5회 평균을 내고 있었던 것이었다.. 그래서 `const networkStats = *useNetworkStore*.getState().networkStats;` 같은 형식으로 항상 새로운 값을 가져오도록 하여 해결했다. ## 네트워크 테스트 기존에 네트워크 테스트는 개발자도구에서 4G나 3G 속도로 제한하는 정도 밖에 해보지 않았다. 하지만 네트워크가 아닌 WebRTC 의 P2P 통신에서는 효과가 없는 것을 확인했다. 다른 네트워크 에뮬레이터 테스트 도구가 있을까 찾아봤다. 처음에는 js 라이브러리 중 찾아보려고 했는데 라이브러리를 사용하는 방법 보다는 외부에서 제어해주는 도구를 쓰는게 더 나을 것 같다고 판단했다. 그래서 찾아본 결과 clumsy라는 도구를 발견했다. 이 도구는 다양한 네트워크 지연 현상을 시뮬레이션하는 도구였다. 랙, 쓰로틀, 대역폭 제한 등의 다양한 상황을 조절해가면서 테스트할 수 있는 도구다. https://jagt.github.io/clumsy/index.html ![](https://jagt.github.io/clumsy/clumsy-demo.gif) 결과적으로 내가 원하는 것은 네트워크 품질이 안좋아지면 품질 프리셋이 낮아지는 것이다. 그래서 극한의 네트워크 상황을 테스트해야했다. 테스트에 사용한 설정은 아래와 같다. 전반적인 네트워크 품질을 떨어뜨려야했기 때문에 랙, 드랍, 쓰로틀을 걸어줬고, 대역폭을 제한하기 위해서 초당 200KB로 제한했다. ![나의 클럼시 세팅](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743429091390-%EB%B3%80%ED%99%98%EB%90%9C_%EB%82%98%EC%9D%98%20clumsy%20%EC%84%A4%EC%A0%95-PHfX1nreQhDXFTQkxhoaEfYzXLmSyF.webp) 해당 영상은 clumsy 테스트 하기 전과 후를 보여주는 영상 테스트이다. 테스트 하기 전에는 ultra 품질을 유지하다가, clumsy를 켜는 순간 low로 점점 떨어지는 모습을 볼 수 있다. [테스트 영상](https://youtu.be/IydfuO_AV7Y) ![클럼시 테스트 전](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743429392540-%EB%B3%80%ED%99%98%EB%90%9C_%ED%81%B4%EB%9F%BC%EC%8B%9C%EC%A0%84-n9XTx3tMyGZWQJJmoqiQUDAKwLwtfJ.webp) 화질이 좀 안좋은데 네트워크 품질이 ultra인 것을 볼 수 있다. 이건 클럼시 테스트를 하기 전의 상태이다. ![클럼시 테스트 후](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1743429395289-%EB%B3%80%ED%99%98%EB%90%9C_%ED%81%B4%EB%9F%BC%EC%8B%9C%ED%9B%84-3DEBah9VlKZj47RVvLSoLUyTIjSRKu.webp) 이 사진은 클럼시 테스트 시작 후 20초 정도가 지났을 때의 사진이다. 대역폭이 많이 떨어져서 네트워크 품질은 최하인 'Very-low'에 도달했다. 이제 네트워크 상태에 따른 품질을 조절하는 것은 모두 완성됐다. 여기서 계산 식만 조율해가면서 최적의 식을 찾으면 되는 정도만 남았다. 이 다음 글에서는 이렇게 결정된 프리셋 단계를 가지고 webrtc 비디오 컴포넌트에 적용하는 것을 해보려고 한다. 👻👻👻👻 > 다음 글 [프리뷰 | 네트워크 기반 동적 품질 조절 기능 개발 3편](/posts/%ED%94%84%EB%A6%AC%EB%B7%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B8%B0%EB%B0%98-%EB%8F%99%EC%A0%81-%ED%92%88%EC%A7%88-%EC%A1%B0%EC%A0%88-%EA%B8%B0%EB%8A%A5-%EA%B0%9C%EB%B0%9C-3%ED%8E%B8)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[블로그 API 최적화]]> https://shipfriend.dev/posts/블로그-api-최적화 https://shipfriend.dev/posts/블로그-api-최적화 Mon, 24 Mar 2025 05:04:52 GMT []).push({ seriesId: seriesId._id, } as QuerySelector); } const posts = await Post.find(searchConditions) .sort({ date: -1 }) .limit(10); return Response.json({ success: true, posts: posts }); } catch (error) { console.error(error); return Response.json( { success: false, error: '포스트 목록 불러오기 실패', detail: error }, { status: 500 } ); } } ``` 여기서 이런 검색 관련 기조는 유지한채 단순 플래그 하나로 가벼운 API로 만들어보려고 한다. 예를 들어 &light=true 같은 `searchParams` 를 사용해서 글의 세부 내용을 가져오지 않도록 하는 방식을 사용할 수 있을 것 같다. ## 최적화한 코드 query문을 변수로 빼고 isCompact 여부에 따라 property를 select해서 보내는 방식으로 최적화를 진행했다. 이 방법으로 이제 글목록을 불러올 때 글에 대한 content는 제외하고 보내준다. ```tsx const { searchParams } = new URL(req.url); const isCompact = searchParams.get('compact') === 'true'; let q = Post.find(searchConditions); if (isCompact) { q = q.select( 'slug title _id subTitle author date tags thumbnailImage seriesId timeToRead createdAt updatedAt' ); } const posts = await q.sort({ date: -1 }).limit(10); ``` 이렇게 수정한 API는 /posts 라우트에서 글 목록을 불러올 때와 글을 수정하기 위해 글 목록을 불러오는 admin 페이지에서 유용하게 사용되고 있다. 글이 좀 더 생기면 페이지네이션을 구현할 생각이다.]]> sjw4371@naver.com (개발자 서정우) <![CDATA[드래그 앤 드롭 기능 예제와 성능 최적화 🚀]]> https://shipfriend.dev/posts/드래그-앤-드롭-기능-예제와-성능-최적화 https://shipfriend.dev/posts/드래그-앤-드롭-기능-예제와-성능-최적화 Sun, 16 Mar 2025 09:01:57 GMT 이 글은 티스토리 블로그에서 이전된 글입니다. [원본 링크](https://oraciondev.tistory.com/entry/%EB%93%9C%EB%9E%98%EA%B7%B8-%EC%95%A4-%EB%93%9C%EB%A1%AD-%EA%B8%B0%EB%8A%A5-%EC%98%88%EC%A0%9C%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94%EA%B9%8C%EC%A7%80-%ED%95%B4%EB%B3%B4%EA%B8%B0) 최근에 드래그 앤 드롭 기능을 만들어보면서 느낀 점은 정말 재미있는 기능이라는 점인 것 같다! 이번에는 간단한 드래그앤드롭,DND 예제를 만들어보고, 그 후에 어떤 최적화를 할 수 있을까에 대해서 고민해보려고 한다. # 드래그 앤 드롭 기능 예제와 성능 최적화 🚀 일단 dnd 예제를 만들어야하는데, 초기에 필요한 세팅은 클로드의 도움을 받아서 작성했다. 프롬프트를 작성한 예시는 아래와 같다. > 간단한 드래그앤드롭을 만들기 위한 초기 html과 css만 만들어줘, 기능 구현은 하지 않고 만들어줘 > 이렇게 해서 만들어진 예시 화면이다. 디자인은 대충 디스코드 느낌 나게 만들어봤다. (색깔만) ![예제 사진](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1742115373567-converted_%E1%84%8B%E1%85%A8%E1%84%8C%E1%85%A6%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5-idOHjmuzdZqO64iJ0Q6ZUD1mYFr151.webp) ## 드래그 앤 드롭 기능 구현 dragover 성능 최적화까지 간단하게 설명하면 왼쪽에 있는 draggable한 아이템들을 드래그앤드랍으로 오른쪽의 dropzone으로 끌어다 놓으면 아이템을 움직일 수 있도록 구현되어 있다. 그리고 드래그한 상태로 마우스를 dropzone에 가져다 두면 미리보기가 반투명하게 생기도록 하는 기능을 구현해 뒀다. ![최적화 전](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1742115546955-requestAnimationFrame%20%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%92%E1%85%AA-RwY9bQWVMHnZzvxPmQ4KfTXv52NldE.gif) 최적화 전의 모습, 이벤트 핸들러가 엄청나게 호출되는 모습이다!! 😱 위 예제를 가지고 최적화를 해볼 계획이다. 일반적으로 드래그앤드랍에서는 성능적인 문제가 없을 것 같다. 하지만 미리보기를 띄우는 기능에서 dragover 이벤트를 활용하는데 이 이벤트는 클릭과 같이 단발성으로 끝나는 이벤트가 아니다. 드래그한 상태라면 무수히 많이 호출되는 이벤트가 바로 dragover이다. 다른 방법이 있을 수도 있지만 우선 내 예제에서는 dragover 이벤트 핸들러에서 계속해서 마우스가 위치한 좌표값을 비교하는 함수를 사용하기 때문에 이벤트 호출이 되면 될수록 성능적인 부담이 되는 구조이다. ## Drag 최적화 방법 1. throttle 다른 것보다 가장 먼저 떠오른 방법이다. 쓰로틀링과 같은 말을 어디선가 들어본 적 있을 수 있는데 컴퓨터 하드웨어 등의 분야에서 온도가 너무 올랐을 때 발열량을 줄이기 위해 일부러 클럭(작동속도)을 낮추는 등의 기술을 말한다. 이것처럼 드래그 앤 드롭 과정에서 발생하는 수많은 이벤트 핸들러의 호출을 강제로 일정 간격을 두고 실행이 되게끔하는 것이 throttle 최적화의 핵심이다. 리액트의 lodash 같은 라이브러리에서도 많이 사용하는 함수인데, 직접 구현해 보면 아래와 같다. 처음 보면 이해하기 어려울 수 있는데, 그냥 매개변수로 함수와 시간간격을 받아서 시간간격마다 함수가 실행되도록 제한하는 함수이다. ```tsx const throttle = (func: (...args: any[]) => void, gapTime: number) => { // func 지연할 함수, gapTime 지연시간 간격 let lastTime: NodeJS.Timeout | null = null; return (...args: any[]) => { if (lastTime) return; lastTime = setTimeout(() => { func(...args); lastTime = null; }, gapTime); }; }; ``` 그렇다면, 어떻게 적용할 수 있을까 아래 예시코드처럼 적용할 수 있다. 처음에는 전체 핸들러를 throttle 함수로 감싸서 이벤트 핸들러 발생을 지연시켰다. 이렇게 하면 dragover 이벤트 핸들러를 100ms (예시)에 한번 실행하도록 할 수는 있지만, 정작 중요한 Drop 이벤트가 발생하지 않는 참사가 일어난다. 이벤트 핸들러 자체를 지연시키면, 지연되는 동안(throttle에서 강제로) drop 이벤트가 호출돼도 drop 핸들러가 발동하지 않는다. 그렇다면 아래의 예시코드와는 어떤 차이가 있을까? 아래의 예시코드는 e.preventDefault()와 e.stopPropagation()을 제외한 나머지 미리보기 렌더링 로직을 별도의 함수로 분리하고 해당하는 함수에 throttle을 적용시킨 모습이다. 이렇게 하면 이벤트 핸들러는 그대로 많이 호출이 되지만, 실질적인 성능을 요구하는 작업은 딜레이를 할 수 있기 때문에 drop 이벤트의 발생도 막지 않으면서 성능을 요구하는 작업은 최적화를 진행할 수 있었다. ```tsx const dragOverHandler = (e: DragEvent) => { e.preventDefault(); e.stopPropagation(); throttledDragOver(e); }; const throttledDragOver = throttle((e: DragEvent) => { const target = e.target as HTMLElement; const closest = target.closest(".drop-zone"); if (closest) { // dragover 되고 있는 위치가 drop-zone일 때 const elements = [...closest.querySelectorAll(".item")] as HTMLElement[]; // findIndex는 현재 마우스의 위치에 따라 어디에 미리보기를 넣을지 그 인덱스를 계산하는 함수 const index = findIndex(elements, e.y); // 미리보기 Element const preview = document.querySelector(".place") as HTMLElement; // 미리보기 넣기 if (elements.length - 1 === index) { closest.insertBefore(document.querySelector(".place"), null); } else { closest.insertBefore(document.querySelector(".place"), closest.children[index] || null); if (preview instanceof HTMLElement) { if (elements.length - 1 === index) { closest.appendChild(preview); } else { closest.insertBefore(preview, closest.children[index] || null); } } } }; // 16ms 마다 한번 실행되도록 제한 }, 16); ``` 그렇다면 최적화 후의 모습은 어떨까? 확연하게 호출량이 줄어든 것을 볼 수 있다. 쓰로틀로 지연시켰음에도 부드럽게 전환되는 미리보기 효과 ![쓰로틀 최적화 결과](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1742115613091-%E1%84%8A%E1%85%B3%E1%84%85%E1%85%A9%E1%84%90%E1%85%B3%E1%86%AF%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%92%E1%85%AA%E1%84%80%E1%85%A7%E1%86%AF%E1%84%80%E1%85%AA-bp04pNvXyy0zaKfuYGRQsQSyZXrGzD.gif) 쓰로틀의 지연 시간을 16ms로 한 이유는, 일반적으로 60hz 모니터는 1초에 60번의 화면을 그린다고 한다. 그렇다면 16ms * 60번이면 대충 1초가 되기 때문에 16ms가 넘지 않으면 화면이 전혀 끊겨보이지 않는다. 물론 60hz 모니터 이상이면 다를 수 있다. ## Drag 최적화 방법 2. requestAnimationFrame 이 메서드는 이전에 대충 따라서만 써봐서 학습이 필요했다. 알아보니 throttle처럼 작용한다. throttle은 개발자가 임의의 시간 간격을 넣어줘서 제한한다면, 이 requestAnimationFrame은 사용자의 주사율에 맞게 알잘딱으로 화면을 그려준다는 점이 큰 차이점이다. 그 외에도 백그라운드나 해당 요소가 숨겨지는 경우에 애니메이션을 멈추기 때문에 에너지 측면에서도 절약된다는 점이나, 브라우저 최적화로 가장 최적의 타이밍에 콜백함수를 실행하는 점이 특징이다. 그렇다면 이 기능을 써서 최적화를 해보자. 리퀘스트 애니메이션 프레임을 사용하면 쓰로틀 기법처럼 e.preventDefault()와 e.stopPropagation()을 따로 빼줄 필요가 없다. ```tsx const dragOverHandler = (e: DragEvent) => { e.preventDefault(); e.stopPropagation(); renderPreview(e); }; let raf: number | null = null; const renderPreview = (e: DragEvent) => { if (raf !== null) { cancelAnimationFrame(raf); } raf = requestAnimationFrame(() => { const target = e.target as HTMLElement; const closest = target.closest(".drop-zone"); if (closest) { const elements = [...closest.querySelectorAll(".item")] as HTMLElement[]; const index = findIndex(elements, e.y); console.log(index); const preview = document.querySelector(".place") as HTMLElement; // 미리보기 넣기 if (preview instanceof HTMLElement) { if (elements.length - 1 === index) { closest.appendChild(preview); } else { closest.insertBefore(preview, closest.children[index] || null); } } } raf = null; }); }; ``` raf는 requestAnimationFrame의 id 값이 들어가거나 null 값을 가진다. 만약 raf가 id 값을 가지고 있는 상태라면(하나의 프레임이 그려지고 있는 과정) 해당 프레임이 끝날때까지 다른 프레임이 중복을 실행되지 않는다. 그렇게 하나의 프레임이 끝나면 raf를 null 값으로 바꿔서 다음 프레임을 그릴 수 있도록 만든다. 이렇게 최적화해 봤는데, 어떻게 동작할지 확인해 보자 ![raf 최적화 후](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1742115664510-requestAnimationFrame%20%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%92%E1%85%AA-GTUXEzZIlwV1vNAe0RlNoYr2sin9Nr.gif) 테스트를 좀 더 용이하게 하기 위해서 1초마다 한번 콘솔로그를 찍는 interval함수를 만들어 사용했다. 그렇게 확인한 결과 정말 1초에 60번 정도 실행되는 것을 확인할 수 있었다. 신기하다 😱 throttle은 16ms 이상의 시간간격으로 할 경우에는 버벅거림이 약간 생길 수 있지만 이 리퀘스트 애니메이션 프레임은 화면 주사율에 맞게 실행되기 때문에 더 효율적으로 최적화를 할 수 있는 것 같다. 정말 성능이 중요해서 16ms 이상으로 조절해야하는 경우가 아니라면 requestAnimationFrame을 사용해서 최적화를 하는 것이 더 효율적이라고 생각이 들었다. 이번 글에서 살펴본 모든 예제와 코드는 아래 깃허브 리포지토리에서 확인할 수 있다. 브랜치별로 코드가 다른데, performance/drag1 과 drag2는 각각 throttle과 requestAnimationFrame 으로 최적화한 각각의 코드를 볼 수 있다. 그리고 beforeOptimize는 최적화 전의 코드를 볼 수 있다. [GitHub - ShipFriend0516/laboratory](https://github.com/ShipFriend0516/laboratory) Contribute to ShipFriend0516/laboratory development by creating an account on GitHub. 최적화에는 정답이 없다고 생각해서 아마 이것보다 더 뛰어난 성능최적화 방법이 있을 것이라고 생각한다. 이번 글에서는 대표적으로 쉽게 활용할 수 있는 2가지 최적화 방법에 대해서 알아봤다. 👍]]> sjw4371@naver.com (개발자 서정우) <![CDATA[미디어 장치 권한이 없을 때 대응하기]]> https://shipfriend.dev/posts/미디어-장치-권한이-없을-때-대응하기 https://shipfriend.dev/posts/미디어-장치-권한이-없을-때-대응하기 Wed, 12 Mar 2025 05:24:55 GMT 📌 미디어 장치 권한을 수락하지 않았을 때 미디어 장치 목록에 접근이 불가능함 ## 현재 코드 useMediaDevices 커스텀 훅에서 미디어 장치들을 제어하고 있는다. 원래 의도대로라면 미디어 장치를 권한 이슈로 불러오지 못하면 에러가 뜨거나 아예 장치가 [] 빈 배열로 내려오는 것이었다. ```tsx useEffect(() => { // 비디오 디바이스 목록 가져오기 const getUserDevices = async () => { try { const devices = await navigator.mediaDevices.enumerateDevices(); const audioDevices = devices.filter( (device) => device.kind === "audioinput" ); const videoDevices = devices.filter( (device) => device.kind === "videoinput" ); setUserAudioDevices(audioDevices); setUserVideoDevices(videoDevices); } catch (error) { console.error("미디어 기기를 찾는데 문제가 발생했습니다.", error); } }; getUserDevices(); }, []); ``` 하지만 이 코드에서 에러는 발생하지 않고, 그렇다고 빈배열이 내려오는 것도 아니었다. ```tsx [ { "deviceId": "", "kind": "audioinput", "label": "", "groupId": "" }, { "deviceId": "", "kind": "videoinput", "label": "", "groupId": "" }, { "deviceId": "", "kind": "audiooutput", "label": "", "groupId": "" } ] ``` 실제 컴퓨터에서 미디어 장치가 3개 이상 있었고, 해당 장치들은 권한이 허락되어있지 않아도 위와 같이 숨겨진 채로 정보가 내려왔다. > 📌 **검증** > > 검증하기 위해 검색해서 알아본 결과 미디어 장치 목록을 가져오는 것은 권한이 없어도 오류가 나지 않고 모두 빈 문자열 값으로 치환되어 내려온다는 것을 알게 되었다. ## 해결 ```tsx const dontHavePermission = devices.find((device) => device.deviceId !== "") === undefined; if (dontHavePermission) { setUserAudioDevices([]); setUserVideoDevices([]); } else { setUserAudioDevices(audioDevices); setUserVideoDevices(videoDevices); } ``` `dontHavePermission` : 디바이스 목록들이 모두 deviceId가 빈 문자열일 경우에 true 하나라도 있으면 false를 반환 이제 권한이 없어도 제대로 작동하는 것을 확인했다. ![image.png](https://idmlft3uczstcjaa.public.blob.vercel-storage.com/images/1741757078147-123123%E3%85%81%E3%85%87%E3%84%B9%E3%85%81%E3%84%B9-i2EzvFyyLNd9tSOyd9Jk6Axpkdy0s0.png)]]> sjw4371@naver.com (개발자 서정우) <![CDATA[다크모드 FOUC 깜빡임 현상 수정하기]]> https://shipfriend.dev/posts/다크모드-fouc-깜빡임-현상-수정하기 https://shipfriend.dev/posts/다크모드-fouc-깜빡임-현상-수정하기 Mon, 10 Mar 2025 07:34:55 GMT
``` 찾아보니 리액트에서 위험하다고 표시하는 이유는 XSS 공격에 취약해서라고 한다. > XSS란 악의적인 스크립트를 포함한 html를 삽입해서 해당 스크립트를 실행시키는 공격이다. > 이렇게만 보면 왜 위험하다는건지 잘 와닿지 않는데 아래 예시를 보고 이해해보자. ```tsx

댓글

{/* 댓글 목록 표시 - XSS 취약점! */}
{comments.map((comment, index) => (
))}