Clearboth

6. 정보 설계 — 웹 사이트 기획

서광철 — Fri, 06 Nov 2009 19:30:40 +0900

6. 정보 설계 — 웹 사이트 기획

이 강좌는 Dev.Opera의 ' 6: Information Architecture - Planning out a web site'을 번역한 문서입니다. 번역과 관련된 안내는 여기에서 확인해 주세요.

역자들 : 예진아빠

소개

전통적으로 웹사이트 설계를 할때는 약간의(또는 많이) 스트레스를 받을 때가 있다. 누구나 웹사이트 설계시 많은 생각들을 이야기 하는데 이런 생각들로 인하여 다른 이들과 대립을 하고는 한다. 이런 일들은 당신의 최종 목표인 사람들이 유용하게 이용할 사이트들을 구축하는 한가지 과정에 포함된다. 당신의 사장의 말이나, 권위있는 소프트웨어 엔지니어의 말 또는 당신의 개인적인 취향조차도 그리 큰 문제가 아니다; 결국에는 이 모든 것들은 당신이 유별난 사람들(*문맥상 일반 여러 사용 유저를 말함.)을 위한 웹사이트를 구축할 때 그들의 의견은 단지 여러 문제중에 한가지일 뿐이다.

이 문서에는 일반적으로 기획 초기에 통상적으로 말하는 정보설계 또는 IA 에 대해 살펴볼 것이다. 이 정보설계에서는 당신이 생각하는 핵심 이용자(메인타겟 또는 코어 타겟)에게 그들이 웹사이트 내에서 어떤 정보와 서비스를 필요로 하고 그리고 그들에거 어떤식으로 조직화하여 그들에게 제공을 할것인가를 포함하고 있다. 우리는 사이트에 필요에 의하여 구체화된 정보 전체를 어떻게 분해하고 조각낼 것인가를 생각하고 그리고 이렇게 나누어진 정보를 서로 연관 관계를 갖게하여 할 것인가를 살펴 볼 것이다. 이번 장의 내용은 다음과 같다.

사이트 구축시 면밀한 계획이 필요하다.
- “The Dung Beatles:쇠똥구리 밴드”를 소개합니다.
- 이제 뭘하지? 사이트맵 그리기
- 페이지에 이름을 붙이자.
- 추가 내용
요약
연습 문제

사이트 구축시 면밀한 계획이 필요하다.

당신은 문득 생각한 이 기괴한 프로젝트에 사전 준비 없이 바로 뛰어 들것이다 그러나 지금까지 이런 것들이 가끔 일어나는 예외가 아닌 일반적으로 여겨 졌다.우리는 가상의 음악밴드를 살펴 볼 것이며 이 밴드명을 “The Dung Beatles:쇠똥구리 밴드”라 부를 것이다. 그리고 그들의 초기 단계인 웹사이트 계획(기획)을 도울 것이다.우리는 그 밴드들과, 그들의 목표를 확인하며 그리고 그들이 자신들의 웹사이트에서 무엇을 보여 주고 보여질지를 이야기 할 것이다.그럼 이제부터 우리는 그 밴드의 정보를 구성하는 일을 시작 할 것이다.

“The Dung Beatles:쇠똥구리 밴드”를 소개합니다.

“The Dung Beatles:쇠똥구리 밴드”(이하 TDB) 문제점을 가지고 있다. 그들은 Moose Jaw, Saskatchewan(*캐나다 서부에 지역) 지역에서 인기있는 비틀즈 모방 밴드 이지만 그러나, 그들은 다가오는 여름 북아메리카 투어를 위해 그들의 밴드 인지도를 높일(프로필 인상 시킬) 필요가 있다. 그들은 캐나다와 미국 전역 개최 예정인 투어 스케줄이 있지만, 불행이도 그들은 현재의 지역 외에는 거의 알려지지 않았다. 몃가지 기술을 이용 한다면, 그들은 많은 비용을 쓰지 않고 수많은 비틀즈 팬들에게 그들을 알릴 수 있다.

그들은 운이 좋다, 우리는 이런 것을 알고 있으며 그것을 월드와이드웹이라 부른다. 이것이 그들이 찾던 해답이며, 그들은 망설임 없이 웹사이트를 구축하기로 결정 하였다. TDB밴드는 그들의 투어 일정을 홍보하는 장소가 필요 하며, 다른 도시에 팬층 확보 그리고 밴드 이미지를 제고할 필요가 있다. 당신은 그들과 그들의 아이디어를 생각(공유)하는 일을 시작하며, 그리고 차트(도표)를 통해 그들의 웹사이트 계획을 확인 할 수 있다.

당신은 신규 고객과 회의 일정을 통해 그들이 구체적으로 원하는 것이 무엇인지 그리고 납기 및 비용에 대해 충분한 회의와 협의를 통해 결정한다. 당신은 고객의 목표에 대한 회의를 제의하고 그리고, 고객의 원하는 웹사이트 목표를 위한 아이디어를 회의를 통해 도출해야 한다.밴드(TDB)가 온라인에서 돋보이는 존재로 달성하기를 희망 합니까?

TDB 는 다가오는 그들의 투어와 그리고 어떻게 밴드의 모든 공연 스케줄이 끝나면 비틀즈 팬들에게 자신들의 밴드의 모습이 어떤식으로 입에 오르내릴 것인가?에 대해 이야기를 시작 했다. 지금은 2월이며, 그리고 그들의 투어는 5개월동안 이루어질 예정이다.

잠시만, 웹사이트는 자신만의 의견을 교환하거나 자신을 홍보를 위해 만들지 않는다. 당신은 지금까지 대화를 통해 사이트의 주요 목표는 TDB 팬들을 위한 온라인 공간을 제공하는 것이며; 그 공간에서는 TDB에 대한 최신뉴스, 순회공연 날짜 및 장소에 대해 정보를 취할 수 있다. 라는 것을 알수 있다. 팬들의 입에서(입소문) 그리고 몇몇 다른 광고를 통해, 새로운 사람들이 사이트를 방문하여 사이트 어디에선가 샘플 음악을 다운로드 하거나 밴드의 사진(전체 의상 사진)을 확인 할 수 있다. 그리고 언제/어디서나 그들의 생생한 정보를 확인 할 수 있다.

Raul McCoffee:밴드의 리더 는 CD 및 밴드 판촉상품 판매를 통하여 투어를 위한 약간의 여유돈을 모을 수 있다고 이야기 하였다. 당신은 밴드를 중심으로 정보를 추출 하며,밴드 웹사이트를 방문할때 사람들이 무엇을 원하는지 간략한 스케치를 통해 도출 한다. 그 생각(아이디어) 브레인스토밍하는건 정말 힘든 일이다;그 생각(아이디어) 브레인스토밍하는건 쉽지 않을 일이다.;이 시점에서 사이트는 다음 과 같이 큰 틀을 그릴 수 있다.

사이트를 방문하는 사람들은 크게 두가지로 그룹으로 나누어진다. 첫번째 그룹은 TDB에 대해 이미 알고 있고 그들을 좋아하는 그룹(현재의 팬)이며, 나머지는 전혀 TDB에 대해 전혀 알지 못하는 그룹이다. 당신은 두개의 그룹을 다른 방법을 통해 만족을 시켜야 한다;잠재적인 팬들(TDB를 전혀 알지 못하는 그룹)은 세일즈 포인트(:밴드를 알게 하는 컨텐츠) 가 필요하며, 이에 반해 현재의 팬들은 밴드에게 보다 더 중독될 수 있는 정보(:밴드에게 보다 중독될 수 있는 컨텐츠) 를 원한다. 각각의 사용자 그룹별 그들은 어떤 종류의 정보를 찾고 있을까? 그림 1. 웹사이트 정보의 비율(중요도)을 나타냅니다.—이 스케치는 이 시점에서 확인 나타낼수 있는 전형 적인 스케지 이며, 앞으로 만들어 갈 웹사이트의 큰 모습을 보여 줍니다. 이 순간부터, 당신은 웹사이트에 어떤 정보의 페이지가 필요 하고, 그리고 어떻게 페이지들은 연결 할지 알 수 있다.

그림1: 당신의 사이트 방문자들이 원하는 것. 당신은 예산에 결정하고 한 달간 이 웹 사이트를 제작에 동의합니다. 밴드에게 며칠 후 다시 만날 것을 약속 하며, 그 때는 앞으로 사이트를 어떻게 어떤 방향으로 할것인 지에 대한 설명을 할 것이다.

Now what? Drawing a site map

많은 사람들이 이 단계에 이르면 사이트 맵을 작성을 할것이다.—이것은 흡사 조직 차트 같이 보인다. 이것은 대게 기초적인 그래픽을 통해 사이트의 각 페이지의 이름을 보여 주고, 어떻게 그것들이 전체적으로 연결된 구조를 보여준다. 나는 개인적으로 이 단계에서 좀 더 상세하게 각각의 페이지의 목적과 간략한 내용에 대해 내용을 추가 한다. 예를 들면, 어떤 페이지의 이름이 “홈”이라고 하면, 하지만 “홈” 이란 페이지는 무엇인지? 혹시 “우리 웹사이트 방문을 환영합니다.” 메시진 출력하는 건가요? (윽) 또는 역동적인 이미지가 포함된 새로운 소식 과 멋진 이미지 인가요? 페이지 위의 스케치를 통해 어떤것을 추가 하고, 각 페이지에 포함 시킬 지를 생각하는데는 몃 분 걸리지 않는다. 다음 섹션으로 가기 전에 우선 자신의 사이트 맵을 그려야 한다.

자! 이제 기본적인 것을 시작 하면 : 앞서 언급한 차트를 다시 생각해 본다. 그림2.는 그 사이트 차를 다시 생각하고 그리고 내가 어떤 시도(생각)을 보여 줍니다.

그림2: 첫번째 사이트 구조도 변경. 이미지 설명[:이 이미지는 웹사이트를 구조화하는 최초의 시도를 보여 주는 예를 든 문서이다.구성 페이지들이 가운데 “홈”을 중심으로 거미줄 처럼 연결되어 있다.이 페이지들의 링크는 가운데를 중심으로 “Store”, “Biographies”, “Fan Discussion”, “Tour dates and locations, “Pictures”, “Discography” and “Contact”. 로 연결되어 있다(*1depth의 내용을 보여 주고 있다.) . The “Discography page has two further sub-pages spidering off it, “Lyrics” and “Sample tracks”. Discography 메뉴는 2개의 “Lyrics” and “Sample tracks” 가 추가로 연결 되어 있다. ] 정확히 말하면 일반적으로 모든 페이지를 나열해야 하지만 지금은 기본적인 큰 틀로만 구성되어 그룹핑되어 있다. 이 시점에서 나는 많은 생각을 통해 많은 변화를 가져 온다. 큰그룹(1DEPTH) 에 정보를 보내는 것을 한번 더 했다. —그림 3 무엇을 한지 보여 준다:

나는 사이트 구조를 좀 수정 하였습니다. “Band News” 페이지를 추가 하여 밴드와 팬이 공유 할수 있는 장소를 묶어서 구성 하였다. 여름투어가 종료된 후에도. “Tour dates and locations”페이지는 더 이상 그룹의 이야기를 올리는데 적당하지 않다. 여기에 블로그 형식을 취하여 팬들과 다양한 기사 및 콘텐츠를 공유하게 할 것 입니다. 그리고 이런 것을 통해 TDB 의 온라인 커뮤니티 형성에 도움이 됩니다. 또한 그들이 원하는 정보를 페이지를 나누어서 분류를 하여도”brand News”페이지의 “News” 라는 단어에서 느껴지는 심플하고 보다 일반적인 단어를 통해 사람들에게 쉽고 빠르게 기억될것입니다. “About The Dung Beatles”라는 신규 페이지 에서 그룹이 함께 멤버들의 신상 정보 및 자신들의 사진으로 구성한다. 이 신규 페이지를 통해 우리는 각 밴드 구성원의 신상정보를 바로 찾아 볼수 있는 곳을 제공 합니다. 이전부터 일반적으로 “about”는 네이밍은 많은 웹사이트에서 유사한 성격의 페이지에 이름이 붙여 졌습니다. 사이트 방문자가 회사, 제품, 서비스 또는 개인에 대한 자세한 정보를 찾을 때는 일반적으로 “about” 단어가 포함된 링크를 찾습니다.

마지막으로 “Discography”는 전문 용어 입니다. “The Music”이란 용어가 보다 많은 사람들이 해당 페이지의 내용을 쉽게 이해 할 수 있는 네이밍입니다. 또한 이페이지도 자세한 내용을 담은 페이지가 열립니다.:당신이 아이디어를 얻은 영감을 얻은 소스, 특정노래의 역사…등. 우리는 준비는 다 된거 같습니다. 이제 페이지 이름(네이밍)에 대해 약간의 이야기를 했습니다, 이제 우리는 좀 더 구체적인 내용을 이야기 할 것입니다.

Naming your pages

페이지 이름은 하나의 웹사이트를 디자인(구축) 하는 과정 중에 만들어야 하는 가장 중요한 결정이 될 수 있습니다. 뿐만 아니라 이것을 통해 당신의 사이트 방문자들이 당신의 웹사이트에서 자신의 길을 찾을 수 있는 것도 중요 합니다: 또 다른 것은 이것이 검색엔진이 당신의 사이트를 쉽게 찾을 수 있게 이용된다.(여러 가지 검색 엔진 최적화 과정(방법)에 언급되어 있다.) 일반적으로 검색엔진은 “중요한 점[how important]”을 결정할때는 웹페이지의 포함된 텍스트, 해당 페이지의 주소:URL, 그리고 링크가 연결된 텍스트를 통해 참고한다. 당신의 페이지에 센스있는 이름과 주소를 포기 하고 대신 재치 있는 설명을 사용 하면 당신의 사이트로의 연결을 권장합니다. 여기에 예제가 있습니다. 당신이 자동차 회사 라고 하고 “The Speedster”라 불리는 모델이 있다. 당신의 자동차를 홍보하는 웹사이트와 그리고 자동차 기능설명을 나열 되어 페이지가 있다. 그럼 당신은 이페이지를 어떻게 불를 것인가 “기능:Features”, “사용가능한 기능:Available Features”, “Speedster의 기능:Features of the Speedster”, or “종과 경적:Bells and Whistles”? 나는 “Speedster의 기능:Features of the Speedster”로 이름을 붙이는 것을 제안 한다. 내가 제안한 것은 페이지의 특징을 포함하며, 검색 엔진의 검색 결과 페이지에 가장 먼저 눈에 띄는 곳에 노출될 가능성이 있습니다.(이것은 검색엔진의 색인 생성을 위해 좋다.)그리고 생성되는 URL도 홈페이지에 맞게 할 수 있습니다. (예를 들면 “www.autocompany.com/speedster/speedster-features/”).

Adding some details

이 시점에서 모든 것을 알아낼 필요가없습니다,하지만 당신은 적어도 기본적으로 각 페이지에 대해 무엇을 해야 한다는 간단한 설명(힌트)을 제공해야 합니다. 그 다음 당신은 사이트 구조, 페이지 넘버 그리고 각 페이지의 설명을 제공 하며,내가 그림4처럼 홈페이지에 해준 것(이 기회에 다른 페이지에 문서 끝에 있는 질문을 하는 연습을 합니다.)

This is about as involved as you want to get at this point. You don’t need to describe page functionality, the technology you’ll use to build it, or the design/layout in great detail. Just describe what you have in mind in general terms. Your goal here is to communicate what you’re thinking to your client and to force you to think things through.

It’s not uncommon at this stage to come to the realisation that you have too many pages, and you’ll never be able to find content for them. You can go crazy in creating a hierarchy of pages. For example, if the band members just wanted to publish one paragraph about themselves, it wouldn’t be necessary to create separate biography pages for each member. They could all be combined into a single page.

Summary

This article has looked at the web site as a whole, and how you should think about structuring it. In the next article, you’re going to get taken down to the page level, and look at what goes into making a great web site: what features to include and where to include them. Articles 8, 9 and 10 then look at the visual design of a page. So this is being done in 3 logical steps (check it with the client at each stage to make sure they are happy with it):

First you decide on the content of a web site, and decide how to structure that content into pages.
Next you decide on the functionality that will actually be used on your web site.
The last thing you do before you actually start going ahead and coding your web site is work out the visual design of it—the page layouts, and the colour scheme, etc.

Exercise questions

Look back at Figure 1 and try to develop a similar brainstorm for a web site about a car (pick any current or imaginary car).
- What will visitors to the web site want to know?
- Is there anything at existing car web sites that you see as essential? Frivolous?
Take your brainstorm and try to organise the information. What page groupings make sense?
Another activity that is sometimes useful when planning out a web site is to check out the competition. Do a search for band web sites (bonus points for tribute bands), and take a look at what they’re offering. Did we miss anything?
Take a look at Figure 4 and try to develop similar figures for the other pages I’ve identified on the web site.

저자 소개

Jonathan Lane은 산업 인터렉티브의 대통령이다. Mayne Island에 있는 웹 개발/웹 어플리케이션 개발 회사에 있다. 그는 수년동안 Lethbridge 대학의 커리큘럼 재개발 센터에서 웹 프로젝트 코디네이터 작업을 하면서 일을 시작했다.

그는 Flyingtrol 블로그를 가지고 있고, 현재 Basecamp 프로젝트 메니지먼트 어플리케이션을 위한 이메일 인터페이스 개발을 하고 있다.

History of Web Standards

추지호 — Fri, 06 Nov 2009 17:35:36 +0900

History of Web Standards

이 문서는 W3C의 표준 권고안과 웹브라우저의 발전 역사를 요약한 것입니다.

1969

First Internet - Leonard Kleinrock에 의한 최초의 데이터¹⁾ 전송.

1989

First HTTP
First HTML
First Web Browser / Editor - WWW_NexTSTEP

1993

^4월 NCSA Mosaic Browser 1.0 Release
^12월 NCSA Mosaic Browser 2.0 Release

1994

^10월 Establish W3C
^12월 Netscape Navigator 1.0 Release
^10월 Spyglass Mosaic Release (IE 전신)

1995

^11월 HTML 2.0 RFC 1866
^10월 Netscape Navigator 2.0 Release - JavaScript Support
^8월 Internet Explorer 1.0 Release (Plus! for Windows 95 Release)
^11월 Internet Explorer 2.0 Release (Windows 95 OSR1 Release) - JavaScript, SSL, VRML Support
^4월 Opera 1.0 Release

1996

^4월 Opera 2.0 Release
^4월 Internet Explorer 2.0 for Macintosh Release
^8월 Internet Explorer 3.0 Release (Windows 95 OSR2 Release) - HTML 3.2, CSS 1(Not Standards), JScript Support, ActiveX Support
^10월 Netscape Navigator 3.0 Release - VRML
^11월 Internet Explorer 3.0 for Macintosh Release
^12월 CSS 1.0 Recommendation

1997

^1월 HTML 2.x RFC 2070
^3월 HTML 3.2 Recommendation
^6월 Netscape Communicator 4.0 Release - CSS 1 Support (Not Standard)
^6월 ECMA-262(ECMA Script) 1st Edition
^9월 Internet Explorer 4.0 Release (Windows 95 OSR2.5 / 98 Release) - Trident Engine, DHTML Support
^12월 HTML 4.0 Recommendation
^12월 Opera 3.0 Release - HTML 2.0 Full Compliance

1998

^1월 Internet Explorer 4.0 for Macintosh Release
^2월 XML 1.0 Recommendation
^2월 Establish Mozilla Project
^3월 Netscape Communicator 5.0 Scrapped - NGLayout Engine (Geoko)
^3월 Internet Explorer 4.0 for Unix(Solaris, HP-UX) Release
^5월 CSS 2 Recommendation
^6월 ECMA-262 2nd Edition(ISO/IEC 16262 국제 표준과 완전히 동일한 규격 적용)
^7월 Establish Web Standards Projects - Jeffery Zeldman, ACID 1,2,3
- ACID 1 - Test Compliance with HTML 4 and CSS 1
- ACID II - Test Compliance with CSS 1 and CSS 2
- ACID III - Test Compliance with CSS 2.1 DOM and ECMA Script
^11월 KHTMLW(KDE HTML Widget) Release (Safari의 전신) - HTML 3.2, Frames Support
^12월 Opera 3.5 Release - CSS 1 Support

1999

^1월 CSS 1 Revised Edition Recommendation
^3월 Mozilla Milestone 3 Release
^3월 Internet Explorer 5.0 Release (Windows 2000 Release) - CSS 1, XHR, XML, HTA Support
- Windows 98 SE (Using the Trident II)
- Windows ME (Using the Trident III)
^5월 WCAG 1.0 Recommendation
^12월 HTML 4.01 Recommendation
- Strict - HTML 2.x
- Transitional - HTML 3.2
- Frameset - Using Frame
^12월 ECMA-262 3rd Edition(강력한 정규 표현식, 향상된 문자열 처리, 새로운 제어문 , try/catch 예외 처리, 엄격한 오류 정의, 수치형 출력의 포매팅 등)

2000

^1월 XHTML 1.0 Recommendation
^12월 XHTML Basic Recommendation
^10월 XML 1.0 Second Edition Recommendation
^12월 Mozilla 0.6 Release
^11월 Netscape 6.0 Release - Standard Support
^6월 Opera 4.0 Release - DHTML, CSS 1/2, XML, HTML 4.0, ECMAScript, JavaScript 1.3 Support
^12월 Opera 5.0 Release - Free Download
^7월 Internet Explorer 5.5 Release (Windows Me Release) - CSS, HTML Standards Support
^3월 Internet Explorer 5.0 Macintosh Edition Release - Using Tasman Engine (Compliant with W3C Standards such as HTML 4.0, CSS 1, DOM 1, ECMA Script)

2001

^5월 XHTML 1.1 Recommendation
^12월 Opera 6.0 Release - PNG Alpha Transparency Support
^8월 Internet Explorer 6.0 Release (Windows XP Release) - DOM 1, Quirks Mode Support

2002

^8월 XHTML 1.0 Second Edition Recommendation
^6월 Mozilla 1.0 Release
^9월 Phoenix 0.1 Release (Firefox의 전신)
^8월 Netscape 7.0 Release - Base on Mozilla 1.0
^9월 Internet Explorer 6.0 SP1 Release

2003

^7월 Independent Mozilla Foundation
^5월 Firebird 0.6 Release (Firefox의 전신)
^1월 Opera 7.0 Release - DOM 2 Support
^6월 Internet Explorer for Macintosh 5.2.3 Release
^6월 Safari 1.0 Release
^10월 with OSX 10.3 Release

2004

^2월 XML 1.0 Third Edition Recommendation
^2월 XML 1.1 Recommendation
^2월 Firefox 0.8 Release
^11월 Firefox 1.0 Release
^8월 Internet Explorer 6.0 SP2 Release

2005

^12월 인터넷 웹 콘텐츠 접근성 지침 발표 (한국)
^8월 Establish Mozilla Corporation
^11월 Firefox 1.5 Release - SVG, Canvas, CSS 2/3, JavaScript 1.5 Support
^4월 Opera 8.0 Release - SVG, XMLHttpRequest Support
^5월 Netscape Browser 8.0 Release - Two Layout Engine (Trident / Gecko)
^4월 Safari 2.0 Release - OS X 10.4 (Tiger)
^10월 Safari 2.0.2 Release - ACID 2 Passed

2006

^10월 Firefox 2.0 Release - JavaScript 1.7 Support
^10월 Internet Explorer 7.0 Release - Improvements to CSS, DOM, HTML, PNG Alpha Support
^6월 Opera 9.0 Release - ACID2 Passed, Canvas Support

2007

^6월 Safari 3.0 for Mac / Windows Release
^10월 Netscape Navigator 9.0 Release

2008

^12월 WCAG 2.0 Recommendation
^6월 Firefox 3.0 Release - ACID 2 Passed, HTML 5, APNG Support
^2월20 Netscape Navigator 9.0.0.6 Final Release - Gecko Engine
^4월 Internet Explorer 6.0 SP3 Release
^12월 Chrome 1.0 Release - ACID 2 Passed

2009

^2월 WAI-ARIA 1.0 Working Draft
^3월 웹 접근성 향상을 위한 국가 표준 기술 가이드라인 발표 (한국)
^3월 Internet Explorer 8.0 Release - ACID 2 Passed, CSS 2 Full Support
^6월 Firefox 3.5 Release - HTML 5 Support
^6월 Safari 4.0 Release - ACID 3 Passed
^7월 Tmax Scoutor Alpha Release
^8월 HTML 5 Working Draft
^9월 CSS 2.1 Candidate Recommendation
^9월 ECMA-262 5th Edition
^9월 Opera 10.0 Release - ACID 3 Passed, Web Font Support
^9월 Chrome 3.0 Release

¹⁾ Logon 중 'LO' 전송 성공

CSS Nite in Seoul Vol.1

추지호 — Mon, 19 Oct 2009 10:28:33 +0900

CSS Nite in Seoul Vol.1

CSS Nite in Seoul Vol.1 은 일본 최대 규모의 웹표준 컨퍼런스인 CSS Nite를 한국에서 개최하는 첫 자리입니다. CSS Nite는 웹 제작 전반에 관한 주제를 가지고 각 분야의 전문 강사를 초청하여 발표와 토론을 갖는 일본에서 가장 큰 컨퍼런스입니다. 지금까지 총 113 개의 컨퍼런스를 통해 총 18,191분들이 참여(일본)해 주셨습니다.

CSS Nite in Seoul Vol.1은 CSS Nite in Seoul 실행위원회와 (유)리그래피가 함께 주최하고, 한국 마이크로소프트와 태그앤브레이스가 협찬하고 있습니다. 그리고 웹표준 커뮤니티인 하드코딩하는 사람들, CSS Design Korea, Clearboth가 후원을 하고 있습니다.

Clearboth가 이번 행사를 후원하면서 3장의 초대권을 받았습니다. 이 페이지 하단에 위치한 의견란에 패널토의 시간을 통해서 다루어 주었으면 하는 주제 또는 질문을 남겨주신 분 가운데 세 분께 초대권을 드리도록 하겠습니다. 많은 참여 부탁드리겠습니다. 기간은 ~~11월 15일~~ 10월 21일(사전등록자가 이미 백여분 가까이 되어서 무료 초대 이벤트 기간을 줄이게 되었습니다.)까지로 하겠습니다.

행사내용과 프로그램

행사내용

구분	내용
일정	2009년 11월 21일 12:30-18:00
장소	삼성동 포스코센터 서관 5층 한국MS
주최	CSS Nite in Seoul 실행위원회, 유한회사 리그래피
협찬	한국 마이크로소프트, 태그앤브레이스
후원	하드코딩하는 사람들, CSS Design Korea, Clearboth
모집인원	150명 (초대 인원 포함)
등록비용	사전 등록：25,000원 / 현장 등록：30,000원
발표자	타가노 마사히로 (주식회사 스위치 대표 이사) 마시코 다카히로 (주식회사 사이바가덴 대표 이사) 박 태준 (주식회사 NHN 웹표준1팀팀장)

프로그램

시간	발표자	내용
12:30 [30min]		입장개시
13:00 [15min]	이 유미	오픈닝,행사 소개
13:15 [45min]	박 태준	웹표준을 기반으로 한 HTML개발 프로세스
14:00 [60min]	타가노 마사히로	일본의 웹표준현실과 제작 프로세스
15:00 [10min]	한국 마이크로소프트	라이트닝 토크1
15:10 [15min]		휴식
15:25 [60min]	마시코 다카히로	미래의 웹표준으로서의 HTML5과CSS3
16:25 [10min]	태그앤브레이스	라이트닝 토크2
16:35 [15min]		휴식
16:50 [60min]	박태준, 박중석, 타가노 마사히로, 마시코 다카히로, 미츠코시 유스케	패널토의와 질의응답
17:50 [10min]		경품 추첨
18:30 [60min]		교류파티(무료)

아래 의견란에 패널토의 시간을 통해서 다루었으면 하는 주제 또는 질문을 남겨주시는 분 세 분을 추첨하여 초대권을 드리겠습니다. 때문에 의견을 남겨 주실 때 반드시 이메일 주소를 등록해 주세요.

Clearboth

추지호 — Fri, 16 Oct 2009 09:41:25 +0900

Clearboth

클리어보스는?(What's Clearboth)

클리어보스는 2007년 12월 11일 시작된 '웹표준을 알리는 사람들의 모임(Web Standards Evangelist Forum)'입니다.

주요 활동(Activity)

2009. 11. 21 - CSS Nite in Seoul Vol.1 공동운영 및 후원, 자원봉사 지원
2009. 09. 19 - 두번째 웹 퍼블리셔 오리엔테이션
2009. 02. 21 - 첫번째 웹 퍼블리셔 오리엔테이션
2009. 02. 07 - 세번째 웹 표준의 날 자원봉사 지원
2008. 10. 18 - 오페라 웹표준 커리큘럼 번역 프로젝트 시작
2008. 07. 05 - 스터디 연합 세미나(신림 소모임) 진행

발자취(History)

09. 07. 31 - 웹퍼블리셔 오리엔테이션 OT 1기 오프모임(홍대)
09. 07. 17 - 2009 워크샵(가평, ~18)
09. 06. 27 - 클리어보스 6월 모임(홍대)
09. 05. 08 - 오페라 웹표준 커리큘럼 번역 위키 오페라 웹사이트 공식 등록
09. 04. 10 - 클리어보스 4월 모임(강남)
09. 03. 13 - 클리어보스 3월 모임(강남)
09. 03. 04 - 클리어보스 팀블로그 오픈
09. 02. 21 - 첫번째 웹 퍼블리셔 오리엔테이션
09. 02. 12 - 클리어보스 2월 모임(강남)
09. 02. 07 - 세번째 웹표준의 날 공동 주최(CSS Design Korea 주최, 한국정보문화진흥원 후원)
09. 01. 05 - 클리어보스 신년 모임(강남)
08. 11. 20 - 자바스크립트 스터디 2차 모임
08. 11. 06/08 - 자바스크립트 스터디 1차 모임
08. 10. 30 _ 자바스크립트 스터디 사전모임 (강남)
08. 10. 18 _ 클리어보스 사이트 개편 (영문 문서 번역 스터디 / 자바스크립트 스터디 분리)
08. 10. 09 _ 강남모임 20차 모임(회식 / 강남스터디 모임 종료)
08. 09. 11 _ 강남모임 19차 모임(16차 스터디 / 3시즌 시작)
08. 08. 28 _ 강남모임 18차 모임(15차 스터디 / 2시즌 끝)
08. 07. 30 _ 강남모임 17차 모임(14차 스터디 / 정글 웹표준 강사 차영신님 참관)
08. 07. 17 _ 강남모임 16차 모임(13차 스터디)
08. 07. 05 _ 강남모임 15차 모임(1차 연합(신림)스터디 / 나나, 별군, 송창희, 바람, 모모, 유주영님 참관)
08. 07. 04 _ 강남모임 14차 모임(회식 / CDK 인터뷰)
08. 06. 19 _ 강남모임 13차 모임(12차 스터디 / 엽님 가입 / 웹표준경진대회 수상)
08. 06. 05 _ 강남모임 12차 모임(11차 스터디 / 아트강님 탈퇴)
08. 05. 22 _ 강남모임 11차 모임(10차 스터디 / 성민장군, 엽님 참관)
08. 05. 10 _ 강남모임 10차 모임(9차 스터디 / 워크샵)
08. 04. 17 _ 강남모임 9차 모임(8차 스터디 / 겨미겨미, 써니님 가입 / 주방장님 송별회)
08. 04. 03 _ 강남모임 8차 모임(7차 스터디 / 2시즌 시작)
08. 03. 12 _ 강남모임 7차 모임(6차 스터디 / CDK 홍윤표님 참관)
08. 02. 28 _ 강남모임 6차 모임(5차 스터디)
08. 02. 13 _ 강남모임 5차 모임(4차 스터디)
08. 01. 24 _ 강남모임 4차 모임(3차 스터디)
08. 01. 10 _ 강남모임 3차 모임(2차 스터디)
07. 12. 20 _ 강남모임 2차 모임(1차 스터디)
07. 12. 11 _ 강남모임 1차 모임(사전모임)

로고

로고 내려받기

가입

클리어보스는 참여형 포럼입니다. 클리어보스가 일구어 나가는 모든 사업에 어떤 식으로든 참여를 해 주시면 그 순간부터 클리어보스의 회원이 되시는 것입니다. 위키 사이트에 회원가입 여부와는 상관이 없습니다. 클리어보스는 '웹 표준을 알리는 사람들의 모임' 즉 Web Standards Evangelist Forum입니다. 웹 표준을 더 많은 사람들에게 알리고자 하는 사람들과 함께 만들어가는 포럼입니다.

연락 및 문의

포럼장 - 봄눈(chubzo@gmail.com)

Clearboth

추지호 — Tue, 13 Oct 2009 14:40:57 +0900

Clearboth

클리어보스는 웹표준을 알리는 사람들의 모임_{WebStandards Evangelist Forum}입니다.
클리어보스 가입은 여기에서 해 주세요.
위키 사용이 처음이라면 위키 문법을 먼저 보세요.

Event

CSS Nite in Seoul Vol.1 안내 및 무료 초대 이벤트

Project

번역된 강좌들(20개)

한글화 작업을 함께 해 주실 분들은 강좌 목록중 번역되지 않은 강좌를 선택해서 진행해 주시면 됩니다.

웹퍼블리셔 오리엔테이션

웹퍼블리셔 오리엔테이션 안내

발자취

첫번째 웹 퍼블리셔 오리엔테이션 _2009.2.21
두번째 웹 퍼블리셔 오리엔테이션 _2009.9.19

Campaign

45. 자바스크립트 객체

추지호 — Tue, 13 Oct 2009 14:39:32 +0900

45. 자바스크립트 객체

이 강좌는 Dev.Opera의 ' 45: Objects in JavaScript'을 번역한 문서입니다. 번역과 관련된 안내는 여기에서 확인해 주세요.

역자들 : 검은태양

소개

이전 글 에서 함수의 컨셉에 대해 소개했다. 함수를 사용함으로서 프로그램들을 논리적인 덩어리들로 쪼개서 당신의 코드를 좀더 잘 조직화하고, 쉽게 재사용할 수 있었다. 이제 당신이 자바스크립트 프로그래밍의 핵심적인 개념들을 거부감 없이 받아들일 수 있게 되었으므로, 객체 에 대해 소개함으로서 활용의 폭을 더욱 넓혀보고자 한다. 객체를 사용함으로서 함수로 정의한 기능성들을 하나로 묶을 수 있고, 또한 그것을 이곳저곳으로 전달하며 또한 참조할 수 있다. 이러한 능력은 당신이 앞으로 작성할 코드에 상당히 실질적인 의미를 갖게 될 것이다 - 비록 지금 이 순간에는 다소 모호하게 들리겠지만 말이다.

눈치채지 못했을수도 있지만, 당신은 이 시리즈를 따라 오면서 암묵적으로 객체들을 사용해 왔다. 이제 이것에 대해 좀 더 명시적인 설명을 함으로서 자바스크립트에서 객체가 어떻게 동작하는지, 그리고 객체를 통해 당신의 프로그램을 좀 더 명확하게 하고 재사용하기 쉽도록 하는 방법을 알려주겠다.

이 글의 구조는 다음과 같다:

다운로드하거나 직접 실행해볼 수 있는 예제가 준비되어 있다. 이것은 삼각형의 면적을 계산하는 코드를 포함하고 있는데, 객체를 사용한 것과 사용하지 않은 것이 있다. 이 코드는 아래에서 설명하는 예제들로 만들어져 있다. 삼각형 객체 예제를 실행해보라.

왜 객체를 사용하는가?

객체에 대해 주의를 기울이는 단 하나 가장 중요한 이유는, 객체를 사용함으로서 당신의 코드에서 데이터와 처리과정을 더 잘 표현할 수 있기 때문이다. 익숙한 예제로서, 당신이 삼각형에 관한 뭔가를 코딩한다고 가정하자. 삼각형은 3개의 변 을 가지고 있다는 것을 알고 있으므로, 특정한 삼각형에 대해 다루려면 당연히 3개의 변수를 만들어야 할 것이다:

// This is a triangle.
var sideA = 3;
var sideB = 4;
var sideC = 5;

자, 삼각형이 준비되었다. 하지만 아직 명확하지는 않다. 따로따로 추적해야 할 세개의 변수를 이제 만들었고, 당신이 이것을 가지고 무엇을 어떻게 하려고 했었나를 떠올리게 해 줄 주석이 있다. 이것은 그다지 명확하거나, 사용할만하다고 할 수는 없다. 어쨌든, 계속해보자. 이 “삼각형”에 대해 어떤 계산을 할 수 있을까? 면적을 알기 위해서, 다음과 같은 함수를 사용할 수 있을 것이다:

function getArea( a, b, c ) {
  // Heron의 공식을 이용해서 삼각형의 면적을 계산한다.
 
  var semiperimeter   =   (a + b + c) / 2;
  var calculation     =   semiperimeter * (semiperimeter - a) * (semiperimeter - b) * (semiperimeter - c);
  return Math.sqrt( calculation );
}
 
alert( getArea( sideA, sideB, sideC ) );

뭔가 계산을 하기 위해서는 삼각형에 대한 모든 정보를 전달해주어야 한다는 것을 깨달았을 것이다. 삼각형과 관련된 활동(계산)은 삼각형의 데이터로부터 완전히 분리되어 있는데, 이러한 고립에는 그다지 의미가 있어 보이지 않는다.

좀 더 보자. 나는 이 함수와 변수들에 대해 상당히 범용적인 이름을 정해주었다: getArea, sideA 와 같이 말이다. 다음주에, 직사각형에 대해서 동작하도록 프로그램을 확장해야 함을 깨달았다면 어떻게 할 것인가? 아마도, 사각형에 사용하기 위해 sideA 와 sideB 같은 변수를 사용하려고 하겠지만, 이러한 변수는 이미 사용되었다. side1 과 side2 를 사용할수도 있겠지만, 이런 변수를 사용함으로서 혼동과 재난을 초래할 것이 분명함을, 당신도 이미 짐작할 것이라고 생각한다. 아마도, rectangleSideA, rectangleSideB 같은 변수들을 시도해 보다가 모순 속에 빠져들게 될 것 같다. 삼각형에 대해 이미 만들어 둔 코드를 다시 수정해서 triangleSideA 같은 것을 쓰게끔 하다가, 필경 에러를 만들어 낼 것이다. 이러한 수작업과 오류는 물론 함수의 이름에도 계속된다 - 두개의 다각형에 대해서, 그 계산이 개념적으로는 같은 것이기 때문에, 똑같이 getArea 라는 이름을 사용하고 싶지만, 그렇게 할 수 없다. 데이터를 표현할 수 있는 더 좋은 방법이 있을것이다.

몇개의 명령어들을 묶어서 단일한, 적당한 이름을 가진 활동(함수)을 만들어 내는 것이 이치에 맞는다. 마찬가지로, 몇가지 “것” 들을 하나의 단위로 묶어서 객체를 만들어내는 것이 이치에 맞는다. 자바스크립트에서 미리 정의된 기초적 데이터 타입(문자열, 상수, 불린 등)에 제한받는 대신, 객체를 만들어 사용함으로서 당신만의 데이터 타입 연결을 만들어 낼 수 있다. 객체에 사용되는 변수들은 숫자나 타입의 제한을 받지 않는다. 이렇게, 형식에 얽매이지 않는 유연함은, 프로그램을 작성할 때 당신이 다루려고 하는 것을 직접적으로 다루는 구조를 만들어낼 수 있게 하며, 또한 그것들을 자바스크립트에 내장된 기초적인것들과 마찬가지로 사용할 수 있게 해준다. 이제 삼각형과 직사각형 객체를 만들 것인데, 각각의 객체는 그 모양을 다루기 위해 필요한 모든 데이터들을 포함할 것이며, 또한 그 데이터들을 가지고 수행하려고 하는 모든 행동들도 함께 포함할 것이다. 이러한 목적을 염두에 두고, 문법을 보도록 하자.

익숙한 영역

이전 글의 마지막 실습을 보면, 다음과 같은 코드가 포함되어 있다:

var obj = document.getElementById( elementID );

그리고:

obj.style.background = 'rgb('+red+','+green+','+blue')';

자, 객체가 무엇인지 몰랐지만 이미 객체를 사용하고 있었다. 이 두개의 조각을 좀 더 자세히 분석해서 자바스크립트의 객체 문법에 대해 살펴보도록 하자.

var obj = document.getElementById( elementID ) 이 코드는 익숙해 보인다. 명령어 마지막에 포함되어 있는 괄호는 뭔가가 실행될 것이라는 의미이고, 이 실행의 결과가 obj 라는 변수에 저장될 것이라고 짐작할 수 있다. 여기에서 새로운 것은 딱 하나, 중간에 있는 점 이다. 이러한 점 표기법은 자바스크립트가 객체 안에 저장된 데이터에 접근하기 위해 사용하는 방법이다. 점 은 + 나 - 와 마찬가지로, 피연산자 사이에 있는 연산자이다.

관습적으로, 객체 안에 저장되고 점 연산자를 통해 접근하는 데이터를 property 라고 부른다. 프로퍼티는 함수가 될 수 있는데, 이 경우 method 라 부른다. 이러한 단어에 특별한 의미는 없다 - 메서드는 함수일 뿐이고, 프로퍼티는 변수일 뿐이다.

점 연산자의 왼쪽에는 객체가, 오른쪽에는 프로퍼티가 놓인다. 위의 코드에 이러한 규칙을 적용해 본다면, 자바스크립트에 내장되어 있는 document 객체의 getElementById 메서드에 접근한다고 말할 수 있을 것이다. 이것에 관해 더 자세한 내용은 이어질 DOM 여행 글에서 확인할 수 있다.

다음 코드는 조금 더 흥미롭다: 이것은 점을 두개 가지고 있다. 자바스크립트의 객체 지원 중에서 정말로 흥미로운 것 중 하나는, 점 연산자 체인을 통해 복잡한 구조 속으로 들어간다는 것이다. 짧게 말해서, 이러한 체인은 마치 var x = 2 + 3 + 4 + 5; 를 계산하고 값으로 14를 기대하는 것과 같다. 객체 참조는 자신을 반환하고, 이러한 체인이 왼쪽에서 오른쪽으로 계속 이어진다(친구들에게 이것을 설명하면서 자바스크립트가 점 연산자를 “좌측 연결 삽입 연산자” 로 사용한다고 표현해서 깊은 인상을 줄 수 있을 것이다) 이 경우, obj.style 이 먼저 평가되고, 이것을 해석하면 그것의 background 프로퍼티에 접근하는 객체가 된다. 당신이 원한다면, 괄호를 사용해서 이것을 좀 더 명시적으로 표현할 수 있다: (obj.style).background.

객체 생성

삼각형 객체를 만들기 위해, 다음의 문법을 사용해서 명시적으로 생성할 것이다:

var triangle = new Object();

triangle 는 이제 비어있는 기초이며 무언가를 그 위에 쌓아올려야 한다. 점 연산자를 통해 프로퍼티들을 추가함으로서 그렇게 할 수 있다:

triangle.sideA  =   3;
triangle.sideB  =   4;
triangle.sideC  =   5;

객체에 새로운 프로퍼티를 생성하기 위해서 다른 특별한 일을 할 필요는 없다. 자바스크립트가 점 연산자를 평가할 때, 이것은 대단히 관대한 방법을 사용한다. 존재하지 않는 프로퍼티에 접근하려고 시도한다면, 자바스크립트는 그것을 새로 만들어낸다. 존재하지 않는 프로퍼티를 읽으려 한다면 자바스크립트는 “undefined” 값을 반환한다. 이것은 편리하지만, 주의깊게 사용하지 않는다면 에러를 만들어 낸다. 따라서 오타에 주의하도록 하자.

메서드를 추가하는 것 역시 비슷하다 - 예제를 보자:

triangle.getArea    =   function ( a, b, c ) {
  // Return the area of a triangle using Heron's formula
 
  var semiperimeter   =   (a + b + c) / 2;
  var calculation     =   semiperimeter * (semiperimeter - a) *
                                (semiperimeter - b) * (semiperimeter - c);
  return Math.sqrt( calculation );
 
};      // 이 줄에 사용된 세미콜론을 눈여겨 보기 바란다. 이것은 규칙의 일부이다.

이것이 함수 선언과 무척 비슷하다고 생각한다면, 제대로 보고 있는 것이다. 그저 함수 이름이 빠졌을 뿐이다. 자바스크립트는 익명 함수라는 개념을 갖고 있는데, 함수는 이름을 가지는 대신 다른 값들과 마찬가지로 변수에 저장된다. 이 코드에서, 나는 익명 함수를 만들어내고 그것을 triangle 객체의 getArea 프로퍼티에 저장했다. 이제 객체는 데이터와 함께 함수를 데리고 다닌다.

자가 참조

삼각형 객체를 만들어 낸 목적 중 하나는, 삼각형의 데이터와, 그 데이터를 가지고 할 계산 사이의 관계를 만들어 내는 일이었는데, 아직 그것을 완성하지 못했다. triangle.getArea 메서드가 여전히 각 변의 길이를 필요로 하고 있음을 알 수 있을 것이다. 따라서 이런 식으로 명령해야 하는데:

triangle.getArea( triangle.sideA, triangle.sideB, triangle.sideC );

이것이 처음에 했던 코드보다는 나은데, 왜냐하면 이것은 데이터와 계산 사이의 관계를 명확하게 표현하고 있기 때문이다. 하지만, 그 관계는, 메서드에게 어떤 값을 가지고 계산할지를 매번 알려줄 필요가 없는 것이어야 한다. 메서드는 자신을 포함하고 있는 객체 안에서 데이터를 수집할 수 있어야 하고, 사용자에게 값을 입력할 것을 요구하지 않고 그 데이터를 사용해야 한다.

메서드가 자신을 포함한 객체 안에서 데이터를 수집할 수 있게 하는 비결은 this 키워드 안에 있다. 메서드를 정의할 때 이 키워드를 사용함으로서, 메서드가 실행될 때 같은 객체 내의 다른 프로퍼티나 메서드를 참조하도록 지정할 수 있다. this 를 사용하도록 getArea 를 다시 수정하면 다음과 같다:

triangle.getArea    =   function () {
  // Return the area of a triangle using Heron's formula
 
  var semiperimeter   =   (this.sideA + this.sideB + this.sideC) / 2;
  var calculation     =   semiperimeter * (semiperimeter - this.sideA) * (semiperimeter - this.sideB) * (semiperimeter - this.sideC);
 
  return Math.sqrt( calculation );
 
};      // Note the semi-colon here, it's mandatory.

여기서 보는 바와 같이, this 키워드는 거울과 비슷하게 동작한다. getArea 메서드가 실행될 때, 메서드는 객체 내부에서 sideA, sideB, sideC 프로퍼티를 검색하게 된다. 객체 내부에 프로퍼티가 이미 정의되어 있으므로, 외부에서 입력하는 값에 의존하지 않고 계산을 할 수 있다.

이것은 조금 과하게 단순화시킨 표현이다. this 키워드가 언제나 메서드를 포함하는 객체를 참조하는 것은 아니다 - 사실 이 키워드는 자신을 호출하는 문맥에 기반해서 동작한다. 모호함에 대해 사과드린다. 하지만, 이것을 다루는 것은 이 글의 초점을 벗어나는 일이 될 것이다. 아무튼, 이 글에서는, this 키워드는 항상 triangle 객체를 참조할 것이다.

연관된 배열로서의 객체

객체의 프로퍼티와 메서드에 접근하는 방법에는 점 연산자만이 있는것은 아니다. 이미 다루었던 글, 배열에 대하여를 통해서 충분히 익숙해져 있을, 대괄호 표기법<sbb>subscript notation</sub>을 사용해서 더 효율적으로 접근할 수 있다. 짧게 말해, 당신은 객체를 연관된 - 일반적인 배열이, 값에 숫자를 할당하는 것과는 대조적으로 값에 문자열을 할당하는 - 배열이라고 생각해도 무방하다는 것이다. 이러한 표기법을 사용해서, triangle 객체를 다른 방법으로 작성할 수 있다:

var triangle = new Object();
triangle['sideA']   =   3;
triangle['sideB']   =   4;
triangle['sideC']   =   5;
triangle['getArea'] =   function ( a, b, c ) {
  // Return the area of a triangle using Heron's formula
 
  var semiperimeter   =   (a + b + c) / 2;
  var calculation     =   semiperimeter * (semiperimeter - a) * (semiperimeter - b) * (semiperimeter - c);
  return Math.sqrt( calculation );
 
};      // Note the semi-colon here, it's mandatory.

언뜻 보기에는, 이것은 불필요하게 길게 쓴 것으로 보일 수 있다. 왜 간단한 점 연산자를 사용하지 않는가? 이러한 새로운 문법의 장점은, 프로퍼티의 이름이 프로그램 안에서 완전하게 정의될 필요가 없다는 것이다. 프로퍼티의 이름을 명시하기 위해 변수를 사용할 수 있고, 이러한 것을 허용함으로서 프로그램은 참으로 유연해질 수 있다 - 문맥에 기초해서 다양한 동작을 수행할 수 있다는 뜻이다. 예를 들어, 두개의 객체가 하나의 프로퍼티를 공유하는지 비교해 볼 수 있는 함수를 작성할 수 있다:

function isPropertyShared( objectA, objectB, propertyName ) {
  if (
     typeof objectA[ propertyName ] !== undefined
     &&
     typeof objectB[ propertyName ] !== undefined
     ) {
         alert("Both objects have a property named " + propertyName + "!");
       }
}

이러한 함수는, 점 표기법을 사용해서는 절대 만들어 낼 수 없는데, 점 연산자 뒤에는 프로퍼티의 이름을 명시적으로 적어주어야만 하기 때문이다. 당신은 이 문법을 아주 많이 사용하게 될 것이다.

참고 : 연관된 배열은 Perl 언어에서는 해쉬 라고 부르며, C# 에서는 해쉬테이블, C++ 에서는 맵, 자바 에서는 해쉬맵, Python 언어에서는 딕셔너리, 이렇게 다양하게 표현된다. 이것은 아주 강력하면서도 기초적인 프로그래밍 기법이고, 이것의 다른 이름을 이미 알고 있었을 수도 있다.

객체 리터럴

아주 친숙한 코드를 좀 더 자세히 들여다보도록 하자:

alert(“Hello world”);

alert는 함수이고, “Hello world” 라는 문자열을 인수로 가지고 호출되고 있다는 것을 알 수 있다. 여기에서 강조하고자 하는 것은, 이렇게 쓸 필요가 없다는 것인데:

var temporaryString = "Hello world";
alert(temporaryString);

자바스크립트는, 따옴표(” ”)로 둘러싸인 모든 것은 문자열로 취급되어야 한다고 이해하며, 그것이 어디에 쓰였든 간에 올바르게 처리할 수 있는 필요한 모든 일을 백그라운드로 처리한다. 문자열이 만들어지고, 그것이 함수의 인수로 전달되는 과정이 한번에 이루어졌다. 정형적으로는, “Hello world” 이것은 문자열 리터럴 을 참조한다: 문자열을 생성하기 위해 필요한 모든 것을 완전하게 입력한 것이다.

자바스크립트는, “객체 리터럴” 에 대해서도 비슷한 문법을 가지고 있으며 이것을 통해 문법적인 제약에 지나치게 구애받지 않고 객체를 생성할 수 있다. 객체 리터럴을 가지고, 위에서 만들어 낸 객체를 다시 작성해 보자:

var triangle = {
  sideA:      3,
  sideB:      4,
  sideC:      5,
  getArea:    function ( a, b, c ) {
    // Return the area of a triangle using Heron's formula
 
    var semiperimeter   =   (a + b + c) / 2;
    var calculation     =   semiperimeter * (semiperimeter - a) * (semiperimeter - b) * (semiperimeter - c);
    return Math.sqrt( calculation );
 
  }
};

역주 : 이러한 표기법을 JavaScript Object Notation - 자바스크립트 객체 표기법 - JSON 이라고 부른다.

이러한 문법은 명확하다: 객체 리터럴은 객체의 시작과 끝을 중괄호로 둘러싸며, 중괄호 안에는 프로퍼티 이름 : 프로퍼티 값 쌍이 콤마로 구분되어 나열된다. 이러한 문법을 사용함으로서, 프로그램의 매 행마다 객체 이름을 반복하는 지루한 작업에서 해방되어 쉽게 프로그램을 구조화할 수 있다.

한가지 조심할 것이 있다 : 객체 리터럴의 프로퍼티 리스트 중 마지막 것(여기에서는, getArea) 뒤에 쉼표를 넣는 실수를 아주 흔하게 범한다. 쉼표는 프로퍼티 사이 에만 넣어야 한다 - 마지막에 넣어진 필요없는 쉼표는 에러를 만든다. 특히, 코드를 이후에 수정하면서 프로퍼티를 추가하거나 지울 때 이런 실수를 범하기 쉬우므로, 쉼표가 정확한 위치에 있도록 주의를 기울일 필요가 있다.

요약 - 배울 것이 더 많이 있다

이 글은, 자바스크립트에서 객체가 갖는 가능성과 한계에 대해서 정말로 수박 겉핧기 정도밖에는 되지 않는다. 이 글을 완전히 읽었다면, 스스로 객체를 생성하여 프로퍼티와 메서드를 추가하고 그것을 자가참조의 형태로 사용하는데에는 익숙해 질 것이다. 이것 외에도 정말로 많은 것들이 있지만, 그중 어떤것도 필수적 이지는 않다. 이 글은 긴 여행의 출발점으로서 기획되었으며, 이후 당신이 길을 헤쳐나가는데 필요로 할 도구를 제공하는 목적으로 작성되었다.

읽어볼 것들

Object Oriented JavaScript: 자바스크립트의 객체지향 컨셉에 대한 더욱 상세한 소개.
Private Members in JavaScript: 더글러스 크록포드의, 자바스크립트에서의 캡슐화 기법을 다루는 세미나 형식 토의.

(역주 : 캡슐화 란, 함수 안에서 벌어지는 일에 대해 함수 밖에서는 알 방법이 없도록 분리하는 개념이라고 이해하면 된다. 조금 더 번거로울지는 모르겠으나, 에러는 확실히 줄어든다)

Scope in JavaScript: 다양한 문맥에서 사용되는 this 키워드의 복잡함에 대한 좀 더 상세한 토의.

연습문제

객체의 프로퍼티를 참조하기 위해 점 표기법 대신 대괄호 표기법을 사용해야 할 때는 어떤 경우인가?
객체는 어떻게 자신을 참조하는가? 왜 이것이 중요한가?
객체 리터럴이란 무엇인가? 객체 리터럴을 생성할때, 쉼표를 어디에 사용해야 하는가?
삼각형을 표현하고, 넓이를 계산하는 객체를 만들었다. 직사각형에 대해서도 그렇게 해 보기를 바란다. this 키워드를 사용해서, 직사각형의 getArea 메서드가 그 데이터를 필요하지 않은 곳에 전달하는 것을 막도록 해 보라.

저자에 관해

Mike West 는 경험많고 성공한 웹 개발자의 탈을 쓴 철학과 학생이다. 그는 웹 분야에서 10년 넘게 일해오고 있으며, 야후! 의 유럽 뉴스 사이트 개발의 책임을 맡은 팀에서 오랫동안 일했다.

2005년, 텍사스 교외의 광활한 평야를 떠나, Mike 는 독일의 뮌헨에 정착했고 독일어를 익히기 위한 그의 고군분투는 다행히 성공적이다. mikewest.org 가 웹에서의 그의 집이며, 후대를 위해 자신의 글과 링크들을 (천천히)모아 가고 있다. 그가 작성한 코드들은 GitHub 에서 찾아볼 수 있다.