생성적 하네스 (Generative Harness): 에이전트가 스스로 실행 구조를 작성하기 시작할 때

에이전트 시스템은 대부분 하나의 단순한 가정(assumption)을 바탕으로 구축되어 왔습니다. 즉, 모델이 다음에 무엇을 할지는 결정할 수 있지만, 이를 둘러싼 실행 구조(execution structure)는 개발자에 의해 설계된다는 것입니다. 우리는 모델에게 도구(tools)를 제공하고, 루프(loop)를 정의하며, 컨텍스트(context)를 관리하고, 권한을 제한하며, 트레이스(traces)를 기록하고, 재시도(retries)를 추가하며, 때로는 인간의 승인(human approval) 단계를 삽입합니다. 모델은 행동하지만, 시스템이 행동의 형태를 결정합니다.

그 가정이 약해지기 시작했습니다.

에이전트 스택(agent stack)의 여러 부분에서 새로운 패턴이 나타나고 있습니다. 모델은 더 이상 고정된 루프 안에서 다음 도구를 선택하는 것에 그치지 않습니다. 모델은 실행 구조의 일부를 직접 생성하기 시작하고 있습니다. 즉, 도구를 조합하는 코드, 워커(workers)를 조율하는 스크립트, 그리고 작업이 어떻게 분해(decomposed), 병렬화(parallelized), 검증(checked), 요약(summarized)되어야 하는지를 결정하는 워크플로(workflows)를 생성합니다. 저는 이 패턴을 **생성적 하네스 (generative harness)**라고 부르고 싶습니다.

이 용어 자체보다는 이 용어가 가리키는 변화가 더 중요합니다. 하네스(harness)란 모델의 능력을 작업 완료로 전환하는 실행 구조를 의미합니다. 초기 시스템에서 이 구조는 고정되어 있었거나 개발자가 작성한 것이었습니다. 생성적 하네스에서는 모델이 작업 특화적인 오케스트레이션(orchestration)을 생성하기 시작하고, 런타임(runtime)이 이를 실행합니다.

이는 강력하지만, 핵심적인 문제를 변화시킵니다. 병목 현상(bottleneck)은 더 이상 에이전트가 실행할 수 있는지 여부만이 아닙니다. 그것이 생성한 오케스트레이션을 우리가 검증(verify)할 수 있는지 여부입니다.

행동에서 오케스트레이션으로

초기 도구 호출(tool-calling) 에이전트들은 의도적으로 단순했습니다. 모델이 행동을 선택하면, 도구가 관찰 결과(observation)를 반환하고, 다음 모델 호출이 그 결과를 어떻게 처리할지 결정하는 방식이었습니다. 이 루프는 제한적이고 종종 비효율적이지만, 한 가지 유용한 특성을 가지고 있습니다. 바로 피드백이 국소적(local)이라는 점입니다. 만약 도구 호출이 잘못된 인자(argument)를 사용하거나, 누락된 파일을 읽으려 하거나, 권한 오류(permission error)가 발생하면, 그 실수는 대개 즉시 나타납니다. 그러면 다음 턴(turn)에서 이를 수정할 수 있습니다.

LangGraph는 동일한 문제에 대해 더 명시적인 해답을 제시합니다. 개발자는 암시적인 루프(implicit loop)에 의존하는 대신, 상태(state), 전이(transitions), 체크포인트(checkpoints), 인간 참여(human-in-the-loop) 게이트, 그리고 내구성 있는 실행(durable execution)을 포함하는 그래프로 오케스트레이션(orchestration)을 정의할 수 있습니다. LangGraph는 에이전트 오케스트레이션을 일반적인 루프 안에 숨기는 대신, 이를 가시화하고 제어 가능하게 만들기 때문에 여전히 중요한 이정표입니다. 하지만 오케스트레이션은 여전히 주로 개발자에 의해 작성됩니다. 그래프는 작업이 실행되기 전에 존재하며, 모델은 그 안에서 동작합니다. 장기 실행되는 상태 유지 에이전트(stateful agents)를 위한 저수준 오케스트레이션 프레임워크로서의 LangGraph의 포지셔닝은 이러한 역할을 명확히 해줍니다.

이는 현재 변화하고 있는 모습과 유용한 대조를 이룹니다. 개발자가 작성한 오케스트레이션은 검사 가능하고 통제 가능하다는 점에서 가치가 있습니다. 하지만 모든 작업 형태에 맞춰 설계하는 것은 비용이 많이 듭니다. 어떤 작업은 팬아웃(fan-out) 검색이 필요하고, 어떤 작업은 맵리듀스(map-reduce)가 필요하며, 어떤 작업은 독립적인 검증이 필요하고, 또 어떤 작업은 다단계 마이그레이션에 이은 테스트와 복구가 필요합니다. 단일 고정 루프는 너무 취약한 반면, 미리 작성된 그래프는 너무 정적일 수 있습니다. 여기서 자연스러운 질문은 모델이 당면한 작업에 적합한 오케스트레이션을 스스로 생성할 수 있는가 하는 점입니다.

CodeAct는 액션(action) 수준에서 그 질문에 대한 하나의 해답입니다. 핵심 아이디어는 모델이 JSON 호출이나 미리 정의된 텍스트 명령에 국한되지 않고, 실행 가능한 코드(executable code)를 액션으로 사용할 수 있게 하는 것입니다. CodeAct 논문에서 실행 가능한 Python 코드는 도구(tools)를 조합하고 실행 결과에 따라 액션을 동적으로 수정할 수 있는 통합된 액션 공간(action space)이 됩니다. 이는 코드가 한 번에 하나의 도구 호출로 표현하기 까다로운 제어 흐름(control flow)을 표현할 수 있기 때문에 중요합니다. 모델은 파일들을 루프 돌며 탐색하고, 함수를 호출하고, 결과를 파싱하고, 데이터를 집계하고, 조건을 확인하며, 구조화된 출력을 반환할 수 있습니다.

TanStack AI Code Mode는 애플리케이션 도구들을 위해 이러한 패턴을 더욱 구체화합니다. 모델에게 일련의 개별적인 도구 호출 (tool calls) 과정을 강요하는 대신, 샌드박스 (sandbox) 내에서 TypeScript 프로그램을 작성하고 실행할 수 있게 합니다. 해당 프로그램들은 도구들을 조합하고, 분기하고, 루프를 돌며, 병렬로 처리하고, 구조화된 결과를 반환할 수 있습니다. TanStack은 그 동기를 직접적으로 설명합니다: 한 번에 하나의 도구 호출만 수행하는 것이 병목 현상 (bottleneck)이라는 것입니다.

이것은 이미 생성적 하네스 (generative harness)의 한 형태이지만, 여전히 대부분 로컬 (local) 수준에 머물러 있습니다. 모델은 작은 실행 가능한 구조를 생성하고, 런타임 (runtime)은 비교적 빠른 피드백을 제공합니다. 코드는 파싱에 실패하거나, 런타임 에러 (runtime error)를 발생시키거나, 타임아웃 (time out)이 발생하거나, 도구를 잘못 호출하거나, 잘못된 형태의 값을 반환할 수 있습니다. 그러면 모델은 코드를 수정할 수 있습니다. 핵심은 생성된 구조가 실행 피드백을 여전히 받을 수 있을 만큼 충분히 작다는 점입니다.

**Claude Code의 동적 워크플로 (dynamic workflows)**는 이 아이디어를 더 큰 규모로 확장합니다. 여기서 모델은 단순히 몇 개의 도구를 조합하는 로컬 프로그램을 작성하는 것에 그치지 않습니다. Claude는 많은 하위 에이전트 (subagents), 중간 결과물, 그리고 검증 단계 (verification passes)를 조정하는 오케스트레이션 스크립트 (orchestration script)를 작성할 수 있습니다. 공식 문서에서는 동적 워크플로를 Claude가 작성하고 재실행할 수 있는 스크립트로 설명하며, 이를 통해 코드베이스 감사 (codebase audits), 대규모 마이그레이션 (large migrations), 교차 검증 연구 (cross-checked research)를 위해 많은 하위 에이전트를 오케스트레이션할 수 있다고 명시합니다. Anthropic의 출시 포스트에서는 Claude가 단일 세션 내에서 수십 개에서 수백 개의 병렬 하위 에이전트를 실행하는 오케스트레이션 스크립트를 동적으로 작성한다고 설명합니다.

이것은 질적으로 다른 경계입니다. CodeAct는 코드를 액션 (action)으로 만듭니다. Code Mode는 로컬 도구 조합을 프로그래밍 가능하게 만듭니다. 동적 워크플로는 태스크 수준의 오케스트레이션을 생성적으로 만듭니다.

검증 격차 (The verification gap)

생성적 하네스 (Generative Harness)의 매력은 명백합니다. 복잡한 태스크들은 모두 동일한 형태를 띠지 않습니다. 어떤 것은 병렬 탐색 (parallel exploration)을 필요로 하고, 어떤 것은 단계적 정교화 (staged refinement)를 필요로 하며, 어떤 것은 독립적인 비판 (independent critique)을 필요로 하고, 또 어떤 것은 최종 결론을 내리기 전에 증거를 수집할 수 있는 워크플로 (workflow)를 필요로 합니다. 만약 모든 태스크가 동일한 고정된 루프를 통과해야 한다면, 에이전트 (agent)는 컨텍스트 (context)와 시간을 낭비하게 됩니다. 만약 모든 워크플로를 개발자가 수동으로 설계해야 한다면, 시스템은 충분히 빠르게 적응할 수 없습니다. 모델이 태스크별 오케스트레이션 (orchestration)을 생성하도록 하는 것은 자연스러운 다음 단계입니다.

문제는 오케스트레이션이 실행 (action)보다 검증하기 더 어렵다는 점입니다.

단일 도구 호출 (tool call)은 로컬 피드백 (local feedback)을 가집니다. 호출이 성공했는가? 인자 (argument)가 유효했는가? 파일이 존재했는가? API가 데이터를 반환했는가? 코드 실행 (code action)은 실행 피드백 (execution feedback)을 가집니다. 코드가 실행되었는가? 타입 체크 (typecheck)를 통과했는가? 테스트가 통과했는가? 프로그램이 예상된 형태를 반환했는가? 개발자가 작성한 그래프 (graph)는 배포 전에 검토될 수 있습니다. 그 노드 (nodes), 전이 (transitions), 그리고 체크포인트 (checkpoints)를 조사할 수 있습니다.

생성된 워크플로는 다른 종류의 피드백이 필요합니다. 태스크가 올바른 차원을 따라 분해되었는가? 각 워커 (worker)가 적절한 컨텍스트를 전달받았는가? 적절한 서브태스크 (subtasks)들이 병렬화되었는가? 검증기 (verifier)가 실제 리스크를 확인했는가, 아니면 단순히 포맷팅 (formatting)만 확인했는가? 완료 기준 (completion criteria)이 충분히 강력했는가? 워크플로가 증거의 한 범주 전체를 놓치지는 않았는가?

이것이 생성적 하네스 (generative harness)를 위험하게 만드는 요소입니다. 잘못된 도구 호출은 로컬 에러 (local error)입니다. 잘못된 코드 실행은 종종 런타임 (runtime)에서 실패합니다. 하지만 잘못된 워크플로는 성공적으로 실행되면서도 여전히 틀릴 수 있습니다.

이러한 실패 모드(failure mode)는 시스템이 충돌하지 않을 수 있기 때문에 매우 미묘합니다. 사실, 모든 단계가 실행된 것처럼 보이기 때문에 오히려 더 설득력 있게 보일 수 있습니다. 워커(workers), 중간 요약(intermediate summaries), 검증기(verifier), 그리고 최종 보고서(final report)가 존재합니다. 프로세스는 완결된 것처럼 보이지만, 그 프로세스의 구조 자체는 한 번도 검증되지 않았을 수 있습니다.

이 지점에서 AI 슬롭(AI slop)과의 비유가 유용해집니다. 비록 이것이 주요 주제가 되어서는 안 되겠지만 말입니다. AI 슬롭은 흔히 저품질의 생성된 콘텐츠로 논의되지만, 그 이면의 더 깊은 패턴은 '검증되지 않은 완결성(unverified completion)'입니다. 출력물은 섹션, 유창한 언어, 결론, 때로는 인용문까지 갖추고 있지만, 실제적인 판단력이나 증거 밀도(evidence density)가 부족합니다. 생성적 하네스(Generative harness)는 프로세스 수준에서 동일한 패턴을 만들어낼 수 있습니다. 워크플로(workflow)가 단계, 워커, 검증, 그리고 다듬어진 최종 답변을 갖추고 있더라도, 오케스트레이션(orchestration) 자체가 결함이 있을 수 있습니다.

그런 의미에서 AI 슬롭은 콘텐츠 수준의 검증되지 않은 완결성입니다. 워크플로 슬롭(Workflow slop)은 프로세스 수준의 검증되지 않은 완결성입니다. 동일한 패턴이 출력물에서 실행 단계로 이동하는 것입니다.

오케스트레이션은 조용히 실패할 수 있다

이것이 중요한 이유는 생성된 워크플로가 증폭기(amplifier) 역할을 하기 때문입니다. 오케스트레이션이 올바를 때, 그것은 검색 범위를 넓히고, 조사를 병렬화하며, 독립적인 비판(critiques)을 수행하고, 대규모 마이그레이션을 조정하며, 결과가 사용자에게 도달하기 전에 검증할 수 있습니다. 반대로 오케스트레이션이 잘못되었을 때는, 모든 워커에 걸쳐 잘못된 가정을 증폭시킬 수 있습니다.

작업이 잘못된 차원을 따라 분해될 수 있습니다. 모든 하위 에이전트(subagents)가 동일한 결함이 있는 프레이밍(framing)을 상속받을 수 있습니다. 검증기는 증거가 주장을 뒷받침하는지 확인하는 대신, 최종 보고서가 형식에 맞게 작성되었는지만 확인할 수 있습니다. 워크플로는 "모든 워커가 응답함"을 "작업이 완료됨"과 동일하게 취급할 수 있습니다. 요약기(summarizer)에게 갈등 상황을 보존하라는 지침이 내려지지 않았다면, 최종 합성(synthesis) 과정에서 워커들 사이의 의견 불일치가 숨겨질 수 있습니다.

이것들은 일반적인 실행 오류 (execution errors)가 아닙니다. 이것들은 오케스트레이션 오류 (orchestration errors)입니다. 이 오류들은 반드시 예외 (exceptions), 테스트 실패, 또는 잘못된 도구 응답 (invalid tool responses)의 형태로 나타나지 않을 수도 있습니다. 대신, 세련되고 구조화되어 있지만 틀린 결과를 만들어낼 수 있습니다.

이것이 생성적 하네스 (generative harness)의 핵심적인 긴장 상태입니다. 즉, 우리가 그 구조를 검증할 성숙한 방법을 갖추기 전에 모델이 작업의 구조를 먼저 생성할 수 있다는 점입니다.

검증된 생성적 하네스를 향하여

해답은 생성적 하네스를 피하는 것이 아닙니다. 고정된 루프 (fixed loops)는 너무 경직되어 있으며, 개발자가 작성한 그래프 (graphs)는 모든 작업 형태를 다룰 수 없습니다. 만약 에이전트가 개방형 작업 (open-ended tasks)을 수행해야 한다면, 필요에 따라 실행 구조를 합성 (synthesize)할 수 있는 능력이 필요할 것입니다.

다음 단계는 이러한 구조들을 통제 가능하게 (governable) 만드는 것입니다. 생성적 하네스를 위한 런타임 (runtime)은 단순히 도구를 실행하고 워커 (workers)를 시작하는 것에 그쳐서는 안 됩니다. 생성된 오케스트레이션을 검사, 제약 및 검증 (inspect, constrain, and validate)해야 합니다. 이는 워크플로 사전 점검 (workflow preflight), 범위 및 예산 확인 (scope and budget checks), 컨텍스트 커버리지 확인 (context coverage checks), 체크포인트 검토 (checkpoint reviews), 독립적 검증기 (independent verifiers), 트레이스 기반 최종 검증 (trace-based final validation), 구조적 경계에서의 인간 승인 (human approval at structural boundaries), 그리고 재사용 가능한 워크플로를 위한 회귀 테스트 (regression tests)를 의미합니다.

여기서 중요한 단어는 '구조적 (structural)'입니다. 우리는 이미 개별 행동과 코드 실행을 검증하는 부분적인 방법들을 가지고 있습니다. 우리에게 부족한 것은 작업의 형태 그 자체에 대한 강력한 피드백 루프 (feedback loop)입니다. 검증된 생성적 하네스는 다음과 같은 질문에 답할 수 있어야 합니다: 모델이 어떤 워크플로를 생성했는가? 왜 이 분해 (decomposition) 방식이 선택되었는가? 각 워커는 어떤 컨텍스트를 받았는가? 최종 답변을 뒷받침하는 증거는 무엇인가? 검증기가 실제로 검증한 것은 무엇인가? 워크플로가 원래 범위를 벗어난 지점은 어디인가? 이 워크플로를 저장, 재사용 또는 폐기해야 하는가?

이는 플랫폼의 책임을 상위 단계로 격상시킵니다. 이제 런타임 (Runtime)이 도구 호출 (Tool call)을 안전하게 실행하는 것만으로는 충분하지 않습니다. 런타임은 생성된 오케스트레이션 (Orchestration)을 감독해야 합니다.