사실 게임 프로그래머 리더십에 대한 이야기

리펙토링 2

내가 메그넘 프로젝트의 코드가 더럽다고 말하자 허윤 파트장님과 내 동기 4명은 토끼 눈을 하고 나를 바라봤다.

“조금 더 말씀드리면, 코드가 급하게 짜인 것처럼 보입니다. 20여 명의 클라이언트 개발자들 사이에 컨벤션이나 코드 가이드 같은 것들이 없지 않았나 싶습니다. 그래서 중복 함수도 많고, 어쩔 수 없이 중복되는 영역을 여러 명이 작업해야 하는 곳은 캡슐화가 전혀 되어있지 않아 보입니다.”

허윤 파트장님은 입사 일주일 차인 수습 직원의 조금 솔직한 평가에 황당한 마음이었을 거다.

허윤 파트장님이 우리 다섯 명의 수습에 말했다.

“여러분은 리팩토링이 무엇이라 생각하시나요?”

허윤 파트장님은 한명 한명 집으면서 대답을 요구했다. 내 동기들은 각자의 대답을 했다.

“코드 정리를 통해 최적화를 하는 것입니다···”

“중복 함수를 정리하면서 버그를 찾아 없애는 것입니다···”

등등 다들 리팩토링을 통한 목적을 초점으로 대답했다. 다음은 내 차례였다.

“진수 님은 리팩토링이 뭐라 생각하시나요?”

“리팩토링이란, 목적이 없어야 하는 작업입니다. 내부적으로 코드의 관계만 변할 뿐. 결과는 아무것도 변하면 안 됩니다. 그게 핵심입니다. 만약 기존에 어떠한 버그가 있었다면, 리팩토링은 그 버그까지 옮겨와져야 합니다.”

“왜 그렇게 생각하시죠?”

“신뢰성의 문제입니다. 리팩토링이 필요한 경우는 대부분 여러 작업자가 공통으로 일하는 프로젝트입니다. 누군가 A에 대해서 리팩토링할 때, A의 기능이 조금이라도 달라진다면 그

리팩토링은 다른 작업자들의 신뢰를 얻을 수 없습니다. 그럼 리팩토링을 진행하는 사람뿐 아니라 전체 작업자들이 리팩토링으로 인한 사이드를 함께 해결하게 됩니다. 결국, 리팩토링은 코드 생산성을 좋게 하기 위한 것인데, 전체 작업자가 리팩토링으로 인한 사이드를 겪는다면 차라리 리팩토링하지 않는 것이 낫다고 생각합니다.”

“흠··· 진수 님은 리펙토링 작업을 해본 적 있나요?”

지금 생각해보면, 미믹게임즈 당시 코드를 재활용하기 위해 레고블록처럼 코드를 만들었던 것이 리팩토링이었다.

“레고 블록을 만들어 본 적이 있습니다.”

“마침 잘됐네요. 저희 코드 리팩토링을 할 사람이 필요했는데. 진수 님에게 맡겨보겠습니다.”

이렇게 나는 허윤 파트장님 직속으로 리팩토링 작업을 하게 됐다.

나는 이미 파트 내에서 리팩토링하는 두 명의 선배를 소개받았다. 두 명도 리팩토링을 시작한 지는 일주일 정도밖에 되지 않았고, 대신 경력은 모두 10년 이상으로 고경력자였다.

경력이 많은 두 명의 선배가 코어 로직을 리팩토링했고, 상대적으로 경력이 적은 나는 콘텐츠를 순차적으로 리팩토링하기로 했다.

내가 질문했다.

“리팩토링은 어떻게 하면 될까요?”

허윤 파트장님이 말했다.

“딱히 정해진 것은 없고, 각자 노하우대로 카드 가독성을 높여 주시면 됩니다.”

“네.”

리팩토링을 다른 사람과 함께 하는 것은 처음이다. 그동안은 리팩토링을 나 혼자만 했었다. 그래서 지금 리팩토링을 각자의 노하우대로 하라는 말에 대해서 위험성을 몰랐다. 하지만, 이렇게 정해진 목적이나 룰 없이 리팩토링을 각자 하는 것이 얼마나 위험하고 어리석은 행동이었는지 알게 되는 데에는 생각보다 오래 걸렸다.

우선, 나는 툴을 만들기 위해 몬스터 코드를 본 김에, 몬스터 쪽을 먼저 리팩토링 하기로 했다.

내게 리팩토링이란 레고 블록과 같다. 기능을 하나하나 잘개 쪼개고, 그것을 재조립하기 편하게 모아두면 끝이다. 크게 깊이 생각할 것 없는 단순 반복 작업이다.

리팩토링 첫날은 상상하는 데에 시간을 모두 썻다. 내가 이렇게 쪼개고 조합시키면, 어떤 모습이 될까? 그 모습은 나 외의 다르 작업자에게도 도움이 될까?

뭐가 됐든 지금처럼 중구난방인 코드보다는 나을 것이라는 판단이 섰다. 그래서 그 다음 날부터 몬스터 코드를 레고블럭화 하기 시작했다.

프로젝트가 컨텐츠 양산을 시작한지 얼마되지 않아 몬스터 코드는 양이 많지 않았다. 그래서 몬스터 관련 코드의 리팩토링은 삼일만에 끝냈다.

나는 허윤 파트장님에게 보고했다.

“파트장님. 몬스터 쪽 코드 리팩토링 다 했는데 확인 부탁드립니다.”

허윤 파트장님은 내 코드를 확인도 하지 않고 말했다.

“기능 변화 있나요?”

“아니요. 블록화만 시켰습니다.”

“그럼 커밋 하세요.”

“제 코드 확인 안 해보셔도 될까요? 코드 변화량이 꽤 많은데···”

“네. 나중에 제가 로그로 확인할 테니 우선 커밋 하세요.”

“네. 알겠습니다.”

조금 다 같이 사용하는 코드를 코드 리뷰도 받지 않고 대량 커밋 한다는 것이 찝찝했지만, 허윤 파트장님의 지시대로 리팩토링 코드를 푸시했다.

내 인생의 경험상 나처럼 무딘 사람이 찝찝함을 느낄 때는 반드시 문제가 발생한다.

서익준 님에게 메시지가 왔다. 지난주 매그넘 프로젝트 svn로 그를 봤을 때, 서익준 님은 매그넘 프로젝트 초창기 멤버 중 한 사람이었다.

단순 텍스트로만 보이는 메시지에서도 신경질적인 상대의 감정이 느껴졌다.

“이진수 님이 Binary 아이디 쓰시는 거 맞죠?”

“네 안녕하세요. 이번에 입사한 이진수라고 합니다.”

그는 바로 본론으로 들어갔다. 성격이 급한 사람인 것 같다.

“몬스터 코드 모두 바꿔서 커밋 하셨던데, 왜 그러신 거예요?"

“네. 허윤 파트장님이 리팩토링해보라고 하셔서 수정했습니다.”

“하··· 진수 님도 리팩토링 하시는거에요?”

나이도, 얼굴도 모르는 상대가 인사도 없이 예의 없게 구는 것이 나도 신경 쓰였다.

“네. 그렇게 됐어요.”

“또 누가 더 리팩토링하나요?”

“그건 허윤 파트장님한테 물어보시는 게 나을 것 같네요.”

“흠··· 알겠습니다.”

“네”

“그리고, 제 코드 수정하지 마세요.”

“제 코드라니요?”

“몬스터 쪽 코드는 되도록 건드리지 마시라고요.”

나는 대답하지 않았다. 우리나라 최고의 인재들을 모아 둔 3N 게임즈에서는 코드에 주인이 있나 보다. 아무튼 입사 이 주차인 내가 결할 일은 아니었다. 그리고 이 사건을 클라이언트 리더가 인 허윤 파트장님이 어떻게 해결하는지 지켜보고 싶었다.

나는 허윤 파트장님에게 메시지를 보냈다.

“파트장님 안녕하세요.”

“네 진수 님.”

“서익준 님한테 메시지가 왔는데요. 리팩토링에 대해서 말씀하셨어요."

“흠··· 익준 님이 리팩토링하지 말라던가요?”

“네. 비슷한 뉘앙스였어요."

“흠··· 제가 회의 중이라, 회의 끝나고 익준 님이랑 얘기해볼게요.”

“넵”

나는 곰곰이 생각해 봤다. 이 관계에 흥미로웠다. 클라이언트 프로그래머 직군의 공식 리더인 허윤 파트장님과 프로젝트 스타팅 멤버이면서, 업무량이 매우 많은 서익준 님. 이 둘의 관계가 궁금해졌다.

우선 허윤 파트장님은 딱히 남을 괴롭히거나 하는 타입은 아닌 것 같다. 하지만 친절하게 누군가를 잘 케어해주는 타입도 아니었다. 반면 서익준 님은 어떨까?

나는 서익준 님에게 메시지를 보냈다.

“안녕하세요. 이진수입니다.”

서익 주은 1초 만에 회신했다. 성격이 급한 것 같다.

“네 안녕하세요. 무슨 일이시죠?”

“네 다름이 아니라, 저는 허윤 파트장님에게 리팩토링을 하라고 업무 지시를 받았는데, 익준 님은 코드를 수정하지 말라고 하셔서요.”

“그건 제가 허윤 파트장님과 얘기해 보겠습니다."

“네. 그런데 그전에 개인적으로 궁금한 것이 있어요.”

“네?”

어차피 상대도 직설적인 타입인 것 같아서. 나도 질문을 에둘러 표현하지 않았다.

“리팩토링이 왜 싫은지 궁금해요.”

“리팩토링이 싫다고 한 적 없습니다.”

“저한테는 그렇게 들렸어요.”

“저는 콘텐츠를 만들어야 돼요. 그런데 리팩토링으로 우리가 알던 함수가 변경되고, 버그가 자꾸 생기니까 그게 싫은 거예요."

리팩토링이 싫은 진짜 이유는 저기 있었군. 익준 님처럼 진솔한 타입이 대화의 효율은 좋다. 대화를 할 때마다 내 기분이 안 좋아진다는 단점은 있지만 말이다.

“그럼 콘텐츠 개발자들이 불편하지 않게 작업하면 리팩토링을 반대하시는 건 아닌 거죠?”

“네. 버그도 없으면요.”

나는 해결법을 찾은 것 같다. 겸손하지 않은 상대뱡을 위해 나도 겸손을 버렸다.

“네. 제 리팩토링에 버그는 없을거에요. 제가 리팩토링해서 변경한 몬스터 코드 API를 수정해서 기존 몬스터 작업자들이 리팩토링이 됐는지도 모르게 수정해둘게요.”

(API란 기능의 이름이다. 컨텐츠 개발자들이 그 기능을 사용하기 위해 부르는 이름. 이 API만 변경되지 않으면 내부가 얼마나 많이 변경되든, 컨텐츠 개발자들은 기존 기능을 그대로 사용할 수 있다)

익준 님은 내 마지막 메시지에 대답하지 않았다. 나를 못믿는 것인지, 대화가 끝났으니 대답은 불필요하다고 생각 했던 것인지.

아무튼 나는 허윤 님이 회의를 끝내고 오기 전에, 내가 리팩토링으로 변경시킨 API에 인터페이스를 한꺼플 더 씌워 기존 작업자들이 사용하던 API로도 리팩토링된 코드를 사용할 수 있도록 작업해서 커밋했다.

그리고 서익준 님에게 메시지를 보냈다.

“익준 님. 방금 API 맞춰서 다시 커밋 했습니다. 문제 있으면 다시 연락 주세요.

“네.”

그리고 잠시 뒤, 허윤 파트장님이 내게 왔다.

“진수 님 잠시 회의실로 가서 얘기할까요?”

“네.”

나와 허윤 파트장님 둘은 회의실로 들어갔다.

허윤 파트장님의 얼굴과 몸짓에는 그가 난감해한다는 사실이 그대로 드러났다. 그는 서익준 님을 어려워하는 것 같다. 자기 부하 직원임에도 불구하고, 그는 서익준 님을 어려워하고 있는 것 같았다.

나는 허윤 파트장님을 이해한다. 실력이 좋고 내부 프로젝트에 이해도가 높은 사람이 프로젝트에 항상 도움되는 것은 아니다. 더군다나 그 유능한 사람이 조직의 분위기 따위 무시하고 자기 실력만 존중하며, 다른 사람의 기분 따위는 신경 쓰지 않는 타입이라면, 그의 조직자에게는 큰 골칫거리일 확률이 높다.

허윤 파트장 님은 자신의 업무 지시를 공식적으로 반대한 서익준 님 때문에 난감해하고 있다.

나는 허윤 파트장님의 고민을 덜어주기로 했다.

“파트장님. 파트장님이 회의 오래 하시길래 제가 익준 님과 얘기했습니다.”

“어떻게요?”

“제가 리팩토링이 왜 싫냐고 물어봤는데. API 변경과 버그만 없으면 괜찮다고 했어요. 그래서 제가 기존 API랑 호환되게 리팩토링 코드 다시 수정해서 커밋 했습니다.”

“익준 님이 그렇게 하래요?”

“아뇨. 제가 그렇게 하겠다고 했어요.”

“익준 님이 별말 안 하던가요?”

“네. 조금 전에 커밋 했다고도 알려줬어요.”

“아··· 수고하셨습니다. 진수 님.”

나는 이주만에 많은 것을 깨닳았다. 매그넘 프로젝트의 코드를 보면, 분명 난이도 높은 수준의 코드가 많이 들어가 있다. 그리고 코드 하나 하나에 요구되는 완성도도 높다. 이는 3N게임즈에는 유능한 사람이 많이 모여있다는 것을 의미한다.

그러나, 내가 지금 리팩토링을 하는 이유와 마찬가지로, 코드의 복잡도가 너무 높다. 그리고 그 높은 기술력과 완성도로 만들어진 각각의 기능이 조화되지 못하고 있다.

오히려 유능한 사람이 한명이라면, 모두 그 사람을 필두로 따라가겠지만, 능력자가 많은 이 회사에서는 오히려 능력자가 많은 것이 비효율을 만들고 있다.

나는 생각했다.

오히려 조직력은 절대 강자 1인이 있었던 미믹게임즈가 가장 좋았다.

이 큰 회사에서 유능한 인재들이 서로 조화롭게 일하려면 방법은 하나다.

나는 이 회사의 리더가 되어 조직을 바꾸고 싶어졌다.

[페일블루]

재미있어요

[gy******..]

오 목표가 생겼네요 굳굳