사용자 도구

사이트 도구


사이드바

blog:start

브레베 데이터베이스

발단 - 포켓몬 데이터베이스

몇 주 전에 타임라인에서 Notion Pokédex를 봤습니다. 노션 페이지에 포켓몬을 타입 별로 정보를 볼 수 있고 포켓몬 한 종류의 정보를 한 페이지에 나열해 볼 수도 있었습니다. 이 페이지의 중요한 특징은 정보를 페이지에 정적으로 입력하는 대신 내부에 데이터베이스를 두고 각 페이지에서는 이 정보를 조회한 결과만을 보여주고 있다는 점입니다. 이렇게 구성해두면 새로운 포켓몬이 추가될 때 편리하게 대응할 수 있고 일부 정보만 조회한 결과로 새로운 페이지를 만들 수도 있었습니다. 그렇잖아도 한국랜도너스 웹사이트에서 지난 시즌 브레베1) 정보가 종종 삭제되어 아쉽다고 생각하는 중이었고 페이지에 정적으로 입력된 일정과 이벤트 정보는 그 상태로만 조회할 수 있었습니다. 그래서 노션 포켓몬 데이터베이스와 비슷한 것을 흉내내보기로 했습니다.

환경

비슷한 것을 만들기로 했지만 노션을 사용하지는 않기로 했습니다. 이미 오랫동안 사용해 온 위키가 있었고 비슷한 역할을 하는 struct라는 플러그인이 있다는 것을 이미 알고 있었습니다. 이 플러그인은 SQLite 데이터베이스를 조회한 결과를 위키 페이지에 표시하는 기능을 합니다. 노션처럼 아름답고 우아한 모양은 결코 아닐테지만 기능상으로는 비슷할 거라고 예상했습니다. 하지만 플러그인과 SQLite 양쪽 모두 처음 사용해보는 입장이라 어디까지 가능하고 또 어디부터 가능하지 않을지 파악하지 못하는 상태로 시작했습니다.

테이블 구성

일단 테이블 구조를 생각해 두기로 했습니다. 브레베 이벤트는 각 지역 별로 서로 다른 코스에서 진행됩니다. 코스는 이 코스를 주행했음을 증명할 컨트롤 포인트(CP라고 부름)의 집합으로 구성되어 있고 각 컨트롤 포인트는 이곳에서 해야 할 행동이 있습니다. 대부분은 편의점에서 도장을 받지만 사진을 찍거나 그 위치에서만 알 수 있는 정보를 적어가야 할 때도 있습니다. 웹사이트에서는 이 코스를 여러 가지 데이터를 통해 제공합니다. GPX 파일과 RwGPS 주소, 구글맵 경로 주소 등을 매 코스마다 제공합니다. 또 코스 하나는 같은 지역의 서로 다른 날짜에 지정되어 서로 다른 이벤트에 사용됩니다.

몇 가지 생각할 점이 있었습니다. 일단 같은 코스가 여러 이벤트에 사용되는데 종종 이전에 사용된 코스를 다음 이벤트에 재사용하면서 테스트라이딩 결과에 따라 코스를 변경할 때가 있습니다. 그러면 이전에 이 코스를 사용하던 이벤트의 코스정보도 변경되곤 했습니다. 가령 3월과 8월에 같은 코스를 달리는 이벤트가 있는데 7월에 테스트라이딩을 해보니 공사구간이 많아 경로를 변경하고 이를 정적인 페이지에 반영해버리면 이 코스를 사용하는 3월 이벤트에도 변경된 코스가 나타나곤 했습니다. 이 상황을 없애고 싶었습니다. 또 컨트롤 포인트의 목록을 이미지 파일로 제공하는데 브레베 전에는 항상 각 컨트롤 포인트의 이름과 이들 사이의 거리, 예상 주행속도에 따른 목표 도착시각을 기록한 표를 만들었습니다. 시각정보를 제외하고서라도 컨트롤 포인트 목록을 이미지 대신 텍스트와 테이블로 전달하고 싶었습니다.

이런 생각을 좀 더 고려해서 테이블을 고쳤습니다. 여기까지 하고 보니 브레베 이벤트 데이터를 안전하게 보관할 수 있을 것 같아 보였지만 별도로 입력 페이지 코드를 작성하지는 않을 작정이라 입력이 편하지 않을 것 같다는 걱정을 하기 시작했습니다.

데이터베이스

제가 다뤄본 데이터베이스는 MySQL 딱 하나입니다. 회사에서는 항상 다른 데이터베이스를 사용했는데 그건 엔지니어들의 몫이었으므로 제가 그 데이터베이스를 직접 다룰 일은 없었습니다. 그런데 이번에 사용할 struct 플러그인은 SQLite를 지원하므로 이 데이터베이스를 사용할 수밖에 없었고 기존에 알고 있던 데이터베이스와 뭐가 다른지 알아둬야 했습니다. 일단 애초부터 다른 애플리케이션에 임베딩 할 용도이고 데이터타입 종류가 적은 점이 눈에 들어오는 특징이었습니다. 하다못해 enum 타입을 따로 정의할 수 없었습니다. 이를 엄격하게 적용한다면 enum에 해당하는 별도 테이블을 만들어야 했고 느슨하게 적용한다면 텍스트 타입으로 만든 다음 enum에 해당하는 값을 그냥 텍스트로 넣어버릴 수도 있어 보였습니다. 느슨한 정책을 사용하기로 했습니다.

struct 플러그인

도쿠위키 페이지에 SQLite 데이터베이스를 조회한 결과를 표시하기 위해 struct 플러그인을 사용했습니다. 이 플러그인은 SQL과 비슷하지만 무척 제한적인 전용 문법을 통해 데이터베이스를 조회할 수 있습니다. 이 플러그인을 사용해 스키마를 입력하면 플러그인에 의존성을 가짐과 동시에 몇 가지 도움을 받을 수 있습니다. 위에서 이야기했던 enum 칼럼을 쉽게 만들 수 있습니다. 내부 타입은 그냥 텍스트이지만 이 플러그인이 중간에서 입력을 제한해 줍니다. 또 날짜시간 타입을 사용할 수 있고 URI 타입으로 칼럼을 생성하면 여기에 기입한 텍스트를 조회하면 자동으로 링크를 만들어줍니다. 게다가 미디어 타입은 미디어를 위키 시스템을 통해 업로드한 다음 이를 링크하는 구성이어서 굳이 BLOB 타입을 사용할 필요가 없을 뿐 아니라 최대한 위키에 호환성을 유지하는데도 도움이 될 것 같아 보였습니다.

문제

하지만 테스트 데이터 몇 개를 입력해놓고 출력 페이지를 만들기 시작한지 1분만에 문제가 생겼습니다. struct 플러그인은 데이터베이스 조회 결과를 항상 '테이블 모양' 또는 '리스트 모양'으로만 표시할 수 있었습니다. 아마도 개발자는 이거면 충분할 거라고 생각한 모양입니다. 실제로 저 두 가지 표현방법으로 데이터를 표현할 수 있었습니다. 하지만 정보를 전달하는 웹페이지를 만드는 것은 다른 이야기였고 저는 조회 결과를 '값 하나'로만 얻기를 원했습니다. 검색해보니 이미 저와 똑같은 의견을 가진 사람들이 'Struct data as variables'에 의견을 주고받고 있었을 뿐 아니라 'Value aggregation type'에 풀리퀘스트도 있었습니다. 다만 마지막 활동이 거의 1년 전이라 언제 적용될지 알 수 없었습니다. 급한 성격에 이 코드를 바로 적용했습니다. 이참에 미뤄뒀던 서버에 적용할 위키 코드를 깃헙 리파지토리로부터 배포할 수 있게 했습니다. 이제 원하는 대로 값 하나하나를 가져올 수 있게 됐고 무사히 브레베 정보 페이지를 만들게 됐습니다.

노가다

한국랜도너스 웹사이트로부터 작년 브레베 이벤트 정보를 가져오는건 꽤 귀찮았습니다. 이 정보는 여러 사람들이 긴 시간을 들여 직접 달려보고 작성한 거대한 노력의 결과물입니다. 라이딩을 통한 정보수집은 훌륭하지만 다들 정보시스템을 미리 정의된 규칙에 따라 운영하지는 않기 때문에 같은 장소를 의미하는 텍스트가 서로 다른 이름으로 사용되기도 하고 비슷한 거리를 어느 페이지에서는 파일 하나로 표현하는 반면 다른 페이지에서는 여러 파일로 나눠 표현하기도 했습니다. 또 위에서 이야기한 컨트롤 포인트 정보는 이미지만으로 제공되었습니다. 때문에 정보를 테이블에 입력하는건 그냥 노가다였습니다. 일의 종류가 이전에는 바로 앞에 있는 문제를 해결하는 것이었는데 순식간에 노가다로 바뀌면서 급속히 하기 싫어져 약간 곤란했습니다만 어쨌든 2019년도 정보를 모두 가져왔습니다.

결과

브레베 데이터베이스: https://neoocean.net/b/

작년도 브레베 이벤트의 일정과 지역 별 목록, 브레베 이벤트 하나하나의 정보를 테이블로부터 가져와 보여줍니다. 새로운 이벤트가 추가될 때 편리하게 대응할 수 있고 정적인 페이지일 때에 비해 다른 뷰를 만들어내기 쉬워졌습니다. 구조화된 데이터는 각각 event, course, uri_cppage, place 테이블 페이지에 있습니다. 남은 목표는 두 가지입니다. 첫째, 한국랜도너스 웹사이트에서 사라진 2018년 및 그 이전 이벤트 정보를 찾아다가 입력하는 것. 둘째, 한국랜도너스 웹사이트보다 더 오래 이 정보를 유지하는 것입니다.

한계

struct 플러그인을 처음 볼 때는 SQL에 가까운 문법을 사용할 수 있을 줄 알았습니다. 그래서 조인이나 통계기능, 그룹핑을 통해 페이지를 쉽게 구성하고 컨트롤 포인트 별 분포나 사용 횟수 같은 정적인 정보로는 알아내는데 품이 많이 드는 정보를 바로 위키 페이지에 표시할 수 있기를 기대했습니다. 하지만 실제로는 기초적인 조회 쿼리밖에 사용할 수 없었습니다. 때문에 컨트롤 포인트 관련 통계 페이지를 만들어내는데는 실패했습니다. 위 결과place 테이블이 다른 정보 없이 컨트롤 포인트 이름만 나열한 채 끝난 이유가 이것입니다. 제한된 문법 대신 차라리 쿼리를 직접 날릴 수 있으면 좋지 않나 싶은데 뭔가 이렇게 만든 이유가 있을 거라고 생각합니다.

또 이렇게 데이터베이스에 기반한 페이지들은 위키 시스템의 유지보수기능의 대상이 아니기 때문에 난처한 점도 생겼습니다. 가령 도쿠위키의 검색 기능은 렌더링 되기 전의 Raw페이지를 그대로 인덱싱하는데 데이터베이스를 조회하기 전의 Raw페이지에는 명령어만 적혀있으므로 사실상 검색이 안됩니다. 또 데이터베이스에 적어둔 위키 링크는 링크가 변경되어도 자동으로 수정되지 않습니다.

결론

노션만큼 우아하지는 않지만 데이터베이스를 뒤에 두고 조회한 결과를 페이지에 표시하는 애플리케이션을 아무 코드 없이 만들 수 있다는 것을 문득 깨달았습니다. 비슷한 방식을 다른 대상에 적용해볼 수 있지 않을까 하며 이것저것 둘러보게 되었습니다.

· 2020-01-18 21:02

안읽음

결론

  • 무슨 짓을 해도 회의자료는 안 읽고 들어온다.
  • 읽고 들어오도록 하는 대신 안 읽고 들어온 사람들에 대응하자.

오래 전에 한 임원이 주최하는 회의에 한동안 들어갈 일이 있었습니다. 인상적인 점이 있었습니다. 그때도 지금처럼 회의를 하면 아무도 자료를 읽지 않은 채로 들어와 골머리를 앓고 있었습니다. 회의 일정은 하루이틀 전에 보내고 회의 시간도 일부러 아침 일찍이 아닌 시간대로 신경써서 골랐습니다. 그렇게 확보한 시간에 미리 읽고 오시라고 자료를 첨부하고 혹시나 첨부한 파일이나 링크를 안 읽거나2) 못 읽을 경우3)를 대비해 메일 본문에 요약도 해 놓지만 시간과 장소만 보고 그 시간에 나타나는 것4)을 초과한 어떤 행동도 하지 않는 사람이 대부분이었습니다. 그렇다고 그들에게 뭐라고 하기는 어려웠습니다. 일을 부탁하는 입장이라 함부로 심기를 거스르기도 어려웠습니다. 결국 처음에는 사람들 앞에서 문서를 읽기 시작했고 시간이 흐를수록 문서를 스크롤하며 빠르게 요약하는 잔기술이 생겼습니다. 같은 문제를 고민하던 누군가는 회의 때 사용할 전용 프리젠테이션을 만들기도 하던데 위험해보여서 따라하지는 않았습니다. 결국 문서가 두 벌이 되어 둘 다 관리하는 상황으로 이어졌거든요.

그런데 이 회의는 좀 달랐습니다. 들어가자마자 “다들 읽고 왔죠? 바로 이야기합시다.”로 시작했습니다. 재빨리 참석자들의 눈치를 훑었는데 일부는 약간 당황하는 눈치였습니다. 인쇄물을 쥔 손가락에 힘이 들어가고 눈동자가 빠르게 돌아가기 시작했습니다. 다른 사람들이 잠깐 이야기하는 동안 종이 넘기는 소리가 함께 들려왔습니다. 정말로 이번에도 미리 안 읽고 들어왔을까 싶었지만 그건 제가 확인할 수 있는 일이 아니니 모두의 침묵이 긍정의 의미로 받아들이겠습니다.

그로부터 시간이 많이 흐른 지금도 회의를 할 때마다 비슷한 경험을 합니다. 빈 손에 스마트폰만 들고 들어온 사람들은 이 회의에서 무슨 결정을 내려야 하고 기왕에 만난 자리에서 무슨 이야기를 해야 할지도 미리 고민하지 않은 상태로 방에 들어옵니다. 애초에 회의를 시작하기 전에 정보수준부터 맞춰야 합니다. 한편으로는 잘 이해하기 어려웠습니다. 회의 시간을 줄이자며 회의실마다 시계를 갖다놓고 필요한 사람만 초대하자거나 미리 자료를 공유하자는 등의 수칙이 적힌 코팅된 종이가 회의실에 굴러다니지만 그 누구도 관심을 가지지 않습니다. 도대체 이유를 이해하기 어려웠습니다. 하지만 어느 순간부터 이유를 이해하려고 노력하는 대신 상황에 대처하는 쪽으로 생각을 바꿨고 위에 이야기한 문서를 스크롤하며 이 사람들의 의견을 듣기 위해 지금 당장 필요한 항목 몇 가지만 빨리 이야기하며 회의를 시작하게 됐습니다.

얼마 전에 아마존의 이상한 회의문화을 소개하는 글을 읽었습니다. 이 글은 아마존의 성장을 소개하는 책을 소개하는 글이었는데 인상적이었습니다. 크게 두 가지 중요한 요소가 있었습니다. 하나는 회의 전에 회의자료를 만들 때 프리젠테이션을 지양하고 여섯 페이지짜리 산문 형태의 문서를 준비하는 겁니다. 문서는 회의의 사전지식, 현황, 목표, 실천방안, 방안에 따른 장단점 등 회의에 참여하는 사람들이 알고 있어야 할 정보를 충분히 제공해야 합니다. 이 문서를 얼마나 잘 작성하느냐에 따라 회의의 퀄리티가 달라집니다. 다른 하나는 회의를 시작한 다음에 이 문서를 읽는다는 점입니다. 일단 다 같이 문서를 나눠갖고 처음 십여분동안은 문서를 읽는데 시간을 보냅니다. 누군가가 프리젠테이션을 띄워놓고 설명하는 동안 중간에 생긴 의문을 해결하기 위해 전체 설명을 중단시킬 필요 없이 한번에 문서를 끝까지 읽고 지식수준을 맞춘 다음에 이야기를 시작하면 회의에 낭비를 줄일 수 있다고 합니다.

그런데 이 이야기를 읽으며 깊은 인상을 받은 것과는 별개로 심지어 제프 베조스가 들어오는 회의조차 문서를 안 읽고 들어오는 사람이 있었을거라는데 생각이 미치면서 회의 참석자들이 문서를 안 읽고 들어온다고 화낼 일이 절대 아님을 깨달았습니다. 이쯤 되면 본능입니다. 회의 자료를 전혀 안 읽고 들어와서 이미 공유한 자료에 포함된 설명을 요구하는 것. 제프 베조스라고 하면 그냥 옆집 아저씨같은 느낌이지만 좀더 우리들이 다니는 회사 용어로 바꿔 쓰면 대표님이 주제하는 회의조차 자료를 안 읽고 들어가는 겁니다. 그래서 고민하던 대표님이 세계적으로 이상한 회의문화로 알려진 회의를 시작한 다음에 다 같이 문서를 읽는 방법을 고안해낸 것이 아닐까 의심해봅니다. 대표가 들어가는 회의조차도 이모양인데 하다못해 일을 부탁하는 다른 부서 사람이 주제하는 회의에 문서 좀 안 읽고 들어온다고 뭐라고 할 수는 없겠다는 생각이 굳어졌습니다.

몇 가지 방법은 있습니다. 문서를 스크롤해가며 주요 부분을 설명하는 것, 이 설명에 대비해 문서를 만들다 보면 정말 중요한 점 위주로 목차를 구성하게 됩니다. 또 회의 주제와 문서를 연결해서 설명할 수 있게 됩니다. 이런 상황을 반복해서 겪다 보면 상황을 다른 사람들보다 더 잘 이해한 채로 회의를 시작할 수 있고 내 의도 대로 결과를 이끌어낼 수 있을 가능성도 높아집니다. 제프 베조스도 실패한 일을 나도 똑같이 도전해 고통받지 말고 빨리 포기한 다음 상황을 이용합시다.

· 2019-12-21 23:04

서피스 프로 수리경험

보증기간 후 배터리 스웰링 문제

공식 서비스는 만 3년까지

  • 보증기간이 끝난 서피스는 리퍼 받아야 하며 비용은 약 80만원이다.
    • 배터리가 부푼 문제는 구매 후 3년까지는 도움을 줄 수 있다고 한다.

사설수리는 약 30만원

  • 사설수리점에서 배터리 교체비용은 약 30만원이다.
    • 경우에 따라 기계를 분해하면 배터리에 의해 휘어있던 보드가 고장날 수 있고 이 때 추가 비용이 청구될 수 있다.
    • 비용으로 인해 수리를 포기하더라도 점검비용은 청구된다.

문제

올해 들어 펜을 사용하려고 서피스를 바닥에 내려놓으면 필기할 때 기계가 좀 덜컹거렸습니다. 아이패드처럼 카메라가 튀어나와 있지도 않은데 왜 기계가 바닥에 평평하게 놓이지 않을까 궁금했습니다. 올해로 4년째 아낌없이 사용해온 기계라 외장에 조금쯤 문제가 생긴다 해도 그리 이상한 일은 아닙니다. 특히 킥스탠드를 수 천 번은 접었다 폈다 했을 테니 조금쯤 휘어도 납득할 만한 일입니다. 이 일이 일어나고 나서도 계속해서 아무 문제 없이 돌아갔고 온갖 곳에 들고다녔으며 도킹스테이션에 붙여 펜이 굉음을 내도록 사용했고 또 여전히 킥스탠드를 접었다 폈습니다. 그러던 어느 날에는 화면 일부가 더 밝게 빛나기 시작했습니다. 마치 그 자리만 꾹 누른 것처럼요. 다들 모니터에 빛샘 현상에 민감하게 반응하는 분위기이지만 저는 별로 신경쓰지 않는 문제였고 이번에도 화면에 새끼손가락 지문만한 반점이 생겼지만 가장 신경쓴 것은 그 자리에 펜이 인식되냐는 것이었습니다. 다행히 밝은 반점 위에서도 펜은 이상 없이 동작했고 또 신경을 끄고 살았습니다. 그러는 사이에도 서피스는 여전히 한달에 몇 백 시간은 돌아갔습니다.

지난주에 필기하다가 눈앞에서 '뽁' 소리를 내며 스크린이 불룩하게 튀어나왔습니다. 처음에는 단순히 플라스틱으로 된 스크린 표면이 저혼자 늘어난 거라고 생각하곤 커다란 집게로 꽉 잡아 다시 본체에 붙여놓고 계속해서 사용했습니다. 그대로 회의에 들고 들어갔다가 옆자리에 앉은 분이 제가 필기하는걸 보곤 “그거 원래 화면이 곡면인가요?”라고 물었습니다. 그러다가 문득 언제까지 이걸 집게로 잡아 사용할 수 없겠다는 생각이 들었습니다. 사실 가장 큰 이유는 스크린이 튀어나온걸 집게로 잡아 놓은 상태로는 킥스탠드를 펼칠 수가 없었기 때문입니다.

배터리 스웰링

구글에 검색해 스크린이 튀어나오는 현상은 스크린의 문제가 아니라 배터리 문제라는 사실을 알게됐습니다. 또 서피스 기계에 흔하게 일어나는 문제라는 것도 알게 됐고요. 사실 아이폰이나 아이패드, 애플워치 배터리가 부풀어 스크린이 튀어나오는 사진을 본 적이 있었는데 같은 문제가 제 서피스에도 일어날 수 있다는 생각 자체를 못했습니다. 일단 배터리 문제라는 것을 알게 됐지만 이미 1년 보증은 끝난 상태여서 문제를 어떻게 해결해야 할지 막막했습니다. 어떤 분들은 새 배터리를 구입해 과감하게 기계를 뜯어 수리하시기도 하지만 저는 그런 타입의 사람은 아니었습니다.

제조사에 지원요청

일단 이전에도 전화해본 적이 있는 제조사 고객센터에 전화를 걸었습니다. 이 번호로는 아주 오래전부터 여러 번 전화한 적이 있습니다. 마우스 버튼이 눌린 채로 튀어나오지 않거나 서피스펜이 영원히 켜지지 않거나 키보드 다리가 부러졌거나 비지오를 인스톨하다가 인터넷 인증에 실패할 때 전화해서 도움을 받아 왔습니다. 마우스나 키보드는 택배를 통해 교환했고 서피스펜은 새 제품을 보내줬습니다. 비지오는 90일 이내의 인스톨이라 생긴 문제였다면서 제한을 해제해주기도 했고요. 거의 항상 의미있는 도움을 받아 왔습니다. 하지만 이번에는 제 상황이 좀 여의치 않았습니다. 보증은 옛날에 끝났으니까요. 아니나다를까 이미 ARS에서부터 보증기간 내와 보증기간 외를 구분해서 번호를 누르도록 안내하고 있었습니다. 상담사분 역시 구입 후 3년까지는 조치를 취할 수 있는데 3년을 초과한 제품은 리퍼 제품을 구입해야 하고 서피스 프로 4는 단종되어 제품이 없기 때문에 그 다음 모델을 구입해야 하며 가격은 약 80만원이라고 안내를 받았습니다. 80만원은 제가 같은 기계를 새로 구입하는 것 보다 확실히 싼 비용입니다. 하지만 배터리가 부풀어 바닥에 평평하게 놓이지 않고 스크린은 반점이 생긴 채로 둥글게 튀어나왔지만 여전히 멀쩡히 하루하루 제 요구를 들어주고 있어 선뜻 새 기계를 살 결정을 하기 어려웠습니다.

사설수리

전화를 끊고 사설수리를 알아보니 서피스를 맡아주는 곳은 드물었습니다. 애플 기계를 고쳐주는 사설수리점이 판교에만 여러 개 있는 반면 서피스는 반경 몇 킬로미터 안에도 수리해주는 곳이 없었습니다. 결국 지하철을 타고 한참을 가야 하는 곳에 서피스를 맡아주는 곳이 있다는걸 알게됐고 그나마 맡아주는게 어딘가 싶어 다행스런 기분으로 수리를 맡기러 갔습니다. 가격은 새 제품 가격의 35% 정도입니다. 다음다음날 더이상 배가 불러있지도 않고 바닥에 내려놓을 때 덜렁거리지도 않으며 스크린에 반점도 사라진 서피스를 돌려받았습니다. 물론 결제하고 나서요.

결론

높은 서피스 의존

수리를 맡기고 만 하루 동안 서피스 없이 살면서 제가 이 기계에 얼마나 많이 의존하고 있는지를 문득 깨달았습니다. 위키에 메모를 할 수도 없었고 노트에 메모를 할 수도 없었습니다. 물론 여전히 아이폰에 키보드를 연결해 타이핑할 수 있었고 원노트 메모에 접근할 수도 있었습니다만 어느 시도도 서피스에 비교할 바는 아니었습니다. 게임을 돌리던 안드로이드 태블릿은 긴 위키 페이지를 편집할 때 반응이 너무 느렸고 원노트를 열기에는 스토리지가 부족했습니다. 간신히 필기는 안드로이드 태블릿으로 하고 노트 조회는 아이폰으로 하면서 하루를 그럭저럭 보내고 보니 수리를 맡기는 대신 당장 중고 서피스를 하나 사올걸 그랬나 하는 생각도 들고 이 정도로 의존한다면 만약을 대비해 한대 더 사서 들고있는 것이 낫지 않나 하는 생각도 들었습니다.

보증 종료 후 상황 고려

제조사 지원에 처음으로 거절당한 경험을 했습니다. 여기에는 두 가지 생각을 하게 됐는데 이번을 제외하고는 제조사로부터 나쁘지 않은 지원을 받아왔기 때문에 다음번에도 비슷한 용도의 기계를 구입한다면 서피스를 고려하게 되지 않을까 하는 점. 한편으로는 만약 보증기간이 끝나고 기계에 문제가 생길 때 애플 기계처럼 사용하는 사람도 많고 그에 따라 고쳐주는 곳도 많은 기계를 사용하는게 낫지 않을까 하는 생각도 들었습니다. 이제 서피스는 다시 멀쩡해졌으니 한동안 이런 고민을 다시 할 필요는 없겠지만 미래에 이런 고민을 하게 된다면 이제 기계가 고장나고 제조사가 더이상 지원해주지 않을 때 어떤 도움을 받을 수 있는지도 고려해봐야겠다는 교훈을 얻었습니다.

· 2019-12-21 23:00

조상들의 오버테크놀러지

채집시스템이나 생활경험치가 다 무슨 소용인가

최근 출시된 모바일게임을 돌리다가 문득 퀘스트 텍스트를 읽어봤습니다. 어차피 퀘스트 대부분은 자동진행되니 퀘스트 텍스트를 잘 읽어볼 필요는 별로 없었습니다. 때때로 지금 내 캐릭터가 무엇을 하고 있는지 궁금해지면 별도로 퀘스트 저널 창을 찾아 그때서야 각 잡고 텍스트를 읽으면 된다고 생각했습니다. 그러다 문득 지금 내가 이 몬스터와 전투하고 있는 이유가 뭔가 싶어 퀘스트 인터페이스에 떠있는 목표를 읽어본 겁니다. 잠깐 당황했습니다. 나는 지금 모래를 수집하고 있었습니다. 배경은 사막처럼 보였고 제가 아는 사막은 그 자체가 모래로 이루어져 있었습니다. 아마 바닥에 널려있는 것도 모래를 생각하고 만든 그래픽일 것입니다. 그런데도 나는 굳이 이곳에 사는 몬스터를 공격해 이들로부터 드랍되는 모래를 가져가고 있었습니다. 당황은 잠깐이고 문득 근본적으로 온라인게임에서 말하는 생활스킬이 다 무슨 소용인가 하는 생각을 하기 시작했습니다.

모래를 삽으로 퍼 들고 갈 수 있다고 해봅시다. 먼 옛날 세금과 죽음이 해결된 세계에서 나무를 베고 낚시를 하며 살아가던 사람들이 이 게임을 만들었을 겁니다. 광산에서 구리를 캐고 땅에서 흙과 모래를 얻습니다. 모래를 얻으려면 필드에 모래를 얻을 수 있는 장소를 만들고 모래를 수집하는 애니메이션을 만들어야 합니다. 이 행동 역시 게임으로부터 자원을 얻는 행동이므로 무한히 하게 할 수는 없습니다. 전투가 무기의 내구도와 포션 등을 비용으로 사용하게 만드는 만큼 모래 수집에도 비슷한 개념이 있어야 합니다. 전용 도구를 사용하게 만들고 도구에도 무기와 같이 내구도가 생깁니다. 이제 모래를 수집하는 플레이어들은 망가질 것을 대비해 예비 삽을 여러 개 들고 다니거나 그 자리에서 삽을 고칠 또 다른 생활스킬을 배우기 시작합니다. 삽을 고치는 스킬은 삽만 고치게 하면 별로 배우고 싶지 않을 테니까 무기와 도구를 모두 고칠 수 있도록 설정합니다. 이제 원활한 전투를 위해 전투스킬과 도구수리 스킬을 모두 배워야 하고 몬스터를 쓰러뜨리는 행동을 좋아하는 플레이어와 도구를 수리하는 행동을 더 좋아하는 플레이어들이 갈라지며 플레이어 한 명에게 이 행동을 모두 요구하는 게임은 누구에게도 맞지 않게 됩니다.

아직 안 끝났습니다. 전투로 레벨을 올릴 수 있는데 당연히 모래를 수집해도 레벨을 올릴 수 있어야 합니다. 하지만 서로 다른 행동이 같은 레벨을 올리는 것은 위험합니다. 가령 던전은 레벨 제한에 맞춰 설계되는데 플레이어의 레벨이 전투를 통해 성장한 레벨인지 모래수집을 통한 레벨인지 쉽게 파악해내기 어렵기 때문입니다. 이제 기존 레벨에 전투레벨이란 새 이름을 붙여주고 새로운 레벨을 만들어 생활레벨이라고 부르기 시작합니다. 전투레벨은 던전 출입 제한으로 사용할 수 있게 됐습니다. 그런데 이제 생활레벨을 올려야 할테니 이 레벨에도 쓸모를 만들어야 합니다. 그렇다면 모래를 수집하고 도구를 수리하는 사람들에게 던전에 출입하라고 해야 할까요. 물론 그런 사례가 있습니다. 필드에는 잘 나타나지 않는 자원을 수집할 수 있는 던전이요. 하지만 이런 서로 명백히 다른 플레이를 만든다 하더라도 근본적으로 MMO 게임에서는 이들이 어딘가에서 다시 마주치게 만들어야만 하는 강박적 관습이 있습니다. 레벨이 높은 던전의 보스는 전설급 무기를 드랍하고 이 무기를 고칠 수 있는 사람은 전설적으로 생활레벨이 높은 경험 많은 도구를 수리하는 사람 뿐이라는 식으로 둘을 연결해봅니다. 결국 서로가 서로를 원하는 시점에 편리하게 찾을 방법이 없어 한 사람에게 이 모든 역할을 요구하는 모양으로 돌아갑니다. 상황은 복잡해진 채 개선되지 않고 이 상황을 만든 게임디자이너는 고객들로부터, 개발팀으로부터, 경영진으로부터 쉴 새 없이 욕을 먹고 맙니다.

이 모든 문제는 몬스터가 모래를 드랍하게 만드는 순간 해결됩니다. 자동전투 돌리러 온 고객들에게 채집과 제작 등 생활로부터 가져온 시스템을 기존 전투시스템과 아무런 차이 없이 바로 전달할 수 있습니다. 아까는 도적단을 소탕하기 위해 전투를 했지만 지금은 모래를 수집하기 위해 전투를 합니다. 또 다른 몬스터를 공격해 나무를 얻어 제작에 사용합니다. 제작한 아이템은 거래소에 올려 다른 사람들의 시간을 절약해주는 대신 재화를 얻을 수도 있습니다. 자연스럽게 생산자와 소비자가 비교적 간단한 방법으로 만나고 플레이어 한 명에게 이 모든 시스템을 플레이할 것을 요구할 필요도 없어집니다. 모래를 수집하는 행동은 여전히 포션과 무기를 필요로하므로 비용을 따로 만들어낼 필요도 없습니다. 삽을 만들거나 삽질 애니메이션을 만들지 않아도 되고 전투레벨과 생활레벨을 분리할 필요도 없습니다. 이 모든 문제는 몬스터가 채집물을 드랍하는 순간 거짓말처럼 해결됐습니다.

하지만 지난 이십여년 동안 시도해 온 온갖 가생세계의 여러 가지 삶을 표현하려던 시도들은 별로 성공적이지 않았습니다. 그러다가 문득 20여년 전에 이 모든 문제가 간단한 발상의 전환만으로 이미 갚히 해결되어 있었을 뿐 아니라 그 시스템이 현대 모바일게임의 자동진행 요구에도 잘 부합한다는 사실에 문득 조상들의 오버테크놀러지를 느껴봅니다.

· 2019-12-21 18:30

문서 길이 줄이기

팀원님의 문서를 검토하다가 예상한 길이에 비해 문서 길이가 엄청나게 길어 지레 겁부터 먹었습니다. 일단 긴 문서를 읽고싶지 않았을 뿐 아니라 요청한 주제는 이렇게까지 긴 문서를 필요로 하지 않을 거라고 예상했거든요. 일단 문서를 끝까지 읽으면서 요구사항을 만족하는지 확인해본 다음 어쩌다가 이 주제의 문서가 이렇게까지 길어졌는지를 생각해보기 시작했습니다.

문서는 일단 짧아야 합니다. 이전 시대에 비해 활자를 엄청나게 읽어대는 현대인들이지만 그들이 읽는 활자 덩어리는 점점 더 짧아지고 있다고 합니다. 이전 시대에는 읽을 수 있는 활자라고는 두툼하게 편집된 책이 전부였지만 한동안 블로그의 시대를 지나 지금은 그보다 더 짧은 마이크로블로깅(aka 트위터) 시대이고 또 활자를 벗어난 인스타그램의 시대이기도 하니까요. 문서는 짧아야 합니다. 그나마 활자를 읽는데 거부감이 적은 사람들이 매일같이 읽는 활자덩어리는 점점 더 짧아지고 있습니다. 이제 활자 길이거 길어져야 한다면 처음부터 길게 작성한 글 대신 짧은 글 여러 개를 짧은 호흡으로 이어붙인 글을 읽습니다. 이런 블로그에 긴 글을 적어도 그 누구도 읽지 않는 시대입니다. 문서는 짧아야 합니다. 문서는 읽는이에게 행동을 하도록 유도합니다. 기획서는 읽는 사람이 내용을 이해하고 개발하도록 만듭니다. 그런데 이 문서가 길다면 읽는 사람은 그 내용이 뭐든지간에 일단 겁부터 먹습니다. 실제로 이번 마일스톤에 구현할 항목은 첫 번째 챕터의 팝업 윈도우 하나뿐이지만 총 56페이지에 달하는 거대한 문서를 받는 순간 공포에 사로잡혀 서로 의도하지 않은 방어적인 자세로 변할 수도 있습니다.

문서는 짧게 써야 합니다. 짧게 쓰는데는 두어 가지 요령이 있는데 하나는 조금 더 어려운 방법, 다른 하나는 조금 더 쉬운 방법입니다. 여기서 어려운 방법을 잘 설명할 생각은 없으니 짧게 이야기하고 지나가면 문서를 MECE하게 작성하는 겁니다. 위키피디아 한국어판의 설명에 따르면 '상호배제와 전체포괄'이라고 하는데 내용에 중복된 부분이 없어야 하고 동시에 빠진 부분도 없어야 한다는 겁니다. 긴 문서를 읽다 보면 생략할 수 있는 중복이 자주 등장합니다. 앞에 한번 나온 개괄 설명이 뒤에 나오는 작은 항목을 설명하는데 다시 복사된 채 인용되기도 하고 서로 비슷비슷해 차이점만 나열하면 될 인터페이스 디자인이 여러 번 나타나기도 합니다. 또 같은 항목에 작은 옵션이 달라지는 형태로 정리할 수 있을 개념이 서로 아예 다른 개념으로 큰 챕터를 차지하고 나타나기도 합니다. 이런 중복을 줄이는데 MECE의 '상호배제'부분이 중요한 역할을 합니다. 다음 부분인 '전체포괄'은 난이도가 조금 더 높은데 전체를 포괄하기 위해 게임의 최상위 목표로부터 연관되어 내려오는 요구사항의 전체 트리를 파악하고 내가 담당한 트리와 하위 요소를 파악해 이들을 포괄할 시스템을 고안해내야 하기 때문입니다. 사실은 주니어분들께 이걸 잘 요구하지는 않습니다. 실제로 한번에 해내기 어렵고 현대의 게임 개발은 중간에 요구사항이 광범위하게 변경되는 일이 잦기 때문이기도 합니다. 몇 번 겪으면 일반적인 인간은 멘탈이 깨질 수 있거든요. 하지만 '상호배제'부분은 어렵지 않게 실천해 문서 길이를 줄일 수 있는 확실한 방법입니다.

좀더 쉬운 방법들이 있습니다. 눈속임일 수 있지만 많은 페이지 수로 독자에게 겁을 주는 것 보다는 낫습니다. 지난번에 이야기한 문단간격의 연장입니다. 일단 서양의 서술식 문서에 더 적당한 문단간격 설정을 동양의 개조식 문서에 더 적합한 모양으로 바꿉니다. MS워드 기본 서식에 '본문'과 '본문 (간격없음)'의 차이를 인식하고 사용해야 합니다.

전통적으로 문서에 꼭 집어넣던 항목이 정말 문서에 필요한지를 고민해야 합니다. 가령 표지와 목차와 히스토리가 정말 필요한지 고민해보세요. 표지는 이 문서가 길다는 인상을 첫 페이지부터 줍니다. 표지는 정말 필요한 정보를 전달하고 있나요? 아니면 다른 모든 기획서에 표지가 있으니까 나도 따라하고 있나요? 팀 외부로 공유할 예의를 갖춘 문서가 아니라면 표지는 필요없습니다. 부서 이름, 날짜도 필요없습니다. 사실은 쓴사람 이름도 필요없습니다. 이 모든 항목은 과거에 문서를 팀 외부로 인쇄해서 공유할 때 필요했습니다. 표지에는 부서, 책임자, 작성일, 결재선이 표시되어 있어야 했고 일단 결재선을 통과한 문서는 그대로 진행해야 했습니다. 또 문서는 문서 자체만 공유되므로 히스토리도 중요했습니다. 누가 언제 무엇을 고쳤는지 히스토리가 없으면 파악할 방법이 아예 없었으니까요. 하지만 현대 개발팀에서 문서는 웹 기반의 위키에 올라가 있거나 MS워드로 작성한다 하더라도 높은 확률로 형상관리시스템에 올라가 있을 겁니다. 누가 언제 무엇을 고쳤는지는 형상관리시스템의 로그에 더 잘 기록되어 있을 테고 문서 공유 역시 이 시스템을 통하므로 더이상 표지와 히스토리에 시간을 낭비할 필요가 없습니다. 문서를 커밋할 때 메시지를 잘 작성하는 습관만 남기세요.

목차도 필요없습니다. 목차는 문서가 길고 챕터 구조가 복잡할 때 사용합니다. 누군가는 목차를 잘 작성하면 목차만 보고도 문서의 내용을 파악할 수 있으므로 문서를 잘 구성하고 목차에 잘 드러나도록 해야 한다고도 말합니다만 제 생각은 다릅니다. 목차는 이 문서가 길다는 신호이고 목차 스스로도 문서를 더 길게 만듭니다. 문서를 짧게 만드는 노력을 기울이기 시작하면 굳이 목차가 필요 없는 수준으로 페이지가 줄어들고 굳이 목차를 빌어 요약을 제시할 필요도 없어집니다. 만약 필요하다면 목차 대신 실제 요약문을 문서 앞부분에 제공할 수도 있습니다. 굳이 목차 형식을 빌리지 않고서도요.

마지막으로 팀에 공유되는 문서 템플릿에 위에 이야기한 없앨 수 있는 모든 것이 들어있을 수 있습니다. 또 내가 가진 결정권이 없거나 거의 없는 것처럼 느껴진다면 문서를 개선해볼 생각 자체가 안 들 수도 있습니다. 하지만 팀의 문서 템플릿은 헌법이 아닙니다. 헌법조차도 시대의 흐름에 따라 수정되는 마당에 팀 표준 문서 템플릿이 이를 사용하는 사람들에게 자연스럽게 문서를 길게 쓰도록 유도하고 있다면 이는 따라야 할 대상이 아니라 바로잡아야 할 대상입니다.

문서는 짧은 편이 더 낫습니다. 읽는 사람이 겁먹지 않게 해 목표를 더 잘 달성할 수 있습니다. 문서를 짧게 쓰는데는 상호배제와 전체포괄의 원칙을 사용해야 하는데 상호배제가 당장 실천하기 더 쉽습니다. 문서의 형식에 따라 스타일 옵션에 신경쓰고 표지, 목차같은 불필요한 항목을 삭제하면 쉽게 문서 길이를 줄일 수 있습니다. 형상관리도구를 사용한다면 히스토리는 문서 안에 있을 필요가 없으모 형상관리도구를 사용하는 표준 규칙을 잘 따르기만 하면 됩니다. 비교적 간단한 방법으로 문서 길이를 줄일 수 있습니다.

· 2019-12-15 11:46

오래된 항목 >>

2)
링크 클릭에 이탈률이 높음
3)
환경에 따라 파일을 못 열 수도 있음
4)
사실은 나타나기만 해도 다행임
blog/start.txt · 마지막으로 수정됨: 2020-01-14 20:52 저자 neoocean