하네스 엔지니어링과 개발자의 미래

AI가 내 일을 다 한다는데, 나는 뭘 해야 하지?

AI가 코드를 짜고, 테스트를 돌리고, 심지어 커밋까지 합니다. "LLM이 다 해준대요." 사장님은 바이브코딩으로 개발하라고 합니다. 이런 말들 사이에서 개발자로서 불안하지 않으면 거짓말이겠죠.

근데 저는 실제로 LLM과 함께 일하면서, 좀 다른 생각을 갖게 됐습니다. AI가 잘 달리려면 누군가는 길을 깔아줘야 한다는 것. 그리고 그 일이 꽤 재밌다는 것.

어떤 경험이었냐면요,

zustand이라는 라이브러리를 쓰고 있는데, Next.js 같은 SSR 환경에서는 전역 모듈로 활용하면 문제가 생깁니다. 전역변수처럼 다른 사용자의 데이터로 오염될 수 있는 여지가 있거든요. 그래서 zustand에서도 React Context와 조합해서, 사용자 요청별로 전역 객체를 생성하게 해서 오염을 격리하는 사용법이 있고, 저는 여기에 제가 원하는 규칙을 덧대어서 LLM한테 가이드를 하고 있었습니다.

근데 문제는, zustand 문서의 예시가 CSR 기준으로 되어 있다 보니까, LLM이 많은 요청을 한번에 수행하면 제 지침을 누락하더라고요. 프롬프트에 "제발 좀 지켜줘"라고 넣어도, 모델 성능이 발전해도, 이 누락이 0이 되지 않았습니다.

그래서 eslint rule을 짰습니다. 컴파일 결과를 받고, 제가 원하는 형태로 zustand가 쓰이지 않았을 때 에러가 뜨게 했습니다. 덕분에 AI가 실수하는 일은 없어졌는데... 실수하고 → 아차 하고 → 다시 고치고, 이게 토큰이 아까웠습니다. 무엇보다 한번에 끝낼 수 있었던 일을 두 번에 걸쳐서 하게 되니까요.

그래서 아예 라이브러리를 새로 만들었습니다. 애초에 전역 모듈에서 import하는 사용법 자체를 막아버렸습니다. 그랬더니 LLM이 원하는 대로 한번에 움직이더라고요. 그거 아니면 사용할 수가 없으니까요.

이런 경험을 하면서 하네스 엔지니어링이라는 개념에 관심을 갖게 됐습니다.

하네스 엔지니어링이 뭔데?

앤트로픽이 공식 엔지니어링 블로그에서 하네스 엔지니어링을 다루고 있습니다:

"모든 하네스 구성 요소는 모델이 단독으로 할 수 없는 것에 대한 가정을 인코딩한다"
— Harness design for long-running application development

"모델의 성능을 기준선보다 훨씬 높이기 위해서는 프롬프트 엔지니어링과 하네스 디자인이 필수적이다"
— Effective harnesses for long-running agents

에이전트와 하네스의 차이

이해를 돕기 위해, 에이전트와 하네스를 구분해보겠습니다.

최근 Claude Code 소스가 유출되면서 내부 구조가 공개됐는데(분석 글), 4,600개 이상의 파일, 512,000줄 규모의 코드에서 핵심 기술들이 드러났습니다.

에이전트 기술은 LLM의 능력 자체를 올려주는 쪽입니다:

• 에이전트 루프: 1,729줄의 while(true) 루프 — 압축 → API 호출 → 에러 복구 → Hook 검증 → 도구 실행 → 상태 전이, 이 6단계 파이프라인을 계속 반복합니다
• 4단계 메시지 압축: 컨텍스트 윈도우가 가득 차면 Snip → Microcompact → Context Collapse → Auto-Compact 순서로 대화를 압축해서 맥락을 유지합니다
• QueryEngine: 46,000줄 규모로 LLM API 호출, 스트리밍, 캐싱, 오케스트레이션을 전부 관리합니다
• 코디네이터-워커 모델: 멀티 에이전트가 메일박스 패턴으로 위험한 작업을 승인받고 실행합니다

이런 것들은 LLM이 더 똑똑하게, 더 오래, 더 정확하게 작업할 수 있도록 LLM 안쪽에서 접근하는 기술입니다.

하네스 엔지니어링은 반대로 LLM 바깥에서 접근합니다. 앤트로픽 블로그의 실제 예시를 보면:

• Feature List: 200개 이상의 세부 기능을 JSON으로 나열하고, 에이전트가 하나씩 완료 표시하게 합니다. 마크다운이 아니라 JSON인 이유는 변조 저항성이 높기 때문입니다
• Progress File: claude-progress.txt에 에이전트가 한 일의 로그를 기록합니다. 새 세션이 시작되면 이걸 읽고 맥락을 빠르게 파악합니다
• 스프린트 계약: 코드를 작성하기 전에 "완료"가 뭔지 구체적 기준을 정합니다. 27개 같은 세부 기준으로 성공을 정의하고 나서야 구현에 들어갑니다
• Planner → Generator → Evaluator 구조: 계획하는 에이전트, 구현하는 에이전트, 평가하는 에이전트를 분리합니다. 평가자는 Playwright MCP로 실제 브라우저를 띄워서 사용자처럼 클릭하면서 검증합니다
• Init.sh: 새 세션에서 개발 서버를 자동으로 띄우고, 기본 테스트를 돌려서 환경이 정상인지 확인합니다

앤트로픽이 직접 밝히는데, 이건 "효율적인 소프트웨어 엔지니어가 매일 하는 일"에서 영감을 받은 것이라고 합니다. 명확한 진행 상황 기록, 작은 단위의 커밋, 세션 간 문맥 전달 — 사람이 일을 잘하기 위해 하는 것들을 AI한테도 적용한 거죠.

차이가 보이시나요? 에이전트는 LLM을 직접 다루는 기술이고, 하네스는 LLM이 일을 잘할 수 있는 환경을 만드는 겁니다. 그리고 사람이 일할 때도 유용한 것들이에요. 진행 기록 남기고, 완료 기준 정하고, 세션 간 맥락 넘기는 건 사람한테도 좋은 습관이니까요.

그런데 저는 여기서 조금 더 넓게 봅니다

앤트로픽이 말하는 하네스는 주로 특정 도메인의 지침 구축, 의사결정 노하우 정리, 에이전트 자율주행 환경 설계 — 이런 쪽입니다.

근데 LLM이 코드를 짤 때 뭘 쓰나요? React 쓰고, Vite 쓰고, Spring 쓰고, Next.js 쓰잖아요. LLM이 쓰는 도구를 만드는 것도 하네스 엔지니어링이라고 생각합니다. 라이브러리, 프레임워크, 개발 도구 — 종래의 개발자들이 해오던 이 일들이, AI 시대에 와서 보면 하네스 엔지니어링에 기여하고 있었던 거라고 봅니다.

개발 도구를 만드는 것도 하네스 엔지니어링이다

앤트로픽의 아이러니

올해 2월에 앤트로픽이 코볼 현대화 도구를 발표했습니다. "수천 줄의 코볼 코드를 AI가 분석하고, 인간이 몇 달 걸릴 일을 신속하게 처리할 수 있다." IBM 주가가 하루 만에 13.2% 폭락할 만큼 임팩트가 컸습니다.

근데 아시나요? 앤트로픽의 Claude 데스크톱 앱, Electron으로 만들어져 있습니다. 444MB짜리, 느리고 무겁기로 유명한 그 Electron입니다. 테크 블로거 John Gruber는 아예 "Electron Turd"라고 불렀을 정도입니다.

AI가 개발자를 대체한다면서, 자기네 앱은 왜 Electron을 못 벗어날까요? "왜 Claude는 Electron 앱인가?"라는 글에서는 이렇게 분석합니다. "에이전트는 개발의 처음 90%에는 뛰어나지만, 마지막 10% — 엣지 케이스 처리와 지속적 지원 — 은 여전히 어렵다." 결국 개발자 친숙도와 유지보수 단순성 때문에 기존 프레임워크를 쓸 수밖에 없다는 겁니다.

기존 도구와 프레임워크의 생태계는 그만큼 강력하고, AI가 등장했다고 쉽게 대체되는 게 아닙니다.

LLM의 학습 구조를 생각해보면 답이 나옵니다

LLM이 어떻게 발전해왔는지 한번 보겠습니다.

처음에는 다음 단어 예측기였습니다. A라는 문장 뒤에 B라는 문장이 올 확률을 학습하는 거였습니다. 그러다가 "A라는 질문 → B라는 답변"으로 바뀌었고, 지금은 "A라는 요청 → B라는 행동"으로 진화했습니다. 행동이라고 해도 결국 문자열이긴 한데, 잘 정의된 문자열을 에이전트가 파싱해서 프로그램을 실행하는 방식입니다.

"웹사이트 만들어줘"라고 하면 LLM이 뱉는 행동은 이런 식입니다:

• Vite로 프로젝트 생성
• React 설치
• 컴포넌트 구성
• ...

여기서 중요한 포인트가 있습니다. "범용 AI"라는 게 특수한 지식이 없다는 뜻이 아닙니다. 오히려 반대입니다. React로 웹 만드는 법, Spring으로 서버 구성하는 법, Next.js로 SSR 처리하는 법 — 이런 특수한 지식을 어마어마하게 학습했기 때문에 범용이 된 겁니다.

그러면 React 없이 순수 JavaScript로만 웹을 만들거나, Spring 없이 순수 Java로만 서버를 구성하게 학습시킬 수 있을까요? 이론적으로는 가능하겠지만, 그런 학습 데이터가 압도적으로 부족합니다. 자바로 웹 서버 만드는 사람 대부분이 Spring을 쓰니까요.

프레임워크가 오히려 AI 성능을 올려줍니다

단순히 "AI가 프레임워크를 벗어날 수 없다"가 아닙니다. 프레임워크가 AI의 성능을 끌어올려주는 존재입니다.

프레임워크가 코딩 규칙을 강제하면 → AI가 실수할 여지가 줄어듭니다.
리액트가 더 많은 API를 일관되게 제공하면 → AI가 더 빠르고 정확하게 코드를 짭니다.

잘 만든 프레임워크는 AI한테 가드레일이자 고속도로입니다. 규칙이 명확할수록, 인터페이스가 일관될수록, AI는 더 잘 달립니다.

그래서 라이브러리를 만들고, 프레임워크를 개선하고, 개발 도구를 설계하는 것 — 개발자들이 원래 해오던 이 일들이 AI 시대에 와서는 하네스 엔지니어링이 됩니다.

그래서 우리는 뭘 할 수 있는가

개발을 좋아하면서 AI와 상생하는 방법이 뭘까요?

AI가 할 수 있는 일을 내가 직접 하는 게 아니라, AI가 할 수 없는 일을 할 수 있게 만드는 겁니다.

생각해보면, 예전에는 이런 데 투자할 시간이 없었습니다. 매일 API 짜고, 테이블 설계하고, 화면 기획하고, 피그마 반영하고... 당장의 비즈니스 요구사항 처리하느라 시간이 없었거든요.

근데 이제 LLM한테 이런 일들을 위임할 수 있게 되면서, 드디어 시간이 생겼습니다. 그 시간에 뭘 할 수 있냐면:

AI가 우리 회사의 코딩 컨벤션을 따르도록 시스템 프롬프트를 설계하고, 특정 워크플로우를 정확히 수행하도록 에이전트를 구성하고, 실수할 수 없는 구조의 라이브러리를 만들고, 결과물을 검증하는 시스템을 구축하는 겁니다.

직접 코딩하는 사람에서, AI가 잘 일할 수 있는 환경을 만드는 사람으로. 개발자의 포지션이 바뀔 수 있다고 생각합니다.

실제 사례들

AutoBE — 애초에 실수할 수 없는 구조

AutoBE라는 오픈소스가 있습니다. LLM한테 코드를 직접 짜게 하는 대신, AST(추상 구문 트리)를 생성하게 합니다.

LLM이 코드를 텍스트로 생성하면 문자열이 깨지거나 구문 오류가 생길 수 있습니다. 근데 AST로 생성하면 각 노드가 타입 규칙에 따라 검증되니까 애초에 컴파일 에러가 날 수가 없습니다. 실제로 100% 빌드 성공률을 달성하고 있습니다.

AI를 더 잘하게 만드는 게 아니라, AI가 실수할 수 없는 환경을 설계하는 것. 하네스 엔지니어링의 좋은 예시라고 생각합니다.

Flitter — 바이브코딩으로 차트를 커스텀할 수 있다면

LLM은 HTML을 꽤 잘 다룹니다. 근데 SVG나 Canvas로 원하는 인터랙션을 구현하라고 하면 갑자기 품질이 떨어집니다. 복잡한 그래픽 인터랙션 코드는 학습 데이터가 상대적으로 적으니까요.

저는 Flitter라는 Canvas/SVG 렌더링 엔진을 만들었는데요, 이걸로 차트 라이브러리도 만들었습니다. 목표는 사람들이 바이브코딩만으로 원하는 부분을 커스텀할 수 있게 API를 제공하는 것이었습니다.

실제로 AI가 Flitter 코드를 꽤 잘 짭니다. 문서를 보다 보면 왜 AI가 잘 짜는지 알 수 있을 겁니다. 약간 꼼수를 부렸거든요.

개발자의 역할은 사라지지 않습니다

LLM이 등장해서 개발자의 역할이 사라지는 게 아닙니다. 이동하는 겁니다.

매일 API 짜고, 테이블 설계하고, 피그마 반영하느라 정작 하고 싶었던 개발은 못 했잖아요. 이제 그 시간에 진짜 재밌는 걸 할 수 있게 된 겁니다. AI가 처음부터 하기 어려운 일을 쉽게 할 수 있도록 도구를 만들고, 실수할 수 없는 구조를 설계하고, 일관되게 높은 품질을 낼 수 있도록 환경을 조성하는 것.

오히려 LLM 덕분에 그동안 하고 싶었지만 못 했던 — 색다른 개발에 집중할 수 있게 된 거 아닐까요?

여러분은 어떤 하네스를 만들고 있나요?