TIL 2026-05-21
2026-05-21 모의면접 통합 발표(CS 28·29) + 심화수업 Final Test + 팀 PR 머지·레벨 배치 + 내일(05/22) TCP/UDP 사전 작성
목차
- 2026-05-21 모의면접 통합 발표(CS 28·29) + 심화수업 Final Test + 팀 PR 머지·레벨 배치 + 내일(05/22) TCP/UDP 사전 작성
오늘 한 일 요약
- 모의면접 통합 발표 — CS 28(32/64비트 OS) + CS 29(메모리 계층) 한 번에 발표 — 어제 작성한 통합본(
scrum/2026-05-21_모의면접_32vs64_메모리계층.md)을 기반으로 두 주제를 한 흐름에 묶음. 전환점 한 줄(“32/64는 시스템 폭, 메모리 계층은 그 폭 위의 배치”)로 자연스럽게 이어 붙임. 발표 중 면접관·동료에게 받은 꼬리질문 10여 가지를 정리. OS 정의를 “프로토콜”이라고 잘못 답한 부분은 즉시 “시스템 소프트웨어”로 정정 - 팀원 PR 머지 + 레벨 배치 마무리 — 5시경 창욱·성현·재봉님 프로토타입 PR이 순차적으로 올라옴 → 코드 리뷰 후 머지, 9시까지 레벨 배치 마무리. 어제 변경한 깃허브 구조 규칙(폴더 구획·네이밍)이 신규 PR에 적용된 것 확인. 창욱님 자작 Portal로 룸 간 전환까지 한 PIE 세션 안에 통과
- git.io 마무리 — 개인 블로그/리포 설정 정리 묶음 마감
- 심화수업 + Final Test 풀이 — 1~5강(벡터·삼각함수·내적/외적·dt 루프·포물선·충돌) + 펄어비스 CS 변형(포인터·재귀·복잡도·해시·스레드·가상함수·패딩·데드락·반사) + race condition 종합 서술. 60분 19문항 풀이 정리, 자주 틀리는 함정 11개를 카드화
- 내일(05/22) 모의면접 사전 — TCP/UDP CS 파일 작성 완료 —
raw/cs-notion/30_tcp_vs_udp.md(cs-agent 별도 처리). 28·29번이 한 머신 안의 시스템 폭·메모리 배치라면, 30번부터는 머신 간 통신 영역으로 첫 진입
미해결 — 히트스톱 의심2 패치(헤더 변경 동반 별도 PR) 여전히 이월, PIE 검증·24번 정밀도 보강·graphify CS 풀 빌드(26·27·28·29번 일괄)·Bootcamp-TIL 미커밋 정리까지 줄줄이 이월.
작업 환경
- 발표 자료(본 레포) —
scrum/2026-05-21_모의면접_32vs64_메모리계층.md(CS 28·29 통합본) - 심화수업 시험지·풀이 —
scrum/2026-05-21_심화수업_FinalTest_풀이.md(1~5강 + 펄어비스 변형 19문항) - CS 자료(본 레포) — 어제 작성한
raw/cs-notion/28_os_32bit_vs_64bit.md,29_memory_hierarchy.md본문 참조. 내일 발표분은raw/cs-notion/30_tcp_vs_udp.md로 사전 작성 - 외부 프로젝트 —
D:\Unreal\8th-Team11-CH3-Project(Ch3 팀플, 발표 2026-05-26 잔여 5일). 5시 PR 머지 → 9시 레벨 배치 마무리 - 자작 Portal — Epic Games 마켓플레이스 플러그인 아님. 창욱님이 팀프로젝트 진행 중 직접 제작한 룸 간 전환·체크포인트 시스템. 외부 종속성 없이 팀 내부 자산으로 동작
1. 모의면접 통합 발표 — 32/64비트 OS(CS 28) + 메모리 계층(CS 29)
두 주제를 한 번에 묶기로 결정한 이유
원래는 두 주제를 따로 발표하는 일정이었지만, 어제 작성하면서 — 28번(시스템 폭)과 29번(메모리 계층)이 같은 시스템의 두 면이라는 게 분명해졌다. 따로 발표하면 주소 공간·레지스터·캐시 라인 같은 용어가 두 번 반복 정의되고, 듣는 사람 입장에서도 “왜 같은 얘기를 두 번 하지?”가 된다. 그래서 한 번에 묶고 통합본(scrum/2026-05-21_모의면접_32vs64_메모리계층.md) 작성 — 같은 용어(GPR·XMM·주소 버스·ALU·캐시 라인·MESI·TLB·NUMA)를 한 번만 정의하고, 두 주제 사이의 연결점은 전환점 한 줄로 처리.
발표 흐름과 전환점 한 줄
| 단계 | 내용 | 핵심 한 줄 |
|---|---|---|
| ① 워드 크기 = 시스템 폭 | 주소 버스·ALU·GPR/XMM 너비가 한꺼번에 결정 | “32 vs 64는 비트 수가 아니라 시스템 폭” |
| ② 그 결과 바뀐 것 | 주소 공간·포인터·레지스터·ABI·호출 규약·평탄 메모리 | 32비트 = 4GB·8 GPR·스택 호출 / 64비트 = 256TB·16 GPR·레지스터 호출 |
| ── 전환점 ── | 32/64는 시스템 폭, 메모리 계층은 그 폭 위의 배치 | 한 시스템의 두 면 |
| ③ 메모리 계층 6단 | 레지스터→L1/L2/L3→DRAM→NVMe→HDD | 격차 3천만 배 |
| ④ 계층이 통하는 이유 | 시간·공간 지역성, L1 hit rate 95%+ | 평균을 거의 L1 수준으로 끌어내림 |
| ⑤ 멀티코어 추가 축 | MESI·False Sharing·TLB·NUMA | 코어·소켓이 늘면 일관성 비용 |
| ⑥ 게임 엔진 임팩트 | UE5 LWC·TArray·SoA·Hot/Cold split·mmap .pak·Nanite | 모두 64비트 + 메모리 계층 의식 설계 |
전환점에서 실제로 사용한 한 줄 —
“32비트와 64비트의 차이가 시스템 폭의 차이라면, 그 시스템 폭 위에 실제 메모리가 어떻게 배치되어 동작하는가가 다음 주제 — 메모리 계층 구조입니다. 64비트의 256TB 평탄 주소 공간이 있기 때문에 메모리 매핑 파일이 자유로워졌고, 16개 레지스터가 캐시 계층 맨 위에 자리 잡고, GPU 메모리까지 64비트 주소로 일관되게 다뤄지는 — 그래서 두 주제는 사실상 연결된 한 시스템의 두 면입니다.”
발표에서 이 한 줄이 들어가는 순간 두 주제가 하나의 흐름으로 자연스럽게 이어졌다. 듣는 쪽에서도 끊김 없이 다음 주제로 넘어간 인상.
발표 중 받은 꼬리질문·답변 정정 메모
발표 중에 면접관·동료에게 받은 꼬리질문을 들어온 순서대로 정리. 통합본의 “예상 꼬리질문” 카드와 겹치는 것·새로 들어온 것을 섞어 정리.
| # | 질문 | 답변 핵심 |
|---|---|---|
| 1 | 64비트가 무조건 좋은 거 아닌가? 트레이드오프는? | 포인터 4B→8B로 풋프린트 증가, 캐시 라인당 들어가는 포인터 수가 절반 → L1 hit rate 하락. V8·JVM이 pointer compression으로 보완하는 이유 |
| 2 | GPR과 XMM은 정확히 뭐가 다른가? | GPR = General Purpose Register, 정수·주소용. XMM = SSE/SIMD용 128비트 벡터 레지스터. 한 명령으로 float 4개·double 2개 동시 처리. AVX는 YMM 256비트, AVX-512는 ZMM 512비트로 확장 |
| 3 | ABI랑 호출 규약은 같은 건가? | ABI(Application Binary Interface)는 컴파일된 바이너리들이 서로 호출하기 위한 합의 전체. 호출 규약은 ABI의 핵심 일부 — 인자를 어디로 넘기는가. ABI는 그 외에 반환값 위치·보존 레지스터·struct 정렬·이름 맹글링까지 포함 |
| 4 | 주소 버스와 ALU의 차이는? | 주소 버스 = CPU와 메모리 사이의 전선 다발(주소 표현 범위 결정). ALU = CPU 안의 계산 회로(한 번에 더할 수 있는 비트 수 결정). 둘이 같은 너비를 가져야 자연스러운 동작 — 32비트 ALU가 64비트 정수를 더하려면 두 번 나눠 처리 |
| 5 | “평탄 메모리”가 무슨 뜻인가? | 모든 메모리를 0번지~N번지 직선 주소 공간으로 보는 모델. 반대는 옛날 16비트 8086의 세그멘티드(주소를 세그먼트:오프셋으로 나눠 표현). 32비트도 명목상 평탄이지만 4GB 한계라 사실상 작은 영역의 세그먼트를 옮기는 셈. 64비트의 256TB가 진짜 평탄 |
| 6 | 레지스터·트랜지스터를 한 번 짚어 달라 | 레지스터 = CPU 코어 안에 있는 초고속 저장소(<1 cycle), x86-64 GPR 16개·XMM 16개로 총 200~300바이트뿐. 트랜지스터 = 전자 신호를 켜고 끄는 반도체 스위치, 0/1을 표현하는 가장 작은 단위. SRAM 1셀 = 트랜지스터 6개, DRAM 1셀 = 트랜지스터 1개 + 커패시터 1개 |
| 7 | 소켓이라는 용어가 캐시 얘기에 갑자기 왜 나오나? | 메인보드에서 CPU 칩 하나가 꽂히는 자리. 데스크톱은 1소켓이지만 서버는 2·4·8소켓. “L3가 소켓 공유”는 한 CPU 칩 안의 모든 코어가 같은 L3를 공유한다는 뜻. 다른 소켓의 L3는 못 봄 — 여기서 NUMA가 등장 |
| 8 | DRAM이 “집적 가능”하다는 게 정확히 어떤 의미? | DRAM 셀(트랜지스터 1+커패시터)이 SRAM 셀(트랜지스터 6개)보다 약 1/6 면적. 같은 실리콘 면적에 6배 많은 비트가 들어감 → 같은 칩에 큰 용량·싼 단가. 대신 커패시터 전하가 1ms 만에 새어 나가서 주기적 refresh 필요 → 그래서 느림. 이게 SRAM은 캐시(MB 단위), DRAM은 메인 메모리(GB 단위)로 갈라지는 물리적 근거 |
| 9 | 캐시 라인이라는 단위가 왜 64바이트인가? | CPU↔캐시 사이 전송 단위. 한 바이트 요청 시 인접 63바이트도 함께 끌어와 공간 지역성 활용. 64B는 대부분의 x86-64 구현에서 고정. ARM은 일부 구현에서 128B |
| 10 | 캐시 라인의 크기가 32비트·64비트에서 다른가? | 캐시 라인 자체는 워드 크기와 독립. 32비트 CPU도 캐시 라인은 64바이트가 흔함. 캐시 라인은 메모리 시스템(L1·DRAM)의 전송 단위, 워드 크기는 CPU 레지스터·ALU의 너비 — 둘은 직교하는 차원. 다만 64비트에서는 포인터·정수가 두 배라 같은 64B 캐시 라인에 들어가는 데이터 개수가 절반이 되는 간접 효과는 있음 |
| 11 | 운영체제가 뭐냐고 한마디로 — | 처음 “프로토콜”이라고 답함 → 즉시 정정 (아래 별도 섹션) |
이 중 10번(캐시 라인의 32/64비트 차이)은 발표 중 처음 받아본 질문이라 잠깐 멈칫했다. 캐시 라인과 워드 크기를 같은 차원으로 묶어 생각하면 답이 안 나오는데, 둘이 직교한다는 점을 잡으면 깔끔하게 풀린다 — 캐시 라인은 메모리 시스템 쪽 단위, 워드 크기는 CPU 쪽 단위.
OS 정의 오답 정정 — “프로토콜” → “시스템 소프트웨어”
발표 마무리 단계에서 “그래서 운영체제(OS)가 뭐냐”는 가벼운 질문이 들어왔는데, 순간적으로 “프로토콜의 일종”이라고 답해버렸다. 즉시 정정 —
운영체제는 하드웨어와 응용 프로그램 사이에 있는 시스템 소프트웨어입니다. 프로세스 스케줄링·메모리 관리·파일 시스템·디바이스 드라이버·시스템 콜 인터페이스 같은 핵심 기능을 제공해서, 응용이 하드웨어를 직접 다루지 않고 추상화된 API로 동작할 수 있게 합니다. 프로토콜은 통신 규약을 가리키는 다른 개념입니다.
긴장 상태에서 비슷한 어휘(추상화·인터페이스)를 다루는 다른 개념으로 새는 경우가 있는데, 정정한 후에는 “OS = 시스템 소프트웨어 = 하드웨어와 응용 사이의 추상화 계층”이라는 한 줄을 머릿속에 박아 두기로 했다. 다음 면접에서 동일 함정을 피하기 위한 표시.
2. 심화수업 Final Test — 1~5강 + 펄어비스 CS 변형 19문항
scrum/2026-05-21_심화수업_FinalTest_풀이.md 정리 완료. 60분·19문항·100점.
영역 구성과 점수 분포
| 영역 | 점수 | 문항 수 | 범위 |
|---|---|---|---|
| A 그룹 — 벡터의 활용 | 25점 | 5문항 | 1~2강 (벡터 크기·각도·내적·외적·반사) |
| A 그룹 — 운동과 충돌 | 20점 | 4문항 | 3~5강 (dt 루프·포물선·AABB·원-원) |
| B 그룹 — C++ 코드 읽기 | 28점 | 5문항 | 펄어비스 변형 (재귀·복잡도·포인터·가상함수·패딩) |
| B 그룹 — 자료구조와 동시성 | 27점 | 4문항 | 펄어비스 변형 (해시·race·데드락·서술) |
| 합계 | 100점 | 19문항 |
A 그룹(1~5강) — 핵심 공식 한 줄 정리
수업 1~5강을 한꺼번에 묻는 묶음. 시험 풀이 중 가장 의식한 건 “공식을 외워 적용”이 아니라 “직관 한 줄로 식이 자연스럽게 나오게”.
| 강 | 주제 | 핵심 식·직관 |
|---|---|---|
| 1강 | 벡터 크기 | $|\vec{v}| = \sqrt{v_x^2 + v_y^2}$ — 피타고라스 그 자체. (6,8)→10은 3-4-5의 ×2 |
| 1강 | 각도 → 방향 | $(\cos\theta, \sin\theta)$ — 수평이 cos, 수직이 sin. 60° = (0.5, 0.866), 30° = (0.866, 0.5) |
| 2강 | 내적 양수 | $\hat{f}\cdot\vec{e} > 0$ → 전방 180° 시야. 전방이 (1,0)이면 단순히 e.x > 0 검사 |
| 2강 | 2D 외적 부호 | $\hat{f}\times\vec{e} = f_x e_y - f_y e_x$. y-up에서 +면 왼쪽, -면 오른쪽 |
| 2강 | 반사 벡터 | $\vec{R} = \vec{L} - 2(\vec{L}\cdot\vec{N})\vec{N}$ — N 성분만 뒤집기 |
| 3강 | 핵심 두 줄(dt 루프) | $\vec{v} \mathrel{+}= \vec{a}\cdot dt$ 먼저, $\vec{p} \mathrel{+}= \vec{v}\cdot dt$ 나중 (semi-implicit Euler). 순서 반대면 결과 다름 |
| 4강 | 절벽 발사 | 올라가는 시간 $t_\uparrow = v_y/g$, 최고 높이 $H = v_y^2/(2g)$, 떨어질 총 높이 = 절벽 + H |
| 5강 | AABB | 4부등식 AND — 한 축이라도 분리되면 즉시 MISS |
| 5강 | 원-원 | $d^2 \le (r_1+r_2)^2$ 한 줄. sqrt 없이 제곱 비교로 성능 회피 |
가장 의식한 건 4강 절벽 발사의 “올라간 5m 빼먹기” 함정. vy = 10·g = 10이면 1초 올라가 5m 더 떠 있다가, 절벽 40m + 5m = 45m를 떨어진다. 그래서 떨어지는 시간은 $\sqrt{2\cdot 45/10} = 3$초. 올라가는 1초를 더해 총 4초, 수평 거리 7·4 = 28m. 올라간 5m를 빼먹으면 답이 1m 어긋난다.
B 그룹(펄어비스 CS 변형) — 영역 매핑
펄어비스 변형이라 본 1~5강과는 결이 다른 CS 영역으로 들어간다. 9개 문항을 4개 큰 영역으로 매핑.
| 큰 영역 | 문항 | 핵심 |
|---|---|---|
| 재귀·복잡도 | C++ 문제 1·2 | base case 없는 재귀 → 스택 오버플로우 / 이진 탐색 → O(log n). 두 문제 모두 함수의 종료 조건과 매 반복의 입력 감소 비율이 답을 결정 |
| 포인터·연산자 우선순위 | C++ 문제 3 | *(ptr+2) vs *ptr + 2. 단항 *가 이항 +보다 우선. 전자는 arr[2]=30, 후자는 arr[0]+2=12 |
| 다형성·메모리 레이아웃 | C++ 문제 4·5 | 가상함수 = 런타임 vtable, non-virtual = 컴파일 타임 정적 디스패치. p->name()이 부모 버전 실행되는 함정 / 구조체 패딩 = 가장 큰 멤버 정렬(8B). char-int-char-double은 24바이트, 재배열하면 16바이트 |
| 해시·동시성 | 자료구조 1·2·3·4 | 해시 = 결정론적·단방향·계산 비용(②③⑤). “유사 입력 → 유사 출력”은 함정 — 오히려 avalanche가 좋은 성질 / counter++ 동기화 없음 → 1000~2000 비결정적 / 코프만 4조건(상호 배제·점유 대기·비선점·순환 대기) / race condition 서술 |
C 그룹 — Race Condition 종합 서술
서술형 답안(05/13 모의면접 정리 내용을 압축) —
Race condition은 여러 스레드가 동기화 없이 같은 메모리에 read-modify-write를 동시에 수행할 때, 한쪽의 갱신이 다른 쪽의 갱신에 덮어쓰여 값이 손실되고 결과가 실행마다 달라지는 비결정적 문제다. 이를 막기 위해 임계 구역 전체를 직렬화하는 std::mutex(
std::lock_guard로 스코프 단위 보호 — 두 줄 이상의 복합 연산이나 컨테이너 보호에 적합)와, 단일 변수 단위 갱신에는 std::atomic<T>(CPU의 lock-free 원자 명령으로 read-modify-write가 한 사이클에 안전하게 끝나, mutex 컨텍스트 스위치 비용 없이 동기화)를 사용한다. 더 복잡한 producer·consumer 흐름에서는 lock-free queue 같은 동시성 안전 자료구조를 써서 락 경합 자체를 줄인다.
채점 포인트 3개 — (1) 동기화가 없을 때 무엇이 잘못되는지(lost update·비결정성), (2) 어떤 방법으로 막는지(mutex·atomic), (3) 자료구조명과 이유(lock-free queue) — 모두 포함.
자주 틀리는 함정 11개 카드
시험 풀면서 “한 번 더 떠올려 검증해야 했던” 함정만 정리. 다음에 같은 형식 문제가 나오면 즉시 떠올릴 카드.
| # | 함정 | 정답으로 가는 핵심 |
|---|---|---|
| 1 | 각도 → (cos, sin) 순서 헷갈림 | 수평성분이 cos, 수직이 sin. 60°와 30°가 거울상 |
| 2 | 내적 = 0인 적을 시야 안으로 착각 | “양수”는 엄격히 > 0. 정확히 옆은 시야 경계라 제외 |
| 3 | 외적 부호 좌/우 | y-up 좌표계 기준일 때 양수 = 왼쪽. y-down(스크린 좌표)이면 부호 반대 |
| 4 | 반사 공식 부호 | R = L + 2(L·N)N은 표면 뚫고 들어가는 잘못된 식. -2가 맞음 |
| 5 | 절벽 발사 — 올라간 H 빼먹기 | 총 떨어질 높이 = 절벽 + H↑. vy²/(2g) 더하기 |
| 6 | AABB MISS 축 표기 | 어떤 축에서 분리되었는지 명확히. 한 축만 분리되어도 MISS |
| 7 | *ptr + 2 vs *(ptr+2) | 단항 *가 이항 +보다 우선. 전자는 *(ptr) + 2 |
| 8 | p->name() non-virtual | 정적 디스패치 → 부모 버전 실행. virtual 키워드가 없으면 컴파일 타임 타입 기준 |
| 9 | 구조체 끝 패딩 누락 | 전체 정렬 = 가장 큰 멤버 정렬. 24가 8의 배수면 끝 패딩 0 |
| 10 | 해시 “유사 입력 → 유사 출력” 함정 | 오히려 avalanche(1비트 변화 → 출력 크게)가 좋은 성질 |
| 11 | 코프만에 우선순위 역전 추가 | 별개 스케줄링 문제. 데드락 4조건은 상호 배제·점유 대기·비선점·순환 대기 |
3. 팀플 — PR 머지·레벨 배치·창욱님 자작 Portal
5시 PR 머지 — 신규 폴더 규칙 적용 확인
창욱·성현·재봉님이 프로토타입 제작을 진행하던 PR이 5시경부터 순차적으로 올라옴. 코드 리뷰 → 머지 흐름을 한 번에 묶어 처리. 어제 변경한 깃허브 리포지토리 구조(폴더 구획·네이밍·산출물 위치)가 이번 PR들에 일관되게 적용되어 들어왔는지가 가장 큰 확인 포인트.
확인 결과 — 세 PR 모두 새 구조 규칙 위에서 작성됨. 구조 변경 직후 첫 PR 세트가 깔끔하게 들어온 셈이라, 앞으로 들어올 PR들에서도 같은 규칙이 자연스럽게 유지될 전망. 폴더 규칙은 한 번 어긋나면 후속 PR도 따라서 어긋나기 때문에, 변경 직후 첫 PR 묶음에서 정확히 적용되는 게 중요했다.
리뷰 중 발견한 작은 컨플릭트 한 건은 같은 맵 파일에 두 PR이 동시에 수정을 가한 케이스라 머지 도구로 한쪽 선택 → 다른 한쪽 재적용 방식으로 해결.
9시까지 레벨 배치 마무리 — 한 PIE 세션에 끝까지 통과
PR 머지가 끝나자마자 레벨 배치 작업으로 전환. 어제 검증한 발표 시연 동선(스폰 → 교전 구간 → 처형 → 다음 룸 이동)을 PR로 들어온 신규 자산·기능과 묶어 끝까지 통과시키는 게 목표.
| 시연 단계 | 배치 작업 | 결과 |
|---|---|---|
| 스폰 포인트 | PlayerStart·적 스폰 트리거 | 한 PIE 세션 시작 시 정상 |
| 교전 구간 | 무기 픽업·적 스폰·콜라이더 | PR #32 무기 에셋 적용 후 한 방에 통과 |
| 처형(스턴 트리거) | HealthComponent의 임계 체력 진입 | 트리거 미구현 — 데모용 입력 키로 임시 대체 |
| 다음 룸 이동 | 창욱님 자작 Portal 배치 | 룸 간 전환이 한 PIE 세션 안에서 끊김 없이 이어짐 |
9시 직전에 한 PIE 세션 끝까지 시연 통과 확인. 발표일까지 잔여 5일 기준 흐름 검증의 큰 부분이 끝난 셈.
창욱님 자작 Portal 사용 인상
처음에 “Portal”이라는 단어 때문에 Epic Games 마켓플레이스의 어떤 플러그인인 줄 알았는데, 알고 보니 창욱님이 팀프로젝트 진행 중 직접 제작한 룸 간 전환·체크포인트 시스템. 외부 자산이 아니라 팀 내부에서 굴러가는 자작 시스템.
써본 인상 ——
- 외부 종속성 없이 동작 — 마켓플레이스 플러그인 / Epic 계정 / 라이선스 같은 외부 의존이 전혀 없음. 팀 내부 자산으로만 동작하니까 빌드 환경 차이로 깨질 위험이 없다
- PIE 세션 한 번에 룸 간 전환까지 통과 — 어제 프로토타입 단계에서는 룸이 끊겨 PIE 두 번을 띄워야 했는데, 자작 Portal을 끼우자 한 세션 안에 처음~끝까지 시연 동선이 이어진다. 발표 시연에서 “끊김 없는 흐름”이 만들어내는 임팩트는 크다
- 체크포인트 흐름과 자연스럽게 묶임 — 룸 간 전환과 체크포인트가 한 시스템 안에 같이 있어, 처형 트리거 후속 작업에서 재시작 지점·복귀 지점을 따로 설계할 필요가 줄어든다
발표 임팩트 측면에서 — 어제 정리한 시각 피드백 3종(피격 VFX·처형 컷·카메라 셰이크) + 자작 Portal로 끊김 없는 동선 = 발표 자체의 흐름이 한 묶음으로 잡혔다.
4. 내일(05/22) 모의면접 사전 — TCP/UDP CS 파일
cs-agent 별도 처리로 raw/cs-notion/30_tcp_vs_udp.md 작성 완료. 발표 전 답변 한 번 훑어보는 단계까지 마침.
회귀 다리 — 28·29 → 30 (한 머신 안 → 머신 간)
28번(시스템 폭)·29번(메모리 계층)이 한 머신 안의 데이터 흐름을 다뤘다면, 30번(TCP/UDP)부터는 머신 간의 데이터 흐름으로 시야가 넓어진다. 모의면접 흐름 자체가 OS·메모리 → 캐시·계층 → 네트워크 → 응용 순으로 자연스럽게 올라가는 구조.
1
2
3
4
5
6
7
19번 프로세스 vs 스레드 ← 한 머신 안의 동시성
22번 IPC ← 한 머신 안의 통신
25·26·27번 캐시·페이지폴트·단편화 ← 한 머신 안의 메모리 시스템
28·29번 워드 크기·메모리 계층 ← 한 머신 안의 시스템 폭과 메모리 배치
─────────────────────────────────────────────
30번 TCP vs UDP (★) ← 머신 간 통신 — 본 주제부터 시야 확장
이후 HTTP·HTTPS·TLS·게임 네트워킹
이 회귀 다리를 답변 도입에 한 줄로 깔면 — “한 머신 안에서 한 머신 사이로” 시야 전환이 자연스럽다.
답변 흐름의 큰 그림
TCP·UDP를 단순히 “TCP는 신뢰성, UDP는 빠름”으로 끝내지 않고 답변 깊이를 만드는 지점은 — “왜 신뢰성이 비싸고, 왜 게임은 그 비용을 감당할 수 없는가” 라는 인과를 풀어내는 부분.
| 단계 | 핵심 한 줄 |
|---|---|
| ① 트랜스포트 계층 위치 | 둘 다 OSI 4계층 — IP 패킷 위에 응용이 쓸 채널 제공 |
| ② TCP 본질 | 3-way handshake로 연결 수립, ACK·재전송·순서·흐름·혼잡 5가지 메커니즘으로 신뢰성 보장. 헤더 20+B |
| ③ UDP 본질 | 연결 없음·ACK 없음·재전송 없음·순서 보장 없음. 헤더 8B |
| ④ 신뢰성의 비용 | 3-way handshake 1 RTT + ACK 기반 재전송 1 RTT + Head-of-Line Blocking → 실시간성 직격 |
| ⑤ 게임 = UDP 표준 | 200ms 전 정확한 정보보다 30ms 전 손실 위험 정보가 가치 — 다음 패킷이 새 상태를 들고 옴 |
| ⑥ 하이브리드 구조 | 게임플레이는 UDP, 로비·매칭·결제는 TCP. 채팅·로그인은 TCP가 적합 |
| ⑦ 언리얼 Replication | UE는 OS TCP를 안 쓰고 자체 RUDP 구현 — UDP 위에 응용 계층 ACK·재전송. Reliable RPC = TCP-style, Unreliable RPC = UDP-style |
| ⑧ QUIC(HTTP/3) | UDP 위에 신뢰성·암호화·다중화를 응용 계층에서 구현. TCP의 Head-of-Line Blocking·TLS RTT 비용 해결 |
발표 직전 빠르게 훑을 핵심 카드만 미리 골라두면 — (1) 3-way handshake 정확한 동작, (2) Head-of-Line Blocking이 게임에서 왜 치명적인가, (3) UE의 RUDP가 OS TCP를 안 쓰는 이유, (4) QUIC이 UDP 기반인 이유. 이 4개가 발표 중 꼬리질문 핫스팟.
5. git.io 마무리
개인 블로그/리포 설정 정리 묶음 마감. 어제부터 끌고 온 작업으로 큰 변경은 아니지만 잔여 task로 남아 있던 부분을 한 번에 닫음. 별도 섹션으로 깊게 다룰 내용은 없어 — 오늘 작업 목록 안에서 잔여 정리 항목으로 표시.
미해결 / 내일(5/22) 우선순위
- ⬜ 05/22 모의면접 — TCP/UDP 발표 — 본 파일 작성한 답변 한 번 훑어보고 발표
- ⬜ 히트스톱 의심2 패치 —
HitStopTimers멤버 맵 도입 — 발표 임팩트 후순위로 정렬됐지만 여전히 이월. 헤더 변경 동반 별도 PR로 - ⬜ PIE 진단 — 의심2 패치 적용 후 연사 시 0.15초 슬로우 유지 + 다발 push 차단 동시 검증
- ⬜ 피격 VFX 구현 — 파티클·머티리얼·데칼. 발표 임팩트 직격 (잔여 5일)
- 📅 처형 트리거 구현 — 주말 작업 예정 (05/23~05/24) —
HealthComponent::OnHealthThreshold델리게이트. 임시 키 입력으로 대체된 상태 - ⬜ 카메라 셰이크 두 번째 + 무기 분기 통합 —
RangedCameraShake/WeaponConfig::TSubclassOf<UCameraShakeBase> - ⬜
OnHealthDamaged구독 위젯 HP 바 갱신 — PR HUD 골격 들어와 있음, 결선만 남음 - ⬜ 24번 floating_point 정밀도 파트 답변 보강 — 가수 23비트·ULP·machine epsilon 한 묶음
- ⬜ graphify CS 그래프 풀 빌드 — 26·27·28·29·30번 일괄 반영
- ⬜ Bootcamp-TIL 미커밋 정리 —
5월/2026-05-15.md(modified) +5월/2026-05-18·19·20·21.md(untracked). 본 TIL과 한 묶음으로 커밋
오늘 배운 것 정리
두 주제를 한 번에 발표할 때 전환점 한 줄이 흐름을 결정한다 — CS 28(시스템 폭)·29(메모리 계층)를 따로 발표했으면 주소 공간·레지스터·캐시 라인 같은 용어가 두 번 정의되고, 듣는 쪽도 “왜 같은 얘기 두 번?”이 됐을 것. “32/64는 시스템 폭, 메모리 계층은 그 폭 위의 배치” 라는 한 줄 전환점이 두 주제를 한 흐름으로 묶어준 핵심. 발표에서 단순 통합본 작성보다 더 큰 효과를 낸 건 이 한 줄을 미리 준비해 둔 점
꼬리질문은 통합본의 “예상 카드”와 새로 들어오는 것 둘 다 대비해야 한다 — 어제 통합본을 만들면서 예상 꼬리질문 7개를 미리 카드화해뒀는데, 발표 중에 11개 질문을 받았다. 그 중 새로 들어온 게 4개 — “캐시 라인의 32/64비트 차이”, “ABI와 호출 규약이 정확히 같은가”, “DRAM ‘집적 가능’의 정확한 의미”, “OS가 한마디로 뭐냐”. 미리 정리 안 했으면 어느 시점에 한 번은 멈칫했을 것. 다음 발표 전엔 “내 자료에 안 나온 변형 질문 4~5개”를 일부러 추가로 떠올려 대비하는 단계를 넣자
OS 정의 같은 기본 개념도 긴장 상태에서는 인접 개념(프로토콜)으로 샐 수 있다 — 발표 마무리에 “OS가 한마디로 뭐냐”는 가벼운 질문에 “프로토콜”이라고 답한 게 그 예. 정정 후 “OS = 하드웨어와 응용 사이의 시스템 소프트웨어 = 추상화 계층”으로 머릿속에 박아 둠. 가장 기본인 개념일수록 한 줄 정의를 미리 외워두는 게 필요 — 깊은 주제만 준비하다 보면 가벼운 정의에서 미끄러진다
시험 함정은 “공식 자체”가 아니라 “공식 적용 시 한 단계 빼먹기”에서 나온다 — Final Test 풀면서 가장 위험했던 게 4강 절벽 발사의 “올라간 5m 빼먹기”. 공식($v_y^2/(2g)$)을 모르는 게 아니라, 절벽 높이 40m에 올라간 5m를 더하는 단계를 의식하지 않으면 그냥 1m 어긋난 답이 나온다. 비슷하게 —
*ptr + 2와*(ptr+2)의 단항 우선순위, 구조체 끝 패딩, 외적 부호의 y-up 기준 — 전부 공식을 알면서 한 단계 검증을 빼먹어 틀리는 패턴. 공식 외우기보다 “이 공식 적용에서 한 번 더 검증해야 할 단계는?”을 같이 외우는 방향이 효율적다형성에서 가장 자주 틀리는 건 “부모 포인터로 잡힌 자식의 non-virtual 멤버” — Final Test 가상함수 문제에서
p->name()이 부모 버전 실행되는 게 가장 헷갈리는 지점.virtual이 없으면 컴파일 타임 정적 타입 기준이라,Animal* p가 가리키는 객체가 Dog여도Animal::name()이 호출된다. 다형성 코드 읽을 때는 — 멤버 함수마다 (1) virtual 키워드 유무, (2) 정적 타입 vs 동적 타입, (3) 호출자가 객체인지 포인터/참조인지 — 세 축을 같이 봐야 한다자작 시스템(창욱님 Portal)이 외부 플러그인보다 발표에 더 유리한 경우가 있다 — 마켓플레이스 플러그인은 라이선스·외부 종속성·환경 차이가 발표 직전 깨질 위험. 자작 Portal은 팀 내부 자산으로만 동작해서 위험이 거의 0. 게다가 룸 간 전환과 체크포인트가 한 시스템에 묶여 있어 처형 후속 작업에서 재시작·복귀 설계 부담이 줄어든다. 팀 내부 자작 시스템은 “발표 안정성 + 후속 작업 단순화”라는 이중 이득이 있다
CS 학습 흐름이 “한 머신 안 → 머신 간”으로 자연스럽게 전환되는 시점에 다리 한 줄이 답변 깊이를 만든다 — 19·22·25·26·27·28·29번까지 한 머신 안의 동시성·통신·메모리 시스템을 다뤘고, 30번 TCP/UDP부터 머신 간 통신으로 시야가 넓어진다. 다음 모의면접 답변에서 “한 머신 안에서 한 머신 사이로” 한 줄을 도입에 깔면 — 단순히 TCP/UDP 차이만 늘어놓는 답변과 “OS·메모리 영역에서 네트워크 영역으로 확장”하는 답변의 깊이 차이가 명확해진다. 회귀 다리 한 줄이 답변의 격을 결정하는 패턴