하네스 논쟁 : 만능 하네스는 없다

서론

최근 며칠간 스레드 SNS에서는 오픈소스 AI 하네스 툴을 두고 여러 논쟁이 이어졌습니다. 여러 하네스 오픈소스 개발자와 사용자들이 각자의 경험을 공유하고 여러 의견을 주고받았습니다. 물론 이 과정에서 일부 글은 특정 프로젝트를 공격적인 표현으로 비판하기도 했습니다.

여러 글을 읽으면서 한편으로는 이런 생각이 들었습니다.

단편적인 사용 경험만으로 하네스 오픈소스 프로젝트 전체를 공격하고 있는 것은 아닐까?

저도 GPT-5.6 를 사용하면서 Oh-My-Codex(OMX)를 하네스 툴로 잘 사용하고 있습니다.

특히 $ralplan, $ultragoal을 많이 사용했고 두 기능이 만들어 내는 계획, 그리고 결과물에 대해서도 대체적으로 만족했습니다. 하지만 최근에는 작업을 하는 데 있어 $ultragoal은 사용하지 않고 Codex 자체적으로 지원하는 /goal 만 이용하고 있습니다.

$ultragoal의 결과가 나빠졌기 때문은 아닙니다. $ralplan과 $ultragoal을 함께 사용했을 때 발생하는 토큰 사용량이 제가 이용 중인 요금제에서는 부담스러웠고, 비교해 본 결과 현재 제가 진행하는 작업에서는 /goal만으로도 충분한 결과를 얻을 수 있다고 판단했기 때문입니다.

올바른 비유가 아닐 수도 있지만 저의 짧은 사례만 봐도 알 수 있듯이, 하네스에는 정답은 없습니다.

오늘은 이 글을 통해서 하네스가 무엇인지 다시 생각해 보고 제 생각을 정리해 보려고 합니다.

하네스의 본질

하네스 엔지니어링의 정의를 다시 생각해 봅시다.

하네스 엔지니어링(Harness Engineering) 은 최근 생성형 AI 및 AI 코딩 에이전트(예: GitHub Copilot, Claude Code)가 자율적으로 업무를 수행할 때, 발생할 수 있는 오류나 궤도 이탈을 방지하고 올바른 결과물을 낼 수 있도록 작업 환경과 전체 시스템을 설계하는 기술

하네스 엔지니어링이 중요한 이유가 무엇일까요? 결국 설계를 기반으로 올바른 결과물을 만들어 내는 것입니다.

프로젝트 내에서 어떤 문서를 먼저 읽게 할 것인지, 작업 전에 계획을 세우게 할 것인지, 구현과 검증을 어떤 순서로 진행할 것인지, 실패한 작업을 어디까지 되돌릴 것인지, 어떤 조건을 만족해야 작업이 끝났다고 판단할 것인지가 모두 하네스에 포함됩니다.

결국 하네스는 AI에게 일을 시키는 개발자의 사고방식과 작업 순서를 코드와 프롬프트로 구현한 것에 가깝습니다.

문제는 개발자마다 선호하는 작업 방식은 다를 수밖에 없습니다.

어떤 개발자는 구현 속도를 가장 중요하게 생각합니다. 우선 코드를 작성한 뒤 테스트 과정에서 발견되는 문제를 빠르게 수정합니다.

계획과 문서화를 중요하게 생각하는 개발자는 구현 전에 요구사항과 예외 조건을 충분히 정리하고, 확정된 문서를 기준으로 AI가 작업하기를 원합니다.

안정성을 중요하게 생각하는 개발자는 테스트를 먼저 작성하거나 작은 작업 단위마다 별도의 리뷰 에이전트를 실행할 수 있습니다.

기존 소프트웨어 개발에서도 폭포수, 애자일, TDD와 같은 다양한 방식이 사용됩니다. 하나의 방법론이 모든 프로젝트와 조직에 완벽했다면 이렇게 다양한 방식이 만들어질 이유도 없었을 것입니다.

하네스 엔지니어링도 마찬가지입니다.

AI가 개발 과정에 들어왔다고 해서 개발자의 성향과 프로젝트의 조건이 사라지는 것은 아닙니다. 오히려 AI에게 더 많은 권한을 맡길수록, 개발자가 원하는 작업 방식의 차이는 더욱 분명해집니다.

만능 하네스는 없다

OMX, LazyCodex와 같은 오픈소스 하네스를 내 작업환경에 설치하는 것만으로, 비효율적이거나 결과물이 잘 나오지 않던 프로젝트가 곧바로 내 생각대로 진행될까요? 절대 그렇지 않습니다.

결국 우리가 설치하는 OMO, LazyCodex와 같은 오픈소스 하네스는 하네스를 만든 개발자의 문제 정의 방식과 개발 절차가 담긴 하나의 작업 환경입니다.

일반적인 오픈소스 라이브러리를 생각해 봅시다.

많은 개발자가 추천한 라이브러리를 실제 프로젝트에 적용했을 때 항상 만족스러웠나요? 아마 그렇지 않았던 경험도 있을 것입니다.

"이 라이브러리 제공하는 기능은 좋지만, 내 프로젝트에서는 불필요한 코드가 늘어나는 것 같아."

"분명 좋은 라이브러리인데, 추가 기능이 있으면 더 좋을 것 같아."

기능을 제공하는 라이브러리조차 프로젝트마다 평가가 달라집니다. 그렇다면 기능이 아닌 개발 방향성을 공유하는 것에 가까운 하네스 오픈소스가 모든 개발자에게 핏하게 맞을 수 있을까요?

내가 만든 하네스가 아닌데, 나의 문제 정의와 작업 방식에 100% 맞을 수 있는가?

여러 하네스 오픈소스를 사용하면서 내 맘에 드는 부분도 있고, 내 맘에 들지 않는 부분은 당연히 존재합니다.

특정 하네스가 나와 맞지 않는다고 그 하네스는 '쓰레기' 라고 평가할 순 없습니다. 그리고 유명한 개발자가 개발하고 많은 스타를 받았다는 이유만으로 그 하네스가 '나한테 적합한 하네스 툴' 이라고 평가할 수도 없습니다.

만능 하네스 오픈소스는 이 세상에 없습니다.

모델을 어떻게 선택하는가

새로운 LLM이 출시되면 여러 곳에서 벤치마크를 진행합니다. 코딩 성능, 추론 능력, 도구 사용 능력, 장기 작업 수행 능력 등 다양한 지표가 공개됩니다.

하지만 모든 개발자가 벤치마크 결과를 보고, 새로운 모델로 이동하지는 않습니다. 개발자마다 평가하는 기준이 다르고 결과물을 판별하는 기준이 다르기 때문입니다.

어떤 개발자는 새로 발표한 모델이 훨씬 좋아졌다고 평가하는 사람이 있는 반면, 다른 개발자는 이전 모델보다 토큰 소모량은 늘었지만 결과물은 비슷해 과거 모델을 그대로 사용하는 경우도 있습니다.

심지어 같은 회사의 모델을 사용하다가도 새로 발표한 모델이 자신의 작업 방식과 맞지 않는다고 판단해 다른 회사의 모델로 변경하기도 합니다.

벤치마크 점수가 높다는 사실과 특정 개발자의 작업에 적합하다는 사실은 같지 않기 때문입니다.

하네스도 같은 기준으로 평가해야 합니다.

많은 Skills를 제공하고 그 기반으로 정교하게 동작하는 하네스라고 해도, 내 프로젝트의 규모, 작업 방식, 예산과 맞지 않는다면 좋은 선택이 아닐 수 있습니다.

하네스 오픈소스의 한계

하네스는 LLM 위에 만들어진 구조입니다.
LLM이 없으면, 하네스도 없습니다.

따라서 기반 모델의 성향과 기능이 달라지면 하네스의 동작도 달라질 수밖에 없습니다.

이전 모델에서는 계획 에이전트, 구현 에이전트, 리뷰 에이전트를 명확하게 분리해야 했지만, 새로운 모델이 많이 똑똑해져 하나의 에이전트가 충분히 긴 작업을 안정적으로 수행할 수도 있습니다.

반대로 새로운 모델이 더 적극적으로 코드를 수정하여 예상 범위를 넘어 개발하는 경우가 발생한다면, 기존보다 강한 범위 제한과 검증 절차가 필요할 수도 있습니다.

모델 위에 만들어진 하네스는 지속적으로 개선시켜야 합니다.

하지만 하네스 오픈소스 툴이, 새로 출시된 모델을 기반으로 바로 테스트하고 업데이트, 개선할 수 있는 것은 아닙니다.

LazyCodex를 예시로 생각해 보겠습니다.

모든 오픈소스 하네스 개발자가 새로운 모델 출시 전, 얼리 액세스 권한을 제공받아 충분히 테스트할 수 있는 것은 아닙니다.

대부분 모델이 출시된 이후에야, 기존 Skills이나 프롬포트가 새로운 모델과 적합하게 작업하는지, 에이전트 분리가 필요한지, 계획 단계가 과도하게 길어지지는 않는지, 새로운 모델 기능과 충돌하는 부분은 없는지 다시 평가해야 합니다.

결국 오픈소스 개발자가 자신의 하네스를 스스로 벤치마크하고 개선해야 합니다.

하지만 사용자는 새로운 모델이 출시되자마자 기존 하네스를 그대로 연결하여 최신 모델의 성능과 하네스의 역할을 동시에 하기를 원하는 경우가 많습니다.

원하는 결과가 나오지 않으면 모델이나 하네스를 빠르게 비판합니다. 다만 새로운 모델이 출시된 직후 완벽하게 대응하지 못했다는 이유만으로 해당 하네스의 가치가 사라지는 것은 아닙니다.

하네스는 한 번 완성하면 끝나는 것이 아닌 기반 모델과 함께 계속 조정해 나가야 하는 하나의 도구입니다.

하네스를 분석하고, 나만의 하네스를 구축하기

오픈소스 하네스가 새로운 모델에 맞게 업데이트되더라도, 그것만으로 해당 하네스가 나에게 완벽하게 맞게 되는 것은 아닙니다. 또한 오픈소스 하네스를 제대로 활용하려면 단순히 설치하고 명령어를 외우는 단계에서 끝나서는 안 됩니다.

저도 omx에서 제공하던 $ralplan과 $ultragoal의 결과를 그대로 사용해 왔습니다.

하지만 이 과정에서 너무 많은 토큰이 소모되어, Codex의 /goal과 $ultragoal의 작업 결과와 토큰 사용량을 비교했고, 제가 작업하는 수준에서는 Codex의 /goal 로도 원하는 수준의 결과물을 뽑을 수 있다고 판단했습니다.

그래서 필요한 기능은 남겨 두되, 일부 작업에서는 더 단순한 기본 기능을 사용하기 시작했습니다.

이것은 OMX가 나빠진 것이 아닌, OMX를 그대로 소비하는 단계에서 벗어나, 어떤 과정이 제 작업에 필요한지 판단하기 시작한 것입니다.

좋은 하네스를 사용해 보는 것은 중요합니다. 다른 개발자가 컨텍스트를 관리하는 방식, 작업을 분리하는 방식, 검증 에이전트를 구성하는 방식을 빠르게 학습할 수 있기 때문입니다.

하지만 최종 목표가 설치한 하네스의 모든 기능을 잘 사용하는 것에 머물러서는 안 됩니다.

하네스가 제공하는 각 기능들이 내 작업에 효과적인지 이해하고, 필요한 부분만 잘 사용하여 자신의 환경에 맞게 재구성하는 것이 목표가 되어야 합니다.

돌고 돌아 프롬포트와 문서

위와 같은 순서로 하네스를 재구성하고 나면, 결국 다시 처음, 프롬포트와 문서를 잘 구축하는 것으로 돌아옵니다.

잘 작성된 프롬프트와 문서가 있는 프로젝트에서 하네스는 더 안정적으로 동작합니다.

어떤 하네스를 사용하더라도 요구사항이 모호하거나, 프로젝트의 구조나 규칙이 문서화되어 있지 않아 에이전트는 그 작업을 마무리하기 위해서 빈 부분들을 추측합니다.

각 기능들에 대한 조건들이 정의되어 있지 않으면 잘 구축된 하네스 위에서도 추측하여 개발하기도 합니다.

반대로 위와 같은 요구사항이나 프로젝트 규칙들이 잘 구축되어 에이전트는 이해하기 쉬운 형태의 프로젝트에서는, 오히려 복잡한 하네스가 없이, 생각보다 안정적인 결과를 만들어 냅니다.

AI가 어떤 문서를 읽어야 하는지, 각 모듈의 책임이 무엇인지, 변경 가능한 범위가 어디까지인지, 어떤 테스트를 통과해야 하는지, 무엇을 작업 완료로 판단할지를 정의해야 합니다.

규칙이 없는 상태에서 유명한 하네스를 설치한다고 개발 방식이 자동으로 만들어지지는 않습니다.

모델이 발전하면서 과거에는 하네스가 별도로 제공해야 했던 계획 수립, 역할 분리, 작업 검증 기능을 모델 자체가 수행하기도 합니다. 이에 따라 일부 복잡한 하네스 구조는 이전만큼 효율적이지 않게 되기도 합니다.

결국 하네스의 핵심은, 화려한 오케스트레이션 창도, 많은 에이전트 수가 아닌 프로젝트를 설명하는 문서, 모델의 역할을 제한하는 프롬프트, 결과를 판단할 수 있는 명확한 기준을 구축해 주는 것이 더 중요합니다.

결론

현재 공개된 여러 하네스 중 모든 개발자에게 적용되는 정답은 없습니다.

GitHub에 올라온 하네스에는 그 하네스를 만든 개발자의 작업 방식과 성향이 담겨 있습니다. 어떤 하네스는 구현 속도를 우선하고, 어떤 하네스는 계획과 반복 검토를 통해 안정성을 높입니다.

그 툴이 나와 잘 맞을 수도 있고 맞지 않을 수도 있는 것이 당연합니다.

위와 같이 불편함을 느끼기 시작했다면, 왜 불편한지 분석하고, 필요한 기능과 불필요한 단계를 구분해야 합니다.

그리고 자신의 개발 방식을 프롬프트와 문서, 검증 구조를 기반으로 하는 나의 하네스를 구현하기 시작하는 것이 중요합니다.

먼저 사용해 보고, 구조를 분석하고, 필요한 기능만 선택해야 합니다.

결국 나에게 가장 잘 맞는 하네스는 다른 사람이 완성해 주는 것이 아니라, 내가 사용하는 모델과 프로젝트, 비용과 개발 방식에 맞춰 직접 구축해야 한다는 것입니다.