파이썬이 AI 분야의 사실상 표준 언어가 된 것은 우연이 아니다. 파이썬의 지배력이 뛰어난 성능이나 화려한 기능 때문이라고 보긴 어렵다. 오히려 아이디어에서 실제 동작하는 코드로 옮겨가는 거리(개발 진입 장벽)가 가장 짧은 언어이기 때문이다. 파이썬은 누구나 접근하기 쉬운 범용 언어이며, 비록 첫 번째로 배우는 언어는 아닐지라도 많은 개발자에게 ‘두 번째 언어’로 자리 잡았다.

AI의 급성장과 함께 파이썬의 인기가 폭발적으로 높아진 것도 이런 맥락에서 이해할 수 있다. 무엇보다 파이썬은 실험의 문턱을 낮춘다. 빠르게 변화하는 AI 분야에서 이는 매우 중요한 이점이다.

하지만 파이썬이 AI 애플리케이션 시장을 완전히 장악한 것은 아니며, 그래서는 안 된다고 말하는 사람도 있다. 스프링(Spring) 프레임워크의 창시자 로드 존슨이 그 대표적인 인물이다.

존슨은 “이미 파이썬으로 에이전트를 개발하고 있다면, 자바로 옮겨서 타입 안정성과 같은 일부 이점을 얻겠다고 정당화하기는 어렵다”라고 말한다. 그러나 “이미 자바 기반으로 개발을 하고 있다면, 자바로 구축된 엠바벨(Embabel) 같은 에이전트 프레임워크를 사용하는 것은 너무도 당연한 선택”이라고 덧붙였다.

존슨의 주장은 명확하다. 데이터의 가치를 극대화하는 핵심은 새로운 기술이나 ‘신비한 데이터 과학자’를 좇는 것이 아니라, 이미 보유한 인력과 기술 스택을 얼마나 효과적으로 활용하느냐에 달려 있다는 것이다.

핵심은 ‘사람’

AI 분야에서는 자바냐 파이썬이냐, 혹은 다음 세대 언어냐 하는 기술 논쟁에 빠지기 쉽다. 그러나 AI의 가장 어려운 부분은 도구가 아니라 사람이다. 도메인 지식, 역량, 그리고 기술 수용성이야말로 ‘완벽한 언어’를 선택하는 것보다 훨씬 더 중요하다. AI를 성공적으로 도입하려면, 개발자와 도메인 전문가가 현재의 그 자리에서 자연스럽게 AI를 활용할 수 있도록 환경을 맞춰줘야 한다.

당연한 이야기처럼 들리지만, 실제로 많은 기업이 여전히 ‘새로운 기술을 도입하면 사람들이 따라올 것’이라는 착각에 빠져 있다. 그러나 올바른 접근은 사람들이 이미 익숙한 기술을 통해 역량을 확장할 수 있도록 돕는 것이다. 예를 들어, 복잡한 데이터 분석 도구 대신 직원들이 이미 익숙한 엑셀을 활용해 분석을 진행하는 것이 더 효과적일 수 있다. 혹은 AI 기반 쿼리를 위해 SQL을 사용하는 것도 좋은 선택이다. 이미 대부분 직원이 SQL을 다룰 줄 알기 때문이다. 마찬가지로 이미 전문성을 갖춘 프로그래밍 언어를 계속 사용하는 것이, 최근 유행하는 ‘핫한’ 언어로 갈아타는 것보다 훨씬 더 현명한 선택일 수 있다.

이 원칙은 프로그래밍 언어를 넘어 기술 스택 전반에도 그대로 적용된다. 가트너는 2028년까지 생성형 AI 비즈니스 애플리케이션의 80%가 새롭게 설계된 ‘AI 퍼스트(AI-first)’ 스택이 아닌, 기존 데이터 관리 플랫폼 위에서 구축될 것이라고 전망했다. 쉽게 말해 대부분 기업은 완전히 새로운 기술 스택을 도입하기보다는, 현재 사용 중인 시스템에 AI를 통합하는 방식을 택하게 된다는 의미다. 로드 존슨의 말처럼, 개발자가 이미 자바에 익숙하다면 에이전트 개발에 자바를 활용하는 것이 당연한 선택이 될 것이다.

파이썬은 어떨까?

이 관점은 다소 논란의 여지가 있을 수 있다. 오늘날 생성형 AI를 활용하려면 반드시 파이썬으로 개발해야 한다는 인식이 널리 퍼져 있기 때문이다. 예를 들어, 대규모 언어 모델(LLM)을 활용해 작업을 수행하는 오토GPT(AutoGPT) 스타일의 에이전트를 구현할 때 대부분의 오픈소스 예제, 인기 라이브러리, 온라인 튜토리얼이 모두 파이썬 기반으로 제공된다. 실제로 파이썬의 AI 생태계는 매우 풍부하다.

하지만 그렇다고 해서 자바나 C# 개발자가 AI 에이전트를 만들 수 없다는 뜻은 아니다. 전혀 그렇지 않다. 오히려 다른 언어에 숙련된 개발자에게 파이썬을 강제로 사용하게 하는 것은 역효과를 낼 수 있다. 이는 생산성을 떨어뜨리고, 조직 내 기술 일관성을 해칠 위험이 있다.

로드 존슨은 스프링 프레임워크를 통해 엔터프라이즈 컴퓨팅 분야에 지대한 영향을 미친 인물이다. 최근에는 JVM(Java Virtual Machine) 환경에서 에이전트형 워크플로를 작성할 수 있는 프레임워크 엠바벨(Embabel)을 개발했다. 존슨은 미디엄에 올린 최근 글에서, 파이썬 기반의 크루AI(CrewAI) 프로젝트 예시를 가져와 동일한 AI 에이전트 워크플로를 자바로 다시 구현했다. 그리고 결론을 이렇게 내렸다.

자바로 더 나은 에이전트를 만들 수 있으며, 실제 생성형 AI 애플리케이션 환경에서는 JVM이 파이썬보다 우수하다.

다소 도발적인 주장이다. 이것은 ‘자바 신봉자’인 존슨이 익숙한 언어를 옹호하기 위한 발언일까, 아니면 실제로 기술적 근거가 있는 주장일까?

사실 둘 다 맞을 수도 있다. 그러나 존슨이 제시한 예시를 보면, 주장이 단순한 ‘자바 찬양’에 그치지 않는다는 점도 분명하다.

존슨이 구현한 자바 기반 에이전트는 타입 안정성(type safety)을 갖추고 있으며, 확장성과 유지보수성 측면에서도 파이썬 버전보다 우수했다. 자바의 강력한 정적 타입 시스템 덕분에 작업 간 주고받는 프롬프트나 데이터가 컴파일 단계에서 자동 검증된다. 이는 파이썬 스크립트에서 흔히 발생하는 런타임 오류, 예를 들어 프롬프트 키 오타나 데이터 형식 불일치와 같은 문제를 미리 방지할 수 있다는 뜻이다.

또한 존슨은 자바 환경이 엔터프라이즈 기능과의 통합에서도 강점을 가진다고 설명했다. 예를 들어 스프링 데이터(Spring Data)의 자바 퍼시스턴스 API(JPA)를 통해 기존 연락처 데이터베이스와 연결하는 작업이 매우 간단했다. 이런 사례는 엔터프라이즈 자바 도구들이 AI 에이전트에 데이터 영속성, 트랜잭션 관리 등 핵심 기능을 즉시 제공할 수 있다는 점을 잘 보여준다.

파이썬보다 자바가 더 나을까?

그렇다고 해서 자바가 모든 면에서 파이썬보다 우수하다고 단정할 수는 없다. 결론은 결국 ‘어떤 환경에서 출발하느냐’에 달려 있다. 존슨 본인도 이 점을 명확히 짚었다.

이미 파이썬을 사용 중이라면 굳이 다른 스택으로 옮길 이유는 없을 것이다. 하지만 이미 JVM 환경에서 개발하고 있다면 엠바벨을 쓰는 건 당연한 선택이다. 굳이 새로운 파이썬 스택을 들여와 덜 효율적인 방식을 쓸 이유는 없다.

바로 이것이 핵심이다. 이미 하나의 생태계에 투자하고 있다면, 단지 유행에 따라 다른 플랫폼으로 옮기는 것은 대부분 손해다.

파이썬 팀이라면 굳이 모든 코드를 자바로 옮길 필요가 없다. 얻을 수 있는 성능 향상이나 관리상의 이점이 그만큼의 개발 비용을 정당화하지 못할 가능성이 크다. 반대로 자바 팀 역시 오랜 시간 쌓아온 전문성과 코드 자산을 버리고 새로 파이썬으로 갈아탈 이유는 거의 없다. 특히 엠바벨 같은 프레임워크가 자바 환경에서도 최첨단 AI 구현이 가능함을 증명한 지금이라면 더욱 그렇다.

정답은 단순하다. 가장 올바른 언어는 팀이 이미 익숙하고 시스템이 그 위에 구축되어 있는 언어다. 단순해 보이지만, 동시에 가장 어려운 선택이기도 하다.

게다가 파이썬이 모든 문제를 해결하는 만능열쇠인 것도 아니다. 물론 간단한 스크립트를 작성하기에는 매우 편리하지만, 이를 대규모의 안정적인 애플리케이션으로 확장하려 하면 다양한 복잡성이 드러난다. 의존성 관리, 실행 환경 설정, 성능 최적화 등 넘어야 할 산이 많다. 필자 역시 여러 차례 언급했듯, 파이썬 문법을 배우는 건 어렵지 않다. 그러나 패키지 충돌 문제, 라이브러리 버전 불일치, 대규모 환경에서의 확장성 한계를 다루는 일은 훨씬 복잡하다. 따라서 이미 다른 생태계(예를 들어 자바 기반의 최적화된 데브옵스 파이프라인)에서 이런 문제를 해결해놓았다면, 특별한 이유가 없는 한 파이썬으로 옮겨 동일한 시행착오를 반복할 필요는 없다.

물론 파이썬의 가장 큰 강점은 방대한 AI 전용 패키지 생태계다. 이런 풍부한 라이브러리와 프레임워크만으로도 특정 프로젝트에서는 파이썬을 선택할 충분한 이유가 된다. 하지만 최근 들어서는 이런 AI 기능에 접근할 수 있는 언어가 점점 더 다양해지고 있다. 자바스크립트나 자바 등 다른 언어에서도 API나 신규 라이브러리를 통해 동일한 AI 역량을 활용할 수 있게 되면서, 언어 간 격차는 빠르게 줄어들고 있다.

결국 중요한 것은 기술적 정답이 아니라 현실적인 판단이다. 어떤 언어를 선택하든, 유행이나 신념이 아니라 팀의 역량과 프로젝트의 실용성에 기반해 결정하는 것이 최선이다.

망설이지 말자

현실적인 접근은 곧바로 성과로 이어진다. AI 기술은 지금도 기하급수적인 속도로 발전하고 있다. 한 AI 연구원은 “2026년이 AI가 본격적으로 경제 전반에 통합되는 전환점이 될 것”이라고 전망했다.

따라서 이미 역량 있는 팀과 안정된 기술 스택을 갖춘 기업이라면, 지금 당장 그 기반 위에서 AI 솔루션을 탐색하기 시작해야 한다. 빠르게 변하는 이 분야에서 주저하는 데 따르는 기회비용은 엄청나다. 새로운 것을 처음부터 쌓기보다, 이미 가지고 있는 기술 위에서 실험하고 확장하는 것이 훨씬 빠른 길이다.

AI는 목적이 아니라 목표를 달성하기 위한 수단이다. 더 유행하는 프로그래밍 언어를 사용했다고 해서 그 자체로 의미 있는 성과를 얻는 것은 아니다. 중요한 것은 실질적인 가치 창출, 즉 더 나은 비즈니스 성과, 개선된 제품, 자동화된 업무 흐름이다.

이를 실현하는 방법은 명확하다. 팀이 빠르게 시도하고 반복할 수 있으며, 이미 축적한 전문성을 활용하고, 기존 시스템과 자연스럽게 통합할 수 있는 도구를 선택하는 것이다.
dl-itworldkorea@foundryco.com