728x90

SvelteKit은 기본적으로 서버 사이드 렌더링(SSR)을 지원합니다. 그런데 writable()로 만든 store 값이 페이지를 새로고침하거나 이동할 때 초기화되는 문제가 발생할 수 있습니다.

문제 원인

  • SvelteKit은 SSR 시 매 요청마다 store 인스턴스를 새로 생성합니다.
  • 이로 인해 클라이언트에서 저장한 store 값이 서버에는 전달되지 않고 초기값으로 리셋됩니다.

간단한 해결 방법: sessionStorage 동기화

클라이언트 환경에서만 store 값을 sessionStorage에 저장하고, 컴포넌트가 로드될 때 다시 불러오도록 설정하면 값이 유지됩니다.

1. store 정의

src/lib/stores/locationStore.ts
import { writable } from 'svelte/store';
import { browser } from '$app/environment';

const initial = browser && sessionStorage.getItem('location')
  ? JSON.parse(sessionStorage.getItem('location'))
  : {
      x: null,
      y: null,
      address: '',
      name: ''
    };

export const locationStore = writable(initial);

locationStore.subscribe(value => {
  if (browser) {
    sessionStorage.setItem('location', JSON.stringify(value));
  }
});
  

2. 사용 예 (store 값 설정)

import { locationStore } from '$lib/stores/locationStore';

function selectStoreData(data) {
  locationStore.set({
    x: data.x,
    y: data.y,
    address: data.address,
    name: data.name
  });
}
  

3. 다른 페이지에서 가져오기

<code class="language-svelte">
<script>
  import { locationStore } from '$lib/stores/locationStore';
  $: location = $locationStore;
</script>

<p>선택된 주소: {location.address}</p>
<p>좌표: {location.x}, {location.y}</p>
</code>

 

 

보완 팁

  • sessionStorage는 탭 간 공유되지 않지만, 새로고침이나 뒤로가기엔 적합
  • localStorage를 사용하면 브라우저 간에도 값 유지 가능
  • 민감한 정보는 절대 저장하지 마세요 (브라우저 저장소는 안전하지 않음)

결론

SvelteKit에서 클라이언트 상태를 SSR 환경에서도 유지하고 싶다면,

가장 간단한 해결책은 스토어 값을 sessionStorage에 저장하고, 페이지 로드시 다시 복원하는 방식입니다.

728x90
728x90

SvelteKit SSR(서버사이드 렌더링) 프로젝트를 Cloudflare Pages Functions 환경에 wranglerwrangler.toml을 이용해 직접 배포한 과정을 정리합니다.

1. SvelteKit 프로젝트 설정

  • @sveltejs/adapter-cloudflare 어댑터 설치
    npm install -D @sveltejs/adapter-cloudflare
  • svelte.config.js에 어댑터 적용
    import adapter from '@sveltejs/adapter-cloudflare';
    export default {
      kit: {
        adapter: adapter()
      }
    };

2. wrangler.toml 파일 작성

프로젝트 루트에 wrangler.toml 파일을 만들고 아래와 같이 작성합니다.

하나라도 빠지면 실패합니다.

name = "프로젝트이름"
pages_build_output_dir = ".svelte-kit/cloudflare"
compatibility_date = "2025-06-04"
compatibility_flags = [ "nodejs_compat" ]
  • name: 프로젝트 이름(영문, 소문자, 숫자, 하이픈 등)
  • pages_build_output_dir: SvelteKit Cloudflare 어댑터 빌드 결과 폴더
  • compatibility_flags: SSR을 위한 Node.js 호환 플래그

3. 빌드 및 배포

  • Cloudflare 계정 로그인
    npx wrangler login
  • 프로젝트 빌드
    npm run build
  • Cloudflare Pages Functions로 배포
    npx wrangler pages deploy .svelte-kit/cloudflare
TIP: wrangler.toml을 수정할 때마다 npm run buildwrangler pages deploy를 다시 실행해야 변경사항이 반영됩니다.

4. 배포 결과 및 확인

  • 배포가 완료되면 https://프로젝트명.pages.dev에서 SSR이 적용된 SvelteKit 사이트를 확인할 수 있습니다.
  • Cloudflare Pages Functions 환경에서 SSR/Edge 기능이 정상 동작합니다.
  • Node.js 내장 모듈(예: async_hooks)을 사용하는 경우 compatibility_flags 옵션이 반드시 필요합니다.

5. 주요 에러 및 해결법

  • async_hooks 에러: wrangler.toml에 compatibility_flags = [ "nodejs_compat" ] 추가
  • Missing top-level field "name": wrangler.toml에 name = "프로젝트이름" 추가
  • pages_build_output_dir 경고: wrangler.toml에 pages_build_output_dir = ".svelte-kit/cloudflare" 추가

6. 참고 자료

정리:
  • SSR이 필요한 SvelteKit 앱은 @sveltejs/adapter-cloudflarewrangler.toml을 이용해 Pages Functions 환경에 배포
  • wrangler.toml에 name, pages_build_output_dir, compatibility_flags 필수
  • 빌드 & 배포는 npm run buildnpx wrangler pages deploy .svelte-kit/cloudflare

Github 연동해서 배포하면 이런 설정은 필요없습니다.

728x90
728x90

 

SvelteKit은 빠르고 유연한 웹 프레임워크로, 최근에는 npx sv create 방식으로 프로젝트를 생성하는 것이 권장됩니다.

📦 프로젝트 생성 명령어

npx sv create my-app

my-app 대신 원하는 프로젝트명을 넣으면 됩니다.

📂 생성 후 기본 작업

cd my-app
npm install
npm run dev

이후 http://localhost:5173에서 프로젝트를 확인할 수 있습니다.

🛠️ 선택 가능한 추가 도구 기능

도구 설명
Prettier 코드 스타일을 자동 정리해주는 포매터
ESLint 문법 오류와 코드 품질 문제를 탐지하는 검사기
Vitest Vite 기반의 빠르고 가벼운 단위 테스트 도구
Playwright 브라우저 기반의 E2E 테스트 도구로 UI 테스트 가능
Tailwind CSS 유틸리티 기반의 CSS 프레임워크로 빠른 스타일링 가능
Drizzle 타입 세이프한 SQL 쿼리 빌더, DB 접근에 적합
Lucia 사용자 인증, 로그인/로그아웃, 세션 관리 등을 지원
MDsveX Markdown을 Svelte 컴포넌트처럼 사용하는 플러그인
Paraglide 다국어(i18n) 지원을 위한 번역 도구
Storybook 컴포넌트 독립 개발 및 문서화를 위한 UI 도구

💡 추천 조합 예시

  • 웹앱 개발: Tailwind CSS, ESLint, Prettier, Vitest, Lucia, Drizzle
  • 블로그/문서 사이트: MDsveX, Prettier, ESLint, Tailwind CSS
  • 디자인 시스템/대규모 UI: Storybook, Prettier, ESLint, Vitest, Tailwind CSS

🔗 참고 링크

728x90
728x90

 

이 글에서는 Emscripten을 사용하여 C 코드를 WebAssembly(WASM)로 변환하는 방법을 설명합니다.

1️⃣ Emscripten 설치

Emscripten을 설치하려면 다음 명령어를 사용하세요.

git clone https://github.com/emscripten-core/emsdk.git
cd emsdk
./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh

2️⃣ C 코드 작성

아래는 간단한 C 코드 예제입니다.

#include <stdio.h>

int add(int a, int b) {
    return a + b;
}

3️⃣ WASM으로 컴파일

다음 명령어를 실행하여 C 코드를 WebAssembly로 변환하세요.

emcc example.c -o example.js -s WASM=1 -s EXPORTED_FUNCTIONS='["_add"]' -s MODULARIZE=1

4️⃣ HTML에서 실행

생성된 example.jsexample.wasm 파일을 웹에서 로드하여 실행할 수 있습니다.

<script src="example.js"></script>
<script>
    Module().then((module) => {
        console.log("2 + 3 =", module._add(2, 3));
    });
</script>

🎉 마무리

이제 C 코드를 WebAssembly로 변환하여 웹에서 사용할 수 있습니다!

728x90
728x90

웹서버가 설치된 리눅스 컨테이너(록키리눅스1)와 Nginx를 설치할 리눅스 컨테이너(록키리눅스2)가 각각임.
CPU 2코어, 램 2GB, 저장장치 20GB를 할당해서 생성.
웹서버(록키리눅스1)의 서비스 IP는 192.168.1.100:3000, Nginx서버(록키리눅스2)의 IP는 192.168.1.200

1. 리버스 프록시 설정이란?

리버스 프록시(reverse proxy)는 클라이언트의 요청을 받아 실제 서버로 요청을 전달하고, 그 결과를 클라이언트에 반환하는 역할을 하는 서버입니다. 이 방식은 보안, 로드 밸런싱, 캐싱 등 여러 가지 이점을 제공합니다.

2. Nginx를 사용한 리버스 프록시 설정

여기서는 Nginx를 사용하여 리버스 프록시를 설정하는 방법을 소개합니다. Nginx는 요청을 다른 서버로 전달하는 매우 효율적인 웹 서버로, 여러 웹 서버를 관리하는 데 유용합니다.

설정 파일 구조

server {
    listen 1010;  # 포트 1010에서 요청을 수신
    server_name 192.168.1.200;  # 서버의 IP 주소

    location / {
        proxy_pass http://192.168.1.100:3000;  # SvelteKit 서버 IP와 포트
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

이 설정에서는 `192.168.1.200`의 IP 주소로 들어오는 요청을 192.168.1.100:3000에서 구동되는 SvelteKit 애플리케이션으로 전달합니다.

3. 여러 웹 서버를 한 서버에서 구동하기

여러 개의 웹 서버를 같은 IP에서 구동하려면, 포트 번호만 다르게 설정하면 됩니다. 아래는 여러 포트에서 각각 다른 웹 서버를 구동하는 예시입니다.

여러 웹 서버 설정 예시

server {
    listen 1010;  # 포트 1010에서 요청을 수신
    server_name 192.168.1.200;  # 서버의 IP 주소

    location / {
        proxy_pass http://192.168.1.100:3000;  # SvelteKit 애플리케이션
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 1020;  # 포트 1020에서 요청을 수신
    server_name 192.168.1.200;

    location / {
        proxy_pass http://192.168.1.101:3000;  # 다른 애플리케이션
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

위 설정에서는 포트 1010에서 SvelteKit 애플리케이션을, 포트 1020에서 다른 애플리케이션을 처리하도록 설정합니다.

4. 설정 파일 분리 방법

각 웹 서버마다 개별 설정 파일을 생성하여 관리하는 것이 효율적입니다. Nginx에서는 conf.d 디렉토리나 include 지시어를 사용하여 여러 설정 파일을 분리할 수 있습니다.

개별 설정 파일 생성

각각의 웹 서버에 대해 별도의 설정 파일을 생성할 수 있습니다. 예를 들어:

/etc/nginx/conf.d/webserver_1.conf
/etc/nginx/conf.d/webserver_2.conf

설정 파일에 `include` 사용

`nginx.conf` 파일에 여러 개의 설정 파일을 포함시키는 방법:

include /etc/nginx/conf.d/*.conf;

이렇게 하면 여러 설정 파일을 각각 관리할 수 있습니다.

5. Nginx 설정 재시작

설정을 변경한 후에는 Nginx를 재시작해야 합니다. 아래 명령어로 설정 파일을 테스트하고 Nginx를 재시작할 수 있습니다:

sudo nginx -t  # 설정 파일 테스트
sudo systemctl restart nginx  # Nginx 재시작

이 포스트는 Nginx를 이용한 리버스 프록시 설정 방법과 여러 웹 서버를 동일한 IP에서 구동하는 방법에 대해 다루었습니다. 더 많은 정보를 원하시면 공식 Nginx 문서나 관련 자료를 참고하세요.

 

 이 방법을 사용하면 여러가지 이점이 있지만 그 중에서 하나의 도메인 네임에 여러개의 하부 도메인을 생성할 수 있는 기능이 있습니다.

main.com이란 도메인을 가지고 있다고 가정하면 blog.main.com, test.main.com, coding.main.com 등등 생성하여 각각의 서비스를 제공할 수 있습니다.

기본 Proxmox에서 이뤄지는 세팅이긴 하지만 여기에서 다루는 내용은 그냥 웹서버 설정이 주가 되기 때문에 Web카테고리로 설정합니다.

728x90
728x90

Podman 이미지 크기를 줄이는 방법

Podman에서 이미지 크기를 줄이는 방법은 Docker에서 이미지를 최적화하는 방법과 매우 유사합니다. Dockerfile을 최적화하여 더 작은 이미지를 만들 수 있는 주요 방법은 다음과 같습니다.

1. 멀티스테이지 빌드 사용

멀티스테이지 빌드는 빌드 과정에서 필요한 종속성만 포함된 작은 이미지를 생성할 수 있게 도와줍니다. 빌드 단계에서 필요하지 않은 파일이나 패키지는 최종 이미지에 포함되지 않기 때문에 크기를 크게 줄일 수 있습니다.

 
# 빌드 단계
FROM node:16 AS build
WORKDIR /app
COPY . .
RUN npm install

# 최종 이미지 단계
FROM node:16-slim
WORKDIR /app
COPY --from=build /app /app
RUN npm install --production
CMD ["node", "index.js"]
        

2. 불필요한 파일을 .dockerignore로 제외

.dockerignore 파일을 사용하여 빌드에 불필요한 파일을 제외하면 이미지 크기를 줄일 수 있습니다. 예를 들어, node_modules, 로그 파일, 테스트 코드 등을 .dockerignore에 추가하세요.


# .dockerignore 예시
node_modules/
*.log
*.md
test/
        

3. 최소화된 베이스 이미지 사용

가능한 경우 최소화된 이미지를 사용하세요. 예를 들어, alpine 이미지는 다른 배포판보다 훨씬 작은 이미지입니다. alpine을 사용할 때 필요한 라이브러리나 패키지들만 추가하면 이미지 크기를 크게 줄일 수 있습니다.


FROM python:3.9-alpine
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]
        

4. 이미지 레이어 최소화

RUN 명령어를 여러 번 사용하면 각 명령어가 새로운 레이어를 생성하므로 이미지 크기가 커질 수 있습니다. 여러 명령어를 하나로 합쳐서 레이어 수를 줄여보세요.


# 비효율적인 예
RUN apt-get update
RUN apt-get install -y build-essential

# 최적화된 예
RUN apt-get update && apt-get install -y build-essential
        

5. 캐시를 사용한 최적화

캐시를 사용하여 이미지 빌드를 빠르게 만들 수 있지만, 때때로 캐시가 너무 많이 쌓여 이미지 크기가 커질 수 있습니다. 불필요한 캐시를 지우는 것도 중요합니다.


RUN apt-get update && \
    apt-get install -y build-essential && \
    apt-get clean
        

6. 작은 라이브러리 또는 프레임워크 사용

이미지에서 사용하는 라이브러리나 프레임워크가 불필요하게 크다면, 더 작은 대체품을 고려해보세요. 예를 들어, nginxnginx:alpine을 사용하는 것처럼, 가능한 경량화된 버전의 소프트웨어를 선택하는 것이 좋습니다.

결론

위의 방법들을 적용하면 Podman으로 생성되는 이미지의 크기를 줄이는 데 도움이 될 것입니다. Docker와 Podman은 이미지 빌드 방식에서 큰 차이가 없기 때문에, 이러한 최적화는 Podman에서도 동일하게 적용됩니다. 이미지를 최적화하여 더 빠르고 효율적인 컨테이너 환경을 구축해 보세요!

728x90

+ Recent posts