개꿈닷넷의 소프트웨어 이야기

울타리 { PROTECTS YOUR SYSTEM FROM MALWARE } 최신 버전 : 2.6, 업데이트 날짜 : 2009년 2월 17일

울타리는 매우 간단하고 쉬운 악성 코드 제거 프로그램입니다. 간단하게 보이지만 매우 강력한 악성 코드 제거 성능을 자랑하며, 완전 무료인 프로그램입니다.  이미 많은 사용자들이 감격의 성능을 경험하고 있는 울타리, 지금 바로 경험해보세요!  P.S. 울타리란 이름은, 자신의 컴퓨터를 안전한 울타리 안에 두어, 외부의 악성코드들로부터 보호한다는 순 한글 이름입니다.

[ 자세히 알아보기... ]

이번 업데이트에는, 오토런 바이러스를 차단하는 프로그램이 추가되었습니다.
오토런 바이러스의 대표적인 예로는 최근 이슈화되고 있는 2090 바이러스가 있습니다.

자세한 내용은, http://rodream.net 을 참고하여 주십시오 ^^

왜 사용자의 경험에 대한 학습을 해야 할까?

이 이야기는 다소 현실적인 주제로 흘러갈 수 밖에 없다. 우리가 사용자의 경험에 대한 학습을 하는 이유에 대해서, 대부분은 사용자에게 좋은 경험을 제공하기 위해서라는 교과서 적은 답변을 할 것이다.

물론, 이 역시 맞는 말이다. 우리가 잘 알고 있는 Microsoft 에서도 참으로 많은 사용자 경험(이하UX)에 대한 학습을 진행하고 있고, 그 결과로 우리는 새로운 운영체제에 대해서 생각보다는 적은 시간을 투자하여 익숙해지고, 편리하다고 느낄 수 있는 것이다.
일반적으로, 제품은 특별한 UX 에 대한 고려가 없는 경우에는 그 제품을 만드는 사람의 경험에 의해서 디자인 되게 된다. 만약, 어떤 제품이 UX 에 대한 고려 없이 만들어졌다고 한다면, 그 제품을 만든 사람의 경험에 따라 사용하기 쉽도록 만들어진다. 만약, 그 제품이 소프트웨어라고 한다면, 키보드 사용에 익숙한 사용자가 개발한 프로그램은 키보드 만으로 충분히 많은 조작을 할 수 있을 것이고, 비교적 마우스를 즐겨 사용하는 사용자에게는 그다지 맞지 않을 수 있다.

이렇게 UX 는 좀 더 많은 사용자들, 특히 제품을 개발하는 당사자(혹은 회사)의 구성원들과는 다른 구성원들의 요구(Needs)에 적합하도록 만들 수 있을 것이다.
하지만, 이러한 내용들이 항상 유효하게 받아들여지는 것은 아니다. 이러한 UX 에 대한 고려가 유효해지기 위해서는 반드시 경쟁이 있어야 한다. 독점 상태인 물건에 대해서는 일반적으로 UX 가 유용하지 않다. 왜냐하면, 독점 상태로 오래 지속된 제품의 경우, 그 제품의 초기 형태 자체가 이미 사용자들의 경험으로 굳어졌기 때문이다. 이는, 실질적으로 그 제품이 좋은 인터페이스를 가지고 있었던 것이 아니라, 사용자들이 오랜 시간을 거치면서 그 인터페이스에 적응한 결과이다.

앞에서 설명한 Microsoft 의 운영체제의 경우에는 사실상 독점이라는 의견도 있을 것이다. 하지만, 이 경우에는 다른 회사의 운영체제와의 비교보다는, 오히려 Microsoft 에서 만든 이전의 운영체제와의 비교가 문제가 된다. 이전의 운영체제보다 더 좋은 사용자의 경험을 제공하기 위해서 Microsoft 는 UX 에 대한 고려를 해야 하며, 그 주된 대상은 경쟁사의 제품이 될 수 도 있고, 자사의 이전 버전의 제품이 될 수 도 있는 것이다.

사실, UX 에 대한 고려가 대두되고, 이것이 필요한 이유는, 앞에서 장황하게 설명한 내용보다는 좀 더 현실적인 이야기로 풀어낼 수 있다. 바로, UX 에 대한 고려가 없는 제품들이 존재하고, 이에 대하여 만족하지 못한 사용자들이 만들어내는 새로운 시장이 있기 때문이다. 만약 이 새로운 시장이 없다면, 우리는 UX 에 대한 고려를 하지 않아도 될 것이다. 하지만, 이들 사용자는 새로운 시장에 대한 요구(Needs)를 항상 가지고 있으며, 그에 대한 응답을 하여 준다면, 시장을 창출할 수 있다. 예를 들면, 복잡한 금융권 사이트를 한꺼번에 간단 명료하게 묶어 놓은 모네타(http://moneta.co.kr) 사이트가 그 예가 될 수 있을 것이다.

언젠가 UX 에 대한 고려가 일반화 된다면, 우리는 어떤일을 하는 것에 있어서 UX 를 항상 고려 해야 할 것이다. 하지만, UX 에 대한 고민은 어딘가에서 그 정도가 정해져있고, 끝이나는 것이 아니기 때문에, 좀 더 좋은 고민은 항상 새로운 시장을 창출할 수 있을 것이다.

이렇게 , UX 는 블루오션을 만들어내는 발전 동력이기 때문에, 우리는 UX 에 관심을 가지고 집중하여야 한다.

프로그래밍 언어에 대해서 자세하게 알고 있지 않은 사람들은, 프로그래밍 언어를 마치 인간의 언어로 착각하곤 한다.

그러한 착각속에서 생기는 또 다른 착각은, 프로그래밍 언어를 번역하는 컴파일러도 있으니, 그러한 것과 유사하게 자연어(인간의 언어)도 완벽히 번역할 수 있는 번역기를 만들 수 있을 것 이라는 생각이다. 물론, 일이 시작되기도 전에 이 일은 절대로 불가능 합니다. 라는 말을 하려고 하는 것은 아니다.

하지만, 사람들이 생각하는 '완벽한' 이라는 수식어는 굉장히 엄격한 기준을 가지고 있다. 필자는 여기서 '완벽한 자연어 처리기' 는 거의 불가능에 가깝다고 단언할 수 있다. '거의' 라는 수식어를 붙인 것은 필자의 미비한 실력과 관점으로 미래의 일까지 완전히 예측하기에는 어려움이 있어서 이며, 최소한 필자의 개인적인 의견으로는 완벽한 자연어 처리는 불가능하다.

왜 불가능할까? 그 질문에 대답하기 위해서는 완벽한이라는 수식어에 대해서 좀 더 알아볼 필요가 있다. 완벽한이라는 것은 누가 어떤 이야기를 하건 간에, 그 의중을 반드시 파악해야 한다는 것이다. 하지만, 이는 불가능하다. 누가 '앗 뜨거' 라고 말한 것을 가지고, 그 상황을 완전히 이해할 수 있는 사람이 있을까? 그 사람은 뜨거운 불에 데였을 수 도 있고, 뜨거운 음식을 먹고 있었을 수 도 있다. 이렇게 자연어는 반드시 필요한 항목도 없어질 수 있기 때문에, 심지어 사람이라고 할지라도 이 자연어를 완전하게 이해할 수 는 없다. 그렇기 때문에 항상 miss communication 이 발생하는 것이다.
앞의 이야기를 간단하게 요약하자면, 사람조차도 자연어를 완벽하게 처리할 수 없는데, 이를 기계가 처리하기에는 어렵다는 이야기이다. 물론, 이것이 사람이 못한다고 해서 기계가 못한다는 관점에서 접근하는 것은 아니다. 그렇다면, 사람이 못하는 무한 계산 삽질을, 기계는 할 수 있기 때문이다. 하지만 이 경우는 이것과 명백히 다르다. 이는 자연어 자체의 불명확성에 기여한 결과이다.

일반적으로 프로그래밍 언어를 처리하는데에는, 엄격한 문법이 존재한다. 자연어에도 이러한 문법이 존재하지만, 프로그래밍 언어처럼 엄격하지는 않다. 왜일까? 곰곰히 생각해보면, 우리가 프로그램을 작성할때, 즉 프로그래밍을 할 때, 언제 문법오류에 대해서 보고 받는지에 대해서 알아볼 필요가 있다.

일부 프로그래밍언어들은 코드를 직접 입력할 때, 경고를 하기도 한다. 비주얼 베이직과 같은 경우인데, 사실 이러한 경우는 잘 없는 특수한 경우이다. 실질적으로 대부분의 프로그래밍 언어들은 컴파일을 하는 시점에서 사용자에게 '잘못된 문법입니다' 라는 경고를 알려주고, 더 이상 진행하지 않게 된다.
프로그래밍 언어를 해석함에 있어서 문법에 어긋난 표현이나, 허용되지 않는 표현을 걸러내는 것은 매우 중요하다. 사실상 이는 컴파일러에서는 처리 도중 에러를 만난 셈이 되지만, 실제로 프로그래머의 입장에서는 표현을 걸러내짐을 당한 입장이 된다. 더 이상 어떠한 것도 진행되지 않고, 반드시 에러난 그 코드를 수정하여야만 하기 때문이다.
하지만, 자연어에서는 이러한 것이 없다. 어떻게 입력을 하더라도, 누군가 와서 '야 너 이거 무슨 소리야?' 라고 말하는 사람은 거의 없다. 즉, 어떤 입력이라도 일단 받아들이는것이 자연어 처리의 특징이라는 것이다. 또한, 그렇게 특이한 입력들이 증가하는 것은, 언어가 점점 발전함에 따라서 더 많아진다.

이렇게 예외가 점점 많아지는 것이 프로그래밍 언어와 자연어의 두번째 차이점이다. 프로그래밍 언어는 초기 설계시 정해진 문법 사항에 대해서 처리를 하고, 기타의 내용을 그냥 무시하도록 설계되지만, 자연어는 그렇지 않다. 복잡한 문법 사항과 유사한 이야기가 되겠지만, 복잡한 경우에 대한 처리도 해법이 존재해야 한다. 왜냐하면 사림이 그렇게 받아들이고 있기 때문이다.

이러한 문제들로 인하여, 프로그래밍 언어를 분석하는 기법을 가지고는, 자연어를 분석할 수 없고, 자연어를 분석하기 위해서는 구문 분석 뿐만 아니라, 문맥해석, 학습기능등의 여러가지 기능들이 필요하다.

 Windows Vista 에 들어오면서 많은 것들이 바뀌었다. 그 중 가장 큰 변화중 하나가 바로 UAC 이다. UAC 의 새로운 등장으로 인하여, 많은 프로그래머들이 아무생각 없이 사용해왔던, 관리자 권한 Software 들이, 더 이상 아무런 사용자의 동의 없이 실행될 수 없게 되었다.
 이러한 제약 사항들은 운영체제나 사용자의 보안성에 좋은 영향을 주지만, 시스템 유틸리티나 보안 소프트웨어를 개발하는 사람들에게 있어서는 매우 치명적인 일이 될 수 밖에 없다.

 하지만, Windows Vista 에서도, 시스템 유틸리티나 보안 소프트웨어를 개발하는 프로그래머들을 위한 길을 아예 없애버린것은 아니다. 단지, 좀 더 명확한 정책을 따르도록 변경된 것일 뿐이다. 일반적으로 Windows XP 혹은 그 이전에는 '서비스 프로그램' 이 그다지 많은 호응을 받지 못했다. 왜냐하면, 서비스 프로그램은 만들기도 힘들고, 관리도 귀찮았기 때문이다. 하지만, Windows Vista 와 UAC 가 등장하면서 부터, 서비스 프로그램은, 관리자 권한 프로그램을 실행하고자 할 때 가장 안전하고 간편한 방법 중 하나이다. 이번에는 이러한 서비스 프로그램을 사용할 때 가장 문제가 되는 Inter Process Communcation 에 대하여 알아볼 것이다.

 먼저, IPC 를 하는 방법은 여러가지가 있다. WM_COPYDATA 를 사용하는 방법, Shared Memory 를 사용하는 방법, Pipe 를 사용하는 방법, Socket 을 사용하는 방법...등 매우 다양한 IPC 방법들이 존재한다. 하지만, 여기서 다루고자 하는 것은 Pipe 을 사용하는 방식이다. 왜 이 방법을 택해야 하는 걸까? 그에 대한 답변은 매우 간단하다. 먼저, 메시지를 주고 받는 방법은 서비스 프로그램과 IPC 를 할 대상 프로그램과의 Desktop 이 다른 경우 사용할 수 없다. Shared Memory 의 경우도 앞의 경우와 같은 문제를 가지고 있는데, Session 이 다른 경우, 다른 Session 의 Shared Memory에 접근할 수 없다. Socket의 경우에는 가능은 하지만, 단순한 IPC 를 위해서 Socket 을 사용하는 것은, 구덩이를 파기 위해 포크레인을 동원하는 것과 같다.



그래서 결국 선택된 것이 Pipe 이다. Pipe 는 간단한 IPC 를 구현하는데 유효하며, 프로그램이 실행되는 Desktop 이나 계정에 상관없이, 공유가 가능하다.

 Pipe 는 CreateNamedPipe 함수와 ConnectNamedPipe 함수를 통하여 초기화 작업을 진행한다. 그 이후로는 ReadFile 과 WriteFile 을 사용하여 데이터에 접근하게 된다.

CPipeServer
CPipeServer 는 필자가 비스타에서 서비스 프로그램과 IPC 를 하기 위하여 만든 Pipe Server 클래스 이다. 이 클래스는 StartPipeServer 함수를 가지고 있으며, 이 함수를 호출하면, 서버 파이프를 초기화 하고, 클라이언트의 접속을 대기하는 쓰레드를 생성한다.

앞에서 설명한 대로라면, Pipe 는 Vista 에서 쉽게 동작하는 것 처럼 보였지만, 실제로는 한가지 더 신경써줘야 할 것이 있다. 바로 Pipe 의 권한이다. Vista 의 UAC 는 프로그램마다 권한을 가지도록 하였으며, 낮은 권한의 프로그램이 높은 권한의 프로그램이 가지고 있는 리소스에 접근할 수 없도록 제한하고 있다. 그래서 필요한 것이, Pipe 의 권한을 조절하는 것이다.

  BYTE sd[SECURITY_DESCRIPTOR_MIN_LENGTH];
  SECURITY_ATTRIBUTES sa;
 
  sa.nLength = sizeof(sa);
  sa.bInheritHandle = TRUE;
  sa.lpSecurityDescriptor = &sd;
 
  InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(&sd, TRUE, (PACL) 0, FALSE);
     
  hPipe = CreateNamedPipe(
   pInfo->szPipeName,             // pipe name
   PIPE_ACCESS_DUPLEX,       // read/write access
   PIPE_TYPE_MESSAGE |       // message type pipe
   PIPE_READMODE_MESSAGE |   // message-read mode
   PIPE_WAIT,                // blocking mode
   PIPE_UNLIMITED_INSTANCES, // max. instances 
   BUFSIZE,                  // output buffer size
   BUFSIZE,                  // input buffer size
   0,                        // client time-out
   &sa);                    // default security attribute
 

위의 코드는 Pipe 를 생성할 때, Security Attribute 속성을 지정하여, 낮은 권한의 프로그램에서도 해당 Pipe 를 열 수 있도록 허용하는 코드이다.

이렇게 만들어진 Pipe 서버는 특정한 값을 받아서 처리하게 된다. 이 소스에서 필자는 Pipe 의 간단한 프로토콜을 정의하였는데, 그것은 다음과 같다.

프로토콜 정의

[CMDS (정상적인 PIPE 패킷이라는 서명(sign)), 4바이트]
[명령, 4바이트]
[명령 번호, 4바이트]
[추가 정보 길이, 4바이트]
[추가 정보, 추가 정보 길이에 명시된 길이 ~ 버퍼의 최대 길이]

이 프로토콜에 맞는 형식을 갖춘 데이터들은 내부적으로 사용자가 지정한 함수 포인터를 호출한다. 그리고 마지막으로, 그렇게 호출된 함수의 반환값을 다시 클라이언트에 보내주는 것으로 서버는 하나의 패킷에 대한 처리를 마무리 하게 된다.

이 클래스를 사용하는 방법은 매우 간단하다.
먼저, 클래스를 선언한 후, StartPipeServer 함수를 호출해 주면 된다.

다음은 간단한 예제이다.

#include "PipeServer.h"
CPipeServer g_pipeServer;

int WINAPI ProcessIO(DWORD dwCmd, DWORD dwCmdNumber, DWORD dwLen, char* lpszData, DWORD* pdwRetLen, char* lpszReturn)
{
 char szMsg[1024];
 sprintf(szMsg, "Cmd : %d, CmdNumber : %d, dwLen : %d, lpszData : %s",
  dwCmd, dwCmdNumber, dwLen, lpszData );

 strcpy( lpszReturn, "ProcessIO 에서 처리한 내용! : " );
 strcat( lpszReturn, szMsg );
 *pdwRetLen = strlen(lpszReturn);

 return 0;
}

DWORD WINAPI ServiceExecutionThread(LPDWORD param)
{
 g_pipeServer.StartPipeServer( "\\\\.\\pipe\\VistaSvcIPC", ProcessIO );
 return 0;
}

이렇게 구성된 프로그램을 서비스로 만들고, 일반 권한 프로그램에서 이 서비스와 통신하게 할 수 있다. 클라이언트에 대한 코드는 아래와 같다.

void CNormalPrgDlg::OnButton1()
{
 static BOOL bConnected = FALSE;

 if(bConnected) {
  CString szText;
  m_edt.GetWindowText( szText );

  char szBuffer[BUFSIZE] = { 0, };
  char szRetData[BUFSIZE] = { 0, };
  DWORD dwRetLen = 0;
  strcpy(szBuffer, szText);
  g_pipeClient.Send(1024, GetTickCount(), strlen(szBuffer)+1, szBuffer, &dwRetLen, szRetData);
 
  m_lst.InsertString(0, szRetData);
 } else {
  bConnected = g_pipeClient.ConnectPipe("\\\\.\\pipe\\VistaSvcIPC");
 }
}

 이 예제가 동작하는 모습은 아래와 같다.

첨부된 파일의 소스는 서버와 클라이언트이며, MFC 를 기반으로 작성되어 있다.


 

그동안 많은 분들을 속썩여왔던 윈도우즈 업데이트.

사용하기도 복잡하고, 너무 느리고, 더군다나 인증 체제가 강화되면서 인증이 안되신 분들은 업데이트 조차 설치되지 않아서 골치를 썩히게 했던 것을 드디어 해결할 수 있게 되었습니다.

이 윈도우즈 업데이트 설치 프로그램 의 정식 버전을 릴리즈 합니다.

이 프로그램은 다른 프로그램들과 달리 다운로드를 받아서 설치하여 주기 때문에, 한번 다운로드를 받아두면 나중에 인터넷이 안되는 환경에서도 충분히 사용하실 수 있습니다.

이 프로그램의 주요 기능과 특징은 다음과 같습니다.

1. 인증을 받지 않아도 중요 윈도우즈 업데이트가 가능!

2. 한번 다운로드 받아두면, 다시 다운로드 받아도 설치할 수 있기 때문에, 윈도우 재설치 후 인터넷이 안되는 상황에서도 사용 가능!

3. 군더더기 전혀 없이 간단하고 깔끔한 사용법과 프로그램

그럼 즐거운 윈도우즈 업데이트 되세요~

사용중 불편에 대한 문의는 홈페이지나 블로그로 해 주세요!

프로그램 다운 로드 받기

개꿈닷넷에서 배포하는 무료 프로그램들 다운로드 받기

마이크로소프트웨어 4월호에 쓴 글의 내용입니다.

1. 제어판 프로그램 사용하기 (그건 이렇습니다)
 - 제어판 프로그램을 내 프로그램 안에서 실행시키는 방법을 알아봅니다. 더불어 제어판 프로그램에 대한 간단한 설명과 분석, 만드는 방법등을 알아봅니다.

2. GlobalMemoryStatus 에서 겪는 실수
 - GlobalMemoryStatus 에서 겪을 수 있는 실수를 확인해보고 해결할 수 있는 방법을 봅니다.

이번 울타리 업데이트(1.75) 에서는, 다른 프로그램과의 오진 내용을 수정하였습니다.

또한, 앞으로 있을 1.76 버전의 업데이트 사항 중 하나를 미리 알려드리자면,

방화벽 소프트웨어에서 파일로 리스트를 저장하고 불러오는 기능을 추가한 것입니다.

http://jsjang.tistory.com/trackback/426

혼자서만 이상하다고 생각했는데 뭔가 문제가 있나보다...ㅋ

자세한건 알려주지 않는 회사들이라 참으로 갑갑하기만 하다 :)