lalunru.blog

[MSW] REST 스냅샷과 WebSocket 실시간 데이터를 함께 쓸 때 생기는 경쟁 조건

lalunru — Wed, 10 Jun 2026 22:42:05 +0900

1. 들어가며

WebSocket으로 실시간 데이터를 받는 컴포넌트를 구현할 때, 흔히 마주치는 UX 문제가 있습니다. WS 연결이 완료되기까지 (STOMP 핸드셰이크, 구독, 첫 메시지 수신) 수 초가 걸리는 동안 사용자는 스켈레톤 화면만 보게 됩니다. 이를 개선하기 위해 REST로 스냅샷을 먼저 받아 화면을 채우고, 이후 WS 실시간 데이터로 자연스럽게 전환하는 패턴을 도입했습니다. 그런데 이 방식을 단순하게 구현하면 REST와 WS 응답 사이에 경쟁 조건이 발생합니다. 이 글에서는 그 문제와 useRef를 활용한 해결 방법을 정리합니다.

2. 문제 상황: REST와 WS가 동시에 달린다

호가창 컴포넌트는 아래 두 가지 데이터 소스를 동시에 운용합니다.

REST: 컴포넌트 마운트 시 /api/stocks/{stockCode}/orderbook으로 스냅샷 요청
WS: STOMP over SockJS로 /topic/orderbook/{stockCode} 구독, 1초마다 실시간 데이터 수신

대부분의 경우 REST가 먼저 응답하고, 이후 WS가 연결되어 실시간으로 교체되는 시나리오 A로 흘러갑니다.

시나리오 A (정상)
t=0ms    REST 요청 + WS 연결 시작
t=200ms  REST 응답 → 스냅샷 화면에 표시
t=800ms  WS 연결 완료 → 실시간 데이터로 교체

문제는 네트워크 상황에 따라 WS가 먼저 도착하는 시나리오 B입니다.

시나리오 B (역전)
t=0ms    REST 요청 + WS 연결 시작
t=500ms  WS 연결 완료 → 실시간 데이터로 화면 표시
t=700ms  REST 응답 → 더 오래된 스냅샷으로 덮어씌움 ← 문제

시나리오 B에서 REST 응답이 늦게 도착하면, 이미 최신 실시간 데이터가 표시된 화면을 과거 스냅샷이 덮어쓰게 됩니다. 사용자 입장에서는 화면이 순간적으로 과거 값으로 되돌아가는 것처럼 보입니다.

3. 왜 useState로는 해결이 어려운가

가장 먼저 떠올릴 수 있는 방법은 useState로 WS 수신 여부를 추적하는 것입니다.

const [wsReceived, setWsReceived] = useState(false);

// WS 수신 시
client.subscribe(topic, (message) => {
  setWsReceived(true); // 상태 업데이트 → 리렌더링 트리거
  setRaw(JSON.parse(message.body));
});

// REST 응답 시
getOrderbook(stockCode).then((snapshot) => {
  if (wsReceived) return; // wsReceived를 참조
  setRaw(snapshot);
});

이 코드에는 두 가지 문제가 있습니다.

첫째, stale closure 문제입니다. getOrderbook().then() 콜백은 호출 시점의 wsReceived 값을 클로저로 캡처합니다. REST 요청을 보낸 시점에는 wsReceived가 false였기 때문에, WS가 먼저 도착해서 setWsReceived(true)를 호출해도 이미 캡처된 클로저 안의 wsReceived는 여전히 false입니다. 결국 조건문을 통과하여 스냅샷이 덮어쓰게 됩니다.

REST 요청 시점:  wsReceived = false (클로저에 캡처)
WS 수신:        setWsReceived(true) → 리렌더링
REST 응답 도착: 클로저 안의 wsReceived는 여전히 false → 덮어씌움 발생

둘째, 불필요한 리렌더링입니다. wsReceived는 화면에 표시할 값이 아니라 내부 제어 플래그입니다. 이 값이 바뀔 때마다 리렌더링이 발생하면 컴포넌트 전체가 다시 그려지는 비용이 생깁니다.

4. 해결: useRef로 비동기 클로저 간 상태 공유

useRef는 렌더링을 트리거하지 않으면서, 컴포넌트 생애주기 동안 동일한 객체 참조를 유지합니다. 비동기 콜백들이 같은 ref.current를 바라보기 때문에 stale closure 문제가 발생하지 않습니다.

const wsReceivedRef = useRef(false);

// REST 선호출
useEffect(() => {
  wsReceivedRef.current = false; // stockCode 변경 시 초기화

  getOrderbook(stockCode).then((snapshot) => {
    if (wsReceivedRef.current) return; // WS가 이미 받았으면 무시
    if (snapshot) {
      setRaw(snapshot);
      setStatus('default');
    }
    // snapshot이 null이면 skeleton 유지 (장 시작 전, 미수집 상태)
  });
}, [stockCode]);

// WS 수신 시 플래그 설정
client.subscribe(topic, (message) => {
  wsReceivedRef.current = true; // 이후 REST 응답은 항상 무시
  setRaw(JSON.parse(message.body));
  setStatus('default');
});

wsReceivedRef.current는 어느 콜백에서 읽든 항상 현재 값을 반환합니다. WS 수신 후 true로 바뀌고 나면, 나중에 도착한 REST 응답의 콜백에서 참조해도 true가 읽힙니다. stale closure가 발생하지 않습니다.

useState와 useRef의 차이를 정리하면 다음과 같습니다.

useState useRef

리렌더링 트리거	O	X
비동기 콜백에서의 최신값 참조	X (stale closure)	O (항상 현재값)
화면에 표시할 값	적합	부적합
내부 제어 플래그	부적합	적합

5. 우선순위 전략: "마지막이 이긴다"가 아니다

이 패턴의 핵심은 단방향 우선순위입니다. "가장 나중에 도착한 데이터가 이긴다"는 단순한 규칙이 아니라, WS가 한 번이라도 수신되면 REST는 항상 진다는 명확한 우선순위를 가집니다. 이렇게 설계한 이유는 두 데이터 소스의 성격이 다르기 때문입니다. REST 스냅샷은 요청 시점의 정적인 값이고, WS 데이터는 실시간으로 갱신되는 값입니다. 어느 시점에 도착하든, 실시간 데이터가 스냅샷보다 항상 우선합니다.

6. 엣지 케이스 처리

snapshot이 null인 경우

REST 응답에서 data: null이 내려오는 경우가 있습니다. 장 시작 전이거나 아직 데이터가 수집되지 않은 상태입니다. 이 경우 스켈레톤을 유지하고 에러 상태로 전환하지 않습니다. null은 서버 오류가 아니라 정상 응답이기 때문입니다.

getOrderbook(stockCode).then((snapshot) => {
  if (wsReceivedRef.current) return;
  if (snapshot) {           // null이면 이 블록을 건너뜀
    setRaw(snapshot);
    setStatus('default');
  }
  // snapshot이 null → status는 'skeleton' 유지
});

WS 연결이 끊기는 경우

WS가 끊기더라도 이미 받아둔 데이터(REST 스냅샷 또는 마지막 WS 데이터)를 유지합니다. 스켈레톤으로 되돌리지 않습니다. 사용자 입장에서 잠깐의 연결 끊김으로 화면이 비는 것보다, 약간 오래된 데이터가 표시되는 편이 낫습니다.

STOMP 오류 처리

STOMP 연결 오류 시 상태 전환은 현재 상태에 따라 분기합니다.

client.onStompError = () => {
  // 이미 데이터가 있는 상태면 유지, 스켈레톤 상태일 때만 에러로 전환
  setStatus((prev) => (prev === 'skeleton' ? 'error' : prev));
};

데이터가 이미 화면에 있는데 WS 오류가 발생했다고 해서 에러 UI로 전환하면 사용자 경험이 오히려 나빠집니다.

7. 마무리

REST와 WS를 함께 운용할 때 발생하는 경쟁 조건은 "타이밍 문제"처럼 보이지만, 실제로는 두 비동기 소스 간의 우선순위를 명확하게 정의하지 않아서 생기는 설계 문제입니다. useRef가 이 상황에서 적합한 이유는 단순히 리렌더링을 막아서가 아닙니다. 비동기 콜백이 클로저로 값을 캡처하는 특성상, 항상 최신값을 참조할 수 있는 뮤터블 컨테이너가 필요하고, useRef가 정확히 그 역할을 합니다. 화면에 표시할 필요 없는 내부 제어 플래그라면 useState보다 useRef가 더 적합한 도구입니다.

8. 참고 자료

React 공식 문서 — useRef
https://react.dev/reference/react/useRef
React 공식 문서 — Synchronizing with Effects
https://react.dev/learn/synchronizing-with-effects
@stomp/stompjs 공식 문서
https://stomp-js.github.io/guide/stompjs/using-stompjs-v5.html

[MSW] MSW v2가 WebSocket을 막을 때 — SockJS 폴백으로 우회한 방법

lalunru — Fri, 15 May 2026 16:59:52 +0900

1. 들어가며

프론트엔드 개발 환경에서 MSW(Mock Service Worker)는 API 목 처리에 있어 거의 표준에 가까운 도구가 되었습니다. REST 요청을 인터셉트하고 가짜 응답을 내려주는 역할을 깔끔하게 수행해 줍니다.

그런데 MSW v2부터 WebSocket 인터셉트 기능이 추가되면서 예상치 못한 문제와 마주쳤습니다. 실제 백엔드 WebSocket 서버에 연결해야 하는 상황인데, MSW가 포트와 URL을 가리지 않고 브라우저의 모든 WebSocket 연결을 가로채 버린 것입니다.

이 글은 그 문제를 해결하기 위해 시도했던 방법들과 최종적으로 SockJS의 특성을 이용해 우회한 과정을 공유합니다.

2. 문제 상황: MSW v2의 WebSocket 전면 인터셉트

프로젝트는 호가창(주문서) 데이터를 STOMP over WebSocket 방식으로 백엔드에서 실시간으로 수신하는 구조였습니다. 백엔드 서버는 포트 9090에서 /topic/orderbook/{stockCode} 토픽으로 1초마다 데이터를 전송합니다.

문제는 MSW v2가 window.WebSocket을 전역으로 패치한다는 점이었습니다. MSW가 초기화되는 순간, 브라우저에서 발생하는 모든 WebSocket 연결 시도(포트 번호나 URL에 무관하게)를 MSW가 먼저 가로채게 됩니다.

즉, 프론트엔드 개발 서버(포트 5173)에서 백엔드(포트 9090)로 WebSocket 연결을 시도해도, MSW 입장에서는 localhost 어딘가로 향하는 WS 연결이기 때문에 그냥 가로채 버립니다.

[브라우저] WS 연결 시도 → localhost:9090/ws
               ↓
[MSW] "내가 처리한다" (인터셉트)
               ↓
[결과] 실제 백엔드와 연결 불가

3. 시도한 방법들과 실패 원인

시도 1. Vite 프록시로 우회

가장 먼저 떠올린 방법은 Vite의 프록시 설정이었습니다. /ws-orderbook 경로를 9090으로 프록시하고, WS 연결 URL을 localhost:5173/ws-orderbook으로 바꾸면 같은 포트 내에서 연결되니 MSW를 속일 수 있을 거라 생각했습니다.

// vite.config.ts
server: {
  proxy: {
    '/ws-orderbook': {
      target: 'http://localhost:9090',
      ws: true,
    },
  },
},

결과: 실패. MSW는 localhost:5173 자체를 통째로 인터셉트하기 때문에, 프록시 경로를 바꿔도 MSW가 먼저 연결을 가로챕니다. 프록시는 서버 레벨의 작업이고, MSW 패치는 브라우저 레벨의 작업이라 순서상 MSW가 항상 먼저입니다.

시도 2. MSW `server.connect()` passthrough

MSW에는 특정 연결을 실제 서버로 통과시키는 passthrough API가 있습니다.

// MSW WebSocket passthrough 시도
ws.link('ws://localhost:9090/*').on('connection', ({ server }) => {
  server.connect();
});

결과: 실패. 브라우저 환경에서 MSW의 Service Worker가 실제 외부 WS 연결을 중계하는 방식이 제대로 동작하지 않았습니다. 연결 자체가 성립되지 않거나 데이터 수신이 불안정했습니다.

시도 3. NativeWebSocket 캡처

MSW가 window.WebSocket을 패치하기 전에 원본 WebSocket 생성자를 미리 캡처해두는 방법을 시도했습니다.

// MSW 임포트보다 먼저 실행되길 기대
const NativeWebSocket = window.WebSocket;

결과: 실패. Vite의 모듈 번들링 특성상 임포트 순서를 코드 작성 순서로 완전히 보장할 수 없었고, 실제로 MSW 패치가 항상 먼저 적용되었습니다. ES 모듈의 정적 분석과 호이스팅 동작 때문에 이 접근법 자체가 구조적으로 불안정합니다.

시도 4. MSW 전체 비활성화

개발 편의를 위해 .env.local에 환경변수를 추가해 MSW를 아예 끄는 방법을 시도했습니다.

결과: 반쪽짜리 해결. 호가창은 동작했지만, 종목 랭킹, 실시간 시세 등 다른 MSW 핸들러에 의존하는 기능이 전부 함께 죽었습니다. 하나를 살리려고 전체를 희생하는 방식이라 근본적인 해결책이 아니었습니다.

4. 핵심 발견: 백엔드는 SockJS를 사용하고 있었다

네 가지 시도가 모두 막히고 나서, 방향을 바꿔 백엔드 코드를 직접 살펴보았습니다. WebSocketConfig.java를 확인하니 백엔드가 순수 WebSocket이 아닌 SockJS를 사용하고 있다는 것을 발견했습니다.

// WebSocketConfig.java (백엔드)
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
    registry.addEndpoint("/ws")
            .setAllowedOriginPatterns("*")
            .withSockJS(); // SockJS 사용 중
}

여기서 SockJS의 동작 방식이 문제 해결의 실마리가 되었습니다.

SockJS는 WebSocket을 직접 사용하지 않을 때, HTTP 롱폴링(Long-Polling)으로 폴백합니다. 연결 전 /info 엔드포인트에 HTTP 요청을 보내 서버의 WebSocket 지원 여부를 확인하고, 그 결과에 따라 전송 방식을 결정합니다.

즉, SockJS를 클라이언트로 사용하면 window.WebSocket을 직접 사용하지 않고 HTTP 요청 기반으로 통신할 수 있습니다. MSW의 WS 인터셉트는 window.WebSocket을 패치하는 것이기 때문에, HTTP 기반으로 동작하는 SockJS 연결은 MSW의 영향권 밖에 있습니다.

5. 최종 해결: SockJS + STOMP 직접 연결

sockjs-client를 설치하고, @stomp/stompjs의 webSocketFactory에 SockJS를 주입하는 방식으로 교체했습니다.

npm install sockjs-client @stomp/stompjs
npm install --save-dev @types/sockjs-client

// use-orderbook.ts (변경 후)
import { Client } from '@stomp/stompjs';
import SockJS from 'sockjs-client';

const client = new Client({
  // window.WebSocket 대신 SockJS를 팩토리로 주입
  webSocketFactory: () => new SockJS('http://localhost:9090/ws'),
  onConnect: () => {
    client.subscribe(`/topic/orderbook/${stockCode}`, (message) => {
      const data: OrderbookDto = JSON.parse(message.body);
      setViewModel(data);
    });
  },
});

client.activate();

기존에 사용하던 useWebSocket 훅이나 내장 WebSocket을 거치지 않고, SockJS 팩토리를 직접 주입함으로써 MSW의 인터셉트를 완전히 우회했습니다.

6. 추가 문제: SockJS의 `/info` 요청도 MSW가 가로챈다

연결은 성공했지만, 콘솔에서 새로운 오류가 발생했습니다. SockJS는 연결 전 서버 상태를 확인하기 위해 http://localhost:9090/ws/info 로 HTTP GET 요청을 먼저 보내는데, MSW가 이 HTTP 요청까지 인터셉트해서 핸들러가 없다는 오류를 뱉고 있었습니다.

해결 방법은 간단했습니다. MSW 핸들러 파일에 localhost:9090으로 향하는 모든 요청을 통과시키는 passthrough 핸들러를 추가했습니다.

// handlers/stock.ts (MSW 핸들러 파일)
import { http, passthrough } from 'msw';

export const stockHandlers = [
  // 기존 핸들러들...

  // localhost:9090으로 향하는 모든 요청은 실제 서버로 통과
  http.get('http://localhost:9090/*', () => passthrough()),
  http.post('http://localhost:9090/*', () => passthrough()),
];

이렇게 하면 MSW가 살아있으면서도, 9090 포트로 향하는 요청은 MSW를 거치지 않고 실제 백엔드로 전달됩니다.

7. 마무리 및 회고

문제를 정리하면 다음과 같습니다.

시도	실패 원인
Vite 프록시 우회	MSW는 브라우저 레벨에서 패치 → 프록시 경로 변경으로는 우회 불가
MSW passthrough	브라우저 환경에서 WS 중계가 불안정
NativeWebSocket 캡처	Vite 모듈 시스템의 임포트 순서 보장 불가
MSW 전체 비활성화	다른 MSW 의존 기능 전체 손상
SockJS 주입 (최종 해결)	HTTP 폴링 기반 → MSW WS 인터셉트 우회

이번 트러블슈팅의 핵심은 결국 라이브러리의 내부 동작 원리를 파악하는 것이었습니다. MSW가 window.WebSocket을 패치한다는 점과 SockJS가 상황에 따라 HTTP 폴링으로 폴백할 수 있다는 점, 이 두 가지 파편화된 지식을 연결하지 못했다면 네 번의 실패 이후에도 계속 같은 레이어에서 맴돌았을 것입니다.

도구를 사용할 때 "어떻게 쓰는가"만큼 "어떻게 동작하는가"를 아는 것이 막힌 상황을 돌파하는 데 훨씬 직접적인 무기가 된다는 것을 다시 한번 실감했습니다.

8. 참고 자료

MSW 공식 문서 — Intercepting WebSockets
https://mswjs.io/docs/api/ws
SockJS 공식 GitHub — How it works
https://github.com/sockjs/sockjs-client#readme
@stomp/stompjs 공식 문서 — Using with SockJS
https://stomp-js.github.io/stomp-websocket/codo/extra/docs-src/sockjs.md.html

[Shadertoy] Shadertoy 입문 — 브라우저에서 시작하는 실시간 셰이더 개발

lalunru — Mon, 11 May 2026 17:14:25 +0900

1. 들어가며

셰이더를 처음 공부할 때 가장 큰 장벽은 환경 세팅입니다. OpenGL 컨텍스트를 만들고, 컴파일 파이프라인을 구성하고, 렌더링 루프를 짜야 비로소 "Hello, Triangle"을 볼 수 있습니다.Shadertoy는 그 과정을 브라우저 하나로 압축합니다. 계정을 만들고 접속하면, 코드를 작성하는 즉시 결과가 화면에 렌더링됩니다. 별도의 IDE도, 그래픽스 드라이버 설정도 필요 없습니다. 이 글에서는 Shadertoy의 기본 구조와 핵심 유니폼 변수를 정리하고, 실제로 이 플랫폼을 활용해 제가 구현한 NPR 셰이더들이 어떤 원리로 동작하는지 간략하게 소개합니다.

2. Shadertoy가 뭔가요?

Shadertoy는 Inigo Quilez(iq)와 Pol Jeremias가 만든 웹 기반 GLSL 셰이더 샌드박스입니다.

브라우저에서 GLSL ES(WebGL 기반)로 Fragment Shader를 작성하면 실시간으로 렌더링되는 특징이 있습니다. 전 세계 개발자들이 올린 셰이더를 포크하거나 코드를 직접 확인할 수 있어 학습 자료로도 방대하며, 저장 및 공유가 URL 하나로 끝나 용이합니다. 처음 접속하면 우측 상단의 New 버튼을 클릭해 새 셰이더를 만들 수 있습니다. 로그인 없이도 작성과 실행은 가능하지만, 저장과 공유를 위해서는 계정이 필요합니다. 편집창 하단의 ▶ (컴파일 버튼) 또는 Alt+Enter를 누르면 코드가 즉시 반영됩니다. 단, Shadertoy에서 작성하는 코드는 Fragment Shader만입니다. Vertex Shader는 플랫폼이 내부적으로 처리하며, 사용자는 각 픽셀의 색상을 결정하는 로직만 작성합니다.

3. 기본 구조 이해하기

Shadertoy를 처음 열면 아래와 같은 화면이 나타납니다. 왼쪽이 렌더링 결과, 오른쪽이 코드 편집창입니다.

기본으로 작성되어 있는 코드는 다음과 같습니다.

void mainImage(out vec4 fragColor, in vec2 fragCoord) {
    vec2 uv = fragCoord / iResolution.xy;
    vec3 col = vec3(uv, 0.0);
    fragColor = vec4(col, 1.0);
}

일반적인 GLSL의 main() 대신 mainImage()를 진입점으로 사용합니다. 파라미터는 다음과 같습니다.

파라미터	설명
`out vec4 fragColor`	최종 출력 색상 (RGBA)
`in vec2 fragCoord`	현재 픽셀의 화면 좌표 (픽셀 단위)

위 코드를 실행하면 좌하단이 검정, 우상단이 노란색인 그라디언트가 렌더링됩니다. uv.x가 R 채널, uv.y가 G 채널에 각각 매핑되기 때문입니다.

4. 자주 쓰는 유니폼 변수 (Built-in Uniforms)

Shadertoy는 셰이더에 자동으로 전달되는 내장 유니폼 변수들을 제공합니다. 이 변수들을 이해하는 것이 Shadertoy 활용의 핵심입니다.

uniform vec3  iResolution;   // 뷰포트 해상도 (픽셀 단위, z는 픽셀 종횡비)
uniform float iTime;         // 셰이더 실행 시간 (초)
uniform float iTimeDelta;    // 이전 프레임과의 시간 차이 (초)
uniform int   iFrame;        // 현재 프레임 번호
uniform vec4  iMouse;        // 마우스 상태 (xy: 현재 위치, zw: 클릭 위치)
uniform vec4  iDate;         // 현재 날짜 (년, 월, 일, 시각(초))
uniform sampler2D iChannel0; // 입력 채널 0 (텍스처, 사운드 등)

가장 자주 쓰는 세 가지를 정리하면 다음과 같습니다.

iResolution — UV 정규화

// 픽셀 좌표를 0.0 ~ 1.0 범위로 정규화
vec2 uv = fragCoord / iResolution.xy;

// 화면 중앙을 원점으로, 종횡비를 보정한 좌표계
vec2 uv = (fragCoord - 0.5 * iResolution.xy) / iResolution.y;

두 번째 방식이 더 자주 쓰입니다. 화면 비율에 상관없이 원형이 원형으로 렌더링되기 때문입니다.

iTime — 애니메이션

// 시간에 따라 색상이 변하는 예시
float r = 0.5 + 0.5 * sin(iTime);
float g = 0.5 + 0.5 * sin(iTime + 2.094); // 120도 위상 차이
float b = 0.5 + 0.5 * sin(iTime + 4.188); // 240도 위상 차이
fragColor = vec4(r, g, b, 1.0);

iMouse — 인터랙션

// 마우스 위치를 UV 좌표로 변환
vec2 mouse = iMouse.xy / iResolution.xy;

// 마우스 클릭 여부 확인 (iMouse.z > 0 이면 클릭 중)
if (iMouse.z > 0.0) {
    // 클릭 중일 때의 로직
}

5. 자주 쓰는 GLSL 함수

Shadertoy에서 사실상 표준처럼 쓰이는 함수들입니다.

// 값을 특정 범위로 부드럽게 전환 (셰이더의 핵심 함수)
float smoothstep(float edge0, float edge1, float t);

// 두 값 사이를 선형 보간
float mix(float a, float b, float t);  // t=0이면 a, t=1이면 b

// 길이 1로 정규화
vec3 normalize(vec3 v);

// 내적 (두 벡터의 방향 유사도)
float dot(vec3 a, vec3 b);

// 픽셀 단위의 미분값 (안티앨리어싱에 활용)
float fwidth(float p);  // abs(dFdx(p)) + abs(dFdy(p))

// 소수점 부분만 추출 (타일링 패턴에 유용)
float fract(float x);

// 절대값, 최소/최대값
float abs(float x);
float min(float a, float b);
float max(float a, float b);
float clamp(float x, float minVal, float maxVal);

6. 실전 예시: 원 그리기

이론을 이해했으면 가장 기본적인 형태를 직접 그려보는 것이 빠릅니다. 아래 코드를 그대로 붙여넣으면 흰 원이 렌더링됩니다.

void mainImage(out vec4 fragColor, in vec2 fragCoord) {
    // 화면 중앙 원점, 종횡비 보정 UV
    vec2 uv = (fragCoord - 0.5 * iResolution.xy) / iResolution.y;

    // 원점으로부터의 거리
    float dist = length(uv);

    // 반지름 0.3의 원 (smoothstep으로 경계를 부드럽게)
    float circle = smoothstep(0.31, 0.29, dist);

    fragColor = vec4(vec3(circle), 1.0);
}

smoothstep(0.31, 0.29, dist)는 dist가 0.31보다 크면 0, 0.29보다 작으면 1을 반환합니다. 이 두 값 사이에서 부드럽게 전환되어 경계에 안티앨리어싱이 적용됩니다.

7. Shadertoy에서 Unity로 이식하기

Shadertoy는 프로토타이핑에 최적화된 환경이지만, 실제 게임이나 앱에 적용하려면 Unity(HLSL)로 이식해야 합니다. 주요 차이점은 다음과 같습니다.

항목	Shadertoy (GLSL)	Unity URP (HLSL)
진입점	`mainImage()`	`frag()`
UV 좌표	`fragCoord / iResolution.xy`	`i.uv` (버텍스에서 전달)
시간	`iTime`	`_Time.y`
텍스처 샘플링	`texture(iChannel0, uv)`	`SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, uv)`
벡터 타입	`vec2 / vec3 / vec4`	`float2 / float3 / float4`

함수명과 타입 표기만 변환하면 대부분의 로직은 그대로 이식됩니다. vec3 → float3, mix → lerp 정도가 가장 자주 만나는 차이입니다.

8. 실제로 만든 것들

이 파이프라인을 활용해 직접 구현한 NPR 셰이더들입니다.

Cross-Hatching: Value Noise로 유기적인 펜화 질감을 구현한 크로스해칭 셰이더

Toon Shading + Rim Light: Hue-Shift와 스크린 스페이스 노멀 불연속성 감지로 구현한 셀 애니메이션 스타일

Null Cathedral: IFS 기반 프랙탈 레이마칭 + ACES 톤매핑, 크로마틱 어버레이션 포스트 프로세싱

프로젝트 상세 기록 보기
Shadertoy 프로필

9. 마무리

Shadertoy는 셰이더를 처음 접하는 사람에게는 진입 장벽을 낮춰주고, 이미 알고 있는 사람에게는 아이디어를 빠르게 검증하는 도구입니다. "브라우저를 열고 코드를 작성하면 결과가 나온다"는 단순한 피드백 루프가 셰이더 학습의 속도를 크게 높여줍니다. 수식과 결과가 즉시 연결되는 경험을 반복하다 보면, 렌더링 파이프라인에 대한 직관이 자연스럽게 생깁니다.

10. 참고 자료

Shadertoy 공식 사이트: 브라우저에서 바로 실습 가능한 GLSL 셰이더 샌드박스.
https://www.shadertoy.com
The Book of Shaders: 셰이더의 기초 개념부터 고급 기법까지 시각적으로 설명하는 온라인 교재.
https://thebookofshaders.com
Inigo Quilez 블로그: Shadertoy 창시자의 SDF, 레이마칭, 절차적 텍스처 관련 기술 글 모음.
https://iquilezles.org/articles/

[Project] NPR Shaders — GLSL로 구현한 비사실적 렌더링 셰이더 컬렉션

lalunru — Fri, 8 May 2026 19:58:20 +0900

Overview

Period

2026.03 – 진행 중

Type

개인 프로젝트

Role

Technical Artist / 셰이더 개발

Platform

Shadertoy (GLSL) · Unity URP / Built-in

Background

현대 그래픽스 엔진에서 실사 렌더링은 이미 보편화되었으나, 개발자가 빛의 해석 방식을 직접 제어하여 고유한 예술적 스타일을 구축하는 NPR(Non-Photorealistic Rendering) 영역은 여전히 높은 기술적 이해를 요구합니다.

스타일라이즈드 게임 및 애니메이션 렌더링에 필수적인 톤·아웃라인·색상 체계의 직접적인 제어권을 확보하기 위해 본 프로젝트를 시작했습니다.

Shaders

01 실시간 크로스해칭(Cross-Hatching) 시스템 Shadertoy →

Concept

표면 휘도(Luminance)에 따라 펜 드로잉 레이어를 가변적으로 누적하여 수작업 펜화 느낌을 실시간으로 재현하는 셰이더입니다. Praun et al.의 논문을 분석하고 텍스처 없이 순수 GLSL 코드로 재구성했습니다.

Impl

0도~135도까지 45도 간격의 4개 해칭 레이어를 블렌딩하는 알고리즘을 설계했습니다. 단순 수식으로 계산된 직선은 3D 모델 위에서 지나치게 정교하게 배치되어 이질감이 생기는 문제가 있었습니다. 이를 해결하기 위해 해칭 선이 진행되는 방향을 따라 Value Noise를 중첩시켜 선의 굵기와 굴곡에 무작위성을 부여했으며, smoothstep과 fwidth 함수를 조합하여 해상도 변화에도 선이 깨지지 않는 안티앨리어싱 처리를 수행했습니다.

Result

수치적으로 계산된 패턴이 아닌, 아티스트가 실제 펜으로 덧칠한 듯한 자연스러운 농도 표현과 유기적인 질감을 확보했습니다.

02 고급 툰 셰이딩(Toon Shading) + 림 라이트 Shadertoy →

Concept

단순 명암 단계화를 넘어 실제 셀 애니메이션의 채색 기법을 셰이더로 구현했습니다. 빛의 방향과 표면 법선 벡터를 기반으로 색조를 물리적으로 제어합니다.

Impl

Hue-Shift 기법을 적용하여 그림자 영역은 차갑게(Cool), 하이라이트 영역은 따뜻하게(Warm) 색조를 이동시켜 셀 애니메이션의 채색 방식을 재현했습니다. Fresnel 기반의 림 라이트를 구현하고 빛의 방향에 따른 가시성 제어 로직을 최적화했습니다. 아웃라인은 스크린 스페이스 노멀 불연속성 감지 방식으로 처리하여 지오메트리를 복제하지 않고도 외곽선을 렌더링했습니다.

Result

추가 지오메트리 없이 셀 애니메이션 특유의 아웃라인과 색조 분리가 실시간으로 구현되었습니다.

03 Null Cathedral — 프랙탈 레이마칭 Shadertoy →

Concept

반복적으로 붕괴하는 재귀적 메가구조물을 심우주 중계기 시점으로 포착한 실시간 레이마칭 셰이더입니다. 관측 가능한 공간 너머를 유영하는 구조물의 허구적 기록물 — 수학적 프랙탈 구조를 서사적 미장센으로 치환하는 실험입니다.

Impl

IFS(Iterated Function System) 기반 프랙탈 변환(formula)을 4회 반복하여 Distance Estimator를 구성하고, 160-step 레이마칭으로 렌더링했습니다. Hue-Shift와 무지갯빛 쉰(iridescence) 레이어를 조합한 색채 시스템, Fresnel 기반 글로우, 5-step 소프트 섀도우, 스크린 스페이스 엣지 검출 아웃라인을 구현했습니다. 포스트 프로세싱으로 ACES 톤매핑, 크로마틱 어버레이션, 글리치 라인 노이즈, 필름 그레인, 비네팅을 적용하여 손상된 전송 신호 느낌을 연출했습니다.

Result

기술적 정밀도와 예술적 연출이 공존하는 실시간 렌더링을 구현했습니다. 순수 수학 함수만으로 건축적 구조물의 질감과 서사적 분위기를 연출했습니다.

Troubleshooting

해칭 패턴의 기계적 정교함으로 인한 이질감 제거

Problem

수식으로 계산된 직선 패턴을 적용했을 때, 3D 모델 위에서 선들이 너무 정교하게 배치되어 Hand-drawn feel이 결여되는 문제가 발생했습니다.

Solve

해칭 선이 진행되는 방향을 따라 미세한 Value Noise를 중첩하여 선의 굵기와 굴곡에 무작위성을 부여했습니다. smoothstep과 fwidth 함수를 조합해 해상도 변화에도 선이 깨지지 않는 안티앨리어싱 처리를 추가했습니다.

Result

아티스트가 실제 펜으로 덧칠한 듯한 자연스러운 농도 표현과 유기적인 질감을 확보했습니다.

Demo

01 · Cross-Hatching Shader

02 · Toon Shading + Rim Light

03 · Null Cathedral — Fractal Raymarching

Links

GitHub Shadertoy

Retrospective

수학 → 시각

수학적 모델을 시각적인 결과물로 치환하는 과정을 통해 Technical Artist로서 필요한 구현 역량을 쌓았습니다. Praun et al. 논문을 분석하고 텍스처 없이 순수 GLSL로 재구성하면서, 렌더링 파이프라인에서 중요한 것은 물리적 시뮬레이션보다 '빛을 어떻게 예술적으로 왜곡할 것인가'에 대한 통제력임을 깨달았습니다.

다음 목표

Unity URP의 렌더 피처를 활용하여 더욱 복잡한 포스트 프로세싱 효과로 확장해볼 계획입니다. Shadertoy(GLSL)에서 Unity(HLSL)로 이식하는 파이프라인을 완성하고 아티스트가 파라미터를 실시간으로 조정할 수 있는 구조로 발전시키고자 합니다.

[Project] AssetMind — 금융자산관리 웹 서비스 UI/UX 개발 및 실시간 데이터 처리

lalunru — Fri, 8 May 2026 19:45:30 +0900

Overview

Period

2026.01 – 2026.06 (진행 중)

Team

4인 팀 프로젝트 (UI · UX · 백엔드 · 데이터)

Platform

Web — PC / Tablet / Mobile

Infra

서버 2대 운영 (동적 서버 + 정적 서버)

Role

초기

UI 개발 전담

FFigma에서 직접 컬러 팔레트, 타이포그래피, 컴포넌트 시안을 구성하고 이를 토대로 Tailwind CSS 컴포넌트를 구현하였습니다. 또한, Storybook으로 독립적인 문서화 환경을 구축했습니다.

컴포넌트 설계 디자인 시스템 Storybook

현재

UI/UX 전담 — 디자인부터 API 연동까지

UX팀원 이탈 후 역할을 인수하여, Figma 시안 구현·컬러 팔레트 구성 등 디자인 시스템 전체를 담당하는 동시에, UI 모듈을 조립해 실제 페이지를 구성하고 API 연동까지 직접 처리하고 있습니다. 현재는 성능·안정성 측면의 UX 품질 개선 작업도 함께 진행 중입니다.

Figma 시안 구현 컬러 팔레트 구성 페이지 조립 API 연동 UX 안정성·속도 개선 리팩터링

Background

토스증권 등 기존 금융 서비스를 레퍼런스로 삼아, 복잡한 주식 및 자산 데이터를 직관적으로 시각화하는 서비스를 기획했습니다.

PC, 태블릿, 모바일 등 다양한 해상도에서 일관된 사용자 경험을 제공하는 반응형 크로스 플랫폼을 구축하는 것을 목표로 개발을 진행했습니다.

Contributions

01 디자인 시스템 구축 — Figma → Tailwind → Storybook

Impl

Figma에서 직접 컬러 팔레트, 타이포그래피, 컴포넌트 시안을 구성하고 이를 Tailwind CSS로 구현했습니다. Tailwind Config와 Storybook 간 자동 매핑 시스템을 개발하여 색상·타이포그래피 토큰을 시각적으로 동기화하고, Storybook으로 컴포넌트를 독립 문서화하여 팀 내 재사용성과 커뮤니케이션 효율을 높였습니다. Vercel을 활용한 Storybook 자동 배포 파이프라인을 구축하여 PR마다 프리뷰 배포 환경을 제공했습니다.

02 반응형 데이터 시각화 및 차트 구현

Impl

Desktop / Tablet / Mobile 3개 뷰포트별 레이아웃을 구현하고, TradingView 외부 차트 위젯을 React 환경에 맞게 캡슐화했습니다. lightweight-charts 기반 캔들스틱 차트를 구현하여 1분/5분/일/주/월 기간 탭 전환 시 API params를 분기 처리했습니다. 실시간(Realtime), 시장 휴장(Market-closed), 로딩(Skeleton) 등 pageState를 정의하여 서비스 상태별 렌더링 케이스를 체계화했습니다.

03 실서비스 API 연동 및 실시간 데이터 처리

Impl

UX 인수 후 Storybook 디자인 시스템 기반 UI 모듈을 조립하여 실제 페이지를 구성하고, 백엔드 API 연동까지 직접 처리했습니다. SockJS를 제거하고 순수 WebSocket + STOMP(@stomp/stompjs)로 전환하여 MSW mock 환경과의 호환성 문제를 해결했습니다. Zustand store에 mapVersion 카운터를 도입하여 Map 객체의 참조 비교 한계를 우회, 실시간 랭킹 갱신 시 리렌더를 안정적으로 트리거하는 구조를 설계했습니다. React Query + WebSocket 이중 구독 구조로 호가창 초기 데이터(REST)와 실시간 업데이트(WebSocket)를 분리 처리하는 useOrderbook 훅을 설계했습니다. 현재는 렌더링 최적화와 안정성 측면의 UX 개선 작업을 진행 중입니다.

04 MSW 기반 Mock 환경 구축

Impl

MSW(Mock Service Worker)로 REST API 및 WebSocket 전 구간을 mock하여 백엔드 없이 독립적인 프론트엔드 개발 환경을 구축했습니다. 실제 백엔드 API 스펙(timestamp, string 타입 필드 등)을 분석하여 mock 응답 구조를 실서버와 동일하게 맞추고, 급등락 알림·랭킹 실시간 업데이트·개별 종목 체결 데이터 등 다양한 WebSocket 토픽을 mock하여 실제와 유사한 시나리오를 시뮬레이션했습니다.

05 예외 상태 처리 고도화 및 극단값 레이아웃 보호

Impl

ErrorBoundary 컴포넌트를 구현하여 페이지·섹션 단위로 에러를 격리하고 "다시 시도" Fallback UI를 제공했습니다. 로딩(Skeleton), 에러(Error), 빈 데이터(Empty) 세 가지 예외 상태를 각 컴포넌트에 명시적으로 정의했습니다. 99:1과 같은 극단적인 매수/매도 비율 데이터 유입 시에도 게이지 막대가 최소 너비(4px)를 유지하도록 방어 로직을 적용하고, 모바일 뷰에서 호가창을 10호가→5호가 요약형으로 축소하여 가독성을 확보했습니다.

Troubleshooting

01 SockJS → 순수 WebSocket 전환으로 MSW 호환성 해결

Problem

SockJS를 사용한 STOMP 연결에서 MSW가 XHR polling 폴백을 처리하지 못해 STOMP Connected 이벤트가 발생하지 않았습니다. Vite 프록시가 MSW보다 먼저 /ws-stock 요청을 가로채는 것도 원인 중 하나였습니다.

Solve

SockJS를 완전히 제거하고 brokerURL로 순수 WebSocket을 직접 연결하는 방식으로 전환했습니다. Vite 프록시에서 /ws-stock 항목을 제거하여 MSW가 WebSocket 요청을 정상 처리하도록 했습니다.

Result

STOMP Connected → SUBSCRIBE → 실시간 MESSAGE 수신까지 전 구간이 정상 동작하게 되었습니다.

02 Map 참조 비교 한계 우회 — mapVersion 카운터 설계

Problem

Zustand store에서 stockMap(Map 객체)을 React 상태로 구독할 때, Worker에서 새 Map 인스턴스로 교체해도 React의 Object.is 비교가 내용 변경을 감지하지 못해 실시간 갱신 시 UI가 업데이트되지 않았습니다.

Solve

store에 mapVersion: number 카운터를 추가하여 매 업데이트마다 1씩 증가시키고, 컴포넌트에서 mapVersion을 구독해 useMemo 재실행을 트리거하는 구조를 설계했습니다.

Result

실시간 주가 데이터가 초당 1회 갱신되며 현재가·등락률·순위 변동이 UI에 즉시 반영됩니다.

03 Web Worker window is not defined — Vite 빌드 이슈 분석

Problem

Web Worker에서 주가 데이터 정렬을 처리하던 중 window is not defined 에러가 발생하여 Worker가 응답을 보내지 못했습니다.

Solve

Vite가 Worker 번들링 시 env.mjs를 자동 주입하는데, Worker 환경에는 window 객체가 없어 크래시가 발생함을 확인했습니다. 80종 데이터에는 성능 차이가 미미함을 PM과 협의 후, Web Worker를 제거하고 메인 스레드에서 직접 정렬을 처리하는 방식으로 전환했습니다.

Result

Worker 의존성 제거 후 실시간 갱신이 정상 동작하게 되었습니다.

Links

GitHub Storybook

Retrospective

구조적 설계의 중요성

컴포넌트 단위로 UI를 설계하고 Storybook과 연동하는 과정에서, 단순한 화면 구현을 넘어 상태와 뷰포트 변화에 유연하게 대응하는 구조적 설계의 중요성을 배웠습니다.

브라우저·번들러 깊이

SockJS 호환성 문제, Vite 빌드 환경의 Worker 이슈, Map 참조 비교 한계 등 예상치 못한 문제들을 디버깅하며 브라우저와 번들러의 동작 방식에 대한 깊은 이해를 쌓을 수 있었습니다.

유연한 협업과 오너십

UX팀원 이탈이라는 예상치 못한 상황에서 역할을 인수하여, Figma 시안 구현과 컬러 팔레트 구성 등 디자인 시스템 전체를 담당하면서 동시에 UI 모듈로 페이지를 구성하고 API 연동까지 처리하는 작업을 주도했습니다. 현재는 안정성·속도 측면의 UX 개선 작업까지 함께 진행하며, 폭넓은 프론트엔드 역할을 경험하고 있습니다.

[Unity VR] 성능 한계를 공포 연출로 커버한 라이트맵 최적화 경험

lalunru — Fri, 8 May 2026 18:38:21 +0900

1. 들어가며

VR 개발에서 프레임레이트는 단순한 성능 지표가 아닙니다. Meta Quest 2의 권장 프레임레이트는 72fps인데, 이를 밑돌면 화면 끊김이 신체적인 불쾌감, 즉 멀미로 직결됩니다.

이 글은 나폴리탄 괴담 장르를 기반으로 제작한 Meta Quest 2용 1인칭 VR 공포 어드벤처 게임 Line 0를 개발하던 중 마주친 프레임 저하 문제를 해결한 과정을 공유합니다. 단순히 성능을 끌어올리는 것에서 그치지 않고, 최적화 과정에서 생긴 한계를 공포 게임의 연출로 커버한 경험이기도 합니다.

2. 문제 상황: 30fps, 멀미가 나는 게임

초기 빌드를 플레이테스트했을 때 프레임레이트가 30fps 언저리에 머물렀습니다. 일반 게임이라면 "조금 버벅이는 수준"으로 넘길 수 있지만, VR에서는 달랐습니다. 헤드셋을 쓴 플레이테스터들이 실제로 멀미를 호소했습니다.

Unity Profiler로 병목을 분석한 결과, 원인은 명확했습니다.

씬 전체에 배치된 실시간 조명의 연산 비용이 매 프레임마다 발생하고 있었습니다.
VR은 좌우 눈 각각에 대해 렌더링을 수행하기 때문에, 일반 3D 게임 대비 GPU 부하가 약 2배에 달합니다.
실시간 조명과 VR의 이중 렌더링이 맞물리면서 프레임이 목표치의 절반도 채 되지 않았습니다.

3. 해결 방안 모색

가장 먼저 든 생각은 "조명의 수를 줄이거나 품질을 낮추자"였습니다. 하지만 공포 게임 특성상 조명은 분위기를 결정하는 핵심 요소였고, 단순히 줄이는 것은 게임의 완성도를 떨어뜨리는 선택이었습니다.

결국 방향을 완전히 바꿨습니다. 실시간 연산 자체를 없애고, 조명 결과를 텍스처에 미리 구워버리는 베이크 방식으로 전환하기로 했습니다.

핵심 아이디어는 이것이었습니다. "조명을 실시간으로 계산하는 대신, 미리 계산해서 텍스처에 저장해두자."

4. 라이트맵 베이크 전환 적용

Unity의 Lighting 설정에서 씬의 모든 조명을 100% 베이크 방식으로 전환하고, 라이트맵을 생성했습니다.

Mixed Lighting → Baked Indirect 에서
Baked GI → 100% Baked 로 전환

추가로 텍스처 해상도도 낮춰 GPU 메모리 부담을 줄였습니다.

결과는 기대 이상이었습니다.

항목	전환 전	전환 후
프레임레이트	~30fps	~72fps
실시간 조명 연산	매 프레임 발생	없음
멀미 호소	있음	없음

5. 새로운 문제: 실시간 그림자가 사라졌다!

성능 문제는 해결됐지만 새로운 문제가 생겼습니다. 베이크된 라이트맵은 조명 결과를 텍스처에 고정시키기 때문에, 오브젝트의 움직임에 반응하는 실시간 그림자 연산이 불가능해집니다. 플레이어나 NPC가 움직여도 그림자가 따라오지 않았습니다.

일반적인 게임이라면 치명적인 단점이었겠지만, 저는 여기서 개발 중인 게임의 장르에 주목했습니다.

이건 공포 게임이다.

공포 게임은 원래 플레이어의 시야를 의도적으로 방해합니다. 어두운 환경, 짙은 안개, 제한된 시야각은 공포 연출의 기본 문법입니다. 그림자가 어색해도, 어두우면 보이지 않습니다.

6. 한계를 연출로 커버하기

실시간 그림자 부재를 숨기기 위해 다음과 같은 연출을 적용했습니다.

베이크된 라이트맵의 전체 명도를 낮춰 씬을 전반적으로 어둡게 처리했습니다.
지하철 역사 특유의 형광등 깜빡임 효과를 추가해 조명이 불안정한 환경임을 자연스럽게 연출했습니다.
안개를 적극적으로 활용해 먼 거리의 그림자 부재가 눈에 띄지 않도록 했습니다.

결과적으로 플레이테스터들은 그림자 부재를 인식하지 못했고, 오히려 어두운 환경이 공포감을 높이는 데 기여했다는 피드백을 받았습니다.

7. 마무리 및 회고

이 경험에서 얻은 가장 큰 교훈은 "기술적 한계가 때로는 연출의 조건이 될 수 있다" 는 점입니다.

실시간 그림자를 포기한 것은 처음엔 명백한 결함처럼 느껴졌습니다. 하지만 장르의 특성을 이해하고 있었기에, 그 한계를 오히려 공포 연출의 도구로 전환할 수 있었습니다. 단순히 문제를 해결하는 것을 넘어, 제약 조건 안에서 최선의 결과를 만들어내는 것이 개발의 본질이라는 것을 다시 한번 느꼈습니다.

프로젝트 전체 코드는 아래 GitHub 레포지토리에서 확인하실 수 있습니다.

GitHub - unity-vr-game-project

8. 참고 자료

Unity 공식 문서 - Lightmapping: 라이트맵 베이크의 기본 개념과 Unity에서의 설정 방법.
https://docs.unity3d.com/Manual/Lightmappers.html
Unity 공식 문서 - VR Performance Optimization: Meta Quest 환경에서의 VR 성능 최적화 가이드.
https://docs.unity3d.com/Manual/xr-performance-optimization.html
Meta Quest Developer Docs - Performance Guidelines: Quest 2의 권장 프레임레이트 및 GPU 최적화 기준.
https://developer.oculus.com/documentation/unity/unity-perf/

[React] 제네릭을 활용한 재사용 가능한 데이터 카드 컴포넌트 설계

lalunru — Fri, 8 May 2026 18:37:15 +0900

1. 들어가며

프론트엔드 개발을 진행하다 보면 디자인 형태는 완전히 동일하지만, 주입되는 데이터의 구조가 달라 매번 새로운 컴포넌트를 생성해야 하는 상황을 마주하게 됩니다.

특히 금융 도메인이나 대시보드 형태의 서비스를 개발할 때 이러한 문제가 자주 발생합니다. 주식, 현금, 부동산 등 각 자산군마다 백엔드에서 내려주는 API 응답 형태가 다르기 때문입니다. 이 글에서는 이러한 상황에서 TypeScript의 제네릭을 활용하여 컴포넌트를 유연하게 추상화하고 중복 코드를 제거한 과정을 공유합니다.

2. 문제 상황: 늘어나는 보일러플레이트와 중복 코드

초기에는 직관적인 구현을 위해 데이터 타입별로 컴포넌트를 분리했습니다. 백엔드에서 전달받는 주식과 현금 데이터의 타입은 다음과 같이 서로 다른 필드명을 가지고 있었습니다.

interface StockInfo {
  stockName: string;
  currentPrice: number;
}

interface CashInfo {
  accountName: string;
  balance: number;
}

이러한 타입 차이 때문에 각 데이터에 맞는 컴포넌트를 일일이 만들어야 했습니다.

// ❌ Bad: 데이터 타입마다 컴포넌트를 따로 생성하는 방식
function StockCard({ stockData }: { stockData: StockInfo }) {
  return (
    <div className="card">
      <h3>{stockData.stockName}</h3>
      <p>{stockData.currentPrice}</p>
    </div>
  );
}

function CashCard({ cashData }: { cashData: CashInfo }) {
  return (
    <div className="card">
      <h3>{cashData.accountName}</h3>
      <p>{cashData.balance}</p>
    </div>
  );
}

이 방식은 치명적인 단점이 존재했습니다.

UI 디자인(예: .card의 여백이나 색상)이 변경될 경우 모든 Card 컴포넌트를 찾아가 수정해야 합니다.
새로운 자산 타입이 추가될 때마다 거의 동일한 형태의 컴포넌트를 새로 작성해야 합니다.

3. 해결 방안 모색: 제어 역전(IoC)과 뷰(View) 계층의 분리

문제의 원인은 UI를 렌더링하는 로직과 데이터의 구조에 의존하는 로직이 강하게 결합되어 있다는 점이었습니다.

이를 해결하기 위해 컴포넌트는 '어떤 형태의 데이터'가 들어오는지 몰라도 되도록, 데이터 추출 로직을 외부로 위임하는 방식을 채택했습니다. 즉, 컴포넌트가 직접 데이터를 해석하는 대신 외부에서 로직을 주입받는 방식인 제어 역전 개념을 도입했습니다. 이를 통해 컴포넌트는 오직 화면을 그리는 역할에만 집중하도록 설계했습니다.

4. 제네릭을 활용한 컴포넌트 추상화 적용

TypeScript의 제네릭을 사용하여, 앞서 언급한 제어 역전 패턴을 적용했습니다. 어떤 데이터 타입(T)이 들어오든 대응할 수 있는 DataCard 컴포넌트를 구현하고, 객체에서 필요한 값을 뽑아내는 함수를 Props로 주입받도록 설계했습니다.

import React from 'react';

// 공통으로 사용될 Card 컴포넌트의 Props 정의
interface DataCardProps<T> {
  data: T;
  extractTitle: (item: T) => string;
  extractAmount: (item: T) => number;
}

export function DataCard<T>({ data, extractTitle, extractAmount }: DataCardProps<T>) {
  return (
    <div className="rounded-xl border p-6 shadow-sm">
      <h3 className="text-lg font-semibold text-gray-800">
        {extractTitle(data)}
      </h3>
      <p className="mt-4 text-2xl font-bold text-gray-900">
        {extractAmount(data).toLocaleString()}원
      </p>
    </div>
  );
}

이제 이 컴포넌트를 사용할 때는 아래와 같이 사용할 데이터와 그 데이터에 맞는 추출 로직만 전달하면 됩니다.

// ✅ Good: 하나의 컴포넌트로 다양한 데이터 타입 대응
function Dashboard() {
  const stock: StockInfo = { stockName: '애플', currentPrice: 150000 };
  const cash: CashInfo = { accountName: '월급통장', balance: 3000000 };

  return (
    <>
      <DataCard
        data={stock}
        extractTitle={(s) => s.stockName}
        extractAmount={(s) => s.currentPrice}
      />
      <DataCard
        data={cash}
        extractTitle={(c) => c.accountName}
        extractAmount={(c) => c.balance}
      />
    </>
  );
}

5. 마무리 및 회고

제네릭과 제어 역전을 활용하여 컴포넌트를 설계한 결과, UI 코드의 중복을 획기적으로 줄일 수 있었습니다.

디자인 시스템이 변경되더라도 DataCard 컴포넌트 하나만 수정하면 전체 서비스에 반영되므로 유지보수성이 크게 향상되었습니다. 단순히 동작하는 코드를 넘어, 변경에 유연하게 대처할 수 있는 아키텍처를 고민하는 것의 중요성을 깨달을 수 있었습니다.

6. 참고 자료

TypeScript Handbook - Generics: 다양한 타입에 재사용 가능한 컴포넌트를 생성하는 제네릭의 기본 개념과 활용법.
https://www.typescriptlang.org/docs/handbook/2/generics.html
React 공식 문서 - Passing Props to a Component: 리액트 컴포넌트 간 데이터를 안전하고 효율적으로 전달하는 방법.
https://react.dev/learn/passing-props-to-a-component
Kent C. Dodds - Inversion of Control: 프론트엔드 컴포넌트 설계 시 제어권을 외부로 위임하여 재사용성을 극대화하는 IoC 패턴에 대한 심도 있는 고찰.
https://kentcdodds.com/blog/inversion-of-control

[Project] LSTM 기반 악성 URL 탐지 모델 — LSTM과 피처 엔지니어링의 결합

lalunru — Fri, 8 May 2026 18:33:57 +0900

Overview

Period

2025.05 – 2025.06

Type

개인 프로젝트

Role

AI 모델 설계 · 데이터 전처리 및 분석

Dataset

Kaggle Malicious URLs Dataset (651,195개)

Background

새로운 유형의 악성 URL이 급증하면서 기존의 규칙 기반 탐지 방식의 한계가 명확해졌습니다. 공격 패턴의 변화를 유연하게 식별하기 위해서는 학습 기반 모델의 도입이 필수적이었습니다.

단순한 텍스트 구조만으로는 정상 사이트를 교묘하게 모방한 URL을 분류하기 어렵기 때문에, URL의 문맥을 파악하는 LSTM 신경망과 보안 도메인 지식이 반영된 수작업 특성(Handcrafted Features)을 결합한 멀티 인풋 신경망 기반 탐지 모델을 설계했습니다.

Model Architecture

Branch 1 — URL Sequence

URL Text Sequence

문자 단위 토큰화 · pad_sequences(100)

Embedding Layer

vocab=10,000 · dim=64

LSTM (64 units)

문자 순서 · 패턴 · 맥락 학습

→ 64-dim output

Branch 2 — Handcrafted Features

9가지 보안 특성

엔트로피 · URL 길이 · IP 여부 등

Dense (32, ReLU)

→ 32-dim output

Concatenate (96-dim)

64 + 32 = 96

Dense (64, ReLU)

Dropout (0.5)

Output · Dense (4, Softmax)

Benign / Phishing / Malware / Defacement

Performance

클래스	Precision	Recall	F1-Score	Support
Benign	0.87	0.94	0.90	6,018
Defacement ★	1.00	0.99	0.99	6,055
Malware	0.97	0.87	0.92	4,733
Phishing	0.86	0.87	0.86	5,923
전체 정확도	92% (Accuracy 0.92 · F1-macro 0.92)			22,729

Contributions

01 멀티 인풋 딥러닝 아키텍처 설계

Problem

URL 문자열 시퀀스만으로 학습시켰을 때, 정상 사이트를 교묘하게 모방한 피싱 URL의 분류 성능에 한계가 있었습니다. LSTM 단독 구조로는 탐지하기 어려운 이상 징후가 존재했습니다.

Impl

Branch 1 (LSTM): URL 문자를 정수로 변환 후 pad_sequences(maxlen=100)로 고정 길이 패딩. Embedding(vocab=10000, dim=64) → LSTM(64)로 문자 순서·패턴·맥락을 학습.

Branch 2 (Handcrafted): URLFeatureAnalyzer 클래스를 구현해 엔트로피, URL 길이, 숫자 수, 파라미터 수, IP 주소 여부, @·%20 포함 여부 등 9가지 보안 도메인 특성을 추출. Dense(32, ReLU)로 처리.

두 분기의 출력을 Concatenate로 병합한 뒤 Dense(64) → Dropout(0.5) → Dense(4, Softmax) 구조로 4클래스 분류.

Result

LSTM 단독 구조 대비 피싱 클래스 탐지 성능이 향상. 전체 정확도 92% 달성. 특히 URL 패턴이 뚜렷한 Defacement 클래스에서 F1-Score 0.99를 기록.

02 대규모 데이터셋 전처리 및 클래스 균형 조정

Problem

총 651,195개 샘플 중 Malware 클래스(32,520개)가 Benign(428,103개)에 비해 현저히 적어 클래스 불균형 문제가 발생했습니다. 불균형 상태로 학습 시 다수 클래스에 편향된 모델이 생성될 위험이 있었습니다.

Impl

결측치·중복 제거 후 라벨별로 데이터를 분리하고, Malware를 제외한 나머지 3개 클래스(Benign, Defacement, Phishing)에서 각 30,000개를 sample(random_state=101)로 샘플링했습니다. Malware는 전체(23,645개)를 사용해 최종 113,645개의 균형 잡힌 데이터셋을 구성했습니다.

Result

클래스 편향 없이 균형 잡힌 학습 데이터를 확보하여, 소수 클래스인 Malware도 F1-Score 0.92로 안정적인 탐지 성능을 달성했습니다.

Troubleshooting

피싱 URL 분류 성능 개선 — 시퀀스 모델의 한계를 피처 엔지니어링으로 보완

Problem

LSTM만으로 학습했을 때, 피싱 사이트가 정상 URL과 외형적으로 유사하게 설계되기 때문에 문자 시퀀스 패턴만으로는 충분한 판별 근거가 부족했습니다.

Solve

피처 엔지니어링을 도입해 보안 전문가의 시각으로 이상 징후를 수치화했습니다. URL 엔트로피(난독화된 문자열 탐지), IP 직접 입력 여부(DNS 필터링 우회 탐지), @ 기호 수, %20 인코딩 수 등 9가지 지표를 URLFeatureAnalyzer 클래스로 추출하여 LSTM 출력과 병렬로 병합했습니다.

Result

두 입력 방식이 상호 보완적으로 작용하여 피싱 클래스의 탐지 성능이 향상되었으며, 전체 정확도 및 F1-Score 모두 92%를 달성했습니다.

Links

GitHub

Retrospective

핵심 경험

딥러닝 모델 설계 시 데이터의 성격에 따라 단일 모델보다 멀티 인풋 구조가 더 견고하고 높은 성능을 낼 수 있음을 배웠습니다. LSTM을 보안 영역에 적용하며 모델의 추론 능력에만 의존하지 않고 도메인 지식을 피처로 개입시켰을 때 생기는 시너지를 경험했습니다.

공격자 시각의 중요성

오답률이 높았던 피싱 클래스를 분석하며, 방어 모델을 개선하기 위해서는 공격자의 우회 의도를 논리적으로 파악하는 관점이 필수적임을 깨달았습니다. 이는 단순 성능 지표 개선을 넘어 도메인 이해의 중요성을 일깨워 준 경험이었습니다.

[Project] 설명 가능한 인공지능(XAI)을 활용한 네트워크 침입 탐지 시스템의 개발 — 블랙박스 모델의 판단 근거를 설명하다

lalunru — Fri, 8 May 2026 18:22:52 +0900

Overview

Period

2025.03 – 2025.11

Type

개인 프로젝트 (졸업논문)

Role

AI 모델 설계 · XAI 파이프라인 구축 전담

Dataset

UNSW-NB15 (82,332 / 175,341 샘플)

Background

기존 머신러닝 기반 침입 탐지 시스템(IDS)은 높은 성능에도 불구하고 판단 근거를 알 수 없는 블랙박스(Black-box) 구조로 인해 보안 현장에서의 신뢰성이 낮다는 한계가 있었습니다.

단순 탐지를 넘어 '왜 해당 트래픽이 공격으로 판단되었는가'에 대한 객관적 근거를 제시할 수 있는 XAI(Explainable AI) 기술을 통합하여, 보안 전문가의 대응 정책 수립을 지원하는 차세대 IDS 프로토타입 개발을 목표로 연구를 진행했습니다.

Model Performance

모델	정확도	정밀도	재현율	F1-Score	ROC-AUC
의사결정트리	0.86	0.85	0.84	0.84	0.87
MLP	0.90	0.91	0.89	0.90	0.92
XGBoost ★	0.97	0.96	0.95	0.95	0.97

Contributions

01 하이브리드 탐지 모델 설계 및 성능 최적화

Problem

단일 모델로는 탐지 성능과 해석 가능성을 동시에 확보하기 어려웠습니다. 화이트박스 모델은 해석은 쉽지만 성능이 낮고, 블랙박스 모델은 성능은 높지만 판단 근거를 설명할 수 없는 상충 관계가 존재했습니다.

Impl

의사결정트리(화이트박스), MLP, XGBoost(블랙박스) 세 모델을 동일한 파이프라인에서 비교 실험했습니다. StratifiedKFold 5겹 교차 검증으로 클래스 불균형 문제를 완화하고, XGBoost는 n_estimators=300, early_stopping_rounds=20으로 과적합을 방지했습니다. 의사결정트리를 해석의 기준선(baseline)으로 설정하여 블랙박스 모델의 XAI 결과를 검증하는 3계층 비교 구조를 설계했습니다.

Result

XGBoost 모델이 F1-Score 0.95, ROC-AUC 0.97로 가장 우수한 탐지 성능을 달성했으며, 의사결정트리 대비 성능 격차를 정량적으로 검증했습니다.

02 블랙박스 해소를 위한 XAI 파이프라인 통합

Problem

XGBoost와 MLP는 높은 탐지 성능을 보이지만 내부 연산 구조가 복잡해 판단 근거를 사람이 이해할 수 없었습니다. 보안 전문가가 탐지 결과를 신뢰하고 대응 정책을 수립하기 위해서는 '왜 공격으로 판단했는지'에 대한 설명이 필요했습니다.

Impl

MLP 모델에 LIME(LimeTabularExplainer)을 적용해 개별 샘플 단위의 지역적 예측 근거를 시각화했습니다. XGBoost 모델에는 SHAP(TreeExplainer)을 적용해 전역적 특성 중요도(Summary Plot), 특성 간 상호작용(Dependence Plot), 단일 예측 기여도(Force Plot), 누적 의사결정 경로(Decision Plot) 등 4가지 시각화를 구현했습니다.

Result

LIME 분석에서 MLP가 sttl, ct_dst_sport_ltm, sbytes를 주요 판단 기준으로 사용함을 확인했습니다. SHAP 분석에서는 XGBoost가 ct_dst_sport_ltm과 dwin의 비선형 상호작용을 학습하고 있음을 발견했습니다. 두 기법의 핵심 특성이 의사결정트리의 상위 노드와 부분적으로 일치하여 블랙박스 모델의 예측이 임의 잡음이 아닌 일관된 특성에 기반함을 검증했습니다.

03 데이터 전처리 파이프라인 설계

Problem

UNSW-NB15 대규모 데이터셋 정제 과정에서 범주형 특성 인코딩 불일치와 결측치 처리 순서 오류로 인한 데이터 유실, 그리고 학습 데이터 정보가 테스트 데이터로 유입되는 데이터 누수(Data Leakage) 문제가 발생했습니다.

Impl

StandardScaler와 OneHotEncoder의 fit()을 학습 데이터에만 적용하고, 테스트 데이터에는 transform()만 적용하도록 전처리 구조를 재설계했습니다. ColumnTransformer로 수치형 표준화와 범주형 인코딩을 단일 파이프라인으로 통합하여 일관된 변환 기준을 확립했습니다.

Result

데이터 무결성을 보장하는 전처리 파이프라인을 완성하여 모델 평가의 신뢰도를 확보했습니다.

Troubleshooting

데이터 누수(Data Leakage) 방지를 위한 전처리 파이프라인 재설계

Problem

초기 구현에서 전체 데이터셋에 StandardScaler를 먼저 fit한 뒤 분할하는 방식을 사용했습니다. 이 경우 테스트 데이터의 통계 정보(평균, 표준편차)가 스케일러 학습에 반영되어 모델 평가가 과도하게 낙관적으로 측정되는 데이터 누수 문제가 발생했습니다.

Solve

학습/테스트 데이터 분리를 전처리보다 먼저 수행하도록 순서를 재정립했습니다. col_trans.fit(X_train)으로 학습 데이터에서만 변환 기준을 학습하고, col_trans.transform(X_test)으로 동일 기준을 테스트 데이터에만 적용하도록 구조를 체계화했습니다.

Result

데이터 무결성이 보장된 전처리 파이프라인을 완성하여 실무 수준의 신뢰도 있는 모델 평가 결과를 도출했습니다.

XAI Analysis

LIME — MLP 지역적 해석

테스트 샘플 단위 예측 근거 분석. sttl <= -1.17 조건이 정상 판정의 핵심 근거로 작용했으며, ct_dst_sport_ltm, sbytes가 보조 근거로 기여함을 시각화했습니다. 의사결정트리 상위 노드와 일관성 확인.

SHAP — XGBoost 전역적 해석

전역 특성 중요도 1위는 ct_dst_sport_ltm. 의사결정트리(1위: sttl)와 차이 발생 — 앙상블 모델이 단일 트리가 포착 못하는 비선형 상호작용을 반영하기 때문으로 분석.

SHAP Dependence Plot

sttl과 dwin 간 상호작용 분석. sttl 값이 동일해도 dwin 값에 따라 공격 판단 강도가 달라지는 비선형 패턴을 발견. 단일 특성이 아닌 특성 조합 기반의 복합 탐지 전략을 확인.

SHAP Decision Plot

다수 샘플의 누적 의사결정 경로 시각화. ct_dst_sport_ltm 부근에서 공격/정상 샘플이 뚜렷하게 분리됨. 완만하게 누적되는 혼동 구간(오탐/미탐 가능성)도 식별.

Links

GitHub

Retrospective

핵심 경험

AI 모델의 성능 못지않게 '해석 가능성'이 실무에서 얼마나 중요한지 깨달았습니다. 특히 보안 도메인 지식(패킷 지속 시간, TTL, 세션 특성 등)을 모델의 특성으로 녹여내는 과정이 분석의 품질을 결정한다는 점을 배웠습니다.

데이터 파이프라인

데이터 누수라는 구조적 문제를 직접 경험하고 해결하며, 전처리 순서 하나가 모델 신뢰도 전체에 영향을 미친다는 것을 체감했습니다. 체계적인 전처리 파이프라인 설계 역량을 키웠습니다.

[Project] Beyond the Door of Memory — Unity 2D 감정 서사 어드벤처 게임

lalunru — Fri, 8 May 2026 17:17:38 +0900

Overview

Period

2025.03 – 2025.06

Team

2인 팀 프로젝트

Role

클라이언트 개발 (조작 시스템 및 기능 구현)

Platform

PC (Windows)

Background

플레이어의 선택에 따라 결말이 달라지는 몰입형 감정 서사를 전달하기 위해 기획되었습니다.

무의식과 트라우마라는 심리적 요소를 시각적으로 표현하고, 이를 잠입 요소 및 동적 환경 변화와 같은 게임 메커니즘과 결합하여 플레이어에게 심리적 압박감을 제공하는 것을 목표로 개발했습니다.

Contributions

01 다중 엔딩 및 씬 제어 시스템 구축

Problem

플레이어의 누적 선택이 결말에 반영되어야 했지만, 씬 간 상태 공유 수단이 없어 선택 결과를 엔딩까지 유지할 방법이 필요했습니다.

Impl

GameCounter.cs에서 static int value로 씬 이동 이후에도 유지되는 전역 상태 카운터를 구현하고, OnCountFinished_SwitchScene.cs에서 FixedUpdate()마다 해당 값을 감지해 조건 충족 시 지정된 씬으로 자동 전환하는 분기 로직을 작성했습니다. Interactable.cs와 TalkManager.cs를 연동해 오브젝트 상호작용 시 대화 UI가 열리고, 닫힐 때 OnDialogClosed 이벤트로 카운터가 갱신되어 스토리 분기가 진행되도록 설계했습니다.

Result

씬 전체를 복제하지 않고 단일 카운터 값만으로 2개의 엔딩 분기를 제어하는 경량 상태 머신을 구현했습니다.

02 동적 환경 알고리즘 및 시각적 피드백 구현

Problem

씬을 리로드하지 않고도 게임 중 실시간으로 긴장감을 끌어올릴 수 있는 레벨 디자인 알고리즘이 필요했습니다. 씬 리로드 시 플레이 흐름이 단절되고 로딩 오버헤드가 발생하는 문제가 있었습니다.

Impl

Sometime_RandomCreatePrefab.cs에서 InvokeRepeating()으로 일정 간격마다 SpriteRenderer.bounds 범위 내 랜덤 좌표에 프리팹을 생성하는 동적 배치 로직을 구현했습니다. 또한 PlayerController.cs에서 "Glass" 태그 오브젝트와의 충돌 시 StartCoroutine(FlashPlayer())를 호출해 SpriteRenderer를 0.1초 간격으로 깜빡이는 시각적 피드백을 구현하고, 3회 피격 시 게임오버 씬으로 전환하는 체력 시스템을 작성했습니다.

Result

씬 리로드 없이 실시간으로 오브젝트가 배치되는 동적 맵 환경을 구성하고, 피격 시 시각적 타격감을 코드로 표현하여 플레이 몰입감을 높였습니다.

03 AI 기반 추적 시스템 및 잠입 메커니즘 설계

Problem

단순히 쫓아오기만 하는 적은 긴장감이 낮고, 지형을 활용한 회피 전략이 성립하지 않아 게임성이 부족했습니다.

Impl

Forever_Chase.cs에서 FixedUpdate()마다 적과 플레이어 간의 방향 벡터를 정규화하고 Rigidbody2D.velocity에 직접 주입하는 방식으로 물리 기반 추적 로직을 구현했습니다. TypingGlitchWithSpawn.cs에서는 텍스트가 일정 횟수 반복 타이핑되면 가속도가 붙으면서 글리치 효과가 증가하고, 완료 시 적 오브젝트를 Instantiate로 스폰하는 연출 시퀀스를 작성했습니다. 시야 차단 판정은 Collider2D 레이어로 처리해 지형 뒤에 숨으면 추적이 끊기도록 설계했습니다.

Result

플레이어가 지형지물을 적극적으로 활용해 시야를 차단하며 회피하는 잠입 액션 메커니즘을 구현했습니다.

Troubleshooting

씬 리로드 없이 실시간 동적 오브젝트 배치 구현하기

Problem

스테이지에서 수집 아이템의 위치를 매번 다르게 배치하고 싶었으나, 씬을 리로드하면 플레이 진행 상태가 초기화되고 로딩 오버헤드가 발생하는 문제가 있었습니다.

Solve

Sometime_RandomCreatePrefab.cs에서 InvokeRepeating()으로 일정 간격마다 CreatePrefab()을 호출하고, SpriteRenderer.bounds.size로 오브젝트의 범위를 구한 뒤 Random.Range()로 그 안의 랜덤 좌표에 프리팹을 생성하는 방식으로 구현했습니다.

Result

씬 리로드 없이 게임 진행 중 실시간으로 오브젝트가 새로운 위치에 생성되어, 플레이 흐름의 단절 없이 매 플레이마다 다른 배치 환경을 제공할 수 있었습니다.

Demo

Ending 1 · True Ending

Ending 2 · Bad Ending

Links

GitHub

Retrospective

핵심 경험

Unity 코루틴과 상태 관리 로직을 다루며 게임 엔진의 생명주기를 이해하고 코드를 최적화하는 방법을 체득했습니다. static 카운터 기반의 경량 상태 머신으로 씬 간 데이터 유지 문제를 해결한 경험이 특히 인상적이었습니다.

기획 → 코드 치환

추상적인 기획 의도(트라우마, 기억 상실)를 카메라 쉐이크, 좌표 랜덤 재배치, 글리치 텍스트 같은 구체적인 코드 로직으로 치환하며 서사와 기술적 메커니즘을 엮어 사용자 경험을 설계하는 역량을 키웠습니다.

lalunru.blog

[MSW] REST 스냅샷과 WebSocket 실시간 데이터를 함께 쓸 때 생기는 경쟁 조건

1. 들어가며

2. 문제 상황: REST와 WS가 동시에 달린다

3. 왜 useState로는 해결이 어려운가

4. 해결: useRef로 비동기 클로저 간 상태 공유

5. 우선순위 전략: "마지막이 이긴다"가 아니다

6. 엣지 케이스 처리

snapshot이 null인 경우

WS 연결이 끊기는 경우

STOMP 오류 처리

7. 마무리

8. 참고 자료

[MSW] MSW v2가 WebSocket을 막을 때 — SockJS 폴백으로 우회한 방법

1. 들어가며

2. 문제 상황: MSW v2의 WebSocket 전면 인터셉트

3. 시도한 방법들과 실패 원인

시도 1. Vite 프록시로 우회

시도 2. MSW server.connect() passthrough

시도 3. NativeWebSocket 캡처

시도 4. MSW 전체 비활성화

4. 핵심 발견: 백엔드는 SockJS를 사용하고 있었다

5. 최종 해결: SockJS + STOMP 직접 연결

6. 추가 문제: SockJS의 /info 요청도 MSW가 가로챈다

7. 마무리 및 회고

8. 참고 자료

[Shadertoy] Shadertoy 입문 — 브라우저에서 시작하는 실시간 셰이더 개발

1. 들어가며

2. Shadertoy가 뭔가요?

3. 기본 구조 이해하기

4. 자주 쓰는 유니폼 변수 (Built-in Uniforms)

5. 자주 쓰는 GLSL 함수

6. 실전 예시: 원 그리기

7. Shadertoy에서 Unity로 이식하기

8. 실제로 만든 것들

9. 마무리

10. 참고 자료

[Project] NPR Shaders — GLSL로 구현한 비사실적 렌더링 셰이더 컬렉션

NPR Shaders진행 중

[Project] AssetMind — 금융자산관리 웹 서비스 UI/UX 개발 및 실시간 데이터 처리

AssetMind진행 중

[Unity VR] 성능 한계를 공포 연출로 커버한 라이트맵 최적화 경험

1. 들어가며

2. 문제 상황: 30fps, 멀미가 나는 게임

3. 해결 방안 모색

4. 라이트맵 베이크 전환 적용

5. 새로운 문제: 실시간 그림자가 사라졌다!

6. 한계를 연출로 커버하기

7. 마무리 및 회고

8. 참고 자료

[React] 제네릭을 활용한 재사용 가능한 데이터 카드 컴포넌트 설계

1. 들어가며

2. 문제 상황: 늘어나는 보일러플레이트와 중복 코드

3. 해결 방안 모색: 제어 역전(IoC)과 뷰(View) 계층의 분리

4. 제네릭을 활용한 컴포넌트 추상화 적용

5. 마무리 및 회고

6. 참고 자료

[Project] LSTM 기반 악성 URL 탐지 모델 — LSTM과 피처 엔지니어링의 결합

악성 URL 분류딥러닝 모델

[Project] 설명 가능한 인공지능(XAI)을 활용한 네트워크 침입 탐지 시스템의 개발 — 블랙박스 모델의 판단 근거를 설명하다

XAI 기반네트워크 침입 탐지 시스템

[Project] Beyond the Door of Memory — Unity 2D 감정 서사 어드벤처 게임

Beyond theDoor of Memory

시도 2. MSW `server.connect()` passthrough

6. 추가 문제: SockJS의 `/info` 요청도 MSW가 가로챈다

악성 URL 분류
딥러닝 모델

XAI 기반
네트워크 침입 탐지 시스템

Beyond the
Door of Memory