Peter Morville & Louis Rosenfeld의 Information Architecture for the World Wide Web 세미나를 위해 정리한 것입니다. 진한 글씨는 참가자들이 토론한 것을 일부 기록한 것입니다.

쿼리 빌더(Query Builder)

사용자에게는 보이지 않지만 검색 결과를 향상시키기 위해 질의어를 다듬어주는 요소. e.g.

철자 체크: 철자가 틀리면 교정해서 검색
음성 도구(Phonetic tools): 철자를 몰라도 비슷한 발음으로 검색. 이름 검색에 유용함. e.g. Soundex(발음으로 문자를 인덱싱하는 알고리듬. php나 mysql 등 관련 함수를 지원하는 언어도 많다)
파생어 도구(Stemming tools)
자연어 처리 도구: 구문을 분석해서 질의어의 성격을 구분. e.g. 질의어가 “how to”인지 “who is”인지 판별해서 검색 결과를 좁히는 데에 사용한다.
제어된 어휘와 유의어 사전: 동의어도 같이 검색

필요에 맞게 활용해야 한다. 다 쓴다고 다 좋은 것은 아니다.

결과 보여주기

검색된 문서가 모두 몇 개인지 나와야 한다.

결과가 너무 많으면 검색어를 고치거나 검색 대상을 한정할 수 있게 해야 한다. 그런 점에서 검색어 입력창에는 검색어가 그대로 남아 있어야 한다.

검색 결과를 보여줄 때에는 크게 두가지 쟁점을 고려해야 한다.

문서의 어떤 요소를 보여줄까?
결과를 어떻게 나열하고 묶을 것인가?

문서의 어떤 요소를 보여줄까?

간단한 가이드라인: 자기가 무엇을 찾는지 아는 사용자에겐 조금 보여주고, 자기가 무엇을 찾는지 모르는 사용자에겐 많이 보여줘라.

간단한 가이드라인의 변형: 무엇을 찾는지 아는 사용자에게는 콘텐트 대표 요소(representational content component, e.g. 제목, 저자)를 보여주고(예를 들면 제목으로 검색한 사용자들에겐 제목만 보여주는 것이 여기에 해당하지 않을까?), 그렇지 않은 사용자에게는 콘텐트 설명 요소(descriptive content component, e.g. 요약문, 키워드)를 보여준다.

무엇을 보여줄지를 사용자가 선택하게 할 수도 있지만, 그럴 경우에도 그런 옵션을 쓰는 사용자는 거의 없다. 따라서 가장 비중이 높은 수요에 맞춰서 기본값을 정해야 한다.

필드가 같아서 문서가 구분돼 보이지 않는다면 페이지 번호 같은 추가 정보를 표시해 구분되게 한다. e.g. 같은 책의 다른 판이 검색 결과에 나올 때.

콘텐트의 구조와 용처에 따라 어떤 요소를 보여줄지가 결정되기도 한다. 가령 전화번호부 시스템에선 전화번호를 가장 우선으로 원할 것이기 때문에 검색 결과에 당연히 전화번호가 나와야 한다. 결과를 클릭해서 전화번호가 나오는 것은 말이 안된다.

콘텐트에 구조라고 할 것이 없고, 전문(full text) 검색을 하는 경우 검색어가 어떤 맥락에서 쓰였는지 보여줘야 한다.

결과를 어떤 순서로 나열할까?

두가지 방법이 있다: 정렬과 랭킹

정렬은 결정을 내리거나 행동을 취하려는 사용자에게 유용하다. e.g. 온라인 쇼핑객은 가격순으로 정렬하고 싶어할 것이다. 이런 경우에는 사용자의 작업을 완수하는 데에 도움이 되는 정렬 옵션을 제공해야 한다.

랭킹은 정보를 이해하거나 무엇인가를 배우려는 사용자에게 유용하다.

다음은 여러가지 정렬 방법과 순위 매기기 방법이다.

가나다 순: 가장 익숙한 순서여서 다용도로 쓰이지만 이름을 정렬할 때 특히 유용하다. “a”나 “the”와 같은 관사는 정렬 순서를 계산할 때 빼야 한다.
시간 순: 언론 발표나 뉴스성 정보는 시간 역순으로 정렬하는 것이 좋다. (당시 워싱턴 포스트 사이트는 시간순 정렬이 기본 옵션이었다!)
연관성 순서:
- 보통 질의어가 문서에 얼마나 자주, 얼마나 인접해서, 문서의 어느 부위에서, 얼마나 인기 있는 문서에서 나타나는지로 결정된다.
- 사이트의 콘텐츠가 상이할 때는 주의를 요한다. e.g. 질의어가 몇 번 중요하게 언급된 짧은 글보다 지나가는 식으로 많이 언급된 긴 논문이 순위가 더 높을 수도 있다.
- 사람이 색인을 만들어서 연관성을 규정할 수도 있다. 키워드나 다른 필드도 검색하게 하면 색인을 만든 사람들의 판단으로 도움을 받는 셈이다. 특정 검색어에 대한 추천 결과도 선정할 수도 있는데, 이것은 전문성과 시간 투자가 필요한 일이다. 그래서 모든 질의어에 대해서 추천 결과를 다 정할 수는 없고, 가장 흔한 질의어에 대해서 이런 방법을 쓰는 것을 추천한다.
- 연관성 점수를 검색 결과에 보여주고 싶다는 유혹에 빠지지 마라. 연관성 50%와 49%의 차이는 정확히 무엇일까? 그런 점수를 보여주는 것은 무지를 드러내는 느낌을 줄 뿐이다.
사용자나 전문가의 평가에 따른 순위: 사례로는 Digg가 있다. 사용자가 충분히 많지 않으면 의미있는 결과를 내기는 어렵다.

검색 결과 묶기

검색 결과를 정렬하고 순위를 매기는 것 외에 다른 대안이 있다. 검색 결과를 묶음으로 나누는 것이다.

가장 간단한 방법은 그다지 쓸모가 크지 않다. e.g. 문서 유형(.doc, .pdf), 파일 생성일, 수정일. 더 유용한 방법은 사람이 적용한 메타데이터, e.g. 주제, 청중, 제품군, 언어로 묶는 방법인데, 이것은 비용이 지나치게 크다. 그럴 때에는 자동화를 도입할 수도 있다.

검색 인터페이스 디자인

검색 인터페이스 디자인의 변수들:

전문성과 동기: 사용자가 특수한 질의어 문법을 쓸 줄 아는가? 자연어를 선호하는가? 얼마나 많은 상호작용을 시도할 것인가?
정보 수요 유형(e.g. 아는 것을 찾냐 모르는 것을 찾냐)
찾으려는 정보의 유형
찾으려는 정보의 양

웹 초창기에는 많은 검색 엔진이 “전통적” 검색 엔진, 즉 온라인 도서관 카탈로그나 CD-ROM에 기반한 데이터 베이스에서 쓰던 검색 엔진을 웹에 들여오는 방식이었다. 이러한 시스템들은 복잡한 질의어 문법을 이해할 동기와 전문성을 갖춘 연구자나 사서들이 쓰는 것이었다.

웹이 발전하면서 전문성은 하향평준화 됐고, 새로운 사용자들이 참을성이 특별히 높았던 것은 아니었다. 사용자들은 보통 검색어 한두개를 연산자 없이 쓰고 “검색” 버튼을 눌렀다.

이에 검색 엔진 개발자들은 옛날에 쓰던 복잡한 트릭은 “고급 검색” 인터페이스에 숨기거나, 사용자 눈에 보이지 않게끔 검색 엔진 자체에 고급 기능을 추가하는 방식으로 대응했다.

향후에는 역사의 추가 다시 반대 방향으로 쏠리면서 더 복잡한 인터페이스가 생길런지? 모르겠다. 그러나 일단은 사서나 연구원, 전문가들이 쓰는 사이트가 아니면 검색 인터페이스는 되도록 간단하게 디자인하는 것이 최고다.

검색창

사용자가 검색 인터페이스를 보고 어떤 가정을 하는지 조사할 필요가 있다. 예를 들어

찾을 것을 입력하면 알아서 검색해줄 것이다
AND, OR, NOT 따위의 이상한 단어는 쓰지 않아도 된다.
이 검색 엔진은 동의어를 알아서 처리할 것이다
필드 검색? 검색할 수 있는 필드가 무엇인지 알아볼 시간은 없다고!
검색은 사이트 전체를 대상으로 수행될 것이다.

사용자들이 위와 같은 전제를 하고(대부분 그럴 것이다), 검색 엔진을 다루는 법을 특별히 배울 만한 동기부여가 되지 않는다면 보편적인 검색창을 써야 한다. 고급 기능을 써서 더 정확한 질의어를 만드는 방법을 안내하는 “도움말” 페이지를 만들 수는 있겠지만, 사용자들은 거의 보지 않을 것이다.

대신 사용자가 기꺼이 배우려 할 때는 가르쳐라. 가장 좋은 때는 최초 검색을 수행한 후에도 결정을 내리지 못하거나 좌절할 때다. 한번에 원하는 결과를 찾으리라는 희망은 사라졌다. 질의어를 고칠 준비를 한 셈이다. 이제 사용자는 질의어를 어떻게 고칠지 알고 싶어 한다. 당시 IBM 사이트에서는 “servers”라고 검색을 하면 다음과 같은 글귀가 나온다. “검색 결과가 729,288개입니다. 너무 많지 않나요? 그렇다면 ‘고급 검색’ 기능을 사용해보시거나, ‘팁’ 페이지를 참고해서 검색을 더 수월하게 하는 방법을 알아보세요.” 또는 카테고리를 선택해서 검색 결과를 더 좁힐 수도 있다.

보통 검색 결과가 너무 적거나(보통 0개) 너무 많은 것은 사용자들에게 질의어를 고쳐야 한다는 신호로 읽힌다.

검색창은 다른 입력란과 더불어 있으면 혼란을 일으킨다. 비밀번호 입력란에 검색어를 입력하는 일이 벌어지게 해서는 안된다. 가장 좋기로는 사이트 전반에서 쓰이는 내비게이션 가까이 두는 것이 좋다.

고급 검색: Just say no

고급 검색 인터페이스는 검색 시스템의 많은 기능을 드러내는 곳이다. 검색창과는 달리 검색 시스템을 다양한 방식으로 조작할 수 있으며, 이것을 쓰는 사용자는 보통 두가지 유형이 있다. 전문가(사서, 연구자, 변호사 등…)와 좌절한 사용자.

고급 검색 인터페이스에는 없는 것 빼고 다 들어간 모습을 보게 된다. 필드 검색, 기간 설정, 검색 구역 선택, 질의어 문법 등이 모두 여기에 자리를 잡는다. 사실 이런 것들이 인터페이스를 너무 어지럽게 만들어서 사용자들이 갈피를 못잡게 한다.

애초 가정했던 바와는 달리 이런 기능들을 쓰는 사용자는 거의 없다. 그래서 이 인터페이스를 디자인하는 데에 많은 시간과 역량을 투자하기보다는 필요할 때 검색을 수정하게 하는 방법을 고민하는 편이 낫다.

그러나 고급 검색을 완전히 무시할 수는 없다. 관습처럼 자리잡은 구석이 있어서 많은 사용자들이 고급 검색 인터페이스가 존재할 것이라고 기대한다. 이런 상황에서 좋은 지침은 어쩌면 검색 엔진의 다양한 고급 기능은 굳이 쓰려는 사람들을 위해 고급 검색 페이지에 두되, 압도 다수 사용자들이 고급 검색 페이지에 가지 않아도 되게끔 검색 시스템을 설계하는 것일지도 모른다.

**<노동자 연대=""> 사이트는 전문가적 수요(e.g. 우리 기자들)가 좀 있어서 고급 검색이 필요하다.**

질의 수정 지원

무엇을 검색했는지를 결과 페이지에서 보여줄 것. 때때로 사용자들은 기억이 깜빡깜빡 한다. 특히 검색 결과를 십여개 훑어보다 보면 그렇다. 검색창에 질의어를 남겨두면 무엇을 검색했는지 기억하게 해줄 뿐 아니라, 검색어를 쉽게 고칠 수 있게 해준다.
여러 검색 범위를 아우르는 검색 엔진의 경우, 각 결과가 어떤 분류에 속하는지를 보여주면 검색 범위를 수정할 때 유용하다.
시스템의 현 상태를 보여준다: 검색어가 무엇이었는지 외에도, 어떤 필터가 적용됐고, 어떤 순서로 정렬됐는지, 결과 개수는 얼마나 되는지 등
검색과 일람을 통합하기: 아마존에서 “카메라”를 검색하면 검색어와 일치하는 상품도 나오지만, 카테고리도 나온다(검색에서 일람으로 전환이 용이). “카메라” 카테고리로 가면 검색 범위가 “카메라”로 세팅된 검색창이 나온다(일람에서 검색으로 전환이 용이함) **<노동자 연대=""> 사이트에서도 글쓴이 이름으로 검색하면 해당 글쓴이의 기사를 모두 볼 수 있는 방법을 제공하자**

사용자가 막혔을 때

문제가 되는 경우는 두가지다: 검색 결과가 너무 많을 때, 검색 결과가 하나도 없을 때.

검색 결과가 너무 많을 때는 쉽다. 보통은 관련성을 기준으로 순위를 매겨주기 때문이다. 결과내 재검색과 같은 기능으로 검색 결과를 좁혀줄 수도 있다.

검색 결과가 하나도 없을 때는 좀 어렵다. 사용자가 막다른 골목에 이르지는 않게 하자. 즉 결과가 하나도 없을지라도 다른 선택지를 항상 제시하는 것이다. 선택지에는 다음과 같은 것들이 포함될 수도 있다.

검색어 수정 제안
검색 결과를 향상시키기 위한 지침이나 팁
일람 수단 제안
일람과 검색 모두 안될 경우를 대비한 담당자 연락처

**<노동자 연대=""> 사이트에서도 도입할 만한 팁이다.**

유의어, 어휘 제어, 메타데이터

메타데이터란 무엇인가?

“데이터에 대한 데이터”라는 말은 그다지 도움이 되지 않는다. 인식론이나 형이상학의 영역으로 빠지지 않으려면 실천에서 메타데이터가 하는 역할에 초점을 맞춰야 한다.

메타데이터는 페이지를 더 잘 둘러보고 찾아내기 위한 목적으로 문서와 페이지, 이미지, 소프트웨어, 비디오, 오디오, 그 외 콘텐츠 객체를 설명하는 데에 사용된다.

… to be continued