컴파일러와 인터프리터
Compiler & Interpreter
컴파일러와 인터프리터란?
- 컴파일러=통째로 미리 번역
- 인터프리터=한 줄씩 실시간 통역
- 언어별 속도·방식 차이
컴파일이냐 인터프리터냐는 개발자 취향 문제가 아니라 '오류를 언제 발견하느냐'와 '무엇을 배포하느냐'를 바꿉니다. 컴파일 언어는 빌드 단계에서 타입이 안 맞거나 함수 이름이 틀리면 실행 전에 걸러냅니다. 인터프리터 언어는 코드가 그 줄에 도달해야 터집니다. 새벽 배치가 다섯 시간을 잘 돌다가 마지막 집계에서 오타 하나로 멈추는 사고는 대부분 여기서 나옵니다. 배포 형태도 달라져서, 한쪽은 실행 파일 하나를 옮기면 끝이지만 다른 쪽은 소스와 런타임 버전·라이브러리를 서버마다 맞춰야 합니다.
요즘 언어는 둘 중 하나로 딱 나뉘지 않습니다. 자바와 C#은 소스를 바이트코드로 컴파일한 뒤 가상머신이 실행하고, 자주 도는 구간은 JIT가 실행 중에 기계어로 다시 번역합니다. 파이썬도 .pyc 캐시를 만들고, 자바스크립트 V8 엔진 역시 JIT를 씁니다. 타입스크립트는 자바스크립트로 바꿔주는 트랜스파일러에 가깝습니다. 그래서 실무에서 의미 있는 구분은 '배포 파이프라인에 빌드 단계가 있느냐'입니다. 빌드가 있으면 CI에서 몇 분을 기다리는 대신 배포본이 고정되고, 없으면 수정 즉시 반영되는 대신 서버마다 환경이 달라 터질 여지가 남습니다.
가장 흔한 오해는 '파이썬이 느리니 C나 자바로 다시 짜자'입니다. 실제로 재작성해 보면 병목은 언어가 아니라 DB 쿼리와 네트워크 왕복인 경우가 대부분이고, 수치 연산 라이브러리는 이미 내부가 C로 짜여 있습니다. 반년을 들여 포팅하고 체감 개선이 미미해 원복하는 사례가 드물지 않습니다. 반대 방향 오해도 있습니다. '컴파일이 통과했으니 안전하다'는 말인데, 컴파일러는 문법과 타입만 볼 뿐 계산 로직이나 데이터 품질은 보지 못합니다. '소스를 안 넘기니 기술이 보호된다'는 생각도 마찬가지로, 실행 파일은 디컴파일과 역분석이 가능합니다.
| 구분 | 컴파일러 | 인터프리터 |
|---|---|---|
| 방식 | 통째로 미리 번역 | 한 줄씩 실시간 통역 |
| 실행 속도 | 빠름 | 상대적 느림 |
| 예 | C·자바 | 파이썬·자바스크립트 |
프로그래밍 언어와 컴퓨터 과학의 기초 개념으로, 언어 처리 방식의 두 축으로 정립됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 320명, 연매출 1,800억 원 규모의 화학 유통사 A사 이야기입니다. 월말 정산을 파이썬 스크립트 40여 개로 돌리는데, 새벽 2시에 시작해 아침 8시가 되어야 끝났습니다. 지난 3월에는 마지막 단계에서 실패해 영업팀 마감이 반나절 밀렸습니다.
- 개발팀 김 차장이 로그를 뒤져 보니 5시간 40분을 정상적으로 돌다가 마지막 집계 함수의 인자 이름 오타 하나로 멈춘 것이었고, 팀장의 첫 마디는 "이걸 돌리기 전에 알 방법이 정말 없었습니까"였습니다.
- CTO는 전면 자바 재작성 제안을 보류하고, 타입 힌트와 정적 검사 도구를 CI에 붙여 커밋마다 2분짜리 사전 점검을 걸었습니다. "통역 시작 전에 원고를 한 번 훑는 단계를 만들자"는 정리였습니다.
- 데이터 엔지니어 박 과장이 6시간 구간을 프로파일링하자 실제 연산 시간은 40분, 나머지 5시간 20분은 DB를 3만 번 왕복하는 쿼리 대기였습니다. 언어가 느린 게 아니라 왕복이 잦았던 것입니다.
- 쿼리를 건별 호출에서 배치 조회로 묶고 무거운 집계만 SQL과 수치 연산 라이브러리로 넘긴 결과, 배치 총 소요 시간이 6시간에서 1시간 50분으로 줄었습니다. 코드 언어는 그대로 파이썬이었습니다.
- 운영 서버 세 대의 파이썬 버전이 3.9와 3.11로 섞여 있던 것도 이때 발견해 컨테이너 이미지로 고정했고, 이후 6개월간 배치 실패가 7건에서 1건으로, 정산 마감 시각은 아침 8시에서 새벽 4시로 앞당겨졌습니다.