Part 04. 하네스 실전편 [하네스 엔지니어링 with 제미나이]

본 글은 하네스 엔지니어링 with 클로드 코드 기반으로 작성되었습니다. 해당 책을 같이 보시면 이해에 도움이 됩니다
https://product.kyobobook.co.kr/detail/S000220048885

Part 04. 하네스 실전편: 실제로 돌아가는 4가지 AI 팀 만들기

Chapter 11. 코드 리뷰 자동화 팀

실전 시나리오: 깃허브 코드 검토

개발자가 코드를 새로 작성해서 올렸을 때(PR), 사람이 일일이 수백 줄의 코드를 읽다 보면 치명적인 보안 구멍이나 데이터베이스 렉을 유발하는 코드를 놓치기 쉽습니다. 이를 자동으로 꼼꼼히 점검해 주는 2인 리뷰 팀을 만듭니다.

팀 구성과 역할

• 보안 검사관 (SecurityAgent): 해커가 침투할 수 있는 비밀번호 노출이나 악성 코드 취약점만 현미경으로 들여다봅니다.
• DB 성능 코치 (SqlAgent): 데이터베이스에서 자료를 불러오는 쿼리문이 너무 느리거나 서버를 멈추게 만들 위험이 없는지 점검합니다.

명령어 하나로 필요한 검사만 골라 부르기

전체 코드를 다 볼 때는 /review-all을 치면 두 명이 순서대로 코드를 살펴봅니다.
하지만 단순한 쿼리 하나만 확인하고 싶을 때 전체 팀을 깨우면 시간과 돈이 낭비됩니다. 이때는 /review-sql [쿼리문]만 입력합니다. 오케스트레이터가 보안 검사는 건너뛰고 DB 성능 코치 1명만 즉시 깨워 1초 만에 실행 계획을 튜닝해 줍니다.

---

Chapter 12. 풀스택 기능 구현 팀

실전 시나리오: "새로운 로그인 화면 만들어줘"

새로운 웹사이트 기능을 만들 때는 화면을 예쁘게 만드는 일(프론트엔드)과 데이터베이스에 비밀번호를 저장하는 일(백엔드)이 동시에 필요합니다.

부채를 펼치고 접는 팬아웃 · 팬인 워크플로우

1. Phase 1 (기획자): 어떤 화면이 필요하고 데이터는 어떤 규칙으로 주고받을지 '약속 규격(API 명세)'을 먼저 종이에 적습니다.
2. Phase 2 (팬아웃 - 부채 펴기):

• 백엔드 AI는 서버 코드를 짜고,
• 프론트엔드 AI는 로그인 버튼과 화면 디자인을 동시에 병렬로 작성합니다. 작업 시간이 절반으로 줄어듭니다.

3. Phase 3 (팬인 - 부채 접기): 통합 검증 AI가 둘이 만든 코드를 합쳐서 실제로 로그인이 잘 되는지 한 번에 테스트합니다.

이때 두 AI가 서로 다른 생각을 하지 않도록, 기획자가 작성한 약속 규격을 공유 칠판(State)에 딱 붙여두고 보면서 코딩하게 만드는 것이 핵심입니다.

---

Chapter 13. 레거시 마이그레이션 팀 (3,500개의 낡은 테스트 파일)

실전 시나리오: 3,500개의 오래된 파일 일괄 업데이트

회사 시스템을 최신 버전으로 업그레이드할 때, 과거에 작성된 3,500개의 낡은 파일들을 새 문법으로 일일이 바꿔야 하는 거대한 작업이 있습니다. AI에게 "알아서 다 바꿔줘"라고 한꺼번에 던지면 중간에 멈추거나 코드가 꼬여 대형 사고가 납니다.

족보(의존성) 먼저 그리고 바구니에 나누어 담기

1. Phase 1 (의존성 매핑): 가장 먼저 3,500개 파일 중 "누가 누구의 도움을 받아 돌아가는지" 가계도(족보)를 먼저 그립니다. 이 단계의 정리를 아까워하면 나중에 무한 오류에 빠집니다.
2. Phase 2 (배치 분할): 3,500개를 한 번에 돌리지 않고, 서로 영향이 없는 파일들끼리 50개씩 작은 묶음(Batch)으로 쪼개어 차례대로 변환합니다.
3. Phase 3 (3%의 수작업 격리): 3,500개 중 3,400개는 AI가 완벽히 고치지만, 구조가 너무 꼬여있는 100개 파일은 AI도 갈팡질팡합니다. 이때 억지로 AI에게 시키지 않고 "사람 확인 필요 바구니(manual-queue)"로 자동으로 던져두어, 나중에 사람이 직접 눈으로 보고 고칠 수 있게 격리합니다.

---

Chapter 14. 디버깅 및 RCA(원인 분석) 팀

실전 시나리오: "내 컴퓨터에선 잘 되는데 서버에선 왜 터지지?"

개발자들이 가장 머리 아파하는 순간은 "분명 내 노트북에서는 잘 돌아가던 프로그램이 실제 서버에 올리니 먹통이 될 때"입니다. 감으로 때려맞히지 않고 탐정처럼 근본 원인(RCA)을 밝혀내는 팀을 꾸립니다.

탐정 3인방의 수사 과정

1. 로그 수집관: 에러가 난 순간의 서버 기록(로그)을 싹 긁어모아 붉은색 에러 메시지를 찾아냅니다.
2. 환경 비교관: 개발자 노트북과 실제 서버의 환경(파이썬 버전, 메모리 크기, 네트워크 설정)을 대조해 숨은 차이점을 밝혀냅니다.
3. 해결-검증관: "원인은 메모리 부족 때문"이라는 가설을 세우고, 코드를 고친 뒤 모의 테스트를 돌려 가설이 맞는지 확인합니다.

모든 수사가 끝나면 팀은 "어디가 범인이었고, 어떻게 고쳤으며, 재발을 막으려면 무엇을 해야 하는지" 깔끔한 원인 분석 보고서 1장을 사람에게 제출하고 깔끔하게 해산합니다.