시리즈 · MoAI ADK와 하네스 엔지니어링
2회 · MoAI ADK와 하네스 엔지니어링 2 - 휴먼코드 0 팀의 실제 운영
MoAI ADK와 하네스 엔지니어링 2 - 휴먼코드 0 팀의 실제 운영
필자의 팀은 Claude Code 비즈니스 좌석과 MoAI 하네스를 사용해 팀원의 AI 개발 참여율 100%, 사람이 직접 입력한 프로덕션 코드 0을 운영 목표로 달성했다. 여기서 “휴먼코드 0”은 인간 노동 0도, 무검수 자동 배포도 아니다. 사람은 문제를 정의하고 설계를 승인하며 테스트 증거와 운영 위험을 판단한다. 코드 초안·수정·반복 작업을 에이전트가 수행한다는 뜻이다.
실제 프로젝트의 하네스 구조
현대 웹, 최신 Spring Boot, Flutter를 한 제품으로 묶으면 모델에게 “전체 저장소를 잘 이해해”라고 말하는 것만으로 부족하다.
| 하네스 자산 | 웹 | Spring Boot | Flutter |
|---|---|---|---|
| 도메인 계약 | 사용자 흐름·상태 표시 | 애그리거트·트랜잭션·정책 | 화면 상태·오프라인 정책 |
| 인터페이스 | API 클라이언트·타입 | OpenAPI·오류·이벤트 | DTO·직렬화·딥링크 |
| 품질 게이트 | lint·unit·E2E·build | format·unit·integration·build | analyze·test·build |
| 배포 계약 | 환경 변수·정적 자산 | 컨테이너·DB migration | signing·store flavor |
프로젝트 분석과 도메인 설계 문서가 중심축이다. 여기에 코딩 가이드, 아키텍처 의존 규칙, API 계약, CI/CD 명령, 브랜치·커밋·PR 규칙을 붙인다. 모델은 이 컨텍스트를 읽고 SPEC을 세우며, 작은 변경 단위로 구현하고 각 기술 스택의 검증 명령을 실행한다.
Claude Code 좌석은 도구, 팀 합의가 운영체제
팀원 전원에게 Claude Code 비즈니스 좌석을 제공하면 동일한 에이전트 도구에 접근할 수 있다. 그러나 좌석만 통일하면 개인별 프롬프트 습관만 늘어난다. 생산성을 만든 것은 저장소 안의 공통 SPEC, 명령, 품질 게이트와 리뷰 언어였다.
작업 흐름은 다음과 같다.
- 사람이 업무 목표, 제약, 완료 조건과 위험도를 결정한다.
- 에이전트가 코드맵과 도메인 문서를 읽고 변경 계획과 테스트 계획을 만든다.
- 사람이 경계와 데이터 변경을 승인한다.
- 에이전트가 구현하고 로컬 검증을 반복한다.
- CI가 동일한 명령을 깨끗한 환경에서 재실행한다.
- 사람이 diff보다 먼저 요구사항 추적표, 테스트 증거, 보안·운영 영향을 리뷰한다.
- 배포 뒤 관측 결과와 사고 교훈을 하네스 문서에 되먹임한다.
이 방식은 AI 시대의 하네스 엔지니어링에서 말한 역할 전환과 맞닿는다. 타이핑 속도가 아니라 문제 분해, 계약 작성, 검증과 피드백 품질이 병목이 된다. 반대로 바이브 코딩처럼 결과 화면만 좇으면 이 계약과 추적성이 사라진다.
사람이 반드시 소화해야 하는 일
AI가 코드를 전부 썼다는 사실은 책임 이전 계약이 아니다.
- 분석: 고객 문제, 법적·보안 제약, 수익과 운영 목표의 우선순위
- 설계: 도메인 경계, 데이터 소유권, 장애 격리, 장기 유지비
- 리뷰: 요구사항 누락, 과잉 구현, 권한 상승, 개인정보와 라이선스
- 테스트: 중요한 사용자 시나리오, 탐색 테스트, 기기·네트워크·복구 조건
- 운영: 배포 승인, 관측, 롤백, 사고 지휘와 고객 커뮤니케이션
특히 테스트 코드를 AI가 만들고 같은 AI가 통과시켰다면 독립 증거가 약하다. 사람은 테스트가 요구사항을 실제로 증명하는지, 거짓 양성은 없는지, 실패 경로와 비기능 조건을 다뤘는지 확인해야 한다. “코드가 컴파일된다”와 “제품이 안전하게 작동한다” 사이를 메우는 것이 하네스 엔지니어링이다.
Fable 5가 보여주는 긴 작업과 하네스의 가치
Anthropic은 Claude Fable 5를 2026년 6월 9일 공개했고, 수출통제에 따른 일시 중단 뒤 7월 1일 전 세계 제공을 복원했다. 회사는 장시간 코딩·지식 작업에서 계획, 위임, 자체 점검을 수행하고 Claude Code 같은 하네스 안에서 며칠간 일할 수 있다고 설명한다.
이는 Anthropic의 제품 주장이지 독립 벤치마크의 최종 판정은 아니다. 다만 필자의 운용에서도 최근 모델일수록 긴 지침, 역할 분리, 테스트 루프와 금지선을 더 안정적으로 따르는 경향을 체감한다. 역설적으로 모델이 강해질수록 하네스가 덜 필요한 것이 아니다. 작업 반경이 커져 잘못된 목표를 빠르게 완수할 위험도 커지므로, 승인 게이트와 관측성이 더 중요해진다.
커뮤니티 반응: 생산성만큼 비용과 복잡성도 본다
MoAI의 공개 저장소와 ClaudeAI 커뮤니티의 출시 토론에서 긍정적으로 회자되는 지점은 SPEC-first, TDD, 전문 에이전트와 반복 가능한 팀 절차다. 반대쪽 우려도 타당하다.
- 작은 수정에는 명세와 오케스트레이션이 오히려 느리다.
- 여러 에이전트의 컨텍스트와 검증 반복은 토큰 비용을 키운다.
- 문서가 자동 생성물로 불어나면 오래된 규칙이 새 판단을 방해한다.
- 프레임워크 기능에 지나치게 기대면 모델 독립성이 런타임 종속으로 바뀐다.
그래서 모든 작업에 무거운 절차를 강제하면 안 된다. 위험도에 따라 경량 수정, 표준 기능, 데이터·인증·결제 같은 고위험 변경의 게이트를 달리하고, 사용되지 않는 컨텍스트는 정기적으로 삭제해야 한다.
결론: 휴먼코드 0의 진짜 생산성
휴먼코드 0의 성과는 키보드 입력량이 0이라는 숫자 자체가 아니다. 팀원이 코드를 쓰는 시간 대신 요구사항을 명시하고, AI의 변경을 검증하며, 더 빠르게 피드백을 반영할 수 있게 된 점이다. 실패한 작업도 개인의 프롬프트 비법으로 남기지 않고 SPEC·가이드·테스트·CI 규칙으로 환원하면 다음 모델과 다음 팀원이 함께 배운다.
MoAI는 완성품을 대신 만드는 마법이 아니라 AI가 팀의 개발 방식을 반복 실행하게 만드는 매뉴얼 키트다. 좋은 하네스의 최종 지표는 생성 코드량이 아니라 결함 탈출률, 변경 리드타임, 롤백률, 리뷰 시간과 요구사항 추적성이다. 사람이 방향과 책임을 잡고 에이전트가 실행을 맡을 때, 휴먼코드 0은 무모한 바이브 코딩이 아니라 재현 가능한 엔지니어링 방식이 된다.
댓글 없음:
댓글 쓰기