질문 빌런 하네스 VS 아 몰라 하네스
📺 원본 영상: 질문 빌런 하네스 VS 아 몰라 하네스 🎙️ 채널: 안될과학 Unrealscience 📅 정리 일자: 2026-05-20 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 영상은 AI 에이전트 하네스(Harness) 엔지니어링 분야에서 서로 다른 철학을 가진 두 개발자, OMX의 허혜찬과 OMO의 김현규가 각자의 도구를 실시간으로 시연하며 대담을 나누는 내용이다. ‘질문 빌런’으로 불리는 OMX는 AI에게 작업을 넘기기 전 인터뷰를 통해 요구사항의 모호함을 철저히 제거하는 방식이고, ‘아 몰라’ 스타일의 OMO는 최소한의 입력으로 AI가 알아서 실행하게 하는 방식이다. 두 접근법의 차이를 통해 현재 AI 에이전트 개발의 핵심 설계 철학과 실무 활용법을 탐색한다.
AI 하네스(Harness)란 무엇인가
‘하네스(Harness)‘라는 단어는 원래 말의 고삐처럼 무언가를 제어하고 활용하기 위한 장치를 뜻한다. AI 에이전트 맥락에서 하네스는 LLM(Large Language Model)이 특정 방식으로 작동하도록 구조와 제약을 가하는 시스템 전체를 의미한다. 허혜찬은 이 개념이 본격적으로 유명해지기 전부터 비슷한 종류의 엔지니어링을 해왔다고 밝혔으며, 당시에는 “LLM의 오은영 선생님이 되어야 한다”는 표현으로 이 접근 방식을 설명했다고 한다. 결국 시대가 이 엔지니어링 패턴에 ‘하네스’라는 이름을 붙였을 뿐, 개념 자체는 그 이전부터 실무에서 발전해왔다는 것이다.
두 게스트는 하네스라는 단어가 일종의 마케팅 용어로 쓰이는 데 대해 미묘한 시각 차이를 보였다. 이 용어를 싫어하는 개발자들이 있다는 점도 언급되었지만, 동시에 새로운 개념을 대중에게 전달하려면 어떤 식으로든 공유 어휘가 필요하다는 점에도 공감했다. 이는 기술 커뮤니티에서 새로운 패러다임이 자리잡는 과정에서 흔히 벌어지는 긴장으로, 정확성과 접근성 사이의 타협이기도 하다. 허혜찬은 “이 단어가 굉장히 싫어하시는 분들도 많아요”라면서도, 어쨌든 소통할 어휘는 필요하다고 정리했다.
두 가지 철학: 질문 빌런 vs. 아 몰라
OMX의 인터뷰 기반 하네스 - 프리모템(Pre-mortem) 극대화
허혜찬이 개발한 OMX의 핵심은 AI가 작업을 시작하기 전에 철저한 인터뷰를 수행하는 것이다. 이 인터뷰 과정은 단순히 요구사항을 수집하는 것이 아니라, **모호도 점수(Ambiguity Score)**라는 내부 지표를 기반으로 작동한다. AI는 사용자의 답변을 누적하면서 목표(Goal), 제약 조건(Constraints), 성공 조건(Success Criteria)이 얼마나 명확해졌는지를 종합적으로 계산하며, 이 점수가 일정 임계값 아래로 떨어져야만 실행 단계로 넘어간다.
02:12 - 모호도(Ambiguity) 점수가 실시간으로 표시되며 인터뷰가 진행 중인 OMX 인터페이스 화면
04:15 - 매 답변이 누적 기록되며 목표/제약/성공 조건의 명확도를 종합 계산하는 하네스 구성 화면
이 방식의 철학적 근거는 **프리모템(Pre-mortem)**이라는 개념에서 나온다. 포스트모템(Post-mortem)이 장애나 실패가 발생한 후 원인을 분석하는 과정이라면, 프리모템은 “서버가 다운된다면 어떤 이유일까? 누가 창문을 깨고 들어와서 물을 부을 수도 있어”처럼 실행 전에 잠재적 실패 시나리오를 미리 시뮬레이션하는 과정이다. 허혜찬에 따르면, 프리모템 과정을 충분히 늘릴수록 나중에 수정하고 확인해야 하는 포스트모템의 빈도가 줄어들고, 이것이 결과적으로 인지적 부하를 낮춘다. “내가 어떤 과업을 완수하는 데 드는 인지적 부하의 총량을 줄이자”는 것이 OMX 설계의 핵심 원칙이다.
이 과정에서 흥미로운 점은 인터뷰가 사용자 스스로도 미처 생각하지 못했던 부분을 드러낸다는 것이다. 영상에서 김현규가 실제로 인터뷰를 받는 장면에서 그는 “잘 작동한다고 판단하는 기준을 생각해본 적이 없었다”고 고백했다. 이것이 바로 허혜찬이 강조하는 포인트다. 사람들이 무의식적으로 넘겨짚는 부분을 명시적으로 끄집어내지 않으면, AI는 어딘가의 베스트 프랙티스(Best Practice)를 기반으로 결과물을 만들어내고, 이는 사용자가 실제로 원하는 것과 다를 가능성이 높다. 허혜찬은 이를 “그랬을 때 가장 불만이 많이 생깁니다”라고 표현했다.
인터뷰를 마치고 요구사항이 충분히 명확해지면, OMX는 스펙을 작성하고 이를 실행 가능한 계획으로 변환한다. 이 계획 단계에서는 정반합(Thesis-Antithesis-Synthesis) 구조가 적용된다. 플래너(Planner) 에이전트가 계획을 수립하면, 아키텍트(Architect) 에이전트가 이를 검토하여 문제점을 지적하고, 두 에이전트를 조율하는 세 번째 에이전트가 최종 합의를 도출한다. 허혜찬은 이를 검사, 변호사, 판사의 삼자 구조에 비유했다. 계획이 합의에 이를 때까지 이 순환이 반복되기 때문에 시간이 오래 걸리지만, 그만큼 이후에 수정할 일이 줄어든다는 것이 핵심 트레이드오프다.
OMO의 자율 실행 하네스 - “딸깍, 알아서 해”
김현규의 OMO는 대조적으로 간결함을 추구한다. 오토파일럿(Auto-pilot) 스킬을 통해 최소한의 입력으로 AI가 필요한 리서치를 수집하고 계획을 세워 실행까지 마무리하게 만드는 것이 설계 목표다. “딸깍 하면 만들어진다”는 표현처럼, 사용자의 개입을 최소화하는 방향이다. 허혜찬은 솔직하게 “술 먹고 빨리 뭔가 만들어야 한다면 OMO를 쓸 수밖에 없습니다”라고 말했고, 이는 두 도구가 경쟁 관계가 아니라 상호 보완 관계임을 시사한다.
이 방식의 실용적 가치는 명확하다. 피곤하거나 시간이 없는 상황, 혹은 도메인 지식이 부족해서 세밀한 인터뷰에 답하기 어려울 때 OMO는 베스트 프랙티스를 기반으로 빠르게 결과물을 만들어낸다. 반면 사용자가 특정한 방향을 꼬고 싶거나 베스트 프랙티스가 오히려 틀린 답일 수 있는 연구 영역에서는 인터뷰 방식이 더 적합하다고 두 사람 모두 동의했다.
김현규가 강조한 OMO의 또 다른 강점은 지속성이다. 한 번 설치하면 삭제하기 어렵게 설계되어 있으며, 대신 이슈 트래킹 시스템을 통해 사용자들이 문제를 적극적으로 보고하고, Claude Code 기반으로 빠르게 수정이 이루어지는 구조다. 사실상 커뮤니티 기반의 빠른 유지보수 사이클이다. npm 다운로드 수 기준으로 약 200만(업데이트 포함 수치)이 기록되고 있으며, 이를 기반으로 실 사용자 수는 약 3~4만 명으로 추산된다고 김현규는 밝혔다. 허혜찬의 OMX는 GitHub 스타 수 기준으로 OMO의 절반 수준이라고 언급되었다.
실시간 미니 해커톤: 추임새 제거 편집 도구
영상의 하이라이트 중 하나는 두 가지 하네스를 활용하여 실시간으로 간단한 유틸리티 앱을 만드는 과정이다. 주제는 김현규가 제안한 “영상 편집 시 추임새(음, 어, 아 같은 의미 없는 소리)를 자동으로 제거하는 오디오 편집 도구”였다. 기존 AI 편집 도구들이 완전히 무음 구간은 잘 잘라내지만, 소리가 있는 추임새 구간은 처리하지 못한다는 실무 불편함에서 출발한 아이디어다.
OMX 방식으로 이 요구사항을 인터뷰로 정제하는 과정에서 흥미로운 일이 벌어졌다. AI는 독립 실행형 앱인지, 기존 편집 소프트웨어의 플러그인인지, SaaS 형태인지를 물어봤고, “잘 작동한다는 기준”에 대한 질문은 김현규로 하여금 미처 구체화하지 않았던 성공 조건을 생각하게 만들었다. 모호도 점수가 임계값 이하로 내려가자 스펙 작성 단계로 넘어갔고, 이후 Codex 에이전트가 플래너와 아키텍트 에이전트를 스폰(Spawn)하며 병렬로 계획을 검토하고 실행에 들어갔다.
10:45 - 팀 모드에서 여러 서브 에이전트가 동시에 실행되며 서로 메시지를 주고받는 화면
12:07 - 플래너와 아키텍트 에이전트 간 플랜 리뷰 및 합의 과정이 진행 중인 화면 - 우선순위 정렬 피드백 반영
결과적으로 Whisper를 활용한 음성 인식 기반의 추임새 제거 도구가 실제로 작동하는 데모까지 완성되었다. 데모에서는 정상 발화는 그대로 유지되고 “음”, “어”, “아” 같은 추임새만 제거된 클린 버전이 성공적으로 출력되었다. 더 인상적인 것은 단순히 무음 구간을 자르는 게 아니라, “음악이라는 단어”처럼 의미가 있는 발화는 자르지 않는 로직이 적용되었다는 점이다. 말의 맥락을 파악하여 추임새와 의미 있는 발화를 구분하는 방식으로, 하네스가 전달한 계획서에 이 부분이 명시되었기 때문이다.
19:44 - 추임새 제거 도구의 더티 데모 오디오 재생 화면 - 추임새가 제거된 클린 버전 비교 확인
팀 모드와 서브 에이전트 아키텍처
허혜찬이 시연한 팀 모드(Team Mode)는 기존의 서브 에이전트(Sub-agent) 방식과 어떻게 다른가. 기존 서브 에이전트 방식은 메인 에이전트가 하위 에이전트들에게 독립적인 작업을 분배하고, 모든 작업이 완료된 후 병합하는 구조다. 팀장이 4명의 팀원에게 일주일치 업무를 나눠주고 “일주일 뒤에 보자”고 하는 것과 같다. 문제는 중간 확인 없이 병합하는 시점에 충돌이 생길 수 있다는 것이다.
팀 모드는 여기서 한 발 더 나아간다. 에이전트들이 실시간으로 서로 메시지를 주고받으며 작업 상황을 공유한다. “막혔어요, 도와줘요”와 같은 실시간 소통이 가능하기 때문에, 의존성이 있는 작업들을 보다 유연하게 병렬 처리할 수 있다. 허혜찬은 이 과정을 실제 팀 협업에 비유하며, 사전에 역할과 방향을 충분히 정하지 않으면 나중에 “누가 뭘 해야 하는지 모르는 경우가 많다”는 점에서 AI 팀도 사전 계획이 중요하다고 강조했다. 작업이 완료되면 에이전트들은 즉시 해고된다. “고용노동부로부터 자유로운” 분 단위 계약이다.
TDD(테스트 주도 개발)의 재발견
이 대담에서 흥미롭게 등장한 개념 중 하나는 TDD(Test-Driven Development, 테스트 주도 개발)다. TDD는 개발 코드를 먼저 작성하는 것이 아니라, 그 코드가 통과해야 할 테스트를 먼저 구현하는 방법론으로, 이론적으로는 최적이지만 인지적 부담이 크고 인력과 시간이 많이 필요해서 대기업이 아니면 실천하기 어려운 방법이었다.
허혜찬은 AI 에이전트의 등장이 이 상황을 바꾸고 있다고 분석했다. AI는 사람처럼 피로를 느끼지 않기 때문에, 그동안 “사람의 인지적 한계” 때문에 차선책으로 유지되던 많은 개발 방법론들이 원래의 이론적 최적해로 수렴할 수 있게 되었다는 것이다. “사람이 피곤해진다는 가정을 하고 많은 시스템이 설계되어 있잖아요. 그런 것들에 한계가 없다고 생각했을 때, 최적의 워크플로우는 사람들이 원래 만들었던 것과 약간 다를 수 있거든요.” TDD가 그 대표적인 예이며, 이 관점에서 보면 AI 에이전트는 단순히 코딩을 자동화하는 도구가 아니라 소프트웨어 개발 방법론 전체를 원래 의도했던 형태로 복원하는 계기가 된다.
”이래도 되나”의 감각 - 두 개발자의 내면
두 개발자 모두 AI가 스스로 코드를 작성하는 경험을 처음 했을 때 받았던 충격을 솔직하게 이야기했다. 허혜찬은 어릴 때부터 개발을 해온 사람으로서, “안 돼야 되는 게 됐을 때” 느꼈던 충격이 컸다고 했다. 자신이 오랫동안 쌓아온 역량의 영역이 자동화되는 모습을 보면서 “이게 맞나? 나는 지금까지 뭘 한 거야?”라는 감각이 들었다고 한다.
김현규 역시 퀀트 트레이딩(Quant Trading) 자동화 하네스를 개발하던 중 비슷한 경험을 했다. Cursor를 이용해 만드는 에이전트와 검사하는 에이전트를 서로 싸우게 구성해놨더니, 자고 일어나니 결과물이 만들어져 있었다는 것이다. 개발을 초등학생 때부터 해온 사람으로서 “이게 이래도 되나, 너무 놀란 거예요”라는 표현이 그 충격을 잘 담고 있다. 두 사람 모두 이 충격을 극복하기보다는 “어차피 다 같이 맞이할 미래라면 먼저 해야 한다”는 방향으로 수용했다.
허혜찬은 이와 관련하여 개인적인 활용 사례도 공유했다. 그는 ADHD 치료제 콘서타(Concerta, 메틸페니데이트 계열)를 복용하고 있는데, 약물 농도 변화를 시뮬레이션하는 개인 앱을 직접 만들어 사용하고 있다고 밝혔다. 약동학(Pharmacokinetics) 논문 데이터를 기반으로, 복용 시간에 따른 약물 농도 변화 그래프를 그려 “언제 약을 먹으면 원하는 시간에 집중력이 최고조에 달할지”를 예측하는 도구다.
21:06 - ADHD 약물 농도 시뮬레이션 개인 앱 화면 - 복용 시간에 따른 집중력 변화 그래프
⚠️ [STT 교정] 원본 트랜스크립트에서 “ADAC 약”, “콘서트”로 표기된 부분은 문맥상 각각 “ADHD 약”, “콘서타(Concerta, ADHD 치료제)“로 교정했습니다. 원본 영상에서 직접 확인하시길 권장합니다.
이 사례는 단순한 개인 활용을 넘어 중요한 포인트를 담고 있다. 도메인 지식이 깊을수록 AI가 만들어주는 결과물의 가치도 훨씬 높아진다는 것이다. 허혜찬은 “아는 도메인이면 그 공포가 확 온다”고 표현했다. 전문 지식이 있는 사람은 AI가 그 지식 영역에서 얼마나 정확하고 정교한 결과물을 만드는지 즉시 체감할 수 있기 때문이다.
두 하네스의 적합한 사용 시나리오
두 개발자와 진행자는 자연스럽게 어떤 상황에 어떤 도구가 더 적합한지에 대한 결론에 다가갔다. 도메인 지식이 부족하거나, 빠르게 베스트 프랙티스를 적용하고 싶거나, 간단한 작업을 신속하게 처리해야 할 때는 OMO 스타일이 효율적이다. 반면 연구자나 전문가처럼 자신만의 특정한 방향이 있고, 베스트 프랙티스가 오히려 틀린 답일 수 있는 상황, 혹은 처음부터 복잡한 소프트웨어를 구축할 때는 OMX의 철저한 인터뷰와 프리모템이 더 적합하다.
실제로 OMX 사용자층에는 해외 물리학 연구자와 병원 연구 교수가 포함되어 있다고 알려졌다. 연구 영역에서는 제약 조건을 명확히 하고 탐색 범위를 한정하는 것이 중요하기 때문에, 인터뷰 방식이 잘 맞는다는 분석이다. 허혜찬은 “내가 어떤 연구를 한다면, 베스트 프랙티스가 오히려 틀린 정보일 수 있다. 거기서 내가 조금 더 꼬고 싶을 수도 있잖아요”라며 이 점을 강조했다. 반대로 김현규는 OMO가 “진짜 다 탐색해야 되는” 열린 문제에는 제약이 오히려 독이 될 수 있다고 인정했다. 넷플릭스에서 별점 높은 작품을 고르는 사람과 장르 취향으로 고르는 사람이 다르듯, 상황과 사용자에 따라 최적의 도구가 다르다는 것이다.
마무리 - 인지적 부하를 설계하다
이 영상에서 두 개발자가 공통적으로 추구하는 것은 결국 하나다. 인간의 인지적 부하를 줄이면서도 원하는 결과물의 품질을 높이는 것. 방법론은 다르지만 OMX는 전면부에 집중하여 인터뷰와 프리모템에서 인지 에너지를 쏟고 실행은 AI에게 맡기고, OMO는 AI의 자율 실행 능력을 최대화하여 사용자의 개입 자체를 줄이는 방향이다. 허혜찬이 표현한 것처럼 “인터뷰할 때는 10분~20분 집중해서 나의 모든 디테일을 다 넣어주고, 실행하는 과정에서는 얘 혼자 10분, 20분, 몇 시간 돌게 만들자”는 설계 원칙이 두 도구 모두를 관통하는 공통 철학이다.
두 사람 모두 가장 중요한 것은 도구가 아니라 그 도구를 어떻게 상황에 맞게 활용하느냐라는 점에 동의했다. “원래 잘하는 사람은 잘한다”는 담백한 말처럼, 하네스는 만능 해결사가 아니라 능력을 증폭하는 도구다. 그리고 그 증폭의 크기는 사용자의 도메인 지식과 문제 정의 능력에 비례한다.
각자의 목표도 선명하다. 허혜찬은 “1인 회사 중 가장 큰 회사”를 만들고 싶다고 했다. AI를 활용한 병렬 작업을 극한까지 밀어붙여 1인이 기존에 팀이 해야 했던 일을 혼자서 해내는 미래를 향해 나아가고 있다. 김현규는 세상이 크게 바뀌는 그 순간에 “같이 있고 싶다”는 욕심이 있다고 했다. 기술의 확산과 대중화, 더 많은 사람들이 이 도구들을 활용하는 것을 지켜보고 기여하는 것이 그의 동기다. “이 많은 사람들이 이거 가지고 얼마나 많은 태스크를 하겠으며, 이거 쓰고서 연봉 올랐다는 피드백을 듣는 게 진짜 너무 좋다”는 말에서 두 개발자가 공유하는 동력이 느껴진다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 질문 빌런 하네스 VS 아 몰라 하네스 |
| 채널 | 안될과학 Unrealscience |
| 출연 | 허혜찬(OMX/OMC), 김현규(OMO) |
| 리포트 작성 | 2026-05-20 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.