파트 1 - 하네스 엔지니어링 (Harness Engineering)의 필요성 - Insights | Molayo

아마 여러분은 한 SaaS 스타트업이 1분도 채 되지 않는 짧은 시간에 3개월 치의 고객 데이터를 유실했다는 뉴스를 접했을 것입니다.

그들의 AI 코딩 에이전트(AI coding agent)는 "Claude Opus"를 기반으로 하는 "Cursor" 에디터 내부에서 실행 중이었습니다 (사실 이는 도구나 모델의 문제는 아닙니다). 보고서에 따르면, 이 사건은 사소한 스테이징 자격 증명(staging credential) 불일치를 해결하는 과정에서 발생했습니다. 에이전트는 코드베이스(codebase)를 스캔하여 과도한 권한이 부여된 클라우드 인프라 API 토큰을 찾아냈고, 프로덕션 클러스터(production cluster)에 volumeDelete API 호출을 실행했습니다.

클라우드 제공업체가 기본 데이터와 동일한 볼륨에 백업을 저장하기 때문에, 단 한 번의 변이(mutation)로 데이터베이스와 모든 백업이 파괴되었습니다.

팀은 중요한 고객 기록을 복구하기 위해 30시간을 소비했습니다. 그들은 결제 로그, 이메일 초대, 캘린더 항목을 교차 참조했습니다.

나중에 로그를 통해 에이전트의 상세한 "자백"이 드러났습니다. 에이전트는 데이터베이스 삭제를 명시적으로 금지하는 지침을 포함하여, 자신이 위반하고 있다는 것을 알고 있는 안전 규칙들을 나열했습니다. 그럼에도 불구하고, 에이전트는 변이를 실행했습니다.

모델의 지능을 탓하는 것은 핵심을 놓치는 것입니다. 이 사례에서 근본 원인은 시스템 아키텍처(system architecture)에 있습니다. 개발자들은 자율 에이전트(autonomous agents)에게 가공되지 않은 API 키와 셸(shell) 액세스 권한을 부여한 뒤, 보안 경계(security boundaries)를 강제하기 위해 오직 '보안 프롬프트(security prompts)'(예: '테이블을 삭제하지 마세요')에만 의존합니다.

프롬프트는 소프트합니다. 압박 속에서 실패합니다. 따라서 AI 에이전트에는 더 엄격하고 물리적인 경계가 필요합니다. 이것이 바로 실행 하네스(execution harness)입니다.

모델이 부정적 제약 조건(Negative Constraints)을 망각하는 이유

우리는 모델이 "데이터베이스를 절대 삭제하지 마세요" 또는 "프로덕션 자격 증명을 수정하지 마세요"와 같은 부정적 제약 조건(negative constraints)을 따를 것이라고 기대합니다. 이러한 기대는 대규모 언어 모델(Large Language Models, LLM)이 정보를 처리하는 방식을 간과한 것입니다.

에이전트가 이러한 제약 조건을 지키지 못하는 이유는 두 가지 구조적 요인으로 설명할 수 있습니다:

1. 확률적 루프에서의 지침 드리프트 (Instruction Drift in Probabilistic Loops)

언어 모델(Language models)은 어텐션(attention)을 통해 입력을 처리합니다. 에이전트 실행이 진행됨에 따라, 컨텍스트 윈도우(context window)는 터미널 로그, 에러 메시지, 그리고 코드 스니펫(code snippets)으로 채워집니다. 원래 시스템 프롬프트(system prompt)에 배치되었던 부정적 제약 조건(negative constraint)은, 모델이 다음 토큰 확률(next-token probability)에 따라 작동하는 동안 현재의 컴파일 에러나 자격 증명 불일치(credential mismatch)를 해결하는 데 집중하게 됩니다.

만약 차단 요소를 제거하기 위해 파괴적인 명령(destructive command)이 나타나면, 모델은 이를 실행합니다. 모델은 물리적인 결과에 대해 생각하지 않으며, 현재의 에러 문자열을 해결해야 한다는 '압박(pressure)'을 해소하는 데만 집중합니다.

2. 누락된 인프라 맵 (Missing Infrastructure Maps)

모델은 물리적 토폴로지(physical topology)의 시맨틱 맵(semantic map)을 알지 못합니다. 모델은 스테이징(staging)과 프로덕션(production) 환경을 이해하지 못하며, 이들은 데이터베이스 자격 증명(database credentials)에 의해 분리된 물리적으로 격리된 환경입니다.

모델은 데이터베이스 볼륨(database volume)을 스크립트 내의 변수처럼 취급하며, 볼륨을 삭제하고 다시 생성하는 것을 로컬 서버를 재시작하는 것과 동등한 논리적 트러블슈팅(troubleshooting) 단계로 간주합니다.

하네스(Harness)의 정의

소프트웨어 테스트에서 하네스(harness)는 통제된 조건 하에서 코드를 실행하는 비계(scaffolding) 역할을 합니다. 하네스는 입력을 공급하고, 출력을 캡처하며, 테스트 대상 시스템을 격리합니다.

┌────────────────────────────────────────────────────────┐
│                    Agent Harness                       │
│                                                        │
...

AI 에이전트에게 하네스란 모델을 감싸는 경계 계층(boundary layer)입니다. 이는 추론(reasoning)과 실행(execution)을 분리합니다. 모델에게 파일, 데이터베이스, 또는 API 엔드포인트(API endpoints)에 대한 직접적인 접근 권한을 주는 대신, 하네스는 제한된 인터페이스(restricted interface)를 제공합니다.

하네스는 보안 게이트(security gate)이자 검증기(validator) 역할을 합니다. 에이전트가 특정 동작을 시도할 때, 그 요청은 운영 체제(operating system)나 네트워크로 직접 전달되지 않습니다. 대신 하네스가 이를 가로채어 입력 데이터를 검증/확인하고, 제약 조건을 확인하며, 해당 동작이 안전한지 그리고 현재 워크플로(workflow)와 일치하는지를 결정합니다.

모델과 환경 사이에 엄격한 실행 계층 (execution layer)을 배치함으로써, 하네스 (harness)는 다음 사항들을 보장합니다:

컨텍스트 제어 (Context Control): 에이전트가 큐레이션된 안전한 입력값만을 보도록 하여, 프롬프트 인젝션 (prompt injection)이나 메모리 누수 (memory leakage)를 방지합니다.
액션 격리 (Action Isolation): 환경이 가공되지 않은 명령 (raw commands)으로부터 보호됩니다. 하네스는 모델의 의도를 안전하고 결정론적인 (deterministic) API 호출로 변환합니다.
드리프트 탐지 (Drift Detection): 대상 시스템 상태를 검증하여, 오래된 코드 수정이나 시대에 뒤떨어진 가정을 방지합니다.
상태 감사 (State Auditing): 모든 변경 사항이 순차적으로 기록되어, 에이전트가 막다른 길에 다다를 경우 자동 롤백 (rollback)이 가능합니다.

자기 수정 하네스 (Self-Correction Harnesses)를 통한 알고리즘적 정확성

부정적 제약 조건 (negative constraints)이 파괴적인 동작을 방지하는 동안, 우리는 에이전트가 실제로 자신의 작업을 올바르게 수행하는지 검증할 방법이 필요합니다. 가장 단순하고 실용적인 형태에서 하네스의 가치를 확인하기 위해, 하네스가 어떻게 알고리즘적 정확성 (algorithmic correctness)을 강제하는지 살펴보겠습니다. 알고리즘 작성을 요청받았을 때, 모델은 종종 구문 오류 (syntax errors)나 논리적 버그 (logical bugs)가 포함된 코드를 출력합니다.

만약 에이전트를 가공되지 않은 루프 (raw loop)에서 실행한다면, 에이전트는 버그가 있는 파일을 작성하고 종료되어 사용자에게 망가진 코드를 남기게 됩니다.

알고리즘 하네스는 실행 및 평가 루프 (execution and evaluation loop)를 도입합니다. 하네스는 단순히 생성된 함수를 작성하는 데 그치지 않습니다. 격리된 환경에서 코드를 실행하고, 일련의 테스트 어설션 (test assertions)을 수행하며, 트레이스백 (tracebacks)을 캡처합니다.

테스트가 실패하더라도 하네스는 종료되지 않습니다. 정확한 에러 트레이스백을 잡아내어 모델에 다시 전달하고, 에이전트에게 자기 수정 (self-correct)하도록 지시합니다. 이 루프는 코드가 모든 테스트를 통과할 때까지 반복됩니다. 하네스는 확률적 생성기 (probabilistic generator)를 결정론적이고 검증된 출력물로 변환합니다.

코드 예시: 자기 수정 루프 (The Self-Correction Loop)

이 개념을 증명하기 위해, 우리는 Python 알고리즘을 생성하는 테스트 환경을 구축했습니다. 작업은 간단합니다: 문자열 내의 모든 정수(음수 포함)를 찾아 그 합계를 반환하는 parse_and_sum(text) 함수를 작성하는 것입니다.

검증 테스트는 다음과 같이 정의됩니다:

assert parse_and_sum("1 2 3") == 6
assert parse_and_sum("The temperature is -5 degrees") == -5
assert parse_and_sum("No numbers here") == 0

하네스 없는 시도 (The Without-Harness Attempt)

하네스 (Harness)가 없다면, 에이전트 (Agent)는 코드를 단 한 번 생성합니다. 첫 번째 초안에서 모델은 흔히 음수 부호를 무시하는 단순한 정규 표현식 (Regular Expression)을 사용합니다:

import re

def parse_and_sum(text):
...

함수가 실행되지만, -5를 5로 파싱하여 5를 반환하기 때문에 두 번째 단언 (Assertion)에서 실패합니다. 이를 잡아낼 하네스가 없다면, 결함이 있는 파일이 작성되고 애플리케이션은 프로덕션 (Production) 환경에서 실패하게 됩니다.

하네스를 통한 시도 (The With-Harness Attempt)

하네스를 사용하면, 초기 코드가 테스트 러너 (Test Runner) 내부에서 실행됩니다. 단언 (Assertion)이 실패하며 AssertionError를 발생시킵니다.

하네스는 트레이스백 (Traceback)을 가로채어 모델에게 피드백으로 다시 전달합니다:

Your previous Python function failed verification tests. 
The execution harness returned the following error:
AssertionError: Test case verification failed.
...

모델은 트레이스백을 읽고 자신의 정규 표현식이 음수 부호를 캡처하지 못했음을 깨달은 뒤, 수정된 코드를 출력합니다:

import re

def parse_and_sum(text):
...

하네스는 새로운 코드를 실행하여 모든 단언 (Assertion)을 통과하는지 검증하고, 검증된 스크립트를 저장합니다. 수정 루프 (Correction loop)가 성공한 것입니다.

'프롬프트'에서 '하네스'로의 초점 이동

프롬프트 엔지니어링 (Prompt engineering)은 소프트 (Soft)합니다. 이는 컨텍스트 윈도우 (Context window) 내부에서 에이전트의 행동을 제어하려고 시도합니다. 이 접근 방식은 안전성을 정렬 (Alignment) 문제로 취급하며, 모델이 올바르게 행동하기를 기대합니다.

하네스 엔지니어링 (Harness engineering)은 하드 (Hard)합니다. 이는 경계 (Boundary)에서 에이전트의 행동을 제어합니다. 이 접근 방식은 안전성을 아키텍처 (Architectural) 문제로 취급하며, 파괴적인 행동을 물리적으로 불가능하게 만듭니다.

이제 AI 에이전트를 보호하기 위해 지시문 (Instructions)에만 의존하는 것을 멈춥시다. 에이전트가 자율성을 얻을수록, 우리 인프라의 안전성은 우리가 모델 내부에 작성하는 프롬프트가 아니라, 모델 외부에서 구축하는 '제약 조건 (Constraints)'에 달려 있습니다.

Insights

파트 1 - 하네스 엔지니어링 (Harness Engineering)의 필요성

요약

핵심 포인트