---
title: "64비트 어셈블리로 객체·예외·코루틴을 밑바닥부터 다시 만들기"
published: 2026-08-01T14:09:00.000Z
canonical: https://jeff.news/article/5387
---
# 64비트 어셈블리로 객체·예외·코루틴을 밑바닥부터 다시 만들기

No Starch Press의 The Art of 64-Bit Assembly 2권 소개 글로, C++·Python·Rust에서 쓰던 객체, 예외, 클로저, 코루틴, 동시성 같은 개념을 Windows MASM에서 명령어 수준으로 재구현하는 내용을 다룬다. 단순히 AI에게 vtable 설명을 듣는 수준을 넘어, Windows가 실제로 기대하는 메모리 구조와 호출 규약을 이해하게 만드는 책이라는 메시지다.

- 이 글은 The Art of 64-Bit Assembly 2권 소개인데, 타깃이 꽤 선명함
  - “어셈블리는 아는데 고수준 언어의 어려운 부분은 그냥 믿고 넘어갔다”는 개발자용임
  - C++, Python, Rust에서 쓰는 개념을 런타임 없이 Windows MASM에서 직접 다시 만든다는 콘셉트임

- 문제의식은 AI 시대에 더 찰짐
  - AI에게 x86에서 vtable이 어떻게 동작하냐고 물으면 그럴듯한 설명은 해줌
  - 하지만 Windows가 실제로 기대하는 vtable 구조, 메서드 디스패치의 명령어 수준 동작, 관례를 벗어났을 때 깨지는 지점까지 알려주긴 어렵다는 얘기임

- 책에서 다루는 건 “어셈블리 문법”보다 런타임의 속살에 가까움
  - 객체지향 프로그램을 MASM으로 작성하면서 vtable, 메서드 디스패치, 상속을 손으로 구현함
  - Windows 구조화 예외 처리(SEH)를 명령어 수준에서 설치하고 관리함
  - thunk, 클로저, 이터레이터를 고차 함수처럼 동작하게 만듦

- 코루틴과 동시성도 고수준 언어 도움 없이 내려감
  - 코루틴, 제너레이터, 파이버를 HLL 코드에 기대지 않고 구현함
  - 실제 동기화 프리미티브를 써서 동시성 프로그램을 작성함
  - 유니코드 문자열 처리도 대부분의 코드가 틀리는 지점까지 내려가 다룬다고 함

> [!NOTE]
> 이 책의 포인트는 “어셈블리를 배워서 앱을 만들자”가 아니라, 런타임과 ABI가 감춰준 비용과 규칙을 명령어 수준에서 확인하자는 쪽에 가까움.

- 그래서 실무 개발자에게도 완전히 남의 얘기는 아님
  - 크래시 덤프, 네이티브 확장, FFI, 성능 병목, 보안 취약점 분석을 하다 보면 결국 호출 규약과 메모리 레이아웃을 봐야 할 때가 있음
  - 특히 Windows 환경에서 네이티브 코드와 맞붙는 사람이라면 SEH, vtable, 동기화 프리미티브를 아는 게 디버깅 시간을 줄여줌

---

## 기술 맥락

- 이 책이 고른 방식은 고수준 기능을 설명으로 끝내지 않고 MASM에서 직접 재구현하는 거예요. 왜냐하면 객체, 예외, 코루틴 같은 기능은 언어 문법으로 보면 쉬워 보이지만, 실제로는 메모리 레이아웃과 호출 규약 위에서 돌아가거든요.

- vtable을 예로 들면 “함수 포인터 테이블”이라는 설명만으로는 부족해요. Windows ABI가 어떤 구조를 기대하는지, this 포인터가 어떻게 전달되는지, 메서드 디스패치가 어떤 명령어 흐름으로 이어지는지를 알아야 깨지는 이유까지 이해할 수 있어요.

- SEH를 명령어 수준에서 다루는 것도 같은 맥락이에요. 예외 처리는 고수준 언어에선 문법처럼 보이지만, 실제로는 스택 언와인딩과 핸들러 등록 규칙이 맞아야 정상 동작해요. 네이티브 크래시를 분석할 때 이 차이가 꽤 커요.

- 코루틴, 제너레이터, 파이버를 직접 구현하는 건 실행 흐름을 누가 저장하고 언제 복원하는지 보기 위해서예요. 프레임워크가 숨겨준 상태 저장과 전환 비용을 이해하면, 동시성 버그나 성능 문제를 볼 때 감이 훨씬 좋아져요.

## 핵심 포인트

- 책은 C++·Python·Rust의 고수준 개념을 Windows MASM 기반 64비트 어셈블리로 다시 구현함
- vtable, 메서드 디스패치, 상속, SEH, 클로저, 이터레이터, 코루틴, 파이버, 동시성, 유니코드 처리를 다룸
- AI가 그럴듯한 설명을 줄 수는 있어도 실제 런타임·ABI·명령어 수준 디테일은 별도로 배워야 한다는 문제의식이 깔려 있음

## 인사이트

요즘 개발자가 매일 어셈블리를 쓰진 않지만, 런타임과 ABI가 왜 그렇게 생겼는지 아는 건 디버깅·성능·보안 쪽에서 여전히 강력한 무기다. 특히 “AI가 설명해준 것 같은 이해”와 “실제 Windows가 받아들이는 구조를 아는 이해”의 차이를 찌르는 소개가 꽤 정확하다.