이 문서는 정리된 내용을 바탕으로 Claude Opus 4.8이 작성했습니다. 올바른 AI 사용법!

정리 방식 등이 저답지는 않지만, 뭐 괜찮습니다.

서론

AI Engineering Summit Tokyo 2026(#AIE2026_findy)에 참가했기에, 총괄 내용이라도 남겨두려 합니다.

지난 반년 동안 변한 것은, 솔직히 말해 "모델이 어떠하다"라는 이야기가 아닙니다. 변화한 것은 모델 그 자체가 아니라, 그 주변에 있는 다음 4가지 영역입니다.

• harness
• HOTL (Human on the Loop)
• Token ROI
• 도메인 분석 (Domain Analysis)

이벤트 전체의 기조가 "Human in the Loop에서 Human on the Loop로"였고, Day 2의 테마가 "개인 이용에서 조직 전개로"였다는 점에서도 알 수 있듯이, 회장의 무게 중심은 모델 단일 성능이 아니라 그 주변의 설계·운용·조직으로 명확하게 이동하고 있었습니다. 본고에서는 이 4가지 축을 정리한 후, 한 걸음 더 들어가 생각해 두어야 할 논점을 보충하겠습니다.

주전장의 이동: 지수와 로그 (Token ROI)

이번에 가장 중요하다고 생각한 지적부터 시작하겠습니다.

• Token 사용량이나 모델의 진화는 **지수적 (Exponential)**입니다.
• 하지만 비즈니스 가치 향상은 **로그적 (Logarithmic)**입니다.

이것은 매우 중요한 지점입니다. 모델은 확실히 향상되었습니다. 하지만 거기서 끌어낼 수 있는 비즈니스 가치의 ROI (Return on Investment) 향상은 한계에 다다르고 있습니다. 그렇다면 모델 그 자체는 이제 "중요한 전장이 아니다"라는 결론에 이릅니다. 이번 이벤트에서 도메인 분석, harness, 프로세스에 대한 논의가 많았던 것은 이러한 귀결 때문이라고 생각합니다.

보충: 승부는 ROI의 "분모"로 옮겨간다

가치(분자)가 로그 함수적으로 한계에 부딪힌다면, 승부는 비용(분모)의 정의로 옮겨갑니다.

여기서 작용하는 것이 비용의 비대칭성입니다. Token 비용은 지수적으로 낮아집니다. 반면, 도메인 분석, harness 구축, HOTL 리뷰에 들어가는 "인간과 설계의 비용"은 그렇게 쉽게 낮아지지 않습니다. 즉, 새로운 병목 현상은 추론 비용이 아니라 **오케스트레이션 비용 (Orchestration Cost)**으로 이동하고 있습니다.

"왜 이번에 도메인 분석과 harness가 중심 의제가 되었는가"라는 질문에 대한 경제적인 답은 여기에 있습니다. 후술할 "불필요한 Token을 사용하는 것 = 생산 ROI의 악화"도 이 분모 이야기의 일부로 재정의할 수 있습니다.

보충: 분자는 PDO로 확장할 수 있다, 단 확실성이 조건이다

분모를 억제하는 것과 나란히, 또 다른 레버는 분자의 확장입니다. 하나의 스트림에서 끌어낼 수 있는 가치가 로그 함수적으로 한계에 부딪힌다 하더라도, 분자 자체를 늘리는 수단은 있습니다. 그것이 PDO (Parallel Development Orchestration)를 통한 병렬화입니다.

포인트는 PDO가 "1개 스트림당의 로그 곡선"을 뒤집는 것이 아니라는 점입니다. 뒤집는 것이 아니라, **병렬로 실행하는 스트림의 수 (Throughput)**를 늘림으로써 총량으로서의 분자를 밀어 올리는 것입니다. 질문은 "하나의 Agent로부터 얼마나 많은 가치가 나오는가"에서 "얼마나 많은 병렬 스트림을 확실하게 실행할 수 있는가"로 옮겨갑니다.

단, 여기에는 조건이 있습니다. Agentic Workflow가 제대로 운용되지 않으면, 병렬화는 그대로 backtrack (되돌아가기) 비용의 증대로 이어집니다. 병렬 스트림이 의도에서 벗어나거나, 머지(Merge) 지점에서 전제가 충돌하면, 재작업 비용만 불어나 공들여 확장한 분자를 갉아먹게 됩니다. 즉, PDO의 효과는 워크플로의 확실성이라는 천장에 묶여 있습니다.

그럼에도 가치 증대를 위해 PDO는 피할 수 없습니다. 팀 규모라면 DLC (AI-DLC)적인 접근 방식으로 조정하는 방법이 있겠지만, 확실성에 대한 부담은 결국 개인 개발자·운용자에게까지 전가됩니다. 그렇기에 PDO의 개량은 피할 수 없으며, Agentic Workflow의 확실성을 높이는 것이 급무라고 생각합니다.

이 PDO 이야기는 본고 전체의 결절점이 됩니다. 분자(PDO)를 늘릴 수 있느냐는 후술할 harness, HOTL, eval이 담당하는 "확실성"에 그대로 의존하기 때문입니다.

HOTL: Human on the Loop

Agentic Workflow (에이전트 워크플로) 규칙의 근저에 깔린 것은, 인간을 어떻게 루프 (loop) 밖으로 뺄 것인가 하는 발상입니다. 단, HITL (Human-in-the-Loop)이 배제되는 것과는 다릅니다. 인간이 병목 (bottleneck)이라면, 그 인간을 어디까지 유효하게 사용할 수 있는가 하는 문제여야 합니다.

Agentic Workflow (에이전트 워크플로)의 병목은, "정의에는 부합하지만, 어떤 이유로 인해 인간의 의도와는 다른 일이 발생하는" 점에 있습니다. 그렇기에 어딘가에서 인간의 의도가 반영되고 있는지를 판정해야만 합니다. 그리고 그 루프를 AI만으로 닫는 것은 어렵습니다. 여기서 핵심이 되는 것이, 도메인 분석 (domain analysis)이 올바르게 반영되고 있는가 하는 열쇠입니다.

보충: 검증 (verification)과 타당성 확인 (validation)을 구분하기

이 "정의에는 부합하지만 의도와는 다른" 현상은 용어를 구분하면 단번에 파악하기 쉬워집니다.

• 검증 (verification): 사양(specification)대로 동작하고 있는가
• 타당성 확인 (validation): 애초에 그 사양/의도가 올바랐는가

HOTL (Human-on-the-Loop)이 진정으로 담당해야 할 것은 후자인 validation (타당성 확인)입니다. 사양을 충족하는지 (verification)는 후술할 harness가 기계적으로 담당할 수 있습니다. 하지만 "그 사양이 의도와 맞았는가"는 인간이 루프 (loop) 위에서 감시해야만 비로소 판정할 수 있습니다. HITL에서 HOTL로의 이행이란, 인간을 verification (검증) 작업에서 해방시켜 validation (타당성 확인)의 파수꾼으로 재배치하는 작업이라고 바꿔 말할 수 있습니다.

보충: 'on'으로 옮기는 순간 설명 책임이 질문된다

인간을 루프 (loop)의 "안"에서 "위"로 옮긴 순간, "사양 내에는 있지만 바람직하지 않은 결과"가 나왔을 때의 설명 책임(accountability) 소재가 문제가 됩니다. 이는 행사장 내 "AI의 오류가 허용되지 않는 업무 시스템에서 '신뢰받는 AI'를 목표로 한다" 계열의 세션들이 가진 배경이기도 합니다. HOTL을 논한다면, 누가 어떤 입도(granularity)로 결과에 책임을 질 것인가 하는 거버넌스 (governance) 설계를 함께 고민해야 합니다.

도메인 분석 (domain analysis)

"대충 AI에게 맡기고, 어긋나면 HITL로 수정한다"를 반복해서는 HOTL에 도달할 수 없습니다.

한편, 에이전트 (Agent)에게 맡길 때 도메인 분석 (domain analysis)이 문서에 반영되어 있지 않다면, 에이전트는 불필요한 토큰 (Token)을 소비하게 됩니다. 이는 생산 측면의 ROI (투자 대비 효율)를 직접적으로 악화시킵니다. 그렇기에 이 분석은 이전보다 정밀하게 수행되어야 하며, 에이전트를 위한 문서로서 기술되어야 합니다.

보충: 도메인 문서는 부패한다 (신선도 관리 문제)

여기서 운용상의 함정이 되는 것이, 도메인 문서는 시간이 흐름에 따라 진부화한다는 점입니다. 이는 Context Rot (컨텍스트 부패)과 동일한 유형의 문제로, 오래된 분석 문서는 "불필요한 토큰을 사용"할 뿐만 아니라 "자신 있게 틀린 출력을 내놓는" 결과로 이어집니다.

따라서 도메인 분석은 한 번 쓰고 끝내는 것이 아니라, 누가·언제·어떤 기준으로 업데이트할 것인지라는 라이프사이클 (lifecycle, 신선도 관리)까지 포함하여 설계해야 합니다. 에이전트용 문서 정비란, 쓰는 작업 그 이상으로 "부패하지 않는 메커니즘"을 만드는 작업입니다.

harness

harness는 Agentic Workflow (에이전트 워크플로)에 제약, 올바른 정보, 감사를 부여하여 에이전트를 올바르게 활용하기 위해 필수적입니다.

다만 앞으로는, 효과가 낮은 harness의 평가 및 도태가 진행되지 않을까요. Token maximize (토큰 극대화) 문제의 배경도 아마 여기에 있을 것입니다. "모델의 진화를 위해 노력합시다"라는 말을 들어도, 이용자가 오늘 당장 개선할 수 있는 부분은 바로 이 harness 부분입니다. 따라서 무엇을 만들고 그것을 어떻게 평가할 것인가라는 질문은 피할 수 없습니다.

보충: 평가 (Eval)를 harness의 내부에서 끌어내기

harness를 이야기할 때 eval (평가)이 묻히기 쉽지만, 본질적으로는 별개의 레이어 (layer)입니다. harness가 "제약·정보·감사의 메커니즘"이라면, eval은 "그 harness가 제대로 작동하는지를 측정하는 메타 메커니즘"입니다.

앞서 언급한 verification (검증) / validation (타당성 확인)의 구분을 여기에 겹쳐보면, 4개의 축이 깔끔하게 연결됩니다. harness는 verification을 기계화하고, HOTL은 validation을 담당하며, eval은 양자가 얼마나 기능하고 있는지를 측정합니다. "효과가 낮은 harness의 평가가 진행될 것"이라는 말은, 이 eval 측면의 지표가 아직 미성숙하기 때문에 앞으로의 전장이 될 것이라는 의미로 해석할 수 있습니다.

보충: Token maximize 문제의 정체는 인센티브의 비대칭

"Token maximize 문제의 배경은 여기서 무엇인가?"라는 질문에는 한 걸음 더 들어간 답을 내놓을 수 있습니다.

이는 principal-agent(본인-대리인)적인 인센티브의 비대칭입니다. 모델 벤더(Model Vendor) 측은 능력 및 이용량(token)의 최대화에 인센티브가 있고, 이용자 측은 가치의 최대화에 인센티브가 있습니다. 양자는 반드시 일치하지 않습니다. harness란 이용자가 이 줄다리기를 "가치 측"으로 다시 끌어오기 위한 장치에 다름 아닙니다.

그렇게 파악하면, "효과가 낮은 harness의 도태"는 시장이 이용자 측의 ROI(투자 대비 수익) 함수를 학습하기 시작했다는 징후로 읽을 수 있습니다.

조직과 프로세스: 개인 이용에서 조직 전개로

여기까지는 주로 기술·아키텍처(Architecture) 계층의 이야기였지만, Day 2의 테마가 보여주듯 진짜 고비는 조직 전개 계층에 있습니다.

도메인 분석(Domain Analysis)도 harness도, "누가 작성하고, 누가 유지보수하며, 어떻게 노후화를 방지할 것인가"라는 소유와 운용의 문제를 제외하고는 기능하지 않습니다. HITL(Human-in-the-loop)에서 HOTL(Human-on-the-loop)로의 전환은 언뜻 보면 개인의 작업 효율에 관한 이야기처럼 보이지만, 실제로는 조직의 의사결정 구조를 어떻게 재편할 것인가에 관한 이야기입니다. 인간을 loop 위에 둔다는 것은 리뷰와 책임의 권한을 어디에 배치할 것인가라는 조직 설계 그 자체를 묻는 것입니다.

더 나아가서, 앞서 언급했듯이 PDO(Predictable Deterministic Output)의 확실성에 대한 부담은 최종적으로 개인에게까지 되돌아옵니다. 팀 규모의 DLC(Dynamic Learning Cycle) 접근 방식으로 프레임워크를 정비하더라도, 마지막 한 수는 개별 개발자·운용자가 담당하게 됩니다. 즉, 조직 설계와 개인의 워크플로우(Workflow) 개선은 어느 한쪽만으로는 완결되지 않는다는 뜻입니다.

요약

이번 총괄을 한마디로 요약하자면, 전장은 모델에서 "그 주변"으로 옮겨갔다는 것입니다.

Token ROI: 가치는 로그(Log) 스케일로 한계에 부딪힌다. 분모인 오케스트레이션(Orchestration) 비용을 억제하면서, 분자는 PDO로 확장한다.
HOTL: 인간을 verification(검증)에서 해방시켜, validation(타당성 확인)의 파수꾼으로 재배치한다.
도메인 분석: Agent(에이전트)를 위해 정교화하고, 동시에 노후화되지 않는 메커니즘까지 구축한다.
harness: eval(평가)을 독립 레이어로 분리하여, 효과에 따라 도태시킨다.
조직·프로세스: 소유·유지보수·책임을 포함한 의사결정 구조의 재편

만약 단 하나의 척추를 꼽아야 한다면, 그것은 "지수적인 모델 진화 vs 로그적인 비즈니스 가치"입니다. harness도, 도메인 분석도, HOTL도, 조직 전개도, 모두 "왜 지금 그곳이 전장인가"를 이 일반식으로부터 도출할 수 있습니다. 그리고 로그의 천장 아래에서 분자를 늘리는 유일하고 현실적인 수단이 PDO이며, 그 PDO를 기능하게 하는 전제가 Agentic Workflow(에이전트적 워크플로우)의 확실성입니다. 모델을 기다리는 것이 아니라, 우리가 오늘 개선할 수 있는 주변을 어떻게 만들고, 어떻게 평가하며, 어디까지 확실하게 병렬화할 수 있는가——그것이 AIE2026에서 확인할 수 있었던 현재 위치라고 생각합니다.

Discussion