4.12.1 프롬프트 엔지니어링의 한계와 프롬프트 프로그래밍(Prompt Programming)의 부상

비결정성(Nondeterminism)을 가진 거대 언어 모델(LLM)을 다루기 위해 등장한 1세대 접근법은 ’프롬프트 엔지니어링(Prompt Engineering)’이었다. 개발자들은 “너는 세계 최고의 전문가다”, “단계별로 명확히 생각하라(Chain-of-Thought)“와 같은 주술적인 문장들을 시스템 명령에 하드코딩(Hard-coding)하여 모델의 출력을 지향점으로 유도하려 노력했다.

그러나 오라클(Oracle) 파이프라인과 같은 수학적이고 결정론적인 시스템을 구축하려는 공학자들에게, 이러한 텍스트 스튜디움 방식의 접근은 이내 치명적인 한계를 드러내기 시작했다.

1. 프롬프트 엔지니어링의 치명적 한계: 취약성(Brittleness)과 이식 불가능성

프롬프트 엔지니어링의 가장 큰 결함은 **테스트 취성(Test Brittleness)**이다. 특정 LLM(예: GPT-4)의 버전에 맞춰 수십 시간에 걸쳐 정교하게 조율된 시스템 프롬프트는 다른 모델(예: Claude 3, Llama 3)로 스위칭하거나 파인튜닝(Fine-tuning)된 모델을 얹는 순간 그 마법을 잃고 오작동(Fail)을 일으킨다.

표준화 불가능성: 코드는 선언적이고 명세(Specification)로서 동작하지만, 자연어 프롬프트는 모델의 내부 가중치(Weights)의 편향에 기댄 일종의 ’해킹’이다. 따라서 데이터셋 파이프라인이나 오라클의 채점 기준이 변경될 때마다 엔지니어가 수천 개의 프롬프트 문자열을 수동으로 재조정하는 것은 불가능에 가깝다.
최적화 불가능성: 개발자는 자신이 추가한 “친절하게 대답해 줘“라는 한 문장이 정확도(Accuracy)를 1.2% 상승시켰는지 0.3% 하락시켰는지 정량적으로 입증할 방법이 없다. 즉, 머신러닝의 핵심인 최적화(Optimization) 루프가 끊어진 채 엔지니어의 직관에만 의존하는 반쪽짜리 공학이었다.

2. 프레임워크의 진화: 텍스트 튜닝에서 ’컴파일(Compilation)’로

이러한 수동 문장 조작의 공학적 부채를 해결하기 위해 등장한 패러다임이 바로 **‘프롬프트 프로그래밍(Prompt Programming)’**이다.

스탠포드 대학 연구진이 제안한 DSPy(Declarative Self-Improving Language Programs)와 같은 최신 프레임워크는 프롬프트 문자열을 직접 작성하는 행위 자체를 금기시한다. 개발자는 오직 모델이 수행해야 할 입력과 출력의 **‘시그니처(Signature, 자료형 기반 구조)’**와, 성공을 판별할 수 있는 오라클 검증 로직인 **‘메트릭(Metric)’**만을 파이썬(Python) 코드로 정의한다.

# 기존 프롬프트 엔지니어링: 자연어 기반 하드코딩
prompt = f"다음 문장을 읽고 주요 엔티티를 JSON으로 추출해. 제발 딴소리 하지 말고: {text}"

# 프롬프트 프로그래밍 (DSPy 예시): 시그니처와 모듈 기반
class InformationExtractor(dspy.Signature):
    """주어진 문서에서 관계된 데이터 엔티티를 구조화합니다."""
    document = dspy.InputField(desc="입력 문서 텍스트")
    extracted_json = dspy.OutputField(desc="완벽히 파싱 가능한 JSON 구조")

3. 프롬프트 프로그래밍이 오라클 시스템을 완성하는 방식

프롬프트 프로그래밍 체계에서 프롬프트 텍스트는 사람이 쓰는 것이 아니라, 프레임워크의 내부 ’옵티마이저(Optimizer)’가 훈련 데이터를 바탕으로 수만 번의 시도 끝에 알아서 컴파일(Compile) 해내는 동적 산출물이다.

오라클이 정답지(Ground Truth)를 기준으로 Fail을 반환하면, 옵티마이저는 자동으로 퓨샷(Few-shot) 예제를 재배치하거나 시스템 명령어 구조를 변형하여 오라클 점수가 상승하는 방향으로 역전파(Backpropagation)와 유사한 최적화를 수행한다. 결국 프롬프트 프로그래밍의 부상은 AI 개발자들을 단어 선택의 스트레스에서 해방시키고, 그들을 평가 스키마(Evaluation Schema)와 결정론적 오라클을 설계하는 본연의 ‘소프트웨어 아키텍트’ 자리로 복귀시키고 있다.