표준 C++에 리플렉션을 더하는 이유리플렉션은 실행 중인 프로그램이 자신의 타입과 멤버 구조를 조회하고 다룰 수 있는 기능입니다. 표준 C++의 타입 정보만으로는 에디터가 임의의 클래스를 읽어 디테일 패널을 만들거나, Blueprint 노드와 C++ 함수를 연결하고, 저장할 프로퍼티와 객체 참조를 일관되게 찾기 어렵습니다.Unreal은 UCLASS, UFUNCTION, UPROPERTY로 엔진에 공개할 대상을 표시하고 빌드 과정에서 필요한 코드를 생성합니다. 이렇게 등록된 정보는 에디터·Blueprint뿐 아니라 직렬화, 네트워크 복제, 기본값 관리, GC의 참조 추적에도 쓰입니다.매크로가 기능을 직접 수행하는 것이 아니라, UHT가 매크로를 단서로 엔진이 사용할 타입 정보를 생성한다는 점이 핵심입니다...

같은 목적, 다른 방식코드 한 줄을 확인할 때마다 큰 프로젝트를 다시 빌드하고 에디터를 재시작하면 반복 시간이 길어집니다. Unreal Engine과 Unity는 이 시간을 줄이기 위해 실행 중인 에디터에 변경 코드를 반영하지만, 각각 네이티브 C++와 관리형 C# 환경을 사용하므로 갱신 단위와 상태 복원 방식이 다릅니다.핵심은 “적용되었는가”뿐 아니라 “기존 객체와 런타임 상태가 새 코드와 일치하는가”까지 확인하는 것입니다.Unreal Live Coding: 네이티브 코드 패치Live Coding은 에디터 프로세스를 유지한 채 변경된 C++ 소스를 컴파일하고, 생성된 패치 모듈을 불러와 기존 함수가 새 구현을 실행하도록 메모리의 코드를 갱신합니다. 기본 단축키는 Ctrl + Alt + F11입니다.C+..

프로젝트와 문제CH2 Text RPG는 여섯 명이 C++17로 만든 콘솔 게임입니다. 플레이어는 재료 몬스터를 처치해 골드와 식재료를 얻고, 요리를 완성해 능력치를 높입니다. 일반 요리 열 개를 완성하면 궁극의 햄버거와 보스전이 열리고, 최종 요리를 만들면 엔딩에 도달합니다.개발을 시작할 때 저는 BattleManager, RecipeManager, ShopManager, UIManager 등 기능별 매니저 파일을 빈 골격으로 먼저 생성했습니다. 시스템의 경계를 파일과 클래스 단위로 제시한 뒤 팀원들이 역할에 따라 각 영역의 내부 구현을 채우는 방식으로 작업을 나눴습니다.팀원들의 구현이 모인 초기 통합본에는 각 클래스와 함수가 존재했지만, 메뉴 선택은 실제 동작으로 이어지지 않았고 전투 보상은 인벤토리에..

실행 흐름 한눈에 보기프로그램은 디스크에 저장된 명령과 데이터의 묶음입니다. 사용자가 프로그램을 실행하면 운영체제는 주소 공간과 자원을 준비해 프로세스를 만들고, 프로세스 안의 스레드를 실행 가능한 상태로 둡니다. 스케줄러가 그중 하나를 고르면 CPU가 해당 스레드의 레지스터와 프로그램 카운터를 복원하고 명령어를 실행합니다.실행 파일 → 프로세스 생성: 가상 주소 공간과 OS 자원 준비 → 스레드 준비: PC, 레지스터, 스택과 실행 상태 생성 → Ready Queue에서 대기 → Scheduler가 실행 대상 선택 → CPU가 명령어 실행 → I/O 대기·시간 할당량 만료·종료 → 필요하면 Context SwitchCPU가 직접 실행하는 흐름은 스레드입니다. 프로세스는 그 실행에 필요한 주..

서로 다른 두 종류의 병목Hazard는 한 코어 안에서 여러 명령어를 겹쳐 실행할 때 다음 단계로 진행하지 못하는 문제입니다. 반면 DMA와 Interrupt는 CPU와 입출력 장치가 일을 나누는 방법입니다. 발생 위치는 다르지만 목표는 같습니다. CPU가 불필요하게 기다리는 시간을 줄이는 것입니다.CPU 내부: 명령어 A · B · C를 겹쳐 실행 └─ 의존성이나 자원 충돌 → HazardCPU 외부: CPU가 전송 설정 → DMA가 데이터 이동 └─ 완료 → Interrupt먼저 파이프라인 안에서 무엇이 흐름을 막는지 살펴보고, 이후 장치 I/O가 CPU와 어떻게 비동기로 협력하는지 연결해 보겠습니다.파이프라인 Hazard설명..

프로그래머스 단속카메라오늘은 탐욕법을 활용하는 프로그래머스 단속카메라 문제를 풀었습니다. 각 차량은 고속도로에 진입한 지점과 진출한 지점을 가지고 있으며, 모든 차량이 최소 한 번은 단속카메라를 만나도록 카메라를 설치해야 합니다. 목표는 필요한 카메라의 최소 개수를 구하는 것입니다. 처음에는 차량의 진입 지점을 기준으로 정렬하는 방법을 생각했습니다. 하지만 진입 지점을 기준으로 보면 현재 차량과 이후 차량이 어느 지점까지 겹치는지 계속 관리해야 해서 판단이 복잡해집니다. 반대로 차량을 진출 지점 기준으로 오름차순 정렬하면 선택 기준이 명확해집니다. 아직 카메라를 만나지 않은 차량이 나오면 해당 차량의 진출 지점에 카메라를 설치합니다. 진출 지점은 해당 차량을 단속할 수 있는 가장 오른쪽 위치입니다. 따라..

문제 이해심사관마다 한 사람을 처리하는 시간이 다르고 모든 심사대는 처음에 비어 있습니다. 기다리는 n명이 어떤 심사대를 선택하든 상관없이, 전원이 심사를 마치는 데 필요한 최소 시간을 구해야 합니다.예를 들어 n = 6, times = [7, 10]이면 7분 심사대는 28분 동안 4명, 10분 심사대는 2명을 처리할 수 있으므로 답은 28분입니다.시뮬레이션이 어려운 이유가장 직관적인 방법은 각 심사대가 다음에 비는 시간을 관리하며 사람을 한 명씩 배치하는 것입니다. 하지만 사람 수가 최대 10억 명이므로 한 사람마다 작업하는 방식은 입력 상한에서 사용할 수 없습니다.답을 만드는 과정을 직접 재현하기보다, 어떤 시간 T가 답으로 충분한지 빠르게 판정할 수 있는지를 먼저 생각해야 합니다.시간을 결정 문제로..

문제 이해각 차량의 경로는 진입 지점과 진출 지점으로 이루어진 닫힌 구간 [start, end]입니다. 카메라가 구간 안에 있으면 해당 차량을 단속할 수 있으며, 진입점이나 진출점에 설치해도 포함됩니다.차량 경로: [start, end]단속 조건: start 결국 모든 구간을 적어도 한 번 찌르는 점을 최소 개수로 고르는 문제입니다. 어떤 구간을 먼저 처리하고 그 안의 어느 위치를 고를지가 핵심입니다.탐욕적 선택 찾기진출 지점이 가장 빠른 차량을 먼저 생각하면 반드시 처리해야 할 대상이 분명해집니다.이 차량은 진출 지점을 지나면 다시 만날 수 없으므로, 카메라 하나가 반드시 현재 구간 안에 있어야 합니다.구간 안에서 가장 오른쪽인 진출 지점에 설치하면 현재 차량을 단속하면서 뒤에 오는 구간과 겹칠 가능성..

프로그래머스 방의 개수오늘은 그래프를 활용하는 프로그래머스 방의 개수 문제를 풀었습니다.이동한 좌표를 정점, 좌표 사이를 이동한 경로를 간선으로 생각하면 방이 생성되는 순간을 그래프의 사이클로 판단할 수 있습니다.이미 방문한 정점에 도착하더라도 기존 간선을 다시 지나가는 경우에는 새로운 방이 생기지 않습니다. 따라서 정점의 방문 여부뿐만 아니라 간선의 방문 여부도 함께 관리해야 했습니다.또한 대각선이 교차하는 경우에는 교차점이 정수 좌표로 기록되지 않는 문제가 있었습니다. 이를 해결하기 위해 한 번의 이동을 두 번으로 나누어 좌표계를 확대했고, 대각선 교차점도 일반 정점과 동일하게 처리할 수 있었습니다.이번 문제를 통해 복잡한 영역을 직접 계산하기보다, 그래프의 정점과 간선 관계로 문제를 단순화하는 방법..

두 기법은 무엇을 버리는가이분 탐색(Binary Search)은 정렬된 배열이나 단조로운 판정 결과에서 가운데 후보를 검사하고, 정답이 존재할 수 없는 절반을 버리는 탐색 기법입니다. 탐색 공간의 크기가 N → N/2 → N/4 → ...로 줄기 때문에 판정 한 번이 O(1)이라면 전체 탐색은 O(log N)입니다.탐욕법(Greedy Algorithm)은 현재 상태에서 가장 유리하다고 정한 선택 하나를 확정하고 나머지 문제로 넘어가는 설계 기법입니다. 모든 조합을 비교하지 않으므로 빠르지만, 현재의 선택이 전체 최적해를 해치지 않는다는 근거가 반드시 필요합니다.구분이분 탐색탐욕법줄이는 것후보 값 또는 인덱스 구간남은 선택 문제핵심 전제정렬 또는 판정 결과의 단조성탐욕적 선택 속성과 최적 부분 구조핵심 ..