이미지 기반과 벡터 기반 지도 서비스의 적용 범위

이 글은 지도 서비스 방법으로 이미지 방식과 벡터 방식에 대한 장단점과 이런 장단점으로 인해 각각의 적당한 적용분야에 대한 개인적인 생각을 써본 글입니다.

초기 지도 서비스는 서버에서 클라이언트로 데이터를 전송해줄 때 좌표를 던져줌으로써 이 좌표를 이용해 지도를 화면상에 그려냈습니다. GIS의 초창기에는 이런 벡터 방식이 주류를 이루었으나, 지금은  이미 만들어 준비된 지도 이미지를 서버가 클라이언트에게 던져주고, 클라이언트는 이 이미지를 화면에 뿌려주는 방식이 대세가 되었습니다. 구글맵이 그렇고.. 콩나물, 네이버, 다음, 야후, MS 등등, 모두가 이미지 방식입니다. 그렇다면 이유는 무엇일까요?

  1. 속도가 빠르다.
  2. 클라이언트 개발이 간편하다.
  3. 클라이언트에 별도의 프록그램 설치(특히 말도 탈도 많다는 ActiveX)가 필요없다.
  4. Web2.0(특히 AJAX 기술)의 트렌드를 충족시킨다.

가장 중요한 것이… 이미지 기반은 벡터 기반에 비해 속도가 빠릅니다. 속도라 함은 클라이언트가 보고자 하는 지역의 좌표(MBR)를 넘겨주면 서버가 해당 지역에 대한 데이터를 찾아 전송해주고 클라이언트가 화면상에 그려주는데까지 얼마나 빨리 처리할 수 있느냐입니다. 벡터 기반의 경우 이런 처리에 대한 전체 흐름은 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역의 데이터를 수집하는데, 데이터는 복잡한 공간검색(R-Tree나 Grid-File과 같은 공간검색 알고리즘 이용)을 사용하며 이 검색 방식은 많은 시간이 소모된다.
  3. 서버는 수집한 데이터를 클라이언트로 빠르게 전송하기 위해 데이터의 크기를 줄일 목적으로 데이터를 압축한다.
  4. 서버가 보낸 데이터가 압축되었다면 클라이언트는 받은 데이터를 압축해제 한다.
  5. 클라이언트는 받은 데이터(좌표, 속성 등)를 이용하고 지도 이미지를 직접 만들어 그린다.
  6. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

다음으로 이미지 기반의 처리 과정을 살펴보면 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역에 대한 이미지를 찾는데, 해당되는 지역에 대한 파일의 찾기는 매우 단순하며 빠른다.
  3. 서버는 이미지를 바로 클라이언트로 전송한다.
  4. 클라이언트는 받은 이미지를 바로 그린다.
  5. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

처리 과정만을 살펴보더라도 벡터 기반에 비해 이미지 기반의 지도 서비스가 당연히 빠를 수 밖에 없다는 것을 알수 있지요.

그렇다면 이처럼 성능 좋은 이미지 기반의 지도 서비스가 아닌 벡터 기반의 서비스가 할 수 있는 기능은 무엇일까요..? 즉, 이미지 기반의 지도 서비스에서는 불가능한, 아니 매우 어려운 기능은 무엇일까요?

  1. 새로운 건물이 생겼을 때나 형태가 변경되었을 경우, 클라이언트에서 지도 편집
  2. 화면상에 표시된 지도에서 원하는 건물을 찍어 그 건물의 상세 내용을 살펴보는 기능
  3. 플롯터와 같은 출력기를 통해 큰 용지(A4 이상)에서 높은 품질의 지도 출력하기
  4. 건물을 제외하고 도로만을 화면상에 보는 것과 같은 원하는 지도 스타일 만들기.
  5. 건물 전용면적이 200평방 이상인 건물만을 화면상에 표시하여 지도 보기.
  6. 지도의 특정 주제를 가지는 요소 그룹을 사용자가 원하는 색상이나 형태로 표시하는 기능.
  7. 등등…

위의 기능이 왜 이미지 기반에서는 거의 불가능하고 벡터 기반에서는 가능한 이유는 무엇일까요? 그것은 단지 현재 보이는 지도에 대한 정보를 이미지 기반은 “이미지”로써만 가지고 있기 때문입니다. 이에 반해 벡터 기반은 지도에 대한 실제 정보로써 “지도 좌표”를 가지고 있다는 점입니다.

이러한 이미지 기반과 벡터 기반의 서로간의 장단점을 놓고 볼때.. 이미지 기반은 클라이언트 PC에 별도의 프로그램 설치 없이 원하는 지역을 빠르게 보여주는 서비스에 적당하며, 벡터 기반은 사용자가 원하는 지역에 대해서 좀더 다양한 기능, 즉 이미지 기반이 제공할 수 없는 기능, 좀더 전문적으로 말해 지도를 좀더 높은 수준에서 활용하고 응용하는 영역, GIS에 적당하다고 할 수 있습니다.

왠,,,, 메모리릭,,, @_@;

실행시에 실행되지도 않는 코드인데, 이 코드가 들어가면 메모리 누수가 발생합니다. 허걱… @_@;; 이 코드를 빼고 컴파일하고 실행하면 누수가 발생하지 않습니다. 분명 이 코드가 실행되지 않아도, 이 코드를 넣고 컴파일 했다는 이유 하나만으로 메모리 누수가 발생합니다. 누구 크기는 1Byte. 개발툴의 메모리 누수 탐지기의 버그로 판단하고 패스… 이것 원인 규명하려고 낭비한 시간이 다소 아깝습니다.

아.. 회사에서 개발자를 구합니다. 기반기술팀의 구성원으로써, 개발에 대한 남다른 열정을 가진 분으로…. 조만간에 구체적으로 글을 올릴 생각입니다.

간단한 예로 살펴본, OpenMP

필자가 OpenMP이라는 단어를 처음 들었을때는, 보다 안정적인 멀티 스레드 프로그래밍에 대한 갈증이 한창일 때였습니다. XGE 개발 초기에 데이터 요청과 데이터 가시화를 별도의 스레드로 두고, 다시 데이터 요청을 레이어 단위로 나누어 다시 레이어를 별도의 스레드로 분리시켜야할 필요성에서였는데요. 그러다가 찾은 것이 OpenMP 이였습니다. 처음 접하는 기술인지라… 실제 프로젝트에 적용하지 않고 일단 머리속에 북마크만 해 두었지요.

최근에 다시 모 잡지에서 OpenMP라는 단어를 접하게 되었는데, 요즘 CPU가 죄다 듀얼코어니, 쿼드코어니… 얼마후에는 옥타코어와 같이 하나의 CPU가 2개, 4개, 8개의 CPU의 성능을 낼 수 있는 컴퓨팅 환경이고, 이런 컴퓨팅 리소스를 100% 활용하기 위해 병렬 프로세싱, 다중 스레드, 다중 프로세싱 개발 기법을 속속들이 적용하고 있고, 이 기법이라는게 역사라 불리는 시간에서 지금에 이르기까지 존재하는 스레드를 이용한 방법입니다. 여기에 간단히 스레드를 직접 사용하지 않고 간단/명료한, 하지만 아직은 섬세하지는 않는 멀티 프로세싱 방법인 OpenMP라는 기술이 수년전에 나타났는데, 이 글은 간단한 예로 OpenMP를 접해 보도록 하겠습니다.

먼저 고객으로부터 받은 하나의 요청을 예로 OpenMP의 기능을 느껴보는 것이 가장 좋은 접근법 같습니다. 요청은 테일러급수를 이용해 자연로그에서의 e와 파이(3.1415~)를 구하고 이 둘의 값을 합해 보는 것입니다. 왜 이런것이 필요한지는 생각하지 말고 말입니다. ^^; 이 예는 http://www.kallipolis.com/openmp/1.html 의 OpenMP의 Tutorial에서 가져왔음을 명확히 합니다. 위의 문제를 해결하기 위해서는 먼저 e를 구하고 다음으로 phi를 구한후에 마지막으로 e와 phi를 합하면 끝납니다. 모두 3단계로 나눠지는데, 바로 아래와 같이 말입니다.

  1. e를 구한다.
  2. phi를 구한다.
  3. e와 phi를 합한다.

위의 3 단계를 자세히 살펴보면, 3단계는 1단계와 2단계가 반드시 이뤄져야 하지만, 1단계와 2단계는 완전히 서로 독립적이라는 점입니다. 바로 여기서 1단계와 2단계를 2개의 스레드로 분리해 성능을 높일 수 있다는 것일 알 수 있습니다. 2개의 스레드로 분리하는 방법은 직접 개발자가 스레드 API를 사용해서 분리시킬 수 있는 방법과 OpenMP를 사용해서 그 분리 작업을 맡기는 방법이 있습니다. 여기서는 물론~ OpenMP를 사용해 두개의 스레드로 분리해 보겠습니다.

#include "stdafx.h"
#include  
#include  
 
#define num_steps 20000000 

int main(int argc, char *argv[])
{
    double start, stop;
    double e, pi, factorial, product;
    int i;

    start = clock();

    #pragma omp parallel sections num_threads(2)
    {
        #pragma omp section
        {

            printf("e started\n"); // 1. 단계: e구하기
            e = 1;
            factorial = 1;

            for (i = 1; i<num_steps; i++) {
                factorial *= i;
                e += 1.0/factorial;
            }

            printf("e(%lf) done\n", e);
        }

        #pragma omp section
        {
            printf("pi started\n"); // 2. 단계: phi 구하기

            pi = 0;
            for (i = 0; i < num_steps*10; i++) {
                pi += 1.0/(i*4.0 + 1.0);
                pi -= 1.0/(i*4.0 + 3.0);
            }

            pi = pi * 4.0;
            printf("pi(%lf) done\n", pi);
        }
    }
    product = e + pi; // 3. 단계: e와 phi 합하기

    stop = clock();

    printf("Reached result %f in %.3f seconds\n", 
        product, (stop-start)/1000);

    return 0;
}

먼저 살펴 볼 것이 #pragma omp parallel sections num_threads(2)인데, 이 #pragma는 2개의 스레드(num_threads(2))로 실행 구역(section)을 나누겠다는 의미입니다. 그 실행 구역이라는 것이 다름 아닌 e와 phi를 구하는 것인데, 이 실행 구역, 즉 section을 정하는 코드가 바로 다음 코드에 2번 나오는 #pragma section 블럭입니다. 이 블럭은 정확히 e와 phi를 구하는 코드입니다.

여기서 중요한 것은 동기화인데, e와 phi를 계산해서 합하는 것이 최종적인 목표이므로 e의 계산과 phi의 계산이 완전이 완료되어야만 e와 phi를 합할 수가 있다. OpenMP는 #pragma omp parallel sections num_threads를 통해 이 전처리가 규정한 블럭의 코드를 자동으로 동기화 시켜줍니다!! ^^ 와우~

여기서 눈치가 빠른 사람이라면, 위의 코드에서 OpenMP와 관련된 코드를 제거해도 동일한 결과를 낸다는 것입니다. 물론, 싱글 스레드로 돌아가므로  수행 속도는 저하되겠지만 말입니다. 즉, 이를 다시 역으로 생각해보면, 기존에 전혀 멀티 프로세싱을 고려하지 않고 개발된 코드에 대해서 OpenMP를 적절하게 적용하면 큰 코드의 변경 없이도 멀티 프로세싱의 잇점을 추가할 수 있다는 점이겠지요. 필자의 추측으로 OpenMP라는 기술은 아마도… 기존의 싱글 스레드로 작동하는 소프트웨어에 대해서, 멀티코어 CPU의 등장으로 그 하드웨어의 성능을 최대한 끌어내기 위해 등장한 기술로 보입니다.

간단하게 예를 들어 OpenMP를 살펴보았습니다. 이글은 OpenMP의 많은 기능 중에 매우 간단하고 기본적인 예를 든 것입니다. 추후 기회가 된다면 더 많은 OpenMP의 정보를 제공할 수 있도록 하겠습니다. 그때까지 참지 못하겠다면, http://www.kallipolis.com/openmp/index.html 를 참고하길 바랍니다.

Booch and Rumbaugh’s Unified Notation 0.8

UML 탄생 이전에 존재했다고 판단되는, 부치의 Diagram이라고 생각됩니다. 간단하고 명확하며, 특히 개발자에게는 꼭 필요한 내용을 전달하는 좋은 다이어그램 같습니다.


별다른 설명이 없이도 명확합니다. 비록 클래스 관계만을 제시하지만, UML에서 개발자에게 클래스 관계도가 가장 최고의 설계문서 아니겠습니까?

정리하는 차원에서 살펴보면… Base Class를 기준으로하여 .. “Base Class”가(주어) “Used”를 사용하며.. “Had by Reference”와 “Had By Value”를 맴버 변수로 가지고 있는데, 각각 참조(C++에서는 포인터*나 참조형&)으로 가지고 있다는 의미이고 “Derived 1″과 “Derived 2″에 대한 부모 클래스라는 것입니다. 지금의 클래스 관계도(UML에서)를 처음 접하는 초보 사용자에게 있어서 Composition이냐? Aggregation이냐? 라는 애매모한 정의가 없다는 점이 매우 매력적입니다.

한번쯤 숙지해 놓고, 사용해 볼만한 다이어그램이라고 생각됩니다.

사용하기 간단한 Memory Pool 클래스

프로젝트 진행 중에, 다중 스레드에서 사용할 Memory Pool 클래스를 인터넷을 통해 검색해보다가 마땅히 사용만하다 판단되는 것이 없어 직접 만들어 사용하고 있는 클래스입니다. 물론 기존에 공개된 Memory Pool 클래스의 기능이 좋지 않다는 것이 아니라, 제 기준, 수준에 너무 사용하기가 어렵고 복잡하다는 생각에서입니다. 물론 그 기능과 성능은 뛰어나겠지만 말입니다. 이에.. 사용하기 쉽고, 매우 간단하게 적용할 수 있는 메모리풀 클래스를 공개해 봅니다.

먼저 사용 방법은 아래와 같습니다. 전역변수로 CMemoryPool을 생성해 놔야 합니다. 싱글리톤 패턴을 적용해야할테지만.. .일단 적용하지 않았습니다. 다른 분께서 적용해 보시고 공개해주시면 매우 영광이겠습니다.

#include "MemoryPool.h"

CMemoryPool MP(10, 1024*1024);

생성자 중 첫번째 인자는 메모리풀에 생성할 메모리 덩어리의 개수이고 두번째 인자는 메모리 덩어리의 크기입니다. 즉, 여러개의 스레드에서 동시에 10개의 메모리 덩어리를 얻어 사용할 수 있으며, 한 덩어리의 크기가 1메가라는 의미입니다.

메모리 덩어리를 얻어 사용하는 방법은 다음과 같습니다.

CMemoryPool::MEMORY_DESC *pMD = MP.Take();

BYTE *pBuffer = pMD->pBuffer; 

// .
// .
// use memory ..
// .
// .

MP.Release(pMD);

다 사용했으면 최종적으로 Release를 호출해줘서 메모리 풀에 반환해줘야 함을 잊어서는 않됩니다. 아무쪼록…. 저처럼 쉽게 사용할만한 메모리풀 소스 코드를 찾지 못하신 분들에게 도움이 되시길 바랍니다.