큰 회사의 강력한 권한이 안정감을 주기도 한다
속한 팀에 유명해지는 건 때로는 좋은 신호이지만 때로는 아주 나쁜 신호일 때도 있습니다. 한번은 어느 팀인지 정확히 언급되지는 않았지만 기사에 회사에 속한 누군가가 회사에 속하지 않은 다른 분께 아주 나쁜 말을 한 사건이 널리 회자된 덕분에 팀이 아주 유명해졌습니다. 어느 팀인지 정확히 실리지 않았지만 회사에 속한 사람들은 이 기사가 어느 팀의 누구를 가리키는지 한눈에 알 수 있었습니다. 피해를 입으신 분인 공개하셨을 것으로 추정되는 스크린샷에는 상대가 보낸 문제가 될 수밖에 없는 말이 나열 되어 있었는데 보는 누구나 ‘맙소사…….’라고 말할 만한 것이었습니다. [계속]
완벽한 만원
처음 다닌 회사에는 야근 식대 제도가 있었습니다. 포괄임금제였기 때문에 야근을 하더라도 수당을 받지는 못했습니다. 야근은 오후 여섯 시를 기준으로 그 이후 3시간을 추가로 일하면 야근으로 인정했는데 이 때 저녁 식사 비용을 보전해 주는 제도였습니다. 회사에서 일하는 동안 몇 년에 걸쳐 야근 식대는 7천원이었고요.
당시 회사는 압구정 근처에 있었는데 그 근처에서 7천원으로 먹을 수 있는 식사는 꽤 제한적이었습니다. 주로 회사에서 멀지 않은 백반집과 돈가스집, 부대찌개집, 제육볶음집 정도가 고정 메뉴였는데 이들도 일을 시작하고 얼마 지나지 않아 7천원으로는 먹을 수 없는 가격에 진입했습니다. [계속]
아직도 VBA를 가르친다고?
2년 전에 '기획자가 프로덕션에 VBA 쓰면 안돼요!'라고 한 적이 있습니다. 게임 개발의 여러 부분에 엑셀을 사용하고 또 엑셀 사용자들 모두에게 현대적인 엑셀 개발 환경을 교육할 여유가 없다면 VBA는 서기 2023년에도 여전히 엑셀이 제공하는 기능 이상의 뭔가를 상상할 때 처음으로 고민하게 되는 기술이기는 합니다.
한편 그런 장점에도 불구하고 VBA에 의한 결과가 프로덕션 파이프라인에 관여하는 순간 여러 가지 슬픈 일이 일어납니다. 소스 버전 관리가 안 되어 유지보수가 어렵고 숙련되지 않은 작업자가 위험한 코드를 쉽게 사용할 수 있고 여느 코드와 마찬가지로 문서화가 잘 되지 않아 담당자가 없으면 아주 작은 문제에도 쉽게 피해를 입으며 인터페이스와 로직의 경계가 흐릿한 오래된 개발환경의 특성 상 유지보수가 급격히 어려워지는 단계에 쉽게 진입합니다. [계속]
처음 여러명이 일하는 환경에서 형상관리도구를 사용하는 분들께
맞아요. 다른 사람이 쓴 문서에 손을 대는 거 부담스럽죠.
지금 까지 아주 많은 사람들이 한 프로젝트에 속해 일하고 또 이 사람들이 만들어 내는 아주 많은 문서를 감당할 만한 강력한 여러 가지 체계가 개발되었지만 이를 사용하는 사람들의 행동을 살펴 보면 공식으로 여러 사람이 작성해도 된다고 알려진 페이지 소수를 제외한 나머지는 여간해서 다른 사람이 작성한 페이지에 손 대지 않곤 했어요. 단순히 잘못된 그림이나 링크를 수정하거나 오타를 수정하는 것 조차도 그냥 열려 있는 노션 페이지에서 이를 발견한 사람이 수정하면 끝나지만 굳이 문서를 작성한 사람을 찾은 다음 슬랙으로 말을 걸어 오타가 있다고 알려주기도 하고요. [계속]
겹치지 않는 UID를 수동 생성하는 요구사항
'로직을 데이터 모양으로 표현한 간단한 스킬 시스템'에 게임 프로젝트에서 엑셀을 어떤 식으로 사용하는지 이야기한 적이 있습니다. 엑셀 데이터를 프로젝트 전반에 걸쳐 사용하는데 비해 프로젝트에 따라 엑셀 데이터에 접근하는 방식은 저마다 상당히 다릅니다. 어떤 프로젝트에서는 게임이 읽어들일 모든 엑셀 워크시트는 첫 열 첫 행이 반드시 ID여야만 하기도 하고 어떤 프로젝트에서는 Id에 최대 열 자리 숫자만 사용할 수 있기도 하며 또 어떤 프로젝트에서는 Id에 문자열을 사용해 사람이 알아보기 쉬운 모양을 사용할 수 있기도 합니다. 또 어떤 프로젝트는 워크시트 첫 행에 모든 값 이름을 한 줄로 나열해야만 하기도 하고 또 다른 프로젝트에서는 값 이름에 계층 구조를 만들 수 있기도 하고요. [계속]
요구사항 변경과 납기의 관계
어느 프로젝트에서나 일정 기간마다 달성할 목표를 세우고 목표를 달성해 가는 과정을 반복합니다. 이를 통해 팀의 퍼포먼스를 측정해 팀의 역량과 기간에 알맞는 목표를 수립할 수 있게 되고 또 목표마다 우선순위를 설정해 더 중요한 목표와 그렇지 않은 목표를 구분해 더 효율적으로 개발할 수 있게 됩니다. 거의 모든 조직에서 이 과정을 ‘스플린트'나 ‘마일스톤’ 같은 이름으로 불렀는데 전자는 애자일 어쩌구 방법론을 깊은 고민 없이 그냥 도입하려다가 익숙하고 안정감을 주는 여러 습관을 버릴 결정을 내리지 못해 이도 저도 아닌 규칙이 이름만 남곤 할 때 주로 사용했고 후자는 딱히 뭔 방법론을 염두해 두지 않더라도 좀 더 긴 기간 동안 달성할 더 여러 가지 목표를 같은 기간에 개발할 때 사용하곤 했습니다. [계속]
왜 채용 직후 해고하는 일이 벌어질까
22년 하반기에서 2023년도 상반기로 넘어오면서 고용시장이 단단히 얼어붙은 것 같아 보입니다. 물론 여전히 필요한 사람을 구하기는 너무 어렵고 또 한편 일을 구하는 사람은 일이 없는 이상한 상황이 계속되고 있는 것 같지만 확실한 것은 양쪽 모두 쉽지 않은 상황이라는 겁니다. 다른 회사의 여러 프로젝트가 중단되어 사람들이 해고되고 있다는 흉흉한 소식을 직접 듣기도 하고 또 아직 멀쩡한 줄 알았던 프로젝트로부터 이력서 여러 개가 동시에 유통되는 모습을 보면 아직 터지진 않았지만 여기도 조만간 터질 수 있겠다는 짐작을 하기도 합니다. [계속]
기획자 두 명이 만들 수 있는 MMO 게임은 없어요
최근에 전해 들은 일종의 구인 사기에 대한 이야기를 한번 하고 지나가면 좋을 것 같습니다. 구인을 하다 보면 이력서에 비슷한 패턴이 나타날 때가 있습니다. 여러 해에 걸쳐 일했지만 지금은 폐업은 아주 작은 팀을 전전하며 어떻게든 개발을 진행해 보려고 노력했지만 결국 1년 남짓 한 시간을 소모했으면서도 커리어에 도움이 되는 경험을 얻지 못하기를 반복하는 것입니다. [계속]
좋지 않은 태스크 이름
지라를 영문 버전 그대로 사용해 보면 태스크 이름에 해당하는 말이 ‘Summary’임을 할 수 있습니다. 한국어 버전에서는 ‘요약’이라고 나타나는데 영문 의미와 다르지 않습니다. 이 이름을 곧이곧대로 받아들이면 작업 내용의 ‘요약’을 입력하는 곳이라고 할 수 있습니다. 종종 프로젝트 전체에서 태스크 이름을 정하는 모습을 관찰해 보면 이 필드 이름이 ‘요약’임을 잘 인식하지 않는 것 같은 모습이 눈에 띕니다. 작업에 관련된 사람들끼리 작업 이름을 줄여 부르는 말을 그대로 요약에 사용해 다른 사람들은 이 작업 내용과 목표를 쉽게 이해할 수 없기도 합니다. 일단 지라에서 흔히 ‘제목’이라고 인식하는 그 칸은 작업의 요약을 기입하는 곳입니다. 요약은 말 그대로 작업 내용을 짧게 줄인 것입니다. 그래서 요약은 프로젝트 구성원들 누구나 요약을 읽고 이 작업의 목표와 작업이 완료되었을 때 일어날 일을 상상할 수 있는 모양이어야 합니다. [계속]
안 중요한 일은 내가, 중요한 일은 멤버들께
몇몇 프로젝트에서 리드 시스템 디자인 역할을 해 왔는데 처음에는 이 역할을 잘 이해하지 못했습니다. 개인 기여자 역할을 할 때는 개발팀 안에서 적어도 시스템 디자인이나 문제해결 분야에서는 약하지 않은 역할을 해 왔다고 생각합니다. 그래서 리드 역할을 맡기 시작할 때는 이 역할이 개인 기여자 역할의 연장이라고 생각했습니다. 이전의 개인 기여자 역할에 추가로 함께 일하는 다른 개인 기여자 분들께 업무를 분배하고 또 진행 상황을 관찰하고 도움이 필요한 시점을 관찰해 적당한 때 개입해 일을 원활하게 진행 시키는 것을 주요 임무로 받아들였습니다. [계속]
영혼이 없이 개발해야만 임무를 완수할 수 있을 때가 있다.
복제를 강요받는 환경에서 일하다 보면 그래도 그저 복제하는 대신 내 스스로 옳다고 생각하는 뭔가를 더하거나 빼고 싶을 때가 있습니다. 그래서 복제를 강요받는 환경에서 살아남기 위한 방법으로 관리자 입장에서는 복제를 정확히 지시하고 또 복제해야 하는 이유를 설명하며 복제 하는 입장에서는 이 시스템이 게임 전체에 어떤 역할을 하는지 정확히 이해해야 한다고 이야기했었습니다. 복제를 수행하는 자세에 있어 이처럼 자신의 의지를 포함해 복제를 할 때도 있지만 가끔은 영혼 없이 복제해야만 프로젝트를 완수할 수 있는 상황이 있다고 생각합니다. [계속]
누가 고쳐야 할까
언리얼 환경에서 개발하는 가상의 프로젝트에서 사용하는 아이템 데이터 엑셀 파일을 생각해 봅시다. 엑셀 파일을 열면 거대한 워크시트가 펼쳐지고 첫 칼럼에는 아이템 아이디 수 천 개가 줄줄이 늘어서 있습니다. 오른쪽으로 조금 스크롤 해 보면 아이템 아이콘을 설정하는 자리가 있고요. 여기에는 언리얼 에디터에서 에셋 경로를 복사한 에셋 종류와 경로, 네임스페이스가 쭉 연결된 텍스트가 붙어 있습니다. 아이템 아이콘을 수정하고 싶으면 언리얼 에디터에서 원하는 아이콘의 스프라이트 에셋을 찾은 다음 컨텐츠 브라우저에서 경로를 복사해 엑셀 워크시트에 붙여 넣고 저장한 다음 클라이언트를 다시 실행하거나 클라이언트가 실행된 상태에서 데이터만 새로 고쳐 테스트 해 보면 됩니다. [계속]
다른 사람 입장에서 생각해보기
이전에 다른 사람이 글을 읽을 때를 대비해 보기 예쁜 모양으로 만들어 놓는 행동이 업무 역량의 일부를 판단하는 작은 지표가 될 수 있다는 말을 트위터에 쓴 적이 있습니다. 한동안 이 주제를 생각해 보다가 자칫 이런 이야기가 작은 습관에 너무 큰 의미를 부여하는 것 같다는 생각을 했습니다. 또 한편으로는 뚜렷하게 작은 습관을 가진 분과 그렇지 않은 분을 구분할 수는 있어 완전히 의미 없는 지표는 아니라는 생각이 들기도 했고요. 그래서 몇 가지 사례를 소개하기만 하려고 합니다. [계속]
보고 회의에서 망신당하지 않는 요령
회의 시간입니다. 이미 사전에 전달한 문서에 이 시간에 말할 모든 내용이 적혀 있지만 문서를 읽은 사람은 거의 없거나 전혀 없습니다. 때문에 회의 시간에는 사람들에게 이미 문서를 통해 전달한 내용을 반복해서 설명해야 합니다. 이 설명은 때때로 거의 문서를 읽다시피 하며 진행되곤 합니다.
이런 회의에 문제의식을 느껴 회의 형태를 회의실에서 각 잡고 하는 대신 간단히 밖에서 만나 이야기하고 끝내는 형태로 바꾸기도 하고 자리에 앉는 대신 서서 말하기도 하고 또 본인의 용건이 끝나면 그냥 나가도 된다는 규칙을 명시적으로 선언하거나 회의가 시작되면 말 없이 제출한 문서를 읽는 시간을 가지기도 합니다. 우리는 이 중 어떤 방법도 적용할 만한 상황이 아니었고 또 적용할 만한 권한이 있는 분들을 설득하기에는 이런 방법이 가져올 효과를 신뢰하지 못했습니다. 그래서 이미 문서를 통해 제출한 내용을 반복해서 설명하는데 시간을 쓸 수밖에 없습니다. [계속]
실수하지 않도록 가이드하기
이전에 일하던 어느 팀에서 한번은 팀의 근태 관리가 문제 된 적이 있습니다. 보통 근태를 문제 삼으면 팀이나 회사가 기울어 간다는 신호일 때가 있습니다. 높은 분들이 더 이상 뭔가 개선해 가는 모습을 보여줄 수 없을 때 선택하는 마지막 방법 중 하나 입니다. 그래서 이런 신호를 마주하면 탈출 버튼을 만지작거리는 편이 올바른 행동일 수 있습니다. 다행히 그런 상황은 아니었습니다. 근태 자체의 문제가 아니라 실제 실행된 근태와 그 기록이 일치하지 않는 경우가 종종 있었는데 이 점이 문제가 됐습니다. [계속]
회사에서 개인의 성장
회사에서 개인의 성장에 대한 떡밥이 타임라인을 스치고 지나간 것 같습니다. 이번에도 지난번 지속 가능한 크런치? 때처럼 일부러 이야기들이 타임라인을 스쳐 좀 지나가게 놔 둔 다음 회사에서 개인의 성장이란 무엇일지, 성장을 위해 무엇을 제공해야 할 지, 또 전통적인 성장 지원이 지금도 의미 있는지 같은 주제들을 두서 없이 생각해봤습니다. 미리 오리발을 내밀어 두자면 성장에 대한 관점은 사람들마다 모두 다를 수 있으며 이 글은 여러 생각 중 하나 정도의 의미만 있습니다. [계속]
포트폴리오 기획서는 의미 없지 않아요
이전에 포트폴리오 준비하기 어려움에서 투덜거렸지만 포트폴리오 작성은 여전히 골칫거리입니다. 여러 번 준비해봐도 도무지 어떻게 준비해야 할 지 모르겠어요. 오늘은 타임라인을 지나가다가 다른 분의 포트폴리오 기획서에 대한 고민과 이에 대한 조언을 봤고 포트폴리오 기획서에 대한 제 의견을 정리해 보려고 합니다.
게임디자인 포트폴리오를 작성하기에 현실적으로 난감합니다. 테크나 아트는 스스로 작업을 완결 시킬 수 있습니다. 작성한 코드, 동작하는 결과물, 에셋 등 완결된 작업을 포트폴리오로 제시할 수 있습니다. 반면 게임디자인은 스스로 작업을 완결 시킬 수 있는 입장이 아닐 때가 많습니다. 심지어 테크 지원이 필요 없는 보드게임을 디자인한다 하더라도요. 그러니 항상 테크나 아트 직군을 이해하기 위한 지식을 갖추고 스스로 어느 정도 이런 작업을 해낼 수 있어야 한다는 이야기가 나옵니다. 이런 말을 흔히 접하지만 실은 이 말은 무척 가혹한데 어느 정도 지식을 갖추는 수준으로는 완결된 작업을 제시할 수 없기 때문입니다. 테크나 아트가 하는 것처럼 완결된 작업을 제시하려면 결국 테크나 아트에 요구하는 수준에 도달해야 한다는 의미입니다. 게임디자인 입장에서 이는 열심히 해서 도달할 수 있는 수준이 아닙니다. [계속]
포트폴리오 준비하기 어려움
이건 암만 고민해도 답이 안 나와서 하는 투정입니다. 종종 트위터 타임라인에 포트폴리오를 봐 주시는 분들의 글이 지나갈 때마다 포트폴리오 컨설팅이 정말 필요하다는 생각이 들었습니다. 지금까지는 어쩌다 보니 운이 좋아서 내 멋대로 작성한 포트폴리오로 어떻게 밥벌이를 유지할 수 있었지만 시간이 흐르며 신입 분들이 제출하신 문서를 보면서 지금처럼 있다가는 정말 큰일 나겠다 싶었습니다. 하지만 여간해선 포트폴리오 컨설팅을 해 주실 분을 찾을 수가 없었는데 가장 큰 이유는 온라인에서 실명을 까고 있기 때문일 것 같습니다. [계속]