기존의 ASP 프로그램을 이용한 간단한 스케줄링 잡(Scheduling Job) 설정

등록일시: 2003-02-21 10:31,  수정일시: 2013-10-26 12:21
조회수: 19,862
본문은 최초 작성된 이후, 약 10년 이상 경과한 문서입니다. 따라서, 일부 내용은 최근의 현실과 맞지 않거나 동떨어져 있을 수 있으며 문서 내용에 오류가 존재할 수도 있습니다. 또한, 본문이 작성되던 당시의 필자의 의견과 현재의 의견에 많은 차이가 존재할 수도 있습니다. 이 점, 참고하시기 바랍니다.

실무에서 ASP를 사용해서 프로그래밍 작업을 하다보면, 주기적으로 발생하는 업무를 처리하거나 대상 시스템이나 데이터가 특정 조건을 만족하는지 점검하기 위한 스케줄링 잡(Scheduling Job)이 요구되는 경우가 종종 발생하곤 한다. 가령, 매일 아침 특정 시간대에 사용자에게 메일 발송을 한다던가, 매달 말일에 데이터베이스의 상태를 조사해서 여유 공간 상황을 점검한다던가 하는 등과 같은 경우를 말하는 것이다.

보통 ASP 프로그래머 본인이나 팀의 동료가 기타 프로그래밍 언어를 사용해서 NT 서비스 프로그램 같은 보다 고급의 프로그래밍이 가능한 경우라면 해당 인력이 요구 사항을 만족하는 적절한 스케줄링 프로그램을 제작하면되므로, 그나마 그렇지 않은 경우에 비해 상황이 좋은 편이라고 말할 수 있을 것이다. 그러나, 우리 주변에서 흔히 찾아볼 수 있는 소규모의 웹 관련 업체에서는 이를 만족하는 인력을 구하기가 현실적으로 쉽지 않은 것도 사실이고, 그렇다고 결코 적지 않은 금액을 들여서 별도의 스케줄링 프로그램을 구매하거나 외부 인력을 고용하는 것도 부담이 많이 되는 일이다. 이런 상황에서 별도의 스케줄링 프로그램을 구매하거나 자체적으로 따로 제작할 필요 없이, ASP 프로그래머 스스로 기존의 ASP 프로그램 파일과 운영체제에서 기본 제공해주는 스케줄링 기능만으로도 이런 요구사항을 매우 간단하게 해결할 수 있는 방법이 있음에도 불구하고 의외로 아직까지 그 방법을 모르고 있는 분들이 많이 계신 것 같아 그 요령을 소개하고자 한다.

결론부터 얘기하자면, 본문에서 살펴볼 방법은 WSH(Windows Scripting Host)를 이용하는 방법이다. 그러나, 반드시 WSH에 관해서 잘 알고 있어야만 사용할 수 있는 방법은 아니고, ASP 프로그램만 어느 정도 능숙하게 작성할 수 있어도 무리 없이 사용할 수 있는 수준의 작업이므로 미리 걱정부터 할 필요는 없다. 물론, WSH에 능숙할수록 더욱 다양한 응용이 가능할 것이라는 점은 두말 할 나위가 없을 것이다.

글의 편의를 위해서 다음과 같은 상황을 가정해보도록 하자. 사내의 모든 직원들이 파일 서버의 용도로 사용하고 있는 Windows 2000 서버가 한 대 있으며, 이 서버에는 이미 대용량의 하드디스크 드라이브가 장착되어 있기는 하지만, 계속되는 사용자의 증가와 그 사용자들이 저장하는 대량의 파일들로 인해 여유 공간이 기하급수적으로 줄어들고 있다. 그에 따라 관리자가 하드디스크 드라이브의 여유 공간에 대한 지속적인 모니터링을 요구하기에 이르렀으며, 매일 새벽 6시 마다 사용자들에게 할당된 폴더의 용량을 조사하고 만일 총 100MB 이상의 공간을 사용하고 있는 사용자들이 발견되는 경우에는 SMTP 서비스를 이용해서 자동적으로 그 사용자들의 목록을 여러분들에게 전송하도록 해야 하는 상황이라고 가정해보자.

이 상황에서 요구되고 있는 여러 가지 조건들은 일견하기에는 매우 복잡한 것처럼 느껴질 수도 있겠지만, 한 번 차분하게 살펴본다면 매일 새벽에 주기적으로 실행되어야 한다는 점만 제외한다면 ASP 프로그램만으로도 충분히 구현이 가능한 작업이라는 사실을 쉽게 알 수 있을 것이다.

각각의 사용자들이 사용하고 있는 파일 서버의 하드디스크 드라이브 용량은 FileSystemObject 객체를 이용하면 상당히 손쉽게 조사할 수 있으며, SMTP 서비스를 사용해서 조건을 만족하는 사용자들의 정보를 메일로 보내는 작업도 CDONTS 객체를 이용하면 그리 어렵지 않은 작업이다. 특정 사용자가 사용하고 있는 공간이 제한된 용량을 넘었을 경우, .mp3 파일이나 .tmp 파일 같이 회사 정책과 맞지 않거나 쓸모 없는 파일들을 자동으로 삭제하는 등의 추가 기능을 구현하는 것도 그다지 어려운 일이 아니다. 결국, ASP 프로그래머들에게 문제가 되는 부분은, 단지 이 작업이 매일 새벽 6시 마다 자동적으로 실행되어야 한다는 점 뿐이다. 왜냐하면, ASP 프로그램을 비롯한 모든 유형의 웹 프로그램은 사용자가 웹 브라우저를 사용해서 웹 서버로 전송하는 리퀘스트(Request)를 통해서 실행되는 것이 일반적인데, 지금과 같이 웹 프로그램이 자동적으로 실행되어야 하는 상황에서는 리퀘스트를 전송할 사용자 자체가 존재하지 않는 상태나 마찮가지므로 웹 프로그램으로서는 가장 기본적인 개념 자체가 성립되지 않기 때문이다.

따라서, 기존의 ASP 프로그램을 활용하면서 이 문제를 해결하기 위해서는 다음과 같은 두 가지 방법 중 하나를 선택해야만 한다. 첫 번째 방법은 사용자 대신 어떤 프로그램이 지정된 시간 또는 조건에 지정한 URL을 인자로 웹 브라우저를 호출해서 ASP 프로그램을 실행시키는 것이다. 물론, 여기에서 어떤 프로그램이란 당연히 스케줄링 프로그램을 말하는 것이다. 이 방법은 매우 쉽고 별달리 어려운 점도 없어 보이는데 사실 실제로도 그렇다. 다만, 몇 가지 주의 사항을 가지고 있으며 이에 관해서는 나중에 다시 설명하기로 한다.

두 번째 방법은 기존의 ASP 프로그램을 다른 언어를 사용해서 다시 작성하거나 변형한 다음, 스케줄링 프로그램을 사용해서 지정된 시간 및 조건에 실행시키는 것이다. 그러나, 이 두 번째 방법도 한 가지 문제점을 갖고 있다. 뭐냐하면, 이 글은 애초에 ASP 프로그램만 작성할 수 있는 프로그래머들을 대상으로 하고 있다는 점이다. 즉, 기본적으로 다른 프로그램 언어를 사용해서 동일한 프로그램을 손쉽게 작성할 수 없는 상황이라고 가정하고 있기 때문에 조건 자체가 성립되지 않는 것이다.

그러나, 만약 일단 ASP 프로그램을 사용해서 필요한 작업을 처리한다는 기분으로 적절한 ASP 프로그램을 작성한 후, 별도의 도구나 기술 없이도 약 10여분 정도의 시간만 투자해서 손쉽게 Windows 기반의 프로그램으로 변환할 수 있는 방법이 있다면? 더군다나, 그 프로그램이 ASP 프로그램 같이 VBScript를 사용하는 프로그램이라면? 그렇다면 필자는 아마도 이 두 번째 방법이 가장 합리적인 방법이 될 것이라고 생각한다. 그리고, 이 글에서는 바로 그러한 방법에 대해서 얘기하고자 한다.

따라서, 우선 지금은 두 번째 방법에 따라 일단 ASP 프로그램을 사용해서 필요한 모니터링 작업을 처리한다는 기분으로 실제 작업을 수행하는 ASP 프로그램을 제작하는 일에만 관심을 집중해보기로 하자. 먼저, 파일 서버와 웹 서버는 각각 별도로 운영되고 있으며, 웹 서버 쪽에서는 네트워크 드라이브를 통해서 파일 서버의 공유 폴더에 접근한다고 생각하도록 하겠다. 그리고, 각각의 사용자가 사용하는 파일 서버상의 개인 폴더는 사용자의 아이디와 동일한 이름을 갖고 있다고 가정한다.

다음 샘플 코드는 이런 상황을 고려하여 필자가 작성한 모니터링 작업용 ASP 프로그램이다. 아마도 실제 업무 현장에서는 이보다 훨씬 다양하고 보다 치밀한 코드가 요구될 것이다. 그러나, 이 글에서 얘기하고자 하는 주제는 이 코드 자체가 아니라 이 코드를 사용해서 스케줄링 작업을 처리하는 방식에 관한 것이므로 코드 그 자체에 너무 얽매이지는 말기 바란다.

<%

  '******************************************************
  '* 변수 및 상수를 선언한다.
  '******************************************************
  
  Const SHARED_FOLDER_PATH  = "z:\shared root"          '** 파일 서버의 네트워크 드라이브 경로
  Const ADMIN_EMAIL_ADDRESS = "admin@mydomain.co.kr"    '** 결과를 받을 E-Mail 주소
  Const cdoBodyFormatHTML   = 0
  Const cdoMailFormatMIME   = 0
  
  Dim objFSO
  Dim objFolder
  Dim objSubFolder
  Dim objSubFolders

  Dim objMail
  Dim strResult
  

  '******************************************************
  '* 사용자별 하드디스크 사용량을 조사한다.
  '******************************************************

  Set objFSO = Server.CreateObject("Scripting.FileSystemObject")
  Set objFolder = objFSO.GetFolder(SHARED_FOLDER_PATH)
  Set objSubFolders = objFolder.SubFolders

  strResult = ""
  For Each objSubFolder In objSubFolders
    '** 편의상 해당 폴더의 Byte 크기를 1000000 으로 나눈 후
    '** 그 값이 100 보다 크면 사용량이 100 MB 를 초과한다고 생각한다.
    If objSubFolder.Size / 1000000 > 100 Then
      strResult = strResult & "- " & objSubFolder.Name & ", "
      strResult = strResult & FormatNumber(objSubFolder.Size, 0) & " Byte<br><br>"
    End If
  Next

  Set objSubFolders = Nothing
  Set objFolder = Nothing
  Set objFSO = Nothing


  '******************************************************
  '* 사용량 초과자가 존재하는 경우, 메일을 발송한다.
  '******************************************************

  If Trim(strResult) <> "" Then
    Set objMail = Server.CreateObject("CDONTS.NewMail")
    With objMail
      .From = ADMIN_EMAIL_ADDRESS
      .To   = ADMIN_EMAIL_ADDRESS
      .Subject = "[" & Now() & "] 파일 서버 사용량 초과자 명단"
      .Body = strResult
      .BodyFormat = cdoBodyFormatHTML
      .MailFormat = cdoMailFormatMIME
      .Send
    End With
    Set objMail = Nothing
  End If
  
%>

코드를 살펴보면 쉽게 알수 있겠지만 상당히 일반적이고 평범한 수준의 루틴들로만 이루어져 있다. 특별한 기술을 사용했다거나 ASP 고유의 기능 외에 다른 기능을 사용하는 부분은 전혀 존재하지 않는다. 그러면, 이제 앞에서 얘기했던 것처럼 이 ASP 프로그램을 VBScript 기반의 그 어떤 다른 프로그램, 즉 WSH 프로그램으로 변환해보자. 우선 <%%>를 모두 제거하고, 파일의 확장자를 .asp에서 .vbs로 변경한다. 그리고, 마지막으로 Server.CreateObject() 메서드를 모두 CreateObject() 함수로 바꾼다. 별로 바뀐 점이 없는 것 같지만 이것만으로도 ASP 프로그램을 WSH 프로그램으로 변환하는 과정이 모두 끝났다.

다만 한 가지 주의해야 할 점은, 이 방식으로 ASP 프로그램을 WSH 프로그램으로 변환할 때는 ASP의 여섯 가지 기본 객체, 즉 Server 객체, Session 객체, Request 객체, Response 객체, ObjectContext 객체, ASPError 객체를 사용하면 안된다는 점이다. 왜냐하면 ASP의 기본 객체는 말 그대로 ASP 환경 내부에서만 사용할 수 있는 내부 객체이기 때문에 ASP 환경 외부에서는 사용이 불가능하기 때문이다.

따라서, 반드시 예제에서처럼 Server.CreateObject() 메서드는 CreateObject() 함수로 대체해줘야 하고, 상황에 따라 인자값 입력이 필요한 경우에도 Request 객체의 Form 속성이나 QueryString 속성 대신 WSH에서 제공해주는 WScript 객체의 Arguments 속성을 사용해야 한다. 또한, 오류 처리를 위해서도 ASPError 객체 대신 VBScript의 표준 오류 처리 객체인 Err 객체를 사용해야 한다. 그러나, 현실적으로 스케줄링을 위한 프로그램에서는 COM 컴포넌트 객체의 인스턴스 생성을 위한 CreateObject() 함수 이외의 것들은 그 사용 빈도가 매우 낮은 편이므로 필자의 사견으로는 이에 대해서 크게 신경쓰지 않아도 될 것 같다는 생각이다.

다음은 이와 같이 변환을 마친 WSH 프로그램의 전체 코드이다. 이 WSH 프로그램을 monitor.vbs라는 이름의 파일로 C:\ 밑에 저장했다고 가정하도록 하겠다. 비록, WSH 프로그램으로 변환을 했다고는 하지만, 코드 자체는 거의 바뀐 내용이 없다는 점을 쉽게 알 수 있다.

  '******************************************************
  '* 변수 및 상수를 선언한다.
  '******************************************************
  
  Const SHARED_FOLDER_PATH  = "z:\shared root"          '** 파일 서버의 네트워크 드라이브 경로
  Const ADMIN_EMAIL_ADDRESS = "admin@mydomain.co.kr"    '** 결과를 받을 E-Mail 주소
  Const cdoBodyFormatHTML   = 0
  Const cdoMailFormatMIME   = 0
  
  Dim objFSO
  Dim objFolder
  Dim objSubFolder
  Dim objSubFolders

  Dim objMail
  Dim strResult
  

  '******************************************************
  '* 사용자별 하드디스크 사용량을 조사한다.
  '******************************************************

  Set objFSO = CreateObject("Scripting.FileSystemObject")
  Set objFolder = objFSO.GetFolder(SHARED_FOLDER_PATH)
  Set objSubFolders = objFolder.SubFolders

  strResult = ""
  For Each objSubFolder In objSubFolders
    '** 편의상 해당 폴더의 Byte 크기를 1000000 으로 나눈 후
    '** 그 값이 100 보다 크면 사용량이 100 MB 를 초과한다고 생각한다.
    If objSubFolder.Size / 1000000 > 100 Then
      strResult = strResult & "- " & objSubFolder.Name & ", "
      strResult = strResult & FormatNumber(objSubFolder.Size, 0) & " Byte<br><br>"
    End If
  Next

  Set objSubFolders = Nothing
  Set objFolder = Nothing
  Set objFSO = Nothing


  '******************************************************
  '* 사용량 초과자가 존재하는 경우, 메일을 발송한다.
  '******************************************************

  If Trim(strResult) <> "" Then
    Set objMail = CreateObject("CDONTS.NewMail")
    With objMail
      .From = ADMIN_EMAIL_ADDRESS
      .To   = ADMIN_EMAIL_ADDRESS
      .Subject = "[" & Now() & "] 파일 서버 사용량 초과자 명단"
      .Body = strResult
      .BodyFormat = cdoBodyFormatHTML
      .MailFormat = cdoMailFormatMIME
      .Send
    End With
    Set objMail = Nothing
  End If

이제 저장된 monitor.vbs 파일을 마우스로 더블 클릭해보기 바란다. 프로그램에 오류가 없다면 모든 루틴들이 정상적으로 실행되고 우리가 원하는 작업을 정확하게 끝마칠 것이다.

그런데, 예제 프로그램을 실행시켜 보면 알겠지만 현재 상태의 프로그램 코드에는 그래픽적인 요소가 하나도 없기 때문에 언제 시작되고 언제 끝났는지 전혀 알 방법이 없다. 따라서, 프로그램의 실행 결과를 확인하려면 언제나 메일이 발송됐는지 여부를 일일이 확인해야만 하기 때문에 상당히 불편하다. 이처럼 때로는 편리를 위해서나 디버깅 목적으로나 프로그램이 실행되고 끝마치는 과정을 눈으로 직접 확인하고 싶은 경우가 많다.

이런 경우에는 ASP 프로그램에서 Response.Write() 메서드를 사용해서 일종의 상태 추적(Trace)을 했던 것 같이, 다음 코드에서 볼 수 있는 것처럼 VBScript에서 제공해주는 MsgBox() 함수나 WSH에서 기본적으로 제공해주는 WScript 객체의 Echo() 메서드를 프로그래머가 원하는 위치에 추가해서 그 실행 과정을 추적할 수 있다. 즉, WSH 프로그램은 어디까지나 클라이언트 상에서 실행되는 프로그램이므로 ASP 프로그램에서는 사용이 불가능했던 MsgBox() 함수까지도 자유롭게 사용할 수 있는 것이다.

  ... 생략 ...
  
      .MailFormat = cdoMailFormatMIME
      .Send
    End With
    Set objMail = Nothing
  End If
  
  MsgBox "실행이 완료되었습니다."
  '** 또는
  WScript.Echo "실행이 완료되었습니다."

다음 두 그림은 각각 MsgBox() 함수와 WScript.Echo() 메서드를 사용해서 예제 프로그램의 종료 직전에 동일한 메세지를 출력한 결과이다. 단지 메세지 박스의 타이틀 부분만 제외한다면 두 가지 결과가 완벽하게 일치하는 것을 볼 수 있다. 그러나, 필자로서는 MsgBox() 함수보다는 WScript.Echo() 메서드의 사용을 더 강력하게 권하고 싶다. 그 이유에 대해서는 먼저 WSH의 실행 환경에 대해서 간략하게 설명한 후에 다시 자세히 설명하기로 하겠다.

MsgBox() 함수 실행 결과 WScript.Echo() 메서드 실행 결과

약간 순서가 바뀐 얘기인지는 모르겠지만 지금까지의 이야기들은 이 글을 읽고 계시는 분들이 WSH 프로그래밍에 대해서 이미 어느 정도는 사전 지식을 갖고 계실 것이라는 전제하에 씌여진 것이다. 그러나, 분명히 이 글을 읽고 계신 분들 중에는 WSH 프로그래밍에 대해서 처음 들어본다는 분도 있을 수 있으므로 비록 간략하게나마 그 개념을 설명을 하고 넘어가기로 하겠다.

가장 간단하게 WSH 프로그래밍을 이해할 수 있는 방법은 WSH 프로그래밍을 확장된 형태의 Batch 파일 정도로 생각하는 것이다. 아마 프로그래밍을 직업으로 삼고 계신 분들 중에서 Batch 파일이 무엇인지 모르시는 분들은 없으리라고 믿는다. 비록 DOS 시절의 낡은 유산이기는 하지만, 현재도 Batch 파일은 여러 가지 목적으로 실로 다양한 분야에서 활용되고 있다.

그러나, DOS 시절에 개발된 Batch 파일만으로는 현재 GUI 기반의 환경에서 요구되는 각종 다양한 상황들을 모두 만족시키기에는 역부족일 뿐더러, UNIX나 LINUX 계열의 강력한 쉘 스크립트와 비교해본다면 그 비교 자체가 무색해질 정도로 기능이 빈약한 것 또한 엄연한 사실이다. 이에 대한 대안으로 등장한 것이 바로 WSH(Windows Scripting Host)로써, 이는 VBScript 또는 JScript를 사용해서 작성한 스크립트 기반의 프로그램을 별도의 컴파일이나 개발 도구에 대한 요구없이 운영체제 수준에서 메모장만 가지고도 자유롭게 작성하거나 편집하고 실행할 수 있도록 해주는 강력한 프로그래밍 환경인 것이다.

이런 배경으로 미뤄 짐작할 수 있겠지만 WSH는 기존의 DOS에서와 같은 Command Line 기반의 실행 환경과 Windows GUI 기반의 실행 환경을 모두 지원한다. 가령, 우리가 작성한 monitor.vbs 프로그램 또한 이 두 가지의 환경 모두에서 실행이 가능한데 monitor.vbs 파일을 더블 클릭하면 구동되는 환경이 바로 설치 직후의 디폴트 설정인 GUI 기반의 환경이다. 이 monitor.vbs 프로그램을 Command Line 기반의 실행 환경에서 실행시키려면 DOS 창을 열고 다음과 같이 명령어를 입력하면 된다.

cscript.exe monitor.vbs

이 명령어에서 볼 수 있는 cscript.exe 프로그램은 실질적으로 WSH를 실행하는 일종의 호스트 프로그램 같은 것이다. 눈에 보이지는 않지만 WSH 프로그램이 GUI 기반의 환경에서 실행될 때에도 내부적으로는 같은 작용을 하는 wscript.exe라는 프로그램이 실행된다. 즉, WSH 프로그램을 실행시키면 내부적으로 실제로 실행되는 것은 그 WSH 프로그램이 아니라, 이 두 가지 .exe 프로그램 중 하나일뿐이고 WSH 프로그램은 바로 이 프로그램들에 의해서 처리되는 것이다. 다음 그림은 monitor.vbs 프로그램을 Command Line 기반의 실행 환경에서 실행킨 모습이다.

cscript.exe monitor.vbs

여기서 주의 깊게 살펴봐야 할 부분이 바로 '실행이 완료되었습니다.'라는 메세지가 출력되는 부분이다. 이 메세지는 WScript.Echo() 메서드를 사용해서 출력한 것이다. 이처럼 WScript.Echo() 메서드를 사용해서 메세지를 출력하면 현재 실행되는 환경에 따라 자동적으로 현재 상태에 적당한 방식으로 메세지가 출력된다. 그에 반해 MsgBox() 함수를 사용하는 경우에는 실행 환경과는 상관없이 언제나 GUI 형태의 메세지 박스가 출력된다.

이 점이 문제가 되는 이유는 지금 우리가 얘기하고 있는 스케줄링 잡과 같이 자동적으로 프로그램이 실행되는 경우에는 메세지 박스가 출력되었을 때 '확인' 버튼을 눌러줄 사람이 존재하지 않기 때문에 전체 작업이 그 시점에서 중지되기 때문이다. 따라서, WSH 프로그램에서 메세지를 출력할 때는 반드시 WScript.Echo() 메서드를 사용하는 것이 바람직하다.

그러나, 만일 어쩔수 없는 이유로 인해서 MsgBox() 함수를 사용할 수 밖에 없다면 반드시 /b 스위치와 함께 사용해야 한다. 이 /b 스위치는 WSH 프로그램을 일괄 실행 모드로 실행시켜 모든 종류의 메세지 출력을 강제적으로 막아버린다. /b 스위치는 Command Line 기반의 환경과 GUI 기반의 환경에서 모두 동작한다. 그러나, 이 경우에도 한 가지 문제점이 생기는데 그것은 이 스위치가 정상적인 메세지뿐만 아니라 오류 메세지까지도 막아버린다는 점이다.

이제 필요로 하는 스케줄링 잡 작업을 수행할 WSH 프로그램이 완성되었으므로 이 프로그램을 이용해서 실제로 스케줄링 잡 설정을 해보도록 하겠다. 서버 관리자분들이나 프로그래머분들은 대부분 이미 알고 계시겠지만 Windows 계열의 서버급 운영체제에서는 스케줄링 기능으로 AT 명령어예약된 작업이라는 두 가지 기능을 기본적으로 지원해준다.

이 중에서 AT 명령어는 Windows NT 시절부터 지원되던 기능으로 그 이름에서 알 수 있듯이 DOS 기반의 환경에서 사용할 수 있는 명령어다. 사용자들은 이 명령어를 사용해서 지정된 시간과 날짜에 명령이나 프로그램이 자동으로 실행되도록 예약하거나 현재 예약된 작업들의 목록을 표시하는 등의 관리 작업을 수행할 수 있다. 반면 예약된 작업은 Windows 2000에서부터 지원되기 시작한 기능으로 GUI 기반의 환경에서 보다 편리하고 확장된 다양한 기능을 사용하여 AT 명령어와 동일하게 원하는 작업을 예약하거나 관리하는 기능을 갖고 있다.

여기서 한 가지 짚고 넘어가야 할 점은 이 두 가지 기능이 서로 완벽하게 동일한 것이지만 단지 실행되는 환경이 다른 것도, 그렇다고 서로 완벽하게 상관 없는 별개의 프로그램도 아니라는 점이다. 한 가지 이해하기 쉬운 예를 들어보면 AT 명령어를 사용하여 설정한 작업은 예약된 작업에서 보는 것이 가능하다. 그러나, 역으로 만약 이 작업을 예약된 작업을 사용해서 수정하게 되면, 그 다음부터는 오히려 AT 명령어를 사용해서는 해당 작업을 볼 수가 없게 되는 것이다.

일단 본문에서는 AT 명령어보다는 예약된 작업을 사용해서 스케줄링 잡을 설정해보도록 하겠다. AT 명령어에 대해서 보다 자세한 정보가 필요하신 분들은 도움말을 참고하시기 바란다. 먼저, 제어판을 열어보면 다음 그림과 같은 예약된 작업 아이콘을 볼 수 있을 것이다.

제어판의 '예약된 작업' 아이콘

예약된 작업 아이콘을 마우스로 더블 클릭하면 다음 그림과 같이 예약된 작업 창이 뜨게 된다. 또는, 시작 메뉴에서 보조프로그램시스템 도구예약된 작업을 선택해도 동일한 예약된 작업 창을 볼 수 있다. 만약, 현재까지 설정된 예약 작업이 하나도 없는 상태라면 이 그림과 같이 단지 예약 작업 추가 아이콘 하나만 나타날 것이다.

'예약된 작업' 창

새로운 스케줄링 잡을 예약하는 방법은 무척이나 간단하다. 예약 작업 추가 아이콘을 마우스로 더블 클릭해 보자. 그러면, 다음 그림과 같이 예약 작업 마법사가 시작된다.

'예약 작업 마법사'

이제 다음 버튼을 누르면 아래 그림과 같이 예약할 프로그램을 선택할 수 있는 목록을 가진 창이 나타나게 된다. 이 프로그램들의 목록에서 예약할 프로그램을 바로 선택하거나 찾아보기... 버튼을 눌러서 목록에 없는 기타 다른 프로그램들을 선택할 수도 있는데, 지금 우리가 예약 작업을 설정하려고 하는 프로그램은 직접 ASP 프로그램으로부터 WSH 프로그램으로 변환한 monitor.vbs 파일이므로, 여기서는 찾아보기... 버튼을 누르고 이 파일이 저장된 폴더로 이동한 다음 monitor.vbs 파일을 선택해야 한다.

예약 프로그램 선택

프로그램을 선택하고 나면 다음과 같이 예약 작업의 이름과 대략의 작업 실행 주기를 설정할 수 있는 창이 나타난다. 적당한 이름과 작업 실행 주기를 선택하고 다음 버튼을 누른다. 이 때 중요한 점은, 이 단계에서 어떤 작업 실행 주기를 선택하느냐에 따라 다음 단계에서의 세부 설정 내용이 달라진다는 점이다. 이 부분은 직접 여러분들이 테스트해보기 바란다. 필자는 이 글의 내용상 설정을 따르기 위해서 매일 작업이 실행되는 것으로 설정했다.

예약 작업 이름, 작업 실행 주기 설정

이제 좀 더 세부적인 작업 실행 주기를 설정한다. 방금 전에도 말했지만 이 단계는 바로 전단계에서 어떤 설정을 했느냐에 따라 그 세부 내용이 달라지게 된다. 아래 그림은 전단계에서 작업 실행 주기를 작업이 매일 실행되는 것으로 설정했기 때문에 나타나는 것으로, 만약 전단계에서 작업 실행 주기를 매주, 매월, 또는 기타 다른 주기로 설정했다면 이 단계에서는 각각의 설정에 해당하는 다른 세부 항목들이 출력되거나 경우에 따라서는 생략되기도 할 것이다.

세부 작업 실행 주기 설정

다음 단계는 사용자 계정을 설정하는 단계인데 이 설정은 매우 중요한 의미를 지니고 있다. 왜냐하면, 이렇게 예약된 작업을 통해 설정된 예약 작업은 바로 이 단계에서 설정된 사용자의 계정하에서 항상 실행되기 때문이다. 또한, 서버에 현재 로그인한 사용자가 한 명도 없는 상태에서도 예약 작업은 바로 이 계정을 통해서 실행된다. 따라서, 이 사용자 계정의 권한이 부족하거나 올바르지 않으면 스케줄링 된 프로그램은 실행 중 권한 오류가 발생해서 모든 작업이 실패로 돌아가게 된다.

사용자 계정 설정

이제 다음 버튼을 누르면 예약 작업 마법사의 마지막 단계가 나타난다. 여기에서 [마침]을 누르면 이 작업의 고급 등록 정보 열기(A)를 체크하고 마침 버튼을 누르면 현재 예약 작업을 보다 세밀하게 설정할 수 있는 대화 상자가 나타난다. 그러나, 일단 여기에서는 이 옵션을 선택하지 않고 그냥 마침 버튼을 누른다. 이 고급 등록 정보는 나중에 해당 예약 작업을 더블 클릭하는 것 만으로 쉽게 볼 수 있다.

예약 작업 설정 완료

이제 다음 그림과 같이 새로 추가된 예약 작업을 볼 수 있을 것이다. 이로서 거의 모든 예약 작업 설정이 끝난 셈이지만 사실은 아직도 한 가지 중요한 작업이 남아있다. WSH 프로그램을 실행시키면 내부적으로 실제로 실행되는 것은 그 WSH 프로그램이 아니라 인터프리터에 해당하는 wscript.exe나 cscript.exe 프로그램 중 한 가지고 WSH 프로그램은 바로 이 프로그램들에 의해서 처리되는 것이라고 얘기한 것을 기억할 것이다. 따라서, 일반적인 Windows 응용 프로그램과는 달리 WSH 프로그램의 경우에는 지금처럼 직접 WSH 프로그램을 그대로 설정한 경우 기대하는 결과를 얻을 수 없다.

새 예약 작업

새롭게 추가된 예약 작업 아이콘을 마우스로 더블 클릭해보면 다음 그림과 같이 해당 예약 작업에 대한 고급 등록 정보들이 출력된다. 이 대화 상자가 바로 방금전 예약 작업 마법사의 마지막 단계에서 [마침]을 누르면 이 작업의 고급 등록 정보 열기(A)를 체크했을 때 나타나는 것과 동일한 대화 상자다. 얼핏 보기에는 별다른 문제가 없는 것처럼 보인다. 그러나, 이미 앞에서 설명했던 것처럼 실행될 프로그램 설정에 monitor.vbs 파일이 직접 선택되어 있으면 안됨에도 불구하고 현재 실행(R) 입력란에는 monitor.vbs 파일이 그대로 입력되어 있는 것을 볼 수 있다.

cscript.exe 프로그램 설정

아래 그림과 같이 실행(R) 입력란에 입력된 'C:\monitor.vbs'라는 문자열을 'cscript.exe C:\monitor.vbs'로 수정해준다. 만약, WSH 프로그램이 저장된 위치가 이와 다르다면 그 점도 반영해줘야 한다. 그리고, 마지막으로 한 가지 더 주의해야 할 점은 WSH 프로그램 파일이 저장된 경로에 공백 문자가 들어가는 경우에는 반드시 WSH 프로그램 파일의 이름을 포함한 전체 경로를 "(쌍따옴표)로 감싸줘야 한다는 점이다.

가령, 선택하고자 하는 WSH 프로그램이 'C:\Program Files\My WSH'라는 폴더에 저장된 경우라면 다음과 같이 입력해야 한다.

cscript.exe "C:\Program Files\My WSH\monitor.vbs"

그렇지 않으면 cscript.exe 프로그램은 잘못된 인자를 전달받은 것으로 생각하고 오류 메세지를 리턴한 채 종료되어 버릴 것이다.

cscript.exe 프로그램 설정

실행(R) 입력란을 수정한 후 저장을 하고 나면 예약된 작업의 아이콘이 아래의 그림과 같이 바뀐 것을 볼 수 있을 것이다. 이 아이콘은 당연히 cscript.exe 프로그램의 아이콘이며 System32 폴더에서 확인해 볼 수 있다.

cscript.exe 프로그램 설정

이제 모든 스케줄링 잡 설정 작업이 끝났으므로 지정된 날짜나 시간이 되면 우리가 작성한 WSH 프로그램이 주기적으로 실행되어 그 결과를 돌려줄 것이다. 지금까지 설명한 내용이 꽤 복잡해 보일런지 모르겠지만 다시 정리를 해보자면 다음과 같이 매우 간단한 내용이다.

먼저 평소처럼 ASP 프로그램을 사용해서 필요한 작업을 수행하는 프로그램을 작성한다. 그리고, 작성이 끝난 프로그램을 WSH 프로그램으로 변환하는데, 이 때 몇 가지 주의할 점만 신경써서 지켜주면 되는 것이다. 그리고, 마지막으로 운영체제에서 기본적으로 제공해주는 예약된 작업 기능을 이용하여 스케줄링 잡을 설정한다. 이것이 전부인 셈이다.

이제 마지막으로 앞에서 간단히 넘어간 사항을 한 가지 되짚어보고 글을 마치도록 하겠다. 필자는 이 글의 앞 부분에서 기존의 ASP 프로그램을 활용하면서 스케줄링 잡 문제를 해결하기 위해서는, 스케줄링 프로그램이 지정된 시간 또는 조건에 지정한 URL을 인자로 웹 브라우저를 호출해서 ASP 프로그램을 실행시키는 방법이나, ASP 프로그램을 다른 언어를 사용하여 다시 작성하거나 변형한 다음 스케줄링 프로그램을 사용해서 지정된 시간 또는 조건에 실행시키는 방법 중에서 한 가지 방법을 선택해야 한다고 말했다. 그리고, 본문에서는 그 중에서 두 번째 방법에 대해서만 주로 이야기했다.

그렇다면 필자는 왜 첫 번째 방법이 휠씬 간단함에도 불구하고 두 번째 방법이 더 합리적이라고 판단한 것일까? 예를 들어서, 예약된 작업실행(R) 입력란에 다음과 같은 명령을 직접 입력하여 지정한 날짜나 시간에 실행되도록 하면 훨씬 더 간단했을 텐데 말이다.

"C:\Program Files\Internet Explorer\IEXPLORE.EXE" http://localhost/monitor.asp

이렇게 설정을 하고 나서 한 가지 추가적인 사항만 더 설정해주면 실제로도 우리가 원하는 대로 별다른 문제 없이 잘 동작한다. 여기서 한 가지 추가적인 사항을 더 설정해준다는 것이 무슨 말인가 하면, 특이하게도 이처럼 예약된 작업을 사용하여 Internet Explorer를 예약 작업으로 설정해 놓으면, 첫 번째 예약 작업이 실행될 때에는 매우 잘 동작하지만 두 번째 예약 작업이 실행될 때 부터는 프로그램이 전혀 동작하지 않는다. 그 이유는 정확하지는 않지만 아마도 첫 번째 예약 작업이 실행될 때 로드된 Internet Explorer의 인스턴스가 종료되지 않은채 그대로 남아있기 때문인 것으로 생각된다. 따라서, 이 문제를 해결하기 위해서는 다음과 같은 추가 설정 작업이 요구된다.

해당 예약 작업 아이콘을 마우스로 더블 클릭하고 설정 탭을 선택하면 다음 그림과 같은 대화 상자를 볼 수 있다. 이 대화 상자에는 '다음과 같이 일정 기간 동안 실행되면 작업 중지(T)'라는 옵션이 있는데 이 옵션은 기본값으로 72시간, 즉 3일로 설정되어 있다. 반드시 이 값을 조정해서 예약 작업의 주기보다 적은 값으로 설정해야만 원하는 대로 스케줄링 잡이 실행된다. 즉, 다음 예약 작업이 시작되기 전에 반드시 이전 예약 작업이 실행될 때 로드된 Internet Explorer의 인스턴스가 종료되야만 올바르게 동작하는 것이다. 이 그림에서는 필자가 해당 옵션의 값을 1시간으로 조정해 놓은 것을 볼 수 있다.

Internet Explorer를 위한 추가 설정

이렇게 비교적 간단하게 설정을 끝마칠 수 있음에도 불구하고 이 첫 번째 방법에 좀 더 비중을 두고 소개하지 않은 이유는 우선 ASP 프로그램을 WSH 프로그램으로 변환하는 방법을 소개하고자 했기 때문이다. 왜냐하면 이렇게 변환된 WSH 프로그램은 IIS가 설치되어 있지 않은 머신에서도 자유롭게 사용이 가능하기 때문에 ASP 프로그램에 비해 활용도가 더욱 높기 때문이다.

그리고, 필자가 개인적으로 가장 마음에 걸렸던 부분은 ASP 프로그램을 그대로 사용해서 스케줄링 잡을 설정하는 경우에는 실질적으로 처리되는 모든 작업이 끝나고 나서도 Internet Explorer의 인스턴스가 그대로 남아 있는 등 프로그래머 스스로가 프로그램의 전 과정을 자신의 뜻대로 제어할 수 없다는 점이었다.

COPYRIGHT © 2001-2017 EGOCUBE. ALL RIGHTS RESERVED.
Total Visit Count: 9,572,690, v1.9.0.28773 β