1. OpenCode가 뭐야?

OpenCode는 터미널에서 사용하는 AI 코딩 도구(CLI)다. ChatGPT처럼 대화하지만, 내 로컬 프로젝트 폴더 안에서:

• 코드 생성
• 코드 수정
• 파일 생성
• 리팩토링
• 설명 요청

같은 작업을 바로 수행할 수 있다.

즉,

웹에서 쓰는 GPT → 내 프로젝트 폴더 안에서 직접 코드 작업하는 AI

라고 이해하면 쉽다.

2. 설치 방법 (Windows 기준)

1단계: Git Bash 또는 PowerShell 열기

• Windows 검색 → Git Bash
• 또는 PowerShell

붙여넣기 단축키

• Git Bash: Shift + Insert
• PowerShell: Ctrl + V

2단계: 설치 명령어 실행

아래 명령어 복사해서 붙여넣기:

curl -fsSL https://opencode.ai/install | bash

설치가 완료되면 터미널에서:

opencode

라고 입력했을 때 실행되면 성공.

3. Provider 연결하기 (제일 중요)

OpenCode는 AI 모델과 연결해야 작동한다.

이걸 Provider라고 한다.

예시 Provider:

• OpenAI
• Anthropic
• 로컬 LLM (Ollama 등)

OpenAI 연결 예시

1단계: OpenAI API Key 발급

1. https://platform.openai.com 접속
2. API Key 생성

2단계: 환경변수 등록 (Windows PowerShell)

setx OPENAI_API_KEY "여기에_내_API키"

터미널을 완전히 닫았다가 다시 열기

3단계: Provider 설정

opencode config

또는

opencode connect

여기서 OpenAI 선택

4. 기본 사용법

1️⃣ 프로젝트 폴더로 이동

예:

cd D:\UnrealProject\MyGame

그 다음:

opencode

이제 이 폴더 안에서 AI가 작업한다.

2️⃣ 대화 방식 사용

예:

이 프로젝트에 C++로 점프 기능 추가해줘

또는

이 코드 리팩토링해줘

또는

현재 폴더 구조 설명해줘

5. OpenCode로 가능한 것

코드 생성

• C++
• Unreal C++
• Python
• React
• 서버 코드 등

파일 생성

• 헤더 파일 자동 생성
• 클래스 구조 생성
• README 작성

코드 수정

• 기존 코드 읽고 수정
• 버그 수정
• 최적화

6. OpenCode의 한계

❌ 자동으로 Unreal Editor를 조작하진 못함

• 에디터 버튼 클릭 불가
• 블루프린트 직접 수정 불가

❌ 인터넷 검색 자동으로 하지 않음 (기본 설정)

• 로컬 파일 기반 작업

7. OpenCode vs ChatGPT 차이

8. 실전 예시 (언리얼 C++ 기준)

예시 1

ACharacter 상속받은 클래스에 더블 점프 기능 추가해줘

예시 2

이 프로젝트에서 B01으로 시작하는 StaticMesh 자동으로 배열로 모으는 코드 만들어줘

9. OpenCode는 어떤 개념인가?

이건 이런 개념이다:

• LLM (Large Language Model)
• CLI 기반 AI Agent
• 로컬 코드 어시스턴트

즉,

GPT를 내 프로젝트 안으로 끌고 들어온 것

이라고 보면 정확하다.

10. 추천 사용 흐름

1. 기능 설계는 ChatGPT에서 정리
2. 실제 코드 생성/수정은 OpenCode
3. Unreal Editor에서 테스트
4. 다시 OpenCode로 수정

이 방식이 가장 효율적이다.

11. 초보자가 헷갈리는 부분 정리

Q: Bash는 폴더마다 하나인가?

아니다. 터미널은 하나고, cd로 이동하는 것이다.

Q: GPT랑 뭐가 다른 거야?

GPT는 대화 OpenCode는 프로젝트 직접 수정

Q: Unreal C++도 가능?

가능. 헤더/CPP 구조 이해하고 생성도 잘한다.

마무리 정리

OpenCode는:

• AI를 터미널에서 쓰는 도구
• 로컬 프로젝트 직접 수정 가능
• 코딩 생산성을 크게 올려줌
• 특히 C++/언리얼 프로젝트에 매우 강력함

Content : 게임 프로젝트에 사용하는 에셋을 관리하는 공간. 항상 보관해야 한다.

Intermediate : 프로젝트 관리에 필요한 임시 파일들을 저장하는 공간. 이 폴더는 제거해도 에디터에 의해 자동으로 재생성된다.

Saved : 에디터 작업 중에 생성된 결과물을 저장하는 공간. ex)세이브파일, 스크린샷은 모두 이곳에 저장된다. 이 폴더를 제거하면 수동으로 저장한 세이브파일이나 스크린샷등이 삭제될 수 있지만, 게임 프로젝트에는 영향을 주지 않는다.

Binaries : C++ 코드가 컴파일된 결과물을 저장하는 공간. 이 폴더는 삭제해도 빌드할 때마다 새롭게 생성된다.

Source : C++ 소스 코드가 위치한 공간. C++ 소스 외에도 언리얼 엔진의 독특한 빌드 설정을 담은 C# 소스파일이 있으며, 폴더를 삭제할 때 프로젝트 구성이 망가지므로 주의해야 한다.

.sln : C++ 프로젝트를 관리하기 위한 비주얼 스튜디오의 솔루션 파일. 솔루션이 관리하는 각 프로젝트 파일은 Intermediate 폴더 내 ProjectFiles 폴더에 있다. 프로젝트 파일과 솔루션 파일은 삭제하더라도 uproject 파일을 우클릭해 뜨는 Generate Visual Studio project file 메뉴를 선택하면 언제든지 재생성할 수 있다.

• HEAD
• 브랜치(branch)
• git reset

처음에는 각각 따로 외워야 할 것처럼 보이지만, 사실은 “포인터가 어디를 가리키고 있느냐” 하나로 연결된 개념이다.

1. 브랜치란 무엇인가

브랜치는 커밋을 가리키는 포인터다. 즉, 브랜치는 “이 커밋을 기준으로 작업 중이다”라는 표시다.

브랜치 구조 예시

A --- B --- C   (main)

• A, B, C는 커밋
• main 브랜치는 가장 최신 커밋 C를 가리킨다

이 상태에서 새로운 커밋을 만들면:

A --- B --- C --- D   (main)

main 브랜치는 자동으로 D로 이동한다. 브랜치는 “고정된 개념”이 아니라 계속 움직이는 포인터다.

2. HEAD는 무엇인가

HEAD는 “현재 내가 보고 있는 위치”를 가리키는 포인터다.

대부분의 경우 HEAD는 브랜치를 가리킨다.

HEAD -> main -> C

의미를 풀면:

• 나는 main 브랜치를 체크아웃했고
• main은 C 커밋을 가리키고 있으며
• 현재 작업 디렉토리는 C 기준이다

중요한 포인트는 이것이다.

• 브랜치는 커밋을 가리킨다
• HEAD는 브랜치를 가리킨다

즉, HEAD → 브랜치 → 커밋 이 구조로 이어진다.

3. git reset은 무엇을 하는가

git reset은 브랜치가 가리키는 커밋 위치를 옮기는 명령이다.

즉,

• HEAD를 움직이는 것이 아니라
• 브랜치 포인터 자체를 과거 커밋으로 이동시킨다

reset 전 상태

A --- B --- C   (main)
              ^
             HEAD

reset 후 상태

A --- B   (main)
          ^
         HEAD

C 커밋이 “사라진 것처럼” 보이지만, 정확히 말하면 main 브랜치가 B로 이동한 것이다.

4. reset을 하면 왜 HEAD도 같이 이동할까?

HEAD는 항상 “현재 체크아웃된 브랜치”를 따라간다.

• HEAD → main
• main이 가리키는 커밋이 바뀌면
• 결과적으로 HEAD 기준 커밋도 바뀐다

그래서 reset 결과를 보면 “HEAD가 이동한 것처럼” 느껴지는 것이다.

5. git checkout과의 차이

많이 헷갈리는 부분이라 같이 정리해본다.

git reset

• 브랜치 포인터를 이동시킨다
• 브랜치 기준 자체가 바뀐다
• 히스토리를 되돌리는 느낌

git checkout

• HEAD를 다른 브랜치나 커밋으로 이동시킨다
• 브랜치는 그대로 둔다

checkout으로 커밋을 직접 찍는 경우

HEAD -> C
main -> D

이 상태를 Detached HEAD 상태라고 부른다.

이 상태에서 커밋을 만들면 브랜치에 연결되지 않은 “떠 있는 커밋”이 되기 때문에 주의가 필요하다.

6. 이 개념이 중요한 이유

이 구조를 이해하면 다음이 명확해진다.

• 왜 reset을 하면 커밋이 사라진 것처럼 보이는지
• 왜 checkout으로 과거 커밋을 보면 경고가 뜨는지
• 왜 브랜치를 기준으로 작업하는 것이 중요한지

Git은 결국 “포인터를 어디로 옮기느냐”의 문제다.

7. 한 번에 정리

Git LFS(Git Large File Storage)를 프로젝트에 적용할 때 기본적으로 필요한 명령어들을 가장 깔끔한 흐름대로 정리해준다.

1. LFS 설치(처음 한 번만)

git lfs install

2. 특정 확장자를 LFS로 관리(예: *.psd, *.png 등)

git lfs track "*.psd"
git lfs track "*.png"
git lfs track "*.uasset"
git lfs track "*.umap"

Unreal Engine 프로젝트라면 보통 이렇게:

git lfs track "*.uasset"
git lfs track "*.umap"

3. .gitattributes 확인

위 명령을 실행하면 자동으로 아래처럼 .gitattributes가 생성·수정된다.

cat .gitattributes

4. 변경 사항 커밋

git add .gitattributes
git commit -m "Add Git LFS tracking"

5. 기존 대용량 파일을 LFS로 전환(옵션)

이미 커밋된 파일을 LFS로 옮기려면:

git lfs migrate import --include="*.uasset,*.umap"

6. 정상 작동 확인

git lfs ls-files

Unreal Engine 프로젝트용 추천 설정 요약

git lfs install
git lfs track "*.uasset"
git lfs track "*.umap"
git add .gitattributes
git commit -m "Setup LFS for Unreal Engine"

필요하면 추가로 사용하는 확장자도 LFS에 넣으면 된다.

1. 시간복잡도가 필요한 이유

• 실제 실행 시간은 컴퓨터 성능, CPU 상태, 운영체제 등 환경에 따라 달라진다.
• 하지만 알고리즘의 ‘성능’을 비교하려면 환경에 영향을 받지 않는 공통 기준이 필요하다.
• 그래서 입력 크기가 커질 때 시간이 증가하는 패턴을 기준으로 알고리즘을 비교한다.

2. Big-O 표기법(O 표기법)

가장 많이 쓰는 시간복잡도 표기법이며, 가장 빠르게 증가하는 항만 남기고 나머지는 버린 형태로 표현한다.

3. 시간복잡도 직관적으로 이해하기

O(1)

입력 크기와 상관없이 항상 일정한 시간.

int x = arr[5];   // 배열 인덱싱

O(N)

입력 크기만큼 작업 반복.

for (int i = 0; i < N; i++) { ... }

O(N²)

N이 커질수록 작업량이 기하급수적으로 증가. 이중 반복문이 대표적.

for (int i = 0; i < N; i++) {
    for (int j = 0; j < N; j++) { ... }
}

O(log N)

전체 범위를 절반씩 줄여가며 탐색. 이진 탐색(Binary Search) 등이 여기에 해당.

O(N log N)

정렬 알고리즘에서 자주 등장하며, 효율적인 알고리즘의 기준값으로 여겨진다.

4. 시간복잡도 계산 기본 공식

1) 가장 많이 반복되는 부분에 집중

전체 시간에서 가장 큰 영향을 미치는 부분만 고려한다.

2) 상수는 버린다

예: O(2N) → O(N)

3) 가장 큰 차수만 남긴다

예: O(N² + N) → O(N²)

5. 실전 예제

예제 1. 이중 반복문

for (int i = 0; i < N; i++) {
    for (int j = 0; j < N; j++) {
        cout << i << j << endl;
    }
}

반복 횟수: N × N = N² 시간복잡도: O(N²)

예제 2. 절반씩 줄이는 반복

int x = N;
while (x > 1) {
    x /= 2;
}

반복 횟수: log₂(N) 시간복잡도: O(log N)

6. 왜 시간복잡도를 알아야 할까?

• 코드가 입력 크기 증가에 버틸 수 있는지 판단할 수 있다.
• 최적화된 게임 엔진, 서버, 데이터 처리 시스템 개발에서 필수.
• C++, Unreal Engine처럼 성능이 중요한 분야에서는 더욱 중요.

정리

• 시간복잡도 = 입력 크기(N)에 따라 증가하는 연산량을 수학적으로 표현한 것
• 가장 중요한 개념은 Big-O 표기법
• 목표는 빠른 알고리즘, 즉 성능 좋은 코드 구조를 만드는 것

1. LSP가 말하고 싶은 핵심 한 줄

부모 타입에 자식 타입을 넣어도 아무 문제 없이 동작해야 한다.
즉, 부모가 기대하는 행동을 자식도 반드시 지켜야 한다.

2. 왜 이런 원칙이 필요할까?

상속은 코드 재사용에 좋지만, 잘못 쓰면 구조가 엉망이 된다.
특히 자식 클래스가 부모 클래스의 약속을 깨버리면, 다음과 같은 문제가 생긴다.

• 부모를 기준으로 작성된 코드가 예측대로 작동하지 않음
• 자식 클래스가 부모의 일부 기능을 무너뜨림
• 유지보수 시 “왜 이 코드가 여기서 깨지지?” 하는 상황 발생

LSP는 이런 상황을 방지하기 위한 기준이다.

3. 대표적인 잘못된 예 – 직사각형(Rectangle) vs 정사각형(Square)

고전적인 예제로 많이 나오는 케이스다.

class Rectangle {
public:
    virtual void SetWidth(int w) { width = w; }
    virtual void SetHeight(int h) { height = h; }

protected:
    int width, height;
};

class Square : public Rectangle {
public:
    void SetWidth(int w) override {
        width = height = w;
    }
    void SetHeight(int h) override {
        width = height = h;
    }
};

문제는 부모를 기준으로 코드가 작성되어 있을 때 발생한다.

void ResizeTo(Rectangle& rect) {
    rect.SetWidth(10);
    rect.SetHeight(20);

    // Rectangle이라면 width=10, height=20을 기대하지만,
    // Square가 들어오면 width=20, height=20이 되어버린다.
}

정사각형은 직사각형의 규칙(가로와 세로가 독립적)을 지킬 수 없으므로 상속 관계 자체가 잘못된 것이다. LSP를 지키지 않은 대표적 사례.

4. LSP를 지키기 위한 실제 기준

1) 부모의 기능을 약화시키거나 제한하면 안 된다

예: 부모 함수는 아무 때나 SetWidth 가능하지만, 자식에서 “특정 조건에서만 가능하다”고 바꾼다면 LSP 위반이다.

2) 부모의 기대 행동을 깨면 안 된다

예: 부모의 Move()는 1m 이동인데 자식이 Move()를 2m 이동하게 만들면 안 된다.

3) 예외를 더 많이 던져도 안 된다

부모는 정상 실행인데 자식은 자꾸 예외를 던지면 부모의 계약을 위반한 것이다.

4) 부모의 입력/출력 타입을 바꾸면 안 된다

부모는 int를 받는데 자식은 float만 받는 식으로 바꿔버리면 완전히 어긋난다.

5. 게임 개발·언리얼 기준으로 본 LSP 예시

잘못된 예

class AWeapon {
public:
    virtual void Attack() { /* 기본 공격 */ }
};

class ABow : public AWeapon {
public:
    void Attack() override {
        // 조건: 무조건 화살이 있어야만 Attack 가능
        // 부모는 조건 없이 Attack 가능한데 자식이 제한 조건을 추가함
    }
};

부모 기준으로 Attack()은 어떤 상황에서도 실행되리라 기대하지만, 자식이 자기 마음대로 조건을 추가하면 부모를 치환했을 때 코드가 깨진다.

올바른 수정 방향

• SetArrowCount(), CanShoot() 같은 검증은 Attack() 바깥에서 처리한다.
• 혹은 Weapon → RangedWeapon → Bow 같은 구조로 레벨을 나눈다.

6. 결국 LSP가 지키려는 것

LSP는 “상속을 설계할 때 최소한의 약속을 지키도록 강제하는 원칙”이다.

정리하면 다음과 같다.

• 상속은 단순히 코드 재사용 목적이 아니다
• 부모의 규칙을 자식이 지키지 못한다면 상속 관계를 다시 생각해야 한다
• 자식 객체를 부모처럼 다뤄도 프로그램이 정상 동작해야 한다

이 기준만 지켜도 클래스 구조가 훨씬 견고해진다.

7. LSP 정리 한 문장

상속 관계라면 “부모처럼 행동할 수 있는가?”를 반드시 확인해야 한다.

끝

SOLID 중 LSP는 실제로 상속 설계할 때 가장 자주 깨지는 원칙이기도 하다.

C++에서 void 함수는 언제 쓰는가?

한 줄 요약

결과값을 돌려줄 필요가 없을 때 쓰는 함수가 void 함수다.
즉, "일만 하고 끝나는 함수".

void 함수가 필요한 순간

함수를 만들 때는 보통 두 가지 경우가 있다.

1. 행동(Action)을 수행하는 함수
2. 값(Value)을 계산해서 돌려주는 함수

여기서 기준은 간단하다.

• 값이 필요 없다 → void
• 값을 받아서 써야 한다 → void 아님 (int, float, bool 등)

간단 예시로 이해하기

1) 행동만 하고 끝나는 함수 → void

void PrintHello()
{
    cout << "Hello!" << endl;
}

• 화면 출력이라는 행동만 하고 끝.
• 호출한 쪽에서 받아야 할 값이 없음.

사용:

PrintHello();   // 실행만 하면 됨

2) 계산한 값을 받아야 하는 함수 → void 아님

int Add(int x, int y)
{
    return x + y;
}

사용:

int result = Add(2, 3);
// result에 5가 담김

값이 필요하기 때문에 절대 void일 수 없음.

언리얼 스타일 예시

문 여는 함수 → void

void OpenDoor()
{
    PlayDoorOpenAnimation();
    bIsOpen = true;
}

호출하는 쪽에서는 단지:

OpenDoor();

• 문을 열라는 “행동”만 필요
• 문이 열린 후 어떤 숫자나 값이 필요한 것은 아님 그래서 void.

void인지 아닌지 판단하는 기준(매우 중요)

함수 하나 만들기 전에 아래 두 가지를 자신에게 물어보자.

1. “이 함수가 만든 값을 호출한 쪽에서 바로 써야 하나?” → 예: void 쓰면 안 됨. (반환 타입을 int, float, bool, struct, FVector, AActor* 등으로 지정)

2. “그냥 이 함수가 어떤 행동만 하면 되고, 결과값은 필요 없나?” → 예: 이때가 바로 void.

한 줄 정리

• 결과값이 필요 없다 → void
• 결과값이 필요하다 → void 말고 그 값의 타입

잘못 설계된 void 예시

값을 계산해놓고 반환하지 않으면 이런 문제가 생긴다.

void MakeDamage(int Base, float Rate)
{
    int Damage = Base * Rate; // 계산함
    // 하지만 아무것도 돌려주지 않음
}

이러면 호출하는 쪽은 Damage를 쓸 수 없음.

개선 버전:

int MakeDamage(int Base, float Rate)
{
    return Base * Rate;
}

마무리

정리하면 정말 간단하다.

• 돌려줄 값이 없으면 void
• 돌려줄 값이 있으면 그 데이터 타입

게임 개발, 언리얼 C++에서도 이 기준 그대로 적용된다. 특히 “행동 중심” 기능(문 열기, 체력 깎기, UI 보여주기 등)은 대부분 void이고, “값 가져오기” 기능은 반환 타입이 있다.

C++에서 복사 생성자를 어떻게 구현하느냐에 따라 객체가 ‘얕게 복사’될 수도 있고 ‘깊게 복사’될 수도 있다.
특히 포인터 멤버(int*)를 가진 클래스라면 둘의 차이가 결과에 큰 영향을 준다.

1. 얕은 복사 (Shallow Copy)

개념

• 객체의 멤버 값을 그대로 복사한다.
• 포인터 멤버가 있다면 주소값만 복사한다.
• 즉, 원본 객체와 복사된 객체가 같은 메모리(data)를 공유하게 된다.
• 그래서 하나를 수정하면 둘 다 값이 변한다.

예시 코드

class MyArray {
public:
    int size;
    int* data;

    MyArray(int size) {
        this->size = size;
        data = new int[size];
    }

    // 얕은 복사 생성자
    MyArray(const MyArray& other) {
        this->size = other.size;
        this->data = other.data;   // 주소값만 복사됨
    }
};

문제점

• 두 객체가 같은 data[]를 바라봄 → 의도치 않은 변화 발생
• 하나가 소멸되며 delete[] 호출 시 → 다른 객체는 댕글링 포인터(dangling pointer)가 됨

2. 깊은 복사 (Deep Copy)

개념

• 객체가 가진 모든 데이터 자체를 새로 복사한다.
• 포인터 멤버가 있을 경우 → 새로운 메모리(new)를 만들고 → 원본 배열의 내용을 하나씩 복사한다.
• 복사된 객체는 완전히 독립적인 메모리를 가진다.

예시 코드

class MyArray {
public:
    int size;
    int* data;

    MyArray(int size) {
        this->size = size;
        data = new int[size];
    }

    ~MyArray() {
        delete[] data;
    }

    // 깊은 복사 생성자
    MyArray(const MyArray& other) {
        this->size = other.size;
        this->data = new int[size];      // 새 메모리 확보

        for (int i = 0; i < size; i++) {
            this->data[i] = other.data[i];   // 데이터 자체 복사
        }
    }
};

장점

• 복사된 객체는 원본과 완전히 분리된다.
• 서로 영향을 주지 않는다.
• 소멸자에서도 각자 자기 메모리만 관리하면 된다.

핵심 차이 요약

결론

• 포인터나 동적 메모리를 가진 클래스라면 거의 무조건 깊은 복사를 구현해야 한다.
• 얕은 복사는 매우 위험하고, 특별한 목적이 있는 경우에만 사용한다.

업캐스팅 (Upcasting)

자식 → 부모로 변환하는 것. 항상 안전하고, 자동으로 변환된다.

왜 안전할까?

자식 클래스는 부모 클래스의 기능을 모두 포함하고 있기 때문에
부모 포인터로 바라봐도 문제가 생기지 않는다.

일반 C++ 예시

class A {};
class B : public A {};

B* Child = new B();
A* Parent = Child;  // 업캐스팅 (자동)

Unreal C++ 예시

AMyCharacter* MyChar = GetWorld()->SpawnActor<AMyCharacter>();
AActor* ActorPtr = MyChar;  // 업캐스팅

업캐스팅의 특징

• 자동 변환
• 안전함
• 포인터/참조에서만 의미 있음
• 값으로 변환하면 slicing(잘림) 현상 발생

다운캐스팅 (Downcasting)

부모 → 자식으로 변환하는 것. 항상 위험하며, 반드시 체크해야 한다.

부모 포인터가 실제로 자식 객체를 가리키는지 확신할 수 없기 때문.

일반 C++ 예시

A* Parent = new B();  
B* Child = static_cast<B*>(Parent); // 위험

Unreal에서는 Cast<> 사용 (안전!)

AActor* ActorPtr = GetSomeActor();

AMyCharacter* MyChar = Cast<AMyCharacter>(ActorPtr);

if (MyChar)
{
    // 캐스팅 성공 → ActorPtr이 실제로 AMyCharacter임
}
else
{
    // 캐스팅 실패 → 타입이 다름
}

Cast<>는 실패 시 nullptr을 반환하기 때문에 엔진 크래시를 막을 수 있는 가장 안전한 다운캐스팅 방식이다.

왜 “업캐스팅은 포인터/참조에서만 한다”고 할까?

업캐스팅은 객체 자체를 바꾸는 것이 아니라 “가리키는 관점만 부모로 바꾸는 것”이기 때문이다.

B Child;
A& Ref = Child;   // 참조 업캐스팅
A* Ptr = &Child;  // 포인터 업캐스팅

반대로 값으로 바꾸면 업캐스팅이 아니라 복사 + 잘림(slicing)이 발생하므로 쓰지 않는다.

B Child;
A Parent = Child; // 잘림 발생 → 비추천

Unreal에서 자주 쓰는 캐스팅 예시

1) Overlap 이벤트에서 플레이어 판별

void OnOverlap(AActor* OtherActor)
{
    AMyCharacter* MyChar = Cast<AMyCharacter>(OtherActor);
    if (MyChar)
    {
        UE_LOG(LogTemp, Warning, TEXT("플레이어 진입!"));
    }
}

2) Actor → 특정 Component 다운캐스팅

UPrimitiveComponent* Comp = Cast<UPrimitiveComponent>(Hit.GetComponent());

3) 부모 배열에서 자식 타입 찾기

TArray<AActor*> Actors;

for (AActor* Actor : Actors)
{
    ADoorBase* Door = Cast<ADoorBase>(Actor);
    if (Door)
    {
        // Door만 골라서 동작
    }
}

정리

업캐스팅

• 자식 → 부모
• 자동 변환
• 안전함
• 포인터/참조에서만 의미 있음

다운캐스팅

• 부모 → 자식
• 위험함
• Unreal에서는 Cast<>를 꼭 사용
• 캐스팅 실패 시 nullptr로 안전하게 처리

1. 캡슐화 (Encapsulation)

┌───────────────────────┐
│       Player          │
│ ┌───────────────────┐ │
│ │   private:        │ │   ← 내부 숨김
│ │   Health = 100    │ │
│ └───────────────────┘ │
│                       │
│  public:              │
│   GetHealth()         │ ← 외부 접근 함수
│   TakeDamage()        │
└───────────────────────┘

핵심: 중요한 데이터는 감추고, 함수로만 접근하게 한다.

개념

• 데이터(변수)와 기능(함수)을 객체 내부에 묶는다.
• 중요한 데이터는 숨기고, 함수로만 접근하도록 만든다.

이유

• 데이터 보호
• 내부 구조가 바뀌어도 외부 코드가 영향을 덜 받음

예시

class Player
{
private:
    int Health;

public:
    Player() : Health(100) {}

    int GetHealth() const
    {
        return Health;
    }

    void TakeDamage(int Amount)
    {
        if (Amount < 0) return;
        Health -= Amount;
        if (Health < 0) Health = 0;
    }
};

2. 상속 (Inheritance)

       Character
    ┌────────────────┐
    │ Move()         │
    │ Jump()         │
    └────────────────┘
             ▲
             │ (is-a)
             │
    ┌────────────────┐
    │     Player     │
    │ Attack()       │ ← 자식만의 기능
    └────────────────┘

핵심: **부모 기능 물려받고, 자식은 기능을 추가 확장한다.**

개념

• 부모 클래스를 기반으로 새로운 자식 클래스를 만드는 것
• “is-a 관계”일 때 사용 예) Player is a Character

이유

• 공통 기능 재사용
• 중복 코드 감소

예시

class Character
{
public:
    void Move() {}
    void Jump() {}
};

class Player : public Character
{
public:
    void Attack() {}
};

사용:

Player P;
P.Move();
P.Attack();

3. 다형성 (Polymorphism)

    Character* Ptr
           │
           ▼
 ┌───────────────────┐
 │   Attack()        │ ← 하나의 인터페이스
 └───────────────────┘
     ▲          ▲
     │ override │ override
     │          │

┌────────────────┐ ┌────────────────┐ │ Player │ │ Enemy │ │ Attack() │ │ Attack() │ └────────────────┘ └────────────────┘

`Ptr->Attack()` 호출 시:

- Player 객체면 → Player::Attack()
- Enemy 객체면 → Enemy::Attack()

핵심: **같은 함수 이름이지만 객체 타입에 따라 동작이 다르다.**

개념

• 같은 함수 이름이지만 실제 실행되는 동작은 타입마다 다름
• virtual / override 로 구현

이유

• 다양한 객체를 같은 인터페이스로 다룰 수 있음

예시

class Character
{
public:
    virtual void Attack()
    {
        // 기본 공격
    }
};

class Player : public Character
{
public:
    void Attack() override
    {
        // 플레이어 공격
    }
};

class Enemy : public Character
{
public:
    void Attack() override
    {
        // 적 공격
    }
};

사용:

void DoAttack(Character* C)
{
    C->Attack(); // 타입별로 다르게 실행됨
}

4. 추상화 (Abstraction)

┌───────────────────────────┐
│        IWeapon             │
│  Fire() = 0 (규칙만 정의) │ ← 인터페이스
└───────────────────────────┘
▲             ▲
│ implement   │ implement
│             │
┌─────────────────┐   ┌─────────────────┐
│       Gun        │   │       Bow        │
│  Fire(): 총 발사 │   │ Fire(): 활 발사 │
└─────────────────┘   └─────────────────┘

핵심:
사용자는 Fire()만 알면 되고, 내부 구현은 몰라도 된다.

개념

• 복잡한 내부 구현은 숨기고
• 꼭 필요한 기능만 외부에 제공하는 것

이유

• 코드 단순화
• 실제 구현이 바뀌어도 외부 코드는 유지됨

예시 (순수 가상 함수)

class IWeapon
{
public:
    virtual ~IWeapon() {}
    virtual void Fire() = 0; // 반드시 구현해야 한다
};

class Gun : public IWeapon
{
public:
    void Fire() override { /* 총 발사 */ }
};

class Bow : public IWeapon
{
public:
    void Fire() override { /* 활 발사 */ }
};

사용:

void Use(IWeapon* W)
{
    W->Fire();
}

정리

• 캡슐화 → 변수 숨기고 함수로만 접근하도록 보호

• 상속 → 부모 기능 재사용, 구조적 코드 구성 가능

• 다형성 → 같은 함수 이름, 타입마다 다른 동작

• 추상화 → 핵심 기능만 공개, 복잡한 구현은 숨김

┌─────────────────────────────────────────┐
│             OOP 4대 원칙               │
├─────────────────────────────────────────┤
│ 1. Encapsulation  →  데이터 보호/은닉  │
│ 2. Inheritance     →  부모 기능 재사용 │
│ 3. Polymorphism    →  타입별 다른 동작 │
│ 4. Abstraction     →  핵심 기능만 노출 │
└─────────────────────────────────────────┘

📦 기본 명령어

🧱 파일 내용 되돌리기

• 특정 파일을 마지막 커밋 상태로 되돌리고 싶다면
  → 해당 파일 선택 → 코드 뭉치 버리기 선택

🌿 브랜치 (Branch)

브랜치란: 기존 내용을 유지한 채 새로운 내용을 추가할 때 사용
체크아웃(Checkout): 특정 브랜치(혹은 커밋)으로 돌아가기

• SourceTree에서는 브랜치 이름을 더블클릭하면 체크아웃 가능

🔀 병합 (Merge)

병합하기 1 — Fast-forward

• 헤드 브랜치에 변경 사항이 없고
• 병합 대상 브랜치가 헤드로부터 시작된 경우
  → 아주 쉽게 병합 가능

병합하기 2 — 일반 병합

• 헤드 브랜치에 새로운 커밋이 생긴 경우
  → 진짜 병합이 필요함
  충돌이 나도 겁내지 말자!

⚡ 충돌 해결하기

• 가장 중요한 점: 겁내지 말아요!
• 같은 파일을 두 커밋에서 동시에 수정했을 때 충돌 확률이 높음
• 에디터나 SourceTree를 사용해서 충돌 해결 가능

⏪ 커밋 되돌리기

1. reset 사용

• 장점: 쉬움
• 단점: 커밋이 날아감, 강제 푸시 필요

2. 브랜치 만들어 되돌리기

• 장점: 내용이 사라지지 않음
• 단점: 트리가 지저분해짐

3. revert

• 가장 정석적인 방법
• 커밋은 그대로 남고, 되돌리는 커밋이 새로 생김
• 주의: 선택한 커밋의 내용을 되돌림
• 여러 커밋을 되돌릴 경우 → 최신부터 순서대로 revert

✏️ 커밋 덮어쓰기

• commit --amend : 직전 커밋 수정
• 이미 push 했다면 push --force 필요

📥 stash (임시 저장)

• 다른 브랜치로 이동하기 전에 현재 작업 내용을 임시 저장
• 매우 유용하므로 자주 활용하자
  예)

  git stash
  git checkout other-branch
  git stash pop

[Unreal C++] 리플렉션(Reflection) 시스템 완전 정리

🎨 C++과 블루프린트를 잇는 언리얼 리플렉션 시스템 완전 정복

리플렉션(Reflection) 시스템이란?

언리얼 엔진의 리플렉션 시스템(Reflection System) 은 C++ 코드와 언리얼 엔진의 다양한 시스템(에디터, 블루프린트, 직렬화, 네트워킹 등) 간의 상호작용을 가능하게 해주는 핵심 메커니즘이다.

즉, 런타임 또는 컴파일 타임에 객체의 속성과 메서드 정보를 동적으로 접근하고 조작할 수 있도록 도와준다. 이 시스템 덕분에 C++로 작성한 코드가 엔진의 다양한 기능과 유기적으로 연결된다.

리플렉션은 주로 UPROPERTY()와 UFUNCTION() 매크로를 통해 구현되며, 언리얼 헤더 툴(UHT, Unreal Header Tool) 이 이를 분석하여 필요한 리플렉션 코드를 생성한다.

UPROPERTY()

UPROPERTY()는 클래스의 멤버 변수를 언리얼 엔진 내부 시스템에 노출시키는 매크로이다. 즉, 에디터나 블루프린트에서 해당 변수를 조작할 수 있도록 연결해주는 역할을 한다.

주요 기능

• 에디터 노출: 디자이너나 개발자가 에디터에서 직접 값을 수정할 수 있음
• 블루프린트 통합: 블루프린트에서 접근하거나 수정 가능
• 자동 직렬화: 게임 데이터를 저장/불러올 때 자동으로 직렬화되어 저장
• 가비지 컬렉션(GC) 관리: UPROPERTY로 선언된 포인터는 자동으로 참조 카운트 관리
• 메타데이터 지정: EditAnywhere, BlueprintReadWrite 등으로 편집 및 접근 권한 세부 제어 가능

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Movement")
float MoveSpeed;

이 예시는 MoveSpeed 변수를 에디터에서 수정 가능하게 하고, 블루프린트에서도 읽기/쓰기 모두 가능하도록 설정한 예시다.

추가 세부 키워드 (참고: dlemrcnd.tistory.com/96)

변수 공개 & 수정 권한

• VisibleDefaultsOnly : 인스펙터 창에서 보기만 가능
• VisibleInstanceOnly : 월드 배치에서만 보기 가능
• VisibleAnywhere : 둘 다 보기 가능
• EditDefaultsOnly : 에디터에서만 수정 가능
• EditInstanceOnly : 월드 배치에서만 수정 가능
• EditAnywhere : 둘 다 수정 가능

블루프린트 접근 권한

• BlueprintReadOnly : 블루프린트에서 읽기만 가능
• BlueprintReadWrite : 블루프린트에서 읽기 & 쓰기 가능
• BlueprintGetter, BlueprintSetter : 특정 함수로 접근/수정 지정 가능

기타 옵션

• Category : 디테일 패널의 그룹 이름 지정
• meta = (AllowPrivateAccess = "true") : private 변수라도 에디터에 노출 가능

UFUNCTION()

UFUNCTION()은 클래스의 멤버 함수를 언리얼 엔진이나 블루프린트에서 사용할 수 있도록 하는 매크로이다. 즉, 블루프린트에서 함수 호출 노드로 노출시키거나, 네트워크 동작에 활용할 수 있게 한다.

주요 기능

• 블루프린트 노출: 블루프린트 내에서 함수 호출 가능
• 네트워크 동작 정의: Server, Client, NetMulticast 등으로 네트워크 함수 지정
• 이벤트 바인딩: 특정 이벤트 발생 시 자동으로 호출되도록 설정 가능
• 메타데이터 제어: 함수의 동작 방식 및 접근성을 세밀하게 조정 가능

UFUNCTION(BlueprintCallable, Category = "Movement")
void MoveForward(float Value);

이 예시는 블루프린트에서 MoveForward() 함수를 노드로 호출할 수 있도록 만든 예시이다.

추가 세부 키워드 (참고: dlemrcnd.tistory.com/96)

• BlueprintCallable : C++ 함수를 블루프린트에서 사용 가능
• BlueprintPure : 반환값만 있고 상태 변경이 없는 함수에 적합
• UPARAM : 참조 인자를 블루프린트에 넘길 때 사용
• BlueprintImplementableEvent : C++에서 함수 원형만 선언하고, 블루프린트에서 구현
• BlueprintNativeEvent : C++에서 기본 구현 제공, 블루프린트에서 오버라이드 가능

리플렉션 시스템의 작동 원리

1. 개발자가 C++ 코드에 UCLASS, UPROPERTY, UFUNCTION 등을 작성한다.

2. 빌드 시 UHT(Unreal Header Tool) 이 코드를 스캔하고, 클래스와 속성, 함수 정보를 메타데이터 형태로 생성한다.

3. 엔진은 이 정보를 활용해:

   • 에디터 노출
   • 블루프린트 연결
   • 직렬화 및 네트워킹 을 자동 처리한다.

C++ 코드 작성
    ↓
UHT가 코드 분석 및 메타데이터 생성
    ↓
엔진이 런타임에 정보 활용 (에디터, 블루프린트, 네트워킹 등)

핵심 요약

정리

UPROPERTY()와 UFUNCTION()은 단순한 코드 장식이 아니라, 언리얼 리플렉션 시스템의 핵심적인 연결 매개체이다. 이를 통해 개발자는 C++로 작성한 코드를 엔진 내부 기능과 자연스럽게 통합시켜 더 유연하고 효율적인 워크플로우를 구축할 수 있다.

📘 한 줄 요약

언리얼 리플렉션 시스템은 C++과 엔진 내부 시스템을 연결하는 "정보 노출 메커니즘"이며, UPROPERTY()와 UFUNCTION()은 그 핵심 도구이다.

Active Tab Highlighter (1.5.1)

Better Highlights (2025.2.0)

Bracket Block (0.1.3)

CodeGlance Pro (2.0.0)

GitToolBox (600.1.12+243)

MultiHighlight (3.2.1)

UE5 애니메이션 블루프린트 템플릿 & 데이터 테이블 정리

이번 글에서는 다음 내용을 다룬다.

1. 애니메이션 블루프린트 템플릿
2. Linked Anim Graph를 통한 모듈화
3. 직업별 애니메이션 데이터 관리 (데이터 테이블)

1) AnimInstance 클래스와 애님 블루프린트 연결

• SkeletalMesh 컴포넌트 → Details > Anim Class 에 AnimBlueprint 지정 가능
• AnimBlueprint은 결국 AnimInstance를 상속한 클래스이다.

2) 변수 핀 노출

• 변수 생성

• Expose as Pin 체크 → 노드에서 핀으로 노출됨
• 다른 블루프린트에서 값을 주입해 애니메이션 계산에 활용 가능

3) Linked Anim Graph 개념

• 다른 애니메이션 블루프린트를 모듈 단위로 불러올 수 있는 기능
• 장점:
  • 애니메이션을 분리·재사용 가능
  • 직업별, 무기별, 상황별 애니메이션을 모듈화 가능

참고: Control Rig은 레벨 시퀀스에서 애니메이션 제작에 사용.
리타게팅은 다른 스켈레톤 애니메이션을 변환할 때 사용.

4) 애니메이션 템플릿 만들기

• AnimInstance를 상속받은 C++ 클래스 생성
• CoreMinimal.h 대신 GameInfo.h 포함 (공용 헤더 관리 목적)

• 모든 플레이어가 공통으로 쓸 수 있는 공용 AnimInstance 구조 설계

5) 템플릿 AnimBP와 Child AnimBP

• AnimBP를 만들 때 Template 선택 → 스켈레톤 지정이 불가능
• 즉, “애니메이션 그래프의 틀”만 정의

• 스켈레톤 지정된 일반 AnimBP와 달리 추상적인 형태

• Child AnimBP로 상속 시 Anim Graph 없음
• 대신 Linked Anim Graph 또는 Override 방식을 활용

6) 구현부/노티파이 복사

• Template AnimBP에서 복사 → Child AnimBP에 구현부, 노티파이 붙여넣기
• Child는 자체 그래프가 없으므로 Override로 맞춰준다

7) BlendSpace Player 적용

• BlendSpace Player 노드에 원하는 BlendSpace 에셋 지정
• Child AnimBP에서는 애님 그래프를 직접 작성할 수 없으므로
  • 오른쪽 패널의 Asset Override에서 블렌드 스페이스 교체 가능

• Child에서는 Anim Graph 없음
• Asset Override로 교체해야 동작

8) State Machine과 변수 세팅

• State Machine 이름을 넣어야 노드 이름이 정상 출력

• BlendSpace의 X, Y 값에 대응하는 변수 세팅

9) 애니메이션 데이터 관리

데이터를 관리하는 방법은 다양하다:

1. 데이터 에셋: 개별 오브젝트 단위 관리
2. 데이터 테이블: 구조체 기반, CSV/JSON과 연동 가능
3. 스트링 테이블: 문자열만 따로 관리할 때
4. 커브/커브 테이블: 시간 기반 값 관리 (속도, 데미지 곡선 등)

• 데이터 테이블을 만들기 위해서는 구조체(Struct) 가 필요
• MMORPG 기준: 직업별 애니메이션 데이터를 데이터 테이블로 관리

예시: FJobAnimData 구조체

USTRUCT(BlueprintType)
struct FJobAnimData : public FTableRowBase
{
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TObjectPtr<UBlendSpace> MoveBlendSpace;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TObjectPtr<UAnimMontage> AttackMontage;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FString JobName;
};

이렇게 하면 직업별 애니메이션 자산을 테이블로 쉽게 불러와서 캐릭터에 적용할 수 있다.

10) 마무리

• AnimBP 템플릿은 스켈레톤 지정 없이 애니메이션 그래프의 형식만 정의
• Child AnimBP는 Asset Override 방식으로 구체적인 애니메이션 지정
• Linked Anim Graph를 통해 애니메이션을 모듈 단위로 관리
• MMORPG 같은 구조에서는 데이터 테이블로 직업별 애니메이션 세트 관리

이 구조를 잡아두면 새로운 캐릭터/직업을 추가할 때 Anim Graph를 복잡하게 다시 짤 필요 없이, 데이터만 교체해서 확장할 수 있다.

1) 레이어 애니메이션 기본

• Base Pose: 기본 동작 (예: 달리기)
• Blend Pose: 섞어줄 모션 (예: 공격)
• Idle(가만히 있을 때)는 굳이 사용할 필요 없음

2) 캐시와 블렌드 모드

• Attack 캐시를 먼저 만든다 → 재사용 가능

• 블렌드 모드 설정

• 블렌드 모드 → 레이어 세팅에서 본(Bone) 이름 입력
• 뎁스 블렌드: 하위 본까지 적용 범위
  • Depth = 0 → 전체 적용
  • Depth = 1 → 한 단계 아래까지

3) 본 구조 이해

• 본(Bone): 캐릭터의 뼈대

• pelvis를 기준으로 모든 본이 붙어있음
• spine을 기준으로 두 다리가 붙어 있음

즉, 특정 뼈를 중심으로 Blend Pose를 적용할 수 있다.

4) 적용 예시

• spine_01을 기준으로 Blend 적용 시 → 달리면서 공격 가능
• pelvis로 하면 전신이 덮여서 공격 중 달리기가 불가능

5) 조건 분기 (MoveSpeed 활용)

• MoveSpeed > 0 → True Pose: Base Pose(달리기) + Attack 섞기
• MoveSpeed == 0 → False Pose: Attack만 출력

6) 메시 스페이스 블렌딩 & 루트 모션

• 메시 스페이스 회전 블렌드 → 메시 기준으로 회전값 섞음
• 메시 스페이스 스케일 블렌드 → 메시 기준으로 스케일 섞음
• 체크 시 공격 시 허리가 더 자연스럽게 비틀림

루트 모션

• 캐릭터가 제자리에서만 움직이는 게 아니라, 애니메이션에 포함된 실제 이동을 반영
• 켜고 끌 수 있음

• 루트 모션 활성화 → 애니메이션에서 Root Motion 추출
• 캐릭터 클래스의 Movement Component → 루트 모션 옵션 지원

루트 본 기반 블렌드 루트 모션 (가중치: Weight) 사용 가능

7) 애니메이션 레이어

• 레이어 = 함수처럼 생각하면 됨
• 인터페이스 = 다중 상속을 위한 구조

• 클래스 세팅에서 애니메이션 레이어 인터페이스 등록

• 등록 완료 확인

8) 레이어 구현

• 인터페이스를 더블클릭 → 함수처럼 구현 가능
• Attack, Locomotion, Aim 등 모듈화하여 깔끔하게 관리 가능

9) 마무리

• 레이어 애니메이션은 달리면서 공격 같은 복합 모션에서 많이 사용한다.
• Spine 기준으로 Blend를 걸면 상체/하체를 분리해서 동작 가능.
• MoveSpeed 조건, 메시 스페이스 블렌딩, 루트 모션까지 활용하면 자연스러운 전투 애니메이션 구현 가능.
• 애니메이션 레이어 인터페이스를 활용하면 재사용성과 구조화가 크게 향상된다.

UE5 Aim Offset으로 캐릭터 고개 회전 구현

1) 카메라 회전 입력 액션 생성

• IACameraRotation 입력 액션 생성

• Value Type: Axis2D(Vector2D)
• Trigger: Cumulative (누적값)

2) 마우스 축 값 매핑

• IMCGame에 MouseX, MouseY 입력축 추가
• Swizzle(YXZ)로 축 값 변환
  • X축: 마우스 좌우 (오른쪽 +1, 왼쪽 -1)
  • Y축: 마우스 상하 (위 +1, 아래 -1)

3) 입력 클래스 세팅

• Input.h → UGameInput에 변수 추가

  FVector2D mCameraRotation;
  
  

• Input.cpp에 CameraRotationAction 등록

4) 플레이어 캐릭터에 바인딩

• 캐릭터에서 키 바인딩 추가

• CameraRotationKey 함수 등록

5) 스프링암 회전 제어

• 마우스 입력값으로 스프링암 회전 제어
• 위/아래 각도는 제한을 걸어야 뒤집히지 않는다

void APlayerCharacter::CameraRotationKey(const FInputActionValue& Value)
{
    FVector2D Axis = Value.Get<FVector2D>();

    FRotator NewRot = SpringArm->GetRelativeRotation();
    NewRot.Yaw   += Axis.X;
    NewRot.Pitch += Axis.Y;
    NewRot.Pitch = FMath::Clamp(NewRot.Pitch, -80.f, 80.f); // 각도 제한

    SpringArm->SetRelativeRotation(NewRot);
}

6) AnimInstance 변수 추가

PlayerDefaultAnimInstance.h

float mAimLookUp;
float mAimSide;

void SetAimInfo(float LookUp, float Side);

• SetAimInfo에서 변수 세팅

• LookUp 범위를 -90~270에서 -180~180으로 보정

7) 마우스 회전 적용 확인

컴파일 후 플레이 → 마우스 회전이 정상 적용된다.

8) Aim Offset 생성

• Aim Offset 생성
• BlendSpace와 유사하지만, 고개 방향 전용 블렌딩 클래스

• BlendSpace처럼 축과 샘플 애니메이션 배치

• 캐릭터가 안 보이면 Preview Base Pose를 바꿔준다

9) 애님 그래프 연결

• Jump 스테이트(최종 포즈) → Aim Offset 노드 연결
• OutputPose로 연결 마무리

10) 마무리

• 입력 → 스프링암 회전 → AnimInstance 전달 → AimOffset 블렌딩 흐름

• 결과: 마우스 방향에 맞춰 캐릭터 고개가 자연스럽게 회전한다

• 확장:

  • 상체 전용 블렌딩(Layered Blend per Bone) 적용 → 이동 중에도 고개 회전 유지
  • ADS(조준) 시스템 구현 시 활용 가능

0. 올바른 타이핑 방법을 연습한다.
1. 간단한 개념을 이해한다.
2. 예제를 따라 해본다.
3. 문제가 생기면 해결한다. (문제 해결하는 과정이 핵심이다)
4. 예제를 내 맘대로 바꿔본다.

프로그래밍을 배우는 이유는 무언가를 만들고 싶어서이다.

프로그래밍 언어란?

프로그램이란 컴퓨터가 원하는 기능을 수행해 주는 것. 이를 위해서는 계산적 사고(컴퓨팅 사고) 가 필요하다.

기계어 (Machine Language)

• 0, 1 이진수를 사용한다.
• 직접 사용하는 경우는 거의 없다.

어셈블리 언어

• 기계어를 직접 쓰기 힘들어서 등장.

고수준 언어 (High-Level Languages)

• C, C++, Pascal, Java, Javascript, Perl, Python 등
• 사람이 이해하기 쉬운 문법을 사용한다.

컴파일러와 인터프리터

컴파일러 (Compiler)

• 전체 코드를 번역해 실행 파일(exe) 생성
• 실행 파일은 하드웨어에 보관되어 실행됨

인터프리터 (Interpreter)

• 실행 파일을 생성하지 않음
• 한 줄씩 읽고 바로 실행 → 실행 속도 느림
• 대표적 언어: Python

이식성 (Portability)

• OS마다 실행 파일 호환이 안 될 수 있다. (예: Windows ↔ Linux)
• 장기적으로는 가능해지고 있음.

C/C++ 언어 소개

• C++은 객체 지향 언어
• 중요한 것은 언어 기능을 다 아는 것이 아니라 쓸모있는 기능을 제대로 쓰는 것

프로그래밍 과정

1. 문제 정의 – 무엇을 만들고 싶은지, 세부 기능을 잘게 쪼갠다.
2. 해법 설계 – 어떻게 만들지 구상한다.
3. 구현 – 생각한 대로 프로그램을 작성한다.
4. 컴파일 – 코드를 기계어로 번역한다.
   
5. 링킹 – 여러 오브젝트 파일을 하나로 합친다.
   
   → 요즘은 직접 작성하는 코드보다 오픈소스를 잘 가져다 쓰는 능력이 중요하다.
6. 테스트 & 디버깅 – 실행해보고 문제를 고친다.

컴퓨터 메모리 기본 구조

• 메모리에 데이터를 저장 → CPU가 연산 → 다시 메모리에 저장
• 자주 쓰는 데이터는 캐시(Cache)에 저장해 속도를 높인다.

메모리 접근 방식

• RAM (Random Access Memory) → 주소만 알면 바로 접근 가능
• 순차 접근(테이프 방식)은 현대 컴퓨터에서 사용하지 않음

메모리 단위

• 비트(bit): 0 또는 1 (Binary Digit)
• 여러 비트가 모여 바이트, 워드 등을 구성

CPU와 메모리 통신

• 주소 버스(address bus): 데이터가 어디 있는지
• 데이터 버스(data bus): 실제 데이터
• 제어 버스(control bus): 읽기/쓰기 신호
• 이 구조 때문에 포인터(pointer) 가 존재한다.

통합개발환경(IDE) - Visual Studio

프로젝트 관리

• Location(저장 위치)을 잘 관리해야 한다.

프로젝트 생성

• Windows, Console 크게 차이 없음 (Console은 텍스트 출력용)

• Precompiled Header → 멀티플랫폼 코드에서는 사용 X (리눅스에서 컴파일 불가)

컴파일 & 링킹 과정

프로젝트 폴더 구조

• 상위 폴더 열면…
  
• Debug → obj 폴더 확인 가능

명령어 실행

• 원래는 이런 커맨드(Command) 로 실행했음

디버그 빌드 vs 릴리즈 빌드

• 디버그 빌드: 디버깅 정보 포함, 최적화 OFF → 실행 크기 큼, 속도 느림
• 릴리즈 빌드: 불필요한 정보 제거, 최적화 ON → 용량 작음, 실행 속도 빠름

통합 개발환경의 기본적인 사용법 - 윈도우즈/리눅스 Code::Blocks

Code::Blocks 다운로드

• Code::Blocks는 GCC 컴파일러를 사용하므로 별도 다운로드 필요

• 디버거(Debugger)도 함께 설치해야 함

Code::Blocks 첫 실행

• 처음 실행 시 어떤 컴파일러를 쓸지 설정해야 함
• 프로젝트 단위로 시작하는 것이 편리

• 프로젝트 이름과 경로 지정

• 빌드 모드에서 Debug/Release 설정 가능

Code::Blocks 디버깅

• 코드 실행 중 문제를 추적하고 고치는 과정 → 디버깅(Debugging)

비주얼 스튜디오 - 솔루션, 프로젝트 관리

솔루션과 프로젝트 구조

• 솔루션
  • 프로젝트1
  • 프로젝트2
  • ... ...
• 다양한 언어 혼합 가능
• 계층 구조: 솔루션(.sln) > 프로젝트 > 소스파일(.cpp, .h 등)

빌드와 실행

• 솔루션 밑에 여러 프로젝트가 있을 경우, 빌드 후 생성된 exe 및 필요한 파일들이 솔루션 디렉토리 밑으로 이동
  
• 해당 위치는 속성에서 변경 가능

실행 프로젝트 선택

• 프로젝트가 여러 개일 경우, 볼드체로 표시된 프로젝트가 실행 대상

하위 시스템 설정

• 프로젝트 우클릭 → 속성 → 링커 → 시스템 → 하위 시스템(콘솔) 설정

관리 팁

• 솔루션 파일은 직접 수정하지 말 것
• IDE에서 프로젝트 제거 → Source 폴더 삭제 → 리빌드

비주얼 스튜디오 2022 기본적인 사용법

• 메뉴: 툴 → 옵션
• F7: 컴파일 오류 확인용 "빌드만" 실행 (프로그램 실행은 안 됨)

UE5 Warrior 콤보 조건부 처리 & 블렌드 스페이스 이동 구현

1. 콤보가 되었을 때만 노티파이를 호출하는 공격 시스템
2. 블렌드 스페이스를 이용해 자연스러운 이동 애니메이션 구현

1) 콤보 조건부 노티파이

• PlayerDefaultAnimInstance.h에 변수 추가

  bool mAttackEnable = false; // 공격 중인지
  bool mAttackCombo  = false; // 콤보 가능 여부
  

1-1) 기본 동작

• 이 상태에서는 공격 1회만 가능하다.

• PlayerDefaultAnimInstance.cpp에도 초기값을 false로 세팅한다.

1-2) 콤보 활성화 로직

콤보를 허용하면

• else if로 콤보 공격 처리:

  • mAttackSectionIndex 증가
  • 배열 개수에 맞게 모듈러 연산
  • 다음 섹션으로 Jump
  • mAttackCombo = false;

1-3) 몽타주 종료 시 처리

몽타주 종료 시 mAttackCombo = false;

컴파일 후 실행 → 정상적으로 자동 콤보 동작 확인

• 모션 갯수가 달라도 배열 크기에 맞춰 자동 반복 가능

2) 이동 중 공격 개선 방안

현재 문제: 이동하면서 공격 모션이 부자연스럽다. 해결 방법은 두 가지:

1. 공격 시 이동 중지
2. 하체는 이동, 상체는 공격 (Layered Blend Per Bone)

3) 블렌드 스페이스로 자연스러운 이동 구현

현재는 Run 애니메이션만 사용해서 모든 방향이 앞으로 달리는 모션만 나온다. → Kwang 모션에는 방향별 모션이 있으니 블렌드 스페이스로 묶어주자.

3-1) 블렌드 스페이스 생성

• BlendSpace1D: 축 1개
• BlendSpace: 축 2개

BSWarriorIdleAndRun 블렌드 스페이스 생성 (스켈레톤 지정)

3-2) 블렌드 스페이스 세팅

에디터 화면

축 설정 예시

• 가로축: Dir, -180.0 ~ 180.0, 그리드 4
• 세로축: Speed, 0 ~ 600(캐릭터 최대 이동속도), 그리드 1

샘플 이름표시 가능

Ctrl 누른 상태에서 아이콘 이동 → 블렌딩 미리보기 가능

3-3) 애님 블루프린트 연결

AnimBlueprint → Locomotion 연결 해제 새 스테이트 머신 생성 → Ground Locomotion 연결

Locomotion1에 Entry → IdleAndRun 스테이트 추가

IdleAndRun 스테이트에 BSWarriorIdleAndRun 배치

3-4) C++ 변수 연동

AnimInstance에 변수 추가

UPROPERTY(VisibleAnywhere, BlueprintReadOnly)
float MoveSpeed;

UPROPERTY(VisibleAnywhere, BlueprintReadOnly)
float Dir;

PlayerCharacter.cpp → MoveKey 함수에서 방향값 계산

AnimInstance에 SetDir 함수 선언 및 정의

3-5) 애님 블루프린트 변수 세팅

컴파일 후 변수 연결 가능

변수 세팅 예시

정상 동작 확인

4) 마무리

• 공격: mAttackEnable / mAttackCombo 플래그로 콤보 노티파이를 조건부 호출

• 이동: 블렌드 스페이스로 방향+속도 기반 자연스러운 러닝 구현

• 개선 포인트

  1. 공격 중 이동은 상체/하체 분리 블렌딩으로 자연스럽게
  2. 콤보 입력은 노티파이 윈도우(AnimNotifyState)로 정확한 입력 타이밍 제어 가능

0) 라이브 코딩과 디버깅

• F5 디버깅은 실행이 꺼졌다 재시작되므로, 실행 중 수정하려면 라이브 코딩을 켠다.
• 끄는 법: 편집 > 에디터 개인설정 > 라이브 코딩 > 활성화 체크 해제

1) 공격 몽타주 생성

애니메이션 > 애니메이션 몽타주

사용할 스켈레톤 선택

AMWarriorAttack 몽타주 생성

PrimaryAttack 시리즈 애니메이션을 드래그해 배치하면, 링크되어 있으면 순차 재생된다.

2) 슬롯/그룹과 T-포즈 이슈

창 > 애님 슬롯 매니저

슬롯 추가 > Attack

세팅 후 T-포즈가 보이면

기존 섹션 이름이 Default라서 헷갈릴 수 있다 → 섹션 이름을 바꾸면 정상 재생

추가 팁

• AnimGraph에 Attack 슬롯 노드가 경로상에 없으면 몽타주가 출력되지 않는다.
• 몽타주의 슬롯 이름과 AnimGraph Slot 노드 이름이 다르면 재생되지 않는다.
• 스켈레톤이 다른 애셋을 섞으면 T-포즈가 뜬다.

3) 섹션 분할과 링크

Attack1~4 섹션 생성

섹션 링크 상태 확인

독립 재생하려면 섹션 링크를 끊는다

섹션 이름 가이드

• 간단: Attack1, Attack2, Attack3, Attack4
• 확장: Attack_Air, Attack_Down, Attack_Heavy 등 컨텍스트를 이름에 담아두면 유지보수에 유리

4) 슬롯 노드와 AnimGraph 경로

특정 슬롯의 몽타주만 재생하도록 Slot 노드를 사용한다

DefaultSlot 개념

Slot에 재생 중인 몽타주가 없으면 Source 포즈가 그대로 통과한다

AnimGraph에 Attack 슬롯 배치

같은 경로 구조라면 보이는 변화는 없을 수 있다

개선 팁

• 상체만 공격 모션, 하체는 이동 유지하려면 Slot 위에 Layered blend per bone을 배치하고 Spine_01 기준으로 분기한다.
• 몽타주가 전신을 잠식해 움직임이 딱딱해지는 문제를 줄일 수 있다.

5) AnimInstance 변수와 에디터 셋업

AttackMontage 변수 선언

클래스 디폴트에서 AMWarriorAttack 할당

입력 처리 위치 예시(엔핸스드 인풋과 연동)

APlayerCharacter.h에 NormalAttack 가상함수

cpp 기본 구현

Warrior.h 오버라이드

Warrior.cpp 구현

APlayerCharacter.cpp NormalAttack 구현 확인

핵심 포인트

• mAnimInst 타입은 UPlayerDefaultAnimInstance* 로 캐스팅해두면 멤버 함수 접근이 편하다.
• AttackMontage가 비어 있으면 재생되지 않는다.

6) PlayAttack 구현과 섹션 배열

헤더에 PlayAttack 선언

cpp 정의

AnimInstance 유효 체크

Montage_Play, Montage_JumpToSection 사용

섹션 이름 배열 + 현재 인덱스

Attack Section Name 가시화

Attack1~4 이름 지정

배열에 이름이 잘 들어간 상태

PlayAttack에서 섹션 점프

샘플 코드

// PlayerDefaultAnimInstance.h
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Attack")
TObjectPtr<UAnimMontage> AttackMontage;

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Attack")
TArray<FName> AttackSectionNames = { "Attack1","Attack2","Attack3","Attack4" };

int32 AttackIndex = 0;

UFUNCTION(BlueprintCallable) void PlayAttack();
UFUNCTION() void OnMontageEnded(UAnimMontage* Montage, bool bInterrupted);

// PlayerDefaultAnimInstance.cpp
void UPlayerDefaultAnimInstance::PlayAttack()
{
    if (!AttackMontage || AttackSectionNames.Num() == 0) return;

    if (!Montage_IsPlaying(AttackMontage))
    {
        Montage_Play(AttackMontage, 1.0f);
        Montage_JumpToSection(AttackSectionNames[AttackIndex], AttackMontage);

        FOnMontageEnded End;
        End.BindUObject(this, &UPlayerDefaultAnimInstance::OnMontageEnded);
        Montage_SetEndDelegate(End, AttackMontage);
    }
}

void UPlayerDefaultAnimInstance::OnMontageEnded(UAnimMontage* Montage, bool bInterrupted)
{
    if (!bInterrupted) AttackIndex = 0;
}

7) 이동 중 어색함과 지상 조건

이동 중 전신 몽타주가 들어오면 부자연스럽다 → 지상에서만 허용

지상 체크 예시

void APlayerCharacter::NormalAttack()
{
    if (GetCharacterMovement() && GetCharacterMovement()->IsMovingOnGround())
    {
        if (AnimInst) AnimInst->PlayAttack();
    }
}

개선 팁

• 상체 전용 Layered blend per bone + Attack Slot로 하체 이동 유지
• 몽타주 Root Motion을 쓰면 이동/회전이 함께 걸릴 수 있으니 프로젝트 목적에 맞춰 비활성/활성 결정

8) 콤보·히트 판정 노티파이

히트 타이밍과 콤보 전환 타이밍이 필요

애니메이션 더블클릭으로 타임라인 열기

공격판정 노티파이 Attack 생성

무기 스윙 위치에 충돌체 또는 트레이스 적용 권장

AttackCombo 노티파이도 각 섹션에 배치

몽타주 종료 콜백 함수 선언

cpp 정의

MontageEnd 호출 시점

Interrupted true/false 의미

AnimNotify 함수 선언

cpp 구현

노티파이 샘플

// PlayerDefaultAnimInstance.h
UFUNCTION() void AnimNotify_Attack();      // 히트 판정
UFUNCTION() void AnimNotify_AttackCombo(); // 콤보 인덱스 증가

// PlayerDefaultAnimInstance.cpp
void UPlayerDefaultAnimInstance::AnimNotify_Attack()
{
    // 무기 소켓 경로로 짧은 스윙 트레이스 추천
    // UKismetSystemLibrary::SphereTraceMultiForObjects(...) 등
}

void UPlayerDefaultAnimInstance::AnimNotify_AttackCombo()
{
    AttackIndex = (AttackIndex + 1) % AttackSectionNames.Num();
}

고급 팁

• 입력 타이밍을 통제하려면 노티파이 대신 노티파이 윈도우(AnimNotifyState)로 콤보 입력 가능 구간을 열고 닫는다.
• 사용자가 콤보 키를 해당 구간에 입력하면 다음 섹션을 Montage_SetNextSection으로 자연스럽게 이어줄 수 있다.

9) 입력 시스템 연결(엔핸스드 인풋)

기본 흐름

• 프로젝트 시작 시 EnhancedInputLocalPlayerSubsystem에 IMC(매핑 컨텍스트) 추가
• IA_Attack을 액션으로 만들고 캐릭터에서 바인딩
• 바인딩된 함수에서 NormalAttack 호출

예시

void APlayerCharacter::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent)
{
    if (UEnhancedInputComponent* EIC = Cast<UEnhancedInputComponent>(PlayerInputComponent))
    {
        EIC->BindAction(IA_Attack, ETriggerEvent::Started, this, &APlayerCharacter::Attackkey);
    }
}

void APlayerCharacter::Attackkey(const FInputActionValue& Value)
{
    UE_LOG(LogTemp, Log, TEXT("Attackkey Enter"));
    NormalAttack();
}

10) Super 호출은 언제 필요한가

문제 상황 요약

• Warrior에서 Super::NormalAttack();를 호출하니 동작했고, 호출하지 않으면 동작하지 않았다.

이유

• 현재 설계에서 부모 APlayerCharacter의 NormalAttack()이 실제 재생 로직(mAnimInst->PlayAttack())을 가지고 있다.
• 자식이 부모를 호출하지 않으면 재생 로직이 실행되지 않는다.

정리

• Super 호출은 항상 필요한 게 아니라, 부모가 필수 로직을 가지고 있을 때만 필요하다.
• 대안 1: 부모를 순수 가상 함수로 두고 재생 로직을 전부 자식이 갖는다.
• 대안 2: 재생은 AnimInstance 쪽으로만 몰고, 캐릭터 계층에서는 입력 신호 전달만 한다.

권장 구조

• 입력 → 캐릭터 → AnimInstance.PlayAttack()
• 재생의 단일 책임을 AnimInstance로 모아 테스트/유지보수 난이도를 낮춘다.

11) 유지보수 팁과 체크리스트

체크리스트

• AttackMontage 변수에 실제 몽타주 할당됐나
• AnimGraph 경로에 Attack 슬롯 노드가 있나
• 슬롯 이름이 몽타주 슬롯과 정확히 같나(대소문자 주의)
• 스켈레톤이 일치하나
• 섹션 이름 오타 없는가
• 이동 중 공격 자연스럽게 하려면 상체 전용 블렌딩을 썼나
• 루트모션을 의도대로 켜거나 껐나

성능/안정성

• 섹션 이름은 FString 대신 FName 사용
• 델리게이트 바인딩은 중복되지 않도록 관리
• ComboIndex는 범위를 모듈로 연산으로 안정화

테스트 팁

• 애님 프리뷰에서 Section Jump 미리보기
• 노티파이 타이밍은 프레임 스텝으로 미세 조정
• 디버그용 DrawDebugSphere/Line으로 히트 영역 시각화

12) 마무리

한 개의 몽타주로 4콤보를 깔끔하게 관리하려면

• 섹션을 잘게 나누고 링크는 필요할 때만
• 슬롯/AnimGraph 경로를 정확히 배치
• AnimInstance 중심의 PlayAttack, 콤보 인덱스, EndDelegate, 노티파이를 조합
• 상체 전용 블렌딩과 콤보 윈도우로 퀄리티 업