AI 쪽 글을 좀 읽어보신 분이라면 Lilian Weng이라는 이름이 낯설지 않으실 거예요. OpenAI에서 안전 연구를 이끌었고 지금은 Thinking Machines Lab의 공동창업자로 있는 연구자인데요, 개인 블로그 'Lil'Log'에 올라오는 글마다 해당 주제의 교과서 취급을 받는 걸로 유명해요. 그런 그가 이번에 들고 나온 주제가 '하네스 엔지니어링(Harness Engineering)', 그러니까 AI 시스템이 스스로 개선되도록 만드는 틀을 어떻게 설계할 것인가예요.
하네스가 뭐냐면
하네스(harness)는 원래 말을 마차에 연결하는 마구를 뜻해요. AI 맥락에서는 모델 그 자체를 뺀 나머지 전부, 즉 모델을 실제 일에 '연결'해 주는 장치들을 가리켜요. 에이전트가 쓸 수 있는 도구(파일 읽기, 코드 실행, 웹 검색 등)의 설계, 긴 작업에서 어떤 정보를 컨텍스트에 넣고 뺄지 관리하는 로직, 세션을 넘어 기억을 유지하는 메모리, 결과가 맞는지 확인하는 검증 루프까지가 전부 하네스예요.
왜 이게 중요하냐면, 같은 모델이라도 하네스에 따라 성능이 완전히 달라지거든요. 코딩 에이전트 벤치마크에서 동일한 모델이 어떤 스캐폴드(작업 틀)를 쓰느냐에 따라 점수가 수십 퍼센트포인트씩 차이 나는 건 이미 잘 알려진 사실이에요. 모델은 엔진이고 하네스는 차체라고 보면 돼요. 아무리 좋은 엔진도 바퀴에 동력을 제대로 전달하지 못하면 앞으로 못 가는 거죠.
자기개선 루프의 핵심은 '검증'이에요
이 논의의 핵심은, 모델의 가중치를 다시 학습시키지 않아도 하네스를 잘 설계하면 시스템 차원의 자기개선(self-improvement) 루프를 만들 수 있다는 거예요. 구조는 이래요. 에이전트가 작업을 시도하고, 그 결과를 검증기(verifier)가 채점하고, 실패했다면 왜 실패했는지가 피드백으로 돌아오고, 에이전트가 그걸 반영해서 다시 시도하는 순환이에요.
여기서 제일 중요한 부품이 검증기예요. 코딩이 에이전트 분야에서 제일 빨리 발전한 이유가 바로 이건데요, 코드에는 컴파일러와 테스트라는 확실한 채점자가 있거든요. 테스트가 통과하면 성공, 실패하면 실패라고 기계가 판정해 주니까 사람 개입 없이 루프가 돌아가요. 반면 '좋은 기획서 쓰기'처럼 정답을 채점하기 어려운 일은 루프를 돌리기가 훨씬 어렵죠. 그래서 하네스 엔지니어링의 상당 부분은 결국 '이 작업의 성공을 어떻게 기계가 판정 가능하게 만들 것인가'라는 문제로 수렴해요. 여기에 실패 사례를 메모리에 축적해서 다음 시도에 반영하거나, 에이전트가 자기 결과물을 스스로 비평(self-critique)하게 하는 장치가 더해지면, 시간이 지날수록 점점 잘하는 시스템이 되는 거예요.
프롬프트 → 컨텍스트 → 하네스
업계 흐름을 보면 무게중심 이동이 뚜렷해요. 2023년엔 '프롬프트 엔지니어링'(질문을 잘 쓰는 법)이 화두였고, 그다음엔 '컨텍스트 엔지니어링'(모델에게 어떤 정보를 어떻게 넣어줄 것인가)으로 넘어갔는데, 이제는 그걸 포함한 시스템 전체의 설계, 즉 하네스 엔지니어링이 승부처가 됐어요. Claude Code 같은 코딩 에이전트들이 좋은 예인데, 이런 제품의 경쟁력은 모델만큼이나 도구 설계와 피드백 루프의 완성도에서 나오거든요.
한국에서 에이전트 기반 제품을 만들고 있다면 시사점이 분명해요. 모델을 최신으로 갈아끼우는 것보다, 에이전트가 자기 결과를 검증할 수 있는 환경을 만드는 데 투자하는 게 효과가 클 수 있어요. 좋은 테스트 스위트, 명확한 도구 인터페이스, 실패 로그를 다시 활용하는 구조 같은 것들요. 재밌는 건 이게 결국 좋은 소프트웨어 엔지니어링 관행과 겹친다는 거예요. 테스트를 잘 짜둔 코드베이스가 AI 에이전트도 잘 쓰는 코드베이스거든요.
정리하면, AI 시스템의 성능은 이제 모델 혼자가 아니라 모델을 감싼 하네스가 함께 결정하고, 자기개선의 열쇠는 '검증 가능한 피드백'이라는 거예요. 여러분이 만드는 서비스에는 에이전트의 성공과 실패를 기계적으로 판정할 방법이 있나요? 없다면 그걸 만드는 게 첫걸음일지도 몰라요.
🔗 출처: Hacker News