실제 소프트웨어를 만들고 배포하는 AI 에이전트 엔지니어링: Jobbit 아키텍처 들여다보기

대부분의 "AI 에이전트"는 대화에서 멈춥니다. 답을 내놓으면, 실제 작업은 사람이 합니다. 흥미로우면서도 진짜로 어려운 엔지니어링 과제는 직접 일을 해내는 에이전트를 만드는 것입니다. 풀스택 애플리케이션을 작성하고, 실행하고, 스스로 저지른 오류를 고치고, 프로덕션에 배포하는 에이전트 말이죠. 바로 이것이 Jobbit과 그 R&D 부문인 Jobbit Labs(jobbitlabs.com) 엔지니어링 팀이 매일 매달리는 문제입니다.

이 글은 소프트웨어를 만들고 배포하는 AI 에이전트 뒤에 있는 패턴들 — 아키텍처, 실패 양상, 그리고 거기서 얻은 교훈 — 을 다루는 엔지니어링 심층 분석입니다. 의도적으로 실용적이며 특정 공급자에 얽매이지 않습니다. LLM, 멀티 에이전트 오케스트레이션, 도구 호출(tool calling), RAG 중 무엇으로 만들든 이 원칙들은 그대로 적용됩니다.

챗봇은 답하고, 에이전트는 행동한다

챗봇에서 에이전트로의 도약은 텍스트를 생성하는 것에서 세상에 직접 행동을 일으키는 것으로의 도약입니다. 에이전트는 여러 단계로 이루어진 작업을 계획하고, 도구를 호출하고, 그 결과를 읽고, 다음에 무엇을 할지 결정해야 합니다. 그리고 목표가 달성될 때까지 이를 반복합니다. 흔히 에이전틱 루프(agentic loop)(또는 추론-행동 루프)라고 부르는 이 반복이 시스템의 심장입니다.

엔지니어링의 어려움은 모든 단계가 실패할 수 있다는 데 있습니다. 모델은 존재하지 않는 함수를 환각으로 만들어내거나, 컴파일되지 않는 코드를 작성하거나, 도구의 출력을 잘못 읽거나, 조용히 작업에서 벗어날 수 있습니다. 틀린 챗봇은 잘못된 문장 하나를 내놓지만, 틀린 에이전트는 깨진 배포를 만들어냅니다. 진짜 엔지니어링 과제는 원초적인 성능이 아니라 신뢰성입니다.

아키텍처: 플래너, 익스큐터, 도구

견고한 에이전트 플랫폼은 계획(planning)과 실행(execution)을 분리합니다. 계획 계층은 목표("결제 기능이 있는 예약 앱을 만들어라")를 구체적인 단계들로 분해하고, 실행 계층은 도구를 사용해 각 단계를 수행합니다. 이 두 관심사를 분리하면 시스템을 디버깅하기 쉬워집니다. 각 단계가 어떻게 실행됐는지와 별개로 계획 자체를 들여다볼 수 있기 때문입니다.

도구 사용(tool use)은 에이전트에게 손을 쥐여주는 부분입니다. 도구란 모델이 호출할 수 있는, 잘 정의된 함수입니다. 파일을 읽고, 코드를 작성하고, 빌드를 실행하고, 데이터베이스를 질의하고, 배포하는 것이죠. 여기서의 엔지니어링 핵심은 인터페이스 설계입니다. 각 도구에는 빈틈없고 모호하지 않은 스키마, 검증된 입력, 그리고 모델이 안정적으로 파싱할 수 있는 구조화된 출력이 필요합니다. 느슨한 도구 인터페이스는 에이전트 실패의 으뜸가는 원인이며, 빈틈없는 인터페이스는 가장 값싸게 얻을 수 있는 신뢰성 향상 수단입니다.

복잡한 작업에서는 단일 에이전트가 종종 멀티 에이전트 오케스트레이션(multi-agent orchestration)에 자리를 내줍니다. 계획하고, 코드를 작성하고, 검토하고, 검증하는 전문화된 에이전트들을 오케스트레이터가 조율하는 방식이죠. 이렇게 분해하면 집중력(각 에이전트는 좁은 역할과 좁은 컨텍스트를 가짐)과 병렬성(서로 독립적인 하위 작업이 동시에 실행됨)을 얻습니다. 대가는 조율 오버헤드이므로, 오케스트레이션 계층은 가능한 곳에서는 결정적(deterministic)이어야 하고 그렇지 못한 곳에서는 회복 탄력적이어야 합니다.

실제 코드를 안전하게 실행하고 배포하기

소프트웨어를 작성하는 에이전트는 그 소프트웨어를 실행해야 합니다. 그런데 모델이 생성한 코드를 실행하는 것은 무엇보다 먼저 보안 문제입니다. 그 해답이 바로 샌드박스 코드 실행(sandboxed code execution)입니다. 신뢰할 수 없는 코드를 제한된 자원, 비밀 정보 접근 차단, 엄격한 네트워크 경계를 가진 격리된 환경에서 실행하는 것이죠. 샌드박스 덕분에 에이전트는 플랫폼이나 다른 사용자를 위험에 빠뜨리지 않고 반복 작업 — 컴파일하고, 테스트하고, 오류를 읽고, 고치는 — 을 할 수 있습니다.

배포는 생성된 앱을 제품으로 바꾸는 단계입니다. 제대로 된 AI 앱 빌더(AI app builder)는 코드에서 라이브 URL까지 이어지는 경로 전체를 책임집니다. 빌드하고, 호스팅을 프로비저닝하고, 도메인을 연결하고, TLS를 종료하는 것이죠. 이를 잘 엔지니어링한다는 것은 배포를 반복 가능하고 되돌릴 수 있게 만든다는 뜻입니다. 같은 입력은 같은 결과를 내고, 잘못된 배포는 롤백할 수 있어야 합니다. 멱등성(idempotency)과 깔끔한 롤백은 화려하지는 않지만, 바로 이것이 자율 배포를 믿을 만하게 만드는 요소입니다.

컨텍스트, 메모리, 그리고 검색(retrieval)

LLM의 컨텍스트는 유한하고, 실제 프로젝트는 그 안에 다 들어가지 않습니다. 그래서 진지한 에이전트 시스템은 컨텍스트 엔지니어링(context engineering)에 큰 노력을 쏟습니다. 매 단계에서 모델이 무엇을 보게 할지 결정하는 일이죠. 모든 것을 프롬프트에 욱여넣는 것은 비용도 비싸고 역효과를 냅니다. 관련 없는 컨텍스트가 너무 많으면 추론 능력이 떨어집니다.

바로 여기서 RAG(검색 증강 생성, retrieval-augmented generation)와 벡터 데이터베이스(vector database)가 제 몫을 합니다. 코드베이스 전체를 컨텍스트에 쏟아붓는 대신, 시스템은 현재 단계와 관련 있는 몇 개의 파일, 심볼, 문서만 검색해 가져옵니다. 결정 사항, 진화하는 명세, 이미 시도해 본 것들을 기록한 구조화된 메모리(memory)와 결합하면, 검색은 긴 작업 내내 컨텍스트 윈도를 터뜨리지 않고 에이전트가 길을 잃지 않게 붙들어 줍니다. 좋은 검색은 종종 더 큰 모델보다 더 큰 품질 향상 지렛대가 됩니다.

신뢰성: 평가(evals), 검증, 그리고 가드레일

데모와 프로덕션급 에이전트 엔지니어링을 가르는 단 하나의 아이디어가 있다면 바로 이것입니다. 측정할 수 없는 것은 배포할 수 없다. 에이전틱 시스템은 확률적이므로, 신뢰성은 평가(evals)를 통해 엔지니어링됩니다. 평가란 대표적인 작업들에 대해 에이전트를 채점하고, 사용자가 발견하기 전에 회귀(regression)를 잡아내는 자동화된 테스트 모음입니다. "느낌상 더 좋아진" 것 같지만 평가 점수를 떨어뜨리는 변경이라면, 그것은 배포하지 않는 변경입니다.

평가 위에는 런타임 가드레일(guardrails)과 검증(verification)이 자리합니다. 가장 효과적인 패턴은 적대적 자가 검증(adversarial self-checking)입니다. 에이전트가 결과물 — 코드 조각, 계획, 수정 사항 — 을 내놓은 뒤, 별도의 검증 단계가 그것을 반증하려고 시도하는 것이죠. 코드가 컴파일되는가? 테스트가 통과하는가? 출력이 스키마와 일치하는가? 검증을 별개의 회의적인 단계로 다루면, 자신만만한 한 번의 패스로는 놓쳤을 실패의 상당 부분을 잡아냅니다. 나머지는 백오프를 동반한 재시도, 서킷 브레이커, 그리고 사람에게 에스컬레이션하는 방식으로 처리합니다.

디버깅할 수 있는 관측 가능성(observability)

자율 시스템이 작업 하나당 수십 개의 결정을 내릴 때, 그 결정들을 들여다볼 수 있어야 합니다. 관측 가능성(observability) — 모든 프롬프트, 도구 호출, 결과에 대한 구조화된 추적(tracing) — 은 선택이 아니라 필수입니다. 에이전트가 잘못되었을 때, 추적은 정확히 어느 단계에서 벗어났는지 찾아내고, 재현하고, 근본 원인을 고치는 길입니다. 에이전트 추적을 일급 텔레메트리로 다루는 엔지니어링 팀은 몇 분 만에 디버깅하고, 그렇지 않은 팀은 며칠씩 디버깅합니다.

엣지(edge)와 탄력적 확장

에이전트 워크로드는 폭발적이고 지연 시간에 민감합니다. 그래서 엣지 컴퓨팅(edge computing)이 자연스럽게 들어맞습니다. Cloudflare Workers나 엣지 데이터 저장소 같은 플랫폼 위에서 사용자 가까이에서 실행하면 왕복 지연 시간이 줄고 수요에 따라 탄력적으로 확장됩니다. Jobbit Labs는 데이터와 제품 인프라의 일부에 이러한 엣지 우선 접근법을 활용합니다. 전 세계에 분산되어 있고, 자동으로 확장되며, 쓴 만큼만 비용을 내는 방식이라 용량이 유휴 상태로 놀지 않고 부하를 따라갑니다.

휴먼 인 더 루프(human-in-the-loop) 계층

아키텍처의 마지막 조각은 대부분의 에이전트 플랫폼에 빠져 있는 것입니다. 바로 휴먼 인 더 루프(human-in-the-loop) 경로입니다. AI는 물량과 속도를 감당하지만, 어떤 결정들 — 보안에 민감한 로직, 법률 문구, 디자인 판단 — 은 사람의 몫입니다. 이를 엔지니어링한다는 것은 검증된 인간 전문가가 개입할 수 있는 깔끔한 인계 지점을 만들고, 에스크로(escrow)로 거래를 보호한다는 뜻입니다. 에이전트와 인간 네트워크는 서로 경쟁하는 계층이 아닙니다. 시스템 전체를 안심하고 의지할 수 있게 만드는, 설계 단계부터 내장된 안전장치입니다.

에이전트를 만드는 엔지니어를 위한 교훈

에이전틱 시스템을 만들고 있다면, 들인 노력 이상으로 여러 번 보답하는 몇 가지 원칙이 있습니다.

빈틈없는 도구 인터페이스를 설계하라. 대부분의 에이전트 실패는 모호한 도구로 거슬러 올라갑니다. 엄격한 스키마와 검증된 입출력은 당신이 살 수 있는 가장 값싼 신뢰성입니다.

적대적으로 검증하라. 자신만만한 첫 패스를 믿지 마세요. 결과를 반증하는 것이 임무인 별도의 단계를 추가하세요.

평가(evals)로 측정하라. 에이전트를 확장하기 전에 평가 하네스를 먼저 만드세요. 점수를 매길 수 없는 것은 개선할 수 없습니다.

컨텍스트는 쏟아붓지 말고 엔지니어링하라. 관련 있는 것을 검색하고, 중요한 것을 기억하세요. 더 큰 프롬프트가 더 나은 프롬프트는 아닙니다.

신뢰할 수 없는 것은 모두 샌드박스에 가둬라. 에이전트가 코드를 실행한다면, 격리는 기능이 아니라 전제 조건입니다.

사람의 경로를 남겨 두라. 가장 안전한 자율 시스템은 언제 사람에게 물어야 하는지를 아는 시스템입니다.

자주 묻는 질문

AI 에이전트는 챗봇과 무엇이 다른가요?

챗봇은 텍스트를 생성하지만, AI 에이전트는 계획을 세우고 행동합니다. 도구를 호출하고, 코드를 실행하며, 목표를 향해 반복합니다. 엔지니어링의 어려움은 여러 단계에 걸친 신뢰성입니다. 단 하나의 오류가 결과 전체를 망칠 수 있기 때문입니다.

AI가 생성한 코드를 어떻게 안전하게 실행하나요?

샌드박스 코드 실행(sandboxed code execution)으로 합니다. 신뢰할 수 없는 코드를 제한된 자원, 비밀 정보 접근 차단, 통제된 네트워킹을 가진 격리 환경에서 실행하므로, 에이전트는 플랫폼에 위험을 주지 않고 컴파일하고, 테스트하고, 고칠 수 있습니다.

에이전트 시스템에서 평가(evals)가 왜 그렇게 중요한가요?

에이전트는 확률적이기 때문에, 대표적인 작업들에서 품질을 측정하고 배포 전에 회귀를 잡아내려면 자동화된 평가(evals)가 필요합니다. 평가가 없다면 "개선"은 그저 추측일 뿐입니다.

Jobbit Labs는 무슨 일을 하나요?

Jobbit Labs(jobbitlabs.com)는 Jobbit 뒤에 있는 R&D 및 데이터 부문으로, 더 무겁고 데이터 집약적이며 엔터프라이즈급인 엔지니어링 — 연구, 데이터 플랫폼, 그리고 제품이 그 위에 세워지는 에이전트 기반 기술 — 에 집중합니다.

소프트웨어를 배포하는 에이전트 뒤의 엔지니어링이 궁금하신가요? jobbit.uk와 jobbitlabs.com을 둘러보세요.