프로그래밍 잡설

1. 닷넷 기반 프로그램의 특징:

- 뜨는 데 시간이 좀 오래 걸린다.
- 파일 내부를 들여다보면 전통적인 네이티브 프로그램처럼 kernel32, user32, gdi32 따위가 아니라, mscoree.dll에 대한 Dependency만 있다.
- 생성하는 GUI 윈도우들의 클래스를 보면 WindowsForm10 이런 명칭으로 시작한다.
- 같이 들어있는 DLL들이 '뭐.뭐' 이런 식으로 대소문자가 섞이고 중간에 마침표도 있는 등, 이례적으로 이름이 긴 경향이 있다. 네이티브 EXE/DLL은 그런 식으로 작명되는 경우가, 금지되거나 불가능한 건 절대 아님에도 불구하고, 거의 없다. 유닉스 내지 심지어 도스 시절 8.3 영향을 받은 짧고 암호 같은 영어 알파벳 조합이 아직까지 대세.

유명한 닷넷 프로그램으로는 MS Keyboard Layout Creator, Paint .NET이 있다. 비록 닷넷 기반으로 비주얼 베이직.NET과 C++ managed extension 같은 언어도 있긴 하지만, 그래도 90%이상의 여건에서는 닷넷이 곧 C#이나 마찬가지이다.

게임 자체는 모르겠지만, 최소한 게임과 관련된 툴 정도는 C#으로 만드는 게 충분히 승산이 있는 단계에 이른 것 같다. 스타크래프트의 StarEdit처럼 고객이 사용하는 툴이든, 게임 개발사 내부에서 디자이너나 기획자가 쓰는 툴이든 말이다. C#은 일종의 가상 기계 프레임워크 기반이면서도 로컬 환경 역시 적당하게 잘 공략한 것 같다. 이제 MFC는 덩치가 커져도 너무 커졌고, C#은 빌드 속도 같은 생산성 면에서 C++을 압도적으로 능가한다.

게임 클라이언트에 이어 게임 서버까지 C#으로 만들어 돌리는 날이 과연 올지는 모르겠다. 컴퓨터의 성능이 계속 향상되니까 괜찮을 거라는 말이 있지만, 그래도 과거에 C/C++은 어셈블리와 일대일 대응하는 최소한 네이티브 코드 생성 언어이지 않았던가.
다만, 아직은 C# 프로그램이 네이티브에 비해 느린 건 둘째치고라도, 앞서 말했듯이 좀 무겁다는 인상이 짙게 느껴진다. (뜨는 데 걸리는 시간) 이게 좀 개선됐으면 좋겠다. 듣자하니, MS는 내부적으로는 C# 코드를 산뜻한 네이티브 코드로 빌드해 주는 컴파일러를 보유하고 있다는데..;;

2.
본인, 전공이 전공이다 보니 소위 '국어 정보 처리' 분야의 프로그램들을 좀 접했다. 형태소 분석, 말뭉치 검색 등.
비주얼 C++ + MFC로 만들어진 게 다수이지만 2005년 이후부터는 C#을 쓴 것도 심심찮게 보인다. 다만, '깜짝새'라고 유명한 프로그램이 있는데, 얘는 이례적으로 델파이로 개발됐다.

이런 프로그램들은 그 특성상, 결과 데이터를 마치 스프레드 시트처럼 row-column 형태의 출력하는 경우가 많다. 그런데 순수하게 처리를 하는 비용뿐만이 아니라, 처리가 끝난 결과 데이터를 해당 리스트 컨트롤에다 등록하는 데 걸리는 시간도 만만찮아서 본인은 그게 불만이다. 결과 출력하느라 리스트 컨트롤의 스크롤바가 쫘르륵~~ 변하는 모습을 보고 있으면 좀 민망하다. 불필요한 화면 refresh가 수천, 수만 회 발생하고 있다는 뜻이지 않은가?

대용량의 데이터를 그런 형태로 출력할 때는, owner-draw라든가 virtual list control 테크닉을 써서, 결과 데이터를 일일이 리스트 컨트롤로 복사하는 게 아니라, 그때 그때 출력을 내가 직접 하도록 해야 한다. 이렇게만 하면 프로그램의 체감 동작 속도가 월등히 빨라지며 메모리도 크게 아낄 수 있다.
도스 시절이었다면 리스트 컨트롤 같은 컴포넌트라는 개념 자체가 없었을 터이니 이런 비효율 자체가 존재할 여지가 없었을 것이다. 물론, 소프트웨어의 재활용성면에서 도스는 어차피 빵점인 열악한 환경이니 도스 시절이 마냥 좋다는 건 아니다.

저런 프로그램들이 어떤 여건 속에서 개발되었는지 잘은 모르겠다. 허나, 열악한 자금과 시간에 쫓기면서 공밀레 공밀레 하면서 만들어진 프로그램이라면, 개발자가 아무리 날고 기는 천재 프로그래머라고 해도 답이 없다. 품질을 보증할 수 없고, 이런 자그마한 곳에서의 사용자 배려 따위는 절대로 기대할 수 없다. 이는 개인의 프로그래밍 실력과는 하등 관계 없는 문제이다.

그 반면에 <날개셋> 한글 입력기가 가히 변태적인 수준의 최적화를 자랑하며 개발되고 있는 이유는 시간과 돈에 전혀 구애받지 않고 전적으로 개인의 자아 실현을 위해 만들어지는 프로그램이기 때문이다. -_-;; 언제까지나 그런 태도로 프로그램을 만들 수는 없으니까 그게 문제지만.
이런 문제를 이쪽에 계시는 교수님들도 인지는 하고 있지만, 우리나라 IT 인프라에 전반적으로 딱히 답이 안 보이는 문제이니 어쩔 수 없다.

3.
C/C++ 부류의 type 시스템은 액세스(MS Access)와 비슷하고,
파이썬 부류의 type 시스템은 엑셀(MS Excel)과 비슷하다. 진짜 딱 대응하는 것 같다.

스프레드 시트인 엑셀은 아무 셀에 아무 타입의 데이터나 바로 집어넣을 수 있으며, 그러면 그 형태를 엑셀이 알아서 인식해서 출력해 준다. 날짜는 날짜처럼, 문자열은 문자열처럼, 숫자는 숫자처럼 오른쪽 정렬을 해서.
그러나 데이터베이스 프로그램인 엑세스는 테이블을 설계할 때 모든 애트리뷰트와 각 애트리뷰트에 들어갈 수 있는 값의 타입을 지정해야 하며, 딱 그 값만 넣을 수 있다. 문자열은 길이 제한까지도 생각해야 한다. 정말 딱딱하고 까다롭다.

엑셀은 셀의 값들에 서식도 자유롭게 지정할 수 있고 Undo도 얼마든지 가능하다. 엑세스는 그런 게 없으며, 테이블을 수정한 게 파일에도 바로 반영된다.

그러나 수십, 수백만 개에 달하는 데이터를 검색하고 한꺼번에 고치고, 테이블 간의 관계를 분석하는 동작에서 엑셀과 엑세스의 효율은...;; 더 설명이 필요하지 않을 것이다.

그럼에도 불구하고 엑세스 급의 전문적인 성능이 필요한 경우는 매우 드물다. 일반 사용자들은 어지간한 중소 규모의 데이터나 다룰 것이고 이때는 친근한 엑셀이 대부분의 경우 훨씬 더 도움이 될 것이다.

4.
PC 파워 유저라면, 윈도우용 EXE 파일에는 리소스라는 별도의 데이터 섹션이 있다는 걸 알 것이다. 윈도우용 EXE는 이례적으로 자체 아이콘을 갖춘 파일 포맷인데, 그것도 바로 리소스라는 형태로 들어있다. 운영체제는 EXE/DLL의 리소스를 조작하는 API를 제공하며, 이를 이용하면 프로그램의 메뉴, 메시지 문자열을 고쳐서 허접하게나마 프로그램을 한글화(자국어화)할 수도 있다. 물론, 모든 프로그램에 그런 테크닉이 통하는 건 아니지만.

이 일을 프로그래밍을 통해서 하려면 BeginUpdateResource, UpdateResource, EndUpdateResource라는 함수를 쓰면 된다. 다만, 윈도우 9x는 이 기능을 지원하지 않았으며 그건 NT에서만 지원됐다. 그런 기능을 어차피 일반 사용자가 쓸 일은 없었을 테니까.
그런데 신기하게도 그 당시 윈도우 9x에서 실행된 비주얼 C++ 6은, 32비트 EXE/DLL의 리소스를 고칠 수는 없었던 반면, 16비트 EXE/DLL의 리소스를 고쳐서 저장할 수는 있었다.

윈도우 API를 쓴 건지, 아니면 16비트 바이너리는 비주얼 C++의 자체 기능으로 파일을 건드렸는지는 잘 모르겠다. 다만, 16비트 바이너리와 32비트 바이너리는 리소스를 저장하는 방식이 상당히 다르기 때문에 아마 자체 기능이 아니었겠나 싶다. 근본적으로 32비트 바이너리는 wide character 유니코드를 사용하지만 16비트 바이너리는 그렇지 않다. 그래서 과거에 윈도우 3.1에다가 Win32s를 설치하면 각종 시스템 DLL뿐만이 아니라 유니코드 변환 테이블인 NLS 파일들도 잔뜩 설치됐던 것이다.

Posted by 사무엘

2011/07/06 08:09 2011/07/06 08:09
,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/536

Trackback URL : http://moogi.new21.org/tc/trackback/536

Comments List

  1. 아라크넹 2011/07/06 13:42 # M/D Reply Permalink

    상용 게임 서버 중 일부는 이미 C#으로 옮긴 곳도 있다고 알고 있습니다. 네이티브에 비해 크게 성능 차이도 나지 않고(보통 서버 프로그래밍은 I/O 성능과 서버 아키텍처에 큰 영향을 받죠) 그러면서도 심각한 버그를 더 잘 피할 수 있다는 장점이 있으니까요. 클라이언트 쪽이 모조리 C++를 버릴 시점은 아직 멀지 않았나 싶습니다만, 자바(!!!)로 클라이언트랑 서버 둘 다 짜서 성공한 마인크래프트(엄밀히는 lwlgl이라는 OpenGL 라이브러리가 있습니다만) 같은 걸 보면 그래픽에 민감하지 않은 게임은 전환이 이미 한참 진행 중이라고 봐도 될 듯 합니다.

    1. 사무엘 2011/07/06 17:20 # M/D Permalink

      설마 했는데 이제 서버에까지 닷넷이 본격 들어오고 있군요. 덜덜;;
      하긴, C#은 성능이 떨어지는 것에 비해 C++보다 프로그램 짜기는 너무 편리하고 좋은 건 부인할 수 없습니다.

  2. 남정현 2011/07/07 09:56 # M/D Reply Permalink

    MS Research에서 개발 중인 OS 중에 Singularity OS가 말씀하신 C# to Native Compiler인 Bartok Compiler를 기반으로 짜여진 것이긴 합니다. Bartok 컴파일러가 지원하는 C#의 비표준 사양을 보면 Native Code와의 연계를 목표로 만든 몇 가지 특수한 설정, 가령 printf 등에서 사용하는 가변인자 포인터에 대한 핸들링 기법 등이 포함되어있고 이에 대한 흔적이 MS가 공개한 Rotor Framework 소스에도 들어있습니다. 그리고 최근 MS가 성능을 위해서 채택하는걸 보면 C# Only보다는 하단에 Native를 사용하고 상단을 C#으로 커버하는 경우 (WPF나 실버라이트)도 많이 보이죠. ㅎㅎ

    1. 남정현 2011/07/08 10:43 # M/D Permalink

      응용프로그램의 성능이라는 축과 개발자의 생산성이라는 축은 서로 상충되는 면이 있다보니 어떤걸 어느 시점에 잘 취사선택하는가는 굉장히 중요한 이슈가 되는것 같긴 합니다. ㅎㅎ

      아, 그리고 홈페이지에 있는 프로필을 보고 인사도 드리고 싶었습니다. 저는 정올 공모전을 통해서 55회 ISEF 대회에 참가했었던 학생이고, 말씀 많이 들었습니다. 앞으로 종종 블로그에 들러서 많은 가르침 얻었으면 합니다. :-)

    2. 사무엘 2011/07/08 13:19 # M/D Permalink

      처음 뵙는 분이네요. 반갑습니다. 자세한 보충 설명에도 감사합니다. ^^
      같은 네이티브 코드라도, 진짜 운영체제의 원초 API하고만 직통으로 대화하는 놈이 있는가 하면 여전히 아주 크고 아름다운 런타임-_- 라이브러리에 의존해야 하는 놈도 있을 수 있겠죠?

    3. 사무엘 2011/07/08 13:20 # M/D Permalink

      (앞 댓글에 '여전히'가 반복돼 있어서 고쳤더니, 댓글의 순서까지 이상하게 바뀌어서..)

      남정현 님, ISEF 후배이시군요. 더욱 반갑습니다. ^^;;
      워낙 대외 프로필이 화려하게 적혀 있어서 그 한 줄은 미처 간과했습니다.
      이곳에서 제 프로필을 보셨겠지만, 저는 현재 IT 쪽(을/만) 파고 있지는 않죠.
      후배님의 세부 관심 분야가 어디인지는 모르겠지만, 공모 출신, 더구나 그쪽의 만렙인 ISEF 출신들이 각자 다양한 분야를 컴퓨터 기술과 융합하여 사회에 보탬이 되는 창의적이고 좋은 작품을 많이 만들어 내면 좋겠습니다.
      아무쪼록 좋은 인연 맺어 나갔으면 합니다. 고맙습니다. ^^

    4. ???????????? 2011/07/08 17:05 # M/D Permalink

      아, 하단에 네이티브를 쓰는 경우는, MS 안의 OS 전담 부서의 개발자들이 C++를 쓰는 사람들이 대부분이라 그런 거예요. 그것 때문에 Longhorn을 모두 .NET 기반으로 만들려고 하다 결국 무산되었고, 같이 진행되던 Avalon도 C++에서 접근할 수 없어서 WPF라는 원래 목적보다 작은 규모의 시스템이 되었지요.

  3. ???????????? 2011/07/08 17:07 # M/D Reply Permalink

    비밀번호 안 적으면 비밀번호 써 달라고 요구하게 할 수 없을까요... 비밀번호 안 쓰고 글 쓴 뒤에 수정하려면 할 수가 없군요 OTL

    1. 사무엘 2011/07/09 13:14 # M/D Permalink

      헐, 운영체제를 전부 virtual machine 기반으로 만들겠다는 건 흠좀무스러운데요.
      Windows가 완전히 신생 꼬꼬마 운영체제도 아니고 이미 native 기반의 너무 탄탄한 기득권이 있는 물건인데 굳이 그런 위험한 모험을 감행할 이유가 없죠.
      이곳 블로그 엔진을 고치는 방법은 잘 모르겠습니다. 제로보드 4는 제가 마음대로 고쳐 쓸 정도로 구조가 단순한 반면, TextCube는 꽤 복잡하네요. ^^

    2. ???????????? 2011/07/12 11:31 # M/D Permalink

      그런 이유 때문에 코드네임 Longhorn은 개발 중에 무너져 버렸고, 그것은 Windows XP의 수명이 비정상적으로 늘어나 버린 이유가 되었지요 :(

      대신 지금까지 유출된 Windows 8 초기 버전의 내부 구조를 살펴보면 .NET과 C++의 완벽한 공존을 위한 여러 컴포넌트가 준비되어 있다고 해요.

Leave a comment
« Previous : 1 : ... 1212 : 1213 : 1214 : 1215 : 1216 : 1217 : 1218 : 1219 : 1220 : ... 1682 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/10   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Site Stats

Total hits:
1459851
Today:
381
Yesterday:
635