정치적으로 업무 자동화가 좋기만 하지는 않음

개인적으로 주변에서 일어나는 여러 가지 일을 자동화 하는데 큰 관심을 가지고 있습니다. 일상 생활에는 의외로 별 생각 없이 항상 반복해서 수행하는 일이 널려 있습니다. 가령 매일 아무 생각 없이 하는 출퇴근이 대표적인데 물론 이를 자동화 할 수 있다면 제 모가지가 날아가고 더 이상 돈을 벌지 못해 그만 살아야 할 수 있으니 출퇴근을 자동화 하는 것은 좋은 아이디어가 아닐 것 같네요.

하지만 집에 제가 먼저 돌아오면 가족들에게 제가 돌아왔다는 메시지를 보내거나 신용카드를 결제할 때마다 결제 메시지를 가계부에 보내거나 출퇴근 시각을 슬랙 채널을 통해 말하기를 원하는 회사의 요구에 따라 회사에 들어가고 나갈 때 알아서 슬랙 채널에 말하게 만들고 또 인도어에서 운동을 시작하면 알아서 애플워치에 워크아웃을 시작하고 음악을 틀게 할 수도 있습니다.

일상 생활 뿐 아니라 일을 할 때도 자동화 할 부분은 생각보다 많습니다. 가령 사람들이 회의록을 잘 읽지 않았는데 회의록 페이지는 노션의 회의록 데이터베이스에 쌓여 있었지만 이 페이지에 직접 가서 회의록 하나하나를 읽는 사람들은 많지 않았고 이미 잘 결정되어 진행 중인 사안을 파악하지 못하고 갑자기 헛소리를 해 대 나머지 사람들을 긴장 시키는 일이 종종 일어났습니다. 회의록을 읽으라는 공지만으로는 상황을 절대 해결할 수 없음을 알고 있어 난감했는데 회사에서는 회의록을 작성한 사람이 특정 슬랙 채널에 회의록 주소를 올리는 규칙을 만들려고 했고 이런 생각을 너무 쉽게 하고 실행하려 하는 안일함에 화가 났습니다.

이는 특히 회의록을 안 읽어서 문제를 일으키는 사람들이 대부분 회의록을 작성하는 사람들에 비해 직급이 높기 때문에 가능한 일이라 더더욱 화가 났습니다. 그래서 재피어를 사용해 노션 데이터베이스를 보고 있다가 새 회의록이 업데이트 되면 이를 알아서 슬랙 채널에 말하는 아주아주아주아주 간단한 자동화를 만들었고 사람이 관여할 필요 없이 잘 동작했으며 최근에는 더 자유롭게 로직을 만들 수 있을 뿐 아니라 무료로 사용할 수 있는 n8n으로 이전했습니다. 회의록을 쓰는 일만 해도 이미 충분히 힘든데 그걸 기계적으로 채널에 게시하라는 건 너무나 안일한 규칙이라고 생각합니다. 아무도 그럴 필요가 없습니다. 읽는 것이 핵심이지 읽으라고 올려 주는 일이 핵심은 아닙니다.

이전에 참여했던 MMO 프로젝트에서 던전과 퀘스트를 만드는 분들은 게임에 계속해서 추가되는 몬스터, 상호작용 가능한 물체, NPC 따위를 그때그때 파악하는데 어려움을 겪고 있었습니다. 던전을 실컷 만들어 놓고 보니 나중에서야 어떤 상황에 더 잘 어울리는 에셋이나 메커닉이 이미 개발 되어 있었다는 사실을 알게 되어 이를 수정하며 비용을 낭비하는 상황이었습니다. 문제를 해결하기 위해 프로젝트 전체에 사용 가능한 에셋을 한 파일에 정리한 일종의 카탈로그를 만들기로 했는데 엑셀로 만들기로 한 이 파일에는 대상의 분류, 이미지, 구분자, 주요 정보가 나열되어 있었습니다. 다른 정보를 각각의 에셋을 정의한 다른 엑셀 파일로부터 불러오는 것은 어렵지 않았지만 문제는 각각의 스크린샷이었습니다. 이름과 분류를 통해 대강 그게 뭔지 알 수 있었지만 그때그때 에셋을 실제로 열어 외형을 파악하려고 보니 시간도 많이 걸렸고 효율적이지도 않았습니다. 모든 에셋에 대한 카탈로그를 만드는 김에 이 파일에 스크린샷이 포함되어 있어야 한다는 결론에 다다릅니다.

그러려면 누군가 모든 에셋을 하나하나 열어 스크린샷을 찍은 다음 이를 엑셀 파일에 하나하나 첨부해야만 했습니다. 제가 속한 부서에서 일어나는 일이 아니어서 얼마 동안은 무슨 일이 일어나고 있는지 몰랐는데 어느 날 밤에 야근하다가 문득 가까이에서 ‘노가다 하는 소리'가 들려서 자리에서 일어났습니다. ‘노가다 하는 소리’는 키보드나 마우스를 아주 규칙적으로 반복해서 조작하는 소리인데 대략 이런 식입니다. 파일을 열고 스크린샷을 찍어 저장하고 파일을 닫고 또 다음 파일을 연다면 대략 ‘따닥 따닥 탁 타탁 타탁 탁 따닥 따닥’ 같은 소리가 반복해서 들려오는 겁니다. -이런 소리를 들으면 그냥 넘어가면 안된다고 생각합니다. 누군가가 인간이 할 필요 없는 무의미한 작업을 포괄임금제 기반에서 무의미하게 하고 있을 가능성이 높으니 어서 도와줘야 합니다. 소리를 따라 가보니 역시 옆 팀 팀원 분이 대충 멀리서 봐도 똑같은 작업을 반복하고 있었습니다. 뒤에 가서 물어봅니다. “몇 개에요?”, “몇 천 개 정도요.”, “……”

목록에는 게임에 나오는 모든 몬스터와 상호작용 가능한 물체와 아이템이 나열되어 있었고 이걸 하나하나 열어 적당한 카메라 시점을 잡은 다음 화면을 찍어 대상의 구분자를 파일 이름으로 해서 저장하기를 반복하고 있었는데 몇 천 개 중에 이제 처음 몇 십 개를 찍었을 뿐이지만 이미 그 팀원 분의 눈에서는 생기가 사라져 있었습니다. “언제까지 해야 돼요?”, “금요일까지요.”, “…… 작업 멈추고 엑셀파일 줘봐요.” 자리로 돌아와 깜빡이는 메신저로부터 엑셀 파일을 끄집어내 살펴보니 이미 엑셀 파일에는 게임에 등장하는 여러 에셋의 이름과 에셋 경로가 늘어서 있었습니다. 그냥 인하우스 엔진의 에셋 뷰어로 에셋을 열어 찍어 엑셀에 붙여 넣으면 끝나는 일이었는데 이걸 사람이 하려니 따로 파일로 저장했다가 엑셀에서 불러온 다음 마우스로 크기를 조절하는 등의 난리를 치고 있었습니다.

일단 그때까지 수동으로 입력된 스크린샷을 모두 삭제한 다음 간단한 스크립트로 에셋 경로가 있는 칼럼을 돌며 칼럼 경로를 클립보드에 복사해 에셋 뷰어로 전환해 에셋을 열고 에셋마다 아이콘을 찍을 용도로 이미 설정되어 있던 카메라로 전환한 다음 스크린샷을 클립보드에 찍어 다시 엑셀로 돌아와 적당한 위치에 적당한 크기로 알아서 삽입하기를 반복하게 만들었습니다. 개인적으로 윈도우에서 여러 앱을 오가는 자동화를 만들 때는 오래 전부터 AutoIt 이라는 도구를 사용해 왔는데 현대적인 도구들이 있음을 알고 있지만 이들은 종종 특정 앱에 종속되거나 기능이 제한된 경우가 있어 사용이 쉽지 않습니다.

하지만 AutoIt은 오래 되어서 그런지 사용자가 입력하는 것처럼 윈도우를 이벤트 기반으로 직접 제어할 수 있어 여러 앱을 거치는 자동화를 좀 불안하긴 하지만 제한된 범위 안에서는 빠르게 만들어낼 수 있어 아주 오랫동안 애용하고 있습니다. 이 앱으로 엑셀 칼럼을 읽어 에셋 뷰어로 전환해 에셋을 열고 카메라를 전환한 다음 스크린샷을 찍어 엑셀로 돌아와 붙여 넣고 크기를 전환하고 저장하기를 반복하게 했습니다. 직접 윈도우에서 앱 사이를 오가며 동작하기 때문에 아주 빠르지는 않았지만 내일 아침에 돌아오면 작업이 끝나 있을 것 같았습니다.

눈에 생기가 사라져 있던 팀원 분을 불러 저 혼자 엑셀과 에셋 뷰어를 오가며 스크린샷을 찍어 붙여 넣고 알아서 조정하는 모습을 보여드린 다음 ‘퇴근하고 내일 아침에 봐요’ 라고 말하곤 모니터를 끄고 가방을 주섬주섬 챙기다가 그 분을 다시 봤는데 입은 벌어져 있었지만 눈에는 생기가 돌아와 있었습니다. 다음 날 아침에 출근해서 모니터를 켜 보니 기대와 달리 스크립트는 한밤중에 튀어나온 보안 소프트웨어의 점검 작업에 가로막혀 뻑 나 있었지만 이른 출근이라 다른 분들이 출근하기 전에 재빨리 스크립트를 다시 돌려 모두가 출근하기 전에 카탈로그를 완성합니다.

결국 이 카탈로그는 사람들의 레벨디자인 작업에 도움을 줬고 시간을 조금 더 써 하루에 한 번 밤중에 새로 올라온 에셋 데이터를 읽어 카탈로그를 업데이트 한 다음 형상관리도구에 커밋 하도록 만들었고 그 다음부터는 저 자신을 포함해 아무도 신경 쓰지 않았습니다. 원래 카탈로그 파일은 알아서 업데이트 되는 거였고 이게 어떻게 동작하는지는 신경 쓸 필요가 없어졌습니다. 그러다가 퇴사하고 나서 한 달 정도 지났을 때 남은 사람들은 그 스크립트가 제 컴퓨터에서 돌고 있었다는 사실을 깨달았고 또 카탈로그가 더 이상 업데이트 되지 않는다는 사실을 발견해 연락해 왔지만 이미 뭘 할 수는 없었습니다.

이런 일은 생각보다 자주 일어났는데 근본적인 이유는 노가다를 필요로 하는 분들이 그 작업이 실은 자동화 가능하다는 사실을 상상하지 않기 때문인 것 같습니다. 어디선가 읽은 말인데 대략 프로그램을 만드는 기술은 프로그래머들 사이에서는 너무나 당연하기 때문에 직업 프로그래머는 존경 받기 어렵지만 프로그래머가 아닌 사람들 사이에서 이는 마치 마법과도 같아 큰 역할을 하게 된다는 내용이었습니다. 개인적으로 큰 역할도 하고 또 마법과도 같이 인식 된다는 데는 동의하지만 여전히 그걸 할 수 있다고 해서 존경 받지는 않습니다. 한 순간 마법으로 인식 되기는 하지만 순식간에 일상으로 굳어지고 오히려 동작하지 않을 때 책임을 떠맡는 상황이 일어나기 쉬운 것 같습니다. 하지만 일단 노가다를 사람이 하지 않을 수 있다는 사실을 알고 있는 이상 팀에서 사람에 의한 노가다가 일어나는 걸 알게 되면 이를 방치할 수는 없습니다. 다른 팀에서 일어나는 일이라도 결국 프로젝트의 일이고 프로젝트에서 사람이 낭비되면 결국 우리들이 제품을 출시할 수 있을 날짜는 점점 더 멀어지기 때문입니다. 결국 저 자신에게도 피해를 끼치게 됩니다.

한 MMO 게임에 참여해 던전을 자동 생성하는 기능 개발에 참여하며 ‘Skyrim’s Modular Approach to Level Design’을 굉장히 많이 참고했습니다. 처음 이 기능을 만드는 일이 저에게 왔을 때 도대체 어디서부터 시작해야 할 지 막막했지만 저 자료에 기반해 어디부터 시작할 지, 우리의 현실에 어떻게 적용해야 할 지에 집중하며 개발을 진행 시킬 수 있었습니다. 그런데 저 글을 살펴보면 에셋 네이밍의 중요성에 대한 언급이 나오는데 네이밍 규칙에 따라 한 번 만들어진 수많은 에셋의 네이밍 체계를 변경하는데 높은 비용이 소요되기 때문에 네이밍 규칙을 주의 깊고 또 확장 가능하게 설계해야 한다는 것입니다. 처음에는 이 말의 의미를 정확히 이해하지 못했지만 게임에 변경될 수 있는 사소한 마일 이름이나 NPC 이름, 던전 이름에 기반해 만들어진 에셋은 이들의 이름이 변경될 때 곤란한 상태가 됨을 이내 깨달을 수 있었습니다. 대부분은 실제로 부르는 새 이름과 에셋이 파일 시스템에 기록된 오래된 이름이 동시에 통용되며 실제 부르는 새 이름의 에셋은 오래된 이름으로 검색해야 하는 규칙이 팀에 암암리에 전수 되고 있는 상황이었습니다.

그러던 어느 날 이제 이런 에셋이 너무 많아졌고 한동안 컨텐츠 이름이 변경되지 않아 한 번은 에셋 이름을 전체적으로 변경해야만 하는 순간이 찾아옵니다. 이번에도 누군가 이 작업을 담당해 수 천 개에 달하는 에셋 파일 이름을 하나하나 규칙에 맞게 바꾸고 규칙에 맞는 디렉토리에 이동 시키는 일을 맡았지만 그 쪽 팀장님께서 제가 평소에 표 나지 않게 이런 일을 하고 있음을 알고 계셨기 때문에 ‘일단 우진님과 상담해 보세요’ 라고 말해 주신 덕분에 이 일의 존재를 알게 됩니다. 목표는 에셋 파일 이름을 과거 이름에서 새 이름으로 바꾼 다음 새 이름 체계에 맞는 디렉토리로 옮기고 이를 엔진에 반영하는 일이었는데 이걸 사람이 하나하나 하기에는 무리가 있어 보였습니다. 일단 수량이 많고 실수할 수 있을 뿐 아니라 경로를 옮길 때마다 엔진에 이를 반영해야 했기 때문에 절차가 좀 귀찮았습니다. 하지만 네이밍 변경 자체는 기계적으로 특정 키워드를 치환하고 키환된 결과를 디렉토리 별로 재구성 하기만 하면 되는 일로 보였습니다.

잠깐 고민하다가 윈도우 커맨드라인에서 ren 명령어로 파일 이름을 바꾼 다음 파일을 이동 시켜 재구성하고 이를 엔진에서 그때그때 새로고침 하도록 하기로 하고 엑셀을 열어 한 칼럼에는 현재 이름, 그 옆 칼럼에는 변경된 이름, 그 다음 칼럼에는 변경된 다음 위치해야 할 새 경로를 차례대로 나열한 몇 천 줄을 만든 다음 그 앞에 ren 커맨드를 붙여 메모장에 복사한 다음 이를 커맨드라인에 한 번에 붙여 넣고 엔터 키를 누릅니다. 시커먼 커맨드라인에는 붙여 넣은 몇 천 줄에 달하는 커맨드가 계속 올라갔고 하드디스크는 울부짖었지만 작업은 몇 분 안에 끝났고 결과를 커밋하고 나니 모두가 평화를 되찾았습니다.

사례 나열은 그만 하고 이런 일이 생기는 이유는 앞에서 말한 이런게 가능하다는 사실을 모르기 때문에 아예 상상하지 않는 이유가 가장 크고 또 하나는 엔지니어링 조직에서 이런 일을 도와줄 사람이 전혀 없다는 것도 있습니다. 다들 새 기능을 만드는데 바쁘지만 인하우스 도구를 개선하는데는 별 관심이 없는 경우가 많은데 인하우스 도구는 아무리 잘 만들어도 별로 표나지 않기 때문입니다. 그래서 인하우스 도구를 개발하는 부서 구성원은 종종 다른 팀에 인력이 부족할 때 파견되기도 하고 업무 만족도 역시 높지 않아 다른 팀으로 아예 옮기기도 해서 팀이 잘 유지되지 않습니다. 이런 상황에서 인하우스 도구 개발팀을 유지하려면 회사 차원의 강한 지원이 필요한데 보통 회사는 프로젝트 선 까지만 관여하고 프로젝트 내부는 프로젝트가 알아서 관리하는 경우가 대부분이어서 프로젝트 디렉터 수준에서 인하우스 도구 개발팀을 강하게 지원할 결정을 하기는 어렵습니다. 때문에 인하우스 도구는 최소한의 역할을 하는 수준으로 개발되지만 실제 사용자들의 요구사항을 받아들여 개선되기는 쉽지 않으며 사용자들이 겪는 코너 케이스는 더더욱 개선되기 어렵습니다. 그래서 어지간한 자동화를 게임디자인 스스로 해결해야 합니다.

그런데 게임디자인 부서 차원의 자동화 역시 인하우스 도구 개발과 비슷한 취급을 받는데 업무 자동화는 독립된 업무로 잘 취급되지 않습니다. 앞에서 소개한 사례에서도 분명 제 입장에서는 작업을 자동으로 처리할 방법을 고안해 이를 실제로 만들어 실행 시키고 결과를 커밋하고 또 이 과정이 일정에 따라 자동으로 동작하게 만들고 이 환경이 깨지지 않도록 관리하는데 시간을 사용하고 있지만 이 일들은 그저 함께 일하는 다른 사람들을 돕는 일로밖에 취급 되지 않았습니다. 업무 보고에 이를 기입해도 이런 행동이 업무를 얼마나 줄여 주는지 잘 알지 못해 인정 받기도 어려웠습니다. 그래서 한동안은 적극적으로 자동화가 필요한 일에 관여했지만 어느 순간 현타가 와 웬만하면 야근 중에 ‘노가다의 소리’가 들려오더라도 애써 무시하고 제 할 일을 마친 다음 퇴근하곤 했는데 사실 그러면 몸은 훨씬 편했습니다. 하지만 노가다의 소리를 듣는 내내 마음은 결코 편하지 않았습니다. 우리들이 인력을 얼마나 낭비하고 있는지 생각하며 답답한 느낌을 받곤 합니다.

이런 경험 끝에 개인적으로는 제가 해야 하는 일 중 자동화 가능한 일이 있다면 노가다를 하는 대신 적극적으로 자동화 하지만 제가 할 일이 아니거나 제가 포함된 팀이 해야 하는 일이 아니면 개입하지 않게 됐습니다. 또한 자동화 업무는 앞에서 직업 프로그래머가 마치 마법사 집단 사이에서 별로 존경 받지 못하는 현실처럼 자동화 역시 별다른 인정을 받지 않는다는 사실을 깨달았습니다. 가령 앞에서 게임 전체에서 레벨디자인에 활용 가능한 물체들의 카탈로그를 만든다고 할 때 만약 이를 몬스터, 물체, 아이템 별로 여러 사람이 나눠 밤 늦게 까지 직접 스크린샷을 붙여 넣은 다음 이를 합쳐 완성된 현 시점의 최신 카탈로그를 만들었다면 업무 보고에 이를 크게 쓸 수 있습니다. 여러 사람이 밤 늦게 까지 일하며 자신들의 업무 결과를 개선할 수 있는 기반 작업을 수행했다고 말할 수 있고 이는 크게 인정 받습니다. 또 새로운 에셋이 추가될 때마다 대략 한 달에 한 번 정도 이런 바쁘게 야근하는 기간을 거치며 새 카탈로그를 만들기를 반복하면 이 팀은 고생하고 있다는 평가를 받고 다른 팀은 뭐 하냐는 의문을 받을 수도 있습니다.

하지만 시간을 사용해 이를 자동화 하고 하루 한 번 업데이트 되는 카탈로그를 만들고 이 체계가 깨지지 않도록 관리하는데 시간을 사용하더라도 이는 자동화 도구를 만들었을 뿐으로 딱히 고생한 것도 아니고 이 작업을 통해 일찍 퇴근했다면 밤 늦게 까지 열심히 일한 것도 아니며 그저 매일 아침 카탈로그 엑셀 파일의 새 버전을 받아 사용하기만 하면 되니 이 상황 자체가 당연해져 분명히 일하고 있는데도 전혀 존경 받지 못합니다. 심지어 이런 일이 존재한다는 사실을 잊어버리고 결국 게임이 영원히 출시되지 않을 것 같아 퇴사하고 장비를 반납해 작업이 동작하지 않게 된 다음에야 작업의 존재를 깨닫게 됩니다. 이후에도 비슷한 경험을 하며 업무 자동화는 일을 더 정확하고 빨리 할 수 있고 인간의 실수를 방지하며 그 시간에 인간은 정말 인간이 필요한 일에 집중할 수 있게 하지만 이 행동은 결코 인정받지 못하며 심지어 자동화 없이 인간이 직접 노가다 한 일은 더 크게 인정받는 현실을 깊이 납득했습니다.

그래서 이 다음부터는 자동화가 가능하다 하더라도 자동화를 할 지 말 지를 좀 더 고민하기 시작했습니다. 가령 제가 직접 수행해야 할 일이라면 자동화 하되 자동화를 통해 일을 빨리 끝냈더라도 이를 빨리 제출하지 않고 이 노가다를 끝내는데 사람들이 기대하는 시간 동안 지연한 다음 제출 하기도 하고 또 다른 팀의 노가다를 보면 조용히 노가다가 제대로 수행되었는지 점검하는 기능을 만들어 돌려 본 다음 틀린 부분을 전달하곤 했는데 이렇게 행동을 바꾸고 나니 자동화에 의존해 날로 먹는 이미지에서 열심히 일하는 사람으로, 또 다른 팀의 작업에도 관심을 가진다는 이미지를 얻을 수 있었습니다.

개인적으로는 여전히 굳이 인간이 할 필요 없는 일을 인간이 하는 상황을 보면 갑갑하고 당장 어떻게든 해 드리고 싶지만 정치적으로 이런 행동이 올바르지 않다는 사실을 인정합니다. 정치적으로 업무 자동화가 좋기만 하지 않으며 주변 상황에 따라 자동화 가능한 작업에 대한 개입 수준을 조정해 개인의 이미지 관리와 프로젝트의 효율적인 수행 사이에 적당한 선을 찾아야 합니다.