저의 이전 글에서 저는 AI가 소프트웨어 개발에서 제약 조건 (constraints)의 역할을 변화시킨다고 주장했습니다.

수년 동안 많은 개발자들은 제약 조건을 최소화해야 할 대상으로 보았습니다. 정적 (static) 언어보다 동적 (dynamic) 언어가 인기를 얻었습니다. 스키마리스 (Schema-less) 데이터베이스는 더 큰 유연성을 약속했습니다. 설정 (configuration)은 관례 (convention)로 대체되었습니다. 명시적 (explicit) 정의보다는 암시적 (implicit) 동작이 선호되곤 했습니다.

그 동기는 이해할 만했습니다. 제약 조건은 마찰처럼 느껴졌기 때문입니다. 그것들은 우리의 속도를 늦췄습니다.

AI는 그 트레이드오프 (trade-off)를 변화시킵니다.

오늘날, 모든 명시적 제약 조건은 AI가 우리의 시스템을 더 잘 이해하는 데 사용할 수 있는 가치 있는 컨텍스트 (context)가 됩니다.

데이터베이스 스키마 (database schema)는 더 이상 단순한 검증 메커니즘이 아닙니다. 그것은 데이터의 구조와 의미를 설명합니다.

OpenAPI 명세 (specification)는 더 이상 서비스 간의 단순한 계약이 아닙니다. 그것은 AI에게 해당 서비스들이 어떻게 상호작용해야 하는지를 알려줍니다.

타입 정의 (type definition)는 더 이상 컴파일러만을 위한 것이 아닙니다. 그것은 AI가 API 뒤에 숨겨진 의도를 이해하도록 돕습니다.

제약 조건이 가치 있어진 것은 그것들이 실수를 방지하기 때문이 아닙니다.

그것들이 지식을 전달하기 때문에 가치 있어진 것입니다.

저는 동일한 원칙이 소프트웨어 개발 너머에도 적용된다고 믿습니다.

그것은 비즈니스 워크플로우 (business workflows)에도 적용됩니다.

AI 워크플로우 자동화의 문제점

AI 기반 워크플로우 자동화에 대한 엄청난 기대가 있습니다.

현재 대부분의 접근 방식은 자율 에이전트 (autonomous agents)를 기반으로 합니다. 에이전트는 요청을 받고, 상황에 대해 추론하며, 도구를 선택하고, 동작을 실행하며, 다음에 무엇이 일어나야 할지를 결정합니다.

단순한 워크플로우의 경우, 이는 놀라울 정도로 잘 작동할 수 있습니다.

하지만 비즈니스에 핵심적인 (business-critical) 워크플로우의 경우, 이러한 아키텍처 (architecture)는 불필요한 운영 리스크를 초래합니다.

AI는 단순히 작업을 수행하는 것뿐만 아니라,

작업을 실행하는 동안 비즈니스 프로세스를 발견하는 책임까지 지고 있습니다.

이는 확률론적 시스템 (probabilistic system)에게 이미 알고 있어야 할 무언가를 추론하도록 요구하는 것입니다.

비즈니스 워크플로 (Business workflows)에는 AI와 무관한 규칙들이 포함되어 있습니다:

• 어떤 동작은 승인이 필요합니다.
• 어떤 동작은 절대로 두 번 발생해서는 안 됩니다.
• 어떤 전이 (transitions)는 불가능합니다.
• 어떤 실패는 재시도 (retries)를 필요로 합니다.
• 다른 경우에는 보상 (compensation) 또는 롤백 (rollback)이 필요합니다.
• 어떤 동작은 사람의 개입 (human intervention)을 필요로 합니다.

이것들은 AI의 문제가 아닙니다.

이것들은 비즈니스 규칙 (business rules)입니다.

그리고 비즈니스 규칙은 프롬프트 (prompts) 안에 존재해서는 안 됩니다.

워크플로는 프롬프트 안에 존재해서는 안 됩니다

AI 워크플로가 더 복잡해질 때, 흔히 사용하는 해결책은 더 많은 에이전트 (agents)를 추가하는 것입니다.

• 플래너 에이전트 (planner agent)가 실행을 조정합니다.
• 전문화된 에이전트 (specialized agents)가 개별 작업을 수행합니다.
• 검증 에이전트 (validation agents)가 결과를 검토합니다.

프롬프트는 점점 더 정교해집니다. 하지만 워크플로 자체는 종종 암시적 (implicit)인 상태로 남아 있습니다. 워크플로는 오직 프롬프트, 예시, 그리고 창발적인 에이전트 행동 (emergent agent behavior)을 통해서만 존재합니다.

이로 인해 프로세스는 다음과 같은 문제를 겪습니다:

• 이해하기 어렵습니다.
• 테스트하기 어렵습니다.
• 감사 (audit)하기 어렵습니다.
• 검증 (verify)하는 것이 거의 불가능합니다.

비즈니스 프로세스는 더 나은 기반을 가질 자격이 있습니다.

워크플로를 명시적으로 만드세요

AI에게 워크플로를 추론하도록 요청하는 대신, 워크플로를 명시적으로 정의하세요.

이를 수행하는 가장 간단하고 강력한 방법 중 하나는 유한 상태 머신 (finite state machine)을 사용하는 것입니다.

유한 상태 머신은 다음을 명시적으로 모델링합니다:

• 프로세스의 가능한 상태 (states)
• 상태 간의 유효한 전이 (valid transitions)
• 각 전이에 필요한 조건 (conditions)
• 모든 전이와 관련된 동작 (actions)

예를 들어, 구매 승인 프로세스는 다음과 같을 수 있습니다:

Draft
  ↓
Submitted
...

프로세스가 Submitted 상태에 있을 때, 워크플로는 정확히 세 가지의 유효한 전이를 노출할 수 있습니다:

• Approve (승인)
• Reject (거절)
• Request More Information (추가 정보 요청)

이제 AI는 더 이상 워크플로를 스스로 만들어낼 필요가 없습니다. 워크플로 자체가 무엇이 가능한지를 정의합니다. AI는 단지 유효한 동작 중 어떤 것이 가장 적절한지를 결정하기만 하면 됩니다. 워크플로가 경계 (boundaries)를 제공하고, AI가 지능 (intelligence)을 제공하는 것입니다.

명시적 제약 조건이 명시적 컨텍스트가 된다

유한 상태 머신 (Finite State Machine, FSM)의 가치는 단순히 AI를 제약하는 데에만 있지 않습니다.

그것은 비즈니스 프로세스를 명시적으로 만듭니다.

AI는 즉시 다음 사항들을 알게 됩니다:

• 현재 상태 (current state)
• 유효한 다음 행동 (valid next actions)
• 필요한 정보 (required information)
• 비즈니스 규칙 (business rules)
• 가능한 결과 (possible outcomes)

프롬프트 (prompts), 예시 (examples), 또는 이전 실행 (previous executions)으로부터 워크플로를 추론하는 대신, AI는 프로세스에 대한 정밀한 설명을 전달받습니다.

OpenAPI 명세 (specification)가 AI가 API를 이해하도록 돕는 것처럼, 유한 상태 머신은 AI가 비즈니스 프로세스를 이해하도록 돕습니다.

두 경우 모두, 명시적 제약 조건 (explicit constraints)은 고품질의 컨텍스트 (context)가 됩니다.

유한 상태 머신은 문서 그 이상이다

이 지점이 유한 상태 머신이 특히 흥미로워지는 부분입니다.

프롬프트와 달리, FSM은 형식적 모델 (formal model)입니다.

이는 그것이 명시적일 뿐만 아니라,

검증 가능하다 (verifiable)는 것을 의미합니다.

AI 에이전트가 워크플로를 실행하기도 전에, 우리는 모델을 분석하여 다음과 같은 질문에 답할 수 있습니다:

• 워크플로가 유효하지 않은 상태 (invalid state)에 도달할 수 있는가?
• 막다른 상태 (dead-end states)가 존재하는가?
• 모든 승인 (approvals) 절차가 강제되는가?
• 특정 행동이 실수로 두 번 실행될 수 있는가?
• 롤백 경로 (rollback paths)가 정의되어 있는가?
• 모든 실패 시나리오 (failure scenarios)가 처리되었는가?
• 모든 프로세스가 결국 완료 (completion)에 도달할 수 있는가?

이것들은 AI와 독립적으로 검증할 수 있는 속성들입니다. 이는 프롬프트 기반 워크플로 (prompt-driven workflows)와의 근본적인 차이점입니다. 프롬프트는 프로세스를 기술합니다. 유한 상태 머신은 프로세스를 정의하고 제약합니다. FSM은 AI를 둘러싼 실행 가능한 안전 경계 (executable safety boundary)가 됩니다.

AI는 검증된 경계 안에서 작동한다

목표는 AI를 결정론적 (deterministic)으로 만드는 것이 아닙니다.

그것은 불가능합니다.

목표는 AI가 작동하는 환경을 결정론적으로 만드는 것입니다.

명시적인 워크플로가 없다면, AI는 끊임없이 질문합니다:

다음에 무엇이 일어나야 하지?

FSM이 있다면, 대화의 양상이 바뀝니다.

워크플로가 말합니다:

다음에 일어날 수 있는 유효한 행동은 이것들뿐이다.

AI는 대답합니다:

이러한 유효한 옵션들이 주어졌을 때, 어떤 것이 가장 적절한가?

이는 미묘하지만 심오한 아키텍처적 변화입니다.

AI는 더 이상 워크플로 (workflow)를 소유하지 않습니다.

AI는 워크플로를 탐색합니다.

MCP는 이를 자연스럽게 만듭니다

이 모델은 MCP를 통해 노출될 때 더욱 강력해집니다.

수십 개의 저수준 도구 (low-level tools)를 노출하는 대신, 워크플로는 현재 상태와 현재 사용 가능한 전이 (transitions)를 노출합니다.

AI 에이전트는 다음을 발견할 수 있습니다:

• 현재 상태
• 사용 가능한 전이
• 각 전이를 수행하는 데 필요한 정보
• 검증 규칙 (validation rules)
• 롤백 (rollback) 기능
• 에스컬레이션 경로 (escalation paths)

워크플로는 자기 기술적 (self-describing)이 됩니다. 비즈니스 프로세스를 변경한다는 것은 프롬프트 (prompts)를 다시 쓰는 것이 아니라 워크플로 모델을 업데이트하는 것을 의미합니다. AI는 컨텍스트 (context)의 일부로서 새로운 제약 사항을 자동으로 전달받습니다.

명시적 제약 사항은 운영 리스크를 획기적으로 줄입니다

대규모 언어 모델 (Large language models)은 확률적입니다. 비즈니스 프로세스는 그렇지 않아야 합니다. 유한 상태 머신 (finite state machine)은 AI를 더 똑똑하게 만드는 것이 아니라, 전체 시스템을 더 안전하게 만듭니다.

AI를 명시적으로 정의된 전이로 제한함으로써, 우리는 AI 기반 워크플로 자동화의 운영 리스크를 획기적으로 줄일 수 있습니다.

• 유효하지 않은 전이는 불가능해집니다.
• 모든 상태 변화는 검증 가능합니다.
• 모든 결정은 감사 가능 (auditable)합니다.
• 롤백은 사후 고려 사항이 아닌 워크플로의 일부가 됩니다.
• 컴플라이언스 (compliance) 규칙이 암시적이지 않고 명시적이 됩니다.

가장 중요한 점은, AI가 더 이상 무엇이 가능한지를 결정하지 않는다는 것입니다. AI는 이미 경계가 정의된 프로세스를 어떻게 탐색할지를 결정합니다.

명시성은 비즈니스 가치를 창출합니다

이는 제가 이전 글에서 논의했던 것과 동일한 원칙입니다.

• 명시적 스키마 (schemas)는 AI가 데이터를 이해하도록 돕습니다.
• 명시적 계약 (contracts)은 AI가 API를 이해하도록 돕습니다.
• 명시적 타입 (types)은 AI가 코드를 이해하도록 돕습니다.
• 명시적 워크플로는 AI가 비즈니스 프로세스를 이해하도록 돕습니다.

가치는 더 많은 제약 사항을 추가하는 데서 오는 것이 아닙니다. 올바른 제약 사항을 명시적으로 만드는 데서 옵니다.

AI가 비즈니스 운영에 점점 더 많은 책임을 맡게 됨에 따라, 저는 비즈니스 프로세스를 추론하려고 시도하는 자율 에이전트 (autonomous agents)에 대한 의존도는 낮아지고, 인간과 AI 모두가 이해할 수 있는 방식으로 프로세스를 정의하는 명시적 워크플로 모델 (explicit workflow models)에 대한 의존도는 높아질 것이라고 믿습니다.

AI 워크플로 자동화의 미래는 무제한적인 자율성이 아닙니다. 그것은 통제된 자율성 (controlled autonomy)입니다. AI는 지능을 제공합니다. 명시적이고 검증 가능한 워크플로 모델은 정확성 (correctness)을 제공합니다. AI의 역할은 워크플로를 소유하는 것이 아닙니다. AI의 역할은 워크플로를 지능적으로 탐색하는 것입니다.

그리고 바로 그 지점에서 제약 사항은 마찰이 아닌 비즈니스 가치가 되기 시작합니다.