바이브 코딩 + 하네스 = 진짜 에이전틱 엔지니어링

오늘 블로그 스킬을 다듬으면서 다시 느꼈습니다. 같은 실수를 한 번 더 박지 않으려고 룰을 쓰는 행위 자체가 일종의 하네스 설계입니다.

Andrej Karpathy 가 "vibe coding" 이라는 표현을 던진 뒤로 LLM 페어 프로그래밍이 빠르게 퍼졌습니다. 자연어로 의도만 던지면 코드가 술술 나옵니다. 그러나 실제 운영해본 결과, 바이브 코딩 단독으로는 6개월을 못 갑니다. 그럴듯하게 돌아가지만 결국 재개발 비용으로 돌아옵니다.

이걸 막는 게 하네스 (harness) 입니다. 바이브 코딩과 에이전틱 엔지니어링을 가르는 분기점이 정확히 여기 있습니다.

바이브 코딩이 빠지는 함정

Karpathy 의 정의를 정리하면 다음과 같습니다.

자연어로 의도를 던지면 LLM 이 코드를 생성합니다. 사람은 결과물의 "그럴듯함" 으로 빠르게 머지합니다. 검증은 "돌아가는가" 수준에서 멈춥니다. architecture 결정·edge case 검토·예외 처리는 LLM 이 무책임하게 채워 넣습니다.

작업이 빨라 보이는 이유는 단순합니다. 시니어가 30분에서 수 시간 고민하는 architecture 결정 단계가 LLM 의 첫 출력으로 대체됩니다. 그 첫 출력은 흔히 보이는 패턴의 평균치라 단순 CRUD 까지는 잘 굴러갑니다.

문제는 운영 단계입니다. 사용자 100명 동접에서 다운하는 경우의 80% 가 DB·캐싱·connection pool 같은 architecture 결정 영역에 있고, 이 영역을 바이브 코딩 단독으로 커버하면 거의 다 함정에 빠집니다.

하네스는 LLM 을 시스템에 묶는 구조입니다

하네스는 LLM 의 코드 생성을 시스템 차원에서 묶는 구조입니다. 안전벨트와 비슷합니다. 운전을 못 하게 막는 게 아니라, 사고가 큰 비용으로 번지지 않게 막습니다.

베비투스랩이 매일 쓰는 5가지 하네스를 정리합니다.

1. CLAUDE.md (프로젝트별 invariant)

프로젝트 루트의 CLAUDE.md 파일에 "이 프로젝트의 절대 규칙" 을 박아둡니다. 폴더 구조·코드 컨벤션·금지 패턴·환경 변수 룰. 새 세션마다 LLM 이 자동으로 읽습니다. 잘못된 패턴이 시작부터 차단됩니다.

지난 4편 글을 손수 콜론 다 풀어쓰면서 다시 한 번 느꼈습니다. 한 번 룰로 박아두면 다음 글에서 같은 실수가 자동으로 reject 됩니다.

2. permissions (Edit·Write 차단 룰)

.claude/settings.json 에 권한 룰을 둡니다. 예를 들어 Bash(rm:*) 차단·Edit(.env*) 차단. 악성 프롬프트가 슬쩍 위험한 명령을 끼워 넣어도 hooks 단에서 막힙니다.

베비투스랩은 모든 클라이언트 프로젝트에 비슷한 룰을 박습니다. AI Agent 가 자율 작업을 해도 destructive 명령은 사람 결재 필수입니다.

3. Quality gate (발행 전 자동 검증)

코드 머지·글 발행 전에 grep·테스트·빌드를 강제로 통과시킵니다. 이번에 다듬은 블로그 스킬에도 발행 전 grep 4개 (em-dash, 헤딩 콜론, 리스트 라벨, 마이크로 라벨) 가 0건이어야 통과로 묶었습니다. 사람이 깜빡해도 게이트가 잡습니다.

4. Sub-agent isolation (역할별 격리)

architect·security-auditor·code-reviewer 같은 sub-agent 를 분리합니다. 한 agent 가 모든 결정을 내리지 않습니다. architect 가 설계하면 reviewer 가 다른 컨텍스트에서 검토합니다. 같은 모델이라도 시점·역할이 다르면 다른 약점을 잡습니다.

5. Worktree (실험 격리)

위험한 실험은 git worktree 에서 격리합니다. main 브랜치 코드는 절대 안 건드립니다. 실험이 끝나면 PR 로만 합칩니다. AI Agent 가 자율 작업해도 main 이 깨질 일이 없습니다.

에이전틱 엔지니어링은 모델 다루기가 아닙니다

흔한 오해는 "더 좋은 모델 쓰면 된다" 입니다. Claude 4 에서 5 로 바꾸면 자동으로 좋아진다고 생각합니다. 솔직히 모델은 매년 바뀝니다. 1년 전 GPT-4 가 지금 Claude Sonnet 으로 갈렸고, 1년 뒤에는 또 다른 모델이 표준이 됩니다.

진짜 자산은 하네스입니다. CLAUDE.md·permissions·quality gate·sub-agent isolation·worktree. 이 다섯 가지는 모델이 바뀌어도 그대로 굴러갑니다. 5년을 가는 시스템입니다.

시니어 PE 의 진짜 가치도 여기 있습니다. 모델 프롬프트 잘 짜는 게 아니라, 모델을 묶는 하네스를 설계할 수 있는 사람입니다. 1인 50배 효율은 시니어 PE 가 하네스를 설계한 위에서만 성립합니다. 주니어에게 같은 AI Agent 를 쥐여줘도 하네스가 없으면 결과물의 운영 안정성이 무너집니다.

바이브 코딩 A/S 를 별도 서비스로 두는 이유

작년부터 바이브 코딩으로 만든 프로덕트의 A/S 요청이 늘었습니다. 베비투스랩이 4가지 약속 중 바이브 코딩 A/S 를 별도 서비스로 둔 이유가 정확히 이겁니다. 빠르게 만든 만큼 빠르게 무너지는 패턴이 반복됩니다.

A/S 진단의 4축 (architecture·테스트·운영·인계) 모두 바이브 코딩 단독으로는 점수가 안 나옵니다. 하네스 없는 코드가 평균치를 만들면, 평균치는 사용자 30명에서 다운 같은 결과로 이어집니다.

바이브 코딩 자체를 부정하는 건 아닙니다. 빠른 prototype·MVP 검증·단순 CRUD 까지는 충분히 강력한 도구입니다. 그러나 운영에 들어가는 순간 하네스가 필수입니다. 베비투스랩이 시니어 PE 직접·재하청 0건·끝까지 책임지는 4가지 약속을 두는 이유도, 하네스 설계가 시니어 PE 의 핵심 자산이기 때문입니다.

---

우리 코드가 바이브 코딩 함정에 빠졌는지 궁금하면 바이브 코딩 A/S 4축 진단 에서 architecture·테스트·운영·인계 점수를 확인할 수 있습니다.