현대 AI 앱 스택, 처음부터 끝까지

사람들은 AI 애플리케이션을 떠올릴 때 모델을 떠올립니다. 하지만 모델은 여러 계층 중 하나일 뿐이며, AI 기능이 실제로 작동할지를 결정하는 것 대부분은 그 주변의 화려하지 않은 계층들에 있습니다. 전체 스택을 이해하면 — 각 부분이 무엇을 하고 왜 존재하는지 — "AI는 예측 불가능한 마법"이라는 인식이 추론하고 디버깅하고 개선할 수 있는 구성 요소들의 집합으로 바뀝니다. 이 글은 사용자의 입력에서 모델로, 그리고 다시 돌아오는 처음부터 끝까지의 지도이며, 각 계층이 어디서 제 몫을 하는지에 대한 솔직한 메모를 곁들였습니다.

모델 계층: 능력이지 애플리케이션이 아니다

중심에는 모델 자체가 자리하며, 제공자가 호스팅하거나 여러분이 직접 돌립니다. 이것은 날것의 능력입니다. 텍스트가 들어가고, 텍스트가 나오며, 그 사이에 약간의 추론이 있습니다. 필수적이면서도 여러분이 가장 통제력을 적게 갖는 계층인데, 그것을 만드는 게 아니라 대체로 선택지 중에서 고르는 것이기 때문입니다. 실수는 이 선택을 프로젝트 전체로 취급하는 것입니다. 잘 만든 애플리케이션 속의 평범한 모델보다, 형편없는 애플리케이션에 연결된 유능한 모델이 더 못한 성능을 냅니다.

실무적으로 이 계층은 트레이드오프가 따르는 결정입니다. 호스팅 대 직접 운영, 더 큼 대 더 작음, 범용 대 특화. 각각은 비용, 지연 시간, 프라이버시, 능력에 영향을 미칩니다. 알맞은 판단은 여러분의 작업에 달려 있으며 — 중요하게도 — 그것은 교체 가능합니다. 선택지가 개선되거나 필요가 바뀔 때 나중에 모델을 바꿀 수 있도록 설계하는 것은 일찍 내릴 수 있는 가장 지렛대 효과가 큰 아키텍처 결정 중 하나입니다.

오케스트레이션 계층: 호출을 행동으로 바꾸기

단일 모델 호출은 좀처럼 애플리케이션이 아닙니다. 실제 기능은 호출을 연결하고, 결과에 따라 분기하고, 실패 시 재시도하고, 도구를 부르고, 여러 출처에서 프롬프트를 조립합니다. 오케스트레이션 계층은 이 모든 것을 조율하는 코드입니다 — 무엇을, 어떤 순서로 보낼지, 각 응답으로 무엇을 할지 결정합니다. 여러분 애플리케이션의 실제 로직이 사는 곳이자, 대부분의 엔지니어링 노력이 가는 곳입니다.

오케스트레이션은 복잡성이 조용히 쌓이는 곳이기도 합니다. 추가되는 단계마다 — 검색 호출, 도구 호출, 첫 결과를 점검하는 두 번째 모델 패스 — 지연 시간, 비용, 그리고 새로운 실패 방식이 더해집니다. 여기서의 규율은 단계가 제자리를 정당화할 때만 추가하는 것이며, 무언가 잘못됐을 때 무슨 일이 있었는지 여전히 추론할 수 있을 만큼 흐름을 단순하게 유지하는 것입니다. 추적할 수 없는 파이프라인은 고칠 수 없는 파이프라인입니다.

컨텍스트 계층: 프롬프트, 검색, 메모리

모델은 눈앞에 있는 것만 압니다. 컨텍스트 계층은 모델이 보는 것을 조립하는 모든 것입니다. 작업을 틀 짓는 프롬프트, 답을 여러분의 데이터에 근거 짓는 검색된 문서, 그리고 대화의 이전 차례에 대한 기억. 이는 흔히 품질을 결정하는 계층인데, 같은 모델이라도 어떤 컨텍스트를 받느냐에 따라 천차만별의 결과를 내놓기 때문입니다.

검색은 여기에 속합니다. 애플리케이션이 여러분 자신의 문서로 답할 때, 이 계층은 질의를 임베딩하고, 관련 구절을 찾아, 프롬프트에 엮어 넣습니다. 메모리도 여기에 속합니다 — 대화 앞부분에서 이어갈 가치가 있는 것과 버릴 것을 결정합니다. 잘 해내면 이 계층은 범용 모델이 여러분의 구체적인 세계를 아는 것처럼 느끼게 만듭니다. 못 해내면 무관하거나 모순되는 자료를 모델에 먹이고, 여러분은 그 결과를 모델 탓으로 돌립니다.

도구 계층: 모델이 행동하게 하기

텍스트만 만들어낼 수 있는 모델은 제한적입니다. 유용한 많은 애플리케이션은 모델이 무언가를 하기를 요구합니다 — 실시간 데이터 조회, 계산 실행, 데이터베이스 질의, 외부 서비스 호출. 도구 계층은 모델이 쓸 수 있는 행동을 정의하고, 모델이 요청할 때 그것을 안전하게 실행합니다. 모델은 무엇을 할지 결정하고, 여러분의 코드는 그것이 실제로 일어날지, 어떻게 일어날지 결정합니다.

핵심 단어는 안전하게입니다. 도구는 AI 애플리케이션이 현실 세계에 닿는 곳이며, 이는 실수가 나쁜 문장을 넘어선 결과를 낳는 곳이라는 뜻입니다. 이 계층에는 가드레일이 필요합니다. 모델이 요청하는 것을 검증하고, 닿을 수 있는 범위를 제한하며, 되돌릴 수 없는 행동은 확인하는 것. 모델의 도구 요청을 신뢰할 수 없는 입력으로 취급하세요. 사실상 그렇기 때문입니다 — 모델은 행동을 제안하는 것이지 승인하는 게 아니며, 권한은 여러분의 코드가 쥐고 있습니다.

평가 계층: 작동하는지 아는 법

전통적인 소프트웨어는 작동하거나 오류를 던집니다. AI 애플리케이션은 더 미묘하게 실패합니다. 그럴듯하지만 틀린 출력을 내놓고, 프롬프트를 바꾸거나 모델을 교체할 때 조용히 저하됩니다. 평가 계층은 시스템이 정말로 제 일을 하는지 아는 방법입니다 — 대표적인 테스트 케이스 모음과, 그에 견주어 품질을 측정하는 방법으로, 몇 개 출력을 눈으로 한 번 훑고 마는 게 아니라 지속적으로 돌립니다.

이 계층은 팀이 가장 자주 건너뛰고, 건너뛴 것을 가장 자주 후회하는 계층입니다. 이것이 없으면 모든 변경이 도박입니다. 한 사례를 개선하면서 다른 셋을 조용히 망가뜨리고도 알아챌 방법이 없습니다. 변변찮은 평가 세트라도 있으면, 모델을 바꾸거나 프롬프트를 다듬거나 검색 단계를 추가하고서 도움이 됐는지 해가 됐는지 측정할 수 있습니다. 평가는 AI 개발을 어림짐작에서 엔지니어링으로 바꾸는 것이며, 필요하다고 느끼기 전에 만들어둘 가치가 있습니다.

관측성과 비용 계층: 환히 드러내고 운영하기

AI 기능이 일단 라이브가 되면, 그것이 무엇을 하는지 볼 수 있어야 합니다. 관측성 계층은 프롬프트, 검색된 컨텍스트, 모델 응답, 도구 호출, 지연 시간, 비용을 기록합니다. 사용자가 나쁜 답을 신고할 때, 추측하는 대신 실제로 무슨 일이 있었는지 재구성하는 방법이 바로 이것입니다. AI 시스템은 비결정적이며, 이는 좋은 로깅이 보통 소프트웨어보다 덜이 아니라 더 중요하게 만듭니다.

비용이 관측성과 나란히 사는 이유는, AI 애플리케이션에서 비용이 고정된 항목이 아니라 런타임 속성이기 때문입니다. 모든 호출이 토큰을 소모하고, 모든 검색이 컨텍스트를 더하며, 추가되는 모든 오케스트레이션 단계가 사용량을 배가합니다. 가시성이 없으면 비용은 청구서나 속도 제한이 대화를 강요할 때까지 알아채지 못한 채 위로 흘러갑니다. 비용을 일급 신호로 지켜보는 것 — 요청별, 기능별, 시간 경과에 따라 — 이 경제성이 조용히 제품을 망가뜨리지 않게 합니다.

계층들이 어떻게 맞물리는가

단일 요청을 따라가 보면 스택이 구체적으로 드러납니다. 사용자의 입력이 도착하고, 오케스트레이션 계층이 넘겨받고, 컨텍스트 계층이 검색된 문서와 함께 프롬프트를 조립하고, 모델이 응답을 만들고, 도구 계층이 모델이 요청한 행동을 실행하고, 결과가 돌아옵니다 — 그동안 관측성 계층이 그 여정 전체를 기록하고, 평가 계층은 오프라인에서 이런 여정들이 여전히 잘 흘러가는지 계속 점검합니다. 각 계층은 교체 가능하며, 어느 하나의 약점이 전체의 품질에 상한을 씌웁니다.

전략적 통찰은 이 계층들이 독립적으로 실패하고 개선된다는 것입니다. 실망스러운 애플리케이션은 보통 근본적으로 약한 설계가 아니라 약한 계층 하나를 갖고 있습니다. 어느 계층인지 — 나쁜 검색, 엉성한 오케스트레이션, 안전하지 않은 도구, 없는 평가 — 를 진단하는 것이, AI 기능을 꾸준히 개선하는 팀과 다음 모델이 모든 걸 고쳐주길 바라며 계속 모델만 갈아치우는 팀을 가릅니다.

정리

현대 AI 애플리케이션은 모델이 아니라 스택입니다. 모델은 능력을 공급하지만, 오케스트레이션이 그것을 조율하고, 컨텍스트 계층이 그것을 먹이고, 도구 계층이 그것을 행동하게 하고, 평가가 작동하는지 알려주고, 관측성이 그것을 환한 데서 운영하게 합니다. 대부분의 품질과 대부분의 비용은 모델 자체가 아니라 그 주변 계층들에 삽니다. 그 지도를 염두에 두고 만들면, AI 개발은 마법처럼 느껴지기를 멈추고 본모습대로 느껴지기 시작합니다. 중심에 유난히 예측 불가능한 구성 요소 하나를 둔, 평범한 엔지니어링으로 말이죠.