티스토리 뷰
OpenAI에서 주장하는 하네스 엔지니어링으로 얻을 수 있는 장점을 정리해보면 다음과 같다.
- 엔지니어링 속도와 처리량 확대
- 에이전트가 안정적으로 일할 수 있는 환경 설계
- 명확한 의도·범위·아키텍처 규칙 제공
- 테스트·리뷰·평가 기반 피드백 루프 구축
- 인간의 역할을 직접 구현자에서 오케스트레이터로 전환
또 최근 하네스 구축 플러그인을 보고 직접 구축하다보면 공부가 될 것 같다는 생각에 시작하게 되었다.
https://github.com/revfactory/harness/blob/main/README_KO.md ( 클로드 기반 )
하네스 엔지니어링 시 작업순서는 이와 같다.
1. 요구사항에 대한 프로젝트의 규모 파악.
먼저 해당 프로젝트의 규모를 파악한 후 Small, Medium으로 분류한다.
2. 에이전트 아키텍쳐 설계
프로젝트 규모에 따라 어떻게, 어떤 구조로 작업할 지 결정한다.
Small의 경우 단일 에이전트, Medium의 경우 멀티에이전트로 작업한다.
큰 프로젝트에서 멀티에이전트를 사용하는 이유는 컨텍스트 오염을 방지하기 위함이다.
오히려 작은 프로젝트라면 단일에이전트를 사용하는 편이 훨씬 효율이 좋다.
기획자가 설계도 하고 구현도 하고 테스트도 하는 꼴이기 때문이다.
3. 작업 순서
요구사항 파악 -> 설계 -> 구현 -> 테스트 순
요구사항 파악 시 테스트에 대한 기준표도 작성한다.
테스트까지 완료되면, 마지막에 해당 기준표로 검증하고 사이클이 끝난다.
또한 각각의 단계에서 명시된 규칙을 잘 지켰는지 체크리스트를 만들어 체크한다.
에이전트는 자가 판단 후 규칙을 무시하고 작업을 진행하는 경우가 있다.
md파일에 "꼭 지켜야 하는 규칙"과 같이 명시하거나 체크리스트를 두어 이를 예방할 수 있다.
py로 스크립트를 만들어 실행시키는 방법도 있지만 다행이 위의 두가지만으로 규칙을 수행하도록 할 수 있었다.
4. 시간과 토큰 효율
- 멀티 에이전트 환경 구축 시 각각의 에이전트별 모델을 별도로 두어, 어려운 작업인 경우는 고급모델을, 그렇지 않은 작업에는 중저급 모델을 스폰하도록 하였다.
- 멀티 에이전트 환경에서 구현 시, 공통구현이 끝나고 나면 각각의 피쳐별 서브에이전트를 스폰하여 병렬로 작업하여 작업속도를 줄인다.
- 터미널에 필요이상의 내용들을 출력하는 경우 토큰사용량이 늘어난다. 그렇기에 핵심메시지만 표시하도록 하였다.
- md파일의 크기가 커질 때 해당 문서의 핵심이 에이전트에게 흐려지기에, 관련된 규칙들은 별도의 md로 분리하고 이의 주소를 명시한다.
구축 후기
iOS에서의 클린아키텍쳐(or 아키텍쳐 설계)와 비슷하다고 느꼈다.
작은 프로젝트에서 하네스 구축은 오히려 독이 될 수 있다.
하네스 엔지니어링 없이 단순히 진행하게 된다면 적은 토큰량과 빠른 시간에 작업할 수 있다.
하네스 엔지니어링으로 멀티에이전트들을 스폰하고 규칙을 적용시키면 작업 히스토리들이 모두 남으며 개발자의 통제하에 에이전트들이 작업하도록 할 수 있다.
장점과 단점이 명확한데,
큰 프로젝트에서 하네스없이 진행하게 된다면, 건드리지 말아야할 피쳐까지 모두 수정해버리고 토큰을 마구잡이로 써버린 에이전트와 마주하게 될 것이다. 결과로 A화면에 대한 작업만 지시했는데, B화면까지 완전 변해 버린다.
이는 유지보수면에 있어 최악이 아닐 수 없다.
단일 에이전트에서 구현과 테스트까지 작업할 시 작업한 내용에 대해선 항상 후하게 평가하는 경향이 있기에 작업물의 완성도도 낮을 수 있다.
작은 프로젝트에서 하네스를 적용시킨다면, 몇개 없는 간단한 피쳐들에 모든 작업들을 꼼꼼히 체킹하고 문서를 남길 것이고 서브에이전트들을 스폰할 것이다. 이는 더 많은 시간, 토큰을 사용하게 만든다. 즉 "비용"이 필요 이상으로 들어가게 된다.
MVC, MVI, MVVM(-C), VIPER, RIBS..
iOS개발에 있어 수많은 아키텍쳐들이 있고 이를 결정하는 기준은 대부분 프로젝트의 규모였다.
앞으로 하네스또한 유지보수(비용절약), 개발 용이성을 목적으로 둔 여러가지 아키텍쳐들이 나오게 될 것 같다.
Lite Harness, Middle Harness, Full Harness... 반대로 이 하네스는 언제든 제거가 가능하고 다른 하네스를 끼워넣기 용이한가? 까지.
직접 개발에서 바이브코딩으로 완전히 전환되고 시간이 흐르더라도 어떤 구조를 채택하는가에 대한 선택은 여전히 남아있을 것이다.
AI시대에서 살아남는 개발자가 갖춰야할 것들 중 "이러한 판단도 잘 할 수 있는가?"가 포함될거라 생각한다.
+ Codex Plus버전을 사용하였기에 5시간에 한번씩 오는 토큰 리프래시를 기다리며 작업하였고, 이 플랜을 사용했기에 토큰사용량을 줄이는 것에 많이 집중할 수 있었던 것 같다.
실험실 실험쥐들...