Linux나 windows 환경을 사용하다가 OS X 환경을 사용했을 때 가장 답답하게 느끼는 부분 중 하나가 backspace 키 속도가 상당히 느리다는 점이다. OS X는 backspace 키를 다른 기능 키와 조합해서 행 단위, 단어 단위 제거 등 더 많은 영역을 한 번에 지울 수 있는 기능을 제공하고 있어서 그런지 초기 지연 값이 상당히 크게 잡혀 있는 것 같다. 반복키 설정을 변경하는 것으로 그나마 다른 OS와 비슷하게 설정할 수 있다.

반복 키 설정은 시스템 환경설정 > 키보드(System Preferences > Keyboard) 에서 느린 키 반응(Key Repeat)과 반응 지연 시간(Delay Until Repeat) 설정을 최대한 빠르게 변경할 수 있지만 최대한 빠르게 설정해도 다른 OS 만큼 빠르게 반응하지 않는다.

터미널을 이용해서 이 반응값을 더 빠르게 조정할 수 있다. 먼저 현재 설정된 값을 확인하기 위해 다음 명령을 사용할 수 있다.

$ defaults read NSGlobalDomain InitialKeyRepeat
$ defaults read NSGlobalDomain KeyRepeat

첫 번째 명령어가 반응 지연 시간을 반환하고 두 번째 명령어는 느린 키 반응을 반환한다. 반응 지연 시간 값을 가장 빠르게 설정했을 때 15, 느린 키 반응 값은 2에 해당한다. 이 값을 변경하기 위해서 다음처럼 입력할 수 있다.

$ defaults write NSGlobalDomain InitialKeyRepeat -int 11
$ defaults write NSGlobalDomain KeyRepeat -int 2

이렇게 값을 입력한 후에 다시 시스템 환경설정에서 해당 슬라이더를 움직이면 값이 다시 초기화 된다. 너무 작은 수치 또는 0을 입력하면 지나치게 민감하게 입력되니 그런 경우에는 위 명령어로 다시 값을 변경하거나 초기화를 위해 시스템 환경설정에서 값을 변경하자.

조금은 생산적인 도구를 소개하는 것도 좋을 것 같아 GitHub 서비스를 위한 도구를 소개한다. GitHub API를 이용한 ghi가 꽤 많은데 API v3에 맞춰 현재까지 관리되고 있는 도구로 ghi가 있다. Github 리포지터리에 등록된 issue를 CLI에서 관리할 수 있도록 기능을 제공한다.

brew로 설치하거나 Ruby로 작성되어 있어서 gem으로도 설치 가능하다.

$ brew install ghi
$ gem install ghi

curl로도 설치할 수 있다.

$ curl -sL https://raw.githubusercontent.com/stephencelis/ghi/master/ghi > ghi && \
$ chmod 755 ghi && mv ghi /usr/local/bin

설치 후에 토큰을 발급 받기 위해서는 다음 명령이 필요하다.

$ ghi config --auth <GitHub 사용자ID>

맥에서는 키체인을 이용해서 토큰과 사용자 정보를 저장하는데 키체인의 문제인지 제대로 동작하지 않는다.¹ 그래서 내 경우는 수동으로 입력했는데 token을 위 방법으로 발급 받은 다음, GitHub access tokens 페이지에서 생성된 토큰을 Edit > Regenerate token 해서 다음과 같이 환경변수를 지정해줬다.

$ export GHI_TOKEN=<재생성한 access token>

이제 ghi를 입력하면 현재 배정된 이슈 목록이 출력되며 전체 목록은 필터 플래그를 이용해 ghi list -f 'all'로 확인할 수 있다. ghi help 및 ghi help <명령어>로 도움말을 확인하자.

다른 도구도 많이 있는데 대부분 v2이 deprecated 된 이후로 업데이트 되지 않거나 전혀 관리되지 않고 있어서 아쉽다.

spring의 gradle로 프로젝트 시작하기를 따라하며 정리한 글이다.

먼저 brew로 java와 의존성 및 빌드 관리/자동화 도구인 gradle을 설치한다.

$ brew tap caskroom/cask
$ brew install brew-cask
$ brew cask install java
$ brew install gradle

문제없이 설치되었다면 버전 정보를 출력한다.

$ gradle -v

gradle로 프로젝트를 초기화한다.

$ gradle init

초기화하면 기본적으로 gradle wrapper를 생성해주는데 이 스크립트는 gradle이 없는 환경에서도 gradle을 사용할 수 있도록 돕는 스크립트다.

예제 클래스를 먼저 작성한다.

$ mkdir -p src/main/java/hello

// src/main/java/hello/HelloWorld.java

package hello;

public class HelloWorld {
  public static void main(String[] args) {
    Greeter greeter = new Greeter();
    System.out.println(greeter.sayHello());
  }
}

// src/main/java/hello/Greeter.java

package hello;

public class Greeter {
  public String sayHello() {
    return "Hello world!";
  }
}

빌드와 관련한 모든 설정은 build.gradle에 담겨 있다. 빌드를 위해 다음 내용을 build.gradle에 추가한다.

apply plugin: 'java'

그리고 빌드를 하면 build 디렉토리를 생성하고 빌드를 진행한다.

$ gradle build

아래 내용을 추가해서 어플리케이션을 직접 구동할 수 있다.

apply plugin: 'application'
mainClassName = 'hello.HelloWorld'

gradle을 설치한 환경에서는 gradle을 사용해도 되겠지만 다음과 같이 앞에서 생성한 wrapper를 사용해서 구동할 수 있다.

$ ./gradlew run

다음은 튜토리얼에서 최종적으로 작성하게 되는 gradle 파일이다.

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'application'

mainClassName = 'hello.HelloWorld'

// tag::repositories[]
// 서드파티 라이브러리의 소스 출처를 추가한다
repositories {
    mavenCentral()
}
// end::repositories[]

// tag::jar[]
// 빌드에서 jar를 생성할 때 메타를 추가한다
jar {
    baseName = 'gs-gradle'
    version =  '0.1.0'
}
// end::jar[]

// tag::dependencies[]
// 버전 의존성을 추가한다
sourceCompatibility = 1.8
targetCompatibility = 1.8

// 의존 라이브러리를 추가한다
dependencies {
    compile "joda-time:joda-time:2.2"
}
// end::dependencies[]

// tag::wrapper[]
// wrapper로 설치할 gradle version을 정한다
task wrapper(type: Wrapper) {
    gradleVersion = '2.3'
}
// end::wrapper[]

bash나 zsh에서는 작업 제어(job control)을 기본적으로 제공하고 있다. 현재 동작하고 있는 프로그램을 백그라운드로 보내거나 백그라운드에 있는 프로그램을 다시 꺼내서 사용하는 것도 가능하다.

평소에 다음과 같이, 끝에 &을 붙여 명령어를 사용해본 적이 있다면 자신도 모르는 사이에 이미 사용하고 있다는 뜻이다.

$ npm start &
[1] + running    npm start

먼저 간단하게 예제를 보자. 다음 예시는 간단하게 sleep을 사용하고 있다. &와 함께 실행하면 백그라운드로 구동한다는 의미다.

$ sleep 10 &
[1] 3901
$ sleep 20 &
[2] 3902
$ sleep 30 &
[3] 3903

현재 실행하고 있는 작업 목록은 jobs로 확인할 수 있다.

$ jobs
[1]   running    sleep 10
[2] - running    sleep 20
[3] + running    sleep 30

현재 실행하고 있는 프로세스를 일시 정지하고 백그라운드로 보내는 키는 Ctrl + z다. (tmux를 사용하고 있다면 이 키로는 동작하지 않을 수 있다.)

$ vim hello
# <Ctrl + z>을 누름
[1] + 4049 suspended   vim hello

다시 해당 프로세스를 포그라운드로 부르기 위해서는 fg 명령을 사용할 수 있다. fg 뒤 인자는 직접 입력해도 되지만 tab 키를 누르면 알아서 자동완성 해준다.

$ fg %1
$ fg %vim\ hello

만약 백그라운드에서 일시 정지가 아니라 계속 구동하려고 한다면 어떻게 해야 할까? 그때는 백그라운드 명령인 bg를 사용할 수 있다.

$ sleep 30
# <Ctrl + z>을 누름
[1] + 4050 suspended  sleep 30
$ bg %sleep
# 아래처럼 간단하게 가능
$ %sleep &
[1] - 4050 continued  sleep 30
$ jobs
[1] - 4050 running    sleep 30
$
[1] - 4050 done       sleep 30

알고 나니 별 내용은 아니지만 지금까지 전혀 모르고 사용했다는 점에 반성하는 마음에서, 그리고 매번 백그라운드를 끌 줄 몰라서 kill을 당해야만 했던 수많은 프로세스를 추모하며 작성했다. 지금까지 몰랐다는데 참 억울하지만 앞으로는 프로세스 번호 찾으려고 애쓸 일이 없다는 점이 참 감사하다.

터미널에서 사용할 수 있는 트위터 클라이언트는 상당히 많은 편이다. 이전까지 node-tweet-cli를 사용하고 있었는데 스트림도 지원하고 간단하게 트윗을 하기엔 편했지만 멘션에 답하는 기능이 없어서 여간 불편했었다. 그러던 중에 rainbowstream을 보고 나서 한 눈에 반해 바로 옮겨타게 되었다.

이 클라이언트는 현존하는 어떤 클라이언트보다 가장 힙스터스러운 트위터 환경을 구축해준다. 쇼케이스 보면 반하지 않을 수 없다.

이 툴은 pip를 통해서 설치할 수 있다. 전역 설치를 하고 싶다면 그냥 설치하면 된다.

# 그냥... 설치
$ sudo pip install rainbowstream

설치 가이드에서는 venv를 사용하길 권장하고 있다.

# venv 설치
$ virtualenv venv
$ source venv/bin/activate
$ pip install rainbowstream

파이썬이 없거나 환경이 필요한 경우라면 리포지터리를 참고해서 설치하자.

처음으로 실행하면 트위터의 토큰을 발행하기 위한 로그인 창이 뜬다. 토큰을 발행해서 숫자를 집어 넣으면 그때부터 사용 가능하다.

트윗 작성은 t <내용>으로 할 수 있으며 h를 입력하면 도움말 전체를 확인할 수 있다. 가장 마음에 드는 부분은 아예 쉘처럼 동작한다는 점인데 실행하는 순간부터 스트림을 시작하고 매 스트림되는 메시지마다 id를 부여해서 rep <id> <내용> 식으로 멘션에 대한 응답도 쉽게 작성할 수 있다. 스트림은 p, r로 멈추고 다시 시작하는 것도 가능하다. 쉘 종료는 q로 가능하다.

심지어 테마도 지원하니 취향에 맞게 컬러 스킴도 지정해보자. theme으로 사용 가능한 테마 목록을 확인하고 theme <테마명>으로 변경할 수 있다.

tmux와 함께 사용한다면 타임라인과의 분리불안을 해소하는 것과 동시에 본업(?)을 지속할 수 있는 환경을 구성할 수 있으니 tmux를 필히 사용하자.

구글 검색을 위해서 파이어폭스를 켜며 문득, ‘그냥 터미널에서 구글 검색할 수 있는 방법은 없을까?’ 라는 생각이 들어서 검색해봤더니 역시 멋진 분이 googler라는 도구를 멋지게 만들어서 공유하고 있었다.

googler는 파이썬으로 작성되어 있어서 파이썬이 기본적으로 필요하다. OS X나 Linux 환경 대부분은 기본적으로 설치되어 있는 버전과 함께 잘 구동된다.

OS X 환경에서 Homebrew를 사용하고 있다면 brew로 쉽게 설치할 수 있다. 최근에 추가된 패키지라서 brew update가 필요할 수도 있다.

$ brew install googler

Linux 환경에서는 Homebrew Folk인 Linuxbrew를 사용해서 설치할 수 있다. 하지만 내 lubuntu 환경은 그렇게 공간이 넉넉한 편이 아니라서 git 리포지터리를 통해 바로 설치했다.

$ git clone https://github.com/jarun/googler/
$ cd googler
$ sudo make install

검색은 간단하다. googler <검색어>로 검색할 수 있는데 그 외 플래그 등 옵션은 googler를 입력하면 확인할 수 있다. 검색 결과에서 다음 검색 결과를 확인하는 것도 가능하며 열고 싶은 페이지의 숫자를 입력하면 웹브라우저로 열어준다.

이제 구글 검색도 힙하게 터미널에서 하자!

지난 달 노트북을 구입하고 매일 들고 다니면서 유용하게 사용하고 있어 간단하게 사용기를 남겨본다. 4월이면 애플이 새로운 맥북을 내놓을 거라는 이야기가 계속 있어서 노트북을 구입하지 말고 기다려야 하나 고민했었다. 하지만 당장에 해야 할 일이 워낙에 많았던 터라 노트북이 필요했었는데 그렇다고 큰 돈 안쓰고 저렴한 노트북으로 알아보다가 구입하게 된 것이 Dell Inspiron 11 3000이다.

장점

배터리가 엄청 오래간다. 들고 다니면서 하루 1시간 정도 사용하는데 일주일에 한 번 정도 충전한다. 사양이 낮은 것인지 배터리 효율이 좋은 것인지는 모르겠다.

소음이 없다. 이건 팬이 달려 있지도 않을 뿐더러 스토리지가 메모리타입이기 때문에 별도의 팬이 필요하지 않은 것 같다. 다만 좀 과하게 사용하면(= 파이어폭스 창 2개 켜고 터미널 열면) 발열이 좀 있는 편이다. 팜레스트나 키보드보다는 노트북의 하판이 뜨거워지는 편이라서 그렇게 뜨거운걸 느끼진 못하지만 아마 더 많은 연산을 하면 키보드쪽도 뜨거워질 것 같다.

키보드가 준수한 편이다. 키감도 괜찮은 편이고 실제 키보드보다 사이즈가 작아지면 의례 레이아웃을 이상하게 만들거나 키 배치를 어색하게 만들어서 불편하기 마련인데 작은 사이즈에도 불편함이 거의 없는 편이고 방향키 레이아웃도 여유가 있어서 편하다. 키감은 펜타그래프 치고는 좀 얕게 느껴지지만 질이 꽤 좋다. 이런 키보드에서는 메타키를 Fn 조합으로 많이 제공하는데 Delete나 Insert는 일반 키로 설정되어 있어서 특히 마음에 들었다.

단점

모니터 시야각이 좀 심하다. 이건 TN 패널의 고질적인 문제라고 하는데 충분히 밝은 곳이 아니면 이상하게 눈이 쉽게 피곤해지는 느낌이다. 이 노트북에서 하는 작업이 코드를 작성하거나 이미지를 봐야 하는 작업이 아니라 대부분 터미널에서 글쓰고 일기쓰는 정도 일만 하고 있기 때문에 크게 민감하게 생각하고 있진 않지만 만약 그런 작업이 필요하다면 별로 추천하고 싶지 않다. 아쉽게도 이 가격대의 노트북에서 TN 안쓰는 경우를 찾기가 힘들다.

흰지가 조금 불안한 편이다. 무릎에 놓고 사용하기에는 모니터 각도가 충분하게 젖혀지지 않는데다가 약간 힘을 주면 흰지와 모니터 사이가 벌어지는 것을 볼 수 있다. 출퇴근하면서 사용할 때 다른 사람이 내리다가 가방 같은 것으로 모니터를 치면 이게 부러지거나 할 것 같아 불안하다. 그렇다고 아주 헐렁하거나 톡 쳐도 부서질 것 같은 내구성인 것은 아니다.

저가형 노트북 답게 트랙패드가 좋지 않다. 염가 노트북에서 투 핑거 휠까지 지원한다는 것이 놀랍긴 하지만 작은 키보드를 사용해서 입력하다보면 손뼘에 닿아 커서가 이동해버릴 때가 있다. linux에서 키보드 입력 중에 트랙패드 입력 차단하는 설정이 있어서 설정을 해뒀었는데 막상 커서를 사용하게 될 때는 불편함이 있어서 그냥 익숙해지기로 했다. 필요할 때는 민감하게 반응 안하고 필요하지 않을 때는 너무 민감해서 참 친해지기 어렵다.

그 외에는

그 외 짧은 코멘트는 다음과 같다.

• Windows 10은 생각보다 무거워서 lubuntu를 설치했는데 만족하고 있다.
• 무게는 적당하다. 무겁다고 생각해본 적은 없다.
• 플라스틱이라 모서리가 깨질까 걱정이 되긴 한다.
• HDMI 포트가 있는데 쓸 일이 아직 없어서 잘 모르겠다.
• 마이크로SD를 지원한다. dropbox가 안되는 상황에서 백업용으로 사용하고 있다.

추천한다면

• 리눅스 설치해서 터미널만 써도 상관 없는 사람
• 간단한 웹서핑, 글만 쓰면 되는 사람
• 300불 예산 언저리에서 구입해야 하는 사람
• 노트북 소음이 싫은 사람
• 충전 자주 하는 귀찮음이 싫은 사람
• 데스크탑이나 다른 중요한 일을 처리할 수 있는 컴퓨터가 있는 사람
• 심심한 사람

추천 안한다면

• 조금 사양 높은 게임 해야하는 사람 (에뮬 게임이라면 뭐…)
• 메인 노트북으로 사용해야 하는 사람
• 탭 3개 이상 켜고 인터넷 하는 사람
• 윈도만 써야 하는 사람 (XP 같은거 설치하면 빠를지도)
• 좋은 디스플레이가 필요한 사람
• 예산을 늘릴 수 있는 사람

지금까지 사용한 경험으로는 충분히 본전을 뽑을 것 같은 기분이 든다. 터미널에도 점점 친해지고 있고 웹브라우저 없이도 사는 방법을 배우고 있다. (뭔가 이상하지만) 새 맥북이 나오더라도 당분간은 이 노트북으로 계속 지내게 될 것 같다.

code.org 이후로 코딩 교육에 관한 이야기를 자주 보게 된다. 한국에서도 공통 교과에 코딩을 포함해야 하는가에 대한 논의를 많이 접할 수 있었다. 기술 발전에 따라 기초 학문으로 가치가 높아지고 있고 수학과 같이 논리적 사고력을 배양할 수 있다는 의견부터 현장에서 제대로 된 교육이 가능한가에 대한 의문, 코딩 학원과 같은 사교육 열풍만 불 것이라는 부정적인 의견까지 다양했다.

코딩 교육이 옳은가, 옳지 않은가에 관한 이야기보다는 실제로 교육을 위해 움직이고 있는 모습을 보면 먼 이야기가 아니라 이미 현실이다. 앞서 예로 들었던 code.org에서는 프로그래밍을 통해 데이터를 분석하거나 문제를 해결하는 과정을 제공하고 있다. 영국의 Code Club 프로그램에서는 만9-11세를 대상으로 스크래치부터 기본적인 웹개발(HTML, CSS), 파이썬 등을 학습하는 커리큘럼을 학교 현장에서 제공하기 위해 힘쓰고 있다. 찬반을 하기엔 이미 깊숙이 들어와 있고 시행착오를 넘어 성숙하고 있는 단계로 느껴진다.

어릴 때 프로그래밍을 가르치는 것이 정말 효율적인가에 대한 생각은 사실 미술과 음악, 작문과 같이 자기 생각과 관점을 표현하는 수단이라 생각하면 더 와 닿는다. 자신을 드러내는 또 다른 방법을 하나 더 배운다고 생각한다면 그게 크게 잘못되거나 어렵고 힘든 일이라고는 생각이 들지 않는다. 내 또래 세대는 방과 후 프로그램에서 배운 HTML로 학급 웹사이트를 만들고 포켓몬 도감을 만드는 데 시간을 썼다. 한 학년을 마치며 그 기간을 기억하기 위해 학급 문집을 만들고 각자 기념할 만한 물건을 타임캡슐에 넣어 묻었던 일을, 지금 어린 세대는 오늘을 기억하려는 방법으로 스크래치로 만든 애니메이션을 함께 공유하고 마인크래프트에서 함께 지은 건물과 탐험했던 지역을 보며 회상한다. 지금 당장에도 이 세대가 컴퓨터를 통해 만들어내는 수많은 미디어를 Youtube에서 직접 눈으로 확인할 수 있다. 지금의 어린 세대를 가까이서 관찰할 기회가 많지 않아 일반화하기 어렵지만 저스틴님 댁에 놀러 가서 아이들과 이야기할 때마다, 초등학교 다니는 우리 집 막냇동생이 운영하는 블로그를 들어갈 때마다 이 세대의 삶에서 컴퓨터를 어떻게 소화하고 활용하는지는 이미 내 상상 이상이다.

어릴 때 코딩을 배우는데 어렵게 느끼지는 않을까? 이미 추상화된 아이디어가 일반화된 세대에게는 Car, MyCar 클래스를 만들어 설명하기보다 “마인크래프트에서 블럭의 종류는 여럿이지만 블럭은 다 같은 크기고 가방에 넣을 수 있어.” 식으로 훨씬 쉽게 이해할 수 있게 된다. 놀이터에서 그네와 시소를 타고 학교에서는 그 과학적 원리에 대해 배웠던 것과 같이 이런 환경에 일찍 노출된 세대라면 코딩을 배운다는 것 자체가 어색하지 않다. 우리의 사고와 접근으로는 어렵다고 생각할지 몰라도 마우스와 키보드 인터페이스보다 터치 스크린을 먼저 접한 아이들이 이해하기에는 훨씬 간단하고 익숙한 내용일지도 모른다.

내가 교육 현장의 일선에 있는 것도 아니고 아직 자녀가 있는 처지는 아니라서 이게 좋고 나쁨을 이야기하기엔 쉽지 않다. 하지만 이런 변화는 지금의 세대에겐 논쟁거리가 될 수 있어도 이후 세대에겐 당연하고 필수적인 생활 요소가 될지도 모른다. 지하철에서 책을 읽지 않고 스마트폰만 만진다고 못마땅하게 생각하는 사람들이 있지만, 지금의 어린 세대에게는 그런 모습을 당연하다고 생각할 것이다.¹ 지금의 홈 오토메이션은 별 볼 일 없게 느껴지지만, 미래 세대는 훨씬 많은 모듈을 사용해 직접 로직을 구성하고 활용하게 될 것이고 이처럼 일상에서 프로그래밍적 사고가 필요한 일이 더욱 많아져 지극히 당연한 교육이 될지도 모른다. 그때쯤 되면 이런 논쟁이 있었다는 사실을 산업혁명 시기 러다이트 운동과 나란히 배울 수도 있다.

이런 이야기 이면에는, 영미권과 한국을 비교하게 되면 상대적으로 좁은 언어권에서 나타날 수밖에 없는 한계를 느끼게 된다. 영국의 Code Club의 커리큘럼이 호주로도 들어와서 호주판 Code Club 네트워크를 순식간에 구축한 것과 같이 동일 언어권에서는 빠르게 확산하고 지식이 공유된다. 한국어 사용자에게 있어서 상대적으로 소외되는 느낌이 들 수밖에 없다. 그렇다고 학습에서 영어를 직접 사용하거나, 생성자, 소멸자, 발생자와 같은 한문 조어를 통해 배우는 것도 부차적인 학습이 따라와 부담을 느낄 수밖에 없다. 이런 문제를 뒤로 밀어둔다 하더라도, 귤화위지라는 말과 같이, 해외 사례를 모델로 삼아 번안된 교육안으로 적용하는 일은 단순하게 여겨질지 몰라도 옮겨 심는다고 모든 일이 저절로 해결되지 않는다. 환경도 필요하고 인력도 필요하다.

나도 방과 후 교육으로 HTML을 배우고서 웹을 처음 알게 되었고 그 이후로도 웹 프로그래밍이나 컴퓨터에 계속 관심을 두게 된 것은 자연스러웠다. 나는 문과를 선택했고 대학도 지리교육을 전공했다. 코딩을 배운 경험 자체에 대해서는 전혀 불평할 여지가 없었다. ‘문제를 해결하는 논리적 접근 방식을 배웠다.’ 식으로 경험을 말하기에는 쉽게 드러나지 않아 판별하기 어려운 부분이다. 하지만 프로그램을 작성하는 방식, 코딩을 배운 것이 내 삶에 도움이 되지 않았다고 생각하는 편이 더 이상하고 어색하다. 내 삶에 있어 도움이 되었다고 보고 있어서 이 교육이 필요하다고 마음으로 느끼고 있다.² 그래서 나에게는 더더욱 “코딩 교육이 필요하다, 필요하지 않다” 보다는 어떻게 해야 제대로 된 교육이 가능한가에 대해 더 관심이 간다.

앞에서 이야기한 것과 같이 “필요 없다”고 말하기엔 이미 현실이다. 환경과 인력의 부족으로 포기하는 것보다 오히려 현업에 있는 사람들이 좀 더 제대로 된 커리큘럼과 프로그램을 가질 수 있도록 목소리를 더 내야 한다. 개인이기 때문에 할 수 있는 것이 없다고 느껴질지 모르지만, 개인의 경험이 공공의 지식이 되는 과정 없이는 교육적 토대와 사회적 기틀이 생겨나기 어렵다. 나는 어떻게 배웠고 어떤 부분이 쉽고 어려웠다는 이야기를 공유해야 한다. 내가 아는 지식을 타인, 더 나아가 다음 세대가 쉽게 이해할 수 있도록 나눠야 한다. 그리고 이런 지식 데이터베이스를 교육에 어떻게 녹일 수 있는지 담론을 구성해야 한다. 그 역할이 우리 세대가 해야 할 일이라 생각한다.

맥 환경을 사용할 때는 Ctrl + Space를 사용하고 있지만 지금 lubuntu를 설치해서 사용하는 노트북은 키보드 사이즈가 작은 문제인지 Ctrl + Space가 손에 잘 익지 않았다. 그래서 한영 전환키로 우측 Alt 키를 배정해서 사용하고 있었는데 작성하다보면 변경이 되었다 말았다 하는 문제가 있었다. 단순히 입력기 문제라고 생각하고 있었는데 Alt키의 기본 동작이 동시에 나타나는 문제였다.

lubuntu는 xkb를 통해 키보드 맵핑을 처리하고 있다. /usr/share/X11/xkb/symbols/altwin을 열어서 다음 부분을 확인한다.

$ sudo vim /usr/share/X11/xkb/symbols/altwin

// Meta is mapped to second level of Alt keys.
partial modifier_keys
xkb_symbols "meta_alt" {
    key <LALT> { [ Alt_L, Meta_L ] };
    key <RALT> { type[Group1] = "TWO_LEVEL",
                 symbols[Group1] = [ Alt_R, Meta_R ] };
    modifier_map Mod1 { Alt_L, Alt_R, Meta_L, Meta_R };
//  modifier_map Mod4 {};
};

RALT 즉, 우측 Alt키에 Alt_R, Meta_R이 배정된 것을 확인할 수 있다. 이 키의 키맵을 아래와 같이 Hangul로 변경한다.

// Meta is mapped to second level of Alt keys.
partial modifier_keys
xkb_symbols "meta_alt" {
    key <LALT> { [ Alt_L, Meta_L ] };
    key <RALT> { type[Group1] = "TWO_LEVEL",
                 symbols[Group1] = [ Hangul ] };
    modifier_map Mod1 { Alt_L, Alt_R, Meta_L, Meta_R };
//  modifier_map Mod4 {};
};

키맵 설정은 컴파일 과정을 거쳐 /var/lib/xkb 위치에 xkm 파일로 저장되어 있다. 해당 파일을 제거한다. 제거하면 위에서 변경한 설정을 반영한 새로운 파일을 생성할 준비가 끝난다.

$ sudo rm /var/lib/xkb/*.xkm

이제 로그아웃, 로그인을 다시 해서 위에서 제거한 파일을 다시 생성한다. 오른쪽 Alt키가 Hangul키로 변경 된다. 한글 입력기에서 한영 전환키를 다시 설정하면 RALT 대신 Hangul 키로 잡히고 이제 입력이 올바르게 잘 동작하는 것을 확인할 수 있다.

이상한모임 주관으로 진행된, 장소에 구애받지 않고 어디서나 참여할 수 있는 컨퍼런스, 이모콘 2016 S/S에 발표자로 참여했다. 이모콘은 누구든 자신의 경험을 공유할 수 있는 기회를 제공하는 형식으로 진행되는 온라인 컨퍼런스다. 지난 1회에서는 스탭으로 참여했지만 2회에서는 스피커로 참여할 수 있었다.

주제 선정은 한참 고민했었지만 개인적인 일정에 생각보다 시간을 만들지 못해서 이전에 포스팅한 적이 있던 NodeJS의 제너레이터에 관한 내용을 선정했다. 더 미리 준비해서 시작했다면 다른 재미있는 내용을 했을텐데 좀 더 일찍 주제를 정했으면 하고 후회를 좀 했다. 그래도 이전에 작성한 포스트는 koa를 설명하기 보다는 generator와 spawn하는 함수를 작성하는데 너무 많은 분량을 할애해서 정작 koa 얘기가 너무 적었던 반면에 이번엔 koa를 더 설명해야지 하는 욕심이 있었다.

라이브로 진행을 하고 싶었지만 긴장해서 진행에도 방해되고 발표도 신경쓰면 너무 정신 없을 것 같았고, 30분에 맞추기 위해 여러 차례 연습을 하는 것보다 단 편집을 고려해서 한 번 촬영 후 편집으로 30분에 맞추는게 낫겠다 판단해서 녹화를 했다. 슬라이드 준비에 1시간 반 정도 걸렸고 촬영에 45분, 편집에 2시간 반 정도 걸려서 총 4시간 40분 정도 시간을 사용했다. 결과적으로는 연습해서 그냥 하는 시간과 별 차이 없는 느낌이 들었지만 중간에 불필요한 설명을 자른다거나, 미리 넘어가버린 슬라이드를 보정한다거나 하는 부분에 있어서는 많이 편했다. 아무래도 이모콘 특성 상 녹화로 대체할 수 있다는 것은 장점이겠지만 다음에는 라이브로 할 수 있도록 준비를 미리 해야겠다는 생각을 편집하는 내내 했다.

영상 편집은 Screenflow 라는 도구를 사용했다. 예전에 번들로 구입한 적이 있었는데 한번도 사용해보지 않다가 처음으로 제대로 사용했다. 스크린/사용자 녹화, 편집기까지 간단한 기능은 모두 제공한다. 영상을 자르고 편집하는 단축키가 마스터링 도구(어도비 프리미어나 애플 파이널컷 같은)에 비해서 좀 모자란 편이라서 마우스로 일일이 한 탓에 편집 시간이 더 들긴 했지만 그래도 편집하는 도중에 멈춘다거나 하는 일 없이 끝까지 무사히 편집할 수 있었다.

슬라이드는 이전 이상한모임 멜번 모임에서 사용했던 적이 있는 reveal.js를 사용했다. 사실 기본 테마나 설정도 있지만 영어에는 이뻐 보이는데 한글에서는 좀 다르게 느껴져서 인라인 스타일을 막 넣어 편집해서 사용했다. GIF 이미지는 Giphy라는 사이트에서 좋아하는 미드 장면들을 찾아서 넣었다. 슬라이드 작성에는 크게 어려움이 없었는데 최근에 koa로 토이 프로젝트를 진행하고 있었기도 했고, 이전에 작성한 적이 있던 내용이라서 크게 막히는 부분은 없었다. (매번 발표 때마다 그림만 기억나고 내용은 기억나지 않는다는 피드백을 자주 받아서 한편으론 기쁘면서도 슬프다. 다음엔 꼭 제대로 된 내용을…)

발표를 보면서 고쳤으면 하는 점을 적었다.

• 아, 음 같이 횡설수설하는 말과 반복해서 사용하는 미사여구를 줄일 것
• 말이 상당히 여유로운데 조금 더 밀도있게 진행하면 좋지 않을까
• 침묵 속에서 라이브코딩을 할 거라면 미리 작성한 코드를 설명하는 쪽을 택할 것
• 주제의 기승전결이 좀 더 체계적인 느낌이 들도록 내용을 작성할 것
• 연습, 연습, 연습

특히 이번 이모콘에서 다르게 느꼈던 점은 스피커로 참여해서 느낄 수 있던 부분이였다. 각각 선정해서 발표한 내용도 너무 재미있었지만 그 외에 부수적인 부분도 많이 눈에 들어왔다. 다른 발표를 보면서 어떤 방식으로 내용을 풀어가는지, 어떻게 내용을 설명하고 끊기지 않고 자연스럽게 진행하는지, 슬라이드나 영상 자료를 어떻게 활용하는지, 그 내공을 엿보고 배울 수 있어서 좋았었다. (세상은 넓고 초고수는 많다!)

이모콘 이름으로 좋은 기회 제공해주고 함께 참여 및 준비한 모든 분들께 감사의 말씀을 전하고 싶다. 다음 이모콘에서도 스피커로 참여할 기회가 된다면 꼭 참여하고 싶고 그 시기를 위해 미리미리 준비해야겠다.

발표자료

• 제너레이터를 만나고 새 삶을 얻었어요 – JavaScript의 generator와 co, koajs
  • 발표영상 youtube