프롬프트보다 중요한 하네스 엔지니어링, AI 천재들이 바이브코딩하는 법

프롬프트 엔지니어링을 넘어 하네스 설계의 시대

세계 최고의 실리콘밸리 투자사 Y Combinator의 CEO 게리 탄이 자신의 AI 워크플로우를 오픈소스로 공개하면서 전 세계 개발자들이 주목하고 있습니다. 그가 공개한 'G-Stack'은 이미 10만 명이 넘는 사람들이 GitHub에 스타를 누른 화제의 프로젝트입니다. 그런데 여기서 중요한 발견이 있습니다. 상위 0.1% 천재들은 프롬프트를 잘 쓰려고 노력하지 않습니다. 대신 AI가 스스로 판단하고 최적의 결과를 도출할 수 있는 시스템, 즉 하네스를 설계합니다.

많은 사람들이 AI를 활용할 때 여전히 프롬프트를 어떻게 작성할지 고민하는 데 시간을 소비합니다. 그러나 진정한 바이브코딩의 핵심은 AI 에이전트가 우리의 의도와 목적에 맞게 작업할 수 있는 환경을 구축하는 것입니다. 이것이 바로 하네스 엔지니어링이며, 앞으로 우리가 반드시 갖춰야 할 핵심 역량입니다.

23개 AI 에이전트 팀으로 구성된 G-Stack의 비밀

게리 탄은 스탠퍼드 컴퓨터공학 출신으로 팔란티어에서 근무했고, 자신의 회사를 창업해 트위터에 엑시트한 전설적인 인물입니다. 그가 직접 설계한 G-Stack은 23개의 역할을 가진 AI 에이전트들로 구성되어 있습니다. 제품 전체를 총괄하는 CEO 에이전트, 아키텍처를 설계하고 감독하는 엔지니어링 매니저, 제품의 홍보와 판매를 책임지는 마케터 등 각자의 명확한 역할이 정의되어 있습니다.

더욱 놀라운 점은 이 에이전트들이 스스로 생각하고 계획하며, 직접 제작하고 서로 리뷰하고 테스트하는 사이클을 반복한다는 것입니다. 프롬프트 입력에 집중하는 것이 아니라, 누가 어떤 책임과 역할을 가지고 일할지부터 정의하는 것이 진정한 AI 활용의 시작점입니다. 단순히 AI에게 명령을 내리는 것을 넘어, AI가 자율적으로 작업할 수 있는 구조를 만드는 것이 핵심입니다.

부탁이 아닌 강제로 만드는 시스템 설계

하네스 설계에서 가장 중요한 원칙은 지켜야 할 규칙을 단순한 부탁이 아닌 강제 시스템으로 만드는 것입니다. 게리 탄의 G-Stack에는 위험한 명령을 막는 훅(Hook)이 존재합니다. AI가 터미널 명령을 실행하기 전에 스크립트가 먼저 작동하여, 폴더를 통째로 지우는 것과 같은 위험한 명령이면 즉시 차단합니다. 이는 AI에게 조심하라고 말하는 것이 아니라, 아예 실행 자체가 불가능하도록 만든 것입니다.

클로드 같은 AI 모델이 아무리 똑똑해도, 반복적으로 같은 실수를 하거나 특정 규칙을 어기는 상황이 발생할 수 있습니다. 매번 프롬프트로 주의사항을 반복하는 대신, 한 번 설정으로 절대 어길 수 없는 방어 장치를 구축해야 합니다. 이것이 바로 결정론적 장치이며, 신뢰할 수 있는 AI 워크플로우의 핵심입니다.

하네스 엔지니어링의 본질은 실수를 환경으로 해결하는 것

하네스 엔지니어링이라는 개념은 2025년 초 미첼 하시모토라는 개발자가 정리했습니다. 그 의도는 매우 단순하면서도 강력합니다. AI 에이전트가 실수하는 것을 발견하면, 다시는 그 실수를 못 하게 환경 자체를 고쳐두는 것입니다. 매번 같은 지시를 반복하는 것이 아니라, 한 번의 설정으로 영구적인 해결책을 만드는 방식입니다.

중요한 점은 남이 만든 하네스를 그대로 가져다 쓰는 것이 아니라, 자신의 문제와 경험을 바탕으로 직접 설계해야 한다는 것입니다. 게리 탄의 하네스는 그의 작업 방식과 취향이 반영된 결과물입니다. 다른 사람의 하네스에는 그 사람이 정해놓은 가정과 맥락이 담겨 있으므로, 우리의 프로젝트와 정확히 일치하지 않을 수 있습니다. 커뮤니티의 스킬이나 플러그인을 그대로 가져다 쓰지 말고, 왜 그것이 만들어졌는지, 어떤 문제를 해결했는지를 배워서 자신만의 것으로 만들어야 합니다.

루프 엔지니어링, 검사하는 루프의 필요성

하네스 엔지니어링과 함께 주목받는 개념이 루프 엔지니어링입니다. 2025년 6월 에디 오스만이라는 개발자가 명명한 이 개념의 핵심은, 실제로 코드를 작성하는 메인 루프 옆에 그 코드를 검사하는 별도의 루프를 두는 것입니다. 클로드를 만든 Anthropic도 코드를 쓰는 루프에는 그 코드를 검사하는 루프가 필요하다고 강조합니다.

바이브코딩으로 서비스를 운영하다 보면 어제까지 잘 작동하던 서비스가 아침에 열어보니 죽어있는 경험을 하게 됩니다. 기능 하나를 추가하면서 잘못된 코드가 그대로 배포된 것입니다. 이를 방지하려면 사람이 모든 코드를 일일이 검수할 수 없으므로, 자동 검사 시스템이 통과해야만 배포가 가능하도록 설계해야 합니다. 이것이 루프 엔지니어링의 실질적인 적용 방법입니다.

AI 작업 검증의 세 가지 핵심 지점

AI 에이전트의 작업을 검증해야 하는 지점은 크게 세 가지로 나눌 수 있습니다. 첫째, AI가 작업을 완료했다고 말하는데 실제로 열어보면 제대로 작동하지 않는 경우입니다. 이때 고쳐야 할 것은 프롬프트가 아니라 완료의 정의입니다. 무엇이 통과해야 완료인지를 먼저 정의하고, 그 검사가 통과해야만 작업이 완료된 것으로 판정되도록 만들어야 합니다.

둘째, 절대 일어나면 안 되는 일을 막아야 합니다. 중요한 파일을 삭제하거나 손대면 안 되는 데이터를 건드리는 일은 단순히 부탁으로 두면 언젠가는 반드시 문제가 발생합니다. 이러한 위험 요소는 실행 자체가 불가능하도록 강제로 차단해야 합니다. 게리 탄이 훅으로 막은 것, 코드 저장 시 검사를 거는 것이 바로 이 지점입니다.

셋째, 매번 같은 잔소리를 반복하게 되는 순간입니다. 동일한 지적 사항이 반복된다면, 그것을 더 이상 말로 반복하지 말고 역할로 넘겨야 합니다. 리뷰어 에이전트를 만들어 자주 발생하는 문제 지점을 자동으로 체크하게 하는 것이 효율적인 방법입니다. 이렇게 세 가지 검증 지점을 시스템화하면, 프로젝트 규모가 커져도 안정적으로 관리할 수 있습니다.

데이터베이스 변경과 배포 사고를 막는 실전 전략

실제 서비스를 운영하면서 가장 중요한 것 중 하나가 데이터를 건드리는 작업입니다. 사용자 테이블에 컬럼을 추가했는데 기존 데이터에는 해당 컬럼이 없어서 애플리케이션이 오류를 일으키는 경우가 발생할 수 있습니다. 매번 데이터베이스 변경 이력을 남겨달라고 말로 부탁하는 대신, 코드를 저장하는 순간 자동으로 검사가 실행되도록 설정하면 됩니다. 데이터베이스 변경이 필요한데 변경 커맨드 이력이 없으면 코드 저장 자체가 안 되도록 만드는 것입니다.

또한 잘못된 코드가 배포되지 못하게 하는 장치도 필수적입니다. 기능 하나를 추가하다가 다른 부분이 깨지는 일이 자주 발생한다면, 자동 검사가 통과해야만 배포가 가능하도록 시스템을 구축해야 합니다. 이러한 방어 장치들은 한 번 설정해두면 100번이 넘는 변경 작업에서도 사고 없이 안정적으로 서비스를 운영할 수 있게 해줍니다.

하네스는 한 번에 완성되는 것이 아닙니다

게리 탄도 처음부터 모든 하네스를 완벽하게 갖추고 시작한 것이 아닙니다. 작업을 진행하면서 필요에 따라 하나씩 추가하고 발전시켜온 것입니다. 하네스는 AI가 하는 실수와 반복되는 작업들을 최적화하면서 점진적으로 붙여가는 것입니다. 처음에는 규칙을 20개 이상 만들었다가, 프로젝트가 진행되면서 불필요한 규칙을 제거하고 더 이상 필요 없어진 하네스를 걷어내는 과정도 필요합니다.

특히 AI 모델이 발전하고 도구 자체의 기능이 추가되면서, 예전에는 필수였던 하네스가 이제는 필요 없어지는 경우도 많습니다. Anthropic이 새로운 모델을 출시하면서 자체적으로 만들었던 하네스를 줄인 것처럼, 우리도 주기적으로 하네스를 검토하고 최적화해야 합니다. 하네스는 단순히 AI의 결과물 수준을 올려주는 것이 아니라 토큰 비용에도 영향을 미치므로, 필수적인 시스템만 남기는 것도 중요한 설계 원칙입니다.

바이브코딩의 진짜 재미는 시스템 설계에서 시작됩니다

프로젝트 중반까지는 순조롭게 진행되다가 기능을 추가할 때마다 다른 부분이 깨지고, 버그 하나를 고치면 또 다른 곳에서 문제가 발생하는 경험을 하셨다면, 이제는 접근 방식을 바꿔야 할 때입니다. 프롬프트를 더 잘 쓰려고 노력하는 대신, 워크플로우를 정의하고 하네스를 설계하는 방법을 배워야 합니다.

AI의 발전은 누군가에게는 두려운 변화지만, 누군가에게는 삶의 전환점이 됩니다. 코딩이 어렵고 자신과는 거리가 멀다고 생각했던 사람들이 지금은 앱을 만들고 서비스를 운영하며 회사 업무 시스템을 직접 구축하고 있습니다. 중요한 것은 남이 만든 스킬이나 플러그인을 그대로 가져다 쓰는 것이 아니라, 자신만의 워크플로우를 설계하고 발전시킬 수 있는 능력을 갖추는 것입니다. 이것이 바로 빠르게 변화하는 AI 시대에서 자신만의 기준을 지키면서도 앞서갈 수 있는 유일한 방법입니다.