쉬운 설명
사람들이 풀스택이라고 말할 때는, 사람이 보는 화면부터 그 아래의 서버와 저장소까지 제품에 필요한 모든 층을 뜻합니다. 풀스택 AI는 같은 생각을 모델을 중심으로 만든 제품에 적용한 것입니다. 모델은 그저 한 층일 뿐입니다. 사람이 실제로 쓸 수 있는 무언가를 내놓으려면 그 주위의 층들도 함께 있어야 합니다.
실무에서 쓰는 식으로 나열해 보겠습니다. 추론이나 생성을 맡는 모델이 있고, 흔히 거대 언어 모델(LLM)이 그 자리에 들어갑니다. 모델에 들어가는 데이터가 있는데, 모델 뒤에 깔린 학습 데이터와 요청 시점에 읽어 오는 실시간 데이터 둘 다입니다. 출력이 쓸 만한지 재는 평가 층이 있습니다. 시험해 보지 않은 것은 개선할 수 없기 때문입니다. 사람이 직접 만지는 애플리케이션과 사용자 경험이 있습니다. 이를 돌리는 인프라가 있는데, 클라우드 컴퓨팅 머신과 서버리스 함수, 조각들을 잇는 API, 그리고 무엇이 무엇을 어떤 순서로 부를지 정하는 오케스트레이션이 여기 들어갑니다. 그리고 서비스가 살아 움직인 뒤 나쁜 출력과 악용, 장애를 지켜보는 안전과 모니터링 층이 있습니다. 비용과 지연 시간은 이 모든 층을 가로질러 따라붙습니다. 너무 느리거나 너무 비싼 AI 기능은 실제 사용자를 만나면 버티지 못하기 때문입니다.
이 표현이 생긴 이유는, 초기에 많은 팀이 AI를 그저 모델로만 다뤘기 때문입니다. 센 모델을 하나 골라 화면에 잇고는 어려운 부분은 끝났다고 여기곤 했죠. 실제로는 모델이 가장 갈아 끼우기 쉬운 층입니다. 데이터 파이프라인, 평가, 모니터링, 비용 작업에 노력의 대부분이 들어가고, 바로 그것이 데모와 사람들이 믿고 쓰는 제품을 가릅니다.
비유로 보면
식당을 연다고 생각해 보세요. 레시피는 모델이고, 모두가 입에 올리는 바로 그것입니다. 하지만 훌륭한 레시피 하나로는 아무도 먹일 수 없습니다. 재료가 배달되고 보관돼야 하는데 그게 데이터입니다. 음식이 주방을 나가기 전에 맛을 보는 사람이 있어야 하는데 그게 평가입니다. 손님이 읽을 수 있는 홀과 메뉴가 있어야 하는데 그게 애플리케이션과 경험입니다. 전기와 물이 들어오는 주방이 있어야 하는데 그게 인프라입니다. 그리고 위생 점검과 저녁 피크 때 라인을 지켜보는 사람이 있어야 하는데 그게 안전과 모니터링입니다. 주방도, 공급망도, 품질 점검도 없는 유명 셰프는 식당을 운영하지 못합니다. 풀스택 AI는 레시피만이 아니라 식당 전체입니다.
어디에서 만나나
이 표현은 어떤 팀이 AI 제품을 기획하면서 모델 이상을 책임져야 할 때 등장합니다. 회사 자체 문서를 답변에 끌어오는 검색 구성, 흔히 RAG라 부르는 방식은 임베딩 단계와 벡터 데이터베이스, 그리고 평가 장치가 필요한데 모두 모델 위의 층입니다. 행동을 취하는 에이전트는 추론 위에 오케스트레이션과 도구 배선, 모니터링이 더 필요합니다. 그중 무엇이든 운영 환경에서 돌리려면 클라우드나 서버리스 인프라, API 층, 데브옵스 관행, 그리고 비용과 지연 시간 예산이 따라옵니다. 클라우드 벤더들은 이 층들을 묶어 함께 파는 통합 세트를 가리키는 데 풀스택 AI를 쓰는데, 배선 수고를 줄여 줄 수 있지만 늘 따라오는 종속 문제도 함께 키웁니다. 어느 쪽이든 이 용어의 쓸모는 모델 너머의 일, 팀이 가장 자주 과소평가하는 그 부분에 이름을 붙여 준다는 데 있습니다.
작은 예시
2026년 6월 29일, 구글은 자사 블로그에 일반 독자를 위한 입문 설명글 'Ask an AI expert: What exactly is the full stack'를 실었고, 구글 클라우드의 리처드 세로터가 그 개념을 풀어 줍니다. 그는 풀스택 AI를 전통적인 앱 개발의 처음부터 끝까지라는 원칙을 그대로 AI에 적용한 것이라고 설명하며, 층을 컴퓨트 인프라, AI 모델, 오케스트레이션 플랫폼, 사용자 인터페이스로 꼽습니다. 예시는 구글 자신의 스택입니다. 아래에 TPU, 가운데 제미나이 모델, 오케스트레이션 플랫폼, 그 위에 지도와 지메일 같은 제품이죠. 벤더 관점을 걷어 내고 보면 쓸모 있게 남는 건 그 모양새입니다. AI로 일한다는 것은 모델만 고르는 게 아니라 모든 층을 가로질러 일한다는 뜻이라는 점이죠. 일반 독자용 설명글이 이제 필요해졌다는 사실 자체가, 이 표현이 엔지니어링 팀을 넘어 비전문가도 알아야 할 말로 옮겨 갔다는 신호입니다.
자주 하는 오해
한 줄 정리
풀스택 AI는 모델이 제품 전체가 아니라 한 층일 뿐이라는 점을 일깨워 줍니다. 그 주위에는 데이터, 평가, 애플리케이션과 인터페이스, 인프라와 오케스트레이션, 안전과 모니터링이 자리하고, 비용과 지연 시간이 그 전부를 가로지릅니다. 이를 사 올 제품이 아니라 해야 할 일의 묘사로 받아들이고, 모델 너머의 층들을 일찍부터 계획하세요. 노력과 장애, 비용이 실제로 모이는 곳이 바로 거기이기 때문입니다.
자주 묻는 질문
AI 모델은 한 층, 곧 추론이나 생성을 맡는 부분이며 거대 언어 모델(LLM)이 그 예입니다. 풀스택 AI는 그 모델에 더해, 돌아가는 제품에 필요한 주위의 모든 층까지를 가리킵니다. 모델에 들어가는 데이터, 출력이 쓸 만한지 점검하는 평가 단계, 사람이 쓰는 애플리케이션과 사용자 인터페이스, 조각들을 돌리고 잇는 인프라와 오케스트레이션, 그리고 운영 환경에서 시스템을 지켜보는 안전과 모니터링이 모두 들어가고, 비용과 지연 시간이 그 전부를 가로지릅니다. 간단히 말하면 모델은 사람들이 입에 올리는 것이고, 풀스택은 그 모델을 실제 사용자가 의지할 수 있는 무언가로 바꾸는 데 드는 전부입니다. 모델은 보통 가장 덜 바뀌는 층이고, 만들고 유지하는 일의 대부분은 그 주위 층에서 일어납니다.
아닙니다. 풀스택 AI는 AI 제품에 필요한 층들을 설명하는 방식이지, 정의가 고정된 공식 표준도 아니고 하나로 사 오는 물건도 아닙니다. 정확히 어떤 층이 포함되는지에 대한 공식 목록은 없지만, 대부분의 설명이 데이터, 모델, 평가, 애플리케이션, 인프라, 모니터링에는 의견을 같이합니다. 클라우드 벤더들은 인프라와 모델, 오케스트레이션, 도구가 함께 맞물려 돌도록 설계한 통합 묶음을 풀스택 AI라 부르며 팔기도 하고, 그것이 배선 수고를 줄여 줄 수 있습니다. 하지만 묶음을 사는 것은 스택을 조립하는 한 방법이지 용어의 뜻이 아니며, 편리함과 종속이라는 늘 있는 맞교환을 안고 있습니다. 따로 떨어진 여러 조각을 섞어 풀스택 AI 제품을 통째로 만들 수도 있고, 그렇다고 해서 덜 풀스택인 것도 아닙니다.
모델이 가장 빠른 데모를 내주면서 가장 오래가는 골칫거리는 가장 적게 안기는 층이기 때문입니다. 센 모델을 화면에 잇는 일은 하루 만에 인상적인 무언가를 만들 수 있고, 이는 다른 층들이 여전히 얼마나 많은 일을 요구하는지를 가립니다. 데이터 층은 품질 문제가 시작되는 곳입니다. 모델은 자기가 읽은 것만큼만 좋을 수 있기 때문입니다. 평가 층은 건너뛰기 쉽고 나중에 붙이기는 고통스럽지만, 그것 없이는 어떤 변경이 상황을 낫게 했는지 나쁘게 했는지 알 수 없습니다. 모니터링은 실제 사용자가 들어온 뒤 조용한 장애와 악용을 잡아내는데, 데모는 결코 보지 못하는 종류입니다. 그리고 데모 규모에서는 거의 드러나지 않는 비용과 지연 시간이 실제 물량에서는 기능을 성립 불가능하게 만들 수 있습니다. 모델만 계획한 팀은 출시 뒤에 이 모두를 한꺼번에 만나고, 바로 그때 프로젝트가 멈춥니다. 풀스택을 일찍 계획하면 그 일을 끝에 몰아 쌓는 대신 고르게 펼쳐 둘 수 있습니다.