AI 고수들이 프롬프트 대신 쓰는 것! 이제 AI는 ‘하네스’ 하세요
📺 원본 영상: AI 고수들이 프롬프트 대신 쓰는 것! 이제 AI는 ‘하네스’ 하세요
🎙️ 채널: 안될과학 Unrealscience
📅 정리 일자: 2026-05-18
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 영상은 안될과학 채널에서 진행한 인터뷰로, Oh My Claude Code(OMC)와 Oh My Codex(OMX)를 개발한 허예찬과 Oh My Open Agent(OMO)를 개발한 김현균이 출연하여 ‘AI 하네스(Harness) 엔지니어링’이라는 개념을 심층적으로 설명한다. 두 개발자는 GitHub Star를 합산 10,000개 이상 보유한 AI 분야 스타 개발자로, 각자 전혀 다른 철학과 실무 배경을 바탕으로 AI 하네스를 설계하고 있다. 인터뷰는 하네스의 정의와 등장 배경부터 실제 프로젝트 개발 스토리, 한계점, 그리고 하네스의 미래까지 폭넓게 다룬다.
하네스(Harness)란 무엇인가
단어의 기원과 AI에서의 의미
‘하네스(Harness)‘라는 단어는 원래 AI 엔지니어링 전용 용어가 아니었다. 김현균에 따르면, 소프트웨어 개발에서는 테스트를 구조적으로 잘 설계해 놓은 것을 ‘테스트 하네스(Test Harness)‘라고 부르는 관행이 이미 있었다. 보다 광의적으로는 반복 가능한 작업의 묶음, 즉 체계화된 워크플로우 전체를 가리키는 말이었다. 그런데 AI가 단순 채팅을 넘어 외부 도구를 사용하고 반복 가능한 워크플로우로 자동화되기 시작하면서, 이 일련의 행동들을 정의할 공통 용어가 필요해졌고 ‘하네스’라는 단어가 자연스럽게 AI 엔지니어링 영역으로 넘어왔다.
허예찬은 이를 더 직관적인 비유로 설명했다. AI 에이전트는 일종의 ‘금쪽이’라는 것이다. 시키는 대로 해야 하는데 말을 잘 안 듣고, 하지 말라는 짓을 하고, 감시하지 않으면 엉뚱한 방향으로 튀어나간다. 하네스는 이 금쪽이를 특정 방향으로 행동하게 강제하거나 이상한 행동을 하려 할 때 잡아주는 제약 체계다. 영어 원어로 ‘Harness’는 말(horse)에 씌우는 마구(馬具), 즉 안장이나 고삐 같은 주변 장치를 가리키는데, AI를 ‘말’에 빗대어 이 도구 체계를 하네스라고 부르는 셈이다.
프롬프트 엔지니어링, 컨텍스트 엔지니어링과의 관계
많은 사람들이 익숙한 ‘프롬프트 엔지니어링(Prompt Engineering)‘이나 ‘컨텍스트 엔지니어링(Context Engineering)‘은 하네스와 어떤 관계일까. 두 개발자는 이 질문에 명확하게 답했다. 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 AI 하네스를 구성하기 위한 기술적 역량의 **구성 요소(Component)**라는 것이다. 하네스가 더 포괄적인 상위 개념이고, 프롬프트나 컨텍스트를 설계하는 능력은 그 하네스를 만드는 데 필요한 개별 스킬에 해당한다. 따라서 프롬프트 엔지니어링에 감이 있는 사람이라면 하네스 개념으로의 확장도 어렵지 않다는 것이 두 개발자의 공통된 견해다.
왜 지금 하네스가 뜨는가
AI 능력의 폭발적 확장이 촉발한 제어 문제
AI 하네스가 지금 이 시점에 주목받는 이유는 역설적이게도 AI가 너무 강력해졌기 때문이다. 김현균은 2023년 ChatGPT 3.5 시절에 LLM API를 처음 사용하기 시작했을 때와 현재를 비교했다. 당시에는 AI가 다룰 수 있는 컨텍스트(Context) 길이가 짧아 도구를 사용하는 수준에 머물렀지만, 현재는 그 컨텍스트 길이가 당시 대비 8~16배에 달한다. 이는 AI가 훨씬 더 긴 연속 작업을 수행할 수 있게 되었다는 의미로, 이전에는 불가능했던 멀티스텝(Multi-step) 태스크 자동화가 현실적으로 가능해진 것이다.
03:47 - 맥락(Context) 길이 변화 수치 설명
이 변화가 하네스의 수요를 폭발시켰다. 초기에는 AI와 채팅하는 것이 주된 인터랙션이었으나, 사람들은 AI에게 채팅을 시키다 보니 일을 맡기고 싶어졌고, 일을 맡기다 보니 더 잘하게 만들고 싶어졌다. 문제는 AI가 ‘말을 더럽게 안 듣는다’는 점이었다. 이를 해결하기 위해 AI를 원하는 방향으로 따르게 만드는 테크닉들이 개발자들 사이에서 축적되기 시작했고, 이 테크닉들의 묶음이 표준화되면서 ‘하네스 엔지니어링’이라는 개념으로 정립된 것이다.
모델이 똑똑해질수록 하네스가 더 필요하다
흥미로운 점은 모델이 더 똑똑해질수록 하네스가 덜 필요해지는 것이 아니라 오히려 더 중요해질 수 있다는 주장이다. 최근 학계 연구에서는 대형 모델일수록 자꾸 추가 질문을 하거나 주어진 가드레일(Guardrail)을 벗어나려는 경향이 있다는 결과가 나오고 있다. 사람에 비유하자면, 지능이 매우 높은 사람일수록 반복되는 단순 작업을 싫어하고 지시를 그대로 따르지 않으려는 경향이 있는 것과 비슷하다. 허예찬은 자신을 이 “고지능이라 반복적인 일을 싫어하고 말도 잘 안 듣는” 유형에 빗대어 유머러스하게 설명했다.
결국 모델이 발전할수록 하네스는 오히려 더 정교해져야 한다는 시각도 충분히 설득력이 있다. 엑셀을 직접 만들어 쓰지 않아도 좋은 도구가 필요하듯, 아무리 뛰어난 AI 모델이라도 적절한 제어 체계 없이는 원하는 결과를 안정적으로 얻기 어렵다는 논리다. 단, 이 부분에 대해서는 업계에서도 ‘모델이 충분히 발전하면 하네스가 필요 없어진다’는 반론도 존재하며, 두 개발자는 이를 진행 중인 갑론을박으로 소개했다.
두 개발자의 서로 다른 하네스 철학
허예찬의 ‘타이트한’ 하네스
허예찬이 하네스 엔지니어링에 뛰어든 동기는 솔직하게도 “회사 일을 꿀빨고 싶었기 때문”이었다. AI에게 최대한 많은 일을 맡기는 방법을 탐구하던 중, AI가 반복적으로 저지르는 실수에는 일정한 패턴이 있다는 것을 발견했다. 대표적인 예가 코드 주석 문제다. AI는 기본적으로 말이 많아서 코드를 작성할 때 불필요한 주석을 자꾸 달려 한다. 이렇게 생성된 코드는 AI가 짰다는 티가 나기 쉽다. 그래서 시스템 레벨에서 자동으로 주석을 감지해 “이 주석이 정말 필요한가?”라고 반문하는 자동화된 잔소리 체계를 구현했다. 이처럼 AI의 습관을 하나씩 포착하고 교정하는 방식으로 하네스를 구축해 나간 것이다.
허예찬의 핵심 철학은 모호함이 사라질 때까지 질문하는 것이다. 새 프로덕트를 만들 때 AI가 사용자에게 50여 가지 오지선다형 질문을 던지게 설계하여, 사용자 스스로도 생각하지 못했던 디테일을 끄집어내도록 유도한다. 계획 단계를 빡빡하게 만들어 실행 과정에서의 오류를 최소화하는 접근이며, 이는 수치 오류 하나가 실제 손실로 이어지는 Quant 트레이딩(Quant Trading) 경험에서 체화된 감각이다.
김현균의 ‘유연한’ 하네스
반면 김현균의 철학은 정반대에 가깝다. “생각을 하기가 싫어서” 대충 말하면 AI가 알아서 잘 해줬으면 좋겠다는 것이다. 이는 나태함이 아니라, 해당 도메인에서 통용되는 Best Practices(모범 사례)를 AI가 이미 충분히 알고 있다는 전제 위에 선 설계 철학이다. AI에게 일반적인 베스트 프랙티스를 기반으로 먼저 초안을 만들게 하고, 중요한 부분만 사람이 나중에 조정하는 방식이다. 웹 개발이나 앱 개발처럼 가설 검증 속도가 중요한 영역에서 빠르게 프로젝트 방향성을 잡는 데 최적화된 접근이다.
두 철학의 차이는 각자의 커리어 배경에서 비롯된다. 허예찬은 Quant 리서처(Quant Researcher)와 Quant 개발자로 일하면서 알고리즘 트레이딩 및 시계열 데이터 분석 업무를 해왔다. 이 분야에서는 수치 하나가 틀리면 돈이 직접적으로 날아갈 수 있기 때문에 디테일의 정확성이 생명이다. 반면 김현균은 웹/앱 개발과 빠른 가설 검증 환경에서 일해왔기 때문에 완벽한 정확성보다 빠른 방향성 설정이 더 중요했다. 두 사람은 같은 하네스 도구를 공유하다가, 허예찬이 숫자 오류 문제로 불만을 느껴 스스로 새로운 하네스를 만들기에 이르렀다. 그들의 표현대로, 하네스는 “만든 사람 따라간다.”
주요 프로젝트 소개
Oh My Claude Code와 Oh My Codex (허예찬)
허예찬이 개발한 Oh My Claude Code(OMC)는 Anthropic의 Claude Code를 기반으로 한 하네스 프로젝트다. 앞서 설명한 타이트한 설계 철학이 반영된 도구로, Quant 트레이딩 환경처럼 정밀도가 요구되는 태스크에 적합하다. Oh My Codex(OMX)는 OpenAI의 Codex를 기반으로 하는 유사한 프로젝트다.
프로젝트의 확산 경로가 흥미롭다. 허예찬은 GitHub Star를 받고 싶은 마음에 X(구 Twitter)에서 의도적으로 논쟁을 걸었다. “아직도 그런 거 써? 요즘 애들은 다 이거 쓰던데?”라는 도발적인 말로 사람들의 호기심을 자극했고, 실제로 써 본 사람들 사이에서 입소문이 났다. 이후 영국의 테크 인플루언서 Numan Ali가 해당 프로젝트를 태그하며 극찬하면서 하루에 팔로워가 1,000명씩 늘기 시작했다. 지나치게 빠른 성장 때문에 트위터 계정이 스팸으로 오인되어 정지당하는 해프닝도 있었다. 현재 사용자는 미국과 유럽이 주를 이루며 중국에서도 상당수 사용자가 있고, 한국 사용자 비중은 아직 상대적으로 적다.
Oh My Open Agent (김현균)
김현균이 개발한 Oh My Open Agent(OMO)는 이전 이름 Oh My Open Code에서 변경된 프로젝트로, Open Code라는 오픈 소스 프레임워크를 기반으로 하고 있다. 이 덕분에 어떤 AI 모델이든 연결해 사용할 수 있다는 것이 특징이다. Claude Code가 Claude 모델만, Codex가 GPT 모델만 지원하는 것과는 대조적이다.
OMO 개발 스토리는 특정 사건에서 촉발된다. Anthropic이 오픈 소스 에이전트 프레임워크에서 Claude 사용을 차단하는 조치를 내리면서 커뮤니티가 혼란에 빠졌다. 허예찬은 이 사건 직후 Claude Code 위에서 OMO 스타일의 기능을 두 시간 만에 구현했다. 처음에는 대수롭지 않게 생각하고 가볍게 만들었지만, 하루 만에 GitHub Star 500개를 받으며 예상치 못한 반응을 얻었다. 이후 커뮤니티의 피드백이 쏟아지기 시작했고, 예전에는 이슈 티켓 하나를 처리하는 데 하루 이틀이 걸렸다면 이제는 Claude Code 창을 여러 개 병렬로 띄워 20~30분이면 처리할 수 있게 되었다. 개발자 본인이 하네스 도구를 활용해 하네스 도구를 더 빠르게 발전시키는 선순환 구조가 만들어진 것이다.
17:15 - Claude Code 창 병렬 실행으로 이슈 처리하는 개발 워크플로우 설명
하네스의 한계와 적용 가능 영역
시뮬레이션 가능 여부가 핵심 변수
하네스가 효과적으로 작동하려면 반복 가능한 시뮬레이션 환경이 뒷받침되어야 한다. 웹 개발의 경우 표준화된 개발 환경과 브라우저 엔진이 있어 AI가 생성한 결과가 모든 사용자의 디바이스에서 동일하게 동작하는지 반복 검증할 수 있다. Quant 트레이딩 역시 시계열 데이터와 수식을 시뮬레이션 환경 안에서 반복 실행할 수 있기 때문에 하네스의 활용도가 높다.
반면 임베디드 디바이스(Embedded Device) 개발처럼 열, 진동, 센서 노이즈 등 물리적 환경 변수가 많은 분야에서는 상황이 다르다. 소프트웨어 시뮬레이션만으로는 Edge Case(엣지 케이스)를 모두 커버하기 어렵고, 사람이 직접 다양한 물리적 조건에서 테스트해야 하는 경우가 많다. 이런 환경에서는 하네스가 자동화할 수 있는 범위가 본질적으로 제한된다.
모델 품질이 전제 조건
또 다른 근본적인 한계는 AI 모델 자체의 성능이다. 두 개발자는 “AI 모델이 이 하네스의 운영체제(Operating System)“라고 표현했다. 아무리 정교한 하네스를 만들어도 기반 모델이 특정 태스크를 수행할 역량이 없다면 원하는 결과를 얻을 수 없다.
09:53 - AI 모델이 하네스의 운영체제라는 개념 설명
맥 스튜디오(Mac Studio)나 맥 미니(Mac Mini)로 로컬 모델을 돌리며 하네스를 잘 구성하면 되겠다고 생각하는 분들도 있지만, 어떻게든 동작하게 만들 수는 있어도 그 성능의 한계가 명확하다는 점도 언급되었다. 똑똑한 사람에게 좋은 도구를 줘야 효과가 있듯, 모델의 기본 성능이 충분할 때에야 하네스가 진가를 발휘한다.
덧붙여, 같은 계열의 모델이라도 버전 업데이트가 이루어지면 행동 패턴이 달라지기 때문에, 하네스는 모델 업데이트에 맞춰 지속적으로 재조정해야 하는 살아있는 시스템이다. 마치 성장하는 자녀를 키우듯, 하네스도 대상 모델의 변화에 맞춰 함께 진화해야 한다.
하네스의 스펙트럼과 미래
하네스는 단일한 개념이 아니라 굉장히 넓은 스펙트럼 위에 존재한다. 요청을 대충 줘도 AI가 알아서 처리해 주기를 기대하는 느슨한 하네스부터, 하나하나 디테일을 지정하며 완벽한 수행을 요구하는 촘촘한 하네스까지 다양하다. 어떤 하네스가 옳다고 단정할 수 없으며, 수행할 태스크의 성격과 사용자의 업무 스타일에 따라 최적의 설계가 달라진다. 허예찬과 김현균이 서로 다른 철학의 하네스를 만들게 된 것도 이러한 이유에서다.
한편, 제품화된 하네스들도 빠르게 등장하고 있다. ChatGPT나 GPTs 같은 제품의 인터페이스 안에 Gmail이나 구글 드라이브 같은 외부 도구가 연결되어 있는 것도 자유도가 높은 하네스의 일종으로 볼 수 있다. 즉 하네스를 직접 만들지 않더라도, 이미 제품화된 형태로 일상에서 경험하고 있는 것들이 많다는 의미다. 커스터마이제이션(Customization)을 원한다면 필요한 지식의 수준도 프롬프트 엔지니어링과 크게 다르지 않다는 것이 두 개발자의 설명이다.
마무리 / 핵심 정리
AI 하네스 엔지니어링은 단순히 프롬프트를 잘 짜는 것을 넘어, AI 에이전트가 원하는 방식으로 안정적이고 반복적으로 작동하도록 설계하는 포괄적인 제어 체계다. 프롬프트 엔지니어링이나 컨텍스트 엔지니어링은 이 하네스를 구성하는 구성 요소들이다. AI가 더 많은 작업을 수행할 수 있게 될수록, 그리고 맥락을 더 길게 유지할 수 있게 될수록, 이 제어 체계의 정교함에 대한 요구는 높아진다. 허예찬과 김현균의 사례는 AI 하네스가 단순한 기술 트렌드를 넘어, 각자의 도메인과 스타일에 맞게 설계되어야 하는 개인화된 엔지니어링 철학임을 보여준다. 모델이 바뀌면 하네스도 함께 진화해야 하고, 태스크가 바뀌면 하네스의 철학도 달라져야 한다. 이것이 두 개발자가 공통으로 강조한 하네스의 본질이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | AI 고수들이 프롬프트 대신 쓰는 것! 이제 AI는 ‘하네스’ 하세요 |
| 채널 | 안될과학 Unrealscience |
| 리포트 작성 | 2026-05-18 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- AI 모델 성능 경쟁이 더이상 무의미… 하네스 엔지니어링 본격 개화 | NVIDIA는 이미 준비 중, 반도체도 함께 변한다
- Harness Engineering - How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI
- Skills are the New SDKs - Elvin Aghammadzada, DataRobot
- AI 에이전트 100개를 한 번에 관리하는 1인 유니콘 개발자 (커서맛피아 최수민님)
- Field Guide to Fable — Thariq Shihipar, Anthropic