자주쓰는 참고소스2006. 1. 23. 14:06
  • HTML에 JavaScript 삽입
    <script language="javascript">
    JavaScript Statements
    </script>


  • HTML에 JavaScript 코드 파일 삽입
    <script language="javascipt" src="src.js">
    </script>


  • 변수의 대소문자 구분

  • 변수에 포함된 데이터의 형을 지정하지 않고, JavaScript 인터프리터가 변수에 포함된 데이터 형을 추적하고 변환.

  • JavaScript 데이터 형
    • 숫 자 형 : 정수와 부동 소수
    • BOOLEAN : true, false
    • STRING : 작은 따옴표나 큰 따옴표에 들어가 있는 값으로, 특수문자 포맷 사용시에는 '\'와 함께 사용.
    • null : 아무런 값도 없는 것으로, 변수를 초기화 시키거나 어떤 값이나 이벤트를 지울 때 사용됨
    • undefined : 변수만 만들고, 값을 할당하지 않은 상태

  • 유형간의 변환
    • 스트링 피연산자가 비스트링 연산자와 사용된 경우 다른 연산자를 모두 스트링으로 변환
    • BOOLEAN값은 1과 0으로 변환되어 수치 연산을 지원
    • null값은 스트링 연산에 대해서는 "null", 논리 연산에서는 false, 그리고 수치 연산에서는 0으로 각각 변환
    • 변환 함수
      • eval() : 스트링 표현식을 수치값으로 변환하고, 파라미터가 수치형태가 아닌 스트링 값이면 에러 발생
      • parseInt() : 스트링에 포함된 첫번째 정수를 리턴하고, 스트링이 정수로 시작되지 않으면 0을 리턴
      • parseFloat() : 스트링에 포함된 첫번째 부동 소수를 리턴하거나 스트링이 적절한 부동 소수로 시작되지 않으면 0을 리턴

  • 배열 : 값의 시퀀스를 정렬할 수 있는 객체로, JavaScript의 특수형으로 배열 사용 전엔 반드시 선언해야 한다.
    • 배열 선언 예
      arrayName = new Array(arrayLength)
      arrayName = new Array()
      arrayName = new Array(value0,value1, ..., valuen)

  • JavaScript만의 특수 연산자
    • comma(,) 연산자 : 두 표현식을 계산하고, 두 번째 표현식의 값 리턴
    • delete 연산자 : 객체의 프로퍼티나 배열 인덱스의 요소 삭제하고, 항상 undefined 값 리턴
    • new 연산자 : 객체 형의 인스턴스를 만들기 위해 사용
    • typeof 연산자 : 연산자의 형을 식별하는 스트링 값을 리턴
    • void 연산자 : 값을 리턴하지 않는다

  • 지역 변수와 전역 변수 : 함수 안에서만 사용되는 것을 지역 변수라 하고, 프로그램 내에서 사용되는 변수를 전역 변수라 하는 데, 지역 변수 사용시 반드시 var 키워드와 함께 선언해야 함

이벤트 처리!!

  • 이벤트 정의와 사용
    • 이벤트 : 사용자가 웹페이지나 기타 다른 브라우저에 수행한 작업으로 인한 결과
    • 이벤트 처리 : 이벤트로 인해 수행되는 프로세스
    • 이벤트 핸들러 : 프로세스를 수행하는 코드
    • 사용 예 : 사용자가 링크 위로 마우스를 갖다 대면 다이얼로그 박스를 표시한다거나, 폼에 입력한 데이터를 검증한다거나, 버튼을 클릭할 때 애니메이션을 나타내거나, Java 애플릿과 브라우저 플러그인이 상호작용을 하도록 한다.

  • JavaScript가 정의한 이벤트
    HTML 태그 JavaScript 이벤트 설명
    다양 mouseMove 마우스 이동
    <A>..</A> Click 마우스로 링크를 클릭
    dbClick 마우스를 링크위에서 더블클릭
    mouseDown 마우스 버튼을 누름
    mouseUp 마우스 버튼을 놓음
    mouseOver 마우스를 링크위로 이동
    mouseOut 링크 위에 있던 마우스를 링크 밖으로 이동
    keyDown 사용자가 키를 누름
    keyUp 사용자가 키를 놓음
    keyPress 사용자가 키를 눌렀다가 놓음
    <IMG> abort 사용자 액션으로 인해 이미지 로딩 작업을 중단함
    error 이미지 로딩하는 동안 에러 발생
    load 이미지가 로드되고 화면에 나타남
    keyDown 사용자가 키를 누름
    keyUp 사용자가 키를 놓음
    keyPress 사용자가 키를 눌렀다가 놓음
    <AREA> mouseOver 마우스가 클라이언트측 이미지맵의 한 영역으로 이동함
    mouseOut 마우스가 이미지맵 영역 밖으로 이동
    dbClick 사용자가 이미지맵의 한 영역을 더블클릭함
    <BODY>..</BODY> Click 사용자가 문서의 본문을 클릭
    dbClick 문서의 본문을 더블 클릭함
    keyDown 키를 누름
    keyUp 키를 놓음
    keyPress 키를 눌렀다가 놓음
    mouseDown 마우스 버튼을 누름
    mouseUp 마우스 버튼을 놓음
    <BODY>..</BODY>
    <FRAMESET>..</FRAMESET>
    <FRAME>..</FRAME>
    blur 윈도우에서 현재 입력 포커스가 사라짐
    error 윈도우가 로드되는 동안 에러 발생
    focus 입력 포커스가 현재 윈도우로 이동
    load 윈도우 로딩이 완료됨
    unload 윈도우를 종료함
    move 윈도우가 이동됨
    resize 윈도우의 크기가 바뀜
    dragDrop 윈도우에 객체를 드롭
    <FORM>..</FORM> submit 사용자가 폼을 제출
    reset 사용자가 폼을 재설정
    <INPUT TYPE="text"> blur 현재 입력 포커스가 텍스트 필드에서 사라짐
    focus 현재 입력 포커스가 텍스트 필드로 이동
    change 텍스트 필드가 변경되어 현재 입력 포커스가 사라짐
    select 텍스트 필드에 있는 텍스트가 선택됨
    <INPUT TYPE="password"> blur 패스워드 필드에서 입력 포커스가 사라짐
    focus 패스워드 필드에 입력 포커스 생김
    <TEXTAREA>..</TEXTAREA> blur 텍스트 영역이 현재 입력 포커스가 사람짐
    focus 텍스트 영역에 입력 포커스 생김
    change 텍스트 영역이 변경되어 입력 포커스가 사라짐
    select 텍스트 영역에서 텍스트가 선택됨
    keyDown 키를 누름
    keyUp 키를 놓음
    keyPress 키를 눌렀다 놓음
    <INPUT TYPE="button"> Click 버튼이 클릭됨
    blur 입력할 수 없도록 버튼이 흐려짐
    focus 입력할 수 있도록 포커스 생김
    mouseDown 버튼 위에서 왼쪽 마우스 버튼 누름
    mouseUp 버튼 위에서 왼쪽 마우스 버튼 놓음
    <INPUT TYPE="submit"> Click 제출 버튼이 클릭됨
    blur 제출 버튼에서 입력 포커스가 사라짐
    focus 제출 버튼에 입력 포커스 생김
    <INPUT TYPE="reset"> Click 리셋 버튼이 클릭됨
    blur 리셋 버튼에서 포커스가 사라짐
    focus 리셋 버튼에서 포터스가 놓임
    <INPUT TYPE="radio"> Click 라디오 버튼이 클릭
    blur 라디오 버튼에서 입력 포커스가 사라짐
    focus 라디오 버튼에 입력 포커스 생김
    <INPUT TYPE="checkbox"> Click 체크 박스가 클릭
    blur 체크 박스에서 입력 포커스가 사라짐
    focus 체크 박스에 입력 포커스 놓임
    <INPUT TYPE="file"> blur 파일 업로드 폼 요소에서 입력 포커스 사라짐
    change 사용자가 업로드될 파일을 선택
    focus 파일 업로드 폼 요소에 입력 포커스 놓임
    <SELECT>..</SELECT> blur 선택 요소가 현재 입력 포커스 잃음
    change 선택 요소가 변경되어 입력 포커스가 사라짐
    focus 선택 요소에 현재 입력 포커스가 놓임

  • 이벤트 처리 속성
    이벤트핸들링속성실행되는 상황
    onAbort 이미지를 로딩하는 작업이 사용자의 한 행동으로 인해 취소되었음
    onBlur 문서나 윈도우, 프레임세트, 폼 요소에서 현재 입력 포커스가 사라짐
    onChange 텍스트 필드나 텍스트 영역, 파일 업로드 필드, 선택 항목이 변경되어 현재 입력 포커스가 사라짐
    onClick 링크나 클라이언트측 이미지맵 영역, 폼 요소가 클릭됨
    onDbClick 링크나 클라이언트측 이미지맵 영역, 문서가 더블 클릭됨
    onDragDrop 드래그된 객체가 윈도우나 프레임에 드롭됨
    onError 이미지나 윈도우, 프레임을 로딩하는 동안 에러가 발생함
    onFocus 문서나 윈도우, 프레임 세트, 폼 요소에 입력 포커스 놓임
    onKeyDown 키를 누름
    onKeyPress 키를 눌렀다 놓음
    onKeyUp 키를 놓음
    onLoad 이미지나 문서, 프레임이 로드됨
    onMouseDown 마우스 버튼 누름
    onMouseMove 마우스를 이동함
    onMouseOut 링크나 클라이언트측 이미지맵에서 마우스를 옮김
    onMouseOver 마우스를 링크나 클라이언트측 이미지맵으로 옮김
    onMouseUp 마우스 버튼을 놓음
    onMove 사용자가 윈도우나 프레임을 이동함
    onReset 폼의 리셋 버튼을 클릭하여 폼을 리셋시킴
    onResize 사용자가 윈도우나 프레임의 크기를 조절
    onSelect 텍스트는 텍스트 필드나 영역에서 선택됨
    onSubmit 폼이 제출됨
    onUnload 사용자가 문서나 프레임 세트를 종료함



객체 정의하기

  • 객체 유형 정의
    • 프로퍼티 : 객체에 들어 있는 데이터 값에 액세스할 때 사용.
    • 메소드 : 객체에 어떤 작업을 할 때 사용하는 함수.
  • 객체 유형 만들기
    사용자가 직접 객체 유형을 정의하고 특정 객체 인스턴스를 만들 수 있 는데 이렇게 만들려면 객체 유형의 특정 인스턴스를 만들 때 사용되는 함수를 정의하기만 하면 된다. 본래 이러한 생성자 함수는 다음과 같은 일을 한다.
    • 객체 유형의 프로퍼티에 값을 할당한다.
    • 객체 유형의 메소드로 사용할 수 있는 다른 함수를 지정한다.
  • 객체 사용 예
    1. table 객체의 정의 (table.js)
      function table_getValue(row,col){
      return this.data[row* this.columns+col ];
      }
      function table_setValue(row,col,value){
      this.data[row* this.columns+col ]=value;
      }
      function table_set(contents){
      var n=contents.length;
      for(var j=0;jthis.data[j]
      =contents[j];
      }
      function table_isHeader(row,col){
      return this.header[row* this.columns+col ];
      }
      function table_makeHeader(row,col){ this.header[row* this.columns+col ]=true;
      }
      function table_makeNormal(row,col){ this.header[row* this.columns+col ]=false;
      }
      function table_makeHeaderRow(row){ for(var j=0;j< this.columns+j)
      this.header[row* this.columns+col ]=true;
      }
      function table_makeHeaderColumn(col){ for(var i=0;i< this.rows;++i)
      this.header[i* this.columns+col ]=true;
      }
      function table_write(doc){
      doc.write("<TABLE BORDER="+ this.border+">");
      for(var i=0;i< this.rows;++i) {
      doc.write("<TR>");
      for(var j=0;j< this.columns;++j) {
      if( this.header[i* this.columns+j ]) {
      doc.write("<TH>");
      doc.write( this.data[i* this.columns+j ]);
      doc.write("</TH>");
      }
      else {
      doc.write("<TD>");
      doc.write( this.data[i* this.columns+j ]);
      doc.write("</TD>");
      }
      }
      doc.writeln("</TR>");
      }
      doc.writeln("</TABLE>");
      }
      funtion table(rows,columns) {
      this.rows=rows
      this.columns=columns
      this.border=0
      this.data=new Array(rows*columns)
      this.header=new Array(rows*columns)
      this.getValue=table_getValue
      this.setValue=table_setValue
      this.set=table_set
      this.isHeader=table_isHeader
      this.makeHeader=table_makeHeader
      this.makeNormal=table_makeNormal
      this.makeHeaderRow=table_makeHeaderRow
      this.makeHeaderColumn=table_makeHeaderColumn
      this.write=table_write
      }

    2. table 객체 사용하기
      <HTML>
      <HEAD>
      <TITLE>Defining Object Types</TITLE
      <SCRIPT LANGUAGE="JavaScript" SRC="table.js"><!-
      //-></SCRIPT>
      </HEAD>
      <BODY>
      <H1>Defining Object Types</H1>
      <SCRIPT LANGUAGE="JavaScript"><!-
      t=new table(3,4)
      contents=new
      Array("This","is","a","test","of","the","table","object.","Let's","see","it","work")
      t.set(contents)
      t.border=4
      t.makeHeaderColumn(0)
      t.write(document)
      //-></SCRIPT>
      </BODY>
      </HTML>

    3. 객체 유형에 프로퍼티와 메소드 추가
      : prototype 프로퍼티를 통해서 인스턴스화할 수 있는 미리 정의된 객체 유형에 프로퍼티와 메소드 추가
      사용 예
      <HTML>
      <HEAD>
      <TITLE>Updating Object Types </TITLE>
      <SCRIPT LANGUAGE="JavaScript" SRC="table.js"><!-
      //-></SCRIPT>
      </HEAD>
      <BODY>
      <H1>Updating Object Types</H1>
      <SCRIPT LANGUAGE="JavaScript"><!-
      function table_colorWrite(doc){
      ........
      함수 정의
      ........
      ........
      }
      t=new table(3,4)
      table.prototype.bgColor="Cyan"
      table.prototype.colorWrite=table_colorWrite
      .............
      .............
      t.colorWrite(document)
      //-></SCRIPT>
      </BODY>
      </HTML>

    4. 프로퍼티와 메소드 삭제
      delete objectName.propertyName
      delete objectName.methodName



브라우저 객체

객 체 용 도
window 객체 브라우저 윈도우나 윈도우 안에 있는 프레임에 액세스할 때 사용한다. 프로퍼티와 메소드를 참조할 때, window 객체가 존재하는 경우에는 "window."접두사를 붙일 필요가 없다
document 객체 현재 윈도우에 로드되어 있는 문서에 액세스할 때 사용한다. document 객체는 컨텐트를 제공하는 HTML 문서, 즉 HEAD와 BODY 태그가 있는 문서를 의미한다.
location 객체 URL을 나타낼 때 사용한다. 이 객체는 URL객체를 만들거나 URL의 일부분에 액세스하거나 기존의 URL을 수정할 때 사용할 수 있다.
history 객체 한 윈도우 안에서 액세스된 URL의 히스토리를 유지할 때 사용
frame 객체, frames 배열 HTML 프레임에 액세스할 때 사용
frames 배열은 윈도우안에 있는 모든 프레임에 액세스할 때 사용
link 객체, links 배열 하이퍼텍스트 링크의 텍스트 기반이나 이미지 기반 소스 앵커(anchor)에 액세스할 때 사용
links배열은 문서 안에 있는 모든 link 객체에 액세스할 때 사용한다. I.E.는 link 객체의 anchor객체를 결합한다.
anchor 객체, anchors 배열 하이퍼텍스트 링크의 타켓에 액세스할 때 사용
anchors 배열은 문서 안에 있는 모든 anchor 객체에 액세스할 때 사용
image객체, images 배열 HTML 문서에 삽입되어 있는 이미지에 액세스할 때 사용
images 배열은 문서 안에 있는 모든 image 객체에 액세스할 때 사용
area 객체 클라이언트측 이미지맵 안에 있는 영역에 액세스할 때 사용
applet 객체, applets 배열 Java 애플릿에 액세스할 때 사용
애플릿 배열은 문서 안에 있는 모든 애플릿에 액세스할 때 사용
event 객체, Event 객체 이벤트 발생에 대한 정보에 액세스할 때 사용
event 객체는 특정 이벤트에 대한 정보 제공
Event 객체는 이벤트를 식별하는 데 사용하는 상수 제공
form 객체, forms 배열 HTML 폼에 액세스시 사용
forms 배열은 문서 안에 있는 모든 폼에 액세스시 사용
element 객체 폼 안에 들어있는 모든 폼 요소에 액세스시 사용
text 객체 폼의 텍스트 필드에 액세스시 사용
textarea 객체폼의 텍스트 영역 필드에 액세스시 사용
radio 객체 폼의 라디오 버튼 세트에 액세스하거나 세트 안에 있는 각각의 버튼에 액세스할 때 사용
checkbox 객체 폼의 체크 박스에 액세스할 때 사용
button 객체 Submit나 Reset 버튼이 아닌 폼 버튼에 액세스시 사용
reset 객체 폼의 Reset 버튼에 액세스시 사용
selet 객체 폼의 선택 리스트에 액세스시 사용
option 객체 option 객체는 선택 리스트의 요소에 액세스시 사용
password 객체 폼의 패스워드 필드에 액세스시 사용
hidden 객체 폼의 숨겨진 필드에 액세스시 사용
FileUpload 객체 폼의 파일 업로드 요소에 액세스시 사용
navigator 객체 스크립트를 실행하고 있는 브라우저에 대한 정보에 액세스시 사용
screen 객체 사용자의 화면의 색상 깊이와 크기에 대한 정보에 액세스시 사용
embed 객체, embeds 배열 삽입된 객체에 액세스시 사용
embeds 배열은 문서 안에 삽입된 모든 객체에 대한 액세스 제공
mimeType 객체, mimeTypes 배열 브라우저가 제공하는 특징 MIME 유형에 대한 정보에 액세스시 사용
mimeTypes 배열은 제공하는 모든 mimeType 객체의 배열
I.E.는 빈 배열을 리턴하면서 mimeTypes에 대해서 임시적으로 지원
plugin 객체, plugins 배열 특정 브라우저 플러그인에 대한 정보에 액세스시 사용
plugins 배열은 브라우저가 지원하는 모든 플러그인의 배열
I.E.는 빈 배열을 리턴하면서 plugins에 대해서 임시적으로 지원


window 객체

  • 모든 브라우저 스크립트의 기본적인 것으로, 브라우저가 자동으로 정의하는 최상위 레벨의 객체이다. 현재 열려 있는 각 윈도우에 대해 별도의 window 객체가 정의된다.


window 객체의 프로퍼티
프로퍼티 설 명
closed 윈도우가 닫혀 있는지 식별
defaultStatus 브라우저 윈도우의 하단의 상태바에 나타나는 디폴트 상대 메시지를 지정
document 윈도우에 표시되어 있는 현재 문서를 지정하는 객체
frames 윈도우 객체에 들어 있는 모든 프레임 객체로 구성된 배열
history 마지막으로 윈도우로 로드된 URL의 리스트를 포함하는 윈도우의 히스토리 객체
length window에 들어 있는 프레임의 수 식별
location window 객체와 관련된 URL을 지정하는 객체
name 윈도우의 이름 지정
offscreenBuffering 윈도우 정보의 오프스크린 버퍼링이 사용될 것인지를 지정하는 부울값
오프스크린 버퍼링은 윈도우를 나타내기 전에 윈도우의 모든 요소를 로드할 때 사용
opener 윈도우를 만들거나 열 수 있도록 해주는 window 객체 지정
parent 특정 윈도우를 포함하는 윈도우를 지정하는 시너님
self 참조될 현재 윈도우를 지정하는 시너님
status 브라우저 윈도의 하단의 상태 표시줄에 나타날 임시 메시지를 지정
top 중첩된 일련의 윈도우에서 맨 위에 있는 브라우저 윈도우를 의미하는 시너님
window 참조될 현재 윈도우를 식별하는 시너님

window 객체의 메소드
메 소 드 설 명
alert(text) 경고 다이얼로그 박스를 표시
blur() 포커스를 윈도우에서 옮긴다
setInterval(expression,milliseconds) 지정된 타임아웃 인터벌이 지난 이후에 표현식을 반복해서 평가하거나 함수를 불러온다.
clearInterval(interval) 이전에 설정된 인터벌 타이머를 클리어
setTimeout(expression,milliseconds) 타임아웃 기간이 지난 이후에 표현식을 평가하거나 함수를 호출한다.
clearTimeout(timer) 이전에 설정된 타임아웃을 클리어
close() 지정된 윈도우를 닫는다.
confirm(text) 확인 다이얼로그 박스를 나타낸다.
focus() 윈도우로 포커스를 가져간다.
open(url,name,[options]) 새로운 윈도우를 열고 새로운 window 객체를 만듬
prompt(text,defaultInput) 프롬프트 다이얼로그 박스를 나타낸다.
scroll(x,y) 윈도우를 특정 위치까지 스크롤한다.

open() 메소드의 옵션
옵 션 설 명
toolbar yes no 윈도우에 툴바 제공
location yes no 윈도우에 위치 필드 제공
directories yes no 디렉토리 버튼 제공
status yes no 상태 표시줄 제공
menubar yes no 메뉴바 제공
scrollbars yes no 스크롤 바 제공
resizable yes no 윈도우 크기 조절 가능
width 정수 윈도우의 폭(픽셀)
height 정수 윈도우의 높이(픽셀)


frame 객체

  • 프레임은 윈도우를 독립된 표시 영역들로 분할한 후, 이 영역들에 표시되는 정보들을 강력하게 컨트롤 할 수 있게 해준다.
  • 프레임 객체의 프로퍼티와 메소드는 window 객체와 같지만, close() 메소드는 지원하지 않는다.



document 객체

  • JavaScript 에서 아주 중요한 객체로, 이 객체를 사용하면 로드될 문서를 업데이트하고 로드된 문서 안에 있는 HTML 요소에 액세스할 수 있다.


프로퍼티 설 명
alinkColor <BODY> 태그의 alink 속성의 값 지정
anchor 문서에 들어 있는 배열을 참조하는 객체
anchors 문서에 들어 있는 모든 앵커의 배열
applet 문서에 들어 있는 애플릿을 참조하는 객체
applets 문서에 들어 있는 모든 애플릿의 배열
area 문서 안의 이미지맵 영역을 참조하는 객체
bgColor <BODY> 태그의 bgColor 속성의 값 식별
cookie 쿠키의 값 식별
domain 문서가 로드되는 서버의 도메인 이름 식별
embeds 문서안의 모든 플러그인의 배열
fgColor <BODY> 태그의 text 속성값 지정
form 문서 안의 폼을 참조하는 객체
Forms[] 문서 안의 모든 폼의 배열
image 문서 안의 이미지를 참조하는 객체
Images[] 문서 안의 모든 이미지의 배열
lastModified 문서가 마지막으로 수정된 날짜
link 문서 안의 링크를 참조하는 객체
links 문서 안의 모든 링크의 배열
linkColor <BODY> 태그의 link 속성의 값 식별
plugin 문서 안의 플러그인을 참조하는 객체
plugins[] 브라우저가 지원하는 플러그인을 나타내는 객체의 배열
referrer 문서에 대한 링크를 제공하는 문서의 URL
title 문서의 타이틀
URL 문서의 URL
vlinkColor <BODY> 태그의 vlink 속성의 값 식별

document 객체의 메소드
메 소 드 설 명
close() 문서의 객체를 만드는 데 사용된 스트림
open([mimeType][,"replace"]) 선택적인 MIME 유형으로 문서 객체를 만들 때 사용되는 흐름을 개시한다. "replace" 파라미터는 text/html MIME 유형과 함께 사용되어 히스토리 리스트에 있는 현재 문서를 대체
write(expr1[,expr2...,exprN]) 문서에 표현식의 값을 기록
write(expr1[,expr2...,exprN]) 개행 문자가 다음에 따라오는 문서에 표현식의 값 기록


navigator 객체

  • navigator 객체는 window 객체와 마찬가지로 브라우저 객체 모델에서 최상위 레벨의 객체이며, 스크립트를 실행할 때 사용되는 브라우저의 종류와 버전에 대한 정보 제공한다.


navigator 객체의 프로퍼티
프로퍼티 브라우저 지원 설 명
appCodeName N2, I.E3 브라우저 색상 이름
AppMinorVersion I.E4 브라우저 버전 번호
appName N2, I.E3 브라우저 이름
appVersion N2, I.E3 브라우저의 버전
browserLanguage I.E4 브라우저에 설정되어 있는 언어
connectionSpeed I.E4 브라우저가 네트워크에 연결되는 속도
cookieEnabled I.E4 브라우저가 쿠키를 허용하도록 설정되어 있는지의 여부
cpuClass I.E4 브라우저 실행시 사용되는 마이크로프로세서의 유형
onLine I.E4 브라우저가 현재 온라인 연결을 가지고 있는지 여부
Language N4, I.E4 브라우저에 설정되어 있는 언어
mimeTypes N3, I.E4 현재 브라우저가 지원하는 모든 MIME 유형의 배열
platform N4, I.E4 브라우저가 실행되는 운영체제 플랫폼
plugins N3, I.E4 현재 브라우저에 설치된 모든 플러그인의 배열
systemLanguage I.E4 운영체제의 디폴트 언어
userAgent N2, I.E3 브라우저에서 서버로 전송된 HTTP 프로토콜의 사용자 에이전트 헤더
userLanguage I.E4 사용자가 사용하는 언어
userProfile I.E4 사용자 프로파일 정보에 대한 액세스를 제공하는 객체

navigator 객체의 메소드
메 소 드 설 명
javaEnabled() 사용자가 브라우저의 Java 기능을 켜두었는지의 여부를 나타내는 부울값 리턴
taintEnabled() 사용자가 data tainting(보안 메커니즘)을 활성화했는지 여부를 나타내는 부울값 리턴
preference 서명이 되지 않은 스크립트가 보안 관련 프로퍼티를 얻고 설정할 때 사용


event 객체

event 객체의 프로퍼티
프로퍼티 브라우저 설 명
dataNDragDrop 이벤트로 인해 드롭된 객체의 URL이 들어있는 스트링 배열
height, widthN윈도우나 프레인의 길이와 너비(픽셀표시)
pageX, pageYN픽셀로 나타낸 커서의 수평/수직 위치(페이지에서의 상대적위치)
screenX, screenYN, I.E픽셀로 나타낸 커서의 수평/수직 위치(화면에서의 상대적 위치)
layerX, layerYN픽셀로 나타낸 커서의 수평/수직 위치, 이벤트가 발생한 레이어에 대한 상대적 위치. Resize 이벤트와 함께 사용하면 layerX와 layerY가 이벤트가 타겟으로 하는 객체의 길이와 너비 지정
clientX와 clientYI.E픽셀로 나타낸 커서의 수평/수직 위치, 이벤트가 발생한 웹페이지에서의 상대적 위치
offsetX, offsetYI.E픽셀로 나타낸 커서의 수평/수직 위치, 이벤트가 발생한 컨테이너에 대한 상대적 위치
X, YI.E픽셀로 나타낸 커서의 수평/수직 위치, 이벤트가 발생한 문서에 대한 상대적 위치
targetN이벤트가 전송된 원래 객체
srcElementI.E이벤트가 전송된 원래 객체
typeN, I.E발생한 이벤트 유형
whichN눌려진 마우스 버튼(왼:1, 가:2, 오:3)이나 눌려진 키의 ASCII값
keyCodeI.E키 누름과 연관된 Unicode 키 코드를 식별
buttonI.E이벤트가 발생했을 때 눌려진 마우스 버튼 식별(0:눌려진버튼없음, 1:왼, 2:오, 4:가)
modifiersN마우스나 키 이벤트와 연관된 수정자 키(ALT_MASK,CONTROL_MASK,SHIFT_MASK,META_MASK)를 식별
altkey,ctrlkey,shiftkeyI.Etrue나 false로 설정하여 이벤트가 발생했을 때 Alt키와 Control키, Shift 키 중에 어떤 것이 눌려졌는지 알려준다.
cancelBubbleI.Etrue나 false로 설정하여 이벤트 버블링을 취소하거나 활성화한다.
fromElement, toElementI.E이동 중인 HTML 요소 지정
reasonI.E데이터 소스 객체에 대한 데이터 전송 상태를 나타내는데 사용
returnValueI.Etrue나 false로 설정하여 이벤트 핸들러의 리턴값을 나타낸다. 이벤트 핸들러에서 true나 false를 리턴하는 것과 같다.
srcFilterI.Eonfilterchange 이벤트를 시작하는 filter객체 지정


screen 객체

  • screen 객체의 프로퍼티
    • height : 사용자의 화면의 현재 높이(픽셀)
    • width : 사용자의 화면의 현재 너비(픽셀)
    • colorDepth : 사용자의 화면/비디오 카드에서 현재 지원하는 색상당 바이트 수


    form 객체

    • document 객체의 프로퍼티로 액세스되고, form 객체는 문서 안의 폼에 액세스할 수 있도록 해주고, 폼 관련 이벤트에 응답을 할 수 있도록 해주기 때문에 중요하다.
    form 객체의 프로퍼티
    프로퍼티 설 명
    action <FORM> 태그의 HTML action 속성에 대한 액세스 제공
    button GUI 컨트롤 버튼을 나타내는 객체
    checkbox 체크 박스 필드를 나타내는 객체
    elements 폼 안에 포함되어 있는 모든 필드와 GUI 컨트롤을 포함하는 배열
    encoding <FORM> 태그의 HTML enctype 속성에 대한 액세스 제공
    FileUpload 파일 업로드 폼 필드를 나타내는 객체
    hidden 숨겨진 폼 필드를 나타내는 객체
    length elements 배열의 길이에 대한 액세스 제공
    method <FORM> 태그의 HTML method 속성에 대한 액세스 제공
    name 폼의 이름 식별
    password 패스워드 필드를 나타내는 객체
    radio 라디오 버튼 필드를 나타내는 객체
    reset reset 버튼을 나타내는 객체
    select 선택 항목 리스트를 나타내는 객체
    submit submit 버튼을 나타내는 객체
    target <FORM> 태그의 HTML target 속성에 대한 액세스 제공
    text 텍스트 필드를 나타내는 객체
    textarea 텍스트 영역 필드를 나타내는 객체

    form 객체의 메소드
    메 소 드 설 명
    handleEvent() 지정된 이벤트에 대한 폼의 이벤트 핸들러를 호출할 때 사용
    submit() 폼을 제출시 사용
    reset 폼의 엔트리를 디폴트 값으로 재설정시 사용

    form 요소 객체의 프로퍼티
    객 체 프로퍼티 설 명
    button name 버튼의 name 속성에 대한 액세스 제공
    type 객체의 유형 지정
    value 객체의 값 지정
    checkbox checked 체크박스가 현재 체크되어 있는지를 식별
    defaultChecked 체크박스가 디폴트로 체크되어 있는지 식별
    name 체크박스의 HTML name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    FileUpload name 객체의 name 속성에 대한 액세스 제공
    type 객체의 type 속성에 대한 액세스 제공
    value 객체의 값 식별
    hidden name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    password defaultChecked객체의 디폴트 값 식별
    name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    radio checked 라디오 버튼이 체크되어 있는지 식별
    defaultChecked 라디오 버튼이 디폴트로 체크되어 있는지 식별
    name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    reset name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    select length 선택 리스트의 길이 식별
    name 객체의 name 속성에 대한 액세스 제공
    option 선택 리스트가 제공하는 옵션 식별하는 배열
    selectedIndex 선택 리스트 안에서 처음 선택된 옵션 식별
    type 객체의 유형 식별
    submit name 객체의 name 속서에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    text defaultValue 텍스트 필드에 나타나는 디폴트 텍스트를 식별
    name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별
    textarea defaultValue 텍스트 영역 필드에 나타나게 되는 디폴트 텍스트 식별
    name 객체의 name 속성에 대한 액세스 제공
    type 객체의 유형 식별
    value 객체의 값 식별

    form 요소 객체의 메소드
    객 체 메 소 드 설 명
    button Click() 클릭된 버튼 시뮬레이트
    blur() 포커스 잃음
    focus() 포커스 맞춤
    checkbox Click() 클릭된 체크 박스 시뮬레이트
    blur() 포커스 잃음
    focus() 포커스 맞춤
    FileUpload blur() 포커스 잃음
    focus() 포커스 맞춤
    select() 입력 영역을 선택
    hidden 없음
    password blur() 포커스 잃음
    focus() 포커스 맞춤
    select() 패스워드 필드에 나타나는 텍스트를 하이라이트
    radio Click() 라디오 버튼 클릭 시뮬레이트
    blur() 포커스 잃음
    focus() 포커스 맞춤
    reset Click() 리셋 버튼 클릭 시뮬레이트
    blur() 포커스 잃음
    focus() 포커스 맞춤
    select blur() 포커스 잃음
    focus() 포커스 맞춤
    submit Click() 제출 버튼 클릭 시뮬레이트
    blur() 포커스 잃음
    focus() 포커스 맞춤
    text blur() 포커스 잃음
    focus() 포커스 맞춤
    select() 텍스트 필드에 있는 텍스트 하이라이트
    textarea blur() 포커스 잃음
    focus() 포커스 맞춤
    select() 텍스트 영역에 있는 텍스트 하이라이트


    location 객체

    • 윈도우에 로드되어 있는 현재 문서의 URL에 액세스하거나 새로운 문서를 로드할 때 사용

    location 객체의 프로퍼티
    프로퍼티 설 명
    hash URL의 앵커 부분(존재하는 경우)
    host URL의 hostname:port 부분
    hostname URL의 host부분
    href 전체 URL
    pathname URL의 경로명 부분
    port URL의 포트 부분
    protocol URL의 프로토콜 부분
    search URL의 쿼리 스트링 부분

    location 객체의 메소드
    • reload() : 윈도우의 현재 문서를 브라우저의 Reload 버튼에서 사용하는 정책에 따라 다시 로드
      • Every time : 문서는 매번 서버에서 다시 로드
      • Once per session : 서버의 문서의 날짜가 캐시에 저장되어 있는 문서보다 더 최신 날짜라는 것을 나타내면 문서는 세션당 한 번씩 서버에서 다시 로드된다. 문서가 캐시에 없는 경우에는 서버에서 로드
      • Never : 문서는 가능하면 캐시에서 다시 로드, 그렇지 않으면 서버에서 로드
    • replace() : URL을 파라미터로 취하여, 현재 문서 히스토리 목록에 있는 현재 문서위로 그 URL의 문서를 로드, 그러면 브라우저의 Back버튼을 클릭하여 이전 문서로 돌아갈 수 없음


    link 객체

    • link 객체는 document 객체의 프로퍼티로, 문서에 들어있는 텍스트나 이미지 링크를 캡슐화
    • links 배열은 문서에 들어있는 모든 링크의 배열
    • link 객체의 메소드
      handleEvent() : event 객체를 인자로 취하며 그 이벤트에 대해 적당한 이벤트 핸들러 호출

    link 객체의 프로퍼티
    프로퍼티 설 명
    hash URL의 앵커 부분(존재하는 경우)
    host URL의 hostname:port 부분
    hostname URL의 host부분
    href 전체 URL
    pathname URL의 경로명 부분
    port URL의 포트 부분
    protocol URL의 프로토콜 부분
    search URL의 쿼리 스트링 부분
    target 링크의 HTML, target 속성


    anchor 객체

    • HTML 문서 안에서 이름이 지정된 오프셋으로 사용되는 앵커 의미
    • anchors 배열에는 문서의 모든 앵커가 들어있음
    • 프로퍼티나 메소드 또는 이벤트를 전혀 가지고 있지 않음
    • HTML 문서와 관련하여 정의된 이름이 지정된 오프셋을 추적할 때 사용
    • anchor 객체는 HREF 속성을 포함하는 경우에 link 객체가 된다.


    history 객체

    • history 객체의 프로퍼티
      • current : 윈도우에 나타나는 현재 문서의 URL
      • length : History 리스트의 길이
      • next : History 리스트에서의 다음 URL
      • previous : History 리스트에서의 이전 URL
    • history 객체의 메소드
      • back() : History 리스트에 이전 문서를 로드. 브라우저의 Back 버튼을 클릭하는 것과 같은 효과
      • forward() : History 리스트에 다음 문서를 로드. 브라우저의 Forward 버튼을 클릭하는 것과 같은 효과
      • go() : History 리스트에 있는 특정 문서로 감
        • go(n) : n>0인 경우, 이 메소드는 History 리스트에서 n개의 엔트리가 앞에 있는 문서를 로드, n=0인 경우에는 현재 문서가 다시 로드되고, n<0인 경우엔 History 리스트에서 n개의 엔트리 뒤에 있는 문서를 로드
        • go(string) : go()는 이 스트링을 서브스트링으로 갖고 있는 URL의 History 리스트에서 가장 가까운 문서를 로드


    image 객체

    • document 객체의 프로퍼티
    • 문서와 함께 로드된 이미지에 대한 액세스 제공
    • images 배열은 문서 안에 지정되어 있는 각각의 <IMG>태그에 대한 엔트리가 들어있음
    • image 객체 유형을 사용하면 키워드와 생성자로 새로운 image 객체를 명시적으로 만들 수 있다. Image() 생성자는 웹페이지의 일부로서 처음에 나타나지 않는 이미지를 만들고 미리 로드할 때 사용한다. 이러한 image 객체는 브라우저의 캐시에 저장되면 이미 나타난 이미지를 대체할 때 사용
      * Image() 생성자를 사용하여 캐시된 이미지 만드는 예 cachedImage=new Image()
      cachedImage.src="myImage.gif"
      = > 첫번째 문장은 새로운 image 객체를 만들고 그것을 cachedImage 변수에 대입하고, 두번째 문장은 image 객체의 src프로퍼티를 myImage.gif 이미지 파일로 설정한다. 이 경우 myImage.gif는 브라우저 캐시로 로드된다. 그러면 로드된 이미지는 cachedImage 변수를 사용하여 참조 가능하다.

      image 객체의 프로퍼티
      프로퍼티 설 명
      border <:IMG> 태그의 BORDER 속성의 값
      complete 이미지가 완전히 로드되었는지 식별
      height <:IMG> 태그의 HEIGHT 속성의 값
      hspace <IMG> 태그의 HSPACE 속성의 값
      lowsrc <IMG> 태그의 LOWSRC 속성의 값
      name <IMG> 태그의 NAME 속성의 값
      prototype image 객체에 사용자 지정 프로퍼티를 추가할 때 사용
      src <IMG> 태그의 SRC 속성의 값
      vspace <IMG> 태그의 VSPACE 속성의 값
      width <IMG> 태그의 WIDTH 속성의 값


    area 객체

    • 이미지맵은 여러 가지 다른 영역으로 나누어져 있는 이미지로서 각각의 영역은 자체 URL과 관련되어 있다. 그리고 이러한 영역과 관련된 사용자 처리 방식으로 area 객체를 제공

    area 객체의 프로퍼티
    프로퍼티 설 명
    hash area 객체의 HREF 속성의 파일 오프셋 부분
    host area 객체의 HREF 속성의 호스트 이름 부분
    hostname area 객체의 HREF 속성의 host:port 부분
    href area 객체의 완전한 HREF 속성
    pathname area 객체의 HREF 속성의 경로명 부분
    port area 객체의 HREF 속성의 포트 부분
    protocol area 객체의 HREF 속성의 프로토콜 부분
    search area 객체의 HREF 속성의 쿼리 스트링 부분
    target area 객체의 TARGET 속성


    Array 객체

    • Array 객체를 사용하면 배열을 객체처럼 액세스 가능
    • Array 객체의 프로퍼티
      • length : 배열의 길이 식별
      • prototype : 모든 객체 유형이 지원하는 프로퍼티로 객체 유형에 대해 추가적인 프로퍼티 및 메소드 정의 가능
    • Array 객체의 메소드
      • toString() : 배열의 스트링 버전 리턴, 배열 요소는 컴마로 구분
      • join(separator) : 배열의 스트링 버전 리턴, 배열 요소는 seperator 스트링으로 구분, 분리자가 없으면 컴마로 구분
      • reverse() : 배열의 요소를 역순으로 바꿈
      • sort(comparisionFunction) : 비교 연산에 따라 배열의 요소 정렬. 비교 함수가 지정되면, 배열 요소는 사전순서로 정렬. 비교 연산이 지정되면 두개의 파라미터 p1,p2를 취하고, p1이 p2보다 작은 경우에는 음의 정수를 리턴하고, 같으면 0을 리턴하고, p1이 p2보다 크면 양의 정수 리턴


    Boolean 객체

    • Boolean 객체를 사용하면 부울값은 객체로서 액세스 가능
    • Boolean 객체는 생성자에 대한 인자로서 값을 식별하여 만들어짐 myBoolean=new Boolean(false)
      yourBoolean=new Boolean(true)
    • Boolean 객체의 프로퍼티
      • prototype : 모든 객체 유형이 지원하는 프로퍼티로 객체 유형에 대해 추가적인 프로퍼티 및 메소드 정의 가능
    • Boolean 객체의 메소드
      • toString() : 부울값에 해당하는 스트링 리턴
      • valueOf() : 객체의 값에 따라 true나 false로 리턴


    Date 객체

    Date 객체의 메소드
    메 소 드 설 명
    getDate()
    getUTCDate()
    setDate()
    setUTCDate()
    Date 객체의 날짜를 설정하거나 리턴
    getDay()
    getUTCDay()
    Date 객체의 한 주의 날짜를 설정하거나 리턴
    getHours()
    getUTCHours()
    setHours()
    setUTCHours()
    Date 객체의 시간를 설정하거나 리턴
    getMilliseconds()
    getUTCMilliseconds()
    setMilliseconds()
    setUTCMilliseconds()
    Date 객체의 밀리초 값을 설정하거나 리턴
    getMinutes()
    getUTCMinutes()
    setMinutes()
    setUTCMinutes()
    Date 객체의 분을 설정하거나 리턴
    getMonth()
    getUTCMonth()
    setMonth()
    setUTCMonth()
    Date 객체의 달을 설정하거나 리턴
    getSeconds()
    getUTCSeconds()
    setSeconds()
    setUTCSeconds()
    Date 객체의 초를 설정하거나 리턴
    getTime()
    getUTCTime()
    Date 객체의 시간을 설정하거나 리턴
    getTimeZoneOffset() Date 객체의 시간대 오프셋(분)을 리턴
    getYear()
    getFullYear()
    getUTCFullYear()
    setYear()
    setFullYear()
    setUTCFullYear()
    Date 객체의 연도를 리턴하거나 설정한다. 완전한 연도를 나타내는 방법으로 4자리 연도 값을 사용한다.
    toGMTString() 날짜를 Internet GMT(Greenwich Mean Time) 포맷의 스트링으로 변환
    toLocaleString() 날짜를 로케일(locale)포맷의 스트링으로 변환. 로케일 포맷이란 사용자가 위치해 있는 지형적 위치에서 일반적으로 사용하는 포맷 의미
    toString() Date 객체의 스트링 값을 리턴
    valueOf() 1970년 1월 1일 자정 이후의 밀리초 값 리턴
    toUTCString() UTC에서 시간을 나타내는 스트링 값을 리턴

    Date 생성자
    생 성 자 설 명
    Date() 현재 날짜와 시간으로 Date 인스턴스 만듬
    Date(dateString) dateString 파라미터에 지정되어 있는 날짜로, Date 인스턴스를 만든다. dateString의 포맷은 "월,일,연도,시:분:초"
    Date(milliseconds) 1970년 1월 1일 자정 이후 지정된 밀리초 값으로 Date 인스턴스를 만든다.
    Date(year,month,
    day,hours,minutes,
    seconds,milliseconds)
    년,월,일,시,분,초,밀리초 정수에 따라 지정된 날짜로 Date 인스턴스를 만든다. 연도와 월 파라미터는 제공되어야 하고 다른 나머지 파라미터가 포함되면 앞에 오는 모든 파라미터가 제공되어야 한다.


    Function 객체

    • 함수를 객체처럼 액세스 가능하고, 이 객체는 스크립트를 실행하는 동안에 함수를 동적으로 만들고 호출할 때 사용
    • Function 객체는 함수의 파라미터와 본문을 Function() 생성자에 제공하면 된다.
      variable=new Function("p1","p2", ... ,"pn","body")
    • Function 객체 프로퍼티
      • length : 함수에 대해 정의된 파라미터의 숫자 식별
      • prototype : 모든 객체 유형이 지원하는 프로퍼티로 객체 유형에 대해 추가적인 프로퍼티 및 메소드 정의 가능
      • arguments : 호출시 함수에 전달되는 인자를 가리키는 배열
      • caller : 특정 함수를 호출한 함수를 가리킴
    • Function 객체의 메소드
      • toString() : 함수의 스트링 형태 리턴
      • valueOf() : 함수 자체 리턴


    Global 객체

    • new Global() 을 통해서 명시적으로 만들거나, 참조할 수 없다. 대신 해당 프로퍼티와 메소드가 전역 변수와 함수로 직접 참조됨
    • Global 객체의 프로퍼티
      • Nan : 숫자가 아니라는 의미
      • Infinity : 양수 무한대 값 의미
    • Global 객체의 메소드
      • escape(string) : string을 새로운 스트링으로 변환
      • eval(x) : 표현식 x의 값을 계산하고 리턴
      • inFinite(number) : number가 유한하면 true를 리턴하고, 무한하면 false를 리턴
      • inNaN(number) : number가 숫자가 아니면 true를 리턴하고, 숫자이면 false를 리턴
      • parseFloat(string) : string을 부동 소수 값으로 파싱
      • parseInt(string,radix) : string을 밑이 radix인 정수로 파싱
      • unescape(string) : escape()에 들어 있는 스트링을 원래의 값으로 되돌린다.


    Math 객체

    • 수학적 상수와 함수의 표준 라이브러리 제공
    • Math의 특수 인스턴스는 Math가 내장 객체이고 객체 유형이 아니기 때문에 만들어지지 않는다.

    Math 프로퍼티
    프로퍼티 설 명
    E Euler의 상수. 이것은 계산을 하는 어디에서나 발견할 수 있으며 자연대수의 기초
    LN2 2의 자연대수. 이것은 자연대수와 밑이 2인 대수 사이의 전환에 사용되는 간단한 상수
    LN10 10의 자연대수. LN2와 마찬가지로 대수 변환에 사용
    LOG2E 밑이 2인 E의 대수. 이것은 밑이 10인 대수를 밑이 E인 대수로 변환시 사용
    PI 원의 원주 대 지름의 비율
    SQRT1_2 1/2의 제곱근은 많은 삼각법 계산에서 사용
    SQRT2 2의 제곱근은 대수식에서 흔히 사용

    Math 메소드
    메 소 드 설 명
    abs(x) x의 절대값 리턴
    acos(x) x의 아크 코사인값 라디안으로 리턴
    asin(x) x의 아크 사인값 라디안으로 리턴
    atan(x) x의 아크 탄젠트 값을 라디안으로 리턴
    atan2(x,y) (x,y)에 해당하는 극좌표의 각도를 리턴
    ceil(x) x보다 크거나 작은 최소 정수값 리턴
    cos(x) x의 코사인 값 리턴
    exp(x) eX를 리턴
    floor(x) x보다 작거나 같은 최대 정수값 리턴
    log(x) x의 자연대수 리턴
    max(x,y) x, y 중 큰 값 리턴
    min(x,y) x, y 중 작은 값 리턴
    pow(x,y) xy를 리턴
    random() 0과 1사이의 임의의 숫자 리턴
    round(x) x의 가장 가까운 정수로 반올림되는 값 리턴
    sin(x) x의 사인값 리턴
    sqrt(x) x의 제곱근 리턴
    tan(x) x의 탄젠트 값 리턴


    Number 객체

    • Number 객체 유형을 사용하면 숫자를 객체로 다룰 수 있다.
    • Number 객체의 프로퍼티
      • MAX_VALUE : 숫자는 가능한 최대 수치값
      • MIN_VALUE : 숫자는 가능한 최소 수치값
      • NaN : 숫자가 아니다
      • NEGATIVE_INFINITY : 숫자가 음수 무한대 값
      • POSITIVE_INFINITY : 숫자가 양수 무한대 값
      • prototype : 모든 객체 유형이 지원
    • Number 객체의 메소드
      • toString(radix) : 밑이 radix인 숫자를 나타내는 스트링 리턴
      • valueOf() : Number 객체의 수치값 리턴


    Object 객체

    • Object 객체는 다른 모든 객체들이 파생되어 나가는 기반 객체로 이것의 프로퍼티와 메소드는 다른 객체 유형들에서 사용 가능
    • Object 객체의 프로퍼티
      • prototype : 모든 객체 유형이 지원
      • constructor : 객체 생성자의 이름 식별
    • Object 객체의 메소드
      • toString() : 객체를 스트링 표현으로 바꾸는 역할
      • valueOf() : 객체와 관련된 경우의 원시값(숫자,스트링,부울값)을 리턴하고, 그렇지 않은 경우에는 객체 자체를 리턴


    String 객체

    • 스트링을 객체로 액세스 가능
    • String 객체의 프로퍼티
      • length : 문자에서 스트링의 길이 알아내는 역할
      • prototype : 모든 객체 유형이 지원
    String 메소드
    메 소 드 설 명
    charAt(index) 메소드가 적용되는 스트링의 지정된 인덱스에 있는 문자로 구성된 스트링을 리턴
    charCodeAt(index) 지정된 인덱스의 문자의 Unicode 인코딩 리턴
    fromCharCode(codes) 문자 코드의 컴마로 구분된 시퀀스에서 스트링 만듬
    indexOf(pattern) 스트링안에 들어있는 pattern 파라미터가 지정한 첫 번째 스트링의 인덱스 리턴, 패턴이 스트링 안에 들어있지 않으면 -1 리턴
    indexOf(pattern,startIndex) startIndex가 지정한 위치에서 검색을 시작하는 것을 제외하면 indexOf(pattern) 메소드와 같다.
    lastIndexOf(pattern) 스트링에 들어 있는 pattern 파라미터가 지정한 마지막 스트링의 인덱스 리턴, 패턴이 스트링 안에 들어있지 않으면 -1 리턴
    lastIndexOf(pattern,startIndex) startIndex가 지정한 위치에서 검색을 시작하는 것을 제외하면 lastIndexOf(pattern)과 같다.
    splitSeparator() 하나의 스트링을 분리자를 기반으로 하여 서브스트링의 배열로 분리
    substring(startIndex) startIndex에서 시작하는 스트링의 서브스트링을 리턴
    substring(startIndex,endIndex) startIndex에서 시작하고, endIndex에서 끝나는 스트링의 서브스트링을 리턴
    toLowerCase() 소문자로 변환된 스트링의 복사본 리턴
    toString() 객체의 스트링 값을 리턴
    toUpperCase() 대문자로 변환된 스트링의 복사본 리턴
    valueOf() 객체의 스트링 값을 리턴

  • Posted by la30321
    Oracle 관련2005. 9. 20. 15:56

    SELECT SUBSTR(A.COLUMN_NAME,1,15) AS COLUMN_NAME -- 컬럼명
    , DECODE(B.CONSTRAINT_TYPE, 'P','PRIMARY KEY' ,
               'U','UNIQUE KEY' ,
                'C','CHECK OR NOT NULL',
    'R','FOREIGN KEY' ) AS CONSTRAINT_TYPE -- 제약조건 TYPE
    , A.CONSTRAINT_NAME   AS CONSTRAINT_NAME -- 제약 조건 명
    FROM USER_CONS_COLUMNS A
    , USER_CONSTRAINTS B  
    WHERE A.TABLE_NAME = UPPER('AAC010TL')  
    AND A.TABLE_NAME = B.TABLE_NAME  
    AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME  
    ORDER BY 1; 

    Posted by la30321
    Java2005. 6. 29. 10:39
    How to find bottleneck in J2EE application




    자바스터디 네트워크 [www.javastudy.co.kr]

    조대협 [bcho_N_O_SPAM@j2eestudy.co.kr]




    J2ee application을 운영하다보면, 시스템이 극도로 느려지거나, 멈춰버리는 현상이 생기고는 한데, 분명히 개발하면서 테스트할때는 문제가 없었는데, 왜 이런일이 생기고, 어떻게 대처해야하는지에 대해서 알아보도록 하자.


    일반적으로 J2ee application을 서비스 하기 위해서는 아래와 같은 구조를 가지게 된다.


    <그림 1. 일반적인 J2ee application의 구조>


    J2ee application의 동작에 필요한 구성 요소를 나눠보면 위와 같이 Network, User Application (이하 User AP), WAS 또는 Servlet Engine(이하 통칭해서 WAS),JVM과 RDBMS 이렇게 크게 다섯가지 조각으로 나뉘어 진다. 물론 JCA를 이용해서 Legacy와 연결할 수 도 있고, RMI/CORBA를 이용하여 다른 Architecture를 구현할 수 는 있으나, 이 강좌는 어디까지나 일반론을 설명하고자 하는것임으로 범위에서는 제외하겠다.


    1. Hang up과 slow down현상의 정의


    먼저 용어를 정의하도록 하자.. 시스템이 느려지거나 멈추는 현상에 대해서 아래와 같이 용어를 정의하자

    - Hang up : Server Instance는 실행되고 있느나, 아무런 응답이 없는 상황 (멈춤 상태)
    - Slowdown : Server Instance의 response time이 아주 급격히 떨어지는 상태 (느려짐)

    이 Hangup과 slowdown현상은, 대부분이 그림 1에서 설명한 다섯가지 요소중 하나 이상의 병목으로 인해서 발생한다. 즉, 이 병목 구간을 발견하고, 그 구간을 제거하면 정상적으로 시스템을 운영할 수 있게 되는것이다.


    2. Slow down analysis in WAS & User AP


    2-1. WAS의 기본 구조

    이 병목 구간을 발견하는 방법에 앞서서, 먼저 WAS 시스템의 기본적인 내부 구조를 이해할 필요가 있다.


    <그림 2. WAS 시스템의 구조>


    <그림 2>는 일반적인 WAS의 구조이다.
    WAS는 Client로 부터 request를 받아서, 그 Request의 내용을 분석한다 JMS인지, HTTP , RMI request인지를 분석한후 (Dispatcher) 그 내용을 Queue에 저장한다.

    Queue에 저장된 내용은 WAS에서 Request를 처리할 수 있는 Working Thread들이 있을때 각각의 Thread들이 Queue에서 Request를 하나씩 꺼내서 각각의 Thread들이 그 기능을 수행한다.

    여기서 우리가 주의깊게 봐야하는것은 Thread pooling이라는 것인데.
    Thread를 미리 만들어놓고, Pool에 저장한체로 필요할때 그 Thread 를 꺼내서 사용하는 방식이다. (Connection Pooling과 같은 원리이다.)

    WAS에서는 일반적으로 업무의 성격마다 이 Thread Pool을 나누어서 만들어놓고 사용을 한다. 즉 예를 들어서 금융 시스템의 예금 시스템과 보험 시스템이 하나의 WAS에서 동작할때, 각각의 업무를 Thread Pool을 나누어서 분리하는 방식이다. 이 방식을 사용하면 업무의 부하에 따라서 각 Thread Pool의 Thread수를 조정할 수 있으며, 만약에 Thread가 모자르거나 deadlock등의 장애사항이 생기더라도 그것은 하나의 Thread Pool에만 국한되는 이야기이기 때문에, 다른 업무에 영향을 거의 주지 않는다.

    2-2. Thread Dump를 통한 WAS의 병목 구간 분석

    위에서 살펴봤듯이, WAS는 기본적으로 Thread 기반으로 작동하는 Application이다. 우리가 hang up이나 slow down은 대부분의 경우가 WAS에서 현상이 보이는 경우가 많다. (WAS에 원인이 있다는 소리가 아니라.. 다른 요인에 의해서라도 WAS의 처리 속도가 느려질 수 있다는 이야기다.)

    먼저 이 WAS가 내부적으로 어떤 Application을 진행하고 있는지를 알아내면 병목 구간에 한층 쉽게 접근할 수가 있다.

    1) What is thread dump?

    이를 위해서 JVM에서는 Java Thread Dump라는 것을 제공한다.
    Thread Dump란 Java Application이 작동하는 순간의 X-Ray 사진, snapshot을 의미한다.
    즉 이 Thread dump를 연속해서 수번을 추출한다면, 그 당시에 Application이 어떻게 동작하고 진행되고 있는가를 살펴볼 수 있다.

    Thread dump를 추출하기 위해서는
    - Unix 에서는 kill -3 pid
    - Windows 계열에서는 Ctrl + break
    를 누르면 stdout으로 thread dump가 추출 된다.

    Thread dump는 Application을 구성하고 있는 현재 구동중인 모든 Thread들의 각각의 상태를 출력해준다.


    <그림 3-2. Thread dump>


    그림 3-2는 전체 Thread dump중에서 하나의 Thread를 나타내는 그림이다.
    Thread Dump에서 각각의 Thread는 Thread의 이름과, Thread의 ID, 그리고 Thread 의 상태와, 현재 이 Thread가 실행하고 있는 Prorgam의 스택을 보여준다.

    - Thread name
    각 쓰레드의 이름을 나타낸다.
    ※ WAS나 Servlet Engine에 따라서는 이 이름에 Thread Queue이름등을 배정하는 경우가 있다.

    - Thread ID
    쓰레드의 System ID를 나타낸다. 이 강좌 나중에 이 ID를 이용해서 각 Thread별 CPU 사용률을 추적할 수 있다.

    - Thread Status
    매우 중요한 값중의 하나로 각 Thread의 현재 상태를 나타낸다. 일반적으로 Thread가 사용되고 있지 않을때는 wait를 , 그리고 사용중일때는 runnable 을 나타내는게 일반적이다.
    그외에, IO Wait나 synchronized등에 걸려 있을때 Wait for monitor entry, MW (OS별JVM별로 틀림) 등의 상태로 나타난다.

    - Program stack of thread
    현재 해당 Thread가 어느 Class의 어느 Method를 수행하고 있는지를 나타낸다. 이 정보를 통해서 현재 WAS가 어떤 작업을 하고 있는지를 유추할 수 있다.

    2) How to analysis thread dump

    앞에서 Thread dump가 무엇이고, 어떤 정보를 가지고 있는지에 대해서 알아봤다. 그러면 이 Thread dump를 어떻게 분석을 하고, System의 Bottle neck을 찾아내는데 이용할지를 살펴보기로 하자.

    System이 Hangup이나 slowdown에 걸렸을때, 먼저 Thread dump를 추출해야 한다. 이때 한개가 아니라 3~5초 간격으로 5개 정도의 dump를 추출한다. 추출한 여러개의 dump를 연결하면 각 Thread가 시간별로 어떻게 변하고 있는지를 판별할 수 있다.

    먼저 각각의 Thread 덤프를 비교해서 보면, 각각의 Thread는 적어도 1~2개의 덤프내에서 연속된 모습을 보여서는 안되는게 정상이다. 일반적으로Application은 내부적으로 매우 고속으로 처리되기 때문에, 하나의 Method에 1초이상 머물러 있는다는것은 거의 있을 수 없는 일이다.
    Thread Dump의 분석은 각각의Thread가 시간이 지남에 따라서 진행되지 않고 멈춰 있는 Thread를 찾는데서 부터 시작된다.

    예를 들어서 설명해보자 . 아래 <그림 3-3>의 프로그램을 보면 MY_THREAD_RUN()이라는 메소드에서 부터 MethodA()aMethodB()aMethodC() 를 차례로 호출하는 형태이다.


    <그림 3-3. sample code>


    이 프로그램을 수행하는 중에 처음부터 Thread Dump를 추출 하면 대강 다음과 같은 형태일것임을 예상할 수 있다. 함수 호출에 따라서 Stack이 출력되다가 ◇의 단계 즉 MethodC에서 무한루프에 빠지게 되면 더이상 프로그램이 진행이 없기 때문에 똑같은 덤프를 유지하게 된다.



    우리는 이 덤프만을 보고 methodC에서 무엇인가 잘못되었음을 유추할 수 있고, methodC의 소스코드를 분석함으로써 문제를 해결할 수 있다.

    그렇다면 이제부터 Slow down과 Hang up현상을 유발하는 일반적인 유형과 그 Thread Dump의 모양에 대해서 알아보도록 하자.


    [CASE 1] lock contention

    잘 알다싶이 Java 는 Multi Threading을 지원한다. 이 경우 공유영역을 보호하기 위해서 Synchronized method를 이용하는데, 우리가 흔히들 말하는 Locking이 이것이다.

    예를 들어 Thread1이 Synchronized된 Method A의 Lock을 잡고 있는 경우, 다른 쓰레드들은 그 Method를 수행하기 위해서, 앞에서 Lock을 잡은 쓰레드가 그 Lock을 반환하기를 기다려야한다. <그림 3-4>


    <그림 3-4. Thread 간에 Lock을 기다리는 형태>


    만약에 이 Thread 1의 MethodA의 수행시간이 아주 길다면 Thread 2,3,4는 마냥 이 수행을 아주 오랜 시간 기다려야하고, 다음 2번이 Lock을 잡는다고 해도 3,4번 Thread들은 1번과 2번 쓰레드가 끝난 시간 만큼의 시간을 누적해서 기다려야 하기때문에, 수행시간이 매우 느려지는 현상을 겪게 된다.

    이처럼 여러개의 Thread가 하나의 Lock을 동시에 획득하려고 하는 상황을 Lock Contention 이라고 한다.


    <그림 3-5. Lock Contention 상황에서 Thread의 시간에 따른 진행 상태>


    이런 상황에서 Thread Dump를 추출해보면 <그림 3-6> 과 같은 형태를 띠게 된다.


    <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump>


    그림 3-6의 덤프를 보면 12번 Thread가 org.apache.axis.utils.XMLUtils.getSAXParser에서 Lock을 잡고 있는것을 볼 수 있고, 36,15,14번 쓰레드들이 이 Lock을 기다리고 있는것을 볼 수 있다.

    [CASE 1] 해결방안

    이런 Lock Contention 상황은 Multi Threading환경에서는 어쩔 수 없이 발생하는 상황이기는 하지만, 이것이 문제가 되는 경우는 Synchronized Method의 실행 시간이 불필요하게 길거나, 불필요한 Synchronized문을 사용했을 때 발생한다.

    그래서 이 문제를 해결하기 위해 불필요한 Sychronized Method의 사용을 자제하고, Synchronized block 안에서의 최적화된 Algorithm을 사용하는것이 필요하다.


    [CASE 2] dead lock

    이 Locking으로 인해서 발생할 수 있는 또 다른 문제는 dead Lock 현상이다. 두개 이상의 쓰레드가 서로 Lock을 잡고 기다리는 “환형대기조건” 이 성립되었을때, 서로 Lock이 풀리지 않고 무한정 대기하는 현상을 이야기 한다.

    <그림 3-7>을 보면 Thread1은 MethodA를 수행하고 있는데, sychronized methodB를 호출하기전에 Thread2가 methodB가 끝나기를 기다리고 있다. 마찬가지로 Therad2는 Thread3가 수행하고 있는 methodC가 끝나기를 기다리고 있고, methodC에서는 Thread1에서 수행하고 있는 methodA가 끝나기를 기다리고 있다.
    즉 각각의 메소드들이 서로 끝나기를 기다리고 있는 “환형 대기조건” 이기 때문에 이 Application의 3개의 쓰레드들은 프로그램이 진행이 되지 않게 된다.


    <그림 3-7. 환형 대기조건에 의한 deadlock>


    이러한 “환형대기조건”에 의한 deadlock은 Thread Dump를 추출해보면 <그림 3-8> 과 같은 패턴을 띠우고 있으며 시간이 지나도 풀리지 않는다.


    <그림 3-8. Deadlock이 걸렸을때 시간 진행에 따른 Thread의 상태>



    <그림 3-9. Deadlock이 걸린 IBM AIX Thread Dump>


    DeadLock의 검출은 Locking Condition을 비교함으로써 검출할 수 있으며, 최신 JVM (Sun 1.4이상등)에서는 Thread Dump 추출시 만약 Deadlock이 있다면 해당 Deadlock을 찾아주는 기능을 가지고 있다.

    <그림 3-9>를 보자. IBM AIX의 Thread 덤프이다. 1)항목을 보면 현재 8번 쓰레드가 잡고 있는 Lock은 10번과 6번 쓰레드가 기다리고 있음을 알 수 있으며. Lock은 OracleConnection에 의해서 잡혀있음을 확인할 수 있다. (아래)



    <그림 3-9>의 2)번 항목을 보면 이 6번쓰레드는 OracleStatement에서 Lock을 잡고 있는데, 이 Lock을 8번 쓰레드가 기다리고 있다. (아래)



    결과적으로 6번과 8번은 서로 Lock을 기다리고 있는 상황이 되어 Lock이 풀리지 않는 Dead Lock상황이 된다.

    [CASE 2] 해결 방안

    Dead Lock의 해결 방안은 서로 Lock을 보고 있는것을 다른 Locking Object를 사용하거나 Lock의 방향 (Synchronized call의 방향)을 바꿔줌으로써 해결할 수 있다.

    User Application에서 발생한 경우에는 sychronized method의 호출 순서를 “환형대기조건”이 생기지 않도록 바꾸도록 하고.
    위와 같이 Vendor들에서 제공되는 코드에서 문제가 생긴경우에는 Vendor에 패치를 요청하도록 하여 해결한다.


    [CASE 3] wait for IO response

    다음으로 많이 볼 수 있는 패턴은 각각의 Thread들이 IO Response를 기다리는데… IO작업에서 response가 느리게 와서 시스템 처리속도가 느려지는 경우가 있다.


    <그림 3-10. Thread들이 IO Wait를 할때 시간에 따른 Thread Dump 상황>



    <그림 3-11. Thread가 DB Query Wait에 걸려 있는 stack>


    <그림 3-10> 상황은 DB에 Query를 보내고 response를 Thread들이 기다리고 있는 상황이다. AP에서 JDBC를 통해서 Query를 보냈는데, Response가 오지 않으면 계속 기다리게 있게 되고, 다른 Thread가 같은 DB로 보냈는데. Response가 오지 않고, 이런것들이 중복되서 결국은 사용할 수 없는 Thread가 없게 되서 새로운 request를 처리하지 못하게 되고, 기존에 Query를 보낸 내용도 응답을 받지 못하는 상황이다.

    <그림 3-11>은 각각의 Thread의 stack dump인데, 그 내용을 보면 ExecuteQuery를 수행한후에, Oracle로 부터 데이타를 read하기 위해 대기 하는것을 확인할 수 있다.

    이런 현상은 주로 DB 사용시 대용량 Query(시간이 많이 걸리는)를 보냈거나, DB에 lock들에 의해서 발생하는 경우가 많으며, 그외에도 Socket이나 File을 사용하는 AP의 경우 IO 문제로 인해서 발생하는 경우가 많다.

    [CASE 3] 해결 방안

    이 문제의 해결 방안은 Thread Dump에서 문제가 되는 부분을 발견한후에, 해당 소스코드나 시스템등에 접근하여 문제를 해결해야한다.


    [CASE 4] high CPU usage

    시스템이 느려지거나 거의 멈추었을때, 우리가 초기에 해볼 수 있는 조치가 무엇인가 하면, 현재 시스템의 CPU 사용률을 체크해볼 필요가 있다.

    해당 시스템의 CPU 사용률이 높은 경우, 문제가 되는경우가 종종 있는데. 이런 문제에서는 CPU를 많이 사용하는 모듈을 찾아내는것이 관건이다.

    이를 위해서 먼저 top 이나 glance(HP UX)를 통해서 CPU를 많이 점유하고 있는 Process를 판독한다. 만약 WAS 이외의 다른 process가 CPU를 많이 사용하고 있다면, 그 Process의 CPU 과사용 원인을 해결해야 한다. CPU 사용률이외에도, Disk IO양이 많지는 않은지.. WAS의 JVM Process가 Swap out (DISK로 SWAP되는 현상) 이 없는지 살펴보도록 한다. JVM Process가 Swapping이 되면 실행속도가 엄청나게 느려지기 때문에, JVM Process는 Swap out 되어버리면 안된다.

    일단 CPU를 과 사용하는 원인이 WAS Process임을 발견했으면 프로그램상에 어떤 Logic이 CPU를 과점유하는지를 찾아내야한다.

    방식을 정리해보면 다음과 같다.
    WAS Process의 Thread별 CPU 사용률을 체크한다. ← 1)
    Thread Dump를 추출한다. ← 2)

    1)과, 2)에서 추출한 정보를 Mapping하여, 2)의 Thread Dump상에서 CPU를 과점유하는 Thread를 찾아내어 해당 Thread의 Stack을 분석하여 CPU 과점유하는 원인을 찾아낸다.

    대부분 이런 요인을 분석해보면 다음과 같은 원인이 많다.

    과도한 String 연산으로 인해서 CPU 사용률이 높아지는 경우

    잘 알고 있다시피 String 연산은 CPU 를 아주 많이 사용한다. String과 Loop문(for,while등)의 사용은 CPU부하를 유발하는 경우가 많기 때문에 가급적이면 String Buffer를 사용하도록 하자.

    과도한 RMI Cal
    RMI호출은 Java Object를 Serialize하고 Deserialize하는 과정을 수반하는데, 이는 CPU를 많이 사용하는 작업이기 때문에 사용에 주의를 요한다. 특별히 RMI를 따로 코딩하지 않더라도 EJB를 호출하는것이 Remote Call일때는 기본적으로 RMI호출을 사용하게 되고, 부하량이 많을때 이 부분이 주로 병목의 원인이 되곤한다. 특히 JSP/ServletaEJB 호출되는것이 같은 System의 같은 JVM Process안이라도 WAS별로 별도의 설정을 해주지 않으면 RMI Call을 이용하는 형태로 구성이 되기 때문에, 이에 대한 배려가 필요하다.
    ※ WebLogic에서 Call By Reference를 위한 호출 방법 정의

    참고로 WebLogic의 경우에는 Servlet/JSPaEJB를 호출하는 방식을 Local Call을 이용하기 위해서는 같은 ear 파일내에 패키징해야하고, EJB의 weblogic-ejb-jar.xml에 enable-call-by-reference를 true로 설정해줘야한다. (8.1이상)

    자세한 내용은
    http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?table=j2ee&db=lecture0201_1&id=1&searchBy=subject&searchKey=deploy&block=0&page=0를 참고하시 바란다.

    JNDI lookup

    JNDI lookup은 Server의 JNDI에 Binding된 Object를 읽어오는 과정이다. 이 과정은 위에서 설명한 RMI call로 수행이되는데. 특히 EJB를 호출하기 위해서 Home과 Remote Interface를 lookup하는 과장에서 종종 CPU를 과점유하는 형태를 관찰 할 수 있다.

    그래서 JNDI lookup의 경우에는 EJB Home Interface를 Caller Side(JSP/Servlet 또는 poor Java client)등에서 Caching해놓고 사용하는 것을 권장한다. 단. 이경우에는 EJB의 redeploy기능을 제약받을 수 있다.

    다음은 각 OS별로 CPU 사용률이 높은 Thread를 검출해내는 방법이다.


    ■ Solaris에서 CPU 사용률이 높은 Thread를 검출하는 방법


    1.prstat 명령을 이용해서 java process의 LWP(Light Weight process) CPU 사용률을 구한다.

    % prstat -L -p [WeblogicPID] 1 1


    <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump>


    2. pstack 명령어를 이용해서 native thread와 LWP 간의 id mapping을 알아낸다.
    (※ 전에 먼저 java process가 lwp로 돌아야되는데, startWebLogic.sh에 LD_LIBRARY_PATH에 /usr/lib/lwp 가 포함되어야 한다.)

    % pstack [WebLogicPID]


    <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump>


    3. 1에서 얻은 LWP ID를 pstack log를 통해서 분석해보면 어느 Thread에 mapping되는지를 확인할 수 있다.
    여기서는 LWP 8이 Thread 24과 mapping이 되고 있음을 볼 수 있다.

    kill -3 [WebLogicPID]를 해서 ThreadDump를 얻어낸다.


    <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump>


    Thread dump에서 nid라는 것이 있는데, 2에서 얻어낸 thread id를 16진수로 바꾸면 이값이 nid값과 같다. 즉 2에서 얻어낸 thread 24는 16진수로 0x18이기 때문에, thread dump에서 nid가 0x18인 쓰레드를 찾아서 어떤 작업을하고 있는지를 찾아내면 된다.



    ■ AIX Unix에서 CPU 사용률이 높은 Thread 검출해 내기


    1. ps 명령을 이용하여, WebLogic Process의 각 시스템thread의사용률을 구한다.

    % ps -mp [WeblogicPID] -0 THREAD



    여기서 CP가 가장 높은 부분을 찾는다. 이 시스템 쓰레드가 CPU를 가장 많이 점유하고 있는 시스템 쓰레드이다. (여기서는 66723 이다.)

    2. dbx 명령을 이용해서 1.에서 찾은 시스템 쓰레드의 Java Thread ID를 얻어온다.

    1) % dbx -a [WebLogicPID]
    2) dbx에서 “thread” 명령을 치면 Thread ID 를 Listing할 수 있다.



    k-tid 항목에서 1에서 찾은 Thread ID 를 찾고, 그 k-tid에 해당하는 thread id를 찾는다. (여기서는 $t17이 된다.)

    3) dbx에서 $t17 번 쓰레드의 Java Thread ID를 얻는다.
    dbx에서 “th info 17” 이라고 치면 $t17번 쓰레드의 정보를 얻어온다.



    pthread_t 항목에서 Java Thread ID를 얻는다. 여기서는 1011이된다.

    3. Java Thread Dump에서 2에서 얻어온 Java Thread ID를 이용해서 해당 Java Thread를 찾아서 Java Stack을 보고 CPU를 많이 사용하는 원인을 찾아낸다.

    1) kill -3 [WebLogicPID]
    2) Thread dump를 보면 native ID 라는 항목이 있는데, 2.에서 찾은 Java Thread ID와 이 항목이 일치하는 Execute Thread를 찾으면 된다.





    ■ HP Unix에서 CPU 사용률이 높은 Thread 검출해내기


    1. 먼저 JVM이 Hotspot mode로 작동하고 있어야 한다. (classic 모드가 아니어야 한다.) 옵션을 주지 않았으면 Hotspot 모드가 default이다.

    2. glance를 실행해서 ‘G’를 누르고 WAS의 PID를 입력한다.
    각 Thread의 CPU 사용률이 실시간으로 모니터링이 되는데.



    여기서 CPU 사용률이 높은 Thread의 TID를 구한다.

    3. kill -3 을 이용해서 Thread dump를 추출해서. 2에서 구한 TID와 Thread Dump상의 lwp_id가 일치하는 Thread를 찾으면 된다.



    지금까지 Thread Dump를 이용하는 방법을 간단하게 살펴보았다. 이 방법을 이용하면 WAS와 그 위에서 작동하는 Appllication의 Slow down 이나 hangup의 원인을 대부분 분석해낼 수 있으나, Thread Dump는 어디까지나 분석을 위한 단순한 정보이다. Thread Dump의 내용이 Slow down이나 hang up의 원인이 될수도 있으나, 반대로 다른 원인이 존재하여 그 결과로 Thread Dump와 같은 Stack이 나올 수 있기 때문에, 여러 원인을 동시에 살펴보면서 분석할 수 있는 능력이 필요하다.


    3. Slow down in JVM


    WAS의 성능에 큰 영향을 주는것중의 하나가 JVM이다.
    JVM의 튜닝 여부에 따라서 WAS상에서 작동하는 Ap의 성능을 크게는 20~30% 까지 향상시킬 수 있는데, 우리가 지금 살펴보고 있는 slow down과 hangup 을 일으키는 직접적인 요인이 되는것은 JVM의 Full GC이다.

    간단하게 JVM의 메모리 구조를 검토하고 넘어가보도록 하자.

    <그림 4-1. JVM의 메모리 구조>


    JVM은 크게 New영역과 Old영역, 그리고 Perm영역 3가지로 분류가 된다.
    Perm 영역은 Class나 Method들이 로딩되는 영역이고 성능상의 영향을 거의 미치지 않는다.

    우리가 주목해야할 부분은 객체의 생성과 저장에 관련되는 New와 Old 영역인데, 모든 객체는 생성이 되자 마자 New 영역에 저장되고, 시간이 지남에 따라 이 객체들은 Old 영역으로 이동이 된다.

    New 영역을 Clear하는 과정을 Minor GC라하고, Old 영역을 Clear하는 과정은 Major GC또는 Full GC라 하는데, 성능상의 문제는 이 Full 영역에서 발생한다.

    Minor GC의 경우는 1초 이내에 아주 고속으로 이뤄지는 작업이기 때문에, 신경을 쓸 필요가 없지만, Full GC의 경우에는 시간이 매우 오래걸린다.
    또한 Full GC가 발생할 동안은 Application이 순간적으로 멈춰 버리기 때문에 시스템이 순간적으로 Hangup 으로 보이거나 또는 Full GC가 끝나면서 갑자기 request가 몰려버리는 현상 때문에 종종 System의 장애를 발생시키는 경우가 있다.

    Full GC는 통상 1회에 3~5초 정도가 적절하고, 보통 하루에 JVM Instance당 5회 이내가 적절하다고 여겨진다. (절대 값은 없다.)

    Full GC가 자주 일어나는것이 문제가 될경우에는 JVM의 Heap영역을 늘려주면 천천히 일어나지만 반대로 Full GC에 소요되는 시간이 증가한다.

    개당 Full GC 시간이 오래걸릴 경우에는 JVM의 Heap 영역을 줄여주면 빨리 Full GC가 끝나지만 반대로 Full GC가 자주 일어난다는 단점이 있다.

    그래서 이 부분에 대한 적절한 Tuning이 필요하다.

    대부분의 Full GC로 인한 문제는 JVM자체나 WAS의 문제이기 보다는 그 위에서 구성된 Application이 잘못 구성되어 메모리를 과도하게 사용하거나 오래 점유하는 경우가 있다.

    예를 들어 대용량 DBMS Query의 결과를 WAS상의 메모리에 보관하거나 , 또는 Session에 대량의 데이타를 넣는것들이 대표적인 예가 될 수 가 있다.

    좀더 자세한 튜닝 방법에 대해서는 http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?db=lecture0401_1&table=j2ee&id=1를 참고하기 바란다.


    4. Slow down analysis in DBMS


    Application이 느려지는 원인중의 많은 부분을 차지 하고 있는 것은 DBMS의 성능 문제가 있는 경우가 많다.

    흔히들 DBMS Tuning을 받았더니 성능이 많이 향상되었다고 하는 경우가 많은데, 그건 그만큼 DB 설계를 제대로 하지 못했다는 이야기가 된다.

    DBMS 자체 Tuning에 대한 것은 이 문서와는 논외기 때문에 제외하기로 하고, DBMS에 전송되는 각각의 SQL문장의 실행 시간을 Trace할 수 있는 것만으로도 많은 성능 향상을 기대할 수 있는데, 간단하게 SQL 문장을 실행시간은 아래 방법들을 이용해서 Trace할 수 있다.

    http://eclipse.new21.org/phpBB2/viewtopic.php?printertopic=1&t=380&start=0&postdays=0&postorder=asc&vote=viewresult

    http://www.j2eestudy.co.kr/qna/bbs_read.jsp?table=j2ee&db=qna0104&id=5&searchBy=subject&searchKey=sql&block=0&page=0


    5. Slow down analysis in Webserver & network


    WAS와 DBMS 앞단에는 WebServer와 Network 이 있기 때문에 이 Layer에서 문제가 되면 속도저하를 가지고 올 수 있다. 필자의 경험상 대부분의 slow down이나 hangup은 이 부분에서는 거의 일어나지 않지만 성능상에 종종 영향을 주는 Factor가 있는데,

    WebServer 와Client간의 KeepAlive

    특히 WebServer의 Keep Alive설정이 그것이다.
    WebBrowser와 WebServer간에는 KeepAlive 설정을 하는것이 좋은데. 그 이유는 WebBrowser에서 하나의 HTML 페이지를 로딩하기 위해서는 Image와 CSS등의 여러 파일등을 로딩하는데, KeepAlive 설정이 없으면 각각의 파일을 로딩하는것에 각각의 Connection을 open,request,download,close를 한다. 잘들알고 있겠지만 Socket을 open하고 close하는데에는 많은 자원이 소요된다. 그래서 한번 연결해놓은 Connection을 계속 이용해서 HTTP data를 주고 받는 설정이 KeepAlive이다.
    이 KeepAlive 설정은 웹을 이용한 서비스 제공에서 많은 성능 변화를 주기 때문에 특별한 이유가 없는한 KeepAlive 설정을 유지하기 바란다. 설정 방법은 각 WebServer의 메뉴얼을 참고하기 바란다.

    ※ Apache2.0의 Keep Alive 설정은
    http://httpd.apache.org/docs-2.0/mod/core.html#keepalive를 참고하기 바란다. Default가 KeepAlive 가 On으로 되어 있다.

    WebServer와 WAS간의 KeepAlive

    WebServer와 WAS간에는 WebServer에서 받은 request를 forward하기 위해서 WebServer Side에 WAS와 통신을 하기 위한 plug-in 이라는 모듈을 설치하게 된다. 이 역시 WebServer와 Client간의 통신과의 같은 원리로 KeepAlive를 설정하게 되는데, 이 역시 성능에 영향을 줄 수 있는 부분이기 때문에 가급적이면 설정하기를 권장한다.

    ※ WebLogic에서 Webserver와의 KeepAlive설정은
    http://e-docs.bea.com/wls/docs81/plugins/plugin_params.html#1143055을 참고하기 바란다.
    Default는 KeepAlive가 True로 설정되어 있다.

    OS에서 Kernel Parameter 설정

    OS의 TCP/IP Parameter와, Thread와 Process등의 Kernel Parameter 설정이 운영에 있어서 영향을 미치는 경우가 있다. 이 Parameter들은 Tuning하기가 쉽지 않기 때문에, WAS또는 OS Vendor에서 제공하는 문서를 통해서 Tuning하기 바란다.

    ※ WebLogic의 OS별 설정 정보은
    http://e-docs.bea.com/platform/suppconfigs/configs81/81_over/overview.html를 참고하기 바란다.


    6. Common mistake in developing J2EE Application


    지금까지 간단하게나마 J2EE Application의 병목구간을 분석하는 부분에 대해서 알아보았다. 대부분의 병목은 Application에서 발생하는 경우가 많은데, 이런 병목을 유발하는 Application에 자주 발생하는 개발상의 실수를 정리해보도록 하자.

    1) Java Programming

    sycnronized block
    위에서도 설명 했듯이 sychronized 메소드는 lock contention과 deadlock등의 문제를 유발할 수 있다. 꼭 필요한 경우에는 사용을 해야하지만, 이점을 고려해서 Coding해야한다.

    String 연산

    이미 많은 개발자들이 알고 있는 내용이겠지만 String 연산 특히 String연산중 “+” 연산은 CPU를 매우 많이 소모하게 되고 종종 slow down의 직접적인 원인이 되는 경우가 매우 많다.
    String 보다는 가급적 StringBuffer를 사용하기 바란다.

    Socket & file handling

    Socket이나File Handling은 FD (File Descriptor)를 사용하게 되는데, 이는 유한적인 자원이기 때문에 사용후에 반드시 close명령을 이용해서 반환해야한다. 종종 close를 하지 않아서, FD가 모자르게 되는 경우가 많다.

    2) Servlet/JSP Programming

    JSP Buffer Size

    Jsp 에서는 JSP의 출력 내용을 저장하는 buffer 사이즈를 지정할 수 있다.

    <% page buffer=”12kb” %>

    이 buffer size는 출력 내용을 buffering했다가 출력하는데, 만약에 쓰고자하는 내용이 Buffer size 보다 클 경우에는 여러번에 걸쳐서 socket write가 일어나기 때문에 performance에 영향을 줄 수 있으므로 가능하다면 buffersize를 화면에 뿌리는 내용의 크기를 예측해서 지정해주는것이 바람직하다. 반대로 너무 큰 버퍼를 지정해버리면 메모리가 불필요하게 낭비 될 수 있기 때문에 이점을 주의하기 바란다.

    참고로 jsp page buffer size는 지정해주지 않는경우 default로 8K로 지정된다.

    member variable

    Servlet/JSP는 기본적으로 Multi Thread로 동작하기 때문에, Servlet과 JSP 내에서 선언된 멤버 변수들은 각 Thread간에 공유가 된다.
    그래서 이 변수들을 read/write할경우에는 sychronized method로 구성해야 하는데, 이 synchronized는 속도 저하를 유발할 수 있기 때문에, member 변수로는 read 만 하는 객체를 사용하는게 좋다.

    특히 Servlet이나 JSP에서 Data Base Connection을 멤버 변수로 선언하여 Thread간 공유하는 예가 있는데, 이는 별로 좋지 않은 프로그래밍 방법이고, 이런 형태의 패턴은 Servlet이 단 하나만 실행되거나 하는것과 같은 제약된 조건 아래에서만 사용해야 한다.

    Out of Memory in file upload

    JSP에서 File upload control을 사용하는 경우가 많다. 이 control을 구현하는 과정에서 upload되는 파일 내용을 몽땅 메모리에 저장했다가 업로드가 끝나면 한꺼번에 file에 writing하는 경우가 있는데, 이는 큰 사이즈의 파일을 업로드할때, 파일 사이즈만큼의 메모리 용량을 요구하기 때문에, 자칫하면 Out Of Memory 에러를 발생 시킬 수 있다.
    File upload는 buffer를 만들어서 읽고, 파일에 쓰는 작업을 병행하도록 해야한다.

    3) JDBC Programming

    Connection Leak

    JDBC Programming에서 가장 대표적으로 발생되는 문제가 Connection Leak이다. Database Connection을 사용한후에 close않아서 생기는 문제인데,Exception이 발생하였을때도 반드시 Connection을 close하도록 해줘야한다.


    <그림. Connection close의 올바른 예>


    Out of memory in Big size query result

    SQL문장을 Query하고 나오는 resultset을 사용할때, 모든 resultset의 결과를 Vector나 hashtable등을 이용해서 메모리에 저장해놓는 경우가 있다. 이런 경우에는 평소에는 문제가 없지만, SQL Query의 결과가 10만건이 넘는것과 같은 대용량일때 이 모든 데이타를 메모리 상에 저장할려면 Out Of Memory가 나온다.
    Query의 결과값을 처리할때는 ResultSet을 직접 리턴받아서 사용하는것이 메모리 활용면에서 좀더 바람직하다.

    Close stmt & resultset

    JDBC에서 Resultset이나 Statement 객체는 기본적으로 Connection을 close하게 되면 자동으로 닫히게 된다. 그러나 WAS나 Servlet Container의 경우에는 성능향상을 위해서 Connection Pooling 기법을 이용해서 Connection을 관리하기 때문에 Connection Pooling에서 Connection을 close하는것은 실제로 close하는것이 아니라 Pool에 반환하는 과정이기 때문에 해당 Connection에 연계되어 사용되고 있는 Statement나 ResultSet이 닫히지 않는다.

    Connection Pooling에서 Statement와 ResultSet을 사용후에 닫아주지 않으면 Oracle에서 too many open cursor와 같은 에러가 나오게된다. (Statement는 DB의 Cursor와 mapping이 된다.)

    4) EJB Programming

    When we use EJB?

    EJB는 분명 강력하고 유용한 개발 기술임에는 틀림이 없다. 그러나 EJB의 장점과 용도를 모르고 사용하면 오히려 안쓰는것만 못한 경우가 많다.
    각 EJB 모델 (Session Bean,Entity Bean)이 어떤때 유용한지를 알고 사용하고, 정확한 Transaction Model등을 결정해서 사용해야 한다.

    Reduce JNDI look up

    위에서도 설명했듯이 EJB의 Home Interface를 lookup 해오는 과정은 객체의 Serialization/DeSerialization을 동반하기 때문에, 시스템 성능에 영향을 줄 수 있다. EJB Home을 한번 look up한후에는 Hashtable등에 저장해서 반복해서 Remote Call(Serialization / DeSerialization)하는 것을 줄이는게 좋다.

    Do not use hot deploy in production mode

    WAS Vendor 마다 WAS 운영중에 EJB를 Deploy할 수 있는 HotDeploy 기능을 제공한다. 그러나 이는 J2ee spec에 있는 구현이 아니라 각 vendor마다 개발의 편의성을 위해서 제공하는 기능이다. 운영중에 EJB를 내렸다 올리는것은 위험하다. (Transaction이 수행중이기 때문에) Hot Deploy 기능은 개발중에만 사용하도록 하자.

    5) JVM Memory tuning

    Basic Tuning

    Application을 개발해놓고, 운영환경으로 staging할때 별도의 JVM 튜닝을 하지 않는 경우가 많다. 튜닝이 아니더라도 최소한의 메모리 사이즈와 HotSpot VM 모델 (server/client)는 설정해줘야지 어느정도의 Application의 성능을 보장 받을 수 있다. 최소한 메모리 사이즈와 VM모델정도는 설정을 해주고 운영을 하도록 하자.


    7. 결론


    J2EE Application의 병목구간을 확인하기 위해서는 그 문제를 발견하고 툴과 경험을 이용해서 문제의 원인을 발견하고 제거해야한다.

    대부분의 WAS또는 User Application의 slow down이나 hang up은 Thread dump를 통한 분석을 통해서 대부분 발견 및 해결을 할 수 있다.

    그외에 부분 JVM이나 WebServer,Network 등에 대해서는 별도의 경험과 Log 분석등을 알아내야하고 DB에 의한 slow down이나 hang up현상은 DB 자체의 분석이 필요하다.
    Posted by la30321
    Oracle 관련2005. 6. 8. 15:27

    오라클 Index 정보

    ---------------------------------------------------------------------------

    SELECT index_name, table_owner, table_name, column_name
    FROM dba_ind_columns
    WHERE index_owner = 'KDCORA'
    AND TABLE_NAME = 'SUC010TL'
    ORDER BY index_name, column_position;

    Posted by la30321
    와글와글 잡담2005. 4. 1. 15:24

    사회에 존재하는 이런저런 산업를 크게 둘로 나누어보면 이렇게 나뉜다.

    1. 제로섬 산업. 2. 논제로섬 산업.

    제로섬 사업은 간단히 증권시장을 연상하면 된다. 누군가 웃는다면 누군가는 우는 체제이다. 새로운 부가가치를 생산해 판매하는 산업이 아니라 기존의 부가가치를 운용해 더 많은 부가가치를 자신에게 이동시키는 산업이다. 때문에 이 산업의 종사자는 아무리 돈을 많이 벌어도 국가의 부에는 영향을 주지 않는다. 상자안의 빵이 옮겨다닐뿐 빵 자체를 만들어내지는 못하는 것이다.

    논제로섬 산업은 반대이다. 이 산업의 목표는 새로운 부가가치를 창출하거나 생산해 그것을 판매하여 이익을 보는 것이다. 이 업계 종사자의 부는 곧 국가의 부다. 논제로섬 산업이 발달하면 그것은 곧 국가의 부로 연결된다. 흔히 말하는 IT업계가 바로 이쪽이다. 언론에서 툭하면 '대한민국의 미래는 IT에 있다'라고 하는 것도 다 이런 이유에서이다.

    그런데 생각해 보자. 대한민국에서 우대받는 직업에는 어떤 것이 있을까? 주로 끝에 '사'가 붙는 의사, 약사, 변호사, 판사, 회계사, 변리사 등등은 물론 딜러, 펀드매니저 등의 금융이나 대기업의 간부, 전문직 정도일 것이다. 여기서 찾아보자. 이중에 제로섬 직업은 몇이고 논제로섬 직업은 몇일까?

    대한민국의 일그러진 엘리트 주의에서는 논제로섬 직업은 대우받지 못한다.

    관념적인 말이 아니다. 내 주위의 일이다. 흔히 말하는 그 잘난 일류대의 공학, 과학인들이 과연 얼마나 논제로섬 직업에 종사하고 있을것 같은가? 명색이 대한민국에서 제일 우수한 IT교육을 받은 인재들이 죄다 제로섬 게임에 미쳐(혹은 떠밀려) 아무생각없이 달려가고 있다.

    서울대 공대 나와 대기업에 입사하면 실무로 뭘하는지 아나? 전화받는다. AS부서에서. 대기업 기술개발 관련은 해외파가 아니면 명함도 못내밀고 실무생산은 눈높은 신입사원들이 기피한다. 지금 대한민국 IT가 대단하다 떠들고 있지만 실제 업계 종사자들은 다 안다. 현재의 강세는 대한민국의 지식적 힘이 아닌 해외의 힘이며 대한민국의 자본이 아닌 해외 자본의 이익이다. 그나마도 위험하다는 사실을 말이다.

    알기쉽게 예를 들어보자. 가장 IT스러운 프로그래머의 세계를 까발려본다.

    대한민국 프로그래머중 40 넘어서까지 현역(코딩활동)을 유지하는 사람이 얼마나 될 것 같은가? 거의 제로라 보면 된다. 일반적인 업계에서는 보통 40을 업무의 전성기라고 한다. 경험과 패기와 능력이 조화를 이룬 시기라는 말이다. 그런데 대한민국의 프로그래머들은 모두 40 이전에 어떻게 해서는 발을 빼려 아우성친다. 아니면 해외로 나가든가. 도대체 왜그럴까.

    프로그래머는 전문직이다. 그런데 대우는 단순노무직 대우를 받는다. 하루 10시간 근무, 주 6일출근하는 2년차 프로그래머 연봉이 얼마일것 같나? 업계에 따라 조금씩 다른데 가장 열악하다는 게임업계를 들자면 보통 연봉 2000이 안된다. 1800~2000사이를 넘나든다. 세칭 대기업 생산직 근로자들의 딱 반이다.

    문제는 인센티브다. 실리콘밸리에서는 뛰어난 아이디어와 실력으로 좋은 소프트웨어를 개발해 부자가 된 프로그래머들이 널리고 널렸다. 거기가면 50대 프로그래머들도 발에 채인다. 왜냐고? 부자가 될 기회가 많으니까.

    그런대 한국은 웃기게도 대박이 나오면 그 열매는 경영진들이 다 가져간다. 개발직 중에서는 기획자만이 그 단맛을 볼 뿐, 그래픽이나 프로그래밍 파트는 손가락만 빨고 있어야 한다. 인센티브? 허황된 꿈이다. 한국에서는.

    해외 프로그래머들과 이야기를 해보면 그쪽에서는 이런 한국의 IT문화를 신기하게 여기는 분위기다. 어느 업계에서건, 어느 분야에서건 스타는 있다. 그 스타의 모습을 통해 신입들은 의욕을 다지게 되는데... 생각해보라. 한국에 스타 프로그래머가 있는가? 유일(말 그대로 유일)한 이름이 안철수다. 그러나 그분도 얼마전 부패청산 어쩌고 협의에 맞아 쓴소리를 남기셨다. 얼마나 한스러우시면 그럴까. 명색이 IT강국이라는 대한민국, 그중에서도 가장 IT스러운 프로그램 분야에서 한국은 스타가 없다. 즉 새로 업계에 발을 붙히는 사람들이 꿈을 둘 곳이 없는 것이다. 전문지식과 실력과 막중한 근무는 요구하면서도 그 결과를 돌려주는데는 인색하다. 이것이 바로 현실이다.

    대한민국에서 실제 기술개발하고 코딩하는 사람들중 과연 세칭 일류대 출신이라 하는 사람들은 거의 없다. 대기업 연구소라면 모를까. 그 외는 전멸에 가깝다. 엘리트라 자부하는 사람들은 대부분 '사'자가 붙는 직업이나 대기업으로 가 실무와 관계없는 관리쪽에 들어간다. 물론 학력이 실력과 정비례하는 것은 아니지만 일반적인 기준에 맞추어 생각한다면 참으로 암울한 현실이 아닐 수 없다. 이는 모든 IT 산업의 전반적인 특징이다. 실무진은 업계의 허리다. 그런데 그 허리가 너무나 부실하다는 점이 문제다. 대한민국은 모래위에 남의 돈 빌려 대궐같은 IT집을 지어놓고 '나좀봐라' 떵떵거리는 모습이다. 웃음이 절로 나온다.

    지금이야 몇몇 대기업의 약진이라는 화려한 포장지가 있지만 이것이 과연 얼마나 갈까. 그 대기업의 약진도 따지고 보면 해외의 기술력과 자본에 반이상 종속된 상태이다. 눈가리고 아웅하는 꼴이다. 그런데 어떻게든 경영진과 정치인들은 이것을 자신의 치적으로 삼고자 취약점은 외면한채 과대포장시켜 홍보하기에만 들떠 있다. 더불어 대기업의 횡포도 끝이 없다. 이미 대기업 노조의 밥벌이를 하청업체가 책임진다는 사실은 공공연한 사실이다. 더불어 하청업체의 영업이익이 조금이라도 우수하면 바로 대기업의 감찰단이 들이닥친다는 사실도 안철수님의 인터뷰로 까발려졌다. 중소업체가 대기업에 제안서 하나 넣어볼라치면 전 사원의 학력, 경력등은 기본적으로 첨부해야 한다. 해외에서는 웃기는 비상식이 대한민국에선 상식으로 통한다. 가장 국제화되었다는 IT업계에서 말이다.

    얼마안가 망할 것이다. 거품이 빠지고 그나마 버텨주던 기술개발인들이 못버티고 은퇴하는 순간이 대한민국의 IT가 끝장나는 순간이다. 정부와 기업들도 한몫하기로 했다. 그나마 경쟁력의 근원중 하나이던 인터넷을 종량제로 바꾼다고 하지 않는가. 정보와 이익의 독점이 미덕이라는 제로섬 산업의 마인드가 이제 논제로섬 산업을 뒤흔들고 있다.

    솔직히, 나는 즐겁다. 업계의 인력부족이 심각해지고 질적, 양적인 공백이 심화될수록 나는 즐겁다. 세칭 일류대 공대 나와 동기들과는 달리 돈키호테처럼 벤처로 뛰어들때만 해도 상황이 이럴줄은 상상도 못했으니까. 물론 일하기 시작한 몇개월간은 그 암울함에 어려워했지만 지금 생각해보면 오히려 좋은 기회라고 느껴진다. 의욕이 현실앞에 무너지나 걱정도 했지만 점점 늘어나는 스카웃 제의에 근심은 사라졌다. 어디든 그렇지만 희소성은 늘 각광받기 마련이니까.

    대한민국의 영재들이여, 부디 나를 위해 계속 IT를 기피하고 경영이나 '사'자로 가주시길.

    -----------------------------------------------


    Posted by la30321