O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

6.913 visualizações

Publicada em

Publicada em: Tecnologia
  • Login to see the comments

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

  1. 1. 게임 프로그래머는 어떻게 가르치나요? 넥슨코리아 데브캣스튜디오 홍성우
  2. 2. 발표자 • 데브캣스튜디오 서버엔진팀 • 2006년부터 게임 개발 • 카바티나 스토리, 버디러시, 마비노기듀얼 • 현재 프로젝트 MV 서버 담당 • NDC 2017 <내가 만든 언어로 게임 만들기> 발표 • ds5ttk@gmail.com @pb_isb
  3. 3. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  4. 4. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  5. 5. 이런 내용을 이야기 합니다 • 개발 조직이 신입 프로그래머를 교육하는 법 • 조직의 프로그래머를 관리자로 성장시키기 • 좋은 엔지니어링 문화 만들기 표지, 목차 포함 총 75 페이지. 발표 시간 50분
  6. 6. 이런 내용을 다루지 않습니다 • 게임을 만들 때 어떤 기술이 필요한가? • 뭘 공부하면 게임 프로그래머 지망에 도움 되는가? -> 이런 기술적인 내용은 다루지 않을 것 스튜디오 전체를 대상으로 발표했던 내용이어서 아무나 들어도 쉬워요 😃
  7. 7. 이런 분들에게 도움이 될 거예요 • 교육을 담당할 시니어 프로그래머 • 무엇을 배우고 어떻게 적응할지 궁금한 신입 • 조직 관리에 관심 있는 관리자 • 학교와 회사가 어떻게 다른지 궁금한 예비개발자들 (?)
  8. 8. 저는 게임 프로그래머가 아닌데요 • ‘게임’ 프로그래머가 아니어도 이런 방법 쓸 수 있고 • 게임 ‘프로그래머’가 아니어도 힌트가 될 듯 (내부 발표 때 다른 직군 분들이 많이 공감해 주셨어요)
  9. 9. 본론을 미리 살짝 • 이 발표의 원래 제목 여기에 관한 얘기를 할거 1. 무엇인지 2. 왜 하는지 3. 어떻게 하는지
  10. 10. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  11. 11. 영화에 비유해보면 • 영화 감독의 중요한 일 중 하나가 배우들의 연기 지도 • 감독의 의도를 배우들의 연기를 통해 스크린에 표현하기 때문 • 배우들의 연기를 관리하지 못하면 영화의 완성도가 떨어질 것
  12. 12. 게임에서라면? • 프로그래머는 게임의 기획과 아트 어셋을 꿰어 제품으로 완성하는 최종 관문 • 프로그래머의 역량, 기술 수준이 낮다면 게임 전체의 구현과 서비스 품질이 떨어진다 • 프로그래머의 역량을 관리해야 한다
  13. 13. 학교에서 배우는 거 아닌가요? “공부는 학교 다닐 때 해야지 왜 회사에서?” • (관련 전공이라면) 공유하는 지식 기반은 비슷 • 언어, 자료구조, 알고리즘, 네트워크, DB, OS, … • 품질 기준이나 업무를 보는 관점이 크게 다름 • 구현 품질, 유지 보수 기간, 협업, … • 평가 기준이 달라짐
  14. 14. 경력이라면 괜찮을까? “여태까지 잘 일해왔는데 교육이 필요하다구요?” • 조직마다 문화와 기준이 다름 - 팀의 규칙, 정책 학습 필요 - 메인 언어가 바뀌기도 함 (C++ -> Python 처럼) - 낮은 품질 기준에 익숙할 수 있음 (코드리뷰 경험자가 적음) • 조직 문화에 동화시키기 위한 재교육이 필요
  15. 15. 실력 있는 동료의 중요성 • 회사에서 가장 큰 복지는 똑똑하고 실력 있는 동료 • 조직의 코드 품질은 프로그래머의 업무 환경 • 팀의 코드 품질이 나쁘면 깨진 기능을 복구하거나 문제를 추적하는데 시간을 많이 쓴다 • 동료들이 잘 해줘야, 내가 좀더 의미 있는 일에 시간을 쓸 수 있음 • 동료들의 실력 ∝ 나의 생산성
  16. 16. 무엇을 가르치고 싶나요? 나의 교육 목표 1. 커뮤니케이션 하는 법 2. (동료들과 자신이 만족하는) 좋은 코드 작성 3. 조직의 노하우와 가치를 반영하는 설계 +. 조직마다 각자의 목표
  17. 17. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  18. 18. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  19. 19. 프로그래밍 업무 교육 저는 이런 방법을 사용합니다 1. 자신의 일을 잘라서 나눠주고 2. 방법을 자세히 알려주고 3. 결과물을 확인해서 피드백 이 과정을 반복!
  20. 20. 1. 자신의 일을 잘라서 나눠주고 • 실무여야 한다 • 뭘 하는 건지, 어떻게 하는 건지, 내가 충분히 알고 있는 일을 시킴 좋아 피카츄 너로 정했다! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  21. 21. 2. 방법을 자세히 알려주고 • 처음에는 아주 세세하게 • 개발 도구 셋팅, 사용법 • 코드의 어디를 봐야 하는지 • 어떤 구조로 문제를 풀면 되는지 • 어떤 스타일을 참고하면 되는지 • 충분한 정보를 제공, 질문에도 잘 답변 • 테스트가 아님 쉬운 일부터 완수하도록 돕는 것 꼬리를 잡아! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  22. 22. 3. 결과물을 확인해서 피드백 • 내가 했다면 어떤 점에서 다를지 알려줌 • 직접 한 것과 비슷해지도록 수 차례 피드백 = 이걸 코드 리뷰 라고 불러요 피카츄, 한번 더 한다 © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  23. 23. 피드백 • 피드백은 일관성 있어야 하고 지시, 지적 사항의 근거도 명확히 설명해야 • 한번에 모든 규칙을 숙지할 수 없기 때문에 정리된 문서가 필요 ©예림당
  24. 24. 피드백 예시
  25. 25. 문서 예시
  26. 26. 시간이 지날수록.. • 하다 보면 점점 비슷해짐 • 작업 결과를 예상할 수 있기 때문에 신뢰의 근거가 됨 • 세부 지시가 없는 부분도 응용해서 판단 • 더 크고 어려운 일을 할당할 수 있음
  27. 27. 코드 리뷰를 통해 배우는 것 1) 팀의 규칙과 정책 2) 규칙의 근거가 되는 원칙들 3) (언어의 어두운 면에 다가가지 않기 위한) 언어 사용 노하우 4) 코드 작성시의 함정 회피 5) 추상화 6) 좋은 코드를 위한 습관들 나이트런 © NAVER WEBTOON CORP.
  28. 28. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  29. 29. 프로그래밍 업무 교육 저는 이런 방법을 사용합니다 1. 자신의 일을 잘라서 나눠주고 2. 방법을 자세히 알려주고 3. 결과물을 확인해서 피드백 -> 스스로 고민하는 폭을 점점 넓혀 가기!!
  30. 30. 모든 걸 자세히 알려주는 대신 • 요구 사항과 제약 사항을 알려주고 작업을 직접 설계하도록 해서 검토, 피드백 “사용자 수를 얼마로 가정했나요?” “XXXX 를 고려했나요?” “이 인터페이스는 왜 이렇게 정했나요?”
  31. 31. 결정의 근거를 확인하기 • 결정의 근거를 확인하고, 타당성을 검토하고, 예상되는 문제를 찾아내고, 다른 의견을 제시해 봄 • “나라면 이렇게 했을 거예요. 왜냐하면…” = 이걸 설계 리뷰 라고 불러요
  32. 32. 피드백 예시
  33. 33. 문서 예시
  34. 34. 설계 리뷰를 통해 배우는 것 1) 문제를 볼 때 사고의 흐름, 체크 리스트 2) 가치들 간의 우선 순위 (타협할 수 있는 것과 할 수 없는 것) 3) 성능, 품질 기준의 설정과 비용 분석 (계속)
  35. 35. 설계 리뷰를 통해 배우는 것 4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계 5) 미래의 스펙, 환경 변화에 대비하는 설계
  36. 36. 설계 리뷰를 통해 배우는 것 4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계 5) 미래의 스펙, 환경 변화에 대비하는 설계 6) 설계 핑퐁을 통해 설계를 완성해 가는 과정
  37. 37. 커뮤니케이션 • 프로그래머는 생각보다 말을 많이 한다 • (통념과 달리) 기계와 일하는 직업이 아님 • 코드 리뷰, 설계 리뷰 모두 말이나 글로 하는 것 http://news.jtbc.joins.com/article/article.aspx?news_id=NB10294996
  38. 38. 커뮤니케이션 "프로그래밍은 보이지 않는 기계의 동작을 말로 설명하는 행위" • 커뮤니케이션이 단순히 사교적인 활동을 의미하지 않음 • 문제와 해결책을 말로 주고받는 것은 전문적인 기술 • 가르치고 훈련할 수 있을까? 제가 낸 버그 아닙니다
  39. 39. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  40. 40. 커뮤니케이션 • 문제를 공유하고 커뮤니케이션 하는 건 (엔지니어링) 업무의 기본 • 아침회의 : 커뮤니케이션을 훈련시키고 조직 문화의 공감대를 만드는 도구
  41. 41. 아침 회의 • 회의 매일 하는거 시간 낭비 아닌가요? • 이슈 트래커 쓰면 되지 않나요?
  42. 42. 아침 회의 • 한일, 할일, 이슈를 돌아가면서 이야기 • 한 사람당 1~2분씩 짧게 • 전체 시간은 10분, 길어지면 20분
  43. 43. 아침 회의를 통해 연습하는 것 1) 중요 내용을 사실 중심으로 건조하게 요약, 보고하기 2) 모르는 걸 모른다고 이야기하기 3) 원하는 대답을 얻기 위한 질문 방법 4) 논쟁하거나 조율하는 대화의 톤, 적절한 표현 = 사교적인 대화보다 기술적인 대화를 훈련
  44. 44. 아침 회의를 통해 얻는 것 1) 동료들이 문제를 바라보는 관점과 접근 방식 이해 2) 동료의 업무를 조망하고 업무의 큰 그림을 이해 3) 내가 부딪힌 문제에 대한 실마리, 설계 검증 4) 각자 다른 일을 맡더라도 함께 협력한다는 연대감 “우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다.” ⓒ 1997 EIICHIRO ODA.
  45. 45. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 + 정리 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  46. 46. 공통 패턴 • 역할과 롤 모델이 주어진다 • 모방을 통해 롤 모델에 가까워지려는 시도 • 피드백을 통해 개선을 확인하고 방향을 제시 • 난이도와 영역을 점진적으로 올려서, 사수의 업무를 대체 한다
  47. 47. 교육 목표: 업무 능력을 복제하자 • 나의 업무 능력을 복제하는게 목표! • 회의 들어가서 자리 비워도 업무 진행 잘됨 • 채용 할 때 편함 • 업무 의견 핑퐁 할 수 있는 사람 많아짐 • 자기들끼리 가르치면서 증식함 • 배우는 사람은 성장감 을 느끼면서 일함
  48. 48. 신입용 과제 • 책 읽기? • 샘플 게임 구현?
  49. 49. 신입용 과제 • 따로 하지 않음 = 업무의 프로토콜을 익히는게 더 중요!
  50. 50. 트윗짤
  51. 51. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  52. 52. 코드 리뷰, 설계 리뷰, 아침 회의 이제 더 이상 신입이 아닌데 교육 목적이 아니어도 계속 필요할까요?
  53. 53. 업무 리뷰의 원래 목적 설계와 구현 품질을 • 개인의 책임이 아닌 • 조직이 관리하는 것으로 업무 환경과 작업 결과물의 품질을 보증하기 위한 것!
  54. 54. 코드 리뷰, 설계 리뷰, 아침 회의 • “혼자 일하지 말고, 팀과 같이, 동료와 같이 일하는 것” 을 의미 • 회사는 개인이 아니라 조직 전체를 통해 성과를 내야 함 -> 엔지니어링 조직이 가장 효과적으로 일하는 방식 구성원 간의 시너지를 최대한 끌어내는 조직문화 ⓒ 1997 EIICHIRO ODA.
  55. 55. 문화를 정착시키려면 • 관리자, TD : 프로세스와 문화를 리드하고, 구성원을 교육 • 구성원 : 조직 문화의 기반에서 일하고, 조직 문화를 다른 구성원에 전달하고, 조직 문화에 기여하면서 조직 내에서 입지를 만듬 • 관리자, TD 의 역할을 구성원에 분산함으로써 조직의 다음 관리자 후보들을 키움
  56. 56. 그래서 예전 발표에선 • 하지만 발표는 하나
  57. 57. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  58. 58. 도움이 될까? • 제 경험을 소개
  59. 59. 배움 • 넥슨 카바티나 팀 • 온라인 MMORPG. 게임 개발 관련 지식 배움 • 첫 3개월 교육 ≫ 다른 회사 2년 6개월 경력 (교육의 중요성) • 컴퍼니100 도로시 팀 • 웹 브라우저 개발 업무 • 코드 작성 & 리뷰, 교육, 공부하는 법 배움
  60. 60. 가르침 • 컴퍼니100 버디러시 팀 • 모바일 캐주얼 RPG, 글로벌 원빌드 서비스 • 도로시, 카바티나에서 배운 걸로 신입 가르침 • 가르치는 경험, 라이브 서비스를 통해 성장 • 관리 경험을 쌓음 ⓒ Sollmo
  61. 61. 배움 + 가르침 • 데브캣 듀얼팀 서버 • 버디러시 라이브 경험이 도움 • 서버 업무 배움 • 코드 리뷰, 서비스 안정화 • 데브캣 서버엔진팀 • 듀얼팀 서버 경험 활용 • MV 서버, 실버바인 서버엔진 개발 • 코드 리뷰, 신입 교육
  62. 62. 커리어를 통해 배운 것 • 교육의 효과는 일회성이 아니라 지속성 • 이전 조직에서의 경험이 이후 프로젝트에서 지속적으로 활용됨 • 업무와 교육이 뚜렷이 분리되지 않음 • 교육을 통해 개인의 역량이 조직 전체로 전파되고 • 조직의 업무 퍼포먼스를 끌어올려야 업무가 궤도에 오름 • 그 경험을 통해 참여한 구성원들이 성장
  63. 63. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  64. 64. 1. 코드 리뷰에서는 무엇을 보나요? 1) 컨벤션, 네이밍 2) 합의된 규칙 3) 좋은 코드
  65. 65. (부록) 좋은 코드? • 클래스나 함수 설계는 충분히 추상화 되어있고, 의도를 잘 설명하는지 • 인터페이스는 충분히 정규화 되고, 직교적인지 • 해당 구현으로 의도하지 않은 사이드 이펙트가 없는지 • 로직 코드는 단순하고 불필요한 수행이 없는지 • 로직에 코너 케이스가 없는지 • 실행 성능에 복잡도 이슈가 없는지 • DB 접근이나 네트워크 접근 등에 성능 문제나 데드락을 일으키지는 않는지 • 프로그래밍 언어, 플랫폼을 잘 이해하고 효과적으로 활용하고 있는지 • 유닛테스트는 충분한 커버리지를 갖고, 지나치게 바이어스 되어있지 않은지
  66. 66. 2. 코드 리뷰를 잘 받는 요령 • 동작 확인 (필수) • 구현 전 설계 리뷰 • 구체적인 리뷰 요청 • 커밋 분리
  67. 67. 3. 교육은 관심에서 시작 • 관심 갖기 (= 눈치 보기?) • 유대감 쌓아 나가기 • 직장에서의 가장 긴밀한 상호작용 • 좋은 관계가 필수 ©에디터
  68. 68. 4. 일방적인 도움이 아님 • 나의 지식을 점검하고 체계화 하는 효과 • 나도 가르치는 법, 업무를 지시하는 법을 익히는 것 • 시행 착오를 인정하고 서로 맞춰 가기
  69. 69. 5. 피드백 받는 어려움을 이해하기 • 지적은 업무상, 칭찬은 의식적으로 • 적절한 교습법에 개인 차가 있음 • 신입 버프가 도움될 수도
  70. 70. 6. ‘센스’, ‘상식’ 을 조심 • 교육자가 스스로 정의할 수 없거나, 일관성이 없을 때 • 학습과 교정에 노력을 투자하지 않아도 알아서 잘 해주기를 바라는 마음 • 내가 잘 가르치기 힘든 걸 상대방의 탓으로 생각하는 것은 관계를 건강하게 만들지 않음 • 감각의 영역이라면 시간이 필요
  71. 71. 7. 충분한가? • 일상 업무를 잘 커버하지만 • 재난 상황의 감각을 학습시키기는 어려움 (경험이 중요) • 사건 사고 기록이 도움
  72. 72. 목차 1. 어떤 발표인가요? 2. 왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  73. 73. 모두들 채용 얘기만… • 밸브도 똑같아! • 우수한 인재를 잘 뽑는 것도 중요하지만 유입되는 인재풀은 한정적 • 새 동료를 좋은 인재로 성장시키는 것이 조직 뿐만 아니라 업계의 성장에 필요 • 밸브도 똑같아! • 우수한 인재를 잘 뽑는 것도 중요하지만 유입되는 인재풀은 한정적 • 새 동료를 좋은 인재로 성장시키는 것이 조직 뿐만 아니라 업계의 성장에 필요 http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
  74. 74. 발표만으로 이해하기는 어렵죠 경험을 통해 익히는게 가장 좋아요 저도 회사 다니면서, 일하면서 배웠어요! <채용 진행중> • 서버엔진팀 MV 서버 파트 • 넥슨 채용 사이트에서 ‘서버 엔진’을 검색하세요 • 신입/경력 무관. 클라에서 전직도 환영
  75. 75. 마무리 “한 아이를 키우려면 온 마을이 필요하다” 좋은 프로그래머도 그렇습니다. 서로를 위한 마을이 되어주세요. 감사합니다!

×