반응형
원문 : http://www.devx.com/Java/Article/29208


Struts에서 Spring으로의 이주 가이드.

당신은 이 글을 통해 Struts애플리케이션에서 Spring MVC애플리케이션으로 변형하는 방법뿐 아니라 두 프레임워크사이의 논리적인 맵핑과 Struts개념을 Spring MVC개념에 관련시키는 수단을 배울것이다.


사실 Struts프레임워크는 기술발전이나 채택이 감소하기 시작하고 있다고 몇몇 사람들이 제기한다. 사실 Struts의 책임 개발자인 Craig McClanahan또한 Struts사용자에게 새로운 웹 프레임워크로의 이전을 권하고 있는 상황이다. 반면에 J2EE웹 공간에서, Spring MVC는 꾸준한 채택과 자바 개발자의 주의를 끌고 있다. 가장 인기있는 Spring프레임워크는 잘 디자인되었으며, 잘 만들어졌고, 혁신적이다. 그래서 많은 Struts사용자는 Struts를 위한 대체 프레임워크처럼 Spring을 MVC를 사용할것이다.


이 글은 Struts애플리케이션을 Spring MVC로 이전하길 원하는 개발자들을 도와준다. 그리고 다음의 두가지 핵심부분으로 나누어져있다.

Struts와 Spring MVC프레임워크의 기본 개념사이의 논리적인 맵핑.
이전 대체물을 위한 기본적인 추천사항들.

논리적인 맵핑 : 다른 프레임워크간의 유사함.
Struts와 Spring은 MVC패턴 구현에서 본질적으로 유사하다. 둘다 핵심 J2EE컴포넌트인 Servlet과 JSP에 기반한 모델2 타입의 개발방식을 주로 할려는 경향이 있다. Struts에 친숙한 개발자는 하나의 프레임워크에서 다른것으로 개념적으로 쉽게 이주할수 있다. 두가지 프레임워크 모두 View, Controller, Model의 역활을 제공하는 컴포넌트를 명백하게 서술하고 있다. 유사성은 구현레벨에서 멈춘다. Struts디자인은 각각의 사용자지정 action이 Struts Action컴포넌트의 구조적인 상속이 된다는것을 의미하는 견고한 상속에 기반을 둔다. Spring컨트롤러는 인터페이스이기 때문에, 어떠한 컴포넌트도 컨트롤러의 역활을 수행할수 있다. 이것은 애플리케이션 디자이너에게 컴포넌트 디자인의 좀더 나은 유연함을 제공한다.


프레임워크 컴포넌트 레벨에서 Struts는 Form Beans (정적이거나 동적인), Actions, Action Mappings, Action Forwards, 그리고 Request Processors와 같은 Struts 특유의 객체 사용을 요구한다. Spring MVC는 주요한 컴포넌트가 인터페이스처럼 정의된것처럼 좀더 유연하다.


Struts는 오직 웹 프레임워크일 뿐이다.
Struts는 애플리케이션 개발에서 오직 presentation계층에만 할당한다. 반면에 Spring MVC는 비지니스 컴포넌트에다가 Spring 기업용 개발의 다른 부분을 관리하는 Spring 프레임워크의 다른 부분과 완벽하게 통합되는 Spring프레임워크의 주요한 부분일뿐이다. 이제 좀더 상세하게 프레임워크 컴포넌트를 보자.


Struts Actions는 대략 Spring Controllers이다.
Struts에서 Action은 프레임워크의 핵심 "processing"객체이다. 그것들은 MVC패턴에서 컨트롤러의 역활을 수행한다. Struts Actions의 Spring이 가진 대안은 Controller인터페이스이다. 반면에 Controller는 Spring에서 사용자 입력을 처리하고 View컴포넌트로 전달한다. Struts Actions과 Spring Controller사이의 가장 명백한 차이점은 Actions는 추상 클래스이고 Controllers는 인터페이스라는 것이다. Spring MVC 컨트롤러처럼 설정되기 위해서, 객체는 오직 다음의 메소드를 구현할 필요가 있을것이다.


ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception; 


이 디자인(인터페이스에 의한 디자인)은 애플리케이션과 프레임워크간의 커플링을 최소화한다. 또한 이것은 Controllers의 디자인에서 구조적으로 좀더 유연성을 제공한다. 이것을 염두해 두고, Struts에서 Spring으로의 가장 간단한 중계역활을 하는 이전(transition) 단계는 Action을 다시 쓰는 것이다. 그래서 그것들은 Controller인터페이슬ㄹ 구현하고 존재하는 코드를 재사용하는것이다. 이것은 애플리케이션 작동을 유지하는 동안 모든 Struts의존성의 제거를 증가시키는것을 허용한다.


Spring은 다른 Action대체물도 제공한다. 많은 수의 프레임워크가 제공하는 Controller구현물은 가장 공통적인 웹애플리케이션 작업에 대응된다. 몇몇 제공되는 Controller는 당신이 친숙한 Struts Action에 좀더 특성화된 것에 대응된다. 예를 들어, 당신이 DispatchActions을 사용한다면, MultiActionControllers와 좀더 잘 다듬어진 AbstractWizardFormControllers가 도움을 줄것이다. 다른 Controller구현문은 Spring MVC에 딸려나온다.


Action Forms이 없다.
Spring프레임워크내에서 가장 크고 가장 긍정적인 차이점중에 하나는 특성화된 ActionForm객체가 없다는 것이다. 프레임워크는 HTTP폼 값을 직접적으로 POJO에 바인딩하는것을 지원한다. 이 기능은 생성하고 유지할 클래스의 수를 제한하여 애플리케이션 유지관리를 단순화한다. 이 경우, 이전(migration)은 폼빈즈를 삭제하고 직접적으로 도메인 객체를 사용하는것을 의미한다. 어쨌든, 이것은 당신이 폼입력과 도메인 객체간의 맵핑처럼 Form Bean객체를 사용할수 있다면 필수단계는 아니다. Spring MVC에서, AbstractFormController구현물을 확장하는 특수한 목적의 Controllers는 폼을 지지하는 빈즈를 지원한다. AbstractFormController의 사용자지정 하위클래스는 폼객체처럼 폼을 지지하는(Command) Beans를 사용한다. 다시 말해, 이러한 빈즈를 정의하는 요구사항은 없다. Command객체는 java.lang.Object의 어떠한 하위클래스도 될수 있다.


ActionForwards vs. ModelAndView
Struts ActionMapping에서, 객체는 표현자원(Actions, JSPs, Tiles, HTML 파일들 등등.)을 가리킨다. Spring MVC에서 ActionMapping에 대해 가장 가까운 의미의 컴포넌트는 ModelAndView인터페이스이다. Spring Controllers는 사용자에 의해 구현될수 있는것처럼 ModelAndView인터페이스의 구현물을 반환한다. 또는 당신이 원한다면 Spring MVC에 의해 제공되는 ModelAndView구현물을 사용할수도 있다. 내포하는 이름처럼, ModelAndView객체는 Model과 View컴포넌트를 가진다. Model컴포넌트는 View컴포넌트를 통해 표시되기 위한 비지니스 객체를 포함한다. 시나리오에 따르면, ModelAndView구현물은 포함된 어떠한 Model컴포넌트를 가지지 않는다. 그것들은 아마도 실질적인 View컴포넌트(JSP, XSLT, Tiles, HTML, XML, 등등)의 몇몇 형태로 이끌것이다. Controller구현물에서 처럼, 나는 Spring MVC가 제공하는 Model의 구현물과 View인터페이스 그리고 View해석자(Resolver)를 조사하는것을 강력히 권한다.


사용자지정 JSP 태그들
Spring MVC는 표준 JSP태그 라이브러리의 의미있는 힘을 신뢰한다. Struts와는 달리, Spring MVC는 HTML, logic, 또는 bean처리를 위한 분리된 태그 라이브러리를 제공하지 않는다. 이것은 Command객체에서 Web form으로의 바인딩을 가능하게 하는 작은 태그라이브러리만을 제공한다. 당신은 다른 모든 작업을 위해 표준적인 템플릿 라이브러리(JSTL)를 사용할것이다.


유효성체크(Validation)
만약 당신이 Struts의 Commons Validator을 사용한다면, 당신은 Spring내에서 완벽하게 재사용할수 있을것이다. Spring 1.2는 Commons기반 유효성체크를 지원하지 않지만 Spring MVC의 "sandbox"버전은 Commons Validator마크업 (validator.xml 과 validation-rules.xml)으로 쓰여진 유효성체크 정의의 재사용을 지원한다. 유효성체크 선언를 가진 당신의 XML파일을 버리지 마라. 그것들은 Spring내에서 재사용가능할것이다.


Error 와 Validation Messages
좀더 좋은 소식이 있다. Spring은 동일한 형태로 Struts message번들을 인식한다. Spring MVC내 존재하는 Message자원들을 재사용하기 위해서, 당신은 Spring MVC 설정파일내 messageSource가 다음처럼 설정한다.


<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
 <property name="basename">
  <value>resources.ApplicationResources</value>
 </property>
</bean> 


또한, 당신은 Controller구현물내 messageSource프라퍼티로써 당신의 Controller처럼 이것을 사용할 필요가 있다. 요구되는 변경사항은 없다.


Dispatcher Servlet
Spring MVC는 Request Processor/Action Servlet의 자신만의 버전을 가진다. 이것은 URL표시그룹으로 맵핑되는 DispatcherServlet이다. Dispatcher Servlet의 개념을 이해하기 위해서, Controller를 Spring MVC내 설정하는 방법을 보자.


설정파일들
Struts사용자라면, 당신은 모든 forward, action mapping, form definition 그리고 플러그인 선언등을 가지는 적어도 하나의 struts-config.xml파일을 사용한다. Spring MVC에서, 모든 웹 애플리케이션관련 컨트롤러 선언은 Spring Beans처럼 설정된다. 하나이상의 Dispatcher Controller는 웹자원을 위한 모든 요청을 적당한 Controller로 보낸다. 예를 들면, 만약 당신이 ".do"애플리케이션을 Spring MVC애플리케이션으로 다시 맵핑시키길 원한다면, 당신은 애플리케이션의 web.xml에 다음처럼 서블릿 맵핑을 등록하라. (나는 당신이 .do 확장자를 사용하는것을 실질적으로 권하지 않는다. Struts만 사용하는 규칙처럼 ".do"를 남겨두라.)


<servlet>
 <servlet-name>applicationDispatcher</servlet-name>
 <servlet-class>
  org.springframework.web.servlet.DispatcherServlet
 </servlet-class>
 <load-on-startup>1</load-on-startup>
</servlet>

        ...

<servlet-mapping>
 <servlet-name>applicationDispatcher</servlet-name>
 <url-pattern>*.do</url-pattern>
</servlet-mapping>   


지금 당신은 Spring MVC Controller선언을 가진 Spring 설정파일(applicationDispatcher-servlet.xml)을 가진다. "-servlet.xml"는 applicationDispatcher파일을 위한 접미사이다. 이것은 Spring MVC맵핑파일을 자동 리로드하는 DispatcherServlet을 가능하게 하는 Spring MVC규칙이다.


Spring MVC내에서 웹 action을 적당한 컨트롤러로 맵핑하는것은 매우 쉽다. 이것은 Spring애플리케이션의 일부처럼 같은 "wiring"형태로 수행된다. 다음의 예제는 URL expression /showCatalog.do를 Controller showCatalog로 포워드하는 방법을 보여준다.


<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
 <property name="mappings">
  <props>
          <prop key="/showCatalog.do">showCatalog</prop>
  </props>
 </property>
</bean> 


Controller showCatalog는 Controller인터페이스를 구현하는 클래스에 의해 구현된 다른 빈처럼 설정될것이다. 이 예제에서, showCatalog는 URL요청을 카테고리로 명명된 ModelAndView컴포넌트로 포워드하는 간단한 포워딩 컨트롤러에 지나지 않는다.


<bean id="showCatalog" name="showCatalog"
class="org.springframework.web.servlet.mvc.ParameterizableViewController">
 <property name="viewName" value="catalog"/>
</bean> 


Struts에서 Spring MVC로의 이전 경로.
Struts애플리케이션을 Spring MVC로 이전하기 위해서는 3가지 접근법이 있다. 몇몇은 애플리케이션을 점차적으로 이전할것이다. 다른것들은 Struts프레임워크를 완벽하게 포기하고 완전히 다시 쓰는 작업을 수행할것이다. 접근법들은 아래에서 개요를 말하고, 이전의 완벽함 순서대로 정렬된다.


1. Spring은 Struts컴포넌트를 가능하게 한다. 천천히 이전하길 원하는 사람들을 위해, 첫번째이고 완벽하게 이전에 따른 무리가 없는것은.? Spring Beans처럼 Struts Actions를 가능하게 하는것이다. 이것은 간단한 작업이고, Spring문서에 잘 설명되어 있다. 이것은 Struts코드에 대한 변경을 요구하지 않지만, 이것은 Spring Beans처럼 처리되기 위해 Struts Controller컴포넌트, Actions를 가능하게 한다. 이 처리로, Actions은 Spring Beans의 상태를 상속한다. 그러므로, Spring Controller처럼 많은 것을 보기 시작하라. 늦으면서 단계별로 현명한 이전은 이 처리로 가능하다. 각각의 Action은 애플리케이션 재작성과 현재 웹 연속물의 중단없이 Spring Controller에 의해 한번에 대체될수 있다.


2. Tiles를 사용하는 Spring Spring프레임워크에 의해 완전히 제공되는 다른 대체물은 순수한 "view" 프레임워크처럼 Tiles를 유지하는 동안 Spring MVC컴포넌트로 Struts Controller과 관련 컴포넌트(Actions, Form Beans, 등등)를 대체하는것이다. Spring MVC는 Tiles에 대한 특정 대안을 가지지 않는다. 그래서 구조는 Tiles에 대한 것을 유지하기로 결정하고 Spring MVC를 통해 그 작업을 하도록 만든다. 이 접근법의 하나의 심각한 단점은 당신이 웹애플리케이션내 두개의 다양한 웹 프레임워크를 효과적으로 유지관리하기 위해 유지관리를 위한 많은 노력과 두가지 프레임워크를 위한 추가적인 학습이 필요하다는 것이다.


3. 완전한 이전 완전한 이전은 Struts프레임워크의 모든 컴포넌트를 Spring MVC로 교체하는것을 의미한다. 이 처리의 마지막에는 Struts특성의 컴포넌트는 애플리케이션에 남지않는다.
반응형

'개발도 하냐?' 카테고리의 다른 글

웹접근성  (0) 2008.01.03
오픈아이디로 사용가능한 웹서비스  (0) 2007.07.27
사파리 윈도우용 출시  (0) 2007.07.03
미래를위한선택-웹호환성  (0) 2007.06.18
EMAIL 에러메세지  (0) 2007.04.19
반응형

FCKeditor java 버전 설치
- 환경
O/S : Window XP Professional
Servlet Engine : Tomcat 5.0.28
Character Set : UTF-8
IDE Tool : Eclipse 3.2
FCKEditor Version : 2.3.1( http://prdownloads.sourceforge.net/fckeditor/FCKeditor_2.3.1.zip?download )FCKEditor.Java Version 2.3
( http://sourceforge.net/project/showfiles.php?group_id=75348&package_id=129511 )
1. editor 폴더를 생성하고 톰캣 컨텍스트의 루트를 editor 폴더 경로로 지정
2. fckeditor 다운로드
2-1. http://www.fckeditor.net/download/ 에서 다운로드
2-2. editor 폴더에 다운로드 된 압축 파일의 압축을 풉니다.
2-3. 압축을 풀면 나오는 디렉토리인 FCKeditor 폴더를 editor 하위 폴더로 되게끔 이동합니다.


3. 톰캣을 가동한 후 FCKeditor\_samples\default.html 을 실행하여 fckeditor 를 실행


4. 그러나 이미지 업로드를 할려고 서버 보기를 할 경우 에러가 발생합니다.


5. java 버전용 fckeditor 를 editor 폴더로 다운로드(FCKeditor-2.3.zip)
5-1. http://sourceforge.net/project/showfiles.php?group_id=75348&package_id=129511 에서 다운로드
5-2. editor 폴더에 다운로드 된 압축 파일의 압축을 풉니다.


6. 지정폴더\editor\FCKeditor-2.3\web 하위에 있는
_samples 폴더와 WEB-INF 폴더를 각각 이동.
6-1. 2번에서 만들어진 \editor\FCKeditor\_samples 폴더에
\editor\FCKeditor-2.3\web\_samples 폴더를 붙여넣기 합니다.
6-2.  \editor\WEB-INF 폴더에 \editor\FCKeditor-2.3\web\WEB-INF 폴더를 붙여넣기 합니다.


* 새로운 컨텍스트라면 web.xml 을 그대로 덮어씌운 후 복사하고,
기존에 컨텍스트에 다른 체계가 돌아가 있다면 web.xml 내용 중 <web-app> 부분을
기존 사용중인 컨텍스트에 web.xml 에 붙여넣기 합니다.
( load-on-startup 이 이미 있다면 숫자를 변경함 )

완료하면 폴더 구조는 다음과 같습니다.
( UserFiles 디렉토리는 사용자가 업로드한 이미지 저장 디렉토리입니다. )


* 톰캣 리스타트시에 콘솔 창에 다음과 같이 업로드 제한 파일 확장자 리스트가 나옵니다.
( web.xml 파일에 DeniedExtensionsFile 이란 param-name 으로 지정되어 있습니다. )


7. jsp 샘플을 실행
그러나 다음과 같이 fckeditor.html 파일을 찾을수 없다는 메시지가 뜹니다.


\editor\FCKeditor\_samples\jsp\sample01.jsp 내용을 보면
oFCKeditor.setBasePath( "/FCKeditor/" ) ;
위와 같은 부분이 있습니다.


컨텍스트의 루트 폴더가 FCKeditor 이라면 에러 없이 수행되었겠지만
루트가 editor 폴더로 지정되어 있으므로
oFCKeditor.setBasePath( "/editor/FCKeditor/" ) ;
위처럼 수정해주면 제대로 수행되는 것을 확인할수 있습니다.


7-3. 이미지 버튼을 눌러서 서버보기를 눌러보지만 4. 처럼 스크립트 오류가 발생합니다.


8. sample02.jsp 의 태그 라이브러리를 이용한 파일 브라우저 경로 수정
8-1. \editor\FCKeditor\_samples\jsp\sample02.jsp 를 보면 7. 처럼 fckeditor.html 을 찾을수 없다는 메시지가 뜹니다.
<FCK:editor id="EditorDefault" basePath="/FCKeditor/"
위 부분에서 basePath 를 현재 테스트 경로에 맞게끔
<FCK:editor id="EditorDefault" basePath="/editor/FCKeditor/" 로 수정 후 sample02.jsp 를 수정하면
에디터는 잘 나오나 역시 이미지 뷰어나 업로드 부분은 작동하지 않습니다.

sample02.jsp 에선 다음과 같이 브라우저 URL 과 업로드 URL 을 정의한 부분을 볼수 있습니다.
imageBrowserURL="/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/jsp/connector"
linkBrowserURL="/FCKeditor/editor/filemanager/browser/default/browser.html?Connector=connectors/jsp/connector"
flashBrowserURL="/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Flash&Connector=connectors/jsp/connector"
imageUploadURL="/FCKeditor/editor/filemanager/upload/simpleuploader?Type=Image"
linkUploadURL="/FCKeditor/editor/filemanager/upload/simpleuploader?Type=File"
flashUploadURL="/FCKeditor/editor/filemanager/upload/simpleuploader?Type=Flash"


editor 폴더 하위에 FCKeditor 폴더가 위치한 구조이니 /FCKeditor/editor... 부분 앞에
/editor/FCKeditor/editor... 형식으로 수정하고,


web.xml 의
<servlet-mapping>
 <servlet-name>Connector</servlet-name>
 <url-pattern>/editor/filemanager/browser/default/connectors/jsp/connector</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>SimpleUploader</servlet-name>
 <url-pattern>/editor/filemanager/upload/simpleuploader</url-pattern>
</servlet-mapping> 


위 url-pattern 경로대로 Connector 부분과 UploadURL 을 현재 경로를 예를 들어 재구성하자면
다음과 같이 수정하여 sample02.jsp 을 작성하면 됩니다.
imageBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
linkBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
flashBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Flash&Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
imageUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=Image"
linkUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=File"
flashUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=Flash"


위 URL은 web.xml 의 url-pattern 과 매핑된다는 점을 이해하셔야 합니다.
이런 특징을 통하여 경로를 판별할수 있습니다.


8-2. 이미지링크,플래쉬 브라우저 및 업로드가 제대로 동작하지 않을 경우...

8-2-1. browser.html 파일의 경로가 틀렸을 경우
basePath 만 수정한 후 위 8-1. 에서처럼 경로를 수정하지 않을 경우
다음과 같은 화면을 볼수 있습니다.


8-2-2. Connector 부분의 경로가 틀릴 경우
Connector 의 경로는 수정하지 않은채 browser.html 의 경로만 옳바르게 설정할 경우
다음과 같은 화면을 볼수 있습니다.


* Connector 의 경로는 web.xml 의 Connector 의 url-pattern 과 관련이 되어있습니다.
8-1. 에서 보신 web.xml 처럼 /editor/filemanager/browser/default/connectors/jsp/connector 으로
지정되어 있따면 Connector 의 주소는
http://서버url/컨텍스트명/editor/filemanager/browser/default/connectors/jsp/connector 이 됩니다.



위 화면처럼 파일을 찾을수 없다는 화면이 아닌 다른 화면이 나오게 되면 맞는 경로이므로
Connector 부분은 http://서버url/ 을 제외한 나머지 주소를 기술하면 됩니다.
( 8-1. 의 Connector 주소 설정 참조 )


* 옳바른 주소 설정에도 불구하고 위 화면에서처럼 Connector 을 브라우저에서 실행했을 때
다른 에러가 발생한다면 XML 을 생성하는 xalan 콤포넌트가 존재하는지 의심해봐야 합니다.


왜 에러가 발생하는지 보기 위한 테스트URL)
http: //서버url/컨텍스트명 /editor/filemanager/browser/default/connectors/jsp/connector?Command=GetFoldersAndFiles&Type=Image&CurrentPath=/


위 화면에서처럼
javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
에러가 발생한다면 Xerces-J-tools의 xalan.jar 를(http://www.apache.org/dist/xml/xerces-j/)

찾아 다운로드 하여 \WEB-INF\lib 폴더에 넣은 후 톰캣 재가동후 새로운 브라우저에서
테스트 URL 을 확인해보면 다음과 같이 에러 없이 XML 화면이 나오는 것을 확인할수 있습니다.


8-2-3. 업로드 URL 의 확인
Connector 와 마찬가지로 web.xml 의 SimpleUploader 의 url-pattern 의 영향을 받습니다.
위 web.xml 에선 url-pattern 이 /editor/filemanager/upload/simpleuploader 이므로
테스트 URL)
http://서버url/컨텍스트명/editor/filemanager/upload/simpleuploader 을 쳤을 경우 다음과 같은 화면이 나와야 정상입니다.


위 결과대로 나온다면 image,link,flash UploadUrl 을 설정하면 됩니다.( 8-1. 의 각 UploadUrl 확인 )


9. 테스트
이미지를 업로드하고, 목록에 정상적으로 출력된다면 모든 설치가 성공적으로 완료된 것입니다.


10. 샘플이 아닌 기존 체계에 fckeditor 를 적용할 경우.
태그 라이브러리 사용을 위한
<%@ taglib uri="http://fckeditor.net/tags-fckeditor" prefix="FCK" %> 를 페이지 상단에 삽입 하고,
<TEXTAREA></TEXTAREA> 부분에 sample02.jsp 의 <FCK:editor ~ </FCK:editor> 부분을 복사하여 붙여넣기 합니다.
기본 sample02.jsp 에는 <FCK:editor id="EditorDefault" 처럼 id 가 EditorDefault 로 되어있는데
만약 <TEXTAREA name = "contents" 와 같이 name 이 contents 였다면
<FCK:editor id="contents" 로 지정하면 받는 부분에서 contents 로 받을 수 있습니다.


예)
- \editor\board\create_form.jsp(UTF-8 로 작성)

<%@ taglib uri="http://fckeditor.net/tags-fckeditor" prefix="FCK" %>

<%@ page contentType = "text/html;charset=utf-8" %>
<HTML>
<HEAD>
<TITLE>글 입력 폼</TITLE>
<META http-equiv = "Content-Type" content = "text/html;charset=utf-8" />
<SCRIPT>
 function send()
 {
  create_form.submit();
 }
</SCRIPT>
</HEAD>
<BODY>
<FORM name = "create_form" method = "post" action = "./create.jsp">
 <FCK:editor id="contents" basePath="/editor/FCKeditor/"
  imageBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
  linkBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
  flashBrowserURL="/editor/FCKeditor/editor/filemanager/browser/default/browser.html?Type=Flash&Connector=/editor/editor/filemanager/browser/default/connectors/jsp/connector"
  imageUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=Image"
  linkUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=File"
  flashUploadURL="/editor/editor/filemanager/upload/simpleuploader?Type=Flash">
  This is some <strong>sample text</strong>. You are using <a href="http://www.fredck.com/fckeditor/">FCKeditor</a>.
 </FCK:editor>
</FORM>
<INPUT type = "button" onClick = "return send()" value = "전송">
</BODY>
</HTML>


- \editor\board\create.jsp(UTF-8 로 작성)

<%@ page contentType = "text/html;charset=utf-8" %>
<%
 String contents = request.getParameter("contents");

 contents = new String(contents.getBytes("8859_1"), "UTF-8");
%>
<HTML>
<HEAD>
<TITLE></TITLE>
<META http-equiv = "Content-Type" content = "text/html;charset=utf-8" />
</HEAD>
<BODY>
<%= contents %>
</BODY>
</HTML>


11. 몇가지 Tip.
11-1. 공백 값 입력을 방지하기 위해선 스크립트를 다음과 같이 수정합니다.

/**
 * 데이터 전송전 체크
 */
function send()
{
 var oEditor = FCKeditorAPI.GetInstance('contents') ;

 var div = document.createElement("DIV");
 
 div.innerHTML = oEditor.GetXHTML();

 if( isNull( div.innerText ) )
 {
  alert("내용을 입력하세요."); 
  oEditor.Focus();
  return false; 
 }

 create_form.submit();
}

/**
 * 정규표현식을 이용한 공백 체크
 */
function isNull( text ) 

 if( text == null ) return true; 

 var result = text.replace(/(^\s*)|(\s*$)/g, ""); 

 if( result ) 
  return false; 
 else 
  return true; 
}



11-2. 페이지 로딩시 바로 포커스를 주고 싶다면
\editor\FCKeditor\fckconfig.js 의 FCKConfig.StartupFocus 의 값을 true 로 변경하거나

태그라이브러리 옵션으로 startupFocus="true" 를 설정합니다.


11-3. 읽기 전용으로 변환하고 싶다면

var oEditor = FCKeditorAPI.GetInstance('contents') ;
oEditor.EditorDocument.body.contentEditable = false;
oEditor.EditorDocument.body.unselectable = true;


11-4. 기타 환경 설정은 fckconfig.js 파일을 참조하고 아래 사이트를 참조하시기 바랍니다.
http://sourceforge.net/forum/forum.php?forum_id=257180 ( fckeditor help 포럼 )
http://java.lin4u.com/my/index.php?category=&keyfield=title&keyword=fck&favorite ( 폰트 관련 참조 )
http://wiki.fckeditor.net/ ( fckeditor 위키 사이트 )

http://www.ghlab.com/blog/fckeditor/editor.zip ( 위 샘플들을 테스트한 컨텍스트 모든 파일들 )

출처 : Tong - 디트리히님의 자바관련통

반응형
반응형
사용자 삽입 이미지

PCI-X 와 PCI-Express 는 호환되지 않는다.

반응형

'삽질로그' 카테고리의 다른 글

자바에 사용되는 용어들  (0) 2007.07.26
FCKeditor java 버전 설치  (0) 2007.07.26
소프트웨어기술자 등급별 노임단가기준(2008)  (0) 2007.07.09
[펌]자격증정보  (0) 2007.07.09
오라클설정내용  (0) 2007.07.05
반응형

All about google!


특집 2부 성공의 원천, 탄탄한 기술 인프라 대해부


노희섭 | 시니어 개발자


구글은 처음부터 다른 서비스와는 차별되는 검색엔진과 아키텍처, 새로운 개념의 랭킹 모델들을 사용함으로써 그간의 웹 검색에 대한 개념을 크게 바꾸어 놓았다. 구글의 기술은 검색 업계에서 일하는 개발자들은 물론 일반 개발자들까지도 관심을 갖게 만드는데, 그 핵심은 탄탄한 기반 기술들과 그것들을 하나로 묶는 거대한 프레임워크에 있다. 이번 특집 2부를 통해 구글의 기술이 어떤 그림을 갖고 있는지에 대해 이해할 수 있는 시간이 될 것으로 기대한다.


구글 검색엔진


검색엔진은 대상이 되는 문서들을 수집하고, 수집된 문서들로부터 키워드를 추출하여 키워드-문서 간의 역 색인(inverted index)을 생성한 후, 사용자의 질의어(query)를 입력받아 해당 쿼리를 역 색인 구조를 찾아, 매칭된 문서를 결과로 반환해 준다. 구글의 검색엔진 역시 이러한 전통적인 검색엔진의 구조와 크게 다르지 않다. 구글의 검색엔진은 웹 문서들을 수집하고, 웹 문서들로부터 키워드를 추출하여 역 색인 구조를 생성하고, 생성된 역 색인 구조로부터 질의어를 매칭하여 결과를 반환해준다. 그러나 구글의 검색엔진은 기존의 검색 시스템과는 스케일이나 기능 면에서 많은 차이를 보여준다.


전통적인 키워드 매칭(keyword matching)을 기반으로 한 자동화된 검색엔진(automated search engine)은 몇 가지 약점을 갖고 있었다. 기본적으로 낮은 질의 매칭 결과가 너무 빈번하게 나타났다. 게다가 광고주들이 웹 문서에 포함된 키워드들을 조작해 엉뚱한 결과가 노출되도록 하는 것이 가능했다. 구글은 이런 문제점을 해결하기 위해 웹 문서의 하이퍼텍스트에 존재하는 부가적인 구조적 정보들을 사용하기 시작했다. 또한 방대한 웹 문서 데이터들을 처리하기 위해 매우 거대한 스케일의 검색 아키텍처를 구축했다.


구글 검색엔진의 지향점


웹을 효율적으로 검색하기 위해서는 몇 가지의 필수적인 기술들이 요구된다. 웹 문서들을 신속하고 효율적으로 수집하고, 수집된 데이터들을 최신의 상태로 유지하기 위한 크롤링(crawling) 기술, 대용량 데이터 처리를 위해 효율적으로 공간을 사용할 수 있는 색인 구조, 대용량 데이터를 신속하게 처리할 수 있는 색인기(indexer) 기술, 다량의 질의어들을 처리할 수 있는 질의어 분석/처리 시스템 등이 그것이다.


웹이 성장하면서 이러한 기술들이 감당해야 하는 목표들은 급격하게 상향 조정된다. 게다가 단순히 하드웨어의 발전만으로는 웹의 발전 속도를 감당할 수 없다. 하드웨어의 발전이 검색 시스템의 성능을 증가시키지만, 기본적으로 디스크 탐색 시간(disk seek time)이나 운영체제의 강력함(robustness)은 그렇게 주목할 만한 요소가 아니다. 구글 검색엔진은 극단적으로 큰 데이터 셋(data set)을 커버하기 위한 확장형 구조이며, 효율적인 색인 구조를 사용함으로써 데이터에 대한 신속하고 효율적인 액세스가 가능하도록 최적화된 구조이다.


웹 검색의 초창기에 많은 사람들이 검색엔진의 색인이 완전하고 무결성을 갖는다면 어떤 키워드에 대해서도 원하는 웹 문서를 검색할 수 있다고 믿었다. 그러나 웹 검색이 발전하면서 색인의 완전성과 무결성이 검색 품질을 좌우하는 유일한 요소가 아님이 밝혀졌다. 웹 검색은 일반적으로 입력되는 질의어에 대해 매칭되는 문서의 개수가 대단히 많다. 즉, 검색 대상이 되는 색인 내에서 검색 결과로 재현될 수 있는 비율이 대단히 크다. 그러나 일반적인 사용자들은 많은 검색 결과 중에서 상위의 일부 결과만을 보고 검색 결과의 모든 품질을 평가하려는 성향이 있다. 관련 있는 검색 결과가 상위에 랭크되어 있지 않고 몇 십 페이지 뒤에 랭크되어 있다면, 그것을 찾기 위해 페이지를 클릭할 사용자는 그렇게 많지 않다. 따라서 사용자의 만족감을 충족시키기 위해서는 극도로 높은 정확도에 기반한 검색 결과를 제공해야 한다. 정확도는 대용량 데이터의 검색 결과 품질을 좌우하는 요소이기 때문에, 재현율을 희생해서라도 정확도를 확보하는 것이 사용자들의 만족감을 위해 가장 중요하다⑴.


구글 검색엔진은 이러한 이유로 정확도 중심의 엔진으로 설계됐다. 구글의 정확도는 극도의 관계성 판단(relevance judgement)에 의해 산출되는데, 그 기반에는 링크 구조와 앵커 텍스트(anchor text)를 분석한 정보에 의한 질적인 필터링(filtering)이 존재한다. 구글은 이러한 정보들의 정확도를 높이는 두 가지 방법을 사용한다. 하나는 개별 웹 페이지의 품질 순위 할당을 위한 페이지 랭크 알고리즘이고, 다른 하나는 검색 결과 개선을 위한 앵커 텍스트 사용이다.


참고로, 구글이 검색엔진을 발표했던 초창기에는 또 한 가지 목표를 가지고 있었다. 그것은 대용량 웹 문서들과 대용량 트래픽을 감당할 수 있는 거대한 웹 시스템을 만들고, 실제로 많은 사용자들이 그것을 사용하면서 얻는 데이터(usage data)를 학술적인 연구에 제공하겠다는 것이었다.


구글 검색엔진의 특징


페이지 랭크의 사용


웹 문서에 존재하는 레퍼런스(링크) 그래프는 구글 검색엔진이 거의 최초로 주목한 요소이다. 페이지 랭크는 이러한 요소들로부터 사용자들이 생각하는 특정 페이지의 중요성(importance)에 부합하는 정확도(precision)의 객관적인 척도를 산출해낸다. 사용자들의 생각과 관련을 갖기 때문에 페이지 랭크는 웹 문서에 순위를 할당하는데 매우 합리적인 수단이다. 질의어를 문서 제목과 매칭되는지 여부만을 평가하는 단순한 텍스트 검색엔진에는 물론, 풀 텍스트(full text, 제목과 내용을 모두 포함) 검색엔진이나 페이지 랭크로 순위를 매기는 경우에도 상당한 성능을 보여주기 때문이다.


페이지 랭크는 한 페이지의 인용 횟수(백 링크, back link)를 카운팅하는 방식으로 계산된다. 한 페이지가 얼마나 많은 레퍼런스를 받고 있느냐의 수준이 그 페이지의 중요성이나 품질(quality)을 추정할 수 있는 요소로 간주된다. 페이지 랭크는 이 기본적인 아이디어를 확장하여 그 링크가 어떤 페이지에서 왔는지를 차별화하고, 링크하는 페이지에서 외부로 나가는 총 링크 개수로 노멀라이징(normalizing)을 수행했다.


페이지 랭크를 간략하게 정리하자면 다음과 같다. 페이지 A를 링크하는 다른 페이지들의 set을 (T1, T2, T3, ...., Tn)이라고 한다면, 파라미터 d는 0~1 사이의 값을 갖는다. C(A)는 페이지 A에서 외부로 나가는 아웃 링크(out link)의 개수이다. 이 때 페이지 A의 페이지 랭크 값 PR(A)은 다음과 같은 수식으로 표현된다.


페이지 랭크 PR(A)은 반복 알고리즘(iterative algorithm)으로 계산할 수 있으며, 그 값은 웹 링크를 노멀라이징해서 행렬로 바꾸었을 때 주 고유 벡터(principal eigen-vector)에 해당한다. 참고로 이것은 약 2600만 페이지의 페이지 랭크를 계산하는데 중급의 워크스테이션으로 수 시간 내에 연산이 가능한 수준이다.


페이지 랭크는 또한 사용자의 행동 패턴을 모델링하고 있다. 무작위로 선택한 하나의 웹 페이지에서 출발해서 백 버튼을 누르지 않은 상태로 계속 링크를 따라 네비게이션하는 랜덤 서퍼(random surfer)는 네비게이션 도중 지루해지면 다시 무작위로 페이지를 선택해서 네비게이션을 시작한다. 한 페이지의 페이지 랭크는 랜덤 서퍼가 그 페이지를 방문할 확률을 나타낸다. 페이지 랭크에서 주요 파라미터 중 하나가 댐핑 팩터(damping factor) d이다. 페이지 랭크에서는 파라미터 d를 특정 페이지 하나 또는 일련의 페이지에만 선택적으로 적용함으로써 개인화(personalization)를 가능하게 하며, 페이지에 대한 랭킹을 올리기 위한 속임수(abusing)를 사실상 불가능하게 만들 수 있다.


페이지 랭크의 직관적인 요소 중 또 하나는 페이지 랭크 값이 커지기 위해서는 많은 페이지가 어떤 한 페이지를 집중적으로 레퍼런스하고 있거나, 특정 페이지를 레퍼런스하는 페이지 자체의 페이지 랭크 값이 커야 한다는 것이다. 예를 들어 많은 페이지로부터 인용되고 있는 페이지는 살펴볼 만한 가치가 있는 것이고, 야후 같은 메이저 페이지(major page)에서 링크되고 있는 페이지는 그렇지 않은 페이지보다 중요하다고 간주되는 것이다. 페이지 랭크에 대한 더 자세한 내용은 뒤에서 따로 다루겠다.


앵커 텍스트의 사용


구글 검색엔진은 링크의 텍스트 자체를 특별하게 취급한다. 대부분의 검색엔진들은 링크의 텍스트(앵커 텍스트)를 링크를 담고 있는 페이지 자체의 정보 중 일부로만 취급하고 있지만, 구글의 검색엔진은 링크가 가리키고 있는 페이지를 링크의 텍스트와 연관시켜 처리한다. 이런 방법은 몇 가지 장점을 가진다. 첫째, 앵커 텍스트는 링크를 담고 있는 페이지에 대한 설명보다 링크가 가리키고 있는 페이지에 대해 더 정확한 설명을 담고 있는 경우가 대부분이다. 둘째, 일반적인 텍스트 검색엔진이 색인할 수 없는 이미지나 프로그램, 데이터베이스로의 앵커(링크)도 존재할 수 있다. 따라서 앵커를 사용한다면 크롤링되지 않는 웹 페이지들까지도 찾아낼 수 있다. 물론 이러한 링크에 걸려있는 대상들은 검색에 유효하지 않은 대상일 수 있으므로 사용자에게 보여주기 전에 먼저 유효성 검사를 통과해야 한다. 존재하지 않는 페이지를 가리키는 앵커의 경우에도 유효성 검사를 거치면 큰 문제는 없다.


앵커 텍스트를 그 앵커가 가리키는 페이지로 전파시켜 나간다는 아이디어는 World Wide Web Worm(WWWW) 검색엔진에서 먼저 구현됐다. 앵커 텍스트가 텍스트 이외의 데이터에 대한 검색을 용이하게 해 주었고, 검색엔진이 크롤링한 웹 문서보다 훨씬 더 많은 영역을 포괄하게 해주는 것에 이 아이디어의 유용성이 있다. 다만, 이를 위해서는 대용량 데이터 처리를 위한 구조가 필수적이다.


그 밖의 특징


페이지 랭크와 앵커 텍스트에 대한 접근 방식 외에도 구글 검색엔진은 몇 가지 특징을 갖는다. 첫째, 구글 검색엔진은 문서로부터 추출된 모든 키워드들에 대한 위치 정보(positional information)를 저장한다. 위치 정보의 저장은 검색 수행 시 근접도의 광범위한 사용을 가능케 한다. 둘째, 구글은 문서 내에서 추출된 키워드의 폰트 크기, 대소문자 여부 등에 대한 부수적이고 시각적인 세부 요소들을 추적한다. 폰트 크기가 큰 단어나 볼드체로 된 단어, 대문자로 작성된 단어의 경우에는 그렇지 못한 단어에 비해 더 높은 가중치(weight)가 부여된다. 셋째, 구글 검색엔진은 수집된 웹 문서를 완전한 HTML 형식으로 압축 저장하기 때문에 이를 활용할 수 있는 여지가 있다.


<그림 1> 구글 검색엔진의 아키텍처


구글 검색엔진의 전반적인 구조


지금까지 구글 검색엔진의 특징을 살펴보았고, 이제는 구글 검색엔진의 구조에 대해 알아보자. <그림 1>은 구글 검색엔진의 아키텍처를 표현하고 있다. 구글 검색엔진의 구조는 일반 검색엔진과 큰 차이가 없다. 구글 검색엔진은 크게 웹 문서를 수집하는 크롤러(crawler) 영역과, 역 색인(inverted index)을 생성하는 색인기(indexer) 영역, 그리고 검색을 수행하는 검색기(searcher) 영역으로 구분된다. 구글 검색엔진이 데이터를 수집하고 색인을 생성하여 검색을 수행하는 전반적인 시퀀스는 다음과 같다.


크롤링

- 분산 배치된 크롤러에 의해 웹 페이지들이 다운로드된다.
- 크롤러가 수집한 문서들은 URL server로 보내져서 URL list로 변환된다.
- 크롤러로부터 패치(fetch)된 웹 문서들은 Store server에 저장된다.
- Store server에 저장된 웹 문서들은 압축되어 리파지토리에 저장된다.
- 저장된 웹 문서들은 특정한 docID를 부여받는다.


색인

- Indexer가 리파지토리를 읽어 압축된 웹 문서들의 압축을 해제한다.
- Indexer가 압축 해제된 웹 문서를 파싱하여 문서에 포함된 부수적인 정보(위치 정보, 폰트 크기, 대소문자 여부)와 함께 추출한 키워드 정보(Hits라고 불린다)의 set을 생성하고, 링크들을 분석하여 링크의 방향성과 앵커 텍스트들을 추출해서 anchor file을 생성한다.
- Indexer가 문서 당 추출된 키워드들의 set을 Barrel에 일부분 정렬이 이루어진 forward index 형태로 분산 저장한다.
- URL resolver가 anchor file을 분석하여 상대 URL(relative URL)을 절대 URL(absolute URL)로 변환하고, 변환된 URL 정보를 Barrel에 저장되어 있는 forward index의 docID와 조합한다.
- Sorter가 Barrel에 docID 순으로 정렬되어 있는 정보를 키워드 별로 정렬하여 wordID를 할당한다.
- Indexer가 wordID 순으로 정렬된 정보를 이용하여 최종적으로 역 색인(inverted index)을 생성하여 Lexicon에 저장한다.


<그림 2> 라파지토리의 자료구조


검색

- 입력 받은 질의어를 분석한다.
- Lexicon을 뒤져서 분석을 통해 추출된 키워드에 해당하는 wordID를 찾는다.
- 발견된 wordID에 해당하는 doclist의 시작 위치를 Barrel을 뒤져서 찾는다.
- doclist를 스캔하여 입력된 search term과 매칭되는 도큐먼트들을 찾는다.
- 탐색된 도큐먼트들에 대해서 페이지 랭크를 계산한다.


구글 검색엔진의 자료구조


구글 검색엔진은 기본적으로 대용량 데이터를 다룬다. 기본적인 정보 외에도 부수적인 정보들을 충분히 다루고 있는 만큼 모든 색인 구조를 비롯한 자료구조는 매우 효율적이고 최적화돼 있어야 한다. 머신의 성능은 급격하게 발전하고 있지만 디스크 I/O 속도는 크게 변함이 없는 현실에서 자료구조는 훨씬 더 중요한 위치를 차지한다. 다음은 구글 검색엔진에서 사용하고 있는 자료구조들이다. 구글 검색엔진의 자료구조를 살펴보면, 구글 검색엔진의 내부 프로세스와 구조를 더 자세히 볼 수 있다.


리파지토리
리파지토리는 크롤러에 의해 수집된 웹 문서의 full HTML을 zlib를 이용해 압축, 저장한다(zlib은 다른 압축 솔루션에 비해 압축과 압축 해제 속도가 뛰어나다). 리파지토리에 저장되는 각 웹 문서들은 docID를 prefix로 사용하여, 기타 정보들을 함께 묶은 형태의 자료구조로 표현된다. 웹 문서의 consistency 유지나 크롤러의 에러는 리파지토리의 모든 자료구조를 재생성(rebuilding)함으로써 해결한다. <그림 2>는 리파지토리의 자료구조를 나타낸 그림이다.


도큐먼트 인덱스(Document Index)
도큐먼 트 인덱스는 각 도큐먼트의 정보들을 저장하며, 기본적으로 docID에 의해 정렬된 fixed width ISAM(Index sequential access mode)이다. 이것은 도큐먼트에 대한 추가적인 정보로 도큐먼트의 상태 정보, 리파지토리 내에서의 해당 도큐먼트에 대한 위치, 도큐먼트 체크섬(checksum), 기타 수치적 정보들을 포인터로 담고 있다. 포인터 정보만 사용함으로써 콤팩트한 자료구조의 구성이 가능하며, 검색을 수행하는 동안 디스크 탐색 시간을 줄일 수 있다. 추가로, 도큐먼트의 정보 중 URL과 docID의 관계를 저장해 두기 위해 URL을 docID로 변환한 관계를 저장하는 파일이 존재한다. 이것은 URL 체크섬을 키(key)로 갖고, docID를 데이터로 갖는 자료구조로 일반적인 btree(binary tree) 검색과 유사한 방식에 의해, URL 체크섬을 키로 던져 해당 URL의 docID를 찾아내는데 사용된다. 이 방식은 URLresolver가 URL을 docID로 변환하는데 사용된다.


Lexicon
Lexicon은 실제 검색을 수행할 때 반드시 필요한 역 색인 구조를 만들기 위한 자료구조이다. 검색엔진의 성능과 처리 가능한 용량이 대부분 Lexicon과 역 색인 구조에 기반해 결정되기 때문에 Lexicon의 자료구조는 검색엔진의 전체 구조 중 매우 중요한 요소를 차지한다. 검색엔진의 속도 향상을 위한 기초적인 접근 방식은 Lexicon을 메모리에 구동 가능한 크기로 쪼개는 것이다. 초기 구글 검색엔진의 경우에는 256MB 메인 메모리에 올라갈 수 있는 크기로 설계됐고, 256MB 안에 1,400만 개의 단어를 올릴 수 있었다. 구글의 Lexicon은 추출된 단어들의 리스트와 포인터의 해시(hash) 테이블, 두 가지 요소로 구성된다.


Hit Lists
Hit는 하나의 도큐먼트에서 추출된 하나의 단어에 대한 부가적인 위치 정보, 폰트 정보, 대문자 여부 등의 집합이다. Hit List는 forward index와 inverted index에서 모두 사용되며 검색엔진 내의 정보 중 상당 부분을 차지하기 때문에 가능한 효율적인 구조를 가져야 한다. 구글 검색엔진은 하나의 hit를 2바이트로 인코딩하는 방식을 취한다.

Hit는 다시 각 도큐먼트에서 URL, title, anchor text, meta tag로부터 추출된 정보를 저장하는 fancy hit, anchor text로부터 정보를 추출된 정보를 저장하는 anchor hit, 그리고 그 밖의 요소들로부터 추출되는 plane hit 등 3개의 hit로 구분된다. <표 1>은 인코딩된 fancy hit과 plane hit, anchor hit의 구조를 나타낸다.

Anchor hit에 포함된 4비트짜리 해시는 해당 anchor가 출현한 웹 문서의 docID에 대한 해시 값을 저장한다. 이것은 anchor file에 저장되어, 랭크 산출에 가중치 요소로 사용된다. 최종적으로 hit list들은 Barrel에 forward index를 구성하면서 wordID를 기준으로 저장되고, inverted index에 docID를 기준으로 저장된다.


Forward Index
Forward Index는 도큐먼트에 대한 docID를 기준으로 추출된 hit list를 wordID와 함께 붙여서 barrel에 분산해놓은 구조이다. Barrel 자체가 wordID의 특정 range에 대해 분산되도록 설계되어 있기 때문에 docID가 중복 저장될 가능성이 있다. 하지만 inverted index를 구성할 때 Sorter에 의해 wordID를 중심으로 재구성되어야 하기 때문에, 실제로는 이와 같은 방식이 조금 더 효율적일 수 있다. Barrel 내에 forward index가 저장될 때는 wordID 24비트와 hit list length에 대한 정보가 8비트 추가된다.


Inverted Index
Inverted Index는 forward index가 Sorter에 의해 wordID 순으로 정렬된 구조이다. 유효한(valid) wordID는 Lexicon에 저장되고, 각 wordID가 속한 도큐먼트에 대한 docID는 Barrel 내에 역 색인으로서 저장된다. Lexicon의 각 wordID는 inverted barrel 내의 docID를 가리키는 포인터를 갖는다.


<그림 3>은 Forward Index, Inverted Index, Lexicon의 구조에 대한 그림이다. Forward Barrel에 저장된 docID의 리스트는 최종적으로 Lexicon과 Inverted Barrel에 저장되면서 최종적인 역 색인 구조를 구성하게 된다.


<그림 3> Forward/Bcakward Index와 Lexicon의 자료구조


<표 1> 인코딩된 fancy hit과 plane hit, anchor hit의 구조
구분 내용
Plane Hit capitalization: 1 font info: 2 position: 12
Fancy Hit capitalization: 1 font info: 7 type; 4 position: 8
Anchor Hit capitalization: 1 font info: 7 type; 4 hash: 4 position: 4

<표 2> 구글 검색엔진의 퍼포먼스 수치 정보
Storage Statistics
Total Size of Fetched Pages 147.8GB
Compressed Repository 53.5GB
Short Inverted Index 41GB
Full Inverted Index 37.2GB
Lexicon 293MB
Temporary Anchor Data 6.6GB
Document Index Incl. Variable Width Data 9.7GB
Links Database 3.9GB
Total without Repository 55.2GB
Total with Repository 108.7GB
Web Page Statistics
Number of Web pages fetched 24 million
Number of URLs seen 76.5 million
Number of Email Address 1.7 million
Number of 404's 1.6 million
Search Times
  Initial Query Same Query Repeated
Query CPU time Total time CPU time Total time
al gore 0.09 2.13 0.06 0.06
vice president 1.77 3.84 1.66 1.8
hard dixks 0.25 4.86 0.2 0.24
search engine 1.31 9.63 1.16 1.16

지금까지 구글 검색엔진에 대한 특징과 아키텍처, 자료구조에 대해 살펴보았다. 구글이 등장한지 많은 시간이 흘렀지만, 구글의 검색엔진은 여전히 최적화된 혁신적인 구조로 개발자들에게 받아들여지고 있다. 많은 검색엔진들은 여전히 구글 검색엔진을 벤치마크 대상으로 이용하고 있고, 구글 검색엔진이 갖고 있는 합리적인 랭킹 모델이나 데이터 처리 모델과 자료구조는 많은 검색엔진이 닮고 싶어하는 요소들이다.


현대적 랭킹 모델, 페이지 랭크 알고리즘


구글은 처음 등장할 때 대량의 웹 페이지 데이터들에 대한 새로운 개념의 랭킹 모델 적용으로 가장 주목받았다. 페이지 랭크라 불리는 이 랭킹 모델(ranking model)은 각 웹 페이지들의 중요성(importance) 을 기반으로 계산(scoring)된, 사용자 입장에서 상당히 정확해 보이는 랭킹을 제공한다.


세르게이 브린(Sergey Brin)이 제안한 페이지 랭크 알고리즘은 웹 페이지의 중요성에 기반을 둔 일종의 보팅 알고리즘(voting algorithm)으로, 사용자 중심의 주관적 영역에 놓여있던 ‘중요성’을 상대적이고 기계적인 관점에서 정량화가 가능한 객관적 영역으로 변환시킨다. 이것은 기존의 야후나 기타 검색엔진들이 제공했던 사람이 직접 웹 페이지의 중요도를 등록하여 결과로 제공하는 것이 웹 페이지의 랭크라고 믿어오던 사람들의 생각을 완전히 바꿨다. 구글은 모든 페이지들의 중요도를 인터넷에서 웹 페이지를 생산해내는 사람들과 사용자들이 웹 페이지에 접근하는 행태를 분석하여 자동으로 랭킹이 계산되는 구조를 만들어 냈다. 인력으로 랭킹을 처리하는 데에는 한계가 있었기 때문에, 비교할 수 없을 정도로 훨씬 더 많은 데이터들에 대해 유효해 보이고 자동화된 랭킹을 제공한 구글은 단숨에 검색 사용자들의 이목을 끌 수밖에 없었다.


<그림 4> 역 링크: 링크 A와 링크 B는 페이지 C에 대한 역 링크이다.


랭크를 갖는 링크: 링크를 통한 랭킹의 전파


웹 링크의 중요성에 대한 접근은 구글 이전에도 있었는데 대부분 웹 공간 상에서 링크는 논문에 기재되는 학술적 레퍼런스와 유사한 개념으로 보아, 레퍼런스 구조를 분석하고 중요성을 계산하는 테크닉들이 대부분이었다. 예를 들어, 학술적으로 자주 인용되는 논문은 그렇지 않은 논문에 비해 중요한 논문일 가능성이 크다고 보는 것이다. 페이지 랭크의 기본적인 아이디어는 웹 상의 이러한 레퍼런스 구조를 웹 공간의 링크 구조로 더욱 포괄적으로 확장하는 데 있다.


웹 페이지는 그 페이지에서 밖으로 나가는 순 링크(forward link, outedge)와 외부에서 그 페이지를 가르키는 역 링크(back link, inedge)를 포함한다. 기본적으로 페이지 랭크에서 측정되는 웹 도큐먼트의 중요성은 웹 도큐먼트의 컨텐트와 상관없이 그 웹 도큐먼트가 갖고 있는 링크 구조를 분석함으로써 측정된다.


페이지 랭크에서 중요성에 대해 가장 주요한 요소로 간주된 것은 링크가 많이 된 페이지가 그렇지 못한 페이지보다 대부분 더 중요하다는 가정이었다. 역 링크라 불리는, 외부 페이지로부터의 레퍼런스 횟수는 중요성을 계산하는데 기본적인 요소로 사용되었다. <그림 4>는 역 링크의 일반적인 형태를 나타낸다.


하지만 역 링크의 개수를 세는 것만으로 중요성을 매기는 것은 유효하지 않을 수도 있다. 어떤 웹 페이지가 달랑 야후 하나에 링크되어 있다면 그 도큐먼트는 단 1개의 역 링크를 갖고 있지만, 그 링크는 중요하지 않은 페이지로부터의 역 링크 몇 개보다 훨씬 더 중요한 링크라고 간주될 수 있다. 페이지 랭크는 링크를 통해 랭킹을 전파하는 구조이다. 모든 역 링크에는 랭크 값이 있고, 랭크 값이 높은 역 링크의 레퍼런스를 많이 갖는 웹 도큐먼트일수록 웹 도큐먼트의 랭크가 올라간다.


페이지 랭크의 개념


페이지 랭크를 단순하게 모델링한다면 다음과 같은 간단한 수식으로 표현할 수 있다.


어떤 웹 페이지를 u라고 하고, 웹 페이지 u가 레퍼런스하고 있는 페이지의 집합을 Fu, 웹 페이지 u를 역 링크하고 있는 페이지의 집합을 Bu로 표현한다. Nu는 웹 페이지 u로부터 나가는 순 링크의 개수(| Fu |)이다. c는 웹 페이지의 랭크 총합을 일정 레벨로 맞추기 위한 노멀라이징 팩터(normalizing factor)이다. <그림 5>는 페이지 랭크가 계산되는 방식을 간단하게 보여준다.


그러나 웹 공간 상의 복잡한 링크 구조는 이와 같은 수식으로 해결하기 어려운 그래프를 구성하기도 하는데, 랭크 싱크(rank sink)와 댕글링 링크(dangling link)가 그것이다 ⑵. 페이지 랭크에서는 이런 문제를 해결하기 위해 사용자 정의 파라미터를 하나 더 둔다. 다음은 사용자 정의 파라미터 E가 추가된 페이지 랭크 모델을 표현한다.


추가 파라미터 E(u)는 웹 페이지 u로부터 또 다른 특정 페이지로 이탈할 확률 분포에 대한 모델이다. 앞서 검색엔진을 설명하면서 잠시 거론되었던 페이지 랭크의 사용자 행동 패턴에 대한 모델링(랜덤 서퍼 모델)이 바로 파라미터 E이다. 즉, 파라미터 E는 랜덤 서퍼가 특정 확률 주기에 의해 다른 페이지로 이탈하는 것을 의미하며 이것은 댕글링 링크를 이탈하는 행동의 모델링으로 볼 수 있다. 구글 검색엔진은 일반적으로 모든 페이지에 동일한 확률 주기의 E 값을 셋팅하여, 모든 서퍼들이 주기적으로 링크의 그래프를 이탈한다고 보지만 E 값을 특정 페이지로 지정함으로써, 개인화된 페이지 랭크 모델을 만들 수도 있다.


만약 2개의 페이지 랭크 모델을 만들어서 하나는 E를 일반 포탈 사이트의 홈페이지로, 나머지 하나는 E를 컴퓨터 사이언스 관련 커뮤니티의 홈페이지로 셋팅한다면, 일반 포탈 쪽 랭크보다 컴퓨터 사이언스 관련 커뮤니티 쪽의 랭크들이 더 큰 값을 가지게 될 것이다.


페이지 랭크의 구현


페이지 랭크는 일반적인 재귀 연산(recursive operation)의 형태이지만, 효율성을 위해 컴퓨터 상에서는 벡터의 형태로 변환되어 계산된다. 이에 관련된 정보를 얻고 싶다면 Taher H. Haveliwala가 쓴 『Efficient Computation of PageRank(Stanford Technical Report, 1999)』를 참조하기 바란다. 페이지 랭크가 컴퓨터 상에서 처리되는 방식은 다음과 같다.


 R0 ← S loop : Ri + 1 ← ARi d ← ||Ri||1 - ||Ri + 1 ||1 Ri + 1 ← Ri + 1 + dE δ ← ||Ri + 1 - Ri||1 while δ > ∈

S는 한 웹 페이지의 초기 벡터 값이다.
Ri는 i번째 페이지 랭크 벡터 값을 나타낸다.
||R||1은 벡터 R의 노름(norm) 값이다.
d는 댐핑 팩터(damping factor)이다.
A는 한 웹 페이지 u에서 다른 웹 페이지 v로 연결되는 포워드 링크의 개수의 역수이다. 만약 서로 연관된 링크가 없다면 0이 된다.

<그림 5> 페이지 랭크의 계산


이와 같은 연산은 수렴(convergence)이 이루어질 때까지 반복적으로 이루어진다. 구글 검색엔진 내부에서는 방대한 웹 페이지들의 페이지 랭크 계산을 위해 다음과 같은 방식으로 프로세스를 진행한다.


① docID를 이용하여 링크 구조를 정렬한다.
② 링크 데이터베이스에서 댕글링 링크를 제거한다.
③ 랭크 값을 초기화한다.
④ 각 페이지의 가중치를 저장하기 위한 메모리를 할당한다.
⑤ 한 단계의 계산이 완료되면 디스크에 가중치를 저장하고, 다음 단계의 계산을 메모리 상에서 진행한다.
⑥ Stet 5를 수렴할 때까지 반복된다.


페이지 랭크의 의미


페이지 랭크는 본질적으로, 웹 링크의 그래프 상에서의 랜덤 서퍼가 갖는 행동 패턴을 제한된 분포로 결정짓는 작업이다. 그래프 상의 한 노드의 중요도는 충분한 시간이 흐른 후에 랜덤 서퍼가 그 노드 위에 있을 확률이다. 확률이 높다면 웹 상의 서퍼들이 접근할 가능성은 높아진다. 이것은 웹 페이지의 컨텐츠와 상관없이 웹 상에 존재하는 가중치가 부여된 링크 구조에 의한 중요성을 산출한다는 의미이다. 이런 특징은 대부분 사용자들의 웹 페이지 접근 의도에 대한 일반적인 케이스(common case) 처리가 가능토록 한다.


예를 들어 꽃이라는 키워드를 쳤을 때, 일반적인 케이스는 꽃에 대한 설명이 담긴 페이지들이 아니라 꽃 구입이나 배달과 관련된 페이지들이다. 일반적으로 사람들이 특정 질의어를 입력했을 때 특정 페이지가 일반적인 케이스라는 정보는 HTML 자체에는 담겨져 있지 않기 때문에, 링크 구조를 분석하는 페이지 랭크는 일반적인 케이스 처리에 매우 효과적이다. 또한 페이지 랭크는 사용자에게 자신이 찾고 있는 링크가 중요도 측면에서 어느 정도의 위치를 차지하고 있는지에 대한 인디케이터(indicator)가 될 수도 있다.


참고로, 페이지 랭크의 요소들은 지금도 계속해서 튜닝되고 있다. 예를 들면 웹 페이지의 컨텐츠가 얼마나 자주 갱신되는가에 대한 빈도수(frequency) 등이 새롭게 추가되는 요소들 중 하나이다.


대용량 파일의 분산 처리를 위한 구글 파일 시스템


검색엔진의 성능이 검색엔진의 자료구조와 아키텍처에 밀접한 관계가 있는 것은 사실이지만, 어느 수준의 성능 이상을 요구하는 경우에는 반드시 최적화된 하부 구조가 필요하다. 앞서 살펴보았던 구글 검색엔진은 대용량의 웹 데이터를 다루고, 그에 따른 대용량 데이터와 색인 구조들을 다루고 있다. 대용량 처리를 위해서는 비용 문제를 간과하기 힘들기 때문에, 구글은 저 사양의 머신들을 대량 배치하여 분산 처리하는 것으로 대용량 데이터와 대용량 트래픽에 대응하고 있다. 이를 가능하게 한 데에는 효율적으로 대용량 파일의 분산 처리와 성능을 위해 자체적으로 개발된 구글 파일 시스템의 역할이 크다.


<그림 6> 구글 파일시스템 아키텍처


구글 파일 시스템의 특징


대용량 분산 파일 시스템이 가져야 하는 요소에는 확장성(scal ability), 성능(performance), 신뢰성(reliability), 가용성(avail ability) 등이 있다. 구글 파일 시스템 역시 이런 특징적 요소들을 모두 포함하고 있다. 구글 파일 시스템은 리눅스 파일 시스템을 기반으로 개발되었으며, 추가적으로 다음과 같은 접근 특성들에 대한 처리 목표를 취하고 있다.


분산 처리 서버들의 오류(failure)에 대한 대응
- 애플리케이션 버그, 디스크 오류, 메모리 오류, 커넥션 오류, 네트워킹 오류, 파워 서플라이 오류 등에 대해서 모니터링, 오류 허용(fault-tolerance), 자동 복구(automatic recovery) 등이 시스템에 포함


기존의 파일에 비해 훨씬 더 큰 대용량 파일의 처리
- Multi-GB 파일들이 사용되기 때문에 I/O 오퍼레이션과 블럭 크기(block size)에 대한 파라미터 조정을 통해 효율적으로 관리


특징적인 읽기/쓰기 패턴에 대한 최적화
- Large streaming reads
- Small random reads
- Large, sequential writes
- Small writes


Well-defined semantics를 갖는 구조
- 동일 파일에 읽기/쓰기를 하려는 다수의 클라이언트의 오퍼레이션을 처리하기 위해 동기화(synchronization) 처리


고속의 대역폭(bandwidth) 유지
- 읽기/쓰기에 대해 엄격한 응답 시간(response time) 유지


구글 파일 시스템 아키텍처


구글 파일 시스템은 하나의 마스터 서버(master server)와 다수의 청크 서버(chunk server), 그리고 다수의 클라이언트(client)로 구성되어 있다(이러한 서버들은 모두 표준화된 형태인데, 구글에서는 표준화된 서버를 pizza server box라고 부른다). <그림 6>은 이러한 구글 파일 시스템의 아키텍처에 대한 그림이다.


마스터 서버는 청크 서버에 대한 메타 데이터들을 관리한다. 청크 서버는 정해진 크기의 청크들을 저장하고, 클라이언트는 마스터 서버의 메타 데이터들을 확인하고, 청크 서버에 접근하여 필요한 데이터를 읽고 쓴다.


각 파일들은 정해진 크기의 청크(chunk)로 나뉜다. 각 청크는 생성 시점에 마스터 서버에 의해 글로벌하게 유니크한(globally uni que) 청크 핸들(chunk handle)을 할당받는다. 청크 핸들과 바이트 레인지(byte range)에 의해 결정된 청크 데이터들은 청크 서버의 로컬 디스크에 저장되는데, 저장되는 청크 데이터는 기본적으로 3개의 복제본을 가지게 된다. 하나의 청크 서버에서 청크들을 로컬 파일로 존재하므로 별도의 캐시(cache) 없이 리눅스의 버퍼 캐시 효과를 그대로 사용한다. 구글 파일 시스템의 청크 크기는 64MB로 일반적인 리눅스 파일 시스템의 블럭 크기보다 크다. 이처럼 큰 청크 크기를 사용함으로써, 클라이언트가 동일한 청크에 접근할 때 불필요하게 마스터 서버와의 통신을 줄일 수 있고, 클라이언트의 네트워크 오버헤드와 마스터 서버에 저장되는 메타 데이터의 크기도 줄일 수 있다.


마스터 서버는 모든 파일 시스템의 네임 스페이스(name space), 액세스 컨트롤 정보(access control information), 파일-청크 간의 맵핑 정보 등의 메타 데이터를 관리한다. 마스터 서버는 이 정보를 이용하여 청크 서버들과 Heart Beat 메시지에 의한 커뮤니케이션을 통해 청크에 대한 가비지 컬렉션(garbage collection), 청크 서버 간의 마이그레이션(migration)을 수행한다. 마스터 서버의 메타 데이터들은 모두 메모리 상에 저장되기 때문에, 마스터 서버의 오퍼레이션이 매우 빠르다. 이는 주기적으로 상태를 스캐닝하여 청크 서버의 오류 상황이 발생했을 때 복제본을 재배치한다거나 청크 서버들의 디스크 사용 상태에 따라 청크 마이그레이션을 수행하는데 매우 효율적인 방식이다.


클라이언트는 구글 파일 시스템 API에 의해 구현된 애플리케이션을 담고 있으며, 마스터 서버 및 청크 서버와 커뮤니케이션하면서 애플리케이션에 필요한 데이터를 읽고 쓴다. 클라이언트는 마스터 서버와의 메타 데이터와 오퍼레이션 내용과 커뮤니케이션하고, 모든 실제 데이터와의 커뮤니케이션을 청크 서버와 직접 하게 된다.


구글 파일 시스템의 일관성 모델(Consistency Model)


클라이언트에 의해 파일이 청크 서버에 저장될 때는 오류 발생에 대비해서 3개의 복제본으로 저장된다. 만약, 데이터가 변경/추가된다면 청크 서버 내의 모든 복제본에 대해 동기화가 이루어져야 한다. 파일 쓰기가 이루어졌을 때 다음과 같은 순서로 복제본의 동기화가 이루어진다.


① 클라이언트가 마스터 서버에게 현재 사용하고 있는 청크와 또 다른 복제본들의 위치에 대한 정보를 요청한다.
② 마스터 서버가 클라이언트에게 1차 복제본(primary replica)의 ID와 2차 복제본(secondary replica)의 위치 정보를 보내준다.
③ 클라이언트가 모든 복제본에 대해 데이터를 푸시한다. 각 청크 서버는 넘어온 데이터들을 저장한다.
④ 모든 복제본들이 데이터를 받은 것에 대한 완료 여부(acknowledge)가 확인되면 클라이언트는 1차 복제본에 쓰기 요청을 한다.
⑤ 1차 복제본은 모든 2차 복제본에 쓰기 요청을 전달한다.
⑥ 2차 복제본의 오퍼레이션이 완료되면 1차 복제본에 완료 시그널을 보낸다.
⑦ 모든 2차 복제본에서 완료 시그널이 오면 1차 복제본은 쓰기 요청이 완료되었음을 클라이언트에게 회신한다.


<그림 7>은 이와 같은 동작의 흐름을 나타낸 그림이다. 이러한 동작은 기본적으로 컨트롤 플로우(control flow)와 데이터 플로우(data flow)가 구분되어 네트워크를 효율적으로 사용하는 방식으로 구성되어 있다.


구글 파일 시스템의 마스터 서버 오퍼레이션


마스터 서버는 구글 파일 시스템 내의 모든 네임 스페이스와 청크들의 복제본에 대한 관리를 처리한다. 마스터 서버에서 진행되는 오퍼레이션들을 간단하게 살펴보면 다음과 같다.


네임 공간에 대한 관리 및 락킹(locking)
- 네임 공간은 풀 패스 명(full path name)의 맵핑 테이블에 의해 관리된다.
- 읽기/쓰기가 발생할 때 lock 처리를 해 conflict가 발생하는 상황을 방지한다.


복제본 배치
- 청크의 복제본을 데이터의 신뢰성과 가용성을 최대화하는 방향으로 배치한다.
- 청크의 복제본을 네트워크 사용성(utilization)을 최대화하는 방향으로 배치한다.


<그림 7> Write Control and Data Flow


청크와 복제본에 대한 관리
- 새로운 청크를 생성할 때 청크 서버의 디스크 사용 수준이나 최근 영역의 분포 등을 확인하여 생성한다.
- 오류가 발생하여 복제본 간의 내용이 맞지 않다면(corrupted 되었다면) 정상적인 복제본을 재배포한다.
- 청크 서버의 디스크 상태와 부하(load) 상태를 확인하여 좀 더 나은 상태의 청크 서버로 복제본을 재분산(rebalancing)한다.

<그림 8> 구글플렉스의 논리적 구조


<그림 9> 구글의 주요 기술 요소들을 나타내는 다이어그램


가비지 컬렉션
- 파일 삭제가 일어나면 마스터 서버에 삭제 시간을 비롯한 정보가 로그로 남는다. 실제 청크 서버에서는 파일 삭제가 바로 이루어지지 않고, 히든 타입으로 리네임(rename) 처리가 된다.
- 마스터 서버에서는 청크 네임 공간 스캔을 통해 3일 이상된 히든 타입의 파일들을 삭제한다.
- 파일이 네임 공간에서 삭제되면 마스터 서버의 메타 데이터가 삭제된다.


구글 파일 시스템의 오류 복구


마스터 서버와 청크 서버는 각각 메모리에 올라갈 수 있는 수준의 메타 데이터를 가지고 있다. 서버에 문제가 생겨서 재시작되는 경우 빠른 시간 안에 재동작을 할 수 있는 상황으로 복구될 수 있다.


각 청크는 여러 대의 서로 다른 랙(rack)에 위치한 청크 서버에 복제본을 기본적으로 3개 배치한다. 각 청크들은 체크섬 버전 정보를 가지고 관리되며 이에 의해 각 복제본 간의 동기화 작업이 이루어진다. 데이터를 읽기 위해 접근한 청크 서버가 문제가 있다면 또 다른 청크 서버에 담겨있는 복제본에 의해 데이터 읽기 작업은 무사히 수행될 수 있다.


마스터 서버 역시 마스터 서버에서 일어나는 모든 오퍼레이션의 로그와 상태(state), 체크 포인트들은 여러 대의 머신으로 복제한다(Shadow master라고 불린다). 마스터 서버의 디스크에 오류가 있거나, 외부 모니터링 툴에 의해 이상이 발견되는 경우 복제된 마스터 서버에 의해 파일 시스템 오퍼레이션은 정상 수행되도록 조정된다.


구글 파일 시스템은 구글 검색엔진과 서비스에 적합하도록 심플하고 효과적인 파일 시스템으로 설계되어 있다. 구글에서 일어나는 대부분의 데이터 액세스는 추가(append) 중심의 쓰기 작업과 빈번한 읽기 중심의 작업들이고, 저가의 머신에 의한 클러스터(cluster) 구성이기 때문에 오류 처리 역시 중요한 이슈가 된다.


구글의 파일 시스템은 시스템 내의 중심적인 읽기/쓰기 패턴을 명확하게 정의하고 오류 처리를 중심으로 견고하고 효과적으로 설계되어 있다. 검색엔진에서 하부 저장 구조라는 것은 검색엔진 자체의 성능을 뛰어넘도록 하고 검색엔진 자체의 안정성을 확장하는 요소로, 구글이 갖고 있는 효율적인 하부 저장 구조는 구글의 기반을 다진 핵심 기술 요소 중 매우 중요한 요소로 볼 수 있다.


모든 기술을 아우르는 거대한 프레임워크


지금까지 구글이 갖고 있는 기술들 중에 핵심 기술(core technology)이라고 불릴 수 있는 요소들에 대해 간략하게 살펴보았다. 이 기술들은 현재의 구글을 있게 만든 구글만의 독자적인 기술임에 틀림없다. 하지만 구글의 기술은 이것이 전부가 아니다. 구글은 모든 애플리케이션과 기능들을 웹 중심(web-centric)으로 흡수하기 위한 작업을 하고 있다. 그 기반에는 구글의 기술들을 모두 아우르는 거대한 프레임워크가 존재한다.


구글플렉스


구글플렉스(Googleplex, 구글 본사 건물의 별칭이기도 하다)는 구글의 프레임워크에서 매우 중요한 위치를 차지하는 요소이다. 구글플렉스는 동일한 개체들이 모여 거대한 시스템을 구성하는 논리적 구조이다. 하나의 서버는 다른 서버들과 기능과 속성들을 공유한다. 이런 서버들이 모여서 클러스터를 구성한다. 클러스터들을 모여서 데이터 센터(data center)를 구성한다. 또 다시 데이터 센터들은 다른 애플리케이션 서버들과 모여서 구글의 온라인 시스템을 구성한다.


<그림 8>은 구글플렉스의 타이트하고 규칙적으로 조직화된 모습을 보여준다. 그림을 살펴보면 구글플렉스 내의 모든 레벨에 걸쳐 동일한 패턴이 반복되고 있음을 알 수 있다. 다시 말해 구글플렉스의 모든 구성 요소들은 동형(homogeneous)의 컴퓨팅 시스템이다. 구글 버전의 리눅스 위에서 돌아가는 구글 애플리케이션들의 집합은 슈퍼컴퓨터를 이용해 애플리케이션을 돌리는 것과 유사하다.


동형의 컴퓨팅 시스템은 몇 개의 장점을 갖고 있다. 모든 데이터 센터를 구성하고 있는 서버들의 구성 역시 동일한 구성이기 때문에, 시스템 규모의 확장시 단순히 서버 랙을 꽂고(plugged-in) 케이블을 연결하는 작업만으로도 셋팅과 설정(configuration)을 가능하게 한다. 앞서 살펴보았던 구글 파일 시스템 내에서 마스터가 청크 서버에 청크들을 복제하는 작업 역시 동형의 컴퓨팅 시스템에 대한 접근이므로 매우 친숙하고 쉬운 오퍼레이션으로 구현될 수 있다. 즉, 구글플렉스는 구글 파일 시스템의 기능과 목적들을 효율적이고 효과적으로 지원할 수 있는 논리적 구조이다.


구글 컴퓨팅 프레임워크


개발자들이 흔히 말하는 ‘구글스럽다’라는 말의 의미는 무엇인가. 검색 영역의 개발자와 일반 영역의 개발자가 바라보는 관점이 약간의 차이는 있을 수 있겠지만, 대부분의 경우 구글을 구글스럽게 만드는 것은 검색 기술처럼 특화된 기술 자체가 아니라 일반적이고 연구 개발적인 관점에서 접근하는 소프트웨어 공학적이면서 하드웨어 공학적인 솔루션들이 일으키는 시너지이다.


<그림 9>는 구글 프레임워크의 전체적인 모습을 나타낸 다이어그램이다. 이 그림을 보면 구글의 프레임워크에 포함되어 있는 중요한 기술들에 대해 알 수 있다.


대용량 파일 및 function 가속을 위해 수정된 리눅스
- 기능에 적합하게 튜닝된 리눅스를 사용한다.


기능 추가 및 규모 확대에 플러그인 방식에 의해 별도로 손이 가지 않을 정도로 표준화된 분산 구조
- 구글플렉스는 자기 유사 구조를 가지며, 서버의 추가와 오류에 대한 대응이 쉽다.


스케일 레벨(scale level)에 관계없이 유사한 기술 구조
- 동형(homogeneous) 구조에 의해 모든 요소들이 구성된다.


프로그래밍 언어에 관계없이 기능 구현이 가능한 웹 기반 아키텍처
- 프레임워크의 인터페이스로 WSDL, XML, HTML, POP3, SMTP 등과 같은 플랫폼 독립(platform-independent)적인 프로토콜을 제공한다.


<그림 10> Google's fuction: Hardware and Software Innovations


<그림 11> 구글 검색과 LostGoocle을 이용한 검색의 비교


구글의 프레임워크는 구글 파일 시스템에 의해 구성된 데이터 센터와 분석적 방법으로 광고를 집행하는 구글 광고 시스템(Ad System), 각종 서비스 시스템(gmail, News 등), 검색엔진 등을 모두 포함한다. 구글플렉스의 외부와 내부에는 새로운 서비스 시스템과 애플리케이션들이 추가될 수 있고, 기본적인 인터페이스들을 통해 구글 프레임워크로의 접근과 구글 프레임워크의 기능을 사용할 수 있는 확장적이고 오픈된 구조이다(구글의 피카사(Picasa)나 구글 어스(Earth)는 로컬 머신에서 수행되는 애플리케이션을 구글 프레임워크로 포괄시키는 좋은 예이다).


조금 다른 관점에서 본다면, 구글 프레임워크는 소프트웨어 공학과 하드웨어 공학의 접점에 놓여 있다. 소프트웨어적인 관점에서 성능을 확보하면서 동시에 하드웨어 공학적인 관점에서 비용 절감을 위한 기술들을 모두 포함한다. 이는 비용 절감, 저가형 하드웨어, 스마트한 소프트웨어에 대해 집중하는 구글 문화의 주요 부분이다.


구글 프레임워크는 구글을 여타 다른 경쟁업체와 차이를 갖도록 하는 명확한 요소이다. 구글플렉스는 구글 파일 시스템과 구글이 지향하는 성능과 비용절감의 측면에서 매우 효율적인 구조이다. 서버 랙이나 데이터 센터가 오류를 일으키더라도 데이터의 손실이나 구글플렉스 전체의 다운은 방지된다. 또한, 동형 시스템의 사용으로 인해 머신의 설치 과정이나 설정(configuration)의 표준화와 자동화를 가능케 했다. 이는 타 업체가 소프트웨어 중심의 튜닝이나 하드웨어의 업그레이드에 의존해 성능과 안정성을 유지하는 모습과는 상당한 차이를 보인다.


구글의 프레임워크는 또한 구글 내의 개발자는 물론, 일반적인 개발자들에게 아주 좋은 장난감 꾸러미(toy box)이다. 구글 프레임워크의 인터페이스를 통해 언제 어디서나 웹과 연결된 환경이라면 구글의 강력한 기능을 그대로 활용할 수 있는 것이다. 이러한 확장적이고 오픈되어 있는 프레임워크 구조는 많은 개발자들의 호응을 얻고 있다.


구글 APIs


구글은 개발자들이 쉽게 구글 프레임워크에 접근할 수 있는 API set을 제공한다. 구글이 갖고 있는 기술에 쉽게 접근하여 방대한 데이터와 강력한 기능들을 사용할 수 있는 구글 API는 개발자들에게 매력적인 요소일 수밖에 없다. 앞서 1부에서 소개한 것처럼 구글에서는 다양한 API들을 제공하는데, 여기서는 가장 대표적으로 사용되고 있는 구글 웹 검색 API에 대해 살펴보겠다.


구글 웹 검색 APIs


구글 웹 검색 API는 SOAP과 WSDL 표준을 기반으로 구글과 통신할 수 있는 방식을 제공한다. 개발자는 어떤 프로그래밍 언어를 사용하든 상관없이 구글과의 프로토콜만 맞춰줌으로써 구글의 기능을 그대로 사용할 수 있다. 구글 웹 검색 APIs 페이지(http://www.google. com/apis/)에는 다음과 같은 프로그래밍 아이디어들이 기재되어 있다.


- 주제에 맞는 새로운 정보에 대한 자동 모니터링
- 시간의 흐름에 따른 마켓 분석과 트렌드 분석
- 온라인 게임의 개발 - 새로운 검색 UI의 개발
- 구글의 스펠 체크 기능을 애플리케이션에 추가


<표 3> 구글 웹 검색 APls를 통한 검색 요청에 사용되는 기본적인 파라미터

파라미터 명 설명
key 구글 인증키. APls를 다운받은 후 구글로부터 메일로 인증 키를 받아야 한다.
q 질의어
start 검색 결과 중 불러올 index 번호. 0부터 시작
maxResults 한 페이지에 최대로 불러올 검색 결과의 건 수
filter 검색 결과 중 특정 결과들을 필터하기 위한 조건
restricts 구글 웹 색인 중 서브 셋을 검색하기 위한 조건
safeSearch 성인 필터링을 위한 Boolean 파라미터
lr 언어 제한. 특정 나랏말로 된 문서만을 검색하기 위한 조건

구글 웹 검색 APIs는 SOAP을 사용하는 웹 서비스 모델과 만나면 굉장한 효과를 발휘할 수 있다. LostGoogle(http://lostgoggles.com) 은 구글 API를 이용하여 웹 검색 결과에 해당 페이지의 스크린샷을 썸네일로 제공한다. 만약 LostGoogle을 이용하여 아마존닷컴(http:// www.amazon.com)의 내용을 검색하고자 하면 아마존닷컴에서 웹 서비스로 제공하고 있는 요소들과 합쳐져 도서에 관련된 훨씬 더 풍부한 정보 도서의 형태, 가격, 인기도 등을 볼 수 있다.


구글 웹 검색 APIs를 통한 검색 요청


구글 웹 검색 APIs를 통해 구글로 검색 요청을 보내기 위해 사용하는 기본적인 파라미터는 <표 3>과 같다. 질의어 파라미터에 해당되는 는 <표 4>와 같은 형식으로 기술할 수 있다. 부수적인 qualifier들을 사용함으로써 검색 결과를 특정 조건에 맞게 필터링할 수 있다. 파라미터들을 이용하여 SOAP을 구성한다면 <화면 2>와 같은 형식으로 구글에 리퀘스트를 날리게 될 것이다.

 

<화면 2> SOAP으로 구성된 구글 검색 요청

 

<화면 3> SOAP으로 구성된 구글 검색 결과 포맷

 

<표 4> 질의어 파라미터의 기술 형식

쿼리의 성격 예제 설명
특정 질의어를 포함 Star Wars Episode +1 일번적인 질의어에 "+ 특정 질의어"를 붙여 일반적인 질의어와 특정 질의어가 모두 출현한 검색 결과만을 출력한다.
특정 질의어를 제외 bass-music 일반적인 질의어에 "- 특정 질의어"를 붙여 일반적인 질의어는 출현하지만 특정 질의어가 출현하지 않는 검색 결과만을 출력한다.
특정 어구 검색 "yellow pages" 특정 어구가 출현한 검색 결과만을 출력한다.
Boolean or 검색 vacation london OR paris "word A OR word b" 는 word A 와 word B에 대해 Boolean or 검색 결과만을 노출한다.
사이트 제한 검색 admission site: www.stanford.edu 특정 domain에 포함되어 있는 도큐먼트에 대한 결과만을 노출한다.
날짜 제한 검색 Star Wars datarange:2452122-2452234 Jullian Date 포맷으로 입력된 날짜 기간동안 생성된 웹 페이지드에 대한 검색 결과만을 노출한다.
제목 검색(팀) intitle:Google search "intitle:" 바로 뒤에 명시된 질의어가 제목에 출현한 검색 결과만을 노출한다.
제목 검색(전체) allintitle:Google search "alltitle:" 뒤에 명시된 모든 쿼리 팀들이 제목에 출현한 검색 결과만을 노출한다.
URL 검색(팀) inurl: Google search "inurl:" 바로 뒤에 명시된 질의어가 URL에 포함되어 있는 웹 문서만을 노출한다.
URL 검색(전체) allinurl: Google search "allinurl:" 로 시작되는 질의어의 경우 명시된 모든 질의어가 URL에 포함되어 있는 웹 문서만을 노출한다.
텍스트만 검색 allintext: Google search "alltext:"로 시작되는 질의어의 경우, 명시된 질의어가 웹 문서의 body text 부분에서 출현한 문서만을 노출한다.
링크만 검색 allinlinks: Google search "allinlinks:"로 시작되는 질의어의 경우, 명시된 모든 질의어가 앵커 텍스트에서 출현한 문서만을 노출한다.
파일 타입 포함 필터링 Google filetype: doc OR filetype:pdf "filetype:" 뒤에 명시된 파일 타입을 포함하고 있는 문서만을 노출한다.
파일 타입 제외 필터링 Google filetype: doc-filetype:pdf "-filetype:" 뒤에 명시된 파일 타입을 포함하지 않는 문서만을 노출한다.
웹 문서 정보 info:www.google.com 특정 URL에 해당되는 페이지 하나만을 검색 결과로 노출한다.
역 링크 link:www.google.com 특정 URL에 역 링크하고 있는 페이지들을 노출한다.
관련 링크 related:www.google.com 특정 URL의 페이지와 유사한 페이지들을 노출한다.
캐시된 결과 페이지 cache:www.google.com web 구글이 수집하여 캐시해 놓은 페이지를 보여준다. 특정 질의어와 함께 입력되면 해당 질의어에 하이라이팅 처리를 해준다.

구글 웹 검색 API를 이용한 검색 결과의 수신

 

SOAP을 이용하여 리퀘스트를 날리면, 구글은 SOAP으로 검색 결과를 회신한다. 회신되는 결과에 포함되는 주요 정보들은 다음과 같다.

<summary> - 검색결과가 ODP 디렉토리 내의 리스트의 경우, ODP 서머리에 해당되는 텍스트 스트링
<URL> - 검색 결과의 URL path
<snippet> - 검색 결과 웹 페이지 중 입력된 질의어가 출현한 부분을 볼드 처리하여 추출한 웹 페이지 컨텐츠의 일부 스트링
<title> - 검색 결과의 타이틀 - 캐시된 페이지의 KB 크기
<relatedInformationPresent> - related: 요청에 대한 true/false 값
<hostName> - 필터링이 수행되어 한 호스트에서 두 개의 결과가 노출되는 경우, 두 번째 결과에 추가적으로 호스트 네임이 기술된다.

SOAP에 의해 넘어온 검색 결과는 <화면 3>과 같은 형태가 될 것이다. 구글 웹 검색 APIs를 다운로드하면 자바로 작성된 간단한 패키지가 포함되어 있다. 이것은 자바를 통해 SOAP 메시지를 구성해 구글과 간단하게 통신할 수 있는 환경을 제공한다. 굳이 자바뿐 아니라 SOAP 처리를 위한 기타 프로그래밍 언어의 라이브러리도 다수 공개되어 있으니 개발자가 편의에 맞는 언어를 선택해 SOAP 프로토콜을 처리하는 데에는 그리 큰 어려움이 없다.

 

구글만이 가진 튼튼한 인프라 구조

 

지금까지 구글의 핵심 기술이라고 불릴 수 있는 요소들에 대해서 간략하게나마 살펴보았다. 검색에 대한 기술들이 상당 부분 오픈되어 있는 현재 상황으로 볼 때, 검색 기술에 대한 진입 장벽은 많이 높은 편이 아니다. 그럼에도 불구하고 구글이 검색 업계에서 독보적인 위치를 차지할 수 있는 것은 구글만이 갖고 있는 핵심 기술들이 선구적이고 핵심에 집중하며 멈추지 않고 성장하고 있기 때문이다. 게다가 그 기술들은 숨겨져 있는 것이 아니라 많은 개발자들을 위해 개방되어 있다. 구글의 기술이 개발자들에게 전파되고 전파된 기술들이 역으로 다시 구글을 발전시킨다.

 

사용자들이 흔히 말하는 바와 같이, 구글의 서비스가 구글스러울 수밖에 없는 것은 구글만이 갖고 있는 인프라 구조들이 버티고 있기 때문이다. 최하단의 인프라 구조들과 그것을 아우르는 프레임워크, 그리고 구글이 기술을 바라보는 철학이 최상단의 서비스에 영향을 미치고 있는 것이다.

 

제공 : DB포탈사이트 DBguide.net

반응형
반응형

정보보호전문가(SIS) 1, 2급 자격시험은 시행 3년만에 국가공인을 획득하여 조기에 공신력있는 자격제도로서 정착하였습니다.
※ SIS 1급(2005. 1.), SIS 2급(2004. 1.) 국가공인 획득

현재 SIS 취득자는 KISA, 기무사 등 각 계 정보보호 관련 종사자 채용시 우대받을 수 있습니다.

o 학점은행제를 통한 학사 취득시 학점인정
  - SIS 1급 취득시 24학점, 2급 취득시 12학점

자격명
인정 학점
표준교육과정 해당 전공
적용 시점
전문학사
학사
네트워크관리사 2급
18
정보통신, 컴퓨터네트워크
정보통신공학
2006년 4월
학점인정
신청자
인터넷정보검색사
(전문가, 1급)
8/4
인터넷정보
-
PC정비사 1급, 2급
6/3
-
-
리눅스마스터
1급,2급
18/6
-
-
정보보호전문가
1급,2급
24/12
정보보호
정보보호학

- 학점은행제란?
    고등학교 졸업자가 정규대학교에 다니지 않아도 평가인정된 사회교육시설 및 직업훈련기관의 학습과정을
    이수하거나 대학에서 시간제로 등록하여 교과목을 이수, 국가기술자격증 및 국가공인 민간자격 취득을 통해
    학점을 인정받아 전문 또는 학사 학위를 취득할 수 있는 평생교육제도
    ※ 학점은행제에 대한 자세한 내용은 한국교육개발원 홈페이지 참조(https://edubank.kedi.re.kr)

o 한국정보보호진흥원(KISA) 직원 채용시 우대

o 한국전력공사 통신직군 직원 채용시 우대
  ※ 한국전력 채용홈페이지 참조(ibsa.kepco.co.kr)

o 기무사 군무원 모집시 우대

o 육군 정보보호기술병 선발시 우대

* 연령 : 18세 이상 28세 이하자 (77.1.1 ~ 87.12.31 출생자)
* 학력 : 대학2년 수료 이상
* 신체 : 징병신체검사등검사규칙에 의한 신체등위 1~3급
* 자격기준
  - 전산관련학과, 정보보호학과, 전자 관련학과 전공자
  - 정보처리산업기사 이상 자격 취득자
   ※ 자격기준에 해당하는 지원자가 SIS 1,2급 자격을 소지한 경우 가점 부여


o 정통부 정보보호 관련 고시 중 기술인력의 자격요건
  - 취약점 분석·평가를 시행하려면 분석센터는 일정 조건을 만족하는 기술인력을 확보하여야 함
    ※「취약점 분석·평가를 수행하는 정보공유·분석센터의 기준 및 기준심사에 관한 고시(제2002-6호)」
제7조(정보보호유관분야 국내외자격) 규칙 제2조의 규정에 의한 규칙 별표 1 비고 제6호에서 "정보보호와 밀접한 관련이 있는 국내 또는 외국의 기술자격으로서 정보통신부장관이 정하는 자격"이라 함은 다음 각호의 자격을 말한다.
  1. 한국정보보호진흥원 및 한국정보통신대학교의 정보보호전문가 1급
  2.한국전산원의 정보시스템감리사
  3.정보시스템감사통제협회의 정보시스템감사사(CISA)
  4.국제정보보호컨소시움의 정보시스템보호전문가(CISSP)이외 정책적·법률적 혜택 부여를 통해
    우대 범위를 넓혀 SIS 자격증의 활용도를 높이는데 주력하고 있습니다.

o 정보보호관리체계 인증심사원 심사원보 자격요건
  - 한국정보보호진흥원이 조직에 대한 정보보호관리체계 인증심사 수행시 일정 능력을 지닌 기술인력 필요
  - 심사원보, 전문심사원, 심사원, 선임심사원으로 구성
정보기술 실무경력이 5년 이상이되, 이중 최소한 2년 이상은 정보보호 실무경력이어야 한다. 실무경력의 대체요건은 다음과 같다.
  - 다음의 자격증을 취득한 경우는 1년의 정보보호 실무경력을 추가로 인정한다.
    단, 자격증은 중복 인정하지 않는다.
    ㆍ한국정보보호진흥원의 정보보호전문가(SIS)
    ※ 홈페이지 참조(www.kisa.or.kr - 정보보호관리체계인증)

o 정통부 정보보호 관련 고시 중 감리원의 자격요건
  - 일정 경력과 감리원 유사자격(SIS 1급 등)을 소지한 경우 ‘감리원’으로 인정
    ※ 자세한 내용은 첨부한 고시 참조
     「정보시스템 감리원의 자격 및 교육 등에 관한 고시(제2006-34호)

제7조(감리 유사자격의 인정 범위) 영 별표 2의 비고 3에서 감리원 등급으로 인정되는 정보시스템 감리 유사자격이라 함은 다음 각 호의 자격 및 경력을 갖춘 자를 말한다.
3. 한국정보보호진흥원의 『국가공인 정보보호전문가(SIS) 1급』자격을 취득한 자(다만, 정보처리분야 업무 경력이 5년 이상인 자에 한한다)

이외 정책적·법률적 혜택 부여를 통해 우대 범위를 넓혀 SIS 자격증의 활용도를 높이는데 주력하고 있습니다.

반응형

'취미 그리고 생각' 카테고리의 다른 글

전문가가 되기 위해서 필요한 기술들  (0) 2007.08.08
UCC 오페라  (0) 2007.08.03
몸을 움직여 사는 사람  (0) 2007.07.07
신사의 조건  (0) 2007.07.07
비오는 제주도  (0) 2007.06.02
반응형

이전자료를 업데이트 했습니다.

SW기술자 등급별 일 노임단가
(단위:명,원,%)

구 분 2007년
조사인원
일 노임단가 전년대비
2006년도
2007년도
증가액 증가율
기술사

141

277,516

290,938

13,422

4.84

특급기술자

4,076

267,495

273,664

6,169

2.31

고급기술자

3,531

206,698

215,166

8,468

4.10

중급기술자

3,969

165,245

174,432

9,187

5.56

초급기술자

5,470

130,898

136,290

5,392

4.12

고급기능사

102

108,268

112,910

4,642

4.29

중급기능사

269

95,632

99,834

4,202

4.39

초급기능사

105

71,102

75,128

4,026

5.66

2006년 조사결과는 단순인원가중평균치임.(근무일 : 22.34일)
2007년 조사결과는 단순인원가중평균치임.(근무일 : 22.10일)

<시행일> 2008년 1월 1일부터

반응형

'삽질로그' 카테고리의 다른 글

FCKeditor java 버전 설치  (0) 2007.07.26
PCI-X 와 PCI-Express 의 비교사진  (0) 2007.07.12
[펌]자격증정보  (0) 2007.07.09
오라클설정내용  (0) 2007.07.05
관해난수(觀海難水)  (0) 2007.04.22
반응형

ITBANK멀티캠퍼스

자료 : http://www.itechtop.com

문의 : 02-3672-0009


뜨는 자격증, 지는 자격증

1500여종에 이르는 자격증 수에 못지않게 취득자 또한 1인 1자격증 시대라 할 만큼 자격증이 넘쳐나고 있다. 하지만 현재 자격증이 바라던 만큼의 가치를 갖고 있으며, 자격증 취득자가 현실적으로 원하는 취업이나 경력 향상에 도움이 되고 있을까? 물론 자격증만으로 이 모든 고민을 해결할 수 없다는 사실은 누구나 인정한다. 하지만 올바른 시각으로 자격증을 잘 활용한다면 그 가치는 충분하다. 이번 특집을 통해 IT 자격증의 현주소와 문제를 진단하고, 주목할 만한 자격증에는 무엇이 있는지 살펴본다. 지금 이 순간 IT 자격증을 준비하고 있다면 주목하기 바란다.


특집 1부. 1인 1자격증 시대의 자화상

박상훈│마이크로소프트웨어

자격증은 어떤 효용이 있을까. 실제 도움이 되기는 할까. 취업과 이직, 연봉과 관련해 거의 언제나 빠짐없이 등장하는 이 테마는 1500여 종에 이르는 다양한 자격증이 난립하면서 수많은 논쟁으로 이어지고 있다. 1인 1자격증 시대, 다른 사람들에게 뒤쳐지지 않기 위해 알아야 할 자격증 관련 흐름을 정리하고 자격증과 취업, 자격증과 연봉의 관계를 살펴본다.

한취업전문포탈 사이트가 국내 직장인 1932명을 대상으로 설문조사한 결과, 응답자의 63%가 한 가지 이상의 자격증을 갖고 있는 것으로 나타났다. 한국노동연구원이 발표한 자료에서도 국가기술자격 취득자 누계는 2002년까지 약 1767만 명으로, 지난 2004년 6월 현재 전체 경제활동인구 2358만명 가운데 75%가 1개 이상의 국가기술자격을 소지한 것으로 추정됐다. 2002년 이후 자격증 취득자 추세와 이 통계에 잡히지 않은 국제자격증 취득자를 포함하면 현재 우리들은 거의 1인 1자격증 시대를 살아가고 있다.

한편 자격증을 취득하지 않는 직장인 가운데 56.3%는 재직 중 자격증을 취득할 계획이 있다고 답했다. 주로 IT(34.1%)와 외국어(30.8%) 분야의 자격증을 선호했으며 경력 계발과 자기만족 등을 취득 이유로 꼽았다. 하지만 흥미로운 것은 응답자의 절반 이상인 57.1%가 직장생활 내에서는 ‘자격증의 활용도가 거의 없다’고 답한 사실이다. 유용하거나(27.6%) 연봉협상 시 중요한 영향을 미쳤거나 승진 시 가산점이 됐다(10.8%)는 응답은 소수에 그쳤다. 입사 시에도 별다른 영향이 미치지 못한 것(62.6%)으로 느끼고 있었다.

정리해보면 대다수의 직장인들은 자격증이 사회생활에 큰 도움이 되지 않는다는 사실을 알고 있지만 아이러니하게도 자기 자신은 새로운 자격증을 취득하려고 준비 중인 셈이다. 자격증 대중화 시대를 살고 있으면서도, 정작 자격증의 효용에 대해서는 서로 판이하게 다른 두 가지 시각이 공존하고 있는 현실, 이유가 무엇일까.

1200~1500여개 시행 중인 ‘자격증 천국’

현재 국내에서 취득할 수 있는 자격증은 국가자격증과 국가공인 민간자격증, 민간자격증 그리고 국제자격증 등 크게 네 가지로 구분된다. 국가자격증은 정부기관이 직접 시행, 주관하는 자격증으로 공무원 임용 시 가산점이나 학점 인정 등의 혜택이 주어진다. 국가공인 민간자격증이란 민간자격증 가운데 일정 요건을 갖춘 일부를 국가가 공인한 것으로, 국가자격증과 동일하게 취급받는다. 그리고 민간자격증은 민간 기업이나 단체가 시행, 주관하는 사설 자격증으로 수백 종에 달하는 것으로 알려져 있으며, 국제자격증은 주로 글로벌 벤더들이 운영하는 자격증으로 IT 분야에는 오라클, 시스코, MS, 썬 등이 대표적이다.

각 자격증별 종목 수는 <표 1>과 같다. 각종 기능사와 기사, 산업기사 등으로 구분되는 국가자격증은 2003년 11월 기준으로 27개 직무분야에서 총 637개 자격증이 시행되고 있으며 인터넷 정보검색사와 샵 마스터 등 국가공인 민간자격증은 46개가 운영 중이다. 국제자격증은 정확한 통계가 나와 있는 것이 없으며, 민간자격증은 조사기관에 따라 약 600여종으로 추정되고 있어, 현재 국내에서 시행되고 있는 자격증은 총 1200~1500여 종에 이른다.

국가자격증을 분야별로 보면 기계(19.6%), 금속(7.5%), 농림(6.6%) 분야의 자격증이 가장 많고, IT 관련 분야는 정보처리 분야 8개와 워드프로세서, 전자상거래운용사 등 기초 사무와 게임프로그래밍 전문가 등을 모두 포함해 20여 개로, 채 5%가 되지 않는다. 이러한 경향은 민간자격증도 마찬가지다. 지난 2003년 발표된 『민간자격 관리체제의 구축방안 연구』 보고서에 따르면 총 546개 민간자격증 가운데 119개가 보건과 사회복지사업 관련 자격증이었으며 95개는 사업 서비스업 관련 자격증으로 집계됐다. 통신업 관련 자격증은 단 2개에 불과했다.

이처럼 국가자격증 가운데 IT 분야의 자격증을 찾아보기 힘든 이유는 지난 1974년 국가기술자격법 제정 당시 중화학 공업과 건설 산업에 필요한 인력을 공급하기 위해 기계, 금속, 토목, 건축 분야의 자격증을 우선적으로 시행했기 때문이다. 이러한 현상은 지금까지 계속돼 중화학공업 위주의 자격증이 유지되고 있는데, 이 때문에 전자, 정보처리, 통신 등 IT 분야의 자격증은 급변하는 기술 수준을 따르지 못해 활용도가 떨어지고 있다는 지적을 받고 있다.

국가자격증과 민간자격증이 IT 자격증을 마련하는데 소극적으로 대응하는 사이 오라클과 시스코, 썬, MS 등 주요 기술 업체들과 CIW, ISACA, ISC2 등의 단체들은 다양한 국제 IT 전문 기술 자격증 70~100여 종을 국내에서 시행하고 있다.

<표 1> 국내 시행 중인 자격증

구분 국가자격 민간자격 국제자격증
국가기술자격법과
개벽법에 의한 국가자격
국가공인 민간자격 비공인 민간자격
종목수 국가기술자격법에
의한 622개 종목
(한국산업인력공단 601종목,
대한상공회의소 21종목),
개별법에 의한 120개 종목
자격의 검정·
검정과목·응시자격 등
검정수준이 국가자격에 상당하다고 판단하여 2004년 2월 현재 국가에서 인정한 46개 종목
민간자격 검정기관에서 시행하여 실시하는 자격시험으로 정확한 통계는 없으나 한국직업능력개발원에서는 약 600여 개로 추정 주요 해외 업체와 단체에서 시행하는 자격증을 국내에서 시행하는 것
IT
관련
종목
워드프로세서,
전자상거래관리사,
전자상거래운용사,
컴퓨터활용능력,
컴퓨터운용사,
정보통신설비사,
정보처리산업기사/
기사/기능사,
정보관리기술사,
정보기술산업기사 등
E테스트 프로세셔널, 정보시스템감리사,
PC활용능력평가시험,인터넷정보검색사,
리눅스마스터, 정보기술자격,
네트워크관리사 등
소비자상담사,
노인복지사,
심리상담사 등
시스코의 CCNA,
CCDA, CCNP,
오라클의 CCP, OCM,
썬의 SCJP, SCJD,
MS의 MCSE, MCSA를
비롯해 C/W, ISACA,
ISC2 등의 단체가
시행하는 자격증등
혜택 국가공인자격증 혜택 부여 법적으로 공인된 헤택 없음.
자사 취업시 일부 혜택 있음

곤두박질치고 있는 국가자격증

지금의 국가자격증 체계는 지난 1999년에 큰 폭의 변화를 시도한 이후 현재까지 이어져 오고 있다. 당시 기술계와 기능계로 구분돼 있던 직무분야를 통합해 <그림 1>과 같이 단순화하고, 자격 등급도 8단계에서 5단계로 간소화시켰다. 특히 학력보다 산업현장 경력을 우대한다는 취지에 따라 응시요건에서 산업현장 경력 연수를 줄였으며 일본과 IT 자격증을 상호 인증(APEC)한 것도 이 즈음이다.

그러나 이러한 개선에도 불구하고 지난 1999년을 기점으로 국가기술자격 취득자 수는 매년 감소하고 있다. 주로 고급 기술자격인 기술사와 실무를 담당하는 기능사 등급의 자격 취득자가 급감하고 있는데, 기술사의 경우 지난 1999년 취득자가 2041명이었던 것이 2002년에는 1382명으로 줄어들었다. 기능사 자격증 취득자도 한해 47만 명에 육박했으나 2002년에는 32만 명 수준으로 떨어졌다.

이러한 경향은 IT 분야의 자격증에도 공통적으로 나타나고 있다. 대표적인 IT 국가자격증인 정보처리기능사의 경우 2000년 27만 명이 원서를 접수했지만 매년 3만 명씩 줄어들어 2003년에는 19만 명까지 감소했다. 특징적인 것은 정보처리기사의 원서 접수자와 최종 합격자 수가 큰 폭으로 증가하고 있는 점이다(<표 2>). 이것은 4년제 대학 졸업자들이 취업을 위해 대규모로 기사 자격증 취득에 나섰기 때문인데, 정보처리기사 자격증의 실효성이 높아서라기 보다는 청년실업이 심각해지면서 학점 인정과 가산점 등 국가자격증의 혜택을 노린 수요로 해석된다.

전문가들은 국가자격증 제도의 출발점과 최근의 운영실태를 보면서 현재의 자격증 체계가 새로운 트렌드를 반영하기에는 자격증 종목이 너무 단순하다고 지적한다. 특히 IT 분야의 경우 워드프로세서 자격증, 전자상거래관리사 자격증, 컴퓨터활용능력 자격증 등 기초적인 자격증에 집중돼 있고 오픈소스나 임베디드, 유비쿼터스, 보안 등 최신 IT 기술의 흐름을 반영한 자격증을 효과적으로 내놓지 못하고 있다. 이에 따라 정부가 마련한 대안이 국가공인 민간자격증 제도이다.

<그림 1> 현재의 국가기술자격의 등급별 응시자격

민간자격증, 수백 종 가운데 진주찾기

국가공인 민간자격증 제도는 지난 1997년에 자격기본법이 제정되면서 시작됐다. 새로운 분야의 자격증을 발굴하고 민간자격을 활성화하기 위한 제도로, 국가자격증의 커리큘럼이 다양하지 못하고 최신 기술 트렌드를 반영하지 못하는 문제를 일정 부분 해소해 줄 것으로 기대를 모았다. 이들 민간자격증은 국가자격증과 동일한 효력을 발휘하기 때문에 수험자들의 큰 관심을 모았는데, 유통관리사 자격증의 경우 기사자격과 마찬가지로 30학점을 인정해 주기 때문에 편입준비에 이용되기도 했다.

이에 따라 지난 2001년에만 게임프로그래밍전문가, 멀티미디어전문가, 게임디자인전문가, 게임시나리오전문가, 애니메이션전문가, 게임그래픽디자인전문가, 웹디자인기능사 등 다양한 IT 자격증이 선보였다. 당시 큰 주목을 받았던 게임 개발과 멀티미디어 분야에서 집중적으로 신설됐음을 알 수 있다. 특히 올해 국가공인을 받은 리눅스마스터는 국제자격증이 담당하던 영역을 국내 자격증을 대체하기 위한 시도라는 평가를 받았다.

그러나 일부 사례를 제외하면 국가공인 민간자격증 제도 역시 IT 기술의 빠른 흐름을 반영하지 못하고 있다. 국가공인을 신청하는 자격증을 종목별로 구분해 보면 스포츠·건강 분야가 가장 많고 컴퓨터 정보기술은 매년 18~20건 수준에 머물러 있다. 이 가운데 실제 공인을 받은 경우는 2001년 이후 연간 5~7건에 머물러 있으며 그나마 IT 분야는 한두 건에 불과하다. 매년 이전 심사에서 탈락된 자격증이 다시 신청하는 경우도 많아 새로운 커리큘럼을 육성한다는 당초 취지를 무색케 하고 있다.

한편 민간자격증 수가 폭증하면서 이를 둘러싼 소비자들의 피해도 증가하고 있다. 한국소비자보호원이 발표한 『통신판매로 구입한 자격증 교재 관련 소비자 상담 및 피해구제 건수』 보고서에 따르면 2002년 총 1074건에서 2003년 1180건으로 9.9% 증가한 것으로 나타났다. 이 가운데 IT 관련 자격증이 연관된 것은 전자상거래관리사가 유일했으며 그것도 환불 관련된 것이어서 IT 자격증을 이용한 사기 시도가 많지는 않는 것으로 보인다.

그러나 이와 같은 일련의 사건들은 민간자격증에 대한 전반적인 불신을 키웠으며, 국가자격증의 보완재로서 제자리를 찾는데도 실패해 IT 업계의 수요를 만족시킬 만한 자격증이 많지 않다는 것이 전문가들의 중론이다. 최근 몇년 사이 국제자격증에 대한 관심이 높아지고 있는 것도 이런 현실에 대한 반작용이었다.

<표 2> 정보처리기사 연도별 합격자 추이

년도 원서접수자 최종응시자 최종합격자 합격률
2003 154652 114988 45744 39.8%
2002 116299 87805 34379 39.2%
2001 102008 73783 21114 28.6%
2000 85403 59705 14507 24.3%
1999 76830 62594 13013 20.8%
96~98 141854 108960 16480 15.1%
92~95 143819 108569 20371 18.8%
84~91 124607 101287 20014 19.8%
77~83 8010 6204 1557 25.1%

<표 3> 2005년 현재 국가공인민간자격증 현황
이름 등급 자격관리자 유효기간
E-TEST Professional 1,2,3,4급 삼성SDS 03.2.17~07.2.16
정보시스템관리사   한국전산원 03.2.17~07.2.16
PC활용능력평가시험(PCT)   피씨티 03.2.17~07.2.16
인터넷정보검색사 전문가, 1, 2급 한국정보통신산업협회 03.2.17~07.2.16
리눅스마스터 1, 2급 한국정보통신산업협회 05.1.15~07.1.14
네트워크관리사 2급 한국정보통신자격협회 04.1.20~08.1.19
PC정비사 1, 2급 한국정보통신자격협회 05.1.15~07.1.14
정보기술자격(ITQ)시험 A, B, C급 한국생산성본부 04.1.20~08.1.19
공무원정보이용능력평가(NIT)   한국정보문화진흥원 05.2.17~09.2.16
디지털정보활용능력(DIAT) 초, 중, 고급 한국정보통신대학교 05.2.17~09.2.16
정보보호전문가(SIS) 1급 한국정보보호진흥원 04.1.20~06.1.19
2급 한국정보보호진흥원 05.2.17~07.2.16
컴퓨터운용사   대한상공회의소 00.12.22~05.12.21

<표 4> 국가공인 민간자격증 취득자 현황
자격증 취득자수
인터넷정보검색사 전문가 70
1급 9,289
2급 161,696
PC활용능력평가시험(PCT) A 113
B 4306
정보시스템관리사   76
정보기술자격(ITQ)(A, B, C급)   131661
네트워크관리사 2급   4910
E-TEST Professional 1급 7438
2급 22401
3급 19924
4급 14935
공무원정보이용능력평가(NIT)   126
디지털정보활용능력(DIAT) 고급 12
중급 283
초급 617
377,857

출처│한국직업능력개발원, 2003년 6월 기준

국제자격증, 맹신은 금물

국내에 국제자격증이 처음 도입된 것은 노벨 공인 네트워크 전문가 자격증인 CNE(Certified Novell Engineer)가 시행된 지난 1989년이다. 이후 MS, 오라클, 시스코, HP, 썬, IBM 등이 자사의 국제자격증을 국내에 선보였으며 쓰리콤, 로터스, 인텔, 인포믹스, 노텔, SAP, 리버스톤, 스니퍼 등도 선별적으로 자격증 프로그램을 운영하고 있다(<표 5>).

국제자격증은 초기에 협력업체나 관련업계 종사자 위주로 운영했으나 외국계 기업의 국내 진출이 활발해지고 이들 기업이나 협력업체 취업 시 이점을 기대하는 수요가 몰리면서 최근엔 취업준비생들이 주로 취득할 만큼 응시대상이 다양해졌다. 특히 MS와 시스코는 국내 대학에 정규 교과과목을 개설하고 자격증을 취득하도록 지원하는 방식으로 학생층 공략에 가장 성공한 사례로 유명하다.

그러나 일반에 알려진 인식과 달리 국제자격증에 대해서는 체계적인 통계가 없다. 무엇보다 밴더별로 취득자 수 공개를 꺼리고 있는데다, CIW(Certified Internet Webmaster)의 경우 이를 취득하면 연간 12% 연봉 인상을 받을 수 있는 것으로 홍보하고 있지만 미국 국내에 국한된 이야기이거나 공신력 있는 검증이 이루어진 바가 없다. 국내에서는 이들 업체의 협력사 자격을 취득할 때 해당 IT 벤더의 자격증을 소지한 직원이 일정 인원 이상 필요하고, 이 때문에 회사 차원에서 전략적으로 취득한 경우가 많아, 개별 취득자들이 어떤 혜택을 보았는지 통계를 뽑기가 쉽지 않다.

대신 지난 2003년 말에 발표한 IDC 보고서 『Worldwide and US IT Certification Forecast and Analysis, 2003~2007』는 국제자격증의 흐름을 읽을 수 있는 단초를 제공한다. 당시 IDC는 자격증 벤더와 교육기관, 시험 대행기관 등 28개 주요 업체들에 대한 심층 인터뷰를 통해 이 보고서를 작성했다. 이에 따르면 주요 IT 벤더들은 과거의 기술 중심 자격증에서 탈피해 역할과 업무 기반의 자격증을 소개하는데 주력하고 있다. MS가 보안전문가를 겨냥해 출시한 MCSE-Security와 MCSA-Security가 대표적인 사례이며 HP도 지난 2003년 이후 채널과 협력사를 겨냥한 여러 가지 신규 자격증들을 선보이고 있다.

국제자격증을 작업 역할별로 구분하면 가장 많은 것은 시스템 운영(Operation System) 분야로 서버와 윈도우, 유닉스, 리눅스 등 운영체제 기술에 초점이 맞춰져 있다(<그림 2>). ComTIA의 Linux+, 썬의 CSSA, MS의 MCSE 등이 대표적이다. 일반(General)은 초보 IT 직원들을 겨냥한 자격증으로, ComTIA의 A+와 MS의 MCP 등을 꼽을 수 있다. 네트워킹은 네트워크 인프라를 다루는 분야로, 시스코의 CCIE, 노텔의 CSS, 노벨의 CNE, 노벨의 CAN, ComTIA의 Network+ 등이 여기에 속한다. 애플리케이션 개발은 일반적인 프로그래밍의 영역으로 썬의 자바2 플랫폼 기반 자격증들이 대표적이다.

자격증을 난이도에 따라 초급, 중급, 고급으로 나눠보면 <그림 3>과 같다. 당초 IDC는 2001~2002년 IT 업계의 침체로 이 분야에 대한 신규 진출자가 줄어들면서 초보자용 자격증 비율이 다소 감소할 것으로 전망했다. 그러나 2003년 초보 자격증 보유자는 미약하지만 약간 증가했다.

IDC는 그 원인을 대규모 해외 아웃소싱으로 설명했다. 인도와 아태지역으로 대규모 아웃소싱을 단행하면서 이들이 대거 초보자용 IT 자격증 취득에 나선 것이라는 분석이다. 실제로 인텔은 인도에서 500명 규모의 신규 채용을 단행했으며 시스코는 2100명, SAP는 500명을 채용해 소프트웨어 개발을 맡겼다. MS와 오라클은 각각 500명과 2400명 규모의 신규 인력을 인도에서 채용했다. 해외 아웃소싱은 애플리케이션 개발, 기술 통합, 제품 개발, 테스팅 등 복잡한 업무까지 확대되고 있어 이러한 경향은 당분간 계속될 것으로 보인다.

<그림 2> 역할별 국제자격증 구분


<표 5> 국내 IT 업체들의 자격증 프로그램

업체 자격증 대상
시스코 CCNA/CCNP 네트워크 초보 입문자/500노드 이상의 네트워크 전문가
  CCDA/CCDP 중소규모/500노드 이상의 네트워크 설계 전문가
  CCIP 시스코 인프라와 액세스 솔루션 전문가
  CCIE 인터네트워킹 숙련도를 측정하는 시스코 최고 전문가
  CCSP 가상사설망, 침입탐지시스템 등 보안부문 전문가
CompTIA A+ 국제적으로 인정받는 PC 정비사
  Network+ 네트워크에 대한 일반적인 지식을 갖춘 초보자
  Linux+ 리눅스 초보자
  IT Project+ IT 프로젝트 관리자
  Security+ 초보 보안 관리자
HP HPCP/Advanced HPCP 유닉스 시스템 기반의 네트워크 전문가
CIW CIW Associotes/ 인터넷 기술 전문가
  Professional / Master  
Sair Linux LPIC 리눅스 관리자
Sair/GNU LCP 특정 벤더에 종속적이지 않은 리눅스 엔지니어
MS MCSA 윈도우 2000과 닷넷 서버 플랫폼 관리자
  MCSE 윈도우 2000 기반 인프라 구현 전문가
  MCDBA SQL 서버 DB 관리자
  MCSD MS 플랫폼 기반 기업용 솔루션 개발자
  MCAD VS와 XML 웹 서비스 툴을 이용한 개발자
  MCT MS 공인 강사
오라클 OCP-DBA 초보 오라클 관리자
  OCM 오라클 전문가
  OCAD 오라클 디벨로퍼를 이용한 개발자
SCJP 초보 자바 개발자
  SCJD 실무 개발능력이 입증된 자바 개발자
  SCEJ 최고 수준의 자바 응용 프로그램 개발자
  SCNA 솔라리스와 유닉스 환경의 네트워크 관리자
  SCSA 스토리지 전문가
  SCD J2EE를 이용한 애플리케이션 개발자
ISACA CISA 전산 정보 감사 전문가
ISC2 CIPPS 기업 정보 자산 보호 전문가

미국내 국제자격증의 해외 진출 동향은 곧 국내 자격증 시장에도 직접적인 영향을 미친다. 오라클이 지난 해 2월에 ERP 전문가 자격증인 ‘OES(Oracle E-business Specialist)’를 국내에 선보인 것을 비롯해 주요 글로벌 IT 벤더들이 국내에 자사의 최신 자격증 프로그램을 선보이고 있는 것은 아태지역 시장을 중심으로 자격증의 해외진출 계획을 마련하라고 했던 충고했던 IDC 보고서와 완벽하게 일치하는 것이다. 자국내 자격증 시장의 불황 타계책으로 해외 진출을 적극 검토하는 것으로 해석할 수 있다.

한편 2003년 한해 동안 가장 많은 자격증 취득자를 배출한 업체는 MS인 것으로 나타났으며 시스코와 썬, ComTIA가 그 뒤를 이었다. 전세계 자격증 시험시행 횟수는 2000년 3500만 회를 기점으로 급격히 줄어들어 2003년에도 전년 대비 20% 가량 감소한 260만 회에 머물렀다.

IDC는 향후 가장 주목할 만한 자격증 분야로 보안을 꼽았다. 보안은 최근 가파른 성장세를 보이는 분야인데, 특히 금융권의 경우 단 한 번의 보안 사고로도 치명적인 영향을 받을 수 있어 큰 관심을 갖고 있다. 벤더 중립적인 CISSP을 비롯해 ComTIA의 Security+, MS의 MCSE-Security, MCSA-Security 등이 대표적이다. 일부에서는 벤더 중립적인 보안 자격증의 수가 많다고 지적하지만 시장이 지원할 수 없을 정도가 되면 경쟁력이 없는 자격증은 자연스럽게 도퇴될 것으로 전망된다.

스토리지 역시 주목받고 있다. 기업 IT 관리자들은 SAN(Storage Area Networks)을 비롯해 복잡한 스토리지 환경을 능숙하게 다룰 수 있는 전문가가 부족하다고 호소하고 있다. 이에 따라 EMC의 POA(Proven Operator Associate)나 브로케이드의 CSD(Certified SAN Designer) 등 스토리지 분야의 자격증은 향후에도 꾸준히 수요가 늘 것으로 전망된다.

취업엔 ‘플러스’, 연봉엔 ‘글쎄(?)’

지금까지 국가자격증과 국가공인 민간자격증, 민간자격증, 그리고 국제자격증에 대해 현황을 중심으로 살펴봤다. 이들 자격증들은 국가자격증의 경우 취득하는데 평균 7개월에 21만 7000원의 비용이 소요되고(한국노동연구원 발표), 국제자격증은 일반적으로 이보다 훨씬 많은 비용이 소요되기 때문에 그 효용을 둘러싸고 논쟁이 계속됐다. 특히 자격증과 연봉, 자격증과 취업률의 관계는 자격증의 효용을 판단하는 바로미터였다. 이에 대해서는 그동안 찬반논란이 많았는데 실제 연구보고서에서도 그 결과가 엇갈리고 있다.

지난 2003년 중앙고용정보원이 발표한 『자격증이 임금에 미치는 영향을 조사한 보고서』에 따르면 전체적으로 자격증 취득자가 비자격자보다 월 평균 40만 7000원 가량 임금을 더 받는 것으로 나타났다(<표 6>). 이 보고서는 전국 5만 가구 총 7만 1368명을 조사한 것이다. 여기서는 국가자격체계에 대한 부가가치도 계산했는데, 자격증 취득자가 더 받는 금액은 한 달 기준 1890억 원, 연간 2조 2600억 원이므로, 국가자격체계를 유지하는데 들어가는 비용 317억 원과 비교하면 엄청난 사회적인 부가가치를 창출하는 것이라고 주장했다.

흥미로운 것은 직종별 연봉에의 영향을 평가한 내용이다. 보건의료직에서 가장 임금 차이(+84%)가 큰 반면 웹 디자이너(-34%), 컴퓨터 시스템 설계사(-136%), 시스템 운영 관리자(-30%) 등 일부 IT 관련직종에서는 오히려 자격증 보유자의 임금이 낮게 나타났다. 보고서는 이런 현상에 대해 직업에 필요한 특정 자격이 없는 직종이기 때문이라고 분석했는데, 이는 곧 국가자격증 가운데 IT 실무에 도움이 되는 자격증이 없다는 의미와도 같은 것으로 해석된다.

반면 지난 해 5월에 한국노동연구원이 발표한 『자격과 노동시장 연구』에 따르면 자격증은 취업에는 도움을 주지만 임금에는 의미있는 효과를 주지 못하며, 그 효과도 점차 감소하는 추세인 것으로 나타났다. 이는 학교를 마친 졸업자와 중퇴자 8623명을 조사한 것인데, 자격증 보유자의 경제활동 참가율은 76.4%로 자격증 미보유자 64.6%에 비해 11% 가량 높았다. 자격증이 취업이나 구직활동 등 노동시장에 참가하는데 유리하게 작용했다는 것이다.

그러나 자격증이 임금에 주는 효과에 대해서는 대체로 남성이 여성보다 임금이 높으며 연령과 근속, 학력, 근로시간이 늘어날수록 임금이 높아지는 일반적인 임금함수의 특성을 나타냈다. 임금에 미치는 다양한 요인들을 통제하고 자격증의 임금 프리미엄이 있는지를 조사했을 때는 의미있는 상승효과가 나타나지 않았다. 보고서는 자격증의 임금효과가 2002년을 기점으로 마이너스로 돌아서 현재는 사실상 효과를 상실한 것으로 결론내렸다(<그림 4>).

이 밖에도 자격증과 임금의 상관관계에 대해 서로 다른 해석을 제시한 보고서는 매우 다양하다. 그러나 이들 보고서가 공통적으로 지적하는 것은 현행 자격증 제도가 취업 상태의 직장인들의 능력 개발을 유도하는 기능이 매우 미약해 직무수행에 필요한 능력을 향상시키는 수단으로는 제대로 기능하지 못하고 있으며 임금에 미치는 영향도 점차 감소하고 있다는 점이다. 특히 대졸 취업준비생을 중심으로 고학력자의 자격 취득률이 높아지면서(앞서 살펴본 <표 2> 참조) 자격증의 시장성이 크게 저하되고 있으며 노동 시장과 기술의 변화를 효과적으로 반영하지 못하고 있다는 부분도 반복해서 지적되고 있다.

그러나 자격증에 대한 이러한 평가가 곧 자격증 무용론으로 연결되는 것은 아니다. 이들 보고서의 또 다른 공통적인 결론은 자격증이 취업에 일정 정도 긍정적인 영향을 미치고 있다는 것이다. 특히 전문가들은 새로운 기술 트렌드를 반영한 자격증에 주목할 필요가 있다고 조언하는데, 이들은 이미 시장이 형상된 이후에 개설되고 취득자가 많지 않아 희소성이 있다는 점 등을 근거로 들었다. 단, 아직 국가공인을 받지 못한 민간자격증이라면 충분하게 옥석을 가릴 필요가 있다.

<표 6> 자격증이 임금에 미치는 영향


<그림 3> 숙련도에 따른 자격증 취득자 분포
출처│ IDC, 2003



<그림 4> 자격증이 임금효과

자격증 활용 전략을 세워라

지금까지 국내에서 시행 중인 자격증의 현황과 임금, 취업률에 미치는 영향 등을 살펴봤다. 자격증의 효용에 대해서는 의문을 갖고 있지만 가까운 장래에 취득할 계획을 갖고 있는 우리나라 직장인들의 이중적인 관점은 사실 지금까지 살펴본 것처럼 자격증 제도의 한계에서 출발했다고 보는 것이 옳다. 짧지 않은 시간과 적지 않은 비용, 부단한 노력이 필요한 자격증, 이것을 직장 생활에 더 효과적인 ‘수단’으로 활용하기 위해 더 치밀한 자격증 전략이 필요한 것도 이 때문이다.

반응형

'삽질로그' 카테고리의 다른 글

PCI-X 와 PCI-Express 의 비교사진  (0) 2007.07.12
소프트웨어기술자 등급별 노임단가기준(2008)  (0) 2007.07.09
오라클설정내용  (0) 2007.07.05
관해난수(觀海難水)  (0) 2007.04.22
전자렌지 요리법  (0) 2007.03.16
반응형
몸을 움직여 사는 사람은 쓰임새가 헤튼 반면에,
돈을 움직여 사는 사람은 쓰임새가 여물다고 합니다.
그러나 헤프닥는 사실 속에는 헤플 수밖에 없는
대단히 중요한 까닭이 있습니다.
첫째 노동에 대한 신뢰입니다.
일해서 벌면 된다고 생각하기 때문입니다.
그리고 또 한가지는 인간 관계입니다.
노동은 대개 여럿이 함께하는 것이어서
인관 관계가 끈끈하기 때문입니다.
더불어 일하고 더불어 써야 할 일이 많기 때문입니다.
몸 움직여 사는 사람이 헤프다는 것은
이를테면 구두가 발보다 조금 크다는
합리적인 필요 그 자체일 뿐
결코 인격적 결함이라 할 수 없습니다.
헤프다는 것은 스스로의 역량을 신뢰하고,
더불어 살아가는 삶을 당연하게 여긴다는 점에서
오히여 지극히 인간적인 품성이라고 해야 할 것입니다.


신영복.몸을움직여사는사람
반응형

'취미 그리고 생각' 카테고리의 다른 글

UCC 오페라  (0) 2007.08.03
학점인정 정보  (0) 2007.07.09
신사의 조건  (0) 2007.07.07
비오는 제주도  (0) 2007.06.02
10개월만에 다시 방문한 광주  (0) 2007.06.02
반응형

거동에 있어서의 간소
언어에 있어서의 세심
열광에 있어서의 신중
절망에 있어서의 인내

윌리에.드.릴라당<센티멘텔리즘>
반응형

'취미 그리고 생각' 카테고리의 다른 글

학점인정 정보  (0) 2007.07.09
몸을 움직여 사는 사람  (0) 2007.07.07
비오는 제주도  (0) 2007.06.02
10개월만에 다시 방문한 광주  (0) 2007.06.02
잠깐 쉬어가기  (0) 2007.03.14
반응형
/* 개념잡기 */
  오라클에서 데이터베이스의 개념은 MSSQL이나 mysql과는 약간 다르다.
mysql의 경우 mysql로 접속을 한 후, 그 안에서 "create database 디비명;" 과 같은 명령어로 디비를 만들어 쓴다.
오라클에서는 이런 종류의 디비를 테이블 스페이스라고 부른다. 그리고 오라클에서 DB라고 부르는 것은 인스턴스 라고 한다. (JSP컨테이너인 JRun이나 Weblogic에서 서버를 여러개 만들어 쓰는것과 비슷한 이치라고 생각된다.)


/* 데이터베이스 생성 & 삭제 */
  윈도우에서는 Database Configuration Assistant를 누르면 디비를 생성할 수 있는데,
솔라리스에서는 메뉴에서 선택할 수 없어서 당황스럽다.
쉘에서 dbca 라고 치면 Database Configuration Assistant 창이 나타난다. (xwindow가 반드시 있어야 하며, 없다면 수동으로 생성해줘야 한다. 그러나 쉽지 않고, 자료도 많지 않다는걸 염두해두자.)
삭제도 이 툴에서 할 수 있다.


/* 접속할 데이터베이스 선택하기 */
  디비를 생성하고 sqlplus로 접속하려고 시도해 보면 계속 기본적으로 처음에 오라클 설치시 같이 깔았던 디비만 선택되서 당황스럽다. sqlplus로 접속할 디비를 선택하고 싶다면,
사용자 계정의 .profile 또는 .bash_profile(리눅스)에 들어가서 SID를 변경하면 된다.
  또는 디비별로 솔라리스 유저계정을 따로 두는것도 한 방법이다. 이 경우, 기본적으로 오라클 계정으로 셋팅했던 .profile을 복사해서 가져온 후 SID부분을 수정해준다.


/* sqlplus 접속하기 */
  데이터베이스를 생성할 때 암호를 넣게 되어있는데, 혹시 아무생각없이 지나가버렸다면 기본적으로 생성되는 암호는 아래와 같다.
sys      / change_on_install
system / manager
scott    / tiger

비밀번호를 안넣은게 아니라 까먹었다면
$ sqlplus "/as sysdba"
SQL> alter user sys identified by 암호;
SQL> alter user system identified by 암호;
(이 부분에 대해서는 windows에서는 테스트를 해봤는데, 솔라리스로는 테스트를 해보지 못했습니다.)

버전정보)
$ sqlplus '/as sysdba'

Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production


사용자생성)
-----------------------------------------------------------
create user bmsuser identified by bmsuser
default tablespace users
temporary tablespace temp;

grant connect, resource to bmsuser;

계정 접속확인)
$ sqlplus bmsuser/bmsuser


테이블스페이스생성)
-------------------------------------
TS_BMS(업무관리시스템), IX_BMS(인덱스), LO_BMS

생성)
CREATE TABLESPACE TS_BMS DATAFILE '/oradata/bms/bms_table01.dbf' SIZE 500M AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED;
CREATE TABLESPACE IX_BMS DATAFILE '/oradata/bms/bms_index01.dbf' SIZE 500M AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED;
CREATE TABLESPACE LO_BMS DATAFILE '/oradata/bms/bms_lodata.dbf' SIZE 500M AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED;


생성된 테이블스페이스 보기)
select tablespace_name, status from DBA_TABLESPACES


/* 테이블 스페이스 생성 & 삭제 */
SQL> create tablespace 테이블스페이스명
         datafile '/파일경로/파일명.dbf' size 1024m
         default storage(initial 1024m next 100m pctincrease 10);
         // 데이터가 initial 사이즈를 넘어서면 next * pctincrease 만큼 연속된 공간을 확보한다.

SQL> select tablespace_name, status from DBA_TABLESPACES; 
         // 테이블 스페이스 목록보기

SQL> drop tablespace 테이블스페이스명;      //삭제
         // .dbf 데이터 파일은 자동으로 지워지지 않으므로 찾아서 지워줘야한다.


/* 유저 생성 및 권한 주기 */
SQL> create user 유저명 identified by 암호
         default tablespace 테이블스페이스명
         temporary tablespace temp;
SQL> grant connect, resource, dba to 유저명;

SQL> select username, default_tablespace from DBA_USERS;
          //유저 목록 보기

SQL> drop user 유저명 cascade;                  //유저삭제
         //cascade를 쓰면 유저명과 관련된 스키마들이 같이 삭제된다.
반응형

'삽질로그' 카테고리의 다른 글

소프트웨어기술자 등급별 노임단가기준(2008)  (0) 2007.07.09
[펌]자격증정보  (0) 2007.07.09
관해난수(觀海難水)  (0) 2007.04.22
전자렌지 요리법  (0) 2007.03.16
기업체 영문 직급  (0) 2007.03.16

+ Recent posts