RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
'분류 전체보기'에 해당되는 글 379
2007/10/18  zlib 설치  
2007/10/16  [MFC] header & library 설명  
2007/10/16  RPC(Remote Procedure Call)  
2007/10/05  헌팅 노하우  (9)
2007/10/01  OSI 7 Layer 계층  
2007/09/27  오라클 limit  
2007/09/25  ORACLE 인덱스(INDEX)  
2007/08/19  변한건 ....  (1)
Linux  2007/10/18 13:49
이것때문에 다시 리눅스 밀지 마시길

zlib 설치
Download : http://www.gzip.org/zlib/

[root:/usr2/src] tar xvfz zlib-1.1.4.tar.gz
[root:/usr2/src] mv  zlib-1.1.4 /usr/local/zlib
[root:/usr2/src] cd /usr/local/zlib
[root:/usr/local/zlib] ./configure -s // libz.so 관련모듈생성
[root:/usr/local/zlib] make
[root:/usr/local/zlib] ./configure // libz.a 생성
[root:/usr/local/zlib] make test
[root:/usr/local/zlib] make install
[root:/usr/local/zlib] ls -al libz.so*
lrwxrwxrwx    1 root     root           13 Jul  5 08:01 libz.so -> libz.so.1.1.4
lrwxrwxrwx    1 root     root           13 Jul  5 08:01 libz.so.1 -> libz.so.1.1.4
-rwxr-xr-x    1 root     root        60880 Jul  5 08:01 libz.so.1.1.4
[root:/usr/local/zlib] cp libz.so* /usr/local/lib
[root:/usr/local/zlib] cd /usr/local/lib
[root:/usr/local/lib] ls
libz.a  libz.so  libz.so.1  libz.so.1.1.4
[root:/usr/local/lib] rm -rf libz.so
[root:/usr/local/lib] rm -rf libz.so.1
[root:/usr/local/lib] ln -s libz.so.1.1.4 libz.so
[root:/usr/local/lib] ln -s libz.so.1.1.4 libz.so.1
[root:/usr/local/lib] vi /etc/ld.so.conf
/usr/local/lib // 구문 추가 ( rpm 설치시 lib 는 /usr/lib 이기에 )
[root:/usr/local/lib] ldconfig
2007/10/18 13:49 2007/10/18 13:49
이 글에는 트랙백을 보낼 수 없습니다

다음글은 하이텔  MFC소모임의 시삽이신 권정혁님의 글을 정혁님의 허락하에
다음과 같이 기재합니다. 허락해주신 정혁님께 감사드립니다.
****************************************************************************
이 글은 Mike Blaszczak 의 책 "Professional MFC" 의 Appendix D 에 들어있는
내용을 번역한 글입니다. 제 허락없이는 다른 어떤게시판에도 옮기실수 없습니
다. 물론 글의 원 소유자는 Mike 입니다.

                                            MFC&T 사용자 모임 시삽 권정혁

============================================================================
MFC 헤더와 라이브러리 설명 (The Foundation Classes Headers and Libraries) #1

1. Header Files

아래 테이블은 모든 MFC 헤더 파일들과 사용 목적, 그리고 어떤 파일전에 어떤
파일들이 Include 될수 있는지에 대해 나와있습니다. 거의 모든 헤더들이 다른
헤더들에 의해 Include 된다는 것을 주의하십시오.
당신의 코드에서 직접 Include 하는것은 약 4-5개 정도입니다.

----------------------------------------------------------------------------
헤더 (Header)설명
----------------------------------------------------------------------------

Afx.h       Windows 를 사용(?)하지 않는 MFC 프로그램을 작성할때 Include
            하는 Main Header 파일입니다. 콘솔용 MFC 응용프로그램을 작성할때
            이 헤더만 있으면 됩니다. 이것은 Windows 외에서 사용될수 있는
            콜렉션 클래스와 Application Framework 클래스들를 포함한 모든
            클래스를 선언합니다. 콘솔용 프로그램을 작성한다면 다른 MFC 헤더
            들을 Include 하기전에 이 파일을 Include 하여야 됩니다.
            만약 윈도우용 프로그램을 작성한다면, 이 파일대신 Afxwin.h 를
            사용하십시오.

Afxcmn.h    이 파일은 윈도우의 공용 컨트롤(Common Control)에 대한 Definition
            들을 가지고 있습니다. Afxwin.h 를 Include하지 않았다면 이 파일을
            사용할수 없습니다.
           
Afxcoll.h   이 파일은 MFC 컨테이너 클래스들에 대한 Declaration(선언)을
            가지고 있습니다. 이 파일은 Afx.h 의 내용에 의존합니다.
            Afxcoll.h 는 CObject-style 과 type-safe 콜렉션에 대한
            Definition 을 포함하고 있습니다. 템플릿 콜렉션 클래스들은
            Afxtempl.h 안에 있습니다.

Afxctl.h    이 파일은 ActiveX 컨트롤을 작성하는데 필요한 클래스와 선언들을
            가지고 있습니다. 컨트롤 작성 프로젝트에서는 이 파일을 Afx.h 나
            Afxwin.h 대신에 Include 해야 합니다.

Afxcview.h  이 파일은 Tree 와 List 공용 컨트롤을 기초로 하는 CView 파생
            클래스들에 대한 Definition 들을 가지고 있습니다. 이 파일은 좀더
            작고 효율적인 링킹을 위해 Afxwin.h 와 Afxcmn.h 파일로부터
            분리되었으며, 이것은 좀더 작고 빠른 실행화일을 생성할수 있도록
            해줍니다. 만약 CTreeView 나 CListView를 사용한다면 Afxwin.h 파일
            다음에 이것을 Include 하여야 합니다.
           
Afxdao.h    이 파일은 DAO 에 기반한 데이터 억세스를 지원하기 위한 클래스들
            (CDaoDatabase 와 CDaoRecordset 같은)을 담고있습니다. 이 헤더가
            필요하다면 Afxwin.h 와 Afxdisp.h 다음에 Include 하여야 합니다.
           
Afxdb.h     이 파일은 ODBC 에 기반한 데이타 베이스 프로그램을 개발하기 위한
            클래스들(CDatabase 와 CRecordset 같은)을 담고 있습니다.
            이 파일은 또한  "RFX_*" 와 같은 [레코드 필드 교환 명령]들 같은
            데이터베이스 프로그램 개발에 필요한 전역 함수들을 정의하고
            있습니다. 데이터베이스 클래스를 사용하려면 먼저 Afx.h 와
            Afxwin.h 를 Include 한다음 이 파일을 Include 하여야 합니다.

Afxdb_.h    이 파일은 ODBC 와 DAO 에 공통적인 definition 들과 클래스들을
            포함하고 있습니다. 이 파일은 전혀 Include 할 필요가 없습니다.
            이것은 Afxdb.h 나 Afxdao.h 를 Include 할때 따라오게 됩니다.
           
Afxdd_.h    이 파일은 다이알로그 데이타 교환(DDX) 함수들에 대한 선언들을
            포함하고 있습니다. 끝이 _ 로 끝나는 다른 화일들과 마찬가지로,
            이 파일도 직접 Include 할 필요가 없습니다.
            이것은 Afxwin.h 에 의해 포함됩니다.

Afxdisp.h   이 파일은 COM dispatch인터페이스에 대한 선언과 정의들을 포함하고
            있윱求?이것은 CCmdTarget에 의해 처리되는 Automation을 작성하기
            위한 모든 확장들과 MFC 가 COM 프로그램을 쉽게 하기위해 제공하는
            모든 자료형들, Wrapper 클래스들을 포함하고 있습니다.
            COM 을 사용할때만 이 파일을 Include 하십시오. 만약 그렇지 않으면
            필요치 않은 런타임DLL들에 연결되게 되며,이것은 작성된 프로그램의
            시작을 느리게 할것입니다. 이 파일은 Afxwin.h 뒤에 Include 되어야
            합니다. 만약 Afxcmn.h 를 사용하고 있고, OLE 클래스들을 사용할
            필요가 있다면 이 파일을 Include하십시오

Afxdlgs.h   MFC 의 확장 다이알로그 클래스들이 이 파일에 선언되어 있습니다.
            이 클래스들은 CPropertySheet와 CPropertyPage를 포함하여 윈도우의
            공통 대화상자(Common Dialog)에 대한 MFC Wrapper 들입니다.
            이 파일은 Afxext.h 에 의해 포함되게 됩니다.
           
Afxdllx.h   이 파일은 MFC 확장DLL을 작성할때 소스 모듈들에 포함되는 소스코드
            를 포함하고 있습니다.(ExtRawDllMain)
           
Afxdll_.h   이 파일은 MFC 가 확장 DLL 에 대한 정보를 관리하도록 도와주는
            클래스들을 포함하고 있습니다.
            이 파일은 당신의 프로그램이 _AFXDLL Precompiler플래그를 사용하여
            작성될때 Afxwin.h 에 의해 포함됩니다.

Afxext.h    Afxext.h 화일은 '확장' MFC클래스들을 선언합니다.
            이것은 CStatusBar와 CToolBar같은 진보된 User-Interface클래스들을
            포함하고 있습니다. 이 클래스들을 사용한다면, 먼저 Afxwin.h 를
            포함하십시오.

Afxinet.h   CHttpConnection 같은 클래스들을 선언합니다. 이 파일에 선언된
            클래스들을 인터넷 클라이언트 프로그램을 작성가능하게 합니다.

Afxisapi.h  ISAPI 인터페이스를 사용하는 인터넷 서버 프로그램 작성용 클래스들
            선언입니다.

Afxmsg_.h   이 파일은 간접적으로 Afxwin.h에 의해 참조됩니다. 따로 Include 할
            필요는 없습니다. 메시지맵 항목들에 대한 정의를 포함하고 있습니다

Afxmt.h     Multithreaded Application 을 위한 동기화(Synchronization) 객체를
            포함하고 있습니다. 이 클래스들은 Console 프로그램에서도 사용이
            가능하며, 먼저 Afx.h 를 Include 해야 합니다.

Afxodlgs.h  이 파일은 MFC 에서의 OLE 대화상자 구현을 위한 클래스 선언들을
            포함하고 있습니다. 만약 이 대화상자들 사용하거나 서브클래싱 할
            경우에는 이 파일을 직접 Include 하여야 합니다.
            물론 먼저 Afxwin.h 가 Include 되어야 합니다.

Afxole.h    이 파일은 OLE를 위한 핵심 클래스들을 선언하고 있습니다.
            이 클래스들은 COleDocument 기반의 클래스들과 OLE 아이템들 그리고
            그들과 같이 사용되는 Drag-and-Drop 지원을 포함합니다. 프로그램이
            OLE 를 사용한다면 Afxwin.h 다음에 이 파일을 포함해야 합니다.

Afxplex_.h  이 파일은 MFC 에서 CObject기반의 콜렉션 클래스들 구현에 사용되는
            CPlex 클래스를 구현하고 있습니다.

Afxpriv.h   이 파일은 MFC 구현에 필요한 내부적인(사적인) 것을을 포함하고
            있습니다. 만약 안을 들여다본다면, 당신의 일을 도와줄수 있는
            깔끔한 자료구조나 클래스들을 찾을수 있을겁니다.
            하지만, 조심해서 사용하십시오. 이 파일에 있는 것들은 MFC 버젼이
            바뀌면 예고없이 바뀔수도 있습니다.
            이런것을 인지한 다음에 직접 Include 하여 사용하십시오.

Afxres.h    이 파일은 MFC 프로그램을 위한 Resource Script(.rc 파일) 에 의해
            사용됩니다.(Include 됩니다.)
            이 파일은 Afxwin.h 에 의해 간접적으로 참조됩니다.
            이 파일은 거의 직접 참조될 필요가 없습니다. 이 파일은 미리
            정의된 모든 MFC 리소스들에 대한 Preprocessor Symbol Definition
            들을 포함합니다.

Afxrich.h   이 파일은 CRichEditCtrl 과 관련된 약간의 클래스들에 대한 정의를
            포함하고 있습니다. 만약 Rich Edit컨트롤을 사용한다면 Afxcmn.h와
            Afxwin.h 다음에 이 파일을 Include 해야 합니다. 또한 Afxole.h
            파일도 Include 되어야 합니다.Rich Edit 컨트롤은 매우 강력합니다
            이것은 완벽하게 OLE 를 지원합니다.

Afxsock.h   CSocket 과 CAsyncSocket 클래스에 대한 정의를 포함하고 있습니다.
            이 클래스들은 Windows Sockets API(네트워크 기반의 통신 API)를
            감쌉니다.(Wrapping)

Afxstat_.h  이 파일은 동작중인 프로그램에 대해 MFC 가 관리하는 상태정보
            저장용 구조체들을 정의합니다. 이 상태정보는 MFC 에 의해
            사용되며 프로그램이 어떻게 동작해야 할지를 알수 있게 합니다.
            이 파일은 직접적으로는 참조되지 않으며, Afx.h에 의해 Include
            됩니다.

Afxtempl.h  이 파일은 MFC 콜렉션 클래스들에 대한 템플릿 기반의 구현들을
            포함하고 있습니다. Afx.h 뒤에 Include 되어야 합니다.  

Afxtls_.h   MFC 가 각 어플리케이션별 또는 쓰레드별 상태정보를 관리하기 위한
            Thread-Local Storage 매크로 들을 포함합니다. 이 매크로들은
            Afxstat_.h 에 있는 많은 구조체들에 의해 사용되며, 이 파일은
            직접적으로 참조되지 않습니다. Afx.h 에 의해 참조됩니다.

Afxver_.h   이 파일은 MFC 프로그램이 만들어질때(Build) 여러가지 설정을 위해
            사용되는 많은 Preprocessor macro 들을 가지고 있는 중요한 파일
            입니다. 당신이 MFC 어플리케이션을 Build 할때 이 헤더는 당신의
            프로그램이 정확하게 MFC 에 링크되는지를 확인하는 약간의 설정도
            추가하게 됩니다. 이 파일은 전혀 직접 참조할 필요가 없으며,
            실제로 이 파일을 읽어볼 필요도 없습니다. 이 파일은 아주
            저수준(Low-Level)의 매크로와 내부구현들로 가득차 있기때문입니다.

Afxv_cfg.h  이 파일은 한가지의 일을 합니다: 이것은 _AFX_PORTABLE 이란
            플래그에 의해 동작됩니다. 만약 당신이 MFC 를 Build 하기위해
            제작되지 않은 컴파일러(Watcom 이나 Symantec 등)를 사용한다면
            Preprocessor 심볼인 _CUSTOM 을 정의하여 이 파일이 Include되도록
            해야 합니다. 이 파일은 절대로 어플리케이션에 의해 직접적으로
            참조되지 않으면, 일반적인 상황에서는 MFC 에 의해 전혀 사용되지
            않습니다.

Afxv_cpu.h  Afxver_.h 에 의해 참조되며,이 파일은 Macintosh,Power PC,MIPS,
            Alpha용 MFC 에 대한 약간의 설정을 합니다. 이 파일은 절대로
            어플리케이션에 의해 직접적으로 참조되지 않습니다.

Afxv_dll.h  이 파일은 DLL 기반의 MFC Build 에 대한 설정을 하기위해
            사용됩니다. 이 파일은 DLL Build에 대한 많은 특수심볼을 정의하여
            DLL 의 Segment Layout 을 최적으로 만듭니다. 이것은 Afxver_.h 에
            의해 참조되며 절대로 어플리케이션에 의해 직접적으로 참조되지
            않습니다.

Afxv_mac.h  이 파일은 Macintosh용 MFC 에 대한 여분의 설정변경을 가지고
            있습니다. 이것은 Afxver_.h에 의해 참조되며 절대로 어플리케이션에
            의해 직접적으로 참조되지 않습니다.

Afxv_w32.h  이 파일은 Win32 용 MFC 를 설정합니다. 이것은 항상 Include 되며,
            이것은 MFC 가 Win32 의 변형들(Win32s,Win32c..) 상에서 동작될때도
            마찬가지입니다. 이 파일은 시스템관련, 표준 C, C++ Include 파일을
            참조하게됩니다.이 파일이 Windows.h와 그 친구들을 불러오는
            파일입니다. (또한 Tchar.h 나 String.h 같은 헤더도 포함됩니다.)

Afxwin.h    이 파일이 윈도우 상에서 동작하는 MFC 어플리케이션에 대한 주 헤더
            (Primary Header) 파일입니다. Windows 용 프로그램을 작성한다면
            Afx.h 후에 이 파일을 Include 하십시오. 콘솔 프로그램을 만든다면
            이 파일을 사용하지 마십시요.
            이 파일은 CWnd 와 CWnd의 파생 클래스와 같은 기본클래스들을 정의
            합니다.

Winres.h    이 파일은 MFC 어플리케이션에 의해 사용되는 Resource Identifier
            들에 대한 부분집합을 정의합니다. 이것은 Afxres.h에 의해 참조되며
            Windows의 헤더가 일반적으로 정의하는 것들의 부분집합을
            제공합니다. MFC 어플리케이션에서 직접 참조되지 않습니다.

다음글은 하이텔  MFC소모임의 시삽이신 권정혁님의 글을 정혁님의 허락하에
다음과 같이 기재합니다. 허락해주신 정혁님께 감사드립니다.
****************************************************************************

이 글은 Mike Blaszczak 의 책 "Professional MFC" 의 Appendix D 에 들어있는
내용을 번역한 글입니다. 제 허락없이는 다른 어떤게시판에도 옮기실수 없습니
다. 물론 글의 원 소유자는 Mike 입니다.

                                            MFC&T 사용자 모임 시삽 권정혁

============================================================================
MFC 헤더와 라이브러리 설명 (The Foundation Classes Headers and Libraries) #2

2. 런타임 라이브러리 (Run-time Libraries)

이 테이블은 Visual C++ 과 함께 제공되는 라이브러리와 Pre-Compiled Object 들의
기능에 대한 짧은 설명을 보여줍니다.

------------------------------------------------------------------------------
런타임 라이브러리 (Run-time Libraries)
------------------------------------------------------------------------------

파일설명

Advapi32.lib  레지스트리나 보안 관련 API 같은 진보된 API 서비스 들에 대한
              임포트 라이브러리 입니다. 이 임포트 라이브러리와 링크하는 것은
              당신의 프로그램에서 Advapi32.dll에 포함된 함수들을 사용가능하게
              합니다.

Atl.lib       MS의 Active Template Library에 대한 라이브러리입니다.

Binmode.obj   이 모듈과 링크하면 C 런타임 라이브러리에 의해 오픈되는 화일들이
              기본적으로 Binary 모드로 열리도록 만듭니다.

Cap.lib       Call Attributed Profiler 에 대한 인터페이스 입니다.
              이 툴은 함수 호출 패턴(Function Call Patterns)을 분석함으로써
              Win32 어플리케이션을 튜닝하게 해줍니다.

Chkstk.obj    런타임용 Stak-Depth 체킹 모듈입니다.
              이 모듈은 모든 함수 호출전에 스택의 크기(Depth)를 체크함으로써
              Stack Overflow 가 났는지 체크하는 것을 도와줍니다.
              Windows NT 에서는 프로그램의 스택 세그먼트를 조심스레 체크하며,
              스택 오버플로우가 난다면 프로그램을 깨끗히 종료시켜주므로
              이 파일은 거의 필요가 없습니다.

Comctl32.lib  윈도우 공용 컨트롤(Windows common controls)에 대한 라이브러리
              입니다.

Comdlg32.lib  윈도우 공용 대화상자(Windows common dialogs)에 대한 라이브러리
              입니다. 이 라이브러리는 표준 화일오픈,화일저장,폰트선택,프린트
              ,컬러 선택 다이얼로그에 대한 인터페이스를 제공합니다.

Commode.obj   전역적인 File Commit Flag 값을 Commit 으로 설정합니다.
              이 파일과 링크하는것은 오픈되는 모든화일이 기본적으로 Commit
              모드에서 열리도록 합니다.

Compmgr.lib   컴포넌트에대한 임포트 라이브러리입니다.

Ctl3d32.lib   3차원(Three-D) 컨트롤에대한 지원 라이브러리입니다.
              이 라이브러리는 다이알로그와 컨트롤이 3차원으로 보이도록 합니다.
              이 파일은 거의 안쓰입니다. 단지 이전버젼과의 호환을 위해
              제공됩니다.

Ctl3d32s.lib  Win32s 용 프로그램에대한 Ctl3d 라이브러리 입니다.

D3drm.lib     Direct3D 렌더링 모델(Rendering Model) API에 대한
              라이브러리입니다.

Daouuid.lib   DAO 객체들에 대한 UUID 값을 가지고 있는 라이브러리입니다.

Ddraw.lib     DirectDraw API용 라이브러리입니다.

Dflayout.lib  Compound Document File(복합문서파일)에 대한 저장소 관리
              (Storage Management)를 하는 OLE 함수들에 대한 임포트
              라이브러리입니다.

Dlcapi.lib    DLC 3270 연결을 위한 라이브러리 입니다.

Dplay.lib     DirectPlay API용 라이브러리 입니다.

Dsound.lib    DirectSound API용 라이브러리입니다.

Fp10.obj      이 모듈과 링크하는것은 프로그램이 기본적으로 53비트 대신 64비트
              부동소수점(Floating-Point Precision) 형식으로 알고리즘을
              사용하게 합니다.

Gdi32.lib     Windows GDI 임포트 라이브러리 입니다. 이 라이브러리와 링크하는
              것은 프로그램이 Windows 의 Graphic Device Interface 에 있는
              SelectObject(),CreateFont(),LineTo() 와 같은 루틴을 호출하여
              디스플레이나 프린터에 그리기를 수행할수 있도록 합니다.

Glaux.lib     OpenGL 보조 함수 라이브러리 입니다. 거의 모든 프로그램에서
              사용되지 않으나, 이것은 OpenGL의 핵심(Core) 라이브러리의 기능을
              향상시키도록 합니다. Opengl32.lib도 참조하십시오.

Glu32.lib     OpenGL 그래픽의 핵심 함수 라이브러리 입니다.
              Opengl32.lib도 참조하십시오.

Hlink.lib     IHlink 와 관련 인터페이스 지원용 라이브러리 입니다.
              이 인터페이스들은 ActiveX 객체가 일반적인 하이퍼링크 스타일
              (Hyperlink-Style)의 이동을 구현하는것을 도와줍니다.

Imagehlp.lib  디버거 같은 시스템 툴들이 다른 프로세스를 관리하고 디버그
              정보를 추출하도록 하는 루틴이 들어있는 라이브러리 입니다.

Imm32.lib     Input Method Editor(IME)의 사용에 라이브러리입니다.
              IME는 조그만 팝업윈도우창으로 보이며,다른나라 글자를 선택하도록
              해줍니다. (한글윈도우 사용자는 다들 아시죠..? )

Kernel32.lib  Windows Kernel 의 임포트 라이브러리입니다. 이 라이브러리와
              링크함으로써 Windows kernel 안에 들어있는 루틴의 호출이 가능해
              집니다. Windows Kernel 에는 CreateSemaphore() 나 GlobalAlloc()
              같은 함수들이 포함되어 있습니다.

Largeint.lib  수학계산용 Large Interger지원 라이브러리입니다. 이 라이브러리는
              단지 호환목적으로 제공됩니다. Visual C++ 의 컴파일러는
              기본적으로 64Bit Integer 를 지원합니다.

Libc.lib      표준 C Runtime 라이브러리입니다. 이 라이브러리는 sprintf() 나
              strcpy() 같은 함수들이 포함되며,프로그램에 정적으로 링크됩니다.
              이것은 멀티쓰레드나 재진입(re-entrant) 프로그램에는 안전하지
              못합니다.

Libcd.lib     표준 C Runtime 라이브러리의 Debug 버젼입니다. Debug 빌드에선
              Libc.lib 대신 이것을 사용합니다. 이것은 프로그램에 정적으로
              링크됩니다.

Libci.lib     표준 C 라이브러리입니다.이 라이브러리는 Libc.lib 와 비슷하지만,
              이것은 이전 버젼의 Visual C++ 에서 제공된 표준 라이브러리에서
              지원된 표준 iostream 라이브러리와의 호환성을 제공합니다.
              (iostream이 구형이라는 얘기죠..) 이것은 프로그램에 정적으로
              링크됩니다.

Libcid.lib    구형 iostream 버젼이 포함된 표준 C 라이브러리의 Debug버젼입니다.
              역시 프로그램에 정적으로 링크됩니다.

Libcimt.lib   구형 iostream 버젼이 포함된 표준 C 라이브러리의 멀티쓰레드에
              안전한 버젼입니다. 역시 프로그램에 정적으로 링크됩니다.

Libcimtd.lib  구형 iostream 버젼이 포함된 표준 C 라이브러리의 멀티쓰레드버젼의
              Debug 빌드입니다. 역시 프로그램에 정적으로 링크됩니다.

Libcmt.lib    멀티쓰레드 프로그램이나 재진입 프로그램에서도 사용이 안전한
              sprintf() 나 strcpy() 같은 함수들이 포함된 C 런타임 라이브러리의
              멀티쓰레드 버젼입니다. 역시 프로그램에 정적으로 링크됩니다.

Libcmtd.lib   바로위의 Libcmt.lib의 디버그 버젼입니다.
              역시 프로그램에 정적으로 링크됩니다.

Libcp.lib     표준 C++ 런타임 라이브러리 입니다. 이것은 호출하는 프로그램에
              정적으로 링크되며, 멀티쓰레드나 재진입 프로그램에 안전하지
              못합니다.

Libcpd.lib    표준 C++ 런타임 라이브러리의 Debug 버젼입니다.
              역시 프로그램에 정적으로 링크됩니다.

Limcpmt.lib   표준 C++ 런타임 라이브러리의 멀티쓰레드 버젼입니다.
              역시 프로그램에 정적으로 링크됩니다.

Libcpmtd.lib  멀티쓰레드 C++ 표준 라이브러리의 디버그 버젼입니다.
              역시 프로그램에 정적으로 링크됩니다.

Loadperf.lib  이 임포트 라이브러리는 Performance Counter 에 관련된 레지스트리
              값들의 초기화를 지원하는 루틴들을 포함합니다.
              이 라이브러리는 보통 인스톨 프로그램들에 사용됩니다.

Lz32.lib      Lempel-Ziv압축해제 루틴 라이브러리입니다. 보통 인스톨 프로그램에
              의해서 사용됩니다. 이 라이브러리는 압축루틴이 없으며,
              단지 압축해제루틴만 들어있습니다.

Mapi32.lib    Microsoft Mail API 라이브러리 입니다..

Mfcapwz.lib   Custom Wizard의 개발을 가능하게 해주는 클래스와 함수들이 포함된
              라이브러리입니다.

Mfcclwz.lib   Custom Wizard의 개발을 가능하게 해주는 클래스와 함수들이 포함된
              라이브러리입니다.

Mfcuia32.lib  OLE 공통 사용자 인터페이스(Common User Interface)에 대한 MFC 의
              구현부분이 들어있습니다. Oledlg.lib 와 비슷하지만 Unicode 대신
              ANSI 인터페이스를 지원합니다.

Mgmtapi.lib   SNMP(Simple Network Management Protocol) Management API입니다.

Mpr.lib       연결관리(Connection Management)를 위한 LAN Manager 스타일의
              네트웍 API 가 들어있습니다. 이 API 들은 Windows 상에서 Connect와
              DIsconnet 를 가능하게 합니다.

Msacm32.lib   Microsoft Audio Compression Manager API(오디오 압축 관리자 API)
              입니다. 이것은 Audio Waveform 데이타를 압축하고 해제하는
              유틸리티들입니다.

Msconf.lib    Microsoft ActiveX Conferencing API 에 대한 라이브러리입니다.

Mslsp32.lib   License Service API 에 대한 임포트 라이브러리입니다.

Msvcirt.lib   구형 iostream 버젼이 포함된 표준 C 라이브러리의 DLL Build에 대한
              임포트 라이브러리 입니다. 이 라이브러리는 Libci.lib 라이브러리의
              DLL 버젼에 대한 임포트 라이브러리입니다.

Msvcirtd.lib  Mscvirt.lib 라이브러리의 디버그 버젼에 대한 임포트 라이브러리
              입니다.

Msvcprt.lib   표준 C++ 라이브러리의 DLL Build 에 대한 임포트 라이브러리입니다.
              이것은 Libcp.lib 라이브러리의 DLL 버젼에 대한 임포트 라이브러리
              입니다.

Msvcprtd.lib  Msvcprt.lib 라이브러리의 디버그 버젼에 대한 임포트 라이브러리
              입니다.

Msvcrt.lib    표준 C 라이브러리의 DLL Build 에 대한 임포트 라이브러리입니다.
              이것은 Libc.lib 라이브러리의 DLL 버젼에 대한 임포트 라이브러리
              입니다.

Msvcrtd.lib   Msvcrt.lib 라이브러리의 디버그 버젼에 대한 임포트 라이브러리
              입니다. Retail Build 에서 Msvcrt.lib 를 사용한다면 Debug Build
              에서 이것을 사용하십시오.

Mswsock.lib   Windows Sockets 2 API 에 대한 Microsoft 의 특정 확장부분
              (MS-Specific Extension)에 대한 임포트 라이브러리입니다.

Mtx.lib       Microsoft Transaction Server(MTS) 프로그래밍 인터페이스
              라이브러리입니다.

Mtxguid.lib   MTS 에 의해 지원되는 객체들의 Guid 들을 가지고 있는
              라이브러리입니다.

Nddeapi.lib   Network DDE API 입니다. DDE 스타일의 서비스를 네트웍을 통하여
              시스템간에 사용가능하도록 해줍니다.

Netapi32.lib  LAN Manager API Interface 입니다. 이 라이브러리는 MS 의 NOS
              (Network Operation System)에 의해 제공되는 저수준의 기능들을
              사용하도록 해주는 함수들을 포함하고 있습니다.

Newmode.obj   당신의 Application 이 malloc() 함수 호출에 실패했을때 new
              연산자의 에러 처리 메커니즘을 사용하도록 하여줍니다. 기본적으로,
              이것이 동작하지는 않습니다: malloc() 이 실패한다면, NULL 을
              리턴하지 예외를 발생시키지(Throw) 않습니다.              
              이 모듈과 링크하는것은 malloc() 호출 실패시 new 연산자의 에러
              처리루틴을 호출하는 것으로 C 런타임 라이브러리의 동작을
              변경합니다.

Ocx96.lib     OCX 96 스펙(Specification)에 명시된 인터페이스들에 대한
              UUID들이 포함된 라이브러리입니다.

Odbc32.lib    ODBC API 라이브러리입니다. 이 라이브러리는 데이터베이스
              응용프로그램에 대한 하부 독립적인 API 들을 제공합니다.
              이 라이브러리는 MFC 에 의해 다시 추상화 됩니다.

Odbccp32.lib  ODBC control panel applet(제어판에 등록되는 응용프로그램) 에
              관한 인터페이스가 포함된 라이브러리입니다.

Oldnames.lib  "Kernighan and Ritchie C" 와 호환되는 이름을 가진
              표준 C 런타임 라이브러리 함수들입니다. 이 라이브러리는 K&R-C의
              execv() 같은것을 ANSI-C 의 같은 함수인 _execv() 에 매핑(Mapping)
              해줍니다.

Ole32.lib     32-bit OLE 지원을 위한 Core 라이브러리입니다.

Oleaut32.lib  32-bit Automation interface에 대한 라이브러리입니다.

Oledlg.lib    OLE 공통 사용자 인터페이스(Common User Interface)에 대한 System
              Implementation입니다. OleUiEditLinks() 나 OleInsertObject()와
              같은 함수들을 포함합니다.

Olepro32.lib  OLE Property Frame API 입니다. 또한 OLE Font (IFont) 나 Picture
             (IPicture) 프로퍼티 들에 대한 구현도 포함하고 있습니다.

Opengl32.lib  OpenGL 의 Core 함수 라이브러리입니다.
              OpenGL 은 Silicon Graphics에 의해 정의되고 Microsoft 에 의해
              Win32 용으로 구현된 Graphic Rendering Language 입니다.
              Glu32.lib 와 Glaux.lib 도 참조하십시오.

Pdh.lib       Performance Data 헬퍼함수들에 대한 임포트 라이브러리 입니다.
              이 Win32 API의 부분들은 프로세스에대해 Performance Counter 들을
              작성하고,질의하고,갱신하는것을(Create,Query,Update) 도와주는
              쉬운 인터페이스들을 포함하고 있습니다.

Penwin32.lib  Pen Computing 용 Windows에 대한 확장 라이브러리입니다.

Pkpd32.lib    Pen Windows 의 커널함수들입니다.

Rasapi32.lib  클라이언트용 Remote Access Service(RAS) API 입니다.
              이 라이브러리에 있는 함수들은 모뎀이나 그 비슷한 저속회선 연결을
              통해 원격지 컴퓨터에 연결하도록 해줍니다.

Rasdlg.lib    RAS 응용프로그램에 대한 Common User Interface 요소들을 포함하고
              있는 라이브러리입니다.

Rassapi.lib   RAS 서버쪽 API 들입니다.

Rpcndr.lib    Remote Procedure Call(RPC) Helper Function API 들입니다.

Rpcns4.lib    RPC Name Service 함수들 입니다.

Rpcrt4.lib    RPC Windows run-time 함수들 입니다.

Scrnsave.lib  화면보호기(Screen saver) 에 대한 인터페이스입니다.

Setargv.obj   이 모듈과 링크하는 것은 콘솔 프로그램이 Wildcard(*,?) 를 사용한
              Command Line Parameter들을 실제 파일이름들로 지정하도록 확장하여
              줍니다. 각 파일은 main() 의 argv 인자에 들어가게 됩니다.
              윈도우에서 사용하려면 Wsetargv.obj 를 살펴보십시오.

Setupapi.lib  파일 설치와 삭제에 관련된 함수들입니다. 셋업프로그램에서
              사용됩니다.

Shell32.lib   Windows Interface Shell API 들입니다. 이 API 들은 예를 들어
              Norton Desktop for Windows와 같은 프로그램에 사용된 실행파일에서
              아이콘을 추출하거나 Command Line Parameter 를 사용해 다른
              프로그램을 실행하는등의 기능을 제공합니다.

Snmpapi.lib   Simple Network Managerment Protocol(SNMP)에 관련된 주 API 함수들
              입니다. TCP/IP 네트웍에 대해 이 프로토콜은 Gateway 나 연결될
              네트웍들을 모니터링하는데 사용됩니다. Mgmtapi.lib 와 연관되어
              있습니다.

Svrapi.lib    Inter-Server Communication 에 관한 Network API 들입니다.

Tapi32.lib    Microsoft Telephony API(TAPI) 라이브러리입니다. lineOpen() 과
              같은 telephony API 들을 구현합니다.

Th32.lib      32-bit Toolhelp 라이브러리입니다. 이 라이브러리는 Debugger 나
              저수준의 툴을 작성할때 도움을 주는 함수들을 제공합니다.
              예를들어 이 라이브러리의 루틴들을 윈도우상에서 프로세스나
              쓰레드들을 Enumerate 하게 해줍니다.

Thunk32.lib   Thunk 컴파일러의 런타임 지원 루틴들입니다.
              (Thunking 이 뭔지 아시죠?)

Url.lib       이 파일은 URL 을 Parsing 하거나 MIME 헤더를 해석하는데 사용하는
              루틴입니다. 이 라이브러리에 있는 함수들은 현재 문서화가 되어있지
              않으며, 이것은 Win32 SDK 의 이후 버젼이나 Visual C++ 의 이후버젼
              에서 더 정제되고, 무리없게 지원될것입니다.

Urlmon.lib    URL 모니커(moniker)의 런타임 지원 라이브러리에 대한 임포트
              라이브러리입니다.

User32.lib    윈도우즈의 USER.EXE 에 대한 임포트 라이브러리 입니다.
              이 라이브러리와 링크하는 것은 프로그램이 Windows 의 UI 부분을
              사용할수 있도록 해줍니다. 이 라이브러리는 CreateDialog() 나
              CreateWindow() 같은 함수를 포함합니다.

Uuid.lib      Stock(내장된) OLE 객체에 대한 표준 UUID 들입니다.

Vdmdbg.lib    이 라이브러리에 있는 함수들은 NT VDM 안에서 디버깅 하는것에
              관련된 기능들을 지원합니다.

Version.lib   GetFileVersion() 과 같은 버젼 확인 API 들입니다.

Vfw32.lib     Video for Windows API 들입니다. 이 라이브러리에 있는 함수들은
              Multimedia 비디오와 오디오를 재생,녹음,수정,저장 하는것을
              가능하게 합니다.

Webpost.lib   WebPost API 임포트 라이브러리입니다. 이 라이브러리는 ISP
              (internet Service Provider)에 의해 제공되는 웹 사이트에 사용자의
              컴퓨터에서 데이타를 올리는것이 가능하도록 도와줍니다.

Win32spl.lib  Win32 spooler API 입니다. 이 파일에 있는 루틴들은 다른 프로그램
              이나 컴퓨터들로부터 Print Spooler Status에 접근하는것을 가능하게
              해줍니다.

Wininet.lib   Windows Internet Client API 들입니다.

Winmm.lib     Windows Multimedia API 들입니다. Multimedia Device Management,
              Timer, Wave 파일, Multimedia I/O 제어함수 같은 것을 포함합니다.

Winspool.lib  The Win32 spooler API 입니다. 이 라이브러에 보이는 루틴들을
              프로그램이 프린트 하는 동안 Windows Print Spooler 의 기능을
              사용하도록 해줍니다.

Winstrm.lib   Windows NT의 TCP/IP interface들 입니다. 이 파일은 TCP/IP Routing
              함수같은 것들을 제공합니다.

Wintrust.lib  ActiveX 객체에 대한 Trust Verification(신용확인) 에 관한 API들의
              임포트 라이브러리입니다. 이것은 WinVerifyTrust() 같은 함수들을
              사용가능하도록 합니다.

Wow32.lib     이 라이브러리는 16-Bit 와 32-Bit 객체간에 핸들을 변형하도록 하는
              Generic Thunking 메커니즘에 의해 사용됩니다. 이 라이브러리는
              또한 16 Bit 프로세스에서 32-Bit 메모리를 관리하도록 하는것을
              도와줍니다.

Ws2_32.lib    Windows Sockets 2.0 API 입니다.

Wsetargv.obj  이 모듈과 링크하는 것은 Windows 프로그램이 Wildcard(*,?) 를
              사용한 Command Line Parameter 들을 실제 파일이름들로 지정하도록
              확장하여 줍니다. 각 파일은 main()의 argv 인자에 들어가게 됩니다.
              콘솔 프로그램에 사용하려면 setargv.obj 를 살펴보십시오.

Wsock32.lib   Windows Sockets APIs.

Wsock32.lib   Windows Sockets API 입니다.

Wst.lib       Working Set Tuner DLL 에 대한 인터페이스 입니다.
              Working Set Tuner DLL 은 프로그램을 조사하여 프로그램의
              Working Set 을 최소화하도록 도와줍니다.

=============================================================================

참고할점은 주 API 들과, 헤더 파일 그리고 라이브러리들의 요약이 Lib 디렉토리에
있는 Win32api.csv 에 들어있다는 것입니다. 이 파일은 Comma Separated Variable
File(*.csv) 이며,  엑셀같은 스프레드쉬트 프로그램에서 읽어들일수 있습니다.

2007/10/16 10:57 2007/10/16 10:57
이 글에는 트랙백을 보낼 수 없습니다

<<< RPC(Remote Procedure Call)의 역사 >>>

1980년대에 여러 회사들에 의하여 다양한 RPC가 구현되었다. 그들 중에는 SUN 마이크로 시스템즈의 오픈 네트워크 컴퓨팅(ONC)과 Apollo 컴퓨터의 네트워크 컴퓨팅 구조(NCA)가 있었다. 오늘날, 휴렛 팩커드의 HP-UX, IBM의 AIX, SUN 마이크로 시스템즈의 SUN OS 4.1.X, 그리고 산타크루즈 오퍼레이션의 SCO UNIX와
같은 대부분의 상업용 UNIX 시스템들은 모두 ONC 기법을 기반으로 RPC를 구현 하였다.

그러나, SUN의 Solaris 2.x 운영체제와 UNIX 시스템 V.4는 수정된 ONC 기법을 기반으로 RPC를 구현하였다. 두 기법은 매우 비슷하다. 즉, 그들은 모두 네트워크를 통하여 데이터를 전송하기 위한 외부 데이터 표현(XDR) 형식을 사용하고, RPC 응용들의 생성을 간단히 하기 위하여 rpcgen 컴파일러를 제공한다. 그러나 두 기법은 ONC 기반 RPC API들이 소켓에 기초를 하고, 반면에 시스템 V.4 RPC API들은 소켓이나 TLI를 기초로 할 수 있다는 점에서 차이가 있다.

<<< RPC 프로그래밍 인터페이스 계층 >>>

RPC 프로그래밍 인터페이스는 다양한 계층이 있다. 그들의 범위는 C 라이브러리 함수들(예를 들면, printf)을 호출하는 것과 같은 방법으로 사용자들이 시스템이 제공하는 RPC 함수들을 호출하는 최상위 계층으로부터, RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층까지 있다. 이 다양한 프로그래밍 인터페이스 계층들은 이 장의 나머지 부분에서 자세히 설명한다.

최상위 계층에는 원격 시스템의 정보를 수집하기 위하여 사용자들이 직접호출할 수 있는 시스템이 제공하는 RPC 함수들이 있다. 이 함수들은 일반적으로 C 라이브러리 함수처럼 사용될 수 있다. 단지 그들을 사용하기 위해서는 특별한 설정이 필요하다. 즉, (1) 함수의 원형들을 선언하는 특정한 헤더 파일들과 (2) 컴파일된 프로그램은 -lrpcsvc 스위치와 함께 링크되어야 한다. librpcsvc.a 라이브러리는 이 RPC
라이브러리 함수의 목적코드들을 포함한다.

RPC 라이브러리 함수들의 장점은 쉽게 사용할 수 있고 프로그래밍 부담이 적다는 것이다. 그러나, 시스템에서 정의된 RPC 라이브러리 함수들은 많지 않다. 그러므로, 이 함수들에 대한 응용은 제한이 있다.
RPC 프로그래밍의 두 번째 계층은 RPC 클라이언트와 서버의 스터브(stub) 루틴을 자동적으로 생성하기 위하여 rpcgen 컴파일러를 사용하는 것이다. 사용자들은 단지 클라이언트와 서버 프로그램을 생성하기 위한 클라이언트의 main 함수와 서버의 RPC 함수들만 작성한다. 또한 rpcgen 컴파일러는 클라이언트와 서버 사이에 데이터를 전송하기 위하여사용자가 정의한 어떠한 데이터 유형이든지 XDR 형식으로 변환하는 XDR 함수들을 생성할 수 있다. rpcgen 컴파일러를 사용하여 얻는 장점은 사용자들이 RPC 함수들과 클라이언트의 main함수를 작성하는데 주력할 수 있다는 것이다. 즉, 하위 계층의 RPC API들에 대해 알 필요가 없다. 이는 프로그래밍 노력을 절약하고 오류 발생 가능성을 줄이게 한다. 그러나, 이러한 접근 방식의 결점은 rpcgen이 생성한 클라이언트 서버프로그램에 의하여 사용되는 네트워크 트랜스포트의 어떤 자세한 속성들에 대하여 제어하기 어렵다는 것이다. 또한 이러한 클라이언트 서버는 XDR 함수들에 의하여 사용되는 동적 메모리를 관리할 수 없다.
RPC 프로그래밍 인터페이스의 최하위 계층은 RPC 클라이언트와 서버 프로그램들을 생성하기 위하여 RPC API들을 생성하는 것이다. 이것의 장점은 사용자들이 프로세스에 의하여 사용되는 네트워크 트랜스포트와 XDR 함수에 있는 동적 메모리 관리를 직접 제어할 수 있다는 것이다. 그러나, 이는 사용자 부분에서의 더 많은 프로그래밍 노력이 필요하게 된다

출처 : Tong - forestcamp님의 [솔라리스]통

2007/10/16 10:51 2007/10/16 10:51
이 글에는 트랙백을 보낼 수 없습니다

1. 사용자 인증의 단일 창구 SSO

 가. SSO(Single Sigh On)의 개념

  - 사용자가 한 개의 ID, PASSWORD로 여러 응용시스템을 접근할 수 있는 기술

 나. SSO가 필요한 이유

  - 기업내 다양한 응용시스템 도입 및 운영에 따른 ID, PASSWORD 관리 복잡

  - 중앙집중적인 ID관리 및 시스템 권한관리를 통한 업무의 순화 및 표준화 실현


2. SSO의 요소기술과 EAM의 비교

 가. SSO의 특징

   1) 특징 : 단일의 ID, PASSWORD를 통한 다양한 시스템 접근 제공

   2) 구성요소 : 클라이언트/서버 Agent, SSO 인증서버, LDAP

   3) 주요기능 : 단일 로그인, 표준화된 인증 접근방법, 중앙집중식 접근관리 가능

   4) 구현방식 : 쿠키방식, 웹방식, PKI인증서 이용방식


 나. EAM(Enterprise Access Management)와 SSO의 비교

비교항목 EAM SSO
목적 ID관리와 권한, 자원정책의 결합 중앙집중식 ID 관리
장점 자원접근시 권한까지 제어
개별응용레벨의 권한제어
단일 ID 로 사용의 편리성
인증정책과 권한설정이 용이
단점 사용자/자원별 권한관리 어려움
고가 및 구현의 복잡성
ID, PASSWORD노출시 전체시스템 위험
자원별 권한관리 미비


3. SSO 적용시 고려사항 및 활용

 가. 단일 ID, PASSWORD 사용으로 노출시 기업전체의 보안위협이 되므로 개인의 철저한 ID,

       PASSWORD관리와 병행하여 ONE-TIME PASSWORD 정책이 필요함

 나. PKI 기반의 SSO 단순성 탈피위해 PMI(Previlege Management Infrastructure) 의 AC(Attribute

       Certificate) 인증서 사용하고 , 향후 EAM 도입이 필요함.

EAM 시스템과 요구 사항

연·재·목·차

제1회 EAM 시스템과 요구 사항
제2회 SSO 모델과 보안 기술
제3회 SSO·RBAC 표준화 동향


기업의 IT 인프라와 자산에 대한 통합화 및 관리 그리고 통제에 대한 관심이 증대되고 있다. 단순한 사내망에 불과하던 기업 IT 인프라가 직원, 고객, 파트너 등으로 사용자가 확대되면서 다양한 서비스를 요구받기 때문이다. 모든 기업들은 회사의 자원을 보호하고 자원에 대한 접근 권한을 관리함으로써 이러한 복잡한 문제들을 해결하길 바라고 있다. 이러한 기업의 요구에 부합하는 기술적 트렌드를 3회에 걸쳐 연재한다.

강신범 | 소프트포럼 기반기술개발실장


EAM(Extranet Access Management) 시스템은 인트라넷·익스트라넷 서비스를 동시에 수행하는 현재의 기업 IT 인프라 시스템을 안전하게 구성하고 효율적인 관리를 수행할 수 있는 환경 제공을 목적으로 한다.

EAM 시스템에 대한 이해를 돕기 위해 먼저 기업 내 IT 인프라를 EAM 시스템으로 통합하는 시나리오를 간단히 기술하고, 이 시나리오에 근거해서 EAM 시스템의 요구사항을 보안 a기술 측면에서 살펴본다.


EAM 시스템

현재 그룹웨어, 인사관리(HR) 시스템 그리고 전사적자원관리(ERP) 시스템을 운영하고 있는 회사의 경우 각 애플리케이션 별로 각각의 사용자 계정과 권한 관리를 위한 자원이 투입돼 운영된다. 이는 부가적인 관리를 필요로 함은 물론이고 획일적이고 통합되지 않은 상태의 시스템 운영으로 인한 다양한 부작용 및 보안적 결함을 드러내게 된다. 이와 같은 고민에 빠진 회사는 규모의 증대와 IT 인프라 확산에 비례해 보안적 결함이 점차 증가하게 된다. 또한 일정 시일 이후에는 EAM 시스템 도입 비용을 상회하는 기존 시스템의 운영비용으로 인한 손실분을 안게 되는 최악의 상황에까지 몰리게 된다.

이같은 회사가 EAM 시스템을 도입하게 되었을 경우에 회사 내부에서 사용되는 그룹웨어, HR, ERP를 EAM 시스템으로 통합하고 각 애플리케이션별로 개별적으로 관리되던 사용자 계정, 권한관리시스템까지도 단일화된 EAM 시스템에서 통합 관리하게 된다. 이 작업으로 인한 회사의 IT 인프라는 다음과 같이 변경된다.

우선 사내 직원은 사용자 인증을 최초로 한번 받고, 각 애플리케이션을 SSO(Single Sign-On) 기술에 의해 추가 인증없이 사용할 수 있다. 또한 각 애플리케이션은 개인화 서비스를 통해 인증된 사용자의 정보를 얻어 동작에 적용한다.

개별 애플리케이션은 통합된 인가·접근제어 정책에 따라 사용자의 접근을 제어한다. 사내 IT 인프라 관리자는 EAM 관리시스템을 통해 각 애플리케이션별로 접근권한을 사용자에게 제어할 수 있다. 사용자가 통합 인증을 받고 각 애플리케이션에 접근하는 모든 감사정보를 EAM 시스템이 관리해 개별적으로 관리되던 감사정보를 통합해 관리할 수 있게 된다.


EAM 시스템의 요구사항

EAM 시스템은 적어도 다음과 같은 6가지 요구사항 항목을 가진다.

△인증(Authentication):

시스템에 접근하는 사용자를 확인한다. 일반적으로 ID/PWD 방식이 가장 널리 사용되며 보안성을 강화하기 위해 암호, PKI 기술들이 이용된다.

△SSO:

통합 인증된 사용자가 개별 애플리케이션에 추가적인 인증 요구 없이 사용할 수 있어야 한다.

△인가·접근제어(Authorization):

개별 애플리케이션의 각 자원 및 서비스에 대한 인가·접근제어 권한을 관리 툴로 설정하고, 설정된 인가·접근제어 권한이 개별 애플리케이션 동작에 적용이 돼야 한다.

△개인화(Personalization):

통합 인증된 사용자가 개별 애플리케이션에 접근할 때, 접근하는 사용자의 아이덴티티(Identity)와 사용자의 정보를 확인할 수 있는 기술이 제공돼야 한다.

△관리(Administration):

통합 인증을 위한 사용자 계정, 개별 애플리케이션의 인가·접근제어, 개인화를 위한 정보제공의 범위, 감사기능 등을 편리하게 관리할 수 있는 기능이 제공돼야 한다.

△감사(Auditing):

전체 시스템에 접근해 통합 인증을 받고 SSO으로 개별 애플리케이션에 접근, 인가·접근제어가 수행되는 모든 과정이 감사 기록으로 남아야 한다.

<그림> Extranet Computing 환경


인증(Authentication)

EAM 시스템의 요구사항에서 사용자 인증에 관련된 보안 기술은 전체 시스템의 보안성에 매우 중요한 부분을 차지한다. 이와 관련해 EAM 시스템에서 사용될 수 있는 다양한 인증방법 기술에 대해서 소개한다.

인증방법은 기본적인 ID/PWD 방식과 보안성이 상대적으로 높은 X.509 인증서, OTP(One Time Password), 생체인식으로 나뉘어 진다. 아래에서 설명하고 있는 인증 방법들은 일반적인 EAM 시스템에서 웹 환경에 적용하기 적합한 기술들이다.

△Basic ID/PWD:

HTTP/HTTPS 프로토콜의 BASIC Authentication 방법을 이용해 ID와 패스워드로 사용자를 인증한다. 이 인증 방법은 HTTP 프로토콜을 사용하는 경우 사용자가 입력한 ID와 패스워드가 네트워크를 통해 암호화되지 않고 전송된다. HTTPS 프로토콜을 이용하는 경우에는 암호화돼 전달된다.

△Digest Authentication:

HTTP/HTTPS 프로토콜의 Digest Authentica-tion 방법을 이용해 ID와 패스워드로 사용자를 인증한다. 이 인증방법은 패스워드가 평문으로 전달되지 않아 Basic ID/PWD 인증보다 향상된 보안 서비스를 제공하지만, 패스워드가 저장될 때 반드시 패스워드 원본 혹은 복호화될 수 있는 정보로 저장돼야 하기 때문에 서버에서의 패스워드 관리에 각별한 주의가 요구된다.

△Form Based Authentication:

Customized Form(HTML/JSP/ASP etc.)을 이용해 사용자를 확인한다. 폼에 입력되는 인증 정보는 사용자 ID/PWD 만으로 구성될 수도 있고 사용자 ID/PWD 이외의 다른 정보, 예를 들어 사용자 주민등록번호 등을 추가적으로 포함해 사용할 수 있다. 전달되는 정보의 암호화를 위해서는 HTTPS 프로토콜이나 기타 암호 제품을 사용할 수 있다.

△X.509 Client Certificate over SSL:

HTTPS 프로토콜의 사용자 인증서 인증 프로토콜을 이용해 인증한다. 인증서의 폐기 여부 확인을 위해 CRL 검증과 OCSP 검증 방법을 사용할 수 있다.

△One Time Password 인증:

한 번만 사용될 수 있는 패스워드를 이용해 사용자를 인증한다. 사용자에게 미리 전달된 OTP Token을 이용하여 사용자를 인증한다.

△생체 인식:

사용자의 지문이나 홍채 등을 이용해 사용자를 인증한다. 아직은 널리 사용되고 있지 않으나 지문 인식의 경우 그 영역이 확대되고 있는 추세이다.

지금까지 기업의 IT 인프라 관리를 위해 효율성과 보안성을 모두 만족시킬 수 있는 EAM 시스템에 대한 개념과 요구사항을 살펴봤다. 기업의 다양한 IT 시스템 운영에 있어서 보다 안전하고 저비용의 운영 방식을 원한다면 각 애플리케이션 별로 분산돼 있는 인증과 권한 관리 부분을 통합시켜 전사적인 관리가 가능한 EAM 시스템 도입을 고려해 봐야 한다.



연재/EAM·SSO 기술과 표준화 동향 ②

SSO 모델과 보안 기술

강신범
소프트포럼 기반기술개발실장

연·재·목·차

제1회 EAM 시스템과 요구 사항
제2회 SSO 모델과 보안 기술
제3회 SSO·RBAC 표준화 동향

SSO 모델

일반적으로 사용되는 SSO 시스템은 두 가지 모델로 구분된다. SSO 대상 애플리케이션에서 사용되는 사용자 인증 방법을 별도의 SSO 에이전트가 대행해주는 Delegation(인증 대행) 방식과 SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는 Propagation(인증정보 전달) 방식으로 구분된다.

<그림 1> SSO Delegation Model

△Delegation 방식: 대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용된다. 대상 애플리케이션의 인증 방식을 전혀 변경하지 않고, 사용자의 대상 애플리케이션 인증 정보를 에이전트가 관리해 사용자 대신 로그온 해주는 방식이다. 즉 Target Server 1을 로그온 할 때 User1이 alice/alice라는 ID/ PWD가 필요하다면, 에이전트가 이 정보를 가지고 있고, User1이 Target Service 1에 접근할 때 에이전트가 대신 alice/alice ID/PWD 정보를 전달해서 로그온 시켜준다. △Propagation 방식: 통합 인증을 수행하는 곳에서 인증을 받아 대상 애플리케이션으로 전달할 토큰(Token)을 발급 받는다. 대상 애플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달해 대상 애플리케이션이 사용자를 확인할 수 있도록 하는 방식이다. 웹 환경에서는 쿠키(Cookie)라는 기술을 이용해 토큰을 자동으로 대상 애플리케이션에 전달할 수 있다. 이러한 웹 환경의 이점으로 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있다.

<그림 2> SSO Propagation Model

△Delegation & Propagation 방식: 웹 환경이라고 하더라도 Propagation 방식이 모두 적용될 수는 없다. 특히 웹 애플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우 Delegation 방식을 사용하게 된다. 또한 대상 애플리케이션들이 많이 있고 애플리케이션의 특성들이 다양한 경우 각 애플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO을 구성한다.

△Web 기반 One Cookie Domain SSO: SSO 대상 서비스와 응용 애플리케이션들이 하나의 Cookie Domain안에 존재할 때 사용된다. 일반적인 기업 내부의 컴퓨팅 환경이다. 통합인증을 받은 사용자는 토큰을 발급받게 되고, 이 토큰은 Cookie Domain에 Cookie로 설정되어 Cookie Domain 내의 다른 서비스로 접근할 때 자동으로 토큰을 서비스에 제공하게 된다. 서비스에서 동작되는 SSO 에이전트는 토큰으로부터 사용자 신원을 확인하고 요청된 자원에 대한 접근을 허가 해준다.

Web 기반 Multi Cookie Domain SSO

SSO 대상 서비스와 응용 애플리케이션들이 여러 도메인으로 분산돼 있을 경우다. Multi Domain 환경인 경우에는 사용자 인증 및 토큰의 발행을 위한 마스터 에이전트가 존재한다.
마스터 에이전트는 각 서비스 에이전트의 사용자 인증을 위임받아 수행한다. 인증된 사용자에게는 토큰을 발급하고 각 서비스 에이전트에게 안전하게 전달한다. 또한 에이전트가 해당 토큰을 자신의 Domain에서 Cookie로 저장해 사용할 수 있도록 한다. 각 서비스 에이전트의 신뢰도 및 SSO 시스템의 보안 레벨에 따라 다음과 같이 두 가지 방식으로 서비스될 수 있다.

<그림 3> One Token for All Multi Cookie Domain

△One Token for All Multi Cookie Domain: 모든 도메인이 하나의 토큰을 공유한다. 모든 시스템은 서로 신뢰관계를 가져야 한다. 토큰이 하나만 사용되므로, 마스터 에이전트는 사용자 인증 및 각 도메인에 대한 토큰 제공에 대해서만 수행하게 돼 에이전트들의 관리 및 구성이 매우 간단하다. 하지만 모든 도메인들이 서로 신뢰관계를 가져야 한다는 제약사항으로 인해 적용대상이 제한적이다. 일반적으로 하나의 기업에서 운영하는 다중 도메인 서비스들을 SSO로 구성할 때 많이 사용된다.

<그림 4> One Token form each cookie domain & One Token for Master Agent

△One Token for each cookie domain & One Token for Master Agent: 마스터 에이전트와 각 도메인들이 각각 토큰을 가진다. 마스터 에이전트는 각 도메인의 에이전트들과 신뢰관계를 가지며, 각 도메인의 에이전트들 사이는 신뢰관계를 가지지 않는다. 마스터 에이전트는 각 도메인의 에이전트에게 전달할 사용자 토큰을 발행하므로, 에이전트들의 레벨이나 속성에 따라 토큰에 저장되는 사용자 정보의 양을 조절할 수 있다. 토큰이 각 도메인 별로 발행되므로, 도메인별 Replay Attack 등에 대한 취약성이 전체 시스템에 영향을 주지 않는다.

SSO 보안 기술

토큰은 쿠키를 통해 전달되므로 외부에 노출되는 정보이다. 완벽한 보안을 위해서는 토큰이 네트워크에서 노출되어서는 안되지만, 비용 및 관리상의 이유로 허용되고 있다. 하지만 토큰을 통해 토큰이 포함하고 있는 정보까지 외부에 노출하는 것은 심각한 결함을 제공한다. 토큰의 네트워크 구간에서의 정보 노출 및 위·변조를 방지하기 위해 다음과 같은 보안기술이 사용된다.

△Data Confidentiality: 토큰은 주요 암호 알고리즘(AES, SEED)과 128bit 이상의 키로 암호화돼 보호되어야 한다. △Data Integrity: 토큰은 MAC

(Message Authentication Code) 등을 포함해 데이터의 무결성을 보장해야 한다. △Replay Attack Protection: 토큰은 사용자와 대상 애플리케이션 사이에 전달되는 인증 정보이다. 일반적으로 토큰은 네트워크에 노출되며, 노출된 토큰을 사용해 다른 사용자가 인증을 받고 들어올 수 있다(Replay Attack). 특히 웹 환경에서 이러한 문제점이 중요한 이슈로 등장하고 있다. 이러한 문제점을 근본적으로 해결하기 위해서는 토큰을 네트워크에 노출시키지 않아야 한다.
토큰을 네트워크에 노출시키지 않기 위해서는 항상 사용자와 대상 애플리케이션 사이에 암호 채널을 형성해야 하며, 이 채널을 통해 토큰을 전달해야 한다. 그러나 SSL과 같은 채널 암호를 사용하는 데에는 매우 많은 비용이 요구되어 실제로 많이 사용되고 있지는 않다.
SSL과 같은 암호채널을 사용하지 않으면서 Replay Attack이 발생할 수 있는 상황을 줄일 수 있도록 다음과 같은 보안 기술들이 사용된다.

△사용자 주소 제한: 토큰이 발행될 때 접속한 사용자 주소 정보를 토큰 내부나 토큰을 발행한 서버에서 기억함으르써 Token이 제출된 사용자 주소와 최초 발행시 기억된 주소를 비교하여 접속한 곳 이외에서의 접속을 제한할 수 있다. 사용자 주소가 업무진행 중에 자주 변경되지 않는 시스템일 경우 유효하다. 예를 들어 회사내의 인터넷 환경일 경우 사용될 수 있다. 인터넷 환경의 경우에는 사용자 주소가 특정 범위에서 자주 바뀔 수 있는 환경도 있기 때문에 불특정 다수를 위한 일반적인 인터넷 서비스에 사용하기에는 부적합하다.

△유효시간 제한: 토큰의 유효시간을 매우 짧게 줌으로써 Replay Attack에 사용될 수 있는 시간을 제한한다. 유효시간내에 임계시간(예: 유효시간의 1/2)을 넘으면 자동으로 토큰을 재 발행하여 사용자는 의식하지 못하고 서비스를 계속 사용하게 한다. 지금까지 사용자가 각 애플리케이션별로 별도의 인증을 받지 않고, 한번의 통합 인증만으로 각 애플리케이션들을 사용할 수 있도록 하는 SSO 기술에 대해 살펴보았다. 대상 애플리케이션의 수정을 최소화할 수 있는 Delegation 모델과 토큰을 생성해 통합 인증 서비스를 제공하는 Propagation 모델 그리고 양자의 장점을 조합한 Delegation & Propagation 방식을 이해한다면 현재 도입 대상 기업의 IT 인프라와 진행중인 서비스 및 애플리케이션의 특성에 적합한 EAM 시스템 도입을 결정하는데 도움이 될 것이다.

EAM·SSO 기술과 표준화 동향

제3회 SSO·RBAC 표준화 동향

2007/10/11 16:27 2007/10/11 16:27
이 글에는 트랙백을 보낼 수 없습니다

예전부터 궁금했던 cross-domain 의 한계를 극복하는 방법을 찾았습니다. 2005년 자료이지만 근본적으로는 상관 없을듯  합니다. 원문의 내용을 나름 번역을 하였는데 최대한 빠르게 번역을 해보고자 하였기 때문에 어색한 부분이 많습니다. 그런 부분은 원문에 직접 가서 보는게 좋겠습니다.

원문 : http://fettig.net/weblog/2005/11/28/how-to-make-xmlhttprequest-connections-to-another-server-in-your-domain/

Updates to this post

이 기술문서의 업데이트된 버전(firefox 1.5에서 작업한)을 여기에서 볼 수 있다.

The problem

XmlHttpRequest(이하 XHR) 객체는  다른 서버의 데이터 접근으로부터 해당 데이터를 보호하기 위해 브라우저의 same origin security policy으로 둘러싸여져 있다. 이것은 Ajax 개발자에게 심각한 한계에 부딪히게 한다: 당신은 뒷단에서 server에 호출하기 위해 XHR을 사용할수 있을 것이다. 하지만 그것은 현재 페이지와 같은 서버에서 진행되어야만 한다. 이러한 한계점을 해결할수 있는 대안으로 알려진 것으로는 server-side reverse proxyingbypassing XmlHttpRequest entirely이 있다. 나의(원문 필자)의 경우 이러한 접근들 어느쪽도 실무와 연결되지 않았다. 나는 LivePage  (Divmod에서 Donovan Preston 과 다른 훌륭한 해커들에 의해 개발되어진 live-update 프래임워크)를 사용하길 원했다. LivePage는 동시에 많은 장기유지(long-lasting)되는 네트워크 연결을 핸들링하는데 좋은 Twisted를 사용하였기 때문에잘 작동되었다. 많은 long-lasting 연결을 핸들링하는데 아파치가 좋지 않게 됨에 따라 Twisted server의 앞단에 아파치 reverse proxy를 넣는 것은 performance와 scalibility를 손상시키는 주된 요인이될 것이다. 그리고 LivePage가 XHR에 제약을 받게됨에 따라 나는 궁극적으로 non-XHR를 사용할수가 없었다.

JotSpot과 함께 우리의 접근방식은 Twisted server가 모든 페이지의 요청과 XHR 호출을 핸들링하게 하였다. 그것은 JotSpot이 웹사이트 전용으로 standalone일때까지는 좋았다. 그러나 우리의 고객들이 요구하는 것은 보통 xxx.jot.com 사이트에서 Live-style의 실시간 업데이트를 할 수 있는 능력이었다. 그리고 우리는 우리의 도메인에 있는 모든 사이트의 앞단에 Twisted server를 넣는것을 원치 않았다. 따라서 나는 우리의 도에인의 모든 페이지에서도 XHR을 통해 live.jot.com과 통신할수 있게 할 수 있도록 하는 방법을 찾기 시작하였다. 결론적으로, 그것은 가능했다. 하지만 어떤 hoops를 뛰어넘어야만 한다. 여기 있는 예제들에 대해서 두가지를 알아둬라:

  • 나는 실제로 두개의 다른 server를 사용하지 않았다. 나의 예제에서, http://fetting.net/에 있는 페이지는 http://www.fetting.net/.에 XHR호출생성을 시도할 것이다.사실은 나의 아파치가 동일한 가상호스트를 만드는 것이 브라우저에게는 다르지 않게 보인다. 그것들이 같은 hostname을 가지고 있지 않다고 하더라도,그리고 두개의 다른 내용을 가지고 있는 다른 사이트라고 하더라도 다르지않게 취급되어진다. 만약 내가 ajax.fetting.net서버에 그것의 IP주소와 함께 XHR호출을 한다면 결과는 다르지 않다.
  • 나는 getUrl 한수를 제공해주는 간단한 XHR wrapper library를 사용하였다. getUrl은 URL과 callback 함수를 취하고, URL로 XHR연결을 열어준다, 그리고, 결과와 함께 함수를 호출한다. 만약 이것이 흥미롭다면 여기에서 full code를 볼 수 있다.
  • 내가 XHR호출을 만드는 서비스는 간단한 PHP페이지(ajaxdata.php)로 server에서의 편재 UNIX 시간을 출력한다 : 실제로는 그리 유용하지 않지만 테스트를 목적으로 하기에는 충분히 좋다.

첫번째 시도 : 고지식한 접근방식

여기 내가 시도한 첫번째 방식이 있다 :

다른 subdomain의 페이지의 full URL과 함께하는 XHR. 나는 이것은 동작하지 않을 것이라 확신했지만, 나는 이것을 검증해보고 싶었다 :

  1. <html>
    1. <head>
      1. <script type=”text/javascript” src=”xmlhttp.js”></script>
      2. <script type=”text/javascript”>
        1. var AJAX_URL=”http://www.fettig.net/playground/ajax-subdomain/ajaxdata.php”;
        2. function getTime(){
          1. getUrl(AJAX_URL, gotTime);
        3. }
        4. function gotTime(status, headers, result) {
          1. document.getElementById(’time’).innerHTML = result;
          2. setTimeout(getTime, 1000)
          3. }
        5. window.onload = getTime;
      3. </script>
    2. </head>
    3. <body>
    4. <div id=”time”>
    5. </div>
    6. </body>
  2. </html>
이 페이지는 fetting.net으로부터 전달되어졌고, www.fetting.net으로 XHR 호출을 생성하려하고 있다. 실제로는, 이러한 것들이 같은 server겠지만, browser는 그것을 알지 못한다. 놀랄것도 없이, 이것은 어떤 브라우저에서도 동작하지 않는다. 당신은 다음과 같은 security error를 받을 것이다(firefox로 부터) :
  1. uncaught exception : Permission denied to call method XMLHttpRequest.open
당신은 여기서 그것을 해볼 수 있다.

두번째 시도 : iframe과 document.domain 사용하기

나의 최근 JotSpot 사무실로의 방문에서 Alex는  iframe과 document.domain 프로퍼티를 가르쳐주었다. iframe은 다른 페이지로부터 현재의 페이지에 데이터가 로드되는 것은 XHR과 유사하다. 그러나 iframe은 그것들이 포함하고 있는 페이지들과 동일한 웹서버로부터 당겨오는 페이지에 한계가 없다 - 그들은 그 어떤 URL도 로드할 수 있다. cross-site 보안문제를 예방하기 위해서 브라우저는 javascript object model에 same origin policy를 강요한다:한 frame에서 동작하는 script는 각각의 페이지가 동일한 서버에서 온 것이라 할 지라도, 다른 어떤 iframe 안에 있는 객체에도 접근을 할 수 없다. 그러나, 이러한 규칙에도 예외가 있다. 만약 각각의 페이지가 동일한 parent domain으로 부터 왔고, 각각의 document.domain프로퍼티에 동일한 parent domain을 가리키도록 설정하면, 각각의  iframe에서 동작하나는 script는 각각 서로간에 통신을 허용할 것이다.

예를 들어, http://www.example.com/http://ajax.example.com/을 iframe에 로드한다고 하자. 각각의 페이지가 example.com 도메인에 있는 한, 만약 각각의 document.domain이 "example.com"으로 설정되어 있다면 그것들은 서로간의 데이터에 접근을할 수 있게된다.

그럼, 당신은 iframe과 document.domain을 XHR 연결에 사용할 수 있는 것인가? 두가지의 제약사항과 함께 가능하다.

  1. iframe은 반드시 당신이 XHR호출을 하는 서버로부터 와야 한다.
  2. 반드시 document.domain을 설정하기 전에 XHR 연결(open)을 해야만 한다.

여기 내가 사용한 코드가 있다. 첫번째로, test2.html :

  1. <html>
    1. <head>
      1. <script type=”text/javascript”>
        1. document.domain=”fettig.net”;
        2. function gotTime(result) {
          1. document.getElementById(’time’).innerHTML = “Server timestamp: ” + result;
        3. }
      2. </script>
    2. </head>
    3. <body>  
      1. Single XmlHttpRequest. Works in all modern browsers.
      2. <div id=”time”></div>
      3. <iframe src=”http://www.fettig.net/playground/ajax-subdomain/test2-iframe.html”>    </iframe>
    4. </body>
  2. </html>
이 페이지의 script는  document.domain을 설정하고, XHR 호출의 결과를 핸들링하는 gotTime 함수를 정의한다. 모든 XHR 덩어리들은 iframe에서 일어난다. 여기에 test2-iframe.html코드가 있다 :
  1. <html>
    1. <head>
      1. <script type=”text/javascript” src=”xmlhttp.js”></script>
      2. <script type=”text/javascript”>  
        1. var AJAX_URL=”http://www.fettig.net/playground/ajax-subdomain/ajaxdata.php”;    function gotResult(status, headers, result) {
          1. document.domain = “fettig.net”; // set d.d before talking to parent frame      window.parent.gotTime(result);
        2. }
        3. getUrl(AJAX_URL, gotResult);
      3. </script>
    2. </head>
  2. </html>

test2-iframe.html은 www.fetting.net에 XHR호출을 만든다. 그것은 www.fetting.net으로 부터 왔기때문에 가능한 것이다. 따라서 그것은 단지 그것의 원천 서버에 요청을 하것 뿐이다. 그것이 한번 응답을 받으면, 그것은 parent frame의 document.domain과 매칭시키기 위하여  document.domain을 fetting.net으로 설정한다.이제 그것은 javascript를 사용하여 parent frame에 요청을할 수 있다. 따라서 그것은 window.parent.gotTime을 하는것이 가능하다.

이것을 하기 위한 중점은 올바른 요청에 있다. 당신이 한번 document.domain을 설정하면 당신은 XHR 호출을 만들 수 잇는 능력을 잃게 된다. 따라서 당신은 document.domain을 설정하고 parent frame과 통신을 가능케 하기 전에 당신의 XHR 작업에 신경을 써야할 것이다.

Konq이러한 규칙을 따르면 잘 작동할 것이다. 이 기술들은 현대의 모든 브라우저에 잘 작동되어진다(나는 IE6, Firefox1.0.7, Safari 1.3, Opera8.5, 그리고ueror 3.4에서 테스트를 해보았다)
당신은 여기에서 그것들은 테스트해볼수 있다.

세번째 시도 :  XmlHttpRequest 반복하기

나는 우리의 도메인에 있는 다른 서버로 한개의 XHR을 생성하는 방법을 해결하여 기뻤다.  그러나 현시점에서 이 기술은 거의 심각한 한계를 가지고 있다.:당신은 XHR호출을 당신이 document.domain을 설정한 시점에서만 할 수 있다. 당신이 한번 그렇게 하면, 당신은 parent frame과 통신할 수 있는 능력을 얻게 되지만, 앞으로 XHR 호출을 할수있는 능력은 잃게 된다. 계속적으로 서버에 XHR 호출을 생성하고 결과를 핸들링해야하는 능력이 필요한 LivePage에게는 이것은 좋지 못한 방법이었다. 나는 iframe이 server(XHR를 사용하여)와 parent frame(document.domain을 설정해야지만 할 수 있는)과의 통신 모두를 할 수 있는 방법이 필요했다.

이로서 질문한가지를 떠오르게 하였다 : document.domain 프로퍼티를 한번만 설정할수 있는가? 혹은 fly에서 그것을 switch할 수 있는가? 만약 그 변경을 앞으로 혹은 뒤로 되돌릴수 있다면, 그것을 앞으로 뒤로 바꾸는 것은 가능할 것이다. 여기에 iframe의 수정된 버전인 test3-iframe.html이 있다.

  1. <html>
    1. <head>
      1. <script type=”text/javascript” src=”xmlhttp.js”></script>
      2. <script type=”text/javascript”>  
        1. var AJAX_URL=”http://www.fettig.net/playground/ajax-subdomain/ajaxdata.php”;
        2. function gotResult(status, headers, result) {
          1. var oldDomain = document.domain;
          2. document.domain = “fettig.net”;
          3. window.parent.gotTime(result);
          4. document.domain = oldDomain;
          5. setTimeout(getTime, 1000);
        3. }
        4. function getTime(){    
          1. getUrl(AJAX_URL, gotResult);
        5. }
        6. getTime();
        7. </script>
      3. </head>
    2. </html>
결과는 test2-iframe.html에서와 비슷하게, test3-iframe.html에 있는 gotResult 함수는 document.domain을 fetting.net(parent frame에 접근을 가능케 하기 위해)로 설정하고 window.parent.gotTime을 호출한다. 그러나 첫번째로 해당 페이지가 전송되어진 호스트를 디폴트로 하는 현재의 document.domain값을 저장해놓는다. 그것은 parent와의 작접을 끝낸 후, 그것은 document.domain을 원래의 값(XHR 을 생성할 수 있는 처음에 저장한 domain주소)으로 바꾸어 설정한다.  그런다음 그것은 다른 XHR 호출을 설정하기 위하여 setTimeout을 사용한다. 결과는 main page에서 timestamp가 계속해서 갱신되어져야만 한다.
당신은이 동작을 여기서볼수 있다.
이 페이지는 iframe이 각 시간마다 parent page에 있는 함수를 호출하고 XHR을 반복적으로 생성해내고 서버로부터 결과를 얻어낸다 . 불행하게도 이 기술은 IE,Safari,Knqueror에서는 잘 작동되지만 Mozilla와 Opera에서는 작동하지 않는다. 첫번째 XHR은 동작을 하지만, document.domain을 원래의 값으로 바꾸려고 할때 오류가 발생할 것이다. Firefox에서는 다음과 같은 error message를 발생시킨다.
  1. Error: [Exception... "Illegal document.domain value"   code: “1009″  nsresult: “0×805303f1 (NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN)”   location: “http://www.fettig.net/playground/ajax-subdomain/test3-iframe.html  Line: 13″]
Mozilla와 Opera는 document.domain의 값에 대해서 더욱 엄격하다 - 그것은 오직 현재의 값이나 더 상위 레벨의 도메인으로만 설정이 가능하다.예를 들어서 만약 호스트가 aaa.bbb.example.com이라면, 나는 document.domain을 bbb.example.com으로 바꿀수 있다. 이러한 점에서 나는 그것을 다시 example.com으로 바꿀수 있었지만, 다시 aaa.bbb.example.com으로 되돌릴수는 없었다. 한번 당신이 상위레벨의 도메인으로 옮겼다면 다시는 하위레벨로 수정할수가 없어서 곤경에 빠질 것이다.

네번째 시도 : Mozilla에서 동작하게 하기

나는 Opera없이 살 수 있지만 Mozilla없이는 살 수 없다. 따라서 나는 그 문제를 해결할 수 있는 방법을 찾아내야 했다. 잠시동안 그것에 대해서 생각해본뒤 나는 의문이 생기기 시작하였다 : frame들간에 통신에 있어서 보안상의 제한이 단지 어떻게 엄격하게 규정되어지는가? 우리는 브라우저들이 해당 frame의 document.domain이 같은 값을 가지고 있지 않은 이상은 다른 프레임으로의 접근을 하지 못하도록 한다는 것을 알고 있다. 따라서 child frame들의 document.domain을 설정이 parent의 그것과 같지 않다면 child에서 window.parent.foo에 접근하는 것은 불가능 하다. 그러나 만약 당신이 parent frame에 있는 함수를 지시할수 있도록 childframe에 있는 attribute를 설정할 수 있다면, 그리고 document.domain을 바꿀 수 있다면 어떤가? child frame은 여전히 함수를 호출할수 있을까? 대답은 "그렇다"이다. 그리고 그것은 내가 Mozilla에서 작업하는데 있어서 필요로 하는 것을 충족시켜주었따. 방법은 두개의 frame을 사용하는 것:

  1. parent window  bridge iframe  child iframe
bridge iframe과 child iframe은 모두 당신이 XHR 호출을 만들고자 하는 서버로부터 존성되어졌다. parent apge 코드는 위에서의 예제와 동일하다 :그것은 XHR의 결과를 핸들링하는 함수를 정의하고, iframe을 로딩한다. 여기서는 bridge code를 보자 :
  1. <html>
    1. <head>
      1. <script type=”text/javascript” src=”xmlhttp.js”></script>
      2. <script type=”text/javascript”>  
        1. function gotTime(result) {    
          1. window.parent.gotTime(result); // pass result up to the parent  
        2. }  
        3. window.onload = function(){
          1. var subframe = document.createElement(’iframe’);      document.body.appendChild(subframe);
          2. subframe.src = “test4-iframe.html”;
          3. subframe.contentWindow.bridgeGotTime = gotTime;
          4. document.domain = “fettig.net”;
        4. }
      3. </script>
    2. </head>
    3. <body>
    4. </body>
  2. </html>

이 frame이 로드될때, 그것은 다른 frame 그 안에 로드한다. child frame이 bridge frame과 동일한 서버로부터 로딩되어지는 한, bridge frame은 script를 통해서 child frame의 객체에 접근할 수 있다.bridge frame은 그것만의 gotTime에 subframe.contentWindow.bridgeGotTime를 설정한다. 다음으로 bridge frame은 그것의 document.domain을 그것의 parent widnow의 그것과 매칭시켜 변경한다.이 시점에서 bridge frame은 그들의 document.domain 프로퍼티가 매칭되지 않을때까지 child frame에 직접적으로 통신할수 있는 능력을 잃게 된다. 그러나 child frame은 처음에 설정해놓았던 bridgeGotTime 함수를 통해서 bridge frame과 통신을할수 있는 능력을 유지할수 있게된다. 그리고 bridge frame의 document.domain이 parent의 document.domain과 매칭되는한, bridge와 parent는 자유롭게 통신할수 있다. 나의 제한적인 테스팅에서는,이 기술은 오직 Mozilla-based 브라우저에서만 작동하는것처럼 보였다. (나는 Opera에 대한 방법을 찾지 못했지만, 여기에 시간을 많이 소비할 생각은 없다).

나의 마지막 예제에서는 document.domain을 switching하고, 만약 당신이 document.domain을 재설정하려고 할때 브라우저가 에러를 발생시킨다면 bridge-iframe에 의지할 수 있는 hybrid적인 접근방식을 사용하였다. 여기 main page code가 있다 :

  1. <html>
    1. <head>
      1. <script type=”text/javascript”>
        1. document.domain=”fettig.net”;
        2. function gotTime(result) {
          1. document.getElementById(’time’).innerHTML = “Server timestamp: ” + result;
        3. }
      2. </script>
    2. </head>
    3. <body>
      1. <div id=”time”></div>
      2. <iframe src=”http://www.fettig.net/playground/ajax-subdomain/test4-iframe.html”></iframe>
    4. </body>
  2. </html>
여기까지는 iframe이  test4-iframe.html으로부터 로드되어져 온다는 것을 제외하고는 모든것이 동일하다. 여기 그 페이지의 코드가 있다 :
  1. <html>
    1. <head>
      1. <script type=”text/javascript” src=”xmlhttp.js”></script>
      2. <script type=”text/javascript”>  
        1. var AJAX_URL=”http://www.fettig.net/playground/ajax-subdomain/ajaxdata.php”;    function getTime(){
          1. getUrl(AJAX_URL, gotTime);
        2. }
        3. function gotTime(status, headers, result) {
          1. var oldDomain = document.domain;
            1. if (window.bridgeGotTime) {
              1. window.bridgeGotTime(result);    
            2. } else {
              1. document.domain = “fettig.net”;      
              2. window.parent.gotTime(result);    
            3. }
            4. try {
              1. document.domain = oldDomain;
              2. setTimeout(getTime, 1000);    
            5. } catch(e) {
              1. // denied access to switching the domain, use bridge instead        document.location.replace(”test4-bridge.html”);    
            6. }  
          2. }  
          3. getTime();
          4. </script>
        4. </head>
      3. </html>

이 코드는 XHR서버와 parent frame 각각에 대하여 통신할 필요가 있을때마다 document.domain을 전 후로 변환하는 것을 시도한다. 그러나, 만약에 이것이 실패한다면  그것은 대신하여 bridge iframe을 로드할 것이다. 두개의 다른 페이지가 동일한 일을 하게 하기 위하여,이 페이지는 bridge frame의 child로서도 수행되어진다. 만약 그것이 widnow.bridgeGotTime 어트리뷰트를 보게 되면 그것은 bridge iframe의 아래에서 수행되어진다는 것을알수 있을 것이고, 따라서 그것은 직접적으로 widnow.parent를 요청하는 대신에 window.bridgeGotTime를 요청할 것이다.

당신은 이 액션을 test4.html에서 볼 수 있다. 그것은 Opera를 제외한 최근 모든 브라우저에서 작동한다.

Update : test5.html를 사용하라(갱신되었음). 자세한 내용은 여기 참고

결론 :  당신의 도메인에서 다른 서버에 XHR호출을 만드는 것은 가능하다. 만약 당신이 약간의 설정상의 오버로드를 감안할 의지가 있다면 당신은 반복적으로 호출할 수도 있다. 이것은 여러가지의 이점을 가지고 있다 :
  1. 만약 페이지의 주요 컨텐츠가 아파치나 다른 어떤 웹서버로부터 불러져온다면 그동안 LivePage 요청은을 핸들링하는 전용 Twisted server 를 가질 수 있다.
  2. XHR을 포함하는 웹서비스를 핸들링할수 있는 전용 서버를 가질 수 있다.
  3. two-max-connection이라는 브라우저의 한계로부터 DNS에서 자유롭게 XHR를 사용할 수 있다. 브라우저는 당신이  한번에 두개가 넘은 연결을 할수 없게할 것이다-만약 당신이 JotSpot Live와같은 어플리케이션을 사용하고 한번에 한개가 넘는 탭으로 이동하려고 한다면 뒤죽박죽이 되어질 수 있다. 그러나 만약 XHR이 같은 서버에서 호출되지 않아도 된다면, 당신은 wildcard DNS를 사용할 수 있고,
2007/10/09 13:51 2007/10/09 13:51
이 글에는 트랙백을 보낼 수 없습니다
기타  2007/10/05 14:40

본좌가 웹서핑을 하던 중 우연히 헌팅노하우를 묻는 사람과 답변하는 사람들의 글을 읽었는데 묻는 사람은 절실한데 답변들은 모두 상투적이고 실용적이지 못한 것들만 있어서 짧막하게나마 본좌의 노하우를 전수하기로 한다. 참고로 이 글을 읽고 뭔 헛소리냐고 할수도 있겠지만 다년간에 걸친 실험과 이론을 바탕으로 쌓인 노하우를 공개하는 것이다.


먼저 본좌로 말할거 같으면 키는 173정도로 약간 작은 편이며 유머센스가 남다르고(그렇다고 항상 재미있는것은 아니다. 같은 유머를 해도 먹힐때도 있고 이상한 사람취급을 받을때도 있다.) 얼굴이 보기드문 얼짱이다. 집은 중산층에 조금 못미치는 정도이며 직장에 다니고 받은 월급은 자유롭게 쓰는 편이다. 학력은 전문대졸이며 어릴땐 무식이 통통 튀었으나 여러책들을 두루 섭렵하고 지식수준은 남들만큼 아는 편이다.


헌팅은 꼭 잘생기고 멋진 남자만 하는것은 아니다. 모든 여자가 잘생기고 멋진 남자한테만 마음을 여는것은 아니기 때문이다. 다시 설명하겠지만 타이밍을 잡고 대쉬할때 최대한 쿨하게한다. 절박하게 매달리는 듯한 인상을 줘선 안된다. 우연한 만남을 가장하는것이 가장 바람직하다.


여자들은 대부분이 내 얼굴을 보자마자 호감을 갖는 편이나 어떤 여자들은 처음부터 무시하는 경우가 있다. 이것은 네가지의 경우가 있으며 첫째, 얼굴값 한다며 잘생긴 남자를 처음부터 거부하는 여자, 둘째, 남친이 있으며 그 남친을 사랑하는 여자, 셋째, 경험은 전무하나 이론에만 빠삭해서 봐도 별 호감없는척 해서 관심을 끌려는 여자, 넷째, 자기 자신에 대한 열등감이 극에 달해서 본능적으로 잘생긴 남자를 배척하는 여자가 있다.


내가봐도 기가막히게 예쁜 여자가 나에게 싸인을 보낼때도 있고(싸인이 무엇인지 구체적인 설
명은 본문에서 하기로 한다) 예쁘게 생긴 여고딩이 추파를 던질때도 있으며 나보다 키큰여자가 싸인을 보내서 내가 여자를 올려다 봐야할 경우도 있다.


한가지 분명한것은 아무리 예쁘고 많이 놀아본 여고딩이라 해도 연애에는 초보라는 사실이다.


노파심에서 말하지만 본좌는 미성년자나 임자있는 여자는 절대 건드리지 않는다.


이건 철칙이다. 그럼 남친있는 여자가 나에게 대쉬해오면 어떻게 하나? 지금있는 남친에게 잘하라고 설득한 후 그래도 내가 좋다고 하면 그땐 그 남자와 정리하고 나에게 오라고 한다.


단, 정리할때 절대 도와주지 않는다. 여자로서는 자존심이 상할수도 있지만 상한만큼 정리하고 나에게 오면 그만큼 더 잘해준다.


본좌는 주로 지하철에서 헌팅을 하는 편이다.


나이트는 흥분된 감정으로 만나 막나가며 퇴패적이라 싫고 버스는 착 달라붙는 맛이 있지만 너무 흔들거려 싫고 길거리는 타이밍을 잡기가 매우 힘들다.


편의점(거의 모든 업소)알바에 대한 헌팅 요령도 설명을 하겠지만 업소에 갈때마다 돈써야 되서 싫다. 길거리 헌팅, 나이트 부킹, 버스안에서의 헌팅에 대해서도 설명하겠지만 지하철을 적극 추천하는 바이다.


본좌는 지하철에서의 헌팅 성공률 40%를 자랑한다.


"고작 40%?"라고 말하는 사람은 헌팅경험이 전혀 없을 뿐더러 여자경험도 적은 문외한이라고 말하고 싶다. 맹수도 사냥성공률은 운이 좋아야 20%이며 운없을땐 0%일때도 많다고 한다.


40%면 10일동안 하루 한번씩 헌팅해서 4번을 성공한다는 얘긴데 네명을 모두 만난다고 가정할때 스케줄 관리가 아주 어렵다.


자금관리도 중요하다. 네명을 만나면 돈이 돈이 아니라 물이다. 그냥 막새나간다. 참고로 본좌는 1달동안 11명의 여자와 데이트 또는 헌팅을 한적이 있는데 줄곧 체크카드만 쓰다가 돈이 부족해서 신용카드를 만들어 쓰고 그거 메꾸느라 6개월을 고생한 적이 있다.


자금관리는 헌터의 필수 덕목이다.


7곱다리 걸치고 일주일동안 하루 한명씩 만난다는 개구라를 치는 바람둥이들이 있는데 그건

정말 구라다. 그건 진정한 헌팅이 아니며 그냥 되는데로 막만나는 걸레일 뿐이다.


진정한 헌팅은 자기 관리에서부터 시작한다. 1명을 만나던 4명을 만나던 자기일과 여자 둘다 놓치거나 소홀하지 않아야 한다. 어느 한쪽에 소홀하거나 치우치게 되면 양쪽 다 무너지게 된다.


이쯤되면 눈치 챘을것이다. 본좌의 헌팅목적은 섹스는 부수적인 것이며 상대방과 나와의 유쾌한 교감에 있다는 것을 말이다. 생각해보라. 너무 예쁜 나머지 남자들이 넋을 놓고 바라보는 여자와 함께 향긋한 차한잔이나 부드럽고 진한 와인한잔, 또는 더운 여름날 저녁에 시원한 맥주한잔과 함께 오고가는 대화를...


먼저 한가지 더 말하자면 난잡한 섹스를 꿈꾸며 이글을 읽는다면 꿈도꾸지 말라는 것이다.


섹스가 전부는 아니지만 정신에 미치는 영향은 지대하다. 난잡한 섹스는 정신을 망친다. 그래서는 절대 유쾌한 대화가 오고갈수 없다. 정신이 썩어있는데 호감있는 대화가 오고갈수는 없다. 걸래를 목표로 삼는다면 이글을 읽을 필요는 없다. 채팅사이트 가서 돈줄테니 벗으라고 하면 된다.


정신은 썩어있는데 유쾌하고 호감있는 화술을 익히면 될것 아니냐고 반문한다면 그건 또 그렇지가 않다. 대화중에 반드시 티가 나게 되있다. 티가 날것을 우려해서 말을 조심한다면 단어를 선별해서 선택적으로 해야하고 이로인해 대화가 부드럽게 이어지지 못하고 어색한 분위기가 연출된다.


할수 있다면 해봐라. 100%단언하는데 절대 그렇게 되지 못한다. 왜? 인간이니까.


그럼 본좌의 헌팅노하우를 공개하기 전에 대전제를 하나 세우기로 하자.


얼굴을 떠나서, 직업을 떠나서, 가진것을 떠나서 당신은 항상 깔끔하며 지적이고(또는 어느정도 풍부한 상식과 유머감각) 매너있어야 한다. 좀더 정확히 말한다면 지적인것처럼 보여져야 한다. 아니면 옷을 잘입거나(비싼옷을 입으라는 소리가 아니다) 패셔너블하게 입지 못할거면 최대한 단정하고 깔끔하게 입어야 한다. 머리에 염색을 하더라도 멋있게, 어울리게, 절대 튀지 말아야 한다.


얼짱에 직업도 괜찮고 집도 부자라면 더할나위 없지만 그렇지 못하다면 자신이 꾸밀수 있는 한도 내에서 최대한 깔끔하게 하고 다녀야 한다.


당신의 심장을 떨리게 만드는 여자는 예고하고 나타나지 않는다.


언제 어디서 나타날지 모르기 때문에 항상 약간의 긴장과 함께 빈틈없이 준비해야 한다. 그것이 진정한 헌터로의 첫걸음이다. 얼굴이 중간 이하라면 몸매라도 가꿔라. 집중적으로 키워야 할곳은 가슴과 팔뚝이다. 가슴과 팔뚝은 옷위로 봐도 어느정도 예상이 가능하기 때문에 집중적으로 키워야 할 부위다. 배가 나왔다면 배가 들어가보이는 복대가 절찬리에 판매되고 있으며 힘을주고 걸어다니는 연습을 하기 바란다.


샤워는 매일아침에 집을 나서기 전에 하며 이는 아침, 점심, 퇴근전, 자기전에 닦는다. 거르지 말라. 이렇게 닦아줘야 커피등 음식물을 먹은 후에도 입에서 군내가 안난다.


한가지 짚고 넘어가야 할것은 고딩이하는 설명에서 빼고자 한다. 초딩부터 고딩까진 어느정도 예상은 가능하지만 제대로 이해하지 못할 난해한 세대이기 때문이다. 대딩부터 직딩들을 대상으로 설명하기로 한다.


당신의 헤어스타일, 옷차림, 매너, 말투, 얼굴표정등등 여자에게 첫인상으로써 비춰질수 있는 모든 것들은 겉으로 보이는 여자의 차림새와 분위기, 행동거지에 따라 달라진다. 이건 상당히 미묘한 것으로써 100명의 당신들이 처한 상황에 모두 맞춰줄 순 없다.


따라서 몇가지 큰 줄기만 설명할테니 당신에게 맞는 상황이 아니라면 "이글도 별 쓸모없네"라고 단념하지 말고 당신을 바꿔라.


당신은 어떤 여자에게 매력을 느끼는가? 지적인 여자? 여성스런 여자? 섹시한 여자? 순진한 여자? 잘 놀게 생긴 여자? 귀여운 여자? 순결 그 자체로 보이는 여자? 포근한 연상? 당신보다 키가 큰여자? 만만해 보이는 여자? 쉬워보이는 여자? 특별한 매력이 없는 편한 여자? 돈많아 보이는 여자? 부족한 나를 이해해주고 사랑해줄것 같은 마음고와 보이는 여자? 성격좋아 보이는 여자? 치마만 두르면 다 좋은가?


당신은 어떤 여자를 원하는가? 당신이 보기엔 어떤 여자가 당신에게 잘 넘어올것 같은가?


당신이 목표로 삼은 여자는 어떤 여자인가? 지적인가? 지적이라면 당신도 지적으로 보여야 한다. 외모는 지적인데 귀엽거나 거친 스타일을 좋아할수도 있지 않은가? 라고 말한다면 그럴수도 있겠지만 상대방의 외모가 지적이라면 좋아하는 남자스타일도 지적일 확률이 높다.


당신이 볼때 머리를 노랗게 물들인 여자는 어떻게 보이는가? 막놀게 생긴 이미지를 떨칠수 있는가? 마찬가지다. 고학력에 지적이며 풍부한 상식과 호감가는 직업, 고급비지니스 매너를 가진 여자는 외모를 함부로 하지 못한다. 그여자의 주위환경이 그렇지 않거니와 주위에서 그런 모습을 용납하지도 않는다. 그런 여자가 당신의 노란 머리를 보고 어떤 생각을 하겠는가?


당신이 매력을 느끼는 여자가 지적인 여자라면 당신도 지적으로 보여져야 한다.


흔히 지적인 캐리어 우먼이라면 드라마에서처럼 조건을 따져서 즐긴다고 생각하겠지만 사실 그렇지 않은 경우가 더 많다. 그들도 여자이고 대담하며 성적쾌락을 즐긴다. 어째서? 그들도 인간이고 여자이니까.


그럼 반대로 생각해 보자. 당신이 목표로 하는 여자가 잘 놀게 생긴 여자라면 어떨까? 그러한 여자에게 당신은 양복입고 세련된 디자인의 뿔테안경을 쓰고 접근한다고 가정해보자. 여자 입장에서는 세련되고 능력있어 보이는 남자를 싫어하진 않지만 실재로는 상대도 안하고 가버린다. 왜그럴까?


그건 그여자의 생각의 문제다. 자신은 평범하고 보잘것 없다고 생각하고 있는데 상대방은 자신과 정 반대의 이미지라면 만나볼 생각도 않하고 피할 것이다. 자신이 상대방에 비해 부족하다고 생각하기 때문이다.


아닐것 같은가? 직접 나가서 확인해 보라. 10중 8,9는 설명한 대로 될것이다. 유유상종, 끼리끼리 모인다라는 말은 괜히 나온게 아니다.


즉, 당신이 원하는 여자의 스타일을 이미지해서 자신의 스타일도 맞춰야 한다는 뜻이다.


이것은 여자로 하여금 동질감을 느끼게 함과 동시에 좀더 편안한 상대로 비춰질수 있다는 뜻이다. 단, 오바하지 말아야 한다. 머리색이 튀는 여자라고 해서 자신도 온갖 튀는 치장을 하지 말라는 뜻이다.


대부분 남자들이 자신의 스타일을 꾸민답시고 개성있게 꾸미면 대부분의 여자는 좋게 보지 않는다. 가벼운 예로 분위기만든다고 앞머리를 내리는 경우가 있는데 대부분의 여자는 가서 핀으로 당신의 앞머리를 넘겨 집어주고 싶어 할것이다.


옷차림도 개성있게 꾸민다고 이상한 옷을 입고는 자랑스럽게 거리를 활보하는데 그건 당신만의 착각이다. 여자는 편안한 남자를 좋아한다. 옷의 모양뿐 아니라 옷의 질감도 대중적이고 보기에 편한 색감의 천으로 만들어진 옷을 선택해야 한다.


요즘 동남아 스타일로 나시 런닝에 피부는 살짝 그을리고 머리에 젤을바르고 다니는 애들이 있는데 그건 내가봐도 느끼하다. 비교적 잘가꾼 몸매가 잘 드러나는건 좋지만 너무 티내고 다니면 오히려 느끼하다. 몸이 좋더라도 입을거 다 입고 살짝살짝 드러나는 몸매가 더 섹쉬하다. 바깥쪽 허벅지가 드러나는 옆이 쫙 찢어진 중국풍 드레스처럼 말이다.


다시한번 말하지만 대부분의 여자는 편안한 남자에게 쉽게 마음을 연다. 괜히 스타일 연출한답시고 부담스런 패션하지 말라.


그렇다면, 이도저도 아닌 애매한 여자는 어떻게 판단을 할까?


스타일이 확실하다면 금새 판단이 서지만 순진한 거 같으면서도 섹시하게 보이기도 하고, 수수한 옷차림이지만 얼굴에 색기가 흐르는 여자라면? 심장떨리게 만드는 얼굴에 몸매도 수준급이고 옷도 세련되지만 직장에서 입을만한 옷이라고 보기엔 애매한, 적당히 야해 보이는 옷차림의 여자라면? 단정해 보이는 정장을 입고 지적이게 보이는 안경을 썼지만 애기같이 귀여운 얼굴이라면 어떤 종류의 여자일까? 속살이 적당히 드러나보이는 옷차림인데 책을 읽고 있다면 그여자는 잘노는 여자인가 그렇지 않은데 옷차림만 야한 여자인가? 이건 나도 모른다. 직접봐도 잘 모른다.


그렇다면 어떻게 해야할까? 답은 그여자의 마음을 엿봐야 한다.


난생 처음보는 여자의 마음을, 말한마디 해보지 않고 어떻게 알까?


이건 여자따라 다르고 남자따라 다르고, 여러가지 방법이 있지만 가장 손쉬우면서 이해가 빠르고 본좌가 즐겨쓰는 방법은 부드럽지만 강렬하게 상대방을 응시하는 것이다.


멀리있지만 않으면 뒤통수를 보고 있어도 여자는 무심코 뒤를 돌아보게 된다. 사람들에겐 그런 직감이 있다. 반드시 돌아보게 되어있다. 만약 돌아보지 않는다면 무언가에 심하게 정신이 팔려있거나 시선을 느꼈어도 의도적으로 돌아보지 않는 경우이다. 이런 경우는 당신이 응시하기 전에 "저여자는 다른것에 정신이 팔려있어서 봐도 돌아보지 않겠구나"라는 느낌이 온다. 그런 여자는 확률이 제로에 가깝다.


그럼 여자가 돌아봤다고 생각해보자. 경험이 부족한 남자는 지레 부끄러움을 느끼고 고개를 돌려버리는데 여자가 먼저 고개를 돌리기 전까지, 피치못할 사정이 생기기 전까진 계속 응시해야한다. 이때 눈빛은 부드러우면서도 강렬해야 한다. 얼굴을 찡그리라는 얘기가 아니라 머리속에 그렇게 본다는 생각만으로 그런 느낌을 여자에게 줄수 있다. 절대 오버하지 말기를...


여자가 돌아봤을때 얼굴표정과 느낌으로 여자의 마음을 간파해야 한다.


"말이 쉽지 그걸 어떻게 알아. 읽고보니 이글도 중요한 부분은 애매하게 넘겨버리네"라고 생각되겠지만 의외로 알기가 쉽다. 왜? 당신을 본 여자도 첫눈에 당신에게 호감을 느꼈다면 당신에게 싸인을 보내니까!


어떻게 보내나? 몇가지가 있지만 가장 흔한 경우는 처음 눈이 마주친 순간 잠깐동안 당신을 응시할것이다. 무심코 돌아봤는데 이상형이거나 이상형에 가깝거나 호감가는 스타일이라면 눈에 확실히 각인될때까지 눈을 때지 못하기 때문이다. 그래서 바로 시선을 돌리지 않고 잠깐동안 응시한 후 시선을 돌린다. 애매할수 있지만 감만 잡는다면 당신은 헌터로써의 눈을 가지게 된것이다.


그 후 당신은 그 여자가 다시 돌아보기를 기다리며 상대방을 응시하고 있어야 한다. 이때 여자가 다시 당신을 돌아본다면 거의 다 된거다.


그여자도 당신에게 호감을 느끼며 당신이 다가와 주기를 바란다는 싸인인 것이다.


이제 마무리를 하며 삼천포로만 빠지지 않으면 된다. 많은 초짜들은 여자들이 보내는 싸인을 눈으로 봤음에도 알아채지 못하고 그냥 흘려버리거나 용기를 내서 말을 걸어도 여자가 획 가버리는 경우가 있는데 왜 그런지는 아래에서 다시 설명하겠다.


여자가 싸인을 보내고 당신이 조용히 응시를 하고 있으면 여자는 간간히 당신을 돌아보며 계속 싸인을 보낸다. 자, 이때부터가 진짜 승부다. 말을 걸 타이밍을 잡아야 한다. 이 타이밍이 사람잡는다. 진정한 헌터가 되기 전까진 10에 8,9는 실패한다. 싸인만 주고받으면 다 됐다고 하더니 왜 거의 실패를 한다고 하는가?


먼저 여자가 차량의 어디에 있는지 살펴보자. 문앞에 있을땐 네가지 경우가 있다. 첫째, 내릴 준비를 하고 있는경우, 둘째, 문안쪽 좌우 사이드에 쇠기둥에 기대어 서있기 편한 공간이 있다. 거기 서있을 경우, 셋째, 문을 바라보며 좀 안쪽에 있거나 문에 착 달라붙어서 유리에 얼굴을 문대고 있는듯한 경우, 넷째, 문 근처에 서있다가 다른곳으로 이동할 준비를 하는경우.


첫번째 경우는 싸인만 오고 갔다면 따라 내려서 헌팅을 하면 된다. 이때 조심해야 한다. 환승역이거나 환승역이 아니어도 사람이 많이 내렸을 경우 바로 말을 걸면 지나가는 사람들한테 채여서 여자가 당혹스러워하고 여러사람들에게 들리거나 볼수있게 하는 경우도 당혹스러워 한다. 이 경우는 실패한다.


사람이 많을때 바짝 붙어서 한적한 곳으로 갈때까지 따라붙는다. 뒤따라 가면 여자도 남자가 자신을 따라오고있다는걸 알고있다. 이때 능숙한 여자라면 남자가 헌팅하기 편한 비교적 사람이 적은 곳으로 유인한다.


능숙하지 못한 여자라면 무작정 남자가 알아서 해주길 바라고 자기 갈길 가버리는데 조금 답답하지만 넓은 마음으로 이해하고 기회를 기다려라.


만약 끝까지 기회가 오지 않는다면 그냥 포기해라. 어차피 안될꺼 말이나 걸어보자 하고 대쉬하면 될수도 있겠지만 대부분 개무안당하고 실패할 확률이 높다.


왜 그런가 하면 상당히 난해한 부분인데, 차량안에서 싸인을 보냈으면서도 급히 자기갈길 가버리는 여자는 당신을 가지고 논것이다. 이게 무슨 말인가 하면 경험도 없고 용기도 없고 성격도 극 소심형이기 때문에 싸인을 주고받는 단계까지만을 즐기고 당신이 다가오면 관심없는척 내빼버린다는 뜻이다. 그런 여자한테 무리해서라도 말을 걸면 눈이 똥~그래져서 기가막히다는 얼굴표정으로 "됐어요!" 라고 말하고는 횡~하니 가버릴것이다. 물론 안그럴수도 있겠지만 대부분 그렇게 된다. 그러니 급히 갈길 가는 여자는 가라고 내버려 두기 바란다.


둘째 경우에는 당신이 응시할 적당한 장소를 고른후 싸인을 보내면 된다. 장소선정엔 여러가지 방법이 있는데 첫번째는 여자옆이나 뒤에 바짝 붙어서 시선을 보낸다. 가까이 있을땐 뚫어지게 쳐다보고 있으면 안된다. 여자와 처음 눈이 마주치기 전까지 계속 편안한 눈으로 보고 있다가 첫눈이 마주치면 여자가 먼저 시선을 돌릴때까지 편안하지만 당신에게 호감이 있다라는 눈으로 쳐다본다. 여자가 시선을 돌리면 3~5초정도 더 보고 있다가 당신도 다른곳을 본다. 잠시 후 다시 그여자를 응시하면 눈이 마주치기를 기다린다.


왜 이렇게 하냐하면 당신이야 헌터로써의 마음가짐을 가진 상태에서 본다지만 여자쪽에선 갑자기 나타난 당신이 놀랍고 당혹스럽기 때문에 마음의 준비를 할수있는 시간을 줘야 한다. 시간을 주는 이유는 당황한 상태에서 대쉬하면 실패할 확률이 굉장히 높다.


두세번 눈이 마주친 후에 여자는 당신을 돌아보지 않을 것이다. 혹은 문의 유리를 통해 당신을 힐끔힐끔 볼것이다. 남자가 대쉬해올경우 승낙할까 말까를 결정할 시간을 준 후에 가능한 다른사람이 들을수 없는 조용한, 그러나 소근거리지 않는 목소리와 톤으로 말을 걸라. 또는 첫번째 경우처럼 내리기를 기다려서 말을 걸라. 둘중 어떤것도 괜찮은 방법이다. 사람마다 첫번째가 편할 경우도 있고 두번째가 편할 경우도 있기 때문에 알아서 하라.


다른 장소로 대각선 맞은편 기둥에 서있는다. 이경우엔 문유리를 통해 시선을 보내지 않는. 즉, 기둥에 기대어 고개를 돌려 직접 시선을 보낸다. 문유리를 통해 시선을 보내면 시선이 잘 닿지 않을 뿐더러 여자가 시선을 느꼈다고 해도 당신이 소심해 보일수 있다.


또다른 장소로 여자의 정면, 좌석앞에 서있는다. 이경우엔 먼저 시선을 보내지 말고 여자에게 당신을 볼수 있는 시간을 조금 준 후에 여자의 시선이 느껴졌거나 이정도면 여자가 당신을 봤다고 생각됐을때 당신도 고개를 자연스럽게 돌려 여자를 바라본다. 이때 처음부터 강렬한 눈빛을 보내지 말고 무심코 돌아봤는데 호감가는 여성을 봤다는 뜻밖의 살짝 놀란 연출을 한다. 그후 위의 방법에 따라 시선을 보낸다.


마지막 장소로 여자가 서있는 기둥 바로 맞은편에 같이 기대어 바라보는 것이다. 이건 여자측에서 상당한 부담으로 작용할수 있기 때문에 왠만한 자신감이 없으면 하지 말라.


세번째 경우는 두가지 패턴이다. 문에 착 달라붙어 있을경우 두번째 경우의 방법을 써라. 이때 여자가 싸인을 보내는지 안보내는지는 문유리에 비친 여자의 얼굴을 보고 판단하라. 문에서 떨어져 있을경우엔 조금 거리를 두고 응시하는 방법을 써라. 방법은 위에서 다 설명했다.


네번째 경우엔, 보통 여자가 차량에 막 올라탄 경우가 많다. 즉, 당신은 여자를 봤고 여자는 당신을 보지 못한 경우가 많다. 이럴땐 차라리 눈이 마주치지 않았을 경우가 더 좋다. 여자가 자리를 잡으면 그 주위에 적당한 장소를 골라 서있는다.


절대 앉지 마라. 여자가 앉았다고 해서 당신도 앉지 말라는 말이다.


앉아있는 여자를 당신도 앉아서 본다면 여자는 부담스러워 한다. 시선을 피할 장소가 마땅치 않기 때문이다. 고작 피한다는게 고개를 돌려 옆을 보거나 아래를 쳐다보는건데 두가지 경우 모두 여자에겐 불편한 자세다. 여자가 앉아있더라도 옆에 앉거나 마주보고 앉지 않는다. 되도록 당신은 마땅한 장소에 기대어 여자를 응시하는 것이 가장 좋다.


참고로 이어폰을 끼고 헌팅하지 말라. 이어폰을 끼고 있으면 여자가 당신을 봤을때 당신이 음악에 정신이 팔려있다는 느낌을 줄수 있다. 정 끼고 싶으면 음악을 듣다가 당신과 눈이 마주쳤을때 살짝 놀라는 표정과 함께 이어폰을 천천히 빼서 가방이든 주머니든 넣는 연출을 한다.


이것은 마치 예상치 못한 상황에서 남자가 이상형의 여자를 본후 뻑가서 넋이 나가있는듯한 연출을 하는 것이다. 되도록이면 이어폰은 끼지 않는것이 바람직하다.


다음으로 여자가 좌석에 앉아있을 경우다.


앉아있는 여자를 응시하기 가장 편하며 적당한 장소는 문안쪽 양옆 기둥이다. 달리는 차량의 앞을 기준으로 오른쪽에 앉아있든 왼쪽에 앉아있든 대각선 맞은편에 자리를 잡는다. 이해가 가는가? 그림으로 설명하면 이해가 빠르겠지만 그리기가 귀찮아서 그림은 넣지 않겠다.


여자가 오른쪽에 앉았는데 오른쪽에 기대면 여자가 당신의 시선을 느껴도 90각도로 틀어서 봐야하기 때문에 불편하고 더 불편한건 옆자리나 맞은편 앉은 자리의 사람들이 쳐다보기 때문이다. 대각선 맞은편에 기대어 보는것이 여자를 배려하는 것이다.


본좌가 자주 애용하는 우등좌석은 문옆 기둥이다. 거기 기대어 서있으면 전방에 여자를 관찰하기 쉽고 여자가 내리고 탈때 주시하기 쉽고 마음에 드는 여자가 탈때 그 여성을 순간적으로 캐치하고 응시하면, 여자가 당신에게 순간적으로 호감을 가진다고 가정했을때 그여자는 당신에게서 멀리 떨어지지 않은, 주위에 자리를 잡을 것이다. 하지만 이것만으론 여자의 마음을 엿볼수 없다. 여자가 자리잡으면 응시하고 판단한다.


다시 앉아있는 여자로 돌아가보자. 의외로 여기서 부터가 어렵다. 상황에 따라 당신은 여러가지 선택을해야하기 때문이다. 물론 당신의 싸인을 받았고 여자도 당신에게 호감을 가지고 싸인을 보낸 상황이다. 여자가 당신에게 별 호감이 없을경우는 앞서 설명한 것처럼 당신이 알수 있을것이다.


당신이 지하철을 타고 가다보면 당신이 내려야 할 역이 있다. 이건 여자도 마찬가지다. 충분한 싸인을 주고 받았는데 다음역이 당신이 내려야 할 역인 것이다.


이때 어떻게 할것인가? 그냥 내릴 것인가? 아니면 여자가 내릴때까지 기다렸다가 같이 내려서 대쉬할것인가? 아니면 당신이 내리기 전에 먼저 차량 안에서 대쉬할 것인가? 차량 안에서 비교적 사람이 적은 한적한 위치라면 괜찮지만, 사람이 따닥따닥 붙어있으면 대쉬해도 괜찮은가? 당신이 괜찮다고 해도 여자 입장에선 어떻게 반응할 것인가?


그렇게 복잡하다면 여자가 내릴때까지 같이 가면 되지 않겠냐고 하겠지만 그것역시 어렵다. 서로 싸인을 주고 받는건 필수지만 너무 많이 주고받으면 오히려 역효과가 나는 경우가 있다.


더 어려운 점은 바로 지리적 이점을 이용할수 없다는 것이다.


본좌는 헌팅지역을 출퇴근길로 제한한다. (퇴근길보다 출근길이 훨씬 더 어렵다. 다시 설명하겠다)다른곳으로 가는건 귀찮기도 하거니와 지하철코스의 괜찮은 커피숍이나, 여름엔 팥빙수 괜찮게 하는집, 겨울엔 따뜻한 차한잔 하기 좋은 집, 분위기 좋은 술집, 맛있는 집등을 파악하고 있다.


여자의 목적지까지 간다는 것은 이러한 지리적 잇점을 포기한다는 뜻이다. 아무리 싸돌아 다니기 좋아하는 사람이라도 서울 전지역을 커버할순 없다. 헌팅에 성공해서 지하철 밖으로 나가면 어색하지 않게, 여자가 기다리지 않게, 능숙하게 커피숍이나 술집으로 유도를 해야 하는데 얘기할 집 찾느라고 두리번 거리면 좋지 않다. 여자가 자기가 아는집이 있다며 리드하는 경우도 있겠지만 그런 경우는 별로 없다.


이런 여자도 있다. 남자의 대쉬를 받을때 당신에게 호감이 있어서가 아니라 적당히 발라먹기 위해 비싼집으로 유도하는, 나갈때 전번도 알려주지 않고 급히 가버리는 여자. 이런 빌어먹을 여자에게 당하지 않기 위해서라도 당신이 리드하는게 좋다.


참고로 여자가 자기 친구들을 부르는 경우가 있다. 이런 경우는 세가지 경우가 있는데 첫째는 설명한것처럼 당신에게 바가지 씌울 생각으로 친구들과 합세하는 경우, 둘째는 막상 얘기해 보니 당신이 별로 맘에 들지 않아서 일어나고 싶은데 간다는 말을 못해서 친구들에게 지원요청을 하는경우, 셋째는 당신과 얘기를 해보고서도 판단이 서지 않을때, 이상한 사람이아닐까 하고 의심하는 경우 친구들의 눈을 빌려 당신을 판단하려는 경우이다.


첫번째와 두번째 경우와는 달리 세번째 경우는 당신이 잘만 한다면 잘될수 있겠지만 앞서 두가지 경우와 구분하기가 쉽지 않다.


즉, 첫만남에서 당신과 시간을 보내지 않고 다른 사람을 부른다면 그냥 포기하라.


친구들을 부를때 적당한 이유를 둘러대고 그냥 가기 바란다. 타이밍을 놓치고 다른 사람들이 와버렸다면 화장실간다고 하면서 그냥 도망가라. 더좋은 방법을 알고 있다면 그렇게 하던지.


정말 곤란한건 이런 경우다. 내릴 역이 와서 포기하고 내릴려는데 문유리를 통해 본 여자가 내리지 말아달라는 애절한 표정으로 당신을 보고 있다면 어떻게 하겠는가? 외면하고 내리겠는가? 내리지 않고 기다리겠는가? 외면하고 내리면 가는길 내내 후회되지 않겠는가? 내리지 않는다면 성공할수 있겠는가?


본좌는 초짜때 이러한 경우가 참 많았다. 내리지 않았을 때도 있었지만 대부분 내려버렸다. 지금이야 그런 상황이 오기전에 조치를 취하겠지만...물론 지금도 종종 취하지 못할 경우도 생긴다.


남자의 마음을 잘 아는 적극적이며 무한히 예뻐해줘야할 여자는 당신이 내리는 모션을 취하면 은근슬쩍 뒤로 와서 붙을 것이다. 그리고 같이 내릴 것이다. 주접만 떨지 않으면 80%이상 성공이다.


주접의 예를 간단히 든다면 따라 내렸다고 해서 긴장이 풀려 만만히 보고는 택도없는 말실수를 하는 경우이다. 그순간 여자는 뭐 이런게 다있냐는 표정으로 째리고 가버릴 것이다. 방심은 절대 금물이다. 절대 긴장을 늦추지 말아라.


여기서 잠깐, 실전에서 실패한 한가지 예를 들겠다.


차량에 타기 전 승강장에서 눈이 맞은 여자가 있었다. 얼굴은 평범했고 보는 사람에 따라 못생겼다고도 할수 있으나 목이 넓게 파인 스웨터를 입어서 고운 피부가 그대로 드러났고 옷을 단정하면서도 세련되게, 잘입었다. 피부도 고왔고 단발머리에 머리결도 탐스러워서 충분한 매력을 지녔다고 느끼고 접근했다.


여자도 내 시선을 느끼고 약간 당혹스러워 하는 표정과 행동을 보였다. 마음을 가라앉힐 시간을 주기 위해 최대한 편안한 눈빛과 표정과 자세로 짤막하게 여러번 시선을 보냈으며 이 상황에서 너무 가까이 있으면 부담이 가중될수 있기 때문에 적당한 거리를 두고 같은 칸에 타기 위해 기다렸다.


열차가 오고 탈려고 보니 비교적 사람이 붐비는게 어려운 상황이었다. 이번열차에 사람이 많으면 다음열차는 빨리오고 사람이 적을 경우가 많다. 요번 표적은 포기하고 다음 열차에서 고를까 하다가 놓치기 싫은 여자라 같이 탔다.


사람이 많은 상황에선 조금이라도 떨어지면 시선을 보내고 받기가 어렵기 때문에 최대한 붙을려고 했으나 타는와중에 여자와 나사이에 사람한명이 낀 안좋은 상황이 발생했다. 어쩔수 없다. 무리해서 붙으면 여자가 피해버릴수 있기 때문에 그대로 시선을 보내며 기회를 노렸다.


다음 역에서 사람이 좀 내리고 공간이 생기자 여자가 뒤로 한걸음 물러나며 내 앞에 바짝 붙었다. 머리결에서 풍기는 향기를 맡을수있었다. 솔직히 이건 의도적이다. 난 가만히 있었는데 여자가 접근한 것이다. 성공을 확신했다.


다음역에서 또다시 사람들이 내리고 문옆에 기둥에 공간이 생겼다. 여자가 기둥에 기대고 나는 기회를 놓치지 않고 바짝 붙어서 기둥을 오른손으로 잡고 기대는 듯이 해서 그여자의 옆모습을 정면에서 가까이 볼수 있는, 사람도 적당히 많아서 그러한 상황이 자연스럽게 연출됐다.


very nice~


바짝 붙은 상황이기 때문에 옆모습을 최대한 자연스러우면서 뜨거운 시선을 보냈다. 여자는 나와 눈이 마주치지는 않았지만 내 시선을 느끼며 최대한 티를 안낼려고 했지만 한없이 부끄러워하는 얼굴표정을 숨기지 못했다. 싸인은 아니었지만 나의 시선을 부끄러워 하는 여자의 얼굴에서 다시한번 성공을 확신했다. "이건 된다". 경험에서 나온 자신감이었다.


몇정거장 후에 여자가 내리자 나도 따라 내렸다. 가능하면 개찰구를 통과하기 전에 말을 걸고 싶었다. 실패할 경우 지하철비가 아까웠기 때문이다. 하지만 사람이 많이 내려서 할수없이 개찰구를 통과하고 걸어가며 기회를 노렸다. 적당히 걸었고 적당히 사람이 없는 곳에서 살짝 미소를 머금은 얼굴로 맥주한잔 하자고 말을 걸었다. 여자는 놀란 얼굴로 "바빠요. 약속이 있어요"하고는 그냥 가버렸다.


자. 여기서 뭐가 잘못된 것인가? 성공을 여러번 확신했으나 실패한 이유가 무엇일까?


뭐가 잘못된건지는 나도 확실치 않다. 다만 한가지 짚히는건 있다.


바로 차가 아닌 맥주를 마시자고 한것이다. 술이 아닌 차를 마시자고 하는것이 당연한 예의라고 생각한 것인데 술을 마시자고 하니 거기서 이상한 사람으로 치부해 버린 것이다. 즉, 나를 개날라리로 보고 자신을 노는 여자로 봤다고 생각해버린 것이다.


이건 확실히 내 실수다. 처음엔 차를 마시자고 하고 차를 마시며 호감을 산 뒤 간단히 맥주한잔 하자고 했었어야 했는데 성공을 확신한 나머지 실수해버린 것이다. 아니면 차한잔 하자고 한뒤 커피숍에 들어가기 전에 혹시 맥주한잔 해도 괜찮겠냐고 정중하게 물었어야 했는데 방심해 버린것이다. 다시한번 말하지만 확실하게 호감을 사기 전까진 방심은 절대 금물이다.


위의 설명은 그 여자가 의도되길 바란 상황이고 좀더 솔직한 상황을 설명할까 한다.


첫째, 차가 아닌 맥주를 마시자고 한것이 최대 실수인것처럼 썼지만 실은 그렇지 않다. 맥주를 마시자고 한것이 실수인건 맞지만 맥주를 마시자고 한것 자체가 실례가 아니라는 것이다. 무슨 말인가 하면 그 여자는 경험이 없어서 너무 부끄러운 나머지 다가와 주길 바라는 마음과 도망갈 궁리를 같이 생각하고 있었다는 말이다. 나의 함께 커피숍에 가서 차한잔 하며 얘기하고 그다음엔 저녁을 먹던지 술을 한잔 하던지 하는 과정을 겁낸 것이다.


"그걸 왜 겁을내나?"라고 생각하는 사람도 있겠지만 예기치 못한 상황이 생기면 누구나 당황하고 경험이 적거나 없으면 떨리게 되어있다. 한번이라도 헌팅을 해본 사람이라면 처음 말걸기 전에 떨리는 마음을 느껴봤을 것이다.


자신에게 다가와준 남자와 같이 하고 싶은 일이지만 소심하고 경험도 없기 때문에 너무 당황한 나머지 도망갈 궁리도 같이 하고 있던차에 차가 아닌 맥주가 나오니 쿨하게 거부하고 도망갈 핑계가 생겼던 것이다.


그러나...


정말 차가 아닌 맥주한잔 하자는게 실례인가? 첫만남의 첫코스는 반드시 커피숍이여야만 하는가? 맥주한잔 하자고 하면 내가 자신을 취하게 해서 어떻게 할거라고 생각했는가? 맥주 한두잔에 취해서 인사불성이 될 정도로 술이 약한가? 술을 못마시는 당신에겐 술집은 금단의 장소인가? 술집에 가면 당신 앞에놓인 술잔은 반드시 비워야 하는가? 술먹자고 하는 남자는 모두 개날라리인가? 섹스가 목적인 남자는 전부 술부터 먹자고 하고 매너있고 자상하고 마음넓은 남자는 모두 차부터 마시자고 하는가? 그렇다면 섹스가 목적인 남자가 차를 마시자고 한다면 그남자는 매너있고 자상한 남자인가?


본좌가 싫어하는 장소중 하나가 커피숍이다. 먹는재미가 있기를 하나 맛있는 안주나 음식을 보는 재미가 있기를 하나...그냥 가서 돈만 버리고 나오는 곳이기 때문이다.


더 싫은건 정말 얘기만 해야 한다는 것이다. 친구끼리, 연인끼리 가면 할 얘기도 많고 어색하지도 않고 상대방의 눈치를 극심히 살펴야할 상황도 아닌것이다. 말없이 창밖만 봐도 괜찮은 상황인 것이다. 헌팅해서 처음 가면 어색하지 않게 호감을 사기 위해 주저리 주저리 얘기를 해야한다. 설마 처음만나 커피숍가서 분위기잡고 앉아만 있으면 상대가 반할거라고 생각하는 사람은 없겠지?


본좌의 최대장점중 하나가 사소한 특징이라도 부드럽거나 즐거운 대화로 이끌어 낸다는 것이다.


가벼운 예를들어 설명하겠다.


커피숍에 들어가서 주문하고 서로 통성명정도만 한 상태다. 상대방의 머리결을 보고 좋다고 해준다. 안좋아도 좋다고 해준다. 너무 않좋으면 얘기를 꺼지 마라. 머리카락은 쳐다 보지도 말라.


본좌 : "머리결이 참 예쁘시네요. 그런말 많이 듣죠?"

여자 : "어머..."라며 살짝 웃는다.

본좌 : "아까 지하철에서 볼때도 머리결이 너무 예쁘셔서 자꾸 눈이 가더라구요 ^^ "


여기서 잠깐, 예쁘다는 말에 기분좋지 않을 여자는 세상에 없다. 하지만 무턱대고 예쁘다라고 말하면 말은 고맙다고 하지만 이상하게 쳐다본다. 그런 경험을 해본적이 있을것이다. 왜그럴까? 진심처럼 보이지 않기 때문이다. 보자마자 무턱대고 예쁘다고 하면 정말 예뻐서 하는 소리가 아닌 겉치레로 들리기 때문이다.


본좌가 즐겨쓰는 방법은 대화로 상대방의 깍쟁이 같은 짓을 이끌어 내거나 약간 오버하게 만든다. 그럴때 "XX씨는 얼굴만 예쁘신줄 알았더니 말하는것도 깍쟁이시네요 ^^; 라고 하면 효과 만빵이다. 본좌가 즐겨쓰는 방법이니 따라하지 말기를 바란다. 단, 통하지 않는 상대가 있다. 그런여자 여럿봤다. 그런여자한테 쓰면 당신을 정신연령이 낮은 유치한 남자로 볼것이다. 본좌는 그런 경험이 몇번 있어서 몇마디 해보면 금방 감이 오기 때문에 실수는 하지 않는다. 대체로 산전수전 다겪었거나 세상을 진지하게 사는 여자들에겐 잘 통하지 않는다.


여자 : 고맙다고 말할수도 있고 그냥 웃을수도 있다. 자기 머리결이 어떻고 저떻고 얘기를 한

         다면 더 좋고. 고맙다고 하거나 웃는다고 가정하자.


본좌 : "난 머리가 반곱슬이라 어릴때부터 XX씨같은 예쁜 머리결을 많이 부러워했어요^^

          지금 생각해보면 웃음이 나지만 그땐 어린 마음에 난 왜 곱슬일까? 하는 고민도 많이

          했었어요^^ 근데 재미있는건 저같은 반곱슬은 생머리를 부러워하고 생머리는 저같은

          반곱슬을 부러워 한다는 거에요^^ 왜 내머리를 부러워하냐고 물어봤더니 넘기면 넘기

          는대로 잘 넘어가서 부러워한다고 하더라고요 ㅎㅎ. 근데 저같은 경우는 너무 잘넘

          어 가서 선풍기바람 5분만 맞으면 머리가 붕떠서 까치집이 생겨버려요 ㅎㅎ;          

          고등학교때 제 친구중에 정말 머리가 예술인 친구가 있었어요. 그친구는 원래 갈색머

          리인데요. 염색하면 머리결이 약간 상하잖아요. 근데 그친구는 원래 갈색이라 머리결

          이 굉장히 곱고 두께도 굵지도 않고 얇지도 않은 적당한 두께에 머리결이 어찌나 부드

          럽던지, 바람이 불어서 머리가 흩어지잖아요? 바람이 멈추면 손대지 않아도 처음 그상

          태로 돌아가는거에요. 머리카락이 아니라 실크에요 실크. 머리에 실크를 심은것 같은

          머리카락이에요. 누구나 부러워할 머리카락인데 정말 아이러니한건 그친구는 자기 머

          리를 끔찍히도 싫어한다는거에요. 누가 자기 머리카락이 좋다고 하면 인상부터 써요.왜

          그러냐면 아무리 넘겨도 넘어가질 않는거에요. 바람이 불었다 멈추면 손대지 않아도 그

          냥 제자리로 돌아가니까 넘겨봤자 도로아미타불인거에요. 고등학생이니 머리를 길러서

          스타일을 만들수도 없고 맨날 호섭이 머리를 하고 다녔어요 ㅎㅎㅎ. 호섭이 머리를 하

          더라도 난 그친구 같았으면 좋겠어요^^ 그러면 내 스타일을 어쩌구 저쩌구..."


처음 커피숍에 들어가서 이정도 얘기하면 10 이면 10 전부 어색한 분위기는 온데간데 없고 즐거운 분위기가 연출된다. 혼자 말하는것 처럼 썼지만 중간중간에 적당한 질문을 넣어가며 얘기하면 여자도 같이 즐긴다.


바로 이것이 나혼자가 아닌 상대와 내가 같이 즐거운 헌터의 대화술이다. 물론 본좌의 머린 반곱슬이며 귀찮으면 짧게 자르지만 스타일을 연출할땐 길러서 매직 또는 볼륨매직등을 한다.


머리뿐만이 아니라 손 피부 헤어스타일 이목구비 악세사리 직업 취미 모든것이 가능하다. 단, 상대가 특정부분에 전문적인 지식을 가지고 있다면 상대방에게 질문을 던져서 대화를 이끌어낸다.


다시 본론으로 돌아와서 본좌는 커피숍을 싫어하지만 약점은 아니다. 사실 위의 예는 술집에서 해도 괜찮지만 커피숍에서 해도 아주 좋은 대화이다. 즉 커피숍에 가더라도 충분히 대응할 수 있다는 것이다.


혹시라도 이글을 읽는 여성들, 당신들에게 그런 상황이 온다면, 헌팅시 남자가 당신에게 맥주한잔 하자고 했다면 어떻게 생각하겠는가? 한번 잘 생각해보기 바란다.


비교적 많은 남자들이 헌팅에 성공을 하면 커피숍을 간다. 본좌가 알기론 남자들은 처음만났던 자주 만나던 여자와 커피숍에 가기를 꺼려한다. 할수 없이 간다는 말이다. 왜? 첫 만남에서 여자들은 그걸 당연하게 생각하거나 즐기니까. 누군가와 커피숍에 앉아 있으면 자신이 뭔가를 즐기며 만끽하는 기분이 들어한다.


하지만 평소에도 커피숍을 자주 가진 않거니와 동성친구와 만나는 장소가 대부분 커피숍은 아닐것이다.


처음만난 남녀사이에 여자는 말을 아낀다. 아낀다기 보다는 말을 극도로 조심한다. 왜? 처음만난 남자앞에서의 말실수는 자신이 이상한 여자로 보여진다고 생각하기 때문이다.


여자들이 하기쉬운 착각중 하나가 뭐하나 잘못하면 얼굴이 새빨개져서 상대가 자신을 이상한 여자로 본다고 생각하는것이다.그럴수도 있겠지만 대부분의 남자는 그러한 상황에선 대수롭지 않게 넘기거나 귀여운 여자로 본다. 자신이 호감을 가지고 있는 여성의 사소한 실수는 애교로 보여지기 때문이다.


그래서 여자들은 말수가 적고, 얘기한다고 해도 남자보단 적게 말하게 된다. 말한다 해도 대부분 질문형식으로 한다. 왜? 그게 편하거든. 상대방의 말에 대한 피드백으로 질문만 던져주면 되니까. 물론 모든 여자가 그런것은 아니며 나보다 더 말 많이하는 유재석같은 여자도 본적있다.


그래서 여자는 말잘하는 남자를 좋아한다.


남자더러 말하라고 내버려 두고 자신은 속을 내비치지 않은채 간단한 질문만으로 얘기를 이어가고, 남자가 얘기를 잘해서 비교적 괜찮은 분위기가 됐다면 자신도 대화를 잘했다고 생각하기 때문이다. 남자가 얘기를 잘하지 못해서 어색한 분위기가 연출되면 100%남자탓이라고 생각한다. 하긴 자신은 헌팅을 당한 입장이니 남자가 모든걸 책임져야 한다고 생각한다면 할말 없다. 하지만 그렇게 생각하지 않고 자신도 대화에 적극적인 여자를 남자들은 어떻게 볼까? 반면 당신은 어떻게 볼까?


여자는 재미있게 얘기하지 못해도 괜찮다. 지루하더라도 적극적으로 얘기해 주는 것만으로도 남자는 큰 용기를 얻는다.


헌팅의 초짜들은 자신과 비교해서 만만한 여성을 목표로 삼는다.


자신이 서툴러도 자기생각에 괜찮을것 같고 쉬워보이는(모텔가기 쉬운 여자가 아니라 헌팅하고 얘기하기 편한 여성이라는 뜻이다)여성을 고르면 성공할것 같기 때문이다. 하지만 10중 8,9는 실패한다.


그건 여자를 몰라도 한참 모르기 때문이다. 좀더 구체적으로 설명한다면 옷도 추리하게 입고 남자는 한번도 못만나봤을법한 차림새의 여성에게 대쉬하면 여자 입장에선 남자는 한번도 경험이 없는데 이게 왠떡이냐 하고 덥썩 물것만 같은 느낌이 들기 때문이다. 그래서 만만한 여성을 목표로 하고 대쉬한다. 초짜의 경우이다.


그럼 위의 상황에서 헌팅에 성공했다고 가정해보자. 정말 남자는 여자를 쉽게 만만하게 생각하고 있을까?


"이게 무슨소리야? 만만한 여자를 골라서 헌팅했다고 했으면서 쉽게 만만하게 보는건 당연한거 아냐?" 라고 하겠지만 그렇지 않다.


만만한 여자를 목표로 골랐다고 해서 함부로 대한다는 뜻은 아니다. 즉, 아직 경험이나 용기가 부족해서 예쁜 여자는 목표로 삼을 생각도 못하고 비교적 자신이 보기에 성공하기 쉬울것같은 여자를 목표로 고른다는 뜻이다.


헌팅에 성공해도 소중히, 매너있게 대한다. 왜냐하면 헌팅에 나서기 전에 "만약 헌팅을 하면 무슨말을 건내고 승낙받으면 어디로 갈것이며 어떤 대화를 하고 어떻게 대해주면 호감을 살것인가?" 하는 계획이 대충 잡혀있기 때문이다. 즉, 아무리 추리한 여성이라 해도 헌팅에 성공하면 자신이 이미지한 계획에 따라 매너있게 잘 대해준다는 뜻이다.


남자가 만만한 여성을 목표로 골랐기 때문에 여자의 입장에선 자신에 비해 괜찮은 남자가 대쉬를 해오니 자기를 쉽게 보고 꼬신다고 생각하며 이경우엔 실패할 확률이 아주 높다. 이런 여자는 앞서 설명한 싸인을 주고받는 단계까지만을 즐기고 대쉬하면 바로 돌아서서 가버리는 여자일 경우가 많다. 또는 자신이 감당치 못할 상대라고 생각하고 피해버린다.


위와 같다면, 당신이 보기에 훌륭한 여성이 싸인을 보낼때도 있다. 정말 감당 안되게 훌륭한 여성이다. 이런 여성일 경우 어떤생각으로 당신에게 싸인을 보낼까?


남자는 만만한 여성을 목표로 삼지만 여성은 만만한 남자를 목표로 삼지 않는다. 자기수준에 맞거나 자기보다 잘났다고 판단될때 싸인을 보낸다. 이 차이를 잘 이해하고 있어야 한다.



다음 시간엔 지하철 헌팅요령을 이어서 하고, 여성의 입장에서 자신의 마음에 드는 남자가 자신에게 헌팅을 할때 대처방법을 실제 예를 들어 설명하겠다. 아울러 시간이 남는다면 헌터의 고급기술 순간캐치를 설명하겠다.


오늘은 설명하기에 앞서 본좌가 적은 40%의 성공률에 대해서 얘기해 보겠다.


위의 설명엔 10일동안 하루 한번씩 열번을 헌팅해서 4번을 성공한다고 적었다. 대충 맞는 계산이다. 하지만 말처럼 10일동안 하루 한번씩 한다는건 아니다.


꼭 하루 한번씩 헌팅을 한다면 지하철에서 지나쳐가는 여자들이 모두 목표일까? 당신이 여자들을 바라본다면 모든 여자가 좋든싫든 싸인을 보낼까? 물론 아닐것이다.


본좌도 지갑과 정신력이 허락하는 한 매일 헌팅하고 싶다. 하지만 본좌가 돈이 튀어서 맨날 먹고노는 놈팽이도 아니고 일을 해야 먹고산다. 그리고 나도 사람이다. 일에 치여서, 사람에 치여서, 사는것에 치여서 지칠때가 있다. 컨디션이 좋지 못하면 쉬어야 한다.


그렇다면 위의 설명처럼 40%란 성공률은 어떻게 나온 것인가? 헌터를 꿈꾸는 남자들, 또는 헌터까지는 아니어도 애인을 만들고 싶어하는 남자들은 이 확률이 나온 과정에 대해 진지하게 생각해 봐야한다.


헌팅은 카드게임처럼 확률의 게임이다. 기술의 숙련도보다 확률의 계산에서 나오는 선택이 성공을 좌우한다.


바로 이것이 헌팅의 달인이라고 해도 성공률이 50%를 넘지 못하는 이유이다. 기술의 숙련도만으로 성공확률이 좌우된다고 하면 본좌가 이렇게 구구절절이 설명할 필요는 없다. 어떤 여성이 보이거든 어떻게 해라라고만 하면 되니까.


아무리 기술이 좋아도 바람에 흔들리는 갈대처럼 시시각각 변하는 여자의 마음을 종잡을 수는 없다. 때문에 확률의 선택이 중요한 것이다. 시시각각 변하는 상황속에서 빠른 판단과 올바른 선택만이 성공확률을 높여준다.


앞서 설명에서 지하철 차량안의 여성의 위치에 따라 당신이 있어야할 위치, 보내는 시선, 말을 걸 타이밍에 대해 설명했다. 하지만 하다보면 시시각각 변하는 상황 속에서 순간적인 대응을 해야 할때가 있다. 이때 어떤 선택을 해야 성공할수 있겠는가?


지하철 승강장에서 괜찮은 두 여성을 발견했다. 두 여성중 어느쪽에 대쉬해야 성공확률이 높을까?


한 여성을 찍었다고 가정해 보자. 그 여성이 승강장에서 지하철을 기다린다고 했을때, 그 여자는 나같은 스타일을 좋아할까 별로라고 생각할까? 시선이 마주쳤을때 여자의 표정과 분위기, 행동을 보고 재빠른 판단을 해야한다.


마주친 시선이 싸인일수도 있고 아닐수도 있다. 확실하게 보내는 여자라면 판단이 확실히 서겠지만 애매하게 보낸다면 이여자를 목표로 삼을것인지 아닐것인지 선택을 해야한다.


목표로 삼는다면 접근하고 아니라면 다른 목표를 찾아야 하기 때문이다.


차량 안에선 어떤 방식으로 접근하여 당신에게 호감을 가지고 있다는 싸인을 보낼것인가? 차량 안에서 말을 걸것인가 내리길 기다려서 대쉬할 것인가? 다른 사람이 보고 있더라도 당당하게 오케이를 할 여자로 보이는가 아니면 가능한 부끄러운 상황을 피해서 대쉬해야 편안해할 여자로 보이는가? 쿨하게 대쉬해야 좋을 여자로 보이는가 당신에게 첫눈에 반했다는 진심을 얼굴에 담아 얘기해야 좋을 여자로 보이는가? 이여자는 내가 내릴 역 전에서 내릴것인가 다음에서 내릴 것인가? 내릴 역 전이라면 따라 내려야 하는가 그냥 보내야 하는가? 다음역이라면 기다려야 하는가 기다리지 말고 대쉬해야 하는가?


정말 저여자가 나에게 호감을 가지고 있는 것일까? 그냥 한번 쳐다본걸 싸인으로 오해한 것은 아닌가?  이도저도 아니라면 다른 목표를 찾아 대쉬하는게 좋을까? 모든것은 선택이며 당신의 몫이고 결과도 당신의 선택에서 비롯된다.


그렇다면 어떻게 해야 성공확률을 높일수 있을까?


성공확률을 높일수 있는 모범답안은 없다. 가능한 모든 상황을 경험하고, 그 경험에서 나온 지식을 깨달아 지혜로 발전시켜야 한다.


이것이야 말로 이 글을 써내려 가는 핵심이며 모든 남자의 로망이며 가장 어려운 것이며 설명하기도 어려운 것이다.


단순히 어떻게 해라, 용기를 가져라 라는 말을 쓰기 보다는 가능한 모든 경우의 수를 설명할려고 애쓰고 그와 함께 여자의 마음도 최대한 알기쉽게 설명할려고 노력했다.


헌팅은 수학공식이 아니기에 여자의 심리를 최대한 빠른 시간안에 최대한 정확하게 간파하는것이 성공확률을 높일수 있기 때문이다. 때문에 이글을 읽고 시도해 보려는 남자들은 열번 스무번 읽고 머리속에 이미지 트레이닝을 확실히 하기 바란다.


정말 찌질한 방법이지만 성공하든 못하든 횟수를 늘리면 성공확률이 점점 올라가긴 한다. 이건 본좌가 직접 해본 방법이다. 하지만 절대 권하고 싶지는 않다. 사람이 점점 찌질해지며 자신을 혐오하는 병증이 생기며 몸도 마음도 지쳐버린다.


그날 헌팅을 하겠다는 마음을 먹었다면 자신의 눈에 괜찮은 여성을 고르고 성공하기 위해 최선을 다하라. 그리고 대쉬할지 안할지 끝까지 선택의 기로에서 고민하고 갈등하며 대쉬하기로 마음먹었다면 최고의, 최상의 대쉬를 위해 긴장을 늦추지 말라. 떨리는 가슴을 겁내지 말고 즐겨라. 그리고 최고의 타이밍에 대쉬해라. 성공하면 그 기쁨을 만끽하며 즐기고 실패하면 왜 실패했는지 곱씹으며 한층 성장한 자신을 느껴라. 집에가서 푹쉬고 다음날 가뿐한 마음으로 아침을 맞이하라. 멋진 만남을 기대하며 그날도 집을 나서라.


생각보다 길어졌다. 저번시간에 하기로 한 설명은 다음시간에 하기로 한다.


저번시간에 하기로 한 지하철에서의 헌팅요령을 이어서 설명하겠다.


목표로 한 여자가 문 근처에 있을경우, 앉아있을경우에 대해 설명했다. 이번엔 좌석 앞, 손잡이를 잡고 서있을 경우에 대해 설명하겠다.


당연한 얘기지만 창문쪽을 보고있는 경우다. 옆에 서서 같이 창문을 바라보며 창문을 통해 시선을 보내는 것이 좋다. 이때도 앞서 설명한 것처럼 시선을 보내면 된다.


단, 서로 유리창으로 보면 이목구비는 보여도 눈동자가 안보여 자신을 보는것인지 아닌지를 판단하기 어려울 경우가 있다. 이때 자신도 모르게 눈을 똥그랗게 뜨고 뚫어져라 보게될수가 있는데 주의해라. 여자가 보기에 이상하게 느껴질수 있다. 얼굴 방향이 자신을 보고 있다면 눈동자가 보이지 않아도 자신을 보고 있다고 생각하고 시선을 보내라.


사람이 적다면 옆이나 한칸 떨어져서 시선을 보내면 되지만 사람이 많아서 옆에 설수 없는경우가 있다. 이럴땐 여자의 바로 뒤 약간 왼쪽이나 오른쪽에 선다.


남녀가 자연스러운 스킨쉽을 할때 여자들이 좋아하는 포지션이 몇가지 있는데 그중 하나가 뒤쪽에서 포근히 안아주는 것이다. 여자들은 남자의 넓은 품에 안겨 보호받기를 원하는 본능이 있다.


뒤에서 안는다면 대부분은 여자의 목아래 쇠골바로 밑부분에 남자의 팔이 감기게 되는데 등이 남자의 가슴에 안기고 팔로 감싸주면 여자는 포근함을 느끼고 편안해 한다. 남자의 가슴의 심박동을 등으로 느껴서 마음이 편해지고 자신을 감싼 남자의 팔이 자신을 보호해 준다고 느끼게 된다.


누워서 울며 보채던 아기가 엄마품에 안기면 울음을 그치고 편안히 잠들게 되는데 엄마의 심박동이 아기를 가장 편안한 상태로 만들어 주기 때문이다.


약간 왼쪽이나 오른쪽에 서는 이유는 당연하겠지만 시선을 주고받아야 하기 때문이다. 바로 뒤에 서서 뒤통수만 보며 숨만 거칠게 내쉰다면 여자는 성추행을 당한다고 생각할것이다. 바로 뒤에서 왼쪽이나 오른쪽으로 조금 비켜서야 한다.


조금 떨어진 곳에서 유리창을 통해 시선을 주고 받는다면 각도를 잘 봐야 한다. 유리창을 통해 당신이 볼수 있다면 여자도 당신을 볼수 있다. 어떤 경우든 유리창을 이용할땐 이점을 잊지말고 이용한다.


또다른 위치로는 문 양옆 기둥에 기대서 바라본다. 이땐 여자가 좌석 앞 손잡이를 잡고 있지만 좌우 끝에 위치할 경우다.


잘 보면 손잡이 들이 걸려있는 곳에 좌우 끝 손잡이들의 앞엔 유리창이 없다. 이땐 옆이나 뒤에 서봤자 시선을 주고 받을수 없다.고개를 90도로 돌려 쳐다보기 전엔 말이다. 유리창을 통해 볼려면 그만큼 떨어져서 봐야한다. 이것역시 각도계산에 의해 위치가 나온다.


설명을 읽어보면 별것도 아닌것으로 설명한다고 생각될수 있는데 절대 그렇지가 않다. 어쩌면 이게 더 중요하다. 한 차량에 50명의 여자가 탔고 30명의 여자가 서있다고 가정할때 3분의2정도는 손잡이를 잡고 서있는다. 앞서 길게 설명한 문앞의 위치보다 더 많은 기회가 있는 곳이다. 절대 흘려버릴 것이 아니다.


이번엔 헌팅을 당하는 여자로써의 대처방안을 설명하겠다.


왜 헌팅을 당하는 여자로써의 대처방안을 알아야 하는가 하면 아무리 달인이라도 성공확률이 50%를 넘지 못한다고 저번시간에 설명한 적이 있다.


호감가는 남자가 당신(이번 글에선 당신은 여자로 지칭하기로 한다)에게 싸인을 보냈다고 가정하자. 당신은 어떻게 하겠는가?


고개숙이고 다가와 주기만을 기다리겠는가? 아니면 싸인 몇번 보내고 기다리겠는가? 당신이 싸인만 보내면 남자가 다가와 준다는 보장이 있는가? 당신이 보낸 싸인이 남자에게 싸인으로 받아들여 진다는 보장이 있는가? 남자가 싸인으로 인식했다 해도 용기가 부족해 다가오지 못한다면? 용기가 있어도 주변 상황이 도저히 대쉬할수 없는 상황이라면? 당신이 싸인을 보냈음에도 불구하고 남자가 대쉬하지 못하고 끝나버린 상황에서 당신은 할만큼 했는데 남자가 다가오지 않았으므로 남자만 원망하겠는가?


다음에 또 이런 상황이 와도 마냥 대쉬해 주기를 기다리고만 있겠는가?


맘에 안드는 남자가 시선을 보내는 상황에서 어떻게 해야 대쉬를 하지 않게 만들수 있을까? 당신은 뭐 저런게 다있냐라고 생각하며 쳐다봤지만 남자쪽에서 싸인으로 받아들여 진다면?


시간이 늦었다. 다음시간에 설명하기로 하겠다.


덧글에 첫 멘트좀 가르쳐 달라고 한 사람이 있는데 본좌로선 안타까운 마음을 금할길이 없다.


백날 멘트 가르쳐줘 봤자 소용없다. 당신과 내가 다르고 서로 처한 상황이 다르고 여자가 다른데 같은 멘트 날려봤자 당신과 내가 같은 효과가 나올것이라 생각하는가?


헌팅의 성공확률을 높이는 모범답안은 없다라고 분명히 말했다. 당신이 생각하는 방법이 존재한다면 구구절절이 설명할 필요가 없다. 그냥 어떤 여자가 보이면 어떤 멘트 날려서 승낙받고 어디로 가서 무슨 음식을 시키고 어떤얘기를 하며 2차 3차 어디로 가서 어떻게 하라고만 적으면 된다.


당신이 원하는 멘트는 당신 머리속에 있다. 이글을 10번 20번 읽고, 읽으면서 본좌가 적은 글을 자신의 머리속에서 최대한 자세히 상황을 그려보라. 당신이 어느역에서 어떤 여자를 봤는데 어떻게 접근하고 어떤 방법으로 싸인을 보내며 어떤 멘트를 날릴까 하는 과정을 머리속에서 이미지로 만들어 트레이닝하라. 당신에게 가장 잘 맞는 적절한 멘트들이 자연스럽게 떠오를 것이다.


이미지 트레이닝의 효과는 놀랍다. 날 믿고 해보길 바란다.


일주일만의 업데이트인거 같다. 요즘 일이 많아서 신경을 못쓴점 양해해 주길 바란다. 여기서 일이란 헌팅이 아니라 회사일이다.


먼저 글 올린지 얼마 되지도 않았는데 방문자수가 400명을 돌파했다. 여러분의 관심과 성원에 깊이 감사하는 바이다.


그래서 하는 말인데 혹시 이런생각을 하는 사람이 있을지 모르겠다.


헌팅이라는 말의 의미를 생각해보자.


이 글에서 헌팅이란 여자에게 접근해서 전화번호를 받거나 커피숍등에 들어가는 것 까지만을 의미한다. 당신들이 헌팅에 성공해서 여자와 같이 어디든 들어간 후는 내 알바가 아니다. 그것까지 일일이 설명해줄순 없다.


솔직히 해줄 말은 있지만 이 글은 헌팅의 요령이지 꼬시기의 요령이 아니다. 꼬시는건 헌팅과 다르다. 즉, 위에서 설명 했지만 헌팅은 확률이고 꼬시는건 기술이다. 이 글을 쓰는 의미와 전혀 다른 것이다.


앞서 설명했지만 헌팅의 달인이라고 해도 확률이 50%를 넘지 못한다고 했다. 왜그럴까?

먼저 본좌의 헌팅방법을 얘기해 보겠다.


지하철에서 수많은 여자와 눈이 마주친다. 적당한 자리를 잡고 서있으면 전방시야에 있는 여자들이 눈에 들어온다. 여자들도 대부분 나를 한번이나 그 이상 쳐다본다.


본좌와 눈이 마주친 여자들의 행동엔 몇가지 패턴이 있다.


첫째 황급히 눈을(또는 고개를) 돌리는 여자,

둘째 2~3초 정도 시선을 마주치다가 시선을 돌리고 고개를 숙이는 여자,

셋째 얼굴에 당황한 기색이 확연한채 얼어붙어서 어쩔줄 모르고 계속 보고있는 여자,

넷째 뭔진 모르지만 뭔가 애절하게 부탁하는 표정으로 보는여자,

다섯째 아무관심 없다는 표정으로 고개를 돌리는 여자,

여섯째, 갑자기 섹쉬한 분위기를 연출하는 여자,

일곱째 나조차도 민망해질 정도로 계속 쳐다보고 있는여자,

여덟째 내 앞에 적당한 거리에 와서 내가 앞을 보면 자연히 보이는 곳에 있다가 다른곳을

          보며 가끔 고개를 돌려 나를 쳐다보는 여자,

아홉째 눈을 감는건 아니지만 살짝 감을듯 말듯하며 뭔가를 보내는 여자,

열번째 나를 보며 나에게 들리진 않지만 지나칠때 갑자기 얼굴 벌개지며 화를 내는 여자.


위의 패턴에서 헌팅할 여성을 선택할때 선호하는 패턴은 둘째, 셋째, 넷째, 여섯째, 일곱째, 여덟째 패턴을 선호한다. 이중에서 순위를 매긴다면 여덟째, 여섯째, 일곱째, 넷째, 셋째, 둘째 이다.


먼저 몇가지 패턴에 대한 본좌의 경험을 설명해 볼려고 했으나 잘난척 한다는 말 들을까봐 안하고 바로 순위에 매겨진 패턴들을 설명해 보겠다.


먼저 여덟째, 내앞에 적당한 거리에 와서 내가 앞을 보면 자연히 보이는 곳에 있다가 다른곳을 보며 가끔 고개를 돌려 나를 쳐다보는 여자이다.


아무리 추리한 여성이라도 이런 여자들한텐 본좌는 정성껏 매너있게 대해준다.


실제 예로 겜방에서 뚱뚱한 여성이 확실한 싸인을 보내길래 같이 저녁을 먹은 적이 있다. 이 여성은 솔직했기 때문이다.


대화에 솔직한것보다 자신이 어떤가를 떠나서 첫눈에 호감가는 남성에게 진솔한 싸인을 보냈고, 싸인을 받은 나로선 나에게 호감을 가져줘서 고맙기도 하고 어떤 여성인가 궁금하기도 해서 저녁을 같이 먹자고 대쉬한 것이다.


이런 여성들은 싸인이 확실하다. 적극적이며 좋은 성격에 자기 자신에 대한 열등감이 거의 없고 목소리가 예쁘며 자신의 처지를 떠나서 세상을 밝게 사는 여성들이다.


마주보며 대함에 있어서도 지극히 편안하며 조바심 내지않고 자신감이 넘치지만 거만하지 않으며 남자를(상대방을)배려하고 분위기를 잘맞추며 외모를 떠나 누가봐도 성격에 반할만한 여성들이다.


당연히 예외는 있을 것이나 여덟번째 경우는 지금까지 거의 모든 여성들이 그랬다. 몇년이 지났으나 얼굴과 이름을 모두 기억하고 있을정도로 멋진 여성들이었다.


이런 여성에게 처음 말을 걸땐 특별히 잘못을 하지 않는 한 성공한다. 그리고 소중히 진심을 다해 대해준다. 특별히 잘난것 없는 나에게 호감을 표시하고 처음본 사람임에도 상대방의 마음을 배려하고 편하게 해주는 이런 여성들을 만난다면 갑자기 세상이 아름답게 보일 정도다.


하지만 불행히도 이런 여성은 그리 많지 않다. 이러한 여성이 있다고 해도 나, 또는 당신들에게 싸인을 보내줄지도 불확실하다.


지금와서 생각해보면 헌팅을 하지 않던 시절에 이런 여성들을 가끔 본 기억이 난다. 그땐 몰랐지만 지금 생각해보면 그런 여성들을 알아채지 못하고 그냥 보낸게 내 자신이 한심하단 생각이 든다. 그러한 여성들을 보고는 헌팅을 할 결심을 하게 됐는지도 모르겠다.


이 글의 서두에서 말했지만 자신에게 적극적인 호감을 가져주는 여덟번째 경우의 여성과의 대화는 정말 행복하다. 단순히 즐기는 섹스는 이런 대화에 비할바가 아니다.


대화 자체가 자신을 변하게 만들고 변하는 자신은 모두 상대방을 위하게 만들며 세시간 네시간이 언제 지났는지도 모르게 대화에 빠져들고 아무말 없이 상대방의 눈만 봐도 자신의 진심이, 상대방의 진심이 서로에게 통하는 듯한 느낌이 들 정도다.


상상이 가는가? 당신들은 지금까지 여성과의 대화에서 이런 느낌을 가져본적이 있는가? 섹스가 하고 싶어서 꼬신 여성에게서는 이런 느낌은 절대 찾을수가 없다. 여성이 문제가 아니라 바로 당신의 생각이, 마음가짐이 문제인 것이다.


난잡한 섹스는 정신을 망치기 때문에 이런 느낌은 절대 느낄수 없다. 진심으로 서로를 사랑하는 상대방과의 섹스는 사랑을 10배 20배 증폭시켜 주지만 난잡한 섹스는 지겨움만을 더해가는 나락으로 빠져들 뿐이다.


상당수의 남성들이 여러여성과 같이 잔 남자들을 부러워한다. 절대 부러워할 필요 없다. 남자가 진심으로 사랑할 여성은 한명만으로 충분하고 넘친다. 오히려 모자라서 해주고 또 해줘도 부족해서 남자가 힘들어 할수도 있다.


하지만 걱정하지 마라. 본좌가 말하는 이러한 여성은 당신의 사랑을 모두 받아주고 어머니같이 포근히 감싸주며 힘들어할때 곁에 있어주고 당신이 이 엿같은 세상을 살아갈때 강한 힘이 되어준다.


이것이 제대로 된 이성을 갖춘 인간의 진정한 사랑이다. 이러한 사랑을 못해본 남자들은 사랑에 대해 논할 자격도 없다.


헌팅이라고 하면 남자는 바람둥이를 꿈꾸며 여러 여성을 농락하는 것으로 생각하고, 여성들은 바람둥이들이 자신을 가지고 놀다 버리려는 수단으로 생각한다. 실제로 그렇게 생각하고 있는 사람들이 대부분이다.


이러한 고정관념을 조금이라도 바꾸기 위함이 이 글을 쓰는 목적중 하나이다. 본좌의 진심이

이 글을 읽는 모든 남자들에게 조금이라도 전해졌으면 하는 바램이다.


주저리 주저리 말이 길었다. 오늘은 이만하고 내일 여섯번째 여성부터 다시 하기로 하겠다.


그리고 누가 지식인에 올라온 내글을 수정하는 방법좀 가르쳐 달라. 이 죽일놈의 무식 OTL


그럼 여섯번째 여성의 경우로 가보자. 갑자기 섹쉬한 분위기를 연출하는 여자이다.


갑자기 섹쉬한 분위기를 연출한다고 해서 모델포즈에 뒤를 살짝 돌아보며 혀를 낼름거리고 윙크를 한다는게 아니다. 분위기가 바뀌는 것이다.


사람에겐 분위기라는게 있고, 그것이 눈에는 보이지 않지만 아주 둔한 사람이나 전혀 예측을 못한 상황이 아니라면 누구나 느낄수 있다.


여자는 누구나 섹쉬본능을 가지고 있다. 밀리터리룩에 머리는 뒤로 질끈 묵고 슬리퍼 질질 끌고 다녀도 자신이 좋아하는 남성 앞에서는 섹쉬하고 싶어한다.


주로 하는 포즈는 남자가 잘 볼수 있는 곳에서 옆머리를 천천히 위로 쓸어올리는 포즈, 또는 대담한 여성이면 눈을 마주치고 당신만 느끼고 남들은 느낄수 없도록 아주 살짝 윙크를 하며 섹쉬한 표정을 보인다.


그리고 여자가 먼저 내린다면 문앞에서 다시한번 섹쉬하며 강렬한 싸인을 보내고 내린다. 따라오라는 표시다. 그대로 따라가서 대쉬하면 된다. 안따라가면 싸인을 보내준 여성에 대한 남자로써의 예의가 아니다.


지하철에서 내려서 대쉬할때의 유의사항을 다시한번 되새기며 대쉬한다. 두번째 순위인 만큼 성공률이 높은 편이다.


이런 여성들은 차가 아닌 바로 술집으로 가도 괜찮다. 이러한 여성들을 막보는게 아니라 대체로 성격이 솔직하고 화끈한 편이며 처음에 매너있게 대해주면 쉽게 마음을 여는 타입이다.


단, 조심해야 한다. 쉽게 마음을 연다고 해서 막논다는게 아니다. 여성이 마음을 열어도 당신은 끝까지 매너있게 대해야 한다. 성격이 솔직하고 화끈해서 한번 틀어지면 바로 차인다. 이런 여성들이 남자를 찰때 대체로 하는 생각은 "잘해줄때 잘해야지 감히 날 우습게봐? 니가 배가 불렀구나" 라고 한다.


한번 실순데 빌면 봐주겠지라는 생각으로 매달려 봤자 헛수고다. 의지가 확고한 편이기 때문에 영원히 아웃이다. 차라리 쿨하게 떠나라. 그럼 마지막 지푸라기같은 자존심이라도 지킬수 있다.


세번째로 나조차도 민망해질 정도로 계속 쳐다보고 있는 여자이다.


왜그런진 모르겠는데, 이런 여성은 결혼에 한번 실패한 여성일 경우가 많았다. 이혼 경력이 있고 애도 있는 경우도 있었다. 남편과는 이혼했거나 사별한 경우이고, 남편이 놈팽이라 같이 막나가자는 생각으로 하는 경우도 한번 있었다.


모습은 참 단정하고 단아하며 편안한 느낌이 든다. 정숙해 보이지만 고독함과 섹쉬함이 얼굴에 뭍어있다. 이런 여성들은 헌팅확률도 상당히 높고 조금만 잘해주면 무작정 따라온다. 잘만 구슬리면 모든걸 다 주고도 남을 여성들이다.


하지만 본좌가 외롭고 고독한 여성들 등쳐먹을리는 없지 않는가? 아무리 추리하고 아줌마라고 해도 처음 세네번은 꼭 내가 낸다. 물론 본좌는 어떤 여성도 등쳐먹지 않는다.


아줌마라고 해서 파마머리 아줌마를 떠올리면 곤란하다. 어엿한 직장 여성이며 나이는 20대 후반에서 30대 초반으로 미혼여성으로 보인다.


지하철에서 이런 여성과 눈이 마주치면 처음엔 관심없는척 고개를 돌려버린다. 하지만 계속 보고 있으면 다시 눈이 마주친다. 두세번 눈이 마주치면 그때부턴 계속 싸인을 보낸다. 싸인도 확실하고 적극적이며 다른 경우에 비해 아주 수월하다.


지금까지 살아온 당신의 인생이 여자들한테 수난만 받아온 세월이라면 이런 여성을 만나 위로를 받아보는것도 괜찮다.


네번째 여성은 나중에 설명하도록 하겠다.


다섯번째로 얼굴에 당황한 기색이 확연한채 얼어붙어서 어쩔줄 모르고 계속 보고있는 여자이다.


이런 여성들은 남자와 사귀어 본 경험이 많아야 한번, 없는 경우도 부지기수다. 즉, 자신의 이상형이지만 경험이 없어서 어떻게 할줄 몰라하는 타입이다.


성격은 바보스러울 정도로 착하고 솔직하며 귀도 얇아서 대체로 남들이 시키는대로 따라하는 타입이다. 솔직히 좀 골치아픈 타입이다. 이런 여성은 친해질때쯤 되도 좀처럼 마음을 열지 않는다. 걷다가 손이라도 한번 잡으면 바로 빼버린다.


주위의 여자나 친구들이 말하는 연예학상식을 귀동냥하고 그대로 믿어버리는 타입이므로 공주처럼 대해주지 않으면 경험도 없지만 바로 안좋은 연예공식을 적용하고는, 아직 차한두번 밖에 마시지 않은 사이지만 "저남자를 사랑해 버리면 난 가슴이 찢어질듯한 아픔을 겪게 될꺼야. 지금 헤어지는게 나와 저사람에게도 좋은 일일꺼야. 사랑하지만 저사람을 위해 떠나보내는거야. 안녕 내사랑~" 이래버리는 타입이다.


아주 짜증난다. 내가 가장 싫어하는 말중 하나가 짜증난다는 말인데 정말 짜증이 안날수가 없다. 별로 만나고 싶지 않은 타입이지만 세번째 순위인것은 헌팅성공률만은 높기 때문이다.


대체로 단정한 옷에 헤어스타일은 평범하고 화장은 옅으며 다른곳은 몰라도 눈은 동그랗고 입술은 예쁘다. 왜 그런진 모르겠는데 대체로 그렇게 생겼다.


위의 경우가 세번째 경우의 여성인데 혼동하기 쉽다. 싸인을 주고받는 단계까지만을 즐기고 대쉬하면 거절하고 내빼버리는 타입과 혼동하기 쉽다는 말이다. 즉, 만만해 보이는 타입인 것이다. 만만해 보인다는 말의 뜻은 위에서 설명했다.


확실히 구분하기 위한 방법은 느낌으로 알수밖에 없지만 그나마 한가지 구분점을 말해준다면, 싸인을 보내는 방식이다. 대쉬하면 내빼는 여자는 힐끔힐끔 쳐다보면서 눈이 마주칠라 치면 시선을 돌리며(주로 바닥을 본다)고개를 앞으로 하고 모른척 한다.


세번째 여성은 초롱초롱한 눈망울과(느낌이 꼭 캔디같다)비운의 드라마 여주인공같은 표정으로 하염없이 바라본다.


이런 여성에게 키스하면 별 반응이 없다. 아무 느낌 없다는 표정으로 본다는게 아니라 처음부터 끝까지 살짝 놀란 표정으로 계속있다.


워낙에 순진해서 감정이 들어오고 나가는 입구를 모두 차단해버린다. 어찌할줄 몰라서 감정의 문을 열고 느끼면 자신이 감당해버릴수 없다고 생각하고는 처음부터 끝까지 감정의 기복이 거의 없으며 표정의 변화또한 거의 없다. 처음 만난날 키스를 해도 하는 순간엔 얼어서 가만히 있다가 하고 나서야 어찌할지 생각하는 타입이다.


이런 여성을 보거든, 상처받지 않게 해줄 자신 있으면 대쉬하고 아니면 하지말라. 쳐다 보지도 말라. 여자눈에 눈물흐르게 하면 당신눈에선 개피쏟아질 날이 온다. 순진하고 마음여린 여자 가지고 놀다간 제대로 인생 조지는 날이 올것이다. 하지 말랄때 하지 마라. 헌팅의 선배로서의 경고다.


마지막으로 두번째경우인 2~3초 정도 시선을 마주치다가 시선을 돌리고 고개를 숙이는 여자는 다음시간에 설명하도록 하겠다.


덧글에 헌팅실패 후 이글에 감사한 마음이 드는 사람에 대한 얘기를 짧막하게 할까한다.


여자는 절대 헌팅하지 않는다. 주구장창 싸인만 보낼뿐 절대 먼저 대쉬하지 않는다.


여자의 자존심으로써 절대 용납할수 없는 일이기 때문이다. 마음으로는 원하는 남자가 나타났지만 실패했을때 그 무안함과 민망함과 실망감 창피함 후회와 자신에 대한 혐오가 물밀듯이 밀려온다는것을 겪어보지 않아도 여자로써 본능적으로 알기 때문이다.


그래서 여자들은 남자가 나타났을때 열심히 싸인을 보낸다. 자신을 봐달라고, 난 당신에게 호감을 가지고 있다고, 나에게 다가와 말을 걸어 달라고 싸인을 보낸다. 대부분 이조차도 제대로 못하는 여성들이 부지기수다.


확실한 싸인을 보내주는 여성들이 거의 없다는 말이다. 그래서 헌팅이 어려운 것이다. 대쉬하면 응해줄 준비가 되있는 여자와 호감은 있지만 떨려서 도망치는 여자가 헷갈려서 가려내기가 어렵기 때문이다. 때문에 헌팅을 할려는 남자들은 보는 눈을 길러야 한다. 이것이 헌터의 눈이다.


확실한 싸인을 보내주는 여성들은 대쉬하면 대부분 응해준다. 하지만 싸인을 보내긴 보내는데 어설프고 제대로 보내지 못하는 여성들은 성공률이 반 이하이다. 호감을 가지고 보내긴 하지만 어설프고 경험도 없기 때문에 막상 남자가 다가오면 떨리는 감정을 주체 못하고 도망쳐 버린다.


떨리는건 남자도 마찬가지다. 아직 본좌도 초짜때만큼은 아니지만 "OK 저여자다. 대쉬하자"라고 마음먹고 곁에 다가가면 살짝 떨리는 마음이 생긴다.


본좌도 이런데 이제 막 시작하는 남자들은 어떻겠는가? 무척 떨리는 마음을 다잡고 여성에게 가서 대쉬하는 것이다.


실패하면 무척 상심한다. 남자니까 아무렇지도 않을 것이라고 생각한다면 크나큰 착각이다. 큰용기를 가지고 간절한 마음으로 대쉬하는 것이며 실패했을땐 그날 내네 기분이 가라앉아있을 수도 있다.


눈에 들어오는 여성을 목표로 삼고 대쉬를 한다고 하니까 되면 좋고 아니면 그만이라는 생각을 가지고 헌팅하는게 아니다. 꼭 성공하길 바라는 간절한 마음으로 말을 거는 것이며 실패했을때 느끼는 실망감과 상실감은 크다.


싸인을 열심히 주고받는 척 하고 내빼버리는 여자에 대한, 치부라고 생각될 정도의 적나라한 글을 쓸수도 있지만 쓰지 않겠다. 그래도 여자라고 배려해 주는 것이다.


덧글에 실패했다는 분. 다시 같은 경험을 겪고 싶지 않다면 다신 헌팅을 하지말라. 그래도 꼭 해야겠다면 이글을 열번 스무번 읽고 마음을 다잡아 다시 시도해 보기 바란다. 더욱 준비된 모습으로 대쉬하여 꼭 성공하길 바란다.






오늘로 마지막 글이 될것 같다.


이글을 블로그에 쓰며 지식인에도 올렸었는데, 올라온 덧글들을 보니 절실히 공감하는 사람도 있었고 쓰레기 글이라는 사람도 있었다.


이제 글은 그만 쓰겠다. 영자한테 지식인에 올린 글을 지워달라고 요청했으며 늦어도 일요일까진 지워질것 같다.


위에서 설명했지만 길을가다 이상형의 여자를 발견하고 떨리는 가슴을 다잡으며 간절한 마음으로 대쉬하였으나 실패할 경우가 있다. 성공보다 실패가 압도적으로 많을 것이다.


본좌라고 예외는 아니다. 40%의 성공률은 단순계산이 10명중 4명이라는 것이지 한달을 기준으로 볼때 10번을 대쉬해서 다 실패할때도 있으며 40%를 상회할 경우도 있다.


실패했을때 허탈감과 공허함, 참담함은 이루말할수 없다. 다만 본좌는 그런 경험이 많기 때문에 바로 돌아서서 가던길 가지만 경험이 거의 없는, 또는 처음 해본 사람들은 그 허탈감과 후회는 클것이다.


헌팅에 실패한 사람들의 마음을 조금이라도 달래주고 용기를 주며 여성들에게도 뜻밖에 만난 자신의 이상형 또는 호감형을 좋은 인연으로 만들어 가길 바라는 마음에서 이글을 써왔지만 많은 사람들에게 본좌의 진심이 통하지 못한것 같다.


본좌의 글에 공감하는 사람들에겐 안타깝지만 애꿎은 소리 들어가며 이글을 써내려갈 이유는 없다.


싸이에 얼굴을 공개해 달라는 사람들이 있는데, 혹시라도 헌팅을 자주하거나 할 예정인 사람은 절대 공개하지 마라. 헌터는 얼굴 팔리면 끝장이다.


이 블로그도 지우거나 폐쇄해야 하겠지만 본 블로그에 이웃을 신청한 사람이나 공감해주고 응원까지 해준 분들이 있어 블로그는 그대로 두겠다.


종종 쪽지로 질문을 해온 사람이 몇 있었고 400자밖에 적질 못하길 때문에 부족하지만 압축해서 글을 적어서 보내주기도 했다. 앞으론 쪽지나 메일도 보내지 않겠다.


마지막으로 한마디 하자면 본좌는 어릴적 난잡한 생활로 인생을 망쳤던 사람이다. 지금까지 살면서 가장 후회되는것 세가지중 하나가 난잡한 생활을 한 것이다.


누누히 말하지만 난잡한 섹스는 정신을 썩게 만든다. 썩어버린 정신은 육체또한 썩게 만든다. 본좌도 겉으론 멀쩡하지만 속병을 앓아서 계속 약을 먹고 있다. 부모님이 끼니 거르지 말아라 속으로 곪는다라는 말은 사실이다. 절대 끼니는 거르지 말라. 여관갈 돈밖에 없다면 여관가지말고 끼니를 챙겨먹어라. 술을 많이 먹었다면 살이 조금 찌더라도 끼니를 꼭 챙겨 먹어라.


참고로 술을 잘먹는 법을 공개하겠다.


술먹기 전에 반드시 배를 채워라.


먹기전에 집에서 먹고 나가도 좋으나, 제일 좋은건 술집 들어가기 전에 앞에 포장마차에서 순대나 김밥들을 넉넉히 먹고 바로 들어가서 술을 먹는게 제일 좋다. 떡볶이는 먹지마라. 매운데 술까지 마시면 속을 버린다.


술집에 들어가서 처음엔 술을 천천히 마셔라.


마치 운동선수가 가볍게 뛰면서 워밍업을 하듯이 위를 술에 적응시켜야 한다. 천천히 마시면서 아주 약간 취기가 돌면 그때부터 맘대로 마셔라. 맘대로 마셔도 배가불러 많이 먹을수 없다. 마시고 노는사이 배가 점점 꺼지면서 술이 더 들어가니 술못먹는다고 걱정은 마라.


이렇게만 하면 아무리 많이 마셔도 죽거나 술자리에서 토하진 않는다. 술도 늦게 취하며 다음날 숙취가 덜하고 해장국을 먹었을때 술이 빨리 깬다.


살찐다고 걱정하며 배도 안채우고 들어가서는 안주도 안먹고 소주마시고 맹물로 안주를 대신하는 여자들이 있는데, 살찔까봐 걱정하면 술은 왜 마시냐. 가는날까지 건강하게 살다가고 싶으면 시키는데로 해라.


남자도 그렇지만 많은수의 여자들이 자신의 매력을 제대로 알지 못한다.


본좌가 보기에 백옥같은 피부에 아름다운 얼굴선을 가지고 있으면서도 옷을 추리하게 입었다면 이여자는 헌팅실패확률 90%이상이다.


자신의 매력을 제대로 알지 못하고 있으며 자신은 세상을 진지하게 살기때문에 화장은 기초만 하고 머리는 대충 묶고 다니며 옷은 살만 가리면 된다고 생각하는 여성들일 수도 있고, 꾸미는 법을 몰라서 그럴수도 있으며, 자신은 매력이 없으니 꾸며봤자 소용없을 것이라고 생각하고는 아예 해보지도 않는 여성들일수도 있고, 꾸미는것 자체를 모르는 여성도 있다.


하지만 본좌가 보기에 정말 못생긴 여성은 지금껏 거의 보질 못했다. 나머진 이상한 패션을 한다거나 잘 꾸미질 못하는 여성들이었다.


당신들도 최고는 아니지만 충분히 예쁘고, 예뻐질수 있으며 다른 여자들처럼 행복해질 수 있다.


이와같은 이유로 헌팅을 당하는 여성으로서의 자세를 설명할려고 했는데, 하지 못하고 끝을 맺게 됐다.


대충 생각해보면 지금까지 본좌가 적을려고 했던 글중에 1/3정도 쓴것 같다. 지금까지 정독해준 여러분에게 감사의 뜻을 전하며 모두 바라는 이성과의 인연을 만들수 있길 바란다.

2007/10/05 14:40 2007/10/05 14:40
이 글에는 트랙백을 보낼 수 없습니다
Linux/NetWork  2007/10/01 11:18

OSI(Open Systems Interconnection) 계층 구조는 7계층으로 되어있다.


1. Physical (=물리 계층)

 -상위 계층에서 내려온 비트들을 전송 매체를 통하여 어떤 전기적 신호로 전송할 것인가    을 담당.

2. Data Link (=데이터 링크 계층)

-신호수준의 데이터 비트들이 물리계층을 통과하면 데이터블록을 형성하는데, 이 데이터 블   록에 대한 전송을 담당

-인접한 개방형 시스템 간에 발생하는 다음과 같은 문제를 담당.

  ① 데이터 블록의 시작과 끝을 인식하는 동기화 문제

  ② 발생된 오류를 검출하고 복원하는 오류문제

  ③ 혼선 제어문제

3. Network (=네트워크 계층)

- 송신측과 수신측 사이에 보이지 않는 논리적인 링크를 구성

- 데이터를 패킷(packet)단위로 분할하여 전송한 후 조립함

- 패킷 전송의 최적의 경로를 찾아주는 라우팅 기능 제공

4. Transport (=전송 계층)

- 사용자와 사용자, 컴퓨터와 컴퓨터 간에 연결을 확립하고 유지

- 송수신 시스템간의 논리적인 안정과 균일한 서비스 제공

- 세션 계층에서 넘어온 데이터를 세그먼트(segment) 단위로 분할하고 번호를 붙임

- 오류 검출 코드를 추가하고 통신 흐름 제어를 제공

5. Session (=세션 계층)

- 세션을 확립하여 순차적인 대화의 흐름이 원활하게 이루어지도록 동기화 기능 제공

- 데이터 전송 방향 결정

*session : 사용자가 접속 중인 응용 프로그램을 한 쌍으로 연결하는 작업

6. Presentation (=표현 계층)

- 데이터를 표현하는 방식을 다루는 계층

- 데이터의 안정성을 높이기 위해 데이터 압축이나, 데이터 암호화 기능 제공

- 상이한 데이터 표현을 서로 가능케 하는 표준인터페이스 제공

7. Application (=응용 계층)

- 사용자의 응용 PㆍG(Program)이 네트워크 환경에 접근하는 창구역할을 하는 최상위 계    층


OSI 7계층모델 [7layer-model for OSI]-장점

 1. 네트워크 통신이 훨씬 단순하고 작은 부분들로 나뉨

 2. 네트워크 구성요소를 표준화 함 으로써 호환성 증대

 3. 서로 다른 유형의 네트워크 하드웨어나 소프트웨어 간의 통신이 가능

 4. 한 계층을 변경해도 다른 계층에 영향을 미치지 않기 때문에 개발 속도 증대

 5. 네트워크 통신을 여러 작은 요소로 분리함으로써 통신과정을 쉽게 학습가능


OSI 7 Layer의 기능 - 계층 기능

1. APPLICATION

- 전자우편 및 네트워크 유틸리티가 존재하는 계층

2. PRESENTATION

- 애플리케이션이 네트워크로 들어가는 방법

- 네트워크상에서 데이타를 전송하기위해 생산되고 소비되는 데이터의 형태를 번역하는

  방법 정의.

3. SESSION

- 애플리케이션에 대해 Transport Layer에 개념적인 Interface를 제공하는 계층

- 장비들이 네트워크 주소 대신 NAME으로 인식되도록 해준다.

4. TRANSPORT

- 네트워크상에서 물리적인 Location을 Address하는 방법과 노드간의 연결을 확립하고

  끊는 방법 정의

5. NETWORK

- 패켓 들이 어떻게 네트워크상에서 ROUTER되는지 정의

- 네트워크상의 노드에 전송되는 패켓 흐름을 통제하고

- 상태 메시지 가 네트워크상에서 어떻게 노드로 전송되는가를 정의

6. PHYSICAL

- 기계적인 측면(케이블, LAN카드)과 전기적인 측면(전압, 신호를 변조하는 기술)을 포함한

  컴퓨터와 네트워크 사이의 물리적인 연결정의

- 네트워크 토플로지 정의

7. DATA LINK

- 컴퓨터가 메세지를 주고 받기위한 프로토콜 정의


위의 7계층이 이해가 안 되는 경우는 그냥 어플리케이션층, 프로토콜층, 물리층으로 이해하면 편하다. 실제로 랜카드에는 1,2 층이 탑재되어 있고 프로토콜에는 3,4 층이, 웹브라우져 등 에는 5,6,7 층이 탑재되어 있다.


실제 ISO 7 계층을 만든 이유 중 하나는 전 세계 사람이 공용하여 쓸 수 있는 공짜의, 공개된 프로토콜을 만들기 위한 것도 있었다. 그러나 7 계층이 발표된 시점에 이미 많은 프로토콜이 사용되고 있었고 특히 WAN에서는TCP/IP가 표준으로 자리 잡아 독보적인 위치를 확보하고 있었다. 그 이후, 1계층과 2계층에서는 Ethernet이, 3계층과 4계층에서는 TCP/IP, NetBUEI, IPX등이 업계표준으로 자리 잡게 되었다.


OSI 7계층에 따른 프로토콜(OSI 프로토콜)이 교과서 같은 곳에 소개되다가 차세대 시리얼 버스 규격인 IEEE1394에 사용되고 있다. 5,6,7계층은 따로 따로 구현되기보다 통합되어 여러 가지 '서비스'라는 이름으로 제공된다. Telnet, FTP, e-mail(SMTP, POP), News(NNTP), NetBIOS 등이 이 서비스 층에 해당된다.


PS :  본인은 -_- 이거 잘모른다 걍 개념만 잡으면 되지 ;; 구체적으로 알필요는 없다
실무에서 자연스럽게 알게 될테니..


- 출처: 프로젝트 “cafe.daum.net/vlan”

2007/10/01 11:18 2007/10/01 11:18
이 글에는 트랙백을 보낼 수 없습니다

출처 :

http://comeng.andong.ac.kr/%7Echi23/bbs/view.php?id=downdoli_db&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=hit&desc=desc&no=2

 

보통 my-sql에서는 PK로 잡고 auto-increment를 많이 사용하는데
이를 오라클 DB로 마이그레이션 하면서 다음과 같이 한다.....

원본 my-sql 쿼리:
select no, gno, ono, nested, id, name, title, registerDate, readno ]
from tableName
order by gno desc, ono asc limit 0, 15

오라클로 변환된 쿼리
select *
from (select a.*,rownum rnum from
(select * from table_notice order by gno desc, ono asc) a)
where rnum >  페이지당 리스트 수* ( 원하는페이지 번호 - 1) and rownum <= 페이지당 리스트 수

rownum으로 번호를 매기는 것이 order by보다 우선 순위가 높단다.
그리고 위의 방식 말고도 인덱스를 이용한 방법도 있는데..

뭐 이것도 쓸만하지만 더 쓸만한건 ;;;; 내가 품고 이찌롱 ^_^

2007/09/27 17:41 2007/09/27 17:41
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > The Secret To Success Is To Never Give Up
원본 http://blog.naver.com/nkmin80/140032103146

※ 인덱스란?

  인덱스는 테이블이나 클러스트에서 쓰여지는 선택적인 객체로서,
오라클 데이터베이스 테이블내의
원하는 레코드를 빠르게 찾아갈 수 있도록 만들어진 데이터 구조
입니다.  

자동 인덱스 : 프라이머리 키 또는 uinque 제한 규칙에 의해 자동적으로 생성되는 인덱스 입니다.

수동 인덱스 : CREATE INDEX 명령을 실행해서 만드는 인덱스들 입니다.  

※  Index를 생성하는 것이 좋은 Column

WHERE절이나 join조건 안에서 자주 사용되는 컬럼
null 값이 많이 포함되어 있는 컬럼
WHERE절이나 join조건에서 자주 사용되는 두 개이상의 컬럼들


※  다음과 같은 경우에는 index 생성이 불필요 합니다.
table이 작을 때
테이블이 자주 갱신될 때

※  오라클 인덱스는 B-tree(binary search tree)에 대한 원리를 기반으로 하고 있습니다.

  B-tree인덱스는 컬럼안에 독특한 데이터가 많을 때 가장 좋은 효과를 냅니다.

이 알고리즘 원리는

 ① 주어진 값을 리스트의 중간점에 있는 값과 비교합니다.    
     만약 그 값이 더 크면 리스트의 아래쪽 반을 버립니다.
     만약 그 값이 더 작다면 위쪽 반을 버립니다.

 ② 하나의 값이 발견될 때 까지 또는 리스트가 끝날 때까지 그와 같은 작업을 다른 반쪽에도
     반복합니다.



 ※  인덱스는 B-tree 구조를 가지며 크게 다음 네 가지로 분류될수 있습니다.


Bitmap 인덱스

  비트맵 인덱스는 각 컬럼에 대해 적은 개수의 독특한 값이 있을 경우에 가장 잘 작동합니다.
  그러므로 비트맵 인덱스는 B-tree 인덱스가 사용되지 않을 경우에서 성능을 향상 시킵니다.
  테이블이 매우 크거나 수정/변경이 잘 일어나지 않는 경우에 사용할수 있습니다.

SQL>CREATE BITMAP INDEX emp_deptno_indx
        ON emp(deptno);


Unique 인덱스

  Unique 인덱스는 인덱스를 사용한 컬럼의 중복값들을 포함하지 않고 사용할 수 있는 장점이 있습니다.
  프라이머리키 와 Unique 제약 조건시 생성되는 인덱스는 Unique 인덱스입니다.

SQL>CREATE UNIQUE INDEX emp_ename_indx
        ON  emp(ename);


Non-Unique 인덱스

   Non-Unique 인덱스는 인덱스를 사용한 컬럼에 중복 데이터 값을 가질수 있습니다.

SQL>CREATE INDEX  dept_dname_indx
        ON  dept(dname);


결합 (Concatenated(=Composite)) 인덱스

   복수개의 컬럼에 생성할 수 있으며 복수키 인덱스가 가질수 있는 최대 컬럼값은 16개입니다

SQL>CREATE UNIQUE INDEX emp_empno_ename_indx
        ON  emp(empno, ename);


※  인덱스의 삭제

 
 - 인덱스의 구조는 테이블과 독립적이므로 인덱스의 삭제는 테이블의 데이터에는 아무런 영향도 미치지
않습니다.

 - 인덱스를 삭제하려면 INDEX의 소유자이거나 DROP ANY INDEX권한
을 가지고 있어야 합니다.


 - INDEX는 ALTER를 할 수 없습니다.


SQL>DROP INDEX emp_empno_ename_indx ;


※  인덱스에 대한 정보는 USER_INDEXES 뷰 또는 USER_IND_COLUMNS뷰를 통해 검색할 수
      있습니다.

※ 인덱스 생성

 

Oralce 9i에서 인덱스는 Primary Key와 Unique Key와는 별도로 CREATE TABLE의 USING INDEX CREATE INDEX 문법을 이용해서 정의하는 것이 가능해 졌습니다.


아마도 대부분의 사용자들은 다음과 같은 방식을 알고 계실텐데…

예제를 보시면서 어떤 것이 바뀌었는지 확인토록 해보세요~~

SQL> create table test (
 c1 varchar2(4) not null,
 c2 number(10)  not null,
 constrint pk_test primary key(c1) using index );


테이블이 생성되었습니다.


위의 create table문은 pk_test라는 이름을 가지는 primary key 제약 조건을 만들며 아울러 pk_test라는 이름을 가진 인덱스를 만듭니다. 이 두가지는 user_ind_colums 뷰와 user_constraints 뷰에서 table_name = ‘TEST’라는 조건을 주시면 확인이 가능합니다.

그러나 9i이후에서는 인덱스에 대해 명시적으로 이름을 주는 것이 가능해 졌는데…

우선 아래의 예제를 참고 하도록 하죠…


SQL> create table test (

 c1 varchar2(4) not null,
 c2 number(7),
 constraint pk_test primary key(c1)
 using index
 (create index idx_test_c1 on test(c1))
 );


테이블이 생성되었습니다.

이 경우는 테이블을 만들면서 primary key를 만드는데 (원래는 default로 pk를 만들게 되면 그 컬럼으로 인덱스를 만듭니다.) 인덱스의 이름은 primary key 이름과 다르게 주기 위해 using index 구안에 create index문을 이용해서 인덱스를 생성했습니다.


--------------------------------------------------------------------
아래의 SQL문중 하나를 이용해 인덱스는 놔두고 PK만 삭제할 수 있습니다.
--------------------------------------------------------------------

SQL> alter table test drop primary key keep index;


테이블이 변경되었습니다.


또는


SQL> alter table test drop constraint pk_test;


테이블이 변경되었습니다.

2007/09/25 13:59 2007/09/25 13:59
이 글에는 트랙백을 보낼 수 없습니다
기타  2007/08/19 02:48
 

변한건 오직 너의 사랑뿐이었다.

너를 처음만났던 이자리도 그대로였고
너와 첫 데이트를 했던 이자리도 그대로였고
너와함께 웃으며 즐거워했던 이자리도 그대로였고
니가 너무 보고싶어 달려갔던 이자리도 그대로였다.
그리고, 너하나만 바라보는 내마음도 그대로였다.

이자리도, 내마음도 그대로인데


변한건 너의 사랑 하나뿐이었다...

2007/08/19 02:48 2007/08/19 02:48
이 글에는 트랙백을 보낼 수 없습니다
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2025/04   »
    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      
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)