AI 애플리케이션은 모델이 아니라 시스템으로 설계된다

안녕하세요, Seigniter의 유민수 개발자입니다.

AI 애플리케이션을 설계할 때 가장 많이 나오는 질문은 보통 "어떤 LLM을 쓸 것인가"입니다. 하지만 엔지니어링 관점에서는 더 중요한 질문이 따로 있습니다. "AI가 어떤 데이터를 기억하고, 어떤 상태를 추적하며, 어떤 근거로 답변을 생성하게 할 것인가."

최근 AI 애플리케이션의 구조를 보면 변화가 뚜렷합니다. 초기의 생성형 AI는 사용자의 질문에 답하는 채팅 인터페이스에 가까웠고, 이 단계에서는 LLM의 성능이 제품의 대부분을 결정하는 것처럼 보였습니다. 하지만 실제 기업 환경으로 들어가면 이야기가 달라집니다.

기업용 AI는 "그럴듯한 답변"을 만들어 내는 시스템이 아닙니다. 고객 정보, 계약 정보, 결제 내역, 운영 데이터, 내부 문서, 규정, 이력, 권한 체계와 연결되어야 합니다. AI 애플리케이션도 결국 애플리케이션입니다. 그래서 AI 시스템에는 데이터베이스가 여전히 필요하고, 오히려 더 중요해지고 있습니다.

확률론적 소프트웨어라는 난이도

전통적인 소프트웨어는 대체로 결정론적 소프트웨어(같은 입력에 같은 결과를 기대할 수 있는 구조)였습니다. 사용자가 버튼을 누르면 정해진 비즈니스 로직에 따라 결과가 나옵니다. 은행 잔고, 주문 상태, 결제 내역, 재고 수량 같은 데이터는 반드시 정확해야 합니다. 반면 AI 소프트웨어는 확률론적 소프트웨어(같은 입력에도 맥락·모델·샘플링 조건에 따라 결과가 달라질 수 있는 구조)에 가깝습니다. LLM은 문장을 생성하고 추론하지만 늘 같은 결과를 보장하지는 않습니다.

이 차이가 엔지니어링의 핵심 난이도입니다. AI가 mission-critical(장애나 오류가 사업·고객·법적 리스크로 직결되는 업무)에 들어가려면 "답변을 잘한다"로는 부족합니다. 검색 품질, 데이터 최신성, 권한 제어, 트랜잭션 정합성, 응답 근거, 재현 가능성, 실패 처리까지 설계해야 합니다.

RAG는 검색 기능이 아니라 데이터 품질 시스템이다

여기서 RAG(Retrieval-Augmented Generation, 모델이 답하기 전에 외부 지식 저장소에서 관련 정보를 검색해 답변을 보강하는 구조)가 중요해집니다. RAG는 LLM의 사전학습 지식만 믿지 않고, 기업 내부의 최신 데이터와 문서를 검색해 답변에 반영하는 방식입니다.

다만 RAG를 "문서를 벡터화해서 검색한다" 정도로 이해하면 부족합니다. 실제 운영 환경에서는 임베딩(텍스트·이미지·오디오 같은 데이터를 의미 기반 숫자 벡터로 바꾸는 방식)과 벡터 데이터베이스(임베딩을 저장하고 유사도로 검색하는 데이터베이스), 메타데이터, 그리고 주문·결제·계약·상태 변경처럼 실제 업무에서 발생하는 트랜잭션 데이터가 함께 움직여야 합니다.

고객지원 AI를 만든다고 해보겠습니다. 사용자가 "최근 결제 오류가 왜 발생했나요"라고 물으면, AI는 매뉴얼 문서만 뒤져서는 안 됩니다. 고객의 계정 상태, 최근 결제 시도, 장애 공지, 내부 운영 로그, 상품 정책, 환불 규정까지 함께 확인해야 합니다. 문서의 의미 검색만으로는 모자라고, 실제 운영 데이터와 이어져 있어야 합니다. 이때 데이터베이스는 단순한 저장소가 아니라, AI가 과거 상태와 맥락을 유지하려고 참조하는 메모리 계층이자 현재 업무 흐름과 진행 상황을 저장·갱신하는 상태 계층이 됩니다.

특히 에이전트형 시스템(AI가 단일 답변을 넘어 여러 단계의 작업을 계획·실행·검증하는 시스템)에서는 상태 관리가 더 중요합니다. 에이전트가 견적서를 만들고, 고객 정보를 확인하고, 내부 정책을 조회하고, 이메일 초안을 쓰고, 승인 요청까지 보낸다면 각 단계의 결과와 실패 상태를 저장해야 하니까요. 한 번의 프롬프트로 끝나는 시스템은 상태가 거의 필요 없지만, 여러 도구를 호출하고 여러 단계의 판단을 거치며 시간이 걸리는 업무를 처리하는 AI는 반드시 상태를 가져야 합니다. 이 상태를 어디에 저장하고, 어떻게 갱신하고, 어떤 기준으로 재시도하고, 어떤 로그를 남길지가 실제 AI 애플리케이션의 품질을 가릅니다.

저는 이 지점을 AI 엔지니어링에서 가장 중요한 전환점으로 봅니다. 이제 AI 애플리케이션은 "프롬프트 + 모델 API"가 아니라 "모델 + 데이터 + 상태 + 검색 + 평가 + 운영" 구조로 설계되어야 합니다.

AI 애플리케이션의 여섯 계층

아키텍처를 계층으로 쪼개면 역할이 분명해집니다. LLM은 자연어를 이해·생성하고 계획·판단하는 추론 계층(reasoning layer)입니다. 데이터베이스는 업무 맥락과 사용자 이력, 트랜잭션 상태, 검색 대상 데이터를 쥐고 있는 메모리·상태 계층(memory and state layer)이고요. 검색 시스템은 근거 데이터를 찾아 모델에 건네는 검색 계층(retrieval layer), 애플리케이션 서버는 모델·도구·데이터베이스·외부 API 호출을 조율하는 오케스트레이션 계층(orchestration layer)입니다. 여기에 출력과 실행 결과가 기준을 만족하는지 보는 평가 계층(evaluation layer), 그리고 로그·트레이스·메트릭으로 내부 동작을 추적하는 관측성 계층(observability layer)이 더해집니다.

이 구조에서 중요한 건 "벡터냐 그래프냐"의 이분법이 아닙니다. 벡터 검색은 비정형 데이터의 의미를 다루는 데 강하고, 그래프는 개체와 개체 사이의 관계·맥락을 또렷이 표현하는 데 강합니다. 전문 검색(키워드와 문장으로 텍스트를 찾는 방식)은 정확한 용어·코드·이름·조항을 찾을 때 여전히 필요하고, OLTP(Online Transaction Processing, 주문·결제·상태 변경처럼 실시간 업무 데이터를 안전하게 처리하는 방식)는 업무 정합성의 기반입니다. 실무에서 이들은 대체 관계가 아니라 보완 관계입니다. 좋은 AI 애플리케이션은 한 가지 검색 방식에만 기대지 않고, 의미 검색·키워드 검색·메타데이터 필터링·트랜잭션 데이터 조회·그래프 관계 탐색을 조합해 검색 품질을 끌어올립니다.

검색 품질은 프롬프트가 아니라 데이터 모델링 문제다

이 대목에서 많은 AI 프로젝트가 무너집니다. 데모에서는 "문서를 넣고 질문하면 답한다"로 충분해 보이지만, 운영에서는 사용자가 늘 깔끔하게 묻지 않고 문서도 늘 최신이 아닙니다. 권한이 다른 사용자가 같은 질문을 던지기도 하고, 한 문서 안에 오래된 정책과 최신 정책이 섞여 있기도 합니다. 어떤 데이터는 검색되면 안 되고, 어떤 데이터는 반드시 검색되어야 합니다.

그래서 RAG는 단순한 검색 기능이 아니라 데이터 품질 시스템(데이터의 정확성·최신성·일관성·권한 적합성을 관리하는 체계)에 가깝습니다. 필요한 건 단순한 벡터 인덱스가 아닙니다. 문서가 언제 만들어졌고, 누가 승인했고, 어떤 버전이 최신이고, 어느 부서가 볼 수 있고, 어떤 업무 프로세스와 연결되며, 어떤 엔티티(고객·계약·상품·문서처럼 시스템이 구분해 다루는 대상)와 묶이는지까지 함께 관리되어야 합니다. AI 검색 품질은 프롬프트만으로 풀리지 않습니다. 데이터 모델링(서비스가 다루는 데이터를 어떤 구조로 저장하고 연결할지 설계하는 작업)의 문제입니다.

또 하나 중요한 건 컨텍스트 조립(검색된 데이터 중 모델에 넣을 정보를 선별·정렬·압축하는 과정)입니다. LLM에는 컨텍스트 창(모델이 한 번에 참고할 수 있는 입력 토큰 범위)이 있어서 검색된 데이터를 전부 넣을 수 없습니다. 무엇을 우선해서 넣고, 무엇을 빼고, 무엇을 요약할지 정해야 하죠. 그래서 검색 결과의 관련도로 순위를 매기는 retrieval ranking, 1차 결과를 더 정교하게 다시 정렬하는 reranking, 문서를 검색 가능한 작은 단위로 나누는 chunking, 답변이 실제 데이터와 문서에 기반하도록 묶어 두는 grounding이 중요해집니다.

엔지니어링 관점에서 RAG 파이프라인은 이렇게 봐야 합니다. 사용자 질문을 곧장 벡터 검색에 넣는 게 아니라, 먼저 의도 분류(요청이 조회·요약·비교·실행 중 무엇인지 가르는 과정)를 하고, 검색이 잘 되도록 질문을 다듬는 질의 재작성을 거쳐, 권한·날짜·카테고리·상태 같은 조건으로 범위를 좁히는 메타데이터 필터를 적용합니다. 그다음 벡터 검색, 전문 검색, 노드와 관계를 따라가는 그래프 탐색, 실제 업무 데이터베이스에서 상태를 확인하는 트랜잭션 조회를 조합하고요. 결과를 reranking한 뒤 정보가 서로 충돌하면 우선순위를 정해 일관된 근거를 만드는 충돌 해결을 수행하고, 마지막으로 모델에 넘길 컨텍스트를 구성하고 어떤 근거를 썼는지 감사 로그(audit log)로 남깁니다. 이게 실무형 RAG입니다.

에이전트에는 상태와 재현 가능성이 필요하다

에이전트도 마찬가지입니다. 도구를 호출하는 순간, 엔지니어는 "툴을 붙였다"에서 멈추면 안 됩니다. 각 실행을 작업 실행 단위(task run), 단계 실행 단위(step run), 도구 호출(tool call), 산출물(artifact), 사람의 검토·승인이 필요한 단계의 승인 상태(approval state)로 나눠 저장해야 합니다. 이 구조가 없으면 에이전트 시스템은 디버깅이 불가능해집니다. 왜 이 답변이 나왔는지, 어떤 문서를 근거로 삼았는지, 어떤 API를 호출했는지 알 수 없고, 실패했을 때 어디서 재시도할지도, 사용자가 문제를 제기했을 때 재현할 방법도 없습니다.

AI 시스템에서 재현 가능성은 기존 소프트웨어보다 더 어렵습니다. 모델 버전, 프롬프트 버전, 검색 인덱스 버전, 문서 버전, 권한 상태, 호출 시점의 운영 데이터가 모두 결과에 영향을 주기 때문입니다. 그래서 모델·프롬프트·문서·검색 인덱스·정책의 변경 이력을 관리하는 버전 관리가 필요하고, 운영 환경에서는 "지금 답변이 왜 이렇게 나왔는가"를 설명할 수 있어야 합니다.

이건 개발 편의성의 문제가 아니라 책임 소재의 문제입니다. 금융·의료·법률·제조·공공 영역에서는 AI가 어떤 판단을 했는지보다 "어떤 근거로 그 판단을 했는지"가 더 중요합니다. 그래서 답변 생성보다 근거 관리(답변에 쓴 출처·문서·데이터를 추적하고 검증하는 체계)가 더 중요해지는 순간이 많습니다.

권한은 프롬프트가 아니라 시스템 경계에서

AI 애플리케이션에는 권한 제어가 반드시 들어가야 합니다. 역할에 따라 접근 권한을 주는 RBAC(Role-Based Access Control), 사용자·리소스·환경의 속성으로 접근을 제어하는 ABAC(Attribute-Based Access Control), 주민번호·전화번호·이메일 같은 식별 정보를 가리거나 제거하는 PII 마스킹, 여러 고객·조직의 데이터가 섞이지 않게 분리하는 테넌트 격리가 검색 단계부터 적용되어야 합니다.

많은 시스템이 이 부분을 놓칩니다. LLM에 넘기기 전에 검색 결과에서 이미 권한 검사가 끝나 있어야 합니다. 모델에게 "이 정보는 보여주면 안 돼"라고 사후에 맡기는 건 안전한 설계가 아닙니다. 보안은 프롬프트가 아니라 외부 입력과 내부 자원 사이를 통제하는 시스템 경계에서 처리해야 합니다.

결국 무엇이 경쟁력을 가르는가

결국 엔지니어링의 목표는 "모델이 답을 하게 만드는 것"이 아닙니다. 모델이 올바른 근거를 바탕으로, 올바른 권한 안에서, 올바른 최신 상태를 반영해, 재현 가능한 방식으로 업무를 수행하게 만드는 것입니다. 이렇게 보면 AI 전환은 모델 API를 붙이는 일이 아니라, 기존 소프트웨어의 데이터 구조·검색 구조·상태 관리·품질 관리 체계를 다시 설계하는 일입니다.

이 변화는 개발자에게 분명한 메시지를 줍니다. 앞으로의 AI 엔지니어는 프롬프트를 잘 쓰는 사람만을 뜻하지 않습니다. 데이터 모델링, 검색 아키텍처, 시스템 상태 관리, 품질 평가, 보안 설계를 함께 이해해야 합니다.

저는 앞으로 AI 애플리케이션의 경쟁력이 네 가지에서 갈린다고 봅니다. 어떤 모델을 쓰는가, 어떤 데이터를 연결하는가, 어떤 상태를 저장하는가, 어떤 기준으로 품질을 검증하는가. 초기 AI 제품은 첫 번째 질문에 매달렸지만, 실제 기업 도입에서는 두 번째·세 번째·네 번째가 더 중요해집니다.

모델은 점점 더 좋아질 겁니다. 그러나 모델이 좋아진다고 기업 데이터가 저절로 정리되거나, 권한 체계가 저절로 설계되거나, 검색 품질·업무 상태 추적·운영 로그와 감사 체계가 저절로 생기지는 않습니다. 여기가 엔지니어링의 영역입니다.

AI 시대에는 애플리케이션이 더 많이 만들어질 겁니다. 자연어가 새로운 추상화 계층(복잡한 내부 구현을 감추고 더 단순한 인터페이스로 다루게 하는 계층)이 되면서 소프트웨어를 만드는 비용은 낮아지지만, 소프트웨어를 신뢰 가능하게 운영하는 난이도는 오히려 높아지고 있습니다. 이제 중요한 질문은 "AI가 코드를 만들 수 있느냐"가 아니라 "AI가 만든 소프트웨어가 어떤 데이터를 신뢰하고, 어떤 상태를 기억하며, 어떤 기준으로 품질을 보장할 것인가"입니다.

AI 애플리케이션의 경쟁력은 모델 하나로 결정되지 않습니다. 모델·데이터베이스·검색·상태·권한·평가·관측성이 하나의 시스템으로 설계될 때 비로소 실제 업무에 들어갈 수 있습니다. AI는 소프트웨어를 대체하는 게 아니라 소프트웨어의 구조를 바꾸고 있고, 그 변화의 중심에는 여전히 엔지니어링이 있습니다.