Psychogrammer

Next.js 15 instrumentation이 프로덕션에서 안돌아간다면

Psychogrammer — Fri, 20 Jun 2025 22:17:19 +0900

Next.js 앱에서 서버 시작 시점에 딱 한 번만 실행되는 초기화 로직이 필요했다. 데이터베이스 연결, 캐시 설정, 외부 서비스 연결 같은 것들 말이다. 공식 문서를 보니 instrumentation.ts 파일을 만들면 앱 시작 시점에 한 번 돌아가는 기능이 있었고 register 함수를 export하면 된다고 나와있었다.

// instrumentation.ts
export async function register() {
  console.log('서버 초기화 중...');
  // 초기화 로직
}

개발 환경에서는 잘 되더라. npm run dev 하면 콘솔에 로그도 잘 찍히고, 초기화도 정상적으로 실행됐다. 그런데 프로덕션 빌드 후 실행하니까 아무것도 안 된다.

npm run build
npm start

콘솔에 아무런 로그도 없고, 초기화 코드도 실행되지 않았다. 뭔가 이상해서 GitHub 이슈들을 찾아봤더니 나만 겪는 문제가 아니었다.

발견한 이슈들

Next.js 공식 레포지토리에서 관련 이슈들을 여러 개 발견했다.

특히 Next.js 14.0.5-canary.29에서 발견한 건데, 프로덕션 빌드 후 서버를 시작할 때 register 함수가 자동으로 호출되지 않고, 첫 번째 라우트를 방문해야만 실행되는 문제였다. 하지만 나는 Next.js 15를 사용했고, instrumentation 기능이 정식으로 안정화되어서 experimental.instrumentationHook 설정을 config에 작성하지 않아도 기본적으로 동작한다.

이 기능 자체가 성능 추적이나 디버깅, 관찰 가능성 도구 통합 목적으로 만들어진 거라 어느 정도는 예상된 동작이라고 생각했다.

문제는 서버 시작과 동시에 실행되어야 할 초기화 로직이 사용자의 첫 번째 HTTP 요청에 의존한다는 점이었다. 서버가 시작되자마자 데이터베이스 연결이나 환경 설정 같은 걸 초기화해야 하는데, 누군가 웹사이트에 접속해야만 그 코드가 돌아간다니... 결국 다른 방법을 찾아야 했다.

해결책 찾기

instrumentation 기능 자체가 불안정하고, next 팀에서도 동작 방식을 블랙 박스로 숨겨놓으니 다른 방법을 써야겠다고 생각했다. 여러 방법을 시도해봤는데, 각각 장단점이 있었다.

1. Next.js 커스텀 서버

가장 확실한 방법은 Next.js 내장 커스텀 서버를 사용하는 것이다.

// server.js
const { createServer } = require('http');
const { parse } = require('url');
const next = require('next');

const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();

async function initialize() {
  console.log('  서버 초기화 중...');

  // 여기에 초기화 로직 작성
  // await connectDatabase();
  // await setupCache();

  console.log('✅ 초기화 완료');
}

app.prepare().then(async () => {
  await initialize();

  createServer((req, res) => {
    const parsedUrl = parse(req.url, true);
    handle(req, res, parsedUrl);
  }).listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
});

package.json에서 start 스크립트도 바꿔준다:

{
  "scripts": {
    "start": "node server.js"
  }
}

이렇게 하면 Next.js 서버가 준비된 직후에 초기화 함수가 확실히 실행된다.

2. 모듈 레벨에서 실행

좀 더 간단한 방법도 있다. Next.js 앱 내에서 모듈이 처음 로드될 때 초기화하는 방식이다.

// lib/server-init.ts
let initialized = false;

async function initializeApp() {
  if (initialized) return;

  console.log('  앱 초기화 중...');

  // 초기화 로직

  initialized = true;
  console.log('✅ 앱 초기화 완료');
}

// 서버에서만 실행
if (typeof window === 'undefined') {
  initializeApp();
}

그리고 app/layout.tsx에서 이 모듈을 import만 해주면 된다.

// app/layout.tsx
import '@/lib/server-init'; // 이것만 추가

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

3. 좀 더 정교한 조건 처리

빌드 타임과 런타임을 확실히 구분하고 싶다면 이런 방법도 있다.

// 런타임에서만 실행 (빌드 타임 제외)
if (
  typeof window === "undefined" && 
  process.env.NEXT_PHASE !== "phase-production-build" &&
  process.env.NEXT_PHASE !== "phase-export" &&
  !process.env.NEXT_BUILD_ID
) {
  process.nextTick(() => {
    initializeApp().catch((error) => {
      console.error("앱 초기화 중 오류 발생:", error);
    });
  });
}

이렇게 하면 Next.js가 빌드 중일 때는 실행되지 않고, 실제 서버가 돌아갈 때만 실행된다.

이 방법이 최초 1번만 실행되는 이유는 Node.js의 모듈 캐싱 시스템 때문이다. Node.js는 한 번 로드된 모듈을 메모리에 캐시해두고, 같은 모듈을 다시 import할 때는 새로 실행하지 않고 캐시된 결과를 재사용한다. 따라서 lib/server-init.ts 파일이 처음 import될 때만 최상위 레벨의 코드가 실행되고, 그 이후에는 아무리 많은 컴포넌트에서 이 모듈을 import해도 초기화 코드는 다시 실행되지 않는다.

이는 RSC(React Server Components)와는 직접적인 관련이 없는, Node.js 자체의 기본 동작이다. 다만 Next.js App Router 환경에서는 layout.tsx에서 모듈을 import할 때 서버에서 렌더링되면서 초기화가 실행되는 것뿐이다. 여기에 initialized 플래그를 추가로 사용해서 혹시 모를 중복 실행도 방지하고, typeof window === 'undefined' 체크로 서버 환경에서만 실행되도록 보장하는 이중 안전장치를 마련한 셈이다.

결론

Next.js 15에서 instrumentation.ts는 개발 환경에서는 잘 되지만 프로덕션에서는 신뢰할 수 없다. 특히 standalone 빌드나 Docker 환경에서는 더더욱 그렇다. 당분간은 커스텀 서버를 사용하거나 모듈 레벨에서 초기화하는 방식을 쓰는 게 좋겠다. 개인적으로는 커스텀 서버 방식을 추천한다. 좀 더 명시적이고 제어 가능하기 때문이다. 어차피 프로덕션에서는 확실한 게 최고다.

Elasticsearch 대용량 데이터 파이프라인 구축기 - 수십억 건 데이터를 실시간으로 처리하는 법

Psychogrammer — Thu, 19 Jun 2025 17:41:45 +0900

문제 상황

어느 날 갑자기 팀원이 찾아와서 말했다.

"지금 로그에서 사용자 선호 국가 데이터를 시각화하는데, 5개를 고른 유저와 1개만 고른 유저의 데이터가 같이 쌓이고 있어서 왜곡이 생기는 것 같아요. 국가별로 광고 캠페인을 집행해야하는데, 빨리 확인해볼 수 있을까요?"

맞는 말이었다. '한국'만을 선호하는 사용자와 5개 국가 중 하나로 한국을 포함시킨 사용자의 데이터가 동일한 가중치로 집계된다면, 실제 선호도를 제대로 반영하기 어려울 것이다.

"그럼, 선택한 개수에 따라 가중치를 계산해서 필드로 제공해드릴까요? 예를 들어 1개 선택하면 1.0, 5개 선택하면 각각 0.2씩 부여하는 식이면 정확하진 않아도, 지금보다는 훨씬 정확할 거에요."

팀원도 좋은 아이디어라고 동의하며 바로 현재 상황을 분석하기 시작했다. 기존 Elasticsearch에는 이미 수십억 건의 로그가 쌓여있었고, user.preferences.preferRegion 필드는 존재했지만 가중치 필드는 없는 상황이었다. 더욱이 이 문제는 엄청난 데이터가 실시간으로 계속 유입되고 있다는 점이었다.

첫 번째 접근: Update By Query의 함정

처음 생각은 간단했다. "그냥 update_by_query로 기존 데이터를 업데이트하면 되겠네!"

POST /*-log-[service]-*/_update_by_query
{
  "script": {
    "source": """
    def preferRegion = ctx._source.user?.preferences?.preferRegion;
    def size = 0;
    
    if (preferRegion instanceof String) {
      size = (preferRegion == "ALL") ? 0 : 1;
    } else if (preferRegion instanceof List) {
      size = preferRegion.size();
    }
    
    if (size >= 5) ctx._source.preferRegion_weight = 0.2;
    else if (size == 4) ctx._source.preferRegion_weight = 0.25;
    // ... 이하 생략
    """
  }
}

테스트 인덱스로 돌려보니까... 1N억 건 처리해야하는데 대략 80시간이 걸릴 것 같다고 나왔다. 이거 운영에서 돌리면 서비스 터진다. 근데 로그 특성상 최신 로그를 반영하면 된다는 것을 알고, 최근 24시간 데이터부터 처리해볼까?" 싶어서 범위를 좁혀서 시도해봤다.

```json

POST /*-log-[service]-*/_update_by_query
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-24h"
      }
    }
  },
  "script": {
    "source": "..."
  }
}

최근 하루 데이터는 대략 1000만 건 정도였는데, 이것도 30분은 걸렸다. 그리고 무엇보다 치명적인 문제가 있었다 - 새로 들어오는 데이터에는 여전히 가중치가 추가되지 않는다는 것! 매일 이런 식으로 배치를 돌려야 한다면 운영 부담이 너무 클 것 같았다.

두 번째 시도: Ingest Pipeline 발견

다른 방법을 찾아보다가 Ingest Pipeline이라는 걸 알게 되었다. 새로 들어오는 데이터에 자동으로 전처리를 적용하는 방식이었다.

json

PUT _ingest/pipeline/add_region_weight
{
  "description": "Add preferRegion_weight based on preferRegion size",
  "processors": [
    {
      "script": {
        "source": """
        if (ctx.user?.preferences?.preferRegion != null) {
          def preferRegion = ctx.user.preferences.preferRegion;
          def size = 0;
          
          if (preferRegion instanceof String) {
            size = (preferRegion == "ALL") ? 0 : 1;
          } else if (preferRegion instanceof List) {
            size = preferRegion.size();
          }
          
          if (size >= 5) ctx.preferRegion_weight = 0.2;
          else if (size == 4) ctx.preferRegion_weight = 0.25;
          else if (size == 3) ctx.preferRegion_weight = 0.33;
          else if (size == 2) ctx.preferRegion_weight = 0.5;
          else ctx.preferRegion_weight = 1.0;
        } else {
          ctx.preferRegion_weight = 1.0;
        }
        """
      }
    }
  ]
}

테스트해보니 잘 작동했다. 하지만 여기서 첫 번째 삽질이 시작되었다.

세 번째 난관: Index Template 우선순위 지옥

파이프라인만 만들어서는 새로 생성되는 인덱스에 자동으로 적용되지 않았다. Index Template이 필요했다.

json

PUT _index_template/log-service-template
{
  "index_patterns": ["*-log-[service]-*"],
  "priority": 200,
  "template": {
    "settings": {
      "index.default_pipeline": "add_region_weight"
    }
  }
}

그런데 이게 웬걸? 에러가 터졌다.

index template [log-service-template] has index patterns [*-log-[service]-*] 
matching patterns from existing templates with patterns that have the same priority [200]

알고 보니 Elasticsearch에는 수많은 기본 템플릿들이 있었고, 다들 200을 사용하고 있었다. 500으로 올려도 안 되고, 1000으로 올려도 안 되고... 결국 3000으로 올려서야 성공했다.

json

{
  "index_patterns": ["*-log-[service]-*"],
  "priority": 3000,
  "template": {
    "settings": {
      "index.default_pipeline": "add_region_weight"
    }
  }
}

네 번째 깨달음: 기존 인덱스는 따로 처리해야 한다

Template은 새로 생성되는 인덱스에만 적용된다는 걸 뒤늦게 알았다. 기존 인덱스들은 수동으로 파이프라인을 적용해야 했다.

json

PUT /*-log-[service]-*/_settings
{
  "index.default_pipeline": "add_region_weight"
}

다행히 이 작업은 메타데이터만 수정하는 거라 몇 초 만에 끝났다.

가장 중요한 건 제대로 작동하는지 확인하는 것이었다. _simulate API를 사용해서 파이프라인을 테스트해봤다.

json

POST _ingest/pipeline/add_region_weight/_simulate
{
  "docs": [
    {
      "_source": {
        "user": {
          "preferences": {
            "preferRegion": ["KR", "US"]
          }
        }
      }
    }
  ]
}

결과를 보니 정확히 0.5가 나왔다. 드디어 제대로 작동한다!

운영 모니터링과 지속적인 관리

파이프라인을 적용한 후에는 지속적인 모니터링이 필요했다. 실제 데이터에 필드가 잘 추가되고 있는지 확인하는 쿼리를 만들었다.

json

GET /*-log-[service]-*/_search
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-1h"
      }
    }
  },
  "_source": ["@timestamp", "preferRegion_weight", "user.preferences.preferRegion"],
  "size": 10
}

가중치 분포도 확인해서 의도한 대로 처리되고 있는지 체크했다.

json

GET /*-log-[service]-*/_search
{
  "size": 0,
  "aggs": {
    "weight_distribution": {
      "terms": {
        "field": "preferRegion_weight",
        "size": 10
      }
    }
  }
}

마지막 함정: Kibana에서 필드가 안 보인다

Kibana Discover에서 새 필드가 보이지 않았다. 알고 보니 Data View에서 필드 목록을 새로고침해야 했다. Stack Management → Data Views → Refresh field list를 누르니까 드디어 필드가 보였다.

마치며

이번 작업을 통해 배운 것들은 아래와 같다.

Ingest Pipeline 잘쓰자: Update By Query로 몇 시간 걸릴 작업을 실시간으로 처리할 수 있다. 새로 들어오는 데이터에 자동으로 적용되니까 한 번 설정해놓으면 끝이다.

Index Template 우선순위: Elasticsearch 기본 템플릿들이 생각보다 많다. 사용자 정의 템플릿은 1000 이상의 높은 우선순위를 사용하는 게 안전하다.

단계별 검증의 중요성: _simulate API로 파이프라인 로직을 미리 검증하고, 실제 데이터로 테스트하고, Kibana UI까지 확인하는 전체 플로우를 검증해야 한다.

지속적 모니터링: 파이프라인을 적용한 후에도 실제 데이터 적용률, 성능 영향, 가중치 분포 등을 지속적으로 모니터링해야 한다.

결국 처음 예상했던 것보다 훨씬 복잡했지만, 한 번 제대로 구축해놓으니 매일 수백만 건의 데이터가 자동으로 전처리되고 있다.

Docker COPY에서 node_modules 충돌 해결하기

Psychogrammer — Mon, 2 Jun 2025 19:05:46 +0900

turborepo + pnpm 환경을 도커 설정을 수정하다가 흥미로운 에러를 만났다.

ERROR: failed to solve: cannot copy to non-directory: 
/var/lib/docker/overlay2/.../app/apps/chat/node_modules/typescript

node_modules 관련 충돌인 건 분명한데, git에는 node_modules가 없는 상황이라 원인 파악이 필요했다.

상황 분석

현재는 캐시 최적화를 위해 다음과 같은 Dockerfile 구조를 사용하고 있었다.

COPY apps/chat/package.json ./apps/chat/package.json
RUN pnpm install  
COPY apps ./apps  # 여기서 에러 발생

git 상태를 확인해보니 깨끗했다:

$ git status  
nothing to commit, working tree clean

$ ls apps/chat/
src/ public/ package.json # node_modules 보이지 않음

그런데 왜 충돌이 발생할까?

원인 발견

Docker 컨테이너 내부에서 일어나는 일을 살펴봤다.

pnpm install 실행 → 컨테이너 내부에 apps/chat/node_modules/ 생성
COPY apps ./apps 실행 → 로컬의 apps 폴더를 같은 위치에 복사 시도
경로 충돌 발생

그런데 로컬 인스턴스를 다시 확인해보니

$ ls -la apps/chat/
drwxr-xr-x  3 user user 4096 Apr 23 15:05 node_modules
-rw-r--r--  1 user user 1122 May  9 15:40 package.json

아, 로컬 개발 과정에서 생성된 node_modules가 실제로 존재했다. .gitignore로 git에는 올라가지 않았지만 파일시스템에는 있었던 것이다..!

.dockerignore 이슈

당연히 .dockerignore를 설정해뒀다.

node_modules/
**/node_modules/
apps/*/node_modules/

그런데 왜 node_modules가 복사가 된될까? .dockerignore는 COPY . . 같은 명령어에서 해당 파일들을 아예 제외해야 하는데 말이다.

Docker 빌드 캐시나 pnpm의 특수한 링크 구조 때문에 제대로 작동하지 않는 것 같았다. --no-cache 옵션으로 빌드해봐도 동일한 에러가 발생했다.

해결 방법

임시 해결

우선 로컬 node_modules를 제거하고 테스트해봤다:

mv apps/chat/node_modules apps/chat/node_modules.bak
docker build -t test .  # 성공!

예상대로 충돌할 파일이 없으니 정상 빌드됐다.

포인트 짚고 넘어가기

Docker COPY의 동작

같은 경로에 다른 타입(파일 vs 폴더)이 있으면 충돌 발생
.dockerignore가 항상 예상대로 작동하지 않을 수 있음

pnpm workspace 특성

복잡한 심볼릭 링크 구조로 일반적인 npm과 다른 동작
Docker 환경에서는 추가 고려사항 필요

실무 관점

이론적 최적화보다 안정적 빌드가 우선
로컬 개발 환경의 부산물도 Docker 빌드에 영향

마무리

git에는 없지만 로컬 파일시스템에 존재하는 node_modules가 원인이었고, .dockerignore가 예상대로 작동하지 않는 상황이 겹쳤다. 결국 node_modules를 없애서 해결한 간단한 문제였다. Docker 환경에서 당연히 로컬 개발 환경의 상태도 함께 고려해야 한다는 점을 다시 한번 확인했다.

Tailwind v4 도입하다가 monorepo 빌드 시스템을 뜯어고친 썰

Psychogrammer — Sun, 1 Jun 2025 19:01:31 +0900

Currency 앱에 새로 나온 Tailwind v4를 적용해보고 싶었다. 기존 앱들은 v3를 쓰고 있었는데, "각각 따로 빌드하니까 상관없겠지"라고 생각했던 게 착각이었다. PostCSS 설정이 충돌하면서 빌드가 망가지기 시작했고, 이를 해결하려다 보니 결국 전체 monorepo 구조를 뜯어고치게 됐다.

일단 Tailwind v4 적용했던 것

Tailwind v4의 새로운 CSS 엔진이 궁금해서 Currency 앱에 적용한 코드다. 공식 문서를 보니 설정 방법이 꽤 달라져 있었다.

// apps/currency/vite.config.ts
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [
    tailwindcss(), // v4는 Vite 플러그인으로 모든 걸 처리
  ]
})

기존 v3처럼 별도의 PostCSS 플러그인이 필요 없다는 게 신기했다. 일단 적용해보니 잘 동작했다. "이거 쉽네?"라고 생각했는데 터보 빌드를 돌려보니 문제가 생겼다.

첫 번째 문제: PostCSS 설정 충돌

터보가 전체 앱들을 빌드할 때 PostCSS 설정이 뒤섞이기 시작했다. Currency 앱의 CSS는 제대로 생성되는데, 다른 앱들의 CSS가 이상해졌다. 로그를 보니 Tailwind v3와 v4의 PostCSS 처리 방식이 서로 간섭하고 있었다. Currency 앱에 별도의 PostCSS 설정을 만들어서 간단히 해결할 수 있을 줄 알았다.

// apps/currency/postcss.config.js
export default {
  plugins: [] // Tailwind v4는 Vite에서 처리하니까 비워두자
}

하지만 여전히 문제가 있었다. 터보가 빌드할 때 각 앱의 node_modules가 서로 영향을 주고 있는 것 같았다. LLM에 물어보니 "phantom dependencies" 문제일 가능성이 있다고 했다.

두 번째 문제: 패키지 격리 부족

문제를 더 파보니 npm의 hoisting 때문이었다. 각 앱이 독립적으로 관리되어야 하는데, 의존성들이 섞이면서 PostCSS 플러그인들이 예상치 못한 방식으로 로드되고 있었다. 결국 패키지 격리가 더 엄격한 pnpm으로 갈아타기로 결정했다. 일단 설정부터 만들어봤다.

# pnpm-workspace.yaml
packages:
  - 'apps/*'

# .pnpmrc
strict-peer-dependencies=false
auto-install-peers=true
shamefully-hoist=false  # 이게 핵심이었다
store-dir=.pnpm-store

shamefully-hoist=false가 중요했다. 이 설정으로 각 앱의 의존성이 완전히 격리됐다.

세 번째 문제: Turborepo 설정의 미스터리

pnpm으로 바꾸고 나니 새로운 의문이 생겼다. 공식 문서에 나온 best pracice대로 turbo.json 파일을 작성하다 보니 이상했다.

{
  "tasks": {
    "build": {
      "inputs": [
        "src/**",
        "public/**", 
        "*.json",
        "postcss.config.*",
        "vite.config.*"
      ]
    }
  }
}

분명히 내 프로젝트에는 apps/currency, apps/chat, apps/mbti 같은 폴더들이 있는데, 왜 구체적인 경로가 없을까? 처음에는 이렇게 써야 하는 줄 알았다:

"inputs": ["apps/currency/**", "apps/chat/**", "apps/mbti/**"]

터보가 어떻게 내 앱들을 찾는지 궁금해서 여러 실험을 해봤다.

실험 1: 터보가 뭘 보고 있나?

npx turbo ls

이 명령어로 터보가 인식하는 패키지들을 확인해봤다. 신기하게도 apps 폴더 안의 것들만 나타났다. 그럼 터보가 어떻게 이걸 알지?

LLM에 물어보니 "워크스페이스 설정을 자동으로 감지한다"고 했다. 그래서 더 실험해봤다.

실험 2: 워크스페이스 패턴 테스트

packages 폴더를 만들고 그 안에 테스트 패키지를 추가해봤다. npx turbo ls를 다시 실행해도 새 패키지는 목록에 없었다.

그런데 pnpm-workspace.yaml에 packages/*를 추가하고 다시 실행하니 새 패키지가 나타났다! 이제 이해됐다. 터보는 워크스페이스 설정을 읽고 그에 따라 패키지들을 찾는다.

즉, turbo.json의 postcss.config.* 패턴은 각 앱 디렉토리를 기준으로 상대적으로 적용된다는 뜻이었다. apps/currency/postcss.config.js, apps/chat/postcss.config.js 이런 식으로.

문제 해결의 전체적인 그림

모든 퍼즐이 맞춰지니 Currency 앱의 Tailwind v4 적용이 완벽하게 작동했다.

pnpm의 엄격한 격리: shamefully-hoist=false로 각 앱의 PostCSS 관련 패키지들이 완전히 분리됨
독립적인 PostCSS 설정: Currency 앱은 빈 PostCSS 설정, 다른 앱들은 기존 v3 설정 유지
터보의 개별 빌드: 각 앱이 자신의 설정에 따라 독립적으로 빌드됨

최종 빌드 플로우는 이렇게 됐다:

{
  "scripts": {
    "build-apps": "turbo run build",
    "build": "pnpm run build-apps && next build",
    "clean": "rm -rf public/static && rm -rf apps/*/node_modules && rm -rf apps/*/.next",
    "dev": "pnpm run build-apps && next dev --turbopack"
  }
}

먼저 터보가 각 앱을 개별적으로 빌드하고, 그 결과물을 메인 Next.js 프로젝트가 사용하는 하이브리드 구조가 됐다.

예상치 못한 부가 효과들

Currency 앱의 Tailwind v4 적용을 위해 시작한 작업이었는데, 결과적으로 전체 monorepo가 훨씬 견고해졌다.

빌드 캐시 개선: 각 앱의 설정 파일 변경이 해당 앱에만 영향을 주게 됐다. Currency 앱의 Vite 설정을 바꿔도 다른 앱들은 캐시를 그대로 사용한다.

의존성 충돌 해결: phantom dependencies 문제가 완전히 사라졌다. 각 앱이 정말로 독립적인 환경에서 실행된다.

개발 경험 향상: 새로운 앱을 추가할 때 별도 설정이 필요 없어졌다. apps 폴더에 디렉토리 만들고 package.json 추가하면 터보가 자동으로 인식한다.

삽질하면서 배운 것들

이번 경험에서 가장 큰 교훈은 "자동화된 도구의 동작 원리를 이해하는 것"의 중요성이었다.

터보가 "워크스페이스를 자동으로 감지한다"는 문서만 봤을 때는 그냥 '오 편하네' 라고만 생각했다. 하지만 실제로 pnpm-workspace.yaml 파일을 읽고, 글로브 패턴을 확장하고, 각 디렉토리에서 package.json을 찾는 구체적인 과정이 있었다.

이런 과정을 이해하고 나니 Currency 앱의 특별한 PostCSS 설정이 어떻게 다른 앱들과 격리되는지도 명확해졌다. 각 앱의 빌드 환경이 진짜로 독립적이라는 확신이 생겼다.

마치며

Tailwind v4 하나 적용하려다가 monorepo 전체를 뜯어고치게 됐지만, 결과적으로는 훨씬 좋은 구조를 얻었다. Currency 앱은 v4의 새로운 기능들을 자유롭게 사용할 수 있게 됐고, 다른 앱들도 안정적으로 v3를 계속 쓸 수 있다.

무엇보다 이제는 새로운 기술을 실험할 때 다른 앱들에게 영향을 줄 걱정이 없어졌다. 각 앱이 완전히 독립적인 환경을 가지고 있으니까.

처음에는 단순한 CSS 충돌 문제였는데, 해결 과정에서 패키지 관리와 빌드 시스템까지 제대로 이해하게 됐다. 이런 식으로 하나의 문제를 깊이 파다 보면 관련된 시스템 전체를 배우게 되는 것 같다. 시간은 좀 걸렸지만 값진 경험이었다.

https://junha.kr/currency

currency

junha.kr

모듈 시스템을 알아보자. 모듈은 동기적 호출일까? Require vs Import

Psychogrammer — Sat, 26 Oct 2024 17:34:35 +0900

모듈?

관련된 코드들을 하나의 코드 단위로 캡슐화한 하나의 파일을 말한다.

CommonJS (CJS)

Require 키워드를 사용한 모듈 시스템을 말한다.

Node.js와 구버전의 브라우저에서 주로 사용한다.

module.exports와 exports 두 가지 방법으로 모듈을 내보낼 수 있다

예시1. module.exports

// arithmetic.js

class Arithmetic {
    constructor(a, b) {
        this.a = a;
        this.b = b;
    }
    add() {return this.a + this.b;}
    subtract() {return this.a - this.b;}
};
 
module.exports = Arithmetic;

// main.js

const Arithmetic = require('./calculator.js');

const op = new Arithmetic(100,40)
op.add();

module.exports에 값을 담아서 내보내는 방식
값은 클래스, 변수, 함수 등 하나의 레퍼런스(메모리 주소)등이 들어갈 수 있다.
require 키워드는 module.exports에 할당한 값을 반환한다.

예시2. module.exports

// module.js

module.exports = {
	name: 'junha',
	age: 27
}

// main.js

const obj = require('./module.js')

obj.name // 'junha'
obj.age // 27

예시3. exports

// arithmetic.js

exports.add = (a, b) => a + b;
exports.subtract = (a, b) => a - b;

// main.js

const Arithmetic = require('./calculator.js');
 
Arithmetic.add(100,40)
Arithmetic.subtract(100,40)

exports 객체는 module.exports 객체를 참조하는 변수다.
exports 객체에 할당된 프로퍼티들은 모두 module.exports 객체에서 접근이 가능하다.

ECMAScript Modules (ESM)

es6에서 공식적으로 채택된 모듈 시스템이다.

Default exports, Named exports 두 가지 방법으로 모듈을 내보낼 수 있다.

예시1. Default exports

// arithmetic.js

class Arithmetic {
    constructor(a, b) {
        this.a = a;
        this.b = b;
    }
    add() {return this.a + this.b;}
    subtract() {return this.a - this.b;}
};
 
export default Arithmetic;

// main.js

import Arithmetic from './arithmetic.js'

const op = new Arithmetic(100,40)
op.add()
op.subtract()

한 파일에서 한 번만 사용할 수 있고, 대표로 값을 내보낼 때 사용한다.

// utils.js

const add = (a, b) => a + b;
const subtract = (a, b) => a - b;
const array = [1, 2, 3];
const object = { a: 1, b: 2, c: 3 };

const obj = {
	add,
    subtract,
    array,
    object
};

export default obj;

import { add, subtract, array, object }  from "./utils.js";

import시 아무 이름이나 사용 할 수 있으며, destructring도 가능하다.

예시2. Named exports

2개 이상 변수들을 객체에 담아 export할 때 사용한다.

export const getUpload = (req, res) => res.render("upload", obj);
export const postUpload = async (req, res) => {};

import { getUpload, postUpload } from "../controllers/videoController.js";

❌ import upload from "../controllers/videoController.js";
// SyntaxError: The requested module does not provide an export named 'default'

✅ import * as upload from "../controllers/videoController.js";
// as를 통해 객체로 가져올 수 있다

default exports 방식과 named exports 방식을 함께 사용할 수 있다.

// utils.js

const add = (a, b) => a + b;
const subtract = (a, b) => a - b;
const array = [1, 2, 3];

export { subtract, array };
export default add;

// app.js 파일

import add, { subtract, array } from './utils.js';

변수로 바인딩 없이, 단순히 모듈만 실행할 목적이면 import만 사용하는 것이 좋다.

import "my-module.js";

주의

❌ export default const a = 1;

var, const, let 할당하면서 사용할 수 없다.
블록 {…} 안에선 동작하지 않는다.
import, export 는 파일내 최상위에 배치해야한다.
file 프로토콜로 열람할 경우
- 모듈은 로컬 파일에서 동작하지 않고, HTTP 또는 HTTPS 프로토콜을 통해서만 동작한다.
- 로컬에서 file:// 프로토콜을 사용해 웹페이지를 열면 import, export 지시자가 동작하지 않는다.
- 브라우저에서 origin이 존재하지 않는 것으로 취급하기 때문이다.
- 로컬 웹 서버인 ‘라이브 서버’를 사용할 것!!

ESM 사용하기

브라우저에서 사용하려면, 모듈에 해당되는 script 태그에 type="module"을 추가한다.

Node.js에서 사용하려면, package.json에 type="module"을 추가한다.

Uncaught SyntaxError: Cannot use import statement outside a module”

commonjs 방식에서 import를 사용하려 했기 때문에 발생한 오류다.
package.json의 “type” 필드 값을 “module”로 설정해줘야함.
단, 이전에 requre로 불러오던 모듈이 있었다면 import로 불러오도록 다시 선언해 줘야한다.

브라우저에서 ESM 특징

지연(defer) 실행: 다운로드와 파싱은 하지만, 실행은 페이지의 파싱이 완료된 후에 수행한다.
외부 오리진(도메인이나 프로토콜, 포트가 다른 오리진)에서 스크립트를 불러오려면 CORS 헤더가 있어야 한다.
중복된 외부 스크립트는 무시된다.
독립적인 스코프를 갖는다.
항상 엄격 모드로 실행(use strict)된다.
모듈 내 코드는 단 한 번만 실행된다. 모듈을 내보내면 이 모듈을 가져오기 하는 모듈 모두가 내보내진 모듈을 공유한다.
모듈 내에서 정의된 변수, 함수, 클래스 등은 모듈 외부에서 직접 접근할 수 없으며, 각각의 모듈에서 해당 모듈을 import 하여 가져와야 합니다. 모듈은 한 번만 실행되며, 이후에 다른 모듈에서 해당 모듈을 가져올 때는 다시 다운로드하지 않는다.
인라인 모듈 스크립트도 비동기 처리 할 수 있다.

(async () => { const { someFunction } = await import('./someModule.js');})();

잠깐, Import는 동기적 호출일까?

JavaScript 엔진은 구문의 형태를 보고 정적/동적 import를 자동으로 구분하여 처리한다.

1. 처리 순서

구문 분석: 모든 import/export 찾기
모듈 로딩: import된 모듈 불러오기
모듈 평가: 실제 코드 실행

2. 정적 Import (Static Import)

이때 Import는 모듈 초기화 단계에서 처리된다.
- 정적(Static) 구문
  1. 코드가 실행되기 전에 처리되는 문법 구조
  2. 컴파일/파싱 단계에서 처리됨
  3. 위치나 형태가 고정되어야 함
코드가 실행되기 전에 평가 및 로드되기 때문에 동기적 호출로 생각할 수 있다.
반드시 최상위 레벨에서 사용해야 함

import module from './module'
import { something } from './module'
import * as all from './module'

3. 동적 Import (Dynamic Import)

이때 Import는 Promise로 감싸진 해당 모듈을 반환하는 비동기 런타임 함수다.
코드 어디서든 사용 가능

async function someFunction() {
    const module = await import('./module');
}

import('./db.js')
  .then((module) => {
    const db = module.default;
    // 모듈 내 default export로 정의된 컴포넌트를 사용할 수 있음
    // module.default는 db.js 파일에서 export default로 내보낸 객체를 가리킴
  })
  .catch((error) => {
    console.error('Error loading the module:', error);
  });

4. CommonJS

require() 함수는 모듈을 동기적으로 불러오며, 처음 실행된 후 module.exports를 반환. 이후 동일한 모듈에 대한 호출은 캐시된 값을 반환한다.

CJS vs ESM

1. CJS는 기본 값이다. 왜냐면 ESM은 바뀔게 넘 많아서

기본 값으로 use strict가 설정되어 있어야하고, this는 global object를 참조하지 않고, 스코프는 다르게 작동 되는 등등 변화가 많다. 브라우저에서 조차 <script>가 ESM을 기본으로 지정하지 않는 이유다. ESM을 사용하기 위해서는 type="module"을 추가해 주어야 한다. 기본 값을 CJS에서 ESM으로 바꾸는 것은 호환성을 해치는 문제가 된다. (node의 대안으로 주목받고 있는 deno는 ESM을 기본값으로 사용하지만, 결과적으로 모든 생태계를 처음부터 다시 설계해야 했다.)

2. ESM과 CJS는 완전히 다르다.

CommonJS에서는 require()는 동기로 이루어진다. 따라서 promise나 콜백 호출을 리턴하지 않는다. require()는 디스크로 부터 읽어서 (네트워크 일수도 있다) 그 즉시 스크립트를 실행한다. 따라서 스스로 I/O나 부수효과 (side effect)를 실행하고 module.exports에 설정되어 있는 값을 리턴한다.

반면에 ESM은 모듈 로더를 비동기 환경에서 실행한다. 먼저 가져온 스크립트를 바로 실행하지 않고, import와 export구문을 찾아서 스크립트를 파싱한다. 파싱 단계에서, 실제로 ESM 로더는 종속성이 있는 코드를 실행하지 않고도도, named imports에 있는 오타를 감지하여 에러를 발생시킬 수 있다.

그 다음 ESM 모듈 로더는 가져온 스크립트를 비동기로 다운로드 하여 파싱한다음, import된 스크립트를 가져오고, 더 이상 import 할 것이 없어질 때까지 import를 찾은 다음 dependencies의 모듈 그래프를 만들어 낸다. 그리고, 스크립트는 실행될 준비를 마치게 되며, 그 스크립트에 의존하고 있는 스크립트들도 실행할 준비를 마치게 되고, 마침내 실행된다. ESM 모듈 내의 모든 자식 스크립트들은 병렬로 다운로드 되지만, 실행은 순차적으로 진행된다.

3. export default를 피해야 하는 두 가지 이유

export default 문법은 원래 기존의 CommonJS 모듈 시스템과 호환성을 유지하기 위해 만들어졌다. 그러나 named exports와는 다르게, import하는 곳에서 이름을 자유자재로 정할 수 있다. 때문에 1. 같은 모듈이더라도 사용처에 따라 이름이 달라져, 1. 큰 규모의 리팩토링을 어렵게 만든다. 반면 named exports는 export 되는 값들에 이름을 부여하기 때문에 모든 사용처에서 동일한 이름을 사용해 IDE가 이를 찾아서 자동으로 import를 도와줄 수 있어 이러한 문제가 발생하지 않는다.

2. tree-shaking을 통해 번들 사이즈를 줄일 수 없다. 예를 들어, 하나의 거대한 객체를 default로 한번에 export하는 경우에는 tree-shaking을 할 수 없다. 하지만 named exports로 값을 하나씩 export 해주면 사용하지 않는 값들은 tree-shaking을 통해 번들 사이즈를 줄일 수 있다. ES Modules로 작성된 모듈의 경우에는 tree-shaking을 할 수 있지만, CommonJS 모듈로 작성된 모듈의 경우에는 tree-shaking을 할 수 없다.

// 1. Tree-shaking 잘 되는 경우들
// math.js
export default function add(a, b) { return a + b }  // default export도 OK
export const subtract = (a, b) => a - b            // named export도 OK

// 2. Tree-shaking 안 되는 경우
// utils.js
export default {
 add: (a, b) => a + b,
 subtract: (a, b) => a - b,
 multiply: (a, b) => a * b,
 // 하나만 써도 모든 함수가 번들에 포함됨!
}

// main.js
import { add } from './utils'  // multiply, subtract도 함께 번들링됨
// 그저 destructring 한 것일 뿐이다

default export 자체가 문제라기 보다는, 객체로 묶어서 export하면 tree-shaking이 안된다는 점을 명심하자.

자바스크립트 런타임과 엔진의 차이점: 이벤트 루프는 어디에?

Psychogrammer — Thu, 24 Oct 2024 20:41:03 +0900

자바스크립트 엔진? 런타임? 이 두 용어의 차이에 대해 햇갈리시는 분이 계실겁니다. 이 글에서는 자바스크립트의 엔진과 런타임을 비교해보고 이벤트 루프의 역할, 추상적 구조를 살펴보겠습니다.

1. 엔진

역할
- ECMAScript(ECMA-262 표준)코드를 파싱하고 실행한다.
- 메모리 관리, 가비지 컬렉션을 수행한다.
구성요소
- 파서: 소스 코드를 AST(Abstract Syntax Tree)로 변환.
- 컴파일러: AST를 최적화된 바이트코드 또는 네이티브 코드로 컴파일.
- 가상 머신 (VM): 컴파일된 코드를 실행. JIT(Just-In-Time) 컴파일링을 통해 성능 최적화.
주요 엔진
- V8: Google Chrome, Node.js에 사용
- SpiderMonkey: Mozilla Firefox에 사용
- JavaScriptCore: Safari 및 iOS에서 사용
V8 엔진
- V8은 구글이 개발한 자바스크립트 엔진으로, 자바스크립트 코드를 컴파일하고 실행하는 역할을 합니다.
- V8은 단일 스레드에서 동작하며, 자바스크립트 코드를 해석하고 실행합니다.
- 메모리 관리와 가비지 컬렉션도 V8의 책임입니다.
- V8은 단순히 자바스크립트 코드의 실행을 처리하는 엔진일 뿐, 비동기 작업이나 이벤트 루프를 관리하지는 않습니다.

2. 런타임

역할
- 엔진을 포함한 ECMAScript 실행 환경을 제공한다.
- 플랫폼에 따라 추가적인 비표준 API(DOM, fs)를 제공한다.
구성요소
- 엔진: ECMAScript 실행 담당
- 이벤트 루프: 비동기 작업을 관리, 콜백 함수 실행 순서 제어
- 호스트 API: 브라우저의 DOM API, 서버의 파일 시스템 API 등 추가 기능 제공
주요 런타임
- 브라우저: DOM, BOM, fetch API 등 웹 관련 API 제공
- Node.js: 파일 시스템, 네트워크 I/O, 프로세스 관리 등 서버 관련 API 제공
- Deno/Bun: Node.js와 유사하지만 파일 시스템, 보안 모델 등에서 차별화된 API 제공

3. 이벤트 루프는 어디에 포함되어 있는가?

Node.js 환경
- Node.js는 libuv라는 라이브러리를 사용하여 이벤트 루프를 관리합니다. Node.js의 이벤트 루프는 파일 I/O, 네트워크, 타이머, 비동기 작업을 관리하며, 작업이 완료되면 V8에서 해당 작업의 콜백을 실행하게 됩니다.
브라우저 환경
- HTML 명세의 이벤트 루프 스펙을 따르지만, 구체적인 구현은 각자 다릅니다.
- 이벤트 루프 관리를 위한 별도의 공개된 라이브러리를 사용하지 않습니다.
- 내부 구현이 브라우저 코드에 긴밀하게 통합되어 있어, Node.js처럼 명확하게 분리된 모듈로 존재하지 않습니다.
- 각 브라우저가 자체적으로 구현하고 있고, 그 구현이 브라우저 코드에 깊이 통합되어 있습니다.

즉, 이벤트 루프는 자바스크립트 런타임(브라우저, Node.js 등)이 제공하는 기능이고, 자바스크립트 엔진(V8)은 이벤트 루프에서 푸쉬한 콜백을 실행하는 역할을 합니다.

4. 이벤트루프의 구조

flowchart TB
    subgraph ELS["Event Loop System (ELS)"]

        subgraph TQ["Task Queue (TQ)"]
            setTimeout["setTimeout"]
            setInterval["setInterval"]
            IO["I/O Operations (File, Network)"]
            XHR["XHR Requests (Ajax, Fetch)"]
            UIEvents["UI Events (Click, Keypress)"]
        end

        subgraph JQ["Job Queue (JQ)"]
            subgraph MQJ["Microtask Queue (MQJ)"]
                PromiseThen["Promise.then()"]
                AsyncAwait["async/await"]
                MutationObserver["MutationObserver"]
                QueueMicrotask["queueMicrotask()"]
            end
        end

        subgraph RQ["Render Queue (RQ)"]
            Layout["Layout Calculation"]
            Paint["Paint (Rasterization)"]
            Composite["Compositing"]
            StyleRecalc["Style Recalculation"]
            CSSAnimation["CSS Animation"]
            Transition["CSS Transition"]
        end
    end

전체 이벤트 루프 시스템을 표현하는 집합
- Event Loop System, ELS = { Task Queue, Microtask Queue, Render Queue }
Task Queue: 넓은 의미에서 비동기 작업의 완료 후 실행될 일반적인 태스크들, 콜백들이 대기하는 큐
- TQ = { setTimeout, setInterval, I/O, XHR Requests 등 }
- 특정 이벤트(네트워크 응답, 사용자 인터페이스 이벤트 등)를 처리하는 비동기 작업을 기다리는 대기열
- TQ ⊆ Message Queue
Microtask Queue: 즉시 처리되어야 하는 짧은 작업들이 들어가는 큐
- MQ = { Promise.then(), async/await, MutationObserver 등 }
- MQ ⊆ Job Queue (JQ)
Render Queue: 브라우저 렌더링 작업이 들어가는 큐
- RQ = { 렌더링, 스타일 변경 }

한마디로 정리하면 아래와 같습니다.

Event Loop System (ELS) = { TQ, JQ = { MQ }, RQ }
Microtask Queue는 Job Queue의 부분집합
이 모든 큐들은 이벤트 루프 시스템 내에서 서로 역할을 분담합니다.

Node.js 비동기 처리 모델 이해하기 - 실시간 대규모 처리에 적합한 이유

Psychogrammer — Wed, 2 Oct 2024 15:16:51 +0900

Node.js는 싱글 스레드에서 동작하지만, 놀랍게도 동시성과 효율적이고 빠른 응답 시간을 유지할 수 있는 비동기 처리 모델을 제공합니다. 오케스트라의 지휘자처럼 Node.js는 메인 스레드에서 비동기 작업을 관리하고, 백그라운드에서 실행되는 I/O 작업(네트워크 요청, 파일 시스템 작업)들이 완료되면 그 결과를 처리하는 방식으로 작동하죠.

이 글에서는 Node.js의 비동기 처리 모델과 이를 가능하게 하는 libuv 라이브러리의 역할을 설명하고, 대규모 데이터를 처리할 때 스레드 풀과 외부 API 호출이 어떻게 동작하고 성능을 최적화하는지 알아보겠습니다.

1. Node.js의 이벤트 루프와 비동기 논블로킹 I/O 모델

Node.js는 단일 스레드 기반의 자바스크립트 런타임이지만, 모든 작업을 직접 처리하지 않습니다. 비동기 작업 처리를 위해 내부적으로 다중 스레드를 활용합니다. 특히, 네트워크 요청, 파일 시스템 접근, 데이터베이스 호출과 같은 I/O 작업들은 libuv 라이브러리를 통해 백그라운드의 스레드 풀에 위임됩니다. 메인 스레드에서는 이 작업들이 완료되기 전까지 다른 작업을 계속 수행하고, 완료된 결과만 처리하는 방식입니다.

이벤트 루프는 Node.js의 핵심적인 비동기 처리 메커니즘으로, 메인 스레드에서 비동기 작업을 지휘하며 각 작업이 완료되었을 때 적절한 콜백을 실행합니다. 이 논블로킹 I/O 모델 덕분에 Node.js는 실시간 채팅 애플리케이션처럼 수천, 수만 개의 요청을 동시에 처리해야 하는 환경에서 높은 성능을 발휘합니다. 예를 들어, 각 사용자로부터 들어오는 요청을 즉시 처리하면서도 백그라운드에서 데이터베이스 작업을 수행할 수 있어, 많은 사용자들이 동시에 접속해도 원활하게 운영될 수 있습니다.

만약 Node.js가 아닌, 동기적인 시스템 또는 서버였다면, 각 I/O 작업이 완료될 때까지 모든 다른 요청은 차단되어 기다려야 합니다. 하나의 네트워크 요청이 완료될 때까지 다른 요청들이 대기 상태에 머물게 되어, 동시성 처리가 불가능하고, 많은 사용자가 접속하는 상황에서 성능 저하와 병목 현상이 발생하게 되었겠죠.

2. 비동기 모델의 성능과 백그라운드 리소스

비동기 처리 모델에서 중요한 점은, 작업을 메인 스레드에서 비동기로 던진다고 해서 자동으로 무한한 동시성을 보장할 수는 없다는 것입니다. Node.js의 비동기 처리 방식은 libuv의 스레드 풀과 같은 백그라운드 리소스에 의존합니다. 이 스레드 풀은 동시에 여러 I/O 작업을 처리할 수 있지만, 그 크기와 성능은 제한적입니다. 따라서, 대규모 데이터를 처리할 때도 백그라운드에서 실제로 병렬로 작업을 수행할 충분한 컴퓨팅 파워가 있어야 비동기 모델의 이점이 제대로 발휘됩니다. 즉, 비동기 모델이 동시성을 보장하려면 내부 리소스가 이를 뒷받침해야겠죠.

그러나, 대규모 작업을 처리할 때 모든 리소스를 내부적으로 처리하는 대신, API 호출을 통해 외부 리소스에 컴퓨팅 부담을 분산시키는 방법을 많이 사용하죠. Node.js는 비동기 API 호출을 통해 제3자 서버(예: 클라우드 서비스, 외부 API)에 작업을 위임하고, 실제 리소스 소비는 외부에서 이루어집니다. 이렇게 하면, Node.js 서버는 네트워크 대역폭과 API 응답 대기 시간만 관리하면 되고, 직접적인 컴퓨팅 파워는 외부에서 제공받는 구조가 됩니다.

Node.js의 비동기 모델 덕분에 이러한 API 호출은 논블로킹으로 처리되며, 여러 작업을 동시에 던져놓고 그 결과를 비동기적으로 받아들일 수 있습니다. 따라서 이 방식은 내부 컴퓨팅 리소스가 제한된 환경에서 동시성과 성능을 유지하는 훌륭한 전략이 될 수 있습니다.

3. libuv의 역할과 이벤트 기반 아키텍처

Node.js의 비동기 성능은 libuv 라이브러리 덕분에 가능해졌습니다. libuv는 이벤트 루프와 비동기 I/O 작업을 관리하여, Node.js가 단일 스레드로 동작하면서도 높은 성능을 발휘할 수 있게 합니다. Node.js는 전통적인 멀티스레드 방식 대신, 단일 스레드 기반에서 파일 시스템 작업, 네트워크 요청, 타이머 등 다양한 I/O 작업을 비동기적으로 처리합니다. 이를 통해 개발자는 직접적인 쓰레드 관리의 복잡성을 피하고, 간편하게 비동기 함수, 콜백, Promise, async/await 패턴을 활용할 수 있습니다.

libuv는 논블로킹 방식으로 작업을 처리하며, 일부 블로킹 작업의 경우 내부 쓰레드 풀을 사용하여 처리합니다. 이러한 구조는 성능 저하를 최소화하고, I/O 작업이 많은 애플리케이션에서 높은 효율성을 발휘합니다. 특히, 내부적으로 쓰레드 풀을 통해 블로킹 작업을 관리하기 때문에, 개발자는 멀티스레드 관리의 부담 없이 비동기 작업을 직관적으로 다룰 수 있으며, 성능과 생산성을 동시에 확보할 수 있습니다.

Node.js 아키텍처

4. libuv의 스레드 풀

기본적으로 Libuv의 스레드 풀은 4개의 스레드로 구성되어 있습니다. 이는 대부분의 시스템에서 I/O 작업이 그다지 많은 스레드를 요구하지 않기 때문입니다. 그러나 CPU 집약적인 작업을 자주 수행하거나, I/O 작업이 많을 경우에는 스레드 풀의 크기를 조정할 수 있습니다.

시스템 성능에 따라 더 많은 병렬 작업을 처리할 수 있도록 UV_THREADPOOL_SIZE를 사용하여 스레드 풀의 크기를 조정할 수 있습니다.

UV_THREADPOOL_SIZE=8 node app.js

5. 비동기 I/O 작업과 스레드 풀의 관계

Node.js는 비동기 I/O 작업을 처리할 때 libuv의 스레드 풀을 활용합니다. 다만, 모든 비동기 작업이 스레드 풀에서 처리되는 것은 아닙니다. 예를 들어, 네트워크 요청과 같은 작업은 커널의 비동기 I/O 기능을 사용하여 처리되므로 스레드 풀을 사용하지 않습니다.

반면에, 파일 시스템 작업처럼 블로킹 I/O 작업은 libuv의 스레드 풀을 통해 백그라운드에서 처리됩니다. 이 과정에서 메인 스레드는 블로킹 없이 다른 작업을 계속 처리할 수 있어 동시성을 높이고 자원 활용을 최적화할 수 있습니다. 이는 CPU 자원을 많이 사용하지 않는 I/O 작업에서는 매우 효과적입니다.

그러나 CPU 집약적인 작업(예: 복잡한 계산, 대규모 데이터 처리)이 발생할 경우, Node.js의 단일 스레드 모델에서는 병목 현상이 발생할 수 있습니다. 이때는 Worker Threads를 사용하여 CPU 작업을 멀티 스레드 환경에서 병렬로 처리할 수 있습니다. 이를 통해 CPU 사용이 많은 작업도 효율적으로 처리하면서, Node.js의 성능을 극대화할 수 있습니다. 하지만 애초에 CPU 바운드 작업을 많이 처리해야 하는 서버라면, 다른 언어(예: C++, Go, Rust)로 작성하는 것이 더 적합할 수 있습니다.

6. 스레드 풀을 늘렸을 때 이점이 있는 작업의 구분

1. 제3자 API 호출 작업 (예: 클라우드 API 호출)

스레드 풀 영향 없음: 이러한 작업들은 주로 네트워크 I/O를 사용하며, 커널의 비동기 I/O 기능을 통해 처리되기 때문에 libuv의 스레드 풀과 무관합니다. 네트워크 요청은 논블로킹으로 처리되며, 많은 요청을 처리하는 상황에서도 스레드 풀을 늘린다고 해서 큰 이점을 얻을 수는 없습니다.

이러한 경우에는 컨테이너 기반 스케일 아웃이 성능 향상에 더 효과적입니다. 여러 인스턴스로 네트워크 요청을 분산 처리하여 부하를 줄이고, 대규모 트래픽에서도 안정적인 성능을 유지할 수 있습니다.

2. CPU 집약적인 작업 (예: 대규모 데이터 처리, 복잡한 계산)

스레드 풀 영향 없음: 이와 같은 CPU 집약적인 작업은 libuv의 스레드 풀에서 처리되지 않으며, 이러한 작업은 Worker Threads를 통해 멀티스레드 방식으로 처리해야 성능을 극대화할 수 있습니다. 스레드 풀을 늘려도 CPU 작업에 대한 성능 향상은 없습니다.

3. 내부 I/O 작업 (예: 파일 시스템, DNS 조회 등)

스레드 풀 영향 있음: 파일 시스템 접근이나 블로킹 I/O 작업은 libuv의 스레드 풀을 사용하여 처리됩니다. 스레드 풀을 늘리면 이러한 작업들을 더 많이 병렬로 처리할 수 있어, 파일 입출력이나 DNS 조회 작업을 많이 처리해야 할 때 성능 향상을 기대할 수 있습니다.

따라서, 스레드 풀을 늘리는 것은 블로킹 I/O 작업을 더 빠르게 병렬 처리할 때 유용하며, 네트워크 I/O와 같은 작업이나 CPU 바운드 작업에서는 스레드 풀을 늘려도 성능상의 큰 이점을 얻을 수 없습니다.

결론

Node.js는 단일 스레드 모델임에도 비동기 처리 모델을 통해 놀라운 동시성과 성능을 제공합니다. 이는 libuv의 이벤트 루프와 스레드 풀 덕분이며, 파일 시스템과 같은 블로킹 I/O 작업에서 큰 효과를 발휘합니다. 그러나 모든 작업이 스레드 풀에 의존하지 않으며, 네트워크 I/O나 CPU 집약적인 작업은 다른 방식으로 처리됩니다. 따라서 대규모 데이터를 다룰 때는 스레드 풀의 크기 조정뿐만 아니라 Worker Threads나 스케일 아웃 전략을 적절히 사용하는 것이 중요하겠습니다.

Software Design Decoded: 66 Ways Experts Think 후기

Psychogrammer — Sun, 8 Sep 2024 15:52:35 +0900

짤막한 느낀 점

도대체 전문가들은 어떤 식으로 사고하는지 궁금했다. 이 책을 읽으면서 66가지 주제로 사고방식을 엿볼 수 있었다. 카테고리별로 잘 나뉘어 있었고 문단이 길지 않아 읽기도 수월했다. 특히 좋았던 점은 내가 어떤 부분에서 잘하고 있는지와 부족한지가 뚜렷하게 구분되니깐 어디서 헤매고 있는지 진단하기 좋았다. 부족한 부분은 사실, 강점에서부터 비롯된 '트레이드오프' 현상인데 이를 고칠 수가 있나?라는 의문이 들기도 했다. 약점을 보완해 나가며 균형 잡힌 전문가가 될 것인지, 아니면 강점을 더욱 발전시켜 개성 넘치는 전문가가 될 것인지 고민하기도 했다. 그렇게 내린 결론은 "전문가"라는 직업 자체가 균형 잡힌 역량을 갖추는 것이 중요하다고 생각하기 때문에, 전자를 선택하고자 한다. 후자는 개인적인 활동에서 충분히 즐기도록 하자.

저자 소개

Marian Petre는 "전문가들의 생각을 분석"하여 소프트웨어 설계 전문가들이 어떻게 전문성을 발휘하는지, 사람들이 설계와 문제 해결에 대해 어떻게 사고하고 소통하는지, 그리고 그들이 사고 과정에서 표현 방식을 어떻게 활용하는지를 탐구한다. 영국의 오픈 대학교에서 컴퓨팅 교수로 재직 중이며, 심리언어학과 컴퓨터 과학 학위를 보유하고 있다.

André van der Hoek는 본질적으로 프로그래머로서, 소프트웨어 설계자 및 개발자들과 대화하고 협력하여 그들이 더 효과적이고 효율적으로 일할 수 있도록 돕는 새로운 도구를 만드는 것을 좋아한다. 캘리포니아 대학교 어바인 캠퍼스의 정보학 교수이며, 비즈니스 중심 컴퓨터 과학과 컴퓨터 과학 학위를 보유하고 있다.

❤️: 인상 깊게 읽었거나, 부족함을 느껴 더 노력하고 싶은 주제

내용

Experts keep it SIMPLE (1~)

EXPERTS prefer simple solution ❤️ → 문제를 해결하는 데는 수많은 방법이 있다. 전문가는 그중 가장 단순한 걸 선택할 뿐이다.
EXPERTS solve simpler problems first → 먼저 간단한 문제를 해결하면서 복잡한 문제를 단순하게 만들어나간다.
EXPERTS divide and conquer → 쪼개서 이해함과 동시에 전체를 볼 줄 안다.
EXPERTS do not overgeneralize → 무작정 확장성을 고려해서 짜지 않는다.
EXPERTS design elegant abstractions → 추상화를 단지 만드는 게 아니라 설계해서 이를 통해서 고수준의 사고를 가능하게 한대.
EXPERTS use metaphor → 은유를 통해 바로 이미지로 이해시킨다.

Experts COLLABORATE (7~) ❤️❤️

EXPERTS prefer working with others → 전문가는 은둔 고수가 아니다. 이들은 소통을 통해 영감과 통찰을 얻어간다.
EXPERTS reach out ❤️ → 다른 사람의 도움을 빠르면 빠를수록 먼저 요청한다. 난 다른 사람의 리소스를 소모시키지 않겠다는 생각에 읽어도 큰 도움 안 되는 코드를 파악해 가며 도메인을 파악해 갔는데 이는 좋지 않은 전략이었다.
EXPERTS check with others continually ❤️ → 확실히 내가 소통 능력에 약하다는 걸 깨달았다. 전문가들은 짬 내서 소통하는 걸 잘하고 이를 익숙하게 받아들인다고 한다.
EXPERRS involve the user → 사용자가 말하는 것을 그대로 받아들이지 않고 그 너머를 본다는 것은 내가 하는 것과 일맥상통하네. 진짜 이게 중요했음.
EXPERTS socially embed and reinforce food practice → 집단내에서의 네트워킹이 마련되어 있는 것도 중요하구나
EXPRESTS agree to disagree → 의견불일치를 받아들이고 다른 부분을 먼저 집중하고 그 후 얻어지는 추가 정보로 다시 의논해 나간다는 것이 인상 깊네.

EXPERTS KEEP GOING (63~)

EXPERTS design all the time → 어쩌다 하는 게 아니라 그냥 습관적으로 몰두해서 하는 것임
EXPERTS know design is not done until the code is delivered and running → 코드의 품질은 사용성 평가에 따라 달린 것이기 때문이다
EXPERTS keep learning → 전문성을 당연하게 여기지 않고 계속해서 배우려고 한다.
EXPERTS play → 영감과 흥미를 불어 일으킬만한 것들을 계속해서 가지고 논다.

EXPERTS REFLECT (58~)

EXPERTS curtail digressions → 전문가들은 완벽한 기계가 아니다. 뭔가 잘못된 상황을 주기적으로 캐치하고 다시 되돌아가는 힘이 있는 사람들이다.
EXPERTS retain their orientation → 많은 회의, 수많은 의사결정들 속에서 방황하지 않고 나아가야 할 방향을 정해놓고 기억하고 있는다.
EXPERTS think about they are not designing → 이거 난데? 이 파트는 충분히 잘하고 있구나. 자부심을 갖자.
EXPERTS re-assess the landscape → 충분히 잘하고 있고, 너무 과하지 않게 다른 쪽 파트를 보충함으로써 균형을 맞추자
EXPERTS invest now to save effort later → 미래의 일을 예상하고 지금 예방한다

EXPERTS TEST (51~)

EXPERTS are skeptical → 그렇기 때문에 테스트를 꼭 한다
EXPERTS simulate continually → 시뮬레이션을 계속 돌려보는 건 나도 마찬가지!
EXPERTS draw examples alongside their diagrams → 아키첵처 설계는 수동적이라고 생각하고 이에 들어맞는 예시를 생각한다
EXPERTS test across representations → 각각의 뷰들은 제약이 있기 때문에 전부 내려다봄으로써 점검한다
EXPERTS prototype concepts → 추상적인 것과 상호작용하는 것의 한계를 알기 때문에 어떻게든 일단 눈에 보이는 구체적인 프로토타입을 만들고 이를 통해 피드백한다.
EXPERTS play the fool ❤️ → 아무래도 담당자이다 보면 매몰되기 마련이다. 아무것도 모른다고 가정한 상태에서 재평가하는 것도 도움이 될 듯!
EXPERTS are alert to evidence that challenges their theory ❤️ → 나는 정상이었다. 아무래도 내가 만든 설계다 보니 이게 맞는지 의심이 가는 건 당연한 거였고, 이를 반증하는 사례에 대해 귀를 기울이는 상태는 전문가들도 하는 좋은 자세였다.

EXPERTS ITERATE(44~)

EXPERTS repeat activities → 내가 그린 설계도, 다이어그램, 아키텍처. 그냥 순순히 따른다기보다, 백지에서 여러 번 그려보는 것도 최선의 방법이 나올 수도 있겠다. AI적 사고 시행 횟수를 좀 더 늘리는 것을 받아들여볼까
EXPERTS generate alternatives → 대안을 만들 시간까지 현업에서 주어질까.. 시스템이 거대하면 필수적일 것 같긴 하다.
EXPERTS explore different prespectives → 구현, 배포, 유용성, 그 외 인간적 관점까지 고려하는 게 전문가다
EXPERTS move among levels of abstraction → 높은 추상화 단계에서 설계하고 낮은 추상화 단계에서 기술적 부분을 챙긴다
EXPERTS rotate among subject pairs → 전문가는 단지 뚝딱 뚝딱이 아니라, 예술이네.. 문제쌍을 가지고 싸이클 돌면서 마주하면 진전이 더 빠르다는 걸 알고 있음.
EXPERTS change notation deliberately → 표현방식을 달리한다라… 시야를 다르게 보는 유용한 방법론이 될 수 있겠구먼
EXPERTS pause → 전문가는 맺고 끊을 줄 안다. 무지성으로 집착적으로 일이 안 풀린다고 늘어지지 않는다.

EXPERTS ARE NOT AFRAID(37~)

EXPERTS focus on the essence ❤️❤️ → 전문가들은 먼저 본질에 집중하고, 주변적인 부분의 디자인에 대해서는 노력을 늦춘다. 갓챠!!
EXPERTS address knowledge deficiencies → 가정을 할 수밖에 없지만 이건 지식의 부족이라고 알고 있고, 가정이 맞는지 최선을 다한다.
EXPERS go as deep as needed → 추상화와 구현의 일치를 통해 엄격함과 정확성을 유지한다.
EXPERTS try the opposite
EXPERST do something (else) → 교착상태에 빠질 때 그냥 잠시동안 초점을 달리하는 것도 최선의 방법이다.
EXPERTS know when to stop → 이득의 증가량이 감소할 때를 귀신같이 찾아내서 중단한대
EXPERTS build their own tools → 장인은 도구도 잘 다룬다~

EXPERTS WORK WITH UNVETAINTY(30~)

EXPERTS keep options open ❤️ → 결정을 확고히 하는 빨리 정하고자 하는 건 본능이다. 본능을 거스르고 옵션을 오픈하는 게 전문가다.
EXPERTS make provisional decision → 전문가들도 일단 잡고 달린다.
EXPERTS see error as opportunity → 오류, 장애를 통해 배우면 그만이다. 버그가 꼭 개인의 실책을 수반하지 않는다.
EXPERTS know how things work → 사고방식 못지않게 “지식” 역시 중요한 듯
EXPERTS make tradeoffs → 최선이란 존재하지 않고 여러 후보군들 중 종합평가 1위를 선택하면 그만이다
EXPERTS prioritize among stakeholders ❤️ → EXPERTS는 Engineer인 동시에 Employee이기 때문에 이거 역시 중요하다
EXPERTS adjust to the degree of uncertainity present → 불확실성에 따라 업무의 강도가 정해지는 듯

EXPERTS SKETCH(24~)

EXPERTS externalize their thoughts → 생각을 그림으로 자주 그린대. 생각을 말, 그림, 등등의 표현으로 자꾸 발산하는 게 검증과 발전의 기회라는 걸 앎.
EXPERTS draw the problem as much as they draw the solution → 문제상황을 해결방법만큼이나 중요하게 생각해서 그린다.
EXPERTS draw what they need and no more → 필요한 만큼만 그리지 막 세심하게 그리진 않는다. 노력을 낭비하지 않는다.
EXPERTS shift between formal and informal → 정석, 비정석적인 방법으로 다이어그램을 모두 잘 다룰 줄 알며 상황에 따라 다르게 선택한다.
EXPERTS invent notation → 새로운 프로젝트에 어울리는 독창적인 표기법을 알아서 만들고 쓸 줄 안다.
EXPERTS keep sketches → 이건 좀 납득이 안 가네. 보관을 잘해도 꺼내다 보지 않으면 말짱 도루묵인데. 암튼 언젠가 쓰일 걸 알고 보관한대.

Experts BORROW (13~)

EXPERTS prefer solutions that they know work ❤️ → 이미 검증된 해결책을 좋아한다.
EXPRETS look around → 어떤 기술을 적용할지 다른 기술 구경도 많이 한대
EXPERTS take inspiration from wherever they can → 관찰을 많이 하며 아이디어를 수집하고 다닌다
EXPERTS use analogy → 다루기 힘든 문제는 유추를 한대
EXPERTS use design methods SELECTIVELY ❤️ → 새로운 설계 방법을 발명하려고 하지 않는다. 이미 발명된 걸 쓰되 한계점을 인지하고 있는다.
EXPERTS network ❤️❤️ → 모든 걸 알 수 없다고 인정한다. 대신 네트워킹을 통해 전문 지식을 보충한다.

EXPERTS BREAK THE RULES

EXPERTS relax constraints → 필요에 따라, 상황에 따라, 단계에 따라 제약 조건을 내려놓기도 한다.
EXPERTS reshape the problem space → 갑자기 든 생각. 이것도 개발 경험, 트러블 슈팅 경험이 있어야 공감이 되고 읽히겠다고 느낌. 암튼 문제를 재구성한다는 추상적인 말이 너무 뻔하게 느껴지지만 그렇대.
EXPERTS use notations as lenses, rather than starightjacktes ❤️ → 이거 내가 잘 못하는 부분임. 도구를 자유자재로 활용해야지 도구에 빠져버리면 안 됨.
EXPERTS design throughout the creation of software → 설계는 단순히 구현물로 변환되어야 하는 ‘전’ 단계가 아니라 모든 걸 포함한다.
EXPERTS do not feel obliged to use things as intended → 도구를 의도대로만 쓰지 않고 필요에 의해 조합해서 쓴다.

Reference

https://www.amazon.com/Software-Design-Decoded-Experts-Think/dp/0262035189

React-19 useActionState 살펴보기

Psychogrammer — Sun, 26 May 2024 16:48:37 +0900

Action

: 비동기 전환을 사용하는 함수

(Before) Example1. passive process

function OrderCoffee({}) {
  const [coffee, setCoffee] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  const handleSubmit = async () => {
    setIsPending(true);
    const error = await orderCoffee(coffee);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    } 
    redirect("/order-success");
  };

  return (
    <div>
      <input value={coffee} onChange={(event) => setCoffee(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Order Coffee
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

데이터를 변경하고, 이에 대응하여 상태를 업데이트할 때, 예를 들어, 사용자가 이름을 변경하는 양식을 제출할 때 API 요청을 수행한 후 응답을 처리하는 경우 과거에는 보류 상태, 오류, 낙관적 업데이트, 순차적 요청 등을 수동으로 처리해야 했습니다.

(react-19) Example2. async transition

// Using pending state from Actions
function OrderCoffee({}) {
  const [coffee, setCoffee] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const error = await orderCoffee(coffee);
      if (error) {
        setError(error);
        return;
      } 
      redirect("/order-success");
    })
  };

  return (
    <div>
      <input value={coffee} onChange={(event) => setCoffee(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Order Coffee
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

async transition은 즉시 isPending 상태를 true로 설정하고, 비동기 요청을 수행한 후, 모든 전환이 끝나면 isPending을 false로 전환합니다. 이를 통해 데이터가 변경되는 동안 현재 UI를 responsive and interactive할 수 있게 만들어줍니다.

`useTransition`은 React의 동시성 모드를 활용하여 상태 업데이트를 비동기적으로 처리하는 기능으로, 내부적으로 React의 스케줄러와 Fiber 아키텍처를 사용하여 작업의 우선 순위를 관리하고, 메인 스레드가 차단되지 않도록 합니다. 이를 통해 사용자 인터페이스의 반응성을 유지하면서 복잡한 상태 업데이트를 효율적으로 처리할 수 있습니다.

(react-19) Example3. useActionState

// Using <form> Actions and useActionState
function OrderCoffee({ coffee, setCoffee }) {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const error = await orderCoffee(formData.get("coffee"));
      if (error) {
        return error;
      }
      redirect("/order-success");
      return null;
    },
    null,
  );

  return (
    <form action={submitAction}>
      <input type="text" name="coffee" />
      <button type="submit" disabled={isPending}>Order Coffee</button>
      {error && <p>{error}</p>}
    </form>
  );
}

액션(Actions)을 기반으로, 리액트 19는 일반적인 액션 케이스를 처리하기 위한 새로운 훅 React.useActionState를 도입했습니다. 액션은 데이터를 제출하는 작업을 자동으로 관리해 줍니다.

useActionState는 함수(“액션”)를 인수로 받아, 호출할 래핑된 액션을 반환합니다. 이는 액션들이 조합되기 때문에 작동합니다. 래핑된 액션이 호출되면, useActionState는 액션의 마지막 결과를 데이터로 반환하고, 액션의 보류 상태를 보류로 반환합니다.

(react-19) Example4. 실제 사용 예시

const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      if (!formData) {
        setCoffeeImage(null);
        return null;
      }
      const coffeeName = formData.get("coffee");
      const shot = formData.get("shot");
      const temperature = formData.get("temperature");
      const coffeeSrc = await orderCoffee(coffeeName, temperature, shot);

      if (!coffeeSrc) {
        return "Failed to fetch coffee image";
      }

      setCoffeeImage(coffeeSrc);
      return null;
    },
    null,
  );

참고

React.useActionState는 이전에는 canary release 에서 ReactDOM.useFormState라고 불렸으나, 이름이 변경되었고 useFormState는 폐기되었습니다.

브라우저 내의 자바스크립트 동작 원리

Psychogrammer — Sun, 5 May 2024 17:09:37 +0900

1. JavaScript Runtime 구성 요소

브라우저 내의 JavaScript *런타임은 크게 JavaScript 엔진과 웹 API로 구성되어있다. 그리고 여기에 테스크 큐와 이벤트 루프라는 개념 또한 존재한다. 이를 통해 싱글 쓰레드 기반의 프로그래밍 언어라 불리는 JavaScript도 비동기적으로 코드를 실행시킬 수 있게 된다.

*런타임: 프로그래밍 언어로 작성된 코드가 구동되는 환경

2. JavaScript 엔진

JavaScript 코드를 읽고, 해석, 실행을 담당하는 인터프리터이다. 쓰레드 하나로만 동작하기 때문에 스택 영역도 단 하나만 사용하게 된다. 이로 인해 하나의 함수가 실행이 끝나기 전에는 다른 함수가 실행될 수 없는 "Run to Completion" 특성을 가지게 된다.

JavaScript 엔진의 메모리 모델의 두 가지 영역

1) 힙 영역

메모리를 관리하는 영역
동적으로 생성되는 객체들을 할당하는 곳
구조화되지 않은 넓은 메모리 영역을 지칭한다.
ex) 변수 할당시 관련 정보 저장

2) 스택 영역

실행할 테스크를 관리하는 영역
함수가 실행될 때마다 해당 스택 프레임이 푸시되고,
함수가 종료될 때마다 해당 스택 프레임이 팝 되는 영역을 지칭한다.
ex) 함수 호출 시 스택에 쌓임

스택 영역에 푸시되는 함수의 스택 프레임은 그 함수의 실행 맥락(Execution Context)을 의미한다. 실행 맥락이란, 해당 함수를 실행하기 위해 필요한 각종 정보들(ex. 지역 변수)의 집합이다. JavaScript 엔진은 JavaScript 코드의 실행을 시작함과 동시에 전역 실행 맥락(Global Execution Context)을 스택 영역에 푸시하고, 이후 특정 함수의 호출 문을 만나는 순간 그 함수의 실행 맥락을 스택 영역에 푸시하고 그 함수가 종료될 때 그 실행 맥락을 팝 한다.

JavaScript 코드의 실행이 전부 다 끝나기 전까지는 전역 실행 맥락이 스택 영역에서 팝 되지 않고 남아 있다. 이를 기억하고 있어야 뒤에서 설명할 "스택이 비는 순간"이라는 말의 의미를 조금 더 명확히 이해할 수 있다. 즉, 스택이 비는 순간이라는 것은 결국 더 이상 실행할 JavaScript 코드가 없어서 전역 실행 맥락까지 스택 영역에서 팝이 된 경우를 말한다.

3. 비동기 방식 Event loop로 Javascript의 동시성을 지원한다.

이벤트 루프(Event Loop)를 이용해서 callback queue(브라우저에서 발생한 이벤트) 를 call stack에 보낸다. call stack을 지켜보고있다가, 스택이 비는 순간 callback queue에서 callback function을 꺼내서 실행시켜주는 일만 한다. 이벤트 루프는 계속 stack의 empty 여부만을 신경쓰기 때문에, 비동기 방식으로 실행중인 태스크가 call stack에 있는지, 없는지를 확인한다. 브라우저 입장에서는 single thread 로 처리중인 javascript가 마치 동시에 처리되고 있는 것 처럼 보인다.

구동환경 애니메이션 보기: https://www.jsv9000.app/

4. Web APIs

Web api란?

웹 API는 JavaScript 엔진의 바깥에 위치한다. Ajax 요청, setTimeout(), 이벤트 핸들러의 등록과 같이 웹 브라우저에서 제공하는 기능들을 말한다. 그런데 중요한 것은 이러한 요청들의 처리가 JavaScript 엔진의 쓰레드와는 다른 쓰레드들에서 이뤄진다는 점이다. JavaScript 엔진의 스택에서 실행된 비동기 함수가 요청하는 비동기 작업에 대한 정보와 콜백 함수를 웹 API를 통해 브라우저에게 넘기면, 브라우저는 이러한 요청들을 별도의 쓰레드에 위임하게 되는 것이다. 그러면 그 쓰레드는 해당 요청이 완료되는 순간 전달받았던 콜백 함수를 JavaScript 엔진의 태스크 큐라는 곳에 집어넣는다.

예를 들어, setTimeout() 함수가 실행되면 JavaScript 엔진은 웹 API를 통해 브라우저에게 setTimeout() 작업을 요청하면서 콜백 함수를 전달하고, 브라우저는 이러한 타이머 작업을 별도의 쓰레드에게 위임한다. 그러고 나면 JavaScript 엔진의 스택에서는 setTimeout() 함수의 스택 프레임이 즉시 팝 된다. 그리고 인자로 명시한 시간이 흐르고 나면 해당 타이머 작업을 처리하고 있던 쓰레드는 전달받았던 콜백 함수를 JavaScript 엔진의 태스크 큐에 집어넣게 된다.

5. 이벤트 루프 (Event Loop)

한편, 위와 같은 동작이 가능하려면 매 순간 스택이 비어있는지 여부와 태스크 큐에 콜백 함수가 기다리고 있는지 여부를 확인해야만 한다. 이러한 역할을 수행하는 것이 바로 이벤트 루프이다. 즉, 이벤트 루프는 매 순간 스택이 비어있는지 확인을 해서 스택이 비어있다면 태스크 큐에 콜백 함수가 들어올 때까지 기다렸다가 첫 번째로 들어오는 콜백 함수를 스택에 쌓는 역할을 한다. 만약 스택이 비어있지 않다면 일반적인 방식으로 스택에서 함수의 호출을 처리하게 된다. 결국 이벤트 루프는 이름 그대로 같은 작업을 무한히 반복하는 무한 루프라고 생각하면 이해하기 쉬울 것이다. 참고로 이렇게 매 순간 태스크 큐와 스택을 확인하는 작업을 틱(Tick)이라고 부른다. 이벤트 루프의 동작 방식을 가상의 코드로 설명한다면 다음과 같다고 한다(출처 : MDN).

while (queue.waitForMessage()) {
    queue.processNextMessage();
}

The event loop facilitates this process; it constantly checks whether or not the call stack is empty. If it is empty, new functions are added from the event queue. If it is not, then the current function call is processed. (발췌)

6. 이벤트 루프 기반 비동기 처리 모델

여러 팀에게 작업을 지시한 후, 그 팀들이 작업을 완료하면 결과를 받아보고 후속 조치를 하는 것과 비슷합니다. 메인 스레드(매니저)는 실제 작업을 하지 않고, 작업을 분배하고 결과를 받아 처리하는 역할을 합니다.
메인 스레드는 작업을 백그라운드로 던져줌.
각 작업이 완료되면 콜백을 통해 다시 메인 스레드에서 처리.

주요 장점

병렬 처리: 메인 스레드가 실제로 무거운 작업을 직접 하지 않기 때문에, 여러 비동기 작업들이 백그라운드에서 병렬로 처리될 수 있습니다.
비동기 작업의 효율적 관리: 메인 스레드는 이벤트 루프를 통해 여러 비동기 작업이 완료될 때마다 콜백을 순서대로 처리하여 효율적인 실행 흐름을 유지합니다.

결론

메인 스레드의 핵심 역할은 작업을 외부 쓰레드에 위임하고 그 작업이 완료되면 콜백으로 처리하는 것입니다. 이를 통해 자바스크립트는 단일 스레드 모델을 유지하면서도, 비동기적인 비효율을 최소화하고, 동시성을 활용하여 복잡한 작업을 효율적으로 처리할 수 있습니다.
웹 브라우저는 다양한 작업을 최대한 역할별로 여러 쓰레드에 분산시켜 병렬 처리함으로써 성능을 최적화합니다.최종적으로 자바스크립트의 단일 스레드는 특정한 핵심 역할을 맡고 있습니다.

7. 브라우저의 여러 쓰레드

브라우저는 성능과 효율성을 위해 여러 쓰레드를 사용하여 특정 작업을 비동기적으로 처리합니다. 예를 들면:

렌더링 엔진: 레이아웃 계산, 페인팅, 컴포지팅 작업 등을 처리하는 렌더링 관련 쓰레드.
네트워크 쓰레드: 네트워크 요청과 응답 처리 (XHR, Fetch API 등).
입출력(I/O) 쓰레드: 파일 읽기/쓰기, 데이터베이스 접근 등과 같은 I/O 작업.
타이머 쓰레드: setTimeout, setInterval 같은 타이머 작업을 비동기적으로 관리.
GPU 쓰레드: 그래픽 렌더링, 하드웨어 가속 작업 등을 담당하는 GPU 관련 쓰레드.
Compositor 쓰레드: 화면에 여러 레이어를 조합해 최종적인 결과물을 렌더링하는 쓰레드.

이 외에도, 브라우저는 비동기 작업을 효율적으로 처리하기 위해 여러 백그라운드 쓰레드를 활용합니다.

브라우저의 메인 스레드

작업 위임
- 메인 스레드는 시간이 오래 걸리는 작업(예: 네트워크 요청, 파일 입출력, 렌더링 등)을 해당하는 쓰레드에 위임합니다. 예를 들어, XHR이나 fetch 요청을 보내면, 메인 스레드는 해당 요청을 네트워크 쓰레드로 넘기고 즉시 다음 작업을 수행할 수 있습니다.
비동기 작업 관리
- 작업을 다른 쓰레드로 넘긴 후, 메인 스레드는 즉시 다른 코드를 계속해서 실행합니다. 이 덕분에 자바스크립트는 동시적으로 여러 비동기 작업을 처리할 수 있습니다.
콜백 처리
- 다른 쓰레드에서 비동기 작업이 완료되면, 해당 작업의 결과는 콜백 형태로 메인 스레드에 전달됩니다. 이 때 메인 스레드는 Task Queue나 Microtask Queue에 있는 콜백 함수를 차례대로 실행합니다.
- 예를 들어, setTimeout이나 Promise가 완료되면 그 콜백이 메인 스레드에서 실행됩니다.
DOM 조작 및 UI 업데이트
- 메인 스레드는 DOM 조작과 UI 업데이트도 담당합니다. 사용자가 버튼을 클릭하거나 폼을 제출하는 등의 UI 이벤트를 처리하고, 그에 따른 DOM 변경 작업도 메인 스레드에서 이루어집니다.

브라우저는 다양한 작업을 병렬로 처리하지만, 자바스크립트 단일 스레드는 비동기 작업이 완료된 후 큐에 대기 중인 작업들을 순차적으로 실행합니다.
병목 현상 방지: 브라우저의 여러 쓰레드는 네트워크 요청, 렌더링, I/O 작업 등 시간이 오래 걸리는 작업을 병렬로 처리하고, 자바스크립트 엔진의 단일 스레드는 완료된 비동기 작업의 콜백만 처리하므로 병목 현상을 줄입니다.

8. 태스크 큐 (Task Queue)

태스크 큐는 웹 API를 처리하고 있던 쓰레드로부터 전달받은 콜백 함수들을 FIFO(First-In First-Out) 구조로 저장하고 있는 일종의 큐(Queue)로, JavaScript 엔진 자체에 포함되어 있는 부분이다. 여기에 저장된 콜백 함수들은 스택이 비는 순간 스택에 순서대로 푸시된다. 이러한 원리로 비동기 작업이 완료된 이후 콜백 함수가 실행되는 것이다. 그런데 비동기 작업이 완료되어 태스크 큐에 콜백 함수가 들어가 있더라도 스택이 비어있지 않다면 해당 콜백 함수가 바로 실행되지 못한다는 특징이 있다. 그래서 setTimeout() 함수도 인자로 명시한 시간은 '잠드는 최소 시간'일 뿐, 그것보다 더 오래 잠들 수 있다.

*여기서 말하는 태스크란 곧 콜백 함수를 의미하기 때문에, 태스크 큐는 콜백 큐(Callback Queue)라고 부르고, 이벤트 큐, 메세지 큐라고도 부른다. (콜스택이 비어있을 경우에 등록된 함수를 콜스택에 추가)

9. 잡 큐 (Job Queue)

ECMA 2015 에서 나온 개념으로 Promises에 의해 사용된다. promises는 async 함수를 콜스택에 넣는 대신에 가능한 빨리 실행하도록 하는 방법이다. Promises 는 현재 함수가 끝나기 전에 resolve 된후 현재 함수가 끝나자마자 바로 실행된다. job queue는 event queue 보다 우선 권을 가지고 있어 event queue에 쌓인 함수보다 먼저 실행된다. (상위함수가 종료되기 전에 콜스택이 비어있지 않더라도 잡큐에 등록된 콜백을 콜스택에 추가)

const task = () => console.log('task');
const job = () => console.log('job');

const run = () => {
  console.log('callStack');
  setTimeout(task, 0);
  new Promise((resolve, reject) => resolve('job'))
  	.then((resolve) => job());
};

run();

// 'callStak'
// 'job'
// 'task'

요약

브라우저는 대부분의 무거운 작업(렌더링, 네트워크, I/O 등)을 별도의 쓰레드로 분리하여 비동기적으로 처리하고, 그 결과를 단일 자바스크립트 스레드에서 콜백 함수로 처리합니다. 단일 스레드는 자바스크립트 코드 실행, 이벤트 루프 관리, DOM 조작 등을 담당하며, 비동기 작업의 콜백을 순차적으로 실행하여 브라우저가 매끄럽게 동작할 수 있도록 합니다.

메인 스레드(자바스크립트의 단일 스레드)**의 주된 역할은 여러 작업을 적절한 백그라운드 쓰레드나 시스템 작업자에게 넘겨주고, 그 작업이 완료되었을 때 콜백을 실행하는 것입니다. 이 과정에서 자바스크립트는 비동기적으로 여러 작업을 처리할 수 있지만, 실제로 작업을 실행하는 것은 메인 스레드가 아닌 다른 쓰레드들입니다.