NDC Replay

팀을 구하는 툴 개발
박경재
넥슨코리아
<피파 온라인> 퍼블리싱을 맡고 있으며, 과거 <카트라이더>, <에버플래닛>, <던전 앤 파이터> 등의 개발에 참여
프로젝트를 진행해 나가면서, 여러분의 동료와 여러분 자신이 겪고 있는 불편함은 무엇인가요? 그리고 그 불편함과 번거로움은 꼭 필요한 것일까요? 고객들의 요청 사항에 대응하는 만큼, 팀 동료의 불편함을 해결하는 것은 매우 중요합니다. 아직 많은 수의 개발팀에서 개발 초기에 만들어진 툴을 그대로 사용하고 있습니다. 프로젝트의 규모가 명확하지 않은 개발 초기 단계에서는, 다소 불편하고 최소한의 기능만 있는 툴을 사용하게 됩니다. 프로젝트가 오래 될수록 이러한 낡은 툴과 프로세스는 팀원들이 느끼는 불만족과 비효율의 주요 원인이 됩니다. 본 세션에서는 카트라이더, 에버플래닛, 던전 앤 파이터 등의 프로젝트에서 툴을 만들었던 경험을 공유하고, 프로젝트 PM과 프로그래머가 툴과 프로세스에 대하여 가져야 할 마인드셋에 대한 논의를 진행합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 오늘은 팀을 구하는 툴 개발이라는 주제로 발표를 하게 된 박경재라고 합니다. 먼저 제 소개를 간단하게 드리도록 하겠습니다. 저는 2004년에 카트라이더 팀 프로그래머로 넥슨에 입사를 했고요. 그 후 약 10년간 넥슨의 여러 프로젝트를 함께 해 왔습니다. 본격적으로 이야기를 시작하기 전에 먼저 오늘 이야기할 주제에 대해서 간단하게 말씀을 드리도록 하겠습니다. 오늘을 앞서 프로젝트에서 만들어왔었던 개발 툴에 대한 이야기. 카트라이더, 에버플래닛, 던파 등 여러 프로젝트에서 어떤 툴을 만들었는가에 대한 이야기를 늘어놓는 자리가 아니고요. 특정 프로젝트나 특정 툴에 사례에 포커스를 맞춰서 진행하지 않겠습니다. 그 대신 오늘 집중하고 싶은 이야기는 이것입니다. 게임을 만들어 나가면서 그리고 저희가 라이브 서비스를 하면서 같은 팀의 기획자, 아티스트 그리고 프로그래머가 겪고 있는 불필요한 괴로움과 그리고 그 괴로움을 덜어낼 수 있는 툴에 대한 그리고 그 툴을 만드는 마인드 셋에 대한 이야기를 하려고 합니다. 그러면 본격적으로 이야기를 시작해보도록 하겠습니다. 게임이 라이브가 되고 나서 저희가 주로 많이 고치고 개선하고자 하는 것은 어떤 게 있을까요? 보통은 저희가 우리 게임을 즐겨주는 유저, 고객이 게임을 하면서 느끼는 여러 가지 불편 사항, 불만 사항들을 해소하는 데 굉장히 많은 공과 시간을 들입니다. 그러나 정작 우리가 업데이트를 하고, 준비를 하는 과정에서 우리가 느끼는 불편함과 그 어려움에 대해서는 잘 신경을 쓰지 않죠. 이제 몇 가지 한번 예시를 재미있는 그림과 함께 들어보도록 하겠습니다. 첫 번째 이야기는 퀘스트가 있는 게임 이야기입니다. 일단 여기 퀘스트 기획자가 있습니다. 이번 업데이트에 들어갈 퀘스트 구상이 끝났어요. 그런데 이제 이 팀에서는 기획자가 직접 입력을 할 수가 없습니다. 퀘스트 툴이 재대로 갖춰지지도 않았고 그리고 서버에서 입력할 데이터는 기획자가 알기 어려운 포맷으로 관리하고 있기 때문이죠. 그래서 이제 기획자는 프로그래머를 부르게 됩니다. 그래서 이제 엑셀 파일을 만들었는데 잘 해놨으니까 퀘스트를 신규지역_Ver_01.xlsx, 파일 명부터 좀 심상치 않죠? 이런 파일을 전달하면 이 프로그래머가 기획서를 보고 퀘스트 DB에 데이터를 수동으로 입력합니다. 왜냐면 아이템 코드를 아는 사람은 프로그래머 밖에 없으니까요. 기획자는 잘 기다립니다. 그래서 프로그래머가 입력을 마치면 대기하던 기획자에게 작업이 끝났다고 사인을 줍니다. 그러면 기획자가 테스트 서버에 플레이를 열심히 해보죠. 그런데 보통 이게 한번에 끝나지 않아요. 뭔가 ‘연퀘 정보를 잘못 입력해서 보상이 달라.’ 이런 것들이 항상 생기기 마련이죠. 그러면 이제 다시 엑셀 문서를 고치고 02 파일을 보내줍니다. 02가 끝일 거라고 하면서. 그러면 다시 또 열심히 프로그래머는 데이터를 수동으로 입력합니다. 이제 기획자는 기다리고요. 그래서 다시 수정본이 나오면 다시 또 플레이하면서 당연히 수정 사항이 생기죠. 이제 기획자는 고민하게 되요. 언제쯤 이걸 얘기할까. 그리고 다시 파일을 넘깁니다. 수정하고, 또 고치고 파일명에 마음을 담아서 진짜 파이널. 하여튼 이런 과정을 거치고 반복을 하다 보면 엑셀 파일은 엑셀 파일대로 따로 업데이트가 되고, 서버 데이터는 프로그래머가 막 맞춰서 하는 대로 업데이트가 돼서 결국은 불일치가 생기고, 중복 작업이 생기고 맙니다. 또 하나의 예를 한번 들어볼게요. 맵 에디터에 대한 얘기인데요. 어떤 프로젝트에서는 맵 에디터가 좀 불안정합니다. 3년전에는 잘 동작을 했는데 툴을 열심히 만들던 분이 갑자기 퇴사하고 나서는 잘 유지보수가 안돼서 삐걱이기 시작합니다. 어떻게 그러냐면 어떤 맵은 열면 에러나고, 옛날에 만든 맵은 열수는 있는데 저장을 하니까 맵 데이터가 깨져요. 어떤 맵은 저장하고 다시 잘 돌아가는 것 같아서 보니까 나중에 이벤트 데이터, 새로 입력한 데이터들이 날아가서 다시 데이터를 입력해줘야 되는 그런 상황들이 생긴 거죠. 이럴 때 개발팀은 보통 어떤 선택을 할까요? 툴을 처음부터 새로 고치는 그런 작업을 할까요? 대부분의 팀이 이대로 잘 써보자 하고 어떻게든 써보려고 합니다. 그리고 어느 새월에 처음부터 다시 만드냐? 이렇게 하면서 일단 되는대로 해보자. 라는 생각을 하게 되죠. 그래서 팀의 역할을 나눕니다. 기획자와 아티스트가 맵 에디터를 열고 초벌구이를 하는 것처럼 에셋들을 초벌 배치를 합니다. 배경이랑 안 깨지는 애들이 있죠. 몬스터, 기본 NPC 이런 애들 배치를 하면 산전수전 다 겪은 숙련된 기획자와 프로그래머가 와서 그 맵 데이터의 메모장을 열고 상세 파라메터를 넣습니다. 이건 민감한 작업이라서 시니어들만 할 수 있는 거죠. 그리고 이제 테스트 서버에서 방금 입력한 게 잘 되기를 기원하죠. 이런 쪽도 있고요. 또 하나로 소셜 게임, 모바일 게임의 예를 하나 들어보겠습니다. 이제 빵 게임을 만든다고 해봐요. 이건 이제 옛날 FarmVille의 이미지인데요. 가상의 게임이라고 한번 생각을 해볼게요. 그리고 여기 건물 아트를 담당하는 아티스트가 있습니다. 이 아티스트는 지금 자기가 만들고 있는 집이 게임에 올렸을 때 어떤 모습이 될지 되게 궁금해요. 그런데 앞서의 이유로 바로 볼 수는 없습니다. 자기가 서버를 만들 수도 없고. 그렇기 때문에 누군가에게 부탁을 해야 하는데, 이제부터 이 아티스트가 집을 보기 위해서 거치는 작업을 한번 따라가 보겠습니다. 먼저 공용 폴더에 네 방향 그림이랑 모델 원본 텍스처를 올립니다. 그러면 이제 프로그래머가 이렇게 입력을 하라고 한 xml 파일을 열어서 조심조심 수정을 하죠. Front.png 이렇게 하면서. 그러면 이제 착한 프로그래머 아니면 시간이 좀 남는 프로그래머, 내 말을 잘 들어줄 것 같은 프로그래머한테 안드로이드 버전에 올리려고 하는데 좀 시연 버전을 만들어 달라고 부탁을 하죠. 프로그래머는 착하니까 이제 공용폴더에서 리소스를 가지고 와서 테스트 빌드를 만들어줍니다. 다 빌드가 끝나면 지쳐서 “테스트 버전 올라갔으니까 받아보세요.” 하면 고마워 하면서 새 버전을 다운로드 받아요. 테스트 폰에서 잘 올라갔겠지 하고 마음속으로 상상을 합니다. 당연히 처음부터 잘 되지는 않죠. 그림이 그림자는 있는데 안 나오고 그래요. 알고 보니까 아까 xml 파일에서 제가 알고 있는 이미지랑 사람들이 알고 이는 이미지 글자가 달랐단 거에요. 그래서 막 별 구박을 다 먹으면서 다시 수정해서 아까 공용폴더에 다시 올립니다. 그리고 프로그래머한테 미안하다고 다시 한번 좀 빌드 해달라고. 물론 겉으로는 화는 내지만 프로그래머는 착하기 때문에 다시 수정된 파일을 반영해서 다시 새 빌드를 만들어 줍니다. 다행이 이번에는 두 번 만에 잘 끝났습니다. 원하는 모습이 나와서 신나 하죠. 그리고 이제 새로운 건물이 올라가고, 새로운 에셋을 만들 때 마다 이 과정을 계속 반복합니다. 그래서 앞서 일들이 도대체 왜 일어나는 걸까요? 제가 이걸 과장하고 재미있게 만들었다고 생각하실 수도 있겠지만 사실 이 앞서의 예들은 실제 라이브 중인 상당수의 팀에서 일어나고 있는 일입니다. 앞서 이야기들의 공통점은 무엇일까요? 먼저 재대로 된 툴이 없습니다. 있더라도 거의 빈사 직전이죠. 아주 불편하거나 불안전하고요. 그리고 두 번째로 약간 부족하고 잘 안 돌아가는 부분을 ‘우리가 힘을 내면 할 수 있어.’ 하면서 각자가 서로의 품을 들여서 메꿔 줍니다. 그리고 마지막으로 이게 가장 중요한 부분인데, 이런 불만과 귀찮음, 비합리성에도 불구하고 놀랄 정도로 오랫동안 이런 상황이 유지가 됩니다. 보통 서비스 종료 때까지 계속되죠. 그래서 왜 이런 것들이 고쳐지지 않을까요? 한번 여러분들 프로그래머 분도 계시고 많은 분들이 계실 텐데 여러분 팀의 동료들한테 프로그래머가 물어본다고 합시다. 그러면 아마 거의 비슷한 반응이 보일 거에요. 왜 툴이 이런 상황이 있는데 안 고치고 있느냐? 그러면 프로그래머는 툴이 약간 그렇긴 한데 “어쨌든 그거 할 시간에 다음 업데이트 빨리 나오면 좋잖아요. 어쨌든 지금 돌아가는 거니까 그거 10분도 안 걸리는데 제가 금방 하죠.” 이렇게 하면서 대수롭지 않게 얘기를 하고요. 기획자와 아티스트는 “좀 불편하긴 하지만 지금 툴로 작업은 다 되고 잘 쓰고 있습니다.” 이렇게 하면서 웃음인지 쓴 웃음인지 모를 대답을 하곤 하죠. 정말 이 정도로 괜찮은 걸까요? 여기서 중요한 부분이 있습니다. 대부분의 여러분의 동료들, 기획자와 아티스트 동료 분들은 불편을 잘 이야기하지 않습니다. 좀더 정확하게 말하면 이야기를 하지 못합니다. 왜냐면 그 분들은 ‘내가 좀 힘들어도 업무는 어차피 어려운 거를 적응해 나가고 익숙하게 만들어 나가는 과정이다.’ 라고 생각을 하고요. 내가 이게 불편하다고 해서 팀의 업데이트가 지금 사람들이 야근하고 있는데 “이거 고쳐주세요.” 이렇게 할 수는 없으니까요. 그래서 동료들은 프로그래머의 시간을 빼앗고 싶어하지 않아요. 현재 주어진 툴과 프로세스가 어쩔 수 없는 최선이라고 만족하면서 이 분처럼 현실을 받아들이기 시작합니다. 그래서 이 이상 바라는 거는 자기의 안위를 위해서 팀을 희생하고 어떻게 보면 ‘나의 능력 부족인가?’ 이렇게 생각을 하면서 입을 닫게 되죠. 그리고 되게 버그가 많고 불안정한 툴을 쓸 때도 거의 비슷한 반응이 나옵니다. 몬스터 ID를 프로그래머가 빨간 색으로 숫자만 입력하라고 썼는데 모르고 영어로 입력했다가 뻑이 났어요. 그 동안 작업했던 게 다 날아갔죠. 이럴 때는 보통 사람들이 화를 내지 않고 ‘내가 사람들한테 숫자를 입력하라고 했는데 알파벳을 쓰다니’ 하면서 ‘나는 입사 3년차인데 언제 이렇게 잘 될 수 있을까?’ 라고 되게 고민을 하죠. 키패드를 써야 되나? 이러면서. 그러다가 힘을 냅니다. 내가 잘못한 거니까 머릿속에 흐름을 들어있으니까요. 그러면서 다시 괴로운 일을 반복합니다. 그러고도 괴로우면 금방 끝나. 이러면서 스스로에게 위로를 하는 말을 내면서 다시 이런 작업을 반복하죠. 그래서 이런 인내와 개인의 희생이 피할 수 없는, 꼭 필요한 일일까요? 기획자가 NPC를 추가하고 이벤트를 추가할 때 메모장을 직접 열어서 프로그래머가 볼법한 그런 것들을 하게 하는 게 자기 직군의 일을 안 하고 다양한 경험을 쌓게 해주는 그런 좋은 일일까요? 그리고 아티스트가 집 하나 보겠다고 이런 복잡한 과정을 거치게 하는 게 팀원간의 협업과 팀원간에 육성해 나가는 그런 훈련일까요? 그리고 진짜 스치기만 해도 죽는 툴을 조심조심 다루도록 하는 게 한번에 실수 없이 신중한 결과물을 내는 게 훈련이 될까요? 그리고 이런 것들을 다 떠나서 앞서의 괴로움들이 과연 저희한테 필요한 일일까요? 저는 그건 아니라고 생각합니다. 불필요한 협업. 그리고 결과물을 보기까지 걸리는 긴 과정. 데이터를 여러 군데서 만드는 중복 작성과 거기서 나오는 불일치. 이런 무언가를 기획하고 만드는 과정에서 실제 제작 과정이 아닌 다른 과정에서 시간과 에너지를 쏟게 하는 거는 커다란 낭비입니다. 여러분 팀에서 이런 보이지 않는 소모. 어쩌면 보이고 있는 그런 시간과 에너지의 소모가 일어나고 있다면 당장 움직여야 합니다. 기획자, 프로그래머, 아티스트 모두 자신이 가장 잘 하는, 자기한테 주어진 본연의 업무에 집중할 수 있게 해야 합니다. 신경 쓰이는, 괴로운, 훈련이 필요한. 다 이런 불필요한 그런 일들을 진짜 겪게 할 필요는 없다고 생각합니다. 자신이 가장 잘 하는 일에 집중하고 그 외의 일을 최소화 하는 변화의 과정은 좋은 툴과 그 툴을 만드는 프로그래머의 역할이라고 생각합니다. 그렇다면 이제 앞서서 툴의 중요성에 대해서 말씀을 드렸고요. 이제 후반부로 툴을 어떻게 만들어야 할까에 대한 이야기를 진행하도록 하겠습니다. 분류를 세부적으로 나눠서요. 일단은 툴을 언제부터 본격적으로 만들면 좋을지에 대해서 이야기를 해보도록 하겠습니다. 앞서서도 제가 툴을 만드는 게 좋고 사람들한테 한다니까 프로토타이핑 단계부터 저희 팀 이름이 아직 정해지지도 않았는데 ‘일단 우리 툴을 잘 만들고 가자.’ 이렇게 하는 게 과연 바람직한 일일까요? 프로토타이핑 기간에는 아직 만들어진 게임의 모습이 결정되지 않은 상태입니다. 어떤 게임을 만들지도 사실 정확하게 모르는 상태인 거죠. 그리고 아직 사람도 다 들어오지 않았을 뿐더러 이걸 어떤 프로세스로 할지도 결정되지 않은 상황에서 툴을 만들어보자. 이렇게 하는 거는 무리한 생각입니다. 그리고 이 단계야 말로 1시간, 1분, 1초 시간 자체가 굉장히 소중한 자원이기 때문에 툴을 만드는 데 기회를 낭비하기란 사실 되게 쉬운 결정이 아닙니다. 그리고 지금까지 만들고 있었던 것들을 한꺼번에 엎고 다시 새로운 방향으로 가는 빠른 의사 결정의 전환이 그 어느 때 보다 중요한 시기이기 때문에 어느 정도 프로세스를 정형화 하는 데 집중하고 툴의 개발은 여기서 잠깐 지양을 할 필요가 있습니다. 그렇기 때문에 프로토타이핑을 마친, 그리고 프리 프로덕션이 끝나고 본격적인 프로덕션으로 가는 직후. 보통 이 타이밍에 재정비 기간을 거치게 되는데요. 그 타이밍에 이런 툴의 개선 그리고 프로세스의 개선에 집중하는 것이 좋습니다. 그리고 이거는 앞에서는 새 게임을 만드는 쪽의 상황이었고요. 여기 계시는 대부분의 분들이 라이브 업무를 하고 계실 텐데요. 라이브 업무를 진행중인 팀에서는 어떻게 해야 되느냐? 어느 타이밍이 가장 좋으냐? 당연히 지금 당장 진행해야 합니다. 내일 모래 패치거나 다음 주에 대규모 업데이트. 이런 타이밍만 아니라면 지금 당장 저희 프로세스를 다시 점검하고 개선을 진행해야 합니다. 타이밍에 대한 말씀을 드렸고요. 이 다음에 어느 프로그래머가 툴을 만들어야 하는지에 대해서 말씀 드리도록 하겠습니다. 이제 시간도 났고, 툴을 만들어야 될 것 같으면 보통 고민을 하게 되죠. 프로그래머 팀장님께서 대부분의 개발팀에서는 신입 사원 맡게 됩니다. 이런 분들. 보통 이런 말을 해요. 툴을 만들면서 우리 게임분위기도 익혀보고, 어떤 게 있는지 한번 알아보니까 되게 도움이 될 거에요. 그렇게 되죠. 그런데 이제 그 분한테는 툴을 제작하는 게 굉장히 성장할 수 있는 기회가 되겠지만 좋은 툴을 만드는 데에서는 사실 이거는 다른 소양이 필요하다고 생각합니다. 좋은 툴을 만들기 위해서는 다른 직군의 업무 방식에 대한 이해를 할 수 있는 사람. 그리고 프로세스 전체를 보고, 아니면 프로세스를 많이 경험해 봤던 사람들이 시야가 넓은 사람이 필요하죠. 그렇기 때문에 저는 신입 사원이 참여하는 것도 좋긴 하지만 전체적인 툴의 진행 그리고 관장, 앞으로의 스케줄링 이런 모든 부분에 대해서 리드 프로그래머 그리고 시니어 프로그래머가 적극적으로 참여를 해야 한다고 생각합니다. 툴이 계속 신입 사원이 맡고 있었던 그런 문화 때문에 별로 도움이 안 되는 일로 생각을 하시는 분들이 굉장히 많이 있는데, 저는 툴이야 말로 굉장히 많은 것들을 할 수 있는 사람이 직접 맡아야 된다고 생각합니다. 툴을 누가 만드는 가에 대해서 말씀 드렸고요. 그리고 본격적으로 툴 제작을 하기 전에 준비해야 할 것들에 대해서 말씀을 드리겠습니다. 당연히 현재 상황에 대해서 점검하는 게 필요하죠. 보통 처음에는 현재 쓰고 있는 툴에 대한 피드백을 받고자 합니다. 동료들한테 불편한 점을 물어보고 쓸만한지 물어보게 되죠. 물론 이거는 당연히 중요합니다. 불편한 점을 물어보고 이런 자세는 반드시 가져야 하는 자세인 거죠. 그런데 ‘옆자리에서 이거 불편하다고 했으니까 이거 고치면 툴 개선 끝나겠네요?’ 하고 이 상황에서 멈춰버리면 안 됩니다. 왜냐면 인터뷰로 얻을 수 있는 정보에는 약간의 제약이 있습니다. 굉장히 인터뷰를 통해서 직접 듣게 되는 정보는 굉장히 부족하거나 상황이 되게 불 명확할 때가 많습니다. 그런데 앞서서도 말씀 드렸지만 대부분의 사람들이 현재의 상황에 ‘그럭저럭 괜찮은 것 같아요.’ 하면서 마지막에 살짝 눈을 돌리는데 이게 무슨 뜻인지 모르겠죠. 그러면서 ‘생각보다 괜찮은가?’ 왜냐면 툴을 만들었던 프로그래머들 앞에서 ‘이 툴 별로 에요.’ 이렇게 말할 수도 없고, 아까 말했듯이 ‘이것까지 고쳐달라고 하는 건 내 욕심이 아닐까?’ 이런 생각을 하기 때문에 자체적으로 필터링을 하고 말을 하지 못하는 상황들이 생깁니다. 그리고 누군가가 문제라고 얘기를 한다고 하더라도 전해들은 문제의 원인과 실제 진짜 원인은 같지 않을 경우가 굉장히 있습니다. 현상에서 나타나는 원인과 그거를 야기하게 된 진짜 원인은 무엇인가를 알게 됐을 때는 꽤 차이가 나는 경우는 많거든요. 그래서 인터뷰도 중요하고 해야 하는데 그것보다는 한 단계 더 나아가서 저희가 해야 할 것은 바로 기획자, 아티스트, 프로그래머가 어떻게 일을 하는 지를 관찰하는 것입니다. 그래서 각 직군 별로, 그리고 동료들이 하고 있는 일들의 프로세스를 한번 따라가봅시다. 물론 간단한 시연을 받으면 좋겠죠. ‘이 툴을 쓰는 방법 좀 알려주세요.’ 이렇게 한 시간 정도 옆에서 보고 있으면 되게 좋고요. 그리고 프로그래머가 그 과정을 직접 해보면 좋습니다. 그림을 그리라는 말씀이 아니고요. ‘툴을 이렇게 해서 어떤 식으로 하시네요.’ 이런 것들을 직접 해보는 거는 보는 거랑 엄청난 차이가 되죠. 그래서 이런 것들을 좀더 얻을 수가 있습니다. 아까 인터뷰를 통해서 사람들이 약간 모호하게, 아니면 돌려서 얘기했던 말들의 진짜 의미. 그리고 툴을 직접 써보면서 느끼는 데에 자기 스스로 느끼는 갑갑함. ‘이런 거를 참고 쓰고 있었구나.’ 그리고 아까 말씀 드렸던 사람들이 애기했던 문제의 원인과 직접 보면서 알게 된 진짜 문제의 원인. ‘그냥 단순하게 이걸 고친다고 해결 될 문제가 아니구나.’ 라는 것들에 대한 인사이트를 얻게 되는 거죠. 이거 너무 진부한 그림이어서 안 쓰려고 했었는데… ‘사람들이 나는 이걸 원한다.’ 라고 생각하는 것 그리고 그렇게 말하는 것과 진짜 사람들이 필요로 하는 것을 잘 엮고 그걸 파악하는 것이 중요합니다. 그래서 필요성에 대한 어떤 사전 조사는 끝났고요. 이제 할일 목록이 완성 됐어요. 어떻게 어느 부분부터 만들어 갈지를 생각해봅시다. 보통 다 취합을 하고 나면 이렇게 긴 목록이 만들어지죠. 보통 여기서는 한 5페이지 정도인 것 같은데, 실제로 몇 십 페이지가 되는 요구사항들이 나오게 됩니다. 그러면 이제 그런 것들을 다 할 수는 없죠. 어떤 부분에 집중을 해서 만들어 나갈 것들을 정의해야 합니다. 우선은 툴이 없으면 개발이 불가능한 것부터. 이건 당연한 얘기죠. 기본적인 에디터라든가 그런 것들부터 작업을 하고, 작업 프로세스가 너무 쓸데없이 복잡한 것부터. 아까 말씀 드렸던 그림. 그런 부분이라던가 그런 부분들을 줄여 나갈 수 있는 거에 집중을 하고, 어느 정도 개선이 됐다고 생각하면 ‘이거 왜 손으로 직접 하고 있어요?’ 라는 생각이 딱 드는 자동화 가능한 일들을 개선시켜 나가는 방향으로 만들어 나가시면 될 것 같습니다. 그리고 큰 계획, 내가 만들고 있는 툴의 통합 툴을 만들어서 다 관리할 수 있게 하겠어. 이런 어떤 큰 계획을 세우는 거는 중요합니다. 계획을 세우는 건 중요한데, 만들어 나갈 때는 작은 것부터 하나씩 꾸준히 만들어 나가는 것이 중요합니다. 앞서 얘기했던 팜 게임의 집 보기를 한번 예로 다시 한번 들어봅시다. 과정을 다시 따라가 보면, 집 그림을 폴더에 올리고요. 그리고 이걸 XML로 고치고, 프로그래머한테 얘기하고, 빌드를 하고, 기다리고 다운로드 받은 다음에, 문제가 생겨서 다시 이 방법을 반복하고요. 그래서 이런 집 하나 보겠다고 수 많은 불 필요한 일들을 하게 됩니다. 그래서 처음에 의욕에 차서 프로그래머가 ‘툴로 이 과정을 완전 자동화를 해보겠어.’ 이렇게 시작을 하는데, 막상 시작을 하려고 보면 할 일이 너무 많고 일이 커지게 됩니다. 이런 게 나오겠죠. 공통 폴더에 아티스트가 올리면 이걸 감지해서 테스트 버전에 빌드를 하고 소스를 가져와서 전용 테스트 서버를 올리고, 그거를 폰에 자동으로 배달을 하는 이런 것들을 만들자고 처음에 의욕에 차서 하게 되죠. 그런데 이거는 진짜 한 명이 아니라 한 팀이 와서도 할 수 없는 규모의 굉장히 큰 일이 됩니다. 그래서 보통은 이 타이밍에 포기를 하게 되죠. 그러면서 아티스트한테 되게 미안한 표정을 지으면서 “이런 과정이 있기는 한데 들여야 될 노력이 너무 많아요.” 라거나 조금 연차가 찼으면 “이거 하려면 다 갈아 엎어야 되요.” 이러면서 생각보다 쉬운 일이 아니에요. 이렇게 하면서 상황을 정리하죠. 그러면서 아무 일도 없다는 듯이 다시 이전의 프로세스로 돌아가게 됩니다. 그래서 명심해야 할 점이 하나 있는데요. 모든 프로세스 전체를 커버하는 툴을 처음부터 만들려고 하지는 않아야 합니다. 그래서 프로세스 개선, 물론 꿈은 크게 갖는 것이 중요하지만 그런 거창한 목표로 시작은 하지 마세요. 중요한 거는 순간 순간을 줄여주는 것입니다. 가장 짜증을 느끼는 그리고 가장 어려움을 느끼는 곤란한 그런 부분들을 찾아내고 그 부분을 줄여주는 일부터 시작을 해주세요. 그래서 우리 아티스트와 기획자와 동료 프로그래머가 진정으로 원하던 것이 무엇이었는 가를 앞에서 관찰과 인터뷰들을 통해서 다시 알아낼 수가 있습니다. 앞서의 예에서 아티스트가 원한 것을 다시 한번 생각해 볼게요. 아티스트가 원한 거는 딱 한 가지에요. 내가 만든 집이 게임에 올리면 어떻게 보일까? 단순히 그거 하나를 알고 싶은 겁니다. 그래서 정말 뭔가 완벽한 테스트 과정을 통하지 않아도 이런 단순해 보이는 맵 뷰어, 배경 아무거나 스샷 찍어서 선택하고 파일 끌어 넣으면 ‘이 툴 아무것도 아닌 것 같은데…’ 저희 프로그래머들이 이렇게 생각을 하더라도 아티스트들에게는 ‘이게 내가 원하던 거야.’ 결국은 아티스트가 원하는 것들의 적어도 50%는 커버가 되겠죠. 물론 되게 복잡한 거를 원하는 사람도 있겠지만 이런 요청의 50%만 커버가 되더라도 아까 말했던 그런 복잡한 과정들이 절반을 줄어든다는 겁니다. 그래서 정말 소소해 보이는, 별거 아니고, 이렇게 하면 되겠지. 라고 하는 일들이라도 막상 그게 생기고 개선이 되고 나면 중요한 흐름을 바꿔줄 수가 있습니다. 그래서 큰 목표는 세우되 사람들이 원하는 작은 것부터 하나씩 꾸준히 만들어 나가는 것이 중요합니다. 우선 순위에 대한 말씀을 드렸고요. 이제 툴을 만들 때 어느 부분에 포커스를 맞춰서 만들면 좋을 지에 대해서 말씀을 드리겠습니다. 당연한 얘기지만 아티스트가 원하는 편한 방법. 그리고 2D 아티스트, 3D 아티스트가 원하는 편한 방법. 기획자, 프로그래머가 원하는 편한 방법은 모두 다릅니다. 그래서 이럴 때 가장 좋은 방법은 각 직군의 사람들이 익숙하게 쓰고 있는 도구와 최대한 비슷한 기능들을 만들어 가는 겁니다. 포토샵, 플래쉬, 맥스, 워드, 엑셀. 이런 것들이 보통 아티스트와 기획자가 많이 쓰는 툴이죠. 평상시에 어떤 툴을 쓰고 있는지 찾아내고 그 쪽에서 굉장히 편리하게 만들어둔 개념들을 많이 차용을 해나갑시다. 포토샵에는 레이어가 있고요. 오른쪽에 맥스에는 gizmo가 있죠. 그리고 플래쉬의 타임라인. 오피스에 버튼 복잡하게 나열한 것보다는 사람들이 거의 표준으로 쓰고 있는 리본 인터페이스 같은 것들을 하면 굉장히 UI들에 대한 고민들도 줄일 수 있으면서 사람들한테 별도의 학습이나 이런 과정을 거치게 할 필요가 없습니다. 그리고 툴이 아니더라도 웹이나 이런 곳에서 많이 쓰고 있는 자동 완성과 같은 기능들도 굉장히 중요합니다. 일단 여기는 넥슨이라고 해놨는데, 예를 들면 아이템 코드를 보려고 했을 때 뭔가 버튼 눌러서 사전을 열고 보는 것 보다는 그 자리에서 이런 식으로 자동완성을 되게 하는 것들이 나오면, 순간순간 하나만 놓고 보면 2초~3초 정도 일을 단축시켜 주는 거지만 그게 누적이 되면 엄청난 시간과 에너지의 절약을 가지고 올 수 있습니다. 그래서 동료들이 이런 툴들을 어떻게, 어떤 범위를 쓰고 있는지 잘 다시 한번 그런 내용들도 관찰을 하고 기억해두도록 합시다. 그리고 툴을 만들 때 좀 빠질 수 있는 주화입마에 대해서 말씀을 드려 볼게요. 제가 드리고 싶은 말씀은 툴의 자유도, ‘이 툴은 정말 어떻게든 확장시킬 수 있어’ 라는 것과 강력함, ‘이 툴로 게임의 모든 거를 할 수 있어.’ 이런 것들로 굉장히 멋진 툴을 만들려고 하는 분들이 굉장히 많이 있어요. 하지만 이런 자유도와 강력함은 좋지만 불편함과 맞바꿔져서는 안 됩니다. 예를 들어서 정말 모든 거를 할 수 있는 다양한 이런 툴이 있다고 해요. 이런 툴이라든가 강력한, 할 수 없는 게 없는, 이런 강력한 툴을 사람들이 좋아할까요? 앞서서 드린 말씀은 결국은 불편한 툴을 만들고 나서 ‘나는 이게 내가 보기에는 좋다.’ 라고 하면서 사용을 절대 강요하지 맙시다. 사실 여기서는 프로그래머가 좀 불만이 생길만한 부분이긴 해요. ‘솔직히 이 정도도 안 배우고 어떻게 툴을 쓰려고 하냐? 이 정도는 누구나 조금만 배우면 쓸 수 있는 거 아냐?’ 라고 보통 생각을 하시게 되는데요. 솔직히 프로그래머는 다른 직군과 로직의 구조, 흐름, 게임 메카닉, 데이터의 정리 이런 것들에 대한 이해와 숙련도가 월등히 뛰어납니다. 이거는 계속 프로그래머 분들한테 뭐라고 해서 칭찬하는 글이고요. 그런데 당연히 기획자와 아티스트는 그런 이해 범위와 속도 면에서 프로그래머와 차이가 날 수 밖에 없습니다. 제가 그림을 잘 그리지도 않고요. 기획을 잘 하지 못하는 것처럼 앞서 프로그래머에게 필요한 소양이었던 부분들을 기획자와 아티스트가 똑같이 가지고 있으리라고는 보통 기대하기가 어렵죠. 그리고 이런 차이는 마찬가지로 단시간의 훈련, ‘프로그래머처럼 생각하기’ 이런 거를 통해서 좁혀질 수 있는 부분이 아닙니다. 그래서 사람들이 툴을 모르기 때문에 내가 가르쳐줘야겠다. 이런 방식으로 접근해서 그런 간극을 좁히려고 노력을 하기 전에 그냥 이 상태로도 가장 쓰기 좋은 툴을 만들려고 노력을 합시다. 그래서 가장 좋은 거는 배우지 않아도 쓸 수 있는, 이미 익숙하게 알고 있는 개념으로 쓸 수 있는 작업 흐름과 도구들을 제공하고, 만약에 배우더라도 정말 배움을 최소화 할 수 있는 그런 툴들을 만들어 나갑시다. 툴을 만드는 쪽에 대해서 쭉 말씀을 드렸고요. 후반부의 두 개는 제작 이후의 일들에 대해서 말씀을 드리도록 하겠습니다. 보통 그때의 필요에 따라서 작은 툴을 만들면 처음d에 되게 좋아하고 뿌듯해하지만 갈수록 유지보수가 잘 되지 않습니다. 아까 이런 툴이 나오면 아티스트는 되게 좋아하죠. ‘드디어 맵뷰어가 나왔구나.’ 기능들이 확장되고 고맙다는 말을 하죠. 그런데 시간이 지나고 두, 세 달이 지나도 이 맵 툴은 계속 그대로입니다. 아직 돌아가긴 하지만 약간 실망스럽죠. 이제 툴 폴더에는 수십 개의 툴이 있지만 어떤 것들은 동작하지 않고 어떤 것들 은 ‘내가 이거 만들어 줄게. 조금만 기다려.’ 폴더만 만들어 놓고 미완성 상태에 머무르게 되죠. 그런데 프로그래머는 이 툴을 어떻게든 쓰고 있겠지. 라고 생각을 하지만 보통 툴을 쓰는 사용자들은 원하는 기능이 없으면, 무언가 문제를 일으키면 별 말을 하지 않고 그냥 사용을 멈춰버립니다. 저희 게임 유저들과 같죠. 나중에 ‘이거 왜 툴 안 쓰고 있어?’ 라고 하면 ‘지난번 패치 이후부터 뻑나서 안 쓰고 있는데?’ 이렇게 얘기하면서 그냥 사용을 안 해 버리고 이전 방식으로 돌아갑니다. 그러면 이런 툴이 앞에서 말씀 드린 맵툴과 같은 삐걱이는 구닥다리 툴이 돼버리는 거죠. 그래서 만들어진 툴에는 반드시 관리 책임이 따라야 합니다. 보통 이게 정말 잘 되지 않는데요. 제공하고 있는 툴에 대해서는 언제부터 언제까지 유효기간 같은 것들을 통해서 이 툴을 제공하는 기간에 대해서 명확하게 잡고, 만들어진 툴은 게임이 업데이트 되어 나가면서 항상 돌아갈 수 있도록 잘 관리를 해야 합니다. 그리고 마지막으로 피드백이라는 생소한 부분에 대해서 말씀을 드리겠습니다. 이제 툴을 유지하고 죽지 않게 하는 것도 중요하지만 프로그래머가 툴을 만들고 나서 툴이 의도한 대로 내가 생각했던 대로 쓰이고 있나? 라는 거를 살펴보는 것도 굉장히 중요합니다. 인터뷰, 뒤에 가서 관찰하고 이런 것들을 통해서 사람들이 잘 쓰고 있는지 볼 수 있겠죠. 그런데 사실 프로그래머의 시간과 자원과 노력은 사실 한정되어있기 때문에 좀더 다른 관점에서, 온라인 게임에서 저희가 시도하고 있는 여러 가지 분석 기법을 도입해 보는 것도 굉장히 도움이 됩니다. 우리가 만든 게임과 서비스에서 요즘 사용자들의 패턴을 읽기 위한 노력은 굉장히 많이 준비되어있죠. 이런 analytics 툴을 쓰기도 하고요. 그리고 어떤 맵에서 많이 죽는가? 이런 거에 대한 것들을 시각적으로 보려고 하기도 하고, 오른 쪽은 웹 페이지에서 사람들의 시선이 어떻게 옮겨 가는가? Dl런 것들을 굉장히 하나씩 보고 기획자의 의도 아니면 우리의 의도와 다른 방향으로 움직이고 있는 것들이 어떤 것들인지를 관찰하려고 합니다. 이 방법을 저희 툴에도 동일하게 적용해 볼 수 있습니다. 동료들에게 개인 정보 수집에 대한 동의처럼 사용 정보에 대한 수집에 대한 동의를 구하고요. 그리고 이제 한번 어떤 부분들을 클릭할 때나 사용할 때나 이런 것들 것 있을 때 마다 로그를 남겨서 그거를 한번 분석을 해봅시다. 이렇게 하면 어떤 기능을 언제, 어느 시점에, 어느 빈도로 사람들이 사용하고 있는지. 그리고 직군 별로 아니면 특정한 사람들은 이 기능을 안 쓰고 있네? 라는 것들을 볼 수가 있습니다. 그러면 당연히 예상과 빗나가는 지점이 생기게 되고요. 그러면 그 사람들을 만나서 ‘이 기능을 요즘 안 쓰는 것 같던데 무슨 문제가 있냐?’ 크래쉬가 난다던가 아니면 내가 원하는 기능이 안 된다던가 하는 좀더 디테일하게 피드백을 받을 수 있는 굉장히 좋은 도구가 됩니다. 이런 과정에서 궁극적으로는 프로그래머가 자신이 편하다고 생각했던, 자신이 맞다고 생각했던 작업의 흐름과 실제 사용자들이 느끼는 어떤 편안한 거에 대한 차이에 대해서 깨닫고 발전할 수 있는 기회가 됩니다. 그래서 툴을 만든 노력만큼 이후에 사우 지원, 업데이트와 그 결과 측정에도 굉장히 신경을 써야 합니다. 오늘 이야기가 거의 마무리 되어가는데요. 오늘 굉장히 많은 말씀을 드렸는데 제가 하고 싶은 말을 한 문장으로 줄이면 다음과 같습니다. 가장 중요한 것은 같이 일하는 동료들에 대한 존중입니다. 팀의 동료들이 일하는 모습을 한번 관심을 가지고 지켜봐 주시고 살펴봐 주세요. 그리고 어려워 하는 일이랑 어떤 부분에서 괴로워 하고 있는 지를 한번 찾아내세요. 그런 것들을 돕고, 굉장히 별 일 아니라고 생각하는 조그만 도움이라도 그 사람이 일하는 방식 그리고 우리 팀이 일하는 방식은 굉장히 크게 바뀔 수가 있습니다. 그리고 디렉터와 PM 분들은 프로그래머가 이런 일을 할 시간을 낼 수 있도록 시간과 리소스를 내 주세요. 당장은 굉장히 빠듯한 일이겠지만 결과적으로는 1~2년도 생각할 필요 없이 1~2달 뒤가 되면 훨씬 더 이득이 되고 팀이 건강해 지는 지름길입니다. 그래서 앞서 말씀 드린 것처럼 잡다한 과정이 사라지면 가장 좋은 점은 우리와 우리의 동료들은 게임 자체에 더 집중을 할 수 있게 됩니다. 좋은 툴과 프로세스는 단순히 작업량, 시간. 이렇게 정량적인 부분만을 줄여주는 것이 아닙니다. 미처 느끼지 못했던 그리고 사람들이 느끼고 있더라도 말하지 못했던 굉장히 어렵고 힘들고 괴로운 개발 문화를 바꿔줄 수 있는 좋은 계기가 됩니다. 게임에서의 사용자가 어떻게 느끼는 경험에 대해서 생각하고 고민하는 것 만큼 우리 동료들의 작업 환경에 관심을 가져주세요. 라이브 중인 조직이 건강하게 유지될 수 있는 보이지 않은 힘이 되어줄 거라고 확신합니다. 감사합니다. 질문은 이 자리를 통해서 받도록 하고요. 혹시 추가 질문이 있으시면 여기 홈페이지 통해서, 여기 홈페이지 오시면 연락처가 있으니까 이쪽에서 말씀을 주시면 될 것 같습니다. 조그만 툴도 하나 있고요. 질문을 굉장히 많이 해주셨는데,
“툴 개발만 전담하는 파트를 구성하고 있나요?”
네. 이거는 팀의 규모와 상황에 따라서 굉장히 다릅니다. 제가 있었던 팀에서는 어느 쪽에서는 툴 개발 전담을 하는 쪽이 있었고 어느 팀에서는 그냥 라이브 게임을 개발하는 도중에 툴을 만들어 가는 과정이 있었는데요. 장단점은 있습니다. 물론 툴을 개발하는 팀이 별도로 신설이 된다면 생산성이나 목표 의식에서는 좀더 명확해지겠지만 시간이 지나갈수록 실제 작업 프로세스와 경향, 지금 팀의 흐름과는 동떨어진 결과물이 나올 가능성이 굉장히 높습니다. 그래서 가능하다면 지금 실제 게임 업데이트 업무를 같이 하면서 중간중간 로테이션이나 각자 툴을 하나씩 담당해서 맡아가는 게 좀더 나을 것 같고요. 그런데 급하고, 단기적으로 집중해서 개발할 거라면 팀이 있는 것도 나쁘지 않습니다.
그리고 “동료가 어느 정도 괴로울 때 툴을 개발하는 게 좋을까요? 개발할 시간에 그냥 도와주는 것이 나는 경우도 있잖아요?”
네. 이건 저도 정말 많이 고민했는데요. 결국은 그런 생각을 했습니다. 제가 쓰는 시간과 이 툴을 만들었을 때 세이브할 시간을 생각해봤어요. 기간을 1년 정도로. 제가 20분 정도를 도와준 거를 1년 정도 했을 때, 물론 저한테는 별로 아닐 수도 있겠지만 제 옆에 있는 프로그래머도 그걸 하게 되고 다른 기획자도 그런 업무를 하게 되면 사실 이게 사람 수와 시간에 기간을 곱하게 되면 결국은 정말 이 프로젝트를 3번 정도 하고 끝날 일이 아니라면 웬만한 반복되는 일들은 툴로 편리한 기능을 제공하는 게 굉장히 중요합니다.
“10년동안 서비스하고 있는 라이브 팀에서 일하던 UI 디자이너 입니다. 툴이 너무 오래되고 UI 전용 툴이 아니다 보니 일하면서 대부분의 작업은 디자인 작업보다 툴에 등록하는 작업에 대부분의 시간이 할애되어서 매우 힘이 들었습니다. 강연해 주신 내용처럼 툴의 개선을 위해서는 의식 변화부터 시작해야 한다고 생각하는데요. 다른 사람들에게 툴의 중요도를 더욱 강하게 인식시키려면 어떻게 해야 할까요?”
가 좋아요가 10개가 나왔네요. 사실 오늘 저도 이 부분이 중요하게 돼서 이 세션을 준비하게 됐고요. 결과적으로는 프로그래머가 동료들에게 관심을 갖게 해주는 부분이 중요하다고 생각합니다. 그런데 그렇다고 해서 기획자 분이나 아티스트 분들이 ‘나한테 좀 신경 써라.’ 이렇게 사실 애기할 수는 없잖아요? 그렇기 때문에 이런 부분들은 디렉터와 PM들에게 어떤 문제의 상황이나 이런 부분에 대해서 인식을 시켜주는 게 굉장히 중요하다고 생각합니다. 결과적으로는 약간 한계가 있는 답변인 게, 결국은 그 PM과 디렉터가 이 툴이라는 것들에 대한 중요성을 인식하지 않으면 사실 설득이 굉장히 어려운 일인데요. 특정 프로그래머의 도움, 개인의 희생을 요청해서 툴을 만들어가기 보다는 조직 문화가 효율적인 프로세스와 그게 왜 사람들을 행복하게 만드는지에 대한 그런 거를 동조를 해야 한다고 생각합니다. 결과적으로는 굉장히 무리한 얘기이긴 한데 이 부분들은 디렉터와 PM에게 설득을 하는 수 밖에 없을 것 같습니다.
“저희는 툴이 필요한데요. 말하면 그 사람이 만들게 됩니다. 말하기가 너무 무섭습니다. 개발의 배분은 어떻게 하나요?”
이거는 되게 가슴 아프네요. 보통 이 내용들에 대해서 앞서서 말씀 드렸지만 업무를 배치하는 입장에 있는 사람들이 적극적으로 좀더 툴을 만들어 나가야 한다고 생각합니다. “그래. 이거 좋은데 니가 한번 만들어봐.” 이거는 정말 무책임한 말인 것 같아요. 여기서 말씀 하셨던 직접 만들어 보라는 말을 했다는 사람은 그 일을 지정하는 사람일 거잖아요? 사실 그 사람이 만들어야죠. 본인이 만들고, 아이디어를 제안하고, 본인이 정말 잘 할 수 있다면 기꺼이 맡는 것도 나쁘지는 않습니다. 그런데 보통 하게 될 때는 그런 의사 결정 먼저. 그렇기 때문에 리드 프로그래머 또는 시니어 프로그래머가 만드는 게 맞다고 생각합니다.
“툴 개발 시 스크립트를 붙인 에디터에 대한 내용이 있었는데요.”
이거는 지금 이 자리에서 설명 드리기에는 앞으로 질문시간이 많지 않아서… 저한테 메일 주시면 제가 아는 범위 안에서 답변 드리도록 하겠습니다.
“개발의 전반적인 과정을 혼자서 하는 개발 환경의 경우. 이때도 툴을 개발하는 것이 유용할까요? 아니면 그것에 할애할 시간에 개발에 집중하는 것이 유리할까요?”
이거는 자기 자신과 대화를 하시면 됩니다. 내가 이거를 이렇게 견디면서 할 수 있을 것인가? 그거는 자기 마음이죠. 물론 아까 말씀 드렸듯이 우리는 툴이 최고야. 그런데 게임은 느려. 어떤 개발 초기 단계나 게임을 혼자 만들게 되면 굉장히 빠른 개발을 하게 되는데, 그런 부분들에 있어서 프로세스라는 게 사실 없잖아요? 개인이 정한 프로세스니까요. 그런 것들은 어떻게 보면 좋은 툴이 많이 갖춰지지 않았다고 해서 그 팀에 결격사유가 있는 거는 아닙니다. 1인 개발에서는요. 이런 부분을 너무 마음에 두지 마시고 ‘귀찮아서 못해먹겠네.’ 딱 그 생각이 드는 순간부터 개발을 하시면 될 것 같습니다.
“퍼블리셔를 위해 제작사가 툴을 만들어 줘야 되는 경우 같은 거는 어떻게 무난하게 넘어갈 수 있을까요?”
보통은 계약 관계에 있기 때문에 무난하게 넘어갈 수가 없습니다. 이거는 약간 가슴 아픈 이야기지만 이거는 계약 상황에 따라서 유연하게 대처하시면 될 것 같습니다.
“모르는 언어로 만들어진 툴의 경우 수정이 어려운데요. 모르는 언어를 공부할지, 툴을 새 언어로 만들지 기준이 될 만한 게 있을까요?”
보통 기준의 하나가 이 툴이 어느 언어로 쓰여졌는지 보다는 이 툴이 작성된 언어가 게임이랑 굉장히 잘 바인딩이 되어 있느냐. 그리고 이 툴에서 쓰고 있는 언어가 우리 동료 프로그래머들이 잘 알고 있는 언어냐 가 중요한 것 같습니다. 정말로 자기가 모르는 언어인데 사람들이 다 고치고 있고, 이 툴에 문제가 생겨서 고쳐야 됐을 때 옆에 동료들도 다 할 수 있는 거라면 자기가 그 언어를 배워야죠. 그런데 그게 아니고 익숙하지 않고 게임에도 연동되어 쓰이지 않는 언어라면 교체를 해줘도 괜찮다고 생각합니다. 
“라이브 운영 시 발생하는 프로그래머, 기획자, 디자이너 사례로 설명을 해주셨는데, 라이브 운영시 발생하는 문제들로 생기는 서비스 운영 툴로 인한 문제나 사례들은 어떤 경험들이 있으셨는지 궁금합니다.”
죄송한데 이 부분은 제가 경험이 많지 않기 때문에 제가 적절한 대답을 드릴 수는 없을 것 같습니다. 패스하겠습니다.
“다 다루는 툴이 다르겠지만 장르의 구분 없이 공통적으로 사용되는 툴들이 있다면 어떤 것이 있을까요?”
사실 이거는 좀 지양을 해야 될 부분이라고 볼 수가 있는데요. 공용 게시판이나 공용 폴더 시스템, 협업 게시판, 메신저. 이런 어떤 커뮤니케이션 수단으로서의 공용 툴은 몰라도 모든 사람들에게 만족 시켜줄 수 있는 툴을 만들 수는 없다고 생각합니다. 그래서 만드실 때 ‘이거는 최대한 많은 사람들이 써야 되니까 기획자도 편하고, 프로그래머도 편하고, 아티스트도 할 수 있는 툴을 만들어야지.’ 이렇게 하다 보면 망트리를 타게 되고요. 그렇기 때문에 한, 두 명의 요청 그리고 소수 그룹의 요청이더라도 최대한 개별적으로 편리하게 만들어 줄 수 있는 기능을 만드는 게 중요합니다.
“디자이너나 기획자가 툴이 필요하다고 느낀 경우게 직접 그 사람이 툴을 만들어야 되나요? 프로그래밍을 할 줄 모르는 상황에서요.”
정말 비추 드리고 싶습니다. 결과적으로 아까 말씀 드렸듯이 툴을 하나 만든다. 이런 게 있었으면 좋겠다. 라고 생각한 거랑 그거를 만들어 나가는 과정, 그거를 문제 없이 완결성 있게 만들어나가는 과정은 사실 전공이 아니면 굉장히 밟아나가야 될 과정들도 많고, 그 시간에 본인이 하고 있는 일을 잘 하고 프로그래머를 설득하는 게 나을 것 같습니다.
올라온 질문들은 여기까지고요. 더 궁금하신 점 있으면 홈페이지를 통해서 문의 주시기 바랍니다. 오늘 많이 와주셔서 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
