KR20170072025A - 게임 서버의 운용 에스펙트 생성 방법 - Google Patents

Abstract

핵심 게임 로직과 인증/로깅/데이터베이스 처리 로직이 하나의 클래스에 혼재된 기존 소스코드에서 핵심 게임 로직만을 남길 수 있는 게임 서버의 운용 에스펙트 생성 방법을 제시한다. 제시되 방법은 운용 방법의 아티펙트(artifacs)가 되는 집합(collection), 뷰(view), 및 액션(action)을 포함하는 주석이 달린 소스를 근거로 주석 코드를 생성하는 단계, 주석 코드를 분석하여 운용 에스펙트 코드를 생성하는 단계, 주석 코드 및 운용 에스펙트 코드를 컴파일하고 엮는 단계, 및 컴파일 및 위브기에 의해 컴파일되고 엮어진 소스를 에스펙트 컴파일러를 통해 컴파일하여 운용 에스펙트 분리 서버 코드를 생성하는 단계를 포함한다.

Description

게임 서버의 운용 에스펙트 생성 방법{Method for generating operational aspect of game server}

본 발명은 게임 서버의 운용 에스펙트 생성 방법에 관한 것으로, 보다 상세하게는 핵심 게임 로직과 인증/로깅/데이터베이스 처리 로직이 하나의 클래스에 혼재된 기존 소스코드에서 핵심 게임 로직만을 남길 수 있는 게임 서버의 운용 에스펙트 생성 방법에 관한 것이다.

기술의 발달로 스마트폰, 태블릿, 스마트 TV, 스마트 와치가 주목할 만한 성장율로 증가하고 있다.

게임이 애플 앱스토어, 구글 플레이스토어의 이익에 차지하는 비중이 계속 증가하고 있다.

이렇게 수익원으로서의 게임의 중요성이 커져서, 게임을 만드는 스타트업 기업이 급격하게 증가하고 있으며, 이를 린스타트업 기업이라고 부른다. 이러한 회사들은 시장의 요구사항을 즉각 즉각 반영하여 생존을 하는 방식을 채택한다.

시장의 요구사항에 즉각적인 개발을 하기 위하여, 기존의 Waterfall 개발 방법론의 한계를 극복하고자 Spiral, Prototyping, Domain Specific Language, CoC, DRY, AOP , Agile 등 다양한 방법론 및 관련연구가 출현하고 있다.

이러한 다양한 방법론이 있지만, 기존의 방법으로는 게임 개발시에 다음과 같은 문제가 발생한다. 즉, 게임 운영시 게임 소스의 잦은 변경 및 소스 레벨에서의 실행이 요구된다. 다시 말해서, 사소한 운영에 필요한 내용이라도 잦은 소스레벨에서의 변경 및 실행이 요구되지만, 게임의 코어 로직 외에 인증, 로깅, 데이터베이스 접속 등의 소스가 혼재하여 이의 변경이 어렵다.

선행기술 1 : 미국등록특허 제8001519호(Model driven development including aspect integration tool) 선행기술 2 : 미국등록특허 제6539390호(Integrated development environment for aspect-oriented programming)

본 발명은 상기한 종래의 문제점을 해결하기 위해 제안된 것으로, 핵심 게임 로직과 인증/로깅/데이터베이스 처리 로직이 하나의 클래스에 혼재된 기존 소스코드에서 핵심 게임 로직만을 남길 수 있는 게임 서버의 운용 에스펙트 생성 방법을 제공함에 그 목적이 있다.

상기와 같은 목적을 달성하기 위하여 본 발명의 바람직한 실시양태에 따른 게임 서버의 운용 에스펙트 생성 방법은, 레거시 서버가, 운용 방법의 아티펙트(artifacs)가 되는 집합(collection), 뷰(view), 및 액션(action)을 포함하는 주석이 달린 소스를 근거로 주석 코드를 생성하는 단계; 운용 에스펙트 생성기가, 상기 주석 코드를 분석하여 운용 에스펙트 코드를 생성하는 단계; 컴파일 및 위브기가, 상기 주석 코드 및 상기 운용 에스펙트 코드를 컴파일하고 엮는 단계; 및 운용 에스펙트 서버가, 상기 컴파일 및 위브기에 의해 컴파일되고 엮어진 소스를 에스펙트 컴파일러를 통해 컴파일하여 운용 에스펙트 분리 서버 코드를 생성하는 단계;를 포함한다.

상기 운용 에스펙트 코드를 생성하는 단계는, 상기 주석 코드를 에스펙트로 매칭시키기 위한 매칭 시맨틱스를 사용하되, 상기 매칭 시맨틱스는 소스(source), 운용 컨선(operational concern), 주석(annotation), 주석 서명(annotation signature), 에스펙트(aspect), 에스펙트 서명(aspect signature), 및 매핑(mapping)에 정의가 규정될 수 있다.

상기 운용 에스펙트 분리 서버 코드를 생성하는 단계는, 상기 운용 에스펙트 분리 서버 코드를 생성할 때 운용 객체도 함께 생성할 수 있다.

상기 운용 객체는 오류(fault), 구성(configuration), 회계(accounting), 성능(performance), 및 보안(security)을 포함할 수 있고, 각각의 운용 객체의 선언(declaration) 및 포인트컷(pointcut) 방법은 상기 운용 에스펙트 생성기에 의해 자동으로 생성될 수 있다.

상기 운용 에스펙트 분리 서버 코드를 생성하는 단계 이후에, 상기 운용 에스펙트 서버가, 상기 운용 에스펙트 분리 서버 코드와 레거시 코드를 비교함으로써 가독성 및 유지보수성을 향상시킬 수 있다.

이러한 구성의 본 발명에 따르면, 핵심 게임 로직과 인증/로깅/데이터베이스 처리 로직이 하나의 클래스에 혼재된 기존 소스코드에서 핵심 게임 로직만을 남게 함으로써, 로직의 표현력을 증대시키고, 유지 보수 및 추가기능 구현을 쉽게 할 수 있다.

특히, 기존 게임 서버에도 적용하여 에스펙트가 분리/생성되게 하는 알고리즘을 제공할 수 있고, 신규 제작하는 게임 서버에도 적용가능하다.

도 1은 게임 서버의 운용을 최적화하는 방법에 채용되는 FCAPS 모델을 설명하기 위한 도면이다.
도 2는 게임 서버의 운용을 최적화하는 방법이 채용되는 서버 모델의 일 예를 설명하기 위한 도면이다.
도 3은 FCAPS 모델과 서버 모델의 매핑을 통한 운용 모델을 나타낸 도면이다.
도 4 내지 도 9는 도 3의 운용 모델에 사용된 아티펙트를 나타낸 도면들이다.
도 10은 도 3의 운용 모델을 이용한 운용 방법을 설명하는 흐름도이다.
도 11 내지 도 17은 도 10의 설명에 채용되는 도면들이다.
도 18은 일반적인 FCAPS 컨선(concerns)을 가진 서버를 구현한 예이다.
도 19는 다수의 FCAPS 컨선(concerns)으로 인해 엉켜진 소스 코드들의 예를 나타낸 도면이다.
도 20은 에스펙트 개념을 적용하여 자동으로 엮어지고 DSL을 통해 생성되는 FCAPS 에스펙트를 나타낸 도면이다.
도 21은 운용에 관한 컨선(concerns)이 제거된 후에 남아 있는 게임 코어 로직을 가진 소스 코드의 일 예이다.
도 22는 레거시 서버에 운용 에스펙트 응용에 대한 워크플로우의 개요도이다.
도 23은 주석달린 소스 코드의 일 예를 나타낸 도면이다.
도 24는 운용 에스펙트의 생성을 결정하는 알고리즘을 예시한 도면이다.
도 25는 에스펙트를 생성하는 알고리즘을 예시한 도면이다.
도 26은 레거시 서버의 에스펙트를 생성하는 방법을 삭제하는 알고리즘을 예시한 도면이다.
도 27은 운용 에스펙트 코드의 일 예를 나타낸 도면이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시 예들을 도면에 예시하고 상세하게 설명하고자 한다.

그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.

본 발명은 게임 서버의 운용을 최적화하는 방법에서 운용 에스펙트가 분리되고 생성을 통해 사라지는 단계인 운용 에스펙트 생성에 관한 것이다. 운용 에스펙트 생성은 DSL 워크플로우에서 DSL화하는 단계의 일부분이다.

먼저, 본 발명이 적용되는 게임 서버의 운용을 최적화하는 방법에 대해 설명하면 다음의 도 1 내지 도 17과 같다.

도 1은 게임 서버의 운용을 최적화하는 방법에 채용되는 FCAPS 모델을 설명하기 위한 도면이다.

FCAPS는 ISO 통신 관리 네트워크 모델 및 네트워크 관리용 프레임워크이다. FCAPS는 오류(Fault), 구성(Configuration), 회계(Accounting), 성능(Performance), 보안(Security)의 약성어이다. ISO 모델내의 FCAPS의 관리 카테고리들은 네트워크 관리 태스크들을 정의한다.

도 1에서, 오류 관리(Fault management)(1)는 통신 네트워크 및 그 환경의 이상 동작의 감지, 분리(isolation), 수정(correction)을 가능하게 하는 일련의 기능을 담당한다. 오류 관리(1)는 ITU-T M.20으로부터의 유지보수 단계의 성능에 대한 편의(facilities)를 제공한다. 오류 관리(1)를 위한 품질 보증 측정은 신뢰성(Reliability), 이용가능성(Availability) 및 생존가능성(Survivability)에 대한 구성요소 관리를 포함한다.

도 1에서, 구성 관리(Configuration management)(2)는 네트워크 장비(network equipment)에 대한 통제를 연습하는 기능, 네트워크 장비로부터 데이터를 식별 및 수집하는 기능, 및 네트워크 장비에게로 데이터를 제공하는 기능을 담당한다. 구성 관리(2)는 네트워크 계획 및 엔지니어링, 설치, 서비스 계획 및 협상, 준비 및 상태 및 제어 등의 기능 세트 그룹을 지원한다.

도 1에서, 회계 관리(Accounting management)(3)는 서비스 제공자가 네트워크 서비스의 사용 및 비용 결정이 가능하도록 하고 그런 사용을 위하여 고객에게 비용을 부과하는 것을 가능하도록 한다. 또한, 회계 관리(3)는 서비스를 위한 가격 결정을 지원한다. 회계 관리(3)는 이용 측정(usage measurement), 세율정하기(tariffing)/가격매기기(pricing), 징수(collections) 및 재정관리(finance), 및 사업 관리(enterprise control) 등의 기능 세트 그룹을 포함한다.

도 1에서, 성능 관리(Performance management)(4)는 통신 장치의 작동상태 및 네트워크 또는 네트워크 요소의 유효성에 관한 평가 및 보고의 기능을 제공한다. 다시 말해서, 성능 관리(4)는 네트워크, 네트워크 장비들(NEs) 또는 다른 장치의 작동상태 및 유효성을 감시하고 수정할 목적으로 통계적 데이터를 모으고 분석하는 것과 계획, 공급, 유지보수 및 품질관리를 지원할 수 있다. 이에 의해, 성능 관리(4)는 ITU-T M.20의 성능 관리 단계를 실행할 수 있다. TMN은 네트워크 장비들(NEs)로부터 서비스품질 데이터를 수집하고 서비스품질 개선을 지원한다. TMN은 서비스품질 데이터를 네트워크 장비로부터 요구할 수 있고, 또는 그러한 보고는 예정 또는 예외적으로 자동적으로 보내질 수 있도록 할 수도 있다. 언제라도, TMN은 현재의 스케줄 및/또는 예외 범위(thresholds)를 변경할 수 있다. 서비스품질 데이터에 관한 네트워크 장비로부터의 보고는 네트워크 장비에 외부적으로 분석된 로오(raw)데이터(통신 서비스를 제공하는 과정에서 모아진 데이터)로 구성될 수 있거나, 네트워크 장비는 보고가 보내지기전에 그 데이터의 분석을 일부 수행가능할 수도 있다.

도 1에서, 보안 관리(Security management)(5)는 보안의 관리를 위해 제공된다. 더욱이, 보안 관리(5)는 모든 관리 기능 영역 및 모든 TMN 트랜잭션을 위해 요구된다. 보안 관리(5)는 ITU-T M.3010에서 보안 기능의 일부로서 나타난다. 보안 관리(5)의 기능성은 통신 및 보안 이벤트 감지 및 보고를 위한 보안 서비스를 포함한다. 보안 관리(5)는 방지(prevention), 감지(detection), 억제(containment) 및 회복(recovery), 보안 행정(security administration) 등의 기능 세트 그룹을 포함한다.

도 2는 게임 서버의 운용을 최적화하는 방법이 채용되는 서버 모델의 일 예를 설명하기 위한 도면이다.

서버는 다중 기능을 가지는 많은 서버로 구성된다.

이들 서버의 예는 게임, 로비, 로그인, 데이터베이스 서버 등이 있을 수 있다. 비슷한 기능을 가지는 서버들은 서버 팜(server farms)으로 불리도록 무리를 이룬다. 서버 팜 또는 서버 클러스터는 단일 기계의 성능을 훨씬 뛰어넘는 서버의 요구를 달성하려는 사업에 의해 보통 유지된 컴퓨터 서버의 집합이다.

소켓 또는 웹 소켓을 서로 이용하여 연결된 서버를 생성하기 위해 사용된 많은 프로그래밍 언어(예컨대, C++, C#, 자바)가 있다.

도 2에서는 FCAPS를 개발과 운용에 매핑하기 위해 사용된 서버의 형태를 범주화했다.

도 2에서, 로비 팜(Lobby farm)(10)은 엑세스 사용자를 인증하기 위한 로그인 서버(11)와 로그인 DB(12), 사용자가 로그인 후에 채팅, 아이템 쇼핑 및 게임을 할 수 있도록 하는 로비 서버(13), 및 사용자에 대한 정보를 저장하는 사용자 DB(14)를 포함한다.

여기서, 로그인 서버(11)와 로그인 DB(12)는 사용자를 인증하고, 로비 서버(13)와 세션 서버(31)를 로드 밸런싱한다. 이때, 로그인 서버(11)는 로드 밸런싱 알고리즘으로 예를 들어, Round Robin, Least Connection, Response Time, Hash 등을 목적에 맞게 적용할 수 있다.

그리고, 로비 서버(13)는 사용자의 액션(팀/선수/아이템/전술/상점 등)에 대한 처리를 행할 수 있다.

사용자 DB(14)는 게임에서 절대 필요하며, 실시간 백업 과정을 수행하는 복사 데이터베이스를 가진다. 즉, 사용자 DB(원본)(14a)는 사용자 정보(원본)를 담고 있으며, DML(INSERT, UPDATE, DELETE)을 처리한다. 사용자 DB(복제)(14b)는 사용자 DB(원본)(14a)을 복제하여 사용자 정보를 실시간으로 동기화시키며, 조회(SELECT)를 처리할 수 있게 한다.

도 2에서, 게임 팜(Game farm)(20)은 게임 관리 서버(21), 게임 관리 랭킹 DB(22), 게임 서버(23), 및 게임 DB(24)를 포함한다.

게임 관리 서버(21) 및 게임 관리 랭킹 DB(22)는 게임 생성/종료, 참여 팀 관리를 담당할 수 있다.

게임 서버(23) 및 게임 DB(24)는 경기 일정관리, 결과저장, 경기 진행(매치 AI 탑재)을 담당할 수 있다. 여기서, 게임 서버(23) 및 게임 DB(24)는 로드 밸런싱을 위해 쌍을 이루면서 증설됨이 바람직하고, 게임 단위로 분산됨이 바람직하다.

도 2에서, 세션 팜(Session farm)(30)은 사용자의 연결을 관리한다. 세션 팜(30)은 비동기 방식과 한시적 동기 방식을 병행 처리할 수 있다. 세션 팜(30)의 로드 밸런싱을 위해 Least Connection 방식으로 분산하며, 로그인 서버(11)에서 세션 서버(31)를 관리하도록 한다

도 2에서, 로그 팜(Log farm)(40)은 로그 DB(원본)(41), 및 로그 DB(복제)(42)를 포함한다.

로그 DB(원본)(41)은 각 서버들에서 필요한 로그(원본)를 남기고, INSERT를 처리한다

로그 DB(복제)(42)는 로그 뷰어를 통해서 검색을 할 때 사용하고, SELECT를 처리한다.

도 2에서, 푸시 팜(Push farm)(50)은 푸시 DB(51), 및 푸시 서버(52)를 포함한다.

푸시 DB(51)는 예를 들어 "당신의 아이템(또는 캐릭터)이 공격당하고 있습니다" 등과 같은 다양한 푸시 메시지를 저장한다.

푸시 서버(52)는 푸시 DB(51) 내의 푸시 메시지를 출력할 수 있다.

도 2에서, 샵 팜(Shop farm)(60)은 샵 DB(61), 및 샵 서버(62)를 포함한다.

샵 DB(61)는 다양한 아이템(또는 캐릭터)을 저장하고 있다.

샵 서버(62)는 사용자가 샵 DB(61)내의 아이템을 구매할 수 있도록 지원한다.

이번에는, 도 3을 참조하여 매핑 과정을 통해 만들어진 운용 모델에 대하여 설명할 것이다.

도 3은 FCAPS 모델과 서버 모델의 매핑을 통한 운용 모델을 나타낸 도면으로서, FCAPS(도 1 참조) 및 서버 모델(도 2 참조)내에서 다루어진 함축적인 아티펙트(artifacts)의 모델을 나타낸다.

이 모델내에서 사용된 아티펙트들(connection, storage, network topology, user, item, payment, game, push, batch, instance, process, database, log, breach)은 도 3에서와 같은 운용 모델을 사용하여 정의되고 표현될 것이다.

이제부터는, 도 3의 운용 모델에 사용된 아티펙트를 표현할 것이다. 도 4 내지 도 9는 도 3의 운용 모델에 사용된 아티펙트를 나타낸 도면들이다.

App G는 6개가 한 벌로서, G={S,C,V,E,A,P}로 구성된다. 여기서, S는 서버들(S)들의 세트(set)이고, C는 집합(collection)(C ∈ S)으로 불리우는 관리 패시트(management facet)의 세트이고, V는 뷰(view)(V ∈ C)로 불리우는 그래뉴얼 관리 패시트(granular management facet)의 세트이고, E는 엔티티(entity)(S × C × V)→E로 불리우는 인식된 뷰의 세트이고, A는 액션(action)으로 불리우는 엔티티(entity)의 거동의 세트이고, P는 속성(name,value)→P으로 불리우는 관리가능한 데이터의 세트이다.

이와 같이 App는 도 4에서와 같이 하나 이상의 서버(server)로 구성된 게임이 실행되는 어플리케이션이다. 그리고, 서버(server)는 주로 로그인, 세션, 게임 서버 등으로 언급되는 용어이다. 서버는 도 2에서 설명한 바 있다.

한편, 서버(server)는 도 5에서와 같이 하나 이상의 집합(collection)으로 구성된다. 집합(collection)은 FCAPS의 각각의 관리 측면(management facet)과 관련되는 아티펙트들을 언급하고 있다.

그리고, 뷰(VIEW)는 도 6에서와 같이 집합(collection)내의 하위 집합을 의미하는데, 관리의 최소한의 단위를 나타낸다. 앞서 언급한 회계 관리의 예에서, 보드(board), 브로드캐스트(broadcast), 프라이비트(private), 푸시 집합(push collections)의 POI가 뷰(VIEW)에서 보일 수 있다.

또한, 뷰(VIEW)는 도 7에서와 같이 엔티티(entity)로서 실현된다. 이런 관점에서, 뷰(VIEW)는 객체-지향적 개념의 클래스(class) 및 객체로서의 엔티티로서 이해될 수 있다.

엔티티(entity)가 생성될 때, 엔티티는 도 8에서와 같이 액션(action)을 포함한다. 액션은 가장 간단한 형태의 운용의 거동(behavior)을 언급한다.

그리고, 속성(property)은 도 9에서와 같이 액션(action)시에 운용 모델의 가장 적은 아티펙트(artifacts)를 언급한다.

도 10은 도 3의 운용 모델을 이용한 운용 방법을 설명하는 흐름도로서, DSL(Domain-Specific Language) 구현을 위한 DSL 워크플로우 및 운용 패시트(facets; 측면)를 확인하기 위한 FCAPS 워크플로우를 나타낸다.

도 10에서, DSL 워크플로우(workflow)는 서버의 운용과 개발에 초점을 둔 모든 활동을 주관한다. 그리고, 운용 워크플로우(operational workflow)는 오류, 구성, 회계, 및 성능 및 보안 관리 에스펙트들을 주관한다.

운용 방법은 반복적인 원리들에 기초하며 증가하는 개발, 소프트웨어 재사용, DSL, AOP 및 DevOps와 관련되어있다.

게임 서버 운용의 최적화 방법은, DSL 워크플로우에서 재사용가능한 리소스(resource)를 식별하고, 운용 워크플로우에서 운용 패시트(facet)를 식별하는 단계(S100), 단계(S100)에서 식별된 리소스 및 운용 패시트를 근거로 DSL 아티펙트를 특정하여 운용 에스펙트를 생성한 후에 DSL을 구현하는 단계(S200), 및 단계(S200)에 의해 구현된 DSL을 근거로 실제로 게임을 운영하는 단계(S300)를 포함한다.

먼저 도 10에서의 DSL 워크플로우를 설명하고, 나중에 운용 워크플로우를 설명하는 것으로 한다.

DSL 워크플로우에서 식별 단계(S10)는, 예를 들어 소스 코드 및 문서(documents)와 같은 재사용가능한 리소스(즉, 아티펙트들)를 확인한다. 게임 도메인에서의 모든 것이 이 단계(S10)에서 확인될 수 있는 것은 아니다. 현존하는 이용가능한 소스 및 서류들이 있을 때, 그들은 다음 단계 동안 특정(specification) 프로세스에 억세스 가능하도록 식별과정을 처리하게 된다. 도 10에서, 식별 단계(S100)는 상술한 DSL 워크플로우에서 식별 단계(S10)를 포함한다.

DSL 워크플로우에서 DSL 아티펙트(artifacts) 특정 단계(S20)는, 이전의 식별 단계(S10)에서 생성된 리소스(즉, 아티펙트들)와 식별 단계(S100)의 운용 워크플로우에 의해 생성된 운용 아티펙트를 결합함으로써 만들어진다. DSL 워크플로우의 DSL 아티펙트 특정 단계(S20)에서는 예를 들어 서버, 집합, 뷰(view) 및 액션과 같은 방법 아티펙트들을 확인할 수 있다.

DSL 워크플로우에서 운용 에스펙트 생성 단계(S30)는, 에스펙트(aspect)가 적용된 단계이다. 이 단계(S30)에서는 운용 에스펙트를 레거시 코드(legacy code)에 적용하고, 새로운 게임이 개발될 때 운용 에스펙트를 적용할 수 있다. 즉, 상술한 단계(S20)에서 특정된 DSL 아티펙트를 레거시 코드에 적용하여 운용 에스펙트를 생성한다고 볼 수 있다.

레거시 서버에 적용할 때, 개발자는 직접 또는 반자동으로 고칠 수 있고, 코드를 적용할 수 있다. 운용 에스펙트를 적용시키는 방법은 하기의 표 1과 같다.

서버 유형(server type)	방법	설명
레거시 서버 (Legacy servers)	수동	개발자는 각각 및 그들중 하나가 손수 적용해야 한다.
	반자동	운용 에스펙트 알고리즘이 인가된다.
새로운 서버 (New Server)	수동	운용 에스펙트는 확인된 후에 개발되고 새로운 서버를 개발할 때 개발자에 의해 적용된다.

DSL 워크플로우에서 DSL(Domain-Specific Language)을 구현하는 단계(S40)는, 운영자에 의해 사용되는 DSL을 생성한다. DSL의 생성은 이미 정의된 바와 같이 개발자의 부담을 줄이기 위해 운용 에스펙트(operational aspect)의 사용을 통해 달성되며, 현존하는 코드의 재사용을 활성화시킨다. 이러한 점에서, DSL은 운영자의 프로그래밍 수준에 의해 결정된 내부 또는 외부의 방법을 통해 생성될 수 있다. 그러나, 고급 수준 표현의 외부의 DSL 사용을 장려한다. 도 10에서, DSL화시키는 단계(S200)는 상술한 DSL 워크플로우에서 DSL 아티펙트 특정 단계(S20), DSL 워크플로우에서 운용 에스펙트 생성 단계(S30), 및 DSL 워크플로우에서 DSL(Domain-Specific Language)을 구현하는 단계(S40)를 포함한다.

DSL 워크플로우에서 개발 및 운용하는 단계(S50, S52)는, 개발자와 운영자가 실제로 게임을 운용하는 단계이다. 운영자들은 개발자에게 게임 운용을 위한 새로운 기능을 요구할 수도 있고, 그에 따라 개발자는 새로운 집합, 뷰들(views), 엔티티, 액션, 속성 등을 그러한 요구에 기초한 DSL에 포함할 수도 있다. 새로운 운용 에스펙트가 생길 때, 그것은 DSL 구현의 이전 단계로 돌아가고 반복한다. 도 10에서, 개발 및 운용하는 단계는 상술한 DSL 워크플로우에서 개발 및 운용하는 단계(S50, S52)를 포함한다.

이번에는, 도 10에서의 운용 워크플로우에 대해 설명한다.

운용 워크플로우에서 식별 단계(S60)는, 오류, 구성, 회계, 성능 및 보안의 다섯 기준(criteria)을 서버내에서 식별한다. DSL 워크플로우와 유사하게, 식별 단계(S60)은 최종 단계가 아니며, 오로지 식별가능한 기준을 이 과정을 통해 얻어낸다. 서버와 같은 중요한 기준이 식별되어야만 한다. 도 10에서, 식별 단계(S100)는 상술한 운용 워크플로우에서 식별 단계(S60)를 포함하므로, 결국 식별 단계(S100)는 상술한 DSL 워크플로우에서 식별 단계(S10) 및 운용 워크플로우에서 식별 단계(S60)를 포함한다고 볼 수 있다.

운용 워크플로우에서 운용 아티펙트 특정 단계(S70)는, 집합(collection), 뷰(view), 엔티티(entity), 액션(action) 및 속성(property)과 같은 운용 모델에서 정의된 아티펙트들을 특정한다. 이 특정 단계(S70)는 DSL 워크플로우의 DSL 아티펙트 특정 단계(S20)에 추가된다. 이 단계(S70)에서 DSL은 회사에 적당한 신택스(syntax) 및 시맨틱(semantics)을 얻는다. 도 10에서, DSL화하는 단계(S200)는 상술한 운용 워크플로우에서 운용 아티펙트 특정 단계(S70)를 포함하므로, 결국 DSL화시키는 단계(S200)는 상술한 DSL 워크플로우에서 DSL 아티펙트 특정 단계(S20), DSL 워크플로우에서 운용 에스펙트 생성 단계(S30), DSL 워크플로우에서 DSL(Domain-Specific Language)을 구현하는 단계(S40), 및 운용 워크플로우에서 운용 아티펙트 특정 단계(S70)를 포함한다고 볼 수 있다.

도 11 내지 도 17은 도 10의 설명에 채용되는 도면들이다.

운용 아티펙트 특정 단계(S70)를 수행하기 위하여, 예를 들어 도 11에서와 같은 ACME회사 app을 사용하여 출력 특정을 다룬다. 서버는 로그인, 로비, 게임 관리 등으로 구성되며, 오로지 각각의 운영 패시트(facets; 측면)에 관련되는 집합(collection)에 부응하도록 특정한다.

DSL 아티펙트를 특정하는 단계(S20)는, 개략적으로 상술한 단계에서 확인된 집합(collection)을 가지고, 운용 모델의 아티펙트들이 언어를 구현하기 위해 특정된다. 비록 일반 언어들이 가진 조건, 루프, 및 변수들이 DSL내에서 특정되어야 하지만, 간단하게 하기 위하여 본 발명의 실시예에서는 오로지 신택스(syntax) 및 시맨틱스(semantics)만을 다루었다.

app을 다시 설명하면 다음과 같다. 도 12에서는 app의 서버(server)를 도시하였는데, 서버(server)는 로그인, 로비, 게임 등을 포함한다. 데이터베이스가 그러한 서버 유닛에 의해 엑세스될 때, 서버 목록(list)내에 포함되지 않는다.

도 13에서는 서버의 집합(collection)을 나타내었는데, 집합은 시작할 때, 집합을 추론하기 위해 물리적 자원과 논리적 자원으로 나누어진다. 그러나, 본 발명의 명세서에서는 관련 연구에서 보는 것과 같이 양이 많기 때문에 물리적 자원을 다루기 위해 사용된 연구를 면제하였다.

도 14는 서버의 집합(collection)을 도시하고 있다. 식별되지 않은 집합은 추후에 정의되며, DSL화하는 단계에서 DSL을 반영한다.

도 15는 집합의 뷰(View)를 나타내는데, 뷰(View)는 집합의 부분 집합을 통해 정의된다. 각각의 뷰(view)는 직관적이다. PushInfo는 집합 중의 하나로서, 다른 사용자에 대한 통지(notifications)를 포함하고, 보드, 브로드캐스트, 프라이비트, 및 poi로 나누어진다. 또한, 운용 패시트(operational facet)중에서 성능(performance)은 이러한 집합을 관리하기 위한 알고리듬(algoritm), 카운트(count), 보고(report)로 나누어진다.

도 16은 집합의 뷰(View)를 나타내는데, 적용된 뷰(View)의 예를 나타낸다. 도 16은 도 15의 컨텐츠를 적용하며, 집합 및 뷰(View)에서 필요한 방향으로 나누어진다.

엔티티(entity)는 집합(collection), 뷰(view), 액션(action)의 페어링(pairing)으로서, 그들을 객체로 만들기 위한 것이다. 이러한 엔티티는 최소단위의 관리가 된다.

액션(action)은 그들이 구현되는 방법에 의존하여 다르게 될 것이며, 개발자는 그 회사에 적당한 정의를 생성한다.

속성(property)은 액션에 관련된 유닛이다. 게임내에서 게임 정보의 속성의 예는 도 17과 같이 도시될 수 있다. 이 예처럼, JSON은 단순한 키(keys) 및 가치(value)의 쌍(pairs)으로 된 형태로서 속성을 정의한다.

이하부터는, 상술한 게임 서버의 운용을 최적화하는 방법에서 운용 에스펙트가 분리되고 생성을 통해 사라지는 단계인 운용 에스펙트 생성에 대해 보다 상세하게 설명한다.

본 발명의 실시예에서, 게임 서버에 운용 에스펙트를 적용하는 방법으로는, 레거시 게임 서버에 에스펙트를 삽입하는 방법, 및 새롭게 개발된 게임 서버에 에스펙트를 노출시키는 방법이 있을 수 있다.

먼저, 운용 에스펙트(operational aspect)의 개념에 대해 설명한다. 도 18은 일반적인 FCAPS 컨선(concerns)을 가진 서버를 구현한 예이고, 도 19는 다수의 FCAPS 컨선(concerns)으로 인해 엉켜진 소스 코드들의 예를 나타낸 도면이다.

도 18에 예시된 바와 같이, 레거시 서버 소스는 제 3자에서 정의된 코어 게임 로직 및 다른 운영 패시트(facets; 측면)에 대한 컨선(concerns)을 포함한다. 만약, 컨선(concerns)이 종래의 방법을 통해 개발되었다면, 개발자는 단일 코드내에 여러 가지 업무(jobs)를 다루어야만 하기 때문에 코드는 엉키게 된다. 다시 말해서, 기존의 게임 서버의 소스 코드는 핵심 게임 로직 외에 Fault, Configuration, Accounting, Performance, Security에 관한 로직이 하나의 소스내에 섞여 있다.

이를 도식화하여 보면 도 19처럼 표현될 수 있다. 도 19에서와 같이, 운용에 대한 컨선(concerns)은 전체 코드를 가로질러 흩어지게 되고, 결국은 가독성과 유지보수성의 저하를 가져온다.

본 발명에서는 이에 대한 해결책으로서 운용 에스펙트의 패러다임을 소개한다. 이는 같은 클래스내에 게임 운용 관련 방법을 위치시키지 않고 그들을 별도의 에스펙트로 분리한다는 것에 특징이 있다.

도 20은 에스펙트 개념을 적용하여 자동으로 엮어지고 DSL을 통해 생성되는 FCAPS 에스펙트를 나타낸 도면으로서, 운용 에스펙트에 대한 설명을 제공한다. 도 20에서, 에스펙트(예컨대, 로그인 서버(11), 게임 서버(23), 세션 서버(31), 푸시 서버(52))는 컴파일될 때 자동적으로 엮여지며, FCAPS 운영은 이렇게 엮여진 에스펙트내에 노출된다. 노출된 운용 에스펙트들은 후에 DSL내에서 사용된다.

한편, 운용 에스펙트 개념을 적용하여 생성된 코드들은 도 21과 같이 도시될 수 있다. 도 21은 운용에 관한 컨선(concerns)이 제거된 후에 남아 있는 게임 코어 로직을 가진 소스 코드의 일 예이다. 도 21에 도시된 것처럼, 게임에 대한 코어 로직을 제외하고 남은 모든 운용 로직은 삭제되었다. 개발자는 단지 소스 코드내에서 게임 로직만을 다루며, 운용에서 요구된 코드들은 운용 에스펙트내에서 별도로 다룬다.

이번에는, 레거시 서버내에서 및 새롭게 생성된 서버내에서 에스펙트를 생성하는 방법에 대해 설명한다.

새로운 게임을 위한 서버에서, AOP 방법은 레거시 서버에 AOP를 적용시키기 위하여 개발을 위해 사용될 수 있다. 그러나, 에스펙트를 생성하는 레거시 코드를 이용한 알고리즘이 요구된다. 그런 알고리즘을 도식화하기 위하여, 에스펙트 엘리먼트(요소)가 정규화된다.

특히, 운용 에스펙트들을 레거시 게임 서버에 적용시키기 위한 방법을 설명하기 위하여 상세한 워크플로우가 다루어져야만 한다.

도 22는 레거시 서버에 운용 에스펙트 응용에 대한 워크플로우의 개요도이다. 도 23 내지 도 27은 도 22의 설명에 채용되는 도면으로서, 도 23은 주석달린 소스 코드의 일 예를 나타낸 도면이고, 도 24는 운용 에스펙트의 생성을 결정하는 알고리즘을 예시한 도면이고, 도 25는 에스펙트를 생성하는 알고리즘을 예시한 도면이고, 도 26은 레거시 서버의 에스펙트를 생성하는 방법을 삭제하는 알고리즘을 예시한 도면이고, 도 27은 운용 에스펙트 코드의 일 예를 나타낸 도면이다.

도 22에서, 레거시 서버(legacy server)(80)는 레거시 서버 소스이고, 운용 로직이 클래스내에서 엉켜있다. 레거시 서버(80)의 운용 로직은 도 18에서와 같이 전체 소스에 걸쳐 코어 로직과 엉켜있다.

개발자가 레거시 서버(80)에서 현존하는 소스에 주석(annotation)을 쓴다(S400). 여기서, 주석은 집합(collection), 뷰(view), 및 액션(action)을 지정한다. 지정된 집합(collection), 뷰(view), 및 액션(action)은 운용 방법의 아티펙트(artifacts)가 된다.

개발자가 레거시 서버(80)에서 현존하는 소스에 주석(annotation)을 쓰게 됨에 따라, 도 23에 예시한 바와 같은 주석 코드(annotated code)(82)가 생성된다. 도 23에서, 1 ~ 3째줄의 소스 코드를 설명하면 보면, 1째줄에서의 집합(collection)은 오류(fault), 연결(connection)에 대한 뷰(view), 감지(detect)에 대한 액션(action)으로 주석이 달렸다. 이러한 소스내에서의 클래스의 이름은 에스펙트가 2째줄에 정의된 것처럼 노출될 것이다. 3째줄에는 이음 포인트(joint point)가 지정되었다. 이음 포인트는 SomeGameserverClass.connect(..)에 의해 지정되었고, SomeGameserverClass.connect(..)는 SomeGameserver 클래스의 연결방법에 적용된다는 것을 의미한다. SomeGameserver 클래스는 변수의 수 및 변수의 형태(type)에 무관하다. 연속적으로 이어지는 point=”after”는 지정된 방법 이후에 조언(advice)의 삽입을 의미한다.

간단히 하기 위하여, 도 23에서는 운영 모델 집합들 및 뷰들(views)의 특정한 섹션만 도시될 것이다.

이후, 생성된 주석 코드(82)는 운용 에스펙트 생성기(84)에게로 전송된다. 운용 에스펙트 생성기(84)는 개발자가 실행시킴에 따라 동작한다(S402). 운용 에스펙트 생성기(84)는 주석 코드(82)(즉, 주석 달린 소스 코드)를 분석하고 분석 결과를 근거로 운용 에스펙트를 생성한다(S404). 이것을 통해, 운용 컨선(concern)은 레거시 코드로부터 제거되며, 주석(annotation)을 통해 결정된 방법은 운용 에스펙트로 옮겨진다.

여기서, 주석 코드(주석 달린 소스 코드)를 에스펙트로 매칭시키는 운용 에스펙트 생성기(84)의 매칭 시맨틱스(matching semantics)를 설명하면 다음과 같다. 설명하기 전에 매칭 시맨틱스의 정의를 규정한다.

1) 정의 1 (소스)

- 엉켜진 운용 concern 및 코어 concern의 현존하는 소스 코드는 S로 표시된다.

2) 정의 2 (운용 concern)

- 운용 concerns은 O로 표시된다. 일련의 운용 concerns는 O 로 표시된다.

3) 정의 3 (주석)

- 소스 코드에서 시멘틱 메타데이터의 특별한 형태로서, 운용 에스펙트 주석 조각의 집합은 T로 정의된다. 운용 concern의 모든 S가 주석이 달린 때, 다음 방정식이 확립된다.

T:=fault(O) ∪ configuraion(O) ∪ accounting(O) ∪ performance(O) ∪ security(O).

여기서, 운용 concern 소스만을 포함하는 S는 S^O로서 정의된다.

여기서, 코어 concern만을 포함하는 S는 S^C로 표시된다.

그리고, 개발자가 주석을 달 때, 그것은 S≒S^C ∪ S^O ∪ Te로 확립된다.

4) 정의 4 (주석 서명)

T는 {T^e,T^c,T^m}으로 구성된다. 여기서, T^e는 엔티티(entity)를 정의하고, T^c는 클래스(class)를 정의하고, T^m은 방법(method)을 정의한다.

T^e는 {T_c ^e,T_v ^e,T_a ^e}로 구성된다. 여기서, T_c ^e는 집합(collection)을 정의하고, T_v ^e는 뷰(view)를 정의하고, T_a ^e는 액션(action)을 정의한다.

T^m은 {T_s ^m,T_p ^m}으로 구성된다. 여기서, 방법 서명(method signature)은 T_s ^m으로 표시되고, 포인트컷(pointcut)은 T_p ^m으로 표시된다.

5) 정의 5 (에스펙트)

운용 에스펙트를 소개함으로 운용 크로스컷팅(crosscutting) concerns의 분리는 A로서 정의된다.

운용 에스펙트 주석의 조각의 세트(set)는 A로 정의되되, A ⊆ A이다.

6) 정의 6 (에스펙트 서명)

A는 에스펙트 조각의 집합이고, A는 {A ^t,A ^h,A ^p,A ^a}로 구성된다. 여기서, A ^t는 에스펙터 형태(type)를 정의하는 형태 서명이고, A ^h는 광범위한 싱글톤(singleton) 객체인 운용 객체이고, A ^p는 에스펙트내의 포인트컷이고, A ^a는 에스펙트내의 조언(advice)이다.

A ^p는 {A _m ^p,A _s ^p}로 구성된다. 여기서, A _m ^p는 방법 이름이고, A _s ^p는 실행 서명이다

A ^a는 {A _t ^a,A _c ^a}로 구성된다. 여기서, A _t ^a는 조언 실행 시간이고, A _c ^a는 실행될 코드이다.

7) 정의 7 (매핑)

S 내의 T를 변환시키기 위해 매핑을 정의한다.

σ_T ^A 는 T부터 A까지 각각의 매핑 결과를 각각 저장한다. σ_T ^A = {T1 → A1, …, Tn → An}.

그리고, 운용 에스펙트 생성기(84)는 운용 에스펙트의 생성을 결정하기 위해 도 24에 예시한 알고리즘을 사용할 수 있다. 도 24는 (집합(collection), 뷰(view), 액션(action)) ∈ T의 세트의 정의 서술을 이용하여 알고리즘을 설명하고 있다. 만약, 정의 서술이 이전에 생성되지 않았다면, 집합(collection), 뷰(view), 액션(action)은 운용 객체(operational object)를 생성하기 위해 사용된다. 또한, 만약 클래스 이름, 정의 서술의 방법 이름이 소스 내에 존재하면, 클래스 이름, 정의 서술의 방법 이름은 활성화된 지위(status)를 반환한다. 이름 기능은 간단히 객체의 이름을 반환한다.

이후, 운용 에스펙트 생성기(84)는 운용 에스펙트를 생성하게 되는데, 이때에는 도 25에 예시된 알고리즘을 사용할 수 있다. 에스펙트의 클래스 이름이 결정된 후에, 운용 에스펙트의 싱글톤 인스턴스가 삽입된다. 그리고 나서, 포인트컷(pointcut) 및 조언(advice)이 생성된다. 도 25에서, 0는 스트링 연결 오퍼레이터(string concatenation operator)를 나타낸다. 한편, 운용 에스펙트 생성기(84)는 도 26의 알고리즘을 사용하여 레거시 소스의 에스펙트를 생성하는 경우의 방법을 삭제할 수도 있다.

이와 같이 운용 에스펙트 생성기(84)가 주석 코드(82)를 분석하여 운용 에스펙트를 생성하는 경우, 도 27에 예시된 바와 같은 운용 에스펙트 코드(86)가 생성될 수 있다. 도 27에서, faultConnection은 FCAPS의 객체이다. FaultConnection은 싱글톤 클래스이고, faultConnection은 싱글톤 클래스인 FaultConnection의 객체이다. 도 27에서는 간단히 하기 위해, 반복적으로 생성된 프라이빗 객체(private object)를 도시한다.

그리고, 운용 에스펙트 코드(86)가 생성된 이후에는, 개발자는 생성된 운용 에스펙트 코드(86)에 대한 리바이즈(revise) 작업을 수행한다(S406). 즉, 개발자는 필요한 업무(job)에 쓰기 위하여 운용 에스펙트 코드(86)를 사용한다. 이때, 상술한 소스의 조인트 포인트에서, faultConnection.alarm()에 대한 방법이 구현될 것이다.

그리고 나서, 리바이즈 작업이 완료된 운용 에스펙트 코드(86) 및 주석 코드(82)는 컴파일 및 위브기(compile & weave device)(88)에게로 전송된다.

이어, 개발자는 컴파일 및 위브기(88)를 실행시킨다(S408). 그에 따라, 컴파일 및 위브기(88)는 레거시 서버의 언어에 적당한 컴파일러를 사용함으로써, 소스는 컴파일되고 엮어질 것이다.

이와 같이, 검파일 및 위브기(88)에서 컴파일되고 엮어진 소스는 운용 에스펙트 서버(90)로 제공된다.

그에 따라, 운용 에스펙트 서버(90)는 에스펙트 컴파일러를 통해 운용 에스펙트 분리 서버 코드를 생성한다(S410). 운용 에스펙트 서버(90)는 운용 에스펙트 분리 서버 코드와 레거시 코드를 비교함으로써, 가독성 및 유지보수성(maintainability)의 수준을 향상시킨다. 또한, 운용 에스펙트 분리 서버 코드가 생성될 때 싱글톤 객체인 운용 객체(operational objects)가 생성된다. 운용 객체는 운용 객체 저장부(92)에 저장된다. 여기서, 운용 객체는 오류(fault), 구성(configuration), 회계(accounting), 성능(performance), 및 보안(security)으로 구성된다. 각각의 운용 객체의 선언(declaration) 및 포인트컷(pointcut) 방법은 운용 에스펙트 생성기(84)에 의해 자동으로 생성된다.

상술한 바와 같은 과정 이후에, 개발자에 의해 만들어진 DSL(S412, S414)은 운용 객체의 사용에 의해 실행될 것이다(S416). 추후에, 이러한 언어에 대하여 변형 및 확장의 필요가 있을 때에는 운용 객체를 위하여 언어가 자동적으로 변경되기 때문에 더 이상의 고려는 불필요할 것이다.

이상에서와 같이 도면과 명세서에서 최적의 실시예가 개시되었다. 여기서 특정한 용어들이 사용되었으나, 이는 단지 본 발명을 설명하기 위한 목적에서 사용된 것이지 의미 한정이나 청구범위에 기재된 본 발명의 범위를 제한하기 위하여 사용된 것은 아니다. 그러므로, 본 기술 분야의 통상의 지식을 가진자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호범위는 첨부된 청구범위의 기술적 사상에 의해 정해져야 할 것이다.

10 : 로비 팜 11 : 로그인 서버
12 : 로그인 DB 13 : 로비 서버
14 : 사용자 DB 14a : 사용자 DB(원본)
14b : 사용자 DB(복제) 20 : 게임 팜
21 : 게임 관리 서버 22 : 게임 관리 랭킹 DB
23 : 게임 서버 24 : 게임 DB
30 : 세션 팜 31 : 세션 서버
40 : 로그 팜 41 : 로그 DB(원본)
42 : 로그 DB(복제) 50 : 푸시 팜
51 : 푸시 DB 52 : 푸시 서버
60 : 샵 팜 61 : 샵 DB
62 : 샵 서버 80 : 레거시 서버
82 : 주석 코드 84 : 운용 에스펙트 생성기
86 : 운용 에스펙트 코드 88 : 컴파일 및 위브기
90 : 운용 에스펙트 서버 92 : 운용 객체 저장부

Claims (5)

1. 레거시 서버가, 운용 방법의 아티펙트(artifacs)가 되는 집합(collection), 뷰(view), 및 액션(action)을 포함하는 주석이 달린 소스를 근거로 주석 코드를 생성하는 단계;
   운용 에스펙트 생성기가, 상기 주석 코드를 분석하여 운용 에스펙트 코드를 생성하는 단계;
   컴파일 및 위브기가, 상기 주석 코드 및 상기 운용 에스펙트 코드를 컴파일하고 엮는 단계; 및
   운용 에스펙트 서버가, 상기 컴파일 및 위브기에 의해 컴파일되고 엮어진 소스를 에스펙트 컴파일러를 통해 컴파일하여 운용 에스펙트 분리 서버 코드를 생성하는 단계;를 포함하는 것을 특징으로 하는 게임 서버의 운용 에스펙트 생성 방법.
2. 청구항 1에 있어서,
   상기 운용 에스펙트 코드를 생성하는 단계는,
   상기 주석 코드를 에스펙트로 매칭시키기 위한 매칭 시맨틱스를 사용하되, 상기 매칭 시맨틱스는 소스(source), 운용 컨선(operational concern), 주석(annotation), 주석 서명(annotation signature), 에스펙트(aspect), 에스펙트 서명(aspect signature), 및 매핑(mapping)에 정의가 규정된 것을 특징으로 하는 게임 서버의 운용 에스펙트 생성 방법.
3. 청구항 1에 있어서,
   상기 운용 에스펙트 분리 서버 코드를 생성하는 단계는,
   상기 운용 에스펙트 분리 서버 코드를 생성할 때 운용 객체도 함께 생성하는 것을 특징으로 하는 게임 서버의 운용 에스펙트 생성 방법.
4. 청구항 3에 있어서,
   상기 운용 객체는 오류(fault), 구성(configuration), 회계(accounting), 성능(performance), 및 보안(security)을 포함하고,
   각각의 운용 객체의 선언(declaration) 및 포인트컷(pointcut) 방법은 상기 운용 에스펙트 생성기에 의해 자동으로 생성되는 것을 특징으로 하는 게임 서버의 운용 에스펙트 생성 방법.
5. 청구항 1에 있어서,
   상기 운용 에스펙트 분리 서버 코드를 생성하는 단계 이후에,
   상기 운용 에스펙트 서버가, 상기 운용 에스펙트 분리 서버 코드와 레거시 코드를 비교함으로써 가독성 및 유지보수성을 향상시키는 것을 특징으로 하는 게임 서버의 운용 에스펙트 생성 방법.

Images