0. 일단 친구처럼 시작해보자

야, 요즘 어디 가도 "AI 에이전트" 소리가 들리지?

회사 기획팀도, 개발 블로그도, 심지어 유튜브 광고까지 다 "에이전트가 대신 해줍니다!"라고 외치고 있어.
근데 막상 "그래서 그게 기존 자동화랑 뭐가 달라?"라고 물어보면 대답이 애매해지는 경우가 많아.

"어… AI가 들어간 자동화?"
"어… 챗GPT가 대신 일하는 거?"

둘 다 반은 맞고 반은 틀렸어. 그래서 오늘은 이걸 진짜 기술적으로, 그런데 재밌게 정리해볼 거야.
용어 자랑 말고, 실제로 개발할 때 뭐가 달라지는지 중심으로.

1. 기존 자동화의 정체: 아주 성실한 로봇 알바생

먼저 기존 자동화를 욕할 생각은 전혀 없어. 오히려 이건 지금도 세상을 굴리는 핵심 기술이야.

1-1. 우리가 써온 자동화 3대 계열

이 셋의 공통점이 뭔지 알아?

"분기까지도 사람이 미리 다 그려놨다"는 거야.

if 문이 100개 있어도, 그 100개는 개발자가 손으로 쓴 거잖아.
즉 자동화의 지능은 코드 작성 시점(design time)에 이미 고정돼 있어.

1-2. 그래서 강한 점 (이거 진짜 중요)

1-3. 그런데 깨지는 순간

문제는 현실이 지저분하다는 거야.

예를 들어 "메일로 온 거래명세서를 ERP에 입력해줘"라는 업무를 RPA로 만들었다고 해보자.
잘 돌다가 거래처 하나가 PDF 양식을 바꾸면 그 순간 끝이야.

웹사이트 DOM 구조 살짝 바뀌면? 셀렉터 깨짐.
표 안에 열 하나 추가되면? 파싱 깨짐.

이게 업계에서 말하는 "브리틀(brittle) 자동화" — 유리처럼 단단하지만 잘 깨지는 자동화야.
그래서 RPA 도입한 회사들 유지보수 인건비가 은근히 많이 든다는 얘기가 계속 나왔지.

2. AI 에이전트의 정의: 목표를 주면 경로를 만든다

AI 에이전트를 학술적으로 말하면 이래.

이건 사실 러셀 & 노빅의 고전 AI 교과서에 나오는 "지능형 에이전트" 개념이랑 뿌리가 같아.
새로운 건 개념이 아니라, 그 판단 엔진 자리에 LLM이 앉았다는 점이야.

2-1. 에이전트를 구성하는 5개 부품

2-2. 가장 유명한 패턴: ReAct

ReAct는 Reason(추론) + Act(행동)를 번갈아 하는 방식이야. 2022년 논문으로 나와서 지금 거의 모든 에이전트 프레임워크의 기본기가 됐어.

Thought: 사용자가 "지난주 매출 이상치 찾아줘"라고 했다.
         먼저 DB에서 지난주 일별 매출을 가져와야 한다.
Action:  run_sql("SELECT date, revenue FROM sales WHERE ...")
Observation: [{"date":"2024-05-06","revenue":1200000}, ...]

Thought: 5월 9일 값이 평균의 4배다. 환불 데이터도 확인해야 한다.
Action:  run_sql("SELECT * FROM refunds WHERE date='2024-05-09'")
Observation: []

Thought: 환불 이슈는 아니다. 주문 테이블에서 중복 주문을 확인하자.
Action:  run_sql("SELECT order_id, COUNT(*) FROM orders ... HAVING COUNT(*)>1")
Observation: [{"order_id":"A-8821","count":37}]

Thought: 중복 주문 버그로 보인다. 결론을 리포트한다.
Final Answer: 5월 9일 매출 이상치는 주문 A-8821의 37회 중복 기록 때문입니다.

봤지? 여기서 결정적인 건 두 번째 쿼리를 무엇으로 할지 코드에 적혀 있지 않았다는 점이야.
첫 결과를 보고 런타임에 스스로 정한 거지. 기존 워크플로에선 불가능한 동작이야.

3. 핵심 비교: 도대체 뭐가 다른가

3-1. 가장 중요한 차이는 "실패하는 방식"이다

이거 진짜 개발자라면 가슴에 새겨야 해.

3-2. 자율성 레벨로 보면 더 명확해진다

많은 회사가 착각하는 게 있어. "우린 L4로 바로 간다!"
근데 현실에서 성공률 95%짜리 L4보다 성공률 99.9%짜리 L2 + 사람 승인이 훨씬 돈을 아껴주는 경우가 많아.
특히 결제·계약·고객 응대처럼 실수 비용이 큰 영역에선 더더욱.

4. 실무 예시로 감 잡기: 같은 일, 다른 접근

시나리오: "고객 문의 메일을 처리해줘"

차이가 보이지?
에이전트는 "조회 → 근거 확인 → 판단 → 실행"이라는 사람의 업무 흐름 자체를 흉내내.
그리고 이 흐름의 순서가 메일 내용에 따라 매번 달라져. 그게 핵심이야.

4-1. 개발자 입장에서 코드는 이렇게 생김

# 기존 자동화 (경로가 코드에 박혀 있다)
def handle_mail(mail):
    if "환불" in mail.subject:
        route_to("refund_team")
    elif "배송" in mail.subject:
        route_to("delivery_team")
    else:
        route_to("general")

# AI 에이전트 (도구만 주고 판단은 위임한다)
tools = [get_order, search_policy, issue_refund, draft_reply, ask_human]

agent = Agent(
    model="llm-v1",
    tools=tools,
    goal="고객 문의를 사내 정책에 맞게 해결하라",
    guardrails={
        "max_steps": 12,
        "require_approval": lambda t, a: t == "issue_refund" and a["amount"] > 100000,
        "budget_usd": 0.20,
    },
)
agent.run(mail.body)

여기서 개발자의 역할이 완전히 바뀌는 걸 느꼄 수 있어.

즉 절차 프로그래밍 → 환경·권한·정책 설계로 옮겨가는 거야.
이게 요즘 "AI 엔지니어" 채용 공고에서 프롬프트 스킬보다 시스템 설계·평가(Eval) 경험을 더 보는 이유기도 해.

5. 에이전트 기술 스택 훑어보기

5-1. 요즘 특히 뜨거운 건 "도구 연결 표준화"

에이전트가 아무리 똑똑해도, 툴이 없으면 그냥 수다쟁이야.
문제는 툴을 붙일 때마다 인증·스키마·에러 포맷을 다 따로 맞춰야 했다는 거지.

그래서 최근엔 도구를 서버 형태로 노출하고 에이전트가 표준 프로토콜로 붙는 방식이 확산되고 있어.
한 번 만든 "사내 DB 조회 도구"를 여러 에이전트가 재사용하는 구조.
이건 마이크로서비스가 REST로 통일됐던 흐름과 꽤 닮았어.

6. 냉정한 이야기: 에이전트가 실패하는 5가지 이유

6-1. 그럼 어디에 써야 이득인가

실무에서 가장 잘 먹히는 조합은 사실 하이브리드야.

예를 들어 "PDF에서 값 뽑기"는 LLM에게 맡기고,
"뽑은 값을 검증하고 DB에 넣고 재시도하는 부분"은 기존 워크플로 엔진이 하는 거지.
판단은 AI, 실행과 신뢰성은 엔지니어링 — 이게 2024~2025년 현업의 사실상 표준 패턴이야.

7. 처음 만들어 보는 사람을 위한 7단계 로드맵

혹시 "이거 혼자 하긴 좀 벅찬데?" 싶으면, 재능넷처럼 분야별 전문가와 직접 연결되는 재능 공유 플랫폼을 활용하는 것도 방법이야.
LLM 파이프라인 설계, RAG 구축, 사내 데이터 연동 같은 건 한 번 경험한 사람의 조언 30분이 삽질 3주를 줄여주기도 하니까.

8. 오해 정리 Q&A

9. 마무리: 결론은 딱 세 줄

솔직히 말하면, 앞으로 개발자가 짜는 코드의 상당 부분은
"기능을 만드는 코드"보다 "AI의 행동을 제한하고 검증하는 코드"가 될 거야.

브레이크 없는 스포츠카는 빠른 게 아니라 위험한 거잖아.
에이전트도 똑같아. 엔진은 모델이 주고, 브레이크는 우리가 만든다.

자, 이제 친구한테 "AI 에이전트가 뭐야?"라는 질문 받으면 이렇게 대답해도 돼.

"시키는 대로 하는 게 자동화, 방법을 스스로 찾는 게 에이전트. 근데 찾다가 삽질도 하니까 사람이 옆에서 브레이크는 잡아줘야 함."

이 한 줄이면 회의에서 90%는 통한다. 진짜로.