if-else를 걷어내다: Instructor로 비즈니스 로직 구조화하기

1,000줄의 if-else를 걷어내다: Instructor로 비즈니스 로직 구조화하기#

1.1 들어가며: 아무도 건드리지 못하는 1,000줄의 코드#

플랫폼 개발팀의 박 수석에게는 아무도 쉽게 건드리지 못하는 파일이 하나 있었다.

PromotionRuleEngine.java

마지막 수정일은 7년 전. 원래 작성자는 이미 회사를 떠난 지 오래였다.

문제의 핵심은 applyPromotions라는 메서드였다. 이 메서드 안에는 1,000줄이 넘는 if-else와 예외 처리 코드가 복잡하게 얽혀 있었다.

처음부터 이렇게 복잡했던 것은 아니다.

처음에는 단순했다.

  • 신규 가입 고객은 10% 할인
  • VIP 고객은 15% 할인
  • 5만 원 이상 구매하면 무료 배송

하지만 시간이 지나면서 조건이 하나씩 붙기 시작했다.

  • 특가 상품은 할인 대상에서 제외
  • 신규 고객 할인과 VIP 할인은 중복 불가
  • 특정 시즌에는 별도의 이벤트 할인 적용
  • 일부 프로모션은 다른 할인과 중복 가능
  • 특정 상품군을 함께 구매하면 추가 할인
  • 블랙프라이데이에는 기존 규칙보다 이벤트 할인을 우선 적용

각각의 규칙은 어렵지 않다.

진짜 문제는 규칙과 규칙이 만나는 순간 시작된다.

신규 고객이면서 VIP이고, 특가 상품을 장바구니에 넣었으며, 장바구니 금액이 5만 원을 넘었고, 마침 블랙프라이데이라면 어떻게 해야 할까?

어느 규칙을 먼저 적용해야 하는가?

어떤 할인은 중복할 수 있고 어떤 할인은 중복할 수 없는가?

특가 상품은 전체 금액에는 포함하지만 할인 기준 금액에서는 제외해야 하는가?

이런 조건이 수십 개를 넘어가면 if-else의 순서 자체가 비즈니스 로직이 되어버린다.

그러던 어느 날 마케팅팀에서 새로운 요청이 들어왔다.

"이번 주말에 장난감과 가전제품을 함께 구매하면 총액에서 2만 원을 추가 할인해 주세요."

문장으로 보면 단순하다.

하지만 박 수석에게는 전혀 단순하지 않았다.

이 규칙을 VIP 할인보다 먼저 적용해야 할까?

신규 고객 할인과 중복해도 될까?

특가 상품도 장난감이나 가전제품 카테고리 판정에 포함해야 할까?

블랙프라이데이와 겹치면 어느 쪽이 우선할까?

레거시 시스템에서 가장 무서운 것은 코드가 길다는 사실이 아니다.

코드를 수정했을 때 무엇이 함께 깨질지 알 수 없다는 것이다.

그렇다면 접근 방법을 바꿔보면 어떨까?

모든 비즈니스 규칙을 조건문으로 번역하는 대신 사람이 이해할 수 있는 정책으로 관리하고, LLM이 정책을 해석하도록 한 다음 결과는 프로그램이 사용할 수 있는 명확한 데이터 구조로 강제하는 것이다.

여기서 등장하는 것이 Instructor와 Pydantic을 이용한 구조화된 출력이다.

1.2 문제의 본질: 비즈니스 로직이 코드에 갇혀 있다#

1.2.1 조건문 하나는 문제가 아니다#

다음 코드는 전혀 복잡하지 않다.

if user.is_new:
    discount = cart_total * 0.1

if user.is_vip:
    discount = cart_total * 0.15

하지만 현실에서는 곧 예외가 추가된다.

if user.is_new:
    ...

if user.is_vip:
    ...

if cart.has_special_item:
    ...

if is_black_friday:
    ...

if cart.has_toy and cart.has_electronics:
    ...

그리고 다시 조건 사이의 우선순위를 처리해야 한다.

if is_black_friday:
    ...
elif user.is_vip:
    ...
elif user.is_new:
    ...

여기에 중복 가능한 할인과 중복 불가능한 할인이 섞이기 시작하면 코드의 복잡도는 빠르게 증가한다.

결국 개발자는 할인 정책을 구현하는 것이 아니라 조건문의 실행 순서를 관리하는 사람이 되어버린다.

1.3 패러다임의 변화: 로직을 데이터로 관리한다#

전통적인 애플리케이션에서는 대체로 다음 구조를 사용한다.

비즈니스 요구사항
        ↓
개발자가 코드로 변환
        ↓
if / else
        ↓
애플리케이션 실행

비즈니스 정책이 바뀔 때마다 개발자가 코드를 수정해야 한다.

이를 개선하기 위해 Drools와 같은 규칙 엔진이 등장했다.

비즈니스 정책
        ↓
규칙 파일
        ↓
Rules Engine
        ↓
애플리케이션

규칙 엔진은 여전히 중요한 기술이다.

특히 결제, 금융, 세금, 재고처럼 결과가 항상 동일해야 하는 결정적 시스템에서는 명시적인 규칙 엔진이 매우 유용하다.

하지만 LLM의 등장으로 또 다른 선택지가 생겼다.

자연어 정책
      ↓
     LLM
      ↓
구조화된 결과
      ↓
Pydantic 검증
      ↓
애플리케이션

여기서 중요한 변화가 하나 있다.

개발자가 모든 정책을 직접 조건문으로 번역하지 않아도 된다.

예를 들어 다음 문장 자체를 정책 데이터로 사용할 수 있다.

VIP 고객은 특가 상품을 제외한 상품 금액의 15%를 할인한다.

LLM은 이 문장의 의미를 해석할 수 있다.

하지만 여기서 문제가 하나 더 생긴다.

LLM이 다음처럼 답하면 어떻게 해야 할까?

VIP 고객이므로 약 6천 원 정도 할인하면 될 것 같습니다.
배송비도 무료로 처리하면 됩니다.

사람은 이해할 수 있지만 프로그램은 사용하기 어렵다.

그래서 구조화된 출력이 필요하다.

1.4 Instructor가 필요한 이유#

Instructor의 핵심 역할은 LLM의 자연어 출력을 애플리케이션에서 사용할 수 있는 타입이 있는 데이터로 바꾸는 것이다.

예를 들어 우리가 원하는 결과가 다음과 같다고 하자.

{
  "original_total": 120000,
  "total_discount_amount": 26000,
  "shipping_fee": 0,
  "final_amount": 94000
}

이 구조를 Pydantic 모델로 정의한다.

from pydantic import BaseModel


class PromotionResult(BaseModel):
    original_total: int
    total_discount_amount: int
    shipping_fee: int
    final_amount: int

그리고 Instructor에 다음과 같이 알려준다.

response_model=PromotionResult

이제 우리가 원하는 것은 단순한 텍스트가 아니다.

PromotionResult라는 데이터 계약을 만족하는 결과다.

Instructor의 현재 문서에서도 response_model은 Pydantic 모델을 이용해 출력 스키마를 정의하고, 모델의 응답을 검증한 뒤 Pydantic 객체로 반환하는 핵심 기능으로 설명된다.

1.5 먼저 비즈니스 규칙부터 꺼내자#

AI를 적용한다고 해서 1,000줄의 코드를 그대로 프롬프트에 넣어서는 안 된다.

먼저 코드 속에 숨어 있는 정책을 찾아야 한다.

개발자, 기획자, 마케팅 담당자가 기존 코드를 분석해 다음처럼 정리했다고 하자.

1.5.1 신규 고객 할인#

가입 후 첫 구매 고객은 **특가 상품을 제외한 금액의 10%**를 할인한다.

최대 할인 금액은 5,000원이다.

1.5.2 VIP 고객 할인#

VIP 고객은 특가 상품을 제외한 금액의 15%를 할인한다.

1.5.3 무료 배송#

할인 적용 전 상품 금액 합계가 50,000원 이상이면 배송비 3,000원을 면제한다.

1.5.4 할인 중복 정책#

신규 고객 할인과 VIP 고객 할인은 동시에 적용할 수 없다.

두 조건을 모두 만족한다면 VIP 할인을 적용한다.

1.5.5 특가 상품 제외#

특가 태그가 있는 상품은 신규 고객 할인과 VIP 할인 금액 계산에서 제외한다.

1.5.6 가정의 달 특별 할인#

장바구니에 장난감 카테고리와 가전제품 카테고리 상품이 모두 존재하면 20,000원을 추가 할인한다.

1.5.7 블랙프라이데이 정책#

블랙프라이데이 기간에는 별도의 이벤트 할인 정책을 우선 적용한다.

기존 프로모션과 중복 가능한지 여부 역시 명시적으로 정의한다.

여기서 중요한 것은 단순히 할인율을 기록하는 것이 아니다.

규칙 사이의 충돌과 우선순위까지 정책으로 표현해야 한다.

1.6 Pydantic으로 결과 계약 설계하기#

이제 AI가 무엇을 반환해야 하는지 정의한다.

models.py

from typing import List
from pydantic import BaseModel, Field


class CartItem(BaseModel):
    product_id: str
    product_name: str

    price: int = Field(
        ge=0,
        description="상품 단가"
    )

    quantity: int = Field(
        gt=0,
        description="상품 수량"
    )

    category: str

    tags: List[str] = Field(
        default_factory=list
    )


class AppliedDiscount(BaseModel):
    rule_id: str = Field(
        description="적용된 프로모션 규칙 ID"
    )

    name: str = Field(
        description="프로모션 이름"
    )

    description: str = Field(
        description="프로모션이 적용된 이유"
    )

    amount: int = Field(
        ge=0,
        description="할인 금액"
    )


class PromotionResult(BaseModel):
    original_total: int = Field(
        ge=0,
        description="할인 전 상품 총액"
    )

    discounts: List[AppliedDiscount] = Field(
        default_factory=list,
        description="적용된 프로모션 목록"
    )

    total_discount_amount: int = Field(
        ge=0,
        description="총 할인 금액"
    )

    shipping_fee: int = Field(
        ge=0,
        description="최종 배송비"
    )

    final_amount: int = Field(
        ge=0,
        description="최종 결제 금액"
    )

    applied_rule_ids: List[str] = Field(
        default_factory=list,
        description="적용된 규칙 ID 목록"
    )

    explanation: str = Field(
        description="적용된 규칙과 계산 결과에 대한 설명"
    )

여기서 중요한 것이 Field의 description이다.

단순한 개발 문서 역할만 하는 것이 아니다.

Instructor에서는 Pydantic 모델의 타입, 필드 설명, 모델 설명 등을 이용해 LLM이 어떤 데이터를 생성해야 하는지 이해하도록 만들 수 있다.

즉 Pydantic 모델 자체가 프롬프트의 일부이자 API 계약이 되는 것이다.

1.7 Instructor 클라이언트 구성하기#

먼저 Instructor를 설치한다.

pip install instructor pydantic

API 키는 코드에 직접 넣기보다 환경 변수로 관리한다.

export OPENAI_API_KEY="YOUR_API_KEY"

Instructor의 현재 방식에서는 from_provider()를 이용해 제공자와 모델을 지정할 수 있다.

import instructor

client = instructor.from_provider(
    "openai/gpt-5.6-luna"
)

간단한 예를 만들어보자.

from pydantic import BaseModel
import instructor


class UserInfo(BaseModel):
    name: str
    age: int


client = instructor.from_provider(
    "openai/gpt-5.6-luna"
)


user = client.create(
    response_model=UserInfo,
    messages=[
        {
            "role": "user",
            "content": "홍길동은 30세입니다."
        }
    ],
    reasoning_effort="none",
)


print(user)

결과는 단순 문자열이 아니라 다음과 같은 Pydantic 객체다.

UserInfo(
    name="홍길동",
    age=30
)

따라서 별도로 JSON 문자열을 파싱할 필요가 없다.

1.8 프로모션 규칙을 코드 밖으로 분리하기#

이제 프로모션 정책을 별도의 파일로 관리한다.

promotion_rules.txt

[RULE_NEW_CUSTOMER]

신규 고객의 첫 구매에서는
특가 상품을 제외한 상품 금액의 10%를 할인한다.

최대 할인 금액은 5,000원이다.


[RULE_VIP]

VIP 고객은
특가 상품을 제외한 상품 금액의 15%를 할인한다.


[RULE_FREE_SHIPPING]

할인 적용 전 상품 총액이
50,000원 이상이면 배송비를 0원으로 한다.


[RULE_DISCOUNT_PRIORITY]

신규 고객 할인과 VIP 할인은
동시에 적용하지 않는다.

두 조건을 모두 만족하면
VIP 할인을 적용한다.


[RULE_FAMILY_EVENT]

장바구니에 장난감과 가전제품 카테고리가
모두 포함되어 있으면 20,000원을 추가 할인한다.

이렇게 하면 정책 자체와 애플리케이션 코드를 분리할 수 있다.

하지만 중요한 주의점이 있다.

운영 중인 결제 시스템에서 텍스트 파일 수정만으로 즉시 정책을 변경하도록 만드는 것은 위험하다.

실제 서비스라면 최소한 다음 요소가 필요하다.

  • 정책 버전
  • 적용 시작일
  • 종료일
  • 작성자
  • 승인자
  • 변경 이력
  • 테스트 상태
  • 롤백 기능

AI를 사용한다고 해서 운영 통제가 사라지는 것은 아니다.

오히려 정책을 코드 밖으로 꺼낼수록 정책 관리 체계가 더 중요해진다.

1.9 Instructor 기반 프로모션 분석 함수 만들기#

ai_promotion_engine.py

import json
from pathlib import Path
from typing import List

import instructor

from models import CartItem, PromotionResult


client = instructor.from_provider(
    "openai/gpt-5.6-luna"
)


def get_promotion_rules_text() -> str:
    return Path(
        "promotion_rules.txt"
    ).read_text(
        encoding="utf-8"
    )


def analyze_promotions(
    user_is_vip: bool,
    user_is_new: bool,
    cart_items: List[CartItem],
    shipping_fee_default: int = 3000,
) -> PromotionResult:

    rules_text = get_promotion_rules_text()

    cart_json = json.dumps(
        [
            item.model_dump()
            for item in cart_items
        ],
        ensure_ascii=False,
        indent=2,
    )

    prompt = f"""
당신은 전자상거래 프로모션 정책 분석 시스템입니다.

아래 사용자 정보와 장바구니,
프로모션 정책을 분석하세요.

반드시 다음 원칙을 지키세요.

1. 정책에 존재하지 않는 할인을 만들지 마세요.
2. 할인 중복 정책을 확인하세요.
3. 특가 상품 제외 조건을 확인하세요.
4. 적용된 규칙 ID를 반환하세요.
5. 불확실한 규칙은 임의로 만들지 마세요.
6. 결과는 지정된 PromotionResult 구조를 따르세요.

프로모션 정책:
---
{rules_text}
---

사용자 정보:

VIP 여부:
{user_is_vip}

신규 고객 여부:
{user_is_new}

장바구니:

{cart_json}

기본 배송비:

{shipping_fee_default}원
"""

    return client.create(
        response_model=PromotionResult,
        messages=[
            {
                "role": "user",
                "content": prompt,
            }
        ],
        max_retries=2,
        reasoning_effort="none",
    )

max_retries도 중요한 옵션이다.

예를 들어 모델이 다음처럼 잘못된 값을 반환했다고 하자.

{
  "shipping_fee": -3000
}

Pydantic 모델에는 다음 조건이 있다.

shipping_fee: int = Field(ge=0)

따라서 검증에 실패한다.

Instructor는 이러한 검증 실패를 모델에 다시 전달해 올바른 구조를 생성하도록 재시도할 수 있다.

이것이 단순한 JSON 출력과 Instructor를 이용한 구조화 출력의 중요한 차이 중 하나다.

1.10 복잡한 장바구니를 테스트해보자#

다음과 같은 고객이 있다고 하자.

  • 신규 고객
  • VIP 고객
  • 장난감 구매
  • 가전제품 구매
  • 가전제품은 특가 상품
  • 상품 총액 50,000원 이상

테스트 코드를 작성한다.

from models import CartItem
from ai_promotion_engine import analyze_promotions


cart = [
    CartItem(
        product_id="T001",
        product_name="로봇 장난감",
        price=40000,
        quantity=1,
        category="장난감",
    ),

    CartItem(
        product_id="E002",
        product_name="공기청정기",
        price=80000,
        quantity=1,
        category="가전제품",
        tags=["특가"],
    ),
]


result = analyze_promotions(
    user_is_vip=True,
    user_is_new=True,
    cart_items=cart,
)


print(
    result.model_dump_json(
        indent=2
    )
)

상품 총액은 다음과 같다.

40,000원 + 80,000원
= 120,000원

VIP 할인과 신규 고객 할인이 동시에 가능하지만 정책상 VIP 할인을 선택한다.

특가 상품인 공기청정기 80,000원은 할인 기준 금액에서 제외한다.

따라서 VIP 할인 대상 금액은 40,000원이다.

40,000 × 15%
= 6,000원

장난감과 가전제품이 모두 존재하므로 가정의 달 할인도 적용된다.

20,000원

총 할인 금액은 다음과 같다.

6,000 + 20,000
= 26,000원

배송비는 무료다.

따라서 최종 금액은 다음과 같다.

120,000
- 26,000
+ 0
= 94,000원

AI가 제대로 정책을 해석했다면 이와 같은 구조의 결과를 반환하게 된다.

1.11 여기서 반드시 해야 하는 것: AI 결과 다시 검산하기#

여기서 매우 중요한 문제가 있다.

AI가 94,000원이라고 반환했다고 해서 바로 결제 시스템에 전달하면 안 된다.

LLM은 계산기나 전통적인 규칙 엔진과 동일한 성격의 시스템이 아니다.

따라서 금액처럼 결정적인 값은 일반 프로그램으로 다시 확인하는 것이 안전하다.

예를 들어 다음 검증을 추가한다.

def validate_result(
    result: PromotionResult
) -> None:

    expected = (
        result.original_total
        - result.total_discount_amount
        + result.shipping_fee
    )

    if result.final_amount != expected:
        raise ValueError(
            "최종 금액 검증 실패"
        )

    if result.total_discount_amount > result.original_total:
        raise ValueError(
            "할인 금액이 상품 총액보다 큽니다."
        )

    if result.final_amount < 0:
        raise ValueError(
            "최종 결제 금액은 음수가 될 수 없습니다."
        )

그러면 구조가 달라진다.

자연어 정책
     ↓
    LLM
     ↓
Instructor
     ↓
Pydantic 검증
     ↓
비즈니스 검증
     ↓
결정적 계산
     ↓
결제 시스템

이 구조가 훨씬 현실적이다.

1.12 AI가 잘하는 일과 코드가 잘하는 일을 구분하자#

LLM은 다음과 같은 작업에 강하다.

"VIP이면서 신규 고객이면
둘 중 더 높은 할인을 적용한다."

이런 자연어 정책의 의미를 이해하는 것이다.

반면 다음 계산은 일반 코드가 훨씬 안정적이다.

40000 * 0.15

따라서 가장 좋은 구조는 역할을 나누는 것이다.

AI가 담당하는 영역#

  • 자연어 정책 해석
  • 비정형 데이터 이해
  • 적용 가능한 규칙 후보 추출
  • 정책 충돌 발견
  • 결과 설명 생성

일반 코드가 담당하는 영역#

  • 금액 계산
  • 세금 계산
  • 합계 계산
  • 범위 검증
  • 재고 차감
  • 데이터베이스 트랜잭션
  • 결제 승인

AI를 모든 로직의 대체재로 보는 것보다 자연어와 프로그램 사이의 해석 계층으로 보는 편이 훨씬 실용적이다.

1.13 reasoning보다 explanation을 사용하자#

LLM 애플리케이션을 만들다 보면 다음과 같은 필드를 만들고 싶을 수 있다.

reasoning: str

하지만 운영 시스템에서는 이를 AI의 내부 사고 과정으로 생각하기보다 사용자나 운영자가 확인할 수 있는 결정 설명으로 설계하는 것이 좋다.

따라서 다음과 같은 필드가 더 명확하다.

applied_rule_ids: list[str]
explanation: str

예를 들어:

{
  "applied_rule_ids": [
    "RULE_VIP",
    "RULE_FREE_SHIPPING",
    "RULE_FAMILY_EVENT"
  ],

  "explanation":
    "VIP 고객이므로 VIP 할인 정책을 적용했습니다. 특가 상품은 할인 대상에서 제외했으며 장난감과 가전제품이 모두 포함되어 특별 할인 조건도 충족했습니다."
}

이 방식의 장점은 감사 로그를 남기기 쉽다는 것이다.

나중에 문제가 발생했을 때 다음 질문에 답할 수 있다.

어떤 정책이 적용되었는가?
RULE_VIP
RULE_FREE_SHIPPING
RULE_FAMILY_EVENT

정책 ID를 남기는 것은 실제 운영 시스템에서 매우 중요하다.

1.14 기존 시스템을 한 번에 없애지 않는다#

이제 AI 엔진이 만들어졌다고 하자.

그렇다고 기존 PromotionRuleEngine을 바로 삭제하면 안 된다.

처음에는 두 시스템을 동시에 실행한다.

                 주문
                  │
          ┌───────┴───────┐
          ↓               ↓

 기존 PromotionRuleEngine   AI Engine
          ↓               ↓

       기존 결과          AI 결과

          └───────┬───────┘
                  ↓

               비교

                  ↓

             차이 기록

예를 들어 10만 건의 과거 주문을 실행한다.

기존 엔진 : 94,000원
AI 엔진   : 94,000원

→ 일치

하지만 다음과 같은 결과가 나올 수도 있다.

기존 엔진 : 92,000원
AI 엔진   : 94,000원

→ 불일치

이때 중요한 것은 AI가 틀렸다고 바로 결론 내리지 않는 것이다.

기존 시스템에 숨어 있던 버그일 수도 있고, 문서화되지 않은 예외 규칙이 존재할 수도 있다.

이 과정에서 오히려 10년 동안 코드에 숨어 있던 비즈니스 정책을 발견할 수도 있다.

1.15 섀도 아키텍처로 안전하게 전환하기#

현실적인 전환 과정은 다음과 같다.

1단계
기존 코드에서 정책 추출

        ↓

2단계
자연어 정책 문서화

        ↓

3단계
Pydantic 출력 모델 설계

        ↓

4단계
Instructor 기반 AI 엔진 구축

        ↓

5단계
과거 데이터 재생

        ↓

6단계
기존 엔진과 결과 비교

        ↓

7단계
불일치 분석

        ↓

8단계
비핵심 영역부터 적용

        ↓

9단계
모니터링

        ↓

10단계
검증된 영역 확대

이렇게 기존 시스템 뒤에서 새로운 시스템을 동시에 실행하면서 결과를 비교하는 방식을 섀도 실행이라고 부를 수 있다.

AI 시스템을 레거시 시스템에 도입할 때 특히 유용하다.

1.16 Instructor의 최신 활용 방식#

Instructor는 특정 LLM 하나에 종속된 라이브러리가 아니다.

from_provider()를 이용하면 제공자와 모델을 비교적 일관된 방식으로 구성할 수 있다.

예를 들어 기본 구조는 다음과 같다.

client = instructor.from_provider(
    "provider/model"
)

따라서 애플리케이션의 중심을 특정 모델의 응답 형식이 아니라 Pydantic 데이터 모델에 둘 수 있다.

또한 OpenAI 환경에서는 Responses API를 사용하는 구성도 지원한다.

client = instructor.from_provider(
    "openai/gpt-5.6-luna",
    mode=instructor.Mode.RESPONSES_TOOLS
)

구조화된 결과를 받는 기본 개념은 동일하다.

LLM Provider
      ↓
 Instructor
      ↓
response_model
      ↓
 Pydantic
      ↓
Application

이 구조의 중요한 장점은 모델을 변경하더라도 애플리케이션 내부의 데이터 계약을 최대한 유지할 수 있다는 것이다.

1.17 구조화된 출력의 진짜 가치#

Instructor를 처음 접하면 이렇게 생각하기 쉽다.

"JSON을 편하게 받는 라이브러리 아닌가?"

하지만 핵심은 JSON 자체가 아니다.

핵심은 자연어 세계와 프로그램 세계 사이에 타입이 있는 경계를 만드는 것이다.

사람은 이렇게 말한다.

VIP 고객인데 특가 상품은 할인에서 빼고,
장난감과 가전제품을 같이 구매했으면
2만 원을 추가로 할인해 주세요.

프로그램은 다음과 같은 것을 원한다.

{
  "applied_rule_ids": [
    "RULE_VIP",
    "RULE_FAMILY_EVENT"
  ],

  "discounts": [
    {
      "name": "VIP 고객 할인",
      "amount": 6000
    },
    {
      "name": "가정의 달 특별 할인",
      "amount": 20000
    }
  ]
}

그 사이를 연결하는 것이 LLM이다.

그리고 LLM의 자유로운 출력을 애플리케이션이 신뢰할 수 있는 형태로 제한하는 것이 Instructor와 Pydantic이다.

1.18 마무리: 개발자는 조건문 작성자에서 경계 설계자로 이동한다#

처음 박 수석이 마주한 문제는 1,000줄짜리 if-else였다.

처음에는 문제를 이렇게 생각했다.

"이 1,000줄을 어떻게 리팩터링할까?"

하지만 문제를 다시 바라보면 질문 자체가 달라진다.

"왜 모든 비즈니스 정책이 코드 안에 들어 있어야 할까?"

AI와 구조화된 출력을 이용하면 시스템을 다음과 같이 분리할 수 있다.

사람이 작성하는 정책
        ↓
       LLM
        ↓
정책 해석 및 구조화
        ↓
Instructor
        ↓
Pydantic 검증
        ↓
결정적 프로그램 로직
        ↓
실제 서비스

여기서 AI는 계산기를 대신하지 않는다.

데이터베이스도 대신하지 않는다.

결제 시스템도 대신하지 않는다.

AI가 가장 큰 가치를 만드는 곳은 사람이 표현한 의도를 프로그램이 처리할 수 있는 구조로 변환하는 경계다.

그리고 Instructor는 그 경계를 타입이 있는 데이터로 만든다.

결국 AI 시대의 개발자는 모든 조건을 직접 코드로 옮기는 사람에서 조금씩 다른 역할로 이동하게 된다.

어디까지 AI에게 맡길 것인지, 어디부터 프로그램이 검증할 것인지, 그리고 두 세계 사이의 데이터 계약을 어떻게 설계할 것인지 결정하는 사람이다.

1,000줄의 if-else를 없애는 것보다 중요한 것은 바로 이 구조를 만드는 것이다.

# 관련 참고 도서#

레거시 스파게티코드 AI로 심폐소생술#

10년 넘게 쌓인 레거시 코드와 기술 부채를 무작정 재구축하지 않고, AI를 활용해 기존 시스템을 유지하면서 점진적으로 현대화하는 방법을 다루는 실전 가이드입니다.

레거시 코드 분석부터 데이터 구조화, 자연어 기반 데이터 접근, 로컬 AI, AI 에이전트를 활용한 운영 자동화까지 기존 시스템에 AI를 접목하는 다양한 방법을 살펴봅니다.

교보문고에서 전자책 보기 YES24에서 전자책 보기

이 페이지의 목차