토요일, 1월 30, 2010

일기 (2010.01.30)

오늘 모처럼 바람도 쐴겸 장을 보러 킴스클럽에 갔다.
장이라고 해봐야 그냥 먹고 싶은것 사러 가는 것이다.

나도 이제 나이를 먹었는지 마트에서 연인 또는 부부끼리 장을 보다
잠시 먹거리를 먹는 모습을 볼 땐 괜히 옆이 허전하다.
"나도 여친 있으면 장도 보면서 맛있는 것도 먹고 할텐데" 라고 속으로 생각만 하며
맛나는 것 많이 사서 집에가서 먹자라고 마음을 먹고 쇼핑을 한다... -_-;;;

나 혼자 착각일지도 모르지만 이젠 외롭다... ㅠ.ㅠ
노력이라기 보단... 음.. 노력이 맞겠구나...
잘 어울려야 하는데 그저 나 밖에 모르니...

난 혼자 명상을 하거나 산책을 하거나, 혼자 하는게 참 좋다.
하지만 혼자 하는게 정말 싫은 것도 너무 많다...
이래서 늘 혼자서 보내다 보니 옆에 누가 없는게 정상인것 같다.
그래도 내가 그 사람이 좋다고 해서 나랑 사귀자고 할수는 없잖아...

태어나서 미팅은 처음 해봤지만 아무래도 서로 다른 생활을 하던
사람끼리 만나니 어색하기도 하고, 많이 불편해서 얘기도 잘 못하고... 음...

아... 외롭다. 이젠 혼자서 밥 먹는 것도 싫고,
황금 같은 금요일 저녁, 퇴근 후 다들 누군가를 만나러 갈 때
나 혼자서 서점에서 이런저런 책이나 보다 썰렁한 집에가고... 에휴...궁상 맞다.

오늘 사다놓은 "새우 캘리포니아 롤" 을 내일 먹을 생각하니 기분이 좋아진다.
헤헤... 고거 참 맛나겠다. ^^

-----
Cheers,
June

금요일, 1월 29, 2010

Qualcomm BMP (Brew Mobile Platform)

Qualcomm Brew Mobile Platform (BMP)

Source:
http://www.qualcomm.com/products_services/developer_network.html
https://brewmobileplatform.qualcomm.com/devnet/index.jsp

Download page
https://brewmobileplatform.qualcomm.com/devnet/multiplatform_sdk.jsp




Setup for C/C++ Environment – Visual Studio

Procedure for Brew MP C/C++ development environment with one or more versions of Microsoft Visual Studio and Microsoft Windows XP or Vista (UAC disabled):

Prerequisites:

1. Microsoft .NET Framework 3.5 SP1 (or newer).
http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en
2. Adobe Flash® Player 10 ActiveX (or newer). Important: download and install the Adobe Flash Player using Internet Explorer browser for ActiveX version.
http://get.adobe.com/flashplayer/
3. Microsoft Visual Studio 2005 or 2008. To enable the Brew MP API code completion feature in Visual Studio 2005, install  Microsoft Visual Studio 2005 IDE Enhancements.
http://www.microsoft.com/visualstudio/
http://www.microsoft.com/downloads/details.aspx?FamilyID=CD7C6E48-E41B-48E3-881E-A0E6E97F9534&displaylang=en


Installation Procedure - For best results, follow the steps in the order specified:

1. Download & install Sourcery G++ Lite Edition. This includes a CodeSourcery ARM compiler and GNU tools to help build and debug applications.
http://www.codesourcery.com/sgpp/lite/arm/portal/release1033
2. Download & install Brew MP Multiplatform SDK.
http://brewmpsdk.qualcomm.com/BREWMPSDKMP.exe
3. Install Brew MP SDK Visual Studio Plugin through the SDK Manager tool (on Setup tab, click the Visual Studio Plugin Install link located within the current toolset).

To get started, please refer to the Brew MP C Visual Studio Primer.
https://brewmobileplatform.qualcomm.com/devnet/prod/resources/devEx/library/primers/c/C_VS/PDF/c_visual_studio_primer.pdf


[Tip]
* Brew 2.x Problem Analysis
http://www.eetasia.com/ARTICLES/2007AUG/PDF/EEOL_2007AUG10_DSP_EMS_AN.pdf?SOURCES=DOWNLOAD


-----
Cheers,
June

일기 (2010.01.28)

오늘 MBC "뉴스후+" 를 보았다.

그 중, 강제징용에 대한 section 을 보았는데 정말 우리나라 정부의 한심함과 무지함의 극치를 보는 듯 했다.
과연 국회에서 정치인들은 뭘 하고 있는지...
세상에, 우리나라에서 발에 땀 나도록 과거사에 대해 조사를 하고 일본에 문제점을 지적과 요구를 해야 하는데,
우리나라 사람도 아닌 일본인들이 나서서 진상규명에 대해 조사를 하고 증거를 수집하고 일본 정부에 항의를 하고 있다.

아사히 신문에서 "99엔" 보상에 대해 기사가 났었다. 국내에서는 MBC 외에는 작게 보도를 하거나 아예 그런 기사는 없었다고 한다.

이게 말이 되는건지... 더욱이 어이가 없는것은 "강제징용진상위원회"(?) 가 곧 해체될 위기에 처했으며 일본에서 유골을 보내 주겠다고 하는데도 그 유골 반환에 쓰일 예산이 2009년 12월 말 예산안 심사에서 제외되어 삭감되었다는 것이다. 그 잘난 4대강 예산안 때문에 파행을 겪었던 그 때 말이다... 정치인들은 뭐라고들 하냐면 여야를 떠나 하나 같이 다들 몰랐다는 것이다.

한숨만 나온다...
음... 과연 우리나라가 선진국이라고 해도 되는 것일까? 나라가 힘이 없는것도 아니고... 하루빨리 국회의원들이 정신을 차려야 우리나라가 좀 더 깨끗하고 올바른 방향으로 가리라 생각한다. 그리고 국회의원 뽑을 때 제발 학력에 제한은 두었으면 한다.
물론 어려운 환경속에서 열심히 공부해서 좋은 대학에 간 사람도 있을 것이다. 하지만, 그렇지 않는 경우에는 머리가 똑똑해서인지... 음... blah blah...

에씨... 오늘 아침부터 저녁까지 밥 맛있게 먹었는데 정치인들과 정부의 무지함에 기분이 아주 안 좋다...
이런 글을 작성하는 것 자체가 어쩌면 시간 낭비인 것 같다. -_-;

TV CF 중에 "안보고 안듣고 말 안하고" 를 얘기하는게 있는데 아주 마음에 든다.
하지만 그러면 안 되겠지? ㅎㅎ
깨끗한 날이 분명 올 것이라고 믿는다.

-----
Cheers,
June

월요일, 1월 11, 2010

느낌 좋은 글... (출처를 알 수 없음)

Title: 출처를 알수 없음
Source: 원본 출처는 알수 없으나 손성윤 (^^) 미니홈피에서 가져왔음
(http://www.cyworld.com/sy7235)


"하루는 학교 갔다와서 엄마방에 들어갔는데
 엄마가 죽은 듯이 누워있는거야. 멀리서 잠자코 쳐다보고 있었어.
우선은, 근데 엄마가 십분이 지나도 이십분이 지나도
계속 그 상태로 누워서 일어나지 않는 거야. 뒤척이지도 않고.
정말 죽은 사람 처럼."

"그래서"

"가까이 가 봤지. 코 앞에서 내려다봤어.
숨도 쉬지 않는 것 같았어.그래서 생각했지. 울 엄마 죽은 걸까.
눈물이 나려는데 엄마가 눈을 번쩍 떴어.
그리곤 일어나서 방을 나가더니 점심을 차려서 다시 돌아왔지.
숟가락을 내 손에 쥐어주면서 그 일에 대해선 아무 설명도 안해줬어."

"넌 왜 안 물어봤는데?"

"왠지 물어보면 안 될 것 같은 생각이 들어서"

"으응"

"그리고 다음주 그 요일에, 또 그 다음주 그 요일에, 또 그런식이였어.
죽은 사람 처럼 꼼짝도 없이 누워서 내 시선을 받아내고 있었어.
그런게 네번째 인가 다섯번째인가
그날은 점심을 밥 대신 국수를 먹었거든. 내 생일이였어.
오래 살아야 된다면서 엄마가 이번엔 숟가락 대신 젓가락을 쥐여줬어.
막 국수를 한 가닥 끌여올렸는데 엄마가 그랬어.
궁금하지 않냐고. 왜 그러고 있는 건지.
사실 그때는 별로 궁금하지 않았지만 사소한 걸로 싸우기 싫으니까
어,말해줘. 그랬지. 그러니까 엄마가 그래.
죽는 연습 하는 거라고.
만약에 어느날 갑자기 또 어떤 이유로 그렇게 느닷없이
엄마가 죽어버릴 수도 있으니까 나를 단련시키는 연습을 하는 거라고."

"그래서 넌 뭐라고 했는데?"

"아, 그렇구나"

"그게..다야?"

"엄마도 대수롭지 않게 말했으니까.
그랬는데 내가 막 여름방학 하던 날이였나봐.
그 날도 엄마는 연습을 하고 있었거든. 그 쓸데없는 연습.
방해하지 않으려고 점심 안 먹어도 돼,
오늘. 그러고 방에 들어가서 좀 놀다가 왔는데
그때 까지도 엄마는 연습중이었어.
그래서 이번엔 나가서 놀다가 들어왔는데 그때도 엄마는
그 상태 그대로였어. 다음 날 자고 일어나서 방에 들어갔을 때도
그대로인 엄마를 보고야 알았어. 이번엔 연습이 아니네."

여전히 수잔과 남자는 걷고 있다.
느릿느릿 말하던 수잔의 고개는 지루한 듯 떨어진다.
마치 남의 얘기를 하고 있다는 듯이.

"그런데 효력이 있더라고. 별로 슬프지 않았어. 난 단단해져서 벌써"

"응."

"그러니까 우리 헤어지자."

우뚝 멈추어서지도 불쑥 끊겨버리지도 않는다.
그대로 흐르고 있다. 이 노곤하고 잔잔한 기류.
남자가 고갤 돌려 웃었다.
아니 웃는 걸까.

"훈련시키는 거냐, 나?"

"응, 그러니까 늘 긴장하고 있어.
언젠간 진짜 헤어지는 날이 와도  슬프지 않게."



-----
Cheers,
June

일요일, 1월 10, 2010

일기 (2010.01.09) 요즘 드라마... 그리고 나에 대한 얘기...

2010년 방송사 별 내가 요즘 관심있게 보는 드라마들 이다.
 - MBC: "보석 비빔밥", "파스타"
 - KBS: "추노", "공부의 신"(일본 만화 원작 - "최강입시전설 꼴찌, 동경대 가다!", TBS 방영 - "드래곤 사쿠라")
 - SBS: "크리스마스에 눈이 올까요"

요즘 이 드라마 들에 푹 빠져있다.
story 는 내 마음을 잡기엔 충분한 것 같다. 현실에 맞는 상황 scene, 역사, 전문주제, 어울리다고는 생각하진 않지만 철학적인 것 등등, 이렇게 각각 엮이지 않고, 독특한 character 들이 있으며 급하게 진행하지 않는 부분들이 나에게 많은 즐거움을 준다.

또한 나에게 많은 지식과 작가들의 상상력을 배울수 있는 기회를 주기도 한다. 아직 재능이 부족해 완성하지 못한 대본 및 글들이 있다. 완성을 해야 하지만, 사실 이런 저런 핑계가 많아서 -게으르다는 표현이 좀더 정확하겠지? ㅎㅎ- 손을 대지 못하고 있다. 하지만 언젠가는 꼭 완성 할 것이다.

음악도 마찬가지이다. humming 으로 녹음 및 간단하게 작성한 score (MIDI), 여러 DAW, device 로 작업한 많은 sound 나 music 이 있다. 이것 역시 완성된 것은 거의 없다. legacy DAW 으로 작업한 곡들도 많이 있지만 modern DAW 으로 porting 하는 것이 여간 쉽지 않다.

나에게 올바른 방향이라고 함은, 이러한 것들이 완성이 되지 않아서 되도록 빠른 시일내에 완성을 하는 것이 아닌,... 꾸준한 시간을 갖고, 여유롭게 이러한 작업들을 즐기면서 완성도를 높이는 것이다.

어쩌면 내가 지금까지 이렇게 해왔던 것이 내 자신 스스로 즐기고 있던것은 아닐까? 늘 새로운 것을 좋아 하지만, 한번 손에 잡은 것을 바로 끝내는 것이 아닌 여유를 갖고 계속 즐기는 것이 어쩌면 내가 바라는, 내가 나도 모르게 실천해 오던 이상적인 작업은 아니였나 생각해 본다.

난 참, 나를 사랑한다.
이런 일들을 나 스스로 즐기며 발전 시키고, 연구 해 나가는 내 모습이 참 사랑스럽다. 비단 드라마, 음악만은 아니다. 관심있게 공부하는 Medical Science (Thoracic Surgery), 나에 전공인 Computer Engineering, Software Developer 및 Software Engineer 로써도 앞으로 생을 마감하는 날까지 공부는 끊임없이 계속할 것이며 배워나갈 것이다. 이러한 마음가짐과 행동은 지난 날 아주 어렸을 때 공부하지 않고 걱정만을 끼쳐 드렸던 부모님에 대한 예의 이며 효도라고 생각한다.

고등학교 입학하고 부터 마음 먹었던 그런 초심을 아직까지는 잘 유지하고 행동으로 잘 실천 하고는 있는 것 같다. 앞으로도 이러한 초심을 잃지 않고 공부 만큼은 열심히 하련다. 그저 이러한 것으로 인해 그 동안 어긋나지 않고 바르게 키워주신 부모님께, 앞으로는 물론 늘, 큰 도움이 되었으면 좋겠다.

-----
Cheers,
June

토요일, 1월 09, 2010

USB Web Camera Test in SKT WIPI Emulator

WIPI SDK Camera Test
 - you have to have an USB Webcam(recommended Logitech device) for prepare to camera test in SKT WIPI SDK
 - below codes are not tested but have an enjoy! lol  ㅋㅋㅋ  --- June

* Simple Camera Test code

void cameraTest(void) {
M_Int32 ret = -1;
M_Int32 fd = 0;
M_Byte buf[2048];
MC_CameraInfo info;
MC_CameraOption option;
MC_CameraSnapshot snapshot;

M_Uint32 memID_pByteBuf = 0;
M_Byte* pByteBuf = NULL;

memset( (void*)buf, 0x00, sizeof(buf) );

// Open Camera
fd = OEMC_ioDevOpen( "Camera", 0, NULL );

if( fd )
MC_knlPrintk( "Open Camera [OK]\n" );
else {
MC_knlPrintk( "Open Camera [Fail]\n" );
return;
}

ret = OEMC_ioDevControl( fd, "GETSTATUS", &buf, (void*)sizeof(buf) );
if( !ret )
MC_knlPrintk( "Camera Status:\n%s\n", buf );
else {
MC_knlPrintk( "Camera Status [Fail]\n" );
return;
}

if( !ret )
ret = OEMC_ioDevControl( fd, "GETOPTION", &option, NULL );
else {
MC_knlPrintk( "GETOPTION [Fail]\n" );
return;
}

option.nPreviewWidth = 100;
option.nPreviewHeight = 100;
option.nPreviewPosX = 0;
option.nPreviewPosY = 0;
option.nCurrentResolution = 1;
 strncpy( option.szCurrentImageType, "image/jpeg", sizeof(option.szCurrentImageType) );
  
if( !ret )
ret = OEMC_ioDevControl( fd, "SETOPTION", &option, NULL );
else {
MC_knlPrintk( "SETOPTION [Fail]\n" );
return;
}

// Turn on Preview
if( !ret )
ret = OEMC_ioDevControl( fd, "SETPREVIEW", (void*)"on", NULL );
else {
MC_knlPrintk( "SETPREVIEW [Fail]\n" );
return;
}

 // Take a snapshot
ret = MC_ioDevControl( fd, "GETSNAPSHOT", &snapshot, NULL );
if( !ret ) {
if( memID_pByteBuf )
MC_knlFree( memID_pByteBuf );

memID_pByteBuf = MC_knlAlloc( snapshot.nImageDataSize );
pByteBuf = (M_Byte*)MC_GETDPTR( memID_pByteBuf );

if( pByteBuf )
memset( (void*)pByteBuf, 0x00, sizeof(snapshot.nImageDataSize) );
else {
MC_knlPrintk( "Allocates buffer [Fail]\n" );
memID_pByteBuf = 0;
return;
}

ret = MC_ioDevRead( fd, pByteBuf, snapshot.nImageDataSize );
if( ret ) { // read size
M_Int32 hFile;
M_Int32 retMkDir = 0;
M_Int32 flag = MC_FILE_OPEN_WRTRUNC;
M_Char* pFilename = "test_out.jpg";
M_Int32 len = snapshot.nImageDataSize;
M_Char* pFileExt = snapshot.szImageType;

hFile = MC_fsOpen( pFilename, flag, MC_DIR_PRIVATE_ACCESS );
if( hFile < 0 ) {
MC_knlPrintk( "Open a file to write [Fail]\n" );
return;
}

MC_fsSeek( hFile, 0, MC_FILE_SEEK_END );
MC_fsWrite( hFile, pByteBuf, len );
MC_fsClose( hFile );
}

  /*
{
M_Char retBuf[255] = { 0 };
M_Char* pFilename = "test_out2.jpg";
M_Int32 len = snapshot.nImageDataSize;

memset( (void*)retBuf, 0x00, sizeof(retBuf) );
strcpy( retBuf, "PHOTO" );
ret = MC_termResWrite( "PHOTO",
retBuf, sizeof(retBuf),
pFilename, "image/jpeg",
pByteBuf, len, MC_TERMRES_CREATE );
if( ret < 0 ) {
MC_knlPrintk( "MC_termResWrite [Fail]\n" );
return;
}
}
  */
}

// Release resource
if( fd ) ret = MC_ioDevClose( fd );
fd = 0;

if( memID_pByteBuf ) MC_knlFree( memID_pByteBuf );
memID_pByteBuf = 0;
}


* Camera image with mask-based foreground image
*  - NOT TESTED
{
 M_Int32 ret = -1;
M_Uint32 memID_pByteBufFrame = 0;
M_Byte* pByteBufFrame = NULL;
MC_CameraFrameInfo frameInfo;
MC_FileInfo fileInfo;
M_Int32 frameFileSize = 0;
M_Uint32 fd_res = 0;

#ifdef _VCDLL
if( MC_fsFileAttribute("PHOTO/test_frame.bmp", &fileInfo, MC_DIR_SYSTEM_ACCESS) < 0 ) {
MC_knlPrintk( "MC_fsFileAttribute [Fail]\n" );
return;
}
if( (fd_res = MC_fsOpen("PHOTO/test_frame.bmp", MC_FILE_OPEN_RDONLY, MC_DIR_SYSTEM_ACCESS)) < 0 ) {
MC_knlPrintk( "MC_fsOpen [Fail]\n" );
return;
}

frameFileSize = fileInfo.size;

if( memID_pByteBufFrame )
MC_knlFree( memID_pByteBufFrame );

memID_pByteBufFrame = MC_knlCalloc( frameFileSize );
if( memID_pByteBufFrame <= 0 ) {
MC_knlPrintk( "Allocates buffer [Fail]\n" );
}

pByteBufFrame = (M_Byte*)MC_GETDPTR( memID_pByteBufFrame );

if( MC_fsRead(fd_res, pByteBufFrame, frameFileSize) < 0 ) {
MC_knlPrintk( "MC_fsRead [Fail]\n" );

MC_knlFree( memID_pByteBufFrame );
MC_fsClose( fd_res );
return;
}

MC_fsClose( fd_res );
#else
frameFileSize = OEMC_termResGetSize( "PHOTO", "test_frame.bmp" );
if( frameFileSize < 0 ) {
MC_knlPrintk( OEMC_termResGetSize [Fail]\n" );
return;
}

if( memID_pByteBufFrame )
MC_knlFree( memID_pByteBufFrame );

memID_pByteBufFrame = MC_knlCalloc( frameFileSize );
if( memID_pByteBufFrame <= 0 ) {
MC_knlPrintk( "Allocates buffer [Fail]\n" );
}

pByteBufFrame = (M_Byte*)MC_GETDPTR( memID_pByteBufFrame );

if( OEMC_termResRead("PHOTO", "test_frame.bmp", pByteBufFrame, frameFileSize) < 0 ) {
MC_knlPrintk( "OEMC_termResRead [Fail]\n" );

MC_knlFree( memID_pByteBufFrame );
return;
}
#endif

//
// Frame
//
// Frame Image: Width(4 bytes), Height(4 bytes), 16 bit raw data (RGB: 565)
frameInfo.TransparencyColor = 0x00050605; // 0x00RRGGBB
frameInfo.pBmpBuffer = pByteBufFrame;
frameInfo.nBmpBufferSize = frameFileSize;
ret = OEMC_ioDevControl( fd, "SETFRAMEIMAGE", (void*)"on", &frameInfo );
if( ret < 0 ) {
MC_knlPrintk( "SETFRAMEIMAGE [Fail]\n" );
return;
}
}


-----
Cheers,
June

목요일, 1월 07, 2010

enTourage eDGe: the dual-screen eBook reader

enTourage eDGe: the dual-screen eBook reader
Source: http://www.pcpro.co.uk/blogs/2010/01/06/entourage-edge-the-dual-screen-ebook-reader/


Posted on January 6th, 2010 by Barry Collins
enTourage eDGe: the dual-screen eBook reader

enTourage-eDGe-1_webWe’re expecting to see several companies launch dual-screen eBook readers at this year’s CES, but first out of the blocks is a little-known US company called enTourage Systems.
The enTourage eDGe (the company’s ridiculous capitalisation, not ours) was the highlight of the CES Unveiled event, which gives journalists a sneak preview of what’s set to appear this year’s show.  It has a  9.7in e-paper display on one side and a 10.1in LCD screen on the other, both of which are touchscreens, allowing you to annotate eBooks with handwritten notes or scan through web pages with the flick of a finger on the LCD screen.
enTourage eDGe
In a brief hands-on demonstration, the eDGe showed several clever touches, such as allowing you to highlight words in eBooks, perform a Google search on the term using the built-in web browser, and then link the search results to the eBook page, which is a great research tool for students reading academic texts. You can also drag and drop pages from the greyscale e-paper screen onto the LCD, allowing readers to view images in full colour, for instance
enTourage-eDGe-3_web
The device runs on Google’s Android operating system, and includes built-in Wi-Fi for web browsing, updating a Twitter feed or updating your Facebook profile. The eDGe has a claimed “minimum” battery life of six hours “with everything running”, according to the enTourage spokesman we met.
The e-paper display is remarkably sharp for a touchscreen, with handwritten annotations easy to add using the built-in stylus. The LCD display was less impressive, and seemed to be suffering from a distinct lack of brightness under the harsh lighting in the conference centre, although we suspect the brightness on the demo units may have been turned down to preserve battery life.
IMG_3811
The device is far chunkier than your average eBook reader: it’s certainly not going to be slipping unnoticed into a bag like a Kindle or Sony Reader. In fact, it’s more akin to a netbook in terms of size. It’s price tag is heavyweight too, tipping the scales at $490.
So it’s a reasonably assured start for dual-screen eBook readers, but we can’t help feeling there’s going to be better to come at this year’s show.


-----
great gear! i wanna take this... ^^;

Cheers,
June

수요일, 1월 06, 2010

Debugging Linux kernels with Workstation 6.0

Debugging Linux kernels with Workstation 6.0
Source: http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html


Debugging Linux kernels with Workstation 6.0

We just quietly added an exciting feature to Workstation 6.0. I believe it will make WS6 a great tool for Linux kernel development. You can now use gdb on your host to debug the Linux kernel running inside the VM. No kdb, no recompiling and no need for second machine. All you need is a single line in VM's configuration file.

To use the new feature, grab the latest build of Workstation here(http://www.vmware.com/download/ws/),( or free 30-day evaluation here(http://www.vmware.com/download/ws/eval.html). Put this line into configuration file of your Linux VM:

debugStub.listen.guest32=1

Now whenever you run the virtual machine, you'll see the following in the vmware.log file (debug builds will also print this message to Host console):

VMware Workstation is listening for debug connection on port 8832.

Run gdb on the Host, reference it to the kernel with symbols and attach to the virtual machine:

% gdb
(gdb) file vmlinux-2.4.21-27.EL.debug
(gdb) target remote localhost:8832

That's it. The VM is blocked now, so you can "continue" it and "^C" back to gdb. Breakpoints, single step, memory inspection - all this works as usual. If you have SMP VM, then each VCPU is mapped on a thread, so use "info threads" and "thread NN" to switch between them.

Debugging the 64-bit kernel works in the same way, except you need to use a different option:

debugStub.listen.guest64=1

and connect to port 8864. Since gdb starts in 32-bit mode by default, you may also need to switch it to i386:x64-64 before connecting:

(gdb) set architecture i386:x86-64
(gdb) target remote localhost:8864

The kernels with symbols are sadly lacking on most distributions, but if you use RHEL then this website may help (look for kernel-debuginfo rpm):

http://people.redhat.com/duffy/debuginfo/index-js.html

The gdb support in WS6 is experimental, so there may be rough edges here and there. Please post on community forums if something doesn't work right or if you have a suggestion:

http://communities.vmware.com/community/vmtn/general/guestdebugmonitor

There are more debugging specific features in WS6 (for example, you can use gdb hand-in-hand with Record/Replay!). I will describe them shortly.

Updated 4/20/07: added explanation of 64-bit support.
Updated 5/14/07: release build prints "waiting for gdb" message into vmware.log only.
Updated 7/24/07: pointers to new build and discussion forum.


-----
Cheers,
June

화요일, 1월 05, 2010

일기 (2010.01.04) Heavy Snowfall today

I surprised today morning by heavy snowfall.
its height may almost 30 cm. unbelievable... can you see this?




















blocked road, accidents, yea that is, South Korea have deadlock today.

에씨... 여기에서 부턴 한글로 쓰자...
오늘 날씨도 이런데, 퇴근후에 집에 가는길이었다.
한 여자가 나에게 "excuse me" 하면서 길을 물어 보는 것이다.

말투를 들어보니 일본인 이었다. 책을 가리키면서 여기가 어디냐고 물어보길래 map 에서 여기 위치를 알려 주었다.
여행 guide book 을 보니 일본인 이었다.

신사역 근처 "원조 할머니 보쌈?" 식당에 가서 저녁을 먹을 것이라고 한다.
마침 가는 길이라서 "just follow me" 라고 외치며 함께 신사역까지 이동했다.

그런데, 옆에 있던 남자분... 동양인인데, 다들 일본인 이냐고 물어보니 여자는 일본인이며, 남자는 중국인 이라고 한다.
하지만 미국에서 자라서 영어를 한다. native 다... -_-;;;

얘기 하는내내 나는 꿀먹은 벙어리? 마냥 말문이 트이지 않았다.
너무 갑작스러운 만남이었으며 'tall' 과 'hill' 단어의 native pronunciation 에 좌절을 하고 말았다.
일본으로 가는 부산에서 하와이 출신이며 학교 선생님인 흑인과의 대화에서 'taurine' 의 pronunciation 에 좌절을 맛본 이후 이번이 두 번째이다...

학동 사거리쯤에서 신사역까지 걸어 가면서 위치나 신기해 하는 것들을 알려줬다.
여자는 한국에 몇 번 와보았다고 하며 남자는 이번이 처음 이라고 했다.
남자가 나에게 이렇게 얘기했다. 미국에 왔냐고.
가보지 않았다고 하니 한 번 와보지 않겠냐고 해서 그냥 희망 한다고만 말했다.
부러웠다.... 아니 부러우면 지는건가?

지금은 을지병원으로 바뀐 안세병원 사거리에서, 남자분이 을지병원을 보며 저게 뭐냐고 물어봤다.
병원이라고 알려주었더니 멋지다고 했다 미국엔 hospital 이 'ugly' 하다고 한다. ㅋㅋ 어찌나 재밌던지...
그리고 '박찬호' (pronunciation 역시였다... -_-;) 는 아는데 '앙드레 김' 은 모르더라...
그래서 한국과 프랑스 파리에서 유명한 디자이너라고 했다. ㅎㅎ

여자분은 호기심이 많은건지, 큰 복어가 있는 식당을 카메라에 담겠다며 도로까지 나가 버렸다. -_-;;
덕분에 중국인 남자분과 나는 그 귀여운 여연을 위하여(?) 기꺼이 도로로 나가서 guard 해주었다.
나는 내 발목 위까지 쌓인 눈을 밟고(-_-;) 여자분은 너무 신이 났던것 같다.

나는 영화 'Avatar' 를 봤는데 둘은 아직 보지 못했다고 한다. 그냥 "fantastic" 하다고 했다. ㅋㅋ
이렇게 얘기를 하다보니 신사역에 도착.

신사역까지 내려가서 가는 길 한번 더 확인 하고 서로 "Happy New Year" 를 건네며 헤어졌다.
짧은 시간 이었지만, 한/중/일 이렇게 세 명이서 영어로 이렇게 저렇게 얘기를 하면서 행복을 느꼈다.
나도 일본 여행때 많은(?) 여인들의 도움을 받았기에 한국에 여행온 관광객을 목적지까지 편히 갈 수 있게 도와주었다.
그치만 오늘 영어회화는 0점이어서 나에게도 실망했지만, 너무 쪽팔렸다. ㅠ.ㅠ
정말 쪽팔렸다. 회화는 꾸준이 계속해야겠다.

-----
Cheers,
June

월요일, 1월 04, 2010

2016 Bug Hits Text Messages, Payment Processing

2016 Bug Hits Text Messages, Payment Processing

Source: http://tech.slashdot.org/story/10/01/03/1312209/2016-Bug-Hits-Text-Messages-Payment-Processing

Posted by Soulskill  on Sunday January 03, @09:01AM
from the y2k16-has-more-characters-than-2016 dept.

An anonymous reader writes "It seems some systems are suffering from a Y2K16 bug.
When 2009 ticked over to 2010, some Australian EFTPOS machines skipped to the year 2016.
Coincidentally, some Windows Mobile users are also having issues with their new year SMSes coming from 2016.
What function could cause this kind of error?"


-----
That problem has been occurred in South Korea here too. ^^; lol

Article: LG전자, 휴대폰 문자메시지 '오류' 발생
Source: http://www.zdnet.co.kr/Contents/2010/01/02/zdnet20100102220431.htm

this means,
you've got SMS on 0 o'clock January, 1st 2010 then '2010' will be displayed as '2016'.
my mobile phone also has been occurred... shit !!!

LG Telecom supports patching this bug in there official web site

LGT Apologizes:
http://www.cyon.co.kr/lgcyon/pop/20100103/20100103_sorry.html

LGT Patch Software:
http://www.cyon.co.kr/lgcyon/pop/20100101/pop_sms_20100101.html


Cheers,
June

Debugging the kernel using Ftrace - part 2

Debugging the kernel using Ftrace - part 2


Source: http://lwn.net/


Debugging the kernel using Ftrace - part 2
[Kernel] Posted Dec 22, 2009 17:39 UTC (Tue) by jake
The Ftrace tracing utility has many different features that will assist in tracking down Linux kernel problems. The previous article discussed setting up Ftrace, using the function and function graph tracers, using trace_printk(), and a simple way to stop the recording of a trace from user space. This installment will touch on how user space can interact with Ftrace, faster ways of stopping the trace, debugging a crash, and finding what kernel functions are the biggest stack hogs.


-----
Cheers,
June

Debugging the kernel using Ftrace - part 1

Debugging the kernel using Ftrace - part 1

Source: http://lwn.net/Articles/365835/

Ftrace is a tracing utility built directly into the Linux kernel. Many distributions already have various configurations of Ftrace enabled in their most recent releases. One of the benefits that Ftrace brings to Linux is the ability to see what is happening inside the kernel. As such, this makes finding problem areas or simply tracking down that strange bug more manageable.

Ftrace's ability to show the events that lead up to a crash gives a better chance of finding exactly what caused it and can help the developer in creating the correct solution. This article is a two part series that will cover various methods of using Ftrace for debugging the Linux kernel. This first part will talk briefly about setting up Ftrace, using the function tracer, writing to the Ftrace buffer from within the kernel, and various ways to stop the tracer when a problem is detected.
Ftrace was derived from two tools. One was the "latency tracer" by Ingo Molnar used in the -rt tree. The other was my own "logdev" utility that had its primary use on debugging the Linux kernel. This article will mostly describe features that came out of logdev, but will also look at the function tracer that originated in the latency tracer.

Setting up Ftrace

Currently the API to interface with Ftrace is located in the Debugfs file system. Typically, that is mounted at /sys/kernel/debug. For easier accessibility, I usually create a /debug directory and mount it there. Feel free to choose your own location for Debugfs.
When Ftrace is configured, it will create its own directory called tracing within the Debugfs file system. This article will reference those files in that directory as though the user first changed directory to the Debugfs tracing directory to avoid any confusion as to where the Debugfs file system has been mounted.
[~]# cd /sys/kernel/debug/tracing
    [tracing]#
This article is focusing on using Ftrace as a debugging tool. Some configurations for Ftrace are used for other purposes, like finding latency or analyzing the system. For the purpose of debugging, the kernel configuration parameters that should be enabled are:
CONFIG_FUNCTION_TRACER
    CONFIG_FUNCTION_GRAPH_TRACER
    CONFIG_STACK_TRACER
    CONFIG_DYNAMIC_FTRACE

Function tracing - no modification necessary

One of the most powerful tracers of Ftrace is the function tracer. It uses the -pg option of gcc to have every function in the kernel call a special function "mcount()". That function must be implemented in assembly because the call does not follow the normal C ABI.
When CONFIG_DYNAMIC_FTRACE is configured the call is converted to a NOP at boot time to keep the system running at 100% performance. During compilation the mcount() call-sites are recorded. That list is used at boot time to convert those sites to NOPs. Since NOPs are pretty useless for tracing, the list is saved to convert the call-sites back into trace calls when the function (or function graph) tracer is enabled.
It is highly recommended to enable CONFIG_DYNAMIC_FTRACE because of this performance enhancement. In addition, CONFIG_DYNAMIC_FTRACE gives the ability to filter which function should be traced. Note, even though the NOPs do not show any impact in benchmarks, the addition of frame pointers that come with the -pg option has been known to cause a slight overhead.
To find out which tracers are available, simply cat the available_tracers file in the tracing directory:
[tracing]# cat available_tracers 
    function_graph function sched_switch nop
To enable the function tracer, just echo "function" into the current_tracer file.
[tracing]# echo function > current_tracer
    [tracing]# cat current_tracer
    function

    [tracing]# cat trace | head -10
    # tracer: function
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
                bash-16939 [000]  6075.461561: mutex_unlock <-tracing_set_tracer
              -0     [001]  6075.461561: _spin_unlock_irqrestore <-hrtimer_get_next_event
              -0     [001]  6075.461562: rcu_needs_cpu <-tick_nohz_stop_sched_tick
                bash-16939 [000]  6075.461563: inotify_inode_queue_event <-vfs_write
              -0     [001]  6075.461563: mwait_idle <-cpu_idle
                bash-16939 [000]  6075.461563: __fsnotify_parent <-vfs_write
The header explains the format of the output pretty well. The first two items are the traced task name and PID. The CPU that the trace was executed on is within the brackets. The timestamp is the time since boot, followed by the function name. The function in this case is the function being traced with its parent following the "<-" symbol.
This information is quite powerful and shows the flow of functions nicely. But it can be a bit hard to follow. The function graph tracer, created by Frederic Weisbecker, traces both the entry and exit of a function, which gives the tracer the ability to know the depth of functions that are called. The function graph tracer can make following the flow of execution within the kernel much easier to follow with the human eye:
[tracing]# echo function_graph > current_tracer 
    [tracing]# cat trace | head -20
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     1)   1.015 us    |        _spin_lock_irqsave();
     1)   0.476 us    |        internal_add_timer();
     1)   0.423 us    |        wake_up_idle_cpu();
     1)   0.461 us    |        _spin_unlock_irqrestore();
     1)   4.770 us    |      }
     1)   5.725 us    |    }
     1)   0.450 us    |    mutex_unlock();
     1) + 24.243 us   |  }
     1)   0.483 us    |  _spin_lock_irq();
     1)   0.517 us    |  _spin_unlock_irq();
     1)               |  prepare_to_wait() {
     1)   0.468 us    |    _spin_lock_irqsave();
     1)   0.502 us    |    _spin_unlock_irqrestore();
     1)   2.411 us    |  }
     1)   0.449 us    |  kthread_should_stop();
     1)               |  schedule() {
This gives the start and end of a function denoted with the C like annotation of "{" to start a function and "}" at the end. Leaf functions, which do not call other functions, simply end with a ";". The DURATION column shows the time spent in the corresponding function. The function graph tracer records the time the function was entered and exited and reports the difference as the duration. These numbers only appear with the leaf functions and the "}" symbol. Note that this time also includes the overhead of all functions within a nested function as well as the overhead of the function graph tracer itself. The function graph tracer hijacks the return address of the function in order to insert a trace callback for the function exit. This breaks the CPU's branch prediction and causes a bit more overhead than the function tracer. The closest true timings only occur for the leaf functions.
The lonely "+" that is there is an annotation marker. When the duration is greater than 10 microseconds, a "+" is shown. If the duration is greater than 100 microseconds a "!" will be displayed.

Using trace_printk()

printk() is the king of all debuggers, but it has a problem. If you are debugging a high volume area such as the timer interrupt, the scheduler, or the network, printk() can lead to bogging down the system or can even create a live lock. It is also quite common to see a bug "disappear" when adding a few printk()s. This is due to the sheer overhead that printk() introduces.
Ftrace introduces a new form of printk() called trace_printk(). It can be used just like printk(), and can also be used in any context (interrupt code, NMI code, and scheduler code). What is nice about trace_printk() is that it does not output to the console. Instead it writes to the Ftrace ring buffer and can be read via the trace file.
Writing into the ring buffer with trace_printk() only takes around a tenth of a microsecond or so. But using printk(), especially when writing to the serial console, may take several milliseconds per write. The performance advantage of trace_printk() lets you record the most sensitive areas of the kernel with very little impact.
For example you can add something like this to the kernel or module:
trace_printk("read foo %d out of bar %p\n", bar->foo, bar);
Then by looking at the trace file, you can see your output.
[tracing]# cat trace
    # tracer: nop
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
               <...>-10690 [003] 17279.332920: : read foo 10 out of bar ffff880013a5bef8
The above example was done by adding a module that actually had a foo and bar construct.
trace_printk() output will appear in any tracer, even the function and function graph tracers.
[tracing]# echo function_graph > current_tracer
    [tracing]# insmod ~/modules/foo.ko
    [tracing]# cat trace
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     3) + 16.283 us   |      }
     3) + 17.364 us   |    }
     3)               |    do_one_initcall() {
     3)               |      /* read foo 10 out of bar ffff88001191bef8 */
     3)   4.221 us    |    }
     3)               |    __wake_up() {
     3)   0.633 us    |      _spin_lock_irqsave();
     3)   0.538 us    |      __wake_up_common();
     3)   0.563 us    |      _spin_unlock_irqrestore();
Yes, the trace_printk() output looks like a comment in the function graph tracer.

Starting and stopping the trace

Obviously there are times where you only want to trace a particular code path. Perhaps you only want to trace what is happening when you run a specific test. The file tracing_on is used to disable the ring buffer from recording data:
[tracing]# echo 0 > tracing_on
This will disable the Ftrace ring buffer from recording. Everything else still happens with the tracers and they will still incur most of their overhead. They do notice that the ring buffer is not recording and will not attempt to write any data, but the calls that the tracers make are still performed.
To re-enable the ring buffer, simply write a '1' into that file:
[tracing]# echo 1 > tracing_on
Note, it is very important that you have a space between the number and the greater than sign ">". Otherwise you may be writing standard input or output into that file.
[tracing]# echo 0> tracing_on   /* this will not work! */
A common run might be:
[tracing]# echo 0 > tracing_on
    [tracing]# echo function_graph > current_tracer
    [tracing]# echo 1 > tracing_on; run_test; echo 0 > tracing_on
The first line disables the ring buffer from recording any data. The next enables the function graph tracer. The overhead of the function graph tracer is still present but nothing will be recorded into the trace buffer. The last line enables the ring buffer, runs the test program, then disables the ring buffer. This narrows the data stored by the function graph tracer to include mostly just the data accumulated by the run_test program.

What's next?

The next article will continue the discussion on debugging the kernel with Ftrace. The method above to disable the tracing may not be fast enough. The latency between the end of the program run_test and echoing the 0 into the tracing_on file may cause the ring buffer to overflow and lose the relevant data. I will discuss other methods to stop tracing a bit more efficiently, how to debug a crash, and looking at what functions in the kernel are stack hogs. The best way to find out more is to enable Ftrace and just play with it. You can learn a lot about how the kernel works by just following the function graph tracer.

(Log in to post comments)

Debugging the kernel using Ftrace - part 1
Posted Dec 11, 2009 23:43 UTC (Fri) by eparis123 (subscriber, #59739) [Link]
This is indeed a great writeup, and the interface is unixy and elegant.
Thanks a lot for your efforts on ftrace and for writing this article :)

Debugging the kernel using Ftrace - part 1
Posted Dec 14, 2009 5:09 UTC (Mon) by gdt (subscriber, #6284) [Link]
Typically, that is mounted at /sys/kernel/debug. For easier accessibility, I usually create a /debug directory and mount it there.
Please don't do this sort of weirdness in tutorials, unnecessarily changing a perfectly usable default just gets in the way of your [otherwise very fine] exposition.
That goes double for reviewers of Linux distributions. I've lost count of the number of reviews that don't review the out-of-the-box distribution, but rather review some author's preferences applied to that distribution.

Debugging the kernel using Ftrace - part 1
Posted Dec 14, 2009 15:14 UTC (Mon) by nevets (guest, #11875) [Link]
BTW, I noticed that if DEBUGFS is configured, the /sys/kernel/debug directory automatically is created. But why isn't the debugfs automatically mounted there? I mean, the /sys file system is already a pseudo system, why not have it automatically mount debugfs?
If this was the case, I would not need to create a "find_debugfs()" function to search through mounts to find that directory in my tools.

I do pick /debug because I usually do not do my tracing in the debugfs/tracing directory. And it is much easier to type /debug than to type /sys/kernel/debug (even with tab completion). I could also ln -s to /sys/kernel/debug, but if I have to do that, why not just mount it at /debug.

Again, if /sys/kernel/debug automatically mounted debugfs, then a link would be reasonable.

Debugging the kernel using Ftrace - part 1
Posted Dec 17, 2009 5:59 UTC (Thu) by abadidea (guest, #62082) [Link]
gdt: bikeshedding much? :)

Debugging the kernel using Ftrace - part 1
Posted Dec 18, 2009 8:38 UTC (Fri) by tejparkash (guest, #53332) [Link]
I guess these lines should be there in Setting up Ftrace
HowTo mount the debugfs system:
# mkdir /debug
# mount -t debugfs nodev /debug

Anyway simple and excellent article, specially trace_printk is something new to me, as i have observed the all problems listed due to printk.
Waiting eagerly Part-II......


-----
Cheers,
June

[경/공매] 2억으로 강남아파트에 입성하다.

this story is like a novel, but interesting... ^___^
read this smoothly.


[경/공매] 2억으로 강남아파트에 입성하다.

아파트, 그 떨쳐버릴 수 없는 매력
벌써 6월이다.
코끝을 기분 좋게 간지르는 미풍의 산들거림에 스르르 눈이 감겨온다.
수많은 상념 속에서 작년 이 맘 때의 기억들이 아련하게 피어오른다.
이리 치이고 저리 차이고 ..... 희망 없이 암담하기만 했던, 그저 힘들기만 했던 1년 전의 기억들이 시간너머 아득하다.

 미래에 대한 희망을 품어 보고 싶어서.... 사람같이.... 인간처럼 살고 싶어서 돌파구를 모색하다가 우연찮게 경매계로 접어든지 벌써 1년.

경매입문 초반에는 환금성 좋은 아파트가 주된 관심의 대상이었다.
얼마를 투자해서, 얼마 후에 급매를 놓고, 얼마의 차익을 내면, 얼마의 수익률이 되고....
장미빛 환상 속에서 끝없이 공부하고, 끝없이 현장조사하고, 끝없이 응찰하고, 끝없이 낙방했다.
희망과 좌절의 비율이 적절히 배합된, 그럼으로써 하루하루 견딜 수 있었던....그저 버티기만해도 성공인 그런 나날이었다.


어느 정도 실전 경험이 쌓이자 경매의 꽃이라고 할 수 있는 아파트에 본격적으로 눈을 돌렸다.
그러나 당시 아파트에만 10여건을 집중적으로 응찰했는데 한 건도 낙찰 받지 못했다.
그때에도 실수요자나 아줌마 부대들을 고려하여 누구나 쉽게 판단할 수 있는 평범한 물건은 거들떠보지도 않았었는데.....

유치권 신고 된 물건이나 선순위 가처분이 있는 물건, 대지권 미등기 물건이나 예고등기 있는 물건.......
이도저도 아니면 최소한 토지 별도등기라도 있는 물건에 응찰을 했으나 평균적으로 20명 이상씩 응찰하여 2등을 2번했던 기억 말고는 모두 순위조차 알 수 없거나 1등하고의 금액차가 너무 커서 순위조차 알고 싶지 않았던 경우가 대부분이었다.


그 중에 기억나는 물건이 하나 있다!
서울 성북구 정릉동에 소재한 30평형대 재건축 아파트.
거의 감정가의 반에 육박하는 거액의 유치권이 신고 되어 있었고 대지권은 미등기에다가 대지권 유무 불명이 아닌, 아예 대지권 없음이 공지된 물건. 그리고 채무자의 소유권과 경매신청 채권인 저당권이 추후 소송결과에 따라 말소되리라는 예고등기까지 있었던 물건이었다.
최저가는 감정가 대비 50%대....

오랫만에 물건이다 싶어 장장 일주일을 권리분석에 매진(?)했다.
현장탐문결과, 유치권은 허위의 개연성이 상당했고 신고금액의 10%정도면 협상이 가능하리라 판단되었다.
예고등기 또한 대법원 사이트 검색결과 원고 패로 이미 소송이 끝난 상태였기 때문에 아무런 문제가 없었으나 문제는 대지권 미등기였다.
대지지분이 아예 없는 것으로 물건 명세서 상 공지되었고 당연히 감정가에도 대지지분은 포함되지 않았다. 결국 외관상으로는 낙찰자가 현재 대지소유자에게 대지지분을 매수해야하는 상황이었다.
토지등기부 등본을 떼보니 누군가가 위 아파트 호수의 대지지분을 미리 사놓고 있었다.
이름이 낯익어 자세히 보니 바로 유치권자였다.
유치권자가 대지지분을 사놓고 위 건물을 낙찰 받으려는 의도였다.
저가에 낙찰받기 위해 허위의 유치권을 신고해 두고......

흠......대강 알만한 스토리였다....!

판례를 검색하다가 '대지권이 이미 성립한 후에 건물과 분리하여 대지권만을 매도하는 경우에는 그 매매계약은 무효이고 대지권은 건물의 처분에 종속하여 건물소유자에게 귀속한다'는 내용의 판례를 찾아냈다. 잘하면 공짜로 대지권을 얻을 수 있겠다 싶었다.
여러 자료들을 분석하여 나름의 비하인드 스토리를 구성해 보고 별문제 없겠다 싶어서 응찰했다.
이렇듯 복잡한 물건에 누가 들어오겠는가....!
그래도 혹시 몰라 신중을 기하기로 하고 응찰가를 최저가보다 1000만원 정도 더 쓰고 끝자리는 평소 습관에 따라 붙여 넣었는데........!

서울 중앙지법에서 세 번째로 진행된 이 건 개찰에 응찰자로 호명되어 나가는 사람이 끝도 없었다. 나가면서도 모두들 어이없어 했다.
이런 물건에..... 도대체 이 많은 사람들이....!
모두들 표정이 어두웠다. 대부분 최저가 언저리에서 응찰가를 써 넣었으리라.

중풍에라도 걸렸는지 지팡이를 짚고 비척이는 걸음걸이로 간신히 법대 앞에 나온 사람이 인상적이었다.
도대체 무슨 사정이 있길래 저런 몸을 이끌고....!
마음은 더 무거워 졌다. 우린 안돼도 저 사람은 꼭 돼야 할 것 같았다.
자포자기의 심정으로 기다리는 데 낙찰자가 호명 되었고 낙찰가는 거의 감정가의 90%에 육박하는 수준이었다.
환하게 웃고 있는 낙찰자는 건강해 뵈는 젊은 친구였다.

곧이어 지팡이를 짚고 또 다시 힘겹게 계단을 올라가는 그 사람의 뒷모습!
처연했다.....하마터먼 눈물이 날 뻔했다.
내가 떨어져서가 아니라, 지팡이의 주인공의 뒷모습이 너무나 지쳐보여서....
그 한 걸음 한 걸음이 너무도 위태로워 보여서.....


암튼 그때 이후로 나는 아무리 좋아 보여도 아파트는 거들떠도 보지 않았다.
그래서 다가구 주택으로 눈을 돌렸고 상계동 소재 다가구 주택과 팽성읍에 있는 단층주택을 낙찰 받았다.
그럼에도 환금성 좋고 대출 잘되는 아파트의 매력은 떨쳐버릴 수 없었나 보다.
상계동 물건이 해결되고 여유가 생기자 강남역 인근에 소재한 90평짜리 주상복합아파트가 우연찮게 눈에 띄었다. 90평짜리 아파트인데 감정가가 12억원에 불과했고 감정시점도 한창 아파트값이 폭등하기 전인 2005년도였다.
현재 최저가는 감정가 대비 64%인 7억 4천여만원......
물건이다.....!   가슴이 뛰기 시작했다....!!!


흙속의 진주인가


아무리 생각해도 강남에 있는 90평짜리 아파트가 12억원밖에 나가지 않는다는 것이 믿기지 않았다.
부동산 사이트에서 대략적이나마 가격을 확인해 보기로 했다.
주소가 서초구 서초동 00밀라트 0타운......
부동산 사이트 어느 곳에서도 위 아파트는 검색되지 않았다.
이걸 어떻게 받아들여야 하나....
이름 없는 아파트라 아예 등록조차 되어 있지 않은 건가. 약간 실망했지만 부동산 사이트 어느 곳을 찾아봐도 서초동 인근 90평형대 주상복합아파트가 12억원 대로 매물등록이 되어 있는 곳은 없었다.
그만한 평수면 대부분 시세가 20억원을 상회하고 있었다.
이것저것 고려해도  15억원 이상은 나갈 것 같았다.

시세는 나중에 현장에서 정확히 확인해 보기로 하고 물건의 법적인 하자에 집중했다.
이 물건에 외관상 드러난 하자는 '토지별도 등기 있음'과 ‘선순위 대항력 있는 임차인의 존재’였다.
인터넷상에서 토지 등기부등본을 발급받아 보았다. 일견 보기에도 부담스러울 만큼 복잡하고 두툼한 등기부 등본이었다!

그러나 꼼꼼히 분석해 본 결과 이건 토지별도등기는 낙찰자가 인수해야 할 성질의 것이 아니었다. 그저 등기부만 복잡할 뿐, 이 건 아파트의 권리관계에는 하등 영향이 없는 별도등기였던 것이다.


그렇다면 남은 문제는 대항력 있는 선순위 임차인.......!
물건 명세서에는 현황조사결과 신**라는 임차인이 액수 미상의 보증금으로 점유하는 것으로 되어 있었다.
위 세입자의 전입신고일은 말소기준권리인 채권자의 최초 가압류 설정일보다 한참을 앞서 있는데 세입자는 배당요구를 하지 않았다. 그리고 보증금의 액수도 모른다.
진정한 임차인이라면 낙찰자가 위 임차인의 얼마인지도 모르는 보증금 전액을 떠안아야 할 상황이었다.
강남지역의 전세가가 보통 매매가의 40%수준이라면 감정가를 시세로 보더라도 5억 가까운 금액을 떠안아야할 판이었다.
결국 전입신고자가 진정한 임차인이라면 현재의 최저가도 높은 것이고 한번은 더 유찰이 되어야 할 물건이었다.

감정평가서를 꼼꼼히 읽어 보았다.
감정평가서에는 위 아파트가 복층구조로 되어 있고 아래층이 60평, 윗층이 30평으로 나누어져 있다고 기재되어 있었다.
곰곰히 생각해 보았다.
주인이 아랫층을 쓰고 윗층은 임대를 내준 게 아닐까? 그렇다면 보증금의 액수가 그리 클 것 같지는 않았다.
그러나 감정평가서상의 내부구조도를 보고는 추측이 틀렸음을 깨달았다.
아랫층은 넓긴 하지만 방이 하나밖에 없었다. 집주인이 방 하나를 쓰고 임차인이 윗층 전부를 사용한다? 상상하기 어려운 일이었다.
역시 아파트 전체를 빌려 쓰는 경우만이 상정 가능한 스토리였다.
음......감이 좋은 물건이긴 했지만 보증금을 떠안고 나면 남는 게 없을 물건인지라 포기해야 할 것 같았다. 그래도 조금의 미련이 남아 건물등기부등본을 들추어 보았다.

몇 장을 떠들어 보다가.....
어라?
나도 모르게 단발마의 감탄사가 새어 나왔다.....!

위장임차인, 딱 걸렸어


등기부는 그야말로 지저분함 그 자체였다. 가압류가 셀 수 없이 많이 등재되어 있었다.
신용보증기금,기술신용보증, 중소기업은행 등등.....
눈짐작으로도 액수가 100억원이 넘어 보였다.
소유자가 중소기업을 운영하다 망했나 보다.
추측건대, 그래도 초반에는 운영이 잘 되었던 것 같다.
근저당권은 하나 없고 어느 시점부터 가압류가 집중적으로 올라와 있는 걸보니.....

만신창이가 된 등기부 내용 중 나의 시선을 잡아 끄는 것이 있었다.
바로 등기부상의 소유자의 주소지였다.....!
처음 이 물건을 매수할 때 등기부상의 소유자의 주소지는 이건 물건의 소재지가 아니었다.그런데 중간에 이건 물건 소재지로 주소를 변경했다. 주소 변경의 원인은 '전거'였다.

소유자가 이 물건을 매수한 뒤 얼마 되지 않아 세입자가 전입신고를 하고 또 그 후 얼마 되지 않아 소유자가 이 물건 소재지로 주소지를 옮겼다......?
소유자의 이름은 남자, 세입자의 이름은 여자.....혹시 둘이 부부가 아닐까?

뇌세포들이 꿈틀댄다.
평소에는 둔하다가도 필요한 순간에는 비록 찰나지만 번득이는 직감....!

'중소기업을 운영하던 남편이 사업이 잘되어 강남에 대형평수의 아파트를 장만했다. 남편이 집에서도 업무를 볼 수 있게 복층 구조 중 아래층은 사무실 용도로 꾸며 놓고 윗층은 주거용으로 사용했을 것이다.
남편은 소유자니까 서둘러 전입 신고할 필요가 없었으나 아이들 학교문제도 있고 하니까 부인과 자녀들이 일부라도 먼저 전입신고를 했을 것이고 뒤이어 남편도 전입신고를 해서 온전한 세대가 되었으리라......그 후 남편사업이 갑자기 어려워지기 시작했고 여기저기서 채권자들이 가압류를 해댔을 것이다.'
마구잡이로 떠오르는 추리를 적당하게 배열해 놓고 보니 그럴듯한 스토리가 되었다...

이제는 추리를 뒷받침할만한 증거자료들의 수집이 필요한 때....!
확인도 안될 머릿속 상상은 그만두고 몸이 나서야 할 차례였다.

현장에 가보자....!
호적등본만 떼어 볼 수 있으면 몸이 고생하지 않아도 될 텐데.....
혹시 몰라 서초동에서 변호사로 개업 중인 후배에게 도움을 청해 보았다.
쉽진 않겠지만 알아봐 주겠단다....
후배만 믿고 있을 수 없어 현장으로 출동했다.
조만간 뭔가 나와도 나올 것이다........!

현장에 가보니


이건 아파트는 강남역에서 교대역으로 가는 중간에 위치해 있었다.
비록 강남역 3번 출구를 위시한 핵심 상권은 아니었지만  테헤란로 대로변 상에 위치한 발전가능성이 무궁한 요지였다.
그리고 19층짜리 주상복합아파트 2개동 중 뒤에 지어진 2타운에 속해 있었고 15층 로얄층에 향 또한 정남향이었다.


오호라.......!
현장에 가보니 더더욱 마음이 끌리는 물건이었다..
한 블럭 옆으로 삼성타운 3개동의 공사가 한창 활기차게 진행 중이었고 바로 옆에는 롯데칠성의 방대한 물류창고가 개발을 기다리며 움츠리고 있었다.
강남의 스카이라인이 점차 교대역, 서초역 방향으로 뻗어 가고 있는 징후가 현장에 가보니 생생하게 느껴진다.

갖고 있으면 꽤 값이 오르겠는데......!

일단 인근의 공인중개사부터 찾았다. 처음에는 전세를 구한다고 했다.
이왕이면 사무실용도로 겸용할 수 있게 복층구조로 된 대형평수를 찾는다고 했더니 곧바로 이 건 아파트 11층 매물을 소개해 준다.
이 건 물건과 동일한 평수이고 내부구조도 동일하다고 한다.
중개사를 대동하고 가보니 휘황찬란한 샹들리에와 고급대리석 바닥.....
전형적인 부자들만의 공간이었다.
짜임새 있게 설계된 복층구조라, 90평이라 해도 광활한(?)느낌은 없었다. 전세가는 6억원이었고 윗층으로 갈수록 좀 더 비싸다고 한다. 그런데 전세 매물은 이건 하나밖에 없다고 한다.
전세뿐만 아니라 일반 매물도 없어 거래는 거의 없다고 한다.
몇 년 전에 한번 자기가 거래를 성사시킨 적이 있는 데 그 후로는 통 거래가 없단다.
조심스럽게 15층 이상의 매매가를 물어보니 거래가 없어 정확히는 모르겠지만 15억에서 17억원까지는 가지 않겠냐는 분석이다.
그리고 옆에서 신축중인 삼성타운 3개동의 입주가 끝나는 내년 상반기 정도면 수요가 늘어 매매가도 높아지지 않겠냐는 전망도 내놓는다.

공인중개사가 보여준 전세물건은 '어둡고.... 시끄럽고.....구조가 답답하고.....'등등
이런 저런 핑계로 거절하고 이번에는 혼자서 다시 현장으로 돌아왔다.

먼저 우편함을 살펴보는 게 순서겠지.....? 
우편물을 살펴보는데 등 뒤에서 걸걸한 목소리가 귀청을 때렸다!


허물어지는 모래성


돌아보니 인상 좋아 보이는 중년의 아저씨가 털털한 눈웃음을 짓고 있었다.
모범택시기사들이나 입을 듯한 빛바랜 제복을 입고 빤히 쳐다본다.
경비아저씨였다!
“거기서 뭐하세요? 누굴 찾으세요?”
경계의 빛은 없는, 단지 의아함만이 묻어나는 목소리다.
순간 당황했지만 애써 태연을 가장하며 둘러댔다.
'아, 예.....15**호 사는 분을 좀 찾아 왔는데요.'
'아, 김사장님? 김사장님 조금 전에 가족들하고 나가셨는데.....어쩌나.....'
낯선 사람이 입주자의 우편함을 뒤지는 것을 목격한 후임에도 오히려 내가 찾아 온 사람을 못 만나고 그냥 가는 것이 다만 안타까운듯한 목소리였다.
"그래요......? 다음에 또 오지요 뭐....그럼 수고하세요.''

정중하게 인사를 하고 황급히 돌아 나오면서도 머릿속으로 불안한 상념이 스쳐 지나간다.
'김 사장이라....? 소유자는 성이 임씨였고 임차인은 신씨던데.....김 사장이라니?'
기껏 쥐어짜낸 추리가 모래성처럼 허물어질 판이었다.
임차인이 김씨 성을 가진 사람하고 살고 있구나.....!
그렇다면 진정한 임차인일 가능성이 높았다.
공인중개업자 말에 의하면 11층의 전세보증금이 6억원에 윗층으로 갈수록 조금씩 비싸다고 했으니 최소한 6억원을 더 떠안고 나면.....?
술 담배에 찌들어 머리가 많이 무뎌졌으나 이 건 쉽사리 계산이 되었다.^^::

더 볼 것도 없었다! 포기하자!!!


아쉬움을 뒤로한 채 발걸음을 돌렸다.
돌아오면서 둘러 본 이 건 물건 일대!
삼성 타운 3개동 중 1개동은 벌써 입주가 끝나 은백색의 창속에 푸른빛의 하늘을 가득 품고 있었고 나머지 2개동도 어느 정도는 마천루로서의 위용을 드러내고 있었다.
삼성직원들 5만명이 입주하면 관련업체들과 방문객들을 고려할 때 늘어나는 유동인구는 20만명!
이 지역 인근에 나오는 상가나 오피스텔은 꼭 잡아야겠다는 결심이 이번 임장의 수확이라면 수확이었다.
허탈한 마음으로 돌아오는 길에 담배하나를 피워 물었다.
라이터를 찾으려고 주머니에 손을 넣자 손끝을 가볍게 간지르는 휴대폰의 진동!
후배 변호사였다!!!


상황은 역전되고


현장 확인결과 포기하기로 마음먹은 후였음에도 후배의 전화에 사뭇 긴장된다.
'여보세요?'
목소리가 가볍게 떨린다 . 이런 새가슴......!
심호흡을 하고 다소 힘을 내본다.
'그래 좀 알아봤어? '
의례적인 인사는 생략하고 곧바로 본론으로 들어갔다.
'예, 형 여직원 시켜서 알아봤는데 .....호적등본 떼는 거 그거 쉽지 않데요.
여직원 고생 무지했어요. 나중에 한턱 크게 쏘셔야 겠어요!'
한턱 쏘라고? 그럼?

후배의 입에서 기대했던 이야기가 흘러나왔다..
“네. 처음에는 담당 직원이 이해관계인이 아니면 변호사 아닌 대통령이 와도 안된다고 막무가내랍니다.....그래서 자초지종을 얘기했데요. 경매 들어가려는데 그 집에 세입자가 있는지 없는지를 도저히 알아볼 수가 없어서 그러니 소유자와 전입자가 부부인지 아닌지만 알려달라고요. 한참을 고민하다가 결국은 안된다고 해서 돌아서려는데 그 모습이 안쓰러웠는지 옆 사람과 상의하더니 둘이 부부가 맞다고 알려 주더라네요. 요즘 공무원들 철저해요. 조금이라도 불법의 소지가 있으면 안하려고 하지요. 근데 이건 개인의 신상정보를 알려 준 것이 아니고 단지 둘이 부부라는 것만 확인해 준거니까  불법은 아니지요. 그러니 괜한 걱정은 마시구요.”
“그래 고생이 정말 많았구나!”

정말 듣던 중 반가운 소리였지만 이내 의문이 생겨 내친 김에 물어 보았다.
“근데 경비아저씨가 그 호수에는 다른 사람이 산다던데......성이 김씨라던데.....”
“경비아저씨가 잘 모를 수도 있지요 뭐. 만약 그렇다 해도 뭔 걱정이에요. 전입신고한 사람과 소유자가 부부고 그렇다면 형이 낙찰 받아도 떠안을게 없다는 것이 중요한 거지요.”
그렇다. 물건 명세서 상 분명히 임차인은 신**씨 한명이었고 전입세대 열람부에도 전입신고자는 신씨뿐이었다.
그렇다면 혹시 현재 그 집에 다른 사람이 살고 있어도 낙찰자에게는 대항할 수 없는 것이다. 그저 인도명령 대상자일 뿐.....

“둘이 이혼은 안했겠지?”
부부사이라도 이혼한 후라면 그때부터 임대차관계가 성립한다는 판례를 본 적이 있어 조심스럽게 물어 보았다.
“네에~공무원이 별다른 얘기는 안했다니 아직까지는 적법한(?) 부부로 보여요~”
내 질문의 의도를 알아챘는지 말꼬리를 길게 늘이며 너스레를 떤다.”
“그래 고맙다. 나중에 한턱 쏠게. 그때 여직원도 꼭 데리고 나와!”
필요할 때 힘이 되어 주는 고마운 후배였다.


허물어질 뻔했던 모래성이 든든한 반석으로 다시 지어졌다!
정리해보면, 이 건에는 현재 아무런 법적인 문제가 없는 상태다.
이건 물건 명세서는 집행관이 현황 조사할 때 폐문으로 인하여 임대차 관계를 파악하지 못하자, 일단 소유자가 아닌 다른 사람이 전입 신고되어 있으니 잠정적으로 이를 임차인으로 보고 응찰자들에게 확인을 해보라는 취지로 작성되었을 것이다.


세입자라고 기재된 신**씨는 이 건 물건의 어엿한 안주인이니 법원에서 임대차권리관계를 신고하라고 문건을 보내와도 그냥 흘려버렸을 것이고. 그래서 법원에 제출된 문건은 아무것도 없었고.....당연히 배당요구도 안했을 것이니 보증금 액수도 미상인 것이고....


그나저나 이 글 제목을 위장임차인 색출기라 했는데, 그 집의 전입신고자는 저가낙찰을 노린 위장임차인이 아니었다! 너무나도 정직하고 성실한 대한민국의 국민이자, 자랑스러운 서울 시민이었던 것이다.  임차인 만세......!
돌아오는 발걸음에 힘이 넘쳐흘렀다.
처음에는  막연한 상상의 나래로 접근했다가 우여곡절 끝에 추리가 사실로 들어난 순간이었다.


다시금 머릿속을 정리해 본다.
토지별도등기는 낙찰자의 소유권과는 무관하고, 일견 대항력 있는 임차인으로 보이는 전입자 또한 낙찰자와는 무관하다. 100억원이 넘어가는 가압류들이야 낙찰로서 추풍낙엽처럼 빨간 줄이 그어질 운명들.....

좋다! 들어가자!!
문제는 응찰가였다.
이 물건 누가 들어오겠어? 한두 명 들어와도 최저가 언저리에서들 쓰겠지....?
당시 우쭐한 기분에 떠올랐던 생각들이 나중에 며칠 밤을 하얗게 지세우게 하는 빌미가 될 줄이야 그때는 정말이지 짐작도 하지 못했다.......!


과연 얼마를 써야할까


앞으로 입찰일까지 주어진 시간은 나흘!
응찰가를 얼마를 써야할지 지루한 고민이 시작되었다.
현장에서 느낀 직감은 단독응찰이거나 고작해야 한두 명의 경쟁자가 있을 것이라는 판단이었지만 시간이 갈수록 머리속으로 떠오르는 경쟁자의 숫자가 늘어난다.
그로 인하여 예상 낙찰가 또한 하염없이 올라간다.
처음에는 최저가보다 1000만원 정도만 높게 쓰면 무난히 낙찰되겠다 싶었는데 고민에 고민을 거듭하다보니 예상 응찰가가  11억원대까지 올라가 있었다.
이런 식으로 고민하다가는 막판에는 감정가를 넘겨 쓸 것 같았다.^^:;
마음에 확신을 줄만한 무엇인가가 필요했다.

실전경험이 풍부한 후배 변호사에게 도움을 청하기로 했다.
전화를 걸어 이 건에 대해 조사한 내용을 상세히 설명해 주었다.
그리고는 어떤 식으로 응찰가를 정해야 할지 방향을 좀 알려달라고 부탁했다.
'허어~ 이건 물건은 수익률이 하도 좋아 보여서 형 몰래 나도 들어가려고 했는데 포기해야겠네~'

특유의 썰렁한 농담으로 간담을 서늘하게 한다. 후배변호사랑 붙어서는 승산이 없다.
법적으로 지극히도 복잡했던 균형개발 촉진지구 내 빌라입찰에서 3억원 짜리 빌라를 17명의 경쟁자를 물리치고 7300만원에 낙찰 받은 전력이 있는 친구다. 2등과는 단돈 90만원 차이였다. 당시 우리는 후배에게 변호사 말고 박수무당을 해 보라고 적극 권한 바 있었다!
경쟁자의 응찰가를 신들린 듯이 예상하고 항상 근소한 차이로 낙찰 받는 그 친구랑 만약 법정에서 맞딱뜨리면 진검승부고 뭐고 없다. 그냥 내가 깨끗이 포기하던가, 아니면 선배라는 점을 십분 악용하여 반협박으로 후배를 포기시키던가 둘 중 하나다.


후배의 설명이 이어졌다.
'이 건 물건은 비록 아파트라 해도 경쟁자는 3명 내외일 거예요. 토지별도등기가 결론적으로야 아무런 문제가 없음이 드러났지만, 일단 복잡하고 두꺼운 등기부를 해독할 수 있는 능력이 필요한 만큼 어설픈 실수요자들은 덤비지 못할 것이고 전입신고자가 대항력 있는 세입자가 아니라는 것을 밝혀내는 것도 그리 쉬운 일은 아니거든요.

제가 상정해 볼 수 있는 경쟁자는 일단 전입신고자가 진정한 임차인이라는 전제하에 보증금을 떠안고서라도 이 물건을 낙찰 받겠다는 실수요자인데 이 부류는 응찰가를 최저가 언저리에서 쓰거나 최저가 보다 조금 높은 수준에서 쓸 겁니다.

실수요자다보니 법적인 하자를 판단할 수 있는 능력이 부족하여 응찰가를 자신 있게 쓰지 못하는 부류들이지요. 결국 8억원은 넘기지 않거나 넘겨도 초반 대에 머물겁니다.

또 하나의 경쟁자는 소유자와 전입자가 부부라는 내막을 아는 사람들이겠지요. 여기에도 두부류가 있는데 소유자의 측근들로서 자연스럽게 내막을 아는 경우와 우리처럼 고생고생해서 정보를 캐낸 경우로 나눌 수 있겠지요.
다만, 이 건은 소유자가 저가낙찰을 노리고 위장임차인을 의도적으로 만들어 놓은 경우가 아니기 때문에 소유자의 측근들이 들어올 가능성은 제 직감으로는 희박하다고 보여져요.


지금 소유자는 100억원이 넘는 채권자들의 등살에 못 이겨  잠적했거나 도주 중일 가능성이 농후하고 부인인 전입자 또한 뒤에 남아서 사태를 수습하느라 정신없을 거예요.
결국 남은 것은 우리처럼 노력을 통하여  이 건의 내막을 알게 된 사람들인데 우리가 흔히 고수라고 칭하는 사람들이지요. 그 사람들은 응찰가를 최저가 언저리에서 쓰는 일 따위는 하지 않을 겁니다.

경매를 전업으로 하는 사람들이거나 나름대로 이론과 경험으로 무장된 사람들이기 때문에 응찰가 또한 신중하게들 써낼 것이고 특히 이건의 경우 임대차 보증금을 떠안지 않아도 된다는 사실을 알고들 있기 때문에 응찰가를 쓸 때 보증금의 범위만큼의 유도리가 있지요. 그러니 굳이 최저가 언저리를 고집할 필요가 없는 것이지요.

이 같은 고수들의 특징은 응찰가를 쓸 때 최저가를 기준으로 하지 않고 목표로 하는 수익을 기준으로 삼는다는 것이지요 .그러니까 이건 물건의 급매가가 14억원이라면 5억원 정도의 수익을 목표로 9억원을 쓰자, 뭐 이런 식이 되겠지요.

고수들은 2등과의 금액차이를 크게 신경 쓰지 않습니다. 차이가 몇 천만원이든, 몇 억이든 그저 엿 사먹은 셈치자며 호방하게 한번 웃고 미련을 버리지요.
그런데 초보들은 그렇지를 못해요. 응찰가를 높게 썼다가 단독응찰이면  어쩌나....
2등은 얼마를 쓸까.....2등하고 차이가 크면  어쩌나 ....최대한 차이를 줄이려면 도대체 얼마를 써야할까....등등.....(애고~~ 찔려라^^::)


신이 아닌 이상 알 수 없는 상대방의 정확한 응찰가를 추측해 보느라 쓸데없는 헛힘을 다써버리는 것이지요. 이렇듯 하수와 고수의 차이가 극명히 드러나는 때가 바로 응찰가를 결정할 때입니다.

이 건 물건의 경쟁자는 주로 고수들이라고 볼 때 최소한 최저가보다 1억원 이상은 더 쓸 겁니다. 다만 터무니없이 높게도 쓰지 않겠지요. 오랜만에 물건이다 싶어 어느 정도의 수익을 올리고 싶어 할 것이니까요.
다만, 수익을 어느 정도로 잡고 응찰가를 얼마로 쓰느냐는 오랜 기간의 경륜으로 자연스레 체화된 내공의 크기에 따라 달라지겠지요.'


경쟁자의 부류와 심리, 그리고 경륜까지도 고려해 응찰가를 정한다? 허어 역시~!!

거두절미하고 단도직입으로 물어 보았다.
'그래 너 같으면 이 경우에 얼마나 쓸 것 같냐....?'
과연 후배가 정확한 답을 내려 줄 것인가......
온 신경이 수화기로 집중되는 것을 느꼈다!


장고 끝에 내린 결론


짧은 침묵이 이어졌다. 평소에는 급한 성격이지만 중요한 순간에는 신중한 후배다.
드디어........!
“제 생각에는  토지별도등기는 문제가 아니겠지만 고수들의 견지에서도 이 건 전입자가 소유자와 부부임을 밝히는 것은 쉽지 않을 듯 해요.
현재 전입자는 웬만한 방문객들과의 만남은  회피할 것이기 때문에 직접 만나 확인하는 것은 불가능해 보이구요. 경비 아저씨 말대로라면 그 집의 거주자는 김 사장이라는 사람이니 여기서도 한번 혼돈스러울 거예요....

둘이 부부라는 추리도 상상력 풍부한 형이나 가능한 거지,  고수들 중에도 그냥 흘려버리는 경우가 있을 것이고.....만약 형처럼 생각하는 사람이 있어서 부부라고 추측했다 해도 아시다시피 호적열람해 보는 게 여간해선 쉽지가 않거든요...
그렇다면 아무리 고수들이 경쟁자라해도 응찰가를 너무 높게 쓸 필요는 없을 것 같아요.
최소한 1억은 넘기되 2억 이상 더 쓰실 필요는 없을 듯해요.
한번 신중하게 생각해 보세요.....최종 결정은 형이 하시구요. 제가 괜히 응찰가까지 말했다가 나중에 잘못되면 그 원성을 어떻게 들어요? '

그렇다......난 단지 후배에게  도움을 청하려 했던 것이지 내 고민을 떠넘기려 했던 것이 아니었다.
어차피 최종결정은 내 몫이었다........!


                                                     ***


밤이다......
구름한 점 없는 청명한 밤하늘 너머로 오랫만에 별들이 가득하다.
도심을 벗어나.... 금방이라도 쏟아질 듯한 별들의 폭포아래서 사랑하는 사람들과 별자리 이야기로 웃음 꽃을 피울 날 언제 오려나......
숱한 상념 속에서도 낮에 들었던 후배의  일갈이 머릿속을 맴돈다.
'고수들은 응찰가를 쓸 때 목표수익만이 고려의 대상이지 2등과의 차이는 크게 신경 쓰지 않는다!'
물론 고수들도 사람이니 결과적으로 단독응찰이거나 2등과의 차이가 크게 나면 속이 좀 쓰리겠지만 그래도 '엿 사먹은 셈' 치고 훌훌 미련을 털어 버린다잖는가!
그러나 그러한 경지는 억지로 흉내 낸다고 될 것이 아니었다. 오랜 시간 좌절과 성공의 반복 끝에 자연스럽게 몸에 스며든 경륜과 연륜의 결과일 것이기에......

막연하게 상상해 본다.
최저가보다 1억 5천만원이 높은 금액을 써서 낙찰은 받았는데 결과적으로 단독응찰이라면  어떤 기분일까....?
아무리 생각해도 난 호방하게 웃으며 미련을 날려 버릴 수 있을 것 같지가 않았다.
나에게 1억 5천만원은 엿 값이 아니라 엿 공장 하나를 차릴만한 큰돈인 것이다....!
부인할 수 없는 하수인 나는 적어도 한 달은 속 앓이를 할 것 같았다.

전전반측!!
잠자리에 누워도 이리 뒤 척, 저리 뒤 척 일뿐 쉬 잠들지 못했다.

이렇게 마음을 못 잡고 사흘이 흘러갔다.
입찰일은 다음날인데 아직까지 최종 응찰가를 정하지 못했다.

나는 딜레마에 빠져 있었다.
낙찰을 받아야 하는 것과 차순위와의 차이가 근소해야 하는 것!
그러나 내 능력의 한계 내에서는 양자는 결코 섞일 수 없는, 조율이 불가능한 물과 기름이었다.
낙찰을 받으려면 수익에 대한 욕심을 버리고 낙찰가를 올려붙여야 맞을 것인데 자꾸 단독응찰이면 어쩌나 하는 불안감이 발목을 잡는다.

후배의 지적대로라면 난 지금 전형적인 하수들의 고민을 하고 있는 것이다.
일단 며칠 전 후배의 말들을 빠짐없이 정리해 본다.
'예상 경쟁자는 3명 정도에 한명은 8억 초반대를 쓸 실수요자! 나머지는 경매경험 풍부한 고수! 고수들도 1억 이상은 쓰되 난이도가 있어 2억 이상 쓰기는 쉽지 않을 거라는 판단들!'
후배의 분석과정이 설득력 있었던 만큼 신뢰가 가는 추리였다.
좋다! 그렇다면 일단은 8억 5천만원은 넘겨보자!
고민 끝에 정해진 응찰가는 878,930,000원 이었다.

응찰가를 정해놓고 잠자리에 들긴 했지만 평소처럼 쉽사리 잠이 오지는 않는다.

가만히 수익률을 따져본다.
'낙찰가의 80%를 대출받으면 실제 필요한 돈은 세금포함해서 2억원 정도에 한달 만에 14억원 정도에 급매로 팔면 그 차익이 5억원 남짓!  세금 50%를 공제하고 나면......수익이  2억5천만원...!
허억! 입이 다물어 지지 않는다. 연수익률이 1000%를 넘어선다....!
수익률 계산 후 응찰가를 상향 조정했다. 9억을 넘겨보기로 했다.
끝자리는 평소 습관대로 8,400,000원를 붙이기로 했고 그래서 정해진 최종 응찰가는 908,400,000원이었다..!!
상계동 물건 낙찰 받을 당시와 응찰가의 구조가 비슷해 감이 좋았다.
더 이상 바꿀 일이 없기를 바라며 편안한 마음으로 잠자리에 들었다.
딸깍(형광등 불 끄는 소리.^^::)
(어둠....어둠,....)
잠깐 눈을 감았다 뜬것 같은데 벌써 아침이었다. 창가로 밀려드는 햇살이 눈부시다.
본능적으로 시계를 본다.
이런! 절망적인 탄식이 새어나왔다.


숨 막히는 긴장 속에서

9시였다!
밤늦도록 뒤척이다 새벽녘에야 겨우 잠들어 늦잠을 잔 것이다.
여기는 일산,  법정은 서울 서초동 중앙지법이었다....!
당장 해야 할 일들을 머릿속으로 정리해 본다.
은행에서 보증금을 수표 1장으로 끊고 곧바로 올림픽대로를 달려 중앙지법까지 최소 1시간 30분.....
 빠듯하다는 생각이 드는 것과 동시에 움직이기 시작했다.

부산부산.....우왕좌왕.....안절부절......!

서울 중앙지법 앞에 도착하여 무사히 차량을 주차한 뒤 시계를 보았다.
10시 30분!
중앙지법은 입찰마감시간이 11시 20분까지니 시간은 충분했다.
예전보다는 다소 한산해진 법정분위기.
경매붐도 그저 한 때 뿐일런가!
입찰표를 받아들고 심호흡을 한번 했다.
어제 정해놓은 응찰가가 908,400,000원! 
조금 더 올려 볼까, 잠깐 유혹이 있었지만 평소 원칙대로 하기로 했다.
경매장 분위기에 휩쓸려 응찰가를 조정하지 않는다!! 
금과옥조처럼 지켜져야 할 경매의 기본인 것이다.
입찰표를 작성하는데 괜스리 천원단위 끝자리가 신경이 쓰였다.
혹시 몰라 천원단위 기재 란에 살며시 1자를 그었다. 천원단위까지 신경써보긴 처음이었다.좋은 물건이라는 욕심에 신중을 기한다고 써넣은 것이었지만 나중에 얼굴 붉어지는 사건의 발단이 될 줄이야...!


입찰표를 넣고 기다린다. 당일은 두개의 경매계 사건이 병합되어 진행되었다.
내 건은 사건번호는 빨랐지만 앞선 경매계 사건이 모두 끝난 후 진행된다고 하니 1시간 이상은 여유가 있었다.
밖에서 커피한잔을 뽑아 마시고 있는데 누군가가 가볍게 어깨에 손을 짚는다.
돌아보니 후배변호사였다. 경매법정 바로 옆 건물인 행정법원에 사건이 있었는데 궁금해서 들렸단다.
'형! 응찰가 얼마 썼어요?'
정말로 많이 궁금한지 눈이 반짝인다. 하긴 궁금할 만도 할 것이다.
많은 고민을 함께 나눈 물건이니......
' 908,400.000원!!!'  끝자리에 1천원을 더 써 넣은 것은 말하지 않았다. ^^::
'와~ 잘 쓰셨네요. 저도 그쯤 쓰면 될 듯했는데, 감 좋은데요...!!'
후배의 칭찬에 벌써부터 뭔가 된 듯한 느낌이 들어 가슴이 벅차올랐다.
경매법정 밖에서 이런저런 이야기를 나누는 중에  여러 사람들에 둘러싸인 채 상기된 얼굴로 발걸음을 옮기는 사람들이 하나둘 보이기 시작했다.

오늘의 주인공인 낙찰자들이다! 주변사람들은 은행직원이나 대출 알선업에 종사하는 사람들일 터이고!
모르는 사람들이 보면 인기스타에게 사인을 받으려 팬들이 몰려드는 풍경과 흡사하다!
오늘만이라도 낙찰의 기쁨을 맘껏 누리시기를...!
조용한 미소로 축복을 빌어 주었다.
그만 들어가 보자는 후배의 말에 상념을 접고 법정 안으로 들어갔다.
사건번호를 보니 앞으로 3건 진행 후에 우리 건이다.
슬슬 심장박동이 빨라지기 시작하고 숨소리가 불규칙해진다.
개찰이 얼마 남지 않았음을 알리는 내 몸속 기관들의 신호다.
앞선 사건들의 응찰자가 많지 않아 금방 우리차례가 되었다.

집행관 앞에 놓인 서류 봉투는 3장!!
오호! 후배변호사랑 눈이 마주쳤다. 말이 없어도 내가 무슨 말을 하고 싶어 하는지 알 것이다.
'너 변호사 때려 치고 박수무당 개업해라...!'
후배가 씨익 웃는다. 알아 들었다는 듯......
일단 후배의 추리 첫머리가 맞았으니 나머지도 맞아주기를....
속으로 기도를 하는데 조용하고 침착한 집행관의 음성이 마이크를 통해 흘러 나왔다..
'사건번호 0000번호에 응찰하신 분 호명하겠습니다. 누구, 누구, 누구씨 앞으로 나오세요.'
사뭇 어깨가 떨리고 발걸음이 흔들린다.
아.. ! 나는 언제쯤 이런 상황에서도 초연할 수 있는 고수가  되려는가!'
입찰표를 유심히 보고 있는 집행관의 눈빛이 심상치 않다.
혹시 입찰표 작성할 때 실수라도 했나?
예전에 상가물건을 입찰했다가 서너 명의 경쟁자를 물리치고 낙찰은 받았는데 보증금액과 응찰금액을 바꿔 써서 무효 처리됐었던 기억이 악몽처럼 떠오른다.

심호흡을 하며 마음을 가라앉히는데 각자의 응찰가가 불려진다...
'000씨,  810,000,000원! 여자이름!  일단 한명은 제꼈다!
000씨, 9억 8백.........!  헉! 목소리가 작아 이름을 못들었다!
집행관이 여기까지 말하고는 조금 뜸을 들인다. 손바닥이 축축해 지고 입이 마짝 마른다.
어떤 고수가 백만원 단위까지 나랑 같게 쓴 것이다!
이런!! 내 끝자리는 고작 401,000원인데...
10,000원단위까지 신경 쓰지 않은 경솔함이 뼈에 사무치게 후회되는 순간이었다......!


부끄러운 낙찰


집행관이 응찰가를 부르다 말고 유심히 입찰표를 살핀다.
그러더니 재차 응찰자를 호명하며 응찰가를 읽어 내려간다.
'000씨..! 908,401,000원 ....!  이런! 다른 사람 아닌 내 응찰가였다!
응찰가 중간 중간에 0자가 2개나 박혀 있으니 빠르게 읽어 내려가기가 쉽지 않아 멈칫했던 것이었다.
귀 끝까지 새빨개지는 듯한 느낌이 들었다.. 끝자리 1000원은 괜히 붙여 가지고!
''당황하지 말자. 아직까지 사람들은 저 복잡하고 촌스런 응찰가가 내 꺼라는 것을 모른다!'
심호흡으로 마음을 추스리고 태연한 척 했다....^^::


자...이제 마지막 사람이 남았다...!
그런데 이번에도 집행관이 바로 응찰가를 읽어 내려가지 않고 주춤한다.
그러더니 만회라도 하듯 재빨리 ''000씨! .... 888,850,000원.....!! 해버린다.
내거 보다는 덜 복잡하지만 그래도 빠르게 읽기에는 역시 다소 어려운 응찰가였다...!
2000만원 차이였다!
최고가 매수인으로 내 이름이 호명되는 소리..!
법정 끝에 서 있는 후배의 짧은 환호성도 환청처럼 들은 듯했다!
한바탕 크게 웃으며 외치고 싶었다.

‘나 오늘 2000만원짜리 엿 사먹었다~! '

더 이상 2000만원에 대한 미련은 없었다!


그런데 들뜬 기쁨도 잠시.....
최고가매수인을 호명하고 낙찰가를 재차 불러 주면서 집행관이 또 심하게 버벅인다.
''9억 8백...(뜸을 들이다가...^^::)....4십만...(또 뜸......TT) .. 1000원을 쓰신 000씨를 최고가 매수인으로 호명합니다!''
마지막에 1000원! 이라는 소리가 유난히 크게 귓전을 때렸다.
영수증 받으러 앞으로 나서기가 참으로 민망한 순간이었다.^^::
흑~ 내가 앞으로 다시는 천원단위 끝자리를 붙이나 봐라....TT

입찰봉투대신 영수증을 교부받고 나오면서 후배와 눈이 마주쳤다. 누가 먼저라고 할 것도 없이 각자 주먹을 들어  이마 언저리에서 살짝 맞부딪혔다!
뭔가를 이루어 냈을 때 하는 우리들만의 하이파이브였다....!

에필로그

이건 물건을 낙찰받자 마자 전세물건 소개해 줬던 공인 중개사를 찾아 갔습니다.
낙찰 받은 사실을 알리며 급매로 팔아 달라고 하자 놀라는 눈치입니다. 자기도 이건 물건이 경매로 나온지는 알고 있었는데 자금여력이 없어 못 들어 갔다고 합니다.
그러면서 한마디 합니다.
'야, 대단하시네. 거기 전입신고한 사람하고 주인하고 부부인 것은 어떻게 알아냈데요?'
대답대신 조용히 미소를  지어 주었습니다.
그 집 경비아저씨의 털털한 눈웃음이 떠오름과 동시에 그간의 일들이 주마등처럼 스쳐 지나갑니다. ^^

공인중개사한테 급매로 팔아달라고 부탁하니까 얼마를 받고 싶냐고 오히려 되물어 봅니다.
'한 17억원 정도 받았으면 좋겠는데....힘들겠지요...급매로 15억원 정도 받아주세요.'
공인중개사의 표정에 별다른 변화는 없었지만 조심스러운 목소리로 권합니다.
'예전에 아파트 경기 좋을 때는 가능하겠는데 요즘은 원체 거래가 뜸해서....14억원 정도면 보름 안에 해결해 드릴 수 있을 것 같은데...15억원은 좀 부담되네요. 그리고 이 물건 당장 팔지 말고 한 1년만 갖고 있어 보시지 그러세요. 내년에 정권 바뀌고 경기 좋아지면 20억원까지도 갈수 있을 것 같은데...... 내년 상반기 쯤 옆 삼성타운 입주가 끝나면 수요도 몰릴 것 같구요.'

자신의 영업보다는 고객의 이익을 최우선시하는 중개사가 마음에 들어 14억원에 급매로 팔아달라고 부탁하고는 돌아왔습니다.
일주일 후 무사히 낙찰허가 결정이 났고 현재 경락잔금대출을 신청 중입니다.
아파트 담보대출 규제가 강화되었다고는 해도 금융계에서 강남불패의 신화는 여전히 이어지고 있습니다. 평소 친분 있는 금융 알선사에게 문의해보니 낙찰가의 90%대출에 이율 또한 6.5%~7%까지 가능하답니다....수익률이 조금 더 올라갈 것 같습니다. ^^

아직 잔금도 안냈는데 벌써 공인중개사에게 연락이 왔습니다. 2명 정도가 집을 보기를 원한다고......
 월세문의도 있습니다. 보증금 1억원에 월 400만원에 들어오겠다고 합니다.
월세로 돌려 투하원금 회수하고 은행이자를 월세로 막으면서 한 1년 갖고 있어 볼까?
잠깐 흔들리긴 했지만 그냥 급매로 내놓고 시세차익만큼 재투자하기로 마음먹었습니다.
남편 사업이 망해 한참 어려울 때인 전입자에게는 섭섭지 않은 이사비를 지급할 생각입니다.

-----
Cheers,
June