하네스 엔지니어링은 앞으로 AI 에이전트와 함께 일하는 사람에게 중요한 개념이 될 가능성이 높습니다. 지금까지 많은 사람은 “AI에게 어떻게 더 잘 말할 것인가”에 집중했습니다. 하지만 AI가 실제 코드를 만들고, 테스트하고, 수정하고, 보고하는 단계로 들어오면 질문이 달라집니다.
이제 중요한 것은 “AI에게 무엇을 말할 것인가”만이 아닙니다. AI가 제대로 일할 수밖에 없는 환경을 어떻게 만들 것인가입니다.
Read in English: This article is also available in English for global readers.
이 글은 Jay Choi | 인디해커 라이프의 영상 「하네스 엔지니어링: 바이브 코딩에서 에이전틱 코딩으로」를 바탕으로, 바이브 코딩 이후 개발자가 어떤 방식으로 AI 에이전트를 다뤄야 하는지 정리한 글입니다. 관련 흐름은 이전 글 「에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식」과 함께 읽으면 더 잘 연결됩니다.
하네스 엔지니어링이란 무엇인가
하네스 엔지니어링은 AI 모델이나 에이전트가 움직이는 작업 환경 전체를 설계하는 일입니다. 여기서 말하는 환경은 단순한 채팅창이 아닙니다. 프로젝트 폴더 구조, 규칙 문서, 테스트 명령, 도구 목록, MCP, 스킬, 훅, 리뷰 절차, 자동 검증 흐름까지 포함합니다.
프롬프트 엔지니어링이 “모델에게 잘해 달라고 말하는 기술”에 가깝다면, 하네스 엔지니어링은 “모델이 잘할 수밖에 없는 구조를 만드는 기술”에 가깝습니다.
부탁이 아니라 구조를 만드는 일
AI에게 “테스트까지 확인해 줘”라고 말할 수는 있습니다. 하지만 에이전트가 실제로 테스트를 실행했는지, 실패를 어떻게 해석했는지, 결과를 기준에 맞게 보고했는지는 별개의 문제입니다.
하네스 엔지니어링은 이 지점을 구조로 해결하려고 합니다. 예를 들면 이렇게 볼 수 있습니다.
- 작업이 끝나면 반드시 테스트 명령을 실행하게 한다.
- 변경된 파일과 테스트 결과를 보고 양식에 맞춰 남기게 한다.
- 위험한 명령은 실행 전 확인 절차를 거치게 한다.
- 너무 많은 도구를 주지 않고, 작업 목적에 맞는 도구만 제공한다.
- 프로젝트 규칙을 문서화해 에이전트가 항상 읽을 수 있게 한다.
이런 구조가 있으면 매번 사람이 프롬프트로 잔소리하지 않아도 됩니다. 에이전트가 그 환경 안에서 자연스럽게 올바른 절차를 따르게 됩니다.
바이브 코딩은 바닥을 올리고, 하네스 엔지니어링은 천장을 올린다
영상의 핵심 표현 중 하나는 “바이브 코딩은 바닥을 올리고, 에이전틱 엔지니어링은 천장을 올린다”는 말입니다.
바이브 코딩은 개발 경험이 적은 사람도 앱을 만들 수 있게 해 주었습니다. 자연어로 요구사항을 말하면 AI가 코드를 제안하고, 화면을 만들고, 오류를 고쳐 줍니다. 이 변화는 분명히 진입 장벽을 낮췄습니다.
하지만 진입 장벽이 낮아졌다고 해서 좋은 소프트웨어가 자동으로 만들어지는 것은 아닙니다. 실제 서비스에서는 보안, 결제, 예외 처리, 유지보수, 테스트, 배포, 사용자 경험이 모두 더 봐야 합니다.
코드 생성보다 검증이 더 어려워진다
AI가 코드를 빠르게 만드는 시대에는 “코드를 작성하는 능력”보다 “코드가 쓸 만한지 판단하는 능력”이 더 더 봐야 합니다. AI가 그럴듯한 코드를 만들 수는 있지만, 그 코드가 실제 요구사항을 만족하는지 확인하는 책임은 여전히 사람과 시스템에 남습니다.
하네스 엔지니어링은 바로 이 검증 문제를 다룹니다. 에이전트가 작업을 완료했다고 말할 때, 그 말만 믿지 않고 실제 실행 결과와 테스트 결과를 확인하게 만드는 것입니다.
프롬프트를 더 길게 쓰는 것으로는 부족하다
많은 사용자는 AI 결과가 마음에 들지 않으면 프롬프트를 더 자세히 씁니다. 역할을 부여하고, 예시를 넣고, “실수하지 말라”고 지시합니다. 물론 이런 방식도 도움이 됩니다.
하지만 매번 사람이 개입해야 한다면 한계가 있습니다. 같은 유형의 실수를 반복해서 고쳐야 하고, 작업이 길어질수록 맥락이 흐려지며, 에이전트가 실제로 무엇을 했는지 확인하기 어렵습니다.
좋은 프롬프트보다 좋은 작업장
영상에서는 프로젝트 전체가 하나의 거대한 프롬프트가 된다고 설명합니다. 에이전트는 채팅창의 문장만 읽는 것이 아닙니다. 폴더 구조, 파일 이름, README, 규칙 문서, 기존 코드 스타일, 테스트 파일, 설정 파일을 모두 참고합니다.
정리된 프로젝트에서는 에이전트도 정리된 방식으로 일할 가능성이 높습니다. 반대로 프로젝트가 어지럽고 규칙이 없으면, 에이전트도 어지러운 결과를 만들기 쉽습니다.
그래서 하네스 엔지니어링의 첫걸음은 거창한 자동화가 아닐 수 있습니다. 오히려 프로젝트를 정리하고, 규칙을 문서화하고, 반복 작업을 스크립트로 만들고, 검증 절차를 명확히 하는 것에서 시작됩니다.
도구는 많을수록 좋은 것이 아니다
AI 에이전트에게 많은 도구를 연결하면 더 강력해 보입니다. 검색, 터미널, 브라우저, 파일 편집, 배포, 데이터베이스, 메신저까지 모두 붙이면 무엇이든 할 수 있을 것처럼 느껴집니다.
하지만 실제로는 도구가 너무 많으면 에이전트가 어떤 도구를 써야 할지 판단하는 데 에너지를 씁니다. 사람도 선택지가 많을수록 결정을 미루듯, AI도 불필요한 선택지 앞에서 흔들릴 수 있습니다.
작업별로 좁고 정확한 도구를 준다
좋은 하네스는 모든 도구를 한꺼번에 열어 주지 않습니다. 작업 목적에 맞춰 필요한 도구만 제공합니다.
예를 들어 코드 리뷰 에이전트라면 파일 읽기, diff 확인, 테스트 로그 분석이 더 봐야 합니다. 반면 배포 권한이나 외부 메시지 전송 권한은 필요하지 않을 수 있습니다. 데이터 수집 에이전트라면 웹 검색과 저장 도구는 필요하지만, 운영 서버 명령 권한은 제한하는 편이 안전합니다.
도구를 줄이는 것은 성능을 낮추는 일이 아닙니다. 오히려 에이전트가 더 빠르게 판단하고, 실수할 표면을 줄이며, 사람이 신뢰할 수 있는 결과를 만드는 방법입니다.
하네스 엔지니어링의 실무 체크리스트
개발자는 AI 팀 리더가 된다
하네스 엔지니어링을 실제 업무에 적용하려면 다음 항목부터 점검해 볼 수 있습니다.
| 점검 항목 | 질문 | 예시 |
|---|---|---|
| 목표 정의 | 에이전트가 끝내야 할 작업이 명확한가? | “로그인 오류 수정”보다 “재현 절차 확인 후 테스트 통과까지” |
| 도구 제한 | 이 작업에 꼭 필요한 도구만 열려 있는가? | 코드 수정 에이전트에 배포 권한 제외 |
| 규칙 문서 | 프로젝트 규칙을 에이전트가 읽을 수 있는가? | README, AGENTS.md, CLAUDE.md, 테스트 가이드 |
| 검증 루프 | 작업 후 자동으로 확인하는 절차가 있는가? | lint, unit test, build, smoke test |
| 보고 형식 | 결과를 사람이 판단하기 쉽게 남기는가? | 변경 파일, 실행 명령, 실패/성공 로그 요약 |
| 인간 판단 | AI가 결정하면 안 되는 영역이 분리되어 있는가? | 결제 정책, 환불 기준, 보안 예외, UX 우선순위 |
이 표에서 중요한 것은 자동화 자체가 아닙니다. AI에게 맡길 일과 사람이 판단할 일을 분리하는 것입니다.
영상의 마지막 메시지는 강합니다. 생각은 AI에게 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다는 것입니다.
코드 작성, 분석, 리뷰 초안 작성은 AI가 점점 더 잘하게 됩니다. 하지만 왜 이 기능이 필요한지, 어떤 예외를 고려해야 하는지, 어떤 구조가 장기적으로 유지보수에 유리한지는 사람이 이해해야 합니다.
직접 코딩하는 사람에서 작업 환경을 설계하는 사람으로
앞으로 개발자의 역할은 “모든 코드를 직접 치는 사람”에서 “AI 에이전트 팀이 제대로 일하도록 환경을 만드는 사람”으로 이동할 가능성이 높습니다.
이 변화는 개발자에게만 해당하지 않습니다. 기획자, 창업자, PM, 데이터 분석가도 마찬가지입니다. AI에게 일을 맡기려면 작업 기준, 검증 방법, 보고 방식, 권한 범위를 설계해야 합니다.
결국 하네스 엔지니어링은 AI 시대의 협업 설계입니다. AI가 잘하는 실행은 AI에게 맡기되, 사람이 이해하고 책임져야 할 부분은 구조 안에 남겨 두는 방식입니다.
결론: AI에게 “해줘”라고 말하는 시대의 다음 단계
바이브 코딩은 많은 사람에게 만들기의 문을 열었습니다. 하지만 실제 결과물을 안정적으로 운영하려면 다음 단계가 해야 합니다. 그 단계가 하네스 엔지니어링입니다.
좋은 하네스는 에이전트에게 자유를 주되, 방향과 경계를 함께 제공합니다. 필요한 도구만 주고, 프로젝트 규칙을 읽게 하며, 작업 후에는 테스트와 리뷰를 통과하게 만듭니다. 사람은 모든 중간 과정을 붙잡는 대신 최종 판단과 중요한 설계에 집중합니다.
AI에게 “해줘”라고 말하는 것만으로는 충분하지 않습니다. 이제는 AI가 제대로 해낼 수 있는 환경을 설계해야 합니다. 하네스 엔지니어링은 바로 그 환경을 만드는 일입니다.
참고자료
함께 읽으면 좋은 글
이 주제와 함께 읽으면 맥락을 넓히는 데 도움이 되는 thinknote.co.kr의 관련 글입니다.
