4. Agentic Engineering(에이전틱 엔지니어링)

AI가 스스로 계획을 세우고, 도구를 사용하며, 복잡한 태스크를 해결하도록 설계하는 기술 — 자율의 기술

• 에이전틱 엔지니어링(Agentic Engineering)은 AI를 단순히 ‘답변하는 기계’에서 벗어나, 목표를 달성하기 위해’스스로 계획을 세우고 도구를 사용하며 실행하는 주체(Agent)‘로 설계하는 기술
• 멀티 에이전트 협업, 외부 API 호출(Function Calling), 스스로 결과물을 검토하고 수정하는 루프(Loop) 설계 등이 포함됩니다.
• 앞선 3가지 축(프롬프트, 컨텍스트, 하네스)이 잘 갖춰졌을 때, 비로소 에이전트가 “실제로 일을 하는 조직”처럼 작동

프롬프트가 ‘말’이고 컨텍스트가 ‘지식’이라면, 에이전틱 엔지니어링은 AI에게 ‘손과 발, 그리고 판단력’을 달어주는 과정이라고 할 수 있다.

각 엔지니어링의 상호보완성

이 요소들은 하나가 부족하면 전체 시스템의 신뢰도가 급격히 떨어진다

구성 요소	결합 효과	결여 시 발생하는 문제
Prompt + Context	정확한 지식 기반 답변	근거 없는 자신감(환각 현상)
Context + Harness	안전하고 신뢰할 수 있는 정보 제공	유출되면 안 되는 정보의 노출
Harness + Agentic	통제 가능한 자율 시스템	예측 불가능한 폭주(Infinite Loop 등)
Agentic + Prompt	목적 중심의 효율적 업무 수행	목표를 이해하지 못하고 방황함

---

🤖 에이전트의 기본 구조 (Agent Architecture)

에이전틱 엔지니어링의 핵심은 모델을 하나의 거대한 루프(Loop) 안에 넣는 것

1. 브레인 (Brain): 추론과 의사결정을 담당하는 LLM
2. 기획 (Planning): 복잡한 목표를 작은 단위의 태스크로 쪼개는 능력
3. 기억 (Memory): 단기 기억(대화 맥락)과 장기 기억(외부 데이터베이스)을 활용
4. 도구 (Tools): 외부 API, 계산기, 웹 검색, 코드 실행기 등 실제 행동을 수행하는 수단

---

🛠️ 에이전틱 엔지니어링의 주요 기법들

1. ReAct (Reason + Act)

가장 고전적이면서 강력한 프레임워크로써, AI가 생각(Reasoning)을 먼저 하고, 그 생각에 기반해 행동(Action)을 한 뒤, 결과를 관찰(Observation)하는 과정을 반복

• 프로세스: “질문 확인 → 생각 → 도구 사용 → 결과 관찰 → (반복) → 최종 답변”

2. Task Decomposition (태스크 분해)

AI가 한 번에 해결하기 어려운 거대한 문제를 만났을 때, 이를 실행 가능한 하위 문제들로 나누는 기술

• Chain of Thought (CoT): 선형적인 단계별 사고
• Tree of Thoughts (ToT): 여러 가동 경로를 탐색하고 최선의 길을 선택

3. Tool Use & Function Calling

AI가 텍스트 생성을 넘어 외부 시스템과 상호작용하게 한다.

• “내일 서울 날씨 알려줘”라는 요청에 AI가 직접 기상청 API를 호출(Function Calling)하여 실시간 데이터를 가져오는 식

4. Multi-Agent Orchestration (멀티 에이전트 협업)

하나의 만능 에이전트를 만드는 대신, 전문성을 가진 여러 에이전트를 팀으로 구성

• 예시: ‘기획 에이전트’가 초안을 잡으면, ‘코딩 에이전트’가 구현하고, ‘테스트 에이전트’가 검증한 뒤, ‘리뷰 에이전트’가 최종 승인하는 워크플로우를 설계

---

🔄 에이전틱 엔지니어링이 해결하는 문제

단순한 챗봇(Chatbot)과 에이전트(Agent)의 결정적인 차이는 ‘자율성’과 ‘반복’에 있다.

• Self-Reflection (자기 성찰): 에이전트가 생성한 결과물이 만족스럽지 않을 때, 스스로 “이게 최선인가?”라고 묻고 수정하게 만든다. (Reflexion 기법)
• Error Recovery (오류 복구): 코드 실행 중 에러가 발생하면, 에러 메시지를 보고 스스로 코드를 수정하여 다시 실행한다.
• State Management (상태 관리): 긴 작업 과정에서 현재 어디까지 진행되었는지, 다음 단계는 무엇인지 상태를 추적한다.

---

💡 4대 축의 완성: 왜 에이전틱인가?

에이전틱 엔지니어링은 앞서 설명한 모든 축을 집대성 한다.

• Prompt: 에이전트에게 페르소나와 사고 방식을 부여
• Context: 에이전트가 도구를 사용해 찾아온 실시간 정보를 관리
• Harness: 자율적인 에이전트가 무한 루프에 빠지거나 엉뚱한 API를 호출하지 않도록 제어

예시: “우리 회사의 지난 3년간 매출 데이터를 분석해서 보고서 써줘”라는 요청을 받았을 때, 에이전틱 엔지니어링이 적용된 시스템은 스스로 SQL을 짜서 데이터를 뽑고(Tool), 수치를 검토하며(Reflection), 부족한 데이터는 추가로 검색(RAG)하여 보고서를 완성한다.

이 예시는 동작 방향을 설명한다. 실제 시스템에서는 모델이 만든 SQL을 운영 DB에 그대로 실행하면 안 된다. 읽기 전용 계정, 허용된 테이블, 쿼리 시간·결과 건수 제한, 사용자별 데이터 권한이 먼저 필요하다. 보고서의 숫자도 도구가 반환한 원본 집계와 대조해야 한다.

목표를 실행 단계로 바꾸는 방법

“보고서 작성”이라는 목표를 받으면 먼저 완료 조건을 정한다. 예를 들어 2023~2025년 매출, 원화 단위, 분기별 합계, 출처 쿼리 ID, 누락 기간 표시를 요구한다. 이 조건 없이 에이전트가 도구를 반복 호출하면 그럴듯한 문장은 만들어도 숫자가 맞는지 판단할 수 없다.

flowchart TD
    G[목표와 완료 조건] --> P[허용 도구와 실행 예산]
    P --> D{다음 행동 선택}
    D -->|데이터 필요| T[읽기 전용 조회]
    T --> O[결과·오류 관찰]
    O --> D
    D -->|근거 충분| R[보고서 초안]
    R --> V{숫자·형식 검증}
    V -->|통과| F[최종 결과]
    V -->|실패·예산 남음| D
    V -->|예산 소진| H[불완전한 상태 보고]

모델은 다음 행동을 제안하지만 서버가 허용 도구와 인자를 검사한 뒤 실행한다. 관찰 결과가 다시 상태에 들어가고, 검증에서 실패하면 제한된 횟수만 수정한다. 에이전트의 루프는 완료, 승인 대기, 실패, 예산 소진 중 하나로 반드시 끝나야 한다. LangGraph 워크플로와 에이전트 문서는 정해진 단계와 동적으로 도구를 고르는 실행을 구분한다.

상태에는 무엇을 남길까?

상태 필드	값의 예	쓰는 이유
goal	분기별 매출 보고서	루프의 목적 고정
approved_scope	2023~2025, 회사 전체	조회 범위 제한
observations	조회 ID, 집계값, 오류 코드	재시도와 근거 추적
steps_used	2/6	무한 반복 방지
status	running / waiting / complete / failed	재개와 UI 표시
artifact	초안 또는 보고서 URL	중간·최종 결과 구별

상태에 원본 개인정보를 무제한 누적하지 않는다. 큰 조회 결과는 접근 제어된 저장소에 두고 상태에는 식별자와 요약, 버전만 남긴다. 재개할 때는 현재 사용자의 권한을 다시 확인한다. LangGraph persistence는 스레드별 체크포인트와 재개를 설명한다.

도구 호출의 안전한 경계

모델이 반환한 도구 이름과 인자는 요청 데이터다. 서버가 승인한 도구 목록 외의 이름은 실행하지 않는다. 아래 함수는 실제 모델 API보다 바깥쪽에 놓는 검증 계층의 예다. DB 조회 함수 read_sales는 읽기 전용 연결을 사용하고 내부에서 현재 사용자의 접근 범위를 다시 검사한다고 가정한다.

from dataclasses import dataclass
from typing import Literal

@dataclass(frozen=True)
class ToolRequest:
    name: Literal["read_sales"]
    start_year: int
    end_year: int

def execute_tool(request: ToolRequest, *, read_sales):
    if request.name != "read_sales":
        raise ValueError("허용되지 않은 도구입니다.")
    if not (2023 <= request.start_year <= request.end_year <= 2025):
        raise ValueError("승인된 조회 기간을 벗어났습니다.")
    return read_sales(request.start_year, request.end_year)

이 코드는 허용 기간 검사만 보여준다. 외부에서 받아온 JSON은 먼저 ToolRequest에 해당하는 스키마로 파싱하고, 실제 호출 직전에 인증된 사용자와 DB 접근 권한을 검사해야 한다. “시스템 프롬프트에 읽기 전용이라고 썼다”는 이유로 쓰기 권한이 있는 DB 계정을 붙여 두면 제어가 되지 않는다. 도구가 실패하면 오류 코드를 상태에 기록하고 재시도 가능한지 분류한다. 조회는 제한적으로 재시도할 수 있지만 메일 발송이나 결제 같은 쓰기는 멱등 키와 승인 단계가 필요하다.

단일 에이전트와 멀티 에이전트 선택

한 에이전트가 데이터 조회와 보고서 작성만 하면 충분하다면 역할을 나누는 비용이 더 클 수 있다. 서로 다른 데이터 소스, 독립적인 검증, 별도 권한 경계가 있을 때 역할 분리가 의미 있다. “분석 담당”, “작성 담당”, “검증 담당”처럼 이름만 세 개 붙이면 호출이 늘고 책임은 흐려질 수 있다.

구조	적합한 상황	추가로 생기는 문제
고정 워크플로	순서와 도구가 정해짐	예외 경로를 코드로 설계해야 함
단일 에이전트	질문에 따라 도구 선택이 달라짐	도구 오선택과 루프 제한 필요
감독자 + 전문 에이전트	서로 다른 전문 작업을 조율	위임 결과 형식·권한 전달·중복 작업 관리

멀티 에이전트에서는 부모가 하위 작업에 필요한 정보만 넘긴다. 하위 에이전트가 전체 대화와 모든 도구 권한을 물려받으면 자료 유출과 비용 증가를 확인하기 어려워진다. 결과에는 사용한 자료 ID, 실패 이유, 완료 상태를 넣어 부모가 검증할 수 있게 한다. LangGraph 서브그래프 문서는 부모와 하위 그래프 사이의 상태 전달 방식을 설명한다.

결과를 어떻게 평가할까?

“보고서가 자연스러운가”만 평가하지 않는다. 분기 합계가 원본 집계와 일치하는지, 승인 범위 밖 데이터가 들어갔는지, 근거가 없는 숫자를 만들었는지, 실패 후 몇 번 재시도했는지 따로 측정한다. 같은 요청을 여러 번 실행해 도구 호출 수와 비용의 편차도 본다. 실패 사례에는 잘못된 도구 선택, 도구는 성공했지만 잘못 해석, 종료 조건을 놓침, 승인 없이 쓰기 시도를 포함한다.

에이전트가 자기 답을 다시 읽는 성찰 단계는 결함을 찾을 기회를 늘리지만, 같은 모델이 같은 오해를 반복할 수도 있다. 숫자 합계와 허용 범위처럼 코드로 판정할 수 있는 것은 결정적인 검사로 처리한다. 의미 판단이 필요한 부분은 사람 검토나 별도 평가자를 사용하고, 재시도 상한을 넘으면 불완전함을 명시한다(LangSmith 평가 가이드).

참고 문서

• LangGraph: Workflows and agents
• LangGraph: Persistence
• LangGraph: Subgraphs
• LangSmith: Evaluate applications