AI 파일럿 프로젝트를 진행한 기업 중에서 실제 서비스로 이어지는 곳은 아직 소수다. 모델 성능 문제가 아니다. 그 모델을 얹을 바닥 자체가 부실해서 무너지는 경우가 훨씬 많다. 데이터 파이프라인이 엉성하거나, 보안 정책을 서비스 오픈 직전에야 급조하거나, GPU 자원 계획도 없이 프로젝트부터 벌이는 곳들. 딱 이런 패턴이다. 에이전트형 AI로 무게중심이 옮겨가면서 이 기초 공사는 더 중요해졌다. 챗봇 하나 붙이는 수준이 아니라 여러 AI가 서로 도구를 호출하고 데이터를 주고받는 구조라서, 아키텍처가 부실하면 장애 지점이 곱절로 늘어난다. IT 조직이 AI 도입 전에 점검해야 할 기초 요소를 정리해봤다.
데이터 파이프라인부터 다시 봐야 하는 이유
모델은 결국 데이터가 흐르는 대로 결과를 낸다. 사일로화된 데이터베이스, 정제 안 된 로그, 버전 관리도 안 되는 스프레드시트가 뒤섞인 환경. 여기에 아무리 좋은 LLM을 붙여봐야 헛돌 뿐이다. 실무에서 우선순위로 삼아야 할 항목은 이 정도다.
- 데이터 출처와 최신성을 추적하는 메타데이터 관리 체계
- 실시간 추론이 필요한 경우를 대비한 스트리밍 파이프라인
- 부서 간 데이터를 통합할 공통 스키마
이 세 가지가 없는 상태에서 에이전트를 붙이면 어떻게 될까. 잘못된 데이터로 잘못된 판단을 내리는 자동화가 그대로 서비스에 노출된다.
MLOps는 이제 선택지가 아니다
모델 하나 배포하고 끝나는 시대는 지났다. 모델 버전 관리, 성능 드리프트 모니터링, 롤백 절차. 이 셋이 없으면 시간이 지날수록 정확도가 슬금슬금 떨어지는 걸 아무도 눈치채지 못한다. CI/CD 파이프라인에 모델 평가 단계를 끼워 넣고 재학습 트리거를 자동화해둔 조직과, 이걸 수동으로 관리하는 조직. 반년만 지나도 격차가 확연히 벌어진다.
에이전트형 AI는 인프라 요구사항부터 다르다
단일 프롬프트-응답 구조와는 다르다. 에이전트는 여러 단계를 거쳐 도구를 호출하고 상태를 유지한다. 이 과정에서 지연 시간, 컨텍스트 저장, 오류 시 재시도 로직이 전부 새로운 변수로 튀어나온다. 기존 REST API 위주로 짜인 시스템에 에이전트를 그냥 얹으면? 호출량이 폭증하거나 무한 루프에 빠지는 문제가 생기기 쉽다. 오케스트레이션 레이어를 따로 두고, 각 에이전트가 어떤 도구까지 접근할 수 있는지 권한을 명확히 나눠두는 설계가 필요하다.
보안과 거버넌스, 나중에 챙기면 이미 늦다
프롬프트 인젝션, 민감 데이터 유출, 모델이 엉뚱한 근거로 내린 결정에 대한 책임 소재까지. 챙길 항목이 한둘이 아니다. 보안팀을 프로젝트 초기부터 끼워 넣는 조직과, 서비스 오픈 직전에야 검토를 요청하는 조직. 결과물은 완전히 다르다. 최소한 다음 항목은 설계 단계에 넣어야 한다.
- 모델 입출력에 대한 로깅과 감사 추적
- 외부 API 호출 전 데이터 마스킹 정책
- 사고 발생 시 즉시 차단하는 킬스위치
규제 대응 문서만 갖추고 실제 기술적 통제는 빠진 경우, 의외로 흔하다. 문서와 코드가 실제로 일치하는지 주기적으로 확인하는 절차를 만들어두는 편이 낫다.
GPU·컴퓨팅 자원, 전략 없이 덤비면 청구서에서 운다
엔비디아 GPU 확보 경쟁이 이어지면서 컴퓨팅 자원 자체가 병목이 되는 일이 흔해졌다. 온프레미스로 다 구축하기엔 비용이 부담스럽고, 클라우드만 쓰자니 트래픽이 늘어날수록 청구서가 무섭게 불어난다. 현실적인 접근은 워크로드를 나눠서 판단하는 것.
- 실시간 응답이 필요한 추론은 전용 인스턴스로
- 배치성 재학습은 스팟 인스턴스나 예약 자원으로
- 피크 시간대 트래픽은 오토스케일링으로 흡수
자원 계획 없이 프로젝트 규모부터 키우면 서비스가 뜨는 순간 비용 구조가 감당 안 되는 상황을 맞을 수 있다. 이건 흔한 실수다.
기술 못지않게 조직 구조와 사람이 문제다
아키텍처를 아무리 잘 짜도 이걸 운영할 사람이 없으면 무용지물이다. 데이터 엔지니어, MLOps 담당자, 보안 담당자가 각자 다른 팀 소속으로 흩어져 있으면 의사결정이 느려지고 책임 소재도 애매해진다. 최근에는 이 세 역할을 하나의 AI 플랫폼 팀으로 묶어 운영하는 조직이 늘고 있다. 초기 투자 비용은 크다. 다만 장기적으로는 프로젝트마다 처음부터 다시 설계하는 낭비를 줄여준다.
결국 살아남는 프로젝트는 이 3가지가 있다
데이터 기반, 운영 자동화, 보안 통제. 이 세 가지가 튼튼해야 그 위에 어떤 모델을 올려도 버틴다. 유행하는 프레임워크나 최신 모델을 좇기 전에, 이 기초 공사가 되어 있는지부터 점검하는 게 순서다. 반년 뒤, 1년 뒤에도 살아남는 AI 프로젝트와 조용히 사라지는 프로젝트. 차이는 결국 여기서 갈린다.
이것도 궁금하죠
Q. 스타트업도 이런 아키텍처를 다 갖춰야 하나?
규모에 맞게 단계적으로 가면 된다. 처음부터 완벽한 MLOps 파이프라인을 만들 필요는 없다. 데이터 정합성과 최소한의 로깅부터 시작해도 충분하다.
Q. 클라우드 AI 서비스만 써도 아키텍처 고민이 필요한가?
필요하다. 관리형 서비스를 쓰더라도 데이터 흐름 설계, 접근 권한 관리, 비용 모니터링은 여전히 자체 몫이다.
Q. 에이전트형 AI 도입 시 가장 먼저 손봐야 할 부분은?
권한 관리다. 어떤 에이전트가 어떤 도구와 데이터에 접근할 수 있는지부터 명확히 정의해두지 않으면, 사고가 터졌을 때 원인 추적조차 어렵다.
MIT Tech Review AI가 지난 7일 전한 내용을 바탕으로 정리했다.
AI리서치팀
Home-In-One AI리서치팀은 인공지능, 머신러닝, 생성형 AI의 최신 동향과 실용적 활용법을 연구합니다. ChatGPT, 클로드, 미드저니 등 AI 도구 비교 분석과 활용 가이드를 제공합니다.