연봉 360만원짜리 시니어 개발자를 고용했습니다

AI 에이전트와 함께 개발 워크플로를 다듬으며 도착한, 현재 시점 제 개발 워크플로 하네스를 소개합니다. /work-issue 스킬 하나로 기획/설계, 구현 계획, 이슈 생성, 구현, 셀프리뷰, PR, 리뷰 반영, 머지까지 한 번에 동작할 수 있도록 했습니다.

시작하기 전에

이런 분들이 읽으시면 좋을 것 같아요!

Claude Code로 프로젝트를 운영하며 반복 작업 자동화를 고민 중인 개발자

superpowers 스킬 라이브러리가 실전 워크플로에서 어떻게 쓰이는지 궁금한 개발자

0) 개요

AI 코딩 에이전트는 인간의 보폭과는 비교가 안 되는 속도로 달릴 수 있는 적토마와 같습니다. 하지만 아이러니하게도 그만큼 빠르고 강력하기 때문에 목적지에 정확하게 도착시키는 일은 오히려 쉽지 않습니다.

하나의 기능을 머릿속 구조에 맞게, 완성도 있게 구현하도록 하려면 이 적토마에게 아주 섬세하게 지침을 전달해야 합니다.

그렇다고 전속력으로 달리는 적토마를 갈림길마다 멈춰 세워 방향을 알려주고 다시 출발시키는 것은 너무 비효율적입니다. 그보다는 출발 전에 내비게이션처럼, 지도를 펼쳐 경로를 미리 합의하는 편이 훨씬 안정적이고 빠릅니다.

한 발 더 나아가, 프로젝트의 구조와 특성, 제약까지 미리 학습시켜 두면, 일러두지 않은 갈림길에서도 적토마가 알아서 프로젝트에 맞는 선택을 할 수 있게 됩니다. 도로 교통 상황에 따라 내비게이션이 더 나은 길을 제안하는 것처럼요.

문제는 그렇게 잘 교육된 적토마와 끝까지 함께할 수 없다는 점입니다. 적토마는 실수하고, 이전 피처와 지금 피처를 혼동하고, 기억력이 나빠 제 지침을 갑자기 잊어버리기도 합니다. 그런 적토마를 한 세션 안에서 계속 재교육하다 보면, 어느 순간 새 적토마를 데려오는 것보다 교육된 적토마가 오히려 성능이 나빠지는 시점이 옵니다. 이를 **컨텍스트 부패(Context Rot)**라고 합니다.

그래서 적토마 한 마리를 붙잡고 오래 교육하는 대신, 그때그때 어떤 새로운 적토마가 와도 같은 품질로 달릴 수 있도록, 선배 적토마들의 실수와 금지 사항, 우리 프로젝트의 규칙이 미리 장착된 하네스를 만드는 것이 중요합니다. 핵심은 세대를 거듭한 지식의 축적으로, 하네스는 점점 더 개선되어야 한다는 것입니다.

인간 개발자보다 적토마가 월등히 빠르다는 것이 명확해진 지금, 개발 지식만큼 중요해진 것은 AI를 어디까지 어떻게 달리게 하고 어디서 멈춰 세울지 설계하는 능력이라고 생각합니다.

이 글은, 그 중에서 제가 사이드 프로젝트를 진행해오며 현재까지 구축한 개발 워크플로 하네스에 대해 다룹니다.

1) 목표

개발 워크플로를 설계하기 전에, AI에게 개발을 맡길 때 신경 쓰이고 불편했던 지점들을 모조리 적어보았습니다.

구현 방법에 확신이 있어도 혹시 더 좋은 방법이 있을까 싶어 기능 요구사항만 던지고 설계를 통째로 맡기는 일이 많아졌다. 즉, 질문이 점점 러프해진다.
AI가 제시한 설계가 현재 코드베이스와 레거시를 정말 잘 반영한 것인지 불안하다.
AI가 작성한 코드에 실수가 없는지, 보안, 성능, 안정성 측면이 걱정된다.
AI가 리뷰를 남겨도, 그 리뷰가 코드베이스를 제대로 이해하고 쓴 것인지, 빠뜨린 건 없는지 불안하다.
AI가 리뷰를 반영할 때, 리뷰를 회피하기 위한 임시 조치는 아닌지 불안하다.
작업 위치(메인/브랜치/워크트리), 브랜치 네이밍, 커밋 메시지 컨벤션, 빌드, 린팅, 테스팅 같은 작업 완료의 기준이 매번 다르다. 결과적으로 코드 품질은 물론, 품질을 점검하는 리뷰의 품질까지 걱정하게 된다.

정리해보니, 주된 고민은 속도는 빨라졌는데, 코드와 기능에 확신이 없다는 것이었습니다. 마치 세탁기를 돌려놓고 두 시간 내내 세탁기 앞을 서성이는 기분이랄까요.

그래서 위 고민들을 바탕으로 제가 불안해하지 않아도 되는 이상적인 AI 개발 워크플로를 한 번 정리해봤습니다.

내 개떡같은 요구사항을 찰떡같이 이해한다.
추가 결정이 필요한 부분을 먼저 발견하고 나와 논의한다.
코드베이스를 이해한 뒤 구현 방법을 제시한다.
작업 완료 기준과 테스트 범위를 명확하게 정의해 이슈(티켓)를 만든다.
이슈를 격리된 공간에서 작업한다.
변경 사항을 잘 정리하고 스스로 리뷰한다.
PR을 올린 뒤, 다른 AI의 리뷰를 지속적으로 반영한다.
리뷰 봇이 LGTM을 내면, 전 과정을 정리해 머지 전에 내게 보고한다.

매번 프롬프트로 부탁하지 않아도 모든 적토마가 이 사이클대로, 의도한 대로 정확하게 동작한다면, 압도적인 퍼포먼스를 보여줄 것이라고 생각했습니다.

그래서 아예 이 사이클 전체를 스킬 하나(/work-issue)로 압축하기로 했습니다. 성공한다면, 단 한 문장으로 언제나 이상적이고 일관된 사이클로 일하는 시니어 개발자를 고용하는 셈입니다. ~~(연봉은 환율이 올라 약 360만원)~~

그러면 저는 이 시니어 개발자의 진행 상황을 깃허브 이슈와 텔레그램 알림으로 틈틈이 확인하고, 다 완성된 PR만 검토해 머지하면 되는 것이죠.

2) 설계

/work-issue 명령어 한 줄로 구동되는 전체 워크플로 사이클을 도식화하면 다음과 같습니다.

이 사이클에서 제가 키보드에 손을 올리는 순간은 최초의 요구사항 한 줄, 설계 단계의 객관식 답변 몇 번, 그리고 마지막 머지 승인이 전부입니다. 나머지 과정은 모두 에이전트가 수행합니다.

먼저, 이런 자동화가 안정적으로 굴러가려면 전제가 필요합니다. AI가 반드시 멈춰야 할 지점, 철저히 따라야 할 컨벤션, 그리고 기준을 충족하지 못하면 물리적으로 막히는 게이트가 시스템 곳곳에 촘촘히 박혀 있어야 합니다. 그래서 하네스를 독립된 세 개의 계층으로 나누어, 아래 계층이 위 계층을 단단히 떠받치는 구조로 설계했습니다.

코드 품질 게이트: 코드 품질을 물리적으로 통제하는 영역 (Git 훅, CI, 빌드 체크)
GitHub 컨벤션: AI 산출물의 일관성을 보장하는 입출력 규격 (이슈 폼, 브랜치 네이밍, PR 템플릿, 커밋 컨벤션)
/work-issue 스킬: 위 두 계층의 기반 위에서 워크플로를 순차 구동하는 오케스트레이터

각 계층의 역할을 구체적으로 살펴보겠습니다.

2-1) 코드 품질 게이트

코드 품질은 단일 지점에서, 단번에 검증하지 않습니다. 여러 지점에 게이트를 설치하되, 실행 속도가 빠른 게이트는 자주 동작하게 하고, 무거운 게이트는 중요한 병목 지점에 배치합니다.

지점	무엇을	왜 여기서
pre-commit	staged 파일 Prettier	커밋마다 도는 가장 빠른 가드. 포맷만.
pre-push	format, typecheck, lint, test	푸시 전 마지막 로컬 게이트 (CI `verify`와 동일 구성)
CI (`verify`)	format, typecheck, lint, test	신뢰의 공개 게이트. PR마다 검증
claude.yml	AI 보조 코드 리뷰	안정성, 성능, 보안 별도 리뷰. 인라인 코멘트와 LGTM 최종 판정

여기서 핵심은, 각 게이트가 기준 미달 코드를 걸러내는 최소 기준으로서 git 레벨에서 강제로 막아버린다는 점입니다. 특히 포맷, 린팅, 타입 규칙은 간과하기 쉽지만 AI가 일관되게 코드를 이해할 수 있도록 하는 몇 안 되는 아주아주 중요한 장치입니다.

2-2) GitHub 컨벤션

2-1과 마찬가지로, 에이전트에게 구현의 자율성은 부여하되, 결과물의 형태는 철저히 통제해야 합니다. 이를 위해 모든 입출력을 GitHub 컨벤션 규약으로 고정하고 강제했습니다.

이슈 폼 3종 (feat/fix/chore): 공통적으로 1. 작업 범위와 2. 완료 조건 을 필수로 입력받습니다. 완료 조건은 이후 에이전트의 작업 완료 상태를 판단하는 절대적 기준이 됩니다.
브랜치 네이밍: feat/12/ga4-funnel처럼 타입/이슈번호/슬러그 형식을 강제합니다.
PR 템플릿: Closes #N으로 이슈를 연결하고, 추후 AI 리뷰 봇이 활용할 수 있도록 안정성, 성능, 보안 3축 셀프리뷰 체크리스트를 포함합니다.

2-3) `/work-issue` 스킬✨

개발 워크플로 하네스의 본체입니다. /work-issue 명령어 한 줄이 하위의 수많은 규약을 묶어 파이프라인을 실행합니다. 다만 이 오케스트레이터가 모든 기능을 직접 수행하는 것은 아니고, 각 단계에 특화된 도구들을 적재적소에 호출하여 워크플로를 완성합니다.

주로 사용하는 도구는 오픈소스 스킬 라이브러리 **superpowers**와 Claude Code 내장 리뷰 스킬입니다. superpowers는 브레인스토밍, 플랜 작성, TDD, 워크트리, 코드리뷰 수신 등 개발 워크플로 전반의 행동 규범을 스킬 형태로 제공하는 라이브러리인데, 각 스킬 문서를 열어보면 디테일이 꽤 단단해서, 이후 단계별로 함께 소개하겠습니다.

단계	부품 스킬	출처	강제하는 것
설계 정렬	`brainstorming`	superpowers	설계 승인 전 구현 금지, 질문은 한 번에 하나, 접근법 2~3개 비교
구현 계획	`writing-plans`	superpowers	2~5분 단위 태스크, 정확한 파일 경로·실제 코드, TBD 금지
작업 공간 분리	`using-git-worktrees`	superpowers	중첩 워크트리 방지, gitignore 검증, 베이스라인 테스트
구현 + 커밋	`/commit`	팀/개인 컨벤션	커밋 컨벤션 준수, 의미 단위 커밋 분리
로컬 셀프리뷰	`/code-review` `/security-review`	Claude Code 내장	diff의 버그 및 보안 리뷰
CI + 봇 리뷰 반영	`receiving-code-review`	superpowers	검증 후 반영, 맹목 수용 금지

/work-issue의 설계 원칙 중 하나는 컨벤션을 스킬 안에 하드코딩하지 않는다는 것입니다.

커밋 규칙은 .github/COMMIT_CONVENTION.md를, 이슈 규격은 .github/ISSUE_TEMPLATE/을, 제품/디자인 결정은 DESIGN.md로, 각 단계에서 SoT 문서를 그때그때 읽어 따릅니다. 이 덕분에 컨벤션이 바뀌어도 스킬은 손대지 않고 해당 문서 하나만 고치면 됩니다.

위 도식의 초록 육각형 지점이 work-issue 스킬의 휴먼 게이트입니다.

기본적으로 에이전트가 멈추고 사람에게 묻는 지점은 다음과 같이 3곳입니다.

설계, 기획 승인: 이슈 초안 확인
- (UI 작업이라면 시안 비교, 선택도 이 단계에서 함께 진행)
작업 범위 확정 (조건부): 작업을 수행하는 에이전트가 이슈의 완료 조건이 모호할 때, 코드를 손대기 전에 묻습니다.
- 사실상 AI가 다른 AI가 작성한 계획을 검토하는 단계입니다.
머지 직전 최종 승인

그 사이의 사소한 선택들(네이밍, 기본값, 동등한 접근 중 택일)은 멈춰 묻지 않고 알아서 컨벤션과 프로젝트의 특성에 따라 결정한 뒤, 특이사항은 결과 보고에 한 줄로 남깁니다.

이제 이 하네스 위에서 요구사항 한 줄이 실제로 머지까지 가는 과정을 따라가 보겠습니다.

3) 시니어 개발자에게 일 시키기

현재 개발 중인 프로젝트에는 마이페이지에 프로필 수정하는 페이지가 존재하지 않습니다. /work-issue를 통해 프로필 수정 기능을 구현해볼게요.

/work-issue에 요구사항을 설명하거나, 이미 만들어 둔 이슈(티켓) 번호를 입력하면 사이클이 시작됩니다.

/work-issue 호출 — 요구사항 설명 또는 이슈 번호를 인자로 받습니다.

인자가 이슈 번호(숫자) → 기존 이슈로 바로 진행합니다. 이슈에 설계가 비어 있으면 설계 정렬부터 시작합니다.
인자가 작업 설명 → 설계와 계획을 먼저 잡고, 그 결과물로 이슈를 생성합니다.

3-1) 설계 정렬: brainstorming

요구사항을 입력하면 가장 먼저 superpowers의 brainstorming 스킬이 돕니다. 이 스킬은 모든 작업 전에 탐색 → 질문 → 설계 → 문서화 → 승인이라는 고정 루프를 강제합니다.

프로젝트 컨텍스트 탐색: 기존 파일, 문서, 최근 커밋을 먼저 살펴 현재 상태를 파악합니다.
명확한 질문으로 요구사항 파악: 질문은 한 번에 하나씩, 가능하면 객관식으로. 목적, 제약 조건, 성공 기준을 차근차근 묻고, 스코프가 너무 크면 먼저 쪼개자고 제안합니다.
2~3개 접근 방식 비교: 항상 복수의 설계 방향을 각각의 트레이드오프와 함께 제시하고, 추천하는 방향을 밝힙니다.
섹션별 점진적 승인: 아키텍처, 컴포넌트, 데이터 흐름, 에러 처리, 테스트 전략을 섹션별로 나눠 설명하고 각각 확인을 받습니다.
스펙 문서화 + 셀프리뷰: 승인된 설계를 문서로 정리한 뒤, 남아 있는 TBD나 모호한 부분, 섹션 간 모순, 두 가지 이상으로 해석될 수 있는 요구사항을 스스로 점검해 하나로 못 박습니다.
사용자 리뷰 게이트: 최종적으로 스펙을 승인해야만 다음 단계로 넘어갑니다.

명시되어 있는 기본 원칙도 훌륭합니다.

단순해 보여도 설계 먼저.
필요 없는 기능은 설계에서 과감히 제외하는 YAGNI
내부 구현을 읽지 않아도 역할이 이해되도록 작고 명확하게 쪼개기
기존 코드베이스 존중, 목표와 무관한 대규모 리팩토링은 제안 X

이 단계에서 제가 하는 일은 간단한 답변뿐입니다. "2번.", "그 기능은 빼자.", "모바일 대응은 다음에." 의사결정만 합니다.

3-2) 구현 계획: writing-plans

설계가 승인되면 superpowers의 writing-plans 스킬이 구현 계획을 세웁니다. 이 스킬에서 가장 마음에 들었던 건, 스킬이 상정하는 대상 전제가 정확히 제가 원하던 것이었다는 점입니다.

"Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.”

실력은 있지만 우리 코드베이스와 도메인은 전혀 모르는 개발자가, 이 문서 하나만 보고 구현, 테스트, 커밋까지 마칠 수 있도록 계획을 쓰라는 것입니다. 그래서 산출되는 플랜은 이런 모습입니다.

헤더: Goal 한 줄 요약, 접근 방식 2~3문장, 기술 스택, 그리고 스펙에서 그대로 복사해 온 Global Constraints(버전 제약, 네이밍 규칙 등 모든 태스크에 공통 적용되는 제약)
태스크: 독립적인 테스트 사이클을 가질 수 있는 최소 단위. 생성/수정/테스트할 정확한 파일 경로와, 앞뒤 태스크가 주고받는 인터페이스(함수 시그니처, 파라미터, 반환 타입)를 명시
스텝: 각 스텝은 2~5분짜리 액션 하나( 실패하는 테스트 작성 → 실패 확인 → 최소 구현 → 테스트 통과 확인 → 커밋 ), 철저한 TDD 사이클.

그리고 플랜 안에 절대 있어서는 안 되는 것들이 명시되어 있습니다.

❌ TBD, TODO, "나중에 구현" 같은 항목.
❌ "적절한 에러 처리 추가", "엣지 케이스 처리"처럼 구체 내용 없이 뭉뚱그린 문장
❌ "Task N과 유사하게" 식의 참조
- 코드를 반복해서라도 그대로 적도록.
❌ 어느 태스크에도 정의되지 않은 타입, 함수의 언급

플랜을 다 쓰고 나면 스스로 스펙 커버리지(요구사항마다 대응 태스크가 있는지)와 태스크 간 타입, 네이밍 일관성을 검토합니다.

즉, writing-plans는 스펙에서 실제 구현까지 가는 완전한 실행 청사진을 처음 보는 사람 기준으로, TDD 스타일로 계획을 작성합니다.

3-3) 이슈 생성: 작업 완료 조건 정하기

승인된 설계와 계획은 이제 이슈 규격에 맞춰 변환됩니다. 핵심은 확정된 결정사항은 배경/설계 섹션으로, 계획 스텝은 '체크 가능한 완료 조건'으로 두는 것입니다.

완료 조건은 이후 작업 단계에서 작업을 수행하는 AI가 작업을 완료했음을 판단하는 기준이 되기 때문에, 명료하게 자가 검증이 가능하도록 작성을 강제합니다. 이를 통해 AI 에이전트의 고질병인 False Completion, Overclaiming 문제를 예방할 수 있습니다.

이슈 초안 확인은 구현 계획 승인에 묶여 함께 이뤄지므로, 이슈 생성만을 위한 별도의 정지 지점은 없습니다. 다만 최종 생성된 초안을 다시 한번 훑고 넘어가고 싶다면, 이 지점에 별도의 승인 게이트를 추가해 이슈(티켓)를 생성하도록 커스터마이징할 수도 있습니다.

만약 작업 자체가 3-2)의 2~5분짜리 액션으로 쪼개기 어렵거나 별도 작업으로 분류할 필요가 있다면, 여러 개의 이슈를 한 번에 생성하도록 설계합니다.

3-4) 격리된 작업 공간: using-git-worktrees

구현에 앞서 superpowers의 using-git-worktrees 스킬이 격리된 작업 공간을 만듭니다. 이 레포의 컨벤션은 워크트리 .claude/worktrees/<이슈#>-<슬러그>, 브랜치 <타입>/<이슈#>/<슬러그>입니다.

using-git-worktrees는 단순히 아래의 순서로 안전하게 워크트리를 분리합니다.

이미 워크트리 안인지 먼저 감지해 워크트리 안에 또 워크트리를 파는 사고를 방지합니다.
워크트리 디렉토리가 gitignore에 등록되어 있는지 검증해 워크트리 사본 전체가 git에 잡히지 않도록 합니다.
의존성 설치 후 기초 테스트로 정상 동작을 확인한 뒤에야 구현을 시작합니다.

이렇게 격리된 공간에서 에이전트를 실행하면 서로 다른 작업이 같은 파일을 동시에 편집하는 사고를 막을 수 있고, 그동안 추가적인 작업을 독립적으로 수행할 수 있습니다. 추후 여러 수정 사항을 머지할 때 충돌 지점도 깔끔하게 확인할 수 있습니다.

3-5) 이슈 추출 → 구현 → 커밋

이제 에이전트가 이슈에서 플랜을 읽어오고, 완료 조건을 향해 구현합니다.

여기에 3-2의 플랜 전제와 플랜이 그토록 상세하고 잘게 쪼개져야 했던 이유가 있습니다. writing-plans가 생성한 플랜 헤더에는 태스크마다 오염되지 않은 새 서브에이전트를 파견하는 실행 방식(subagent-driven-development) 이 권장으로 박혀 있습니다.

각 태스크의 작업을 수행하는 AI는 세션에 쌓인 히스토리를 물려받지 않고, 본인의 태스크 브리핑만 듣고 작업을 합니다. 작업 완료 조건을 확인하고 명확한 테스트 코드를 선제적으로 작성한 뒤, 태스크가 끝날 때마다 스펙 준수 여부와 코드 품질을 리뷰받고, 마지막에는 브랜치 전체를 조망하는 최종 리뷰를 거칩니다. 매 태스크마다 갓 교육을 마친 새 적토마가 투입되는 셈이니, 서두에서 말한 컨텍스트 부패를 구조적으로 회피합니다.

커밋은 자작 스킬 /commit에 위임됩니다. 이 스킬은 AI가 커밋을 너무 크게 뭉치거나 반대로 너무 잘게 쪼개지 않도록, 팀/개인이 선호하는 정해진 기준대로 쪼개는 역할을 수행합니다.

커밋 컨벤션은 스킬 안에 하드코딩하지 않고, 별도로 SoT로 보관하여 매번 컨벤션을 읽고, 최근 git log에서 실제 커밋 톤을 참고해 커밋 메시지를 만듭니다. 컨벤션이 바뀌면 그 문서 하나만 고치면 되고, 스킬은 손대지 않습니다.

그 외에도 의존성 있는 변경을 앞 커밋에 배치(ex. 리팩토링 → 기능), .env·시크릿 파일 혼입 시 경고 후 확인, --amend 금지(항상 새 커밋), 훅 우회(--no-verify) 금지 같은 가드가 박혀 있습니다.

3-6) 로컬 셀프리뷰

푸시 전, 작업 컨텍스트를 가장 안정적으로 확인할 수 있는 순간인 로컬에서, 에이전트가 작성된 코드를 3축을 바탕으로 병렬로 점검합니다. 이때는 가장 신뢰도가 높은 AI 모델을 사용합니다. (7월 초 기준 Fable, 사라지면 Opus)

3-6-1) 안정성/버그 → `/code-review`

Claude Code 내장 스킬입니다. 현재 diff에서 정합성 버그와 단순화, 효율 여지를 찾습니다. effort 레벨로 리뷰 폭을 조절할 수 있습니다. (낮으면 확신이 높은 것만, 높이면 불확실한 것까지 폭넓게 탐색합니다.), 여기서는 폭넓게 탐색합니다.

3-6-2) 보안 → `/security-review`

Claude Code 내장 스킬입니다. 브랜치의 변경분만 떼어 인젝션, 인증, 시크릿 노출 같은 보안 축을 점검합니다.

3-6-3) 성능

불필요한 연산, 쿼리, 리렌더 회귀를 직접 점검합니다.

발견 사항은 그 자리에서 고치고 다시 커밋합니다. 그래서 PR을 올리기 전에는 3축에 대한 보완사항이 모두 반영되어 있어야 합니다. 이후 푸시하는 순간 pre-push 훅이 format, typecheck, lint, test를 강제로 한 번 더 돌려 코드 일관성을 보장합니다.

3-7) PR 생성 및 리뷰

서브 에이전트들의 작업이 완료되면, 작업 사항을 정리하여 PR 템플릿(요약/변경 사항/3축 셀프리뷰/테스트/스크린샷)에 맞게 PR을 생성합니다.

PR 생성과 동시에 GitHub Actions의 리뷰 봇(claude.yml)이 자동으로 인라인 리뷰를 답니다.

현재 리뷰 봇의 주요 규칙은 다음과 같습니다.

일부러 다른 모델을 씁니다. (현재 Opus) 로컬 셀프리뷰와 봇 리뷰의 모델을 분리해서, 같은 모델이 작성한 코드에 갖는 맹점을 줄입니다.
발견한 모든 이슈를 보고합니다. 만약 확신이 높은 이슈, 영향력이 높은 이슈와 같이 특정 기준에 따라 리뷰를 진행할 경우, 최신 모델일수록 이 지시를 따르기 위해 버그를 찾아놓고도 확신이 낮다며 보고하지 않는 경우가 있습니다. 모델이 좋아질수록 리뷰 리콜이 떨어지는 역설입니다. 따라서 봇 프롬프트는 커버리지를 최우선으로 보고하되 [확신도/심각도] 태그를 붙이게 하고, 필터링은 다음 단계에서 진행합니다.

이후 깃허브 봇 리뷰를 반영하는 루프를 돕니다. 여기서는 gh CLI로 봇의 코멘트를 직접 읽고, superpowers의 receiving-code-review 스킬을 사용합니다.

receiving-code-review 스킬은 다음과 같이 고정된 응답 패턴으로 동작합니다.

리뷰 읽기
요구사항을 자기 말로 재서술하기
현재 코드베이스와 대조 검증하기
이 코드베이스에 기술적으로 맞는지 평가하기
반영 or 반박하기

receiving-code-review의 기본 원칙은 맹목 수용 금지이며, 특히 "You're absolutely right!ㅎㅎ" 같은 영혼 없는 맞장구는 스킬 문서에 명시적 금지어로 올라가 있습니다.

또한 리뷰어의 말을 맹목적으로 수용하지 않는 것 뿐만 아니라, 때로는 리뷰어에게 역으로 반박하기도 합니다. (ex. 봇 리뷰어가 특정 함수에 대해 구현 방식을 지적했을 때, 반영 전에 먼저 grep으로 실제 사용처를 확인하고 만약 그 함수가 어디에서도 호출되지 않는다면 제대로 구현하지 않고, 삭제를 스레드의 답글로 역제안)

이렇게 동의하지 않는 지적은 근거를 PR 코멘트로 남겨 반려하고, 타당한 지적은 반영하고, 커밋하고, 푸시합니다. 푸시하면 봇이 재리뷰하고, 이 티키타카가 봇이 LGTM✅을 뱉을 때까지 자동으로 돕니다.

현재는 5라운드를 넘겨도 수렴하지 않으면 리뷰 반영을 멈추고 상황을 요약해 저에게 알리도록 했습니다.

3-8) 머지 & 환경 정리

머지가 가능한 조건은 세 가지입니다.

리뷰 봇 LGTM ✅
CI verify green ✅
Vercel 프리뷰 빌드 green ✅

세 개의 조건을 모두 통과하면 에이전트가 지금까지의 추가 변경사항을 포함해 정리하여 저에게 알리고, 머지를 승인할지 묻습니다.

머지 승인 시 작업한 worktree 제거 → squash merge → 원격, 로컬 브랜치 삭제 → main 동기화를 수행하고, 기존에 파두었던 이슈는 PR 본문의 Closes #N을 통해 머지 시 자동으로 닫히게 됩니다.

4) 그래도 여전히, 불안하다.

솔직하게, 여기까지 읽으신 분들 중 여전히 AI에 대한 모든 불안이 해소되지 않았다고 느끼시는 분들이 많을 것 같습니다. 왜냐면, 제가 그렇거든요.

이렇게 하네스를 구축하고, 시스템을 잡고, 에스컬레이션을 적절히 넣어도 사람 리뷰어가 없다는 사실은 변하지 않습니다. AI는 "앗.. 실수! 죄송합니다 엣큥 ><" 하면 그만이지만, 그 실수가 금전적 손실로 이어졌을 때 책임지는 것은 결국 개발자이기 때문입니다.

모델을 분리한 2중 AI 리뷰가 그 공백을 얼마나 메워주는지는 솔직히 지금도 계속 검증하는 중입니다. 물론 조금씩 개선되고 있지만, 개선 중이라는 말 자체가 아직 완벽하지 않다는 뜻이기도 하니까요. 그래서 여전히, AI 곁 개발자의 존재는 중요합니다.

결국 여전히 불안한 만큼은 제가 직접 코드를 추적해 가며 꼼꼼히 살펴보고, 읽고, 실행해 봅니다. 다만 예전과 달라진 점이 있다면, 제가 검토하는 그 순간에도 다른 적토마가 다음 기능을 구현하고 있다는 것입니다. 각자의 역할에 충실하고 있는 셈이니, 이 정도면 꽤 건강한 분업이 아닐까요?

5) 코더에서 의사결정권자로

이제 새로운 기능 개발은 더 이상 어려운 일이 아닙니다.

요구사항 단 한 줄로부터 시작해 AI 에이전트가 컨벤션에 맞춰 이슈를 생성하고, 격리된 환경에서 코드를 구현하며, 스스로 리뷰하고, PR을 올려 리뷰 봇과 토론한 뒤, 최종 정리까지의 사이클을 스스로 완수합니다.

이 견고한 파이프라인 위에서 개발자의 역할도 달라집니다. 코드를 한 줄씩 지시하고 오타를 수정하던 타이핑 노동이 사라진 자리에는, 더 깊은 판단의 몫이 남습니다. 설계의 방향성을 결정하고, 아키텍처의 트레이드오프를 평가하며, 최종 품질을 승인하는 의사결정권자로서의 역할입니다.

결국 AI 시대에 기술을 주도하고 지식을 내 것으로 남기는 일을 지켜내는 것은 AI가 어디까지 자율적으로 달리고 어디서 멈춰 인간의 판단을 구해야 하는지, 그 경계와 규칙을 통제하는 하네스를 얼마나 촘촘히 짜느냐에 달려 있다고 생각합니다.

이것이 팀 단위로 확장된다면, 이슈 보드만 봐도 각자의 컴퓨터에서 적토마들이 어떤 작업을 열심히 수행하고 있는지 한눈에 보일 수 있겠죠.

빠른 속도는 시스템에 맡겨두되, 체계와 신뢰의 고삐는 직접 쥐어보시길 권합니다. 이 글이 여러분만의 하네스를 짓는 데 작은 도움이 되었기를 바랍니다. 궁금하신 점이 있다면 언제든 댓글로 남겨주세요!

그럼, 즐거운 승마 되세요! 🐎