소스 코드에서 실행까지: 컴파일·인터프리터·로더

01소스 파일·프로그램·프로세스

• 소스·실행 파일·프로세스소스 파일은 사람이 작성한 명령과 선언을 언어 문법에 맞춰 저장한 텍스트다.

  • 실행 파일은 대상 환경에서 적재·실행할 수 있도록 준비된 코드와 메타데이터다.
  • 프로세스는 그 프로그램이 실행되면서 주소 공간·열린 파일·권한·실행 상태를 가진 운영체제의 관리 단위다.
  • 같은 실행 파일을 두 번 실행하면 보통 서로 다른 프로세스가 생긴다.
• 실패 단계의 구분전처리·컴파일·어셈블·링크·적재·실행은 각각 역할과 성공 조건이 다르다.

  • 문법 오류, 링크 오류, 실행 중 예외와 권한 오류를 발생 단계에 맞춰 구분한다.
  • C/GCC는 대표적인 도구 체인 예이며 모든 언어가 같은 중간 파일을 만드는 것은 아니다.

02C 프로그램이 실행되는 단계

1. 전처리헤더 포함, 매크로와 조건부 컴파일을 처리한다.
2. 컴파일구문·타입 등을 분석하고 대상 기계에 맞는 코드 표현을 만든다. GCC의 -S는 어셈블리 출력을 남긴다.
3. 어셈블어셈블리 텍스트를 기계어·심볼·재배치 정보가 있는 목적 파일로 바꾼다.
4. 링크목적 파일과 라이브러리의 정의·참조를 연결하고 실행 형식을 만든다. 해결되지 않은 심볼은 링크 오류가 될 수 있다.
5. 적재와 초기화운영체제가 주소 공간을 준비하고, 필요한 경우 동적 로더가 공유 라이브러리와 심볼을 연결한다.
6. 사용자 코드 실행런타임 초기화 뒤 프로그램의 동작을 수행한다. 실행 중 오류와 자원 부족은 앞선 구문·링크 오류와 구분한다.

03C 도구 체인: 전처리부터 목적 파일까지

• 전처리·컴파일·어셈블전처리기는 #include에 따라 헤더 내용을 포함하고 매크로와 조건부 컴파일 지시문을 처리한다.

  • 이어 컴파일러가 구문·타입 등을 분석하고 대상 기계의 코드로 내릴 표현을 만든다.
  • GCC에서 -S는 어셈블리 출력을 남기고, 어셈블러는 이를 기계어와 심볼·재배치 정보가 들어 있는 목적 파일로 만든다.
• 목적 파일과 어셈블리.s는 사람이 읽을 수 있는 어셈블리 텍스트이고, .o/.obj는 보통 바이너리 목적 파일이다.

  • 목적 파일에는 아직 외부 함수의 최종 주소를 해결하지 못한 참조가 있을 수 있다.
  • 확장자만 보지 말고 도구·파일 형식·대상 플랫폼까지 확인한다.

gcc -E hello.c -o hello.i
gcc -S hello.i -o hello.s
gcc -c hello.s -o hello.o
gcc hello.o -o hello

각 명령은 전처리, 어셈블리 생성, 목적 파일 생성, 링크를 구분해 보여 주는 예시다. 이 웹사이트를 만드는 과정에서 실행한 명령은 아니다.

04링커와 로더가 맡는 서로 다른 일

• 링커링커는 여러 목적 파일과 라이브러리의 정의·참조를 맞추고 코드와 데이터를 실행 형식에 배치한다.

  • 정적 링크에서는 필요한 라이브러리 코드를 결과물에 포함할 수 있고, 동적 링크에서는 공유 라이브러리에 대한 참조를 남겨 실행 환경에서 연결한다.
  • “컴파일이 됐다”와 “링크가 됐다”는 서로 다른 성공 조건이다.
• 운영체제와 동적 로더실행을 시작할 때 운영체제는 실행 파일을 확인하고 코드·데이터 등의 주소 공간 매핑을 준비한다.

  • 동적 실행 파일에서는 동적 로더가 공유 라이브러리를 찾아 매핑하고 필요한 심볼 처리를 수행한다.
  • 언어 런타임 초기화 뒤 사용자 코드에 도달한다.
  • 전체 파일을 RAM에 한꺼번에 복사해야만 실행되는 것은 아니며, 실제 페이지 적재는 운영체제의 가상 메모리 정책과 연결된다.
• 실행 환경의 호환성소스는 같아도 CPU 명령어 집합, ABI, 라이브러리 버전, 실행 파일 형식이 다르면 그대로 실행되지 않을 수 있다.

  • 반대로 공유 라이브러리 하나가 누락되면 프로그램 시작 전에 실패할 수 있다.
  • 이 경우 소스 문법을 고치는 대신 실행 환경과 의존성을 조사해야 한다.

07인터프리터에도 파싱과 컴파일이 있다

• CPython 실행 모델인터프리터 방식이라는 말은 구현이 프로그램을 실행하는 방식의 큰 분류다.

  • 원본 파일을 반드시 한 줄씩 번역 없이 실행한다는 뜻이 아니다.
  • 일반적인 CPython은 소스를 토큰화·파싱하고 코드 객체와 바이트코드를 만들어 인터프리터가 실행한다.
  • import된 모듈의 바이트코드를 .pyc 캐시에 저장하기도 하지만 이는 보통 독립적인 네이티브 실행 파일이 아니다.
• JVM과 JITJava의 대표 구현도 소스를 JVM 바이트코드로 컴파일한 뒤 가상 머신에서 실행하고, 실행 중 일부 코드를 JIT 컴파일할 수 있다.

  • 따라서 “C는 컴파일, Python은 인터프리터, Java는 컴파일이므로 모두 같은 실행 경로”처럼 세 칸으로만 외우면 실제 처리를 놓친다.
  • 언어와 특정 구현·실행 옵션을 분리해서 설명하는 편이 정확하다.

import dis

def add(a, b):
    return a + b

dis.dis(add)

함수의 CPython 바이트코드를 읽는 예제다. 명령 이름과 배치는 Python 버전별로 달라지며, CPU 기계어를 출력하는 도구가 아니다.

08문법 오류와 실행 중 예외의 발생 시점

• 파일 전체의 구문 검사하나의 Python 소스 파일 전체를 실행하는 경우, 뒤쪽 줄에 구문 오류가 있어 파싱·컴파일에 실패하면 앞쪽 print도 실행되지 않는다.

  • 반면 문법이 올바르고 실행 중 0으로 나누는 예외가 발생하면 그 지점 앞의 부작용은 이미 일어났을 수 있다.
• 대화형 실행과 셀 상태대화형 셸에서는 입력 단위를 각각 컴파일·실행한다.

  • 이전 입력에서 실행한 결과가 다음 입력의 문법 오류로 취소되지 않는 것은 이 때문이다.
  • Notebook의 셀도 상태가 남을 수 있어, 보이는 줄 순서와 실제 실행 순서가 다를 수 있다.
  • 재현하려면 새 실행 환경에서 순서대로 실행했는지 확인한다.

# 사례 A: 이 세 줄을 하나의 파일로 실행하면 '시작'도 출력되지 않는다.
print('시작')
if True
    print('완료')

# 사례 B: 별도 파일로 실행하면 '시작' 출력 후 ZeroDivisionError가 발생한다.
print('시작')
value = 1 / 0
print('완료')

두 사례는 각각 별도 파일이라고 가정한다. 두 사례를 한 파일에 함께 붙이면 사례 A의 문법 오류 때문에 전체가 실행되지 않는다.

09Jupyter의 문서 순서와 커널 실행 상태는 다르다

• 브라우저·서버·커널브라우저는 셀 편집 화면이고 서버는 문서 저장과 통신을 중개한다. 코드를 실제로 실행하는 커널은 별도 프로세스이며 변수와 객체를 메모리에 유지한다.
• 저장된 문서ipynb는 코드·설명·출력·메타데이터를 담는 JSON 문서다. 저장된 출력이 보인다는 사실만으로 현재 커널에 그 변수가 존재하거나 같은 환경이 준비됐다고 판단하지 않는다.
• 실행기의 선택Notebook 서버를 시작한 Python과 선택한 커널의 Python이 다를 수 있다. 셀의 sys.executable과 터미널 출력을 비교하여 패키지와 실행기를 연결한다.

1. 첫 셀 실행빈 커널에서 x = 1 셀을 실행하면 이름 x가 정수 1을 참조한다.
2. 다음 셀 실행x += 1 셀을 실행하면 현재 x를 읽어 계산한 정수 2로 다시 연결한다. 이 셀만 한 번 더 실행하면 3이 된다.
3. 커널 재시작재시작하면 앞선 실행 상태가 사라진다. 문서에 이전 출력이 남아 있어도 x += 1부터 실행하면 x가 정의되지 않아 NameError가 날 수 있다.
4. 순서대로 재실행새 커널에서 정의 셀부터 위에서 아래로 실행해 의도한 결과가 나오는지 확인한다. 문서 배치와 실제 실행 이력의 차이를 줄이는 검증이다.

10함수 호출·지역 변수·객체 수명

• 호출 프레임과 객체 수명함수를 호출하면 인수와 지역 이름, 실행 위치 등 호출을 이어 가기 위한 상태가 필요하다.

  • 이 호출 프레임과 함수가 만든 객체의 수명은 같지 않다.
  • 함수가 반환한 리스트를 호출자가 참조하면 함수 호출이 끝나도 리스트를 계속 사용할 수 있다.
  • “함수 종료 시 모든 heap 데이터가 사라진다”는 식으로 설명하면 이 동작을 설명할 수 없다.
• 대입과 가변 객체Python의 대입은 이름을 객체에 연결한다.

  • b = a는 a라는 이름 자체를 b로 복사하거나 언제나 데이터를 깊은 복사하는 연산이 아니다.
  • a와 b가 같은 리스트 객체를 가리키면 한쪽 이름으로 수정한 결과가 다른 쪽에서도 보인다.
  • b = 10으로 재대입하면 b의 연결이 바뀌며 a의 연결까지 바뀌지는 않는다.
• 언어별 자료 모델C의 정수 변수 대입과 Python의 객체 이름 연결을 비교하는 것은 도움이 되지만, 이를 “절차 지향은 값 복사, 객체 지향은 참조 복사”라는 보편 법칙으로 만들면 틀린다.

  • 값·포인터·참조·가변성은 각 언어의 자료 모델과 자료형에 따라 판단한다.

def make_items():
    items = [1, 2]
    return items

a = make_items()
b = a
b.append(3)
print(a)  # [1, 2, 3]
b = [9]
print(a, b)  # [1, 2, 3] [9]

함수 반환 후 객체가 살아 있는 경우와, 같은 객체의 변경·이름의 재연결을 구분한다.

11절차·함수·객체·관점 지향의 학습 위치

• 절차와 함수형 관점절차적 구성은 작업 순서와 제어 흐름을 중심으로 프로그램을 나눈다.

  • 함수를 쓰면 공통 동작에 이름을 붙이고 입력·출력으로 연결할 수 있다.
  • 그러나 함수를 쓴다는 사실만으로 함수형 프로그래밍이 되지는 않는다.
  • 함수형 관점은 값의 변환·함수 합성·부작용 관리 등을 중요하게 다루며, 순수 함수는 같은 입력에 같은 결과를 내고 관찰 가능한 외부 상태를 바꾸지 않는 식으로 설명한다.
• 객체와 협력객체 지향에서는 관련 상태와 동작을 객체로 묶고 책임·인터페이스·객체 사이의 협력을 설계한다.

  • 클래스는 인스턴스를 만드는 정의이며, 메서드도 함수적 동작이다.
  • “객체 지향에는 함수가 없다”는 표현은 맞지 않는다.
  • 한 언어에서 절차적 코드, 함수, 객체를 함께 사용할 수 있다.
• 관점 지향관점 지향은 로깅·트랜잭션·접근 검사처럼 여러 기능에 걸치는 관심사를 분리하는 방법으로 이해한다.

  • 모든 프로그램이 절차 → 함수 → 객체 → 관점이라는 연대기 단계로 발전해야 하는 것은 아니다.

12성능과 자원 관리는 실행 측정으로 확인하기

• 병목을 결정하는 조건컴파일 언어이면 항상 빠르고 자원을 자동으로 잘 관리하며, 인터프리터이면 자원을 관리하지 않는다는 구분은 성립하지 않는다.

  • 알고리즘, 자료구조, I/O 대기, 외부 라이브러리, 런타임 최적화가 실제 병목을 바꾼다.
  • Python 호출 한 번이 네이티브 라이브러리의 대규모 계산으로 이어질 수도 있다.
• 실행 단계별 진단운영 관점에서는 프로그램이 실패한 단계를 먼저 구분한다.

  • 실행 파일을 못 찾는지, 로딩 중 라이브러리가 없는지, 초기 설정을 못 읽는지, 요청 처리 중 예외인지, CPU·메모리·I/O가 부족한지 확인한다.
  • 오류 메시지·종료 코드·표준 오류·서비스 로그를 실행 단계와 연결해야 수정할 대상을 좁힐 수 있다.