백엔드 엔지니어링에서 에이전틱 AI (Agentic AI)로의 자연스러운 진화, 그리고 왜 Elixir가 당신이 필요로 하는 줄 몰랐던 런타임(Runtime)인가

면책 조항: 여기에 표현된 견해는 실무 경험을 바탕으로 한 개인적인 의견과 해석을 반영합니다. 이는 커뮤니티 연구 및 산업 관행에 의해 뒷받침되지만, 절대적인 진리가 아닌 저의 관점을 나타냅니다. AI 엔지니어링은 빠르게 진화하고 있으며, 오늘 현재의 것이 내일은 구식이 될 수 있습니다.

지난 몇 년 동안 소프트웨어 엔지니어링(Software Engineering) 분야에 계셨다면, 무어의 법칙(Moore's Law)이 여유롭게 느껴질 정도의 속도로 AI 지형이 발밑에서 변화하는 것을 목격하셨을 것입니다. 영리한 프롬프트(Prompt)를 만드는 신기한 기술로 시작된 것은 이제 자체적인 아키텍처(Architecture), 패턴(Pattern), 패러다임(Paradigm)을 갖춘 완전한 엔지니어링 학문으로 성숙했습니다.

최근 주간 개발자 공유 세션에서, 저는 이러한 진화에 대한 저의 견해와 왜 백엔드 엔지니어들이 이 다음 물결을 이끌 독보적인 위치에 있다고 믿는지, 그리고 왜 Elixir와 BEAM VM이 차세대 AI 시스템을 위한 가장 매력적인 플랫폼 중 하나로 조용히 부상하고 있는지에 대해 발표했습니다. 이 포스트는 그 강연의 확장 버전입니다.

프롬프트 엔지니어링(Prompt Engineering)에서 에이전틱 AI (Agentic AI) 시스템으로 이어지는 여정을 살펴보며, 왜 여러분의 백엔드 엔지니어링 기술이 그 어느 때보다 중요한지 알아보겠습니다.

AI 엔지니어링의 진화

시야를 넓혀 AI 애플리케이션 개발의 궤적을 살펴보면, 각각이 이전 단계를 기반으로 구축된 네 가지 뚜렷한 시대를 식별할 수 있습니다.

1. 프롬프트 엔지니어링 (Prompt Engineering) (2022–2024)

핵심 질문: "모델에게 무엇을 말해야 하는가?"

이 시기는 완벽한 프롬프트를 만드는 시대였습니다. 우리는 챗봇(Chatbot)과 코파일럿(Copilot)을 구축했으며, 엔지니어링 작업은 사고의 사슬 (Chain-of-Thought (CoT)), ReAct, 퓨샷 프롬프팅 (few-shot prompting), 역할 수행 (role-playing)과 같은 기술을 중심으로 이루어졌습니다. 초점은 전적으로 입력(Input)에 맞춰져 있었습니다. 즉, LLM이 가능한 최선의 출력을 제공하도록 어떻게 문구를 구성할 것인가에 집중했습니다.

2. 컨텍스트 엔지니어링 (Context Engineering) (2025)

**핵심 질문: "모델에게 어떤 정보를 제공해야 하는가?"

모델의 능력이 향상됨에 따라, 우리는 프롬프팅 (Prompting)만으로는 충분하지 않다는 것을 깨달았습니다. 진정한 차별점은 모델에 어떤 컨텍스트 (Context)를 제공하느냐가 되었습니다. 이는 RAG (Retrieval-Augmented Generation, 검색 증강 생성) 시스템과 근거 기반의 어시스턴트 (Grounded Assistants)의 등장으로 이어졌습니다. 엔지니어링의 초점은 정보 아키텍처 (Information Architecture)로 이동했습니다. 즉, 적절한 정보를 적절한 시점에 어떻게 검색(Retrieve), 순위 지정(Rank), 청킹(Chunk), 그리고 전달(Deliver)할 것인가의 문제로 옮겨간 것입니다.

3. AI 에이전트 (AI Agents) (2025–2026)

핵심 질문: "어떻게 자율성을 부여할 것인가?"

시스템 관점에서 상황이 흥미로워지기 시작한 지점입니다. 우리는 단발성 상호작용 (Single-turn interactions)에서 벗어나, 루프 (Loop) 안에서 추론(Reason), 행동(Act), 관찰(Observe)을 수행할 수 있는 단일 자율 에이전트 (Single autonomous agents)로 이동했습니다. 이 단계의 엔지니어링은 제가 '하네스 엔지니어링 (Harness Engineering)'과 '루프 엔지니어링 (Loop Engineering)'이라 부르는 것들의 결합입니다. 즉, 에이전트에게 도구(Tools), 메모리(Memory), 자율성(Autonomy), 그리고 따라야 할 구조화된 사이클(Structured cycle)을 제공하는 것입니다.

4. 에이전틱 AI 시스템 (Agentic AI Systems) (2026+)

**핵심 질문: "에이전트들이 어떻게 협업할 것인가?"

최전선입니다. 우리는 이제 여러 자율 에이전트가 조정(Coordinate), 위임(Delegate), 그리고 자가 치유(Self-heal)하는 멀티 에이전트 시스템 (Multi-agent systems)을 바라보고 있습니다. 이를 위해서는 고급 루프 엔지니어링 (Advanced loop engineering), 분산 상태 관리 (Distributed state management), 그리고 정교한 오케스트레이션 (Sophisticated orchestration)이 필요합니다. 이는 백엔드 엔지니어들에게 매우 익숙하게 들리는 문제들일 것입니다.

전체 그림

무엇이 AI 에이전트를 "에이전틱(Agentic)"하게 만드는가?

"에이전트 (Agent)\

• 자율성 (Autonomy): 인간의 개입 없이 의사를 결정함
• 목표 지향성 (Goal-Directed): 단순히 입력에 반응하는 것이 아니라 정의된 목표를 향해 작동함
• 적응성 (Adaptive): 피드백과 관찰을 바탕으로 행동을 조정함
• 지속성 (Persistent): 컨텍스트 윈도우 (Context Window) 리셋 시에도 상태를 유지함
• 조합 가능성 (Composable): 더 큰 시스템의 일부로서 다른 에이전트들과 협업함
• 관찰 가능성 (Observable): 텔레메트리 (Telemetry)와 트레이싱 (Tracing)이 별도로 추가되는 것이 아니라 내장되어 있음

핵심적인 변화: 우리는 "응답하는 LLM"에서 "루프 (Loop) 내에서 실행되는 LLM"으로 이동하고 있습니다.

에이전틱 AI (Agentic AI)의 두 가지 기둥

프로덕션급 (Production-grade) 에이전틱 AI를 구축하는 것은 결국 두 가지 엔지니어링 분야로 귀결됩니다:

기둥 1: 하네스 엔지니어링 (Harness Engineering)

"에이전트에게 어떤 환경이 필요한가?"

하네스 (Harness)는 LLM을 유용하고 안전하게 만드는 LLM 주변의 모든 것을 의미합니다:

• 도구, API 및 역량 (Tools, APIs, and Capabilities) - 에이전트가 무엇을 할 수 있는가?
• 제약 조건 및 가드레일 (Constraints and guardrails) - 에이전트가 하지 말아야 할 것은 무엇인가?
• 오류 복구 및 상태 지속성 (Error recovery & state persistence) - 문제가 발생했을 때 어떤 일이 일어나는가?
• 보안 및 권한 모델 (Security and permission models) - 에이전트가 누구를 대신하여 행동할 수 있는가?

기둥 2: 루프 엔지니어링 (Loop Engineering)

"어떤 사이클이 에이전트를 목표로 이끄는가?"

루프 (Loop)는 에이전시 (Agency)의 엔진입니다:

• 반복 로직 (Iteration logic) - 전형적인 추론(Reason) → 행동(Act) → 관찰(Observe) 사이클
• 종료 조건 (Termination conditions) - 에이전트는 언제 멈추는가?
• 에스컬레이션 정책 (Escalation policies) - 언제 인간에게 알림을 보내야 하는가?
• 진행 상황 추적 및 로깅 (Progress tracking and logging) - 에이전트가 무엇을 하고 있는지 어떻게 알 수 있는가?

이렇게 생각해보세요:

프롬프트 (PROMPT) → 컨텍스트 (CONTEXT, 정보) → 루프 (LOOP, 사이클) → 하네스 (HARNESS, 환경)

각 레이어는 이전 레이어를 기반으로 구축됩니다. 프롬프트는 당신이 말하는 것입니다. 컨텍스트는 당신이 아는 것입니다. 루프는 당신이 생각하는 방식입니다. 하네스는 당신이 작동하는 장소입니다.

백엔드 엔지니어가 거대한 강점을 가진 이유

AI 하이프 사이클(hype cycle)이 자주 놓치는 사실이 하나 있습니다. 에이전트형 AI(agentic AI)를 구축하는 것은 근본적으로 백엔드 엔지니어링 문제입니다.

다음 매핑을 살펴보세요:

만약 당신이 회복 탄력성이 있는 분산 백엔드 시스템(distributed backend systems)을 구축하는 데 수년을 보냈다면, 당신은 이미 에이전트형 AI를 위한 멘탈 모델(mental models)을 갖추고 있습니다. LLM은 단지 재시도(retries), 타임아웃(timeouts), 상태 관리(state management), 그리고 관찰 가능성(observability)으로 감싸야 하는 새로운 종류의 신뢰할 수 없는 외부 서비스일 뿐입니다.

에이전트형 AI를 위해 왜 Elixir인가?

이 지점이 제가 진심으로 흥분하는 부분입니다. Elixir의 런타임(runtime)인 BEAM 가상 머신(virtual machine)은 에이전트형 AI가 요구하는 종류의 워크로드(workloads)를 위해 사실상 설계되었습니다. 그 이유를 살펴보겠습니다:

1. 경량 프로세스 (Lightweight Processes)

각 에이전트는 고작 25KB의 메모리만 소비하며 자신만의 격리된 프로세스(isolated process)에서 실행될 수 있습니다. 한 에이전트가 충돌하더라도 다른 에이전트를 절대 다운시키지 않습니다. 이는 "하나의 에이전트, 하나의 프로세스" 모델에 완벽하게 부합합니다.

2. 감독 트리 (Supervision Trees)

OTP 감독자(supervisors)는 충돌을 감지하고 밀리초 단위로 에이전트를 재시작합니다. 장애 복구(failure recovery)는 당신이 직접 구축하는 것이 아니라 런타임으로부터 얻는 것입니다. "Let It Crash" 철학은 LLM 호출이 중단되거나, 도구(tool)가 실패하거나, 에이전트가 예상치 못한 상태에 진입했을 때 정확히 당신이 원하는 방식입니다.

3. 대규모 동시성 (Massive Concurrency)

BEAM 스케줄러(schedulers)는 진정한 병렬성(parallelism)을 통해 수천 개의 동시 에이전트를 처리합니다. 튜닝해야 할 스레드 풀(thread pools)도, 복잡한 async/await 기교도, 싸워야 할 GIL(Global Interpreter Lock)도 없습니다. 수백 개의 에이전트가 각각 다단계 추론 루프(multi-step reasoning loops)를 실행할 때, 이 점은 엄청나게 중요합니다.

4. 메시지 전달 (Message Passing)

에이전트들은 비동기 메시지(asynchronous messages)를 통해 통신하며, 이는 분산 에이전트 시스템(distributed agent systems)에 자연스럽게 적합합니다. 공유 상태(shared state)도, 잠금(locks)도 없이, 깨끗한 메시지 기반의 조정(coordination)만 존재합니다.

5. 핫 코드 업그레이드 (Hot Code Upgrades)

다운타임(downtime) 없이 에이전트 로직을 업데이트할 수 있습니다. 에이전트가 몇 시간 또는 며칠 동안 실행될 수 있는 프로덕션(production) 에이전트 시스템에서는 행동 업데이트(behavioral updates)를 실시간으로 푸시할 수 있는 능력이 매우 중요합니다.

Elixir 툴링 생태계 (The Elixir Tooling Ecosystem)

커뮤니티는 이미 우리에게 필요한 도구들을 구축하고 있습니다.

ReqLLM - Elixir에서의 조합 가능한 LLM 상호작용 (Composable LLM Interactions in Elixir)

ReqLLM은 LLM과 상호작용하기 위한 통합되고 관용적인(idiomatic) Elixir 인터페이스를 제공합니다:

• 제공자(OpenAI, Anthropic, 로컬 모델) 전반에 걸친 통합 API
• 유연한 모델 사양 (문자열, 튜플, 구조체 형식)
• 구조화된 데이터 생성 기능을 갖춘 풍부한 프롬프트 지원
• 관용적인 Elixir 스타일 — 파이프(pipe) 연산에 친숙하며 패턴 매칭(pattern-matching)이 기본적으로 지원됨
• 92개 이상의 비텍스트(non-text) 작업 모델(비전, 오디오 등) 추적

간단한 예시:

response =
  ReqLLM.chat!(
    "openai:gpt-4o",
...

전체 소스 코드: github.com/yauritux/reqllm_demo

Jido 프레임워크 - Elixir에서의 프로덕션급 에이전트 (Production-Grade Agents in Elixir)

BEAM 위에서 프로덕션급 에이전트 시스템을 구축하기 위한 프레임워크를 제공함으로써 한 단계 더 나아갑니다:

• OTP 네이티브 아키텍처 (OTP-Native Architecture) — 에이전트는 감독 트리(supervision trees)를 가진 GenServer입니다.
• 불변 에이전트 (Immutable Agents) — 상태 전이(state transitions)가 명시적이며 추적 가능합니다.
• AI 선택 사항 (AI Optional) — 모든 단계에 LLM이 필요하지는 않습니다. 결정론적 로직(deterministic logic)과 AI 추론을 혼합하여 사용하세요.
• 명시적 효과 경계 (Explicit Effect Boundaries) — 부수 효과(side effects)가 숨겨지지 않고 선언됩니다.
• 대규모 동시성 (Massive Concurrency) — 첫날부터 BEAM의 프로세스 모델을 기반으로 구축되었습니다. 모든 에이전트는 자체적인 경량 프로세스(lightweight process)에서 실행됩니다. 하나가 충돌하더라도 다른 것에는 영향을 주지 않습니다.

실무 사례: Jido를 활용한 스마트 티케팅 에이전트 (Smart Ticketing Agents with Jido)

이것들이 어떻게 결합되는지 확인하기 위해, Jido로 구축된 스마트 티케팅 시스템(Smart Ticketing System)을 살펴보겠습니다. 당황한 고객으로부터 다음과 같은 가공되지 않은 이메일이 들어왔다고 가정해 봅시다:

입력(INPUT): "대시보드가 너무 느리게 로딩되고 503 에러가 떠요. 한 시간 뒤에 중요한 발표가 있는데 정말 미치겠어요!"

모든 것을 처리하려고 시도하는 단일 모놀리식 스크립트 (monolithic script) 대신, 우리는 이를 멀티 에이전트 파이프라인 (multi-agent pipeline)을 통해 라우팅합니다.

1. 트리아지 에이전트 (The Triage Agent)

• 프롬프트 전략 (Prompt Strategy): **Chain-of-Thought (CoT)**와 결합된 CREATE 프레임워크 (Context, Result, Explain, Audience, Tone, Edit)를 사용합니다.
• 입력 (Input): 가공되지 않은 이메일 텍스트.
• 동작 (Action): 감정적 무게를 분석하고 기술적 신호 (technical signals)를 추출합니다.
• 출력 (Output): 구조화된 JSON.

{ 
  "reasoning": "customer is highly desperate...",
  "sentiment": "highly_negative", 
...

2. 진단 에이전트 (The Diagnostic Agent)

• 프롬프트 전략 (Prompt Strategy): Few-Shot Prompting과 결합된 ReAct Loop (Reason + Act)를 사용합니다.
• 입력 (Input): 트리아지 에이전트로부터 추출된 error_code = "503".
• 도구 (Tools): check_server_status/1, restart_service/1.
• 동작 (Action): 에이전트가 503 에러에 대해 추론하고, check_server_status 도구를 호출하며, 프론트엔드 프로세스가 충돌했음을 인지한 후 restart_service를 실행합니다.
• 출력 (Output): 기술적 해결 보고서.

{ 
  "issue": "503 service unavailable", 
  "root_cause": "web frontend process crashed", 
...

이 에이전트들은 Jido와 BEAM을 기반으로 구축되었기 때문에, 트리아지 에이전트와 진단 에이전트는 격리된 프로세스 (isolated processes)에서 실행됩니다. 만약 진단 에이전트가 외부 API를 호출하는 동안 타임아웃 (timeout)이 발생하더라도, 트리아지 에이전트나 애플리케이션의 나머지 부분을 중단시키지 않고 해당 에이전트만 충돌 후 재시작됩니다.

전체 구현 내용은 github.com/yauritux/smart_ticket에서 확인하세요.

결론: 백엔드 엔지니어의 순간