개발세밝

언리얼 공부하면 좋아보이는것

오늘은치킨이닭 — Sun, 29 Mar 2026 15:25:37 +0900

https://dev.epicgames.com/documentation/ko-kr/unreal-engine/gauntlet-automation-framework-overview-in-unreal-engine

언리얼 엔진의 건틀릿 자동화 프레임워크 개요 | 언리얼 엔진 5.7 문서 | Epic Developer Community

테스트를 수행하고 결과의 유효성을 검사하는 언리얼 엔진의 프로젝트 세션을 실행하는 프레임워크입니다.

dev.epicgames.com

건틀렛

2. 주요 테스트 도구 및 방법

Gauntlet 자동화 프레임워크

언리얼 엔진에서 E2E 테스트를 위해 가장 많이 사용하는 도구는 Gauntlet입니다.

역할: 게임 빌드를 실행하고, 여러 세션을 관리하며, 특정 시나리오를 수행한 뒤 결과를 보고합니다.
활용: "게임 패키징 -> 서버/클라이언트 실행 -> 특정 맵 로드 -> 플레이어 행동 수행 -> 결과 확인" 과정을 자동화할 수 있습니다.
멀티플레이어 테스트: 클라이언트 4명과 서버 1명을 동시에 띄워 네트워크 동기화를 테스트하는 데 매우 유용합니다.

functional Testing (기능 테스트 매니저)

에디터 내에서 Functional Test 레벨을 만들어 테스트를 진행할 수 있습니다.

레벨 안에 FunctionalTest 액터를 배치하고, 블루프린트나 C++로 성공/실패 조건을 설정합니다.
예: "플레이어가 A 지점에서 B 지점으로 10초 안에 도착하는가?"

큰 단위의 테스트만 실행하는 방향으로하고 세세한 조작감이나 인간이 개입이 필요한건 QA과정에서 하는걸 추천.

B/B+트리

오늘은치킨이닭 — Sun, 29 Mar 2026 14:54:25 +0900

B+ / B트리의 차이

1. B-Tree (Binary Tree의 확장)

B-Tree는 모든 노드(루트, 중간, 리프)가 **데이터(Value)**와 **키(Key)**를 함께 가질 수 있는 구조입니다.

데이터 저장: 어느 노드에서든 키와 일치하는 데이터를 찾으면 즉시 탐색을 종료할 수 있습니다.
중복 제거: 트리 전체에 걸쳐 키가 중복되지 않습니다.
탐색 효율: 특정 데이터를 찾을 때 운 좋게 루트 노드나 중간 노드에 데이터가 있다면 리프 노드까지 내려가지 않아도 되므로 탐색 시간이 단축될 수 있습니다.

2. B+Tree (B-Tree의 개선형)

B+Tree는 실제 **데이터(Value)**를 오직 **리프 노드(Leaf Node)**에만 저장하고, 중간 노드들은 데이터를 찾기 위한 가이드(Key) 역할만 수행합니다.

데이터 저장: 실제 레코드나 데이터 포인터는 모두 리프 노드에만 존재합니다.
연결 리스트(Linked List): 모든 리프 노드들은 서로 연결 리스트 형태로 이어져 있습니다. 덕분에 **범위 스캔(Range Scan)**이나 전체 탐색을 할 때 트리 위아래를 왔다 갔다 할 필요 없이 리프 노드만 순차적으로 읽으면 됩니다.
인덱스 노드의 효율: 중간 노드에 데이터를 담지 않기 때문에, 하나의 노드(페이지)에 더 많은 인덱스 키를 채울 수 있습니다. 이는 트리의 높이를 낮추어 대용량 데이터 처리 시 디스크 I/O 횟수를 줄여줍니다.

3. 주요 차이점 비교

구분	B-Tree	B+Tree
데이터 저장 위치	모든 노드에 저장 가능	오직 리프 노드에만 저장
리프 노드 간 연결	연결되지 않음	연결 리스트로 연결됨
탐색 성능	특정 키 탐색 시 빠를 수 있음	전체 탐색 및 범위 조회에 압도적 유리
트리의 높이	상대적으로 높음	상대적으로 낮음 (더 많은 키 수용)
사용 사례	일반적인 파일 시스템 등	대부분의 관계형 DB(MySQL, Oracle 등) 인덱스

1. B-Tree: 모든 노드에 데이터가 있는 구조

B-Tree는 검색 과정에서 중간 노드(Internal Node)에 찾는 키가 있으면 즉시 데이터를 반환합니다.

Java

public class BTreeNode {
    int[] keys;          // 부모/자식 노드를 구분하는 키
    Object[] data;       // 실제 데이터 (모든 노드가 데이터를 가짐)
    BTreeNode[] children; // 자식 노드 포인터
    int keyCount;
    boolean isLeaf;

    public Object search(int key) {
        int i = 0;
        while (i < keyCount && key > keys[i]) {
            i++;
        }

        // 1. 현재 노드에서 키를 찾으면 즉시 데이터 반환
        if (i < keyCount && keys[i] == key) {
            return data[i]; 
        }

        // 2. 리프 노드인데 못 찾았다면 데이터 없음
        if (isLeaf) {
            return null;
        }

        // 3. 자식 노드로 내려가서 계속 탐색
        return children[i].search(key);
    }
}

2. B+Tree: 리프 노드에만 데이터가 있고 서로 연결된 구조

B+Tree는 인덱스 노드(Internal Node)에는 가이드용 키만 있고, 실제 데이터 탐색은 반드시 리프 노드까지 내려가야 완료됩니다.

Java

public class BPlusTreeNode {
    // 인덱스 노드와 리프 노드를 구분하여 설계하는 것이 일반적입니다.
    
    // [인덱스 노드 역할]
    int[] keys; 
    BPlusTreeNode[] children; 

    // [리프 노드 역할 - 실제 데이터 저장소]
    Object[] data; 
    BPlusTreeNode next; // 다음 리프 노드를 가리키는 포인터 (연결 리스트)

    public Object search(int key) {
        BPlusTreeNode current = root;
        
        // 1. 무조건 리프 노드까지 내려감 (중간에 멈추지 않음)
        while (!current.isLeaf) {
            current = current.getChild(key);
        }

        // 2. 리프 노드에서만 실제 데이터를 확인
        for (int i = 0; i < current.keyCount; i++) {
            if (current.keys[i] == key) {
                return current.data[i];
            }
        }
        return null;
    }

    // 범위 검색 (Range Query) 시 장점
    public List<Object> searchRange(int start, int end) {
        List<Object> result = new ArrayList<>();
        BPlusTreeNode leaf = findLeafNode(start); // 시작점 리프 찾기

        // 연결 리스트를 따라가며 순차적으로 읽기만 하면 됨 (트리 재탐색 불필요)
        while (leaf != null) {
            for (Object d : leaf.data) {
                if (withinRange(d, start, end)) result.add(d);
            }
            leaf = leaf.next; 
        }
        return result;
    }
}

주요 차이점 요약 (코드 관점)

데이터 위치: B-Tree는 search 도중에 return data[i]가 가능하지만, B+Tree는 반드시 isLeaf가 true인 곳까지 도달해야 데이터를 얻을 수 있습니다.
메모리 효율: B+Tree의 중간 노드(Internal Node)는 Object[] data 배열을 가지지 않으므로, 같은 메모리 크기(페이지 사이즈) 안에 훨씬 더 많은 keys를 저장할 수 있어 트리의 깊이가 얕아집니다.
범위 조회: B-Tree는 10부터 20까지 찾으려면 트리를 계속 오르락내리락(In-order Traversal) 해야 하지만, B+Tree는 리프 노드에 도달한 뒤 next 포인터만 따라가면 되므로 매우 빠릅니다.

MAP과 SET은?

1. 주요 차이점 비교

구분	Set (셋)	Map (맵)
저장 방식	값(Value)만 저장	키(Key)와 값(Value)의 쌍으로 저장
중복 허용	중복 불가 (이미 있으면 무시됨)	키(Key)는 중복 불가, 값(Value)은 중복 가능
인덱스/순서	기본적으로 순서 없음 (구현체에 따라 다름)	순서 없음 (구현체에 따라 다름)
데이터 접근	Iterator나 향상된 for문을 사용해 탐색	키(Key)를 사용하여 특정 값을 바로 찾음

[Docker] TLS/Dockerfile/Compose/ Entrypoint/ 멀티스테이지/레이어 캐싱 / compose베이스

오늘은치킨이닭 — Thu, 26 Mar 2026 21:57:30 +0900

1. 원격 Docker 접근과 TLS

외부에서 Docker 접속 시 인증서가 없으면 거절되는 이유

Docker는 로컬에서는 보통 Unix Socket을 사용하지만, 원격 서버의 Docker 데몬을 제어하려면 2375 또는 2376 포트를 열어야 한다.
이때 외부 네트워크를 통해 Docker 데몬에 접근하면 보안 문제가 커지기 때문에, 기본적으로 인증과 암호화를 요구한다.

Docker의 TLS 옵션

Docker의 TLS는 Docker 클라이언트와 Docker 데몬 사이의 통신을 암호화하고, 서로의 신원을 확인하는 보안 인증 체계다.

필요한 요소:

CA 인증서
서버 인증서 / 서버 키
클라이언트 인증서 / 클라이언트 키

Insecure Registries

기본적으로 Docker는 레지스트리와 통신할 때 TLS(HTTPS) 기반의 암호화 연결을 강제한다.
Insecure Registries 설정은 이 보안 과정을 건너뛰고 HTTP 또는 검증되지 않은 연결을 허용하는 방식이다.

장점:

내부 테스트 환경에서는 설정이 간단하다.
인증서 구성이 번거로운 환경에서 빠르게 붙일 수 있다.

단점:

MITM(Man-in-the-Middle) 공격에 취약하다.
이미지 변조 위험이 있다.
인증 정보가 노출될 수 있다.

2. Dockerfile, Entrypoint, Compose의 역할

Dockerfile

Dockerfile은 이미지를 빌드하기 위한 레시피다.
즉, "서버를 실행할 수 있는 정적인 상태"를 정의하는 문서라고 보면 된다.

# 1. 베이스 이미지 설정
FROM openjdk:17-jdk-slim

# 2. 작업 디렉토리 생성
WORKDIR /app

# 3. 호스트의 빌드된 jar 파일을 컨테이너 내부로 복사
# 실제 경로는 프로젝트 빌드 도구에 따라 달라질 수 있음
COPY build/libs/admin-service.jar app.jar

# 4. 엔트리포인트 스크립트 복사 및 권한 부여
COPY docker_entrypoints/entrypoint-admin.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

# 5. 컨테이너 시작 시 실행할 엔트리포인트 지정
ENTRYPOINT ["/bin/bash", "/entrypoint.sh"]

Docker Entrypoint

Entrypoint는 컨테이너가 실제로 시작될 때 실행되는 초기화 스크립트다.
이미지 자체는 정적인 결과물이고, Entrypoint는 "실행 시점 로직"을 담당한다.

#!/bin/bash
set -e

echo "Starting Admin Service..."

# 예: DB가 준비될 때까지 대기
# /app/tools/wait-for-it.sh db-server:3306 --timeout=30

# 예: 로그 디렉토리 생성
mkdir -p /app/logs

# 실제 자바 프로세스 실행
# exec를 사용해야 Java 프로세스가 PID 1을 가져가서 시그널 처리 가능
exec java -jar /app/app.jar \
    --spring.profiles.active=${BUILD_STAGE} \
    --server.port=${ADMIN_PORT}

Entrypoint와 CMD 차이

ENTRYPOINT: 이 컨테이너가 "무엇을 실행하는 용도인지"를 고정하는 데 가깝다.
CMD: 기본 인자를 주거나, 필요 시 쉽게 덮어쓸 수 있는 기본 실행값에 가깝다.

Docker Compose

Docker Compose는 앞에서 만든 이미지와 실행 방식을 "어떤 환경에서 띄울지" 정의하는 도구다.

version: '3.8'

services:
  nb-admin:
    image: ${NB_REGISTRY_SERVER}/nb-admin:latest
    container_name: nb-admin-container

    environment:
      - BUILD_STAGE=${BUILD_STAGE}
      - ADMIN_PORT=8080
      - DB_URL=${NB_DB_URL}

    volumes:
      - ../docker_configs/admin/config.properties:/app/config.properties
      - /data/logs/admin:/app/logs

    networks:
      - nb-network

networks:
  nb-network:
    external: true

3. 게임 서버와 Docker

게임에서는 클라이언트까지 Docker에 넣는 경우는 드물고, 보통 데디케이티드 서버를 Docker 위에 올리는 경우가 많다.

이유:

서버는 반복 배포와 자동화가 중요하다.
동일한 실행 환경을 재현하기 쉽다.
확장, 재시작, 모니터링 자동화에 유리하다.

4. 멀티 스테이지 빌드

A. 일반 빌드(Single Stage)

이 방식은 빌드 도구와 소스 코드, 결과물을 모두 최종 이미지에 넣는 구조다.

FROM unreal-engine:5.3-build

WORKDIR /src
COPY . .

RUN /Build/BatchFiles/RunUAT.sh BuildCookRun ...

ENTRYPOINT ["./Packaged/LinuxServer/MyProjectServer.sh"]

문제점:

빌드에 사용한 엔진 소스, 컴파일러, 임시 파일이 이미지 안에 그대로 남는다.
이미지 용량이 매우 커진다.
소스 코드와 빌드 도구가 남아 있어 보안상 불리하다.

예시로 생각해볼 수 있는 문제:

언리얼 기반이면 수백 GB 수준까지 커질 수 있다.
Java/Maven 기반도 .m2, 빌드 툴, 소스 코드가 같이 들어가면 수백 MB에서 1GB 이상으로 커질 수 있다.

B. 멀티 스테이지 빌드(Multi-stage)

빌드 전용 스테이지와 실행 전용 스테이지를 분리해서, 최종 결과물만 실행 이미지로 가져오는 방식이다.

# Stage 1: 빌드 전용
FROM unreal-engine:5.3-build AS builder
WORKDIR /src
COPY . .
RUN /Build/BatchFiles/RunUAT.sh BuildCookRun ...

# Stage 2: 실행 전용
FROM ubuntu:22.04
WORKDIR /game

# builder 스테이지에서 결과물만 복사
COPY --from=builder /src/Packaged/LinuxServer/ .

ENTRYPOINT ["./MyProjectServer.sh"]

장점:

최종 이미지에는 실행에 필요한 파일만 남는다.
용량이 크게 줄어든다.
빌드 도구와 소스 코드가 빠져 보안상 유리하다.

핵심:

Stage 1은 빌드용
Stage 2는 실행용
최종 배포는 Stage 2만 사용

5. 레이어 캐싱 최적화

Docker는 Dockerfile의 각 명령을 실행할 때마다 그 결과를 레이어로 저장한다.
파일이 바뀌지 않으면 이전 레이어를 재사용하므로 빌드 속도가 빨라진다.

비효율적인 방식

FROM unreal-engine:5.3-build
WORKDIR /src

COPY . .
RUN /Build/BatchFiles/RunUAT.sh BuildCookRun ...

문제:

프로젝트 내부 파일 하나만 바뀌어도 COPY . . 레이어가 무효화된다.
그 아래의 무거운 빌드 단계도 다시 실행된다.
소스 한 줄 바꾸고도 수십 분을 다시 빌드할 수 있다.

캐시를 고려한 방식

FROM unreal-engine:5.3-build
WORKDIR /src

# 자주 안 바뀌는 파일 먼저
COPY MyProject.uproject ./
COPY Config/ ./Config/
COPY Plugins/ ./Plugins/

RUN echo "Base environment ready"

# 자주 바뀌는 파일은 뒤에서 복사
COPY Source/ ./Source/
COPY Content/ ./Content/

RUN /Build/BatchFiles/RunUAT.sh BuildCookRun ...

핵심 원칙:

폴더 단위로 무조건 잘게 쪼개는 것이 아니라
변경 주기가 비슷한 파일끼리 묶는 것이 더 중요하다

왜 무조건 잘게 나누는 게 답은 아닌가?

1. 언리얼/C++의 PCH 문제

C++은 빌드 속도 향상을 위해 PCH(Precompiled Header)를 사용한다.
특정 폴더만 다시 복사해도 공통 헤더 의존성이 있으면, 실제 빌드 시스템은 전체 리빌드를 판단할 수 있다.

즉:

Docker 레이어는 캐시되었더라도
내부 빌드 시스템이 다시 큰 빌드를 수행할 수 있다

2. 레이어 수 증가와 관리 비용

레이어를 지나치게 많이 쪼개면 다음 문제가 생긴다.

변경 체크 비용이 늘어난다.
Dockerfile 가독성이 떨어진다.
Jenkins나 API에서 자동화할 때 유지보수가 어려워진다.

결론:

캐시는 중요하지만
"너무 잘게 쪼개는 것"보다 "변경 패턴에 맞게 나누는 것"이 더 중요하다

6. Compose Override

docker-compose.yml 하나를 공통 설계도로 두고, 개발/테스트/운영 환경마다 필요한 부분만 추가 파일로 덮어쓰는 방식이다.

왜 필요한가?

예를 들어 모든 게임 서버가 같은 이미지를 사용한다고 해도, 방마다 설정이 다를 수 있다.

예시:

1번 방 서버: 7777 포트 사용, 데스매치 맵 실행
2번 방 서버: 7778 포트 사용, 점령전 맵 실행, CPU 제한 강화

이걸 매번 새 YAML 파일 전체를 복사해서 만들면 관리가 어려워진다.
그래서 기본판 + override 파일 조합 방식을 쓴다.

기본 파일

version: '3.8'

services:
  game-node:
    image: ${REGISTRY_URL}/unreal-server:latest
    networks:
      - game-network
    restart: always

networks:
  game-network:
    driver: bridge

운영용 override 파일

version: '3.8'

services:
  game-node:
    ports:
      - "${SERVER_PORT}:7777/udp"
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 2G
    environment:
      - MAP_NAME=${SELECTED_MAP}
      - MAX_PLAYERS=50

실행 방법

뒤에 오는 파일이 앞 파일 설정을 덮어쓴다.

# 기본 + 운영
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# 기본 + 개발
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

Django API와의 연계

예를 들어 Django API에서 아래처럼 환경 변수를 주입해 Docker Compose를 실행할 수 있다.

import subprocess

def deploy_game_server(port, map_name):
    env_vars = {
        "SERVER_PORT": str(port),
        "SELECTED_MAP": map_name,
        "REGISTRY_URL": "my-reg.com"
    }

    cmd = [
        "docker-compose",
        "-f", "docker-compose.yml",
        "-f", "docker-compose.prod.yml",
        "up", "-d"
    ]

    subprocess.run(cmd, env=env_vars)

7. Health Check

Dockerfile에서 Health Check 설정

컨테이너 내부 서비스가 정상적으로 살아 있는지 Docker가 주기적으로 검사하게 만들 수 있다.

# 포트 확인 도구 설치
RUN apt-get update && apt-get install -y net-tools iproute2

# 30초마다 체크, 5초 제한, 3번 실패 시 unhealthy
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD netstat -anup | grep :7777 || exit 1

ENTRYPOINT ["./MyProjectServer.sh", "-log"]

Django API에서 Health 상태 읽기

import docker

def get_server_status(container_name):
    client = docker.from_env()
    container = client.containers.get(container_name)

    health_status = container.attrs['State']['Health']['Status']

    if health_status == 'healthy':
        return "접속 가능 (로딩 완료)"
    elif health_status == 'starting':
        return "로딩 중... 잠시만 기다려주세요"
    else:
        return "서버 이상 발생 (Unhealthy)"

실무에서 왜 중요한가?

unhealthy 상태를 감지해 자동 재시작 전략과 연결할 수 있다.
매치메이킹에서 아직 starting 상태인 서버를 제외할 수 있다.
depends_on 및 상태 확인과 조합하면, DB가 완전히 준비된 뒤 게임 서버를 띄우도록 제어할 수 있다.

8. 전체 요약

이번 내용의 핵심은 다음과 같다.

원격 Docker 제어에는 TLS 같은 보안 구성이 중요하다.
Dockerfile은 이미지 정의, Entrypoint는 실행 시점 초기화, Compose는 환경별 실행 구성을 담당한다.
게임 서버는 Docker에 올리기 적합하지만, 클라이언트는 보통 대상이 아니다.
멀티 스테이지 빌드는 용량과 보안 측면에서 매우 중요하다.
레이어 캐싱은 빌드 시간을 줄이지만, 무조건 잘게 나누는 것이 정답은 아니다.
Compose Override를 쓰면 환경별 설정을 깔끔하게 관리할 수 있다.
Health Check는 운영 자동화와 장애 대응에 매우 유용하다.

도커 데몬

* 도커 엔진의 심장이나 관리자 역할을 하는 백그라운드 프로세스

* 도커 클라 - 터미널에서 입력하는 명령어 도구

* 도커 데몬 - 클라로부터 REST API를 듣고 작업 처리 , 이미지 관리, 컨테이너관리, 네트워크 및 볼륨관리

를 데몬이함.

도커 이미지 만드는 과정

docker push 명령을 내리면

레이어 체크섬 계산.

3. Dockerfile 빌드와 체크섬

docker build를 실행할 때 도커 엔진은 각 명령어(RUN, COPY, ADD 등)에 대해 체크섬을 검사합니다.

COPY/ADD 명령어: 복사하려는 로컬 파일의 내용과 메타데이터를 기반으로 체크섬을 생성합니다. 파일 내용이 1비트라도 다르면 체크섬이 변하고, 캐시는 깨집니다.
RUN 명령어: 실행되는 명령어 텍스트 자체를 체크섬으로 사용합니다. (주의: RUN apt-get update는 명령어 텍스트가 같으면 캐시를 사용하므로, 실제 외부 패키지 업데이트 여부는 감지하지 못할 수 있습니다.)

4. 레이어 체크섬 확인 방법

터미널에서 특정 이미지의 레이어 체크섬(DiffID) 구조를 직접 확인해 볼 수 있습니다.

Bash

docker inspect <이미지_이름_또는_ID>

출력 결과 중 RootFS.Layers 항목을 보면 해당 이미지를 구성하는 레이어들의 SHA256 체크섬 리스트를 확인할 수 있습니다.

1. 빌드 컨텍스트 준비 -> 파일이 도커 데몬으로 전송

[Django]

오늘은치킨이닭 — Tue, 24 Mar 2026 22:00:25 +0900

MVT패턴이란 ?

모델

역할 : DB의 구조를 정의함
특징 : SQL을 직접 작성 하지 않고도 파이썬 코드로 DB 테이블을 정의하고 데이터 조작가능한 ORM제공 DB의 CRUD 로직 관리

뷰

역할 : 애플리케이션의 비즈니스 로직 처리.
특징 : 모델에서 필요한 데이터를 가져와 가공하거, 그결과를 템플릿으로 전달함. MVC에서 Controller역할

템플릿

역할 : 사용자에게 보여지는 화면을 담장.
특징 : HTML 파일 내에 DTL을 사용해 뷰에서 전달 받은 데이터를 동적으로 표시함.

요청 생명주기

Web Server (Nginx/Apache): 사용자 요청을 가장 먼저 받아서 정적 파일(이미지 등)은 직접 처리하고, 동적 요청은 WSGI(Gunicorn 등)를 통해 Django로 넘깁니다.
URL Conf (urls.py): Django에 도착한 요청의 URL을 보고 "이 주소는 어떤 View가 처리해야 하지?"를 찾습니다.
View: 담당 View가 호출됩니다. 여기서 Model을 통해 DB에서 데이터를 가져오거나, 복잡한 계산 로직을 수행합니다.
Template: View가 처리한 데이터를 Template에 전달합니다. 템플릿은 데이터를 받아 최종적인 HTML 페이지를 완성합니다.
Response: 완성된 HTML을 다시 사용자 브라우저로 응답하며 마무리됩니다.

Middleware

스프링의 AOP랑 비슷한듯 가로채는 역할을 수행함.

장고는 VIEW에 도달하기 전 + 모든 응답이 사용자에게 가기전에 미들웨어를 통과함

인증 및 권한 : 특정 세선이 없으면 view까지 가지도 못하게 입구컷 가능
공통 로깅 : 모든 API의 요청의 소요 시간 , ip같은것을 일괄적으로 수집해 모니터링으로 보내기 좋다.
보안을 처리하기 좋음 : CSRF공격 방어 , XSS필터링 HTTPS 강제 리다이렉션 등 한곳에 처리.인증 및 권한 : 특정 세선이 없으면 view까지 가지도 못하게 입구컷 가능

등록 방법

1. 커스텀 미들 웨어 작성

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # 최초 설정 시 실행됨

    def __call__(self, request):
        # 1. 뷰가 호출되기 전 처리할 로직 (Request 단계)
        print("뷰 호출 전")

        response = self.get_response(request)

        # 2. 뷰가 호출된 후 처리할 로직 (Response 단계)
        print("응답 반환 전")

        return response

2. settings.py에 등록

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # ... 기존 미들웨어들 ...
    
    # 본인이 만든 미들웨어 경로 추가 (앱이름.파일이름.클래스이름)
    'myapp.middleware.SimpleMiddleware',
]

Django ORM의 장단점

WSHI vs ASGI

주말 숙제

forms.py -> 페이지 구성해보고

models.py -> 페이지 db에 올리고

urls.py ->views.py

콤보 박스 a가 변화할때 콤보박스 b의 내용을 변화시켜라.

백엔드 취업 질문

오늘은치킨이닭 — Tue, 24 Mar 2026 21:18:20 +0900

내가 받아본 질문 목록

스프링 프록시 객체언제 생성하는지
vue에서 dom이뭐임
RAG란
왜 벡터DB 썻는지
레디스는 몇개의 쓰레드쓰는지 왜 그렇게하는건지

DB 트랜잭션 격리수준 -> private인건 트랜잭션이 적용 될까요 안될까요
DB 락
DB 인덱스는 뭔지

왜 트리구조?
B+트리 B트리
인덱스 삭제하면 왜 느려짐?
모든걸 인덱스하면 조회가 빨라질까?
스프링 배치 방법 / 청크나눠 올리는 중에 삭제되면 어떻게 처리될지
스프링 DI/AOP/IOC 최대한 자세히 + 어노테이션
스프링은 예외처리 어떻게 처리할까요?
N+1 해결 방법들
정합성 보장 방법
SSE알림 어떻게 구현했는지
스프링에서 API들어올때 어떤식으로 들어오는지 처음부터 최대한 자세히 과정 설명.
디자인 패턴 아는거
디자인 패턴중 싱글톤에대해서
싱글톤 생성방법

트리는 리스트가 아님

트리의 재정렬과 리스트의 재정렬을 착각하면 안됨

게임 안 NPC와 플레이어가 인스타그램 UI에서 댓글로 상호작용 구현

오늘은치킨이닭 — Thu, 5 Mar 2026 13:53:52 +0900

전체적인 구조 : 언리얼에서는 UVVM을 공부할겸 짜보고 백엔드는 MVC로 구현했음.

- Model
  - `UTraningSocialSubsystem`
  - 역할: 소셜 도메인 상태 보유, 서버 동기화, 댓글 전송/검증, 이벤트 발행
- ViewModel
  - `UTraningInstagramViewModel`
  - 역할: Model 이벤트 구독, 화면용 상태 재가공, View 액션을 Model 유스케이스로 라우팅
- View
  - `UTraningInstagramWidgetBase`
  - 역할: 사용자 입력 수집, ViewModel 이벤트 반영 렌더링, 비즈니스 로직 비보유

Q. 페르소나

A. 벡터 DB에 넣을 수 있겠지만 Test용으로 직접 부여

Q. 알림 기능은 ?

A. 미구현 허나 sse나 웹소켓쓰면될듯

Q. 요청 개많으면 어떻게 처리함?

A. 큐에 넣고 순서대로 처리

https://www.youtube.com/watch?v=e4_lrz4bxSs&feature=youtu.be

MVVM UI

오늘은치킨이닭 — Fri, 27 Feb 2026 20:50:18 +0900

모델 - 뷰 - 뷰모델

언리얼에서 공식 지원하기 시작함.

뷰는 모델을 신결 쓸필요없이 뷰모델한테 달라고하면됨

뷰모델은 뷰의 요청을 모델에서 받아옴.

백엔드 역할

-> llm api호출 + 비동기 post처리 + 큐에 요청을 담아놓음.

왜? 댓글 폭주시 댓글 분실 위험

구현 순서

llm api호출 -인스타 피드 데이터 저장 -

언리얼 역할

-> UI에 데이터를 보여줌.

ai에게 일 잘 맡기기

오늘은치킨이닭 — Fri, 27 Feb 2026 20:46:35 +0900

1. 리서치

* 이 폴더를 깊이 읽고 , 어떻게 동작하는지 깊이 이해하고 모든 세부사항을 파악해라. 끝나면 research.md에 상세 보고서를 작성해라. -> 생각해보니 md를 통해 코드 위키를 보고 이해하면 내가 물어보는 토큰을 아낄 수 있다. + 역할 부여하는것도 좋을듯. 어떤 관점에서 기능이 필요한지 ex) 엔진수정이면 엔진 개발자 관점에서 코드이해 같은 또 매우 깊이 상세하게 자세히 가 중요하다고함.

2. 계획

* ~~기능을 작성하려는데 조건1. 조건2. 소스 파일을 읽고 실제 코드 베이스 기반으로 기획을 작성 + Plan.MD도 보고서 작성

-> 제일 많이 힘써야하는단계. 내가 놓치는 부분이 없는지 + 고려해야되는데 고려를 못한건 없는지 생각해봐야함. ex) 8진트리로 eqs를 줄이려는데 -> 이걸 왜줄이려고했지 나부터 왜 이걸 하려는지 명확하게 생각하고 지시를 자세히 해야함.

이 계획을 보고 재수정 다시 프롬포트 또 재수정을 반복함.

그리고 절대 구현 X

3. 구현

* 계획이 잘되어있다면 구현은 기계적으로 하면됨. todo_list를 지우면되기때문에

루트모션 / 모션워핑

오늘은치킨이닭 — Thu, 26 Feb 2026 15:34:13 +0900

루트모션이란

애니메이션 자체에 포함된 캐릭터의 실제 이동 및 회전 정보를 게임 내 캐릭터 좌표에 반영하는기술

구분 일반 애니메이션 (In-Place) 루트 모션 (Root Motion)

이동 방식	스크립트(가속도/속도)로 캡슐을 이동시킴	애니메이션의 루트 본 궤적을 따라 이동
발 미끄러짐	속도와 애니메이션이 안 맞으면 발생함	발이 땅에 붙어 있는 듯 정교함
조작성	즉각적인 반응(정지, 회전)이 유리함	애니메이션의 길이에 종속되어 반응이 약간 느릴 수 있음
주요 용도	일반적인 걷기, 뛰기, FPS 게임 등	콤보 공격, 담 넘기, 처형 씬, 복잡한 회피기

이를 적용하기 위해서는 DCC툴에서 루트 본에 이동값을 애니메이션 키로 잡아야한다.

"루트 본에 이동값을 키로 잡는다"는 것은 캐릭터가 앞으로 나가는 움직임을 단순히 팔다리만 흔드는 것이 아니라, 최상위 부모인 Root 본 자체가 실제로 좌표 평면 위에서 이동하도록 애니메이션 프레임마다 위치 데이터(Keyframe)를 기록하는 것을 의미합니다

루트본의 키값은 당연히 로컬 좌표 기준

1. 일반 애니메이션 (In-Place)

Root 본: 원점 (0, 0, 0)에 고정되어 움직이지 않습니다.
Pelvis(골반) 본: 발을 내디디며 몸이 앞으로 나가는 것처럼 보이게 움직이지만, 한 걸음 뒤에는 다시 원점으로 돌아옵니다.
결과: 캐릭터는 트레드밀(런닝머신) 위에서 뛰는 것처럼 제자리걸음을 합니다. 게임 엔진에서는 코드를 통해 캡슐 컴포넌트를 강제로 밀어줘야 이동합니다.

2. 루트 모션 애니메이션 (Root Motion)

Root 본: 캐릭터가 발을 내디딜 때마다 Root 본 자체가 앞으로 전진합니다.
Keyframe: 0프레임에 (0, 0, 0)이었다면, 30프레임에는 (100, 0, 0) 위치에 가 있도록 위치 값을 입력(Key)합니다.
결과: 애니메이션 데이터 안에 "이 캐릭터는 1초 동안 100만큼 전진한다"라는 물리적인 이동 정보가 포함됩니다.

모션워핑이란

애니메이션 실행하는 도중 캐릭터의 루트모션을 타겟 위치나 회전값에 맞춰 동적으로 변형하는 기술

모션워핑 작동 원리

트랜스폼 기준

로컬 to 월드

S-R-T (스케일-> 로테이션-> 트렌스레이션) 물체 그릴 때 적용되는 순서

월드 트랜스폼 = 로컬트랜스폼 X 부모 트랜스폼

트랜스폼 체이닝

ex) 손의 월드 트랜스폼 = 연결되어있는 Local 핸드 * local 팔꿈치 * local 어깨 * local 루트 * local 캡슐 * 월드 아이덴티티

언리얼 엔진 내부에서는 이 계산을 매 프레임 수천 번씩 수행해야하므로, 두가지 방식으로 나누어서 관리함.

1. 컴포넌트 스페이스

캐릭터 메쉬의 루트본을(0,0,0)으로 잡고 계산한 방식

손->팔꿈치->어깨->루트까지만 계산한 결과

2. 월드 스페이스

위에서 구한 결과에 마지막으로 캡슐의 월드 트랜스폼을 곱하는 단계

World = Local * Parent (자식 먼저, 부모 나중)
Local = World * Parent_Inverse (월드 먼저, 부모 역행렬 나중)

애니메이션에서 루트 모션값을 추출해 충돌 판정

ExtractRootMotionFromTrackRange를 통해 델타 추출가능함.

결과물

https://youtu.be/45pgq5Re7hQ

EQS

오늘은치킨이닭 — Wed, 25 Feb 2026 18:15:10 +0900

EQS구성요소

- CoverNode 동작 시뮬레이션 구현하기

EQS의 3요소 정리

Generator (생성기)

가장 먼저 후보지(Items)들을 생성합니다.

Actors: 주변의 특정 액터들을 후보로 지정.
Simple Grid: AI 주변에 일정한 간격으로 점(Point)들을 생성.
Donut: 도넛 모양의 범위 안에 점들을 생성.

Context (맥락)

기준이 되는 대상을 정의합니다.

Querier: 쿼리를 수행하는 AI 자신.
Player: 플레이어의 위치.
Environmental: 특정 아이템이나 위치.

Tests (테스트)

생성된 후보지들을 필터링하고 점수를 매깁니다.

Distance: 기준점으로부터의 거리.
Trace: 시야(Line of Sight)가 확보되는지 여부.
Pathfinding: 해당 위치까지 실제로 이동 가능한지 여부.
Dot Product: AI가 특정 방향을 바라보고 있는지 등

1. "메모리 여기저기 흩어져 있으면 왜 느릴까?" (Cache Locality)

CPU는 생각보다 똑똑하지 않아서, 메모리(RAM)에서 데이터를 직접 하나씩 가져오면 너무 느려집니다. 그래서 **캐시(L1, L2, L3 Cache)**라는 아주 빠른 임시 보관소를 사용합니다.

캐시 라인(Cache Line): CPU가 메모리에서 데이터를 가져올 때, 딱 필요한 '4바이트'만 가져오는 게 아니라 그 주변 데이터(보통 64바이트)를 뭉텅이로 한꺼번에 가져옵니다. "이거 썼으니까 바로 옆에 있는 것도 쓰겠지?"라고 추측하는 거죠.
연속된 메모리 (빠름): 3,000개의 위치 정보가 배열(TArray)에 FVector 형태(단순 구조체)로 쭈욱 붙어 있다면, CPU는 한 번 메모리에 접근해서 수십 개의 위치 정보를 캐시에 담아 광속으로 처리합니다.
흩어진 메모리 (느림, Cache Miss): 하지만 AActor* 포인터 3,000개는 다릅니다. 각 액터 객체는 월드에 스폰될 때 메모리의 **서로 다른 위치(Heap)**에 생성됩니다.
1. 1번 액터 위치 보러 메모리 갔다 옴 (캐시 채움)
2. 2번 액터 위치 보러 갔더니 캐시에 없음 → 다시 메모리 멀리 갔다 옴 (Cache Miss)
3. 이 과정을 3,000번 반복하면 CPU 연산 장치는 데이터가 오기만을 기다리며 계속 멍 때리게 됩니다(Stall).

이게 바로 **"데이터 지향 설계(Data-Oriented Design)"**에서 말하는 핵심 병목 구간입니다.

그리드(Grid) 해시 맵은 복잡한 트리 구조(Octree)보다 구현이 훨씬 간단하면서도, 정적인 데이터를 찾을 때는 **상수 시간($O(1)$)**에 가까운 성능을 내는 아주 강력한 기법입니다.

쉽게 비유하자면, 월드를 아주 작은 **'우편번호 구역'**으로 나누고, 각 구역(Grid Cell)이라는 보관함에 커버 노드들을 미리 담아두는 방식입니다.

1. 핵심 동작 원리

공간 분할 (Grid Size 결정): 월드를 가로, 세로, 높이 일정한 크기(예: 500 unit)의 격자로 나눕니다.
데이터 등록 (BeginPlay): 3,000개의 커버 노드를 순회하며 자신의 위치가 어느 격자에 속하는지 계산하여 저장합니다.
- GridIndexX = Floor(Location.X / GridSize)
- GridIndexY = Floor(Location.Y / GridSize)
- 이 인덱스들을 조합해 하나의 Key로 만듭니다. (예: FIntVector)
데이터 저장: TMap<FIntVector, TArray<ACoverNode*>> 형태의 구조체에 담습니다.

2. 캐릭터가 노드를 찾을 때 (Query)

캐릭터가 주변 커버 노드를 찾을 때는 더 이상 3,000개를 뒤지지 않습니다.

즉시 계산: 캐릭터의 현재 위치를 GridSize로 나누면 캐릭터가 서 있는 칸의 인덱스가 바로 나옵니다.
주변 탐색: 캐릭터가 속한 칸과 인접한 8칸(혹은 사거리 내의 칸들)의 Key를 생성해 TMap에서 꺼내옵니다.
결과: 수천 개가 아니라, 단 몇 명의 이웃 칸에 담긴 수십 개의 노드만 즉시 손에 쥐게 됩니다.

3. 왜 이게 옥트리나 Overlap보다 빠를까?

연산의 단순함: 옥트리는 "이 상자 안에 있나?"를 체크하며 여러 단계를 타고 내려가야 합니다($O(\log N)$). 하지만 그리드는 단순 나눗셈 한 번이면 위치가 나옵니다($O(1)$).
메모리 연속성: TArray에 담긴 노드들만 루프를 돌면 되므로, 아예 상관없는 멀리 있는 노드들의 메모리는 건드리지도 않습니다.
예측 가능성: 물리 엔진의 Overlap은 내부적으로 동적인 물체(캐릭터, 발사체 등)까지 계산하느라 복잡하지만, 이건 정적인 커버 노드 전용이라 군더더기가 없습니다.

4. 구현 예시 (C++ 의사 코드)

C++

// 1. 그리드 키 생성 함수
FIntVector GetGridKey(FVector Location) {
    return FIntVector(
        FMath::FloorToInt(Location.X / 500.f),
        FMath::FloorToInt(Location.Y / 500.f),
        0 // 2D 그리드라면 Z는 무시 가능
    );
}

// 2. 데이터 등록 (BeginPlay)
TMap<FIntVector, TArray<ACoverNode*>> CoverGridMap;
for (ACoverNode* Node : AllNodes) {
    CoverGridMap.FindOrAdd(GetGridKey(Node->GetActorLocation())).Add(Node);
}

// 3. 쿼리 (AI가 노드 찾을 때)
FIntVector MyKey = GetGridKey(AIPathLocation);
TArray<ACoverNode*> Candidates;
// 내 칸과 주변 칸들을 순회하며 수집 (예: -1 ~ +1 범위)
for (int x = -1; x <= 1; ++x) {
    for (int y = -1; y <= 1; ++y) {
        FIntVector NeighborKey = MyKey + FIntVector(x, y, 0);
        if (CoverGridMap.Contains(NeighborKey)) {
            Candidates.Append(CoverGridMap[NeighborKey]);
        }
    }
}