언어 모델을 애플리케이션에 붙일 때 대부분의 개발자는 프롬프트 문자열을 손으로 다듬고, 모델이 돌려준 텍스트를 정규식이나 JSON 파서로 억지로 해체하는 과정을 반복한다. 파이썬 진영에서 이 방식을 뒤집은 프로젝트가 DSPy다. DSPy는 모델 호출 하나하나를 '입력과 출력이 선언된 타입 있는 함수'로 취급해, 측정하고 개선할 수 있는 대상으로 바꾼다. 최근 공개된 Imp는 이 DSPy를 엘릭서(Elixir)와 그 실행 환경인 BEAM으로 완전히 이식했다고 표방하는 라이브러리다. 시그니처, 모듈, 옵티마이저, 에이전트 루프, 검색(retrieval)이라는 DSPy의 구성 요소를 OTP의 동시성·안정성 위에서 그대로 돌리는 것이 목표다.
프롬프트 대신 시그니처를 쓴다
Imp의 핵심 발상은 '프롬프트를 직접 쓰지 않는다'는 데 있다. 개발자는 각 단계가 무엇을 받고 무엇을 반환하는지를 시그니처로 선언하고, 어떻게 사고할지를 고른다. 그러면 Imp가 시그니처로부터 프롬프트를 생성하고, 모델의 응답이 선언과 맞는지 검사한 뒤 타입이 붙은 필드로 돌려준다. 예컨대 어떤 필드가 세 가지 값 중 하나여야 한다면, 결과는 반드시 그 셋 중 하나이거나 아니면 오류가 반환된다. 같은 과제를 먼저 추론하게 하려면 Imp.chain_of_thought/2를, 도구를 쥐여 주려면 Imp.react/3를 쓰면 되고, 이때 시그니처 자체는 바뀌지 않는다. 사고 방식과 도구 사용을 바꿔도 인터페이스가 고정된다는 점이 이 접근의 장점이다.
예시와 지표로 프로그램을 스스로 개선한다
Imp의 이름값을 하는 부분은 '자기개선'이다. 라벨이 붙은 예시와 평가 지표를 주면, Imp가 프로그램을 채점하고 최적화한다. 이를 위해 세 종류의 목록이 필요하다. 옵티마이저가 학습하는 trainset, 시도한 프로그램들 사이에서 더 나은 쪽을 고를 때 쓰는 valset, 그리고 개선 전후 성능을 재는 testset이다. 여기에 실패 사례를 읽고 새 지시문을 쓰는 데 동원되는 더 강력한 모델(strong_lm)을 지정할 수 있다. 대표 옵티마이저인 GEPA는 프로그램을 실행해 어디서 실패했는지 읽고 지시문을 다시 쓴다. 그 밖에도 좋은 예시를 골라 붙이는 방식(LabeledFewShot, BootstrapFewShot), 지시문과 예시의 조합을 탐색하는 방식(MIPROv2), 프로그램 자신의 성공·실패 시도에서 규칙을 학습하는 방식(SIMBA), 나아가 모델 가중치를 직접 훈련하는 방식(파인튜닝, GRPO)까지 폭넓게 제공한다.
특히 실무적으로 눈에 띄는 지점은 결과물의 투명성이다. 최적화가 끝나면 새 프로그램의 지시문과 예시를 그대로 읽을 수 있고, JSON으로 저장한 뒤 변경분을 diff로 검토할 수 있다. 모델을 개선한다는 작업이 블랙박스로 남지 않고, 사람이 코드 리뷰하듯 검토 가능한 산출물로 떨어진다는 뜻이다.
에이전트가 곧 프로세스라는 점
BEAM으로 이식한 의의는 여기서 드러난다. BEAM에서 에이전트는 하나의 프로세스다. 자기 상태를 유지하고 메시지를 받으며, 애플리케이션의 다른 부분과 나란히 슈퍼바이저 아래에서 돌아간다. Imp.call/2는 프로그램을 현재 프로세스 안에서 실행하지만, Imp.start_run/3는 별도의 감독받는 프로세스로 실행한다. 그래서 실행을 지켜보고, 멈추고, 어떤 도구 호출을 허용할지 결정할 수 있다. 도구는 그저 엘릭서 함수이며, Imp.react/3는 답을 낼 수 있을 때까지 도구를 호출하는 에이전트를 만든다. 예제로 제시된 도구는 Req로 웹 페이지를 읽는 함수인데, 이처럼 자신의 코드가 Req를 부른다면 의존성에 {:req, "~> 0.6"}을 추가해야 한다. 옵티마이저는 이런 에이전트에도 작동해서, GEPA는 에이전트의 실행 전체를 되짚어 그것을 조종하는 지시문을 고쳐 쓴다. 점수를 매길 수 있는 텍스트나 JSON이라면 무엇이든 다시 쓰는 'Optimize Anything'으로 도구 설명 같은 것도 개선 대상이 된다.
도입 전 따져 볼 조건과 한계
실제로 붙여 보려면 환경 요건을 먼저 확인해야 한다. Imp는 엘릭서 1.19 이상과 C·C++ 컴파일러를 요구하는데, jaxon과 erlexec 두 의존성의 네이티브 코드 때문이다. 첫 컴파일 때는 erlexec 빌드가 rebar3 플러그인을 가져오므로 네트워크 접근이 필요하다. 모델 연결은 ReqLLM을 통하므로 ReqLLM이 지원하는 공급자라면 그대로 쓸 수 있다. 다만 성숙도는 냉정하게 볼 필요가 있다. Imp 0.5는 Hex에 처음 올라온 실험적 릴리스로, API가 아직 바뀔 수 있고 옵티마이저들은 대규모 벤치마크 검증이 더 필요한 단계다. 개발사도 버그 리포트와 풀 리퀘스트를 환영한다고 밝힌 상태다.
정리하면 Imp는 파이썬에 사실상 종속돼 있던 DSPy식 '측정 가능한 LLM 프로그래밍'을 엘릭서/OTP 생태계로 끌어온 시도다. 타입 있는 호출 하나부터 오래 돌아가는 다수의 감독형 에이전트까지 같은 방식으로 짜고, 각 부분을 측정으로 개선한다는 그림은 분명히 매력적이다. 다만 프로덕션 투입은 실험 단계라는 전제 아래 소규모로 검증하며 접근하는 편이 안전하다. 이미 엘릭서로 서비스를 운영 중이고 LLM 파이프라인의 신뢰성과 동시성을 OTP 위에서 확보하고 싶은 팀이라면, 지금 시점에서 지켜보고 시험해 볼 가치가 있는 후보다.