64비트 어셈블리로 객체·예외·코루틴을 밑바닥부터 다시 만들기

• 이 글은 The Art of 64-Bit Assembly 2권 소개인데, 타깃이 꽤 선명함

  • “어셈블리는 아는데 고수준 언어의 어려운 부분은 그냥 믿고 넘어갔다”는 개발자용임
  • C++, Python, Rust에서 쓰는 개념을 런타임 없이 Windows MASM에서 직접 다시 만든다는 콘셉트임

• 문제의식은 AI 시대에 더 찰짐

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

• 책에서 다루는 건 “어셈블리 문법”보다 런타임의 속살에 가까움

  • 객체지향 프로그램을 MASM으로 작성하면서 vtable, 메서드 디스패치, 상속을 손으로 구현함
  • Windows 구조화 예외 처리(SEH)를 명령어 수준에서 설치하고 관리함
  • thunk, 클로저, 이터레이터를 고차 함수처럼 동작하게 만듦

• 코루틴과 동시성도 고수준 언어 도움 없이 내려감

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

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

---

기술 맥락

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

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

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

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