"코드는 자산이 아닙니다. 부채입니다."
제가 신입 사원 온보딩 때마다 하는 말입니다.
주니어들 표정이 묘하게 썩어 들어가는 게 보이죠.
꿈과 희망을 가지고 입사했는데, 시작부터 빚쟁이 취급이라니 억울할 만도 합니다.
하지만 이건 부정할 수 없는 현실입니다.
여러분이 짠 코드는 배포되는 순간부터 유지보수 비용을 발생시키는 '잠재적 버그 덩어리'니까요.
오늘은 좀 오래된, 하지만 아주 날카로운 문서 하나를 꺼내볼까 합니다.
1999년에 작성된 '둠2 데스매치 부정행위(Cheating) 분석 보고서'입니다.
뜬금없이 웬 고전 게임 타령이냐고요?
이 문서를 뜯어보면, 우리가 시스템을 구축할 때 왜 그토록 '방어적 코딩'과 '로깅(Logging)'에 목숨을 걸어야 하는지 알 수 있기 때문입니다.
금융권 차세대 프로젝트 때 제가 PM 멱살 잡고 사수했던 원칙들도 다 여기에 들어 있습니다.
지금부터 개발자의 관점에서 이 '고대 유물'을 해부해 드립니다.
1. 치트의 정의: "합의되지 않은 변경"
문서는 '치트'를 이렇게 정의합니다.
"상대방이 동의하지 않았거나 인지하지 못한 상태에서, 시스템의 변경을 통해 우위를 점하는 행위."
이동 속도, 시야, 조준 능력 같은 것들이죠.
이걸 현업 백엔드 용어로 바꿔볼까요?
'비인가 접근(Unauthorized Access)' 혹은 '어뷰징(Abusing)'입니다.
장애인 플레이어가 접근성 향상을 위해 설정을 바꾸는 건 치트가 아니라고 명시한 부분이 인상적이더군요.
즉, '의도(Intent)'와 '공정성(Fairness)'이 핵심입니다.
우리가 API 설계를 할 때 단순히 '기능 구현'만 생각하면 안 되는 이유가 여기 있습니다.
클라이언트가 정해진 규칙대로만 요청을 보낼 거라는 믿음.
그건 개발자의 순진한 망상입니다.
사용자는, 아니 공격자는 여러분이 상상도 못한 파라미터를 던져서 시스템의 허점을 파보려고 할 겁니다.
그게 바로 '치트'니까요.
2. 딜레마: 보안은 '공개'해야 강해진다
작성자는 고민합니다.
치트 방법을 상세히 적으면, 오히려 이걸 보고 따라 하는 악성 유저가 늘어나지 않겠느냐고.
'모방 범죄'에 대한 우려죠.
하지만 결론은 명확합니다.
"정보를 공개해서 대다수의 정직한 플레이어가 치트를 감지하고 증명할 수 있게 하는 게 더 이득이다."
이건 보안 업계의 오랜 논쟁인 'Security by Obscurity(보안을 위한 은폐)'를 정면으로 반박하는 태도입니다.
소스를 숨겨서 보안을 유지하겠다는 건 하수나 하는 생각입니다.
취약점은 공개하고, 패치하고, 모니터링 시스템을 강화해서 막아야 합니다.
이 문서가 지향하는 바가 바로 그렇습니다.
"숨기지 말고, 검출(Detect)하고, 증명(Prove)하라."
3. 로그(Log)는 거짓말을 하지 않는다
이 문서에서 가장 소름 돋았던 부분은 바로 .lmp 파일 분석입니다.
.lmp 파일은 둠2의 데스매치 기록을 담은, 일종의 '바이너리 로그'입니다.
작성자는 이 파일을 분석 유틸리티로 뜯어보면, 상대가 '오토 에임(Aimbot)'을 썼는지, 'SR-50 매크로'를 썼는지 100% 증명할 수 있다고 말합니다.
여기서 주니어 여러분이 뼈에 새겨야 할 교훈이 나옵니다.
"로그 없는 시스템은, 사고 났을 때 시체 없는 살인 사건과 같다."
SI 시절, 금융 사고 터졌을 때 저를 살려준 건 화려한 아키텍처가 아니라 구석에 박혀있던 텍스트 로그 파일이었습니다.
문제가 생겼을 때 "어? 이상하네?" 하고 넘어가면 안 됩니다.
정확히 어떤 요청이, 언제, 어떤 페이로드로 들어왔는지 기록이 남아 있어야 합니다.
이 문서의 저자처럼, 데이터를 근거로 "너 지금 Aimbot 썼지?"라고 팩트를 꽂을 수 있어야 한다는 말입니다.
그냥 같은 쓰레기 로그 좀 그만 남기세요.
제발 부탁입니다.
4. 클라이언트는 절대 믿지 마라
문서에 언급된 치트 목록을 보면 재밌는 게 있습니다.
Map Editing, Sprite Editing, Sound Editing.
플레이어 로컬 PC의 맵이나 그래픽 리소스를 조작해서 벽 뒤를 투시하거나 소리를 증폭시키는 치트들입니다.
이건 '클라이언트 위변조'입니다.
게임 클라이언트(App/Web)에서 유효성 검사를 다 했다고 서버는 안심해도 될까요?
천만에요.
프론트엔드에서 아무리 막아봐야, HTTP 요청 자체를 조작해서 보내면 서버는 뚫립니다.
1999년의 게이머들도 맵 파일을 헥스 에디터로 뜯어고쳐서 썼습니다.
하물며 2024년의 해커들이 고작 자바스크립트 유효성 검사 하나 못 뚫을까요?
모든 입력값 검증은 반드시 서버 사이드에서 다시 이루어져야 합니다.
"화면에 빨간 점(Red Dot) 찍어서 조준 돕는 건 못 막는다"는 대목은 현실적인 한계를 인정하는 엔지니어의 자세를 보여줍니다.
우리가 통제할 수 없는 영역(물리적 모니터)과 통제 가능한 영역(패킷 데이터)을 명확히 구분하는 것.
그게 시니어의 안목입니다.
결론입니다.
1999년 둠2 유저들은 정정당당한 승부를 위해 로그 파일을 뜯어보고 분석 툴을 돌렸습니다.
그 치열함이 있었기에 'e스포츠'라는 개념이 싹틀 수 있었겠죠.
여러분의 코드는 어떻습니까?
누군가 악의를 가지고 덤벼들었을 때, 그 흔적이라도 남길 수 있는 구조인가요?
아니면 "안 돼요"라고 말만 하고 근거는 대지 못하는 무능한 시스템인가요.
화려한 신기술, 좋습니다.
하지만 기본인 로깅, 검증, 모니터링이 없다면 그건 그냥 모래성입니다.
오늘 당장 회사 가서 로그 설정부터 다시 확인해 보세요.
그게 여러분의 연봉보다 먼저 올라야 할 '개발자로서의 기본기'입니다.
