사용자 도구

사이트 도구


사이드바

blog:start

ESC 키 문제

지난 주에 드디어 애플 매직키보드가 배송되었습니다. 아이패드와는 별도로 배송되었기 때문에 케이스 없는 아이패드는 집 밖으로 나갈 수 없는 상태였습니다. 제조사 주장으로는 아이패드는 여러 가지 충격을 적당히 견딜 정도로 견고하게 만들었다고 했지만 이미 지난 세대 아이패드가 여러 환경에서 휘어지는 문제가 있다는 사실1)을 알고 있었고 이번 세대 아이패드는 지난 세대에 비해 이 문제에 한해서는 아무것도 개선되지 않았다는 사실2) 역시 알고 있었습니다. 튼튼한 케이스 없이는 집 밖으로 나갈 수 없음은 물론이고 심지어 다른 책과 함께 가방에 들어가는 것도 금지됐습니다.

매직키보드는 이 상태를 한번에 해결했습니다. 수많은 리뷰어들로부터 이미 알려진 대로 엄청나게 무거웠습니다. 키보드를 상자에서 꺼낼 때 까지만 해도 이정도는 괜찮겠다고 생각했습니다. 하지만 그건 키보드만 들었을 때 이야기였고 이 물건을 언제나 아이패드와 함께 들고다녀야 한다는 사실을 생각해내는데까지는 얼마 시간이 걸리지 않았습니다. 아이패드에 장착해서 아이패드가 바닥에서 대략 1센티미터쯤 떠있는걸 아무 감각 없이 지켜보다가 키보드 째로 들어올렸을 때 느껴진 '이게 뭐야' 하는 감정이 아직도 생생합니다. 케이스를 접어 손에 들자 이건 웬만한 전공책보다 더 무거웠습니다. 회사에 들고 가 동료분들께 들어보게 하다가 문득 다른 분의 그램 노트북을 들어보고 이건 거의 아이패드의 절반 무게로 느껴진다는 것을 알았습니다. 저는 아이패드를 들고다니는게 아니라 무슨 둔기를 들고다니는 느낌이었습니다. 밝은 면만 보면 이 키보드 케이스와 함께라면 아이패드는 절대로 휘어지지 않을 겁니다. 아마도 키보드는 금속으로 만들어진 아이패드보다도 더 휘어짐에 강할 겁니다. 하지만 어두운 면을 보자면 한국은 둔기소지가 합법인 국가가 되었습니다.

리뷰어들이 매직키보드는 5열로 설계되어 ESC키가 없어 불편하다는 이야기를 많이 했습니다. 대수롭지 않게 생각했습니다. 내가 무슨 빔 에디터를 사용하는 것도 아니고 ESC키를 얼마나 사용하겠나 하는 생각이었습니다. 그도 그럴 것이 저는 리눅스에서는 나노 에디터를 사용했고 나머지 모든 데스크탑에서는 5열로 구성된 HHKB를 사용했습니다. HHKB는 매직키보드와 똑같이 5열이었지만 지금까지 아주 오랫동안 사용하면서 아무런 불편함이 없었습니다. 그래서 매직키보드의 배열에 불평하는 리뷰어들을 보며 좀 유난이 아닐까 생각하고 있었습니다.

매직키보드를 사용하고 나서 4일이 지난 지금 이제는 이야기할 수 있습니다. 내가 빔을 사용하든 말든 ESC키는 본능의 일부라고요.3) 가령 아이패드에서 커맨드 + 스페이스를 눌러 스팟라이트 검색 인터페이스를 꺼냈습니다. - 아이패드에서도 이 화면을 스팟라이트라고 부르는지는 모르겠습니다만 - 검색을 해본 다음 이 인터페이스를 그냥 닫을 생각으로 저는 본능적으로 1왼편의 틸드 키를 눌렀고 아무 일도 일어나지 않았습니다. 정확히는 검색 텍스트박스에 문자가 입력됐습니다. 심지어 틸드 키도 아니었습니다. 저는 스팟라이트 인터페이스를 닫기 위해 커서를 움직여 취소 버튼을 클릭하거나 직접 속으로 화면에 있는 취소 버튼을 터치하거나 아니면 커맨드 + 스페이스키를 다시 눌러야만 했습니다.

그때서야 뭔가 잘못됐다는 사실을 깨달았습니다. 빔을 사용하지 않더라도 화면에 나타난 뭔가를 닫거나 취소하기 위해 본능적으로 ESC키를 사용하고 있었다는 사실을 이제야 제대로 알게 됐습니다. 게다가 생각해보니 HHKB는 5열 키보드이지만 1 왼쪽에 ESC키를 배치했습니다. 대신 그 자리에 있어야 할 틸드 키는 1열 맨 오른쪽으로 옮겼습니다. 그래서 일할 때 언리얼엔진의 콘솔을 불러내려면 1왼쪽에 있는 키가 아니라 1열 가장 오른쪽에 있는 키를 눌러야 합니다. 1열 오른쪽 끝에 틸드 키가 있는 대신 백스페이스 키는 그 바로 아래인 2열 오른쪽 끝에 있고요. 누군가는 이 백스페이스 위치가 이상하다고 이야기한 적이 있지만 이 배열을 오랫동안 사용해온 입장에서는 이제 뭐가 문제인지 이해할 수 없었습니다.

하지만 이젠 둘 다 이해합니다. 일단 ESC키가 없으면 불편합니다. 저는 이 키를 눌러 뭐든 닫거나 취소하려고 했습니다. 그리고 백스페이스가 2열에 있는 HHKB가 흔한 배열이 아니라는 것도 이해하게 됐습니다. 다만 둘 중의 하나를 선택해야 한다면 당연히 1열의 1왼편에 ESC키가 있는 배열을 고를 겁니다. 매직키보드는 5열 키보드이면서 ESC키가 없고 불편한 것 맞습니다. 안전 인정합니다. 그리고 이 문제를 회피하려고 틸드 키와 백스페이스 키 위치를 조정한 HHKB의 배열은 흔하지는 않지만 꽤 괜찮은 방법이라고 생각하게 됐습니다.

· 2020-05-10 10:24

서버 장애

문제

며칠 전 저녁에 위키를 구동하는 웹서버 하나가 응답하지 않는다는 사실을 알게 됐습니다. 모니터링 소프트웨어가 슬랙을 통해 메모리 부족 경고 외에도 디스크 응답속도 저하, CPU 점유율 상승 경고를 보내왔습니다. 이미 이전부터 슬랙을 통해 너무 많은 경고를 받고 있어 신경쓰지 않고 있었습니다. 오히려 서버가 돌며 이 정도 메시지는 원래 표시되는 건가 생각하고 있어 왔습니다. 메모리 점유율 문제는 처음 인스턴스를 만들고 나서는 일어나지 않았지만 지난 몇 달 동안 문제가 일어나고 있었습니다. 여러 가지 시도를 하다가 그냥 스왑 크기를 아주 크게 설정해서 서비스가 중단되지는 않는 수준을 유지하고 있었습니다. 더 이상 어떻게 튜닝해야 할지도 몰랐습니다. 다만 지금보다 비용을 늘려 큰 인스턴스를 사용할 생각은 별로 없었습니다. 이런 상황에서 장애가 일어났습니다. 클라우드플레어는 이미 웹서버 다운 페이지를 표시하고 있었고 서버 콘솔에 접근할 수 없었으며 라이트세일 콘솔에서 재시작 버튼이 동작하지 않았습니다. 이 상황에서도 라이트세일 모니터링은 서버 상태를 확인할 수 있다고 주장했고 CPU 사용률이 정상이라고 보고했습니다.

평소 이런 상황일 때 라이트세일 웹 콘솔의 '재시작'은 잘 동작하지 않는다는 것을 알고 있었습니다. '중지'를 누르고 기다린 다음 '시작'을 누르면 서버가 재시작되고 정상으로 돌아왔습니다. 이번에도 그럴 거라고 생각했습니다. 하지만 여러 번 중지와 시작을 반복해도 서비스는 복구되지 않았습니다. 처음 '시작'을 누른 시점부터 원격으로 콘솔에 접근할 수는 있었습니다. 콘솔에 접근해서 상황을 알아볼 작정이었습니다. 일단 디렉토리를 옮기려고 앞 글자를 타이핑한 다음 탭키를 누르자 이전에 본 적 없는 메시지가 나타났고 제가 기대한 나머지 경로가 자동으로 입력되는 동작은 일어나지 않았습니다.

Error: read only file system

상황을 이해하는데 시간이 좀 걸렸습니다. 윈도우를 사용하며 파일시스템 장애를 겪은 적이 있었지만 이런 양상은 아니었습니다. 그래서 이게 파일시스템 장애상황이라는 것을 이해하는데 시간이 필요했습니다. 처음에는 메시지를 보고서도 무슨 상황인지 이해하지 못했습니다. 구글에 에러메시지를 검색해보고 나서야 이게 뭔가 잘못됐고 파일시스템에 장애가 생겼으며 파일시스템 전체가 읽기전용인 상황이고 이로 인해 파일을 써야만 하는 모든 동작 - 가령 로그를 써야 하는 웹서버, 이전에 입력했던 커맨드를 보여주는 쉘 등 - 이 제대로 동작하지 않는 상황을 이해하게 됐습니다.

파일시스템에 문제가 있더라도 일단 인스턴스가 시작됐고 몇몇 커맨드를 사용할 수는 있어 보였습니다. 방법이 있을 거라고 생각했고 정 안되면 새벽시간대에 자동으로 만들어진 스냅샷으로 새 인스턴스를 만들면 해결될 거라고 생각했기 때문에 마음은 편했습니다. 다만 이런 작업을 하며 작업 상황을 기록하는데 사용하던 위키를 사용할 수 없어 엄청나게 답답했습니다.

조사

제 상황과 가장 가까운 것으로 보이는 이 페이지를 따라 시도해보기로 했습니다. 이 글은 EC2 사례지만 라이트세일에도 거의 비슷하게 적용할 수 있을 것 같아 보였습니다. 먼저 상황을 파악해봤습니다.

$ touch file
Error: read only file system

같은 상황이었습니다. 이날 낮까지 웹서버는 정상 동작했습니다. 지금에 와서야 지난 몇 달 동안의 동작이 정상이 아니라는 사실을 알게 됐지만 어쨌든 웹서비스가 동작하는 상태였습니다. 하지만 모니터링 기록을 보니 서버가 이 상태가 되기 몇 시간 전부터 CPU 점유율이 널뛰고 있었고 스토리지 응답속도가 느려지고 있었습니다. 하지만 이전부터 웹서비스의 응답속도는 느린 편이었기 때문에 응답속도 측정 기록으로는 뚜렷한 변화를 파악할 수 없었습니다. 하지만 전반적으로 이전에 비해 상태가 급격히 나빠지고 있었습니다.

CPU utilization xvda1: Disk read rate

상황은 파일시스템에 서비스를 유지한 상태로는 복구할 수 없는 문제가 생겼고 문제를 악화시키지 않는 방법으로 운영체제가 파일시스템을 읽기전용으로 만들어 현 상태를 유지하려는 동작인 것 같았습니다. 해결방법은 윈도우에서 파일시스템에 문제가 생길 때와 비슷했습니다. 파일시스템을 검사해 문제를 해결한 다음 시스템을 재시작하고 문제가 해결됐는지 확인하는 겁니다. 만약 문제가 해결된다면 다행이고 그렇지 않으면 다음으로 넘어가야 할 겁니다. 위 글은 EC2 기준으로 작성되어서인지 글에 언급된 이름과 같은 스토리지 디바이스는 없었습니다. 하지만 이 전에 이 인스턴스에 연결된 스토리지 디바이스 이름이 xvda1이라는 것을 알고 있었습니다.

$ mount -l | grep xvda1
/dev/xvda1 on / type ext4 (ro,relatime,data=ordered) [cloudimg-rootfs]

이 메시지의 핵심은 스토리지 디바이스의 상태가 ro라는 점입니다. 이 화면을 이전까지는 한번도 볼 일이 없었지만 이 디바이스가 제대로 동작하고 있다면 rw라고 나타나야 하는 모양입니다.

시도

$ sudo fsck.ext4 -p /dev/xvda1
cloudimg-rootfs: clean, 375758/7680000 files, 8507918/15728379 blocks

윈도우에서는 chkdsk를 사용했는데 리눅스에서는 fsck라는 유틸리티를 사용헸습니다.

$ mount -l | grep xvda1
/dev/xvda1 on / type ext4 (ro,relatime,data=ordered) [cloudimg-rootfs]

문제가 해결되지 않았습니다. 다시 검색해보니 스토리지 디바이스를 리마운트 해보라고도 되어 있었습니다. 현재 사용중인 하나뿐인 스토리지 디바이스를 어떻게 리마운트 할 수 있는지 잘 이해되진 않았지만 여튼 해봤습니다.

$ sudo mount -o remount, rw /
$ mount -l | grep xvda1
/dev/xvda1 on / type ext4 (rw,relatime,data=ordered) [cloudimg-rootfs]

rw라고 표시됐습니다. 원하는 정확한 상태처럼 보였습니다. 이제 재시작하면 모든 것이 정상화될 것을 기대했습니다. 하지만 여전히 reboot 커맨드는 동작하지 않았습니다. 라이트세일 웹 콘솔에서 인스턴스를 중지시켰다가 다시 실행하고 기다렸습니다. 재시작에는 몇 분이 걸렸습니다.

실패

재시작된 인스턴스의 스토리지 디바이스는 여전히 읽기전용 상태였고 위 과정을 몇 번 더 반복해봤지만 이제 fsck 커맨드를 실행한 다음에도 스토리지 디바이스가 rw상태로 변하지 않았습니다. 이 작업을 시작할 때 수동으로 생성한 스냅샷으로 인스턴스를 재생성해서 같은 작업을 해봤지만 여전히 소용 없었습니다. 그래서 마지막으로 자동 생성된 스냅샷으로부터 약 20시간 정도 변경사항을 유실할 각오를 하고 자동 생성된 최신 스냅샷으로부터 인스턴스를 생성했습니다. 그런데 새로 생성한 인스턴스도 같은 상태였습니다. 웹서버는 실행되지 않았고 스토리지 디바이스는 읽기전용인 상태였습니다. 이제 슬슬 걱정되기 시작했습니다. 나머지 스냅샷 모두 이런 상태일 수도 있었습니다. 만약 그렇다면 상황은 훨씬 귀찮아질 겁니다. 인스턴스가 실행은 되니 일단 파일을 모두 꺼내고 새 인스턴스를 만들어 필요한 소프트웨어를 설치하고 설정한 다음 방금 꺼낸 파일을 복구하는 모든 절차를 생각하니 벌써부터 우울해졌습니다. 이런 걸 하려고 VPS를 사용하기 시작한 것은 아니었는데 말입니다.

어차피 거의 망한 거 조금만 더 테스트해보자 싶어 ap-northeast-2b에 스냅샷으로 인스턴스를 생성해봤습니다. 지금까지는 ap-northeast-2a에서 인스턴스를 운용하고 있었습니다. 그런데 2b에는 아예 스냅샷을 통한 인스턴스 생성이 안됐습니다. 다시 한 번 ap-northeast-2c에 스냅샷으로 인스턴스를 생성했고 이 가용영역에는 인스턴스가 생성됐습니다. 하지만 인스턴스를 생성하고 접근해보니 여전히 스토리지 디바이스는 읽기전용 상태였습니다. 마지막으로 한번 더 fsck를 실행했습니다.

$ mount -l | grep xvda1
/dev/xvda1 on / type ext4 (rw,relatime,data=ordered) [cloudimg-rootfs]

이번에는 재시작도 잘 됐습니다. 웹서버가 실행되기 시작했습니다. 클라우드플레어 보안설정 때문에 자잘한 설정을 바꾸지 않고서는 서비스가 정상 동작하는지 브라우저를 통해 확인할 수가 없었습니다. 그래서 일단 동작하는 것 같으니 바로 클라우드플레어 대시보드에서 아이피를 변경해 새 인스턴스를 연결해봤습니다. 이 시점에서 이전까지 쓰던 고정아이피를 이미 삭제해버렸기 때문에 새 고정아이피를 받아 DNS 설정을 변경해야 했습니다. 사이트는 원래대로 돌아왔습니다. 아무일도 일어나지 않은 것 같았습니다. 모니터링 사이트에도 원래대로 표시되기 시작했습니다.

효과

모니터링 사이트가 이 서버의 디스크립션이 바뀌었고 방금 재시작됐으며 스왑 공간이 50% 미만이라고 동시에 보고했습니다. 이전에 웹서버가 메모리를 반환하지 않고 계속해서 가용 메모리가 줄어들어 스왑파일을 깊숙하게 사용한 다음에야 메모리를 찔끔찔끔 반환하는 문제가 있었습니다. 이 상황을 해결해보려고 이것저것 찾아보고 남들이 하는 튜닝을 시도했으나 예상보다 적은 효과에 스왑 크기를 크게 잡아 대응하고 있었습니다. 스냅샷으로 인스턴스를 생성해보니 스왑파일이 없어져 있었고 그래서 문제를 보고한 것이었습니다. 이제 생각해보니 원래 이 크기의 인스턴스는 스왑이 0이었습니다. 그래서 일단 스왑을 이전과 똑같이 크게 설정해 모니터링 사이트의 보고를 해결했습니다.

이상한 일이 일어났습니다. 한동안 모니터링해보니 웹서버 설정은 딱히 바뀐 것이 없었는데 웹서버가 이전과 달리 메모리를 제때 반환해 가용 메모리가 충분한 상태로 유지됐습니다. 한동안 더 살펴보다가 웹서버가 더 늦게 메모리를 반환하도록 설정을 조금씩 바꿔봤습니다. 이전에는 이렇게 설정하면 사용 메모리를 모두 소진하고 스왑파일 깊숙한 곳까지 사용해 응답속도가 떨어지곤 했는데 이번에는 같은 설정에 스왑 근처에도 가지 않았습니다. 아무리 생각해도 이건 인스턴스를 새로 생성한 효과처럼 보였습니다.

추측

모니터링 소프트웨어를 사용하기 시작한지 이제 몇 달 쯤 지났는데 이전 인스턴스를 사용할 때와 새 인스턴스를 사용할 때 값이 어떻게 다른지 긴 시간에 걸쳐 비교해보기 시작했습니다. 뭔가 이상한 점이 있었습니다.

Details of web scenario Speed Details of web scenario Response time

지난 몇 달에 걸쳐 웹서버의 응답속도가 서서히 감소하고 동시에 응답시간이 계속해서 서서히 증가하고 있었습니다. 그러다가 몇 시간 동안 장애를 겪은 다음 새 인스턴스에서는 이 현상이 모두 사라졌습니다. 심지어 새 인스턴스는 이전 인스턴스를 만들어 처음 모니터링을 시작할 때보다 훨씬 상태가 좋았습니다. 속도와 응답속도 양쪽 모두 빨랐습니다. 잠깐 동안은 인스턴스 플랜을 잘못 선택한 줄 알았습니다. 그것도 아니었습니다.

Available memory Free swap space

서비스를 중단시키지 않으려고 크게 설정해둔 스왑 역시 전혀 사용하지 않고 있었습니다. 이 모든 상황으로 미루어 인스턴스 자체에 내가 파악할 수 없는 어떤 문제가 있었고 이 문제로 인해 성능 저하가 일어난 끝에 장애가 발생했으며 같은 가용영역에 인스턴스를 생성해도 같은 장애가 일어났습니다. 하지만 다른 가용영역에 인스턴스를 생성하자 문제를 더이상 겪지 않게 된 것 같습니다.

교훈

모니터링 소프트웨어는 지난 몇 달에 걸쳐 지속적으로 성능이 감소하는 상태를 기록해 왔습니다. 하지만 모니터링 소프트웨어의 보고 체계는 짧은 시간 안에 급격한 변화가 일어날 때 알려주도록 되어 있었습니다. 가령 지난 몇 분 동안 CPU 사용률이 높다든지 가용 메모리가 20% 미만으로 감소한다든지 스토리지 디바이스가 몇 초에 걸쳐 응답이 느려질 때 보고했습니다. 하지만 이렇게 긴 기간에 걸친 성능의 변화는 보고 대상이 아니었습니다. 하지만 이제와서 그래프를 보면 뭔가 서서히 잘못돼 가는 상황을 알 수 있었습니다. 모니터링 소프트웨어를 좀더 둘러보고 이렇게 장기간에 걸친 변화를 별도로 보고할 규칙을 만들 수 있는지 알아봐야겠습니다. 가령 월 단위로 두달 전 평균과 한달 전 평균을 비교해 차이가 있다면 별도로 보고하게 해야 합니다.

웹서버를 클라우드플레어 뒤에 놓고 운용해 왔습니다. 저 같은 초보자가 라이브 서비스하는 웹서버를 잘 관리할 가능성은 없기 때문에 클라우드플레어가 웹서버 앞에서 여러 가지 문제를 미리 해결해 큰 도움을 받고 있습니다. 하지만 장애상황에서는 클라우드플레어의 보안 설정을 충실히 이행한 덕분에 웹 프론트엔드에는 접근조차 할 수 없었습니다. 오리진 서버는 클라우드플레어의 알려진 아이피로부터만 접근을 허용했고 유효한 오리진 인증서를 사용해야만 했고 클라우드플레어로부터의 요청에는 항상 약속한 인증서만을 사용해야 했습니다. 여기에 로그인이 필요한 영역은 지정된 VPN을 통해야 하고 클라우드플레어 액세스를 통해 인증을 받은 다음 1시간마다 변경되는 유효한 토큰을 유지해야 했습니다. 평소에는 이런 설정들에 딱히 문제가 없었지만 장애상황에서는 이 설정 대부분을 변경하지 않고서는 상황파악조차 할 수 없었습니다.

기존에는 모니터링서버와 웹서버가 같은 ap-northeast-2a 가용영역에 있었는데 이번 장애를 겪으면서 웹서버를 ap-northeast-2c 가용영역으로 옮기면서 가용영역 장애에 동시에 고장나지 않게 됐습니다. 잠깐 동안 모니터링서버가 아예 다른 데이터센터에 있으면 어떨지 생각해봤는데 지금은 서버 사이에 프라이빗 아이피로 통신하고 있으므로 여기저기 손을 대야 할 것 같아 일단 그렇게까지는 아지 않기로 했습니다.

거의 가지고 놀 목적으로 운용하는 웹서버에 비용을 더 들이기는 꺼려지지만 이런 장애상황을 줄이기 위해서는 결국 서버를 이중화하고 앞에 로드밸런스를 붙여야 할 것으로 보입니다. 라이트세일에서는 로드밸런스 서비스가 월 18달러 정액제이고 클라우드플레어에서는 월 50만 쿼리까지 5달러입니다. 하지만 이쪽은 생각만 하고 실행하지는 않을 작정입니다. 라이트세일의 로드밸런스 비용은 장애가 일어난 웹서버 비용보다 더 비쌉니다. 언젠가 이런 체계가 꼭 필요한 시점이 오면 실행할지도 모르지만 지금은 아닙니다.

다만 다음에 비슷한 문제가 일어나면 모니터링 소프트웨어로부터 미리 보고를 받을 수 있도록 설정하고 장애가 일어날 때 이번처럼 우왕좌왕하지 않고 그냥 따라할 수 있도록 매뉴얼을 만들어놓는 정도로 마무리할 작정입니다. 또 백업을 스냅샷에만 의존하는 대신 다른 스토리지 디바이스를 붙여서 파일 단위로 꺼낼 수 있게 준비해둘지도 고민중입니다.

· 2020-05-09 19:19

둠 이터널

이번 둠은 그 이름이 아니었다면 크게 관심을 갖지 않았을 수도 있었습니다. 하지만 이제 인정합니다. 이건 둠이고 둠의 후속작이 맞으며 플레이어가 누구라도 이 게임에서 살아남고 나면 극도로 공격적이고 강한 슬레이어가 되어 있을 겁니다. 이젠 2018년 퀘이크콘에서 함성을 지르던 아저씨들을 이해합니다. :)

이렇게 말하는 스스로가 좀 웃기긴 하지만 FPS 게임을 좋아하지만 잘 하지는 못합니다. 시대를 주름잡는 FPS를 오랜 시간 플레이하지만 멀티플레이에서는 항상 어처구니 없는 플레이를 반복해 FFA밖에 할 수 없는 인생입니다. 하지만 그러면서도 여전히 FPS를 좋아합니다. FPS 장르만큼 본능적인 반응을 이끌어낼 수 있는 장르가 드물다고 생각하기도 하고 또 FPS만큼 긴 역사를 가지고 여러 가지 표현 방법을 연구한 장르 역시 드뭅니다. 여기에 둠은 이 장르를 발명해낸 사람들의 가장 유명한 게임 프랜차이즈입니다. 그렇게 둠에 열광했지만 또 한편으로는 둠3에서 좀 실망했고 4년 전 둠 리부트 때는 또 꽤 괜찮았습니다. 이제 이름이 같을 뿐 현대의 둠은 과거와는 완전히 다른 게임이지만 둠이 발명해냈고 또 여전히 그 플레이를 온전히 복제해낸 게임이 드문 시대에 둠이 둠 답게 이름 뒤에 불길하기 짝이 없는 접미사를 달고 나타나자 다시 관심을 가질 수밖에 없었습니다.

프로젝트 이름 뒤에 이런 불길한 단어를 달고 별 탈 없이 출시한 게임은 드물었습니다. 가령 듀크뉴캠 포에버는 흥미로운 소재와 시스템에도 불구하고 너무 오랜 기간에 걸쳐 개발했고 나중에는 개발팀으로부터 에셋이 유출되어 구직시장에 돌아다니는 수모를 겪었습니다. 결국 게임이 출시됐지만 스팀에서 정가가 유지된 시간은 정말 짧았고 저 역시 할인에 할인을 거듭해 5달러가 됐을 때 구입했습니다. 게임의 여러 부분이 듀크뉴캠의 분위기에 어울렸지만 근본적으로 이건 사려깊게 만든 FPS가 아니었습니다. 엔딩은 고사하고 몇십분쯤 견디다가 - 플레이한 것이 아님 - 그만뒀고 그 후로는 도저히 손을 댈 수가 없었습니다. 이 이상은 언급하지 않겠지만 이런 이름을 게임 이름이나 프로젝트 이름에 사용한 여러 게임들의 결말은 하나같이 별로 좋지 않았습니다. 그런 업계의 불길한 역사에도 불구하고 이 불길한 이름을 소화할 수 있는 게임은 사실 둠 밖에 없었다고 생각합니다. 이 불길한 단어를 붙일 게임 이름조차도 둠이니까요. 혹시나 출시하지 못하면 어쩌나 했는데 결국 게임은 출시됐고 둠 이터널은 … 그냥 최고입니다.

플레이스타일

둠 이터널은 4년 전에 출시한 둠과 비슷하지만 플레이해보면 완전히 다른 게임입니다. 이전 둠이 모던 FPS에 '둠'의 플레이를 온전히 재현하는데 성공했다면 둠 이터널은 이제 플레이어에게 슬레이어처럼 움직일 것을 강제합니다. 내가 공격적으로 플레이할 수록 게임은 내게 더 많은 기회와 힘과 탄약을 제공해줍니다. 평소에 FPS를 플레이하듯 소극적으로 플레이할수록 나는 점점 더 힘들어지고 사실상 게임을 진행할 수 없는 상황이 됩니다. 둠과 둠 이터널 양쪽 모두 가장 좋아하는 순간은 슬레이어의 헬멧을 발견하고 앞뒤로 돌려 살펴본 다음 이걸 뒤집어쓰는 장면입니다. 이 장면이 나오기 전까지는 모니터 앞에서 약간 흐트러진 자세를 하고 있었다면 헬멧을 쓴 다음부터는 의자를 좀 더 당겨 고쳐 앉고 입을 다물고 마우스를 고쳐 쥐고 지옥에서 나타난 악마를 씹어먹을 준비를 합니다. 헬멧을 쓰기 전에는 웃으며 글로리킬을 했다면 헬멧을 쓴 다음부터는 정말 슬레이어의 표정이 내 표정에 나타납니다. 진짜 슬레이어의 표정은 헬멧에 가려 눈밖에 보이지 않지만요. 스테이지를 거듭할수록 중간중간 실수는 있지만 나는 점점 더 공격적으로 플레이하고 이건 정말 신나는 경험이었습니다. 전작에서 '세상에 나만큼 조심스러운 슬레이어는 없을 거야'라고 자조하며 플레이했다면 이제는 '어디냐! 나와! 나와! 나와! 나오라고!'라며 플레이하는 자신을 발견하게 됩니다. 플레이어에게 이 슬레이어스러운 플레이를 강제하는 구성이 훌륭합니다.

레벨디자인

클래식한 레벨디자인은 이제 전투 영역 하나하나를 FFA모드 멀티플레이 레벨과 비슷하게 만들었습니다. 개인적으로는 밀리터리 FPS들이 나타나면서 레벨이 좀 더 수평 형태로 바뀌었다고 생각합니다. 플레이어의 움직임은 좀 더 무거워지고 보다 천천히 움직이며 장면 사이를 전환할 때 긴장감을 유지하는 장치들을 사용합니다. 이런 게임에 익숙해지다 보니 같은 게임에서 위 아래로 긴 레벨을 만날 때 잠깐 동안 여기에 적응하지 못하기도 했습니다. 하지만 둠의 시대가 지나고 퀘이크의 시대가 시작되면서 레벨은 수직 구조가 강조된 경우가 많았습니다. 계속해서 위, 아래로 움직여야 하고 플레이어가 있는 그 층 뿐만 아니라 바로 위 아래 층, 나아가 반대쪽 구조물의 다른 층에도 동시에 신경쓰며 플레이하게 만들었습니다. 이번 둠은 이런 레벨디자인을 더 강조했습니다. 동시에 핵심 전투가 일어나는 각 공간을 멀티플레이 레벨처럼 구성해 앞에서 이야기한 보다 공격적인 플레이에 더 어울리도록 구성했습니다.

둠 다운 기믹

여러 가지 인상적인 기믹이 있습니다. 여러 기믹이 처음부터 끝까지 일관적인 규칙으로 사용되는 점은 수많은 레벨이 등장하는 MMO 게임을 만드는 입장에서 교훈으로 삼아야 합니다. 가령 점프대는 어느 레벨에서나 점프대처럼 생겼고 매달릴 수 있는 벽은 어느 레벨에서나 똑같이 생겼습니다. 올라가도 안전한 곳은 항상 녹색으로, 그렇지 않은 곳은 붉은색으로 표시됩니다. 개발하다 보면 종종 레벨마다 분위기를 유지하기 위해 같은 역할을 하는 기믹의 겉모양이나 애니메이션을 바꿔 고객들을 혼란에 빠뜨리는 일이 자주 일어나는 세계에서 개발하는 입장에서 이 일관성있는 기믹 사용은 인상적이었고 또 부러웠습니다.

이번 둠에서 가장 인상적인 기믹은 개사 손으로 쳐서 무너뜨릴 수 있는 벽입니다. 레벨의 공간과 공간을 연결하는 기믹은 여러 게임에 있었습니다. 가령 자동으로 여닫히는 문이나 엘리베이터 같은 것들입니다. 이들 각각은 게임의 장르나 상황에 따라 사용되었고 또 바이오해저드에서처럼 기술적인 한계를 게임의 일부로 풀어내기도 했습니다. 이들 모두는 공간을 연결하는 역할입니다만 이번 둠에서는 이 공간 사이를 시각적으로 차단하고 다음 공간을 내 인터랙션에 의해 개방하는 기믹을 슬레이어의 스타일로 만들었습니다. 자동문은 내가 조심스럽게 다가갈 수 있고 엘리베이터는 그 스스로 움직여 나를 수동적으로 다음 공간에 데려다주는 기믹이라면 이 부술 수 있는 벽은 슬레이어가 적극적으로 파괴해야 합니다. 둠에서 이 부술 수 있는 벽은 '이 다음엔 뭐가 있을까?' 정도로 기대를 가지는 수준이 아니라 '다음은 누구냐 이 새끼들아' 같은 느낌에 더 가깝습니다. 슬레이어는 적극적으로 벽을 부수고 다음 공간을 시각적으로 개방한 다음 플레이를 계속합니다. 다른 여러 가지 서로 잘 구분되는 기믹들이 있음에도 불구하고 이 무너지는 벽은 가장 둠 다운 기믹입니다.

결론

이번 둠은 그 이름이 아니었다면 크게 관심을 갖지 않았을 수도 있었습니다. 하지만 이제 인정합니다. 이건 둠이고 둠의 후속작이 맞으며 플레이어가 누구라도 이 게임에서 살아남고 나면 극도로 공격적이고 강한 슬레이어가 되어 있을 겁니다. 이젠 2018년 퀘이크콘에서 함성을 지르던 아저씨들을 이해합니다. :)

· 2020-05-02 20:38

의존성

후방 레이더가 꽤 의미있는 만큼 생각보다 더 많이 의존하고 있었습니다. 완전히 멈췄다가 내리막을 내려갈 때는 출발 전에 헤드유닛을 확인해 후미등이 인식된 상태인지 확인해야 합니다.

지난 3월에 가민에서 나온 레이더가 달린 후미등을 사용하기 시작했습니다. 처음 두어번 사용해본 다음 완전히 마음에 들었고 모든 자전거에 거치대를 설치했습니다. 그리고 기존에 사용하던 강력한 문라이트 네뷸러 후미등도 함께 달고 다니기 시작했습니다. 코너가 많은 오르내리막에서는 안 그렇기도 했지만 대부분은 뒤에서 자동차가 접근할 때 소리를 듣기 전에 먼저 헤드유닛에 경고가 뜨고 내가 뒤를 돌아보며 상황을 확인한 다음에야 소리가 들리기 시작했습니다. 이전보다 훨씬 먼저 뒤에서 오는 차를 알고있을 수 있었습니다. 또 내가 확인할 수는 없었지만 차량이 접근해 오면 더 밝게 깜빡여 경고한다고 합니다. 모르긴 몰라도 이 장치가 뒤에서 접근하는 운전자들에게 짜증을 유발해 저를 인식하게 한 적이 분명 있었을 겁니다. 그렇게 기계에 제법 의존하기 시작했습니다.

얼마 전에 동부 5고개를 돌고 마지막에 유명산에서 아신역 방향으로 내려오기 시작했는데 출발하고 한 30초쯤 지나서 가민 헤드유닛에 후미등이 연동되지 않았다는걸 알게 됐습니다. 중간에 좀 긴 시간동안 쉴 때 헤드유닛과 후미등 양쪽 모두 꺼 놓는데 종종 다시 켤 때 후미등이 헤드유닛에 인식되지 않는 일이 있었습니다. 그래서 출발하기 전에 상태를 확인하고 만약 인식되지 않았다면 후미등을 껐다 켜곤 했습니다. 그런데 내리막을 시작하고 나서야 이걸 알게 된 겁니다.

화면 오른쪽 위에 레이더 표시

저는 오르막을 좋아하지만 반대로 내리막은 좀 무서워합니다. 엘리트 사이클리스트들의 경기를 보면 내리막에서 고양이자세를 하고 저러다 낙차하는 거 아닌가 싶을 정도로 낮은 각도를 유지하곤 합니다만 내리막은 아무래도 무서워서 빌빌거리며 시속 40-45킬로미터를 유지하고 그나마 커브가 나타나면 훨씬 더 속도를 줄이곤 합니다. 당연히 유명산 내리막에서도 똑같이 내려올 작정이었지만 속도는 제법 붙어있었고 노면 상태가 아주 나빴고 자동차들이 자주 중앙선을 넘기 때문인지 중앙선에 폴이 박혀 있어 추월은 불가능했습니다. 이런 상황에서 내리막을 내려가면 자동차들은 대부분 자전거 뒤에 바짝 붙어 위협운전을 합니다. 이 상황에 후방 레이더가 사라져 상황을 알 수 없게 된 겁니다.

평지에 내 힘으로 가속하는 중이거나 노면 상태가 더 나았다면 별 일 없이 뒤를 돌아보고 상황을 확인할 수 있었을텐데 노면이 나빴고 내리막인데다가 커브가 많았습니다. 도무지 뒤를 돌아볼 엄두가 안 났습니다. 그리고 뒤에 차 소리는 멀어졌다 가까워졌다를 반복했지만 바람소리에 차량 위치를 정확히 파악하기도 어려웠습니다. 그나마 비슷한 상황에서 헤드 유닛에 표시되는 후방 상황과 같은 차량이라도 커브를 돌며 사라졌다가 다시 나타날 때 소리로 다시 경고해줘서 크게 도움을 받아 왔는데 이게 사라지자 평소보다 훨씬 더 무서웠습니다. 어차피 뒷 차는 안전거리 유지 없이 최대한 바짝 붙어 따라오고 있을테니 낙차하면 뒷 차에 깔려 죽거나 코너에서 감속을 안하면 낭떠러지에 떨어져 죽을테니 이판사판이다 싶어 뒷 차를 무시하고 도로 중앙으로 내려갔습니다만 여전히 노면이 나빠 무서움이 가시지는 않았습니다. 그렇게 내리막을 내려와 아신역 방향으로 완전히 접어들기 전에 근처 카페에 들려 잠깐 진정한 다음 출발해야만 했습니다.

이 날의 교훈은 후방 레이더가 꽤 의미있는 만큼 생각보다 더 많이 의존하고 있었고 특히 완전히 멈췄다가 내리막을 출발하기 전에 헤드유닛을 확인해 후미등이 인식된 상태인지 확인해야 한다는 것입니다.

· 2020-05-02 23:45

발할라

엊그제 어쌔신크리드 신작 영상을 봤습니다. 이제 이집트 말기와 그리스 시대를 거쳐 바이킹들의 시대로 갑니다. 영상은 전체가 시네마틱입니다. 실제 게임 장면은 단 한 장면도 포함되지 않았습니다. 많은 게임들이 시네마틱 광고와 실제 게임 사이에 거대한 갭 때문에 나쁜 평가를 받기도 합니다. 분명 시네마틱에서는 좀 더 많은 멋진 일들을 할 수 있을 것 같아 보였지만 실제 게임은 시네마틱과는 1억광년쯤 떨어진 제한되고 갑갑한 플레이만 할 수 있는 일이 흔합니다. 그런데 어쌔신크리드 발할라 시네마틱은 그런 느낌과는 거리가 멀었습니다. 이미 전작들로부터 이 시네마틱의 각 부분들을 어떻게 플레이할 수 있을지 충분한 힌트와 신뢰를 쌓아둔 상태이기 때문입니다. 전작을 출시한 시점4)으로부터 아직 만 2년이 채 지나지 않은 지금 이들의 신작 트레일러를 보고 이 게임이 출시될 즈음에 대비해 휴가를 충분히 남겨둬야겠다고 생각하면서 크게 두 가지가 부러웠습니다. 너무 부러워서 열받습니다. 하나는 신뢰, 다른 하나는 프로젝트의 연속성입니다.

신뢰

신작 트레일러는 실제 게임 플레이가 전혀 포함되지 않았습니다. 사실 우리들끼리는 이렇게 말하곤 합니다. 에이 저거 다 사기잖아요. 저 시네마틱 중에 실제로 플레이와 관련된 장면은 단 하나도 없을 거라고요. 시작할 때 검게 하늘을 뒤덮는 드래곤과 싸우며 드래곤과 나 사이에 있는 성들이 박살나고 불타오르는 폐허 가장자리를 이리 저리 건너뛰며 물리법칙을 무시한 채 칼을 휘두르는 시네마틱은 곧 식상한 카메라 시점에 저 앞에 깜빡이는 목표지점까지 이동하고 오른손 엄지손가락으로 스킬 버튼을 터치해 제한된 뷰 안에서 스킬을 사용하는 뻔한 플레이로 바뀌는 경험을 여러 번 하다 보면 꽤 많은 비용을 들여 제작했을 것 같은 광고용 시네마틱 앞에 감흥이 없어지고 '아이구 이분들 또 헛돈 썼구만' 하는 생각이 들 뿐이었습니다.

하지만 이 영상을 보고는 그렇게 생각하지 않았습니다. 어두운 바다를 가로지르는 저 장면이 게임에 어떻게 나올지 알고 있습니다. 전작에서 그렇게 바다를 가로질러봤거든요. 그 바다를 떠다니는 경험은 정말 괜찮았습니다. 잉글랜드의 병사들과 싸우는 장면은 어떤가요. 이렇게 많은 사람들이 동시에 전투를 벌이는 전장 한복판에서 내가 상대를 찾아 전투를 벌이는 경험이 어땠는지도 알고 있습니다. 저 강력한 기사 뒤로 빛나는 저녁 해가 정말로 저렇게 반짝이며 또 그와 어떻게 싸울지, 배를 몰아 육지에 다다를 때 아름답게 빛나는 저 모습이 정말로 게임 안에서도 그렇게 보인다는 사실도 알고 있습니다. 새로운 배경의 새로운 게임이지만 또 한편으로는 시네마틱의 각 부분들이 실제 게임의 실제 플레이와 아주 멀지 않다는 사실을 알고 있습니다. 그래서 다른 여느 시네마틱과 다르게 영상을 보며 큰 기대를 가지게 됐습니다. 예약 주문 가능하게 되면 당연히 시즌패스를 포함한 전체 버전을 구입할 생각입니다. 이 선택은 전작, 전전작에서 그리 나쁜 선택이 아니었고 이번에도 그리 나쁜 선택이 아닐 것이며 50에서 100시간쯤을 신나게 보낼 수 있는데 비하면 그리 큰 금액도 아닙니다.

연속성

전작을 발표한 시점으로부터 아직 만 2년이 채 지나지도 않았습니다. 연말 즈음에 출시할 모양이니 실제로는 2년보다 더 긴 시간동안 개발했을 것이 분명합니다만 전작들로 미루어 이 짧은 시간 동안에 이전만한 스케일로 게임을 개발할 수 있다는 점은 대단합니다. 이 정도 시간을 들여 이 정도 완성도와 스케일을 가진 게임을 개발한다는건 우리들 입장에서는 아직까지 그 근처에도 갈 수 없을만큼 엄청난 일입니다. 심지어는 이런 개발을 반복한 락스타조차도 신작의 출시 시점 스케일을 고민5)하고 있을 정도라고 하니까요.

한편으로는 그들이 어떻게 이런 업적을 달성하는지 최소한의 방법을 이해합니다. 일단 서로 다른 여러 스튜디오에서 게임을 번갈아가며 개발해 비즈니스 관점에서 유효한 출시 시점을 유지하고 한 프로젝트에서 개발한 개발경험, 구현체, 도구, 에셋을 다음 프로젝트에 사용하는 겁니다. 거대한 스케일의 도시를 더 빨리 만들기 위해 반복되는 건물 벽을 자동으로 그럴듯하게 칠하는 브러시를 개발하고 레벨디자인과 퀘스트라이팅 작업이 서로 충돌하지 않는 파이프라인을 구축하도록 도구를 개발해둡니다. 이 도구들은 다음 프로젝트의 출발점에 이미 완성되어 있고 아마도 새로운 프로젝트의 요구사항에 맞춰 적당히 튜닝될 겁니다. 바닥부터 시작하지 않았을 테고 비교적 짧은 개발기간 동안 더 많은 결과를 만들어낼 수 있습니다.

우리들

우리들의 생산성이 그렇게 낮지 않고 또 우리들의 개발 수준이 그렇게까지 낮지는 않다고 생각해 왔습니다. 다른 유명한 개발사들이 종종 공개하는 자신들의 고민과 해결방법을 볼 때마다 그렇게 생각했습니다. 하지만 결과를 놓고 보면 그들은 고객들의 기억에 남을 게임을 만들고 우리는 종종 그렇지 않습니다. 어쩌다 고객들의 기억에 남기도 하지만 그 기억이 긍정적이지 않을 때도 있었습니다. 고객들에게 우리가 만든 게임은 이전의 다른 게임들과 별로 다르지 않고 또 비즈니스 관점에 지나치게 매몰된 결과물로 인식되곤 했습니다.

우리들이 항상 비슷한 게임을 비슷한 수준으로 개발하는 근본 원인은 우리가 항상 아무것도 없는 맨바닥에서 서로 일해본 적 없는 사람들과 완전히 새로 시작하는 점입니다. 프로젝트가 종료되면 우리들의 고용도 함께 사라지고 새로운 스폰서를 찾아 새로 팀을 꾸려 새로운 프로젝트를 시작합니다. 이전 프로젝트나 이전 회사와 법적 분쟁을 피하기 위해 가장 간단한 기능조차도 바닥부터 다시 만들어야 합니다.6) 이제는 너무 많이 만들어봤고 또 너무 많은 시행착오를 겪어 거의 정답을 만들어낼 수 있을 법한 데이터 파이프라인부터 시작해서 이런 장르 게임에는 당연히 있을법한 모든 시스템을 처음부터 설계하고 다시 만들기를 반복합니다. 게임을 완성할 때까지 스폰서가 기다려줄 수 있는 시간과 돈은 한정되어 있으므로 바닥부터 만들기 시작해 이 기간 안에 완성한 게임의 수준은 대체로 비슷합니다. 새로 출시되는 여러 게임이 항상 비슷한 수준을 유지하는 이유는 여기에 있습니다.

개발 중에 이전 경험으로부터 나온 개선이 없는 것은 아닙니다. 고객의 관점에서, 또 비즈니스 관점에서 여러 개선이 포함되어 있습니다만 이런 개선은 항상 새로 구축한 그리 단단하지 않은 시스템 위에서 부족한 고민과 시도에 의한 낮은 평가를 받습니다. 당연합니다. 개발기간 대부분을 다른 게임과 비슷한 수준을 갖추는데 사용하고 그 사이사이에 짧은 기간 동안 진행된 개선이 시장이나 고객들의 눈에 만족스러울 가능성은 낮습니다. 이 과정이 반복되며 우리는 신뢰를 잃었고 신뢰를 구축한 프로젝트와 그렇지 않은 프로젝트 사이에 거대한 갭이 생겼으며 신뢰를 다시 구축하는데는 신뢰를 잃으며 보낸 기간보다 더 긴 기간이 필요해졌습니다.

결론

우리들 각각이 이 상황을 개선할 방법은 많지 않아 보입니다. 다만 프로젝트가 중단되어 우리들의 고용이 사라지기 전에 최소한 같은 회사 안에서 같은 사람들이 새 프로젝트를 계속해 법적인 문제를 최소화하는 범위 안에서 이전에 구축한 최대한 많은 구현물과 에셋들이 새 프로젝트에 이어지도록 행동하는 것이 당장 개개인들이 할 수 있는 일입니다. 그 다음은 스폰서나 회사 차원의 과제가 남아있습니다.

· 2020-05-02 18:22

오래된 항목 >>

blog/start.txt · 마지막으로 수정됨: 2020-05-21 01:29 저자 neoocean