프로그램·언어·컴파일러·인터프리터·런타임
개발자가 쓴 total = price * quantity라는 문장은 사람이 읽을 수 있는 규칙이다. CPU가 이 글자를 직접 이해하는 것은 아니다. 언어의 문법과 의미에 따라 소스를 분석하고, 실행 가능한 명령으로 번역하거나 실행 중 해석하며, 메모리·함수 호출·오류를 관리하는 실행 환경이 필요하다.
소스 파일은 혼자서 실행되지 않는다
개발자가 쓴 total = price * quantity라는 문장은 사람이 읽을 수 있는 규칙이다. CPU가 이 글자를 직접 이해하는 것은 아니다. 언어의 문법과 의미에 따라 소스를 분석하고, 실행 가능한 명령으로 번역하거나 실행 중 해석하며, 메모리·함수 호출·오류를 관리하는 실행 환경이 필요하다.
이 식은 “price의 현재 값과 quantity의 현재 값을 곱해 total에 연결한다”는 읽기 예다. *는 곱셈, 여기의 =는 오른쪽에서 구한 값을 왼쪽 이름에 대입하는 표시다. 값을 찾는 이름과 대입의 정확한 동작은 다음 절에서 상태표로 배우며, 여기서는 사람이 적은 규칙이 명령 실행 장치까지 전달되는 경로를 먼저 본다. CPU는 컴퓨터의 중앙처리장치를 가리키며 구체 동작은 뒤 컴퓨터 구조 장의 담당 설명에서 배운다.
오류가 언제 발견되고 어디에서 성능 비용이 생기는지 알려면 소스 코드 → 번역·해석 → 런타임 지원 → 기계 실행 경로를 구분해야 한다. 프로그램·언어·컴파일·런타임은 이 경로의 서로 다른 책임이다.
먼저 되짚기: 프로그램도 입력을 출력으로 바꾸는 규칙이다
입력·처리·출력 모델에서 처리는 입력과 현재 상태에 규칙을 적용하는 변화였다. 프로그램은 그 처리 규칙과 실행 순서를 컴퓨터가 수행할 수 있도록 표현한다. 이번 절은 규칙을 적는 단계에서 실제 실행까지의 경로를 펼친다.
입력·처리·출력에서 실행 가능한 프로그램으로 간다
입력에서 처리 규칙을 거쳐 출력을 만드는 IPO 관계를 컴퓨터가 수행하려면, 처리 규칙을 프로그램으로 표현해야 한다. 프로그램은 언어의 문법·의미를 사용하고 번역·해석과 런타임의 실행 경로를 거친다.
IPO의 처리 규칙을 실제 컴퓨터가 수행하려면 프로그램 표현과 실행경로가 필요하다.
프로그램
프로그램은 입력과 상태에 따라 컴퓨터가 수행할 명령과 규칙의 표현이다. 소스 파일만을 뜻하지 않는다. 실행 순서, 데이터와 상태, 외부 입력·출력, 실패 처리까지 실제 행동을 결정하는 명세와 명령의 집합이다.
프로그래밍 언어 전에 프로그램을 다시 잇는다
프로그램은 입력과 상태에 따라 수행할 명령과 규칙의 표현이다. 이제 그 규칙을 사람이 작성하고 구현이 해석할 공통 문법·의미 체계가 필요하다.
같은 계산도 언어 규칙으로 표현해야 한다
“두 값을 더해 출력한다”는 프로그램 의도를 변수·연산자·호출 문법으로 표현해야 번역기나 실행기가 처리할 수 있다. 프로그램과 프로그래밍 언어를 같은 대상으로 보지 않는다.
프로그래밍 언어
프로그래밍 언어는 계산과 제어를 사람이 작성하고 기계가 해석할 수 있게 표현하는 문법과 의미다. 문법은 어떤 기호 배열이 올바른 문장인지, 의미는 그 문장이 실행될 때 어떤 값을 만들고 상태를 바꾸는지 정한다. 같은 모양의 연산자도 자료형과 언어 규칙에 따라 다른 의미를 가질 수 있다.
번역·해석 전에 언어 규칙을 다시 잇는다
프로그래밍 언어는 올바른 문장과 실행 의미를 정한다. 컴파일러와 인터프리터는 이 규칙을 이용해 소스 표현을 실행 가능한 동작으로 연결한다.
오류가 발견되는 단계도 실행경로의 일부다
문법에 맞지 않는 토큰 배열은 실행 전에 거부될 수 있고, 문법은 맞아도 실행 중 입력이나 자원 때문에 실패할 수 있다. 무엇이 컴파일/해석 단계의 오류이고 무엇이 런타임 실패인지 구분한다.
컴파일과 해석
컴파일은 프로그램 표현을 다른 실행 형식으로 번역하는 일이고, 해석은 표현의 의미에 따라 동작을 수행하는 일이다. 컴파일러(compiler)는 소스나 중간 표현의 구조와 의미를 분석해 기계 명령 또는 다른 중간 표현으로 변환한다. 번역 시점은 실행 전일 수도, 실행 중일 수도 있다. 인터프리터(interpreter)는 프로그램을 실행하는 동안 소스 또는 중간 표현을 읽고 그 의미에 해당하는 동작을 수행한다. 실제 언어 구현은 미리 번역한 중간 표현을 실행 중 다시 최적화하는 등 두 방식을 섞을 수 있다.
실행 중 필요해진 코드 부분을 그때 번역하는 방식을 JIT(Just-In-Time, 적시 컴파일)라고 부른다. 따라서 미리 번역하는 단계와 실행 중 번역·해석하는 단계가 한 구현 안에 함께 있을 수 있다. 어느 언어 이름 하나만 보고 오류 발견 시점이나 실행비용을 확정하지 않는다.
런타임 전에 번역 결과를 다시 잇는다
컴파일과 해석은 소스 표현을 실행 가능한 동작으로 연결하는 방식이다. 번역된 코드가 실제 메모리·호출·예외·운영체제 자원을 사용하려면 실행환경이 더 필요하다.
번역 성공은 실행 성공이 아니다
소스가 번역되었더라도 실행 시 필요한 파일이 없거나 메모리가 부족하거나 입력이 잘못되면 실패할 수 있다. 번역 단계와 런타임 단계의 관찰점을 분리한다.
런타임
런타임(runtime)은 프로그램 실행 중 메모리·호출·오류·자원을 지원하는 환경이다. 언어에 따라 값의 메모리를 회수하고, 함수 호출 상태를 관리하며, 예외를 전달하고, 운영체제 기능을 사용할 연결을 제공한다. 번역이 끝났다고 런타임의 책임이 사라지는 것은 아니다.
코드가 실행되는 다섯 단계
분석·번역이 끝나도 실제 실행의 실패는 남는다 · 상태 따라가기
소스를 읽으며 문법이 맞는지 확인한다. 모든 단계에서 프로그램·처리·오류 지점의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
이 예의 조건
- 그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 소스 프로그램 | 사람이 표현한 규칙 |
| 언어 구조 | 문자·문법 분석 |
| 의미 확인 표현 | 이름·자료형·의미 검사 |
| 실행 형태 | 기계 명령·중간 표현 |
| 실행 중 프로그램 | 메모리·호출·외부 자원 |
| 결과 | 출력·오류 |
| 연결 | 원 라벨·방향 |
|---|---|
| 소스 프로그램 → 언어 구조 | 문법 분석 / 정방향 / 실선 |
| 언어 구조 → 의미 확인 표현 | 의미 검사 / 정방향 / 실선 |
| 의미 확인 표현 → 실행 형태 | 번역 / 정방향 / 실선 |
| 실행 형태 → 실행 중 프로그램 | 자원 준비 / 정방향 / 실선 |
| 실행 중 프로그램 → 결과 | 입력 실행 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 구문 검사 소스를 읽으며 문법이 맞는지 확인한다. |
|
|
| 의미 검사·번역 이름·자료형 등 의미를 확인하고 실행 표현을 만든다. |
|
|
| 실제 실행 런타임은 번역한 프로그램과 실제 입력을 처리한다. |
|
|
분석·번역이 끝나도 실제 실행의 실패는 남는다 · 상태 따라가기
소스를 읽으며 문법이 맞는지 확인한다. 모든 단계에서 프로그램·처리·오류 지점의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
이 예의 조건
- 그림은 소스를 사전 검사·번역해 실행하는 한 경로다. 이름·자료형 검사의 범위와 시점은 언어에 따라 다르며 일부 오류는 실행 중 드러난다. 런타임은 메모리·호출·외부 자원을 준비하고 입력을 읽어 상태를 바꾸며 출력 또는 오류를 낸다. 번역 성공과 외부 파일·권한·입력·저장까지 포함한 실행 성공은 다르다. 실제 구현은 사전 번역과 실행 중 해석을 섞을 수 있다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 소스 프로그램 | 사람이 표현한 규칙 |
| 언어 구조 | 문자·문법 분석 |
| 의미 확인 표현 | 이름·자료형·의미 검사 |
| 실행 형태 | 기계 명령·중간 표현 |
| 실행 중 프로그램 | 메모리·호출·외부 자원 |
| 결과 | 출력·오류 |
| 연결 | 원 라벨·방향 |
|---|---|
| 소스 프로그램 → 언어 구조 | 문법 분석 / 정방향 / 실선 |
| 언어 구조 → 의미 확인 표현 | 의미 검사 / 정방향 / 실선 |
| 의미 확인 표현 → 실행 형태 | 번역 / 정방향 / 실선 |
| 실행 형태 → 실행 중 프로그램 | 자원 준비 / 정방향 / 실선 |
| 실행 중 프로그램 → 결과 | 입력 실행 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 구문 검사 소스를 읽으며 문법이 맞는지 확인한다. |
|
|
| 의미 검사·번역 이름·자료형 등 의미를 확인하고 실행 표현을 만든다. |
|
|
| 실제 실행 런타임은 번역한 프로그램과 실제 입력을 처리한다. |
|
|
괄호가 빠진 오류는 문법 분석에서, 맞지 않는 자료형 연산은 의미 검사에서 찾을 수 있다. 파일이 실제로 존재하지 않는 문제는 실행 전에는 모를 수 있어 런타임 오류가 된다. 소스를 미리 많이 검사하면 실행 전에 잡는 오류가 늘지만, 사용자 입력과 외부 환경에 의존하는 실패까지 없애지는 못한다.
PR-1: 한 프로그램의 실패를 실행단계에 배치한다
가상 프로그램이 orders.csv를 읽어 각 주문의 합계를 출력한다고 하자.
| 상황 | 가장 먼저 확인할 단계 | 이유 |
|---|---|---|
| 닫는 괄호가 빠짐 | 문법 분석·번역 | 올바른 프로그램 문장이 아님 |
| 존재하지 않는 함수 이름 | 정적 검사 또는 실행 중 이름 해석(언어에 따라 다름) | 이름 해석 계약 위반 |
번역은 성공했지만 orders.csv 없음 | 런타임 | 실행 시 외부 자원이 없음 |
파일은 있으나 한 행의 금액이 "ABC" | 런타임 입력·자료형 경계 | 실제 입력값이 계약을 위반 |
| 모든 입력 정상, 결과 저장 중 디스크 오류 | 런타임 자원 경계 | 실행 중 외부 자원 실패 |
같은 “프로그램 실패”라도 발견 단계와 복구 주체가 다르다. 컴파일 방식이 모든 오류를 실행 전에 찾는다는 결론도, 인터프리터가 번역을 전혀 하지 않는다는 결론도 내리지 않는다.
운영 경로도 실제 값으로 이어 보자. 교육용 배치는 소스판 1과 그 소스를 번역한 실행 산출물(artifact) 1을 사용하고, 입력은 orders.csv의 금액 1200·수량 3인 한 주문이라고 둔다. 개발자는 괄호·이름·자료형 오류가 없는 실행 산출물을 준비하고 운영 담당자는 필요한 런타임·파일 읽기 권한·결과 저장 위치를 준비한다. 실행은 입력을 읽어 두 숫자를 검사한 뒤 1200×3=3600을 계산하고 주문번호와 합계를 임시 결과에 쓴다. 모두 성공한 경우에만 그 결과를 완료 결과로 바꾸고 성공 상태를 기록한다. 이 판본·입력·단계별 결과가 재현에 필요한 산출물이다.
파일이 없으면 읽기 단계에서 실패코드 입력없음을 남겨 완료 결과를 만들지 않는다. 금액이 ABC라면 숫자 검사에서 금액형식오류를 남기고 계산으로 진행하지 않는다. 저장에 실패하면 미완료 결과를 완료처럼 읽지 않게 구분하며 운영 담당자가 저장 위치를 고친 뒤 같은 주문 결과가 이미 완료되었는지 확인하고 재실행한다. 문법 오류를 반복 실행으로 해결하는 대안은 같은 잘못된 문장을 다시 실행할 뿐이므로 개발 수정 단계로 돌려보낸다. 이 작은 사례의 “완료 결과만 외부에 전달” 규칙은 부분 출력과 중복을 구별하기 위한 교육용 가정이다.
실행 방식을 판단하는 기준
| 관점 | 미리 번역 비중이 큰 방식 | 실행 중 해석 비중이 큰 방식 |
|---|---|---|
| 오류 발견 | 실행 전 발견 범위를 넓히기 쉽다 | 실제 경로를 실행할 때 드러날 수 있다 |
| 시작과 반복 실행 | 번역 시간이 먼저 들고 반복 실행은 빠를 수 있다 | 바로 시작하기 쉽지만 반복 해석 비용이 들 수 있다 |
| 배포 대상 | 대상 환경용 실행 형태가 필요할 수 있다 | 해석 환경이 있는 곳에서 같은 표현을 쓸 수 있다 |
| 최적화 정보 | 전체 프로그램을 미리 분석 가능 | 실행 중 실제 동작 정보를 활용 가능 |
이 표는 절대적인 언어 분류가 아니다. 구현은 두 방식을 결합한다. 기술을 고를 때는 “컴파일 언어인가?”만 묻지 말고 오류를 언제 막아야 하는지, 시작시간과 지속 성능 중 무엇이 중요한지, 어떤 런타임을 배포할 수 있는지 본다.
흔한 오해와 실패
번역 성공을 실행 성공으로 오해하면 외부 파일·권한·메모리 부족 같은 런타임 실패를 놓친다. 실행 환경의 전제와 실패 경로를 따로 시험한다.
언어와 구현을 동일시하면 같은 언어라도 컴파일러·런타임 버전에 따라 성능과 동작 지원이 달라지는 점을 놓친다. 언어 규칙과 구체 실행 환경을 분리해 기록한다.
환경 의존성 누락은 개발 컴퓨터에만 있는 라이브러리와 설정을 프로그램의 일부로 인식하지 못한 경우다. 실행에 필요한 런타임·라이브러리·설정·권한을 배포 단위에 포함한다.
오류 단계 혼동은 문법 오류를 운영 재시도로 해결하거나 외부 통신 실패를 재컴파일로 해결하려는 경우다. 문법·의미·번역·실행·외부환경 중 어느 단계인지 먼저 분류한다.
자체 10점 문제
프로그램·프로그래밍 언어·컴파일/해석·런타임의 관계를 설명하시오.
요구어는 설명이다. 소스→언어규칙→번역/해석→실행환경의 순서와 오류 발견 경계를 연결한다.
10점 풀이 방향과 모범답안 보기
10점 답안 목차
- 프로그램과 언어의 구분
- 컴파일·해석의 역할
- 런타임의 실행 지원
- 오류 발견 단계
- 혼합 구현의 경계
10점 답안 도식
소스 프로그램은 언어 문법·의미 계약을 사용해 번역·해석되고, 런타임·운영체제·외부 자원을 통해 관찰 가능한 결과로 이어진다. 이 경로의 오류 발견 경계를 함께 설명한다.
모범답안 축약본: 소스부터 실행환경까지 구분한다
문제: 프로그램·프로그래밍 언어·컴파일/해석·런타임의 관계를 설명하시오. 프로그램은 컴퓨터가 수행할 행동의 규칙이고 프로그래밍 언어는 그 규칙을 적는 문법과 의미 체계다. 컴파일은 소스 전체 또는 일부를 다른 실행형식으로 번역하며 발견 가능한 오류를 검사하고, 인터프리터는 실행 시점에 표현의 의미를 읽어 수행한다. 실제 구현은 중간 표현의 사전 번역과 실행 중 해석처럼 둘을 결합할 수 있다. 런타임은 실행 중 함수 호출, 메모리, 예외와 외부 자원 접근을 관리한다. 따라서 번역 성공은 필요한 라이브러리·설정·권한과 입력이 갖춰져 실제 실행이 성공한다는 보장이 아니다. 장애는 문법·형검사·번역·시작·실행·외부환경 단계로 분류하고, 언어 사양과 구체 컴파일러·런타임 버전을 분리해 기록해야 재현과 배포가 가능하다.
자체 25점 문제
주문배치 프로그램의 소스 작성부터 운영 실행까지의 경로와 오류 통제를 설계하시오. 번역단계와 런타임 장애를 구분하시오.
요구어는 설계, 구분이다. 개발·빌드·실행·운영의 증거와 실패 판정을 한 흐름으로 제시한다.
25점 풀이 방향과 모범답안 보기
25점 답안 목차
- 소스·언어 계약
- 구문·이름·형 검사
- 번역/패키지 산출물
- 런타임·파일·메모리·권한
- 입력검증과 오류 분류
- 로그·실패코드·재실행
- 배포판본과 재현
- 번역 성공과 운영 성공의 분리
25점 답안 도식
| 실행 경로의 위치 | 구별할 실패 |
|---|---|
| source | 문법 오류 |
| parse/type | 이름·자료형 오류 |
| artifact | 패키지 오류 |
| runtime | 실제 입력·파일·자원 오류 |
실행 경로에서 실패 위치와 담당자를 연결하고, 번역 전 결함을 운영 재시도로 해결하지 않는다.
25점 모범답안
먼저 주문배치의 소스 판본과 언어·의존성 버전을 고정하고 문법·이름·자료형 검사를 실행한다. 번역 또는 실행 준비가 성공하면 동일한 artifact와 설정을 배포하며, 이 성공을 업무 실행 성공과 같다고 보지 않는다.
실행 단계에서는 파일 존재·권한·입력 자료형·메모리·출력 저장소를 검증한다. PR-1처럼 닫는 괄호 누락은 번역 전 오류, 누락 파일과 잘못된 실제 금액은 런타임 입력·자원 오류로 분리한다. 각 실패에는 판본·입력·단계·오류코드를 남겨 같은 조건으로 재현한다.
재실행은 부분 출력이 남는지와 중복 처리 가능성을 먼저 확인하고, 안전한 경우에만 실패 지점부터 또는 전체를 다시 수행한다. 소스·artifact·runtime·입력의 좌표가 모두 보존되어야 운영 문제를 번역기 문제로 오진하지 않는다.
구체적으로 소스판·실행 산출물 1, 금액 1200·수량 3인 입력을 고정해 합계 3600과 완료 결과를 확인한다. 개발자는 번역 전 결함을 수정하고 운영 담당자는 입력없음·금액형식오류·저장실패를 단계별 코드로 기록한다. 임시 결과는 완료 결과와 분리하며 저장 실패 뒤에는 이미 완료된 주문인지 확인한 뒤 재실행한다. 판본·입력·실패 단계·결과를 보존하고 정상 입력, 누락 파일, ABC 금액, 저장실패를 각각 시험한다. 이 조건에서 완료 결과가 없는 실패를 성공으로 보고하거나 문법 오류를 재시도로 처리하는 대안은 제외한다.
출처와 적용 경계
이 절은 안정된 프로그래밍 언어 실행 개념과 자체 주문배치 예를 사용한다. 실행 중 이름 해석과 NameError는 Python Language Reference §4.2.2, 해석과 실행 중 컴파일을 결합하는 구체 예는 V8의 Sparkplug 소개(2021-05-27)에서 확인할 수 있다. 이는 해당 언어·당시 구현의 예이며 모든 검사 시점이나 현재 V8 단계 전체를 고정하지 않는다. 실제 언어가 컴파일·JIT·인터프리트 단계를 어떻게 섞는지와 오류 분류는 해당 구현 문서를 확인한다.
30초 정리
- 프로그램은 컴퓨터 행동의 규칙이고, 프로그래밍 언어는 그 규칙을 적는 문법과 의미다.
- 컴파일러와 인터프리터는 소스를 실행 형태로 바꾸거나 실행 중 의미를 수행하며 실제 구현은 둘을 결합할 수 있다.
- 런타임은 실행 중 메모리·호출·오류·자원을 맡으므로 번역 성공과 실행 성공은 다르다.
자기교정과 조건 변경
| 잘못 쓴 답 | 수정 | 복습 |
|---|---|---|
| 컴파일이 성공하면 프로그램도 정상 실행된다 | 파일·권한·입력·메모리 같은 런타임 실패를 별도로 본다 | PR-1 |
| 인터프리터는 번역을 전혀 하지 않는다 | 실제 구현은 중간표현·JIT 등 단계를 섞을 수 있다 | 비교 |
| 소스 파일 자체가 실행 중 프로그램이다 | 프로그램 표현과 실행 인스턴스·런타임을 구분한다 | 프로그램 |
| 문법 오류와 입력파일 누락은 같은 종류다 | 발견 단계와 복구 주체가 다르다 | PR-1 |
| 오류가 늦게 나면 언어가 잘못된 것이다 | 언어 규칙과 실제 입력·자원 실패를 분리한다 | 실패 |
파일이 빌드 때 포함되도록 바뀌면? 누락 파일 위험의 위치가 packaging 단계로 이동할 수 있으므로 실행경로를 다시 그린다.
JIT가 실행 중 코드를 다시 번역한다면? 사전 compile/interpret 이분법 대신 실제 단계와 관찰점을 적는다.
같은 artifact가 한 서버에서만 실패한다면? 소스 차이보다 runtime 설정·권한·외부자원 차이를 우선 비교한다.