[JAVA 개발환경설정] 1. 고려사항 2014-10-15

개발환경은 프로젝트 진행에 있어서 상당히 중요한 부분이다. 하지만 상당수의 기업은 이를 무시하는 경향이 많다.

사업기회를 놓치지 않기위해 촉박하게 프로젝트 일정을 잡기 때문에 급한 마음에 ‘구현되는게 우선이다’라는 생각으로 접근하기 때문이 아닐까 한다. 이러한 성급한 결정은 위험요소를 가지고 있다. 구성원간 개발한 소스의 충돌을 일으키기도 하며 심지어 소스를 지우기도 한다. 또한 개발자는 프로젝트의 로직을 생각하는것 말고도 신경써야하는 부분이 많아진다. 결국 촉박하게 진행된 프로젝트는 일정안에 끝나지 못하게 되며 난잡하게 구성된 결과물만 남게되어 리펙토링시 더욱 험난한 길을 가게된다. 결과적으로 기업의 입장에서는 마이너스인 것이다.

프로젝트가 원활히 진행되기 위해서는 다음사항을 고려하여 구성원간 충분히 공유하고 대화하여 최대의 효율을 낼 수 있도록 진행 되어야 한다.

무조건 이렇게 되어야 한다는 것은 아니며 필요없다고 생각하는 구성은 생략해도 된다.

1. 로컬개발환경

로컬에 웹서비스를 구성하고 개발자별 단위 테스트를 하는 것이 좋다. 이때 디비는 개발서버의 것을 사용해도 좋다.

2. SVN서버

로컬에서 개발된 소스는 팀원별로 SVN서버에 커밋하여 종합한다. 충돌이 나지 않는 것이 최선이지만 그렇게 되기는 힘들고 팀원간의 대화로 개선해 최소화 해나간다.

3. 개발서버

SVN서버에 종합된 소스를 개발서버로 옮겨 테스트 해야한다. 문제점이 발견된다면 팀원간의 회의로 해결할 수 있도록 한다.

4. 테스트서버

개발이 완료 되어 개발서버에서 문제가 없다면 별도의 테스트서버에서 QA(Quality Assurance) 를 진행해야 한다.

5. 폴더구성

프로젝트 구성원간에 동일하게 구성하는 것이 좋다. 폴더구성을 변수화 해서 다르게 갈수도 있지만 많은 폴더의 구조를 모두 변수화 하기에는 무리가 아닐까 생각한다.

6. 배포시스템

개발이 아닌 다른부분은 스크립트화 하여 신경쓰이는 일이 없도록 자동화해야 한다.

System architecture 2014-09-22

1. 사전적 정의

> 시스템이 반드시 갖추어야 할 기능적, 비기능적 사항들을 정의하는 수단으로서, 시스템의 서비스 및 기능을 정의하고, 서비스/기능영역의 경계와 참여주체를 정의하고 표현하며, 사업계획, 사업범위 설정 및 통합의 틀을 제공하는 작업

2. 실무적 관점

> 시스템 전체의 구조를 사전에 정리하고 이를 기반으로 체계적인 개발이 진행될 수 있도록 틀을 제공하는 작업으로 시스템 구성의 목적에 기반하여 기획의 요구사항을 효율적으로 반영 할 수 있도록 설계& 문서화 한다.

3. 체계적인 개발진행이 주는 이점

> 비즈니스적인 요구사항을 신속, 정확하게 시스템에 적용할 수 있다.

> 체계적으로 문서화 하게 되면 IT기업의 자산이 된다.

> 문서화 함으로써 프로젝트 참여자들끼리의 소통이 원활해 진다.

4. 설계시 필수 정의사항

> FLOW Diagram : 프로세스, 프로그램, 데이터의 요소들의 구성 및 흐름도를 작성한다.

> DATA IN / OUT : 데이터의 입출력방식/ 통신방식 / 프로토콜을 정의한다.

> DB schema : 데이터 저장에 대한 구조를 정의한다.

> Data Mapping : 서버간 통신시에 데이터를 효과적으로 맵핑시키기 위한 정의서

> API 정의서 : 클라이언트에서 서버의 api를 활용하는 방식이라면 문서화하고 공유한다.

[모바일 게임서버] 1. 시스템 설계 2014-09-05

1. 모바일 서비스

> 일반 서비스 개발과는 다르게 모바일은 고려할 사항이 많다. 서버 / 클라 측면에서 다음사항을 고려하여 프로젝트를 진행해야 한다.

- 다양한 OS에 대하여 대응해야 한다.
- 다양한 화면크기에 대응해야 한다.
- 작은 화면임을 고려하여 꼭 필요한 기능으로 화면을 구성해야 하며 사용자 이용 편의성을 최대한 고려한 직관적인 UI 설계가 필요하다.
- 전력소모를 고려해 화면 메인색상, 페이지 로딩 용량, 캐쉬 데이터 활용여부 등을 결정해야 한다.
- 이미지 로딩에 많은 시간과 데이터를 소모하지 않도록 크기, 용량, 형식을 적절히 한다.
- 이동하면서 사용이 가능 할 수 있어야 하므로 자주 끊기게 되는 상황을 고려한다.
- 아직까지 기기의 사양이 뛰어나지 못하므로 무조건 뛰어난 그래픽을 고려하기 보다는 적절한 수준의 퀄리티를 보여 주어야 한다.

2. 모바일 게임서버

> 시스템 설계는 항상 정확한 답이 없다. 아무리 잘 짜여진 architecture 라도 부족한점이 있고 이를 보완해 프로젝트 진행이 원활하도록 하는 것이 중요하다. 경험상 중요하다고 생각하는 몇가지를 적어본다.

- 응답성 향상을 위하여 서버 및 기타 서비스용 하드웨어 아키텍쳐를 반영하여 구성한다.
- 신속 정확한 서비스 개발 및 운영이 이루어질 수 있도록 배포시스템의 구성이 필요하다.
- 장애에 대비하여 시스템 이중화를 항상 고려해야 한다.
- 팀간 또는 팀원간에 원활한 커뮤니케이션을 위해 문서화 및 적극적인 회의참여를 유도한다.
- 효율적인 업무 협업이 될 수 있도록 형상관리툴을 적극 활용한다.

3. 모바일 게임서버의 일반적인 구성도

4. 디비서버

- 트래픽이 몰렸을 경우 가장 문제가 많이 발생하는 것은 디비이다. 테이블 설계시 인덱스를 잘확인하도록 해야하며 이중화하는 것을 잊지 말자.
- 관계형데이터 베이스로 작업시 유리한 점이 많지만 데이터량이 증가할경우 대응하는데 무리가 있을 수 있다. 이럴경우 NOSQL디비를 고려 하는것도 좋다.

5. 캐시서버

- 관계형데이터 베이스로 작업시 유리한 점을 그대로 활용하고 부하를 캐시서버로 분산시킬 수 있다. Redis, Memcached 등이 사용된다.
- 특히 redis의 경우 영구적인 데이터 저장 및 다양한 기능을 제공하므로 활용도가 높다.

6. 웹서버

- 로드벨런싱을 통해 여러대의 웹서버에서 부하를 분산시킨다.
- 웹서버의 경우 메모리를 많이 사용하지 않으므로 남는 메모리를 캐쉬서버의 용도로 사용할 수 있다. 이렇게 되면 서버 비용을 줄일 수 있다.

7. 채팅서버

- 게임에서 채팅이 필요할 경우 채팅 서버를 구축해야 한다. 접속자가 많아질 경우 채널을 분리해야 하고 타 채널끼리의 통신을 위해 중계서버를 두어야 한다.