Web Dev Learn

Theme

11-1. AI 에이전트 개요와 동작 모델 ​

한 줄 요약: AI 코딩 에이전트를 챗봇이 아니라 관찰-행동-검증 루프를 도는 비결정적 자동화 프로세스로 이해하고, 무엇을 위임할 수 있고 어떤 책임이 사람에게 남는지 판단할 수 있다.

학습 목표 ​

  • AI 에이전트를 모델·하네스·환경의 세 계층으로 분해하고, 챗봇·자동완성과의 구조적 차이를 설명할 수 있다.
  • 에이전트의 기본 실행 루프(목표 수신 → 관찰 → 계획 → 도구 실행 → 피드백 → 검증 → 인계)를 단계별로 설명할 수 있다.
  • 프론트엔드 개발에서 에이전트가 특히 유용한 작업 유형과 그 이유를 판단할 수 있다.
  • 대표 코딩 에이전트(Codex, Claude Code, Antigravity, Pi)의 성격 차이를 하네스 구조 기준으로 비교할 수 있다.
  • 작업 위험도와 검증 비용을 기준으로 모델 등급을 배정하는 판단을 내릴 수 있다.

배경: 왜 이것이 존재하는가 ​

LLM을 개발에 쓰는 방식은 세 세대로 나눌 수 있다. 첫 번째는 챗봇이다. 개발자가 질문을 붙여 넣고 답변 코드를 복사해 온다. 코드베이스를 아는 쪽은 사람이고, 모델은 매번 백지에서 답한다. 두 번째는 자동완성이다. 에디터가 커서 주변 컨텍스트를 모델에 보내고 다음 몇 줄을 제안받는다. 컨텍스트 수집이 자동화됐지만, 행동 단위는 여전히 "텍스트 삽입" 하나다. 세 번째가 에이전트(agent)다. 목표를 받으면 스스로 코드베이스를 읽고, 파일을 수정하고, 테스트를 실행하고, 실패 로그를 보고 다시 수정한다. 사람의 개입 없이 여러 단계의 행동을 이어 간다는 점이 앞의 두 세대와 질적으로 다르다.

이 차이는 UI의 차이가 아니라 피드백 루프의 소유권 차이다. 챗봇 시대에는 "제안된 코드가 실제로 동작하는가"를 확인하는 루프를 사람이 돌렸다. 에이전트는 이 루프를 자신이 돈다. 컴파일 에러를 보고 고치고, 테스트 실패를 보고 접근을 바꾼다. 백엔드 개발자라면 이 구조가 낯설지 않을 것이다. 이는 cron으로 도는 배치 작업, CI runner, 운영 자동화 봇과 같은 부류의 시스템이다. 즉 권한을 가진 자동화 프로세스이고, 다만 결정적(deterministic)이지 않다는 점이 다르다. 같은 입력에도 다른 행동을 할 수 있고, 그럴듯하지만 틀린 판단을 할 수 있다.

그래서 이 Phase가 다루는 것은 "프롬프트 잘 쓰는 법"이 아니다. 비결정적 프로세스에게 코드베이스 접근 권한을 주는 문제는 입력 설계(작업 명세), 환경 설계(컨텍스트, 도구, 권한), 출력 검증(테스트, 브라우저, 리뷰), 실패 대응(귀인, 롤백)의 문제다. Phase 0~10에서 쌓은 프론트엔드 판단 기준이 바로 이 검증과 귀인의 재료가 된다.

핵심 개념 ​

에이전트는 모델이 아니라 시스템이다 ​

"Claude로 코딩한다"거나 "GPT가 버그를 고쳤다"는 표현은 시스템의 한 부품만 가리킨다. 실제로 동작하는 것은 세 계층의 결합이다.

계층역할예시
모델(model)텍스트를 읽고 다음 행동을 결정하는 추론 엔진Claude, GPT, Gemini 계열 모델
하네스(harness)모델을 감싸 도구·컨텍스트·권한·루프를 제공하는 런타임Claude Code, Codex CLI, Pi
환경(environment)에이전트가 관찰하고 변경하는 대상저장소, 파일 시스템, shell, 브라우저, CI

모델은 도구를 직접 실행하지 못한다. 모델이 하는 일은 "이 파일을 읽고 싶다", "이 명령을 실행하고 싶다"는 의도를 구조화된 형식으로 출력하는 것까지다. 그 의도를 받아 실제로 파일을 읽고, 명령을 실행하고, 결과를 다시 모델의 컨텍스트에 넣어 주는 것이 하네스다. HTTP 요청을 만드는 것은 애플리케이션 코드지만 실제 바이트를 나르는 것은 네트워크 스택인 것과 같은 관계다.

이 분해가 중요한 이유는 결과의 품질이 세 계층 모두에서 결정되기 때문이다. 같은 모델이라도 하네스가 어떤 파일을 보여 주고, 어떤 도구를 허용하고, 어떤 실패 신호를 돌려주는지에 따라 성공률이 크게 달라진다. Polar 연구(참고 자료)는 동일 모델을 Codex, Claude Code, Qwen Code, Pi 등 서로 다른 하네스에서 실행했을 때 개선 폭이 하네스별로 다르게 나타남을 보고한다. "모델 A가 모델 B보다 좋다"는 벤치마크 비교는 하네스와 환경 변수를 통제하지 않으면 실무 판단의 근거가 되기 어렵다. 하네스 자체의 설계는 11-4에서 다룬다.

기본 실행 루프 ​

하네스마다 세부는 다르지만, 코딩 에이전트의 실행 루프는 공통 골격을 가진다.

text
1. 작업 명세 수신     사람이 목표, 제약, 성공 조건을 전달한다
2. 저장소 관찰        파일 목록, 관련 코드, 설정, 문서를 읽는다
3. 계획 수립          변경할 파일과 순서, 검증 방법을 결정한다
4. 도구 호출          파일 편집, 명령 실행, 브라우저 조작
5. 결과 관찰          diff, 컴파일 에러, 테스트 출력, 스크린샷
6. 계획 수정          실패 신호를 반영해 3~5를 반복한다
7. 검증               테스트·타입체크·빌드·브라우저 확인을 실행한다
8. 인계               변경 요약, 검증 결과, 남은 리스크를 사람에게 보고한다

핵심은 4→5→6의 반복이다. 에이전트의 지능은 한 번에 완벽한 코드를 쓰는 데 있지 않고, 실패 신호를 받아 행동을 수정하는 데 있다. 이 관점은 실무 판단 하나를 바로 끌어낸다. 에이전트에게 좋은 환경이란 실패 신호가 빠르고 명확한 환경이다. 타입체크가 있는 저장소, 빨리 도는 테스트, 명확한 에러 메시지를 내는 빌드는 사람에게만 좋은 것이 아니라 에이전트의 루프 품질을 직접 올린다. 반대로 테스트가 없는 저장소에서 에이전트는 "컴파일이 된다" 이상의 피드백을 받지 못한 채 루프를 닫는다.

루프를 직접 관찰해 보면 모델을 이해하는 데 도움이 된다. 대부분의 CLI 에이전트는 실행 중 도구 호출을 실시간으로 보여 준다. 작은 작업 하나를 시켜 놓고 어떤 파일을 읽는지, 어떤 명령을 실행하는지, 실패했을 때 무엇을 하는지 지켜보라. "코드를 생성한다"는 인상이 "저장소를 탐색하고 가설을 검증한다"는 인상으로 바뀔 것이다.

에이전트의 구성 요소 ​

실행 루프를 지탱하는 구성 요소를 나열하면 다음과 같다. 각각은 뒤 문서에서 심화한다.

  • 목표(goal): 사람이 준 작업 명세. 모호하면 에이전트는 질문 대신 추측으로 행동한다. → 11-2
  • 컨텍스트(context): 모델이 현재 볼 수 있는 정보 전체. 유한한 예산이며 오염될 수 있다. → 11-3
  • 도구(tools): 파일 읽기/쓰기, shell, 브라우저, MCP 커넥터 등 행동 수단. → 11-4
  • 메모리(memory): 세션을 넘어 유지되는 프로젝트 규칙과 학습. → 11-3
  • 권한(permissions): 어떤 행동을 자동 허용하고 어떤 행동에 승인을 요구하는가. → 11-6
  • 관측 가능성(observability): 에이전트가 무엇을 읽고 실행했는지의 기록. → 11-5
  • 검증(verification): 결과가 맞다는 것을 보이는 증거의 생산. → 11-5

프론트엔드에서 에이전트가 유용한 작업 ​

프론트엔드는 에이전트와 궁합이 좋은 특성과 나쁜 특성을 동시에 가진다. 좋은 쪽은 검증 도구가 풍부하다는 점이다. 타입체크, 컴포넌트 테스트, Playwright, 스크린샷, 접근성 트리, Lighthouse까지 기계가 확인할 수 있는 신호가 많다. 나쁜 쪽은 최종 판정 기준이 "화면이 사용자에게 어떻게 보이고 느껴지는가"라는, 텍스트로 완전히 환원되지 않는 영역이라는 점이다.

이 특성에서 위임 적합도가 갈린다.

작업적합도이유
낯선 코드베이스 탐색·요약높음읽기 전용이라 위험이 낮고, 검증은 사람이 답을 대조하면 된다
테스트 보강높음성공 조건이 기계적(테스트가 돌고 의미 있는 단언을 한다)
타입·prop 경계 보강높음타입체커가 즉시 피드백을 준다
버그 재현과 원인 탐색높음재현 명령이 있으면 루프가 자체 검증된다
작은 리팩터링중간테스트가 있으면 높음, 없으면 동작 보존을 보장할 수 없다
UI 상태 경계(loading/empty/error) 처리중간상태표가 명세로 주어지면 높음
접근성 점검·수정중간axe 같은 도구로 일부 검증 가능, 실제 스크린 리더 경험은 사람 몫
시각 디자인·레이아웃 미세 조정낮음판정 기준이 주관적이고 스크린샷 피드백 루프가 느리다
아키텍처 결정낮음후보 비교 자료 생성은 유용하나 결정과 책임은 사람의 것

패턴이 보일 것이다. 성공 조건을 기계가 판정할 수 있는 작업일수록 위임 적합도가 높다. 이는 에이전트가 자체 검증 루프를 돌 수 있는 조건과 정확히 일치한다.

도구 지형: 네 가지 대표 사례 (2026년 7월 기준) ​

제품은 빠르게 바뀌므로, 여기서는 개별 기능이 아니라 하네스 설계의 스펙트럼을 보여 주는 사례로 네 가지를 짚는다.

  • Codex — OpenAI의 코딩 에이전트. CLI, IDE 확장, 클라우드 웹, 앱까지 여러 실행 표면을 가지며, AGENTS.md로 저장소 지시문을 읽고 샌드박스와 승인 모드로 권한을 조절한다. 하나의 에이전트를 로컬 대화형부터 클라우드 무인 실행까지 걸쳐 놓은 "다표면 제품형" 사례다.
  • Claude Code — Anthropic의 코딩 에이전트. 터미널을 1차 표면으로 코드베이스 읽기, 파일 편집, 명령 실행을 중심에 두고 IDE·데스크톱·웹으로 확장된다. CLAUDE.md 지시문, 권한 모드, MCP, 서브에이전트, worktree 격리를 갖춘 역시 제품형 사례다.
  • Antigravity — Google의 에이전트 우선(agent-first) IDE. 에디터 안에서 코드를 보조하는 것이 아니라, 여러 에이전트의 작업을 관리자 화면(manager surface)에서 조율하고 산출물(artifacts)로 결과를 검토하는 구조를 내세운다. "에이전트가 여럿이고 사람은 검토자"라는 방향의 사례다.
  • Pi — 오픈소스 BYOK(bring your own key) CLI 코딩 에이전트. Read/Write/Edit/Bash 네 가지 최소 도구만 코어에 두고, 나머지는 extension·skill·prompt template으로 사용자가 확장한다. 미니멀 하네스의 사례로, "하네스에 무엇이 들어가야 하는가"를 최소 집합에서 출발해 생각하게 해 준다.

이 네 사례를 나란히 놓으면 하네스 설계의 축이 드러난다. 도구를 얼마나 내장할 것인가(Pi의 4개 vs 제품형의 수십 개), 실행 표면을 어디까지 넓힐 것인가(터미널 vs IDE vs 클라우드), 권한을 어떻게 나눌 것인가, 지시문·메모리를 어떤 형식으로 받을 것인가. 흥미로운 점은 최소 도구의 Pi도 실전 코딩 작업을 수행한다는 사실이다. 파일을 읽고 쓰고 명령을 실행할 수 있으면 루프는 성립한다. 나머지 하네스 기능은 루프의 성립이 아니라 루프의 효율과 안전을 위한 것이다. 이 구분은 11-4의 출발점이 된다.

모델 선택: 벤치마크가 아니라 위험도와 검증 비용 ​

같은 하네스 안에서도 모델 등급을 고를 수 있다. 상위 모델은 능력이 높지만 느리고 비싸며, 하위 모델은 빠르고 싸지만 복잡한 추론에서 무너진다. 이 선택을 "벤치마크 점수가 높은 모델을 쓴다"로 접근하면 비용이 낭비되거나 품질이 무너진다. 판단 기준은 두 가지다.

  1. 작업의 위험도: 결과가 틀렸을 때의 피해. 파일을 읽고 요약하는 탐색은 틀려도 사람이 읽다가 걸러 낸다. 상태 관리 코드를 수정하는 작업은 틀리면 미묘한 버그가 병합된다.
  2. 검증 비용: 결과가 맞는지 확인하는 데 드는 노력. 테스트가 즉시 판정해 주는 작업은 하위 모델의 실패가 싸게 걸러진다. 사람이 diff를 정독해야만 검증되는 작업은 실패 한 번이 비싸다.
작업위험도검증 비용권장 배정
코드베이스 탐색, 파일 요약낮음낮음하위 모델
커밋 메시지·PR 설명 초안낮음낮음하위 모델
테스트가 있는 코드의 작은 수정중간낮음(자동)중위 모델
여러 파일에 걸친 구현·리팩터링높음높음상위 모델
설계 후보 비교, 까다로운 버그 추적높음높음상위 모델

많은 하네스가 서브에이전트에 다른 모델을 배정하는 기능을 제공하므로, "메인 루프는 상위 모델, 대량 탐색 서브에이전트는 하위 모델" 같은 구성이 실용적 기본값이 된다.

자동성과 책임은 다르다 ​

이 문서에서 가장 중요한 구분이다. 에이전트가 어떤 행동을 할 수 있다는 것(자동성)과 그 행동의 결과를 사람이 책임에서 놓아도 된다는 것(위임)은 별개다. 에이전트는 커밋을 만들고 PR을 열고, 설정에 따라 배포 명령도 실행할 수 있다. 그러나 병합된 코드가 프로덕션에서 일으키는 장애, 유출된 secret, 라이선스 위반의 책임은 하네스에도 모델에도 물을 수 없다. 책임은 병합 버튼을 누른 사람과 그 팀의 운영 규칙에 남는다.

CI/CD에 비유하면 정확하다. 배포 파이프라인이 자동이라는 것과 배포 승인이 자동이라는 것은 다른 문제이며, 성숙한 조직은 파이프라인 자동화 수준과 무관하게 승인 지점과 책임자를 명시한다. 에이전트 운영도 같은 구조를 요구한다. "AI가 만든 코드"라는 범주는 책임 관점에서 존재하지 않는다. 존재하는 것은 "검증되고 리뷰된 변경"과 그렇지 않은 변경뿐이다. 이 원칙의 운영 규칙화는 11-6에서 다룬다.

실무 관점 ​

흔한 오해와 안티패턴 ​

  • "주니어 개발자처럼 대하면 된다" — 절반만 맞다. 설명을 명확히 해야 한다는 점은 같지만, 주니어는 모르면 질문하고, 어제 배운 것을 기억하고, 이상하면 멈춘다. 에이전트는 기본적으로 질문 대신 추측하고, 세션이 끝나면 잊고, 모호한 지시도 확신을 갖고 실행한다. 주니어 온보딩보다는 자동화 시스템의 입력·권한·검증 설계에 가까운 마음가짐이 안전하다.
  • "좋은 모델을 쓰면 해결된다" — 모델 업그레이드는 하네스와 환경의 결함을 못 덮는다. 테스트 없는 저장소, 모호한 작업 명세, 오염된 컨텍스트에서는 상위 모델도 검증되지 않은 그럴듯한 코드를 낼 뿐이다.
  • "돌아가는 코드가 나왔으니 성공이다" — 에이전트 산출물의 단위는 코드가 아니라 검증 가능한 변경이다. 어떤 검증이 실행됐고 어떤 증거가 남았는지가 없으면, 그 작업은 아직 끝나지 않은 것이다.
  • "에이전트가 확인했다고 한다" — 모델은 실행하지 않은 검증을 실행했다고 서술할 수 있다(hallucination). 검증의 증거는 에이전트의 문장이 아니라 하네스가 기록한 도구 호출 로그와 그 출력이다.

챗봇·자동완성·에이전트의 선택 기준 ​

에이전트가 항상 우월한 것은 아니다. 세 형태는 공존하며 각자의 자리가 있다.

상황적합한 형태이유
개념 질문, API 사용법 확인챗봇루프가 필요 없고 가장 싸다
타이핑 중 보일러플레이트자동완성지연이 낮고 흐름을 끊지 않는다
코드베이스를 읽어야 답할 수 있는 질문에이전트탐색 도구가 필요하다
여러 파일 수정 + 테스트 확인이 필요한 변경에이전트자체 검증 루프가 필요하다
판단 자체가 목적(설계 결정, 트레이드오프)챗봇/에이전트 보조 + 사람 결정책임은 위임되지 않는다

무너지는 경계 ​

에이전트 위임이 무너지는 신호를 알아 두면 손실을 줄일 수 있다.

  • 재작업 비용이 직접 작성 비용을 넘을 때: 같은 작업을 세 번째 다시 시키고 있다면, 작업 명세나 컨텍스트의 문제이거나 애초에 위임 부적합 작업이다.
  • 검증 수단이 없는 영역에 들어갈 때: 테스트도 타입도 없는 레거시 모듈의 리팩터링은 에이전트가 아니라 누구에게도 안전하게 위임할 수 없다. 먼저 검증 수단(특성화 테스트)을 만드는 작업으로 바꿔야 한다.
  • 작업이 판단을 요구하기 시작할 때: "이 두 접근 중 무엇이 팀 방향에 맞는가"에 도달하면 루프를 멈추고 사람이 결정해야 한다.

더 깊이 ​

도구 호출의 실제 메커니즘 ​

모델과 하네스의 경계를 프로토콜 수준에서 보면 이렇다. 하네스는 모델에 요청을 보낼 때 사용 가능한 도구의 목록을 스키마(이름, 설명, 파라미터의 JSON Schema)로 함께 전달한다. 모델의 응답은 일반 텍스트이거나, "도구 X를 인자 Y로 호출하라"는 구조화된 출력이다. 하네스는 그 호출을 실제로 실행하고 결과 텍스트를 대화 이력에 덧붙여 다시 모델에 보낸다. 즉 에이전트 루프 한 바퀴는 모델 API 호출 한 번 + 도구 실행 한 번이며, 수십 바퀴의 루프는 수십 번의 API 왕복이다.

여기서 두 가지 실무 함의가 나온다. 첫째, 루프가 돌 때마다 대화 이력 전체가 다시 입력으로 들어가므로, 긴 세션은 토큰 비용이 선형이 아니라 누적으로 증가하고 컨텍스트 예산을 잠식한다(11-3의 근거). 둘째, 도구의 설명(description)과 파라미터 스키마 자체가 모델이 읽는 프롬프트의 일부다. 도구 설계가 곧 프롬프트 설계이며, MCP로 도구를 추가한다는 것은 컨텍스트 예산과 행동 공간을 함께 넓힌다는 뜻이다(11-4).

비결정성의 출처 ​

에이전트의 비결정성은 한 곳에서 오지 않는다. 모델의 샘플링(temperature가 0이어도 부동소수점 연산과 배치 구성에 따라 출력이 흔들릴 수 있다), 환경의 변화(어제와 오늘 의존성 버전이 다르다), flaky test, 그리고 컨텍스트 순서(같은 정보라도 제시 순서에 따라 판단이 달라질 수 있다)가 겹친다. 따라서 "어제는 됐는데 오늘은 안 된다"는 현상의 귀인은 모델 탓 한 곳으로 좁혀지지 않으며, 체계적 귀인 방법이 필요하다. 이는 11-5의 실패 귀인에서 다룬다.

"하네스가 결과를 좌우한다"의 연구 근거 ​

이 문서의 주장이 감상이 아니라는 근거로 두 갈래의 연구가 있다. AI Harness Engineering 계열 연구는 하네스를 파운데이션 모델 에이전트의 **런타임 기판(runtime substrate)**으로 정의하고, 작업 명세·컨텍스트 선택·도구 접근·메모리·상태·관측 가능성·실패 귀인·검증·권한을 하네스가 져야 할 책임 목록으로 정리한다. Polar 연구는 기존 하네스를 블랙박스로 두고 모델 API 경계에서 trace를 수집해 학습하는 접근을 취하는데, 같은 모델 개선이 하네스별로 다른 폭의 성능 향상으로 나타남을 보인다. 실무 번역은 단순하다. 에이전트 도입 효과가 기대에 못 미칠 때, 모델 교체보다 하네스·환경 점검이 먼저다.

정리 ​

  • 에이전트는 모델·하네스·환경의 결합 시스템이다. 결과 품질은 세 계층 모두에서 결정되며, 같은 모델도 하네스에 따라 성능이 달라진다.
  • 에이전트와 챗봇의 본질적 차이는 피드백 루프의 소유권이다. 에이전트는 실패 신호를 스스로 관찰하고 행동을 수정하므로, 빠르고 명확한 실패 신호를 주는 저장소가 곧 에이전트 친화적 저장소다.
  • 위임 적합도는 성공 조건을 기계가 판정할 수 있는가로 갈린다. 탐색·테스트 보강·타입 경계는 높고, 시각 판단·설계 결정은 낮다.
  • 모델 등급은 벤치마크가 아니라 작업 위험도와 검증 비용으로 배정한다. 탐색은 하위 모델로, 다파일 구현은 상위 모델로.
  • 자동성과 책임은 다르다. 에이전트가 실행할 수 있다는 것과 사람이 병합·배포 책임을 놓아도 된다는 것은 별개이며, 책임은 항상 사람과 팀의 운영 규칙에 남는다.

확인 문제 ​

  1. 팀 동료가 "우리 저장소에서는 에이전트가 자꾸 엉뚱한 코드를 짜니 더 비싼 모델로 바꾸자"고 제안한다. 이 저장소는 테스트가 거의 없고 빌드 명령이 README에 문서화되어 있지 않다. 모델 교체보다 먼저 점검할 것을 이 문서의 모델(모델-하네스-환경)로 설명하라.
정답과 해설

에이전트의 품질은 모델 단독이 아니라 모델-하네스-환경 시스템에서 결정된다. 이 저장소의 증상은 환경 결함을 가리킨다. 테스트가 없으면 에이전트의 핵심 능력인 "실패 신호를 보고 수정하는 루프"가 성립하지 않아, 어떤 모델이든 검증되지 않은 그럴듯한 코드를 낸다. 빌드 명령이 문서화되지 않았다면 에이전트는 검증 명령 자체를 추측해야 한다. 우선순위는 ① 실행·테스트 명령을 프로젝트 지시문에 문서화하고 ② 변경 대상 영역에 최소한의 테스트를 만들고 ③ 작업 명세에 검증 명령을 포함하는 것이다. Polar 연구가 보이듯 같은 모델도 하네스·환경에 따라 결과가 달라지므로, 환경 결함을 둔 채 모델만 올리면 "더 비싸고 여전히 검증 안 된 코드"를 얻을 가능성이 높다.

  1. 다음 세 작업이 있다: (a) 500개 컴포넌트 파일에서 deprecated prop 사용처를 찾아 목록화, (b) 장바구니 합계 계산 버그 수정(재현 테스트 있음), (c) 상태 관리 라이브러리를 교체할지에 대한 결정. 각 작업에 대해 위임 여부와 모델 등급 배정을 근거와 함께 판단하라.
정답과 해설

(a) 위임 적합도 높음, 하위 모델. 읽기 전용이라 위험도가 낮고, 결과는 grep 등으로 교차 확인 가능해 검증 비용도 낮다. 대량 반복 탐색은 저비용 모델·서브에이전트의 전형적 용도다. (b) 위임 적합도 높음, 중위 이상 모델. 재현 테스트가 있어 성공 조건을 기계가 판정한다 — 에이전트가 자체 검증 루프를 돌 수 있는 최적 조건이다. 다만 금액 계산은 틀렸을 때 피해가 커 위험도가 중간 이상이므로 사람 리뷰는 유지한다. (c) 결정 자체는 위임 불가. 후보 비교 자료 조사(각 라이브러리의 마이그레이션 비용, 번들 영향 분석)는 에이전트에게 맡길 수 있으나, 팀 방향과 유지보수 책임이 걸린 결정과 그 책임은 사람의 것이다. 자동성과 책임의 구분이 적용되는 사례다.

  1. 에이전트가 작업을 마치며 "테스트를 실행해 모두 통과함을 확인했다"고 보고했다. 이 보고를 그대로 믿으면 안 되는 이유와, 무엇을 확인해야 하는지 설명하라.
정답과 해설

모델은 실행하지 않은 행동을 실행했다고 서술할 수 있다(hallucination). "확인했다"는 문장은 모델이 생성한 텍스트일 뿐, 검증이 일어났다는 증거가 아니다. 확인해야 할 것은 하네스가 기록한 도구 호출 로그다: 테스트 명령이 실제로 호출됐는가, 그 명령의 실제 출력(통과/실패 수)이 무엇인가, 실행된 테스트가 변경 영역을 실제로 커버하는가(전체 통과라도 관련 테스트가 없으면 의미가 약하다). 원칙은 "에이전트의 서술이 아니라 도구 호출의 기록과 출력이 증거"이며, 이를 체계화한 것이 11-5의 증거 패키지다.

참고 자료 ​