1. Agent ≈ Model + Harness.
기본적으로 모델은 입력을 받아 출력을 만든다.
파일을 읽거나 명령을 실행하라는 요청을 만들 순 있지만, 그 출력만으로 실제 환경의 상태가 바뀌진 않는다.
AI로 처음 코딩하던 때를 생각해 보면, 그 사이에는 항상 사람이 있었다.
- 어떤 파일을 보여줄지 고르고, 필요한 부분을 복사해 프롬프트에 붙여 넣는다.
- 모델이 출력한 코드를 에디터로 옮기고 직접 테스트한다.
- 에러가 발생한 경우, 그 에러를 복사해서 다시 모델에게 전달한다.
그런데 오늘날, 상당 부분이 소프트웨어로 옮겨졌다.
모델이 사용할 도구를 연결하고, 실행 결과를 다시 모델의 입력으로 돌려주면서 반복적인 실행 루프를 만들었다.
우리가 흔히 쓰는 Claude Code나 Codex 같은 코딩 에이전트들은 이런 구조 위에서 동작한다.
2. 에이전트의 자율성에는 통제가 따른다.
흔히 에이전트를 두고 "AI가 알아서 한다"고 말한다.
하지만 그 추상적인 표현 안에는 상당히 구체적인 것들이 요구된다.
- 어떤 정보를 보여줄 것인가
- 어떤 도구를 사용하게 할 것인가
- 무엇을 허용하고 무엇을 막을 것인가
- 작업 상태는 얼마나, 어떻게 이어갈 것인가
- 결과를 확인하는 방법은 무엇이며, 종료 기준은 무엇인가
이런 것들을 담당하는 실행 구조가 하네스다.
하네스는 모델과 환경을 연결하는 것에서 시작하지만, 단순한 Tool Calling에서 그치지 않는다.
컨텍스트와 상태를 관리하고, 실행 흐름과 권한을 통제한다.
실패를 복구하고 결과를 검증한다.
에이전트의 자율성이 커졌다는 것은, 단순히 사람을 대체한다는 의미가 아니다.
오히려 사람이 수행해 온 판단 중, 어떤 것을 시스템에 명시적으로 구현해야 하는지가 중요해졌다.
3. 하네스 엔지니어링은 단순한 지침 작성이 아니다.
하네스 엔지니어링은 실행 구조를 설계하고, 실제 동작을 관찰하고, 필요에 따라 변경하는 일이다.
AGENTS.md나 Skills만으로는 하네스 엔지니어링을 대변하기 어렵다.
확률을 높이는 것과 실제로 확인하고 막는 것은 다르기 때문이다.
예를 들어, 에이전트가 코드를 수정한 뒤 반드시 통과해야 하는 테스트가 있다고 하자.
AGENTS.md에 "코드 수정 후 테스트를 실행한다"고 적을 수 있다.
이건 분명 모델이 원하는 행동을 하도록 유도한다.
하지만 실제로 테스트를 실행했는지, 그 결과가 통과였는지를 보장하지는 않는다.
우리는 에이전트 루프 안에서 실제 테스트를 실행하고 결과를 다시 받도록 할 수 있다.
모델은 자기 판단이 아니라 실제 환경에서 얻은 결과를 바탕으로 다음 행동을 결정할 수 있게 된다.
더 나아가, 같은 테스트를 Required CI Check로 둘 수 있다.
테스트가 실패하면 단순히 결과를 알려주는 것에서 그치지 않고 Merge 자체를 막는다.
같은 목표를 향하더라도 세 방식의 역할은 다르다.
- Guide는 원하는 행동을 유도한다.
- Sensor는 실제 상태와 실행 결과를 관찰해 Verification에 필요한 정보를 제공한다.
- Gate는 조건을 만족하지 못하면 다음 단계로 넘어가는 것을 막는다.
좋은 하네스는 모든 문제를 지침으로 해결하려 하지 않는다.
4. 기존 DX의 유산은 Verification의 출발점이 된다.
결과를 검증하기 위해 모든 기준을 처음부터 새로 만들 필요는 없다.
개발 조직 안에는 이미 자동화된 검증 장치가 존재하기 때문이다.
대표적으로 Unit Test, Integration Test, Build, Type Check 등이 있다.
기존에는 개발자가 코드를 작성한 뒤, 이 결과를 확인하고 수정했다.
그런데 에이전트에서도, 같은 검증 과정을 충분히 재사용할 수 있다.
달라지는 것은 검증 기준이 아니라, 그 결과를 받아 다음 행동을 결정하는 주체다.
그런데 여기서 더 중요한 지점은, 예시로 든 검증 기준 모두 코드로 명확히 판정할 수 있는 것들이란 점이다.
5. Jev가 흥미로운 이유는 여기에 있다.
모든 검증 기준을 테스트나 명시적인 조건문으로 작성할 수 있는 건 아니다.
실제 변경이 자연어로 주어진 요구사항을 충족했는지는 코드만으로 표현하기 어렵다.
이런 판단에 Jev를 사용한다면 어떨까.
Jev는 일반적인 LLM처럼 비정형 텍스트를 출력하는 대신, 미리 정해 둔 형태의 판단과 확률을 반환한다.
즉, 코드로 작성하기 어려웠던 의미 기반 판단을 프로그램의 Control Flow 안에서 사용할 수 있게 한다.
물론 이런 모델 기반 판단이 기존의 코드 기반 검사와 동일하다고 볼 수는 없다.
모델의 판단에는 불확실성이 따르기 때문이다.
6. Verification과 Eval은 무엇이 다른가.
Verification은 개별 결과가 주어진 기준을 만족하는지 확인하는 작업이다.
"이번 결과가 기준을 만족하는가?"
코드 변경 후 테스트가 통과했는지를 확인하는 것이 대표적인 Verification이다.
Eval은 조금 다른 질문을 한다.
"이 에이전트가 실제 작업을 얼마나 잘 수행하는가?"
이건 하나의 결과만 확인해서는 답하기 어렵다.
대표적인 Task 집합과 Grader를 준비하고, 여러 번 실행한 결과를 모아 비교해야 한다.
그 비교에는 성공률이나 비용, 지연 같은 지표가 활용될 것이다.
Verification이 개별 결과의 적합성이라면, Eval은 여러 작업과 실행을 통해 에이전트를 측정하는 절차에 가깝다.
7. Eval은 AX 과정에서 성장한다.
실제 업무의 성공 기준을 처음부터 완벽히 정의하기는 어렵다.
초기에는 도메인 전문가가 대표적인 작업 몇 가지와 그에 대한 성공 기준을 만들어 줄 수 있다.
하지만 실제 업무에 해당 에이전트를 투입해 보면, 처음에는 예상치 못했던 신호가 쌓이기 마련이다.
에이전트의 결과를 그대로 승인하기도, 일부를 수정해 사용하기도, 아예 거부하기도 한다.
Human-in-the-loop를 단순한 승인 절차 정도로 볼 필요는 없다.
기존 Eval이 놓치고 있던 실패 유형을 발견할 수 있는 신호로 보아야 한다.
반복되는 사례는 재현 가능한 Task로 만들고, 성공 기준과 Grader를 추가해 Regression Eval에 포함할 수 있다.
이 과정을 반복하면 실제 업무에서 발생한 신호가 다시 하네스를 개선하는 데이터가 된다.
8. 하네스 엔지니어링은 새로운 역량이다.
결국 하네스 엔지니어링은 에이전트에 이것저것 계속 추가하는 일이 아니다.
실패를 관찰하고, 재현 가능한 형태로 만들고, 원인을 진단해 필요한 조치를 취한다.
그 조치가 실제 개선으로 이어졌는지는 Eval을 통해 확인한다.
효과가 없다면 되돌리기도 한다.
모델이나 도구가 발전해 더 이상 필요하지 않은 하네스는 미련 없이 제거한다.
에이전트를 활용하는 개발이 늘어날수록, 에이전트의 실행 구조를 설계하고 검증하는 역량도 중요해진다.
그리고 아이러니하게도, 그럴수록 도메인 지식의 중요성도 함께 커진다.
지금까지 이야기한 것들을 제대로 결정하려면, 결국 해당 업무를 알아야 하기 때문이다.