하네스 엔지니어링이란? 프롬프트·컨텍스트 엔지니어링 다음 단계로 온 AI 코딩 전략 정리

핵심 메시지

• 하네스 엔지니어링은 AI에게 '하지 마'라고 말하는 데서 그치지 않고, 어겼을 때 실제로 걸리는 장치까지 만들어 두는 접근이다.
• 출발점은 생산성 병목이 사람에게 있다는 인식이다. AI는 빠르게 코드를 만드는데 그것을 하나씩 검사하는 인간이 느리다는 것.
• 핵심 구성 요소는 세 가지다. 로그로 AI에게 '눈'을 달아주기, 지침 문서를 목차처럼 쪼개 점진적으로 열어주기, 그리고 검증 절차를 강제하기.
• 지침을 하나의 거대한 문서에 몰아넣으면 AI가 앞부분만 대충 읽고 넘어간다. 목차만 주고 필요할 때 찾아가게 하는 편이 낫다.
• 구축에는 시간이 오래 걸리므로 처음부터 전부 도입할 필요는 없다. 반복되는 작업을 하나씩 자동화하며 자신만의 체계를 쌓아가는 편이 현실적이다.

쉽게 이해하기

프롬프트 엔지니어링, 컨텍스트 엔지니어링에 이어 '하네스 엔지니어링'이라는 말이 돌기 시작했다. 영상은 이 용어들을 하나의 흐름으로 정리한다. 프롬프트 엔지니어링이 말을 잘하는 기술이라면, 컨텍스트 엔지니어링은 매일 기억이 초기화되는 신입에게 회사의 히스토리를 전달하는 기술이다. 6개월 일한 인턴이 첫날 신입보다 나은 이유가 맥락을 알기 때문이라는 비유가 쓰였다.

그런데 AI가 지시를 잘 알아듣게 되자 새로운 문제가 생겼다. 자기 마음대로 만들어버리고, 사람이 계속 결과물을 확인하고 되돌려 보내는 일이 반복된 것이다. 하네스는 강아지 산책용 하네스에서 온 말로, AI가 활동할 수 있는 경계를 정해주는 장치를 뜻한다. 다만 말로만 '빨간색을 써라'고 하면 AI가 잊고 제멋대로 만들기 때문에, 지시를 어겼을 때 잡아내는 장치까지 갖춰야 하네스 엔지니어링이라 부를 수 있다는 것이 영상의 정의다.

이 개념이 최근 주목받은 계기는 오픈AI가 공개한 문서다. 개발자들이 다섯 달 동안 코드를 한 줄도 직접 치지 않고 서비스를 만들었고, 그 방법을 정리해 공개했다. 문제의식은 분명했다. AI가 코드를 만드는 속도는 빠른데 그것을 테스트하는 인간이 느려 병목이 된다는 것. 그래서 사람의 개입을 최대한 걷어내고 AI가 스스로 계획하고 구현하고 테스트하고 버그까지 잡게 만드는 시스템을 짰다.

첫 번째 요소는 가시성이다. 예전에는 시니어 개발자가 '쓸데없는 로그 지워'라고 했다면, 이제는 오히려 로그를 붙인다. AI가 자기 실행 결과를 로그로 읽고 원하는 결과가 아니라고 판단하면 스스로 고칠 수 있기 때문이다. 두 번째는 컨텍스트 관리다. 하나의 큰 지침 파일에 전부 몰아넣었더니 분량이 많아 '지침이 지침 노릇을 못 하는' 상태가 됐고, 그래서 지침 파일을 목차로 취급해 AI가 필요한 문서를 찾아가도록 바꿨다.

영상 후반부는 발표자가 직접 만든 시스템의 동작을 보여준다. 작업 요청이 들어오면 먼저 깃 워크트리를 따로 만들어 메인 코드를 건드리지 않게 하고, 계획 문서를 작성한 뒤 그 워크트리 안에서 구현한다. 이어 단위 테스트를 작성하고 린트·빌드·파일 크기 같은 검증을 실행하며, 통과하면 정해진 형식으로 커밋 메시지를 만들어 스스로 병합한다. 완료된 계획 문서는 자동으로 완료 폴더로 옮겨진다.

주요 인사이트

• 이 접근의 진짜 핵심은 '강제'다. 발표자는 하지 말라는 말은 백만 개도 할 수 있지만 AI가 무시한다는 점을 지적하며, 커밋 훅 같은 도구로 규칙을 어기면 에러가 나게 만드는 것이 하네스 엔지니어링의 본질이라고 정리했다.
• 실제 시연 중에 AI가 워크트리를 만들지 않고 곧바로 계획 문서를 쓰려 하자 훅에 걸려 차단됐고, 다시 워크트리를 만든 뒤 문서를 작성했다. 장치가 실제로 작동한 사례다.
• 지침 문서 자체도 무시당할 수 있다는 점을 전제로 설계해야 한다. 발표자는 AI가 지침 파일을 그냥 넘어가는 경우가 많다며, 중요한 것은 무시했을 때 되돌아오게 만드는 장치라고 강조했다.
• 오픈AI가 공개한 문서에는 클로드용 지침 파일에 대한 언급이 없어서, 그대로 적용하면 도구가 각자 알아서 해석해버리는 문제가 있었다고 한다. 발표자는 실행 전에 반드시 읽히는 지침 파일을 직접 다시 작성해 필수 단계를 명시했다.
• 도입 시점에 대한 조언이 현실적이다. 초기 구축에 시간이 많이 들기 때문에 무조건 전부 적용할 필요는 없고, 편한 방식으로 개발하다가 반복되는 작업을 하나씩 자동화하면 결국 자기 나름의 체계가 만들어진다는 것이다.

자주 묻는 질문

관련 AI 소식