원래 모바일 쪽 개발을 하지는 않지만, 최근에 WIPI 플랫폼에서 C 언어로 작은 프로젝트를 하나 하고 있습니다. 실제 폰 환경에 돌려보기 전에 윈도 환경에서 WIPI 에뮬레이터로 테스트를 먼저 하고 있는데, ETRI에서 제작한 이 윈도 WIPI 에뮬레이터가 정말 걸작(?)이네요.

1. 짤리는 로그

WIPI C의 MC_knlPrintk()라는 함수를 이용해 콘솔에 로그를 찍어보고 있는데, WIPI 에뮬레이터는 별도의 로그 창을 띄어줍니다. 근데 문제는 로그 창을 넘어가는 로그를 그대로 잘려서 보인다는 것이죠. 스크롤 바도 없어서 잘린 로그를 확인할 수 있는 방법이 없습니다.


2. 엉터리 MC_knlSprintk()

WIPI C의 MC_knlSprintk() 함수는 stdio.h의 sprintf() 함수와 동일합니다. WIPI C 환경은 stdio.h 헤더 파일을 제공하지 않기 때문에 별도의 함수를 두고 있습니다. ETRI의 윈도 에뮬레이터는 이 함수 구현이 버그투성이더군요. MC_knlPrintk(buf, "%02x", 0xff)와 같이 포맷 지정자에 %02x 와 같은 포맷이 들어가면 아무 것도 찍지 않는 문제가 있더군요. MC_knlPrintk(buf, "%02x\n", 0xff)와 같이 개행 문자(new line)이 들어가면 또 출력이 됩니다.

WIPI C 표준안에 따르면 MC_knlSprintk()는 C 언어 표준에 정의된 sprintf()을 따라야 한다고 했는데, 윈도 에뮬레이터는 윈도가 기본으로 제공하는 sprintf() 함수를 두고 왜 엉터리 구현을 굳이 작성해서 사용자를 골탕 먹이는 걸까요?


3. 서버 소켓 지원

WIPI C에서 서버 소켓 지원은 선택 사항입니다. 덕분에 일부 플랫폼에 서버 소켓을 지원할 수도 있고, 상황이 여의치 않는 경우는 지원 안 할 수도 있습니다. 확인해보니 이 표준안에 충실해서 윈도 에뮬레이터도 서버 소켓을 지원 안 하더군요. 문제는 윈도 에뮬레이터가 왜 서버 소켓을 지원 안 하는지를 모르겠다는 것입니다. 내부적으로 WINSOCK을 썼을텐데, 함수 한 개 매핑만 해주면 될 일을 굳이 선택 사항이니깐 안 해도 되겠지라는 식으로 구현해줘서, 에뮬레이터 사용자를 불편하게 만드네요.


답답한 환경에서 개발하는 모바일 개발자 여러분 힘내십시오.

요즘 제가 화두로 삼고 있는 것 중에 하나가 "정보 혹은 생각을 어디까지 공개할 것인가?"라는 질문입니다.

개인이나 작은 기업이 기발한 아이디어를 떠올립니다. 잘만 하면 큰 사업 기회가 될 수도 있을 것입니다. 전통적인 사업 방식이라면 이런 아이디어를 꼭꼭 숨겨두고 극비리에 추진해서 대박을 노리는 전략을 취하는 것이 옳은 일입니다. 하지만 이렇게 떠올린 대부분의 아이디어는 개인이나 작은 기업이 추진하기에는 무리인 경우가 많이 있습니다. 이런 경우 비장의 아이템으로 꼭꼭 숨겨두는 경우가 대부분인데, 그렇게 숨겨둔 생각만 가지고는 얻을 수 있는 이익이 실상 별로 없는 경우가 많이 있습니다.

괜찮은 아이디언데 내가 당장 실행할 수 없는 일이라면 차라리 내가 먼저 공개해버리는 것이 오히려 이익이라는 생각이 듭니다. 과거는 기업 보고서에서나 볼 수 있었던 내용들이 지금은 각종 블로그를 통해서 무료로 쏟아져 나오는 것도 이런 생각과 맞닿아 있을 것이라 생각합니다. 요컨대 내가 혼자서 소화할 수 없는 아이디어라면 먼저 공개해서 관련된 피드백을 받고 다른 사람들과 함께 기회를 만들 수도 있을 것입니다. 일례로 블로그 같은 경우는 매우 효과적인 이력서 역할을 하게 될지도 모릅니다. 내가 꾸준히 공개해 온 생각들이 결국 다른 사람들이 나의 능력을 신뢰할 수 있는 밑바탕이 되는 것이지요.

요즘은 가진 게 없는 개인일수록 더욱 다 자기 패를 적극적으로 보여주는 게 올바른 전략이 아닐까라는 생각이 드네요.

Trac는 현재 가장 많이 쓰이는 오픈 소스 이슈 트래킹(issue tracking) 도구 중에 하나입니다. Trac에서 각각의 이슈는 티켓(ticket)이라는 이름으로 관리합니다. 각 티켓은 버그 리포트가 될 수도 있고 해야 할 일이나 제안이 될 수도 있는데, 일반적으로 다음과 같은 항목을 가집니다.

• id
• time
• changetime
• component
• severity
• priority
• owner
• reporter
• cc
• version
• milestone
• status
• resolution
• summary
• description

트랙은 이런 티켓을 묶어서 관리하는 방법으로 리포트(report)라는 개념을 사용합니다. 리포트는 특정 조건을 만족시키는 티켓 만을 보여주는 논리적인 뷰(view)라고 할 수 있습니다. Trac에서 View Ticket 메뉴를 누르면 Trac에 미리 정의된 리포트를 보여주는데 다음과 같습니다.




이는 어떤 티켓을 보여줄 것인지 미리 정의해놓은 것입니다. 예를 들어 {7}번의 경우 나에게 할당된 티켓만을 보여달라는 옵션이고, {6}은 특정 마일스톤에 해당하는 티켓만 보여달라는 뜻입니다.

Trac는 이 시스템을 좀 더 확장해서 사용자가 원하는 리포트를 직접 작성할 수도 있도록 하였습니다. Trac의 리포트는 티켓이 저장되는 DB 테이블을 SQL 문으로 직접 얻어오는 방식을 사용합니다. 예를 들어, 모든 티켓의 모든 필드를 얻어오고 싶다면 select * from ticket이라고 입력해 주면 됩니다.

하지만 TracReports의 노트를 보면 이런 디자인 결정이 실수라고 이야기하고 있습니다. 티켓의 테이블은 세부 구현 사항에 해당하는데, 리포트를 구현하기 위해 티켓 테이블을 외부로 노출시켰기 때문입니다. 따라서 이후 버전에서 티켓 테이블의 구조를 변경해야 하거나 최적화가 필요할 경우 이를 수정할 수 있는 유연성이 떨어지게 되는 것이죠.

이 문제를 해결하기 위해 Trac은 원하는 티켓을 검색해주는 트랙 질의(Trac Query) 모듈을 별도로 만들었습니다. 트랙 질의 모듈은 티켓 테이블에 직접 접근하는 방식에서 벗어나 사용자가 원하는 정보를 몇 가지 필터를 적용해 얻어올 수 있도록 하였습니다. 티켓 테이블이라는 내부 구현을 숨겼기 때문에 이후 버전에서 변경의 용이성이 생긴 셈입니다.

Trac은 현재는 두 가지 버전(SQL 이용, 질의 모듈 이용)을 모두 지원하지만, 앞으로는 질의 모듈을 사용할 것을 강력히 권고하고 있습니다. 이는 정보 은닉(information hiding)과 관련된 잘못된 디자인이 소프트웨어의 유지 보수(maintenance)에 어떤 영향을 미치는지를 보여주는 좋은 사례라 할 수 있습니다.

D 언어로 알려진 Digital Mars 사에서도 EcmaScript 엔진을 만들어서 팔더군요. DMDScript라는 제품은 ECMA 262 스크립트 언어(네스케이프 구현은 자바스크립트, MS의 구현은 JScript로 알려져 있음)를 구현한 엔진입니다. D 언어를 만든 Digital Mars 사답게 이 엔진도 D 언어를 사용해서 만들었더군요.

D 언어 컴파일러를 설치하고, DMDScript를 컴파일해서 실행시켜보았는데, DMDScript에 포함된 "Sieve prime number calculation" 벤치마크 결과는 다음과 같습니다.

[1] 인터넷 익스플로러 7.0


[2] DMDScript 엔진


속도 차이가 대략 3.5 배 정도 DMDScript가 빠름을 알 수 있습니다.



** 벤치마크에 사용된 자바스크립트 소스 코드


벤치 마크에 사용된 소스 코드가 비교적 단순해서 쉽게 결론 내리기는 어렵지만, 기존 인터넷 익스플로러나 모질라에 포함된 자바스크립트 엔진이 상당한 개선의 여지가 있다는 생각이 드네요.


더불어 DMDScript의 라이센스는 GPL로 소스 코드는 공개 되어 있습니다. 상업적으로 이용하기 위해서는 DMDScript Commercial License를 구입해야 하는데, $999.00 이면 살 수 있고 별도의 로얄티(running royalty)는 받지 않는군요.

자바스크립트의 함정 중에 하나는 객체 비교 연산자가 ==와 === 두 가지 버전으로 있다는 점입니다.



==는 자동으로 변환을 수행하여 비교 연산을 하기 때문에 a = 1과 b = "1"을 비교했을 때 a == b는 true를 리턴하게 됩니다. 반면에 ===는 타입과 값을 모두 비교하기 때문에 서로 다른 타입인 a와 b를 비교하는 a === b는 false를 리턴합니다.

다음은 자바로 작성된 자바스크립트 엔진인 Rhino1.6 R5에서 ==와 ===를 수행한 결과입니다.

자바 스크립트는 함수형 언어들과 마찬가지로 클로저(closure)를 지원한다.


위 함수 sayHello()의 리턴 값은 또 다른 함수인 function() { alert(text); }이다. 이렇게 얻은 함수는 다음과 같이 호출할 수도 있다.



함수 안에 함수를 정의하는 중첩 함수(nested function)의 개념은 어렵지 않지만, 클로저는 중첩 함수에 대한 단순 함수 포인터만은 아니다. sayHello() 함수에서 text는 지역 변수이므로 스택에 할당하는 구조를 따른다면 sayHello() 함수가 리턴된 후에는 더 이상 text 변수의 값을 읽을 수 없어야 한다. 자바스크립트에서 function() { alert(text); } 같이 클로저를 선언하면 클로저 내부에서 참조하는 지역 변수인 text를 마치 힙에 할당한 것처럼 보존한다. (즉 클로저에 대한 감춰진 포인터가 하나 더 있는 셈이다.) 따라서 sayHello() 함수가 리턴된 후에도 클로저를 호출했을 때 text 변수의 값을 읽을 수 있는 것이다.

자세한 내용은 참고 문서를 참조하기 바란다.


참고 문서
[1] JavaScript Closures 101- they're not magic
http://www.javascriptkit.com/javatutors/closures.shtml

[2] More closure examples
http://www.javascriptkit.com/javatutors/closures2.shtml

이전에 메릴랜드 있을 때 참석하던 Software Chat에서 "Enforcing and Validating Programmer-Defined Type System"라는 주제의 강연 메일을 받았다.

프로그램의 중요한 속성(well-formedness properties)을 보장하는 데 타입 시스템이 자연스러운 접근 방법인 것은 사실이다. 하지만 프로그래머마다 원하는 속성이 다르고, 언어 설계자가 이 모든 요구사항을 언어 타입 시스템에 모두 녹여 넣을 수 없다. 따라서 UCLA의 Todd Millstein의 아이디어는 언어 타입 시스템 자체를 확장성 있게 만들어 프로그래머가 필요한 속성을 체크할 수 있도록 타입 시스템을 확장할 수 있게 해주자는 것이다.

Clarity 프레임워크의 경우 C의 타입 시스템을 확장해서 nonnull, positive, tained 같은 타입 한정자(type qualifier)를 손쉽게 추가할 수 있게 해준다. JavaCOP은 이 아이디어를 자바 쪽으로 확장하여 객체 한정(object confinement)나 레이스 컨디션 검사 등을 자동화하는 것이다.

스크립트 언어를 위시한 한 쪽에서는 그나마 있던 컴파일 타임 검사도 안 하는 판인데, 학계에서는 각종 검사를 컴파일 타임에 조금이라도 더할 수 있게 만들고, 또 언어 사용자가 이런 검사를 추가할 수 있는 프레임워크를 만들고 있다는 게 참 재미난 현상이다.

WIPI C는 핸드폰 환경에서 C 언어로 응용 프로그램을 제작하기 위한 국내 표준 모바일 환경입니다.  메모리 할당해제, LCD 제어, 이벤트 처리, 네트워크 접속 등에 관련된 각종 API도 표준으로 정하고 있습니다. 최근에 WIPI C로 간단한 프로젝트를 할 일이 있었는데, 이 과정에서 WIPI C의 느낀 문제점을 정리해 보려 합니다. (이전 글인 "WIPI 플랫폼에 포팅하기"에서 메모리 할당에 대해 이야기한 적이 있습니다.)

*** WIPI C에서 메모리 할당/해제

WIPI C는 대부분의 메모리가 제약된 임베디드 환경에 맞추어서 메모리 컴팩션(compaction)을 기본으로 지원합니다. 기존의 malloc/free 방식은 아무리 잘 구현해도 외부 단절화(external fragmentation) 현상으로 인해 메모리를 할당 받을 수 없는 문제를 피해갈 수 없기 때문입니다.

WIPI C는 MC_knlAlloc()/MC_knlCalloc() 함수를 통해 메모리를 할당 받고 MC_knlFree() 통해 메모리를 해제합니다. 이 때 할당 받은 메모리는 포인터가 아닌 메모리 식별자(M_Uint32 타입)입니다. MC_GETDPTR()라는 매크로를 이용하면 해당 식별자에서 메모리 포인터를 얻어올 수 있습니다. 이렇게 간접 참조를 사용하는 이유는, 컴팩션이 일어나면 메모리 포인터가 언제든지 바뀔 수 있기 때문입니다. 컴팩션이 일어날 수 있는 시점 이후에는 항상 MC_GETDPTR()를 이용해 새로 포인터를 얻어오는 방식이죠.

응용 프로그램 개발자가 이 규칙을 제대로 준수하면, malloc/free 구현에서 발생하는 외부 단편화 현상도 없애고 메모리를 매우 효율적으로 이용할 수 있으므로 좋은 일이 될 것입니다. 하지만 ‘개발자 편의성’이라는 측면에서 보면 이 방식은 너무 귀찮습니다. MC_knlAlloc()/MC_knlCalloc()을 통해 메모리를 한 번 할당해 올 때마다, 컴팩션이 일어날 수 있으므로 이전에 얻어놨던 포인터가 전부 무효가 됩니다. 한 번이라도 포인터를 새로 얻어오지 않은 지점이 있으면 잠재적인 버그로 이어지니 무시무시한 것이지요.

불편함은 여기에서 그치지 않습니다. M_Int32 foo(M_Byte *str, M_Int32 len)과 같은 함수를 구현한다고 생각해 봅시다. 만약 foo라는 함수를 작성할 때 새로 메모리를 할당 받을 필요가 있으면 어떻게 될까요? 우리는 인자로 넘어온 str이 동적 할당된 메모리에서 온 것이지 정적 할당된 메모리에서 온 것인지 알 방법이 없습니다. 만약 동적으로 할당된 메모리에서 왔다면 우리가 foo() 함수 내부에서 메모리를 새로 할당 받는 순간 str은 더 이상 유효한 포인터가 아니게 될지도 모릅니다.



물론 여기에 대한 대안은 포인터 대신에 식별자를 넘기도록 수정하는 것입니다. M_Int32 foo(M_Uint32 strHnd, M_Int32 len)와 같이 수정하면 foo() 함수 내부에서 새로 메모리를 할당 받더라도 변경된 포인터를 얻어올 수 있을 것입니다. 하지만 이 방식에서는 첫 번째 인자가 M_Byte *라는 타입 정보가 날라가는 효과가 있습니다. 함수만 봐서는 인자로 어떤 타입을 받는지 알 수 없는 거죠.

나름 좋은 의도로 출발한 제약 사항이라도 개발자의 편의를 심각하게 저해하는 경우 역효과를 일으킬 수 있습니다. WIPI C 개발자는 동적 할당의 제약 사항을 피하고자 되도록이면 동적 할당을 피하고, 정적 할당을 사용하는 것이 첫 번째입니다. 동적 할당에서 포인터를 매번 새로 얻어오는 번거로움을 피하고자, 포인터가 변경되지 않는 정적 할당을 필요보다 훨씬 더 많이 사용하게 되는 것이지요.

이 방식이 극단으로 가면 큰 메모리 블록은 할당 받아서 내부적으로 malloc/free 함수를 구현해 쓸 수도 있는 일입니다. WIPI C 플랫폼이 그토록 피하고자 했던 일을 개발자가 오히려 추가적인 수고를 들여서라도 하려고 하는 것입니다. 욕심이 지나치면 일을 망친다고 하였습니다. ’개발자 편의성’을 무시하고 무리한 일을 요구하면, 그 의도가 아무리 좋아도 일을 망치는 법이 아닐까 싶습니다.

W3C XQuery, XSL 워킹 그룹에서 다음 8개의 권고안을 릴리즈했습니다.

• XSL Transformations (XSLT) Version 2.0
• XQuery 1.0: An XML Query Language
• XML Path Language (XPath) 2.0
• XQuery 1.0 and XPath 2.0 Data Model
• XML Syntax for XQuery 1.0 (XQueryX)
• XQuery 1.0 and XPath 2.0 Functions and Operators
• XSLT 2.0 and XQuery 1.0 Serialization
• XQuery 1.0 and XPath 2.0 Formal Semantics

이제 해당 명세를 구현하려는 움직임이 뒤따르겠군요. 현재 오픈 소스로 Saxon이 XQuery/XSLT 2를 구현하고 있고, eXist를 비롯한 일부 오픈 소스 XML 데이터베이스가 XQuery를 지원하고 있습니다. 하지만 브라우저도는 현재 XSLT 2를 지원하는 제품이 없습니다. 사실 XSLT 1을 제대로 지원하는 것도 힘든 일이기 때문입니다.

자바원 2007 컨퍼런스가 현재 참가 신청을 받고 있습니다. 참가 비용이 조기 예매 할인을 적용해도 1795 달러(원화로 170만원 가량) 되네요. 이벤트 행사로 5명의 친구에게 추천해 주면 PSP를 주는 행사와 5명이 가면 덤으로 1명을 더 등록해 주는 5+1 행사가 있습니다. 갔다 오고는 싶은데 제 돈으로는 등록할 엄두가 안 나네요. 흑흑.

지난 번에 공지드린 오픈소스 프로젝트 소개하기를 시작하려고 합니다. 처음으로 소개드릴 오픈소스 라이브러리는 아파치(Apache) Jakarta 프로젝트의 일환인 Commons Codec입니다. Commons Codec은 Base64나 Hex 포맷 등으로 변환을 지원하는 자바 라이브러리입니다.

[Commons 프로젝트는 Apache Jakarta 프로젝트에서 자주 사용되는 유용한 클래스들을 모아 놓은 유틸리티 프로젝트라고 할 수 있습니다.]

Commons Codec은 Base64를 지원하기 위해 처음 만들어졌는데, Base64는 바이너리 데이터를 출력 가능한 아스키코드(ASCII) 형태로 변환하여 표시하는 방식입니다. MIME((Multipurpose Internet Mail Extensions)에서도 Base64를 사용하고 있습니다.

Base64 클래스의 사용법은 매우 간단합니다. Base64.encodeBase64(byte[] byteArray) 메쏘드를 이용해 바이트 배열을 인코딩하고 Base64.decodeBase64(byte[] byteArray)을 이용해 디코딩합니다. 여기에서 Base64 클래스를 사용하는 예제를 참조하세요.

읽을거리

[1] Using the Jakarta Commons, Part 1
[2] Using the Jakarta Commons, Part 2

회사에서 개발 서버로 사용하게 된 리눅스 서버가 오래된 배포판인 Redhat 9이라, Fedora Core로 업그레이드를 하였습니다. 지워버리고 새로 설치하는 게 더 빠르겠지만, 패키지 관리 도구인 Yum(Yellow dog Updater)을 통해서도 업그레이드가 가능하다 길래 시도해보았습니다.

자동화된 패키지 관리 도구를 사용해도 한 번에 업그레이드 시킬 수는 없더군요. YumUpdateFaq에 나와있는 데로, Redhat 9 -> Fedore Core 1 -> Fedora Core 2 -> Fedora Core 3 -> Fedora Core 4 -> Fedora Core 5 라는 지루한 단계를 거쳐서 업그레이드를 완료시켰습니다.

예전에는 glibc 같이 시스템의 주요 라이브러리의 버전이 바뀌면 패키지 업데이트가 매우 힘들었는데, 이제 리눅스도웬만큼 편리하게 자동 업데이트가 가능하군요.

12월 31일까지 맹렬한 기세로 포스팅을 하다가 1월 1일부터 잠시 잠적하였습니다. 다들 새해 계획을 세우고 실천에 옮기느라 분주할 2007년 첫 날부터 몸이 불덩이처럼 타오르다 급기야 응급실 행. 처음에는 병명을 모르고 집에서 해열 주사만 맞고 끙끙거리다가 '인후염'이라는 진단을 받고 입원해 있다가 이제서야 퇴원하였습니다.

결국은 건강이 제일이네요. 병원에 누워있으니 아무리 열심히 무엇인가를 이루려고 해봐도 어느 순간 몸이 말을 안 들으면 아무 것도 할 수 없다는 사실을 새삼 알겠더라고요. 올해부터 너무 열정에 불타서 몸을 혹사시키려고 마음 먹고 있었는데 누군가 미리 말고 건강부터 챙기라고 조언을 해줬나 봅니다.

아무튼 이제 서서히 회복되고 있습니다. 건강을 되찾는 데로 포스팅도 조금씩 재개해 보겠습니다. 여러분도 건강 조심하세요 -_-)=b

연휴 동안 쉬면서 김국현 님의 [웹 2.0의 경제학]과 우메다 모치오의 [웹 진화론]을 읽었습니다.  둘 다 웹 2.0을 화두로 변화하는 인터넷 세상을 통찰력 있게 잘 풀어내고 있어서 재미있게 보았습니다.

우메다 모치오는 마이크로소프트의 인재상과 구글의 인재상을 비교하고 있습니다. [The Microsoft Way]에 나온 마이크로소프트의 인재상 초천재(super smart)라 불리는데, 그 특징은 다음과 같습니다.

• 새로운 지식을 리얼 타임으로 신속하게 흡수하는 능력
• 예리한 질문을 던질 수 있는 능력
• 서로 다른 분야 지식들 간의 연관성을 찾아내 종합적으로 이해하는 능력
• 프린트된 코드를 단번에 이해할 수 있을 정도의 뛰어난 프로그래밍 능력
• 운전이나 식사할 때조차 코드를 생각하는 열의
• 극도의 집중력 등

구글의 인재상은 MS 인재상 + 박사 학위 취득자라는 말이 있군요. 물론 박사 학위가 없는 사람도 구글에 많이 입사하지만 구글의 전략이 박사들을 연구만 시키지 않고 주요 사업 요소요소에 심어서 회사 전체가 연구하는 분위기로 이끌고 있는 것은 사실이니깐요.

이런 초천재형 인재가 3-4명만 있어도 세상을 놀라게 할 서비스를 꾸릴 수 있으니 앞으로의 사회는 더욱 더 양보다 질이 되지 않을까 생각 됩니다. 멀지 않은 미래에 소수의 슈퍼 개발자를 제외하고는 프로그래머라는 직군 자체가 멸종되는 게 아닐까 심히 염려스럽습니다.
 

요즘은 뉴스 포탈 보다는 블로그를 통해 여러 정보를 얻는 편인데, 훌륭한 블로거들이 많이 계시지만 가끔 너무 전문적인 나머지 간단히 핵심 용어를 설명해주는 사소한 배려가 없어서 안타까운 경우가 많습니다. 블로그는 혼자 말하는 장소가 아닌 만큼 읽는 분들을 고려해야 함에도 불구하고, 앞 뒤 설명 없이 본론으로 들어가는 경우에는 어떤 이야기를 하는지 알아듣기 힘든 경우가 많이 있거든요. 물론 독자층을 어떻게 선정하고 글을 쓰냐에 따라서 이 부분을 크게 달라질 수 있지만 조금만 더 신경을 써주시면 글을 읽기가 훨씬 쉬워집니다.

저는 병역특례 생활을 할 때 경제 신문인 Financial Times[각주1]을 읽고 토론하는 모임인 FTCLUB(Financial Times Club)이라는 모임을 했었습니다. 이 때 FT 내부 자료인 FT Inside라는 소책자를 읽어볼 기회가 있었습니다. FT Inside는 FT의 신입 기자들을 위한 기사 작성법을 다루고 있었습니다. 명쾌하고 정확한 기사 전달을 위한 여러 가지 원리 원칙을 설명하고 있었는데 그 중에 하나 기억에 남는 것이 전달하고자 하는 기사의 핵심 주체나 내용을 짧게나마 설명해 주는 것입니다.

오늘 나온 따끈따끈한 실제 FT 기사를 통해 예를 들어 보겠습니다.


위 기사는 Apple 사의 스티븐 잡스에 대한 소식인데, Apple 뒤에 "the computer company"라는 부연 설명을 달았습니다.



위 기사를 보면 YouTube의 경우 "the site for amateur videos"로, Wikipedia는 "the online encyclopedia written by volunteers"로 부연 설명하고 있습니다.

컴퓨터 업계에 종사하는 입장에서 보면 당연한 알아야 할 내용이므로 생략해도 된다고 말할 수 있지만, 요즘처럼 급변하는 세상에서는 IT 관련자라도 한 두 달 휴가만 갔다 오면 유튜브가 뭔지 위키피디아가 뭔지 알 수가 없습니다. 일반인들은 말할 것도 없겠지요. FT는 독자층을 전세계의 임원급 경영진으로 잡고 있기 때문에 그에 상응하여이런  부가적인 설명을 기사 중간에 슬쩍 끼워 넣어 제공하는 것입니다.

블로그의 경우도 점점 미디어화되어 가는 경향이 큰데, 내 글을 읽을 독자층이 어떤지, 그들을 위해서는 어느 정도 자세히 부가 설명을 해줘야 할지를 결정하는 일이 선행되어야 할 것입니다. 그렇지 않으면 허공을 향한 독백이 될 가능성이 크거든요. 물론 저 역시 지금까지 이런 부분을 많이 못 지켰는데 앞으로 좀 더 고민해 볼 문제인 것 같습니다.

[각주 1] Financial Times는 영국에서 발간되는 경제, 경영 일간지로 미국의 WSJ(Wall Street Journal)과 함께 양대 경제 신문의 양대 산맥을 형성하고 있습니다. 국내 매경이나 한경에도 FT의 기사를 그대로 번역해서 싣는 경우가 많이 있을 만큼 그 권위를 인정받고 있습니다.

애자일 이야기의 "떨어뜨리는 면접"을 읽고 제 생각을 써봅니다. 이 글에서 김창준 님은 결론은 특수한 상황을 제외하고는 IT 회사에서 압박 면접은 좋은 면접 방법이 아니라는 것입니다.

이와 관련된 좋은 책으로 로버투 우드, 팀 페인 공저의 [채용과 선발의 심리학]이 있습니다. 이 책은 역량 기반의 채용과 선발 방법에 대한 이야기를 하고 있는데, 면접시 편안한 분위기 형성을 매우 강조하고 있습니다. 면접의 목적은 누군가를 떨어뜨리는 데 있는 것이 아니라 지원자의 정보를 최대한 얻어내는 데 있습니다. 솔직한 정보를 이야기할 수 있도록 편안한 분위기를 조성하는 일은 면접의 목표를 달성할 수 있는 가장 기초적인 작업인 것이죠. 편안한 분위기를 형성하기 위해서 어려운 질문은 해서는 안 된다는 뜻은 아닙니다. '지원자를 압박하는 면접'을 피하라는 것이지요.

압박 면접은 스트레스가 심한 상황에서 대처하는 능력이 업무에서 가장 중요한 요소일 때나 필요한 특수한 면접 방법입니다. 예컨대 구조 요원이나 응급실 의사처럼 스트레스 대응 능력이 생명과 직결되는 중요한 일일 때는 사용할 수 있는 방법이겠죠. 하지만 개발 업무와 같이 화기애애한 분위기에서 자유롭게 의견을 교환하고 창의력을 발휘해야 하는 업무에는 가장 나쁜 면접 방식일 것입니다.

오늘 O'Reilly XML.COM의 피드를 읽던 중에 "GMail Disaster, Google confirmed the Mass Email Deletions. Even backups are gone?"라는 글에 눈에 띄네요. 사건은 요지는 GMail에서 불의의 사고로 약 60명의 이메일이 통채로 지워진 데 있습니다. 필자는 백업해 놓은 데이터를 이용해서라도 소중한 이메일을 살려줘야 하지 않느냐고 항의하고 있고요.

GMail의 엄청난 사용자 수를 생각해 볼 때 60명 정도가 피해를 입은 것은 경미한 사고입니다. 하지만 이런 사고가 몇 번 더 발생한다면 기업 이미지에 상당한 타격을 입을 것은 분명합니다. 비단 구글 뿐만 아니라 웹메일과 웹서비스를 제공하는 업체들은 데이터 백업과 보안 등에 더 신경을 써야 할 것 같습니다. 사용자들도 웹에 저장된 데이터가 안전한 가에 대해 다시 한 번 생각해봐야겠습니다.

[둠: 컴퓨터 게임의 성공 신화 존 카맥 & 존 로메로]를 읽었습니다. 존 카맥과 존 로메로는 둠의 개발로 일약 게임 업계의 스타덤에 오른 게임계의 전설과 같은 인물입니다. 이 책은 카맥과 로메로의 전기인 셈인데, 그들의 어린 시절부터 전설의 게임 '둠'과 '퀘이크'를 개발하게 되는 과정을 자세하게 묘사하고 있습니다.


카맥은 전형적인 컴퓨터 해커의 모습으로 프로그래밍을 즐기는 것 외에는 관심이 없는 사람입니다. 반면에 로메로는 카맥을 보조해줄 수 있는 프로그래밍 실력을 지녔지만 또한 미술적인 감각, 기획력, 사업 능력까지 갖춘 팔방미인으로 나옵니다. 서로 다른 성격과 능력을 가진 두 콤비이지만 이런 차이는 서로의 단점을 감싸주고 최고의 시너지를 발휘할 수 있는 원동력이 됩니다.  이 책을 읽으면서 시종일관 부러웠던 것은 같은 즐거움과 비전을 공유한 사람들이 만나서 무한한 에너지를 함께 쏟아내는 모습이었습니다. 일생에서 그런 파트너를 찾을 수 있다는 것은 크나큰 행운이겠지요. (물론 이후에는 이런 성격 차이로 결별하게 되지만, 로메로가 없었다면 카멕 또한 상업적인 성공과는 거리가 먼 긱으로 남았을 것 같습니다.)

최근에 ZDNET에 로켓 선구자가 된 존 카맥과의 인터뷰 기사가 올라왔는데 재미있네요. 근황이 궁금하신 분은 참고하시길.

최근에 마이크로소프트가 영향력 있는 블로거들에게 최신 노트북을 선물해서 화제가 되고 있는데, 조엘 온 소프트웨어로 유명한 조엘이 "Bribing Bloggers"라는 글을 통해 쓴 소리를 했습니다. 글 제목에서 알 수  있듯이 MS의 이런 행동은 뇌물이랑 다를 바가 없다는 것이죠.

저도 이 생각에 동의합니다. 일개 블로거들에게 준 노트북 선물이 무슨 큰 문제냐고 할 수도 있지만 유명 블로거들의 영향력이 기존 언론과 맞먹는 파급력을 가졌다는 사실을 비추어볼 때 블로거들은 언론 윤리를 가질 필요가 있습니다. 즉 자신의 글이 외압이나 이권에 의한 것이 아닌 순수한 자신의 생각임을 천명해야 하는 것이죠. 이번에 노트북을 선물 받은 블로거들이 MS에 쓴 소리를 쓸 수 있을지, 바른 말을 쓰더라도 독자들이 이를 믿어줄지 모르겠습니다. 노트북 한 대 때문에 그 동안 쌓아온 신용을 잃을 수도 있는 것이지요.

톰 켈리, 조너던 리트맨이 지은 [유쾌한 이노베이션]은 세계 최고의 디자인 회사를 자부하는 IDEO의 독특한 경영 방식과 창의성의 상관 관계를 설명하는 책입니다. 김창준 님도 애자일 이야기의 "IDEO의 비밀 무기" 라는 글에서 이 책을 소개하신 적이 있습니다.



이 책은 창의적이고 효율적인 조직을 만들기 위한 여러 방안을 제시하고 있는데, 특히 '열정 팀'에서 팀과 팀원을 이어주는 방식이 마음에 와 닿습니다. IDEO에는 할리우드식 영화 스튜디오 프로젝트 방식을 추구합니다. 헐리우드 영화는 대본이라는 프로토타입을 손에 넣고 최고의 배우, 감독, 제작자, 프로듀서, 엑스트라, 하청 업자를 끌어 모아 옵니다. 제작사마다 끌어 모을 수 있는 최고의 팀을 가동하고 영화 완성이라는 맹렬한 목표를 향해 뛰어 갑니다. 타성에 젖어 주어진 일만 하는 소극적인 직원이 아닌 각자 맡은 바 일을 완수하기 위해 모인 팀의 전문가가 되라는 이야기입니다.

이렇게 하려면 팀 결성 방식부터 달라야 합니다. 사장이나 팀장이 일방적으로 팀원을 지목해서 데려가는 방식으로는 곤란하기 때문입니다. 팀원이 열정으로 100% 실력을 발휘하기 위해서는 자신이 원하는 곳에서 일하는 것이 무엇보다 중요하기 때문입니다. IDEO에서는 각 스튜디오의 팀장들이 자신들이 일이 얼마나 자극적이고 도전적인지 사원들에게 설명하고, 사원들이 최종적으로 자신이 참여할 프로젝트를 결정하게 됩니다.

물론 이렇게 할 수 있는 것은 IDEO는 창의성과 열정이 다른 어떤 사업보다 중요한 디자인 회사라는 점이 작용했겠지요. 하지만 국내 대기업처럼 무슨 일을 하게 될지 전혀 힌트도 안 주고 일방적으로 채용한 후에 배치하는 행태로는 직원들의 열정도 창의성도 끌어내기 힘듭니다. 지금이야 체계화된 학습과 조직으로 이 부분을 어느 정도 보완하고 있겠지만, 갈수록 치열한 경쟁 속에서 창의력 없이 그저 '열심히' 하는 직원으로는 한계가 있을 것입니다.