LLM-First 또는 Code-First? 생산 AI에서 지능이 속하는 곳

모델이 처리해야 할 것, 코드가 처리해야 할 것, 그리고 두 가지를 어떻게 연결할지 결정하는 방법.

몇 년 전만 해도 AI 애플리케이션의 아키텍처는 다음과 같았습니다: 대형 언어 모델에 프롬프트를 보내고 → 응답을 받아서 → 사용자에게 표시한다. 하지만 요즘은 더 이상 전체 이야기가 아닙니다. 모델은 이제 의도를 해석하고, 정보를 검색하고, 도구를 선택하고, API를 호출하고, 계획을 세우며, 다단계 워크플로를 실행하도록 요구됩니다.

그 변화로 분야가 두 갈래로 나뉘었습니다 – LLM-First 또는 Code-First

LLM-First 아키텍처에서는 모델이 중심에 위치하며 다음에 일어날 일을 결정합니다. 모델은 요청을 읽고, 도구를 선택하고, 작업 순서를 정하며, 중간 결과를 확인하고, 필요할 때 경로를 바꿉니다.

Code-First 아키텍처에서는 소프트웨어/코드가 순서 지정, 비즈니스 규칙, 검증, 권한 및 실행을 담당합니다. 여기서 LLM은 언어 이해나 생성이 필요할 때 코드가 호출하는 전문가와 같습니다.

사람들은 어느 쪽이 더 좋은지 논쟁하기를 좋아합니다. 저는 그 논쟁이 잘못됐다고 생각합니다. 더 중요한 질문은 각 종류의 지능이 어디에 속하는가입니다. 제가 본 가장 강력한 생산 시스템은 거의 순수하게 하나만을 따르지 않습니다. 이들은 확률적 추론과 결정론적 제어를 혼합하며, 이를 의도적으로 수행합니다.

LLM-First가 매력적인 이유

전통적인 소프트웨어는 요구사항을 명확히 정의할 수 있을 때 훌륭히 작동합니다. 예를 들어, 사용자가 제품을 선택하고, 금액을 입력하고, 결제를 제출합니다. 허용된 상태, 검증 규칙, 오류 조건 및 거래 순서를 코드로 정의합니다. 끝.

자연어는 그렇게 협조하지 않습니다. 사용자가 다음과 같이 입력한다고 상상해 보세요: \”비정상적으로 보이는 거래를 찾아서, 무슨 일이 있었는지 설명하고, 먼저 조사해야 할 사항을 알려줘.\”

그 요청에 대해 고정된 경로는 없습니다. 여기서 시스템은 “비정상”이 무엇을 의미하는지 결정하고, 어떤 데이터가 중요한지 파악하고, 여러 도구를 호출할 수도 있으며, 응답을 평가하고, 사용자가 활용할 수 있는 설명을 작성해야 합니다. 엔지니어 팀이나 코드가 사전에 모든 표현과 요청 조합을 예측할 수는 없습니다.

LLM이 인간 언어와 결정론적 서비스 사이의 유연한 추론 계층으로서 중요한 역할을 수행하는 곳입니다. 또한 에이전트가 큰 주목을 받는 이유이기도 합니다.Google Cloud’s 에이전트형 AI 아키텍처 가이드는 AI 모델이 추론 엔진 역할을 하는 애플리케이션으로 정의하며, 도구를 통해 외부 시스템 및 데이터에 접근할 수 있게 합니다.

Anthropic’s 효과적인 AI 에이전트 구축 가이드제가 계속 강조하는 구분을 제시합니다. 여기서워크플로, 모델과 도구는 코드가 정의한 경로를 따릅니다.에이전트, LLM은 자체 프로세스를 주도하고 도구 사용 방식을 결정합니다. 동일한 가이드는 문제를 해결하는 가장 간단한 아키텍처부터 시작하고, 반사적으로 에이전트 복잡성을 추가하지 말 것을 권장합니다. 저는 그 조언을 두 번 강조하고 싶습니다.

“모델에게 결정하게 하라”의 한계

모델은 일어날 일에 대해 추론할 수 있습니다. 추론은 규칙을 집행하는 것과 동일하지 않습니다.

예를 들어 금융 워크플로를 생각해 보세요. LLM은 “지난 달에 보낸 금액과 동일한 금액을 같은 공급업체에 보내라”와 같은 문장을 이해하는 데 뛰어날 수 있습니다. 하지만 전송이 승인되었는지 판단하고, 규제 한도를 계산하고, 계정 소유권을 확인하고, 보안 정책을 무시하며, 거래를 실행까지 해야 할까요?

아마도 아닙니다. 이러한 작업은 결정론적이며, 테스트 가능하고, 감사 가능하며, 실행 가능하기 때문에 전통적인 소프트웨어가 잘 하는 분야입니다. 모델이 도구에 접근하게 되면서 위험이 커집니다.OWASP’s 생성 AI 보안 가이드는 표시합니다과도한 자율성을 중요한 위험으로 표시합니다: LLM 기반 시스템에 작업에 필요한 것보다 더 많은 기능, 권한 또는 자율성을 부여하는 경우. 모델이 텍스트를 생성할 때는 이상하거나 조작된 출력이 하나의 문제일 뿐입니다. 모델이 실제 세계에서 행동할 수 있게 되면 훨씬 더 큰 문제입니다.

이것이 모델이 절대 행동하지 말아야 한다는 뜻은 아닙니다. 모델의 자율성은 결정론적 권한에 의해 제한되어야 함을 의미합니다.

Code-First는 여전히 중요합니다

AI가 급속히 발전함에 따라 기존 엔지니어링이 시대에 뒤떨어졌다고 느끼기 쉽습니다. 저는 그와 반대로 주장합니다. AI는 좋은 결정론적 시스템을 더 중요하게 만들며, 덜 중요하게 만들지는 않습니다.

작업이 정확한 재현성을 요구할 때 코드는 여전히 올바른 선택입니다. 인증이 가장 간단한 예입니다. 모델이 누군가가 관리자 권한을 가지고 있는지 “추론”해서는 안 됩니다. 애플리케이션은 권한 있는 신원 및 접근 관리 시스템에 문의해야 합니다. 금전 계산, 권한 확인, 데이터 검증, 규제 제약, 거래 한도, 스키마 검증 및 모든 비가역적인 작업도 마찬가지입니다. 이러한 경우 명시적인 계약이 필요하며, 추측에 의존해서는 안 됩니다.

이는 보다 넓은 거버넌스 사고와 일치합니다. NIST AI Risk Management Framework는 조직이 설계, 개발, 배포 및 사용 전반에 걸쳐 AI 위험을 관리하도록 요구합니다. 그 부속인 Generative AI Profile은 위험 수준에 따라 생성 시스템에 추가적인 감독, 문서화, 검토 및 제어가 필요할 수 있다고 덧붙입니다.

따라서 저는 모든 설계 결정을 두 가지 질문으로 나누는 것이 도움이 된다고 생각합니다:

무엇이 일어나야 합니까?

그리고

무엇이 허용될 수 있습니까?

LLM은 첫 번째 질문에 종종 도움이 될 수 있습니다. 결정론적 시스템은 보통 두 번째 질문을 담당해야 합니다.

하이브리드 패턴: 확률적으로 추론하고, 결정론적으로 실행하기

대부분의 기업 애플리케이션에 대해 실용적인 답은 하이브리드입니다. LLM은 해석 및 추론 계층으로 작동하고, 결정론적 서비스는 실행 및 적용 계층으로 작동합니다.

예를 들어 보겠습니다. AI 어시스턴트가 개발자들이 임시 API 테스트 환경을 구축하도록 돕고, 개발자가 다음과 같이 입력합니다: “고객 온보딩 워크플로우용 샌드박스를 만들어 주세요.”

LLM은 이를 해석하여 어떤 워크플로우가 의도된 것인지 파악하고, 문서를 읽어 관련 가능성이 높은 API를 제안할 수 있습니다. 그러나 실제 환경을 생성하는 것은 자유 형식의 생성 텍스트에 의존해서는 안 됩니다. 코드는 요청된 API가 존재하는지 확인하고, 계약을 검증하며, 권한을 검사하고, 자원 제한을 적용하며, 승인된 구성을 생성하고, 배포를 실행할 수 있습니다.

대략적인 구분은 다음과 같습니다:

• LLM: 이해, 추론, 분류, 제안, 요약.
• 코드: 검증, 권한 부여, 계산, 영구 저장, 적용, 실행.

각각의 영역은 자신이 가장 잘하는 작업을 수행하며, 서로의 강점을 가장하는 일은 요구되지 않습니다.

에이전트가 강력해질수록 경계가 더욱 중요해집니다

이 구분은 어시스턴트에서 에이전트로 전환할수록 더욱 중요해집니다. 잘못된 답변을 제공하는 어시스턴트는 누군가에게 불편을 초래하지만, 프로덕션에 쓰기 권한을 가진 에이전트는 훨씬 더 큰 혼란을 야기할 수 있습니다.

해결책은 반드시 자율성을 없애는 것이 아니라, 명시적인 제어 지점을 유지하면서 자율성을 점진적으로 추가하는 것입니다. Google의 다중 에이전트 시스템에 대한 가이드비즈니스 핵심 시나리오에 대해 동적 AI 행동을 결정론적 보안 제어, 가시성, 명확히 정의된 자율성 및 인간 감독과 결합할 것을 권장합니다.

인간 승인은 비공식적인 안전망이 아니라 워크플로우 자체에 내장될 수도 있습니다. Microsoft’s agent framework documentation는 예를 들어, 요청된 작업이 사람에 의해 명시적으로 승인될 때까지 일시 중지되는 도구 호출을 지원합니다.

원칙은 간단합니다: 행동의 결과가 클수록 그 주변의 결정론적 제어가 더 강력해야 합니다.

LLM에 작업을 맡기기 전에 물어볼 다섯 가지 질문

구성 요소를 LLM 우선으로 할지 코드 우선으로 할지 결정할 때, 저는 다음 질문들을 검토합니다:

1. 해당 작업에 객관적으로 올바른 답이 하나만 있습니까? 그렇다면 결정론적 코드를 선호하십시오. 세금 계산, 권한 부여 및 스키마 검증은 모델이 오늘 다르게 해석한다는 이유만으로 변경되어서는 안 됩니다.
2. 모호한 언어나 비구조화된 정보를 포함하고 있습니까? 그렇다면 LLM이 실질적인 가치를 제공할 수 있습니다.
3. 모델이 틀렸을 경우 어떤 일이 발생합니까? 회의 요약을 위한 적절한 아키텍처는 결제 시작을 위한 적절한 아키텍처와 크게 다릅니다.
4. 출력을 독립적으로 검증할 수 있습니까? 결정론적 규칙이 실행 전에 결과 행동을 확인할 수 있다면 LLM이 생성한 계획은 훨씬 안전해집니다.
5. 이 작업에 정말 에이전트가 필요합니까? 이미 단계가 명확하다면, 몇 번의 특정 LLM 호출을 포함한 일반 워크플로우가 보통 더 간단하고, 비용도 적게 들며, 테스트와 운영이 용이합니다.

마지막 질문은 특별히 주의할 가치가 있습니다. 에이전트는 모든 단계를 예측할 수 없는 상황을 처리할 수 있기 때문에 강력합니다. 하지만 당신이 할 수 있다면, 단계를 예측할 수 있다면, 이를 개방형 추론 문제로 전환하는 것은 종종 지능을 추가하지 않고 변동성만 늘립니다.

신뢰성은 프롬프트가 아니라 아키텍처적 속성입니다

많은 팀이 신뢰성을 개선하려고 프롬프트 엔지니어링에 거의 전적으로 의존하면서 시작합니다. 프롬프트는 중요하지만, 전체 부담을 짊어질 수는 없습니다.

프로덕션 시스템은 모델 출력이 때때로 불완전하거나, 형식이 잘못되었거나, 예상치 못했거나, 단순히 잘못될 수 있다는 것을 가정해야 합니다. OWASP Top 10 for LLM applications은 프롬프트 인젝션 및 부적절한 출력 처리와 같은 위험을 나열하며, 이는 핵심 습관을 강화합니다: 모델 출력을 자동으로 실행되는 명령이 아니라 하위 시스템에 대한 신뢰할 수 없는 입력으로 취급하십시오.

그것은 당신이 묻는 질문을 바꿉니다. “모델이 규칙을 항상 따르게 하는 프롬프트를 어떻게 작성할까?” 대신에 “모델이 실수를 하더라도 규칙이 깨지지 않도록 시스템을 어떻게 설계할까?” 라고 물어보세요.

이는 소프트웨어 아키텍처 문제이며, 프롬프트 문제는 아닙니다. 프롬프트는 에이전트에게 허가되지 않은 행동을 하지 말라고 지시할 수 있습니다. 실제로는 권한 부여 서비스가 이를 차단할 수 있습니다. 이 두 제어는 동등하지 않습니다.

논쟁을 넘어: Intent-First 시스템

이 모든 것을 생각해보면, 나는 LLM-first와 code-first 논쟁이 세 번째 아이디어, 즉 intent-first 아키텍처를 가리킨다고 믿게 되었습니다.

Intent-first 시스템에서는 애플리케이션이 사용자가 달성하려는 목표를 이해하는 것부터 시작합니다. 사람들은 원하는 바를 정확히 표현하지 못하는 경우가 많기 때문에, 이 단계에서 LLM이 가장 가치 있습니다. 그 다음 시스템은 그 모호함을 점진적으로 구조화된 결정론적 작업으로 변환합니다.

“고객의 결제 문제를 해결해 주세요”와 같은 요청은 파이프라인으로 전환될 수 있습니다: 의도 이해, 거래 조회, 실패 원인 식별, 해결책 제안, 승인 요청, 승인된 작업 실행.

그 단계들 중 일부는 언어 모델의 추론을 활용하면 좋습니다. 다른 단계는 고정된 서비스여야 합니다. 아키텍처는 AI가 “이긴다” 혹은 코드가 “이긴다”에 의해 정의되는 것이 아니라, 불확실성이 허용되는 위치에 의해 정의됩니다.

핵심 요약

모델이 개선됨에 따라 스택의 더 큰 부분을 모델에 맡기고 싶어질 것입니다. 때때로 그것이 올바른 선택이 될 수도 있습니다. 다른 시스템에서는 가장 정교한 설계가 모델에게 덜 권한을 부여하는 설계일 것입니다.

결국 프로덕션 AI 엔지니어링은 인텔리전스를 올바른 경계에 배치하는 것입니다. 해석, 추론, 종합 및 적응이 가치를 창출하는 경우에 언어 모델을 사용하고, 일관성, 권한 부여, 정밀성 및 강제성이 중요한 경우에 결정론적 소프트웨어를 사용하십시오. 그런 다음 두 요소를 좁고 관찰 가능하며 충분히 테스트된 인터페이스로 연결합니다.

기업 AI의 미래는 순수하게 LLM-first도, 순수하게 code-first도 아닐 가능성이 높습니다. 불확실성이 인텔리전스를 요구할 때는 LLM을, 확실성이 제어를 요구할 때는 코드를 사용하는 것이 될 것입니다.

그 구분은 어떤 모델을 선택하느냐보다 훨씬 더 중요할 수 있습니다.