신입교육은 조직의 문화나 시스템에 따라 다르게 진행된다. 그러나 공통으로 추구하는 건 같다. 그렇기에 교육에는 수많은 방법론이 존재한다.
넥슨코리아 데브캣 서버엔진팀의 홍성우는 신입 프로그래머를 위해 사용하는 여러 교육 방법을 소개했다. 단순 신입 프로그래머뿐만 아니라, 재교육이 필요한 경력직 교육을, 조직문화를 이어갈 수 있는 관리자 육성차원에서 설명했다.
왜 회사가 프로그래머를 가르쳐야 하는가
프로그래머는 게임의 기획과 아트 어셋을 꿰어 제품으로 완성하는 일종의 최종관문이다. 즉 프래그래머의 역량, 기술 수준이 낮다면 게임 전체의 구현과 서비스 품질이 떨어질 수밖에 없다. 그러므로 프로그래머의 역량을 잘 관리해야 한다.
혹자는 왜 회사에서 배우느냐고 물어보고는 한다. 물론 관련 전공자라면 공유하는 지식 기반, 이를테면 언어, 자료구조, 알고리즘, 네트워크 등등은 비슷할 수 있다. 그러나 실무는 학교와 다르게 품질 기준이나 업무를 보는 관점이 크게 다르므로 회사에서 교육이 필요하다. 환경도 다르다. 평가 기준도 다르다.
5년 이상의 즉시 전력감인 경력 프로그래머도 다르지 않다. 재교육이 필요하다. 조직마다 문화와 기준이 다르기 때문이다. 이직하면 팀마다 규칙이나 정책 학습이 필요하다. 기술적으로는 메인 언어가 바뀌기도 한다. 그동안의 경험으로 낮은 품질 기준에 익숙할 수도 있다. 그러므로 조직문화를 흡수하고 눈높이를 맞추려면 재교육이 필요하다.
많은 프로그래머가 "실력 있는 동료와 함께 일하고 싶다"고 한다. 맞다. 회사에서 가장 큰 복지는 똑똑하고 실력 있는 동료란 말도 있다. 조직의 코드 품질은 프로그래머의 업무환경과 연관 있다. 만약 팀의 코드 품질이 나쁘면 깨진 기능을 복구하거나 문제를 추적하는 데 많은 시간을 할애해야만 한다. 즉 동료들이 잘해줘야 시간을 좀 더 의미 있는 일에 쓸 수 있다는 말이다. 동료의 실력은 곧 생산성과 연결된다.
어떻게 가르쳐야 하나. 코드리뷰, 설계리뷰, 아침회의
프로그래머 업무 교육 중 '코드 리뷰'는 ▲ 자기 일을 잘라서 나눠주고 ▲ 방법을 자세히 알려주고 ▲ 결과물을 확인해서 피드백을 주는 과정을 반복하며 이뤄진다.
자기 일을 잘라준다는 건 반드시 실무여야만 한다. 샘플게임을 만드는 건 아무 의미가 없다. 무엇을 하는 것인지, 어떻게 하는 것인지 알려줘야 한다. 알려주는 사람은 본인이 충분히 알고 있는 일을 시켜야 한다. 버그를 잡으라고 지시했는데 내가 모르는 걸 교육하면 교육 난이도 제어가 제대로 될 리가 없다.
일을 시킬 때는 쉬운 일을 시켜서 일을 완결 지을 수 있는 경험을 하게 하도록 하는 것이 중요하다. 신입의 능력을 테스트하는 게 아니라 완수하도록 해 결과를 확인하도록 해야 한다. 만약 같은 일을 본인이 했다면 어떤 점에서 다룰지 피드백을 줘 내 수준까지 올라올 수 있도록 해야 한다.
이런 교육 과정을 반복하다 보면 교육하는 사람과 교육받는 사람의 스타일이 점점 비슷해진다. 비슷하므로 결과를 예측할 수 있으며 신뢰할 수 있게 된다. 또한, 세부 지시가 없는 부분도 응용해서 판단할 수 있으므로 더 크고 어려운 일을 할당할 수 있다.
코드 리뷰를 통해서 팀의 규칙과 정책 그리고 규칙의 근거가 되는 원칙들을 알게 되며 이전에 몸에 배었거나 잘못 알고 있던 언어 사용 습관을 바꿀 수 있어 코드 작성 시의 함정을 회피할 수 있다. 또한, 코드 사용의 미적 감각, 논리보다는 감각이 필요한 '추상화'도 가르칠 수 있다. 전반적으로 좋은 코드를 위한 습관들을 교육할 수 있다.
피드백은 반드시 일관성이 있어야 하며 지시, 지적 사항의 근거도 명확히 설명해야 한다. 또한, 한번에 모든 규칙을 숙지할 수 없으므로 정리된 문서도 필요하다.
'방법을 자세히 알려준다'는 스스로 고민하는 폭을 점점 넓혀 간다는 의미다. 이 과정을 설계 리뷰라고 한다. 결정의 근거를 확인하고, 타당성을 검토하고, 예상되는 문제를 찾아내고 다른 의견을 제시하는 과정이다. "나라면 이렇게 했을 거예요. 왜냐하면..."을 대표적 예시로 들 수 있다.
언제까지 모든 것을 알려줄 수는 없다. 주어진 작업을 직접 설계하도록 해서 검토하여 피드백을 주는 교육이다. 피드백은 주로 질문을 이용해 준다. 이를테면 "사용자 수를 얼마나 가정했니?". "무엇을 고려했니?" 등이 있겠다. 근거 중심으로 생각할 수 있도록 유도하는 게 중요하다.
설계리뷰도 문서를 제공한다. 대부분 정책과 규칙에 관한 내용으로 조직의 노하우라고 볼 수 있다. 교육받는 사람 역시 체크리스트를 만들게 하여 고려할 가치들의 우선순위를 결정할 수 있도록 유도해야 한다. 일종의 비용 분석이다. 참고할 만한 기준 또는 과거의 나쁜 경험도 좋은 교보재다. 모든 스펙은 시간이 지남에 따라 바뀌므로 특히 라이브 게임 같은 경우는 변경 방향을 예측하는 훈련도 필요하다.
가장 중요한 것은 완성하는 과정을 경험케 하는 것이다. 설계는 '핑퐁'을 해가면서 한다. 주고받는 과정이다. 이런 과정을 배우는 게 매우 중요하다. 비슷한 수준의 프로그래머가 없으면 애초에 핑퐁을 주고 받을 수 없으므로 비슷한 수준으로 끌어올리는 교육이 필요하다.
그래서 편견과 다르게 프로그래머는 생각보다는 말을 많이 해야 하는 직군이다. 프로그래머에게 중요한 언어는 C+이나 파이선이 아니라 한국어다. 적어도 한국에서 프로그래머를 하려면 한국말을 가장 잘해야 한다.
설계 토론은 굉장히 어려운 작업이다. 눈에 보이지 않는 기계의 동작을 말로 설명하는 행위이다. 모호함을 배제하면서 명료하게 이야기할 줄 알아야 한다. 코드리뷰, 설계 리뷰 모두 말이나 글로 한다. 그래서 필요한 게 아침회의다.
문제를 공유하고 커뮤니케이션 하는 게 엔지니어링 업무의 기본이다. 대부분 회사 일이 마찬가지겠지만, 프로그래머에게는 더욱 각별하다. 물론 커뮤니케이션이 단순히 사교적인 활동을 의미하지는 않는다. 커뮤니케이션이란 문제와 해결책을 말로 주고받는 '전문' 기술이다.
아침회의는 커뮤니케이션 방법을 훈련하고 조직문화의 공감대를 만드는 도구로 사용할 수 있다. 스크럼이나 스탠드 업 미팅 같은 것이 이에 포함된다.
흔히들 "회의 매일 하면 시간 낭비 아니냐?", "이슈 트래커 쓰면 되는데 왜?"라고 한다. 데브켓 서버엔진팀의 경우 아침회의로 한 사람당 1~2분 발언을 하여 일반적으로 10분에서 길게는 20분 정도 소요한다.
일반적인 회의는 같은 팀이어도 하는 업무가 다르니까, 자기 업무와 연관 있는 게 아니면 겉핥기로 진행되는 경우가 많다. 그럼에도 이를 왜 하는 걸까. 우선 보고하고 피드백 받는 연습을 할 수 있기 때문이다. 가장 좋은 보고 방법은 어제 한 작업 같은 사실을 사실 중심으로 건조하게 요약해 보고하는 것이다.
회의에서 모르는 건 모른다고 이야기 해야 한다. 사람들은 모른다는 이야기를 하기 힘들어하는데, 이런 대화가 이뤄지지 않으면 대화가 빙빙 돌거나 전달이 되지 않는다. 더 중요한 건 모른다는 사실을 비난하지 말아야 한다는 것이다. 모른다는 말에 평가하기 시작하면 모른다는 사실을 숨기고 질문하는 걸 부끄럽게 여기는 문화가 생긴다. 심지어 답을 알고 있는 상급자가 아니라 모르는 사람들, 이를테면 동기들끼리 모여서 물어보는 상황도 생길 수 있다. 절대적으로 조직 커뮤니케이션을 무너트리는 일이다. 절대 비난을 하지 말아야한다.
질문 방법을 훈련할 수도 있다. 사람들은 질문할 때 자신이 궁금한 걸 물어보지만, 맥락은 이야기하지 않는 경우가 많다. 그런데 아침회의 때는 어제 작업을 말하면서 맥락을 함께 언급하기 때문에 좋은 도구로 사용할 수 있다.
회의 중 논쟁하거나 조율하는 태화의 톤 등 적절한 표현도 연습할 수 있다. 회의 때 논쟁이 벌어질 수 있다. 그런데 이게 논리의 싸움이 아니라 태도나 톤 탓에 감정싸움으로 번지기도 한다. 사실 직접 회사에서 써도 되는 언어를 교육할 수는 없는 법이다. 매너와 사회화의 영역이기 때문에 직접 설명하기보다는 경험으로써, 이를테면 부적절한 표현을 쓰면 주의를 받는 모습을 보게 한다든지 하여 교육해야 한다.
이를 통해 동료들이 문제를 바라보는 관점과 접근 방식을 이해할 수 있으며 동료의 업무를 조망하고 업무의 큰 그림을 이해할 수 있다. 또한, 내가 부딪힌 문제에 대한 실마리를 제공하여 설계를 검증할 수 있게 해주며 각자 다른 일을 맡더라도 함께 협력한다는 연대감을 줄 수 있다.
"우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다"는 말이 있다. 석공들의 이야기인데, 프로그래머들도 만들어 할 게임의 모습을 그리는 데 많은 도움이 된다.
조직의 다음 관리자 후보를 키우는 것
코드리뷰, 설계리뷰, 아침회의는 공통으로 전달하는 바가 있다. 역할과 롤 모델을 전달할 수 있다. 모방을 통해 롤 모델에 가까워지려는 시도를 계속하게 된다. 또한, 개선하는 게 아니라 '개선을 확인'하게 하여 방향을 제시한다. 궁극적으로는 난이도와 영역을 점진적으로 올려서, 사수의 업무를 대체하게 하는 것이 목표다.
결국은 교육은 업무 능력을 복제하기 위한 과정이다. 업무 의견을 핑퐁 할 수 있는 사람이 많아지며 피교육자들끼리 가르치면서 증식하는 장점도 있다. 또한, 나와 비슷하게 잘하는 사람을 뽑기는 힘들지만, 나처럼 만들 수 있는 사람은 상대적으로 뽑기 쉽다는 장점도 가지고 있다.
무엇보다 배우는 사람이 성장감을 느끼면서 일할 수 있다는 점이 큰 장점이다. 성장감을 느끼면 업무 만족도가 높아지며 회사에 체류할 확률도 높아진다. 성장이 멈췄다고 생각할 때 이직하기 마련이다.
업무 리뷰의 원래 목적은 설계와 구현 품질을 개인이 아닌 조직이 관리하는 것을 위하여 존재한다. 즉, 업무 환경과 작업 결과물의 품질을 보증하기 위한 것이다. 코드리뷰, 설계리뷰, 아침회의는 동료와 함께 일하기 위한 도구다.
이런 문화를 정착시키기 위해서, 관리자와 TD는 프로세스와 문화를 리드하고 구성원을 교육해야 하며 구성원은 조직문화의 기반에서 일하고 문화를 다른 구성원에 전달하며, 조직 문화에 기여하면서 조직 내에서 입지를 만들 수 있다. 결국, 관리자와 TD는 자신의 역할을 구성원에 분산함으로써 조직 다음 관리자 후보를 키우는 것이다.
교육은 관심에서 시작한다. 힘들지는 않은지, 필요한 것은 없는지 등에 관심을 두고 유대감을 쌓아가야 한다. 나와 함께 일하고 있지만, 포섭한다는 느낌으로 긴밀하게 상호작용하며 관계를 유지해야 한다. 잘 가르쳐 놓고 나가면 조직 전체의 손해다.
간혹 교육하는 사람만 손해 아니냐는 이야기도 듣는다. 당연히 아니다. 교육은 나의 지식을 점검하고 체계화하는 효과가 있다. 가르치는 법을 배우고 업무를 지시하는 법을 익히는 과정이다.
피드백을 받는 어려움도 생각해야 한다. 피드백으로 지적만 받다 보면 힘들 수 있다. 그러므로 지적은 업무상으로만 하고 칭찬은 의식적으로 찾아서라도 해야 한다. 잘하는 부분을 발견해 의식적으로 칭찬해야 비난만 받는다는 생각을 하지 않는다.
교육 과정에 있어 '센스'와 '상식'이란 단어는 별 도움이 안 되는 단어다. 교육자가 스스로 정의할 수 없거나 일관성이 없을 때 나오는 이 단어는, 학습과 교정에 노력을 투자하지 않아도 알아서 잘 해주기를 바라는 마음이 담겨있다. 가르치지도 않았는데 잘하기를 바라거나, 제대로 설명하지도 않고 알아듣기를 원하는 거다. 본인도 잘 가르치기 힘들 걸 센스와 상식을 운운하면서 상대방의 탓으로 생각하는 건 관계를 틀어지게 한다. 업계에 유입되는 인재풀은 매우 한정적이다. 뽑은 사람을 잘 가르쳐야 한다.
desk@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
