팀을 구하는 툴 개발

박경재

요약

• 적절한 툴을 만들어 작업의 비효율을 줄이고 고통받는 동료를 구원하자.
• 그러기 위해서 높으신 분들은 이에 대한 필요성을 인지하고 자원 분배를 잘 하자.

도입

• 게임 개발 시 동료가 겪는 불필요한 괴로움을 극복하기 위한 툴과 마음가짐
• 라이브 서비스를 하면서 고객의 불편/불만 사항은 개선하지만, 개발자 우리들의 불편/불만 사항은 개선하지 않는다.

• eg) 퀘스트 입력

  • 기획자가 excel 파일로 데이터를 입력해서 프로그래머에게 데이터 파일로 만들어달라고 요청
  • building 후 테스트 진행. 마음에 안 들면 위 항목 반복
  • 이 과정에서 excel 파일과 서버 데이터 파일의 불일치가 발생해 버그가 발생하기도 하고, 무엇보다도 비효율적이다.

• eg) map editor

  • 옛날에 처음 만들었을 때에는 잘 돌아갔지만, 제작자 퇴사 이후 뭔가 잘 안 돌아간다.
  • 저장하면 일부 파일이 깨지거나 parameter가 날아간다.
  • 이 상황에서도 툴을 고치지는 않고 조심조심 사용한다. 1. 초벌 배치를 하고, 2. 필요한 부분을 손으로 채워넣고, 3. 잘 동작하기를 기도한다.
• eg) mobile social game _ 리소스 추가 시 확인해보기 위해 building 요청 등 고생을 한다. _ 사소한 실수에 의해 위 작업을 반복하므로 테스트 비효율이 심각하다.

• 왜 이런 일이 일어나는가?

  • 제대로 된 툴이 없거나 부족하기 때문에 그 부분을 작업자의 희생으로 메꾼다.
  • 그럼에도 툴을 개선/개발하지 않고 현 상태를 유지한다.
  • 프로그래머는 툴을 만들 시간에 게임 피처를 추가하는 것이 더 낫다고 생각한다.
  • 기획자/아트는 현재 툴을 일단 쓸 수는 있다고 생각하고, 요청에 대한 부담으로 툴 개선/개발 이야기를 하지 않는다.
  • 만약 툴이 잘못 동작해도 잘못 사용한 본인 탓을 하거나,
  • 프로그래머에게 개선/개발 요청하는 것을 본인의 이기주의라고 생각한다.

• 하지만 이런 인내와 희생은 필요하지 않다.

  • 툴 부족으로 인한 불필요한 협업은 비효율과 낭비를 야기한다.
  • 자신이 가장 잘하는 자기 일에 집중할 수 있도록 작업 과정은 최소화되어야 한다.
  • 이를 위해서는 좋은 툴이 필요하고, 이것은 프로그래머의 일이다.

툴 만들기

• 타이밍

  • prototyping 시점은 게임과 작업 프로세스가 미확정된 시점이고, 시간 자원이 중요하고 빠른 의사결정이 중요한 시기다. 따라서 이 시점에 툴 개발은 불필요하다.
  • 따라서 prototyping 이후 pre-production 단계 즈음에 툴 개발하는 것이 좋다.
  • 만약 이미 라이브 중이라면, 가능하면 지금 당장 만들자.

• 주체

  • 툴 개발자로 보통 신입 사원을 시키는데, 이것이 신입 사원의 성장에는 도움이 될 수 있어도 좋은 툴을 만들지 못할 가능성이 크다.
  • 좋은 툴은 업무 방식 이해가 높고 시야가 넓은 사람이 만들어야 한다. 즉, 리드/시니어 프로그래머가 만드는 것이 좋다.
  • 툴은 하찮은 일이 아니다!

• 사전 조사

  • 현재 상황을 파악하기 위해 불편한 점을 수집한다.
  • 인터뷰는 좋은 방법이지만 그 내용이 부족하거나 부정확한 점이 있어 수집에 한계가 있다. 보통은 현재 상태에 만족한다고 대답하기 때문이다.
  • 전해들은 원인은 진짜 원인이 아닐 수 있다. 따라서 한 단계 더 나아가 관찰을 한다.
  • 아니먼 더 나아가 하고 있는 일을 직접 따라가 보자. 시연을 해달라는 것도 좋고, 가능하면 직접 해보는 것도 좋다.
  • 그러면 수집된 정보의 실제 의미, 속사정, 진짜 원인을 알 수 있게 된다.
  • 원한다고 생각하는 것과 진짜 필요로하는 것을 잘 구분해야 한다.

• 우선순위

  • 요구 사항으로부터 기능 목록이 완성되면 다음의 순서로 일을 진행한다. 1. 없으면 개발이 불가능한 것 2. 너무 복잡한 프로세스인 것 3. 자동화가 가능한 것
  • 큰 계획을 세우되 작은 것부터 하나씩 꾸준히 진행해야 한다.
  • 모든 프로세스를 커버하는 툴을 처음부터 만드려하면, 일이 너무 커져서 포기하는 경우가 발생한다.
  • 따라서 작업 프로세스의 50%만 커버해도 좋으니 진짜 원하는 것을 중심으로 작업을 진행한다.
  • 순간순간부터 줄이는 것은 모여서 큰 것을 이루어낸다.

• 포커스

  • 아티스트/기획자/프로그래머의 편한 방법은 다 다르다.
  • 따라서 익숙한 것과 최대한 비슷하게 만든다. 늘 쓰던 툴의 기능/개념을 차용해서 만들면 좋다. (photoshop, flash, excel, auto completion 등)

• 주의

  • 툴의 자유도/확장성을 불편함과 바꾸지 않는다.
  • 불편한 것을 만들고 사용을 강요하지 말자!
  • 이 정도도 안 배우고? 라고 툴 개발자가 생각할 수 있는데, 프로그래머는 이해/숙련이 타 직군에 비해 빠른 편이다. 그리고 이 차이는 타 직군이 단시간 훈련해서 좁힐 수 있는 것도 아니다.
  • 따라서 교육을 하기 보다는 쓰기 좋은 것을 만들어라.
  • 배우지 않아도 쓸 수 있는 것을 만들면 더 좋다. 배움의 최소화

• 제작 후

  • 필요에 따라 그 때마다 파편화된 작은 툴을 만들면 갈수록 유지보수/관리가 잘 안된다.
  • tools 디렉토리 하위에는 동작하지 않거나 미완성된 툴이 쌓이게 된다.
  • 그리고 이는 마치 게임 유저의 이탈처럼 개발된 툴의 사용 중단을 유발한다.
  • 반드시 관리 책임이 필요하다.
  • 툴 서비스 기간의 시작과 끝을 명시하고, 항상 가용하도록 관리한다.

• 피드백

  • 툴이 의도대로 사용되고 있는가?
  • 인터뷰, 관찰을 다시 한다. 하지만 이건 항상하거나 자주하기에는 자원 소모가 좀 크니, 사용 지표를 남기고 그것을 분석한다.
  • eg) 각 메뉴별 사용 정보를 수집한다.
  • 언제, 어느 시점에, 어느 빈도로, 누가 사용하는지를 수집한다.
  • 예상과 다르다면 사용자와 직접 만나서 피드백을 받는다.
  • 만약 불일치가 발생한다면 프로그래머의 멘탈 모델을 수정할 수 있다.
• 툴 개발 이후 업데이트와 측정에 신경을 쓰자.

결론

• 옆 동료들에 대한 존중과 작업 환경에 대해 관심을 가지고,

  • 프로그래머는 주변 동료가 일하는 과정에서 발생하는 어렵고 괴로운 점을 찾아 툴을 개발해주고,
  • 디렉터/PM은 프로그래머에게 툴 개발을 할 수 있도록 시간을 할당해 주자.
• 이는 어렵고 힘든 개발 문화를 바꿔줄 것이고, 게임 개발 자체에 더 집중할 수 있도록 만들어준다.

Q&A

• 툴 전담팀을 두는 것에 대해서는 어떻게 생각?

  • 툴 전담팀이 툴을 개발할 경우, 단기적 개발이라면 괜찮지만 시간이 지날수록 게임 개발과 동떨어진 툴이 나올 수 있다. 따라서 게임 개발하는 팀이 직접 하는 것이 좋다고 생각한다.

• 동료가 얼마나 괴로워할 때 툴을 만드는 것이 좋을까? 그냥 작업을 도와주는게 낫지 않나?

  • 3번 정도 할 일이 아니고 그 이상으로 반복되는 일이면 툴이 낫다.

• 툴 개발의 중요성을 부각시키려면 어떻게?

  • 프로그래머는 타 직군 동료들에게 해당 내역을 전파한다. (그들이 나서서 먼저 도와달라고 하기에는 좀 그렇다.)
  • 디렉터와 PM 수준에서 나서야 좋은데 그들이 이를 중요치 않게 생각한다면 조직 문화가 그런 인식이 생길 수 있도록 설득해야 한다.

• 툴 개발 요청을 하면 요청자에게 만들라고 한다. 어쩌면 좋나?

  • 의사결정권자가 잘못했다. 툴은 잘 만들 수 있는 사람이 만들게 해야 한다.

• 1인 개발 시 툴 개발은 필요한가?

  • 본인 스스로 상담하라.

• 툴이 내가 모르는 언어로 작성되어 있다면 어떻게?

  • 본인만 모르면 공부하고, 개발자 모두 모르고 게임이랑 연동되는 언어도 아니라면 다른 언어로 고쳐도 좋다.

• 장르 불문 공용 툴에 대해서는 어떻게 생각?

  • communication 툴이라면 몰라도 너무 general하게 만드려다가는 망할 수 있다.
  • 한두명의 요청이라도 툴을 만드는 것이 좋다.

• 프로그래머가 아닌 직군인데 툴이 필요하면 직접 만드는 것이 좋나?

  • 그 시간에 본인이 잘할 수 있는 일을 집중하고, 툴 개발은 프로그래머에게 맡기는 것이 낫다고 생각한다.

• 툴 개발은 관심있던 분야고 전 회사에서 당해본 것이 많아서 굉장히 공감되는 내용이 많았다.

• 특히 내 경우 대외적 interface가 좀 안 좋았던 편이라서 그런지 누가 툴 개발을 요청했던 적은 적었고 내가 비효율적인 부분을 찾아서 툴 개발을 진행했던 경우가 많은데,

  • 정말 툴을 사용하는 개발자가 뭘 원하는지를 제대로 파악하지 못했던 경우나,
  • 그 사람이 괜찮다고 해서 정말 괜찮다고 생각했던 적이 몇 번 있다. 진짜 괜찮은 줄 알았는데(…) 그 점에서는 이 발표를 통해 많이 배웠다.

• 결론에서도 다시 한 번 강조되었지만 툴 개발은 모든 사람의 인식이 바뀌어야 잘 진행될 수 있다.

  • 툴이 필요한 사람은 적극적으로 개발을 타진해야 하며,
  • 툴 개발자는 기꺼이 그 필요성을 인식하고 협력하여 좋은 툴을 개발할 수 있어야 하며,
  • 관리자는 이를 장려하고 지원해줄 수 있어야 한다. 는 꿈

• 그냥 좀 억울해서 이야기를 해보자면,

  • 툴 개발자가 자의적으로 비효율 지점을 분석하여 사용자에게 툴을 공급하는 경우 잘못 분석된 프로세스에 의해 필요한 것과 한참 동떨어진 툴이 나올 수 있다. 그런데 툴 개발에 이미 자원이 꽤 소모되었다면 관리자가 이 툴 사용을 강제하는 경우가 있다(…)
  • 툴 개발/지원 분위기가 장려되면 툴 요청자는 본인이 뭘 원하는지도 잘 모르면서 크고 아름답고 거대한 툴을 요청하는 경우가 있다. 최악의 경우에는 기싸움으로 번질 수가 있으니 노련한 사람이 잘 제어를 해주어야 한다. 왜 제 요청만 구현을 안해주세요?
  • 툴 개발자가 툴 개발에 대한 인식이 좋지 않다면 툴 개발은 잔업으로 밖에 보이지 않는다. 이러한 인식이 바뀌지 않는다면 툴 유지보수는 꿈 같은 이야기가 된다. 그걸 제가 왜 고쳐요?
  • 관리자/경영자는 비용 기반으로 결정하기 때문에 본인이 꽂힌 것이 아니고서야 툴 개발로 인한 효율성 개선으로 얻을 수 있는 비용이 명확하지 않다면 별로 개발을 장려하지 않는다.
• 툴 요청자와 툴 개발자는 그냥 SI한다고 생각하고 개발하는 것이 제일 낫다고 본다. 갑/을 관계 이야기가 아니라 고객과 구현자의 입장에서 필요한 기능을 분석하고, 구현하고, 출시 이후 관리를 해주어야 하니까 말이다.
• 협업이니까 다들 좋은 분위기에서 효율적으로 작업하면 좋겠지만 그게 쉽지는 않다. 어쨌든 유명한 분이 좋은 발표를 해주셨으니 이제 앞으로는 좀 더 좋아지지 않을까 기대해본다.