Korea [국가변경]

이 기사 내에서 :
	XHTML 현황: 지금 우리는 어디에 있는가?
	XHTML 2: 무엇이 새로워졌는가?
	더욱 풍부한 구조
	더 나은 장치 독립성, 접근성, 의미
	메타데이터의 추가
	XHTML 2 사용하기
	참고자료
	필자소개
	기사에 대한 평가

관련 링크:
	XML 기술자료
	웹 개발 기술자료

한국 developerWorks > XML | 웹 개발 >

XHTML 2 사용하기 (한글)

XHTML의 차기 버전의 풍부한 콘텐트 구조 경험하기

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

영어원문

제안 및 의견

피드백

난이도 : 초급

Bob DuCharme, Solutions Architect, Innodata Isogen

2007 년 8 월 14 일

XHTML 2 스팩은 아직 완성되지 않았지만 XHTML 1보다 이미 많은 장점을 갖고 있습니다. 편집 포맷으로서, 단일 소스 퍼블리싱 시스템을 위한 중앙 스키마로서의 역할을 하는 등, 이전 버전보다 훨씬 풍부한 구조를 갖추었습니다. 브라우저에서 XHTML 2의 새로운 사용자 인터페이스 기능이 지원되기를 기다릴 필요 없이, 지금 이러한 새로운 기능을 경험할 수 있습니다.

소셜 북마크


	mar.gar.in

	Digg

	del.icio.us

	Slashdot

1년 전에, 산업 표준 그룹이 XHTML 2가 퍼블리셔(publisher)에게 얼마나 유용한지에 대한 프리젠테이션을 해줄 것을 요청했다. 필자는 그 유용성에 대해 잘 몰랐지만, 그들이 뉴욕까지의 경비를 대주었기 때문에 이것을 연구하기로 결정했다.

힘들여 연구할 필요가 없었다. XHTML 2는 XHTML에 세련된 구조를 추가하여, 콘텐트를 브라우저에 단순히 전달하는 것이 아닌, 콘텐트를 생성 및 저장할 수 있는 포맷이다. XHTML 2를 거의 사용할 수 있는 것처럼 말했지만, 이는 약간 과장법을 섞은 것이다. 많은 곳에서 이 미완의 표준을 사용하는 것에 대한 확고한 정책들을 만들어 놓았고, XHTML 2는 여전히 Working Draft (참고자료)이다. 거의 모든 HTML 관련 표준과는 달리, XHTML 2는 유명한 브라우저가 지원하기도 전에 이미 많은 가치를 드러내고 있다. 많은 사람들에게 익숙한 HTML 엘리먼트와 애트리뷰트에서 많이 벗어나지 않고도 더욱 풍부하고 세련된 구조로 콘텐트를 저장할 수 있기 때문이다.

XHTML 현황: 지금 우리는 어디에 있는가?

W3C XHTML 1.0 표준(참고자료)은 XML 버전의 HTML을 만들었다. 브라우저는 웹 페이지가 잘 구성된 XML인지 여부에는 까다롭게 굴지 않지만, Firefox와 Microsoft™ Internet Explorer에서 작업하는데 지친 웹 사이트 디자이너들은 표준에 더 많은 가치를 부여한다. Open Web Design과 Open Source Web Design (참고자료) 같은 오픈 소스 CSS 컬렉션의 많은 스타일시트들은 데모용으로 XHTML 1 샘플 파일을 사용하고, 필자도 잘 구성된(well-formed)이라는 의미가 사이트가 XHTML로 되어있다라는 의미라는 이야기도 들었다. Internet Explorer와 Firefox가 더 많은 CSS 기능을 지원하면서, 웹 디자이너들은 CSS 스타일시트에 디자인 트릭을 더했고, 더욱 간단하고 단순한 XHTML은 베이스 문서로 남겨두었다.

XHTML 1.1 (참고자료)은 어떤 새로운 기능도 추가하지 않았지만, XHTML을 모듈로 나누었다. 이는 두 가지 관점에서 가치가 있다. 먼저, 특정 모듈에서 가치를 발견했다면 이것의 하위 세트를 보다 쉽게 적용할 수 있다. 예를 들어, Wireless Application Forum (WAP)는 기본 XHTML 구조를 표준과 통합시켜 콘텐트를 모바일 폰에 제공할 충분한 이유를 갖고 있지만, WAP 문서에 이미지 지도나 편집 모듈 기능 같은 작은 스크린에는 비합리적인 사용자 인터페이스 기능들을 적용하는 것을 허용하지 않았다.

DTD용 모듈식 아키텍처 또는 스키마의 또 다른 장점은 자신의 애플리케이션을 위해 특화된 새로운 모듈을 쉽게 연결할 수 있다는 점이다. 기존의 모듈을 선택하는 기능과 결합하여, 이것은 이미 퍼블리싱 산업에 혜택을 가져다 주었다. 퍼블리싱 산업 메타데이터를 위한 PRISM 표준은 XHTML 1.1의 하위 세트를 선택했고 산업 스팩의 어휘를 사용하여 새로운 모듈을 추가하여 퍼블리싱 워크플로우를 통해 콘텐트의 트래킹을 쉽게 만들었다. (참고자료)

XHTML 1.1의 개발을 단순하게 생각할 수 있다. 이러한 것을 더 낫게 구성함으로써 많은 것들을 던지지 않겠지만, 여러분은 보다 쉽게 여러분이 가진 것을 사용할 수 있고 심지어 새로운 것을 만들 수 있는 워크벤치를 구현할 장소도 된다.

XHTML 1.1은 2001년 5월부터 표준이었다. W3C 용어로 권고안(Recommendation)이었다. XHTML 2.0의 최신 라운드는 2006년 7월의 새로운 Working Draft였다. 이것은 여전히 더 많은 여러 단계들을 거쳐야 하지만, 현재 RELAX NG 스키마로(참고자료) XHTML 2를 생성 및 사용하여 스팩이 Recommendation이 될 때 XHTML로의 이동 속도를 높일 수 있다. 간단한 XSLT 스타일시트는 이러한 파일들을 브라우저 디스플레이용 XHTML 1으로 전환하거나, XHTML 2 Working Draft (참고자료)에 포함된 CSS 스타일시트를 사용하여 브라우저에서 이러한 문서들을 디스플레이 할 수 있다. (현재로서는, Firefox가 더 나은 일을 수행한다.)

위로

XHTML 2: 무엇이 새로워졌는가?

XHTML 2는 기존 신택스를 더욱 단순하게 하는 작업을 계속 이어가면서 새로운 기능도 추가했다. XForms 지원도 추가했다. 10년이 넘게 군림해 오던 HTML 보다 더욱 고급이다. XHTML 2에는 또한 XML Events가 포함되어 있는데, 이는 특정 사용자 인터페이스 액션에 대해 실행할 이벤트를 구분할 수 있도록 해주며, JavaScript나 ASP를 사용하여 스크립트를 작성할 필요를 줄여준다. 주요 브라우저가 이를 지원한다면 이러한 기능들은 유용하겠지만, 브라우저가 XHTML 2를 지원하기 전부터 퍼블리시 하는 사람들이 유용하게 사용할 수 있는 기능들도 있다.

더욱더 풍부한 재사용 가능한 구조
장치 독립성, 접근성, 문법
메타데이터 추가 용이성

위로

더욱 풍부한 구조

XML에 콘텐트를 저장하는 많은 퍼블리셔들은 기존의 표준 스키마(W3C Schema, RELAX NG 스키마, DTD)를 사용하는 것이 고유의 스키마를 처음부터 만드는 것보다 더 낫다. 이들은 DocBook이 너무 복잡하다는 사실을 깨달았다. HTML이나 XHTML 1은 너무 단순했다. 이 중에서, XHTML 2는 DocBook의 풍부함과 XHTML 1의 단순함을 겸비했다. 콘텐트가 다양한 미디어 형태로 딜리버리용 다른 포맷으로 변환되어야 하는지 여부에 상관없이 콘텐트를 저장하는데 완벽하게 좋은 포맷이 되게 한다.

Listing 1에는 샘플 XHTML 1 파일이 포함되어 있는데, 이것의 구조는 들여 쓰기로 나타난다.

Listing 1. XHTML 1 파일의 구조

                
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>My Web page</title>
  </head>
  <body>
    <h1>My Web Page</h1>
    <p>Here is my Web page.</p>
    <h2>Section 1 of my Web page</h2>
    <p>Here is section 1 my Web page.</p>
    <h3>Section 1.1 of my Web page</h3>
    <p>Here is a subsection of my Web page.</p>
    <h2>Section 2 of my Web page</h2>
    <p>Here is section 2 of my Web page.</p>
  </body>
</html>

여기에는 많은 구조가 없기 때문에 body 엘리먼트 내에 많은 들여쓰기를 볼 수 없다. 이 문서의 트리 표현은 많은 자식들은 있고 손자는 없는 body 엘리먼트를 보여주면서, 메인 h1 타이틀의 계열인 "My Web Page"로서 보여지는 "Here is a subsection of my Web page" 문장으로 나타난다. 이 단락이 서브 섹션의 일부라는 마크업의 유일한 단서는 이보다 앞선 최신 헤더인 h3이 이전 헤더보다 더 큰 숫자를 갖고 있다는 사실이다. 어떤 컨테이너 엘리먼트도 이들이 타이틀로서 작용하는 콘텐트로 헤더를 그룹핑 하지 않는다. 여러분이 h1 헤더와 웹 페이지의 디스플레이 가능한 나머지 콘텐트를 래핑하는 body 엘리먼트를 카운트 하지 않는 한 말이다. 헤더/콘텐트 컴비네이션 주위에 div 엘리먼트를 래핑할 수 있지만, span 엘리먼트와 마찬가지로 div는 매우 일반적인 그룹핑 엘리먼트이다. 이것은 특정 단락이 메뉴, 또는 사이드바, 또는 기타 웹 페이지의 시각적 프리젠테이션 엘리먼트를 형성하고 있다는 것을 나타내는 등의 많은 목적들을 제공하기 때문에 이것의 존재가 콘텐트의 구조적 단위를 나타낸다고 추측할 수 없다.

XHTML 2의 새로운 section과 h 엘리먼트들은 함께 작동하여 콘텐트 재사용을 더욱 쉽게 만드는 더욱 풍부한 구조를 만든다. Listing 2는 Listing 1에서 XHTML 2에서 body 엘리먼트에 상응하는 것을 나타내고 있다.

Listing 2. XHTML 2 body 엘리먼트

                
<body>
  <section>
    <h>My Web Page</h>
    <p>Here is my Web page.</p>
    <section>                      
      <h>Section 1 of my Web page</h>
      <p>Here is section 1 my Web page.</p>
      <section>
        <h>Section 1.1 of my Web page</h>
        <p>Here is a subsection of my Web page.</p>
      </section>
    </section>
    <section>
      <h>Section 2 of my Web page</h>
      <p>Here is section 2 of my Web page.</p>
    </section>
  </section>
</body>

이 버전에서, "Here is a subsection" 단락은 메인 타이틀을 보여주는 "My Web Page" h 엘리먼트를 갖고 있는 section 엘리먼트의 증손자와 같은 것이다!

이러한 풍부한 구조의 한 가지 장점은(싱글 소스 퍼블리싱 시스템에 대해 중앙 포맷으로서 작용하기에 XHTML 1 보다 XHTML 2가 더욱 가능한 후보가 되는 근본적인 이유는) 스트림 프로세싱이 더 쉽다는 점이다. 이 모든 것을 프로세싱 전에 메모리로 로딩할 수 없는 많은 인풋을 프로세스 해야 한다면, 예를 들어, CD-ROM을 위한 콘텐트를 준비한다면 프로세스가 XHTML 2 문서에서 각 섹션이 끝나는 곳을 규명하기가 더 쉽다는 점이다. 예를 들어, 제목에 "Beagle" 이라는 단어를 가진 모든 섹션들을 가져와야 하는 경우를 생각해 보자. 이러한 제목을 찾는 것은 쉽지만, 섹션이 어디에서 끝나는지를 결정하는 것은 XHTML 1에서 더욱 어렵다. 스트림 기반 인터페이스, XQuery, 또는 XSLT 중에서 어떤 것으로 XHTML을 처리하든지 간에, 섹션이 끝나는 곳에 대한 확실한 설명은 추상화를 더욱 쉽게 만든다.

이제, beagles에 새로운 퍼블리케이션을 추가할 것이기 때문에 이러한 섹션들을 추출했고, 여러분이 가져온 모든 섹션은 헤더로서 h3 엘리먼트를 갖고 있다. h3 같이 숫자가 달린 XHTML 1 헤더들은 XHTML 2에서도 합법적이지만, 새로운 퍼블리케이션이 이러한 엘리먼트를 메인 섹션으로서 사용하거나 특정 챕터 내의 하위 섹션으로서 사용한다면 어떻게 하겠는가? 다시 돌아가서 h3 엘리먼트를 h2 엘리먼트 또는 h4 엘리먼트로 바꾸거나, 새로운 콘텍스트에서 역할을 구분한 엘리먼트로 바꿔야 한다. 이들이 원래 문서의 XHTML 2 h 엘리먼트였다면, section 조상 엘리먼트의 수에 의해 표시된 계층적 역할에서 (예를 들어, 위 Listing 2의 section 1.1 h 엘리먼트는 세 개의 section 헤더 조상들을 갖고 있지만, "My Web Page" h 엘리먼트는 단 한 개만 갖고 있다.), 여러분은 이들을 바뀌지 않은 새로운 문서로 연결해야 하고 새로운 문서의 section 엘리먼트의 중첩에 의해 표시된 역할을 갖고 있어야 한다. CSS, XSLT, 기타 XML 프로세싱 툴과 표준들은 중첩 레벨에 기반하여 같은 이름의 엘리먼트들을 다르게 처리하는 방식을 제공하기 때문에, XHTML 1 헤더의 일부였던 숫자들을 놓칠 것이다. h2와 h3 엘리먼트는 갖고 있지만 h1 엘리먼트는 없는 (X)HTML 문서의 수를 고려한다면, 너무나 많은 사람들이 계층을 나타내기 위해 이들을 사용하지 않는 이유를 알 수 있을 것이다.

p 엘리먼트 역시 XHTML 2에 더 많은 구조를 갖고 있다. 한 문장의 중앙에 일부 샘플 코드 가져왔다.

print "Hello? World?";

샘플 코드 다음에 문장을 지속시키기 원한다면, XHTML 1은 나뉜 문장의 두 부분들을 두 개의 다른 p 엘리먼트에 놓도록 할 것이다. 이들이 의미적으로 같은 단락에 있을 경우 말이다. XHTML 2는 p 엘리먼트 내에 샘플 코드, 블리트 및 넘버 리스트, 다른 많은 블록 엘리먼트를 놓을 수 있도록 하면서 마크업이 문서의 구조를 보다 정확하게 반영할 수 있도록 한다.

표현 마크업에서 구조적 마크업으로 가는 또 하나의 단계는 hr 엘리먼트를 separator로 재 명명 하는 것이다. HTML Working Group은 수평적 규칙(horizontal rule,)을 의미했던 원래 이름이 구조적 마크업과 표현 마크업 중간의 회색 지대로 빠진다는 것을 알게 되었다. 이들은 아시아 언어로 작성하는 사람들의 수직 규칙(vertical rule)을 요청하고, 실제로 규칙들이 아니었던(HTML Working Group Chair Steven Pemberton은 James Joyce의 Ulysses에서 여러 다른 변이들을 지목했다; 참고자료) 많은 수평적 세퍼레이터(separator)를 보았다. 이것의 사용을 보다 정확히 반영하고 프리젠테이션에서 유연성을 허용하도록 hr 엘리먼트를 재 명명 하도록 하였다.

위로

더 나은 장치 독립성, 접근성, 의미

이러한 세 가지 목표는 실제로 서로 오버랩 된다. Text-to-Speech 트랜스레이터로 읽힐 때 의미가 통하는 웹 페이지는 하나의 플랫폼에서 연결되지 않은 웹 페이지이고, 이것은 시각 장애인들이 보다 쉽게 이해할 수 있는 웹 페이지이다. XHTML 2 Working Draft에는 다음과 같이 기술하고 있다.

전화, PDA, 타블릿, 텔레비전 같은 온라인에 등장하는 새로운 장치들은 각 장치 유형에 대한 문서의 새로운 버전을 작성할 필요 없이, 한번 작성해서 다양한 장치에서 여러 가지 방식으로 렌더링 될 수 있도록 하는 디자인의 필요를 야기시킨다.

퍼블리셔들은 이것의 가치를 보기 위해 더 기다릴 필요가 없다. 장치 독립성은 XML이 고안되기 전에 SGML에 많은 부분 적용되었다. 콘텐트의 편집 버전이 자동화된 루틴이 각 포맷들로 변환할 정도로 충분한 구조와 의미 시맨틱 정보를 갖고 저장되는 한, 프린트, 웹 페이지, CD-ROM에서 같은 콘텐트를 퍼블리시 할 수 있기 때문이다. 11년 전, 필자는 경쟁사가 HTML로 그들의 콘텐트의 편집 버전을 저장할 것이라고 들었다. XHTML 2 시대에는, 이것이 허황된 생각은 아니다.

XHTML 2의 엘리먼트의 기존 문법으로는 충분하지 않다면, 어떤 엘리먼트에 추가될 수 있는 새로운 role 애트리뷰트는 엘리먼트의 목적에 대해 더 많은 것을 이야기 해 줄 수 있다. XHTML 2 스팩은 이 애트리뷰트에 9 개의 값(banner, note, contentinfo, search, definition, secondary, main, seealso, navigation)을 지정한다. banner와 navigation 같은 역할 값들은 프리젠테이션 지향이지만, definition과 note 같은 값들은 다중 미디어를 위해 콘텐트를 준비하는 퍼블리싱 환경에 더욱 유용한 시맨틱을 갖고 있다. 고유의 네임스페이스에 있다면 고유의 role 값들을 만들 수 있다.

위로

메타데이터의 추가

W3C RDF 표준으로 메타데이터를 URL로 구분할 수 있는 것으로 할당할 수 있다. 이를 수행하는 RDF/XML 신택스는 1999년부터 존재했고, 많은 사람들을 질리게 할 정도로 복잡하고 어렵다. 기존 XHTML 애트리뷰트를 사용하고 몇 가지 새로운 것을 추가함으로써, XHTML 2에서는 새롭고 더 간단한 RDF 신택스를 사용하여 about 애트리뷰트를 갖고 있는 문서와 문서 컴포넌트에 대핸 메타데이터를 추가할 수 있다. Listing 3은 RDF 메타데이터를 나타내는 데 사용되는 span 엘리먼트가 주어-술어-목적어 트리플(객체 아이디-애트리뷰트 이름-애트리뷰트 값 트리플)을 삽입하는데 필요한 추가 정보를 저장하는 예제를 보여주고 있다.

Listing 3. span 엘리먼트로 메타데이터 인코딩 하기

                
<section>
  <span property="dc:subject" content="recipe"/>
  <span property="fb:workflowStage" content="3a"/>

  <h><span property="dc:title">
Carrion, My Wayward Son
</span></h>
  <p><span property="dc:date" content="2007-05-15" datatype="xs:date>
May 15, 2007
</span></p>
</section>
</blockcode>
</section>

Listing 3의 RDF 마크업은 about 애트리뷰트를 사용하여 주어의 이름을 짓지 않으므로, RDF 프로세서는 문서 자체가 각 트리플의 주어인 것으로 간주한다. — 이들은 문서 자체에 대한 메타데이터이다.

접두사 dc가 Dublin Core namespace http://purl.org/dc/elements/1.1/을 나타내기 위해 선언되고, fb가 FooBar Company의 http://www.foobarco.com/ns/vocab# 네임스페이스를 나타낸다고 가정하면, Listing 3의 RDF 마크업은 RDF 트리플의 데이터베이스로 추출 및 로딩할 수 있는 방식으로 다음과 같은 문장을 만든다.

이 문서는 "recipe"라고 하는 Dublin Core 주어를 갖고 있다.
이 문서는 "3a"라고 하는 workflowStage 값 (이 문서를 생성했던 기업용 메타데이터)을 갖고 있다.
이 문서는 "Carrion, My Wayward Son"이라는 Dublin Core 제목을 갖고 있다. 이 문장의 경우, 메타데이터 값 또는 트리플의 목적어는 실제 웹 페이지의 일부이고 다른 span 엘리먼트에서와 마찬가지로 content 애트리뷰트에 저장되지 않는다. 개별 객체를 지정할 필요 없이, 주어로서 작동하는 문서를 가지고, 싱글 애트리뷰트를 가진 span 엘리먼트를 가진 문서에 추가되는 메타데이터의 유용한 트리플을 갖고 있다.
이 문서는 2007년 5월 15일에 공표되었다. 저장될 실제 값은 ISO 8601 표준 포맷 2007-05-15이다. 여기에는 타이핑 정보가 포함되어 있다. 이것은 W3C Schema 날짜 데이터 유형이다. (참고자료).

Semantic Web의 꿈은 사람들이 읽을 수 있는 콘텐트로서 그리고 프로그램이 읽을 수 있는 데이터로서 웹 페이지 데이터를 사용하는 것이다. (Listing 3의 dc:title 예제 참조) fb:workflowStage 예제는 RDFa의 추가 장점들을 설명하고 있다. 임의의 메타데이터를 XHTML 2 문서에 추가할 수 있고, 이는 문서 트래킹과 재사용을 용이하게 한다.

위로

XHTML 2 사용하기

XML Events 같이 XHTML 2m의 새로운 사용자 인터페이스 기능을 사용하기까지 기다릴 필요가 없지만, XHTML 2의 새로운 구조적 기능들을 시험해 봐야 한다. 아직 완성되지 않은 스팩으로서 여전히 매력적인 대상이지만, 천천히 진행되고 있다. 스키마와 CSS 스타일시트를 현재 사용할 수 있으므로, 이것이 어떤 이득을 가져오는지 생각해 봐야 한다. 사실, 필자는 이 글을 작성하는데 이것을 사용하고 있다. nXML 모드의 Emacs에서(참고자료) XHTML 2의 RELAX NG 스키마의 콘텍스트 중심 XML 편집을 실행하고 있다. 필자는 developerWorks DTD와 간단한 XSLT 스타일시트에 순응하기로 결정했다. XHTML 2는 표준 Recommendation이 될 때 이를 더욱 전적으로 사용할 예정이다.

참고자료

교육

XHTML 2.0 기술 리포트
CSS 스타일시트: XHTML 2 Working Draft에 포함된 스타일시트.
XHTML 1.0 Recommendation
W3C XHTML 1.1 Recommendation
"웹의 미래: XHTML 2.0" (Nicholas Chase, developerWorks, 2002년 9월)
"XHTML 2.0" (Edd Dumbill, developerWorks, 2006년 1월)
Chris Herboth의 developerWorks 시리즈, "XForms 소개":
- Part 1: 폼을 위한 새로운 웹 표준: XForms가 실제로 작동하는 방법, Firefox와 Microsoft Internet Explorer로 XForms 설정 방법.
- Part 2, 폼, 모델, 컨트롤, 제출 액션: 컨트롤을 사용하고 데이터 모델을 생성하여 XForms 기반 폼 생성하기
- Part 3,액션과 이벤트 사용하기: XForms로 액션과 이벤트를 사용하고 폼의 아웃풋 포맷을 제어하는 방법 배우기.
W3C XForms Recommendation
"XHTML2: 접근성, 가용성, 장치 독립성, 시맨틱"
XML Schema Part 2
오픈 웹 디자인과 오픈 소스 웹 디자인: XHTML 1 샘플 파일을 포함하여 오픈 소스 CSS 컬렉션의 많은 스타일시트.
무선 애플리케이션 포럼
PRISM
IBM XML 인증: IBM-Certified Developer.
XML 기술 자료: 한국 developerWorks XML 존의 광범위한 기술자료, 팁, 튜토리얼, 표준, IBM 레드북 보기.
developerWorks 기술 이벤트와 웹캐스트
technology bookstore

제품 및 기술 얻기

nXML: GNU Emacs를 강력한 XML 에디터로 바꾸기.
RELAX NG schema for XHTML 2: RELAX NG 다운로드
IBM 시험판 소프트웨어: developerworks에서 시험판 소프트웨어를 다운로드 하여 차기 개발 프로젝트에 활용해보라.

토론

XML 존 토론 포럼
developerWorks 블로그: 블로그와 한국 developerWorks 커뮤니티 참여하기.

필자소개


		Bob DuCharme 는 Innodata Isogen의 솔루션 아키텍트이고, XML이 네 글자 단어였을 때 XML 전문가였다. 정보 기술과 관련한 네 권의 책과 거의 백 건의 아티클을 기고했다. (http://www.snee.com/bob)

기사에 대한 평가

위로

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. 기타 회사, 제품, 및 서비스명은 다른 상표나 서비스 마크일 수 있습니다.

IBM 소개

개인정보 보호정책

문의