코틀린 디자인 패턴 (15) - Interpreter 패턴은 어디까지 써야 할까

이 글의 목차 숨기기

왜 이 패턴이 필요한가

가장 짧은 정의: 문법 규칙을 클래스 구조로 옮긴다

마무리

코틀린 Interpreter 패턴은 디자인 패턴 책에서 이름은 자주 보이지만, 실제 코드에서는 어디까지 적용해야 하는지 감이 잘 안 오는 패턴입니다. 이유는 이 패턴이 단순 클래스 하나를 감싸는 구조가 아니라, 작은 언어 규칙이나 표현식을 객체 구조로 바꾸어 해석하는 흐름과 연결되기 때문입니다.

이번 글에서는 Interpreter 패턴을 추상 정의로 끝내지 않고, 간단한 규칙 언어를 AST처럼 표현하고 evaluate 흐름으로 해석하는 구조로 설명하겠습니다. 그리고 코틀린에서는 어디서 더 읽기 쉬워지고, 어디서부터는 오히려 과해지는지도 같이 보겠습니다.

Interpreter 패턴 핵심 요약 카드 — 핵심 판단 기준을 먼저 잡는 요약 카드

왜 이 패턴이 필요한가

코드 안에 작은 규칙 언어가 숨어 있는 경우가 있습니다. 예를 들어 조건식을 문자열로 저장했다가 평가하거나, 필터 규칙을 조합하거나, 검색 쿼리를 객체로 풀어내야 하는 상황입니다. 이때 if문과 분기 로직이 커질수록 규칙 구조가 코드 속에 흩어져 버립니다.

Interpreter 패턴은 이 문제를 “규칙을 객체 구조로 표현하고, 각 객체가 자기 의미를 해석하게 한다”는 방향으로 풀려고 합니다. 그래서 핵심은 실행 자체보다 문법과 해석 책임을 구조로 드러내는 것입니다.

가장 짧은 정의: 문법 규칙을 클래스 구조로 옮긴다

Interpreter 패턴은 표현식의 문법 요소를 클래스 계층으로 나누고, 각 노드가 evaluate 같은 메서드로 자신의 의미를 계산하게 만드는 패턴입니다. 즉 Number, Plus, Minus, Variable 같은 요소가 각자 객체가 됩니다.

이 구조는 작은 언어를 트리로 본다고 이해하면 쉽습니다. 하나의 큰 수식이 있고, 그 안에 하위 표현식이 있고, 각 표현식이 다시 자신의 하위 표현식을 갖습니다. 결국 전체 문장은 트리 구조가 됩니다.

Interpreter 패턴 AST 구조 그림 — 작은 수식을 AST처럼 객체 구조로 바꾸면 각 노드가 자기 의미를 해석할 수 있다

입문자가 많이 헷갈리는 부분은 여기서 parser와 interpreter를 한 덩어리로 보는 것입니다. 하지만 개념상은 구분하는 편이 좋습니다. parser는 입력을 구조로 바꾸고, interpreter는 그 구조의 의미를 계산합니다. 작은 예제에서는 두 단계가 섞여 보일 수 있지만, 머릿속에서는 분리해 두는 편이 훨씬 이해가 쉽습니다.

코틀린 코드로 보면 어떻게 생길까

sealed interface Expr {
    fun evaluate(): Int
}

data class NumberExpr(private val value: Int) : Expr {
    override fun evaluate(): Int = value
}

data class PlusExpr(
    private val left: Expr,
    private val right: Expr,
) : Expr {
    override fun evaluate(): Int = left.evaluate() + right.evaluate()
}

data class MinusExpr(
    private val left: Expr,
    private val right: Expr,
) : Expr {
    override fun evaluate(): Int = left.evaluate() - right.evaluate()
}

val expr: Expr = PlusExpr(
    NumberExpr(1),
    MinusExpr(NumberExpr(5), NumberExpr(2))
)

println(expr.evaluate()) // 4

sealed interface Expr {
    fun evaluate(): Int
}

data class NumberExpr(private val value: Int) : Expr {
    override fun evaluate(): Int = value
}

data class PlusExpr(
    private val left: Expr,
    private val right: Expr,
) : Expr {
    override fun evaluate(): Int = left.evaluate() + right.evaluate()
}

data class MinusExpr(
    private val left: Expr,
    private val right: Expr,
) : Expr {
    override fun evaluate(): Int = left.evaluate() - right.evaluate()
}

val expr: Expr = PlusExpr(
    NumberExpr(1),
    MinusExpr(NumberExpr(5), NumberExpr(2))
)

println(expr.evaluate()) // 4

이 예제의 핵심은 evaluate가 한곳에 몰려 있지 않다는 점입니다. NumberExpr는 자기 값을 반환하고, PlusExpr는 왼쪽과 오른쪽을 평가한 뒤 더하고, MinusExpr는 뺍니다. 즉 각 표현식 객체가 자기 의미를 스스로 계산합니다.

코틀린에서는 sealed interface와 data class를 쓰면 이 구조가 꽤 읽기 좋게 정리됩니다. 전통적인 자바 스타일로 구현하면 상속 계층과 보일러플레이트가 더 무거워질 수 있는데, 코틀린은 작은 AST를 표현할 때 그 무게를 줄여줍니다.

동작 흐름은 어떻게 읽어야 할까

실행 시점에는 보통 전체 표현식의 루트 노드에서 evaluate를 호출합니다. 그러면 루트는 하위 노드 평가를 요청하고, 하위 노드는 자기 하위 노드를 다시 평가합니다. 이렇게 재귀적으로 내려갔다가, 숫자 같은 terminal expression에서 실제 값을 반환하면서 다시 올라옵니다.

Interpreter 패턴 해석 흐름 그림 — 입력 규칙을 객체 구조로 만들고, 각 노드가 재귀적으로 자신의 의미를 계산하는 흐름

즉 Interpreter 패턴은 결국 트리를 따라 내려가며 의미를 계산하는 구조입니다. 그래서 트리, 재귀, AST, 평가기(evaluator)라는 단어들이 자주 함께 나옵니다.

어떤 문제에서 자연스러울까

간단한 수식 계산기나 조건식 평가기
검색 필터 DSL처럼 규칙을 조합하는 구조
정책 규칙을 객체화해서 테스트 가능하게 만들고 싶을 때
문법 요소가 작고 비교적 안정적일 때

핵심은 문법이 작고, 규칙 요소를 객체 단위로 나누었을 때 읽기 좋아지는 문제여야 한다는 점입니다. 예를 들어 수식, 조건식, 간단한 쿼리 규칙은 Interpreter 패턴과 잘 맞습니다.

언제는 오히려 과할까

문법이 커지기 시작하면 클래스 수가 빠르게 늘어납니다. terminal/non-terminal expression이 많아지고 parser 단계까지 복잡해지면, 패턴이 주는 깔끔함보다 유지보수 부담이 더 커질 수 있습니다.

Interpreter 패턴이 잘 맞는 경우와 과한 경우 비교 카드 — 작은 규칙 DSL에는 맞지만 큰 문법으로 갈수록 전용 도구가 더 나을 수 있다

즉 Interpreter 패턴은 “언어를 만들 수 있다”는 가능성보다 “작은 규칙을 구조적으로 드러내는 데 적합하다”는 쪽으로 이해하는 편이 안전합니다. 진짜 문법이 커지면 parser generator나 전용 쿼리 엔진, rule engine 쪽을 보는 편이 낫습니다.