티스토리 뷰
오늘은 많은 서버 개발자 분들이 (그리고 더 많은 다른 파트 개발자 분들이) 알고 계신데 막상 개발 플랜에 누락되는 일이 비일비재한 것들에 대해 이야기 해보고자 합니다.
많은 팀이 겪게되는 가상 시나리오를 그려보겠습니다.
--------------------------------------------------------------------------------------------
프로토타이핑이 성공적이었습니다!
개발팀이 세팅 됩니다.
개발 언어, 플랫폼, 엔진 (or 프레임워크)등을 정하게 되죠.
베이스 작업 기간으로 한달 정도 잡습니다.
컨텐츠별로 1주~2주 사이를 잡습니다.
그리고 각 컨텐츠가 다 완성되고 폴리싱 작업으로 한달 잡네요.
네. 좋습니다.
대략 컨텐츠가 8개 정도 되네요.
평이한 컨텐츠가 다수라 8주라 예상해봅시다.
베이스 작업+컨텐츠해서 3달 나왔네요.
폴리싱까지 4달이었죠?
여유 기간 포함해서 5달 질러봅니다.
오오!! 승인됐네요.
자~ 작업에 들어갑니다.
베이스 작업은 예상대로 잘 됩니다. 오히려 시간이 조금 남았네요?
작은 오차들과 예상외 변수가 있었지만 그럭저럭 개발 기간을 맞췄군요!
기능도 오류가 좀 있지만, 폴리싱 기간에 집중하면 될거 같은 양입니다.
출시 문제 없겠네요. 하하하~
… 헌데… 예상치 못한 일들이 끼어들어오기 시작합니다.
GM툴과 사용법을 달라고 하시는군요.
… 헐...꼭 해줘야할까…? 고민도 되고 반려도 하고 싶지만, 서비스를 위해 꼭 필요한 기능이죠.
갑자기 머리가 아파집니다.
우선 GM툴이 만들어질때까지, DB쿼리를 만들어 테스트를 지원합니다.
자...다른 일정을 몇개 양보받고, 시간을 쪼개고 쪼개서 GM툴을 만들어 제공합니다.
이전보다 원활한 테스트가 진행되는군요.
자 이제 출시 준비를 하려는데… 통계툴을 요청받습니다.
….-_- 더 시간을 확보할 방법도 없는데…
최소한의 기능만 볼 수 있게 끼워 넣습니다…
남기고 있는 로그가 추출하기 적절한 로그가 아니라, 로그 기록 작업을 하느라 더 시간 소모가 컸군요.
어라? 당연히 필요한 결제 기능이 없었군요?
지원 해야 될 스토어가 세종류네요…
스토어별로 처리 방식이 달라, 세번 다 따로 구현해야 되겠군요...
자 어떻게든 선택과 집중을 통해 몇몇 기능과 퀄리티를 양보하며, 필요한 백엔드 작업을 그럭저럭 마친 것 같습니다.
게임을 출시합니다.
가아아아암동~ 몇달간의 노력이 드디어 빛을 발할 때 입니다.
유저가 몰립니다. 우오오오오~~
서버를 증설합니다!
이제 서버가 50대로 구성됐습니다.
이제 점검을 할 때마다 50대에 배포 해야 되네요…
한대당 2분 잡아도 패치만 100분이군요.
다행히 우린 서버 프로그래머가 2명이니 50분 정도면 될까요?
부족한 운영툴의 기능으로, 서버 데이터 패치로 이벤트를 진행합니다.
밤이 되었습니다.
유저는 여전히 많네요. 불안불안합니다.
새벽 3시가 됐음에도 유저는 별로 줄어들지 않네요.
혹시 몰라 서버 50대를 순회하며, 오류 로그를 모니터링합니다.
헐…! 사고가 났네요. 복구 및 보상을 해줘야겠습니다.
… 점검시점에서 모든 유저에게 보상을 주자니 너무 많네요.
로그인시 아이템을 지급하는 보상 시스템을 구현합니다…
…하… 복구를 하려했더니 백업된 데이터가 부족하네요. 백업/복구 시스템을 못갖춰놨었습니다.
이대로 롤백해야 되는걸까요…?
--------------------------------------------------------------------------------------------
자… 이쯤 되면 감이 오시나요?
서버라는 포지션 자체는 당연하게도 서비스를 위해 존재합니다.
비지니스 로직이 아닌 작업이 이렇게나 많이 필요하고, 당연히 많은 시간이 필요합니다.
물론 제가 나열한 작업 중에 여러 작업이 지원 부서가 있는 회사. 혹은 퍼블리셔에서 제공되는 기능들도 많습니다.
하지만 의외로 원하는 기능들 중 빠졌거나, 기능은 제공되지만 세부적인 기능이 달라 사용할 수 없는 일도 비일 비재합니다.
혹은 원하는 기능이 모두 있는 서비스는 비용이 비싸서 사용하기 부담스러운 경우도 생기지요.
가장 큰 문제는 이런 백엔드 작업들이 개발 초기 단계부터 일정 산정에 고려 대상이 아닐 때가 많다는 점입니다.
개발 담당자가 직접 어필하지 않으면, 백엔드 작업은 프로젝트 전체 일정 산정에 고려되지 않을 공산이 큽니다.
개발 초기 서비스 일정을 산정하셔야 되는 분들이라면, 이 글을 읽으시고 하나라도 더 떠올리시어 백엔드 작업 일정과 작업 계획도 수립하시길 바라며 마치겠습니다.
-----------------------------------------------------
컨텐츠 제외 필요 작업 요약
-----------------------------------------------------
GM툴
통계툴
로그 기록 작업
결제 기능
배포
이벤트
모니터링
보상 시스템
백업/복구 시스템
'BlahBlah' 카테고리의 다른 글
블로그 이전 (0) | 2017.01.27 |
---|---|
프로그래밍 언어 이야기 (0) | 2016.04.20 |
업무 일지 쓰는 법 (0) | 2015.12.09 |
기계식 키보드 지름!! CM STORM QUICK FIRE TK WHITE | 적축 (0) | 2013.06.14 |
명령행 프로그램에 대한 이야기 (0) | 2013.05.28 |
- Total
- Today
- Yesterday
- 디버깅
- 엘키
- 게임개발포에버
- ftp
- NDC2013
- Ruby on Rails
- 좋은 프로그래머
- 임백준
- perfmon
- SDL
- 바로가기 프로그램
- 루비 온 레일즈
- EasyExec
- 조엘 온 소프트웨어
- svn
- 멀티스레드
- 리버스 엔지니어링
- CppSQLite
- MS-SQL
- SQLite Spy
- RoR
- Rails
- TraceRoute
- 디자인 패턴
- TDD
- ruby
- EzShortcut
- 게임데브포에버
- 루비
- c언어
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |