전문가 인터뷰

하네스 엔지니어링의 진짜 문제는
만든 뒤부터 드러납니다.

#하네스 엔지니어링 #루프 엔지니어링 #리팩토링

개발동생

현) 35.2K 유튜브 '개발동생' 운영

외부 활동

• 2024~ 삼성전자 개발 관련 생성AI 콘텐츠 제작
• 2024 Stable Diffusion Fooocus 마스터 클래스 강의 런칭
• 2022 엘리스 AI 트랙 웹 프로젝트 코치

“사실 하네스는 잘 만드는 것보다, 만들고 난 뒤가 더 어렵습니다.”

요즘 AI 코딩을 조금 깊게 쓰다 보면 결국 ‘하네스’라는 단어를 만나게 됩니다. Rule을 만들고, Skill을 붙이고, Hook과 MCP를 연결하면서 AI가 더 안정적으로 일할 수 있는 환경을 만드는 것이죠.

그런데 하네스는 한 번 잘 만들어두면 끝나는 구조가 아닙니다.
프로젝트가 커질수록 규칙은 쌓이고, 서로 충돌하기도 하고, 필요 없어진 설정이 오히려 컨텍스트와 토큰을 잡아먹기 시작합니다.

그래서 이제 중요한 질문은
“하네스를 어떻게 만들까?”보다 “만든 하네스를 어떻게 계속 잘 굴릴까?”에 가깝습니다.

이번 인터뷰에서는 개발 유튜브 채널 ‘개발동생’을 운영하는 최준혁 개발자와 함께, 좋은 하네스의 기준부터 루프 엔지니어링, 하네스 다이어트, 실제 배포와 피드백이 필요한 이유까지 하나씩 짚어봤습니다.

🧑‍💻 AI 개발 생산성을 연구하는 현업 개발자, ‘개발동생’

Q. 먼저 간단한 자기소개 부탁드립니다. 현재 어떤 일을 하고 계신가요?

A. 안녕하세요. 유튜브 ‘개발동생’ 채널을 운영하고 있는 개발자 최준혁입니다. 유튜브에서는 주로 AI를 활용한 개발 생산성 향상과 하네스 엔지니어링 같은 주제를 다루고 있고, 현재 스타트업에서 현업 개발자로도 활동하고 있습니다.

Codex 마스터 클래스 1시간 편집본 하네스 설계부터 서비스 배포까지

클로드 만든 개발자는 이제 프롬프트를 안씁니다
| Fable 5로 Loop Engineering

클로드 코드 Dynamic Workflow
| 낡아빠진 하네스는 다이어트가 필수입니다...!

⚙️ 하네스 엔지니어링은 ‘AI가 일하는 환경’을 설계하는 일

Q. 최근 AI 개발 영역에서 ‘하네스 엔지니어링’이라는 개념이 자주 언급되고 있습니다. 정확히 무엇을 의미하나요?

A. 하네스 엔지니어링은 에이전트가 제대로 일할 수 있는 환경을 설계하는 것입니다. 프로젝트의 룰과 규칙을 정하거나, 자주 반복되는 작업을 스킬로 패키징하고, MCP 서버를 통해 외부 도구를 사용할 수 있도록 연결하는 것 등이 포함됩니다. 또 에이전트가 안전하게 작업할 수 있도록 제한이나 안전장치를 만드는 것도 하네스 엔지니어링의 영역입니다.

🔄 하네스 다음 단계는 ‘루프 엔지니어링’ ?!

Q.그렇다면 하네스 엔지니어링과 루프 엔지니어링은 어떤 차이가 있나요?

A. 쉽게 말하면 하네스는 작업 환경이고, 루프는 그 환경 위에서 에이전트가 실제 목표를 완수하도록 만드는 실행 구조입니다. 루프에서는 목표를 정하고 작업을 실행한 뒤 테스트하고 결과를 검증합니다. 실패했다면 그 결과를 다시 다음 작업에 반영하고, 목표를 만족할 때까지 개선하는 과정을 반복합니다.

하지만 같은 프롬프트를 여러 번 실행한다고 해서 루프가 되는 것은 아닙니다. 제대로 된 루프에는 세 가지가 필요합니다. 매 회차의 결과를 확인하는 검증기, 실패 원인을 다음 시도에 반영하는 피드백, 그리고 언제 작업을 끝낼지 결정하는 종료 조건입니다.

에이전트가 한 바퀴 작업할 때마다 결과가 실제로 나아지도록 만드는 것이 단순 반복과 루프 엔지니어링의 가장 큰 차이입니다.

🏃 하네스도 계속 ‘다이어트’해야 합니다

Q. 강사님께서는 ‘하네스 다이어트’라는 표현을 자주 사용하시는데요. 왜 필요한가요?

하네스도 코드처럼 계속 사용하다 보면 낡습니다. 모델의 성능이나 제품 기능, 프로젝트 구조와 팀 규모가 계속 변하기 때문에 과거에 필요했던 룰이나 스킬이 지금은 필요하지 않을 수도 있습니다. 사용하지 않는 스킬이 계속 남아 있거나, 룰끼리 충돌하거나, Claude Code나 Codex의 기본 기능과 우리가 만든 설정이 중복된다면 하네스를 다시 점검할 필요가 있습니다.

❌ Rule과 Skill은 많다고 좋은 게 아닙니다

Q. 기능과 안전장치를 많이 넣을수록 더 좋은 하네스가 되는 것은 아닌가요?

A. 그렇지 않습니다.
룰이 너무 많아지면 무엇이 중요한지 흐려지고 서로 충돌하는 지시가 생길 수 있습니다. 스킬 역시 실제 반복되는 작업이 아닌데 계속 추가하면 에이전트가 어떤 도구를 사용해야 하는지 판단하기 어려워집니다.

결국 좋은 하네스는 설정의 개수가 많은 하네스가 아니라, 필요한 순간에 필요한 설정이 정확하게 작동하는 하네스입니다.

📋 남이 만든 하네스 템플릿을 그대로 쓰면 안 되는 이유

Q. 이미 잘 만들어진 하네스 템플릿도 많은데, 그대로 가져와 사용하면 더 빠르지 않을까요?

A. 템플릿을 출발점이나 체크리스트로 활용하는 것은 좋습니다. 다만 그대로 복사해서 하네스가 완성됐다고 생각하면 안 됩니다. 프로젝트마다 기술 스택과 팀 규모, 배포 환경, 실패했을 때 발생하는 위험이 모두 다르기 때문입니다. 따라서 각각의 설정이 우리 프로젝트에서 어떤 문제를 막기 위해 존재하는지 설명할 수 있어야 합니다.

🧑‍🏫 하네스 구축 → 루프 엔지니어링 → 리팩토링 후 배포까지 과외!

Q.그럼 이런 하네스, 루프, 리팩토링은 어떻게 배워야 하나요?

A. 그래서 제가 이번에 오프라인 과정을 오픈했는데요. 하네스가 무엇인지는 어느 정도 알고 있지만, 실제 자신의 업무나 프로젝트에 어떻게 적용해야 할지 막막한 분들께 추천드립니다.

유튜브에서는 개별 프로젝트의 맥락까지 파악하면서 모든 질문에 답변드리기 어렵지만, 이번 오프라인 과정에서는 직접 대면해 질문하고 각자의 프로젝트를 보면서 피드백을 받을 수 있습니다.

자신의 프로젝트에 맞는 하네스를 직접 설계하고, 더 안전하고 지속적으로 개선할 수 있는 개발 환경을 만들고 싶은 분들이 참여하시면 좋겠습니다.