게임 개발, AI, 교육 — 현장에서 배운 것들을 기록합니다.
RPG 몬스터 설계의 첫 질문은 ‘이 정보가 모든 고블린에게 공통인가, 이 한 마리만의 상태인가’다. 플라이웨이트 패턴처럼 타입 데이터와 개체 상태를 분리하면 메모리 중복뿐 아니라 수정 범위까지 함께 좁아지고 데이터 의미도 선명해진다. 오브젝트 풀은 멋이 아니라 생성·해제 빈도가 실제 병목일 때만 얹는 최적화라는 점도 함께 정리한다.
더 읽기 →
WinAPI로 게임 개발을 시작할 때 가장 먼저 이해해야 할 것은 창 만드는 함수가 아니라, 메시지를 받아 윈도우 프로시저로 보내는 Win32의 흐름 자체다. Win32와 Winsock은 자주 함께 등장하지만 역할이 다르므로 분리해서 익히는 편이 낫다. 입문자는 거대한 설계보다 작은 루프부터 직접 움직여 보는 순서를 정리한다.
더 읽기 →
스타크래프트 봇 개발은 프로게이머 빌드를 코드로 옮기는 작업이라기보다, 공개 API로 게임 상태를 관측하고 그 위에서 행동을 선택하는 에이전트를 만드는 작업이다. BWAPI와 SC2 API, 리플레이 분석을 활용해 ‘관측 → 해석 → 행동’ 파이프라인을 만드는 입문 순서가 메모리 해킹보다 훨씬 현실적이라는 점을 정리한다.
더 읽기 →
스타크래프트의 마이크로가 깊이로 남은 이유는 단순히 손이 빠른 게임이라서가 아니다. Move·Attack-Move·Hold Position·Stop 같은 기본 명령의 차이를 자동화하지 않고 플레이어가 직접 해석해 개입하게 만든 설계 때문이다. 불편함과 깊이가 함께 있는 이 RTS의 조작 감각이 어떻게 실력 표현의 공간이 되었는지를 정리한다.
더 읽기 →
익스트림 프로그래밍은 이름과 달리 사람을 몰아붙이는 문화가 아니라, 테스트·리팩터링·작은 릴리스·지속 가능한 속도를 엮어 변화 비용을 낮추려는 공학 습관의 묶음이다. ‘Extreme’의 의미도 중요한 실천을 끝까지 밀어 보자는 태도에 가깝다. XP는 빨리 만드는 법이 아니라 바뀌어도 계속 만들 수 있는 법을 묻는다는 점을 정리한다.
더 읽기 →
FAB(Feature·Advantage·Benefit)는 낡은 약어 같지만, 기술이 복잡해질수록 오히려 더 중요해지는 설명 구조다. 고객은 기능 그 자체가 아니라 그 기능이 자기 일에 만들어 주는 변화를 사기 때문이다. AI나 자동화처럼 내부 동작이 모호한 제품일수록 기능을 가치 언어로 번역하는 작업이 다시 필요해진다는 점을 정리한다.
더 읽기 →
토글이 불편한 이유는 형식 자체가 나빠서가 아니라, 사용자가 지금 어떤 상태인지 즉시 알 수 없을 때 ‘기억 게임’이 되기 때문이다. W3C·Material·Apple 가이드를 종합하면 토글은 이진 상태가 분명하고, 라벨이 명확하고, 변화 결과를 바로 확인할 수 있을 때만 좋은 선택이 된다. 결국 문제는 토글이 아니라 상태를 얼마나 잘 보여 주는가에 있다.
더 읽기 →
K-pop과 Afrobeats, K-콘텐츠처럼 취향과 팬덤이 국경을 넘는 사례가 늘었지만, 그렇다고 로컬라이징이 불필요해진 것은 아니다. Spotify와 Netflix의 공식 자료가 보여 주듯 입문 경로와 표현 방식은 지역마다 다르다. 지금의 글로벌 마케팅은 ‘취향으로 묶고 지역으로 번역하는’ borderless taste + local entry point 구조에 가깝다는 점을 정리한다.
더 읽기 →
‘모든 프로그램은 데이터베이스다’는 엄밀한 정의는 아니지만 사고 실험으로는 꽤 쓸모 있다. 저장·조회·갱신·삭제, 무결성, 상태 전이의 관점으로 코드를 보면 객체 이름보다 접근 패턴과 유효 상태가 먼저 보이고, 프레임워크가 바뀌어도 설계가 덜 흔들린다. 데이터를 어떻게 다루는지가 결국 프로그램의 성격을 결정한다는 점을 정리한다.
더 읽기 →
기술 변화 속도가 빨라질수록 ‘무엇을 배웠는가’보다 ‘배운 것을 다른 맥락으로 옮길 수 있는가’가 더 중요해진다. WEF의 미래 일자리 보고서와 OECD Learning Compass도 분석적 사고·유연성·주도성을 반복해서 강조한다. 전문성을 부정하는 대신, 그 위에 전이 가능한 사고를 쌓아야 다음 기술을 배우는 속도까지 달라진다는 관점을 정리한다.
더 읽기 →