반응형
출처: http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=51142

CPU 오버클러킹

 

난이도: 보통

소요시간: 오전 중 10분

 

 

약간의 수고만으로도 시스템의 속도를 10% 이상 증가시킬 수 있다. 대다수의 CPU는 최대 한도보다 낮게 설정된 채로 출고된다. 일부 제품은 종종 속도를 향상시킬 수 있는 방법이 함께 제공되기도 있다.

 

많은 사람들의 우려와 달리 오버클러킹은 PC에 크게 위험하지도 않고 조작하기 어렵지도 않다. 물론 오버클러킹 시 제품 보증서의 효력은 공식적으로 사라지지만 말이다.

 

반면 오버클러킹이 가능한 기성 PC제품들은 흔치 않다. 일단 자신의 PC가 오버클러킹을 지원하는지 확인해 보자. 만약, 여러분의 PC가 오버클러킹을 지원한다면, 수 분 내에 PC의 속도를 개선시킬 수 있다. 참고로 높은 성능 및 안정성을 얻고 싶다면, 오후 시간대는 피하여 테스트해 보는 것이 좋다.

 

오버클러킹을 하기 위해서는 우선 정보를 모아야 한다. 마더보드의 모델을 확인하고, 해당 모델의 매뉴얼을 다운로드 받은 다음 BIOS를 최신 버전으로 업데이트시킨다. 마더보드 제조사가 윈도우용 오버클러킹 유틸리티들을 제공하는 경우도 있지만 가급적 BIOS 내에서 직접 설정내역을 변경하는 것을 권장한다. 이 경우 설정을 재변경하기 전까지 설정내역이 유지된다.

 

다음으로는 BIOS에 액세스 하는 방법 및 업그레이드가 불안정할 경우(애플리케이션이 충돌하거나 시스템이 다운되는 현상 등)를 대비해 이를 디폴트 구성으로 재설정할 수 있는 방법을 파악해야 한다. PC가 부팅되지 않은 경우 재설정을 하기 위해서는 물리적으로 점퍼 스위치를 변경시키거나 마더보드의 버튼을 눌러야만 하는 경우가 있는데, 이를 알아두어야 한다는 이야기다. 그렇지 않으면, 문제 발생시 BIOS 화면으로 돌아가는 길을 찾지 못해 컴퓨터가 잠겨 버리게 된다.

 

아울러, 온라인으로 CPU의 모델을 파악하고 (BIOS에서 이와 관련된 일부 정보들을 찾을 수 있다) 해당 모델이 지원하는 온도를 확인하도록 한다. 오버클러킹이 성공적으로 이루어지기 위해서는 성능과 열을 절충하여 선택해야만 한다. CPU가 너무 뜨거워지면 PC가 충돌을 일으키게 된다. 오버클러킹을 진행하면서 BIOS에서 온도를 체크하도록 한다.

 

때때로 BIOS는 ‘Al’ 모드, 자동 모드를 통해 CPU를 성공적으로 오버클러킹시킬 수도 있다. ‘Al’ 모드를 선택할 수 있다면, 오버클러킹은 한마디로 식은죽 먹기다. 그러나, 대부분의 경우는 버스(FSB) 스피드의 설정을 변경하여 CPU의 속도를 향상시키게 된다. BIOS 내에서 FSB 스피드를 5-MHz나 10-MHz정도 올리고, 변화를 저장한 뒤, 재부팅하는 방식이다.

 

만약 PC가 성공적으로 부팅되지 않는다면, 즉, 윈도우 화면이 나타나지 않는다면, BIOS 화면으로 돌아가 FSB 스피드를 기존의 설정대로 복귀시켜야 한다. 복귀 후 부팅이 성공적으로 이루어진다면, 다시 한 번 FSB 스피드를 조금씩 증가시킨 다음 약 30분간의 Prime95 테스트를 통해 CPU가 제대로 작동하는 지를 확인하도록 한다.

 

Prime95는 오버클럭된 CPU에 부하를 주어 안정적으로 작동하는 지를 확인하는 테스트다. Prime95 테스트에서 시스템이 안정적으로 작동한다면, FSB 스피드를 천천히 조금씩 증가시키는 것을 계속하도록 한다.

 

이 과정 중 성능상의 문제나 충돌이 발견된다면, 혹은 CPU가 너무 뜨거워 진다면, FSB 스피드를 줄여 안정적인 수준을 찾아야 한다. 온도를 낮게 유지하기 위해 CPU의 히트 싱크를 업그레이드하는 것도 좋다. ; 더욱 튼튼한 히트 싱크는 FSB 스피드를 조금 더 올려줄 수 있다.

 

그래픽카드 오버클러킹

 

난이도: 쉬움

소요시간: 60분

 

 

ATI와 엔비디아는 모두 일부 고성능 비디오 카드에 한해 무료 오버클러킹 툴을 제공하고 있다. 이 방법은 BIOS의 설정을 변경하지 않고도 시스템의 그래픽 성능을 향상시켜 준다. 속도가 빨라짐에 따라 게이머들은 더욱 부드러운 비디오 영상을 즐길 수 있을 것이다. 시작하기에 앞서 그래픽 보드의 드라이버를 업그레이드 정도는 해두자.

 

엔비디아의 컨트롤 패널(Control Panel)에서 퍼포먼스(Performance)로 들어가 디바이스(Device) 설정을 클릭한다. GPU를 클릭하고, 커스텀(Custom)을 선택한 뒤, 안정성을 확인해 가면서 슬라이더를 이동시켜 클럭 스피드를 증가시키도록 한다.

 

ATI 카드를 사용하고 있다면, 카탈스트 컨트롤 패널(Catalyst Control Panet)을 열고 오버드라이드(Overdrive)로 들어가 자동조정(Auto-Tune)을 클릭한다. 이 방법은 점진적으로 클럭 스피드를 증가시키면서 연달아서 각 스피드를 테스트한다. 불안정성이 발견되면, 클럭 스피드를 감소시켜 기존 수준으로 복귀시킨다.

 

에너지 절감을 위한 PC 다운클러킹

 

난이도: 쉬움

소요시간: 20분

 

많은 사람들이 무료로 시스템의 속도를 향상시키기를 원하지만, 에너지 절감과 열 차단을 중시하는 사용자라면 하드웨어를 다운클러킹 시키는 것이 더 나은 선택일 수도 있다. 물론, 다운클러킹에 따른 에너지 절감폭은 그리 기대할 만한 수준이 아니지만 말이다.

 

조용한 시스템이 요구되는 홈시어터PC에서도 다운클러킹을 고려해 볼 수 있다. 온도를 낮춰주면서 쿨링팬이 돌아가는 소리가 조용해지기 때문이다.

 

시스템을 다운클러킹시키기 위해서는, 이전 페이지에 위에서 언급한 오버클러킹 조언들을 따르되 CPU의 속도를 증가시키는 것이 아니라 감소시키면 된다. 또 윈도우의 전원 옵션(Power Options) 컨트롤 패널에 들어가 상세 설정을 변경하도록 한다.

 

프로세서 전원관리(Processor power management)를 클릭하고 최저 속도와 최고 속도를 변경해라. 필요시 CPU의 속도를 증가시킬 수 있도록 최저 속도를 5%, 최고 속도를 100%로 설정한다. 만약 이메일 등 기본적인 업무를 위해서만 PC를 사용한다면 최고 속도를 좀 더 낮게 설정하면 된다.

 

안테나 추가로 무선랜 범위 확대

 

난이도: 쉬움

소요시간: 45분

 

 

간단하고 수동적인 파라볼라 반사기(Parabolic Reflector)를 무선 안테나 주변에 설치함으로써 신호를 정확히 원하는 지점에 집중시킬 수 있다. 파라볼릭 반사기는 네트워크의 범위를 넓혀줄 뿐만 아니라 네트워크의 보안까지도 개선시켜줄 수 있다.

 

적합한 안테나 모양을 찾으려면 파라볼라 계산기를 다운로드하는 것이 좋다. 라우터의 안테나가 물리적으로 수용할 수 있는 최대 규모의 반사기의 직경 및 깊이를 입력해라. 파라볼라 계산기는 모눈 종이에 설계도를 그릴 수 있도록 수치표를 산출해 줄 것이다. 두 장의 마분지에서 파라볼라 모양을 잘라낸 다음, 부드러운 금속 조각을 잘라 반사기로 사용하도록 한다. 금속조각을 U자형으로 구부려 유도장치를 둘러싸도록 한 다음 본드로 붙여 고정시킨다. 마지막으로 유도장치의 초점 부분에 작은 구멍을 내고 반사기를 설치한다.

 

무선 라우터에 고급 기능 추가

 

난이도: 보통

소요시간: 45분

 

 

사용하다 보면 무선 네트워크를 확장해야 할 필요성을 느낄 수도 있다. 그러나, 그렇다고 해서 반드시 새로운 네트워킹 하드웨어를 구입할 필요는 없다. 써드파티의 펌웨어를 사용해 기존의 무선 라우터에 새로운 기능을 더함으로써 네트워크의 확장이 가능하다.

 

이 경우, 라우터의 성능을 새 장비를 구입하는 것과 대등하게, 혹은 (많은 경우) 그 이상으로 개선시킬 수 있다. 이 해킹 방법을 통해 사용자들은 안테나의 파워를 증가시키고, 리피터가 더욱 넓은 Wi-Fi 범위를 지원할 수 있다. 또 무선 네트워크의 보안을 개선시키며, Wi-Fi 트래픽을 유선 네트워크에서 분리시키고, VPN을 설치하는 등 많은 긍정적 효과들을 기대할 수 있다.

 

X-Wrt 펌웨어는 아수스, 버팔로, 링크시스를 포함한 많은 라우터를 지원한다. 웹사이트를 방문해 X-Wrt 펌웨어가 각자의 라우터를 지원하는 지 확인하도록 한다. (만약, 라우터가 지원 가능한 라우터 목록에 포함되지 않는다면, 온라인에서 해당 라우터 모델에 대한 펌웨어를 검색해 보자. 여러분의 라우터를 지원하는 유사한 펌웨어가 있을지도 모르기 때문이다.)

 

이더넷 케이블을 사용하여 라우터를 PC에 직접 연결시킨 다음 라우터의 구성 페이지에서 로그인한다. 시스템 설정 메뉴를 열고 펌웨어 옵션을 살펴본다. 버튼을 클릭해 새로운 펌웨어 파일을 선택한 다음, 이를 라우터로 업로드시킨다. 업데이트가 종료되기 전까지는 라우터와 PC를 분리해서는 안 된다. 그렇지 않으면, 하드웨어가 영구적으로 손상될 위험이 있다. 이 과정에는 최대 15분의 시간이 소요된다.

 

업데이트가 종료되고 라우터가 재시작하면, 브라우저를 사용하여 무선 네트워크를 다시 연결한다. 곧 디폴트 화면 대신 X-Wrt 인터페이스가 나타나면서 사용자로 하여금 신규 패스워드를 설정하도록 한다. 이제 무선 인터넷을 재연결할 수 있다. 그러나, 이는 이더넷을 통한 대부분의 관리업무들을 수행하는 데 있어서는 최고의 방법이다.

 

펌웨어 업데이트 메뉴에서 네트워크(Network)로 들어가 무선 설정(Advanced Wireless Settings), 그리고 전력 송신(Transmit Power)을 클릭한 후 송신 전력을 변경해라. 무선 네트워크의 지원 범위를 확대해야 할 경우에는 수치를 높이고, 네트워크가 이웃집까지 흘러가는 것을 막고 싶다면 수치를 낮추면 된다.

 

네트워크 탭 내에 있는 QoS를 이용하여 특정 P2P 프로그램들의 우선 순위를 낮춰 긴급한 업무가 발생할 시 항상 가능한 모든 대역폭을 사용할 수 있도록 디폴트 서비스 품질을 설정하는 것도 가능하다.

 

그래프(Graph) 탭으로 들어가면 사용 대역폭 및 기타 정보들의 실시간 차트를 볼 수 있다. 각 페이지마다 오른쪽 하단에 있는 저장(Save Changes) 버튼을 눌러 변경 내역을 저장하고, 업데이트를 할 준비가 되었다면 적용(Apply Changes) 버튼을 누르는 것을 잊지 마라. 만약, 기본 펌웨어로 복귀하고 싶다면, 라우터 제조사의 웹사이트에서 이를 다운로드한 뒤 시스템에 업로드시키고 페이지를 업그레이드(Upgrade) 하면 된다.

반응형

rath님의 블로그에서 퍼온 글입니다. 하루에 한번씩은 방문하는 블로그인데요..

좋은 글들과 자료들이 많네요.. 그리고 여러가지 문서를 번역하시는 분이시기도 하구요.(Java API등..)

이번에도 좋은 글이 있어 퍼왔습니다. rath님이 번역해서 한글 번역본을 올리셨다는 군요.

아래 링크에..

http://www.markforster.net/autofocus-system/

Autofocus 시간관리 시스템

 

이 시스템에서 무엇을 기대할 수 있나요?

지금부터 말씀드릴 것은 지난 몇주간 이 시스템을 사용하며 느낀 순수한 제 경험에 바탕한 것들로 아래와 같은 것들이 있습니다.

 

엄청나게 올라간 업무 처리량. 일을 훨씬 빨리 처리할 수 있다는 것을 알게 되었습니다. 이것은 저항이나 꾸물거림 같은 것들이 없기 때문인 것 같습니다.

적은 스트레스. 분명 일을 하긴 해야 합니다만, 극복해야할 반발심이나 귀찮은 감정들이 거의 생기지 않습니다. 사실 모든 일들이 즐거운 것이 되었지요. 제가 이 시스템을 믿는 것을 배우면 배울수록 더 즐거운 것이 되었습니다.

중요한 것에 집중하기. 한 사람의 이성적인 마음만으로는 중요한 것에 집중하기가 대단히 어렵습니다. 왜냐하면 자의식이 중요하다고 생각한 것과 무의식이 중요하다고 생각한 것은 다를 수 있기 때문입니다. 여기서 제가 발견한 것은 제가 끝낸 일들을 뒤돌아 보며 시스템이 집중하라고 한 것들이 ‘옳았다’고 느껴진 것입니다.

잡일들의 매우 빠른 처리. 하지 않으면 안되는 다양한 기계적인 일들을 처리하는 속도가 기하급수적으로 빨라졌습니다. 제가 생각하는 잡일의 종류는 이메일에 답장하기, 블로그 코멘트에 응답해주기, 회신 전화걸기 등입니다. 

중요한 일과 프로젝트들의 철저한 처리. 이 시스템은 중요한 일들에 대해 ‘조금씩 자주’ 접근하는 것을 장려합니다. 그 결과 이 방법론에 의해 프로젝트는 (이 시스템을 사용해보는 것과 같은) 일정 주기를 가지고 처리하는 것이 된다는 겁니다. 이 ‘조금씩 자주’ 접근법의 또 하나의 이점은 한 작업에 주기적으로 관심을 쏟게 해서 아이디어나 통찰들이 자연스럽게 떠오른다는 것이지요.

 

Quick Start

이 시스템은 줄쳐진 노트(한 페이지에 25~35줄 정도라 이상적입니다)에 해야할 모든 일들을 적은 긴 목록으로 이루어져 있습니다. 새로운 할 일이 생각났으면 목록의 맨 끝에 추가하세요. 다음과 같이 한번에 한 페이지에서만 일하게 됩니다.

  1. 해당 페이지의 모든 할 일들을 빠르게 읽어본다. 읽기만 하고 어떤 추가 행동도 하면 안된다.
  2. 하고 싶은 일이 떠오를 때까지 그 페이지의 할 일들을 천천히 다시 읽어본다.
  3. 그 할 일을 하고 싶은 기분이 지속되는 한 계속 한다.
  4. 목록에서 그 할 일에 줄을 긋는다. 만약 그 일을 다 끝내지 못했다면 목록의 맨 끝에 다시 넣는다.
  5. 같은 방법으로 그 페이지 내에서 계속 반복한다. 어느 일도 하고 싶지 않을 경우를 제외한다면, 그 페이지의 모든 일을 끝내기 전까지 다음 페이지로 가면 안된다.
  6. 다음 페이지로 이동하여 이 과정을 반복한다.
  7. 만약 페이지를 넘겼는데 떠오른 일이 하나도 없다면, 목록의 맨 끝에 넣는 작업없이 그 페이지의 모든 일들을 취소한다. (이 규칙은 마지막 페이지에는 적용되지 않는다. 마지막 페이지는 아이템을 계속 추가할 것이기 때문이다.) 취소한 아이템들을 표시할 때는 형광편을 쓴다.
  8. 마지막 페이지까지 다 끝냈으면 아직 끝내지 못한 일이 있는 첫 페이지로 가서 다시 시작한다.

아래에서는 각 단계들을 더 자세히 설명할 것이긴 합니다만 지금 바로 일하러 가고 나머지를 읽어보는 것은 나중에 하기를 제안합니다. “설명서 마저 읽어보기”를 할 일로 넣어두는 것을 잊지 마세요. 물론 처음부터 수많은 할 일 목록을 구성할 필요는 없습니다. 그저 생각난 것을 할 일 목록에 추가하면 언젠가 당신 앞에 나타날 것입니다.

 

자세한 사용법

 

새로운 할 일이 생각나면 목록의 끝에 추가한다.

이 시스템의 특성 중 하나는 여러분은 어떤 할 일도 없애버릴 수 있다는 것입니다. 생각난 모든 것들을 목록에 넣을지 말지 평가하지 말고 일단 목록에 넣는 것을 권장합니다. 평가는 시스템이 해줄 것입니다.

 

해당 페이지의 모든 할 일들을 빠르게 읽어본다. 읽기만 하고 어떤 추가 행동도 하면 안된다.

페이지를 빨리 훑어보는 것은 당신의 마음에 어떤 압박도없이 일을 시작하도록 해줍니다.

 

하고 싶은 일이 떠오를 때까지 그 페이지의 할 일들을 천천히 다시 읽어본다.

이것이 이 시스템의 핵심입니다. 마음속으로 할 일의 우선순위를 매기려들지 마세요. 그러면 이성적인 마음과 직관적인 마음 사이의 균형이 흔들릴 것입니다. 대신 하나의 일을 하고 싶은 기분이 들 때까지 기다리세요. 이러한 과정은 설명하기는 힘들지만 인지하기는 쉽습니다. 당신은 그저 어떤 일이 완료될 준비가 된 것이라고 느낄 것입니다. 페이지 아래쪽으로 내려가다보면 어떤 일이 당신의 마음을 빼앗아 버려서 다시 올려다보게 하는 것을 느낄 수 있습니다. 어떤 일에 대한 감정이 생기고 나면 일을 함에 있어 느껴지는 모든 저항감들이 사라지고 그저 하기 쉬운 일이 됩니다. 

 

그 할 일을 하고 싶은 기분이 지속되는 한 계속 한다.

더이상 그 일을 계속 하는 것이 옳다고 느껴지지 않는다면 절대 자기 자신에게 그 일을 계속하도록 강제하지 마세요. 이 시스템은 ‘조금씩 자주’ 접근법을 장려합니다. 할만큼 했다는 기분이 들면 그만하세요.

 

목록에서 그 일에 줄을 긋는다. 만약 그 일을 다 끝내지 못했다면 목록의 맨 끝에 다시 넣는다.

사실 목록의 맨 끝에 먼저 넣고나서 줄을 긋는 것이 더 좋습니다. 그래야 어디까지 진행했는지 잊을 확률이 적기 때문이지요. 하지만 저는 이런 순서를 잘 기억하지 못한다는 것을 인정할 수밖에 없군요. 아이템을 다시 넣는 것은 이 시스템의 필수적인 부분입니다. 여러분은 주기적으로 처리해야 하는 일들을 끝냈을 때마다 아이템을 맨 끝에 다시 넣어야 합니다. (이메일, 문서 작업, 운동하기 같은) 아직 완성되지 않은 것들도 모두 넣어야 하고요 (기사나 레포트의 초안같은), 체크할 필요가 있는 모든 일들도 넣어야 하며, (마이크가 이메일에 응답을 했었나? 같은) 책이나 잡지, 저널을 읽는 것처럼 시간이 오래 걸리는 작업들도 넣어야 합니다. 바로 이어서 할 일들이나 추적해야할 아이템들도 넣을 수 있습니다. 제 경우 일들의 대략 1/3 정도가 다시 넣어야 되는 작업들이였습니다.

 

같은 방법으로 그 페이지 내에서 계속 반복한다. 어느 일도 하고 싶지 않을 경우를 제외한다면, 그 페이지의 모든 일을 끝내기 전까지 다음 페이지로 가면 안된다.

각 페이지를 하나의 단위(unit)로 간주하는 것은 당신이 ‘구조화된 꾸물거림’의 이점을 얻을 수 있게 해줍니다. ‘구조화된 꾸물거림’이란 것은 꾸물거림이 상대적이다라는 사실에 근거한 것입니다. 말하자면 어떤 일을 하는 것과 더 어려운 다른 일을 하는 것 사이에 하나의 선택 밖에 없다면 그 무엇도 쉬운 것이 된다는 것이지요.

 

다음 페이지로 이동하여 이 과정을 반복한다.

여러분은 한 페이지를 아주 빠르게 훑어볼 수도 있고 일을 어떻게 할 것인지 충분히 생각해볼 수도 있습니다. 어떤 방법을 사용해도 상관없습니다. 그저 그 방법이 당신을 ‘떠오름’의 방법으로 안내해주기만 한다면요.

 

만약 페이지를 넘겼는데 떠오른 일이 하나도 없다면, 목록의 맨 끝에 넣는 작업없이 그 페이지의 모든 일들을 취소한다. 취소한 아이템들을 표시할 때는 형광편을 쓴다.

시스템에 어떠한 평가 과정도 거치지 않고 집어넣은 모든 아이템들을 어디서 없애버릴지에 대한 것입니다. 여기서 평가라는 것은 시스템이 일들을 분류하고 원하는 것을 찾는다는 것이지요. 이것은 아주 빠르게 처리할 수도 있습니다만 (예를들면 읽어야겠다고 생각한 책들의 긴 목록을 집어넣었다거나) 다소 천천히 하는 것이 좋습니다.

이 아이템들을 다시 집어 넣지 않아야 한다는 규칙을 심도있게 받아들여주세요. 결코 이 아이템들을 다시 집어 넣으면 안된다는 얘기를 하는 것이 아닙니다만 그렇게 하기 전에 충분한 시간을 쓰는 것이 좋고 그 일들이 왜 없어져야 하는지, 정말 끝내야 될 필요가 있는 것인지, 완료되기 위해 아직 시간이 더 필요한 것인지, 주 목표를 방해하는 것들인지 등에 대해 조심스럽게 고민해보라는 것입니다. 취소된 일을 없애버리거나 그 일을 나타내는 말을 여러가지 다른 방법으로 재표현해볼 수 있는 최상의 시간은 그 일을 다시 넣으려고 할 때 입니다.

취소된 아이템들을 형광펜으로 칠해두는 것은 이것들을 리뷰하기 쉽게 만들어줍니다.

이 규칙은 할 일을 계속 적어나가고 있는 페이지에는 적용되지 않는다는 것을 꼭 기억하세요. (맨 마지막 페이지)

 

마지막 페이지까지 다 끝냈으면 아직 끝내지 못한 일이 있는 첫 페이지로 가서 다시 시작한다.

저는 더이상 할 일이 없는 페이지의 상단 구석에 표시를 해둡니다. 그리고 이전 페이지까지 끝내지 못한 일이 하나도 없는 페이지라면 줄 친 곳 주변에 원을 그려 넣습니다. 이렇게 하면 활성화된 일이 있는 첫번째 페이지를 쉽게 찾을 수 있습니다. 그리고 시간이 흘러감에 따라 첫 활성화 페이지가 몇 개인지 여러가지 방법으로 둘러볼 수 있을 것 입니다. 제가 이 글을 쓰는 시점에서는 9개의 페이지가 있었지만 그것은 3~4페이지에서 15페이지까지 다양했습니다.

제 경험에 의하면 이 시스템은 중독성이 꽤 강합니다. 그러므로 당신은 하루에 일하는 시간을 정확하게 정해두는 것이 필요하다는 것을 알아낼 수 있을 겁니다. 시간이 다 되면 일하기를 그만두세요, 그리고 일을 시작할 때가 됐을때만 동일한 위치에서 다시 시작하세요. 솔직히 이 조언을 제 자신도 잘 못지키고 있음을 인정해야겠네요.

 


밀린 작업들

이 시스템을 도입할 때에도 밀린 작업들이 있을 것 입니다. 잔여작업들이 남아있다면 저는 그 모든 일들을 시스템에 한번에 넣고 시스템에 알아서 감별하도록 둘 것을 추천해드립니다. 만약 그 중 일부분을 취소하는 것이 더 좋겠다고 생각했다면 이 일들이 정말 필요한 것인지 스스로에게 심각하게 질문을 던지는 과정을 거쳐야 합니다.

아무튼 아직 처리하지 못한 이메일이나 문서 업무들이 상당히 많다면 이것을 시스템에 넣는 것은 위험합니다. 왜냐하면 새로 도착한 이메일이나 문서 작업들의 업무 효율이 떨어질 수 있기 때문이지요. 그래서 저는 잔여작업들을 위한 별도의 폴더를 만들어서 그 폴더들에게 “밀린 이메일들”, “밀린 문서 작업들”로 이름을 지으시고 “깨끗한 이메일들”, “깨끗한 문서 작업들” 로 이름을 지으시길 추천해드립니다.

 

이것이 왜 동작하는가

이 시스템은 뇌의 이성적인 부분과 직관적인 부분 사이의 균형을 맞춰주는 틀을 제공해줍니다.

만약 우리가 이성적인 뇌만 가지고 살아가려고 한다면, 우리의 계획을 우리들의 마음이 망쳐버릴 확률이 높습니다. 왜냐하면 우리들의 마음은 이성적인 기반으로만 동작하는 것이 아니기 때문이지요. 우리들 대부분은 (이성적인 뇌가) 확실한 것이 제공되기를 좋아하지만 그럼에도 불구하고 우리의 자연스러운 성향은 그것들을 거부하려고 한다는 것을 경험을 통해 알고 있습니다.

반면에 우리가 자연스러운 성향만을 따라가며 살려고 한다면, 추진력에 휩쓸리고 충동적이 되고 분별없이 행동하게 됩니다. 

어쨌든 이 두가지 사고방식이 균형을 이룰 때, 우리의 느낌과 감정이 충분히 조화를 이룬 상태의 합리적인 결정을 내릴 수 있습니다. Autofocus 시스템이 이것을 가능하게 해주는 틀을 제공하는 것이고요. 비록 제가 ‘시스템’이라는 단어를 사용했지만 제가 정말 말하고자 하는 것은 이 시스템은 스트레스를 받지 않고도 균형잡힌 결정을 할 수 있게 도와주는 틀을 제공한다는 것입니다.

 

해야하는 것과 하지 말아야 할 것들

  • 이 시스템을 신뢰하세요. 잘 구조화된 이 방법은 당신에게 도움없이 일을 하는 것보다 더 나은 결정을 내릴 수 있게 도와줄 것입니다.
  • 상식을 사용하세요. 만약 어떤 일을 지금 당장 해야될 필요가 있다고 생각되면 그 일을 바로 하세요.
  • 시스템에 작업을 넣기 전에 수정하려고 하지 마세요. 그렇게 한다면 시스템보다 비효율적인 우선순위 선별방법을 사용하게 될 것입니다.
  • 각 일들이 다른 주기를 가지고 움직일거라고 기대하세요. 어떤 일을 빠르게 움직이고 어떤 것을 느리게 움직이고 어떤 일은 일정 시간동안 멈춰있을 것이고 어떤 일은 완전히 거절될 것입니다. 일들이 어떻게 가정될 수 있는지를 보여줍니다.
  • 특정 날짜나 시간까지 끝내야하는 일은 이 시스템에 넣지 마세요. 식사 준비하기, 음악 연습, 가게 문 닫기와 같은 것들이 포함됩니다.
  • 작업 하나를 끝내고 페이지로 돌아갔을 때, 아직 떠오르지 않은 모든 아이템들을 다시 읽어보세요. 무엇을 끝내야 하는지에 대한 전체적인 모습을 되돌아 볼 수 있도록 도와줄 것입니다.
  • 추적해야할 일(follow-up)이나 까먹지 않아야할 것(reminder)들도 시스템에 넣는 것을 잊지 마세요. 이것들은 작업의 흐름을 놓치지 않기 위한 필수적인 방법입니다.
  • “~에 대해서 생각하기”, “~ 연구하기”, “~ 토론하기”, “~ 리뷰하기” 같은 창의적인 일들도 넣어두세요.
  • 각 날마다 첫번째 할 일에게 날짜를 적어두세요. 시스템에 필수적인 것은 아니지만 진행 상황을 보는데 도움이 됩니다.
  • 기록한 아이디어들과 여러분 마음속에 들어온 작업들의 의미들을 목록에 적지 않은 상태로 내버려두지 마세요.
  • 미래에 완료될 수 있다고 공표한 작업들의 의미를 사용하세요. (수첩, Outlook reminders, Calendar 등)
  • 각 장소마다 다른 공책을 사용하세요. 집, 작업실 처럼요.

반응형


뇌운동 방법입니다.

아래 참고하시고 건강한 뇌 되세요!!

 

1. 아침 밥을 꼭 먹도록 해라

 뇌는 에너지를 저장하는 곳이 없고, 포도당의 농도가 맞지 않으면 급격하게 움직임이 떨어지고 포도당이 흡수되지 않으면 이내 사멸해 버린다. 2~3일 굶으면 혈중의 당이 제일 먼저 뇌로 공급되도록 되는 것을 보아 뇌가 가장 중요함을 몸도 알고 있다는 것이다. 입으로 씹는 행위는 움직이는 근육운동으로 인해 뇌를 자극하여 더욱 활성화시키게 된다. 단기 기억을 요하는 행동을 하기 전에 껌이나 무엇을 씹으면 그 기억능력이 향상된다는 말도 같은 이유인 것 같다.


2. 어디서나 숫자를 세고, 계산한다.

 뇌는 숫자를 매우 좋아한다고 할 정도로 숫자를 셀 때 뇌의 많은 부위가 적극적으로 활성화되는 것을 볼 수 있다. 심심할 때, 목욕탕에 들어가 있을 때 1~100까지 센다거나 바로 앞에 보이는 차의 번호판을 더하거나 곱하여 계산하면서 뇌를 활성화할 수 있다.


더욱이 단순히 숫자를 세는 것이 아니라 걸음을 걸으며 그 걸음을 숫자로 소리 내어 세면서 지나치는 지점의 숫자가 무엇이었는지 기억하는 것을 일정한 게임으로 하면 다양한 기능을 담당하는 뇌의 각 부분이 활성화됨을 알 수 있다.


※단순한 숫자를 단시간 집중해서 계산할 때는 좌우의 전두엽이 점점 활성화되지만 익숙하지 않은 복잡한 계산 문제를 풀 때는 좌뇌만 움직이고 우뇌는 움직임이 별로 없다.

특히 이 책 전체에서는 단순한 숫자를 계산하는 것을 매우 중요하게 언급하고 반복하고 있다. 특히 창의력을 위해서는 숫자와 문장의 낭독 등 말을 하는 것을 중요하게 여긴다. 이는 실험결과 창의력을 발휘할 때 움직이는 뇌의 영역이 읽기와 계산을 할 때 활성화됨을 알았기 때문이다. 


3. 정기적으로 눈에 보이는 문장을 낭독하거나 묵독한다.

 글씨를 읽는 것 만으로도, 사물을 볼 때나, 숫자 또는 그림의 의미를 해석할 때, 언어의 의미를 해석할 때, 소리를 듣고 해석할 때는 특히 뇌의 많은 부분이 활발하게 움직인다고 한다. 그래서 낭독을 하거나, 예전의 천자문을 암송하며 공부하는 것은 뇌를 활성화하는 좋은 예라고할 수 있다. 단지 단 5분을 하더라도 정기적으로 하는 것이 중요하지만 이것이 어려운 일이 아닌가 싶다.


4. 사람의 얼굴이나 현재의 표정으로 유추해 보라
사람의 얼굴을 유심히 보는 것만으로도 사물을 볼 때 움직이는 뇌의 부분이 활성화된다. 하지만 이를 기준으로 ‘연상’을 하게 되면 뇌의 여러 영역이 동시에 활성화 됨을 알 수 있다. 사람의 얼굴 표정을 보고 그 사람의 기분과 이전의 스토리를 상상한다거나 사람의 얼굴을 보고 그 사람에 맞는 옷이나 속옷을 상상하는 등을 예로 들 수 있다. 이런 것은 많은 놀이와 축제에서 행해지고 있는 일이다.
 

5. 오른손 잡이는 왼손을 사용하면 좌우 뇌가 동시에 활성화 한다.
 오른손 잡이가 오른손을 사용하면 왼쪽 뇌가 활성화되지만 오른손 잡이가 잘 쓰지 않는 왼손을 사용하게 되면 명령에 익숙하지 않은 우뇌가 익숙한 좌뇌의 도움을 받아 움직인다. 그렇기 때문에 잘 사용하지 않는 쪽의 손이나 육체의 움직임을 활성화 시키는 것이 뇌 전체를 활성화하는데 좋은 방법이 될 수 있다.
 

6. 집중력은 뇌활동의 효율성을 극도로 높인다.
 집중력이 창의력과 무슨 관계인가? 뇌는 두 가지를 동시에 하면 혼란스러워 한다. 손가락으로 주머니 안의 동전을 만져 촉감만으로 동전의 앞뒤를 구분하는데 집중하다 보면 <사물의 감촉을 판별하는 체성감각야>와 <물체의 위치와 방향을 알아내는 두정연합야>를 단련시키지만 후두엽의 <사물을 바라볼 때 작용하는 시각야>와 측두엽의 <사물의 정체를 파악하는 하측두회>의 활동이 감소한다. 뇌는 하나에 집중하게 되면 다른 영역의 활동을 억제하는 경향이 있어 감촉에 집중하기 위해서 시각으로 들어오는 정보를 막기 위해 눈을 감는 활동을 하게 된다. 한편으로 억제한다는 말은 한편으로 한 쪽의 효율성을 극대화한다는 말이다.
 

여기에서는 집중의 조건을 뇌 활동의 효율성으로 이야기하지만 창의력에서는 집중할 수 있는 능력을 중요한 창의력 발전의 중요한 전제 조건으로 이야기 하곤 한다. 하기야 뇌 기능이 저하되면 제일 먼저 집중력이 없어지고 감정을 억제하지 못하는 현상이 나타나는 것을 보면 집중력은 뇌가 정상적이고 효율적으로 작동되고 있다는 증거가 되기도 하니까 맞는 말인 것 같다.
 

7. 해야할 일의 우선순위를 정하는 것은 뇌를 활성화 한다.
 일의 우선순위를 정하고 이를 처리하는 이미지를 그려보는 것만으로도 뇌를 활성화할 뿐만 아니라 일을 체계적이고 빠르게 수행할 수 있다. 뿐만 아니라 일의 우선순위를 정하는 것 자체는 자신의 가치관을 기준으로 우선순위를 따져 복잡한 상황에 규칙성을 부여하여 이를 순서대로 나열하다 보면 전두엽의 활성화가 일어난다.
<그렇기 때문에 가족 주간회의를 통해 자신의 주간 일정을 정해서 발표하는 활동을 통해 뇌를 다각적으로 활성화할 수 있다. 이는 사람들의 표정과 시선을 함께하면서 사람들의 의사, 감정, 사고를 고려하면서 내용을 전달하는 커뮤니케이션은 전두엽의 활동을 또한 촉진하기 때문이다>
 
 
 
8. 오늘 만난 사람의 이름을 기억하려고 한다.
뇌는 기억하려고 할 때 활성화된다. 사람의 뇌는 단순히 생각을 떠 올리는 것 보다는 기억하려고 할 때 뇌(전두전야)가 본격적으로 움직이기 시작한다. 단순히 떠 올리는 것이 아니라 기억하려고 시작할 때 기억이 정착된다는 말이다. 사람의 이름을 부르면 청각과 더불어 시각을 담당하는 뇌가 활성화된다. 그기에 기억하려는 의도의 시작은 기억과 관련된 뇌을 움직이게 하기 때문에 휠씬 더 잘 기억하게 된다.

기억력이 좋다는 말은 기억과 연관된 것이 맡아 쉽게 의식으로 꺼집어 올린다는 말이다.
기억력을 좋게 하기 위해서는 뇌에 기록된 정보의 연관된 체인이 많다는 것이다. 연관된 체인이 많게 기억하고 있으면 이를 쉽게 꺼집어 낼 수 있다는 것이고 이를 두고 기억력이 좋다는 것이다. 결국 뇌에 연관된 체인이 많도록 훈련되어 있으면 의식의 얕은 곳까지 걸려들기 쉬운 곳까지 기억이 올라와 쉽게 꺼집어 낼 수 있도록 되어 있다는 것이다. 쓰면 쓸수록 그 능력이 향상되는 뇌에 지속적으로 연관된 체인을 만들기 위해서 궁리해야 한다는 것이다.

자기 전에는 정신을 평화롭고 자유롭게 하라는 사람도 있지만 나의 경우는 잠자리에 누워서 오늘 만난 사람들을 순서대로 만나서 나눈 이야기의 이슈를 기억해 본다. 그것이 완료되면 마음은 한결 편해진다. 그러면 그런 종료의 기분 때문에 그런지 잠이 잘 오기도 한다.
 
9. 매일 새로운 패턴의 운용으로 뇌를 새롭게 자극준다.
 창의력을 연구하다 보면 뇌는 같은 것, 패턴화되는 것을 싫어한다는 이야기를 많이 듣는다. 같은 작업만 반복하고 패턴화되어 있으면 뇌의 기능은 저하된다. 뇌에 가장 좋지 않은 행동은 같은 행동을 반복하는 것이다. 왜냐하면 뇌만큼 실증을 잘 내고 새로운 자극을 좋은하는 존재도 없기 때문이다. 그래서 매일 새로운 점심 메뉴를 찾거나 출퇴근 시간, 교통수단, 노선의 변경은 그 만큼 뇌에 새로운을 줄 수 있는 뇌를 활성화시키는 일상 패턴이자 좋은 방법이 된다.
 

10. 완성을 연상하며 조립하거나 그리거나 자르는 즐거운 놀이를 만든다
아직 완성되지 않은 상태에서 결과를 연상하면서 만드는 종이 접기나 그림 그리기, 조각, 요리, 무늬 오리기는 뇌(전두전야)를 활성활 할 뿐만 아니라 창의력과 집중력을 증강시킨다. 이런 것을 할 때 마음을 담은 동기가 있어 즐기는 것은 뚜렷한 목표와 기준이 있기 때문에  뇌의 활성화를 더욱 촉진시킨다. 그렇지 않은 상태에서 뇌는 전혀 다르게 움직이기 때문이다.
 

11. 눈에 띄는 사물의 명칭으로 동사형을 연상해 본다.
창의력을 할 때도 흔하게 언급되는 것이지만 특정 주제나 단어를 던지고 관련된 말이나 언어, 이미지를 쓰라고 하면 당장 몇 개도 연상해 내기 어렵다. 연상은 뇌의 활동을 촉진하는 좋은 방법이다. 이 말은 뇌의 혈류 속도를 원활하게 자극한다는 말이다. 또한 뇌에 기록된 정보들간의 연관된 체인을 많이 만들어 더 많이 기억하고 쉽게 기억을 꺼집어 올릴 수 있는 조건을 만든다는 말이다. 연필=> 깍다. 부러지다. 굴러가다, 쓰다..../ 개=>짖다, 물다, 먹다, 꼬리치다...이를 소리를 내어 이야기하면 다각적으로 뇌를 활성화할 뿐만 아니라 창의력도 높아진다. 또는 연속된 그림을 제시하고 그 다음은 어떤 그림이 나올지를 연상하거나 / 특정 사건에 대한 변신 로봇이 무엇으로 변신할 지에 대한 연상활동이 좋은 훈련방법이 될 수 있다.
 

12. 뇌를 많이 사용했을 때 TV시청으로 쉬게 한다.
뇌의 건강 차원에서 혹사당한 뇌를 쉬게하고 다시 활동하도록 하면 더욱 활발하게 뇌를 활용할 수 있다. 이때 뇌를 쉬게 하는 방법으로 TV를 시청하면 좋다. 실험을 통해 TV를 시청할 때는 뇌(전두전야)의 혈류 속도가 떨어지는데 이는 가만히 눈을 감고 아무것도 하지 않을 때 보다 더 둔해지고 활동을 멈춘다는 것이다. 이런 사실은 개인적으로 매우 놀라운 사실인데 TV를 너무 많이 봐서 머리가 항상 멍하고 순발력이 늦은 것은 아닌지 의심 스럽다.
 

13. 좋아하는 시, 영화나 드라마 대사을 주기적으로 낭송한다.
 소리내어 낭송한다는 것은 비단 그 뜻을 몰라도 간단한 계산을 빠르게 하는 것만큼이나 뇌의 많은 영역을 동시에 활성화 시켜 준다. 반복적이고 꾸준한 낭독은 직접적으로 관련이 없는 기억력까지도 향상시킨다는 것을 실험을 통해 확인할 수 있었다고 한다. 나의 경우에는 내가 좋아하는 영화나 드라마의 대사를 암기하면 좋겠다 싶다. 대사를 암기하는 훈련과 낭독을 하며 그 장면을 동시에 연상하면서 이어 나의 일상과 연관지어 생각해 볼 수 있기 때문이다. 

반응형
가입절차 필요없이 파일 변환이 가능합니다.
 JPG, PNG, BMP, GIF  -> ICO

사용자 삽입 이미지

http://ico.bradleygill.com/advanced.php 

반응형

 출처 : http://www.thinkmania.com/zb40/zboard.php?id=ibmboard2&page=2&sn1=&divpage=17&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=96474

[펌] PC를 이용한 방범 CCTV 설치하는 방법 아시는 분!

(1)
음.. 간단하게 말씀드리자면...
DVR 카드 구매하셔서 연결하시면 됩니다.. 카메라는 적외선 카메라....대략 15만원정도?
DVR카드는 한 10만원정도... 케이블값은 3~4만원선?
대략 30만원선에서 끝내실수있습니다...
IP CCTV는.. 30~45만원 정도 하던데... 비싸죠;;; 뭐 물론 번거러움이 줄어들겠지만요 ㅎㅎ

(2)
http://bloggernews.media.daum.net/news/964189

(3)
알파캠m2 사서 딸려오는 s/w 워치아이 쓰면 움직임이 있을때만 사진찍게 할 수도 있습니다. 아주 좋아여..

(3) 상세

무료로 집 안의 컴퓨터와 웹캠을 이용, 집 안에 CCTV설치하는 방법을 알려드립니다.


1) 컴퓨터 본체의 잠자기 기능을 모두 해제해야합니다. 컴퓨터가 잠들기에 들어가면 원격제어가 불가능하기 때문이죠.

2) 컴퓨터 본체에 데이콤의 '네트로'라는 프로그램을 설치합니다.
이것은 외부 컴퓨터로 집 안의 컴퓨터를 원격 제어하기 위한 프로그램입니다.
외출 시 '네트로' 바로가기 화일을 클릭해주면 됩니다.

3) 집 안의 컴퓨터에 웹캠을 설치합니다. 웹캠은 비싸지 않으니깐 괜찮은 제품으로 아무거나 하나 구입해서 USB로 컴퓨터와 연결합니다. 마이크까지 연결하면 집 안의 소리도 들을 수 있습니다. 또 웹캠을 컴퓨터가 없는 곳에 설치하려면 USB선이  길어야하니 거리에 맞추어 USB연장선을 구입합니다.

4) 네이트메신저나 MSN메신저처럼 화상대화가 가능한 메신저를 설치합니다.
그리고 아이디를 2개 만듭니다.

5) 외출시 집 컴퓨터 본체를 켜고, 네트로를 실행시킨 다음, 메신저도 구동시킵니다.
물론 웹캠은 메신저와 문제없이 연동됨을 꼭 확인해야합니다. 모니터는 꺼도 됩니다.

6) 회사에서 네트로 사이트에 접속하면 바로 왼쪽 상단에 집의 컴퓨터 이름이 떠 있습니다. 그것을 클릭하면 직접 회사 컴퓨터로 집 안의 컴퓨터 데스크탑 화면을 볼 수 있게 됩니다. 그 다음 회사 컴퓨터의 메신저에서 집의 메신저에 화상대화를 신청합니다.
그리고 네트로를 이용, 집의 컴퓨터에서 화상채팅 승인을 해주면 회사 컴퓨터의 메신저로 집 안의 모습과 소리를 실시간으로 감시할 수 있습니다.

7) 음, 저는 이 방법으로 화면 녹화까지는 안해봤는데요, 만약 녹화도 하고 싶다면 메신저보다는 웹캠에 같이 딸려오는 녹화 전용 프로그램을 이용하는 것이 좋지 않을까 싶네요.(메신저에 녹화 기능이 없을 듯)  '네트로'를 이용하면 외부에서도 집안의 컴퓨터를 원격 제어할 수 있으니 직접 회사에서 이런 녹화프로그램을 구동시켜서 집 안의 컴퓨터에 녹화 데이타를 저장시킬 수도 있습니다. ^^

반응형

HP 노트북 PC - HP Pavilion 및 Compaq Presario PC에서 Windows XP로의 다운그레이드 및 Windows Vista 복원과 관련된 문제

Vista에서 XP로 다운그레이드할 경우 경험하는 문제

PC에 변경을 가하기 전에 해야 할 일

OS를 변경한 후 PC가 제대로 작동하지 않는 경우 해야 할 일

Windows XP에서 Vista로 업그레이드한 후 XP로 되돌리려는 경우 해야 할 일

이중 부팅 시스템을 사용하지 말아야 하는 이유

이 문서는 Windows Vista가 기본으로 제공된 HP Pavilion 및 Compaq Presario 노트북 PC에 적용됩니다.

이 문서는 비즈니스 노트북 및 데스크탑 PC에는 적용되지 않습니다. 비즈니스 노트북 모델을 선택하십시오. 2510p, 2710p, 6910p, 8510p, 8710p, 6510b, 6515b, 6710b, 6715b 및 기타 모델들은 Windows XP를 지원합니다.

Vista에서 XP로 다운그레이드할 경우 경험하는 문제

HP Pavilion 및 Compaq Presario 컨슈머용 노트북 PC에 Windows Vista가 기본으로 제공된 경우, Windows XP로 다운그레이드를 시도하지 마십시오. 운영 체제를 변경하면 심각한 운영 문제를 일으킬 수 있습니다. 사운드, 비디오, 그래픽, 네트워트 연결 장치, 드라이브 또는 기타 장치 및 주변기기 등의 구성 요소가 제한된 기능을 갖거나 전혀 작동하지 않을 수 있습니다. 운영 체제 변경을 고려하기 전에 하드웨어 및 소프트웨어 제조업체의 지원 정책을 조사하고 다른 사용자들이 경험한 문제들을 살펴 보십시오.

Vista용으로 설계된 HP Pavilion 및 Compaq Presario 컨슈머용 노트북 PC를 구형 운영 체제로 다운그레이드할 경우 다음과 같은 문제들을 경험할 수 있습니다.

  • HP는 이러한 컨슈머용 노트북에 사운드, 비디오, 그래픽, 네트워크 연결 장치, 드라이브 또는 기타 장치 및 주변기기 등을 구동할 수 있는 Windows XP 호환 드라이버를 제공하지 않습니다.

  • 운영 체제를 변경하면 시스템에 Windows Vista를 복원할 때까지 보증을 받을 수 없습니다. HP 기술 지원에서는 전화 또는 온라인 지원을 제공하거나 하드웨어 서비스를 수행하기 전에, 컴퓨터에 원래 제공된 Windows 운영 체제 버전을 다시 설치할 것을 요청합니다.

  • 일부 부품 제조업체는 Windows Vista용으로 설계된 부품에 Windows XP 호환 드라이버를 제공하지 않습니다.

  • 타사 또는 Windows 자체에서 모든 장치를 작동시킬 수 있는 일반 드라이버를 제공할 수 있더라도 HP PC의 성능이 최적화되지 않을 수 있습니다.

알려진 하드웨어 및 소프트웨어 문제에도 불구하고 Vista에서 XP로 다운그레이드하기로 결정한 경우, 또는 이미 운영 체제를 변경했고 PC가 제대로 작동하지 않는 경우, 이 문서의 다른 항목들을 읽어보십시오. 아래에 이중 부팅 시스템 설정 결과를 설명한 항목도 있습니다.

PC에 변경을 가하기 전에 해야 할 일

알려진 하드웨어 및 소프트웨어 문제에도 불구하고 Vista에서 XP로 다운그레이드하거나 OS에 다른 변경 사항을 만들려고 결정한 경우, 다음 권장 사항을 따르는 것이 좋습니다.

  • Windows Vista 복구 DVD 만들기. Vista PC를 처음 시작한 경우 복구 DVD를 만들라는 메시지가 표시됩니다. 이 디스크 세트를 만들고 나서 OS를 변경한 후에 문제가 발생한 경우 복구 디스크를 사용하여 Windows Vista와 모든 필수 하드웨어 드라이버를 다시 설치하면 PC를 원래의 상태로 복원할 수 있습니다.

    복구 디스크 세트를 아직 만들지 않았다면, 최소 2장의 DVD-R 디스크를 이용해 지금 만드십시오. 시스템 상태가 예상과 다르게 나타나는 경우 이 Vista 복구 디스크를 이용해 PC를 안정된 기본 상태로 되돌릴 수 있습니다. 복구 디스크를 만드려면 PC를 다시 시작하고 F11을 눌러 HP Backup and Recovery Manager(HP 백업 및 복구 관리자)를 시작합니다. 복구 디스크 한 세트를 만들 수 있습니다. 자세한 내용은 아래에서 HP 노트북 PC - HP Recovery Manager(HP 복구 관리자) 사용(c00909173)을 참조하십시오.

    복구 디스크를 찾을수 없거나 복구 디스크를 만들기에 실패한 경우, HP에 연락하여 교체용 Vista 복구 디스크를 구입하십시오.

  • XP 드라이버 조사. 컴퓨터에서 장치 목록을 확인하고 제조업체 웹 사이트로 가서 장치에 제공된 드라이버에 관한 정보를 봅니다. 일부 구성 요소들은 함께 작동하지 않으며, 어느 한 구성 요소의 드라이버를 사용할 수 없는 경우 다른 장치들이 제대로 작동하지 않거나 전혀 작동하지 않을 수 있습니다.

OS를 변경한 후 PC가 제대로 작동하지 않는 경우 해야 할 일

Vista에서 Windows XP로 이미 컴퓨터를 다운그레이드한 경우, PC가 제대로 작동하지 않을 수 있습니다. 새 PC에서 사운드, DVD 또는 웹캠 등이 작동을 멈출 수 있으며, 사용자는 알맞은 XP 드라이버를 어디에서 구할 수 있는지 잘 알지 못할 수 있습니다. HP는 Vista 전용으로 설계된 PC에 XP 호환 드라이버를 제공하지 않습니다. PC에 Vista가 제공된 경우, PC가 Vista 운영 체제에서 작동하고 있으면 HP는 서면 계약에 따라 설치된 하드웨어 및 소프트웨어를 지원합니다.

참고 :

다른 업체에서 제공된 Vista용이 아닌 드라이버 및 프로그램을 사용해 볼 수는 있지만, HP는 사용자가 원래의 Vista 운영 체제를 다시 설치할 때까지 기술 지원을 제공하거나 잠재적인 하드웨어 문제를 진단해 드리지 않습니다.

하드웨어 및 소프트웨어 문제를 해결하려면, 다음과 같이 원래 PC에 설치되었던 Vista 운영 체제를 반드시 다시 설치해야 합니다.

Windows XP에서 Vista로 업그레이드한 후 XP로 되돌리려는 경우 해야 할 일

Windows XP가 제공된 Vista 지원 HP 노트북 PC를 구입한 후 Vista로 업그레이드한 경우, XP를 다시 설치할 수 있습니다. 이 경우 모든 XP 호환 드라이버를 다시 설치해야 합니다.

참고 :

모든 경우에 BIOS 및 하드웨어 드라이버는 해당 운영 체제와 호환되도록 설계된 것이어야 합니다. XP 드라이버는 Vista OS에서 작동하지 않고, Vista 드라이버는 XP OS에서 작동하지 않습니다.

하드웨어 및 소프트웨어 문제를 해결하려면, 다음과 같이 원래 PC에 설치되었던 XP 운영 체제를 다시 설치해야 할 수 있습니다.

  • XP를 사용하는 동안 Windows XP HP 복구 디스크를 만들었다면, 첫 번째 디스크를 넣고 PC를 다시 시작하여 시스템을 XP로 복원합니다.

  • PC를 원래의 구성으로 되돌린 후 HP 웹 사이트의 소프트웨어 및 드라이버 다운로드 웹 페이지로 이동하여 업데이트된 XP 드라이버가 있으면 설치하십시오. XP 페이지에 나열된 최신 BIOS를 설치해야 하며, Vista 드라이버는 설치하지 마십시오.

이중 부팅 시스템을 사용하지 말아야 하는 이유

이중 부팅 시스템 사용 방법에 관한 문서가 웹상에 제공되어 있지만, HP는 이중 부팅 구성으로 설정된 컴퓨터를 지원하지 않습니다. 이중 부팅은 두 가지 운영 체제에 모두 사용할 수 있는 하드웨어 드라이버가 필요합니다. HP는 특정 운영 체제용으로 설계되지 않은 부품에 대한 드라이버를 제공하지 않습니다. 이러한 구성 변경은 보증에 위반됩니다.

또한 노트북에 이중 부팅 구성을 설정할 수 있는 타사의 일반 드라이버를 구할 수 있다 해도 하드 드라이브 크기를 고려해야 합니다. 각 운영 체제는 하드 드라이브에서 상당한 크기의 공간을 차지합니다. XP와 Vista를 모두 설치하면 다른 응용 프로그램을 위한 공간이 제한될 수 있고, 시스템 성능이 저하됩니다.

관련 링크

HP 노트북 PC - HP Recovery Manager(HP 복구 관리자) 사용(c00909173) 

반응형

http://services.nexodyne.com/email/
 

사용자 삽입 이미지



잘 사용하지 않지만 위 사이트에서 제작한 나의 구글 메일 주소 이미지이다..

나름 깔끔하게 잘 나왔다 ㅎㅎ

반응형

소프트웨어 개발 프로젝트뿐만 아니라, 지금 하고 있는 일의 의미와 목적에 대해 생각해 본적이 있는가? 모든 일에는 그 목적을 위해 제때 적절한 사람이 해야 할 일이 있게 마련이다.

시점의 변화

일을 하다 보면 본래 목적과 의미를 잊어버린 채 전혀 엉뚱한 이슈에 많은 시간을 낭비하는 경우가 많다(원래 목적과는 상관없는 이슈로 몇 시간씩 회의해 본 일이 있다면 쉽게 이해할 수 있지 않을까?).

지금 무엇을 하고 있는가?
소프트웨어 프로젝트의 실패 원인 중 대부분은 ‘무엇을 왜 만들고 있는가’라는 고객의 요구사항을 제대로 파악하지 못하는 데 있다. 오픈을 얼마 남기지 않은 프로젝트 중반에 고객의 수정사항은 늘어가고, 고객들은 기능적인 면보다는 화면 디자인(색이나 폰트 사이즈 등)에 더 민감한 모습을 나타낸다. 또한 대부분의 고객은 자신이 원하는 바가 무엇인지를 제대로 알지 못하지만, 고객 자신이 좋아하고 좋아하지 않는 것에 대해서는 정확하게 알고 있다.

성공적인 프로젝트를 위해서는 가장 먼저 고객의 요구사항을 적절하게 파악하는 것이 중요하다. UML 유스 케이스 다이어그램(Use Case Diagram)이나 스토리보드 등이 매우 효율적으로 사용될 수 있으며 간단한 HTML이나 RIA(FLEX etc), 혹은 4GL(VB)로 만든 기능이 없는 스토리 위주의 샘플 애플리케이션은 고객의 요구사항을 수집하는 데 매우 좋은 도구가 될 수 있다. 복잡한 비즈니스 프로세스가 있는 업무의 경우에는 BPA 등의 도구를 사용해 워크플로우를 시각화시켜 두면 복잡한 흐름을 일목요연하게 정리할 수 있다.

이런 도구들로 수집한 요구사항에 대해 고객으로부터 확인을 받아 놓는다면(회의록에 대한 싸인이나 위의 산출물에 대한 고객 확인을 받아 놓는 것) 그 요구사항에 따라 스케줄된 일정에 새로운 변경이 이뤄졌을 경우에 합당한 개발 비용과 시간을 요구할 수 있을 것이다. 이처럼 소프트웨어 개발 프로젝트는 고객의 요구사항만 제대로 파악하고 있어도 80%는 성공한 것이다.

● TAG : 요구사항 분석, Use Case Diagram, sample software, 복잡한 비즈니스 프로세스, 워크플로우, BPA


닭 잡는데 소 잡는 칼 사용하기
모든 기술 역시 그 태생에 목적과 이유를 가지고 있다. 소프트웨어 개발에서 중요한 점 중에 하나가 현재 소프트웨어 개발 규모와 요구사항에 맞게 적절한 기술을 사용하는 것이다. 일반적으로 개발자들은 기술적인 호기심으로 인해 신기술 도입에 대한 욕심이 많다. 또한 매니저는 매니저 나름대로 신기술을 적용한 시스템이라는 ‘업적’을 원한다.

그러나 그런 기술들은 그만큼의 습득 시간과 비용을 요구한다. 예를 들어 몇 년 전 EJB 붐이 일었을 때, 많은 사이트들이 값비싼 WAS를 도입해 개발한 적이 있다. EJB는 분산 컴포넌트와 트랜잭션의 보장이 가장 큰 장점이다. 하지만 정작 이런 사이트들에서 그런 고차원적인 트랜잭션 처리가 필요한 경우는 실제 얼마나 있었을까? 그 당시 많은 사이트들이 고가의 WAS를 도입했음에도 불구하고 WAS를 단순한 JSP/Servlet 컨테이너 수준으로 밖에 사용하지 못했거나, EJB 역시 단순한 POJO식의 Business Object 이상으로 사용하지 못한 경우를 많이 봤다.

요즘처럼 JSTL, WebWork, Struts, Spring, Mapper, AOP 등과 같은 각종 오픈소스 프레임워크와 새로운 개념들이 난무하는 세상에서, 자칫하면 신기술에 대한 욕심으로 무리한 선택을 할 수도 있다. 프레임워크와 기술은 도구일 뿐이다. 아무리 좋은 도구라도 사용법을 제대로 알지 못한다면, 이런 도구들은 오히려 소프트웨어 프로젝트에 해가 될 수 있다.

그러나 한 번 더 생각해 보자. 소프트웨어 개발을 위해서는 시스템 기능과 요구사항에 적합한 적절하고 사용하기 쉬운 기술이 선택되어야 하며, 기술을 도입하는 데는 그만한 도입에 대한 비용(구입 비용뿐만 아니라 교육 및 습득에 대한 비용)이 고려되어야 한다.

● TAG : 오픈소스, 개발자와 매니저의 욕심, 도구는 도구일 뿐, 적절한 도구 사용하기

Simple is best! Easy is best!
모든 기계가 그렇듯이 복잡한 기계일수록 고장이 잘 난다. 소프트웨어도 마찬가지다. 복잡한 아키텍처일수록 문제가 생겼을 경우에 디버깅하기가 어렵고, 변경 사항이 생겼을 때 반영하기가 어렵다. 디자인 패턴으로 무장한 컨설턴트가 와서 시스템을 온통 디자인 패턴으로 도배해 놓을 수도 있다. 그렇지만 그것을 디버깅해야 하는 것은 그 컨설턴트가 아니라 개발자 여러분이다(디자인 패턴이 나쁘다는 것은 아니다. 불필요한 패턴 사용으로 시스템의 복잡도를 올리는 것에 대한 일종의 경고인 셈이다).
가능하면 시스템은 간단하게 설계하자. 고수가 설계한 시스템일수록 단순하고 고장이 적다.

좋은 기술이나 개념은 천재의 머릿속에서 나올 수 있다. 그러나 그것을 실제로 사용하는 사람은 천재가 아니라 평범한 사람들이다. 천재들의 수준에 맞춰 개발된 기술들을 과연 범인들이 쉽게 사용할 수 있을까? 인기 있게 널리 오래 사용되는 기술은 대부분 개념을 이해하기 쉽고 사용하기 쉬운 기술이다. 고수들이 만들어내는 각종 이론들로 무장한 시스템들이 아니라 오히려 이해하기 쉬운 시스템인 것이다.
 
● TAG : 간단할수록 튼튼하다. 쉬운 기술이 널리 퍼진다.

깊게 그리고 넓게
기술을 깊게 공부해야 하는 것은 당연한 이야기이지만, 지식의 깊이와 폭에 대한 균형이 필요하다. 예를 들어 소켓(Socket) 프로그래밍을 할 때, 자바의 경우 Multiplexing 성능이 떨어지기 때문에 C 언어로 MultiPlexer를 구현하고 JNI로 연결하면 훨씬 더 좋은 성능을 낼 수 있다.

화면이 많고 권한 처리가 복잡한 엔터프라이즈 솔루션의 경우에는 엔터프라이즈 포털(Enterprise Portal)과 같은 솔루션을 선택하면 시행착오를 줄이면서 양질의 소프트웨어를 만들어 낼 수 있다. SAP와 CRM 등을 통합할 때 모두가 자신이 강점을 지닌 언어로 개발할 수 있지만, 그보다 EAI 솔루션을 사용한다면 쉽고 성능 좋은 시스템 통합을 이끌어 낼 수 있다. 어느 정도 수준의 개발자라면 고객의 요구사항을 구현하는 것은 그다지 어려운 일은 아닐 것이다. 

그러나 이미 구현되어 있는 솔루션이나 오픈소스 아키텍처에 대한 지식이 있다면 처음부터 구현하는 게 아니라 그것들을 활용함으로써 주어진 시간과 비용 내에서 시행착오를 줄이고 양질의 소프트웨어를 만들어 낼 수 있다.

● TAG : 이미 있는 것들 찾아보기, 활용하기, 폭넓은 지식 가지기

마일스톤
마일스톤이란 ‘이정표’를 의미하는 것으로 프로젝트 일정 가운데 중요시점으로 생각하면 된다. 예를 들어 요구사항 분석 완료 시점, 각각 컴포넌트 완성 시점, 릴리즈 시점, 알파, 베타 테스트 시기 등이 이에 속한다.

마일스톤을 설정하는 이유는 마일스톤 전의 작업에 대한 검증을 통해 발생한 문제를 다음 단계까지 전파시키지 않기 위함이며, 요즘의 개발 방법론들이 잦은 Release와 Feed Back 등을 강조하는 것 역시 잦은 마일스톤을 설정함으로써 문제를 가능한 한 빨리 발견하고 풀어내기 위함이다(불확실성의 제거).

마일스톤이 설정된 주기는 그 각각이 전체 프로젝트에 대한 미니 프로젝트가 되며, 각 마일스톤 시 필요한 최소한의 산출물에 대한 정리와 검증(확인을 통한 문제 발견)이 뒤따라야 한다. 정확한 마일스톤을 설정한다면, 소프트웨어 개발 프로젝트에서 발생할 수 있는 위험 요소를 줄이는 데 큰 도움이 될 것이다.

나만의 도구를 갖추자
소프트웨어 개발에 있어서 IDE나 디버거(Debugger)와 같은 툴은 생산성에 지대한 영향을 준다. 개발자라면 적어도 자기가 가지고 다니는 도구 세트 하나는 있어야 하지 않을까? 여기서는 이미 많이 알려진 IDE나 디버깅(Debugging) 툴보다 소프트웨어 프로젝트에 필요한 각종 자동화 도구에 대해 간략하게 소개한다.

소스 관리
일주일 전에는 잘 돌아가던 모듈인데 일주일 동안의 작업 내용이 반영된 후에는 뭔가 문제가 생겼다. 어떻게 해야 할까? 어느 부분을 수정했는지 알 수 있다면 좀 더 빨리 문제의 원인을 밝혀낼 수 있지 않을까?

운영 중인 시스템이 새로운 코드를 반영한 후에 문제가 생겼다. 수정한 부분을 찾는 것보다 이전의 소스 코드로 원상 복귀하는 것이 운영을 정상화하는 데 더 빠르다. 그렇다면 예전에 개발한 소스는 어디에 있을까?

고객별로 릴리즈한 버전이 많은데 A 고객의 이슈를 해결한 버전은 도대체 어느 버전일까? 여러 사람이 협업 작업을 한다면 공통으로 소스 코드는 어떻게 관리해야 할 것인가? 소스를 한 곳에서 중앙 집중적으로 관리하고 협업을 가능하게 해주며 소스에 대한 변경 내역을 관리할 수 있게 해주는 것이 바로 소스 관리 시스템이다. 널리 사용되고 있는 무료 소스 관리 시스템에는 CVS와 SubVersion이 있다.

● TAG : 소스 관리, CVS, SubVersion
빌드 도구
빌드는 소프트웨어 개발에서 항상 수행해야 하는 작업이다(물론 JSP나 ASP 등의 스크립트 언어로만 개발한다면 모르겠지만). 컴파일하고 기다리고 결과가 나오면 검증하고 에러가 없으면 릴리즈(또는 배포)하고 항상 해야 하는 반복적인 작업이다.
에러가 발생하지 않는 상황이라면 특별하게 할 일도 없다. 우리가 빌드를 기다리는 것은 혹시나 있을지 모르는 에러에 대비하기 위한 것일 뿐 빌드와 배포는 커맨드들을 반복해 입력하는 단순 작업에 해당한다.

이런 단순 작업을 내가 아닌 누군가가 해준다면 그 시간에 코드를 최적화하거나 좋은 소프트웨어 구조로 리펙토링하는 등의 생산적인 작업을 할 수 있지 않을까? 그 누군가가 바로, 빌드 자동화이다. 기본적인 도구로는 make, ant, maven과 같이 커맨드들을 조합해 빌드해 주는 도구가 있고, 여기에 Daily Build (Daily Build의 중요성은 여기서 언급하지 않더라도 『조엘 온 소프트웨어』와 같은 유수의 개발 관련 서적에서 이미 충분히 언급되어 있다)나 스케줄에 따른 빌드나 Release 버전 생성을 자동으로 수행해 주는 빌드 자동화 소프트웨어가 있다. 이러한 소프트웨어들은 빌드 배포에 대한 스케줄링뿐만 아니라, 자동화된 릴리즈 버전 생성 등이 가능하고 빌드 중의 에러에 대해 담당자에게 SMS나 이메일 등으로 ALERT해 주는 기능을 가지고 있으므로, 대규모 협업 프로젝트에서 매우 유용하게 사용될 수 있다.

대표적인 공개 소프트웨어로는 Cruise Control, Ant Hill 등이 있다. Cruise Control은 Text 기반의 도구로 매우 강력한 빌드 자동화 기능을 제공하지만 Text 기반이기 때문에 다소 사용하기가 어렵다. Ant hill의 경우에는 Web UI를 제공하기 때문에 상대적으로 사용하기는 쉽지만 대신 Cruise Control과 같은 강력한 기능을 제공하기는 어렵다. 그리고 빌드 과정 중에 빌드된 컴포넌트가 제대로 작동하는지 여부를 자동으로 테스트하기 위해 JUnit과 같은 테스트 프레임워크가 있다. 빌드 자동화는 ant와 같은 빌드 도구, JUnit과 같은 테스트 도구, 그리고 Cruise Control 등과 같은 빌드 자동화 도구로 구성되고, 빌드와 릴리즈(배포)를 수행함으로써 시간 절약은 물론, 품질에 대한 향상까지 기대할 수 있다.

● TAG : ant, maven, cruise control, anthill, JUnit

테스트 도구
테스트와 QA(Quality Assurance)에 대한 중요성은 언급하지 않더라도 이미 잘 인식하고 있으리라 믿는다. 테스트의 종류에는 컴포넌트별 단위 테스트, 시나리오에 따른 기능 테스트, 적절한 용량을 커버하고 성능을 낼 수 있는지를 검증하는 부하 테스트, 그리고 장애에 대한 대처 능력을 시험하는 장애 테스트 등이 있다.
그 중에서 테스트팀이나 QA팀이 아닌 개발자들이 일반적으로 수행할 수 있는 테스트로는 컴포넌트별 단위 테스트와 부하 테스트를 꼽을 수 있다. 단위 테스트는 소프트웨어 개발 주기 중 테스트 단계에서뿐만이 아니라 개발단계 중간에서도 컴포넌트가 제작될 때마다 모듈의 기능을 검증해 버그를 예방할 수 있다.

단위 테스트는 JUnit 등의 단위 테스트를 자동화할 수 있으며, 위에서 설명한 것처럼 빌드 절차에 자동화해 포함시켜 빌드 때마다 개발한 컴포넌트 기능의 이상 여부를 검증할 수 있다. 부하 테스트는 소프트웨어의 비기능적인 요소인 성능이나 용량을 측정하는 데 사용되는데 개발자 단계의 부하 테스트를 통해 알고리즘의 최적화 여부나 과부하시에 장애(Dead Lock, Lock 대기 현상, CPU 과점유)를 검증할 수 있다.
 

● TAG : 단위 테스트, 기능 테스트, 성능 테스트, JUnit, MS Stress, JMeter, Load Runner

커뮤니케이션 도구
팀원 간의 작업 배분, 이슈에 대한 기술적인 토론, 고객의 변경된 요구사항의 반영 내용, 그리고 버그에 대한 이슈 등을 해결해 나가는 것이 개발이라고 할 수 있다. 보통 이런 이슈들은 회의나 이메일, 전화 등을 통해 이뤄지는데, 각각의 이슈에 대해 서로 이야기한 내용과 협의한 내용들에 대해 문서화해 추후에 이슈에 대해 어떻게 대처를 하고 소프트웨어 코드에 반영을 했는지를 추적해야 할 경우가 있다.

이런 이슈에 대한 추적과 커뮤니케이션을 가능하게 해주는 것이 Issue Tracking 시스템이다. 이슈를 오픈하고 관련된 사람을 추가하며 이슈에 대한 진행 상황과 중요도를 기입함으로써 현재 시스템에 대한 이슈에는 어떤 것이 있는지 알려주고, 진행되고 있는 상태를 쉽게 관리할 수 있게 해준다.

해당 이슈가 반영된 버전을 기입해 어느 버전에 문제가 있고 해결되었는지를 판단하게 함으로써 적절한 Release 버전을 판단할 수 있게 한다. 그리고 이슈가 해결되었을 때는 SubVersion과 같은 소스 관리 시스템에서 이슈를 해결한 Revision Number를 Issue Tracking 시스템에 기입해 이슈를 어떤 식으로 소스 코드에 반영했는지를 추적할 수 있게 한다. 주로 버그 관리에 많이 사용되는데, 그 외의 개발 요구사항을 반영하는 데도 응용할 수 있다. 대표적인 소프트웨어로는 BugZilla나 JIRA와 같은 소프트웨어를 들 수 있다.


● TAG : Issue Tracking System, Bugzilla, JIRA

튼튼한 소프트웨어를 만드는 관점 갖추기
마지막으로 실제 개발을 할 때 생각해야 할 것 몇 가지만을 짚고 넘어가도록 하자.

개발자는 메모리로부터 자유로울 수 없다.
자바 언어가 나오면서 개발자들은 malloc과 free(C 언어에서 메모리를 할당하는 함수)로부터 자유로워졌다. Garbage Collector라는 강력한 기능이 자동으로 메모리를 관리해 준다. 그렇다면 진정 우린 메모리에서 자유로울 수 있을까?

32비트 머신을 가정했을 때, 32비트 머신의 프로세스당 메모리 사용량은 2^32=4G이다. 여기서 유닉스의 경우는 이 가운데 2GB가 공유 메모리 영역이고 실제 자바가 사용할 수 있는 것은 2GB이다. 이 중에서 클래스(Class)나 메소드(Method)가 올라가는 Perm 영역이 대략 64~256MB이고, JVM 자체가 로딩되는 메모리 영역을 다 합하면 실제로 자바 애플리케이션의 Heap Size는 최대 1.5~1.7GB 내외이다.

그 영역 안에서도 애플리케이션이 기본적으로 꾸준히 사용되는 영역이 400~500MB라면, 일반적으로 1GB 내에서 프로그래밍을 해야 한다는 이야기다.
물론 64비트 JVM이 출시되고 GC의 성능이 좋아지면서 메모리에 대한 부담이 줄어드는 것은 사실이지만, 소프트웨어를 개발한다면 항상 메모리 사용에 대해 충분히 고려하고 시스템을 설계해야 한다.

● TAG : 메모리 신경 쓰기

성능에 대해 고민하기
성능에 대해 개발자들만큼 민감한 사람들이 또 있을까? 그렇지만 그들이 작성한 코드는 정말 최적의 성능을 낼 수 있도록 구현되어 있을까? 직접 작성한 코드를 한 두명의 유저 기반에서 테스트했을 때는 잘 돌아간다. 그렇지만 실제 환경이 여러 명의 동시 접속자를 지원하는 서비스라면? SQL 문장이나 잘못된 Synchronized 처리 등은 실제 환경이나 동시 사용자가 많지 않으면 성능에 영향을 주지 않는다.

성능에 대한 좋은 가이드와 프로그래밍 방법은 항상 고민해야 하는 문제이고, 여기에 성능에 대한 검증을 어떻게 할 것인지를 고려해 코드를 만들어야 할 것이다.
컴포넌트별로 테스트시에 Profiler나 APM-Application Performance Management Tool 등을 이용하면 도움이 되고 간단한 부하 테스트를 더한다면 성능 상에 문제가 있는 코드가 아닌지 좀 더 쉽게 검증할 수 있다. 물론 어느 정도 경험이 쌓인다면 이런 도구 없이도 코딩 시에 성능에 문제가 되는 코드의 대부분은 걸러낼 수 있을 것이다.


● TAG : 성능 고려하기, 성능 테스트, Profiler, APM
로깅 습관화
결함(Defect)이 없는 소프트웨어는 있을지 몰라도 문제(Bug)가 없는 소프트웨어는 존재하지 않는다. 그러므로 문제가 있을 때 어떻게 빨리 발견해 해결할 것인지가 중요하다. 그런 방법 중의 하나가 디버깅을 위한 로깅(LOGGING) 처리이다. 로깅은 장애나 문제가 없을 때는 그다지 소용 없는 코드이고 시간 낭비처럼 보일 수 있지만 잘 구현된 로그인(LOGGIN)은 문제 해결 시간을 줄이는 데 큰 도움을 준다. 그렇다고 로깅이 범람해서는 안 된다. 로그(LOG) 메시지도 비즈니스 로직처럼 설계가 필요하다. 적절한 로깅 설계와 반영에 대해 습관을 들이도록 하자.

● TAG : Logging, Debugging

  1. Favicon of http://kyungseo.pe.kr/blog BlogIcon 박경서 2008.04.04 18:07

    언넝 고수의 반열에 오르길~! ^^)b

반응형
쉘 프로그래밍 강좌

  • 참고서적: 초보자용 리눅스 프로그래밍 (대림출판사, 한동훈,이만용역, NEIL MATTHEW, RICHARD STONES 저)
  • 넷츠고 리눅스 동호회 7월 제 5회 정기 공개강좌 자료
  • 글쓴이: 위경섭 <powerhack@netsgo.com>
  • 위키문서 변환: 윤현호 <hhyoon@kldp.org> 2005년 2월 23일. 원본: http://wiki.kldp.org/KoreanDoc/Shell_Programming-KLDP


1 변수

  • 쉘변수는 처음 사용될 때 만들어진다. 즉 미리 선언할 필요가 없다.
  • 쉘변수는 유닉스 명령과 마찬가지로 대소문자에 구별이 있다.
  • 쉘변수는 기본적으로 데이터를 문자열로 저장한다. 수치를 대입해도 실제 수치가 아닌 문자열이 저장된다. 계산이 필요할 경우는 자동으로 수치로 변환하여 계산후 다시 문자열로 저장된다.
  • 쉘변수의 값을 사용할 때는 변수명앞에 "$" 를 붙여서 사용한다.
  • 쉘변수에 값을 대입할때는 "$"를 사용하지 않는다.
  • 쉘변수는 타입이 없다. 즉 아무 값이나 다 넣을 수 있다.

1.1 환경변수

쉘을 기동하고나면 기본적으로 셋팅되어있는 변수들이다. 유닉스/리눅스에는 많은 환경변수들이 있고 필요한경우 이 변수들을 마치 일반변수처럼 값을 얻어오거나 셋팅할 수 있다. 여기서는 쉘과 직접적인 관련이 있는것만 설명한다.
  • $0 - 실행된 쉘 스크립트 이름
  • $# - 스크립트에 넘겨진 인자의 갯수
  • $$ - 쉘 스크립트의 프로세스 ID

1.2 인자 변수

쉘스크립트에 인자를 넘겨줄때 그 인자들에 대한 정보를 가지고 있는 변수들.
  • $1~ $nnn - 넘겨진 인자들
  • $* - 스크립트에 전달된 인자들을 모아놓은 문자열. 하나의 변수에 저장되며 IFS 환경변수의 첫번째 문자로 구분된다.
  • $@ - $*과 같다. 다만 구분자가 IFS변수의 영향을 받지 않는다.

2 일반변수

일반변수에 특별한 제약은 없다. 단 대소문자 구분만 정확하게 해주면 된다.

예제
#!/bin/sh
echo "This Script Executable File : $0"
echo "Argument Count : $#"
echo "Process ID : $$"
echo "Argument List \$* : $*"
echo "Argument List \$@ : $@"
echo "Argument 1 : $1"
echo "Argument 2 : $2"
echo "Argument 3 : $3"
echo "Argument 4 : $4"  
실행
$chmod 755 test1
$./test1 a1 a2 a3 a4
This Script Executable File : ./test1
Argument Count : 4
Process ID : 905
Argument List $* : a1 a2 a3 a4
Argument List $@ : a1 a2 a3 a4
Argument 1 : a1
Argument 2 : a2
Argument 3 : a3
Argument 4 : a4

2.1 연산

sh
변수의 산술 연산은 생각하는 것처럼 쉽지 않다. 위에서 언급했듯이 변수에는 모든 것이 문자열로 저장되기 때문에 연산이 불가능하다. 연산을 위해서는 좀 복잡한 절차를 거쳐야 한다.
변수 = $((산술식))
이것이 가장 단순한 연산 규칙이다. 산술식내에는 변수($1, $a 와 같은) 도 들어갈 수 있다. 산술식 내에 숫자가 아닌 문자열, 또는 문자열이 담겨있는 변수가 들어가면 그것들은 계산에서 제외된다. (정확히 말하면 0 으로 간주되어 연산이 이루어 지지 않는다.)

2.2 매개변수 확장

매개변수 확장이란 변수의 값을 문자열 등으로 대체하는 것을 말한다. 단순한 대체뿐 아니라 변수내의 문자열을 조작하여 원하는 문자열만을 추출할 수도 있다.

형식:
  • ${parm:-default} - parm이 존재하지 않으면 default로 대체된다.
  • ${#parm} - parm의 길이를 참조한다.(가져온다)
  • ${parm%word} - 끝에서부터 word와 일치하는 parm의 최소부분(첫번째 일치)을 제거하고 나머지를 반환한다.
  • ${parm%%word} - 끝에서부터 word와 일치하는 parm의 최대부분(마지막 일치)을 제거하고 나머지를 반환한다.
  • ${parm#word} - 처음부터 word와 맞는 parm의 최소부분(첫번째 일치)을 제거하고 나머지 부분을 반환한다.
  • ${parm##word} - 처음부터 word와 맞는 parm의 최대부분(마지막 일치)을 제거하고 나머지를 반환한다.
word에는 와일드 카드를 사용할 수 있다.예를 보자.
1 #!/bin/sh
2
3 p="/usr/X11R6/bin/startx"
4
5 unset p
6 a=${p:-"Variable p Not found"}
7 echo $a
8
9 p="/usr/X11R6/bin/startx"
10 a=${p:-"Variable parm Not found"}
11 echo $a
12
13 a=${#p}
14 echo $a
15
16 a=${p%/*}
17 echo $a
18
19 a=${p%%/*}
20 echo $a
21
22 a=${p#*/}
23 echo $a
24
25 a=${p##*/}
26 echo $a
27                    
위 스크립트의 결과는 다음과 같다.
Variable p Not found
/usr/X11R6/bin/startx
21
/usr/X11R6/bin

usr/X11R6/bin/startx
startx
  • 6행 : 변수 p 가 제거 되었으므로 "Variable p Not found" 가 a에 들어간다.
  • 10행 : 변수 p 가 있으므로 그대로 a에 들어간다.
  • 13행 : a에는 변수 p의 길이가 들어간다.
  • 16행 : p 에서 가장 오른쪽의 "/"부터 끝까지 지우고 나머지를 a에 넣는다.
  • 19행 : p 에서 가장 왼쪽의 "/" 부터 끝까지 지우고 나머지를 a에 넣는다. (아무것도 없다)
  • 22행 : p 의 처음부터 가장왼쪽의 "/" 까지 지우고 나머지를 a에 넣는다.
  • 25행 : p 의 처음부터 가장 오른쪽의 "/"까지 지우고 나머지를 a에 넣는다.

3 조건 판단

쉘 스크립트에서 조건판단은 if 와 test 명령을 혼합하여 사용한다. 일반적인 예는 다음과 같다.
if test -f test1
then
...
fi

-f 는 주어진 인자가 일반 파일일 때 참이 된다.

test 명령은 [] 로 대체될 수 있다.
if [ -f test1 ]
then
...
fi

if [ -f test1 ]; then
...
fi

3.1 test 명령

sh
test 명령의 조건은 다음과 같이 세 부류로 나누어진다.

3.1.1 문자열 비교

  • [ string ] - string이 빈 문자열이 아니라면 참
  • [ string1 = string2 ] - 두 문자열이 같다면 참
  • [ string1 != string2 ] - 두 문자열이 다르면 참
  • [ -n string ] - 문자열이 null(빈 문자열) 이 아니라면 참
  • [ -z string ] - 문자열이 null(빈 문자열) 이라면 참

3.1.2 산술 비교

  • [ expr1 -eq expr2 ] - 두 표현식 값이 같다면 참 ('EQual')
  • [ expr1 -ne expr2 ] - 두 표현식 값이 같지 않다면 참 ('Not Equal')
  • [ expr1 -gt expr2 ] - expr1 > expr2 이면 참 ('Greater Than')
  • [ expr1 -ge expr2 ] - expr1 >= expr2 이면 참 ('Greater Equal')
  • [ expr1 -lt expr2 ] - expr1 < expr2 이면 참 ('Less Than')
  • [ expr1 -le expr2 ] - expr1 <= expr2 이면 참 ('Less Equal')
  • [ ! expr ] - expr 이 참이면 거짓, 거짓이면 참
  • [ expr1 -a expr2 ] - expr1 AND expr2 의 결과 (둘다 참이면 참, 'And')
  • [ expr1 -o expr2 ] - expr1 OR expr2 의 결과 (둘중 하나만 참이면 참, 'Or')

3.1.3 파일 조건

  • [ -b FILE ] - FILE 이 블럭 디바이스 이면 참
  • [ -c FILE ] - FILE 이 문자 디바이스 이면 참.
  • [ -d FILE ] - FILE 이 디렉토리이면 참
  • [ -e FILE ] - FILE 이 존재하면 참
  • [ -f FILE ] - FILE 이 존재하고 정규파일이면 참
  • [ -g FILE ] - FILE 이 set-group-id 파일이면 참
  • [ -h FILE ] - FILE 이 심볼릭 링크이면 참
  • [ -L FILE ] - FILE 이 심볼릭 링크이면 참
  • [ -k FILE ] - FILE 이 Sticky bit 가 셋팅되어 있으면 참
  • [ -p FILE ] - True if file is a named pipe.
  • [ -r FILE ] - 현재 사용자가 읽을 수 있는 파일이면 참
  • [ -s FILE ] - 파일이 비어있지 않으면 참
  • [ -S FILE ] - 소켓 디바이스이면 참
  • [ -t FD ] - FD 가 열려진 터미널이면 참
  • [ -u FILE ] - FILE 이 set-user-id 파일이면 참
  • [ -w FILE ] - 현재 사용자가 쓸 수 있는 파일(writable file) 이면 참
  • [ -x FILE ] - 현재사용자가 실행할 수 있는 파일(Executable file) 이면 참
  • [ -O FILE ] - FILE 의 소유자가 현재 사용자이면 참
  • [ -G FILE ] - FILE 의 그룹이 현재 사용자의 그룹과 같으면 참
  • [ FILE1 -nt FILE2 ] - : FILE1이 FILE2 보다 새로운 파일이면 ( 최근파일이면 ) 참
  • [ FILE1 -ot FILE2 ] - : FILE1이 FILE2 보다 오래된 파일이면 참
  • [ FILE1 -ef FILE2 ] - : FILE1 이 FILE2의 하드링크 파일이면 참

3.2 if 구문

if 문은 조건을 판단하여 주어진 문장을 수행한다.

3.2.1 형식 1 (단일 if 문)

형식:
if [ 조건 ]
then
    문장1
    문장2
fi

3.2.2 형식 2 (if-else 문)

형식:
if [ 조건 ]
then
    문장3
    문장4
fi

3.2.3 형식 3 (if-elif 문)

형식:
if [ 조건 ]
then
    문장1
    문장2
elif
    문장3
    문장4
else
    문장5
    문장6
fi

3.3 case 구문

'패턴'에는 * 문자, 즉 와일드카드를 사용할 수 있다.

형식:
case 변수 in
패턴 [ | 패턴 ] ... ) 문장 ;;
패턴 [ | 패턴 ] ... ) 문장 ;;
....
* ) 문장 ;;
esac

3.4 목록

여려 명령을 실행할때 앞의 명령의 결과에 의해서 다음행동이 결정되어야 할 경우가 있다. 이런경우에 AND나 OR조건을 사용해서 한번에 처리할 수 있다. 이것은 쉘 스크립트 뿐 아니라 명령행에서도 사용 가능하다. 물론 if 문을 이용해서 반환값을 검사하여 처리할 수 있지만 문장이 길어지고 복잡해진다.

3.4.1 AND 목록

statment1 && statment2 && statmentN && .....

위의 명령들은 각 명령이 거짓이 될 때 까지 명령을 수행해 나간다. 수행 도중 결과가 거짓이 되면 그이후의 명령은 수행되지 않는다.

3.4.2 OR 목록

statment1 || statment2 || statmentN || .....

위의 명령들은 각 명령이 거짓이 나오는 동안 계속된다. 즉 참이 나오면 실행을 멈춘다.

3.4.3 AND와 OR목록은 혼용이 가능하다.

[ 조건 ] && 문장1 || 문장2

위의 예는 조건이 참이면 문장1을 수행하고 거짓이면 문장2를 수행한다.

또한 위의 문장1이나 문장2에서 여러개의 문장을 수행하고 싶을 때는 {}를 사용하면 된다.
[조건] && {
    문장1
    문장2
    문장3
} || {
    문장4
    문장5
    문장6
}

4 제어문

4.1 for

for 문은 지정된 범위안에서 루프를 수행한다. 범위는 어떤 집합도 가능하다.

형식:
for 변수 in 값1, 값2, ...
do
    문장
done

매 루프를 돌때마다 변수의 값은 in 이후의 값으로 대체된다.

예제:
for str in "test1", "test2", "test3", "test4"
do
    echo @str
done

출력:
test1
test2
test3
test4

값에는 와일드 카드 확장을 사용할 수 있다.
for file in $(ls -a | grep "^\.")
do
    echo "$file is Hidden File"
done

위 예의 출력 결과는 현재 디렉토리에서 처음이 "." 으로시작하는 파일(히든파일)만을 출력한다.

for file in $(ls chap[345].txt); do
    echo "--- $file ---" >> Books.txt
    cat $file >> Books.txt
done

위의 예는 chap3.txt, chap4.txt, chap5.txt 파일을 Books.txt 라는 파일에 붙여 넣는다.

다음의 예를 보고 결과를 예측해보자.
echo "\$* output"

for fvar in $*
do
    echo $fvar
done

echo "\$@ output"
for fvar in $@
do
    echo $fvar
done

4.2 while

for 명령의 경우는 횟수를 지정해서 루프를 수행하는 데는 문제가 있다. while 문은 실행 횟수가 지정되지 않았을 때 편리하다.

형식:
while 조건문
do
    문장
done

예제를 보자. 패스워드를 입력받고 맞는지 확인하는 프로그램이다.
echo "Enter Password : "
read password1

echo "Retype Password : "
read password2

while [ "$password1" != "$password2" ]
do
    echo "Password mismatch Try again "

    echo "Retype Password : "
    read password2
done

echo "OK Password Match complete"

어떻게 동작하는가 ?

4.3 until

until은 while문과 동일한 효과를 내지만 조건이 반대이다. 즉, while문은 조건이 참일동안 루프를 수행하지만 until은 조건이 거짓일 동안 루프를 수행한다.

형식:
until 조건문
do
    문장
done

다음 예를 보자. 이 예는 지정한 유저가 로그인하면 알려준다.
#!/bin/sh

until who | grep "$1" > /dev/null
do
    sleep 10
done

echo "User $1 just logged in ^_^"

4.4 select

select문은 원하는 리스트를 출력하고 그 중 선택된 것을 돌려주는 구문이다. 주의할 점은 select의 루프 내에서는 자동적으로 루프를 벗어날 수 없다. 반드시 break문을 사용해서 루프를 벗어나야 한다.

예: 간단한 퀴즈
#!/bin/sh

echo "다음중 스크립트언어 프로그래밍에 속하는 것은 ?"
select var in "쉘 프로그래밍" "C 프로그래밍" "자바 프로그래밍" "Exit"
do
    if [ "$var" = "쉘 프로그래밍" ]
    then
        echo "정답입니다."
        exit 0
    elif [ "$var" = "Exit" ]
    then
        echo "종료합니다."
        exit 1
    else
        echo "$var 을 선택하셨습니다. 오답입니다."
        echo "다음중 스크립트언어 프로그래밍에 속하는 것은 ?"
    fi
done

5 함수

쉘 스크립트 내부에 또는 다른 스크립트파일에 함수를 정의해 놓고 사용할 수 있다. 함수를 사용하면 코드를 최적화 할 수 있고, 코딩이 간결해지며,재사용이 가능하다. 그러나 다른 스크립트 파일을 호출해서 함수를 실행할 경우, 가능은 하지만 스크립트의 실행시간이 길어지고, 함수의 결과를 전달하는 것이 까다롭기 때문에 가급적이면 외부파일의 함수는 안쓰는 것이 좋다.

형식:
함수명 ()
{
	문장
	return 값
}

사용
함수명 인자1, 인자2, ...

함수는 독립적으로 $#, $*, $0 등의 인자 변수를 사용한다. 즉 함수내의 $#과 본체의 $#은 다를 수 있다는 것이다.

다음의 예를 보자
#!/bin/sh
		
func()
{
    echo ------ this is func --------
    echo "This Script Executable File : $0"
    echo "Argument Count : $#"
    echo "Process ID : $$"
    echo "Argument List \$* : $*"
    echo "Argument List \$@ : $@"
    echo "Argument 1 : $1"
    echo "Argument 2 : $2"
    echo "Argument 3 : $3"
}

echo ------ this is main --------
echo "This Script Executable File : $0"
echo "Argument Count : $#"
echo "Process ID : $$"
echo "Argument List \$* : $*"
echo "Argument List \$@ : $@"
echo "Argument 1 : $1"
echo "Argument 2 : $2"
echo "Argument 3 : $3"
echo "Argument 4 : $4"
func aa bb cc 

본체와 함수에서 동일한 변수를 보여주지만 값은 틀린다는 것을 알 수 있다.

함수에서 값을 반환하기 - 함수에서 반환값은 반드시 정수값만을 반환할 수 있다. 이 값을 if 등으로 조건을 판단해서 사용할 수 있다. 반환값 중 0은 참으로 나머지 숫자는 거짓으로 판별된다.

6 명령어

쉘에서 쓸 수 있는 명령어는 두가지로 나누어진다. 명령 프롬프트 상에서 실행 시킬 수 있는 외부 명령어와 쉘 내부 명령이다. 내부 명령은 보통 쉘 내부나 쉘 구문상에서 쓰인다. 외부명령은 쉘에 관계없이 사용이 가능하다.

6.1 break

제어문이나 조건문의 루프를 빠져나갈때 사용한다.

예제
while [ $a -eq 10 ]
do
    if [ $a -eq 5 ]; then
        break
    fi
done

6.2 continue

제어문이나 조건문의 처음으로 돌아가서 다시수행한다.

예제
while [ $a -eq 10 ]
do
    if [ $a -eq 5 ]; then
        continue
    fi
done

6.3 : 명령

의미없는 명령. 논리값 true를 대신해 쓰기도 한다.

6.4 . 명령

. 명령을 사용하면 현재 쉘에서 명령을 실행시킨다 그러므로 실행된 명령의 결과를 본 프로그램에서 사용할 수 있다.

예를 들면 A 라는 스크립트에서 B라는 스크립트를 그냥 실행할 경우 B에서의 변화(환경변수 등)는 A에게 아무런 영향도 미치지 않는다. 그러나 . 명령을 사용해서 실행하면 B에서의 변화가 A에도 영향을 미친다.

6.5 echo

문장을 출력한다. 자동으로 개행문자가 삽입된다. (다음 줄로 넘어간다)

6.6 eval

인자의 실제 값을 구하는데 사용한다.
foo=10
x=foo
y='$'$x
echo $y

이 예를 실행해 보면 $foo가 출력된다
foo=10
x=foo
eval y='$'$x
echo $y

이 예에서는 $foo의 값 즉 10 이 출력된다. eval명령은 원하는 문자열들을 조합해서 변수를 액세스 할 수 있다.

6.7 exec

현재 쉘을 다른 프로그램으로 대체한다.

예제
exec csh

6.8 exit n

현재 쉘을 종료한다. 종료시 n 값을 리턴한다.

6.9 export

해당 쉘에서 파생된 자식 프로세스에서 export한 환경변수는 본래 쉘에서 관리한다.

6.10 expr

표현식의 값을 구한다.
x=`expr 1 + 2`
요즘은 expr보다는 $((계산식)) 구문을 많이 사용한다.

6.11 printf

C 언어의 printf명령과 흡사하다.

형식:
printf "Format String" arg1 arg2 arg3 ...

6.12 return

쉘 함수에서 값을 반환 할 때 쓰인다. 0은 성공을 1~125까지는 쉘 에러코드를 나타낸다.

6.13 set

쉘 내부에서 매개 인자를 설정한다. set의 인자로 쓰인 문자열은 공백에 의해 $1 부터 차례대로 대입된다.

예제
#!/bin/sh
echo $#
set $(ls)
echo $# 

결과는
0
22

이다. (22는 필자의 ls 결과의 갯수이다.) 첫번째 0는 이 스크립트에 인수가 없으므로 0이고 set $(ls) 에 의해서 인수의 갯수가 22개로 늘었다.

6.14 shift

쉘의 인자를 한자리씩 아래로(n -> 1 로) 이동시킨다.

예제
#!/bin/sh

echo $1
shift
echo $1
shift 5
echo $1

실행
#./myscript 1 2 3 4 5 6 7 8 9 0
1
2
7

6.15 trap

쉘의 실행도중 시그널을 처리하는 시그널 처리기를 만드는 역할을 한다.

형식:
trap command signal

쉘 스크립트는 위에서 아래로 실행되므로 보호하려는 부분 이전에 trap 명령을 사용해야 한다. trap 조건을 기본으로 사용하려면 명령에 - 를 넣으면 된다. 신호를 무시하려면 '' 빈 문자열을 준다.

6.16 unset

변수나 함수를 제거한다.

7 명령 실행

외부 명령의 실행 결과를 변수에 집어넣어 변수의 값으로 사용할 수 있다.

형식:
x = $(명령)

이렇게 변수에 결과를 넣은 후에는 이 변수를 일반문자열로 생각하고 원하는 가공을 해서 결과를 얻어낼 수 있다. 위에서 보았던 매개변수 확장이나 set명령을 이용해서 원하는 부분을 추출해 내면 그만이다.

8 쉘 스크립트 내부에서 명령에 입력 전달하기 (Here Documents)

이 기능은 쉘 내부에서 명령어에 입력을 전달하는 방법이다. 전달된 입력은 마치 키보드에서 눌려진 것처럼 반응한다.

형식:
명령 << 종료문자열
입력값.....
종료문자열

예제: 자동으로 메일을 보내는 스크립트
#!/bin/sh

mail $1 << myscript
This is Header
This is Body
.

myscript

9 디버깅 하기

쉘 프로그래밍 시 간단하게 디버깅하는 방법을 소개합니다.

9.1 쉘 옵션

  • sh -n 스크립트 : 문법 에러만을 검사, 명령을 실행하지 않음
  • sh -v 스크립트 : 명령을 실행하기 전에 에코
  • sh -x 스크립트 : 명령줄에서 처리한 다음 에코

9.2 set 옵션

위의 쉘 옵션은 아래와 같이 set 옵션으로도 설정할 수 있다.
  • set -o noexec 또는 set -n : 문법 에러만을 검사, 명령을 실행하지 않음
  • set -o verbose 또는 set -v : 명령을 실행하기 전에 에코
  • set -o xtrace 또는 set -x : 명령줄에서 처리한 다음 에코
  • set -o nounset 또는 set -u : 정의되지 않은 변수가 사용되면 에러 메시지를 제공한다.

아래와 같이 set -x를 이용하여 손쉽게 실행과정을 추적할 수 있다. (참고로 set 옵션을 취소하려면 set +x를 입력하면 된다. 다른 옵션도 마찬가지)
set -x
for str in "test1" "test2" "test3" "test4"
do
    echo $str
done

결과
+ for str in '"test1"' '"test2"' '"test3"' '"test4"'
+ echo @str
@str
+ for str in '"test1"' '"test2"' '"test3"' '"test4"'
+ echo @str
@str
+ for str in '"test1"' '"test2"' '"test3"' '"test4"'
+ echo @str
@str
+ for str in '"test1"' '"test2"' '"test3"' '"test4"'
+ echo @str
@str
반응형

필자 서문


프로그래머들은 솔라리스 제품을 사용하기 시작할 때 프로그래밍 스크립트를 즉시 시작하기를 원합니다. 처음에는 효율성과 간결성에 대해서는 관심들이 없고 오로지 그 결과에만 관심을 가지고 있습니다. 본 기술 자료에서는 신속한 시작을 위해 검증된 쉘 프로그래밍 기법에 대해 설명합니다. 경험이 쌓일수록 자신만의 프로그래밍 스타일을 개발하고 스크립트의 효율성과 간결성을 향상시킬 수 있을 것입니다.

배경


command shell 은 사용자와 상호 작용하고 운영 시스템과 통신하는 레이어입니다 MS-DOS를 사용할 때 대부분의 사람들은 command.com 쉘을 사용하지만, COMSPEC 환경 변수를 통해 다른 쉘이 지정될 수도 있습니다.

이와 유사하게, 각 UNIX 사용자는 UNIX로 전달하기 위해 사용할 명령 쉘을 선택해야 합니다. UNIX 계정이 설정될 때 시스템 관리자는 사용자의 기본 쉘을 선택합니다. 표준 옵션은 Bourne Shell(/bin/sh), C-Shell(/bin/csh), Korn Shell(/bin/ksh), Bourne-Again Shell(/bin/bash)입니다. 많은 개발자들이 C와 유사한 구문 때문에 C-쉘을 사용하지만 이는 주관적인 선택이며, 여기에서는 Korn 쉘만을로 사용합니다. 다른 쉘에서는 구문이 세대로 실행되지 않을 수도 있습니다.

명령행에서 쉘 스크립트를 실행하면 기본 쉘이 사용됩니다. 기본 쉘이 Korn이라면 기술 자료에 있는 스크립트는 구문 오류 없이 실행됩니다. 하지만 스크립트를 실행하기 위해 다른 쉘을 원한다면 어떻게 해야 할까요? 스크립트가 항상 Korn 쉘을 사용해 실행되도록 하려면 사용자의 기본 쉘에만 의존할 수 없습니다. 해결책은 스크립트의 첫 행에 스크립트가 어느 쉘 아래에서 실행될지 표시되는 UNIX 기능을 사용하는 것입니다. 코드 예제 1의 구문은 현재 사용자가 어느 쉘을 사용하든 상관없이 스크립트가 Korn 쉘을 사용해 실행되도록 지시합니다.

#!/bin/ksh

# your script goes here. All lines starting with # 
# are treated as comments
코드 예제 1 - 스크립트가 Korn 쉘에 의해 실행되도록 지정합니다.

일부 문서에서는 표 1에 나타난 것처럼 현재 쉘을 표시하기 위해 다른 명령 프롬프트 기호를 사용합니다. (필자가 가장 선호하는 쉘이 Korn 쉘이기 때문에 본 기술 자료에 나오는 모든 예제는 $-prompt를 사용합니다.) 스크립트가 항상 Korn 쉘을 사용하여 실행되도록 할 수 없기 때문에 각 스크립트의 첫 행으로 #!/bin/ksh를 입력합니다. (본 기술 자료의 $-prompt는 단지 명령이 명령행에 입력되고 있음을 나타냅니다.)

프롬프트 쉘l
$ Bourne 또는 Korn 쉘
% C-shell
# Root login

표 1 - UNIX 프롬프트 기호

스크립트 작성 - 기초


UNIX 스크립트 파일은 DOS BAT 파일과 유사합니다. DOS에서의 프로그래밍 권장 사항과 비권장 사항은 모두 UNIX에도 적용됩니다.

스트립트 작성과 관련된 단계는 다음과 같습니다:

  1. 쉘 프롬프트에서 UNIX 명령을 대화식으로 실행합니다.
  2. UNIX 명령을 포함하는 쉘 스크립트를 작성합니다.
  3. 쉘 스크립트를 실행 가능하도록 만듭니다.
  4. 스크립트를 테스트합니다.
  5. 스크립트를 실행합니다.
    1. 대화식으로
    2. 미래의 어느 일자 및 시간에 단 한 번
    3. 고정된 일정에 따라 반복적으로
    4. HTML 형식 사용

간단한 스크립트 작성


vmstat 정보를 확보하기 위한 스크립트를 작성하고자 한다고 가정해 보십시오. 1분 동안 2초 간격으로 vmstat를 실행하고자 합니다. 위에 설명된 5단계를 사용해 목표를 달성할 수 있습니다.

먼저, man vmstat를 사용해 vmstat에 대한 문서를 조회합니다. 그 다음, 명령을 대화식으로 실행해 구문과 예상되는 출력을 파악합니다. 코드 예제 2는 vmstat를 2초 간격으로 30회 실행하는 구문을 보여줍니다.

$  vmstat  2  30
코드 예제 2 - vmstat 명령을 2초 간격으로 30회 대화식으로 실행

쉘 스크립트 작성


다음으로, 명령을 포함하는 스크립트 파일을 작성합니다. 스크립트 위치와 스크립트 이름을 설명하는 표준을 확립해야 합니다. 예를 들어 회사와 같은 특정 카테고리의 모든 사항을 /usr/local 아래의 하위 디렉토리에 저장합니다. 이 예제에서는 회사를 Acme Products로 가정하므로 디렉토리는 /usr/local/acme입니다. 이 디렉토리 내에 scripts라는 하위 디렉토리와 logs라는 하위 디렉토리를 만드십시오. 목적에 따라 다른 하위 디렉토리가 필요할 수도 있습니다.

다음으로, vi와 같은 텍스트 편집기를 사용해 capture_vmstat.sh라는 스크립트 파일을 작성합니다. EXE, COM, BAT가 실행 가능한 파일을 나타내는 DOS와 달리, UNIX에서는 파일 확장자의 의미가 없습니다. .sh를 확장자로 사용해 쉘 스크립트 파일을 표시할 수 있지만 스크립트를 실행 가능하도록 만들지는 못합니다. 파일에 대한 이 명명 규칙을 통해 보다 쉽고 신속하게 파일을 식별할 수 있습니다. 또한, 파일 이름이 표준을 준수한다면 find 명령을 사용해 특정 유형의 모든 파일을 찾을 수 있습니다.

스크립트 파일은 두 개의 행을 보유합니다. 첫 번째 행은 일말의 여지를 두지 않고 Korn 쉘이 이 스크립트에 있는 명령을 실행하도록 지정합니다. 두 번째 행은 UNIX 명령 그 자체입니다. 코드 예제 3은 capture_vmstat.sh 스크립트의 전체 목록입니다.

#!/bin/ksh

vmstat  2  30
코드 예제 3 - vmstat를 2초 간격으로 30회 실행하는 capture_vmstat.sh 스크립트

쉘 스크립트를 실행 가능하도록 만들기


파일 확장자를 이용해 파일의 실행 가능성 여부를 판단하는 DOS와 달리, UNIX는 파일 접근 권한(file permission)에 의존합니다. chmod 명령은 파일을 실행 가능으로 표시하는 데 사용됩니다.

execute-bit를 설정하는 가장 간단한 방법은 chmod +x capture_vmstat.sh를 사용하는 것입니다. 현업 환경에서는 공개된 서버에서 스크립트에 대한 전체 액세스를 제어하기 위해 소유자, 그룹 및 세계 권한(world permission)을 고려해야 합니다. (파일 접근 권한 주제는 본 문서의 범위를 벗어납니다.) 보다 자세한 정보는 man chmod를 참조하십시오.

쉘 스크립트 테스트


이제 스크립트를 테스트할 준비가 되었습니다. DOS와 달리, UNIX는 실행할 파일을 현재 디렉토리에서 자동으로 찾지 않습니다. UNIX는 PATH 환경 변수를 제공하며 단지 PATH 변수에서 확인된 디렉토리에서 실행 파일을 검색합니다. 대부분의 사람들이 PATH에 현재 디렉토리를 포함시키지 않아(점이 현재 디렉토리를 나타냄) /usr/local/acme/scripts가 PATH에 존재하지 않기 때문에 코드 예제 4의 명령을 입력하는 것만으로는 실행되지 않습니다.

$  cd /usr/local/acme/scripts

$  capture_vmstat.sh
코드 예제 4 - "."이 PATH에 없으면 스크립트가 실행되지 않습니다

경로를 포함하여 스크립트의 전체 파일명을 명시적으로 지정해야 합니다. 나중에 변경되거나 둘 중 하나가 잘못될 가능성이 있으므로 PATH 변수에 의존하지 마십시오. 우선, 스크립트가 있던 디렉토리가 실수로 PATH에서 제거될 수 있으며 이 경우 UNIX는 더 이상 스크립트를 찾지 못할 것입니다. 심지어 UNIX는 새로운 PATH에 있는 다른 디렉토리에서 동일한 이름을 가진 스크립트를 찾아 실행할 수도 있습니다. 그러므로 안전을 위해서는 코드 예제 5에서처럼 전체 파일명을 지정하여 스크립트를 실행해야 합니다.

$  /usr/local/acme/scripts/capture_vmstat.sh
코드 예제 5 - UNIX가 올바른 스크립트를 찾을 수 있도록 전체 파일명 지정

일일이 입력하기가 번거로우므로 "."(점)이 현재 디렉토리를 나타낸다고 가정합니다. 우선, 스크립트 디렉토리로 변경한 다음 코드 예제 6에서처럼 스크립트명에 "./"(점-슬래시)를 덧붙여 스크립트를 실행합니다. 스크립트 하나만 실행하는 경우에는 별 차이가 없지만 스크립트 디렉토리에서 여러 개의 스크립트를 실행하는 경우에는 디렉토리명을 한 번만 입력하면 되는 장점이 있습니다.

$  cd /usr/local/acme/scripts

$  ./capture_vmstat.sh
코드 예제 6 - 점-슬래시(./) 표기를 사용해 스크립트 실행

capture_vmstat.sh 스크립트를 어떤 방법으로 호출하든 간에, vmstat를 대화식으로 실행할 때 얻은 결과와 출력이 동일해야 합니다.

스크립트 실행


이제 스크립트가 작성되었고 그 작동 방식을 알고 있습니다. 스크립트를 다음 네 가지 방법으로 실행할 수 있습니다:

1.대화식


스크립트를 문서화하여 다른 사람(헬프 데스크 직원 등)이 스크립트 파일을 실행할 수 있도록 합니다. DOS 사용자가 그들을 위해 만들어진 BAT 파일을 사용하기 위해 DOS 명령이나 구문을 이해할 필요가 없는 것과 매한가지로, 스크립트를 실행하는 사람들이 UNIX 명령이나 구문을 알아야 할 필요는 없습니다.

2.at 명령 사용


at 명령을 사용해 향후 언젠가 한번 스크립트를 실행합니다. 자세한 내용은 man at을 확인하십시오. 일부 UNIX 시스템은 사용자가 로그아웃하면 at-jobs 실행을 취소합니다. 시스템 문서를 신중하게 확인합니다.

3.cron 유틸리티 사용


crontab 파일을 사용해 고정된 일정에 따라 스크립트를 반복적으로 실행합니다. 자세한 내용은 man crontab을 확인합니다. 코드 예제 7은 월/수/금요일마다 오전 8시-오후 5시까지 한 시간에 한번 X시 10분에 스크립트를 실행하는 간단한 crontab 입력을 보여줍니다:

10   8-17   *   *  1,3,5  /usr/local/acme/scripts/capture_vmstat.sh
코드 예제 7 - capture_vmstat.sh를 실행하는 crontab 입력 script

스크립트를 실행하기 위한 네 번째 방법으로 넘어가기 전에, crontab을 통해 스크립트를 실행할 경우 생기는 두 가지 문제를 이해해야 합니다. 첫째, 스크립트가 실행될 때 로그인하지 않았기 때문에 기본 쉘이 되는 Korn 쉘에 의존할 수 없습니다. 그러므로, 코드 예제 1에 설명된 것처럼 #!/bin/ksh를 스크립트의 첫 행으로 사용하도록 해야 합니다. 둘째, 현재 버전의 스크립트는 터미널로 출력을 전송합니다. cron이 스크립트를 실행할 때 터미널이 없으므로, cron은 stdout의 경로를 다른 곳으로 재지정해야 합니다. 정상적인 위치는 crontab으로 스크립트를 실행한 사용자의 e-메일 수신함(inbasket)입니다. 이 방법도 괜찮지만, 기본 스크립트를 확장할 때 아래에 설명된 다른(더 나은) 해결책을 사용할 수 있습니다.

4.HTML 형식 사용


HTML 형식을 사용해 스크립트를 실행하고 CGI(common gateway interface)를 통해 스크립트를 게시합니다. 명령의 출력은 브라우저로 다시 전송되므로 <PRE>와 </PRE> HTML 태그는 서식을 보존하는 데 사용되어야 합니다.

이 HTML 형식 메소드는 여기서 설명한 것보다 많으며, FORM과 CGI를 사용할 경우 수많은 보안 위험이 존재합니다. 그러나, 이 메소드는 사내 헬프 데스크 직원이나 기타 레벨1 지원 인력이 사용하기에 매우 성공적인 것으로 입증되었습니다.

간단한 스크립트 확장


이전 스크립트는 새로운 프로그래밍 언어를 배울 때 작성되는 최초의 표준 프로그램인 "hello, world"의 쉘 스크립트 버전이었습니다. 이제 몇 가지 기본 기능을 여기에 추가할 수 있습니다.

stdout 경로 재지정


먼저, 스크립트는 출력을 stdout으로 전송합니다(정상적으로는 터미널임). 스크립트를 확장해 코드 예제 8에서처럼 출력 경로를 로그 파일로 재지정할 수 있습니다.

#!/bin/ksh

vmstat  2  30  >  /usr/local/acme/logs/vmstat.log
코드 예제 8 - stdout 경로를 파일로 재지정

그러나 이로 인해 몇 가지 새로운 문제가 발생합니다. 우선, 스크립트를 실행할 때마다 마지막 로그 파일의 내용을 덮어쓰게 됩니다.+ 이 문제를 해결하려면 기존 로그 파일의 끝에 새로운 출력을 덧붙입니다. 파일에 있는 date-time stamp는 마지막 로그가 작성된 시점만을 표시하므로 이제 로그에 있는 각 출력이 작성된 시점을 알아야 합니다.

스크립트 내 하위 명령 실행

스크립트의 각 실행보다 앞서는 파일에 현재의 일자와 시간을 기록합니다. 기존 파일을 덮어쓰는 대신 >>를 사용해 파일 끝에 출력을 덧붙입니다. 코드 예제 9에서, find 및 find-next를 사용해 파일을 검사하기 쉽도록 독립적으로 파악할 수 있는 문자를 열 1에 놓습니다. 또한 로그 파일에 현재의 일자와 시간을 기록할 수도 있습니다. 코드 예제 9 $(date)는 Korn 쉘이 date 명령을 실행하고 출력을 echo 명령행으로 배치하도록 지시합니다. UNIX 명령을 실행하고 출력을 사용하려고 할 때마다 $를 입력하고 괄호 안에 명령을 넣으십시오.

#!/bin/ksh

echo "#--- $(date)"  >> /usr/local/acme/logs/vmstat.log

vmstat  2  30	>> /usr/local/acme/logs/vmstat.log
코드 예제 9 - 로그 파일에 stdout 추가

코드 예제 10에서 Korn 쉘은 netstat 명령, grep for ESTABLISH를 실행하고, 이들 명령을 $(xxx) 안에 넣어 행 수를 세는 데 wc를 사용하도록 지정될 수 있습니다. 나아가 Korn 쉘은 이러한 명령의 출력을 환경 변수 CTR_ESTAB에 저장하도록 지시됩니다. 그 다음, echo 명령에서 Korn 쉘은 해당 환경 변수에 저장된 값을 사용하도록 지시됩니다. 환경 변수에 저장된 값을 사용하려면 변수 이름 앞에 $를 넣습니다(예: $CTR_ESTAB). 가독성을 높이고 모호성을 방지하려면 중괄호 안에 변수 이름을 넣는 Korn 쉘 옵션을 사용합니다(예: ${CTR_ESTAB}).

# store current date as YYYYMMDD in variable DATE for later 
# use

export DATE=$(date +m%d)

# count number of established socket connections and write. 
# to log

export CTR_ESTAB=$(netstat -na -P tcp | grep ESTABLISH | wc 
  -l)

export CTR_CLOSE_WAIT=$(netstat -na -P tcp | grep CLOSE WAIT 
  | wc -l)

echo "${DATE} ${CTR_ESTAB} ${CTR_CLOSE_WAIT} >> ${LOG_FILE}
코드 예제 10 - $(xxx)를 사용해 Korn 쉘 스크립트 내 명령 실행

고유 파일명 생성


여러 사용자가 스크립트를 동시에 실행하면 어떤 일이 발생할까요? 스크립트의 각 인스턴스는 동일한 출력 파일에 기록할 것이므로, 각 스크립트의 출력은 출력 파일에 인터리브됩니다. 코드 예제 11에서처럼 파일 이름에 PID 번호($$로 표현)를 넣어 고유한 출력 파일명을 작성할 수 있습니다.

#!/bin/ksh

echo "#--- $(date)" 
  >> /usr/local/acme/logs/vmstat.$$.log

vmstat  2  30	>> /usr/local/acme/logs/vmstat.$$.log
코드 예제 11 - $$를 사용해 현재 PID를 사용하는 고유한 파일명 생성

다음 사용자가 스크립트를 실행할 때 다른 PID가 스크립트 실행에 할당되기 때문에 기존 로그 파일에 추가되는 것이 아니라 매번 별도의 로그 파일을 작성하게 됩니다 잘못된 것은 아니지만 이런 결과를 원하지도 않았습니다.

스크립트가 실행될 때마다 값이 변경되는 환경 변수를 사용하는 대신 스크립트 실행 이전에 스크립트 외부에서 한 번 설정된 환경 변수를 사용하는 방법도 생각해볼 수 있습니다. UNIX는 사용자가 로그인할 때마다 LOGNAME 환경 변수를 설정합니다. 코드 예제 12에서, 이 값은 각 사용자가 로그 파일을 가질 수 있도록 로그 파일명에 들어갑니다:

#!/bin/ksh

echo "#--- $(date)"	
  >> /usr/local/acme/logs/vmstat.${LOGNAME}.log

vmstat  2  30		
  >> /usr/local/acme/logs/vmstat.${LOGNAME}.log
코드 예제 12 - 값이 외부에서 설정된 환경 변수를 사용해 파일명 생성

구조적 프로그래밍 기법


두 번의 최종 마무리 점검을 거쳐 기본 Korn 쉘 스크립트를 완료합니다. 첫째, vmstat 명령의 빈도 또는 기간을 변경하고자 하는 경우 어떻게 될까요? vmstat 명령의 간격과 기간을 하드 코딩(hard-coding)하는 대신 명령행 인수를 사용해 해당 값을 받아들일 수 있습니다. 이러한 인수는 vmstat 명령이 인수를 액세스할 수 있는 환경 변수에 저장될 수 있습니다. 물론, 사용자가 명령행을 사용해 값을 제공하지 않는 경우 스크립트는 기본값을 제공해야 합니다.

둘째, 로그 파일 명명 규칙에 대한 생각을 변경하면 어떻게 됩니까? 명명 규칙은 사용자에게 명령행 인수를 사용할 때마다 제공할 것을 요구하는 사항이 아닙니다. 그러나, 스크립트의 여러 행에 하드 코딩된 로그 파일명이 있을 경우 다른 명명 규칙을 사용하기로 결정하면 이름이 지정된 위치를 확인하기 위해 스크립트의 모든 행을 검색해야 합니다.

그 대신, 환경 변수에 로그 파일명을 저장하고 변수에 포함된 파일명에 출력을 덧붙이도록 각 명령을 수정하십시오. 그러면 로그 파일 명명 규칙을 변경할 때 환경 변수가 설정된 한 행을 수정하기만 하면 됩니다.

#!/bin/ksh
# ----------------------------------------------------
# capture_vmstat.sh	<INTERVAL> <COUNT>
#	<INTERVAL> vmstat interval
#	<COUNT>	vmstat count
# run vmstat and capture output to a log file
#-----------------------------------------------------

# indicate defaults for how often and for how long 
# to run vmstat
export INTERVAL=2		# every 2 seconds
export COUNT=30		# do it 30 times

# obtain command line arguments, if present
if [ "${1}" != "" ]
then
	INTERVAL=${1}
	# if there is one command line argument, 
	# maybe there's two
	if [ "${2}" != "" ]
	then
	COUNT=${2}
	fi
fi

# directories where scripts and logs are stored
export PROGDIR=/usr/local/acme/scripts
export LOGDIR=/usr/local/acme/logs

# define logfile name and location
export LOG_FILE=${LOGDIR}/capture_vmstat.${LOGNAME}.log

# write current date/time to log file
echo "#--- $(date)"		>> ${LOG_FILE}
vmstat  ${INTERVAL}  ${COUNT}	>> ${LOG_FILE}

# say goodnight, Gracie
exit 0
코드 예제 13 - capture_vmstat.sh 스크립트의 더욱 강력한 버전

for-loop 스크립트 작성


객체 목록에 대해 단일 명령을 실행하고자 하는 경우가 있습니다. 예를 들어, rsh 명령을 사용해 여러 서버에 대해 동일한 명령을 원격으로 실행하려 할 수도 있습니다(자세한 내용과 r-명령을 사용할 때의 보안 위험에 대해서는 man rsh를 참조합니다). .

한 가지 기법은 환경 변수에 LIST라고 하는 객체 목록을 저장하는 것입니다. 그러면 for loop를 사용해 rsh 명령을 반복적으로 실행할 수 있으며, 각 루프는 LIST에 다음 값을 보유하게 됩니다. 코드 예제 14는 for-loop 스크립트 샘플을 보여줍니다.

#!/bin/ksh

export LIST="bvapp1 bvapp2 bvapp3"

export LOG=/usr/local/acme/logs/throw_away.log

for SERVER in ${LIST}
do
  # each loop has a different value for ${SERVER}
  echo "#------- values from ${SERVER}" >> ${LOG}
  rsh  ${SERVER} 
  "ps -f -u bv -o pid,pmem,pcpu,rss,vsz" >> ${LOG}
done

# say goodnight, Gracie
exit 0
코드 예제 14 - 간단한 for-loop 스크립트

while-loop 스크립트 작성


경우에 따라 단일 명령을 실행하고 잠시 기다린 다음 명령을 다시 실행하기를 원할 수도 있습니다. 때로는 이 루프가 무제한 계속되기를 원할 수도 있고 때로는 루프가 한정된 횟수 만큼 실행된 다음 종료되기를 원합니다.

사용자 bv 아래에서 실행되는 프로세스를 모니터링하려고 하며 2시간 동안 10분마다 bv를 모니터링하기를 원한다고 가정해 보겠습니다. 우선, 코드 예제 15에 나오는 코드를 사용해 명령을 대화식으로 테스트합니다(자세한 내용은 man ps를 참조합니다):

ps  -f -u bv  -o  pid,pcpu,pmem,rss,vsz,comm
코드 예제 15 - -o 인수를 사용하는 대화식 ps 명령

이제 이 명령을 루프에서 실행하는 스크립트 파일을 작성해야 합니다. 루프는 ps 명령 실행 간의 10초 동안 일시 정지하고 720회 실행해야 합니다[2시간 동안 10초마다 한번, 즉 분당 6회 또는 시간당 360회(60분/시 * 6/분)]. 코드 예제 16은 간단한 while-loop 스크립트를 보여줍니다.

#!/bin/ksh

export INTERVAL=10
export COUNT=720

export LOG=/usr/local/acme/logs/while_loop_test.log

export CTR=0
while [ true ]
do
	if [ ${CTR} -ge ${COUNT} ]
	then
		exit
	fi
	echo "#------- $(date +m%d-03/24/03M%S)"	
          >> ${LOG}
	ps  -f  -u  bv  -o  pid,pcpu,pmem,rss,vsz,comm	
          >> ${LOG}
	CTR=$(expr ${CTR} + 1)
	sleep ${INTERVAL}
done
코드 예제 16 - 간단한 while-loop 스크립트

코드 예제 17은 출력 로그 파일의 일부분을 보여줍니다.

#------- 19991203-123237
  PID %CPU %MEM  RSS  VSZ COMMAND
12007  0.2  0.8 13640 24280 cmsdb
11938  0.0  0.7 11536 20496 sched_poll_d
<snip>
#------- 19991203-123240
  PID %CPU %MEM  RSS  VSZ COMMAND
12007  0.2  0.8 13640 24280 cmsdb
11938  0.0  0.7 11536 20496 sched_poll_d
<snip>
#------- 19991203-123243
  PID %CPU %MEM  RSS  VSZ COMMAND
12007  0.3  0.8 13640 24280 cmsdb
11938  0.0  0.7 11536 20496 sched_poll_d
<snip>
#------- 19991203-123246
<and-so-on>
코드 예제 17 - while-loop 스크립트의 출력

퀵 레퍼런스 카드(Quick Reference Card)


아래 프로그래밍 팁과 기법은 본 기술 자료에 제시된 프로그래밍 스타일과 방법론에 대한 퀵 레퍼런스로서 여기에서 다룬 주제에 대한 퀵 레퍼런스 버전을 확인할 수 있을 것입니다.

1. 항상 다음과 같은 행으로 스크립트를 시작합니다


#!/bin/ksh

2. 항상 변수를 정의할 때 대문자를 사용합니다. 소문자를 사용해 단어를 분리합니다.


BIN_DIR=/opt/bv1to1/bin

3. 하위 프로세스가 값을 자동으로 액세스하도록 항상 환경 변수를 익스포트합니다:


export SUPPORT_IDS="userA@domain.com,userB@domain.com

4. UNIX 명령을 실행하고 Korn 쉘 스크립트의 어딘가에 출력을 사용하려면 $를 입력하고 괄호 안에 명령을 넣은 다음 출력을 환경 변수에 저장합니다.


export CTR_ESTAB=$(netstat -na | grep ESTABLISH | wc -l)

5. 환경 변수에 저장된 값을 사용하려면 변수명 앞에 $를 넣습니다. 가독성을 높이고 모호성을 방지하려면 중괄호 안에 변수 이름을 넣습니다.


echo "The number of ESTABLISHED connections is ${CTR_ESTAB}"

6. 고유한 파일명을 갖게 하려면 $$를 사용해 파일명에 PID 번호를 포함시킵니다. 파일 확장자 바로 앞의 파일명에 PID 번호를 삽입합니다:


export LOG_FILE=/tmp/capture_vmstat.$$.log

7. chmod +x 파일명을 사용해 스크립트 파일을 실행 가능하도록 만듭니다.


chmod  +x  capture_vmstat.sh

8. 스크립트가 현재 디렉토리에 있다는 것을 UNIX가 알 수 있도록 스크립트 이름 앞에 점-슬래시(./)를 넣습니다.


./capture_vmstat.sh

9. stdout ( > )의 경로를 로그 파일로 재지정하거나 stdout ( >> )을 로그 파일에 덧붙입니다.


./capture_vmstat.sh >> ${LOG_FILE}

10. stderr의 경로를 stdout과 동일한 대상 또는 고유한 파일로 재지정합니다.


./capture_vmstat.sh  >> ${LOG_FILE}  2>&1

- or -

./capture_vmstat.sh  >> ${LOG_FILE}  2>>${ERR_LOG}

11. for-loop를 사용해 목록을 처리합니다.


export LIST=$(ls *sh)
for FILE in ${LIST}
do
	echo "Processing ${FILE}"
	cat ${FILE} | mailx -s "Here is ${FILE}" 
          userA@domain.com
done

Use the while-loop to process the same command 
  repeatedly.
export INTERVAL=20
export COUNT=180

export CTR=0
while [ true ]
do
if [ ${CTR} -ge ${COUNT} ]
	then
		exit
	fi
	# --- do some command here ---
	sleep ${INTERVAL}
	      CTR=$(expr ${CTR} + 1) 
done

참조 자료


UNIX Shell Programming (Hayden Books UNIX System Library)


필자: Stephen G. Kochan, Patrick H. Wood
페이퍼백 - 490페이지
2번째 개정판(1990년 1월)
Hayden Books; ISBN: 067248448X

필자 약력


켄 코트리(Ken Gottry)는 현재 NerveWire, Inc.의 수석 인프라 아키텍트로 근무하고 있으며, 메인프레임에서 데스크탑에 이르는 시스템 부문에서 30년 간 경력을 쌓았습니다. 지난 10년 동안 그는 분산, 다계층 및 웹 기반 시스템의 설계, 구현, 튜닝 업무에 전념해 왔습니다. 또한, 수많은 G2K 업체에 자문을 제공하는 성능 엔지니어로서 웹 서버, 애플리케이션 서버, Solaris상에서 실행되는 JVM을 평가하고 튜닝했습니다.

켄의 기술 자료는 썬의 개발자 웹 사이트에 게재되었던 내용이며, 최근 SysAdmin 매거진에서 Solaris 성능 튜닝에 대한 기술 자료도 발표됐습니다.

+ Recent posts