Agentic AI 다시 배우기 — 내 업무를 돕는 AI 시스템을 만든다면

Andrew Ng의 Agentic AI 강의를 들었지만, 시간이 지나니 내용이 흐릿해졌다. Reflection, Tool Use, Planning, Multi-agent. 용어는 기억나는데, 실제로 무엇을 하는 구조였는지 설명하려면 잠시 멈추게 된다.

그래서 이번에는 가장 작은 실습부터 다시 따라가 보려고 한다. AI에게 에세이를 한 번 써 달라고 하는 것과, 초안을 쓰고 검토한 뒤 수정하게 하는 것은 어떻게 다른가?

그 차이를 이해한 다음 검색과 계산, 평가, 계획과 역할 분담으로 넓혀 가겠다. 마지막에는 로토크 Inside Sales 업무에 대입하고, 이런 프로그램을 AI의 도움으로 어떻게 만들 수 있을지 생각해 본다.

1절부터 6절까지는 보관한 강의 실습을 중심으로 작동 원리를 풀어 쓴 복습이다. 7절부터 9절까지의 업무 적용과 개발 방법은 이번에 덧붙인 가상 설계다. 회사의 실제 시스템·가격·정책을 설명하지 않는다. 코드는 이해를 위해 새로 줄여 썼으며, 모델 호출을 포함한 예시는 완성 프로그램이 아닌 의사코드다.

1. 한 번 답하게 하는 것과, 결과를 받아 다시 일하게 하는 것

AI에게 에세이를 써 달라고 요청한다고 하자.

가장 단순한 프로그램은 주제를 모델에 보내고, 돌아온 글을 그대로 보여 준다.

주제 → 모델 호출 → 글

여기서 모델 호출은 프로그램이 모델에 입력을 보내고 응답을 받는 한 번의 요청을 뜻한다. 입력에는 “이 주제로 에세이를 써 줘” 같은 지시와 자료를 넣을 수 있고, 출력으로는 생성된 글을 받는다.

처음 나온 글에 설명이 빠졌다면 어떻게 할까? 사람이 읽고 “이 부분을 보완해 줘”라고 다시 요청할 수 있다. 이 검토와 수정 절차를 프로그램 안에 넣을 수도 있다.

강의의 2주차 과제인 Reflection in a Research Agent가 바로 그 예다.

앞에서 나온 결과를 다음 호출의 입력으로 사용하는 것이 핵심이다. 검토 단계에는 실제 초안을 주고, 수정 단계에는 초안과 검토 의견을 함께 준다.

사용자가 주제를 한 번 입력해도 프로그램 내부에서는 세 번의 요청이 이어진다. 사람이 매번 복사해서 붙여 넣던 일을 프로그램이 연결하는 셈이다. 프로그램을 만들지 않고 대화로 이 순서를 직접 따라 해 보는 것도 원리를 이해하는 좋은 출발점이다.

이 실습은 Agentic Workflow, 즉 AI가 여러 단계에 걸쳐 작업을 수행하도록 구성한 흐름의 기본적인 예다. 이때 각 단계의 순서를 모델이 스스로 정하는 것은 아니다. 사람이 미리 정한 작성 → 검토 → 수정 순서를 따른다.

더 나아가 모델이 필요한 도구를 고르거나, 중간 결과에 따라 다음 작업을 정하게 할 수도 있다. 자율성에는 정도의 차이가 있는 것이다. 단순히 함수를 여러 번 호출했다고 모두 같은 수준의 자율적인 에이전트가 되는 것은 아니다.

이 글에서 비교하는 것은 이런 호출과 작업 흐름의 차이다. 오늘날의 채팅 서비스도 내부에서 도구와 여러 단계를 사용할 수 있으므로, 채팅창으로 쓰면 비에이전트이고 별도 프로그램이면 에이전트라는 구분은 아니다.

2. Reflection — 초안과 피드백이 어떻게 연결되는가

앞의 실습에서 사용한 패턴이 Reflection이다. 생성한 결과를 검토하고, 그 피드백으로 결과를 고친다.

과제에는 generate_draft, reflect_on_draft, revise_draft라는 함수가 나온다. 함수 이름만 외우지 말고, 안에서 모델에 무엇을 전달하는지 보자.

아래는 실습의 구조를 설명하기 위해 새로 쓴 의사코드다. ask(prompt)는 문자열을 모델에 보내고 응답 문자열을 받는 호출 함수라고 가정한다. 실제 API 연결은 생략하고, 세 번의 입력이 어떻게 달라지는지만 드러냈다.

topic = "도시의 녹지가 생활에 미치는 영향"

draft = ask(f"다음 주제로 짧은 에세이를 써 줘.\n주제: {topic}")

feedback = ask(
    "다음 초안의 논리, 빠진 설명, 표현의 문제를 지적해 줘. "
    "아직 글을 다시 쓰지는 마.\n"
    f"초안:\n{draft}"
)

revised = ask(
    "검토 의견을 반영해 초안을 수정해 줘.\n"
    f"초안:\n{draft}\n\n"
    f"검토 의견:\n{feedback}"
)

draft에는 첫 번째 응답인 에세이가 저장된다. 두 번째 요청은 그 문자열을 포함한다. feedback에는 두 번째 응답인 비평이 저장되고, 세 번째 요청은 두 문자열을 모두 포함한다.

즉 모델이 이전 호출을 저절로 기억한다고 가정하지 않는다. 프로그램이 필요한 내용을 명시적으로 다시 전달한다.

검토와 수정을 나누는 이유도 있다. “더 좋게 써 줘”라고만 하면 무엇이 문제였는지 알기 어렵다. 먼저 문제를 지적하게 하면, 수정본이 그 문제를 실제로 고쳤는지 비교할 수 있다.

한 번 더 생각한다고 맞는 것은 아니다

모델은 초안을 쓸 때와 같은 잘못된 가정을 검토할 때도 사용할 수 있다. 틀린 내용을 더 자연스러운 문장으로 바꿀 수도 있다.

그래서 원문, 테스트 결과, 계산 결과처럼 모델 밖에서 확인할 수 있는 피드백이 도움이 된다. 예를 들어 코드라면 실행 오류와 테스트 결과를 돌려줄 수 있다. 다만 테스트가 불완전하면 통과한 코드도 틀릴 수 있다.

Reflection은 개선을 시도하는 방법이지 정확성 보증이 아니다. 또한 이 예시는 모델을 재훈련하는 과정이 아니다. 초안과 피드백을 새 입력으로 사용해 이번 결과물을 고치는 과정이다.

3. Tool Use — 모델의 요청을 프로그램이 실행한다

모델에게 “지금 몇 시야?”라고 물었다고 하자. 현재 시각을 입력받거나 시계에 접근하지 못한다면, 언어 생성 능력만으로 지금 시간을 확인할 수는 없다.

3주차 Turning Functions into Tools 실습은 현재 시간을 반환하는 Python 함수를 도구로 연결한다. 이런 간단한 함수부터 출발한다.

from datetime import datetime

def get_current_time():
    """이 프로그램이 실행되는 환경의 현재 시각을 반환한다."""
    return datetime.now().strftime("%H:%M:%S")

함수를 정의하는 것만으로 모델이 사용할 수 있는 것은 아니다. 프로그램은 모델에 어떤 도구가 있고, 무슨 일을 하며, 어떤 입력이 필요한지 알려 줘야 한다.

그 뒤의 흐름은 다음과 같다.

1. 사용자가 현재 시간을 묻는다.
2. 모델이 get_current_time을 호출해 달라고 요청한다.
3. 프로그램이 그 함수를 실행한다.
4. 프로그램이 함수의 반환값을 모델에 전달한다.
5. 모델이 그 값을 이용해 답한다.

모델은 호출을 요청하고, 실행 환경은 실제 함수를 실행한다. 도구 호출을 관리하는 라이브러리가 이 연결을 대신해 줄 수도 있지만, 이 구분 자체가 없어지는 것은 아니다.

위 함수가 돌려주는 것은 실행 환경의 로컬 시각이다. 사용자 지역의 시각이 필요하면 시간대도 처리해야 한다.

시간 조회에서 검색과 이메일로

같은 구조를 검색 함수나 계산 함수에도 적용할 수 있다. 모델이 도구 이름과 인자를 선택하고, 프로그램이 실행 결과를 돌려준다.

3주차의 Email Assistant Workflow는 모의 이메일 서버를 사용한다. 검색, 읽음 표시, 발송 같은 기능을 도구로 연결한다. 연구 보고서 과제에서는 웹과 논문 검색 도구를 사용한다.

여기서 두 가지를 혼동하면 안 된다.

• “이메일을 보냈습니다”라는 문장을 생성하는 것
• 실제 발송 함수가 성공한 결과를 받는 것

조회만 하는 도구와 외부 상태를 바꾸는 도구도 다르다. 실제 서비스에 적용할 때는 입력 검사, 권한, 실패 처리와 실행 기록을 프로그램에 넣어야 한다. 이 운영상의 경계는 도구가 연결됐다는 사실만으로 생기지 않는다.

4. Evaluation — 여러 단계를 붙였더니 정말 좋아졌는가

초안을 검토하게 했다. 검색 도구도 붙였다. 그 결과가 좋아졌는지는 무엇으로 확인할까?

이 질문에 답하는 것이 Evaluation, 즉 평가다.

4주차 Adding a Component-level Eval to the Research Workflow 실습은 연구 보고서 전체가 아니라 검색 단계만 따로 본다. 검색 결과의 URL을 추출해, 미리 정한 선호 도메인에서 나온 결과의 비율을 계산한다.

예를 들어 아래 세 URL을 가져왔다고 가정하자. 실습의 계산 원리를 보여 주기 위한 가상 목록이지, 실제 검색 결과나 측정값은 아니다.

from urllib.parse import urlsplit

urls = [
    "https://arxiv.org/",
    "https://www.nasa.gov/",
    "https://example.com/",
]
preferred = {"arxiv.org", "nasa.gov"}

def is_preferred(url):
    host = (urlsplit(url).hostname or "").lower()
    return any(host == d or host.endswith("." + d) for d in preferred)

ratio = sum(is_preferred(url) for url in urls) / len(urls) if urls else 0.0
print(round(ratio, 2))  # 0.67

셋 중 둘이 정해 둔 도메인에 해당한다. 이것은 출처 선택에 관한 하나의 지표다. 보고서가 67% 정확하다는 뜻은 아니다. 신뢰하는 사이트에서도 질문과 무관한 페이지를 가져올 수 있다. 검색 결과가 비었을 때 0으로 두는 것도 이 예제의 규칙이다.

좋은 평가는 숫자를 만드는 데서 끝나지 않는다. 그 숫자가 무엇을 확인하며 무엇을 확인하지 못하는지 알아야 한다.

최종 결과와 중간 단계를 따로 본다

• End-to-End Evaluation: 최종 보고서가 사용자의 질문에 제대로 답했는가?
• Component-level Evaluation: 검색·자료 선택·작성 등 특정 단계가 제 역할을 했는가?

보고서가 틀렸다면, 잘못된 자료를 검색했을 수도 있고 올바른 자료를 잘못 요약했을 수도 있다. 두 경우는 고칠 곳이 다르다.

그래서 단계별 입력과 출력, 도구 호출과 오류를 남기는 trace, 실행 기록을 살펴본다. 모델의 숨은 사고를 추측하는 것이 아니라, 실제로 관찰할 수 있는 작업 과정을 확인한다.

정답이 명확한 수량이나 날짜는 코드로 비교할 수 있다. 설명의 명확성처럼 판단이 필요한 부분은 기준표를 주고 모델 평가자를 활용할 수도 있지만, 그 판단 역시 사람과 대조해야 한다.

개선에 사용한 사례뿐 아니라 별도의 사례에서도 시험하고, 품질과 함께 비용·응답 시간을 비교한다. 검토 한 번을 추가했는데 오류는 그대로이고 시간만 늘었다면 좋은 개선이라고 하기 어렵다.

Reflection은 이번 결과를 고치는 절차이고, Evaluation은 그 절차가 도움이 되는지 확인하는 시험이다.

5. Planning — 다음에 무엇을 할지 누가 정하는가

앞의 에세이 실습은 작성 → 검토 → 수정 순서가 정해져 있다. 모든 요청에 같은 순서를 적용한다.

반면 사용자의 요청에 따라 해야 할 일이 달라질 수도 있다.

5주차 Customer Service Agent 실습은 선글라스 가게를 가정한다. 재고와 거래 기록이 있고, 고객은 재고를 묻거나 구매·반품을 요청한다. 예를 들면 다음과 같다. 아래는 실습 요청을 한국어로 풀어 쓴 것이다.

• 100달러 미만의 둥근 선글라스가 재고에 있는지 묻는다.
• 지난주 산 Aviator 선글라스 두 개를 반품해 달라고 한다.

첫 번째는 조건에 맞는 재고를 조회하면 된다. 두 번째는 반품에 따른 재고와 거래 기록의 변경이 필요하다. 같은 작업을 그대로 반복할 수 없다.

이 실습에서는 모델이 Python 코드로 작업 순서를 표현한다. 데이터를 조회하고 조건으로 걸러 내거나, 필요한 갱신을 수행할 코드를 생성한다. 실행 프로그램은 그 코드를 받아 실행하고 결과와 변경 전후 상태를 보여 준다.

이것이 실습에서 다룬 Planning with Code Execution이다. 계획이 단순한 할 일 목록이 아니라, 실행할 수 있는 코드로 표현되는 것이다. 모델이 코드를 생성하는 단계와 프로그램이 실행하는 단계는 여전히 구분된다.

고정된 흐름과 계획은 함께 쓸 수 있다

Planning은 수행할 작업과 순서를 정하는 패턴이다. 처음에 전체 계획을 만들 수도 있고, 실행 결과에 따라 다음 행동을 조정할 수도 있다. 모든 계획이 코드 형태여야 하는 것도 아니다.

차이를 단순화하면 다음과 같다.

고정된 규칙으로 충분한 부분까지 모델에게 맡길 필요는 없다. 필요한 정보가 없으면 사람에게 확인한다는 규칙은 코드로 정해 둘 수 있다.

또한 강의의 모의 가게를 실제 업무 DB로 바꾸고 생성 코드를 그대로 실행해서는 안 된다. 제한된 실행 네임스페이스나 “위험한 코드를 만들지 마”라는 지시만으로 충분한 보안 격리가 되지는 않는다. 실제 시스템에서는 접근 권한과 실행 환경, 시간·비용 한도와 중단 조건을 별도로 설계해야 한다.

6. Multi-agent — 역할을 나누면 무엇이 달라지는가

하나의 에이전트가 검색부터 작성과 검토까지 할 수도 있다. 서로 다른 역할로 나눌 수도 있다.

5주차 Agentic Workflows 과제는 연구 보고서를 만들면서 다음 역할을 사용한다.

과제의 Executor는 작업을 담당 에이전트에 전달하고, 이전 결과를 다음 작업의 문맥으로 제공한다.

여기서 에이전트는 서로 다른 사람이나 반드시 다른 모델을 뜻하지 않는다. 역할별 지시, 제공하는 자료, 사용할 수 있는 도구를 구분한 실행 단위로 이해하면 된다. 같은 모델을 사용해도 이런 구성이 가능하다.

Research Agent에는 검색 도구와 조사할 질문을 주고, Writer Agent에는 조사 결과와 글의 목적을 준다. Editor Agent에는 검토 대상과 기준을 준다. 따라서 중요한 것은 에이전트 이름보다 어떤 역할이 무엇을 받아서 무엇을 넘겨주는가다.

여러 에이전트가 동의해도 틀릴 수 있다

자료를 찾은 에이전트가 출처와 미확인 항목을 빼고 전달하면, 다음 에이전트는 그 빈틈을 모른 채 글을 쓸 수 있다. 같은 모델과 비슷한 자료를 쓰면 오류도 겹칠 수 있다.

역할을 나누면 전문화와 정보 분리에 도움이 될 수 있지만, 호출 비용과 지연, 소통과 통합의 부담이 늘어난다.

따라서 “여러 개니까 더 좋다”가 아니라 하나로 처리할 때보다 어떤 문제가 줄었는지 평가해야 한다. 네 가지 패턴을 전부 넣어야 완성되는 것도 아니다.

7. 내 업무에 옮겨 보기 — 고객 회신 초안을 검토한다면

여기부터는 강의의 사례가 아니라, 앞에서 이해한 구조를 업무에 적용해 보는 가상 예시다.

나는 로토크에서 Inside Sales Engineer로 일한다. 고객의 요구사항을 읽고, 액추에이터 선정과 견적, 수주 과정을 다룬다.

처음부터 AI에게 제품 선정과 견적 확정까지 맡기기보다, 고객 문의에 대한 확인 질문 초안을 만드는 작은 작업부터 생각해 보자.

다음 이메일을 받았다고 가정한다.

전동 액추에이터 3대의 견적을 요청합니다.

2026년 11월 20일까지 현장 입고가 필요합니다.

견적은 2026년 10월 2일까지 회신 부탁드립니다.

이 예시에서는 전원 사양이 제공되지 않았고, 확인 질문에 그 항목을 포함하기로 했다고 하자. 실제 제품 선정에 필요한 전체 조건을 이 이메일이나 예제가 대신하는 것은 아니다.

한 번의 호출은 바로 회신을 작성하게 한다. Reflection을 적용하면 초안 작성 → 고객 원문과 대조 → 수정으로 나눈다.

앞에서 쓴 ask()를 사용하면 입력은 이렇게 바뀐다.

# 의사코드: 위 가상 이메일을 email 문자열에 넣었다고 가정한다.
rules = (
    "없는 전원 사양은 추측하지 말고 확인 질문에 넣어라. "
    "견적 회신 기한과 현장 입고 요청일을 구분하라. "
    "고객 요청일을 공급자가 확정한 납기로 표현하지 마라."
)

draft = ask(
    f"다음 기준으로 고객 회신 초안을 써라.\n{rules}\n"
    f"고객 원문:\n{email}"
)
feedback = ask(
    f"다음 기준으로 원문과 초안의 불일치를 지적하라.\n{rules}\n"
    f"고객 원문:\n{email}\n\n초안:\n{draft}"
)
revised = ask(
    f"원문과 기준을 지키면서 피드백을 반영하라.\n{rules}\n"
    f"고객 원문:\n{email}\n\n초안:\n{draft}\n\n피드백:\n{feedback}"
)

강의의 에세이를 고객 회신으로 바꿨지만, 이전 결과와 검토 의견을 다음 호출로 전달하는 구조는 같다. 업무상 사실을 확인해야 하므로 검토 단계에도 고객 원문과 기준을 함께 넣었다.

이 기준 문장은 이해를 위한 지시이지, 항상 준수된다는 보증은 아니다. 실제로 날짜를 혼동하거나 전원을 만들어 내는지 시험해야 한다.

가령 다음은 실제 모델 실행 결과가 아니라, 평가를 설계하기 위한 오류 예시다.

단지 문장이 공손한지보다, 이런 오류가 줄었는지를 보는 것이 이 작업의 Evaluation이다.

조회와 계산이 필요해진다면

승인된 제품 문서나 납기 정보를 확인해야 한다면 Tool Use를 연결할 수 있다. 요청마다 필요한 조회 순서가 달라지면 Planning을 검토한다. 기술 검토와 상업 검토를 분리할 이유가 생기면 Multi-agent를 검토한다.

계산은 명확한 함수로 맡길 수 있다. 예를 들어 **가상 원가 70만 원과 매출총이익률 30%**를 입력하면, 판매가는 원가 ÷ (1 − 이익률)로 계산한다.

from decimal import Decimal, ROUND_HALF_UP

def calculate_price(cost: str, margin: str) -> str:
    c, m = Decimal(cost), Decimal(margin)
    if not c.is_finite() or not m.is_finite():
        raise ValueError("유한한 숫자가 필요합니다.")
    if c < 0 or not Decimal("0") <= m < Decimal("1"):
        raise ValueError("원가 또는 이익률의 범위가 잘못됐습니다.")
    return str(
        (c / (1 - m)).quantize(Decimal("1"), rounding=ROUND_HALF_UP)
    )

print(calculate_price("700000", "0.30"))  # 1000000

70만 원에 30%를 더하는 것은 원가 기준 가산율 계산이지 매출액 기준 이익률 계산이 아니다. 원 단위 반올림은 이 예제를 위한 규칙이다. 실제 견적의 운임·세금·환율·할인과 회사 정책을 구현한 코드는 아니다.

또한 함수가 있다고 바로 Tool Use가 구현된 것은 아니다. 이 함수를 모델이 요청할 수 있는 도구로 등록하고, 요청 검증·실행·결과 반환을 연결해야 한다. 적용할 원가와 이익률도 모델이 임의로 정하는 대신 승인된 입력을 받아야 한다.

8. 그렇다면 이 프로그램은 어떻게 만드는가?

여기까지 이해하면 처음의 개발 질문으로 넘어갈 수 있다.

“저장소를 만들고, 프런티어 모델과 브레인스토밍해서 강의에서 본 구조를 코드로 구현하면 되는 것인가?”

큰 방향은 그렇다. 프런티어 모델이라는 말은 여기서 설계와 코딩을 도울 수 있는 고성능 범용 모델을 가리킨다. 다만 두 역할을 구분해야 한다.

같은 모델을 써도 되고 달라도 된다. 새로운 모델을 직접 훈련하는 것이 아니라, 기존 모델을 호출하는 애플리케이션을 개발하는 것으로 시작할 수 있다.

개발 모델에게 무엇을 부탁할까

앞의 회신 사례라면 다음처럼 요청할 수 있다.

합성 고객 이메일로 회신 초안을 만드는 Python 프로그램을 만들고 싶다.

먼저 모델을 한 번 호출하는 버전을 만들자. 그다음 원문과 초안을 대조하는 검토 호출, 피드백을 반영하는 수정 호출을 붙이자.

각 호출에 실제로 어떤 문자열이 들어가는지 볼 수 있게 해 줘.

날짜 혼동, 없는 전원 사양의 추측, 고객 요청일의 확정 납기 표현을 시험할 사례도 함께 만들자.

이메일 발송과 실제 회사 시스템 연결은 하지 않는다.

이 요청은 단순히 “Agentic AI를 만들어 줘”보다 구현하고 확인할 대상이 분명하다.

모델과 합의한 뒤에는 코드 파일을 만들고 실행한다. 오류가 나면 실행 기록을 보고 고친다. 실행되더라도 결과가 업무 기준에 맞는지는 별도로 확인한다. 내가 설명하지 않은 업무 기준까지 모델이 정확히 알아서 정한다고 기대해서는 안 된다.

Repo는 무엇을 보관하는가

Repo(repository, 저장소)는 프로그램과 변경 이력을 관리하는 곳이다. 처음에는 다음 정도로도 시작할 수 있다.

inside-sales-assistant/       # 가상의 작은 프로젝트
├── README.md                 # 목적, 실행 방법, 하지 않는 일
├── model_client.py           # ask()가 실제 모델을 호출하는 부분
├── workflow.py               # 초안 → 검토 → 수정 연결
└── tests/                    # 합성 이메일과 검사 기준

반드시 이 폴더 구성을 따라야 하는 것은 아니다. 강의처럼 노트북에서 먼저 시험할 수도 있다. 저장소가 에이전트를 만드는 것이 아니라, 모델 호출과 도구, 데이터 전달을 구현한 프로그램이 동작하는 것이다.

개발 대화에서 “전원을 추측하지 마”라고 말한 내용은 운영 모델에 저절로 전달되지 않는다. 프로그램의 지시와 검사 기준, 평가 사례로 남겨야 한다. API 키와 실제 고객 자료는 공개 저장소에 넣지 않는다.

또한 개발 중 모델과 계획을 의논했다고 제품에 Planning이 구현된 것은 아니다. 여러 모델에게 코드를 검토받았다고 제품이 Multi-agent인 것도 아니다. 개발 과정의 협업과 완성된 프로그램의 동작은 다른 층위다.

9. 첫 버전은 작게 만들고, 비교하면서 넓힌다

지금까지의 강의 복습을 실제 개발 순서로 옮긴다면 다음처럼 시작하겠다. 이것은 강의의 필수 구축 절차가 아니라, 앞의 가상 업무에 대한 내 제안이다.

1. 합성 이메일과 기대 결과를 준비한다. 수량·두 날짜·알 수 없는 전원, 그리고 허용하지 않을 확정 표현을 정한다.
2. 한 번의 모델 호출로 초안을 만든다. 이를 비교 기준으로 남긴다.
3. 검토와 수정 호출을 붙인다. 각 단계의 입력과 출력을 보관한다.
4. 같은 사례에서 비교한다. 오류와 사람의 수정량이 줄었는지, 시간과 비용이 얼마나 늘었는지 본다.
5. 다른 사례에서도 시험한다. 날짜 표현이 다르거나 이메일과 첨부자료가 충돌하는 경우처럼 조건을 바꾼다.
6. 필요가 확인된 부분만 확장한다. 승인된 자료 조회나 계산을 붙이고 다시 평가한다.

작업이 단순하다면 고정된 워크플로만으로 충분할 수 있다. 동적 계획과 여러 에이전트가 필요하다는 결론은 실행해 보기 전에 정하지 않아도 된다.

실제 회사 자료를 사용하려면 데이터 처리 정책과 사용 승인을 먼저 확인해야 한다. 제품 선정은 검증된 기술 기준과 선정 절차를 따라야 하며, 간단한 예제 코드로 대신할 수 없다.

고객용 초안을 만드는 것과 고객에게 발송하는 것도 별개의 권한이다. 고객이 보낸 문서는 읽을 자료이지 시스템의 권한을 바꾸는 지시가 아니다. 실제 적용 시에는 모델의 지시문뿐 아니라 도구 접근과 외부 전송을 실행 환경에서 제한해야 한다.

이 경계들은 업무에 적용하기 위해 추가로 설계할 사항이다. 사람의 승인이나 견적 업무 규칙 자체가 Agentic AI의 정의인 것은 아니다.

10. 복습 — 결국 무엇을 기억해야 하는가

강의 실습과 핵심 질문을 다시 연결해 보자.

가장 작은 출발점은 이 문장으로 기억할 수 있다.

한 번의 응답을 곧바로 끝으로 삼는 대신, 중간 결과와 피드백을 다음 작업에 활용하도록 흐름을 설계한다.

그 위에 필요한 도구와 계획, 역할 분담을 붙일 수 있다. 하지만 단계나 에이전트가 많다는 사실은 성능의 증거가 아니다. 실제 효과는 평가해야 한다.

모델이 코드를 써 줄 수 있는데도 강의를 복습하는 이유는 여기에 있다. 무엇을 만들게 할지, 어떤 구조가 필요한지, 제대로 만들어졌는지를 판단하려면 원리를 알아야 한다.

노트를 덮고 답해 볼 질문

1. 에세이를 세 번 따로 생성하는 것과 초안 → 검토 → 수정은 무엇이 다른가?
2. 수정 호출에 초안과 검토 의견을 모두 넣는 이유는 무엇인가?
3. 도구 호출 요청과 실제 실행은 누가 각각 담당하는가?
4. 선호 도메인 비율이 높아도 보고서가 틀릴 수 있는 이유는 무엇인가?
5. 고정 워크플로와 모델의 Planning은 어떻게 다른가?
6. 여러 역할을 나누면 무엇이 좋아지고 어떤 부담이 늘어나는가?
7. 고객 회신 예제에서 검토를 추가한 효과를 어떻게 확인할까?
8. 개발을 돕는 모델과 프로그램이 호출하는 모델은 어떻게 다른가?

이 질문에 자기 사례로 답할 수 있다면, 용어를 기억하는 것에서 실제로 구조를 이해하는 쪽으로 한 걸음 나아간 것이다.

복습에 사용한 자료

• Andrew Ng, DeepLearning.AI, Agentic AI 과정.
• Week 2 과제: Reflection in a Research Agent — 초안·비평·수정의 입력과 출력.
• Week 3 실습·과제: Turning Functions into Tools, Email Assistant Workflow, Tool Use and Reflective Agents — 함수 연결, 모의 이메일, 검색 도구를 사용하는 연구 흐름.
• Week 4 실습: Adding a Component-level Eval to the Research Workflow — 검색 결과의 선호 도메인 비율 평가.
• Week 5 실습·과제: Customer Service Agent, Agentic Workflows — 선글라스 가게의 코드 계획과 역할별 연구 흐름.

강의 녹취나 과제 해답을 재게시한 글이 아니라, 보관한 실습의 구조를 바탕으로 설명을 다시 쓴 개인 복습 글이다. 1주차 노트는 대부분 목차여서 상세 설명의 근거로 사용하지 않았다. 주제·프롬프트·업무 예시와 축약 코드는 새로 작성했다. 모델 API와 실제 회사 시스템을 연결해 운영 성능을 검증한 글은 아니다.

함께 읽으면 좋은 글

• Build with Andrew vs Claude Code: 두 강좌의 메타 합성 — vibe coding의 두 호라이즌