[Language] Assembly

Assembly란?

---

Assembly는 특정 프로세서 아키텍처의 기계어 명령을 사람이 읽고 작성할 수 있는 기호 형태로 표현하는 저수준 언어이다. 일반적인 고수준 언어가 자료구조, 타입, 런타임, 표준 라이브러리를 중심으로 문제를 표현한다면 Assembly는 레지스터, 메모리 주소, 분기, 스택, 호출 규약처럼 CPU가 실제로 처리하는 실행 단위에 가깝게 프로그램을 표현한다.

Assembly는 하나의 언어라기보다 ISA(Instruction Set Architecture), 어셈블러 문법, 운영체제 ABI가 결합된 계열에 가깝다. x86-64, AArch64, RISC-V는 명령어 집합과 레지스터 모델이 다르고, 같은 x86 계열 안에서도 Intel 문법과 AT&T 문법처럼 표기 방식이 달라진다. 따라서 Assembly를 이해한다는 것은 특정 CPU의 실행 모델과 소프트웨어가 하드웨어 위에서 약속을 맺는 방식을 이해한다는 뜻이다.

Assembly는 CPU 명령을 기호화한 저수준 표현이며, 성능 최적화보다 실행 모델·ABI·시스템 경계 이해에 더 큰 가치를 갖는 기술이다.

Assembly 소스가 어셈블러와 링커를 거쳐 기계어가 되고, CPU가 이를 가져오기·해석·실행·메모리 접근·쓰기 단계로 처리하는 흐름이다.

핵심 동작 원리

---

Assembly 소스는 보통 니모닉, 피연산자, 라벨, 지시어, 매크로로 구성된다. 어셈블러는 니모닉을 opcode와 operand encoding으로 변환하고, 라벨과 심볼을 재배치 가능한 주소 정보로 남기거나 확정한다. 링커는 여러 오브젝트 파일과 라이브러리를 결합하면서 섹션을 배치하고, 외부 심볼을 해결하며, 실행 파일 또는 공유 라이브러리를 만든다.

CPU 관점에서 중요한 것은 Assembly 문장 자체가 아니라 최종 기계어 바이트이다. 프로세서는 프로그램 카운터가 가리키는 명령을 가져오고, 디코더가 명령의 의미와 피연산자를 해석한 뒤, 실행 유닛이 산술·분기·메모리 접근을 수행한다. 현대 CPU는 파이프라인, 분기 예측, out-of-order execution, 캐시 계층을 사용하므로 소스의 순서와 실제 내부 실행 순서가 항상 단순히 일치하지 않는다.

Assembly 작성은 명령어를 나열하는 일이지만, 실제 성능과 동작은 인코딩, ABI, 링킹, 파이프라인, 캐시, 메모리 모델까지 함께 영향을 받는다.

ISA, ABI, 어셈블러 문법

---

ISA는 프로세서가 제공하는 명령어, 레지스터, 주소 지정 방식, 예외 모델, 메모리 모델을 정의한다. Intel 64/IA-32, Arm AArch64, RISC-V 같은 ISA 문서는 어떤 명령이 어떤 피연산자를 받고 어떤 상태를 바꾸는지의 기준점이 된다. Assembly는 이 ISA를 사람이 쓰기 쉬운 텍스트로 표현하는 층이다.

ABI는 함수 호출 시 어느 레지스터에 인자를 넣는지, 반환값은 어디에 두는지, 스택을 어떻게 정렬하는지, 어떤 레지스터를 호출자가 보존해야 하는지 같은 소프트웨어 약속을 정한다. 운영체제 시스템 콜 규약도 ABI의 일부로 볼 수 있다. 어셈블러 문법은 다시 별도의 문제다. GNU as, LLVM integrated assembler, NASM, MASM 등은 지원 문법과 지시어가 다르므로 같은 ISA라도 소스 호환성이 자동으로 보장되지 않는다.

실무에서 Assembly를 읽을 때는 먼저 ISA, 운영체제 ABI, 어셈블러 문법을 분리해서 봐야 오해가 줄어든다.

실무에서 쓰이는 지점

---

• 운영체제·부트로더: 초기 부팅, 인터럽트, 컨텍스트 스위칭, 시스템 콜 진입부처럼 고수준 언어만으로 표현하기 어려운 경계를 다룬다.
• 컴파일러·런타임: 코드 생성기, JIT, GC safepoint, 스택 언와인딩, 예외 처리 프롤로그와 에필로그 분석에 필요하다.
• 성능 최적화: SIMD, 원자적 명령, 메모리 배리어, 특수 CPU 명령을 직접 사용하거나 컴파일러 산출물을 검토한다.
• 보안 분석: 취약점 재현, 리버스 엔지니어링, exploit mitigation, 바이너리 패치, 악성코드 분석에서 기계어 수준 흐름을 읽는다.
• 임베디드 개발: 제한된 메모리와 장치 레지스터, 인터럽트 핸들러, 타이밍 제약을 직접 제어한다.

다만 애플리케이션 일반 개발에서 대규모 Assembly 코드를 직접 작성하는 경우는 드물다. 대부분은 C/C++/Rust 같은 시스템 언어를 기본으로 사용하고, 아주 좁은 병목이나 하드웨어 경계에서만 인라인 Assembly 또는 별도 어셈블리 파일을 사용한다.

Assembly는 대체 언어가 아니라 시스템의 가장 낮은 층을 읽고, 검증하고, 필요한 지점만 정밀하게 조정하는 도구에 가깝다.

성능과 유지보수 트레이드오프

---

Assembly는 CPU 기능을 직접 사용할 수 있다는 장점이 있지만, 항상 더 빠른 코드를 보장하지 않는다. 현대 컴파일러는 레지스터 할당, 명령 스케줄링, 벡터화, profile-guided optimization을 적극적으로 수행한다. 사람이 작성한 Assembly가 특정 마이크로아키텍처에서는 빠르더라도 다른 세대의 CPU에서는 분기 예측, 캐시, 디코더 폭, 포트 사용량, uop fusion 차이 때문에 기대만큼 동작하지 않을 수 있다.

유지보수 비용도 크다. 타입 안정성, 테스트 가능성, 포터빌리티, 디버깅 편의성이 낮고, ABI 변경이나 컴파일러 옵션 변화에 민감하다. 인라인 Assembly는 컴파일러 최적화와 잘못 상호작용할 수 있으므로 clobber 목록, volatile 여부, 메모리 장벽 의미를 정확히 적어야 한다.

Assembly 최적화는 측정 가능한 병목, 명확한 하드웨어 요구, 장기 유지 계획이 있을 때만 선택하는 것이 합리적이다.

보안과 운영 관점

---

Assembly 수준에서는 함수 경계, 스택 프레임, 반환 주소, 레지스터 보존, 메모리 접근 범위가 그대로 드러난다. 이 때문에 버퍼 오버플로, ROP/JOP 체인, use-after-free 이후 제어 흐름 변조, 스택 카나리, ASLR, DEP/NX, CET 같은 방어 기법을 이해하는 데 중요하다. 보안 엔지니어는 소스 코드만으로 설명되지 않는 취약점의 실제 실행 경로를 Assembly와 디스어셈블리로 확인한다.

운영 환경에서는 CPU 세대, OS 커널, 컨테이너 런타임, 하이퍼바이저, 보안 기능 활성화 여부가 실행 결과에 영향을 줄 수 있다. 특히 원자 명령과 메모리 배리어는 멀티코어 동시성 버그와 직접 연결되며, 잘못된 가정은 드물고 재현이 어려운 장애를 만든다.

Assembly 지식은 장애와 보안 이슈가 소스 코드 위의 추상화만으로 설명되지 않을 때 원인을 추적하는 해상도를 높인다.

사례

---

• Intel 64 and IA-32 Architectures Software Developer's Manual: Intel은 x86/x86-64 아키텍처의 프로그래밍 환경, 명령어 형식, 시스템 프로그래밍 동작을 공식 매뉴얼로 제공한다. 운영체제, 컴파일러, 성능 분석 도구가 x86 플랫폼을 다룰 때 기준 문서로 사용된다. Intel SDM
• Arm Developer Introduction to Assembly Language: Arm은 Assembly가 저수준 언어이며 일반적으로 니모닉과 기계어 명령 사이에 밀접한 대응 관계가 있다는 점을 공식 학습 문서에서 설명한다. AArch64나 임베디드 Arm 환경을 이해할 때 출발점이 된다. Arm Developer
• RISC-V Unprivileged ISA Specification: RISC-V International은 오픈 표준 ISA의 사용자 수준 명령어와 실행 모델을 공개 사양으로 유지한다. 교육, 연구, 반도체 설계, 컴파일러 백엔드에서 Assembly와 ISA의 관계를 확인하기 좋은 사례다. RISC-V ISA Manual
• Linux kernel entry and architecture-specific code: Linux 커널은 시스템 콜 진입, 인터럽트 처리, 컨텍스트 전환 등에서 아키텍처별 Assembly를 사용한다. 커널이 C 코드와 하드웨어 경계 사이를 어떻게 연결하는지 보여주는 대표적인 실무 사례다. Linux arch tree