JVM 옵션으로 -Dfile.encoding=UTF-8을 주면 될 것 같지만, ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist 에 JVM옵션을 추가해도 jenkins의 file.encoding은 여전히 US-ASCII 다.

jenkins가 업데이트 될 때마다 고쳐하는 게 문제이지만, ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist파일에 아래처럼 환경변수를 추가해주면 인코딩을 UTF-8로 jenkins를 띄울 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dt>
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>homebrew.mxcl.jenkins</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/java</string>
      <string>-jar</string>
      <string>/usr/local/opt/jenkins/libexec/jenkins.war</string>
      <string>--httpListenAddress=127.0.0.1</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>EnvironmentVariables</key>
    <dict>
      <key>LANG</key>
      <string>ko_KR.UTF-8</string>
    </dict>
  </dict>
</plist>

위에서 EnvironmentVariables 이하를 추가한다. 다시 말하지만 위쪽의 ProgramArguments 부분에 -Dfile.encoding=UTF-8을 넣는 방식은 환경변수 때문에 정상적으로 작동하지 않는다.

jenkins를 아래와 같이 다시 시작한다.

1
2

$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist

1
2
3
4
5
6

> /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home
> /usr/libexec/java_home -v1.6
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> /usr/libexec/java_home -v1.7
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home

.bashrc 파일에 아래처럼 세팅하면 되겠다.

1

export JAVA_HOME=`/usr/libexec/java_home`

cucumber-jvm은 java외에도 groovy, scala, jython 등 jvm 기반의 언어 다수를 지원한다. 그래서 cucumber-java가 아니라 cucumber-jvm이라 이름 붙인듯 하다. 이 글에서 maven, junit, spring framework과 같은 대표적인 java 개발환경에서 cucumber를 사용하기 위한 방법을 소개한다.

maven dependency

pom.xml 파일에 아래와 같이 dependency를 추가한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

...
<properties>
  <cucumber.version>1.1.2</cucumber.version>
  <junit.version>4.11</junit.version>
</properties>
<dependencies>
  ...
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-junit</artifactId>
    <version>${cucumber.version}</version>
  </dependency>
  <dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-java</artifactId>
    <version>${cucumber.version}</version>
  </dependency>
  <dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-spring</artifactId>
    <version>${cucumber.version}</version>
  </dependency>
<dependencies>
...

주의할 점은 junit은 최신버전(현재 4.11)을 사용해야 한다. 4.8버전에서 문제가 있다. 또, 현재 최신인 1.1.3버전의 cucumber는 pretty formatter에 오류가 있으니, 1.1.2버전을 사용한다.

• cucumber-junit은 cucumber를 JUnitRunner을 이용하여 실행하기 위해 필요하다. 대부분의 IDE가 junit을 지원하므로 cucumber-junit을 사용하는 것이 편하다.
• cucumber-java는 java를 이용하여 step definition을 작성하기 위해 필요하다.
• cucumber-spring은 Spring Framework과 연동하여 사용할 때 테스트를 위한 Configuration Context를 로딩하기 위해서 필요하다. (Spring을 사용하지 않는다면 뺀다.)

JUnit 연동

JUnit을 통해서 Cucumber 테스트를 실행하기 위해서 아래와 같은 파일을 src/test/java/features 디렉토리 밑에 추가한다.

1
2
3
4
5
6
7
8
9
10
11
12

package features;

import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@Cucumber.Options(
        features = "classpath:features",
        format = {"pretty", "json:target/cucumber.json", "html:target/cucumber"}
)
public class CucumberTests {
}

일반적으로 cucumber 관련 파일들은 features 패키지 밑에 둔다.

• @RunWith : JUnitRunner를 통해서 Cucumber가 실행되도록 한다. Cucumber.class가 실질적으로 feature에 대한 테스트를 수행하게 된다.
• @Cucumber.Options : Cucumber실행에 대한 옵션.
  • features : gherkin DSL로 작성된 feature 파일들의 경로를 지정한다. 보통 src/test/resources/features/ 밑에 위치하므로 classpath:features라고 지정한다.
  • format : 출력 포맷을 지정한다. pretty는 텍스트 형태의 console 출력이고, json/html 등은 파일명을 지정하게 된다.
• CucumberTests 클래스는 JUnit으로 테스트를 실행하기 위한 용도로만 사용하므로 클래스 내부는 비워둔다.

Spring 연동

Spring Framework 환경에서 JUnit test를 쓸 때 @org.springframework.test.context.ContextConfiguration 어노테이션을 사용하여 로딩할 context configuration을 지정하게 된다. Cucumber에서는 기본적으로 classpath:cucumber.xml 파일을 Spring context로 로딩한다. 따라서 cucumber.xml파일을 src/test/resources/에 만든다.

아래는 예시일 뿐이고, 테스트에 필요한 Spring 설정을 추가하거나, 별도로 테스팅용 context configuration 파일이 있다면 import하도록 한다.

1
2
3
4
5
6
7
8

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
    <context:annotation-config/>
    <context:component-scan base-package="net.oddpoet.cucumber.sample"/>
</beans>

feature 작성

feature 파일은 위의 CucumberTests.java 에서 features 옵션으로 설정한대로 src/test/resources/features/ 밑에 만든다. feature가 많아지면 sub-directory를 만들어 구성할 수도 있다. 아래는 feature 파일의 예이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

@interface
Feature: 대화형 팀매칭 시스템

  시스템과 대화형으로 작업하는 사용자는
  입력값을 입력하면 그에 대한 즉각적인 피드백을 받는다.
  모든 입력이 완료되면 시스템은 입력된 선수 정보를 기반으로 2팀을 구성하여 출력한다.

  - 각 선수 정보 포맷 : <선수번호> <싫어하는 선수 수> <싫어하는 선수번호> <싫어하는 선수번호> ...

  Scenario: 기본 예제
    Given 시스템 출력: '총 선수 수를 입력하시오'
    When 사용자 입력: '5'
    Then 시스템 출력: '1번선수 정보를 입력하시오'
    When 사용자 입력: '1 1 2'
  # 1번 선수는 1명을 싫어하고 싫어하는 선수는 2번 선수이다
    Then 시스템 출력: '2번선수 정보를 입력하시오'
    When 사용자 입력: '2 1 3'
  # 2번 선수는 1명을 싫어하고 싫어하는 선수는 3번 선수이다
    Then 시스템 출력: '3번선수 정보를 입력하시오'
    When 사용자 입력: '3 0'
  # 3번 선수는 싫어하는 선수가 없다
    Then 시스템 출력: '4번선수 정보를 입력하시오'
    When 사용자 입력: '4 2 2 3'
  # 4번 선수는 2명을 싫어하고 싫어하는 선수는 2, 3번 선수이다
    Then 시스템 출력: '5번선수 정보를 입력하시오'
    When 사용자 입력: '5 1 4'
  # 5번 선수는 1명을 싫어하고 싫어하는 선수는 4번 선수이다
    Then 팀 구성 결과를 출력한다


  Scenario: 총 선수 수에 오류가 있을 경우
    Given 시스템 출력: '총 선수 수를 입력하시오'
    When 사용자 입력: '-10'
    Then 시스템 출력: '총 선수 수를 다시 입력하시오'
    When 사용자 입력: '3'
    Then 시스템 출력: '1번선수 정보를 입력하시오'

  Scenario: 선수정보에 오류가 있을 경우
    Given 시스템 출력: '총 선수 수를 입력하시오'
    When 사용자 입력: '5'
    Then 시스템 출력: '1번선수 정보를 입력하시오'
    When 사용자 입력: 'A 1 B'
    Then 시스템 출력: '1번선수 정보를 다시 입력하시오'
    When 사용자 입력: '1 1 2'
    Then 시스템 출력: '2번선수 정보를 입력하시오'

feature 파일을 만들고 JUnit으로 테스트를 수행하면, Step Definition이 없다는 메시지와 함께 step definition에 대한 code snippet을 console에 출력해준다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

You can implement missing steps with the snippets below:

@Given("^시스템 출력: '총 선수 수를 입력하시오'$")
public void 시스템_출력_총_선수_수를_입력하시오() throws Throwable {
    // Express the Regexp above with the code you wish you had
    throw new PendingException();
}

@When("^사용자 입력: '(\\d+)'$")
public void 사용자_입력_(int arg1) throws Throwable {
    // Express the Regexp above with the code you wish you had
    throw new PendingException();
}

@Then("^시스템 출력: '(\\d+)번선수 정보를 입력하시오'$")
public void 시스템_출력_번선수_정보를_입력하시오(int arg1) throws Throwable {
    // Express the Regexp above with the code you wish you had
    throw new PendingException();
}

@When("^사용자 입력: '(\\d+) (\\d+) (\\d+)'$")
public void 사용자_입력_(int arg1, int arg2, int arg3) throws Throwable {
    // Express the Regexp above with the code you wish you had
    throw new PendingException();
}

...(이하 생략)...

아직 각 step(Given, When, Then)에 대한 step definition이 정의되지 않아서 발생하는 경고이다. Cucumber는 이것을 테스트의 Fail로 처리하지 않고, Pending 처리한다.

Step Definition 작성

Step definition은 feature에 기술된 각 단계(step)를 어떻게 수행할 것인지를 코딩하는 하는 단계다. 보통 실제 코드가 만들어진 후 작성하여 연결하게 된다.

Step definition을 작성할 때는 cucumber 실행시 출력되는 code snippet을 복사해서 붙일 수도 있지만, Intellij같은 IDE를 사용한다면 Step Definition을 생성해주는 IDE의 기능을 사용한다.

일반적으로 src/test/java/features/step_definitions 밑에 Step Definition 클래스를 정의한다. Cucumber는 step과 step definition을 정규식 매칭으로 연결하므로 의미적으로 동일한 step들이 동일한 step definition으로 연결되도록 정규식을 수정한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package features.step_definitions;

import java.io.*;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.*;

public class InteractiveStepDef {
    @Autowired
    TeamCreateService teamCreateService;

    @Autowired
    @Qualifier("inputWriter")
    PrintWriter inputWriter;

    @Autowired
    @Qualifier("outputWriter")
    LoggedWriter outputLog;

    @Given("^시스템 출력: '(.+)'$")
    public void 시스템_출력_(String output) throws Throwable {
        String systemOut = outputLog.getLoggedLine();
        assertThat(systemOut, is(output));
    }

    @When("^사용자 입력: '(.+)'$")
    public void 사용자_입력_(String input) throws Throwable {
        inputWriter.println(input);
    }
    .. 후략...

• JUnit과 유사하게 @cucumber.api.java.Before, @cucumber.api.java.After 어노테이션으로 Step Definition 클래스에 대한 setUp, tearDown 코드를 쓸 수 있다.
• Step Defnition 클래스는 일반적인 Java 구현이므로, Spring DI를 사용하거나, mockito 역시 사용할 수 있다.

문서로써의 테스트 결과

Cucumber의 feature는 test automation으로써의 기능 외에도 문서의 기능도 가진다. 따라서 프로젝트 관계자들이 모두 그 결과를 보고 검토할 수 있도록 CI 툴과 연계하는 것이 좋다.

Jenkins를 사용한다면 cucumber-report 플러그인을 사용하여 보다 fancy한 결과를 얻을 수 있다.

참고할만한 것들

• Step Definitions 용례
• Cucumber 다국어 예제
• Top5 Cucumber Best Practices
• 자작 Cucumber+Spring Sample

그와 발맞춰 일명 ‘곡괭이책’-Programming ruby 1.9 & 2.0 (4th ed) 역시 업데이트되었다.

ruby 2.0의 새로운 기능

keyword arguement

기존에 hash로 named argument처럼 쓰는 것과 비슷해보이지만, 정의한 keyword arguement가 넘겨지지 않으면 에러가 발생한다.

Module#prepend

Module#include는 include되는 모듈의 메소드를 클래스의 메소드가 override 하지만, Module#prepend는 반대로 클래스의 메소드를 모듈의 메소드가 override하게 된다. 즉, 모듈 메소드를 call chain 앞에 추가하는 형태가 된다.

아래 예를 보면 Module#include와 Module#prepend의 차이를 확인할 수 있다.

1
2
3
4
5
6
7
8

module A; end
module B; end
class C
    include A
    prepend B
end

C.ancestors #=> [B, C, A, Object, Kernel, BasicObject] 

Refinements

Rails도 그렇고 ruby 커뮤니티는 기본 core lib나 stdlib의 클래스를 열어서 기존 메소드를 변경하거나 확장하는 경우가 종종 있는데(e.g. 3.days.ago), 이런 류의 변경을 Module scope 내에서만 적용할 수 있도록 Module#refine 메소드가 추가됨

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

module NumberQuery
    refine String do
        def number?
            match(/^[1-9][0-9]+$/) ? true : false
        end
    end
end

"123".number?  #=> NoMethodError

module NumberQuery
    p "123".number?  #=> true
end

module MyApp
    using NumberQuery

    p "123".number?  #=> true
    p "foo".number?  #=> false
end

symbol list creation

심볼 배열을 생성할 수 있는 새로운 literal 표현(%i)이 추가됨

1
2
3
4
5

# Ruby 1.9:
KEYS = [:foo, :bar, :baz]

# Ruby 2.0:
KEYS = %i{foo bar baz}

__dir__

현재 실행 중인 파일의 경로를 File.dirname(__FILE__)로 쓸 필요가 없어짐. 이제부터는 __dir__을 사용하면 됨. (지금까지 왜 없었는지 의문임)

UTF-8 default encoding

이제 파일의 default encoding을 UTF-8로 처리함. 파일 첫라인에 매번 #encoding: UTF-8을 써줄 필요가 없음.

나머지…

그외의 자세한 변경사항은 릴리즈 노트를 볼 것.

아래 아티클에서는 Ruby 2.0의 변경점을 예제 코드로 설명하고 있으니 참고.

• Preview of the new features in Ruby 2.0.0
• Ruby 2.0.0 by Example

1.9와의 호환성

ruby 1.9가 ruby 1.8과 ruby 2.0 사이의 과도기적 버전이다 보니, 1.8에서 1.9로 올라올 때만큼의 호환성 문제를 만들것 같지는 않음.

ruby 1.9와의 하위 호환에는 큰문제는 없어보이지만 tricky한 코드를 많이 썼다면 관련문서를 확인해볼 필요가 있음.

ssh key 추가

로컬 머신의 공개키(e.g. ~/.ssh/id_rsa.pub)를 Gateway서버와 접근하려는 서버의 ~/.ssh/authorized_keys 파일에 추가한다. ~/.ssh/authorized_keys 파일이 없으면 생성해서 추가한다. 단, 파일 퍼미션은 600으로 준다.

ssh config

로컬 머신에 ~/.ssh/config 파일에 아래와 같은 내용을 넣는다.

1
2
3
4
5
6
7

Host target.server
   User irteam
   ProxyCommand ssh oddpoet@gateway.server nc %h %p

Host *.dev.server
   User irteam
   ProxyCommand ssh oddpoet@gateway.server nc %h %p

• Host : 특정 서버를 지정한다. ‘*‘로 이름패턴을 사용할 수도 있다.
• User : 타겟서버에 로그인할 계정이름이다.
• ProxyCommand : Gateway 서버 호스트명과 계정명을 사용한다.

다음과 같이 직접 접근하는 것처럼 사용할 수 있다.

1
2

$ ssh target.server # 타겟서버에 접속 (irteam 계정)
$ ssh irteamsu@target.server # 계정을 별도 지정 (irteamsu 계정)

netcat을 쓰지 않는 방법들

OpenSSH >= 5.4

OpenSSH 5.4 이상을 쓰는 경우 -W 옵션을 이용해서 SSH의 netcat mode를 쓸 수 있다.

1
2
3

Host target.server
   User irteam
   ProxyCommand ssh oddpoet@gateway.server -W "%h:%p"

netcat이 없을 경우

Gateway 서버에 netcat이 설치되어 있지 않은 경우에는 아래처럼 설정할 수 있다.

1
2
3

Host target.server
   User irteam
   ProxyCommand ssh oddpoet@gateway.server "/bin/bash -c 'exec 3<>/dev/tcp/%h/%p; cat <&3 & cat >&3;kill $!'"

Single elimination tournament

가장 일반적인 토너먼트 방식. 서든 데스(sudden death)라고도 한다. 1위를 결정하는데에는 효과적이지만 단1패만 해도 탈락하게 되므로 나머지 순위에 대해서는 불명확한 방식이다.

참고 : 싱글 엘리미네이션, Single elimination

Double elimination tournament

싱글 엘리미네이션과 유사하지만 1패 시에는 패자조로 옮겨서 다른 경기의 패자와 싱글 엘리미네이션 방식의 토너먼트를 치룬다. 1패를 하더라도 나머지 경기를 승리하면 최종 우승이 가능하다.

참고 : 더블 엘리미네이션 토너먼트

Swiss system tournament

첫 1 라운드에는 무작위로 경기를 치루게 되고 2라운드에서는 1-2등, 3-4등 끼리 대전하게 된다. 그 이후에는 성적이 비슷한 사람끼리 경기를 치루게 되고 모든 경기에서 승리한 사람이 1명 나올 때까지 라운드를 진행한다.

참고 : Swiss-system tournament, 스위스시스템 토너먼트

Round-Robin tournament

모든 팀과 한번씩은 승부를 하게 하는 방식이다. N개의 팀이 있으면 N-1 번의 라운드가 진행된다. 보통 리그전이라고 부르는 방식이다.

참고 : Round-robin tournament

diff

• git diff

  staged가 아닌 파일들에 대한 diff 결과 출력

• git diff --cached

  staged 파일들에 대한 diff 결과 출력

log

• git log --pretty=format:"%h %s" --graph

  아스키 그래프와 함께 히스토리 출력

• git log --since=2.weeks

  2주 내의 커밋만 조회

undo

• git commit --amend

  직전 커밋을 수정하는 경우

  변경된 파일이 없을 경우 직전 커밋의 메시지만 수정

  변경된 파일이 있을 경우 직전 커밋에 변경 내역 추가 (하나의 커밋으로 처리됨)

• git reset HEAD <file>

  staging area의 파일을 unstange.

• git checkout -- <file>

  수정된 파일을 원복

• git clean -f

  untracked file 삭제

remote

• git remote -v

  리모트 저장소들을 URL과 함께 출력

• git remote show origin

  특정 원격 저장소의 정보를 출력

• git remote add <name> <url>

  주어진 URL의 리모트 저장소를 추가

• git remote rename <old_name> <new_name>

  원격 저장소 이름 변경

• git remote rm <name>

  원격 저장소를 제거

tag

• git tag -a v1.4 -m 'my version 1.4'

  annotated tag 생성 (-a 옵션)

  일반 태그와는 달리 메시지와 tag 생성자의 정보도 저장된다.

• git show <tag_name>

  tag의 정보 및 커밋 정보 확인

branch

• git checkout -b iss53

  iss533라는 이름의 브랜치를 생성하고 checkout.

  아래 명령과 동일

1
2

git branch iss53
git checkout iss53

• git branch -d <branch_name>

  브랜치 삭제

• git branch --merged | --no-merged

  현재 브랜치를 기준으로 merge된(혹은 merge되지 않은) 브랜치를 확인.

• git push <remote> <branch>

  리모트 저장소에 특정 브랜치를 push(처음인 경우 원격저장소에 브랜치 생성됨)

  로컬 저장소의 브랜치와 다른 이름으로 push하려면 git push <remote> <local_branch>:<remote_branch>를 사용.

• git push <remote> :<remote_branch>

  원격 브랜치를 삭제.

rebase

rebase는 merge와 달리 두 branch를 선형으로 합친다.

주의 : 공개 저장소에 push 커밋을 rebase하지 말 것.

• git rebase <master_branch> <topic_branch>

  <topic_branch>를 <master_branch>로 rebase한다.

배포

• git describe master

  가장 가까운 annotated tag로 부터 빌드 넘버를 생성한다.

  e.g. v1.6.2-rc1-20-g8c5b85c

• git archive master --prefix='project/' | greph > `git describe master`.tar.gz

  소스코드의 snapshot 압축 파일 생성 (이메일 혹은 웹사이트 배포용)

• git shortlog --no-merges master --not v1.0.1

  가장 최근 릴리즈(v1.0.1) 이후의 커밋 요약 정보 출력

stashing

작업 도중 commit 하지 않고, 브랜치 변경해야 할 때 작업내역 임시 저장. (modified, staged 모두 보관 )

• git stash

  작업 중인 파일 보관

• git stash list

  저장된 stash 목록 확인

• git stash apply <stash_name>

  stash 적용. stash_name이 없으면 가장 최근 stash 사용.

  --index 옵션을 사용하면 staged 파일들을 staged 상태로 만들어 줌.

blame

• git blame -L <begin_line>,<end_line> <file>

  각 라인을 누가 수정했는지 확인.

  -C 옵션을 주면 파일 이름 출력. (파일 이름이 변경된 경우)

config

• git config --global user.name "John Doe"

  사용자 이름 설정

• git config --global user.email johndoe@example.com

  이메일 설정

• git config --global core.editor vim

  기본 편집기 설정

• git config --global color.ui true

  콘솔 출력에서 컬러 사용

• git config --global core.autocrlf input

  MS 윈도우에서의 개행문자가 문제되는 경우

  개행문자를 윈도우에서는 CRLF 사용. mac, linux, 저장소는 LF 사용함

John Gruber의 Standard markdown 외에도 processor 구현체에 따른 확장 문법들이 존재하는데 그 수도 적지 않고 또한 자잘한 차이점들이 있다.

Standard Markdown

John Gruber가 만든 오리지널이다. 홈페이지에 보면 markdown 문법에 대한 설명과 perl로 만든 html 변환 툴을 제공하고 있다.

markdown은 간결한게 장점이라지만 definition list, table 등에 대한 syntax가 없는게 개인적으로 아쉽다.

PHP Markdown Extra

표준 Markdown에 fenced code block, definition list, table, footnote 등의 문법을 확장했다. 이 후 대부분의 markdown processor들이 이것을 언급할 만큼 markdown 확장의 완전판에 가깝다. PHP 구현체라는 점 때문에 실제 많이 사용되고 있지는 않은듯.

Multimarkdown

HTML 외에도 LaTex, PDF, OpenDocument, OPML 등 다양한 포맷으로 변환을 제공하는 markdown processor다.

PHP Markdown extra 와 비슷한 수준의 확장 문법을 제공하는 듯.

다양한 포맷 지원 외에도 c구현체의 command line 툴이라 많이 사용되는 듯하다.

Github Flavored Markdown

Github에서 코드 snippet 들을 embed 하기 편하도록 확장한 문법

syntax highlighting을 위해서 fenced code block 문법에 언어를 명시할 수 있도록 했음

Maruku

입력으로는 PHP markdown extra 및 기타 확장을 포함 markdown 뿐만아니라 textile까지 지원하고, 출력은 HTML, LaTex, PDF, textile, markdown 을 지원하겠다는 야심찬 툴.

많이 쓰이는지는 모르겠음.

kramdown

이 녀석도 왠만한 확장 문법은 다 지원하고 게다가 ruby 구현체 중에서 제일 빠르다는 markdown processor.

markdown 관련 툴들 중에 ruby로 만들어진게 많은 편인데 느낌상으로는 이게 앞으로 대세가 될 듯.

ruby 구현체로는 BlueFeather, rdiscount 등도 있지만 이게 4~5배 빠르다니까 나머지는 생략.

jekyll

markdown 계의 완소툴!

단순히 markdown 파일을 html로 변환해주는게 아니라 markdown으로 작성한 문서들을 처리해서 사이트를 만들 수 있게 해준다.

요즘 댓글 등의 기능이 사이트 기능이 아니라 SNS 서비스 연동으로 가는게 대세이다 보니 jekyll을 이용해서 DB없이 static한 파일들로 site를 만들고 운영하는게 가능해졌다.

보통 jekyll로 사이트를 생성하고 github page에 올려서 블로그를 운영하는게 요즘 geek들의 대세인듯.

markdown 처리기로 rdiscount, redcarpet, kramdown 를 사용한다.

octopress

“Hacker들을 위한 블로그 프레임웍”이라는 부제를 달고 있는 툴

jekyll 기반으로 만들어진 툴인데 jekyll이 생성한 파일들을 배포하는 기능을 제공한다. GitHub page, Heroku 로의 배포를 지원하며 rsync 이용하여 호스팅 받는 서버로의 배포도 가능하다.

검색해보면 Wordpress에서 Octopress로 갈아탄 사람이 꽤나 있는 것 같다 : 25 Reasons to Switch From WordPress to Octopress

물론 다시 Wordpress로 돌아온 사람도 있다 ^^ : WordPress to Octopress and Back

${var1:-var2}

bash script에 ${VAR1:-VAR2} 의 표현을 종종 봤는데 오늘에야 뭔지 알았다.

다른 스크립트 언어에서 var1 || var2 형태와 같은 표현이다.

1
2
3
4
5
6

${TM_MARKDOWN:-markdown.pl} $filename
# TM_MARKDOWN이 정의되어 있지 않으면 'markdown.pl'을 실행.

INPUT=${INPUT:-$DEFAULT}
# INPUT이 정의되어 있지 않으면 DEFAULT 값을 쓰라는.. 
# 다른 언어에서 'input ||= default' 과 같은 의미임. 

source script.sh or . script.sh

source 명령은 현재 프로세스에서 다른 스크립트를 실행하는 명령이다. 현재 프로세스에서 실행하므로 스크립트에 의한 환경변수들의 생성/수정에 영향을 받게 된다. 주의할 점은 shebang¹은 무시된다는 점이다.

일반적으로 다른 스크립트 파일을 include하는데에 사용한다. 혹은 .bashrc 같은 파일을 수정했을때 다시 로그인 하지 않고 source .bashrc 와 같은 방법으로 다시 .bashrc를 로딩한다.

source script.sh대신 . script.sh로 줄여 쓸 수 있다.

cursor 제어

tput 명령을 이용해서 cursor를 제어할 수 있다.

tput sc

현재 커서 위치 저장

tput rc

커서 위치 복구 (저장했던 위치로 커서가 이동함)

tput cub1

커서를 왼쪽으로 한칸 이동한다.

tput cuf1

커서를 오른쪽으로 한칸 이동한다.

tput ll

마지막 라인의 첫번째 위치로 이동한다.

tput ed

현재 위치부터 화면 마지막 까지 clear한다.

tput lines

터미널의 라인 수를 출력한다.

tput cols

터미널의 컬럼 수를 출력한다.

• 참고 : Colours and Cursor Movement With tput

color 제어

tput을 이용해서도 터미널 컬러 제어가 가능하지만 echo -e와 escape를 이용하는것이 보다 편하다.

\x1b 대신 \e나 \033를 사용해도 되지만 mac osx에서 \e는 정상작동하지 않는다. 그리고 출력시에는 echo -e로 출력해야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

black="\x1b[30m"
red="\x1b[31m"
green="\x1b[32m"
yellow="\x1b[33m"
blue="\x1b[34m"
magenta="\x1b[35m"
cyan="\x1b[36m"
white="\x1b[37m"
color_off="\x1b[39m"

bg_black="\x1b[40m"
bg_red="\x1b[41m"
bg_green="\x1b[42m"
bg_yellow="\x1b[43m"
bg_blue="\x1b[44m"
bg_magenta="\x1b[45m"
bg_cyan="\x1b[46m"
bg_white="\x1b[47m"
bg_color_off="\x1b[49m"

bold="\x1b[1m"
bold_off="\x1b[22m"
underline="\x1b[4m"
underline_off="\x1b[24m"

echo -e "${red}Hello${color_off} ${bg_yellow}World${bg_color_off}"

• 참고 : ANSI Escape Sequences: Colours and Cursor Movement

heckyesmarkdown

웹에서 URL을 입력하면 변환 및 변환결과에 대한 프리뷰를 볼 수 있다. 블로그의 경우 메뉴/사이드바를 제외한 컨텐츠 부분만 변환해준다.

html2text

파이썬 스크립트.

heckyesmarkdown와 마찬가지로 웹 변환도 제공하지만, script를 받아서 로컬에서 수행할 수 있다는게 장점. 옮길 포스트가 많을 때 좋을 듯.

메뉴/사이드바를 포함한 페이지 전체를 변환한다는게 아쉽다.

둘 다 original markdown 포맷만 지원하는듯 하다. table 등은 정상적으로 변환하지 못한다. 어차피 변환 후 수작업을 피할 수 없으니 큰 문제는 아니다.

ruby 사용이 불가능한 환경의 서버라 bash script 로 작업했는데 익숙치 않아서 삽질을 많이함.

Manage host list

알고 있는 호스트 목록을 보여주고 커서를 움직여서 선택

호스트 이름을 입력하면 목록 필터링됨

Tab 자동완성 지원

Bash key map 지원

접속에 성공한 호스트는 목록에 자동으로 추가

호스트에 대한 설명을 추가할 수 있음.

Automatic kinit

비밀번호를 ~/.kinit_passwd 파일에 써놓으면 실행시 자동으로 kinit 인증을 통해 ticket을 발급받는다.

(주의) 비밀번호를 plain text로 기록하게 되므로 보안 문제가 있을 수 있다.

~/.kinit_passwd 파일이 없으면 비밀번호를 입력받음.

스크립트는 gist에 있음. https://gist.github.com/3115022

1
2
3
4
5
6
7
8
9
10
11
12
13
14

_foo()
{
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts="--help --verbose --version"

    if [[ ${cur} == -* ]] ; then
        COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
        return 0
    fi
}
complete -F _foo foo

위와 같은 파일을 만든 후에 아래와 같이 실행하자.

1

$ . sample-completion.sh

이제 foo --[TAB]하면 --help, --verbose, --version이 자동완성 목록으로 나타난다.

작동방식

_foo(){...}는 function 정의이고 complete -F _foo foo는 _foo 함수를 foo에 대한 자동완성 처리를 위해 등록하는 명령이다. 즉, foo 이후에 [TAB]을 누르면 _foo 함수가 실행된다.

자동완성 처리 함수에는 입력변수 COMP_WORD, COMP_CWORD가 전달되고, 자동완성 목록은 COMPREPLY로 리턴된다.

COMPREPLY

shell 함수에 의해서 만들어지는 배열 변수이고 bash가 이 변수를 읽어서 자동완성 목록을 표시한다.

COMP_WORDS

현재 명령행에 있는 단어들에 대한 배열 변수이다.

COMP_CWORD

현재 커서가 있는 단어의 ${COMP_WORDS} 상의 인덱스.

함수는 자동완성에 보여줄 목록을 가지고 적당한 조건으로 필터링한 후에 COMPREPLY 변수에 담기만 하면 된다.

목록 필터링

보통 목록 필터링에는 compgen command를 사용한다.

compgen LIST -- INPUT

compgen은 LIST 중에서 INPUT으로 시작하는 단어만 돌려주는 command이다. 아래 예를 보라.

$ compgen -W "apple banana melon apple-iphone" -- app
apple
apple-iphone

compgen에 대한 자세한 내용은 Unix Command: compgen을 참고하도록 한다.

References

• Bash Completion Part1
• Bash Completion Part2

백업 툴 선택

백업 툴을 선택하는데 고려할 만한 요소는 아래와 같은 것들이 있다.

• 증분 백업(incremental backup)을 지원하는가?
  증분 백업은 바뀐 부분에 대한 정보만 저장하므로써 백업 사이즈를 줄여준다. 보통 daily로 증분 백업, weekly로 full backup을 하게 된다. 주기적인 백업본이 필요한게 아니라면 rsync만으로도 충분하다.

• 백업 설정 및 복구를 위한 GUI를 제공하는가?
  편리한게 좋은거다. 있으면 좋다.

• 백업 수행에 대한 스케쥴을 관리 기능을 제공하는가?
  cron을 직접 설정할거냐의 얘기다. 있으면 편하다.

• 다른 시스템의 스토리지에 원격으로 백업할 수 있는가?
  백업 파일을 다른 머신에 저장할거냐인데 상황에 따라 중요하다.

duplicity는 incremental backup과 remote backup을 지원하는 command line 툴이다. GUI와 스케쥴링 혹은 더 많은 기능들이 필요하다면 백업 유틸리티들의 목록을 보라.

설치

sudo apt-get install duplicity

백업

백업은 아래와 같은 command line으로 수행할 수 있다.

$ duplicity 원본경로 백업경로 

백업경로는 url 형식으로 써야한다. 로컬경로의 경우 file:///path/to/backup 형태로 쓴다.

예를 들어 /etc 디렉토리를 /backup로 백업하려면 shell에서 아래와 같이 한다.

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity /etc file:///backup
$ unset PASSPHRASE

실행되면 아래와 같은 형태의 결과가 출력될 것이다.

--------------[ Backup Statistics ]--------------
StartTime 1342086679.23 (Thu Jul 12 18:51:19 2012)
EndTime 1342086689.32 (Thu Jul 12 18:51:29 2012)
ElapsedTime 10.09 (10.09 seconds)
SourceFiles 2145
SourceFileSize 3577250 (3.41 MB)
NewFiles 2145
NewFileSize 3577250 (3.41 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2145
RawDeltaSize 2646680 (2.52 MB)
TotalDestinationSizeChange 924110 (902 KB)
Errors 0
-------------------------------------------------

검증

백업과 원본의 비교는 다음과 같이 한다.

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity verify file:///backup /etc
$ unset PASSPHRASE

결과는 다음과 같다

Verify complete: 3503 files compared, 2 differences found.

verbose 레벨을 높여서 자세한 결과를 볼 수 도 있다.

$ duplicity verify -v4 file:///backup /etc
Difference found: File . has mtime Fri Dec  2 05:58:42 2005, expected Wed Nov 30 11:42:01 2005
Difference found: File resolv.conf has mtime Fri Dec  2 05:58:42 2005, expected Mon Nov 28 18:58:28 2005
Verify complete: 3503 files compared, 2 differences found.

확인

백업 내용은 아래와 같이 확인할 수 있다.

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity list-current-files file:///backup
$ unset PASSPHRASE

파일 목록이 아래처럼 출력된다.

...
Sat Nov 12 19:58:23 2005 rcS.d/S70xorg-common
Sat Nov 12 20:06:57 2005 rcS.d/S75sudo
Sat Nov 12 20:35:43 2005 readahead
Mon Nov 28 18:57:23 2005 readahead/readahead
Mon Nov 28 18:57:23 2005 readahead/readahead.new
Tue Jan 25 15:03:18 2005 reportbug.conf
Mon Nov 28 18:58:28 2005 resolv.conf
Sat Nov 12 19:55:51 2005 resolvconf
Sat Nov 12 20:06:57 2005 resolvconf/update-libc.d
Wed Aug 17 21:17:26 2005 resolvconf/update-libc.d/fetchmail
Mon Jun 27 07:16:38 2005 rmt
Mon Sep 19 06:41:04 2005 rpc
Sat Nov 19 13:08:21 2005 samba
Thu Jul 21 13:31:14 2005 samba/gdbcommands
Sat Nov 19 13:08:21 2005 samba/smb.conf
Sat Nov 19 13:05:32 2005 samba/smb.conf~
Sat Nov 12 20:00:22 2005 sane.d
Tue Sep 27 09:14:55 2005 sane.d/abaton.conf
Tue Sep 27 09:14:55 2005 sane.d/agfafocus.conf
...

복구

파일 단위 복구

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity --file-to-restore apt/sources.list file:///backup ~/restore/sources.list
$ unset PASSPHRASE

전체 복구

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity restore apt/sources.list file:///backup ~/restore/
$ unset PASSPHRASE

특정 시간에 대한 복구

아래는 4일전 파일 내용을 복구한다.

$ export PASSPHRASE=SomeLongGeneratedHardToCrackKey
$ duplicity -t4D --file-to-restore apt/sources.list file:///backup ~/restore/sources.list
$ unset PASSPHRASE

기타

백업 기본 기능에 충실한 편이고 설정없이 command line으로 작동하는 툴이라 scripting 및 cron scheduling을 활용하기 용이하다.

reference

• Duplicity Backup HOWTO

# install add-apt-repository
$ sudo apt-get install python-software-properties

# add ppa for oracle java
$ sudo add-apt-repository ppa:webupd8team/java

# add pass for airvideo server
$ sudo add-apt-repository ppa:rubiojr/airvideo

이제 oracle jdk 및 airvideo server를 설치할 수 있다.

$ sudo apt-get update
$ sudo apt-get install oracle-jdk7-installer
$ sudo apt-get install airvideo-server

1. static site는 gh-pages라는 branch에 push된다.
2. gh-pages branch는 github에서 프로젝트 페이지가 있다고 가정하는 브랜치이기도 하다.
3. octopress 및 markdown 문서는 source branch로 push하는게 관례인듯.
   관리편의를 위해서 프로젝트 소스와 동일 repository에 gh-pages, source branch를 만들어서 문서 작성 및 퍼블리싱을 함.
4. 메타 정보에 published: false를 넣으면 generate 때 페이지가 생성되지 않음. (draft 작업시 사용)
5. github 프로젝트가 https://github.com/USER/PROJECT라면 gh-pages 브랜치에 있는 페이지들은 http://USER.github.com/PROJECT에서 호스팅된다.
6. github repository 이름을 USERNAME.github.com으로 만들고 그 repository에 site를 publish하면 http://USERNAME.github.com 으로 호스팅됨.
   즉, 프로젝트에 대한 사이트가 아니라 사용자(조직)에 대한 사이트가 됨.

## 데이터 모델 매핑

RDB의 관계형 모델을 RDF 트리플로 매핑하기 위해 W3C의 R2RML이라는 언어를 사용할 수 있다. 기본적으로 테이블의 각 Row를 하나의 Subject로 각 컬럼명과 컬럼값을 predicate와 object로 매핑하게 되는데 R2RML은 DB의 스키마를 어떻게 RDF 트리플로 매핑할지 정의하는 언어라고 할 수 있다.

D2RQ에는 R2RML과 유사한 D2RQ Mapping Language가 있다. 개념적인 부분은 R2RML과 유사하므로 여기서는 D2RQ의 툴을 사용하여 데이터베이스를 RDF로 덤프해본다.

D2RQ 설치

1. D2RQ를 다운로드 받아서 적당한 곳에 압축을 푼다.
2. Java 기반의 툴이므로 JAVA 환경을 준비한다.

mapping rule 생성

• 참고 : D2RQ Generate mapping

D2RQ를 이용하여 DB 스키마에서 매핑룰을 생성하는데 DB 접속정보와 적합한 JDBC 드라이버를 준비하면 된다.

generate-mapping -o outfile.ttl -u user -p pw -d DRIVER_CLASS_NAME JDBC_URL

위와 같이 수행하면 outfile.ttl 에 아래와 같은 DB-RDF 매핑 정보가 생성된다. 테이블 별 s-p-o 매핑 정보 외에도 DB 접속정보도 포함되어 있음을 확인할 수 있다.

@prefix map: <#> .
@prefix db: <> .
@prefix vocab: <vocab/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix d2rq: <http://www.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/0.1#> .
@prefix jdbc: <http://d2rq.org/terms/jdbc/> .

map:database a d2rq:Database;
	d2rq:jdbcDriver "com.mysql.jdbc.Driver";
	d2rq:jdbcDSN "jdbc:mysql://125.209.205.37/tahiti";
	d2rq:username "root";
	d2rq:password "lod";
	jdbc:autoReconnect "true";
	jdbc:zeroDateTimeBehavior "convertToNull";
	.

# Table nsp_user
map:nsp_user a d2rq:ClassMap;
	d2rq:dataStorage map:database;
	d2rq:uriPattern "nsp_user/@@nsp_user.user_id|urlify@@";
	d2rq:class vocab:nsp_user;
	d2rq:classDefinitionLabel "nsp_user";
	.
(이후 생략)

주의 : mysql은 기본 지원하지만 cubrid는 문제가 좀 있다.

mapping rule 수정

위에서 생성한 mapping rule은 컬럼이름이 predicate으로 그대로 사용되므로 실제 적용시에는 이 파일을 수정하여 원하는 vocabulary를 사용하도록 변경하는 것이 필요하다.

이 매핑 파일은 D2RQ mapping language으로 기술되어 있지만, 개념적으로는 R2RML과 유사하고 자동생성되는 파일이므로 추후 R2RML로 매핑이 변경되더라도 RDF 덤프 관련 작업에 큰 변경은 없을 것으로 보인다.

(D2RQ language 역시 RDF 이다)

데이터베이스를 RDF로 덤프할 때 대략 아래와 같은 매핑 정보 수정이 예상된다.

1. vocab을 적절한 이름으로 수정
2. 외부키 등의 relation에 대한 매핑 확인 및 수정

dump!

mapping rule을 수정했으면 dump만 남았다.

mapping rule에 DB접속정보가 포함되어 있으므로 outfile.ttl 파일을 dump rdf 툴을 사용하여 DB를 rdf로 덤프해보자

dump-rdf -b baseURI -o rdf_output mapping-file.ttl

__mapping-file.ttl__에 위에서 만든 mapping rule파일명을 쓰면 되는데, format을 지정하지 않으면 기본 값이 “N-TRIPLE” 포맷으로 출력된다.

현재 SPDY 프로토콜 구현체는 http://dev.chromium.org/spdy에 언급된 대로 아파치 모듈이나 주요 언어들의 웹서버 구현 등이 있습니다. 그러나 SPDY가 SSL위에서 작동하는데다가, NPN(Next Protocol Neotiation) 확장을 필요로 하기 때문에 간단하게 SPDY의 작동을 확인할 목적으로 테스팅 환경을 만들 때 부담스러운 면이 많습니다.

실제 도입할 목적이 아니라 Lab Testing 목적이라면 node.js의 express를 사용하는 express-spdy를 사용하는게 가장 손쉽게 SPDY환경을 구축하는 방법일 것 같습니다. 이 글에서는 The SPDY Book 에서 실습환경 부분 참고하여 linux와 mac에서의 SPDY 서버를 만들어 보겠습니다. 클라이언트는 Google Chrome을 사용하면 세션확인까지 가능합니다.

Edge openssl 설치

SPDY가 SSL 위에서 정상작동하기 위해서는 NPN (Next Protocol Neogtiation)확장이 필요합니다. NPN은 SSL의 다음 계층에서 HTTP를 쓸지, SPDY를 쓸지를 서버와 클라이언트가 협상할 수 있도록 해주는 것이라고 보시면 됩니다. NPN은 현재 edge openssl에서만 지원하고 있으므로 직접 openssl ftp server에서 소스를 받아서 컴파일 해야 합니다.

우선 openssl ftp server 에서 openssl-SNAP-* 으로 시작하는 파일 중 가장 최신파일의 경로를 확인합니다.

mkdir -p $HOME/src
cd $HOME/src
wget ftp://ftp.openssl.org/snapshot/openssl-SNAP-.tar.gz
tar xvzf openssl-SNAP-.tar.gz
cd openssl-SNAP-

이제 아래와 같이 설정을 합니다. (맥OS의 경우 linux-elf 대신에 darwin64-x86_64-cc를 씁니다. 64비트 linux라면 linux-x86_64를 쓰세요.)

./Configure shared \
  --prefix=$HOME/local \
  no-idea no-mdc2 no-rc5 zlib \
  enable-tlsext \
  linux-elf

이제 컴파일하고 설치합니다.

make depend
make
make install

Node.js 설치

기존에 이미 apt-get(ubuntu)이나 brew(osx)로 node.js를 설치했더라도 위에서 컴파일한 edge openssl을 사용하도록 재컴파일해서 별도 설치합니다.

mkdir -p $HOME/src
cd $HOME/src/
wget http://nodejs.org/dist/v0.6.18/node-v0.6.18.tar.gz
tar xvzf node-v0.6.18.tar.gz
cd node

앞서 컴파일 설치한 openssl을 사용하도록 아래와 같이 설정하고 컴파일해서 설치합니다. 설치경로는 마찬가지로 $HOME/local입니다.

./configure \
  --openssl-includes=$HOME/local/include \
  --openssl-libpath=$HOME/local/lib \
  --prefix=$HOME/local/node-v0.6.18
make
make install

Shell 설정하기

$HOME/.bashrc 에 아래 내용을 추가합니다.

# For locally installed binaries
export LD_LIBRARY_PATH=$HOME/local/lib
PATH=$HOME/local/bin:$PATH
PKG_CONFIG_PATH=$HOME/local/lib/pkgconfig
CPATH=$HOME/local/include
export MANPATH=$HOME/local/share/man:/usr/share/man
# For node.js work. For more info, see:
# http://blog.nodejs.org/2011/04/04/development-environment/
for i in $HOME/local/*; do
  [ -d $i/bin ] && PATH="${i}/bin:${PATH}"
  [ -d $i/sbin ] && PATH="${i}/sbin:${PATH}"
  [ -d $i/include ] && CPATH="${i}/include:${CPATH}"
  [ -d $i/lib ] && LD_LIBRARY_PATH="${i}/lib:${LD_LIBRARY_PATH}"
  [ -d $i/lib/pkgconfig ] && PKG_CONFIG_PATH="${i}/lib/pkgconfig:${PKG_CONFIG_PATH}"
  [ -d $i/share/man ] && MANPATH="${i}/share/man:${MANPATH}"
done

NPM설치

curl http://npmjs.org/install.sh | sh

이미 기존 node와 함께 npm이 설치되었다면 이 단계는 건너뛰어도 됩니다.

express-spdy 설치

npm install -g express-spdy

위와 같이 express-spdy를 설치합니다. express-spdy는 express에서 spdy를 사용할 수 있게 확장한 모듈입니다.

샘플 App 만들기

express-spdy를 설치하였으면 application을 생성해봅니다.

cd
mkdir $HOME/projects
cd $HOME/projects
express-spdy spdy-sample
cd spdy-sample
npm install

spdy-sample이라는 이름의 app이 생성되었습니다. app.js 파일을 열어보면 기본적인 app 골격이 나와있습니다. (생성된 코드를 보면 Ruby 개발자분들은 sinatra, rails의 느낌을 받으실듯)

var app = module.exports = express.createServer({
  key: fs.readFileSync(__dirname %2B '/keys/spdy-key.pem'),
  cert: fs.readFileSync(__dirname %2B '/keys/spdy-cert.pem'),
  ca: fs.readFileSync(__dirname %2B '/keys/spdy-csr.pem'),
  NPNProtocols: ['spdy/2', 'http/1.1'],
  push: awesome_push
});

위 코드에서 key, cert, ca 부분은 SSL과 관련된 설정입니다. SSL관련 설정까지 템플릿으로 만들어주니 간단히 만들고 테스트하기에 좋습니다.

그리고 NPNProtocols 부분이 NPN 설정에 대한 부분입니다. Chrome 처럼 SPDY를 지원하는 브라우저와는 SPDY/2로 통신하고, 그 외에는 HTTP/1.1로 통신을 하게 됩니다. 즉, 여기에서 ‘spdy/2′ 부분을 제거하면 HTTP/1.1만 사용하게 되겠죠? 이렇게 SPDY를 ON/OFF하면서 비교테스트 하시면 되겠습니다. 그리고 awesome_push 는 함수 정의부를 보시면 설명이 있을텐데 SPDY의 server push에 대한 부분입니다.

서버 실행하고 확인하기

쉘에서 아래와 같이 실행하면 서버가 뜹니다.

node app.js

자~ 이제 브라우저를 띄워볼까요? https://localhost:3000/로 접근하시면 됩니다. http가 아니라 https입니다!

뭐 별거 없는 썰렁한 샘플 페이지 입니다만, 구글 크롬으로 chrome://net-internals/#spdy 페이지를 열어보시면 그 페이지에 대한 세션이 있음을 확인할 수 있습니다. 게다가 server push된게 1개 있다는 것도 볼 수 있습니다. (awesome_push함수에서 index 페이지에서 사용하는 css파일 하나를 push하도록 되어 있어요.)

그리고… 흔적제거

저만 그런지 모르겠지만 잠깐 테스팅하겠다고 구질구질하게 unstable lib들을 컴파일해서 설치하고 나면 나중에 뒷정리가 짜증이 납니다. apt-get, brew와 같은 패키지 관리툴에서 관리해주는게 아니라서 의존성이 꼬일 수도 있구요.

하지만 openssl, node를 모두 $HOME/local 밑에 설치했기 때문에, $HOME/local 디렉토리만 삭제하면 됩니다. 그리고 .bashrc에 추가했던 부분도 지우면 설치전과 동일한 상태가 됩니다.

참고자료

• The SPDY Book: Making Websites Fly
• Install express-spdy

이 글은 SPDY의 백서 “SPDY : An experimental protocol for a faster web“를 번역한 글입니다.

개요

“웹을 더 빠르게 하자(Let’s make the web faster)” 계획의 부분으로써 우리는 웹페이지들의 반응속도를 높일 수 있는 대안 프로토콜을 실험 중에 있다. 이러한 실험 중에 하나가 SPDY(SPeeDY-스피디라고 읽는다)인데, SPDY는 웹에서 컨텐츠 전송을 위한 애플리케이션 레이어 프로토콜이다. 이 프로토콜 명세와 더불어 우리는 SPDY를 지원하는 구글 크롬 브라우저와 오픈소스 웹서버를 만들었다. 내부 테스트를 통해 우리는 HTTP와 SPDY 위의 어플리케이션의 성능을 비교한 결과 SPDY를 사용할 때 페이지 로드 타임을 64%정도 줄일 수 있었다. 우리는 오픈 소스 커뮤니티에 아이디어, 피드백, 코드, 테스트 결과들을 기여함으로써 보다 SPDY가 빠른 웹을 위한 차세대 애플리케이션 프로토콜이 되길 바란다.

배경 : 웹 프로토콜과 웹 반응속도

현재 웹에서 사용하는 프로토콜은 HTTP와 TCP이다. TCP는 일반적이고 신뢰성있는 전송프로토콜(transport protocol)로써 전송 보증(guaranteed delivery), 중복 제거(duplicate suppression), 순서유지(in-order delivery), 흐름제어(flow control), 혼잡 회피(congestion avoidance) 등을 제공한다. HTTP는 어플리케이션 레벨 프로토콜로써 기본적인 요청/응답의 시맨틱스를 제공한다. 우리는 전송계층(transport layer)에서 반응속도를 개선할 가능성이 더 있다고 생각하지만, 최초에는 어플리케이션 레이어(HTTP) 쪽을 중점적으로 조사를 했다. 불행히도 HTTP는 반응속도에 대해 특별히 고려된 프로토콜이 아니었다. 게다가 현재 네트웍 상에서 전송되는 웹페이지들은 10년 전의 웹페이지들과는 많이 달라졌고, 이에 따라 HTTP가 개발되던 시절에 예상할 수 없었던 개선이 필요하게 됐다. 다음은 HTTP가 최적의 성능을 내는데 저해가 되는 기능들이다.

• 커넥션 당 하나의 요청
  HTTP가 한번에 하나의 리소스만 가져올 수 있기 때문에(HTTP piplelining이 도움이 되지만 여전히 FIFO queue라는 제약이 있다), 500ms의 서버 지연시간이 다른 요청에 대해서 TCP channel의 재사용을 어렵게 한다. 그래서 브라우저들은 다수의 컨넥션을 사용하여 이 문제를 우회하고 있다. 2008년 이후 대부분의 브라우저들은 결국 도메인 당 커넥션 수를 2개에서 6개로 늘렸다.
• 클라이언트만 가능한 요청
  
  HTTP하에서 오직 클라이언트만 요청을 보낼 수 있다. 서버 측에서 클라이언트가 어떤 리소스가 필요하리라는 걸 알더라도 클라이언트에 알릴 메커니즘이 존재하지 않는다. 서버는 클라이언트가 요청할 때까지 기다려야만 한다.
• 압축되지 않는 요청/응답 헤더
  요즘 요청 헤더의 크기는 200byte에서 2KB까지 다양해졌다. 어플리케이션에서 쿠키를 더 많이 사용하고, user agent의 기능이 확장됨에 따라 일벅으로 헤더 크기가 700~800 바이트가 되었다. 업링크 대역폭이 아주 작은 모뎀이나 ADSL 연결에서 헤더의 데이터를 줄이는 것은 요청을 보낼 때의 응답시간을 직접적으로 향상 시킬 수 있다.
• 중복 헤더들
  같은 채널에서의 대부분의 헤더들은 모든 요청에 반복적으로 사용된다. 그러나 User-Agent, Host, Accept* 등의 헤더 값들은 고정된 값이며 일반적으로 재전송이 필요하지 않다.
• 선택적인 데이터 압축
  HTTP는 선택적으로 데이터에 대한 압축을 사용할 수 있다. 하지만 컨텐츠는 항상 압축되어 전송되는 것이 좋다.

기존의 접근방법들

SPDY는 HTTP를 빠르게 하려는 유일한 연구는 아니다. 웹의 반응속도 개선에 대한 제안들 있었고, 그 대부분이 전송계층이나 세션계층에서의 연구였다.

Stream Control Transmission Protocol (SCTP)

TCP를 대체하는 전송계층 프로토콜로써 멀티플렉스 스트림과 스트림 기반 혼잡제어를 제공한다.

HTTP over SCTP

SCTP 위에 HTTP를 작동하자는 제안. Comparision of HTTP Over SCTP and TCP in High Delay Networks 는 두 전송프로토콜 위에서의 성능 비교 연구 결과를 보여준다.

Structured Stream Transport (SST)

“structured streams”는 일반적인 전송층 위에서 사용될 수 있는 가볍고, 독립적인 스트림을 만드는 프로토콜. 이것은 TCP를 대체하거나 UDP의 위에서 작동할 수 있다.

MUX와 SMUX

전송계층과 어플리케이션 레이어 사이에 작동하는 중간 레이어 프로토콜. 스트림의 멀티플렉싱을 지원한다. HTTP/1.1과 비슷한 시기에 제안됐다.

상기 제안들은 웹의 반응속도 문제에 대한 부분적인 해결책을 제공한다. HTTP의 압축, 우선순위 등의 고유의 문제는 여전히 남아있고, 그 아래의 전송계층과 별개의 문제다. 현실상황의 어떤 경우라도 전송계층을 변경하는 일은 매우 어렵다. 대신 우리는 어플리케이션 레이어에서의 문제들을 정리하면서 더 쉬운 해결방안 있다고 생각했다. 이 방법은 기존의 인프라스트럭쳐에 최소한의 변경만 필요로 하고, (우리 생각에는) 상당한 성능 향상을 얻어낼 수 있을 것이다.

SPDY의 목표

SPDY 프로젝트는 웹의 반응속도를 개선할 수 있는 어플리케이션 프로토콜을 정의하고 구현한다. SPDY의 상위 수준 목표는 다음과 같다.

페이지 로드 타임 50% 감소

우리의 사전작업 결과는 이 목표에 이미 근접하고 있다. (아래)

도입 복잡도를 최소화

SPDY는 전송계층으로 TCP를 사용하여 기존 네트웍 인프라스트럭쳐에 어떤 변화도 필요로 하지 않는다.

웹사이트의 컨테츠에 변경이 필요하지 않도록 함.

SPDY는 오직 클라이언트 user agent와 웹서버만 변경하면 되도록 한다.

반응속도의 문제를 해결하기 위한 방법으로 프로토콜을 탐구하는 사람들이 함께 할 수 있도록 한다. 우리는 오픈 소스 커뮤니티와 산업계 전문가들의 협력하에서 이 새로운 프로토콜을 개발하길 원한다.

기타 기술적인 목표들은 다음과 같다.

• 하나의 TCP 세션을 통해 다수의 HTTP요청을 동시에 수행할 수 있게 한다.
• 헤더에 대한 압축과 불필요한 헤더를 제거함으로써 HTTP가 현재 사용중인 대역폭을 줄인다.
• 구현하기 쉬우면서 서버측에 효율적인 프로토콜을 정의한다. 우리는 예외적인 상황들을 줄이고 파싱하기 쉬운 메시지 포맷을 정의함으로써 HTTP의 복잡도를 낮추려고 한다.
• 전송계층 위의 SSL을 보다 보안성있고 기존 네트웍 인프라스트럭쳐에 보다 호환성이 좋게 만든다. SSL은 반응속도 측면에서는 불리하지만, 장기적인 관점에서 웹은 결국 보안 네트웍 연결에 의존하게 될 것이라 믿는다. 추가적으로 SSL의 사용이 기존의 프락시들을 통한 통신이 깨지지 않도록 보장해야 한다.
• 서버가 클라이언트와의 통신을 시작할 수 있게 하여, 가능한 상황에서는 클라이언트에 데이터를 push해줄 수 있도록 한다.

SPDY 설계와 기능

SPDY는 SSL 위에 세션계층을 추가했다. 이것은 하나의 TCP 연결 위에서 다수의, 동시수행되는 스트림을 교차배치할 수 있게 한다.

일반적인 HTTP GET과 POST 메시지 포맷은 동일하다. 그러나 SPDY는 연결위에서 데이터를 인코딩하고 전송하는 새로운 프레이밍 포맷을 정의한다.

스트림들은 양방향이다. 즉, 스트림은 클라이언트와 서버에 의해서 생성될 수 있다.

기본 기능(항상 활성화됨)과 고급 기능(선택적으로 활성화)을 통해서 SPDY는 빠른 반응속도를 얻을 수 있다.

기본 기능

멀티플렉스 스트림

SPDY는 하나의 TCP 연결 위에 무제한 동시 스트림을 지원한다. 하나의 채널에서 요청들이 교차배치되기 때문에 TCP의 효율은 높아진다. 적은 네트웍 연결만 필요하고, 더 적은 수의 패킷만 사용된다.

요청 우선순위

무제한으로 스트림을 병렬화 할 수 있기 때문에 직렬화 문제를 해결할 수 있지만, 이것은 다른 문제를 만든다. 채널의 대역폭이 제한되어 있다면 채널이 막힐 수 있기 때문에 클라이언트는 요청을 블록할 수 있다. 이 문제를 극복하기 위해서 SPDY는 요청 우선순위를 구현한다 : 클라이언트는 원하는 수 만큼 요청할 수 있고, 각 요청에 우선순위를 부여한다. 이것은 네트웍 채널이 중요하지 않은 리소스들 때문에 혼잡해져서 높은 우선순위의 요청이 지연되는 것을 막는다.

헤더 압축

SPDY는 요청과 응답의 HTTP 헤더를 압축한다. 결과적으로 더 적은 수의 패킷과 더 적은 수의 데이터가 전송된다.

고급 기능 (advanced features)

SPDY는 서버에서 스트림을 생성할 수 있는 기능을 제공한다. 서버에서 생성된 스트림은 클라이언트의 요청이 없어서도 컨텐츠를 클라이언트에 전송할 수 있다. 웹개발자는 이 옵션을 2가지 방식으로 설정할 수 있다.

Server push

SPDY는 서버가 클라이언트에 데이터를 푸쉬(push)하는 것을 X-Associated-Content 헤더를 통해서 실험했다. 이 헤더는 클라이언트가 요청하기 전에 서버가 리소스를 푸시하고 있다는 것을 클라이언트에 알린다. 사용자가 사이트에 처음으로 방문하여 첫 페이지를 다운로드할 때, 이 기능은 사용자 경험을 크게 향상시킬 수 있다.

Server hint

자동으로 클라이언트에 리소스를 push하는 대신, X-Subresources 헤더를 사용하여 클라이언트가 특정 리소스를 요청하도록 제안하지만, 컨텐츠를 보내기 전에 클라이언트의 요청을 기다리게 된다. 네트웍 연결이 느린 경우, 클라이언트가 필요한 리소스들을 파악하는 걸리는 수백 밀리세컨드의 시간을 줄여줄 수 있다. 이 옵션은 초기 페이지가 아닌 페이지에서 더 나은 선택이 될 것이다.

기술적인 세부사항은 SPDY draft protocol specification을 참조하라.

SPDY 구현 : 우리가 만들어온 것들

• HTTP와 SPDY로 TCP와 SSL 위에서 효율적으로 응답할 수 있는 high-speed의 in-memory 서버. 우리는 조만간 오픈소스로 이 코드를 릴리즈할 예정이다.
• TCL와 SSL위에서 HTTP나 SPDY를 사용할 수 있는 수정된 구글 크롬. 소스 코드는 여기에 있다. (주: 현재 내부적인 코드네임은 “flip”이지만, 조만간 바뀌게 될 것이다.)
• 페이지들이 정확하게 복사되었는지 검증할 수 있는 테스팅과 벤치마킹 인프라스트럭처. SPDY는 원래의 서버 헤더들과 컨텐츠 인코딩, URLs 등을 그대로 유지한다. 우리는 곧 테스팅 툴과 우리의 결과를 재활용하기 위한 가이드를 릴리즈할 것이다.

사전 실험 결과

우리가 개발한 구글 크롬 클라이언트와 웹서버를 가지고, SPDY의 HTTP 대비 성능을 벤치마크하기 위해서 많은 실험실 테스트를 수행했다.

우리는 1%의 패킷손실을 가지는 홈 네트워크 시뮬레이션 하에서 “Top 100″ 웹사이트 중 25개를 다운로드 해봤다. 각 사이트를 10번씩 다운로드했고, 평균 페이지 로딩 시간을 계산했다. 그 결과 HTTP 대비 TCP 하에서는 27%~60%정도, SSL하에서는 39%~55% 정도의 성능향상을 확인할 수 있었다.

표1 : Top 25 웹사이트들에 대한 평균 페이지 로딩 타임

• 많은 경우 요청 리소스가 속한 도메인의 수와 무관하게 SPDY는 하나의 연결로 모든 요청을 처리할 수 있다. 이 경우에는 모든 다운로드는 완전히 병렬로 진행될 수 있다. 그러나 모든 도메인을 하나의 도메인으로 줄일 수 없는 경우가 있는데, 이 경우에는 SPDY는 각 도메인별로 연결을 만들어야만한다. 이때 연결 생성마다 초기 RTT(round trip time)만큼의 시간이 필요하다.*

그래서 우리는 2가지 모드에 대해서 테스트를 수행했다. 하나는 모든 도메인을 하나로 줄여놓은 경우(즉, 하나의 TCP 연결)와 리소스를 원래 속한 다수의 도메인으로 나누어놓은 경우(즉, 도메인 당 하나의 TCP 연결). 우리는 테스트 결과에 이를 각각 “single-domain”과 “multi-domain”이라고 표기해놓았다. 실제 환경에서의 결과는 이 결과의 사이값이 될 것이다.

헤더 압축의 효과

헤더 압축은 요청헤더의 크기를 88%, 응답헤더의 크기를 85%정도 줄인다. 낮은 대역폭을 갖는 DSL 환경에서(업로드가 375Kbps) 요청헤더 압축은 특정사이트에서 페이지 로딩 시간에 있어서 상당한 성능향상을 보여주었다(리소스 요청이 수가 많은 경우). 헤더압축만 해도 페이지 로딩 시간을 45~1142ms만큼 줄일 수 있었다.

패킷 손실과 RTT(round-trip time)의 효과

우리는 두번째 테스트로 패킷 손실율과 RTT가 결과에 어떤 영향을 주는지 확인하기 위한 테스트를 수행했다. 이 테스트를 위해서 패킷 손실율과 RTT를 실험변수가 아니라 케이블 연결에서 측정을 했다.

우리는 SPDY의 응답시간 향상효과가 패킷손실율이 높아질 수록 증가한다는 것을 알아냈다. 패킷손실율이 2%일때 최대 48%의 성능향상이 있었다. (패킷손실이 2%는 넘어서면 성능향상폭이 줄어들기 시작해서 2.5%가 되면 성능향상율이 떨어진다. 실제 미국내에서 패킷손실율은 일반적으로 1~2%이고, RTT는 평균 50-100ms이다.)

패킷손실율이 증가할 수록 SPDY가 더 나은 이유는

• SPDY는 HTTP보다 40% 정도 적은 패킷을 전송한다. 즉 패킷손실율의 영향을 덜 받는다.
• SPDY는 보다 적은 TCP 컨넥션을 사용한다. 이것은 SYN packet이 손실될 가능성을 줄인다. 많은 TCP 구현에서 이것에 대한 지연은 의외로 크다. (3초)
• SPDY는 재전송 타이머보다는 TCP의 빠른 재전송을 이용하여 TCP를 보다 효율적으로 이용한다.

SPDY는 RTT가 증가하면 더 나은 성능을 보였다. RTT가 200ms일때 최대 27%의 성능향상이 있었다. RTT가 증가할 때 SPDY가 HTTP 대비 더 나은 성능보이는 이유는 SPDY가 모든 요청을 병렬로 처리하기 때문이다. HTTP 클라이언트가 도메인당 4개의 연결을 사용하고, 20개의 리소스를 받아야 한다면, 대략 5RT(round trip)가 걸릴것이다. SPDY는 20개의 리소스를 한번의 RT만에 가져올 수 있다.

표2 : Top 25 웹사이트에 대한 평균 페이지로딩시간 (패킷손실율 별)

SPDY 다음 단계 : 어떻게 우리를 도울 수 있는 방법

우리의 초기 결과는 좋지만, 우리는 그것들을 어떻게 현실 세계에 적용해야 할지 잘 모르겠다. 게다가 SPDY는 더 개선할 여지들이 있다. 예를 들면

• 대역폭 효율성은 여전히 낮다. 전화망의 대역폭 효율이 90%에 근접한다고 하지만, 고속망의 효율은 약 32% 밖에 안된다.
• SSL은 추가적인 지연시간과 도입에 대한 난관들을 가지고 있다. SSL 핸드셰이킹를 위한 추가적인 RTT, 암호화, 프락시에서의 캐싱 문제 등이다. 우리는 SSL에 더 적합하게할 일들이 있다.
• 우리의 패킷 손실율에 대한 실험결과로는 아직 결론을 내릴 수 었다. 패킷 손실율에 대한 연구들이 있었지만, 우리는 웹을 위한 현실적인 모델을 만들기 위한 충분한 데이터를 가지고 있지 않다. 패킷 손실율 시뮬레이션을 더 정교하게 할 수 있는 데이터들을 더 수집할 필요가 있다.
• SPDY의 단일 커넥션은 연결이 끊겨서 복구할 경우 다수 컨넥션보다 때로는 성능이 낮을 수 있다. 특히 RTT가 매우 높을 때는 단일 커넥션보다 멀티플 커넥션이 빠를 수 있다. 언제 SPDY 클라이언트가 새로운 커넥션을 만들거나 기존 커넥션을 끊을지, 이것이 서버에 어떤 영향을 줄지를 더 고민할 필요가 있다.
• 서버는 우리가 만든 것보다 더 지능적으로 구현할 수 있을 것이다. 서버가 스트림을 생성하는 경우, 프리패칭 제안을 위해서 클라이언트 네트웍 정보를 수집하는 등의 케이스에 대해서 더 많은 연구가 필요하다.

이런 문제에 도전하기 위해 당신이 참여하길 원한다면…

SPDY에 대한 FAQ

Q: HTTP piplelining이 이미 응답시간에 대한 문제를 해결하지 않았나요?

A: No. 파이프라이닝이 다수의 요청을 하나의 TCP 연결하에서 병렬로 보내는 것을 지원하고 있지만, 여전히 단일 스트림입니다. 스트립 내의 과정에서 지연이 발생하면(첫 요청이 long request이거나 패킷 손실이 발생하거나해서) 전체 스트림이 지연됩니다. 파이프라이닝은 적용이 어렵기도 해서 대부분의 주요 브라우저에서 기본적으로 비활성화된 채로 남아있지요.

Q: SPDY는 HTTP를 대체하는 겁니까?

A: 아니오. SPDY는 HTTP의 일부분을 대체할 뿐이고, HTTP를 확장합니다. 어플리케이션 계층의 최상위 레벨에서 요청-응답 프로토콜은 여전히 동일합니다. SPDY는 여전히 HTTP 메소드, 헤더 등을 사용합니다. 그러나 SPDY는 커넥션 관리와 데이터 전송 포맷 등의 프로토콜의 다른 부분을 오버라이드합니다.

Q: 왜 이름을 이렇게 지었습니까?

A: 우리는 이름이 ‘속도’의 의미를 내포하길 원했습니다. SPDY(SPeeDY라고 읽음)는 그에 부합할 뿐만 아니라 압축이 어떻게 속도 향상에 도움되는지를 보여주기도 하지요.

Q: SPDY는 전송계층을 변경해야합니까?

A: 전송계층의 보완이 지연을 줄일 수 있는지는 더 연구해봐야 합니다. 그러나 전송계층의 교체는 복잡한 일이고, 어플리케이션 레이어에서 TCP와 HTTP의 비효율적인 부분들을 극복할 수 있다면 현실 적용이 더 쉬울거라고 봅니다.

Q: TCP는 네트웍의 혼잡이나 붕괴를 유발하지 않는지 오랜 시간 사용되면서 검증되었습니다. SPDY가 인터넷을 깨뜨릴 수도 있습니까?

A: 아니오. SPDY는 TCP 위에서 작동하므로 TCP의 혼잡제어 알고리즘들의 혜택을 받습니다. 게다가 혼잡 제어 방법을 수정한 HTTP가 인터넷에서 동작하고 있습니다. 예를 들면, 오늘날의 HTTP 클라이언트는 하나의 서버에 6개의 연결을 동시에 엽니다. 그리고 어떤 HTTP 서버는 초기 congestion window를 4 패킷으로 증가시켰습니다. TCP가 각각의 연결들을 독립적으로 속도를 올릴 수 있기 때문에 서버는 초기부터 효과적으로 24패킷을 보낼 수 있습니다. 다수 연결에서 TCP의 slow-start 문제를 회피한 것이죠. 반면 SPDY는 하나의 연결 위에 다수의 스트림을 구현한 겁니다.

Q: SCTP는 뭡니까?

A: SCTP는 재미있는 대한 전송 프로토콜이에요. 이것은 하나의 커넥션 위에 다수의 스트림을 제공합니다. 그러나 이건 전송계층의 변경을 필요로 해서 가정용 라우터에까지 적용하려면 매우 어렵운 일이 되죠. 또한 SCTP는 은총알(silver bullet)이 아니에요. 서버와 클라이언트 사이의 채널을 효율적으로 사용하려면 어플리케이션 계층의 변경 역시 필요하죠.

Q: BEEP은 뭡니까?

A: BEEP은 비슷한 여러가지 기능을 제공하는 재미있는 프로토콜이지만, 이것은 페이지 로드 타임을 줄이는 것을 목표로 하지 않습니다. 그걸 가능하게 할 몇몇 기능이 없지요. BEEP은 바이너리 프레이밍 대신에 텍스트 기반의 프레이밍을 사용합니다. 이것은 확장성에 있어서 경쟁력있는 좋은 프로토콜이지만, 몇몇 보안 문제들도 있고 정확히 파싱하기가 어렵다는 문제도 있습니다.

Dave Astels의 A New Look at Test Driven Development라는 Article을 번역한 글입니다. BDD(Behavior Driven Development)의 시작점이라 할 만한 글이지요. 2005년도에 씌여진 아티클이지만 개발조직에서 TDD의 수행지표로 code coverage를 사용하고 있는 작금의 현실에, TDD의 의미를 다시금 새겨보는데 도움이 될 듯 합니다.

참고로 BDD(Behaviour Driven Development)를 일반적으로 ‘행위주도개발’이라고 번역하는 듯하지만, 문맥상 Behavior를 ‘행위’로 번역할 경우 의미전달이 힘든 부분이 있어서 ‘기대행동(Behavior)’라고 번역/표기했습니다. 사실 길지 않은 글이니 원문을 읽어보시는 걸 권장합니다. (발번역이라 죄송~)

## A New Look at Test Driven Development

Test Driven Development (TDD)는 요즘 전성기를 맞고 있다. 큰 회사들은 개발자들이 TDD를 교육하는데 많은 돈을 쓰고 있으며, 컨퍼런스에도 TDD는 단골주제다. 내 책(Test-Driven Development: A Practical Guide)은 Jolt award를 수상했다. 모든게 잘 되어 가는 것 같다. TDD를 적용한 모두가 TDD를 완전히 이해하고 있고, 그로 인한 혜택을 누리고 있다. 정말 그런가?

우울한 현실 (Fat Chance!)

내가 얘기해본 10% 정도의 사람들만 TDD가 무엇인지 이해하고 있다. 사실 5% 정도밖에 안될지도… 어디서 잘못된걸까? 사람들은 TDD를 test에 대한 것이라고 생각한다. case라고 생각하지 않는다는 거다.

조금 비슷하기는 하지만, 일반적으로 사람들은 TDD를 low level의 회귀테스트 정도로 본다. 그런데 그건 TDD의 부수적인 이익 정도에 불과하다. 왜 이런 일들이 비일비재하게 일어나는 걸까? 잠깐 과거로 돌아가보자. 만약 my old Coad Letter 의 예전 이슈들을 봤다면, 그곳에서 TDD의 배경이 되는 것들을 찾을 수 있다.

원래 XP는 깨질 수 있는 모든 것들을 테스트한다는 원칙을 가지고 있었다. 
그리고 XP의 테스팅 관습은 Test Driven Development로 진화했다.
XP originally had the rule to test everything that could possibly break. 
Now, however, the practice of testing in XP has evolved into Test-Driven Development.

그들이 테스트를 작성하는 것에 대해 얘기하던 그 시절을 생각해보면, 왜 TDD가 테스트 중심의 어휘들을 가지게 되었는지를 상상할 수 있다. 그리고 이게 사람들이 TDD가 테스트가 목적이라고 생각하게된 이유이다. 그들이 TestCases, TestSuites, Tests 등에 대해 얘기했고, 메소드 이름을 “test”로 시작하게 했기 때문이다. jUnit의 경우 그렇다. nUnit은 test로 메소드 이름이 시작해야 한다는 제약은 없다. (역주: JUnit도 annotation을 활용하게 되면서 이제 method 이름에 대한 명명제약은 없어졌지요.)

결국 TDD로 진화하면서 우리는 전혀 다른 종의 동물을 만들어 냈다. 원래 XP 관습은 깨질 수 있는 모든 것들에 대한 테스트를 작성하는 것이었다. 그래서 테스트를 먼저 작성하는 것에서 시작했고, 결국 TDD가 되었다. 그러나 TDD는 사람들이 생각하는 것처럼 최종점이 아니다. TDD는 단지 다음 단계를 위한 발판일 뿐이다.

사실 unit이라는 단어가 가장 큰 문제다. 그 이유는 첫번째로 unit은 막연한 용어라는 점이고, 두번째로는 그 단어가 코드의 구조적 분할을 의미한다는 점이다. 그래서 사람들은 method나 class를 테스트해야 한다고 생각한다. 우리는 unit에 대해서 생각해야 하는게 아니고, 기대행동(behavior)의 관점에서 생각해야 한다.

unit test에 대한 이런 생각들은 우리들이 코드의 구조에 따라 테스트를 나누도록 한다. 예를 들면, product class들과 test class들이 1:1 관계를 만드는 것이다.

그건 우리가 원하는 게 아니다. 실제로는 기대행동(behaviour) 단위로 나누는 것이 필요하다. 또한 일반적인 unit test보다 더 작은 단위의 레벨에서 작업하는 것이 필요하다. 우리는 작은 단위의 기대행동들에 초점을 맞추어, 매우 작은 단위로 작업해야 한다. 예를 들면, “리스트가 비어 있을 때[Given], 객체에 대해 add() 메소드가 호출되면[When], 리스트에는 하나만 들어있어야 한다[Then].”에서 메소드는 매우 특정 상황(context)에서 특정 매개변수와 함께 호출되고, 매우 특정한 결과가 만들어지는… 이렇게 하나의 메소드에 대해 더 작은 단위로 작업해야 한다.

이것이 바로 “테스트”라는 관점에 의해서 가려져버린 고대의 아이디어이다. 왜 이렇게 되었을까? 사람들이 “Test”에 대해 어떻게 생각하는지 보자.

개발자들은 보통 이렇게 생각한다: “난 모든 테스트를 작성할 생각은 없어”, “이건 매우 단순한 코드라서 테스트할 필요가 없거든”, “테스트는 시간 낭비야”, “난 이미 많이 해봤어”.

프로젝트 매니져들은 이렇게 생각한다: “테스트는 코드가 다 만들어 진 후 하는거야”, “우리는 테스팅할 사람들이 따로 있어”, “당장 거기에 쏟을 시간은 없어”….

사람들은 테스팅에 대한 생각은 이렇게도 부정적이고, 하지 않을 이유를 쉽게도 찾아낸다. 특히나 시간이 없고, 압박이 심한 경우는 더욱….

TDD가 테스트가 아니라면, 뭔데? (So if it’s not about testing, what’s it about?)

TDD는 실제 코딩을 하기 전에 무엇을 만들 것인지 생각해보는 작업이다. 즉, 간략하고, 모호하지 않으며, 실행가능한 형태으로 기대행동(behavior)들을 보다 작은 단위로 명세화(specification)하는 과정이다. 이 과정은 테스트를 작성하는 것일까? 아니다. 이것은 코드가 무엇을 해야하는지에 대한, 명세(specification)을 작성하는 것이다. 그래서 이것은 코드를 작성하기 전에 작성하는 것이 좋다. 더 많은 명세들이 해야할 일을 더 명확히 해주기 때문이다. TDD의 기본 방식대로 조금씩 점진적으로 작업한다. 기대행동(behavior)들을 작은 단위로 명세화하고, 그리고 그것을 구현한다.

이제 TDD가 테스트를 작성하는 것이 아니라, 기대행동(behavior)에 대한 명세에 대한 것이라는 걸 알았다면 관점이 바뀔 것이다. 각 product class마다 test class를 만든다거나, 어떤 method에 대한 test method를 만들어서 테스트한다던가 하는 일들이 얼마나 어이없는 일인지 느껴질 것이다.

그럼 무엇을 할까?(So What to do?)

test라는 관점에서 생각하지 않으려고 해도 JUnit은 그걸 어렵게 만든다. 그럼 이런 일에 걸맞는 새로운 프레임웍이 있을까? ThoughtWorks의 Dan North는 jBehave 라는 프로젝트를 시작했다.

기대행동(behavior) 중심의 어휘와 개념들을 사용하는 행동 중심의 프레임웍을 사용하면, 기대행동(behavior)에 대한 명세로써 생각하는데 도움이 된다.

기대행동 명세 프레임웍(A Behaviour Specification Framework)

기대행동(behavior)에 대한 명세는 어떤 모습이어야 할까? 다음과 같은 부분에서는 jUnit과 같은 것들과 비슷해야 할 것이다.

• 충분히 잘 동작한다.
• 모든 사람들에게 익숙한 형태이다.

가장 큰 차이는 어휘(vocabulary)이다. TestCase를 상속받는 것이 아니라, Context를 상속받는다. 그리고 method를 쓸때 test가 아니라, should로 시작하는 이름을 사용한다. 검증에는 assertions(e.g. assertEquals(exp, act)) 대신, shouldBeEqual(act, exp) 같은 어휘들을 사용한다.

Smalltalk와 Ruby의 경우, class library 안으로 이런 framework을 내장시키는데 좀더 용이하다. 예를 들면, actual shouldEqual: expected 나, result shouldBeNull, [2/0] shouldThrow: DivideByZeroException 과 같은 형태로 쓰는 것이 가능하다.

현재 진행 상황은…(What Now?)

앞에서 얘기한 대로 Dan North는 기대행동(behavior) 명세를 위한 junit 대체물로 jBehave 프로젝트를 시작했다. 나도 조금 다른 방법으로 그 프로젝트에 참여할 것이다. 나는 Smalltalk와 Ruby에서 이러한 아이디어들을 적용해볼 계획을 가지고 있고, 행위기반의 jUnit 버전을 위한 작업을 진행중이다.

요약

TDD에 대해 알고 있는 모든 것이 무용지물이 된다는 얘기인가? 아니다. TDD의 모든 기술을은 BDD에도 적용가능하다. 행위를 기술한다는 접근에서 이것은 TDD와 같다. 여전히 mock을 사용할 수도 있다. 바뀐 것은 어휘와 관점이다.

관점은 매우 중요하다. 프로세스의 가치가 어떻게 바뀌었는가? 다수의 should를 사용하며, should method의 이름들은 보다 명세를 명확하게 해줄 것이다. 예를 들면…

• shouldAllowValidUser
• shouldCheckIsValidBeforeUpdate
• shouldUpdateRecordSet
• shouldWriteToUpdateLog

요약하면…

1. TDD에 대한 문제는 우리들이 서로 다른 방향을 바라보고 있었다는 것이다. 틀린 방향을…
2. 우리는 검증 테스트(verification test)가 아니라, 기대행동 명세(behavior specifications)를 생각하는 것에서 시작할 필요가 있다.
3. 클래스나 메소드에 대한 테스트라는 관점보다, 각각의 기대행동(behavior)의 관점이 더 명확해지므로써, 실행가능한 문서를 가질 수 있게 된다는 잇점이 있다.
4. TDD가 생겨난 이후 어느 누구도 그 이름의 의미를 바꾸거나, 우리가 기대하는 바를 바꾸지 않았다. 그래서 우리는 이 새로운 작업 방식에 BDD:”Behaviour Driven Development” 라는 새로운 이름을 사용하려고 한다.