Software Development

Koster, M. 1994. ALIWEB – Archie-Like Indexing in the WEB.

첫번째 WWW 컨퍼런스인 WWW ’94에 발표된 paper.

1990년 11월에 첫번째 웹서버가 생긴 이후로, 웹의 사용자와 정보의 크기는 점점 늘어나고 있었고, 1993년에는 200개 이상의 웹서버가 있다고 알려지게 되었다. 이렇게 되자, 웹에서 어떤 정보를 찾는 것은 점점 힘들어지게 되었고, 이 문제를 해결하기 위한 여러 노력들이 1993년부터 나타나기 시작했다. 그 결과로 나타난 첫번째 웹 검색엔진이 바로 ALIWEB이었다.

도입 부분에서, 웹의 resource discovery 방법이 진화한 과정을 Browsing – Listing – Searching (Catalogue) – Automatic Collection (from Catalogue) – Automatic Discovery의 단계로 설명하고 있는데 흥미롭다. 현재의 검색엔진에서 Automatic Discovery를 당연시하고 있는 것을 생각하면, 마치 FORTRAN Compiler가 탄생했을 때, 이를 Automatic Programming이라고 부르던 느낌이랄까.

한편, Archie란 여러 Anonymous FTP 사이트가 가지고 있는 파일들을 인덱싱하여 검색할 수 있도록 해주는 Anonymous FTP의 검색 엔진이었다. Archie의 동작 방식은 각 Anonymous FTP 사이트에서 파일 리스팅에 해당하는 파일을 받아서 사용자가 검색 가능하도록 해주는 것이었다. 이 paper에서 Archie-Like라고 부르는 것도 그러한 동작 방식을 사용했다는 것을 의미한다.

ALIWEB의 동작 방식은 다음과 같다.

1. 웹사이트 관리자가 정해진 포맷으로 각 사이트에 대한 인덱스 파일을 만들고 이를 ALIWEB의 웹 인터페이스를 통해 등록한다.
2. ALIWEB은 등록된 웹사이트들의 인덱스 파일들을 자동으로 받아와서 이를 검색 가능하도록 인덱싱한다.
3. 검색을 원하는 사용자는 오늘날의 검색엔진 인터페이스와 거의 같은 모습의 ALIWEB의 웹 인터페이스를 통해서 쿼리를 보내고 결과를 볼 수 있다.

이 paper에서 밝히고 있는 ALIWEB의 문제점은 역시

• 사이트별 인덱스 생성 과정의 어려움, 그리고
• scalability

이다.

사실, 사이트 관리자에 의한 사이트별 인덱스 생성은, 사이트 관리자가 그 사이트에서 어떤 것이 인덱싱 되어야하는가를 가장 잘 알고 있을 것이라는 합리적인 의도를 가지고 있고, Koster는 이러한 방식이 적어도 medium term에서는 잘 동작할 것이라고 예상했지만, 실제로 이는 실패했다. 물론, 사이트 관리자에 의한 사이트별 인덱스 생성이라는 개념은 현재에도 Google Sitemap과 같은 형태로 존재하지만, 적어도 이러한 메커니즘이 Automatic Discovery의 주요한 역할을 맡고 있는 것은 아니다.

어쩌면, 텍스트를 위주로 한 현재의 웹에 대한 Automatic Discovery가 정점에 이르면, 오히려 장기적인 관점에서, 사이트 관리자에 의한 사이트별 인덱스 생성이라는 개념이 유효해질 가능성도 있다. Semantic Web이나 Web Services와 같은 웹을 구조화된 형태로 만드려는 노력이 어떤 방향으로 진행될지는 아직 미지수다.

Scalability의 문제는 프로토타입의 성격을 지닌 ALIWEB에서 해결되리라고 기대할만한 문제는 아니지만, 사이트별 인덱스를 사이트 내의 상위 레벨 서비스에 대해서만 생성한다든가, 특정 분류나 도메인에 한정된  ALIWEB 사이트를 만들어서 해결한다는 생각은 현재 시점에서 바라볼 때는 실망스럽다.

현재의 웹을 바라보면, 상위 레벨 서비스만 검색되면 되는 것이 아니라, 하위 레벨 페이지들이 실제로 사용자들에게 가장 흥미로운 내용을 포함하고 있고, 검색의 결과로서 적합한 경우도 많다. 한편, 특정 분류나 도메인에 한정된 검색도 물론 유용하지만, 이것이 Scalability 부족의 대안으로 나오는 것은 현재 웹의 크기를 고려할 때 바람직하지 못하다.

소스 파일(이하, 파일)도 모듈의 일종이다.

어떤 프로그래밍 언어에서는 파일을 언어 자체가 정의하는 개념(예를 들어, C++의 ‘컴파일 단위’)으로 본다. 어떤 프레임워크에서는 특정한 파일은 어떤 특별한 역할을 하는 코드의 집합으로 본다. (예를 들어, RoR의 파일 구성) 마찬가지로, 어떤 프로젝트에서는 정해진 독특한 규칙에 따라 특정 파일에 특별한 역할을 부여할 수 있다.

이런 면에서, 소스 파일의 구성(File Organization)은 소프트웨어 품질에 영향을 미치는 디자인 결정 중의 하나다.

파일이라는 OS라는 낡고 거추장스러운 곳으로부터 나온 (어떤 면에서) 언어 외적인 요소를, 고매하고 청명한 정신으로부터 태어난 자신의 코드와 결부시키는 것이 불편하게 느껴질지도 모르겠다. 언어 자체가 파일 개념에 의존하지 않는다면, 한 프로젝트의 모든 코드가 한 파일에 들어있든, 1억개의 파일에 들어있든 무슨 상관이 있겠는가.

하지만, 아직은 프로그래밍 세계는 파일이라는 요소에 의존하는 편이다. 그럴 듯한 IDE를 사용하지 않는 프로그래머들도 너무나 많다. (당신이 vim을 IDE라고 주장하더라도 notepad는 어떤가?!) 그들에게 파일은 Readability에 직접 영향을 미치는 단위가 된다. 너무 긴 파일은 너무 긴 클래스나 너무 긴 함수의 문제점과 동일한 문제를 유발한다. 읽기 힘들다. 파악하기 힘들다. 소위, 스크롤의 압박이란거다.

한편, 현재의 IDE들은 언어가 파일에 의존하지만 않는다면, 파일이라는 요소를 배제할 수 있는 포텐셜을 가지고 있으나, 단순하게도, 그렇게 하지 않는다! 그나마 우리를 행복하게 해주기 위해 IDE를 제작하는 분들에게 뭔가를 추궁하지는 않겠다. 아직은 우리는 파일이라는 개념에 너무나 익숙하다. 정말로 파일이 싫은가 하면 그렇지도 않단 말이다.

어쨌든, 파일은 모듈이고 다시 말해, decomposition의 단위다. 이것은 파일이라는 모듈에도 높은 cohesion과 낮은 coupling이 요구된다는 것이다.

Java와 같은 언어에서는 (Top-level) 클래스 각각은 그 클래스의 이름을 가진 독립된 하나의 파일을 점유하는 것이 일종의 컨벤션이다.

얼마전에 코드 리뷰를 한 적이 있는데, Top-level 클래스 5-7개 정도가 하나의 파일에 들어가 있는 경우를 발견했다. 이것을 발견하자 내 직관은 뭔가 잘못된 것이라는 알려주었다. 도대체 이 클래스의 범위는 어디까지인거지? 왜 이렇게 길어? 이 클래스로 이동하려면? (난 이클립스를 사용하고 있고, 코드 navigation 기능은 숙지하고 있으니, 친절하게 알려주지 않아도 된다.) 혼자만의 생각이지만, 다른 개발자가 이런 코드를 보더라도 분명 나와 비슷한 느낌을 받으리라고 생각한다. (무슨 소리?)

자, 그럼 직관이 아니라, 뭔가 납득할만한 설명을 필요한 것 같다. 대체 왜 그  클래스들은 한 파일에 있어야만 할까? 클래스들을 자세히 들여다보면, 1) A와 B는 Use 관계에 있으나, 그 역할은 충분히 다르고, 특히 A와 B는 그 파일 밖에 있는 클래스 P와 Q에 의해서 사용되고 있었다. 2) D는 C의 구현이 되어야할 부분을 다시 모듈화한 것이었다.

1) A와 B는 충분하게 cohesive하지 않을 뿐만 아니라 파일 외부의 클래스에 의해서도 사용되므로 다른 클래스들과 동등한 자격으로 – 즉, 파일로 노출될 필요가 있다. 2) D는 C의 구현에 해당하고 외부로 노출될 필요가 없으므로 Top-level 클래스가 될 필요가 없다. 즉, D는 C의 임베디드 클래스가 되면 훌륭하다.

이런 식으로 리팩토링을 하고 나니, 하나의 파일에는 하나의 Top-level 클래스만이 남아있었다.

물론 하나의 파일에 무조건 하나의 Top-level 클래스만 써야만 하는 법은 없을 것이다. 내가 알지 못하는 문맥에서의 필요성이 있을 수도 있고, Top-level 클래스를 하나의 파일에 모아두는 것에 페티쉬를 가진 경우도 있을 것이다. 물론, 파일 개념의 철폐를 부르짖는 해방주의자도 빼놓을 수는 없다. 하지만, 대부분의 경우에는 별 생각 없이 한 파일에는 하나의 Top-level 클래스를 두는 것으로 생각하면 별 탈 없을 것이고, 어쩌면 칭찬을 들을지도 모른다.

오늘의 Rule of Thumb: Java 프로그래밍에 있어서 하나의 파일에는 하나의 Top-level class를 두자. 땅땅땅.

소프트웨어가 해결하려는 문제가 복잡하다면 그 해결책 즉, 소프트웨어도 복잡해진다. 즉, 소프트웨어의 복잡성은 부정적인 효과를 가지지만, 항상 잘못된 것이고 거절할 수 있는 것은 아니다.

따라서, 소프트웨어의 복잡성 문제를 해결하려고 할 때는 불필요한 소프트웨어의 복잡성(Unnecessary Software Complexity)라는 개념을 가지고 얘기해야한다.

한편, 소프트웨어의 복잡성이 문제의 복잡성에 의존하기 때문에, 문제가 달라지면 불필요한 소프트웨어의 복잡성도 달라진다. 다르게 말하면, 문제가 달라지면, 소프트웨어를 평가하는 기준도 달라질 수 있다는 것이다.

이야기를 하나 해보자. 어떤 소프트웨어 팀은 실제로 많은 문제가 있다고 생각해서, 또는 의욕적이어서 많은 문제를 해결하는 소프트웨어를 만든다. 시간이 지나고, 그런 문제를 해결할 필요가 없어졌고, 사람들은 그런 사실을 잊어버렸다고 해보자. 남아있는 소프트웨어는 그 시점에서 불필요한 소프트웨어의 복잡성이 높은 소프트웨어일테고, 그 소프트웨어의 개발자는 비난을 받는다. 이것은 공평하지 못하다. 소프트웨어 엔지니어링에서 얘기하는 것처럼 문제의 합의에 대한 계약서라도 써놓는 것이 이러한 문제를 해결할까? 그렇지는 않다고 생각한다. 사람들은 ‘문제가 변화한다’는 사실에 대한 명확한 인식을 가지고 있어야할 뿐만 아니라 ‘문제를 알고있다’라는 생각에 대해 좀 더 보수적일 필요가 있다.

문제가 언제 변화하냐고? 문제는 항상 변화한다.

web_crawler_20070223.pdf

올해 초에 신입 팀원들을 대상으로 발표한 자료로, Web Crawler의 기본적인 설계와 구현시 신경써야할 기초적인 사항들을 언급하고 있습니다. 대단한 내용이 있는 것은 아니고 단순히 Mining the Web의 Web Crawler chapter를 정리한 내용입니다.

Web Crawler 개발에 있어서 가장 중요한 것은 무엇이냐고 제게 묻는다면 저는 이 발표자료의 Closing에 적혀있는 한 줄로 대신 답하겠습니다.

Understand status quo of Web

사실 어느 정도 숙련된 개발자라면 Web Crawler의 기초적인 기능들은 대단히 단순하기 때문에 별로 어렵지 않다고 느끼실 겁니다. 저도 물론 처음엔 그렇게 생각했구요. 하지만 현재는 약간 생각이 달라졌습니다. 훌륭한 Web Crawler를 만들 수 있는 능력은 바로 웹의 현재 상태에 관한 지식을 얼마나 가지고 있는가 또는 얻을 수 있는가에 달려있다고 생각합니다. 이 발표자료를 쓸 때보다 이러한 생각이 더욱 강하게 드는 요즈음입니다.

사람들이 미술을 처음 시작하면 잘못된 부분을 다시 그리는 것을 꺼려한다. 일단 그 정도로 그린 것에 만족하며, 다시 손을 대다가 혹시 더 망치지나 않을까 염려한다. 그리하여 방금 그린 것이 그렇게 나쁘지는 않다고, 어쩌면 최선의 작품일지도 모른다고 생각하여 스스로를 설득한다. 폴 그레이엄, 해커와 화가

전에 언급한 Non-ASCII 문자 스트링과 관련한 Java와의 호환 문제가 Charles Nutter가 예고한대로 JRuby 1.0에서는 말끔하게 해결되었음을 저의 테스트 케이스로 확인했습니다. 강문식 군에 의하면 이창신 님이 이 작업에 기여하신 모양입니다.

이 글은 2004년 12월 14일, 네오위즈에서 일하던 시절에, 팀 내부에 공유한 메일입니다. (영어 단어나 어법 오류 등은 수정했습니다.) 현재의 제 생각과는 약간 다른 부분도 있지만,

• 문제 영역의 언어로 이름짓기
• 적절한 비유의 사용
• 최소화 인터페이스

등은 저 뿐만 아니라 많은 사람들이 동의하는 프로그래밍의 원칙들입니다.

이름 짓기

바쁜 일정과 많은 업무로 인해서 팀 내에서는 ‘이름 짓기’가 중요하게 여겨지지 않고 있지만, 저는 이름 짓기에 대해서 강한 의견을 가지고 있는 사람입니다. ;-)

객체와 메서드의 이름을 지을 때는 그것이 하는 역할에 맞게 이름을 짓는 것이 좋습니다. 당연히 이 역할은 객체가 해결하려는 문제의 도메인 안에서, 그 도메인의 언어로 정의됩니다. 따라서, 객체와 메서드의 이름은 문제 도메인의 언어로 기술하는 것이 가장 바람직합니다. (일반화된 이름은 원래 문제 도메인의 이름이 아닌 경우가 있지만, ‘일반화’ 역시 일종의 해결하려는 문제입니다)

예를 들어, 6살짜리 어린이가 가게에서 사탕을 사먹는 문제에 대해서 해결 방법을 기술하려면, 6살짜리 어린이가 이해할 수 있어야 하고, 사탕이라는 단어가 거의 반드시 들어가야겠죠.  또한, 사탕을 사 먹어야 하는데, 다른 도메인의 언어, 즉 음표라든가, 양자역학 같은 단어가 나오면 곤란합니다.

junkmemocheck를 희생양으로 삼아 예를 들어보죠. (junkmemocheck는 쪽지를 너무 많이 보내는 사람을 차단하기 위해 사용자별로 최근에 쪽지를 보낸 수를 세어주는 컴포넌트입니다.)

메서드 이름 짓기

제가 이해한 바로는, junkmemocheck(이하, 줄여서 JMC)에 관련된 시나리오는 다음과 같습니다.

1. 사용자 A가 쪽지를 보낼 때, A가 쪽지를 보냈음을 JMC에 알려줍니다.
2. 사용자 A가 미리 정해진 시간 내에, 쪽지를 보낸 수를 얻거나, 너무 많이 보냈다는 정보를 얻어옵니다.

이를 좀 더 단순한 말로 적어보죠.

1. 특정 사용자가 쪽지를 보냈다.
2. 특정 사용자가 최근에 쪽지를 보낸 수를 주세요.

메서드 이름으로 바꿔보죠.

쪽지는 Memo라는 용어로 대치하고, ‘미리 정해진 시간 내에’라는 requirement에 대해서 ‘Recently’라는 단어를 도입했습니다.

1. sentMemo(user)
2. getCountOfMemoSentRecently(user)

좀 더 줄이면,

1. sentMemo(user)
2. getRecentMemoSent(user) 또는 getMemoSent(user)

클래스 이름 짓기

이러한 역할에 비추어보면, junkmemocheck는 (Sent)MemoCounter 같은 이름이 더욱 적당하지 않을까 싶습니다. (사실 ‘정해진 시간 내’라는 제약 조건이 있어서, “Counter”라는 비유가 약간 부적절해 보이므로, 좀 더 나은 비유가 있으면 좋을 듯 하네요.)

MemoCounter
+ increaseCount(user)
+ getRecentCount(user)

일반화된 이름 짓기

나중에 다른 요구사항이 생겨서, 쪽지만이 아니라 다른 곳에도 이 어플리케이션이 사용되기도 결정되었다고 합시다. 우리는 “Counter”라는 비유를 이미 사용했으므로, 이를 그대로 사용하면 될 것 같습니다. 사용자 대신 슬롯(slot)이라는 개념을 사용합니다.

Counter 클래스의 역할(Role)은 다음과 같습니다.

1. k 슬롯의 카운터를 하나 증가시킨다.
2. 일정 시간 내에 k 슬롯에 증가된 카운터 값을 가져온다.

이를 바탕으로 다음과 같이 이름을 지을 수 있겠네요.

Counter
+ increaseCount(k)
+ getRecentCount(k)

개선된 디자인

사실 Counter 안에 k라는 슬롯을 찾는 것보다는, k라는 이름의 Counter가 있는 것이 더욱 직관적입니다. Counter의 메서드에 k를 명시하기 보다는, k에 해당하는 Counter 객체가 있는 것이 낫겠죠.

kCounter = CounterCollection.getCounter(k)
kCounter.increaseCount()
kCounter.getRecentCount()

좀 더 단순하게 만들어볼까요? CounterCollection에 Count가 있는 것은 당연하고, Count를 increase하는 것은 당연하므로,

kCounter = CounterCollection.get(k)
kCounter.increase()
kCounter.getRecent()

성능 고려하기

MemoCounter 든, Counter든 역할에 따라 두개의 operation으로 분리했습니다. 하지만, 내부적인 구현에 따르면, 각각이 server로 메시지를 따로 보내야 한다면, 그리고 거의 항상 두 operation이 같이 쓰인다면, 이러한 분리는 비효율적입니다. 한번에 물어볼 수 있는 방법이 필요합니다.

Counter
+increase(k)
+getRecent(k)
+increaseAndGetRecent(k)

가능한 한 원래의 인터페이스가 직관적이므로 유지하는 것이 좋다고 생각하지만, 이를 유지하면서 성능을 개선할 수 있는 더 나은 방법이 있을지도 모르겠습니다.

인터페이스 최소화

거의 항상 단순한 인터페이스가 좋습니다. 필요없는 인터페이스는 사용자를 혼란스럽게 합니다. 예를 들어, increaseAndGet(k)만이 사용되고, 다른 메서드는 사용될 가능성이 별로 없다면,

Counter
+increaseAndGetRecent(k)

만으로도 충분합니다.

결론

저는 메서드 이름부터 새로 짓기 시작했지만, 좀 더 일반적인 방법은,

1. 문제 해결에 필요한 객체의 이름과 역할을 정합니다. 객체를 정할 때는 문제를 해결하기 위한 비유를 생각해보면 좀 더 쉽게 지을 수 있습니다. 문제는 얼마나 적절한 비유인가인데, 어떤 비유가 객체의 역할 즉, 문제의 해결방법에 얼마나 근접하느냐를 따져야할 것입니다. 객체의 이름은 항상 문제 도메인의 언어나, 비유의 이름으로 짓습니다.
2. 객체 역할에 따라 메서드를 추가합니다. 하나의 동작에 하나의 메서드를 추가합니다. 메서드 이름 역시 항상 문제 도메인의 언어로 짓습니다.
3. 이 후에도 얼마든지 성능 고려나 인터페이스 최소화를 할 수 있습니다.