이러한 개발 효율을 증가시키는 대표적인 방법이 바로 생산성 향상 툴을 쓰는 것이다. 과연 생산성 향상 툴을 쓰면 작업 효율을 얼마나 올릴 수 있는 걸까? 액션스퀘어 '블레이드2' 서버 프로그래밍 및 개발 생산성 향상을 위한 작업을 하고 있는 최우성 개발자가 25일 NDC 현장에서 자신의 경험을 공유했다.
※ 기사는 편한 전달을 위해 강연자의 시점에서 서술했습니다.
■ Part 1. 옛날 이야기: 생산성 향상의 적들
Case 1. 삶의 고단함
처음 프로젝트에 합류한 회사는 16명이 10년간 개발하다가 사람을 40명으로 늘리면서 급격히 성장하던 데였다. 난 여기서 36번째 멤버였다. 이후 이 회사는 80명까지 늘어났다. 아무튼, 그 회사에서는 소스 코드를 SVN으로 받았는데 데이터와 리소스는 따로 관리하고 있었다. 그런데 제로보드로 압축해서 공유하는 거였다. 상상도 못 할 일이었는데, 한마디로 말해 개발 관리가 거의 안 됐던 상황이었다.
그래서 PM에게 SVN을 통해서 한 번에 받을 수 있게 바꾸자고 하니까 라이브 서비스에 문제는 없을지, 프로그래머가 아닌 사람들은 사용하기 어렵지 않나 하는 얘기가 나왔다. 어느 정도는 이해가 되는 얘기였다. 자칫 사용이 어려워서 삐끗하면 콘텐츠 업데이트가 밀리는 최악의 상황이 발생할 테니까. 그럼에도 지속적인 설득 끝에 4개월 후에 SVN을 통해 소스 코드와 리소스, 데이터를 받을 수 있도록 했다.
여기서 알아야 할 건 세상에는 다양한 수준의 개발팀이 있다는 거다. 정말 몰라서 시작하지 못하는 경우도 있다. 특히 비 프로그래머들의 경우는 그럴 가능성이 더 컸다.
그리고 중간에 도구를 도입하는 것도 부정적으로만 생각할 수밖에 없다. 그러니 생산성 향상을 위해선 처음부터 도입할 필요가 있다.
Case 2. 크고 아름답게
큰 회사에 다닐 무렵 7개의 프로젝트를 돌리고 있었는데 그러다 보니 업무 관리를 할 필요가 있었다. 거기서 실장님이 팀별로 요구사항을 취합할 수 있는 툴을 만들어달라고 요구하셨다. 그래서 만들었는데 결과적으로 말해서 잘 안됐다. 처음부터 모든 팀의 요구사항을 만족할 수 있도록 한 툴을 만드는 바람에 공통적인 부분은 만족했는데 팀별로 불만족인 부분이 두드러졌다.
이때 생산성 향상을 위한 도구는 Bottom-Up 방식으로 진행해야 한다는 걸 느꼈다. 처음엔 딱 필요한 기능을 넣고 점차 추가하는 식으로 말이다. 그러면서도 처음에 정한 기준을 벗어나지 않도록 해야 했다.
그리고 필요한 것만 넣으면 됐다. 능률을 X% 늘리는 툴을 만들겠다기보다는 당장 불편함을 덜어주는 툴만으로도 충분하다.
Case 3. 의지의 문제
엑셀 데이터를 유니티에 넣는 경험은 많은 팀에서 했을 거다. 다 겪은 문제일텐데 시간이 너무 걸린다. 그것도 아예 한 번에 끝나는 게 아니라 엑셀을 띄우고 CSV 파일로 Export 하면서 기다리고 유니티를 키고 Import하는 작업을 일일이 해야 해서 시간을 너무 허비한다.
그래서 이걸 자동화하는 작업을 했다. 이때 구성원의 자발적인 의지가 필요하단 걸 깨달았다. 불편한 부분이 눈에 제일 잘 보이는 건 작업자 자신이기 때문이다. 그걸 지켜보는 리더도 중요하다. 리더가 하지 말라고 하면 작업은 할 수 없다. 그리고 툴을 만드는 데만 집중에 개발에는 신경을 쓰지 못하는 상황이 발생할 수도 있기에 리더가 관리할 필요가 있다.
Case 4. 제국군과 저항군
PM을 했을 때의 일인데 레드마인과 젠킨스를 도입하려고 했었다. 그런데 CTO와 개발팀 사이에 트러블이 있어서 일이 진행되지 않았다. 그때 팀워크의 중요성을 다시 한번 깨달았다. 나중에 문제를 해결하고 나서 개발팀과 인터뷰를 했었는데 CTO가 시킨 일이 중요하고 해야 한다는 건 알지만 싫어서 안 했다고 얘길 하더라.
상호 간의 팀워크가 없다면 기술은 있으나 마나다. 그렇기에 리더라면 어떻게든 구성원을 품어야 한다. 이런 분쟁을 불러오는 요소는 여러 개가 존재하는 만큼, 초반에 어떻게 할지 기준을 확립하는 게 좋다.
■ Part 2. 블레이드2: 서버 개발 생산성 향상을 위한 사례
예전 얘기는 이쯤하고 이제 본격적으로 '블레이드2' 서버를 개발하면서 생산성 향상을 위해 어떤 일들을 했는지 소개하겠다.
시작은 미약했다. PD님이 AWS에서 서버 성능 테스트를 할 거고 매번 하나씩 일일이 하면 시간 낭비니까 빌드와 배포를 어느 정도 자동화하면 좋을 것 같단 의견을 줘서 해당 툴을 만들었다. 이런 생산성 향상 툴을 만들 때는 세 가지를 명심하고 만들면 좋다.
첫 번째는 방금 전에도 한 말인데 능률을 X% 늘리는 툴을 만들겠다기보다는 반복적인 작업을 줄이는 툴 정도만 돼도 충분하다는 거다. 자동화 툴을 만든 이유도 마찬가지다. 자동화를 통해 반복 작업을 줄일 수 있고 이게 곧 생산성 향상으로 이어진 거다.
두 번째는 툴이 작업 흐름을 유지해준다는 거다. 사람이 뭔가에 몰입할 때 단번에 몰입하는 게 아니다. 점진적으로 몰입한다. 그런데 자동화 툴이 없다고 할 때 몰입하려고 할 때마다 방해가 들어와 몰입을 방해한다. 결국, 개발 능률은 떨어지고 만다. 자동화 툴은 그런 중간에 몰입을 방해하는 요소를 제거해 능률을 올려준다.
끝으로 세 번째는 내부 개발용 툴이라는 걸 명심해야 한다. 다소 조잡해도, 간혹 멈춰도 상관없다. 파는 툴이 아니라 내부에서 조금이라도 편하기 위해 만든 툴이니 만큼 완벽할 필요가 없다는 얘기다.
나도 '블레이드2'를 AWS에서 서버 테스트를 할 때 이런 것들을 고려해 툴을 만들었다. 우선 사람들에게 불편한 점을 물어보니 구성을 바꿔가며 성능 테스트할 때마다 다시 설정해야 하는 인스턴스와 옵션이 너무 많다는 것과 소스 코드가 수정 된 후 빌드 후 배포 해야 할 서버의 종류와 수가 많다는 얘기가 있었다. 이런 것들을 자동화할 필요가 있었다.
이 작업을 자동화하니 번거롭게 일일이 수정할 필요가 없어서 개발 능률이 향상됐을 뿐 아니라 용도별 서버를 설정하기 편해서 테스트하기가 수월해졌다. 이런 자동화 툴을 만들어야 하는 이유에 대해서는 앞서 말한 개발 주기가 짧아진 것도 있지만 전체 개발자에 비해 서버 프로그래머는 대개 소수이기 때문이다.
보통 개발자들로부터 서버가 떠 있는지, 테스트할 수 있는지, 플레이어 데이터를 옮겨줄 수 있는지 등의 요청이 오는데 이걸 수작업으로 일일이 하려면 끝이 없다. 그래서 개발자들이 서버 프로그래머에게 묻지 않아도 확인할 수 있도록 커맨드에 Show 명령어를 치면 확인할 수 있도록 간소화시켰다.
여기에 Git 사용이 생소한 개발자들을 위해 버튼만 누르면 바로 수정된 파일을 올릴 수 있도록 툴을 만들었다. 물론 완벽하진 않았다. 간혹 에러가 발생하기도 했는데 이럴 경우 그냥 껐다가 다시 켜면 됐다. 내부 개발용이었으니 완벽할 필요는 없었기 때문이다.
■ 결론
생산성 향상 툴들을 만들면서 깨달은 게 있다. 우선 툴들은 최대한 빨리 만들어 제공하는 게 좋다는 거다. 누누이 말하지만, 내부 개발용인 만큼, 완벽할 필요도 없고 당면한 문제를 해결한 정도만 되면 충분하다. 코드도 깔끔하면 좋지만, 꼭 그럴 필요는 없다. 이외에도 파이선-젠킨스 조합으로 많은 걸 해결할 수 있단 것과 인터넷에는 정보들이 가득하단 걸 깨달았다.
한편, 아쉬운 점도 있었다. 필요한 게 아닌 '있으면 좋지 않을까?' 한 것들은 대부분 필요가 없었다. 시간 낭비인 셈이었다. 그리고 이렇게 해도 데이터 검증이라던가 놓치는 부분은 발생했다. 반성해야 할 부분이었다.
결론을 내리자면 개발 주기가 짧아진 현재 개발 생산성 향상을 위한 툴은 있으면 좋은 게 아닌 필수가 됐다. '블레이드2' 서버 개발할 때에도 시작은 미약했지만, 상당히 도움이 됐다. 개발자들이 원래 해야 할 일에 집중할 수 있도록 한 것이다. 이런 툴을 만들면 적은 노력으로도 생산성을 높일 수 있으니 다른 개발사나 팀에서도 하길 추천하다.
Nowl@inven.co.kr