프로그램·언어·컴파일러·인터프리터·런타임

소스 파일은 혼자서 실행되지 않는다

개발자가 쓴 total = price * quantity라는 문장은 사람이 읽을 수 있는 규칙이다. 그런데 CPU가 이 글자를 직접 이해하는 것은 아니다. 먼저 언어의 문법과 의미에 따라 소스를 분석해야 하고, 그 결과를 실행 가능한 명령으로 번역하거나 실행 중에 해석해야 한다. 실행하는 동안에는 메모리와 함수 호출, 오류를 관리하는 실행 환경도 필요하다.

이 식은 “price의 현재 값과 quantity의 현재 값을 곱해 total에 연결한다”고 읽는다. *는 곱셈이고, 여기의 =는 오른쪽에서 구한 값을 왼쪽 이름에 대입하는 표시다. 값을 찾는 이름과 대입의 정확한 동작은 다음 절에서 상태표로 배우고, 여기서는 사람이 적은 규칙이 명령을 실행하는 장치까지 전달되는 경로를 먼저 본다. CPU는 컴퓨터의 중앙처리장치를 가리키며, 구체적인 동작은 다음 장의 ‘중앙처리장치(CPU)·명령어·레지스터·클록’ 절에서 배운다.

오류가 언제 발견되고 어디에서 성능 비용이 생기는지 알려면 소스 코드 → 번역·해석 → 런타임 지원 → 기계 실행 경로를 구분해야 한다. 프로그램, 언어, 컴파일, 런타임은 이 경로에서 서로 다른 일을 맡는다.

먼저 되짚기: 프로그램도 입력을 출력으로 바꾸는 규칙이다

입력·처리·출력 모델에서 처리는 입력과 현재 상태에 규칙을 적용하는 변화였다. 프로그램은 그 처리 규칙과 실행 순서를 컴퓨터가 수행할 수 있도록 표현한다. 이번 절은 규칙을 적는 단계에서 실제 실행까지의 경로를 펼친다.

입력·처리·출력에서 실행 가능한 프로그램으로 간다

입력에서 처리 규칙을 거쳐 출력을 만드는 IPO 관계를 컴퓨터가 수행하려면, 처리 규칙을 프로그램으로 표현해야 한다. 프로그램은 언어의 문법과 의미를 사용하고, 번역·해석과 런타임의 실행 경로를 거친다. 즉 IPO의 처리 규칙이 실제로 수행되려면 프로그램이라는 표현과 그 표현이 실행되는 경로가 함께 있어야 한다.

프로그램

프로그램은 입력과 상태에 따라 컴퓨터가 수행할 명령과 규칙의 표현이다. 소스 파일만을 뜻하지는 않는다. 실행 순서와 데이터, 상태, 외부 입력과 출력, 실패 처리까지 실제 행동을 결정하는 명세와 명령의 집합이 모두 프로그램이다.

프로그래밍 언어 전에 프로그램을 다시 잇는다

프로그램은 입력과 상태에 따라 수행할 명령과 규칙의 표현이다. 이제 그 규칙을 사람이 작성하고 구현이 해석할 공통 문법·의미 체계가 필요하다.

같은 계산도 언어 규칙으로 표현해야 한다

“두 값을 더해 출력한다”는 의도도 변수와 연산자, 호출 문법으로 표현해야 번역기나 실행기가 처리할 수 있다. 그래서 프로그램과 그것을 적는 프로그래밍 언어를 같은 대상으로 보지 않는다.

프로그래밍 언어

프로그래밍 언어는 계산과 제어를 사람이 작성하고 기계가 해석할 수 있게 표현하는 문법과 의미다. 문법은 어떤 기호 배열이 올바른 문장인지 정하고, 의미는 그 문장이 실행될 때 어떤 값을 만들고 상태를 어떻게 바꾸는지 정한다. 그래서 같은 모양의 연산자도 자료형과 언어 규칙에 따라 다른 의미를 가질 수 있다.

번역·해석 전에 언어 규칙을 다시 잇는다

프로그래밍 언어는 올바른 문장과 실행 의미를 정한다. 컴파일러와 인터프리터는 이 규칙을 이용해 소스 표현을 실행 가능한 동작으로 연결한다.

오류가 발견되는 단계도 실행경로의 일부다

문법에 맞지 않는 토큰 배열은 실행 전에 거부될 수 있다. 반대로 문법은 맞아도 실행 중 입력이나 자원 때문에 실패할 수 있다. 그래서 무엇이 컴파일·해석 단계의 오류이고 무엇이 런타임 실패인지 구분해야 한다.

컴파일과 해석

컴파일은 프로그램 표현을 다른 실행 형식으로 번역하는 일이고, 해석은 표현의 의미에 따라 동작을 수행하는 일이다. 컴파일러(compiler)는 소스나 중간 표현의 구조와 의미를 분석해 기계 명령 또는 다른 중간 표현으로 변환한다. 번역 시점은 실행 전일 수도, 실행 중일 수도 있다. 인터프리터(interpreter)는 프로그램을 실행하는 동안 소스 또는 중간 표현을 읽고 그 의미에 해당하는 동작을 수행한다. 실제 언어 구현은 미리 번역한 중간 표현을 실행 중 다시 최적화하는 등 두 방식을 섞을 수 있다.

실행 중 필요해진 코드 부분을 그때 번역하는 방식을 JIT(Just-In-Time, 적시 컴파일)라고 부른다. 따라서 미리 번역하는 단계와 실행 중 번역·해석하는 단계가 한 구현 안에 함께 있을 수 있다. 그러니 언어 이름 하나만 보고 오류 발견 시점이나 실행비용을 확정하지 않는다.

런타임 전에 번역 결과를 다시 잇는다

컴파일과 해석은 소스 표현을 실행 가능한 동작으로 연결하는 방식이다. 번역된 코드가 실제 메모리·호출·예외·운영체제 자원을 사용하려면 실행환경이 더 필요하다.

번역 성공은 실행 성공이 아니다

소스가 번역되었더라도 실행할 때 필요한 파일이 없거나, 메모리가 부족하거나, 입력이 잘못되면 실패할 수 있다. 그래서 번역 단계에서 확인할 것과 런타임 단계에서 확인할 것을 나누어 본다.

런타임

런타임(runtime)은 프로그램 실행 중 메모리·호출·오류·자원을 지원하는 환경이다. 언어에 따라 런타임은 값의 메모리를 회수하고 함수 호출 상태를 관리한다. 예외를 전달하고 운영체제 기능을 사용할 연결을 제공하는 것도 런타임의 일이다. 그래서 번역이 끝났다고 런타임이 맡을 일이 사라지는 것은 아니다.

코드가 실행되는 다섯 단계

분석·번역이 끝나도 실제 실행의 실패는 남는다 · 상태 따라가기

소스를 읽으며 문법이 맞는지 확인한다. 모든 단계에서 프로그램·처리·오류 지점의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.

이 예의 조건

• 그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상소스 프로그램	원 설명사람이 표현한 규칙
대상언어 구조	원 설명문자·문법 분석
대상의미 확인 표현	원 설명이름·자료형·의미 검사
대상실행 형태	원 설명기계 명령·중간 표현
대상실행 중 프로그램	원 설명메모리·호출·외부 자원
대상결과	원 설명출력·오류

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결소스 프로그램 → 언어 구조	원 라벨·방향문법 분석 / 정방향 / 실선
연결언어 구조 → 의미 확인 표현	원 라벨·방향의미 검사 / 정방향 / 실선
연결의미 확인 표현 → 실행 형태	원 라벨·방향번역 / 정방향 / 실선
연결실행 형태 → 실행 중 프로그램	원 라벨·방향자원 준비 / 정방향 / 실선
연결실행 중 프로그램 → 결과	원 라벨·방향입력 실행 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
구문 검사 소스를 읽으며 문법이 맞는지 확인한다.	값·보충 정보 프로그램: 소스 입력 처리·오류 지점: 구문 검사	변화·이유 구문 오류는 런타임 성공 경로로 넘어가지 않는다.
의미 검사·번역 이름·자료형 등 의미를 확인하고 실행 표현을 만든다.	값·보충 정보 프로그램: 의미를 확인한 소스 처리·오류 지점: 번역 결과	변화·이유 문법이 맞아도 의미 오류면 실행 표현을 확정하지 않는다.
실제 실행 런타임은 번역한 프로그램과 실제 입력을 처리한다.	값·보충 정보 프로그램: 실행 중 상태 처리·오류 지점: 출력 또는 런타임 오류	변화·이유 번역 성공과 실제 입력에서의 성공은 다른 조건이다.

분석·번역이 끝나도 실제 실행의 실패는 남는다 · 상태 따라가기

소스를 읽으며 문법이 맞는지 확인한다. 모든 단계에서 프로그램·처리·오류 지점의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.

이 예의 조건

• 그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상소스 프로그램	원 설명사람이 표현한 규칙
대상언어 구조	원 설명문자·문법 분석
대상의미 확인 표현	원 설명이름·자료형·의미 검사
대상실행 형태	원 설명기계 명령·중간 표현
대상실행 중 프로그램	원 설명메모리·호출·외부 자원
대상결과	원 설명출력·오류

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결소스 프로그램 → 언어 구조	원 라벨·방향문법 분석 / 정방향 / 실선
연결언어 구조 → 의미 확인 표현	원 라벨·방향의미 검사 / 정방향 / 실선
연결의미 확인 표현 → 실행 형태	원 라벨·방향번역 / 정방향 / 실선
연결실행 형태 → 실행 중 프로그램	원 라벨·방향자원 준비 / 정방향 / 실선
연결실행 중 프로그램 → 결과	원 라벨·방향입력 실행 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
구문 검사 소스를 읽으며 문법이 맞는지 확인한다.	값·보충 정보 프로그램: 소스 입력 처리·오류 지점: 구문 검사	변화·이유 구문 오류는 런타임 성공 경로로 넘어가지 않는다.
의미 검사·번역 이름·자료형 등 의미를 확인하고 실행 표현을 만든다.	값·보충 정보 프로그램: 의미를 확인한 소스 처리·오류 지점: 번역 결과	변화·이유 문법이 맞아도 의미 오류면 실행 표현을 확정하지 않는다.
실제 실행 런타임은 번역한 프로그램과 실제 입력을 처리한다.	값·보충 정보 프로그램: 실행 중 상태 처리·오류 지점: 출력 또는 런타임 오류	변화·이유 번역 성공과 실제 입력에서의 성공은 다른 조건이다.

그림은 소스 프로그램이 문법 분석과 의미 검사, 번역을 거쳐 실행 형태가 되고, 런타임이 자원을 준비한 뒤 입력을 실행해 출력이나 오류를 내기까지의 다섯 단계다. 예를 들어 괄호가 빠진 오류는 문법 분석에서, 맞지 않는 자료형 연산은 의미 검사에서 찾을 수 있다. 그런데 파일이 실제로 존재하지 않는 문제는 실행 전에는 모를 수 있어 런타임 오류가 된다. 소스를 미리 많이 검사하면 실행 전에 잡는 오류가 늘지만, 사용자 입력과 외부 환경에 의존하는 실패까지 없애지는 못한다.

PR-1: 한 프로그램의 실패를 실행단계에 배치한다

가상 프로그램이 orders.csv를 읽어 각 주문의 합계를 출력한다고 하자.

같은 “프로그램 실패”라도 발견되는 단계와 복구하는 사람이 다르다. 그러니 컴파일 방식이 모든 오류를 실행 전에 찾는다고 결론 내리지 않고, 인터프리터가 번역을 전혀 하지 않는다고 결론 내리지도 않는다.

운영 경로도 실제 값으로 이어 보자. 교육용 배치는 소스판 1과 그 소스를 번역한 실행 산출물(artifact) 1을 사용하고, 입력은 orders.csv에 있는 금액 1200, 수량 3인 주문 하나라고 둔다. 개발자는 괄호·이름·자료형 오류가 없는 실행 산출물을 준비한다. 운영 담당자는 필요한 런타임과 파일 읽기 권한, 결과 저장 위치를 준비한다. 실행은 입력을 읽어 두 숫자를 검사한 뒤 1200×3=3600을 계산하고, 주문번호와 합계를 임시 결과에 쓴다. 모두 성공한 경우에만 그 결과를 완료 결과로 바꾸고 성공 상태를 기록한다. 이 판본과 입력, 단계별 결과가 있어야 같은 실행을 재현할 수 있다.

파일이 없으면 읽기 단계에서 실패코드 입력없음을 남기고 완료 결과를 만들지 않는다. 금액이 ABC라면 숫자 검사에서 금액형식오류를 남기고 계산으로 넘어가지 않는다. 저장에 실패하면 미완료 결과를 완료처럼 읽지 않게 구분한다. 그런 다음 운영 담당자가 저장 위치를 고치고, 같은 주문 결과가 이미 완료되었는지 확인한 뒤 재실행한다. 반대로 문법 오류는 반복 실행으로 해결되지 않는다. 같은 잘못된 문장을 다시 실행할 뿐이므로 개발 수정 단계로 돌려보낸다. 이 작은 사례의 “완료 결과만 외부에 전달” 규칙은 부분 출력과 중복을 구별하려고 세운 교육용 가정이다.

실행 방식을 판단하는 기준

이 표는 절대적인 언어 분류가 아니다. 실제 구현은 두 방식을 결합한다. 그래서 기술을 고를 때는 “컴파일 언어인가?”만 묻지 않는다. 오류를 언제 막아야 하는지, 시작시간과 지속 성능 중 무엇이 중요한지, 어떤 런타임을 배포할 수 있는지를 함께 본다.

흔한 오해와 실패

번역 성공을 실행 성공으로 오해하면 외부 파일이나 권한, 메모리 부족 같은 런타임 실패를 놓친다. 실행 환경의 전제와 실패 경로는 따로 시험해야 한다.

언어와 구현을 같은 것으로 보면, 같은 언어라도 컴파일러와 런타임 버전에 따라 성능과 지원하는 동작이 달라진다는 점을 놓친다. 그래서 언어 규칙과 구체적인 실행 환경을 나누어 기록한다.

환경 의존성을 빠뜨리는 실수는 개발 컴퓨터에만 있는 라이브러리와 설정을 프로그램의 일부로 인식하지 못해 생긴다. 실행에 필요한 런타임과 라이브러리, 설정, 권한을 배포 단위에 포함해야 한다.

오류 단계를 혼동하면 문법 오류를 운영 재시도로 해결하려 하거나, 외부 통신 실패를 재컴파일로 해결하려 한다. 문법, 의미, 번역, 실행, 외부환경 중 어느 단계의 문제인지 먼저 분류한다.

자체 10점 문제

프로그램·프로그래밍 언어·컴파일/해석·런타임의 관계를 설명하시오.

요구어는 설명이다. 소스→언어규칙→번역/해석→실행환경의 순서와, 각 단계에서 어떤 오류를 발견할 수 있는지를 연결한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 프로그램과 언어의 구분
2. 컴파일·해석의 역할
3. 런타임의 실행 지원
4. 오류 발견 단계
5. 혼합 구현의 경계

10점 답안 도식

소스 프로그램은 언어의 문법·의미 규칙에 따라 번역·해석되고, 런타임과 운영체제, 외부 자원을 거쳐 관찰 가능한 결과로 이어진다. 이 경로의 어느 단계에서 어떤 오류가 발견되는지 함께 설명한다.

모범답안 축약본: 소스부터 실행환경까지 구분한다

프로그램은 컴퓨터가 수행할 행동의 규칙이고 프로그래밍 언어는 그 규칙을 적는 문법과 의미 체계다. 컴파일은 소스 전체 또는 일부를 다른 실행형식으로 번역하며 발견 가능한 오류를 검사하고, 인터프리터는 실행 시점에 표현의 의미를 읽어 수행한다. 실제 구현은 중간 표현의 사전 번역과 실행 중 해석처럼 둘을 결합할 수 있다. 런타임은 실행 중 함수 호출, 메모리, 예외와 외부 자원 접근을 관리한다. 따라서 번역에 성공했다고 해서 필요한 라이브러리·설정·권한과 입력이 갖춰져 실제 실행까지 성공한다는 뜻은 아니다. 장애는 문법·자료형 검사·번역·시작·실행·외부환경 단계로 분류하고, 언어 사양과 구체 컴파일러·런타임 버전을 분리해 기록해야 재현과 배포가 가능하다.

자체 25점 문제

주문배치 프로그램의 소스 작성부터 운영 실행까지의 경로와 오류 통제를 설계하시오. 번역단계와 런타임 장애를 구분하시오.

요구어는 설계, 구분이다. 개발, 빌드, 실행, 운영 단계마다 남길 기록과 실패 판정 기준을 한 흐름으로 제시한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 소스·언어 계약
2. 구문·이름·형 검사
3. 번역/패키지 산출물
4. 런타임·파일·메모리·권한
5. 입력검증과 오류 분류
6. 로그·실패코드·재실행
7. 배포판본과 재현
8. 번역 성공과 운영 성공의 분리

25점 답안 도식

실행 경로의 위치	구별할 실패
source	문법 오류
parse/type	이름·자료형 오류
실행 산출물	패키지 오류
런타임	실제 입력·파일·자원 오류

실행 경로에서 실패 위치와 담당자를 연결하고, 번역 전 결함을 운영 재시도로 해결하지 않는다.

25점 모범답안

먼저 주문배치의 소스 판본과 언어·의존성 버전을 고정하고 문법·이름·자료형 검사를 실행한다. 번역 또는 실행 준비가 성공하면 동일한 실행 산출물과 설정을 배포한다. 다만 이 성공을 업무 실행의 성공과 같다고 보지 않는다.

실행 단계에서는 파일 존재와 권한, 입력 자료형, 메모리, 출력 저장소를 검증한다. PR-1처럼 닫는 괄호 누락은 번역 전 오류로, 누락 파일과 잘못된 실제 금액은 런타임 입력·자원 오류로 나눈다. 각 실패에는 판본·입력·단계·오류코드를 남겨 같은 조건으로 재현할 수 있게 한다.

재실행하기 전에는 부분 출력이 남았는지와 중복 처리 가능성을 먼저 확인하고, 안전한 경우에만 실패 지점부터 또는 전체를 다시 수행한다. 소스, 실행 산출물, 런타임, 입력의 판본이 모두 보존되어 있어야 운영 문제를 번역기 문제로 잘못 진단하지 않는다.

구체적으로는 소스판과 실행 산출물 1, 금액 1200·수량 3인 입력을 고정해 합계 3600과 완료 결과를 확인한다. 개발자는 번역 전 결함을 수정하고, 운영 담당자는 입력없음·금액형식오류·저장실패를 단계별 코드로 기록한다. 임시 결과는 완료 결과와 분리하고, 저장에 실패한 뒤에는 이미 완료된 주문인지 확인하고 재실행한다. 판본과 입력, 실패 단계, 결과를 보존한 채 정상 입력, 누락 파일, ABC 금액, 저장실패를 각각 시험한다. 이 조건에서 완료 결과가 없는 실패를 성공으로 보고하는 방식과 문법 오류를 재시도로 처리하는 방식은 제외한다.

출처와 적용 경계

이 절은 안정된 프로그래밍 언어 실행 개념과 자체 주문배치 예를 사용한다. 실행 중 이름 해석과 NameError는 Python Language Reference §4.2.2, 해석과 실행 중 컴파일을 결합하는 구체 예는 V8의 Sparkplug 소개(2021-05-27)에서 확인할 수 있다. 이는 해당 언어와 당시 구현의 예일 뿐이며, 모든 언어의 검사 시점이나 현재 V8의 단계 전체를 그대로 보여 주지는 않는다. 실제 언어가 컴파일·JIT·인터프리트 단계를 어떻게 섞는지와 오류 분류는 해당 구현 문서를 확인한다.

30초 정리

1. 프로그램은 컴퓨터 행동의 규칙이고, 프로그래밍 언어는 그 규칙을 적는 문법과 의미다.
2. 컴파일러와 인터프리터는 소스를 실행 형태로 바꾸거나 실행 중 의미를 수행하며 실제 구현은 둘을 결합할 수 있다.
3. 런타임은 실행 중 메모리·호출·오류·자원을 맡으므로 번역 성공과 실행 성공은 다르다.

자기교정과 조건 변경

조건을 바꿔 보자. 파일이 빌드 때 포함되도록 바뀌면 파일 누락 위험이 packaging 단계로 옮겨 갈 수 있으므로 실행경로를 다시 그린다.

JIT가 실행 중 코드를 다시 번역한다면 사전 compile/interpret 이분법으로 나누지 말고, 실제로 거치는 단계와 각 단계에서 확인할 점을 적는다.

같은 실행 산출물이 한 서버에서만 실패한다면 소스 차이보다 런타임 설정과 권한, 외부자원의 차이를 먼저 비교한다.