AI 코딩 4단계는 그대로다. 사람만 빠졌고, 내가 세운 감시 훅 12개는 4개월간 발화 0회였다
AI 코딩 4단계는 그대로다. 사람만 빠졌고, 내가 세운 감시 훅 12개는 4개월간 발화 0회였다
사이드로 굴리는 모바일 게임 프로젝트가 하나 있다. 회사에서 AI로 설계를 밀어붙이다 두 달 만에 방법론을 접은 뒤에 시작한 거라(그 얘기는 지난 글에 썼다), 여기서는 조건을 하나 바꿔서 해보고 싶었다. 설계를 건너뛰지 않되, 그 설계를 내 손으로 쓰지는 않는 것. 분석부터 테스트까지 전부 AI에게 넘기고 나는 검토만 하는 구조를 만들어보자는 거였다.
219 커밋이 쌓였다. 설계 문서 21개, 테스트 파일 102개, 유니티 클라이언트 쪽에만 git이 추적하는 파일이 1,113개. 게임이 돈다. 5대5 전투가 굴러가고 가챠가 뽑히고 던전이 열리고 영웅 12종에 포트레이트까지 붙었다. 그 사이 내가 직접 친 코드는 거의 없다.
그래서 잘 굴러가는 줄 알았다. 이번 글을 쓰려고 오랜만에 "검토" 쪽 장치들을 열어봤는데…
열두 개 중에 이 레포를 보고 있는 게 하나도 없었다.
사람들이 착각하는 지점
"AI한테 말만 하면 알아서 다 만들어준다"는 말을 요즘 자주 듣는다. 반은 맞는데, 그 말이 자주 이렇게 번역돼서 돌아다닌다. 이제 분석이나 설계 같은 건 안 해도 된다.
이건 틀렸다. 그것도 관찰로 틀렸다고 말할 수 있는 종류로 틀렸다.
컴퓨터가 입력, 처리, 출력으로 도는 건 어떤 기계를 쓰든 안 바뀐다. 진공관이든 GPU든 그 셋은 그대로다. 기계의 성질이 아니라 계산이라는 일 자체의 성질이라서 그렇다. 분석, 설계, 구현, 테스트도 같은 층위에 있다. 뭘 만들지 모르는 상태에서 돌아가는 물건까지 가려면 그 넷을 어떤 형태로든 통과해야 한다. 통과하는 게 사람 손이냐 모델이냐는 한 층 아래 얘기다.
내 게임 프로젝트 디렉터리를 그냥 ls 해보면 나오는 게 이거다.
client/ design/ docs/ production/ server/ shared/ tests/ tools/
design/ 안에 gdd, balance, registry가 있고, docs/ 안에 architecture, engine-reference, handoff가 있다. production/ 안에는 epics, sprints, qa, sprint-status.yaml이 있다. 이게 뭐냐면 분석이고, 설계고, 구현이고, 테스트다. 이름만 게임 업계 용어로 바뀌었을 뿐이다.
design/gdd/ 밑에는 문서가 21개 있다. arena, battle-engine, economy, gacha, hero-system, tutorial 같은 식으로 시스템 하나에 문서 하나다. 그리고 이 문서들은 규격이 있다. 문서마다 Overview, Player Fantasy, Detailed, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria 여덟 개 섹션을 갖춰야 한다. 수식이 몇 번 수식이고, 어떤 예외 상황이 있고, 어떤 값이 밸런싱 손잡이인지가 다 적혀 있다.
분석 쪽도 형태가 남아 있다. production/ 밑에 epics, sprints, qa가 있고 sprint-status.yaml과 stage.txt가 지금 어느 단계인지를 들고 있다. 무엇을 만들지 쪼개고 순서를 정하고 지금 어디까지 왔는지 적어두는 일인데, 이것도 없앤 적이 없다. 오히려 이게 없으면 AI가 매 세션 처음부터 다시 판단해서 지난주에 결정한 걸 뒤집는다. 몇 번 겪고 나서 상태 파일이 늘었다.
테스트도 마찬가지다. client/Assets/Tests/EditMode/ 밑에 Unit, Integration, Performance가 나뉘어 있고 파일이 102개다. arena_battle_determinism_test.cs, try_spend_budget_test.cs, tutorial_gate_suppression_test.cs 같은 것들. 전투 결정론 검증, 재화 소비 예산 검증, 튜토리얼 게이트 억제 검증. 소프트웨어공학 교과서에 나오는 그 테스트 분류 그대로다.
AI 시대에 없어진 단계는 없다. 분석은 여전히 있고 설계도 여전히 있다. 없어진 건 단계가 아니라 그 단계를 손으로 통과하던 사람이다. 저 21개 문서를 쓴 것도, 102개 테스트를 쓴 것도 AI다. 그런데 문서가 필요하다는 사실 자체는 하나도 안 바뀌었다. 오히려 늘었다. 내가 손으로 짜던 시절에는 GDD를 21개까지 안 썼다. 머릿속에 있으면 됐으니까.
AI한테 맡기면서 문서가 늘어난 이유는 단순하다. AI는 내 머릿속을 못 읽는다. 예전에 암묵지로 들고 있던 걸 전부 파일로 꺼내놔야 세션이 바뀌어도 같은 판단이 나온다. "말만 하면 된다"는 건 말을 안 해도 된다는 뜻이 아니라, 말을 문서로 적어두면 그다음부터 실행이 자동이라는 뜻이다.
내 역할이 옮겨간 자리
그래서 219 커밋 동안 내가 실제로 한 일이 뭐였냐면, 읽고 판단하고 승인하는 거였다.
경제 설계가 올라오면 재화 흐름이 닫혀 있는지를 본다. 전투 엔진 설계가 올라오면 결정론이 깨지는 자리가 어디인지를 본다. 커밋이 올라오면 diff를 훑고 통과시킨다. 손은 안 움직이는데 판단은 계속 해야 한다. 역할이 수행에서 관리로 넘어간 거다.
이 판단이 형식적인 게 아니라는 것도 몇 번 확인했다. 문서에 적힌 대로 짰는데 문서 쪽이 틀려서 계획서대로 나갔으면 버그가 그대로 배포됐을 뻔한 적이 있다. 설계가 맞는지는 설계를 읽어야 알고, 읽는 건 아직 사람 몫이다.
여기까지는 사람들이 하는 말이 맞다. 개발자가 코더에서 리뷰어로, 실행자에서 관리자로 바뀐다는 말. 실제로 그렇게 됐다.
문제는 그다음이다.
관리도 노동이다. 그것도 꽤 지겨운 노동이다. AI는 하루에 커밋을 여덟 개씩 만들어내는데 나는 그걸 다 읽어야 한다. 설계 문서 여덟 개 섹션이 다 채워졌는지를 매번 눈으로 확인해야 하고, 자산 파일 이름 규칙이 지켜졌는지, JSON이 깨지지 않았는지, 하드코딩된 밸런스 숫자가 코드에 박히지 않았는지를 봐야 한다.
이걸 몇 주 하면 자연스럽게 드는 생각이 있다. 이것도 자동화하면 되잖아.
그래서 자동화했다. 훅을 깔았다.
감시 장치 열두 개, 727줄
.claude/hooks/ 밑에 지금 파일이 열두 개 있다. 다 합쳐서 727줄이다.
validate-commit.sh가 101줄로 제일 크다. 커밋 직전에 스테이징된 파일을 훑어서 설계 문서 섹션 누락, JSON 문법 오류, 게임플레이 코드의 하드코딩 숫자, 담당자 없는 TODO를 잡는다. validate-assets.sh는 72줄로 자산 파일 이름 규칙과 JSON 유효성을 본다. validate-push.sh는 보호 브랜치 푸시를 막는다. detect-gaps.sh는 155줄짜리로, 세션 시작할 때 코드는 많은데 설계 문서가 부족한 상태를 잡아낸다. 나머지는 세션 로깅과 알림 쪽이다. 여기에 에이전트 21종과 스킬 75개가 얹혀 있다.
숫자만 보면 꽤 그럴듯한 관리 체계다. 나는 이걸 만들어놓고 안심했다. 내가 매번 안 봐도 기계가 대신 본다고 생각했으니까.
그래서 이번에 열어봤다.
열어보니 아무도 안 보고 있었다
validate-commit.sh부터 보자. 이 훅에는 검사가 넷 있는데, 각각 이런 경로를 본다.
DESIGN_FILES=$(echo "$STAGED" | grep -E '^design/gdd/')
DATA_FILES=$(echo "$STAGED" | grep -E '^assets/data/.*\.json$')
CODE_FILES=$(echo "$STAGED" | grep -E '^src/gameplay/')
SRC_FILES=$(echo "$STAGED" | grep -E '^src/')
이 레포에 assets/도 없고 src/도 없다. 유니티 프로젝트라 소스는 client/Assets/Scripts/MasterHeroes/ 밑에 있고 데이터도 client/Assets/ 밑에 있다. 확인해보려고 전체 히스토리를 뒤졌다.
$ git log --all --name-only --pretty=format: | grep -E '^(assets|src)/' | sort -u | wc -l
0
219 커밋 동안 그 경로에 파일이 커밋된 적이 한 번도 없다. 그러니까 네 검사 중 셋은 발화 기회 자체가 0회였다. 더 나쁜 쪽은 따로 있다. 이 훅에서 유일하게 커밋을 차단할 수 있는 분기가 assets/data/의 JSON 문법 검사인데(exit 2로 실제로 막는다), 하필 그게 없는 경로를 본다. 차단 능력이 있는 코드가 한 번도 실행된 적이 없는 거다.
validate-assets.sh는 더 미묘하게 빗나갔다.
if ! echo "$FILE_PATH" | grep -qE '(^|/)assets/'; then
exit 0
fi
소문자 assets/다. 유니티는 자산 폴더 이름이 Assets로 대문자다. grep에 -i가 없으니 client/Assets/Data/foo.json은 이 조건에 안 걸린다. git이 추적하는 파일이 그 밑에 1,113개 있는데, 자산 검증 훅은 그중 단 하나도 본 적이 없다. 대문자 A 하나 때문이다.
detect-gaps.sh는 판정 조건이 두 줄이다.
if [ "$SRC_FILES" -gt 50 ] && [ "$DESIGN_FILES" -lt 5 ]; then
echo "⚠️ GAP: Substantial codebase ... but sparse design docs"
SRC_FILES는 find src 로 센다. src가 없으니 항상 0이다. 0은 50보다 크지 않다. 이 경고는 구조적으로 뜰 수 없다. 매 세션 시작마다 이 스크립트가 돌면서 "=== Checking for Documentation Gaps ===" 를 출력하고 아무것도 못 찾고 끝난다. 나는 그 출력을 매번 보면서 문제가 없다는 뜻으로 읽었다.
validate-push.sh는 아예 대놓고 꺼져 있었다.
if [ -n "$MATCHED_BRANCH" ]; then
echo "Push to protected branch '$MATCHED_BRANCH' detected." >&2
echo "Reminder: Ensure build passes, unit tests pass, and no S1/S2 bugs exist." >&2
# Allow the push but warn -- uncomment below to block instead:
# echo "BLOCKED: Run tests before pushing to $CURRENT_BRANCH" >&2
# exit 2
fi
차단하는 두 줄이 주석 처리돼 있다. 남은 건 "빌드 통과했는지, 테스트 돌렸는지, S1/S2 버그 없는지 확인하세요"라는 안내문이다. 사람한테 확인하라고 말하는 문장이 사람 대신 확인해주는 장치 자리에 앉아 있는 거다. 저 주석을 누가 썼냐면 이 훅을 만든 AI고, 그걸 읽고 통과시킨 건 나다.
살아 있는 검사가 하나는 있다. design/gdd/ 섹션 검사는 경로가 맞으니까 실제로 돈다. 그게 뭘 잡았는지 직접 세봤다. 설계 문서 21개에 여덟 개 필수 섹션을 대조하니 이렇게 나왔다.
| 문서 | 누락 섹션 |
|---|---|
| game-concept.md | 7개 (Player Fantasy, Detailed, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria) |
| systems-index.md | 6개 |
| gdd-cross-review-2026-04-18.md | 8개 전부 |
| gdd-cross-review-2026-04-19.md | 7개 |
| 나머지 17개 | 없음 |
전부 그대로 커밋돼 있다. 왜냐면 이 검사는 경고만 하고 exit 0으로 끝나기 때문이다.
여기서 구조가 드러난다. 차단할 수 있는 검사는 한 번도 실행된 적이 없고, 실행되는 검사는 차단하지 않는다. 같은 원인의 양면이다. 차단은 아프니까 아픈 검사는 안전한 경로에 놓였고, 안 아픈 검사만 실제 경로에 남았다. 내가 의식적으로 그렇게 배치한 건 아닌데, 아무도 아프지 않은 방향으로 굴러가면 결과는 똑같다.
이 훅들은 남의 지도를 들고 들어왔다
왜 경로가 안 맞나 싶어서 도입 시점을 찍어봤다.
$ git log --diff-filter=A --format='%ad %h %s' --date=short -- .claude/hooks/
2026-04-16 2ce2eaf chore: CCGS 기반 게임 개발팀 구성
$ git log --diff-filter=A --format='%ad %h' --date=short -- client/ | tail -1
2026-03-29 71154e9
client/ 스캐폴드가 3월 29일에 들어왔고, 훅들은 4월 16일에 들어왔다. 감시 장치가 감시 대상보다 18일 늦게 설치됐다. 처음부터 안 맞았던 거다. 훅을 짜는 시점에 레포 안에는 이미 client/Assets/가 있었는데 훅은 src/와 assets/를 봤다.
이유는 커밋 메시지에 있다. "CCGS 기반 게임 개발팀 구성". 외부 템플릿을 통째로 이식한 커밋이다. 그 템플릿은 src/와 assets/를 쓰는 레이아웃을 전제로 만들어졌고, 나는 그대로 가져와 유니티 레포에 얹었다. 그 뒤로 4개월간 이 세 파일은 한 줄도 안 고쳐졌다.
여기가 제일 아픈 지점이다. 나는 훅을 "도입"했다고 생각했는데 실제로 한 건 파일 복사였다. 도입은 대상에 맞춰 조준하는 작업까지 포함하는데 그 부분을 건너뛰었고, 건너뛴 걸 4개월간 몰랐다. 몰랐던 이유는 단순하다. 훅이 조용히 통과시킬 때와 검사할 게 없어서 통과시킬 때가 출력이 똑같기 때문이다. 둘 다 아무 말도 안 한다.
이게 사람이 직접 하던 시절과 다른 점이다. 내가 손으로 코드 리뷰를 하다 말면 리뷰가 안 된 게 티가 난다. 코멘트가 안 달려 있으니까. 자동 검사는 안 하고 있어도 하는 것과 겉모습이 같다. 침묵이 두 가지를 뜻하는데 로그에는 한 가지로만 남는다.
블로그 레포에서도 같은 걸 겪었다. 커밋 훅이 정작 커밋되는 파일을 안 보고 있었던 적이 있고, 시크릿 스캔을 걸어뒀는데 AWS 키가 그냥 통과한 적도 있고, 벤치마크 게이트가 두 달 반 죽어 있던 적도 있다. 그때마다 그 레포의 실수라고 생각했다. 다른 레포에서 같은 모양이 또 나오니까 이제는 실수가 아니라 이 작업 방식의 기본 실패 모드로 보인다.
CI는 더 조용하게 낡았다
훅보다 한 층 위에 CI가 있다. 여기도 봤다.
.github/workflows/tests.yml이 있고 EditMode 테스트를 유니티 러너로 돌리게 돼 있다. 그런데 트리거를 보면 한 줄뿐이다.
on:
workflow_dispatch:
푸시에도 PR에도 안 돈다. 손으로 눌러야만 돈다. 이걸 언제 바꿨는지 찾아봤더니 5월 4일이었고, 커밋 메시지에 이유가 적혀 있었다.
회사 PC GitHub repo 에 UNITY_LICENSE/EMAIL/PASSWORD secrets 미설정 + prototype 단계 (Step 9 진행 중) 라 push 시 자동 발화는 무의미한 fail. 보존은 하되 자동 트리거만 제거 — Sprint 2 + secrets 설정 후 push trigger 복구.
판단 자체는 합리적이다. 라이선스 시크릿이 없으면 매 푸시마다 빨간 X만 쌓이고, 그게 쌓이면 빨간 X를 무시하는 습관이 생긴다. 끄는 게 맞았다. 복구 조건까지 주석으로 적어놨으니 나쁘지 않은 처리다.
문제는 그 뒤다. 5월 4일 이후로 커밋이 42개 쌓였고, 그중 8월 초 커밋 하나가 눈에 걸렸다.
8642d53 chore(engine): Unity 6.3 → 6.5 (6000.5.4f1) 이주 + 컴파일 블로커 수정
엔진을 올렸다. 그리고 tests.yml은 지금도 안 바뀌었다.
env:
UNITY_VERSION: 6000.3.0f1 # Unity 6.3 LTS — update on /setup-engine upgrade
프로젝트의 ProjectVersion.txt는 6000.5.4f1이다. CI에 박힌 값은 6000.3.0f1이다. 주석에는 "엔진 업그레이드 시 갱신"이라고 친절하게 적혀 있는데 갱신이 안 됐다. 갱신이 안 된 걸 아무도 못 알아챈 이유는, 그 워크플로가 안 돌기 때문이다.
그러니까 이 게이트는 두 겹으로 죽어 있다. 자동으로 안 돌고, 수동으로 눌러도 설치되지 않을 에디터 버전을 요구한다. 나중에 시크릿을 채우고 트리거를 복구하는 날 나는 켜자마자 실패하는 파이프라인을 만난다. 원인은 테스트가 아니라 3개월 묵은 버전 문자열이다.
꺼둔 게이트는 꺼져 있는 상태로 보존되지 않는다. 낡는다. 이게 모델 버전이 오르면 하네스의 일부가 무효화된다는 얘기의 인프라 버전이다. 대상이 바뀌면 대상을 보던 장치가 같이 안 바뀐다. 그리고 그 불일치는 장치가 돌 때만 드러난다.
테스트 실행 기록도 봤다. test-results/ 안 로그 중 제일 최근이 editmode-batt-2026-05-03.xml이다. 그 뒤 42 커밋 동안 실행 증거가 하나도 안 남았다. 테스트 파일은 102개 그대로 있다. 쓰여 있고, 안 돌아간다.
곁다리로 하나 더 나왔다. .claude/settings.json 허용 목록에 Step 49 commit hash 3351fa1 기록 처럼 특정 커밋 해시가 박힌 일회용 규칙이 둘 남아 있다. 그 커밋을 만드는 순간 죽은 항목이다. 같은 파일에 /Users/kakaoent/... 로 시작하는 경로도 두 줄 있는데, 이 레포의 실제 경로는 /Users/jaewon.lee/...다. 다른 머신에서 굳은 문자열이 그대로 따라와서 아무 데도 안 걸리는 허용 규칙으로 남았다. 하나하나는 사소한데, 사소한 게 지워지지 않고 쌓인다는 게 이 레포에서 반복되는 모양이다. 설정 파일은 누가 감사하지 않으면 줄어들지 않는다.
순서가 거꾸로였다
여기까지 뒤지고 나니 내가 뭘 잘못했는지가 보인다. 검사기를 먼저 깔고 규칙은 나중에 정하려고 했다는 것.
원래는 반대다. 개발 주기를 네 단계로 끊는 이유가 단계마다 정해야 할 게 다르기 때문인데, 그 "정하는 일"이 먼저고 자동 검사는 정해진 것에서 파생돼야 한다. 단계마다 하나씩 놓고 보면 이렇게 갈린다.
| 단계 | 사람이 정해야 하는 것 | 그게 정해져야 나오는 자동 검사 |
|---|---|---|
| 분석 | 무엇을 만들고 무엇은 안 만드는지, 완료 판정 기준 | 스코프 이탈 경고, 요구사항과 커밋 연결 |
| 설계 | 문서 규격, 불변식, 되돌릴 수 없는 결정 목록 | 섹션 누락 검사, 문서와 코드 불일치 검사 |
| 구현 | 코딩 규칙, 파일 이름 규칙, 데이터와 코드의 경계 | 린트, 하드코딩 값 검사, 이름 규칙 검사 |
| 테스트 | 무엇을 어디까지 보장할지, 언제 돌릴지 | CI 트리거, 결정론 검증, 커버리지 하한 |
내 레포는 오른쪽 칸이 꽉 차 있고 가운데 칸이 비어 있었다. 자산 파일 이름 규칙을 정한 적이 없는데 이름 규칙 검사기는 있었다. 그러니 746건이 나오는 게 당연하다. 검사기가 틀린 게 아니라, 참조할 규칙이 이 레포에 없어서 남의 규칙을 대신 참조한 거다.
한 행만 예외였다. GDD 여덟 개 섹션은 내가 실제로 정한 규격이고, 그래서 그 검사만 유일하게 이 레포를 보고 있었다. 가운데 칸이 채워진 유일한 행이 유일하게 살아 있는 검사와 정확히 겹친다. 우연이 아닐 거다.
요즘 AI한테 일을 시키는 걸 보면 이 가운데 칸이 통째로 빠져 있는 경우가 많다. 정확히 말하면 빠진 게 아니라 그것까지 넘긴 거다. "규칙도 알아서 잡아줘"라고 하면 AI는 진짜로 잡아준다. 훅 727줄이 반나절 만에 나온 것도 그래서다. 문제는 그렇게 나온 규칙이 어디에도 없던 규칙이 아니라 학습된 일반 규칙이라는 것. 즉 남의 프로젝트 규칙이다. 소문자와 밑줄로 파일 이름을 짓는 건 일반적으로 맞는 규칙이고, 유니티 레포에서만 틀린다. AI는 일반을 주고 나는 특수를 안 줬다. 746이 그 차이의 크기다.
가운데 칸은 위임이 안 되는 칸이다. 이 프로젝트가 뭘 보장해야 하고 어디까지 안 해도 되는지는 학습 데이터에 없다. 이건 AI 성능이 올라가면 해결되는 종류의 공백이 아니다.
그래서 관리자는 뭘 세야 하나
관리자로 역할이 옮겨갔다는 말은 맞다. 그런데 관리자의 일은 감시 장치를 만드는 것이 아니다. 만드는 건 AI가 더 빨리 한다. 727줄짜리 훅 세트를 나는 반나절도 안 걸려 갖췄다.
관리자의 일은 단계마다 기준을 정해두는 것, 그리고 그 기준에서 나온 장치가 최근에 무언가를 실제로 막았는지 세는 것이다. 이번에 뒤져보고 나서 처방으로 떠오른 게 넷이었다.
게이트마다 발화 기록을 남긴다. 훅이 아무 말 없이 통과시킬 때와 볼 게 없어서 통과시킬 때를 구분할 수 있어야 한다. 몇 건을 봤고 몇 건이 걸렸는지 한 줄씩 append 해두면, 그 파일이 안 자라는 게 그 자체로 신호가 된다.
발화 0회가 오래 지속되면 통과가 아니라 고장으로 읽는다. 깨끗해서 안 걸리는 경우도 물론 있다. 그런데 219 커밋 동안 0회면 깨끗한 게 아니다. "한 달 넘게 아무것도 안 잡은 검사"를 뽑아보는 게 감사의 첫 질문이 돼야 한다.
감시 대상 경로가 실재하는지를 먼저 확인한다. grep -E '^src/' 앞에 [ -d src ] || echo "WARN: src/ 없음" 한 줄만 있었으면 4개월이 아니라 첫날에 걸렸다. 경로가 없을 때 조용히 exit 0 하면 검사를 안 한 것과 통과시킨 것이 같은 출력으로 나온다. 없으면 시끄럽게 실패해야 한다.
템플릿에서 가져온 하네스는 가져온 날 재조준한다. 복사는 도입이 아니다. 남의 레이아웃을 전제로 만들어진 스크립트는 내 레포에서 문법적으로는 잘 돌면서 아무것도 안 한다. 잘 도는 게 제일 위험하다. 에러가 안 나니까.
다섯 번째 단계가 생긴 게 아니다
처음에 나는 이렇게 정리하려고 했다. 분석, 설계, 구현, 테스트 네 단계 위에 "관리"라는 다섯 번째 단계가 생겼다고. AI가 아래 넷을 하고 사람이 위에서 본다고.
레포를 뒤지고 나서는 그 그림이 틀렸다고 생각한다. 다섯 번째 단계가 생긴 게 아니라 네 단계 전부가 사람 없이도 끝까지 돌 수 있게 된 것이다. 관리는 위에 새로 얹힌 층이 아니라, 네 단계 안에 원래 있었는데 사람이 손을 움직이는 동안 자동으로 딸려오던 일이다. 코드를 직접 치면 그 코드를 읽게 된다. 안 치면 안 읽는다.
그래서 "AI가 다 해주니까 사람은 관리만 하면 된다"는 말이 위험하다. 관리는 남은 일이면서 동시에 제일 먼저 자동화하고 싶어지는 일이다. 지겹고, 반복적이고, 눈에 성과가 안 남으니까. 넘기기 딱 좋은 조건을 다 갖췄다.
내 프로젝트는 그 자동화까지 마쳤다. 훅 12개, 727줄, 에이전트 21종, 스킬 75개. 그리고 그중 감시를 맡은 넷이 4개월간 발화 0회였다. 게임은 그동안 잘 굴러갔다. 그게 제일 무섭다. 감시가 없어도 티가 안 났다는 뜻이니까.
고치기 전에 먼저 돌려봤다
아직 훅을 안 고쳤다. 고치기 전에 궁금한 게 있어서, 죽어 있던 검사 셋을 정규식만 떼어다 실제 경로에 손으로 돌려봤다. 4개월치가 한꺼번에 걸릴 줄 알았다.
하드코딩된 밸런스 숫자 검사부터. 훅에 있는 정규식 그대로 client/Assets/Scripts/ 전체에 걸었더니 1건 나왔다. 219 커밋에 1건이다. 담당자 태그 없는 TODO 검사는 7건. 이 둘은 솔직히 김이 좀 샜다. 켜뒀어도 내 판단이 달라졌을 것 같지 않다.
남은 하나에서 걸렸다. 자산 파일 이름 규칙 검사는 소문자와 밑줄만 허용한다. 이걸 client/Assets/ 에 걸었더니 이렇게 나왔다.
전체 추적 파일: 1113
이름 규칙 위반: 746
67%다. 왜냐면 유니티 쪽 관행이 PascalCase고, 이 규칙은 그걸 모르는 템플릿에서 왔기 때문이다. 경로만 남의 것이었던 게 아니라 규칙도 남의 것이었다.
그러니까 대문자 A 하나 고치고 훅을 켜면 어떻게 되냐면, 파일 하나 저장할 때마다 경고가 쏟아진다. 그리고 경고가 쏟아지면 나는 그걸 끈다. 확실하게 끈다. 이미 CI에서 한 번 그렇게 했으니까. 빨간 X가 계속 뜨니까 트리거를 수동으로 돌려놨고, 그게 3개월 뒤에 버전 문자열까지 같이 썩게 만들었다.
게이트가 죽는 방식이 두 가지라는 걸 여기서 봤다. 하나는 조용해서 죽는다. 아무것도 안 잡는데 아무 말도 안 하니까 살아 있는 줄 안다. 다른 하나는 시끄러워서 죽는다. 맞는 말을 746번 하면 사람은 그걸 끈다. 그리고 조준을 고치는 작업은 조용한 죽음을 시끄러운 죽음으로 옮기는 일이다. 그것만 해서는 아무것도 안 끝난다.
그래서 지금 하려는 순서를 바꿨다. 훅을 고치는 게 아니라 이 레포의 자산 이름 규칙이 뭔지부터 정하는 것. 그게 정해져야 검사가 뭘 잡을지가 정해지고, 그게 정해져야 켤 수 있다. 남의 하네스를 가져다 쓸 때 진짜로 이식해야 하는 건 스크립트가 아니라 그 스크립트가 전제한 규칙이었다.
저 727줄을 만든 날의 나는 관리를 시작한 게 아니라 관리를 그만뒀다. 그날 내가 실제로 한 일은 파일 열두 개를 복사한 거였고, 그걸 관리 체계라고 부르는 순간 그 위를 다시 볼 이유가 없어졌다. AI가 네 단계를 다 밟아주는 판에서 사람 몫으로 남는 게 그 "다시 보는 일" 하나인데, 그것마저 넘길 수 있게 만들어놓고 넘긴 줄도 몰랐다.
1이랑 7은 별거 아니었다. 746이 진짜였다.
댓글
댓글 쓰기