사내에서 "에이전트 붙이자"는 말이 나오면 저는 요즘 반사적으로 한 가지를 묻는다. "그거 플로우차트 그릴 수 있어요?" 그릴 수 있으면 에이전트가 아니라 파이프라인이다. 이 질문 하나로 회의 시간이 40분 줄어든 경험이 여러 번 있다.
Dev.to에 올라온 James Anderson의 글 "Most 'AI Agents' Are Just If-Statements in a Trench Coat"이 정확히 그 얘기를 한다. 저자는 플래너, 툴, 리즈닝 루프까지 갖춘 에이전트를 만들어 데모에서 박수를 받았다. 그리고 프로덕션에 올렸더니 느리고, 비싸고, 재현 안 되는 방식으로 깨졌다. 화요일과 수요일에 같은 입력이 다르게 동작했고, 장애 원인은 자기가 통제하지도 관측하지도 못한 상류의 "자율적 결정" 세 개였다.
결국 그는 지루한 선형 파이프라인으로 다시 썼다. 고정 스텝, 리즈닝 루프 없음. 그리고 중요한 모든 축에서 더 나아졌다 — 더 빠르고, 더 싸고, 테스트 가능하고, 디버깅 가능해졌다. 그러고 나서 옛 "에이전트"의 로그를 보니 매 실행마다 똑같은 세 스텝을 밟고 있었다. Extract, transform, respond. 자율성을 단 한 번도 쓰지 않았다. 그가 만든 건 시스템 프롬프트를 얹은 for 루프였다.
인프라 담당자 입장에서 이 글이 중요한 이유는 감성적 공감 때문이 아니다. 자율성이 비용이라는 점, 그리고 그 비용이 청구서에 항목별로 찍힌다는 점을 명확하게 짚기 때문이다.
경계선은 딱 하나다: 제어 흐름을 누가 정하는가
원문의 정의는 단순하고, 저는 이보다 나은 정의를 아직 못 봤다.
- 에이전트: 런타임에 모델이 자기 제어 흐름을 결정한다. 어떤 툴을 부를지, 다음 스텝이 무엇인지, 다시 루프를 돌지, 언제 멈출지를 모델이 본 것에 따라 동적으로 고른다.
- 파이프라인: 제어 흐름을 설계 시점에 내가 고정한다. 스텝 1, 2, 3. 매번 같은 경로. LLM은 각 스텝 안에서 일하지만 스텝을 고르지는 못한다.
여기서 사람들이 자주 건너뛰는 부분: 고정된 스텝 안에서 LLM이 똑똑한 일을 하는 건 자율성이 아니다. 필드 추출, 티켓 분류, 요약 생성 — 그냥 LLM을 쓰는 것이다. 똑똑한 함수 호출이다. 자율성은 모델에게 핸들을 넘겼을 때만 발생한다.
대부분의 "에이전트"는 핸들을 넘기지 않는다. 고정된 경로를 유창한 자연어로 서술하고, 그 서술을 "추론"이라고 부른다.
리트머스 시험지는 이거다. 실행 전에 플로우차트를 그릴 수 있으면 파이프라인이다. 컨텍스트 검색 → 툴 호출 → 응답 포맷팅. 코드 한 줄 쓰기 전에 화이트보드에 그릴 수 있었나? 그럼 모델은 경로를 결정하는 게 아니다. 내가 이미 결정했고, 모델은 각 노드에서 일하면서 결정하는 것처럼 들리게 말하고 있을 뿐이다.
실무에서 이 구분을 코드로 보면 더 선명하다. 아래는 "에이전트"라고 불리던 코드를 파이프라인으로 벗겨낸 형태다.
# before: "에이전트" (실제로는 매번 같은 3스텝)
while not done:
plan = llm.chat(f"다음에 뭘 해야 해? 상태: {state}") # 매 턴 토큰 소비
tool = parse_tool(plan) # 파싱 실패 위험
state = TOOLS[tool](state)
done = "FINISH" in plan
# after: 파이프라인 (LLM은 가치 있는 지점에만)
def run(doc: str) -> dict:
fields = llm_extract(doc) # LLM: 구조화 추출
norm = normalize(fields) # 순수 함수, 테스트 가능
answer = llm_answer(norm) # LLM: 문장 생성
return {"fields": norm, "answer": answer}
after 쪽에서 LLM이 하는 똑똑한 일은 하나도 줄지 않았다. 여전히 추출하고 생성한다. 다만 작업의 구조를 즉흥적으로 만들게 하는 걸 멈췄다. 구조는 애초에 지능이 필요한 부분이 아니었다. 내가 이미 알고 있던 부분이다.
코스튬 값이 청구서에 찍히는 방식
"그래도 동작하는데 뭐가 문제냐"는 반박이 나온다. 문제 되는 사람은 그걸 운영하고, 돈 내고, 새벽 2시에 디버깅하는 사람들이다. 원문이 정리한 항목을 인프라 관점으로 다시 풀어보면 이렇다.
1. 비결정성 → 버그가 재현되지 않는다. 모델이 경로를 고르면 같은 입력이 실행마다 다른 경로를 탄다. "제가 해봤을 땐 됐는데요"가 영구 상태가 된다. 장애 대응 프로세스가 성립하지 않는다.
2. 디버깅 붕괴. 고정 파이프라인이 깨지면 어느 스텝이 실패했는지 안다. 에이전트는 스텝 4에서 내린 결정 때문에 스텝 12에서 깨진다. 코드를 디버깅하는 게 아니라 선택에 대한 포렌식을 하게 된다.
3. 실패 표면의 곱셈. 고정 5스텝 파이프라인은 확인할 게 5개다. 결정 5개를 하는 에이전트는 각 결정이 틀릴 수 있고, 조합으로 틀릴 수 있고, 그 순서가 매 실행 바뀐다.
4. 비용과 지연. 리즈닝 루프는 고정 시퀀스보다 훨씬 많은 모델 호출을 만든다. 생각하고, 다시 생각하고, 반성하고, 또 돌기로 한다. 이미 답을 알고 있던 경로를 모델이 숙고하는 데 토큰당 돈을 낸다.
5. 테스트 불가. 회귀 테스트는 고정된 경로 집합이 있어야 한다. 에이전트는 정의상 그게 없다. 프로덕션에서 자율적 결정을 하는 그 컴포넌트가 동시에 신뢰할 만한 테스트를 쓸 수 없는 컴포넌트다.
인프라 쪽에서 실제로 아픈 지점을 하나 더 붙이자면 멱등성이다. 파이프라인은 스텝별 재시도 정책을 내가 정한다. 스텝 2가 타임아웃 나면 스텝 2만 재시도한다. 에이전트는 루프 안에서 어떤 툴이 몇 번 호출됐는지가 실행마다 다르다. 그 툴이 결제 API나 티켓 생성 API라면? 중복 실행 방어를 에이전트 바깥에 깔아야 한다. 툴 호출 단위 idempotency key를 강제하는 래퍼를 씌우는 게 최소 방어선이다.
# 툴 래퍼: 멱등성 + 호출 상한 + 예산 상한
import hashlib, time
CALL_BUDGET = {"n": 0, "max": 12}
SEEN = {} # 실제로는 Redis SETNX 권장
def guarded(fn):
def wrap(**kw):
CALL_BUDGET["n"] += 1
if CALL_BUDGET["n"] > CALL_BUDGET["max"]:
raise RuntimeError("tool call budget exceeded")
key = hashlib.sha1(f"{fn.__name__}:{sorted(kw.items())}".encode()).hexdigest()
if key in SEEN: # 같은 인자 재호출은 캐시 반환
return SEEN[key]
SEEN[key] = fn(**kw)
return SEEN[key]
return wrap
호출 상한(max)이 없으면 무슨 일이 벌어지는지는 한 번 겪어보면 안다. 루프가 자기 출력을 잘못 파싱해서 같은 툴을 계속 부르고, 토큰 청구서가 조용히 불어난다. 상한은 기능이 아니라 서킷 브레이커다.
실무 도입: 관측성부터 깔고, 자율성은 마지막에 준다
비결정적 시스템을 운영하려면 순서가 있다. 저는 이 순서를 지키지 않아서 두 번 고생했다.
먼저 트레이싱. LLM 호출을 하나의 span으로 잡고, 실행 전체를 trace로 묶는다. 스텝 이름, 모델명, 입력/출력 토큰 수, 재시도 횟수, 그리고 결정 근거를 속성으로 남긴다. 에이전트에서 가장 아쉬운 로그는 "왜 이 툴을 골랐는지"가 없는 로그다. 최소한 모델이 반환한 tool_call 원문은 그대로 저장해야 나중에 리플레이가 된다.
# 스텝 단위 span (OpenTelemetry Python)
from opentelemetry import trace
tracer = trace.get_tracer("llm-pipeline")
with tracer.start_as_current_span("llm.extract") as sp:
out = llm_extract(doc)
sp.set_attribute("llm.model", "gpt-4o-mini")
sp.set_attribute("llm.tokens.in", out.usage.prompt_tokens)
sp.set_attribute("llm.tokens.out", out.usage.completion_tokens)
sp.set_attribute("app.step", "extract")
실행 결과 로그는 대충 이런 모양으로 남는다. 스텝별로 지연과 토큰이 분리돼야 어디가 비싼지 보인다.
$ python run_pipeline.py --doc sample.txt
[trace 4f1a...c9] llm.extract ok 842ms in=1_204 out=186
[trace 4f1a...c9] normalize ok 3ms
[trace 4f1a...c9] llm.answer ok 1_310ms in=402 out=311
[trace 4f1a...c9] TOTAL ok 2_155ms tokens=2_103
그다음 평가(eval). 파이프라인은 경로가 고정이라 스텝별 골든 데이터셋을 만들 수 있다. 추출 스텝은 필드 정확도, 생성 스텝은 규칙 기반 체크 + 사람 샘플링. 이게 회귀 테스트 역할을 한다. 에이전트로 가면 경로가 달라지니 "최종 결과만" 평가하게 되고, 어디서 틀렸는지는 다시 포렌식이다.
흔한 함정
Traceback (most recent call last):
File "agent/loop.py", line 88, in parse_tool
return json.loads(raw)
File "/usr/lib/python3.11/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
# 또는 스키마 강제 시
openai.BadRequestError: Error code: 400 - {'error': {'message':
"Invalid schema for response_format 'ToolCall': ... 'additionalProperties'
is required to be supplied and to be false", 'type': 'invalid_request_error'}}
대응은 두 갈래다. (a) 자유 텍스트 파싱을 버리고 function calling / structured output 스키마를 쓴다 — 다만 스키마 제약(필수 필드, additionalProperties 등)이 프로바이더마다 다르니 공식 문서 확인이 필요하다. (b) 파싱 실패 시 재시도 횟수를 못 박고, 초과하면 폴백 경로로 빠진다. 무한 재시도는 위에서 말한 청구서 사고로 직행한다.
② 타임아웃이 중첩된다. 에이전트 루프는 "전체 예산"이 있어야 한다. 툴 호출 하나에 30초 타임아웃을 걸어도 루프가 10번 돌면 5분이다. API 게이트웨이 타임아웃(보통 훨씬 짧다)에 먼저 잡혀서 클라이언트는 504를 받고, 백엔드 루프는 계속 돌면서 토큰을 태운다. 요청 단위 deadline을 만들어 컨텍스트로 내려보내고, 남은 시간이 없으면 루프를 즉시 종료해야 한다.
③ "if문 3개짜리 분기"를 에이전트라고 부르기. 원문 표현대로, 케이스 세 개짜리 if문은 그냥 switch 붙은 파이프라인이다. 진짜 자율성이 필요한 건 미리 열거할 수 없을 만큼 분기 공간이 큰 경우다. 분기를 셀 수 있으면 명시적으로 쓰자. 코드로 쓴 switch는 테스트가 되고, 프롬프트에 숨긴 switch는 안 된다.
④ 컨텍스트가 조용히 커진다. 루프가 돌 때마다 이전 관찰 결과를 프롬프트에 다 넣으면 토큰이 스텝 수에 비례해 늘어난다. 요약 압축이나 슬라이딩 윈도우를 안 넣으면 어느 순간 컨텍스트 초과 에러로 실패하고, 그 실패는 입력 데이터 길이에 따라 들쭉날쭉해서 재현이 어렵다.
그럼 언제 진짜 에이전트인가
원문도 "에이전트는 항상 나쁘다"고 하지 않는다. 자율성이 값을 하는 경우를 셋으로 정리한다.
- 스텝을 미리 알 수 없을 때. 열린 조사, 탐색, 원인 모르는 문제 디버깅. 플로우차트 자체가 발견 대상이라 그릴 수가 없다.
- 진짜 멀티홉. "찾고, 찾은 것의 정체에 따라 다음을 판단한다." 스텝 1을 돌리기 전엔 스텝 2를 정말로 알 수 없는 경우.
- 분기가 사실상 무한할 때. 미리 열거하기엔 가능성 공간이 너무 큰 경우.
그리고 이 경우에도 원칙은 자율성 최소화다. 하드코딩할 수 있는 건 다 하드코딩하고, 런타임 결정은 정말 필요한 한 지점에만 남긴다. 원문의 관찰이 인상적인데, 프로덕션에서 실제로 잘 돌아가는 "에이전틱" 시스템을 들여다보면 대개 거의 고정된 파이프라인에 조심스럽게 제약된 결정 지점이 한두 개 있는 형태다. 자유롭게 돌아다니는 리즈닝 루프가 아니다.
왜 그럼 다들 에이전트를 만드냐. 원문의 답이 불편하지만 정확하다. 에이전트는 작업이 아니라 만드는 사람을 위해 만들어진다. 데모가 잘 되고, 진짜 AI처럼 느껴지고, "agentic"은 이력서와 IR 자료에 쓰기 좋은 단어다. "결정론적 파이프라인"으로는 그 신호가 안 나온다. 그 이유 중 어느 것도 내 작업이 에이전트를 필요로 하는지와는 관계가 없다.
정리
한 줄 요약: 플로우차트를 미리 그릴 수 있으면 파이프라인으로 만들어라. 자율성은 정당화해야 하는 비용이다.
누가 언제 써야 하는지 정리하면:
- 지금 파이프라인으로 가라 — 문서 처리, 분류, 요약, 티켓 라우팅, 정형 추출. 즉 업무 형태를 이미 이해하고 있는 대부분의 백오피스 작업. LLM은 각 스텝 안에서만 쓴다.
- 제약된 결정 지점 하나만 추가 — 분기 조건을 규칙으로 못 쓰겠고, 케이스가 열 개 안팎으로 셀 수 있을 때. 단, 분기는 코드에 명시하고 모델은 라벨만 고르게 한다.
- 진짜 에이전트 — 조사·탐색·원인 규명처럼 경로가 실행 중 발견되는 작업. 이때는 툴 호출 상한, 요청 deadline, 멱등성 키, trace 기반 리플레이를 먼저 깔고 시작한다. 이 네 개 없이 에이전트를 프로덕션에 올리면 새벽 2시에 후회한다.
원문의 마지막 문장을 저도 빌리고 싶다. 데모에서 이기는 시스템보다, 수요일에도 여전히 돌아가는 시스템이 목표였다. 코트를 벗겨보면 안에 있는 게 더 마음에 들 것이다.
참고 자료
'Tech_News' 카테고리의 다른 글
| async/await은 하나의 문법이 아니다 — 런타임 7개가 서로 다른 답을 내는 이유 (1) | 2026.09.14 |
|---|---|
| AI 게이트웨이에서 RBAC와 데이터 접근 제어: 애플리케이션 인가만으로는 안 되는 이유 (0) | 2026.09.11 |
| BZip3 실무 적용기: bzip2의 후속작은 정말 쓸 만한가 (0) | 2026.09.09 |
| DNS 라이브러리를 걷어내면 드러나는 것들 — 남이 대신 내려준 40개의 결정 (0) | 2026.09.08 |
| AI SRE가 장애를 다 처리하면, 남는 건 아무도 못 고치는 장애뿐이다 (0) | 2026.09.07 |