다양한 테스트에 대한 이해는 필수

테스트는 정상에 있는 품질목표를 달성하기 위한 등산과 같다. 입구에서 시작해 산등성이를 지나 절벽을 오르면 정상에 도달할 수 있다. 하나하나의 과정을 반드시 이겨내야만 정상에 도달해서 환희, 기쁨, 만족감 등을 맛볼 수 있는 것이다

품질은 기능 품질과 비기능 품질로 나눈다. 기능 품질은 기능성, 작동성, 정합성 등 시스템의 기능을 테스트한다. 단위 테스트, 회귀 테스트, 부정 테스트, 통합 테스트, 크로스 테스트, 제품품질 검사, 인수 테스트, 현장 테스트 등을 기능 테스트로 분류한다. 비기능 품질은 주로 성능, 보안 등 인프라에 대한 품질을 말한다. 성능 테스트, 스트레스 테스트, 볼륨 테스트, 보안 테스트 등을 비기능 테스트로 분류한다.

단위 테스트

단위 테스트는 개발과 동시에 진행하여 개발 기간과 함께 종료한다. 개발자는 설계자가 설계한 대로 코딩을 하고 설계자와 함께 기능의 정확성을 확인한다. 소프트웨어가 작동하는 지 확인하기 위해 신규 또는 변경 코드만 따로 테스트하는 최초의 테스트 단계이며 이를 통해 내부 프로그램과 모듈 로직에 맞추어 프로그램 스펙을 검증하고 나아가 프로그램 로직을 검증한다.

단위 테스트의 검증 단계로 단위 모듈 테스트와 단위 화면 테스트를 수행하고, 모듈 테스트는 단위 모듈의 기본 처리를 검증하는 단계이며, 각 모듈에 구현된 기능의 정확성과 완전성을 검증한다. 화면 테스트의 범위는 단위 화면 내 버튼 기능이 모두 정상임을 확인한다.

회귀 테스트

회귀 테스트는 단위 테스트에서 시작해서 인수 테스트로 끝나는 테스트 전체기간 동안 결함의 추적성을 통제하여 한 번 발생한 결함은 다시 발생하지 않도록 점진적, 반복적으로 수행하는 것이다. 이를 위해 테스트 관리자는 형상관리 툴을 이용하여 단위 테스트, 통합 테스트, 인수 테스트 등 테스트 시 발생한 모든 결함들을 등록하고 반복적 테스트를 통해 기능의 완전성과 정확성을 높여 품질을 보증한다.

부정 테스트

부정 테스트는 사용자의 예기치 못한 조작방법에 대응하기 위해 일반적인 작동 프로세스를 무시하고 테스트 시나리오 없이 기능을 테스트를 하는 것이다. 조회 버튼을 백 번 연속해서 누른다든지 날짜가 들어가는 곳에 문자를 입력하거나 2월 30일과 같이 존재하지 않는 데이터를 입력하는 등 일반적인 사용자가 하지 않는 범위에 대해 테스트를 하는 것이다.

통합 테스트

통합 테스트는 기능 테스트 중 가장 중요하고 반드시 실시해야 하는 필수 테스트다. 어떤 프로젝트팀은 테스트 종류 중 오직 통합 테스트에만 집중하여 모든 결함과 오류를 수정하고 이 데이터를 근거로 오픈에 대한 의사결정을 한다. 통합 테스트 목적은 다음과 같다.

◆ 단위 테스트를 통과한 애플리케이션과 업무 기능의 인터페이스가 정상적으로 작동하는지를 검증한다.

◆ 이를 위해 통합 모듈의 기능, 화면과 연관된 업무 기능, 모듈 간의 인터페이스 검증 테스트 등에 대해 테스트와 평가를 한다.

◆ 고객이 제시한 테스트 시나리오를 바탕으로 하여 실행방법과 예상결과 등을 포함하는 테스트 케이스를 정의하고 그 기준에 의하여 통합 테스트를 진행한다.

◆ 통합 테스트를 위해 정의된 세부적 테스트 케이스가 고객의 테스트 시나리오의 요구조건을 모두 수용해야 하며 각 테스트 케이스의 실행이 예상결과와 일치해야 해당 케이스의 실행이 성공한 것으로 간주한다.

◆ 반드시 데이터 정합성에 대해 테스트를 진행해야 한다.

통합 테스트를 통해 많은 결함이 도출된다. 결함들은 난이도에 따라 분류되어 수정일정과 함께 개발자에게 넘겨진다. 분류는 다음과 같이 할 수 있다.

◆ 치명결함 : 애플리케이션 종료, 시스템 다운, PC 재부팅 등을 하여야 하는 결함

◆ 중결함 : 데이터의 정합성 불일치 또는 해당 업무(기능)을 정상적으로 진행할 수 없는 결함

◆ 경결함 : 일부 오류를 포함하고 있으나 처리가 가능한 결함

◆ 단순결함 : 해당 기능을 수행하는데 문제가 되지 않으나 사용자들의 에러를 유발시킬 수 있거나, 혼동할 수 있는 내용(예 : 불명확한 메시지 처리, 조회필드의 입력가능, 오타, 등)

크로스 테스트

크로스 테스트는 테스트 종류라기보다는 테스트 진행방법 중의 하나이다. 기능 테스트를 실행하는 데 고객에게만 테스트를 맡기지 말고 프로젝트 팀원 전원이 테스트를 함께 참여하여 서로의 것을 테스트하며 많은 결함과 오류를 발견하고자 하는 목적에서 만들어진 것이다. 크로스 테스트의 묘미는 본인이 개발한 것보다 타인이 개발한 프로그램에서 훨씬 많은 결함을 도출해낸다는 것이다.

제품품질 검사

제품품질 검사는 공인된 테스트 전문 업체를 통해 단기간에 개발된 시스템을 전수 검사를 하는 것이다. 품질 체크리스트를 기반으로 4~5명이 참여하여 기능에 대한 테스트를 수행한다. 이 때 투입된 전문가들은 부정 테스트에 대한 개인적 경험을 이용하기도 한다. 테스트 전문가들에 의해 실행되기 때문에 숨겨진 에러까지 발견하곤 한다.

1 GCC(12)에 대해서

GNU C compiler는 GNU system을 이루고 있는 중요한 부분중 하나이며 Richard Stallman에 의해서 만들어졌다. 최초에는 단지 C코드만을 컴파일 할 수 있었기 때문에 GNU C Compiler 로 불리웠었다. 그러던 것이 다른 많은 지원자들에 의해서 C++, Fortran, Ada, Java 등의 컴파일도 지원할 수 있게 되면서 GNU Compiler Collection으로 이름을 변경하게 된다. 이 문서는 단지 C언어코드에 대한 컴파이러로써의 GCC의 사용법에 대해서 다루도록 할 것이다.

GCC는 Linux뿐 만 아니라 FreeBSD, NetBSD, OpenBSD, SunOS, HP-UX, AIX등의 *Nix운영체제 그리고 Cygwin, MingW32의 윈도우환경에서도 사용할 수 있다. 플렛폼 역시 Intel x86, AMD x86-64, Alpha, SPARC 등에서 사용가능 하다. 이러한 다양한 환경에서의 운용가능성 때문에 다양한 플렛폼에서 작동을 해야 하는 프로그램을 만들기 위한 목적으로 유용하게 사용할 수 있다.

2 GCC의 기본 옵션들

GCC가 여러분의 시스템에 설치되어 있다고 가정하고 글을 쓰도록 하겠다.

2.1 GCC 특징과 지원 환경 확인

[root@localhost include]# gcc -v

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 

--infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking 

--with-system-zlib --enable-__cxa_atexit 

--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux

Thread model: posix

gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

-v옵션을 이용하면 GCC와 관련된 다양한 정보들을 확인할 수 있다. 위의 정보에서 현재 설치된 gcc는 POSIX(12) 쓰레드 모델을 지원하고 있음을 알 수 있다. 이는 다중쓰레드를 지원하는 애플리케이션의 작성이 가능하다는 것을 의미한다.

이제 하나의 헤더파일과 하나의 소스코드파일로 이루어진 간단한 프로그램을 만들고 컴파일을 해보면서 GCC에서 지원하는 다양한 컴파일 옵션들에 대해서 알아보도록 하겠다.

// helloworld.h

#define COUNT 2



static char hello[] = "hello world";

// helloworld.c

#include <stdio.h>

#include "helloworld.h"



int main()

{

  int i;

  for (i =0; i <= COUNT; i++)

  {

    printf("%s - %d\n", hello, i);

  }

  return 0;

}

2.2 Object 파일의 생성

[root@localhost ~]# gcc -v -c helloworld.c 

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u

sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s

ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-aw

t=gtk --host=i386-redhat-linux

Thread model: posix

gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

 /usr/libexec/gcc/i386-redhat-linux/3.4.4/cc1 -quiet -v helloworld.c -quiet -dum

pbase helloworld.c -auxbase helloworld -version -o /tmp/ccs8066J.s

ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/3.4.4/../../../..

/i386-redhat-linux/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/local/include

 /usr/lib/gcc/i386-redhat-linux/3.4.4/include

 /usr/include

End of search list.

GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2) (i386-redhat-linux)

        compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2).

GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64407

 as -V -Qy -o helloworld.o /tmp/ccs8066J.s

GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version 2.15.92.

0.2 20040927

위 결과에서 오브젝트 파일을 만들기 위해서 include 경로를 찾는 과정과 GNU assembler를 이용해서 컴파일을 하고 있음을 확인할 수 있다. 컴파일러는 원본파일로 부터 /tmp/ccs8066J.s 라는 어셈블리코드를 만들고, 이것을 as를 이용해서 helloworld.o라는 이름의 오브젝트 파일을 만들었다.

2.3 실행파일 생성

[root@localhost ~]# gcc -v -o helloworld helloworld.c 

...[생략]...

GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2) (i386-redhat-linux)

        compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2).

GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64407

 as -V -Qy -o /tmp/ccj9GxKi.o /tmp/ccGzRoCh.s

GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version 2.15.92.0.2 20040927

 /usr/libexec/gcc/i386-redhat-linux/3.4.4/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker 

/lib/ld-linux.so.2 -o helloworld /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../crti.o 

/usr/lib/gcc/i386-redhat-linux/3.4.4/crtbegin.o -L/usr/lib/gcc/i386-redhat-linux/3.4.4 -L/usr/lib/gcc/i386-redhat-linux/3.4.4 

-L/usr/lib/gcc/i386-redhat-linux/3.4.4/../../.. /tmp/ccj9GxKi.o -lgcc 

--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s

--no-as-needed /usr/lib/gcc/i386-redhat-linux/3.4.4/crtend.o /usr/lib/gcc/i386-redhat-linux/3.4.4/../../../crtn.o

-L 옵션을 이용해서 링크할 라이브러리의 경로를 찾고 있음을 알 수 있다. 여기에서는 기본적으로 지정된 경로에서만 라이브러리를 찾고 있는데, 별도로 -L 옵션을 줘서 다른 경로에서 라이브러리를 찾도록 할 수도 있다. 그리고 -l옵션을 이용해서 링크할 라이브러리를 지정하고 있음을 알 수 있다. -l로 지정된 라이브러리는 -L에 의해 지정된 경로에서 동일한 이름의 라이브러리가 있는지를 찾아서 링크하게 된다.

필요한 라이브러리들을 링크 시키고 나면, 완전한 실행파일이 만들어지게 된다.

3 PreProcess 에 대해서

전처리기로 불리우기도 하는 preprocessor는 C컴파일러에서 매우 중요한 역할을 담당한다. preprocessor은 #include, #ifdef, #pragma등 '#'으로 시작되는 코드를 분리해 낸다. 이들 코드는 컴파일이 이루어지기 전에, 매크로 치환, 조건부 컴파일 확인, 파일 첨가(include)등의 업무를 처리한다. 예를 들어 #define COUNT 2 라는 코드라인이 있다면, 이부분을 해석해서 소스코드에 있는 모든 COUNT를 2로 치환하는 일을 한다. preprocessor은 줄단위로 처리된다.

3.1 proprocessed 출력

# gcc -E helloworld.c > helloworld.preprocess

파일첨가, 매크로치환등 을 포함한 모든 preprocess 과정을 파일로 저장하고 있다. 편집기를 이용해서 파일을 열어보면 preprocess가 담당하는 일이 어떤건지를 대략적으로 이해할 수 있을 것이다. 실질적으로 C컴파일러는 preprocess가 완전히 끝난 상태인 helloworld.preprocess를 소스코드로 해서 컴파일을 수행하게 된다.

3.2 매크로 치환 (#define)

# gcc -E helloworld.c -dM | sort | less

모든 define 문을 처리하고 이를 sort 해서 보여주고 있다. 여기에서 GNUC, GNUC_MINOR, GNUC_PATCHLEVEL 등등 GCC버전과 관련된 정보들도 확인할 수 있다.

1

4 Assembly(12) 코드 생성

GCC는 이진코드를 만들기전에 C코드를 assembly 코드로 변환되고, 변환된 assembly가 해석되어서 이진코드가 만들어진다. -S 옵션을 이용하면, C코드가 어떤 assembly코드로 변환되는지를 확인할 수 있다.

# gcc -S helloworld.c

다음은 만들어진 assembly 코드다.

  .file "helloworld.c"

  .data

  .type hello, @object

  .size hello, 12

hello:

  .string "hello world"

  .section  .rodata

.LC0:

  .string "%s - %d\n"

  .text

.globl main

  .type main, @function

main:

  pushl %ebp

  movl  %esp, %ebp

  subl  $8, %esp

  andl  $-16, %esp

  movl  $0, %eax

  addl  $15, %eax

  addl  $15, %eax

  shrl  $4, %eax

  sall  $4, %eax

  subl  %eax, %esp

  movl  $0, -4(%ebp)

.L2:

  cmpl  $2, -4(%ebp)

  jg  .L3

  subl  $4, %esp

  pushl -4(%ebp)

  pushl $hello

  pushl $.LC0

  call  printf

  addl  $16, %esp

  leal  -4(%ebp), %eax

  incl  (%eax)

  jmp .L2

.L3:

  movl  $0, %eax

  leave

  ret

  .size main, .-main

  .section  .note.GNU-stack,"",@progbits

  .ident  "GCC: (GNU) 3.4.4 20050721 (Red Hat 3.4.4-2)"

위의 어셈블리 코드에서 우리는 "hello world" 문자열이 읽기전용 데이터로 static하게 정의되어 있는걸 확인할 수 있다. .LC0 섹션은 printf의 인자를 보여주고 있다. 이 값들은 스택에 넣어지며 printf() 가 호출될 때, 읽어오게 된다. .L2 섹션은 loop를 위한 상태검사 코드가 들어간다. .L3 섹션은 함수가 끝난후 필요한 값을 리턴하고 종료하기 위한 코드가 들어간다. 이 어셈블리코드는 컴파일되어서 기계가 해석할 수 있는 이진코드로 변경되며, 이러한 컴파일 작업은 as가 담당하게 된다.

5 라이브러리 사용하기

만든 코드를 다른 프로그램에서 사용할 수 있도록 라이브러리 형태로 만들기를 원한다면 -fpic 옵션을 주면된다. fpic 옵션은 코드를 Position Independent Code (PIC) 로 만들어 준다. 라이브러리에 대한 자세한 내용은 library 만들기를 참고하기 바란다.

6 profiling 및 디버깅

profiling 는 프로그램의 실행시간시 코드의 어떤 부분이 가장 많은 자원을 차지하고 있는지 알아내기 위해서 사용하는 방법이다. profiling은 기본적으로 프로그램의 특정한 지점에 모니터링 코드를 입력하는 방식으로 이루어지며 GCC의 -pg옵션을 이용해서 모니터링 코드를 입력할 수 있다. profiling에 대한 자세한 내용은 Gprof를 이용한 프로그램 최적화를 참고하기 바란다.


일반적으로 프로그램을 디버깅 하기 위해서는 당연히 프로그램 실행 코드 외의 다른 코드가 삽입되어야 할 것이다. -g 옵션을 이용하면, gdb를 통해서 사용할 수 있는 여분의 디버깅 정보가 코드에 삽입된다. 여분의 코드가 삽입되기 때문에 실행파일의 크기가 커진다는 단점이 있지만, 어차피 디버깅이 끝난다음에는 디버깅코드를 제거하고 다시 컴파일하면 되므로 크게 문제될건 없다. 일단 디버깅 모드로 컴파일이 되면 모든 최적화(optimization) 플래그가 무효화 된다.

$ gcc -g -o helloworld helloworld.c #for adding debugging information

$ gcc -pg -o helloworld helloworld.c #for profiling

7 컴파일 시간 모니터링

완전한 하나의 실행파일을 만들기 위해서는 몇개의 단계를 거쳐야 함을 앞에서 배웠다. 그렇다면 각각의 단계에 어느정도의 시간이 소모되는지에 대한 정보를 알고 싶을 때가 있을 것이다. -time 옵션을 사용하면 각 단계별 소모시간을 알 수 있다.

[root@localhost ~]# gcc -time helloworld.c 

# cc1 0.07 0.01

# as 0.00 0.00

# collect2 0.06 0.01

-Q 옵션을 이용하면 좀더 자세한 소모시간을 확인할 수 있다. 더불어 컴파일이 어떠한 과정으로 이루어지는지도 확인 가능하다.

[root@localhost ~]# gcc -Q helloworld.c 

 main



Execution times (seconds)

 preprocessing         :   0.02 (25%) usr   0.00 ( 0%) sys   0.05 (26%) wall

 lexical analysis      :   0.01 (12%) usr   0.01 (50%) sys   0.01 ( 5%) wall

 parser                :   0.01 (13%) usr   0.00 ( 0%) sys   0.04 (21%) wall

 global alloc          :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 5%) wall

 TOTAL                 :   0.08             0.02             0.19

8 GCC 최적화

Before we move on to optimizations, we need to look at how a compiler is able to generate code for different platforms and different languages. The process of compilation has three components:
최적화에 대해서 설명하기 전에, 어떻게 컴파일러가 서로다른 플렛폼과 다른 언어에서 사용가능한 코드를 생성해내는지에 대해서 알아보도록 하겠다. 컴파일 프로세스는 다음의 3가지 컴포넌트들로 이루어진다.

• Front End : 최초에 입력된 코드는 인간이 이해하기 쉬운 문자열로 이루어지는데, 이를 컴퓨터가 능률적으로 해석할 수 형식으로 만들어 줘야 한다. 일반적으로 컴파일러는 주어진 코드를 파싱을 해서 Tree 형식의 데이터 구조로 재구성한다. 이 단계는 최적화할 만한 여지가 거의 없으며, GCC가 지원하는 언어에 따라서 다른 방법으로 Tree를 구성하게 될 것이다.
  
• Middle End : 코드생성을 위해서 구성된 트리구조에서 적절한 값들을 가지고 와서 재 배치시킨다. 이 단계는 모든 언어와 플렛폼에서 일반적인 과정을 거치게 되므로 역시 최적화의 요소는 거의 없다고 볼 수 있다. 이러한 과정들이 어떻게 일어나는지를 확인하기 원한다면 컴파일러와 관련된 문서를 읽어야 할 것이다.
  
• Back End : 실제 이진코드를 만들어 내기 위한 마지막 전 단계로, 플렛폼의 특성을 따르게 된다. 이 단계에서 플랫폼의 특성에 따른 최적화의 대부분이 이루어지게 된다. 컴파일러는 MMX/SSE2/3DNow와 같은 확장되거나 독특한 instruction셋에 대한 정보를 이용해서 거기에 맞는 바이너리 코드를 생성하려고 한다. CPU의 종류에 따라서 register의 갯수, 캐쉬와 파이프라인의 구조가 다르기 때문에, 컴파일러는 이들 구조간의 차이점을 고려해서 가능한 빠른 코드를 만들어 낸다.
  

최적화에는 속도 우선 최적화와 공간 우선 최적화의 두가지가 있다. 이상적으로 보자면 속도와 공간을 모두 고려해서 최상의 균형조건을 찾는게 좋을 것이다. 최근에는 메모리의 가격이 내려간 관계로 메모리의 소비를 증가하고 속도를 우선적으로 높이는 방법을 많이 사용하게 된다. 인라인 함수가 가장 대표적인 경우가 될것이다. 인라인 함수를 사용하게 되면 실행파일의 크기가 커지지만, 대신 좀더 빠른 함수의 호출이 가능해지므로 전체적으로 실행속도가 향상될 것이다.

GCC는 4단계의 최적화 정도를 제공한다. 단계는 -O 옵션뒤에 단계를 나타내는 숫자를 명시하는 식으로 이루어진다. 기본적으로는 "최적화를 안함"인데 -O0와 동일하다. -O1, -O2, -O3은 아래와 같은 최적화 수준을 가진다.

• -O1 는 컴파일 시간의 특별한 증가 없이 코드의 크기와 실행 시간을 줄여준다.
• -O2 는 코드의 크기와 실행 시간을 절충한 최적화 코드를 만든다.
• -O3 는 가능한 모든 최적화를 한다. 대신 컴파일 시간이 늘어나게 된다.

[root@localhost ~]# gcc -O3 -o hello3 helloworld.c 

[root@localhost ~]# gcc -O0 -o hello0 helloworld.c 



[root@localhost ~]# ls -al hello*

-rwxr-xr-x  1 root root  4754  1월  3 19:12 hello3

-rwxr-xr-x  1 root root  4782  1월  3 19:12 hello0



[root@localhost ~]# time ./hello3 > /dev/null 



real    0m0.003s

user    0m0.001s

sys     0m0.001s

[root@localhost ~]# time ./hello0 > /dev/null 



real    0m0.002s

user    0m0.000s

sys     0m0.002s

위의 결과를 보면 -O3 최적화를 했을 경우 실행파일의 크기가 더 작아졌음을 알 수 있다.

또한 CPU와 architecture에 따른 최적화도 가능하다. 예를 들어 architecture에 따라서 가질 수 있는 레지스터의 수가 달라질 수 있는데, 이를 잘 이용하면 좀더 최적화된 실행파일을 만들어 낼 수 있게 된다. CPU의 종류는 -mcpu=<CPU name>, architecture는 -march=<architecture 타입> 으로 지정할 수 있다. architecture에는 ix86(i386, i486, i586), Pentiumx(pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4), athlon(athlon, athlon-tbird, athlon-xp, opteron)등이 올 수 있다. architecture를 지정해 줄경우 좀더 세밀한 최적화가 가능하겠지만, 비교적 최신의 아키텍처 타입입을 지정할 경우 주의 해야 한다. -march=i386 으로 최적화한 코드의 경우 i686 에서도 문제없이 돌아가겠지만, -march=i686으로 최적화환 코드는 오래된 CPU에서 작동하지 않을 수도 있기 때문이다.

이 글은 스프링노트에서 작성되었습니다.

생각이 자라나는 노트 - "스프링노트" 에 오신 것을 환영합니다 ^^^#

1. 페이지를 클릭하면, 글을 쓰고 지울 수 있습니다.
2. 스프링노트에는 저장 버튼이 없습니다. 글을 쓸 때마다 바로 바로 저장됩니다 :)
3. FAQ 를 눌러, 스프링노트의 자세한 기능을 살펴보세요.
4. 새 페이지를 만들어 내 프로필을 작성해 보는건 어떨까요? 링크를 눌러보세요

스프링노트에 오늘의 할일을 써보세요-^#

• 먼저, 여기를 눌러보세요. 커서가 깜빡거리고 있죠?
• 자, 그럼 이제 오늘의 할일을 하나씩 써보세요.

1. 장보기 - 복숭아잼 사야함
2. 공과금 내기
3. 스카치 테이프 사오기
4. (...)

 ^#

앗! 이런 기능이?^#

1. Ctrl-Space를 눌러보세요. 손쉽게 링크를 걸 수 있답니다.
2. 글을 쓴 뒤 Alt-1, 2, 3, 4, 5, 6 를 눌러보세요^^
3. F2를 누르면 쓸 수 있는 단축키들이 모두 펼쳐집니다 =)

다른 분들은 스프링노트를 이렇게 쓰고 있어요^#

• 시험 공부 어떻게 계획하세요? 스프링노트로 기말고사 공부 계획을 세워보세요
• 아이디어 노트로 쓰시는 분들이 정말 많아요
• 친구들과 함께 써보세요! 100문 100답
• 링크를 이용하면 심리테스트도 할 수 있어요- 혈액형별 심리테스트

• 지금 100% 활용법에서, 스프링노트를 알차게 쓰고 계신 분들을 만나보세요!

자, 이 페이지를 지우시고, 나만의 첫 페이지를 꾸며보시기 바랍니다.

이 글은 스프링노트에서 작성되었습니다.

OSGi

위키백과 ― 우리 모두의 백과사전.

OSGi(Open Service Gateway initiative) Alliance는 1999년에 썬 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 후 몇 년 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 이 표준 사양의 핵심은 어플리케이션의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.

OSGi 프레임워크는 독립적인 자바/VM 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 어플리케이션 또는 컴포넌트(번들, Bundle)은 재부팅 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled)될 수 있다

OSGi는 Embeddable(어플리케이션 내부로 포함될수 있는) SOA를 구현하고 있다. 이를 통해 어플리케이션 개발에 있어 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)

OPML(Outline Processor Markup Language) 이란 무엇인가?

Mashup: 신종 웹 애플리케이션

제공 : DB포탈사이트 DBguide.net

출처 : IBM Korea

mashup은 대화형 웹 애플리케이션의 한 장르로서, 외부 데이터 소스에서 가져온 콘텐트를 사용하여 완전히 새롭고 혁신적인 서비스를 만듭니다. 비공식적으로 Web 2.0이라고 알려진 2 세대 웹 애플리케이션을 의미하기도 합니다. 이 글에서는 mashup의 의미, 오늘날 구현되는 대중적인 mashup들, mashup 개발자들이 애플리케이션을 구현할 때 활용하는 기술들을 소개합니다. 또한, mashup 개발자들이 직면한 기술적, 사회적인 많은 문제점들도 있습니다.

1.머리말

신종 웹 기반 데이터 통합 애플리케이션이 인터넷을 통해 자라나고 있다. 비공식적으로 mashups이라고 불리는 이 애플리케이션은 대화형 사용자 참여를 강조하고, 자기 파괴적인 방식으로 서드 파티 데이터를 한데 모은다. mashup에 대한 정의는 다음과 같다; mashup 웹 사이트는 웹에 기반하여, 외부의 데이터 소스에서 가져온 콘텐트와 기능을 사용한다.

mashup의 모호한 데이터 통합에 대한 정의는 정확한 것은 아니다. mashup을 생각하는 가장 좋은 방법은 이 용어의 어원을 생각해 보는 것이다. 대중 음악에서 차용된 것으로, mashup은 (보통 다른 장르에 속한) 두 개의 다른 노래들에서 보컬과 악기 트랙을 혼합한 새로운 노래이다.

“잡종 팝송(bastard pop)” 과 마찬가지로, mashup은 콘텐트를 비정상적이고 혁신적으로 혼합한다. (종종 관련성이 없는 데이터 소스에서도 가져온다.) 전산 소비가 아닌 인간이 소비할 수 있도록 만들어진다.

그렇다면, mashup은 과연 어떤 모습일까? ChicagoCrime.org 웹 사이트는 매핑 mashup의 좋은 예제이다. 언론에서 광범위한 대중성을 확보한 첫 번째 mashup 중 하나인 이 웹 사이트는 Chicago Police Department의 온라인 데이터베이스에서 얻은 범죄 데이터를 Google Maps의 지도 제작법과 혼합한다.

사용자들은 이 mashup 사이트와 인터랙팅 할 수 있다. 이를 테면, South Chicago의 최근 모든 강도 사건의 상세를 나타내는 푸쉬업(pushup)을 포함한 지도를 지리적으로 디스플레이 할 수 있다. 개념과 표현은 단순하고, 범죄와 지도 데이터의 합성은 시각적으로 강력한 힘을 발휘한다.

In mashup 장르에서는, 매핑 mashup을 포함한 대중적인 mashup 장르를 연구할 것이다. 관련 기술에서는 mashup의 구현과 작동과 관련된 기술을 검토할 것이다. 기술적 문제와 사회적 문제 섹션에서는 시급한 기술적, 사회적인 도전 과제들을 규명할 것이다.

2.Mashup 장르

이 섹션에서는, 대표적인 mashup 장르를 간단히 설명할 것이다.

매핑 mashup

정보 기술 세대에서, 사람들은 물건과 행위에 대한 상당한 데이터를 모으게 된다. 두 가지 모두 위치에 대한 주석이 달린다. 위치 데이터를 포함하고 있는 이 모든 데이터들은 지도를 사용하여 지리적으로 표현되고 있다. mashup이 등장하기 까지 가장 큰 촉매제가 된 것 중 하나가 Google의 Google Maps API이다.

이것은 웹 개발자들(취미 활동가, 사상가, 기타)이 모든 데이터들(핵 재앙에서부터 보스턴의 CowParade까지) 지도로 가져왔다. Microsoft (Virtual Earth), Yahoo (Yahoo Maps), AOL (MapQuest)의 API들이 바로 뒤를 이었다.

비디오 mashup과 사진 mashup

사진 호스팅과 Flickr 같은 소셜 네트워킹 사이트와 사진 공유를 표방하는 API들이 등장하면서 다양한 mashup들이 생겨나고 있다. 이러한 콘텐트 프로바이더들은 그들이 호스팅 하고 있는 이미지와 관련된 메타데이터(누가 사진을 찍었는지, 어떤 사진인지, 어디서 언제 찍었는지 등)를 갖고 있기 때문에, mashup 디자이너들은 사진을 이 메타데이터와 제휴될 수 있는 다른 정보들과 혼합한다.

예를 들어, 하나의 mashup이 노래 가사나 시를 분석하고 관련 사진들의 모자이크나 콜라주를 만들 수 있고, 또는 공통적인 사진 메타데이터(제목, 타임스탬프, 기타 메타데이터)에 기반하여 소셜 네트워킹 그래프를 디스플레이 한다. (CNN 뉴스 사이트 같은) 웹 사이트에서 뉴스의 단어들을 사진들과 매칭시키는 방식으로 텍스트를 렌더링 할 수 있다.

검색 mashup과 쇼핑 mashup

검색과 쇼핑 mashup은 mashup이라는 용어가 생겨나기 전부터 존재했다. 웹 API 전에, BizRate, PriceGrabber, MySimon, Google Froogle 같은 비교 쇼핑 톨들은 b2b 기술이나 screen-scraping의 결합을 사용하여 가격 비교 데이터들을 모았다. mashup과 기타 웹 애플리케이션들을 활용하기 위해, eBay와 Amazon 같은 사용자 마켓플레이스는 이들의 콘텐트에 프로그래밍 방식으로 액세스 할 수 있는 API를 만들었다.

뉴스 mashup

뉴스 소스(New York Times, BBC, Reuters)는 2002년부터 RSS와 Atom 같은 신디케이션 기술을 사용하여 다양한 토픽과 관련된 뉴스 피드를 보급했다. 신디케이션 피드 mashup은 사용자의 피드를 모아서 웹에 나타낸다. 독자의 특수한 취향에 맞게 제공되는 개인적인 신문을 만든 것이다. Diggdot.us가 한 예인데, 이는 기술 관련 뉴스 소스인 Digg.com, Slashdot.org, Del.icio.us 등에서 피드를 결합한다.

3.관련 기술

이 섹션에서는 mashup의 개발에 활용할 수 있는 기술들을 살펴보도록 하겠다. 기술에 대한 자세한 내용은 참고자료 섹션을 참조하기 바란다.

아키텍처

mashup 애플리케이션은 논리적으로나 물리적으로 떨어진(네트워크와 구성 영역에 의해 분리된 것 같다.) 세 개의 다른 참여자들로 구성된다: API/콘텐트 프로바이더, mashup 사이트, 클라이언트의 웹 브라우저.

• API/콘텐트 프로바이더. 이들은 혼합되는 콘텐트의 공급자들이다. ChicagoCrime.org mashup 예제에서, 공급자는 Google과 Chicago Police Department가 된다. 데이터를 가져올 수 있도록 하기 위해, 공급자는 REST, 웹 서비스, RSS/Atom 같은 웹 프로토콜을 통해서 웹 콘텐트를 노출한다.
  
  하지만 많은 잠재적인 데이터 소스는 아직까지는 편리한 방법으로 API를 노출하지 않는다. Wikipedia, TV Guide, 그리고 가상의 모든 정부 및 공공 도메인 웹 사이트에서 콘텐트를 추출하는 mashup은 스크린 스크래핑 기술을 사용하여 이를 사용한다.
  
  이러한 상황에서, 스크린 스크래핑이 의미하는 것은, 원래 인간이 소비하기로 되어있는 공급자의 웹 페이지를 파싱하여, 콘텐트 프로바이더에서 정보를 추출하는 과정을 의미한다.
  
• mashup 사이트. 이곳은 mashup이 호스팅 되는 장소이다. 여기에 mashup 로직이 있다는 이유 때문에 여기에서는 반드시 실행될 필요가 없다. 반면, mashup은 자바 서블릿, CGI, PHP, ASP 같은 서버 측 동적 콘텐트 생성 기술을 사용하는 전통적인 웹 애플리케이션과 비슷하게 구현될 수 있다.
  
  또는, mashup 콘텐트는 클라이언트 측 스크립팅(JavaScript)이나 애플릿을 통해 클라이언트의 브라우저에서 직접 생성될 수도 있다. 이러한 클라이언트 측 로직은 mashup의 웹 페이지에 직접 삽입된 코드와 스크립팅 API 라이브러리나, 이러한 웹 페이지들이 참조하는 애플릿들의 결합이다.
  
  이 방식을 사용하는 mashup을 rich internet applications (RIA)이라고 하는데, 대화형 사용자 경험을 강조한다는 뜻을 내포하고 있다. (리치 인터넷 애플리케이션은 "Web 2.0"이 표방하고 있는 것이다.) 클라이언트 측에서 혼합할 때의 이점은 mashup 서버를 대신하기 때문에 오버헤드가 적고(데이터는 콘텐트 프로바이더에서 직접 가져올 수 있다.), 보다 완벽한 사용자 경험이 가능하다는 점이다. (페이지들은 전체 페이지를 리프레쉬 하지 않고도 콘텐트의 일부만 업데이트할 것을 요청할 수 있다.)
  
  Google Maps API는 브라우저 측 JavaScript를 통한 액세스를 위한 것이고, 클라이언트 측 기술의 한 예가 된다.
  
  종종 mashup은 서버 측 로직과 클라이언트 측 로직의 결합을 사용하여 데이터를 모은다. 많은 mashup 애플리케이션들은 자신들에게 직접 제공된 데이터를 사용하여, (적어도) 한 개의 데이터 세트는 로컬로 만든다.
  
  게다가, 다중 소스 데이터("Kevin Bacon과 공동 주연을 했던 영화 배우가 사들인 평균 부동산 가격")에 대한 복잡한 쿼리는 클라이언트의 웹 브라우저 내에서 많은 일을 수행해야 한다.
  
• 클라이언트의 웹 브라우저. 이곳에서 애플리케이션은 그래픽으로 실행되고, 사용자 인터랙션이 발생한다. 앞서 설명한 것처럼, mashup은 종종 클라이언트 측 로직을 사용하여 혼합 콘텐트를 조합 및 합성한다.

Ajax

Ajax가 약어(어떤 사람은 "Asynchronous JavaScript + XML"의 합성으로 본다.)인지 아닌지에 대한 논의가 있다. Ajax는 특정 기술이기 보다는 웹 애플리케이션 모델이라고 할 수 있다. 비동기식 로딩과 콘텐트의 표현에 초점을 맞춘 여러 기술들을 구성하고 있다.:

• 스타일 표현을 위한 XHTML과 CSS
  
• 동적 디스플레이이와 인터랙션에 의해 노출된 Document Object Model (DOM) API
  
• 비동기식 데이터 교환, 일반적으로 XML 데이터
  
• 브라우저-측 스크립팅, 주로 JavaScript

이러한 기술들이 함께 사용될 때, 그 목적은 사용자 액션 후에 전체 페이지를 재 로딩 및 재 실행 하기 보다는, 소량의 데이터를 콘텐트 서버와 교환하여 보다 원활한 사용자 경험을 만들어 내는 것이다. JavaScript에서 구현된 다양한 Ajax 툴킷과 라이브러리(Sajax 또는 Zimbra)에서 mashup용 Ajax 엔진들을 구현할 수 있다.

Google Maps API에는 상용 Ajax 엔진이 포함되어 있고, 사용자 경험 역시 강력하다. 페이지 재 로드를 실행하는 조작 화살표나 트랜슬레이션 화살표에 대한 스크롤바가 없다는 점에서 진정한 로컬 애플리케이션처럼 작동한다.

웹 프로토콜: SOAP과 REST

SOAP과 REST는 원격 서비스들과 통신하는 플랫폼 중립적인 프로토콜이다. 서비스 지향 아키텍처 패러다임의 일부로서, 클라이언트는 SOAP과 REST를 사용하여 기반 플랫폼에 대한 지식 없이도 원격 서비스들과 인터랙팅 할 수 있다. 서비스의 기능은 요청 및 응답 받은 메시지의 디스크립션에 의해 전달된다.

SOAP은 웹 서비스 패러다임의 기본 기술이다. 원래, Simple Object Access Protocol의 약어였던 SOAP은 Services-Oriented Access Protocol (또는 그냥 SOAP)으로 개명되었다. 초점이 객체 지향 시스템에서 메시지 교환의 상호 운용성으로 이동했기 때문이다. SOAP 스팩에는 두 개의 핵심 요소가 있다. 첫 번째는 플랫폼 중립적인 인코딩을 위한 XML 메시지 포맷이고, 두 번째는 헤더와 바디로 구성된 메시지 구조이다.

헤더는 애플리케이션 페이로드(바디), 이를 테면, 인증 정보에 국한되지 않는 콘텍스트 정보를 교환한다. SOAP 메시지 바디는 애플리케이션 스팩의 페이로드를 캡슐화 한다. 웹 서비스용 SOAP API는 WSDL 문서로 기술되는데, 서비스가 노출하는 작동, 메시지 포맷(XML Schema 사용), 접근 방법 등이 설명되어 있다. SOAP 메시지는 HTTP를 통해 전달되지만, 다른 트랜스포트(JMS 또는 이메일)도 가능하다.

REST는 Representational State Transfer의 약어로서, HTTP와 XML을 사용한 웹 기반 통신 기술이다. 단순함과 프로파일의 부족 때문에 SOAP과 분리되고 매력도 떨어진다. 현대 프로그래밍 언어에서 찾을 수 있는 동사 기반 인터페이스(getEmployee(), addEmployee(), listEmployees() 같은 다양한 메소드로 구성됨)와는 달리, REST는 근본적으로 모든 정보 조각에 사용할 수 있는 몇 가지 연산들(POST, GET, PUT, DELETE)만 지원한다. REST에서 강조하는 것은 리소스라고 하는 정보이다.

예를 들어, 사원에 대한 정보 기록은 URI로 구분되고, GET 연산을 통해 가져오고, PUT 연산으로 업데이트 되는 식이다. 따라서 REST는 SOAP 서비스의 document-literal 스타일과 비슷하다.

스크린 스크래핑

앞서 언급했던 것처럼, 콘텐트 프로바이더에서 오는 API의 부족 때문에, mashup 개발자들이 스크린 스크래핑에 의존하여 그들이 혼합하고자 하는 정보를 가져온다. 스크래핑(Scraping)은, 프로그래밍 방식으로 사용 및 조작될 수 있는 정보의 시맨틱 데이터 구조를 추출하기 위해, 소프트웨어 툴을 사용하여 인간이 소비하도록 작성된 콘텐트를 파싱하고 분석하는 프로세스이다. 일부 mashup은 데이터 획득에 스크린 스크래핑 기술을 사용한다.

특히, 공공 섹터에서 데이터를 가져올 때 그렇다. 예를 들어, 부동산 매핑 mashup은 지도 제작 공급자의 지도와 판매 또는 임대 리스팅을 스크랩 된 “comp” 데이터를 혼합할 수 있다. 데이터를 스크래핑 하는 또 다른 mashup 프로젝트로는 XMLTV가 있는데, 이것은 전 세계, TV 리스트를 모으는 툴의 컬렉션이다.

스크린 스크래핑은 세련되지 않은 솔루션으로 간주된다. 여러 가지 이유가 있다. 두 개의 근본적인 단점들이 있기 때문이다. 첫 번째는 인터페이스를 가진 API와는 달리, 스크래핑은 콘텐트 프로바이더와 콘텐트 소비자 간 지정된 프로그램 방식의 콘트랙트가 없다.

스크래퍼는 소스 콘텐트의 모델과 관련하여 툴을 디자인 해야 하고, 공급자는 지속적으로 표현 모델에 의존해야 한다. 웹 사이트는 룩앤필을 주기적으로 정비하여 스타일을 유지해야 한다. 툴이 이 일을 하지 못하기 때문에 스크래퍼의 고통만 늘어난다.

두 번째 문제는 고급의, 재사용 가능한 스크린 스크래핑 툴킷 소프트웨어, 즉 scrAPIs의 부족이다. 이 같은 API와 툴킷이 부족한 이유는 각 스크랩핑 툴이 애플리케이션을 필요로 하기 때문이다. 때문에 많은 개발 오버헤드가 생기고, 개발자들은 콘텐트를 역 엔지니어링 하고, 데이터 모델을 개발하며, 공급자 사이트에서 미가공 데이터를 파싱 및 모아야 한다.

시맨틱 웹과 RDF

스크린 스크래핑의 세련되지 못한 특성은 인간이 소비하도록 만들어진 콘텐트가 자동화된 머신이 소비하기에 좋은 콘텐트가 되지 못한다는 사실에서 기인한다. 시맨틱 웹은, 기존 웹이 머신도 읽을 수 있는 정보를 사용하여 인간을 위해 설계된 콘텐트를 보완하도록 증가될 수 있다고 표방한다.

시맨틱 웹이라는 정황에서, 정보는 데이터와는 다르다. 데이터가 의미를 전달할 때에는 정보가 된다. 시맨틱 웹의 목적은 의미를 전달하는 메타데이터를 가진 데이터를 보강하여, 자동화, 통합, 추론, 재사용에 맞는 웹 인프라스트럭처를 만드는 것이다.

Resource Description Framework (RDF)로 알려진 W3C 스팩군은 데이터를 기술하는 문법 구조를 확립하는 방식을 제공한다. XML로는 충분하지 않다. 같은 데이터를 기술하는데 많은 방식으로 코딩 할 수 있다는 점에서 너무 모호하다. RDF-Schema는 RDF의 기능에 추가되어 머신이 읽을 수 있는 방식으로 인코딩 한다.

일단 데이터 객체가 데이터 모델에서 기술될 수 있다면, RDF는 subject-predicate-object(subject의 S는 relationship R과 object O를 갖고 있다.)를 통해서 데이터 객체들 간 관계 구조를 제공한다. 데이터 모델과 관계 그래프의 결합은 온톨로지의 생성에 적용되고, 이는 검색 및 추론될 수 있는 계층적 지식 구조가 된다.

예를 들어, it "eats" other "animal-type" 라는 제약 조건을 가진 "animal-type"의 하위 클래스로서 "carnivore-type" 모델을 정의할 수 있고, 이것에 대한 두 개의 인스턴스를 만든다. 하나는 치타와 북극곰과 이들의 습성과 관련된 데이터로 전개되고, 또 다른 하나는 가젤과 펭귄과 이들 각각의 습성과 관련된 데이터를 전개할 수 있다. 추론 엔진은 이러한 개별 모델 인스턴스들을 “혼합”하고 치타가 펭귄이 아닌 가젤을 잡아먹는다는 추론을 내린다.

RDF 데이터는 다양한 분야에서 빠르게 채택되고 있다. 소셜 네트워킹 애플리케이션(FOAF -- Friend of a Friend)과 신디케이션(RSS)도 한 예이다. 게다가, RDF 소프트웨어 기술과 컴포넌트는 어느 정도 성숙해졌고, 특히 RDF 쿼리 언어(RDQL과 SPARQL)와 프로그래밍 프레임웍과 추론 엔진(Jena와 Redland) 분야가 성장했다.

RSS와 ATOM

RSS는 XML 기반 신디케이션 포맷의 일부이다. 신디케이션은 콘텐트를 배포하고자 하는 웹 사이트가 RSS 문서를 만들고 이 문서를 RSS 퍼블리셔로 등록한다. RSS가 실행되는 클라이언트는 퍼블리셔의 피드에서 새로운 콘텐트를 검사하고 알맞은 방식으로 이에 대응한다.

RSS는 뉴스 아티클과 헤드라인, CVS checkins나 wiki pages용 changelog, 프로젝트 업데이트, 라디오 프로그램 같은 오디오 데이터까지, 광범위한 콘텐트를 합성한다. Version 1.0은 RDF 기반이지만, 최신 2.0 버전은 그렇지 않다.

ATOM은 새롭지만 더 유사한 신디케이션 프로토콜이다. Internet Engineering Task Force (IETF)의 제안 표준이고 RSS 보다 더 좋은 메타데이터를 관리 할 방법을 모색하고 있으며, 더 좋은 문서를 제공하고, 구조 개념을 일반 데이터 표현에 적용한다.

이러한 신디케이션 기술은 뉴스와 웹로그 애그리게이터 같은 이벤트 기반 콘텐트 또는 업데이트 중심 콘텐트를 모으는 mashup에는 잘 맞는다.

4.기술적 문제

다른 데이터 통합 분야와 마찬가지로, mashup 개발에는 기술적 문제들이 많이 있다. 특히 mashup 애플리케이션들은 더욱 많은 기능들을 갖추어야 한다. 이 섹션에서는 몇 가지 문제점들을 규명해보도록 하겠다.

데이터 통합 문제: 시맨틱 의미와 데이터 품질

오늘날 기업의 제 1의 IT 관심사는 엔터프라이즈 가상 구조에 데이터 통합하기라는 조사가 있었다. 가상 구조(virtual organization)는 연합 비즈니스 단위의 합성이며, 각각은 관리 도메인 안에 포함되어 있음을 의미한다.) (현재 비즈니스 조건들을 반영하는 기업 대시보드를 만들기 위해) 레거시 데이터 소스를 통합해야 하는 도전에 직면한 많은 엔터프라이즈 IT 관리자들과 마찬가지로, mashup 개발자들도 이종의 데이터 세트 간 공유 시맨틱 의미를 추출해야 한다는 비슷한 도전 과제를 안고 있다. 따라서, mashup 개발자가 무엇을 해야 하는지 알고 싶다면 엔터프라이즈 IT가 직면한 통합 문제를 검토해 봐야 한다.

예를 들어, 데이터 모델들 간 트랜슬레이션 시스템들이 설계되어야 한다. 데이터를 일반 형식으로 변환할 때, 매핑이 완전한 것이 아닐 때 추론이 이루어진다. (예를 들어, 하나의 데이터 소스가 하나의 모델을 가질 수 있고, 주소 유형에는 국가 필드가 포함되어 있는 반면, 다른 것은 그렇지 않다.) mashup 개발자들은 소스 데이터 모델 분야에는 전문가가 될 수 없다. 이 모델은 이들에게는 서드 파티에 해당하고, 추론은 매력적이거나 명확하지 못하다.

소실된 데이터나 불완전한 매핑 외에도, mashup 디자이너는 그들이 통합하고자 하는 데이터가 머신 자동화에 맞지 않다는 것을 알게 된다. 정리가 필요하다. 예를 들어, 법 집행 체포 기록은 일관성 없이 입력될 수 있다. 이름을 줄여서 쓰고(어떤 곳에서는, "mkt sqr"로, 또 다른 곳에서는 "Market Square"로 표기한다.), 추론이 어렵게 된다.

RDF 같은 시맨틱 모델링 기술은, 데이터 스토어에 빌트인 된다면, 다른 데이터 세트들 간 자동화 추론 문제를 완화시킨다. 레거시 데이터 소스들은 시맨틱 모델링 기술에 사용되기 전에 분석과 데이터 청소의 관점에서 인간의 노력이 많이 필요하다.

mashup 개발자들은 IT 통합 매니저가 겪지 않은 여러 문제들과도 싸워야 한다. 이중 하나가 데이터 오염 문제이다. 이들의 애플리케이션 디자인의 일부로서, 많은 mashup들은 퍼블릭 사용자 인풋을 끌어들인다. WIKI 애플리케이션 도메인에서 분명해졌듯이, 이는 양날이 선 칼이다. 공개 기여와 데이터 혁신을 가능케 하기 때문에 강력하지만, 일관성 없고, 부정확 하게, 또는 의도적으로 데이터 입력을 유도한다. 후자는 데이터 신뢰성에 대해 의심하게 되고, 이는 mashup이 제공하는 가치를 충분히 상쇄한다.

mashup 개발자들이 직면한 또 다른 통합 문제는 스크린 스크래핑 기술이 데이터 획득에 사용될 때 발생한다. 이전 섹션에서도 설명했지만, 파싱과 수집 툴과 데이터 모델을 추출하는 데는 상당한 역 엔지니어링이 필요하다. 이러한 툴과 모델이 만들어지는 최고의 상황에서도, 소스 사이트가 콘텐트를 표현하는 방식을 리팩토링 해야 한다. 따라서 통합 프로세스에 제동이 걸리고 mashup 애플리케이션 오류로 이어진다.

컴포넌트 문제

Ajax 모델의 웹 개발은 보다 풍부하고 완벽한 사용자 경험을 제공할 수 있지만, 난점도 안고 있다. Ajax는 브라우저의 클라이언트 측 스크립팅 기능과 DOM을 결합하여 브라우저 디자이너가 생각하지 못했던 콘텐트 전달 방식을 이룩해야 한다. (아마도 Ajax의 해킹 특성에 기인한 것 같다.)

하지만, 이는 Ajax 기반 애플리케이션을 Microsoft created Internet Explorer 이후 웹 디자이너를 난감하게 하는 같은 브라우저 호환성 문제로 가져온다. 예를 들어, Ajax 엔진은 XMLHttpRequst 객체를 사용하여 원격 서버들과 비동기식으로 데이터를 교환한다. Internet Explorer 6에서, 이 객체는 원시 JavaScript가 아닌 ActiveX로 구현된다.

보다 근본적으로는, Ajax의 경우, 사용자 브라우저 안에 JavaScript가 실행되어야 한다. 하지만 JavaScript를 지원하지 않거나 실행되지 않는 브라우저나 자동화 툴을 사용하는 특정 사용자들도 있기 마련이다. 이 같은 툴 세트로는 인터넷과 인트라넷 검색 엔진용 정보를 모으는 로봇, 스파이더, 웹 크롤러 등이 있다. Ajax 기반 mashup 애플리케이션은 소수의 사용자 기반과 검색 엔진 가시성을 잃게 된다.

페이지 내에 비동기식으로 콘텐트를 업데이트 할 때 JavaScript를 사용하면 사용자 인터페이스 문제가 생긴다. 콘텐트는 더 이상 브라우저의 주소 바에 있는 URL로 연결되지 않기 때문에, 사용자는 브라우저의 백(back) 버튼의 기능과 BOOKMARK 기능을 기대할 수 없다.

Ajax는 비점증적 콘텐트 업데이트를 요청함으로써 레이턴시를 줄일 수 있지만, 형편 없는 디자인 때문에 사용자 경험이 엉망이 되고, 업데이트의 세분성은 양에 비해 너무 적고 업데이트 오버헤드는 가용 리소스를 갉아먹는다. 또한, 인터페이스 로드나 콘텐트가 업데이트 되는 동안 사용자(진행 바 같은 비주얼 피드백을 가진)사용자를 지원해야 한다.

분산된, 크로스 도메인 애플리케이션과 마찬가지로, mashup 개발자와 콘텐트 프로바이더는 보안 문제도 다루어야 한다. 아이디의 개념은 성가신 주제가 될 수 있다. 전통적인 웹은 익명 액세스용으로 구현되었다. 싱글사인온은 바람직한 기능이지만, 많은 기술들이(Microsoft Passport에서 Liberty Alliance 까지)있고, 반드시 통합되어야 하는 아이디 네임스페이스에 부조화를 만든다.

콘텐트 프로바이더는 자신들의 API에 인증과 권한 스킴을 적용하여(보안 아이디나 안전하게 구분할 수 있는 애트리뷰트 개념이 필요하다.) 유료 등록자나 민감한 데이터가 포함된 비즈니스 모델에 실행해야 한다.

민감한 데이터는 기밀성(암호화)이 필요하고, 이들을 다른 소스들과 결합할 때 특별한 주의를 기울여야 한다. 아이디는 감사와 규제 순응에 필수적이다. 게다가, 서버와 클라이언트 측에서 발생하는 데이터 통합의 경우, 사용자부터 mashup 서비스까지 아이디와 보안이 필요하다.
 

사회적 문제

이전 섹션에서 설명한 기술적 문제 외에도, mashup이 대중성을 확보하면서 생기는 사회적인 문제도 있다.

mashup 개발자들이 직면한 가장 큰 사회적 문제들 중 하나는 지적 재산의 보호와 소비자 프라이버시 대 공정 사용과 정보의 자유로운 흐름 간 대립이다. 무식한 콘텐트 프로바이더(스크린 스크래핑의 표적)와 데이터 검색을 위해 API를 노출하는 콘텐트 프로바이더들은 자신들의 콘텐트가 승인되지 않는 방식으로 사용되고 있다는 것을 알아야 한다. 웹 애그리게이션과 규제와 관련하여, 참고자료를 참조하라.

mashup 웹 애플리케이션 장르는 아직 유아기에 머물러 있다. 여가 시간에 많은 mashup을 만드는 정도이다. 이러한 개발자들은 보안 같은 문제들을 인식하지 못한다. 게다가, 콘텐트 프로바이더는 머신 기반 콘텐트 액세스에 API를 제공하는 것의 가치를 이제서야 깨닫기 시작했고, 많은 사람들은 이것을 중요한 비즈니스 문제로 간주하지 않는다.

이러한 사실들이 결합하여 저질의 소프트웨어를 양산하고, 테스팅과 품질 보증 같은 우선순위들은 개념 입증과 혁신의 뒤로 물러나 있다. 커뮤니티는 보다 성숙한 소프트웨어 개발 프로세스를 위해서 오픈 표준과 재사용 가능한 툴킷들을 조합해야 한다.

mashup이 재미있는 장난감에서 세련된 애플리케이션으로 변모하기 전에, 강력한 표준, 프로토콜, 모델, 툴킷 등의 제반 사항들이 해결되어야 한다. 많은 소프트웨어 개발 리더, 콘텐트 프로바이더, 기업가들이 mashup의 가치, 즉 mashup이 귀중한 비즈니스 모델이라는 것을 인식해야 한다.

API 프로바이더는 자신들의 콘텐트에 요금을 부과할 것인지의 여부를 결정해야 하고, 부과할 것이라면, 그 방법도 모색해야 한다. (예를 들어, 등록비 또는 사용료) 아마도, 다양한 서비스 품질이 제공될 것이다. eBAY나 Amazon 같은 프로바이더들은 자신들의 API를 무료로 사용할 수 있도록 하는 운동을 벌이고 있다. mashup 개발자들은 광고 기반의 수익 모델을 모색하거나, 흥미진진한 mashup 애플리케이션을 개발해야 할 것이다.
 

5.요약

mashup은 웹 애플리케이션의 신종 장르이다. 시맨틱 웹에서 기인한 데이터 모델링 기술을 약결합, 서비스 지향, 플랫폼 중립의 통신 프로토콜과 결합하면, 웹에서 사용할 수 있는 거대한 정보를 활용 및 통합할 수 있는 애플리케이션을 위한 인프라스트럭처를 제공하게 된다.

mashup 애플리케이션이 대중성을 얻어가면서, 공정 사용과 지적 재산권, 그리고 그리드 컴퓨팅과 b2b 워크플로우 관리 같은 사회적 문제들에 어떤 영향을 미치는지를 보는 것도 재미있는 일이다.

mashup 개발에 대해 자세히 알고 싶다면 developerWorks의 새로운 튜토리얼 시리즈를 기대하기 바란다. mashup 구현 방법을 설명할 예정이다. 시맨틱 웹 기술과 온톨로지를 사용하여 자신의 mashup을 구현하는 방법을 설명할 것이다.