AI의 역사에서 사실상 고대사나 다름없는 1년 전보다 더 이전에, 저는 새로운 셀프 서비스(self-service) 기능을 구축하기 위해 AI를 사용하는 것에 관한 블로그를 작성했습니다.

그것은 마치 미래처럼 느껴졌습니다.

우리는 새로운 셀프 서비스 액션(action)을 생성할 수 있는 셀프 서비스 액션을 구축했습니다. 이를 통해 우리는 더 빠르게 움직이고, 병목 현상을 줄이며, 수백 명의 개발자를 지원하는 소규모 플랫폼 엔지니어링(Platform Engineering) 팀의 규모를 확장할 수 있었습니다.

가장 흥미로운 부분 중 하나는 Amazon Bedrock을 사용하여 런타임(runtime)에 Terraform 코드를 동적으로 생성하는 것이었습니다. 이를 통해 시스템은 기존 Terraform 모듈을 사용하여 새로운 클라우드 리소스가 어떻게 프로비저닝(provisioned)되어야 하는지 결정할 수 있었습니다.

그것은 작동했습니다.

인상적이었습니다.

그리고… 우리는 그것을 제거했습니다.

돌이켜보면, 그 방식을 포기한 것은 우리가 내린 최고의 엔지니어링 결정 중 하나였습니다.

당시에는 그것이 고립된 기술적 결정처럼 느껴졌습니다.

하지만 그렇지 않았습니다.

최근에 우리는 훨씬 더 작은 문제에 직면했습니다. 우리는 셀프 서비스 플랫폼을 통해 Cloudflare에서 DNS 레코드 생성을 자동화하고 싶었습니다.

첫 번째 제안은 오늘날 여러분이 예상할 법한 내용이었습니다: “Claude Skill을 만들자.”

즉시 강한 데자뷔(deja vu)가 느껴졌습니다.

하지만 저의 망설임은 AI가 그것을 할 수 있는지에 대한 것이 아니라, 그것을 해야 하는지에 대한 것이었습니다.

우리는 단순히 잘못된 질문을 던지고 있었습니다.

업계의 변화

오늘날 많은 엔지니어는 지난 10년 동안 배운 모든 것이 갑자기 덜 중요해졌다고 느낍니다.

우리는 DevOps 엔지니어입니다.

우리는 플랫폼 엔지니어(Platform Engineers)입니다.

우리는 코드 한 줄을 쓰기 전에 시스템을 설계하고, 표준을 정의하고, 아키텍처를 검토하고, 계획을 세우는 데 시간을 보냈습니다.

모든 자동화는 동일한 질문에서 시작되었습니다:

“이것을 어떻게 자동화해야 할까?”

오늘날, 그 질문은 조용히 변했습니다. 이제 우리는 이렇게 묻습니다:

“AI가 이것을 어떻게 할 수 있을까?”

언뜻 보기에 그것은 진보처럼 들립니다. 그리고 때로는 실제로 그렇기도 합니다.
대규모 언어 모델(Large Language Models, LLM)은 우리가 소프트웨어를 구축하는 방식을 근본적으로 바꾸어 놓았습니다. 몇 시간이 걸리던 작업이 이제 몇 분 만에 끝나고, 단 하나의 프롬프트(prompt)로부터 전체 프로토타입(prototype)이 나타납니다.

그 유혹은 명백합니다. AI가 할 수 있다면… 왜 AI에게 맡기지 않겠습니까?

하지만 그 과정 중 어디에선가, 우리 중 많은 이들이 무의식적으로 도구 그 이상을 바꾸어 놓았습니다. 우리는 엔지니어링 프로세스(engineering process)를 바꾸어 버렸습니다.

아키텍처(architecture)를 먼저 설계하는 대신, 기술을 먼저 선택하게 된 것입니다.

논의는 다음과 같이 흘러갑니다:

• “Claude를 써야 할까, 아니면 GPT를 써야 할까?”
• “이것을 에이전트 (Agent)로 만들어야 할까?”
• “Hermes가 할 수 있을까?”

이 훨씬 더 단순한 질문에 답하기도 전에 말입니다:

이 문제에 실제로 “추론 (reasoning)”이 필요한가?

런타임 추론 (Runtime Reasoning) vs. 결정론적 실행 (Deterministic Execution)

사람들은 흔히 AI 에이전트 (Agents), 스킬 (Skills), MCP 서버, 그리고 LLM 워크플로 (workflows)를 마치 단순히 차세대 자동화 기술인 것처럼 이야기합니다.

하지만 그렇지 않습니다.

이들은 다른 유형의 문제를 해결합니다.

LLM은 복잡하고 모호한 문제를 추론하는 데 탁월합니다. 계획을 조정하고 변경할 수도 있습니다. 하지만 추론은 확률 (probability)을 추가합니다. 즉, 더 이상 100% 확실하지 않다는 뜻입니다.

그 능력은 믿을 수 없을 정도로 강력하지만, 근본적인 트레이드오프 (tradeoffs)를 동반합니다. 추론은 정의상 프로세스에 확률을 도입합니다.

전통적인 자동화는 결정론적 (deterministic)입니다. 모든 단계는 예측 가능하고 테스트 가능하며, 매번 동일한 결과를 생성합니다.

다시 우리의 DNS 예시로 돌아가 보겠습니다:

Slack Form ──► Lambda ──► DynamoDB ──► Terraform ──► Cloudflare
이 파이프라인(pipeline)의 그 어떤 것도 해석 (interpretation)을 필요로 하지 않았습니다.

우리는 원하는 상태를 알고 있었고, 코드는 이미 존재했으며, 단계는 명확했습니다. 그런데 왜 “확실한” 프로세스에 “어쩌면”이라는 요소를 도입하려 할까요?

엣지(Edge)에서 추론하고, 코어(Core)에서 실행하라.

LLM은 시스템의 경계(boundaries)에서 믿을 수 없을 정도로 가치 있을 수 있습니다. 개발자가 Slack에 다음과 같이 작성한다고 상상해 보십시오: “우리의 새로운 로드 밸런서(load balancer)를 가리키는 api.staging용 CNAME을 생성해 줘.”

이러한 자연어 문장을 구조화된 JSON 페이로드 (payload)로 변환하는 것은 바로 LLM이 뛰어난 역량을 발휘하는 모호함의 영역입니다. 자연어는 무질서하고, 인간은 맥락을 생략하며, 의도는 해석이 필요합니다. 이것이 진정한 추론 문제(reasoning problem)입니다.

구조화된 출력 (Structured Outputs)은 포맷팅 (formatting) 문제를 해결합니다. 하지만 의사 결정 (decision-making) 문제를 해결하지는 않습니다.

위험 요소는 확률적 모델 (probabilistic model)이 프로덕션 (production) 환경에서 어떤 도구를 실행할지 결정하도록 방치하는 것입니다.

사용자의 의도 (user intent)가 구조화된 데이터 (structured data)가 되는 순간 (또는 처음부터 구조화된 Slack 양식을 통해 수집된 경우), 나머지 파이프라인은 더 이상 추론 (reasoning)으로부터 이득을 얻지 못합니다. 그 이후의 모든 단계는 예측 가능하고 (predictable), 테스트 가능하며 (testable), 결정론적 (deterministic)인 표준 프로덕션 소프트웨어처럼 동작해야 합니다.

결정적으로, LLM에 의해 생성된 구조화된 데이터는 코어 (core)에서 엄격한 스키마 검증 (schema validation)과 결정론적 권한 부여 정책 (RBAC)을 통과합니다. 설령 엣지 (edge)에서 LLM이 조작되더라도, LLM은 오직 액션 (actions)을 요청할 수 있을 뿐입니다. 코어는 실행이 인프라 (infrastructure)에 닿기 전에 사용자가 해당 액션을 수행할 권한이 있는지 독립적으로 검증합니다.

LLM은 액션을 제안합니다.

플랫폼은 그것이 허용되는지 결정합니다.

이러한 깨달음은 우리를 명확한 아키텍처 원칙으로 이끌었습니다:

엣지에서 추론하고, 코어에서 결정론적으로 실행하라.

런타임 추론 (Runtime Reasoning)의 숨겨진 비용

워크플로 (workflow) 대신 AI 스킬 (AI Skill)을 사용하는 것은 처음에는 빨라 보이지만, 안정성과 보안 측면에서 숨겨진 비용을 발생시킵니다.

실행 경로 (execution path)에 런타임 추론을 도입하면, 프로덕션의 안정성, 보안 및 비용에 직접적인 영향을 미치는 근본적인 트레이드오프 (tradeoffs)를 받아들여야 합니다.

이러한 트레이드오프가 프로덕션에서 나타나는 방식은 다음과 같습니다:

Human in the Loop 병목 현상

LLM이 관리자의 감독 없이 프로덕션 변경 사항을 실행할 수 있다고 신뢰할 수 없다면, 누군가는 모든 실행 건을 수동으로 검토해야 합니다 (예를 들어, PR을 생성하는 경우).

이는 당신이 해결하려고 했던 바로 그 병목 현상을 다시 불러옵니다.

확률적 인프라 (Probabilistic Infrastructure)

스크립트 (script)는 명령을 따르지만, LLM은 선택을 합니다.

프로덕션은 AI가 실수를 저질렀다는 사실을 확인하는 장소가 아닙니다.

사용하지 않는 지능에 대한 비용 지불

스크립트는 비용이 거의 들지 않습니다. LLM은 토큰 (tokens) 비용이 듭니다.

만약 워크플로가 이미 예측 가능했다면, 당신은 실제로 필요하지 않은 "지능"에 대해 비용을 지불하고 있는 것입니다.

공격 표면 (Attack Surface)의 확장

결정론적 워크플로는 당신이 명시적으로 작성한 코드만을 실행합니다.

LLM은 프롬프트(Prompt)를 어떻게 해석하느냐에 따라 동작을 실행합니다.

LLM이 실행 경로(Execution Path)에 직접 위치하는 순간, 프롬프트 인젝션 (Prompt Injection), 컨텍스트 포이즈닝 (Context Poisoning), 그리고 예기치 않은 도구 실행 (Unexpected Tool Execution)이 당신의 위협 모델 (Threat Model)의 일부가 됩니다.

인프라를 위해서는 즉흥적인 대응이 아닌 예측 가능성 (Predictability)이 필요합니다.

백만 번을 실행해도 똑같은 일을 수행하는 스크립트가, 대부분의 경우

그것은 불확실성 (Uncertainty)을 실제로 그로부터 이득을 얻을 수 있는 시스템의 부분으로 한정하는 것에 관한 문제입니다.