'Computing'에 해당되는 글 58건

  1. 2009.09.30 Guide to building FFMpeg for Windows Mobile / Win CE
  2. 2009.09.30 윈도우에서 ffmpeg 컴파일하기(to use in vc++)
  3. 2009.09.30 HOWTO: compiling ffmpeg + x264 + MP3 + Xvid + AMR on Ubuntu
  4. 2009.07.22 Excel에서 만든 Graph를 LATEX에 삽입할 수 있는지요
  5. 2009.07.21 [칼럼]SW개발자의 희생을 요구하는 문화는 바뀌어야 한다
  6. 2009.03.10 Windows Mobile 개발 관련 setup
  7. 2009.01.28 시게이트, 한국 소비자들을 위한 공식 입장 전달
  8. 2009.01.21 결함판정’ 하드디스크
  9. 2009.01.02 인공지능의 창시자, 자살할 수밖에 없었던 이유
  10. 2009.01.01 넷북용 리눅스 이분투
  11. 2008.12.10 5분이면 뚝딱 무선랜 보안 따라잡기
  12. 2008.11.17 기업내 오픈소스 개발 방식 도입記
  13. 2008.10.14 Vista에서 ping 응답이 가능하게 만들기 (ICMP Echo)
  14. 2008.09.19 훌륭한 프로그래머의 딜레마
  15. 2008.09.08 한국 SW는 레드오션인가?
  16. 2008.08.18 [수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술
  17. 2008.05.27 Filezilla Server 한글문제 해결
  18. 2007.10.18 메모리 누수 디버깅
  19. 2007.10.18 메모리 할당한 부분 찾기
  20. 2007.10.16 SATA2 하드디스크의 NCQ 기능 사용하기
  21. 2007.10.10 Microsoft Robotics Studio에서 XInputController
  22. 2007.08.27 C++ 형변환 연산자 (cast operators), C 형변환 연산자 ()
  23. 2007.05.30 Ubiquitous 연구 동향
  24. 2007.05.22 안티스파이웨어 랭킹 리뷰
  25. 2007.05.17 samba에서 user
  26. 2007.05.11 zeroboard 설치
  27. 2007.05.11 Ubuntu 7.04 server 설치중...
  28. 2007.05.10 Elliptic curve cryptography (ECC)

Guide to building FFMpeg for Windows Mobile / Win CE

Hi all,

I after playing round with Crags guide I thought I would post what I have found. No small amount of hair pulling from me to

Prerequisites

1. Before proceeding, you must have the Msys + MingW development environment set up. I can highly recommend thishttp://ffmpeg.arrozcru.org/ guide as a starting point. Follow this guide through until you have an environment which is sufficient for building FFMpeg on Windows.

2. Get the CeGCC cross compiler from the http://sourceforge.net/project/showfiles.php?group_id=173455&package_id=198682 . The version you should get is http://downloads.sourceforge.net/cegcc/cegcc-mingw32ce-0.50-cygwin.tar.gz?modtime=1188210321&big_mirror=0%20cegcc-mingw32ce-0.50-cygwin.tar.gz.

3. Unzip cegcc-cegcc-0.50-cygwin.tar.gz into your msys/mingw directory. Assuming you followed the guid in step 1, that will be
"c:\msys\mingw"

4. Rename the winsock 2 library found in
"/mingw/opt/mingw32ce/arm-wince-mingw32ce/lib"
from libws2.a to libws2_32.a. Assuming you followed the guide in step 1 that will be
"C:\msys\mingw\opt\mingw32ce\arm-wince-mingw32ce\lib"

5. Modify the file errno.h found in
"/mingw/opt/mingw32ce/arm-wince-mingw32ce/include/errno.h"
Remove lines 11-14:
#ifdef __COREDLL__
# include_next <errno.h>
#else /* __COREDLL__ */
and lines 106-107:
#endif /* Not __COREDLL__ */

6. Note that this is only an issue if you are ''not'' using CeGCC to build your Windows CE / Mobile application. There is an issue with the alignment of structures that contain 8-byte variables in CeGCC (see this http://www.mail-archive.com/cegcc-devel@lists.sourceforge.net/msg00738.html discussion for more info). The solution for this problem involves modifying the stdint.h header file that ships with the release of CeGCC.
/mingw/opt/mingw32ce/arm-wince-mingw32ce/include/stdint.h
If the guide in step 1 was followed that will be
C:\msys\mingw\opt\mingw32ce\arm-wince-mingw32ce\include\stdint.h
Modify the typedefs of the 64-bit integer variables from:
typedef long long int64_t;
typedef unsigned long long uint64_t;
to:
typedef long long int64_t
#if defined(__GNUC__)
__attribute((aligned(8)))
#endif
;
typedef unsigned long long uint64_t
#if defined(__GNUC__)
__attribute((aligned(8)))
#endif
;

7. Download http://www.gnuarm.com/bu-2.16.1_gcc-4.1.0-c-c++_nl-1.14.0_gi-6.4.exe binutils-2.16.1, gcc-4.1.0-c-c++, newlib-1.14.0, insight-6.4, setup.exe [25.3MB] from http://www.gnuarm.com.

8. Install the gnuArm tools to the default location.

Build Process
1. Check out the latest version of the FFMpeg source from SVN. The rest of this guide will assume you checked out to c:\projects\ffmpeg.

2. Open a MSYS command window and navigate to the directory you checked FFMpeg out to:
cd /c/projects/ffmpeg

3. Add the path to the CeGCC cross compiler's bin directory to your PATH environment variable:
PATH=$PATH:/mingw/opt/mingw32ce/bin

4. Add the path to the gnuArm tools bin directory to your PATH environment variable:
PATH=$PATH:"/C/Program Files/GNUARM/bin"

5. Configure the build by executing the following command:
./configure --enable-mingwce --cross-compile --cross-prefix=arm-wince-mingw32ce- --arch=arm --disable-static --enable-shared --disable-parsers --enable-memalign-hack --disable-ffmpeg --disable-ffplay --disable-debug
note from metalkin) It seems that ffmpeg doesn't support '--enable-mingwce' and '--cross-compile'options anymore, '--enable-cross-compile' could replace '--cross-compile' based on current ffmpeg revision.
During build, dsputil_arm_s.S makes several errors "' junk at end of line, first unrecognized character is `p'". I guess an arm assember has to be designated to compile it.
Due to the reasons, this option could be a bit out of date, I think.

6. Remove any old intermediate files
make clean

7. Start the build by executing make:
make

8. Once the build is finished.
make install

9. The lib and header files will now have been copied over to the directories below.
/usr/local/lib
/usr/local/include/ffmpeg
Which if you followed the guide in the prerequisites will be located in:
C:\msys\local\lib
C:\msys\local\include\ffmpeg

Have fun
ceebmoj

ceebmoj
Posts: 1
Joined: Thu Nov 20, 2008 4:30 pm

윈도우에서 ffmpeg 컴파일하기(to use in vc++)

출처 : http://lotus.tistory.com/5?srchid=BR1http%3A%2F%2Flotus.tistory.com%2F5

http://blogit.blogkorea.net/15838845/http://microdev.pe.kr/84 에서
윈도우용 바이너리를 미리 컴파일 해놓은 것이 있어서 굳이 직접 컴파일 할 필요는 없습니다.

<직접컴파일하는 방법>

다운 받은 패키지는 아래와 같습니다.
원래하드에 깔려 있던 패키지
mingw-5.0.3
추가로 받은 패키지.
MSYS-1.0.11-2004.04.30-1.exe
bash-2.05b-MSYS.tar.bz2
binutils-2.16.91-20060119-1.tar.gz
ffmpeg 소스
svn클라이언트로 ffmpeg을 다운로드 합니다.
주소는 다음과 같습니다. svn://svn.mplayerhq.hu/ffmpeg/trunk
인터넷에서 돌아다니는 문서에 보면 binutils를 받으란 얘기는 없는데 binutils 버전이 안 맞으면 컴파일 도중에러가 나네요. 이것때문에 시간 좀 끌었습니다.
mingw와 msys를 설치해 줍니다. path는 경우에 맞게 지정해주세요.
msys.bat에
call "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
이 한줄을 추가 시켜줍니다. vcvars32.bat가 있는 경로로 수정해주세요.
msys실행 후 link.exe를 실행해서 뭔가 주루룩 나오면 제대로 된겁니다. 그 다음 다운 받은 ffmpeg 디렉토리로 가서 configure를 수행합니다.
./configure --enable-shared --disable-static --enable-memalign-hack
그다음 make를  실행후 컴파일 완료되면
c:\program files\FFmpeg 이란 디렉토리가 생깁니다.
FFmpeg폴더 밑에 lib란 디렉토리를 만든후 원 소스가 있던 FFmpeg소스 디렉토리의 하위 디렉토리에lib파일이 세개 있는데 programs files\FFmepg\lib 디렉토리에 카피 합니다.
그리고 dll파일들은 system32에 카피 합니다.
아래 링크에 설치 과정이 나와있습니다.
http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html#SEC26
http://arrozcru.no-ip.org/ffmpeg/

HOWTO: compiling ffmpeg + x264 + MP3 + Xvid + AMR on Ubuntu

ffmpeg is THE audio/video conversion tool. Unfortunately, the default build included in Ubuntu is usually quite outdated, as well as lacking support for many codecs.
The purpose of this article is to show you how you can build a fresh, up to date version of ffmpeg supporting (almost) all codecs. This procedure was successfully performed on Ubuntu 8.04 and 8.10.
0) Prerequisites
Before we start, let's check if subversion and git are installed. We'll need both to install some of the libraries required by ffmpeg:
ubuntu% svn
Type 'svn help' for usage.
ubuntu% git
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]
OK, they're both present. If not, you need to install them with the following commands:
ubuntu% sudo apt-get install subversion
ubuntu% sudo apt-get install git git-core
Now would be a good time to decide where you're going to build all those sources. Just create a temporary directory anywhere you like (you'll need less than 150MB).
[Updated on 2008/01/02] If you have an existing installation of ffmpeg, you may run into linking issues caused by conflicting library versions. My advice is to remove all existing copies of libav* (libavcodec and so on) which may be present in /usr/lib, either by uninstalling them with APT or by deleting the .a and .so files. Please read the comments below for additional information.
1) Fetching the ffmpeg sources
First of all, let's get the latest ffmpeg source snapshot from the Subversion server:

ubuntu% svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
lots of output removed
Checked out external at revision 28172.
Checked out revision 16245.

Of course, you could just go ahead with configure, make, make install and be done with it. Unfortunately (?), it's not that simple. Go ahead, run configure:

ubuntu% cd ffmpeg
ubuntu% ./configure
--prefix=/usr/local
lots of output removed
Creating config.mak and config.h...

Take a closer look at the output, especially at the 'Enabled encoders' section. A number of major formats, like AAC, MP3, x.264 or XViD are missing. Can you live without these? Probably not...
Why, oh why are they missing? Take another look at the output of the configure command:
libfaac enabled no
libmp3lame enabled no
libx264 enabled no
libxvid enabled no

These encoders are missing because they're handled by external libraries which are not part of the ffmpeg source package. Chasing them all is a bit of a pain in the #$$ and hopefully this article will help!
2) Configuring ffmpeg... and failing
Let's go wild and enable almost everything, including shared libraries (nice if you're running multiple copies of ffmpeg) and POSIX threads (additional parallelism can't hurt):
ubuntu% ./configure --prefix=/usr/local --enable-gpl --enable-nonfree --enable-shared --enable-postproc --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-x11grab --enable-bzlib --enable-libamr-nb --enable-libamr-wb --enable-libdc1394 --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libschroedinger --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-zlib

It will inevitably lead to something like this:
FAAD test failed.
If you think configure made a mistake, make sure you are using the latest
version from SVN. If the latest version fails, report the problem to the
ffmpeg-user@mplayerhq.hu mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.err" produced by configure as this will help
solving the problem.

It's normal, we haven't installed the external libraries required for our ffmpeg build. Let's get to it!
3) Installing libamr
This library is needed for 3GPP speech codecs. For legal reasons, it is not part of the standard Ubuntu repository. You can find it in the Medibuntu repository. Of course, you need to let APT know about this new repository. These are the commands for Ubuntu 8.04 (more information on other versions here):

ubuntu% sudo wget http://www.medibuntu.org/sources.list.d/hardy.list --output-document=/etc/apt/sources.list.d/medibuntu.list
ubuntu% sudo apt-get update && sudo apt-get install medibuntu-keyring && sudo apt-get update
Now you can install libamr:
ubuntu% sudo apt-get install libamrnb-dev libamrwb-dev
4) Installing libnut

NUT is a container format under construction by MPlayer and FFmpeg developers. Libnut needs to be built from source:
ubuntu% svn co svn://svn.mplayerhq.hu/nut/src/trunk/ nut
ubuntu% cd nut
ubuntu% make
ubuntu% sudo make install

5) Installing libx264
x264 is a free library for encoding H264/AVC video streams.
It can be fetched with APT using 'apt-get install libx264-dev' but let's make sure we have both the latest ffmpeg and the latest x264.
Before we build the x264 source, we need to install

  • libgpac, required to support the mp4 container with the x264 codec,
  • the yasm assembler, required to compile several assembly language routines present in the x264 code.
Installing libgpac is straightforward:
ubuntu% sudo apt-get install libgpac-dev
Now, let's take a look at yasm:
ubuntu% yasm --version
zsh: command not found: yasm
It's not there. Let's get it using APT:
ubuntu% sudo apt-get install yasm
ubuntu% yasm --version
yasm 0.5.0.1591

OK, now let fetch the x264 source and configure the build:

ubuntu% git clone git://git.videolan.org/x264.git
ubuntu% cd x264
ubuntu% ./configure --prefix=/usr/local --enable-shared
Found yasm 0.5.0.1591
Minimum version is yasm-0.6.1
If you really want to compile without asm, configure with --disable-asm.

Hmmm.. Do we want to use generic C routines instead of optimized assembly? No. Let's build the latest yasm (0.7.2 at the time of this writing):
ubuntu% sudo apt-get remove yasm
ubuntu% wget http://www.tortall.net/projects/yasm/releases/yasm-0.7.2.tar.gz
ubuntu% tar xvfz yasm-0.7.2.tar.gz
ubuntu% cd yasm-0.7.2
ubuntu% ./configure --prefix=/usr/local
ubuntu% make
ubuntu% sudo make install
ubuntu% yasm --version
yasm 0.7.2.2153

OK, now we can build x264:

ubuntu% cd x264
ubuntu% ./configure --prefix=/usr/local --enable-shared
output removed
Platform: X86
System: LINUX
asm: yes
avis input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: yes
visualize: no
ubuntu% make
ubuntu% sudo make install

6) Installing libxvid
Before we install libxvid, we need to check that the nasm assembler is OK. It's required to build assembly code inlibxvid and you do NOT want this code to be replaced with generic C code in case nasm is missing : I ran some Xvidencoding tests with and without assembly code and there's a 2.5x factor... So read on :)
You need at least nasm 2.0, so let's check the default version on Ubuntu 8.04 and Ubuntu 8.10:

ubuntu8.04% sudo apt-get install nasm
ubuntu8.04% nasm -v
NASM version 0.99.06-20071101 compiled on Sep 16 2008
ubuntu8.10% sudo apt-get install nasm
ubuntu8.10% nasm -v
NASM version 2.03.01 compiled on Jun 19 2008

So, if you have 8.10, you're good to go and you can skip the rest of this section. If you have 8.04, follow me:
ubuntu% sudo apt-get remove nasm
ubuntu% wget http://www.nasm.us/pub/nasm/releasebuilds/2.05.01/nasm-2.05.01.tar.gz
ubuntu% tar xvfz nasm-2.05.01.tar.gz
ubuntu% cd nasm-2.05.01
ubuntu% ./configure --prefix=/usr/local
ubuntu% make
ubuntu% sudo make install
ubuntu% nasm -v
NASM version 2.05.01 compiled on Dec 23 2008

Now, let's fetch the xvid sources and build them:

ubuntu% wget http://downloads.xvid.org/downloads/xvidcore-1.2.1.tar.gz
ubuntu% tar xvfz xvidcore-1.2.1.tar.gz
ubuntu% cd xvidcore/build/generic
ubuntu% ./configure --prefix=/usr/local
ubuntu% make
lots of output removed
---------------------------------------------------------------
Xvid has been successfully built.
* Binaries are currently located in the '=build' directory
* To install them on your system, you can run '# make install'
as root.
---------------------------------------------------------------

ubuntu% sudo make install
7) Installing everything else
All the other libraries we need are part of the standard Ubuntu repository. Let's install them all with a single command:

ubuntu% sudo apt-get install
libfaac-dev libfaad-dev libschroedinger-dev libtheora-dev libvorbis-dev libxv-dev libxvmc-dev

We also need to install the LAME MP3 encoder. The name of the library differs on Ubuntu 8.04 and Ubunto 8.10, so choose wisely :)

ubuntu8.04% sudo apt-get
install liblame-dev
ubuntu8.10% sudo apt-get install libmp3lame-dev
8) Configuring ffmpeg... and succeeding!

We should have everything we need now. Let's try that configure command again:
[Updated on 2009/02/18 : the '--enable-xvmc' flag has been removed. XVMC support now seems to be integrated by default. If you're using an old build, please add the flag to the command line below]
[Updated on 2009/03/09 : the '--enable-swscale' flag has been removed. This library is now built by default. If you're using an old build, please add the flag to the command line below]
ubuntu% cd ffmpeg
ubuntu% ./configure --prefix=/usr/local --enable-gpl --enable-nonfree --enable-shared --enable-postproc --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-x11grab --enable-bzlib --enable-libamr-nb --enable-libamr-wb --enable-libdc1394 --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libschroedinger --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-zlib
lots of output removed
License: unredistributable
Creating config.mak and config.h...
All right. Let's build it.

9) Building ffmpeg
That's the easiest bit!
ubuntu% make
LOTS of output removed
ranlib libavutil/libavutil.a
rm doc/ffserver.pod doc/ffmpeg.pod doc/ffplay.pod
ubuntu% sudo make install
That's it. Cool, huh? Before you can start playing with your ffmpeg binary, you need to register those new dynamic libraries in /usr/local/lib (I'm using zsh. the syntax may be different if you're using another shell):
ubuntu% LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
ubuntu% export LD_LIBRARY_PATH
ubuntu% sudo ldconfig
Now, let's check this new ffmpeg:
ubuntu% which ffmpeg
/usr/local/bin/ffmpeg
ubuntu% ffmpeg -formats
lots of output removed
Pretty good list of codecs, isn't it?
10) Cleaning up

If like me you keep building the latest version, you will eventually end up with a lot of unecessary libraries in/usr/local/lib, e.g.:
ubuntu% cd /usr/local/lib
ubuntu% ls -l libav*
-rw-r--r-- 1 root root 24108334 2009-02-20 11:15 libavcodec.a
lrwxrwxrwx 1 root root 21 2009-02-20 11:15 libavcodec.so -> libavcodec.so.52.15.0
lrwxrwxrwx 1 root root 21 2009-02-20 11:15 libavcodec.so.52 -> libavcodec.so.52.15.0
-rwxr-xr-x 1 root root 5791060 2009-02-04 11:34 libavcodec.so.52.11.0
-rwxr-xr-x 1 root root 5791192 2009-02-05 15:29 libavcodec.so.52.12.0
-rwxr-xr-x 1 root root 5791228 2009-02-10 17:46 libavcodec.so.52.14.0
-rwxr-xr-x 1 root root 5774920 2009-02-20 11:15 libavcodec.so.52.15.0
-rw-r--r-- 1 root root 467478 2009-02-20 11:15 libavdevice.a
lrwxrwxrwx 1 root root 21 2009-02-20 11:15 libavdevice.so -> libavdevice.so.52.1.0
lrwxrwxrwx 1 root root 21 2009-02-20 11:15 libavdevice.so.52 -> libavdevice.so.52.1.0
-rwxr-xr-x 1 root root 39492 2009-02-20 11:15 libavdevice.so.52.1.0
-rw-r--r-- 1 root root 63220 2009-02-20 11:15 libavfilter.a
lrwxrwxrwx 1 root root 20 2009-02-20 11:15 libavfilter.so -> libavfilter.so.0.3.0
lrwxrwxrwx 1 root root 20 2009-02-20 11:15 libavfilter.so.0 -> libavfilter.so.0.3.0
-rwxr-xr-x 1 root root 17876 2009-02-20 11:15 libavfilter.so.0.3.0
-rw-r--r-- 1 root root 6259158 2009-02-20 11:15 libavformat.a
lrwxrwxrwx 1 root root 22 2009-02-20 11:15 libavformat.so -> libavformat.so.52.29.0
lrwxrwxrwx 1 root root 22 2009-02-20 11:15 libavformat.so.52 -> libavformat.so.52.29.0
-rwxr-xr-x 1 root root 766736 2009-02-05 15:29 libavformat.so.52.25.0
-rwxr-xr-x 1 root root 770972 2009-02-10 17:46 libavformat.so.52.26.0
-rwxr-xr-x 1 root root 771072 2009-02-12 16:57 libavformat.so.52.27.0
-rwxr-xr-x 1 root root 775232 2009-02-13 11:22 libavformat.so.52.28.0
-rwxr-xr-x 1 root root 767108 2009-02-20 11:15 libavformat.so.52.29.0
-rw-r--r-- 1 root root 225672 2009-02-20 11:15 libavutil.a
lrwxrwxrwx 1 root root 20 2009-02-20 11:15 libavutil.so -> libavutil.so.49.14.0
lrwxrwxrwx 1 root root 20 2009-02-20 11:15 libavutil.so.49 -> libavutil.so.49.14.0
-rwxr-xr-x 1 root root 55508 2009-02-20 11:15 libavutil.so.49.14.0
There's nothing really wrong here, but for the sake of clarity, you may want to remove the old libraries, i.e. the ones NOT linked as lib*.so.
That's it for today :)
Related Posts by Categories

ffmpeg

open source

howto

x264

Written by: Julien Simon at 3:45 PM

Tags: ffmpeg, howto, open source, x264

Excel에서 만든 Graph를 LATEX에 삽입할 수 있는지요

 

http://doc.ktug.or.kr/gfaqprj/gfaq-html/node54.html

 

Excel에서 만든 Graph를 LATEX에 삽입할 수 있는지요.

[*] Windows 시스템에서 사용하는 그림 정보는 WMF(EMF)라는 형태의 포맷을 가집니다. MS사의 프로그램에서 만들어지는 그림들은 모두 이 포맷이죠. 그러므로 메모리에 있는 그림을 파일로 그대로 쓰면 wmf 그림이 됩니다.

메모리의 그림 정보를 파일로 기록하기 위해서는 ClipMeta차재춘 님이 만드신 ClipWMF 같은 유틸리티를 쓰면 쉽게 파일로 쓸 수 있습니다.

Excel에서 그래프를 만들어서 그래프 전체를 선택합니다. 그런 다음, 이것을 잘라내기(Ctrl-X)합니다. `복사'를 해서는 그림이 잘 안 잡아진다는 보고가 있었답니다. 그런 다음 클립보드에 있는 그림을 ClipMeta로 디스크에 쓰면 됩니다.

그리고, wmf2eps를 실행하여 이 wmf 파일을 EPS로 변환하세요.

참고로, 1999년 12월에 게시판에 올려주신 `무식인' 님과 강윤배 님의 게시물을 인용합니다.

무식인:
드디어 엑셀의 막대그래프를 텍에 넣는데 성공했읍니다. 정말 기쁨에 눈물이 앞을 가립니다. clipwmf프로그램에 대한 정보를 주신 도은이 아버님과, 이를 만드신 차재춘 님께 감사드립니다.
clipwmf.exe파일은 http://www.texplus.com이나, 도은이 아버님이 아래의 ``bibtex로 리퍼런스 만들기''의 답장에 달아 놓으셨습니다.3
clipwmf.exe파일은 클립보드에 있는 그림등을 캡쳐하는 기능을 가지고 있습니다.
clipwmf.zip을 다운 받아서 풀면, clipwmf.exe파일 하나만 중요한 파일이고 나머지는 파일들은 사용설명을 담고 있읍니다. 이 파일을 실행시키면 맨 아래에 작은 아이콘이 다른 아이콘 옆에 생깁니다. 만약 그림 파일을 띄운 상태에서 그림을 클릭해서 copy 또는 cut 명령을 쓰면 이 그림은 일시적으로 클립보드에 카피되어 있읍니다. 이때 마우스 화살표를 clipwmf의 작은 아이콘에 대고 오른쪽 버튼을 누르면 Save, About,Exit의 세 문구가 나오는데 save 하면 그림을 캡쳐합니다. 파일 형식은 *.wmf로 됩니다.
그러나 주의 할 점은 엑셀의 히스토그램은 copy 명령을 때리고 clpwmf로 캡쳐하려면 안된다는데 중요한 포인트가 있읍니다. 엑셀의 히스토그램을 클릭하면 그림,설명내용, 백그라운드...등 여러가지 중 하나가 선택되는데, 이것을 캡쳐해 보았자 쓸모가 없겠지요. 저는 이것때문에 한참동안 고생했읍니다. 따라서, cut을 선택해야 캡쳐가 가능합니다. 히스토그램에 마우스로 클릭하고 cut을 하면 몽땅 클립보드에 임시로 저장되겠지요. 그런후에 clpwmf를 사용해서 wmf파일 형태로 저장하면 됩니다. $\rightarrow$ 쉬운 내용을 너무 어렵게 설명한 것 같군요.
그후의 일은 일사천리입니다. 저장한 wmf파일은 wmf2eps를 사용해서 EPS(TeX에 잘 사용되는 그림포맷) 형태로 만들거나, Paint Shop Pro 테스트 버전이 있으시면 이 프로그램으로 wmf를 읽어서 EPS로 저장하셔도 됩니다.
도움이 되셨으면 합니다. 건강하십시오.
강윤배 :
무식인 님께서 여기 언급하신 내용과 관련된 정보가 박원규 님 홈페이지(http://chem.skku.ac.kr/~wkpark)에도 제법 있습니다. 저는 이 홈페이지에서 clipmeta라는 프로그램을 다운받아 사용했는데 무식인님께서 말씀하신 clipwmf랑 거의 비슷한것 같네요... 이 홈페이지에는 wmf파일에 관한 설명과 LaTeX에서 그림을 사용하는 방법을 상세히 설명해 놓고 있습니다...관심있으신 분은 한번 둘러보셔도 좋을것 같네요...

[칼럼]SW개발자의 희생을 요구하는 문화는 바뀌어야 한다

[칼럼]SW개발자의 희생을 요구하는 문화는 바뀌어야 한다

류한석 IT칼럼니스트 hanseok.ryu@gmail.com

2009.07.21 / AM 10:00

티맥스윈도,

[패널토의 동영상보기] 전문가 5인이 말하는 ‘국내 앱스토어의 미래’

[지디넷코리아]지난 7월 7일, 티맥스소프트의 티맥스윈도 제품 공개 후 업계와 인터넷이 시끄럽다. 논란의 주제들도 다양하다. OS 개발이 과연 우리 수준에 가능한 일이고 또한 필요한 일인가, MS 호환 제품을 굳이 만들어야 하는가, 오픈소스 도용 의혹, MS와의 상표권 분쟁, 박대연 회장의 발언 논란까지 티맥스와 관련된 이슈들이 참으로 많다.

물론 티맥스의 성공과 박대연 회장의 사업가로서의 능력은 명백하게 인정할 만 하다. 티맥스는 작년에 매출 1천억원을 돌파했는데, 국내 소프트웨어 산업의 현실을 감안할 때 무척 놀라운 일이다. 불가능해 보이는 목표를 향한 그의 공격적인 경영 덕분에 가능한 일이었다.

박대연 회장의 주장대로 이번에 OS만 제대로 개발된다면, 전세계에서 IBM과 MS 다음으로 데이터베이스, 미들웨어, OS 모두를 보유한 토털 소프트웨어 업체가 될 수도 있다. 소프트웨어 산업의 가장 핵심적인 제품 세가지를 모두 보유하게 되는 것이다.

하지만 빛이 있으면 그림자도 있다. 티맥스는 부채가 1천500억원이고 작년 영업이익은 14억원에 불과하다. 여전히 티맥스의 소프트웨어들은 국내용이고, 또한 SI 프로젝트의 비중이 상당하고, 작년에만 직원 수가 두 배로 늘어 조직 관리에 대한 잡음이 회사 외부에까지 들리고, 올 1분기에 150억원의 적자를 냈고, 급여가 제때 지급되지 않아 자금위기설도 있었고, 최근에는 자구책으로 임직원들이 증자에 참여하기도 했다.

필자는 티맥스가 OS를 개발하는 것 자체를 평가절하하고 싶은 마음은 전혀 없다. 그것은 경영자의 사업 전략이자 의사결정 영역이기 때문이다. 어려운 목표에 도전하기로 한 사업적 결정을 존중하고 싶다. 다만, 티맥스가 업계에 미치는 영향이 상당하기에(또한 논란이야말로 커다란 에너지 소모가 아니던가), 그러한 관점에서 다음과 같은 세가지 사항을 살펴보고자 한다.

첫째, 개발자들의 희생을 바탕으로 제품을 만드는 문화는 바뀌어야 한다.

티맥스에 따르면, 티맥스윈도의 개발에 350명의 개발자가 참여하고 있다고 한다. 티맥스는 과거 DBMS의 개발에만 7년이 걸렸다고 하는데, 지난 5월까지만 해도 DBMS보다 훨씬 복잡성이 높은 OS 개발과 관련하여 다음과 같이 주장했다. 티맥스는 OS 개발을 올해 상반기에 끝마쳐서, 올 7월에 출시한 후 8월에는 일반인 대상의 테스트를 하고, 늦어도 10월 1일에 소비자가 구매할 수 있도록 하겠다고 호언한 바 있다. 하지만 지난 7일의 발표회에서 선보인 제품은 베타는커녕 알파 버전이랄 수도 없는 것이었다.

이렇듯 말도 안 되는 일정의 수립이야말로, 저명한 소프트웨어 공학자인 에드워드 요든(Edward Yourdon)이 말한 ‘죽음의 행진(Death March)’ 프로젝트의 가장 핵심적인 요건이다.

티맥스는 MS 대비 100분 1의 인력으로 OS를 개발하고 있는 상황인데, 박대연 회장은 개발자들에게 “꿈속에서 프로그램이 보이면 문제다. 꿈속에서 에러를 찾아야 한다”고 강조한다고 한다. 그 자신 스스로 ‘8-10맨’이라며 오전 8시 출근해서 오후 10시에 퇴근하며, 또한 자신의 목표 달성을 위해 지난 25년간 영화, 드라마를 단 한번도 보지 않았다고 한다.

그런 타입의 경영자는 모든 산업에 존재하는데, 자신의 열정만큼 직원들에게도 열정을 강요하곤 한다. 실제로 그는 발표회와 인터뷰에서 직원들이 얼마나 희생하고 있는 지를 강조하며, 이혼당한 개발자, 건강 이상으로 쓰러진 개발자 이야기를 공공연히 밝혀왔다. 직원들의 가정파괴와 건강상실은 경영자로서 부끄럽게 생각할 일이지 자랑스러워 할 일이 아니다.

우리는 한국에서 그런 식의 죽음의 행진 프로젝트를 지금까지 많이 보아왔다. “지금의 고생만 참으면 파라다이스를 만날 수 있어” 프로젝트 말이다. 하지만 아무도 파라다이스를 만난 적은 없었다.

인간의 정신에 의한 100% 순도의 멘탈 작업으로 만들어지는 소프트웨어는 희생에 의해 창조되는 것이 아니다. 그렇게 해서는 A+급 소프트웨어가 나올 수 없다.

해외의 성공한 소프트웨어 기업들을 살펴보면 공통점이 있다. 직원들이 자유롭고 즐겁고 행복하다는 것이다. 바로 그런 가운데 고도의 집중력을 발휘함으로써 최상의 정신적 산물인 소프트웨어가 창조된다. 그렇다. 진정으로 가치 있는 A+급의 소프트웨어는 고통을 참고 희생하는 가운데 만들어지는 것이 아니라, 자유롭고 행복한 환경에서 만들어진다. 필자는 그것이 바로, 한국이 아직까지 소프트웨어 산업에서 성공을 만들어내지 못한 가장 큰 이유라고 믿는다.

개발자들이 피곤한 몸을 이끌고 억지로 야근하는 상황에서는 비록 개발이 진척된다고 하더라도, 분노와 고통의 안 좋은 기운이 코드에 스며들어 버그가 양산되고 결국 품질이 저하된다. 해외의 연구에 따르면, 일주일에 20시간 정도의 야근을 할 때는 생산성이 증가할 수도 있지만, 이후에는 분명히 쉬어줘야 하며 그렇지 않으면 순생산성이 낮아진다. 야근은 임시일 뿐 지속되어서는 안 되는 것이다. 삶에서 오로지 일이 전부인 일중독자들을 제외하고는 다들 경험상 이 말에 동의할 것이다.

과연 티맥스가 전세계의 선진 소프트웨어 기업들에서는 찾아볼 수 없는 죽음의 행진 방식을 통해 제대로 된 OS를 만들어 낼 수 있을까? 물론 성공할 가능성이 희박하다고 보여지지만, 설사 성공한다고 하더라도 바람직한 일이 아니다. 국내에서 그런 죽음의 행진 풍토가 더욱 일반화될 것이기 때문이다(물론 지금도 충분히 일반화되어 있지만 말이다).

한국의 개발자들에게 고하건대, 어떻게 대해도 해내니까 어떻게든 학대하는 것이다. 그렇게 해서 결과물을 완성시켰다고 하더라도 소프트웨어 산업은 발전하지 않는다. 그것이 바로 소프트웨어 산업이 다른 종류의 산업들, 즉 제조업, 건축/토목업 등과 다른 점이다. 육체와 달리 정신은 여유가 있을 때야 비로소 제대로 동작하기 때문이다. 개발자들의 희생을 통해 만들어진 소프트웨어는 언제나 창조성이 떨어지고 본질적인 품질 문제가 존재한다.

필자는 지금까지 이혼을 당하고, 회사에서 쓰러져 식물인간이 되고, 종교에 귀의하고, 다른 직업으로 전직하는 개발자들을 많이 보아왔다. 산업 논리와 경영자의 욕심으로 인해 더 이상 개발자들이 희생 당하는 일이 없기를 바란다. 어떻게든 제품이 나오면 무얼 하겠는가? 개발자들이 치를 떨며 업계를 떠나는 이 현실에서 말이다.

한국의 소프트웨어 산업에서 진정으로 필요한 것은 개발자들의 희생정신이 아니라 즐겁게 일하며 최상의 창조성을 발휘할 수 있는 환경이다.

둘째, 오픈소스 도용 의혹에 대해 명확히 밝힐 필요가 있다.

많은 사람들이 티맥스가 너무도 짧은 시간에 적은 인력들로 100% 자체 기술로만 OS를 개발하여 출시하는 것이 실제로 가능한가라는 의문을 갖고 있다. 사실 양적, 질적으로 그것은 불가능한 것이다. 유능한 인재들의 집합체인 마이크로소프트조차 5조원의 돈을 투자하여 개발하고서도 좋은 평가를 받지 못하는 분야가 바로 OS이다.

그런 상황에서 티맥스의 OS 개발자라고 밝힌 이가 모커뮤니티 게시판에 오픈소스를 참조하여 개발하고 있다는 글을 올리면서, 티맥스윈도의 오픈소스 도용 의혹이 인터넷에 급격하게 퍼지게 되었다.

의혹의 핵심은 “티맥스윈도가 오픈소스의 짜깁기가 아니냐”는 것이다. 실제로 인터넷에는 MS 윈도 에뮬레이터, 호환 OS 개발을 위한 쓸만한 오픈소스들이 많이 존재한다. 리눅스 상에서 윈도 프로그램을 가동하기 위한 Wine, 그리고 MS 윈도와 호환성 있는 OS를 개발하는 ReactOS 등이 대표적이다.

그런데 소스가 공개된 오픈소스라고 해서 라이선스가 없는 것이 아니다. 오픈소스의 종류에 따라 라이선스들도 다 다르고 무척 복잡하여 함부로 상용 소프트웨어의 개발에 사용해서는 안 된다. 저작권 침해로 소송을 당할 수도 있기 때문이다. 그래서 일부 대기업에서는 자사 개발자들이 오픈소스를 함부로 사용하지 못하도록 교육도 하고 있다.

물론 오픈소스를 가져다 쓰는 것 자체가 문제는 아니다. 그 사용을 명확히 밝히고 라이선스의 내용을 준수하면 된다. 만일 기존 오픈소스를 개선한 부분이 있다면 오히려 그것을 공개함으로써 오픈소스 커뮤니티에서 훌륭한 기여자로 평가 받을 수도 있다.

결국 현재의 문제점은, 많은 사람들이 의심을 하고 있고 티맥스의 개발자라고 주장하는 이가 올린 글로 인해 의혹이 더욱 커졌음에도 불구하고 티맥스측에서 “얼마나 오픈소스를 사용했는지, 그리고 라이선스를 지켰는지”에 대해 정확히 밝히고 있지 않다는 점이다. 이와 관련해서 오픈소스 진영의 사람들 중에는 분노를 표시하는 사람들이 많다. 티맥스는 오픈소스 도용 의혹이 해소될 수 있도록 공식적인 입장을 표명할 필요가 있다.

셋째, 애국심에 호소하는 자세와 불필요한 언사, 정치적 행보는 자제할 필요가 있다.

티맥스윈도와 관련한 여러 가지 의혹과 논란 및 반감을 증대시키는 것은 박대연 회장의 일련의 발언들 덕분이다. 특히 그는 국민이 인정해주는 국민 소프트웨어 기업이 될 것임을 공공연하게 강조해왔다. 그런데 국민 가수가 되고 싶다고 될 수 없듯이, 국민 소프트웨어 기업 또한 스스로 원한다고 해서 될 수 있는 것이 아니다. 그리고 애국, 국민 등의 키워드를 강조해서 잘 된 기업이 없다. 그 자체로 정치적인 성향을 증명하는 것이기 때문이다.

최근 중앙일보와의 인터뷰를 통해 알려진 그의 어록은 대단하다. 일부만 살펴보면 다음과 같다.

“토종 OS의 등장은 한국 산업사에서 조선이나 자동차, 반도체 산업 진출에 비견되는 위대한 도전이다.”

“티맥스윈도와 오피스로 2012년까지 세계 OS 시장의 10%를 차지할 것이다.”

“내년에 해외법인 10개를 세울 것이다. 2011년에는 30개가 추가된다.”

(인력이 부족하지 않냐는 질문에 대해) “실제로 MS윈도 개발의 핵심인력은 5명에 불과하다. 나머지는 테스트하고 성능을 개선하는 인력이다.”

“구글의 OS는 우리 기술의 5분의 1도 안 된다.”

또한 지난 7일의 시연에서 올드 게임 구동과 동영상 재생조차 제대로 되지 않았음에도 불구하고, 여전히 1%가 미완이며 단순 에러라서 향후 3개월 내에 문제점이 0.1%도 남지 않을 것이라고 주장하기도 했다.

이런 경영자의 주장은 회사의 이미지에 나쁜 영향만 끼칠 뿐이다. 개발은 말로 하는 것이 아니다. 제품으로 보여주어야 한다. 기업용 제품인 DBMS, 미들웨어에 대해 호언장담을 할 때에는 대중의 관심이 적어서 그럭저럭 묻힐 수 있었겠지만, 개인 소비자 대상의 OS에 대해 이런 식으로 얘기를 해서는 곤란하다. 기업의 신뢰성에 심각한 손상이 갈 뿐이다.

티맥스 내부에서 “회장님, 이러시면 안됩니다.”라고 말하는 사람조차 없는 것일까? 그의 경영 스타일로 보건대 충분히 그럴 거 같다.

그리고 이번 발표회에서 테잎커팅(실제로는 전원을 키는 방식)에 강만수 국가경쟁력강화위원회 위원장을 비롯하여 금융감독원장, 국회의원 등 정재계 인사들이 다수 참석했다.

이에 대해 발표회의 많은 참석자들이 의아하게 생각했으며, 티맥스의 정치적 행보에 다시금 의심의 눈초리를 보내고 있다. 핵심 개발자들이 테잎커팅을 할 수는 없었을까? 그랬다면 그들의 자부심을 높였을 것이고 업계 전반에 훈훈한 미담이 되었을 것이다.

티맥스는 기업의 이미지와 티맥스윈도의 마케팅을 위해서 어떻게 처신하는 것이 가장 올바른가를 다시 한번 생각해보았으면 좋겠다. 현재와 같은 방식은 안티들을 양산할 뿐이다. 적어도 이 기술업계의 승자들(예컨대 애플, 구글 등)은 거의 종교라고 할 수 있을 정도로 강력한 팬들을 거느리고 있다. 그런 팬을 만들어내지는 못할망정 안티들만 늘어난다면 티맥스윈도의 앞날은 잿빛이 될 뿐이다.

이상으로 업계와 인터넷에서 큰 논란이 되고 있는 티맥스윈도와 관련된 세 가지 주요 이슈들을 개발자들의 희생, 오픈소스 도용 의혹, 정치적 행보라는 관점에서 살펴보았다. 필자의 주장 또한 하나의 견해일 뿐이므로, 이에 대해서도 바라보는 관점에 따라서 논란이 있을 수 있다.

하지만 위의 세가지 내용은 국내 소프트웨어 업계에서 오래 전부터 만연되어 온 구태의연한 문제점들이다. 새삼스러울 것이 없는 것들이다. 그 정점을 티맥스가 찍고 있다고 본다.

혁신적인 제품을 만들려면 그 방식부터 혁신이 필요하다. 그럼에도 불구하고, 티맥스가 성공적인 제품을 만들어 낼 것인지 애정과 비판의 마음으로 계속 지켜보면서 필요하다면 추가적인 글을 쓰도록 하겠다. @

Windows Mobile 개발 관련 setup

http://video.naver.com/2009022706342575043

 

드디어 T옴니아 폰을 질렀습니다.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

기존에 사용하고 있던 폰은 제가 개발하고 만든 윈도우 모바일 폰이며 애착이 가는 폰입니다. 그래서 제 스스로 기능을 개선시켜가며 사용하는 재미에 오랫동안 사용하고 있었습니다.<o:p></o:p>

하지만, 대세가 대세인지라 터치폰을 사용해 보기로 결정!<o:p></o:p>

뭐, 그런 이유도 있고 이제는 좀 새로운 폰을 사용해 보고 싶어서 구매를 했습니다.<o:p></o:p>

<o:p></o:p>

그래서 기념으로 윈도우 모바일 운영체제에 대한 내용을 추가 하도록 하겠습니다.<o:p></o:p>

최근에 Kmobile(http://www.kmobile.co.kr/k_conedu/Conference/Con_gProgram.asp?id=516)<o:p></o:p>

에서 윈도우 모바일 관련 세미나를 진행하기도 해서 관련 사항에 대해 블로그를 올리도록 하겠습니다.<o:p></o:p>

<o:p></o:p>

윈도우 모바일 개발 환경의 구축<o:p></o:p>

<o:p></o:p>

1. Windows XP Service Pack 2 또는 Windows Vista 운영체제 설치<o:p></o:p>

1) Windows XP 서비스팩2 운영체제에서는 스마트 폰과 PC와의 연결을 하기 위해서는 액티브 싱크(ActiveSync)가 필요합니다. 최신 버전은 4.5 입니다. <o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=9e641c34-6f7f-404d-a04b-dc09f8141141<o:p></o:p>

2) Windows Vista 운영체제에서는 Windows Mobile Device Center 가 6.1 로 업데이트가 필요합니다.<o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=46f72df1-e46a-4a5f-a791-09f07aaa1914<o:p></o:p>

<o:p></o:p>

2. 개발 도구로는 한글이든 영문이든 Visual Studio 2008 Professional Edition 이상이 있어야 합니다. 저는 아직까지 Visual Studio 2005 Professional Edition을 사용하고 있습니다. 그 이유는 윈도우 임베디드 CE 6.0 플랫폼 빌더를 2008에서 지원하지 않기 때문입니다.<o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?FamilyID=83c3a1ec-ed72-4a79-8961-25635db0192b&DisplayLang=ko<o:p></o:p>

<o:p></o:p>

3. Visual Studio 2008 서비스 팩1을 설치해 주시기 바랍니다. .NET 프레임워크 3.5 및 WIndows Mobile 개발 컴포넌트를 업데이트 할 수 있습니다.  <o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?FamilyID=fbee1648-7106-44a7-9649-6d9f6d58056e&DisplayLang=ko<o:p></o:p>

<o:p></o:p>

4. Windows Mobile 6 Professional Edition SDK를 설치하면 됩니다. http://www.microsoft.com/downloads/details.aspx?FamilyID=06111a3a-a651-4745-88ef-3d48091a390b&DisplayLang=en<o:p></o:p>

<o:p></o:p>

5. 원래 Windows Mobile 6 SDK 에는 영문(USA) 밖에 없기 때문에 한글을 사용하기 위해서는 Windows Mobile 6 Emulator Localization Images 를 다운로드 받아야 합니다.<o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?FamilyID=38c46aa8-1dd7-426f-a913-4f370a65a582&DisplayLang=en<o:p></o:p>

<o:p></o:p>

6. 마지막으로 Windows Mobile 6.1.4 Emulator Images (USA) 를 설치해 주면 되는데 여기에는 T옴니아 폰이나 HTC 터치 다이아몬드 HD 디스플레이처럼 DPI 가 480 * 800 이미지가 포함 되어 있으므로 이를 다운로드 받아서 사용하는 것이 좋습니다. <o:p></o:p>

http://www.microsoft.com/downloads/details.aspx?FamilyID=1a7a6b52-f89e-4354-84ce-5d19c204498a&DisplayLang=en<o:p></o:p>

<o:p> </o:p>

위 내용은 원래 MS의 서진호 차장의 블로그에서 나오는 이야기를 제 나름대로 수정하여 올립니다. 원문의 주소는 다음과 같습니다.<o:p></o:p>

MS 서진호 차장의 블로그 내용 :http://blogs.msdn.com/jinhoseo/archive/2008/12/23/0-t.aspx<o:p></o:p>

<o:p> </o:p>

Cellular Emulator<o:p></o:p>

윈도우 모바일 개발 환경에서 전화 걸기나 SMS 관련 에뮬레이터를 사용하기 위해서는 Cellular 에뮬레이터를 사용해야 합니다. Windows Mobile SDK를 설치하면 C:\Program Files\Windows Mobile 6 SDK\Tools\Cellular Emulator 디렉토리에 있습니다. 이 툴을 사용하는 방법이나 테스트 방법은 다음 동영상을 참고하시기 바랍니다. 제가 직접 제 PC에서 테스트 하는 장면입니다.

<o:p></o:p>

<o:p> </o:p>

윈도우 모바일 프로그래밍에 대한 보다 자세한 이야기는 “월간 마이크로 소프트웨어 3월호(www.imaso.co.kr)”나 추후 업데이트될 제 블로그를 참고해 주세요!<o:p></o:p>

<o:p></o:p>

2009년 2월 27일 ratharn <o:p></o:p>

시게이트, 한국 소비자들을 위한 공식 입장 전달

http://www.kbench.com/hardware/?no=64743

시게이트, 한국 소비자들을 위한 공식 입장 전달

최근 불거진 하드디스크 결함 문제로 말미암아 세계 최대의 스토리지 전문 회사인 시게이트의 위상에 큰 위기가 찾아온 가운데 지사를 갖고 있지 않은 국내에서는 많은 유저들을 확보하고 있음에도 불구하고 이 문제의 해결에 대한 시게이트와의 의사 소통이 다소 부진한 인상이었던 것이 사실.


이에 시게이트는 국내의 자사 홍보기업을 통해 공식적인 입장을 전달해왔다. 이에 따르면 시게이트는 지난 2008년 12월에 제조된 바라쿠다 7200.11 일부 제품을 포함한 시게이트 일부 제품군들이 펌웨어 문제로 PC의 전원이 켜졌을 때 사용자가 하드 드라이브 내의 데이터에 접근할 수 없게 되는 상황이 발생할 가능성이 있는 것을 확인했다고 밝히고, 해당 펌웨어를 제거했다고 발표했다.


시게이트는 해당 문제가 발생하는 제품을 대상으로 무료 펌웨어 업그레이드를 즉각 실시한다고 발표했으며, 펌웨어 업데이트가 필요한 하드 드라이브인지의 여부는 다음의 사이트를 통해 확인할 수 있다. http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931.
고객들은 시게이트 고객 지원센터에 이메일(discsupport@seagate.com)을 통해 즉각적인 지원을 받을 수 있으며, 모델 넘버, 시리얼과 현재 사용중인 펌웨어 버젼 등을 첨부하면 필요한 조치에 대한 빠른 안내를 받을 수 있다고 한다.


이번 펌웨어 업데이트와 관련, 이를 시행하는 경우 기존에 보관되어있던 드라이브 내부의 데이터에는 손실이 발생하지는 않으며, 개인 데이터들은 모두 다시 사용할 수 있다고 한다. 또 데이터에 접근할 수 없는 고객들에게는 불편함을 최소화 할 수 있도록 무료 데이터 북구 서비스를 진행한다고 한다.
http://www.seagate.com/www/en-us/about/contact_us/를 통해 각국의 서비스관련 연락처 및 문의 방법을 확인할 수 있으며,http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951&NewLang=ko를 통해 문제가 발생한 하드디스크의 새로운 펌웨어를 다운로드 할 수 있다. 시게이트의 공식적인 설명에 따르면 ISO 방식으로 제공되는 해당 펌웨어를 CD에 레코딩한 후 이를 통해 시스템을 부팅하면 펌웨어가 하드디스크를 인식, 자동으로 펌웨어를 업데이트 하게 된다고 한다. - 케이벤치(www.kbench.com)

결함판정&amp;rsquo; 하드디스크

시게이트하드

인공지능의 창시자, 자살할 수밖에 없었던 이유

http://www.hankyung.com/news/app/newsview.php?aid=2009010162581&intype=1&nv=1

튜링에 대한 이야기…

 

인공지능의 창시자, 자살할 수밖에 없었던 이유

너무 많이 알았던 사람

'컴퓨터의 아버지'로 불리는 천재 수학자 앨런 튜링. /승산 제공

너무 많이 알았던 사람  데이비드 리비트 지음│고중숙 옮김│승산│408쪽│1만8000원
알렉산더 매켄드릭 감독의 '흰옷 입은 사나이'에는 닳지 않는 옷감을 발명한 화학자 스트래튼 이야기가 나온다.
그가 만든 옷감은 닳지도 않고 더러워지지도 않는 '기적의 섬유'였다. 그러나 이 때문에 일자리를 빼앗길 것을 우려한 노동조합 동료들과 섬유회사 주인의 엄청난 반발에 직면한다.
사람들은 그 옷감으로 흰옷을 만들어 입고 있는 스트래튼을 붙잡아 옷을 없애버리려고 한다. 나중엔 그를 죽이려고까지 한다. 마지막 순간에 옷감이 스스로 분해되면서 그는 가까스로 목숨을 건진다.
'컴퓨터의 아버지'로 불리는 앨런 튜링(1912~1954)의 전기 《너무 많이 알았던 사람》은 이 얘기부터 시작한다. 영국이 낳은 천재 수학자 튜링의 기묘한 인생이 영화 속의 스트래튼과 닮았기 때문이다. 물론 스트래튼이 '발명 때문에' 쫓긴 것과 튜링이 '발명에도 불구하고' 쫓긴 차이는 따로 있다.
스트래튼의 '흰옷'은 실패한 발명으로 끝나지만 튜링의 '가상적 및 실제 기계'는 2차 대전의 연합군 승리와 컴퓨터 시대의 개막에 결정적인 역할을 했다.
여기에 동성애와 자살,과학적 상상력과 20세기 전반의 시대 상황이 겹쳐져 그의 일생은 더욱 드라마틱해진다. 튜링은 정보과학과 인공지능의 창시자로도 불린다.
논리학과 생물학을 연결시킨 공적 덕분에 생물학과 철학 이론가로 불리기도 한다. 그가 스물네 살 때 내놓은 논문은 위대한 수학적 과제에 도전한 것으로 유명하다.
'결정가능성 문제(decidability problem)'라고 불리는 이 과제를 해결하기 위해 그는 프로그램을 할 수 있는 가상적인 기계를 상정했다.
이 '튜링기계'는 독일군의 암호를 해독하기 위해 실제로 구현됐고,이 덕분에 연합군은 승리를 거둘 수 있었다.
전쟁이 끝난 뒤 그는 인공지능의 최고 권위자가 됐다. 하지만 그의 컴퓨터 제작은 '반동성애법 위반 혐의'로 체포되면서 갑작스레 중단되고 말았다.
"구속되고 난 뒤 그에게 남은 짧은 삶은 비탄과 광기를 향한 느리고도 슬픈 추락의 길이었다. 도덕적 죄목으로 재판을 거친 그에게는 감옥에 가두는 대신 동성애를 '치료'하기 위한 에스트로겐요법을 받으라는 선고가 내려졌다.
에스트로겐 주사는 화학적 거세 효과를 가져온다. 게다가 치욕적인 부수적 효과도 뒤따른다. 달리기를 좋아했던 야윈 사람에게 살이 불어나고 젖가슴이 자라났다. "

 

이 같은 굴욕과 호르몬 불균형에 따른 부작용은 그를 자살로 내몰았다. 그는 몇 입 깨물어진 사과 옆에서 죽은 채로 발견됐다.
그의 사인을 두고 여러 추측이 많지만 그의 집에 시안화칼륨(청산가리) 등 화학약품이 많았다는 점에서 <백설공주와 일곱 난쟁이>의 독이 묻은 사과를 떠올리게 한다. 저자는 '인터넷에서는 애플컴퓨터사의 로고가 튜링의 사과를 가리킨다는 소문이 떠돈다.
회사에서는 이를 부정하면서 오히려 이는 뉴턴의 사과를 암시한다고 해명한다. 하지만 정말 그렇다면 왜 한입 베어져 있을까?'라고 되묻는다.
튜링의 의식세계와 컴퓨터 발명,수학사의 뒷얘기를 촘촘하게 엮어낸 저자의 역량이 돋보인다.
고두현 기자 kdh@hankyung.com

입력: 2009-01-01 17:31 / 수정: 2009-01-02 09:33

넷북용 리눅스 이분투

5분이면 뚝딱 무선랜 보안 따라잡기

개인적으로는 무선랜 네트워크를 공개해놓는 것을 좋아한다. 근처에 온 누군가가 내 네트워크를 통해 얼마든지 인터넷에 접속할 수 있게 말이다. 그러나 그 네트워크가 업무용이라면 이야기가 달라진다. 할 수 있는 한 최대한의 보안을 취해야 한다.
 
정보나 데이터를 개방된 무선 네트워크를 통해 보낸다는 것은 근처의 모든 이에게 이를 공개한다는 것과 마찬가지다. 업무에 필요한 데이터를 보호하기 위해, 할 수 있는 조치에 대해 알아본다.
 
우선 SSID를 숨겨야 한다. 무선 네트워크를 보호하는 가장 간단한 방법이다. 현재 사용하는 네트워크를 마치 ‘잊혀진 섬’처럼 사라지게 해준다.
 
방법은 간단한다. 무선랜 라우터 설정 페이지에 접속해 무선랜 설정 탭을 연다. 이후 SSID 브로드캐스트를 해제하면 끝이다. 이후 숨겨진 SSID 네트워크에 접속하기 위해서는 수동으로 SSID를 입력해 넣으면 된다.
 
그러나 SSID를 숨겨놨다고 해서 능사는 아니다. 몇 단계만 거치면 숨겨진 네트워크도 손쉽게 찾아낼 수 있어서다. 단지 보안을 위한 첫 단계 정도로만 간주하는 편이 좋다.
 
다음 단계는 패스워드를 설정하는 것이다. 무선 네트워크가 개방돼 있다는 것은 이 패스워드를 요구하지 않는다는 의미다. 누구나 접속할 수 있는 것은 물론 공중에 떠있는 데이터를 누구나 볼 수 있다는 것과 마찬가지 의미다.
 
암호를 설정하게 되면 라우터에 접속하기 위해 암호를 입력해야할뿐더러 이 패스워드를 통해 데이터를 암호화하게 된다. 방법은 여러 가지가 있는데, 이중 WEP 암호화는 가장 보안 성능이 떨어진다. 해커라면 몇 분 이내에 손쉽게 풀어낼 수 있다.
 
WPA 암호화는 상대적으로 좀더 강력하지만 보안을 위해서라면 WPA2 암호화를 권한다. 대다수의 간단한 네트워크에서 가장 이상적인 암호화 방법이다. 라우터의 보안 설정 탭을 연 후 ‘WPA2 개인화’ 등의 설정을 통해 암호를 입력하면 된다.
 
맥 어드레스를 통한 필터링을 이용할 수도 있다. 사전에 미리 입력한 무선 네트워크 기기만 접속할 수 있도록 제한시키는 방법이다. 모든 네트워크 기기에는 고유의 맥 어드레스라는 것이 있는데, 이를 활용하는 것이다.
 
설정은 라우터의 보안 페이지에서 맥 어드레스 입력 탭을 열어 연결하려는 스마트폰, 아이팟 터치, 무선랜 노트북 등의 맥 어드레스 주소를 수동으로 입력하면 된다.

기업내 오픈소스 개발 방식 도입記

http://www.zdnet.co.kr/itbiz/column/anchor/scyoon/0,39030409,39175288,00.htm

기업내 오픈소스 개발 방식 도입記


윤석찬(다음 R&D 센터 팀장)   2008/11/16 04:50:07 PM
[지디넷코리아]최근에 오픈 소스 소프트웨어(Open Source Software)가 인기를 끌고 상용 S/W의 대안으로 자리 매김 하면서 많은 IT 기업들이 오픈 소스 소프트웨어를 개발 현장에서 사용하기 시작했다. 

과거에는 제품 개발 시 비용 절감을 위해 단순히 차용하는데 머물고 있었으나, 최근에는 자사의 제품을 직접 오픈 소스로 공개하고 개발자 커뮤니티를 제품 개발에 끌어들이는 것은 이제 일반화 되고 있는 실정이다. 

노벨, 썬마이크로스시스템즈, IBM, 오라클, 레드햇 같은 해외 유수 기업은 물론 국내에서도 삼성 SDS의 애니프레임, NHN의 큐브리드 등이 대열에 동참하고 있다. 

하지만, 흔히 ‘프로젝트’라고 부르는 기업의 제품 개발 방식과 개발자 커뮤니티에서 오픈 소스 소프트웨어가 만들어지는 방식이 다르기 때문에 문화적 혹은 기술적 차이가 생기게 된다. 만약 자사의 제품을 오픈 소스 방식으로 개발하고 싶다면 많은 부분을 고려해야 한다. 

오픈 소스 개발 방식은 다수 사용자의 버그 리포팅과 개발자 사이의 엄격한 상호 코드 리뷰를 기반으로 진행되는 특징을 가지고 있다. 오픈 소스 커뮤니티는 태생적으로 원격지에서 전혀 모르는 개발자들 사이에 만들어지기 때문에 개발 과정에서 온라인 프로세스의 엄격성은 매우 중요하고 잘 지켜진다. 

하지만, 회사의 경우 개발팀 내에서 주로 직접 대면을 통한 의 의사 소통에 의해 개발이 이루어지기 때문에 문화적 차이가 존재한다. 

특히, 시스템 통합(SI) 같은 기업형 프로젝트에서 CMMI 준수나 인수 인계 혹은 회계적 요구 사항에 의해 도입되는 전통적인 프로젝트 관리 시스템은 개발자들로 하여금 더 많은 비용을 야기 시키는 경향이 있다. 우리 회사에서도 과거 일정 관리 PMS가 있었는데 분기나 반기가 끝나면 형식적인 입력을 했었다. 

따라서, 오픈 소스 개발 방식과 전통적 프로젝트 관리 방식 사이에서 적합한 솔루션을 찾는다면 효율성 측면에서 좋은 결과를 얻을 수 있을 것 같다. 아래는 몇 년 전부터 다음(Daum)에서 오픈 소스 개발 방식을 기업에서 차용하기 위해 시도했었던 몇 가지 노력에 대한 경험을 공유해보고자 한다.

(1) 소스 코드를 한곳에 

2004년 처음 입사 했을 때 우리 회사 개발 프로세스에는 몇 가지 문제점이 있었다. 우선 각 서비스 소스 코드가 각 팀들이 별도의 레포지터리(Repository)에 보관하고 있었는데 그러다 보니 서비스 중단 혹은 조직 개편으로 중간에 뜨는 것들이 생기고 있었다. 게다가 팀마다 CVS, 서브버전(Subversion), 소스세이프(SourceSafe) 등 다양한 소스 콘트롤을 사용했다. 

가장 먼저 시도한 것이 바로 '소스 콘트롤 및 저장소 일원화’였다. 기존에 많은 팀에서 사용하던 CVS에서 서브버전으로 옮기는 작업을 했다. 

서브버전은 CVS이 비해 체인지셋(Change Set) 단위 커밋(Commit)이 가능하고 파일 및 디렉토리 관리가 편하기 때문에 코드 변경 횟수나 파일이나 디렉토리명 변경이 자주 이루어지는 웹 개발 현장에서 훨씬 좋은 것으로 판단되었다. 

특히, 서브버전은 웹으로 관리하도록 개발하기 용이한 구조로 되어 있어서 아직도 당시 만든 사용자 인증, 레포지터리 생성 및 관리 도구는 별 불편 없이 사용하고 있다. 당시 서브버전이 이클립스 플러그인 안정성 등 많은 이슈가 있어서 어려움이 많았지만 다행히 수백 개나 되는 전사 소스 코드가 한 자리로 모일 수 있었다.

(2) 사소한 것부터 문서화 

오픈 소스 프로젝트에서는 누구나 알만한 것들이나 알쏭달쏭한 것들을 모아서 문서로 잘 만들어 둔다. 누구나 다 알고 있을 것이라 여기는 사소한 것들부터 논쟁이 될만한 사안까지 다양한 문제를 하나의 문서로 제공해 주는 일은 꽤 유익한 일이다.

우리 회사에서는 오래 전부터 자바(Java)를 주 언어로 사용해오면서 언어를 어느 정도 일원화해 왔기 때문에 개발자가 갖추어야 할 기술 지식에 대해 각 팀 별로 크게 다르지 않았다. 

하지만, 각 팀 내 개발자에 따라 꽤 다른 코딩 습관 때문에 코드 리뷰나 이동이 일어나면 다양한 개발 이슈들이 자주 생기고 있었다. 

우선 자바 코딩 컨벤션 번역문과 회사 내 코딩 컨벤션을 합쳐 문서화 하고 여기에 주석 가이드, SQL 작성 가이드, 사내 SW 라이센스 규정, 파일 및 디렉토리 명명 표준화, 코드 리뷰 프로세스 등 개발 중에 질문할 수 있는 것들을 묶어 문서로 제공하였다. 

오픈 소스 커뮤니티에서도 이렇듯 자주 질문하는 내용에 대한 문서 정리가 매우 잘 되어 있다. 따라서, 회사 내 자질구레한 개발 프로세스에 대한 지식들을 모아서 문서로 제공하는 것은 가장 기본적인 일에 속한다. 이런 것들을 한번 문서화 해 두면 신입 이나 경력 개발자들이 들어와서 빠르게 업무를 파악 가능하기 때문이다.

(3) 생산성 높은 프로젝트 관리 도구 제공 

오픈 소스 개발 방식에서 사용하고 있는 대표적인 도구는 포지(Forge)류라고 불리는 프로젝트 관리 도구이다. 이들 소프트웨어는 프로젝트 생성 및 관리, 개발자 관리, 문서화, 게시판, 메일링리스트, 소스 콘트롤, 버그 트래커 등 다양한 기능을 제공해 준다. 온라인에서 널리 이용되는 것 중에 소스포지(SourceForge.net), 지포지(GForge.org) 등을 들 수 있다. 

초기에 회사 공통 라이브러리 및 공용 소프트웨어를 위해 GNU Forge를 도입하고 사내 개발자 참여를 유도 했었는데, 실패로 끝났을 정도로 활용도는 극히 미비했다. 대표적인 이유가 포지 소프트웨어의 사용 편의성이 낮고 불필요한 기능이 많다는 점이었다. 

따라서 최근 나온 Google Code나 LaunchPad.net 같은 신규 오픈 소스 프로젝트 호스팅 서비스를 보면 문서화, 버그트래킹, 소스콘트롤 등 심플하고 필요한 기능만 딱 제공 되고 있다. 많은 점에서 기존 포지 소프트웨어를 기업에서 바로 가져다 쓰기는 곤란하다고 본다. 

2006년부터 각 개발팀에서 서브버전과 궁합이 잘 맞는 Trac이라는 프로젝트 관리 도구 이용에 대한 요구 사항이 들어오기 시작했는데 지금은 신규 레포지터리 중 대략 40% 정도가 트랙(Trac)을 이용하고 있다. 따라서, 각 회사에 맞는 적당한 프로젝트 관리 도구를 필요에 따라 제공하면 생산성을 높일 수 있을 것 같다.

(4) 쉬운 문서화: 위키 통합 공간 

개발자들에게 문서화를 촉구해 보면 대부분 템플릿을 요구한다. 도대체 어떻게 문서화 해야 할지 모르는 경우가 많기 때문이다. 전통 기업 프로젝트에서는 이를 위해 정형화된 워드, 엑셀, 파워포인트 양식이 있다. 

아마 이런 것들은 어느 개발자나 한번쯤은 본적이 있을 것이다. 이 템플릿들의 문제점은 그 양식만 보고도 학을 뗄 정도로 쓰기 싫어진다는 데 있다. 대부분 필요한 요구 사항을 계속 덧붙이다 보니 배보다 배꼽이 더 큰 양식이 되어 버리기 일쑤다. 

이런 탓에 우리 회사에서도 개발 업무 보고, 소스 코드 및 S/W 사용법 문서화 등에 쉬운 문법과 템플릿 그리고 이력(Revision) 관리가 가능한 위키(Wiki)가 주로 쓰이고 있었다. 하지만, 각 팀 취향에 따라 여러 가지 위키를 사용하는 데다 개발자와 기획자의 커뮤니케이션에서 위키가 쉽지는 않았다. 

그래서 전사에서 사용할 수 있는 공용 위키 서버를 두어 개인 메모, 업무 보고나 자료 정리 등에 쉽게 위키를 쓰도록 하였다. 원하는 팀은 언제든 위키를 바로 세팅할 수 있다. 

각 팀별로 위키 S/W가 일원화에 따라 유지 보수 비용 및 학습 비용이 감소 되고 기획자들도 자연스럽게 위키에 접근할 수 있는 기회가 열렸다. (요즘엔 기획자들도 위키를 쓰는데 익숙할 정도...)

아직 미해결 과제 

그 후 2년 전부터 외부 개발자 지원으로 업무를 옮겼지만 위의 사내 개발 지원 서버들은 계속 우리 팀이 관리하고 있다가 얼마 전 기술 자원 담당팀으로 이전을 했다. 그 동안 사내 개발 프로세스에서 오픈 소스 도구와 방식을 잘 이식시켜 왔다고 생각하지만 아직 남아 있는 몇 가지 숙제들이 있다. 

첫 번째는 버그 트래킹에 대한 이슈다. 기존 오픈 소스에서는 버그는 원격의 다수 개발자들과 사용자 사이에 TODO 목록이고 작업에 대한 토론과 공유 그리고 리뷰가 함께 이루어지는 제일 중요한 요소다. 

하지만, 회사 내 버그(?)는 대개 고객센터로 들어온 문제와 기획자의 의사 결정과 요구 사항이 함께 만들어져 개발자에게 제공되는 방식이다. 

즉, 개발자와 기획자 1:1 혹은 팀장과 3자 정도로 공유되고 있다. 따라서 버그 트래커가 거의 불필요하거나 도입했더라도 버그 처리 과정 자체가 번거러운 일로 인식되게 된다. 게다가 소스 이력 관리를 위해 소스 콘트롤과 버그트래커의 유기적인 관계와 데이터 연결이 매우 중요한데도 이런 부분은 문화적으로 쉽게 정착되지 못하고 있다. 

두 번째는 여전히 잦은 소스 콘트롤 사용 방법의 오류 문제다. 앞서 말한 대로 웹 개발 코드는 요구 사항이 자주 변경되고 사용자 인터페이스(UI) 부분의 변경도 수시로 일어난다. 그 도중에서 개발자들이 잦은 커밋을 하기 때문에 소스 콘트롤 로그가 아무런 정보를 제공하지 못하는 커밋 로그에 불과한 경우가 많다. 

웹과 같은 서비스형 소프트웨어 개발 프로젝트가 늘면서 빠른 개발 방식을 선호함에 따라 잦은 소스 커밋을 브랜치(Branch)에 자유롭게 하고 최종 변경 사항만 트렁크(Trunk)에 할 수 있도록 쉽게 합쳐(Merging) 주는 자동화 도구가 절실한 것도 이런 이유다. 

지금까지 나열한 개발 프로세스와 도구는 전통적인 소프트웨어 개발에서도 존재하거나 차용되어 왔던 것들이다. 하지만 오픈 소스 커뮤니티에서는 이를 위한 개발 도구 및 문화를 적극적으로 개방해서 공유함으로서 이러한 혜택을 얻지 못하는 기업에게도 도움이 되고 있다. 

소프트웨어 공학자들의 최근 연구 결과에 따르면 오픈 소스 커뮤니티의 오류에 의해 버그가 생길 확률이 기업의 것 보다 더 낮다고 한다. 특히, 오픈 소스 커뮤니티에서 많은 개발자들이 이들 방식을 학습하여 실제 기업에서 적용할 수 있는 기회가 커지고 있다. 이러한 기회를 잘 활용하는 IT 기업에게 미래가 있을 것이다.

Vista에서 ping 응답이 가능하게 만들기 (ICMP Echo)

비스타는 기본적으로 ping을 받아주질 않는다.
이걸 해제하려면 아래 관리도구를 실행시킨다.

사용자 삽입 이미지

사용자 삽입 이미지

몇몇 블로그에서는 아래와같은 메뉴에서 "차단"을 "허용"으로 바꾸라고 하고 있다.
하지만 이건 방화벽을 끄는것과 별차이가 없어서 그닥 권장사항이 아니다.
그냥 "차단"으로 일단 둔다.

사용자 삽입 이미지

왼쪽의 "인바운드 규칙"을 선택하고
중앙에서 "파일 및 프린터 공유(에코 요청 - ICMPv4-In)"을 선택하고
오른쪽에서 "규칙 사용"을 선택한다.

"네트워킹 - 반향 요청(ICMPv4-In)"도 규칙사용 선택

(Vista의 버젼에 따라서 항목이 약간 다르다.)

사용자 삽입 이미지

이러면 방화벽을 동작시키면서 동시에 icmp echo를 처리하게 할 수 있다.

훌륭한 프로그래머의 딜레마



-----------------------------------------------------------------------------
소프트웨어 업계의 잘 알려지지 않은 명작 [ Wicked Problems, Righteous Solutions ]에
나온 일화를 국내 XP(Extreme Programming)의 전도사 김창준님이 각색한 것이다.
-----------------------------------------------------------------------------
 
'열심히' 씨와 '훌륭한' 씨는 각각 '엄청난 소프트웨어 회사'와 '허벌난 소프트웨어 회사'의 두 직원이다. 우연치 않게 두 회사에 정확히 똑같은 내용의 주문이 들어왔다. '열나 어려운 문제' 해결을 위한 프로그램을 작성해 달라는 것이었다.

열심히 씨는 처음 예상 소요 시간인 3개월 동안 정말 열심히 일했다.
하지만 일을 하면서 예상 외의 장애를 직면했고, 밤샘 작업까지 해가면서 3개월 마지막 날 매니저에게 이런 말을 할 수 있었다. "정말 열나게 프로그램을 짰습니다. 밤샘도 하고요. 제가 지금까지 작성한 프로그램은 2,000줄입니다. 그런데 새로운 문제가 기술적으로 불가피하게 발생했습니다. 복잡한 버그(프로그램 오류)도 몇 가지 해결해야 하고요. 한달 가량이 더 필요합니다". 그러고 한 달 후 열심히 씨는 몇 개의 버그와 더불어 나름대로 작동하는 프로그램을 매니저와 고객에게 자랑스럽게 보여줄 수 있었다. 벌겋게 충혈된 눈과 미처 깎지 못한 수염, 무지무지 어렵고 복잡해 보이는 2,500여 줄의 프로그램과 함께. "예상보다 훨씬 더 복잡한 문제였군요. 정말 수고하셨습니다."라는 칭찬을 들으면서,

훌륭한 씨는 매니저가 '의무적으로' 잡아놓은 예상 소요 시간 3개월의 첫 2달 반을 빈둥거리며 지냈다. 매니저는 훌륭한 씨가 월말이 되어서 "정말 죄송해요. 아직 한 줄도 못짰어요. 너무 어려워요. 좀 봐주세요."라고 처량하게 자비를 구할 날을 손꼽아 기다렸다. 웬걸, 마지막 날 훌륭한 씨는 예의 '너무도 태연스러운' 모습으로 나타났다. 150여 줄의 프로그램과 함께. 그 프로그램은 멋지게 '열나 어려운 문제'를 해결했다. 하지만 매니저 가 그 코드를 들여다 보자, 한 마디로 "너무도 쉬웠다." 초등학생도 생각해 낼 정도였다. 매니저와 고객은 이름을 '열나 쉬운 문제'로 바꾸는 데에 전적으로 동의한다. 훌륭한 씨는 "이렇게 간단한 문제를 3개월씩이나 걸려서 풀었습니까? 왜 이렇게 성실하지 못하죠?"라는 비난을 들어야 했다.

둘 중에 누가 승진을 했을까? 열심히 씨는 승진하고, 급여인상을 받았다. 훌륭한 씨는 급여삭감을 직면하고는 퇴사해 버렸다. 훌륭한 프로그래머는가난하다. 훌륭한 프로그래머의 딜레마인 것이다.





위나라의 임금이 편작에게 묻는다.

"그대 삼형제 가운데 누가 제일 잘 병을 치료하는가?"

큰 형님의 의술이 가장 훌륭하고 다음은 둘째 형님이며 저의 의술이 가장 비천합니다. 임금이 그 이유를 묻자 편작이 대답한 내용은 이러했다.

'큰 형님은 상대방이 아픔을 느끼지 전에 얼굴빛을 보고 그에게 장차 병이 있을 것임을 안다. 그리하여 그가 병이 생기기도 전에 원인을 제거하여 준다. 그러므로 상대는 아파보지도 않은 상태에서 치료를 받게 되고 따라서 그간 자기의 고통을 제거해 주었다는 사실을 알지 못한다. 큰 형이 명의로 소문나지 않은 이유는 여기에 있다.
둘째는 상대방이 병세가 미미한 상태에서 그의 병을 알고 치료를 해준다. 그러므로 이 경우의 환자도 둘째형이 자신의 큰 병을 낫게 해주었다고 생각하지 않는다.
그러나 나는 병이 커지고 환자가 고통속에 신음할 때가 되어서야 비로소 병을 알아 보았다. 환자의 병이 심하므로 그의 맥을 짚어야 했으며 진기한 약을 먹이고 살을 도려내는 수술도 했다. 그런데 사람들은 나의 그러한 행위를 보고서야 비로소 내가 자신의 병을 고쳐주었다고 믿게 되었다. 내가 명의로 소문이 나게 된 이유는 여기에 있다.'


한국 SW는 레드오션인가?


http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39172878,00.htm


"한국 SW는 레드오션인가?"


황치규 기자 (delight@zdnet.co.kr)   2008/09/07
이명박정부
[지디넷코리아]정말이지 그동안 많은 시행착오를 겪었다. 거품도 있었고, 쓴맛도 봤다. 산전, 수전, 공중전 다 치러봤다.

한시대를 풍미했던 많은 스타 벤처 사업가중에 상당수가 사라졌다. 남은 것은 싸늘한 시선과 회의론뿐이다. 절망감이 느껴진다.

2008년 가을, 대한민국소프트웨어(SW)산업의 기상도는 대충 이렇게 묘사된다.

반도체가 한국을 이끄는 핵심 산업으로 부상하고 '한국산' 휴대폰과 디스플레이가 세계를 누비고 다닐때, SW는 우물안 개구리 신세를 벗어나지 못했다. 지난해 기준으로 매출 1천억원을 넘긴 국내 SW기업은 하나도 없다. 해외 시장서도 마이너중 마이너일 뿐이다.

상황은 점점 나빠지고 있다. 우물안에서조차 안심할 수 없는 처지가 됐다. 급기야 이런 얘기도 들린다.

"솔직히 5년후가 안보인다" 

무명 벤처 사업가의 절망섞인 푸념이 아니다. 

대표적인 스타 벤처 사업가로 꼽히는 안철수가 한국 경제를 향해 부르짖는 외침이다. 위기론이 진하게 묻어나오는 발언이 아닐 수 없다.

안철수의 말대로 한국SW 산업은 지금 지칠대로 지쳐있다.

창업 열기는 확 식어버렸고 '88만원 세대’라 불리는 20대들의 성향은 갈수록 ‘안정지향형'으로 바뀌고 있다. 우수 인력이 제대로 유입되지 않고 있다. 

전산을 전공한 뒤 의학대학원으로 방향을 트는 학생들이 늘고 있단다. 그나마 의욕이 있던 개발자들도 속속 대기업과 외국계 기업에 새로 둥지를 틀고 있다. 벤처는 '찬밥신세'다.

이들을 향해 도전정신이 부족하다느니 편한것만 추구한다느니하며 거룩하고도 지당한 말씀을 늘어놓기에는 우리네 현실이 너무 척벅하다. 뻔한 얘기해봤자 소용이 없다.

창업이 줄고 사람들이 떠나는 국내SW벤처 생태계는 지금 혁신의 잠재력이 점점 줄어드는 위기를 맞고 있다. 대기업은 '슈퍼갑'이고, 중소SW벤처는 철저하게 '을'임을 요구받는 요상한 권력관계도 별로 변한게 없다.

한마디로 악순환이고, 순환의 고리를 끊기는 현재로선 쉽지 않아 보인다. 이쯤되면 '총체적 난국'이란 말이 어색하지 않다.

인정할 수 밖에 없는 대한민국SW산업의 현주소다.

한국 SW생태계가 항상 '우울증'에 걸려있었던 것은 아니다. 나름 생기가 돌았던 시절이 있었다. 한동안은 해외 무대를 향한 '노크소리'도 끊임없이 들려왔다.

그러나 세계의 벽은 생각보다 높았다. 

K-리그를 주름잡았던 축구스타들이 유럽무대에서 쉽게 적응하지 못한 것처럼, 국내 대표 SW업체들의 해외 시장 성적표도 '기대 이하'였다. 성과가 없다고는 볼 수 없으나 솔직히 내세울게 많지 않다.

이런 과정이 반복되다보니 돌아오는 것은 회의론뿐이다. 하다하다 안되니까, "어차피 안되는 것 아냐?"란 인식이 꼬리에 꼬리를 물고 확산되고 있다.

SW를 바라보는 정부의 인식도 점점 차가워지고 있다는 목소리도 많이 들린다. 

이명박 정부 출범 이후 전통산업과 IT의 융합을 표방하는 '뉴IT'란 등장했지만, 아직은 디테일이 부족하다는 평가가 지배적이다. 뉴IT에서 SW는 그저 SW로 불리울 뿐이다. 세분화돼 있는 다른 분야와는 어딘가 '엇박자'가 느껴진다. 그저 '끼워졌다'는 인상을 지울 수 없다.

뉴IT는 지난 10년간 별 재미를 못봤던 IT벤처보다는 대기업에 정책적 힘을 실어주는 듯한 분위기다. 

'토목 경제'의 위력도 점점 높아지는 모양새다. 

엎친데 덮친격으로 정부기관 통폐합에 따라 각종 공공 프로젝트가 연기되면서 공공시장 의존도가 높은 SW기업들은 이중고를 겪고 있다. SW산업 종사자들의 상대적 박탈감이 커져가는 이유다.

묻고싶다.한국경제에 SW는 레드오션인가? 

대기업들이 주도하는 반도체, 휴대폰, 디스플레이, 자동차와 '토목경제'만으로 한국경제는 지속가능한 성장이 가능할까?

그럭저럭 성장은 할지 모르겠다.

그러나 경제가 연간 7% 성장한다고 해서 한국을 '불안한 사회'로 몰고가는 고용 불안과 사회 양극화 문제를 해결할 수 있을까. 대기업들이 글로벌 아웃소싱을 확대하고 있는 상황에서 대기업 중심의 성장 전략이 과연 한국 경제의 기초체력 강화로 이어질 수 있을까.

지난 3년간 미국에서 공부를 하고 돌아온 안철수는 이렇게 말한다.

"물론 대기업 중심 구조로 가도 잘먹고 잘사는 나라도 있다고 말하는 분들도 있어요. 그러나 포트폴리오 차원에서 보면 우리나라의 대기업 중심 구조는 매우 위험합니다. 대기업 고용 능력이 점점 줄어들고 있잖아요? 현재 130만명 정도밖에 안된다는 얘기를 들었습니다. 나머지 국민들을 먹여살리는 것은 2천만명을 고용하는 중소기업들이에요

"얼마전 대기업 총수분들이 정부와 만나 투자를 통해 7만명의 고용을 창출하겠다고 했다는데 그렇더라도 대기업 고용 능력은 137만명 아닙니까? 한국은 중소기업에 있는 2천만명을 주목해야 합니다. 일자리 창출이 거기서 일어나잖아요."

결국 한국경제는 중소기업이 클 수 있는 인프라를 갖춰야 고용과 양극화 문제를 그나마 개선할 수 있다는 것이다. 고급 인력이 넘쳐나는 세상에서 이들을 수용할 수 있는 산업 인프라는 결국 경쟁력있는 중소벤처 생태계 구현에 달렸다는 것이다.

안철수말고도 많은 사람들이 이렇게 얘기하고 있다. 

한국경제에서 SW가 갖는 전략적 가치는 크다는 여론은 광범위하게 퍼져 있다. 거시적 차원에서 표면화되지 않고 있을 뿐이다.

전세계적으로도 SW파워는 점점 커지고 있다.

서버와 데스크톱을 넘어 웹과 모바일에서도 SW는 판세를 좌우하는 중량감있는 변수로 떠올랐다. 웹과 SW 그리고 통신과 방송간 컨버전스도 가속화되고 있다. SW와 웹간 컨버전스에 기반한 새로운 비즈니스 모델도 쏟아지고 있다. 세계 IT산업 혁신의 중심에 SW와 웹이 자리잡고 있는 것이다.

'SW 때문에 휴대폰을 사게 만들겠다"는 빌 게이츠의 호언장담도 지금 애플과 구글에 의해 현실화되고있다.

애플이 선보인 3G 아이폰에서 쓸 수 있는 수많은 애플리케이션과 곧 출시될 구글 모바일SW 플랫폼 안드로이드는 지금 세계 통신 뉴스의 헤드라인을 장식하고 있다. 몇년전과는 확 달라진 모습이다. IT산업 전반에 걸쳐 SW파워가 커졌다는 반증일 것이다.

다들 한국이 휴대폰 강국이라고 말한다. 세계 최고 수준의 이동통신 서비스 인프라를 갖췄다는 찬사도 쏟아진다.

맞는 말이다.

삼성전자와 LG전자는 세계 휴대폰 시장을 주도하고 있고, 국내 휴대폰 사용자들은 신기술 수용에 거부감이 없다. 한국이 모바일 관련 SW는 승부를 걸어볼만하다는 얘기가 나왔던 것도 바로 이 때문이다.

폐쇄적인 이동통신 환경 등으로 인해 아직까지는 별다른 성과가 없지만 모바일SW가 한국에 아직도 남아 있음은 분명하다.

그래서다.

지디넷코리아는 변화하는 IT환경에서 점점 중요해지는 SW가치를 집중 조명하는 기획시리즈를 진행할 예정이다. 이를 통해 SW가 한국이 반도체와 휴대폰 그리고 자동차에 이어 또 하나의 성장동력으로 삼을 수 있는 그래도 '확률높은 승부수'임을 부각시켜 나갈 것이다.

벤처 특성상, 실패 가능성이 크기는 하지만 자본과 인력 그리고 정부 정책이 잘 버무려져 제대로 성과를 낼 수 있다면 SW는 한국 경제에 신선한 바람을 불어넣을 수 있는 '촉매'란 인식을 확산시키고 싶다.

적어도 '토목경제'보다는 SW에 힘을 실어주는게 여러모로 낫다는 것을 보여주고 싶다. 전통산업과의 융합이든 새로운 산업을 육성하든 핵심은 바로 SW란 것도 강조하고 싶다.

아울러 지디넷코리아는 한국SW산업의 현주소와 위기를 돌파할 수 있는 대안에 대해서도 논의해 나갈 것이다.

물론 몇년째 듣고 있는 뻔한 얘기들을 반복할 수 있다. 그래도 새정부 출범과 함께 SW가치를 알려나가는 작업을 멈춰서는 안된다고 믿는다. 

'한국에 SW는 없다'고 단정짓기엔 지금은 너무 이르다.

[수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술

http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39172030,00.htm


[수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술


양병규(빵집 개발자)   2008/08/15
[지디넷코리아]공 고를 졸업하여 전자제품을 만드는 회사에서 10여 년간 납땜을 하던 젊은이가 있었다. 결혼을 하고 되돌아보니 이미 나이는 스물아홉. 자신이 처해있는 전자제품 업체에서 하는 일에 대한 전망이란 캄캄한 곳에서 바늘귀보다 찾기 어려웠다.

회사를 그만둔 그는 꼬박 열 달 동안 방에 틀어박혀 공부와 코딩에만 매달렸다. 수입이 없으니 집안 사정이야 말할 것도 없었다. 그 와중에 아이까지 태어나고 보니 분유 값은커녕 한겨울 난방유를 살 돈이 없어서 보일러를 돌리지도 못했다. 찬데서 자다가 감기가 걸린 탓인지 몸이 불덩이처럼 뜨거운 아이를 데리고 병원에 다녀온 그는 간장 가게에서 간장 통 하나를 얻어, 그 통에 기름을 사다가 보일러를 돌렸단다. 10리터도 안 되는 그 기름 한통은 일주일간 세 가족을 따뜻이 해 줬단다.

60, 70년대 이야기가 아니다. 꼭 10년 전의 일이니 우리도 당시의 기억이 생생할 만큼 가까운 과거의 일이다. 이런저런 어려움을 이겨내며 가까스로 만들어낸 프로그램은 ‘준이네 비디오 대여점’이라는 비디오 대여점 프로그램. 이제 이 프로그램이 대박 복권이 되어 세 가족을 도와줄 거라 믿던 청년의 꿈이 산산조각 나는 데에는 그리 오래 걸리지 않았다.

프로그램을 PC 통신 서비스에 올려두고 판매를 기다렸지만 한 달이 지나도록 전화 한통 오질 않았다. 현장의 이해가 전혀 없이 만들어진 소프트웨어이다 보니 외면당하는 것이 당연했을 터다.

그렇다고 다시 원래의 직업으로 돌아갈 수는 없다고 결심한 청년은 하는 수 없이 자신의 프로그램을 디스켓에 담아 이력서와 함께 들고 다녔다. 어렵게 입사한 회사에서 받은 월급은 70만원. 전자회사에 다닐 때보다 훨씬 적은 돈이었지만 청년은 자신의 꿈을 놓치지 않았다.

10년 전 프로그래머가 되겠다는 꿈을 품고 세상에 도전한 빵집 개발자 양병규 씨의 이야기다. 당신의 가슴 속에는 어떠한 꿈이 있는가? 지금부터 양병규 씨가 터득해 온 꿈을 현실로 만드는 기술에 대해 알아보자.


소프트웨어 개발자에 있어서 직장생활은 어쩔 수 없이 선택해야하는 것일까? 물론 자기 사업이나 불안한 프리랜서 생활보다는 안정적인 직장생활을 원하는 사람도 있을 것이다. 하지만 직장생활을 하고 있는 개발자 중에는 그것이 좋아서라기보다는 분명한 자기 꿈이 있음에도 불구하고 현실적인 문제로 인해 어쩔 수 없이 직장생활을 하는 경우도 있다.

그런 개발자들에게 꿈을 이루기 위해 직장생활 속에서 할 수 있는 현실적인 방법 한 가지를 소개하고자 한다. 물론 대부분은 필자가 경험을 통해서 깨달은 사실이므로 누구에게나 적용될 수 있는 방법은 아닐 것이다.

2개월간 진행한 PC 원격제어 프로그램 개발 프로젝트
누구나 한번쯤 써 봤을 원격제어 프로그램. 필자도 원격제어 프로그램의 대명사인 PC 애니웨어라는 소프트웨어를 써 본적이 있다. 이 프로그램을 처음 보는 순간 상당히 신기하기도 하고 한편으로는 직접 만들어보고 싶은 충동도 느껴졌다. ‘어떤 원리로 만들어진 것일까?’ 동공이 커지고 소름이 돋고 가슴이 두근거렸다.

필자 안에 탑재되어 있는 호기심 프로세서가 작동하기 시작한 것이다.

그러고 약 2년쯤 지난 뒤에 필자는 한 업체로부터 고객 지원용 원격 제어 프로그램을 개발해 달라는 의뢰를 받았다. 한국의 업체들이 다 그렇듯이 이 업체 또한 필자에게 무리한 프로젝트 기간을 제안했다. 2개월 만에 개발과 테스트까지 마쳐달라는 이야기였다. 개발팀 없이 필자 단신으로 개발해야 하는 상황이었다.

이 글을 읽고 있는 당신은 단신으로 원격제어 프로그램을 두 달 만에 버그 없이 만들 수 있겠는가? 필자 또한 보통의 경우라면 이런 프로그램을 두 달 만에 혼자서 개발할 수는 없다.

하지만 그 프로젝트를 진행하기로 계약하고 바로 작업에 들어갔다. 프로젝트는 딱 두 달 만에 전날 끝이 났다. 이 글을 읽으며 ‘미쳤군’이라고 생각했다면 그 생각이 옳다고 말해주고 싶다. 프로젝트란 절대로 이런 식으로 해서는 안 된다. 프로젝트가 진행되는 2개월간 필자는 단 한 번도 데모 프로그램을 업체에 전달해 주지 않았다.

일을 맡긴 업체나 담당자는 아마 불안하기 짝이 없었을 것이다. 프로젝트가 끝나가야 할 시기는 다가오는데 프로그램 모양 한번 못 봤으니 말이다. 하지만 필자는 별다른 초조함이나 두려움은 없었다. 두 달 안에 프로젝트를 끝낼 자신이 있었고 그런 자신감을 가질 수 있게 해 주는 비장의 무기가 있었던 덕분이다.

결국 프로젝트 마감 하루 전날에 완성된 프로그램을 보여주고 마지막 날 테스트를 진행하였다. 버그는 발견되지 않았으며 프로젝트는 단 하루의 오차도 없이 성공하여 서비스를 시작할 수 있게 되었다.

분명히 이런 상황은 엄청난 위험을 안고 있지만 필자는 단 2개월 동안 아무 문제없이 진행을 했고 결과 역시 만족스러웠다. 지금까지 필자가 진행했던 프로젝트 중에서 방금 소개한 원격제어 프로젝트와 필자가 직접 판매했던 도움말 저작 툴인 ‘헬프워드’ 그리고 ‘빵집’도 이와 유사한 방법으로 개발되었다.

이제부터 필자가 이처럼 터무니없는 기간에 프로젝트를 완성할 수 있도록 해 주는 비장의 무기에 대해 설명해 보려고 한다.

머리로 시작하고 머리로 완성하라.
소프트웨어 개발은 컴퓨터를 이용해서 작업한다. 그래서 대부분의 개발자들은 일단 컴퓨터 앞에 앉아야 업무가 시작된다. 설계, 코딩은 물론이고 디버깅하고 테스트하는 과정까지 모두 컴퓨터가 없이는 아무것도 할 수 없다. 너무나 당연하게 생각되는 이런 모습 때문에 직장 안에서 내 컴퓨터는 내 맘대로 할 수 없는 물건이 되어 버린다.

회사 일이 바쁜데 그 와중에 자기의 꿈을 위해서 자기가 만들고 싶은 것을 자유롭게 코딩을 하기란 여간 눈치 보이는 일이 아니다. 하지만, 만약에 소프트웨어 개발의 모든 과정을 머리로만 할 수 있다면 어떨까.

직장생활을 하면서 가지게 될 수 있는 자투리 시간이란 넉넉지 않다. 하지만 무언가 생각할 수 있는 시간은 생각보다 많다. 출퇴근 시 지하철 안에서 혹은 회의 중, 식사시간에도 프로젝트가 조금 여유 있다면 회사의 프로젝트 소스코드를 펼쳐놓고 코딩을 하면서, 아니면 화면을 디자인하면서 머리로는 자기만의 소프트웨어를 개발하고 있을 수도 있다.

약간씩 생기는 여유 시간에 머리로 내가 꿈꾸는 일이나 프로젝트에 대한 것들을 생각하고, 또 이것이 1년이나 2년쯤 쌓이게 되면 상당히 많은 양의 연구가 된다.

생각하기 위해 필요한 것
그럼 어떻게 생각하면 좋을 것인가? 가이드가 없는 생각은 공상이 되어버리기 십상이다. 필자가 제안하고자 하는 생각은 바둑의 수와 같다. 제조업체에서의 공정과도 같으며 건축가에게는 시공법과도 같다. 바둑의 수, 공장의 공정, 건축의 시공법은 모두 방법이나 절차 등을 정의한 것이다.

실제로 프로 바둑 기사들은 수년전의 대국도 기억하고 있고 제조업체의 라인 장들은 수 년 전에 생산한 제품의 제작 과정을 다 기억하고 있다. 건축가들은 자신이 설계한 모든 건축물의 구조를 모조리 기억하고 있다.

그런 능력은 비단 과거를 기억하게 만든 것에 그치지 않고 현재하고 있는 일과 미래에 해야 할 일을 머리만으로 미리 시뮬레이션 해 볼 수 있는 능력으로 발전한다. 물론 소프트웨어를 개발하는 일이 꼭 그것들과 같을 수는 없다. 개발과 생산은 엄연한 차이가 있다. 하지만 개발도 결국은 기존의 경험과 지식을 토대로 새로운 방법을 고안해 내는 것에 불과하다.

개발자가 그들처럼 세월이 흘러도 자신이 개발한 소스코드를 기억하고 새로운 프로젝트를 머리로 미리 시뮬레이션 할 수 있으려면 최소한 개발 방법은 명확하게 정의되어 있어야 한다.

물론 OOP나 디자인패턴과 같이 일반화 되어있는 개발 방법론들도 매우 훌륭한 역할을 할 수 있다. 필자가 생각하기에는 그것들보다도 더 구체적으로 방법론이 정의되어 있어야 한다.

한 클래스 내에서 또 다른 클래스를 생성해서 사용하는 것을 무엇이라고 하며 변수 명을 정하는 기준이나 상속을 하는 이유 등 상당히 자세한 부분까지 방법과 기준이 정의되어 있어야 한다. 물론 그것들 모두에게 일일이 이름을 지어주기란 쉽지 않으므로 뜬 구름 잡듯이 이름 없이 기억하고 있어도 좋다.

중요한 건 그렇다는 사실 자체다. 그런 것은 평소에 열심히 실력을 갈고 닦는 수밖에 없을 것이다.

생각 시작하기
생각은 무한정 할 수 있을 것 같지만 현실 세계에서는 꼭 그렇지만은 않다. 지하철 안에서는 내릴 때가 되었는지를 자주 확인해야하며 직장에서는 열심히 생각하고 있는데 전화가 오거나 옆 사람이 말을 시킬 수도 있다. 그런 상황에서는 방금 한 생각도 잊을 수 있으며 아주 짧은 시간, 수초에 불과한 시간을 활용해서 무언가를 골똘히 생각하는 것은 어렵다.

그러므로 생각을 시작할 때는 ‘앞으로 몇 분간에 걸쳐서 무슨 생각을 하겠다’고 계획을 세우고 생각을 시작하는 것이 좋다.

생각을 구체화하는 기술
어떤 기능이나 절차, 혹은 구조를 생각할 때에는 최대한 그것과 유사한 형태를 일상에서 찾는 것이 빠르고 기억하기 쉽다. 예를 들어서 서버에서 데이터베이스를 가져오는 과정을 쌀통에서 쌀을 가져 오는 것으로 기억하고, 가져온 데이터를 분석하는 과정을 밥 짓는 과정으로 기억하고, 화면에 출력하는 과정은 밥상을 예쁘게 차리는 것으로 기억하고 사용자로부터 입력 받는 과정은 밥이니 반찬을 뜨는 과정으로 기억하자.

이런 과정에서 중요한 점이 하나있는데 실제 코딩에서의 처리 방법을 최소한 한번 이상은 생각해봐야 한다는 것이다. 그렇지 않으면 자칫 소프트웨어에서와 자신이 생각한 비유가 논리적으로 모순이 될 수도 있기 때문이다.

생각은 단어보다는 그림을 이용하는 것이 좋다. 동그라미 네모 등 평범한 모양보다는 별이나 도넛, 연필 등 생활 속에서 자주 접하는 모양이 좋다. 생각하기 좋은 것을 이용하여 비유적으로 생각하는 것이 좋으나 앞서 설명한 것처럼 실제 코딩이나 화면 디자인을 같이 병행하여 두 가지 생각을 동시에 진행하는 것이 좋다.

성과로 연결하기 위한 생각의 중단
그렇게 생각이 진행되면 어느 순간 중단해야 할 때가 온다. 그 순간이 비교적 여유 있는 순간 일 수도 있겠지만 갑작스러운 순간 일 수도 있다. 생각은 시작하는 것보다는 중단하는 것이 더 중요하다. 생각을 중단하는 것은 곧 성과를 정리하는 것과 같으므로 중단을 잘 하지 못하면 성과가 무용지물로 돌아갈 수도 있다.

생각을 중단 할 때 가장 중요한 것은 정리되는데 까지만 기억을 하고 열심히 생각했으나 정리가 잘 안 되는 내용들이나 애매해서 다시 생각해야하는 내용들은 모두 잊어야 한다. 그냥 가만히 있으면 시간이 지나서 저절로 잊혀 지길 바라는 것이 아니라 의식적으로 ‘방금 한 생각은 모두 없었던 걸로 하자’라고 정리를 해야 한다.

그래서 다음에 또 생각을 시작할 때 어디부터 시작해야 하는지를 짧은 시간에 결정할 수 있어야 한다. 생각 중단하기에서 두 번째로 중요한 것은 검토해봐야 할 부분이나 검증이 필요한 내용과 같이 어떤 결정을 내리기 위해 직접 해봐야 할 과제가 있을 때 그것들을 정리하는 일이다. 물론 시간이 없으므로 대략 제목만 빨리 정리한다.

머리 이외의 저장소에 생각 정리하기
천재가 아닌 다음에야 아무리 좋은 생각도 시간이 지나면 잊게 마련이다. 바쁜 업무와 야근에 시달리다보면 방금 전에 뭘 하려고 인터넷 익스플로러를 열었는지조차 기억나지 않는데, 잠깐씩 구체화시켜 놓은 생각 따위는 기억날 리가 없다.

필자의 경우 어느 정도 생각을 하고 정리가 되면 그 내용을 대략적으로 작은 수첩에 정리한다. 비록 작은 수첩이지만 그 기능은 마이크로소프트 오피스 2007 부럽지 않게 기능은 빵빵하다.

글씨 입력되지, 그림 그려지지, 표도 그려지지, 부팅 안 해도 되지 따지고 보면 어느 것 하나 안되는 게 없다. 한 가지 안되는 게 있다면 복사(Ctrl+C)나 붙여넣기(Ctrl+V) 기능이 없다는 것이다. 필자의 경우는 그 대안으로 작은 포스트잇을 이용한다.

물론 클립보드처럼 사본이 만들지는 것은 아니고 기록했다가 맘에 안 들어서 다시 기록하거나 혹은 한 예제를 이런 저런 방법으로 정리해 볼 때에 그 예제를 포스트잇에 기록한다. 그리고 이 내용을 다시 기록해야 할 때 포스트잇을 떼어서 필요한 부분에 옮겨 붙이는 방법으로 재활용한다. 그래서 수첩은 쫙~ 찢어 버리기 좋게 스프링이 있는 수첩을 이용한다.

그렇게 정리된 생각들이 1년이 지자면 꽤 많은 양이 된다. 서두에 밝힌 원격제어 프로젝트의 경우에는 이런 방법으로 정확히 2년을 생각했다. 화면을 캡처하는 방법과 화면 이미지를 압축하는 방법, 압축된 데이터를 소켓으로 전송하는 방법, 서버와 클라이언트를 동기화 하는 방법 등등 모든 과정을 하나씩 떼서 소제목을 붙여서 생각했다.

전체 구조도 하나의 소제목으로 생각해서 각 소 제목 간에 의존성을 없애서 한 가지 생각을 하는데 다른 부분을 참조해야하는 일이 적도록 했다. 결국 프로젝트에 사용된 2개월의 기간은 단순히 코딩만 하는 기간인 셈이었다.

생각을 할 때부터 부분씩 떼서 했으므로 코딩, 디버깅도 부분적으로 한다. OOP가 저절로 될 것은 불 보듯 훤한 일. 버그가 줄어드는 이유도 여기에 있다.

어떤가? 당신이 만들고 싶었던, 언제나 꿈꾸던 프로그램이 있다면 눈앞의 바쁜 업무나 복잡한 잔무들을 탓할 것이 아니라 조금씩 그 꿈을 구체화 시켜보고 싶지 않은가? 참 이상하게도 수첩에 모아둔 생각들은 절대로 그 주인을 배신하는 법이 없어서 시간이 지나면 지날수록 그 꿈에 점점 더 다가가도록 만들어준다.

이런 방법으로 작은 수첩하나를 가슴에 품고 자신의 생각들을 차곡차곡 쌓아가다 보면, 방금 산 복권을 양복 주머니에 넣고 희망찬 모습으로 걸어가는 모습의 복권 포스터 주인공 못지않게 희망찬 하루하루를 살 수 있을 것이다. 수첩이 하나씩 늘어갈 수록 이 복권의 당첨 확률과 일의 능률도 따라 올라간다.

생각하는데 도움을 주는 유틸리티들
역시 가장 좋은 방법은 눈으로 볼 수 있는 것이 가장 좋다. 앞서 예를 들었던 쌀통에서 쌀을 퍼 와서 밥을 짓는 과정을 보자. 사무실 파티션에 예쁜 주방을 배경으로 자신이 좋아하는 연예인이 있는 사진과 멋지게 차려진 식탁 사진 등 자신이 생각하고 있는 내용의 그림이나 사진을 붙여놓고 틈만 나면 그 생각을 해보자. 아마도 많은 도움이 될 것이다.

컴퓨터의 바탕화면도 상당히 많은 도움이 될 수 있다. 벽의 사진이나 컴퓨터의 바탕화면은 전체적인 구조나 일부분의 구조를 반복적으로 생각하여 완벽한 모습을 갖추게 하는데 많은 도움이 된다. <화면 1>과 <화면 2>는 현재 필자가 사용하고 있는 두 개의 바탕화면이다. 노트북에 듀얼모니터를 쓰고 있는데 각 모니터 마다 다른 바탕화면을 쓴다.

<화면 1> 필자가 사용하고 있는 바탕화면-1


<화면 2> 필자가 사용하고 있는 바탕화면-2


두 개의 바탕화면은 서로 밀접한 관계가 있다. 바닷가에 있는 키트와 그 위에 있는 건물들, 또 한 화면에는 금방이라도 음악소리가 흘러 나올듯한 턴테이블 돌아가는 모습. 이 턴테이블은 다른 화면에 있는 건물 안에 있다. 과연 필자는 어떤 상상을 하고 있을까 독자 여러분이 알아 맞혀 보는 것도 좋을 듯하다.

참고로 인터넷에서 필자의 이름으로 검색해보면 과거의 노트북 배경화면을 찾아 볼 수 있다. 그 화면에는 화면 중앙에 키트만 있었다. 지금은 그 생각이 확장된 상태이다.

현실에서 벗어나서 꿈을 이루고 싶다면 생각부터 하자
지면 관계상 딱 한 가지 ‘생각하자’만 정리해봤다. 하지만 서두에서 밝힌 것처럼 OOP 등 기술적인 실력을 쌓고, 열심히 공부하고 작은 것부터 하나씩 생각부터 하는 습관을 기르는 것이 중요하다. 그렇지 않으면 아무리 좋은 생각이라고 구체화되기보다는 공상이 되게 마련이다.

아무리 어려운 기술이라도 그것을 자신의 것으로 만드는 대에는 대략 3년 정도면 충분하다. 필자가 과거에 했던 헬프워드와 원격제어 프로젝트는 모두 2년 정도 생각한 후 작업에 착수한 경우다.

약 2~3개월 정도마다 생각한 것을 정리하기 위해 간단하게 샘플을 만들어 보고 테스트를 해보는 작업을 했었다. 그런 경험으로 봤을 때 대략 2년 정도 생각하면 물건 하나 만들 수 있다. 도합 5년이면 충분하다. 해 볼만 하지 않은가? @

'Computing' 카테고리의 다른 글

훌륭한 프로그래머의 딜레마  (0) 2008.09.19
한국 SW는 레드오션인가?  (0) 2008.09.08
Filezilla Server 한글문제 해결  (0) 2008.05.27
메모리 누수 디버깅  (0) 2007.10.18
메모리 할당한 부분 찾기  (0) 2007.10.18

Filezilla Server 한글문제 해결

Filezilla Server 한글문제 해결
http://www.mesmerize.pe.kr/166


얼마전 새로 Filezilla Server를 설치해서 사용 (FTP 서버 프로그램 비교 (Serv-U / Filezilla server / Wftpd) ) 하고 있었는데, 이 서버에 접속하는  몇몇 사람들이 접속하면, 영어로 된 폴더와 파일은 잘 보이는데 한글로 된 폴더와 파일은 글자가 깨져서 나온다는 이야기를 했다. 나는 FTP 프로그램으로 (Client) 파일질라(Filezilla)를 사용하고 있었는데 한글로 된 파일과 폴더가 이상없이 나와서 그 사람들의 FTP에 문제가 있다고 생각했다. (알 FTP의 오류야~ - 이런저런 알툴즈 시리즈를 별로 좋아하지 않는다.)

그런데 우연히 파일질라 외에 다른 FTP프로그램(LeapFTP)으로 그 문제의 서버에 접속해보니, 나 역시 한글로 된 파일이름이 깨져서 보이는 것이 아닌가! 다른 사람의 FTP프로그램의 문제가 아니라 파일질라 서버의 문제였던 것이다. 뭐가 문제인지 몰라 파일질라 서버의 설정을 들여다봤는데 도무지 원인을 알 수가 없었다. 모든 FTP 프로그램에서 문자가 이상하게 나오면 서버 프로그램이 이상하다고 생각할 테지만 내가 처음에 사용했던 파일질라는 문제없이 한글을 보여줬으니...

인터넷을 마구 뒤진 결과 문제의 원인과 해결책을 찾아냈다. 원인은 파일질라 서버는 파일을 UTF8로 인코딩하여 전송하는데 알FTP 등 많은 수의 FTP프로그램은 UTF8로 인코딩된 문자를 지원하지 않는다. UTF8을 지원하는 FTP프로그램을 다른 사람들이 사용하거나(Filezilla), 서버쪽에서 문자열을 변경할 수 있으면  문제가 쉽사리 해결될텐데 두 가지 모두 바꾸기가 쉽지 않았다. 다행히 소스포지쪽에서 파일질라 서버파일을 일반 FTP프로그램에서 문자열이 잘 보이도록 하는 패치파일을 제공하고 있었다.



위의 주소로 가면 최신 파일질라 서버 버전에 맞는 패치 파일이 올라와있다. 이 패치 파일을 서버가 설치된 폴더에 덮어 씌우면 된다. 단 이 때는 미리 작업관리자 등을 통해서 파일질라 서버의 프로세스를 먼저 종료시켜야 한다.

추가 ) 패치파일은 7z라는 압축형식으로 되어있으며, 이 압축파일은 널리 쓰이는 빵집 혹은 알집 등의 프로그램으로 풀 수 있다. 압축을 풀면 filezilla server.exe파일이 생성되는데 그 파일을 설치된 폴더에 복사하면 설치 완료

메모리 누수 디버깅

메모리 누수 디버깅..

http://blog.naver.com/nixie77?Redirect=Log&logNo=60033515206

원문 보기

일반적으로 가장 잡기 힘든 버그의 하나로서 메모리 누수, 메모리 Overwrite등을 꼽을 수 있다. 이런 문제점을 해결하기 위해 CRT(C Runtime library)에서는 여러가지 다양한 메모리 관련 디버그 함수들을 제공한다. 그러나 이것들이 디폴트로 사용하기 힘들게 꺼져 있기 때문에 대부분의 프로그래머들은 이 사실을 알지 못하는 경우가 많다. 그래서 이 글에서는 CRT의 디버그 관련 함수들에 대해 알아보고 어떻게 사용하는 것이 좋은지에 대해 논해 보려고 한다.


John Robbins(필자가 가장 좋아하는 프로그래머 중의 한명)가 지은 Debugging Applications 이라는 책에도 좋은 내용들이 있으니 참고하기 바란다. 그러나 여기 나온 팁은 그 책에는 나와 있지 않은 것이다. Numega Bounds Checker나 Rational Purify등의 툴이 비싸서 엄두도 못내는 분들께는 좋은 내용이 되리라 믿는다




메모리 누수


개요


CRT가 출력해 주는 메모리 누수 리포트 결과를 간혹 본적이 있는 사람도 있을 것이다. 만약 MFC를 주로 사용한다면 이와 같은 메시지를 자주 볼 수 있다. 왜냐하면 MFC에서는 기본적으로 CRT 디버그 기능을 켜기 때문이다. 메시지 내용은 다음과 같다


Dumping objects ->

{65} normal block at 0x003748B0, 48 bytes long.

Data: <@H7 @H7 @H7 > 40 48 37 00 40 48 37 00 40 48 37 00 CD CD CD CD

{64} normal block at 0x00374840, 48 bytes long.

Data: < H7 H7 H7 > B0 48 37 00 B0 48 37 00 B0 48 37 00 CD CD CD CD

Object dump complete.

이 메시지의 내용은 두개의 블록이 할당된다음 해제되지 않았다는 것을 의미한다. 그렇다면 우선 이 메시지들에 대해 대략 알아보도록 하자


우선 {64}, {65}와 같은 것은 메모리에 할당된 순서로서, 각각 64번째, 65번째 할당된 메모리가 해제되지 않았음을 나타낸다. Normal block이라 함은 사용자에 의해 일반적인 new, delete, malloc등으로 할당된 메모리라는 뜻이다. 그리고 그 메모리 포인터 주소를 알려주고 있으며, 몇 바이트짜리 메모리 블록인지도 나와 있다


Data:… 라인은 그 메모리의 선두번지로부터 실제 메모리의 내용이 어떤 값을 포함하고 있는지를 나타내는 것이다

그러나 위의 메시지를 보았듯이 실제로는 아무 도움이 되지 않는다는 것을 금방 알수 있을것이다. 왜냐하면 메시지의 내용이 너무 암호와같이 복잡하다는데 문제가 있다. 몇줄짜리 프로그램이라면 또 모르겠으나, 거대한 프로그램인 경우 실제로 64,65번째 할당된 메모리를 순서대로 추적하는 것은 너무나도 어려우며, 어떤 포인터에 어느 번지의 메모리가 할당되었는지를 확인하는 것도 불가능에 가깝다고 할 수 있다. 또 자신이 만든 클래스나 구조체가 몇 바이트짜리인지를 일일이 확인한다는 것도 불가능하다.


그렇다면, 이 문제를 어떻게 해결해야 할 것인가? 실제로 CRT에는 여러가지 도우미 함수들을 포함하고 있어서 이 문제를 좀 더 쉽게 해결할 수 있도록 해 준다. 그러나 제대로 알고 사용하지 않는다면 결국에는 또다른 암호 코드만을 추가로 더 얻게 될 뿐이라는 것도 알아야 한다


샘플코드


#include "stdafx.h"

int main()
{
int *p = new int;

return 0;

}

위의 코드는 int *를 할당하고 해제하지 않았으므로 명백한 메모리 누수이다. 그러나 이 프로그램을 빌드하고 디버그해봐도 프로그램 종료시 아무런 메시지를 남기지 않는다. 즉 메모리가 샌것인지, 혹은 Overwrite가 일어났는지 등을 확인할 길이 전혀 없다. 그러면 프로그램 일부를 수정해 보도록 한다

#include "stdafx.h"
#include

int main()
{

int *p = new int;

_CrtMemDumpAllObjectsSince(0);

return 0;
}

_CrtMemBumpAllObjectsSince를 사용하기 위해 crtdbg.h를 인클루드 하고, 프로그램 종료 직전에 함수를 호출했다 디버그를 시작하고 프로그램을 종료하면 출력결과는 다음과 같다
Dumping objects ->

{64} normal block at 0x00374838, 4 bytes long.

Data: < > CD CD CD CD

Object dump complete.
The thread 0x65C has exited with code 0 (0x0).
The program 'test.exe' has exited with code 0 (0x0).

위에서 설명한것과 비슷한 종류의 메시지가 포함되어 있는 것을 알 수 있을 것이다. 이 메모리는 64번째 할당된 일반 메모리이며 0x00374838번지에 4바이트 할당되었음을 알 수 있다. 또 데이터 내용은 16진수로 CD CD CD CD이다 이 정보만으로도 많은 것을 알 수 있다. 예를들어 데이터가 CD CD CD CD라는 것은 할당만 해놓고 전혀 초기화를 하지 않았다는 의미이다. 단순한 위의 프로그램 만으로도 사용자가 처음 할당한 메모리가 64번째만에 할당되었다. 이유가 무엇일까? 이유는 간단하다. main함수가 호출되기 이전에 이미 많은 메모리 할당 요청이 있었고, 그것은 프로그램을 실행시키기 위해 운영체제나, CRT가 이미 사용했기 때문이다. 위의 프로그램은 단순하기 때문에 어디서 메모리가 샜는지 한눈에 척 알 수 있다. 그러나 메모리를 수십~수백번씩 할당했다 해제하는 일반 애플리케이션에서는 어떻게 정확히 64번째 할당된 메모리를 찾아낼 수 있을까? CRT에서 내준 정보는 CRT를 이용해 분석 가능하다 main함수가 처음 시작되기 전에 다음의 함수를 사용하도록 하자



_CrtSetBreakAlloc(64);

int *p = new int;


이 함수는 64번째 메모리 할당이 발생할 경우 프로그램 실행을 중지하고 디버거로 제어를 넘기라는 의미이다. 실제로 프로그램을 실행시켜 보면, “crtdbg.exe의 0x00411cb7에 처리되지 않은 예외가 있습니다. 사용자 중단점”과 같은 메시지를 출력하면서 프로그램 실행을 중지하게 된다. 브레이크 포인트가 가리키는 위치는 CRT의 메모리 할당 함수 내부이며, Call Stack을 따라가 보면 어느곳에서 할당이 일어났는지 바로 알수 있게된다.

전역 변수와 CRT 디버깅


다음과 같은 프로그램을 보도록 하자


#include "stdafx.h"
#include "crtdbg.h"
#include

class A
{
public:
A() { p = new int; }

private:
int *p;
};

A a;

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
_CrtSetBreakAlloc(64);

_CrtMemDumpAllObjectsSince(0);

return 0;
}

이 프로그램을 디버그 해 보면 똑 같은 메모리 누수를 보고하긴 하지만, 그러나 64번째 메모리 할당에서 정지하지 않는다. 이유가 무엇일까?

이유는 간단하다. A라는 클래스의 인스턴스인 a가 전역변수로 선언되었기 때문에 main함수가 호출되기 이전에 생성되기 때문이라는 것이다. a가 이미 생성되고 난 다음에 브레이크 포인트를 설정하니, 브레이크 포인트가 먹힐리가 없다. 그럼 방법이 없는 것일까?


답은 간단하다. 모든 할당이 일어나기 직전에 프로그램을 정지시켜놓고, 64번째 메모리 할당이 일어날 때 브레이크 하라는 명령을 주면 된다. 그럼 어떻게 하면 될까? 다음과 같이 하도록 한다.




CRT소스에서 WinMainCRTStartup()함수를 찾아낸다. 이 함수는 실질적인 main함수이며, 프로그램이 로드되기 전에 가장먼저 실행된다. 이 함수 내부에서 여러분이 정의한 main 또는 WinMain함수를 호출하게 된다. 이 함수는 파일의 찾기 기능을 이용하거나, 또는 crt0.c파일을 바로 열어서 찾아도 된다. 그러나 더 간단한 방법은 main함수에 BP를 찍어놓고, 한번 실행시킨다음 call stack을 거슬러 올라가는 방법이다.

WinMinCRTStartup함수의 시작부분에 BP를 찍어놓고 다시 디버거를 시작시킨다

Watch창을 열어 _crtBreakAlloc 변수를 확인해 본다. 아마 -1일 것이다.

이 변수값을 원하는 메모리 할당 번지(위의 경우64)로 바꾼다.

다시 실행시키면 64번째 메모리 할당을 하기 전에 정지한다.


이 기술은 코드를 재 컴파일 하지 않아도 디버거 상에서 바로 브레이크 포인트를 수정할 수 있다는 장점이 있다. 현재 이 방법 보다 간단하게 할 수 있는 방법은 현재 연구중에 있다. 좋은 결과가 나오는대로 다시 여러분들에게 알려드리도록 하겠다.


이상 몇가지 메모리 누수를 찾아내는 방법을 살펴보았다. 그러나 주의할 것은 반드시 crtdbg.h를 같이 인클루드 해야 한다는 것이며 _DEBUG매크로가 정의되어 있을때에만 제대로 동작한다는 것이다.
CRT Debug 기능 사용법 2


요즘 CRT의 디버그 기능을 연구하기 시작하면서, 그동안 정말 좋은 기능들을 여럿 묵혀놓았다는 느낌을 지울수가 없습니다. 어렵게 메모리 관련 디버깅 루틴을 만들지 않아도, 너무나도 정확히 메모리 관련 에러를 잡아주니 STL을 처음 쓸 때 만큼이나 편리하게 느껴지더군요. 그럼 그동안 제가 연구한 것에 대해 보고드리도록 하겠습니다


지난 내용의 메모리 누수가 아닌 것 까지 모두 보고하는 문제


지난번 예제에서 약간만 더 수정해 보자


#include "stdafx.h"
#include
#include
using std::list;

typedef list IntList;
typedef IntList::iterator IntListIter;

IntList myList;

int main()
{
_CrtMemDumpAllObjectsSince(0);

return 0;
}

위의 프로그램은 메모리 누수를 한 개 보고한다. 위치는 myList의 생성자이다. 그러나 정말 그것이 샌것일까? 그렇다면 STL은 항상 메모리 누수가 있다는 말인가.. 이것저것 고민하던 중에, 진짜 Main함수는 {{{WinMainCRTStartup()}}}라는 사실이 생각났고, 디버그 상에서 {{{WinMainCRTStartup()}}} 메소드의 끝까지 따라가 보았다. 그랬더니 다음과 같은 루틴을 찾을 수 있었다. (처음에는 숨겨진 함수를 찾았다고 생각했으나, 알고봤더니 MSDN에 이미 문서화 되어있는 함수였다. 역시 소스보다는 문서를 찾아보는 것이 우선이다 -.-)
{{{
/* Dump all memory leaks */
if (!fExit && _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) & _CRTDBG_LEAK_CHECK_DF)
{
fExit = 1;
_CrtDumpMemoryLeaks();
}

_CrtSetDbgFlag이라는 함수는 CRT디버거의 전역 플랙을 셋팅하는 함수이다. 위에서 보다 시피 이미 CRT의 메인함수가 종료할 때 메모리 누수를 검사하고 있었던 것이다. 다만 디폴트로 꺼져 있었으며 열쇠는 _CrtSetDbgFlag이라는 함수가 쥐고 있다. MSDN에서 찾아본 결과 다음과 같다. _CrtSetDbgFlag함수는 다섯개의 Flag이 있다.
_CRTDBG_ALLOC_MEM_DF : 디폴트로 켜져 있으며, 디버그 버전에서 모든 메모리 할당이 일어날 때마다 추적 가능하도록 특별한 기능을 추가해 둔다. 이 플랙이 켜져 있어야 메모리 누수를 안전하게 검사 할 수 있다.


_CRTDBG_DELAY_FREE_MEM_DF : delete, free등으로 삭제되어도 바로 삭제되지 않고, CRT의 메모리 관리소에 남아 있다가 프로그램 종료시에 완전히 삭제된다.


_CRTDBG_CHECK_ALWAYS_DF : 모든 메모리관련 연산에서 _CrtCheckMemory를 호출한다. 이 메소드는 이후에 다시 살펴볼 것임


_CRTDBG_CHECK_CRT_DF : CRT가 내부적으로 할당한 블록도 메모리를 체크할 때 포함한다. 일반적으로는 CRT가 할당한 블록은 메모리 체크에서 제외된다. 일반적으로 사용하지 않는다


_CRTDBG_LEAK_CHECK_DF : 프로그램이 완전히 종료되기 직전에 아직 해제되지 않은 메모리가 있는지 검사한다. 프로그램의 종료 포인트가 여러군데 있는 경우에 사용하면 일일이 _CrtDumpMemoryLeaks 메소드를 호출하지 않아도 자동적으로 메모리 누수를 검사할 수 있게된다.




이 중에서 첫번째 플랙만을 제외하고는 모두 디폴트로 꺼져있다. 그러므로 다음과 같이 메모리 검사 기능을 켜도록 한다


_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

위의 프로그램에서는 다음을 삭제한다

_CrtMemDumpAllObjectsSince(0);


_CrtMemDumpAllObjectsSince 함수는 실제로는 특정 지점에서 지점간에 할당되어 있는 메모리들을 보고해 주는 함수이다. 인자로 0을 넘겨주면 처음부터 지금까지 할당되어 있는 메모리들을 보고해 준다. CRT가 아직 전역으로 할당된 메모리를 완전히 삭제하기도 전에 호출했기 때문에 STL의 메모리가 샌 것 처럼 보인것이다.


CRT 메모리 블럭


다음으로 넘어가기 전에 다음을 짚어보고 넘어가기로 하자. 디버그 버전에서는 메모리가 할당되거나 사용되기 직전에 특정한 값들로 할당된 메모리가 채워진다는 것을 알고 계실것이다. 의미는 다음과 같다


0xFD : 메모리 블록 양 끝의 버퍼에 생성된다
0xCD : 새로 생성된 버퍼에 저장되는 기본값이다
0xCC : 스택에 변수가 생성되면 우선 이값으로 채워진다
0xDD : 삭제된 메모리 블록은 이 값으로 채워진다


다음 예제를 보자


int main()
{ // 함수 시작지점

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

int *p = new int [10]; // 메모리가 할당되는 지점
printf("%d", *p);
delete [] p; // 메모리가 삭제되는 지점

return 0;
}

함수 시작지점에서 포인터 p는 초기값으로 0xCCCCCCCC를 갖게 된다. 디스어셈블 해보면 모든 지역변수들을 0xCC로 채워넣는 것을 볼 수 있다. 이후 메모리가 할당되는 지점에서 아마도 sizeof(int) * 10 바이트의 메모리가 할당될것이다. Sizeof(int)가 4바이트라면(32비트 운영체제에서) 40바이트가 생성되는 것이다.(디버그 버전이라는 가정하에) 이렇게 생성된 40바이트에 0xCD값이 채워진다. 만약 어떤 포인터의 값을 읽었을 때 값이 0xCDCDCDCD와 같은 형식이거든 초기화안된 메모리를 읽었다고 생각하면 된다.


그런데, 위의 할당지점에서 실은 48바이트가 생성된다. 40바이트 할당 명령을 주었는데 왜 48바이트의 메모리가 할당되었는가 이유는 위의 0xFD값에 있다. 40바이트의 블록을 생성시키고 그 블록의 앞과 뒤에 각각 0xFDFDFDFD를 삽입시켰기 때문이다. 이 값이 채워지는 이유는 다음과 같이 접근하는 경우


p[-1] = 10; // underwrite
p[11] = 10; // overwrite

0xFD로 채워진 메모리의 일부분이 깨질 것이고, 나중에 사용할 메모리 체크 명령에 의해 overwrite/underwrite가 발생했다는 사실을 알 수 있게된다.

마지막으로 메모리가 삭제되는 지점에서는 이론 대로라면 p값이 0xDD로 채워질 것이다. 그러나 실제로 필자의 컴퓨터에서는 0xFEEE가 채워졌다. 왜 그런지는 좀더 연구해 보고 알려드리도록 하겠다. -.- 오늘은 일단 여기까지 접고 연구결과가 더 나오는대로 여러분께 보고하는 시간을 갖도록 하려한다.


CRT Debug 기능 사용법 3


지난번에 이어 이번에는 메모리에 어떤 문제가 있었는지를 체크해주는 _CrtCheckMemory함수에 대해 연구해 보도록 하겠습니다.


강좌를 진행하기 전에 지난번 강좌 마지막 부분에서 메모리가 삭제될 때 0xDD값 대신에 0xFEEE값이 채워지는 이유를 찾아본 결과 CRT에서는 0xDD값을 정확히 채워 넣는다는 것을 확인하였다. _CRTDBG_DELAY_FREE_MEM_DF 플랙이 디폴트로 꺼져 있기 때문에 삭제했다는 표시를 하고 난 다음 바로 운영체제에서 삭제(진짜 삭제) 해버렸기 때문이다. 이부분은 뒤에서 다시 알아보도록 하겠다.


_CrtCheckMemory()

지난번에 알아보기를 CRT에서 메모리를 할당하려 할 때 몇가지 정보블럭들을 설정한다는 것을 알았을것이다. 자 이제는 설정된 정보블럭들을 검사할 차례이다. 문제는 일일이 디버거의 Watch창이나 Memory창을 이용해 블록이나 스택이 깨졌는지를 확인해야 한다는 것이다. 이런 기법은 아마도 잘 알고 있을 것이다. 특정 메모리 주소를 가르키게 해놓고 의심되는 코드를 실행시켰을 때 Memory창의 내용이 빨간색으로 변하는 모양을 살펴서, 엉뚱한 부분까지 쓰거나, 원치않은 결과를 얻는지를 확인하는 것이다. 문제는 이것이 너무나도 수동적이기 때문에 CRT에서는 _CrtCheckMemory라는 도우미 함수를 곁들였다. 이 함수는 몇가지 경우에 있어서는 아주 쓸만하다. 사용법을 보자


int _tmain(int argc, _TCHAR* argv[])
{
if(_CrtCheckMemory() == 0)
return -1;

return 0;
}

그냥 메모리 체크를 하기 원하는 위치에 _CrtCheckMemory함수를 삽입하기만 하면된다. 만약 0을 리턴한다면 할당된 메모리에 어떤 문제가 발생했다는 것을 의미한다. 그러나 위의 코드는 문제가 하나 있는데 바로 모든 CRT의 디버그 함수들은 DEBUG버전에서만 의미를 가지기 때문에 RELEASE버전에서는 아무 의미없는 코드가 된다는 것이다. 일단 보기에도 두 줄에 걸쳐 표기되어 있으므로 흉하다. 그러므로 다음과 같이 코딩하도록 한다.


_ASSERTE( _CrtCheckMemory( ) );

_ASSERTE는 CRT에서 제공해주는 매크로이다. 또는 assert.h의 assert함수를 이용해도 좋다. MFC등을 사용한다면 ASSERT등을 사용해도 좋고 Robbins의 SUPER_ASSERT를 사용해도 좋다. 각각 약간씩의 차이점이 있기는 결과는 거의 같다. 그러니 여기서는 CRT를 사용한다는 일관성을 유지하기 위해 _ASSERTE를 사용하도록 하겠다.


단순히 위와같이 의심갈때마다 호출해 주기만 한다면, CRT는 지금까지 등록된 모든 할당된 메모리들을 검사해 문제가 발생했는지를 확인한다. 그럼 어떤 종류의 에러들을 잡아주는지 다음의 예제들을 통해 알아보도록 하자


예제1. 경계를 넘어서서 쓰는 경우


int _tmain(int argc, _TCHAR* argv[])
{
int *p = new int[10];

p[-1] = 100; // 둘다 모두 오류이다
p[10] = 100;

_ASSERTE( _CrtCheckMemory( ) );

return 0;
}

위의 예제에서는 정수 타입 10개짜리 배열을 할당하고 11번째 멤버에 쓰기를 시도하였다. 이부분에는 지난 강좌에서 알려 드렸듯이 0xfd값이 채워져 있는 영역이다. 주어진 메모리 체크 함수는 0xfd값이 있어야 할 자리에 다른 값이 있는 경우 0을 리턴한다.


예제2. 삭제된 포인터에 접근을 시도하는 경우


int _tmain(int argc, _TCHAR* argv[])
{

// _CRTDBG_DELAY_FREE_MEM_DF 플랙을 반드시 켜야된다
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_DELAY_FREE_MEM_DF);

int *p = new int[10];
delete [] p;

p[0] = 10;
_ASSERTE( _CrtCheckMemory( ) );

return 0;
}

위 예제에서는 이미 삭제된 포인터를 다시 접근하고 있다. 이것은 디폴트로 비활성화된 플랙을 사용하므로 위의 예제에서처럼 프로그램 시작전에 _CRTDBG_DELAY_FREE_MEM_DF 플랙을 켜줘야한다. 이 플랙이 켜지게 되면 CRT는 삭제 명령(free함수)이 호출되는 경우 바로 삭제처리하지 않는다. 대신 삭제 처리했다는 표시(0xdd값)만을 남겨둔다음 필요할 때 이값이 깨졌는지 검사한다. 디버그 버전이라면 이 플랙은 반드시 켜두도록 한다. 물론 메모리 부하가 약간 더 있겠지만 심각한 오류를 검출하는데는 꼭 필요한 플랙이다. 어차피 디버그 버전은 디버깅이 최고의 목표이니까..

이 두가지 기능만해도 일반적인 프로그래머들이 겪는 대부분의 메모리 문제는 해결된다. 아! 필자가 지금까지 봐온 대부분의 메모리 관련 문제들은 거의 60%이상이 초기화가 되지 않았거나 쓰레기값이 들어있는 포인터 접근 문제였다. 이문제는 위의 함수가 잡아주지 않는다. 그럼 쓰레기값이 들어있는 포인터 접근 문제는 어떻게 해결하겠는가? 아시는 분들은 다 아실것이다 0xC0000005 오류가 바로 정답이다. 또 대부분의 컴파일러의 경우 컴파일하는 도중에 이미 초기화 안된 변수를 사용했다고 여러분들에게 알려줄 것이다.


다음에는 구간과 구간 사이에서 메모리 문제를 발견하는 방법에 대해 다룰 것이다. 전체 프로그램에서 문제를 발견했다면 그 범위를 점차 좁혀나가는 것이 중요하다. 아쉽지만 필자 개인적인 사정으로 인해 조금 늦어질지도 모르겠다

메모리 할당한 부분 찾기

http://blog.naver.com/nixie77?Redirect=Log&logNo=60033515206


메모리 릭이 생겼는데 알수 없는 문자들만 가득!!


{5038} normal block at 0x0176A028, 68 bytes long.
 Data: <  ;   ;   ;     > 10 B4 3B 00 10 B4 3B 00 10 B4 3B 00 00 00 00 00


이것은 과연 무엇인가??


{5038} -> 메모리 할당하였을때 인덱스(?) ( 다이렉트 x도 다이렉트 x용 인덱스(?)가 있겠죠?? )

노말 블럭.. 뭐냐.. 이건.

그리고 그다음 주소부터 시작해서 68 바이트들이 메모리 해제를 안했단 말이죠.


그 밑줄 Data: < ; ; ; >이것은 저 주소에 들어가 있는 값을 대충 보여준건데요.

가끔씩 아스키 값이 들어갈때나 그럴때는 유용하기는 하죠. 근데 거의 쓸 일이 없어요.


그 뒤에는 그에 맞는 값들을 나열 했습니다.


이제.. 본격적으로 메모리 릭을 어떻게 알수 있을까요?


브레이크 포인터를 main 전의 함수에서 겁니다.

그다음에 {,,msvcr80d.dll}_crtBreakAlloc <- 2005 버전

이렇게 적으면 -1이라고 뜨죠

할당할 인덱스가 오면 브레이크 걸어라는 뜻이죠.


여기다가 5038을 넣으면 거기서 딱걸림. ㅋ


mfc {,,msvcr80d.dll}_crtBreakAlloc

mfc {,,msvcr71d.dll}_crtBreakAlloc

6.0 모름


api 모름


일반프로젝트 _crtBreakAlloc (아마도)

SATA2 하드디스크의 NCQ 기능 사용하기

Microsoft Robotics Studio에서 XInputController

http://blogs.msdn.com/coding4fun/archive/2007/07/16/3902344.aspx

그런데 이상하게 동작을 안한다.. 쩝..
뭔가 Configuration이 이상한거 같은디..

C++ 형변환 연산자 (cast operators), C 형변환 연산자 ()

참고] C++ 형변환 연산자 (cast operators), C 형변환 연산자 ()

내용 수준: 초급~중급


표준 C++에서는 4개의 형변환 연산자가 추가되었습니다.


dynamic_cast<>()

const_cast<>()

static_cast<>()

reinterpret_cast<>()


따라서 C의 형변환 연산자 () 를 포함해서 5개의 형변환 연산자를 사용할 수 있습니다. 이미 많은 사이트에서 논쟁이 있었지만 흔히들

C++에서는 되도록이면 C 형변환 연산자 () 를 사용하지 않도록 권장합니다. 이렇게 C 형변환 연산자 () 대신에 새로운 C++ 형변환 연산

자들의 사용을 권장하는 이유로 첫 째, 코드의 호환성이 증대되고 둘 째, 코딩의 의미를 분명히 함으로써 의도하지 않은 오류를 사전에

예방할 수 있다고 합니다.


대부분의 C++ 프로그래머들은 C++ 형변환 연산자들이 프로그램에서 사용될 때 어떠한 역할을 하는지 다들 잘 알고 있겠지만 실재 어떤

상황에서 어떻게 적용되어 지는게 바람직한지 c 형변환 연산자 ()는 왜 나쁘고 이런 상황에서 어떠한 C++ 연산자를 사용해야 하는지 조

리있게 조목조목 따져보지는 않는것 같습니다. 여기서는 각각의 C++ 형변환자에 대해서 아주 "간단히" 알아본 후 왜 C 형변환 연산자

() 의 사용이 바람직하지 않은지, 이 때 어떤 C++ 형변환 연산자를 대신 사용하는게 좋은지 생각해봅니다.



dynamic_cast 연산자


dynamic_cast<>()는 RTTI(RunTime Type Information) 흔히 OOP의 다형성의 개념을 구현하기 위해서 C++에서 제공되는 형변환 연산자입

니다. 다른 세 가지 형변환 연산자와는 확연히 다른 용도라 할 수 있고 더욱이 C 형변환 연산자 () 와는 별다른 관계가 없다고 볼 수

있습니다. 자세한 내용은 MSDN이나 다른 문서를 참조하세요.


const_cast 연산자


const_cast<>()constvolatile 조건을 설정/해제하는 형변환을 해줍니다. 다른 C++형변환 연산자들절대로 constvolatile

조건을 해제하는데 사용할 수 없습니다 라는 내용을 일반적인 문서들에서 찾아볼 수 있습니다.


const double d = 20.0;

double d2 = const_cast(d); // OK? 아니 컴파일 에러 발생!!! 암시적인 형변환 또는 static_cast<>() 필요하다고 불평.

double d3 = d;                                // OK! o.O

double d4 = static_cast(d); // OK! O.o


위의 const_cast<>() 설명을 읽지 않고서 그냥 위의 샘플을 접하면 세 째, 네 째 라인의 대입문이 문제없이 컴파일 실행되는 것이 전혀 이상하지 않았을텐데 일단 const_cast<>() 설명을 읽고나니 이상하군요. 인터넷을 대충 찾아봐도 const_cast<>()가 포인터나 참조랑 같이 사용될 때 const 또는 volatile 조건을 해제한다라는 문구는 찾을 수 없었지만 const_cast<>()를 다음 샘플 코드에서 처럼 사용할 때 const 또는 volatile 조건을 해제할 수 있다는 것을 알 수 있습니다. 포인터 또는 참조가 아닌 데이터 변수(객체)에 직접 const_cast<>()를 사용하여 const 또는 volatile 조건을 제거하려면 컴파일 에러가 발생합니다.


const double d = 20.0;

const double *pCD = &d;

double *pD = const_cast(pCD);                      // OK!

double *pD2 = static_cast(pCD);                     // 컴파일 에러! static_cast<>()는 const 조건 "해제" 불가능

const double *pCD2 = static_cast(*pD);  // OK! static_cast<>()로 const 조건 "설정" 가능


double &rD = const_cast(d);                          // OK!

double &rD2 = *const_cast(&d);                     // OK!


*pCD = 30.0;                                                                // 컴파일 에러! *pCD는 const double 형 변수

rD = 30.0;                                                                     // 컴파일 OK! 그러나 상수형 변수의 값을 변경하는 것은 정의되지 않은 행동


const_cast<>()를 이용하여 const 조건을 해제할 수 있지만 이 것이 const 변수(객체)의 값을 변경할 수 있다는 것을 의미하지는 않습니다. const 변수(객체)의 값을 const_cast<>()를 이용하여 const 조건 해재 후 변경하는 경우는 C++ 표준에서는 정의되지 않은 행동(undefined behavior)으로 정의 합니다. 쉽게 무슨 일이 일어날지 모릅니다. volatile 조건 역시 const 와 동일한 방법으로 동작합니다.


static_cast 연산자


static_cast<>()는 암시적으로 형변환이 일어나는 경우에 이를 명백하게 형변환을 하겠다라고 분명히 해주는 용도록 사용될 수 있습니

다.


bool b = true;

int n = static_cast(b);


위와 같은 예제에서 굳이 static_cast<>() 를 사용하지 않고 b를 정수형 n에 대입하여도 암시적인 형변환이 자동적으로 이루어집니다.

하지만 위와 같이 명백하게 static_cast<>()를 사용하게 되면 프로그래머의 형변환 의도를 분명하게 나타내주면서 차후에 문제가 생길

지도 모르는 소지를 없애줍니다. C++ 표준에 static_cast<>() 대신에 위와 같은 암시적인 형변환을 나타내는 implicit_cast<>() 연산자

를 포함하자는 주장도 있었다고 합니다. implict_cast<>()는 템플릿을 이용하여 다음과 같이 쉽게 정의할 수 있습니다.


template

inline TO implicit_cast(const FROM &x)

{

 return x;

}


bool b = true;

int n = implicit_cast(b); // 암시적인 형변환이 이루이진다는 것을 명백히 해줌.


다른 한편으로 static_cast<>()는 컴파일 시에 제공되어지는 형정보를 이용하여 가능한 형변환인 경우 데이터의 내부 바이너리 구조를

변경하기도 합니다. 앞선 암시적인 형변환의 경우와는 다르게 이 경우에는 반드시 static_cast<>()를 사용해야 합니다.


float f = 10.0f;

int n = static_cast(f); // n은 10


위의 예제에서 float형 10.0 과 int형 10 의 내부 바이너리 구조는 확연하게 다르다는것을 쉽게 알 수 있죠.


마지막으로 위의 경우와 같은 맥락으로 (데이터의 내부 바이너리 구조 변경한다는) 상속관계에서 빈번하게 static_cast<>()를 사용하

는 경우는 다중 상속관계에서 다운캐스팅(downcasting)할 때 입니다. 일반적으로 업캐스팅(upcasting)은 항상 안전한 형변환(type

safe)이고 암시적으로 형변환이 일어나기 때문에 특별한 형변환 연산자를 사용하지 않아도 문제가 없습니다. 그러나 다운캐스팅 할 때

에는 컴파일 시 제공되어지는 형정보를 이용하여 적절한 this 포인터의 계산이 이루어집니다. 즉 내부 바이너리 구조가 변경됩니다. 여

기서 dynamic_cast<>()static_cast<>()가 다른 점이 static_cast<>()는 사용자가 변환하고자 하는 형과 원래 데이터형이 상속관계에

있기만 하다면 컴파일러는 이러한 사실만을 확인하고 사용자가 제공한 상속 관계가 옳바른 관계인지는 확인하지 않습니다. 반면에

dynamic_cast<>()는 실행 시 실재로 이러한 관계가 옳바른 관계인지 확인하고 이에 따라서 적절한 조치(NULL 리턴)를 합니다.


class B1

{

};


class B2

{

};


class D1 : public B1

{

};


class D2 : public B1

{

};


B1 *pB1 = implict_cast(new D1()); // 컴파일 & 실행 OK!, 업캐스팅, 암시적인 형변환

B2 *pB2 = static_cast(new D1());  // 컴파일 에러! 업캐스팅! 그러나 B2와 D1은 상속관계가 아님

D1 *pD11 = pB1;                                // 컴파일 에러!, 다운캐스팅 따라서 static_cast<>() 필요

D1 *pD12 = static_cast(pB1);      // 컴파일 & 실행 OK! 다운캐스팅

D2 *pD2 = static_cast(pB1);       // 컴파일 OK! 그러나 런타임 에러!

                                                    // D2와 B1이 상속관계에 있기 때문에 컴파일러는 에러를 발생시키지 않지만

                                                    // 실재로 pB1은 D2가 아니라 D1 객체을 가리킴.


reinterpret_cast 연산자


reinterpret_cast<>()는 포인터나 정수형 데이터를 다른 임의의 포인터나 정수형으로 변경합니다. 즉 포인터에서

부동소수형(float,double)형 또는 그 반대 방향으로의 형변환에는 사용할 수 없습니다. reinterpret_cast<>()는 데이터의 내부 바이너리 구

조를 변경하지 않으며 컴파일 시에 제공되어지는 형변환 정보에 의존하지도 않습니다. reinterpret_cast 라는 이름이 의미하는 그대로

주어진 데이타의 의미를 강제적으로 프로그래머가 원하는, 즉 보통 서로 관련되지 않는, 다른 의미로 해석하겠다는 의지를 나타냅니다.

이는 컴파일러를 속이겠다는 의미라고 볼 수도 있으며 이에 따라서 예측하지 못한 오류가 발생할 위험성이 높아지며 이 때문에

reinterpret_cast를 자주 사용하면 좋지 못한 코딩 습관이라고 하는 이유입니다. 또한 이러한 코드는 컴파일러에 종속되기 쉽상이고 호

환성이 떨어지는 프로그램이 됩니다.


C 형변환 연산자 ()


C 형변환 연산자 ()는 C++ 형변환 연산자들 중에서 dynamic_cast<>()를 제외한 나머지 3가지 형변환 연산자를 대신하여 사용할 수 있는

만능 형변환 연산자 입니다. 동시에, 그렇기 때문에 사용해서는 안되는 연산자이기도 합니다. 단순하게 C 형변환 연산자 ()를 사용하면 컴파일

러가 알아서 static_cast<>(), const_cast<>() 또는 reinterpret_cast<>()가 필요할 각각의 상황에 맞게 변환해줍니다. 경우에 따라서

는 2개의 C++ 형변환 연산자를 콤보로 적용하는 효과를 내기도 하는 만능 연산자입니다. 코드를 작성하는 프로그래머 입장에서는 아주 편리하게 사

용할 수 있지만 코드를 분석하는 입장에서보면 코드를 작성한 프로그래머의 의도가 무엇인지를 혼돈시키는 가장 큰 장애물로 작용합니

다. (초보 프로그래머의 경우는 C 형변환 연산자 ()를 사용하면서 자신이 무엇을 의도했는지 파악하지 못하는 경우도 있을거라 생각합니다.)


float f = 10.0f;

int n = (int)f; // static_cast(f)와 동등


// const_cast<>() , reinterpret_cast<>() 콤보

const double d = 20.0;


long *pL = (long *)&d;                                                                  // reinterpret_cast( const_cast(&d) ) 와 동등

long *pL2 = reinterpret_cast( const_cast(&d) );   // (long *) 와 동등


long &rL = (long &)d;                                                                   //

long &rL2 = reinterpret_cast( const_cast(d) );    // (long &) 와 동등


B1 *pB1 = (B1 *)(new D1()); // static_cast(new D1())와 동등, 업캐스팅! B1과 D1은 상속관계

B2 *pB2 = (B2 *)(new D1()); // reinterpret_cast(new D1())와 동등, 업캐스팅! B2와 D1은 상속관계가 아님


D1 *pD12 = (D1 *)(pB1);      // static_cast(pB1)? reinterpret_cast(PB2) ? 컴파일러는 영리하게 static_cast<>() 선택

                                       // this 포인터 계산 (내부 바이너리 구조 변경)

D2 *pD2 = (D2 *)(pB1);       // static_cast(pB1)? reinterpret_cast(PB2) ? 아마도? static_cast<>()


// const_cast<>(), static_cast<>() 콤보

const D1 cD1;


B1 *pB11 = (B1 *)&cD1;                                                     // implicit_cast(const_cast(&cD) ) 와 동등

B1 *pB12 = implicit_cast( const_cast(&cD1) );  // (B1 *) 와 동등


const B1 *pBC11 = (const B1 *)&cD1;                                 //  implicit_cast(&cD) 와 동등

const B1 *pBC12 = implicit_cast(&cD1);            //


D1 *pD11 = (D1 *)pBC11;                                                  // static_cast( const_cast(pBC11) ) 과 동등

D1 *pD12 = static_cast( const_cast(pBC11) ); // (D1 *)와 동등


C 형변환 연산자()를 사용하게 되면 컴파일러는 "우선 const_cast<>()를 적용해야 하는지 결정하고나서 static_cast<>()를 적용할 수 있는지 조사해보고 적용할 수 있으면 static_cast<>()를 적용, 아니면 reinterpret_cast<>()를 적용한다" 라고 생각하면 될 것 같습니다.


따라서 다음과 같이 간략하지만 일부러 꼬아놓은 C++ 문장은 컴파일러가 의외로 많은 함축적인(!) 정해진 작업을 수행 하고 결국 실행 시 오류가 날  수 밖에 없게 됩니다.


const D1 cD1;

D2 *pD21 = (D2 *)(const B1 *)&cD1;


위의 문장은 아마도 아래와 같이 컴파일러가 확장하겠죠.


D2 *pD21 = static_cast( const_cast( implicit_cast(&cD1) ) );


그렇다면 다음 문장은 어떻게? ^^;


D2 &rD21 = (D2 &)cD1;


최근 프로그래밍 추세에 있어서 코드의 가독성(readablity)과 관리용이성(maintenance)은 가장 중요한 요소입니다. 그러한 점에서 상

황에 따라서 제각기 다르게 해석되어질 수 있는 C 형변환 연산자 () 의 사용은 바람직하지 못하다고 할 수 있습니다. 물론 많은 C++ 프로그래머

들이 아직도 C 형변환 연산자 ()를 사용하고 있으며 그 이유는 의외로 간단하다고 생각 합니다.


"C++ 형변환 연산자는 키보드 치기가 너무 힘들어! --;;;"




P.S. 형변환 연산자에 대해 쓰는 김에 마져 덧붙입니다.


간혹 union_cast<>() (또는 이 링크의 글에서는 horrible_cast<>() 라고 합니다) 라는 천하무적 형변환 연산자를 만들어 쓰기도 합니다. 아래와 같이 템플릿을 이용하여 정의되는데 정말로 꼭 필요한 상황이 아니면 절대로 사용하지 말아야 할 연산자입니다. 그냥 이렇게도 사용하는구나 정도만 알고 있으면 될 듯 싶습니다.


template

union horrible_union

{

  TO out;

  FROM in;

};


template

inlineTO horrible_cast(const FROM &x)

{

    horrible_union u;

    // 변환되는 형과 변환하고자 하는 형의 크기가 다르면 컴파일러가 에러를 발생 시키게 함

    typedef int ERROR_CantUseHorrible_cast[sizeof(FROM) == sizeof(u) && sizeof(FROM) == sizeof(TO) ? 1 : -1];

    u.in = x;

    return u.out;

}


union을 이용하여 단순 무식하게 바이너리 비트 복사가 일어나는 것과 같은 형변환 효과를 보여줍니다. 이런 의미에서 union_cast<>() 또는 horrible_cast<>()는  아무런 제약이 없는 (reinterpret_cast<>() 의 경우 부동소수형(float, double)으로의 형변환은 불가능) 진정한 reinterpret_cast 연산자라고 할 수 있습니다. 단 이렇게 union 을 이용하여 형변환을 하는 것은 C++의 형검사(type check) 체계를 뒤흔드는 일일 뿐만 아니라 C 표준에서 조차 정의되지 않은 행동(undefined behavior)으로 정의되어 있다고 합니다. 변환하고자 하는 형과 변환되어지는 형 그리고 union 의 크기를 비교하는 오류 검사를 컴파일 시 수행하기 때문에 그나마(!) 조금 안전하게 사용할 수 있다고는 하지만 여전히 reinterpret_cast<>() 보다, 심지어 C 형변환 연산자 () 보다 백배 천배는 나쁜 녀석(!!!EVIL!!!)입니다.

'Computing' 카테고리의 다른 글

SATA2 하드디스크의 NCQ 기능 사용하기  (0) 2007.10.16
Microsoft Robotics Studio에서 XInputController  (0) 2007.10.10
Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
samba에서 user  (0) 2007.05.17

Ubiquitous 연구 동향

http://kidbs.itfind.or.kr/ITWRD/ITWorld/et3-11.htm

안티스파이웨어 랭킹 리뷰

'Computing' 카테고리의 다른 글

C++ 형변환 연산자 (cast operators), C 형변환 연산자 ()  (0) 2007.08.27
Ubiquitous 연구 동향  (0) 2007.05.30
samba에서 user  (0) 2007.05.17
zeroboard 설치  (0) 2007.05.11
Ubuntu 7.04 server 설치중...  (0) 2007.05.11

samba에서 user

samba에서 user를 따로 추가해야지 쓸수있구만..

smbpasswd -a dhlee

-a가 꼭 필요하단다 -_-;;;
system의 /etc/passwd와 연결시킬수도 있을것같은데..
잘 모르겠구만..

'Computing' 카테고리의 다른 글

Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
zeroboard 설치  (0) 2007.05.11
Ubuntu 7.04 server 설치중...  (0) 2007.05.11
Elliptic curve cryptography (ECC)  (0) 2007.05.10

zeroboard 설치

table create sql에 문제가 있다니.. -_-;;
schema.sql의 139라인을
> no int(11) not null auto_increment primary key,
이렇게 고쳐야 한덴다..
왠지 허무하다...


문제를 하나 더 찾았다..
기존 zeroboard에서 데이타를 backup받기 위해서
관리자 페이지에서 "DB백업" 항목을 이용했는데...
여기에 버그가 있는것같다.
덤프받은 sql에는 table이름이 전부 소문자로 들어가 있다.
그런데 실제 zeroboard에서는 대소문자가 섞여서 사용되고 있고...
덕분에 table을 찾지 못한단다.. -_-;;;;
역시 허무하다... (그런데 문제는 이건 해결이 쉽지않다. 킁)

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /home/www/wwwroot/bbs/_head.php on line 111

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/www/wwwroot/bbs/zboard.php on line 29

이런 메세지를 토해놓고 있다... 쩝...
아무래도 DB백업을 mysql을 통해서 직접 받던지..
아니면 DB백업을 수행하는 php소스를 수정해야될듯하다... 음냐..

'Computing' 카테고리의 다른 글

Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
samba에서 user  (0) 2007.05.17
Ubuntu 7.04 server 설치중...  (0) 2007.05.11
Elliptic curve cryptography (ECC)  (0) 2007.05.10

Ubuntu 7.04 server 설치중...

Ubuntu 7.04 server 설치를 해보고 있다.
이거 완전 골치아픔이다. 킁

한글로 깔았더니만 apt-get의 출력이 이상하게 깨지더구만...
그래서 영문으로 깔았더니 파일이름과 내용들이 또 다 깨지고...
결국 locale이 en_US.UTF-8 로 되어있기때문에 나타난 현상이었다.

locale에 관여하는 configuration file은 아래의 두가지...
/etc/environment
/etc/default/locale

막상 ko_KR.UTF-8 로 바꿔놓으니까... 설치하려는 파일들
(제로보드, 기존 web 서버에서 backup받은것들) 이 전부 EUC-KR인거 같다. -_-;;;

이를 어쩌면 좋단말이냐.. EUC-KR로 결정을 해야되나..
왕 고민중.......

'Computing' 카테고리의 다른 글

Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
samba에서 user  (0) 2007.05.17
zeroboard 설치  (0) 2007.05.11
Elliptic curve cryptography (ECC)  (0) 2007.05.10

Elliptic curve cryptography (ECC)

요즘에 알바를 살짝 하고 있는데.. 이게 좀 골때리는 내용이다..
Elliptic curve cryptography (ECC) 라고 하는 분야인데.. 암호학 쪽이다.

최근 들어서 뜨고 있는 알고리즘같은데... 내용이 꽤 어렵다.
private key를 알면 public key를 생성할 수 있고
public key로는 private key를 쉽게 알아낼 수 없다. (이게 핵심)

이 ECC는 수학적인 graph 모델을 사용해서 양쪽 key를 생성할수
있도록 하고 있다.  그러나 RSA와는 다르게 message를 encryption하는
방식은 제공하고 있지 않다. (거의 확실한듯...)

그래프에서 base point가 존재하고 private point
(정확하게는 point가 아니라 distance정도..)를 찍으면 public point를
계산해낼수있다.  하지만 public point와 base point만으로는 private point를
역으로 계산해내기 어렵다. (불가능에 가깝다고 봐야겠지...)

뭐 여러모로 쓸모있는 알고리즘이 될듯 싶지만... 하드웨어로 구현하기엔
만만치 않아보인다. ㅎㅎㅎ

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

Digital Signatures
    * ECDSA: Elliptic Curve Digital Signature Algorithm
    * ECPVS: Elliptic Curve Pintsov Vanstone Signatures
    * ECNR: Elliptic Curve Nyberg Rueppel

Key Agreement
    * ECMQV: Elliptic Curve Menezes-Qu-Vanstone
    * ECDH: Elliptic Curve Diffie-Hellman

Encryption
    * ECIES: Elliptic Curve Integrated Encryption Standard


'Computing' 카테고리의 다른 글

Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
samba에서 user  (0) 2007.05.17
zeroboard 설치  (0) 2007.05.11
Ubuntu 7.04 server 설치중...  (0) 2007.05.11
prev 1 2 next