글로벌 해운 예외 업무를 운영하는 AI 에이전트의 설계 원칙

URL: https://www.youtube.com/watch?v=dQ-_i1tZiws 날짜: 2026-08-30 채널: latentspacepod

📌 핵심 질문 / 이 작업이 다루는 핵심 논점

==AI 에이전트의 성패는 에이전트 루프 자체보다, 복잡한 운영 지식을 실행 가능한 SOP로 바꾸고 예외를 안전하게 처리하며 수정 사항을 누적하는 주변 시스템에 달려 있다.==

• 글로벌 배송은 문서상 하나의 워크플로우지만 실제로는 여러 병렬 상태 머신의 오케스트레이션이다.
• 이미 자동화된 정상 경로보다, 시스템이 감당하도록 설계되지 않은 긴 꼬리(long tail)의 예외 업무가 더 비싸다.
• 전문가는 무엇을(what) 해야 하는지 소유하고 에이전트는 어떻게(how) 실행할지 담당하며, 둘 사이를 SOP 메모리·실행 런타임·피드백 캡처가 연결한다.
• 운영 품질은 더 큰 모델이나 막연한 인상이 아니라, 권한을 제한한 상태에서 실제 사례를 재생하고 실행 가능한 수정으로 바꾸는 반복 과정에서 나온다.

글로벌 해운처럼 국가별 규정과 레거시 시스템이 얽힌 환경에서 정확도는 사전에 그려 둔 단일 다이어그램에서 나오지 않는다. 작업을 표현 가능하게 만들고, 실행 범위를 제한하고, 모든 행동을 관찰 가능하게 만들고, 수정 비용을 낮추고, 개선이 누적되게 만드는 공학적 방법론이 에이전트 운영의 핵심 자산이다.

1. 정상 경로 뒤에 숨은 글로벌 배송의 복잡성

글로벌 배송의 실제 난제는 에이전트 데모에 등장하는 매끄러운 루프가 아니라, 여러 시스템이 동시에 일관성을 유지해야 하는 예외 처리다.

1.1. 현장 보고서가 겨냥하는 문제

1. 출발점은 실제 프로덕션 업무다

   1. 실무자 보고서: 실제 생산 현장(real production work)에서 얻은 실무자 보고서가 출발점이다.
   2. 일반적인 에이전트 소개의 생략: 또 하나의 루프 에이전트 소개나 전형적인 데모는 건너뛴다.
   3. 데모가 숨기는 어려운 부분: 대부분의 에이전트 데모가 생략하는 핵심은 엉킨 운영 지식을 에이전트가 안전하게 실행할 수 있는 형태로 바꾸는 일이다.

2. 해운 운영에 적용된 사례

   1. 현업 맥락: 문제는 발표자가 근무하는 회사에서 글로벌 배송 운영을 지원하며 얻은 실제 프로덕션 업무에서 나왔다.
   2. 현장성: 추상적인 AI 실험이나 노트북 수준의 데모가 아니라 생산 환경에 기반한 운영 문제다.

1.2. 하나의 워크플로우가 아닌 병렬 상태 머신

1. 서류와 현실의 차이

   1. 서류상 구조: 배송 프로세스는 보통 하나의 워크플로우처럼 보인다.
   2. 실제 구조: 실제 배송 하나하나는 여러 병렬 상태 머신(parallel state machines)을 오케스트레이션하는 일이다.
   3. 정상 경로의 한계: 정상 경로(happy path)가 효과적이라는 점에는 동의할 수 있지만, 어느 한 상태가 경로에서 벗어나는 순간 예외 업무가 발생한다.

2. 자동화의 긴 꼬리

   1. 자동화된 다수: 많은 기업에서 쉬운 다수의 작업은 이미 자동화되어 있다.
   2. 남은 문제: 남은 것은 긴 꼬리(long tail)와, 기존 시스템이 처리하도록 만들어진 것보다 더 많은 예외다.
   3. 비용의 집중: 자동화되지 않은 긴 꼬리 부분이 비싼 부분이다.

3. 샌프란시스코 AI 버블 바깥의 농담

   1. 가장 좋아하는 범주: 이 현장 예외 업무를 ‘가장 좋아하는 범주’라고 부르는 농담이 나온다.
   2. 특별한 명판: 해당 범주에는 특별한 명판(plate)이 붙어 있으며, AI 빌더의 꿈과 노트북만으로는 해결되지 않는 문제를 가리킨다.
   3. 현실의 위치: 이런 문제는 샌프란시스코의 AI 버블 바깥에서 발견된다.

2. 운영 지식을 에이전트가 실행할 수 있게 만드는 일

에이전트가 안전하게 행동하려면 조직의 경험을 화면 캡처가 아니라 실행 조건과 검증 절차를 포함한 프로세스로 표현해야 한다.

2.1. 여러 시스템의 일관성과 전문가 오케스트레이션

1. 동시 일관성이 필요한 처리

   1. 신호·업무 처리 과정: 처리 과정은 여러 시스템이 동시에 일관된 상태를 유지하는 데 의존한다.
   2. 한 단계의 실패: 어느 한 단계라도 완료되지 못하면 정상 경로가 깨진다.
   3. 불완전한 시스템의 조정: 정상 경로가 깨진 뒤에는 여러 불완전한 시스템에 걸쳐 전문가가 오케스트레이션해야 한다.

2. 변형 경로를 SOP에 담기

   1. 예외의 문서화: 정상 경로에서 파생되는 모든 변형 경로(variation pathway)를 표준 운영 절차(SOP, Standard Operating Procedure)에 담아야 한다.
   2. SOP의 성격: SOP는 산업 전반에서 공통적으로 사용되고 규제되는 운영 절차다.
   3. 해석의 목표: 전문가와 모델이 SOP를 같은 방식으로 읽고 해석할 수 있어야 한다.
   4. 가장 어려운 간극: 전문가의 운영 지식과 모델이 읽을 수 있는 실행 명세 사이의 간극이 핵심 난제다.

3. 안전한 의도 감지와 도구 호출

   1. 의도 감지: 안정적인 의도 감지(intent detection)는 에이전트가 어떤 작업을 수행하려는지 일관되게 파악하게 한다.
   2. 도구 호출의 안전성: 의도에 맞는 도구 호출(tool call)이 안전한지 보장해야 한다.
   3. 레거시 통합: 도구 호출은 기존 백엔드 시스템과 안전하게 통합되어야 한다.
   4. 전문가 평가: 실행 결과는 전문가가 평가해 실제 업무 의도와 맞는지 검증한다.

2.2. ‘부족 던전’과 스크린샷 SOP의 한계

1. 부족 던전(tribal dungeons)의 의미

   1. 발표자가 붙인 이름: 조직 안에 지식은 존재하지만 에이전트가 실행할 형태로 정리되지 않은 상태를 ‘부족 던전’이라고 부른다.
   2. 실행 불가능한 지식: 그 지식이 존재한다는 사실만으로는 프로세스를 안전하게 실행할 수 없다.
   3. 반복되는 위험: 실행 가능한 조건과 검증이 없으면 같은 프로세스를 안전하게 실행할 수 없다는 문제가 반복된다.

2. 레거시 SOP의 실제 모습

   1. 스크린샷의 연속: 조직은 기존 표준 운영 절차를 순서대로 정리한 수많은 스크린샷으로만 표현하는 경우가 있다.
   2. 스크린샷은 프로세스가 아님: 스크린샷은 사람이 무엇을 보고 어떤 버튼을 클릭했는지를 보여줄 뿐, 실행 가능한 프로세스 자체가 아니다.
   3. 사람 중심 설명: 기존 SOP는 사용자가 화면에서 무엇을 보고 클릭하는지 설명한다.

3. 에이전트 SOP에 필요한 실행 명세

   1. 환경 설정과 전제 조건: 에이전트 SOP에는 더 복잡한 설정(setup)과 사전 조건(preconditions)이 포함되어야 한다.
   2. 판단과 식별: 어떤 결정을 내려야 하는지, 어떤 식별자(identifiers)를 사용해야 하는지 명시해야 한다.
   3. 백엔드 상호작용: 호출해야 할 백엔드(back-end calls)와 호출 순서를 정의해야 한다.
   4. 검증과 복구: 실행 결과를 검증(validation)하고 실패 시 복구(recovery)하는 방법을 적어야 한다.
   5. 성공의 증거: 작업이 성공적으로 실행되었다고 판단할 수 있는 증거(evidence of successful execution)가 필요하다.

2.3. 전문가의 무엇과 에이전트의 어떻게

1. 역할 분담

   1. 전문가의 소유 영역: 전문가는 무엇을 해야 하는지(the what)를 소유한다.
   2. 에이전트의 소유 영역: 에이전트는 어떻게 해야 하는지(the how)를 담당한다.
   3. 예외의 역할: 예외(exception)는 단순한 실패 목록이 아니라 안전장치이자 가드레일(guardrail)이 된다.

2. 번역과 협상

   1. 가장 큰 노력: 전체 노력의 대부분은 전문가와 에이전트 사이의 번역(translation)과 협상(negotiation)에 들어간다.
   2. 상식의 정렬: 번역과 협상의 목표는 양쪽이 상식(common sense)에 부합하는 판단에 합의하게 만드는 것이다.
   3. 실행 가능한 공통 이해: 전문가의 암묵지와 에이전트의 실행 방식을 같은 운영 언어로 맞춰야 한다.

3. 에이전트를 둘러싼 운영 아키텍처

에이전트 루프 하나가 아니라, 지식을 저장하고 실행을 통제하고 피드백을 다시 반영하는 정제 루프가 시스템을 이룬다.

3.1. 세 가지 구성요소

1. SOP 메모리

   1. SOP 코퍼스: SOP 메모리는 정리된 SOP 코퍼스(SOP corpus)로 운영 지식을 보관한다.
   2. 프로세스 메모리: 코퍼스는 회사가 축적한 프로세스 메모리(process memory)이며, 국가별 운영 조건에 맞춰 계속 수정된다.

2. 실행 런타임

   1. 실행 영역: 실행 런타임(execution runtime)은 SOP에 정의된 판단과 호출을 실제 시스템에서 수행한다.
   2. 레거시 연동: 런타임은 여러 기존 백엔드와 상호작용하며 각 상태를 안전하게 이어 가야 한다.

3. 테마 피드백 캡처

   1. 실패와 결과의 수집: 테마 피드백 캡처(theme feedback capture)는 실행 사례와 실패 신호를 수집한다.
   2. 개선으로의 연결: 수집된 피드백은 전문가의 판단과 엔지니어의 수정 작업으로 연결된다.

4. 정제 루프의 우선성

   1. 에이전트 루프의 위치: 에이전트 루프(agent loop) 자체는 시스템 전체가 아니다.
   2. 진짜 시스템: 에이전트를 둘러싼 정제(refining) 루프가 시스템이며, 에이전트 루프보다 더 복잡한 부분이다.
   3. 운영의 핵심: 에이전트가 행동하는 한 번의 경로보다, 실패를 관찰하고 SOP와 도구를 고치는 반복 구조가 더 중요하다.

3.2. 국가별 변형과 코퍼스의 자산 가치

1. 영국 슬라이드의 즉석 수정

   1. 발표 중 정정: SAP 관련 슬라이드가 괜찮다고 했다가, 현재 화면이 영국(UK)용 슬라이드라며 이것이 올바른 화면이라고 즉석에서 정정한다.
   2. 작은 사례의 의미: 같은 프로세스도 국가에 따라 의미가 달라지고 다르게 기술될 수 있다는 점을 보여주는 사례다.

2. 국가별 차이의 누적

   1. 표현의 차이: 같은 업무 항목이 국가마다 다른 의미와 표현을 갖는다.
   2. 변형의 규모: 국가별 조건이 달라지면서 프로세스 변형이 많이 생긴다.
   3. 코퍼스의 역할: 코퍼스는 국가별 변형을 보존하고 에이전트가 해당 국가의 조건에 맞게 실행하도록 한다.

3. 회사 자산으로서의 프로세스 메모리

   1. 자산성: 국가별 조건에 맞춰 수정·정렬된 코퍼스는 회사의 자산이다.
   2. 런타임보다 큰 규모: 회사의 프로세스 메모리는 실행 런타임보다 훨씬 크다.
   3. 비율: 프로세스 메모리와 런타임의 규모 비율은 약 20 대 1(20:1)이다.

3.3. 프로덕션 규모와 레거시 병목

1. 동시 운영 규모

   1. 동시성: 시스템은 여러 작업을 동시에 운영하는 동시 운영 체계(concurrently operating system)다.
   2. 인스턴스 수: 현재 프로덕션에서 200개가 넘는 인스턴스를 실행한다.
   3. 트래픽 급증: 트래픽이 급증하면 지연 시간이 몇 분에서 최대 10분까지 변동한다.

2. 레거시 시스템의 속도 한계

   1. 다수의 의존성: 시스템은 여러 레거시 시스템에 의존한다.
   2. 에이전트 루프와의 비교: 레거시 시스템은 에이전트 루프 자체보다 빠르게 응답할 수 없다.
   3. 지연의 주된 원인: 지연 시간 변동의 주요 원인은 에이전트 모델의 추론만이 아니라 연결된 레거시 시스템의 처리 속도다.

4. 실패를 실행 가능한 개선으로 바꾸는 피드백 루프

전문가의 시간이 병목인 환경에서는 실패를 모아 분류하고 공통 증거로 검토한 뒤, 실제 코드나 실행 명세의 수정으로 바꾸는 구조가 필요하다.

4.1. 전문가 시간과 테마 벤치의 트리아지

1. 전문가 시간의 병목

   1. 사람의 한계: 전문가가 모든 실패 사례를 직접 검토하는 데 필요한 시간이 병목이다.
   2. 우선순위 문제: 수많은 실패를 같은 깊이로 검토하면 가장 유익한 개선에 시간을 집중할 수 없다.

2. 테마 벤치(theme bench)의 역할

   1. 자동 트리아지: 테마 벤치는 실패 사례의 트리아지(triage)를 대신 수행한다.
   2. 클러스터링: 흩어진 실패를 유형별로 묶어(clusters) 반복되는 패턴을 찾는다.
   3. 행동 가능한 결과: 단순히 실패를 보여주는 데 그치지 않고, 사람이 조치할 수 있는 형태로 결과를 돌려준다.

3. 공통 증거로서의 트레이스

   1. 동일 사례 검토: 트레이스(trace)는 전문가와 엔지니어가 같은 실행 사례를 검토하게 하는 공통 증거다.
   2. 원인 합의: 양쪽은 트레이스를 근거로 무엇이 일어났는지와 발생 원인에 합의할 수 있다.
   3. 주관성 축소: 각자의 인상이나 추측이 아니라 같은 실행 기록을 보며 논의한다.

4.2. 의견과 프로덕션 수정의 경계

1. 실행 가능한 변경만 유효하다

   1. 수정의 기준: 수정(correction)은 실행 가능한 변경(executable change)이 되었을 때만 수정으로 인정된다.
   2. 생산 반영: 실행 명세, 코드, 분류기, 도구 호출 또는 가드레일 중 실제 동작을 바꿔야 한다.
   3. 경계선: 실행 가능한 변경으로 이어지지 않는 말은 의견(opinion)이고, 실행 가능한 변경이 된 결과가 프로덕션 수정(production fix)이다.

2. 품질의 출처

   1. 막연한 분위기가 아님: 품질은 ‘왠지 좋아 보인다’는 분위기(vibes)에서 나오지 않는다.
   2. 모델 크기만의 문제가 아님: 더 큰 모델을 선택하는 것만으로 품질이 보장되지 않는다.
   3. 실제 사례 재생: 실제 실패 사례를 재생(replay)하면서 동작이 개선됐는지 확인해야 한다.
   4. 권한 비활성화: 재생할 때는 프로덕션 시스템을 보호하기 위해 쓰기 등 위험한 권한을 비활성화한 상태로 실행한다.
   5. 행동 개선 확인: 수정 전후의 행동을 비교해 실제 개선 여부를 확인한다.

4.3. 파이프 코딩 이후에 시작되는 진짜 작업

1. 노력 비율의 변화

   1. 인지적 비율: 프로젝트의 각 활동에는 서로 다른 인지적 비율(cognitive proportion), 즉 노력 비율(effort ratio)이 있다.
   2. 파이프 코딩의 종료점: 일반적인 파이프 코딩(pipe coding)은 일정 지점에서 끝난다.
   3. 사양 중심 개발의 종료점: 사양 중심 개발(spec-driven development)도 이 규모에서는 더 이상 정확도를 크게 높이지 못하는 지점에서 끝난다.

2. 운영 품질 작업의 시작

   1. 진짜 일의 시작: 파이프 코딩과 사양 중심 개발이 도달할 수 있는 한계 뒤에서 진짜 일이 시작된다.
   2. 특이한 비법이 아님: 이 작업은 신비한 비법이나 완전히 새로운 이론이 아니다.
   3. 대규모 공학 상식: 지난 30년 동안 소프트웨어 개발에서 발전한 공학적 상식을 대규모로 적용하는 일이다.
   4. AI 에이전트의 기본 소양: 모든 AI 에이전트와 AI 코딩 에이전트가 이런 소프트웨어 공학 용어와 실천을 알아야 신뢰할 수 있고 정확한 프로덕션 시스템 개발을 도울 수 있다.

5. 작은 수정의 누적과 관찰 가능한 운영

정확도는 처음부터 완성된 설계로 얻는 결과가 아니라, 실제 운영에서 발견한 문제를 한 번에 하나씩 수정하며 축적한 결과다.

5.1. 다이어그램이 아닌 수정으로 얻은 정확도

1. 사전 설계의 한계

   1. 단일 다이어그램의 환상: 현재의 규모와 정확도가 처음부터 하나의 다이어그램으로 설계된 것은 아니다.
   2. 점진적 형성: 시스템을 운영하며 작은 수정들을 계속 반영한 결과로 지금의 구조가 만들어졌다.

2. 9개월간의 수정

   1. 수정 건수: 시스템을 개발한 지난 9개월 동안 10만 건이 넘는 수정(corrections)을 처리했다.
   2. 정확도의 출처: 정확도는 한 번의 거대한 설계가 아니라 작은 수정 하나하나에서 얻어졌다.
   3. 운영 시스템의 성격: 수정이 계속 누적되는 살아 있는 운영 시스템이 정적인 설계 문서보다 중요하다.

5.2. 히트맵으로 수천 개의 트레이스를 우선순위화하기

1. 히트맵의 기능

   1. 대량 사례의 정리: 히트맵(heat map)은 수천 건의 트레이스를 우선순위로 바꾼다.
   2. 공통 문제 시야: 전문가와 엔지니어가 같은 문제를 바라보게 한다.
   3. 유익한 업무의 선택: 가장 큰 이익을 주는 업무부터 우선순위를 정하게 한다.

2. 셀과 시나리오 그룹

   1. 셀의 의미: 히트맵의 각 셀은 추적 중인 시나리오 그룹이다.
   2. 색의 신호: 특정 시나리오 그룹에서 실패나 문제가 누적되면 블록이 붉게 변한다.
   3. 팀 투입 규모: 블록 하나를 빨간색으로 바꾸는 수준의 문제를 해결하려면 엔지니어 전체 팀과 AI 에이전트 팀이 약 1~2개월 동안 투입되어야 한다.

3. 실패의 해석

   1. 조사의 출발점: 에이전트 실패는 조사의 끝이 아니라 조사가 시작되는 지점이다.
   2. 수정과의 연결: 모든 실패는 특정한 수정 사항에 매핑된다.
   3. 조사 결과: 실패를 유형화하고 원인을 찾은 뒤, 실행 가능한 변경 하나로 연결해야 한다.

6. 발견의 자유와 프로덕션의 케이지

에이전트가 새로운 실패를 발견할 때는 충분한 자유가 필요하지만, 프로덕션에서 행동할 때는 위험한 경로를 사전에 차단하는 제한이 필요하다.

6.1. 발견 환경과 실행 환경의 분리

1. 서로 다른 요구

   1. 발견에는 자유: 새로운 문제와 예외를 찾는 발견(discovery) 단계에는 에이전트의 자유로운 환경이 필요하다.
   2. 프로덕션에는 케이지: 실제 운영(production) 단계에는 제한된 환경, 즉 케이지(cage)가 필요하다.
   3. 같은 권한을 주지 않음: 탐색을 위해 필요한 자유와 실제 고객·시스템에 영향을 주는 실행 권한을 분리한다.

2. 하네스의 목적

   1. 공간 확장이 아님: 하네스(harness)는 에이전트에게 더 많은 행동 공간을 주기 위해 존재하지 않는다.
   2. 어리석은 실수의 차단: 하네스는 어리석은 실수(dumb mistakes)가 일어나는 것을 불가능하게 만들기 위해 존재한다.
   3. 중요 경로 보호: 에이전트의 탐색이 중요한 운영 경로의 위험한 행동으로 이어지지 않게 한다.

6.2. 오류 유형별 평가와 게이트

1. 하네스는 단순한 경비원이 아니다

   1. 규모에 맞는 주의: 이 규모의 시스템에서 하네스를 단순한 경비원(guard)이나 감시자로 이해해서는 안 된다.
   2. 오류 유형에 따른 처리: 무엇이 잘못됐는지에 따라 서로 다른 평가와 게이트를 적용해야 한다.

2. 세 가지 오류 예시

   1. 워크플로우 오류: 워크플로우가 잘못된 경우 분류기 평가(classifier eval)로 보낸다.
   2. ‘wrong right’와 right gate: 자막에 ‘wrong right’로 들리는 경우는 right gate를 통과시키는 예시로 제시된다. 정확한 화면 문구가 불분명하더라도, 행동 유형에 맞는 별도 게이트를 둔다는 취지는 분명하다.
   3. 잘못된 가정: 잘못된 가정(wrong assumption)에 기반한 결과는 확정된 사실이 아니라 단순한 견해(mere view)로 취급한다.

3. 예방 조치와 사람의 통제

   1. 위험 경로 제거: 예방 조치(preventive measure)는 중요한 경로에서 안전하지 않은 경로를 제거한다.
   2. 검토와 승인 유지: 검토(review)와 승인(approval)은 계속 사람의 루프 안에 남는다.
   3. 엔지니어링의 핵심: 엔지니어링의 초점은 안전한 핸드오프(safe handoff)와 신뢰할 수 있는 실행 흔적(trail)을 만드는 데 있다.

7. 다섯 가지 운영 설계 원칙

프로덕션 결과를 만든 주체는 에이전트 하나가 아니라, 에이전트 주변에 구축한 방법론이다.

7.1. 방법론이 만든 실제 결과

1. 에이전트보다 방법론

   1. 성과의 원인: 실제 결과는 시스템 안에 들어간 특정 에이전트 자체에서 나온 것이 아니다.
   2. 주변 구조의 힘: 결과를 만든 것은 에이전트 주변에 구축한 방법론(methodology)이다.

2. 운영 시스템으로의 전환

   1. 행동의 명세화: 사람의 지식과 예외를 표현 가능한 실행 단위로 만든다.
   2. 실행의 통제: 에이전트가 할 수 있는 행동과 실행 시간을 제한한다.
   3. 실패의 관찰: 모든 행동을 추적하고 같은 실행 사례를 재검토할 수 있게 한다.
   4. 수정의 누적: 수정 사항을 다음 실행과 다른 국가·시나리오에 재사용한다.

7.2. 다섯 가지 움직임

1. 작업을 표현 가능하게 만들기(make work representable)

   1. 암묵지의 외부화: 사람 머릿속의 운영 지식을 SOP, 조건, 식별자, 호출, 검증으로 표현한다.
   2. 실행 언어로 변환: 사람이 이해하는 업무 설명을 에이전트가 실행할 수 있는 구조로 바꾼다.

2. 실행을 경계 안에 두기(make execution bounded)

   1. 권한과 범위 제한: 에이전트의 실행 범위와 위험한 권한을 제한한다.
   2. 실행 시간 제한: 실행 가능한 작업의 시간을 제한해 무한 대기와 통제되지 않은 연쇄 작동을 막는다.

3. 모든 에이전트의 행동을 관찰 가능하게 만들기(make behavior observable for every agent)

   1. 트레이스 확보: 모든 에이전트 행동을 추적해 전문가와 엔지니어가 같은 증거를 보게 한다.
   2. 개선 측정: 실제 사례 재생을 통해 수정 전후의 행동이 좋아졌는지 확인한다.

4. 수정을 저렴하게 만들기(make correction cheap)

   1. 작은 변경의 반복: 실패를 한 번에 하나의 구체적인 실행 변경으로 연결한다.
   2. 우선순위화: 히트맵과 트리아지로 가장 가치가 큰 수정부터 선택한다.

5. 개선이 누적되게 만들기(make improvement compound)

   1. 재사용: 성공한 실행 시나리오와 수정 사항을 다른 에이전트가 사용할 수 있게 한다.
   2. 점진적 품질 향상: 시스템 품질을 점진적이고 체계적으로 높인다.

8. AI 네이티브 운영과 적응형 아키텍처

AI 네이티브 운영은 워크플로우 안에 에이전트를 배치하는 데서 끝나지 않고, 성공한 행동을 다시 코드와 복합 도구로 편입하는 학습 시스템으로 확장된다.

8.1. 워크플로우 에이전트 이상의 운영 시스템

1. 작동하는 방법을 학습하는 시스템

   1. 결과로부터 학습: AI 네이티브 운영은 무엇이 작동하는지에서 학습한다.
   2. 코드로의 환류: 학습한 방법을 코드에 다시 접어 넣어(fold back) 새로운 복합 도구(composite tool)를 만든다.
   3. 주변 환경에 적응: 복합 도구는 애플리케이션과 그 주변의 사람들에 맞춰 적응한다.

2. 모델과 아키텍처의 역할

   1. 모델의 역할: 최고의 AI 모델은 지능적인 방향(orienting intelligence)을 제공한다.
   2. 최종 자산: 회사가 구축한 적응형 아키텍처(adaptive architecture)가 최종적으로 남는 자산이다.
   3. 운영 자산의 본질: 특정 모델 버전보다 반복 가능한 실행, 검증 방식, 복합 도구와 피드백 루프가 오래 남는 가치를 만든다.

8.2. 성공 시나리오를 재사용 가능한 도구로 집계하기

1. 반복 가능한 실행의 집계

   1. 단계의 수집: 반복 가능한 단계의 연속(repeatable sequence of steps)을 집계한다.
   2. 성공 사례의 수집: 성공한 시나리오(successful scenarios)를 함께 모은다.
   3. 패턴의 발견: 여러 국가와 사례에서 반복되는 실행 패턴을 식별한다.

2. 더 큰 도구로의 결합

   1. 복합화: 집계한 단계와 성공 사례를 더 큰 도구로 합친다.
   2. 재사용 가능한 코드 조각: 검증된 시나리오를 다른 에이전트가 재사용할 수 있는 코드 스니펫으로 결합한다.
   3. 다음 에이전트의 출발점: 새 에이전트가 매번 처음부터 동일한 운영 지식을 발견하지 않도록 한다.

3. 국가 확장

   1. 한 국가의 한계 극복: 완성된 도구를 한 국가에만 적용하지 않는다.
   2. 수백 국가 동시 배포: 검증과 재사용이 갖춰지면 수백 개 국가에 한 번에 롤아웃(roll out)할 수 있다.
   3. 코퍼스와 런타임의 결합: 국가별 코퍼스 변형과 공통 런타임을 결합해 확장성을 확보한다.

9. MCP를 선택하지 않을 수 있는 이유

도구에 감정적으로 애착을 갖는 AI 빌더라도, 모든 환경에서 MCP가 최선이라는 가정을 버리고 품질 통제에 맞는 도구 연결 방식을 선택해야 한다.

9.1. 발표를 마무리하며 덧붙인 선택

1. 짧은 질의응답 안내

   1. 발표 종료: 이야기를 마치며 질문 시간이 많지 않다는 안내가 나온다.
   2. 사후 대화: 발표가 끝난 뒤 곁에 있을 테니 질문이 있으면 물어보라고 안내한다.

2. AI 빌더를 향한 마지막 농담

   1. 도구에 대한 애착: AI 빌더가 도구에 감정적으로 애착을 갖고 있다면 특히 이 판단을 기억해야 한다고 말한다.
   2. MCP 미사용: 조직은 MCPs(Model Context Protocol servers/tools)를 사용하지 않는다.
   3. 항상 최선은 아님: MCP가 일반적으로 나쁜 기술이라는 뜻이 아니라, 해당 조직의 목적에는 언제나 최선의 선택이 아니기 때문에 사용하지 않는다는 설명이다.

9.2. 함수 호출 기반 도구 조정

1. 비대해지는 시스템

   1. 시스템의 비대화: 시스템은 일반적으로 매우 비대해진다.
   2. 응답의 복잡성: 에이전트가 받는 도구 응답도 커지고 복잡해진다.
   3. 필요한 정제: 응답을 추출·정제(distill)해야 에이전트가 필요한 정보만 사용할 수 있다.

2. 함수 호출로 도구를 조율하기

   1. 도구 튜닝: 도구를 함수 호출(function calling)을 통해 에이전트의 목적에 맞게 조정한다.
   2. 품질 통제: 이 방식으로 소프트웨어의 품질을 통제한다.
   3. 업무 처리 검증: 할당된 작업을 에이전트가 올바르게 처리하는지 확인한다.

3. 선택의 기준

   1. 유행보다 운영 적합성: 널리 알려진 프로토콜을 쓰는지보다 시스템 응답의 크기, 통제 가능성, 검증 가능성이 중요하다.
   2. 도구 인터페이스의 설계: 에이전트가 실제 업무를 안정적으로 수행하도록 필요한 도구만 노출하고 응답을 운영 목적에 맞게 정제한다.

주요 발언 모음

“The hard part most agent demos skip is turning messy operational knowledge into something an agent can execute safely.”

“Every shipment is an orchestration of many parallel state machines.”

“That tail is the expensive part.”

“Screenshots are not a process.”

“Experts own the what, agents own the how. And exception becomes a guardrail.”

“The agent loop is not the system. The refining loop around the agent is the system.”

“A correction only counts when it becomes an executable change.”

“The agent failed is where the investigation starts, not where it ends.”

“Discovery needs agent freedom and production needs a cage.”

“The harness isn’t there to give the agent more room. It’s there to make the dumb mistakes impossible.”

“Make work representable. Make execution bounded. Make behavior observable for every agent. Make correction cheap. And make improvement compound.”

“The real outcome wasn’t the agent in the system. It was the methodology we built around it.”

“AI-native operation is more than agents in workflow.”

“We’re not using MCPs because for us it’s not always the best choice.”

핵심 데이터 & 수치

• 20:1: 국가별 조건에 맞춰 확장되는 프로세스 코퍼스·메모리의 규모가 실행 런타임보다 약 20배 크다.
• 200개 이상: 현재 프로덕션에서 동시에 실행하는 인스턴스 규모다.
• 수 분~최대 10분: 트래픽 급증 시 관찰되는 지연 시간 변동 폭이다.
• 지난 9개월: 시스템 개발 과정에서 수정 사항을 누적한 기간이다.
• 10만 건 이상: 지난 9개월 동안 처리한 수정(corrections) 수다.
• 1~2개월: 엔지니어 전체 팀과 AI 에이전트 팀이 히트맵의 시나리오 블록 하나를 개선하는 데 투입되는 전형적인 기간이다.
• 30년: AI 에이전트와 AI 코딩 에이전트가 활용해야 할 소프트웨어 공학 용어와 실천이 발전해 온 대략적인 기간이다.
• 수백 개 국가: 검증된 복합 도구와 국가별 프로세스 코퍼스를 활용해 한 번에 롤아웃할 수 있는 확장 목표다.

결론 및 시사점

1. 글로벌 해운의 업무 단위는 하나의 선형 워크플로우가 아니라 여러 병렬 상태 머신을 조정하는 예외 처리 시스템이다.
2. 정상 경로의 자동화율이 높아질수록 비용과 난이도는 긴 꼬리 예외로 이동한다.
3. 사람용 SOP의 스크린샷을 에이전트용 SOP로 간주하지 말고, 설정·사전 조건·판단·식별자·백엔드 호출·검증·복구·성공 증거까지 명세해야 한다.
4. 전문가는 업무의 무엇을, 에이전트는 실행의 어떻게를 맡기고 예외를 가드레일로 바꿔야 한다.
5. SOP 코퍼스, 실행 런타임, 피드백 캡처를 분리하고 에이전트 주변의 정제 루프를 시스템의 중심에 둬야 한다.
6. 국가별 프로세스 메모리는 런타임보다 훨씬 큰 회사 자산이며, 20:1 규모의 지식·변형을 관리해야 한다.
7. 200개가 넘는 인스턴스와 최대 10분의 지연을 감당하려면 레거시 시스템 의존성과 전문가 시간 병목을 함께 다뤄야 한다.
8. 트레이스는 전문가와 엔지니어가 같은 사례를 보는 공통 증거이고, 수정은 실행 가능한 변경으로 이어질 때만 유효하다.
9. 품질은 더 큰 모델이나 분위기가 아니라, 권한을 제한한 실제 사례 재생과 행동 개선 확인에서 나온다.
10. 발견 단계의 자유와 프로덕션 단계의 케이지를 분리하고, 하네스로 어리석은 실수를 불가능하게 해야 한다.
11. 에이전트 실패는 조사의 끝이 아니라 특정 수정으로 연결되는 시작점이다.
12. 작업 표현 가능성, 실행 경계, 행동 관찰 가능성, 저렴한 수정, 누적 개선이라는 다섯 가지 원칙이 대규모 운영의 청사진이다.
13. 지난 9개월의 10만 건 이상 수정은 정확도가 사전 설계가 아니라 작은 개선의 누적임을 보여준다.
14. AI 네이티브 운영은 성공한 단계와 시나리오를 복합 도구와 재사용 가능한 코드로 되돌려 넣는 적응형 시스템이다.
15. MCP를 쓰는지 여부보다 응답 정제, 함수 호출 기반 도구 조정, 소프트웨어 품질 통제, 할당 업무의 정확한 처리 여부가 중요하다.