요즘 AI 추론에 대한 이야기가 많습니다. 훈련이나 미세 조정을 마친 모델을 프로덕션 환경에 배포해 추론을 하는 단계로 어떻게 나아갈 것인지로 관심사가 바뀐 것입니다. 관련해 이제 본격적으로 AI가 생산성 향상이나 새로운 비즈니스 기회 창출 같은 본격적인 가치 창출의 단계로 진화하고 있다고 말하기도 합니다. 프로덕션 환경에서 모델을 서빙하는 것은 AI 인프라와 MLOps/LLMOps 플랫폼만 있다고 되는 일이 아닙니다. 프로덕션 환경에서 모델 추론을 기반으로 AI 에이전트를 운영하는 것은 탄탄한 소프트웨어 엔지니어링 역량이 뒷받침 되어야 가능한 일입니다.
AI 모델 업데이트
AI 에이전트의 두뇌라 할 수 있는 거대 언어 모델(LLM)을 프로덕션 환경에서 서빙할 때 소프트웨어 엔지니어링 측면에서 무엇을 먼저 고려해야 할까요? 바로 점진적인 배포입니다. 이는 새로운 버전(V2)을 기존 버전(V1)과 함께 운영 환경에 배포한 다음 사용자 트래픽을 아주 조금씩 새로운 버전으로 옮겨오는 방식입니다. 마치 댐의 수문을 아주 조금씩 열듯 신중하게 진행하는 이 접근법은 새로운 버전이 일으킬 수 있는 예기치 못한 성능 저하, 품질 문제, 비용 급증과 같은 위험을 최소화하는 데 효과적입니다.
배포 과정을 알아볼까요. 먼저 새로운 버전(V2)의 AI 에이전트를 실제 운영 환경에 배포하지만 사용자에게는 노출시키지 않습니다. 이 격리된 상태에서 개발팀은 과거 사용자 요청 기록을 V2에 다시 보내 내부 검증을 합니다. 이 작업이 끝나면 전체 사용자 중 1% 같이 적은 비율의 트래픽을 V2로 보내며 실시간으로 응답 시간, 오류율, 사용자 만족도 등 모든 지표를 관찰합니다. 마지막으로 모든 것이 안정적임을 확인한 뒤에 트래픽 비중을 10%, 50% 순으로 늘려갑니다. 문제가 생기면 즉시 이전 버전으로 롤백할 수 있는 안전장치도 마련해야 합니다.
유연하고 튼튼한 시스템을 위한 설계
AI 에이전트 운영을 위한 시스템의 아키텍처는 모든 기능이 한 덩어리로 뭉쳐있는 구조가 아닙니다. 각자 명확한 책임을 가진 여러 서비스가 API나 MCP, A2A를 통해 느슨하게 연결된 형태를 띱니다. 예를 들어 AI 에이전트를 프로덕션 환경에서 운영할 경우 핵심 로직, 외부 도구 연동, 데이터베이스 검색 기능 등을 각각 독립된 마이크로서비스로 분리합니다. 이런 설계 원칙은 시스템의 유연성과 확장성의 핵심이라 할 수 있습니다. 각 요소를 독립적으로 개발하고 테스트할 수 있어 단일 지점에서 발생하는 오류나 장애가 시스템 전체로 번지는 것을 막을 수 있습니다.
테스트 환경
AI 에이전트는 출력이 항상 같지 않습니다. 전통적인 소프트웨어보다 테스트가 훨씬 까다롭습니다. 따라서 설계 초기부터 테스트의 편리성을 반드시 고려해야 합니다. 일례로AI 에이전트가 외부 날씨 API를 호출한다면 테스트 환경에서는 실제 API 대신 항상 똑같은 가상의 날씨 정보(‘맑음, 25도’)를 돌려주는 가짜(Mock) API를 호출하도록 시스템을 설계해야 합니다. 이렇게 테스트 대상을 외부 환경의 변화로부터 분리하면 AI의 답변이 조금씩 달라지더라도 시스템의 핵심 로직이 올바르게 작동하는지는 일관된 환경에서 검증할 수 있습니다.
지속적인 모니터링과 평가
AI 에이전트 환경은 새로운 차원의 모니터링을 요구합니다. 관리자는 다음과 같은 질문을 끊임없이 던져야 합니다. 시간이 지나도 모델의 답변 정확도는 그대로인가? 사용자의 만족도는 높은가? AI가 만들어내는 답변에 이상한 점은 없는가? 예상보다 비용이 많이 나오지는 않는가? 그리고 모델이 편향되거나 유해한 답변을 하고 있지는 않은가? 이러한 모니터링 결과는 배포 과정에 반영되어야 합니다. 가령 소수 사용자 테스트 단계에서 오류율이 기준치를 넘어서면 배포 파이프라인이 자동으로 중단되고 이전 버전으로 되돌아가도록 만들어야 합니다.
체계적인 프롬프트 관리
프로덕션 환경에서는 프롬프트를 코드처럼 다루어야 합니다. 무슨 소리야 하면 AI 모델의 행동을 결정하는 지시문인 프롬프트를 소스 코드와 동일한 수준의 엄격함으로 다루어야 한다는 뜻입니다. 여기에는 버전 관리, 테스트, 동료 검토 과정이 모두 포함됩니다.
가장 기본적인 방법은 프롬프트를 별도의 설정 파일에 저장하고 코드와 함께 버전 관리 시스템(Git)에서 관리하는 것입니다. 하지만 팀 규모가 커지고 기획자나 마케터 등 현업 전문가가 프롬프트 개선에 참여하면 사용자 인터페이스(UI)를 갖춘 전용 프롬프트 관리 시스템을 도입하는 것이 더 효율적입니다.
효과적인 프롬프트 관리는 테스트를 기반으로 한 반복적인 개선 과정입니다. 코드처럼 프롬프트도 여러 단계의 테스트를 거쳐야 합니다. 기본적인 기능 검증을 위한 유닛 테스트, 정해진 입력에 대해 원하는 품질의 결과가 나오는지를 확인하는 품질 테스트를 자동화해야 합니다.
무중단 업그레이드
RAG는 AI가 외부 지식 데이터베이스를 참조하여 답변하게 하는 기술입니다. 이 시스템은 글자를 ‘의미’를 담은 숫자 좌표(벡터)로 바꾸는 임베딩 모델에 의존합니다. 그런데 이 임베딩 모델을 더 좋은 모델로 바꾸려면 기존에 저장된 모든 벡터 데이터를 전부 새로 만들어야 하는 작업이 필요합니다.
서비스 중단 없이 이 작업을 수행하기 위한 핵심 전략은 병렬 운영 후 점진적 전환입니다. 먼저 새로운 V2 임베딩 모델에 맞춰 구성된 새로운 V2 벡터 데이터베이스를 만듭니다. 그리고 기존의 모든 원본 데이터를 V2 모델로 다시 변환하여 이 새로운 데이터베이스를 채워 넣습니다. 이 작업은 기존 V1 시스템이 사용자 요청을 처리하는 동안 백그라운드에서 조용히 진행됩니다.
V2 데이터베이스가 준비되면 이 데이터베이스를 조회하는 새로운 V2 검색 서비스를 개발하여 배포합니다. 그러면 구버전과 신버전 시스템이 동시에 존재하게 됩니다. 마지막으로 앞서 소개한 점진적 배포 원칙에 따라 사용자 트래픽을 V1에서 V2로 아주 서서히 옮겨옵니다. 전환 과정에서 V2 시스템의 성능과 품질을 면밀히 모니터링하여 모든 것이 안정적이라고 판단되면 100% 전환하고 난 후에 V1 시스템을 안전하게 제거합니다.
AI와 소프트웨어 엔지니어링의 화학적 결합
정리하자면 프로덕션 환경에서 AI 모델을 서빙하고 여기에 다양한 AI 에이전트나 AI 서비스를 연계해 운영하는 과정은 견고한 소프트웨어 엔지니어링 역량에 뿌리를 두어야 합니다. 점진적 배포, 테스트 자동화, 체계적인 프롬프트 관리, 무중단 업그레이드에 이르기까지 모든 논의를 관통하는 하나의 키워드가 바로 소프트웨어 엔지니어링 역량입니다. 추론의 시대로 접어든 AI 투자 이제 조직이 오랜 기간 쌓아온 소프트웨어 엔지니어링 역량과 어떻게 화학적 결합이 이루어지게 할 지 고민해야 될 때가 아닐까요.
