특정 리눅스 배포판 (e.g. CentOS 5) 의 중요 파일에는 (e.g. /etc/sudoers) ext2의 immutable attribute가 설정되어 있다.
ext2 파일시스템 내부적으로는 ext behaviour control flags이라고 부르는 것으로 보인다.
lsattr, chattr을 사용해서 ext2 attributes를 조회하거나 설정할 수 있다.
대규모 장비에 대한 환경을 운영해야 한다면, immutable attribute를 활용해보는 것도 괜찮을 것 같다. (e.g. 계정 공통 bash이나 vim 설정)
@ 그나저나 요즘은 리눅스 커맨드도 위키피디아에 나오는군.
어떤 것을 경제적인 가치를 평가할 때 가장 좋은 방법은 숫자로 나타내보는 것이다. 주식이 실제로 어떤 기업의 미래 가치를 반영한다면, 그 기업의 주가총액은 그 기업의 미래 가치를 평가하는 척도가 될 수 있다.
국내 인터넷 서비스 업계에서 선두 주자라고 할 수 있는 NHN의 시가총액은 현재 97,467억이다. 10조라고 보면 된다. 반면 2위라고 볼 수 있는 다음의 시가총액은 10,447억, 즉 1조다. 일반적인 사용자들이 인지하는 것과는 반대로, 다음은 NHN의 1/10 규모에 불과한 것이다. 매출액이나 영업이익 등의 지표를 확인해봐도 마찬가지다.
NHN의 직원 규모나 채용 규모를 보면 다음은 역시 점점 뒤로 쳐지고 있는 것을 알 수 있다. 현재 직원 수가 2000여명이지만, 앞으로의 채용 규모를 보면, 그리고 NHN의 해외 진출 전략 등을 고려해보면, Microsoft나 Google 처럼 1만명 이상의 직원이 되는 소프트웨어 기업이 되는 것도 시간 문제로 보인다.
양 뿐만 아니라 질에 있어서도 떨어지지 않는다. NHN에 채용되는 개발자들의 수준이 적어도 평균적인 수준보다는 높다고 생각한다. 게다가 예전에 같이 일했던 능력있는 분들이 모두 NHN에 모이는 느낌이 들 정도로 NHN은 소위 말하는 ‘인력의 블랙홀’이 되어가고 있는 것 같다. 이러한 현상은 물론 개발자에 국한된 현상이 아닐 것이다.
인터넷 서비스 회사의 경쟁력은 사업 방향이나 아이디어, 환경 등의 요소등도 있겠지만 기초가 되는 경쟁력은 일하는 사람들의 질과 양에 있다고 봐도 무방하다. 인적 자원의 질과 양을 확보한 NHN은 해외진출의 벽만 뛰어넘는다면 미래가 밝아보인다. 이제 국내 시장을 넘어 아시아 시장에서 구글과 야후를 경쟁 상대로 인식하기 시작한 것으로 보인다. 최근에 내가 NHN에 투자하겠다고 판단한 근거도 바로 그러한 판단에 기초한 것이다.
이쯤 되면, 윤석찬 님이 다음과 NHN을 ‘다윗과 골리앗의 싸움’으로 비유하며 자조하는 것을 어느 정도 이해할 수 있다.
애초에 다음이 NHN의 경쟁자일까라는 질문에 대해서, 다음은 스스로에게 그 질문을 해보면 될 것이다. 적어도 최근의 다음의 행보들을 보면, 노골적으로 자신이 NHN의 경쟁자임을 자처하고 있다. 네이버와 거의 동일한 탑 페이지 구조 (원래도 비슷했지만, 최근 리뉴얼에서 더 비슷해졌다), NHN의 그린 윈도우 브랜드에 대응하는 블루 윈도우(?), 네이버 지식인 검색의 대체로서의 다음 카페 검색을 내세운 것이 그러하다. 그것이 상위 결정자들의 전략이 아니라고 하더라도 다음의 직원들은 NHN을 경쟁상대로 생각하고 있는 것이다. 다음이 NHN을 경쟁자로 생각하고 NHN과 같은 분야에서 경쟁하는 것이 다음에게 좋은 것인지 나쁜 것인지는 모르겠다. 설령 나쁘다고 하더라도 다음이 현재의 캐시 카우인 포탈 사업을 접을 수는 없을 것이다. 어쨌거나 확실한 것은 NHN을 뛰어넘으려면 지금보다는 잘해야 된다는 것이다.
한편, 독점에 대해서, 독점이 나쁘다라는 기본적인 내 입장에는 변함이 없다. 독점은 의도적이든 아니든, 불법적이든 아니든 공정한 경쟁을 방해한다. 결과적으로 사용자들이 얻을 수 있는 더 좋은 서비스를 얻을 수 없게 되는 일이 발생한다. 독점을 막는 마지막 방법은 Microsoft의 경우와 같이 반독점법에 의한 규제를 하는 것 이겠지만, 그것은 말그대로 마지막 방법이다. 기업은 법의 틀 내에서 공정한 경쟁을 해야하지만, 기본적으로 사용자에게 가치를 제공하고, 수익을 얻을 수 있어야 한다. 규제가 동작하기 이전에 다른 경쟁자가 사용자에게 더 나은 가치를 제공하고 수익을 창출함으로써 독점자의 이익을 빼앗아 가질 수 있어야 하는 것이다.
특히 미국이든 한국이든 인터넷 서비스 업계의 역사를 보면 영원한 1등은 없다는 것이 정설이다. 인터넷 서비스 업계의 특성상 독점자가 플랫폼이나 인프라를 장악함으로써 진입장벽이나 서비스 고착 (lock-in)현상을 만들기가 힘들기 때문이다. 규모의 크기가 문제가 된다고 생각하지는 않는다. 그러한 예로는 싸이월드, 마이스페이스, 페이스북을 보면 된다. 다음 또는 또 다른 누군가가 좀 더 열심히, 좀 더 잘 해주었으면 하는 마음이 항상 든다.
일반적인 소켓 API를 이용하여 멀티쓰레디드 서버 프로그램을 만들 때, 쓰레딩 방식을 결정함에 있어서, Boss-Worker 모델과 Peer 모델을 고려하게 됩니다.
서버 프로그램에 있어서 Boss-Worker 모델이라고 하면, (하나의) Boss thread에서 accept를 수행하고 Boss thread가 Worker thread에게 accept된 커넥션(connection)을 전달하여, Worker thread가 커넥션에 따른 서버 로직을 수행하는 것입니다. 한편, Peer 모델은 각 thread가 각자 커넥션을 accept하려고 시도하고, accept된 커넥션에 대해서 서버 로직을 각자의 thread에서 수행하는 것을 얘기합니다.
두 모델간에 어느 것이 낫냐는 질문을 종종 받곤 하는데, accept할 기회만 충분히 주어진다면, 큰 차이가 없다고 볼 수 있습니다. 굳이 말하자면, Peer 모델의 경우 (어떤 이유로든) thread 수가 부족하다면 accept될 기회가 없어서 자원이 남는데도 불구하고 불필요하게 처리량(throughput)이 떨어지는 서버가 만들어질 수도 있습니다. 클라이언트의 접속에 대해서 별 걱정없다는 면에서 Boss-Worker 모델이 좀 더 속편하다고 볼 수도 있습니다. 처리량의 문제는 클라이언트의 리퀘스트 양이라는 문제와 서버가 이를 처리할 수 있는 능력(capacity)이라는 문제와 연결되어있는데, 당연히 서버는 자신이 처리할 수 있는 양 이상을 처리하려고 시도하지 않아야겠죠. 이 때, 커넥션을 가지고 있는 상태에서 서비스할지 말지 결정하는 것이 커넥션이라는 하위 메커니즘에 대해서 이것저것 고민하는 것보다는 훨씬 편리합니다. (제 경험상, 다른 일을 할 수 없을 정도로 커넥션(클라이언트의 리퀘스트)이 들어오는 것은 상식적으로 클라이언트가 잘못된 상태거나 클라이언트-서버의 설계가 부적절하게 설계된 것입니다.)
원래 얘기로 돌아와서, Boss-Worker 모델과 Peer 모델은 적어도 POSIX 소켓 API를 이용하는 멀티쓰레디드 서버 프로그램에서는 일반적이지만, Java의 java.net.ServerSocket을 이용하여 accept하는 경우에는 Peer 모델을 사용하는 것은 부적절해 보입니다. 그 이유는 단순하게도 ServerSocket.accept() 메서드가 synchronized 메서드이기 때문입니다.
이 사실 자체가 정상적으로 ServerSocket을 accept하는 상황에서 문제가 되지는 않습니다. 하지만, Peer thread들을 정상적으로 종료시키려면 문제가 되기 시작합니다. ServerSocket.accept()는 non-blocking I/O이고 (당연하게도) interrupt도 불가능합니다. 따라서 Peer thread를 종료시키려면, ServerSocket.accept()에서 빠져나오게 하기 위한 방법이 필요합니다. ServerSocket.accept()를 빠져나오게 하기 위해서는 가짜 접속을 하거나, ServerSocket.setSoTimeout() 메서드를 통해서 소켓 타임아웃을 설정하는 방법밖에는 없습니다. 가짜 접속을 하는 방법이 복잡해 보이므로, 소켓 타임아웃에 의존해봅시다. 하지만, ServerSocket.accpet() 메서드는 synchronized 메서드이기 때문에, 모든 Peer thread에 대해서 소켓 타임아웃이 적용되어 모두 종료되려면, (number of peer threads) * (socket timeout) 만큼의 시간이 걸립니다. 그러면 가짜 접속을 하는 방법을 고려해볼까요? 이쯤에서 짜증이 나기 시작합니다.
해결책은 그냥 처음부터 Boss-Worker 모델을 사용하는 것입니다. 위에서 언급했듯이 숙제로 짜는 프로그램이 아니라면, Boss-Worker 모델이 Peer 모델에 비해서 별로 복잡하지도 않습니다. (제대로 짠 프로그램이라면, 어차피 통신 방법과 서버 로직은 잘 분리되어있어야 하겠죠) Boss-Worker 모델에서는 당연히 한 시점에 하나의 thread가 ServerSocket.accept()를 호출하므로 (socket timeout) 만큼의 시간이 걸릴 뿐입니다.
Peer 모델을 그대로 사용하면서, NIO의 java.nio.channels.Selector를 사용하는 방법도 있습니다만, 애초에 서버 프로그램을 NIO를 이용하여 짜지 않았기 때문에, 필요 이상의 복잡함이 추가됩니다.
사실 이런 종류의 문제들은 서버 프로그램에서 항상 반복되는 문제들이고 MINA와 같은 프레임워크들이 잘 해결하고 있습니다. 처음부터 이런 프레임워크를 고려하는 것도 한가지 방법입니다.
황색 저널리즘(Yellow Journalism)이라는 잘 알려진 개념이 있다. 황색 저널리즘이 생산하는 선정적인 기사들은 사람들의 주목(attention)을 불필요하게 점유함으로써 좀 더 생산적인 언론의 기능들 예를 들면, 의제 설정 기능(agenda-setting function)과 같은 기능을 방해할 수 있다. 황색 저널리즘 자체가 가질 수 있는 장점들이 있을 수 있겠지만, 그러한 장점은 선정성을 통한 이익 추구에 의해서 가려지게 마련이다. (이 글에서 선정적인 기사란 무엇인가 또는 선정적인 기사가 가지는 가치 등에 관해서 논하지는 않겠다. 우리는 우리에게 좀 더 이득이 되는 기사를 접할 수 있는 기회를 박탈하는 선정적인 기사에 대한 어느 정도의 공감대를 가지고 있다고 가정한다.)
인터넷 매체가 주요한 매체가 되기전부터 황색 저널리즘의 경계는 언론사, 매체, 기사들 사이에 뚜렷한 경계가 있었다. 주요 신문들의 헤드라인과 소위 ‘스포츠 신문’들의 헤드라인은 누가봐도 구분할 수 있다. 인터넷 매체가 점점 발전하면서 최근 1-2년 사이에 소위 ‘주류’ 신문이라고 부를 수 있는 신문사의 사이트- 인터넷 신문들이 변화하고 있다. 사이트의 첫 화면에 내거는 기사들의 반 정도는 선정적인 기사들에 속한다. 물론 종이 신문에서는 아직도 전통적인 의미의 헤드라인을 고수하고 있고, 웹 사이트에서도 그 기사들을 헤드라인이라는 분류를 통해서 접근할 수 있다. (수년간 조선일보의 첫 페이지를 현재의 것과 비교해보라.)
아마 이러한 변화의 경향은 주요한 포털 사이트의 뉴스 서비스와의 경쟁에서 비롯되었으리라고 생각한다. 뉴스 서비스의 소비가 인터넷으로 옮겨가기 시작하면서 전통적인 신문사들은 포털 사이트와의 경쟁에서 압박을 느끼기 시작했을테고, 결국은 이들을 베끼는 전략을 사용하기 시작한 것으로 보인다. 오히려 현재는 포털 사이트의 뉴스 서비스의 첫 페이지보다 주요 신문사의 인터넷 뉴스 서비스에서 선정적인 기사를 찾아보기 쉽다.
종이 신문이 인터넷 신문을 대체할 것인가 하는 문제는 또다른 흥미로운 문제지만, 그 문제를 논외로 하고서라도, 인터넷 신문이 우리 생활에 막강한 영향을 미치고 있다는 것은 사실이다. 언론을 접하는 대중들의 태도는 대체로 수동적인 것이 현실이기 때문에, 대중들이 ‘무엇을 선택하느냐’ 이전에, ‘무엇이 주어지는가’하는 문제는 중요한 문제라고 생각한다.
이런 문제는 법이나 규제로 해결되지는 않는다. 언론사들의 책임 의식과 지식인과 시민 단체들의 언론사들에 대한 감시와 비판을 통해서 해결할 수 있을 것이다. 물론 대중들의 교육은 언제나 빼놓을 수 없는 해결방법이다.
무엇보다도 인터넷 매체를 기반으로 하는 언론들은 – 주요 포털 사이트들을 포함한 인터넷 뉴스 서비스들은, 설령 기사의 생산을 담당하지 않는다고 하더라도, 이미 기사의 선별 과정을 통해 언론의 기능을 수행하고 있는 만큼 언론으로서의 책임 의식을 자각할 필요가 있다.
한편, 포털 사이트의 뉴스 서비스들이 수익을 창출하기 위해서 어느 정도 선정성을 활용할 수 밖에 없다고 한다면, 그것을 원하지 않는 사람들을 위한 다른 성격의 서비스의 가능성은 없는가 하는 의문이 든다.
Lucene에서 Analyzer의 역할은 Field의 텍스트를 TokenStream 즉, 토큰들의 스트림으로 만들어주는 역할입니다. 이 역할을 하는 abstract 메서드가 바로 Analyzer.tokenStream() 메서드인데, signature는 다음과 같습니다.
public abstract TokenStream tokenStream(String fieldName, Reader reader);
Lucene이 제공하는 Analyzer들에서 이 메서드의 구현은 하나의 Tokenizer와 다수의 TokenFilter들을 사용합니다. Tokenizer는 Field의 텍스트를 토큰들로 만들어주고, 이 토큰들이 TokenFilter들에 의해 변형되거나 걸러집니다. StandardAnalyzer.tokenStream() 메서드의 구현은 다음과 같습니다.
public TokenStream tokenStream(String fieldName, Reader reader) {
TokenStream result = new StandardTokenizer(reader);
result = new StandardFilter(result);
result = new LowerCaseFilter(result);
result = new StopFilter(result, stopSet);
return result;}
일단 TokenFilter들에 대해서 설명하면, StandardFilter는 영어에서 소유격을 나타내는 apostrophe 또는 apostrophe s를 제거해주거나 acronym에서 period(.)를 제거해주는 역할을 합니다. LowerCaseFilter는 이름이 의미하듯이 토큰들을 소문자로 만들어주는 TokenFilter고, StopFilter는 지정된 stop word들을 토큰에서 걸러내는 역할을 합니다. StandardAnalyzer가 지정하는 stop word들은 StopAnalyzer.ENGLISH_STOP_WORDS로, 영어에서의 관사나 전치사, 대명사에 해당하는 단어들입니다.
결국 StandardAnalyzer의 한국어 처리에서 중요한 것은 바로 StandardTokenizer인데, 일종의 parser generator에서 생성된 것으로 보입니다. Lucene 소스에서 lucene-2.0.0/src/java/org/apache/lucene/analysis/standard/StandardTokenizer.jj를 보면, 토큰 정의들을 볼 수 있는데, 한국어와 관련해서 다음과 같은 부분이 있습니다.
// basic word: a sequence of digits & letters
<ALPHANUM: (<LETTER>|<DIGIT>|<KOREAN>)+ ><중략 />
| < CJ: // Chinese, Japanese
[
"\u3040"-"\u318f",
"\u3300"-"\u337f",
"\u3400"-"\u3d2d",
"\u4e00"-"\u9fff",
"\uf900"-"\ufaff"
]
>| < KOREAN: // Korean
[
"\uac00"-"\ud7af"
]
>
이것을 보면 한국어 문자들을 유니코드 범위로 표현하고, ALPHANUM이라는 토큰이 한국어 문자를 포함하도록 처리하고 있는데, 따라서, StandardAnalyzer를 사용하면, ”911사태”, “Bush대통령”과 같은 것들이 하나의 토큰으로 처리됨을 알 수 있습니다. 중국어와 일본어 문자들은 CJ 토큰으로 따로 분리해놓은 반면 KOREAN은 왜 ALPHANUM으로 들어갔는지는 모르겠지만, 궁극적으로는 모든 언어의 문자들이 ALPHANUM에 들어가는 것이 정확하겠죠.
이렇게 해서, Lucene 2.0의 StandardAnalyzer에서 한국어 문자들로 이루어진 단어들이 제대로 인덱싱된다는 것은 알았지만, 이들을 이용해서 잘 검색할 수 있느냐는 다른 문제입니다. Analyzer.tokenStream() 메서드에서 돌려준 TokenStream에 담긴 토큰들을 인덱스에 그대로 저장하기 때문에, (이들을 다른 식으로 가공하기 위한 별다른 레이어를 발견하지 못했습니다.) 쿼리의 토큰들이 문서의 토큰들과 정확히 match되는 문서만 검색 결과에 포함됩니다. 즉, “Bush대통령”이라는 토큰으로 인덱스에 들어간다면, “Bush”나 “대통령”, “대통” 등으로는 이 토큰이 들어간 Document를 검색할 수 없습니다.
이 문제를 해결하기 위해서는, n-gram 분석이나 형태소 분석을 통해 토큰들을 적절하게 분리한 후, 인덱싱해야할 것입니다. lucene-2.0.0/contrib/analyzers/src/java/org/apache/lucene/analysis/cjk/에 있는 CJKAnalyzer와 CJKTokenizer는 2문자 단위로 토큰들을 생성하는 극히 단순한 Bigram 분석을 통해 이 문제를 해결하고 있는 것 같습니다. 이 경우의 문제점은 한국어에 존재하는 조사나 용언 어미등이 들어가는 토큰들을 전혀 배제하지 못하는 것인데, 검색의 품질을 상당히 낮출 가능성이 있습니다.
홍태희님은 루씬과 한글이라는 페이지(via 루씬에 대한 한국개발자의 고민들)에서 이 문제를 조사에 해당하는 부분을 토큰에서 잘라내는 TokenFilter를 도입해서 해결하고 계시긴 하지만, 조사에 해당하는 문자로 끝나는 단어들을 검색하지 못하는 문제가 있습니다.
제대로 된 오픈소스 한국어 Analyzer의 수요가 많음에도 불구하고 없는 것이 아쉽습니다. 짧은 생각으로는 단순한 휴리스틱으로는 힘들 것 같고, 충분히 많은 데이터를 이용한 분석이 필요할 듯 한데, 아무래도 오픈소스 활동에 전념하기 힘든 개인의 수준에서는 힘들지 않을까 싶군요. 좀 더 조사해 봐야겠습니다.
‘How To Code’는 팀 내에서 발표할까 생각했다가 취소한 발표자료입니다. 내용은 소프트웨어 개발에서 프로그래머가 지켜야하는, 또는 지키도록 기대되는 기본적인 원칙들 입니다. (빠진 것들도 많겠지만, 생각나는 중요한 것들만 적었습니다.)
발표 자료에 관해 잠시 언급하자면, 이 발표 자료만으로 발표하는 것은 졸린 설교가 될 가능성이 높기 때문에, 충분한 예들이 있어야 합니다. 가능하다면, 팀에서 쓴 코드를 직접 사용하는 것도 괜찮다고 생각이 됩니다.
최근에, 팀 내에서 잘 지켜지지 않는 개발 원칙들을 어떻게 바른 방향으로 유도할 것인가에 관해서 대단히 관심이 많아졌는데, 이런 원칙들만을 나열하는 것은 ‘당신이 잘못 했으니까 고치라’라는 식으로 들릴 가능성이 높고, 그렇다면 절대 변화는 일어나지 않을 것이라는 생각이 듭니다.
다른 사람들을 변화시키려면, 원칙 이전의 가치에 대한 공감대가 필요한데, 우선 그 공감대가 형성되어있는가, 또는 어떻게 형성될 수 있는가를 따져야할 것 같습니다. 공감대를 어떻게 형성할 수 있는가에 대해서는, 이러한 원칙들이 실제로 적용되는 경우를 보여주면서 그것이 좋다는 것을 ‘느낄’ 수 있도록 해주는 것이 가장 좋은 방법인 것 같습니다. 이를 위한 실제적인 방법으로 ‘코드 리뷰’를 생각 중입니다만… 여러모로 아직 고민 중입니다.
루비로 만들어진 크리스마스 트리. 크리스마스는 지났지만, 예쁘다아.
현재 사용하고 있는 Firefox Extension들의 리스트입니다. (원문은 제 위키의 Firefox Extension 페이지) Firefox 2.0으로 가기 전에 호환성도 체크해야 해서 한번 정리해봅니다. Tab Mix Plus 빼고는 대부분 호환되는 것 같군요. 그래서, Tab Mix Plus가 2.0을 지원하기 전까지는 2.0으로 가지 않을 것 같군요.
난 항상 좀 예쁜 여자애가 뿔테 안경을 쓰면 정신을 못차리는 것 같다. 그런데, 소개팅 상대들 중이나 주변의 여자들 중에는 그런 여자가 없다는 것이 문제.
저번 version에 비해 크게 달라진 점은 보이지 않는다. 이제 기술적인 process는 끝났고, ISO에서의 승인 process로 넘어간 것으로 보인다. ISO 표준 과정에 적어도 1년 정도는 걸릴테고, 실제로 여러 벤더들의 컴파일러 제품에서 이 Library extention을 볼 수 있는 것은 2-3년 후가 될 것 같다.
From: Beman Dawes <bdawes@acm.org>
Reply-To: boost@lists.boost.org
To: Boost mailing list <boost@lists.boost.org>
Date: Sun, 23 Jan 2005 15:59:49 -0500
Subject: [boost] Latest TR draft available
Reply | Reply to all | Forward | Print | Add sender to contacts list | Trash this message | Report phishing | Show original
The latest draft of the C++ Standard Library Technical Report is available.
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf
AFAIK, this is the version that will go to ISO for the long process of
formal voting. Thus it is the one Boosters should use; it contains a lot of
minor fixes that turned up during the final editing.
–Beman
Recent Comments