최근 알게 된 「하네스 설계 (Harness Design)」라는 사고방식이 상당히 중요했다

수고 많으십니다.

제목 그대로입니다만, 최근 Claude Code를 이용하여 AI 주도 개발 (AI-driven development)을 하고 있는 동기로부터 **하네스 설계 (Harness Design)**라는 말을 배웠습니다.

조사해 보니 상당히 중요한 사고방식이자 설계라는 생각이 들어서, 이번에는 하네스 설계에 대해 정리해 보려고 합니다.

대략적으로 말하면, 다음과 같은 사고방식입니다.

AI가 망가뜨렸을 때 검지할 수 있는 메커니즘을 먼저 만든다

AI에게 자유롭게 코드를 쓰게 한다

↓

망가지면 검지한다

↓

안전하게 되돌릴 수 있다

를 먼저 만들어 두는 것입니다.

최근의 AI는 술술, 스피디하게 코드를 작성해 줍니다.

하지만 그 반면 언뜻 보기에는 자연스럽고 올바른 것 같은 코드를 쓰는 경우가 허다합니다.

간단한 예로 들자면

• null 체크 누락
• edge case (예외 케이스) 미고려
• 타입 붕괴
• 기존 사양 파괴

등을 아무렇지 않게 저질러 옵니다.

게다가 최근에는 코드 생성뿐만 아니라,

• API 실행
• 커맨드 (Command) 실행
• DB 조작

까지 AI에게 맡기는 케이스도 늘어나고 있다고 생각합니다.

실제로 아는 엔지니어가 Claude에게 API 사양 조사를 시켰을 때도, 운영 (Production) API에 대하여,

위조된 토큰이 포함된 curl을 실행하려고 했었다고 합니다. 그냥 통째로 맡기는 것은 위험하다고 느꼈습니다.

물론 악의가 없다는 것은 알고 있고, 목적 달성을 위해 최단 수단을 선택했을 뿐이라고 생각합니다.

하지만 인간 측에서 보면 위험할 뿐입니다.

그렇기 때문에,

AI에게 자유롭게 구현하게 한다

↓

인간이 열심히 리뷰한다

가 아니라,

망가진 것을 검지하는 메커니즘을 먼저 만든다

라는 사고방식이 중요해집니다.

이것이 하네스 설계의 필요성이 아닐까 생각합니다.

예를 들어, AI에게 API 사양 조사를 맡겼다고 가정해 봅시다.

그때 AI가 다음과 같은 커맨드를 생성하고, 그대로 실행하려고 하는 케이스가 있습니다.

curl https://api.example.com/users \
-H "Authorization: Bearer xxx"

위의 내용은 「API 동작 확인을 하고 싶다」라는 목적을 달성하기 위해, 최단으로 실행할 수 있을 법한 방법을 선택한 것이라고 합시다.

하지만 인간 측에서 보면 위험한 행위일 뿐이므로, 이러한 사고를 방지하기 위해 다음과 같은 제약을 미리 마련해 둘 필요가 있습니다.

• 운영 환경으로의 통신을 금지한다
• sandbox 환경만 건드릴 수 있도록 한다
• read only 권한으로 제한한다
• curl 실행 전에 확인 단계를 거친다

예를 들어, AI에게 develop 브랜치에서 작업 브랜치를 따서 push 해달라고 명령했다고 가정해 봅시다.

이때 AI가 작업 브랜치를 생성했지만, upstream이 develop인 상태 그대로여서, push 시 의도치 않게 develop에 반영되어 버리는 케이스가 있습니다.

인간이 알아차리면 막을 수 있겠지만, AI 주도 개발에서는 커맨드 실행 속도가 빠르기 때문에 매번 육안으로 확인하며 멈추는 것은 현실적이지 않습니다.

따라서 다음과 같은 제약을 미리 마련해 둘 필요가 있습니다.

• develop / main으로의 직접 push를 금지한다
• push 전에 현재 브랜치와 upstream을 확인한다
• 보호된 브랜치 (Protected branch)로의 push 커맨드를 차단한다
• Bash 툴 실행 전에 기계적인 체크를 거친다

예를 들어, AI에게 이 버그만 고쳐줘라고 명령했다고 가정해 봅시다.

하지만 이 버그만 고쳐달라는 요청에 대해, 다음과 같은 관계없는 수정까지 시작하는 케이스가 있습니다.

• 함수명 변경
• 디렉토리 구성 변경
• 공통화
• import 정리
• formatter 적용 등...

AI로서는 「코드를 깔끔하게 하는 편이 좋다」라는 판단으로 자연스럽게 수행하는 것이지만,

결과적으로 1줄의 수정이어야 할 것이 대량의 diff (차이점)가 되어 리뷰 불능 상태가 되는 일이 결과적으로 일어날 수 있습니다.

따라서 이러한 사고를 방지하기 위해서는 다음과 같은 제약이 역시 필요해집니다.

• diff 사이즈 제한을 둔다
• 지정된 파일 이외의 변경을 금지한다
• formatter-only 변경을 거부한다
• AI용 리뷰 gate (관문)를 둔다
• 불필요한 rename (이름 변경)을 검지한다

변경 행수가 일정 이상이면 정지하거나, 지정 외 파일을 변경하면 에러를 내거나, 파일 삭제나 운영 환경에 간섭하는 커맨드 등을 기계적으로 판정함으로써,

AI가 쓸데없는 일을 시작한다

↓

하네스가 검지한다

↓

실행 전에 멈춘다

라는 형태로 만들 수 있습니다.

아직 저 자신도 이해 및 설계 과정 중에 있습니다만, AI 주도 개발 (AI-driven development)에서는 **「AI에게 올바르게 쓰게 하는 것」**보다 **「망가졌을 때 멈출 수 있는 것」**이 더 중요하다는 것을 느꼈습니다.

AI는 확실히 편리한 도구이지만, 그 편리함을 안전하게 사용하기 위해서는 인간 측의 제약 설계 (Constraint design)가 상당히 중요해집니다.

앞으로 AI를 개발 프로세스 (Development flow)에 편입시키는 과정에서, 하네스 설계 (Harness design)는 피할 수 없는 사고방식이라는 생각이 들었습니다.