AI가 코드를 만드는 시대일수록, 개발자는 문제·구조·검증·성능·완성도를 소유해야 한다.

아래 일곱 문장에 모두 답할 수 있다면, AI를 사용해도 프로젝트의 통제권은 개발자에게 있다.

• 문제: 지금 해결하는 문제가 한 문장으로 정의되어 있는가?
• 완료 조건: “작동한다”가 아니라 검증 가능한 종료 조건이 있는가?
• 경계: AI가 수정해도 되는 파일과 건드리면 안 되는 영역이 구분되어 있는가?
• 수명주기: 객체·이벤트·비동기 작업·에셋의 생성과 종료 책임자가 정해져 있는가?
• 검증: 생성된 코드의 diff를 읽고 테스트했는가?
• 측정: 성능 문제를 추측하지 않고 실제 빌드에서 측정했는가?
• 플레이: 기술적으로 정상인 것과 실제로 재미있는 것을 구분해 확인했는가?

AI 사용의 핵심:
더 많이 생성하기가 아니라,
더 작게 맡기고 더 정확하게 검증하기

flowchart LR
    A["문제 정의<br/>요구사항·제약·완료 조건"] --> B["구조 설계<br/>경계·소유권·데이터 흐름"]
    B --> C["AI 위임<br/>작은 범위·명확한 지시"]
    C --> D["검증<br/>Diff·테스트·정적 분석"]
    D --> E["측정<br/>Profiler·메모리·실기기"]
    E --> F["플레이 판단<br/>손맛·피드백·이해 가능성"]
    F --> G["문서화<br/>결정·한계·다음 실험"]
    G --> A

    classDef human fill:#0f172a,stroke:#67e8f9,color:#fff,stroke-width:2px;
    classDef ai fill:#211a38,stroke:#a78bfa,color:#fff,stroke-width:2px;
    class A,B,D,E,F,G human;
    class C ai;

AI는 구현 루프 안에 들어오지만, 루프의 시작과 종료 판단은 사람이 맡는다.

AI의 진입은 한 번의 사건이 아니라 세 단계로 진행되었다.

자동완성 시대        : 사람이 쓰고 AI가 이어 쓴다
대화형 AI 시대       : 사람이 묻고 AI가 초안을 만든다
에이전트 시대        : 사람이 작업을 정의하고 AI가 실행한다
현재 개발자의 역할   : 방향·경계·검증·최종 품질을 책임진다

flowchart TD
    Q{"결과가 틀렸을 때<br/>피해가 큰가?"}
    Q -->|낮음| A["AI에 초안 위임"]
    Q -->|높음| B{"자동으로 검증할 수 있는가?"}
    B -->|예| C["AI 위임 + 테스트/검증 필수"]
    B -->|아니오| D["사람 주도 + AI는 대안 제시"]
    A --> E["Diff 확인"]
    C --> E
    D --> E

나쁜 요청:

인벤토리 시스템 만들어줘.

좋은 작업 명세:

슬롯형 인벤토리다.
같은 소비 아이템은 최대 99개까지 중첩한다.
장비는 중첩되지 않는다.
저장 데이터에 UnityEngine.Object 참조를 넣지 않는다.
핵심 규칙은 MonoBehaviour 없이 Edit Mode 테스트가 가능해야 한다.
기존 저장 데이터 버전 2를 계속 읽을 수 있어야 한다.

좋은 개발자는 구현 전에 다음을 답할 수 있다.

• 입력과 출력은 무엇인가?
• 데이터의 단일 소유자는 누구인가?
• 생성·활성화·비활성화·파괴 시점은 언제인가?
• 실패하면 어떤 상태로 돌아가는가?
• 씬 전환과 앱 중단을 견딜 수 있는가?
• 저장하거나 네트워크로 전달해야 하는가?
• 어떤 테스트가 통과하면 완료인가?

피해야 할 구조:

PlayerController
├─ 입력
├─ 이동
├─ 애니메이션
├─ 전투
├─ 피격
├─ 사운드
├─ 저장
├─ UI
└─ 서버 통신

권장 방향:

Game.Domain
├─ Combat
├─ Inventory
├─ Progression
└─ Rules

Game.Unity
├─ PlayerView
├─ InputAdapter
├─ AnimationAdapter
└─ SceneComposition

Game.Infrastructure
├─ Save
├─ Network
├─ Addressables
├─ Analytics
└─ Platform

flowchart LR
    I["Input System"] --> C["Command"]
    C --> D["Domain Logic<br/>일반 C#"]
    D --> R["Result / Event"]
    R --> V["Unity View<br/>MonoBehaviour"]
    D --> S["Save / Network Adapter"]

핵심 규칙은 가능한 한 일반 C#으로, MonoBehaviour는 Unity와 연결하는 어댑터로 사용한다.

flowchart LR
    A["재현 조건 고정"] --> B["관찰 가능한 증거 추가"]
    B --> C["가설 하나 선택"]
    C --> D["변수 하나만 변경"]
    D --> E["결과 비교"]
    E --> F["회귀 테스트 추가"]
    F -->|미해결| C

기록할 것:

• 대상 기기와 빌드 설정
• 씬 진입 순서
• 네트워크 상태
• 저장 데이터 버전
• 프레임레이트와 시간 배율
• 객체 인스턴스 ID
• 이벤트 구독 횟수
• 비동기 작업의 시작·취소·완료 시점

수정 후에는 테스트·Assert·에디터 검사기·재현 씬 중 하나를 남긴다.

프레임 예산:

이 시간은 스크립트만의 예산이 아니라 렌더링·물리·애니메이션·UI·오디오·드라이버 작업을 모두 포함한다.

올바른 최적화:
측정 → 병목 확인 → 가설 → 작은 수정 → 재측정

잘못된 최적화:
일단 풀링 → 일단 struct → 일단 Jobs → 일단 Burst

반드시 볼 항목:

• CPU Main Thread / Render Thread
• GC.Alloc과 GC 스파이크
• Physics와 Animation
• UI Layout·Canvas Rebuild
• 로딩과 셰이더 컴파일 스파이크
• 드로우콜·배치·오버드로
• 메모리 증가 추세
• 실제 대상 기기의 온도·배터리·프레임 유지

Jobs와 Burst는 프로파일링으로 CPU 병목이 확인되고, 작업을 독립적인 데이터 처리 단위로 나눌 수 있을 때 고려한다.

다음 질문에 답이 없으면 언젠가 누적 버그가 생긴다.

• 누가 만들고 누가 파괴하는가?
• 씬에 종속되는가, 앱 전체에서 유지되는가?
• 이벤트는 어디서 구독하고 어디서 해제하는가?
• 비동기 작업은 오브젝트가 사라질 때 취소되는가?
• 풀로 반환될 때 어떤 상태를 초기화하는가?
• Addressables 핸들은 누가 보관하고 해제하는가?
• 정적 필드는 플레이 재진입과 Domain Reload에서 안전한가?

stateDiagram-v2
    [*] --> Created
    Created --> Enabled: Awake / OnEnable
    Enabled --> Running: Start / Update
    Running --> Disabled: OnDisable
    Disabled --> Enabled: 재활성화
    Disabled --> Destroyed: OnDestroy
    Running --> Destroyed: 씬 종료 / Destroy
    Destroyed --> [*]

비동기는 “시작”보다 “취소와 무효화”를 먼저 설계한다.

Edit Mode 테스트에 적합

• 데미지와 스탯 계산
• 인벤토리와 경제 규칙
• 경험치 곡선
• 퀘스트 조건
• 확률·드롭 테이블
• 세이브 데이터 마이그레이션
• 쿨다운과 상태 전이

Play Mode 테스트에 적합

• 씬 로딩
• 프리팹·컴포넌트 연결
• 물리 충돌
• 애니메이션 상태
• Addressables 로딩과 해제
• 풀링 객체 재사용
• UI 상호작용

테스트의 목적은 모든 플레이를 자동화하는 것이 아니라, AI와 사람이 반복해서 수정해도 핵심 규칙이 깨지지 않게 만드는 것이다.

"공격이 답답하다"
→ 입력 버퍼가 없는가?
→ 공격 후딜 중 다음 입력을 버리는가?
→ 히트 프레임과 이펙트가 어긋나는가?
→ 카메라·사운드·히트스톱 피드백이 약한가?
→ 100~150ms 버퍼 등 가설을 세우고 비교한다.

게임 프로그래머는 감상을 구현 가능한 변수로 바꿀 수 있어야 한다.

• 값 타입·참조 타입·boxing
• class와 struct의 선택 기준
• delegate·event·Action·Func
• interface·추상 클래스·컴포지션
• 제네릭과 컬렉션
• LINQ·closure·할당 비용
• 예외와 IDisposable
• Task·async/await·CancellationToken
• GC와 메모리 할당
• 직렬화용 데이터 구조
• 스레드 안전성과 공유 상태

• GameObject·Component·Prefab
• ScriptableObject의 데이터와 런타임 상태 구분
• Unity 직렬화
• Awake·OnEnable·Start·OnDisable·OnDestroy
• Update·FixedUpdate·LateUpdate
• Input System
• 물리와 Animator
• UGUI 또는 UI Toolkit
• 씬 전환과 DontDestroyOnLoad
• Addressables
• 플랫폼별 빌드 차이

• Git·브랜치·PR·코드 리뷰
• 빌드와 테스트 자동화
• 구조화된 로그와 크래시 분석
• 저장 버전과 마이그레이션
• 현지화
• 분석 이벤트
• 에셋·패치·카탈로그 관리
• Android/iOS 실기기 검증
• 장애 재현과 롤백

flowchart TD
    A["20분 직접 설계"] --> B["AI에게 비판만 요청"]
    B --> C["작은 범위 구현 위임"]
    C --> D["Diff를 줄 단위로 검토"]
    D --> E["테스트·빌드·Profiler"]
    E --> F["AI 없이 구조 설명"]
    F -->|설명 불가| A
    F -->|설명 가능| G["결정 기록"]

이 설계에서 다음 위험을 찾아라.
- 객체 수명과 이벤트 누적
- 비동기 취소 누락
- 반복 프레임의 메모리 할당
- 저장 데이터 호환성
- 테스트하기 어려운 결합
코드는 작성하지 말고 문제와 대안만 제시하라.

[목표]
적 투사체를 오브젝트 풀 방식으로 변경한다.

[문제]
Instantiate/Destroy 구간에서 GC와 프레임 스파이크가 관찰된다.

[제약]
- 기존 SerializeField 이름을 바꾸지 않는다.
- 외부 패키지를 추가하지 않는다.
- Unity 6에서 동작해야 한다.
- Projectile 외 공개 API는 변경하지 않는다.

[변경 가능 범위]
- Assets/Game/Combat/Projectile
- Assets/Tests/Combat

[완료 조건]
- 동시에 300개 투사체를 처리한다.
- 재사용 시 Rigidbody, TrailRenderer, ParticleSystem,
  피격 대상 목록과 이벤트 상태가 초기화된다.
- 씬 전환 시 남은 투사체와 비동기 작업이 정리된다.

[성능 조건]
- 투사체 대여/반환 경로의 GC.Alloc이 0이어야 한다.

[테스트]
- 동일 인스턴스를 20회 대여/반환해도
  이벤트와 피격 데이터가 누적되지 않는다.

[결과 보고]
- 수정 파일
- 설계 결정
- 잠재적 위험
- 검증 방법

• 요청하지 않은 파일을 수정하지 않았는가?
• public API 또는 직렬화 필드가 불필요하게 바뀌지 않았는가?
• Update 등 반복 경로에 새 할당이 생기지 않았는가?
• 이벤트 구독과 해제가 짝을 이루는가?
• 비동기 작업의 취소와 완료 후 유효성 검사가 있는가?
• 예외를 삼키거나 로그만 남기고 잘못된 상태를 계속 사용하지 않는가?
• 테스트가 구현 세부가 아니라 요구사항을 검증하는가?
• 실패 경로와 재진입을 검사했는가?

새 프로젝트를 계속 늘리기보다, 하나의 작은 프로젝트를 프로덕션 수준으로 다듬는다.

오늘 변경한 것:
관찰한 문제:
확인한 원인:
다음에 검증할 것:

• 튜토리얼을 보는 것만으로 학습을 끝내기
• AI가 만든 코드를 읽지 않고 붙여 넣기
• 컴파일 성공을 기능 완료로 간주하기
• 성능을 측정하기 전에 최적화 기법부터 적용하기
• 모든 시스템을 싱글턴·이벤트 버스·DI로 통일하기
• 작은 프로토타입만 만들고 저장·옵션·빌드·테스트를 생략하기
• ECS·MCP·Agent 같은 기술 이름 자체를 실력으로 착각하기
• 베타 도구를 백업 없이 핵심 프로젝트에 적용하기

1. AI 코딩 도구는 자동완성에서 에이전트 실행으로 이동했다.
   현재 도구는 파일 수정·명령 실행·테스트·PR 흐름까지 담당한다.

2. Unity 안에서도 프로젝트 문맥을 읽는 AI가 현실화됐다.
   Unity AI 오픈 베타는 씬 그래프·GameObject·컴포넌트·패키지·대상 플랫폼을 문맥으로 사용한다.

3. AI가 만든 코드는 반드시 사람이 검토하고 테스트해야 한다.
   GitHub 공식 책임 있는 사용 지침도 생성 코드를 주의 깊게 검토하고 테스트하라고 명시한다.

4. Profiler는 에디터 수치만 보는 도구가 아니다.
   연결된 대상 기기와 릴리스 플랫폼에서 데이터를 수집할 수 있다.

5. Jobs/Burst는 기본 정답이 아니다.
   CPU 중심 병목을 데이터 단위로 분리할 수 있을 때 강력하며, 먼저 측정해야 한다.

6. Addressables는 단순 비동기 로더가 아니다.
   주소·카탈로그·위치·의존성·다운로드와 핸들 해제를 함께 관리한다.

1. 사람이 문제와 완료 조건을 정의한다.
2. 시스템을 작게 나누고 소유권을 명시한다.
3. AI에는 제한된 범위만 위임한다.
4. 생성된 Diff를 이해하지 못하면 병합하지 않는다.
5. 테스트와 실제 실행으로 검증한다.
6. 성능은 실제 대상 기기에서 측정한다.
7. 재미와 사용성의 최종 판단은 플레이로 내린다.
8. 결정과 실패를 기록해 다음 반복의 입력으로 사용한다.

코드 작성 속도는 평준화된다.
문제를 제대로 나누고, 틀린 결과를 발견하고, 실제 게임으로 완성하는 능력은 더 중요해진다.

검증일: 2026-08-01

1. GitHub, GitHub Copilot is generally available to all developers — 2022-06-21
   https://github.blog/news-insights/product-news/github-copilot-is-generally-available-to-all-developers/

2. OpenAI, Introducing ChatGPT — 2022-11-30
   https://openai.com/index/chatgpt/

3. GitHub Docs, Responsible use of GitHub Copilot Agents
   https://docs.github.com/en/copilot/responsible-use/agents

4. GitHub Docs, Best practices for using GitHub Copilot to work on tasks
   https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent-to-work-on-tasks/best-practices-for-using-copilot-to-work-on-tasks

5. Unity, Unity Unleashes the Power of AI for Creators — 2023-06-27
   https://unity.com/news/unity-unleashes-power-ai-creators-supercharging-content-creation-and-user

6. Unity, Unity's AI tools in beta: How to get started — 2026-05-05
   https://unity.com/blog/unity-ai-how-to-get-started

7. Unity, The in-Editor AI Assistant: Ask, Plan, and Agent Modes Explained — 2026-05-06
   https://unity.com/blog/unity-ai-assistant-ask-plan-agent-mode-explained

8. Unity Docs, Unity AI products
   https://docs.unity.com/ai

9. Unity Manual, Unity Profiler
   https://docs.unity3d.com/6000.0/Documentation/Manual/Profiler.html

10. Unity Manual, Profiler modules introduction
    https://docs.unity3d.com/6000.0/Documentation/Manual/profiler-modules-introduction.html

11. Unity Manual, Job system overview
    https://docs.unity3d.com/6000.0/Documentation/Manual/job-system-overview.html

12. Unity Manual, Burst compilation
    https://docs.unity3d.com/6000.0/Documentation/Manual/script-compilation-burst.html

13. Unity Manual, Order of execution for event functions
    https://docs.unity3d.com/6000.0/Documentation/Manual/execution-order.html

14. Unity Test Framework
    https://docs.unity3d.com/Packages/[email protected]/manual/index.html

15. Unity Addressables, Addressables overview
    https://docs.unity3d.com/Packages/[email protected]/manual/AddressableAssetsOverview.html

16. Unity Addressables, Asynchronous operation handles
    https://docs.unity3d.com/Packages/[email protected]/manual/AddressableAssetsAsyncOperationHandle.html

17. Microsoft Learn, Asynchronous programming with async and await
    https://learn.microsoft.com/dotnet/csharp/asynchronous-programming/

18. Microsoft Learn, Cancellation in managed threads
    https://learn.microsoft.com/dotnet/standard/threading/cancellation-in-managed-threads

19. Microsoft Learn, Task cancellation
    https://learn.microsoft.com/dotnet/standard/parallel-programming/task-cancellation