LLamjinLab
AI Agent글자 수 5749읽는 시간≈ 15 분

AI 에이전트는 어떤 언어를 써야 할까: Python, TypeScript와 다음 세대 제품 엔지니어링

AI 에이전트는 과연 Python을 써야 할까, 아니면 TypeScript를 써야 할까? 본 글은 딥러닝의 역사, 에이전트 제품화, 타입 시스템, 비동기 이벤트 스트림, 그리고 엔지니어링 분업을 출발점으로 삼아 차세대 AI 애플리케이션의 언어 선택을 다룬다.

AI에이전트도구 사용워크플로우프로그래밍

최근 AI 에이전트의 언어 선택에 대한 두 가지 논의가 나왔다. 참 흥미롭다.

한쪽에서는 초기 AI 에이전트가 대규모로 Python을 사용한 것은 딥러닝, 과학 계산, 모델 학습, 노트북 실험, PyTorch / TensorFlow 생태계가 오랫동안 Python을 중심으로 형성되어 왔기 때문이라고 본다. AI의 초기 주어는 “모델”이었고, 연구자들은 자연스럽게 가장 익숙한 Python을 사용해 LLM, 도구 호출, 출력 파서, 벡터 데이터베이스, 각종 실험 스크립트를 조합했다.

다른 한쪽에서는 오늘날 실제로 제품화되는 Agent는 점점 TypeScript가 더 적합하다고 본다. 실제 에이전트는 논문과 실험 스크립트에 머물지 않고 웹, 플러그인, 워크플로우 패널, IDE 확장, 기업 백오피스, SaaS 서비스, 여러 사용자 인터페이스로 들어가게 되기 때문이다. 이 단계에서 타입 시스템, 이벤트 스트림, 프론트엔드·백엔드 스키마 공유, 툴 호출 구조, 권한 객체, UI 상태 동기화가 매우 중요해진다.

나는 이것을 “Python이 끝났다” 혹은 “TypeScript가 승자다”의 단순한 문제가 아니라, 더 정확히는 AI 에이전트의 시대가 모델 엔지니어링에서 제품 엔지니어링으로 이동하고 있고, Python은 여전히 중요하지만 TypeScript가 에이전트 제품 계층과 런타임 계층에서 핵심 언어로 떠오르고 있다는 판단으로 본다.

1. 왜 초기 AI와 에이전트 생태계는 본질적으로 Python에 기울었을까

1. AI의 초기 공학 중심은 모델이지 제품이 아니다

초기 딥러닝 엔지니어링의 핵심 과제는 모델을 어떻게 학습시키고, 하이퍼파라미터를 조정하고, 텐서를 처리하고, 계산 그래프를 구성하고, GPU를 운영하며 실험을 반복하는지였다. 이 단계에서 가장 중요한 것은 웹 인터랙션, 사용자 권한, 과금, 배포, 멀티 디바이스 UI가 아니라 모델 가설을 신속하게 검증하는 일이다.

Python은 이런 작업에 매우 잘 맞는다. 문법이 간결하고 대화형 작업 경험이 좋으며, 성숙한 생태계를 갖췄고 C / C++ / CUDA 백엔드를 통해 고성능 계산 능력을 가져올 수 있다. 연구자는 Python으로 소량의 코드를 쓰고 실제로 무거운 연산은 하위 라이브러리에 맡길 수 있다.

NumPy, SciPy, Jupyter, PyTorch, TensorFlow, scikit-learn 같은 도구들은 AI와 과학 계산의 기본 워크스테이션을 오랫동안 형성해왔다. 그래서 초기의 많은 AI 에이전트 프로토타입은 본질적으로 “LLM + Python 글루 코드”였다. 즉, 프롬프트, 모델 API, 툴 함수, 출력 파싱, 벡터 검색, 작업 루프를 이어 붙이는 방식이었다.

2. Python의 강점은 과학 계산 생태계에서 왔다

Python이 AI에서 가진 위치는 단지 “쉽기 때문”이 아니다. 더 본질적으로는, 아주 일찍부터 과학 계산 생태계를 형성해왔기 때문이다.

NumPy는 다차원 배열, 선형대수, 난수, 푸리에 변환 같은 기초 기능을 제공했고; SciPy, pandas, scikit-learn이 통계, 머신러닝, 데이터 분석으로 확장했다. Jupyter Notebook은 연구자가 코드를 작성하면서 즉시 결과를 보고 실험을 디버깅하도록 해준다.

이런 워크플로우는 연구자에게 매우 적합하다. 데이터를 불러오고, 특성을 처리하고, 모델을 학습시킨 뒤 결과를 시각화한다. 모델 시대의 AI는 애초에 이런 실험 사이클을 중심으로 전개됐다.

따라서 Python은 그냥 갑자기 우세해진 것이 아니다. 그것이 강했던 이유는 이랬다:

  • 학습 비용이 낮고 진입 장벽이 낮다;
  • 과학 계산 생태계가 일찍 성숙했다;
  • C / C++ / CUDA 백엔드와 결합이 성숙했다;
  • Notebook 경험이 실험에 적합하다;
  • AI 튜토리얼, 논문 코드, 오픈 소스 모델에서 Python이 대다수다.

3. PyTorch의 동적 그래프가 Python 중심을 더 강화했다

PyTorch가 연구자에게 친화적인 이유는 크게는 “Python의 직관에 더 가까운 동적 그래프 방식” 덕분이다. 모델의 계산 그래프를 코드 실행 과정에서 동적으로 구성해 디버깅이 자연스럽고, 연구자의 반복 실험 습관과도 잘 맞는다.

TensorFlow는 초기에 정적 그래프에 더 집중했지만, 나중에 eager execution을 도입해 작업을 일반 Python 코드처럼 즉시 실행할 수 있게 바뀌었다. 이 변화만으로도 알 수 있듯이 AI 연구·실험 단계에서 개발자는 상호작용성, 직관성, 디버깅 효율을 매우 중요하게 본다.

이것이 바로 초기 AI 에이전트가 자연스럽게 Python을 택한 이유다. 연구자는 완성된 제품을 만들기 전이라도 모델, 툴, 환경, 출력 파서를 이어 붙이면 되었고, Python이 가장 편리한 글루 언어였다.

2. 왜 오늘날 에이전트 제품은 점점 TypeScript에 더 적합해졌는가

1. 에이전트는 더 이상 “모델 스크립트”가 아니라 제품 시스템이다

현재의 AI 에이전트는 단순히 “사용자가 하나 묻고 모델이 하나 답한다”가 아니다. 실제 에이전트는 대개 다음을 포함한다:

  • LLM API 호출;
  • tool calling / function calling;
  • 다중 턴 작업 상태;
  • 사용자 승인 및 인간 개입;
  • RAG 및 벡터 데이터베이스;
  • 워크플로우 노드;
  • 브라우저 자동화;
  • 파일 읽기/쓰기;
  • 권한 시스템;
  • 과금 시스템;
  • 로그, 트레이싱, 평가, 모니터링;
  • 프론트엔드 UI의 실시간 업데이트.

이것은 더 이상 단순한 모델 엔지니어링이 아니라 완전한 제품 엔지니어링이다.

에이전트가 제품 계층으로 들어가면 TypeScript의 장점이 분명해진다. 왜냐하면 대부분의 사용자 노출형 에이전트 시나리오는 웹 생태계에서 발생하기 때문이다. 채팅 인터페이스, 워크플로우 패널, 브라우저 플러그인, 웹 앱, Electron 데스크톱 앱, VS Code 플러그인, Slack / Discord Bot, API Route, Serverless, Edge Runtime 등.

이 영역의 엔지니어링 주체 언어는 오랫동안 JavaScript / TypeScript였다.

2. TypeScript는 사용자 인터페이스와 이벤트 흐름에 더 가깝다

에이전트는 이벤트 흐름에 크게 의존한다.

실제 에이전트 실행은 보통 한 번의 요청과 한 번의 응답이 아니다. 보통은:

  • 생각하는 동안 출력하고,
  • 출력하는 동안 도구를 호출하고,
  • 사용자 확인을 기다리고,
  • 중간에 취소하거나 재시도하고,
  • 툴 실행 후 상태를 되돌려 쓰고,
  • 프론트엔드에서 중간 단계를 실시간으로 보여주고,
  • 실패했을 때 컨텍스트를 복구하며,
  • 여러 에이전트 또는 여러 워크플로우 노드 간에 결과를 전달한다.

이런 흐름은 웹의 이벤트 모델, stream, WebSocket, Server-Sent Events, UI 상태 관리와 본질적으로 맞닿아 있다.

Python도 물론 비동기를 처리할 수 있고 FastAPI, WebSocket, 백그라운드 작업, 스트리밍 출력 등을 작성할 수 있다. 하지만 에이전트 제품 자체가 웹 앱이라면, TypeScript가 프론트엔드, 백엔드, 툴 스키마, UI 상태, API 타입을 더 쉽게 통합해줄 수 있다.

3. 에이전트는 구조가 깨지면 더 쉽게 망가진다. 모델만 깨지는 게 아니다

많은 사람은 에이전트의 난점이 “모델이 똑똑하지 않다”라고 생각한다. 하지만 실제로 에이전트 시스템을 운영해본 사람은 알게 된다. 모델은 문제의 일부일 뿐이다.

에이전트는 종종 구조적 오류로 실패한다:

  • 툴 파라미터 필드 오기입;
  • JSON 스키마 불일치;
  • API 반환 구조 변경;
  • 메시지 형식 불일치;
  • 워크플로우 상태를 특정 단계에서 망가뜨림;
  • UI 이벤트와 백엔드 상태 불일치;
  • 권한 객체 누락 필드;
  • 다중 턴 복구 시 컨텍스트 왜곡.

에이전트 시스템에는 구조화된 객체가 계속 오가므로, 이 지점에서 타입 시스템은 사치가 아니라 붕괴 확률을 줄이는 인프라다.

TypeScript의 가치는 여기서 드러난다. tool input/output, agent state, message format, workflow node, permission object, external API response 같은 구조를 미리 분명히 정의할 수 있다. 많은 오류가 런타임으로 넘어가서야 발견되지 않고 개발 단계에서 타입 체크로 차단된다.

4. TypeScript는 제품 계층 Agent Runtime에 더 적합하다

당신이 Agent 프레임워크, SDK, 플러그인 시스템, 워크플로우 엔진, 혹은 사용자에게 보이는 런타임을 만들고 있다면 TypeScript의 장점은 더 커진다.

이유는 간단하다. 사용자들은 이 에이전트를 웹, 백엔드 서비스, 브라우저 플러그인, 데스크톱 앱, VS Code 플러그인, Serverless 함수, 기업 시스템에 통합할 가능성이 높다. 이런 시나리오에서 TypeScript 생태계는 훨씬 통합적이다.

그래서 최근 에이전트 생태계에서 TypeScript 프로젝트가 분명히 늘어난 것이다. Vercel AI SDK는 텍스트 생성, 구조화 객체, 툴 호출, 에이전트에 대해 통일된 API를 강하게 내세운다. Mastra는 직접 TypeScript AI Agent 프레임워크로 포지셔닝한다. OpenAI Agents SDK도 Python과 JavaScript / TypeScript 버전을 모두 제공한다.

이는 한 가지 흐름을 보여준다. 에이전트가 더 이상 연구자만을 위한 것이 아니라, 제품팀과 풀스택 개발자를 위한 대상으로 확장되고 있다는 것.

3. Python과 TypeScript는 대체 관계가 아니라 분업 관계다

1. Python은 여전히 모델 계층, 데이터 계층, 실험 계층에 적합하다

TypeScript가 에이전트의 제품 계층에 적합하다고 해서 Python이 덜 중요해지는 것은 아니다.

오히려 여전히 Python은 많은 AI 시스템의 핵심 언어로, 특히 다음에 잘 맞는다:

  • 모델 학습;
  • 데이터 정제;
  • 임베딩 파이프라인;
  • 오프라인 배치 처리;
  • 평가 시스템;
  • 검색 실험;
  • 머신러닝 특성 엔지니어링;
  • 과학 계산;
  • Notebook 프로토타입 검증;
  • PyTorch / TensorFlow / scikit-learn 생태계 연동.

복잡한 텍스트 처리, 모델 평가, 데이터 분석, 벡터 구축, 오프라인 작업이 필요하다면 Python은 매우 자연스러운 선택이다.

2. TypeScript는 제품 계층, 인터랙션 계층, 오케스트레이션 계층에 더 적합하다

TypeScript는 다음 작업군을 맡기 더 적합하다:

  • 프론트엔드 채팅 인터페이스;
  • 에이전트 워크플로우 오케스트레이션;
  • tool 스키마 정의;
  • API Route;
  • 사용자 권한;
  • 과금 및 계정 시스템;
  • 플러그인 시스템;
  • 브라우저 및 IDE 확장;
  • Serverless / Edge 배포;
  • 스트리밍 출력 및 UI 상태 동기화.

사용자에게 실제로 제공되는 에이전트 제품, 특히 웹 제품을 만들 때는 TypeScript를 주력 언어로 두는 편이 더 매끄럽다.

3. 더 현실적인 아키텍처: Python은 능력, TypeScript는 제품을 담당한다

내가 더 동의하는 분업은 이렇다:

  • Python은 모델 계층, 데이터 계층, 평가 계층, 오프라인 작업, 실험 스크립트를 담당한다;
  • TypeScript는 제품 계층, 에이전트 오케스트레이션 계층, 프론트엔드 인터랙션 계층, 플러그인 계층, 사용자 가시 런타임을 담당한다.

이건 누가 이기느냐의 문제가 아니라 AI 애플리케이션이 성숙해지며 자연스럽게 나타나는 엔지니어링 계층화다.

초기 AI = 모델이므로 Python이 주인공이었다.

오늘의 에이전트 = 모델 + 툴 + 상태 + 워크플로우 + UI + 권한 + 배포 + 모니터링이므로 TypeScript의 비중이 커질 수밖에 없다.

4. “에이전트 작성”에서 “에이전트 제품 만들기”로

1. 초기 에이전트는 연구 프로토타입이다

초기 에이전트의 전형적 형태는 Python 스크립트였다:

  • LLM 호출;
  • 모델 출력 파싱;
  • 도구 호출 필요 여부 결정;
  • 툴 결과를 컨텍스트로 되돌림;
  • 모델 추론 계속 수행;
  • 최종 답변 출력.

이러한 시스템은 연구형 프로토타입에 가깝다. 초점은 “돌아가느냐”이지 “안정적으로 사용자에게 서비스하느냐”가 아니다.

2. 신세대 에이전트는 장기 실행 애플리케이션이다

신세대 에이전트는 단일 스크립트가 아니라 장기 실행 애플리케이션 시스템이다.

이것은 사용자 로그인, 권한 경계, 데이터 격리, 작업 복구, 실패 재시도, 도구 감사, 실행 로그, 비용 제어, 모델 전환, 인간 승인, UI 피드백을 처리해야 한다.

따라서 언어 선택은 “어느 언어가 모델 호출에 더 편한가”만으로 결정할 수 없다. 더 살펴봐야 할 것은:

  • 어떤 언어가 제품 인터랙션에 더 적합한가;
  • 어떤 언어가 복잡한 상태 관리를 더 잘 다루는가;
  • 어떤 언어가 프론트엔드와 타입을 공유하기 쉬운가;
  • 어떤 언어가 팀 협업에 유리한가;
  • 어떤 언어가 실제 비즈니스 환경에 배포하기 쉬운가;
  • 어떤 언어가 장기 운영을 더 잘 견디는가.

이것이 바로 TypeScript가 중요해진 근본 원인이다.

5. 개인 개발자를 위한 제안

1. AI 초심자라면 먼저 Python을 배우라

AI를 막 시작했다면, 여전히 Python이 가장 먼저 배울 만한 언어다.

이유는 간단하다. 대부분의 머신러닝 튜토리얼, 데이터 분석 튜토리얼, 모델 학습 코드, Notebook 예제, 오픈소스 모델 프로젝트가 여전히 Python 중심이다. 데이터, 모델, 임베딩, RAG, 평가, 기본 LLM API 호출을 이해하려면 Python이 가장 매끄러운 진입점이다. 스마트 에이전트의 기초, ReAct 패턴, 메모리, RAG, 컨텍스트 엔지니어링을 체계적으로 배우고 싶다면 《Hello-Agents: AI 에이전트를 처음부터 만드는 오픈소스 튜토리얼》을 참고하라.

2. 에이전트 제품을 만들고 싶다면 TypeScript를 필수로 보완하라

목표가 데모를 넘어서 실제 공개 가능한 웹사이트, SaaS, 플러그인, 워크플로우 도구, 온라인 에이전트라면 TypeScript는 거의 피할 수 없다.

프론트엔드 전문가가 될 필요는 없더라도 최소한 이해해야 할 것은:

  • TypeScript 타입 시스템;
  • API 스키마;
  • React / Next.js 기본 구조;
  • streaming response;
  • tool calling의 타입 정의;
  • 프론트엔드와 백엔드 상태 동기화;
  • Serverless / Edge 배포;
  • 웹 제품의 기본 엔지니어링 습관.

이것이 당신의 에이전트가 스크립트에서 제품으로 전환될지를 좌우한다.

3. 에이전트 인프라를 만들고자 한다면 TypeScript를 더 우선시해야 한다

Agent 프레임워크, 워크플로우 시스템, 플러그인 프로토콜, 툴 마켓, 브라우저 자동화 플랫폼, IDE 에이전트, 엔터프라이즈급 에이전트 런타임을 만들고자 한다면 TypeScript의 가치가 더 높다.

이런 것들은 결국 제품팀, 풀스택 엔지니어, 웹 개발자가 통합해 사용하기 때문이다. 타입 시스템, 패키지 생태계, 프론트엔드·백엔드의 통합된 경험 덕분에 에이전트 인프라에서 TypeScript의 존재감은 점점 커진다.

6. 내 판단: 시대의 방향은 “듀얼 스택”이지만 중심은 제품 엔지니어링이다

AI 에이전트에 어떤 언어를 써야 하느냐? 내 대답은 이렇다:

학습과 실험 단계에서는 Python, 제품과 런타임 단계에서는 TypeScript를 중시한다. 진정한 성숙한 에이전트 시스템은 결국 듀얼 스택일 가능성이 크다.

Python은 사라지지 않는다. AI의 모델 계층, 데이터 계층, 실험 계층은 여전히 크게 의존한다.

TypeScript는 계속 중요해질 것이다. 에이전트가 “모델 실험”에서 “제품 엔지니어링”으로 넘어가는 이상, 웹, 플러그인, 워크플로우, IDE, 기업 백오피스, 사용자 인터페이스에 들어가는 곳에서는 TypeScript의 위치는 계속 상승할 수밖에 없다.

그러니 이 논쟁은 겉으로는 Python과 TypeScript의 대결처럼 보이지만, 실제로는 더 큰 질문에 대한 싸움이다:

AI의 전장이 여전히 모델 실험실인가, 아니면 이미 제품 엔지니어링 현장으로 옮겨졌는가?

내 판단은, 모델은 여전히 중요하지만, 단순히 모델을 호출하는 능력은 이제 희소하지 않다는 것이다. 앞으로 진짜 희소한 것은 누가 모델, 도구, 데이터, 권한, UI, 워크플로우, 실제 비즈니스 프로세스를 묶어 안정적으로 사용 가능한 시스템으로 만들어내는가이다.

이것이 AI 에이전트의 시대 방향이다.

자주 묻는 질문

AI 에이전트는 Python을 써야 하나, TypeScript를 써야 하나?

정답은 하나가 아니다. 더 정확히는 분업에 가깝다. 학습과 실험 단계에서는 Python, 제품과 런타임 단계에서는 TypeScript를 중시하고, 성숙한 에이전트 시스템은 대체로 듀얼 스택이다. Python은 모델 / 데이터 / 평가 계층을, TypeScript는 제품 / 오케스트레이션 / 프론트엔드 인터랙션 계층을 맡는 편이 적절하다.

왜 초기 AI 에이전트는 대체로 Python을 썼나?

초기에는 딥러닝, 과학 계산, 모델 학습, 노트북 실험 생태계가 오랫동안 Python을 중심으로 형성되어 있었기 때문이다(NumPy, PyTorch, TensorFlow, scikit-learn). 초기 에이전트의 대부분은 “LLM + Python 글루 코드”로, 프롬프트, 모델 API, 툴 함수, 출력 파싱, 작업 루프를 연결하는 형태였다.

왜 에이전트 제품 계층에서 TypeScript가 점점 더 적합한가?

실제로 사용자에게 제공되는 에이전트는 대개 웹 생태계에서 동작한다. 채팅 인터페이스, 브라우저 플러그인, 워크플로우 패널, IDE 확장, 기업 백오피스 같은 시나리오에서는 타입 시스템, 이벤트 흐름, 프론트엔드·백엔드 스키마 공유, UI 상태 동기화가 필요하다. TypeScript는 프론트엔드, 백엔드, 툴 스키마, API 타입을 더 통일되게 만들어주고, 컴파일 타임에 구조적 오류를 더 빨리 걸러낼 수 있다.

초보자는 어느 언어를 먼저 배워야 하나?

먼저 Python을 배워 AI를 시작하라. 데이터, 모델, 임베딩, RAG, 평가, 기본 LLM API 호출을 이해해야 한다. 그리고 데모를 공개 가능한 웹사이트, SaaS, 플러그인, 온라인 에이전트로 전환할 때 TypeScript를 보강하라.

참고 출처

Share

이 글 공유