하네스 엔지니어링을 꼭 알아야 하는 이유: 바이브 코딩의 한계와 AX 전환 사례

이미 국내 근로자의 절반 이상인 51.8%가 생성형 AI를 업무에 활용하고 있습니다. AI를 활용하면서 업무시간도 평균 3.8%, 주당 약 1.5시간 줄었습니다. 하지만 절약된 시간이 실제 생산 증가로 이어지지는 않았습니다. 한국은행은 그 배경으로 개별 업무의 효율 향상이 업무 흐름 개선이나 조직 구조 변화까지 이어지지 못한 점을 짚었습니다.

개발에서도 마찬가지입니다. AI가 코드를 빠르게 만들어도 프로젝트 규칙과 검증 과정이 그대로라면 속도 향상만으로 개발 과정 전체가 달라지지는 않습니다. 이 설계를 다루는 것이 앞선 글에서 살펴본 하네스 엔지니어링입니다.

이번 글에서는 바이브 코딩의 한계와 AX 전환, 국내 기업 사례를 통해 왜 지금 하네스 엔지니어링이 필요한지 살펴보겠습니다.

하네스 엔지니어링이 필요한 이유

하네스 엔지니어링이 필요한 이유는 AI가 맡는 작업이 늘어날수록 프로젝트 규칙을 일관되게 적용하고, 필요한 정보를 활용하며, 결과를 검증하는 과정이 중요해지기 때문입니다. 개인의 바이브 코딩부터 AI 에이전트, 조직의 AX 전환까지 활용 방식과 규모는 다르지만, 세 경우 모두 AI가 지켜야 할 기준과 작업 절차를 미리 정해야 합니다.

① 바이브 코딩의 한계: 코드 생성 이후 검증이 필요합니다

바이브 코딩을 활용하면 아이디어를 빠르게 구현할 수 있습니다. 하지만 코드가 오류 없이 실행된다고 해서 보안까지 확인된 것은 아닙니다.

보안 기업 베라코드(Veracode)는 2026년 조사에서 AI 모델에 보안 취약점이 생길 수 있는 코딩 과제를 맡겼습니다. 별도의 보안 지침 없이 생성한 코드의 결과는 다음과 같았습니다.

문법상 올바른 코드: 95% 이상
보안 테스트를 통과한 코드: 약 55%

→ AI가 코드를 빠르게 생성하더라도 보안상 문제가 없는지는 별도로 검증해야 합니다.

② AI 에이전트: 작업이 길어질수록 규칙과 도구가 필요합니다

Claude Code나 Codex 같은 AI 에이전트는 여러 파일을 수정하고 명령어를 실행하며 테스트까지 수행하는 등 여러 단계의 개발 작업을 이어서 처리합니다. 하지만 맡기는 작업이 길어질수록 AI가 참고해야 할 정보와 지켜야 할 규칙도 많아집니다.

OpenAI는 Codex 에이전트에게 제품 개발을 맡긴 내부 실험에서도 같은 일을 겪었습니다.

초기 병목: 필요한 도구와 내부 구조 부족
환경 정비: 프로젝트 문서·개발 도구·아키텍처 규칙·테스트 체계 구축
변화: 버그 재현부터 수정·검증까지 처리, 6시간 이상 장기 작업 수행

→ AI 에이전트에게 긴 작업을 맡기려면 필요한 정보와 도구, 작업 규칙, 검증 방법까지 함께 제공해야 합니다.

③ AX 전환: 개인의 효율을 조직의 성과로 연결해야 합니다

조직에서도 AI 도구를 도입하는 것만으로 AX(AI Transformation, AI 전환)가 이루어지지는 않습니다. 개발자가 AI로 코드를 더 빠르게 작성해도 테스트와 리뷰, 배포 과정의 병목이 그대로라면 개인의 생산성 향상이 조직 전체의 성과로 이어지기 어렵습니다.

구글 클라우드 DORA의 2025년 연구도 AI를 조직이 이미 가진 강점과 문제를 함께 확대하는 ‘증폭기’로 설명합니다. AI가 일부 업무의 속도를 높이더라도 기존 업무 절차나 협업 방식, 의사결정 구조가 그대로라면 그 효과가 조직 전체로 이어지기 어렵다는 뜻이죠.

→ AI 도입 효과를 조직 전체로 확대하려면 AI를 쓰는 사람뿐 아니라 업무 흐름과 개발 환경도 함께 바꿔야 합니다.

AI가 일하는 환경을 바꾼 국내 기업 사례

국내에서도 AI가 참고할 규칙과 사용할 도구, 권한을 업무에 맞게 정리하는 사례가 나오고 있습니다.

우아한형제들: 팀의 개발 규칙을 AI가 먼저 참고하도록

배달의민족을 운영하는 우아한형제들의 한 프론트엔드 개발팀은 개발자마다 AI에게 전달하는 내용이 달라 코드 스타일이 일관되지 않는 문제를 겪었습니다. 프로젝트 규칙을 매번 다시 설명해야 했고, PR 리뷰에서도 스타일 관련 수정이 반복됐습니다.

이 프로젝트는 React Query를 사용하고
캐시 키는 특정 파일에서 중앙 관리하며
API 호출은 직접 fetch를 쓰지 않고 API Class를 사용합니다

- 원하는 코드를 얻기 위해 매번 붙이는 설명 예시 (출처:우아한기술블로그 https://techblog.woowahan.com/26177/)

팀은 Cursor의 Rules와 Skills를 활용해 프로젝트 규칙과 반복 작업 절차를 AI가 참고하도록 구성했습니다.

Rules: 코딩 컨벤션과 프로젝트 구조
Skills: API 연동, 테스트 생성 등 반복 작업 절차
변화: 반복적인 규칙 설명과 PR 스타일 수정 감소

여기어때: 데이터 분석에 필요한 정보와 도구를 AI에 연결

여행·여가 플랫폼 여기어때는 현업 부서가 데이터 분석을 요청하면 결과를 받기까지 수일이 걸렸습니다. 필요한 정보도 Slack과 Jira 등 여러 시스템에 흩어져 있었죠.

여기어때는 구글 클라우드 기반으로 사내 AI 에이전트 플랫폼 YAPP을 구축해 자연어로 질문하면 필요한 데이터를 찾고 분석한 뒤, 결과 정리와 공유까지 이어지도록 만들었습니다.

정보·도구: MCP로 Slack, Jira 등 업무 도구 연결
권한: 부서·사용자·에이전트별 데이터 접근 범위 설정
변화: 수일 걸리던 데이터 분석을 수 분 안에 처리

AI를 잘 쓰는 것만큼 일할 환경을 만드는 것이 중요합니다

바이브 코딩에서는 생성한 코드를 검증할 기준이 필요하고, AI 에이전트에는 긴 작업을 이어갈 정보와 도구가 필요합니다. 조직에서는 AI를 어느 단계에서 활용하고, 결과를 어떻게 확인할지까지 업무 방식에 반영해야 합니다. AI가 맡는 일이 늘어날수록 모델 자체보다 AI가 일할 규칙과 절차, 검증 방법을 함께 설계하는 일이 중요해집니다.

이 판단을 하려면 문제를 나누고 결과를 검증할 수 있어야 합니다. 그 기본기를 코드트리에서 길러보세요.

코드트리에서 시작하기