많은 사람들이 최근 들어서 하네스 엔지니어링에 관심을 많이 가지고 있는 것 같다.
나 역시도 이에 관심을 많이 가지고 있고 지금 현재 진행 중인 프로젝트에 나만의 하네스를 만들어서 적용해보았다.
0번을 제외하고 요약하자면 notion에 있는 api 명세를 불러와서 설계 후 구현을 하는데 각 과정을 서로 다른 에이전트가 진행하고 이를 오케스트레이터가 총괄하도록 하며 마지막에 verify.sh를 실행해서 코드를 테스트하는 하네스이다.
추가적으로 프로젝트의 정보에 대해서 단일 진심 공급원도 제공하고 있어서 프롬프트는 너무 정교하게 작성하지 않아도 Agent가 잘 구현해주지 않을까라는 생각을 가지고 있었다.
하지만 오늘 겪은 아주 간단한 api 구현에서 프롬프트의 중요성에 대해서 다시 한 번 생각하게 되었다.
상황은 다음과 같다.
bandid로 band를 불러오는 GET 요청에 대한 api를 구현하는 것이었다. 나는 아주 단순 구현이라고 생각이 들어서
"bandid 기준으로 band를 조회하는 api를 구현해줘 notion 명세 부터 작성하자" 이런 프롬프트를 입력했다.
지금 현재 notion에 api는 다음과 같은 형태로 정리되어있다.
부가 설명을 좀 하자면 #뒤에 번호는 api의 고유 넘버링으로 ai와의 원활한 소통을 위해서 붙여놨다.
그래서 나는 당연히 ai가 새로운 api의 번호는 현재 존재하는 api의 마지막 번호인 69다음인 70을 붙여서 api 명세를 작성할 것으로 생각했는데 현재 band api의 13번 다음인 14번으로 api를 만들었다.
이 부분에서 아직 내가 구축한 하네스가 완벽하지 않음을 느꼈다.
그래서 급하게
"notion 명세에는 왜 적어두지 않는거야?
user는 다 적었잖아
그리고 api 이름에 수정한 다음 오늘날짜로 바꿔"
라는 프롬프트를 적었더니 AI가 모든 notion의 명세를 검토하고 동기화하는 작업을 시작했다...
난 분명 band에서 bandid로 get하는 api만을 명세화 하기를 바란건데 여기서도 나의 하네스의 허점을 발견했다.
지금 하네스는 명확한 워크 플로우를 가지고있다
1. 명세 확인 2. 명세 동기화 3. 설계 4. 설계 보완 5.구현 6.QA
이러한 명확한 워크 플로우에 나의 프롬프트가 구조적으로 잘못된 프롬프트 였던 것 같다.
이로서 하네스가 구축이 되어있더라도 하네스에 벗어나는 프롬프트는 예상치 못한 결과를 초래한다는 것을 배울 수 있었다.
또한 한 번 하네스를 구축하고나면 강제적으로 해당 하네스에 맞춰서 모든 작업이 진행 되기 때문에 항상 그 무거운 워크 플로우를 다 따라가야한다는 단점도 느꼈다. 오늘의 경험을 통해서 크게 느낀 점은 2가지 인 것 같다.
1. 하네스 버전 관리도구가 있었으면 좋겠다. 모든 작업이 무거운 하네스로 이루어질 필요가 없고 가끔은 경량화 된 하네스를 선택해서 사용할 수 있으면 좋을 것 같다. 이런 하네스 관리 툴을 만들어보면 좋을 것 같다는 생각이 들었다.
2. 프롬프트를 입력할 때 하네스가 잘 보완해주겠지라는 믿음을 가지지 말고 여전히 최대한 잘 기술하는게 중요한 것 같다. 물론 내가 아직 부족해서 그럴 수도 있지만 앞으로는 프롬프트를 조금 더 신중히 작성해야겠다.