오늘의 모델보다 오래 지속되는 AI 시스템 설계하기

이 시리즈를 통해 제가 배운 교훈이 하나 있다면 바로 이것입니다:

모델을 중심으로 애플리케이션을 구축하지 마세요. 역량 (Capability)을 중심으로 구축하세요.

이것이 아주 작은 차이처럼 들릴 수도 있습니다.

하지만 그렇지 않습니다.

왜냐하면 모델은 변하기 때문입니다.

끊임없이 말이죠.

몇 달 전만 해도 모두가 GPT-4에 대해 이야기했습니다.

그다음은 Claude.

그다음은 Gemini.

그다음은 DeepSeek.

그다음은 Qwen.

여러분이 이 글을 읽고 있을 때쯤이면, 아마 또 다른 모델이 헤드라인을 장식하고 있을 것입니다.

그런 일이 일어날 때마다 애플리케이션을 새로 작성해야 한다고 상상해 보세요.

그것은 혁신이 아닙니다.

그것은 기술 부채 (Technical debt)입니다.

제가 매우 자주 목격하는 실수 중 하나는 개발자들이 자신의 애플리케이션을 특정 제공업체 (Provider)에 밀접하게 결합 (Tightly coupling)시키는 것입니다.

여러분의 비즈니스 로직은 자신이 GPT-4와 대화하고 있다는 사실을 알고 있습니다.

여러분의 프롬프트 (Prompts)는 GPT-4에 맞춰 구체적으로 작성되어 있습니다.

여러분의 출력 파싱 (Output parsing)은 GPT-4를 가정합니다.

여러분의 에러 핸들링 (Error handling)은 GPT-4를 가정합니다.

이제 회사가 제공업체를 바꾸기로 결정했다고 상상해 보세요.

단순한 설정 변경이어야 했던 작업이 갑자기 몇 주간의 리팩터링 (Refactoring) 작업으로 변합니다.

이것은 피할 수 있는 일입니다.

여러분의 애플리케이션은 누가 요청에 응답했는지 알아서는 안 됩니다.

그저 요청한 역량 (Capability)이 전달되었다는 사실만을 알아야 합니다.

이 문서를 요약해 줘.

이 코드를 생성해 줘.

이 텍스트를 분류해 줘.

이 단락을 번역해 줘.

이것들이 바로 역량 (Capabilities)입니다.

제공업체 (Provider)는 단순히 구현 세부 사항 (Implementation detail)일 뿐입니다.

제가 더 일찍 하지 않아 후회하는 것 중 하나는 프롬프트 (Prompts)의 버전 관리 (Versioning)였습니다.

대부분의 개발자는 그 외의 모든 것의 버전을 관리합니다.

소스 코드 (Source code).

데이터베이스 마이그레이션 (Database migrations).

인프라 (Infrastructure).

설정 (Configuration).

그러다 프롬프트는 결국 다음과 같은 모습이 됩니다:

const prompt = "You are a helpful assistant...";

3개월 후 누군가가 문장 하나를 수정합니다.

응답이 변합니다.

아무도 그 이유를 모릅니다.

익숙한 상황인가요?

프롬프트는 코드와 동일한 엔지니어링 규율 (Engineering discipline)을 갖춰야 합니다.

버전 관리를 하세요.

검토하세요.

왜 변경되었는지 문서화하세요.

필요할 때 롤백 (Roll back)하세요.

프롬프트 엔지니어링 (Prompt engineering)은 마법이 아닙니다.

그것은 소프트웨어 개발 (Software development)입니다.

현재 사용 중인 모델보다 성능이 더 뛰어난 완전히 새로운 추론 모델 (reasoning model)을 발견했다고 상상해 보세요.

그것을 즉시 모든 사용자에게 배포하시겠습니까?

아마 아닐 것입니다.

기능 플래그 (feature flags)를 사용하세요.

사용자의 5%에게만 배포하세요.

지연 시간 (latency)을 모니터링하세요.

비용을 모니터링하세요.

예상치 못한 출력을 주시하세요.

트래픽을 점진적으로 늘리세요.

이것은 우리가 다른 중요한 기능을 배포할 때 하는 방식과 정확히 일치합니다.

AI도 다르게 취급되어서는 안 됩니다.

모델 제공업체의 리더보드 (leaderboard)는 당신의 벤치마크 (benchmark)가 아닙니다.

당신의 사용자가 벤치마크입니다.

어떤 모델이 모든 공개 순위에서 1위를 차지할 수도 있습니다.

그것이 당신의 애플리케이션에 자동으로 최선의 선택이 된다는 뜻은 아닙니다.

자신만의 평가 데이터셋 (evaluation dataset)을 구축하세요.

여러 모델에 대해 동일한 프롬프트 (prompts)를 실행하세요.

실제로 중요한 것들을 측정하세요:

• 정확도 (Accuracy).
• 응답 시간 (Response time).
• 비용 (Cost).
• 구조화된 출력 품질 (Structured output quality).
• 환각률 (Hallucination rate).
• 사용자 만족도 (User satisfaction).

최고의 모델은 다른 사람의 문제가 아니라, 당신의 문제를 일관되게 해결하는 모델입니다.

AI에도 회귀 테스트 (regression testing)가 필요합니다

전통적인 소프트웨어에는 단위 테스트 (unit tests)가 있습니다.

통합 테스트 (Integration tests).

종단 간 테스트 (End-to-end tests).

AI 애플리케이션에는 이러한 규율의 자체 버전이 필요합니다.

다음 중 무엇이라도 변경할 때마다:

• 프롬프트 (prompt),
• 모델 (model),
• 시스템 지침 (system instruction),
• 또는 라우팅 로직 (routing logic),

평가 스위트 (evaluation suite)를 다시 실행하세요.

응답 품질이 향상되었나요?

비용이 증가했나요?

지연 시간이 두 배로 늘어났나요?

구조화된 출력이 깨졌나요?

테스트 없이는, 사용자가 문제를 발견한 후에야 회귀 (regressions)를 발견하게 될 것입니다.

그리고 그것은 결코 즐거운 대화가 아닙니다.

제공업체가 아닌 인터페이스 (interfaces)를 중심으로 구축하세요

한 가지 설계 원칙이 저의 수많은 골칫거리를 해결해 주었습니다.

제 애플리케이션의 모든 것은 인터페이스 (interface)와 통신합니다.

OpenAI와 직접 통신하지 않습니다.

Claude와 직접 통신하지 않습니다.

Gemini와 직접 통신하지 않습니다.

인터페이스는 다음과 같은 메서드 (methods)를 노출할 수 있습니다:

• generateText()
• summarize()
• classify()
• embed()

이러한 메서드 뒤에 무엇이 있는지는 바뀔 수 있습니다.

애플리케이션은 상관하지 않습니다.

그것이 좋은 아키텍처 (architecture)입니다.

오늘은 구현체가 OpenRouter를 사용할 수 있습니다.

내일은 그렇지 않을 수도 있습니다.

괜찮습니다.

그 외의 다른 것은 변경할 필요가 없기 때문입니다.

최고의 AI 시스템은 적응력이 뛰어납니다

AI의 발전 속도는 우리가 소프트웨어 분야에서 목격했던 그 어떤 것과도 다릅니다.

모델은 몇 달마다 개선됩니다.

가격 정책은 하룻밤 사이에 바뀝니다.

컨텍스트 윈도우 (Context windows)는 확장됩니다.

역량 (Capabilities)은 진화합니다.

오늘의 "최고 모델"을 중심으로 구축하는 것은 2012년의 가장 빠른 브라우저를 기준으로 웹 애플리케이션을 구축하는 것과 같습니다.

당신은 특정 시점만을 위해 최적화하고 있는 것입니다.

훌륭한 아키텍처 (Architecture)는 변화에 최적화합니다.

마치며

이 시리즈를 통해 우리는 SDK, 게이트웨이 (Gateways), 관측성 (Observability), 폴백 (Fallbacks), 재시도 (Retries), 라우팅 (Routing), 비용 최적화 (Cost optimization)에 대해 이야기했습니다.

하지만 이 중 그 어떤 것도 진정한 핵심은 아닙니다.

이것들은 모두 유지보수가 더 쉬운 소프트웨어를 구축할 수 있도록 돕는 도구일 뿐입니다.

그것이 궁극적으로 엔지니어로서 우리의 역할입니다.

최신 모델을 쫓는 것이 아닙니다.

벤치마크 (Benchmark)가 바뀔 때마다 애플리케이션을 다시 작성하는 것도 아닙니다.

그 뒤에 어떤 모델이 위치하든 상관없이 계속 작동하는 시스템을 설계하는 것입니다.

모델은 변할 것이기 때문입니다.

제공업체 (Providers)도 변할 것입니다.

가격도 변할 것입니다.

하지만 훌륭한 소프트웨어 엔지니어링의 기본 원칙은 변하지 않습니다.

만약 제가 이 시리즈를 통해 여러분이 얻어갔으면 하는 것이 하나 있다면, 바로 이것입니다:

단순히 현재의 모델뿐만 아니라, 차세대 모델에서도 살아남을 수 있는 AI 애플리케이션을 구축하십시오.

미래의 당신과 동료들, 그리고 아마도 사용자들도 당신이 그렇게 하길 잘했다고 생각할 것입니다.