POOOLING FOREST
15MB 모델로 수 테라바이트 데이터를 이기는 법: 2048과 테트리스가 알려준 엔지니어링의 본질 - 고작 15MB의 모델이 수 테라바이트의 데이터를 이긴 비결은 무엇일까요? 2048과 테트리스 강화학습 사례를
Engineering & Tech

15MB 모델로 수 테라바이트 데이터를 이기는 법: 2048과 테트리스가 알려준 엔지니어링의 본질

고작 15MB의 모델이 수 테라바이트의 데이터를 이긴 비결은 무엇일까요? 2048과 테트리스 강화학습 사례를 통해 효율적인 엔지니어링과 커리큘럼 러닝의 본질을 살펴봅니다.

송찬영

CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

AI 모델을 학습시킨다는 건, 때로는 지독한 짝사랑과도 같습니다. 수많은 밤을 지새우며 파라미터를 조정하고, 기도하는 마음으로 학습 그래프를 지켜보지만, 돌아오는 건 차가운 손실(Loss) 값뿐일 때가 많으니까요. 하지만 최근 읽은 강화학습(RL) 관련 사례는 우리가 기술을 대하는 태도에 대해 아주 날카로운 질문을 던집니다. 바로 고작 15MB 크기의 정책(Policy)으로 수 테라바이트(TB)에 달하는 검색 테이블 기반의 기존 솔루션을 압도해 버린 2048 게임 AI 이야기입니다.

오늘은 이 사례를 통해 단순히 모델의 크기를 키우는 것이 아니라, 어떻게 효율적으로 학습시킬 것인가에 대한 본질적인 이야기를 해보려 합니다.

우리는 흔히 문제가 풀리지 않으면 "모델 사이즈를 키우자"거나 "GPU를 더 쓰자"는 유혹에 빠집니다. 하지만 이 사례의 저자는 단 한 대의 RTX 4090으로 이 모든 것을 해냈습니다. 그 비결은 하드웨어의 물량이 아니라, 엔지니어링의 '순서'와 '방법론'에 있었습니다.

가장 먼저 충격을 받은 부분은 '속도'에 대한 관점입니다. 저자는 PufferLib이라는 고속 C 기반 환경을 사용하여 초당 100만 단계 이상의 시뮬레이션을 돌렸습니다. 속도가 빠르다는 건 단순히 결과를 빨리 본다는 의미가 아닙니다. 이는 강화학습을 '운에 맡기는 도박(YOLO and Pray)'에서 '체계적인 과학'으로 바꿔줍니다. 학습이 몇 분 만에 끝나니, 수백 번의 하이퍼파라미터 스윕(Sweep)을 돌리며 최적의 지점을 찾아낼 수 있었던 것이죠. 우리 팀도 때로는 무거운 모델에 갇혀 실험 횟수 자체를 줄이는 실수를 범하곤 하는데, 뼈저리게 반성하게 되는 대목이었습니다.

하지만 진정한 통찰은 '커리큘럼 러닝(Curriculum Learning)'에 있었습니다.

2048 게임은 규칙은 단순하지만, NP-hard 문제에 속할 만큼 상태 공간이 방대합니다. 기존의 방식은 모든 경우의 수를 저장하려다 보니 수 테라바이트의 데이터가 필요했습니다. 하지만 저자는 '스캐폴딩(Scaffolding)' 방식을 도입했습니다. 갓 태어난 아기가 바로 마라톤을 뛸 수 없듯, AI에게도 단계별 학습이 필요합니다.

초기 모델이 2048 타일을 만드는 엔드게임을 경험하지 못하면, 그 상황을 타개하는 법을 영영 배울 수 없습니다. 그래서 저자는 훈련 환경에서 인위적으로 고득점 타일(8k, 16k 등)을 미리 배치해 주는 커리큘럼을 설계했습니다. AI가 "아, 여기까지 오면 이렇게 해야 살아남는구나"를 미리 경험하게 해 준 것입니다. 이것이 바로 15MB의 작은 모델이 거대한 데이터 테이블을 이길 수 있었던 핵심입니다. 경험하지 않은 것은 배울 수 없다는 단순한 진리를 기술적으로 구현한 셈입니다.

테트리스 사례는 더 흥미롭습니다. 개발 과정에서 버그가 발생해 관찰 데이터에 노이즈가 계속 쌓이는 문제가 있었습니다. 상식적으로는 학습이 망가져야 하는데, 오히려 버그가 있을 때 AI가 더 강력해졌습니다. 왜 그랬을까요?

초기 단계의 혼란스러운 데이터(노이즈)가 AI에게 '견고함(Robustness)'을 가르쳤기 때문입니다. 마치 온실 속의 화초보다 비바람을 맞고 자란 나무가 튼튼하듯, 노이즈가 섞인 데이터를 처리하며 훈련된 AI는 게임 후반부의 극악한 속도와 불규칙한 상황에서도 당황하지 않았습니다. 개발자는 이 '버그'를 통해 무작위성을 주입하는 것이 훌륭한 커리큘럼이 될 수 있다는 사실을 깨달았습니다.

이 프로젝트가 우리에게 주는 교훈은 명확합니다.

첫째, 모델의 크기(Network Scale)는 가장 나중에 고민해야 할 문제입니다. 관찰(Observation) 데이터를 어떻게 가공해서 보여줄지, 보상(Reward) 체계는 올바른지, 그리고 어떤 순서로 학습시킬지(Curriculum)를 먼저 치열하게 고민해야 합니다. 우리는 종종 기반 공사가 부실한 상태에서 건물 층수만 높이려 듭니다.

둘째, 속도는 곧 경쟁력입니다. 빠른 이터레이션(Iteration)이 가능한 환경을 구축하는 것이야말로 불확실성을 줄이는 최고의 투자입니다.

풀링포레스트 동료 여러분, 그리고 이 글을 읽으시는 엔지니어 여러분. 지금 마주한 난제가 단순히 컴퓨팅 파워가 부족해서라고 느껴지시나요? 어쩌면 우리는 문제의 본질을 외면한 채 덩치만 키우려 하고 있었는지도 모릅니다. 오늘은 잠시 코드를 멈추고, 우리 AI에게 어떤 '교과서(Curriculum)'를 쥐어주고 있는지 돌아보면 좋겠습니다.

작은 모델로도 위대한 성과를 낼 수 있다는 사실, 그것이 엔지니어링의 낭만 아니겠습니까.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.