[CSAPP 3장 완전 정복] 3.2 어셈블리 명령어는 어떻게 저장될까?

어셈블리 명령어는 어떻게 저장될까?

C 언어로 작성한 코드 한 줄이 어셈블리 코드로 바뀌고, 그 어셈블리 코드는 다시 바이너리 머신 코드(기계어)로 변환된다는 얘기를 한 번쯤 들어본 적 있으실 것 같습니다. 이번 3.2절에서는 바로 그 과정을 개략적으로 보여주는데요. 즉, "어셈블리어는 실제로 메모리 안에 어떻게 저장될까?"라는 질문에 대한 첫 번째 답을 다루고 있습니다.

 

 

C 코드가 기계어로 실행되기까지

ISA: 기계어의 설계 기준

C 코드가 어셈블리로, 그리고 다시 기계어로 번역된다는 말은 단순히 코드 형식이 바뀐다는 의미를 넘어서, 이 모든 명령어들이 ISA(Instruction Set Architecture)라는 체계에 따라 정의되어 있다는 뜻입니다.

 

ISA는 어떤 명령어들이 존재하는지, 각각이 어떤 기능을 수행하는지, 그리고 어떤 형식으로 인코딩되는지를 규정하는 하드웨어-소프트웨어 간의 계약입니다. 우리가 주로 다루는 x86-64는 인텔의 ISA 중 하나로, 그 명세에 따라 어셈블리어와 머신 코드가 구성됩니다.

 

ISA는 추상적인 수준에서 순차적 명령어 실행(sequential execution model)을 전제로 하며, 이 관점은 디버깅, 최적화, 보안 분석 등에서 프로그램의 흐름을 추론하는 데 핵심이 됩니다.

 

이를 통해 우리가 작성한 C 코드는 컴파일러에 의해 어셈블리어로 변환되고, 이는 다시 어셈블러를 통해 기계가 이해할 수 있는 기계어(machine code)로 번역됩니다.

 

예를 들어, 아래와 같은 간단한 C 코드를 작성한다고 해보겠습니다.

int square(int x) {
    return x * x;
}

이 함수는 컴파일러에 의해 다음과 같은 어셈블리 코드로 변환될 수 있습니다. (GCC 컴파일러 기준)

square:
    movl %edi, %eax
    imull %edi, %eax
    ret

그리고 이 어셈블리 명령어들은 다음과 같은 바이트 시퀀스로 인코딩됩니다.

어셈블리	기계어
movl %edi, %eax	89 f8
imull %edi, %eax	0f af c7
ret	c3

즉, 우리가 작성한 간단한 C 함수도 여러 단계의 변환을 거쳐 고유한 머신 코드 바이트 시퀀스로 바뀌며, 이 결과가 실행 파일의 텍스트 섹션(text section) 에 저장됩니다.

 

그리고 텍스트 섹션에 저장된 기계어는 프로그램 실행 시에 메모리의 코드 영역(Code Segment)으로 로딩됩니다. CPU는 이 영역의 명령어를 위에서부터 차례로 읽으며 프로그램을 실행하게 되죠.

 

프로세서 상태와 명령어 실행

기계어는 메모리에 적재되면 CPU가 차례대로 실행하게 되는데, 이 과정에서 프로세서의 상태(processor state)라는 요소들이 관여합니다.

대표적인 상태 요소로는 다음이 있습니다:

• 명령어 포인터(%rip): 다음에 실행할 명령어의 주소
• 레지스터 파일: 계산 및 임시 저장용 레지스터들 (%rax, %rbx 등)
• 조건 코드: 연산 결과에 따라 설정되는 플래그 (ZF, SF, OF 등)

이 상태들은 어셈블리 명령어가 실행되며 지속적으로 변하고, 프로그램 흐름과 결과에 직접적인 영향을 미칩니다. 디버깅이나 리버싱에서도 이러한 상태 정보를 추적하는 것이 핵심입니다.

 

결국, 어셈블리 명령어는 바이트 단위로 메모리에 저장되며, CPU는 프로세서 상태를 바탕으로 이 명령어들을 순차적으로 실행합니다.

 

 

x86 명령어의 길이와 명령어 경계의 중요성

x86 아키텍처의 명령어는 고정 길이가 아니라, 가변 길이(variable-length) 인코딩을 사용합니다. 예를 들어 어떤 명령어는 1바이트만으로도 표현되지만, 다른 명령어는 접두사, 연산코드, 주소 정보, 오퍼랜드 등을 포함하여 7바이트 이상을 차지할 수도 있지요.

 

이러한 구조 때문에 다음 명령어가 정확히 어디서 시작되는지, 즉 정확한 명령어 경계(instruction boundary)를 파악하는 것이 매우 중요합니다. 이 능력은 특히 다음과 같은 작업에서 필수적입니다.

• 디버깅(Debugging): 프로그램의 동작을 정확히 추적하고 문제를 분석하기 위해
• 리버싱(Reverse Engineering): 실행 파일을 분석하고 원리를 파악하기 위해
• 시스템 보안(System Security): 악성 코드 분석이나 취약점 점검 등에서 코드 흐름을 정확히 이해하기 위해

 

어셈블리어 -> 바이너리: 인코딩 예시

기계어 관점에서의 메모리

C 언어나 고급 언어에서는 변수의 타입(int, float 등)이 메모리 구조를 결정짓는 것처럼 보이지만, 기계어 수준에서의 메모리는 단지 바이트 배열(byte array)에 불과합니다.

 

즉, 어떤 값이 저장되었는지에 대한 의미는 프로그래머나 컴파일러가 부여하는 것이며, CPU는 단순히 특정 주소에 어떤 바이트들이 있는지만 인식할 뿐입니다.

 

이런 관점은 버퍼 오버플로우 같은 메모리 취약점을 이해하거나, 이진 분석을 수행할 때 매우 중요하게 작용합니다. 아래는 실제 어셈블리 명령어가 어떤 방식으로 바이트 시퀀스로 인코딩되는지 보여주는 간단한 예시입니다.

어셈블리 코드	바이너리 인코딩 (예시)
mov %eax, %edx	89 c2

각 명령어는 내부적으로 연산 코드(opcode), 오퍼랜드, 주소 접근 방식, 크기 정보 등을 조합하여 바이너리로 인코딩됩니다.

 

이러한 정보들은 컴파일러, 어셈블러, 링커를 거치는 빌드 과정을 통해 실행 파일에 담길 바이트 코드로 완성됩니다.

 

 

어셈블리어를 알아야 하는 진짜 이유

이 내용이 중요한 이유는 단순히 "기계어를 이해하기 위해서"가 아닙니다. 앞으로 우리는 디버깅(gdb), 최적화, 리버싱과 같은 작업을 할 때, 기계어 수준의 분석이 반드시 필요한 순간들을 마주하게 될 텐데요. 이때 사람이 기계어를 해석하고 이해할 수 있는 최후의 보루가 바로 어셈블리어입니다.

 

따라서 어셈블리어가 어떻게 메모리에 저장되고, 어떤 구조를 가지는지를 이해하고 있어야 문제를 정확하게 분석하고 빠르게 해결할 수 있는 개발자가 될 수 있습니다.

 

 

마치면서

어셈블리 명령어는 프로그램의 "텍스트 섹션"에 저장되는 머신 코드로 변환되며, 이들은 각각 고유한 바이너리 인코딩을 가진 가변 길이 명령어입니다. 그리고 우리가 어셈블리어를 배우는 이유는, 이러한 구조를 이해하고 분석함으로써 기계어 수준에서 프로그램을 다룰 수 있는 능력을 기르기 위해서입니다.

 

다음은 3.3절, 메모리 속 데이터의 저장 방식에 대해 다뤄보도록 하겠습니다. 감사합니다.