에이전틱 워크플로우란 무엇인가? 계획하고, 실행하고, 평가하는 워크플로우 구축 방법

에이전틱 워크플로우란 무엇인가?
에이전틱 워크플로우는 AI 에이전트와 어떻게 다른가?
에이전틱 워크플로우의 핵심 부분은 무엇인가?
에이전틱 워크플로우 구축에서 계획이 중요한 이유
에이전틱 워크플로우에서 도구 사용은 어떻게 작동해야 하는가?
코드 실행에 샌드박스가 필요한 이유는 무엇인가?
에이전틱 워크플로우를 어떻게 평가하는가?
에이전틱 워크플로우 구축을 위한 실용적인 아키텍처
예시: Python의 에이전틱 워크플로우 컨트롤러
플래너로 어떤 모델을 사용해야 하는가?
에이전틱 워크플로우의 일반적인 실패 모드
에이전틱 워크플로우를 사용하지 말아야 할 때는?
FAQ
추천 글

에이전틱 워크플로우는 언어 모델이 단순히 한 번 응답하는 것을 넘어, 계획을 세우고, 도구를 선택하며, 작업을 실행하고, 결과를 확인한 후, 작업이 완료될 때까지 다음에 무엇을 할지 결정하는 다단계 시스템입니다. 실제로는 LLM 추론 계층과 도구 호출, 실제 실행 환경, 그리고 평가 루프를 결합하는 것을 의미합니다. 코딩 에이전트, 연구 에이전트, 또는 작업 중간에 적응해야 하는 내부 자동화를 구축하는 경우, 이것이 일반적으로 실제로 구축하게 될 아키텍처입니다.

에이전틱 워크플로우란 무엇인가?

에이전틱 워크플로우는 텍스트 생성에서 멈추지 않고 작업을 통해 진행할 수 있는 AI 시스템의 기본 패턴입니다. 모델에 하나의 응답을 요청하고 사용자에게 반환하는 대신, 모델이 통제된 루프 내에서 작동하도록 합니다:

목표와 현재 상태를 읽습니다.
다음 단계를 계획합니다.
도구를 호출하거나 코드를 실행합니다.
결과를 관찰합니다.
작업이 완료되었는지 평가합니다.
필요하면 반복합니다.

이는 각 단계가 코드에 미리 작성된 고정 워크플로우와는 다릅니다. 고정 워크플로우에서는 경로를 사전에 결정합니다. 에이전틱 워크플로우에서는 사용자가 제공한 경계 내에서 모델이 다음에 어떤 작업을 수행할지 결정합니다.

이 차이는 많은 실제 개발자 작업이 선형적이지 않기 때문에 중요합니다. 코딩 에이전트는 어떤 테스트를 실행해야 하는지 알기 전에 파일을 검사해야 할 수도 있습니다. 연구 에이전트는 첫 번째 소스가 불완전했기 때문에 두 번 검색해야 할 수도 있습니다. 브라우저 에이전트는 로그인 실패나 변경된 페이지 레이아웃에서 복구해야 할 수도 있습니다. 이러한 것들은 워크플로우 문제이지만 적응이 필요합니다.

에이전틱 워크플로우는 AI 에이전트와 어떻게 다른가?

사람들은 종종 이 두 용어를 혼용하지만, 분리하는 것이 더 유용합니다:

에이전틱 워크플로우 는 실행 패턴입니다.
AI 에이전트 는 해당 패턴 위에 구축된 제품 또는 시스템입니다.

지원 티켓만 분류하는 범위가 제한된 에이전틱 워크플로우를 가질 수도 있고, 많은 작업에 걸쳐 계획, 도구 사용, 메모리 및 승인 체크포인트를 조정하는 광범위한 AI 에이전트를 가질 수도 있습니다.

실용적인 규칙을 원한다면, 아키텍처와 제어 흐름에 대해 이야기할 때는 **워크플로우 ** 를 사용하고, 사용자 대면 시스템에 대해 이야기할 때는 에이전트 를 사용하세요.

에이전틱 워크플로우의 핵심 부분은 무엇인가?

대부분의 프로덕션 시스템은 결국 동일한 다섯 가지 부분으로 구성됩니다.

1. 플래너

플래너는 광범위한 명령을 다음 구체적인 작업으로 전환합니다. 이는 때로는 작업 목록을 출력하는 명시적인 계획 단계입니다. 때로는 암시적이며 각 도구 호출 턴 내에서 발생합니다. 어느 쪽이든, 모델은 읽기, 쓰기, 검색, 실행 또는 중지 중 어떤 작업을 수행해야 하는지 결정하기에 충분한 컨텍스트가 필요합니다.

좋은 계획이 모든 요청에 대해 긴 개요를 생성한다는 의미는 아닙니다. 다음 움직임을 명확하게 유지하는 것을 의미합니다. 짧은 작업의 경우 원스텝 계획으로 충분합니다. 리포지토리 리팩터링, 브라우저 자동화 또는 문서 검토와 같은 긴 작업의 경우 명시적인 계획이 불필요한 반복을 줄여줍니다.

2. 도구 계층

도구는 워크플로우와 외부 세계 간의 인터페이스입니다. 강력한 도구 계층은 일반적으로 좁고 예측 가능합니다. 예를 들어:

read_file(path)
write_file(path, content)
search_files(query)
run_command(cmd)
fetch_url(url)

작은 도구는 모델이 올바르게 호출하기 쉽고, 로깅하기 쉬우며, 보안을 유지하기 쉽습니다. “무엇이든 하는” 대규모 도구는 처음에는 편리해 보이지만, 실패가 모델 결정, 도구 구현 또는 그 뒤에 있는 외부 시스템 중 어디에서 발생했는지 알 수 없기 때문에 디버그하기 어려워집니다.

3. 실행 런타임

모델이 작업을 결정하면, 무언가가 그 작업을 실행해야 합니다. 파일을 쓰고, 패키지를 설치하고, 코드를 실행하거나 브라우저 세션을 열는 모든 워크플로우의 경우, 이 런타임에 격리가 필요합니다.

바로 여기에 섄드박스가 등장합니다. Novita Agent Sandbox는 이 실행 계층을 위해 설계되었습니다: 에이전트 작업이 호스트 시스템에 직접 영향을 미치지 않고 실행될 수 있는 별도의 환경입니다. 이는 "모델이 명령어를 제안했다"와 "워크플로우가 해당 명령어를 안전하게 실행했다"의 차이입니다.

4. 상태와 메모리

에이전틱 워크플로우는 단계 간에 작업 메모리가 필요합니다. 여기에는 일반적으로 다음이 포함됩니다:

대화 상태
도구 출력
중간 파일
실행 로그
스크래치패드 또는 짧은 계획

상태가 없으면 각 단계는 상태 비저장 프롬프트 엔지니어링이 되며, 작업이 하나 이상의 작업에 걸쳐 있으면 시스템이 곧바로 무너집니다.

5. 평가 루프

이것은 많은 팀이 너무 늦게 추가하는 부분입니다. 워크플로우는 단계가 성공했는지와 작업이 완료되었는지 판단할 방법이 필요합니다. 코딩 워크플로우에서는 테스트 통과를 의미할 수 있습니다. 연구 워크플로우에서는 답변이 충분히 신뢰할 수 있는 출처를 인용하는 것을 의미할 수 있습니다. 브라우저 워크플로우에서는 예상된 UI 상태가 보이는 것을 의미할 수 있습니다.

평가 없이는 "에이전틱"이 종종 "타임아웃될 때까지 도구 호출을 계속하는 것"으로 변질됩니다.

에이전틱 워크플로우 구축에서 계획이 중요한 이유

에이전틱 워크플로우 구축에서 가장 큰 실수는 모델이 매 턴 모든 것을 처음부터 즉흥적으로 처리해야 한다고 가정하는 것입니다.

이는 일반적으로 세 가지 문제를 만듭니다:

모델이 동일한 파일이나 URL을 반복해서 방문합니다.
도구 사용이 노이즈가 많고 비용이 많이 듭니다.
워크플로우가 명확한 중지 조건을 잃습니다.

더 나은 패턴은 가버운 계획과 기반을 둔 실행입니다. 모델이 다음 작업을 결정하도록 하되, 명시적인 작업, 보이는 현재 상태, 그리고 소수의 허용된 도구 세트를 기준으로 결정하도록 합니다. 이는 유용한 곳에서는 유연성을 유지하고 그렇지 않은 곳에서는 제거합니다.

코딩 워크플로우에서 계획은 종종 다음과 같습니다:

관련 파일을 식별합니다.
현재 구현을 읽습니다.
최소한의 변경 사항을 결정합니다.
편집을 수행합니다.
검증을 실행합니다.
중지하거나 수리합니다.

리포지토리가 예상치 못한 상황을 만들 때 모델이 분기할 수 있기 때문에 여전히 에이전틱합니다. 하지만 방황하지는 않습니다.

에이전틱 워크플로우에서 도구 사용은 어떻게 작동해야 하는가?

도구 사용은 명시적이고, 타입이 지정되며, 관찰 가능해야 합니다.

모델이 함수 호출을 지원한다면 사용하세요. Novita의 LLM API는 OpenAI 호환 엔드포인트를 노출하고 함수 호출을 직접 문서화하므로, 모델이 취약한 문자열 파싱에 의존하지 않고 도구 중에서 선택할 수 있는 가장 깔끔한 방법입니다.

몇 가지 규칙이 도구 사용을 훨씬 더 안정적으로 만듭니다:

도구 이름을 구체적으로 유지하세요.
필수 필드가 있는 스키마를 사용하세요.
오류를 포함한 완전한 결과를 반환하세요.
모든 호출, 인자 및 출력을 로깅하세요.
파괴적인 작업은 드물게 만들고 쉽게 제어할 수 있도록 하세요.

도구 계층은 또한 실제 경계를 반영해야 합니다. 예를 들어, 코딩 에이전트에 edit_repo_and_run_tests라는 하나의 메가 도구를 제공하지 마세요. 읽기, 쓰기 및 실행 단계를 분할하여 무언가 실패할 때 모델이 복구할 수 있도록 하세요.

코드 실행에 샌드박스가 필요한 이유는 무엇인가?

아무것도 실행하지 않는 에이전틱 워크플로우는 종종 일반 앱 서버 내에 머무를 수 있습니다. 셸 명령을 실행하고, 종속성을 설치하고, 다운로드한 파일을 처리하거나, 공개 웹을 탐색하기 시작하는 순간 격리가 필요합니다.

샌드박싱은 두 가지 다른 문제를 해결합니다:

안전성: 생성된 코드와 도구 출력은 잘못되었거나, 적대적이거나, 단순히 예측 불가능할 수 있습니다.
상태 유지: 다단계 작업은 파일, 패키지 및 실행 기록이 턴 간에 유지되는 지속적인 작업 공간이 필요합니다.

많은 팀에게 두 번째 요점은 첫 번째 요점만큼 중요합니다. 코드를 편집하고, 테스트를 실행하고, 실패를 수리하고, 검증을 다시 실행하는 워크플로우는 매 단계가 깨끗한 기계에서 시작한다면 불가능합니다.

그렇기 때문에 실용적인 아키텍처는 일반적으로 다음과 같습니다:

LLM API: 계획 및 도구 선택용
샌드박스 런타임: 실행 및 지속성용

Novita는 이 분할에 자연스럽게 맞습니다: LLM API는 플래너 및 도구 호출 계층 역할을 하고, Agent Sandbox는 실제 실행 환경을 처리합니다.

에이전틱 워크플로우를 어떻게 평가하는가?

평가는 두 가지 수준에서 이루어져야 합니다.

단계 수준 평가

마지막 작업이 효과가 있었나요?

예:

명령어가 성공적으로 종료되었나요?
API가 유효한 JSON을 반환했나요?
예상된 파일이 생성되었나요?
브라우저 페이지에 대상 요소가 포함되었나요?

작업 수준 평가

워크플로우가 사용자의 문제를 해결했나요?

예:

코드 변경 후 테스트가 통과했나요?
요약이 증거와 함께 연구 질문에 답변했나요?
자동화가 수동 정리 없이 트랜잭션을 완료했나요?

강력한 워크플로우는 둘 다 사용합니다. 최종 출력만 평가하면 실행 중에 명백한 실패 신호를 놓칩니다. 단계만 평가하면 워크플로우가 로컬적으로 유효한 일련의 작업을 길게 완료하고도 실제 작업을 실패할 수 있습니다.

에이전틱 워크플로우 구축을 위한 실용적인 아키텍처

대부분의 팀이 시작해야 하는 아키텍처는 다음과 같습니다:

사용자 요청이 앱에 들어옵니다.
컨트롤러가 목표, 상태 및 사ㅂ용 가능한 도ㅜ구를 LㅣMㅔ 전송합니다.
LLMㅣ 직접 응답 또는 도ㅜ구 호ㅜ출을 반환합니다.
컨트롤러가 샌드박스 또ㅜ른 통제된 런타임 내에서 도구를 실행합니다.
도구 결과가 대화 상태에 추가됩니다.
평가자가 완료, 실패 또는 승인 게이트를 확인합니다.
워크플로우가 완료되거나 차단될 때까지 루프가 계속됩니다.

이 컨트롤러 루프는 간단할 수 있습니다. 많은 경우 단일 오케스트레이터 프로세스로 충분합니다. 첫날부터 다중 에이전트 시스템이 필요하지 않습니다. 하나의 플래너, 몇 개의 잘 정의된 도구, 하나의 샌드박스 런타임 및 명확한 평가자로 시작하세요.

예시: Python의 에이전틱 워크플로우 컨트롤러

아래 예시는 제어 루프 형태를 보여줍니다. 도구 호출을 위해 Novita의 OpenAI 호환 API를 사용합니다. 실행 함수는 사용자 자신의 런타임 또는 샌드박스에 대해 구현해야 합니다.

import json
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.novita.ai/openai",
    api_key=os.environ["NOVITA_API_KEY"],
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "워크스페이스에서 파일 읽기",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "샌드박스에서 셸 명령 실행",
            "parameters": {
                "type": "object",
                "properties": {"cmd": {"type": "string"}},
                "required": ["cmd"],
            },
        },
    },
]


def read_file(path: str) -> str:
    # 자체 워크스페이스 또른 샌드박스 파일 시스템에 대해 구햔하세오.
    raise NotImplementedError


def run_command(cmd: str) -> str:
    # 자신의 샌드박스 런타임에 대해 구현하세요.
    raise NotImplementedError


dispatch = {
    "read_file": read_file,
    "run_command": run_command,
}


def run_workflow(task: str, model: str) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "당신은 워크플로우 컨트롤러입니다. 필요할 때 도구를 사용하고, "
                "각 작업 후 결과를 확인하며, 작업이 완료되면 중지하세요."
            ),
        },
        {"role": "user", "content": task},
    ]

    while True:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for call in message.tool_calls:
            fn = dispatch[call.function.name]
            args = json.loads(call.function.arguments)
            result = fn(**args)
            messages.append(
                {
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": result,
                }
            )

이는 의도적으로 최소화되었습니다. 프로덕션에서는 다음도 추가해야 합니다:

일시적 오류에 대한 재시도 정책
타임아웃 및 예산 제한
민감한 작업에 대한 인간 승인
구조화된 단계 로그
최종 완료 전 작업 수준 평가자

플래너로 어떤 모델을 사용해야 하는가?

에이전틱 워크플로우의 경우 플래너 모델은 단순한 원시 지능만 필요한 것이 아닙니다. 올바른 형태가 필요합니다:

신뢰할 수 있는 도구 호출
안정적인 긴 컨텍스트 동작
강력한 지시 따르기
다중 턴 깊이에서 예측 가능한 지연 시간

Novita에서 오픈 웨이트 시작점을 원한다면, Qwen3 Coder 30B A3B Instruct는 워크플로우 계획 및 코딩 중심의 도구 사용에 실용적인 옵션입니다. Novita의 현재 모델 페이지는 OpenAI 호환 액세스, 함수 호출 지원, 구조화된 출력 지원 및 160K 호스티드 컨텍스트 윈도우를 나열합니다. 많은 내부 자동화 및 코딩 작업의 경우, 더 크거나 더 전문화된 플래너로 이동하기 전에 진지한 첫 번째 버전을 구축하기에 충분합니다.

올바른 모델은 여전히 작업에 따라 다릅니다. 광범위한 추론 중심 워크플로우의 경우 먼저 계획 품질을 선택하세요. 볼륨이 많은 자동화의 경우 지연 시간과 비용이 벤치마크 강도만큼 중요할 수 있습니다.

에이전틱 워크플로우의 일반적인 실패 모드

대부분의 실패는 극적이지 않습니다. 반복적이고 비용이 많이 듭니다.

과도한 도구 사용

모든 기능이 자체 원격 종속성이 되면 워크플로우는 유용한 작업을 수행하는 것보다 조정에 더 많은 시간을 소비합니다.

취약한 중지 규칙

시스템이 "완료"가 언제인지 알지 못하면 계속해서 한 단계를 더 생성합니다.

부실한 오류 처리

도구가 실행 가능한 출력 대신 "실패"와 같은 모호한 메시지를 반환하면 모델이 복구할 수 없습니다.

샌드박스 경계 없음

워크플로우는 개발에서는 작동하지만, 실제 파일, 자격 증명 또는 외부 시스템에 닿는 순간 안전하지 않게 됩니다.

평가자 없음

에이전트는 바쁘게 보이지만 작업이 올바르게 완료되었다는 것을 증명하지 못합니다.

에이전틱 워크플로우를 사용하지 말아야 할 때는?

용어가 유행한다고 해서 구축하지 마세요.

다음과 같은 경우 에이전틱 워크플로우가 필요하지 않을 가능성이 높습니다:

작업이 일회성 생성인 경우
경로가 고정되어 있고 거의 변경되지 않는 경우
기존 프로그램이 모든 단계를 저렴하게 결정할 수 있는 경우
도구 사용이나 실행이 필요하지 않은 경우

예를 들어, 앱이 항상 양식 입력을 받아 하나의 프롬프트를 호출하고 형식화된 이메일을 반환한다면, 일반 LLM 워크플로우가 더 간단하고 좋습니다.

에이전틱 워크플로우는 환경이 시스템을 놀라게 할 수 있고 시스템이 여전히 계속 진행해야 할 때 효과를 발휘합니다.

긴 컨텍스트 모델 시작점을 원한다면, Novita AI의 Macaron V1 Tall Quick Start 및 Novita AI의 Qwen3.8-Max를 비교해 보세요.

FAQ

에이전틱 워크플로우는 함수 호출과 동일한가요?

아니요. 함수 호출은 워크플로우 내의 한 메커니즘입니다. 전체 워크플로우에는 제어 흐름, 상태, 실행 및 평가도 필요합니다.

에이전틱 워크플로우를 구축하려면 여러 에이전트가 필요한가요?

아니요. 대부분의 팀은 하나의 컨트롤러 루프와 몇 가지 도구로 시작해야 합니다. 다중 에이전트 설계는 나중에 유용하지만 기본 시작점은 아닙니다.

가장 중요한 안전 제어는 무엇인가요?

코드를 실행하거나 외부 시스템에 접촉하는 워크플로우의 경우, 가장 중요한 제어는 격리된 실행 환경과 좁은 도구 권한의 조합입니다.

가장 간단한 프로덕션 준비 스택은 무엇인가요?

좋은 첫 번째 스택은 다음과 같습니다: OpenAI 호환 LLM API, 소규모 도구 레지스트리, 샌드박스 런타임, 그리고 작업이 실제로 완료되었을 때 결정할 수 있는 평가자.

에이전틱 워크플로우란 무엇인가? 계획하고, 실행하고, 평가하는 워크플로우 구축 방법

에이전틱 워크플로우란 무엇인가?

에이전틱 워크플로우는 AI 에이전트와 어떻게 다른가?