홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018

홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018

홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018 from devCAT Studio, NEXON

 홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018

1. 게임 프로그래머는 어떻게 가르치나요? 넥슨코리아 데브캣스튜디오 홍성우

2. 발표자 • 데브캣스튜디오 서버엔진팀 • 2006년부터 게임 개발 • 카바티나 스토리, 버디러시, 마비노기듀얼 • 현재 프로젝트 MV 서버 담당 • NDC 2017 <내가 만든 언어로 게임 만들기> 발표 • ds5ttk@gmail.com @pb_isb

3. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

4. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

5. 이런 내용을 이야기 합니다 • 개발 조직이 신입 프로그래머를 교육하는 법 • 조직의 프로그래머를 관리자로 성장시키기 • 좋은 엔지니어링 문화 만들기 표지, 목차 포함 총 75 페이지. 발표 시간 50분

6. 이런 내용을 다루지 않습니다 • 게임을 만들 때 어떤 기술이 필요한가? • 뭘 공부하면 게임 프로그래머 지망에 도움 되는가? -> 이런 기술적인 내용은 다루지 않을 것 스튜디오 전체를 대상으로 발표했던 내용이어서 아무나 들어도 쉬워요 😃

7. 이런 분들에게 도움이 될 거예요 • 교육을 담당할 시니어 프로그래머 • 무엇을 배우고 어떻게 적응할지 궁금한 신입 • 조직 관리에 관심 있는 관리자 • 학교와 회사가 어떻게 다른지 궁금한 예비개발자들 (?)

8. 저는 게임 프로그래머가 아닌데요 • ‘게임’ 프로그래머가 아니어도 이런 방법 쓸 수 있고 • 게임 ‘프로그래머’가 아니어도 힌트가 될 듯 (내부 발표 때 다른 직군 분들이 많이 공감해 주셨어요)

9. 본론을 미리 살짝 • 이 발표의 원래 제목 여기에 관한 얘기를 할거 1. 무엇인지 2. 왜 하는지 3. 어떻게 하는지

10. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

11. 영화에 비유해보면 • 영화 감독의 중요한 일 중 하나가 배우들의 연기 지도 • 감독의 의도를 배우들의 연기를 통해 스크린에 표현하기 때문 • 배우들의 연기를 관리하지 못하면 영화의 완성도가 떨어질 것

12. 게임에서라면? • 프로그래머는 게임의 기획과 아트 어셋을 꿰어 제품으로 완성하는 최종 관문 • 프로그래머의 역량, 기술 수준이 낮다면 게임 전체의 구현과 서비스 품질이 떨어진다 • 프로그래머의 역량을 관리해야 한다

13. 학교에서 배우는 거 아닌가요? “공부는 학교 다닐 때 해야지 왜 회사에서?” • (관련 전공이라면) 공유하는 지식 기반은 비슷 • 언어, 자료구조, 알고리즘, 네트워크, DB, OS, … • 품질 기준이나 업무를 보는 관점이 크게 다름 • 구현 품질, 유지 보수 기간, 협업, … • 평가 기준이 달라짐

14. 경력이라면 괜찮을까? “여태까지 잘 일해왔는데 교육이 필요하다구요?” • 조직마다 문화와 기준이 다름 - 팀의 규칙, 정책 학습 필요 - 메인 언어가 바뀌기도 함 (C++ -> Python 처럼) - 낮은 품질 기준에 익숙할 수 있음 (코드리뷰 경험자가 적음) • 조직 문화에 동화시키기 위한 재교육이 필요

15. 실력 있는 동료의 중요성 • 회사에서 가장 큰 복지는 똑똑하고 실력 있는 동료 • 조직의 코드 품질은 프로그래머의 업무 환경 • 팀의 코드 품질이 나쁘면 깨진 기능을 복구하거나 문제를 추적하는데 시간을 많이 쓴다 • 동료들이 잘 해줘야, 내가 좀더 의미 있는 일에 시간을 쓸 수 있음 • 동료들의 실력 ∝ 나의 생산성

16. 무엇을 가르치고 싶나요? 나의 교육 목표 1. 커뮤니케이션 하는 법 2. (동료들과 자신이 만족하는) 좋은 코드 작성 3. 조직의 노하우와 가치를 반영하는 설계 +. 조직마다 각자의 목표

17. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

18. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

19. 프로그래밍 업무 교육 저는 이런 방법을 사용합니다 1. 자신의 일을 잘라서 나눠주고 2. 방법을 자세히 알려주고 3. 결과물을 확인해서 피드백 이 과정을 반복!

20. 1. 자신의 일을 잘라서 나눠주고 • 실무여야 한다 • 뭘 하는 건지, 어떻게 하는 건지, 내가 충분히 알고 있는 일을 시킴 좋아 피카츄 너로 정했다! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972

21. 2. 방법을 자세히 알려주고 • 처음에는 아주 세세하게 • 개발 도구 셋팅, 사용법 • 코드의 어디를 봐야 하는지 • 어떤 구조로 문제를 풀면 되는지 • 어떤 스타일을 참고하면 되는지 • 충분한 정보를 제공, 질문에도 잘 답변 • 테스트가 아님 쉬운 일부터 완수하도록 돕는 것 꼬리를 잡아! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972

22. 3. 결과물을 확인해서 피드백 • 내가 했다면 어떤 점에서 다를지 알려줌 • 직접 한 것과 비슷해지도록 수 차례 피드백 = 이걸 코드 리뷰 라고 불러요 피카츄, 한번 더 한다 © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972

23. 피드백 • 피드백은 일관성 있어야 하고 지시, 지적 사항의 근거도 명확히 설명해야 • 한번에 모든 규칙을 숙지할 수 없기 때문에 정리된 문서가 필요 ©예림당

24. 피드백 예시

25. 문서 예시

26. 시간이 지날수록.. • 하다 보면 점점 비슷해짐 • 작업 결과를 예상할 수 있기 때문에 신뢰의 근거가 됨 • 세부 지시가 없는 부분도 응용해서 판단 • 더 크고 어려운 일을 할당할 수 있음

27. 코드 리뷰를 통해 배우는 것 1) 팀의 규칙과 정책 2) 규칙의 근거가 되는 원칙들 3) (언어의 어두운 면에 다가가지 않기 위한) 언어 사용 노하우 4) 코드 작성시의 함정 회피 5) 추상화 6) 좋은 코드를 위한 습관들 나이트런 © NAVER WEBTOON CORP.

28. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

29. 프로그래밍 업무 교육 저는 이런 방법을 사용합니다 1. 자신의 일을 잘라서 나눠주고 2. 방법을 자세히 알려주고 3. 결과물을 확인해서 피드백 -> 스스로 고민하는 폭을 점점 넓혀 가기!!

30. 모든 걸 자세히 알려주는 대신 • 요구 사항과 제약 사항을 알려주고 작업을 직접 설계하도록 해서 검토, 피드백 “사용자 수를 얼마로 가정했나요?” “XXXX 를 고려했나요?” “이 인터페이스는 왜 이렇게 정했나요?”

31. 결정의 근거를 확인하기 • 결정의 근거를 확인하고, 타당성을 검토하고, 예상되는 문제를 찾아내고, 다른 의견을 제시해 봄 • “나라면 이렇게 했을 거예요. 왜냐하면…” = 이걸 설계 리뷰 라고 불러요

32. 피드백 예시

33. 문서 예시

34. 설계 리뷰를 통해 배우는 것 1) 문제를 볼 때 사고의 흐름, 체크 리스트 2) 가치들 간의 우선 순위 (타협할 수 있는 것과 할 수 없는 것) 3) 성능, 품질 기준의 설정과 비용 분석 (계속)

35. 설계 리뷰를 통해 배우는 것 4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계 5) 미래의 스펙, 환경 변화에 대비하는 설계

36. 설계 리뷰를 통해 배우는 것 4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계 5) 미래의 스펙, 환경 변화에 대비하는 설계 6) 설계 핑퐁을 통해 설계를 완성해 가는 과정

37. 커뮤니케이션 • 프로그래머는 생각보다 말을 많이 한다 • (통념과 달리) 기계와 일하는 직업이 아님 • 코드 리뷰, 설계 리뷰 모두 말이나 글로 하는 것 http://news.jtbc.joins.com/article/article.aspx?news_id=NB10294996

38. 커뮤니케이션 "프로그래밍은 보이지 않는 기계의 동작을 말로 설명하는 행위" • 커뮤니케이션이 단순히 사교적인 활동을 의미하지 않음 • 문제와 해결책을 말로 주고받는 것은 전문적인 기술 • 가르치고 훈련할 수 있을까? 제가 낸 버그 아닙니다

39. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

40. 커뮤니케이션 • 문제를 공유하고 커뮤니케이션 하는 건 (엔지니어링) 업무의 기본 • 아침회의 : 커뮤니케이션을 훈련시키고 조직 문화의 공감대를 만드는 도구

41. 아침 회의 • 회의 매일 하는거 시간 낭비 아닌가요? • 이슈 트래커 쓰면 되지 않나요?

42. 아침 회의 • 한일, 할일, 이슈를 돌아가면서 이야기 • 한 사람당 1~2분씩 짧게 • 전체 시간은 10분, 길어지면 20분

43. 아침 회의를 통해 연습하는 것 1) 중요 내용을 사실 중심으로 건조하게 요약, 보고하기 2) 모르는 걸 모른다고 이야기하기 3) 원하는 대답을 얻기 위한 질문 방법 4) 논쟁하거나 조율하는 대화의 톤, 적절한 표현 = 사교적인 대화보다 기술적인 대화를 훈련

44. 아침 회의를 통해 얻는 것 1) 동료들이 문제를 바라보는 관점과 접근 방식 이해 2) 동료의 업무를 조망하고 업무의 큰 그림을 이해 3) 내가 부딪힌 문제에 대한 실마리, 설계 검증 4) 각자 다른 일을 맡더라도 함께 협력한다는 연대감 “우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다.” ⓒ 1997 EIICHIRO ODA.

45. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 + 정리 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

46. 공통 패턴 • 역할과 롤 모델이 주어진다 • 모방을 통해 롤 모델에 가까워지려는 시도 • 피드백을 통해 개선을 확인하고 방향을 제시 • 난이도와 영역을 점진적으로 올려서, 사수의 업무를 대체 한다

47. 교육 목표: 업무 능력을 복제하자 • 나의 업무 능력을 복제하는게 목표! • 회의 들어가서 자리 비워도 업무 진행 잘됨 • 채용 할 때 편함 • 업무 의견 핑퐁 할 수 있는 사람 많아짐 • 자기들끼리 가르치면서 증식함 • 배우는 사람은 성장감 을 느끼면서 일함

48. 신입용 과제 • 책 읽기? • 샘플 게임 구현?

49. 신입용 과제 • 따로 하지 않음 = 업무의 프로토콜을 익히는게 더 중요!

50. 트윗짤

51. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

52. 코드 리뷰, 설계 리뷰, 아침 회의 이제 더 이상 신입이 아닌데 교육 목적이 아니어도 계속 필요할까요?

53. 업무 리뷰의 원래 목적 설계와 구현 품질을 • 개인의 책임이 아닌 • 조직이 관리하는 것으로 업무 환경과 작업 결과물의 품질을 보증하기 위한 것!

54. 코드 리뷰, 설계 리뷰, 아침 회의 • “혼자 일하지 말고, 팀과 같이, 동료와 같이 일하는 것” 을 의미 • 회사는 개인이 아니라 조직 전체를 통해 성과를 내야 함 -> 엔지니어링 조직이 가장 효과적으로 일하는 방식 구성원 간의 시너지를 최대한 끌어내는 조직문화 ⓒ 1997 EIICHIRO ODA.

55. 문화를 정착시키려면 • 관리자, TD : 프로세스와 문화를 리드하고, 구성원을 교육 • 구성원 : 조직 문화의 기반에서 일하고, 조직 문화를 다른 구성원에 전달하고, 조직 문화에 기여하면서 조직 내에서 입지를 만듬 • 관리자, TD 의 역할을 구성원에 분산함으로써 조직의 다음 관리자 후보들을 키움

56. 그래서 예전 발표에선 • 하지만 발표는 하나

57. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

58. 도움이 될까? • 제 경험을 소개

59. 배움 • 넥슨 카바티나 팀 • 온라인 MMORPG. 게임 개발 관련 지식 배움 • 첫 3개월 교육 ≫ 다른 회사 2년 6개월 경력 (교육의 중요성) • 컴퍼니100 도로시 팀 • 웹 브라우저 개발 업무 • 코드 작성 & 리뷰, 교육, 공부하는 법 배움

60. 가르침 • 컴퍼니100 버디러시 팀 • 모바일 캐주얼 RPG, 글로벌 원빌드 서비스 • 도로시, 카바티나에서 배운 걸로 신입 가르침 • 가르치는 경험, 라이브 서비스를 통해 성장 • 관리 경험을 쌓음 ⓒ Sollmo

61. 배움 + 가르침 • 데브캣 듀얼팀 서버 • 버디러시 라이브 경험이 도움 • 서버 업무 배움 • 코드 리뷰, 서비스 안정화 • 데브캣 서버엔진팀 • 듀얼팀 서버 경험 활용 • MV 서버, 실버바인 서버엔진 개발 • 코드 리뷰, 신입 교육

62. 커리어를 통해 배운 것 • 교육의 효과는 일회성이 아니라 지속성 • 이전 조직에서의 경험이 이후 프로젝트에서 지속적으로 활용됨 • 업무와 교육이 뚜렷이 분리되지 않음 • 교육을 통해 개인의 역량이 조직 전체로 전파되고 • 조직의 업무 퍼포먼스를 끌어올려야 업무가 궤도에 오름 • 그 경험을 통해 참여한 구성원들이 성장

63. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

64. 1. 코드 리뷰에서는 무엇을 보나요? 1) 컨벤션, 네이밍 2) 합의된 규칙 3) 좋은 코드

65. (부록) 좋은 코드? • 클래스나 함수 설계는 충분히 추상화 되어있고, 의도를 잘 설명하는지 • 인터페이스는 충분히 정규화 되고, 직교적인지 • 해당 구현으로 의도하지 않은 사이드 이펙트가 없는지 • 로직 코드는 단순하고 불필요한 수행이 없는지 • 로직에 코너 케이스가 없는지 • 실행 성능에 복잡도 이슈가 없는지 • DB 접근이나 네트워크 접근 등에 성능 문제나 데드락을 일으키지는 않는지 • 프로그래밍 언어, 플랫폼을 잘 이해하고 효과적으로 활용하고 있는지 • 유닛테스트는 충분한 커버리지를 갖고, 지나치게 바이어스 되어있지 않은지

66. 2. 코드 리뷰를 잘 받는 요령 • 동작 확인 (필수) • 구현 전 설계 리뷰 • 구체적인 리뷰 요청 • 커밋 분리

67. 3. 교육은 관심에서 시작 • 관심 갖기 (= 눈치 보기?) • 유대감 쌓아 나가기 • 직장에서의 가장 긴밀한 상호작용 • 좋은 관계가 필수 ©에디터

68. 4. 일방적인 도움이 아님 • 나의 지식을 점검하고 체계화 하는 효과 • 나도 가르치는 법, 업무를 지시하는 법을 익히는 것 • 시행 착오를 인정하고 서로 맞춰 가기

69. 5. 피드백 받는 어려움을 이해하기 • 지적은 업무상, 칭찬은 의식적으로 • 적절한 교습법에 개인 차가 있음 • 신입 버프가 도움될 수도

70. 6. ‘센스’, ‘상식’ 을 조심 • 교육자가 스스로 정의할 수 없거나, 일관성이 없을 때 • 학습과 교정에 노력을 투자하지 않아도 알아서 잘 해주기를 바라는 마음 • 내가 잘 가르치기 힘든 걸 상대방의 탓으로 생각하는 것은 관계를 건강하게 만들지 않음 • 감각의 영역이라면 시간이 필요

71. 7. 충분한가? • 일상 업무를 잘 커버하지만 • 재난 상황의 감각을 학습시키기는 어려움 (경험이 중요) • 사건 사고 기록이 도움

72. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리

73. 모두들 채용 얘기만… • 밸브도 똑같아! • 우수한 인재를 잘 뽑는 것도 중요하지만 유입되는 인재풀은 한정적 • 새 동료를 좋은 인재로 성장시키는 것이 조직 뿐만 아니라 업계의 성장에 필요 • 밸브도 똑같아! • 우수한 인재를 잘 뽑는 것도 중요하지만 유입되는 인재풀은 한정적 • 새 동료를 좋은 인재로 성장시키는 것이 조직 뿐만 아니라 업계의 성장에 필요 http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf

74. 발표만으로 이해하기는 어렵죠 경험을 통해 익히는게 가장 좋아요 저도 회사 다니면서, 일하면서 배웠어요! <채용 진행중> • 서버엔진팀 MV 서버 파트 • 넥슨 채용 사이트에서 ‘서버 엔진’을 검색하세요 • 신입/경력 무관. 클라에서 전직도 환영

75. 마무리 “한 아이를 키우려면 온 마을이 필요하다” 좋은 프로그래머도 그렇습니다. 서로를 위한 마을이 되어주세요. 감사합니다!