본문은 로드 존슨(Rod Johnson)의 글 <Don’t Talk English to Your LLM>을 번역한 글입니다. 로드 존슨은 스프링 프레임워크를 만든 것으로 유명한 개발자죠. 그는 최근 Embabel이란 기업을 설립하고, 에이전트 프레임워크를 개발하고 있습니다. 필자에게 허락받고 번역과 게재를 진행했습니다.

우리가 자연어를 사용해도 LLM이 잘 알아듣는다고 해서 언제나 자연어만 써야 하는 것은 아닙니다. 중요한 프로세스를 다룰 때면 인간 스스로도 자연어로 소통하지 않으니까요.

경험상 프로세스는 구조화하지 않으면 확장시킬 수 없습니다. 컴퓨터가 존재하기 이전에도 구조화된 형태가 존재했듯이 말입니다.

물론 LLM의 유창한 자연어 능력은 의사소통에 유용합니다. 또 여러 가지를 통합하며 생기는 문제의 모호함을 완화하는 데 유용합니다. 하지만, 이는 우리의 주의를 산만하게 할 우려가 있습니다. 즉, LLM을 이용하느라 시스템 설계에 대해 소홀해져서는 안 됩니다.

채팅 인터페이스, 과연 최선일까?

Commonwealth Bank의 Blair Hudson은 생성형 AI 도입의 1차 물결이 채팅에 대한 과도 의존으로 실패했다고 말합니다. 챗GPT가 소비자 앱 분야에서 기록적인 성장세를 보였지만, 비즈니스에는 부적합한 방향이었다고 보는 것입니다.

전 세계 팀들은 범용적이고 빠르게 시제품을 만들 수 있다는 이유로 채팅 인터페이스를 만들었습니다. 일부는 제품화되었지만,

대부분은 그렇지 못했습니다.

개인적인 견해로 채팅 인터페이스는 본질적 작업이 이루어지는 공간이 아니기에 AI 도입이 정체되었습니다. 병원을 채팅창으로 운영할 수는 없습니다. 소매점이나 공급망도 마찬가지입니다. 대부분의 일에 대해 채팅은 잘못된 추상화였습니다. 가능성을 열어줬을 뿐 실질적인 생산성에는 더 많은 것이 필요합니다.

잘못된 인터페이스도 문제지만 더 중요한 건 구조가 빠져 있다는 것입니다.

인간은 텍스트로 병원을 운영하지 않습니다. 여러 출처의 구조화된 정보를 이용하고 갱신합니다. 그리고 구조는 이러한 작업의 안전성을 높이고 예측할 수 있도록 만듭니다.

(병원에서 일하는 사람들은) 모니터가 “Kim의 혈압이 대부분 안정적이다가 오전 늦게 치솟았다”라고 말하는 대신 그래프나 위급 상황 알림을 원합니다. 의사는 차트를 기록할 때, 자연어를 쓰기도 하지만 가능한 한 구조를 활용합니다. 각 약물의 밀리그램 수, 온도, 산소포화도 같은 명확한 수치를 포함합니다. 환자의 기분과 같은 주관적 사항도 비교할 수 있게 구조화된 설문과 척도를 사용합니다.

자연어의 과도한 사용이 부르는 숨겨진 비용

생성형 AI를 사용할 때 자연어를 활용하는 방식은 매력적이지만, 과하게 의존하는 일은 높은 비용을 치르게 합니다. 인상적인 결과를 빠르게 생산할 수는 있어도 미래의 문제를 남겨 둡니다.

자연어는 불투명합니다. 도구에 적용하기 어렵고, 고가의 벡터 임베딩을 써도 검색이 부정확할 수 있습니다. LLM의 이해를 완전하게 신뢰할 수 없고 지연 시간이 길어지거나 비용을 키우기도 합니다. 정확한 RAG 시스템 구축의 어려움이 이를 증명합니다. 모든 작업을 자연어로 처리하는 것은 어려우며, 특히 코드를 실행할 때는 더 그렇습니다. 코드는 항상 LLM보다 비용과 예측 가능성 측면에서 우월합니다.

자연어는 또한 모호하다는 문제를 지니는데, 이는 바로 프로그래밍 언어가 존재하는 이유이기도 합니다.

흔히 쓰이는 소프트웨어 객체나 데이터베이스 행은 다음과 같은 비즈니스 문제 해결에 훨씬 뛰어납니다.

검색: ID를 알면 필요한 정보를 확실히 찾거나 그러한 정보가 존재하지 않음을 확실히 알 수 있습니다. (후자는 특히 중요합니다.) 구조화된 데이터를 이용하면 적합한 데이터베이스 기능을 활용해서 성능 좋은 쿼리를 쓸 수 있습니다.
변경 추적: 구조를 더 많이 활용할수록 더 낮은 비용으로 정확하게 변화를 감지할 수 있습니다. 객체 그래프의 변경 감지나 데이터베이스 트리거를 이용한 세부 변경 감지를 예로 들 수 있습니다.
안전하고 선택적인 공유: 신뢰도가 낮은 외부와는 모델 부분만 안전하게 공유할 수 있습니다.

생성형 AI 앱을 개발할 때, 구조가 필요한 소통에도 자연어를 이용하는 것은 게으른 선택입니다. 초기에는 시간을 아낄 수 있겠지만, 장기적으로 문제를 쌓는 일입니다.

그렇다면, 어떤 구조를 써야 할까?

구조가 필요하다면 어디를 봐야 할까요?

LLM은 어떤 포맷을 쓰든 큰 상관 없습니다. JSON, XML은 물론 흔히 쓰이는 다른 포맷도 충분히 이해합니다.

중요한 질문은 표현 방법이 아니라 구조를 어떻게 채우느냐입니다.

비즈니스 애플리케이션 관한 한, 답은 명확하지만 이상하게도 생성형 AI를 다룬 많은 글에서 간과하고 있습니다. 우리는 가능한 이미 존재하며, 도메인 특징을 잘 반영하는 구조를 사용해야 합니다.

다시 말해 도메인 통합이 핵심이며, 가능하면 자연어 대신 도메인 언어로 LLM과 소통해야 합니다.

가장 가치 있는 생성형 AI의 활용법은 완전히 새로운 비즈니스 애플리케이션이 아니라 대부분 기존 비즈니스 애플리케이션에서 성장할 것입니다. 이들 애플리케이션은 기존 도메인 모델과 인프라를 활용하기 때문에 결과적으로 더 견고하고 유용할 것입니다.

JVM이 빛을 발하는 이유

이것이 기업용(enterprise) 자바 생태계가 빛을 발하는 부분입니다. 수십 년간 자바 개발자들은 도메인 모델링, 타입 안전성, 구조화 데이터 처리를 뛰어나게 해왔기에, 생성형 AI 앱에도 이들이 필요합니다.

파이썬 프레임워크는 기존 기업용 시스템과 분리되어 있어 모든 것을 문자열과 딕셔너리(dicts)로 처리합니다. 그렇기 때문에 구조가 깨진 상태에서 LLM 생성 결과를 다루도록 유도하는 경향이 있습니다. 반면에 JVM 기반 접근법은 다음과 같은 이점을 제공합니다.

강력한 타입 지원: LLM 출력이 도메인 객체로 직접 역직렬화됩니다.
기존 도메인 모델 활용: 스프링 데이터 엔티티, JPA 모델과 같이 수십 년간 집약된 도메인 지식 코드를 활용합니다.
Bean Validation (JSR 380): 추정으로 작업하는 대신 구조화된 LLM 출력을 검증합니다.
실전 검증을 거친 신뢰받는 인프라: 기존 스프링 부트 설정, 영속성 계층, 엔터프라이즈 통합을 지원합니다.

성공적인 AI 앱 개발을 위해 게으름을 버리세요

생성형 AI를 이용해서 중요한(mission critical) 애플리케이션을 개발할 때, 게으름* 피우지 마세요.

*게으름(lazy)이라고 번역하려니 어색해서 저자인 Rod Johnson에게 맥락을 확인하려고 질문을 던졌더니 다음과 같이 답했습니다.

제가 말한 ‘게으르다(lazy)’는 정말로 일을 안 한다는 뜻이 아니라, 미래에 문제가 될 수 있다는 것은 신경 쓰지 않고 일단 빠르게 돌아가게 만들기 위해 지름길을 택하는 것을 의미합니다. (By lazy I meant taking a shortcut; getting something to work quickly without caring that you are storing up problems for the future

다른 애플리케이션에서처럼 도메인 모델링을 하거나 기존 도메인 모델을 써야 합니다. 기업용 시스템을 신뢰성있게 만들어 온 엔지니어링 규율을 적용하세요. 그래야 더욱 안전하고 저렴한 동시에 예측 가능한 결과를 만들 수 있습니다.

JVM을 쓰고 있다면 이미 앞서가게 됩니다. 도구, 패턴, 인프라가 있으니까요. (그리고 Embabel이라는 강력한 에이전트 프레임워크가 있습니다.)

LLM이 자연어에 능숙하다고 해서 이미 여러분이 갖고 있던 강점을 버리지 마세요.