Lucene 또는 Lucene Java는 매우 유명한 오픈 소스 검색 엔진 소프트웨어입니다. Lucene은 Apache Lucene 프로젝트에 속해있는데, 이 프로젝트는 Lucene 외에도 Nutch나 Hadoop 등을 포함하는 Apache의 검색 소프트웨어 프로젝트입니다.

팀에서 웹크롤한 결과의 질을 가시적으로 만들기 위한 방법의 하나로 Lucene을 사용해보기로 했습니다. Lucene이 사용하기 쉽다는 평은 처로군으로부터 자주 들었지만, 이 정도 일 줄은 몰랐습니다. 팀이 가지고 있는 데이터베이스와 연동해서 콘솔을 통해 검색 가능하게 만드는데, 한시간 밖에 안걸렸습니다. Lucene에 대한 사전지식은 거의 없었다고 봐도 무방합니다. Lucene을 사용하기 위해 참고한 것은 Lucene 소스 코드 내에 들어있는 데모와 데모를 간단하게 설명하고 있는 문서 뿐이었습니다. Lucene에 관한 유일한 책인 ‘루씬 인 액션‘을 살짝 보긴 했으나 책에 등장하는 코드들이 out-of-date 더군요. Lucene을 연동하는 코드를 짜는 데에는 별로 도움이 안되었습니다.

1시간 동안 만든 것은 데모의 코드를 Copy and Paste하면서 만든 Indexer 프로그램과 Searcher 프로그램인데, 각각 인덱싱을 수행하는 프로그램과 생성된 인덱스로부터 검색을 수행하는 프로그램입니다.

Indexer 코드의 중요한 부분만을 보자면 대충 다음과 같습니다.

IndexWriter writer = new IndexWriter(INDEX_DIR, new StandardAnalyzer(), true);

// make lucene document
Document doc = new Document();
doc.add(new Field(“url”, uri, Store.YES, Index.UN_TOKENIZED));
doc.add(new Field(“title”, title, Store.YES, Index.TOKENIZED));
doc.add(new Field(“content”, cpmtemt, Store.YES, Index.TOKENIZED));

// add it to IndexWriter
writer.addDocument(doc);

writer.optimize();
writer.close();

간단히 설명하면, IndexWriter는 인덱스를 생성하는 역할을 하고, 인덱스의 단위는 Document입니다. Document는 복수의 Field를 가질 수 있고, Field 별로 tokenize할 것인가, 인덱스에 Field 내용을 저장할 것인가를 지정할 수 있습니다. Analyzer가 Field를 tokenize하는 역할을 하는데, IndexWriter에 명시한 것 외에 Field 별로 Analyzer를 지정할 수 있습니다.

디자인이 도메인을 그대로 반영하고 있고, 단순하면서도 확장성이 높은, 좋은 API입니다.

Searcher 코드도 한번 들여다 보죠.

IndexReader reader = IndexReader.open(“index”);
Searcher searcher = new IndexSearcher(reader);
Analyzer analyzer = new StandardAnalyzer();

QueryParser parser = new QueryParser(“content”, analyzer);
Query query = parser.parse(queryString);

Hits hits = searcher.search(query);

for (int i = 0; i < hits.length(); i++) {

Document doc = hits.doc(i);
String urlString = doc.get(“url”);
String title = doc.get(“title”);
String content = doc.get(“content”);
// …

}

역시 마찬가지로 코드만으로도 이해하기 쉽습니다. 별로 설명할 것이 없네요.

인덱싱 하는데에는 시간이 좀 걸리지만, 한번 인덱싱하고난 후에는 검색 속도는 대단히 빠릅니다. 10만개 정도까지밖에 안해봐서 실제 크기의 데이터에서는 어떨런지는 모르겠습니다.

한편, 한글 관련한 Analyzer 이슈에 대해서는 아직 잘 모르겠습니다만, 한글 검색도 그럭저럭 되는 것 같군요. 좀 더 자세히 알아봐야할 것 같습니다.

현재의 검색 솔루션이 맘에 안든다면, 엔터프라이즈급의 간단한 검색 솔루션으로는 부담없이 연동해서 쓸 수 있는 수준인 것 같습니다.

지금 구글 검색해보니, 좀 더 좋은 튜터리얼 들이 있군요. 참고하세요.

• Lucene Tutorial, by Steven J. Owens
• Lucene: A Tutorial Introduction to Full-Text Indexing in Java, by John Ferguson Smart
• Lucene-Mini-Tutorial, by funzel

Martin Fowler는 Effective Java Reloaded에서 언급했던 ‘Builder Pattern with Builder’s setter methods that return Builder’를 Expression Builder라고 이름 짓고 있다. Expression Builder는, CommandQuerySeparation을 어기는 Fluent Interface의 단점을 보강한 패턴이다.  Django Model의 filter 메서드를 봤을 때 다들 신기해했던 기억이 난다.

Effective Java Reloaded는 구독하고 있는 서민구 님의 블로그 글 ‘Effective Java Reloaded‘에서 발견한 것인데, Effective Java 의 저자인  Joshua Bloch 가 JavaOne 2006 에서 발표한 내용이다.

이 material의 도입부에서 Joshua는 “Effective Java Hasn’t Yet Been Reloaded, but I Have Plenty of Ammunition” 이라는 얘기를 하고 있다. 조만간 Effective Java  다음 판이 나오리라고 기대할 수 있을 듯 하다. 몇가지 인상적인 내용을 적어보면,

Builder Pattern with Builder’s setter methods that return Builder

NutritionFacts twoLiterDietCoke = new NutritionFacts.Builder("Diet Coke").sodium(1).build();

 위와 같은  Builder Pattern이 새로운 것은 아니지만, Joshua Bloch가 얘기하고 있는 것은, 이러한 패턴을 많은 수의 optional parameter를 가진  constructor의 대안이라는 것이다. 내가 직접 디자인하는 경우에는 constructor에 parameter가 많아야하는 경우를 가능한 한 피하려고 하기 때문에, 이 정도의 대안이 필요할 정도의 클래스를 디자인하게 되는 건 드문 일이지만, 간혹 수많은 parameter들을 가진  constructor들의 overloading으로 점철된 클래스를 맞닥뜨리게 되기도 한다. 이 경우 난 setter method와 Factory Pattern을 조합하는 형태(Dependency Injection의 Setter Injection)로 리팩토링 방법을 권장하는데, 아무래도 invariants를 벗어나는 instance를 생산한다는 것은 개운하지는 않은 일이다. 이런 경우에 위와 같은 Builder Pattern이 약간이나마 더 우아한 해결책이 될 수 있다.

한편, 이렇게, 간단한 개념을 표현하기 위해서 복잡한 방법을 동원해야한다는 것은 자주 프로그래밍 언어의 한계를 느끼게 한다. 언제쯤 Factory Pattern이나  Builder Pattern을 프로그래밍 언어 자체에서 지원할런지.

Erasure/Wildcard 때문에 복잡한 Generic

Generic이 명시하는 타입은 컴파일 단계에서만 유효할 뿐, 실행 단계에서는 타입 정보는 모두 사라지고 Erasure 만이 남는다. 아마 기존의  VM을 어느 정도 유지하면서도 Generic의 이점을 얻기 위해서 이러한 방법을 선택했으리라고 생각된다. 하지만, 동시에 Generic을 복잡하게 만드는 원인이 되기도 한다. (Joshua Bloch도 아마도 미래의 Java에서는 없어질 것이라고 언급하고 있다.)

Wildcard의 존재도 Generic을 복잡하게 만드는 개념 중의 하나인데 이를 가장 극명하게 드러나는 것이 바로 이 material의  Pop Quiz다.

public static void rotate(List<?> list) {
    list.add(list.remove(0));
}

언뜻 보기에 정상적으로 보이는 이 코드는  컴파일이 되지 않는 코드다. 자세히 들여다보면, list.add() 메서드와 list.remove()  메서드에서의 list의 타입은  wildcard type이고, List<?>와 List<?>라고 볼 수 있다. 그렇다면, list.add(List<?>) 에는  List<?> 를 넣을 수 있을까?  List<?>는, Object 클래스 또는 Object 클래스의 subclass의 List임이 보장될 뿐이기 때문에, List<?>와 List<?>를 같은 타입인지는 비교할 수는 없다.

Joshua는 같은 material에서 type parameter 자체가 사용되는 일이 없다면, wildcard를 사용하라고 조언하고 있지만, 과연 그렇게 해서 얻는 것이 무엇인지 의문이 든다. parameterized type 대신 wildcard type을 써야만 하는 이유가 뭘까? wildcard 관련 JSR을 살펴봐야겠다.

Erasure와  Wildcard 를 이해하지 못하면 Java Generic의 반만 이해한 것에 불과하다.

private final is the norm

필요하지 않은 자유도를 가능한 한 제약해야한다는 원칙을 따르고 있다면, 필드(멤버 변수)들은 물론, 파라미터 변수, 로컬 변수까지 final을 붙여야 하는가 하는 고민을 한번쯤 해봤을 것이다. 이는 C++ 프로그래밍 언어의 const에 관해서도 비슷한 이슈가 발생하한다. 결론부터 얘기하자면, 여기서 우리는 타협이 필요하다. 모든 타입 선언에 final (또는 const)을 붙이는 것은 프로그래머에게 상당한 비용을 요구하는 일이지만, 그로 인해 얻는 것이 그 비용을 상회하리라는 보장은 없기 때문에 그렇다. 따라서, 우리가 final을 사용함으로써 무엇을 얻는가를 따져보아야 한다.

이를테면, 상대적으로 좁은 메서드 scope로 격리되어있어서 그 영향이 적은 파라미터 변수, 로컬 변수 값의 변경은 제한된 코드 블럭에서 일어나기 때문에, 상대적으로 변수를 제어하거나 변수로 인해 발생한 문제를 수정하기도 쉬운 편이다. (이것이 메서드를 짧게 쓰라는 이유 중의 하나다.) 하지만, 클래스의 필드들의 경우에는 파라미터 변수나 로컬 변수들과는 접근 범위가 상당히 넓은 편이다. (클래스의 모든 메서드들 뿐만 아니라, 접근 권한에 따라 외부의 불특정 다수가 접근할 수 있으므로). 따라서, 필드를 가능한 한 final로 사용하는 것은 얻을 수 있는 이익이 크다.

비용-효율적(cost-effective)한 지점에서 타협을 해야한다는 얘기는, static typing과  dynamic typing 논쟁(아마도 이 외에도 많은 프로그래밍 언어 논쟁)에도 적용시킬 수 있다. 변수의 파라미터 타입을 명시하지 않아도 되는 언어를 사용하다보면, 주의를 기울인다고 하더라도 실수할 가능성이 있다. 설령 이러한 가능성이 매우 낮더라도, 한번 실수를 하게되면, 드러나지 않은 문제를 찾아내기란 결코 쉽지 않다. (strong typing 특유의 편안함은 여기서 온다.) 그렇다고 해서  static typing만을 극단적으로 추구한다면, 불필요한 수준의 타입 명시로 인해 개발  비용은 높아지고, 충분히 유연하지 못한 언어상의 한계로 인해 디자인에서 어려움을 겪게 될 것이다. 결국 우리가  static/dynamic typing 사이에서 취해야할 행동은 마찬가지로 cost-effective 한 어떤 지점에서의 타협이 될 것이다. C# 3.0의 ‘Static Typing Where Possible, Dynamic Typing When Needed‘를 참고해보길 바란다.

The Java Programming Language, 4th Edition, by Ken Arnold, James Gosling, David Holmes

Java를 처음 쓰기 시작한 것은 대학교 시절의 숙제나 프로젝트들을 통해서였다. 기억이 나지 않는 과목에서 applet을 만든 (아마도 지금까지도, 앞으로도 applet에 대한 유일한) 경험, Software Engineering 과목에서의 UML로 모델링하고 그것을 구현하는 프로젝트 (도메인은 Parking Lot이었던 걸로 기억한다), Software Project 과목에서의 웹 애플리케이션 경험을 제외하고는 Java를 사용해 본 것이 전무하다.  사실, Java 부문이 워낙 넓고 배울 내용이 방대하기 때문에, 그동안 습득해야할 기술 목록에서 고의적으로 빼놓은 상태였으며, 그동안 Java에 대한 나의 인상은 성능에 대한 미신과 높은 수준의 추상화에 대한 부러움 같은 것들이 섞여있었다고 볼 수 있다. 그러던 중, 작년 2월 경 입사한 회사 ‘첫눈’에서 시작한 프로젝트에 참여하게 되었고, 초기 셋업 과정에서 Java를 사용하기로 결정되었기 때문에 (당시까지는 나는 C++ 프로그래머였다), Java 프로그래머로서의 이력을 시작하게 되었다.

Java에 대한 경험은 있긴 하나 일천한, 어설픈 초보의 상태에서 가장 필요한 것은 언어와 표준 라이브러리에 대한 정확한 지식들이다. Head First Java가 Java 입문서로는 상당히 유명하지만, 내게 ‘입문’이 필요한 상태는 아니라고 생각했고, 입문서는 표준 명세를 대체할만한 엄격한 언어 정의를 포함하고 있지 않기 때문에 선택 목록에서 제외되었고, 역시 유명한 Thinking in Java 4th Edition의 경우에는 Java 5.0을 반영하는 새 판이 나올거라는 소식은 알고 있었으나, 당시에 출판되지 않았던 상태라고 생각하고 있었기 때문에 (지금 보면, 2006년 2월 10일에 출판된 것으로 보인다.), Java 프로그래밍 언어에 관한 가장 권위있는 저자들이 쓴 이 책을 선택하게 되었다.

책의 내용은 크게 문법과 표준 라이브러리의 두가지 부분으로 나뉘는데, Java 5.0의 문법을 대부분 커버하고 있으나, 표준 라이브러리는 핵심적인 부분(Collection과 Stream)에 집중하고 있다. 따라서, Java의 표준 라이브러리에 대해서 책을 통해서 공부하고 싶다면, 다른 책을 보아야할 것이다.

평이하게 쓰여졌으며, 중요한 부분에는 항상 예제를 덧붙여서 설명하고 있어서, 그 문법이나 라이브러리가 어떠한 용법을 가지고 있는지도 알 수 있기 때문에, 어느 정도는 잘 쓰여진 책이라고 평할 수 있을 것 같다. 어느 정도 Java에 대해 알고 있는 상태에서 그 예제를 설명하는 부분을 보면 상당히 지루하기 때문에, skimming할 것을 권장한다. 책의 성격상 상대적으로 덜 중요한 내용들에 대한 설명들도 많이 들어가기 때문에 입문서로서는 이 책은 약간 무거울 것 같다. (살짝 본 것 뿐이지만, 입문서로는 Java 언어의 중요한 사항들만 쉽게 설명하고 있는 Head First Java를 추천한다.) 특히, Stream과 Collection을 다 읽고 난 후 ‘기타’ 성격에 해당하는 라이브러리 부분을 읽을 때는 너무 지루해져서, 다른 책 (Effective Java)을 읽고 나서야, 다시 이 책을 잡을 수 있었다.

한편, 기대했던대로 문법의 각 요소들에 대한 정확한 semantic과 이 책이 커버하고 있는 라이브러리 부분에 대해서는 완전하게 설명하고 있기 때문에, Java 프로그래밍 언어에 대한 지식에 어느 정도 자신감이 생겼다. 당연히 옆에다 두고 Java 문법 레퍼런스로도 사용할 수 있다. 라이브러리를 레퍼런스 해야할 경우에는, (Java 개발자라면 누구나 알다시피) 사실 Sun의 문서화가 너무나 잘되어있으므로, 그것을 참조하는 것이 효율적이고 더 정확할 것이다.

전체적으로 Java의 The C++ Programming Language라고 해도 손색은 없을 것 같다. The Java Programming Language는 serious한 Java 개발자라면 반드시 읽고 넘어가야할 책이다.