waymyself

[waymyself]

17, Oct, 2013

“벌써 이 년 전, 수술 이후 성공적으로 회복된 시력에 어떤 궂은 일도 행복했던 그 시절이 있었다. 벌써 시간을 지나 이 만큼 나아왔고, 문득, 부족함을 이야기하고 있다. 이미 많은 것을 더 이뤘다. 사소한 잃음에 슬퍼할 것 없어야 않겠는가.” 

- 2013년 10월의 어느날, 나의 기록으로 부터

[waymyself]

05:53

시간이 참 빠르다. 어제를 지나 오늘의 새벽이 빠르고, 이 기록을 시작한지지도 일년이 다 되어간다. 지금은, 이 기록의 시작과 함께 작업했던 게임 서버를 확장하기 위해, 지구 반대편의 퍼블리셔와 협업을 하고 있다. 시간의 흐름과. 공간의 이동과. 나 자신의 변화에 세삼스럽다

[waymyself]

토요일 저녁

집에오는 길, 한참을 돌아왔다. 사년살이 집에 들어와 서양술 한 잔 했다. 어느 덧 6월을 지나 7월을 바라보고 있다. 큰 일 치른 친구도 어서 집에 돌아올 수 있기를..

[waymyself]

'요즘 바쁘네요'는 자랑이 아니다

http://slownews.kr/38239

하루 동안 모든 활동에 관심을 기울이자. 모든 일을 ‘선택’으로 바라보고, 그것이 정말 중요한 일인지 혹은 하지 않아도 되거나 늘 하는 습관인지 적극적으로 ‘결정’하자.  (...)  이제부터는 누군가가 “요즘 어떻게 지내느냐”고 물어본다면, “바쁘다”가 아니라 “아주 좋다”고 대답하게 될 것이다. 어쩌면 잠시 멈춰서는 미소를 지어 보일 수도 있다. 당신에겐 따로 떼어낼 시간이 있기 때문이다. 그리고 그것을 계획한 사람이 당신이기 때문이다.

 "행복하게 지내고 있어요."라는 대답은  나의 하루가, 내가 선택한 일들로 내 통제 아래에 있게 만드는 것에서 부터 시작한다

[waymyself]

"BLACK IS BEAUTIFUL"

[waymyself]

가치 가설 테스트 설계 원칙 : 성공적인 프로젝트를 위한 '테스트 주도 프로젝트'

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

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

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

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

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

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

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

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

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

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

가치가 장소/시간/게임 컨텍스트에 종속 적일 수 있다. - '페르소나 맵' 유저가 플레이 하게 되는 전후 상황을 머리 속에 그리고, 그 상황에서 가설을 테스트 해 본다. 혹은 실제 유저를 가정할 전후 상황(장소, 시간, 게임 컨텍스트 등)에 있는 것처럼 매핑하여 테스트를 진행한다. (*2015.1.9 추가)

[waymyself]

2014. 10. 15 ~ 10. 31의 작업 [StressTest#4 + Performance Tuning]

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

[한일 : 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 프로젝트에 대한 내용과 기타 만남은 따로 포스트를 작성 예정

[회고]

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

Python과 Django라는 도구를 사용하여 얻은 장점을 체감 1) '성능 측정', '원인 분석', '대응(성능 개선)'에 드는 시간이 매우 짧았음 2) '측정'과 '분석'은 스크립트 언어의 특성상 빠르게 진행 3) '대응'의 경우 잘 만들어진 라이브러리들이 이미 많이 존재하기에, 잘 분석된 원인에 맞는 솔루션을 적용하여 완료 이러한 장점은 개발자 행복 원칙을 만족시키는데에 큰 도움이 되었는데, 원칙2) 빠른 피드백 을 통해 즐거움을 느낄 수 있었을 뿐 아니라, 이를 토대로  원인을 분석하고, 개선사항들을 확인, 체감하면서 원칙4) 개발자로서의 도전의식과 자부심을 모두 느낄 수 있었음

[waymyself]

2014. 10. 13~14 의 작업 [StressTest#3]

[ 한일 ]

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사에 들렀고, 생각보다 지연되었던 작업을 모두 마무리하고 일어남. 작업을 끝내고 함께 치킨을 먹는 순간에도 점심의 이야기를 이어서 즐겁고, 의미있는 대화를 할 수 있었음.

[ 회고 ] - 도움을 마무리했다는 성취감(원칙4 개발자로서의 자부심/책임감) + 관계에서 비롯된 행복을 느낌 - 스트레스 테스트를 진행하며, 결과에 다가가는 성취감(원칙4 개발자로서의 자부심/책임감 + 원칙2 빠른 피드백)을 느낌 - 지금은, 지난 하루를 회고하며 테스트 작업을 돌아보고, 오늘 할 테스트 단계 및 공유할 자료가 명확해 지는 것에서 행복함을 느낌 (원칙1 명확한 일/목표)

[waymyself]

2014.10.13의 작업 [StressTest#2]

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

가상 유저의 작업들이 모두 게임서버와 통신(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콜이 비동기 수행되고 손쉽게 큰 성능향상을 얻을 수 있었다. 베리 굳.

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

- 일정회의

- 

[waymyself]

2014.10.13

아

사는게 녹록치가 않다...

[waymyself]

2014.10.8 의 작업

- 선택들

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. O사에 도움을 주기 위해 시작했지만, 원격으로 작업을 하고 있는 지금 이 상황은 어려움이 있다.

[waymyself]

2014. 10. 8 (10.7.의 작업) [StressTest#1]

- 선택들

1, 스트레스 테스트를 위한 테스트 시나리오를 정리 2. 테스트 시나리오를 구성할 테스트 툴의 필요 기능을 정리 3. 테스트 툴을 구현할 랭기지 Python의 특성에 맞춰 구현할 수 있는 설계를 R&D  3_1 해결해야할 문제:  인터프리터의 한계로 하나의 프로세스에서 다수의 CPU프로세서를 활용할 수 없기 때문에, 다수(대량)의 가상 테스터를 구동시키는데에 어려움이 있다.  3_2 이를 해결하기 위한 방법으로     "1) gevent를 활용하여 단일 프로세스 안에서의 가상테스터의 수를 최대한 증가시키고(서버로부터의 응답을 받게되는 Response Delay에 종속적, IO Bound의 작업이므로 gevent를 통한 동시처리가 좋은 선택일 것으로 예상)"     "2) CPU코어수 만큼 프로세스를 생성하도록 process pool을 사용하여 1)의 수를 늘리고, 서로 공유해야할 테스트데이터의 경우 로컬 DB를 활용하는 것"    위 두 가지 방법으로 c++에서의 멀티스레드를 활용한 적극적인 CPU 활용과 비슷할 정도의 결과를 얻을 수 있을 것으로 기대. 이 때, 프로세스간/테스크 간 공유데이터가 한정적이기 때문에 추가 발생할 문제도 적을 것으로 기대. 4. 지난 목요일 진행한 짝프로그래밍의 연장으로, B의 클라이언트 작업을 함께 준비  4_1 지난 짝 프로그래밍에서, 구현과 빌드 후 테스트까지의 간극이 너무 길어(iOS디바이스에서 페이스북 데이터를 가져와야 했음) 작업시간이 길어졌던 것이 큰 문제점이었다. 이를 해결하기 위해, 작업의 시작에서 디바이스에서 전달되는 페이스북 데이터를 저장하고, Unity Client내에서 해당 데이터를 재현시켜주는 방식으로 디바이스 빌드 시간을 제거하였다. 준비시간이 조금 걸렸지만, 빠르게 작업을 확인하며 진행할 수 있는 기반이 되어:'빠른피드백을 토대로 작업' 충분히 만족스러운 작업이었다.  4_2 이번 짝프로그래밍에서는, 이전에 목표로 했던 바와 같이 'B의 성장의 기쁨을 조금 더 느낄 수 있기 위함'과 '함께 짝 프로그래밍을 하면서 전달한 경험의 체화 정도 확인'을 위해서, 작업에서 해야할 To Do를 함께 수도코드형식으로 기록한 후 나머지 작업을 B가 혼자 작업하는 형식으로 진행하였다. 기대했던 바와 같이, 마무리까지 잘 해결하는 모습을 볼 수 있었고, 경험의 체화 또한 만족스러운 정도가 된 것 같다. - 좋았던 점  1. 여전히 테스트 툴을 구현함에 있어, R&D를 통해 새롭게 접한 개발언어의 특징에 맞춰, 요구사항들을 탐색하며 '원칙4 : 개발자로서의 자부심과 도전...'을 지키면서 즐거움이 있었다.  2. 짝 프로그래밍의 연장으로 이전에 기대했던 바들을 확인하고, B가 혼자서 작업을 진행할 수 있는 모습으로 이어지면서 성취감이 있었다. 성취감에는 짝 프로그래밍을 토대로 목표한 바의 성취와 관계적 측면에서 B에게 기대한 바를 전해주는 것에서의 성취감이었다. - 개선할 점  1. 짝프로그래밍의 연장을 시작하기에 앞서, B가 혼자 작업을 정리하실 시간을 가지도록 기다렸는데, 그 시간 동안 어려워하는 모습을 보여(피동적인 도움 요청으로 해석) 아쉬움이 있었다. 이는 짝프로그래밍의 연장으로 조금씩 단계적으로 작업에 자신감을 부여하고, 책임감을 이전하게 될 수 있는 것으로 기대한다. 앞으로도 조금씩 의존도를 줄여가며 짝프로그래밍을 진행하고, 자신감을 실어주면서 해결될 것으로 기대해 본다.  혹은 개선이 되지 않는다면, B에게 작업을 전달함에 있어 '책임'을 느낄 수 없는 방식으로 진행한 것은 아닌가 대화를 통해 되돌아 볼 예정이다.  2. 목표로 했던 만큼의 일의 진도가 있었으나, B의 작업을 돕느라 목표한 만큼의 성취를 이루지 못하여 썩 만족스러운 하루는 아니었다. 다만, 오늘의 작업을 토대로 B의 진척을 위해 고민하는 일이 줄어들 것으로 기대해본다.

[waymyself]

2014. 10. 7

- 선택들

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에게 변화를 만들기 위해서, 이 프로젝트가 끊임 없는 추가 요구사항으로 실패하는 경험을 주지 않고는 어떠한 방법으로 해결할 수 있을지 모르겠다. 또 다시 이런 '변화'를 고민해야 하는 것은 결코 즐겁지 않다. 그냥 내버려 두고 내 할일만 하는 것이 옳은 일일까 싶기도 하다. 이 행복하지 않은 고민은 그만.

1. 변화를 만들고 싶다고 느낄 수 있게, 신경쓰지 않으면 놓칠 일들, 신경써서 공부해야 할 일들의 책임을 이 팀의 구성원들에게 분산시킬 필요가 있다. 일을 인계하였지만, 아직도 내가 처리하고 있는 일들에 대한 책임을 느낄 수 있도록, '배려'를 거두는 것이 가장 첫번째로 시도해 볼 일이다.

[waymyself]

2014. 10. 3.

전날 밤 J가 부탁한 빌드를 전달해 주지 못해, 휴일이지만 점심쯤 사무실에 들러 디버그 빌드를 J의 핸드폰에 넣어 주었다. 1) B와의 짝프로그래밍 과정이 지연되었고 2) 작업중인 내용에 버그가 있어, 중간에 릴리즈 빌드를 올릴 수 없었고 (B는 아직 git에 적응하는 중으로, 작업단위를 끊어서 커밋하는 습관을 체화하지 못하였다) 3) 빌드를 테스트 플라이트에 전달하는 일을 B에게 인계하였고 4) 퇴근 시간에 나보다 민감한 B에게 압박을 주고싶지 않았기에 5) J에게 급한 용무로 요청하지 않은 빌드라면 팀을 퇴근시키고 다음날 빌드를 전해주기로 했다.

유니티 라이센스와 빌드머신이 없어 마저 구성하지 못 했던 자동화 빌드 시스템을 구성해야 할 필요를 느낀다(팀이 느낄 수 있게 팀에게 빌드를 인계하는 과정에 있다. 다음 빌드요청이 온다면 B 혹은 A에게 그 책임을 바로 넘겨야겠다. 생각해보니 빌드를 관리하는 것은 A의 역할이니 A에게 인계해야겠다. 자동화 빌드시스템도 A에게..)

자동화 빌드 시스템을 아직 구축하지 못 한 것은 부끄럽지만, 그렇게 하기 위해 노력중이다. 한 달 전 이 팀에 합류했을 때, 버전관리 시스템조차 존재하지 않았고, 프로젝트를 파악하며 git을 팀에게 학습/변화 시키는 것이 우선이었다.

간단히 빌드를 전달해 준 뒤에는 로그서버로 활용하던 머신의 윈도우를 밀어버리고 리눅스ubuntu를 셋팅하였다. os 인스톨부터 리눅스를 사용하는 것은 처음이지만, 이후 퍼블리셔 측에 전달할 배포 가이드를 위해 직접 셋팅을 진행하였다. postgre와 ssh, 계정 권한설정 이후 python virtualenv를 사용하여 배포환경을 구분하고 있다. 일단 ssh 및 방화벽 설정을 마무리하고 좋은 날씨의 공휴일에 저녁약속을 잡고 사무실을 나왔다.

이번 하루는 또, 다른 이를 배려하느라 떠안은 일로 그리 기분이 유쾌하지만은 않은 하루였다. 더불어 배려하려 시작한 작업이 J가 당연하고 평등한 관계로 인식하고 응대해 옴에 기분이 좋지 않았다. - ‘사람을 걱정하는 것 보다 제품에 집중하는 것’, ‘순수한 열정을 가진 사람들과 함께하는 것’에 있어 ‘나를 포함하는’ 이 팀이 맞지 않다는 것을 느낀다. - ‘개발자로서의 자긍심’을 지키려 노력하고 있다. 아, 지금은 이 팀의 작업을 도와 마무리를 하고 있지만 공식적으로는 나는 이 팀의 외부인이다.

문득 쌀쌀해진 가을의 공기가 설레는 날씨다.

[waymyself]

2014. 10. 2.

B 와 짝 프로그래밍을 시도했다. REST API로 구현된 서버의 컨텐츠를 미리 더미 클라이언트 테스트로 확인 후, 실제 게임 클라이언트에 연동하는 작업을 B에게 부탁했다. API문서는 추후 함께 개선해 나가기 위해 구글 닥스의 스프레드 시트를 사용해 공유했다. URL, Request, Response의 내용과 예로만 구성했다.

서로가 막히는 부분에서 쉽게 전환할 수 있도록. 두 쌍의 키보드/마우스, 하나의 모니터로 진행했다. 현재 작업하고 있는 부분의 목적과 방법, 이유를 대화하며 진행하는 것을 기본 원칙으로 삼았다.

1) B의 코딩 스타일을 엿보고, B가 그동안 작업해둔 클라이언트 구조를 쉽게 이해할 수 있었다. 2) 리퀘스트 콜백을 작성하며 람다식의 문법과 활용을 가르쳐 줄 수 있었다. 3) 구현과 오류 해결과정에서, 유니티와 Native의 연결과 문제 검증 단계를 전달 할 수 있었다. 또한 REST API와 네트워크의 IP/PORT의 이해를 도울 수 있었다. 직접(함께) 오류를 해결하는 과정에서 전달한 내용인 만큼 B가 쉽게 체득할 것을 기대해 본다. 다음주 개선작업을 통해 B의 체득 정도를 돌아보는 것이 좋겠다. 4) 많은 작업을 하였지만, 혼자 작업하면서 성장의 기쁨을 느끼지 못 한다고 하였던 B에게 조금이나마 성장하고 있음, 변화하고 있음의 기분을 경험하게 해 주는 것을 부가 목표로 한다.

B의 업무에 도움을 주고자 시작한 짝프로그래밍이었지만, ‘관계’적 측면에서 ‘행복감’에 도움을 주었음을 경험할 수 있었다. 저녁식사쯔음 일어나는 시간에 즐거운 감정을 느낄 수 있었고, 몰입하고 있었다.

B와 작업시간이 다르고, P의 작업시간까지 종속되어, 짝프로그래밍을 시작하는데까지 소모된 시간이 많았던 점이 아쉽다.

[waymyself]

네가지 원칙 : 행복한 개발자 되기

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

분명, 문제가 있었다.

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

나는 행복하지 않았다.

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

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

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

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

< 행복한 개발자 원칙 >

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

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

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

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

나 자신의 지난 실수를 돌아볼 기회를 주신 지인에게 큰 감사함을 전하고 싶다.  꼭 행복한 얼굴로, 감사한 분들에게 보답할 수 있는 시작이 되길 바란다.