유니티 넉 달과 로블록스 이틀, 무엇이 달랐을까?

이틀 만에 로블록스 게임을 하나 만들었다. Lua 43개 파일에 25,220줄, 문서 11개, 커밋 11개. 만들라고 시키기 전에 공부부터 시킨 이야기는 따로 적었다.

그 글을 쓰고 나서 기분이 좋았다. 순서를 잘 잡았더니 이틀 만에 나왔다는 이야기였으니까.

며칠 뒤에 다른 저장소를 열어볼 일이 있었다. 유니티로 만들던 모바일 게임인데, 3월 말에 시작해서 7월 말이 마지막 커밋이다. 넉 달이다. 커밋은 219개.

같은 사람이 같은 도구로 작업했다. 한쪽은 이틀, 한쪽은 넉 달.

그 차이가 어디서 났는지 보려고 커밋 로그를 시간순으로 훑었다. 보고 나서 내가 이틀 만에 만들었다고 생각한 게 틀렸다는 걸 알았다.

월별로 세보니 이상했다

먼저 커밋을 월별로 세봤다.

2026년 3월에 2개, 4월에 163개, 5월에 40개, 6월과 7월에 각각 7개다. 합쳐서 219개다.

4월에 163개다. 전체의 74%가 한 달에 몰려 있다. 그리고 5월에 40개로 떨어지고 6월엔 7개가 된다.

처음엔 그냥 프로젝트에 시들해진 곡선이라고 생각했다. 대부분의 개인 프로젝트가 이렇게 생겼으니까.

그런데 커밋 종류를 세어보니 다른 게 보였다.

feat 이 101개로 제일 많고 fix 가 51개다. chore 36개, docs 22개, refactor 4개, 기타 5개가 뒤를 잇는다.

fix가 51개다. 전체의 23%. 그리고 이 51개가 어디에 몰려 있는지가 문제였다.

4월 첫 주에 무슨 일이 있었나

4월 4일부터 7일까지 나흘간의 커밋을 그대로 옮긴다.

04-07 feat(assets): BoomBlitz 레퍼런스 기반 에셋 구조 전면 재설계
04-06 fix: StageSelectController long→int 캐스트 오류 + deprecated ScaleMode 수정
04-06 feat(ui): UI 스프라이트 에셋 29종 생성 + 전체 화면에 적용
04-06 feat(ui): 가챠/스테이지/영웅목록 화면 비주얼 대폭 개선
04-06 fix(ui): 화면 배경 투명화 + 전투 복귀/보상 수정 + 데이터 바인딩 보강
04-06 fix(assets): 프리팹을 Resources/로 이동하여 런타임 로드 복구 + 목업 코드 정리
04-06 chore(env): Unity 에디터 버전을 6000.0.72f1로 다운그레이드
04-06 fix(packages): Unity 6 호환 안 되는 패키지 제거 + Animation 모듈 추가
04-05 feat(town): 아이소메트릭 마을 시스템 구현 및 UI 비주얼 개편
04-05 fix(sprites): HeroManager heroId 양방향 폴백 + 전투 HUD 이미지 로드 수정
04-05 fix(sprites): heroId 접두사 불일치 수정 — 영웅 이미지 로드 복구
04-05 fix(ui): Settings/Legal 컨트롤러 재구현 + ScreenManager null 방어 강화
04-05 chore(editor): 에디터 메뉴 17개 → 5개로 정리
04-05 fix(editor): 에디터 메뉴명 통일 (Master Heroes → MasterHeroes)
04-05 refactor(ui): OnGUI/목업 코드 전면 제거 + 프리팹 기반 아키텍처 전환
04-04 fix: ScreenManager에 화면별 배경 이미지 적용 + 메모리 업데이트
04-04 fix: 원본 SO heroId 접두사 수정 (에디터 AssetDatabase 로드 경로)
04-04 fix: 이미지 로드 실패 근본 해결 — Texture2D→Sprite 폴백
04-04 fix: OnGUI 로비를 메인 화면으로 전환, 씬 전환 기반 플로우
04-04 fix: SaveAll/RegenerateStamina null 체크 추가

스무 개 중 열두 개가 fix다.

그리고 내용을 보면 종류가 하나다. 앞에서 만든 게 안 돌아서 고치는 것.

heroId 접두사 불일치가 이틀에 걸쳐 세 번 나온다. 4월 4일에 "원본 SO heroId 접두사 수정"을 하고, 4월 5일에 "heroId 접두사 불일치 수정 — 영웅 이미지 로드 복구"를 하고, 같은 날 "HeroManager heroId 양방향 폴백"을 넣는다. 세 번째는 아예 고치기를 포기하고 양쪽 다 받아주는 폴백을 깐 것이다.

OnGUI도 그렇다. 4월 4일에 "OnGUI 로비를 메인 화면으로 전환"하고, 다음 날 "OnGUI/목업 코드 전면 제거"를 한다. 하루 만에 만든 걸 지웠다.

fix: 이미지 로드 실패 근본 해결이라는 커밋도 있다. "근본 해결"이라고 적어놓고 다음 날 같은 계열 버그를 두 개 더 고쳤다.

이게 무슨 상태였는지 지금은 안다. 나는 그때 결과물을 검사하지 않고 다음 지시를 넣고 있었다.

지시하고, 받고, 다시 지시했다

당시 내 작업 방식을 복기하면 이랬다.

"영웅 목록 화면 만들어줘"라고 시킨다. 코드가 나온다. 유니티에서 돌려본다. 이미지가 안 뜬다. "이미지가 안 뜬다"고 말한다. 고친 코드가 나온다. 돌려본다. 다른 화면에서 같은 증상이 난다. 그것도 말한다.

이 루프가 4월 내내 돌았다. 163개 커밋이 그 흔적이다.

문제는 이 루프에서 내가 하는 일이 증상 전달뿐이었다는 것이다. "안 된다"고만 말하고 왜 안 되는지는 상대가 알아내게 뒀다. 그래서 상대는 매번 그 자리에서 보이는 것만 고쳤다. heroId 접두사가 세 번 나온 이유가 그거다. 첫 번째와 두 번째 수정은 각각 자기가 본 자리에서는 맞았다. 전체를 본 사람이 없었을 뿐이다.

전체를 봐야 하는 사람은 나였다.

4월 19일에 전부 지웠다

그 루프가 열흘쯤 더 돌았다. 그리고 4월 17일부터 커밋의 종류가 갑자기 바뀐다.

04-17 docs: economy GDD 완성 (Design Order #2, 11섹션 + 35 AC + 25 Knobs)
04-17 docs: time-system GDD 완성 (Design Order #3, Foundation/MVP)
04-17 docs: hero-system GDD 완성 (Design Order #5)
04-17 docs: equipment GDD 완성 (Design Order #6) + 주문서 tier 시스템
04-19 docs: MVP 17/17 GDDs 완성 + Technical Setup 진입 + Master Architecture v1.0
04-19 docs(foundation): 아키텍처 결정서 6종 확정 및 구현 로드맵 추가
04-19 chore(client)!: 클라이언트 전체 소스 코드 및 에셋 삭제
04-19 refactor(client)!: Unity 6.0 LTS mono-repo scaffold + Economy Story 001-007 구현

이틀 동안 게임 설계서 17개와 아키텍처 결정서 6개를 썼다. 그리고 클라이언트 소스를 통째로 지웠다.

느낌표가 붙은 커밋 두 개가 그 지점이다. chore(client)!: 클라이언트 전체 소스 코드 및 에셋 삭제, 그리고 바로 다음 refactor(client)!: Unity 6.0 LTS mono-repo scaffold.

4월 4일부터 16일까지 만든 걸 다 버리고 처음부터 다시 시작했다.

이게 그 넉 달의 진짜 분기점이다. 나는 이 글을 쓰기 시작할 때 "6월에 규칙을 적었다"가 핵심인 줄 알았는데, 커밋을 시간순으로 보니 아니었다. 6월은 결과였고 시작은 4월 19일이었다.

그날 내가 한 판단은 단순했던 것 같다. 고치는 속도보다 어긋나는 속도가 빨랐다. heroId 접두사를 세 번 고치고 폴백까지 깔았는데도 계속 나온다면, 그건 개별 버그가 아니라 애초에 규칙을 정해두지 않아서 생기는 것이다. 규칙이 없으면 매번 그 자리에서 그럴듯한 걸 만들고, 그럴듯한 것들끼리 안 맞는다.

그래서 지우고, 규칙부터 썼다.

여기서 중요한 건 지운 게 아니라 지우기 전에 이틀 동안 문서를 썼다는 순서다. 그냥 지우고 다시 만들었으면 같은 일이 반복됐을 것이다.

5월엔 번호를 붙여서 시켰다

5월 커밋 40개는 4월과 생김새가 완전히 다르다.

05-03 feat(app-flow): Step 1 — Splash + Lobby + 메뉴 placeholder scene scaffolding
05-03 feat(app-flow): Step 2 — Battle scene 분리 + Result overlay (보상/LOBBY 복귀)
05-03 feat(app-flow): Step 3 — Lobby/Town 본격 구성 (HUD 6자원 + 8건물 4×2 그리드)
05-04 feat(app-flow): Step 8 — Stage Campaign 다층 진척 (4 챕터 × 15 stage)
05-06 feat(battle): Step 38 — HeroPrototypeDefinition NormalSkillEffects 데이터 wire
05-07 feat(battle): Step 50 — Battle UI 상태효과 시각화 (10 슬롯 × 3 badge)
05-11 feat(hero): Step 53 — Hero Breakthrough Tier 4+ Iron 해금

Step 1부터 Step 53까지 번호가 붙어 있다.

그리고 사이사이에 이런 게 끼어 있다.

05-06 chore(session): Step 48 commit hash f5e4c12 기록
05-07 chore(session): Step 50 commit hash 3cefa6e 기록
05-11 chore(session): Step 53 commit hash 003ba04 기록

각 단계가 끝날 때마다 커밋 해시를 기록해뒀다. 세션이 끊겨도 어디까지 갔는지 남게.

5월 40개 커밋 중 fix는 3개뿐이다. 4월 첫 주 나흘에 열두 개였던 것과 비교하면 차이가 크다.

같은 도구, 같은 사람, 같은 게임이다. 바뀐 건 하나다. 무엇을 만들지 먼저 정하고 번호를 붙였다.

Step을 붙인다는 건 지시를 자르는 것이다. "영웅 목록 화면 만들어줘"가 아니라 "Step 38: HeroPrototypeDefinition에 NormalSkillEffects 데이터를 연결한다"가 된다. 범위가 명시돼 있으니 돌아온 걸 볼 때 볼 자리도 정해진다. 어긋났는지 안 어긋났는지 내가 판정할 수 있다.

4월엔 그 판정을 못 했다. 범위가 없으니 "이게 맞나"를 물어볼 기준이 없었고, 그래서 돌려보고 안 되면 그때 알았다.

여기서 4월과 6월의 차이가 나온다.

6월엔 커밋이 7개였고, 그중 절반이 코드가 아니었다

6월 커밋 7개 중 다섯 개를 옮긴다.

06-14 feat(agents): 코드 작성 에이전트 5종에 Karpathy C1~C4 코딩 행동 기준선 적용
06-14 chore(harness): CCGS 업스트림 스킬 sync 감사 — 반영 0건 기록
06-09 chore(harness): Surgical Changes 작업원칙 신설 — Karpathy 누락 축 1개 이식
06-05 chore(harness): 착수 전 계획 확인 룰 추가 — 규모(T0~T3)에 비례
06-05 chore(harness): 완료 게이트를 트리아지에 결속 — T0/T1 over-process 제거

게임 코드가 하나도 없다. 전부 일을 어떻게 시킬지에 대한 규칙이다.

• 착수 전에 계획을 확인하게 한다. 단, 일의 규모에 비례해서. 한 줄 고치는 데 계획서를 받지는 않는다.
• 완료 판정을 규모에 묶는다. 작은 일에 전체 검수를 돌리지 않는다.
• 변경은 최소 범위로 한다(Surgical Changes). 시킨 것만 고치고 주변을 건드리지 않는다.

이 세 줄을 지금 읽으면 새로울 게 없다. 일 시키는 사람이면 다 아는 이야기다.

그런데 이걸 문서로 박아 넣은 날짜가 6월 5일이다. 4월 19일에 지우고 다시 시작한 지 47일 뒤다.

이 47일이 이상하다. 나는 4월 19일에 이미 이 규칙대로 일하고 있었다. 설계서를 먼저 쓰고, 범위를 잘라 번호를 붙이고, 단계마다 확인했다. 5월 40개 커밋이 그 증거고 fix 3개가 그 결과다.

하고 있으면서 말로는 못 하고 있었다.

47일이 걸린 건 그걸 문장으로 바꾸는 데 걸린 시간이다. 몸으로 아는 것과 남에게 넘길 수 있게 적는 것 사이에 그만큼이 있었다.

적고 나니 세 줄이었다.

이건 신입에게 일 시키는 이야기와 같은 모양이다

여기까지 정리하고 나서 이상한 기분이 들었다.

"착수 전에 계획을 확인한다", "일의 크기에 맞춰 절차를 조절한다", "시킨 것만 고치고 주변은 건드리지 않는다."

이건 내가 AI에게 배운 게 아니다. 사람 신입에게 일을 시켜보면서 배운 것이다.

신입에게 "이 화면 만들어줘"라고만 던지면 어떻게 되는지 나는 안다. 열심히 만들어 오는데 다른 화면과 규칙이 안 맞는다. 그래서 착수 전에 어떻게 만들 건지 먼저 들어보게 된다. 반대로 오타 하나 고치는 데 설계 리뷰를 시키면 그것도 안 된다. 그래서 일의 크기를 보고 절차를 조절하게 된다. 그리고 한 군데 고치라고 했는데 옆에까지 손대서 다른 게 깨지는 걸 몇 번 겪으면, 범위를 명시해서 주게 된다.

이 세 가지를 나는 사람과 일해보면서 배웠고, 그걸 6월에 에이전트용 문서로 옮겨 적은 것이다.

옮겨 적는 데 68일이 걸린 이유도 이제 짐작이 간다. 상대가 사람이 아니면 신호가 안 온다. 신입은 지시가 모호하면 되묻거나, 표정이 굳거나, 엉뚱한 걸 만들어 와서 당황한다. 에이전트는 그냥 만들어 온다. 만들어 온 게 틀려도 자신 있게 만들어 온다. 그래서 내 지시가 모호했다는 신호가 나에게 도달하지 않는다.

fix: 이미지 로드 실패 근본 해결이라고 커밋 메시지에 적힌 그 자신감이 그 신호 부재의 증거다.

그래서 그 넉 달은 게임을 만든 시간이 아니었다

숫자를 하나 더 보자. 219개 커밋의 총 변경량이다.

변경 파일 7,917개
추가      761,819줄
삭제      489,421줄

삭제가 추가의 64%다.

이 숫자는 조심해서 읽어야 한다. 유니티 프로젝트라 에셋 메타파일이나 자동 생성 파일이 대량으로 섞여 있고, 그걸 걸러내지 않은 수치다. 그리고 삭제분의 상당량은 4월 19일 그 한 커밋이다. 버그 때문에 조금씩 지운 게 아니라 한 번에 통째로 지웠다.

다만 자체 코드만 따로 세면 288개 파일에 46,683줄이다. 넉 달 동안 76만 줄을 넣고 49만 줄을 뺐는데 남은 게 4만 7천 줄이다.

그러니까 그 넉 달의 산출물은 게임이 아니었다. 게임도 나오긴 했지만, 진짜 산출물은 일을 시키는 순서였다.

그 순서를 정리하면 이렇게 된다.

4월 초에는 시키고 받고 안 되면 말하고 다시 시켰다. fix 가 도배된 구간이다. 4월 17일부터 19일 사이에 멈추고 설계서 17개와 아키텍처 결정서 6개를 썼다. 그리고 소스를 전부 지웠다. 5월에는 Step 1부터 53까지 범위를 잘라 번호를 붙이고 단계마다 해시를 남겼다. fix 가 3개로 줄었다. 6월에는 그 방식을 프로젝트 밖으로 꺼내 규칙 문서로 만들었다.

4월 19일에 한 일을 6월에 문장으로 적은 것이다. 실행이 먼저였고 규칙화가 나중이었다.

그리고 8월에 로블록스 게임을 이틀 만에 만들었다. 그때 내가 한 건 이 표의 재현이다. 만들라고 하기 전에 공부부터 시킨 것이 4월 17~19일에 해당하고, 그다음 순서대로 시킨 것이 5월에 해당한다. 다른 점은 하나뿐이다. 이번엔 지울 필요가 없었다.

이틀이 아니었다. 넉 달 하고 이틀이었다.

PwC가 센 10억 건의 공고

이 지점에서 최근에 본 통계가 걸렸다.

PwC가 2026년 6월에 낸 자료다. 27개국의 채용공고 10억 건 이상을 분석했다. 확인된 것만 옮긴다.

AI 노출도가 높은 신입 직무가 판단력이나 리더십 같은 전통적 시니어 역량을 요구할 확률이 일반 신입 직무의 7배였다. 2019년 대비 AI 노출 신입 직무는 35% 늘었는데, 그 외 신입 직무는 10% 줄었다.

스탠퍼드 쪽 연구도 있다. 22~25세 연령대에서 AI 노출도가 높은 직무(소프트웨어 개발자, 고객 응대 포함)의 고용이 2022년 말부터 2025년 중반까지 약 6% 감소했다. 같은 직무의 더 나이 많은 인력은 같은 기간 6~9% 증가했다.

ICIMS 조사에서는 신입 구직자 중 "매우 자신 있다"고 답한 비율이 19%, "자신감이 낮거나 없다"가 29%였다.

첫 번째 줄이 제일 이상하다. 신입 직무가 시니어 역량을 요구할 확률이 7배.

판단력을 갖춘 신입을 뽑겠다는 것이다.

판단력은 첫 칸을 밟아야 생긴다

내 넉 달로 돌아온다.

6월에 내가 적은 세 줄 — 착수 전 계획 확인, 규모에 비례한 절차, 최소 범위 변경 — 은 정확히 "판단력"에 해당하는 것이다. 무엇을 시킬지, 얼마나 시킬지, 돌아온 걸 어떻게 볼지.

나는 그걸 4월의 163개 커밋을 치르고 얻었다. heroId 접두사를 세 번 고치고, OnGUI를 만들었다 하루 만에 지우고, "근본 해결"이라고 적은 다음 날 같은 버그를 또 만나고 나서 얻었다.

그 과정이 첫 칸이다.

그런데 지금 채용시장은 첫 칸에 서는 사람에게 그 칸을 밟아본 결과를 요구하고 있다. AI 노출 신입 직무가 시니어 역량을 요구할 확률이 7배라는 건 그런 뜻이다. 그리고 그런 요구를 하지 않는 나머지 신입 직무는 2019년 대비 10% 줄었다.

밟을 칸은 줄고, 남은 칸은 밟아본 사람을 찾는다.

이걸 조금 다르게 말할 수도 있다. AI에게 일을 시키려면 돌아온 결과를 검증할 줄 알아야 한다. 검증 기준은 그 일을 직접 해본 사람에게 생긴다. 그런데 그 "직접 해보는 일"을 지금 AI가 하고 있다.

아이에게서 같은 걸 봤다

이 구조를 나는 다른 데서 먼저 봤다.

아이와 AI로 게임을 만들면서 관찰한 기록이 있다. 그 글의 결론은 아이가 번호로 고른 건 아무것도 안 남았고 자기 문장으로 말한 건 남았다는 것이었다.

AI가 선택지를 1번부터 5번까지 제시하면 아이는 번호를 고른다. 빠르고 편하다. 결과물도 나온다. 그런데 왜 그걸 골랐는지 아이가 설명하지 못한다. 다음에 비슷한 상황이 오면 또 번호를 골라야 한다.

반대로 아이가 자기 문장으로 "이렇게 됐으면 좋겠어"라고 말한 것은, 결과가 어긋났을 때 아이가 어긋난 걸 알아챘다. 자기가 원한 걸 알고 있었으니까.

번호를 고르는 것과 문장을 말하는 것의 차이가, 4월의 나와 6월의 나의 차이와 같다.

4월의 나는 "안 된다"고만 말했다. 그건 번호 고르기에 가깝다. 6월의 나는 무엇을 어떻게 해야 하는지를 문서로 적었다. 그건 문장이다.

그런데 여기서 단정하면 안 되는 것

이 글을 여기서 끝내면 깔끔한데, 그러면 두 군데가 틀린다.

6월에 커밋이 7개로 준 게 학습 효과 때문이라고는 확인하지 못했다. 프로젝트에 쓰는 시간 자체가 줄었을 가능성이 크다. 4월엔 거의 매일 붙어 있었고 6월엔 그러지 않았다. 커밋 감소의 얼마가 "숙련"이고 얼마가 "관심 감소"인지 나는 구분할 자료가 없다. 이걸 성장 곡선으로 읽고 싶은 유혹이 있지만, 지금 있는 데이터로는 그렇게 못 읽는다.

내가 확실히 말할 수 있는 건 6월 커밋의 내용뿐이다. 그 7개 중 다섯 개가 코드가 아니라 작업 규칙이었다는 것. 시간을 덜 썼든 아니든, 그 시간에 내가 만든 건 규칙이었다.

삭제된 489,421줄이 전부 "AI가 잘못 만든 것"도 아니다. 유니티 자동 생성 파일, 에셋 교체, 패키지 정리가 대량으로 섞여 있다. 실제로 커밋 목록에도 "이전 아트 에셋 및 스타일 앵커 삭제" 같은 게 있다. 그건 잘못 만들어서 지운 게 아니라 방향을 바꿔서 지운 것이다.

채용 통계는 미국 중심이라 내 경험과 직접 연결되지도 않는다. PwC 자료는 27개국이지만 스탠퍼드 연구는 미국 데이터다. 한국 신입 개발자 시장이 같은 모양인지 나는 확인하지 않았다. 그리고 내 넉 달은 개인 프로젝트고 채용과 아무 관계가 없다. 두 이야기를 한 글에 놓은 건 인과를 주장하려는 게 아니라 구조가 닮았다고 말하려는 것이다.

덧붙이면 반대 방향 자료도 있다. 한 CEO 조사에서는 응답자의 67%가 2026년에 신입 채용이 늘어날 것이라고 답했다. 이게 낙관인지 예측인지는 시간이 지나야 안다.

아직 모르는 것

그래서 이 글은 답이 아니라 질문으로 끝난다.

나는 4월을 치렀기 때문에 6월에 규칙을 적을 수 있었고, 그 규칙이 있어서 8월에 이틀 만에 게임을 만들었다. 순서가 이렇다.

4월을 건너뛴 사람은 6월에 무엇을 적을 수 있나.

이건 수사적 질문이 아니다. 나는 정말 모르겠다. 몇 가지 답이 가능해 보인다. 어쩌면 4월 없이도 규칙만 배우면 되는 것일 수도 있다. 이 글에 적은 세 줄을 읽고 그대로 적용하면 되는 것 아니냐고 하면, 반박하기 어렵다.

그런데 나는 그 세 줄을 4월 전에 이미 알고 있었다. 사람 신입에게 일을 시키면서 배웠으니까. 알고 있었는데도 보름 동안 적용하지 못했다. 4월 4일부터 19일까지, 알고 있는 걸 안 쓰면서 fix를 쌓았다. 상대가 사람이 아니어서 신호가 안 왔기 때문이다.

규칙을 아는 것과 그 규칙이 필요한 상황을 알아보는 것은 다르다. 후자는 겪어야 생기는 것 같다. 최소한 나는 그렇게 생겼다.

지금 확실한 건 하나다. 나는 그 넉 달을 이미 썼다. 그 시간이 없었으면 이틀은 없었다.

그리고 그 넉 달을 쓸 자리가 지금 줄고 있다.