NDC 2017 둘째 날(수)

원래 2시 15분 세션부터 참석하려 하였으나 모종의 이유로 3시부터 3개의 세션밖에 참석하지 못하였습니다.

아무래도 게임 관련 세션들이 주로 분포되어있어 기술적인 내용보다는 기획, 운영 적인 내용을 기대하며 참석 하였습니다.

싱글 스레드로 서버를 만들 수 있을까?

사실 세션 전체 내용은 처음으로 파이썬을 사용하여 게임 서버를 개발하게 된 일을 리뷰하는 듯 했습니다.

하지만 발표자분은 파이썬에 전혀 노 베이스였고 8개월이란 완성기한이 있었으며 재활용 및 운영을 위해 높은 완성도가 필요한 상황.
심지어 빌드도 없어야 했고 무중단 패치에 칼퇴근까지 하는 것을 이상으로 삼았다고 합니다.

그래서 선택한게 파이썬. (무엇보다 스스로도 배우기 쉬운 언어라는걸 강조하고 있다는건 아실겁니다)

필요한건 성능이 아닌 수평 확장성. 병렬 프로그래밍이였다고 합니다.

그래서 쓰기로 한게 세션 내내 지겹도록 언급될 파이썬 라이브러리 asyncio

Event Loop 덕분에 싱글 스레드로 병행 프로그래밍이 가능했고 콜백지옥을 겪지 않도록 코루틴을 사용한다는 장점을 가졌다는,

( Event Loop? )

물론 지금의 콜백은 개선된 면이 있지만 이분이 개발하실 시점은 콜백 초창기 시절이였다고 합니다.

비동기이기 떄문에 스레드 하나로 완전한 서버로 만들 수 있다고 합니다.

서버 프로세스가 독립적으로 돌아가기에 확장이 쉽고 관리가 편하였으며, 한 프로세스가 죽어도 서버 전체가 죽지 않는 장점이 있다고 합니다.
확장하기 쉽고 관리가 편하여 코어 수 만큼 서버 프로세스를 생성하여 멀티 프로세스 서버를 구동하였다고 하였습니다.
또한 프로세스당 1 스레드가 멀티 프로세스로 돌아가기 때문에 GIL(글로벌 인터프리터 락) 방지도 가능했다고 하네요. (파이썬에서 병렬 처리가 필요할 때는 다중 스레드가 아닌 다중 프로세스로 GIL을 우회하는 방식을 사용한다  - https://namu.wiki/w/Python#s-4.1)

뒤로는 비동기로 작성한 이유에 대한 설명이였는데, 게임서버 임에도 stateless 하고 유저간 인터렉션이 적은 모바일이라는 점 덕분에 비동기로 작성했을 때 큰 문제가 없었다고 합니다. 물론 채팅과 같은 서비스는 TCP 서버를 파이썬으로 따로 개발 했다고 ...

뒤로는 asyncio 에 대한 간증의 시간이였습니다.

표준라이브러리이며, aync 한 부분에서 await 패턴을 사용하여 작성과 코드리딩에 편하다고 합니다. 또한 데코레이터를 사용하여 가독성, 코드관리향상 효과를 볼 수 있다고 하네요.

밤새지 않고 휴일출근하지 않고 일정대로 출시하기

이 세션은 필히 직접 찾아 영상으로 보시기를 권합니다. 발표자분의 입담이 장난이 아니라 지루할 틈이 없었거든요.

우선 이 세션은 우리나라의 PM 역할을 하고 있는 사람들을 포함한 일정에 쫓기는 사람들을 위한 세션입니다.

저희 회사 같은 경우는 아사나 태스크로 일정을 누구한테 관리받는 다기 보다는 내가 내 일정을 관리하되 모든 사람들에게 공유하는 느낌이지요(플랫폼만 그런가요)

그렇기 떄문에 굳이 PM 이나 PO 가 아니더라도 충분히 들을만한 가치가 있던 세션이었습니다. 어쨌든 세션 내용은 이렇습니다.

우선 밤새지않고 휴일출근하지 않고 일을 해야하는 이유에 대해 짚고 넘어갑니다.

인간의 욕구는 참으로 단순하여 과정이 있으면 결과가 있습니다. 물론 의지로 모든 것을 헤쳐나가는 경우가 있지만 더욱 큰 피로를 얻을 수 있겠죠.

밤새고 휴일출근하면 정기적으로 더 느리다. '터널비전' 을 언급하였습니다. 피로가 극에 달해서 시야가 좁아져 잘못된 판단을 해도 알 수 없게되고 최선의 판단을 못한다는 말입니다.

그리고 프로젝트가 완료 됬더라도 완료가 아니라 완료 후 버그 수정, 업데이트 등의 이슈가 있을 텐데 나쁜 효과를 준다는 것이죠.

또한 가장 공감이 됬던게 학생시절 공부를 매번 벼락치기 하다보니 시간이 많이 남아있다는 착각을 매번 받던 경험을 일하면서까지 받을 수 있다는 것입니다.

그래서 밤새지 않고 휴일 출근하지 않기 위해서 지금부터 세션 끝날 때까지 강조 될 것이, '계획을 세우자' 라는 것입니다.

당연한 말이긴 한데 당연한 만큼 해야 한다는 것입니다. 어떤 일들이 남아있는지 추적을 하기 이해 남은 일을 리스팅하여 가지고 있어야 하고 이 목록에서 남은 기간동안 해낼 수 있는 계획을 세워 실행해야 합니다. 물론 계획을 세워도 인지하지 못했던 변수가 생기지만 계획 없이 변수에 맞닥뜨리는 것 보다는 낫다는 의견입니다.

계획을 실패하면 실패를 계획하는 것이다? 라는 말이 있다고 합니다. 발표자는 이 말에 반만 동의한다고 하였는데요, 물론 언제나 최선의 의사결정을 내릴 수 없기 떄문에 실패했다면 실패한 계획이 되지만 이 실패를 통해서 성공하는 계획을 세울 수 있다면 충분히 겪어볼만한 일이라는 것입니다. 뭐 이것도 다들 하는 말이죠 실패는 성공의 어머니다.

질러야 할 때 지르기 위해서, 역시 계획을 세워야 합니다. 새로운 것을 만들어야 하는데 어렵습니다. 비용을 미리 예측하기 힘듭니다. 하지만 하지 않는다면 밋밋한 프로젝트가 됩니다.

그렇기 때문에 계획을 세울 때 새로운 것의 시도에 대한 변수를 두고 세워야 한다는 얘기 였습니다. 당연히 가능한 일정에 어쩌면 가능할지도 모를 일정까지 합산하여 계획을 세우는거죠.

우리 이대로 진짜 출시할 수 있나? 프로젝트가 길어지면 길어질 수록 스스로에게 묻게 됩니다. 이거 진짜 완성할 수 있는건가? 하다가 터지는거 아니야?

제가 처음 입사하고 진행한 '도서 사전 검증 시스템' 의 경우가 그랬습니다. 그 전에 진행한 태스크에 비해 상대적으로 오래걸렸기 때문에, 심지어 이전에는 일정에 맞추지 못하면 갈구는 사람이 있었기 때문에 갈구지도 않고 오래걸리고 있는 프로젝트에 대해 이게 진짜 중요한 프로젝트인가 꼭 완성해야 하는 것인가 에 대한 물음을 스스로에게 던졌습니다.

하지만 역시 여기서도 계획이라고 부를만한 아사나 가 있었기 때문에 완료 체크하지 못한 태스크가 저를 계속 상기시켜 줬고 결국 완성했습니다. 또한 이게 진짜 중요한 프로젝트인가? 에 대한 답변은 완성 후 도서 오픈에 걸리는 검증 시간이 굉장히 빨라졌다는 content DB 분들의 피드백으로 얻을 수 있었습니다. 말은 길었지만 결국 이런 불안감을 해소하기 위해 큰 그림을 프로젝트 진행원들에게 공유 해야 한다는 것입니다.

뒤로는 발표자가 겪은 상황들에 대해서 혹시나 같은 상황에 맞닥뜨릴 후배들을 위한 조언이였습니다.

약속. 약속을 소중히 여기고 되도록 지킬 수 있는 약속만 하되 맡은 일에 최선을 다하고 혹시나 지키지 못하게 될 것 같으면 PM 급에게 가능한 한 빨리 알리자. 쫄지말고 알리자.

아무 설명 없이 약속이 깨어지다보면 아무도 믿지 않게 된다. 라는 말에서는 이솝의 양치기소년이 생각났네요.

예측. 예측은 어렵다 하지만 해야만 한다. 예측을 해야 계획을 세울 수 있다.

예측치에 불확실성을 반영하자. 우리가 오라클도아니고 미래를 확실하게 예측할 수는 없기에 불확실한 사항에는 최대치를 고려해야 한다고 합니다.

불확실성을 길들이자. 안해본 것, 실패할 가능성이 높은 것을 일찍 배치하자.

불확실성을 줄이기 위한 작업 자체에 시간을 투자하자(이 구절에서는 유닛테스팅이 생각났습니다)

미뤄도 문제없는 일은 미루다보면 안해도 되는 경우도 있다. 라는 꼼수도 있었네요.

전체를 보고 낭비를 없애자
내 일만 보지 말고 전체 프로덕션 계획에서 내 일이 다른 일들이랑 어떤 관계가 있는지 의식하면서 일해야 한다. 다른사람이 후속 작업을 할 수 있을 정도로 완성이 되면 일단 전달하고 다시 작업한다.

이건 솔직히 저격당한 느낌 이였습니다. 제가 이런 문제로 태스크가 밀려본 경험이 있었거든요.

물론 아사나 태스크로 자신의 일정을 직접 관리하는 입장이지만 분명 같은 플랫폼에서 같이 개발하고 있기에 타인의 태스크에 의해 일정이 밀리는 일이 생기게 됩니다.

저 같은 경우는 제가 가볍게 생각했던 CP 프론트 스크립트 리팩토링이 생각보다 다른 분들에게 많은 영향을 끼치고 있었기에 다른 분들의 태스크를 이틀정도 밀리게 한 상황이 있었습니다.

그래서 이 상황을 인지하고는 당장 건드릴 수 있는 부분만 리팩토링하여 부분 완료 처리하고 MR 하였죠. 후속 작업을 할 수 있을 정도로 완성이 되면 일단 전달하고 이어서 작업한다. 라는 것입니다.

그 이후에도 여러가지 조언들이 있었습니다.

저희도 PM 역할을 하시는 분들이 있는걸로 아는데 프로젝트 전체 일정 체크를 하면서 일을 하는 느낌이 안드는 것은 내 시간을 들여서 내결과를 내는 방식으로 업계에 들어와 시작해서 번아웃되는 것이다 라는 말을 들었습니다. 크게 화이팅을 외치고 싶게 만들어준 세션이였습니다.

<리그 오브 레전드> 모바일 상점 개발 회고

작년 세션을 들었어야 이해에 도움이 됬을 세션이였습니다.

솔직히 부제는 무시하고 들어도 괜찮았을, 문서와 회의를 최대한 줄이는 방법은 얻지 못하고 개발 회고만 듣고 왔습니다 

하지만 서로 다른 직군간의 소통 문제를 한번에 이해할 수 있는 적절한 이미지는 찾아왔네요.