김신건의 로그 - 위키 / plt

[PLT] Abstract Syntax Tree (AST)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Abstract Syntax Tree (AST, 추상 구문 트리) 는 프로그램의 문법 구조를 트리로 표현 한 자료구조입니다. 파서의 출력물이자, 이후 컴파일러/인터프리터의 거의 모든 단계 (semantic 분석, 최적화, 코드 생성) 의 입력.

핵심: 소스 코드의 본질적 구조 만 남기고, 문법 세부 (괄호, 세미콜론, 공백) 제거.

왜 트리인가

프로그래밍 언어의 구조는 자연스럽게 재귀적:

함수는 statement 들의 목록
statement 는 expression 을 포함
expression 은 다른 expression 을 포함

트리 = 재귀 구조 표현의 자연스러운 자료구조.

AST 예시

소스 코드:

if (x > 0) {
  y = x * 2;
} else {
  y = 0;
}

AST:

flowchart TD
  Root["IfStatement"]
  Root --> Cond["BinaryOp: >"]
  Root --> Then["Block"]
  Root --> Else["Block"]

  Cond --> C1["Identifier: x"]
  Cond --> C2["Number: 0"]

  Then --> Assign1["Assignment"]
  Assign1 --> T1["Identifier: y"]
  Assign1 --> T2["BinaryOp: *"]
  T2 --> T3["Identifier: x"]
  T2 --> T4["Number: 2"]

  Else --> Assign2["Assignment"]
  Assign2 --> E1["Identifier: y"]
  Assign2 --> E2["Number: 0"]

각 노드는 의미 있는 구조:

IfStatement: cond, then, else 세 자식
BinaryOp: op, left, right
Assignment: target, value
Block: statements 리스트

AST vs Parse Tree (Concrete Syntax Tree)

두 개념 자주 혼동.

Parse Tree (CST)

문법 규칙을 그대로 반영. 모든 non-terminal 이 노드.

Expression
├── Term
│   ├── Factor
│   │   └── Number(2)
│   └── OP(+)
│   └── Term
│       ├── Factor
│       │   └── Number(3)
│       └── OP(*)
│       └── Factor
│           └── Number(4)

2 + 3 * 4 의 CST 는 Expression → Term → Factor 등 중간 노드 다수.

AST

본질 구조만:

BinaryOp(+)
├── Number(2)
└── BinaryOp(*)
    ├── Number(3)
    └── Number(4)

간결. 이후 처리에 유리.

언제 CST 유지?:

소스 코드 포매터 (원본 재구성 필요)
리팩터링 도구 (주석/공백 보존)
IDE (원본 위치 정확성)

AST 노드 정의 (TypeScript 예시)

// 표현식
type Expression =
  | NumberLiteral
  | StringLiteral
  | BooleanLiteral
  | Identifier
  | BinaryOp
  | UnaryOp
  | Call
  | MemberAccess
  | Assignment;

interface NumberLiteral {
  kind: 'NumberLiteral';
  value: number;
  location: SourceLocation;
}

interface Identifier {
  kind: 'Identifier';
  name: string;
  location: SourceLocation;
}

interface BinaryOp {
  kind: 'BinaryOp';
  op: '+' | '-' | '*' | '/' | '==' | '<' | '>' | '&&' | '||';
  left: Expression;
  right: Expression;
  location: SourceLocation;
}

interface UnaryOp {
  kind: 'UnaryOp';
  op: '-' | '!' | '++' | '--';
  operand: Expression;
  location: SourceLocation;
}

interface Call {
  kind: 'Call';
  callee: Expression;
  args: Expression[];
  location: SourceLocation;
}

// 문장
type Statement =
  | ExpressionStatement
  | VariableDeclaration
  | IfStatement
  | WhileStatement
  | ReturnStatement
  | FunctionDeclaration
  | Block;

interface IfStatement {
  kind: 'IfStatement';
  condition: Expression;
  thenBranch: Statement;
  elseBranch?: Statement;
  location: SourceLocation;
}

interface FunctionDeclaration {
  kind: 'FunctionDeclaration';
  name: string;
  params: Identifier[];
  body: Block;
  location: SourceLocation;
}

interface SourceLocation {
  file: string;
  line: number;
  column: number;
}

AST 순회 (Traversal)

AST 를 처리할 때 대부분 재귀 순회.

Depth-First

function visit(node):
    switch node.kind:
        case 'NumberLiteral':
            processNumber(node)
        case 'BinaryOp':
            visit(node.left)
            visit(node.right)
            processBinaryOp(node)
        case 'IfStatement':
            visit(node.condition)
            visit(node.thenBranch)
            if node.elseBranch:
                visit(node.elseBranch)
            processIf(node)
        ...

방문 시점

Pre-order: 자식 방문 전 노드 처리
Post-order: 자식 모두 방문 후 노드 처리
In-order: 이진 트리 특수 (프로그래밍 언어 AST 는 잘 안 씀)

Visitor Pattern

전형적 OOP 패턴:

interface Visitor<T> {
  visitNumber(node: NumberLiteral): T;
  visitBinaryOp(node: BinaryOp): T;
  visitIdentifier(node: Identifier): T;
  visitIf(node: IfStatement): T;
  // ...
}

class Evaluator implements Visitor<Value> {
  visitNumber(node) {
    return node.value;
  }
  visitBinaryOp(node) {
    const left = this.visit(node.left);
    const right = this.visit(node.right);
    return applyOp(node.op, left, right);
  }
  visitIdentifier(node) {
    return this.env.get(node.name);
  }
  // ...

  visit(node): Value {
    switch (node.kind) {
      case 'NumberLiteral': return this.visitNumber(node);
      case 'BinaryOp': return this.visitBinaryOp(node);
      case 'Identifier': return this.visitIdentifier(node);
      // ...
    }
  }
}

Discriminated union + switch 방식 (TypeScript, Rust 스타일) 이 최근 관용.

AST 변환 (Transformation)

새 AST 를 만들어 반환하는 함수:

function replaceConstants(node: Expression): Expression {
  if (node.kind === 'Identifier' && node.name === 'PI') {
    return { kind: 'NumberLiteral', value: 3.14159, location: node.location };
  }
  if (node.kind === 'BinaryOp') {
    return {
      ...node,
      left: replaceConstants(node.left),
      right: replaceConstants(node.right),
    };
  }
  return node;
}

Babel plugin, TypeScript transformer, ESLint auto-fix 가 이 패턴.

실전 사용 사례

1. 인터프리터

AST 순회하며 실행. Tree-walking interpreter.

function evaluate(node: Expression, env: Environment): Value {
  switch (node.kind) {
    case 'NumberLiteral': return node.value;
    case 'BinaryOp':
      const l = evaluate(node.left, env);
      const r = evaluate(node.right, env);
      return applyOp(node.op, l, r);
    case 'Identifier':
      return env.lookup(node.name);
  }
}

Crafting Interpreters 의 첫 인터프리터.

2. 컴파일러 (코드 생성)

AST → 목표 코드:

NumberLiteral 42       → PUSH 42
BinaryOp(+, l, r)      → visit(l); visit(r); ADD

3. 정적 분석 / 린터

ESLint 는 AST 를 순회하며 규칙 적용:

// no-unused-vars 규칙
Program(node) {
  const declared = collectDeclared(node);
  const used = collectUsed(node);
  for (const varName of declared) {
    if (!used.has(varName)) {
      report(`Unused variable: ${varName}`);
    }
  }
}

4. 트랜스파일러

Babel: ES2020+ AST → ES5 AST (다운그레이드).

TypeScript: TS AST → JS AST + 별도 타입 검사.

5. IDE 지원

자동완성: 커서 위치 AST 노드 확인
Go to definition: identifier → declaration
Rename: 같은 심볼의 모든 참조 재작성
포매팅: AST → 표준 형식으로 재출력 (Prettier)

6. Code Mods (자동 리팩터링)

jscodeshift, ts-morph: 대규모 자동 리팩터링. AST 변환.

AST Explorer

https://astexplorer.net/ 에서 여러 언어 파서의 AST 를 실시간 확인 가능. 학습 필수 도구.

예: JavaScript const x = 42; 의 AST:

{
  "type": "Program",
  "body": [
    {
      "type": "VariableDeclaration",
      "kind": "const",
      "declarations": [
        {
          "type": "VariableDeclarator",
          "id": { "type": "Identifier", "name": "x" },
          "init": { "type": "Literal", "value": 42 }
        }
      ]
    }
  ]
}

언어별 AST 표기법

JavaScript

ESTree 명세: 사실상 표준. Acorn, Babel, ESLint 채택.
SWC AST, Oxc AST: Rust 기반 최근 도구, 대부분 ESTree 호환.

TypeScript

TypeScript 자체 컴파일러 AST. ESTree 와 다름 (typescript-eslint 는 변환).

Python

ast 모듈. ast.parse(source) → AST.

import ast
tree = ast.parse("x = 42")
print(ast.dump(tree))

Rust

rustc_ast, syn (proc macro 용).

Go

go/ast 표준 패키지.

함정

[!WARNING] Source location 저장. AST 노드에 원본 위치 (파일/줄/열) 없으면 에러 메시지 최악.

[!CAUTION] 주석/공백 처리. Prettier / 포매터 하려면 AST 에 관련 정보 유지 필요. 대부분 컴파일러는 버림.

[!WARNING] AST 재사용 시 immutable 지향. 변환은 새 AST 생성. 원본 수정은 버그 온상.

[!IMPORTANT] Discriminated union + switch 가 OOP visitor 보다 현대적. TypeScript exhaustive check.

[!CAUTION] AST 순회 순서가 의미 결정. Pre-order 인지 post-order 인지 명확히 (예: 순회 중 변수 정의 발견 순서).

[PLT] Interpreter vs Compiler

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

프로그래밍 언어의 실행 모델 두 접근:

Compiler (컴파일러): 소스 → 목표 코드 (기계어, 바이트코드) 로 변환. 실행은 나중.
Interpreter (인터프리터): 소스 (또는 AST) 를 직접 실행. 별도 목표 코드 없음.

현대는 하이브리드. 순수 컴파일러/인터프리터는 드묾. JIT, 바이트코드 VM 등 조합.

Compiler 파이프라인

flowchart LR
  Src[Source] --> L[Lexer] --> P[Parser] --> A[AST]
  A --> S[Semantic] --> IR[IR Gen] --> Opt[Optimizer]
  Opt --> CG[Code Gen] --> Bin[Machine Code / Bytecode]
  Bin --> R[Runtime Execution]

Ahead-Of-Time (AOT): 실행 전 전체 컴파일.

예: C, C++, Rust, Go, Swift (native), Kotlin/Native.

Interpreter 파이프라인

flowchart LR
  Src[Source] --> L[Lexer] --> P[Parser] --> A[AST]
  A --> E[Evaluator]
  E --> Out[Output]

Tree-walking interpreter: AST 순회하며 실행.

예: 초기 Python (인터프리티브), Ruby MRI 초기, Lua 5.1, PHP 초기.

Tree-Walking Interpreter (의사코드)

evaluate(node, env):
    switch node.kind:
        case NumberLiteral:
            return node.value

        case BinaryOp:
            l = evaluate(node.left, env)
            r = evaluate(node.right, env)
            return applyOp(node.op, l, r)

        case Identifier:
            return env.lookup(node.name)

        case Assignment:
            v = evaluate(node.value, env)
            env.set(node.target.name, v)
            return v

        case IfStatement:
            if isTruthy(evaluate(node.cond, env)):
                return evaluate(node.then, env)
            elif node.else:
                return evaluate(node.else, env)

        case WhileLoop:
            while isTruthy(evaluate(node.cond, env)):
                evaluate(node.body, env)

        case FunctionCall:
            fn = evaluate(node.callee, env)
            args = [evaluate(a, env) for a in node.args]
            return callFunction(fn, args)

장점: 단순, 이해 쉬움. 단점: 느림. 매 노드가 dict lookup + case switch.

Bytecode VM

Tree-walking 을 개선. AST → 바이트코드 (스택 기반 명령) 로 컴파일 후 VM 이 실행.

Source: 1 + 2 * 3

Compile to bytecode:
  PUSH 1
  PUSH 2
  PUSH 3
  MUL
  ADD

VM 실행:
  스택: [1, 2, 3]
  MUL: 2*3=6, 스택 [1, 6]
  ADD: 1+6=7, 스택 [7]

예: CPython (bytecode + VM), JVM (bytecode + JIT), .NET (CIL + JIT), Lua (bytecode).

장점:

Tree-walking 대비 훨씬 빠름 (10-100배)
Portable (VM 만 있으면 어디서든)
최적화 여지

단점:

컴파일 단계 필요
VM 자체 오버헤드

JIT (Just-In-Time)

바이트코드 (또는 소스) 를 실행 중 native 기계어로 컴파일.

Warm-up: 초기에는 인터프리터 (또는 baseline 컴파일)
Hot path 감지: 자주 실행되는 코드 발견
Optimizing JIT: hot path 를 최적화된 native 로 재컴파일
Deoptimization: 가정 (타입, inline) 이 깨지면 인터프리터로 fallback

예:

V8 (Chrome, Node.js): Ignition (interpreter) + TurboFan/Maglev (JIT)
HotSpot (Java): C1/C2 컴파일러
LuaJIT: 세계에서 가장 빠른 JIT
PyPy: Python JIT
SpiderMonkey (Firefox): Ion, Warp

성능: JIT 언어는 종종 C++ 성능의 50-90% 도달.

AOT vs JIT vs Interpreter

축	AOT	JIT	Interpreter
시작 속도	빠름 (컴파일 완료)	느림 (warm-up)	빠름 (파싱만)
최대 성능	최고	매우 높음	낮음
동적 최적화	불가	가능 (runtime info)	불가
배포 크기	큼 (native binary)	작음 (bytecode)	소스
크로스 플랫폼	재컴파일	VM 있으면	인터프리터 있으면
개발 iteration	느림	빠름	매우 빠름
예	C, Rust, Go	Java, V8	Bash, 초기 Ruby

하이브리드 (현대)

대부분 현대 언어는 여러 접근 조합:

JavaScript (V8)

Parse → AST
Ignition: bytecode 인터프리터 (빠른 시작)
Sparkplug: baseline JIT (한 번 실행된 함수)
Maglev: mid-tier JIT
TurboFan: optimizing JIT (hot 함수)
Deoptimization: 가정 깨지면 이전 계층으로

Java (HotSpot)

javac → bytecode (.class)
Interpreter (인터프리팅)
C1 compiler (client JIT, 빠른 컴파일)
C2 compiler (server JIT, 고급 최적화)

Python (CPython)

Parse → AST
Compile → bytecode (.pyc)
VM 실행
(PyPy: JIT 추가)

C# (.NET)

Roslyn → CIL
RyuJIT 또는 AOT (Native AOT)

Transpiler (소스-대-소스 컴파일러)

소스 → 다른 소스.

Babel: 최신 JS → 옛 JS (호환성)
TypeScript: TS → JS (타입 제거)
Kotlin → JVM/JS/Native
CoffeeScript → JS (legacy)
Vue SFC compiler: .vue → JS
Sass → CSS

차이점: 컴파일러이지만 목표가 기계어가 아닌 다른 고급 언어.

Cross-Compilation

한 플랫폼에서 다른 플랫폼용 바이너리 생성.

Rust: cargo build --target=x86_64-unknown-linux-gnu
Go: GOOS=linux GOARCH=amd64 go build
임베디드 (Rust, C): x86 머신에서 ARM 바이너리

REPL (Read-Eval-Print Loop)

인터프리터의 확장. 사용자 입력 즉시 실행.

예: Python REPL, Node.js, GHCi (Haskell), rusti (Rust).

컴파일 언어도 REPL 가능: Kotlin, Scala (컴파일 후 실행).

Meta-Circular Interpreter

언어 X 로 X 를 구현. Lisp 이 유명.

예: JavaScript 로 JavaScript 파서 (Acorn, Babel).

장점: bootstrap, self-hosting.

Interpreter vs Compiler 선택 기준

컴파일러가 좋을 때:

성능 우선 (게임, 시스템)
배포 크기 (native binary)
최적화 여지 극대화

인터프리터가 좋을 때:

개발 iteration 빠름
동적 (eval, reflection)
이식성 우선 (같은 소스 여러 플랫폼)

JIT 가 좋을 때:

두 이익 모두 (개발 편의 + 성능)
런타임 정보 활용 (동적 타입 최적화)

함정

[!WARNING] 인터프리티드 언어 = 느림 은 오해. JIT (V8, LuaJIT, HotSpot) 는 C 급 성능.

[!CAUTION] JIT warmup. 짧은 CLI 프로그램은 JIT 이점 없음. Java 는 특히 startup 느림 → AOT (GraalVM) 로 해결.

[!WARNING] Bytecode 도 크로스플랫폼 아님. JVM 바이트코드는 JVM 필요. WASM 은 다양한 호스트.

[!IMPORTANT] Transpiler 도 컴파일러. AST 변환은 동일. 다만 출력이 소스 코드.

[!CAUTION] Tree-walking interpreter 는 프로덕션 부적합. 학습용. 실전은 bytecode + JIT.

[PLT] IR, 최적화, 코드 생성 (Compiler Backend)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

컴파일러의 백엔드 는 semantic 분석까지 마친 AST 를 실제 실행 가능한 목표 코드로 변환합니다. 세 주요 단계:

IR (Intermediate Representation) 생성: AST → 중간 표현
최적화: IR 을 더 효율적인 IR 로 변환
코드 생성: IR → 목표 코드 (native, bytecode, WASM)

이 문서는 세 단계를 통합 소개합니다.

왜 IR 인가

AST 는 언어 특유의 구조. 그대로 다루면:

언어마다 다른 최적화 코드
아키텍처마다 다른 코드 생성

IR 은 언어 독립 + 아키텍처 독립 중간 지점:

[C 소스] ─┐              ┌─→ [x86 어셈블리]
[Rust]  ─┼─→ [LLVM IR] ─┼─→ [ARM 어셈블리]
[Swift] ─┘              └─→ [WASM]

LLVM 이 이 개념의 극한. LLVM IR 은 사실상 산업 표준.

IR 종류

1. AST 자체

가장 원시. 처리 어려움. 트리 순회 인터프리터 급.

2. Three-Address Code (TAC)

각 명령이 최대 3개 피연산자 (source1, source2, destination):

t1 = a + b
t2 = t1 * c
t3 = t2 + 1
d = t3

원본:

d = (a + b) * c + 1

한 명령 = 한 연산. 최적화하기 쉬움.

3. Static Single Assignment (SSA)

각 변수는 정확히 한 번 할당. 새 값은 새 변수 이름.

// 원본
x = 1
x = x + 1
x = x * 2

// SSA
x_1 = 1
x_2 = x_1 + 1
x_3 = x_2 * 2

Phi 함수 (Φ)

분기 후 합류 시 어떤 정의를 선택:

if cond:
    x = 1        // x_1 = 1
else:
    x = 2        // x_2 = 2
y = x + 1        // x_3 = Φ(x_1, x_2); y_1 = x_3 + 1

Φ(x_1, x_2) = “실행 경로에 따라 x_1 또는 x_2”.

왜 SSA 인가

Def-use chain 명확: 각 변수 정의는 유일, 사용 곳 추적 쉬움
최적화 알고리즘 단순: constant propagation, dead code elimination
Register allocation 개선

모든 현대 컴파일러: LLVM, JVM (Hotspot C2), V8 Turbofan, GCC (GIMPLE) 가 SSA.

4. Control Flow Graph (CFG)

프로그램을 기본 블록 (basic block) 으로 나누고 분기를 간선으로:

flowchart TD
  E["Entry"] --> B1["b1: x = 1"]
  B1 --> C{"if x > 0"}
  C -->|true| B2["b2: y = 2"]
  C -->|false| B3["b3: y = 3"]
  B2 --> B4["b4: return y"]
  B3 --> B4

기본 블록: 분기 없이 순차 실행되는 명령의 최대 시퀀스.

CFG 위에서 data flow analysis 수행.

5. LLVM IR

산업 표준 IR. 텍스트/바이너리 두 형식.

define i32 @add(i32 %a, i32 %b) {
entry:
  %sum = add i32 %a, %b
  ret i32 %sum
}

Typed (i32, i64, ptr)
SSA (기본)
Portable (아키텍처 독립)
Optimizer + Backend 도구 풍부

Optimization (최적화)

컴파일러의 각종 최적화 pass. 100+ 가지 존재.

Constant Folding

x = 2 + 3
→
x = 5

컴파일 시 상수 표현 미리 계산.

Constant Propagation

x = 5
y = x + 1
→
x = 5
y = 6

상수 값을 전파.

Dead Code Elimination

x = 1
y = 2
z = x + 1
return z

y 는 사용 안 됨 → 제거:

x = 1
z = x + 1
return z

Common Subexpression Elimination (CSE)

a = (x + y) * 2
b = (x + y) * 3

x + y 중복. 한 번만 계산:

t = x + y
a = t * 2
b = t * 3

Function Inlining

function add(a, b) { return a + b; }
result = add(1, 2);

→ (inlined)

result = 1 + 2;  // 그 다음 constant folding → 3

작은 함수는 호출 오버헤드 제거 + 추가 최적화 활성.

Loop Optimizations

Loop-invariant code motion: 루프 안 불변식을 밖으로
Loop unrolling: 반복 횟수 줄이고 iteration 확장
Strength reduction: 곱셈 → 덧셈 (i*4 → i+i+i+i 아니 i<<2)
Vectorization: SIMD 명령 활용

Tail Call Optimization

function factorial(n, acc=1) {
  if (n <= 1) return acc;
  return factorial(n - 1, n * acc);   // tail call
}

Tail call = 함수 마지막 액션이 함수 호출. 스택 프레임 재사용 가능 → 무한 재귀 없이 실행.

Scheme, Haskell 필수. JavaScript ES2015 스펙에는 있지만 실구현 미미.

Escape Analysis

객체가 함수 밖으로 escape 안 하면 스택 할당 (heap 대신):

function foo() {
  const arr = [1, 2, 3];  // 함수 안에서만 사용 → stack alloc 가능
  return arr[0];
}

V8, JVM 이 활용.

실행 순서 (Pass Manager)

최적화들은 순서 대로 적용. 한 최적화가 다른 것을 활성:

1. Function inlining
2. Constant propagation
3. Dead code elimination
4. Common subexpression elimination
5. Loop invariant code motion
6. ... (반복)

각 pass 는 IR 을 읽고 새 IR 을 출력. 여러 번 실행하기도 (fixed-point).

Code Generation

IR → 목표 코드.

Register Allocation

CPU 는 유한한 레지스터 (예: x86-64 는 16개 일반 레지스터). IR 은 무한 가상 레지스터 사용 → 물리 레지스터에 매핑.

Graph Coloring: interference graph 색칠 문제 (NP-hard, 근사).

Linear Scan: 빠른 근사, JIT 에 자주 사용.

Spilling: 레지스터 부족 시 메모리 (stack) 로.

Instruction Selection

IR 명령 → 실제 CPU 명령.

IR: %c = mul %a, %b
x86: imul %eax, %ebx, %ecx
ARM: MUL R0, R1, R2

Tree matching, BURS (bottom-up rewriting).

Instruction Scheduling

CPU 는 pipeline. 명령 순서 재배열로 stall 최소화. Superscalar 활용.

Peephole Optimization

작은 명령 시퀀스를 더 나은 것으로:

MOV eax, 0    →    XOR eax, eax  (더 짧고 빠름)

LLVM 파이프라인

Source (C, Rust, ...)
   ↓ (Language frontend)
LLVM IR
   ↓ (opt: optimization passes)
Optimized LLVM IR
   ↓ (llc: code generation)
Assembly
   ↓ (as: assembler)
Object file
   ↓ (ld: linker)
Executable

각 단계 도구화. 개별 실행/디버그 가능.

목표 코드 종류

Native (기계어)

CPU 아키텍처별 (x86-64, ARM64, RISC-V, …).

Bytecode

VM 용 중간 코드 (JVM bytecode, .NET CIL, Python .pyc).

WebAssembly (WASM)

브라우저용 저수준 VM. 여러 언어 대상 (C, C++, Rust, Go).

Intermediate (LLVM IR, SPIR-V)

LLVM IR 자체를 목표로 배포 (Rust no-std 라이브러리 등).

Transpiled (High-level)

다른 고급 언어. TypeScript → JavaScript, Kotlin → JS.

최적화의 한계

Rice’s Theorem (계산 가능성 이론): 비자명한 프로그램 성질은 undecidable.

즉, 컴파일러는 완벽한 최적화 불가. 근사만 가능.

보수적 근사: “안전하지 않으면 최적화 안 함”. 옳지 않은 최적화 > 아쉬운 최적화.

최적화 vs 가독성

컴파일러가 훌륭하다면 가독성 우선. 손으로 최적화 (loop unrolling 등) 는 대개 컴파일러가 이미 하거나 오히려 방해.

예외: 알고리즘 선택 (Big-O), 데이터 구조. 이건 컴파일러가 못 함.

함정

[!WARNING] 최적화 = 항상 빠름 은 아님. Inlining 은 코드 크기 폭발. Loop unrolling 은 캐시 miss. 프로파일링 우선.

[!CAUTION] -O0 (최적화 X) 에서 잘 되던 코드가 -O3 에서 실패. UB (undefined behavior) 원인 (C/C++). Sanitizer 사용.

[!WARNING] JIT 는 옛 코드 무효화. 가정 (타입, inline) 이 깨지면 deoptimize. 이 원인 이해가 hot path 튜닝의 핵심.

[!IMPORTANT] LLVM IR 이 표준. 새 언어 만들 때 backend 재발명 X. LLVM 활용.

[!CAUTION] Register allocation 이 컴파일러 성능 큰 요인. JIT 는 특히 speed vs quality trade-off.

[PLT] Lexical Analysis (어휘 분석)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

어휘 분석 (Lexical Analysis) 은 소스 코드 문자 시퀀스 를 의미 있는 최소 단위인 토큰 (Token) 으로 분해하는 과정입니다. 담당 컴포넌트를 Lexer (또는 Tokenizer, Scanner) 라고 합니다.

한 줄 요약: 문자열을 프로그래밍 언어의 “단어” 로 자름.

왜 필요한가

파서가 매 문자를 다루면 매우 복잡합니다. 어휘 분석이 미리 의미 없는 것 (공백, 주석) 제거 + 의미 있는 것 그룹핑 하면 파서는 훨씬 단순.

토큰 (Token)

의미 있는 최소 단위. 예: JavaScript let x = 42; 를 lex 하면:

[LET]           value: "let"        type: keyword
[IDENTIFIER]    value: "x"          type: identifier
[EQUAL]         value: "="          type: operator
[NUMBER]        value: "42"         type: literal
[SEMICOLON]     value: ";"          type: punct

각 토큰:

Type (Kind): 카테고리
Value / Lexeme: 원본 문자열
Location: 파일/줄/열 (에러 메시지용)

토큰 카테고리

일반적 언어의 토큰 유형:

Keyword: if, else, while, let, const, function (예약어)
Identifier: 변수/함수 이름 (x, myFunc)
Literal: 값
- Number: 42, 3.14, 0xFF
- String: "hello", 'world'
- Boolean: true, false
- Null: null
Operator: +, -, *, ==, &&, <=
Punctuation: (, ), {, }, ;, ,
Whitespace / Comment: 대개 건너뜀 (일부 언어는 유의미)

정규 표현식과 토큰 정의

각 토큰 유형은 정규 표현식 으로 정의:

NUMBER      = [0-9]+ (\.[0-9]+)?
IDENTIFIER  = [a-zA-Z_][a-zA-Z0-9_]*
KEYWORD_IF  = "if"
OPERATOR_EQ = "=="
STRING      = "[^"]*"

중요: 규칙 순서. if 는 identifier 패턴에도 매치 → keyword 먼저 확인.

Longest Match Rule

여러 규칙이 매치 시 가장 긴 매치 선택.

== 는 [EQUAL_EQUAL] (2 문자) vs [EQUAL][EQUAL] (1 문자씩)
→ 항상 longest = [EQUAL_EQUAL]

<= vs <, ** vs * 등.

시각화: Lexer 흐름

flowchart LR
  I["let x = 42;"] --> C[Character Stream]
  C -->|read| S[State Machine]
  S -->|match keyword| T1["LET"]
  S -->|match ident| T2["x"]
  S -->|match op| T3["="]
  S -->|match number| T4["42"]
  S -->|match punct| T5[";"]

유한 오토마타 (Finite Automata)

정규 표현식은 유한 상태 머신 으로 구현.

DFA (Deterministic Finite Automaton)

각 상태에서 각 입력에 대해 유일한 다음 상태.

예: 정수 인식 DFA

     [0-9]         [0-9]
State 0 ─────> State 1 <─┐
  (start)      (accept)  │
                └────────┘

Start (0): 첫 숫자 도착 시 State 1 로
State 1 (accept): 계속 숫자 소비, 아니면 종료

NFA (Nondeterministic Finite Automaton)

한 상태에서 여러 다음 상태 가능. 정규 표현식 → NFA 는 자연스러움.

NFA → DFA 변환 알고리즘 (subset construction) 이 존재.

실전

컴파일러 구현 시:

수동 구현: 상태를 switch 문으로. Crafting Interpreters, 대부분 프로덕션 컴파일러.
자동 생성: Lex/Flex 가 정규식 → C 코드 생성. Legacy.

대부분 현대 컴파일러는 수동 lexer (에러 메시지, 성능, 유연성 이유).

실전 Lexer 구현 (의사코드)

function lex(source):
    tokens = []
    pos = 0
    while pos < len(source):
        char = source[pos]

        if char is whitespace:
            pos += 1
            continue

        if char is '/' and source[pos+1] is '/':
            # line comment
            while pos < len(source) and source[pos] != '\n':
                pos += 1
            continue

        if char is digit:
            start = pos
            while pos < len(source) and source[pos] is digit:
                pos += 1
            tokens.append(Token(NUMBER, source[start:pos]))
            continue

        if char is letter or '_':
            start = pos
            while pos < len(source) and (source[pos] is letter/digit/_):
                pos += 1
            lexeme = source[start:pos]
            if lexeme in KEYWORDS:
                tokens.append(Token(KEYWORDS[lexeme], lexeme))
            else:
                tokens.append(Token(IDENTIFIER, lexeme))
            continue

        if char is '"':
            # string literal
            pos += 1
            start = pos
            while pos < len(source) and source[pos] != '"':
                pos += 1
            tokens.append(Token(STRING, source[start:pos]))
            pos += 1   # skip closing quote
            continue

        if char is operator:
            # ==, !=, <=, etc.
            if source[pos:pos+2] in TWO_CHAR_OPS:
                tokens.append(Token(TWO_CHAR_OPS[source[pos:pos+2]], source[pos:pos+2]))
                pos += 2
            else:
                tokens.append(Token(ONE_CHAR_OPS[char], char))
                pos += 1
            continue

        raise LexError(f"Unknown character: {char}")

    tokens.append(Token(EOF, ""))
    return tokens

핵심 패턴:

Position pointer 로 문자열 순회
각 상태별 while 로 매치
Longest match 자연스럽게 구현

에러 처리

Lexer 오류:

알 수 없는 문자
종료되지 않은 문자열 ("hello)
종료되지 않은 주석 (/* ...)
잘못된 숫자 형식 (3.14.15)

전략:

즉시 실패 (초기 예)
에러 토큰 생성 후 계속 (파서에서 recovery)

좋은 에러 메시지:

error: unterminated string literal
  --> src/main.rs:3:15
   |
 3 |     let x = "hello
   |             ^ expected closing quote

파일/줄/열 정보를 토큰마다 저장.

Special Cases

Whitespace-Significant Languages

Python, Haskell, YAML 은 들여쓰기가 의미 있음. Lexer 가 INDENT / DEDENT 토큰 생성:

def foo():
    x = 1        ← INDENT
    if x:
        y = 2    ← INDENT
    z = 3        ← DEDENT
                 ← DEDENT

Template Literals (JS/TS)

`hello ${name}` 는 lexer 가 특수 처리. 문자열 안에 표현식 삽입.

다국어 지원

Unicode identifier. 이모지 변수 (💰 = 100). 언어 스펙에 따라.

유명 언어의 Lexer

JavaScript: ECMAScript 스펙 에 정의된 문법. V8, SpiderMonkey 등이 각자 구현.
Python: tokenize 모듈로 노출.
Rust: rustc_lexer crate.
TypeScript: TS 컴파일러의 scanner.ts.

도구

Lex / Flex (C): 정규식 → C lexer. Legacy.
ANTLR: 파서 생성기 (lexer 포함), Java 기반.
Rply, PLY (Python): 옛 방식.
Chumsky, Pest (Rust): parser combinator.

대부분 현대 컴파일러는 수동 lexer. 유연성, 성능, 에러 메시지.

함정

[!WARNING] Longest match 잘못 구현하면 == 이 =, = 두 개로.

[!CAUTION] Keyword 를 identifier 로. if 를 identifier 처리하면 파서가 이상해짐. Keyword 먼저 매치.

[!WARNING] 위치 정보 저장 잊음. 에러 메시지에 line/col 없으면 UX 최악.

[!IMPORTANT] Lookahead. == 인지 확인하려면 다음 문자 미리 봄. 1-2 문자 lookahead 흔함.

[PLT] Parsing & Grammars

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Parsing (구문 분석) 은 lexer 의 토큰 스트림 을 언어의 문법 규칙 에 따라 구조화된 트리 (AST, Abstract Syntax Tree) 로 조립하는 과정입니다.

토큰들이 어떤 구문 구조 를 이루는가
우선순위 (precedence): 2 + 3 * 4 = 2 + (3 * 4)
결합성 (associativity): 1 - 2 - 3 = (1 - 2) - 3 (좌결합)

문법 (Grammar)

프로그래밍 언어의 문법 규칙 을 형식적으로 기술 하는 표기법.

BNF (Backus-Naur Form)

가장 기초적인 표기:

<expression> ::= <term> | <expression> "+" <term>
<term>       ::= <factor> | <term> "*" <factor>
<factor>     ::= <number> | "(" <expression> ")"
<number>     ::= [0-9]+

::=: “정의”
|: “또는”
<...>: 비단말 (non-terminal, 다른 규칙 참조)
문자열: 단말 (terminal, 실제 토큰)

EBNF (Extended BNF)

? (선택), * (0+), + (1+) 확장:

expression = term ( "+" term )*
term       = factor ( "*" factor )*
factor     = number | "(" expression ")"
number     = digit+
digit      = "0" | "1" | ... | "9"

정규식 같이 간결.

CFG (Context-Free Grammar)

BNF/EBNF 의 이론 이름. 문맥 자유 = 규칙 적용이 주변 문맥과 무관.

프로그래밍 언어 대부분이 CFG (완전히는 아니고 근사).

시각화: 파싱

입력: 2 + 3 * 4

토큰: [NUM 2] [PLUS] [NUM 3] [STAR] [NUM 4]

파스 트리 (문법 규칙 따라):

                expression
               /    |     \
            term   "+"   term
             |            |  \  \
           factor       factor "*" factor
             |            |         |
           NUM 2        NUM 3     NUM 4

AST (더 간결):

AST 는 파스 트리에서 불필요한 노드 (expression, term, factor 같은 중간) 제거.

Ambiguity (모호성)

같은 입력이 여러 파스 트리를 가지면 문법이 모호.

예: 2 + 3 * 4 를 아래 문법으로:

expr ::= expr op expr | number
op   ::= "+" | "*"

두 파스 트리 가능:

(2 + 3) * 4 = 20
2 + (3 * 4) = 14

해결: 우선순위/결합성 반영한 문법 재작성 (위의 expression → term → factor 계층).

하향식 vs 상향식

Top-Down (하향식)

Start 규칙 부터 시작해 규칙 적용:

LL(k): Left-to-right, Leftmost derivation, k 토큰 lookahead
Recursive Descent: 재귀 함수로 각 규칙 표현
Predictive Parser: 다음 토큰 보고 어떤 규칙 적용할지 결정

Bottom-Up (상향식)

토큰 부터 시작해 규칙으로 결합:

LR(k): Left-to-right, Rightmost derivation reversed
LALR(1): LR 축약, yacc/bison 이 채택
SLR: LR 의 단순 변종

Recursive Descent (가장 흔한 실전 방식)

각 non-terminal 을 함수로:

function parseExpression():
    left = parseTerm()
    while peek() is "+":
        consume("+")
        right = parseTerm()
        left = BinaryOp("+", left, right)
    return left

function parseTerm():
    left = parseFactor()
    while peek() is "*":
        consume("*")
        right = parseFactor()
        left = BinaryOp("*", left, right)
    return left

function parseFactor():
    if peek() is number:
        return NumberLiteral(consumeNumber())
    if peek() is "(":
        consume("(")
        expr = parseExpression()
        consume(")")
        return expr
    error("expected number or '('")

장점:

손으로 쉽게 작성
에러 메시지 세밀 제어
디버깅 쉬움
재귀 자연스러움

단점:

좌측 재귀 (expr → expr + term) 처리 어려움 → while loop 로 변환
문법 규모 크면 코드도 큼

대부분 실전 언어 (Rust, TypeScript, Go, Swift) 는 recursive descent.

연산자 우선순위 (Pratt Parser / Precedence Climbing)

Recursive descent 의 확장. 각 연산자에 우선순위 부여, 하나의 함수로 처리.

function parseExpr(minPrec):
    left = parsePrimary()
    while peek() is operator and precedence(peek()) >= minPrec:
        op = consume()
        rightPrec = precedence(op) + (rightAssociative(op) ? 0 : 1)
        right = parseExpr(rightPrec)
        left = BinaryOp(op, left, right)
    return left

여러 연산자 (+, -, *, /, **) 를 한 함수로
우선순위 표 관리만 하면 됨

Vaughan Pratt 의 원래 알고리즘. Rust, Kotlin, Swift 등에서 사용.

LR Parser (자동 생성)

Yacc, Bison, ANTLR 이 사용.

LR(1) 파서: 상향식, 1 토큰 lookahead. 대부분 실용 문법 수용.

Shift-Reduce:

Shift: 다음 토큰을 스택에.
Reduce: 스택 상단이 규칙 우변과 매치되면 좌변으로 축약.

LALR(1): LR(1) 상태를 병합해 크기 축소. Yacc/Bison 기본.

장점: 어떤 CFG 든 처리, 자동 생성. 단점: 에러 메시지 어색, 디버깅 어려움, 상태 폭발 가능.

2020년대 트렌드: 파서 생성기 → 수동 recursive descent. 이유는 UX.

PEG (Parsing Expression Grammar)

CFG 대안. 결정적 파싱 (모호성 없음). Ordered choice: a | b 는 a 먼저 시도.

Expr    <- Term ('+' Term)*
Term    <- Factor ('*' Factor)*
Factor  <- Number / '(' Expr ')'

/: ordered choice (좌 우선)
&: positive lookahead
!: negative lookahead

Packrat parsing: 메모이제이션으로 선형 시간. Peg 스타일 대표.

도구: Pest (Rust), TatSu (Python), PEG.js.

Parser Combinator

파서를 값처럼 다루는 접근. Haskell 스타일:

expr = do
  left <- term
  rest <- many (do op <- symbol "+"; t <- term; return (op, t))
  return (foldl (BinaryOp) left rest)

장점: 파싱 로직 조합, 언어 임베딩. 단점: 에러 메시지, 성능.

도구: parsec (Haskell), Chumsky (Rust), nom (Rust).

AST 생성

파서의 출력물 은 AST. 노드 예시:

type ASTNode =
  | { kind: 'Number'; value: number }
  | { kind: 'Identifier'; name: string }
  | { kind: 'BinaryOp'; op: '+' | '-' | '*' | '/'; left: ASTNode; right: ASTNode }
  | { kind: 'Assignment'; target: ASTNode; value: ASTNode }
  | { kind: 'If'; cond: ASTNode; then: ASTNode; else?: ASTNode }
  | { kind: 'While'; cond: ASTNode; body: ASTNode[] }
  | { kind: 'Function'; name: string; params: string[]; body: ASTNode[] }
  | { kind: 'Call'; callee: ASTNode; args: ASTNode[] }

자세한 것은 [[plt-abstract-syntax-tree|AST]] 참조.

에러 복구

파서가 오류 만나면:

Panic mode: 다음 세미콜론까지 건너뜀
Phrase-level recovery: 특정 토큰 삽입/삭제
Error productions: 문법에 흔한 오류 규칙 추가

좋은 컴파일러는 한 파일에 여러 오류를 함께 보고. 하나 발견 후 즉시 중단 X.

실전 파서 예시

TypeScript

Recursive descent. parser.ts 안에 각 parseXXX 함수.

Rust

rustc_parse crate. Pratt 스타일 우선순위 처리.

Python

PEG parser (Python 3.9+). 이전에는 LL(1). PEP 617 이 이관.

JavaScript (V8, SpiderMonkey)

수동 recursive descent, 성능 극도로 튜닝.

함정

[!WARNING] 좌측 재귀 는 recursive descent 에서 무한 재귀. expr → expr + term 은 while loop 로 재작성.

[!CAUTION] 우선순위 오류. 2 + 3 * 4 가 20 이 나오면 문법 재점검.

[!WARNING] 에러 메시지 개선을 후순위로. 실전에서는 좋은 에러가 언어 채택 좌우. 초기 설계부터.

[!IMPORTANT] Comment / trailing comma 등 언어 UX. 문법 규칙에 명시 필요.

[!CAUTION] 파서 생성기의 유혹. 초기엔 빠르지만 유지보수 어려움. 수동 recursive descent 검토.

[PLT] Semantic Analysis (의미 분석)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Semantic Analysis (의미 분석) 는 파서가 생성한 AST 를 검사하여 문법적으로 올바르지만 의미상 오류인 경우 를 발견하고, 각 이름 (identifier) 이 무엇을 가리키는지 결정하는 단계입니다.

한 줄 요약: “코드가 문법적으로 맞는 건 알겠는데, 말이 되나?”

무엇을 검사하는가

파서가 통과시킨 것들:

undefinedVar + 1        // 정의되지 않은 변수
"hello" * 3             // 잘못된 타입 (문자열 * 숫자? 파이썬은 가능, JS 는?)
myFunc()                // 함수 없음
const x = 1; x = 2;     // const 재할당
return 42;              // 함수 밖 return

파서는 이런 것을 발견 못 함. Semantic analyzer 가:

이름 해석: 각 identifier 가 어떤 declaration 을 가리키는지
Scope 규칙: 어느 변수가 여기서 보이는지
타입 검사: 값의 타입이 문맥에 맞는지
컨트롤 흐름: return 이 함수 안에 있는지, break 가 루프 안에 있는지
접근 제어: private 필드 접근 금지, immutable 재할당 금지

Symbol Table

이름 → 정보 매핑. Semantic analyzer 의 핵심 자료구조.

각 심볼의 정보:

이름
종류 (variable, function, class, module)
타입
선언 위치
가시성 (scope)
속성 (const, static, private)

interface Symbol {
  name: string;
  kind: 'variable' | 'function' | 'class' | 'parameter';
  type: Type;
  declLocation: SourceLocation;
  isConst: boolean;
  isExported: boolean;
}

class SymbolTable {
  private scopes: Map<string, Symbol>[] = [new Map()];

  enterScope() { this.scopes.push(new Map()); }
  exitScope() { this.scopes.pop(); }

  declare(sym: Symbol) {
    const current = this.scopes[this.scopes.length - 1];
    if (current.has(sym.name)) {
      throw new Error(`Duplicate declaration: ${sym.name}`);
    }
    current.set(sym.name, sym);
  }

  lookup(name: string): Symbol | undefined {
    for (let i = this.scopes.length - 1; i >= 0; i--) {
      if (this.scopes[i].has(name)) {
        return this.scopes[i].get(name);
      }
    }
    return undefined;
  }
}

Scope (범위)

Scope: 한 이름이 유효한 코드 영역.

Lexical Scope (정적 스코프)

소스 코드의 위치로 결정. 대부분 언어 (JavaScript, Python, Rust, Java, C).

function outer() {
  const x = 1;
  function inner() {
    console.log(x);   // ← outer 의 x
  }
  inner();
}

inner 안의 x 는 정의 시점의 outer 를 가리킴 (lexical).

Dynamic Scope (동적 스코프)

호출 시점의 스택 으로 결정. 초기 Lisp, Emacs Lisp, Perl local 등.

(defun outer () (let ((x 1)) (inner)))
(defun inner () (print x))    ; ← 호출한 outer 의 x

대부분 언어는 lexical scope. Dynamic scope 는 예측 어려워 지양.

Nested Scope

Scope 는 중첩 가능. 안쪽 scope 가 바깥 참조 가능:

Global scope
  └── Module scope
        └── Function scope
              └── Block scope
                    └── (nested block)

이름 해석: 가장 안쪽부터 바깥으로 확인.

Shadowing (섀도잉)

내부 scope 가 외부 이름을 가림:

const x = 1;
{
  const x = 2;    // 바깥 x 를 가림
  console.log(x); // 2
}
console.log(x);   // 1

Rust 는 shadowing 을 명시적 언어 기능 으로:

let x = 5;
let x = "hello";   // 다른 타입도 가능

Python 은 함수 scope 안에서만 shadowing.

이름 해석 알고리즘

각 identifier 참조를 declaration 에 연결.

resolve(node, symbolTable):
    switch node.kind:
        case Identifier:
            sym = symbolTable.lookup(node.name)
            if sym is None:
                error(f"Undefined: {node.name}")
            node.resolvedSymbol = sym

        case VariableDeclaration:
            resolve(node.init, symbolTable)
            sym = Symbol(name=node.name, type=...)
            symbolTable.declare(sym)

        case Block:
            symbolTable.enterScope()
            for stmt in node.statements:
                resolve(stmt, symbolTable)
            symbolTable.exitScope()

        case Function:
            fn = FunctionSymbol(...)
            symbolTable.declare(fn)
            symbolTable.enterScope()
            for param in node.params:
                symbolTable.declare(param)
            resolve(node.body, symbolTable)
            symbolTable.exitScope()

Hoisting (호이스팅)

일부 언어 (JavaScript) 는 선언을 scope 상단으로 끌어올림:

console.log(foo());   // OK, 호이스팅
function foo() { return 1; }

console.log(x);       // undefined (var 는 호이스팅되지만 값 아님)
var x = 5;

console.log(y);       // ReferenceError (let 은 TDZ)
let y = 5;

Semantic analyzer 는 두 pass:

선언 수집 pass: block 전체를 훑어 선언 등록
참조 해석 pass: 표현식의 identifier 해석

TypeScript, Rust 는 이 방식 (선언 순서와 무관하게 참조 가능).

Type Checking

각 표현식의 타입 을 결정하고 문맥에 맞는지 확인.

const x: number = "hello";   // 오류: string 을 number 에
add("hello", 1);              // 오류 여부는 언어 나름

간단한 규칙:

NumberLiteral: type = number
StringLiteral: type = string
BinaryOp(+):
- number + number → number
- string + string → string
- number + string → 언어별 (JS 는 coercion, Python 은 오류, Rust 는 오류)

Type inference (Hindley-Milner, TypeScript, Rust): 명시 없이도 타입 추론. 자세한 것은 [[plt-type-systems|Type Systems]] 참조.

Control Flow Check

return 이 함수 안?
break / continue 가 loop / switch 안?
모든 경로가 return 하는가? (noImplicitReturns)
예외 처리 (throws 선언 vs actual throw)

checkReturn(node, insideFunction=false):
    switch node.kind:
        case ReturnStatement:
            if not insideFunction:
                error("'return' outside function")
        case FunctionDeclaration:
            checkReturn(node.body, insideFunction=True)
        case Block:
            for stmt in node.statements:
                checkReturn(stmt, insideFunction)

상수 검사

const 는 재할당 금지:

const x = 1;
x = 2;    // 오류

const arr = [];
arr.push(1);   // OK (내부 변경, 재할당 X)

Semantic analyzer 는 const 변수의 재할당 사이트 를 검사.

Symbol Table 구현 전략

Chained Hash Tables

각 scope 가 별도 map, 안쪽 → 바깥 순회.

Flat + Depth

하나의 map 에 (name, depth) 키. 스코프 depth 로 shadowing.

Persistent (Immutable)

각 scope 변화가 새 map. 함수형 언어에 자연스러움.

오류 메시지 개선

좋은 semantic error:

error[E0425]: cannot find value `undefined_var` in this scope
  --> src/main.rs:5:9
   |
 5 |     let x = undefined_var + 1;
   |             ^^^^^^^^^^^^^ not found in this scope
   |
   = help: did you mean `undefined_val`?

유사 이름 제안 (Levenshtein distance)
Import 제안
정의 위치 표시

Rust 컴파일러가 이 방면 최상.

두 언어의 대비

JavaScript (동적 타입, hoisting)

대부분 검사는 런타임
undefined_var 는 파싱/semantic 통과, 런타임 ReferenceError
Static analysis 는 ESLint, TypeScript 가 담당

Rust (정적 타입, ownership 검사)

매우 엄격한 semantic 분석
Ownership + borrow checking (semantic 안)
컴파일 오류가 대부분 실제 버그

Semantic Analysis 결과

AST 에 정보 주석 (annotated AST):

interface AnnotatedIdentifier extends Identifier {
  resolvedSymbol: Symbol;   // 이 identifier 가 가리키는 declaration
  inferredType: Type;
}

이후 단계 (IR 생성, 최적화, 코드 생성) 가 이 정보 활용.

함정

[!WARNING] 이름 해석 순서 실수. Hoisting 있는 언어는 2-pass 필요.

[!CAUTION] Scope stack 관리. enterScope/exitScope 짝 맞지 않으면 버그.

[!WARNING] 좋은 에러 메시지 = 좋은 언어. 초기 개발 시부터 신경.

[!IMPORTANT] 정적 분석은 완전 X. eval, exec, 리플렉션 있는 언어는 불가피한 undecidable.

[!CAUTION] 캐시 이슈. 큰 IDE 는 심볼 테이블을 지속 유지. 파일 변경 시 정확한 무효화.

[PLT] Type Systems (타입 시스템)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

타입 시스템 (Type System) 은 프로그램의 값과 표현식에 타입 (type) 을 부여하고, 이 타입들이 규칙에 맞게 결합되는지 검증하는 형식 체계입니다.

타입 = 값의 집합 + 그 값들에 정의된 연산.

number: 수의 집합 + 산술 연산
string: 문자열 + 결합/추출
Array<T>: T의 배열 + push/pop 등
() => number: 인자 없이 number 반환하는 함수

목적: 특정 종류의 오류를 컴파일 시 (또는 런타임 시) 방지.

왜 타입 시스템인가

방지하는 오류

"hello" + 3 (문자열/숫자 혼합, 언어별)
null.foo (null 참조)
array[100] (index out of bounds)
divideByZero(10, 0) (0 나눗셈)
Map<string, number> 에 boolean 저장

얻는 이익

문서화: 함수 시그니처로 사용법 명시
자동완성: IDE 가 타입 기반 제안
리팩터링 안전성: rename, extract method
성능: 컴파일러가 최적화 (JIT 는 타입 추측)

정적 vs 동적

Static Typing (정적 타이핑)

컴파일 시 타입 검사.

예: TypeScript, Rust, Java, C++, Haskell, Go, Kotlin

function add(a: number, b: number): number {
  return a + b;
}
add("hello", 1);  // 컴파일 오류

장점:

오류 조기 발견
리팩터링 안전
컴파일러 최적화 여지

단점:

프로토타이핑 느림
표현력 제약 (극한 케이스)

Dynamic Typing (동적 타이핑)

런타임 시 타입 검사.

예: Python, JavaScript (기본), Ruby, PHP, Lua, Clojure

function add(a, b) {
  return a + b;
}
add("hello", 1);  // "hello1" (JS 자동 변환)

장점:

유연성, 빠른 프로토타이핑
메타프로그래밍 자연스러움

단점:

런타임 오류
IDE 지원 부족
대규모 코드베이스에서 유지보수 어려움

Strong vs Weak

Strong Typing: 타입을 엄격히 지킴. 자동 변환 최소.

Python: "hello" + 3 → TypeError

Weak Typing: 자유로운 자동 변환.

JavaScript: "hello" + 3 → "hello3"
PHP: "1" == 1 → true

Strong vs Weak 은 스펙트럼. Static 인지 동적인지와 무관.

Type Checking

Nominal Typing

이름 기반. 두 타입이 같은 이름을 가지면 호환.

class Cat { String name; }
class Dog { String name; }

Cat c = new Cat();
Dog d = c;   // Java: 오류 (다른 이름)

C++, Java, C# 대표.

Structural Typing

구조 기반. 같은 shape 이면 호환.

interface Named { name: string; }
class Cat { name: string = ""; }

const n: Named = new Cat();   // TypeScript: OK (구조 같음)

TypeScript, Go, OCaml 대표.

Duck typing = “오리처럼 걷고 꽥꽥 하면 오리” = structural typing 의 dynamic 버전.

Trade-offs

Nominal: 명확한 의도. 실수로 호환 불가.
Structural: 유연. Boilerplate 감소.

Type Inference

명시 없이 컴파일러가 타입 추론.

Local (지역 추론)

변수 초기값에서 타입 결정:

let x = 42;         // number
let s = "hello";    // string

C++ (auto), Java (var), C# (var), Swift, Go (:=).

Global (전역 추론): Hindley-Milner

함수 시그니처도 추론. Haskell, ML, OCaml, Elm.

add x y = x + y
-- 추론: add :: Num a => a -> a -> a

컴파일러가 사용 문맥으로부터 타입 방정식 세우고 통합 (unification).

Damas-Milner 알고리즘: 다항 시간 안에 principal type 결정.

TypeScript / Rust

지역 추론 + contextual typing. 완전한 Hindley-Milner 는 아니지만 실용적.

Sound vs Unsound

Sound 타입 시스템: 컴파일 통과한 프로그램은 런타임에 타입 오류 없음.

Unsound: 통과해도 런타임 오류 가능.

예:

Haskell, Rust, OCaml: sound (거의)
Java, C#: sound (array covariance 등 예외)
TypeScript: 의도적으로 unsound. 실용성 우선.

// TypeScript 는 unsound 인 예
const arr: number[] = [];
const anyArr: any[] = arr;
anyArr.push("string");   // 컴파일 OK
arr[0].toFixed(2);        // 런타임 오류

TypeScript 는 “developer productivity” 우선. 100% soundness 는 실전 부담.

주요 타입 시스템 개념

Union / Intersection

Union (A | B): A 또는 B
Intersection (A & B): A 이고 B

자세한 것은 [[ts-union-intersection|TypeScript Union/Intersection]] 참조.

Generics (Parametric Polymorphism)

타입 매개변수:

function identity<T>(x: T): T { return x; }

Java <T>, C++ template<T>, Haskell forall a.

Subtyping

Dog extends Animal → Dog 는 Animal 의 subtype. Liskov Substitution.

Variance

Generic 안 subtype 관계:

Covariant (out T): List<Dog> → List<Animal> OK
Contravariant (in T): Consumer<Animal> → Consumer<Dog> OK
Invariant: 관계 없음

Higher-Rank / Higher-Kinded Types

HKT: 타입 생성자를 타입 매개변수로. Functor<F>. Haskell, Scala.
Rank-N: 함수 인자로 다형 함수. Rust for<'a> ....

Dependent Types

값이 타입을 결정. Vector<N: nat> (길이 N의 벡터).

Idris, Agda, Coq, Lean, F*. 형식 증명.

서브셋 타입. PositiveInt = { x: int | x > 0 }.

LiquidHaskell, F*.

Type Erasure vs Reified

Type Erasure: 컴파일 후 타입 사라짐. Java generics, TypeScript.

Reified: 런타임에 타입 유지. C#, Kotlin (reified), Rust (monomorphization).

Gradual Typing

정적 + 동적 혼합. any 타입으로 escape.

예:

TypeScript: JavaScript 위에 점진 도입
Python + mypy / TypeScript-like
PHP with type hints
Sorbet (Ruby)
Flow

프로덕션 코드베이스에 실용적.

언어별 특징

TypeScript

구조 타이핑 + 강력한 추론
Union / intersection / mapped / conditional
Unsound (intentionally)
자세한 것은 [[typescript|TypeScript]] 참조

Rust

Sound, ownership + lifetimes
Trait 기반 (Haskell type class 스타일)
Monomorphization (reified)

Haskell

Hindley-Milner 완전 추론
타입 클래스 (ad-hoc polymorphism)
Pure (side effect 도 타입 안)

Java

Nominal, subtyping
Erased generics
Wildcard variance

Python

동적 + gradual (typing module, mypy)
Duck typing

Type-safe Programming 팁

any 최소화 (TypeScript, Python)
Discriminated union 활용 (Rust enum, TS union)
Exhaustive matching (compiler 가 case 누락 감지)
NewType 패턴: UserId vs ProductId (branded types)
Immutability by default

실전 튜토리얼

간단한 타입 검사기 (의사코드)

check(expr, env):
    switch expr.kind:
        case NumberLiteral: return NumberType
        case StringLiteral: return StringType
        case BooleanLiteral: return BoolType

        case Identifier:
            if sym in env: return sym.type
            error(f"Undefined: {expr.name}")

        case BinaryOp:
            lt = check(expr.left, env)
            rt = check(expr.right, env)
            if expr.op in ['+', '-', '*', '/']:
                if lt == NumberType and rt == NumberType:
                    return NumberType
                error(f"Type mismatch: {lt} {expr.op} {rt}")
            if expr.op in ['==', '<', '>']:
                if lt == rt:
                    return BoolType
                error(...)

        case IfExpr:
            ct = check(expr.cond, env)
            if ct != BoolType: error("if condition must be bool")
            tt = check(expr.then, env)
            et = check(expr.else, env)
            if tt != et: error("if branches must have same type")
            return tt

        case FunctionCall:
            ft = check(expr.callee, env)
            if not isinstance(ft, FunctionType):
                error("Not callable")
            for arg, paramType in zip(expr.args, ft.paramTypes):
                argType = check(arg, env)
                if not isAssignable(argType, paramType):
                    error(...)
            return ft.returnType

함정

[!WARNING] TypeScript 는 sound 아님. 100% 타입 안전을 가정하면 런타임 오류.

[!CAUTION] Type inference 함정. let x = [] 는 never[] 로 추론. 명시 필요.

[!WARNING] Structural typing 실수. 우연히 같은 shape 이면 호환 → branded types 로 방어.

[!IMPORTANT] Type-driven development. 타입을 먼저 정의하고 구현. Haskell / Rust 방식.

[!CAUTION] 동적 언어에 억지 타입. Python 은 mypy 로 좋아지지만, 원래 동적으로 짜인 라이브러리는 타입 부착 어려움.

프로그래밍 언어론 (Programming Language Theory)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

프로그래밍 언어론 (Programming Language Theory, PLT) 은 프로그래밍 언어를 어떻게 설계하고, 정의하고, 처리하는가 를 다루는 컴퓨터 과학 분야입니다.

크게 두 갈래:

언어 설계 (Language Design): 문법, 의미론, 타입 시스템
언어 구현 (Language Implementation): 어휘 분석, 파싱, 의미 분석, 최적화, 코드 생성

컴퓨터가 소스 코드를 이해하고 실행하는 모든 단계 를 이론적으로 뒷받침합니다.

왜 배워야 하는가

프로그래머는 매일 언어를 사용합니다. 하지만 이 언어가 어떻게 작동하는지 이해하지 않으면:

컴파일 오류 메시지 해석 어려움
타입 시스템의 제약 이유를 모름
왜 특정 코드가 느린지 (컴파일러 최적화 이슈)
새 언어를 배울 때 표면적 문법만 익힘

PLT 를 알면:

디버깅 능력 향상: “왜 이 오류가?”
성능 튜닝: 컴파일러가 뭘 최적화하고 뭘 못 하는지
DSL 구축: 자체 언어 만들 수 있음
정적 분석 도구 개발: 린터, 포매터, 리팩터링 도구
언어 선택 판단: Rust vs Go 의 근본 차이

언어 처리기의 큰 그림

컴파일러/인터프리터 는 소스 코드를 다음 파이프라인으로 처리합니다.

flowchart LR
  Src["Source Code<br/>(text)"] --> Lex["Lexer<br/>(Tokenizer)"]
  Lex -->|Tokens| Par["Parser"]
  Par -->|AST| Sem["Semantic<br/>Analyzer"]
  Sem -->|Annotated AST| IR["IR Generator"]
  IR -->|IR| Opt["Optimizer"]
  Opt -->|Optimized IR| CG["Code Generator"]
  CG --> Out["Target Code<br/>(machine / bytecode)"]

각 단계:

Lexer: 문자열을 토큰 (의미 있는 최소 단위) 으로 분해
Parser: 토큰을 AST (Abstract Syntax Tree) 로 조립
Semantic Analyzer: 이름 해석, 타입 검사, scope 결정
IR Generator: 플랫폼 독립 중간 표현
Optimizer: 성능 개선 (죽은 코드 제거, 인라인 등)
Code Generator: 목표 (x86 어셈블리, JVM 바이트코드, WASM 등)

Frontend vs Backend

전통적으로 컴파일러를 두 부분으로 나눔:

Frontend: Source → AST → IR (언어 의존)
Backend: IR → Target Code (하드웨어 의존)

LLVM 은 이 분리를 극한으로: 각 언어는 LLVM IR 을 생성만 하면, LLVM 이 x86, ARM, WASM, RISC-V 등 다양한 백엔드 지원.

Compiler vs Interpreter

두 접근법이 있습니다.

컴파일러: 소스 → 목표 코드 (실행 파일). 한 번 컴파일, 여러 번 실행.
인터프리터: 소스 → 즉시 실행. AST 를 순회하며 실행.

혼합 (Modern):

JIT (Just-In-Time): 실행 중 자주 쓰이는 부분만 컴파일 (V8, HotSpot, LuaJIT, PyPy)
AOT (Ahead-Of-Time): 사전 컴파일 (Java native image, Rust)
Bytecode + VM: 중간 형태 (JVM, .NET, CPython)

자세한 것은 [[plt-interpreter-compiler|Interpreter vs Compiler]] 참조.

주요 학습 주제

이 코스가 다루는 순서:

1. Lexical Analysis (어휘 분석)

문자열을 토큰 으로 분해. 정규 표현식, 유한 오토마타 (DFA/NFA).

→ [[plt-lexical-analysis|Lexical Analysis]]

2. Parsing (구문 분석)

토큰을 문법 규칙 (grammar) 에 따라 AST 로. Top-down (LL, recursive descent) vs Bottom-up (LR, LALR).

→ [[plt-parsing|Parsing & Grammars]]

3. Abstract Syntax Tree

프로그램의 본질 구조 를 트리로. 코드 → AST → 실행/변환/분석.

→ [[plt-abstract-syntax-tree|AST]]

4. Semantic Analysis

이름 해석, scope, 타입 검사. AST 의 각 노드에 “무엇을 가리키는지” 주석.

→ [[plt-semantic-analysis|Semantic Analysis]]

5. Type Systems

정적 vs 동적, sound vs unsound, 타입 추론. 언어 안전성의 근간.

→ [[plt-type-systems|Type Systems]]

6. Interpreter vs Compiler

두 실행 모델의 근본 차이. 각 접근법의 트레이드오프.

→ [[plt-interpreter-compiler|Interpreter vs Compiler]]

7. IR + 최적화 + 코드 생성

컴파일러 백엔드. 3-address code, SSA, dead code elimination, register allocation.

→ [[plt-ir-optimization-codegen|IR, 최적화, 코드 생성]]

이론 vs 실전

이 코스는 실전 언어 구현 관점. 하지만 배경 이론도 관련:

형식 언어 이론: Chomsky 위계 (Regular, CFG, CSG, Recursive)
오토마타 이론: DFA, NFA, PDA, Turing Machine
람다 계산법: 함수형 언어 근본
타입 이론: Hindley-Milner, System F, Dependent Types
의미론 (Semantics): Operational, Denotational, Axiomatic

이론에 관심 있으면 Pierce, Types and Programming Languages 부터.

형식 언어 계층 (Chomsky Hierarchy)

프로그래밍 언어의 이론적 토대는 Chomsky 위계 다. 계층마다 표현력과 인식 오토마타가 다르다.

flowchart BT
    RE["Type 3: 정규 언어<br/>DFA / NFA / 정규식<br/>어휘 분석 (Lexer) 에 사용"]
    CFL["Type 2: 문맥 자유 언어 CFL<br/>Push-Down Automata<br/>대부분의 프로그래밍 언어 문법"]
    CSL["Type 1: 문맥 의존 언어<br/>선형 유한 오토마타 LBA<br/>자연어 일부"]
    RE0["Type 0: 귀납적 열거 언어<br/>Turing Machine<br/>계산 가능한 모든 언어"]

    RE -->|"부분집합"| CFL
    CFL -->|"부분집합"| CSL
    CSL -->|"부분집합"| RE0

실전 연관:

어휘 분석: 정규 언어 (Type 3). 정규식이나 DFA 로 토큰 인식.
구문 분석: 문맥 자유 언어 (Type 2). LL, LR 파서가 CFG 를 처리.
의미 분석: CFG 를 벗어난 규칙 (같은 타입 변수 선언 등) 은 별도 통과.
C++ / Rust 의 일부 구문은 CFG 의 표현 한계를 벗어나 파서가 의미 정보를 참조.

파서 기법 선택

기법	방향	특징	사용 예
LL(1)	Top-down	예측 파싱, 왼쪽 재귀 금지	교육용
Recursive Descent	Top-down	손으로 작성, 에러 메시지 우수	Rust, Go, TypeScript
LALR(1)	Bottom-up	파서 생성기 (yacc/bison)	구형 컴파일러
Pratt Parser	Top-down	중위 연산자 우선순위 처리 탁월	실전 언어 구현
PEG / Packrat	Top-down	백트래킹, 결정적	pest, PEGN

현대 컴파일러 (Clang, Rust, Go, TypeScript) 는 대부분 hand-written recursive descent 채택. 에러 메시지 품질과 IDE 지원 (incremental parsing) 때문.

명작 자료

Crafting Interpreters (Robert Nystrom, 무료 웹): 실전 인터프리터 구현. 최고 입문서.
Dragon Book (Aho et al.): 정통 교과서. 두꺼움.
Engineering a Compiler (Cooper & Torczon): 현대 관점.
Programming Language Pragmatics (Scott): 언어 설계 관점.
TAPL (Pierce): 타입 이론.
PLAI (Krishnamurthi, 무료 온라인): 함수형 관점.

실전 언어 만들기

이 코스를 마치면 다음 프로젝트를 스스로 할 수 있어야:

작은 인터프리터 (calculator, Lisp subset)
트리 순회 인터프리터
바이트코드 VM
간단한 컴파일러 (자체 문법 → LLVM IR 또는 C)
DSL (config 언어, query 언어)
정적 분석 도구 (린터, 포매터)

컴퓨터 과학 응용

PLT 지식이 쓰이는 곳:

컴파일러 / 트랜스파일러: gcc, clang, Babel, TypeScript, SWC
인터프리터: Python, Ruby, Lua
VM: JVM, V8, .NET CLR
JIT: V8 TurboFan, LLVM ORC, PyPy, LuaJIT
정적 분석: ESLint, mypy, Clippy, Sonar
IDE: Language Server Protocol, 자동완성, 리팩터링
DSL: SQL, GraphQL, HTML, CSS, regex
템플릿 엔진: Handlebars, Jinja2
쿼리 옵티마이저: SQL query planner
정규식 엔진
암호화 회로: 형식 검증
AI: 코드 생성 LLM 이 AST 활용

실전 도구와 언어 처리기

PLT 지식이 직접 들어가는 실전 도구 분류:

도구 / 프레임워크	언어	관련 PLT 개념
Babel / SWC	JS	AST 변환 트랜스파일러
TypeScript	TS	타입 시스템, 타입 추론, 타입 체킹
ESLint / Clippy	JS / Rust	정적 분석, 패턴 매칭 on AST
LLVM	다언어	IR, 최적화 패스, 코드 생성
Tree-sitter	다언어	증분 파서, IDE 심볼 추출
ANTLR	다언어	LL(*) 파서 생성기
Cranelift	Rust	JIT 백엔드 (Wasmtime, Cranelift)

Babel AST 변환 예시

JSX 를 일반 JS 함수 호출로 변환하는 것이 Babel 트랜스파일의 핵심:

// 입력 (JSX)
<!-- mdx-component: Button -->
Click

// AST 변환 후 출력
React.createElement(Button, { onClick: fn }, "Click")

Babel 은:

소스를 파싱 → AST (parser: @babel/parser)
플러그인 체인에서 AST visitor 로 노드 변환
변환된 AST → 코드 생성 (@babel/generator)

이 파이프라인이 PLT 컴파일러 프론트엔드와 완전히 동일한 구조다.

오토마타와 실전 연결

오토마타	실전
DFA	Lexer 토큰 인식, 정규식 엔진
PDA	CFG 파서 (LL, LR)
Turing Machine	범용 계산, 정지 문제

Lex (flex) 는 정규식 → DFA 변환으로 빠른 lexer 생성. Yacc/bison 은 LALR(1) 파서 테이블 생성.

함정

[!WARNING] 이론만 배우고 구현 안 하면 잊음. 반드시 작은 언어를 직접 구현해봐야.

[!CAUTION] Dragon Book 부터 시작하면 좌절. 두껍고 오래됨. Crafting Interpreters 로 시작.

[!WARNING] 파서 생성기 만능 아님. yacc/bison 이 옛 관용, 요즘은 hand-written recursive descent 가 더 흔함 (에러 메시지 우수).

[!IMPORTANT] 최신 언어는 표준 파이프라인을 따르지 않음. Rust 는 여러 pass, Swift 는 별도 SIL, Go 는 매우 단순. 원리 이해 후 각 언어 특성.

김신건의 로그 - 위키 / plt

[PLT] Abstract Syntax Tree (AST)

정의

왜 트리인가

AST 예시

AST vs Parse Tree (Concrete Syntax Tree)

Parse Tree (CST)

AST

AST 노드 정의 (TypeScript 예시)

AST 순회 (Traversal)

Depth-First

방문 시점

Visitor Pattern

AST 변환 (Transformation)

실전 사용 사례

1. 인터프리터

2. 컴파일러 (코드 생성)

3. 정적 분석 / 린터

4. 트랜스파일러

5. IDE 지원

6. Code Mods (자동 리팩터링)

AST Explorer

언어별 AST 표기법

JavaScript

TypeScript

Python

Rust

Go

함정

관련 위키

[PLT] Interpreter vs Compiler

정의

Compiler 파이프라인

Interpreter 파이프라인

Tree-Walking Interpreter (의사코드)

Bytecode VM

JIT (Just-In-Time)

AOT vs JIT vs Interpreter

하이브리드 (현대)

JavaScript (V8)

Java (HotSpot)

Python (CPython)

C# (.NET)

Transpiler (소스-대-소스 컴파일러)

Cross-Compilation

REPL (Read-Eval-Print Loop)

Meta-Circular Interpreter

Interpreter vs Compiler 선택 기준

함정

관련 위키

[PLT] IR, 최적화, 코드 생성 (Compiler Backend)

정의

왜 IR 인가

IR 종류

1. AST 자체

2. Three-Address Code (TAC)

3. Static Single Assignment (SSA)

Phi 함수 (Φ)

왜 SSA 인가

4. Control Flow Graph (CFG)

5. LLVM IR

Optimization (최적화)

Constant Folding

Constant Propagation

Dead Code Elimination

Common Subexpression Elimination (CSE)

Function Inlining

Loop Optimizations

Tail Call Optimization

Escape Analysis

실행 순서 (Pass Manager)

Code Generation

Register Allocation

Instruction Selection

Instruction Scheduling

Peephole Optimization

LLVM 파이프라인

목표 코드 종류

Native (기계어)

Bytecode