미친병아리의 프로그래밍 이야기

오라클 클라이언트는 설치과정이 좀 독특한 프로그램이다.. 자바로 만들어진 설치 프로그램은 윈도우, 리눅스, 유닉스, 맥 등의 OS에서 모두 사용하기 위해 설계가 되었는가 본데, 각 운영체제에서 당연히 여겨지는 점들이 지켜지지 않아 황당한 경우가 많다..

예를들면, 윈도우 환경에서 설치경로에 공백문자와 한글을 지원한다.. 하지만, 오라클 클라이언트는 이런 경로에 설치를 하면 제대로 동작을 안한다.. 더구나 일정 경로 이상 깊이가 길어지면 (즉, 경로명 길이가 길어지면) 동작을 안하는 경우도 있다.. 온갖 삽질을 통해 경험으로 이런 내용들을 알고 있어 오라클 클라이언트를 설치할때면 무조건 디폴트 경로에 설치를 한다.. 또 무슨 일이 생길지 모르므로.. 오라클의 새 버젼이 나올때 마다 오라클 클라이언트도 새로 나오는데, 왜 아직까지 이런 문제점들을 수정되지 않는가 모르겠다.. 이런 부분을 보면 한중일 2바이트 문자에 대한 지원을 Microsoft 만큼 제대로 하는 곳도 없다.. 오픈소스 진영도 Microsoft를 따라가려면 아직도 멀었다..

하지만, 이것도 내가 잘 하면 되는 것이지만 다른 사람이 이상하게 설치를 해둔 상황에 내가 이상한 점을 발견하고 문제를 해결해야 하는 상황을 접하게 되면 피곤하게 된다.. 이번에도 그런 경우였는데, 다른 서버에서는 잘 동작하는 IIS 서버 컴포넌트가 새 서버에 세팅을 했더니 DB 접속이 안되는 것이다.. 젠장..

정말 신기한 현상은 제어판의 ODBC 세팅하는 화면에서 접속 테스트를 해보면 접속이 제대로 된다는 것이다.. ODBC 세팅창에서는 제대로 되는데, 프로그램에서 안되니 우리 프로그램 문제라 생각하고 연락을 한 것이다..

Microsoft OLE DB Provider for ODBC Drivers 오류 '80004005'
5 (Oracle in OraHome92) 시스템 오류가 발생하여 지정한 드라이버를 로드하지 못했습니다.
/OracleTest.asp, 줄 15

컴포넌트가 DB 접속이 계속 실패를 하는데 원인 찾기가 쉽지 않아, ASP로 간단한 샘플코드를 만들어 확인을 해봤다.. ASP에서도 똑같은 오류가 발생했다.. 위와 같은 오류가 발생하였는데, 원인을 찾는 것이 쉽지 않았다.. 구글을 비롯해 네이버 지식인 등 검색을 좀 해봤는데 완전 똑같은 현상은 아니지만 비슷한 현상들 겪는 사람들이 좀 있었다.. 내용을 종합해보니 C 드라이브 루트가 아닌 D 드라이브에 오라클 클라이언트를 설치하면 제대로 동작을 안하는 경우가 있다는데 힌트를 얻었다.. 확인해보니 문제의 서버에도 오라클 클라이언트가 D 드라이브에 설치되어 있었다.. 젠장, 이렇게 황당한 경우가.. 왜 D 드라이브에 설치를 하면 정상동작을 안하는 것이야? 이렇게 만들라고 해도 이렇게 만들기 힘들겠다..

http://database.ssarang.net/?inc=read&aid=1641&criteria=mssql&subcrit=qna&id=&limit=20&keyword=&page=5

http://locke.tistory.com/40

http://sqler.pe.kr/web_board/view_list.asp?id=6551&read=1718&pagec=&gotopage=24&block=2&part=myboard3

원인을 찾기가 힘들었지 해결방법은 간단했다.. 오라클 클라이언트를 언인스톨 하고, C 드라이브에 설치를 하니 해결이 되었다.. 무슨 프로그램이 C 드라이브에 설치를 했을때와 D 드라이브에 설치를 했을때 동작이 틀려질 수가 있을까? 어떻게 만들면 이렇게 동작할 수가 있을까? 정말 신기하다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

ASP.NET 환경에서 안전한 웹 어플리케이션을 만드는데 알아두면 좋은 내용들을 다루고 있다.. 본질적인 내용은 어느 개발환경에서든 모두 고려해볼만한 내용을 담고 있지만, 예와 설명이 ASP.NET을 기준으로 설명을 하고 있어 모든 웹개발자들이 공유하고 즐기기엔 약간 아쉬운 점이 있기는 하다.. 뭐, MS 기술자들이 모이는 블로그 사이트에 올려진 글이니 당연하기 하겠지만..

3번째 이야기에서 보면 입력값 점검을 위해 정규표현식을 사용하는 예가 나오는데, 아주 좋은 방법이라 생각한다.. 올바로된 값이 입력되었는지를 점검하는데 정규표현식 만큼 간결하면서도 강력한 방법이 없는데, 자바 스크립트 뿐만 아니라 많은 프로그래밍 환경에서 지원하는 방법인데 주변의 프로그래머들은 의외로 사용을 안하는 것 같다.. 왜 그럴까 좀 궁금해진다..

First Line of Defense for Web Applications - Part 1
(http://blogs.msdn.com/hackers/archive/2007/10/12/first-line-of-defense-for-web-applications-part-1.aspx)
First Line of Defense for Web Applications - Part 2
(http://blogs.msdn.com/hackers/archive/2007/10/22/first-line-of-defense-for-web-applications-part-2.aspx)
First Line of Defense for Web Applications - Part 3
(http://blogs.msdn.com/hackers/archive/2007/10/30/first-line-of-defense-for-web-applications-part-3.aspx)
First Line of Defense for Web Applications - Part 4
(http://blogs.msdn.com/hackers/archive/2007/11/12/first-line-of-defense-for-web-applications-part-4.aspx)
First Line of Defense for Web Applications - Part 5
(http://blogs.msdn.com/hackers/archive/2007/12/16/first-line-of-defense-for-web-applications-part-5.aspx)
First Line of Defense for Web Applications - Conclusion
(http://blogs.msdn.com/hackers/archive/2008/01/06/first-line-of-defense-for-web-applications-conclusion.aspx)

4번째 이야기에서 주로 다루는 Cross Site Scripting에 대해서는 그동안 관심을 가져보지 못했었는데, 앞으로는 이 부분에 대해서도 관심을 가져야 하겠다..

5번째 이야기에서는 SQL 인젝션에 대해 지면을 할애하고 있다..

4번째, 5번째 이야기는 사실 프로그래밍 개발환경에 상관 없이 모두에게 동일하게 적용되는 내용이니 참고해보면 좋겠다.. 물론, 이 두가지 주제에 대해서는 이 글들 말고도 다른 좋은 글들이 훨씬 더 많이 있을테니 그러한 글들을 참조해도 좋다.. 아무튼 이 두 주제는 요즘 보안에서는 기본에 해당하는 내용이므로 꼭 내용을 숙지하고 프로그래밍시 반영을 해야한다..

정 시간이 없다면 맨 마지막 글인 결론 내용이라도 꼭 읽어볼 필요가 있겠다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

다음 DNA에서 C/C++에서 integer변수 swap 방법 비교 (http://dna.daum.net/technote/ccpp/CPPSwap) 라는 글을 보고 옛날 생각도 나고, 요즘 CPU 환경에서는 그냥 임시변수를 선언하여 구현하는 것이 더 빠르다는 결론이 재밌어 보여 윈도우에서도 함 해봤다.. VC++ 6.0과 VS 2008을 사용하여 2개를 비교를 해봤다..

원문에서 소개된 소스코드를 아래와 같이 조금 수정해봤다.. 윈도우즈 환경에서 실행시간 위해 약간의 코드를 추가했다.. 원본 코드는 그대로 유지했음.. 새 컴파일러가 좀 더 좋아진 점이 있는가 해서 VC++ 6.0과 VS 2008을 가지고 두번 비교를 해봄..


std::swap을 사용하는 방법
std::swap : c++에서 일반적으로 가장 널리쓰이는 안전한 방법

#include "stdafx.h"

#include <iostream>
#include <algorithm>
#include <stdio.h>

#include <windows.h>

int main(void)
{
    DWORD start = ::GetTickCount() ;

    int a = 1;
    int b = 2;
    for(int i=0;i<50000000;i++)
    {
        std::swap(a,b);
    }
   
    printf("%d %d\n\n",a, b);

    DWORD end = ::GetTickCount() ;
    printf("execution time : %1.3f m/s\n", (double)(end - start) / (double)100) ;

    int temp ;
    std::cin >> temp ;

    return 0 ;
}

VC++ 6.0 : execution time : 0.630 m/s
VS 2008 : execution time : 0.630 m/s


xor를 이용한 방법
c에서 예전에 많이 사용되던 방법 임시변수를 사용하지 않아서 좋다는 장점이 있음. 오래된 CPU에서는 이 방법이 빨랐으나 최근 CPU에서는 bit operation이 느려서 그다지 좋지 않다고 알려져있음.

#include "stdafx.h"

#include <iostream>
#include <algorithm>
#include <stdio.h>

#include <windows.h>

#define SWAP(a,b) { if (a!=b) { a^=b; b^=a; a^=b; }}

int main(void)
{
    DWORD start = ::GetTickCount() ;

    int a = 1;
    int b = 2;
    for(int i=0;i<50000000;i++)
    {
        SWAP(a,b);
    }
   
    printf("%d %d\n\n",a, b);
   
    DWORD end = ::GetTickCount() ;
    printf("execution time : %1.3f m/s\n", (double)(end - start) / (double)100) ;
   
    int temp ;
    std::cin >> temp ;
   
    return 0 ;
}

VC++ 6.0 : execution time : 0.940 m/s
VS 2008 : execution time : 0.940 m/s


임시변수를 이용한 방법
가장 기본적인 방법. 임시변수를 사용한다는 단점이 있음.

#include "stdafx.h"

#include <iostream>
#include <algorithm>
#include <stdio.h>

#include <windows.h>

#define SWAP(a,b) { int t=a; a=b; b=t; }

int main(void)
{
    DWORD start = ::GetTickCount() ;

    int a = 1;
    int b = 2;
    for(int i=0;i<50000000;i++)
    {
        SWAP(a,b);
    }
   
    printf("%d %d\n\n",a, b);
   
    DWORD end = ::GetTickCount() ;
    printf("execution time : %1.3f m/s\n", (double)(end - start) / (double)100) ;
   
    int temp ;
    std::cin >> temp ;
   
    return 0 ;
}

VC++ 6.0 : execution time : 0.470 m/s
VS 2008 : execution time : 0.630 m/s


결론
실험환경 : Intel Core2 Duo T5600 1.83GHz, 2.5GB RAM

VC++ 6.0 : execution time : 0.630 m/s
VS 2008 : execution time : 0.630 m/s

VC++ 6.0 : execution time : 0.940 m/s
VS 2008 : execution time : 0.940 m/s

VC++ 6.0 : execution time : 0.470 m/s
VS 2008 : execution time : 0.470 m/s

VC++ 6.0과 VS 2008의 차이점은 없음 (옵션 변경 없이 디폴트로 실행시켰을때..)
임시변수를 사용하는 방법이 가장 빠름.. 이상한 점은 VS 2008에서는 세번째 실험방법의 결과가 실행시마다 왔다갔다 한다는 점.. 0.470과 0.630이 실행시마다 왔다갔다 함..

새로운 환경에서는 예전의 지식은 힘을 발휘하지 못하게 되는 경우가 있다.. 임시변수를 두면 좋지 않다는 생각을 가지고 살다, 이런 결론을 얻고 보면 좀 황당하다.. std::swap 보다도 임시변수를 사용하는 것이 빠르다니.. 많이 읽고 정보를 수집하고, 직접 실습을 해보고 하여 항상 최신 지식으로 무장할 필요가 있다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MS SQL 2005를 수동으로 삭제하는 방법.. 설치시 오류가 났거나, 언인스톨 과정에서 오류가 난 경우, Visual Studio 설치시 지 맘대로 설치를 해버리는 쓸데없는 MS SQL 2005의 인스턴스들을 제거하고 싶은 경우에 사용..

Microsoft의 페이지들은 사이트 개편이 URL이 언제 어떻게 바뀌어버릴지 모르니 몇가지 핵심 내용을 메모해둘 필요가 있음..  원문은 http://support.microsoft.com/kb/909967/ko 참조..

아래 명령어를 실행하여 삭제하고 싶은 인스턴스를 선택하면 삭제됨..

"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\ARPWrapper.exe" /Remove

설치된 인스턴스가 여러개인 경우, 언인스톨을 하고 나면 설치지원 프로그램들이 같이 삭제가 되기 때문에 설치 CD를 사용해 설치지원 프로그램만 설치한 후 취소를 하여 종료하고 다시 위의 명령어를 실행하여 삭제하고 싶은 인스턴스 갯수만큼 반복해야 함.. 불편하지만, 다른 방법 없음..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

기능 개선상 스토어드 프로시저가 몇개 추가되었는데, 갑자기 스토어드 프로시저 호출이 안되는거다.. 예전 스토어드 프로시저는 잘 호출되고 실행도 되는데 새로 추가된 스토어드 프로시저는 호출이 안된다.. 도대체 뭐가 문제인가.. 몇일을 끙끙 거리고 해매도 답도 안나오고..

스토어드 프로시저 내부에 select 가 2개 이상 있는 것도 아니고.. 이렇게 수정해보고, 저렇게 수정을 해봐도 해결이 안되더군..

2008/03/18 19:16:18 at ets.biz.admin.siteadmin.TestMngMgt.TestMngTO.testMngMarking2
(TestMngTO.java:500) [Debug] call proc_answer ex ( ?, '' ) start
2008/03/18 19:16:18 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:683) [Error] com.microsoft.sqlserver.jdbc.SQLServerException: 서버 커서는 둘 이상의 SELECT 문이 있는 원격 저장 프로시저나 저장 프로시저에서 사용할 수 없습니다. 기본 결과 집합이나 클라이언트 커서를 사용하십시오.
    at ets.biz.admin.siteadmin.TestMngMgt.TestMngTO.testMngMarking2(TestMngTO.java:522)
    at ets.biz.admin.siteadmin.TestMngMgt.TestMngBLC.testMngMarking2(TestMngBLC.java:154)
    at ets.biz.admin.siteadmin.TestMngMgt.TestMngBLC.doTheWork(TestMngBLC.java:51)
 
에러메시지를 가지고 구글 검색을 해봤는데도 검색도 안되고.. 결국, 안되는 영어로 메시지를 영어로 바꾸어 검색을 해서 영문에 해당하는 에러메시지를 찾아냈다.. 그 메시지로 Microsoft의 MSDN 사이트에서 검색을 하니 알려진 버그라는 사실을 찾았다.. 문제는 SQL Server JDBC 드라이버의 버그였으며, 최신버젼으로 업데이트 하니 해결되었다..
 
2006년에 수정된 버그인데, 몇날 몇일을 이것 때문에 시간을 허비한 것인지.. preparedStatement를 MS SQL 2000에서 수행할때 나는 버그였다.. 2005에서는 발생하지 않았다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

데스크탑 어플리케이션 개발시 잡기 힘든 버그 중 하나가 가끔씩 일어나는 크래쉬.. 언제 죽는다, 재현을 해보기 힘든 비정상 종료상황이 발생하는 경우는 죽는 상황을 어떻게 하면 재현할 수 있다는 정보를 수집하기가 상당히 어려운 부분이 있다..

다행히 윈2000 이상의 윈도우 시스템에서는 Dr Watson 이라는 꽤 괜찮은 기본 디버거가 윈도우 시스템에 기본 탑재가 되어 있다.. 메트 피에트릭이 소개한 SEH 처리용 클래스를 활용하는 방법 보다는 훨씬 더 많은 디버깅 관련 자료를 제공해주는 덤프를 작성해 줄 수 있기 때문에 Dr Watson을 활용하는 방법이 좋다고 생각한다.. (SEH 처리용 클래스에 관련된 보다 더 많은 정보 참고)

실행시킨 모습은 위와 같은데, 로그파일과 크래쉬 덤프를 위와 같이 세팅한 대로 남겨준다.. 이렇게 남은 정보는 위에서 이야기한 기사에 소개된 SEH 처리용 클래스가 남기는 정보보다 훨씬 더 유용한 정보들을 많이 남겨준다.. 하지만, 위 그림과 같이 저장되는 경로만 내가 원하는 곳으로 저장해둔다고 동작하는 것은 아니다.. 잊지말고 반드시 해줘야 하는 작업, 하지만 막상 하려면 명령어가 생각나지 않는 작업을 해줘야 한다..

명령행에서 "drwtsn32 -i" 라고 쳐줘야 Dr Watson이 기본 디버거로 설정이 되면서 정보를 남겨주게 된다..

그럼 이 정보를 제대로 활용하는 방법은? 인터넷에서 검색을 통해 더 좋은 자료를 찾을 수도 있겠지만, 지금까지 내가 알기로는 Debugging Applications라는 책이 가장 좋은 활용법을 알려준다..

언제 죽는지 모르는 버그에 시달리고 있다면, 개발자 자신의 PC의 세팅을 이렇게 남겨두면 어떨까?

더 나아가 우리가 배포하는 사용자 PC의 환경도 이렇게 바꿔두면 어떨까? 사실 사용자의 PC 환경을 우리가 만든 어플리케이션이 맘대로 조작한다는건 상당히 기분 나쁜 일일 수도 있다.. 더구나 내가 만든 프로그램의 사용자 역시 프로그래머다.. 그런데 그 사람이 사용하는 기본 디버거가 따로 있는데, 이게 Dr Watson으로 어느날 갑자기 바뀌었다.. 이건 좀 아니긴 하다.. 하지만, 많은 경우에 기본 디버거를 바꿔버리고, 우리가 원하는 위치에 크래쉬 덤프를 남기고 그것을 우리가 수집할 수 있다면 여러 사용자 환경에서 발생하는 오류에 대한 대처에 더욱 능동적일 수 있지 않을까?

최소한 사용자 동의를 얻어 진행할 수 있는 클로즈 베타, 혹은 베타 서비스 기간에는 이를 적용하여 크래쉬에 대한 정보를 적극적으로 수집하는 것도 좋은 방법일 것이다..


추가내용 : jrogue님이 알려주신 주옥같은 정보..

1. Dr Watson은 윈도우 설치시 사용할 수 있는 기본 디버거.. 별도로 세팅하지 않아도 크래쉬 정보를 수집할 수 있다.. 난, 개발툴을 설치했기 때문에 Dr Watson이 기본 디버거가 아니었던 것이다..

2. Dr Watson에 관련된 좋은 정보

3. Dr Watson의 로그파일을 점검하는 방법에 관한 정보

음.. 이쯤되면, 무식한 덕에 제목을 완전 잘 못 달았음을 알 수 있다.. Dr Watson은 원래 윈도우즈의 기본 디버거였던 것이다.. 이름은 아마도 셜록홈즈 소설에 나오는 바로 그 왓슨 박사에서 따온 듯 하다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

96년도에 졸업하고 사회생활을 하면서 가장 처음으로 접한 DB서버가 MS SQL 6.5였다.. 그래서 그런지, 오라클 보다는 MS SQL에 더 정이 가는가보다.. 첫인연도 그렇지만, 사용하기에 MS SQL 서버가 훨씬 편리하다는 특징이 더 이런 상황을 만들었을 것이라 생각한다..

MS SQL 서버의 편리함은 인스톨과정에서 부터 조금만 사용해보면 바로 나타난다.. 설치, DB 생성, 백업, 백업으로부터의 복구 등등의 과정을 프로젝트 진행간 자주 해보면 MS SQL 서버를 사용해보면 편리하다.. mySQL 같이 간편하면서, 성능은 오라클 못지 않는다고나 할까.. 뭐, 이렇게 말하면 오라클 유저들에게 한 소리 듣는다.. 어떻게 오라클과 MS SQL을 성능 비교를 할 수 있느냐, 비교할 것을 해야지.. 하지만, 난 MS SQL과 오라클의 성능차이는 거의 없다고 생각한다..

아무튼, MS SQL 서버를 사용하면서 가장 편리한 점은 DB 복사를 손쉽게 할 수 있다는 것이다.. 예를들면 개발중인 DB서버에서 이 DB를 다른 서버에 그대로 복사본을 만들고 싶으면 DB 파일만 새 서버에 복사를 해서 새 MS SQL 서버에서 파일로 DB에 연결만 하면 끝이다.. 오라클에서는 이 과정이 꽤 복잡하다..

하지만, 이때 좀 귀찮은 경우가 생길때가 있다.. 위와 같은 방법으로 A서버에 CBT라는 DB를 B서버에 똑같이 만들어서 A서버에서는 계속 개발을하고 B서버에서 단위테스트를 진행을 했다.. 그러다 DB가 변경된 부분들이 생겨서 B서버에 DB를 다시 옮겨야 한다.. 이때도 B서버의 CBT DB를 없애고 위와 같은 방법으로 새로 붙이면 되는데 문제는 계정이 좀 꼬이는 경우가 생긴다..

A서버에서와 같은 이름과 패스워드 계정으로 CBT DB에 접근하고 싶은데 이미 계정이 있으니 만들 수 없다는 둥, 이런 문제가 발생하는 것이다.. 정말 큰 문제는 이런 경우 MS SQL 엔터프라이즈 메니저 (2000이하) 혹은 SQL Server Management Studio (2005이상)가 제공하는 UI 상에서는 이 문제를 해결할 수 있는 방법이 없다.. 모든 작업을 커맨드 라인이 아닌 UI에서 하는 MS SQL 서버의 특징에 위배되는 상황이다.. 하지만, 뭐 방법없다.. UI에서 제공 안해주니 별 수 없지.. 쿼리를 날려 해결해야 한다.. 이때 사용하는 스토어드 프로시저가 sp_change_users_login 이다..

이 스토어드 프로시저를 사용하지 않으면 해결할 수 있는 방법이 없는데, 도움말에서 이거 찾기도 쉽지 않다.. 쩝..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

새로운 OS가 나오게 되면 가장 관심을 가지는 것은 과연 내가 만든 프로그램이 새 OS에서 정상적으로 동작할 것인가 하는 점이다.. 윈95가 등장할때 그랬으며, 윈98, 윈ME, 윈2000, 윈XP 등등.. 이번 윈도우 비스타도 예외는 아니었지만, 그러면서도 안심이 되는 부분은 MS가 새 OS를 내 놓을때 가장 신경을 많이 쓰는 부분이 다름아닌 하위호환성 보장이라는 것.. 새 OS들이 나올때마다 걱정은 했지만, 별 일 없이 넘어갈 수 있었던 것이 바로 이 부분 때문이었으며, 이번에도 큰 어려움 없을 것이라는 안일한 자세.. 사실 윈3.1에서 윈95로 넘어갈때 말고는 큰 일이 없었던것이 사실이다.. (Microsoft가 그렇게 중요시 하는 하위호환성에 대해 자세히 느껴보고 싶으면 조엘 온 소프트웨어를 읽어보시길..)

하지만, 윈도우 비스타는 달랐다.. 많이 달랐다.. 윈XP에서 잘 돌아가는 프로그램을 윈도우 비스타에서 돌아가게 만드는데 무려 2달 정도가 걸렸다.. 물론, 다른 일들이 많아 팀원 전체가 붙어 대응을 하지 못해 오래 걸리긴 했지만, 애초에 예상했던 것 보다는 훨씬 오래걸린 대응 준비기간이었다..

우리 프로그램의 문제점
- ActiveX 컨트롤
- 레지스트리
- 파일저장
- 프로세스 생성
- 윈도우 메시지 전달

ActiveX 컨트롤은 사실 아무런 문제없이 윈도우 비스타로 옮길 수 있다.. 윈도우 비스타라고 해서 ActiveX 컨트롤이 없으질게 아니고 (Silverlight도 윈도우 환경에서는 ActiveX로 구현되며, 플래쉬, 애크로뱃리더도 ActiveX로 구현되어 있기 때문에 대체기술이 나오기 전에는 없어질 리가 없기 때문에.. 대체기술은 웹표준이 그래픽과 멀티미디어쪽으로 확정되기 전에는 오랜기간 없을 것으로 보인다..) 기본적으로 우리 프로그램도 아무런 문제가 없었지만, 레지스트리와 파일억세스를 하는 부분이 많았다..

레지스트리 접근은 HKEY_CURRENT_USER 하위는 읽고 쓸 수 있기 때문에 위치만 옮기면 아무런 문제가 되지 않는다.. 물론, 현실에서는 이 위치를 공유하는 프로그램들이 많을 수 있고, 어떤 프로그램에서는 위치를 변경하는게 만만한 작업이 아닐 수 있기 때문에 현실은 그리 녹녹치 않을 수도 있다.. 가장 좋은 방법은 레지스트리 사용은 아예 하지 않도록 수정하는 방법이 정답이다.. 하지만, 우리 프로그램은 새 버젼이 개발중이었으므로 최소한의 노력을 들이기로 했다..

파일저장 부분도 사실 큰 어려운 부분은 아니지만, 레지스트리의 경우와 비슷하다.. 권한이 없는 폴더에는 접근하지 않도록 수정해줘야 한다.. 특히, 권한을 가진 프로그램이 만들어둔 파일을 다른 프로세스에서 접근해야 하는 경우 문제가 생길 수 있다.. 가장 문제가 되는 것이 ActiveX 컨트롤이 접근해야 하는 경우인데, 이 경우는 ActiveX 컨트롤이 해당 파일에 접근할 수 있는 방법이 없으므로 권한이 낮은 프로세스에서도 접근 가능한 위치로 옮겨야 한다..

프로세스 생성은 비교적 간단하다.. ShellExecute에 추가된 파라미터를 넣어 높은 권한으로 실행시킬 수 있는 방법이 있기 때문이다.. 하지만, 원래 권한이 낮은 곳에서 (다른 프로세스나 ActiveX 컨트롤이) 높은권한의 프로세스를 실행시키는 일이라 권한상승 경고창이 뜬다..

윈도우즈 메시지 전달은 사실 별로 신경을 쓰지 못했던 부분인데, 낮은 프로세스에서 높은 프로세스로 메시지를 보내는 것은 사정없이 무시된다.. 특히, ActiveX 컨트롤이 실행파일을 실행시킨 후에 메시지를 통해 데이터를 전달하는 구조의 경우 문제가 된다..

하지만, 위의 문제들을 해결하기 위해 그동안 여러가지 검토를 하고 테스트 코드를 짜며 든 생각은 과연 무엇이 더 좋아졌는가 이다.. 좋아진 부분이 딱 하나 있기는 하다.. 권한이 상승된 프로세스가 허락없이 실행될때 경고창이 뜬다는 것이다.. 이점은 나 몰래 어떤 프로그램을 실행시키기가 더 어려워 졌다는 점에서 보안이 강화되었다고 할 수 있는데, 이외의 것들은 소위 하위호환성 때문에 조금만 코드를 고치면 XP에서 동작했던 것 처럼 동작하도록 수정할 수 있다.. 어찌 보면 내가 예상한대로였는데, 작년말쯤 팀원들과 이야기 하던 내용이 기억난다.. "그렇다면 좋아질게 하나도 없는데, 그렇게 고칠거면 뭐하러 고치나?"

열심히 함 고쳐보라는건가? 뭐하러 이런 소모적인 해야 수정을 하는지 모르겠다.. 되먹지 않은 악성 프로그램을 배포하는 사람들이 코드 좀 수정해서 비스타에서도 동작하도록 만들게 하기 위해, 전 세계 수많은 프로그래머들이 비스타에서 돌아가는 프로그램을 위해 코드를 수정하게 만들어야 했는가? 하위호환성 때문에 피해가는 방법이 다 존재한다면, XP에서 문제없이 돌아가는 프로그램은 비스타에서도 그냥 돌아가도록 하는게 더 좋았을 것이다.. 그렇다 하더라도 권한상승창 때문에 원래의 목적은 달성할 수 있었을 것이다.. 참, 아쉬운 부분이다..

권한 상승창이 뜨는 부분은 비스타 사용자들로부터 많은 이야기가 나올 것인데, 윈도우 비스타에서 깔끔하게 돌아가는 프로그램을 만들기 위해서 (권한상승 허가하는 창이 뜨지 않고 동작하도록)는 앞으로는 개발초기 설계시부터 잘 고려를 해야하겠다..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.