LLM 하이프 사이클이 시작될 때, 우리 시대의 큰 논쟁 중 하나가 Python과 Markdown 사이의 에이전트 명세 언어 선택이 될 거라고는 아무도 예상하지 못했습니다. 하지만 The AI Frontier(Vikram Sreekanti 외)가 Agent Native 시리즈의 일부로 짚듯, 이 질문은 빠르게 AI 아키텍처에서 가장 결정적인 논쟁이 되었습니다. 글의 핵심 주장은 단순합니다 — 이 논쟁은 두 개의 방어 가능한 입장 사이의 선택이 아니라, 양쪽 모두 실패 모드라는 것입니다. 어느 쪽도 agent-native가 아니기 때문입니다.
원문: Agents can’t choose between structure and flexibility — The AI Frontier (Agent Native series)
두 캠프의 정의
| 캠프 | 표현 수단 | 무엇을 표현하나 | 트레이드오프 |
|---|---|---|---|
| Python 캠프 | 코드 | 에이전트가 밟아야 할 단계의 엄격한 요구사항 | 강한 가드레일·계획 이탈 위험 ↓ / 유연성 ↓ |
| Markdown 캠프 | 영어 | 넓은 목표와 제약, 경로는 모델이 계획 | 도구·모델 간 이식성 ↑ / 예기치 못한 행동 위험 ↑ |
대부분의 논쟁은 이를 두 개의 방어 가능한 입장으로 다룹니다. 글의 진단: 둘 다 실패 모드다. 한쪽을 고르는 것은 에이전트를 진짜로 설계하는 어려운 일을 회피하는 방식일 뿐입니다.
“Picking a side is how you avoid the hard work of designing an agent.”
그리고 양쪽의 종착지는 같습니다 — “인간이 하던 일을 다른 문법으로 복붙하는 것”.
코드 최대주의가 놓치는 것
코드 최대주의의 세일즈 포인트는 신뢰성입니다. 에이전트에게 무엇을 할지 정확히 명시하고, 깨지면 에러를 띄우고, 결과를 좁게 묶어둡니다. LLM이 실수하고 의도를 오해하고 이상한 짓을 한다는 점을 생각하면 매력적으로 들립니다.
저자들은 자신들의 AI SRE 도메인 경험을 사례로 듭니다. 거의 모든 벤더가 고객에게 runbook 작성을 요구합니다. 제품은 그 runbook을 워크플로로 인코딩하고, 특정 알림에 대해 에이전트가 그 워크플로를 실행하게 합니다. 결과는 좁은 의미에서 신뢰할 만합니다 — 예상한 대로 동작합니다. 하지만 알림이 과거와 다르게 보이거나 아키텍처가 바뀌는 순간 쓸모없어집니다. RunLLM도 초기에 이 길을 갔다가 빠르게 실패를 확인했습니다.
실패의 세 가지 양상
- 인간 행동의 복붙 — 인간은 가장 가능성 높은 단일 가설을 골라 직렬로 따라갑니다. 자신감이 있을 때는 잘 작동하지만, 첫 가설이 틀리면 엄청난 낭비가 발생합니다. 에이전트는 그 함정에 빠질 필요가 없습니다 — 여러 가설을 병렬로 평가할 수 있고, 일부는 막다른 길이지만 정답에 도달할 확률이 극적으로 올라갑니다. RunLLM은 이 아키텍처로 만들어졌고, 실제 인시던트가 그렇게 해결되는 것을 본다고 말합니다.
- 인간에게 의미 있는 가시성을 주지 않음 — SRE는 “에이전트가 런북 3단계를 실행했는지"를 확인할 필요가 없습니다. 그들은 에이전트가 무엇을 시도했고, 무엇을 배제했고, 왜 그랬는지를 알아야 합니다. 잘 닦인 길은 지루한 일을 자동화하지만, 사람이 에이전트의 추론을 신뢰하거나 배울 수 없게 합니다.
- 인코딩된 워크플로는 진화하지 않음 — 에이전트가 약속하는 지능을 잃습니다. 시스템이 바뀌거나 요구사항이 바뀌면 모든 인코딩이 따라 바뀌어야 합니다. 에이전트가 피드백을 받아 기대 행동이 달라졌음을 이해하고 스스로 적응할 길이 없습니다 — 누군가 harness를 손봐야 합니다.
마크다운 최대주의가 놓치는 것
마크다운 최대주의는 유연성을 최적화합니다. 목표를 기술하고, 능력 있는 모델에게 넘기고, 알아서 풀게 합니다. 이식성이 높고, 표현력이 좋고, 빠르게 동작하는 것을 얻습니다. 창의성과 열린 문제 해결이 중요한 곳에서는 고정된 워크플로보다 극적으로 유용할 수 있습니다.
변질된 형태: AI 슬라이드 생성
저자들이 드는 사례는 AI 슬라이드 생성기입니다. 외부에서 보면 “LLM에게 다 시킨다” 형태로 읽힙니다 — 프롬프트 하나 넣으면 전체 데크가 나옵니다. 실패 모드는 누구나 익숙합니다.
- 슬라이드 7의 레이아웃이 이상하다
- 차트가 주장과 맞지 않는다
- 논리 흐름이 뒤엉켜 있다
이때 사용자는 말하고 싶습니다 — “슬라이드 7에서 흐름을 가로 대신 세로로 바꾸고, 차트를 아래로 옮겨줘.” 보통 이게 의도대로 작동하지 않습니다. 조정할 수 있는 이산적인 레이아웃 로직이 없고, 차트 배치를 위한 분리된 단계가 없으며, 전체 생성보다 작은 주소 가능한 단위가 없습니다. 다시 프롬프트를 넣고, 다른 방식으로 틀린 새 데크를 받고, 처음부터 다시 시작합니다.
정교한 마크다운 최대주의도 마찬가지
이를 허수아비라고 치워서는 안 됩니다. 진지한 마크다운 최대주의자는 모든 앱을 원샷하자고 주장하지 않습니다. 정교한 버전은 skills.md + 기본 에이전트 루프 — 풍부한 컨텍스트, 사려 깊은 지시, 추론하는 능력 있는 모델을 통해 이끄는 접근입니다.
복잡한 애플리케이션이 그 격차를 드러냅니다. 현실과 부딪히면, 여전히 엄격한 제약이 필요한 엔지니어링 결정들이 남습니다.
- 컨텍스트 관리 및
- 모델 선택
- 비용 관리
- 교차 에이전트(cross-agent) 조정
이 각각의 과제는 모델의 추론을 신뢰하지 않는 것이 아닙니다. 사려 깊은 모델이 이 작업을 효율적이고 안정적으로 실행하도록 돕는 도구와 인프라를 짓는 것이 과제입니다.
프로덕션에서 이는 컨텍스트 관리·모델 라우팅·서브에이전트 오케스트레이션·순수 프롬프팅이 깨지는 예측 가능한 지점 처리를 담당하는 code harness로 귀결됩니다. 이는 정확히 마크다운이 가이드 작업을 하고 코드가 구조 작업을 하는 하이브리드 아키텍처 — 즉 원래 논쟁이 다투려던 그 입장입니다.
마크다운 최대주의로 시작해도, 결국 콘텐츠 관리·모델 라우팅 같은 좁은 harness 같은 능력을 잔뜩 지을 수밖에 없습니다. 질문은 그 후크를 의도적으로 설계할지, 코드 컴포넌트가 유기적으로 자라게 둘지일 뿐입니다.
하이브리드는 타협이 아니다
진지한 에이전트를 만드는 팀들은 거의 독립적으로 같은 자리에 도달했습니다.
- Markdown — 의도(intent)와 도메인 가이드
- Code — 강제(enforcement), 도구 실행, 그리고 조용히 실패해서는 안 되는 모든 것
“Claude Code works this way. We built RunLLM this way.”
이를 무성격한 타협으로 읽으면 안 됩니다. 에이전트의 핵심은 — 전통 소프트웨어와 달리 — 풀어야 할 문제를 이해하고 적합한 도구를 골라 도달할 수 있다는 점입니다.
| 입장 | 무엇을 타협하는가 |
|---|---|
| 코드 최대주의 | 계획(planning) 을 타협 — 추론을 빼앗긴 워크플로 |
| 마크다운 최대주의 | 실행(execution)과 학습(learning) 을 타협 — 의도만 있고 깨지는 시스템 |
| 하이브리드 | 어느 쪽도 타협하지 않음 — 두 레이어가 각자의 일을 함 |
“Neither extreme gives you both, which means neither maximalist position gives you a truly flexible agent. It gives you either a workflow with aspirations or a wish with nothing to execute it.”
아키텍처 작업의 본질은 시스템의 각 부분에 대해 어느 레이어에 속하는지 판정하는 것입니다.
- 무엇이 의도로 표현되어 추론의 대상이 되는가?
- 무엇이 강제·검증되어야 하는가?
- 어디에 창의성이 필요하고, 어디에 제약이 필요한가?
이것이 어려운 부분이며, 한쪽 진영을 고르는 일은 바로 이 어려움을 회피하는 방식입니다.
Agent-native가 실제로 요구하는 것 — 4개의 진단 질문
Python vs Markdown을 더 이상 논쟁의 축으로 두지 않으면, 진짜 아키텍처 우선순위가 또렷해집니다.
| # | 질문 | 코드 최대주의 | 마크다운 최대주의 | Agent-native |
|---|---|---|---|---|
| 1 | 여러 가설을 병렬로 평가하는가, 하나를 직렬로 따라가는가? | 직렬 | 모델 의존 | 병렬 평가 |
| 2 | 사람이 에이전트가 시도한 것과 그 이유를 볼 수 있는가, 최종 답만 받는가? | 단계 실행 로그만 | 블랙박스 | 시도/배제/근거 노출 |
| 3 | 시스템이 바뀔 때 에이전트가 적응하는가, 누가 harness를 편집해야 하는가? | 매번 재인코딩 | 자동이지만 통제 불가 | 피드백 루프 + 가드레일 |
| 4 | 사용자가 자신이 신경 쓰는 입자도(granularity) 로 출력을 교정할 수 있는가, all-or-nothing인가? | 변경 단위가 큼 | all-or-nothing | 주소 가능한 단위 |
왜 이 논쟁이 여전히 살아 있는가
저자들의 결론적 진단:
“The maximalist debates are a symptom of an industry still thinking about agents as workflow automators — either very rigid ones, or very loose ones.”
에이전트 네이티브 제품을 만드는 팀들은 이미 이 논쟁을 지나갔습니다. 그들이 알아낸 것은 이 논쟁이 처음부터 Python이냐 Markdown이냐의 문제가 아니었다는 사실입니다. 진짜 질문은 “에이전트처럼 행동하는 것을 만들기 위한 작업을 할 의지가 있는가” 였습니다.
실무 체크리스트
- 에이전트의 각 구성요소를 intent 레이어 / enforcement 레이어로 라벨링
- enforcement 중 “조용히 실패하면 안 되는” 지점은 반드시 코드로 — 컨텍스트 관리, 모델 라우팅, 비용 관리, 교차 에이전트 조정
- intent 마크다운은 절차가 아니라 목표·제약·도메인 지식에 집중
- 단일 가설 직렬 추적을 기본값으로 둔 부분이 있는지 감사 — 가능한 곳은 병렬 가설 평가로 전환
- 에이전트 출력에 시도/배제/근거 가시성 노출 — 단순 step log 아님
- 사용자 교정의 입자도 점검 — “슬라이드 7만 세로로” 같은 요청을 받을 주소 가능한 단위가 있는가?
- 시스템 변화 시 에이전트가 피드백으로 적응할 통로가 있는지 (없으면 매번 harness 패치 신세)
핵심 인용
“Picking a side is how you avoid the hard work of designing an agent.”
“Either a workflow with aspirations or a wish with nothing to execute it.”
“Markdown for intent and domain guidance, code for enforcement, tool execution, and anything that must not fail silently.”
“The argument was never really about Python or Markdown. It was about whether you were willing to do the work to build something that actually behaves like an agent.”
결론 — 양쪽 진영은 모두 인간 행동의 복붙이다
에이전트 설계의 성숙도는 어떤 문법을 쓰느냐가 아니라 어떤 것을 어느 레이어에 두느냐, 그리고 에이전트가 인간보다 더 잘 할 수 있는 것(병렬 가설 평가, 적응, 입자도 있는 교정)을 실제로 활용하느냐로 측정됩니다. Python 최대주의는 직렬로 답을 쫓는 인간을 자동화하고, Markdown 최대주의는 전체 산출물을 한 번에 던지는 인간을 자동화합니다 — 둘 다 에이전트의 의미를 잃습니다.
에이전트는 구조와 유연성 사이에서 고를 수 없다 — 둘 다 필요하고, 둘은 서로 다른 레이어에서 공존해야 한다. 그리고 그 레이어 분리를 설계하는 일이 바로 에이전트 네이티브의 본업이다.