검색하고 싶어요.

지금의 설치형 블로그인 텍스트큐브를 사용하기 전부터 HTML로 일일이 페이지를 만들어보기도 하고, SP Board 시절에 게시판을 써보기도 했었다. 시대(?)의 흐름에 따라 홈페이지를 운영하기 위한 툴을 바꿔보고, 다양한 사이트들을 사용해보기도 했는데, 늘 한가지 불만족스러운 것이 있었다.

'분명 예전에 이런 내용의 글을 썼던 것 같은데...'

라는 느낌이 드는 글을 찾을 때마다 한참을 고생하게 되는 것이다. 그런 글을 어디에 썼는지(블로그에 썼나? 게시판? 아니, 예전에 돌리던 다른 서버에 있는 웹페이지?)를 생각해내야 하고, 그 글을 쓸 때 썼던 문구도 왠만큼 정확하게 기억해 내야 한다는 점이다.¹ 그럴 때마다 구글이나 네이버 같은 검색기능을 가져다 쓸 수 있으면 얼마나 좋을까, 싶은 마음이 굴뚝 같았다.

Google CSE

이런 간지러운 곳이 있을 때 나온 것이, 바로 Google의 Custom Search Engine(CSE, http://www.google.com/coop/cse/)이다. 복잡하고 어려운 얘기를 생략하고 간단히 말해서, "'나의' 구글 검색 엔진"을 만들 수 있는 서비스정도라고 이해하면 되겠다. 개인적으로, 이런 사람들이 쓰면 좋을 것 같다.

1. 평소 자신이 사용하고 있는 툴(블로그, 게시판 등)의 검색 결과가 마음에 들지 않는 사람
2. 툴을 사용하지 않고 그냥 HTML 정도로 자료를 모으고 있어 검색할 방법이 없는 사람
3. 여러 곳에 자신의 흔적(?)을 남겨두어 자료를 한꺼번에 찾을 방법이 없는 사람
4. 그냥 뭔가 신기해서 한번 써보고 싶은 사람

Google CSE 만들기가 완료되면 자신의 블로그, 게시판, 혹은 사이트에서 다음과 같이 자신의 홈페이지 검색 결과를 구글을 이용해 사람들에게 보여줄 수 있다.²

나만의 Google 검색 엔진 만들기

준비하기

나만의 Google 검색 엔진(Google CSE)을 만들기 위해선 크게 준비할 것이 없다. 화면에서 시키는대로 뚝딱뚝딱 설정만 지정하면 나오는 코드 조각(snippet)을 자신의 홈페이지에 붙여넣기만 하면 된다. 단지 다음의 사항들만 만족시키면 될 것이다.

1. 스킨(혹은 HTML)을 수정할 수 있는가.
2. JavaScript를 사용할 수 있는가.

일반적으로 서비스형 블로그나 홈페이지(네이버 등에서 가입만 하면 쓸 수 있는 블로그나 홈페이지 서비스들)들의 경우, 스킨, 혹은 HTML 수정을 막아놓거나, 일부만 수정할 수 있도록 되어 있다. 또한 수정이 된다 하더라도 JavsScript를 사용할 수 없도록 해 놓은 곳이 있으니, 이를 미리 확인해 보는 것이 좋다.³

또 하나 준비해야 할 것은, 검색 엔진에 포함시킬 홈페이지의 리스트 정도.

Google CSE 설정

우선 Google CSE 홈페이지(http://www.google.com/coop/cse/) 에 접속한다. Google 서비스를 많이 사용하는 사람들이라면 친근할 페이지가 보인다. 우측에 있는 "Create a Custom Search Engine"을 누른다. 그러면 기본적인 설정 사항들이 나온다. 다음과 같은 것들이 있다.

1. Search engine name: 사용할 검색 엔진의 이름을 입력한다. "My Blog Search Engine"이라던가, "This is my Search Engine!" 등이 가능하겠다.
2. Search engine description: 만들고자 하는 검색 엔진에 대해 간단히 기술한다. "Search my blog posts" 라던가 하는 식으로. 귀찮으면 검색 엔진 이름과 똑같이 써도 된다.
3. Search engine keywords: 검색 엔진을 잘 설명하는 키워드를 입력한다. 일종의 태깅Tagging이라고 보면 된다. 적당히 생각나는 단어를 입력한다.
4. Search engine language: 검색 엔진에서 사용할 언어를 선택한다. 한국어Korean도 있으니, 선택해주는 센스!
5. What do you want to search?
   1. Only sites I select. 등록한 사이트만 검색하도록 만들 수 있는 옵션이다. 예를 들어, "나의 블로그만 검색할 수 있는 놈"을 만들고 싶다면 선택한다. 여러 개의 사이트를 등록할 수 있다.
   2. The entire web, but emphasize sites I select. 모든 웹을 검색 대상으로 하지만, 지정한 사이트의 순위를 조금 "강조"하는 수준의 검색 엔진을 만들고 싶은 경우 선택한다. "사람들이 내 블로그의 글을 좀 더 잘 찾을 수 있으면 좋겠지만, 그냥 웹의 검색 결과도 함께 보여줄 수 있다면 좋겠다."라고 생각하는 경우.
   3. The entire web. 이 옵션을 선택하면, 그냥 구글 검색 엔진을 가져다 쓰는 거라고 생각하면 된다.
6. Sites to search: 5-1, 5-2를 선택한 경우 입력 가능하다. (5-3은 구글 검색 엔진을 그냥 붙이는 거니깐.) 만들려고 하는 검색 엔진의 검색 결과에 포함시킬 사이트를 입력한다. 다음의 사항들을 주의한다.
   1. 한 줄에 하나의 사이트를 입력해야 한다.
   2. 사 이트 전체(즉, 블로그 전체)를 대상으로 할 경우, "http://[도메인]/*"와 같이 뒤에 "*"를 붙여줘야 한다. 부분적인 매칭도 가능한데, 예를 들어 주소에 "music"이 들어간 페이지만 검색 대상으로 삼고 싶다면, "http://[도메인]/*music*"과 같은 식으로 입력한다.
   3. 필자의 경우, 블로그(http://www.jayzlife.com/tt/), del.icio.us(http://del.icio.us/jackleg/), Flickr(http://www.flickr.com/photos/jackleg/)를 다음과 같이 등록했다.
      
      http://www.jayzlife.com/tt/*
      http://del.icio.us/jackleg/*
      http://www.flickr.com/photos/jackleg/*
7. Select an edition: 돈을 내고 고급 기능을 사용할 생각이 없다면, "Standard Edition"과 "Do not show ads on results pages."를 선택한다.⁴
8. 약관(I have read and agree to the Terms of Service.)을 읽고 동의하고 CSE를 사용하고자 할 경우, 체크한다.

입력할 게 많아 보이긴 하지만, 심호흡을 한번 천천히 하고 페이지를 천천히 살펴보면 입력할게 별로 없다. 모든 사항을 입력한 후, "Next" 버튼을 누르면 다음과 같이 테스트를 할 수 있는 페이지가 나온다.

검색 결과가 잘 나온다면, 그걸로 완료다. "Send confirmation email to [자기 gmail 계정]"에 체크를 하고 "Finish" 버튼을 누르면, gmail로 해당 검색 엔진을 관리하는 페이지로 바로 이동하는 URL 들이 온다. 번번히 로그인해서 검색 엔진 설정 페이지를 찾는 것이 귀찮은 사람들은 이 메일에 적혀 있는 URL을 잘 적어두도록 하자.

Code 얻기

이제 자신의 홈페이지에 삽입할 Google CSE의 코드를 얻도록 하자. Google CSE 홈페이지에 로그인을 하거나, confirm email로 온 URL을 따라가면 Google CSE 관리 페이지control page로 이동한다. 여기에서 [code] 메뉴를 선택한 후, 몇 가지를 선택하면 자동으로 코드 조각code snippet을 생성해준다.

여기에서, 별다른 설정을 하지 않고 Google CSE를 포함시켜 사용하고 싶으면 "Host results on a non-Google site using an:"과 "overlay – requires one page, but presents results in a modal overlay"를 선택한다. 그러면 하단에 Google CSE를 달 사이트의 URL을 입력한 후, "Generate Code" 버튼을 누르면, 코드 조각을 만들어준다. 이 코드를 복사한 후, 사이트의 원하는 위치에 넣으면 된다.

결론

Google CSE는 Google 측에 있어서 다양한 사용자의 메타데이터metadata를 얻을 수 있으며, 자사의 네트워크 확장, 롱테일longtail 광고 시장 획득 등 다양한 이득이 있다. 또한 사용자의 입장에서는 자신의 입맛에 맞는 검색 엔진을 손쉽게 만들어 제공할 수 있다는 장점이 있다. 이것이야말로 win-win 전략.

아직 서비스가 완벽하지는 않은 것 같지만⁵, 지속적으로 발전하는 서비스가 되었으면 좋겠다. 그리고 국내 서비스들도 이런 식의 숨어 있는 사용자 니즈needs를 보다 빨리 찾아내어 대응할 수 있기를 바란다. 서비스로서의 명성을 얻는 다는 것은 세세한 고객 관리에서 나오는 것일 테니까. = )

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

예전에 <검색으로 세상을 바꾼 구글스토리> 를 읽었던 기억이 났다. 존 바텔은 "검색한다"라는 말을 "구글한다(google)"로 바꾸어버린 엄청난 기업, Google을 중심으로 미국 검색 시장의 태동부터 지금까지(그 책이 쓰여졌을 때 까지)의 이야기를 풀어나갔다. 그리고 한참 동안 나는, "구글한다" 못지 않게 "지식인에 물어봐"라는 말로 "검색한다"를 대체해버린 네이버에 대해 쓰여진 책이 왜 없을까 궁금했다.

얼마 전에 여기저기 책들을 기웃거리다가 이 책을 발견하고선 반쯤 호기심에 사보기로 했다. (물론 내가 지금 겪는 일들도 영향을 주었지만.) 꽤 묵직한 느낌이었던 <검색으로 세상을 바꾼 구글스토리> 와는 다르게 작은 판형의 가벼운 느낌의 책은, 말 그대로 가볍게 읽을 수 있을 것 같았다. 게다가 저자 윤선영씨는 IT 기자로 활동했었다. 그 때문에 보다 각종 IT기업에 대해 자세히 알 수 있었고, 또한 기자라는 직업의 특성 상 보다 객관적이고 현실적인 이야기가 가능할 것이라 기대했었다. 그런데 책을 펴고 한 페이지, 한 장, 한 권을 다 읽어가면서 책을 읽는다는 것 자체가 너무 거북해지기 시작했다.

우선 한가지 짚고 넘어갈 것이 있다면, 네이버는 분명 훌륭한 서비스라는 점이다. 어렵잖게 반反네이버족을 곳곳에서 만날 수 있지만, (재미있는 점은 그런 반反네이버족을 네이버 안에서 찾기도 쉽다는 점이다.) 비약적인 논리를 펼치는 사람도 많고, 그저 싫다는 사람도 많다. 그런 사람들까지 어찌 일일이 아우를 수 있겠는가. 그렇다고 네이버에 단점이 없는 것도 아니고. 말이 좀 꼬이기 시작하는데, 한마디로 요약하자면 좋은 점도 있고, 단점도 있고. 그저 바라는 건 좋은 건 좋은 거고, 고칠 건 고쳐야 한다고 말해야 한다는 거지, 일면을 가지고 그 모든 것을 평가해서는 안된다는 점이다.

왜 이렇게 이야기를 시작하는가 하면, 이 책은 네이버 찬양론자에 의해 씌여진 네이버 찬양론 입문서이기 때문에, 좀 반박해보려고 한다. 그렇다고 무작정 반박하다보면 오해의 여지가 생길 것 같아서. 저자는 이 책의 곳곳에서 네이버(정확하게는 이해진과 김범수, 또는 그 휘하에 있는 사람들)가 한 일과 행보는 가히 획기적이며, 이보다 더 좋을 수는 없다고 이야기한다. 그래, 그것까지는 좋다. 그런데 갑자기 애꿎은 구글과 구글러까지 들먹거린다. 저자는 "구글을 좋아하는 사람들은 구글의 진짜 속내를 모르고 좋아하고 있다"고 한다. 그래, 그렇다면 네이버와 구글, 둘 다 좋아하고 둘 다 사용하고 있는 나는 어떻게 해야 하지?

네이버든 구글이든, 서비스 자체에 있어서의 장단점도 분명 존재하고, 시장을 독과점하면서 생긴 문제, 그리고 아직까지도 온전히 해결되지 않은 프라이버시 문제들이 존재한다. 그럼에도 불구하고 저자는 구글을 제국주의의 산물에 비유하고, 네이버는 그렇지 않다고 이야기한다. 구글과 네이버를 비교하는 것은 잘못된 것이라고 이야기하면서 정작 저자는 그 둘을 붙여놓고 있는 이 아이러니한 글이라니. 물론 이건 서비스에 대한 철학적인 문제이고 개인마다 모두 다르게 느낄 수 있다는 걸 안다. 하지만 이렇게까지나 "나를 따르라"는 듯한 이야기를 보고 있자니 슬며시 부아가 치민다. 문장 하나하나마다 반박할 수도 있겠지만, 그러자면 이미 이 글은 리뷰가 아니게 되어버릴게다.

물론 저자의 의견에 동의하는 부분도 있다. 웹 2.0에 대해 언급한 부분. 요즘 (아마도 IT업계 쪽에서만) 한창 유행하고 이미 하나의 패러다임이 되어버린 웹 2.0이라는 용어를 잘 해체시켜보자면 우리나라에서 오래전부터 시작한 많은 서비스들의 특징을 담고 있다는 걸 알 수 있고, 네이버의 지식인 서비스도 그러하다. (혹자는 지식인 서비스를 "모양만 웹 2.0"이라고 하는데, 왜 그렇게 느끼는지 좀 의문이다. 사실 그 문제를 따지자면 웹 2.0이라는 말 자체에 대한 논의가 먼저 이루어져야 한다. 실제로도 반反웹 2.0론자들은 웹 2.0이라는 말이 하나의 마케팅 용어일 뿐이라고 공격하기도 하고.) 왜 우리는 우리가 처음 시작한 서비스를 세계적으로 이슈화시키지 못하는 걸까. 저자의 말처럼 외국 학계에서 먼저 발표된 것을 받아들이기만 급급한 현행 때문에? 허나 그것은 그렇게 단순한 문제가 아닐 뿐더러, 그렇게 결론지어 버리면 저자는 이 책에서 내내 열변을 토한 이해진의 장점들에 반하게 되는, 모순이 되어버린다.

아직은 짧고, 지나칠 정도로 성숙되어버린 우리나라의 IT 문화와 기업들에 대해, 성공적인 모델을 기준으로 역사가 (비약하지만) 정리되었다는 점에서 이 책은 그마큼의 가치가 있다. 하지만 논란의 여지가 아직도 많은 문제들을 너무 확신에 차 독자에게 설파하려는 저자의 문체는 좀 거부감이 든다. 심지어 기술적인 면에 있어서의 오류를 (고작 나에 의해서!) 찾기도 했다. 혹시 이 책의 재판이 나오게 된다면, 보다 많은 사례들과 객관적인 사실들로 우리나라 IT, 특히 검색에 있어서의 역사를 잘 정리해 줄 수 있었으면, 눈에 띄는 몇 가지 기술적인 오류들이 수정되고, 좀 더 편안한 문체가 되었으면 좋겠다.

덧붙이기.

혹시나 해서 검색해보니 네이버에 대한 몇가지 책들이 2007년 초반에 나와 있다. 시기적으로 봤을 때 구글에 대한 책이 나온 것에 자극을 받아서 쓴 책들이 아닐까, 싶은 생각도 해본다.

심지어 <The Google Story>의 번역판인 <구글, 성공 신화의 비밀>을 공짜로 얹어주는 <네이버, 성공 신화의 비밀>이라는 책도 나와있으니, 이 책을 구입해 구글과 네이버에 대해 비교해보면서 읽는 것도 색다른 재미가 있을 듯 하다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Google Experimental Search

Google Labs에서 몇 달 전에 'Google Experimental Search'라는 이름의 베타 서비스를 들이밀었다. "실험적 검색"이라는 타이틀에 걸맞게, 이번 서비스는 검색 결과를 보여주는 새로운 방식들이 테스트되고 있다. 이번 서비스에서는 4가지 결과 view가 실험되고 있다. 그 중에서도 꽤 관심을 끌고 있는 끄는 view가 있는데, 고것이 바로 검색 결과를 시간 기준으로 보여주는 timeline view와 지도로 보여주는 map view이다.

새로운 방식을 이용한 검색 결과 탐험

timeline view와 map view의 공통점은 기존의 list 스타일의 검색 결과 view를 탈피하기 위한 새로운 시도라는 점이다. 어느 나라, 어느 서비스를 막론하고 현재 검색 결과는 기본적으로 list view를 기본으로 하고 있다. (Clusty.com과 같이 클러스터링을 내세운 서비스도 있기는 하지만, 이들도 키워드에 대한 클러스터링을 제외하고선 list view에서 벗어나지는 못했다.) 키워드를 입력하고 '검색' 결과를 누르면 검색 결과들이 1위부터 순서대로 보여진다. "통합 검색" 같은 패러다임도 검색 결과들을 성질에 따라 모아서 보여주는 새로운 패러다임이긴 하지만 '가장 키워드와 관련있다고 판단되는 컨텐츠부터 순서대로'를 벗어나지는 않는다.

이러한 컨텐츠 list view를 탈피하고자 새로운 메타데이터를 활용해 검색 결과를 보여주려고 하는 서비스가 timeline view와 map view이다. 이름에서 알 수 있듯이 timeline view는 시간을, map view는 위치를 중심으로 검색 결과를 보여주고 있다.

Timeline View

엄밀히 따지자면 timeline view 역시 list view를 기본으로 하고는 있지만, list를 생성하는 기준이 기존과 다르다. Timeline view의 검색 결과의 기준은 '시간'이다.


이 시간 정보는 그럼 어떻게 얻어지는가. 위의 'web 2.0' 검색 결과를 timeline view로 보는 그림을 보면 어느 정도 예상할 수 있겠지만, 이 시간 정보는 'web 2.0' 관련 컨텐츠를 분석해서 얻어낸다. 그러니까, (실제로는 어떤 방식으로 처리하는지 알 수 없지만) 다음과 같은 프로세스를 거치지 않을까 추정된다.

1. 'web 2.0' 키워드로 웹 페이지 검색을 한다.
2. 검색된 웹 페이지에서 시간 정보를 추출한다.
3. 추출된 시간 정보를 바탕으로 timeline view를 생성한다.

그러니까 예를 들자면, "web 2.0에 대해서 처음에 O'Reilly가 2004년에 한 학회에서 언급했다."는 내용이 있는 컨텐츠라면, "2004년"이 인덱싱되어 timeline의 2004년에 위치하게 되는 것이다.

Map View

Map view 역시 timeline view와 크게 다르지 않다.


Map view 역시 기본적으로 키워드 검색을 수행한 후, 컨텐츠에 '위치 정보'가 있다면 그것을 추출하고, 그 정보를 기반으로 지도에 표시해주는 형태다. 즉, "web 2.0 학회가 샌프란시스코에서 열릴 예정인데..."라는 컨텐츠가 있다면 "샌프란시스코"가 인덱싱되어 지도에 보여지게 되는 것이다.

한계

Timeline view나 map view 모두, "실험적"인 검색 서비스라는 점에서 봤을 때는 흥미롭긴 하지만, 실제로 서비스가 된다면 "과연?"이라는 느낌이 든다.

메타데이터 추출
임의의 웹 컨텐츠에서 메타데이터를 추출하는 것은 기본적으로 '매우' 어렵다. 이전부터 검색 관련 논문들에서 이런식의 view를 실험하고는 있었는데, 그들은 하나같이 '정확한 메타데이터를 추출하는 것이 어렵다'고 한다. 이는 기본적으로 시각과 위치 정보를 표기하는 명확한 기준이 없기 때문이다. 예를 들어 미국의 경우 mm/dd/yyyy 형태를 쓰지만 우리나라는 yyyy/mm/dd 형태를 쓴다. 또한 1/7/2007 이라고 하는 것과, Jan/7/2007이라고 하는 것에서도 차이가 있다. (이런 차이를 극복하기 위한 방법이 지난 WWW2006 학회에서 소개되긴 했었는데, 그 기술이 적용되었는지는 알 수 없는 일이지만.)

무엇이 올바른 메타데이터인가?
만약 모든 케이스를 구글측에서 학습해 웹 페이지에 있는 시간 정보와 위치 정보를 얻었다고 가정해보자. 그렇다면 추출된 메타데이터들 중 어떤 것이 해당 컨텐츠와 키워드를 가장 잘 연결해주는 메타데이터인가?

지금 'web 2.0' 키워드를 timeline view에서 찾아보면 위키피디아의 web 2.0 페이지가 "1995년"에 보여진다. 하지만 이 페이지에서 "1995년"은 "Amazon.com이 1995년에 서비스를 시작할 때 선보였던 기능들이 지금 web 2.0이라고 불리는 기능들과 다르지 않다."는 내용에 포함되어 있을 뿐이다. 오히려 이 페이지에서 'web 2.0'과 관련 있는 시간 정보는 "2003년"(web 2.0은 O'Reilly Media에서 처음 2003년에 사용되었다.)이나 "2004년"(첫 web 2.0 학회는 2004년에 열렸다.)일 것이다. 즉, 이 페이지 하나에만 수많은 시간 정보가 있는데, 아직까지 '어떤 시간 정보가 키워드와 가장 관련이 있는가'에 대한 문제가 해결되지 않은 것 같다.

또한 개인적으로 약 2년 쯤 전에 미국 뉴스 기사들로부터 위치 정보를 추출하는 프로젝트를 해봤을 때, 같은 이름을 가진 도시들, 다른 고유명사와 같은 이름의 도시들 등의 문제로 상당히 골치를 썩었었는데, 과연 map view에서는 이들을 제대로 걸러내고 있을지도 의문이다.

정말 원하는 정보는 있는 걸까?
그리고 무엇보다 가장 큰 의문점은 "timeline view나 map view로 보여지는 결과들 중에서, 내가 정말 원하는 정보가 있을까?"라는 점이다. (역시나 실제로 어떤 프로세스를 거치는지는 알 수 없지만) 2차 필터를 거치는 과정에서 스팸성 데이터 등은 충분히 걸러져, 키워드에 대한 정확도(precision)는 높아지겠지만, 과연 웹 어딘가에 있을, 내가 원하는 정보가 이 timeline view나 map view에 나타나는지(recall)에 대해서는 끊임없이 의심하고 불안해야 한다.

예를 들어 "web 2.0"으로 검색했을 때, 운 나쁘게도 내가 원하는 정보가 있는 컨텐츠에 시각 정보나 위치 정보가 없다면 이 컨텐츠는 timeline view나 map view에 나타나지 않을 것이고, 나는 내가 원하는 정보가 아직 없는 걸까, 의심해봐야 한다. 한마디로 사람 죽는다.

홀로 쓰이기는 어려울 듯

처음 timeline view 인터페이스를 봤을 때에는 "오! 이렇게 나온다면 키워드에 대한 정보를 시간순으로 볼 수 있으니 연구하기에 좋겠는걸! 재미난 데이터도 많이 있겠어!"라고 생각했었다. 하지만 실험을 해봤더니 시각 정보의 추출 등에서 아직 많은 허점이 보여 실망할 수 밖에 없었다.

timeline view 같은 경우엔 차라리 컨텐츠에 있는 시각 정보를 추출해서 사용하지 말고, '처음 그 페이지가 수집(crawling)되었을 때'를 사용했다면 차라리 훨씬 더 의미 있는 view가 되지 않았을까 싶은 생각이 든다. 현재로서는 하나의 웹 페이지가 "1995년"에 나타나도, 그 웹페이지에서 "1995년"을 언급했다는 걸 나타낼 뿐이지, 그 이외의 정보를 직관적으로 얻기는 힘들기 때문이다.

또한 앞서 언급한 recall에 대한 문제도 있어, 메타데이터의 정확성 문제가 해결된다 하더라도 각각 홀로 쓰이기는 힘들 듯 하다. UI에 대한, 혹은 메타데이터 추출을 위한 더 많은 고민을 거쳐 이들이 하나의 서비스로 융합되었을 때 오는 시너지 효과를 노려야 하지 않을까.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.