게임 개발, AI, 교육 — 현장에서 배운 것들을 기록합니다.
GameTutorials.com 같은 옛 입문 사이트는 창 만들기, 렌더링 루프, 충돌 같은 큰 흐름을 작게 쪼개 보여 준 좋은 학습 문화의 산물이지만, 그대로 따라 하면 API와 도구 선택이 어긋난다. 옛 자료를 개념 입문용으로만 활용하고 Unity Learn, Unreal Engine 학습 자료, LearnOpenGL 같은 최신 공식 경로로 구현을 교차검증하는 방식을 정리한다.
더 읽기 →
재사용성과 테스트는 따로 다뤄지는 품질처럼 보이지만 실제 설계에서는 같은 방향으로 움직인다. 의존성을 드러내고 책임 경계를 작게 유지한 코드는 다시 쓰기도 쉽고 시험하기도 쉽다. 마틴 파울러의 의존성 주입 설명을 빌려, 두 품질이 결국 얼마나 덜 얽혀 있는가라는 같은 질문으로 수렴한다는 점과 함께 챙길 수 있는 설계 습관을 정리한다.
더 읽기 →
데드락은 본래 여러 작업이 서로의 자원을 기다리다 모두 멈춰 버리는 운영체제 용어다. 사람은 스레드가 아니지만, 데드락 성립의 네 조건이라는 구조만 빌리면 조직과 관계에서 누구도 먼저 풀 수 없는 교착이 왜 생기는지를 누가 더 나쁜가가 아니라 무엇이 서로를 묶고 있는가의 질문으로 다시 보게 된다. 그 비유의 쓸모와 한계를 정리한다.
더 읽기 →
데이비드 파나스의 정보 은닉 원칙이 오래 살아남은 이유는 모듈을 기능이 아니라 변경 가능성이 있는 결정의 경계로 나누는 발상 때문이다. PG사 연동, 수치 테이블, 저장 포맷처럼 자주 바뀌는 부분이 흩뿌려지면 작은 요구도 연쇄 수정이 되지만, 한곳에 숨기면 변경 영향이 줄어든다. 유지보수성은 결국 변동성을 격리하는 일관성에서 나온다.
더 읽기 →
실망스러운 기술 책의 공통점은 설치 화면과 홍보 문장은 길고 개념 설명과 실전 맥락은 약하다는 점이다. 좋은 책은 공식 문서를 반복하지 않고 문서를 이해할 수 있게 도와주며, 첫 50페이지 안에 실제 문제 해결이 등장한다. 책을 고를 때는 제목의 무게보다 예제의 깊이와 개념 밀도를 먼저 봐야 한다.
더 읽기 →
좋은 소프트웨어 설계는 화려한 패턴이나 거대한 아키텍처가 아니라 변경 비용을 낮추는 구조에서 드러난다. 단순함과 중복 제거, 자주 바뀌는 결정의 격리, 지속적 리팩터링이 쌓이면 다음 변경을 덜 아프게 받아들이는 코드가 된다. 결국 설계의 질은 다음 수정을 얼마나 잘 견디느냐로 뒤늦게 드러난다.
더 읽기 →
개발 고전이 자주 미뤄지는 큰 이유 중 하나는 두께도 오래된 점도 아닌 영어 장벽이다. 『The C++ Programming Language』, 『실용주의 프로그래머』, 조엘 스폴스키의 에세이처럼 한국어판으로 읽을 수 있는 책들을 예로 들어, 문법보다 판단과 태도, 작업 방식 전체를 다루는 책을 어떻게 바이블이 아닌 관점 보정 도구로 읽을 수 있는지 정리한다.
더 읽기 →
Stackless Python은 코루틴이 들어간 파이썬이라는 짧은 설명만으로는 부족하다. 태스크릿, 채널, 스케줄러를 통해 매우 가벼운 실행 단위를 다루는 별도 구현이며, PEP 342와 PEP 492가 정착시킨 오늘날의 `async`/`await`와는 다른 계보로 동시성을 메시지 전달과 작은 실행 주체의 협력으로 보게 만드는 관점을 보여 준다는 점을 정리한다.
더 읽기 →
익스트림 프로그래밍은 이름과 달리 사람을 몰아붙이는 문화가 아니라, 테스트·리팩터링·작은 릴리스·지속 가능한 속도를 엮어 변화 비용을 낮추려는 공학 습관의 묶음이다. ‘Extreme’의 의미도 중요한 실천을 끝까지 밀어 보자는 태도에 가깝다. XP는 빨리 만드는 법이 아니라 바뀌어도 계속 만들 수 있는 법을 묻는다는 점을 정리한다.
더 읽기 →
‘모든 프로그램은 데이터베이스다’는 엄밀한 정의는 아니지만 사고 실험으로는 꽤 쓸모 있다. 저장·조회·갱신·삭제, 무결성, 상태 전이의 관점으로 코드를 보면 객체 이름보다 접근 패턴과 유효 상태가 먼저 보이고, 프레임워크가 바뀌어도 설계가 덜 흔들린다. 데이터를 어떻게 다루는지가 결국 프로그램의 성격을 결정한다는 점을 정리한다.
더 읽기 →
비야네 스트롭스트룹의 『The C++ Programming Language』는 두꺼운 문법서로 보이지만, 실제로는 언어 기능 하나하나를 어떤 설계 판단 아래 써야 하는지를 함께 묻는 책이다. 창안자가 직접 쓴 만큼 ‘할 수 있다’와 ‘해야 한다’를 구분하는 감각이 남으며, 한 단계 올라가려는 C++ 사용자에게 한 번쯤 통과해야 할 책으로 정리한다.
더 읽기 →