하네스 엔지니어링이란?

wldud·2026년 4월 5일

이제는 모델이 아니라 하네스 경쟁?!

여태까지는 “어떤 모델이 더 똑똑한가”가 경쟁의 핵심이었습니다. 근데 지금은 솔직히 GPT, Claude, Gemini 등 모두 충분히 뛰어나서, 모델 자체의 품질 격차가 점점 줄어들고 있습니다.

그렇다면 이제 경쟁은 어디서 일어날까요????
바로 AI를 얼마나 잘 쓰는지에 따라 달라지는겁니다.

2026년 2월, OpenAI Codex 팀에서 엔지니어 3명이 5개월간 코드를 단 한 줄도 직접 타이핑하지 않고, 약 100만 줄 규모의 프로덕션 애플리케이션을 만들어냈습니다. 1,500개의 PR을 머지하면서 엔지니어 1인당 하루 평균 3.5개의 PR을 처리했고, 수작업 대비 약 10분의 1 시간에 완성했다고 밝혔습니다.
그런데 여기서 더 똑똑한 모델을 쓴 것이 아니었습니다!! 이들은 에이전트가 실수하지 않도록 감싸는 시스템인 하네스를 설계헀습니다.

또한, LangChain은 코딩 에이전트 벤치마크 Terminal Bench 2.0에서 모델을 바꾸지 않고 하네스만 개선해서 30위 → 5위로 올랐습니다.

이제는 AI에이전트의 성능을 좌우하는건 모델의 지능이 아니라, 그 지능을 감싸는 시스템 설계다!!!

하네스 엔지니어링이란?

하네스 엔지니어링은 AI 자체를 더 똑똑하게 만드는 일이 아니라, AI가 일을 제대로 하게 둘러싸는 작업 환경을 설계하는 것이다. Agent = Model + Harness 라고 설명하는데, 여기서 harness는 모델 바깥의 코드, 설정, 실행 규칙, 도구, 검증 루프 같은 전부를 뜻합니다.

쉽게 비유!!

  • 모델(Claude, Codex 등등) = 똑똑한 신입
  • 하네스 = 업무 메뉴얼, 사내 툴, 권한, 체크리스트, 리뷰 프로세스, 로그 시스템
  • 하네스 엔지니어링 = “이 신입이 실수 덜 하고, 빠르고, 안전하게 일하도록 회사 시스템을 짜는 일”

그래서 하네스 엔지니어링에는 보통 아래와 같은 것들이 들어간다.

  • 어떤 툴을 쓸 수 있는지
  • 어떤 파일/문맥을 먼저 읽게 할지
  • 중간중간 테스트, 린트, 검증을 어떻게 돌릴지
  • 작업이 길어질 때 상태를 어떻게 이어갈지
  • 여러 에이전트를 병렬로 어떻게 나눠 돌릴지
  • 실패했을 때 재시도/수정 루프를 어떻게 할지

이런 것들 전부 하네스 쪽 설계다.

그래서 oh-my-claudcode는??

이건 기본 Cladue code 위에 얹는 멀티 에이전트 오케스트레이션 플러그인이다.
그냥 Claude Code를 쓰면 보통 한 세션 안에서 직접 지시하면서 하나의 에이전트를 쓰는 느낌인데, OMC는 거기에 팀 운영, 자동 위임, 단계별 실행, 훅, 스킬 조합같은 걸 붙여준다.

  • 기본 Claude Code = 유능한 1명한테 직접 일 시킴
  • OMC = PM 1명이 팀원 여러 명한테 역할 나눠서 일 시킴

오케스트레이션?

오케스트레이션은 여러 작업 주체를 하나의 목표에 맞게 순서와 역할, 연결 규칙에 따라 조율하는 것. AI 시스템에서는 모델, 도구, 검증 단계, 재시도 루프를 유기적으로 연결해서 실제 업무가 끝까지 수행되도록 만드는 운영 방식. ⇒ 한마디로 지휘하는 애라고 보면 됩니다

oh-my-claudcode가 기존이랑 뭐가 다른가?

  1. 자동 위임이 강해진

    OMC는 설정 후에 자동 행동 감지, continuation enforcement, skill composition 같은 걸 붙여서, 요청을 보고 “아 이건 이런 흐름으로 가야겠네”를 더 많이 대신 판단해줍니다. 문서에는 one-time setup 후 최신 CLAUDE.md 다운로드, 에이전트 설정, 자동 행동 감지, continuation enforcement, skill composition 설정이 이뤄진다고 적혀 있습니다.

    기존에는 계획, 구현, 검증 등을 우리가 직접 지시를 해야했으면, OMC는 팀장이 알아서 일을 나눠서 하게 해준다. 

  2. 팀모드
    OMC는 팀 실행을 기본 표면으로 밀고 있습니다. 현재 README 기준으로 팀 실행은
    team-plan → team-prd → team-exec → team-verify → team-fix(loop)
    같은 단계형 파이프라인으로 돌아갑니다. 즉 그냥 “해봐”가 아니라 계획 → 실행 → 검증 → 수정 흐름이 기본 내장된 것입니다.

  3. 멀티 에이전트/병렬 작업이 쉬움

    예를 들어 보안 리뷰용 팀, UI 개선용 팀, 구현용 팀처럼 나눠서 돌릴 수 있습니다. 기본 Claude Code보다 병렬 처리와 역할 분담 쪽이 훨씬 강하다고 볼수있어요

    그래서 요새는 OMC 몇 개 켜서 병렬로 일시킨다고 하더라구요

  4. 요구사항이 애매할 때도 도와줌

    /deep-interview 같은 기능이 있어서, 바로 구현 들어가기 전에 질문을 통해 문제를 더 분명하게 만드는 것이다.

    기존
    대충 알아듣고 바로 코딩 시작

    OMC

    정확히 원하는게 뭐지? 범위는? 예외 상황은? 출력 형태는? 등등 이런 걸 더 구조적으로 캐묻고 정리해주는 늒미

0개의 댓글