#happy developer

혼자 개발을 시작한지도 벌써 몇 달이 지나고 있다. 프로젝트 백로그, 혹은  To Do List를 관리해야 할 필요가 있다고 생각되었고, 이를 위한 더 나은 방법을 고민해 보았다.

프로그래밍을 함에 있어 좋은 도구로 TDD가 있다면, 거시적인 관점으로 바라본 '프로젝트'에도 충분히 적용 가능한 도구가 되어줄 것이라 생각되었다. 하나의 '할 일'을 시작함에 앞서, '끝남'여부를 확인할 수 있는 테스트를 미리 설계하고 시작하는 것.

TDD에는 많은 장점이 있는데 그 중, 프로젝트 설계에서 가져오고 싶은 장점은 다음과 같다. 일의 시작에서 좋은 테스트 케이스를 만드는 것을 통해, 설계나 구현사항을 명확히 할 수 있다. 프로젝트의 시점에서도 이를 통해 '가치'를 명확히 하고 구현 이전에 가치를 검증 할 수도 있다.

아래에는 '성공하는 프로젝트'의 시작을 위해 가치를 설계하는 단계에서 꼭 포함해야할 가치 테스트(Done여부를 결정할 수 있는)를 설계하기 위해 시도해볼 몇가지 메모이다.

< 가치 가설 테스트 설계를 위한 메모 >

'가치 표현' 아래에 진짜 가치를 찾는 것이 필요하다. - 직관적으로 표현한  '가치 가설'을 한 번 더 생각해 보는 것은 의미가 있다. - 진짜 가치를 찾았을 때에 더 의미있는 테스트를 설계할 수 있다.

'가치 가설'이 복합적일 수 있고, 복합적인 가치를 쪼개어 검증할 수 있다.

가치검증을 위한 방법은 충분히(많이) 생각해 보는 것이 좋다. - 빠른 피드백(싼 비용)을 얻을 수 있는 검증방법을 택한다. - 다른 프로덕트(게임)에 비유/비교 하여 검증된 가치를 찾을 수 있다.  다른 예(게임)에서 찾은 '가치의 구현'을 토대로 더 좋은 테스트를 설계할 수 있거나, 직접 검증하지 않고 증명할 수 있다. - AB 테스트를 설계하면서 모호한 가치를 명확히 할 수 있다. 유저의 입장에서 받아들이는 가치를 다양한 각도에서 생각하고, 단순화된 가치를 만들고 있는 것(A)과 없는 것(B)의 차이를 만들 수 있음 - 다양한 방법 예 : 페이스북 마케팅, 실제 구현을 통한 테스트, AB테스트, 페이퍼 프로토타입 - 다양한 방법을 생각하다보면, 검증할 필요가 없는 것은 하지 않을 수도 있다.

가치 검증에 순서가 존재할 수 있다. 순서를 잘 만드는 것이 중요 - 예 : 랭킹이 의미있기 위해서 선행 검증되어야 하는 가치가 존재한다. '랭킹'이 주는 경쟁욕/협동욕 은 랭킹을 제외한 게임의 가치 위에서 존재한다. - 가치의 우선순위를 매기고, 그를 토대로 검증의 순서를 만드는 것은 '디렉터/기획자'가 가진 시야이자 역량.  역으로, 좋은 기획자를 증명하기 위한 방법으로 '기획한 게임의 가치 검증'을 맡겨보는 것이 좋은 테스트가 될 수 있을 것으로 기대. 우선순위로 놓은 2~3가지를 직접 테스트해보고, 객관적인 데이터를 토대로 평가할 수 있다.

검증할 필요가 없는 가치들을 걷어낼 수 있다. (비용을 낭비할 필요가 없어요)

약 이주동안, 게으름으로 미룬 작업의 회고

[한일 : FA 서버]

1. 퍼블리셔 측에서 전달받은 북미 서버 머신 3대에 게임서버를 배치하고, 스트레스 테스트를 진행

퍼블리셔측 초기 설정  처음 협업하는 단계이기에, 초기 설정은 개발사에서 진행하는 것으로 결정. ssh 접근을 통해 셋팅 및 테스트 진행하기로. 1) os버전과 서버 구성도(역할 및 개방포트 명시)를 퍼블리셔측에 전달 2) 하드웨어 방화벽 세팅 부탁 3) SSH 권한 획득

2. 초기 세팅 및 과부하 테스트

외부 망에서 과부하 테스트 진행 시 가상유저를 20~30개만 구동시켜도 접속 거부(connectoin refused) 에러 발생 : -> 네트워크 하드웨어 단에서 ddos 방어를 위해 접속을 조절하는 것으로 보여, 할당받은 서버 머신에서 테스터를 돌림(vpn 내부에서 진행)

세팅 후 테스트시 약 3~4000의 가상유저를 넘어서면 초당 처리량이 더 증가하지 못하고, DB 및 게임서버에 CPU풀로드 -> 접속 거부 에러 발생 (front-end nginx 레벨에서 처리되지 않은 리퀘스트 큐가 가득차 거절)

3. 디테일한 성능 및 병목 확인을 위해 성능평가 모듈을 추가

테스터 : 요청 리퀘스트 수 및 성공률 기록, 초당 리퀘스트 처리량 측정

테스터 핑 : 가장 자주 사용하는 리퀘스트(랭킹 확인)의 리스폰스 타임을 토대로 응답속도 주기적 측정

서버 병목 확인 : 리퀘스트 별 응답시간 측정 (평균/최대 시간)

4. 병목 확인 및 성능 개선

목표 성능은 수만의 동접(가상유저)이므로 성능 개선 시도성능 개선 시도 0 : 다양한 환경설정 

성능 개선 시도 0 : nginx / gunicorn / os 에서  네트워크/리퀘스트 큐/백업 큐 조작 : 큰 개선은 없었지만 최대치 허용을 위한 및 작업으로 생각하고 위안 삼음

성능 개선 시도 1 :  redis를 통해 유저 정보 및 랭킹 데이터 캐싱 - 테스트 결과 큰 성능향상을 얻지 못함(이유는 이후 결과에 첨부)

성능 개선 시도 2 : postgresql 커넥션 풀링 - 테스트 진행 시, 초당 처리량 한계에 달하면 DB server의 단일 postgresql 프로세스 로드는 작지만, 수없이 많은 postgresql connection 및 대응하는 프로세스가 생성되어 CPU 풀 로드. DB의 처리 량보다, connection 처리에 오버헤드가 있는 것으로 판단, DB 커넥션 풀을 통한 개선을 선택 1) django-postgrespool 적용 : 처리량 한계에 달할 때 쯤 connectoin 숫자에 변함이 없음. 옵션값을 이리저리 수정해보아도 개선 되지 않아 튜닝이나 결과 확인보다, 다른 솔루션을 사용해보기로. (gevent을 사용하는 옵션에서 구동 확인이 되지 않았다는 포스트를 확인하고, 딥 다이브는 다른 솔루션으로 해결되지 않으면 하는 것으로) 2) djorm-ext-pool 적용 : 단일 커넥션 옵션을 변경하는 것이 아닌, django app형태로 구현된 'djorm-ext-pool'을 적용해 봄. 테스트 결과 처리량이 늘어나도, 설정한 limit을 넘어서지 않고 안정적인 커넥션 풀링이 진행 됨. 커넥션 오버헤드가 줄어들면서 1만개 가량의 가상유저 구동에도 DB서버는 여유롭게 처리. 이후는 각 게임서버에서 CPU풀로드로 인해 처리량 한계 (이후 테스터틑 DB서버에 구동)

5. 기타 작업 및 결과

보안 작업 진행  - 패킷 암호화 및 기타 미뤄두었던 보안 작업 수행

최종 테스트 1) 8000개의 가상유저 구동 : 초당 208개의 리퀘스트를 안정적으로 처리.  - 게임 서버의 경우 7~80%의 점유율  - DB서버의 경우 매우 여유로운 점유율  - 게임 서버를 늘리면, 약 6~7배 정도까지 선형적인 퍼포먼스 향상을 기대    (초당 1000개 가량의 리퀘스트까지 기대 : 5만 유저 구동의 경우) 결과 기록 : http://goo.gl/A1MDn8

메모리 캐싱의 경우 도입시 큰 퍼포먼스 향상을 얻을 수 없었던 이유는 당시 병목자체가 DB의 처리량/속도가 아니었기 때문. 어느정도 개선은 있을 수 있었겠지만, 로그인 시 발생하는 DB 접근에서 수없이 많은 커넥션을 생성하게 되고, 그로인한 오버헤드가 처리량 한계를 만들고 있었음. 메모리 캐싱의 경우 더 많은 수의 유저셋이 생성되고, DB의 처리 속도에 한계가 달할때 쯤 빛을 볼 것으로 기대. + 캐시 히트를 높이기 위해, 캐싱 단위의 범위를 조금더 늘리는 추가 작업을 To Do로 남김

[한일:그 외]

 그 외 TA 프로젝트에 대한 내용과 기타 만남은 따로 포스트를 작성 예정

[회고]

북미 시차로 인한 사소한 어려움 존재 방화벽 설정에서의 사소한 커뮤니케이션 미스에도 대응 시간이 걸림

[ 한일 ]

1. 게임 서버의 과부하 테스트를 진행 및 개선 중.

테스트 변수 (가상 유저) 1) 유저수의 증가(요청 증가)  : VirtualUser 2) 유저의 행동 패턴(시나리오) 변화 : VirtualAction

테스트 변수 (서버 환경) 1) 서버 하드웨어 구성 2) 단일 서버 내 소프트웨어 구성  - wsgi 워커 수  - 어플리케이션 워커 수  - 백로그 허용량

측정 결과 1) 서버 하드웨어 CPU Load, Memory Load, Database CPU 점유율 2) 초당 처리량 (서버측) 3) 단일 요청 응답시간 (클라이언트측)

14일 새벽까지,

위 변수에 따라 상황을 재연할 수 있도록 VirtualUser와 VirtualAction, VirtualUserManager를 구현함

프로세스 간 공유 가능한 데이터 시트를 구성, 여러 단위의 프로세스가 각기 다른 집합의 VirtualUser 데이터로 500~4000 (혹은 그 이상)의 유저를 시뮬레이션

4 코어 머신에 5개의 프로세스로 나누어 대량의 유저를 시뮬레이션 함

VirtualAction은 로그인, 상태 업데이트(친구리스트), 전체 친구 스테이터스 가져오기, 새로운 기록 업데이트, 스테이지 랭킹 가져오기 로, 각 VirtualAction마다의 '주기(Period)+무작위오프셋)'마다 액션을 수행. 연관관계있는 Action은 차례로 수행

테스트 셋팅으로 구성되어있는 서버 하드웨어에서 4000개 가량의 가상 테스터가 게임 플레이를 진행하였을 때, 한계점에 달함. (CPU 풀로드 및 단일 응답시간 7초이상)

 최대치를 측정하였고, 가변 변수에 따라 테스트 시트를 만들고, 재연 및 기록 분석하는 작업을 15일(오늘) 진행할 예정  진행한 결과에 따라 릴리즈 환경의 서버 스펙을 결정하고, 테스트 결과 및 결정된 스펙을 퍼블리셔에 전달하는 것이 15일(오늘)의 목표

 이후에는 Redis를 이용해 메모리 캐시로 응답시간 향상을 예정 2. 오후의 미팅 및 O사의 iOS 런칭 빌드 완성

 O사와 지금 작업중인 N사가 서로 도움을 줄 수 있을 것 같아, 점심 쯤 만남을 주선하고 이런저런 창업자와 게임 스타트업에 대한 이야기로 즐거운 시간을 보냄.  모두 지난 일들을 회고하고, 개선을 위한 고민을 하고 있는 단계라 의미있는 대화가 이어졌고, 나 자신 또한 지난 일을 돌아보고 이야기하며 교훈을 얻을 수 있었음.  특히 기억에 남는 교훈은 '내재적 동기'가 스타트업에서 큰 힘이 되는데 서로 다른 '내제적 동기'를 하나의 목적으로 모아 팀을 만들고 앞으로 나아가게 함에 있어, '메타 개발'을 하고 잘 돌아가도록 노력하는 사람이 한 명 있어야 한다는 것에 동의 하였음  오후에는 O사에 도움을 주고 있는 iOS 런칭 빌드를 위해 O사에 들렀고, 생각보다 지연되었던 작업을 모두 마무리하고 일어남. 작업을 끝내고 함께 치킨을 먹는 순간에도 점심의 이야기를 이어서 즐겁고, 의미있는 대화를 할 수 있었음.

게임서버 과부하 테스트를 위해 유저 시뮬레이터를 작업중.

가상 유저의 작업들이 모두 게임서버와 통신(rest api)하는 일을 포함하고 잇기 때문에, IO이벤트의 비동기 처리+테스크 동시처리를 수행하여 성능향상을 꾀함. 여기서 gevent를 사용 함 . (2014.10.5일 R&D)

테스트 결과

공통변수 : 단일 파이썬 프로세스, 계정 생성 및 로그인, 10000개의 클라이언트 시뮬레이팅, python 2.7

1) default 셋팅 : 절차적 수행(동기형 IO) :  213.264689922 초

2) gevent 를 통한 IO 동시 처리 : 25.1476459503 초    * gevent 몽키패치사용

gevent 몽키패치와 조금의 수정만으로 시스템 라이브러리의 IO콜이 비동기 수행되고 손쉽게 큰 성능향상을 얻을 수 있었다. 베리 굳.

이후 작업은 클라이언트 집합을 나누어서 개별 프로세스로 너댓개를 구동시키는 것

- 일정회의

- 선택들

1. 출근하여 사무실에 들어가는 순간, B가 W가 작업하던 일의 버그 수정을 하고 있었음. B의 옆에는 J가 함께 앉아 원하는 일들을 주문하고 있었음. B의 서버 연동작업이 또다시 딜레이가 되고, 하나의 작업에 집중할 수 없는 B의 상황이 과연 괜찮을지 걱정 됨.

2. B와 J가 작업을 마무리하고, B에게 자세한 상황을 물어보니, J가 전날 밤 빌드에서 버그를 발견하였고, 해당 버그 수정을 일단 출근한 B에게 부탁한 것. 서버 연동작업보다 먼저 해당 버그를 수정하고 빌드를 준비한 것이라는 것을 알게 됨.

3. B가 온전히 본인이 계획한 작업에 몰입할 수 있는 상황이 제공되지 않고 있고, J또한 추가 개발에 대한 욕심을 버리지 못하고 B에게 밀어놓는 상황이, B의 작업에 진척을 만들 수 없을 뿐 아니라 많은 양의 버그를 발생시키고 있는 것은 아닌가 걱정 됨. 대화를 통해 B 또한 온전히 하나에 몰입하여 마무리 할 수 있는 상황을 원하는 것을 확인 함. 

4. 작업자들이 하나의 작업에 몰입할 수 있는 환경을 만들기 위해, J에게 일정회의를 요청 함.  J의 추가 개발 욕구를 유지한 채로 작업자들의 작업 우선순위를 지키는 것이 목표였는데, 이를 위해 기획자 K를 프로젝트 관리자로 제안 함. 일단 작업의 카테고리에 따라 우선순위를 정하고(소프트 런칭을 기준), J의 욕구에 따른 개발사항들을 K 에게 던져주면, K가 우선순위에 따라 작업자들에게 작업을 부탁하는 방식으로 시도해 보기로 함.  시간을 가리지 않는 추가 개발/ 버그 수정 요청으로 작업자들이 몰입에 어려움이 있고, 피로도가 높아졌다는 것을 모두 공감했고, 시도해 볼 변화에 대해서도 긍정적으로 이야기하고 일어남.

5. O사의 iOS 결제 모듈 작업을 마무리하러 들름. 서버개발자 J도 함께 와서 작업을 하였지만, 막차시간으로 먼저 일어나게 되어 사실상 소통하며 개발 진행은 어려웠음. J가 떠나고, 맥주를 한 잔하며 이런저런 이야기를 나누다 돌아 옴. 

일이 밀려 여기까지만 정리 회고는 다음에 ㅠㅠ

- 선택들

- 선택들

1. 게임 서버의 배포환경을 구성해 봄 1_1. ubuntu에 nginx 와 gunicorn wsgi를이용하여 django 인스턴스를 여러 대 구성함. supervisor를 통해 gunicorn의 구동을 설정하여, 장애시 서버 인스턴스의 구동을 자동화 함. 2. J가 게임 데이터시트를 서버로 옮겨서 실시간 업데이트를 구성해줄 수 있겠는지 조심스럽게 부탁함. 그렇게 하자 라고 이야기 했지만, 클라이언트 사이드에서 추가작업이 많아질 것 같아 보류. 3. J가 퍼블리셔로 부터 의 요청(새로운 udid로 프로비저닝한 빌드 전달)을 저녁 늦게 리마인드 해주었고, 빌드를 만들어 전달 함.

- 좋았던 점 : 원칙 4번 (개발자로서의 책임감과 도전의식, 자부심을 지킬 수 있는 일을 한다)을 지키는 행동으로 즐거움을 느낄 수 있었던 하루였다. 또한 이 일의 진행에서 원칙 2번 (빠른 피드백을 기반으로 즐거움을 느끼면서 한다 : 막연함과 계획 없는 것을 피한다)을 지키기 위한 테스트코드를 기반으로 환경 구성을 변화시키면서도 동일한 테스트의 성공여부를 확인하고, 일의 진척사항을 바로 확인할 수 있어 즐거움이 더 컸던 것 같다.

1. nginx의 셋팅 및 다수의 인스턴스로 웹 어플리케이션(django)을 구성해 보는 것은 처음이었으나, 생각보다 잘 만들어져 있는 도구들이 있어 쉽게 구성할 수 있었고, 새로운 도전들을 넘어가는 것에서 즐거움을 느낄 수 있었음. 기타 방화벽 및 postgre 권한설정 등 자잘한 장벽들도 해결한 이후의 즐거움이 있었음.  2. 잘 만들어져 있는 도구들. 특히 배포시 자동화 스크립트나 장애 대응을 위한 supervisor의 셋팅 등에서도 큰 어려움 없이, 큰 도움이 될 기능들이 눈 앞에 구현되어있다는 것과 이를 활용할 수 있다는 것이 즐거움을 주었음.

- 개선할 점 : 원칙 3번 (순수한 열정을 가진 사람들과 함께 한다.)를 지키기에는 여전히 어려움이 있다. 게임을 만들고 출시하여 결과를 보는 것 모두에 열정을 가진 사람을 동료로 찾는 것에는 어려움이 있다. 그렇기에 신경써서 점검해야 할 일든은 그 열정을 가진 소수의 사람들만이 진행하게 된다. 그렇지 않은 이들로 이미 구성된 팀에서 변화를 만드는 것은 나는 이제 하고싶지 않다. 아무튼, 오늘도 내가 밤늦게까지 앉아 빌드를 하고 있었던 것은 즐겁지 않은 경험이었다. 또한 출시 일정이 한달도 남지 않은 지금, 아직도 추가 'Feature'를 요구하는 J에게 변화를 만들기 위해서, 이 프로젝트가 끊임 없는 추가 요구사항으로 실패하는 경험을 주지 않고는 어떠한 방법으로 해결할 수 있을지 모르겠다. 또 다시 이런 '변화'를 고민해야 하는 것은 결코 즐겁지 않다. 그냥 내버려 두고 내 할일만 하는 것이 옳은 일일까 싶기도 하다. 이 행복하지 않은 고민은 그만.

주어진 일들에 책임감을 가지고, 내 자신에게 부끄럽지 않은 삶을 살았다고 생각한다. (물론 인지하지 못하고 넘어간 미안한 일들도 있었을 것이다. 혹여나 의도치않게 연루되어 마음고생했던 이들이 있다면 미안하다 전하고 싶다.) 그러한 책임감이나 열정과는 무관하게, 특히, 지난 2년 동안 개발자로서의 내 인생은 행복하지 않았다.

분명, 문제가 있었다.

개발자로서의 내 인생을 회고하지만, 지난 2년, 창업 전선에서의 생활을 삶의 전부인 것 처럼 살았기에, 개발자로서의 2년일 뿐 아니라, 지난 2년 내 인생 전반에 대한 평가이기도 하다.

나는 행복하지 않았다.

정말 치열한 생활이었다. 그나마 곁을 지켜주던 몇 안되는 친구들과도 연락하기 어려운 사이가 되버렸고, 비슷한 일을 하고 있기에, 어려울 때면 도움을 주던 이들과의 관계에서도 매번 도움만 받았기에 연락하기에 어려운 것은 매한가지가 되어버렸다. 어머니의 제사상에 제 때 술 한잔 올리지 못 했으니, 가족관계에 있어서도 할 말이 없다.

이제서 주변을 둘러보면, 남긴 것이 없다. 나는 무언가 치열하게 했고, 책임감을 다했다고 하지만, 누구도 행복하게 할 수 없었다. 심지어 나 조차도 행복하게 하지 못 했다. 무엇을 위한 책임감이었을까?

지난 실수들-치열하게 살았던 것 만큼 행복하지 못했던-를 반복하지 않기 위해서, 앞으로의 선택에서 행복한 삶을 만들기 위한 원칙을 세웠다.

물론, 이 원칙이 앞으로의 선택을 모두 행복한 선택으로 만들어줄 수는 없겠지만 적어도 같은 실수를 피해갈 수 있는 기준이 되어줄 것이라 생각한다. 어제보다 더 나은 오늘, 그리고 내일을 위한 이정표가 되어주길.

< 행복한 개발자 원칙 >

1) 사람에 대한 고민보다, 만드는 것의 가치에 집중한다 : 게임의 명확한 목표를 공유하고 그 가치에 집중할 수 있어야 한다.

2) 빠른 피드백을 기반으로 즐거움을 느끼면서 한다 : 막연함과 계획 없는 것을 피한다.

3) 순수한 열정을 가진 사람들과 함께한다.

4) 개발자로서의 책임감과 도전의식, 자부심을 지킬 수 있는 일을 한다.