미움 받을 용기 없음

미움 받을 용기라는 단어들이 제목에 포함된 책이 있다는 말을 들은 적이 있습니다. 평소 같으면 책 제목을 검색한 다음 링크를 걸었을텐데 이 책은 존재한다는 이야기를 들었을 뿐 실제로 책을 본 적도 없고 책을 읽은 적도 없어 굳이 정확한 제목과 내용을 검색하지도 않았습니다. 책을 읽지 않았지만 어쩐지 이 책에는 사회 생활의 다양한 측면에서 미움 받을 수도 있는 말과 행동을 해서 상황을 개선하고 일을 더 잘 수행하는 내용이 적혀 있을 것만 같은 선입견이 있습니다. 종종 다른 분들이 이 제목을 인용하실 때 이와 비슷한 맥락의 이야기를 하고 계셨기 때문입니다.

지난 마일스톤 중간 점검. 제한시간 안에 서비스 할 수 있을까?에서 이따금 프로젝트 진행 상황을 점검하고 있는데 이번 점검 결과를 살펴보니 어떻게든 목표를 달성할 수 있을 것 같기는 하지만 결국 이전에 하던 것과 비슷한 방식으로 마일스톤 후반에는 아주 엉망진창으로 일한 끝에 빌드를 내게 될 것 같다는 이야기를 했습니다. 10년의 밤에 언급한 실패하는 연습을 반복하는 상황과는 조금 달라 우리들이 무모한 목표를 설정한 다음 여기 달려들어 마구 개발하고 있지는 않습니다. 마일스톤을 시작할 때 예상한 플레이시나리오를 어느 정도 달성하는 범위 안에서 실현 불가능한 목표를 수정하고 또 첫 홀더 테스트를 마쳤습니다에서 언급한 것과 같은 짧은 서비스 일정을 적절히 조절할 여지가 충분히 있는 상황입니다. 이런 이전에 경험한 것에 비하면 훨씬 긍정적인 상황 속에서도 마일스톤 후반은 어째 실패하는 연습과 비슷한 시나리오로 흘러가 너덜너덜한 상태로 마일스톤을 마무리하게 될 것 같은 이 예감은 경험에 의한 예측인지 아니면 학습된 일종의 무기력인지 잘 모르겠습니다.

마일스톤 목표와 일정에 초점을 맞춰 개발하다 보면 장기적으로 개발 속도에 악영향을 끼치는 여러 문제를 단기적으로는 해결하지 않은 채 그냥 안고 갈 때가 있습니다. 전에 정치적으로 업무 자동화가 좋기만 하지는 않음이라고 의견을 정리한 적이 있기는 하지만 당장에 인간을 투입해 단기적으로는 무리 없이 해낼 수 있는 프로세스를 개선하지 않으면 당장에는 아무 일도 일어나지 않고 또 프로세스를 개선한다며 업무를 지연 시키고 새로운 일을 추가하면 반발을 마주할 수 있습니다. 단기적으로 이런 결과를 예상한다면 굳이 단기적으로는 별 도움이 되지 않을 수 있는 프로세스 개선을 조용히 메모한 다음 당장의 머릿속에서는 지워 버리고 마음 편히 신경 끄고 제 할일에만 집중하는 선택을 하면 됩니다. 하지만 장기적으로 이런 단기적 마음의 평안에 집중한 선택은 확실히 개인적인 정신 건강에는 도움을 주지만 장기적으로 이런 사례가 쌓이면 프로젝트 전체 비용을 증가 시킬 수 있습니다. 물론 이런 낭비를 따로 계산하지는 않기 때문에 낭비가 낭비로 드러나지도 않으니 당장의 할일에 집중하고 정신 건강에 올바른 선택을 하더라도 개인에는 아무런 문제도 생기지 않습니다.

이전에 참여한 적 있는 커다란 프로젝트에서 프로젝트 전체의 문서 관리에 컨플루언스를 사용했는데 프로젝트를 시작하고 컨플루언스를 처음 도입할 때는 별 문제 없었겠지만 시간이 흐르며 여러 사람들이 작성한 온갖 문서가 쌓이기를 반복하며 프로젝트 컨플루언스는 어떤 문서가 현재 유효하고 또 어떤 문서가 그렇지 않은지 판단하기 어려운 거대한 쓰레기통 같은 상태가 되었습니다. 그렇다고 이 도구가 아니면 달리 프로젝트에서 생산되는 온갖 문서를 공유하고 보관할 더 나은 방법도 없었기에 이 상태를 유지했습니다. 회사에서는 큰 비용을 들여 프로젝트 구성원 전체가 컨플루언스를 사용할 수 있도록 했지만 이 도구를 통해 큰 프로젝트에서 문서를 어떻게 유지보수 해야 할 지에 대한 힌트를 주지는 않았는데 당연히 이 부분은 프로젝트 내부에서 해결해야 할 문제였습니다. 하지만 프로젝트 수준에서 컨플루언스에 쌓인 엄청난 문서를 관리하고 유지보수할 정책을 가지고 있지도 않았고 그런 정책이 필요하다고 생각하지도 않았던 것 같습니다. 시간이 지나자 사람들은 이미 오래전에 작성되어 현재와 전혀 맞지 않는 기획서 문서 트리에 새 문서를 추가하기를 포기하고 적당히 비슷한 카테고리 이름 하위나 아예 개인 공간에 문서를 작성하기 시작합니다.

이 상황에 대해 모두가 문제의식을 가지고는 있었지만 프로젝트 전체에 적용할 만한 어떤 의견으로 발전 시키지는 못했는데 그도 그럴 것이 우리들은 당장의 할일에 집중하기도 쉽지 않은 상황이었고 또 상황을 개선하려는 어떤 시도가 성공할지 여부 역시 확실하지 않아 함부로 목소리를 내 제안하기 어려웠기 때문입니다. 약간 급진적인 의견을 가지고 계시던 분들은 개인 공간에 작성된 문서가 위키 본연의 기능 중 하나인 다른 사람들이 작성한 문서를 쉽게 수정할 수 있게 하는 동작을 무력화 한다는 점에 집중해 아예 개인 공간을 없애고 모든 문서는 제한된 공간 안에서만 작성하게 하면 이 상황을 개선할 수 있으리라는 의견을 내기도 했습니다. 컨플루언스에서 개인 공간은 다른 사람이 읽을 수는 있지만 수정할 수는 없어 개인 공간에 문서를 작성하기 시작하는 행동은 문서 분류를 확정할 필요가 없어 문서 작성을 시작하기 쉽게 만들지만 다른 사람이 수정할 수는 없어 종종 문제를 일으켰고 또 검색으로 찾기 힘든 문서를 내비게이션 만으로 거의 찾을 수 없도록 만들고 있어 이런 약간은 과격한 제안이 나올 수 있었습니다. 하지만 프로젝트 전체에 이런 제한을 납득 시킬 수 있을지 여부는 또 다른 차원의 문제였기에 이런 의견은 결국 시도 단계에 도달하지 못합니다.

한편 지금 참여하는 프로젝트 역시 비슷한 문제가 있습니다. 문서 도구로 사용하는 노션은 그나마 마일스톤 단위의 문서를 마일스톤에 따라 구분된 한 공간 하위에 작성하도록 해 어느 정도 문서가 아무데나 생성되어 검색 없이 내비게이션을 통해 탐색이 불가능해지는 문제를 완화하고는 있습니다. 하지만 여전히 동북아시아에서 나고 자란 사람들의 특성 상 다른 사람이 작성한 문서를 수정하기를 꺼리고 또 자신에게 편안한 개인 공간에서 문서를 작성한 다음 이 위치를 유지한 채 문서 권한만 공개로 바꾸는 행동을 해 내비게이션을 통한 탐색을 방해하기도 합니다. 하지만 대체로 이런 행동을 하는 분들은 이전 시대에 비해 소수여서 당장 문제를 재기할 만한 수준은 아니어서 그저 지켜 보고만 있습니다. 또 컨플루언스와 비슷하게 노션 역시 문서의 위치를 바꿔도 문서의 웹 주소가 그대로 유지되기 때문에 문서 위치를 바꿀 때 링크가 깨지지 않아 언젠가 문서 위치를 한바탕 수정하더라도 별 영향이 없어 굳이 지금 당장 문제를 해결하려고 해 혼란을 일으킬 필요가 없습니다.

하지만 프로젝트의 에셋 위치는 노션 문서만큼 느슨하게 관리하기에는 신경이 더 쓰이곤 합니다. 가령 언리얼 엔진 기반에서 개발할 때 레벨은 주로 /Contents/Levels/ 하위에 넣고 캐릭터와 몬스터 관련 에셋은 프로젝트에 따라 /Contents/Characters/ 하위 또는 /Contents/CH/ 하위에 넣곤 했습니다. 현대에는 어떤지 신경 쓰지 않아 잘 모르겠지만 한때 플랫폼에 따라 전체 경로 길이에 제한이 있을 때 그 플랫폼을 타겟으로 한 빌드에 실패할 때가 있어 디렉토리 이름을 줄여 캐릭터는 CH, 몬스터는 MN, 블루프린트는 BP와 같이 전체 경로 길이를 줄이기 위한 이름을 사용하곤 했습니다. 또 이번 프로젝트에는 이전에는 사용하지 않았던 개발자 별 서브디렉토리인 /Contents/Developers/ 디렉토리를 사용하고 또 아직 제작 중인 에셋을 임시로 넣어 두는데 사용하는 /Contents/Working/ 디렉토리를 만들어 사용했습니다. 전자는 언리얼 엔진 기능의 일부로 컨텐츠 브라우저에서 켜고 끌 수 있었고 후자는 프로젝트의 규칙이었습니다.

문제는 제작이 끝났거나 어느 정도 작업이 진행되어 본격적으로 협업 파이프라인에 올라간 에셋이 여전히 이 디렉토리를 벗어나지 않은 채 이 경로에 의존해 계속해서 개발되고 있다는 점입니다. 가령 어떤 레벨은 지난 짧은 서비스에 사용되었지만 여전히 /Contents/Working/ 하위에 있어 이 레벨이 /Contents/Levels/ 하위에 있을 거라고 예상한 내비게이션을 통해 레벨 경로를 찾으려던 사람들을 쉽게 좌절시켰습니다. 또한 지난 마일스톤에 등장한 모든 몬스터들의 데이터는 /Contents/Developers/ 하위에 있어 관련 개발에 직접 참여한 사람들이 아니고서는 이 위치에 몬스터 관련 에셋이 있으리라고 예상하기는 쉽지 않습니다. 게다가 이렇게 개개인이 편안하게 사용할 수 있는 위치에서 작성된 에셋은 빌드를 생성할 때 임시 에셋과 실제 빌드에 필요한 에셋을 구분하기 아주 어렵게 만들어 별 것 없는 클라이언트 크기를 이미 엄청나게 키우는 문제를 일으키고 있었으며 장기적으로 클라이언트는 누군가에 의해 반드시 난도질 되기 마련이므로 보안 문제를 일으킬 수도 있었습니다.

이 상황이 문제가 있음을 프로젝트 내 여러 부서의 여러 사람들이 인식하고 있었고 이런 의견은 그저 잡담으로만 떠돌다가 종종 전혀 상관 없는 회의에 갑자기 나타나 전통적인 기획자의 낮은 직급 문제를 겪는 사람들을 곤란한 상황으로 밀어 넣곤 합니다. 하지만 문제가 있음을 알고 있다고 해서 마일스톤 막바지로 치닫는 상황에 의견을 받아들여 당장 주요 에셋의 경로를 조정하자는 결정을 내릴 수는 없었습니다. 이론적으로 언리얼 에디터 상에서 에셋 위치를 옮기면 이 에셋을 가리키는 다른 에셋의 경로를 자동으로 수정해 주기 때문에 한 에셋의 위치를 옮긴 다음 이 에셋에 의해 영향을 받은 나머지 에셋들을 에디터가 함께 수정한 다음 수정된 모든 에셋을 한 번에 커밋하면 문제를 일으키지 않습니다. 그래서 마일스톤 목표에 해당하는 에셋들을 각자가 언리얼 에디터 상에서 조금씩 옮긴 다음 커밋하기를 반복하면 큰 비용을 들이지 않고 에셋 위치들을 조정할 수 있습니다. 다만 이론적으로는 그렇고 실제로는 하드코딩 된 에셋 위치가 존재할 수도 있고 언리얼 엔진이 인식하지 못하는 방식으로 참조되는 에셋이 있을 수도 있으며 프로젝트에 참여하는 모든 사람들이 한 번에 변경사항을 적용하지 않으면 누군가는 이미 위치가 변경된 에셋을 수정한 다음 커밋하려다가 곤란을 겪을 수도 있습니다.

그래서 문제를 인지하고 있고 중장기적으로 이 상황이 개발 비용을 올릴 것임을 이해하고 있으나 이번 마일스톤에 당장 문제를 해결하지 않고 이번 마일스톤 개발 완료 및 짧은 서비스를 마무리하고 나서 다음 마일스톤을 시작하기 전에 에셋 경로를 정리하거나 다음 마일스톤 목표에 포함해 에셋 경로를 정리하기로 하는 선에서 문제 제기를 수용했습니다. 하지만 당장 발생하는 비효율을 남은 마일스톤 기간 동안은 유지하자는 결정은 좀 더 성격이 급하고 또 프로젝트의 비효율에 민감하며 스스로 의견을 빌드에 직접 반영할 권한과 기술이 있는 분들께는 잘 받아들여지지 않을 수 있습니다. 이 분들은 선의로 당장 이 비효율을 제거하기를 원하시는데 이런 의도는 순전히 프로젝트에 대한 선의로부터 비롯됩니다. 다만 이 선의는 본인의 작업에 한정된 상대적으로 좁은 시야 때문에 실제보다 난이도가 낮아 보일 수 있습니다. 누군가의 시야에는 그냥 지금 당장 /Contents/Working/ 하위 어딘가에 있는 레벨 디렉토리를 /Contents/Levels/ 하위로 옮기고 언리얼 에디터가 참조 문제를 해결해 주면 이를 커밋하기만 하면 되는데 왜 이를 마일스톤 종료 다음으로 미뤄야 하는지 이해하지 못할 수 있고 또 당장 이를 실행해서 커밋해 버릴 수도 있습니다.

팀의 한 분이 당장 이렇게 하겠다고 이야기했는데 이 의견이 방금 이야기했듯 프로젝트에 의한 선의로부터 비롯되었음을 알기에 당장 ‘이번에 안 하기로 했잖아요?’ 라고 반응하기도 좀 뭣하단 생각이 들었습니다. 그래서 조금 지켜보다가 언리얼 에디터가 에셋들의 의존성을 대체로 해결해준다는 점은 이해하지만 언리얼 엔진이 인식하지 못하는 방식으로 의존성을 가지고 있는 곳들이 있을 수 있고 또 에셋을 사용하는 모든 사람들이 한번에 업데이트 하지 않으면 문제가 일어날 수 있으며 이 문제해결에 비용이 들 수 있으니 지금 당장은 하지 않았으면 한다고 이전에 했던 이야기를 가벼운 수준으로 설명합니다.

하지만 그 분은 본인의 주장이 올바르며 작업이 그리 크지 않고 지금 당장 수행해 비용 낭비를 완화할 수 있다는 사실을 다시 한 번 강조하셨는데 사실 팀 전체에 일어날 가능성이 있다는 점을 제외하면 주장에 틀린 점이 없었기에 어떻게 할지 약간 고민했습니다. 무작정 이전에 결정된 바, 방금 이야기한 이유를 다시 한 번 반복하며 지금 당장 수행하려는 그 행동을 마일스톤 종료 시점까지 기다려 달라고 조금 더 강하게 이야기할 수도 있었고 또 한번 한 위험성에 대한 이야기를 다시 한 번 반복하고 수긍하기를 기대할 수도 있었습니다. 그런 고민을 하는 사이 이 분은 이미 본인이 설정한 정책에 따라 에셋을 이동한 다음 이 사실을 선언하셨는데 불행하게도 그 규칙은 위에서 설명한 에셋 경로 길이를 줄이기 위한 것도 아니었고 또 언리얼 엔진 기반 프로젝트에서 흔히 사용하는 경로 네이밍 규칙을 따른 것도 아닌 뭔가 이상한 규칙이었습니다. 이제 관리자로써 뭔가 행동을 취해야만 하는 상황이 된 겁니다.

만약 더 어릴 때의 저라면 일단 권한을 사용해 이 행동을 취소 시키고 좀 더 강하게 상황을 설명하고 또 방금 했던 독단적인 행동이 일으킬 수 있는 문제를 설명할 수도 있었습니다. 이 과정은 권한을 사용해야 하기에 저 스스로의 체력과 정신력을 사용해야 하고 또 앞에 이미 충분히 설명했다고 생각하는 설명을 반복해야 할 뿐 아니라 권한 사용에 따라 자칫 스탭님께 상처를 줄 수도 있습니다. 그럼에도 불구하고 좀 더 어린 저였다면 명백한 문제가 발생한 상황에 좀 더 강하고 단호하게 대처해 방금 푸시한 커밋을 취소 시키고 행동에 대한 문제를 제기했을 겁니다. 이 과정의 일부는 부드럽겠지만 다른 일부는 그렇지 않을 수도 있습니다. 하지만 어릴 때 이런 식으로 행동해보니 이런 접근은 단기적으로 문제를 해결하지만 장기적으로 저 자신의 평판을 나쁘게 만들었는데 심지어 그 조치가 프로젝트 전체에 올바른 결정이었음이 확인되더라도 저 자신에 대한 평판은 달라지지 않곤 했습니다. 이전에 참여했던 큰 프로젝트에서 이런 실수를 많이 했는데 덕분에 10년이 지난 지금도 저를 아주 나쁘게 평가하는 분들이 남아 있고 이런 평가는 제 평생에 걸쳐 수정할 수 없습니다.

그래서 이제는 좀 더 치졸하고 교활한 방법을 사용하기 시작했습니다. 혈기 왕성한 누군가가 자신의 시야 안에서 옳다고 생각하는 행동을 독단적으로 실행해 버리더라도 당장 이를 문제 삼지 않습니다. 분명 이전에 지금 당장 그렇게 해서는 안되는 이유를 여러 번 설명했고 그 행동을 할 시점을 지정해 놓았으니 굳이 지금 일어난 행동을 문제 삼을 필요가 없습니다. 그러면 제 자신의 체력과 정신력을 보호할 수 있고 또 행동을 한 분의 사기를 유지할 수도 있으며 근미래의 자잘한 문제해결이 일어나지 않도록 하기 위해 제 평판을 망가뜨릴 필요도 없습니다. 다만 조용히 새 규칙을 무시하고 이전처럼 행동하기만 하면 됩니다. 이 분들은 혈기 왕성하지만 시야가 상대적으로 넓지 않아 프로젝트 전체에 걸쳐 영향을 주는 정책을 배포하기 아주 어렵습니다. 그래서 이 분의 결단과 실행에 관계 없이 프로젝트 전체는 이전과 똑같이 행동할텐데 저 자신도 조용히 그들과 한 편이 되어 새 규칙을 무시하기만 하면 됩니다. 그 개인의 작은 반발이 있겠지만 적당히 위로하고 적당히 지키는 척 하다가 이전으로 돌아가기를 아무렇지도 않게 반복하면 관리자인 제 평판을 유지하고 또 제 체력과 정신력을 낭비하지 않으면서도 개인을 좌절 시켜 상황을 원래대로 되돌려 계획 대로 진행 시킬 수 있게 됩니다.

이번에도 비슷한 일이 일어났고 저는 딱 한번만 지금 그래서는 안되는 이유를 설명한 다음 상황을 지켜 봤고 더 이상 낮은 비용으로 설득하기 어렵겠다는 판단을 하자마자 뒤로 물러나 교활한 늙은이처럼 저 정책을 의도적으로 무시해 개인을 좌절 시키기로 마음 먹었습니다. 하지만 제 상사는 그렇게 생각하지 않았기에 마치 젊을 때의 저처럼 끝까지 개인을 설득해 당장 좀 이상한 개인적인 새 정책의 적용을 취소하게 만들고 근미래에 이 문제를 해결할 계획이 이미 수립되어 있음을 다시 한 번 강조했는데 이 상황은 원래 제가 표면적으로 해결해야 하는 문제였지만 저는 그런 방식으로 해결할 생각이 전혀 없어 뒤로 물러나자 제 상사가 나선 상황이었습니다. 당연히 제 상사로부터 한 소리를 들었는데 젊을 때의 저였다면 지금 문제에 접근한 방식을 사용했겠지만 젊을 때 그런 행동들이 결국 제 자신의 평가를 망가뜨려 오랜 세월이 지난 다음에도 나쁜 평가를 받게 만드는 마당에 그런 방식을 전혀 사용하고 싶지 않으며 교활하고 또 치졸하게 조용히 규칙을 무시하는 방식으로 직접적인 나쁜 사람이 되지 않으면서도 문제를 완화하며 대신 개인을 좌절 시키는 방법을 사용할 작정이라고 해명했습니다.

물론 이런 접근이 말 그대로 교활하고 상사님의 표현에 따르면 ‘삐딱’하며 솔직히 좀 구리다는 사실을 인정합니다. 그런데 젊을 때 미움 받을 용기를 가지고 행동해 보니 적어도 제 개인의 관점에서는 이를 통해 일이 조금 더 잘 진행되었을 수 있지만 그 누구도 이를 알아보거나 인정하지 않았고 비용을 절약하더라도 결국 그 공이 저에게 돌아오지도 않으며 저는 그저 계속해서 문제를 일으키고 다니는 예민한 사람으로 인식되는 결과를 가져올 뿐이었습니다. 하지만 조용히 뒤로 물러나 교활하고 치졸하고 또 삐딱하게 의도적으로 규칙을 무시하는 방법으로 개인을 좌절 시키면 그런 문제를 겪지 않고도 같은 결과를 얻을 수 있고 또 저 자신의 자원을 사용하지 않을 수도 있습니다. 앞으로도 이번 대응과 같은 자세를 유지할 작정이지만 물론 그런 방식이 과연 올바른가 하는 의문은 남아 있기는 합니다.