TIL 2026-05-20

게시 2026/05/20

By GoldBoll

33 분읽는 시간

TIL 2026-05-20

2026-05-20 CS 28·29 신규(32/64비트 OS·메모리 계층) + Ch3 프로토타입·Portal 설치·팀 코드 분석

오늘 한 일 요약

CS 28 — 32비트 vs 64비트 운영체제 신규 작성 — raw/cs-notion/28_os_32bit_vs_64bit.md. 워드 크기(레지스터·주소 버스 너비) → 가상 주소 공간(4GB vs 256TB 실효) → 포인터 크기 → 레지스터 수(x86 8개 vs x86-64 16개) → ABI/호출 규약(WoW64·Rosetta) → 게임 엔진 영향(UE5 LWC)까지 6축으로 묶어 정리. 정책대로 예상 문제 슬롯은 비워둠
CS 29 — 메모리 계층 구조 신규 작성 — raw/cs-notion/29_memory_hierarchy.md. 레지스터·L1·L2·L3·DRAM·보조 저장장치 6계층의 속도·용량·기술·전송 단위 → 포함 관계(Inclusive/Exclusive/NINE) → 캐시 일관성(MESI) → TLB → 가상 메모리·페이지 캐시·스왑 → NUMA → 게임 엔진 적용까지. 25·26·27·28번의 상위 프레임으로 자리잡음
Ch3 팀프로젝트 프로토타입 제작 — 발표 잔여 6일(2026-05-26) 기준 흐름 검증용 프로토타입. 현재까지 develop에 들어간 무기·HitReact·HUD를 한 맵에서 묶어 보고, 빈 슬롯(피격 VFX·처형 트리거·카메라 셰이크)을 시각적으로 확인
Portal 플러그인 설치 — 에디터에서 외부 자산·예제 프로젝트·레퍼런스를 직접 불러오기 위해 Epic Games Launcher 경유로 Portal 활성화. 팀 작업 시 동일 환경 보장 목적
팀 코드 분석 — 어제 develop에 들어간 PR #32(feat/Player 무기 에셋)·PR #33(feat/system-HUD)의 변경 범위를 읽고 인터페이스 영향 정리. 의심2 패치(HitStopTimers 멤버 맵) 진입 전에 rebase 충돌 가능성을 미리 살펴봄

미해결 — 히트스톱 의심2 패치(헤더 변경 동반 별도 PR) 여전히 이월, PIE 검증·24번 정밀도 보강·graphify CS 풀 빌드(26·27·28·29번 일괄)·Bootcamp-TIL 미커밋 정리까지 줄줄이 이월.

작업 환경

CS 자료(본 레포) — 신규 2개
- raw/cs-notion/28_os_32bit_vs_64bit.md (워드/주소공간/ABI/ISA)
- raw/cs-notion/29_memory_hierarchy.md (6계층 + TLB·MESI·NUMA)
외부 프로젝트 — D:\Unreal\8th-Team11-CH3-Project (Ch3 팀플, 발표 2026-05-26 잔여 6일)
외부 분석 대상 — develop 최신(PR #32·#33·#34 동시 머지 이후)의 Source/.../Private/Player/·Source/.../Private/UI/·Source/.../Private/Combat/
Portal — Epic Games Launcher에서 활성화. UE5 에디터 내에서 마켓플레이스·예제 자산을 직접 가져오는 경로

1. CS 28 — 32비트 vs 64비트 운영체제 신규 작성

raw/cs-notion/28_os_32bit_vs_64bit.md 신규. 다음 모의면접 주제 — “32비트 운영체제와 64비트 운영체제의 가장 큰 차이점은 무엇인가요?”

작성 의도 — 10·11번을 묶는 “시스템 폭”이라는 큰 그림

10번에서 “포인터 크기는 주소 공간에 따라 결정된다 — 32비트는 4바이트, 64비트는 8바이트”를 짚었고, 11번에서 가상 주소 공간을 다뤘다. 28번은 이 단편적 사실들을 “비트 수가 CPU 레지스터·주소 버스·ALU·가상 주소 공간·포인터 크기·호출 규약을 한꺼번에 결정하는 시스템 폭(system width)” 이라는 한 그림으로 묶는 자리.

면접에서 “가장 큰 차이”를 묻는 의도는 보통 4GB 한계 vs 사실상 무제한과 그 파급 효과. 거기서 멈추면 단순 암기로 보이니까, 그 한계가 왜 생기고, 어떤 연쇄 효과를 일으키는지를 풀어내는 것이 답변 깊이를 만든다.

핵심 골격 — 6축으로 묶기

축	32비트	64비트
가상 주소 공간	2³² = 4GB (사용자 공간 2~3GB)	2⁴⁸ = 256TB 실효 (5-level paging은 2⁵⁷ = 128PB)
포인터·`size_t`·`intptr_t`	4바이트	8바이트 (`int`는 LP64/LLP64 모델에서 그대로 4바이트)
범용 정수 레지스터	8개 × 32비트 (EAX~ESP)	16개 × 64비트 (RAX~R15)
XMM(SSE) 레지스터	8개	16개
호출 규약	`__cdecl`은 인자 전부 스택	Win64: RCX·RDX·R8·R9 + XMM0~3 / Sys V: RDI·RSI·RDX·RCX·R8·R9 6개
메모리 모델	PAE로 물리 36비트 늘려도 한 프로세스는 4GB	단일 평탄 256TB, `mmap`·메모리 매핑 자유

이 표가 본문의 중심축. 각 행은 단일 비트 수 결정이 일으키는 연쇄 효과의 단편을 보여준다.

면접 답변에서 가장 신경 쓴 한 줄

“비트 수”는 단순히 한 번에 처리하는 비트 수가 아니라, CPU 레지스터·주소 버스·ALU·가상 주소 공간·포인터 크기·호출 규약을 한꺼번에 결정하는 시스템 폭(system width)입니다.

이걸 답변 초반에 깔아두면 — 뒤따라오는 6축이 전부 이 한 줄의 구체화라는 게 자연스럽게 이어진다. 면접관 입장에선 “왜 이렇게 많은 축이 한 번에 바뀌는가”의 답을 첫 문장에서 듣는 셈.

또 하나 — 트레이드오프 한 줄도 빼먹지 않았다. “64비트가 단순히 더 좋다”가 아니라 포인터 크기 두 배 → 같은 자료구조의 L1 hit rate 하락이라는 비용을 짚어야 균형 잡힌 답변. V8 JavaScript 엔진의 Compressed OOPs·JVM의 포인터 압축이 이 비용을 피하려는 사례.

27번 단편화와의 연결고리

28번에서 굳이 27번과 잇는 한 줄은 — “32비트의 4GB 가상 주소 공간 협소가 외부 단편화 압박을 키운다”. 64비트는 큰 블록이 부족해도 다른 위치를 잡으면 그만이지만, 32비트는 4GB 안에서 큰 free 블록을 못 찾으면 그대로 OOM. 그래서 32비트 시대의 게임 엔진·DB 엔진이 자체 메모리 풀과 메모리 매핑 우회를 적극적으로 썼던 배경.

이 한 줄로 27번과 28번이 따로 노는 주제가 아니라 같은 문제(메모리 자원의 부족)의 다른 측면이라는 게 분명해진다.

2. CS 29 — 메모리 계층 구조 신규 작성

raw/cs-notion/29_memory_hierarchy.md 신규. 다음 모의면접 주제 — “컴퓨터의 메모리 계층 구조에 대해서 설명해 주세요”

작성 의도 — 25·26·27·28번의 상위 프레임

25번(캐시 히트/미스)·26번(페이지 폴트)·27번(메모리 단편화)·28번(32/64비트 OS)이 전부 메모리 계층의 어느 한 부분을 다룬 거였다면, 29번은 그 모두를 한 그림으로 묶는 상위 프레임. 작성하면서 가장 의식한 건 — “모든 메모리 최적화는 이 계층의 비용 차이를 이용한다” 가 마무리 한 줄.

6계층 표 — 본문 중심축

계층	접근 시간	용량	기술	코어별
레지스터	<1 cycle (~0.3ns)	16개 GPR × 8B = 128B / 코어	SRAM	전용
L1 (D+I)	약 4 cycles (~1ns)	32+32 ~ 64+64 KB / 코어	SRAM	전용
L2	약 12 cycles (~3ns)	256KB ~ 2MB / 코어	SRAM	전용
L3 (LLC)	약 40 cycles (~10ns)	4 ~ 64MB / 소켓	SRAM	공유
DRAM (DDR4/5)	약 200~300 cycles (~70ns)	8 ~ 256GB	DRAM	공유
NVMe SSD	~100µs	256GB ~ 4TB	NAND Flash	공유
HDD	~10ms	1 ~ 20TB	자기 디스크	공유
테이프	수십 초 ~ 분	수십 TB ~ PB	자기 테이프	아카이브

인접 계층 간 속도·용량·가격 비율이 대체로 10~100배. 이 한 장이 답변에서 가장 강한 시각적 정박점이 된다.

지역성이 계층을 떠받친다는 한 줄

메모리 계층은 “이상적인 메모리(빠르고·크고·싼)가 물리적으로 불가능하기 때문에 만들어진 절충안”. 이게 동작하는 이유는 단 하나 — 지역성(Locality).

이상적 메모리는 SRAM·DRAM·NAND가 동시에 만족시킬 수 없는 제약 조합(빠름·큼·싸다). 그래서 여러 계층을 쌓아 평균적으로 빠르고 평균적으로 크게 만든 절충안이 메모리 계층. 이게 통하는 통계적 토대가 시간 지역성(루프 변수·반복 호출) + 공간 지역성(배열 순회·구조체 필드 연속 접근).

답변에서 한 가지 꼭 짚은 것 — L1 hit rate가 95% 이상으로 유지되는 통계 덕분에 평균 메모리 접근 시간이 거의 L1 수준으로 수렴한다는 점. 이 한 줄이 “왜 캐시가 이렇게 작아도 통하는가”의 답.

TLB·캐시 일관성·NUMA — 답변 깊이를 만드는 3개의 측면 축

본 계층(레지스터→L1→L2→L3→DRAM→SSD/HDD) 위에 답변 깊이를 더하는 3개의 측면 축을 따로 묶었다.

TLB(Translation Lookaside Buffer) — 가상→물리 주소 변환 캐시. 64~512 엔트리로 작지만 hit는 거의 0 cycle, miss면 페이지 테이블 walk로 수십 cycles. 캐시 계층과 별개로 동작하는 주소 변환 계층
캐시 일관성(MESI) — 멀티코어에서 같은 메모리 주소를 여러 코어가 캐시할 때 Modified·Exclusive·Shared·Invalid 상태로 일관성 유지. false sharing으로 성능이 수십 배 떨어지는 게 이 비용의 가장 흔한 표면화
NUMA(Non-Uniform Memory Access) — 멀티 소켓에서 로컬 DRAM(100ns) vs 원격 DRAM(200~300ns). NUMA-aware 스케줄링이 서버 성능에 직접 영향

이 3개 축이 답변에 있으면 “기본 6계층만 외운 사람”과 “메모리 시스템 전체 구조를 본 사람”의 차이가 분명해진다.

작성 정책에 따라 예상 문제 슬롯은 비워둠. 이론·꼬리질문 대비까지만.

3. Ch3 팀프로젝트 프로토타입 제작

목적 — 발표 6일 전, 완성도보다 흐름 검증이 먼저

발표 잔여 6일이라는 시점에서 가장 위험한 건 — 각 컴포넌트는 동작하는데 전체 흐름이 어색한 상태로 발표일을 맞는 것. 그래서 의심2 패치 같은 단일 기능을 더 다듬기 전에, 현재 develop에 들어간 모든 부분을 한 맵에 묶어 실제 플레이 동선을 먼저 확인하기로 했다.

PR #32(무기 에셋)·PR #33(HUD)·PR #34(라그돌·히트스톱 안정성)가 어제 동시에 develop에 들어갔으니까, 세 PR이 충돌 없이 한 빌드에서 같이 동작하는지부터 검증할 필요. 프로토타입의 의미는 “완성품의 축소판”이 아니라 “현재까지의 합이 발표 시나리오에 충분한가” 를 묻는 도구.

확인한 동선과 부족 지점

플레이 동선을 처음부터 끝까지 한번 굴리면서, 발표 시 시연하게 될 흐름이 어디서 끊기는지 확인 ——

시연 단계	현재 상태	부족 지점
무기 장착·전환	PR #32 무기 에셋 정상	—
사격 → 라그돌	PR #34로 안정. 가슴/옆구리 사격해도 본별 자식 폴백	—
히트스톱 슬로우	단발은 의도대로. 연사 시 약함(의심2)	의심2 패치 미적용
피격 VFX(파티클·머티리얼·데칼)	미구현	발표 임팩트 직격
처형 트리거	미구현	HealthComponent::OnHealthThreshold 델리게이트 검토 필요
카메라 셰이크(무기 분기)	1차만, 두 번째 + 무기 분기 통합 미완	RangedCameraShake / WeaponConfig::TSubclassOf 설계
HUD HP 갱신	PR #33 골격은 있음	OnHealthDamaged 구독 위젯 결선 필요

프로토타입을 굴려보니 — 시각 피드백(피격 VFX·처형 컷·카메라 셰이크) 3종이 발표 임팩트의 핵심이고, 의심2 슬로우 약화는 발표 시 카메라 워크로 어느 정도 가려진다는 게 명확해졌다. 우선순위 재조정의 근거가 잡힘.

4. Portal 플러그인 설치

도입 배경 — 자산·레퍼런스 관리를 에디터 안에서 통일

UE5의 마켓플레이스·예제 프로젝트·러닝 콘텐츠를 에디터 안에서 바로 가져오기 위해 Portal 활성화. 발표 6일 전 시점에 피격 VFX·처형 컷 관련 레퍼런스를 빠르게 훑고 일부 자산을 가져오는 워크플로우가 필요한 게 직접적인 도입 이유.

팀 작업 환경에서는 — 팀원마다 외부 자산 가져오는 경로가 다르면 에셋 경로·종속성이 어긋날 수 있어서, Portal로 경로를 통일하면 빌드·쿡 단계의 불필요한 누락이 줄어든다.

설치 흐름 — Epic Games Launcher 경로

Epic Games Launcher
  └─ Unreal Engine
     └─ Library 탭
        └─ 해당 엔진 버전(5.x) 옆 톱니바퀴
           └─ Marketplace → Vault 동기화

활성화 후 에디터에서 Edit > Plugins로 들어가 Marketplace·LauncherPlatform 등 Portal 관련 플러그인이 Enabled 상태인지 확인. 비활성화 상태였다면 체크하고 에디터 재시작.

활성화 후 확인 포인트

에디터 안에서 Marketplace 직접 접근 — Window > Get Content 또는 메인 툴바의 Add 버튼을 통해 외부 자산을 현재 프로젝트로 바로 import 가능한 상태인지 확인
자산 경로 일관성 — 가져온 자산이 Content/Marketplace/<자산명>/처럼 표준 경로에 떨어지는지 확인. 팀원과 경로가 달라지면 GitHub LFS 추적 누락·.uasset 경로 깨짐의 원인이 됨
종속 플러그인 활성화 여부 — Niagara·Chaos·EnhancedInput 등 마켓플레이스 자산이 요구하는 플러그인 자동 활성화 알림에 주의. 팀원 환경과 분기되지 않도록 활성화 후 .uproject diff를 확인

이번엔 자산을 직접 가져오는 것보다 경로를 준비해 두는 단계까지만 진행. 실제 VFX·처형 자산 다운로드는 내일 이후 작업.

5. 팀 코드 분석 — develop 변경분 파악

분석 대상 — PR #32·#33의 영향 범위

어제 같은 시각 머지된 두 PR이 Combat 인터페이스에 미치는 영향을 보는 게 목적. 의심2 패치(HitStopTimers 멤버 맵 도입, WeaponComponent.h 변경 동반)가 별도 PR로 들어가야 하는데, 그 전에 develop pull → rebase가 안전하게 통과될지 확인할 필요.

PR #32 — feat/Player 무기 에셋 — 주로 Content/ 아래의 .uasset 추가. cpp 변경은 무기 슬롯·인풋 매핑 일부 보완. WeaponComponent의 공개 API는 시그니처 변경 없음
PR #33 — feat/system-HUD — 위젯·HUDWidget·PlayerHUD. HealthComponent의 델리게이트 시그니처와 위젯 BindUFunction 결선 추가. Combat 쪽 인터페이스 직접 변경은 아니지만 — OnHealthDamaged/OnHealthThreshold 델리게이트 시그니처가 의심2 패치 시점에 충돌할 가능성이 있어 주의

읽으면서 정리한 인터페이스 영향

변경 위치	영향 받는 파일	의심2 패치 충돌 가능성
`WeaponComponent.h` 공개 API	— (PR #32 변경 없음)	낮음. `HitStopTimers` 멤버 추가만
`HealthComponent.h` 델리게이트	PR #33이 시그니처 사용	의심2와 무관. 처형 트리거 후속에서 영향
`Content/Combat/TestMap1.umap`	PR #34에 포함됨	의심2 패치 시 같은 맵 재저장 시 충돌 — 머지 도구로 한쪽 선택
빌드 ABI(헤더 변경)	`WeaponComponent.h`	의심2 패치는 헤더 변경 동반 → 별도 PR로 분리한 결정이 옳음

의심2 패치 진입 전 체크리스트

git checkout develop && git pull — PR #32·#33·#34 최신 반영
git checkout feat/combat-hit-damage-system && git rebase develop — 어제 PR #34 머지 후 같은 브랜치 재사용 여부 확인. 보통 머지 후엔 새 브랜치를 따는 게 깔끔
새 브랜치 권장 — feat/combat-hitstop-timers 신규 생성. 헤더 변경이 들어가는 별도 PR이라 이름도 별도로
HitStopTimers 멤버 추가 → ApplyHitStop 진입부에 기존 타이머 ClearTimer → 지역 FTimerHandle → 멤버 맵 저장 전환 → 복귀 람다에 Remove(WeakHit) 추가
PIE 진단 — [HitStop] %s scale=%.2f dur=%.2fs 로그로 호출 여부·스케일·duration 동시 확인

PR #32·#33 분석 결과 의심2 패치 자체에는 충돌 위험이 거의 없다는 게 확인되어, 내일 의심2 패치를 안전하게 진행할 수 있는 상태.

미해결 / 내일(5/21) 우선순위

⬜ 히트스톱 의심2 패치 — HitStopTimers 멤버 맵 도입 — Public/Combat/WeaponComponent.h에 TMap<TWeakObjectPtr<AActor>, FTimerHandle> HitStopTimers 멤버 추가, ApplyHitStop 진입부에 기존 타이머 ClearTimer, 지역 FTimerHandle → 멤버 맵 저장 전환, 복귀 람다에 Remove(WeakHit). 헤더 변경 동반 별도 PR로 진행
⬜ PIE 진단 — 연사 시 0.15초 슬로우 온전 유지 + 다발 push 차단 동시 검증. 진단 로그([HitStop] %s scale=%.2f dur=%.2fs) 활용
⬜ 피격 VFX 구현 — 파티클·머티리얼·데칼. 발표 임팩트 직격이라 의심2 패치 다음 우선순위. Portal로 마켓플레이스 레퍼런스 자산 일부 import 가능
⬜ 처형 트리거 구현 — HealthComponent::OnHealthThreshold 델리게이트 신규 검토. PR #33의 위젯 결선 패턴과 일관성 유지
⬜ C-AL-02 카메라 셰이크 두 번째 + 무기 분기 통합 — RangedCameraShake / WeaponConfig::TSubclassOf<UCameraShakeBase> 설계
⬜ OnHealthDamaged 구독 위젯으로 HP 바 갱신 (필수 1) — NBC_Master 마스터 과제. PR #33의 HUD 골격이 들어왔으니 결선만 남음
⬜ 24번 floating_point 정밀도 파트 답변 보강 — 가수 23비트 → 7자리 십진 정밀도($\log_{10}(2^{23}) \approx 6.92$), ULP, machine epsilon 한 묶음 정리 (이월)
⬜ graphify CS 그래프 풀 빌드 — 26·27·28·29번 일괄 반영. graphify update . 1회 실행 (이월)
⬜ Bootcamp-TIL 미커밋 정리 — 5월/2026-05-15.md(modified) + 5월/2026-05-18.md·5월/2026-05-19.md·5월/2026-05-20.md(오늘) + 코드카타 cpp 2개. 본 TIL과 한 묶음으로 커밋

오늘 배운 것 정리

“비트 수”는 단일 숫자가 아니라 시스템 폭(system width) — 32비트와 64비트의 차이를 “한 번에 처리하는 비트 수”로 외우면 단순 암기에 그친다. 실제로는 레지스터 너비 + 주소 버스 비트 수 + ALU 폭 + 가상 주소 공간 + 포인터 크기 + 호출 규약 이 한꺼번에 바뀌는 패키지 결정. 이 한 줄로 6축의 차이가 한 그림으로 묶인다. 트레이드오프(포인터 두 배 → L1 hit rate 하락, V8 Compressed OOPs·JVM 포인터 압축이 이걸 우회) 한 줄까지 더해야 균형 잡힌 답변
메모리 계층은 “이상적 메모리가 불가능하기 때문에 만들어진 절충안” — 통하는 이유는 단 하나, 지역성 — 빠르고·크고·싼 메모리는 물리적으로 동시에 불가능(SRAM·DRAM·NAND 제약). 그래서 여러 계층을 쌓아 평균적으로 빠르고 평균적으로 크게 만든 것이 메모리 계층. 이게 동작하는 통계적 토대가 시간 지역성 + 공간 지역성 단 두 가지. L1 hit rate 95%가 가능한 이유. 답변에서 이 한 줄을 첫머리에 두면 뒤따라오는 6계층·MESI·TLB·NUMA가 자연스럽게 연결된다
25·26·27·28번이 29번의 부분집합 — CS 흐름의 상위 프레임이 잡힌다 — 캐시 히트/미스(25)는 캐시 계층 내부, 페이지 폴트(26)는 DRAM↔디스크 경계, 메모리 단편화(27)는 할당기 효율, 32/64비트(28)는 워드 크기가 계층 전반에 미치는 영향. 메모리 계층(29)은 이 모두의 상위 프레임. 모의면접에서 한 주제 답변 중 다른 주제로 자연스럽게 확장할 수 있는 “주제 간 다리”가 생긴 셈
발표 6일 전 프로토타입의 의미 — 완성품의 축소판이 아니라 “전체 합의 충분성 검증 도구” — 각 컴포넌트가 동작해도 전체 흐름이 어색하면 발표 임팩트가 깎인다. 프로토타입을 굴려본 결과 — 시각 피드백(피격 VFX·처형 컷·카메라 셰이크) 3종이 임팩트 직격, 의심2 슬로우 약화는 카메라 워크로 가려진다는 우선순위 재조정의 근거가 잡혔다. “기능 완성도 vs 발표 임팩트”의 트레이드오프에서 후자를 선택하는 결정
헤더 변경이 들어가는 패치는 별도 PR로 분리 — 빌드 시간·리뷰 부담·rebase 위험을 동시에 줄인다 — PR #34는 cpp만 들어가 빠르게 머지됐다. 의심2 패치는 WeaponComponent.h에 TMap<TWeakObjectPtr<AActor>, FTimerHandle> 멤버 추가가 따라가야 해서 ABI 영향이 있고, 리뷰어가 인터페이스 변경을 별도로 살필 수 있어야 한다. cpp 패치 PR과 헤더 변경 PR을 분리하는 워크플로우가 팀 작업에서 머지 충돌·리뷰 누락을 막는 패턴
팀 코드를 미리 읽어두면 rebase 충돌을 사전 해결할 수 있다 — develop에 동시 머지된 PR #32·#33의 변경 범위를 미리 읽어보니 — HealthComponent 델리게이트 시그니처가 PR #33의 위젯 결선과 묶여 있어, 처형 트리거 구현 시점에 영향이 있을 수 있음을 발견. 의심2 패치 자체에는 충돌 위험이 거의 없다는 결론까지 — rebase 직전에 변경분을 읽는 5분이, rebase 후 충돌 디버깅 30분을 절약한다
Portal은 자산 수입의 단일 경로 — 팀 환경 일관성을 위한 인프라 — 팀원마다 외부 자산 import 경로가 다르면 .uasset 종속성·GitHub LFS 추적 경로가 어긋난다. Portal을 통일 경로로 두면 Content/Marketplace/<자산명>/ 같은 표준화된 디렉토리로 들어와 빌드·쿡 단계의 누락이 줄어든다. 팀 작업의 인프라 정리는 기능 작업 사이에 끼워넣어도 비용 대비 효과가 큰 작업

TIL

daily til

TIL 2026-05-20

2026-05-20 CS 28·29 신규(32/64비트 OS·메모리 계층) + Ch3 프로토타입·Portal 설치·팀 코드 분석

목차

오늘 한 일 요약

작업 환경

1. CS 28 — 32비트 vs 64비트 운영체제 신규 작성

작성 의도 — 10·11번을 묶는 “시스템 폭”이라는 큰 그림

핵심 골격 — 6축으로 묶기

면접 답변에서 가장 신경 쓴 한 줄

27번 단편화와의 연결고리

2. CS 29 — 메모리 계층 구조 신규 작성

작성 의도 — 25·26·27·28번의 상위 프레임

6계층 표 — 본문 중심축

지역성이 계층을 떠받친다는 한 줄

TLB·캐시 일관성·NUMA — 답변 깊이를 만드는 3개의 측면 축

3. Ch3 팀프로젝트 프로토타입 제작

목적 — 발표 6일 전, 완성도보다 흐름 검증이 먼저

확인한 동선과 부족 지점

4. Portal 플러그인 설치

도입 배경 — 자산·레퍼런스 관리를 에디터 안에서 통일

설치 흐름 — Epic Games Launcher 경로

활성화 후 확인 포인트

5. 팀 코드 분석 — develop 변경분 파악

분석 대상 — PR #32·#33의 영향 범위

읽으면서 정리한 인터페이스 영향

의심2 패치 진입 전 체크리스트

미해결 / 내일(5/21) 우선순위

오늘 배운 것 정리

인기 태그