▲ 하네스 엔지니어링을 직접 굴리면서 정리한 워크플로 메모

하네스 엔지니어링, 결국 구조가 답이었던 이유

처음에는 솔직히 모델만 바꾸면 해결될 줄 알았다. 더 큰 모델, 더 긴 컨텍스트, 더 비싼 플랜을 쓰면 복잡한 작업도 자연스럽게 끝까지 밀어붙일 거라고 생각했다. 그런데 실제로 길게 굴려 보면 꼭 비슷한 순간이 온다. 초반에는 잘 달리다가도 중간부터 목표를 흐리고, 아직 끝나지 않은 일을 스스로 끝났다고 판단하고, 자기가 만든 결과물을 이상할 만큼 후하게 평가해 버린다. 그걸 몇 번 겪고 나니 문제는 모델의 똑똑함보다 일을 시키는 방식에 있다는 생각이 들었다.

그때부터 제일 크게 바뀐 건 프롬프트를 예쁘게 쓰는 집착보다, 작업 구조를 분리해서 설계하는 쪽이었다. 만드는 역할과 검증하는 역할을 갈라 놓고, 완료 기준을 명시하고, 중간 점검을 넣어 주는 것만으로도 체감이 확 달라졌다. 이걸 두고 어렵게 말하면 하네스 엔지니어링이겠지만, 제가 느끼기엔 결국 AI가 지치기 전에 레일을 깔아 주는 일에 더 가까웠다.

길어진 컨텍스트가 항상 장점으로 남지는 않았다

대화가 길어지면 오히려 안정감이 생길 줄 알았는데, 실제로는 반대인 경우가 적지 않았다. 컨텍스트가 쌓일수록 중요한 요구와 이미 지나간 잡음이 한 공간에 뒤섞이면서 에이전트가 자신 있게 엉뚱한 결론을 내리기 시작했다. 작업 흐름을 길게 이어 가는 능력보다, 어느 시점에 무엇만 남기고 무엇은 버릴지를 정하는 일이 더 중요해졌다. 그래서 이제는 긴 대화 하나로 몰아붙이기보다 상태를 나누고, 체크포인트를 만들고, 작업 목적을 계속 다시 붙여 주는 쪽이 훨씬 낫다고 느낀다.

생성자와 평가자를 분리하니 답변의 톤부터 달라졌다

하나의 에이전트가 만들고, 스스로 검수하고, 스스로 합격 판정까지 내리게 두면 생각보다 금방 관대해진다. 반대로 생성자와 평가자를 분리하면 분위기가 바뀐다. 결과물을 내는 쪽은 속도를 담당하고, 평가하는 쪽은 기준을 담당하는 식으로 역할이 갈린다. 이 분리 하나만으로도 ‘대충 끝낸 것을 완료로 착각하는 문제’가 꽤 줄었다. 결국 제가 얻은 건 더 똑똑한 문장이 아니라, 더 믿을 수 있는 프로세스였다.

프롬프트 엔지니어링보다 시스템 설계 쪽으로 시선이 옮겨 갔다

예전에는 문장을 조금 더 정교하게 다듬는 데 시간을 많이 썼다. 지금은 그보다 작업 단위를 어떻게 쪼개고, 어떤 기준으로 통과시킬지, 실패했을 때 어디서 다시 돌릴지가 더 중요하게 느껴진다. 특히 UI나 풀스택 작업처럼 결과 검증이 가능한 분야에서는 계획자, 생성자, 평가자처럼 책임을 분산해 놓는 편이 훨씬 안정적이었다. 하네스 엔지니어링은 멋진 유행어라기보다, AI를 실제 작업 환경으로 끌고 들어올 때 피할 수 없는 설계 문제라는 쪽이 제 체감에 더 가깝다.

요즘은 새 모델이 나왔다는 소식보다 작업 구조를 어떻게 바꿔야 하는지를 먼저 보게 된다. 모델은 계속 좋아지겠지만, 무너지는 지점은 늘 비슷하다. 그래서 저한테 하네스 엔지니어링은 트렌드가 아니라, AI를 실제 업무에 붙이려면 결국 한 번은 통과해야 하는 현실적인 단계처럼 느껴진다.