시대는 이미 달라졌다.

2022년, 대학교에서 소프트웨어 전공 수업을 듣던 중 교수님이 이런 말씀을 하셨다.

“개발자로 살아가고 싶다면 항상 최신 기술과 동향을 파악하는 습관을 길러라.”

그리고 그 자리에서 막 등장했던 ChatGPT를 소개해주셨다.
직접 사용해본 교수님의 평가는 이랬다

“대학교 1~2학년 수준의 코딩 능력은 갖춘 것 같다.”

그 당시만 해도 그 말은 그저 흥미로운 신기술에 대한 가벼운 리뷰처럼 들렸다. ‘AI가 코드를 짜준다’는 개념은 신기하긴 했지만, 내 피부에 와닿는 현실은 아니었다.
학기 프로젝트로 수행했던 강화학습 기반의 AI 에이전트 구현 역시, 우리에게 AI는 어디까지나 ‘우리가 연구해서 만들어야 할 대상’이었지 ‘나와 협업하는 도구’는 아니었기 때문이다.

하지만 불과 3~4년이 지난 지금, 상황은 완전히 뒤바뀌었다.

AI는 더 이상 연구실 안에 갇힌 기술이 아니다. 우리의 개발 환경 깊숙이 스며들어 IDE, 브라우저, 심지어 터미널 안에서도 실시간으로 우리와 소통하고 있다.

단순히 오타를 고쳐주거나 코드를 추천하던 수준은 옛일이 되었다. 이제 AI는 시스템 설계를 제안하고, 복잡한 로직을 리팩토링하며, 수십 페이지의 논문을 단 몇 줄로 요약한다. 나아가 우리가 놓친 예외 상황을 찾아 테스트 코드까지 생성해낸다.

“AI를 써야 할까?”라는 의구심의 시대는 끝났다.
이제 우리는 “AI를 어떻게 활용하여 나만의 경쟁력을 만들 것인가?”를 치열하게 고민해야 하는 시대를 살고 있다.

---

AI를 쓰면서 느낀 나의 경험 3가지

1. 실패와 반복이 매우 빨라졌다.

흔히 성공은 수많은 실패와 반복 위에 세워진다고 말한다.
문제는 그 “반복”에 드는 시간이었다.

예전에는 하나의 기술을 이해하는 데 몇 주, 구현하고 디버깅하는 데 몇 달이 걸렸다.
그 과정은 느렸지만 당연한 것이었다.

학부 시절, AI의 도움 없이 DirectX 12 기반의 테셀레이션(Tessellation)과 디스플레이스먼트 매핑(Displacement Mapping) 논문을 분석했던 기억이 난다.
그래픽스 파이프라인과 Graphics API 사용법을 익히는 데 한 달.
논문을 직접 번역하고 이해하는 데 한 달.
이를 실제로 구현하고 디버깅하는 데 두 달.
단 하나의 기술을 체화하는 데 매우 오랜 시간이 필요했다.

하지만 지금은 다르다.

AI 리서치를 통해 최신 논문을 빠르게 탐색하고,
요약 도구로 핵심 개념을 정리하고,
자연스러운 번역을 통해 생소한 용어나 외국어 논문도 하루 안에 읽어낼 수 있다.

최근 XPBD(Extended Position Based Dynamics)를 이용한 SoftBody를 구현하면서 이런 시대의 변화를 체감했다.
SoftBody을 구현하고 싶어 관련 기술과 논문을 찾는데 1시간.
기반 논문을 빠르게 요약으로 읽고 핵심 알고리즘을 파악하는 데 반나절.
이걸 실제 코드로 옮기는 작업을 하루.

옛날이었다면 한달 남짓은 걸렸을 작업이 단 이틀 만에 끝나버린 것이다.

이해되지 않는 수식은 AI에게 물어 즉시 해답을 얻고, 개념을 더 잘게 쪼개어 질문하며 구현의 정확도를 높였다.
예전에는 “한번 시도해 볼까?”라는 생각이 수개월의 리스크를 감수해야 하는 무거운 결정이었다면, 이제는 가벼운 ‘하루짜리 실험’이 되었다.

실패의 비용이 극적으로 줄어든 것이다.

이 변화는 단순히 생산성이 높아졌음을 의미하지 않는다.
우리가 탐색하고 도전할 수 있는 영역 자체가 무한히 넓어졌음을 뜻한다.

최근 많은 IT 기업이 신입 개발자 채용에 신중해진 것도 어찌 보면 당연한 귀결이다.
신입 한 명이 수개월간 겪어야 할 시행착오를, 시니어 한 명이 AI를 활용해 단 며칠 만에 끝내버리는 시대이기 때문이다. AI는 단순한 노동력을 대체한 것이 아니라, ‘경험의 속도’를 비정상적으로 끌어올렸다.

AI는 능력만 대체한 것이 아니다.
경험의 속도 역시 비정상적으로 끌어올렸다.

이제 주니어 개발자에게 중요한 것은 "무엇을 할 줄 아는가"를 넘어 "얼마나 밀도 있게 실패해 보았는가"라고 생각한다.
남들이 한 번 실패할 때 AI를 활용해 열 번, 스무 번 실패하며 살아남는 개발자만이 미래의 개발자가 될 수 있지 않을까 싶다.

2. AI, 활용과 남용을 구분할 줄 알아야한다.

최근에는 이른바 ‘바이브 코딩’이라는 말도 익숙하게 들려온다.
코드를 직접 치기보다, AI와 대화하며 기능을 구현해나가는 방식이다.
실제로 코드 한 줄 작성하지 않고 서비스를 배포했다는 사례도 어렵지 않게 찾을 수 있다.

처음에는 나 역시 그 흐름에 올라타고 싶었다.

“이제는 설계도 AI가, 구현도 AI가 해주는 시대 아닐까?”

그래서 언리얼 엔진 프로젝트를 통째로 AI에게 맡겨보기도 했다.
기능을 설명하고, 구조를 요청하고, 수정사항을 전달했다.

초반에는 놀라울 정도로 빠르게 결과물이 나왔다.

문제는 그 다음이었다.

어느 순간부터 내가 코드를 통제하는 것이 아니라, AI가 만들어낸 구조에 내가 끌려다니고 있다는 느낌이 들었다.

• 왜 이런 구조가 나왔는지 정확히 이해하지 못했고
• 버그가 발생했을 때 어디를 고쳐야 할지 감이 오지 않았으며
• 작은 수정 하나에도 다시 AI에게 의존해야 했다

결국 프로젝트는 중단되었다.

그때 깨달았다.

AI를 “사용”하는 것과 AI에게 “의존”하는 것은 전혀 다른 문제라는 것을.

그렇다면 의존은 어디까지 허용될까?

내가 구조를 이해하고 있고, 문제가 생겼을 때 직접 수정할 수 있는 범위라면
AI는 매우 훌륭한 도구다.
하지만 설계 자체를 이해하지 못한 채 전체 구조를 통째로 위임하는 순간, 개발자는 주도권을 잃는다.

AI 의존성은 코드를 대신 작성해주는 것에서 생기는 것이 아니라, 판단을 대신 맡기는 순간 시작된다.

AI를 사용하면서 나는 스스로에게 몇 가지 질문을 던지기 시작했다.
이 질문에 명확히 답할 수 없다면, 그건 활용이 아니라 의존에 가깝다고 생각했다.

1. 나는 이 코드를 AI 없이 설명할 수 있는가?

단순히 “동작한다”는 것이 아니라, 왜 이런 구조가 되었는지, 왜 이런 방식으로 설계되었는지를 설명할 수 있는가?

설명할 수 없다면, 그 코드는 아직 내가 아니라 AI가 짠 것이다.
과감하게 버려라.

2. 버그가 발생했을 때 AI 없이 수정할 수 있는가?

AI가 작성한 코드에 문제가 생겼을 때 나는 어디를 의심해야 할지 감이 오는가?

• 흐름은 추적할 수 있는가?
• 의존 관계는 이해하고 있는가?
• 수정 방향을 스스로 결정할 수 있는가?

AI 없이는 손댈 수 없다면, 이미 통제권은 넘어간 상태다.

3. 설계의 구조와 설계 이유를 모두 이해하고 있는가?

AI는 보통 “그럴싸한” 구조를 제시한다.

하지만 그 구조가

• 성능에 어떤 영향을 주는지
• 확장성에 어떤 한계를 가지는지
• 유지보수 비용이 얼마나 드는지
  온전히 이해하지 못한 채 맡긴다면 프로젝트의 변경 사항에 의거하여 나중에 설계를 바꾸고 싶어도 일부분이 아니라 전체를 뒤집어엎는 경험을 하게 될 것이다.

4. 이 코드를 일주일이 지나도 이해할 수 있는가?

AI와 대화하며 빠르게 만들고 복붙한 코드는 쉽게 기억에서 사라진다.

나중에 직접 봤을 떄 코드를 보고

• 내가 왜 이렇게 구현했는지 기억나는가?
• 어떤 고민이나 문제점이 있었는 지 생각나는가?

시간이 지나도 내 뇌리에 남는 이해 가능한 코드만이 진짜 “내 경험”이다.

5. 나는 지금 구현을 맡긴 것인가, 판단을 맡긴 것인가?

구현을 맡기는 것은 효율이다. 판단을 맡기는 것은 의존이다.

AI에게 “이 기능을 이렇게 구현해줘”라고 말하는 것과 “어떻게 해야 할지 모르겠으니 네가 결정해줘”라고 말하는 것은 다르다.

의존은 코드에서 시작되는 것이 아니라, 사고를 위임하는 순간 시작된다.

물론 아직은 모르는 것도 많고 새로운 개념도 많아서 의존을 쉽게 떨쳐내진 못하고 있다... 노력하자!.....

3. 질문하는 능력이 곧 실력이 된다.

처음 AI를 사용하기 시작했을 때, 나는 이렇게 물었다.
“적 NPC가 플레이어를 발견하면 공격하게 하고 싶어.”

이런 프롬프트를 맥락 없이 던지면, AI는 교과서적인 일반론만 늘어놓을 뿐이다.
예를 들면,

• 상태 머신을 사용하세요.
• Behavior Tree를 활용하세요.
• Perception 시스템을 사용하세요.

처럼 말이다.
물론 최근의 AI는 이전 대화를 기억하고 더 디테일한 답변을 내놓기도 하지만, 여전히 우리가 원하는 복잡한 기능을 '마법처럼' 한 번에 뚝딱 해결해 주지는 못한다.

결국 좋은 답변을 얻으려면, 문제를 AI가 소화할 수 있는 '최소 실행 단위'로 쪼개어 질문해야 한다.
위의 모호한 질문은 숙련된 개발자의 머릿속에서 다음과 같은 구체적인 맥락으로 분리된다.

• 참조(Reference): AI가 월드 내 플레이어 클래스를 효율적으로 참조하는 최적의 방법은?
• 인지(Perception): AI가 시야(Field of View)나 거리를 기반으로 타겟을 감지하는 구조는?
• 트리거(Trigger): 특정 조건이 만족되었을 때, 공격 로직을 실행할 이벤트 시스템의 설계는?

이렇게 작은 맥락으로 쪼개어 질문할수록 해결 확률은 비약적으로 높아진다.

하지만 여기서 중요한 포인트가 있다.
문제를 이렇게 쪼개는 능력 자체는 결국 개발자의 '베이스 지식'에서 나온다는 점이다.

AI를 도구로서 제대로 부리려면, 사용자가 해당 도메인의 기본 원리를 깊이 이해하고 응용할 줄 알아야 한다.
엔진의 구조를 모르는 사람이 던지는 질문과, 내부 동작 원리를 꿰고 있는 사람이 던지는 질문은 그 밀도가 다를 수밖에 없다.

코드를 짜는 행위는 AI가 대신해 줄 수 있지만, "어떤 문제를, 어떤 순서로 해결할 것인가"를 결정하는 기획과 설계의 영역은 여전히 개발자의 몫이다.

AI 시대에도 우리가 기초 지식을 치열하게 공부해야 하는 이유가 바로 여기에 있다. 이제 단순히 '코드를 잘 치는 것'이 아니라, '복잡한 문제를 정의하고 AI에게 최적의 질문을 던지는 능력'도 중요하지 않을까.

---

개발자는 사라질까?

AI 이야기를 하다 보면 자연스럽게 이런 질문으로 이어진다.

“그럼, 결국 개발자는 사라지는 걸까?”

나 역시 취업을 준비하며 이 길을 계속 가야 할지 수없이 고민했다. AI가 순식간에 코드를 짜고, 복잡한 구조를 제안하며, 버그까지 잡아내는 모습을 보면서 ‘근미래에 내가 서 있을 곳이 남아있긴 할까?’라는 두려움이 엄습했기 때문이다.

하지만 곰곰이 생각해보면 개발자의 본질은 변하지 않았다. 개발자는 단순히 코드를 타이핑하는 사람이 아니라, 무언가를 만들기 위해 문제를 정의하고 해결책을 설계하는 사람이다.

게임 개발자도 마찬가지다. 유저에게 줄 플레이 경험을 설계하고, 복잡한 시스템의 논리를 구성하며, 예상치 못한 오류의 원인을 끝까지 파고들어 해결하는 역할을 수행한다.

과거에는 어셈블리어와 텍스트 기반 환경에서 개발했고, 그 다음은 IDE 환경에서 생산성을 끌어올렸다. 그리고 이제는 AI와 함께 개발한다.

역사를 돌이켜보면 도구는 언제나 변해왔다.

• 과거: 어셈블리어와 텍스트 기반의 가혹한 환경에서 개발했다.
• 어제: IDE(통합 개발 환경)가 등장하며 생산성을 비약적으로 끌어올렸다.
• 오늘: 이제 우리는 AI와 함께 협업하며 개발한다.

수단은 바뀌었지만, 문제를 해결해야 하는 주체로서의 역할이 사라진 적은 한 번도 없었다. 물론 변화의 파동은 분명히 존재한다. 예전만큼 많은 인력이 투입되던 단순 구현 업무는 자동화될 것이고, 그만큼의 인력 수요는 줄어들지도 모른다.

하지만 그것이 개발 수요의 종말을 의미하지는 않는다.

세상은 더 복잡한 시스템,
더 높은 완성도,
그리고 더 정교한 사용자 경험을 끊임없이 요구하고 있기 때문이다.

또한 현실적인 장벽도 무시할 수 없다. 기업 현장에서는 보안과 신뢰성 문제로 인해 외부 AI 사용을 엄격히 제한하기도 한다. 특히 핵심 로직이나 인프라 영역에서는 AI의 결과물을 그대로 믿기보다, 개발자의 철저한 검증과 내부 가이드를 거치는 과정이 필수적이다.

특히 핵심 로직이나 인프라 영역에서는 AI의 결과를 그대로 사용하는 대신, 철저한 검증과 내부 가이드를 거치는 경우가 많다.

결국 AI는 개발자를 없애기보다는 개발자의 역할을 재정의하고 있는 것에 가깝다.

코드를 많이 치는 사람이 아니라, 무엇을 만들지 결정하고 어떻게 만들지 판단하는 사람이 더 중요해지고 있다.

개발자는 사라지지 않는다. 다만, 어제의 방식에 머물러 있는 개발자가 설 자리가 좁아질 뿐이다. 우리는 사라지는 것이 아니라, AI를 통해 더 고도화된 문제를 해결해야 할 차례가 아닐까 싶다.

물론 아직 주니어 개발자인 나의 짧은 식견이니 틀릴 수도 있다.

그래서 나는 뭘 해야할까?

그렇다면 AI 시대의 주니어 게임 개발자인 나는 무엇을 준비해야 할까?

어느 AI 스타트업 CEO는 이런 말을 했다.

“이제 모든 사람들이 전세계적인 수준의 천재들을 수십 명 데리고 일할 수 있는 시대가 왔다.”

이 말을 들었을 때 이런 생각이 들었다.
지금의 개발자는 어쩌면 개개인이 팀장이 된 것과 비슷하지 않을까?

곁에는 언제든 호출할 수 있는 수십 명의 “가상 시니어 개발자”가 있다.

하지만 중요한 건 이것이다.

그들에게 어떤 일을 시킬 것인지, 어떤 판단을 맡길 것인지, 최종 결정을 누가 내릴 것인지는 온전히 나에게 달려 있다.

AI는 인력처럼 보이지만, 책임을 대신 져주지는 않는다.

1. AI를 잘 쓰는 사람이 되기

나는 AI를 피할 생각은 없다.
오히려 적극적으로 활용할 생각이다.

• 반복 구현
• 보일러플레이트 코드
• 테스트 코드 및 주석 작성
• 자료 리서치 및 논문 요약

이 영역에서는 AI를 충분히 활용할 수 있다.

예를 들어 GitHub Copilot을 활용해 언리얼 프로젝트를 구성해보기도 했고,

기술 블로그나 논문은 AI 요약 도구를 활용해 핵심 개념을 먼저 파악한 뒤, 직접 원문을 읽는 방식으로 학습 속도를 높이고 있다.

설계 단계에서는 AI에게 여러 구조를 제안받고 각각의 장단점을 비교해보는 식으로 검증하면서 끊임없이 사고하고 있다.

2. 하지만 더 단단해지기

동시에 더 명확해진 것도 있다.

AI를 잘 쓰려면 내 기초 체력이 더 단단해야 한다는 것이다.

• 자료구조와 알고리즘
• 네트워크와 동기화 구조
• 렌더링 파이프라인
• 엔진 내부 흐름 이해

이런 기초가 없다면 AI의 답이 맞는지 틀린지도 판단할 수 없다.

특히 게임 개발에서는 성능, 동기화, 프레임 안정성, 예측 불가능한 버그 같은 현실적인 문제가 끊임없이 발생한다.

이 영역에서 최종 책임은 항상 개발자에게 있다.

3. AI와 협업하는 방법을 익히기

앞으로는 각 회사가 자체 AI 모델을 도입하거나 내부 전용 도구를 사용하는 시대가 올 가능성이 높다.

그렇다면 중요한 것은 “AI를 쓰느냐 마느냐”가 아니라 “AI와 어떻게 협업하느냐”가 될 것이다.

• 문제를 잘게 분해하는 능력
• 맥락을 정확히 전달하는 능력
• 결과를 검증하는 능력
• 잘못된 답을 걸러내는 판단력

이러한 능력 역시 중요해 질 것이다.

4. 나는 지금까지 AI로 어떤 것들을 해봤을까?

• GitHub Copilot과 언리얼 엔진 : 프로젝트 전반에 코파일럿을 적극 도입했다. 특히 방대한 Unreal API를 탐색할 때 가이드 역할을 톡톡히 해내며 개발 속도를 확실히 끌어올렸다. 하지만 코드가 길어지고 구조가 복잡해질수록 뼈저리게 느낀 사실이 있다. 결국 디버깅과 최종 설계 판단은 오롯이 내 몫이라는 것. AI는 시작을 가볍게 만들어주지만, 완성의 책임까지 대신해주지는 않았다.

• Antigravity를 활용한 구조 설계 : 기획 단계에서 시스템 구조를 여러 방식으로 시뮬레이션해 보았다. 상태 기반 설계부터 데이터 지향 접근까지, 다양한 대안을 빠르게 비교하며 며칠이 걸릴 고민을 단 몇 시간으로 단축했다. 하지만 선택의 속도는 빨라졌을지언정, 판단의 무게는 결코 가벼워지지 않았다.

• OpenClaw를 활용한 기술 블로그 구독 : 최근 주목받는 오픈소스 프로젝트인 OpenClaw를 호기심에 직접 설치해 사용해 보았다. 수많은 정보가 쏟아지는 환경에서 내가 관심 있는 기술 블로그만 선별하여 구독하는 기능을 활용하며 리서치 효율을 높였다. 과거에는 정보를 '얼마나 많이 읽느냐'가 실력이라 생각했지만, 이제는 넘쳐나는 정보 속에서 '나에게 필요한 것을 선별하고 무엇을 깊게 읽을지 고르는 능력'이 개발자의 진짜 실력이 되는 시대임을 체감했다.

• LiveWiki를 통한 학습: 요즘 긴 컨퍼런스 영상이나 영문 논문을 접할 때, 먼저 핵심을 요약한 뒤 원문을 정독하는 방식을 주로 선호한다. 학습 속도는 비약적으로 빨라졌지만 경계해야 할 점도 발견했다. 요약본만 보고 '이해했다'는 착각에 빠지기 쉽다는 것. 결국 개념을 자기만의 언어로 다시 풀어내지 못한다면, 그것은 진짜 내 지식이 아니었다.

• AI의 기반 지식 학습 경험 : AI를 단순히 도구로 사용하는 것에 그치지 않고, 그 저변의 원리를 파악하고자 노력했다. CNN과 MLP를 통해 신경망의 데이터 처리 및 학습 과정을 익혔고, 몬테카를로 알고리즘을 활용해 강화학습 에이전트를 직접 구현해 보기도 했다. Diffusion Model을 분석하며 생성형 AI가 데이터를 생성하는 구조를 파악해보기도 했다.

최근에 교보문고에 가서 책을 천천히 둘러보니 RAG라는 개념이 자주 눈에 들어온다. 조만간 시간을 된다면 이 부분도 알아보면 좋겠다는 작은 결심을 세워보았다.

---

결론

짧게 쓰고 싶었는데 쓰다보니 너무 길어져 버렸다.

하룻밤만 지나도 새로운 기술이 쏟아지고, 그 속도를 따라잡기도 전에 또 다른 변화가 밀려온다.
그리고 그 흐름에 휩쓸려 어디로 가는지도 모른 채 떠내려가는 기분이 들기도 하고, 흐름에 삼켜져 숨이 막히는 기분이 들기도 한다.

하지만 AI라는 거대한 흐름에 무작정 떠내려가는 대신, 나름의 중심을 잡고 꾸준히 헤엄치다 보면 결국 나만의 길을 찾아낼 수 있지 않을까 생각한다. 앞으로도 더 빠르게 변화하는 시대가 되겠지만, 그 변화를 관찰하며 묵묵히 내 나름대로 적응해 나가면 그걸로 되지 않을까.