기술 블로그

K-pop과 Afrobeats, K-콘텐츠처럼 취향과 팬덤이 국경을 넘는 사례가 늘었지만, 그렇다고 로컬라이징이 불필요해진 것은 아니다. Spotify와 Netflix의 공식 자료가 보여 주듯 입문 경로와 표현 방식은 지역마다 다르다. 지금의 글로벌 마케팅은 ‘취향으로 묶고 지역으로 번역하는’ borderless taste + local entry point 구조에 가깝다는 점을 정리한다.

‘모든 프로그램은 데이터베이스다’는 엄밀한 정의는 아니지만 사고 실험으로는 꽤 쓸모 있다. 저장·조회·갱신·삭제, 무결성, 상태 전이의 관점으로 코드를 보면 객체 이름보다 접근 패턴과 유효 상태가 먼저 보이고, 프레임워크가 바뀌어도 설계가 덜 흔들린다. 데이터를 어떻게 다루는지가 결국 프로그램의 성격을 결정한다는 점을 정리한다.

기술 변화 속도가 빨라질수록 ‘무엇을 배웠는가’보다 ‘배운 것을 다른 맥락으로 옮길 수 있는가’가 더 중요해진다. WEF의 미래 일자리 보고서와 OECD Learning Compass도 분석적 사고·유연성·주도성을 반복해서 강조한다. 전문성을 부정하는 대신, 그 위에 전이 가능한 사고를 쌓아야 다음 기술을 배우는 속도까지 달라진다는 관점을 정리한다.

아이디어가 막힐 때 필요한 것은 더 큰 영감이 아니라 다른 질문이다. 스탠퍼드 d.school의 How Might We, IDEO의 유사 사례 영감, 배율 바꾸기, SCAMPER 같은 도구는 모두 ‘같은 방식으로만 생각하는 상태’를 깨기 위해 만들어졌다. 창의성은 무에서 솟는 재능이 아니라 질문의 다양성과 관찰 밀도에서 자란다는 점을 정리한다.

티머시 골웨이의 『The Inner Game of Work』는 일을 더 많이 하라는 생산성 책이 아니라, 자기 의심·과잉 긴장·평가 불안 같은 내부 잡음을 먼저 보라고 말하는 책이다. 같은 과제를 하면서도 에너지가 다르게 빠지는 이유를 외부 조건이 아닌 주의력의 질에서 찾는 관점이며, 의지력보다 자기 관찰의 언어가 더 중요해지는 지점을 정리한다.

비야네 스트롭스트룹의 『The C++ Programming Language』는 두꺼운 문법서로 보이지만, 실제로는 언어 기능 하나하나를 어떤 설계 판단 아래 써야 하는지를 함께 묻는 책이다. 창안자가 직접 쓴 만큼 ‘할 수 있다’와 ‘해야 한다’를 구분하는 감각이 남으며, 한 단계 올라가려는 C++ 사용자에게 한 번쯤 통과해야 할 책으로 정리한다.

트리즈는 소프트웨어 문제를 자동으로 풀어 주는 만능 표가 아니라, ‘성능을 높이면 복잡성이 늘고 단순화하면 유연성이 떨어진다’ 같은 충돌을 더 선명하게 분해하게 만드는 사고 도구다. 40가지 원리 이름을 외우기보다 이상적 상태와 모순을 한 문장으로 적고, 시간·공간·조건으로 분리해 보는 습관이 실무에서는 더 쓸모 있다는 점을 정리한다.

게임 디자이너는 보상의 양을 자주 고민하지만, 실제로 더 자주 문제를 만드는 것은 도전의 조절이다. 칙센트미하이의 플로우처럼 실력과 난이도가 맞물릴 때 몰입이 생기며, 보상은 진행감을 보강할 뿐 대체하지 못한다. 좋은 밸런스는 정답이 아니라 ‘플레이어가 다음 도전에 다시 손을 뻗을 이유’를 계속 만들어 주는 일이라는 점을 정리한다.

테스트 주도 개발은 테스트를 나중에 붙이는 습관이 아니라, 실패하는 테스트부터 써서 설계 순서 자체를 바꾸는 방식이다. 레드-그린-리팩터링의 짧은 피드백 주기에서 핵심은 테스트 개수가 아니라 설계와 검증 사이의 왕복 거리이며, 마지막 단계의 리팩터링이 빠지면 TDD는 반쪽만 남는다. 진짜 가치는 커버리지 숫자보다 더 분명한 경계선과 안전한 변경 능력에 있다.

세스 고딘이 말한 ‘작은 것이 새로운 큰 것’은 소규모 예찬이 아니라 디지털 시대 경쟁 방식이 바뀌었다는 진단이다. 작은 팀의 무기는 인원 수가 아니라 낮은 실험 비용, 짧은 의사결정, 고객과의 가까운 거리이며, 대기업 운영 방식을 흉내 낼수록 오히려 약해진다. 규모보다 방향 전환 속도가 결과를 가른다는 관점을 정리한다.

작은 팀이 자유롭게 느껴지는 이유는 낭만이나 재능이 아니라 의사결정 거리가 짧고 실패 비용이 낮기 때문이다. 반대로 큰 팀의 답답함도 단순한 관료주의가 아니라 변경 한 번의 파급 비용이 넓어진 결과에 가깝다. 라미 이스마일과 Wolfire 사례를 빌려, 핵심은 팀 규모 자체가 아니라 실험과 수정의 왕복 시간을 어떻게 짧게 유지하느냐에 있다는 점을 정리한다.

Read It Later와 Pocket의 진짜 가치는 링크 저장 기능이 아니라, 지금의 발견을 미래의 읽기로 옮겨 주고 여러 기기 사이에서 읽기 맥락을 이어 주는 ‘주의력의 예약’에 있었다. 2025년 7월 서비스 종료 이후에도 그 기능이 브라우저로 흡수되고 있다는 사실은 ‘나중에 읽기’라는 습관이 사라진 것이 아니라 도구의 형태만 바뀌고 있음을 보여 준다.

Wolfire의 Overgrowth 사례가 보여 준 오픈 개발의 핵심은 화려한 기술 시연이 아니라, 선주문·주간 알파·비공개 포럼·블로그를 하나의 운영 구조로 묶어 자금·피드백·신뢰를 한꺼번에 쌓은 데 있다. 오픈 개발이 ‘솔직해 보이기’가 아니라 개발 리스크를 커뮤니티와 공유하는 운영 방식이라는 점, 그리고 인디 팀에 그 의미가 큰 이유를 정리한다.

앤디 그로브의 ‘Only the Paranoid Survive’는 늘 겁을 내라는 자기계발 문구가 아니라, 전략적 변곡점의 신호를 늦기 전에 읽으라는 경고에 가깝다. 잘되고 있을 때조차 전제를 다시 점검할 수 있는가가 핵심이며, 조직이 흔히 실패하는 이유도 무능보다 이전 성공 논리를 너무 오래 유지한 데 있다는 점을 정리한다.

상속은 ‘무엇의 하위 타입인가’를 표현하는 데 강하지만, UI 이벤트나 객체 간 통신처럼 호출 관계가 자주 바뀌는 영역에서는 델리게이트나 시그널과 슬롯 같은 느슨한 연결이 더 잘 맞는다. C# 델리게이트와 Qt 시그널의 사례를 빌려, 좋은 설계는 상속을 줄이는 신념이 아니라 ‘타입 관계’와 ‘실행 시 연결 관계’를 분리해 보는 습관에서 나온다는 점을 정리한다.

MMORPG 서버 설계의 진짜 문제는 ‘방을 몇 개로 나눌까’가 아니라 ‘각 플레이어에게 지금 무엇이 relevant한가’를 어떻게 싸게 계산하느냐다. 거리 기반 필터링과 공간 분할 같은 interest management가 그래서 중요하다. 좋은 서버는 많이 보내는 구조가 아니라 ‘어떻게 덜 보내도 충분하게 만들까’를 푸는 구조에 가깝다는 점을 정리한다.

온라인 게임에서 반복되는 아이템 복사·재화 누락·거래 절반 반영 버그의 공통 원인은 대개 ‘여러 변경이 한 묶음으로 처리되지 않은 것’이다. 트랜잭션은 이론 시간의 용어가 아니라 이런 절반만 성공한 상태를 막기 위한 기본 장치다. ACID 암기보다 ‘무엇과 무엇이 반드시 함께 성공해야 하는가’를 정하는 일이 더 실무적이라는 점을 정리한다.

참조 무결성은 외래 키 규칙으로만 생각하기 쉽지만, 런타임에서 포인터·핸들·식별자가 가리키는 대상의 수명을 관리하는 문제에도 거의 같은 구조가 깔려 있다. 데이터베이스가 ‘존재하는 행만 가리키게 하라’고 한다면 런타임은 ‘살아 있는 객체만 가리키게 하라’를 요구한다. 결국 핵심은 소유권과 수명, 유효성 확인을 함께 설계하는 일이다.

인터넷 덕분에 정보는 싸졌지만, 무엇을 읽고 무엇을 버릴지 판단하는 비용은 오히려 커졌다. 허버트 사이먼과 조지 스티글러의 관점을 빌리면 정보 과잉 시대에 희소한 것은 주의력이며, 우리가 책과 큐레이션 서비스에 돈을 쓰는 이유도 정보 그 자체보다 선별과 배열이라는 편집 노동을 사는 데 있다는 점을 정리한다. 더 많이 읽기보다 더 많이 버리는 능력이 결국 생산성을 만든다.

온라인 게임은 개발자가 만든 콘텐츠 밀도만으로 오래 버티지 못한다. 플레이어가 협력·경쟁·표현·소속감을 만들 수 있는 ‘빈칸’이 잘 설계되어 있어야 상호작용이 누적되며, 접속자 수보다 연결의 질이 가치를 결정한다. 다만 빈칸은 방치와 다르고, 자유와 그것을 읽히게 돕는 규칙·보상 구조가 함께 있어야 한다는 점에서 기획의 어려움이 시작된다.

조엘 스폴스키의 『Joel on Software』는 거대한 이론 대신 The Joel Test, 버그 추적, 새는 추상화 같은 낮지만 치명적인 마찰을 집요하게 건드린다. 좋은 팀은 우연히 굴러가지 않는다는 감각, 즉 빌드·버그·채용 같은 기본기를 잃지 않게 만드는 운영 감각이 이 책의 가장 큰 가치라는 점을 다시 짚는다.

게임 객체는 이동·물리·AI·네트워크처럼 여러 시스템의 교차점에 놓이기 때문에 깊은 상속 계층은 금방 무거워진다. 그래서 컴포넌트 중심 조합이 자주 선택되는 것이지, 상속이 틀려서가 아니다. 안정적인 공통 규약에는 상속이 여전히 유용하며, 핵심은 ‘상속이냐 조합이냐’의 신념 싸움이 아니라 변경 비용이 가장 낮아지는 지점을 보는 일이라는 점을 정리한다.

시장 점유율을 한 장의 파이 차트만으로 읽으면 현재의 강자만 눈에 들어오고 변화의 방향을 놓치기 쉽다. 진짜 알고 싶은 것은 보통 ‘무엇이 커지고 줄고 있는가’이므로, 한 시점의 비율과 함께 시간 흐름·전체 규모 변화·신규 항목의 진입을 같이 봐야 한다. CDC와 Datawrapper 가이드를 빌려, 시장 구조는 정지 화면이 아니라 움직이는 장면이라는 관점을 정리한다.

‘All Your Base Are Belong To Us’가 오래 기억되는 이유는 단순히 웃긴 오역이어서가 아니다. 게임 장면이 커뮤니티를 거치며 합성 이미지와 플래시 영상으로 재가공되고, 이용자가 직접 노동을 들여 퍼뜨린 참여형 밈의 대표 장면이기 때문이다. 알고리즘 없이도 인터넷 문화가 어떻게 공동 제작되었는지 보여 주는 기록으로 다시 본다.

게임 업계의 노동 문제를 ‘열심히 공부하면 된다’거나 ‘산업이 원래 그렇다’로만 말하면 중요한 부분이 빠진다. IGDA와 콘진원 자료가 반복해서 보여 주듯 고용 불안, 크런치, 차별 대응 부재 같은 구조적 요인이 함께 얽혀 있기 때문이다. 자기계발은 필요하지만 충분조건은 아니며, 제도와 집단적 대응 언어가 같이 필요하다는 점을 정리한다.

2010년 Google I/O를 다시 보면, 진짜 메시지는 HTML5라는 단어가 아니라 Chrome Web Store, WebM과 VP8, Android Froyo의 브라우저 개선을 한꺼번에 밀어 웹을 앱 플랫폼으로 끌어올리려 한 큰 방향에 가까웠다. 웹이 어디까지 갈 수 있는가에 대한 기대가 한꺼번에 폭발한 순간이었다는 점을 정리한다.

짐 콜린스(Jim Collins)의 『Good to Great』는 위대한 회사를 만드는 비결을 카리스마나 한 방의 아이디어보다, 레벨 5 리더십과 규율 있는 사람·생각·행동의 축으로 설명한다.

좋은 디자인과 더 나은 디자인의 차이는 화면이 예쁜가보다도, 사용자의 마찰을 어디까지 제거했는가에 더 가깝다. 버튼을 다듬는 수준과 흐름 전체를 다시 짜는 수준은 분명히 다르다.

불변 자료구조는 매번 전체를 복사하는 비효율적인 방식처럼 보이지만, 실제 구현은 구조적 공유와 영속 자료구조를 바탕으로 훨씬 더 실용적으로 동작한다.

함수형 프로그래밍에서 재귀는 루프의 대체재라기보다 상태 변화를 인자로 드러내는 방식에 가깝다. 특히 꼬리 재귀와 누산기 패턴을 이해하면 이 차이가 분명해진다.

함수형 프로그래밍은 게임 코드를 전부 다시 쓰라는 명령이 아니다. 불변 데이터와 순수 함수의 관점을 이용해 규칙 계산, 상태 전이, 서버 메시지 처리처럼 변화를 분리해야 하는 영역을 더 다루기 쉽게 만든다.

앤디 그로브의 『Only the Paranoid Survive』는 전략 전환의 핵심을 거창한 혁신 선언보다 '새 CEO라면 무엇을 먼저 버릴까'라는 냉정한 질문에서 찾는다.

잘 설계된 소프트웨어는 지금 동작하는 것만으로는 충분하지 않다. 요구사항 충족, 정보 은닉, 가독성, 변경 용이성, 과잉 설계 회피라는 다섯 기준으로 다시 정리한다.

처음 설계를 시작할 때는 클래스 수를 늘리는 것보다, 무엇이 책임이고 무엇이 자주 바뀌는지 먼저 묻는 편이 훨씬 안전하다. 입문자가 바로 적용할 수 있는 5가지 질문으로 정리한다.

소프트웨어 개발은 분석-설계-구현-테스트가 한 번 직선으로 끝나는 공정이 아니다. 작은 단위를 반복하며 스코프를 줄이고 피드백을 되감는 순환 구조로 보는 편이 실제에 가깝다.

소프트웨어 설계 입문에서 중요한 것은 다이어그램 도구를 많이 아는 것이 아니라, 시스템의 경계와 책임을 설명하는 습관을 익히는 것이다. UML과 C4 모델은 그 다음에 붙이는 도구에 가깝다.

이 글에서는 게임 디자인을 이해하는 편의적 틀로 '첫인상-동기-연결' 세 축을 제안한다. 다만 이것은 정설 이론이 아니라, MDA와 자기결정성이론 연구를 바탕으로 정리한 실무적 관점이다.

게임 프로그래밍은 언어 하나로 끝나지 않는다. 시간 관리, 물리, 상태 머신, 길찾기, 데이터 구조처럼 서로 다른 문제 영역을 어떻게 나눠 공부할지 정리한다.

게임 개발을 시작할 때 가장 중요한 것은 거대한 기획이 아니라 작은 게임 하나를 끝까지 만들어 보는 경험이다. 엔진 학습과 협업도 그다음에 붙이는 편이 안정적이다.

Steven Johnson의 『Everything Bad Is Good for You』는 텔레비전과 게임을 둘러싼 익숙한 도덕 공황에 반론을 제기하며, 대중문화의 복잡성이 인지적 훈련이 될 수 있다고 주장한다.

EA의 공식 채용·육성 페이지를 보면, 대형 스튜디오가 신입과 초기 경력 프로그래머에게 기대하는 것은 화려한 꿈의 프로젝트보다 C++ 기초, 협업, 테스트, 문제 해결 능력에 더 가깝다.

Microsoft가 DirectX 9.0에서 고급 셰이더 언어와 더 강한 그래픽 프로그래밍 기능을 밀어붙이면서, 윈도우 게임 개발의 기준이 한 단계 올라갔다.

Erich Gamma 외 3인의 『Design Patterns』는 23개 패턴 목록보다도, 반복되는 설계 문제를 이름 붙이고 토론하게 만든 공통 언어로서 영향력이 컸다.

미국 경제학자 월터 블록의 문제작과 CBO·OECD·NBER·FTC 자료를 함께 놓고, 규제가 언제 보호가 되고 언제 부작용을 키우는지 단순한 선악 구도 대신 상충 관계 관점에서 다시 본다.

라그나로크 온라인을 둘러싼 그라비티 내부 갈등은 단순한 '개발자 배신' 이야기로 요약하기 어렵다. 당시 기사에서 직접 확인되는 사실과 오늘 시점에 섣불리 단정하면 안 되는 부분을 나눠 정리한다.

게임 개발자 노엘 로피스의 글과 Unity의 데이터 지향 기술 묶음 문서를 바탕으로, 데이터 중심 설계가 왜 캐시 친화적 접근을 중시하는지, 그리고 언제 도움이 되고 언제 과한 선택이 되는지 정리한다.

Google C++ Style Guide, PEP 8·257, Javadoc, Go 문서 주석 가이드를 바탕으로, 어떤 주석은 지우고 어떤 주석은 남겨야 하는지 정리한다.

기억 연구와 노트 필기 연구를 기준으로, 브레인덤프를 과학적 백업 기술처럼 과장하지 않고 무엇을 남겨야 나중의 내가 다시 생각을 이어갈 수 있는지 정리한다.

McKinsey Quarterly 인터뷰를 바탕으로, 브래드 버드가 왜 돈을 로켓의 연료라고 표현했는지 그 문맥만 짧게 정리한다.

Dan North, Martin Fowler, Cucumber 문서를 기준으로, 행동 주도 개발이 단순한 '주어진 상황-행동-결과' 문법이 아니라 요구사항과 테스트를 같은 언어로 연결하려는 시도였다는 점을 다시 정리한다.

알랭 드 보통 공식 소개와 발췌문을 바탕으로, 그가 말하는 불안이 개인의 약함보다 비교와 평가의 구조에서 어떻게 생겨나는지, 그리고 왜 일과 일상을 다시 보는 시각이 그 불안을 다루는 출발점이 되는지 정리한다.

세계보건기구의 체르노빌 포럼 자료와 유엔 방사선영향과학위원회 자료를 바탕으로, 체르노빌 사고의 장기적 공중보건 영향이 방사선량만으로 설명되지 않으며 정신건강과 사회심리적 피해, 위험 커뮤니케이션의 실패가 실제 피해의 일부가 됐다는 점을 정리한다.

Eames Office 아카이브와 도널드 노먼의 시그니파이어 개념을 바탕으로, 게임 사용자 경험에서 좋은 디자인이 어떻게 플레이어의 다음 행동을 분명하게 만드는지 살펴본다.

작은 문제를 미루는 습관이 어떻게 기술 부채와 팀 피로를 키우는지 살펴보고, 즉시 해결 문화가 왜 생산성과 유지보수성을 함께 높이는지 정리한다.

3D 카메라의 핵심은 입체 영상이 아니라 깊이 정보와 3D 복원 워크플로에 있다. 애플의 인물 사진 모드, RealityScan, ARKit, NeRF, 가우시안 스플래팅 사례를 바탕으로 실제 활용 지점을 정리한다.

MIT OpenCourseWare가 실제로 제공하는 것과 제공하지 않는 것을 구분하며, 무료 공개 강의가 대학식 학습 경험을 어디까지 재현하는지 정리한다.

DigiPen, BUas, USC의 공식 프로그램 소개와 커리큘럼 자료를 바탕으로, 해외 게임 교육의 공통점을 비교한다. 핵심은 특정 학교의 명성이 아니라 수학·프로그래밍·협업·완성 경험을 어떻게 한 구조 안에 묶는가에 있다.

언리얼 엔진만으로도 게임을 만들 수 있는데 굳이 DirectX를 공부해야 할까? 두 기술의 관계를 정확히 이해하고, 언제 DirectX 지식이 필요한지, 어떤 순서로 학습하는 것이 현실적인지 정리한다.

게임 밸런스의 목표는 모두를 똑같게 만드는 데 있지 않다. David Sirlin과 Riot의 공식 글을 바탕으로, 밸런스가 왜 공평함보다 의미 있는 선택과 좌절 관리의 문제에 가까운지 정리한다.

게임업계는 작지 않은 산업이지만, 채용은 여전히 어렵고 현업은 인력난을 말한다. 한국콘텐츠진흥원, 국제게임개발자협회, 게임 개발자 콘퍼런스 자료를 바탕으로 그 이유가 왜 단순한 인원 부족이 아니라 구조적 미스매치에 가까운지 정리한다.

게임 산업의 변화는 단순히 기기가 바뀐 문제가 아니다. 디지털 유통, 무료 플레이, 라이브 서비스, 규제 강화가 개발자와 유저의 관계를 어떻게 다시 설계했는지 근거 중심으로 정리한다.

게임 프로듀서의 일은 좋은 아이디어를 믿는 것이 아니라 단계별 전환점을 관리하는 데 있다. 프로토타입, 버티컬 슬라이스, 알파, 베타, 출시 준비를 어떤 기준으로 나눠야 하는지 근거 중심으로 정리한다.

성능, 툴, 아키텍처는 모두 수단이다. Unity와 Unreal의 공식 프로파일링 문서, YAGNI와 기술 부채 관점을 바탕으로, 게임 프로그래머가 단계별로 무엇을 우선 최적화해야 하는지 정리한다.

코루틴은 멀티스레드의 대체물이 아니라, 메인 스레드 안에서 시간을 나눠 쓰게 해주는 구조다. Unity 공식 문서를 바탕으로 코루틴이 무엇을 해결하고 무엇을 해결하지 못하는지 다시 정리한다.

게임 기획서는 처음부터 완성본을 쓰는 문서가 아니다. 레퍼런스 분석, 핵심 루프 정리, 한 장짜리 설계, 프로토타입과 플레이테스트를 연결하는 방식으로 기획 문서를 현실적으로 만드는 법을 정리한다.

대학, 부트캠프, 독학 중 무엇이 맞는지는 사람마다 다르다. 지금 기준으로 유효한 공식 학습 경로와 공공 훈련 체계를 바탕으로, 어떤 상황에서 어떤 조합이 현실적인지 정리한다.

생성형 인공지능이 게임 개발 전반에 들어오면서 중요한 역량도 바뀌고 있다. 코드를 더 빨리 만드는 능력보다, 인공지능 결과물을 읽고 검증하고 교정하는 능력이 왜 더 중요해졌는지 정리한다.

좋은 프로그램의 기준은 성능 하나로 정해지지 않는다. 이름, 함수 크기, 주석, 일관성, 리팩토링 가능성처럼 다른 사람이 읽고 고칠 수 있는 코드의 조건을 다시 정리한다.

출시 직전에 터지는 버그, 기능 추가할 때마다 무너지는 구조. 게임 프로젝트에서 리팩토링을 미루면 어떤 일이 벌어지는지, 그리고 실전에서 리팩토링을 언제, 어떻게 해야 하는지를 경험을 바탕으로 정리한다.

UML, 디자인 패턴, 개방-폐쇄 원칙 같은 개념을 게임 개발 맥락에서 어떻게 익히고 적용할지 정리한다.

Hook, Flow, Bond, Loop는 학술 표준이라기보다 실무 체크리스트에 가깝다. 플레이어가 왜 시작하고, 왜 몰입하고, 왜 애착을 느끼고, 왜 다시 돌아오는지를 순서대로 점검하는 틀로 다시 정리한다.

첫 게임은 혼자서도 만들 수 있지만, 오래 가려면 협업의 감각이 필요하다. 작은 프로젝트로 시작해 팀 프로젝트와 게임잼으로 넘어가는 현실적인 순서를 정리한다.

게임에서 테스트 주도 개발은 모든 것을 테스트하자는 구호가 아니다. Unity의 에디트 모드·플레이 모드 테스트와 테스트 피라미드 관점을 바탕으로, 어떤 코드를 먼저 테스트 가능한 구조로 분리해야 하는지 정리한다.

텍스트 RPG와 MUD는 낡은 장르처럼 보이지만, 프로그래밍 기초를 실제 동작으로 연결하기엔 여전히 훌륭한 프로젝트다. 무엇을 어떤 순서로 만들면 좋은지, 역사와 구현 포인트를 함께 정리한다.

게임 기획자의 역할은 '재미있는 아이디어 내기'보다 훨씬 넓다. 시스템, 레벨, 콘텐츠, 사용자 경험을 어떻게 설계하고 무엇으로 포트폴리오를 준비해야 하는지 근거 중심으로 정리한다.