한 번의 컴파일로 어디서든 실행하기: 여러 LLM 제공업체 지원하기

AI 개발에서 가장 큰 과제 중 하나는 프롬프트 (Prompt)를 작성하는 것이 아닙니다.

여러 제공업체 (Provider)에 걸쳐 프롬프트를 유지 관리하는 것입니다.

오늘 당신은 다음을 사용할 수도 있습니다:

• OpenAI
• Anthropic Claude
• Google Gemini
• Ollama
• Groq
• Mistral

내일은요?

아마 완전히 다른 모델을 사용할지도 모릅니다.

문제는 프롬프트 자체가 아닙니다.

모든 제공업체가 약간씩 다른 형식을 요구한다는 점입니다.

오늘날의 현실

간단한 어시스턴트가 있다고 가정해 봅시다.

OpenAI의 경우, 요청은 다음과 같이 보입니다.

messages: [

  {
...

직관적으로 보입니다.

이제 다른 제공업체로 전환해 보세요.

갑자기 메시지 형식을 다시 작성해야 합니다.

프로젝트의 모든 프롬프트에 대해 이 작업을 반복한다면...

...제공업체를 전환하는 비용이 매우 커지게 됩니다.

벤더 종속 (Vendor Lock-In)

대부분의 AI 애플리케이션은 의도적으로 한 제공업체에 종속되지 않습니다.

이는 점진적으로 발생합니다.

처음에는 OpenAI로 시작합니다.

몇 달 후 회사가 Claude를 비교하고 싶어 할 수 있습니다.

또는 Gemini를 원할 수도 있습니다.

아니면 Ollama를 사용하여 로컬에서 실행하고 싶을 수도 있습니다.

이제 모든 프롬프트를 수정해야 합니다.

지침 (Instructions)이 바뀌어서가 아니라...

...페이로드 (Payload)가 바뀌었기 때문입니다.

프롬프트는 문제가 아닙니다

실제 프롬프트는 거의 바뀌지 않습니다.

이것은 바뀌지 않습니다.

You are an expert software engineer.

Review this code.
...

오직 전송 계층 (Transport layer)만 바뀝니다.

이는 즉...

당신의 프롬프트 정의는 OpenAI에 대해 아무것도 알 필요가 없어야 한다는 뜻입니다.

의도와 구현의 분리

제공업체의 페이로드를 정의하는 대신...

당신의 의도 (Intent)를 정의하세요.

const reviewPrompt = pf.define({

    input: z.object({
...

무언가 눈치채셨나요?

OpenAI도 없습니다.

Claude도 없습니다.

Gemini도 없습니다.

오직 프롬프트만 있을 뿐입니다.

컴파일하기

이제 필요한 제공업체에 맞춰 컴파일하세요.

const compiled = reviewPrompt.compile({

    code
...

그다음부터는...

compiled.toOpenAI()

compiled.toAnthropic()
...

하나의 프롬프트.

여러 제공업체.

컴파일이 중요한 이유

TypeScript를 생각해 보세요.

당신은 JavaScript를 직접 작성하지 않습니다.

TypeScript를 작성합니다.

그런 다음 컴파일합니다.

PromptForge도 동일한 철학을 따릅니다.

프롬프트 정의 (Prompt Definition)

↓
...

프롬프트는 일관되게 유지됩니다.

오직 출력값(output)만 변할 뿐입니다.

더 쉬운 제공업체 테스트 (Easier Provider Testing)

GPT-4o와 Claude를 비교한다고 상상해 보세요.

PromptForge가 없다면

프롬프트 A (Prompt A)

↓
...

PromptForge가 있다면

프롬프트 (Prompt)

↓
...

정확히 동일한 프롬프트입니다.

공정한 비교가 가능합니다.

더 깔끔한 아키텍처 (Cleaner Architecture)

중복된 프롬프트를 포함하는

type openai.ts

claude.ts
...

대신에,

당신의 프로젝트는 다음과 같이 변합니다.

prompts/

review.ts
...

유지보수가 훨씬 쉬워집니다.

미래 대비 (Future-Proof)

AI 생태계는 매달 변화합니다.

새로운 제공업체(providers)가 등장합니다.

API가 진화합니다.

모델이 개선됩니다.

당신의 프롬프트가 매번 바뀔 필요는 없어야 합니다.

PromptForge는 어댑터(adapters)가 제공업체별 차이점을 처리하는 동안, 프롬프트 정의를 안정적으로 유지해 줍니다.

이것이 중요한 이유 (Why This Matters)

프롬프트 엔지니어링 (Prompt engineering)이 한 회사에 종속되어서는 안 됩니다.

당신의 프롬프트는 당신의 지적 재산입니다.

프롬프트는 오늘 어떤 모델이 인기를 끌든 상관없이 그보다 더 오래 지속되어야 합니다.

그것이 PromptForge가 제공업체 독립성(provider independence)을 중심으로 설계된 이유입니다.

프롬프트를 한 번만 작성하세요.

어디서든 컴파일하세요.

향후 전망 (Looking Ahead)

여러 제공업체를 지원하는 것은 이야기의 일부일 뿐입니다.

다음 과제는 프롬프트를 LLM에 보내기 전에 실제로 올바른지 확인하는 것입니다.

다음 기사에서는 **프롬프트 검증 (Prompt Validation)**을 탐구하고, API 호출 전에 오류를 잡아내는 것이 어떻게 시간과 토큰(tokens)을 모두 절약할 수 있는지 살펴보겠습니다.

설치 (Installation)

npm install @promptforgee/core

리소스 (Resources)

🌐 문서 (Documentation)

https://prompt-forge-docs.vercel.app/

⭐ GitHub

https://github.com/Omnikon-Org/PromptForge

📦 npm

https://www.npmjs.com/package/@promptforgee/core

마치며 (Final Thoughts)

프레임워크는 나타났다 사라집니다.

모델도 나타났다 사라집니다.

제공업체도 나타났다 사라집니다.

하지만 당신의 프롬프트는 그래서는 안 됩니다.

PromptForge는 프롬프트 설계와 제공업체 구현 (provider implementation)을 분리하여, 생태계가 변할 때마다 페이로드 (payload)를 다시 작성하는 대신 AI 애플리케이션을 구축하는 데 집중할 수 있도록 합니다.