메인 컨텐츠로 가기

developerWorks 이용 약관에 동의하시는 경우 제출을 클릭하십시오. 이용 약관 보기.

developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

  • 닫기 [x]

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

developerWorks 이용 약관에 동의하시는 경우 제출을 클릭하십시오. 이용 약관 보기.

모든 정보가 안전하게 전송되었습니다.

  • 닫기 [x]

유닉스와 리눅스를 함께 어울리게 만들기

Martin Brown, 자유기고가, IT 컨설턴트/프리랜서 작가
Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.

요약:  NIS(Network Information Service)로 리눅스(Linux®)와 유닉스(UNIX®) 사이에 핵심 데이터베이스를 공유하는 방법과 NFS(Network File System)로 직접 연결하거나 automounter로 파일 시스템을 공유하는 방법을 살펴봅니다. 유닉스와 리눅스는 비슷하지만, 두 시스템을 통합하는 과정을 복잡하게 만드는 몇 가지 차이점이 있습니다. 예를 들어, 동일한 인증 시스템을 공유하지만, 대다수 시스템은 또한 단독으로 동작합니다. 이런 인증 정보 공유는 네트워크에 물린 모든 서버에 SSO(Single Sign-On) 기능을 제공합니다.

원문 게재일:  2008 년 7 월 08 일
난이도:  중급 영어로:  보기
페이지뷰:  1521 회
의견:  


NIS로 자료 공유하기

NIS(Network Information Service)는 썬 마이크로시스템즈가 개발했으며, 옐로우 페이지 서비스라고도 알려져 있다. 시스템 동작 방식은 단순하다. /etc/hosts와 /etc/passwd 같은 표준 시스템 데이터베이스를 (약어 의미는 오래전에 사라진 DBM 형식을 사용한) 일반적인 데이터베이스 형식으로 변환한다.

이 데이터베이스는 NIS 서버(NIS 마스터라고도 부른다)에 저장된다. 모든 개별 데이터베이스는 이름을 붙인 도메인에 놓아두며, RPC(Remote Procedure Call) 인터페이스를 사용해 마스터로부터 공유한다. 다음에 제시하는 다양한 파일을 지원한다.

  • passwd (지원한다면 /etc/shadow 파일도)
  • groups
  • hosts
  • netmask
  • netgroup
  • automount
  • services
  • protocols
  • ethers
  • (전자편지를 위한) aliases

슬레이브 서버(예를 들어, NIS 마스터 데이터베이스 백업 복사본을 제공하기를 원하는 기계)는 서버에서 공개된 데이터베이스를 복사한다. 사용자가 로그인할 경우 정보를 탐색할 필요가 생기면 NIS 클라이언트는 NIS 서버에 질의를 던진다. NIS 클라이언트는 정보를 절대로 저장하지 않는다. 클라이언트는 (ybind 도구를 사용해) NIS 서버에 묶여있기 때문이다. 이런 결과로 인해 그림 1과 같은 구조가 만들어진다.


그림 1. NIS 마스터와 슬레이브 구조
NIS 마스터와 슬레이브 구조

NIS 데이터베이스에 변경이 일어나면 변경이 일어난 시점에서 슬레이브 서버로 자동으로 전파되며, yppush 명령을 사용해 수동으로 전파할 수도 있다.

사용자가 암호를 변경할 때 사용자가 NIS 데이터베이스에 직접 변경을 가하면 NIS 마스터 서버로 변경 내역이 전해지며, 데이터베이스를 갱신하고 슬레이브 서버에 변경 내역을 전파한다.


NIS냐 NIS+냐?

NIS+는 NIS 마스터와 슬레이브 컴퓨터 사이에 자료를 교환할 때 인증과 암호화를 지원하는 점에서 NIS와 다르다. 하지만 NIS+는 설정 방식이 상당히 어렵고 복잡하므로, 보안 요구가 있을 경우에만 사용한다. NIS+는 또한 이름 시스템을 확장해 단일 도메인 대신 트리 구조에 놓이도록 만들므로 좀 더 복잡하고 넓은 범위에도 사용자 정보를 배포할 수 있다.

NIS는 일반적으로 제대로 설정된 네트워크 내부에 구축된 표준 환경에서 동작하는 데 문제가 없으며, 동일 네트워크가 인터넷에 물려 있더라도 보안 위협을 받지 않는다. 대학교나 공중망을 통해 NIS 자료가 오가는 여러 사이트를 망라하는 경우를 비롯하여 사설망이 외부로 공개된 환경에서만 NIS+를 사용하자.


NIS 서버 설정하기

솔라리스, AIX®, HP-UX는 기본으로 NIS 시스템을 지원한다. 리눅스(Linux®) 배포판은 종종 NIS를 표준으로 포함하며, glibc 라이브러리도 NIS 지원 기능을 내장한다. 하지만 NIS를 설정하고 관리하기 위해 필요한 툴킷은 별도로 설치할 필요가 있다. 리눅스에서 NIS 서버를 돌리려면 다음 패키지가 필요하다.

  • ypserver
  • makedbm

두 패키지를 설치했다면, 일반적으로 /var/yp/Makefile 위치에 설치되는 NIS용 makefile를 편집해야 한다. 이 makefile은 초기 YP 데이터베이스를 빌드하는 데 사용할 환경 설정 매개변수를 포함한다. NIS에서 지원하려는 파일 유형을 포함하려면 all 정의를 편집해야 한다. 기본적으로 이런 규칙은 Listing 1에 열거된 모든 파일을 포함해야 한다.


Listing 1. all 규칙 정의
                
all: passwd group hosts ipnodes ethers networks rpc services protocols \
     netgroup bootparams aliases publickey netid netmasks c2secure \
     timezone auto.master auto.home ageing \
     auth.attr exec.attr prof.attr user.attr audit.user

원하지 않는 파일은 제거가 가능하다. 예를 들어 passwd, group, hosts 파일만 공유하기를 원할지도 모른다.

이제 데이터베이스를 생성할 차례다. 먼저 NIS 도메인 이름을 설정하자.

$ domainname mcslp.nis

리눅스 서버에서 지역 네트워크에 맞도록 /var/yp/securenets와 /etc/ypserv.conf 파일을 편집하자. 두 파일은 NIS 도메인 내부에서 정보를 공유하고 접근할 기계를 통제한다.

이제 데이터베이스를 초기화하자.

$ ypinit -m

ypinit 명령은 makefile을 사용해 원시 파일(예: /etc/passwd)을 NIS 형식으로 변환하는 나머지 작업을 수행한다.

원시 파일 내용을 바꾼 다음에는 항상 /var/yp 디렉터리로 이동해 다시 한번 make 명령을 내려 데이터베이스를 다시 빌드하자.

$ cd /var/yp
$ make

개별 사용자가 원격에서 로그인 암호를 갱신하도록 만들려면 rcp.yppasswdd 데몬을 띄워야 한다. 이 데몬은 클라이언트 요청을 받아서 NIS 데이터베이스를 직접 갱신하므로 마스터와 슬레이브 사이에 변경 사항을 전파해 클라이언트 요청을 제대로 처리하게 된다.


NIS 클라이언트 설정하기

NIS 클라이언트 설정을 위해 NIS 도메인 이름을 정의하고, 지역 NIS 서비스를 시작하고, NIS 마스터나 마스터 슬레이브에서 정보를 찾도록 서비스를 초기화할 필요가 있다. 이 과정에서 핵심은 ypbind인데, 클라이언트 기계를 NIS 서버에 붙이는 작용을 한다.

유닉스 환경에서, ypbind를 호출하면 자동으로 NIS 서버를 결정한다. 대다수 리눅스 버전에서는, /etc/yp.conf 파일에 유효한 NIS 서버 목록을 설정해야 한다. 예는 다음과 같다.

ypserver 192.168.0.22

클라이언트를 NIS 서버에 연결하는 기본 과정은 다음과 같다.

  1. $ domainname mcslp.nis로 NIS 도메인을 설정한다.
  2. $/sbin/portmap으로 필요하다면 RPC 매퍼 데몬인 portmap을 시작한다.
  3. /var/yp 디렉터리를 생성한다. 이 디렉터리는 몇몇 NIS 정보를 담는 데 사용한다.
  4. $ /usr/sbin/ypbindypbind를 시작한다.

이제 ypcat을 사용해 직접 데이터베이스에 질의를 던지는 방법으로 NIS 연결이 활성인지를 점검한다. 예를 들어, 이름 순으로 NIS passwd 파일 내용을 보려면 다음과 같은 명령을 내린다.

$ ypcat passwd.byname

이렇게 하면 전체 passwd 데이터베이스 내용을 출력한다. 실제로 시스템이 NIS 데이터베이스 정보를 사용하려면, 원하는 정보를 찾기 위해 시스템이 사용하는 서비스 종류를 다시 설정해야만 한다.


nsswitch.conf

리눅스와 유닉스 양쪽에서 nsswich.conf 파일은 일반적으로 시스템이 다양한 자료에서 정보를 찾는 위치를 결정하기 위해 사용한다. 예를 들어, 정보 탐색을 위해 nsswitch.conf 파일을 설정해 파일에서 호스트 정보를 찾고, DNS 질의를 던지고, 해당 정보 검색을 위해 NIS 시스템을 사용하도록 만든다.

이 파일은 정보를 찾는 위치를 지정할 뿐만 아니라 다양한 정보원을 대상으로 질의 순서도 정한다. 올바른 순서는 정보를 질의하기 위한 올바른 위치 지정과 장애가 일어났을 경우 대응하는 네트워크 회복력에 영향을 미친다.

파일 형식은 시스템 데이터베이스를 열거한 단순 목록이며, 콜론 이후에 원하는 순서로 서비스 목록을 정의한다. 예를 들어, Listing 2는 NIS, DNS, 지역 파일 순서로 nsswitch.conf 파일을 간단하게 설정한 예다.


Listing 2. 간단한 nsswitch.conf 파일 예
                
passwd:      nis files
shadow:      nis files
group:       nis files

hosts:       nis dns files
networks:    nis dns files

Listing 2에서 (가능하다면) NIS 데이버테이스를 사용하도록 passwd를 정의한 행을 볼 수 있다. 사용자가 로그인할 때 NIS 테이블을 먼저 참조한다. 사용자 이름을 찾지 못하면 서비스는 오류를 반환하고, 시스템은 목록에서 다음 행(이 경우에는 지역 파일)을 참조한다.

nsswitch.conf 파일을 올바르게 설정하고 활용하는 몇 가지 팁을 정리했다.

  • 항상 files를 마지막 옵션으로 지정하자. 특히 passwd, shadow, hosts 자료에 해당하는 팁이다. 파일로 참조하지 않는다면 네트워크 장애가 생길 경우 시스템 전체가 사용 불능인 상태가 되며, NIS 시스템에 문제가 생길 경우 심지어 루트 사용자조차도 로그인을 거부당할 가능성이 있기 때문이다.
  • 파일 자료는 중요한 로그인, 호스트, 기타 정보를 포함하도록 주의를 기울이자.
  • 인터넷에 연결된 기계에서, NIS를 사용한 포워딩 시스템에 의존하는 대신 인터넷 기반 이름 탐색을 위한 서비스인 DNS를 활용하는 편이 좀 더 효율적이다.

이런 팁을 지키면 시스템이 잠기는 바람에 로그인이 불가능한 상황을 피할 수 있다.


NFS로 파일 공유하기

NFS(Network File System) 역시 썬 마이크로시스템즈가 개발했으며, 기계 사이에 파일을 공유하는 방법으로 자리 잡고 있다. NFS로 디렉터리를 공유할 때, 지역 디스크인양 다른 기계의 디렉터리를 마운트할 수 있다. 동일한 보안, 파일 접근 권한, 기타 자료가 NFS 클라이언트와 NFS 서버 사이에 복제된다. 이런 이유 때문에 NIS로 사용자 자료 역시 공유해야 한다. 사용자 ID, 그룹 ID, 다른 정보가 NFS 공유 파일에 똑같이 적용되기 때문이다.

일반적으로 NFS 서버 시작에 앞서 먼저 공유할 디렉터리 설정부터 해야 한다. 리눅스에서, 이런 작업은 /etc/exports 파일을 수정하면 끝난다. /etc/exports 파일은 (보안 제약과 같은) 공유 디렉터리를 위한 디렉터리와 옵션을 정의한다. 예를 들어, 네트워크 내부에 있는 기계에만 /export/data를 공유하도록 하려면, 다음과 같이 지정한다.

/export/data *.mcslp.pri(rw,sync) *(sync)

rw 옵션은 네트워크에 있는 클라이언트에게 읽기/쓰기 공유 권한을 설정한다. sync 옵션은 원격 마운트가 파일 시스템 자료를 서버와 동기화하도록 만든다.

솔라리스를 사용하면, /etc/dfs/dfstab 파일을 사용해 NFS로 특정 디렉터리를 공유하도록 공유 명령을 지정한다. 모든 네트워크 내부 클라이언트에게 읽기 쓰기 권한으로 동일한 디렉터리를 공유하려면 다음과 같은 명령을 내린다.

share -F nfs -o rw /export/data

AIX를 사용하면 smit 도구로 특정 디렉터리를 공유하며, HP-UX를 사용하면 SAM 도구로 특정 디렉터리를 공유하자.

운영체제에 무관하게, 일단 파일과 환경 설정이 끝나고 나면, 가장 먼저 NFS 서버를 시작한다.

클라이언트 쪽에서는 NFS 클라이언트 프로세스만 띄우면 된다. 그리고 나서 mount 명령을 사용해 NFS 파일 시스템을 마운트한다. 다음과 같이 서버 이름, 콜론, 원격 디렉터리 전체 경로를 적어주면 된다.

$ mount bear:/export/data /mnt/data

컴퓨터 시작 과정에서 NFS 디렉터리를 마운트하기 위해 /etc/fstab이나 /etc/vfstab 파일을 통해 NFS 디렉터리를 자동으로 마운트하도록 동일한 형식을 사용할 수 있다. 하지만 더 좋은 방법인 automount 시스템을 사용해 서버에서 성능을 최대로 이끌어내는 동시에 마운트 과정을 단순하게 만들어보자.


automounter 활용하기

NFS 확장 기능으로 automount 시스템을 고려하자. 이 컴포넌트는 참조되는 시점에서 디렉터리를 자동으로 마운트한다. 예를 들어, /mnt/data로 NFS 공유를 자동 설정해 놓으면, 다음과 같이 입력한 순간 /mnt/data와 연결된 NFS 공유가 자동으로 마운트되어 사용이 가능해진다.

$ cd /mnt/data

계속해서 디렉터리를 사용하지 않으면, 디렉터리는 언마운트된다. automounter는 사용자 디렉토리를 공유할 때 특히 유용한데, 각 사용자가 특정 기계에 로그인하는 시점에 원격 NFS 서버에서 자신의 홈 디렉토리를 마운트해 사용하도록 지원하기 때문이다.

automounter는 NFS 서버에서 원격 디렉토리를 마운트하는 방식을 단순하게 만들 뿐만 아니라 NFS 공유를 활발하게 사용하지 않는 클라이언트에 통계와 접속 유무를 제공하는 데 걸리는 서버 부하를 줄이는 데 기여한다.

여러 유닉스 기계에 automount 기능이 들어있다. 리눅스를 사용하면, 커널에서 automounting을 설정하고 automount 설정과 시작에 앞서 다시 시작해야 한다. automounter를 설정하려면, 먼저 /etc/auto.master나 /etc/autofs/auto.master 파일을 편집해야 한다. 이 파일은 최상위 공유 집합을 정의하고, 사상 파일에 대한 최상위 디렉터리를 지정한다. 예를 들어, 다음 파일은 /home과 /mnt를 사상하는 방법을 보여준다.

/home /etc/autofs/auto.home
/mnt  /etc/autofs/auto.mnt

/mnt 디렉터리와 대응하는 사상을 정의한 다음에, 하위 디렉터리와 사상 대상인 NFS 디렉터리를 설정한다. 예를 들어, Listing 3은 mnt 사상을 정의한 내용이다.


Listing 3. mnt 사상을 정의한 내용
                
applications     atuin:/Volumes/Shared1/Applications
archiveprepare   atuin:/Volumes/Shared1/ArchivePrepare
backupprepare    atuin:/Volumes/Shared1/BackupPrepare
build            atuin:/Volumes/Shared1/Build
correspondence   atuin:/Volumes/Shared1/Correspondence
devprojects      atuin:/Volumes/Shared1/DevProjects
docarchive       atuin:/Volumes/Shared1/DocArchive
incoming         atuin:/Volumes/Shared1/Incoming
information      atuin:/Volumes/Shared1/Information

Listing 3에서 보여준 목록은 /mnt 사상이므로, 사용자가 /mnt/applications를 방문할 때 automouner가 사상된 NFS 공유 디렉터리를 마운트하는 명령을 수행한다. 이 경우에는 atuin:/Volumes/Shared1/Applications를 마운트한다.

그리고 나서 유닉스에서 automount 데몬을 시작할 필요가 있다. 대다수 유닉스 기계에서는 automount나 automountd라는 이름이 붙어있는 반면에 대다수 리눅스 기계에서는 autofs라는 이름이 붙어 있고, 다음과 같이 시작한다.

/etc/init.d/autofs start


시각 동기화하기

NIS와 NIS+를 사용할 때, 서버 사이에 시각을 올바르게 유지하는 편이 바람직하다. NIS나 NIS+에서 시각 동기화가 특히 중요한 이유는 데이터베이스를 최신으로 유지하기 위해 정보 배포 동안에 시각 정보를 사용하기 때문이다. 기계가 동기화되어 있지 않은 상태에서, 슬레이브는 마스터에서 정보를 가져오지 않을지도 모르며, 마스터 쪽에서 갱신을 거부할지도 모른다.

가장 손쉬운 시각 동기화 기법은 NTP(Network Time Protocol)로, 대다수 리눅스 기계에 표준이나 설치 가능한 컴포넌트로 자리잡고 있으며, 유닉스 기계에서도 점차 표준 컴포넌트가 되고 있다.

NTP 관련 패키지를 내려받아 컴파일하거나 독자적으로 패키지를 설치했다면, 핵심 컴포넌트인 ntpd 데몬을 확인할 수 있다. ntpd 데몬은 배경 작업으로 동작하며, 시각 정보를 제공하거나 지정된 서버에서 지역 기계로 시각을 자동으로 맞추도록 설정할 수 있다.

NIS를 사용한다면, NIS 마스터를 내부 네트워크 시각 정보 제공 서버로 설정하자. 내장 시계를 활용하거나 인터넷에 접속했을 경우 여러 공개 서버 중 하나에서 시각 동기화 정보를 얻도록 설정하자. 예를 들어, 우리 ISP는 NTP 서버를 제공한다. /etc/ntp.conf 환경 설정 파일에 다음과 같이 ISP에서 제공하는 NTP 서버 이름을 추가하자.

server ntp0.zen.co.uk minpoll 12 maxpoll 17

네트워크에 물린 각 NIS 서버와 클라이언트 쪽에서 시각 동기화가 가능하게 하려면, NIS 마스터와 통신하도록 다음과 같이 동일한 /etc/ntp.conf 파일을 설정하면 끝난다.

server atuin.mcslp.pri minpoll 12 maxpoll 17

양쪽 시스템 설정이 끝나면 NIS 마스터에서 NTP 데몬을 다음과 같이 시작하자.

/etc/init.d/ntp start

그리고 나서 각 NIS 슬레이브 서버와 클라이언트에서도 이 과정을 반복한다.


정리

정보를 주고받고 공유하는 작업은 유닉스와 리눅스 시스템 통합 과정을 좀 더 쉽게 만들어준다. 일단 로그인과 다른 정보를 공유하면, 사용자는 기계마다 암호를 외우지 않고서도 유닉스와 리눅스 기계에 접속해 사용할 수 있다. 로그인과 함께 NFS 공유를 결합하면, 파일 공유가 가능해지며, automounter를 사용해 사용자 개별 홈 디렉터리를 공유하면, 동작 중인 운영체제나 기계에 무관하게 파일 시스템을 통해 각자 파일과 자원을 계속 사용할 수 있다.


참고자료

교육

토론

필자소개

Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.

잘못된 도움말 신고

부정사용 신고

감사합니다. 이 항목은 운영자가 관심을 표시했습니다.


잘못된 도움말 신고

부정사용 신고

제출실패 신고. 나중에 다시 실행해주세요.


디벨로퍼웍스 로그인


IBM ID가 필요하세요?
IBM ID를 잊으셨습니까?


비밀번호를 잊으셨습니까?
비밀번호 변경

developerWorks 이용 약관에 동의하시는 경우 제출을 클릭하십시오. 이용 약관.

 


developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

화면상에 보여지는 닉네임을 정하세요.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

3개의 &이나 대쉬를 포함해주시고 31글자내로 제한해주세요.


developerWorks 이용 약관에 동의하시는 경우 제출을 클릭하십시오. 이용 약관.

 


아티클 순위

의견

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=20
Zone=AIX와 UNIX, 리눅스
ArticleID=318933
ArticleTitle=유닉스와 리눅스를 함께 어울리게 만들기
publish-date=07082008
author1-email=mc@mcslp.com
author1-email-cc=

태그

Help
검색 필드를 사용하여 My developerWorks 내에서 해당 태그가 사용된 모든 종류의 컨텐츠를 검색하십시오.

태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.

인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.

내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.

검색 필드를 사용하여 My developerWorks 내에서 해당 태그가 사용된 모든 종류의 컨텐츠를 검색하십시오. 인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다. 내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.