AI 에이전트 개발 필수 용어 총정리 (1): 자바스크립트 및 타입스크립트 런타임

Think harder. Think systematically.

[Context]
I am a new junior developer who has absolutely zero background in modern AI agent development and software infrastructure. I have recently joined a development team to build AI agents, but I find myself completely lost when my seniors use terms like 'Bun' or 'pi' as if they are common knowledge. I now need to master the essential vocabulary of AI agent development and its underlying infrastructure to build and manage agents effectively in a software development setting.

I have never studied, practiced, or even casually encountered modern runtimes, package managers, or agentic frameworks. My knowledge in this area is completely blank.

Therefore, do NOT skip over terms, actions, or concepts that a senior software engineer would consider so obvious they go without saying. The things that are "too basic to mention" are precisely what I need explained — the implicit, taken-for-granted knowledge that experts forget is not universal.

[Request]
Create an encyclopedia-level deep-dive terminology dictionary covering these sub-domains: JavaScript and TypeScript Runtimes, Package Managers and Dependency Management, Agentic Orchestration Frameworks, Vector Databases and Memory Management, Execution Environments and Sandboxing, API Integration and Tool Calling.

For each term, explain not just the definition but also: why the term exists (historical or practical origin), how it connects to neighboring concepts, common beginner mistakes or misconceptions, edge cases or exceptions that practitioners know from experience, and how the term is actually used in day-to-day work (not just textbook definitions).

[Output Constraints]

Output Language: ALL output MUST be written in Korean. English original terms should appear in parentheses where they aid understanding (e.g., 런타임(Runtime)).

Output Volume: Use your FULL output token capacity with ZERO abbreviation. Absolute maximum verbosity.

Output Format: Use long-form descriptive paragraphs, NOT short bullet points. No emojis.

Depth: Expand on every nuance, edge case, historical context, and common real-world mistake for each term.

If you reach the output limit, end with ">>> 여기서부터 이어서 작성 <<<" so the user can prompt you to continue.

1부: 자바스크립트 및 타입스크립트 런타임 (JavaScript & TypeScript Runtimes)

런타임(Runtime)이란 무엇인가

런타임(Runtime)이라는 단어는 AI 에이전트 개발 팀에서 매우 빈번하게 등장하지만, 그 뜻을 정확히 모르면 대화 자체가 불가능해진다. 런타임이란 한 마디로 “프로그래밍 언어로 작성된 코드가 실제로 실행될 수 있도록 해주는 소프트웨어 환경”을 의미한다. 좀 더 구체적으로 말하면, 여러분이 작성한 소스 코드(Source Code)는 그 자체로는 컴퓨터가 이해할 수 없는 텍스트에 불과하다. 컴퓨터의 CPU(중앙 처리 장치)는 오직 0과 1로 구성된 기계어(Machine Code)만을 이해하기 때문이다. 런타임은 그 중간 다리 역할을 한다. 즉, 여러분이 작성한 자바스크립트(JavaScript) 코드를 읽어서, 그 의미를 해석하거나 컴파일하여, 실제로 컴퓨터 위에서 동작하게 만드는 전체 생태계가 바로 런타임이다.1

런타임이라는 개념이 생겨난 역사적 배경을 이해하면 왜 이 용어가 지금처럼 중요하게 쓰이는지 알 수 있다. 초기의 프로그래밍 언어, 예를 들어 C언어 같은 경우는 컴파일(Compile), 즉 소스 코드를 기계어로 미리 번역하는 과정을 거친 뒤, 그 번역된 실행 파일을 운영 체제 위에서 직접 실행하는 방식이었다. 이 방식은 속도가 빠른 반면, 각 운영 체제(Windows, Mac, Linux)마다 별도로 컴파일해야 한다는 불편함이 있었다. 이후 자바(Java)를 필두로 “한 번 작성하면 어디서든 실행된다(Write Once, Run Anywhere)”는 철학이 등장하면서, JVM(Java Virtual Machine)이라는 중간 실행 환경이 탄생했다. 자바스크립트 역시 처음에는 웹 브라우저(Web Browser) 안에서만 실행되는 언어였지만, 2009년 Node.js가 등장하면서 처음으로 서버 측에서도 자바스크립트를 실행할 수 있는 독립적인 런타임이 만들어졌다.2

초보 개발자가 가장 흔히 혼동하는 것 중 하나는 “런타임”과 “프레임워크(Framework)”를 동일하게 취급하는 것이다. 프레임워크는 어떤 애플리케이션을 만들기 위해 미리 구성된 코드의 집합이지만, 런타임은 그 코드를 실행시켜주는 기반 환경이다. 예를 들어 Node.js는 런타임이고, Express.js나 NestJS 같은 것은 Node.js 런타임 위에서 동작하는 프레임워크다. 실무에서 “우리 프로젝트는 Bun 런타임을 쓴다”라고 말할 때, 그것은 프레임워크가 아니라 코드를 실행하는 엔진 자체를 무엇으로 선택했느냐를 말하는 것이다. 또 다른 흔한 실수는 런타임을 단순히 “설치된 언어”와 혼동하는 것이다. 예를 들어 파이썬(Python)을 설치한다는 것은 파이썬 런타임을 설치하는 것이고, Node.js를 설치한다는 것은 자바스크립트 런타임을 설치하는 것이다.3

Node.js

Node.js는 2009년 라이언 달(Ryan Dahl)이 만든 자바스크립트 서버 런타임으로, AI 에이전트 개발 생태계에서 사실상 기본 전제처럼 취급되는 소프트웨어다. Node.js가 등장하기 이전까지 자바스크립트는 오직 웹 브라우저 안에서만 실행될 수 있었다. 웹 페이지를 볼 때 버튼 클릭에 반응하게 만들거나, 폼 입력값을 검사하거나, 애니메이션을 추가하는 등의 용도로만 쓰였던 것이다. 라이언 달은 구글 크롬(Google Chrome) 브라우저의 자바스크립트 엔진인 V8(V8 Engine)을 분리해내어, 브라우저 없이도 자바스크립트 코드를 직접 실행할 수 있는 환경을 만들었다. 이로써 개발자들은 자바스크립트 하나만으로 웹 브라우저(클라이언트)와 서버(백엔드) 양쪽을 모두 개발할 수 있게 되었고, 이것이 Node.js의 역사적 혁신이었다.4

Node.js의 핵심 동작 원리는 “비동기 이벤트 루프(Asynchronous Event Loop)”다. 이것은 처음에는 이해하기 어려운 개념이지만, AI 에이전트 개발에서 빈번하게 마주치므로 반드시 이해해야 한다. 예를 들어, 여러분이 API를 통해 OpenAI의 GPT 모델에 요청을 보낸다고 상상해보자. 그 응답이 오기까지 2~3초가 걸릴 수 있다. 일반적인 동기식(Synchronous) 방식에서는 그 응답이 오기를 기다리는 동안 모든 다른 작업이 멈춰버린다. 하지만 Node.js는 비동기(Asynchronous) 방식으로 동작하기 때문에, 응답을 기다리는 동안 다른 요청을 처리하거나 다른 작업을 수행하고, 응답이 도착하면 그때 이벤트 루프가 해당 콜백(Callback) 함수를 호출하여 처리한다. 이것이 Node.js가 수많은 동시 접속을 효율적으로 처리할 수 있는 이유다.

실무에서 Node.js의 버전 관리는 매우 중요한 일상적 과제다. Node.js는 짝수 버전이 LTS(Long Term Support), 즉 장기 지원 버전으로, 안정성이 보장되고 기업 환경에서 권장된다. 홀수 버전은 최신 기능이 먼저 도입되지만 빠르게 지원이 종료된다. 팀 프로젝트에서 동료 A는 Node.js 18을 쓰고 자신은 Node.js 20을 쓰면 어떤 기능의 동작 방식이 미묘하게 달라지거나 패키지 호환성 문제가 발생하는 일이 생긴다. 이를 해결하기 위해 .nvmrc 파일이나 .node-version 파일을 프로젝트 루트에 두어 프로젝트가 요구하는 Node.js 버전을 명시하는 관행이 생겼다. NVM(Node Version Manager)이라는 도구를 사용하면 컴퓨터 한 대에 여러 버전의 Node.js를 동시에 설치하고 프로젝트마다 다른 버전을 사용할 수 있다.5

Deno

Deno는 Node.js의 창시자인 라이언 달이 2018년 발표하고 2020년 정식 출시한 두 번째 자바스크립트/타입스크립트 런타임이다. 이름 자체가 “Node”의 철자를 뒤집은 것(“De-no → De, no → Deno”)으로, 이전 작품의 문제를 반성하고 처음부터 다시 설계했다는 의미를 내포한다. 라이언 달은 2018년 JSConf EU(자바스크립트 컨퍼런스)에서 “Node.js에 관해 내가 후회하는 10가지”라는 유명한 발표를 통해 Node.js가 가진 구조적 문제들, 예를 들어 보안 모델의 부재, npm의 복잡성, package.json의 설계 방식 등을 공개적으로 비판한 뒤 Deno 개발을 시작했다.6

Deno의 가장 큰 특징 중 하나는 타입스크립트(TypeScript)를 기본으로 지원한다는 점이다. Node.js에서 타입스크립트를 실행하려면 별도의 변환 과정이 필요하지만(후술), Deno는 타입스크립트 파일을 추가 설정 없이 곧바로 실행할 수 있다. 또 다른 혁신은 보안 모델이다. Node.js에서는 작성된 프로그램이 기본적으로 컴퓨터의 파일 시스템, 네트워크, 환경 변수 등 모든 것에 접근할 수 있었다. 이는 악성 패키지나 잘못된 코드가 시스템 전체에 피해를 줄 수 있는 위험이 있었다. Deno는 반대로, 기본적으로 아무 것도 허용하지 않고 명시적으로 권한을 부여해야 한다. 예를 들어 파일에 접근하려면 –allow-read 플래그를, 네트워크 요청을 하려면 –allow-net 플래그를 실행 명령에 추가해야 한다.7

실무에서 Deno는 Node.js만큼 광범위하게 채택되지는 않았지만, Deno가 제시한 아이디어들, 즉 타입스크립트 기본 지원, URL을 통한 모듈 임포트, 보안 퍼미션 모델 등은 자바스크립트 생태계 전반에 영향을 미쳤다. AI 에이전트 팀에서 Deno를 선택하는 경우는 주로 보안이 매우 중요한 환경이거나, 최신 웹 표준 API를 최대한 활용하고 싶을 때다. 초보 개발자가 흔히 하는 실수는 Deno 환경에서도 npm의 node_modules 폴더가 생성될 것을 기대하는 것이다. Deno는 기본적으로 URL에서 직접 모듈을 다운로드하고 글로벌 캐시(Cache)에 저장하는 방식을 사용하므로, 프로젝트 폴더 안에 node_modules 폴더가 생기지 않는다. 다만 Deno v2부터는 호환성을 위해 npm 패키지도 지원한다.

Bun

Bun은 2022년 자레드 서머(Jarred Sumner)가 개발하고 2023년 정식 버전을 출시한, 현재 자바스크립트 생태계에서 가장 빠르게 성장하는 런타임이다. 팀 시니어들이 “Bun”을 아무 설명 없이 언급하는 것은, 이 도구가 2024~2025년 사이에 AI 개발 커뮤니티를 중심으로 사실상 표준처럼 자리잡았기 때문이다. Bun이 혁명적인 이유는 단순히 빠른 런타임이어서가 아니라, 기존에는 여러 개의 분리된 도구가 담당하던 역할들을 단 하나의 바이너리(Binary, 실행 파일)로 통합했기 때문이다.8

구체적으로 Bun은 단일 설치로 런타임(코드 실행), 패키지 매니저(패키지 설치), 번들러(Bundler, 여러 파일을 하나로 합치는 도구), 테스트 러너(Test Runner, 코드 자동 테스트 도구), 개발 서버를 모두 제공한다. 기존에는 Node.js로 프로젝트를 시작하면, 코드 실행은 Node.js, 패키지 설치는 npm 혹은 yarn 혹은 pnpm, 번들링은 Webpack(웹팩) 혹은 esbuild, 테스트는 Jest, 타입스크립트 변환은 ts-node 혹은 tsx 같은 별도 도구를 각각 따로 설치하고 설정해야 했다. Bun은 이 모든 것을 하나로 합쳐버렸다. Midjourney같은 대형 AI 기업이 Bun을 실서비스에 채택하고 있으며, Vercel도 Bun 런타임 지원을 베타로 추가했다.9

Bun이 이처럼 빠른 이유는 기술적 선택에 있다. Node.js와 Deno는 구글의 V8 엔진을 사용하지만, Bun은 애플(Apple)이 사파리(Safari) 브라우저를 위해 개발한 JavaScriptCore(JSC) 엔진을 사용한다. JSC는 특히 시작 시간(Start-up Time)과 메모리 사용량에서 V8보다 유리한 특성을 갖는다. 더불어 Bun 자체는 Zig라는 저수준 시스템 프로그래밍 언어로 작성되었는데, 이는 C언어처럼 메모리를 직접 관리할 수 있어 훨씬 미세한 성능 최적화가 가능하다. 그 결과 HTTP 서버 성능 기준으로 Bun은 Node.js의 약 4배에 달하는 처리량(Throughput)을 보이며, 패키지 설치 속도는 npm 대비 최대 30배 이상 빠르다.1011

초보 개발자가 Bun을 처음 접할 때 가장 많이 하는 실수는 “Bun은 Node.js를 완전히 대체하는가?”라는 질문에 “예스”라고 가정하고 기존 Node.js 코드를 아무 검증 없이 Bun으로 전환하는 것이다. Bun은 Node.js 호환성 레이어(Compatibility Layer)를 제공하여, 대부분의 Node.js 코드가 그대로 동작하지만, 2025년 말 기준으로 Node.js 테스트 스위트의 약 75~90%만 통과한다. 즉, 일부 Node.js 전용 네이티브 모듈이나 특정 스트림(Stream) API, 자식 프로세스(Child Process) 관련 기능은 아직 완전히 지원되지 않을 수 있다. 따라서 새 프로젝트에서는 Bun을 적극 채택하되, 기존 대형 Node.js 레거시 프로젝트를 마이그레이션할 때는 반드시 테스트 스위트를 모두 통과하는지 확인해야 한다.12

실무에서 Bun은 AI 에이전트 프로젝트에서 특히 유용한데, 그 이유는 에이전트 특성상 서버 시작/종료가 빈번하고, LLM API 호출, 데이터베이스 쿼리, 파일 시스템 작업 등 다양한 비동기 입출력(I/O)이 동시다발적으로 발생하기 때문이다. Bun의 빠른 시작 시간과 높은 I/O 처리량은 이러한 에이전트 특성에 매우 잘 맞는다. 또한 Bun이 타입스크립트를 추가 설정 없이 네이티브로 지원하므로, AI 에이전트 팀에서 타입스크립트로 작성된 에이전트 코드를 즉시 실행할 수 있어 개발 생산성이 크게 향상된다.13

타입스크립트(TypeScript)와 자바스크립트(JavaScript)의 관계

자바스크립트(JavaScript)는 1995년 넷스케이프(Netscape) 브라우저를 위해 단 10일 만에 만들어진 언어다. 빠르게 만들어진 만큼 설계상의 허점이 많고, 특히 “타입(Type)”이 없다는 것이 가장 큰 단점이다. 자바스크립트에서 변수는 숫자도 됐다가 문자열도 됐다가 객체도 됐다가 자유롭게 바뀔 수 있으며, 이 유연함 때문에 대규모 프로젝트에서 디버깅이 매우 어려워진다. 예를 들어 어떤 함수가 숫자를 받아야 하는데 문자열을 실수로 전달해도, 자바스크립트는 아무 경고 없이 그냥 실행되다가 예상치 못한 곳에서 버그가 터진다.

타입스크립트(TypeScript)는 마이크로소프트(Microsoft)가 2012년에 발표한 언어로, 자바스크립트의 완전한 상위 집합(Superset)이다. 즉, 모든 자바스크립트 코드는 곧 타입스크립트 코드이기도 하다. 타입스크립트는 자바스크립트에 정적 타입(Static Type) 시스템을 추가한 것으로, 변수나 함수의 인자, 반환값의 타입을 코드에 명시하여 컴파일 시점에 타입 오류를 미리 잡아낼 수 있게 해준다. AI 에이전트 개발에서 타입스크립트가 선호되는 이유는 에이전트가 수행하는 작업의 복잡성 때문이다. LLM의 응답 구조체, 도구 호출 파라미터, 벡터 데이터베이스에서 반환되는 문서 객체 등 다양한 복잡한 데이터 구조를 다룰 때, 타입스크립트의 타입 시스템이 실수를 미리 방지해준다.

중요한 점은, 타입스크립트는 직접 실행되지 않는다는 것이다. 타입스크립트 코드는 최종적으로 자바스크립트로 변환(트랜스파일, Transpile)되어야만 실행될 수 있다. 이 변환 과정을 담당하는 도구가 tsc(TypeScript Compiler)이다. 그러나 위에서 언급했듯이, Bun과 Deno는 이 변환 과정을 내부적으로 자동 처리하여 개발자가 직접 tsc를 실행하지 않아도 타입스크립트 파일을 바로 실행할 수 있다. Node.js 환경에서는 ts-node, tsx, 혹은 esbuild 같은 별도 도구를 설치해야 타입스크립트를 직접 실행할 수 있다.

트랜스파일(Transpile)과 컴파일(Compile)의 차이

트랜스파일(Transpile)이라는 단어는 처음 들으면 생소하지만, AI 에이전트 개발 과정에서 빌드 파이프라인(Build Pipeline)을 설정할 때 반드시 이해해야 하는 개념이다. 컴파일(Compile)은 보통 고수준 언어(예: C, 자바)를 저수준 기계어 또는 바이트코드로 변환하는 것을 의미한다. 반면 트랜스파일은 같은 수준의 언어에서 다른 언어로, 혹은 같은 언어의 다른 버전으로 변환하는 것을 의미한다. 타입스크립트를 자바스크립트로 변환하는 것이 트랜스파일의 전형적인 예다. 둘 다 코드를 변환한다는 점은 같지만, 변환의 추상화 수준(Level of Abstraction)이 다르다.

실무에서 트랜스파일은 다음과 같은 상황에 등장한다. 개발팀이 최신 자바스크립트 문법(예: ESNext 기능)을 사용해 코드를 작성하면, 그 코드는 구버전 Node.js나 구버전 브라우저에서는 실행되지 않을 수 있다. 이때 Babel(바벨)이나 esbuild, SWC 같은 트랜스파일러가 최신 문법을 구버전에서도 동작하는 코드로 자동 변환해준다. AI 에이전트 프로젝트에서 패키지를 배포하거나 엣지(Edge) 환경에 배포할 때 트랜스파일 설정이 잘못되면 “Unexpected Token” 오류나 “Cannot use import statement” 오류가 자주 발생한다. 이는 ESM(ECMAScript Modules)과 CJS(CommonJS Modules)라는 두 가지 자바스크립트 모듈 시스템의 충돌 때문인 경우가 많다.

ESM(ECMAScript Modules)과 CJS(CommonJS Modules)

자바스크립트에서 “모듈(Module)”이란 코드를 여러 파일로 나눠서 관리하는 방식이다. 한 파일에서 작성한 함수나 변수를 다른 파일에서 가져다 쓰는 것이 모듈 시스템의 핵심이다. 그런데 이 모듈 시스템이 역사적으로 두 가지 방식으로 나뉘어져, 현재까지도 개발자들에게 끊임없는 혼란을 야기하고 있다.

CommonJS(CJS)는 Node.js가 초기에 도입한 모듈 시스템으로, require() 함수와 module.exports를 사용한다. 예를 들어 어떤 함수를 다른 파일에서 불러오려면 const myFunction = require(‘./myModule’) 와 같이 작성한다. ECMAScript Modules(ESM)는 자바스크립트 언어 표준 기관인 TC39(ECMAScript 위원회)가 제정한 공식 모듈 시스템으로, import와 export 키워드를 사용한다. import { myFunction } from ‘./myModule.js’ 와 같은 형태다. ESM은 브라우저와 서버 양쪽에서 동일하게 동작하도록 설계된 공식 표준이며, 현재 새 프로젝트에서는 ESM을 사용하는 것이 권장된다.

문제는 이 두 시스템이 완전히 호환되지 않는다는 것이다. AI 에이전트 프로젝트에서 npm을 통해 설치한 어떤 패키지는 CJS 형식으로만 배포되고, 또 다른 패키지는 ESM 전용이며, 어떤 것들은 둘 다 지원한다. 그리고 이 두 시스템을 혼용할 때 예상치 못한 오류들이 발생한다. 예를 들어 “ERR_REQUIRE_ESM” 오류는 CJS 환경(require 방식)에서 ESM 전용 패키지를 불러오려 할 때 발생한다. 이 오류를 처음 마주한 초보 개발자들은 대개 무엇이 문제인지 파악조차 하지 못하고 여러 시간을 낭비한다. 해결책은 package.json에 “type”: “module”을 추가하거나, 파일 확장자를 .mjs(ESM) 또는 .cjs(CJS)로 명시하거나, 번들러 설정에서 출력 형식을 맞추는 것이다.