
런타임은 살 수 있지만, 수락 조건은 살 수 없다 —— AI 개발 기반은 3층 분리로 수렴한다
요약
AI 에이전트 산업이 단순 모델 래퍼를 넘어, 구조화된 실행 환경을 제공하는 '런타임(Runtime)' 플랫폼으로 진화하고 있음을 분석합니다. 실행 환경과 도구는 상품화될 수 있지만, 도메인 특유의 수락 조건과 그에 대한 최종 책임은 여전히 인간의 영역으로 남는다는 점을 강조합니다.
핵심 포인트
- AI 에이전트 기반이 개별 배선 단계에서 PLC와 같은 표준화된 런타임 시대로 이행 중
- 상태 관리, 샌드박스, 오케스트레이션 등 실행 인프라는 상품화 가능
- 도메인 고유의 수락 조건 내용과 그 충분성에 대한 입증은 구매 불가능한 영역
- 기능 블록은 실행 원리(결정론적/확률적)와 검증 상태라는 두 축의 타입이 필요
그래프 다음은 런타임이다 —— 그리고 그것은 이미 시작되었다
⬜ 예측(단, 징후는 관측됨)
제4고의 말미에서, AI 에이전트 기반은 "모델을 호출하기 위한 얇은 래퍼(Wrapper)가 아니라, 불확실한 실행 주체를 안전하게 장시간 운전하기 위한 런타임(Runtime)으로 변화해 갈 것이다"라고 썼다. 이 문장을 제품 측면에서 다시 말하면 다음과 같다:
그래프 다음에 오는 것은, 구조화된 실행 환경을 제공하고 기능 블록을 목적에 따라 조합할 수 있는, 더 큰 틀의 플랫폼이다.
임베디드 제어를 다루는 사람들에게 이 전개는 기시감이 있다. 제어 업계는 릴레이 판을 안건마다 개별적으로 구성하던 시대에서, PLC라는 런타임과 IEC 61131-3의 표준화된 언어·부품의 시대로 이행했다. AI 에이전트 업계는 지금, 래더 다이어그램(Ladder Diagram)을 수작업으로 짜던 단계에서 PLC로 이행하는 국면에 보인다 —— 이는 엄밀한 역사의 재연을 주장하는 것이 아니라, "개별 배선에서 공통 런타임과 구성 가능한 부품으로"라는 방향에 대한 비유이다.
징후는 이미 존재한다. durable execution 기반, 상태 전이 그래프의 오케스트레이션(Orchestration) 프레임워크, 그리고 Anthropic의 Managed Agents와 같이, session(추가 전용 로그) · harness · sandbox를 독립된 인터페이스로 분리한 매니지드 실행 환경[1]. 모델 고유의 harness보다 더 오래 살아남는 런타임 추상화를 상품화하려는 움직임은 이미 시작되었다.
문제는 이 상품화가 어디까지 도달할 것인가이다.
무엇을 살 수 있고, 무엇을 살 수 없는가 —— 경계의 정확한 위치
📐 도출(시리즈 B·C의 귀결)
먼저 "살 수 있는" 범위를 솔직하게 넓게 잡는다. 다음은 모두 상품화할 수 있으며, 실제로 그렇게 될 것이다.
- 이벤트의 추가 로그와 재개 메커니즘, 상태 관리자, 오케스트레이션
- 샌드박스(Sandbox), 권한 분리, scope 대조, 예산 상한 실행계
- 동결 측정기의 호스팅, 드리프트(Drift) 통계 계산 기반
수락 조건을 기술하는 DSL, policy-as-code 실행계, 보안 규칙 집합, 업계별 평가 템플릿 - 그리고,
확률적인 의미 평가기 그 자체조차 상품이 된다.
마지막 두 가지가 핵심이다. "수락 조건은 살 수 없다"라고 말할 때, 그릇까지 살 수 없다는 뜻이 아니다. 살 수 없는 것은 다음과 같다.
자신의 안건에 있어서의 올바른 수락 조건의 내용(무엇을 "계약의 올바른 실현"으로 볼 것인가는 도메인 고유의 계약이다) -
그 조건이 요구사항을 충분히 커버하고 있다는 입증(의미 평가기는 살 수 있어도, 그것이 자신의 계약에 대해 충분하다는 입증은 살 수 없다) -
조건 밖에 남는 사각지대 목록의 유지(측정기를 추가할 때마다 다시 써야 하는 규율 —— C 선언1 —— 은 구매할 수 있는 종류의 것이 아니다) 최종적인 수락 책임
한 문장으로 압축한다.
수락 조건의 그릇과 실행기는 살 수 있다. 수락 조건의 내용, 그 충분성의 입증, 그리고 수락 책임은 살 수 없다.
제목의 "런타임은 살 수 있지만, 수락 조건은 살 수 없다"는 이러한 의미에서의 압축 표현이다.
그리고 이 선긋기로부터 플랫폼의 성실함을 판별하는 기준도 하나 나온다. 전전고 B의 검증 상태 타입을 힌트로, 기능 블록에는 두 축의 타입이 필요하다. 하나는 블록의 실행 원리 —— 결정론적으로 조작을 허용/거부하는 deterministic-enforcer,
결정론적인 양을 측정하는 deterministic-observer,
확률적으로 의미 평가·진단·제안을 수행하는 probabilistic-advisor.
또 하나는 그 출력의 검증 상태 —— claimed / mechanically-checked / semantically-sampled / human-approved (전전고 B의 타입 그 자체).
전자는 블록의 정적인 성질이며, 후자는 개별 출력이 현재 어디까지 검증되었는가 하는 동적인 상태이므로, 이를 섞어서는 안 된다. 결정론적 블록이라도 설정이 잘못되어 있으면 출력은 틀릴 수 있고, 확률적 블록의 출력이라도 부수적인 수량·scope·형식은 후단의 기계 검사에서 mechanically-checked로 승격될 수 있다 —— "확률적 블록이니까 항상 claimed"가 아니라, 확률적 블록이 자기 신고한 의미 판단이 claimed인 것이다 (B고의 다축 구조 보존). 성실한 플랫폼은 이 두 축을 별도로 명시한다. 구분을 모호하게 하여 "AI 블록도 다른 블록과 마찬가지로 배선할 수 있습니다"라고 파는 플랫폼이 가장 위험하다.
살 수 있는지 여부와, 어디에 둘 수 있는지는 별개의 축이다
📐 도출
초안 단계에서 나는 "살 수 있는 주변부는 안전계로, 살 수 없는 중심부는 주제어계로——두 경계는 하나의 선이다"라고 썼다. 이것은 오류였다. 정정한다.
상품화할 수 있는지 여부를 결정하는 것은 범용화(Generalization)·표준화(Standardization)·재사용(Reuse)·인터페이스 정의(Interface Definition)가 가능한가이다. 안전계(Safety System)에 배치할 수 있는지 여부를 결정하는 것은 독립적으로 구현할 수 있고, 고장 시 안전 측 동작(Fail-safe operation)을 정의할 수 있으며, 보증 범위를 결정론적(Deterministic)으로 입증할 수 있는가이다. 이 둘은 별개의 축이다.
반례는 금방 찾을 수 있다. 이벤트 로그와 재개 메커니즘은 살 수 있지만, 그것은 주 실행계(Main Execution System)의 내구성과 감사성(Auditability)을 뒷받침하는 런타임(Runtime) 기능이지, 최종 차단을 담당하는 안전계가 아니다. 드리프트(Drift) 모니터링도 살 수 있지만, 그것은 이상을 **추정하는 진단(Diagnosis)**이지, 피해를 **막는 보호(Protection)**가 아니다. 반대로, 도메인 특화된 수락 조건(Acceptance Condition)이라 하더라도, "운영 환경으로의 쓰기 금지", "변경 파일 수는 10개 이하"와 같이 결정론화할 수 있는 부분은 안전측에 배치할 수 있다.
올바른 원칙은 다음과 같다.
살 수 있는 주변부 중, 독립적으로 구현할 수 있고, 고장 시 안전 측 동작을 정의할 수 있으며, 보증 범위를 결정론적으로 입증할 수 있는 부분만이 보호층(Protection Layer)으로 들어간다. 그 외의 살 수 있는 기능은 실행층(Execution Layer) 또는 진단층(Diagnostic Layer)에 속한다.
이 정정을 반영하면, 계(System)의 구조는 2층이 아니라 3층이 된다. 다만 배치에 주의가 필요하다. 3층을 위에서 아래로 직렬로 쌓아서는 안 된다. 그것은 "진단층이 이상을 감지하고, 그 결과에 따라 보호층이 차단한다"는 구조이며, 확률적인 진단기가 보호의 직렬 요소, 즉 새로운 공통 고장점(Common Cause Failure Point)이 되어버린다. 올바른 배치는 다음과 같다.
굵은 실선은 차단 경로이고, 점선은 관측과 경보이다. 진단층은 점선으로만 계에 연결되어 있다——이 비대칭이야말로 직렬화 금지를 도식화한 것이다.
보호층은 실행층과 외부 환경·영속적 결과물(Persistent Artifacts) 사이에 위치하며, 모든 조작 요청이 그곳을 통과한다. 진단층은 실행층(과 보호층의 기록)을 옆에서 관측하여 경보와 보조 증거를 반환하지만, 차단 경로 상에는 있지 않다. 3층의 관계를 한 문장으로 말하면 다음과 같다.
진단층은 가관측성(Observability)을 높인다. 보호층은 조작 경계(Operational Boundary)를 직접 강제한다. 그리고 보호층은 진단층이 침묵하더라도 기능한다.
의미 평가 LLM이 "문제 없음"이라고 오판하더라도, 운영 환경에 대한 쓰기 권한, 변경 가능한 스코프(Scope), 비용 상한, 비가역적 조작 금지는 진단 결과와 무관하게 보호층이 직접 차단한다. IEC 61511이 보호층 간의 의존 관계와 공통 원인 분석을 요구하는 것은 바로 이러한 직렬화를 방지하기 위함이다.
이 3분할은 전전고 B에서 구분했던 **계측(Measurement)과 방호(Protection)**를 그대로 보존하고 있다. 2층(주제어/안전)으로 몰아넣으면 드리프트 모니터링(이상의 추정)과 예산 하드 리미트(피해의 차단)가 동일한 "안전계"로 흡수되어 버린다. 시리즈가 일관되게 나누어 왔던 두 가지를 최종고에서 재결합할 뻔했다. 진단·보증 지원층은 확률적이어도 되는 대신, 최종 차단의 근거가 될 수 없는 층으로서 독립적으로 세울 필요가 있다.
FA 분리와의 대응 —— 우선순위의 차이로서의 두 계
📐 도출(FA의 규율로부터의 사상)
이 3층은 프로세스 제어가 반세기 동안 도달한 보호층(Protection Layers) 구조에 대응한다. 주제어계(BPCS)가 통상 운전을 담당하고, 경보와 진단이 그 이탈을 알리며, 안전 계장계(SIS)가 마지막 차단을 담당한다——동심원상으로 겹쳐 있는 독립된 층이다.
여기서 비유의 정밀도를 하나 높여두겠다. 초안에서는 "주제어계와 안전계는 목적 함수가 반대 방향을 향하고 있다"라고 썼지만, 이는 너무 강한 표현이다. BPCS도 위험 상태를 피하면서 운전한다. 정확하게는 다음과 같다.
두 계는 최적화의 우선순위가 다르다. 주제어계는 제약 조건 안에서 기능·생산성·가용성을 유지한다. 안전계는 그것들을 희생해서라도 안전 상태를 달성·유지한다. 평상시에는 양쪽 모두 같은 방향을 향하지만, 이상 시에는 목적 함수가 반대 방향을 향한다.
독립성 요구 사항도 규격에 충실하게 적어둔다. IEC 61511이 요구하는 것은 SIS의 안전 무결성(Safety Integrity)을 해치지 않을 정도의 분리와 독립성, 그리고 BPCS와의 의존 관계·공통 원인 고장(Common Cause Failure)의 분석이다. 필요한 독립도에 따라 전원, 센서, 로직 솔버(Logic Solver), 통신 경로, 구현 원리의 분리나 다양화가 선택된다——항상 모든 것을 별개로 하라는 일률적인 요구가 아니다. AI 기반에 대한 함의도 같은 형태가 된다: 실행층과 보호층(그리고 진단층) 사이에서 무엇을 공유하고 있으며, 그 공유가 어떤 공통 원인 고장을 일으키는지를 분석하고, 필요한 독립도를 선택하는 것. 동일 모델 계열의 공유는 이 분석에서 가장 먼저 걸러내야 할 공통 요인이다(C 선언 2의 맹점 상관관계).
대응표를 3층으로 다시 작성한다.
| FA/프로세스 안전 요소 | AI 개발 기반에서의 대응 |
|---|---|
| BPCS(주제어계) | 실행·주제어층: AI worker, 오케스트레이션 (Orchestration), 상태 관리, 재개 메커니즘 |
| ... | 미정의(후술) |
안전 상태(Safe State)의 정의에 주의해야 한다. 초안에서는 "정지, 롤백 (Rollback), 인간으로의 이양"이라고 썼지만, 이 역시 정밀도가 부족했다. 롤백할 수 없는 외부 조작은 존재하므로, 롤백은 롤백이 가능한 경우의 복구 조작이지 안전 상태의 요건이 아니다. 인간으로의 이양은 상태가 아니라, **안전 상태로부터의 해제 권한을 인간에게 넘기는 전이 (Transition)**이다. 안전 상태 그 자체는 "더 이상 악화되지 않음이 보장되는 상태"——영속화의 정지, 권한의 축소, 불가역 조작의 금지——로 정의한다. IEC 61511이 SIS의 역할을 안전 상태의 "달성 또는 유지"로 두는 것은, 정지시킨 후에 무엇을 유지할 것인가까지 정의하라는 의미다.
최종 차단 경로는 보장 가능한 복잡성 내부에 닫혀야 한다
📐 도출
기능 안전(Functional Safety)의 규율이 AI 업계에 대한 경고로서 가장 날카로워지는 지점이 여기다. 초안에서는 "안전계는 피감시계보다 단순해야 한다"라고 썼지만, 이 역시 규격상의 절대 조건처럼 읽힐 수 있는 과한 표현이었다. 실제 SIS에는 단순한 로직부터 복잡한 안전 PLC까지 존재한다. 지켜야 할 원칙은 복잡성의 상대적 비교가 아니라 다음과 같다.
최종적인 차단을 담당하는 경로는 보장 가능한 복잡성 내부에 닫혀 있어야 한다. 안전 측에서는 똑똑함보다 기능의 한정, 예측 가능성, 독립성, 검증 가능성을 우선한다.
이 원칙으로부터 LLM에 의한 의미 평가의 올바른 위치가 결정된다. 금지되는 것은 LLM 평가기의 사용이 아니다. 확률적인 의미 평가만을 최종적인 안전 근거로 삼는 것이다.
LLM에 의한 의미 평가 (진단·보증 지원층)
→ 진단, 경보, 샘플링 우선순위 지정, 수락의 보조 증거로 사용 가능
→ 최종 차단의 유일한 근거로 삼지 않음
...
원칙을 한 문장으로 정리한다.
확률적인 의미 평가는 진단층에 둘 수 있다. 단, 보호층은 그 의미 평가가 틀리더라도 피해를 유계화 (Bounded)할 수 있어야 한다.
별개의 글 C의 선언 3(의미 판정의 재귀)은 이 배치로 사라지는 것이 아니다. ——의미를 심판하는 오류를 범할 수 있는 판정자는 진단층의 중심에 계속 남는다. 변하는 것은, 그 판정자의 오류가 피해의 상한선을 움직일 수 없게 된다는 점이다. 판정의 정확성 보장과 피해의 유계화 보장은 서로 다른 층이 서로 다른 원리로 담당한다. 이를 섞는 순간 둘 다 상실된다.
마지막 억제는 인지 구조에 남는다 —— 그리고 그것 자체도 드리프트 (Drift)한다
📐 도출 / ⬜ 대책은 미검증
런타임 (Runtime)이 상품화되고 주변부가 자동화될수록, 남은 작업은 중심의 의미 판정으로 응축된다. 억제의 최종적인 담당자는 살 수 있는 것(런타임)에서 살 수 없는 것(AI와 사용자의 인지 구조)으로 옮겨간다.
여기서 낙관론에 빠지기 전에, 시리즈 자체의 논리로 두 가지를 지적해 둔다.
첫째, "AI + 인간"이라는 이항 대립은 자동으로 독립적이지 않다. 사용자가 AI와 동일한 전제를 채택하거나, AI의 일관된 오류에 설득된다면 두 판정자는 상관(Correlation)하게 되며, 한쪽이 다른 쪽의 맹점을 메워주지 못한다 (C 선언 2의 인간으로의 확장). 특히 인간이 AI의 출력과 자기 평가를 읽은 뒤에 판단하는 운용 방식은 이 독립성을 해친다. 전전편 B의 "신고와 재정의의 분리"는 인간 재정의자에게도 적용되어야 한다.
다만 모든 건에 대해 이를 수행하는 것은 정보 면에서도 비용 면에서도 비현실적이다. 여기서도 전전편 B의 공정 관리 개념을 그대로 사용한다. ——**전수 검사가 아닌 샘플링 (Sampling)**이다. 고위험 안건 또는 샘플링 대상에 한하여 다음 절차를 밟는다:
1. 계약과 결과물만을 인간에게 제시한다 (AI의 자기 평가·근거 설명은 숨김)
2. 인간이 판정과 우려 사항을 먼저 커밋 (Commit)한다
3. AI의 자기 평가와 근거 신고를 공개한다
...
이 차이점은 재정의의 질을 높이기 위한 절차만이 아니다. 인간과 AI의 판정 상관관계를 조사할 표본이 운용 과정에서 자연스럽게 축적된다. ——일치율, 동시 간과율, 한쪽만이 발견한 비율, 고장 클래스별 상관관계. 단, 한계를 둔다. 이것으로 측정할 수 있는 것은 관측된 안건 분포와 추출 조건 내부에서의 상관관계일 뿐, 통계적 독립성의 입증은 아니다. 원칙은 이렇게 말해야 한다. ——독립성을 가정하지 않고, 관측 가능한 고장 분포 내부에서 판정 상관관계와 동시 간과를 계속 측정한다. seeded faults에 붙였던 "주입 분포 내부만"과 동일한 제한이다. ⬜ 설계 단계만 해당.
둘째, 인지 구조 그 자체도 운용 과정에서 드리프트 (Drift)한다. 이는 시리즈에 아직 실리지 않은 빈틈이므로 여기서 선언해 둔다.
FA와의 유추가 깨지는 지점 —— 등급이 없는 안전계
⬜ 미검증 (누락된 부분의 명시)
유추를 솔직하게 닫는다. 프로세스 안전의 SIS(Safety Instrumented System)에는 AI 보호 계층이 아직 갖추지 못한 것이 있다. 바로 정량화된 보증 등급이다.
SIS에서는 저빈도 요구 모드(Low Demand Mode)라면 PFDavg(작동 요구당 평균 고장 확률)를, 고빈도·연속 모드라면 시간당 위험 측 고장 빈도를 사용하며, 요구되는 리스크 저감에 따라 개별 안전 기능(SIF, Safety Instrumented Function)에 SIL(Safety Integrity Level)을 할당한다. 그리고 그 달성을 아키텍처, 고장률, 진단, 프루프 테스트(Proof Test), 소프트웨어 개발 방법론, 안전 라이프사이클 전체를 통해 입증한다. 중요한 것은 SIL이 제품 라벨이 아니라는 점이다. 인증된 서브시스템을 구매하더라도, 안전 기능 전체로서 요구되는 SIL을 달성하고 있는지 확인하는 책임은 사용자에게 남는다.
즉, FA(Functional AI) 자체가 본고의 제목과 동일한 구조를 먼저 경험하고 있다.
안전 인증을 받은 부품은 살 수 있다. 애플리케이션으로서 안전 기능이 성립함을 입증하는 것은 살 수 없다.
AI 보호 계층에 결여된 것은 이 입증의 분모이다. 결정론적인 수락 검사(Acceptance Test)의 커버리지(정의된 변환 클래스 내부)는 측정할 수 있어도, 의미적 고장(Semantic Failure)의 디맨드 레이트(Demand Rate)는 미지수이며, SIL에 상응하는 등급은 정의조차 존재하지 않는다. 별도의 글 C의 선언 5—서명과 귀결의 대응표는 비어 있다—가, 여기서는 "등급을 부여하는 병리학이 아직 쓰이지 않았다"는 형태로 나타난다.
따라서 수렴의 형태는 보호 계층형일지라도, 성숙도는 SIS의 여명기에 머물러 있다. 계측기는 있다. 분리의 원칙도 있다. 하지만 등급을 부여하는 통계가 아직 없다. 등급이 없는 보호 계층을 등급이 있는 것처럼 말하는 것은, 본 시리즈가 일관되게 금지해 온 "보증이라는 용어의 남용" 그 자체이며, 본고의 예측이 가장 배신당하기 쉬운 지점도 바로 이 부분이다. 의미적 고장은 밸브의 고착(Stuck)처럼 셀 수 없다.
요약
시리즈 전체를 본고의 위치에서 조망한다.
A~C는 단일 루프의 반복계에 대해 "생성기의 약속에 맡기지 않고, 결과물의 관계와 수락 조건에 맡기며, 투영되는 것을 측정하고, 투영되지 않는 것의 목록을 유지한다"는 것을 도출했다. D는 그 위탁 대상의 구조가 감독 제어가 포함된 상태 전이 그래프(State Transition Graph)로 수렴함을 보여주었다. 본고는 그 너머를 예측했다:
- 그래프 다음에 오는 것은 기능 블록을 조합하는 런타임/플랫폼이다.
- 수락 조건의 그릇과 실행기는 살 수 있다. 수락 조건의 내용, 그 충분성의 입증, 수락 책임은 살 수 없다 —— "런타임은 살 수 있지만, 수락 조건은 살 수 없다"는 이것을 압축한 것이다. 살 수 있는지 여부와 어디에 둘 수 있는지는 별개의 축이다. 계는 실행·주제어층 / 진단·보증 지원층 / 독립 보호층의 3층으로 분리된다. 구매 가능한 기능 중, 고장 시 안전 측 동작을 결정론적으로 입증할 수 있는 부분만이 보호층에 들어간다. 확률적인 의미 평가는 진단층에 둘 수 있다. 단, 보호층은 차단 경로상에서 진단층에 의존하지 않으며, 의미 평가가 틀리거나 침묵하더라도 피해를 유계화(Bounded)한다. 최종 차단 경로는 보증 가능한 복잡성 내부에 닫힌다.
- 마지막 억제는 인지 구조에 남으며, 거기에는 새로운 관측 대상이 있다 —— 최종 결정자의 능력 또한 운용 중에 드리프트(Drift)한다(선언 6). 독립성을 가정하지 않고, blind 결정의 차분(Difference)과 seeded faults를 통해 관측 가능한 범위의 판정 상관관계와 동시 놓침(Simultaneous Miss)을 계속 측정한다. 단, SIL에 상응하는 보증 등급은 아직 존재하지 않는다. 분리 구조는 수입할 수 있어도, 정량적 보증은 아직 수입할 수 없다.
마지막으로 시리즈의 기점으로 돌아간다. 전전전고 A는 "작동한 경험과, 언제 고장 나는지에 대한 설명 모델 사이의 간극"에서 시작되었다. 다섯 편의 글을 거쳤음에도 그 간극은 사라지지 않았다. 이동했을 뿐이다 —— 개인의 멘탈 모델의 구멍에서, 앞으로 만들어질 산업 구조의 설계 원칙 문제로.
플랫폼은 반드시 온다. 살 가치가 있다. 하지만 구매한 날 가장 먼저 해야 할 일은 아마 이것일 것이다:
그 플랫폼의 문서 중에서 "보증하지 않는 것"의 목록을 찾는 것. 만약 없다면, 스스로 쓰기 시작하는 것.
참고 문헌
-
IEC 61508 (기능 안전 (Functional Safety)) / IEC 61511-1:2016+AMD1:2017 (프로세스 산업의 안전 계장 시스템 (Safety Instrumented Systems)) — 보호 계층 (Protection Layers), 분리 및 독립성 분석, SIL/PFDavg, 안전 수명 주기 (Safety Lifecycle)
-
IEC 61131-3:2025 — PLC를 위한 표준화 언어군 (ST, LD, FBD, SFC). 「개별 배선에서 공통 런타임 (Runtime) 및 구성 가능한 부품으로」의 대응 대상
-
Lisanne Bainbridge, "Ironies of Automation" (Automatica, 1983) — 자동화의 성공이 인간의 개입 능력을 약화시킨다는 고전적 지적
-
Knight & Leveson, "An Experimental Evaluation of the Assumption of Independence in Multiversion Programming" (1986) — 공통 원인 고장 (Common Cause Failure) · 사각지대 상관관계 (Blind Spot Correlation)의 실험적 근거 (별도 원고 C에서 계속)
-
Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands". https://www.anthropic.com/engineering/managed-agents
-
Addy Osmani, "Own the Outer Loop" (2026-07-15). https://addyosmani.com/blog/own-the-outer-loop/
-
전전전고 A / 전전고 B / 별도 원고 C / 제4고 D — 링크는 공개 후 추가 예정
Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands". https://www.anthropic.com/engineering/managed-agents ↩︎
Lisanne Bainbridge, "Ironies of Automation" (Automatica, 1983) ↩︎
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기