수십억 개의 토큰을 낭비하지 않고도 엔터프라이즈 코드를 탐색할 수 있도록 에이전트형 AI (Agentic AI)를 활용하세요.

$5,000의 질문

평균적인 엔지니어링 작업을 수행하는 데 수십억 개의 토큰을 소비하려면 1억 개의 토큰 컨텍스트 윈도우 (Context Window)가 필요했습니다. 오늘날의 프런티어 모델 (Frontier Model) 가격을 기준으로 하면, 단일 작업에 약 $5,000가 소요됩니다.

이것은 AI 에이전트 (AI Agent)를 사용하여 평균적인 복잡성을 가진 평균적인 엔터프라이즈 소프트웨어인 Magento (Adobe Commerce)에서 작업하는 데 필요한 비용에 대한 저의 대략적인 추정치였습니다. 제가 어떻게 이 결론에 도달했는지 설명하겠습니다.

LLM (Large Language Models)은 프롬프트 (Prompts)를 통해 입력을 받습니다. 의존성(Dependencies)을 포함한 새로 설치된 Magento는 약 66,000개의 XML 및 PHP 파일로 구성됩니다. 이는 대략 3억 500만 자, 즉 약 1억 개의 토큰에 해당합니다. 이것은 대화의 첫 메시지일 뿐입니다. 대부분의 LLM은 전체 컨텍스트 윈도우 (Context Window)를 100만 토큰으로 제한하므로, 우리는 이미 두 자릿수(two orders of magnitude)만큼 차이가 납니다. 그리고 상황은 더 악화됩니다. 새로운 프롬프트가 추가될 때마다 그 1억 개의 토큰이 계속 쌓입니다. 10라운드만 진행해도 10억 개의 토큰을 소비하게 됩니다.

이를 완화할 수는 있습니다. 턴(Turn) 사이의 토큰 재사용을 캐싱 (Caching)하면 소비되는 토큰을 2억 개까지 줄일 수 있겠지만, 컨텍스트 윈도우 (Context Window) 자체에는 여전히 약 80 TB의 RAM이 필요합니다.

100,000,000 tokens × 0.8 MB ≈ 80 TB of KV cache

따라서 요구 사항은 실재합니다: 1억 개의 토큰 컨텍스트 윈도우 (Context Window), 80 TB의 메모리. 기술은 아직 그 수준에 도달하지 못했으며, 에너지의 유한한 특성을 고려할 때 우리 생애 동안에는 도달하지 못할 수도 있습니다.

진짜 문제: 메모리가 없음

하지만 덜 순진하게 접근하고 더 비판적으로 생각해보면, 다른 문제가 발생합니다. LLM은 메모리가 없습니다. 이들은 상태가 없는 뇌 (Stateless brains)입니다. 이들에게 메모리를 부여하기 위해 현재는 단 두 가지 해결책만이 존재합니다.

첫 번째는 명백한 방법입니다. Magento를 기반으로 LLM (Large Language Model)을 학습시키는 것입니다. 이미 Google의 Gemma, Qwen, DeepSeek와 같이 역량 있는 오픈 웨이트 (open-weight) 모델들이 존재합니다. 문제는 데이터입니다. 소스 코드만으로는 충분하지 않습니다. 설명(descriptions), 문서(documentation), 아키텍처(architecture) 이면의 추론 과정, 코드베이스(codebase)에 대한 전체적인 기록, 그리고 비즈니스 요구사항(business requirements)과 결합된 가능한 한 많은 실제 커스텀 사례들이 필요합니다. 실제로 이러한 모델을 학습시키려는 사람은 에이전시가 지난 10년 동안 수행한 Magento 작업들을 재구성해야 할 것입니다. 커밋(commits)과 그 소스 코드, 각 비즈니스 요구사항을 정의하는 티켓(tickets), 심지어 공백을 메우기 위한 회의 녹취록까지 말입니다. 그런 데이터는 존재하지 않습니다.

모든 기업 내부를 들여다볼 수는 없지만, 대부분의 조직에서는 의사결정 과정이 추적되거나 기록되지 않는다는 점은 상당히 확신할 수 있습니다. 거대 자본이 소규모 에이전시들을 인수하여 투자 목적으로 데이터를 수집한 뒤, 코드와 비즈니스가 만나는 비즈니스 특화 LLM을 구축하는 시나리오를 상상해 볼 수 있을 것입니다. 하지만 오직 Magento만을 위해 그렇게 하는 것은 ROI (투자 대비 수익)가 낮을 가능성이 크며, 여러 플랫폼에 걸쳐 동시에 진행하는 것은 노이즈(noise)를 생성할 위험이 있습니다. 따라서 오늘날 이 옵션은 사실상 존재하지 않습니다. 재정적으로 너무 위험합니다.

두 번째 옵션이자 제가 선택한 방법은 더 안전한 방법입니다. 제한된 예산으로 인해 고품질의 자체 모델을 학습시킬 수 없고 10억 개의 토큰 (tokens)을 입력할 수 없다면, 직접 메모리 (memory)를 구축하면 됩니다. 잊지 않는 무언가를 말이죠.

잊지 않는 무언가를 구축하기

상태가 없는 (stateless) LLM에 자체적인 메모리를 부여하는 것은 새로운 아이디어가 아닙니다. 초기 AI들은 심볼릭 (symbolic) AI였습니다. 즉, 시스템이 루프를 돌며 처리하는 결정론적 데이터 (deterministic data)의 거대한 구조였으며, 이를 심볼릭 추론 (symbolic reasoning)이라고 부릅니다. 가장 유명한 사례는 IBM의 Deep Blue였습니다.

(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fgwhs19dmw7y3yt47bj9a.png)

제가 관찰한 바에 따르면, OpenAI나 Anthropic과 같은 현대적인 AI 네이티브 기업들은 더 많은 데이터로 학습된 점점 더 거대한 LLM(Large Language Models)을 통해 우월한 지능에 도달할 수 있다고 주장합니다. Google과 같은 다른 플레이어들은 다른 경로를 택하는 것으로 보입니다. 그들의 모델은 종종 덜 똑똑하게 느껴지지만, 더 많은 것들과 연결되어 있습니다. 그들이 작동하는 방식을 살펴보면 대부분의 답변이 문서, 이메일, 웹사이트와 같이 동적으로 가져온 리소스에서 나온다는 것을 알 수 있습니다. 그들은 이를 그라운딩 (grounding)이라고 부릅니다. 모델을 정확한 소스에 결합하여, 창의성은 다소 떨어지더라도 더 근거가 확실한 (better-grounded) 응답을 제공하도록 하는 것입니다.

엔지니어링에서 그라운딩 (grounding)은 매우 중요합니다. 종종 어느 정도의 환각 (hallucination)에서 비롯되는 창의성도 제 역할이 있지만, 소프트웨어에서는 정밀함 (precision)이 핵심입니다.

Claude, Codex, Antigravity와 같은 AI 에이전트들은 프로젝트의 디렉토리 구조를 인덱싱하고, 정규 표현식 (regex) 및 키워드 매칭으로 검색한 다음, 수많은 파일을 무작정 읽어 들임으로써 그라운딩 (grounding)에 도달하려 합니다. 이 과정에서 많은 토큰 (tokens)을 소모하면서도 여전히 무언가를 놓치곤 합니다. 이는 RAG (Retrieval-Augmented Generation, 검색 증강 생성)의 한 형태이지만, 제 생각에는 올바른 방식은 아닙니다.

소스 코드는 하나의 우주입니다

코드가 실제로 무엇인지 생각해 보십시오. 클래스 (class)는 인터페이스 (interfaces)를 구현하고, 부모를 상속 (extends)하며, 트레이트 (traits)를 사용합니다. 메서드 (methods)는 또 다른 클래스들을 가리키는 파라미터 (parameters)와 반환 타입 (return types)을 선언합니다. 패키지 (packages)는 패키지에 의존합니다. 코드는 단순히 파일들의 더미가 아닙니다. 그것은 관계들의 조밀한 망 (web)입니다. 그리고 데이터가 이미 노드 (nodes)와 연결 (connections)의 망 형태를 띠고 있다면, 그래프 (graph)는 단순히 데이터를 저장하는 한 가지 방법이 아니라, 데이터가 이미 가지고 있는 형상 그 자체입니다. 따라서 그래프 데이터베이스 (graph database)가 자연스러운 선택이었으며, 그로부터 정보를 검색하는 것이 사람들이 말하는 GraphRAG입니다. 그것이 제가 시작한 지점입니다.

목표는 크로스 플랫폼(cross-platform) 데스크톱 앱을 만드는 것이었습니다. 사용자가 이를 설치하고 자신의 AI 에이전트(agent)에 MCP 서버(server)로 연결하면, 그 이후부터 에이전트는 이를 하나의 도구(tool)로 취급합니다. 즉, 코드를 탐색해야 할 때마다 무작정 grep을 실행하거나 파일을 읽는 대신 그래프(graph)에 쿼리(query)를 날리는 것입니다. 그래프가 소스 코드의 완전한 지도 역할을 하기 때문에, LLM이 탐색할 수 있는 하나의 세계가 됩니다. 프롬프트(prompt)에 단 하나의 원본 파일도 로드하지 않고도, 클래스(class)에서 인터페이스(interface)로, 이를 선언하는 패키지(package)로, 그리고 메서드(method)가 소비하는 타입(type)으로 이동할 수 있습니다. 그런데 왜 데스크톱 앱일까요? 그 세계를 시각화하는 것 자체가 처음부터 구상했던 비전의 일부였기 때문입니다. 그것이 바로 컨셉(concept)이었습니다.

엔지니어링의 성공과 실패 (Engineering hits and misses)

저는 Node.js와 함께 제공되는 Chromium 기반 데스크톱 프레임워크인 Electron과 React를 선택했습니다. 첫 번째 장벽은 거의 즉각적으로 나타났습니다. 바로 PHP를 파싱(parsing)하는 문제였습니다. JavaScript나 TypeScript에는 제대로 된 PHP 파서(parser)가 없습니다. 성숙하고 정확한 파서(nikic/php-parser)는 PHP 자체로 작성되어 있습니다. 그래서 계획은 PHP 바이너리(binary)를 정적 컴파일(statically compile)하여 앱 내부에 포함시키고, 실제 PHP가 PHP 소스를 파싱하게 만드는 것이었습니다. 그래프 데이터베이스(graph database)로는 현대적인 임베디드 엔진(embedded engine)인 LadyBug를 선택했습니다. 임베디드(Embedded)라는 것은 사용자가 별도로 설치하거나 관리할 서버 없이 앱 자체의 프로세스(process) 내에서 실행됨을 의미합니다.

프로토타입의 끝에 다다를수록, 문제는 코드에서 배포(distribution)로 옮겨갔습니다. 번들링된 바이너리(bundled binary)를 배포한다는 것은 PHP 실행 파일과 앱 자체 모두에 서명(signing)을 해야 함을 의미하며, Windows와 macOS 모두에서 코드 서명(code signing)은 사실상 필수적입니다. 이는 매년 갱신해야 하는 유료 인증서와 더불어, 매 릴리스 전 테스트를 위해 플랫폼당 한 대씩 총 세 대의 기기가 현실적으로 필요함을 뜻합니다. 개념 증명(Proof of Concept, PoC) 단계에서 이는 너무 과했습니다. 배포에 드는 비용이 제품 자체보다 더 많은 시간을 잡아먹을 판이었습니다.

그래서 저는 다른 방식의 배포로 방향을 틀었습니다. 동일한 기능을 수행하는 단순한 PHP 패키지(package) 방식입니다. 하지만 그것이 가능할까요? 즉각적인 결격 사유가 발견되었습니다. PHP를 위한 사용 가능한 임베디드 그래프 데이터베이스(embedded graph database)가 전혀 없다는 점이었습니다. 단 하나도 없었습니다. 한 가지 우회 방법은 패키지를 분리하는 것이었습니다. MCP 서버와 그래프 연결을 위한 Node.js CLI, 파싱을 위한 PHP 컴포넌트, 그리고 시각화를 위한 React UI로 나누는 것이죠. 하지만 그 시점에서 이 "패키지"는 사실 패키지인 척하는 다중 언어 스택(multi-language stack)에 불과했습니다. 차라리 이 상황과 싸우는 것을 멈추고, 전체를 도커화된(dockerized) 서버 측 프로젝트로 취급하는 것이 훨씬 합리적이었습니다.

도커(Docker) 프로젝트로 전환하면서 하위 패키지들은 서비스(services)가 되었고, Neo4j가 임베디드 데이터베이스를 대체했습니다. 이를 하나로 엮기 위해서는 프론트엔드(frontend), 백엔드(backend), 워커(worker), PostgreSQL, 큐(queue)를 포함한 완전한 서버 측 시스템이 필요했습니다. 저의 단순했던 데스크톱 도구는 이제 성장 가능성이 무궁무진한 작은 분산 시스템(distributed system)이 되었습니다.

목적지는 같지만, 길은 다르다

“내 AI에게 뇌를 주어야 한다”라는 결론에 도달한 사람은 저뿐만이 아닙니다. 점점 더 많은 엔지니어와 과학자들이 자신들의 LLM(Large Language Model)을 위한 메모리(memory)를 구축하고 있습니다. 여기에는 Andrej Karpathy도 포함되는데, 그는 “LLM 위키(LLM wiki)”를 운영합니다. 이는 서로 연결된 일반 Markdown 노트들로 구성되며, 그는 자신의 AI가 자신의 지식을 탐색할 수 있도록 Obsidian에서 브라우징하는 그래프(graph)를 형성합니다. 우아한 아이디어이지만, 복잡한 코드를 매핑하기에는 그러한 노트 및 링크(notes-and-links) 방식은 너무 기초적입니다.

개념 증명 (Proof of concept): Magentic

Magentic의 개념 증명(proof-of-concept) 버전은 표준 Model Context Protocol을 통해 모든 AI 에이전트(Anthropic의 Claude, OpenAI의 Codex, Google의 Antigravity 등)에 연결됩니다. 이 도구는 소스 코드를 스캔하고 그래프 데이터베이스(graph database) 내부에 이를 기반으로 한 세계를 구축합니다. 그런 다음, 에이전트가 사용자로부터 작업을 받으면, 수많은 파일을 토큰화(tokenizing)할 필요 없이 해당 그래프를 들여다보고 코드베이스를 효율적으로 탐색할 수 있습니다. 각각의 자연어(natural-English) 질문은 에이전트가 이해할 수 있는 그래프 결과로 변환되며, Magentic의 UI는 그 결과를 시각화된 노드(nodes)와 연결(connections) 세트로 보여줄 수 있습니다.

제가 이 프로젝트의 이름을 Magentic이라고 지은 이유는 현재 Magento, MageOS, 그리고 Adobe Commerce를 타겟으로 하고 있기 때문이며, 이들은 엔터프라이즈급 규모와 복잡성을 고려할 때 완벽한 대상입니다. 하지만 이러한 아키텍처(architecture)를 통해 GraphQL 매핑, DI 매핑, 플러그인(plugin) 매핑 등으로 확장할 수 있는 문이 열려 있으며, 어쩌면 새로운 플랫폼으로도 확장될 수 있습니다.

우리가 테라바이트급 메모리를 가진 노트북이나 1억 개의 토큰 컨텍스트 윈도우(context windows)에 도달하기 훨씬 전이라도, AI 워크플로(workflows)를 효율적으로 만들기 위해 구축해야 할 것들은 아주 많습니다.