어쨌건간에 흘러가는 者

Introduction

한참이나 그간 언급되었고 언급되고 있는 소위 AI engineering 시리즈에 대한 개념 정리 노트이다. 이들 거대 개념을 수박 겉햝기나마 한 이유는 AI agent 설계 시에 내가 지금 어디 있는지, 어디로 가는 것인지를 알기 위함이다.
따라서, 아래부터 이어질 단정적 표현은 'fact'가 아닌 내가 이해한 수준, 즉 '의견'으로 받아들여지면 좋을 듯(내가 이들 개념 정의자도 아니고). AI가 초안쓰고 내가 감수(?) 및 편집하고 딴 AI가 내용 검증했다.

내용 요약하자면,

• prompt는 모델이 따를 말을 설계하고,
• context는 모델이 볼 정보를 설계하며,
• harness는 모델이 어겨도 시스템이 실패하지 않도록 실행 환경과 검증 가능한 경계를 설계하는 쪽에 가깝다.

Introduction

• Conventional Commits 을 강제화하기 위한 방법에 대한 논의이다.

Motivation

• versioning 자동화, git log 기반 release note 자동 생성을 위해서는 commit log가 규격화 되어 있어야 함. 대표적인 규격 : Conventional Commits

  • Conventional Commits 대표 link : https://www.conventionalcommits.org/en/v1.0.0/

Introduction

효과/효율적으로 release note 및 version 관리를 하기 위한 주요 규격 - Conventional Commits, Semantic Versioning, CHANGELOG.md에 관한 논의이다.

Motivation

• release note는 내용 상 git log와 겹침. git log와 별개로 release note 작성은 상당히 거추장스러움과 동시에 비효율적인 일.
• 따라서 git log를 잘만 활용하면 release note 생성은 자동화 가능
• 그리 비범하지 않은 아이디어인데 이미 open source로 마련되어 있을 듯.

평소 다니는 수영장이 휴관일이라서리 걍 쉴까... 했지만 근질거리는 몸을 못 참고, 게다가 youtube의 수영 동영상이 뽐뿌질을 하기에 결국에는 집 근처의 또 다른 수영장으로 직행.

먼저 sweet spot 현황

원래는 sweet spot이 아닌 active balance(sweet spot 자세에서 반대편 sweet spot으로 rolling하는  drill)을 연습하고자 한 것인데, 이를 위해서는 설명에도 보이듯 sweet spot 자세 마스터가 필수라서리.

sweet spot이 안도는 것은 여전하다. 오히려 손 뻗고 sweet spot은 어설프게나마 양쪽 모두 되었는데, 오늘은 이 마저도 안먹혔다. 나아가 잘만 되던  배면 눕기부터 흔들거렸다. 어찌어찌해서 배면 눕기까지 되었다 하더라도 옆으로 눕기를 진행하면 머리고 하체고 모두 가라앉기 시작. 얼굴 드러내기를 포기하고 아래를 바라보아도 하체는 여전히 가라앉았다.

• 연주곡 제목은 Rinaldo Overture로 Handel 곡이다.
• 영화 파리넬리에서 파리넬리가 몰래 감상하던 Handel의 파이프 오르간 연주, 바로 그 곡이다.
• 여러 트랙을 따로 연주하여 짬뽕한게 아니다. 한번에 몽땅. 따로 연주하여 믹싱하는 것이 내겐 더 어렵다.
• 사용한 (가상)악기는 Mainstage(3) + Kontakt Factory Library 내 Violin, Viola, Cello, Bass, Harpsichord.
• 연주하고 나서 진짜 String 연주같지 않은가! 하며 내심 좋아하고 있었는데, 가상악기란거 티 무지 난단다. 원곡처럼 파이프오르간 음색으로 연주하는 것이 더 그럴 듯 하다는 피드백이 있었다.

노자 도덕경 51장에서,

生而不有, 爲而不恃 (생이불유, 위이불시)

長而不宰, 是謂玄德 (장이부재, 시위현덕)

낳되 이를 소유하지 않고,

내일, 그러니깐 설 황금 연휴의 피크날. 근데 출근.

낼 모래 역시 출근.

황금연휴 피날레인 글피? 이 역시 출근.

그 다음 날은? 평일이니 당연히 출근.

본 내용은 MS Visual Studio 2008에 기반하며, 2010이나 2005 등에서도 별다를 바 없으리라 예상한다.

Remote Debugging 자체로만 보자면, 이를 위한 설정은 전혀 어려울 것이 없다. local에서 Attach to Process 하는 것과 다른 것이라곤 Remote Debugging Monitor를 디버그 대상 프로세스가 담긴 Remote Host에서 실행하는 단계 하나가 더 추가되었다고 할까?

하지만 항시 문제는 해당 과정까지의 환경 설정에서 발생하곤 하는데, Remote Debugging이 딱 그 꼴이다. Active Directory 등을 통한 동일 Domain 내의 Remote Host가 아닌 타 Domain의 Remote Host의 것을 하려다 보니 보안 관련 설정에서 당장에 문제로 다가온다. 난 꼬박 이틀 간 삽질했다. 어쨌건 아래 내용은 바로 이러한 상황에서의 Remote Debugging 방법이 되겠다.

1. Remote Host와 개발 Host 모두에 동일한 id/pwd의 계정을 생성한다.

다음은 실제 프로젝트에서 마주친 ADO.NET Entity Framework(이하 EF) 1.0의 주요 문제점이다. 그간의 문제점 먼저 짚어야 이야기 풀기가 용이할 듯 해서리... 이렇게 돌아서 간다.

1. POCO(Plain Old CLR Object) 미지원

• 기 사용되던 Entity 객체는 사용할 수 없다는 이야기. 신규 프로젝트에서도 자체 Entity 객체 구성이 일반적이기 때문에 EF 1.0에서 자동 생성하는 Entity 객체(이하 PAE(persistence-aware entity))는 오직 ORM(Object Relation Mapping)을 위한 부담으로 다가온다.

2. N-Tier 아키텍처 적용 시, DTO(Data Transfer Object) 수동 적용 필

ADO.NET Entity Framework 4.0의 개선 사항 (1/3)에 이어…

먼저 POCO 지원에 대해서 썰풀어 본다

http://weblogs.asp.net/gunnarpeipman/archive/2009/07/11/entity-framework-4-0-how-to-use-pocos.aspx

위 컬럼에서 나오는 직접 생성한 Entity 클래스를 보자. 부가 속성이 전혀 없는 POCO 그대로이다. 당연스럽게도 LINQ를 통한 편리한 조회 연산에서 CUD(Create Update Delete) 연산까지 모두 지원한다. 또한 POCO 생성 도구 역시 지원하는데, 이는 따로 설치해야 하며 해당 템플릿은 요기에서 받으면 된다. 템플릿은 T4(Text Template Transformation Toolkit) 기반이며 당연히 수정 가능하기에 입맛대로 여러 spec을 끼워 프로젝트에 적용하면 되겠다. 슬쩍 보니 사용법 익히는데 그리 많은 시간이 필요할 것 같지는 않다(XSLT 기반보다는 훨 쉬워 보인다).

http://www.sysnet.pe.kr/Default.aspx?mode=0&sub=0&detail=1&wid=217

알고보니 위와 같이 프로그래머 사이에서도 쓰래기 취급을 받는 프로그램이었다는.

내 경우는 이야기가 다른데, 갑자기 10~20초 단위로 윈도우 포커스가 다른 곳으로 튀었다가 다시 돌아오는 증상을 일으키는 것이다. 이로 인해 글을 쓰건 뭔 작업을 하건간에 해당 작업이 위 주기로 끊기게 된다. 한마디로 말해 엄청난 짜증을 불러 일으킨다는 이야기이다.

재미있는건 위 증상을 일으키는 장본인이 nProtect의 프로세스 중 하나인 'npnj5Agent.exe' 인데, 이놈은 작업 관리자에서도 해당 파일이 어디에 붙어있는지 알 수 없다. 또한 위 주기로 생성/소멸을 반복하는 이놈을 완전히 죽이기 위해서는 결국 호스트 프로세스까지 찾아 죽여야 한다는 뜻인데, 위와 같은 실행 속성으로 인해 강제 프로세스 종료 역시 쉽지 않다.

이제는 쓸 때 없는 저항 의식에서 벋어나 자신의 삶을 관조하는 자세로 임했다...

'대망(大望)' 에 묘사된 형장 이슬로 가기까지의 미쓰나리.

그렇게나 그 분에 대한 많은 배신을 이루고도, 어느새인가 또다시 그 분을 찾는 나의 나약함을 보면서, 또한 잠시나마 그 분의 힘에 기대어 평정심을 유지하는 나를 보면서 이 글귀가 생각났다.

어느새 인가 그를 휘두르려 하고, 그의 반응에 어느새 또다시 대응하는 나 자신의 모습에, 그러한 나의 유약함에 고통스러웠던 것이었겠지. 언제나 옳은 자세라고는 확신하지 못하지만, 적어도 지금의 내게 가장 필요한 것은 이러한 마음을 유지하고자 하는 지속적 의지와 행동이다. 그리고 이를 흩게 만드는 그 모든 요소가 바로 '유혹'이라 부르는 것이겠지.

그것은 일종의 감성적 충돌인가? 묘한, 정제되지 못한 습관에서 비롯한 보호막인가? 강한 눈빛과 함께 나타나는 굳은 표정은 유약함의 또다른 모습?

더 이상 잠을 통한 회피를 요구하지는 않는 듯 싶다. 고통의 순간 마저도 삶 자체가 이루는 수많은 변화, 다양성이 주는 또다른 자극으로 음미하는 여유가 생기는 듯. 그렇다고 그러한 여유를 느끼는 양상이 자연스럽게 찾아오는 수준은 아니다. 그 고통을 받아들이는 하나의 방법으로서, 내 삶의 관성에 저항하는 의도적 노력을 필요로 하니까.

Definition

• 상속 시 부모와 자식의 관계가 반드시 IS-A 관계를 유지하도록, 좀더 정확히 하자면, 부모를 치환(substitution) 가능한 자식을 만들도록.
• 상속 관계 코드 작성 시의 원칙. Base type의 사용 조건을 derived type에서 모두 따를 수 있도록

LSP violated sample

• LineClient.DoSomething()은 해당 매개변수(line) 위의 모든 점에서 IsOn() == true를 기대하고 코드 작성 가능.

  • 하지만 선분인 LineSegment instance를 LineClient.DoSomething()의 매개변수로 넘길 경우, IsOn() == false가 가능함으로 LineClient.DoSomething()은 유효하지 않은 코드가 됨.

Agile의 주안점

• 변화에 대한 능동적 대처 : dependency의 최소화

Application의 주요 문제

상기문제를 해결하기 위한 주요원칙 (SOLID)

Definition

• 클래스는 단일 책임 만이 따르도록. 좀더 나은 표현으로, 단 한가지의 변경 이유만을 가지도록
• Cohesion(응집도) 증대 원칙

SRP violated sample

특징

좀 긴가민가했던 .NET core 관련 내용을 정리하다가, 올바른 unmanaged 리소스 청소법을 위한 '지저분하기 짝이 없는, 그러나 반드시 알아야 하는' Finalize, IDisposable에 다다랐는데, 흥미롭게도 C# 쪽 pattern과 C++/CLI 쪽 pattern이 (적어도 표면 상으로는) 완연히 다르다는 사실을 발견.

본 사항은 정상적 application 구현을 위해서는 반드시 숙지해야 할 내용인데, 언어 별로 그리도 달라서야 원. 게다가, C++/CLI 쪽 MSDN 설명은 뭔가 하나 빠진 듯 하여 다 읽고 나서도 제대로 이해가 가질 않는다. 언어 별로 따로 익혀야 하는 것도 거시기한데, 설명이라도 제대로 해야지.

먼저, C#쪽 pattern. MSDN에 떡하니 올라와 있는 정형화된 pattern이다.

암만 봐도 복잡하기 짝이 없는 패턴. 하지만 이보다 더 단순한 패턴을 내 머리로 만들어낼 궁리는 안한다(나올 가능성도 거의 없겠지만). 다음은 상기 사항에 대한 C++/CLI 쪽 pattern. 이 역시 MSDN에 명시된 내용이다.

子夏曰 君子는 信而後에 勞其民이니 未信則以爲厲己也니라 信而後에 諫이니 未信則以爲謗己也니라.

자하가 말했다. 군자는 믿음을 얻은 후에야 그 백성들에게 일을 시킨다. 만약 믿음을 얻지 못한 상태에서 일을 시키면, 백성들은 자신들이 괴롭힘을 당하는 것이라고 생각하는 법이다. 또, 군자는 믿음을 얻은 후에야 윗사람의 잘못을 간하는 법이니, 만약 믿음을 얻지 못한 상태에서 간언한다면 윗사람은 자신이 비방당하고 있다고 여기게 된다.

논어 자장편 중에 있다고(원문 링크)

어릴 적 유교적 가르침에 맘 고생이 심했던지라 위와 같은 문구를 보면 덮어두고 무시해버렸는데, 나이를 먹어서 그런지 이런 문구가 눈에 들어오기도 한다.

ITU-T 권고안 : X.800 Security Architecture for OSI

• 보안성을 위한 조직적 작업을 이루는 Guideline을 제시

• 국제 표준이며, 아래를 다룸

  • Security Attack
  • Security mechanism: security attack에 대한 검출, 예방, 회복을 위한 설계
  • Security Service: 시스템에 대한 보안성 향상을 위한 서비스. Security attack에 대항한 Security mechanism의 활용

  참고

  • ITU-T (The International Telecommunication Union Telecommunication Standardization Sector)
  • OSI : Open Systems Interconnection
  • The OSI security architecture는 OSI protocol architecture의 문맥 아래 개발됨

동일한 내용의 코드를 세가지 버전으로 작성해내는 프로그래머의 모범적 자세... 라고 표현하면 나름 위로가 되기도 하겠지만, 최종 코드를 만들고 나니 이미 숱하게 보았던, 하지만 언제나 쉽사리 지나쳤던 바로 그 루틴이었다는데서 느끼는 허탈감.

배경

삽질 1 : 좆 Windows Messaging. COM에서의 프로세스간 동기/비동기 호출 의 그것과 동일하다. out of process에서 동작하는 COM Server와 통신하는 COM Client. 인스턴스로 올라간 COM Server에 client가 달라붙기 위해서 Running Object Table에 Server를 등록하고, client는 이 테이블에서 해당 Server를 찾아 연결하기까지의 내용. 알고보면 IPC(Inter Process Communication)를 이루는 가장 쉬운 방법(동기화 문제는 물론이요, 개체 기반 프로그래밍 패러다임까지 그대로 보존한 채 이를 이루기에)이 되겠다.

첫 번째 버전

배경

1. ROT(Running Object Table)를 통해 IPC(Inter-Process Communication)통신을 이루는 COM Server/Client. 본 채널을 가리켜 lightweight RPC라고 한다나?(Server와 Client 모두 동일 호스트에서 동작하기 때문에 RPC는 아니라고).
2. COM Server는 USB 드라이브와 통신하며, COM Client는 IE browser에 내장되어 Server와 연결짓는 역할(따라서 COM client 역시 browser를 위한 COM Server 역할을 담당). Client의 메서드와 이벤트는 javascript를 통해 호출 및 수신한다.
3. COM Server/Client 모두의 threading model은 STA(Single Thread Apartment).
4. COM Server 쪽에는 UI가 있어 내장 IE Browser가 달려있음.

문제

1. COM Server 메서드 호출은 성공. 허나 COM Server에서 event firing시 Fire 위치에 따라 성공 또는 실패하는 황당한 상황이 발생. 실패 시 HRESULT 값 : 0x8001010d(An outgoing call cannot be made since the application is dispatching an input-synchronous call)
2. 우연찮게 COM Server의 threading model을 MTA(Multi Thread Apartment)로 바꿨더니, 1의 문제가 사라짐. 하지만 내장 IE Browser window의 위치가 desktop window origin에 달라붙어 떨어지지 않는 상황이 발생(MoveWindow() 등의 API가 전혀 안먹음).

ATL Control Containment FAQ: VS2005 / .NET 2.0

ATL Control Containment FAQ: VS2008 / .NET 3.5

핵심만 간단히 찌르고 들어간듯 한 느낌인데?(IOleObject::DoVerb에서 E_NOINTERFACE란 엉뚱한 RETURN VALUE를 만나고 나서). 그토록이나 호스팅하는데 삽질했던 IE 컨트롤을, CAxWindow::Create() 매개변수에 URL만 넣으면 알아서 IE 컨트롤이 호스팅되는 황당한 사태가. 근데 왠 설명서가 버전별로 달라지는거야.

Creating Signed CAB Files for MFC and ATL Controls

COM Threading Model의 필요성

• in-process server를 제외한 COM 서버는 기본적으로 단일 COM 개체에 여러 클라이언트 스래드가 접근 가능한 다중스래드 환경에 노출되어 있다. 바로 이 클라이언트의 접근 동기화를 위해 COM threading model이 존재한다.

COM Threading Models

• single-threading model, apartment-threading model, free-threading(multi-threaded) model, mixed-threading(apartment 및 free-threading 지원) model, neutral model의 총 5가지 모델이 존재한다(명칭이 혼란스럽다. free-threading, mixed-threading model, neutral model 역시 apartment를 통한 threading 모델이다. 여기서는 apartment-threading model까지 포함한 이들을 가리켜 Apartment 연관 모델이라 지칭하겠다).
• COM 라이브러리를 사용하기 전에 반드시 호출해야 하는 CoInitializeEx()이 바로 이 모델 지정에 사용된다.
• 클라이언트와 COM 서버의 threading model이 서로 다르더라도 COM run-time 라이브러리가 이들 간 통신을 thread-safe하게 조절하지만, 성능 저하가 발생한다.

COM 구조에 관한 스터디 중 Inteface 지원을 위한 vptr 및 vtable에 관한 내용을 보다, 직접 vptr과 vtable memory layout을 쑤셔보고자 시작. 이 내용을 한두번 본 것도 아닌데 또다시 그냥 지나치려니 영 감질 맛이 나는거다. 하긴, 지금 아니면 언제 이 구조를 뜯어보겠어?

일단, vtable은 함수 포인터의 배열로 이루어진 가상함수 테이블을 의미하며, vptr은 vtable을 가리키는 C++ 개체에 숨겨진 포인터를 뜻한다. 이들 vtable 및 vptr이란 명칭은 관례적으로 그리 사용한다고. 물론 가상함수가 없는(해당 클래스에 virtual 키워드가 없는) 개체는 이들 둘 모두 없다. 따라서 해당 개체의 크기는 vptr의 크기(32bit OS일 경우 4byte)만큼 작아지겠다.

앞으로 보일 예제는 32bit WindowsXP 위의 Visual C++ 2005 버전으로 테스트한 것이다. 참고로, C++ 표준은 vptr의 개체내 위치나 vtable 구현법에 대해 지정하지 않는다고 한다. 따라서 컴파일러에 따라 결과는 달라질 것이다.

확인할 사항은 첫째 vptr 및 vtable의 존재 여부와 다중 상속시 vptr의 개수이다. 확인 방법은 직접 vptr과 vtable의 포인터를 얻어, 이들 포인터를 통해 각 가상 함수를 호출하는 것이다. 다음은 이를 확인해 줄 마루타 클래스들. 순수 추상 클래스까지나 쓸 필요는 없었지만 COM 인터페이스 구현을 모방하기 위해 일부러 이를 선택했다.

반성.. 아니, 지나간 과거를 뒤돌아볼 때, 회고를 할 때, 나이를 먹어 달라지는 부분 중 하나가 개별 사건을 추상화하여 크게 묶어 처리하는 것이다. 그리하게 된 이유는 무엇일까? 먼저 반성의 경우, 반성을 위한 기준, 즉 덕 자체가 추상적 용어로 표현되므로 사건에 대한 표현 자체를 그 수준으로 끌어올려야만 하기 때문일 것이다. 또한, 사건의 양이 많은 경우, 개개의 사건 모두에 공통된 냄새가 풍기는 경우에는 그 공통된 원인을 찾고자 추상화를 사용하는 것일 터이다. 나이가 들고 경험이 쌓였기에 가능할 터이지. 어쨌건 이들 모두는 제대로 된 회고를 위해 올바르게 사용한 것이다.

헌데, 이러한 이유에서만 추상화를 사용하지만은 않는 것 같다. 올바로 회고를 하려면 구체적 사건 자체를 똑바로 들여다볼 줄 알아야 한다. 당연한 이야기이다. 하지만, 그 사건이 나를 두렵게 하는 것이라면, 바라보는 것 자체가 두려움을 불러일으킨다면, 그러했던 나를 인정하기 싫다면, 그러한 상태임에도 나의 이성은 회고를 요구하는 상황인 경우, 나는 그 사건을 최대한 빨리 흟고, 잽싸게 그 사건을 추상적 용어 안에 가두어버린다. 그리고는 그 사건을 두 번 다시 떠올리지 않는다. 그 사건을 가두어 놓은 추상적 용어가 과연 그 사건에 맞는지 확인하는 절차는 재껴버린다.

여전히 그 사건은 내게 두려움을 주는 대상이다. 하지만, 나는 그 사건을 정리하였다. 도대체 뭘 정리한 거야!

그리하여 얻어낸 그 추상적 용어는 또 다른 의문을 불러일으킨다. 왜 내가 그리하였지? 왜 난 그럴까, 왜 난 그런 놈인가, 왜 난 그런 놈이었을까. 그 용어가 원인을 찾는 키워드였다면 그나마 다행이겠지만,  헛다리에 다름 아닌 용어라면 그 뒤로 얻어내는 원인 전부 역시 헛다리가 된다. 이 과정이 만약 단순 '회고'가 아닌 '반성'이 된다면, 나는 엄한 곳을, 멀쩡한 곳을 찌른 것이 된다. 결국, 이는 회복이 아닌 악화이다. 과할 때는 피투성이가 된다. 졸라 아프다. 아... 이게 바로 '자학'이였구나.

먼저, 기술사 프로젝트 일기의 141 ~ 168일차, 21 ~ 24주차 정리. 날짜로 따지면 07.11.26 부터 07.12.23까지가 되겠구만. 오늘까지말야.

그간 공부량은 주당 15시간 정도 치면 대강 나오리라 생각한다. 평일에는 거의 공부할 생각을 못한다. 일찍 퇴근한다고 해도 그간의 흐트러진 리듬으로 인해 공부되는 법이 거의 없다. 덕분에 '미녀들의 수다' 시청량만 왕창 늘었네. 대략 4주... 한 달을 날려먹었다. 왜 그랬냐고? 바로 아래 때문에.

프로젝트 막판, 윗대가리의 좆지랄

현재 진행하는 프로젝트 초기에는 12월 한달은 놀면서 여유있게 끝나겠다 싶었는데, 그럴리가 없지.. 프로젝트에 여유가 있으면 위에서는 당장 사람을 빼간다. 어떻게해서든 '지랄'을 떨게 만드는 것이 우리네 윗대가리들의 기본 개념? 아니, 이건 '개념없는 행동'이라 표현하는 것이 더욱 올바른 평가이겠다.

캐시를 위한 두가지 방식

• Write Through: 캐시 갱신 때마다 주기억장치를 동시에 갱신
• Write Back: 주기억장치는 캐시 라인이 캐시로부터 제거(flush)될 때만 갱신

캐시 일관성 문제

SMP와 같은 공유 메모리 방식의 병렬 컴퓨터에서 주기억 장치(공유 메모리)와 캐시에 저장된 데이터가 달라지는 현상. 캐시 내의 데이터가 변경되면 주기억장치 내의 해당 단어 뿐 아니라 다른 캐시 내의 그 단어도 무효가 된다. Write Through 방식 역시 갱신된 캐시와 주기억장치의 데이터는 동일하지만 타 캐시의 데이터가 무효가 되므로 캐시 일관성 문제가 발생될 수 있다.

• 07.11.19, 134일차: --
• 07.11.20, 135일차: 2.2시간
• 07.10.21, 136일차: 6시간
• 07.11.22, 137일차: —
• 07.11.23, 138일차: 3.8시간
• 07.11.24, 139일차: 8시간
• 07.11.25, 140일차: 8시간

켁. 다음 주가 아주~ 두려워진다. 금주 토픽을 전혀 준비안해서리, 내 페이스대로 걍 밀고나가다보니 스터디 준비를 전혀 안했고, 앗싸~ 걍 스터디를 빠져버림. 아예 한발 더 나아가 갈무리까지 개무시! 담주 수욜에 멘토님을 모시고 단합대회하기로 했는데, 멘토님이 날 보면 뭐라고 하실까? 종락씨 왈, 술김에 팰지도 모른다는 무시무시한 야그를... 헐헐.

그래도 울 멘토님의 사상이 넘 맘에 드는 것은 이해를 기반으로 한 정석 플레이를 추구한다는 것. 모범답안형... 그러니까 딱 들어맞는 참고서형 답안은 개무시대상이라고 한다. 실제 채점도 그런 식으로 이루어진다는 조언과 함께~. 해서 나는 요즘 또다시 프로시딩, 엥라퍼 개무시 모드로 돌입하고 있다. 까짓거 떨어지면 어떠하리.. 하는 아주 곱상치 못한 자기 위안형 잔머리와 함께. 헤헤.

Computer Architecture는 그야말로 이 계통의 핵심인데, 이 놈의 시험은 본 과목을 너무 무시한다. 그나마 전자계산조직응용이니까 비중이 좀 있지.. 정보관리쪽은 왕 개무시 모드. 암만봐도 말장난 같은 소프트웨어공학은 뭐그리 강조하는지 몰라... 하긴 이해할만도 한 것이 전산 영역의 대부분을 차지하는, 그리고 대부분이 몸담게 될 SI영역이 결국 대규모 프로젝트이기에 어쩔 수 없겠지..

• 07.11.12, 127일차: 3.8시간
• 07.11.13, 128일차: 3.2시간
• 07.10.14, 129일차: --
• 07.11.15, 130일차: --
• 07.11.16, 131일차: 2.0시간
• 07.11.17, 132일차: 10시간
• 07.11.18, 133일차: 6시간

총 공부량 25시간. 슬슬 손바닥 노트를 정리해야겠다 싶은데, 아직도 상당수 토픽이 뭘 중점으로 적어야하는지 모르기 땜시 어정쩡한 상태. 금주는 나름 해당 토픽 거반을 공부해가서 셤 성적이 좋을 것이라 기대했는데 이게 왠걸.. 몇몇 미처 준비못했던 토픽에서 와장창 나와버렸네. 멘토님 왈 '노력은 하는구만' 하는데, 글쎄.. 내가 과연 노력이나 하는지 몰겠다.

기대를 별로 안하는 생각때문인지 시험을 죽쓰건, 공부량이 모자라건 이전처럼 맘이 급박하지가 않다. 아니.. 열정이 사라진 것 같은 느낌이 들기도 하고. 어찌되었건 시간은 아주 자알 가는구만.. 후훔..

헝거리언 표기법에서는 접두어로서 타입의 특징을 나타내는 축약어를 사용하는데, User Defined Type이 많아질수록, 그 타입의 특징을 나타내는 축약어를 만들기가 힘들어지더라(class등의 User Defined Type이 많아지는 것은 Object Oriented Language를 사용하면 당연히 나타나는 현상).

C/C++ User Journal에 나온 Hungarian Notation 반대에 관한, Herb Sutter와 어떤 사람의 썰~. (member 변수 명명에는 camelCase에 접미어로 underbar(_)를 붙이라니.. 지저분한데.. 차라리 'm_'가 더 나아 보이는데..)

Conversations: Hungarian wartHogs by Jim Hyslop and Herb Sutter

위에까지는 05년 6월 14일에 이전 블로그에 적어둔 썰. 다음은 Modern C++ Design에 알렉산드레스쿠(!! 이름 함 지랄스럽다)가 Herb Sutter의 표기법이라며 추천한 위 대화의 결과물.

총 공부량은 대강 12시간 정도. 주중에는 또다시 중간 발표와 이로 인해 리듬이 깨져서 아예 공부를 못했다. 토욜에는 시간이 만빵 남았음에도 한 6시간 정도 했나? 계속되는 대박 수준.

자료를 찾지않고 앵라퍼를 정리하여 숙제해갔더니만, 담당 기술사께서 바로 날리는 한마디. '쳇!'

단음절 하나만으로도 그토록 가슴을 찌를 수 있을 줄은 생각도 못했네.

내가 맡은 토픽에서 단 한문제만 나왔음에도 불구하고 나름 선방을 했다. 이렇게 긍정적(?) 평가를 내릴 수 있는 단 하나의 이유. 반즘 포기하고 시험에 임하는, 따라서 기대치를 확실히 낮추는 마인드 컨트롤, 자기 방어 내공이 쌓였기 때문. 실 내공은 쌓이지 않고 잡스러운 내공만 잔뜩 쌓여간다. 푸헤헤.

• 07.10.29, 113일차: 1시간
• 07.10.30, 114일차: 4시간
• 07.10.31, 115일차: 3.8시간
• 07.11.01, 116일차: 3시간
• 07.11.02, 117일차: --
• 07.11.03, 118일차: 11시간
• 07.11.04, 119일차: 5시간

총 공부량 27.8시간. AMP 시작. 이틀간 독서실에서 스터디. 아... 거반 일주일이나 지난 시점에서 쓰려니 영 생각이 나질 않는군. 아…

07.10.22 ~ 07.10.28. 106 ~ 112일차 총 공부량은 대략 10시간. 대박이다~!

그래도 나는 할 말이 남아있다. 이미 리듬이 깨져가는 사이 Workshop으로 완벽하게 박살났기 때문이라고. 여하간 공부 지질라게도 안했고, 또 안되었다. 그 와중에도 안된 원인을 찾는다면 책상 머리에 컴퓨터가 있었기 때문이라고. 인터넷이 있었기 때문이라고. 해서 결심한다. 고3 모드의 독서실로 가자~!

AMS 과정이 끝났다. 나름 심화과정이었는데 내 수준이 심화되었는지는 긴가민가. 말로만 듣던 대박 고수들의 집단인 AMP과정으로 넘어가기는 하는데, 내가 과연 따라 붙을 수 있을까 심히 의심된다. 방해만 놓게되는건 아닌지 모르겠다. 그나마 다행인 것은 함께하는 새로운 조원들이 이전 과정에서 함께 했던 사람들이 대부분이란 사실.

새 멘토 기술사님은 이전 기술사님의 멘토이셨다고. 이렇게 되면 무협지로 따지면 '태사부님' 비스무리하게 되는 건가? 10명 중 8명을 붙이신 대박 기술사님. 오리엔테이션에서의 느낌.. 포스가 장난아니다.

• 07.10.15, 99일차: 4.8시간
• 07.10.16, 100일차: 3.0시간
• 07.10.17, 101일차: --
• 07.10.18, 102일차: --
• 07.10.19, 103일차: 5.0시간
• 07.10.20, 104일차: 5.0시간(스터디)
• 07.10.21, 105일차: 갈무리(모의 시험)

이번에는 총 공부량에 대해선 적지 않겠다. 맘이 너무 아파올 것이기 때문이다. 대신 매우 불만스러운 나의 의지력에 대해 위로를 해주겠다. '워크샵 준비를 했기 때문에 어쩔 수 없던 거야. 별수 있었니?' 나 자신을 속이는 짓이 될 수도 있겠고, 실제로 그러했다고도 느껴지지만 핑계김에 아예 한주 푸욱 쉴 생각도 한 몫 작용.

갈무리는 저번 시험보다 '상당히' 어려웠다. 그럼에도 불구 1교시를 제외한 2, 3, 4교시 모두 4문제를 전부 채우는 대사건이 발생. 성적이야 뻔하겠지만 그래도 나름 발전했다는 뜻이 아니겠어? 일정 수준의 구라를 푸는 것도 실력이라고 생각한다. '상상력'을 발휘하는 것이 얼마나 힘든 일인데.. 그것도 제한된 시간 안에 말야.

갑자기 타 기술사님의 공부 후기에 대해 생각이 난다. 갈무리 후 그날 반드시 복습을 했다고. 나는 이날 본가로 직행했다. 시험문제는 꺼내보지도 않았네. 함께 시험을 쳤던 상훈이형에게 한마디를 날리면서. '시험 꼴도 보기 싫어요~!'

패턴에 이끌려 직시해야만 하는 사건에 대해 무심코 지나쳐버리는 행태.

'자연스러움', '연속성', '부드러움'이란 DOGMA에 이끌려 '인위적 자연스러움'을 만들어내고 있다는 느낌.

이들 표상은 외부에서 바라보았을 때, 그러함을 만들어냐는 당사자가 아닌 제 3자가 마주쳤을 때에 느끼게 되는 것들이 아닌가! 내가 그런 표면적 모습에 얽매일 필요가 있던가? 이미 그럴 필요가 없음을 알고 있음에도 불구하고 자꾸 끌려가는 이유는 무엇인가?

그다지 맛좋지 않은 감각이 계속하여 느껴지고 있음에도 불구하고, 어느새 나는 그러한 느낌을 주는 무엇의 정체를 알아내려는 노력을 게을리하고 있었다.

• 07.10.08, 92일차: 4.5시간
• 07.10.09, 93일차: 4.5시간
• 07.10.10, 94일차: 1.8시간
• 07.10.10, 95일차: --
• 07.10.10, 96일차: 5.0시간
• 07.10.10, 97일차: 5.0시간(스터디)
• 07.10.10, 98일차: 5.5시간

총 26.3시간. 푸념도 한두번해야 들을만 하지, 한두번해야 쓸 맛이 나지. 주욱~ 잘도 떨어진다. 그래도 한번더 핑계를 대보겠다. '스터디 동료들 모두 슬럼프여서 나도 거기에 동참했어요~!'

그간 회사 레디에이터 위에서 선 잠을 자가며 공부시간을 늘렸는데, 이젠 이것도 못해먹겠다. 이런 노숙자틱한 생활이 몸에 배버린건가? 레디에이터 위에서 마저 잠이 아주 '자알~' 오는 것이다. 언제나 일어나면 아침 6시. 무섭다니깐.

내 몸뚱아리에 대한 통제력 부제를 절감하고 있다. 어릴 때나 지금이나 이놈의 것에 대한 고민은 여전하군.

분산 시스템의 정의

물리적으로 분리된 상태에서 컴퓨터 통신 네트워크를 통해 약결합(Loosely Coupled)을 이루는 정보 시스템의 집합

분산 시스템의 특징

downsizing이란 새로운 산업화 경향을 이끌어냄(예: 메인 프레임을 네트워크로 연결된 워크스테이션 및 PC로 대치함으로 비용대비 성능의 급격한 향상을 가져옴)

• 07.10.01, 85일차: 4.4시간
• 07.10.02, 86일차: --
• 07.10.03, 87일차: 8.2시간
• 07.10.04, 88일차: --
• 07.10.05, 89일차: 7시간
• 07.10.06, 90일차: 5시간
• 07.10.07, 91일차: 5.5시간

총 30.1시간. 슬럼프가 맞는건가? 아니다. 이는 슬럼프라고 볼 수 없다. 슬럼프란 얼마간 정상 괘도를 밟고 있다가 잠시 이탈한 상태를 뜻하기 때문이다. 나에게는 정상 상태가 없었으므로 슬럼프라는 것이 있을 수가 없다. 썅.

투자한 시간 대비 효과가 아주 좋지 않다. 언제나 고민되었던 사항이지만 결국에는 공부 방법으로 그 원인이 귀결되는 듯. 과하다 싶을 정도로 강의 자료를 무시하는 행위, 특정 토픽에 필요 이상으로, 아주 과하게 많은 시간을 쏟는 행위에 대강 짚혀온다. 짚혀온다기보다는 나를 바라본 같은 팀원들의 조언, 그리고 담당 기술사님의 한마디에 인정할 수 밖에 없는 상황이다. 집중력 태부족도 원인 중 하나이고.

이래저래 댈 핑계꺼리야 많다. 하지만, 언제나 그러했지만 결과가 모든 것을 증명해주는 법. 그럴 수 밖에 없는 상황. 나의 방법에 달리 정당성을 부여한다 하더라도 결과가 성격을 바꿔버린다. 단지 핑계일 뿐이라고.

• 07.09.24, 78일차: 10시간
• 07.09.25, 79일차: 10시간
• 07.09.26, 80일차: 7.5시간
• 07.09.27, 81일차: 4.5시간
• 07.09.28, 82일차: 4.0시간
• 07.09.29, 83일차: 6시간
• 07.09.30, 84일차: -- (모의고사)

총 41.5시간. 어떻게 해서건 전 주에 모자랐던 4시간을 만회해보려 했지만, 월, 화, 수 연달아 생긴 추석 연휴에 충분히 그럴만도 했지만 결국 실패. 이야... 이거 휴일의 그 많던 시간을 조금 더 채우는 것이 뭐가 그리 힘들어. 고1 때 담임이 주창했던 6 - 9 - 12 공부 시간(평일 - 토요일 - 일요일)은 그 때나 지금이나 내게는 황당하기 짝이없는 공부시간이다.

문제는 투자대비 공부시간이 부족하다는 것. 대략 투자시간의 2/5은 어떤 형태로건 간에 날라가버리는 시간이다. 10시간을 투자했으면 6시간만 공부한다는 이야기. 내 집중력의 현실을 아주 잘 보여준다. 특히 3일차 즈음에서 급격히 집중력이 저하됨.

모의고사는 그럭저럭 보았다는 느낌. 합격에 근접한 점수를 기대할 수 있다는 이야기는 절대 아니라, 이전 시험에 비해 조금 더 나아진 것이라고나 할까? 답지 14페이지를 다 채우는 것은 택도 없고... 끽 해야 9페이지 정도 채웠나? 10 - 4 - 4 - 4 의 필답 개수 중 8 - 3 - 4 - 3 정도이니. 답을 전혀 모르기 때문에 못 푼 것도 그렇거니와, 쓰기 속도 자체도 여전히 주요 문제 중 하나. 악필이란 문제도 아주 신경 거슬리는 사항 중 하나다. 얼마나 출제자의 의도에 맞게 답을 정확하게 적었는가, 창조적 답안, 마지막 단락에서의 정리 등의 사항을 고려하기엔 아직 나는 '격'이 안되어 있다.

• 07.09.17, 71일차: 1.5시간
• 07.09.18, 72일차: 3.5시간
• 07.09.19, 73일차: 6.3시간
• 07.09.20, 74일차: 4.5시간
• 07.09.21, 75일차: --
• 07.09.22, 76일차: 10시간
• 07.09.23, 77일차: 10시간

총 35.8시간. 75일차 금요일의 공백을 어떻게해서든지 휴일중에 매꿀려고 해보았지만 10시간 채우기도 핵핵. 주 40시간.. 거 정말이지 만만치 않다.

전주 주말 모의 시험에서 완전 낙담, 우울. 블랙박스 테스트(동등분할, 경계값 분석, 오류 예측... 그리고 하나가 더 있는데, 또 까먹었군. '원인 결과 기법'!) 하나가 완전 뒤통수를 후려친다. 이번까지 무려 3번이나 나왔던 문제인데, 여전히 못쓰다니! 그럼 나머지 문제는 잘 썼느냐고? 6문제 채우기 중에 4문제 얼렁뚱땅 겨우. 2문제는 손도 못댔다는 이 한심한 현실. 설상가상으로 같은 조 다른 팀원의 답안을 보니... 아니, 이놈들이 문제를 낸거야? 똑같이 공부해놓고 어찌 그리 이쁘장(!)한 답안이 나올 수 있을꼬? 충격과 우울속에서 지낸 스터디였다.

금주 스터디 과목은 C/A. 그나마 기술사 과목 중 가장 자신있는 과목인데, 뭔놈의 새로운 토픽, 이슈가 그리도 많냐... 겨우 한번 전체를 흟어봄. 하루 5개의 수기를 통한 토픽 정리? 택도 없다. 수기도 수기 나름이지... 걍 배껴쓰는 것은 역시나 아무런 도움이 되지 못한다.

• 07.09.10, 64일차 : 4.5시간: AOP 정리, SLDC, 방법론 흟기
• 07.09.11, 65일차 : 5.5시간: Use case model, 프로젝트 관리, PMO 배끼기. post mortem, PSP/TSP 자료 찾기
• 07.09.12, 66일차 : 5.0시간: post mortem, PSP/TSP 정리. FP 배끼기
• 07.09.13 67일차 : 0.8시간: module/component/service 정리하다 뻗음. 한계에 도달했나?
• 07.09.14, 68일차 : 6.3시간: module/component/service 정리. 구조적, 정보공학 재정리. 내 분량 전체 정리. SW 공학 전체 토픽 정리는 택도 없군.
• 07.09.15, 69일차 : 7시간 정도 : 스터디
• 07.09.16, 70일차 : 10시간 : 기출문제 검토, 어제 시험 검토.

총 공부량 약 39시간. 스터디 시간은 전체 시간에서 2/3정도 곱해준 값. 그래도 40시간에서 1시간이 모자라는군.

대강 40시간을 채우는 생활 프레임워크(?)는 나오는 듯 하여 좋기는 하지만 토요일 시험 결과에 완전 낙담. 여전히, 그리고 한참이나 모자라다. 모자라는 기준도 시험 패스 점수 기준이 아닌 함께 공부하는 사람들 기준으로.

공부법에 대해 여전히 해매이고 있는 중. PMS 과정이 다 지나가고 AMS로 넘어왔기까지 했는데 이게 뭐하는 꼴이야?

• 07.09.03, 57일차 : 1.0시간
• 07.09.04, 58일차 : 2.2시간
• 07.09.05, 59일차 : 4.0시간
• 07.09.06, 60일차 : 3.0시간
• 07.09.07, 61일차 : 4.2시간
• 07.09.08, 62일차 : 5.0시간
• 07.09.09, 63일차 : --

9주차 총 공부시간: 19.4시간

우리의 은찬냥은 여전히 내 머리에서 왱왱거리시는군. 상황은 퇴근 후 '보고 또보고'. 나참.. 그래서 나타난 꼬락서니가 바로 위의 꼴이다.

완전 사이비 공부, 프로시딩 배끼기를 하고 있는대도 불구하고 토픽당 1시간이 넘어간다. AMS 과정 중 마스터할 토픽 수는 무려 350개! 우리 성기술사님, 우릴 수퍼맨으로 아시는가부다. '수퍼맨이 되어야 기술사가 된다?' 라는 뜻으로 받아들이고 조용히 찌그러져야하는 상황.

50 ~ 56일, 8주차 : 총 16.9시간

• 07.08.27. 50일차 : --
• 07.08.28. 51일차 : 1.0 시간
• 07.08.29. 52일차 : 3.2 시간
• 07.08.30. 53일차 : 3.0 시간
• 07.08.31. 54일차 : --
• 07.09.01. 55일차 : 4.5 시간
• 07.09.02. 56일차 : 5.1 시간

16.9시간.. 움, 나 미친거 아냐? 커피프린스 1호점 - 고은찬 땜시 이러한 황당한 사태가. 그토록이나 심각했던 지난 토요일의 기술사 공부법에 대한 고민은 잊은지 오래네. 이 망할놈의 남장녀가 혼을 주욱 빼놔서리. 1주일이 지난 지금까지도 내 머릿속에선 은찬냥의 모습이 왱왱. 요즘 드라마가 재미있다는 이야기는 많이 들었지만 이토록이나 빠지게 만들 줄이야. 아... 처음부터 건드리는 것이 아니였어.

공부법은 하루 한개의 블로깅 - 자료찾기를 통한 - 토픽 정리. 그리고 4개의 프로시딩 적기로 대강 결론을 맺었다. 하루 5개꼴로 한다는 이야기인데, 그래도 만만치 않는 계획.

7주차 정리: 33.8시간

PMS가 다 끝나가는 이 시점에서야 내 공부 방법 - 블로그를 통한 토픽 정리 - 을 찾은 줄 알았더니만, 이를 지도 기술사님께 상의드렸더니만, 하시는 말씀. '기술사님 중에 종이에 직접써서 토픽을 정리하시지 않은 분은 없어요. 저는 반대입니다.'

역시나, 나의 스타일대로, 습관(!)대로 이것저것 이유를 대가며 반론을 펼쳤지만 돌아오는 대답은 '자신의 스타일에 맞게 가세요'였다. 왠지 모르게 억지로 대답을 얻어냈다는 느낌이 강하게 몰려온다. 신경을 너무 많이 쓴 탓일까? 자고 일어나니 머리가 깨질 듯이 아파온다.

분명 틀린 이야기가 아닐 것이다. 시험 시간 400분 동안 멈추지 않고 써야하기에 반드시 필요한 것 중 하나가 '필력'인데, 필력을 키운다는 차원에서 당장 문제가 생길터. 답안 작성 연습 차원에서도 '몸'으로 익힌다는 중요한 요소가 빠져버린다는 문제가 있기 때문이다. 게다가 내용이 아닌 형태 면에서도 자신이 쓴 필기체가 활자체보다 우위에 있다고 하니, 나아가 나중가면 내용이 아닌 이미지로 머리에 남는다는 말씀까지. 후...

6주차 정리: 28.5시간

KPC 프로젝트가 끝남과 동시에 ECMiner와의 모든 프로젝트 종료. 다시 본 페이스를 찾는 것이 관건이었지만.. 기존의 페이스로는 합격이 택도 없다는 것이 여지없이 증명됨. 서브노팅은 본 시험 준비 처음에 마음먹었던 이 블로그를 이용하는 것으로 변경.

블로그를 이용한 서브노팅.. 해보니 상당히 쓸만하다. digital 기반이기에 확장성이 뛰어나고, 정리하는 시간이 대폭 줄게된다. (인터넷에서) 찾은 자료를 정리하기에도 좋다. 필기 연습이야 답안 작성 숙제 정도면 충분히 연습이 될 것이라 예상. potability는 나중에 프린팅을 하면 되겠고. 앗싸~!

• 07.08.13, 36일차: --
  KPC 프로젝트 피날레 장식~! 그래 이제부터가 시작이야, 모든 일은 잘될꺼~야~.
• 07.08.14, 37일차: 2.0시간
  다시 시작이다~. 디지털 신 서비스 강의듣기.
• 07.08.15, 38일차: 9.5시간
  디지털 신 서비스, 경영 강의 듣기. 서브노트 customizing. 서브노트 형식이 맘에 안든다.새로운 서브노트 형식의 조건: 1. 토픽정리와 답안 연습 모두가 가능하도록. 2. 이동성(이동 중간에도 볼 수 있도록) 3. 확장성(내용을 추가할 수 있도록)
• 07.08.16, 39일차: 2.0시간
  발동이 잘 안걸리는군. 서브노트 customizing 실패, 도로 제자리. 답안 포맷을 반으로 잘라 2개 토픽정도 정리해보았는데, 영... 글씨 크기가 크다보니 페이지 량이 너무 커지고, 토픽작성에 시간이 너무 많이 걸린다.
• 07.08.17, 40일차: 2.0시간
  미쳤지.. 밀양 보느라. 달랑 두시간. 아~ 이창동이여!!
• 07.08.18, 41일차: 8.0시간
  숙제 및 스터디. 오늘 우리 스터디 쫄딱 망했네. 달랑 3명 참가. 상훈형, 인영씨, 나 끝!
• 07.08.19, 42일차: 5.0시간
  必勝, 技術士: 83회 전자계산조직응용기술사 후기 참가. 12시 퇴실. 1교시 문항 정리

시험 전날 대략 1시 반 경에 취침 모드로 들어감. 어짜피 낼 시험의 목적은 시험장 분위기 파악, 그리고 내용은 둘째치더라도 1시간 40분 * 4 란 긴 시간 동안 계속 써내려갈 수 있는지를, 얼마나 써내려갈 수 있는지를 파악하는 것이기 때문이었기에 수면시간에 대해 신경쓰지 않았다. 근데... 이게 그리도 후회하게 될 행동이었을 줄이야.

오전 6시 반 정도 일어나 밥차려 먹고 오픈소스 라이센스 자료를 들적이다 7시 50분 경에 집을 나섬. 시험장은 집에서 버스로 15분 거리인 일원동 로봇고등학교.

도착하니 20분 정도 남는 시간. 준비물 검사를 하는데 이런, 가져왔던 팬 두개가 이미 거반 앵꼬가 나있네. 바로 나가서 1.6mm는 아니지만 비스무리한 팬 두개를 더 사가지고 옴.

시험 시작. 왠일로 8시 50분에 시작. 10분이나 일찍 시작하다니. 아... 진짜 제대로 시험 보는 것이었다면 이거 완전히 땡잡은 케이스인데.

29일차 - 8월 6일 ~ 35일차 - 8월 12일까지 총 8시간

KPC 프로젝트로 인해 전혀 공부 못했네. 34일차인 8월 11일에 겨우 8시간정도. 숙제였던 Watermarking, Fingerprinting, CDN, Cache Server 정리 뿐. 주간할당 토픽에 대한 시험을 본지 2주가 지났는데, 시험을 위한 토픽정리는 손도 못대고 있다. 답안 멘토링을 못받는 것 만큼 아쉬운 것도 없을터인데...

5주차 정리

썅, 이번주로도 끝나지 않는 KPC 프로젝트. 그 와중에도 새삼 깨달은 사실 하나. 단지 시간을 만든다고 해서, 억지로 잠을 줄이고 작업량을 늘린다고 해서 수행할 수 있는 량이 늘지는 않는다는 것. 이를 고상히 표현하자면 '임계점, threshold에 이르렀다'라고 하나? 아주~ 고상치 못한 자세로 작업을 하고, 아주~ 고상하지 않은 자세로 잠을 잤다는 것. 그것도 오히려 평소 작업량보다 더 적게, 그것도 평소 수면량보다 더 많이.

• 22일차, 7월 30일 : 2.0 시간
  헤헤, 11시까지 야근하고 2시간 씩이나 채웠네. 네트워크 계층 거반 끝남. 아니, 근디 IPv4, IPv6를 뭐 이렇게 간단하게 설명하냐.. 너무 짧잖아!
• 23일차, 7월 31일 : 3.5시간
  IPv4 심화 학습 및 네트워크 계층 끝, 링크, 물리 계층 80% 완료. 낼이면 무선, 보안으로 넘어간다~
• 24일차, 8월 1일: 1시간
  환송회를 도대체 몇 번하는거야. 그나마 한시간이라도 한 것이 기적. 덕분에 아직도 OSI 7에서 놀고 있네.
• 25일차, 8월 2일: 6.0시간
  OSI 7, 무선 종료. 보안 80% 정도. 아니 이런.. 멀티미디어란 복병도 있었구만.
• 26일차, 8월 3일: 4.0시간
  보안 종료, 숙제하기. 멀티미디어 뿐 아니라 네트워크 관리도 숨어있었네. 아... 자료 찾는데 시간을 다 소비하는군..
• 27일차, 8월 4일: 8.5시간
  숙제 및 오후 그룹 스터디 참가. 뭔 시간이 이렇게 오래걸리냐. 숙제도 다 못하고, 시험 공부도 못하고.. 시간 관리 완전 실패.
• 28일차, 8월 5일: --
  KPC 프로젝트로 인해. 전무.

4주차 정리

공부량 총 24시간. 네트워크 관리, 멀티미디어를 빼놓고는 얼래벌래 네트워크 교과서 흟기 완료. 각 토픽에 대해 구체적으로 파고든 것은 아니지만 전반의 흐름잡기는 성공이었다고 판단한다. 문제는 KPC 프로젝트가 이번주는 커녕 다음 주까지 계속 이어지리라는 예상. 다음주면 끝나려나? 아...정말이지 근 몇년간 최고로 힘든 나날을 보내고 있다...

일단, 8월 초까지 네트워크에서 보안까지 커리큘럼이 이어지고 있다는 데에 안도한다. 덕분에 택도 없이 모자랐던 교과서 흟기 시간을 한 주 더 벌었다는 것~

3주가 지났음에도 공부량에서 무려 10시간하고도 대여섯 시간이 모자란다. 굳이 변명을 대자면 퇴사, 입사, 프로젝트 마감 등의 굵직한 사건이 터졌기 때문이라고 할 수도 있겠지만, 그렇기에 정신적 여유가 없었기 때문이라고 하겠지만, 그렇다고 시간을 비워두지 못한 것도 아니기에 그리 안심할 수 있는 상황은 아니다. 여전히 할당된 시간에 비해 절대적 공부량은 턱없이 모자라다. 대략 시간 활용 비율은 70%정도?

스터디 내용의 경우, 흐름을 잡는다는 데에 주력하고 있다. 그렇기에 교과서를 흟는 것이다. PIS에서 제공하는 토픽은 일종의 milestone으로 보아도 상관 없겠다.

• 15일차, 7월 23일 : 4.0시간
  아자붕! 시작이 좋군... but 시간만. 컴퓨터 네트워킹 흟기.
• 16일차, 7월 24일 : 1.0시간
  아자붕! 시작이 좋더니만, 왕폭락! 컴퓨터 네트워킹 흟기 계속.
• 17일차, 7월 25일 : --
  아자붕! 아예 주저 앉았네~! 프로젝트 마감 보름 앞당기기 와이리 힘드냐.. 웹이라고 너무 우습게 본건가?
• 18일차, 7월 26일 : 2.7시간
  그나마 체면치례. 컴퓨터 네트워킹 흟기 계속. 이제 OSI 레이어 중 프리젠테이션 레이어 끝남. 약 150 페이지? 언제 다 끝나??
• 19일차, 7월 27일 : 3.5시간
  FTTH/PON, Wireless LAN 서브노팅 및 유,무선 네트워크 흟기. 곱게 정시 퇴근하고 방해요소도 없었는디 30분이 모자라네.
• 20일차, 7월 28일 : 8.0시간
  그룹 스터디로 도배를 한 날. 오전 10시 반부터 오후 10시반까지. 아 근데 왜이리 졸리냐..
• 21일차, 7월 29일 : 7.5시간
  그래, 도서관이었어!! 그래도 두시간 반이 모자라는군.. 컴퓨터 네트워킹 흟기 - Application 계층, Transport 계층, Network 계층 중간까지. 앗싸리~! 알고보니 교과서에서 네트워킹, 보안 모두 다루고 있네? 왠간한 최신기술까지. 담주까지 흟기 계속이다~!

1일차: 3.8시간

0.2시간은 담배피며 뭐하며 얼래벌래 보낸 시간. 자료 찾는데 대략 1시간 소비. 서브노트 포맷 숙지 및 할당된 object 정리. 정리 이거 만만찮다.. 아직 1개도 제대로 끝내지 못했네..

2일차: 2.0시간

안좋은 일이 생겨 그냥 퍼짐. 새벽에 일어나 2시간 겨우 채웠구만. S/W 개발방법론 서브노팅 완료. FTR:Formal Technical Review(Inspection/Walkthrough/Peer Review) 자료 검색.

공부량: 3시간

그래, 달랑 3시간. 뭐 특별한 일이 있던 것도 아니다. 오로지 이 스터디를 위해 온전히 하루 전체를 할애해서 3시간.

게을러서 그랬다는 둥, 집중력이 부족하다는 둥의 자학을 하려는 것이 아니다. 이는 실행 가능한 스터디 루트가 보이지 않았기 때문이다. 명확한 이정표가 머리에 새겨지지 않았기 때문이다. 단기가 되건 장기가 되건 뚜렸한 목표가 없으면 중간에 보내는 시간은 대부분 삽질이 될 가능성이 농후하다는 판단. 집중 대상이 불분명하니, 집중력이 없을 것은 당연하고.

결국 '달랑 3시간'이 되어버린 이유는 게을러서가 아니었다. 집중력이 부족해서가 아니었다. 목표가 불분명해서였다. 목표를 이루기까지의 실행 루트가 불분명해서였다.

목표: 84회정보처리기술사 필기 시험(2008년 2월) 합격.

시험 전 최소 1000시간은 공부해야 합격할 수 있다는 것이 정설이라 한다. 6개월 코스일 경우 평일 4시간, 주말 각각 10시간을 해야 답이 나온다고. 대략 평균 이하의 실무 경력의 나는 여기에 가중치를 두어야 답이 나오지 않을까 하는 예상.. '최소'라는 말이 신경쓰이기도 하고. 스터디 가이드라인을 책으로 제시한 그 기술사님은 1500시간을 했다는데.. 상당히 잘 썼던 그 필력을 봐선 나보다 뛰어난 사람이 분명하고.. 그럼 1500시간을 넘겨야 답이 나온다는 이야기잖아!!

대략 시험 전까지 6개월 하고도 1개월이 더 남은 상태이니, 일단 평일 4시간, 주말 10시간을 목표로 달려본다. 어렵다는 잘 알고 있다. 시간 내는 것 뿐 아니라, 힘겹게 얻은 시간도 잘 활용하는 것 또한 만만찮다.

어찌되었건, 이 시험은 붙고 봐야한다. 7여년을 몸담아온 이 컴퓨터 분야, 어떤 형태로던지 일단락을 지어야지 않겠어? 지도 기술사님 曰, '나중에 치킨집 차리기 싫으면 반드시 붙으셔야죠?'

원문은 이곳에서..

다음은 header의 선언부.

위 선언부에 대한 정의는..

최종 몸무게 69.5kg

78kg -> 69.5kg, 8.5kg 감량, 약 1년 10개월에 걸쳐 64개일만에 프로젝트 완료.

이전 페이스대로라면 저번주 중으로 프로젝트가 종료되었어야 하는데, 최근 몇 주동안 회사일과 Framework Design Guidelines: Conventions, Idioms, and Patternsfor Reusable .NET Libraries 번역 검토 때문에 운동 시간을 마련하기가 쉽지 않았다. 근 며칠은 운동대신 식사량 조절로 살을 뺐다. 말이 좋아 조절이지 사실은 그냥 '굶기'. 건강에 좋지 않다는 것을 뻔히 알면서도 며칠만 그럴 것이라는 데 약간은 안심. 어제는 점심 겸 저녁으로 2000원 어치 떡볶이 + 튀김. 오늘 아침은 항정살 200g 정도에 상추. 점심 및 저녁은 굶기. 지금 이순간 아주 배가 고프다. 목표 완수를 했으므로, 이 글을 쓴 이후 바로 밥을 먹을 것이다.

• 몸무게: 79.5kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 25 = 200회
• 뱃살빼기 몸부림: 8 * 25 = 200호흡

이놈의 발모가지..아래는 나을 생각을 안하네. 여전히 아픈 것이 아니라 어제보다 더 아파진 듯. 운동을 하지 말았어야 하나? 어디 부딛힌 것도 아니고, 삐끗한 것도 아닌데 뭐가 이리 오래도 가나.

• 몸무게: 71.4kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

어제랑 완전히 상황 동일. 저녁도 안먹은지라 내심 70kg대를 기대했지만 무산. 아침의 돼지고기 불고기와 점심의 닭조각 2개가 컸나? 쭈압. 금주 중에는 70kg대로 와야 담주에 69란 숫자를 보고 끝낼 수 있으련만. 슬슬 불안해지기 시작하네.

정말 금주 중으로 70kg대로 들어설 수 있으려나? 아 글쎄 토욜부터 왼쪽 발목 안쪽의 복숭아뼈 아래가 아파오는거다. 걷는데는 크게 무리없는데 뛰기만 하면 아파오니 원.. 핑계낌에 며칠 제끼고 오늘 다시 운동을 시작했다. 여전히 아프긴 한데 발바닥 전체로 뛰면 그나마 견딜만 하다. 일욜에는 피자 5조각에 광어회, 어제는 치킨 두조각 추가. 칼로리가 높아졌겠다 싶은데, 다행히도 71kg대는 유지해주고 있네.

• 몸무게: 71.4kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

전반적으로 강도를 조금 높여도 상관없겠다 생각들 정도로 여유만만. 하지만 시간이 얼마 안남은지라 올리지는 못하겠네. 이제 정말 일주일밖에 안남았는데 먹는거나 조절해줘야겠군.

70kg대 진입 실패. 70kg대로 진입한 모습을 보기 위해 점심도 2/3정도만 먹다 남기고, 저녁은 삶은 계란 두개에 요플레 하나로 때웠는데..음.. 내일은 칼로리가 매우 높은 술을 마시기 땜시 금주 중으로 70kg대로 진입하기는 글렀다. 아쉽군.. 이번달 중순이면 끝나겠다 싶었는데..

• 몸무게: 71.3kg
• 뜀박질: 풀코스 + 알파
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

뱃살은 거반 만족스러운 상태가 되가는 듯. 운동 후 살짝 힘을 주면 어설프게나마 근육이 갈라지는 모습이 보인다. 반면 옆구리살은 예나 지금이나 그냥 그대로. 본 프로젝트가 끝나도 옆구리살에는 별 변화가 없겠다싶다. 한편 팔굽혀펴기의 효과는 가슴 근육이 아닌 어깨 근육으로 붙는거 같다. 단백질 부족인가? 자세에 문제가 있을 수도 있겠는데 이건 근육을 쓰는 습관의 문제인 듯. 누구는 나랑 정 반대라고 하기도 하고.

오늘의 몸무게 및 운동상황.

• 몸무게: 71.2kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

4시간자고 일어나 운동하려니 평소같지가 않다. 5월 내내 그래야 할터인데 이를 어떻게 감당해야하나.. 하긴 계획대로라면 5월 중으로 본 프로젝트는 끝나겠다만. 조금 늦은 시간에 한지라 운동하는 사람보다는 출근하는 사람이 더 많다. 내일 혹은 모레이면 70kg대로 접어들겠군. 구웃~!

오늘의 몸무게 및 운동상황.

• 몸무게: 71.9kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

찌긴 얼마나 더 쪘다고 찌뿌둥함에다가 삐걱거리기까지. 찐 것이 영향을 미쳤는지 일욜날 오전 운동 후 저녁 농구 시합 때까지도 이전같지가 않다. 그런 몸은 오늘 뜀박질까지 계속. 근육운동 후반정도 가서야 이제 몸이 풀리는 듯. 먹는 것이 문제다. 이제 좀 밥이건 뭐건 과하다 싶으면 남길줄도 알아야 하는데, 밥한톨까지 깨끗이 비우는 어릴적부터의 습관 땜시..아냐.. 식탐때문이지 뭔! 여하간 71kg대로 재진입.

그래.. 내가 원래 식탐이 좀 있다니깐. 약간은 부족한 듯이 먹는 것이 좋다는 것을 알면서도 먹는 그 순간에는 그냥 잊어버리게 된다. 음식을 남기지 말아야 한다는 어릴 때부터의 강박관념도 얼마간 있기도 하고. 어제 저녁, 오늘 아침.. 그렇게 먹어댔으니 찔만도 하지.

다음은 오늘의 몸무게 및 운동 상황

• 몸무게: 72.7kg
• 뜀박질: 풀코스 한바퀴 빼기 500m 정도(집에서 뜀박질 코스까지의 거리)
• 팔굽혀펴기: 15 * 8 = 120회
• 윗몸일으키기: 20 * 8 = 160회
• 뱃살빼기 몸부림: 20 * 8 = 160호흡

한동안 운동을 안했더니만, 전날 과식에 음주까지 했더니만 1kg정도 고대로 올라가버렸다. 뜀박질을 할 동안 몸이 무거워졌다는 것을 그대로 느껴진다. 하지만 근육운동할 때는 힘이 남아돈다는 느낌. 뜀박질을 제외한 세 코스 모두 가뿐히 완료. 희안하게도 한낮에 운동을 했음에도 평소와는 달리 별로 땀이나지 않는다. 몸무게를 재기 전에 대략 72kg대 중반을 예상했는데.. 아니나 다를까, 그대로 몸이 뿔어나있다. 땀이 적어 수분이 덜 빠졌을 것이다.

갈등의 법칙은 단순히 미학적 원칙 중 하나가 아니다. 그 자체가 이야기의 정수이다. 이야기는 삶의 은유이고 산다는 것은 곧 쉴새없는 갈등의 연속이다.

...작가들 가운데도 인생무상이라는 진리를 이해하지 못하는 사람들이 있다. 이들은 근대 세계가 주는 헛된 안락함에 속아 일단 제대로 처신하는 법만 알면 인생도 만만할 줄 안다. 그 탓에 이야기 안에서 갈등을 제대로 다루지 못한다.

...한편 갈등 자체에 대한 반발심에서 씌어진 지루한 인물 묘사들이 후자에 속한다. 갈등만 없다면 인생이 정말 멋질 거라는 낙천적인 몽상이 이런 작가들의 생각이다.

...가령 사람이 외적인 욕구를 어떻게든 충족시켜서 바깥 세상과 큰 무리 없이 지낸다 하더라도 그 평온함은 얼마 못 가 지루함으로 바뀐다. 이 경우 갈등의 부재 자체가 사르트르가 말한 '결핍'의 내용을 이룬다. 인간이 부족함이 없어 욕구를 상실할 때 겪는 내적인 갈등이 바로 지루함이다.

아 글쎄.. 절대로 밥먹고 나서 침대에 누우면 안된다니깐. 아주 잠시만, 눈도 감지 않는다고 아무리 굳게 맘먹어도 그 맘은 그 순간뿐이다. 시간은 저~만치 흘러 한밤중으로 가버리고 설사 중간에 일어난다 해도 그 상태에서 운동하길 바라는 것은 그야말로 택도 없는 일이다. - 바로 어제, 그리고 본 프로젝트가 시작된 후 수시로 일어났던 상황에 대한 설명.

다음은 오늘의 몸무게 및 운동 상황이다.

• 몸무게: 71.9kg
• 뜀박질: 풀코스 한바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

저녁을 먹어주고도 71kg대. 또다시 주말에 피자니 뭐니해서 먹어준 것이 있는지라 72kg대로 돌아왔겠다 싶더니만, 여전히 흐뭇함을 느끼게 해주는 나의 기특한 모옴~

71kg대 돌입. 얼마전 이번달 중반이면 목표치에 도달하겠다고 써놓고 한편으로는 '과연 될까나?'했었는데, 이거.. 될 것 같다. 다음은 오늘의 몸무게 및 운동 상황.

• 몸무게: 71.7kg
• 뜀박질: 풀코스 1바퀴
• 팔굽혀펴기: 8 * 15 = 120회
• 윗몸일으키기: 8 * 20 = 160회
• 뱃살빼기 몸부림: 8 * 20 = 160호흡

그래.. 생각해보니 저녁을 안먹어서 그런거다. 반찬하기도 귀찮은데 뭐 살도 빼고 일석이조이지. 해서 뜀박질 역시 가뿐하게 뛰어줌. 맨날하는 소리지만 재보지 않아서 그렇지 이전보다 기록이 더 좋을거다.

헌데, 윗몸일으키기에서 약간의 트러블이.. 요상하게 후반부터 평소보다 올라가기가 힘들다. 아주 겨우 풀코스 완료. 팔굽혀펴기는 조만간 또 업그레이드해도 상관없을 듯.

오늘의 몸무게 및 운동상황.

• 몸무게: 72.1kg
• 뜀박질: 풀코스 1바퀴
• 팔굽혀펴기: 15 * 8 = 120회
• 윗몸일으키기: 20 * 8 = 160회
• 뱃살빼기 몸부림: 20 * 8 = 160호흡

점심에 이어 또 풀무더기 반찬으로 저녁을 먹으려니 조금 남은 삼겹살이 눈에 띈다. 해서 삼겹살 반찬으로 저녁 식사를 했는데.. 이게 영향을 준건가? 뜀박질 오르막 코스에서 갑자기 무릅 부위가 뻣뻣해져온다. 그 전까지는 상당한 속도로 꾸준히 잘 달리고 있었는데.. 무리하는 것이 싫어 그 시점부터 속도를 팍 낮추었다.

보통 뜀박질 직후에는 몸이 가뿐해져 불렀던 배도 꺼지는 법인데.. 여하간 오늘은 뭔가 좀 다르다. 이걸 컨디션이 않좋다..라고 표현해야하는 건가? 근육 운동 때 역시 그다지 상쾌하지 않은 몸상태로 겨우 풀코스를 마췄다. 어제보다 0.1kg이 줄어든 기록.

이번달 안으로 끝마쳐야 담달부터 본격적으로 다음 프로젝트에 올인할 수 있다. 살빠지는 추세로 보아서는 이번달 중순쯤이면 대강 목표에 도달할 것 같기도.

다음은 53회차 상황

• 몸무게: 72.2kg
• 뜀박질: 풀코스 1바퀴
• 팔굽혀펴기: 15 * 8 = 120회
• 윗몸일으키기: 20 * 8 = 160회
• 뱃살빼기 몸부림: 20 * 8 = 160호흡

기특하기도 하지.. 주말의 폭식과 어제 저녁에 먹은 삼겹살에도 불구하고 72kg대 초반을 그려주고 있는 이쁜 나의 몸~

오늘의 상황.

• 몸무게: 72.8kg
• 뜀박질: 풀코스 1바퀴
• 팔굽혀펴기: 100회
• 윗몸일으키기: 120회
• 뱃근육 강화 운동(?): 160호흡

드디어 72kg대로 돌입했다! 저녁 식사 후 잠시 눈만 붙인다는 것이 2시간을 넘겨버렸다. 그냥 오늘도 넘겨버릴 생각으로 잠을 청하는데 갑자기 잡스런 생각이 머리를 채우는 것이다. 때이른 모기의 기승도 한 몫 작용하고. 해서 뒤늦게나마 운동을 하게 되었는데, 보람이 있다.

지난 주 간만에 농구를 뛰어보니 그간 살을 뺀 효과가 분명히 있다. 일단 순발력이 좋아졌다. 두 게임을 뛰고 나서도 크게 지치지 않던 상황을 생각해보면 지구력도 상당히 좋아진 느낌.

어제의 운동 직후 몸 상황.

• 몸무게: 73.0kg
• 뜀박질: 변경된 기본 한코스(왕복 두 블럭 + 트랙까지의 거리).
• 팔굽혀펴기: 110회
• 윗몸일으키기: 130회
• 헬스장 아저씨용 뱃살빼기 운동: 160호흡.

(조금이나마) 운동량이 많아져서 그런건지 본 프로젝트 초반 때처럼 운동 전과 운동 후의 몸무게 변화량이 1kg씩이나 차이난다. 물론 기분은 좋다. 뭔가 확실히 했다는 결과로 보이니깐.

간만에 쇠고기를 먹어서 그런건가.. 뜀박질에서부터 뭔가 다르다 느껴지더니만, 근육운동에서는 확연히 힘이 덜 든다는 느낌이다. 코스를 8번 돈다는 것 자체가 지겨워서 그랬지, 그렇지만 않았다면 똑같이 8번은 더 돌 수 있지 않았다는 느낌까지 받는다.

대강 50일차 정도로 치면 나오지 않을까? 23, 24일차가 작년 10월 27일인 것을 보면 한참 새로운 RtmdsController를 개발하고 있을 때다. 아마 그 때문에 포스팅이 끊겼지 않을까.

그간 간간히 운동을 하다가 제대로 다시 시작한 것은 한 1월 중순 경이 되지 않을까 싶다.

다음은 어제의 몸무게와 운동 상황.

• 몸무게: 73.3kg
• 뜀박질: 한코스(두 블럭) + 뜀박질 코스까지의 왕복거리 약 500m 정도.
• 팔굽혀펴기: 100회(12 * 6 + 14 * 2)
• 윗몸일으키기: 120회(15 * 8)
• 헬쓰장 아저씨용 뱃근육 강화 숨쉬기: 160호흡.

독창성은 특이함을 추구하는 과정에서 얻는 것이 아니라 신빙성을 확보하기 위해 고투하는 과정에서 얻어진다.

다른 말로 하자면 개인적인 스타일이란 자의식 속에서 얻을 수 있는 것이 아니다. 그보다는 이야기의 설정과 등장 인물들에 대한 작가로서의 자식이 작가의 개성과 만날 때, 다시 말해 헤아릴 수 없이 많은 정리되지 않은 자료들 속에서 작가 자신에게 가장 의미 있는 것들을 골라내고 정리하는 과정에서 작가의 개인적 스타일이 형성되는 것이다. 이 과정에서 작품은 작가라는 사람만큼이나 독창적인 존재가 된다.

... 이 두 사람의 독창적인 스타일은 상투화될 가능성을 철저히 배격하면서 각자의 대상을 철저히 연구하는 과정에서 얻는 자연적이고 무의식적인 부산물이다.

로버트 맥키(Robert McKee)의 Story 중에

'그 인물이라면 이러한 상황에서 어떻게 행동할까?' 는 상투성으로 나아가기 십상인 잘못된 질문이라고. 그 대신, '이러한 상황에서 나라면 어떻게 행동할까?'가 나은 질문이라 한다. 인물 전체에 대한 조명이 아닌 특정 상황으로 조건을 좁혔다는 데 주의. 이 순간 나는 그 인물의 특성과 상황을 충분히 이해한 채 더 현실적으로 그 인물의 정서를 얻어낼 수 있을 것이다. 이로서 '내가 저 상황에 처한다면 나는 어떻게 할까'란 질문으로 현실적인 정서를 얻어낼 수 있지만 그 인물의 성향을 반영하지 못한 결과를 피해갈 수 있다고.

이야기의 주된 동력은... 간극. 갈등.

자신의 행동이 야기할 반응에 대한 기대와 실제로 돌아오는 반응이 다를 때 인간의 내부에서 벌어지기 시작하는 간극, 즉 기대와 결과, 개연성과 필연성 사이의 단절로 인해 형성되는 공백 그 자체가 바로 이야기의 실체이다. 장면을 구축해 나가기 위해서 작가는 끊임없이 이 틈을 만들고 벌려야 만 한다.

로버트 맥키(Robert McKee)의 Story 중에

C++/CLI로 Managed Type, Native Type 짬뽕하기(1/2) 에서 계속하여

1. Native Type의 Method 안에서 Managed Type 생성 및 사용 가능

단, 해당 .cpp 파일은 /clr(공용 언어 런타임 지원) 옵션으로 컴파일해야함.

2. clr based enumeration 사용 가능

낼 정도면 기존 블로그에 남긴 글들을 이전해도 별 무리 없겠군.

태터툴즈.. 이거 정말 물건이다.. AJAX인가? 글쓰기에서 간간히 보여주는 위지윅 기능이 특히나 놀랍게 다가온다. 빨랑 웹 프로그래밍 환경에 익숙해져야겠다는 생각이 밀려옴.

다행이도 이전 글의 날짜 문제는 그 날짜에 맞게 변경하는 것이 가능하다. 일단 온전히 글을 옮기는 데는 문제 없겠다. 그래도 일일이 다 옮기려면 상당한 노가다인데, 좋은 방법이 없으려나?

트랙백이나 댓글도 함께 옮길지는 고민중..가끔씩 파이어폭스와 IE의 화면이 달라질 때가 있다. 웹 표준에 대해 공부가 필요한 시점이야.. 후훔.

오늘이 화요일. 지지난 주 일요일에 호스팅과 태터툴즈를 설치했으니, 따지면 10일차가 되겠군.

공사 중간에 스킨 테마만 4번이 바뀌었다. 처음 http://www.freecsstemplates.org의 스킨을 보았을 때는 왠간한 것 아무거나 하나 짚어들어 태터에 포팅하면 이쁘겠다 싶었는데, 아니 이게 왠걸? 한글이 들어가기만 하면 그토록이나 멋졌던 스킨도 뭔가 하나 빠진 듯한 느낌으로 다가오는 것이다.

글꼴이 살을 깎아먹으니 색상 등의 다른 요소로 채워야 하는데, 바탕을 어둡게 하니 조금만 색을 잘못써도 난잡해진다. 왠간하면 바탕을 어둡게 가려고 했는데 이또한 만만하지 않고..

이런 과정을 몇번 거치고 나니 블로그를 새로 만든다는 것 자체가 후회스러워지려 한다. 한마디로 짜증 이빠이.

류시화의 시모음집에서 처음 접한 시. 싯구 내용대로라면 난 죽을 때까지 어른되긴 틀려먹었나?

알고보니 프란시스 코폴라의 Apocalypse Now(지옥의 묵시록)에서도 잠시 튀어나왔었다. 왕뽀대나는 싸이키델릭 말론 브란도를 통해. 코폴라도 그리 비중있게 다룬 시인 것을 보면, 내 눈이 그리 많이 삔 것은 아닌거 같다.

내 썰이 아닌지라 포스팅하고 싶지는 않았는데, 요즘들어 유난히 머리에서 왱왱거리길래 안되겠다 싶어 올려본다.

만일 내가 모든 걸 잃었고 모두가 너를 비난할 때
너 자신이 머리를 똑바로 쳐들 수 있다면,

Stream of Depair

12월은 그냥 지나가버린건가? 그간 나는 잘 살고 있었나?

나이에 대해 상당히나 무덤덤한 모습으로 지내왔던 내가, Time: The End를 되새기며 애써 무시해왔던 그전과는 한층 달라졌다고 판단되었던 내가, 친척을 만나자 여지없이 몸둘바를 모르는 추한 모양새를 보이고 있었다.

상당히나 강하다 생각했던 나 자신에 대해, 상당히나 잘못 판단하고 있었던 듯 하다.

주요 개념은 Passing parameters to predicates 컬럼에서..

List<>::Find() 등의 검색 메서드에서 조건을 지정할 때 사용하는 Predicate<> 타입의 대리자. MSDN에는 인수를 지정할 수 없는 static 함수형 예제만 나와 있는데, 이보다 더 많이 쓰이게 될 형식은 객체형 대리자 및 무명 메서드이다. 다음은 MSDN에 올라온 함수형 predicate 사용법의 예제다.

위 예제 predicate의 비교 구문 중 100000이란 조건을 임의의 수치로 바꾸고자 할 경우, 함수형 Predicate으론 외부 객체를 사용하지 않고서는 해결할 방법이 없다. 바로 이 때가 무명 메서드와 객체형 대리자가 등장할 좋은 시점이다.

다음은 무명 메서드를 이용한 방법이다.

• 오늘의 몸무게 77.5kg.
• 달리기 풀코스 완료.
• 팔굽혀펴기: 80회
• 윗몸 일으키기: 60회
• 뒷몸 일으키기: 60회.

피곤해서 몬쓰겠다. 어쨌건 전체 코스 완료. 히힛~!

오홋! 최종 몸무게 76.5kg. 뜀박질 후의 몸무게는 77.3kg였는데, 후반 헬스모드에서 오늘따라 유난히 땀이 많이 나더니만 그 사이 0.8kg이 빠진 것이였다. 샤워 후의 몸무게 역시 76.5kg. 운동 시작 후 오늘까지해서 딱 3번 76kg대로 나왔는데, 근간에 이승엽이 홈런 못치는것 마냥 나오질 않았던 와중이었다. 운동후 최소 몸무게 기록인줄 알았는데, 최소 몸무게 기록은 76.1kg이었다. 무엇보다도 오늘 저녁을 먹지 않았던 효과가 컸던 것이라 생각한다.

그저께 운동후 이상스럽게 몸이 안좋아 어제는 많이먹고 푹 쉬었는데, 그 효과가 있었다. 오늘 몸상태는 최상. 뜀박질 속도가 상당히 붙었고, 후반 전력질주 때 역시 아주 좋았음. 이제는 스탑워치로 시간을 재어봐야 하겠다.

호흡 역시 마지막까지 '훕훕후~'의 네박자 모드. 앞으로 다리를 내밀 때 쭈욱~ 편다는 느낌으로 내딛는 방법이 상당히 좋게 느껴진다. 팔굽혀펴기의 경우, 10번도 안되어 중간에 휴식을 갖는 것이 이제는 필요없겠다 싶어 7,8 - 10,8 등으로 나누던 방법을 하나로 뭉쳐서 하기로 했다. 약간은 힘들긴 했지만 큰 무리 없었음.

• 전반 반바퀴: 그간 전반의 주법에 별로 신경을 쓰지 않아서 운동 전의 주법과 똑같아졌겠다 싶었는데 그게 아니다. 주법을 그대로 한체 몸을 앞으로 조금 굽혔더니만 당장에 발이 지면에 닫는 소리가 크게 난다. 신경을 안쓰게된 이유는 결국 새로운 주법에 익숙해졌기 때문이었다. 전반 1/2 지점까지는 호흡에 신경을 쓰지 않음. 이제는 '훕훕후~'의 안정적 호흡이 체력안배에 상당히 도움을 준다는 것을 많이 느낀다.
• 후반 반바퀴:역시나 앞꿈치 모드로 변경. 내딛을 때 다리를 쭉 편다는 느낌으로 달리니 확실히 빨라졌다. 오늘은 몸상태도 좋은지라 더더욱 빨라졌다는 느낌. 조금 과장해서 표현하자면 이전 속도보다 1/2 정도 더 빨라졌다. 호흡이 안정되니 그리 힘들다고 느껴지지도 않는다. 전력질주 때까지 매우 느낌이 좋았음.
• 팔굽혀펴기: 15-18-14-18-15, 총 80회
• 윗몸일으키기: 10-10-10-10-10, 총 50회
• 뒷몸일으키기: 7-7-7-7-7, 총 35회

20일. 드디어 20일차에 왔다고 해야하는지, 벌써 20일차에 도달했다고 해야하는지 모르겠다. 그간 흐른 시간을 생각해서는 '이제서야, 드디어'란 수식어를 붙이는 것이 맞는거 같지만, 느낌상으로는 '벌써'란 수식어가 더 어울리는 듯. '용케도'란 표현도 나름대로 어울리겠다 싶은데, 내게는 왠간해서 작심 삼일을 넘겼던 다짐(?)이 없었기 때문이다.

오늘은 뜀박질 전에 자전거포에 다녀오느라 코스가 약간 달라졌다. 거리상으로는 이전 코스의 약 4/5정도? 시간대는 오후 4시경. (시간 변경으로 인한) 생체리듬이 달라져서 그런지 뛰는 내내 힘이 들었다. 속도도 그렇고 막판 전력질주 때도 그렇고 어제와는 완전 딴판이다. 후반 헬스모드에서는 대강 어제수준의 몸상태를 유지했던 정도.

오늘의 몸무게는 77.1kg이다. 뜀박질 후의 몸무게 77.1kg, 후반 헬스까지 모두 마친 후의 몸무게 역시 77.1kg. 물 몇잔 마시고 샤워 후의 몸무게 역시 77.1kg이다. 이상하다싶을 정도로 변화가 없었다.

• 전반 반바퀴: 일요일이라서 그런지 낮시간인데도 운동하는 사람이 꽤 있었다. 너무 일찍 나와서 썰렁하겠다 싶었는데 그게 아니다. 몸이 이상하게 무겁다. 딱히 햇볕이 강했던 것도 아닌데, 밥을 먹은지 얼마 안되었던 것도 아닌데 말이다. 호흡은 이전과 동일하게 '훕훕후~'의 네박자 모드. 주법은 따로 신경쓰지 않았지만, 오늘 유난히 뒷꿈치부터 자꾸 걸린다.
• 후반 반바퀴: 앞꿈치모드로 변경. 여전히 느린 속도는 지속되고, 그 느린 패턴은 후반 전력질주때가지 계속되었다. 어제와 마찬가지로 의식적으로 다리를 쭈욱 펴서 달리니 숨찬 정도는 그대로이면서 속도는 조금 더 빨라짐. 특별한 느낌없이 전력질주모드까지 끝냄.
• 팔굽혀펴기: 7,8 - 10,8 - 7,7 - 8,10 - 8,7의 총 80회.
• 윗몸일으키기: 5-6-7-7-7-7의 총 39회
• 뒷몸일으키기: 5-5-5-5-5-5의 총 30회.

그럭저럭 추석은 지나갔다. 담 추석부터는 아버지를 축으로한 분가가 이루어질 것임과 동시에, 아부지를 축으로한 새로운 집안 추석 문화가 생겨날 것임을 예감한다.

또 1주일정도 지나간건가? 1주일에 4일을 넘기기가 만만치 않다. 역시 간만에 재개해보니 '적어도 느낌상으로는' 기운이 펄펄하다. 뜀박질의 경우 전반적으로 속도는 조금 느렸을지는 몰라도, 호흡 상태부터 마지막 전력질주 때까지 상태가 매우 좋았다. 전력질주 때는 지금껏 달렸던 최고 속도를 내었던 듯. 일주일이나 지나다보니 뱃가죽에 알배긴 것도 다 풀려있었고, 스트레칭 때도 이전의 평소 유연성을 잃지 않고 있다는 느낌. 끝나고 밥을 먹으려했는데, 나보다 운동에 대해 조금더 잘아는 동생 왈, 운동후 탄수화물을 섭취하면 그대로 살로 간다나? 잘마시던 오렌지주스도 칼로리가 높기 때문에 왠간하면 물로 대신하라고.

운동 후, 오늘의 몸무게 77.4kg

• 전반 반바퀴: 몸상태는 매우 좋음에도 불구하고 오래간만에 하다보니 몸이 조금 무겁다는 느낌이다. 초반 반바퀴 정도부터 호흡은 이전의 '훕훕후~'의 네박자 모드로 들어가 끝날 때가지 계속 유지. 주법은 발 전체를 붙인다는 생각만 놔두고 완전 자유.
• 후반 반바퀴: 역시 앞꿈치모드로 변경. 몸이 약간 무겁게 느껴지다보니 속도도 느려진 것 같다. 가만히 다리를 느껴보니 다리를 앞으로 내밀 때 전부 펴지를 않고 있다는 것이 느껴진다. 왠지 그리 좋게 느껴지지를 않아 다리를 의식적으로 펴보니 보폭이 커져 속도가 더 붙는다. 약간의 변화인지라 그리 힘이 더 들지도 않고. 막판 100m 정도를 남기고 전력질주 때는 지금껏 해왔던 그 어떤 전력질주 때보다 빨리 달렸음. 호흡은 그대로.
• 팔굽혀펴기: 9-10-11-11-10-9, 총 60회
• 윗몸 일으키기: 10-10-10-10-10-10, 총 60회
• 엎드려 뒷몸일으키기: 5-5-5, 총 15회.몸상태가 좋다보니, 중간에 휴식시간을 아주 짧게 잡고서도 각 세트를 이어서 할 수 있었다. 세트에 엎드려 뒷몸일으키기 종목 추가. 팔굽혀펴기나 윗몸 일으키기는 이제 요령이 붙어 자연스럽게 진행된다. 이제 팔굽혀펴기의 경우에는 주기를 변경하여 횟수를 더 늘려도 좋을 듯. 윗몸일으키기의 경우, 알이 베이지 않아 마지막까지 자연스럽게 몸이 올라갔다. 오늘같으면 발을 고이지 않고서도 꽤 많은 횟수를 할 수 있지 않았을런지.

운동 직전 몸무게 77.6kg. 운동 직후 몸무게 76.7kg. 샤워 후 음료수 두세잔을 마신후의 최종 몸무게 77.2kg. 몸무게를 생각해서 일부러 저녁도 일찍 조금 먹고 한세트를 돌았지만, 큰 변화는 없음. 하긴... 하루 그랬다고 기대를 하는 것도 무리기는 하지.. 오늘따라 유난히 아주 십스러운 생각에 휘말려서 지금 그리 기분이 좋지 않다. 그 놈의 생각땜시 운동도 관둘뻔 했음. 죄를 진 것이라고까지는 말하긴 힘들지만, 그리 유쾌하지 않은 상태로 있다는 것 또한 부인하기 힘들다.

• 전반 반바퀴: 그 십스러운 휘말림에 시간을 잠시 보낸 탓인지 그리 컨디션이 좋지 않다. 오늘따라 유난히 힘들었다. 그래도 호흡은 이전과 동일한 '훕훕후~'로 마지막까지 유지를 했다. 달리다보니 새삼 느껴지는 것이 내 다리가 꽤나 안짱다리라는 것. 가만 느껴보니 몸의 하중이 발 바깥쪽으로 상당히 몰려있다. 안쪽 끝은 바닥에 살짝 덴 정도? 그런 생각 때문에선지 지금도 발날이 상당히 아프다.
• 후반 반바퀴: 오늘 역시 앞꿈치 모드로. 어제에 이어 오늘의 뛰는 모습도 아주 곱상치가 않다. 방방 뛰면서 좌우로 이리저리 흔드는 모습이랄까.. 그래도 오늘은 나르시스마냥 내 그림자만 쳐다보며 뛰지를 않고 상당히 오랜시간을 정면을 보며 뛰었다. 어제와 동일한 지점.. 100m 정도 남긴 지점에서 전력질주. 호흡은 역시 그대로. 오늘 유난히 파워 워킹 아줌마가 많이 보인다.
• 팔굽혀펴기: 9-10-11-11-10-9 총 60회.윗몸일으키기: 8-8-7-8-7-6 총 44회(약간의 뽀록성으로. 몸을 바닥으로 내리는 시점에서 등을 바닥에 붙여보지 못함. 많으면 30도 정도의 각도로 내려갔을라나?)
  윗몸일으키기의 경우야 이제 메이저 업그레이드를 해야할 시점에 도달했기에 어제보다 6회 더 많은 60회도 가뿐. 하지만 윗몸일으키기의 경우, 어제 너무 무리를 해서 그랬던지 뱃가죽에 알이 왕창 배겼다. 초반 20회정도는 어제와 비슷한 느낌으로 갔는데 후반에는 뱃가죽(뱃근육?)이 땡겨서 혼났다. 그나마 8-7-6의 마지막 회수가 나온 것은 뽀록성이 상당히 짙다. 내일이면 알이 좀 풀리려나?

운동 직전 몸무게 77.6kg. 운동 직후 몸무게 76.7kg. 샤워 후 음료수 두세잔을 마신후의 최종 몸무게 77.2kg. 몸무게를 생각해서 일부러 저녁도 일찍 조금 먹고 한세트를 돌았지만, 큰 변화는 없음. 하긴... 하루 그랬다고 기대를 하는 것도 무리기는 하지.. 오늘따라 유난히 아주 십스러운 생각에 휘말려서 지금 그리 기분이 좋지 않다. 그 놈의 생각땜시 운동도 관둘뻔 했음. 죄를 진 것이라고까지는 말하긴 힘들지만, 그리 유쾌하지 않은 상태로 있다는 것 또한 부인하기 힘들다.

• 전반 반바퀴: 그 십스러운 휘말림에 시간을 잠시 보낸 탓인지 그리 컨디션이 좋지 않다. 오늘따라 유난히 힘들었다. 그래도 호흡은 이전과 동일한 '훕훕후~'로 마지막까지 유지를 했다. 달리다보니 새삼 느껴지는 것이 내 다리가 꽤나 안짱다리라는 것. 가만 느껴보니 몸의 하중이 발 바깥쪽으로 상당히 몰려있다. 안쪽 끝은 바닥에 살짝 덴 정도? 그런 생각 때문에선지 지금도 발날이 상당히 아프다.
• 후반 반바퀴: 오늘 역시 앞꿈치 모드로. 어제에 이어 오늘의 뛰는 모습도 아주 곱상치가 않다. 방방 뛰면서 좌우로 이리저리 흔드는 모습이랄까.. 그래도 오늘은 나르시스마냥 내 그림자만 쳐다보며 뛰지를 않고 상당히 오랜시간을 정면을 보며 뛰었다. 어제와 동일한 지점.. 100m 정도 남긴 지점에서 전력질주. 호흡은 역시 그대로. 오늘 유난히 파워 워킹 아줌마가 많이 보인다.
• 팔굽혀펴기: 9-10-11-11-10-9 총 60회.윗몸일으키기: 8-8-7-8-7-6 총 44회(약간의 뽀록성으로. 몸을 바닥으로 내리는 시점에서 등을 바닥에 붙여보지 못함. 많으면 30도 정도의 각도로 내려갔을라나?)
  윗몸일으키기의 경우야 이제 메이저 업그레이드를 해야할 시점에 도달했기에 어제보다 6회 더 많은 60회도 가뿐. 하지만 윗몸일으키기의 경우, 어제 너무 무리를 해서 그랬던지 뱃가죽에 알이 왕창 배겼다. 초반 20회정도는 어제와 비슷한 느낌으로 갔는데 후반에는 뱃가죽(뱃근육?)이 땡겨서 혼났다. 그나마 8-7-6의 마지막 회수가 나온 것은 뽀록성이 상당히 짙다. 내일이면 알이 좀 풀리려나?

오늘의 몸무게 76.9kg. 지난번에 꾸준히 77.6kg을 유지했다는 사실을 감안해보면 살이 빠지긴 한거 같다. 뭐 1.5kg정도는 하루만에 오르락 내리락하는 것을 봐선 그렇다고 장담할 수 있는 것은 아니지만, 동일한 코스를 밟았는데 그렇게 나왔다는 것은 분명 좋은 징조다. 또 하나. 스트레칭을 하니 도대체나 안올라가던 윗몸, 허리가 아주 쉽게 올라간다는 것. 허리에 힘이 붙는다는 느낌이 확실하게 다가온다. 굳이 표현하자면 허리를 구부리는 것이 아닌, 허리를 앞으로, 혹은 위로 잡아끈다는 느낌이랄까? 하여간 진척이 눈에 띄다보니 아~주 기분 좋다.

• 전반 반바퀴: 한동안 주법에 신경을 안쓰다보니 오늘 유난히 발디딤 수직 속도가 빠름을 느꼈다. 러닝머신에서 뛰었으면 뒷굼치로 인해 '쿵쿵'소리가 났을 법하다. 다시 살짝 주법에 신경써주기 시작함. '후우후우훕 후~'로 호흡이 바뀐줄 알았더니만, 그게 아니다. 예전의 호흡 리듬인 '훕훕후~'로 되돌아갔다. 억지로 '후우후우훕 후~'를 흉내내보았는데, 불편해서 중도 포기. 호흡이 너무 길다. 저번에는 어떻게 그리 길게 했을까?
• 후반 반바퀴: 오늘따라 몸이 매우 흔들렸다. 그림자를 통한 내 뛰는 모습이 아주 맘에 안든다. 속도는 못내면서 높이 뛰기만 하는 듯. 호흡은 전반의 리듬을 그대로 유지. 막판 전력 질주 거리를 좀더 늘렸다. 100m는 나오리라는 예상. 그리 뛰고나서도 호흡은 그대로. 분명 실력이 늘긴 늘었다.
• 팔굽혀펴기: 8-9-10-10-9-8 총 54회.
• 윗몸일으키기: 13-10-8-6-8-10 총 55회.동생이 보더니 많이 늘었다고 한다. 내가 느끼기에도 이제는 팔굽혀펴기에 각이 나오는거 같다. 한바퀴만 돌아서는 이젠 모자르고 세트당 횟수를 줄이고 두세트를 하는 것이 좋을 듯. 윗몸일으키기 횟수가 급격히 늘어난 이유는 스트레칭과 팔굽혀펴기와 윗몸일으키기를 교차해서 했기 때문이다. 그중에서도 스트레칭 덕을 많이보는 듯 한데, 특히 허리 굽히기를 중점적으로 하다보니, 자연스럽게 허리 움직임이 좋아졌다.

1. Native Type와 Managed Type 교차 상속 불가(H.Sutter에 의하면 지원 예정이라고.)

2. Managed Type의 멤버로 Native Type 객체 생성 불가. 단, pointer Type일 경우에는 가능.

3. Native enum 역시 마찬가지. Managed Type 내부에 Native enum 정의 불가

4. Managed Type의 Method 안에서는 Native Type 생성 및 사용 가능(포인터, 객체 모두 포함해서)

3일 연속하다보니 리듬을 살짝 탄거 같다. 초반부터 바로 "후우후우훕 후 ~~"의 안정적 호흡 모드로 들어가더니, 마지막까지 그 호흡을 계속하여 유지하였다. "훕훕후~"가 아닌, "후우후우훕 후~~"이 다. 글자만 봐서는 주로 입으로 쉰것 같지만, 실제는 콧구멍으로도 만만찮게 들락거렸다. 입은 힘빼고 어중간하게 벌린 정도. 확실한 것은 아니지만, 몸상태가 좋을 때는 콧구멍 평수가 더 늘어나고 코딱지, 코막힘 정도가 덜한듯 싶다. 확실히 입보다는 코로 숨쉬는 것이 더 편하다.

저녁을 먹기 전에 잰 몸무게 77.6kg. 운동 후 잰 몸무게 역시 77.6kg. 샤워 후 사이다 두잔정도 들이키고 잰 몸무게 또한 77.6kg. 오늘 이거 왜이래? 변화가 없다! 굳이 상황을 분석해보자면, 저녁을 먹고나서 몸무게가 늘어났다가 늘어난 만큼 운동으로 다시 빠지고, 샤워를 통해 뺀 땀과 때로 인해 조금 빠졌다가 사이다 두잔으로 제자리로 돌아왔을 것이란 예상. 절묘하게 아귀가 맞아 떨어져 변화가 없던 것으로 나타났으리라 생각해본다.

• 초반 반바퀴:발바닥 전체로 내딛는다는 것 빼고는 주법 완전 무시. 이젠 어떻게하던간에 발과 다리에 무리가는 법은 없다. 시작하자마자 호흡이 약간 불규칙해졌지만 이내 "후우후우훕 후~~" 호흡 모드로 돌입. 억지로 그리한 것은 아니고 그리 저절로 되더라. 뛰는 리듬과 아주 잘 맞아떨어지기에 후반부에서는 호흡을 의식적으로 유지했다. 저녁먹은지가 얼마 안된지라 뱃속에서 저녁으로 먹은 라면이 좀 출렁거리는 것 같기도.
• 후반 반바퀴:역시나 앞꿈치 모드로 변경. 정면을 주시하며 달리는 것이 좋으리라 생각했지만, 그림자를 통한 내 뛰는 모습에만 시선이 간다. 별로 볼 것도 없는데 말이다. 오늘따라 유난히 몸의 흔들림이 많아보였다. 그러고보니 요즘에 파워 워킹녀가 눈에띄게 줄어든거 같다. 유행이 끝난건가? 대신 쌍쌍으로 산보를 즐기는 커플이 많아보인다. 후후훔.. 그렇다고 뛰는 도중에 내 배알이 뒤틀리지는 않았다. 막판 50m 정도를 남기고 전력질주. 마지막 10m정도를 남기고 나서야 호흡이 불규칙해짐.
• 팔굽혀펴기:8-9-10-10-9-8 총 54회. 각 단계마다 하나씩 올렸는데도 불구하고 가뿐하게 끝냈다. 오늘 역시 전반은 슬로우 고고 모드로. 후반은 후따닥 해치웠다. 몸에 익숙해져서 그런지 후따닥 해치워도 (느낌상) 각은 나오는 듯하다.
• 윗몸 일으키기:10-10-10 총 30회. 물론 다리를 걸치고 해서 나온 횟수다. 팔굽혀펴기 쉬는 시간에 교차해서 윗몸 일으키기를 하니 이거 괜찮은거 같다. 어짜피 힘쓰는 부위가 완전 다르기 때문에 교차해서 하는 것이 가능하다. 그 덕분에 횟수 또한 상당히 늘릴 수 있었다.

아니 이놈의 몸무게가 미친건가. 통닭으로 저녁을 먹은다음, 운동 시작 바로 전에 젠 몸무게 78.6kg. 운동을 끝낸 후의 몸무게 77.6kg. 샤워를 끝내고 젠 몸무게 77.1kg. 약 두시간 반 사이에 무려 1.5kg이 줄어버렸다. 아니 잠깐. 방금 물 두잔을 마시고 나서 다시 제보았더니 다시 77.6kg으로 늘어났다. 후훔. 운동으로 뺀 땀이 1kg. 샤워를 통해 빠진 땀과 때가 0.5kg. 물 두잔이 0.5kg(??). 이렇게 정리하면 되는 건가? 이 중 몇백그램 정도는 체중계의 오차범위로 생각해보면.. 대강 말이 되는거 같기도 하고. 여하간 대략 1.5kg의 체중차이는 무시해야 한다는 결론이 나온다.

오늘 다시 '훕훕후~'의 안정적인 호흡을 되찾았다. 뜀박질 초반에는 어제와 마찬가지로 호흡의 변화가 심했는데, 약 1/3정도 뛰는 지점 정도에서 어느새 예전 호흡으로 돌아와 있었다. 입을 오무려서 내쉬기를 길게했는데 침만 잘고일 뿐 별로 좋은거 같지는 않다는 느낌이다. 한번에 들여내쉬는 양은 그대로인 채 호흡 주기만 길어진 꼴이다. 한마디로 말해, 폐활량 증가에 도움이 안될 것이라는 말이다.

• 전반 반바퀴: 이제는 발 전체로 내딛기만 할 뿐, 굳이 발디딤의 수직속도에 대해 신경쓰지 않는다. 신경쓰면 다리만 아플뿐, 그다지 관절이나 근육에 도움이 안되는 것 같다는 판단에서다. 좀 뛰다보니 이전 호흡을 찾기는 했는데, 어제보다 숨이 더 많이 차는거 같다. 이는 얼마전에 먹었던 저녁..통닭때문이다. 뱃가죽이 꽤나 무겁다.
• 후반 반바퀴: 이전과 동일하게 앞꿈치를 이용한 주법으로. 중반 이후로는 저녁 식사로 인해 옆구리가 아주 살짝 아파오기 시작했다. 다리가 아프다거나, 숨이 윗선까지 차오는 일은 없었지만 어제보다는 힘이 더 든다는 느낌이 분명했다. 하지만 이젠 본 코스에 상당히 익숙해진지라 중단하고 싶다는 마음은 들지 않았다. 막판 50m정도 남겨둔 시점에서 전력질주. 하지만 오늘은 어제보다는 확실히 느렸다는 느낌.
• 팔굽혀펴기: 7-8-9---9--8-7 해서 총 48회. 중간의 '--'는 쉰시간이 그만큼 길었다는 뜻이다. 쉬는 시간이라고 해서 그냥 쉬었던 것은 아니고, 윗몸 일으키기, 스트레칭 등으로 몸을 풀었다. 동생 왈, 스트레칭만으로도 살이 많이 빠진다나? 그 말이 옳건 그르건간에 워나게 몸이 뻣뻣한지라, 스트레칭이 그렇지 않아도 필요하기는 했다. 초반 24회는 아주 천천히. 후반 24회는 빠른 속도로. 물론 천천히하는 것이 더 힘들다. 알이 밴 것은 아니었지만, 어제에 이어 바로 하다보니 횟수가 부담스러웠다.
• 윗몸일으키기: 팔굽혀펴기 중간 쉬는 시간에 다리 걸친 상태에서 10회. 스트레칭으로도 뱃살이 빠진다해서, 윗몸일으키기의 비중을 줄이고 스트레칭으로 대체. 이렇게 하는 것이 더 효율적이다. 안되는 자세로 낑낑거리며 몇번 못하는 것보다, 되는 자세로 오랜 시간하는 하는 것이 더 낫다는 판단. 이렇게 하고보니, 적어도 땀은 더 난다.

일주일이 홀라당 넘어가버렸다. 꽤나 정신적으로 피곤한 일주일이였기 때문이다. 예전에 수시로 느꼈던 자괴감이 간만에 찾아왔기 때문이다. 자괴감을 느낀 이유, 몸이 축날정도로 괴로왔던 그 이유에 대해서는 적지 못하겠다. 쪽팔리기 때문이다.

일주 일정도 지나고보니 제정신으로 좀 돌아온듯 싶었기에 오늘 프로젝트가 재개된 것이다. 보통 그런식으로 괴로움을 느낄 때는 주로 '생각', '망상' 때문이데, 그럴 때는 이것저것 가릴거 없이 몸을 굴리는 것이 최고다. 이를 아주 잘 알고 있기에 운동을 다시 하려고 맘먹었지만, 실제 운동을 재개하기까지는 3일이 걸렸다.

멍한 정신만큼이나, 뛰던 그 당시의 몸 상태에 대해서도 크게 느껴지는 바가 없다. 민감하지 못하다는 말이다. 그나마 이전과 다른 변화를 꼽자면, 호흡이 매우 거칠어졌다는 것, 호흡이 불규칙적이었다는 것, 그 와중에도 지나치는 몸매 좋은 여자에게는 눈길이 계속 끌렸다는 것, 오늘따라 내 눈길을 잡아끌었던 여자가 많았다는 것 정도.

• 전반 반바퀴: 주법은 예전과 동일. 반도 안되서 호흡이 거칠어졌다. 오늘따라 '훕훕후~'의 규칙적인 호흡이 나오질 않았다. 달리는 도중에도 내 몸 상태를 느껴보려고 애썼지만, 당장에 생각나는 것은 '도대체 별다른 느낌을 찾지 못하겠군'이다. 전반인 만큼이나 달리는데는 문제없었다.
• 후반 반바퀴: 예전과 동일하게 앞꿈치를 이용한 주법으로 변경. 조금 달라진 느낌이라면 뛰는 높이가 커졌다는 정도? 이전회에서도 그랬던 것 같은데... 속도도 이전보다는 빠른거 같다. 뛰는 내내 그림자를 통해 내 뛰는 모습을 보았는데, 시선이 땅바닥에 있는 것이 그리 좋지 않아보여 앞을 주시하려고 애썼지만 어느새 내 시선은 바닥을 향해 있었다. 호흡이 아주 지랄이었다. '훕훕후~'가 아닌 '훕후~~'였다. 내쉬는 시간을 늘리려 입을 좁게 모아서 쉬었는데, 중간에 입을 잠시 벌리고 한번에 내쉬니 호흡이 망가지는 느낌이다. 입을 모아 쉬다보니, 후반에는 호흡이 상당히 거칠어지다보니 침이 튀어나와 옷을 적셨다. 으이그.
• 팔굽혀펴기: 7-8-9-9-8-7 총 48회. 왠일인지 느리게 내려가고 느리게 올라오면서도 나름대로 각이 느껴진다. 내려갈때도 확실히 가슴이 달랑말랑한 지점까지 내릴 수 있었다. 아주 간만에 운동을 하는 것이지만, 나름대로 이력이 붙은거 같다.
• 윗몸일으키기: 여전히 발을 고이지 않고서는 하나도 할 수가 없다. 오늘부로 당분간 발을 안괴고 하는 것은 중단하기로 했다. 1개도 하지 못하다보니, 도대체 뱃살운동을 할 수가 없다. 레벨을 내려 괴고 하는 것으로 변경. 10개 정도하니, 배가 아픈 것이 아니라, 허벅지가 아프다. 힘이 엉뚱한 곳에 들어간 것이다. 대강 허리부위 스트레칭으로 운동 마무리.
  
  요즘따라 예전에 날 괴롭히던 망상이 잘 따라붙는다. 분명한 것은 '생각이 많아지면 힘이 빠진다는 것, 특히나 그 생각이 망상인 경우에는'. 찌질거림에 대한 반감도 결국에는 망상이 바탕에 깔린 상태에서 나오는 표현이란 판단 때문인가?

아~주 간만이다. 약 일주일정도 거른건가? 꾸준히 지속해오던 운동을 잠시 멈추다가 다시 재개했을 때 갑자기 이전보다 기량이 더 났게 느껴지는 경우가 있다. 물론 그 상태가 지속되는 것은 아니고 재개하던 그 때 뿐이기는 한데, 오늘이 딱 그 꼴이었다. 오늘따라 왜 그리 뜀박질이 잘 되는지. 보폭이 상당히 커진 느낌, 속도가 한층 빨라진 느낌으로 가뿐히 풀코스를 뛰어주었다. 막판 1/4 정도를 남기고는 의식적으로 속도를 좀더 높이기도 하였는데, 처음으로 '훕훕후~'의 네박자 호흡 리듬을 맞추기가 힘든 상태까지 도달하였다. 뜀박질 전체 리듬을 깨지 않기 위해, 숨을 깊게 들여쉼으로써 억지로 호흡 리듬을 유지했다.

• 전반 반바퀴: 시작부터가 다르다. 늘어난 보폭 만큼이나 뛰는 높이도 더 올라간 듯한 느낌. 발딛는 수직 속도를 낮추는 것이 쉽지가 않다. 억지로 발디딤을 만들려고 하면 정강이 부위가 아파온다는 것을 알고 있기에 자연스리 발 전체로 디디면서 아주 약간만 주법에 신경을 썼다. 반바퀴 내내 특별한 이상도 없었고. 확실히 속도가 빨라진거 같다.
• 후반 반바퀴: 예전과 마찬가지로 앞꿈치로만 뛰는 주법으로 변경. 전반 때의 속도와 별반 차이가 없는거 같다. 간만에 뛰어서 그런지 초반에 아킬레스건 쪽에 힘이 많이 들었는데, 1/4 정도 뛰고나니 바로 익숙해진다. 평소보다 숨은 조금 더 찼다는 것을 느꼈지만, 속도가 빨라져서 그런가부다하고 넘어감. 막판에는 전력의 80%정도 속도로 질주. 질주 조금 전부터 계속해서 이어오던 '훕훕후~' 호흡 패턴을 맞추기가 힘들다. 들여쉴 때 조금 더 크게 들여쉬니 좀 나아진 듯 하기도 하고. 끝나고 나서 피가 역류하는 듯한 느낌은 없었음. 끝난 직후의 호흡이 상당히 중요하게 느껴진다.
• 팔굽혀펴기: 7-8-9-9-8-7-1의 총 49회. 6부터 시작해서 8피크를 생각했지만, 오늘 몸상태로 보아 조금더 올려도 상관없겠다 싶어 올렸더니, 대성공. 컨디션이 좋아 막판에 10개 정도 더 하려 했는데, 막상 하고보니 만만치가 않았다. 위의 1은 보너스 샷
• 윗몸일으키기: 다른 부위와는 달리 복근의 상태는 더 나빠진듯. 반동을 쓰지 않고는 1개도 못하겠더라. 깽꺵거리는 사이 시험삼아 동생에게 동일한 자세로 10개 정도 시켜보니, 가뿐하게 넘어감. 동생 왈, 한 30개까지는 할 수 있겠다고. 이 사태는 내 복근의 무기력함 뿐만 아니라, 딱딱하기 그지없는 허리 때문이기도 함. 허리가 유연하지 않다... 이거 결혼했을 시 '성생활' 측면으로 볼 때 고민 되는 문제인데.. 새삼 경각심이 느껴짐.
  
  당분간 윗몸일으키기의 횟수에 대해서는 입을 막는게 좋을 듯 하다. 쪽팔리기도 하거니와, 이 상태로는 개선 여지가 별로 크지 않을 것이라는 판단.

힘없고 짜증나고 우울한데, 그러한 상태의 나를, 그러한 상태에서 튀어나오는 생각을 표현하면 안된다는 압박감이 더 짜증을 불러 일으킨다. 그 당시 나타나는 생각이란 소위 '찌질거림'에 해당한다는 판단. 그 판단의 옳고 그름을 떠나, 찌질거리면 안된다는 법이 어디에 있느냐 말이다. 말도 안되는 압박임을 뻔히 알면서도 그러한 압박 속에 열심히 묶여 살고 있다니.

정제되지 않은 상태의 표현을 마주치는 것이 분명 유쾌하지는 않은 일이지만, 그렇다고 나 아닌 누군가를 위해, 더군다나 무작위의 누군가를 위해 이유없는 압박으로 나 자신을 옭아매는 것은 더욱이나 짜증나는 일이다. 한심스러운 일이다.

왕년에는 우울이고 나발이고 표출하고 싶은 내 모습을 맘껏 보였는데...
많이도 쪼그러들었다. 많이도 소심해졌다. 아직 장가도 못갔는데 이렇게 용기가 없어서야 원.

어제 아침에 재어본 나의 몸무게 77.5kg, 오늘 아침은 76.1kg. 식사 여부에 따라서 1.4kg이나 차이가 날 수 있을까? 여하간 기존에 재어보았던 몸무게는 77kg에서 79kg를 왔다갔다 했으니깐, 그간 운동의 효과가 있긴 있던 것 같다.

간만에 아침에 운동을 하였다. 아침이라고 좀 상쾌하고 몸이 가뿐할 줄 알았더니만, 이전과 별반 다를 바 없다. 지난밤에 그리 곱상치 못한 수면 자세로 있었던지, 괴상한 꿈만 꾸며 숙면을 취하지 못했던 이유다. 양재천을 뛰다보니 전에는 보지 못했던 허수아비가 늘어서있다. 작은 면적이기는 하지만 도심에서 벼, 옥수수 등을 재배하는 것만해도 그런데,허수아비까지 나타나다니 상당히 놀라왔다. 재배 면적에 비해 허수아비 수가 많은 것이나, 얼굴 등을 자세히 꾸민 것을 봐서는 아이들이 방학 숙제 등으로 한 것인 듯하다. 오늘도 두 블록을 도는 코스를 그대로 따랐다.

• 전반 반바퀴: 이 전번에 다리가 상당히 아팠던 것을 의식하여 뛰었다. 굳이 수평 착지 속도를 높이려고 하지 않으니 그리 아프지가 않다. 아침이라서 그림자를 통해 내 뛰는 모습을 볼 수가 없었는데, 느낌상 그리 곱상하지는 않을 것 같다는 생각이 들었다. 이상하게도 평소보다 몸이 마구 흔들리는 것 같다. 1/4 지점 정도를 지나치니 저절로 '훕훕후~' 호흡 모드로 변경되었다. 컨디션이 그리 좋지 않다는 증거다.
• 후반 반바퀴: 역시 앞꿈치 모드 변경. 컨디션이 별로 안좋은 것은 분명한데, 보폭이 커졌다는 느낌을 받는다. 보폭이 커졌다는 말은 그만큼이나 빨라졌다는 말. 시간을 정확히 재어보지 않아서 확실하지는 않다. 막판 전력 질주를 하려는데, 이미 최고 속도의 90%정도까지 올라있었다는 느낌을 받았다. 근간에 뛰고 난 직후에 느끼는 피가 거꾸로 쏠리는 듯한 느낌이 없었는데, 끝난 직후에 크게 호흡을 바로 하면 그 현상이 안나타난다는 것을 알았다.
• 팔굽혀펴기: 6-7-8-8-7--6-5 해서 총 47회. 평소보다 5번을 더 했는데, 막판에 쉬는 시간이 길다보니 힘이 남아돌아서 그런 것이다. 슬슬 몸에 적응되어 강도를 높여도 될 시기가 온 것인가?
• 윗몸일으키기: (튕기기를 약간 이용하여) 18회. 다리를 완전히 바닥에 붙여서는 여전히 하나도 안된다. 튕기기를 해선 허리만 아프다는 것을 잘 알지만 어쩔 수가 없다. 어쨌건 횟수는 좀 늘은거 같다. 팔굽혀펴기와는 달리 세트로는 하질 않는데, 본 프로젝트의 첫번째 목표가 '뱃살빼기'임을 감안한다면 자세를 교정하여 세트 모드로 가야하겠다.

Windows Vista와 .NET Framework 3.0에 적용될 Windows Presentation Foundation을 통해 웹 디자이너가 아닌 '응용 프로그램 디자이너'란 직업이 새로 생겨날 것이란 예측도 있더니만..

어찌되었건, 그러한 전문 디자이너가 보편화되기 전까지는 UI 디자이너 역할도 함께해야 하는 것이 우리나라 응용프로그램 개발자의 현실.. 특히나 울 회사같이 자금이 넉넉치 못한 벤처에서는.

다음은 MSDN에 올라온 WIndows 응용프로그램 UI 디자인 가이드라인.

응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법

지난번 윗몸일으키기를 하나도 못했던 원인은 뱃가죽 안에 알이 배겨서 그랬던 것이 확실한 듯하다. 오늘은 그나마 몇개를 할 수 있었는데, 처음 시작하자마자 뱃가죽 안의 근육(?)이 빳빳함을 느꼈던 것이다. 요런 근육(?)이 내게 있음을 이전에는 한번도 느끼지 못했는데.. 그래도 내 배에 똥뱃살만 있던 것이 아니라는 사실에 난데없는 뿌듯함을 살짝 느꼈다.

발바닥 전체로 뛰는 주법에 문제가 있는 것 같다. 주법 자체에 문제가 있는 것이 아니라, 내가 주법을 뭔가 잘못알고 있는 것 같다는 말이다. 오늘따라 심하게 정강이 근육과 발목이 아팠는데, 뛰면서 유심히 느껴보니 무리하게 힘이 가있는 것이다. 억지로 발 앞꿈치를 위로 쳐들어 내딛기 때문이다. 숨이 차거나 체력이 딸려서 힘든 것이 아닌, 다리가 아파서 힘든 조깅이 되었다.

• 전반 반바퀴: 여전히 발바닥 전체로 딛는 주법을 이용. 다리가 아프다보니 그림자를 통해본 내 뛰는 모습이 가관이다. 상당히 기우뚱거리고 있었다. 오늘따라 이쁜여자를 많이 지나쳤는데, 폼이 영 안났다. 다리가 아프다보니 숨도 이전보다 빨리 차오른다. 반정도 지나친 지점부터 '훕훕후~' 호흡 모드로 변경.
• 후반 반바퀴: 오늘도 역시 앞꿈치만을 이용하는 주법으로. 전반에 다리에 무리가 가다보니, 후반에도 그대로 영향이 미친다. 전반에는 주로 정강이 근육이 아팠는데 이번에는 발모가지가 아프다. 주법을 달리했으니 힘이 덜 들어갈 법도 한데 여전히 힘이 쏠려있다. 마지막 1/4 정도 지점을 남기고는 골반과 다리를 잇는 부분도 아파오기 시작한다. 찌르는 듯이 아픈 것은 아니고 약한 정도로 통증이 지속된 것이기에, 끝까지 달릴 수는 있었다. 막판 전력 질주를 하려해도 영 속도가 안났다. 꽤나 오늘은 힘들었는지, 끝난 후 간만에 몸이 져려왔다.
• 팔굽혀펴기: 6-7-8-8-7-5-1, 총 42회. 막판 5-1은 6번을 채우지 못하고 어퍼져서, 갯수나 채우려고 하나를 더 한것이다. 슬슬 가슴 근육에 힘이 전달되고 있음을 느낀다. 양 팔의 폭을 좁힌 상태보다 넓힌 상태가 더 하기가 힘들었다.
• 윗몸일으키기: 6회 + 튕기기로 5회 정도. 뱃근육에 생긴 알이 풀려서 그런건지 오늘은 발을 쭉 펴서 바닥에 붙인 체로 6회나 할 수 있었다. 알이 배겨있었음은 오늘에서야 알았고. 역시 튕겨서 하는 것은 허리만 아프지 뱃근육 운동에는 별 도움이 안된다. 새삼 많이 느낀 것. 어지간히 허리, 배가 뻣뻣하다...p.s 내일이면 체중계가 온다~!

오늘 역시 한세트 완료. 중간에 몇일 빼먹긴 했지만 3주 정도 끊기질 않아서인지 오늘따라 조깅이 가벼웠다. 초반 반바퀴 때는 굳이 '훕훕 후~'의 규칙적 호흡을 하지 않아도 별다른 어려움이 없었고, 후반 반바퀴 때도 힘들다는 생각이 거의 나질 않았다. 막판 100m를 남기고 전력 질주를 하고나서도 끝난 이후 별 느낌 - 피가 거꾸로 역행하는 느낌 - 도 없었고. 약간 빗방울이 떨어졌는데, 그만큼이나 시원했기 때문이었는지도 모른다.

팔굽혀펴기까지도 좋았는데, 아니 이런, 윗몸일으키기가 이전만큼 나오질 않는다. 딱히 배에 알이 배긴 것도 아니었는데 말이다. 후훔... 나도 모르는 사이 뱃살 안에서 알이 배겼던 것일까?

초반 반바퀴: 오늘 역시 발 전체로 내딛는 주법을 이용. 확실히 다리 전체에 힘이 많이 들어간다. 특히 정강이에 달라붙은 근육에 힘이 쏠리는거 같다. 움직임이 둔하다는 것을 느낀다. 뛰는 그림자를 보며 새삼 느낀 것이, 뛰는 모습이 꽤나 추하다는 것. 경보 비스무리한 포즈같기도 하다. 이외에는 별 무리없이 호흡에도 신경이 전혀 안써질 정도로 쉬웠다.

후반 반바퀴: 앞꿈치만을 이용한 주법을 이용. 오늘따라 유난히 힘이 덜들었음에도 불구하고 이전보다 속도를 더 내지는 않았다. 뭐 진정 실력이 올랐다면 내가 억지로 빨리 달리지 않아도 알아서 속도가 붙을 것이라는 예상. 그림자를 보니 발 전체를 딛는 주법의 포즈나 앞꿈치만을 이용한 포즈나 거기서 거기다라는 생각이 든다. 그렇다면 이건 주법문제가 아니라 나의 달리는 모양새가 원래 그리도 추한 것인가? 후훔.. 그동안 지나쳐간 파워워킹녀들이 내 모습을 보고 비웃었는지도 모른다. 쭈압.. 막판 100m 정도를 남기고 전력 질주. 오늘따라 유난히 컨디션이 좋다.

간만에 한세트(그러니깐 조깅부터 시작해서 팔굽혀펴기, 윗몸일으키기 말이다)를 전부 돌았다. 샤워까지 마치고 이 글을 쓰는 이 시점.. 매우 뿌듯하다. 하하~

양재천을 낀 두 블록 코스. 어제에 비해서는 조금더 힘들었지않나 싶다. 후훔, 어제 코스가 짧았던 것일까? 후반부에 가서 꽤나 잡생각 안하느라 고생좀 했다. 꽤 힘들다 싶을 때야 잡생각을 안하려고 따로 노력하는데 오늘이 그랬던 것이다. 육체적으로 힘이 들어 포기하고픈 맘이 들때면 군대시절 유격행군을 떠올리며 화이팅을 외치는데, 오늘도 그 시점까지 도달했으니 말이다. 유난히 오늘따라 이쁜 여자가 안보여서 그랬을 수도 있다.

전반부: 역시나 발바닥 전체로 뛰기. 이젠 발바닥의 뜨거움을 느끼지는 않는다. 다만 다리 전체에 힘이 과도하게 들어가있다는 느낌을 받았다. 그다지 유연하지 못하다고나 할까나? 뒷주머니에 넣어둔 열쇠가 찰랑거려 꽤나 신경쓰인다.

후반부: 이 역시나 앞꿈치로 뛰기. 분명 어제는 주법을 변경하면서 절로 빨라짐을 느꼈는데, 오늘와보니 그다지 빨라진 것 같지도 않다. 군대에 있을 때 동기들 왈, 머리를 좌우로 기우뚱거리며 뛴다고 했는데, 내 달리는 모습을 그림자를 통해 보니 별로 그렇지도 않은거 같다. 머리가 아니라 몸 전체가 그렇듯 싶고. 그다지 폼나는 뜀박질 폼은 아니다. 누가 보더라도 아마추어의 그것. 쓸때없는 움직임이 많다고나 할까나? 어제보단 힘들었지만, 오늘도 막판 전력질주를 할 힘은 남아 있었다.

뜨아, 뛰고난 이후 바로 목욕탕으로 직행해버렸다. 날이 좀 지난지라 알도 다 풀려서 간만에 윗몸일으키기를 해보겠구나 싶었는데 깜빡해버린 것이다. 그럼 지금하면 되지않냐 싶겠지만, 샤워까지 마친 풀린 몸으로 또다시 땀을 빼기는 싫다. 뭐, 가뿐히 오늘은 재끼는 것이다.

(이건.. 샤워를 해도 별 수 없다. 샤워를 마친 후 수건으로 젖은 몸을 닦는 도중에도 땀이 난다. 특히 얼굴에서 땀이 '흘러내린다')

참으로 아쉬운 것이, 내가 도대체 몇 km를 뛰었는지를 모른다는 것이다. 오늘도 어림잡아 5km 내외를 뛰었으리라 예상만 해본다. 귀찮아서 시간도 재지를 않았다. 오늘은 코스가 약간 달랐는데, 주변에 자전거 대리점을 찾느라 그간 뛰던 방향의 반대로 한참을 걸어내려갔기 때문이다. 거리는 양재천 다리를 기준으로 한 블록 반 정도. 자전거 포를 찾아낸 후, 바로 그 거기서부터 뛰다보니 보통 처음 시작하는 지점까지 해서 약 1/3을 뛰게되는 것 같다. 1/3 지점까지는 발바닥 전체로, 나머지는 앞꿈치로 뛰었다.

1/3 지점까지: 왠일로 발바닥이 그다지 뜨겁게 느껴지지 않는다. 몸도 왠일인지 평소보다는 가볍다. 뛰기 시작한 이후 얼마 안있어 '훕훕 후~'의 규칙적 호흡 모드로 자연스리 변해있었다. 움... 벌써부터 몸이 적응하기 시작한건가?

아침에 일어나보니, 가슴살부터 팔꿈치까지의 모든 근육(및 살)이 아프다. 알이 제대로 베겼다. 다만 사타구니와 다리를 잇는 안쪽 근육은 멀쩡하다. 요 근육이야기를 왜 하느냐하면, 근간에 조깅을 했다하면 그 근육먼저 땡겨왔기 때문이다. 그 땡겨옴도 일종의 '알베김'이라고 해야겠지.

양재천을 끼고 두 블록을 왕복하는 지금의 조깅 코스가 정확히 얼마나 나올지는 모르겠지만, 뭐 대략 5km는 나오지 않을까 예상한다. 뜀박질에 걸린 시간은.. 30분이 조금 못미치는거 같다.

나 보다는 헬쓰에 대해 조금 더 많이 아는 동생 왈, 뜀박질에도 두 종류가 있단다. 하나는 지금까지 내가 했던 방식인 앞꿈치로만 뛰는 것. 이전에도 말했지만 이는 무릎 관절을 보호하기 위해서다. 또하나는 뒤꿈치부터 디디되 수평 착지속도를 높여 수직충격을 최소화하여 뛰는 것이다. 전자는 단거리용이고 후자는 장거리용이라나? 꽤 그럴싸한 이야기이다. 어쨌건 간에 디디는 표면적이 넓어지기에 아무래도 충격이 덜하겠지. 대신 느려지는 것은 어쩔 수 없겠다.

또한, 같은 거리라도 꾸준한 속도로 뛰는 것보다 속도 편차를 두는 것이 같은 시간이라도 더 많은 운동 효과를 낸단다. 그렇다면 두 주법을 모두 채용하여 뛰면 딱이라는 결론이 나온다.

그러니깐, 이전에 이 프로젝트가 중단된 날짜가 작년 9월이었으니, 거반 1년이 지난거 같다. 3개를 포스팅했는 줄 알았는데 4개였군. 작심 3일은 넘겼던 셈이다. 풋.

시간이 얼마나 흘렀건간에, 중도 포기한 것은 아니다. 본 프로젝트를 진행한 후(그러니깐 뱃살빼기용 운동을 한 후), 지금 이렇게 포스팅까지 날리고 있으니 말이다. 다만 이글루 가든의 '할일' 제목이 조금 변했을 뿐이다. '적어도 삼일에 한 번은 헬쓰장 가기'에서 假題였던 "권상우 몸 반만이라도!"로.

제목이 변경된 만큼이나, 본 프로젝트도 헬쓰장에서 이루어지지 않고 있다. 몸을 태워 살을 빼는데 필수인 조깅은 양재천에서 이루어지고 있다. 헬쓰장에서 TV화면이나 보며 뛰는 것에 비해 심심하지는 않지만, 내가 몇 km를 뛰었는지 얼마나 칼로리가 소모되었는지 등의 자세한 운동 내역을 알 수 없다는 것이 아쉽다.

뭐 오늘 말고도 최근 한달 중 서너일을 뛰었었는데, 본 프로젝트를 재개해야겠다는 생각은 오늘에서야, 그것도 거반 다 뛴 시점에서야 났다. 후훔... 이 말은 뛰던 중 나의 몸 상태에 대해 기억나는 것이 없다는 변명이다.

적어도 표면적으로 경제적으로는,

지금보다 훨씬 더 안좋은 상황에서도 이처럼 찌질거리는 생각이 내 머릿속을 해매어 다니지는 않았다.

찌질거림이란?

1. 불만족스러운 삶의 원인을 나 이외에서 찾는 행위.
2. 반성의 뉴앙스로 가장한 자학을 통해 마음의 평화를 얻음으로써 근원적 원인 해결을 중단하는 행위.

"MFC를 포함한 Native C++ 코드와 .Net 코드를 어디까지 짬뽕할 수 있는가"란 주제로 이것 저것 들쑤시던 중, STL.NET을 써보려 했더니만 도대체나 이놈의 라이브러리가 보이지 않는다. Stan Lippman이 그리도 뛰어나다 광고하며 VS2005에 포팅된다던 그 라이브러리가.

잠시 웹을 뒤져보니 VS2005에는 포팅이 안됐다는 소식이 보인다. Where is STL/CLR

어느새 STL.NET은 STL/CLR란 이름으로 바뀌어 있었으며 Visual Studio 다음 버전인 Orcas에서나 선보인다고 한다. 그렇게나 광고를 때렸는데 출시를 못했다니, MS VC++ 팀.. 수뇌부에게 엄청 깨졌을 터. 스티브 발머.. 생긴거 봐서는 꽤나 성깔 더럽겠던데.

잠시 C++/CLI: .NET 프레임워크 프로그래밍을 위한 가장 강력한 언어(1/2)를 만져보니, '포인터를 통해서만'이란 수식어가 붙기는 하지만 managed 타입 내부에서 직접 Native 타입의 조작이 가능하다. 그렇다면 COM을 통해 Native C++ 타입의 인터페이스를 빼지 않고도, C#으로 Native C++ 타입을 조작할 수 있다는 이야기?

움… 상당히 흥미로와진다.

아니 어제 하루도 시간 잘~ 보냈다. 후훔.

영화 한편과 삼순이 씨리즈를 모조리 디비고 나니 어느새 새벽 1시가 넘어가 버린 것이다. 이제 잘시간이다. 확실하게 다음 할일이 정해져 있으니 안도감을 느낀다. 뭔가 이상하다.

"뭘 할까?"도 아닌 "이제 뭘 해야하지?"하고 반문하는 때가 무진장 많아졌다. 이 말은 그만큼이나 한가하다는 뜻인데, 나의 지금 상황이 그렇게 한가해도 되는 것인지 잘 모르겠다. 경험상 그런 생각이 나는 상황은, 방향을 잃었을 때에 나타나곤 했는데.. 말이다.

여하간 일종의 우왕좌왕... 그 와중에 내가 선택한 일은 영화 한편과 삼순이 씨리즈 디비기였다. 그 '선택'이라 칭한 행동의 옳고 그름의 여부는 둘째치더라도, 과연 그 행동은 '선택'이라 부를 수나 있는 것인지 모르겠다. 컴퓨터 앞에 앉고 보니 아주 자연스럽게 연달아 일어난 행동의 결과였는데.. 어느새 나는 그 영화를 보고 있었고 삼순이 씨리즈를 보고 있었는데..

'모자로군'

난 딴 예기 안할 것이다.내 그림 보여주길 고집할 것이다.
"나는 그에게 이해를 강요하고 있는 것은 아닌가?"

쓰발... 하늘에 구멍이 뚤렸다.

잡생각... 갑자기... 밥먹기... 등으로 인하야...
네시간을 이 도서관에서 그냥 보내고 있다. 나의 의지와는 상관없이, 그냥 그리 흐르고 있다.

정칙이 있어야 변칙이 살고, 변칙이 있어야 정칙이 산다고 생각합니다.

손석희 (MBC 언어운사 웹진 창간 모임 중에)

'능숙함'이란 정칙과 변칙이 조화를 이룬 모습, 정칙과 변칙 둘 모두의 달인이 보여주는 모습이라 하겠다.

'변칙'보다는 '원칙'에 더욱 충실한 사람, 충실했던 사람이라 느껴지는 그는, '정칙'과 비스무리한 뉴앙스를 주는 또다른 어휘, 훨씬 더 많이 쓰이는 어휘인 '원칙'을 쓰지 않았다. 뭐, 그 어휘를 쓰지 않은 정확한 이유를 알 도리는 없다만, 그간 '원칙'이란 어휘가 남용되어 상대적으로 '변칙'의 중요성은 깎여나가는 모습, 다른 말로 표현하여, 이들 두 어휘가 주는 중요성에 대한 인식의 균형이 깨진 모습이 대중들에게 보였기 때문일지도 모른다..라 생각해 본다.

근 1년만에 삼성에서의 생활을 마감한다.

환송회 술자리. 그간 벌려놓았던 (개인적인) 나에 관한 일에 대해 간만에 창수 대리님이 물어보았다. 이제 과거사 정리는 다 끝났냐고. 정신없이 웃고 떠드는 와중에 쉽게 대답하고 만다. "다 끝났어요."

갑자기 그 얼버무리고 말았던 대답을 다시 생각하게 된다. 과연 끝난 것일까. 어느새 나는 그 엉성했던 대답 만큼이나 엉성하게 나의 과거, 그리고 그 과거에 얽힌 또다른 사회와의 관계를 마무리하려고 했었다. 진정 그렇게 엉성히 매듭져진다면, 이는 또다른 KARMA로 변하여 내 뒤통수를 잡아당길 것이다. 자유롭지 못하게 될 것이다.

마음의 '거리'는 말할 것도 없고, 우습게 보았던 물리적인 '거리'마저 이제는 부담으로 다가온다. 그 '거리'를 좁혀내는 것은 나 자신에게 달린 일임을 잘 알지만, 이를 수행해낼 (그간 믿고 있던) 정신적 에너지 역시 여러 일에 치여 바닥나고 있는 듣한 느낌이다. 아니, 이미 그리된지 오래이다.

말그대로 딱 3일만이다. 이거 역시 만만찮은 일이다. 특히나 요즘 같이 바쁠 때에는.

• 달린 거리: 7.1km
• 달린 시간: 51분
• 속도: 최초 8km/hr 부터 0.5km에 0.1km/hr씩 올려 최종 9.1km/hr까지 꾸준히 올림.
• 소모 칼로리: 396kcal
• 샤워를 끝내고 물 몇잔 마신 후의 몸무게: 77kg

3일차 때였다. 신나게 뛰고 있는데 헬스장 아저씨가 내 옆으로 오더니만 발 뒤꿈치를 들고 앞굼치로만 뛰라 한다. 거 어디서 들었던 이야기인거 같아 바로 자세를 교정하여 그리 뛰었더니만 이거 열라리 빡시다. 그날 운동을 끝낸 후, 헬스장 아저씨와 몇마디를 더 나누었는데, 발바닥 전체를 붙이고 뛰는 것은 몸에 별로 않좋고, 운동 효과도 크지 않다고 한다. 힘이 다리 근육에 전달되는 것이 아니라, 관절에 전달되는 것이라나? 그래서 산을 탈 때, 오르는 것보다 내려가는 것에 신경을 써야 한다고 한다. 왜? 내려갈 때는 뒤꿈치가 항시 바닥에 붙기 마련이기 때문에.

한 30분 정도 되는 때까지 그 자세를 유지하면서 달렸다. 일단 보폭이 커지는 느낌이다. 겅중겅중 뛸 수밖에 없는거 같다. 말을 미리 들어서 그런 것인지는 모르겠지만, 진짜로 다리 근육에 힘이 간다는 느낌이 든다. 하지만 난 평발끼가 있어서 그런지, 발바닥 움푹 파인 중간 부위가 계속해서 아파왔다. 익숙치 않은 자세로 신경써가면서 달리니, 힘이 더든 것은 말할 나위도 없다.

정확히! 작심 3일차에 실패를 맛보았다. 원래는 어제 갔어야 적어도 3일에 한번은 헬스장에 가는 것인데.. 변명을 늘어놓자면 이렇다. 몇일 전에 할머니께서 쓰러지셔서 간병 등의 이유로 병원에 들락날락 거렸고, 들락날락 거리고 있는데 도대체 시간이 안나는 것이다. 지금 쓰는 이 글도 잠시 시간을 내서 후따닥 쓰고 있는 것이니..

뭔가 맘을 먹고 실행에 옮기는 데 있어, 어릴 때는 게을러서 실패하고 나이 먹어서는 바빠서 실패하는 거 같다.

달린 거리: 6.45km

당장 또 병원으로 가서 울 오마니와 바톤 터치를 해야하기 땜시, 오래 달리지 못했다. 지금의 정신에 이 글을 쓰고 있다는 것 조차 사실 내겐 놀라운 일이다.

헬스장에 가보니, 지난 등록일이 2003년 11월.. 우후훔, 벌써 2년이 되어가려 한다.

헬스장 아저씨 왈, 1시간에 10km 주파를 목표로 일단 뛰란다.

…

일단 뛰고 보았다. 1시간에 10km면, 평균 시속 10km로 1시간을 뛰어주란 야그다. 시속 10km로 놓고 러닝머쉰 위에서 달려보니 이거 우습다. 적어도 시속 15km는 내야 내 속도로 나올거 같다. 하지만, '처음'임을 생각해서 일단 시속 10km에 45분을 놓고 뛰었다.

...

1. express concept directly in code
2. express relations among concepts directly in code
3. express independent concepts in independent code
4. compose code representing concepts freely wherever the composition makes sense
   
5. 개념을 코드에 직접적으로 반영한다
6. 개념들간의 관계를 코드에 직접적으로 반영한다
7. 서로 독립적인 개념들을 독립적인 코드에 반영한다
8. 개념들을 나타내는 데 있어 자유롭게 코드를 구성하되, 그 구성은 언제나 타당하도록

…

I "measure" maturity primarily based on how close people got to those ideals in production code (i.e., in code suffering real-world constraints). People who use C++ primarily as "a better C" fail on the first count - they fail to use classes, class hierarchies, and parameterization (template) to express ideas and relations among ideas directly. People who insist seeing C++ as just an object-oriented language fail on the third and fourth - they construct massive hierarchies that bind unrelated concepts together through unsuitable bases and exclude built-in types and simple classes.

사랑은 감정이 아니다. 사랑이 시험에 들었다.

비트겐슈타인

란다.

사랑이 시험에 들었다라니.. 번역을 어떤 놈이 한거야? 어쨌건간에,

말할 수 없는 것에 대해서는 침묵해야 한다.

"하늘을 내 집의 지붕으로 삼는다."

영웅문 3부의 ‘양정천’이란 이름이 생각났다. '양'은 성에 해당하고 '정천'이란 이름에는 '하늘을 짊어진다.'란 의미가 담겨있었다고 기억하는데, '정'에 해당하는 한자는 찾지 못하겠다. 내가 잘못 기억한 것일 수도 있다.

여하간..
그 의미, 그 말이 다시금 떠오를만한, 그리고 그 마음가짐이 절실해지는 상태가 돌아왔다.
그야말로 '몸을 던지는 자세'가 필요한 때에 도달했다.

그 골문에는 어느새 수문장이 들어 앉았던 것이다. 그녀는 어느새 수문장을 들여 앉혔던 것이다.

약간 고상하게 이야기하자면, ”한번 뜻을 품으면 뿌리를 뽑는다”에 담긴 자세.

꼭 그 말에 충동받는 것은 아니지만 어찌되었던 간에 비슷한 의미로 날 몰아가는 또다른 말,

“남자가 칼을 뽑으면 무라도 썰어야지”

“안되면 되게 한다.. 하면 된다”

다른 한편으로 생각해보면 대성공 또한 될 가능성 또한 농후하다.

간만에 그 때 그녀에게 보냈던 메일을 읽어보았다. 알고보니, 마지막으로 보냈던 것이 바로 오늘이었다. 그러니깐, 정확히 2년만에 작업을 재개한다고 해도 별로 이상할 것은 없겠다. 뭐, 요런식으로 숫자를 짜맞춰놔야 왠지 '운명'에 해당하는 무엇처럼 보이게된다. 그리고 나는 '의미'를 하나 더 가져다 붙일 수 있게 되는 것이다. 물론 구린 냄새가 아주 쫴금 풍길 법도 하겠다. 허나, 결코 그렇지 않다고 우길만도 한 것이, 들쳐본지 오래된 그 편지들을 왜 하필이면 오늘 들쳐보게 되었느냐하는 것이다. 이건 뭣하는 우연이냐고 묻는다면 말이다.

하긴... 그게 뭔 그리 대단한 사건이냐라고 묻는다면 그에 대해서도 할 말은 없다. 의미란 역시 가져다 붙이기에 따라 달라지는 것인가? 상황에 따라선.

얼마전에도 '성공'이니 뭐니 하는 생각을 갖고 나 자신을 질책했는데, 그것은 분명 아니라고 생각했는데.. 그당시에는 분명 '나'를 던졌는데..

나의 생각이 맞건 틀리건 간에, 내게는 그런 생각이 들었다. 그들의 반응은 '무관심'과는 다른 것이었다고. 모종의 '나'에 대한 선입견이 작용하고 있다고. 아마도 그 선입견이란, '나이 먹은 노땅이 자신에게 맞는 놀 곳을 잃어버려 혹은 그곳에서 쫓겨나서 만만하게 보이는 자기들.. 나보다 어린 사람들이 있는 곳으로 찾아들었다.'에 해당할 것이라고.

역시 그 생각이 맞건 틀리건 간에, 내가 그러한 오해를 불러일으킬 여지가 있는 행동을 하고 있다는 것, 자의건 타의건간에 그러한 상황에 처해 있다는 것, 그리고 그러한 상황에 처할 수밖에 없도록 살아왔던 지난 과거의 나 자신에 대해서 나는 매우 불만이다.

이러한 불만이 내게 존재한다.. 이는 내게 아직도 풀지 못한 매듭이 있다는 반증이다. 그러므로 나는 그곳에 제대로 들어간 것이다. 그곳에 가야만 한다는 나의 판단이 옳은 것이다.

그들… 그 후배들의 빠른 판단. 어설픈 판단. 열심히들 오해해보라지. 오해를 하고 있는 그만큼 제대로 이해하기까지 자신만 고통스러울 터이니.

후후... 난 거창한 것을 좋아한다.

나의 감관을 통해 내게 남겨진 여러 표상들.
그리고 직관과 추론이라는 두 도구를 통해 처리, 재생산된 결과물.
그 내적 활동의 결정체가 나의 언어를 지배해야 하지만,
나의 행동 방향을 결정해야 하지만,

아쉽게도 나는 아직 완전히 깨어있는 자가 아니므로,
결코 그러한 자가 못되므로,

내게서 설익혀 무심코 튀어나오는 언어, 행동조차,
역으로 나의 내적 활동, 판단 과정에 영향을 미친다는,
나의 가치관에 영향을 미친다는 점을 인정하지 않을 수 없다.

기억해 두거라. 추상화, 상속, 다형성이란 개념을 알았다고 해서 네가 훌륭한 객체 지향 설계자가 되는 것은 아닐지어다. 진정한 구루는 어떻게 하면 유연성을 갖도록 설계를 하여, 유지보수가 용이하고 변화에 능동적으로 대응할 지에 관해 고민을 한다. (알겠느뇨?)

Remember, knowing concepts abstraction, inheritance, and polymorphism do not make you a good object oriented designer. A design guru thinks about how to create flexible designs that are maintainable and that can cope with change.

guru틱한 자세로 앉아있는 어떤 인도여자 왈(in Head First Design Pattern)

Stroustrup 이 C를 제껴놓고 C++를 만들 때 추구했던 목표 중 하나는 속도 향상이 아니라 유지보수성 향상이 아니었을까? 다시 말하자면 그의 목표는 C보다 나은 유지보수성을 갖춘 언어를 만드는 것에 있지 않았을까?

아니 좀더 일반화하여, Object Oriented Programming이라는 개발 방법론의 탄생 배경에는 보다 나은 유지보수성을 갖춘 프로그래밍 방법론이라는 목표가 담겨있지 않았을까?

진리는 혼돈에서보다 과오로부터 더 잘 나타난다.

프랜시스 베이컨

어설픈 전통.. 그 묘한 패턴으로의 안주.. blinding.. 혼돈.

실체를 바라보기 위해.. 아니, 패턴에 휩쓸리지 않기 위해서라도, 위험을 무릅쓰고 부딛히는 수밖에 없다.

국민의 90%가 부동산에 관심이 쏠려있다.

떠도는 말 中에서..

아주 간만에 만나본 어떤 지인들. 우짜 살고 있는지 몇마디 나눈 후에 심층(?) 대화로 들어가니, 당장 먼저 나오는 주제.. 공통된 첫 번째 관심사가 '부동산 투기'.

그 지인들, 대부분은 이제 겨우 돈을 모으기 시작할 나이인, 경력 1~2년차의 평범한 샐러리 맨이 대부분이었고, 어떤 이는 학생, 그나마 그중 가장 나이가 많았던 한 형만이 자영업으로 큰 액수의 돈을 만질 수 있었던 사람들이었다.

바로 그 모양새를 보고 '깝친다'라고 말할 것이다.
'깝친다'란 말이 가장 적당할 것이다.

그 꼴을 보는 것은 참으로 힘든 일이었다.
젠장, 내가 왜 피하기만 했지? 그 대신, 치워버렸어야 했는데.. 쓸어버렸어야 했는데..

두, 세달만 되도 알아차릴만 한데, 그들은 1년이 넘도록 못알아 차리고 있다.
그렇게도 속고 나서도, 그 모양새가 만들어내는 장단에 여전히 맞춰 놀아나고 있다.
자신이 얼마나 많이도 당했었는지 모른채 말이다. 그러고 나서도 개떡같은 개떡받고 좋아하기만 한다.

떨어져 지내보니 이젠 알아차릴만도 한데, 그들의 그 멍청한 뒷장구는 계속된다.
그리고 묵묵히 자릴지키며 무덤덤하게 자신이 할 일을 하는 사람에게는 그 잔머리꾼과 똑같은 모습으로 속이려 들고 있다. 꽤나 자신들이 똑똑한 줄 안다.

거반 진리에 해당하는 것이라고 믿는 생각중 하나..

"이해하기 힘든 글은 주제에 대해 글쓴이 자신이 그만큼이나 이해하지 못했다는 사실의 반증이다."

생각해보니, 장자의 "논쟁은 분명하게 보지 못한 증거다."란 말과도 상통하는 것 같다.

그간 나의 'see'에 대한 믿음.. 그 믿음의 기초가 되는 동양의 여러 유명 도사님들의 말..

하나의 생각이, 하나의 관념이 내 머리를 떠돌고 있다.

이리저리 모든 상황에 끼어들어 결국에는 모든 것들을 그 관념에 들어맞도록 변화시키고 있다. 합리화시키고 있다. 그리고는 내 머리를 짓누른다. 점점더 주위 사람들에 대한 감정은 소원해진다. 계속 가다보면 어느새 그들은 적으로 변해버릴 것이다.

그간 이뤄왔던 그들에 대한 신뢰는 무너지고, 그들을 대하면서 느꼈던 호의적 감정은 점점더 사라진다. 그 관념은 대상을 가리지 않고 무너뜨린다. 인간에 대한 모든 것들을.

나는 아주 잘 알고 있다. 아니, 아주 잘 믿고 있다. 그 관념으로 인해 일어나는 모든 것들은 실재의 것들이 아니라, 결국에는 내 머리안에서만 일어나는 것이라는 것을. 그것의 정체는 유령이라는 것을. 소위 maya라고 불리는 망령이라는 것을. 그 순간 나의 행동은 실재안에서 일어나는 것이 아니라는 것을. 홀린, 미친 짓거리라는 것을.

얼마나 많은 시간이 그냥 지나쳐가는지 모르겠다. 과연 그 시간이 그 반성문이 나오기 위한 필요 조건에 해당되는 것인지도 확실치 않다. 기껏 힘겹게 시간을 마련해놓고, 구상을 한답시고, 혹은 기억을 되살린다는 의지 아래에서 결국 하고 있는 꼴은 그 목적과는 아무런 관계없는 딴 생각, 딴짓거리.. 맹~하니...

'말 꾸미기' 좋아 하는 사람들은 이를 보고 '명상, 구상 중'이라고 한다. 난 이를 보고 '헛지랄'이라고 한다. 아니, '헛지랄'이 많이 들어간 무엇.. 에라... 모르겠다~

문득 또다시 영화 Adaptation이 생각났다. Adaptation의 경우 Kaufman이 실제 만들고자 했던 시나리오는, 그 주제는 영화가 보여주었던 그대로의 것, 즉 작가 자신의 모습이 아니라 Orchid, Susan이 난초와 난초꾼에게서 받았던 감흥이 아니었을까? (영화에 나오다시피 그 어떤 이유로던 간에) 결국은 실패하고 그 실패에 대한 대안이라고 마련한 것이 '- 실패에 도달하기까지의 자신의 모습 - 이란 주제로 바꿔버림'이 아니었을까? '가다보니 어느새 처음 의도했던 것과는 완전히 달라진 무엇.. 이 우연찮게 튀어나온 것'이 바로 영화 Adaptation이 아니었을까? 그럴 가능성이 상당하다.

For returning to the Source의 '본편'이 아니라 '외전'이 많아지는 현상..

Don Box의 Essential COM을 보다가 발견한 묘~한 테크닉.

뭐, 중첩된 클래스의 생성자 등에서 중첩한 클래스의 this 포인터를 인수로 넘겨주어, 이를 멤버 변수로 갖고 있으면 되니깐, 그다지 실무에서 쓰일 일은 없는 듯한 테크닉이다. 하지만 (작긴 하지만) 멤버 변수가 차지할 메모리를 안잡아 먹는다는 점, 그리고 요 테크닉을 다른 곳으로도 확대해서 쓸 가능성이 보인다는 점에서 봐둘만 하다. COM에서는 composition 기법에서 요 테크닉을 사용한다고. 이놈의 COM을 제대로 알려면 instance의 메모리 구조도 알아야 하니... 쭈압. composition 기법은 MFC의 COM에서 사용한단다.

다음은 요 테크닉의 핵심인 offsetof() 매크로.

offsetof()는 자신의 부모 구조체(중첩한 클래스)의 시작 주소에서 멤버(중첩된 클래스 등) 주소까지의 거리(offset)를 반환한다고. 요놈은 함수가 아닌 매크로다. 다음은 샘플코드다.

STL.NET Primer (3/4)에서 이어지는 글입니다.

이 컬럼은 STL.NET Primer란 제목으로 MSDN에 포스팅된 글을 번역한 것입니다.

알고리즘 선택하기

지네릭 알고리즘은 STL/STL.NET 컨테이너에 담긴 요소와 두가지 내장 배열 타입에 담긴 요소 모두에 운용됩니다. 지네릭 알고리즘은 검색(find, count), 정렬(merge, partition, permutate, reverse, rotate, shuffle, sort), 삭제/치환(remove, replace, swap, unique), 복사, 관계(equal, min, max, includes), 산출(fill, for-each, generate, transform), 설정(union, intersection, difference), 힙(make, sort, pop, push) 연산을 지원할 뿐만 아니라, 축적(accumulate), 부분합(partial sum), 내적(inner product), 인접차(adjacent difference)과 같은 난해한 수치 연산도 지원합니다.

STL.NET Primer (2/4) 에서 이어지는 글입니다.

이 컬럼은 STL.NET Primer란 제목으로 MSDN에 포스팅된 글을 번역한 것입니다.

기반 지식 정의

STL.NET 을 알아가는 데는 두 가지 방법이 있습니다: 하나는 STL과 STL.NET의 차이점을 알아보는 것이고, 다른 하나는 STL과 STL.NET이 공통점을 알아보는 것입니다. 이 둘의 차이점을 나열하는 것은 이미 STL을 맛보았던 사람에게만 와닫을 법하기 때문에, (독한 연기로 질식시키는 듯한) 라이브러리의 낯선 부분에 대한 설명은 피하는 것이 좋을 듯 합니다. 말하자면, 컨테이너의 세밀한 특징, 그리고 System 컬렉션 라이브러리와의 상호운용 원리라는 난해한 부분에 대해서는 설명을 자제하겠다는 뜻입니다. 물론 이들 사항도 흥미로운 부분이긴 합니다. 하지만 이들 사항에 대한 설명은 이 라이브러리에 깊이 빠진 새로운 누군가의 몫으로 남겨두는 편이 더 났지 않을까요? 이것이 바로 아래에 이어질 내용 - 입문자를 위한 내용- 에 담긴 저의 의도입니다. 이런 방법을 취함으로써 이 라이브러리에 처음 발을 내딛는 사람은, STL과 STL.NET 모두가 제공하는 확장된 모델, 즉 매개변수화된(parameterized) 컬렉션에 기분좋게 다가갈 수 있을 것입니다.

For returning to the Source.. 역시 쉽지 않은 일이다.대략 3일이나 되는 여유가 주어졌음에도 불구하고, 이렇다 할 뭔가가 튀어나오지 않았다. 후훔..

그 당시로의 회상.. 생각은 많이 해두었다.

3월 4일.. 그 날짜에 맞춰보려고도 했었지만.. 어쩔 수 없다. 완전함을 뒤로한 체, 시간에 억지로 끼워맞추는 것은 아무런 의미없는 일이다. 의미있는 날은, 후후.. 의미는 나중에 가져다 붙이면 되는 것이다.

4월 안으로 끝맺을 수 있을지 모르겠다. 되길 기대한다.

STL.NET Primer (1/4)에서 이어지는 글입니다.

이 컬럼은 STL.NET Primer란 제목으로 MSDN에 포스팅된 글을 번역한 것입니다.

행복한 고민 : 무엇을 선택해야 하는가?

CLI 타입으로 이루어진 컬렉션을 조작하는 데 있어 Visual C++ 프로그래머가 선택 가능한 컨테이너 라이브러리에는 세 가지가 있는데, 이들 라이브러리는 세 가지의 타입 매개변수화(type parameterization) 모델에 각각 기반하여 만들어진 것입니다. 아래의 리스트는 각 모델에 해당하는 코드 샘플과 함께 이들 라이브러리를 요약한 것입니다.

이 컬럼은 STL.NET Primer란 제목으로 MSDN에 포스팅된 글을 번역한 것입니다.

STL.NET Primer

스탠리 B. 립먼(Stanley B. Lippman)

아키텍트, 마이크로소프트 비주얼 C++ 팀

불켜논 상태의 환함 속에서, 켜진 컴퓨터가 내뿜는 전자파장 속에서의 밤잠..

이틀째 이런 어설픈 상태가 주는 고통 속에서 자버렸다. 순전히 F.R.T.T.Source 때문이다. 그러고도 나온 것이라고는 없다. 역시나.. 쫌만 잤다가 해야지..하는 맘은 그 때뿐이다. 그러고 나서도, 회사에서 비몽사몽 간에 있지 않았다는 것은.. 나의 뛰어난 체력 덕분인가?

오늘 역시 그 정리를 해야겠다는 모종의 압박감은 계속되었지만.. 역시나 머리에서 뭔가 튀어나올 기세라고는 느껴지지 않는다. 이럴 때는 별 수 없다. 그냥 화끈하게 포기하고, 화끈하게 자버리는 수 밖에.

..

요즘 C++의 virtual 메카니즘에 빠져서 산다. virtual.. 그리 오랜시간 보아왔는데도, 여전히 어렵다.. 다음은 오늘 알아낸 것들.

1. RTTI(Run-Time Type Identification), 실행 중에 기반(base) 클래스 타입 포인터의 실체를 밝혀내는데 쓰이는 typeid 연산자. 그 기반 타입의 포인터가 다형성을 지닌 클래스(polymophic class), 즉 "virtual 함수가 있는 클래스"가 아니면 아무짝에도 쓸모가 없다. "typeid(기반 타입의 포인터)" 해보았자, 보이는 그대로 그 기반 타입임만을 알려줄 뿐, 실제 담겨있는 타입, 즉 그 기반 타입의 포인터로부터 파생된 타입(derived type)에 대해서는 알려주는 바가 없다.

2. dynamic_cast 연산자는 반드시 polymophic class에 사용해야 한다. polymophic class가 아닌 클래스에 사용할 경우에는 컴파일 오류(Visual C++의 경우, C2683 컴파일 오류 - dynamic_cast : 'type' is not a polymorphic type.)를 낸다. (이 때는 static_cast로 대체하여 사용하면 되더라..)

3. 기반 클래스 타입의 포인터로 자식 클래스 객체를 delete 연산자로써 소멸시킬 경우, 역시나 기반 클래스가 polymophic class가 아니면 기반 클래스 부위만 소멸될 뿐, 파생 클래스 부위는 소멸되지 않는다.

   다음은 예제 코드다.

   복사

   #include <typeinfo>
   #include <iostream>
   
   using namespace std;
   
   class base
   {
   public:
       base() { cout << "base contructed." << endl; }
       virtual ~base() { cout << "base destructed." << endl; }
   };
   
   class derived : public base
   {
   public:
       derived() { cout << "derived contructed." << endl; }
       ~derived() { cout << "derived destructed." << endl; }
   };
   
   int main()
   {
       derived* pD = new derived;
   
       base* pB = pD;
       derived* pD1 = dynamic_cast<derived*>(pB);
   
       if( typeid(*pB) == typeid(derived) )
           cout << "OK!" << endl;
       else
           cout << "No!" << endl;
   
       delete pB;
   }
   

   C++

   다음은 출력 결과.

   복사

   base constructed.
   derived constructed.
   OK!
   derived destructed.
   base destructed.
   

   C++

   위 예제 코드 중, base 클래스의 소멸자에 virtual이 없다면,

   1. dynamic_cast가 담긴 문장에서 c2683 컴파일 오류가 난다.
   2. 위 dynamic_cast가 담긴 문장을 제거한다고 해도,

   출력 결과는 OK!가 아닌 No!이며,

   1. 마지막 delete 연산에서는 생성된 derived 객체의 base 부위만이 소멸되고 derived만의 고유 부위는 그대로 남아, memory leak이 발생한다.

우파니샤드의 위대한 무기를 활로 삼고

명상으로 날카롭게 간 화살을 그 위에 걸어

'그것'의 본질로 향하는 사유로써 잡아당기어

벗이여, 표적인 그 불멸을 꿰뚫어라.

뚱딴지 같은 포스팅 하나.. 작년 3월 30일짜 일기에 썼던 글이다. 출처가 어딘지는 모르겠다.

통찰(Insight): 생활체가 자기를 둘러싼 내적, 외적 전체 구조를 새로운 시점에서 파악하는 일

문제 해결이나 학습의 한 원리이다. 시행착오와 대비되며, 게슈탈트 심리학자들이 학습의 기본적인 행동 형식으로서 강조한다.

N. 쾰러는, 길을 돌아가지 않으면 철망 넘어로 보이는 먹이를 얻을 수 없는 상황에서 굶긴 개를 이용하여 실험하였다. 개는 먹이를 보고, 한 순간 멍한 자세로 있다가 곧 행동을 바꾸어 먹이를 얻었다. 이와 같은 통찰은 도구의 발견, 사용, 제작 과정에서도 흔히 볼 수 있다.

라는 생각을 갖고 글을 쓰려했더니만, 두어 시간이 지나 이빨까지 딱고 나니깐 이미 술기운은 거반 다 사라진듯 싶다. "아, 아쉽다~"라 자연스럽게 자판에 손이 올라갔지만, 헐헐.. 암만 봐도 이 회사다니면서 술기운에 블로깅을 할 기회는 무진장 많을 것 같다. 이 회사의 멤버들.. 술 엄청 좋아한다.

첫 날의 느낌이 좋다. 오늘 하루 종일 미소가 계속 머물러 있었다. 오랜시간에 걸친 '백수'의 신분에서 탈출했다는 것..오랜시간 함께 지낼 사람들의 첫 느낌이 좋았다는 것..그리고 그러한 기분에 계속해서 취하고 싶다는 마음..이런 것이 짬뽕되어 나타난 현상이다. 어떤 느낌 하나에 계속하여 머무는 것.. 머물고자 하는 것.. 이거 위험한 태도인데..후훔. 하지만 자연스리 그렇게 흘러가는데, 굳이 그 판, 그 느낌을 깨버리는 것도 그다지 괜찮은 태도는 아니라고 생각해보니...

이제는 "어쨌건간에 흘러가는" 인생, 그 굴곡많던 인생은 좀 끝냈으면 좋겠다. 뭐, 그 것이 오로지 내 뜻대로만 이루어지는 것이라고는 생각하지 않지만, 적어도 중간에 수식어가 하나 더 붙어, "어쨌건간에 안정적으로 흘러가는" 인생으로 조류를 달리 탔으면 하는 바램이다. 그리고 그리 되리라 예상한다.

여하간 오늘 하루, 매우 행복했다(내 입에서 '행복'이란 말이 자연스럽게 나오다니..지난 과거를 생각해보면 엄청난 발전이다).

에릭 레이몬드의 논문 '성당과 시장'에 있던 문구를 발견했다.

OPEN이란 개념.

그 문구를 쓰던 시점은 OPEN이란 개념에 가장 심취했던 때이다. 그리고 어느새 그 개념은 내 행동 방향성의 주요 기준이 되어버렸고..사실, 이 블로깅을 한다는 것 자체도 '나 자신을 드러낸다.', '나를 OPEN한다.'라는 방향성 아래에 이루어지는 것이니. 또한 그 전에는 OPEN 정신의 또다른 화신인 토발즈의 'Just for Fun'을 읽었더니만, 그 제목 문구 역시 내 행동 방향성의 기준이 되어버렸고. 이즈음 되니깐, 가끔은 내가 Linux 개발자가 아니라 Windows 개발자라는 것이 이상스럽게 느껴지기도 한다.

예전에 쓰던 일기장에는 '성당과 시장'에서 실험 소재로 삼았던 소프트웨어(fetchmail)를 '나'로 대치시켜 분석했기 때문에, 그 논문에 담긴 훌륭한 문구들이 많이 적혀있다. 하지만 여기에는 하나 밖에 없기에, 그냥 이 것만 적어본다.

그 당시의 '느낌'을 쓰지 못하고, '생각'밖에 쓸 수 없다는 데에 아쉬움을 느낀다. 그만큼이나 그 당시의 현실을 그대로 바라보고 느끼지 못했다는 말이 될 수도 있겠다. 그럼 내가 그 때에 보고 느낀 것은..내 생각이 만들어 놓은 환상?...무언가에 홀림?

한편으로 보면, 그간 단체에서 떨어져나와 홀로였던 시간이 많아서 그랬던 것 같기도 하다. 그래서 그 짧은 시간 내에서 적응을 하지 못했다는 것이 될 수 있겠고. '그럴 수도 있는 것이지..'라고 넘어가서도 안되겠지만, 이 부분을 '현재 내게 붙어있는 안좋은 품성'이라 정의하여, 이를 떼내려고 안간힘을 쓰는 것도 부질없는 짓이라 생각한다. 무엇보다도, 그 정의가 올바르게 이루어진 것인지부터가 너무나도 불확실하지 않은가.

여하간, 내가 기분이 안좋아질 요소가 없었음에도 불구하고, 또한 있다 하더라도, 그 요소가 나를 내가 '환상'이라고 칭하는 그러한 묘한 상태로 끌어냈다는 것 자체가 내게는 불만이다. 그 것은 분명 내게 '약함'. '마음의 빈틈'이 있기 때문에 생긴 무엇이 확실하기 때문이다. 그 요소에, 나 자신의 '약함'에 내가 진 것이기 때문이다.

이중적 구도..왜 나는 그 상황에서의 나의 느낌을 적기가 힘든 것일까? 그럼 위의 글은 느낌이 아니면 무엇? '생각'...그럼 이 '생각'의 정체는 무엇? 느낌은 단지, 기분이 썩 좋지는 않았다...라고 밖에 쓰기가 힘들다. 아니다. 느낌이 아닌 내가 쓰고 싶은데 쓰지 못하는 그것은 '그 당시 나의 상태'이다. 그리고 내 시각, 느낌을 통해 전후 상황이 어떻게 돌아갔는지를 서술하는 것이다. 상황에 대한 정의? (아..그 당시의 느낌은 잃고, 그 대신 '언어' 안으로 점점 빨려들어가고 있다...'언어'가 만들어낸 정밀도가 매우 떨어지는, 때론 왜곡까지 해버리는 느낌의 복사본..환상..)

후훔..오늘도 역시, 전화는 오지 않더라.

거참, 그 때는 언제일까.
이 기둘림, 이 도 닦는 시간은 언제나 되야 끝나게 될까?
도대체 얼마나 더 많은 정성을 쏟아야 꽃은 피게되는 것일까.

설마하니 그날이 안오지는 않겠지.
설마..Never, ever. 분명 그럴리는 없을거야.

아주 자연스리 머릿속에서 "Everything's gonna be alright"이 울려퍼진다. 뭐, 딱히 좋아하던 곡도 아니었고, 누가 불렀는지도 몰랐는데, 요런 시점에 머릿속에서 뱅뱅거리는 것을 보면, 나름대로 좋은 노래라 생각해야 할 것같다. 찾아보니 sweetbox란 그룹의 곡인데(그룹인지, 여자 한명인지도 잘 모르겠다. 그래도 더 찾아볼 맘은 안난다), 언제부터인지는 가물하지만, 길거리 다니다보면 아주 지겹게 들려오던 곡이다. 그 말 한마디는 참 좋다. "모든 일은 잘될거야".

본 글은 MSDN에 올라온 "C++: The Most Powerful Language for .NET Framework Programming"의 번역문입니다.

Written by Kenny Kerr

요점

: Visual C++ 2005에서 새로이 소개되는 C++/CLI 언어의 설계와 원리에 대해 탐구해봅니다. .NET 프로그래밍을 위한 가장 강력한 언어 - C++/CLI - 를 이용하여, 파워풀한 .NET 애플리케이션을 만드는 데에 이 칼럼 내용을 도움되길 바래용~

C++/CLI: .NET 프레임워크 프로그래밍을 위한 가장 강력한 언어(1/2)에서 이어지는 글입니다.

본 글은 MSDN에 올라온 "C++: The Most Powerful Language for .NET Framework Programming"의 번역문입니다.

타입 되돌아보기

박싱(boxing)에 대해 썰을 풀기 전에, 값 타입과 참조 타입을 왜 구분하는지 되짚어보는 곳도 괜찮을 거야.

전세계 또다시 4년의 암흑기에 돌입!

멍청한 케리..생긴것도 멍청하더니만, 막판까지 멍청한 짓거리를...

끝까지, 대법원 갈 때까지 물고늘어졌어야 할 일을...어허 이 사태를 우짜할꼬~!

특히 우리나라, 현대사에 있어 최대 위기에 봉착.

MFC를 쓰며 언제나 "저게 뭐야?"하고 지나쳐왔던 RUNTIME_CLASS, DECLARE_DYNAMIC등의 매크로. 어디에, 왜, 언제쓰는지도 모른 채 그냥 지나쳐왔던 그 내용들..이것들이 실행 시 인스턴스의 실제 타입을 알아내는 데 이용하는 MFC의 메카니즘이라는 것을 이제야 알게되었다. 그것도 MFC가 아니라, C++을 다시 보면서.

RTTI(Run-Time Type Identification 혹은 Run-Time Type Information)

은 C++에서 기본적으로 지원한다. 근디, MFC에서는 C++이 지원하는 놈들을 안쓰고 위의 매크로 등을 통해 독자적으로 이 기능을 지원하는데, 왜 그런지는 낭중에 알아보기로 해야겠다. (새로 배우기도 빡신데, 찾기까지는 넘 힘들다.) Visual C++에서는 프로젝트 Setting 항목에서 C++ Language 탭의 "Enable RTTI"를 활성화해야 한다.

dynamic_cast 연산자

보기도 쉽지 않고, 한번도 사용 안해봤던 C++의 여러 캐스트 연산자들. 언제나 C 스타일의 캐스트 연산자만 써왔는데, 당장 알아야 하는 것은 아니지만, 내친김에 한번 훌터보고 가는 것이 좋을거 같다. 기왕 사용하는 거, 좀 제대로 알고 사용하는 것이 좋지 않겠나..으흐.. 그놈의 면접 질문 파장, 정말 오래도 간다..

캐스트(cast)란 명시적 변환(explicit conversion)을 의미한다. C++의 캐스트 연산자는 4가지인데, 이들은 C++의 타입 체킹 기능을 약화 혹은 마비시키기 때문에, 조심해서 사용해야 할 것이다.

캐스트를 이용하는 경우

• void* 포인터 형태의 인스턴스에 명시적으로 타입을 지정해야 할 때.

• 일반적 표준 변환의 동작을 오버라이드해야 할 경우.

  복사

  double dval;
  int ival;
  
  ival += dval; //여기서 ival은 double로 승격되었다가, 덧셈이후, 대입 과정에서 int로 격하된다.
  ival += static_cast< int > ( dval ); //승격 과정이 없어진다.
  

  C++

• 한번 이상의 변환이 일어나는 경우의 상황에서 모호성을 없애기 위해서..(나도 몬소린지 모르겠다..별로 안중요한거 같아..넘어간다..으흐..)

이 내용 역시 면접 당시의 질문에서 버벅거린 사항들. 아...C++을 맞이한지 벌써 5년째 접어드는데, 이런 기본으로 아직까지도 버벅거리는 것을 보면, 거참...

virtual 키워드에 대해서

다형성(polymorphism)이란?

한 개의 기반 클래스(Base Class)에 대한 포인터나 레퍼런스를 통해, 한 개 이상의 파생(Derived) 타입을 조작할 수 있는 능력

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon) 에 담긴 내용입니다.

• 뮤텍스(Mutex) 커널 객체: 사용 카운트, 쓰래드 ID, 재귀 카운트(현재 뮤텍스를 소유하는 쓰래드가 몇번 소유하고 있는지를 나타냄)로 구성된다. 쓰래드로 하여금 단일 리소스에 독점적으로(mutualexclusive) 접근할 수 있도록 보장한다. 그러므로 사용자 모드 객체인 크리티컬 섹션(critical section)과 동일하게 동작하더라.. 하지만 뮤텍스는 커널 객체이므로, 크리티컬 섹션보다 느리다. 이 말은 단일 뮤텍스에 서로 다른 프로세스의 쓰래드가 접근할 수 있고, 리소스를 얻기위한 쓰래드 대기 시간 값을 지정할 수 있다는 뜻이다. 가장 많이 사용되는 커널 객체이기도 하며, 보통 여러 쓰래드에서 접근하는 메모리 블록을 보호하는 데 사용된다.

• 뮤텍스가 따르는 규칙

  • 쓰래드 ID가 0이면, 뮤텍스는 어떤 쓰래드에도 소유된 것이 아니며, 신호 상태이다.쓰래드 ID가 0이 아니면, 어떤 쓰래드가 소유하고 있는 것이며, 비신호 상태이다.
  • 다른 커널 객체와는 달리, 일반 규칙에 반하는 것을 허용하는 특별한 코드가 OS 내에 존재한다.뮤텍스 vs 크리티컬 섹션

  성능

  • 뮤텍스: 느리다 / 크리티컬 섹션: 빠르다

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon) 에 담긴 내용입니다.

• 이벤트(Event) 커널 객체: 커널 객체 중 가장 원시적인 객체. 사용 카운트(usage count), 자동 리셋(auto reset)-수동 리셋(manual reset) 상태 여부를 구분하는 불 값, 신호-비신호 상태 여부를 구분하는 불 값으로 구성되더라..
• 수동 리셋 이벤트: 신호 상태가 되었을 때, 이벤트를 기다리던 모든 쓰래드가 스케쥴 가능 상태가 되더라..
• 자동 리셋 이벤트: 신호 상태가 되었을 때, 이벤트를 기다리던 쓰래드 중 하나만 스케쥴 가능 상태가 되더라..
• 용도: 쓰래드 하나가 초기 작업을 한 이후에 다른 쓰래드(들)로 하여금 나머지 작업을 하도록 신호를 보낼 경우에 사용하더라...

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon) 에 담긴 내용입니다.

• 세마포어(semaphore) 커널 객체: 리소스 카운팅에 이용된다. 사용 카운트 외에도 두 개의 부호없는 32비트 값(최대 리소스 카운트, 현재 리소스 카운트)을 갖는다. 최대 리소스 카운트는 세마포어가 제어할 수 있는 최대 리소스 갯수를 나타내고, 현재 리소스 카운트는 현재 사용 가능한 리소스의 갯수를 나타낸다.

• 세마포어가 따르는 규칙

  • 현재 리소스 카운트가 0보다 크면, 세마포어는 신호 상태에 있다.
  • 현재 리소스 카운트가 0이면, 세마포어는 비신호 상태에 있다.
  • 시스템은 세마포어의 현재 리소스 카운트가 음수가 되는 것을 허용하지 않는다.
  • 현재 리소스 카운트는 최대 리소스 카운트보다 클 수 없다.

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon) 에 담긴 내용입니다.

• 대기가능 타이머(waitable timer) 커널 객체: 특정 시간에 혹은 일정 간격으로 그 자신에게 신호를 보낸다. 주로 특정 시간에 어떤 연산을 수행해야할 때에 사용되더라..

  • 대기가능 타이머는 언제나 비신호 상태로 생성되기 때문에, 신호 상태로 만들려면 반드시 SetWaitableTimer()를 호출하여, 타이머가 신호 상태로 변경될 시점을 알려야 하더라..

  (SetTimer()로 설정하는) 사용자 타이머와 대기가능 타이머의 비교

  • 사용자 타이머: 추가적인 UI 인프라를 요구하기 때문에, 리소스 사용량이 많다. 또한 사용자 타이머가 발생시키는 WM_TIMER는 가장 우선순위가 낮은 메시지기 때문에 울림 시간이 정확하지 않은 경우가 많다. 하지만 UI관련 타이머 이벤트를 수행한다면 사용하기가 쉽다. (대기가능 타이머는 커널 객체뿐만 아니라 메시지도 기다려야 한다. -> MsgWaitForMultipleObjects() 이용)
  • 대기가능 타이머: 커널 객체이기 때문에, 여러 쓰래드에서 공유될 수 있으며, 안전하고 정확하다.이벤트(Event) 커널 객체: 커널 객체 중 가장 원시적인 객체. 사용 카운트(usage count), 자동 리셋(auto reset)-수동 리셋(manual reset) 상태 여부를 구분하는 불 값, 신호-비신호 상태 여부를 구분하는 불 값으로 구성되더라..//이벤트 생성

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon) 에 담긴 내용입니다.

• 커널 객체(kernel object)는 사용자 모드(user mode)의 메카니즘보다 훨씬 더 유용하더라..

  • 사실 사용자 모드의 것보다 딸리는 점이라고는 성능밖에 없더라..(커널 객체를 다루는 함수는 반드시 사용자 모드에서 커널 모드로 전이(transition)하게 된다. 이 전이에서 성능 저하가 일어난다.)

  쓰래드 동기화에서 거의 대부분의 커널 객체는 신호 상태(signaled state)가 아니면 비신호 상태(unsignaled state)에 놓이게 되더라..

  쓰래드 동기화를 위해 윈도우즈가 제공하는 커널 객체 : 이벤트(event), 대기가능 타이머(waitable timer), 세마포어(semaphore), 뮤텍스(mutex)

행정 타운, 행정 특별시 건설이라...

서울에서 큼직한 권력 기관은 옮겨야겠고, 정부의 힘으로 옮길 수 있는 기관은 사립 기관이 아닌 국가 기관이겠고, 국가 기관을 옮기자니 '수도'라는 명칭이 헌법에 걸리고..
그럼 '수도'라는 명칭을 빼내오지 않아도 옮길 수 있는 기관만 옮기면, 헌법에도 안걸리고, 실리도 찾는 일석 이조가 되겠다.

오늘 수도 이전 특별법 위헌 판결에 대한 TV 토론을 보니, 헌재에서 '수도' 명칭과 직접적으로 연결된 국가 기관은 청와대와 국회뿐이란다. 그나마 국회도 연결되는지는 논란의 대상이고...

그럼 청와대만 빼놓고, 아니 백번 양보해서 국회까지 빼놓은 다음, 그 외의 국가 기관을 옮기면 만사 해결되는 것이 아니겠는가..벌써 그 대안으로 행정타운, 행정 특별시 등의 대안책이 나오고 있다.

하긴, 그렇게 해도 크게 문제될 것은 없어 보인다. 행정 관계부처와 청와대는 서로 떼어놓기 힘든 대상이라고는 하지만, 뭐 국가 기관이 좀 많은가? 이 참에 옮기는 대상에서 제외되었던 사법부 먼저. 딴지 걸던 헌재부터 옮겨버리고, 대법원도 덩달아 옮기고, 권력에서 독립했다던 대검찰청도 옮겨버리고..과천이나 충청이나 서울까지의 거리는 별반 차이 없는거 같은데, 종합청사도 옮겨버리고...옮길거 정말 많다. 그래도~ '수도'는 서울~!

만약 요 모양새로 가게된다면, 입에 거품물면서 이전 반대해오던 서울의 뱃살 기름낀 사람덜...정말로 열받을만 하겠다. 머리 굴리다가 뒤통수 한대 맞는거지 뭐. 그넘의 집값...기득권이 뭔지...

제프리 릭터의 Programming Applications for Microsoft Windows. (4th Editon)에 담긴 내용입니다.

주의 사항

실행 쓰래드는 비선점이라고 가정함. (허나..대부분의 고 정밀도의 실행 시간을 원하는 코드는 수명이 짧도록 작성된다.)