1. 서론

클라이언트-서버 기반의 분산 또는 네트워크 애플리케이션은 클라이언트 노드가 서버 노드에게 서비스를 요청하고 반대로 서버 노드가 클라이언트 노드로 서비스 결과를 제공하는 형태로 서로 상호작용하는 애플리케이션이다. 하드웨어 성능과 네트워크 속도가 향상됨에 따라 이러한 네트워크 애플리케이션의 실행 플랫폼이 데스크탑과 모바일 환경으로 다양화되는 등 복잡도가 올라가고 이를 처음부터 개발하기가 어려워지고 있다.^[1] 네트워크 애플리케이션 프레임워크 또는 미들웨어는^[2] 클라이언트 및 서버의 통신 기능의 빠른 개발에 도움을 주는 애플리케이션 프로그래밍 인터페이스(API)를 제공한다.

그런데, 기존의 프레임워크나 미들웨어 연구에서는 특정 플랫폼만 대상으로 하거나 다양한 플랫폼에 대한 지원 여부를 특별히 고려하고 있지 않다. 예를 들어, 본 논문의 이전 연구인 기존 통신 프레임워크(CM)는^[3,4] 데스크탑 플랫폼을 주 대상으로 하기 때문에 클라이언트와 서버도 데스크탑 애플리케이션으로 가정했다. 안드로이드 같은 모바일 플랫폼에서 클라이언트 개발에 기존 CM을 적용하려면 데스크탑 환경과 다른 안드로이드 플랫폼 특성 때문에 문제가 된다. 첫째, 안드로이드 플랫폼에서 CM 설정 파일을 다루기가 불편하다. 클라이언트가 CM을 이용하기 위해서는 별도의 설정 파일에 서버 정보 등을 편집해야 하는데, 데스크탑 클라이언트는 설정 파일을 별도로 직접 편집할 수 있는 반면에 안드로이드 클라이언트는 배포되는 클라이언트 앱 내에 설정 파일이 포함되어야 하기 때문에 사용자가 직접 액세스할 수 없다. 또한, 기존 CM에서는 설정 파일의 경로가 애플리케이션 실행 디렉토리로 고정되어 있어 설정 파일의 위치를 변경하지 못하는 문제도 있다. 둘째, 안드로이드 앱의 메인 스레드에서는 네트워크 관련 메소드를 직접 호출할 수 없다. 메인 스레드는 사용자 인터페이스(UI)를 통한 이벤트를 항상 처리해야 하는데 이 스레드가 호출한 네트워크 메소드에 지연이 발생하면 전체 앱 실행이 잠시 중단되는 문제가 발생하기 때문이다. 클라이언트가 호출하는 CM 애플리케이션 프로그래밍 인터페이스(API) 중에서도 네트워크 메소드를 사용하는 경우가 있기 때문에, 안드로이드 클라이언트는 이런 API를 바로 호출하지 못하고, 별도 스레드를 통해 호출해야 한다. 이러한 문제점 때문에, 클라이언트는 안드로이드 플랫폼에서 기존 CM을 이용하기가 매우 불편하고 데스크탑 환경과 개발 방식이 일관되지 못하게 된다. 설정 파일 관련한 문제는 CM의 특수한 경우이지만, 메인 스레드에서의 네트워크 메소드 호출 문제는 CM뿐만 아니라 다른 관련 연구들에도 동일하게 발생한다.

본 논문에서는 기존 CM의 문제점을 개선하여 데스크탑 플랫폼과 모바일 플랫폼에서의 클라이언트-서버 애플리케이션 개발을 모두 지원하는 통신 프레임워크(CM)을 제안한다. 제안하는 CM의 주된 역할은 개발자에게 애플리케이션 플랫폼에 상관없이 다양한 하이레벨 통신 서비스를 사용하는 방법에 일관성을 유지하는 것이다. 따라서, 본 논문에서 주로 다루는 내용은 CM 서비스를 본격적으로 사용하기 전에 클라이언트가 CM을 설정하는 방법을 위주로 기술한다. 먼저 설정 파일 문제를 해결하기 위해, 애플리케이션은 CM 설정 파일 경로를 CM에 등록할 수 있게 개선되었다. 안드로이드 클라이언트 앱이 배포될 때, 설치파일인 apk 파일 이외에 CM 설정 파일을 별도로 제공하는 것은 비효율적이기 때문에 설정 파일 역시 apk 파일에 포함된다. 클라이언트 apk 파일에 포함된 설정 파일 자체는 읽기 전용으로만 액세스가 가능하기 때문에, 클라이언트는 설정 파일 편집을 위해 안드로이드 플랫폼의 내부 스토리지 같은 임의의 경로로 이동시키고, 추가된 CM API를 통해 설정 파일의 새로운 경로를 CM에 등록할 수 있다. 또한, CM 서비스에 설정 파일 내의 필드값을 읽고 변경할 수 있는 API를 추가하여, 클라이언트가 설정 파일을 직접 액세스하지 않고도 필드 값을 편집하는 것이 가능해졌다. 애플리케이션 메인 스레드에서의 네트워크 메소드 호출 문제를 해결하기 위해, 먼저 메인 스레드에서 호출하는 CM API 중 내부적으로 소켓 채널 관리와 연관된 네트워크 메소드를 호출하는 API를 선별했다. 해당 API가 호출되면, CM은 네트워크 관련 메소드를 스레드풀을 통해 별도 스레드에서 호출하도록 변경했다. 따라서, 애플리케이션은 데스크탑과 안드로이드 플랫폼에 상관없이 메인 스레드에서 CM API를 그대로 사용할 수 있다.

본 논문의 구성은 다음과 같다. 2장에서는 기존의 네트워크 애플리케이션 프레임워크와 미들웨어에 대해 기술하고,이기종 플랫폼에서의 애플리케이션 개발을 어떻게 지원하는지 분석한다. 3장에서는 이전 연구인 기존 CM의 역할과 스레드 모델을 소개하고, 데스크탑 애플리케이션이 기존 CM을 이용하는 과정을 기술한다. 4장에서는 기존 CM이 안드로이드 플랫폼을 지원하기 위해 고려해야할 사항들을 기술하고, 5장에서 구체적인 CM 개선 방법을 기술한다. 6장에서는 애플리케이션이 데스크탑과 안드로이드 플랫폼에서 일관된 방법으로 개선된 CM을 이용하는 절차를 기술하고, 이를 CM 안드로이드 클라이언트 앱 개발에 실제 적용한 결과를 제시한다. 마지막으로, 7장에서 결론과 향후 연구 내용을 요약하고 논문을 마무리한다.

2. 관련 연구

이번 장에서는 네트워크 애플리케이션 개발을 도와주는 기존의 프레임워크와 미들웨어에 대해 기술하고, 애플리케이션이 이들 프레임워크나 미들웨어를 사용할 때, 데스크탑과 안드로이드 환경 같은 플랫폼 차이로 인한 문제를 어떻게 다루는지 분석한다.

본 논문의 이전 연구인 기존 통신 프레임워크(CM)^[3,4]는 클라이언트-서버 애플리케이션 개발을 용이하게 하는 고수준 통신 서비스를 지원한다. 현재 CM은 데스크탑 플랫폼을 기반으로 한 애플리케이션 개발을 가정하기 때문에, 안드로이드 같은 모바일 플랫폼에서 통신 서비스를 사용하기가 상당히 비효율적이다. 자세한 사항은 이후 장에서 더 구체적으로 기술한다. [5]^[5]의 연구는 무선 인터넷 환경에 특화된 메시지 중심 미들웨어인 MOCKETS를 제안했다. MOCKETS는 TCP 통신의 단점을 보완하고자 UDP 기반으로 통신 노드의 이동시에도 끊김없는 통신 서비스를 제공한다. 하지만, 소켓 레벨의 통신 기능을 애플리케이션 단에서 제공하는 것에 초점을 맞추었기 때문에 애플리케이션 개발 플랫폼 종류별 서비스 지원 여부는 기술되지 않았다. [6]^[6]의 연구에서는 네트워크 게임을 위한 메시지 중심 미들웨어를 제안했다. 특히, 이 연구는 대규모 사용자로 인한 메시지 수를 감소시켜 확장성을 제공하기 위해, 사용자의 메시지 관심도 (또는 필터링) 관리 기법에 초점을 맞추고 있다. 이 미들웨어는 애플리케이션의 대상 플랫폼을 따로 기술하지는 않았지만 주로 데스크탑 클라이언트를 가정하고 있다. [7]^[7]의 통신 미들웨어 (Generic Communication Middleware) 연구에서는 주로 이기종 분산 컴퓨팅 환경의 개발을 용이하게 하기 위한 메시징 서비스를 제공한다. 다양한 애플리케이션의 요구사항에 맞게 데스크탑과 모바일 플랫폼 모두 지원하지만 소켓 레벨의 메시지 송수신 서비스에 중점을 두기 때문에 이기종 플랫폼의 특성 차이로 인한 이슈가 없다. [8]^[8]의 연구에서는 CORBA^[9]와 유사하지만 보다 경량의 통신 서비스를 지원하는 객체지향 미들웨어로써 인턴넷 통신 엔진(Internet Communication Engine)을 제안했다. CORBA와 유사한 서비스를 제공하기 때문에 데스크탑 및 모바일 플랫폼에서의 통신을 지원하지만 이에 대한 구체적인 설명은 없다. [10]^[10]의 연구에서는 FlexFeed라고 하는 전장 환경에 특화된 모바일 에이전트 기반의 통신 프레임워크를 제안했다. 주로 제한된 컴퓨팅 및 통신 리소스를 갖는 이기종 시스템에서의 데이터 데이터 스트리밍 방법에 초점을 맞추고 있고, 지원하는 플랫폼에 대한 별도 기술은 없다. MoCA^[11]는 모바일 사용자용 협업 애플리케이션 개발을 지원하는 미들웨어이다. 서버 및 클라이언트 API와 프락시 프레임워크를 제공하고, 클라이언트 디바이스의 다양한 컨텍스트에 따라 적응형 서비스를 제공한다. MoCA는 자바를 기반으로 하고 있고 데스크탑과 모바일 플랫폼 특성 차이에 대한 고려는 기술하지 않았다.^[12] 의 연구에서는 스마트폰 상에서의 SNS 개발 지원에 중점을 둔 미들웨어를 제안했다. Surrogate 객체 사이에서 Publish-Subscribe 기반의 통신을 통해 친구의 현재 위치를 지속적으로 업데이트하는 등의 특정 서비스 용도로 사용된다. [13]^[13]의 연구에서는 클라이언트-서버 환경이 아닌 애드혹 피어대피어(P2P) 환경에서 SNS 콘텐츠를 디바이스 사이에 직접 전달할 수 있는 MobiClique라는 SNS 미들웨어를 소개했다. MobiClique은 주로 친구와의 연결 상태, 메시지 수신 같은 SNS 관련 통지 이벤트를 비동기식으로 전달하는 서비스를 제공한다. [14]^[14]와 [15]^[15]의 연구에서는 MobiSoC이라는 모바일 SNS 개발용 플랫폼을 제공하는 미들웨어를 제안했다. MobiSoC은 프로파일, 사용자 위치, 장소 정보같은 사용자 그룹의 다양한 소셜 상태를 모니터링, 관리, 공유하는 기능을 중점 서비스로 제공한다. 이상의 온라인 소셜 네트워크(OSN)를 대상으로 하는 미들웨어 연구들은 주로 모바일 플랫폼만을 대상으로 하기 때문에 이기종 플랫폼에 대한 지원 이슈가 없다.

Netty(https://netty.io), Apache MINA(https://mina.apache.org), Grizzly (https://javaee.github.io/grizzly/) 프로젝트는 서버 및 클라이언트의 빠른 개발을 지원하는 이벤트 기반 네트워크 애플리케이션 프레임워크이다. 자바 기반으로 동기식 또는 비동기식의 다양한 소켓 관리 및 입출력 관련 API를 제공하여 애플리케이션의 통신 기능 개발을 용이하게 해준다. Message Passing Interface (MPI)는^[16,17] 여러 프로세스들 사이의 메시지 전달 프로토콜 표준이다. 병렬 및 분산 컴퓨팅 시스템 개발에서 프로세스들 사이의 일대일 또는 그룹 통신 개발에 적용할 수 있는 다양한 API와 메시진 전달 프로토콜을 정의하고 있다. 이상의 Netty, Apache MINA, Grizzly 프로젝트와 MPI에서 제공하는 API는 주로 소켓 관리와 메시지 입출력 관련 기능들이고, 이들을 사용하는 애플리케이션의 플랫폼 환경은 고려하고 있지 않다. 최근의 모바일 환경을 타겟으로 하는 통신 미들웨어 연구들^[18,19]은 대규모 모바일 노드들의 연결 관리나 애드혹 네트워크에서 노드간의 연결 관리 등 모바일 플랫폼에 특화된 통신 서비스 연구를 진행했다.

기존 연구 분석 내용을 요약하면, 대부분의 프레임워크나 미들웨어에서 애플리케이션의 플랫폼 특성에 대한 언급은 하고 있지 않다. 이는 타겟 애플리케이션의 플랫폼이 동일한 환경이어서 문제가 없거나, 이기종 플랫폼 환경에서의 애플리케이션 개발을 고려하지 않았기 때문으로 보인다. 하지만, 일반적인 데스크탑 애플리케이션 개발 환경과 안드로이드 같은 모바일 플랫폼에서의 애플리케이션 개발 환경이 다르기 때문에, 애플리케이션이 프레임워크나 미들웨어를 이기종 플랫폼에서 적용하기 어려운 문제가 생길 수 있으며, 이러한 문제는 본 연구의 이전 연구인 CM을 통해 이후에 살펴보고, 해결 방안은 본 논문의 CM 개선 방안 및 적용 결과를 통해 살펴보도록 한다. 다음 장에서는 먼저 기존 CM의 기본 모델과 애플리케이션 적용 절차를 기술한다.

3. 통신 프레임워크 (CM) 개요

통신 프레임워크(CM)^[3,4]는 클라이언트-서버 기반의 분산 애플리케이션 개발에 필요한 다양한 통신 서비스를 지원한다. CM의 주된 목적은 애플리케이션 개발자가 통신 기능을 구현하는 노력을 최소화하고, 애플리케이션 서비스 자체 개발 효율을 높이는 것이다. CM을 이용하면, 클라이언트 및 서버 개발자는 클라이언트와 서버 사이의 통신 기능을 직접 구현할 필요가 없고, 적절한 CM 응용 프로그래밍 인터페이스(API)를 호출함으로써 필요한 기능을 이용할 수 있다. CM은 많은 분산 애플리케이션들이 공통으로 필요로 하는 통신 서비스를 제공한다. 예를 들어, 로그인 서비스를 통한 사용자 인증, 텍스트 (채팅 등) 메시지 또는 사용자 정의 메시지 송수신, 파일 전송, 소셜 네트워크 서비스 (이미지 및 텍스트 컨텐츠 업로드 및 다운로드, 게시물 공개 범위 설정, 친구 관리 등), 네트워크 상태 모니터링 등이 있다. 그림. 1은 CM의 사용 여부에 따라 클라이언트와 서버에서 로그인 기능을 추가하기 위해 개발해야 하는 사항을 비교한 것이다. CM을 이용하면, 애플리케이션은 통신 서비스의 요청과 이의 결과에 대한 처리 등 서비스를 이용하기만 하면 되기 때문에, 클라이언트-서버 애플리케이션의 통신 기능 개발 속도가 빠르고 프로토타입 개발 등에 쉽게 적용할 수 있다. CM을 이용하지 않으면 애플리케이션 개발자는 통신 서비스를 이용하기 위해 개발까지 부담해야 한다.

CM 서비스를 이용하는 애플리케이션은 클라이언트와 서버로 역할이 구분되고, 각 역할에 따라 사용할 수 있는 CM 서비스도 차이가 있다. 하지만, 애플리케이션 역할과 상관없이 CM을 사용하기 위해 필요한 절차는 동일하다. 본 논문에서는 클라이언트가 CM을 사용하는 경우를 중점적으로 다룬다.

모바일 (안드로이드) 클라이언트가 CM 서비스를 사용하는 경우를 고려하기 전에, 먼저 기존의 데스크탑 클라이언트가 CM 서비스를 사용하는 방법에 대해 살펴본다. 클라이언트가 다양한 CM 서비스를 사용하려면 서버에 로그인을 해야 한다. (로그인 자체도 CM 서비스이다.) 데스크탑 클라이언트 개발자가 CM을 이용하여 서버에 로그인하기까지 필요한 전체 작업은 아래와 같다.

(1) 클라이언트 홈 디렉토리 내에 CM 라이브러리(cm.jar)와 설정파일(cm-client.conf) 놓기

(2) 클라이언트 설정 파일에서 연결할 서버 주소(SERVER_ ADDR)와 포트번호(SERVER_PORT) 필드 값 저장

(3) 클라이언트 설정 파일에서 CM이 수신한 파일을 저장할 디렉토리 경로 저장

(4) CM 이벤트 핸들러 클래스 작성

(5) 클라이언트 클래스 내에서 CM 클라이언트 스텁 객체 생성

(6) 클라이언트 이벤트 핸들러 객체 생성 및 CM에 등록

(7) CM 초기화 및 시작

(8) CM 로그인 서비스 호출

클라이언트는 CM 서비스를 사용하기 전에 다음의 두 가지 종류의 작업이 필요하다. 1-3번 과정은 CM 객체를 생성하기 전에 설정 파일을 관리하는 태스크이고, 4-7번 과정은 CM 서비스를 사용하기 전에 필요한 프로그래밍 태스크이다. 클라이언트는 8번 과정에서 서버에 로그인을 성공하면, 이제 모든 CM 서비스를 사용할 수 있게 된다.

1번 과정에서 CM 설정 파일이 클라이언트의 홈 디렉토리에 있기 때문에, 클라이언트가 CM을 초기화할 때 현재 디렉토리에서 바로 설정 파일을 액세스할 수 있다. 클라이언트 CM의 설정파일에는 연결할 서버 주소, 포트번호, 파일 전송 서비스 옵션 등 CM 구동 초기에 필요한 설정 정보를 포함하고 있고, CM 초기화시에 이 설정 파일 내용을 참조하도록 구성되어 있다. 2번 과정에서 클라이언트는 연결할 서버의 주소와 포트 번호를 미리 설정 파일을 편집해서 저장해 놓는다. CM은 초기화할 때 이 정보를 읽어서 바로 해당 서버에 접속을 시도한다. 3번 과정에서 클라이언트는 CM 파일 전송 서비스를 이용해서 파일을 수신할 때 수신된 파일을 저장할 디렉토리 경로를 설정 파일 편집을 통해 저장할 수 있다. 기본 디렉토리 경로는 “./client-file-path”이다. 즉, 클라이언트가 실행되는 홈 디렉토리 아래 client-file-path 서브 디렉토리에 수신된 파일이 저장된다. 기본 디렉토리 경로를 그대로 이용한다면 이 과정은 생략할 수 있다. 4번 과정에서 이벤트 핸들러를 작성하는 이유는 서버가 전송하는 CM 이벤트를 비동기적으로 수신하기 위해서이다. 개발자는 애플리케이션의 이벤트 핸들러 클래스를 CM의 CMEvent- Handler 인터페이스를 이용하여 구현해야 하고, 이를 위해 이 인터페이스에 정의된 processEvent( ) 메소드를 구현하면 된다. 클라이언트가 관심있는 CM 이벤트를 수신했을 때 필요한 작업을 processEvent( ) 내에 구현하는 것이다. CM은 이벤트를 수신하면 processEvent( )를 콜백 형태로 호출하여 클라이언트로 전달한다. 5번 과정에서 CM 클라이언트 스텁 객체를 생성한 후에, 클라이언트는 이 스텁 객체만을 통해 CM에 모든 태스크를 요청한다. 6번 과정에서 클라이언트는 자신의 이벤트 핸들러를 CM에 등록해야, CM이 수신한 이벤트를 비동기적으로 전달 받을 수 있다. 7번 과정에서 클라이언트가 CM을 초기화하면, CM은 초기화에 필요한 정보를 설정 파일로부터 로드하고 초기화 작업을 수행한다. CM이 시작되면 내부 스레드들이 실행되어 각자의 작업을 동시적으로 수행한다. 8번 과정에서 클라이언트가 CM의 로그인 서비스를 요청해서 성공하면, 이후 모든 CM 서비스를 이용할 수 있다. 그림. 2는 데스크탑 플랫폼에서 클라이언트가 CM 서비스를 이용하는 과정을 (1 ~ 8) 도식화했다.

CM의 초기화 작업은 CM 내부 관리자 모듈들을 초기화하는 작업이고, CM을 시작하는 작업은 CM 내부 스레드들을 실행시키는 것을 의미한다. 구체적인 과정은 다음과 같다.

(1) 스레드풀 초기화

(2) 설정 관리자 (CMConfigurator 클래스) 초기화

(3) 인터랙션 관리자 (CMInteractionManager 클래스) 초기화

(4) 프로세싱 스레드 실행

(5) 수신 스레드 실행

(6) 송신 스레드 실행

1번 과정에서 스레드풀 초기화를 통해, CM은 파일 전송 같은 태스크를 비동기적으로 수행하기 위해 스레드풀을 이용한다. 2번 과정에서 설정 관리자는 CM 설정 파일의 내용을 로드한다. 3번 과정에서 인터랙션 관리자는 CM의 모든 나머지 초기화 작업을 수행한다. CM은 초기화 작업을 완료한 후에, 4-6번 과정에서 스레드를 실행함으로써 동작을 시작한다.

이벤트 기반의 비동기식 통신 방식을 지원하기 위해, 그림. 3과 같이 CM은 다중 스레드(메인 스레드, 프로세싱 스레드, 송신 스레드, 수신 스레드)로 실행된다. 애플리케이션의 메인 스레드가 CM을 구동하면 CM에서 프로세싱 스레드, 송신 스레드 및 수신 스레드를 시작한다. 메인스레드는 애플리케이션 사용자로부터의 로컬 이벤트 처리를 담당한다. 프로세싱 스레드는 수신 스레드로부터 수신된 CM 이벤트를 전달받아 처리하는 역할을 담당한다. CM 이벤트의 처리는 CM이 내부적으로 처리하는 경우와 애플리케이션이 처리하는 두 가지 경우로 나누어진다. 애플리케이션이 CM 이벤트를 처리하기 위해서는 우선 이벤트 처리 메소드를 포함한 이벤트 핸들러 객체를 CM에 등록한다. 프로세싱 스레드는 필요한 경우에 수신한 CM 이벤트를 먼저 CM 내부적으로 처리한 후, 애플리케이션 이벤트 핸들러의 이벤트 처리 메소드를 호출함으로써 애플리케이션이 필요한 별도의 수신 이벤트 처리가 가능하다.

송신 스레드는 메인 스레드나 프로세싱 스레드가 작성한 CM 이벤트를 바이트 메시지로 변환하여 네트워크로 전송하는 역할을 담당한다. 메인 스레드나 프로세싱 스레드는 원격 노드로 메시지를 전송해야할 때, 필요한 CM이벤트를 작성하여 이를 송신 큐에 넣어서 송신 스레드로 전달한다. 수신 스레드는 네트워크에서 바이트 메시지를 수신하여 이를 CM이벤트로 변환하여 프로세싱 스레드로 전달하는 역할을 담당한다. 수신 스레드는 수신한 CM 이벤트를 수신 큐에 넣고, 프로세싱 스레드가 이를 전달받아 처리하게 된다.

4. 안드로이드 플랫폼 지원을 위한 고려사항

CM 클라이언트의 환경을 데스크탑 플랫폼에서 안드로이드 같은 모바일 플랫폼으로 변경하기 위해서, 기존 CM이 개선되어야 하는 부분은 크게 세 가지이다. 그림. 4와 같이, 데스크탑 클라이언트 환경을 그대로 안드로이드 환경에 적용하면 데스크탑과 안드로이드 플랫폼의 차이로 인해 CM 설정파일 관리, 수신 파일 저장 디렉토리 경로, 메인스레드에서의 네트워크 메소드 호출 문제 때문에 모바일 클라이언트에서 CM을 그대로 사용할 수 없다. 모바일 클라이언트를 지원하기 위해 CM이 개선되어야 하는 구체적인 사항은 다음과 같다.

데스크탑 클라이언트에서는 CM 설정파일 (cm-client.conf)을 클라이언트가 실행되는 홈 디렉토리와 동일한 디렉토리에 두기 때문에 클라이언트가 설정 파일 위치를 따로 설정할 필요가 없다. 또한, 클라이언트가 연결할 서버 주소 정보 등 설정 파일 내용을 변경하고자 할 때, 바로 텍스트 편집기 등으로 직접 편집이 가능하다. 반면에 안드로이드 클라이언트의 경우, 안드로이드 디바이스에 설치되는 클라이언트 apk 파일 내에 CM 라이브러리 및 설정 파일이 모두 포함되어 있어야 한다. 안드로이드 디바이스에 설치된 후, 클라이언트 실행위치와 설정 파일의 실행 위치가 달라지기 때문에 클라이언트가 CM을 통해 설정 파일 위치를 설정하는 수단이 필요하다.

안드로이드 애플리케이션은 하나의 패키지 파일인 apk 파일로 배포된다. CM 설정 파일 역시 클라이언트 apk 파일 내에 같이 패키징 되어 있기 때문에, 사용자가 클라이언트 실행 전에 설정 파일의 내용을 변경하고 싶을 때, 이를 직접 편집할 수 없다. 설정 파일을 직접 편집할 수 있게 하려면, 개발자는 클라이언트 apk 파일과 별도로 설정 파일을 제공해야 하며, 이럴 경우 CM 서비스의 사용 및 관리가 비효율적일 수 밖에 없다. 따라서, apk 파일내의 CM 설정 파일 수정이 가능하도록 추가적인 CM 서비스 제공이 필요하다.

데스크탑 클라이언트에서는 수신되는 파일의 기본 디렉토리 경로명이 현재 클라이언트 실행 디렉토리 아래로 (./client-file-path) CM 설정 파일내에 FILE_PATH 필드값으로 설정되어 있다. 클라이언트가 수신하는 모든 파일은 이 디렉토리 내에 저장된다. 안드로이드 클라이언트는 디바이스와 운영체제의 특성상 데스크탑 클라이언트에서 설정한 수신 파일 저장 디렉토리 경로를 그대로 사용할 수 없고, 안드로이드 디바이스의 내부 또는 외부 저장소 내에 별도로 디렉토리 경로명을 지정해야 한다. 따라서, 안드로이드 클라이언트는 CM 서비스를 시작하기 전에 CM 설정 파일을 편집하여 특정 수신 파일 저장 디렉토리 경로를 변경 및 저장하는 절차가 필요하다.

안드로이드 앱을 개발할 때, 안드로이드 정책에 의해 Main Activity (메인) 스레드에서 네트워크 관련 메소드를 직접 호출할 수 없다. 앱의 메인 스레드는 사용자 인터페이스(UI)로부터의 이벤트를 지속적으로 처리해야 하는데, 네트워크 메소드를 호출해서 스레드가 오래동안 블록되면 사용자 인터페이스(UI)의 업데이트도 지연되는 문제가 발생하기 때문이다. 안드로이드 앱의 메인 스레드가 CM 서비스 API를 호출할 때, 이전 버전 CM에서 문제가 되는 부분은 통신 채널을 추가하거나 삭제하는 서비스를 요청했을 때이다. 또한 클라이언트가 처음에 CM을 시작할 때, CM의 초기화 과정중에 기본 통신 채널을 추가하는 작업이 포함되어 있다. 즉, CM의 초기화 작업과 채널 추가 또는 삭제 서비스는 안드로이드 메인 스레드에서 바로 요청하지 못하고 별도의 스레드에서 처리되어야 한다. 클라이언트와 서버 사이에 CM 이벤트를 송수신하는 서비스도 네트워크 메소드를 사용하지만, 이벤트 송수신 태스크는 이미 CM 내의 송신 및 수신 전용 스레드를 통해 처리되기 때문에 문제가 되지 않는다.

5. CM 개선

이번 장에서는 이전 장에서 기술한 설계 고려사항을 반영하여, CM이 모바일 클라이언트 개발을 지원하기 위해 어떻게 개선되었는지 자세히 기술한다. CM이 수정된 부분은 설정 파일 경로 관리, 설정 파일 편집 및 저장 서비스 추가, 전송 파일 저장 경로 변경 서비스 추가, 스텁 모듈의 네트워크 관련 API 수정으로 구분된다.

CM은 Eclipse IDE에서 Java를 (jdk 1.8.0_181) 이용하여 라이브러리 파일로 (cm.jar) 개발되었다. CM을 이용한 안드로이드 클라이언트는 안드로이드 스튜디오에서 (3.2.1 버전) Java 8을 지원하는 안드로이드 SDK 버전 26 (안드로이드 8.0) 이상에서 개발되었다.

안드로이드 클라이언트 앱의 패키지 파일 안에 CM 설정 파일을 포함시키기 위해, 개발툴인 안드로이드 스튜디오의 프로젝트 폴더에 assets 폴더를 추가하고 여기에 설정파일을 복사해 둔다. 단, asset 폴더에 있는 파일은 수정이 안되기 때문에, 클라이언트에서 설정 파일을 수정하기 위해서는 클라이언트가 asset 안의 설정 파일을 안드로이드 내부 스토리지로 복사하는 과정이 필요하다. 그리고, 복사된 설정 파일의 경로를 CM에 알려주기 위해 다음과 같이 CM을 수정했다. 애플리케이션이 CM 사용 전에 설정 파일을 임의의 위치에 둘 수 있도록 CMStub 클래스에 setConfigurationHome(Path filePath) 메소드를 추가했다. 이 메소드의 파라미터(filePath)는 설정 파일의 경로이며, CM은 설정 파일 정보를 관리하는 CMConfigurationInfo 클래스 내에 이 경로값을 추가한다. 설정 파일 기본 위치는 클라이언트의 기본 실행 디렉토리라서 설정 파일을 해당 디렉토리에 두면 별도의 경로 지정이 필요없지만, 안드로이드 환경에서는 내부 스토리지나 다른 가능한 디렉토리에 설정 파일을 두고 이 경로를 CM에 등록하는 것이다. 설정 파일의 경로를 반환하기 위해 CMStub에 getConfigurationHome( ) 메소드도 추가했다. CM은 초기화 때 설정 파일 경로를 참조하여 설정 파일 내의 필드 값을 사용해야 하기 때문에, 클라이언트는 CM을 초기화하기 전에 setConfigurationHome( ) 메소드로 설정 파일 경로를 지정해야 한다.

CM의 안드로이드 클라이언트 앱은 apk 파일 안에 CM 설정 파일이 포함되어 있기 때문에 사용자가 이 파일에 직접 액세스할 수 없다. 따라서, 설정 파일 내의 필드값 수정이 가능하도록, CMConfigurator 클래스에 changeConfiguration(String confFilePath, String field, String value) 메소드를 추가했다. 이 메소드는 설정 파일 내의 특정 필드값을 새로운 값으로 변경하고 설정 파일을 저장해준다. 첫번째 파라미터(confFilePath)는 설정 파일의 경로, 두번째 파라미터(field)는 수정하고자 하는 필드명, 마지막 파라미터(value)는 해당 필드의 새로운 값을 나타낸다.

클라이언트 CM 설정 파일의 필드 중에서 실제 가장 많이 사용하는 것은 서버의 주소(SERVER_ADDR)와 포트번호(SERVER_ PORT) 값이다. 클라이언트가 실행 전에 연결할 서버 정보를 설정 파일에 저장할 때 직접 changeConfiguration() 메소드를 호출할 수 있다. 하지만, 이 메소드는 설정 파일을 관리하는 일반적인 메소드라서 CMConfigurator 클래스의 멤버 메소드로 추가한 것이고, 대신 클라이언트 애플리케이션에서 직접 액세스하는 CMClientStub 클래스에는 좀더 편하게 호출할 수 있도록 setServerAddress(String addr)와 setServerPort(int port) 메소드를 추가했다. 이 두 메소드는 내부적으로 changeConfiguration( ) 메소드를 호출하여 서버 주소와 포트번호를 설정 파일에 저장한다. 클라이언트가 이전 실행에서 연결했던 서버 주소 정보를 확인할 수 있도록, CMClientStub 클래스에 getServerAddress( )와 getServerPort( ) 메소드도 추가했다. 이 두 메소드 역시 설정 파일로부터 서버 주소와 포트번호를 각각 반환한다.

CM이 원격 노드로부터 수신한 파일을 저장할 디렉토리 경로는 CM 설정파일의 FILE_PATH 필드 값으로 설정한다. 안드로이드 플랫폼은 데스크탑 환경과 다르기 때문에, 기본 필드값인 “./client-path” 경로를 사용할 수 없다. 대신, 클라이언트는 안드로이드의 외부 스토리지에 CM이 수신한 파일을 저장할 수 있다. 이를 위해, CMClientStub 클래스에 setTransferedFileHome(Path dir) 메소드를 추가했다. 파라미터(dir)는 클라이언트가 수신한 파일을 안드로이드 디바이스 내에 저장할 디렉토리 경로이다. 이 메소드도 설정 파일의 필드를 변경하기 때문에 위에서 언급한 changeConfiguration() 메소드를 호출해서 사용한다.

안드로이드 클라이언트는 CM 서비스를 이용하기 위해, 애플리케이션 메인 스레드에서 CM 서비스 API를 호출한다. CM 메소드 중에서 안드로이드 메인 스레드에서 호출되는 네트워크 관련 메소드는 별도 스레드에서 실행하기 위해, 자바의 Executor- Service 인터페이스와 Executors 클래스를 통해 제공하는 스레드풀 서비스를 이용하여 네트워크 관련 메소드 실행을 요청하도록 수정한다. CM에서는 이미 이 스레드풀 기능을 파일 전송 서비스에 사용하고 있는데, 이를 확장하여 CMClientStub의 API 중 메인 스레드에서 네트워크 관련 메소드를 호출하는 서비스를 수정 대상으로 한다(표 1 참조). 수정 대상 메소드들은 모두 통신 채널 관련 태스크(open/close/connect)를 수행하는 메소드들이다. 수정 메소드 중에서 startCM() 메소드에서 스레드풀 객체를 생성하여 등록한 후, 별도 스레드의 필요가 있을 때마다 이 풀에 비동기 태스크를 요청한다. CM은 이러한 각 태스크를 별도의 스레드에서 수행하도록 Callable 클래스로 재정의하여 스레드풀 객체로 실행 요청한다. 기존의 스레드 태스크를 정의하는 Runnable 클래스 대신, Callable 클래스를 사용하면 태스크 실행 결과를 반환받을 수 있다. 태스크 처리 결과는 요청한 메인 스레드에서 Future 객체를 통해 동기식으로 반환받아서 다음 태스크를 순차적으로 처리할 수 있도록 한다. 현재, 메인 스레드에서 호출하는 네트워크 관련 메소드들은 많은 시간을 필요로 하지 않기 때문에 스레드풀 작업 결과를 동기식으로 받는 것에 큰 문제는 없다.

표 2는 개선된 CM을 사용하는 경우와 이전 CM을 사용하는 경우 개발 과정에서의 일관성과 효율성 비교를 위해, 하나의 예로써 클라이언트 개발자가 데스크탑 플랫폼과 안드로이드 플랫폼에서 각각 CM을 구동하기 위해 클라이언트 내에서 startCM() 메소드를 호출하는 코드를 나타낸 것이다. 이전 CM을 안드로이드 플랫폼에 적용하려면 클라이언트에서 네트워크 메소드를 호출할 때마다 별도 스레드를 추가하여 그 스레드 내에서 메소드를 호출하고 리턴값을 확인해야하기 때문에 데스크탑 환경에서의 개발과 비교했을 때 CM 서비스 사용의 일관성도 깨지고 비효율적인 코드가 된다. 반면에, 개선된 CM에서는 안드로이드 환경에서도 데스크탑 환경에서와 동일하게 CM 메소드를 바로 호출하면 된다.

개선된 CM은 내부적으로 스레드 관리가 추가로 필요하기 때문에 이에 대한 비용을 기존 CM과 비교하기 위해, 클라이언트가 CM을 초기화하는데 걸리는 지연 시간도 측정했다. 측정 결과, 평균 지연 시간의 차이는 1밀리초 이내이기 때문에 개선된 CM에서 스레드 관리로 인해 추가된 비용은 무시할만한 수준이라고 할 수 있다. 단지, 개선된 CM은 기존 CM과 비교했을 때 초기화 과정이 평소보다 10배 이상(약 200 밀리초) 오래 걸리는 횟수가 약간 증가했다.

6. 개선된 CM을 이용한 안드로이드 클라이언트 개발

개선된 CM을 이용하여 안드로이드 플랫폼에서 클라이언트를 개발하는 절차가 기존 CM으로 데스크탑 클라이언트를 개발하는 절차와 가장 큰 차이점은 다음과 같다. 기존 데스크탑 클라이언트 개발 과정에서 개발자는 CM 설정 파일의 필드값 설정을 위해, 파일을 직접 편집하고 저장해야 했다. 개선된 CM으로 안드로이드 클라이언트를 개발하는 개발자는 CM 설정 파일을 준비하는 태스크를 포함하여 CM을 이용하는 모든 과정을 CM API를 통해 수행하도록 일원화했다. 안드로이드 클라이언트에서 CM 서비스를 이용하기 위한 구체적인 준비 절차는 다음과 같다(그림. 5 참조).

(1) CM 이벤트 핸들러 클래스 작성

(2) 클라이언트 클래스 내에서 CM 클라이언트 스텁 객체 생성

(3) 클라이언트 이벤트 핸들러 객체 생성 및 CM에 등록

(4) 안드로이드 내부 스토리지에 설정 파일이 없으면 Asset으로부터 복사하고, CM을 통해 현재 설정 파일 경로를 설정

(5) CM을 통해 수신 파일 저장 경로를 안드로이드 외부 스토리지로 설정하고 이를 설정 파일에 저장

(6) 연결할 서버 주소(SERVER_ADDR)와 포트번호(SERVER_ PORT) 필드 값을 CM을 통해 설정 파일에 저장

(7) CM 초기화 및 시작

(8) CM 로그인 서비스 호출

1번 과정에서 개발자는 우선 CM 이벤트를 비동기적으로 수신할 이벤트 핸들러 클래스를 작성한다. 이후의 모든 작업은 CM API를 사용하기 때문에, 2번 과정에서 CM 클라이언트 스텁 객체 생성 코드를 우선 작성한다. 3번에서 6번 과정은 CM을 시작하기 전에 필요한 태스크들로써, 이벤트 핸들러 등록, 설정 파일 경로 등록, 설정 파일 내의 수신 파일 저장 경로 및 서버 정보 설정의 모든 태스크를 CM 스텁 객체를 통해 수행한다. 특히, 4번 과정에서 CM 설정 파일의 경로는 안드로이드 내부 스토리지로 설정하여, 설정 파일을 CM 클라이언트에서만 접근 및 수정이 가능하도록 하였다. 또한, 5번 과정에서 수신 파일 저장 디렉토리 경로를 안드로이드 외부 스토리지로 설정하여, 클라이언트가 수신한 파일을 다른 앱에서도 사용할 수 있도록 하였다. 7번 과정에서 CM이 초기화될 때, 네트워크 관련 메소드는 메인 스레드가 아닌 스레드풀의 별도 스레드를 이용하여 호출한다. 안드로이드 클라이언트 CM 서비스 사용 준비 과정을 코드 레벨로 기술하면 표 3과 같다.

CM을 이용하여 애플리케이션을 개발할 때 중요한 점은, 애플리케이션이 실행되는 플랫폼에 상관없이 CM 이용 절차를 일관되게 유지하는 것이다. 개선된 CM을 사용하는 애플리케이션은 데스크탑 플랫폼과 안드로이드 플랫폼에 상관없이 위에 제시한 일관된 절차를 통해 CM 서비스를 사용할 수 있다. 데스크탑 클라이언트의 경우, CM 설정 파일 경로와 수신 파일 저장 디렉토리 경로를 기본 값으로 이용하려면 4번과 5번 과정은 생략할 수 있다. 기존 CM과 개선된 CM을 단계별로 비교하면, 4번 과정은 기존 CM에서 지원하지 않기 때문에 개발자가 CM 설정 파일의 위치를 변경할 수 없었다. 설정 파일의 내용을 변경하는 5번 및 6번 과정의 경우, 기존 CM에서는 개발자 또는 사용자가 직접 설정 파일을 편집해야 했다. 개선된 CM에서는 직접 편집뿐만 아니라 CM API를 통해 임의의 필드값을 변경하도록 지원하기 때문에, 안드로이드 같이 직접 설정 파일을 액세스하지 못하는 환경에서도 관리가 가능해졌다. 설정 파일에 등록된 서버 주소 정보를 변경할 필요가 없는 클라이언트는 개발 플랫폼과 상관없이 6번 과정도 생략이 가능하다. 7번 과정에서 기존 CM은 모든 초기화 과정을 현재 스레드에서 수행하기 때문에 안드로이드 환경에서 CM을 시작하기 위해서는 애플리케이션에서 직접 별도 스레드를 생성하여 CM 시작 메소드를 호출해야 했다. 개선된 CM에서는 플랫폼에 상관없이 CM 시작 메소드를 그대로 호출하면 된다. 그림. 6은 일관된 절차를 통해 개발된 CM 데스크탑 클라이언트와 안드로이드 클라이언트가 서버에 로그인하여 통신하는 예를 보여준다.

7. 결 론

본 논문에서는 데스크탑 플랫폼과 모바일 플랫폼에서 클라이언트-서버 애플리케이션 개발을 모두 지원하는 통신 프레임워크(CM)를 제안했다. 본 논문의 주안점은 이기종 플랫폼에서 실행되는 클라이언트가 CM의 하이레벨 통신 서비스를 본격적으로 사용하기 전에 클라이언트가 일관된 방법으로 동일하게 CM을 설정할 수 있도록 기존 CM을 개선한 것이다. 클라이언트는 먼저 CM 사용을 준비하기 위해 CM 설정 파일을 편집해야 하고, CM 시작 및 통신 서비스 이용은 API를 호출함으로써 가능하다. 개선된 CM에서는 설정 파일 관리 역시 API를 통해 가능하기 때문에, 안드로이드 같이 설정 파일을 직접 액세스하기 어려운 환경에서도 CM 설정이 가능하다. 또한, 클라이언트는 안드로이드 환경에서 네트워크 메소드를 필요로 하는 CM API를 별도 스레드를 생성해서 호출할 필요없이 데스크탑 플랫폼에서와 같이 그대로 호출할 수 있다. 플랫폼에 상관없이 일관된 애플리케이션 개발 환경을 제공함으로써, 이기종 플랫폼에서 CM의 활용 범위가 향상되었다.

향후 연구에서는, CM 적용 범위를 데스크탑 및 모바일 플랫폼에서 웹 환경으로 확장하는 방안을 연구할 계획이다. 이 때, 웹 브라우져가 클라이언트 역할을 수행하며, 서버 CM은 웹서버와 통합할 방안이 필요하다. 웹 클라이언트에서 서버 CM의 서비스를 이용할 수 있도록, 현재의 CM API를 웹서비스로 제공할 수 있어야 한다. 현재의 서버 CM은 로긴한 클라이언트와의 연결을 유지하는 stateful 서버인데, 웹 환경을 지원하기 위해서는 클라이언트의 연결을 세션 단위로 관리하는 stateless 서버 기능이 필요하다. CM의 최종 목표는 다양한 플랫폼의 클라이언트와 서버가 최소한의 노력으로 상호작용이 가능한 범용 서비스를 제공하는 것이다.