AI 워크플로우의 변화: 다음 스프린트에 더 나은 실행 계약 (Execution Contracts)이 필요한 이유

도입부: 병목 현상이 이동했고, 대부분의 팀은 이를 놓쳤습니다

현재 AI를 활용해 가장 빠르게 제품을 출시하는 방법은 모델을 쇼핑하는 것이 아니라, 워크플로우 엔지니어링 (Workflow Engineering)입니다.

모두가 최신 모델 출시를 벤치마킹하고 어떤 어시스턴트가 더 "똑똑하게 느껴지는지" 논쟁하는 이번 주 상황에서는 역설적으로 들릴 수 있습니다. 하지만 최근 LLM (Large Language Models)을 사용하여 사소하지 않은 결과물을 만들어 본 적이 있다면, 고통의 원인이 보통 "모델이 코드를 잘못 작성했다"는 것이 아님을 이미 알고 있을 것입니다. 진짜 고통은 다음과 같습니다:

작업 중간에 중단되어 버리는 에이전트 루프 (Agent loops)
아무도 논리적으로 이해할 수 없는 승인 프롬프트 (Approval prompts)
재시도 (Retries)를 견디지 못하는 취약한 컨텍스트 체인 (Context chains)
자동화가 상태 (State)를 잊어버려 사람이 직접 정리 작업을 수행하는 상황

즉, 제약 사항이 지능 (Intelligence)에서 실행 (Execution)으로 이동했다는 뜻입니다.

그리고 이번 주의 트렌드 신호들은 이를 무시할 수 없게 만들었습니다.

이번 주에 무엇이 변했는가 (그리고 왜 중요한가)

몇 가지 논의가 강력하게 수렴되었습니다:

새로운 프런티어 모델 업데이트(예: Claude Opus 4.8 관련 논의)에 대한 큰 기대감.
"내구성이 있는 워크플로우 (Durable workflows)를 위해 그냥 Postgres를 사용하라"는 사고방식의 강력한 추진력.
AI 에이전트의 권한 피로 (Permission fatigue)에 대해 너무나 현실적인 공감을 불러일으킨 바이럴 게임.
개발자들이 슬라이드 자료에서 말하는 방식이 아니라, 실제로 업무에서 AI를 어떻게 사용하는지에 대한 DEV 플랫폼의 지속적인 대화.
임베딩 (Embeddings) 기반의 관련성(Relevance)에 대한 DEV 플랫폼의 작업. 이는 검색 (Retrieval)과 랭킹 (Ranking)이 이제 부차적인 작업이 아니라 제품의 핵심 요소임을 모두에게 상기시켜 줍니다.

게시물은 제각각이지만 메시지는 동일합니다: 능력은 상승하고 있지만, 신뢰와 운영 제어 (Operational control)는 뒤처지고 있습니다.

우리는 "오케스트레이션 세금 (Orchestration tax)" 시대에 진입하고 있습니다. 의도적으로 이 세금을 지불하지 않는다면, 서비스 중단, 침묵하는 실패 (Silent failures), 그리고 밤 11시 40분에 엔지니어가 봇을 돌보며 지켜봐야 하는 상황으로 그 대가를 치르게 될 것입니다.

이것이 실제 팀들에게 뼈아프게 다가오는 이유

실제 코드베이스에서 AI 출력물은 최종 결과물인 경우가 드뭅니다. 그것은 티켓 분류 (Ticket triage), PR 초안 작성, 테스트 생성, 마이그레이션 계획, 장애 대응 (Incident response), 문서 업데이트, 고객 대면 변경 사항 등 더 큰 시스템 내부의 중간 단계입니다.

즉, 핵심 문제는 "모델이 텍스트/코드를 생성할 수 있는가?"가 아닙니다. 그것은 다음과 같습니다:

타임아웃(timeout) 발생 후 작업을 재개할 수 있는가?
누가 무엇을 승인했는지 감사(audit)할 수 있는가?
중복된 부작용(side effects) 없이 안전하게 재실행할 수 있는가?
사람이 처음부터 다시 시작하지 않고 중간 단계에서 업무를 인계받을 수 있는가?

대부분의 팀은 이러한 문제들을 "나중에" 해결할 과제로 취급합니다. 그러다 결국 한 번의 출시 주간이 실패하고 나면, 그 "나중"은 바로 "지금"이 됩니다.

불편한 진실은 이것입니다: 시니어 엔지니어들은 이미 이러한 종류의 문제를 해결하는 방법을 알고 있습니다. 우리는 수년 전에 결제(payments), 큐(queues), 백그라운드 작업(background jobs)을 위해 이 문제를 해결했습니다. 멱등성 키(Idempotency keys), 체크포인트(checkpoints), 재시도(retries), 보상 작업(compensating actions), 트랜잭션 로그(transaction logs). 똑같은 영화인데 배우만 바뀌었을 뿐입니다.

AI가 분산 시스템(distributed systems)의 고통을 만들어낸 것이 아닙니다. AI는 단지 주니어 수준의 실패 모드(failure modes)가 시니어의 속도로 발생하게 만들었을 뿐입니다.

모두가 계속해서 던지는 잘못된 질문

잘못된 질문은 다음과 같습니다:

"어떤 모델을 표준으로 삼아야 할까?"

물론 유용한 질문입니다. 하지만 이는 1차적인(first-order) 문제가 아닙니다.

취약한 워크플로우(workflow) 위에서 훌륭한 모델을 실행하더라도 여전히 혼란은 발생할 수 있습니다. 반면, 견고한 워크플로우 위에서 그저 괜찮은 수준의 모델을 실행한다면 매 스프린트마다 복리 효과를 누릴 수 있습니다.

모델의 품질은 중요합니다. 하지만 이제 모델은 더 큰 신뢰성 방정식(reliability equation)의 변수 중 하나일 뿐입니다.

만약 여러분의 프로세스가 끊김 없는 컨텍스트 윈도우(context windows), 정책 없는 수동 승인, 그리고 "희망에 기반한 재시도(hope-based retries)"에 의존하고 있다면, 모델 리더보드(leaderboard)는 여러분을 구원해주지 못할 것입니다.

실행 계약(execution contract)을 선택하기 전에 모델을 선택하는 것은 브레이크가 없는 자동차에 레이싱 엔진을 다는 것과 같습니다.

더 나은 질문: 어떤 실행 계약을 강제할 것인가?

대신 이렇게 물으십시오:

"우리 스택에서 AI 작업이 안전하고, 재개 가능하며, 검토 가능하기 위해 반드시 충족되어야 하는 조건은 무엇인가?"

이 질문은 단순한 느낌(vibes)이 아닌 엔지니어링 결정으로 이어집니다. 이번 주에 바로 적용할 수 있는 실질적인 플레이북(playbook)을 소개합니다.

다음 주 스프린트를 위한 구체적인 플레이북

1. 프롬프트 품질보다 작업 경계(task boundaries)를 먼저 정의하라

AI 작업을 입력(input)과 출력(output)이 명확한 단계로 분리하십시오:

collect_context (컨텍스트 수집)
propose_change (변경 제안)
run_checks (체크 실행)
request_approval (승인 요청)
apply_change (변경 적용)
summarize_result (결과 요약)

하나의 거대한 프롬프트가 전체 라이프사이클(lifecycle)을 통제하게 두지 마십시오.

2. 지루한 인프라(infrastructure)에 상태(state)를 유지하십시오

많은 팀에게는 Postgres만으로도 충분합니다:

status, step, attempt_count를 포함한 워크플로우(workflow) 테이블
추가 전용(append-only) 전환 기록을 담은 이벤트 로그(event log) 테이블
주요 체크포인트(checkpoint)에서의 페이로드(payload) 스냅샷

워커(worker)가 충돌하더라도, 메모리(memory)가 아닌 상태(state)로부터 복구할 수 있습니다.

3. 기본적으로 재시도(retries)를 멱등(idempotent)하게 만드십시오

부수 효과(side-effecting)를 일으키는 모든 작업에는 안정적인 작업 키(operation key)가 필요합니다.

동일한 단계가 두 번 실행되더라도, 결과는 동일하거나 안전하게 중복 제거(deduplicated)되어야 합니다.

멱등성(idempotency)이 없다면, 프로덕션(production)도 없습니다.

4. 권한 스팸을 정책 계층(policy tiers)으로 교체하십시오

권한 피로(permission fatigue)는 실재합니다. 연속으로 17번이나 승인을 요청하지 마십시오.

계층을 만드십시오:

Tier 0: 읽기 전용 작업(read-only ops) 자동 승인
Tier 1: 저위험 쓰기 작업(low-risk write ops) 일괄 승인
Tier 2: 고영향 작업(high-impact ops) 명시적 인간 체크포인트

그런 다음 모든 결정을 로그(log)로 남기십시오. 인간은 프롬프트(prompts)를 싫어하지만, 명확한 정책(policy)은 좋아합니다.

5. 토큰 사용량뿐만 아니라 실패 모드(failure modes)를 계측(instrument)하십시오

다음 항목을 추적하십시오:

단계 타임아웃(step timeout) 비율
재시도 성공률(retry success rate)
인간 개입 지점(human intervention points)
롤백(rollback) 빈도
"완료되었으나 사용할 수 없는" 결과

지연 시간(latency)과 비용(cost)만 추적한다면, 운영 품질(operational quality)에 대해 눈이 먼 상태가 됩니다.

6. 워크플로우 신뢰성 확보 후 프롬프트를 최적화하십시오

프롬프트 튜닝(prompt tuning)도 중요하지만, 순서가 더 중요합니다:

신뢰할 수 있는 상태 전환(state transitions)
복구 가능성(recoverability)
승인 편의성(approval ergonomics)
그 다음 출력물 다듬기(output polish)

불안정한 시스템을 다듬는 것은 그저 더 예쁜 실패를 만드는 것뿐입니다.

7. 다른 프로덕션 시스템과 마찬가지로 소유권을 할당하십시오

한 팀에게 AI 워크플로우 신뢰성에 대한 명시적인 소유권(ownership)을 부여하십시오.

"모두가 책임진다"는 것은 사고 대응(incident response), 정책 드리프트(policy drift), 또는 재생 도구(replay tooling)를 책임질 사람이 아무도 없다는 뜻입니다.

반전된 견해 (The contrarian take)

결론은 이렇습니다. 2026년 가장 뜨거운 AI 팀들은 겉보기에 지루해 보일 수도 있습니다.

그들은 자율 에이전트(autonomous agents)가 모두를 대체할 것이라고 자랑하지 않을 것입니다. 대신, 예상치 못한 상황을 줄이면서 지속적으로 결과물을 내놓는 내구성이 있고, 관찰 가능하며(observable), 정책 중심적인(policy-driven) 파이프라인(pipelines)을 조용히 운영할 것입니다.

그들의 초능력은 신비로운 프롬프트(prompts)가 아닐 것입니다. 그것은 AI 네이티브(AI-native) 작업에 적용된 절제된 시스템 엔지니어링(systems engineering)이 될 것입니다.

이는 영화처럼 극적이지는 않습니다. 하지만 현실과 마주했을 때 살아남는 방식이기도 합니다.

기억해야 할 마지막 문장

모델은 매달 더 똑똑해지고 있습니다. 당신의 경쟁 우위(edge)는 현실이 닥쳐왔을 때 당황하지 않는 워크플로우(workflows)를 구축하는 데서 옵니다.