생성형 AI와 AI 에이전트가 빠르게 일상과 업무 속으로 들어오고 있습니다. 무엇을 만들 수 있는지가 중요했던 시기를 지나, 이제는 만든 AI를 얼마나 잘 이해하고 평가하며 운영할 수 있는지도 중요한 과제가 되었습니다. 하지만 실제 운영 환경에서는 예상하지 못한 입력과 달라지는 출력, 외부 도구의 실패처럼 데모에서는 보이지 않던 문제들이 드러납니다.

이제는 더 좋은 모델을 찾는 것만으로는 충분하지 않습니다. 불확실한 AI를 어떻게 평가하고 통제할 것인지, 문제가 생겼을 때 어떻게 원인을 파악하고 다시 개선할 것인지까지 함께 설계해야 합니다. AI를 하나의 기능이 아니라 지속적으로 관찰하고 관리해야 하는 ‘시스템’으로 바라보는 관점이 필요한 이유입니다.

『AI 시스템 설계』 이한울 저자에게 AI 시스템이 운영에서 실패하는 이유부터 평가와 통제, 에이전트 시대에 필요한 설계 원칙까지 이야기를 들어보았습니다.

안녕하세요, 이한울 저자님. 저자님은 최근 컨퍼런스를 직접 진행하셨을 만큼 AI의 보안과 신뢰성에 대한 고민을 오래 해오셨는데요. 생성형AI와 에이전트가 빠르게 확산되는 지금, AI를 둘러싼 가장 중요한 변화는 무엇이라고 생각하시나요? 

가장 중요한 변화는 AI의 발전 속도를 인간의 활용과 통제 능력이 따라가지 못하고 있다는 사실을 많은 사람이 인식하기 시작했다는 것이라고 생각합니다. 

Fable, Astra처럼 물리적인 몸을 갖지 않은 환경에서도 AGI에 가까운 모습을 보여주는 모델이 빠르게 등장하고 있죠. 반면 우리는 이런 AI를 어떻게 제대로 활용하고 통제해야 하는지 아직 충분한 답을 갖고 있지 않습니다.

활용 측면에서는 새로운 기술과 방법론이 계속 등장하고 있습니다. 2023년에는 프롬프트 엔지니어링, 2024년에는 RAG, 2025년에는 에이전트 구축, 2026년인 올해는 하네스 엔지니어링이 주목받았습니다. 모두 AI를 활용해 ‘원하는 것을 어떻게 더 잘 만들 것인가’에 초점을 맞춘 기술들이죠. 하지만 특정 시점의 모델에 맞춰 지식과 시스템을 쌓아도 더 뛰어난 모델이 등장하면 상당 부분을 다시 바꿔야 하는 일이 반복되고 있습니다.

통제의 문제는 더 큽니다. 기업 안에서 어떤 AI가 사용되고 있는지 정확히 파악하지 못하는 경우도 있고, 구축한 AI 서비스가 의도대로 동작하는지, 어떤 취약점이 있는지조차 확신하기 어렵습니다.

『AI 시스템 설계』는 바로 이런 문제의식에서 출발했습니다. AI가 아무리 빠르게 발전하더라도 적어도 시스템을 만든 사람은 자신이 만든 AI 서비스를 이해하고 통제할 수 있어야 한다는 것이죠. 소프트웨어 공학이 오랫동안 관측 가능하고, 신뢰할 수 있고, 유지보수 가능한 시스템을 지향해왔듯 AI 시스템 역시 그런 설계의 영역 안으로 들어와야 합니다. 이 책은 그 방법을 다루고 있습니다.

바이브 코딩과 AI 에이전트의 확산으로 ‘누구나 코딩할 수 있는 시대’라는 말까지 나옵니다. 저자님이 현장에서 보시기에 실제로 줄어든 일과 오히려 늘어난 일은 각각 무엇인가요? 

직접 코딩하는 일은 줄었지만, 무엇을 어떻게 만들지 결정하는 데 필요한 인지적 부담은 오히려 커진 것 같습니다. 충분히 고민하지 않은 채 바이브 코딩으로 만든 결과물을 다시 이해하고 정리하고 수정하는 일도 늘었고요.

코딩은 결국 사람의 생각과 의도를 코드로 표현하는 일입니다. AI가 코드를 대신 작성해준다고 해서 그 앞단의 생각까지 사라져도 되는 것은 아닙니다. 오히려 충분히 고민하지 않은 채 만들어진 코드가 쌓이면서 일종의 ‘인지적 부채’가 생기고, 나중에는 그것을 이해하고 정리하는 일이 새로운 숙제가 됩니다.

그래서 AI가 코딩을 더 쉽게 만들어줄수록, 역설적으로 무엇을 만들 것인지 명확하게 정의하고 결과를 판단하는 능력은 더 중요해지고 있다고 생각합니다.

기업들이 생성형 AI를 앞다퉈 도입하고 있지만 PoC 이후 실제 서비스까지 이어지지 못하는 프로젝트도 많습니다. 현재 기업의 AI 도입 과정에서 가장 자주 과소평가되는 문제는 무엇인가요?

조금 과장해서 말하면 도입 이후의 거의 모든 것이 과소평가되고 있다고 생각합니다. 만들어진 AI 서비스가 의도대로 동작하는지 검증하는 것부터 안전한지, 안정적으로 운영할 수 있는지, 유지보수가 가능한지까지 충분히 고려되지 않는 경우가 많습니다.

대부분은 “일단 도입부터 해보자”는 생각으로 서비스를 만들고, 문제가 생기면 다음에 더 좋은 모델이 나오면서 자연스럽게 해결될 것이라고 기대합니다. 하지만 모델의 성능이 좋아진다고 해서 시스템의 문제가 저절로 해결되는 것은 아닙니다.

무엇보다 현재 시스템을 제대로 평가할 수 없다면 모델을 바꾸더라도 무엇이 얼마나 좋아졌는지 알 수 없습니다. 결국 서비스를 만드는 시점부터 무엇을 평가할 것인지, 문제가 발생했을 때 어떻게 관찰하고 통제할 것인지를 함께 설계해야 합니다.

이 책은 “데모에서는 잘 작동하던 AI가 왜 운영 환경에서는 실패하는가?”라는 문제에서 출발합니다. 저자님이 실제 연구나 개발 과정에서 데모와 운영 사이의 간극을 가장 강하게 체감했던 순간이 있었나요?

2016년 AI 분야에서 커리어를 시작한 이후 거의 모든 연구와 개발 과정에서 느껴온 문제입니다. AI가 없는 일반적인 소프트웨어도 데모와 실제 운영 환경 사이에는 차이가 있지만, AI가 시스템에 들어오면서 그 간극이 훨씬 커졌습니다.

과거 금융 B2B 서비스를 개발하면서 AI 기반 최적 주문 집행 서비스를 만든 적이 있습니다. 높은 성능의 모델을 만들었고 시뮬레이션에서도 안정적인 결과가 나왔습니다. 그런데 실제 자금을 투입해 테스트하던 중 한 종목에 VI(변동성 완화장치)가 발동했고, 서비스가 예상하지 못한 방식으로 동작하면서 손실이 발생했습니다. 시뮬레이션에도 VI 상황 자체는 포함되어 있었습니다.

문제는 실제 시장에서 발생한 상황이 우리가 시뮬레이션했던 형태와 달랐다는 것이었습니다. 이 경험을 통해 데모나 시뮬레이션에서 아무리 잘 동작하더라도 현실에서는 우리가 미처 예상하지 못한 상황이 얼마든지 나타날 수 있다는 사실을 다시 한번 체감했습니다.

책에서는 ‘평가 주도 개발(EDD)’이라는 관점을 제시합니다. AI 시스템을 만들면서 정확성·안전성·비용·속도 등 여러 기준이 충돌할 때 실무에서는 무엇을 기준으로 우선순위를 정해야 할까요?

결국 가장 중요한 것은 “우리가 무엇을 만들고 있는가”입니다. 

책에서도 이야기했듯 모든 서비스에는 이루고자 하는 목표와 의도가 있습니다. 따라서 무엇을 가장 중요하게 평가해야 하는지도 서비스의 목적과 실패했을 때의 위험에 따라 달라집니다.

예를 들어 일반적인 질의응답 챗봇이라면 정확성뿐 아니라 유해하거나 위험한 답변을 생성하지 않는 안전성이 중요할 수 있습니다. 반면 여러 서비스와 연결된 AI 시스템이라면 작은 오류 하나가 다른 시스템의 장애로 이어질 수 있기 때문에 안정성과 복구 가능성이 더 중요한 기준이 될 수 있습니다.

평가 주도 개발(EDD)은 특정한 하나의 평가 방법을 의미하지 않습니다. 우리 서비스에서 무엇이 중요한지를 먼저 정의하고, 그것을 실제로 평가할 수 있도록 설계 단계부터 준비하는 개발 방식​에 가깝습니다. 

책에서는 AI 에이전트를 하나의 ‘실행 시스템’으로 바라봅니다. 앞으로 에이전트가 실제 업무에 깊이 들어갈수록 개발자가 가장 중요하게 설계해야 할 ‘경계’는 무엇일까요?

가장 중요한 것은 AI가 어디까지 스스로 판단하고 실행하도록 허용할 것인가라는 경계라고 생각합니다. 에이전트가 메일을 보내고, 코드를 실행하고, 데이터베이스를 수정하고, 다른 시스템을 호출하기 시작하면 모델의 오류가 단순한 답변의 오류를 넘어 실제 행동으로 이어집니다.

예전에는 AI가 틀린 답변을 내놓는 것이 주된 문제였다면, 이제는 틀린 판단 하나가 실제 업무를 변경하거나 시스템 장애를 일으킬 수도 있습니다.

따라서 에이전트 개발에서는 지능을 얼마나 잘 활용하느냐만큼이나 그 지능이 현실에 영향을 미칠 수 있는 범위를 어디까지 허용하고, 그 안에서 어떻게 통제할 것인지​가 중요합니다. 이를 위해서는 어떤 행동을 했는지 관찰할 수 있어야 하고, 문제가 발생했을 때 중단하거나 되돌릴 수 있어야 하며, 그 과정 자체를 지속적으로 평가할 수 있어야 합니다.

마지막으로, 책을 덮은 독자가 다음 날 자신의 AI 프로젝트에서 가장 먼저 바꿔보았으면 하는 한 가지는 무엇인가요?

“나는 지금 이 AI 프로젝트를 무엇으로 평가하고 있지?”라는 생각을 한 번 해보셨으면 합니다.

몇 가지 질문을 던지고 나온 답을 보며 “괜찮네”라고 판단하고 있는 것은 아닌지, 평가 데이터셋이 있다면 단순히 입력과 기대 출력만 모아둔 것은 아닌지 살펴보는 겁니다.

AI 시스템을 개선하려면 먼저 지금의 시스템이 잘하는 것과 잘못하는 것을 확인할 수 있어야 합니다. 평가할 수 있어야 문제를 찾을 수 있고, 그래야 새로운 모델이나 기술을 적용했을 때 정말 나아졌는지도 알 수 있습니다.

이한울  | 『AI 시스템  설계』저자

AI 시스템의 평가와 안전성, 신뢰할 수 있는 운영 구조를 연구하고 이를 실제 제품으로 구현해 온 연구자이자 엔지니어다. 현재 AI 안전 전문 기업 AIM Intelligence에서 Head of Defensive Security로 재직하며 방어 부문의 연구·제품·사업을 총괄하고 있으며, 국가인공지능전략위원회 자문위원으로도 활동하고 있다.

고려대학교를 졸업하고 현재 서울대학교 대학원에 재학 중이다. 신한투자증권에서 AI 엔지니어로, NCSOFT에서 AI 연구원으로 근무하며 다양한 연구개발을 수행했다. 언어 모델과 멀티모달 모델의 평가 벤치마크를 비롯해 AI 에이전트의 안전성과 신뢰성, 실제 운영 환경에서의 AI 시스템 평가와 통제 구조를 지속적으로 연구하고 있다.