
52시간의 광기: 언어부터 게임까지 바닥부터 다 만드는 게 가능할까?
52시간 만에 새로운 언어와 VM을 만들고 게임 5개까지 출시한 Langjam 참가팀의 도전기. 밑바닥부터 만드는 기술의 의미와 극한의 제약이 주는 통찰을 다룹니다.
김테크
8년차 개발자

안녕하세요. 풀링포레스트 8년차 개발자 김테크입니다.
개발자라면 누구나 한 번쯤 "내가 직접 프로그래밍 언어를 만들어보면 어떨까?"라는 로망을 가져본 적이 있을 겁니다. 물론 저도 그랬습니다. 컴파일러 수업 때 파서(Parser)를 붙잡고 씨름하다가 "아, 그냥 있는 언어나 잘 쓰자"라며 포기했던 기억이 나네요. 그런데 얼마 전, 제 개발자 혼을 다시금 불타오르게 만든 엄청난 도전기를 발견했습니다.
바로 'Langjam'이라는 해커톤에 참가한 한 팀의 이야기인데요. 이 팀이 52시간, 그러니까 딱 주말 동안 해낸 일이 정말 믿기지 않습니다.
새로운 프로그래밍 언어 설계 (
GarLang)그 언어를 돌릴 가상 머신(VM)과 컴파일러 제작
그리고 그 언어로 만든 게임 5개 출시
네, 오타 아닙니다. 52시간 안에 이 모든 걸 다 해냈답니다. 오늘은 이 미친(!) 도전기를 통해 우리가 배울 수 있는 '밑바닥부터 만드는 기술(Wheel Reinventing)'의 의미와, 극한의 제약 사항이 개발자에게 주는 영감에 대해 이야기해 보려 합니다.
왜 사서 고생을 할까요?
솔직히 말해, 실무에서 이런 짓을 했다가는 팀장님께 불려 가기 딱 좋습니다. "김테크 님, 일정이 이렇게 바쁜데 갑자기 프레임워크를 새로 짠다고요?"라는 소리를 듣겠죠. 우리는 효율을 위해 잘 만들어진 도구(Spring, Django, Unity 등)를 쓰는 데 익숙합니다. 저 역시 풀링포레스트에서 안정적인 서비스를 위해 검증된 기술 스택을 고집하고요.
하지만 이 GarLang 프로젝트 팀은 기술의 편의성을 걷어차고 '로우 레벨(Low-level)의 야생'으로 뛰어들었습니다. 이들이 만든 GarLang은 8비트 레트로 감성을 타겟으로 한 16색 팔레트, 128x128 해상도의 아주 제한적인 환경을 제공합니다.
재미있는 건 이들이 겪은 문제 해결 과정입니다.
보통 게임 잼(Game Jam)이라면 유니티나 언리얼 엔진을 켜고 "자, 무슨 게임 만들까?"부터 시작하죠. 하지만 이들은 컴파일러부터 만들어야 했습니다. VM을 만들고 화면에 픽셀 하나를 찍기 위해 메모리 주소를 직접 건드려야 했죠.
이 과정에서 '추상화(Abstraction)가 우리에게 무엇을 숨기고 있었는지' 뼈저리게 깨닫게 됩니다.
극한의 제약이 만들어낸 창의성
개발을 하다 보면 리소스 부족, 빡빡한 일정, 레거시 코드 같은 제약 사항을 마주합니다. 그때마다 우리는 한숨을 쉬죠. "서버 사양만 좀 더 좋았어도...", "시간만 더 있었어도..."
하지만 이 프로젝트를 보면 제약 사항이 오히려 창의력의 기폭제가 된다는 걸 알 수 있습니다. 52시간이라는 절대적인 시간 부족, 그리고 직접 만든 언어의 불안정함 속에서도 그들은 무려 5개의 미니 게임을 만들어냈습니다.
어떻게 그게 가능했을까요?
핵심은 '본질에 집중하기'였습니다. 화려한 그래픽이나 복잡한 물리 엔진은 과감히 버렸습니다. 대신 언어 자체의 기능(Sprite 처리, 입력 감지 등)을 게임 개발에 딱 필요한 만큼만 구현하고, 게임 로직도 그에 맞춰 단순화했습니다.
저도 예전에 트래픽이 몰려 서버가 터지기 일보 직전이었던 적이 있습니다. 그때 온갖 캐싱 전략을 다 동원하려다가 실패하고, 결국 가장 많이 호출되는 API 하나의 로직을 단순하게 뜯어고쳐 해결했던 기억이 납니다. 도구가 부실하다고 탓하기 전에, 우리가 해결하려는 문제가 무엇인지 명확히 정의하는 것이 엔지니어링의 핵심임을 다시 한번 느꼈습니다.
"바퀴를 다시 발명하라"의 진짜 의미
주니어 개발자분들이 종종 묻습니다. "라이브러리 안 쓰고 직접 구현해보는 게 도움이 될까요?"
제 대답은 항상 "무조건 해보세요"입니다. 실무 코드에 넣으라는 게 아닙니다. 사이드 프로젝트나 학습 과정에서 바퀴를 다시 발명해보는 경험은, 나중에 진짜 타이어가 펑크 났을 때 누구보다 빠르게 원인을 찾을 수 있게 해줍니다.
그들의 경험은 나중에 복잡한 JVM 튜닝 이슈나, 원인을 알 수 없는 메모리 누수(Memory Leak)를 만났을 때 직관적인 통찰력을 제공합니다.
마치며: 가끔은 야생으로 돌아가자
요즘 Cursor나 Claude 같은 AI 코딩 도구가 너무 잘 나와서, 코드를 '작성'하는 일보다 '검토'하는 일이 더 많아졌습니다. 편하고 효율적이지만, 가끔은 내가 기술의 소비자로만 남는 건 아닌지 불안할 때가 있습니다.
그럴 때 이 GarLang 프로젝트처럼, 아주 작고 쓸모없어 보이는 것이라도 '처음부터 끝까지 내 손으로' 만들어보는 건 어떨까요? 거창한 언어가 아니어도 좋습니다. 아주 간단한 텍스트 에디터, 나만의 작은 웹 서버, 혹은 엑셀 함수 몇 개를 구현한 계산기라도요.
편리한 도구 뒤에 숨겨진 원리를 이해하는 순간, 우리는 단순히 코드를 짜는 코더(Coder)에서 문제를 해결하는 엔지니어(Engineer)로 한 단계 성장할 수 있습니다.
저도 이번 주말에는 다 잊고, 아주 예전에 보다가 덮어둔 컴파일러 책을 다시 한번 펼쳐봐야겠습니다. 혹시 알나요? 풀링포레스트 차세대 시스템의 힌트를 거기서 얻게 될지 말이죠.
오늘도 밑바닥부터 고민하며 성장하는 여러분을 응원합니다.



