칼럼 | 첫 엔터프라이즈 AI 앱을 개발하기 전에 생각해야 할 것

AI 분야에서 잡음을 가려내기가 점점 더 어려워지고 있다. 매일 새로운 벤치마크가 등장하고, 새 ‘최첨단’ 모델이 발표되며, 어제의 아키텍처가 이미 구식이 됐다는 주장도 끊임없이 나온다. 특히 대기업에서 첫 AI 애플리케이션을 구축해야 하는 개발자라면, 쏟아지는 발표의 양 자체가 판단을 마비시킬 수 있다.

이때 순위는 큰 도움이 되지 않는다. 변화 속도가 너무 빠르기 때문이다. 불과 지난주만 해도 미스트랄(Mistral)의 새로운 모델이 공개됐고, 구글은 대규모 업데이트를 발표했으며, GPT-4o를 코딩 벤치마크에서 앞선다고 주장하는 오픈웨이트 모델도 등장했다. 이런 상황에서 무엇을 해야 할까? 오늘의 모델을 기준으로 개발을 시작했다가 배포하기도 전에 구식이 되는 것은 아닐까? 더 근본적으로는, 계획하고 추론하며 복잡한 워크플로우를 실행하는 완전 자율형 에이전트 시스템을 아직 만들고 있지 않다면 이미 크게 뒤처진 것은 아닐까 하는 걱정도 생길 수 있다.

그런 생각은 멈춰도 된다. 실제로 뒤처진 것이 아니다.

엔터프라이즈 AI의 현실은 매주 발표되는 챗봇 성능 경쟁의 결과와는 큰 관련이 없다. 핵심은 화려하지도 않고 주목받지도 않는 데이터 엔지니어링, 거버넌스, 통합 작업에 있다. 이제 AI를 만능 해결책처럼 바라보던 시기를 지나 산업화 단계로 들어서고 있다. 과제는 가장 똑똑한 모델을 고르는 것이 아니라, 실제 세계의 온갖 비합리성과 복잡성을 견뎌낼 수 있는 시스템을 구축하는 것이다.

개발자가 첫 번째 AI 애플리케이션을 만들 때 참고할 만한 몇 가지 접근법을 소개한다.

빠지기 쉬운 함정

AI 개발과 관련해서는 이른바 ‘순위표의 환상’에 휘말리기 쉽다. 수학 벤치마크에서 1% 더 높은 점수를 받은 모델을 보고, 그것이 유일한 선택지라고 단정하는 식이다. 프로그래머이자 작가인 사이먼 윌리슨은 이를 ‘느낌 기반 평가(vibes-based evaluation)’라고 표현했다. 가벼운 대화에서 어떤 챗봇이 더 ‘똑똑해 보이는지’를 판단하는 데는 어느 정도 참고가 될 수 있지만, 실제 운영 환경의 워크로드를 평가하는 기준으로는 적절하지 않다. 이제는 1990년대 소프트웨어 경쟁처럼 하나의 플랫폼이 모든 것을 차지한다는 관점에서 AI를 바라보는 태도에서 벗어날 필요가 있다.

모델 가중치는 점점 차별성이 사라지는 방향으로 가고 있다. 모두에게 필요하지만 누구도 직접 관리하고 싶어 하지 않는, 일종의 기반 인프라에 가까워지고 있다는 의미다. 앤트로픽이나 오픈AI를 사용하든, 라마(Llama)와 같은 오픈소스 모델을 선택하든, 기업 업무의 약 90%를 처리하기에 충분한 수준의 지능을 확보할 수 있다. 첫 번째 AI를 개발하는 데 체감되는 차이는 크지 않다. 결국 ‘가장 좋은’ 모델이란 성능 순위표에서 앞선 모델이 아니라, 보안과 안정성을 갖추고 실제로 사용할 수 있는 모델인 경우가 많다.

AI 분야의 여러 사이클을 누구보다 많이 경험한 스탠퍼드대 교수 앤드루 응은 최근 비교적 단순하지만 핵심을 찌르는 조언을 내놓았다. 그는 “가치 있는 무언가를 만드는 데 훨씬 더 집중해야 한다”라고 말했다. 당연하게 들리지만, 실제 현장에서는 자주 간과되는 조언이다. 응은 진정한 가치가 모델 계층이 아니라 애플리케이션 계층에 있다고 설명했다. 송장을 자동으로 대조하거나 법률 문서를 요약하는 등 실제 비즈니스 문제를 해결하는 도구를 만든다면, 그 파운데이션 모델이 순위표에서 1위인지 3위인지는 결국 큰 의미를 갖지 않는다.

AI의 작동 원리는 전통적인 소프트웨어와 근본적으로 다르다. 오픈소스 세계에서는 코드 자체가 핵심 자산일 수 있지만, AI 환경에서 모델은 일시적인 상품에 가깝다. 진정한 자산은 데이터이며, 그 데이터를 어떻게 모델에 공급하고 활용하느냐에 있다.

데이터베이스처럼 사고하라

모델을 선택한 후에는 곧바로 ‘에이전트’를 만들어야 한다는 유혹에 빠지기 쉽다. 웹을 탐색하고, 데이터베이스를 조회하며, 스스로 판단까지 내리는 AI 에이전트를 설계했다는 공로를 인정받고 싶기 때문이다. 하지만 신중할 필요가 있다. 아직 에이전트를 만들 준비가 되지 않았을 가능성이 크다. 이는 AI가 충분히 똑똑하지 않아서도 아니고, AI 경험이 부족해서도 아니다.

문제의 핵심은 데이터가 충분히 정리돼 있지 않다는 데 있다.

최근 기사에서 언급했듯, AI의 메모리는 본질적으로 데이터베이스 문제다. 에이전트에서 메모리를 제거하면 비용이 매우 높은 난수 생성기에 불과해진다. 에이전트는 사람의 데이터를 기계의 속도로 처리한다. 이 데이터가 구조화돼 있지 않고, 거버넌스가 적용돼 있지 않다면 에이전트는 대규모 환경에서 확신에 찬 오답을 만들어내게 된다.

대부분의 기업은 여전히 데이터가 어디에 존재하는지 파악하는 단계에 머물러 있다. 대규모 언어 모델에 데이터를 어떻게 노출할지까지 고민하는 경우는 더 드물다. AI의 메모리는 흔히 컨텍스트 윈도우라는 개념으로 단순화해 설명되지만, 실제로는 구조화된 저장과 관리가 필요한 데이터베이스에 더 가깝다. 여기에는 스키마 설계, 접근 제어, AI가 허위 사실을 지어내거나 민감한 정보를 잘못된 사용자에게 노출하지 않도록 막는 방화벽 등 트랜잭션 로그에 적용하는 것과 동일한 수준의 엄격함이 필요하다.

첫 번째 AI 시스템을 설계하고 있다면, 출발점은 메모리 계층이어야 한다. AI가 무엇을 알고 있어도 되는지, 그 지식은 어디에 저장되며, 어떤 방식으로 업데이트되는지를 먼저 결정해야 한다. 그 다음에야 프롬프트를 고민할 차례가 뒤따른다. 이때 가장 먼저 고려해야 할 요소는 따로 있다. 바로 추론이다.

추론부터 시작하라

과거에는 모델 학습에 들어가는 막대한 비용에 관심이 쏠렸다. 그러나 엔터프라이즈 환경에서는 이 부분이 크게 중요하지 않다. 현재 AI의 핵심은 추론, 즉 이미 학습된 지식을 실제 애플리케이션에 적용하는 단계에 있다. 다시 말해, 거버넌스가 적용된 기업 데이터를 모델과 결합할 때 AI는 비로소 실질적인 가치를 만들어낸다. 기업에서 AI 활용 역량을 키우는 가장 좋은 출발점은 거창한 에이전트 시스템이 아니라 간단한 검색 증강 생성(RAG) 파이프라인이다.

실무에서 이는 무엇을 의미할까? 인사 정책, 기술 문서, 고객 지원 로그처럼 지루하고 정리가 덜 된 문서 묶음을 하나 정한 뒤, 그 데이터만을 기반으로 사용자가 질문하면 답을 얻을 수 있는 시스템을 만들어보는 것이다. 이 과정은 기업 경쟁력을 높이는 중요한 문제들을 해결하는 데 유용하다. 예를 들면 다음과 같다.

• 데이터 수집 및 정리: PDF 문서를 어떤 기준으로 나누고 정리해야 모델이 내용을 제대로 이해할 수 있을지 고민한다.
• 거버넌스: 사용자가 권한이 없는 질문을 했을 때, 모델이 답변하지 않도록 어떻게 통제할 것인지 설계한다.
• 지연 시간: 응답이 느리다면 아무리 정확해도 실제 현장에서 활용되기 어렵다.

이런 작업은 지루하게 느껴질 수 있다. 하지만 AI 연구자 안드레 카파시는 대규모 언어 모델을 새로운 운영체제의 커널에 비유한 바 있다. 사용자는 커널과 직접 상호작용하지 않으며, 그 위에서 동작하는 애플리케이션을 사용한다. 결국 개발자의 역할은 사용자 인터페이스, 업무 로직, 데이터 연결 구조를 포함한 ‘사용자 영역’을 구축하는 데 있다.

표준화된 개발 경로를 구축하라

플랫폼 엔지니어링 역할을 맡고 있다면, 모든 것을 통제하고 싶다는 생각이 먼저 들 수 있다. 하나의 모델과 하나의 API를 정해두고, 모든 개발자가 이를 따르도록 강제하고 싶어지는 것이다. 그러나 이런 접근은 바람직하지 않다. 플랫폼팀이 이른바 ‘안 된다고만 말하는 조직’이 되어서는 안 된다. 통제 장치를 지나치게 강화하면, 개발자들은 개인 신용카드를 쓰거나 관리되지 않는 외부 API를 활용하는 방식으로 우회하게 된다.

대신 ‘표준화된 경로’를 구축해야 한다. AI 애플리케이션을 올바르게 구축하는 방식이 곧 가장 쉬운 선택이 되도록, 조합 가능한 서비스와 가드레일을 제공하는 전략이다. 예를 들어 vLLM 등 여러 제공자가 지원하는 ‘오픈AI 호환 API’와 같은 인터페이스를 표준으로 삼으면, 이후 성능 순위가 바뀌더라도 백엔드 모델을 유연하게 교체할 수 있다. 당장은 빠르고, 규정을 준수하며, 안정적으로 사용할 수 있는 모델 하나를 선택한 뒤 다음 단계로 나아가면 된다.

목표는 개발자의 속도를 억누르는 것이 아니라 올바른 방향으로 이끄는 것이다. 데이터 거버넌스가 기본적으로 적용된 안전한 실험 환경을 제공해, 큰 위험 없이 다양한 시도를 할 수 있도록 해야 한다.

또한 첫 애플리케이션을 만들 때는 반드시 사람이 개입하는 구조를 염두에 둬야 한다. 전체 과정을 한 번에 자동화하려고 하기보다는, 보고서 초안이나 SQL 쿼리의 1차 결과를 AI가 생성하고, 이를 사람이 검토한 뒤 실행하도록 설계해야 한다. 이는 잘못된 답변이 그대로 사용될 위험을 줄이고, 사람의 판단을 보조하는 도구로 AI를 활용하도록 만든다.

그렇다면 성능 순위를 참조하지 않고도 어떻게 모델이 충분히 괜찮은지 판단할 수 있을까? 추측할 필요는 없다. 직접 테스트하면 된다.

오픈AI와 앤트로픽은 모두 ‘평가 기반 개발’을 강조하지만, 처음부터 복잡한 체계를 도입할 필요는 없다. 모델이 수행하길 원하는 실제 사례 50~100개, 즉 정답이 명확한 질문과 답변 세트만 준비하면 된다. 새로운 모델이 등장해 성능 향상을 내세울 때마다, 이 사례들을 실행해 보면 된다. 현재 사용 중인 모델보다 더 빠르거나 더 저렴하게 문제를 해결한다면 교체하면 되고, 그렇지 않다면 굳이 신경 쓸 필요 없다. 결국 중요한 기준은 외부 리더보드가 아니라, 각 조직이 직접 만든 자체 기준이다.

지루함을 선택하라

요약하자면, 데이터에 집중해야 한다. 거버넌스에 집중해야 한다. 수많은 문서나 반복적인 업무에 파묻혀 있는 회사 내 특정 사용자를 위해, 지루해 보이지만 실제로 필요한 문제 하나를 해결하는 데 집중해야 한다. 성능 순위표는 굳이 신경 쓰지 않아도 된다. 이는 연구자에게 의미가 있는 지표일 뿐이다.

AI 시대의 승자는 거버넌스가 적용된 데이터 위에서 지능을 저렴하고, 쉽게, 안전하게 활용할 수 있도록 만드는 곳이 될 것이다. SNS에서 화제가 되는 결과를 만들지는 못할지 모르지만, 엔터프라이즈 환경에서 실제로 살아남는 애플리케이션을 만드는 데는 분명 도움이 된다.
dl-ciokorea@foundryco.com