시리즈 첫 번째 글에서 나는 Prolog에서 기술을 다시 짓기 시작하게 만든 불편함을 이야기했다. 그 끝에서, 각 부분을 하나씩 풀어보겠다고 약속했다. 내가 이해하는 데 가장 오래 걸린 것부터 시작한다: 하네스.
먼저 밝혀둔다, 여기 마법 같은 공식은 없다. 내가 읽은 것, 다른 회사들이 하는 걸 본 것, 그리고 우리가 시도하고 있는 것, 성공과 실패를 섞어가며 하는 이야기다.
나는 느끼기는 하는데 뭐라고 말해야 할지 모르는 무언가를 부를 이름을 몇 달 동안 찾아 헤맸다.
빠져 있던 단어
세 명짜리 회사가 예전엔 서른 명이 붙어야 하던 걸 내놓는 걸 나는 계속 봤다. 그리고 그 개선이 모델에 있는 게 아니라는 것도 봤다, 모델은 다들 비슷한 걸 쓰니까. 그건 다른 데 있었고, 나는 그걸 부를 단어가 없었다.
2026년 2월 OpenAI가 Harness Engineering이라는 글을 냈고, 그 단어를 나에게 줬다.
그들의 정의는 짧은 두 줄로 시작한다: “인간이 방향을 잡는다. 에이전트가 실행한다.” 그리고 이어지는 말이 생각하는 방식을 바꾼다: 엔지니어링 팀의 주된 일은 더 이상 코드를 짜는 게 아니라, 환경을 설계하고, 의도를 명세하고, 에이전트가 믿을 만한 일을 하게 만드는 피드백 루프를 짓는 것이다.
거기 각 조각이 다 진짜 노동이다. 에이전트가 돌아갈 환경을 설계하는 것. 단계별 절차 대신, 무엇을 해야 하는지 그 의도를 분명히 하는 것. 그리고 AI에게 제대로 했는지 알려줘서 스스로 고치게 만드는 루프를 짜는 것.
그 문장에서 무엇이 사라졌는지 보라: 코드를 짜는 것. OpenAI가 코드는 중요하지 않다고 말하는 게 아니다. AI가 대부분을 짤 때, 인간의 일이 한 층 위로 올라간다고 말하는 것이다. 그리고 무언가 깨질 때, 질문도 함께 바뀐다. “다시 해봐, 더 신경 써서”가 아니라 “AI가 제대로 하려면 환경에 어떤 능력이 빠져 있었나”가 된다. 버그는 AI 탓(“AI가 멍청해서”)이 아니라 그 주변에 무엇이 빠져 있었는가에 대한 질문이 된다.
그러니까 하네스란, AI가 보고, 이해하고, 실행할 수 있도록 코드와 프로세스와 일을 정리하는 것이다. 사서 쓰는 도구가 아니다. 팀이 내놓는 것에 대한 새로운 사고방식이다.
모델은 하나, 하네스는 다른 것
이걸 머리에 박아넣기에 가장 간결한 문장은 LangChain 엔지니어 Vivek Trivedy에게서 나왔다: “모델이 아니라면, 그건 하네스다.”
모델은 날것의 LLM이다. Opus든, GPT든, 뭐든. 텍스트가 들어가고, 텍스트가 나오고, 끝. 그리고 모델은 거의 모두가 가지고 있다. 커머디티다. 10%를 얻는 쪽과 5배를 얻는 쪽의 차이는 모델에 있지 않다.
하네스에 있다. 하네스는 나머지 전부다: 코드, AI가 호출할 수 있는 도구, AI가 보는 컨텍스트, 훅, 오케스트레이션, AI가 돌아가는 샌드박스, 메모리, 비즈니스 규칙. 일이 다 끝난 채로 당신에게 오기 전에, 그 흐름 속에서 모델을 감싸는 모든 것이다.
당신은 아마 “컨텍스트 엔지니어링”이라는 말을 들어봤을 것이다. 그것도 이것의 일부다, AI가 보는 것을 정리하는 부분. 하네스는 더 크다: 컨텍스트를 포함하지만, 도구, 훅, 샌드박스, 영속성, 오케스트레이션도 포함한다. 컨텍스트는 한 조각이고, 하네스는 전체다.
모델 vs. harness
모델은 커모디티라, 거의 모두가 같은 걸 쓴다. 10% 향상과 5배 향상을 가르는 건, 그것을 감싸는 것들이다.
하네스는 모든 것을 AI가 읽을 수 있게 만드는 일이다
하네스를 원칙 하나로 줄여야 한다면, 이거다: 모든 것을 AI가 읽을 수 있게 만들 것.
앞 글에서 나는 나를 붙잡은 진단을 이야기했다. Prolog의 컨텍스트는 흩어져 있었다. 한 조각은 Notion에, 다른 건 Drive에, 또 다른 건 Jira에, Figma에. 단일한 출처가 없었다. AI와의 모든 새 대화가 0에서 시작했다, AI에게 필요한 정보가 다섯 군데에 있고 어디에도 정리돼 있지 않았기 때문에.
그걸 하네스라는 렌즈로 다시 읽으면, 문제는 뻔해진다. AI가 보지 못했던 것이다. 그리고 AI가 보지 못하는 건, 쓰지 못한다.
CREAO의 CTO Peter Pang은 급진적으로 들리지만 완전히 말이 되는 결정을 이야기했다: 그는 코드 전부를 하나의 모노레포로 합쳤다. 이유는 정리정돈이 아니었다. AI가 한 번에 전부 볼 수 있게 하기 위해서였다.
이게 그 일이다. 영리한 프롬프트가 아니고, 요령이 아니다. 흩어져 있고, 암묵적이고, 사람들 머릿속에만 살아 있는 것을 가져다가, 한 곳에 글로 써서, 에이전트가 닿을 수 있게 읽을 수 있게 만드는 것이다. 때로는 지겹다. 하지만 바로 그게 10% 개선과 5배 개선을 가르는 것이다.
증거: 엔지니어 3명, 100만 줄
나는 천성적으로 하이프를 의심한다. 그래서 이게 유행이 아니라고 나를 설득한 건 숫자가 붙은 사례였다.
OpenAI의 커맨드라인 도구인 Codex CLI를 만든 팀은 엔지니어 세 명이었다. 몇 주 만에, 그들은 약 100만 줄의 코드를 내놨다: 애플리케이션, 인프라, 툴링, 문서. 그리고 손으로 쓴 줄은 0. 그들이 직접 말한 팀의 철학은 “손으로 짠 코드는 없다”였다. 약 1,500개의 풀 리퀘스트였고, 전부 머지됐고, 사람이 타이핑한 건 하나도 없었다. 세 명이 방향을 잡고, AI가 지었다.
혼동을 피하기 위해: OpenAI에는 코드용으로 훈련된 모델인 Codex가 있고, 도구인 Codex CLI가 있다. 세 명은 그 모델을, 그 도구를 통해, 도구 자체를 짓는 데 썼다. 자기 자신으로 자기 자신을 짓는 것.
그리고 여기서 끝나지 않는다. OpenAI 전체에서, Codex는 회사의 풀 리퀘스트 100%를 리뷰한다.
나를 확신시킨 건 OpenAI의 숫자 하나만이 아니었다. CREAO의 Peter Pang이 아무와도 맞추지 않고, 따로 떨어진 경로로 같은 결론에 도달했다는 것이었다. 서로 다른 두 곳이 같은 것을 묘사하고 있었다. 그런 일이 벌어지면, 대개 그건 유행이 아니다. 패턴이다.
세 사람이 방향을 잡고, AI가 짓는다. 손으로 쓴 코드는 0.
no manually-written code 팀이 내건 철학. 그리고 OpenAI 전체에서, Codex가 모든 pull request의 100%를 리뷰한다.
AI-assisted는 AI-first와 같은 게 아니다
여기서 나는 Prolog가 어디에 있는지 솔직해져야 한다.
AI로 일을 거드는 것과 AI를 일의 중심에 두는 것 사이에는 거의 아무도 눈치채지 못하는 차이가 있다.
AI-assisted는 인간이 중심에 있고 AI가 가장자리에 꽂혀 있는 것이다. 같은 스프린트, 같은 보드, 같은 회의, 같은 흐름. AI는 이미 존재하던 프로세스 안에서 돕는다. 개선은 진짜이고 작다: 10, 20%. 대부분의 회사가 여기 있다. Prolog도 오늘 여기 있고, 나는 아닌 척하지 않겠다.
AI-first는 AI가 중심에 있고 인간이 방향을 잡는 것이다. 당신은 에이전트가 주된 빌더라고 전제하고, 그 위에서 프로세스와 아키텍처, 나아가 조직까지 다시 짓는다. 인간은 비평하고, 검증하고, 판단한다. 개선은 차원이 다르다: 5배, 10배. Codex, CREAO, Anthropic이 하고 있는 게 이것이다.
그 차이는, Peter Pang의 말처럼, 증분이 아니라 곱셈이다. 그래서 하네스가 그렇게 중요한 것이다. 이미 존재하는 것에 AI를 꽂아서는 AI-first에 도달하지 못한다. AI가 보고, 이해하고, 실행할 수 있게 다시 지어야 도달한다. 다시 말해, 하네스를 지어야 한다.
그리고 이건 엔지니어링만의 문제가 아니다
OpenAI의 문장, “주된 일은 더 이상 코드를 짜는 게 아니다”는 엔지니어링을 염두에 두고 쓰였다. 하지만 주어를 바꿔서 다시 읽어보니, 그건 기술 조직의 모든 직무에 들어맞았다.
프로덕트는 더 이상 문서만 쓰지 않는다; 에이전트가 해법을 제안할 수 있게 한다. 디자인은 더 이상 화면만 그리지 않는다; 에이전트가 시스템 안에서 인터페이스를 생성할 수 있게 한다. QA는 더 이상 손으로 테스트만 돌리지 않는다; 에이전트가 검증할 수 있게 한다. 데이터는 더 이상 쿼리만 돌리지 않는다; 에이전트가 비즈니스 질문에 답할 수 있게 한다.
이 모두에서 질문은 같아진다: 에이전트가 이걸 하려면 어떤 능력이 빠져 있고, 나는 그걸 에이전트에게 어떻게 보이고 제어 가능하게 만들 것인가.
여기서 내가 가져가는 것
하네스는 사서 쓰는 도구도, 구독하는 더 나은 모델도 아니다. 노동이다. 사람들 머릿속에 있고 열 개의 시스템에 흩어져 있는 것을 가져다가, 한 곳에, 기계가 쓸 수 있게, 읽을 수 있게 만드는 노동.
지겨운 부분은 지름길이 없다는 것이다. 좋은 부분은, 노동인 이상, 할 수 있다는 것이다. 우리는 그 한복판에 있다: AI-first에서는 멀고, 두 달 전보다는 가깝다. 어떻게 되어가는지 계속 이야기하겠다.
출처
- OpenAI, Harness Engineering: leveraging Codex in an agent-first world (2026년 2월). “인간이 방향을 잡고, 에이전트가 실행한다”는 문장과 Codex CLI 팀 사례가 여기서 나왔다.
- Vivek Trivedy, LangChain, The Anatomy of an Agent Harness. “모델이 아니라면, 그건 하네스다”라는 정의.
- Peter Pang, CREAO, AI를 중심에 두는 것에 관하여. AI가 전부 볼 수 있게 한 모노레포와 곱셈적 차이.
- How OpenAI’s Codex Team Works and Leverages AI, Eng Leadership Newsletter. Codex 팀의 숫자.