리눅스 as 명령어 완벽 가이드: 컴파일러의 심장, GNU 어셈블러 파헤치기

alias인가, as인가? 리눅스 명령어의 두 얼굴

리눅스 터미널에서 'as'라는 키워드를 접했을 때, 많은 개발자와 시스템 엔지니어는 두 가지 다른 명령어를 떠올릴 수 있습니다. 하나는 셸에서 긴 명령어를 짧게 줄여주는 alias이고, 다른 하나는 소프트웨어 개발의 가장 근본적인 단계에 관여하는 as, 즉 GNU 어셈블러입니다.

alias는 셸(Shell)의 내장 명령어로, 복잡하고 긴 명령어를 자신만의 짧은 별칭으로 만들어 작업 효율을 높여주는 편리한 도구입니다. 예를 들어, ls -alF라는 자주 사용하는 명령어를 ll이라는 별칭으로 만들고 싶다면 alias ll='ls -alF'와 같이 설정할 수 있습니다. 이러한 설정은 보통 사용자의 홈 디렉터리에 있는 .bashrc 파일에 저장하여 셸이 시작될 때마다 자동으로 적용되게 합니다.

하지만 이 글에서 집중적으로 다룰 대상은 alias가 아닌, 훨씬 더 근본적이고 강력한 도구인 as (the GNU Assembler) 입니다. as는 GNU 툴체인의 기본 어셈블러로서, 컴파일러가 생성한 인간이 읽을 수 있는 어셈블리 코드를 컴퓨터가 직접 실행할 수 있는 기계어(오브젝트 코드)로 변환하는 핵심적인 역할을 수행합니다.

본 문서는 as가 컴파일 과정에서 어떤 역할을 하는지부터 시작하여, 복잡하게 느껴질 수 있는 문법의 차이, 실제 어셈블리 프로그램을 작성하고 실행하는 방법, 그리고 매크로 프로그래밍과 크로스 컴파일 같은 고급 기법까지 심도 있게 탐구할 것입니다. 시스템 엔지니어부터 IT 분야에 입문하는 학생과 개발자까지, 모두에게 유용한 지침서가 되는 것을 목표로 합니다.

컴파일의 여정: 소스 코드에서 실행 파일까지

as의 역할을 제대로 이해하기 위해서는 먼저 C와 같은 고급 언어로 작성된 소스 코드가 어떻게 실행 가능한 파일로 변환되는지, 그 전체적인 여정을 알아야 합니다. 이 과정은 크게 네 단계로 나눌 수 있으며, as는 이 중 세 번째 단계를 책임지는 핵심 주자입니다.

1. 전처리 (Preprocessing)

컴파일의 첫 단계는 전처리기(cpp)가 담당합니다. 전처리기는 소스 코드에 포함된 #include, #define과 같은 전처리기 지시문을 처리합니다.

#include는 명시된 헤더 파일의 내용을 소스 코드에 그대로 삽입하고, #define은 정의된 매크로를 해당 값으로 치환합니다. 이 과정을 거치면 여러 파일과 매크로로 나뉘어 있던 코드가 하나의 순수한 C 소스 파일(보통 .i 확장자)로 통합됩니다.

2. 컴파일 (Compilation)

다음으로, 컴파일러의 본체(GCC의 경우 cc1)가 전처리된 .i 파일을 입력받아 아키텍처에 종속적인 어셈블리 언어 코드로 변환합니다. 이 결과물이 바로 .s 확장자를 가진 어셈블리 파일이며, 이것이 as가 처리할 입력 데이터가 됩니다. 이 단계에서 대부분의 문법 오류 검사와 코드 최적화가 이루어집니다.

3. 어셈블 (Assembly)

이 단계의 주인공이 바로 어셈블러(as)입니다. as는 컴파일러가 생성한 .s 파일을 받아, mov, add와 같은 어셈블리 니모닉(mnemonic)을 실제 CPU가 이해할 수 있는 이진 코드, 즉 기계어로 번역합니다. 이 결과물은 오브젝트 파일(.o)로 저장됩니다. 오브젝트 파일에는 프로그램의 코드와 데이터가 담겨 있지만, printf와 같은 외부 라이브러리 함수의 주소를 알지 못하는 등 아직은 불완전한 상태이므로 바로 실행할 수는 없습니다.

4. 링킹 (Linking)

마지막 단계는 링커(ld)가 수행합니다. 링커는 하나 이상의 오브젝트 파일들과 프로그램에 필요한 라이브러리 파일들을 하나로 합치는 작업을 합니다. 이 과정에서 오브젝트 파일들이 참조하던 외부 심볼(함수나 변수)의 주소를 찾아 연결하고, 모든 조각을 모아 최종적으로 운영체제가 실행할 수 있는 완전한 실행 파일을 만들어냅니다.

GNU 툴체인 생태계 (Binutils)

as는 단독으로 존재하는 도구가 아니라, GNU Binutils라는 강력한 바이너리 유틸리티 모음의 일부입니다. 이 생태계에는 as와 긴밀하게 협력하는 여러 도구들이 포함되어 있습니다.

• ld: 링커, 오브젝트 파일들을 묶어 실행 파일을 생성합니다.
• objdump: 오브젝트 파일의 구조를 분석하거나 기계어를 다시 어셈블리 코드로 역어셈블(disassemble)합니다.
• nm: 오브젝트 파일에 포함된 심볼(함수, 변수 이름 등) 목록을 보여줍니다.
• strip: 실행 파일에서 디버깅 심볼 등을 제거하여 파일 크기를 줄입니다.

이처럼 as는 바이너리를 다루는 정교하고 강력한 시스템의 한 축을 담당하고 있습니다.

과정 시각화: GCC로 단계별 파일 생성하기

추상적인 컴파일 과정을 눈으로 직접 확인하는 가장 좋은 방법은 GCC의 옵션을 사용하여 각 단계의 중간 결과물을 생성해보는 것입니다.

# 1. 전처리: main.c -> main.i
gcc -E main.c -o main.i

# 2. 컴파일: main.i -> main.s (어셈블리 코드 생성)
gcc -S main.i -o main.s

# 3. 어셈블: main.s -> main.o (오브젝트 파일 생성)
gcc -c main.s -o main.o

# 4. 링킹: main.o -> main (최종 실행 파일 생성)
gcc main.o -o main

물론 gcc main.c -o main이라는 단 하나의 명령만으로 이 모든 과정이 자동으로 수행됩니다. GCC는 내부적으로 as와 ld 같은 도구들을 순서대로 호출하는 '드라이버' 역할을 하는 것입니다.

이러한 GCC의 표준 컴파일 파이프라인은 중요한 설계 철학을 드러냅니다. C -> Assembly -> Object Code 흐름에서 컴파일러(gcc)의 역할은 어셈블리(.s 파일)를 생성하는 것이고, 어셈블러(as)의 역할은 그것을 소비하는 것입니다. 이는 as가 처음부터 인간 개발자를 위한 도구라기보다는, 컴파일러가 생성한 결과물을 처리하기 위해 최적화된 도구라는 점을 시사합니다. 뒤이어 다룰 AT&T 문법의 '투박함'은 설계 결함이 아니라, 기계 생성에 최적화된 정밀하고 모호하지 않은 표현 방식이라는 관점에서 이해할 수 있습니다.

세기의 문법 대결: AT&T vs. Intel

x86 어셈블리 언어를 처음 접할 때 가장 큰 장벽 중 하나는 바로 두 가지 주요 문법, AT&T와 Intel의 존재입니다. 이 둘은 단순히 스타일의 차이를 넘어, 각기 다른 컴퓨팅 역사와 철학을 반영합니다.

• AT&T 문법: GNU 툴체인(as, gdb, objdump)의 기본 문법입니다. 그 뿌리는 유닉스와 PDP-11의 역사에 닿아 있으며, 리눅스를 포함한 유닉스 계열 시스템의 표준 언어와도 같습니다.
• Intel 문법: Intel의 공식 CPU 문서에 사용되는 문법으로, NASM, FASM, MASM과 같은 어셈블러를 통해 DOS 및 Windows 환경에서 지배적인 위치를 차지하고 있습니다.

두 문법의 핵심적인 차이점은 다음 표와 같습니다. 이 표는 두 생태계를 오가는 개발자들에게 유용한 빠른 참조 가이드가 될 것입니다.

표 1: AT&T (GAS) vs. Intel (NASM) 문법 핵심 비교

GAS에서 Intel 문법 사용하기

다행히도 as는 Intel 문법에 익숙한 개발자들을 위해 실용적인 해결책을 제공합니다. 바로 .intel_syntax noprefix 지시어입니다. 이 지시어를 사용하면 GAS 파일 내에서도 Intel 문법으로 코드를 작성할 수 있습니다.

# AT&T 기본 문법
movl $10, %eax  # eax 레지스터에 10을 저장

# Intel 문법으로 전환
.intel_syntax noprefix
mov eax, 10     # eax 레지스터에 10을 저장

# 다시 AT&T 문법으로 복귀 (필요 시)
.att_syntax

이처럼 문법의 차이는 기술적인 것을 넘어 문화적, 역사적 배경을 담고 있습니다. 유닉스 계열 툴체인의 심장인 GNU 어셈블러가 경쟁 진영의 문법을 지원하기로 한 결정은, 소프트웨어 도구가 독단주의보다는 실용주의를 택하며 발전해왔음을 보여주는 중요한 사례입니다. 이는 개발자 커뮤니티의 현실을 인정하고 더 넓은 사용자층을 포용하려는 노력의 산물이며, GNU 툴체인의 접근성을 크게 높였습니다.

나의 첫 어셈블리 프로그램: 리눅스 x86-64에서 "Hello, World!"

이론을 배웠으니 이제 직접 어셈블리 코드를 작성하고 실행해볼 차례입니다. 가장 고전적인 "Hello, World!" 프로그램을 통해 as의 작동 방식과 리눅스 시스템 콜의 원리를 깊이 있게 살펴보겠습니다. 여기서는 C 라이브러리의 도움 없이, 운영체제 커널과 직접 통신하는 가장 순수한 형태의 프로그램을 작성합니다.

코드 해부: 한 줄 한 줄 뜯어보기

다음은 AT&T 문법으로 작성된 최소한의 "Hello, World!" 프로그램입니다.

# 파일명: hello.s

.section.data
msg:
    .ascii "Hello, World!\n"
    len = . - msg

.section.text
.global _start

_start:
    # write(1, msg, len) 시스템 콜 호출
    mov $1, %rax        # 시스템 콜 번호 1 (write)
    mov $1, %rdi        # 파일 디스크립터 1 (stdout)
    mov $msg, %rsi      # 출력할 메시지 주소
    mov $len, %rdx      # 메시지 길이
    syscall

    # exit(0) 시스템 콜 호출
    mov $60, %rax       # 시스템 콜 번호 60 (exit)
    xor %rdi, %rdi      # 종료 코드 0 (mov $0, %rdi와 동일하나 더 효율적)
    syscall

• .section .data: 초기화된 데이터가 위치할 데이터 섹션을 선언합니다.
• msg: .ascii "...": msg라는 레이블에 "Hello, World!\n" 문자열을 바이트 시퀀스로 정의합니다.
• len = . - msg: .은 현재 위치를 나타내는 특수 심볼입니다. 현재 위치 - msg 레이블의 시작 주소를 계산하여 문자열의 길이를 len이라는 심볼에 저장합니다.
• .section .text: 실행 코드가 위치할 텍스트 섹션을 선언합니다.
• .global _start: _start라는 심볼을 외부 링커가 볼 수 있도록 전역(global)으로 만듭니다. 링커는 이 _start 레이블을 프로그램의 진입점(entry point)으로 인식합니다.
• syscall: x86-64 아키텍처에서 커널의 서비스를 요청하는 명령어입니다. 오래된 int 0x80 인터럽트 방식을 대체하는 현대적인 방법입니다.

리눅스 시스템 콜 심층 분석

위 예제의 mov 명령어들은 임의의 숫자를 레지스터에 넣는 것이 아닙니다. 이는 x86-64 System V ABI(Application Binary Interface)라는 엄격한 '규칙'에 따른 것입니다. 이 ABI는 프로그램이 커널과 어떻게 상호작용해야 하는지를 정의하며, 어떤 레지스터에 어떤 값을 넣어야 하는지에 대한 규약을 포함합니다. 아래 표는 이 규칙을 이해하는 '로제타석' 역할을 합니다.

표 2: x86-64 리눅스 시스템 콜 주요 레지스터 규약 (ABI)

이 표를 보면 write 시스템 콜(번호 1)을 호출하기 위해 왜 rax에 1을, 첫 번째 인자인 파일 디스크립터(stdout)를 위해 rdi에 1을 넣는지 명확히 이해할 수 있습니다.

소스에서 실행까지: 두 가지 경로

작성한 hello.s 파일을 실행 파일로 만드는 방법은 두 가지가 있습니다.

경로 1: 수동 방식 (as와 ld 직접 사용)

이 방법은 툴체인의 각 단계를 직접 실행하여 내부 동작을 명확히 보여줍니다.

# 어셈블: hello.s -> hello.o
as hello.s -o hello.o

# 링크: hello.o -> hello
ld hello.o -o hello

경로 2: 드라이버 방식 (gcc 사용)

이것이 더 간단하고 일반적인 방법입니다. gcc가 as와 ld를 자동으로 호출해줍니다.

# 어셈블과 링크를 한 번에
gcc hello.s -o hello

두 경로 모두 ./hello 명령으로 실행하면 "Hello, World!"가 화면에 출력됩니다.

여기서 _start와 syscall을 사용한 방식과, C언어에서처럼 main 함수와 printf 같은 라이브러리 함수를 사용하는 방식 사이에는 근본적인 차이가 있습니다. main 함수를 사용한다는 것은 C 런타임(CRT)과 표준 라이브러리 전체를 프로그램에 링크한다는 의미입니다. 이는 편리함을 제공하지만, 프로그램의 크기를 상당히 증가시킵니다. 반면, _start를 사용하는 것은 CRT나 라이브러리 없이 오직 커널과 직접 대화하는, 작고 독립적인 프로그램을 만드는 것을 의미합니다. 이는 제어권과 크기, 그리고 편의성과 이식성 사이의 중요한 트레이드오프를 보여줍니다.

as 명령어 마스터하기: 핵심 옵션과 지시어

gcc가 편리한 드라이버이긴 하지만, 어셈블 과정을 세밀하게 제어하거나 디버깅하기 위해서는 as의 커맨드 라인 옵션을 직접 사용하는 것이 필수적입니다.

표 3: GNU Assembler (as) 필수 커맨드 라인 옵션

필수 어셈블러 지시어

지시어(Directives)는 CPU 명령어가 아니라, 어셈블러에게 특정 작업을 수행하도록 지시하는 명령어입니다. 데이터 정의, 섹션 배치, 심볼 관리 등 어셈블리 과정 전반을 제어합니다.

데이터 정의:

• .byte, .short, .long, .quad: 각각 1, 2, 4, 8바이트 크기의 정수를 정의합니다.
• .ascii, .asciz / .string: 문자열을 정의합니다. .asciz는 C 스타일로 문자열 끝에 널(null) 문자를 자동으로 추가합니다.

심볼 관리:

• .global <symbol>: 심볼을 다른 파일에서 참조할 수 있도록 전역으로 만듭니다.
• .local <symbol>: 심볼을 현재 파일 내에서만 사용하도록 지역으로 제한합니다.
• .equ <symbol>, <value> / .set...: 심볼에 특정 상수 값을 할당합니다.

섹션 제어:

• .section .text, .section .data, .section .bss: 코드가 위치할 .text 섹션, 초기화된 데이터가 위치할 .data 섹션, 초기화되지 않은 데이터가 위치할 .bss 섹션을 지정합니다.

정렬 및 채우기:

• .align <boundary>: 다음 데이터나 코드를 지정된 바이트 경계에 맞추어 정렬합니다. 성능 최적화에 중요합니다.
• .skip <size> / .space <size>: 지정된 바이트만큼 공간을 건너뜁니다(주로 0으로 채움).

고급 기법: 재사용 가능한 강력한 매크로 작성법

어셈블리 프로그래밍에서 반복적인 코드 시퀀스를 줄이고 가독성을 높이는 가장 강력한 도구는 매크로(Macro)입니다.

as의 매크로 기능은 단순한 텍스트 치환을 넘어, 조건부 어셈블리와 결합하여 고도로 추상화된 구조를 만들 수 있게 해줍니다.

매크로의 기초

• 정의와 종료: 매크로는 .macro 지시어로 시작하고 .endm 지시어로 끝납니다.
• 인자 전달: 매크로 이름 뒤에 인자 이름을 나열하여 값을 전달받을 수 있습니다. 매크로 본문 내에서는 백슬래시(\)를 인자 이름 앞에 붙여 참조합니다 (예: \arg1).
• 지역 레이블: 매크로가 여러 번 호출될 때 레이블 이름이 중복되는 문제를 피하기 위해, \@라는 특수 심볼을 사용합니다. 어셈블러는 매크로를 확장할 때마다 \@를 고유한 숫자로 대체하여 충돌을 방지합니다.

조건부 어셈블리

매크로에 논리를 부여하는 기능입니다. .if, .ifeq(if equal), .ifne(if not equal), .else, .endif와 같은 지시어를 사용하여 특정 조건이 참일 때만 코드를 어셈블하도록 할 수 있습니다. 예를 들어, DEBUG 심볼의 값에 따라 디버깅 코드를 포함하거나 제외하는 매크로를 만들 수 있습니다.

실용 예제: 재귀적 sum 매크로

as 공식 문서에 나오는 이 예제는 인자 전달, 재귀 호출, 조건부 어셈블리를 하나의 우아한 코드로 보여줍니다.

# 0부터 5까지의 숫자를 .long 지시어로 생성하는 매크로
.macro sum from=0, to=5
    .long \from
    .if \to-\from  # 'to'가 'from'보다 클 경우에만 재귀 호출
        sum "(\from+1)", \to
    .endif
.endm

.section .data
# 매크로 호출
sum 0, 5

위 코드를 어셈블하면 다음과 같이 확장됩니다.

.long 0
.long 1
.long 2
.long 3
.long 4
.long 5

이러한 기능들의 조합은 단순한 어셈블리 프로그래밍의 차원을 넘어섭니다. as의 매크로와 조건부 어셈블리를 활용하면 if/else, while 루프와 같은 구조적 프로그래밍 구문을 직접 구현할 수 있습니다. 실제로 이를 구현한 매크로 라이브러리도 존재합니다. 이는 어셈블러가 단순한 번역기를 넘어, 개발자가 자신만의 도메인 특화 언어(DSL)를 구축할 수 있는 강력한 메타프로그래밍 시스템임을 보여줍니다.

크로스 컴파일 입문: x86에서 ARM을 향하여

크로스 컴파일(Cross-compilation)은 현재 사용 중인 시스템(예: x86-64 PC)에서 다른 아키텍처(예: ARM 프로세서)를 위한 실행 파일을 만드는 과정을 말합니다. 개발용 PC의 성능이 훨씬 뛰어난 임베디드 시스템, IoT 기기, 모바일 장치 개발에 있어 이는 선택이 아닌 필수 기술입니다.

GNU 크로스 툴체인

GNU 툴체인은 표준화된 이름 규칙을 통해 크로스 컴파일을 체계적으로 지원합니다. 툴체인의 이름은 보통 <arch>-<vendor>-<os>-<abi> 형식으로 구성됩니다 (예: aarch64-linux-gnu). 데비안/우분투 계열 리눅스에서 apt install gcc-aarch64-linux-gnu와 같은 명령어를 실행하면, gcc뿐만 아니라 aarch64-linux-gnu-as, aarch64-linux-gnu-ld 등 타겟 아키텍처에 맞춰진 전체 툴체인이 설치됩니다.

실전: x86에서 AArch64용 "Hello, World!" 컴파일하기

툴체인 설치 (데비안/우분투 기준)

sudo apt update
sudo apt install gcc-aarch64-linux-gnu

AArch64 어셈블리 코드 작성 (hello_arm.s)

AArch64는 x86-64와 시스템 콜 번호 및 레지스터 사용 규칙이 다릅니다.

.data
msg: .asciz "Hello, ARM World!\n"
len = . - msg

.text
.global _start

_start:
    // write(1, msg, len)
    mov x0, 1       // 파일 디스크립터 (stdout) -> x0 레지스터
    ldr x1, =msg    // 메시지 주소 -> x1 레지스터
    mov x2, len     // 메시지 길이 -> x2 레지스터
    mov x8, 64      // AArch64의 write 시스템 콜 번호 -> x8 레지스터
    svc 0           // 시스템 콜 호출

    // exit(0)
    mov x0, 0       // 종료 코드 0 -> x0 레지스터
    mov x8, 93      // AArch64의 exit 시스템 콜 번호 -> x8 레지스터
    svc 0

크로스 어셈블 및 링크

반드시 타겟 아키텍처용 as와 ld를 사용해야 합니다.

aarch64-linux-gnu-as hello_arm.s -o hello_arm.o
aarch64-linux-gnu-ld hello_arm.o -o hello_arm

결과 확인

생성된 파일이 정말 ARM용인지 file 명령어로 확인할 수 있습니다.

$ file hello_arm
hello_arm: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, no section header

출력 결과가 ARM aarch64를 명시하고 있음을 볼 수 있습니다. 이 파일은 x86 PC에서는 실행되지 않으며, QEMU 같은 에뮬레이터나 실제 ARM 장치에서 실행해야 합니다.

GNU 툴체인의 잘 정립된 크로스 컴파일 지원은 전체 오픈소스 임베디드 생태계를 지탱하는 기반 기술입니다. 만약 이러한 도구가 없다면, 개발자는 매번 지극히 복잡한 과정을 거쳐 직접 크로스 컴파일러를 빌드해야 할 것입니다. aarch64-linux-gnu-as와 같은 도구는 as가 단지 x86 리눅스 시스템만을 위한 도구가 아니라, 현대의 거의 모든 프로세서를 위한 소프트웨어를 구축하는 '다리' 역할을 한다는 것을 보여줍니다.

결론: 어셈블러를 아는 개발자의 힘

지금까지 우리는 as, 즉 GNU 어셈블러의 세계를 깊이 있게 탐험했습니다. 컴파일 과정에서의 역할부터 AT&T와 Intel 문법의 차이, 시스템 콜의 작동 원리, 그리고 매크로와 크로스 컴파일이라는 고급 기법에 이르기까지, as는 단순히 오래된 도구가 아니라 현대 소프트웨어 개발의 가장 낮은 계층을 떠받치는 핵심 기둥임을 확인했습니다.

컴파일러와 하드웨어 사이의 계층을 이해하는 능력은 결코 낡은 기술이 아닙니다. 이는 성능을 한계까지 끌어올리는 최적화, 원인을 알기 힘든 버그를 추적하는 로우레벨 디버깅, 보안 취약점 분석과 리버스 엔지니어링 등 고급 개발자가 갖추어야 할 핵심 역량과 직결됩니다.

이 글을 읽는 데 그치지 말고, 직접 실천해보기를 권장합니다. 자신만의 작은 어셈블리 프로그램을 작성해보고, 평소 사용하던 C/C++ 코드를 gcc -S 옵션으로 컴파일하여 그 결과물을 분석해보십시오. 소프트웨어가 하드웨어와 어떻게 상호작용하는지 직접 눈으로 확인하는 경험은, 더 깊은 수준의 이해와 문제 해결 능력을 선사할 것입니다. 어셈블러를 이해하는 것은 개발자에게 세상을 다르게 보는 눈을 뜨게 해주는 강력한 무기입니다.