김 용묵의 절대공간 - 블로그

C 언어 표준 라이브러리에는 잘 알다시피 배열 데이터에 대해서 간단한 검색과 정렬 알고리즘을 구현해 놓은 함수가 존재한다.
정렬을 수행하는 qsort()가 대표적인 예이고, 이미 정렬된 배열에 대해서 이분 검색을 수행하는 bsearch()도 유용하다.

이들 검색과 정렬 함수는 비슷한 형태의 인자를 받아서 동작한다. 배열을 가리키는 포인터, 각 원소의 개수와 크기, 그리고 찾고자 하는 원소의 값, 그리고 비교 함수의 포인터이다. 비교 함수는 두 원소의 비교를 수행하여 대소 관계를 리턴값의 부호 또는 0 여부로 알려 주어야 한다. 이렇게 함으로써 int든 float든 그 어느 자료형이라도 범용적으로 검색하거나 정렬을 수행할 수 있다.

그런데 C 언어는 이분 검색뿐만 아니라 선형 검색을 하는 함수도 제공한다. 찾는 원소와 같은 값이 나올 때까지 배열을 처음부터 끝까지 단순히 뒤지기만 하는 알고리즘 말이다. 동작 방식은 단순하기 그지없지만, 이분 검색과 더불어 그냥 일관성을 위해서 선형 검색도 함수로 표준화한 듯하다. 선형 검색이 받아들이는 비교 함수는 두 값의 대소 비교를 할 필요가 없이 두 값이 단순히 같으면 0, 그렇지 않으면 nonzero만 되돌려도 된다.

그런데 본인은 C 언어가 제공하는 선형 검색 함수의 형태를 보고는 놀라지 않을 수 없었다.

1. 이분 검색이 bsearch이니 선형 검색은 응당 lsearch일 거라고 본인은 생각했다. 그런데 선형 검색 함수는 _lsearch와 _lfind로 나뉘어 있고, 어찌 된 이유인지 함수 이름 앞에 밑줄이 추가돼 있다. 이분 검색과 정렬 함수는 stdlib.h에도 선언이 되어 있는 반면, 선형 검색 함수는 거기에 없으며 반드시 생소한 search.h를 인클루드 해 줘야 한다. 왜 이런 차이가 존재하는지부터 의문이다.

2. _lsearch는 원소를 찾아서 이게 배열에 존재하지 않으면, 그 원소를 배열의 끝에다가 추가를 한다. 따라서 이 함수는 매개변수만 올바르다면, 원하는 원소가 배열에 없다고 하더라도 NULL을 리턴하지 않는다. 그 반면 _lfind는 read-only 함수로, 원하는 원소가 없으면 NULL을 되돌린다. 그러므로 정확하게 bsearch 함수의 동작 방식만 선형 검색의 형태로 원한다면 _lsearch가 아닌 _lfind를 써야 한다.

3. bsearch와는 달리, 선형 검색 함수는 배열 원소의 개수를 넘겨주는 인자가 포인터형이다. 그것도 size_t도 아닌 unsigned int의 포인터이기 때문에 64비트 환경에서도 여전히 32비트 값 전달만 가능하다는 한계마저 그대로 지닌다. ㅜ.ㅜ 왜냐하면 _lsearch의 경우, 원하는 원소가 배열에 존재하지 않아서 그 원소가 배열 뒤에 추가되었을 경우, 배열 원소 개수를 1 증가시켜 주기 위해서이다.

그러나 배열 원소 추가를 하지 않는 _lfind라면 배열 원소 개수 인자가 포인터여야 할 필요가 전혀 없고 bsearch처럼 size_t 값을 그대로 받기만 하면 된다. 왜 _lfind까지 _lsearch처럼 그렇게 포인터를 받게 해 놓았는지 모르겠다.

Posted by 사무엘

1.
병특 회사에서 근무하던 시절의 일이다.
그때 본인은 본업을 넘어-_-, ActiveX 컨트롤을 만들어 관리하던 적이 있었다.
(사용자들이 아무리 ActiveX 욕하고 우리나라가 무슨 MS 공화국이네 뭐네 하면서 까도, 일선 개발자들은 위에서 까라면 깔 수밖에 없다. 더구나 본인은 국방부 시계가 돌아가던 중! ^^;;; )
ActiveX는 내부에 플래시 UI를 하나 만들어서 플래시는 웹 상에서 사용자와 소통을 하고, ActiveX는 플래시와 소통을 하면서 플래시만으로 하기 힘든 네이티브 코드를 수행했다. 내가 왕년에 저런 일까지 했다니..

그런데 문제가 있었다. 정확하게는 기억이 안 나지만, ActiveX든 플래시든.. 뭔가 로컬에 있는 파일을 참조하는 건 아무 문제가 없었는데 웹에 있는 놈을 가져오는 건 아무 이유 없이 도무지 되지 않고 작동을 거부하는 것이었다.
먼 옛날 일이 됐으니 망정이지, 이것 때문에 당시 회사에 환멸을 느낄 정도로 좌절하고 삽질했었다. -_-;;

문제의 원인은 보안이었다. 그 당시 갓 출시된 플래시 7이던가 8이던가.. 하필 그때부터 보안 정책이 딱 바뀌어 플래시의 액션스크립트는 아무 웹에서나 정보를 덥석 가져오지 못하게 되었다.
그 반면, 내 로컬 컴퓨터의 ....\flash player\#security\flashplayertrust 이런 디렉터리에다가 configuration file을 만들어서 접근을 허용하는 웹 주소를 먼저 적어 줘야 하고, 플래시는 허용된 웹으로만 접근할 수 있다.
자세한 정보: http://kb2.adobe.com/cps/116/1165eb90.html

어쨌든 이것 때문에.. 가장 권한이 많고 강력한 ActiveX가 DllRegisterServer를 통해 등록될 때 저 flashplayertrust에다가 우리 플래시에 대한 정보를 덩달아 등록해 주고, 등록 해제될 때 그 정보를 삭제하도록 함으로써 문제는 일단락되었던 걸로 기억한다. ActiveX는 네이티브 코드인 관계로 파일, 레지스트리, 웹 등에 다 접근이 되고, 심지어 Win32 API를 직접 호출해서 뭐든 다 할 수 있으니.. 사기 유닛이다.

물론 오늘날은 다른 웹 표준과 RIA 기술도 풍부한데 저런 무식한 방법을 쓰는 건 곤란하다.
참고로 플래시에 전설의 flv 동영상이 추가된 게 그 무렵부터일 것이다. 유튜브가 그때 막 태동했으니 말이다. 플래시가 벡터 드로잉 애니메이션뿐만 아니라 일반 비디오 플레이어 분야도 섭렵하기 시작했으며, 덕분에 이제 인터넷으로 동영상 볼 때 ActiveX 설치를 요구하는 사이트는 개념 없다는 소리를 듣기 시작하게 됐다.

2.
안드로이드 어플 만들면서도 비슷한 경험을 했다. 아놔 다른 프로그램에서는 잘 되는 환경설정 변경이 왜 도대체 안 되고, 기껏 되더라도 왜 내가 바꾼 환경설정이 다른 곳에 도무지 적용이 안 되는지.. 함수 호출 결과는 성공인데.. 그 뒤 결과는 그냥 씹히고 있던 것이다.
하루를 삽질하고 났더니 원인은 역시 매니페스트 파일에다가 android.permission.WRITE_SETTINGS , android.permission.CHANGE_CONFIGURATION 요 따위 퍼미션 요청을 안 해 놨기 때문이었다.

3.
그동안 유닉스 계열 OS에 비해 권한이나 보안 같은 관념이 너무 약하던 윈도우도, 비스타부터는 그쪽으로 좀더 엄격해졌다.
잘 알다시피 사용자 계정 컨트롤(UAC)라는 게 추가됐으며, 프로그램을 관리자 권한으로 실행할 때와 그렇지 않을 때에 허용되는 권한의 차이가 매우 커졌다. 가령, 관리자 권한이 아니면 '내 문서' 말고 다른 디렉터리에다가는 파일을 제대로 만들지도 못한다.

그리고 이 프로그램이 요구하는 권한을 명시하는 게 가능해졌다.
아무 권한에서나 실행 가능한지, 무조건 관리자 모드에서 실행돼야 하는지 하는 걸 말이다.
지정은 EXE 내부의 매니페스트 XML에다가 하면 된다. 그 개념은 이미 윈도우 XP에서 시스템 DLL의 로딩 방식을 제어하기 위해 도입된 바 있으므로 새삼스러울 게 없다.
비주얼 C++ 2008부터는 링커 옵션에 이걸 바로 지정해 주는 게 추가됐다. 그 이전 버전에서는 사용자가 직접 xml 파일을 손으로 써서 링크해 주면 된다.

스크린 키보드처럼 장애인 Accessbility용 프로그램은 의외로 높은 보안 수준이 필요하다.
내가 받은 입력에 대한 결과를 시스템 모든 프로그램에다가 끼쳐야(키보드 입력 흉내) 하기 때문에
이런 프로그램은 별도의 인증을 거쳐야 운영체제가 그 정도의 권한을 허락하게 되어 있다.
그런 인증을 거치지 않은 "<날개셋> 입력 패드"는, 사용자가 직접 관리자 권한으로 실행해 주지 않으면,
자기보다 권한 등급이 높은 프로그램에다가는 글자 입력을 전달해 줄 수 없다.

글을 맺는 소감:
삽질해야 하는 게 싫다. -_-;;
지금 유닉스 명령어 익히느라 땀 뻘뻘 흘리는 걸 보면, 옛날에 지금보다 영어도 훨씬 더 못 하던 시절에 도스 명령은 어째 알아서 외웠는지 궁금하다.
지금 이놈의 안드로이드 때문에 삽질하는 걸 보면, 옛날에 윈도우 API는 어째 공부했는지 내가 생각해도 나 자신을 이해할 수 없다.
그때는 삽질을 삽질이라고 여기지 않고 전적으로 재미로 했기 때문에 프로그래밍에 재미를 붙일 수 있었던 것 같다.

Posted by 사무엘

1. PentaCombat (마지막 빌드 2000): 2000년대 이후로 개발이 중단됐다. (그 당시 이 프로젝트 이후 곧장 <날개셋> 한글 입력기 개발로..) 나름 3*3과 4*4 판단 알고리즘을 굉장히 정교하게 구현해 냈고 오목은 AI 연구용으로도 굉장히 재미있는 주제라고 생각했는데, 더 개발을 못 하게 된 게 무척 아쉽다. 지금 공개되어 있는 컴파일 EXE, DLL은 무려 비주얼 C++ 4.2로 빌드되었으며, 날짜도 1999년~2000년대이다. ㅎㄷㄷ

2. WordTech (마지막 빌드 2007): 이것도 굉장한 애착을 갖고 있는 프로그램이다. 국내에서 스크래블/업워드 크로스워드 게임을 자체 개발한 사례는 이 프로그램이 유일하기 때문이다. 그것도 컴퓨터 AI에다 네트워크 기능까지 말이다.
지금은 10년 전보다 더 효율적인 단어 목록 자료구조와 더 빠르고 똑똑한 AI 알고리즘을 만들 수도 있다. 그리고 네트워크 쪽도 구닥다리 DirectPlay 대신 저수준 네트웍 API로 새로 짤 필요도 있다. 하지만 본인은 이제 이걸 도저히 손댈 수 없는 처지가 됐다.

3. <날개셋> 타자연습 (마지막 빌드 2009): 더 무슨 말이 필요하리요? 게임은 좀 3D로 고쳐야 하고 각종 바이러스들의 비주얼 효과도 더욱 현란하게 고쳐야 한다. 윈도우 비스타부터는 운영체제의 기본 내장 게임조차 Direct3D를 쓰는 세상이 되지 않았던가.
그리고 네트워크 기능을 적극 도입하여 온라인 타자방, 실시간 연습글 업데이트 같은 기능도 넣어야 한다.
하지만 타자연습도 작년 말 3.21을 끝으로, 더는 내가 더 손을 볼 수 없는 사실상 개발 중단 상태가 되지 않을까 싶다. (지원 중단이라는 뜻은 아님. 여건상 새로운 기능을 추가하지는 못하지만, 버그 패치나 보안 업데이트 정도만. ㅎ)

4. <날개셋> 한글 입력기: 그나마 지금까지 독자적인 아이템으로, 10년간 가장 열정적으로 기능 연구와 개선을 해 온 프로그램. 엔진 쪽도 사실 최하 6.0까지는 더 만들고 싶지만 현실은 5.7, 혹은 5.53에서 끝날지도 모르겠다. 엔진 차원에서 더 고차원적인 개념을 생각하자면 끝도 없지만, 일반 사용자의 관점에서는 지금 엔진만으로도 기능은 이미 너무 많아서 미처 다 활용도 못 할 수준이리라.
지금의 5.5x대 엔진을 바탕으로 아무래도 여타 운영체제 포팅을 할 가능성부터 먼저 찾는 걸로 계획을 수정해야 할 것 같다. 그것부터 된 후에 여건이 남으면 엔진 작업도 더 할 것이다.

본인에게는 <날개셋> 한글 입력기만큼이나, 한글과 관련된 또 완전히 다른 솔루션을 연구하고 싶은 게 있다. 시기가 시기이니만큼 이 카드도 슬슬 꺼내 봐야 할 것 같다. 그러니 언제까지나 기존 아이템의 유지 보수에만 매달려 있을 수가 없다. 지저분한 윈도우 IME 쪽 버그 살펴보는 것도 한계가 있다.

이런 식으로 사람은 점점 발전하는 것 같다.
역시 어렸을 때, 실패에 대한 위험 부담 내지 사회적 책임이 적을 때 하고 싶은 일을 실컷 해 놔야 한다. 게임으로 허비하기엔 인생은 너무나 아깝다.

고등학교 3학년 때 과감하게 <날개셋> 한글 입력기 1.0을 만들었기 때문에 10년 뒤에 이것이 5.5까지 버전이 오를 수 있었다.
그리고 그 전에 허접하게나마 저 두 보드 게임을 만들었기 때문에 그 기술과 경험을 근거로 이듬해에 <날개셋> 한글 입력기 1.0이 만들어질 수 있었다.

저 프로젝트들 생각만 하면 그나마 프로그래머다운 기질이 팍팍 살아나는 걸 느낀다. 하지만 나는 순수 공돌이나 전산학도는 아니기에, 내 경쟁력을 위해서는 아무 프로그램이나 짜서는 안 되고, 컴퓨터를 수단으로 삼아 다른 특정 분야에서 활로를 찾아야겠다.

Posted by 사무엘