테크

공통적으로 사용되는 위협 탐지룰의 텍스트 메이트 문법을 공통적으로 관리하기 위해 공통 모듈을 만들고자 했습니다. NPM 라이브러리의 경우 NPM 저장소에 올라가며 비즈니스 플랜이 아니고서야 오픈되는 경향이 있습니다. 그래서 외부로 노출되지 않고 내부에서만 사용하기 위해 사내 NPM 저장소를 찾아 배포를 진행하며 로컬 저장소에 어떤 방식으로 배포할 수 있는지 포스팅을 하고자 합니다. 아래 예제에서는 사내 NPM 저장소에 배포되는 모나코 에디터에 자체 텍스트 메이트 문법을 적용하기 위해 패키지를 배포하는 과정을 담은 내용입니다. 프로젝트 구성하기 각각으로 공통적으로 모듈을 레포지토리로 구성하여 만드려고했으나, 앞으로 많아질 공통 모듈들을 각 레포지토리 별로 관리하기가 어렵다는 생각이 들었습니다. 그래서 공통 모듈을 한 곳에 모아두는 레포지토리를 각각 레포로 구성하기 보다는 한 레포지토리에서 관리할 수 있도록 모노레포 방식으로 구성하기로 했습니다. 모노레포로 구성을 하게 되면 한 레포지토리에서 여러 프로젝트 관리가 용이하기 때문입니다. 모노레포로 관리하기 위한 패키지들에는 서비스가 들어가지는 않고, 유틸 성격의 코드들이 패키지 형태로 제공이 될 예정입니다. 루트의 package.json 에서는 아래와 같이 pnpm 을 통해 모든 패키지들을 순회하며 배포를 진행하게 됩니다. 배포를 진행하며, 버전이 바뀌지 않은 패키지의 경우에는 넘어가고 버전이 바뀐 패키지에 한해서 배포를 진행합니다. 여기서 중요한 점은 package.json 에 registry 를 명시해줘야 NPM 공개 저장소에 배포되는 것이 아닌 사설 레포지토리 주소로 배포됩니다. 이제 배포할 패키지를 하나 만들어놓을 차례입니다. 위와 같이 위협 탐지 시그니쳐 룰을 임포트할 수 있는 패키지들을 만들었습니다. 메인 엔트리 파일 (index) 에서는 배럴 패턴으로 정의해놓은 텍스트 메이트 언어 파일들을 내보냅니다. package.json 에서는 위와 같이 구성을 해주며, .cjs 와 .mjs 에 대한 호환을 진행합니다. 관련하여 아래 이어지는 vite.config.js 도 같이 참고해주면 좋습니다.

웹에서 코드 편집기를 만들 때 가장 많이 사용하는 선택지 중 하나는 Monaco Editor 입니다. VSCode의 편집기 엔진을 기반으로 하여 자동 완성, 진단, 다중 커서 같은 편집 경험들을 쉽게 구현할 수 있습니다. 다만 기본 문법 강조의 경우, VSCode에서 보이는 결과와 완전히 같지 않을 수 있습니다. Monaco Editor의 기본 토크나이저가 모든 TextMate 문법을 그대로 처리하지 않기 때문입니다. 이때 Shiki를 연결하면 VS Code 계열의 TextMate 문법과 테마를 사용하여 더 정확한 색상 표현을 할 수 있습니다. Shiki는 Monaco 용도의 공식 어댑터 @shikijs/monaco 를 제공합니다. 해당 어댑터를 통해 직접 토큰화 결과를 Monaco에 주입하는 방식보다 이 패키지를 사용하여 적용하는 편이 훨씬 더 간단합니다. 패키지 설치하기 Monaco , shiki, @shikijs/monaco 패키지를 설치합니다. 적용해보기 createHighlighter 로 필요한 언어와 테마를 로드합니다. 사용할 언어의 ID를 monaco.languages.register() 을 통해 등록합니다. shikiToMonaco() 를 통해 Shiki 문법과 테마를 Monaco에 연결합니다. 이때 지원되는 themes (에디터 테마)와 langs (언어 설정) shiki 공식 홈페이지에서 확인이 가능합니다. 다크모드와 같이 테마를 동적으로 변경하고 싶다면 Shiki에 여러 테마를 미리 등록했다면 Monaco 테마로 바로 전환이 가능합니다. 중요한 점은 monaco.editor.defineTheme() 를 별도로 호출할 필요가 없으며, shikiToMonaco() 가 Shiki에서 로드한 테마를 Moaco 테마로 자동 등록해줍니다. 커스텀 언어셋을 나만의 언어로 하이라이팅 하고싶다면 만약 사내에서 커스텀 언어 (ex. 보안 위협 탐지룰 등) 으로 기본 언어 목록에 없는 문법으로 강조를 해야한다면, TextMate Grammer 파일, 즉 .tmLanguage.json 을 추가하여 로드해야합니다.

웹 어플리케이션을 사용하다보면 같은 사이트를 여러 탭에서 열어두는 경우가 많습니다. 이때 한 탭에서 로그아웃을 했는데 다른 탭은 로그인 화면을 계속 보여주거나, 장바구니가 탭마다 다르게 보이면 사용자 경험은 떨어지게 됩니다. 이러한 문제를 간단하게 해결할 수 있는 브라우저 기능이 BroadcastChannel API 입니다. 같은 출처의 탭, 창, 아이프레임, 웹 워커사이에서 메세지를 실시간으로 주고받을 수 있게 해주는 웹 표준 API이며, 별도 라이브러리나 서버 연결없이 사용할 수 있다는 것이 큰 장점입니다. BroadcastChannel API는 현재 모던 브라우저에서 지원이 되고 있습니다. BroadcastChannel API가 무엇인가요? BroadcastChannel API는 이름이 같은 채널에 연결된 모든 브라우저 컨텍스트에 메세지를 전송하는 기능입니다. 여기서, 브라우저 컨텍스트란 다음과 같은 실행 공간을 의미합니다. 같은 사이트의 다른 탭 새 창 또는 팝업 창 아이프레임 웹 워커 예를 들어 new BroadcastChannel(“auth”)로 auth 라는 채널을 만들면, 같은 출처에서 auth 채널을 구독하고 있는 다른 탭들이 메세지를 받을 수 있습니다. 여기서 중요한 점은 같은 origin (프로토콜, 도메인, 포트의 조합)이여야 한다는 점이 관건입니다. 서로 다른 도메인 간의 통신을 위한 도구가 아니기에, 다른 출처의 아이프레임 또는 팝업과 통신을 해야한다면 이런 경우에는 window.postMessage() 를 사용해야합니다. 기본적인 사용 방법 초기 세팅부터 사용 방법이 많이 복잡할 것 같지만, 생성자를 통해 생각보다 쉽고 간단하게 세 단계 정도로 나누어 사용할 수 있습니다. 브로드캐스트로 사용할 채널을 생성합니다. 메세지를 수신할 이벤트 리스너를 등록합니다. postMessage() 로 메세지를 보냅니다. 이 코드를 같은 사이트의 서로 다른 두 탭에서 실행하게 되면, 한 탭이 보낸 메세지를 다른 탭이 받는 구조가 됩니다. 여기서 확인해야할 점은 메세지를 보낸 BroadcastChannel 객체 자신은 메세지를 받지 않는다는 것입니다. 첫 번째 탭에서channel.postMessage() 를호출하면 두 번째 탭에서는 메세지를 수신하지만, 첫 번째 탭의 같은 channel 객체에는 message 이벤트가 발생하지 않습니다.

한 눈에 확인해보자면 .. staleTime : 이 데이터가 신선하다고 보는 시간 gcTime : 아무 컴포넌트가도 안쓰는 캐시를 메모리에 남겨놓는 시간 staleTime은 refetch를 할지 말지 영향을 주는 요소이다. Q. 5분이라고 가정했을 때, 흐름은 아래와 같다. 0분 : 데이터 fetch 0 ~ 5분 : 데이터가 fresh한 상태 5분 이후 : stale 상태 fresh 상태에서는 같은 querykey로 다시 useQuery가 실행되어도 보통 네트워크 요청을 다시하지 않고, 캐시 데이터를 사용한다. Q. 만약 5분이 지난 경우라면? 0분 : "/organizations" 진입 → API 요청 7분 : 다른 페이지 갔다가 다시 "/organizations" 진입 → stale 상태 → 기존 캐시 데이터 먼저 보여줄 수 있음 → 백그라운드 refetch 가능 2. gcTime은 캐시를 언제 알게할지에 대한 영향을 주는 요소이다. 여기서 중요한 점은 gcTime은 쿼리가 inactive 된 순간부터 돌아간다. active와 inactive의 차이점 active : 어떤 컴포넌트가 useQuery로 이 데이터를 사용 중 inactive : 아무 컴포넌트도 이 queryKey를 사용하지 않음

서버 상태를 데이터 테이블 컴포넌트에서 그대로 사용하면서, 페이지가 넘어갈 때 새로운 데이터를 패칭하면서 데이터 테이블 컴포넌트의 페이지가 undefined으로 떨어지며, 이전 상태 값을 잃어버리는 상황이 발생했다. 이렇게 되면 로컬 상태로 현재 페이지를 다뤄야하는 상황인데.. 서버 상태를 그대로 사용하면서 패칭할 수 있는 방법이 없을까 고민을 하다가 placeholderData 옵션으로 해결이 된다는 것을 알게되었다. placeholderData란? 이전의 keepPreviousData: true 플래그 형식으로 이전 데이터를 보여줄 것인지에 대한 옵션 값으로 사용되었으나, 현재는 placeholderData: (previousData) => previousData 형태로 사용을 할 수 있다. Tanstack Query에 placeholderData는 새 쿼리 결과가 오기 전까지 임시로 보여줄 데이터를 저장하는 옵션이다. 기본적으로 이전에 성공했던 결과 값이 전달되며, 미리 보여줄 데이터를 사전에 설정할 수 있다. queryKey가 바뀌어서 새 요청을 보낼 때 → 응답이 오기 전까지 화면을 비우지 않고 → 직전 데이터(위에 코드에서는 previousData)를 그대로 보여준다. 어떻게 사용할 수 있을까? 나 같은 경우에는 데이터 테이블 컴포넌트에 클라이언트 상태를 넣지 않고, 모두 서버 상태로 대치를 하기 때문에 리스트에서 placeholderData가 존재하지 않으면 data가 undefined가 되어 전체 아이템 개수가 0으로 잠깐 내려가는 현상이 발생할 수 있다. 그래서 placeholderData에 이전 데이터를 사용할 것이라 명시를 해준다면 이전 데이터 잠시 유지되며 데이터 테이블 컴포넌트가 급격하게 1페이지로 보정되는 현상을 줄일 수 있다. 즉, 로딩 중에도 이전 값을 일시적으로 유지해주는 기능이라고 생각을 하면 된다. placeholderData는 staleTime, gcTime과 수행하는 역할이 다르기 때문에 독립적으로 운용되며 전혀 관여하지 않으니 주의하자.

SCSS를 사용하는 환경에서 Flex 박스로 레이아웃을 정의하며 계속 하위 트리로 내려간다고 가정을 할 때, 아래와 같은 구조가 발생하게 된다. 부모에서 Flex 스타일 속성을 정의하고, 또 자식 요소에서 레이아웃 구조 구성을 위해 Flex 스타일을 정의하게 되면 무한으로 Flex 스타일 속성을 매번 정의를 해줘야하는 상황이 발생한다. 이러한 반복 구조를 매번 직접 작성을 해주면 개발 피로도가 생각보다 엄청나다, 그래서 SCSS에서는 @mixin 키워드를 사용하여 이러한 문제들을 해결할 수 있다. 1. @mixin으로 스타일 반복 구조 줄여보기 flex 라는 mixin을 정의하고, 이 구조를 프로그래밍 언어의 함수처럼 사용을 할 수 있다. 먼저 .scss 파일에 아래와 같이 정의를 하면 된다. 그런데 여기서, Vue의 SFC scope SCSS를 사용하는 사람이라면, 해당 블록은 독립적으로 컴파일 되기 때문에 아무리 @mixin을 글로벌로 선언하더라도 모듈을 불러오지 못하기 때문에 사용을 하지 못한다. 그럴 경우에는 파일에서 @use 키워드를 통해 직접 임포트를 하거나, 아래와 같이 vite.config.js에 모든 SCSS에 자동 주입을 하는 방법이 있다. 2. 컴포넌트로 추상화해보기 위의 @mixin 스타일을 그대로 사용해 컴포넌트로 만들기는 했지만, 위의 @mixin 스타일 적용을 해보았다면 아래 컴포넌트 구조화는 쉽게 이해가 될 수 있다. 컴포넌트를 래핑하여 하위 컴포넌트들의 엘리먼트 배치를 컴포넌트 선언단에서 제어하는 방식이다. 래핑된 컴포넌트들은 <slot/> 에 렌더링되면서 사전에 정의한 배치 구조로 나오게 된다.

Axios를 사용하면서, 배열 파라미터로 서버에 데이터를 전송할 때 클라이언트 상태에서는 정상적으로 ['A', 'C', 'D'] 형태로 삽입되는 것을 확인했다. 그런데 Axios로 서버에 전송을 할 때마다 아래와 같이 전송이 되는 현상이 발생한다. Axios에서 제공하는 paramSerializer 를 사용하게 된다면 원하는 형태의 배열을 브라켓 없이 손쉽게 전송할 수 있다. axios@1.x 기준으로 아래 코드를 참고한다. 위의 전송 동작으로 네트워크 탭의 페이로드를 확인하게 되면 URL 인코딩이 되면서 아래와 같이 노출된다. 서버 측에서는 아래와 같이 배열을 브라켓 없이 반복 key로 보내는 방식으로 원하고 있는데, 이 경우에는 클라이언트에서 어떻게 처리를 해줄 수 있을까? Axios paramsSerializer 사용해보기 indexs = null 을 주면 배열이 아래와 같이 서버로 전송된다. 반대로 기본 값 또는 ìndexes: false 면 직렬화가 되지 않으니 주의해야한다.

전사 AX(Artificial Intelligence Transformation) 전환을 하면서 자연스레 서비스에도 Agentic UI를 적용하면서, SSE를 적용하는 과정에서 브라우저에서 제공하는 new EventSource 를 POST 메서드에서는 사용하지 못한다는 것을 알게되었고 EventSource 방식과 Fetch + ReadableStream(SSE) 방식의 차이를 공부해보고자 해요. AX(Artificial Intelligence Transformation)이란? '인공지능 전환'을 뜻하는 말로, 기업이나 조직이 인공지능(AI)을 핵심 동력으로 삼아 업무 방식, 의사결정 체계, 비즈니스 모델 전반을 새롭게 재설계하는 혁신 과정을 의미합니다. SSE(Server-Sent Events)란? 서버 → 클라이언트 단방향 실시간 스트리밍 프로토콜입니다. Content-Type: text/event-stream 으로 연결을 유지하면서 서버가 data: ...\n\n 형식으로 계속 데이터를 밀어냅니다. 실제로 호출을 하게 되면 아래와 같은 결과 값을 네트워크 탭에서 확인할 수 있습니다. EventSource (브라우저 내장 API) 브라우저가 자동으로 재연결 처리를 지원합니다. (retry : 필드 지원) 연결이 끊기면 자동으로 재시도를 합니다. GET 전용입니다, URL에 파라미터를 쿼리스트링으로만 전달이 가능합니다. Authorization 헤더 추가가 불가합니다. 즉, JWT 인증이 불가한 상황이라는 겁니다. 쿠기 기반의 인증만 가능합니다. (withcredentials : true) 제약 사항으로는 GET 메서드 전용이며, 헤더를 추가하지 못합니다. 보통 주식 시세, 알림, 공개 피드 같은 곳에서 사용을 합니다. Fetch + ReadableStream (SSE) POST + Request Body → 긴 질문, 복잡한 옵션 전달이 가능합니다. Authorization: Bearer ... 헤더가 가능합니다. 즉, JWT 인증이 가능합니다. 자동 재연결이 없으며, 직접 구현해야합니다.

Vercel 서버리스 함수는 서버를 직접 관리하지 않고, 백엔드 로직을 실행할 수 있는 기능이에요. 기본적으로 상태가 없는 Stateless 하며, 각 요청은 독립적으로 처리되어요. 함수는 HTTP 요청이 들어올 때만 실행이 되고, 유후 상태에서는 비용이 발생되지 않아요. 또, 트래픽에 따라 자동으로 인스턴스가 늘어나는 구조를 가지게 됩니다. /api 폴더 아키텍쳐로 서버리스 함수 구현해보기 비교적 간단하게 사용을 할 수 있는데, 아래와 같은 예제로 구성을 할 수 있어요. 서버리스 함수는 서버가 없어도 호출할 수 있는 구조이기에, 단순한 정적 사이트에서도 API 호출을 테스트하거나 간단한 서버 로직을 구현하는데 활용 할 수 있어요. 프론트엔드 중심의 프로젝트에서 별도의 백엔드 환경 없이도 빠르게 데이터를 처리할 수 있다는 것이 강점인 것이죠. vercel.json으로 서버리스 함수 구현해보기 /api 폴더 아키텍쳐가 아닌 vercel.json 으로 서버리스 함수를 명시적으로 구현을 하는 방법도 존재해요. 만약 서버 자원이 아닌, 서버에서 html 을 받아 html 의 일부를 파싱하고, 수정하는 서버리스 함수를 만든다고 가정을 해볼게요. Vercel 서버리스 함수, 편하고 마냥 좋은거 아닌가요? 마냥 좋지만은 않아요. 콜드스타트 방식이면서 Vercel 서버리스 함수는 실행에 제약을 가지고 있는데, 기본은 10초 · Pro 플랜은 60초의 최대 요청 시간을 제공해요. 메모리는 최대 1GB이기 때문에 주의해서 사용을 해야합니다. Vercel 서버리스 함수의 동작 원리 일반 서버와 서버리스 함수를 비교해보면 아래와 같은 동작 원리를 가지게 되는 것을 볼 수 있어요. 요청이 들어올 때만 함수를 생성해서 요청을 처리한다는 것은 "콜드 스타트" 라는 방식이에요. 콜드 스타트와 웜 스타트? 위에서 확인한 콜드스타트의 개념을 차용해서 보면 Vercel 서버리스 함수는 아래와 같은 내부적인 세부 동작을 가지게 돼요. 또 각각의 Vercel 서버리스 함수는 각 요청 시 마다 개별적이고 독립적으로 움직이게 됩니다.

어떤 경우에 어떤 시맨틱 태그를 써야할까? <article> vs <section>, 둘 중 어떤 것으로 래핑을 해야할까? 엘리먼트 구조를 구성할 때, 두 태그 모두 콘텐츠를 묶는 역할로 사용을 하고 있다. 그런데 두 태그를 "언제 어떻게" 사용을 해야하는지에 대해서는 명확하게 사용법을 알고있지 못하는 것 같다. 핵심 기준은 하나이다, 페이지에서 떼어내도 독립적으로 의미가 있으면 <article>, 아니면 <section>. <article> 안에 <section>이 들어갈 수 있고, <section> 안에 <article>도 들어갈 수 있다. <article>은 중첩도 가능하다. <button> vs <a>, 둘 중 어떤 것을 사용해야할까? <a>는 링크(URL 이동)용이고, <button>은 동작(스크립트, 폼 제출)용이다. <a href="#">나 <a onclick="...">로 버튼 역할을 구현하는 경우를 종종 봤는데, 스크린리더는 이걸 "링크"로 읽는다. 키보드로 Enter를 눌렀을 때 동작이 예상과 다를 수 있다. <time> 태그는 어떤 경우에 사용할까? 화면에 표시되는 텍스트는 "2주 전"처럼 사람이 읽기 편한 형식이어도, datetime 속성에 ISO 형식을 넣으면 검색엔진과 보조 기술이 정확한 시각을 파악할 수 있다. heading 계층은 순서를 지키는 것이 좋다 스크린리더 사용자는 heading 목록으로 페이지를 탐색한다. h1 → h3처럼 계층이 건너뛰면 탐색 구조가 깨진다. 만약, 텍스트 크기가 이유라면 CSS로 조정하는 것이 올바르다. 시맨틱 태그의 주의사항 <section>은 기본적으로 랜드마크가 아니다 앞서 설명했지만, 접근 가능한 이름(accessible name)이 없는 <section>은 스크린리더의 랜드마크 목록에 등록되지 않는다. <section>을 쓸 때는 aria-label이나 aria-labelledby로 이름을 주거나, 제목을 <h2>~<h6>로 명확히 제공하는 것이 좋다. ARIA role을 중복으로 선언하지 않는 것이 좋다

처음 웹 퍼블리싱을 진행할 때 거의 모든 레이아웃을 div 태그에 의존하여 구성을 진행했었다. 클래스 이름이나 아이디 값을 붙여 다른 사람들이 잘 이해하면 그렇게 퍼블리싱이 끝난 줄 알았다. 처음 프론트엔드 개발에 본격적으로 진입을 했을 때, HTML이 사실 "의미"를 담는 언어라는 건, 한참 뒤에야 알게 됐다. 시맨틱 태그는 태그 하나하나가 "이 콘텐츠가 어떤 것을 의미하는지" 브라우저와 검색엔진, 스크린리더에게 알려주는 도구이다. <div class="header"> 와 <header> 는 눈으로 보기에 같은 의미를 담고 있을 수 있지만, 기계가 읽을 때는 전혀 다르게 수행한다. 당시에는 "잘 동작하니까" 라는 이유로 이 차이점을 체감하지 못했으나, 접근성 이슈에 대해 조금 고찰을 하고나서 의문이 생겼다. 스크린 리더가 내 페이지를 어떻게 읽는지, 그리고 어떤 태그가 실제로 영향을 주는 것인지 다시 한번 시맨틱 태그에 대해 들여다보고자 한다. div 수프가 표준이던 시절 HTML이 처음 만들어진 건 1991년이다. 팀 버너스리(Tim Berners-Lee)가 문서를 서로 연결하기 위해 설계한 언어였다. 초기에는 구조보다 내용이 중요했다. 폰트 크기를 키우고 싶으면 <font size="5">, 글씨를 굵게 하고 싶으면 <b> 태그를 썼다. 그 시절 웹 개발자들은 테이블로 레이아웃을 만들었다. <table>, <tr>, <td>를 격자처럼 배치해 컬럼 구조를 구현했다. 이후 CSS가 등장하면서 테이블 레이아웃은 줄었지만, 그 자리를 <div>가 채웠다. <div>를 쌓아 레이아웃을 잡는 방식이 표준처럼 자리잡았고, 이를 "div 수프(div soup)"라고 부르게 됐다. 이 구조는 시각적으로는 잘 동작한다. 스타일도 입힐 수 있고, 레이아웃도 자유롭게 잡힌다. 근데 기계 입장에서는 모든 게 그냥 "빈 상자"다. 어디가 헤더인지, 어디가 탐색 영역인지, 어디가 주요 콘텐츠인지 알 수 없다. 2008년 HTML5 초안이 나오면서 상황이 달라졌다. W3C와 WHATWG는 <div> 대신 의미를 가진 구조 태그들을 도입했다. <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>. 이 태그들이 현재 우리가 쓰는 시맨틱 HTML의 기반이다.

Nuxt를 처음 쓸 때 데이터를 가져오는 방법이 여러 개라는 게 헷갈렸다. useFetch도 있고, useAsyncData도 있고, $fetch도 있다. 셋 다 API를 호출하는 것 같은데 왜 따로 존재하는걸까? $fetch가 네이티브 fetch나 axios 처럼 이벤트처럼 사용하는 것이고, 또 useFetch는 데이터 뿐만 아니라, 로딩 및 에러 상태를 받아볼 수 있고.. 이 세가지의 패칭 방식에 대해서 온전히 잘 모르다보니 어느 상황에서 사용해야하고 적용해야하는지 헷갈렸다. Nuxt는 서버와 클라이언트 양쪽에서 코드가 실행되는 환경을 제공한다. 같은 컴포넌트 코드가 서버에서 한 번 실행되고, 브라우저에서 또 실행된다. 이 구조에서 데이터를 어떻게 가져오느냐에 따라 API 호출 횟수, 사용자 경험, 성능이 모두 달라진다. 세 가지 방법은 이 구조 안에서 각자 다른 역할을 위해 설계됐다. 먼저 Nuxt4의 SSR 방식 가볍게 알아보기 브라우저에서만 돌아가는 React 앱이라면 데이터 페칭은 단순하다. 컴포넌트가 마운트되면 API를 호출하고, 응답이 오면 화면에 표시한다. 그게 전부다. Nuxt의 SSR(서버 사이드 렌더링)은 다르다. 같은 페이지를 두 번 렌더링한다. SSR(Server-Side Rendering) 브라우저가 아닌 서버에서 HTML을 미리 만들어서 보내주는 방식. 첫 화면이 빠르게 보이고, 검색엔진 최적화(SEO)에 유리하다. 하이드레이션(Hydration) 서버에서 만든 정적 HTML에 Vue가 달라붙어서 상호작용 가능한 앱으로 만드는 과정. 이 시점에 <script setup> 코드가 브라우저에서 다시 실행된다. 이 이중 호출 문제를 해결하기 위해 Nuxt는 페이로드(payload) 메커니즘을 사용한다. 서버에서 가져온 데이터를 HTML 안에 직렬화해서 담아두고, 브라우저에서 하이드레이션할 때 그 데이터를 재사용한다. useFetch와 useAsyncData는 이 메커니즘을 활용한다. 서버에서 실행하고, 데이터를 페이로드에 담고, 클라이언트에서는 API를 다시 호출하지 않는다. $fetch는 이 메커니즘을 사용하지 않는다.

사내에서 각 프로젝트 별로 유틸 함수들이 따로 관리되다보니 동기화 과정 자체가 너무 힘들었다. 그래서 모노레포로 프로젝트를 만들기에는 빌드 설정과 리소스가 부족하다보니 유틸 함수 라이브러리를 만들어서 배포하자는 생각을 했다. 그 당시 당연하게만 생각헀던 NPM 라이브러리였다. 그러다 우연히 면접 과정에서 "서브 모듈로도 고려해보시지 않은 이유가 무엇인가요?" 라는 질문이 나왔고, "왜 서브모듈이어야할까?" 라는 생각이 문득 들었다. 사실 NPM이 아니라 서브모듈이라는게 많이 낯설었다. "그게 뭐가 다른 거지?" 라는 의문이 생겼고, 막상 찾아보니 둘의 동작 방식이 생각보다 근본적으로 달랐다. 그냥 나한테 익숙하다고 빠른 선택을 하는 것이 아닌, 어떤 것들이 존재하고 무엇이 최선의 선택인지를 항상 생각해야한다는 것을 다시 한번 일깨워주었다. 그래서 GIt 서브 모듈로 했을 때의 경험들은 어떠할까에 대한 내용을 배워보고자 포스팅을 진행한다. 두 방식이 각각 왜 생겼을까? 코드를 공유하는 방법의 역사 소프트웨어에서 코드를 공유하는 방법은 크게 두 방향으로 발전해왔다. 하나는 소스 코드를 직접 참조하는 방식이고, 다른 하나는 배포된 패키지를 의존성으로 선언하는 방식이다. Git 서브모듈은 전자의 계보에 있다. 2008년 Git 1.5.3에 처음 도입됐다. 당시에는 모노레포 도구도 없었고, 하나의 저장소에 여러 프로젝트를 담는 표준적인 방법이 없었다. "다른 저장소를 내 저장소 안에 포함시키는" 서브모듈은 그 공백을 채우는 자연스러운 해결책이었다. 내부 공유 라이브러리, 서드파티 코드, 플러그인 시스템 등에 쓰였다. NPM은 후자의 계보다. 2010년 Node.js 생태계와 함께 등장했다. 소스 코드가 아니라 빌드되고 버전이 붙은 패키지를 중앙 레지스트리*에서 내려받는 방식이다. 버전 범위를 선언하면 npm이 알아서 호환되는 버전을 찾아주고, node_modules에 설치해준다. 레지스트리 패키지를 저장하고 배포하는 중앙 서버. 기본값은 npmjs.com이며, 사설 레지스트리(GitHub Packages, Verdaccio 등)를 직접 운영할 수도 있다.

Vue2 → Vue3 마이그레이션을 진행하면서 Options API와 Composition API를 다양하게 사용해왔다. 그러면서 자연스레 Vue의 서버 사이드 렌더링에도 관심을 가지게 되었고, Nuxt에 대해 공부를 하고 싶어졌다. Nuxt의 신규 프로젝트를 스캐폴딩하여 만들어보니, 신규 프로젝트는 Nuxt3로 시작을 하게 되었고 Nuxt2와 Nuxt3의 차이는 무엇이 있는지 문득 궁금해졌다. (like Next의 Page 라우터와 App 라우터의 변천사처럼 ^,^..) Nuxt가 어떻게 여기까지 왔을까? Nuxt는 2016년에 등장했다. Next.js가 React 생태계에서 SSR을 풀어낸 방식에서 영감을 받아, Vue 커뮤니티에서 같은 개념을 구현한 것이다. Nuxt 1, Nuxt 2를 거치면서 Vue 생태계의 표준 SSR 프레임워크 위치를 굳혔다. Nuxt 2는 2018년에 출시됐다. Vue 2 기반, Options API, Vuex, webpack, Connect 미들웨어 스택. 안정적이었고 생태계가 풍부했다. 지금도 레거시 코드베이스에서는 주류다. Nuxt 3는 2022년 말에 정식 출시됐다. 단순한 메이저 버전 업이 아니다. Vue 3와 Composition API를 중심으로 프레임워크 전체를 다시 작성했다. 빌드 도구는 Vite로 교체됐고, 서버 엔진은 Nitro라는 완전히 새로운 것으로 바뀌었다. asyncData와 Vuex는 사라졌다. 그 과정에서 Nuxt 2 유지보수는 2024년 6월에 공식 종료됐다. 지금 Nuxt 2를 프로덕션에서 쓰고 있다면 보안 패치도 없는 상태다. 내부에서 실제로 무슨 일이 일어날까? 표면적인 API 차이보다 내부 동작의 차이가 더 중요하다고 한다. Nuxt 2와 Nuxt 3가 어떻게 다르게 동작하는지를 이해하면, "왜 이런 식으로 써야 하는가"가 설명된다. 빌드 파이프라인: webpack vs Vite Nuxt 2는 webpack을 사용한다. webpack은 모든 모듈을 번들링한 뒤 개발 서버를 시작한다. 프로젝트 규모가 커질수록 이 초기 번들링 시간이 길어진다. (사내의 백오피스 프로젝트도 Webpack 기반의 프로젝트였다가, 초기 번들링 시간이 너무 오래 걸려 각 모듈을 그대로 서빙해주는 Vite로 변경을 하게 되었다)

문득 ref.value = x 가 화면으로 전달되기 까지의 내부 과정들이 궁금해졌다. 상태 값이 바뀌면 컴포넌트가 리렌더링되는 라이프사이클과 빗대어 생각을 하게 되지만, 내부적으로는 어떤 값들이 트리거되어 레이아웃 상에 반영되는지 그 코어의 개념을 모르는 듯한 느낌이 들었다 ^,^ .. Vue의 반응형이 왜 이런 구조를 갖게 됐을까? 초기 프론트엔드 개발에서 상태 변화를 화면에 반영하려면 직접 DOM을 조작해야 했다. document.getElementById로 노드를 찾고 innerHTML을 바꾸는 방식이었다. 상태가 늘어날수록 "이 값이 바뀌면 저 DOM을 바꿔야 한다"는 연결고리를 직접 관리해야 했고, 그 관계가 복잡해지면 추적이 불가능해졌다. Vue 2에서 이 문제를 Object.defineProperty 기반의 반응형 시스템으로 해결하려 했다. 데이터가 바뀌면 연결된 DOM이 자동으로 업데이트되는 구조였다. 근데 배열 변이나 런타임에 추가된 프로퍼티는 감지하지 못하는 한계가 있었다. Vue 3에서 Proxy 기반으로 전면 재설계했다. ref는 그 반응형 시스템의 가장 기본적인 단위다. 숫자, 문자열 같은 primitive 값은 Proxy로 직접 감쌀 수 없기 때문에, ref는 .value 프로퍼티 안에 값을 담고 거기에 getter/setter를 붙이는 방식으로 반응형을 구현한다. 왜 Object.defineProperty 는 배열 변이나 추가된 프로퍼티를 감지하지 못할까? Object.defineProperty 는 이미 존재하는 속성의 값을 변경할 때 가로채기 위해 사용이 되는데, 동적으로 추가되는 구조 전체를 감시하는 것이 아니라 정의하는 싲머에 존재하는 특정 키들에 대한 게터와 세터를 설정하기 때문에 동적으로 추가되는 프로퍼티에 대해서는 감시가 설정되어있지 않아 감지를 할 수 없다. ref는 내부적으로 어떻게 생겼을까? ref(0)을 호출하면 RefImpl이라는 클래스의 인스턴스가 만들어진다. dep이라는 필드가 지금 현재 바라보고 있는 ref 를 바라보고 있는 이펙트들의 집합이기 때문에 핵심이며, "지금 나를 읽고 있는 코드"를 여기에 담아둔다. 값이 바뀌면 이 목록에 있는 코드들에게 알린다. 이 구독/알림 메커니즘이 반응형의 본질이다.

Vue3 + Next.js App Router 경험자 기준으로 작성. 1. 핵심 구조 차이 2. 파일 기반 라우팅 개념은 같지만 파일명과 폴더 구조 방식이 다르다. Next.js App Router 폴더가 라우트 세그먼트이고, 폴더 안의 page.tsx가 실제 페이지. Nuxt3 .vue 파일 자체가 라우트. 폴더 구조도 동일하게 지원. 동적 파라미터 접근 라우터 이동 3. 컴포넌트 모델 — 가장 큰 차이점 이 부분이 Next.js App Router와 Nuxt3의 가장 근본적인 차이다. Next.js App Router: Server Component vs Client Component Nuxt3: Universal Component (단일 모델) Nuxt3에는 Server Component / Client Component 구분이 없다. 모든 컴포넌트는 SSR 시 서버에서 실행되고, hydration 후 클라이언트에서도 실행된다. <script setup> 하나로 모든 것을 처리한다. 브라우저 전용 코드 처리 4. Auto-imports Nuxt3의 핵심 기능. import 없이 사용 가능한 것들: components/ 폴더의 모든 컴포넌트 composables/ 폴더의 모든 composable

코드 리뷰를 하다 보면 "이 코드 좀 더 선언적으로 작성하면 좋겠는데요"라는 말을 종종 듣는다. 근데 막상 "선언적이 뭔지 설명해봐"라고 하면 정확히 말하기가 쉽지 않다. 처음 컴퓨터 공학과에서 선언적 프로그래밍과 절차적 프로그래밍의 개념을 숙지하고, 프론트엔드에 적용을 할 때 조차 이 구분이 명확하게 와닿지 않았다. 예전만 해도 목록에서 특정 조건을 만족하는 항목만 골라 새 배열을 만드는 코드를 for 루프로 짰고, 그게 잘못됐다는 생각을 해본 적이 없었다. 코드 리뷰를 스스로 돌이켜보면서 .filter() 로 쓰면 의도가 더 잘 드러난다는 것을 생각해보면서, 무엇(what)을 원하는 선언적 프로그래밍과 어떻게(how)를 원하는 절차적 프로그래밍이 단순히 스타일 차이가 아니라는 것을 깨닫게 되었다. 본래 프로그래밍의 시작은 절차적 프로그래밍이였다. 컴퓨터는 본래 절차적으로 작동한다. CPU는 명령어를 위에서 아래로, 순서대로 실행한다. 초기 프로그래밍 언어(FORTRAN, C)도 그 구조를 그대로 따랐으며, "데이터를 읽어라 → 조건을 확인해라 → 이 변수에 결과를 써라" 같은 방식으로 진행이 된다. JS도 초기에는 이 패러다임이 주류였다. for 루프로 배열을 순회하고, 변수에 값을 직접 쌓고, 콜백을 중첩했다. 지금도 JS 엔진 자체는 절차적으로 코드를 실행한다. 선언적 코드도 결국 런타임에서는 절차적 명령어의 연속이다. 선언적 프로그래밍은 그 절차적 세부 사항을 추상화 뒤로 숨긴다. 개발자는 무엇을(What) 원하는지를 표현하고, 어떻게(How) 할지는 추상화가 담당하게 한다. 두 방식의 내부 동작은 어떻게 다를까? 같은 결과이지만 신기하게도 다르게 표현이 될 수 있다. 배열에서 짝수만 골라 제곱한 결과를 만드는 코드를 두 방식으로 써보자. 두 코드는 실행 결과가 동일하다. 근데 읽히는 방식이 다르다. 절차적 코드는 루프 변수 i의 흐름을 따라가야 의도가 보인다. 선언적 코드는 .filter().map()이라는 서술만 봐도 의도가 드러난다. 런타임에서 실제로 무슨 일이 일어날까?

회사 사내에서 Vue 기술스택을 많이 사용하다보니, 자연스레 SCSS 를 많이 사용하게 된다. React 의 Emotion 등의 스타일, 그리고 최근 많이 사용하고 있는 Tailwind 의 경우에는 자연스럽게 내부 난수와 같은 값으로 클래스 명을 유니크하게 지정해주면서 스타일을 지정해준다. SCSS 는 스타일은 서비스 도메인의 바닥부터 함께 스타일 구조들을 천천히 쌓아나가며, 직접 이름을 짓고 붙여주는 과정을 진행하게 되는데 이를 사용해보았다면 CSS 클래스 이름을 어떻게 지어야 할지 고민을 했던 적이 있을 수 있다. 처음 CSS를 배웠을 때, 클래스 이름은 그냥 의미 있어 보이면 된다고 생각했다. .header, .menu, .button처럼. 회사 업무를 진행하면서 막상 생각치도 못한 곳에서 문제가 생겼다. 누군가 .button을 이미 쓰고 있다면, 거기에 내가 .button을 또 정의하면서 스타일이 충돌하게 된다는 것인데, 만약 스타일시트에 모듈과 같은 스코프가 정의되어있지 않다면 CSS의 특성상, 이건 단순한 실수가 아니라 구조적인 문제였다. 그때부터 "이름을 어떻게 지어야 하는가"가 진짜 문제처럼 느껴졌다. 그러다 — , __ 클래스 네임에 프리픽스가 붙는 클래스 네임들을 발견하게 되었고, 이게 뭔가 찾아보다가 포스팅을 시작하게 되었다 ^,^ .. 바로 BEM(Block Element Modifier)이라는 개념인데, CSS 클래스 네이밍 방법론 중 가장 오래되고, 가장 널리 쓰이는 방식이다. BEM은 왜 생겼을까? BEM은 러시아 인터넷 기업 Yandex에서 2005년경 내부적으로 사용하기 시작한 방법론이다. Yandex는 대규모 웹 서비스를 수십 명의 개발자가 함께 유지보수해야 했고, 스타일 충돌과 유지보수 어려움이 반복됐다. 2010년대 초, CSS 생태계에는 마땅한 기준이 없었다. 클래스 이름은 개발자마다 달랐고, 프로젝트가 커질수록 스타일 파일은 누구도 건드리기 싫은 영역이 됐다. OOCSS(Object-Oriented CSS)나 SMACSS 같은 개념들이 있었지만, 구체적인 네이밍 규칙까지 제시한 건 BEM이 처음이었다.

자바스크립트가 동적언어라서 런타임 시점에 타입을 지정해주고, 이것저것 마법같은 동작들이 많아 마법같은 언어라고 칭하기도 하지만, 자바스크립트 내부 엔진이 코드를 실행하는 방식은 생각보다 구조적이다. "왜 선언 전에 함수를 호출할 수 있지?", "왜 클로저는 외부 변수를 기억하고 있지?" 와 같은 질문들이 전부 하나의 개념으로 연결된다. 바로 실행 컨텍스트(Execution Context)로 부터 시작된다. 실행 컨텍스트는 무엇일까? 자바스크립트 엔진은 코드를 실행하기 전에 실행에 필요한 정보들을 하나의 구조체로 묶는다. 이게 실행 컨텍스트다. 변수가 어디에 있는지, this가 무엇을 가리키는지, 외부 스코프는 어디인지에 대한 모든 정보가 실행 컨텍스트 안에 들어있다. 실행 컨텍스트는 주로 세 가지 상황에서 생성된다. 실행 컨텍스트가 생성되는 시점 전역 코드 실행 시 → 전역 실행 컨텍스트 (Global Execution Context) 함수 호출 시 → 함수 실행 컨텍스트 (Function Execution Context) eval() 실행 시 → eval 실행 컨텍스트 (거의 사용 안 함) 실행 컨텍스트들은 콜 스택(Call Stack)이라는 구조에 쌓인다. 실행 컨텍스트의 내부 구조 실행 컨텍스트는 크게 세 가지로 구성된다. 핵심은 LexicalEnvironment다. 이것 역시 두 부분으로 나뉜다. outer 참조가 스코프 체인(Scope Chain)을 만든다. 변수를 찾을 때 현재 EnvironmentRecord에 없으면 outer를 타고 올라가게된다. inner에서 x를 참조하면: inner EC → outer EC → 전역 EC 순으로 탐색한다. 전역 EC에서 x: 1을 발견하고 반환한다. 실행 컨텍스트는 두 단계로 동작한다 실행 컨텍스트가 생성될 때 바로 코드를 실행하지 않는다. 먼저 생성 단계(Creation Phase)가 있고, 그 다음 실행 단계(Execution Phase)가 진행된다. 이 두 단계가 호이스팅(hoisting)의 실제 이유다.

React와 Vue를 함께 쓰다 보면 두 프레임워크 모두 지정된 포맷팅이 너무 다르기도 하고, 추상화 방식도 생각보다 달라서 Vue 를 쓰다가 React 를 사용하게 되면 혼동되는 경우가 많이 생긴다. 예전에 풀던 과제들도 다시 풀면 롤백되어 탈락하기도 하고.. React 를 Vue 의 template 문법처럼 사용하는 경우도 많아서, 천천히 돌아볼겸 두 프레임워크를 동시에 사용하는 사람들을 위해 다시 한번 정리를 하고자한다. 사실 두 프레임워크의 차이를 명확하게 알고있으면 되긴 하지만, React 에서는 한 파일에서 여러 모듈들을 임포트할 수 있고, Vue 의 경우에는 SFC (Single File Component) 이기 때문에 단 하나의 모듈만 임포트할 수 있다. 사실 자바스크립트라는 교집합이 존재하지만 이 과정에서 두 프레임워크의 차이를 명확하게 알고 있고, 어떤 방식에서 차이점을 가지고 있는지 알아야 프레임워크에서 추구하는 추상화가 가능하다는 생각이 들었다. 인터넷에서 여러 문서들을 참고하고, 또 여러 과제들을 진행하면서 느꼈던 부분들을 적은 내용들이라 아마 개발자들마다 코드에 대해 생각하는 부분들이 다를 수 있겠지만 여러 문서들을 읽으며 동의했던 부분들과 내가 생각한 좋은 코드에 대한 기준을 적은 문서이니 지나가시는 분들은 가볍게 보시면 좋을 것 같다 ^,^ .. React — 좋은 코드를 작성하는 방법 코드는 예측 가능해야 한다 좋은 코드의 기준은 하나라고 생각한다. 다음 줄이 어떻게 생겼을지 읽기 전에 예측할 수 있어야 한다. 이름, 구조, 인터페이스가 일관된 패턴을 따를수록 읽는 사람의 인지 부하가 줄어든다. 예측이 맞으면 빠르게 읽히고, 빗나가면 흐름이 끊긴다. 컴포넌트는 하나의 관심사만 가지는 것이 좋다 컴포넌트가 커지는 가장 흔한 이유는 "여기에 추가하면 빠르니까"다. 하지만 한 컴포넌트가 데이터 페칭, 레이아웃, 인터랙션을 모두 담당하면 어느 하나를 바꿀 때 다른 것이 영향을 받는다. ProductPage는 데이터를 가져오는 것에만 집중하고, ProductDetail은 레이아웃에만 집중하고, ProductActions는 인터랙션에만 집중한다. 각 컴포넌트를 독립적으로 테스트하고 교체할 수 있다.

Proxy는 JavaScript 객체에 대한 접근을 가로채서 중간에서 원하는 동작을 끼워 넣을 수 있는 기능이다. Vue 3의 반응형 시스템이 이 위에서 동작하고, MobX도 같은 방식을 쓴다. Vue 3를 공부하다가 reactive()로 감싼 객체의 프로퍼티를 직접 수정했는데 화면이 자동으로 업데이트되는 걸 보고 신기했다. React에서는 반드시 setState를 호출해야 하는데, Vue는 그냥 obj.count++만 해도 자동으로 반응성을 유지하는데, 내부에서 어떤 일이 일어나고 있을까? Proxy 이전에 라이브러리는 어떻게 만들어졌을까? 전에는 SPA 라는 개념 자체가 생소했고, MPA 개념으로 웹을 주로 사용해왔다. Proxy 라는 강력한 기능이 나오기 전에는 SPA 라이브러리는 어떻게 구성이 되었는지 너무 궁금했다. 현재는 React와 Vue를 섞어쓰다보니 메이저 버젼이 바뀌면서 아예 내부 패러다임이 변경된 Vue를 기준으로 알아보자면 Vue 3 이전, Vue 2는 Object.defineProperty()로 반응형을 구현했다. Object.defineProperty는 이미 존재하는 프로퍼티의 getter/setter만 가로챌 수 있다. 그래서 Vue 2에는 구조적인 한계가 있었다. 이 문제를 해결하려고 Vue 2는 배열 메서드를 직접 패치하고, Vue.set()이라는 특별한 API를 만들었다. 근본적인 해결이 아니라 우회였다. 2015년 ES6에 Proxy가 추가됐다. Vue 3는 2020년에 이 Proxy를 기반으로 반응형 시스템을 완전히 재설계했다. Proxy의 내부 동작 new Proxy(target, handler)는 target 객체를 감싸는 래퍼를 만든다. 이 래퍼에 대한 모든 작업(읽기, 쓰기, 삭제 등)이 handler의 트랩(trap) 을 통해 가로채진다. Reflect는 Proxy 트랩과 1:1로 대응하는 API다. 트랩 안에서 원래 동작을 수행할 때 사용한다. target[key]로 직접 접근하는 것과 결과는 같지만, receiver(프록시 자신)를 올바르게 처리하기 위해 Reflect를 쓰는 것이 안전하다.

JavaScript에서 모듈을 불러오는 방법은 두 가지다. Node.js가 오랫동안 사용해온 CJS(CommonJS) 와, ES2015 표준에 추가된 ESM(ES Modules) 이다. 라이브러리 문서에서 "This package is ESM only"라는 문구를 처음 봤을 때, 단순히 문법이 다른 것 정도로 생각했다. 그런데 파고들수록 두 시스템은 모듈을 불러오는 방식 자체가 근본적으로 달랐다. 단순히 require 대신 import를 쓰는 게 아니라, 브라우저와 런타임이 코드를 이해하는 방식이 바뀌는 것이었다. JavaScript에는 원래 모듈이 없었다? JavaScript가 처음 설계됐을 때 모듈 시스템은 없었다. 브라우저에서 스크립트 파일을 순서대로 나열하는 게 전부였다. 모든 변수가 전역 스코프에 쌓였다. 파일이 많아질수록 어떤 파일이 어떤 변수를 만드는지 추적하기 어려워졌고, 이름이 겹치면 나중에 로드된 쪽이 덮어썼다. 의존 순서를 틀리면 런타임에서야 에러가 났다. CJS — Node.js가 직접 만든 모듈 시스템 2009년 Node.js가 등장했다. 서버에서 수백 개의 파일을 다루려면 모듈 시스템이 필수였는데, 당시 JavaScript 표준에는 없었다. 그래서 Node.js가 직접 만든 게 CommonJS(CJS) 다. CJS의 내부 동작 require와 module.exports는 JavaScript 문법이 아니다. Node.js가 파일을 실행하기 직전에 모듈 래퍼 함수로 감싸서 인자로 주입하는 것들이다. require()는 그냥 함수다. 그래서 코드 어디서든 호출할 수 있다. require()가 호출되면 Node.js는 아래 순서로 동작한다. 핵심은 동기적이라는 것이다. require()가 호출되면 파일을 다 읽고 실행할 때까지 다음 줄로 넘어가지 않는다. CJS의 값 복사 방식 CJS에서 module.exports로 내보낸 값은 복사본이다. 원본이 바뀌어도 가져간 쪽에서는 모른다. count를 구조분해할 때 그 시점의 값(0)이 복사됐다. 이후 increment()로 원본 count가 바뀌어도, 복사본은 그대로다. 객체를 내보내면 참조가 공유되지만, 원시값은 항상 이 문제가 생긴다.

CSS로 레이아웃을 만들다 보면 요소들이 겹치는 상황이 생긴다. 모달, 툴팁, 드롭다운 같은 UI가 대표적이다. 이때 어떤 요소가 위에 올라올지를 제어하는 속성이 z-index다. 그런데 z-index는 단순히 "숫자가 크면 위에 온다"는 규칙으로 동작하지 않는다. 스태킹 컨텍스트(Stacking Context) 라는 경계 안에서만 비교되는 값이기 때문이다. z-index: 9999를 줬는데 다른 요소 뒤에 가려진 적이 있다. 분명히 숫자는 더 큰데, 원하는 대로 쌓이지 않았다. 한참을 디버깅하다가 결국 찾아낸 원인은 스태킹 컨텍스트를 이해하지 못한 채로 z-index를 쓰고 있었던 것이었다. 스태킹 컨텍스트는 무엇일까? 스태킹 컨텍스트(Stacking Context) 는 z축(화면 깊이) 방향으로 요소를 쌓는 독립적인 단위다. 각 스태킹 컨텍스트는 내부적으로 고유한 레이어 순서를 가지며, 외부 스태킹 컨텍스트와 완전히 독립된다. 쉽게 말하면, z-index 비교는 같은 스태킹 컨텍스트 안에서만 유효하다. 부모가 다른 스태킹 컨텍스트에 속해 있다면, 자식의 z-index 값이 아무리 커도 그 경계를 넘어갈 수 없다. 위 구조에서 A-1의 z-index가 9999여도, B보다 아래에 쌓인다. A 자체가 z-index: 1로 B(z-index: 2)보다 낮기 때문이다. A-1은 A의 스태킹 컨텍스트 안에서만 의미가 있다. 스태킹 컨텍스트는 언제 만들어질까? 모든 요소가 스태킹 컨텍스트를 생성하는 건 아니다. 특정 CSS 속성을 가진 요소가 새로운 스태킹 컨텍스트를 만든다. 이 중에서 실수가 가장 많이 발생하는 경우는 transform과 opacity다. 애니메이션 성능 최적화를 위해 transform: translateZ(0) 이나 will-change: transform을 추가했다가, 의도치 않게 스태킹 컨텍스트가 생성되어 z-index가 꼬이는 경우가 많다. 같은 스태킹 컨텍스트 안에서의 쌓임 순서 스태킹 컨텍스트 안에서도 요소들은 일정한 순서로 쌓인다. z-index를 명시하지 않아도, position: relative를 추가하는 것만으로도 일반 블록 요소보다 위에 올라온다. z-index가 auto인 경우 새 스태킹 컨텍스트를 만들지 않으면서도 쌓임 순서에 영향을 준다.

DOM을 조작하다 보면 분명히 코드는 간단한데, 스크롤 할 때마다 버벅이고, 애니메이션은 뚝뚝 끊긴다. 레이아웃 작업이 수백 밀리초를 잡아먹고 있는데, 이 원인은 바로 레이아웃 스레싱(Layout Thrashing)이다. 변경이 생길 때 브라우저가 거치는 단계 (픽셀 파이프라인) 초기 로드 이후, JS로 DOM이 변경될 때마다 브라우저는 아래 흐름을 다시 탄다. Style: 변경된 요소에 어떤 CSS 규칙이 적용되는지 재계산 (DevTools에서는 "Recalculate Style"로 표시) Layout: 각 요소의 위치와 크기를 계산 (Reflow라고도 부른다) Paint: 픽셀을 채우는 단계 Composite: 레이어를 합성 이 중에서 Layout 단계가 제일 비싸다. 요소 하나의 크기가 바뀌면, 연관된 모든 요소의 위치를 다시 계산해야 하기 때문이다. 브라우저는 JavaScript 실행 중에 발생하는 DOM 변경들을 즉시 반영하지 않는다. 일괄 처리(batch)해서 한 번에 처리한다. 레이아웃 스레싱은 바로 이 배치 처리를 무력화할 때 발생한다. 픽셀 파이프라인이란? 브라우저 렌더링 파이프라인은 "페이지를 처음 만드는 과정" 이라면, 픽셀 파이프라인은 "만들어진 페이지를 또 다시 갱신하는 과정"을 의미한다. 픽셀 파이프라인은 무조건 변경될 때마다 전부 다 실행되는 것이 아닌 어떤 것을 변경했냐에 따라 순서가 달라진다. width 변경 → Style → Layout → Paint → Composite color 변경 → Style → Paint → Composite transform → Style → Composite (단, opacity, transform은 Style/Layout/Paint를 건너뛰고 Composite만 실행) 레이아웃 스레싱이 무엇일까? 레이아웃 스레싱(Layout Thrashing)은 JavaScript가 DOM의 기하학적 속성을 읽고 쓰는 작업을 번갈아 가면서 반복할 때 발생한다. 왜 이게 문제냐면 ^,^ .. boxes[i].style.width를 변경하면 브라우저는 레이아웃을 무효(dirty)로 표시한다

npm install을 치고 멍하니 기다린 적이 있을 것이다. node_modules가 1GB를 넘어서 당황했던 경험도. 팀원이 yarn을 쓰는데 나는 npm을 써서 package-lock.json과 yarn.lock이 동시에 생겨버린 아찔한 기억도. 패키지 매니저는 워낙 당연한 도구라 깊이 생각하지 않고 그냥 쓰게 되는데, 사실 선택에 따라 설치 속도, 디스크 사용량, 팀 협업 경험이 꽤 크게 달라진다. 요즘 npm에서 pnpm이나 Yarn Berry로 갈아타는 팀이 늘고 있다. 어떤 패키지 매니저가 무엇이 다른지, 내부적으로 어떻게 동작하는지 제대로 정리해보려 한다. 패키지 매니저의 역사를 짧게 짚고 넘어가면 2010년 — npm이 Node.js와 함께 등장. 사실상 표준이 됨 2016년 — Facebook이 Yarn(v1) 출시. npm의 느린 속도와 비결정적 설치 문제를 해결하기 위해 2017년 — npm v5에서 package-lock.json 도입. Yarn의 장점을 상당 부분 흡수 2018년 — pnpm이 주목받기 시작. 디스크 효율성과 속도에서 차별화 2020년 — Yarn Berry(v2) 출시. node_modules를 아예 없애는 PnP 방식 도입 2022년 — Bun 등장. JS 런타임과 패키지 매니저를 통합한 새로운 접근 2023년 — Deno 2.0에서 npm 호환성 강화 패키지를 어떻게 설치하는가? — 핵심은 node_modules 구조 패키지 매니저들의 가장 근본적인 차이는 패키지를 디스크에 어떻게 배치하는가에 있다. npm — 플랫 호이스팅(Flat Hoisting) 초창기 npm(v1~v2)은 의존성을 중첩(nested) 구조로 설치했다. package-a가 package-b를 필요로 하고, package-b가 package-c를 필요로 하면 이렇게 깊이 중첩됐다. Windows에서는 경로 길이 제한(260자)에 걸려 설치가 실패하는 일도 있었고, 같은 패키지가 여러 곳에 중복 설치되어 디스크를 낭비했다. npm v3부터는 플랫 호이스팅을 도입했다.

내가 노드 서버를 언제 켜놓았더라? 하면서 새로운 포트번호의 localhost 서버가 실행되어 포트 번호를 직접 입력해주었던 경험.. 그래서 포트 번호를 3001로 바꾸고, API 서버는 8080인지 3001인지 헷갈리고, 어제 열어둔 브라우저 탭은 이미 죽은 서버를 가리키는 문제점들이 모든 프론트엔드 개발자라면 한번 쯔음 모두 경험해본다. 거기에 요즘 AI 코딩 에이전트까지 쓰게 되면 문제가 더 심해지는데, 에이전트가 서비스 포트를 추측하다가 틀려서 엉뚱한 곳에 요청을 보내는 일이 생긴다. 이 문제들은 사실 전부 포트 번호라는 개념에서 비롯된다. 포트 번호는 원래 개발자가 매번 의식해야 할 대상이 아니다. 네트워크 계층의 구현 세부사항인데, 어쩌다 보니 우리가 매일 외우고 관리해야 하는 것이 되어버렸다. Portless는 바로 이 문제점들을 지적하기 위해 나온 개념이다. Portless가 무엇일까? 포트 번호를 이름 기반의 안정적인 로컬 URL로 바꿔주는 도구 localhost:3000 대신 my-app.localhost 같은 URL로 앱에 접근할 수 있게 된다. 그리고 이 URL은 세션이 바뀌어도, 컴퓨터를 껐다 켜도 항상 동일하게 유지된다. 내부적으로는 경량 로컬 프록시가 동작하는 방식인데, 실제 앱은 여전히 포트에 바인딩되지만 그 포트를 Portless가 알아서 관리해준다. 개발자는 포트를 몰라도 되는 것이다. 4000~4999 범위에서 빈 포트를 자동으로 찾아 PORT 환경변수로 주입하고, HOST는 127.0.0.1로 설정해 IPv4 루프백에 바인딩한다. 기존 방식 http://localhost:3000 Portless 사용 시 http://my-app.localhost 어떤 문제를 해결하려고 했을까? 포트 충돌과 관리 피로 멀티 서비스 프로젝트를 하다 보면 포트 관리가 은근히 번거롭다. 프론트엔드는 3000, 백엔드 API는 8080, 어드민은 3001... 팀마다 포트 번호 컨벤션도 다 다르고, 로컬 환경에 다른 뭔가가 실행 중이면 충돌이 생긴다. EADDRINUSE라는 에러를 처음 봤을 때의 당혹감을 기억하는 사람이 많을 것이다.

React를 사용하면서 여러 기능들이 추가되며 화면에서 사용되는 컴포넌트들이 존재하는 경우가 많아진다. 이때, 확장성을 위해 고려할 수 있는 2가지 정도의 컴포넌트 설계 패턴에 대해서 알아보자. Flat 패턴 Flat 컴포넌트는 내부 구조를 감추고, 대부분의 변형을 props 로 제공하는 방식을 의미한다. 위의 방식은 사용은 직관적이지만, Flat API 설계의 단점은 분명하다. 시스템이 상정하지 않는 요구사항이 등장하면, props 는 끝없이 늘어나게 된다는 한계점을 가지고 있다. actionLabel 을 hover 했을 때, callback 을 전달하고 싶을 때, button 이 아니라 anchor 로 그려 href 를 전달하고 싶을 때는 이런 flat 패턴이 오히려 확장과 유지보수를 어렵게 할 수 있다. Compound 패턴 하위 컴포넌트를 제공하고, 제품 팀이 직접 조합하여 사용하도록 제공하는 방식이다. 사용하는 쪽에서는 아래와 같이 활용할 수 있다. Flat 패턴과 비교했을 때, Compound 패턴의 장점은 유연함이다. 시스템이 미리 예측하지 못한 레이아웃도 조합으로 해결이 가능하며, 확장 지점이 코드 레벨에서 자연스럽게 제공되는 것을 확인할 수 있다. 다만, Compound 패턴도 만능은 아니며, 사용하는 측에서 구현 난이도와 코드량이 늘어나게 되는 특징을 가지고 있다. 변형 여지가 거의 없는 컴포넌트까지 Compound 패턴으로 컴포넌트화 하게 되면 사용하기 오히려 불편해지는 상황이 발생한다. 어떤 것을 사용해야 좋은 패턴 구조일까? 두 패턴을 비교해보자, 공통 컴포넌트 틀에서 title 만이 다른 상태라고 가정했을 때, Flat 패턴과 Compound 패턴은 아래와 같이 도출될 수 있다. 둘의 차이를 확인해보면 조립하는 쪽과, 조립된 상태에서 사용법을 통해 컨트롤하는 것과 같이 둘의 차이는 명확한 것을 확인할 수 있다. Flat API 는 사용 방법 또한 간결하고, Card 컴포넌트 외에는 알아야할 것들이 그다지 많지 않다. 반면 Compound API 는 개발자가 Card 구조를 이해하고 있어야하며, Header 안에 Title 들어가야하는지, Body 는 필수인지 등 학습해야할 것들이 많다. dot operator 로 하위 컴포넌트들을 탐색할 수 있지만, 올바른 조합 방법을 찾는 것은 또 다른 러닝 커브가 된다. 결과적으로 친절한 도구보다 번거로운 도구로 경험될 수 있다.

사용자가 페이지를 떠날 때마다 백엔드에 몇가지 요청을 보내려고 할 때, 두가지 정도의 접근 방식이 존재한다. 바로 navigator.sendBeacon 또는 fetch + keepalive 방식이다. 두 방식의 트레이드 오프 Navigator.sendBeacon Navigator.sendBeacon의 장점 페이지가 언로드될 때 데이터를 전송하도록 특별히 설계되었다. 우선순위가 낮은 비동기식으로 페이지 언로드 프로세스를 차단하지 않는다. (네트워크 탭의 우선순위 참고) 브라우저는 페이지가 닫힌 후에도 데이터 전송을 완료한다. 간편한 API 인터페이스로 사용할 수 있다. POST 메서드를 주로 지원하기 때문에, 자동으로 POST 메서드를 사용한다. 응답을 처리할 필요없으며, 단방향 데이터에 이상적이다. Navigator.sendBeacon의 제약사항 POST 요청만을 지원한다. 응답 내용을 받을 수 없다. 크기 제한이 있다. (크롬의 경우 약 64KB) 사용자 커스텀 헤더 지원을 하지 않는다. 사용 예시 Fetch + keepalive Fetch + keepalive의 장점 모든 HTTP 메서드 (GET, POST, PUT 등)을 지원한다.

IndexedDB는 기술 면접을 준비할 때 브라우저의 로컬 저장소에 관련된 내용들을 배우면서, 한번쯔음 들어보았을 용어이다. 사실 쿠키를 많이 사용해보았지, IndexedDB의 경우에는 사용할 일이 많이 없다고 생각해 실제로 써보지는 못했는데 이번에 게시글 자동저장 기능을 구현해보면서 여러 로컬 저장소들과의 특징들을 비교하며 도입을 하고자했다. 객체 형태의 저장 형태 · 대용량 저장소 · 비동기 처리 등의 특징과 메인 스레드를 블로킹하지 않는 특성들이 IndexedDB가 자동 저장에 적합하다고 생각이 들었다. 오늘은 IndexedDB 를 활용해보며 배웠던 내용들을 복기차 포스팅을 해보려고 한다. IndexedDB란? 브라우저에 내장된 비동기 NoSQL 데이터베이스로, 대용량 및 구조화된 데이터를 영구적으로 저장할 수 있는 클라이언트 DB이다. IndexedDB는 웹이 단순 문서에서 오프라인 및 대용량 데이터를 다루는 어플리케이션으로 진화하면서, 기존 저장소(Local Stoarge, Cookie)가 이러한 요구 조건들을 감당하지 못해 등장하게 되었다. 초창기 웹 저장소의 한계점 우리가 흔히 알고 있는 Cookie 와 LocalStorage 와 같은 로컬 스토리지의 경우에는 아래와 같은 한계점을 가지고 있었다. Cookie 4KB의 용량을 가진다. 모든 요청마다 서버로 전송된다. LocalStorage / SessionStorage ~5MB의 용량을 가진다. 동기 API로 메인 스레드의 블로킹을 한다. 문자열만 저장이 가능하며, 인덱싱 및 검색이 불가하다. (별도 로직 필요) 브라우저에서 제공하는 기존 로컬 저장소들은 설정 값을 저장하는 저장소 수준이지, DB 개념으로 사용하기에는 무리가 있었다. 2008 ~ 2012년 Gmail, Google Docs, Facebook 등의 웹 서비스들이 급부상되면서 수천수만 건의 데이터가 저장되어야하고 오프라인에서도 동작을 해야했다. 또 빠른 검색이 필요하며 UI 멈춤 없이 비동기 처리가 가능해야했기에 브라우저 자체에서 DB가 필요하다고 느끼게 되었고, 기존 브라우저의 로컬 저장소로는 해결이 되지 않던 문제를 IndexedDB를 정의하며 해결하고자 했던 것이다.

NPM Audit 이란? 2018년에 발표된 NPM v6에서 처음 도입되었다. 이 명령어는 프로젝트의 의존성 트리를 검사하여 보안 취약점을 찾고, 이를 보고하는 기능을 제공한다. NPM 사용자들이 프로젝트에서 사용하고 있는 패키지들의 보안 상태를 쉽게 확인하고, 필요한 경우 취약점을 수정할 수 있도록 하기 위한 중요한 기능이다. npm audit 명령어는 CLI 커맨드이며, Node Security Platform (NSP)의 데이터베이스에서 취약점에 대한 정보를 얻을 수 있다. NPM Audit 활용 방안 사용 커맨드는 비교적 간단하다. npm audit을 통해 패키지 내의 의존성 트리들을 검사할 수 있고, 관련하여 프로젝트 내에 패키지들이 어떤 위험성을 가지고 있는지 알려준다. 여기서 취약성의 심각도를 알려주는 Severity 라는 속성이 존재한다. 이는 취약성의 심각도를 나타내며, 취약점의 영향과 악용 가능성에 따라 결정된다. 기본적으로 취약점은 CVSS (Common Vulnerability Scoring System)에 의해 스코어와 심각도를 부여받는다. Tier Description Critical Highest severity; requires immediate action as it can be easily exploited, often remotely. (최고 심각도; 즉각적인 조치가 필요하며 원격으로 쉽게 악용될 수 있음) 가장 위험한 취약점을 의미한다. 즉시 수정 조치를 필요로 한다. 원격 공격에 노출될 수 있다. High Very serious; should be addressed as quickly as possible. (매우 심각함; 가능한 한 빨리 해결해야 함) 심각한 보안 취약점을 의미한다. 최우선적으로 수정 조치를 필요로 한다. 빠른 시일 내 패치를 권장한다. Moderate Can become risky under specific conditions; address as time allows.