당신이 운영 체제가 되는 비디오 게임

 (plbrault.com)
7P by GN⁺ | ★ favorite | 댓글 1개
  • You’re the OS는 플레이어가 운영 체제 역할을 맡아 CPU 코어, 프로세스, 메모리 페이지, 스왑 공간을 관리하고 사용자의 재부팅을 막는 게임임
  • 기본 흐름은 유휴 프로세스를 CPU에 배정하고 활성 프로세스를 제거하는 방식이며, 오래 방치된 프로세스는 starvation 단계를 거쳐 종료됨
  • 시간이 지날수록 프로세스 수와 메모리 압박이 커져, 디스크에 있는 페이지를 RAM으로 되돌리는 메모리 스와핑까지 직접 처리해야 함
  • 구현은 Python/Pygame 기반이며, pygbag으로 WebAssembly 빌드를 만들어 브라우저에서도 실행 가능하게 함
  • 정확한 운영 체제 시뮬레이션은 아니지만, 전제를 분명히 하면 프로세스 스케줄링과 RAM 부족 상황을 설명하는 데 활용할 수 있음

운영 체제가 되는 게임 아이디어

  • 게임은 플레이어가 운영 체제가 되어 CPU 코어, 프로세스, 메모리 페이지, 스왑 공간을 관리한다는 구상에서 출발함
  • 목표는 사용자가 시스템이 너무 느리다고 느끼지 않도록 프로세스에 CPU 시간을 배정하고, 필요할 때 메모리 페이지를 스왑하는 것임
  • 단순한 2D 게임에 맞춰 전체 게임 엔진 대신 Pygame을 선택함
    • Python을 다시 사용해 보고 싶었던 점도 선택 이유였음
    • Pygame은 pygbag을 통해 WebAssembly로 컴파일할 수 있어 브라우저 실행에 유리함
  • 개발 기간은 8개월 사이에 흩어진 몇 주 정도였음

프로세스 스케줄링과 게임 종료 조건

  • 게임의 중심 조작은 프로세스와 CPU 관리임
    • 유휴 프로세스를 클릭하면 사용 가능한 CPU에 배정됨
    • 활성 프로세스를 클릭하면 해당 CPU에서 제거됨
  • 유휴 프로세스는 시간이 지나며 색상과 이모지로 표시되는 6단계의 starvation 수준을 거침
    • 마지막 단계에서 너무 오래 머무르면 사용자가 해당 프로세스를 종료함
    • 프로세스 10개가 종료되면 사용자가 운영 체제인 플레이어를 재부팅하고 게임이 끝남
  • 오래 살아남으려면 각 프로세스가 starvation 단계를 모두 거치기 전에 충분한 CPU 시간을 받아야 함

I/O와 메모리 스와핑

  • 활성 프로세스는 I/O 이벤트를 기다리며 blocked 상태가 될 수 있음
    • blocked 프로세스는 CPU 시간을 낭비하므로 CPU에서 제거하는 편이 좋음
    • I/O 이벤트는 이벤트 발생 시 모양이 바뀌는 버튼을 클릭해 처리함
  • 시간이 지날수록 더 많은 프로세스가 등장해 난도가 올라감
  • 어느 시점부터 전체 프로세스가 사용하는 메모리가 RAM보다 많아져 RAM과 디스크 사이의 페이지 스와핑이 필요해짐
    • 활성 프로세스가 디스크에 있는 페이지에 접근하려 하면 프로세스와 해당 페이지가 깜박임
    • 이 표시를 보고 필요한 페이지를 스왑해야 함
  • 디스크에 있는 페이지를 기다리는 프로세스는 해당 페이지가 RAM으로 돌아올 때까지 blocked 상태로 남음
    • 너무 오래 blocked 상태가 이어지면 starvation 단계를 계속 거쳐 결국 종료될 수 있음

난이도와 커스텀 설정

  • 게임에는 여러 난이도 수준이 있음
  • 난이도는 CPU 수, RAM 용량, 시작 시 존재하는 프로세스 수, I/O 이벤트 확률 등에 영향을 줌
  • 커스텀 모드에서는 이런 설정을 각각 독립적으로 조정할 수 있음

교육적 가치와 한계

  • 이 게임은 우선 게임이며, 현실성보다 플레이 가능성을 우선해 설계됨
  • 실제 운영 체제를 정확히 묘사하지 않는 부분이 있음
    • 플레이어가 실제 컴퓨터만큼 빠르게 반응할 것으로 기대하지 않음
    • 프로세스가 실제 일반적인 프로세스보다 훨씬 적은 메모리 페이지를 사용함
    • 사용자가 새 프로세스를 무한히 계속 실행하는 구조는 난도를 높이기 위한 게임 메커니즘임
  • 교육 목적으로 만들어진 것은 아니지만, 정확한 묘사가 아니라는 점을 분명히 하면 운영 체제 원리를 소개하는 데 가치가 있을 수 있음
    • 프로세스 스케줄링과 메모리 스와핑을 설명하는 예시로 쓸 수 있음
    • CPU 코어가 더 많다는 것이 무엇을 뜻하는지, RAM이 부족할 때 어떤 일이 생기는지 보여줄 수 있음

WebAssembly 컴파일과 배포

  • WebAssembly 컴파일은 pygame-web 문서 덕분에 예상보다 쉬웠음
    • 주요 단계는 pygbag 설치와 문서에 나온 코드 수정 적용임
  • 가장 큰 문제는 이모지 렌더링에 쓰던 pygame-emojis 라이브러리가 pygbag과 함께 작동하지 않았던 점임
    • 대신 OpenMoji에서 SVG 파일을 내려받음
    • GIMP로 크기를 조정하고 PNG로 내보내 사용함
  • 브라우저 버전은 기본적으로 데스크톱 버전과 같은 비율을 유지하면서 브라우저 뷰포트에 맞춰 크기를 조정함
    • 데스크톱 버전이 더 작은 창 크기를 쓰면 화면이 늘어나 보일 수 있음
    • 이 게임은 레트로 스타일이라 픽셀화가 심각하게 느껴지지는 않았음
  • 게임은 itch.io에서 브라우저로 플레이할 수 있음
  • 소스 코드는 GitHub에 공개되어 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 멋질 만한 아이디어로 조각 모음 게임이 떠오름. 기본적으로 원형 배치의 Tetris인데, 자주 쓰는 데이터 블록은 바깥쪽 트랙으로, 오래된 파일이나 아카이브 파일 형식은 안쪽 트랙으로 보낼수록 점수를 더 받는 식임
    예전에 그래픽 조각 모음 도구가 마법처럼 움직이는 걸 보는 걸 좋아했고, 조각 모음 게임이 나오면 진심으로 해보고 싶음

    • Wilmot's Warehouse가 사실상 이런 게임
      위에서 내려다보는 2D 게임이고, 큰 빈 창고에 혼자 있음. 일정 간격으로 트럭이 뒤쪽에 여러 물건을 내려놓고, 앞쪽 카운터에서는 몇 사람이 특정 물건을 요청함. 할 일은 요청을 최대한 빨리 처리할 수 있도록 창고 안 물건을 배치하는 것임. 색, 기능, 이름 등 자신에게 맞는 방식으로 정리하면 됨
      게임이 진행될수록 트럭은 더 다양한 물건을 가져오고, 보통 여러 범주에 걸치는 물건도 많아지며 요청도 점점 복잡해짐. 마지막에는 전체 게임 동안 창고가 어떻게 변했는지 타임랩스로 보여줘서 전략이 시간에 따라 진화하는 걸 볼 수 있음
      꽤 잘 만들었고 단순함. 실제로 HN 댓글에서 개발자 중 한 명을 통해 알게 됨
    • https://defrag.lolalabs.com/
    • https://classic.csunplugged.org/activities/community-activit...도 있고, https://www.itgsnews.com/the-defragmentation-game-lesson-pla...도 볼 만함
      https://boardgamegeek.com/boardgame/376284/defrag
      https://www.defraggame.com
      예전에는 이것들보다 더 직접적인 모사에 가까운 오래된 게임도 몇 개 해본 기억이 있는데, 다른 사람이 찾을 수 있을지는 모르겠음
    • 전자제품을 만들 때 PCB 라우팅과 배치에 대해 비슷한 느낌을 받았음
    • 판돈을 올려서, 게임을 위한 제물로 실제 드라이브를 쓰게 하자

  • Ender's Game처럼, 최상위 플레이어가 자기도 모르게 어딘가의 핵심 인프라 메모리를 할당하고 있다고 상상하면 좋음

    • Severance 느낌이 남
    • “가입을 완료하려면 이 이미지에 정지 표지판이 있는지 알려주세요. 서둘러 주세요, 우리 자율주행차가 이걸 필요로 합니다.”
      https://xkcd.com/1897/

  • 이 웹사이트를 반 문장 읽자마자 완전히 납득했음
    이런 문제를 이해하는 가장 좋은 방식 중 하나임. “이제 네가 메모리 관리자야. 행운을 빈다.”
    아이디어가 정말 좋음. 귀엽게 꾸며서 레스토랑 경영 시뮬레이션처럼 만들 수도 있을 것 같음. 다만 레스토랑은 컴퓨터이고 손님은 자원인 식임
    Human Resource Machine도 이런 면에서 훌륭했음. 어느 순간 “잠깐, 방금 내가 연결 리스트를 만든 건가?”라고 생각한 기억이 있음

    • Human Resource Machine은 정말 좋음. 아내가 그 게임과 후속작을 끝낸 뒤 코딩으로 커리어 전환까지 하게 됨

  • 사실 인간의 삶은 일종의 운영체제에 가깝다고 봄. 우리는 매일 작업, 자원, 입출력, 저장소, 캐시, 상태를 다루며 살아감
    대시보드는 운영체제의 필수 도구이고, 인간 규모에서는 은행, 할 일, 캘린더, 받은편지함 같은 것임. 그래서 많은 “자기계발” 개념은 운영체제의 모범 사례로 깔끔하게 번역됨. 예를 들어 할당 관리를 위한 선입선출이나 후입선출, 교착 상태를 깨기 위한 사전 계획, 병렬성 관리, 적시 가비지 컬렉션 같은 것들임

    • 추천하는 책인 Algorithms to Live By가 조금 떠오름
      [0] https://algorithmstoliveby.com/
    • 인간은 뇌를 기술에 비유하길 자주 좋아함
      예를 들어 톱니바퀴가 첨단 기술이던 시절에는 머릿속에서 톱니바퀴가 도는 그림을 그려, 생각하는 행위를 톱니바퀴의 움직임에 빗댄 사람들이 있었음. 만화 같은 곳에서는 아직도 가끔 그런 표현을 보는 것 같음
    • 우리가 운영체제라고 생각하는 것에 더 가까운 건 자율신경계일 수도 있음. 습식 하드웨어의 저수준 동작을 추상화해 줌
      https://en.m.wikipedia.org/wiki/Autonomic_nervous_system
    • 문명은 분산 운영체제임! Joscha Bach에게서 들었음
    • 자위에 해당하는 운영체제 비유는 뭘까? 캐시 비우기?

  • 참고로 이건 9월 30일에 HN에 올라왔지만 전혀 주목받지 못했고, 올린 사람도 자기 댓글을 지웠음
    그때도 썼지만, 정말 좋은 개념임. 레벨을 추가하면 좋겠음. 예를 들어 흥미로운 제품 안의 마이크로컨트롤러, 스마트폰, SaaS 회사의 부하 분산기나 API 서버 같은 식으로 레벨을 나누면 개념을 하나씩 도입할 수 있음. 그러면 대학 수준의 운영체제 수업이 됨
    자동화를 위한 약간의 프로그래밍을 넣고, 운영체제 캐시 알고리즘까지 깊게 파고들면 좋겠음. LRU 좋지. 고등학교 졸업 전에 끝낼 수 있었을 만한 수업임
    https://news.ycombinator.com/item?id=36938032

  • 멋진 아이디어지만 나한테는 너무 어려움. 일반 모드에서도 게임 시작 20초 만에 미친 듯이 클릭하게 되고, 막힌 프로세스를 순환시켜도 빨간 프로세스가 쌓임
    어떤 프로세스는 입출력 이벤트가 끝내 오지 않아서 죽었음. 쉬움 모드도 똑같거나 오히려 더 어려운 것 같음. 메모리가 문제가 되는 지점까지 가지도 못하는데, 이 속도라면 가고 싶지도 않음
    나이가 든 걸 수도 있고 운영체제가 되는 게 스트레스라는 건 이해하지만, 내 일도 이미 스트레스임. 또 하나의 일을 원하지 않음
    처음에는 쉽게 시작해서 점점 올라가되 내 안락 지대 바로 바깥에 머물 정도의 더 관대한 속도라면, 아주 재미있는 게임이 될 수 있음

    • 입출력 이벤트를 기다리다가 끝내 오지 않아 프로세스가 죽는 같은 문제가 있었음. 죽은 프로세스가 전부 그 상태에서 죽었음. 이런 일이 생기면 막을 방법이 없어 보임
    • 반복 작업을 겁먹지 않고 대신 해주라고 컴퓨터가 있는 거지 :)

  • 이런 게임에는 강한 미래가 있음
    Unity나 Unreal 같은 게임 엔진이 제공할 수 있는 범위를 넘어 혁신하는 게임은, 설계상 요즘 나오는 것들보다 성공 가능성이 높은 방향으로 가고 있음
    엔진 사용자들이 건드릴 수 없을 만큼 영역 밖에 있는 초덕후 게임을 만들면 다른 리그에 서게 됨. 게임이 엉망으로 보여도 재미있고 쓸 수 있으면 됨
    인디 게임은 5년 전 의미의 인디 게임이라는 점에서는 죽었음. 이제 이런 것이 새로운 인디 게임. GG. 참고로 상업 타이틀 2개 이상을 낸 실패한 인디 개발자임
    Zachtronics가 멈춘 건 아쉬움. 그들은 항상 앞서 있었음

    • 뭔가 놓친 건지도 모르겠지만, 같은 유형의 게임은 수십 년 동안 계속 인기를 끌어온 것 같음. 그런 게임들이 성공 가능성이 더 낮아졌는지도 모르겠고, “네가 운영체제다!”가 더 성공 가능성이 높은지도 확신이 안 듦
      그리고 이 게임은 Unity로도 만들 수 있을 것 같음
    • 이걸 Unity나 Unreal로 만들 수 없을 이유가 없음. 계산 한계 안에서는 그 엔진들로 말 그대로 뭐든 만들 수 있음
    • 이 게임이 어떤 면에서 Unity가 제공할 수 있는 범위를 넘어섬?
    • “성공”이 무슨 뜻인지에 따라 다름. 수익을 낸다는 뜻이라면 아마 아닐 것임. 시장이 원하는 것에 최적화된 엔진들이 지원하는 흐름에서 멀리 벗어난 게임은 그 안에 있는 게임보다 더 자주 실패할 가능성이 큼
      “예상 밖의 돌파구가 되어 게임의 방향을 바꾸는 히트작이 된다”는 뜻이라면, 어느 쪽이든 확률은 극히 낮지만 틀 밖의 게임이 그 확률은 더 높을 수 있음
      홈런 확률은 더 높지만, 아웃될 확률도 더 높고, 안타를 칠 확률은 더 낮음
    • 무슨 얘기인지 잘 모르겠음. 덕후 게임은 항상 있었고, 너무 덕후스럽기 때문에 대개 크게 성공하지 못함
      최근 몇 년에도 기술 덕후 게임이 여럿 있었지만 히트작이라고 부를 만한 건 없었음. 아마 자기 게임은 만들 수 있겠지만, 관객층이 본질적으로 작아서 성공의 상한도 제한됨. 앞으로 이게 바뀔 것 같지도 않음
      오히려 반대일 가능성이 큼. 젊은 세대는 덜 덕후화되고, 저수준 주제와 기술에서 더 멀어지는 듯함

  • 게임이 높은 사용률로 어려워질수록, 이정표나 성능 목표를 달성해 얻은 토큰으로 작은 반복 작업을 자동화하는 업그레이드를 “구매”할 수 있어야 함. Universal Paperclips 같은 느낌임
    그다음 간단한 자동화를 방해하는 병적인 작업부하를 던져서 사용자가 수동으로 풀어야 하게 만듦. 그러면 사용자는 조금 더 나은 자동화를 사지만, 다시 조금 더 병적인 작업부하에 막힘. 이렇게 게임 진행 루프가 완성됨

    • 메모리 할당기를 살 수 있으면 좋겠음. 직접 하나 작성하는 선택지도 있으면 좋고

  • 곧 운영체제가 일을 자동화할 수 있게 스크립트 언어를 제공하겠지?
    아, 알겠다...

    • C 인터프리터를 써서 Linux 코드를 그냥 복사해 오자... 아니면 반대로 하거나

  • 아주 멋짐. 지난주에 올라온 게임이 떠오름. Defcon 관련이었나? 연산 코드가 들어 있는 Tetris 블록 같은 사각형이 떨어지고, 사용자가 가장 큰 수를 “점수” 메모리 레지스터로 섞어 넣는 Rube Goldberg식 시퀀스를 배치해야 하는 게임이었음

답변달기