왜 harness engineering은 따로 봐야 했을까
Categories:
참고 자료
앞 글에서는 sub-agent를 실행자, skill을 기준서로 구분해야 구조가 선명해진다는 점을 정리했다. 하지만 그렇게 역할과 기준을 나눴다고 해서, 그 구조가 실제로 도움이 되는지는 아직 알 수 없다.
바로 그 지점에서 harness가 등장한다. sub-agent를 실행자로 보고, skill을 기준서로 구분하고 나면 구조가 훨씬 선명해진다. 하지만 그걸로 끝나지는 않는다. 구조를 잘 나눈 것과, 그 구조가 실제로 잘 작동하는지는 또 다른 문제이기 때문이다.
여기서 필요해지는 개념이 harness engineering이다. harness engineering은 에이전트를 반복 가능하게 실행하고 검증하는 틀을 만드는 일이다.
쉽게 말하면 다음을 일관되게 정의하는 작업이다.
- 어떤 입력으로 실행할지
- 어떤 절차를 따를지
- 어떤 결과를 남길지
- 어떻게 성공과 실패를 판단할지
이 개념이 중요했던 이유는, 처음에는 “구조만 잘 나누면 되는 것 아닌가”라고 생각했기 때문이다. 하지만 실제로는 로그, 파일 소유권, 중복 작업 여부, 상위 에이전트의 검증 책임 같은 것들이 함께 관리되지 않으면, 계층형 구조가 도움이 되는지 아니면 복잡도만 늘어났는지 판단하기 어렵다.
이 지점에서 skill과 harness를 섞으면 안 된다는 것도 선명해졌다.
skill은 어떻게 일할지에 대한 기준harness는 그 기준이 실제로 잘 작동하는지 비교하고 검증하는 구조
이 둘은 비슷해 보여도 목적이 다르다. 하나는 작업 방식이고, 다른 하나는 평가 구조다.
작게 시작할 때도 원리는 같다. 고정된 작업 몇 개와 최소 로그만 있어도 충분하다. 중요한 건 처음부터 거대한 플랫폼을 만드는 것이 아니라 반복 실행 + 결과 저장 + 간단한 점수화를 가능하게 만드는 것이다.
이렇게 보고 나면 하네스는 부가 기능이 아니라 운영 기준의 일부가 된다. 특히 여러 번 같은 구조를 시험해보려면, 비교 가능한 기록을 남기는 장치가 먼저 있어야 한다.
여기까지 정리하면 관점이 한 번 더 바뀐다. 질문은 더 이상 “어떤 에이전트를 둘까”가 아니다. 이제는 “이 구조를 실제 변경 흐름 위에 올려놓으면 어떻게 움직여야 하는가”가 더 중요해진다.
그다음부터는 질문이 조금 달라졌다.
- 구조를 나누는 것과 구조를 검증하는 것은 다른 문제다
- 그렇다면 실제 운영 단위는 조직도가 아니라 무엇을 기준으로 잡아야 하는가