# [[Agent-Computer Interfaces (ACI)]]

## 📌 Brief Summary
**Agent-Computer Interface (ACI)**는 AI 에이전트가 실행 환경과 상호작용하는 방식을 규정하기 위해 에이전트 하네스(Agent Harness)가 설계한 인터페이스 계층입니다 [1, 2]. 이 인터페이스는 에이전트가 사용할 수 있는 명령어 세트, 수신하는 상태 표현, 파싱해야 하는 에러 포맷 등을 결정합니다 [2]. ACI의 설계는 기초 모델(Underlying model)의 품질과 독립적으로 에이전트의 계획 성능과 역량을 결정짓는 핵심 요소로 작용합니다 [1, 2].

## 📖 Core Content

*   **하네스의 고유 권한 및 책임:** ACI는 전적으로 에이전트 하네스에 의해 설계 및 통제됩니다 [2]. 에이전트 모델 자체는 자신에게 주어진 명령어 세트를 변경하거나, 수신하는 상태 표현을 재설계하거나, 에러 포맷을 바꿀 권한이 없습니다 [2]. 따라서, ACI를 설계하는 것은 모델 자체의 기능 문제가 아니라 하네스 엔지니어링의 주요 책임으로 간주됩니다 [2, 3].
*   **성능에 미치는 결정적 영향:** SWE-agent의 연구 등에서 입증되었듯, ACI 설계는 에이전트 역량의 '1차 결정 요인(first-order determinant)'입니다 [1]. 부실하게 설계된 ACI는 모델의 추론 실패가 아니라, 올바른 추론을 구조적으로 표현하기 어렵게 만듦으로써 높은 에러율을 유발합니다 [1, 4]. 즉, ACI의 구조적 설계가 모델 자체의 역량보다 계획 성능에 더 큰 영향을 미칩니다 [2].
*   **필수 설계 요구사항:** 효과적인 ACI가 되기 위해 하네스는 다음과 같은 요소들을 제공해야 합니다 [3].
    *   각 행동 이후의 **모호하지 않은 명확한 상태 표현(unambiguous state representations)** 제공.
    *   복구 가능한 실패와 복구 불가능한 실패를 구별할 수 있는 **구조화되고 파싱 가능한 에러 메시지(structured, parseable error messages)** 반환.
    *   모델이 유효한 행동 순서를 추측할 필요가 없도록 하는 **최소한이되 완전한 명령어 어휘(minimal but complete command vocabulary)** 노출.
    *   돌이킬 수 없는 행동이 실행되기 전에, 계획 승인 게이트(plan approval gate)를 통해 점검받을 수 있는 **검증 가능한 계획 포맷(checkable plan formats)** 제시.
*   **도메인 특화 및 권한 제어:** ACI는 모델에 범용적인 bash 셸을 그대로 제공하는 대신, 목적에 맞게 특화된(purpose-built) 인터페이스를 제공할 수 있습니다 [5]. 예를 들어 SWE-agent의 ACIface 모델은 소프트웨어 엔지니어링 작업에 적절하도록 파일 뷰어, 검색, 편집 도구를 명시적 상태 제약과 함께 제공합니다 [5, 6]. 이는 에이전트가 전체 도구 카탈로그에 접근하는 것을 막고, 실행 전 역량을 제한(pre-execution capability restriction)하여 안전성을 높이는 패턴입니다 [6, 7].

## ⚖️ Trade-offs & Caveats

*   **인터페이스 세금(Interface Tax)의 발생 위험:** ACI가 모호한 상태 표현이나 불충분한 에러 메시지를 반환하도록 잘못 설계될 경우, 모델의 계획 예산(planning budget)에 이른바 '인터페이스 세금'이 부과됩니다 [2]. 모델은 실제 당면한 작업에 대해 추론하는 대신, 하네스가 어떤 의미로 이러한 응답을 반환했는지 유추하는 데 유한한 토큰과 연산 자원을 낭비하게 됩니다 [2].
*   **특화(Specialization) vs. 범용성(Generality)의 균형:** 도메인에 특화된 제한적 셸 인터페이스(예: ACIface)를 노출하면 보안과 정확도는 높아지지만, 모델이 원래 하네스에 존재하는 전체 도구 카탈로그를 활용하지 못하게 되는 제약이 따릅니다 [6]. 따라서 ACI는 에이전트의 잠재력을 제한하지 않도록 "최소한이되 완전한(minimal but complete)" 명령어 세트를 구성해야 하는 까다로운 설계 균형을 요구합니다 [3].
*   **하네스에 대한 완벽한 종속:** 모델은 ACI의 결함(예: 잘못된 에러 피드백 형식, 누락된 도구 명령어)을 스스로 우회하거나 수정할 수 없습니다 [2]. 이는 에이전트의 성공 여부가 전적으로 하네스를 개발한 엔지니어의 인터페이스 설계 역량에 종속된다는 것을 의미합니다 [2].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/기반 기술]
*   [[Agent Harness]]
    *   연결 이유: ACI는 에이전트 하네스가 전적으로 설계하고 관리하는 인터페이스이므로 하네스의 핵심 책임 영역에 속합니다 [2].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 지능형 모델이 아닌 하네스 인프라가 어떻게 에이전트의 실행 환경과 행동을 제어하고 인터페이스를 구성하는지 근본적인 원리를 파악할 수 있습니다 [1, 2].
*   [[Execution Environment]]
    *   연결 이유: ACI는 에이전트가 실행 환경과 상호작용하는 방식을 규정하는 접점(Interface)입니다 [1].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 인터페이스 설계가 실제 컨테이너나 샌드박스 같은 실행 환경에서 에이전트의 성능 및 에러율에 미치는 독립적인 영향을 이해할 수 있습니다 [1].

#### [관계 유형 B: 설계 원칙 및 제약]
*   [[Interface Tax]]
    *   연결 이유: 모호하거나 불충분한 ACI 설계는 에이전트의 계획 예산(planning budget)을 낭비하게 만드는 '인터페이스 세금'을 부과합니다 [2].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 인터페이스 설계의 결함이 어떻게 에이전트의 추론 토큰과 시스템 자원(예산)을 고갈시키는지 경제적, 성능적 측면에서 파악할 수 있습니다 [2].
*   [[Capability Restriction]]
    *   연결 이유: ACI 설계(예: SWE-agent의 ACIface)는 에이전트가 전체 도구를 다 보도록 두는 대신 작업에 적합한 제한된 셸 인터페이스만 노출하도록 제약을 가합니다 [6].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 실행 전 단계(pre-execution)에서 어떻게 에이전트의 행동 반경을 좁혀 오류를 줄이고 시스템을 보호하는지 알 수 있습니다 [6, 7].

### Deeper Research Questions

*   범용 bash 셸 대신 도메인에 특화된 ACI를 설계할 때, "최소한이되 완전한(minimal but complete)" 명령어 어휘를 결정하는 정량적 평가 기준이나 프레임워크는 무엇인가?
*   모호한 상태 표현과 불충분한 에러 메시지가 부과하는 '인터페이스 세금(Interface Tax)'을 모델의 추론 토큰 및 시간 비용 측면에서 어떻게 정량적으로 측정할 수 있는가?
*   ACI의 강력한 권한 및 도구 노출 제약(예: ACIface 모델)이 에이전트의 자율적 탐색(Autonomous exploration) 및 문제 해결 창의성에 미치는 부정적인 영향을 어떻게 최소화할 수 있는가?
*   복구 가능한 실패(recoverable)와 복구 불가능한 실패(unrecoverable)를 구분하여 반환하는 ACI의 에러 포맷 설계가 에이전트의 자체 수정(Self-correction) 사이클 속도에 미치는 구체적인 영향은 무엇인가?
*   다양한 모델 제공자(OpenAI, Anthropic 등)의 상이한 기능, 컨텍스트 제한, 함수 호출 규격을 모두 수용할 수 있는 범용 ACI 설계는 어떻게 가능한가?

### Practical Application Contexts

*   **Implementation:** SWE-agent와 같은 시스템을 구현할 때, 모델이 임의의 시스템 명령어를 사용하게 두지 않고, 파일 뷰어나 검색 도구 등 목적에 맞게 특화된(purpose-built) 제한적 셸 인터페이스(ACI)를 구축하여 에이전트를 제어합니다 [5, 6].
*   **System Design:** 에이전트가 돌이킬 수 없는 파괴적인 행동을 실행하기 전에, 인간이나 정책 게이트가 계획을 검토할 수 있도록 명확하고 검증 가능한 계획 포맷(checkable plan formats)을 생성하도록 ACI를 설계합니다 [3].
*   **Operation / Maintenance:** 모델이 작업 실패 이유를 명확히 인지할 수 있도록, 시스템 로그에서 단순히 원시 오류를 던지는 대신 복구 가능한 에러와 불가능한 에러를 구분해 파싱 가능한 구조화된 형태의 에러 메시지를 반환하도록 로깅 시스템을 유지보수합니다 [3].
*   **Learning Path:** 에이전트를 개발할 때 모델의 프롬프트나 파라미터를 개선하는 데만 몰두하지 않고, 모델이 환경과 상호작용하는 '접점(Interface)'의 설계가 에이전트의 성능과 에러율을 결정하는 핵심 변수임을 학습합니다 [1, 2].
*   **My Project Relevance:** 개인 프로젝트에서 에이전트에 자율성을 부여할 때, 범용 터미널 환경을 그대로 노출하는 대신 엄격한 제약과 상태 피드백을 제공하는 ACI 계층을 도입하여 에이전트의 무한 루프, 환각, 권한 남용을 방지하는 아키텍처로 활용할 수 있습니다 [2, 3, 5].

### Adjacent Topics

*   [[Context Engineering]]
    *   확장 방향: ACI가 에이전트에게 제공하는 상태 표현이나 에러 메시지가 결국 에이전트의 컨텍스트 윈도우로 유입되므로, 이 정보를 어떻게 효율적으로 압축하고 우선순위를 매길 것인지 컨텍스트 관리 기법으로 조사 범위를 확장할 수 있습니다.
*   [[Agent Harness Security]]
    *   확장 방향: ACIface 모델이 도구 노출을 제약하여 보안을 높이는 것처럼, 하네스 수준에서의 샌드박싱 구조, 권한 제어, 파괴적 행동에 대한 가드레일 설계 기술 전반으로 확장이 가능합니다.

---
*Last updated: 2026-05-01*