프롬프트 설계는 그만: Eval‑First 방식으로 25개 알고리즘 버전을 자동 배포

Source: Dev.to

tl;dr — 에이전트는 작은 수정에는 능숙하지만 “이 알고리즘을 더 좋게 만들어라”는 작업에는 형편없다. 왜냐하면 모든 변경이 개별적으로는 좋아 보이지만 다른 곳에서는 조용히 퇴보하기 때문이다. 우리는 AI 하니스—불변 테스트 세트, 다축 루브릭, 스윕 도구, 독립 리뷰어 에이전트, 인간이 볼 수 있는 평가 인터페이스, 지식 영속성 레이어—를 구축했다. 이 하니스 덕분에 에이전트가 실제 알고리즘을 자율적으로 반복 개선할 수 있게 되었고, 인간은 적절한 단계에서 직관을 제공한다. 13일 동안 색상 양자화 파이프라인을 25버전이나 배포했으며(깃 로그는 거짓말을 하지 않는다); 가장 최근 6버전은 하니스 자체가 업그레이드된 직후 5일 만에 배포되었다. 속도를 안전하게 만든 것은 프롬프트나 완전 자동화가 아니라 하니스였다.

두 가지 중요한 전제는 이 글의 나머지 부분을 이해하는 데 영향을 준다:

• 이것은 부업 프로젝트이며, 저녁·주말·가끔 점심시간에 진행한 작업이다. 전담 팀이나 전일제 스프린트가 아니다.
• 저자는 코드를 한 줄도 읽을 수 없는 프로덕트 매니저다. 실제 양자화 파이프라인의 모든 코드는 AI 에이전트가 작성했으며, 저자의 기여는 하니스, 가설, 그리고 인간 눈으로 하는 리뷰 단계이다.

25개의 버전을 그 강도와 저자에게서 얻을 수 있었던 이유는 하니스가 감시를 담당했기 때문이다. 루프가 한 번 설정되면 각 반복은 “터미널을 열고, 평범한 영어로 가설을 제시하고, 대시보드를 한눈에 보고, 승인하거나 되돌리기” 정도다. 오히려 이 두 전제가 하니스를 만들 이유를 가장 강하게 뒷받침한다: 비엔지니어가 실제로 가지고 있는 짧은 시간 창을 전일제 컴퓨터 비전 엔지니어가 필요로 하는 알고리즘 진행으로 전환해 주기 때문이다.

제품은 BMBrick—무료 웹 기반 도구로, 사진을 레고 스타일의 픽셀 모자이크로 변환한다. 강아지 사진이나 결혼식 사진을 업로드하면 미리보기, 인쇄용 PDF 청사진, 그리고 각 격자 위치에 정확히 맞는 레고 1×1 브릭 색상 리스트를 받아 실제로 브릭을 구매해 조립할 수 있다.

이 글에서 튜닝하는 알고리즘은 최종 모자이크의 각 픽셀에 어떤 레고의 약 42가지 물리적 1×1 플레이트 색상을 배치할지 결정하는 색상 양자화 파이프라인이다. 제약이 바로 이 작업을 어렵게 만든다: 1,600만 개의 가능한 RGB 입력값을 42개의 물리적 브릭 색상에 매핑해야 하며, 출력은 실제로 조립했을 때 원본 사진과 비슷하게 보여야 한다. 매핑을 잘못하면 피부톤이 뚜렷한 색대역으로 변하고, 눈이 인식되지 않으며, 배경이 점처럼 부서져서 완성된 결과물이 사진 속 인물을 알아볼 수 없게 된다.

아래에 소개하는 하니스 패턴은 이미 작동하던 부분을 깨뜨리지 않으면서 양자화 파이프라인을 지속적으로 개선하기 위해 우리가 만든 구조다. 이 패턴은 일반화 가능하며, 레고 모자이크는 단지 적용 사례일 뿐이다.

몇 달 동안 에이전트와 페어 프로그래밍을 해왔다면, 대략적인 흐름은 다음과 비슷할 것이다:

• 리팩터링 및 UI 작업: 에이전트가 스타다. 결과를 설명하면 파일을 수정하고, 테스트를 실행하고, 배포한다.
• 문서화: 문제 해결. 에이전트는 대부분 인간보다 더 나은 README를 쓴다.
• 알고리즘 튜닝: 재앙.

재앙 모드에 대해 구체적으로 설명한다. “이 이미지에서 출력을 더 깔끔하게 만들어라”라고 에이전트에 요청한다. 에이전트는 매끄럽게 하는 파라미터를 올리는 등 무언가를 시도한다. 보여준 이미지에서는 실제로 깔끔해 보인다. 에이전트는 커밋하고, 우리는 다음 단계로 넘어간다.

하지만 3주 후에 그 매끄럽게 만든 변경이 우리가 보지 못한 다른 7개의 이미지에서 퇴보를 일으킨 것을 발견한다. 에이전트가 만든 “개선” 중 6개가 같은 문제를 일으킨다. 코드베이스는 이제 자신 있게 배포된 작은 트윅들로 가득 차며, 하나씩 되돌려야 하는 상황이 된다.

이는 에이전트의 실패가 아니다. 하니스의 실패다. 구체적으로는 에이전트가 다른 부분을 퇴보시켰다는 사실을 알 방법이 없었기 때문이다. 에이전트에게 더 친절히 묻는다고 해서 해결되지 않는다. 더 비싼 프롬프트 엔지니어링도 해결되지 않는다. 문제는 구조적인 것이다.

해결책은 변경이 배포되기 전에 에이전트가 만족해야 하는 평가 하니스다. 이 글이 바로 그 하니스에 관한 이야기다.

에이전트 자율성 스펙트럼에는 세 가지 단계가 있다:

1. 프롬프트 엔지니어링 — 완벽한 프롬프트를 만들고, 에이전트는 한 번 실행, 우리는 출력을 확인하고 프롬프트를 반복한다. 일회성 생성에는 괜찮지만, 누적되는 작업에는 끔찍하다.
2. 완전 에이전트 자율성 — 에이전트를 레포에 풀어놓고 기대한다. 그린필드 프로토타입에는 통하지만, 프로덕션 코드에서는 붕괴한다. 에이전트는 언제 악화되는지 감지할 방법이 없기 때문이다.
3. 하니스 매개 자율성 — “에이전트가 변경을 제안한다”와 “변경이 배포된다” 사이에 자동 체크포인트를 만든다. 이 체크포인트가 바로 하니스다. 에이전트는 원하는 만큼 빠르게 반복할 수 있지만, 하니스를 통과한 변경만이 살아남는다. 핵심은 하니스가 두 명의 리뷰어—처리량을 담당하는 AI 리뷰어와 직관을 담당하는 인간 리뷰어—를 가지고 있다는 점이며, 평가 결과는 두 리뷰어 모두 활용할 수 있게 설계된다.

우리는 13일 동안 레고 색상 양자화 파이프라인을 옵션 3으로 운영했다. 25개의 배포된 버전과 11개 이상의 문서화된 거절 실험이 있었다. 가장 눈에 띄는 연속은 v18 → v19가 같은 날 배포된 뒤, v22 / v23 / v24 / v25가 다음 4일에 걸쳐 배포된 경우다—하니스 자체가 업그레이드된 직후 5일 만에 6버전이 나온 것이다. 같은 하니스는 인간 코드 리뷰에서 놓친 퇴보, 한 이미지에서는 잘 작동했지만 여섯 다른 이미지에서는 깨진 파라미터 변경, 그리고 “AI가 이 코드를 더 깔끔하게 고쳐줬다”는 시도에서 발생한 복합 부작용 등을 잡아냈다.

이제 레시피를 소개한다.

작동하는 하니스를 만들기 위해서는 다음 다섯 가지 구성 요소가 필요하다. 각각은 명백하지만, 조합이 루프를 작동하게 만든다.

1. 대표 입력 세트를 선택하고 튜닝 반복 중에는 절대 변경하지 않는다.

   • 우리 파이프라인의 테스트 세트는 13장의 사진이다: 인물·반려동물 초상 4장, 다중 피사체 초상 2장, 결혼식 장면 2장, 풍경 2장, 클로즈업 객체 1장, 의도적으로 흐릿하게 만든 부정 대조 1장, 흑백 레퍼런스 1장. 각각은 특정 실패 모드(그라디언트 밴딩, 피부톤 팔레트 압박, 배경 잡음 등)를 강조하도록 선택했다.

   테스트 세트에 관한 두 규칙

   • 새로운 케이스는 주 버전 사이에만 추가하고, 반복 중에는 절대 추가하지 않는다. 반복 중에 테스트 세트를 바꾸면 에이전트(그리고 우리)가 승리를 골라내기 쉬워진다.

   • 각 케이스는 무언가를 구체적으로 스트레스해야 한다. “입력을 더 많이”라는 식으로 대량 추가하지 말고, 서로 다른 실패 모드를 드러내는 입력을 골라라. 우리의 13개는 서로 거의 직교(orthogonal)하게 어떤 부분을 깨는지 구분된다.

   • 최소 유용 테스트 세트는 5개 정도일 수 있다. 20개를 넘으면 실제 데이터 분포보다 테스트 세트 자체에 최적화하게 된다.

2. 평가를 하나의 숫자로 축소하지 말라. 하나의 지표만 있으면 에이전트는 그 숫