2005년에 넥슨 공채로 시작한 게임 프로그래머 경력이 벌써 20주년을 맞이했다. 학교에서 보낸 시간보다 게임 프로그래머로 돈을 번 시간이 더 길다. 20주년이 된 기념으로 소박한 회고를 남겨본다.
게임 프로그래머로 입사했을 때는 멤버 모두가 어렸다. ’자녀 대학교 등록금 지원’ 같은 회사 복지를 상상하기 어려웠다. 왜냐하면 자녀가 대학생인 직원이 없었기 때문이다. 이래서였을까? 나이를 먹으면 게임 프로그래머를 못하는 거 아니야? 이런 질문들이 간간이 나오곤 했다.
“프로그래머를 40세 넘어서까지 할 수 있어요?”
우선 이 질문에 대한 답부터 해야겠다.
“네. 물론입니다.”
요약 by human
- 과거의 나를 만나면 해주고 싶은 얘기
- 20년 전 내가 지금 봤으면 놀랐을 것
- “풀파티”
- “부지런하다”
- “엔지니어링 매니저”
- 운동을 꾸준히 하고 있다
- 20년 전 내가 나를 봤을 때 실망할 것
- 구체적으로 바라는 게 없으니 크게 실망할 것도 없다
- 20년 전 나를 만나면 조언할 것들
- 스스로 계획을 세워라
- 글을 써라 - 업무 일지, 중간보고, 블로깅, 회고
- 한 걸음의 힘 - 냉소적이고 비관적인 태도를 벗어나는 마법의 주문
- 운동은 훌륭한 GC(Garbage Collection) 메서드
- 일을 100%로 완료하는 습관을 가져라
- Engineering manager(엔지니어링 매니저)의 기회가 있다면 잡아라
- 경력에 걸맞는 시야를 가져야 하고 기여를 해야 한다
- 순수 엔지니어가 아니라 게임 프로그래머
- 미워하지 말고 기대치를 낮춰라
- 변화를 일으키고자 하는 열정의 상한선
- 라이브 프로젝트 경험을 쌓아라
- 홈그라운드를 넓힐 수 있는 도구를 벼리자
- 스터디에 참여하라
- 과거 프로젝트 멤버와의 연결 고리
남의 향한 조언이라기보다는 내 자신의 회고
이 글이 뻔할 수도 있다. 특별한 경험으로 가득 찬 경력은 아니기 때문이다. 그리고 한 번쯤은 들어 본 말일 수도 있다. 형님 누님들이 좋은 얘기를 정제하고 멋진 비유를 곁들여 이미 다 말해 놓았다. 훌륭한 조언을 찾아보면 ChatGPT에 요약을 부탁해야 할 정도로 많은 양에 압도당할 것이다.
그래서 다른 사람이 아니라 내가 20년 전 나를 만나면 비트코인을 기억했다가 사라는 얘기 말고 어떤 얘기를 해줄 수 있을까? 이런 질문에서 20주년 회고를 시작했다.
간단한 경력 요약
2005년 넥슨 공채로 게임 프로그래머 경력을 시작했다. ’프로젝트 뫼비우스’, ’마비노기’, ’프로젝트 XR’, ’허스키 익스프레스’ 프로젝트에 참여했다. 엔씨소프트에서는 ’연구개발실 엔진팀’, ’리니지 3’, ’리니지 이터널’ 프로젝트에 참여했다. 넥슨게임즈에서는 ’프로젝트 DX’ 프로젝트에 참여했다. 엑스엘게임즈에서는 ’문명온라인’, ’프로젝트 X4’, ’달빛조각사’, ’아키에이지 크로니클’ 프로젝트에 참여했다.
대부분이 PC MMORPG 게임이다. 드랍 된 프로젝트도 많다. 게임을 보는 눈이 없었을까? 이렇게 생각이 들다가도 자신의 프로젝트 합류를 망설이던 내게 게임 보는 눈을 운운했던 PD의 프로젝트가 접힌 걸 떠올리면 운도 따른다고 생각한다. 확실하다고 생각했던 ’리니지 3’ 타이틀을 부여받은 프로젝트도 접혔으니 말이다.
그렇다고 모든 걸 운에만 맡겨야 할까? 아니다. 적어도 회사의 절실함과 PD를 포함한 구성원의 절실함은 있어야 나머지를 운에 맡길 수 있다.
20년 전 내가 지금 봤으면 놀랐을 것
“풀파티”
몇 명을 낳아야지. 자녀 계획이 딱히 있진 않았다. 첫째 딸기부엉이를 낳고 신기하게도 모든 일이 잘 풀렸다. 더 큰 책임감 때문이었을까? 더 열심히 살았던 것 같다. 둘째 Taek은 날 살린 것 같다. 몸도 마음도 힘들었던 시기에 지속 가능성을 생각하게 됐다. 이대로 계속할 수 있을까? 내가 통제할 수 있었던 걸 조금씩 변경해 부담을 낮추는 계기가 되어 주었다.
하나만 있으면 내가 직접 참가자가 되어야 하지만 둘이니 매니징을 주로 하고 가끔 참가만 하면 된다. 역시 애들끼리 노는 게 최고다. 많이 싸우지만.
여행지에서 집으로 돌아오는 길. 내가 운전하는 차 안에서 모두 피곤해서 잠든 모습을 보면 이런 게 가장이라고 생각하게 된다.
“부지런하다”
이런 얘기를 듣는다면 많이 놀랄 것 같다. 스스로 너무 게으르다고 생각했기 때문이다. 내일의 나를 믿고 내일로 미루는 일도 비일비재했다. 대부분 내가 가장 게으른 그룹에 속해있었던 것 같다. 새벽 6시에 수영을 다닐 때도 수영반에서 내가 가장 게을렀다. 아슬아슬하거나 약간 늦게 도착해서 물에 입수하곤 했다. 6시에 맞추는 것도 힘든데 10분~20분씩 일찍 와서 몸을 푸는 사람들을 보며 정말 부지런하다 생각했다. 집에서는 부지런한 아내를 보며 항상 나는 정말 게으르다고 생각했다. 부지런해 보이는 건 루틴 때문인 것 같다. 아침 일찍 출근하고 매주 정기적으로 블로그 포스팅을 발행하는 루틴이 나를 부지런한 사람으로 보이게 한다. 실제로도 조금은 더 부지런해진 것 같다. 꾸준한 루틴이 조금씩 변화시켰다.
“엔지니어링 매니저”
IC(Individual Contributor, 실무자)로 계속 남고 싶었다. 매니저가 되면 프로그래밍 실력이 정체되거나 퇴화할 것으로 생각했다. 해본 적이 없으니 주변에서 들은 말로 그렇게 상상했던 것 같다. 기득권 같은 실무자들이 매니저를 떠밀듯이 시키는 것도 본 것 같다.
프로그램팀장이 없던 조직이었다. PD의 권유로 프로그램팀장을 맡게 됐고 런칭까지 했다. 시야가 달라지는 걸 느꼈다. 디테일보다는 아키텍처에 더 신경 쓰게 된다. 구현 세부 사항보다는 인터페이스를 먼저 보게 된다.
프로그래밍 실력이 정체되진 않았다. IC로만 일했을 때보단 실력의 직선이 완만하지만 그래도 기울기는 양수다. 시야가 바뀐 긍정적인 영향이다. 매니징만 백퍼센트 할 수 있는 환경이 아니었다. 다행히 실무를 놓지 않아야 하고 매니징과 프로그래밍을 적절히 배분해야 한다고 생각하고 있어서 그런 환경이 불만족스럽진 않았다. 일손이 모자라 Bottleneck(병목) 지점을 맡는 경우도 많아서 항상 넘치게 일했었다. 엄청 힘들었는지 뇌가 나를 보호하려고 그 기간의 기억을 지운 것 같다. 그때가 잘 기억나지 않는다. 채용 전략이 너무 초보였다. 더 뽑아야 했다.
운동을 꾸준히 하고 있다
운동을 하긴 해야 하는데, 지금 하지 못하는 백만 가지 이유를 가지고 있던 나였다. 어떤 운동이든 하나를 꾸준히 하고 있는 게 신기하다. 운동에 재미를 붙였다기보다는 살기 위해 하는 것에 가깝지만 말이다. 그렇게 시작한 운동 습관 스노우볼링이 되니 뭔가를 하지 않으면 이상하다. 습관이란 게 이런 거구나.
수영, 복싱을 했고 지금은 달리기를 하고 있다.
20년 전 내가 나를 봤을 때 실망할 것
크게 실망할 게 없을 것 같다. 구체적으로 바라는 게 없었기 때문이다. 기대가 있어야 실망할 것도 생긴다. 미래에 대한 내 모습을 그리지 않았다. 땅을 보고 살았던 것 같다. 한 번씩은 고개를 들어 풍경도 바라봐야 했었다.
막연히 게임 하나 대박쳐서 은퇴하는 모습을 상상했던 것 같다. 만약 은퇴했으면 무엇을 하고 있을까? 경제적인 걱정 없이 프로그래밍하고 있지 않을까? 아직까진 이게 제일 재미있다.
내 이름이 저자로 적힌 책이 있는 걸 상상했었다. 블로깅을 시작한 것도 이런 욕구에서부터 시작했던 것 같다. 결과물을 정리해 개발자 컨퍼런스에 발표를 몇 번 하긴 했지만 책을 쓸 볼륨은 만들지 못했다. 아직 책을 쓰고 싶다는 욕구는 있다.
실망을 제대로 못 해서 아쉽다. 기대해야 실망할 수 있다.
20년 전 나를 만나면 조언할 것들
우선 비트코인을 사라는 조언을 하고 아래 조언을 할 것 같다.
스스로 계획을 세워라
If you don’t design your own life plan, chances are you’ll fall into someone else’s plan. And guess what they have planned for you? Not much.
당신이 스스로 인생을 설계하지 않으면, 다른 사람의 설계에 따라 살게 될 가능성이 큽니다. 그런데 그들이 당신을 위해 준비한 건요? 별로 없습니다. - 짐 론(Jim Rohn)
등대 역할을 할 열린 계획을 세울 수 있어야 한다. 통제할 수 없는 요인들 때문에 변하지 않는 닫힌 계획을 세우는 건 불가능하다. 그렇다고 핑계를 대면서 계획을 세우는 걸 미루기만 할 수는 없다.
이제까지 게임 개발을 하면서 마일스톤 시작 전에 게임 기획서가 다 준비된 적은 한 번도 없다. 게임 디자인팀(기획팀)을 욕하기엔 좋은 상황이다. 그런데 정말 이 핑계를 대면서 계획을 세우지 말아야 할까? 정말 모든 게 다 준비된 상태에서 시작하는 이상적인 상황이 오기나 하는 걸까?
외부 요인이 하나도 없다면 다음 마일스톤에는 어떤 일들을 해야 할까? 여기서부터 시작해야 한다. ’내부 주도 업무’로만 다음 마일스톤 목표를 세워두는 것이다. 50% 정도로만 채워서 진행하고 변경이 가능한 열린 계획임을 명심해야 한다. 뒤에 추가되는 ’외부 요청 업무’를 우선순위에 맞게 처리하며 균형을 잡으면 된다. 하나의 팀에서 시작한 이런 계획은 전체에 영향을 준다.
이런 계획이 주는 장점은 뭘까? 등대 역할을 할 수 있다. 단거리를 뛰는 게 아니라 마라톤을 뛰는 거라고 생각해야 한다. 디테일에만 매몰되면 해야 할 일을 허겁지겁 해치우기에 바빠서 정작 중요한 일에 힘을 제대로 쓰지 못하거나 임시방편으로 떼어놓고 뒤처리에 괴로워하게 된다.
매니저가 되면 계획을 세워봐야지? 일간 계획부터 시작해 주간 계획으로 넓히면서 조금씩 범위를 넓혀보는 게 좋다. IC(Individual Contributor)일 때는 주간 계획까지가 적당했다. 일간 계획을 세워보니 하루 만에 끝나는 일의 비율이 낮아서 컨텍스트를 유지하기에 주간 계획이 잘 맞았다. 실무자일 때 석 달 정도로 묶는 마일스톤 계획까지는 못 세워봤다. 이렇게 하기엔 변수가 너무 많아서 힘들 것 같다.
업무 계획을 세우다 보니 자연스럽게 이런 생각이 들었다. 더 중요한 내 인생에 대한 계획은 세우고 있는가? 그때부터 일상에서도 계획을 세우기 시작했다. 조금이라도 더 일찍 시작했더라면 더 나은 사람이 됐을텐데. 이런 생각을 한다.
글을 써라 - 업무 일지, 중간보고, 블로깅, 회고
글을 쓰는 건 생각하는 행위다. 예전에는 쓸 게 왜 그리도 없었는지 모른다. 지나고 보니 글솜씨에 문제가 있었던 게 아니라 생각이 부족한 탓이었다. 유려한 문장은 글솜씨에서 나오겠지만 알아듣게 쓰는 건 생각에 의존한다.
업무 일지부터 시작해 보는 게 좋다. 중간보고로 자연스럽게 이어진다. 무언가를 쓴다는 것은 정신 모델을 덤프하는 행위이기도 하다. slack 같은 인터럽트 툴들이 협업 도구가 된 시대에 인터럽트에 맞설 무기를 얻게 된다.
업무 일지를 쓰다 보면 상반기와 하반기에 있는 자기 평가에서 이전과는 다른 고민을 하게 된다. 쓸 게 없어서 찾아다니는 게 아니라 너무 많아서 중요한 업적을 추려내야 한다. 주간 업무 일지를 모으고 거기서 중요한 걸 추려내는 작업이다. 최근에 자기 평가에 쓸 내용 정리를 ai에게 도움받는 팁을 들은 적이 있다. ai를 사용해 자신이 작업한 jira 이슈나 코드를 바탕으로 한 일들을 뽑아낸다. 좋은 접근일 수도 있지만 나는 필요성을 전혀 느끼지 못했다. 내가 ai를 사용한다면 뽑아내는 게 아니라 이미 써 놓은 주간 업무 일지를 바탕으로 요약하는 용도로 사용할 것 같다.
블로깅을 하자. 글을 잘 쓰는 사람들이 부러워서 블로깅을 시작했다. 처음부터 책 같은 걸 쓸 능력이 없다는 자기 객관화가 된 덕분이다. 짧은 글들을 쓰다 보면 책을 한 권 쓸 수 있는 능력이 생기지 않을까? 이런 막연한 목표로 시작했던 것 같다. 기대하지 않은 걸 배운 것 같다. ’왜?’라는 질문을 뇌에 하드코딩한 것이다. 뇌의 입장에서 ’왜?’라고 묻는 건 에너지를 많이 써서 괴로운 행위다. 뭔가 깨달음을 얻어 한 번에 바꾸기 힘들다는 뜻이기도 하다. 꾸준히 글을 쓰다 보면 뇌가 포기하는 것 같다. ’왜?’라고 묻는 건 에너지를 많이 써서 괴롭지만 이번 생에는 어쩔 수 없군. 항상 ’왜?’라는 질문을 하게 된다.
한 걸음의 힘 - 냉소적이고 비관적인 태도를 벗어나는 마법의 주문
냉소적이고 비관적인 말과 태도를 가진 사람이 왜 항상 보이는 걸까? 비율의 문제이지 항상 있는 것 같다. 이런 태도를 지니는 사람은 어떤 걸 얻는 걸까? 감정을 발산하는 행동이니 스트레스 관리에 도움이 될 것 같다. 스스로를 더 똑똑한 사람이라고 착각하게 만들어서 자기만족에 도움을 주기도 한다.
이런 사람과는 최선을 다해 거리를 둬야 한다. 술자리에서 같은 테이블에 앉으면 온갖 숨겨진 에피소드를 듣는 재미에 잠깐 빠질 수도 있지만 그런 재미는 금방 수명을 다한다. 냉소적이고 비관적인 말을 듣는 족족 흘려보낼 수 있을까? 결국 쌓이게 된다. 말하는 사람은 스트레스 수치가 낮아지겠지만 주변 사람들은 스트레스 수치가 점점 높아진다.
다른 사람은 그렇다고 치자. 내가 이런 태도를 가지지 않으려면 어떻게 해야 할까? ’한 걸음의 힘’을 믿어야 한다. 냉소적이고 비관적인 태도는 변화를 불러오기 힘들겠다는 믿음에서 나온다. 긍정적인 변화를 불러 올 수 있는 계단을 하나씩 발견해서 올라가다 보면 비관적인 태도를 가질 여유조차 없어진다. 팀 간의 의견 교환이 활발해지길 원하면 정기적인 티타임을 만들자. 게임 최적화에 아무도 신경을 안 쓰는 것 같다면 모두가 볼 수 있는 위키에 필요한 최적화 리스트를 작성하자. 자신이 할 수 있는 한 걸음을 내디디면 된다.
냉소적이고 비관적인 사람을 멀리해야 한다. 힘이 되는 좋은 버프를 달고 게임을 만들어도 힘들다. 그런데 이런 디버프까지 달고 극복하며 개발할 여력이 있을까? 나 스스로도 이런 태도를 가지지 않게 주의해야 한다. ’한 걸음의 힘’을 믿고 할 수 있는 가장 작은 목표를 찾아서 해보자.
운동은 훌륭한 GC(Garbage Collection) 메서드
나이가 들면 자연스럽게 운동을 시작한다. 건강 검진에서 빨간색 수치가 하나둘씩 보이게 되고 운동만이 살 길이라는 걸 깨닫기 때문이다. 빨간색 스탯이 뜨기 전에 운동을 시작했으면 더 좋은 삶을 보냈을 것 같다.
체력은 여유와 자상함을 만든다. 체력이 없는데 주변 사람들에게 자상할 수 있는 정신력은 탈인간급이라고 생각한다. 멘탈 버퍼는 결국 체력인 것 같다. 가까운 사람들에게 더 친절해지고 싶으면 운동화를 신고 달리러 가면 된다.
운동은 훌륭한 GC(Garbage Collection) 수단이다. 임시 객체가 가득한 머릿속을 정리한다. 운동하기 전에 가득한 잡생각이 숨이 차오르는 운동이 끝날 즈음엔 거의 살아남지 못한다. 게임 런칭후 발생한 각종 버그에 정신적, 육체적으로 힘들었을 때 걸어서 퇴근한 게 도움이 됐다. 버스가 끊긴 늦은 시간이었는데도 걸어갔다. 퇴근하며 GC를 해주고 다음 날 출근해서 잡생각을 머릿속에 쌓는 생활의 반복이었다. 지금 돌아보면 그때 걸어서 퇴근한 게 나를 지켜준 것 같다.
어떤 운동이라고 시작하자. 주짓수 같은 운동은 한 살이라도 젊을 때 하는 게 좋은 것 같다. 나이가 들수록 관절기 부상으로 시작하기 어려운 운동이다. 주짓수를 배워보고 싶었지만 나이 때문이 타격기인 복싱을 배웠다. 달리기도 좋다. 달려서 출근할 수 있는 거리에 산다면 출근과 운동을 한 번에 해치울 수 있다. 미혼이라면 새벽 수영을 강력하게 추천한다.
GC도 하고 몸도 건강해지고 멘탈 버퍼도 만드는 운동이 최고다.
일을 100%로 완료하는 습관을 가져라
Issue tracking system을 통해 받은 이슈를 완료하기 전 100%로 완료하기까지 남은 일이 있는지 확인하자. 공유할 거리가 있다면 문서를 써서 팀원에게 발표하자. 거창하지 않아도 괜찮다. 정기적으로 열리는 주간 회의 같은 곳에서 같은 팀 동료에게만 공유해도 충분하다.
덩치가 큰 일이면 잘 정리해서 개발자 컨퍼런스에서 발표를 해보자. 90%로 끝냈을 일이 발표 자료를 만들면서 100%로 만들어지는 경험을 할 수 있다. 나는 ’NDC22 달빛조각사에서 서버 테스트 코드를 작성하는 방법 발표 후기’를 준비하면서 그런 경험을 했다. 만약 발표하지 않았다면 90% 정도에서 스스로 만족했을 것이다.
Engineering manager(엔지니어링 매니저)의 기회가 있다면 잡아라
IC(Individual Contributor)면 절대 배우지 못할 것들을 배우는 매니저를 할 수 있는 기회가 있다면 하라고 얘기하고 싶다. 프로젝트를 보는 시야와 프로젝트에 대한 기여를 한 번에 점프시킬 기회다. 한 번 매니저를 하면 끝까지 매니저를 하는 것도 아니다. 다시 IC로 내려가 프로젝트에 기여하기도 한다. 팀장의 고충을 아는 팀원의 배려는 고맙다.
프로그램팀장을 하는 사람들의 태도가 변해가는 걸 곁에서 보곤 한다. 프로그램팀 입장만 고수하는 사람에서 더 큰 시야로 프로젝트에 도움이 되려면 어떻게 해야 하는지를 생각하고 행동하게 된다. 커뮤니케이션도 좀 더 부드러워지는 것 같다. 나만 잘하면 되는 직책에서 프로그램팀이 잘해야 하고 더 크게는 프로젝트가 잘 돼야 하는 넓고 높아진 목표를 경험하면 변하게 된다.
팀원과 연봉 협상을 하고 사인받는 시기가 오면 소화가 잘되지 않아서 점심을 건너뛰곤 했다. 소화가 잘되지 않아서 식사를 건너뛴 건 딱 이때뿐이었다. 그만큼 엄청난 부담이었다. 매번 아쉬운 소리를 들으며 사인 여부를 결정하는 처지에서 아쉬운 소리를 하며 사인받아야 하는 처지가 되었다. 이 정도는 되겠지 하는 암묵적인 추가적인 협상 금액을 융통하며 사인받아야 했다. 어떤 협상 카드를 내면 내가 PD에게 조금이라도 더 추가로 타내려고 노력하겠다는 걸 연봉 협상을 하는 입장이 되어보니 알겠더라. 지금은 전자서명으로 모든 게 바뀌었다. 바뀌기 전 연봉 협상을 직접 하는 소중한 경험을 하게 됐다. 물론 지금 다시 하라면 점심을 또 굶을지도 모르겠다.
실무를 놓아서는 안 된다. 처음에는 매니징을 100% 가까이하면서 시스템을 만들고 안정적으로 굴러가기 시작하면 50% 정도로 낮추면 이상적일 것 같다. 매니저를 맡은 후로 계속해서 맡을 수도 있지만 IC(individual contributor)로 기여할 수 있는 좋은 프로젝트에 참여할 기회를 얻기도 한다. 매니저를 맡았을 때의 경험을 바탕으로 매니저를 도우며 충분히 IC로서 프로젝트 참여도 할 수 있다. ’소프트웨어 아키텍처 101 (마크 리처즈, 닐 포드, 2021)’ 책에서 도움을 얻을 수 있다. 우선 순위가 떨어지는 일 위주로 해야 한다. 병목이 되는 일을 하면 디테일에 매몰돼서 정작 해야할 매니징을 소홀히 하게 되니 피할 수 있으면 피해야 한다. 나는 몇 번 어쩔 수 없이 병목을 맡게 돼서 디테일에 매몰되면 어떻게 되는지를 몸으로 체험했다. PoC(Proof of Concept)를 해보는 것도 좋다. Technical Debt을 갚는 일도 천천히 진행해 보자. 정리해 보면 개발 스케쥴의 크리티컬 패스에 놓이지 않은 일이라면 무엇이든 괜찮다.
AI-assisted software development(AI 보조 소프트웨어 개발)이 점점 더 발전하면서 매니징 경험이 AI를 보조 도구로 사용하는 데 도움이 되고 있다. 특히 모호한 일을 명확한 일로 가공해서 팀원에게 나눠주는 일이 도움이 된다. 미래에는 모두가 팀장 역할을 해야 하지 않을까? 모든 팀원이 AI 에이전트를 몇 개씩 굴릴지도 모르니 말이다.
경력에 걸맞는 시야를 가져야 하고 기여를 해야 한다
매니징을 하는 건 골치 아픈 일이고 피할 수 있으면 좋다는 얘기를 예전에 업계 선배에게 들은 적이 있다. 정말 개인에게 좋은 것일까?
경력에 따라 팀 퍼포먼스에 더하기 또는 곱하기를 한다. 목표가 잘 정리된 일을 빠르고 정확하게 하는 일은 더하기다. 모호한 문제를 풀 수 있는 문제를 재정의할 수 있는 순간부터 곱하기를 하기 시작한다.
자신이 곱하기 영향력을 끼친다고 자각한 순간부터는 돋보기를 들고 코드 한 줄에 집중하기보단 높은 곳으로 올라가 코드 전체를 보기 시작해야 한다. 중요한 일은 직접 처리하지만 목표와 수단이 명확한 일은 매니저와 상의해서 다른 사람에게 넘기는 일을 시작해야 한다.
퍼포먼스 뿐만 아니라 문화에도 곱하기 역할을 한다. 시니어의 나쁜 업무 태도는 팀 전체에 강한 디버프를 걸게 한다. 실력이 엄청 뛰어나면 감수할 수 있지 않을까? 그런 경우를 겪으면 한 번 생각이 정리될 것 같다. 나는 나쁜 업무 태도를 커버할 만큼 출중한 실력을 갖춘 사람을 아직 한 명도 보지 못했다.
나는 어떤 기여를 해야 하는 걸까? 매니저에게 상담하기에도 좋은 주제다. 한 번쯤은 물어보자.
순수 엔지니어가 아니라 게임 프로그래머
프로그래머로서 기본 역량이 중요하다. 이건 프로그래머라는 직업을 갖는 데 필요한 기본 소양이다. 새로운 기술을 따라가기도 바쁘지만 여기에서 끝나지 않는다. 도메인 지식 또한 필요하다.
게임 개발에 관심이 아주 많고 도메인 지식도 풍부하지만 프로그래밍 실력이 형편없는 프로그래머. 프로그래밍 실력은 출중하지만 게임에는 아예 관심이 없는 게임 프로그래머. 각자 적절한 균형점을 찾아야 한다. 모두 다 자기 역량을 발휘할 수 있는 적절한 위치가 있지만 기본적인 도메인 지식은 꼭 필요하다.
왜 기본적인 도메인 지식이 필요한가? 순수 엔지니어로 가는 걸 막아준다고 생각하기 때문이다. 문제 해결에 더 집중하고 비즈니스 퍼스트로 생각해야 하기 때문이다. 더 나아가 PD에게 게임 프로그래머가 줄 수 있는 옵션도 제공할 수 있기 때문이다. 예를 들면 어떤 게임 영상을 최근에 봤는데 R&D를 해보니 우리도 가능할 것 같다는 프로그래머가 먼저 줄 수 있는 그런 옵션들이다.
도메인 지식은 게임을 많이 해보면서 쌓는다. 컨텐츠를 구성하는 트렌드를 봐야 한다. 다른 게임과 구별 짓는 엣지(edge)를 어떻게 만들어 내는지도 배운다. 어디까지 해야 할까? 프로그래밍 공부에도 벅찬데 게임 트랜드까지 따라가야 한다. 어디까지 따라갈 수 있을까? 답은 없다. 답이 없다고 아무런 생각을 안 해도 되는 건 아니다. 답이 여러 개이니 자신의 답을 찾아야 한다.
나는 식사 자리나 회의 자리에서 소재가 되는 게임을 따라 해 보겠다고 생각했다가 포기한 적이 있었다. 게임 디자이너가 게임하는 양을 보니 도저히 따라가지 못하겠다. 내가 게임에 할애할 수 있는 시간이 초라해 보인다. 내가 내린 절충안은 레퍼런스 게임 플레이다. 레퍼런스 게임부터 다 해보고 시간이 더 확보되면 트렌드를 주도하는 게임을 해본다.
미워하지 말고 기대치를 낮춰라
판단하지 말고 호기심을 가져라 - 월트 휘트먼 via 테드 래소 시즌 1 (Apple TV+, 2020)
엄청난 말이다. 이내 시큰둥해진다. 이렇게 할 수 있는 사람이 과연 있기나 한 것일까?
따뜻한 차를 옆에 두고 말을 곱씹어본다. 기대하지 말라는 말과도 통하는 것 같다. 판단하려면 기대가 있어야 한다. 내 기대에 얼마나 부응하는지 못 미치는지를 판단하는 것이다.
일을 못 한다고 미워할 필요가 있을까? 모두 자신의 정글에서 열심히 살고 있다. 기대를 너무 해서 미워하게 되는 것이다. 어떤 기대를 하는지 명료하게 글로 옮기지 못할 정도로 추상적이고 감정에 따라 바뀐다. 이런 기대에 부응하는 사람은 애초에 존재하지 않는지도 모른다.
미워하지 말고 기대를 낮춰라. 어쩌면 호기심이 생길지도 모르겠다.
변화를 일으키고자 하는 열정의 상한선
“내가 이렇게까지 해야 하는가?”
열심히 일하다 보면 이런 생각이 들 수 있다. 더 많은 시간을 프로젝트에 쏟는 것이 꼭 헌신이 아니다. 똑같은 시간을 일하더라도 더 많은 관심의 에너지를 쏟을 때도 헌신이 필요하다고 생각한다. 내가 생각하는 대로 바꾸면 더 효율적으로 게임을 만들 수 있다고 생각하는 데 적극적으로 따라주지 않는다. 이런 걸 게임에 넣으면 정말 재미있을 텐데 디자인팀에서는 별 반응이 없다. 모두 게임을 많이 하지 않는다고 허공에 대고 모두를 비난한다.
“모르겠고 그냥 남들이 하는 만큼만 해야겠다”
아무도 모르게 삐지게 된다. 어느 순간부터는 다른 열정적인 멤버의 장애물이 된다. 삐진 걸 드러내고 싶어 한다. “내가 예전에 얘기했는데”를 달고 살며 변화를 시키고자 하는 사람들의 의욕을 꺾는 일을 하게 된다.
상한선이 있는 것 같다. 남을 원망하지 않는 한도 내에서 지속적으로 변화를 일으키고자 하는 열정이 꺾이지 않는 한도 내에서만 한다. 현재 내가 내린 답은 ’한걸음의 힘’이다. 변화의 시작은 사소하며 그렇게 혼자서 계단을 쌓아가다 보면 자연스럽게 설득이 돼서 같이 계단을 쌓는 동료가 생기게 된다.
한 번에 거대한 변화를 동료에게 쌓은 믿음의 마일리지 하나도 없이 시도했다가 실패해서 삐지지 않아야 한다. 다른 동료의 열정을 꺾지 않아야 한다. 자신이 가지고 있는 열정의 상한선을 기억하자.
라이브 프로젝트 경험을 쌓아라
주니어로 신규 프로젝트에 참여해서 런칭하고 라이브 경험까지 쌓는 게 베스트다. 하지만 게임 런칭이란 내가 통제할 수 없는 것들에 좌지우지되는 게 많아서 운도 따라줘야 한다. 그래서 주니어일 때, 라이브 중인 게임에 입사 지원하는 게 좋지 않을까 생각한다.
라이브 개발팀에 들어가면 기획부터 시작해 유저에게 배포해서 피드백을 받는 전체 프로세스를 경험할 수 있다. 단계마다 배우는 게 다르다. 게임 컨셉을 증명해야 하는 프리프로덕션 단계에서는 기술적으로 모호한 것들을 해결해야 한다. 컨텐츠 대량 생산을 하는 프로덕션 단계에서는 프리프로덕션 단계에서 미처 준비하지 못했던 생산성에 집중해야 하며 대량 생산에 맞지 않은 구조를 발견하고 고쳐야 한다. 라이브 단계에서는 앞에서 한 잘못된 결정에 대해 대처해야 하며 달리는 차 안에서 차 바퀴를 서서히 교체해야 한다. 이런 일련의 경험을 반복해서 차례로 하면 좋겠지만 거듭 말하는바 런칭은 힘들다.
그래서 마지막 단계라고 볼 수 있는 라이브 서비스 단계를 주니어 때 경험하면 좋지 않을까 생각한다. 내 첫 프로젝트는 프로덕션 단계까지 가지 못하고 종료했다. 종료 후 라이브 서비스 중인 프로젝트로 이동했다. 내 코드가 QA를 통과하고 유저에게 배포되는 것까지 경험하니 시야가 넓어진 느낌이었다. 이전에 잘못한 결정으로 고통받으며 다음 게임에서는 어떻게 코드를 짜야 할지 영감도 얻었다. 첫 프로젝트에서 좋은 사람들을 많이 만나서 후회는 없지만 주니어일 때 라이브 서비스를 하는 프로젝트에 들어갔으면 어땠을까 생각하게 됐다.
홈그라운드를 넓힐 수 있는 도구를 벼리자
홈그라운드 역할을 할 수 있는 에디터를 하나 선택해서 꾸준히 사용하며 익혔던 게 도움이 됐다. 이왕이면 고인 물이 많은 도구를 선택하는 게 좋다. 내가 앞서가지 못하더라도 고인 물이 앞서서 뛰어가며 내 멱살을 잡아서 끌어주기 때문이다. AI를 붙인 에디터가 많이 나오네. 이렇게 감탄만 하고 있다 보면 내가 쓰는 에디터에도 관련 패키지가 추가된다. 이 글을 쓰는 지금 Visual Studio Code가 다 싸잡아 먹고 있기 때문에 이걸 선택하는 것도 좋을 것 같다. 하지만 평생 주력으로 삼을 에디터 하나만 선택하고 싶다면 Emacs나 Vim을 추천한다.
확장이 쉬워야 한다. 주력 에디터로는 Visual Studio 밖에 없던 시절 내 입맛에 맞는 플러그인 하나 만들기가 왜 그리 어려웠던지 용두사미로 끝나곤 했다. 열정이 부족한 탓도 있겠지만 간단한 기능도 손쉽게 확장 기능으로 넣지 못하는 에디터 설계 자체에도 문제가 있었다. Emacs는 다르다. 내 입맛에 맞게 함수도 추가하고 패키지도 수정하며 점점 더 내 수족이 되어가고 있다. Emacs가 아니더라도 이런 에디터를 골라야 한다.
IDE로는 JetBrains Rider나 Visual Studio를 사용하더라도 에디터 하나쯤은 오래 사용할 걸 하나 선택해서 공부해 보는 걸 추천한다. AI 시대에 더욱더 글을 쓰고 편집하고 확인하는 게 중요해지고 있다. IDE 말고 잘 다루는 에디터 하나 배워서 손해 볼 게 없다.
스터디에 참여하라
’아꿈사’와 ’Shader Study’ 모임에 꾸준히 나갔었다. 발표 준비를 하면서 평소 공부하는 것보다 더 완성도를 높이는 경험도 하게 된다. 그러면서 더 배움의 너비와 깊이를 더할 수 있다. 작은 인원이지만 여러 사람 앞에서 발표하는 경험을 많이 할 수 있다. 게임 개발뿐만 아니라 다른 도메인을 가진 프로그래머를 만나 같이 공부하며 연결된 경험을 나누며 영감을 얻을 수 있다.
가장 도움이 되는 건 뭐였을까? 자극이다. 쉬고 싶은 개인 시간 중 일부를 할당해 공부하고 스터디 모임에 나오는 사람들이다. 새로운 시각을 배우고 열심히 사는 모습에 자극받는다. 다양한 경험에서 많은 영감도 얻는다.
풀파티를 구성하다 보니 이런 모임에 할당할 수 있는 시간의 틈을 찾기가 힘들다. 하지만 애들이 좀 커서 힘든 구간이 지났으니 다시 평일에 열리는 스터디 모임을 찾아보고 싶다.
과거 프로젝트 멤버와의 연결 고리
간만에 연락하면 이직 상담인 줄 알까 봐 단순 안부 인사라는 걸 알리곤 한다. 과거에 참여했던 프로젝트를 돌이켜보면 좋은 멤버들이 많았는데, 연락이 많이 끊겼다. 메신저 친구로는 남아있지만, 안부를 나는 뒤 이어갈 화제가 마땅치 않다.
업계 소식이나 트렌드에 대한 얘기를 나누지 않더라도 각자의 정글에서 살아남고 있는 무용담을 서로 나누며 위로받는 것만으로도 정신 건강에 도움이 된다.
그래도 지금은 꾸준히 술자리나 점심 식사 자리를 만들고 있다. 과거에 같이 게임을 만들던 좋은 사람이 많았는데, 연락이 많이 끊겨서 아쉽다.
다음 10년을 생각하며
요즘은 경력 지속가능성에 대해 많은 생각을 하게 된다. 큰돈을 벌어서 은퇴하게 된다면 어떤 걸 하게 될까? 결국 뭔가를 만들 것이다. 시간을 온전히 내가 소유한다는 게 달라질 뿐이다. 은퇴는 요원하고 이래 되나 저래 되나 뭔가를 만드는 걸 계속할 텐데, 이왕이면 더 뿌듯한 걸 만들고 싶다.
이제는 매니저급이 아니면 이직하기 힘들어지는 경력이 됐다. 위에 선배들이 많은 큰 회사에 들어가면 매니징을 하지 않을 수 있을까? 그렇게 실무로 입사한다고 해도 매니저를 할 수 있는 인력으로 분류돼서 조직개편이든 차기 신작이든 결국 매니저를 맡게 될 것이다. 매니저를 하면서도 일정 비율을 프로그래밍에 할당할 수 있는 잘 굴러가는 시스템을 만드는 능력을 길러야 한다. 크리티컬 패스에 놓여있지 않은 업무에도 재미있는 게 많아서 다행이다.
다시 코로나19처럼 재택 업무가 가능해질까? 코로나19 전후로 업무 환경이 많이 바뀔 것으로 예상했지만 몇몇 회사를 빼놓고는 출근을 강제한다. 재택근무를 하면 일을 안 하고 논다고? 일과 일상이 구분을 잘 못해서 하루 종일 일을 하는 것 같았다. 오히려 일상을 지키려고 노력했던 것 같다. 업무와 일상을 분리하는 게 자리를 잡아갈 때즘 재택근무가 끝나서 아쉽다. 재택근무 좋았는데. 재택근무에 대한 미련이 아직 남아있다. 기회가 오기 전까지는 비동기(asynchronous)로 일하는 방법을 강화하며 기다릴 것 같다. 동기(synchronous)로 일하는 건 모두가 할 수 있다. 비동기로 일하는 게 어렵다. 하지만 효율적이다. 출근 근무를 하더라도 효율적이다.
이제는 AI라는 단어가 어떤 문장에 들어가도 더 그럴듯하고 더 나아질 것 같은 시대다. AI가 텍스트를 다루는 프로그래머에게 가장 먼저 스며드는 게 당연하다. 텍스트는 AI가 다룰 수 있는 primitive이기 때문이다. GitHub Copilot 같은 AI 보조 도구는 써야 한다와 안 써야 한다로 토론하는 시기는 지났다고 생각한다. 어떤 보조 도구가 괜찮은지. 어떻게 사용하면 더 효율적으로 사용할 수 있는지. 잘 쓰는 방법을 궁리해야 할 단계이다.
AI 위임은 허들을 하나씩 넘으며 현실로 다가오고 있다. AI 보조 도구처럼 당연시되는 날이 올지도 모른다. 근본은 달라지지 않는다. 문제 해결을 위한 도구만 달라지는 것이다. 뒤처지지 않고 AI 보조 도구 및 위임 같은 걸 부지런히 따라갈 계획이다. 너무 빠르지도 않고 너무 느리지도 않게 속도를 잘 조절하고 싶다. 시장을 지배하는 유력한 프로그램이 나올 때쯤이 아닐까? 여러 제품을 사용해 보며 평가할 만큼 시간이 많지 않다. 시장을 지배하는 제품이 나오면 그걸 사용한다. 초기 제품 평가에 웬만하면 시간을 쓰지 말고 큐레이션을 적극 활용한다. AI 도구에 잡아먹히지 않고 실용적으로 사용하려는 내 절충안이다.
마치며
자부심이든 후회든 적을 게 있어서 다행이다. 누군가에겐 자극을 누군가에겐 위로를 줬다면 충분하다. 다음 10년이 기대된다.
]]>
