에이전트는 쉽다. 루프(Loop)가 진짜 업무다. — 2026년 AI 엔지니어링에 대한 개발자용 No-BS 가이드 - Insights | Molayo

내가 아는 모든 개발자는 똑같은 경험을 해왔습니다. ChatGPT에 무언가를 붙여넣으면 작동하는 컴포넌트가 튀어나오고, 여러분은 _"세상에, 내 일은 이제 끝났구나."_라고 생각합니다. 그러다 실제 엣지 케이스(edge cases)가 존재하는 실제 코드베이스에 적용해 보면, 그 마법은 증발해 버립니다.

화려한 데모와 배포할 수 있을 만큼 신뢰할 수 있는 것 사이의 그 간극 — 바로 그곳에 완전히 새로운 분야가 존재합니다. 그것은 **AI 엔지니어링 (AI engineering)**이라 불리며, 여러분이 생각하는 것과는 다릅니다.

그렇다면 AI 엔지니어란 정확히 무엇인가?

초기에 혼란을 바로잡아 봅시다.

AI 엔지니어는 유행하는 직함만 가진 ML 엔지니어가 아닙니다. ML 엔지니어는 모델 계층 (model layer) — 데이터셋 학습, 아키텍처 최적화, 백서 작성 — 에 머뭅니다. AI 엔지니어는 애플리케이션 계층 (application layer) 에 머뭅니다. 우리는 사전 학습된 모델 (GPT-4o, Claude, Llama, DeepSeek 등 원하는 것을 선택하세요) 을 가져와 실제 사용자와의 접점에서도 살아남는 제품으로 만듭니다.

에이전트(agent)는 쉬운 부분입니다. 루프(loop)가 진짜 업무입니다.

이렇게 생각해 보세요. 데이터 사이언티스트가 감성 분석 모델을 만들었습니다. ML 엔지니어가 이를 학습시키고 최적화했습니다. AI 엔지니어로서 여러분의 업무는 무엇일까요? 그 모델을 고객이 실제로 사용하는 제품에 연결하고, 모델이 던지는 모든 엣지 케이스 (edge case) 를 처리하며, 평가 파이프라인 (evaluation pipelines) 을 구축하고, 프로덕션 (production) 환경에서 전체 시스템이 계속 작동하도록 유지하는 것입니다.

이는 학술적 연구보다는 소프트웨어 엔지니어링 (software engineering) 과 더 많은 공통점을 가집니다. 하지만 전통적인 앱 개발과는 근본적으로 다른 사고방식이 필요합니다. 왜냐하면 여러분은 비결정론적 (non-deterministic) 인 것 위에 구축하고 있기 때문입니다.

AI 엔지니어 vs ML 엔지니어 vs 소프트웨어 엔지니어

제가 드릴 수 있는 가장 명확한 구분은 다음과 같습니다:

ML 엔지니어 (ML Engineer) → 모델을 학습시키고 최적화합니다. PyTorch, TensorFlow, SageMaker 환경에서 활동합니다. 깊은 수학 지식이 필요합니다. 결과물: 학습된 모델.

AI 엔지니어 (AI Engineer) → 모델을 사용하여 애플리케이션을 구축합니다. LLM API, LangChain, 벡터 데이터베이스 (vector databases), FastAPI 환경에서 활동합니다. 적당한 수학 지식이 필요합니다. 결과물: 작동하는 제품.

소프트웨어 엔지니어 (Software Engineer) → 결정론적 (deterministic) 소프트웨어 시스템을 구축합니다. 결과물: 웹 앱, API, 인프라 (infrastructure).

이 둘 사이의 중첩은 실재하며 — 채용 공고에서도 이 역할들을 끊임없이 혼동하곤 하지만 — 일상적인 업무는 완전히 다릅니다. 만약 당신의 결과물이 학습된 모델(trained model)이라면, 당신은 ML(Machine Learning)을 하고 있는 것입니다. 만약 당신의 결과물이 타인의 모델을 기반으로 구축되어 출시된 제품(shipped product)이라면, 당신은 AI 엔지니어링(AI engineering)을 하고 있는 것입니다.

반복해서 등장하는 네 가지 기술

LinkedIn에서 AI 엔지니어 채용 공고를 살펴보면 (네, 알고 있습니다만, 데이터는 거기에 있습니다) 네 가지 기술이 반복적으로 나타납니다:

RAG (Retrieval-Augmented Generation, 검색 증강 생성)
Evals (Evaluation pipelines, 평가 파이프라인)
Agents (Autonomous multi-step systems, 자율적 다단계 시스템)
Production deployment (프로덕션 배포)

이 중 세 가지는 학습이 가능합니다. 프로덕션 배포(Production deployment)는 회사의 환경과 기술 스택(stack)에 너무나 특화되어 있어서, 전문가가 해줄 수 있는 최선은 당신에게 _어떤 질문을 던져야 하는지_를 가르쳐 주는 것뿐입니다.

이러한 핵심 기술들 아래에서, 실제 일상적인 업무는 다음과 같이 나뉩니다:

컨텍스트 엔지니어링 (Context engineering) — 적절한 시점에 모델에 적절한 토큰(tokens)을 보내는 것. 토큰은 화폐와 같습니다. 토큰은 에너지와 비용을 소모합니다. 업계는 실제 측정 단위로서 "와트당 토큰(tokens per watt)"을 향해 나아가고 있습니다.
도구 설계 (Tool design) — 에이전트(agents)에게 적절한 능력을 부여하고, 그들이 잘못된 행동을 하지 않도록 확실히 보장하는 것.
평가 (Evaluation) — 당신의 에이전트가 실제로 개선되고 있는지, 아니면 단지 그렇게 느껴지는 것뿐인지를 측정하는 것.
프로덕션 신뢰성 (Production reliability) — 자가 치유(self-healing), 우아한 에러 처리(graceful error handling), 지연 시간 관리(latency management). 당신의 시스템이 실제 사용자와 함께하는 첫 일주일을 버텨낼 수 있을지를 결정하는 요소들입니다.

Build → Eval → Improve 루프

여기 취미가와 실무자를 구분 짓는 멘탈 모델(mental model)이 있습니다:

Build (구축) → Eval (평가) → Improve (개선) → Eval (평가) → Improve (개선) → ...

에이전트를 구축하는 것은 사소합니다. 현대적인 SDK를 사용하면 코드 다섯 줄이면 충분합니다. 오후 한나절이면 느낌대로 코딩(vibe-code)할 수 있습니다. 중요한 부분은 그 이후에 오는 모든 것입니다.

어디서 실패하는지 평가하십시오. 왜 실패하는지 파악하십시오. 그 특정 실패를 해결하기 위해 적절한 기술을 적용하십시오. 다시 평가하십시오. 이 루프(Loop)는 결코 끝나지 않습니다. 이것은 제품을 출시하고 유지보수 모드로 전환하는 프로젝트가 아닙니다. 비결정론적 시스템 (non-deterministic system)에 대한 지속적인 피드백 사이클입니다.

이것이 바로 적절한 **지표 (metrics)**를 선택하는 것이 아마도 이 업무에서 가장 어려운 부분인 이유입니다. 잘못된 지표를 선택하면 당신의 루프는 노이즈를 생성합니다. 올바른 지표를 선택하면 전체 시스템이 복리로 성장합니다. AI 엔지니어링의 대부분의 레버리지 (leverage)는 무엇을 측정할지 선택하는 데서 옵니다.

실전 도입 여정 (현장에서 얻은 교훈)

Vagrant, Terraform, Ghostty의 제작자인 Mitchell Hashimoto는 최근 자신의 개인적인 AI 도입 여정을 공유했는데, 이는 제가 읽은 것 중 가장 현실적인 견해 중 하나입니다. 몇 가지 핵심적인 교훈이 눈에 띄었습니다:

실제 업무를 위해 챗봇을 버리십시오.

모든 사람의 첫 AI 경험은 채팅 인터페이스입니다. 그리고 코딩의 경우, 이는 제한적입니다. 모델이 제대로 맞히기를 바라다가, 그렇지 않을 때는 두더지 잡기 게임을 하는 격이 됩니다. 진정한 가치를 찾으려면 **에이전트 (agents)**가 필요합니다. 즉, 파일을 읽고, 프로그램을 실행하며, 루프 안에서 HTTP 요청을 보낼 수 있는 시스템이 필요합니다.

에이전트로 자신의 작업물을 재현해 보십시오.

이 방법은 고통스럽지만 탁월합니다. 수동으로 작업을 수행한 다음, 에이전트가 당신의 솔루션을 보지 못한 채 동일한 결과를 만들어내도록 에이전트와 싸워보십시오. 매우 괴로운 과정이겠지만, 이를 통해 에이전트가 무엇을 잘하고 무엇을 못하는지에 대한 진정한 전문성을 쌓을 수 있습니다.

프롬프트뿐만 아니라 하네스 (harness)를 설계하십시오.

에이전트가 실수를 할 때마다, 그 실수를 다시는 반복하지 않도록 보장하는 데 노력을 투자하십시오. 이는 두 가지를 의미합니다:

더 나은 암시적 프롬프팅 (implicit prompting) (예: 관찰된 실패를 기반으로 규칙을 정의한 AGENTS.md 파일)
실제 프로그래밍된 도구들 — 스크린샷을 찍고, 필터링된 테스트를 실행하며

AI 엔지니어링 (AI engineering)으로 전환하려는 개발자라면, 다음과 같은 현실적인 단계별 접근 방식을 권장합니다.

1단계: Python 및 개발 기초 (2~3개월)

AI 엔지니어링의 모든 것은 Python 위에서 돌아갑니다. 객체 지향 프로그래밍 (OOP), Git, CLI 도구, 그리고 API 소비 (API consumption)에 능숙해지세요. 이것은 선택 사항이 아닙니다. 모든 프레임워크와 도구가 기반을 두고 있는 토대입니다.

2단계: LLM 기초 및 애플리케이션 개발 (2~3개월)

LLM (Large Language Models)이 실제로 어떻게 작동하는지(토큰화 (tokenization), 컨텍스트 윈도우 (context windows), 온도 (temperature)) 학습하세요. 프롬프트 엔지니어링 (prompt engineering), 함수 호출 (function calling), 그리고 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 마스터하세요. FastAPI와 Docker를 사용하여 실제 AI 애플리케이션을 구축하고 배포해 보세요.

3단계: 데이터, 수학, 그리고 머신러닝 (3~4개월)

박사 학위가 필요한 것은 아니지만, 그 밑바탕이 되는 과학적 원리는 반드시 이해해야 합니다. 통계학, 지도/비지도 머신러닝 (supervised/unsupervised ML), 그리고 딥러닝 (deep learning)의 기초는 단순히 API를 맹목적으로 호출하는 대신, AI 시스템을 디버깅하고 개선할 수 있는 직관을 제공합니다.

4단계: 임베딩, RAG, 그리고 에이전트 (2~3개월)

이 단계에서 모든 것이 하나로 합쳐집니다. 벡터 데이터베이스 (Vector databases), 시맨틱 검색 (semantic search), RAG (Retrieval-Augmented Generation) 파이프라인, 평가 프레임워크 (evaluation frameworks), 그리고 자율 에이전트 (autonomous agents)를 다룹니다. 이 단계는 현재 기업들이 실제로 활발하게 채용하고 있는 분야를 다룹니다.

일정 현실 점검: 만약 아무것도 모르는 상태에서 시작한다면, 주당 10~~15시간을 투자하여 8~~12개월을 계획하세요. 소프트웨어 엔지니어링 출신이라면 3~~5개월, 데이터 사이언스 (data science) 출신이라면 3~~6개월이 소요됩니다.

이것이 중요한 이유 (그리고 왜 거품이 아닌가)

수치는 무시하기 어렵습니다. 미국의 AI 엔지니어는 연간 중앙값으로 약 142,000달러를 벌며, 시니어 역할은 220,000달러를 초과하고, 상위 기업의 총 보상 (total compensation)은 300,000~600,000달러에 달합니다. LinkedIn은 AI 엔지니어를 2년 연속 미국에서 가장 빠르게 성장하는 직함으로 선정했습니다.

하지만 급여보다 더 중요한 것은 업무의 본질입니다. OpenAI의 채용 공고를 살펴보면, 그들은 추상적인 의미의 "AI 엔지니어"를 채용하는 것이 아닙니다. 그들은 시스템의 특정 영역 (one specific slice), 즉 도구 선택 (tool selection), 인간 참여형 루프 (human-in-the-loop), 안전성 (safety), 토큰 최적화 (token optimization)를 담당할 사람들을 채용하고 있습니다. 이것이 제품이 에이전트 (agent)일 때 요구되는 노력의 규모입니다.

제품 자체가 에이전트인 AI 네이티브 (AI-native) 기업이 늘어남에 따라, 우리는 거대하고 전문화된 AI 엔지니어 팀들을 보게 될 것입니다. 이것은 일시적인 유행이 아닙니다. 하나의 학문적 분야 (discipline)가 형성되는 초기 단계입니다.

## 모든 곳이 아닌, 여기서부터 시작하세요

이 글에서 단 한 가지만 기억해야 한다면, 바로 이것입니다: 한꺼번에 모든 것을 배우려고 하지 마세요.

API 호출을 능숙하게 하고 JSON을 다룰 수 있기 전에는 에이전트 (agents)로 뛰어들지 마세요.
모든 새로운 프레임워크 (LangChain, LlamaIndex, CrewAI)를 쫓아다니지 마세요. 우선 하나를 깊게 배우세요.
평가 (evals)를 건너뛰지 마세요. 평가 (evals)는 "가끔 작동하는 것"과 "제대로 작동하는 것"의 차이를 만듭니다.
튜토리얼을 보는 것과 무언가를 만드는 것을 혼동하지 마세요. 무엇이든 출시(ship)하세요. 무엇이든 말입니다.

도구는 변할 것입니다. 하지만 기본 원칙은 변하지 않습니다. 모델을 실제 제품에 연결하고, 신뢰할 수 있는 파이프라인 (pipelines)을 구축하며, 실제로 작동하는 시스템을 배포하는 것 — 그것이 소프트웨어 엔지니어링 (software engineering)이며, 다음 파도가 어떤 모습이든 그 가치는 유지될 것입니다.

에이전트는 쉽습니다. 루프 (loop)가 진짜 업무입니다. AI 엔지니어링의 세계에 오신 것을 환영합니다.

추가 읽을거리:

에이전트는 쉽다. 루프(Loop)가 진짜 업무다. — 2026년 AI 엔지니어링에 대한 개발자용 No-BS 가이드

요약

핵심 포인트