stophobia

유튜브의 발렌타인데이 센스

stophobia — Thu, 14 Feb 2008 14:39:18 +0900

하트표로 바뀐 빨강 원.

재미있네요~ 발견하신분?

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

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

구글의 에러...

stophobia — Thu, 14 Feb 2008 14:10:12 +0900

구글의 검색페이지에서 에러가 났네요...

회사 컴터가 전부 이 상태인걸 보니 바이러스가 돌아다니고 있는건가...

일단 저 패스워드를 넣으면 정상적으로 동작은 하지만...

뭔가 찜찜...

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

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

구글의 센스

stophobia — Tue, 15 Jan 2008 12:34:28 +0900

오늘 구글독스를 쓰던 중 에러가 발생했습니다.

그런데, 에러메세지가 보통이 아니군요.

친절한 듯 하면서도, 그 센스에서 약간 화가 날려고도 하는, 매우 야릇한 기분...

확대해서 봐 주세요.

해석을 하자면...

나쁜 소식은, 구글독스가 에러를 만났다는 것입니다.
좋은 소식은, 당신이 우리가 에러를 발견할 수 있도록 도와주셨다는 사실입니다.
당신이 초래한 불편함에 우리는 사죄드립니다.

죄송합니다. 그리고, 도와주셔서 감사합니다!

음...
결국 내가 잘못했다는건가효?

항상 딱딱한 사죄 인사에 길들여져 있어서일까, 이런 재치있는 사죄가 익숙하지 않긴 합니다.

웬지 친근하게도 느껴지구요.

하지만... 이왕 기분좋게 만들 계획이셨다면, 60년대 유머는 좀 지양해 주셨으면...

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

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

웹디자인의 기본

stophobia — Mon, 7 Jan 2008 16:24:00 +0900

guN6es2WcfAaB8WB8HhPWt5xVeq

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

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

stophobiaとは？

stophobia — Tue, 18 Dec 2007 15:49:57 +0900

stophobiaという言葉は、停止恐怖症という意味の造語です。

多忙な現代社会で、周辺環境の影響で真実な安息を見つかることができず、「人間本来の価値」と表裏する物質重心の文化に尊厳な個人としてではなく単純な部品として自分のことを認めてしまう、そして「社会共通の価値」以外には何も認めない状況を表した単語であります。

[ 停止恐怖症 ]

恐怖症の一種類で、止まっていることを嫌がり、不安を感じる。
こういう不安が恐怖の状態まで致す状態が停止恐怖症である。

この病勢以外の他の病勢はないが、一般的に社会生活で大きな支障はないため恐怖症というより癖や性格だと思われます。

ところが、深刻な場合、全力を尽くして余力が残してないことにもかかわらず先進を止まらない危険もある。

僕は何の人なんでしょうか。何をするためこの世に生まれてきたのでしょうか。

こういうことを自問する時間も持たず、今、ここになぜ立ち止まっているのでしょうか。

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

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

stophobia란?

stophobia — Thu, 13 Dec 2007 14:36:54 +0900

stophobia라는 말은 정지공포증이라는 뜻의 조어입니다.

바쁜 현대 사회에서, 주변 환경의 영향으로 진정한 안식을 찾지 못하고, "인간 본연의 가치"와 상반하는 물질 위주의 문화에 존엄한 개인으로서가 아닌 단순한 부품으로 스스로 폄하하게 된, 그래서 "사회 공통의 가치" 이외에는 아무것도 인정하지 않는 상황을 풍자한 단어입니다.

[ 정지공포증 ]

공포증의 한 형태로, 멈추어 있는 것을 꺼리고 두려움을 느낀다.
이러한 불안이 공포에까지 이르는 상태가 정지공포증이다.

이 증세 외에 다른 증세는 없는데, 일반적으로 사회생활에서 큰 지장은 없어 공포증이라기 보다는 버릇이나 성격으로 여겨진다.

하지만 심각한 경우에는 전력을 쏟아부어 여력이 남아있지 않음에도 불구하고 전진을 멈추지 않을 위험도 있다.

나는 어떤 사람일까요? 무엇을 하기 위해 이 세상에 태어났을까요?

이런 것들을 자문할 시간도 없이, 지금 이자리에 왜 서있는 걸까요?

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

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

근본부터 고치는 IE의 CSS버그

stophobia — Tue, 30 Oct 2007 11:00:58 +0900

IE7을 포함하는 IE계통 브라우저에서는 확대, 축소시 레이아웃이 겹쳐 버리거나 float가 초과한다던지 하는 버그가 많습니다. 이것은, IE의 hasLayout이 원인이 되고 있는 것으로 알려져 있습니다.

이 문제에 대해서도 꽤 오래전 IE6의 CSS 버그를 위한 Ultra CSS Hack 라는 이름으로 세네세네님께서 친절하게 설명해 주신 문제인데요, 너무 단편적인 감이 없지 않아서, 좀 더 자세히 살펴보았습니다.

링크한 기사는 꽤 오래전에 읽은 기사이지만, 그 동안 저 스스로 연구좀 하느라고 포스팅은 좀 늦게 되어버렸습니다.

실제 마이크로소프트의 Internet Explorer Developer Center에도 관련 이슈가 있습니다. 이슈라기보다는 "해결책"이지만,

이 포스팅의 제목은 "CSS버그의 수정"이지만, 핵과는 전혀 상관 없습니다. 기본 설정값을 파악해서 근본을 약간 손대는 방법으로 CSS버그가 애초에 일어날 수 없는 환경을 만들어보고자 하는 의도입니다.

1. hasLayout 이란?

hasLayout 이란, 오브젝트가 레이아웃을 가지고 있는지를 나타내는 것입니다. hasLayout 의 값은 Read-only이기 때문에 읽기만 가능하며 false와 true로 구분합니다. false는 오브젝트가 레이아웃을 가지고 있지 않은 경우, true는 오브젝트가 레이아웃을 가진 경우입니다.

IE계통 CSS 버그중 다수를 차지하는 float, width, height 와 관련된 버그가 이 haslayout과 관련이 있습니다. 이러한 속성을 true값으로 지정해 둔다면 관련된 버그가 어느 정도는 해소될 듯 합니다.

2. hasLayout 과 관련된 버그의 예

배경색이 지정된 상위 요소 안에서 float된 하위 요소가 있으면, 상위 요소안에서 하위요소의 위에 있는 문자가 사라집니다.

float에 뒤따라오는 margin값이 무시됩니다.

width가 지정된 박스의 안에 float된 하위요소가 있으면 자동적으로 높이가 성장합니다.

(근거가 되는 에러의 예시는 11월 중순 이후 원고가 정리되는대로 자세하게 공개하겠습니다. 이것만으로도 카테고리를 하나 만들어야하지 않나 할 정도로 양이 방대하군요...)

3. 각 속성값과 true값

만약 IE계통의 브라우저 레이아웃 설정이 파이어폭스처럼 수정 가능하도록 공개가 된 상태라면 애초에 덮어쓰기용 파일이 나오지 않았을까하고 생각도 해 봅니다만...

속성	값(true값)
display	inline-block
height	any value
float	left or right
position	absolute
width	any value
writing-mode	tb-rl
zoom	any value

그럼 실제, 이 블로그에서 hasLayout을 가진 요소는 무엇이 있는지 알아볼까요?

4. hasLayout 패블릿

여기를 눌러보세요!

위의 링크를 누르면, 이 블로그에서 hasLayout이 true인 요소는 빨강, false라면 파랑색 보더가 적용됩니다.

5. CSS버그에 효과가 있는 hasLayout 지정법

hasLayout을 변경하는 속성 중에는 float, position처럼 레이아웃을 무시하고 함부로 속성값을 지정할 수 없는 것도 있습니다.

그래서, zoom을 생각해 보았습니다. zoom은 지정한 요소의 확대/축소를 지정하는 것입니다. 대부분의 레이아웃이 100%로 유저에게 보여지는 것을 전제로 제작되고 있기 때문에 이것을 이용해도 문제는 없으리라 생각합니다.

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

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

올바른 웹표준 마크업의 기준

stophobia — Fri, 26 Oct 2007 18:42:29 +0900

웹표준에 무슨 마크업의 기준이 존재하겠습니까.

기준이라는 것이, 사실은 상대적인 규칙입니다. 웹 퍼블리셔 자신이 만들어가는 기준이라고 할 수 있겠죠. 좀 더 규칙적이고 이해하기 쉬운 규칙을 찾느냐 아니냐는 전적으로 웹퍼블리셔에게 달려있겠고요.

제가 제시하고자 하는 기준은 이러한 규칙을 설정하는데 있어서 어느 정도의 틀을 제공하고자 하는 것이구요.

원문의 인용은 맨 뒤에 싣도록 하겠습니다. 제가 봐도 머리가 어지러워서...

웹페이지를 출판하는데 있어서 "구조화"라는 것은 이제까지 웹퍼블리셔들이 의식하지 못했던, 그러나 분명히 존재했던 문제들을 수면위로 끌어올립니다.

바로 "자유"인데요, 이것은 "무슨 코드를 사용할 것인가"와 관련이 있습니다. 자신이 "왜 여기에 이렇게 지정을 했는가"정도만 설명할 수 있다면 특별히 문제가 없는 정도지요.

역으로 "구속"도 있는데요, 이것은 "무슨 DTD를 사용할 것인가", "특수한 경우에 있는 유저들을 위한 CSS를 표현하기 위해서는 어떠한 방식으로 CSS를 지정할 수 있는가" 등과 관련이 있겠지요. 이건 선택의 여지가 별로 없습니다.

예전에도 이러한 고민은 존재했겠습니다만, 어지간한 고민은 대충 해결해 주었던 IE6 덕분에 그리 골치 아프지는 않았던 것 같습니다.

그럼, 어디까지가 자유고, 어디까지가 속박인가... 그에 대한 기준을 알아보고자 하는 것이지요.

사실은 이러한 기준이 IETF의 문서 RFC2119에 기술되어있습니다. 이 문서는 XHTML1.0의 사양서에도 언급된 문서입니다.

구분은 대충 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL 정도가 있는 것 같지만, 제 나름대로 3단계로 나누어 보았습니다. 더 아실 분은 맨 밑의 원문을 참조해 주세요...

필수(MUST) : 문법이 문서형 정의에 어긋나지 않은가?
추천(SHOULD) : 사양서에서 정해놓은 방침을 따르는가?
가능(MAY) : 구조화나 의미의 부여, 목적이나 문맥에 의한 용법에 부합하는가?

필수 : 필수 레벨은 XHTML, XML문서에 명시되고 있는 사항으로, W3C의 밸리데이션에서 페이지의 오류를 체크하는 기준이 되는 것 같습니다. 최저한의 기준, 마지노선이 되겠지요.
혹자는 밸리데이션을 받은 것 만으로 "웹표준"이라는 사람도 있지만, 그러한 정의와는 조금 다릅니다.
테이블 레이아웃도 밸리데이션받는데 아무 문제 없으니까요.

추천 : 여기서부터는 문법 이상의 것을 요구합니다. 예를 들어, "구조와 표현의 분리"라는 것도 여기서부터의 레벨입니다.
필수 레벨과의 최대 차이는, 문맥이나 목적에 따라 올바른 마크업을 사용하고 있는지, 구조에 맞는 태그를 사용하고 있는지를 생각하게 되는 레벨이지요. 프로그램으로는 이러한 타당성을 체크하는 것이 매우 어렵습니다.

가능 : 이 부분은 완벽하게 웹퍼블리셔의 자유에 맡겨진 부분입니다. 그만큼, 초보 웹퍼블리셔와 숙련된 웹퍼블리셔를 구분짓는 부분이기도 하지요.
인용문을 <q>로 마크업할 것인지, <cite>로 마크업할 것인지, 또는 강조 구문을 <em>으로 마크업할 것인지, <strong>으로 마크업할 것인지의 문제입니다. 무엇을 쓰던 상관은 없습니다. 다만, "얼마나 납득가능한 설명을 하느냐"에 달렸다고 해도 과언은 아닐겁니다.

아래는 문서의 원본을 게재해 보았습니다.
해석 여부에 따라 다양한 생각이 나게하는 문서네요...
(조금 정확한 표현을 쓰자면... 애매하다는 뜻입니다. 결국 XHTML사양서를 잘 읽으시오! 정도로 요약이 됩니다.)

Network Working Group S. Bradner
Request for Comments: 2119    Harvard University
BCP: 14 March 1997
Category: Best Current Practice

Key words for use in RFCs to Indicate Requirement Levels

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements. Distribution of this memo is unlimited.

Abstract

   In many standards track documents several words are used to signify
   the requirements in the specification. These words are often
   capitalized. This document defines these words as they should be
   interpreted in IETF documents. Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

   Note that the force of these words is modified by the requirement
   level of the document in which they are used.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
   truly optional. One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly. In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions) For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications. The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification.

8. Acknowledgments

   The definitions of these terms are an amalgam of definitions taken
   from a number of RFCs. In addition, suggestions have been
   incorporated from a number of people including Robert Ullmann, Thomas
   Narten, Neal McBurnett, and Robert Elz.

9. Author's Address

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138

phone - +1 617 495 3864

email - sob@harvard.edu

---

Copyright (C) The Internet Society (March 1997). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

논리적인 ID, CLASS이름을 생각한다

stophobia — Fri, 26 Oct 2007 12:24:59 +0900

앞의 글에서 DIV의 존재에 대해서까지 고찰했습니다만, 문제는 "최대한의 구조화"입니다.

사이트를 구조적으로 만들기 위해서는 의미에 맞는 마크업도 중요하지만, 마크업에 부여하는 ID, CLASS명도 중요하다고 생각합니다.

조금 빗나간 이야기지만, ID명, CLASS명 합쳐보면, 심한 경우는 코드와 비슷할 정도로 많은 바이트를 차지하는 경우도 있습니다.

그런 의미에서 보면, 이런 것도 웹표준을 위해 신경써야하지 않나 생각합니다.

일단 기본적으로 논리구조를 살펴봅시다. 논리구조를 올바로 파악하지 않고 있다면 올바른 ID명, CLASS명을 붙이기도 힘들어지니까요.

1. 종래의 이름 vs 제안

종래의 이름	제안
ID:header CLASS:description information gloval_nav ID:body CLASS:contents hot_topics hot_products sidebar sub_nav banners ID:footer CLASS:credit privacy	ID:site CLASS:description information navigation ID:page CLASS:recent information products related navigation services ID:publication CLASS:credit privacy

2. 보다 구조를 의식한 CLASS이름을 붙이자!

구체적으로, 위에 나타난 예와 같이 CLASS이름을 상층에서 하층으로 늘어놓았을 때, 논리적인 일관성이 유지되도록 합니다. 하나의 기준으로, CLASS이름을 자연문(일반적인 문장)으로 바꿔보고, 부자연스럽지는 않은지 체크해 봅니다.

예를 들어, #header .description 에 들어갈 내용은, 감히 추측해 보건대, "사이트에 관한 설명"이 기술되어 있지 않을까요? 어찌되었던 "헤더에 관한 설명"이 들어가 있지는 않으리라 생각합니다.

이런 생각으로 하나하나 살펴보면

site - description: 사이트 전체에 대한 - 설명문
site - information: 사이트 전체에 대한 - 정보
site - navigation: 사이트 전체에 대한 - 안내
page - navigation: 페이지 고유의 - 안내
page - recent - information: 페이지 고유의 - 최신 - 정보
page - recent - products: 페이지 고유의 - 최신 - 제품
related - services: 관련된 - 서비스

header나 (main)contents, body, footer 등은, Web 페이지를 작성할 때에 많이 사용되는 id, class명입니다만, 보통 "header"의 공간에는 사이트 공통의 메타레벨 콘텐츠가, 또 "body"의 공간에는 그 페이지 고유의 오리지날 컨텐츠가 포함되는 경우가 많다는데에 착안하여, 사이트 공통의 정보와 페이지 고유의 정보를 구별하는 의미로, header 부분을 "site", body(혹은 (main)contents) 부분을 "page"라는 이름으로 해 보았습니다.
만약 "페이지 고유의 최신 정보"라는 문맥이 마음에 들지 않으시면, ourCompany - recent - product(우리 회사의 최신 제품)등으로 하는 방법도 있습니다.

각각의 상황이나 목적에 어울리도록, 적절하게 논리 구조를 추상화한 이름을 붙여 보면 좋을 것같습니다.

3. 논리적으로 동급의 경우에는 의식적으로 같은 class명을 붙인다.

#header .global_nav -> #site .navigation
#body .local_nav -> #page .navigation

CSS에서는 글로벌 네비게이션과 로컬 네비게이션을 구별하고 싶을 때 셀렉터의 기술만으로도 간단하게 처리할 수 있습니다. 이 쪽이 각 네비게이션을 구별하거나 동일화할 때, 어느쪽에서든지 사용할 수 있기 때문에, 더욱 유연성이 있다고 생각할 수 있습니다.

4. 종래의 이름도 상관은 없습니다만...

실제 많은 웹페이지를 출판하시는 웹퍼블리셔들이 구조를 무시한 외관 위주, 또는 습관적으로 마크업을 해 버리는 경우가 많습니다. 심지어는 어느 홈페이지던간에 구별없이 "템플레이트"라는 물건을 만들어 ID와 CLASS를 "생각할 시간을 절약"하는 경우도 있는 것 같습니다.

하지만, 더욱 구조를 생각하는 마크업을 하려 하신다면, 조금 더 생각해 보셔도 그리 시간이 아깝지 않은 문제라고 생각합니다.

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

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

주요 브라우저의 디폴트CSS

stophobia — Thu, 25 Oct 2007 18:45:31 +0900

예전에 HOONEY님의 블로그에서 파이어폭스의 default CSS 에 대한 글을 읽었습니다만,

웹 브라우저마다 각각 default CSS가 존재합니다. cascade한 CSS의 특성상, 제작자가 작성한 CSS도 브라우저의 디폴트 CSS의 영향을 받습니다. 웹 사이트가 브라우저마다 조금씩 다르게(경우에 따라 심각하게) 표현되는 이유가 바로 default CSS 때문입니다.

라는 글을 읽고 흥미를 가지고 있던 중, 여기저기서 정보를 얻어 정리해 보았습니다.

AccessifyForum.com이라는 곳에서는 list of browsers' default CSS 이라는 이슈도 있군요.

locations of default stylesheets
브라우저	운영체제	모드	관련 파일 경로
(W3C CSS 2.1 CR)		HTML4	http://www.w3.org/TR/CSS21/sample.html
파이어폭스	윈도우즈	HTML4	C:\Program Files\Mozilla Firefox\res\html.css
	윈도우즈	Quirks	C:\Program Files\Mozilla Firefox\res\quirks.css
	맥	HTML4	/Applications/Firefox.app/Contents/MacOS/res/html.css
	맥	Quirks	/Applications/Firefox.app/Contents/MacOS/res/quirks.css
IE6	윈도우즈		DLL
IE7	윈도우즈		?
IE5	맥		?
오페라	윈도우즈, 맥		?
사파리	맥	HTML4	/sw/share/apps/khtml/css/html4.css
	맥	Quirks	/sw/share/apps/khtml/css/html4.css
	윈도우즈	HTML4	?
	윈도우즈	Quirks	?

흠... 뭐 별 영양가는 없지만...

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

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