기술 블로그

생성형 AI가 만든 글의 오류는 제각각이 아니라 꽤 규칙적인 패턴으로 반복된다. 유창한 오답, 작은 왜곡의 누적, 확인되지 않는 인용과 숫자, 원문에 없던 도입부 일화와 마무리 질문 같은 문체 습관이 같이 따라붙는다. 그래서 AI 재작성본에 필요한 것은 더 좋은 프롬프트가 아니라 주장 단위의 사실 검증이라는 점을 정리한다.

연애에서 경제적 차이는 분명한 현실이지만, 관계를 무너뜨리는 것은 차이 자체보다 그 차이를 둘러싼 침묵과 추측, 해석의 엇갈림이다. 한쪽의 배려를 다른 쪽이 통제로 읽기 시작하면 격차는 더 커진다. 상대를 점수화하는 전략보다 불편한 돈 이야기를 솔직하게 꺼내고 기대를 맞춰 가는 대화가 관계를 더 오래 가게 만든다는 점을 Pew와 CFP Board 자료와 함께 짚는다.

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 구조에 가깝다는 점을 정리한다.