Things...

Windows 용 응용프로그램을 만들 경우에, console 프로그램이 아닌경우에는 실행시에 window의 초기 위치와 크기를 정해주고 싶은 경우가 있을것이다. 나는 몇일전에 있었다~

쉽게 할 수 있는 방법을 정리하고자 한다.

우선 코드를 논하기에 앞서서 내가 사용한 방법을 간략히 설명하자면, MainFrame class에 WM_SHOWWINDOW message에 대한 event handler를 만들어주어 그 안에서 WINDOWPLACEMENT structure를 이용했다.


WINDOWPLACEMENT structure에 대한 구체적인 설명은 MSDN을 참고하시기 바라며...
Visual C++ 6.0 MFC에서의 WINDOWPLACEMENT structure documentation (http://msdn2.microsoft.com/en-us/library/aa253040(VS.60).aspx)

추가적으로 창의 최대 크기 및 최소 크기 지정하는 방법까지 설명하겠다...
Window의 최대 크기 및 최소 크기에 대한 정보를 지정하는 방법은 WM_GETMINMAXINFO message에 대한 event handler를 만들어주는 것이다. 아마도 창의 사이즈가 변경될때 OnGetMinMaxInfo를 불러 창 크기의 최대값과 최소값에 대한 정보를 읽어와 동작에 대한 constraint가 주어지는것 같다...
하지만 이것은 내 생각일뿐... 진실은 저 너머에...ㅎㅎㅎ


GetSystemMetrics(SM_CXSCREEN) 및 GetSystemMetrics(SM_CYSCREEN)은 현재 설정된 해상도의 가로폭과 세로폭에 대한 정보를 return해준다. 이 정보를 사용하면 해상도에 따라 적절한 창의 크기 및 위치를 설정해 줄 수 있다. 또한 나의 경우에는 OnGetMinMaxInfo에서 설정해준 창의 최소 크기의 값을 사용하여 창의 위치를 정해줄때 화면 한가운데에 놓이도록 숫자를 입력하였다. 그러기 위한 숫자들은 수학을 잘하는 당신들이 알아서 해보세요~

내 블로그에 AdSense를 달았다.
수입을 올리자는 기대가 전혀 없는건 아니지만, 뭐 사실 수입이 얼마나 올라가겠나???

몇일전에 결혼과 연애에 관한 글을 써서 그런지 연애 정보회사, 결혼 예단준비 광고 같은것이 나온다...
ㅡ.ㅡ;

AdSense를 달기는 했지만 달기만 했지 뭐가 뭔지는 아직 잘 모르겠다...
아무튼 두고 보겠다... 수입을 얼마나 올릴 수 있을지...
^^

Until I started to work, there wasn't much chance for me to look at how real world code really works. In other words, I programmed in my own fashion and I only had to use my own codes. However, I had to write MFC applications as I started to work. I realized that many of the methods for MFC were written and used very differently from how I used to write methods.

When passing by parameter to a function in an in/out fashion, I usually use the following function signature.


But, the functions or methods written for MFC usually use the following signature for in/out parameters.


So, what's the difference?
Here is my explanation according to my opinion. The function signature that I usually use for in/out parameters explicitly shows that it is passed by reference like the Foo case. I say "explicit" because you can know the parameter is passed by reference just by looking at the function signature. However, in the Bar case, the parameter is passed by reference implicitly by passing a pointer type. Even though they both have the same affect on the parameter, the Bar case does not necessarily mean that the parameter is passed by reference. They both have the same affect on the parameter, but keep in mind that all parameters are passed by value in C++. Therefore, passing a parameter by reference only works by passing an address of a variable (or an object). For that reason, I am saying that passing a pointer to a function does not necessarily mean that you want the parameter to work in an in/out manner.

Sometimes you simply want to pass a pointer. In that case you should limit the side affect on the parameter by using the const keyword. So, if that is the case function Bar should be written

void Bar(const int* const a)

but let's don't discuss that here.

On the other hand, the situation looks slightly different in the client code like the following.


By looking at the code, you won't be able to tell whether b is passed by value or reference for Foo. Since the parameter passing scheme of Foo is indeterminable in the client code, I personally think that using a pointer type for in/out parameter is better to use than passing a parameter to a function by reference explicitly in the function signature (in other words Bar is better than Foo). Using the '&' to declare the parameter to be passed by reference in the function signature makes the intention clear in the function signature itself only. But by using a pointer type parameter, you can at least guess that the parameter is in/out by looking at the function signature and maybe it becomes clearer when you look at how it is used the client code. Besides, as I mentioned in the colored quoted section above, if you want to pass a pointer to the function and avoid side affects, you should use the const keyword.

So, my conclusion...
For code readability issues, I personally think that functions that require in/out parameters should be written in the Bar way rather than the Foo way.

아직 내일이 되려면 2시간 정도의 시간이 남았는데 오늘 내 블로그에 방문자 카운터가 195를 기록했다...
평소에 많아야 40명인데... 오늘따라 왜 이리 많은 사람이 방문했을가?

어제 올린 circular dependency에 대한 글은 많은 사람들이 관심이 없을것 같은데...
그렇다면 소개팅, 연애, 결혼에 관해서 내 생각을 쓰고 여자들에게 생각을 물어본 글 때문인것 같은데...
그건 어제 올린거고, 답글은 아무것도 없다 ㅡ.ㅡ;

Bot들이 또 판을 치나???
방문자 카운터에 Bot들은 카운트 하지 않도록 plug-in 설정도 했는데... 음...

뭔가 이상하다...

It's been a while since I have learned C++ from school. The last time I heard about circular dependency in C++ was from my sophomore year in college. Yesterday, I was having trouble making circular dependency to get working. I decided to post about how I solved the problems I had considering that circular dependency isn't a situation you encounter very often. I usually get rusty on things I don't do often. Hopefully, many people are like me and some may benefit from this post sometime later.


While at work designing an application, I encountered a situation where two classes had attributes of their own referring to another class in the following manner.
I recognized that this resulted in a circular dependency and included a forward declaration in the header file of each class for the class that it was referring to. So the header file for each class resulted in the following.
 

// A.h
class B;   // forward declaration for class B
class A
{
    private:
       B* pB
    public:
       ...
};

// B.h
class A;    // forward declaration for class A
class B
{
    private:
       A a;
    public:
       ...
};

However, I got a compile error indicating that class A and B were not defined. It was weird at first because I thought I got my circular dependency problem solved. I had no idea how to get around the compile error. My solution to this was to create another class to use it as a mediator for the establishing an associative relationship between class A and B. My new design was like the following.
I was stupid enough to think that this new design will avoid the circular dependency relationship. But after another build of my application, I figured that this also results in a circular dependency. If you look carefully at the #include statements in each header file for class A, B, and C,
    - A.h includes C.h
    - C.h includes B.h
    - B.h includes A.h
, but then B must compile A.cpp and A cannot be compiled because C and B has not been compiled. Therefore, class A is not defined and the circular dependency prevents the code to be compiled in spite of the forward declarations.

At this point, I realized that class A does not require C.cpp to be compiled. This is because that  class A refers to class C with a pointer. As you all know, pointers are usually a 4 byte (32 bit) integer and as long as the type of the pointer is specified, the code compiles. From what I have just realized, I decided to change my design like the following.
I could have gotten rid of class C but I kept it for another good reason (design issue in my application). As I changed all my inter class relationship into association, the code compiled as I expected and also worked fine.


The point I would like to make here is that it is important that you know that circular dependency only works only when classes are associated with each other based on pointers.

 Was this so obvious?

내나이 27... 슬슬 결혼을 생각할 나이가 되어버렸다...
지금이라도 슬슬 결혼이라는 것을 염두해 두지 않고 살았다가는 대학원시절에 보게된 30을 훌쩍 넘은 결혼을 하지 못한 형과 누나들 처럼 될것 같다...

다른 사람들은 결혼을 어떻게 하는지 모르겠다...
평생을 같이 할 운명적인 만남을 어떻게 만들어가는지...
과연 결혼하는 사람과는 진정 사랑해서 결혼하게 되는건지...

과연 결혼하는 사람들 중에 진짜로 사랑해서 결혼하는 사람은 몇이나 될까?
나도 솔직히 우리 부모님이 진짜로 사랑해서 결혼했는지 의심스럽고 궁금하다...
우리 가족은 어느가족 못지 않게 화목하게 지내고 엄마와 아빠의 관계에 문제가 있는것은 아니지만,
엄마아 와빠가 만나게 된 이야기를 들어보면 딱히 서로 없으면 죽을것 같을 정도로 사랑해서 결혼했다는 느낌을 못받는다...

오랜 연애기간 끝에 결혼하는 사람들 아니면 대부분 그냥 나이 어느정도 꽉차면 선봐서 그나마 조건이 괜찮은 사람을 골라 결혼하는것이 요즘 풍속인것 같다...

나는 여기서 여자들에게 물어보고 싶다...
당신들은 어떤 사람을 만나 어떻게 결혼하고 싶나요?
여자들에 대해서 잘 모르지만,
좋은사람 만나서 낭만적인 사랑을 하다가 결혼하고 싶은게 대충의 줄거리 아닌가?

하지만 얼마나 많은 비중의 여자들이 자신의 꿈대로 이루어질까?
그리고 남자들은 어떻게 결혼하고 싶어할까?
내가 모든 남자를 대변할 수 없겠지만, 대부분의 남자도 선봐서 결혼하기보다는 연애를 해서 결혼하고 싶을것이다.

연애를 하기 위해서는 어떻게는 만남이 있어야 하고 만남이 있기 위해서는 선을 보거나 소개팅을 해보는 방법이 있을것이다.
근본적으로 선이나 소개팅은 이성은 만나본다는 점에서는 똑같은 것이라고 본다.
다만 차이점이라면 우리는 소개팅은 어린 사람들이 하는것이고 선은 나이든 사람(나이가 꽉찬 사람)들이 하는것이라고 인식하고 있다 . 왜?
인생에 있어서 어떤 시점을 지나게 되면 이성을 만날때 어느새 자연스럽게 결혼상대를 찾기 위한 하나의 전제 조건이 깔리게 된다.
내가 생각하는 선과 소개팅의 차이라면 그것이라 하겠다...
결혼상대를 찾겠다는 의도가 커지면 커질수록 선에 가까워지는 것이다...
좋은 사람을 만나기 위해서 다양한 사람을 만나보는것은 필요하기도 하고 나쁘지 않다고 생각하지만,
단지 결혼상대 탐색을 위해서 여러 이성을 만나는것은 왠지 나에게 부자연스럽다...

나는 최근에 좋아하는 사람으로부터 이별을 통보받고 더 좋은 여자를 만나라는 얘기까지 들었다.
마침 친구가 이소식을 듣고 소개팅을 주선해주겠다고 해서 오랜 고민끝에 소개팅이라는 것을 처음 해봤다.
마음에 두고 있었던 사람을 소개 받은것도 아니고, 그냥 친구를 통해 소개받은 정말 Random한 사람이었다...
설레임이라는 것은 내 마음 어떤 구석에도 없었다...
이성으로 다가오기 보다는 나에겐 그냥 또 하나의 사람이었다...
다른사람들도 이런식으로 이성을 만나기 위해 소개팅을 하나 궁금할 정도로 아무런 감흥이 없었다...
상대방은 어떤 기대를 가지고 나왔는지 알 수조차 없었고, 물어보기에는 조금 부담스러웠고...
정말 어정쩡한 인간 관계만 늘어나게 될것 같다는 생각이 들었다...
그러다보니 감성적으로 사고하기 보다는 이성적으로밖에 사고할 수 밖에 없었다...

아마도 자연스럽게 만나서 자연스럽게 호감을 가지게 되고 연애를 하지 않는 이상 조건부터 따져들고 그만큼 이성교제는 계산적으로 되지 않나 싶다...
이런 계산적인 사고는 남자나 여자나 결혼적령기가 되었지만 결혼상대를 못찾았을때 최고조에 이른다고 본다.
서로 아무리 계산적으로 만나서 서로의 조건이 충족되더라도, 과연 오래 지속될 수 있을까?

결혼적령기를 훌쩍 넘기게 되면 아마도 그나마 괜찮은 사람이 나타나면 나는 내 자신에게 내 운명의 상대가 나타났다고 최면을 걸것 같다...
분명히 남녀를 불문하고 실제로 그러는 사람도 있을것이다...
이런 경우 역시 결혼이 오래 지속될 수 있을까?

나는 굉장히 이기적인 사람이다.
내가 우유부단하기도 하지만 원하고 원치 않는것이 뚜렷한 경우도 있다.
배우자를 선택하는데 있어서만큼은 정말로 내가 원하는 사람을 얻지 못하면 나는 불행해질것이다.

갑자기 이런 생각을 문득 많이 하게 된 이유는?
아까도 말했듯이 내나이 27... 어떻게 보면 결혼하기에는 약간 이른 나이...
하지만 그렇다고 결혼을 전혀 염두하지 않고서 살다가는 아마도 노총각이 될것이 뻔하다...
하지만 위와 같은 생각을 쭈욱 해봤을때... 도무지 어떻게 결혼을 해야 할지 감이 잡히지 않는다...

지금 결혼 적령기에 다다른 여자들에 한해서 물어봅니다...
이런 얘기를 듣고도 여자인 당신은 선이나 소개팅을 하고 싶습니까?
그냥 당신을 충분히 많이 사랑해주는 사람이 있었다면 그냥 계속 잘 지낼껄 그랬다고 후회하신적 없습니까?

This year's Must buy 항목 중에 하나로 Mac이 정해졌다...
Yay~ 그런데 때마침 내 데스크탑이 죽어버렸다...

그래서 이렇게 빨리 Mac을 장만할 계획은 없었는데, 질러버리기로 했다... 하지만... 무엇을 지르느냐(?)가 문제다...일단 사양을 떠나서 MacBook을 사느냐 Mac Mini를 사느냐가 문제다...

사실은 MacBook Air도 고려해봤지만 너무 비싸다... 이왕 MacBook Air를 구입할거면 SSD가 들어간 \3,500,000짜리를 사고 싶었다... MacBook Pro도 고려를 해봤지만 비싸기도 하고 Mac Book과 Mac Air에 비해 휴대성이 떨어진다고 판단해서 나에게 큰 메리트가 없다고 생각했다.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
휴대성까지 고려해서 구입한 현재의 14인치 랩탑도 막상 들고다녀보니 크고 무겁게 느껴진다
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
iMac도 고려를 해봤지만, 이미 20인치짜리 모니터를 산 관계로 공간도 없고 그래서 iMac은 제외했다...


1. Mac Book을 선택하고픈 이유...

Mac Mini를 사고 싶기는 한데, 집에서만 쓸 수 있다는 단점이 크게 마음에 걸린다...
Mac Book을 사서 들고 다니면서 스타벅스 같은데서 뽀대나게 작업해보고 싶기도하다...

그러면 혹시 프로그래밍 하는 내 모습이 너무나 멋져서 접근하는 여자가 있으려나?
일반적인 랩탑으로는 혼자의 힘으로는 안되니까...
Mac Book의 힘을 빌어서라도 그런 경험을 해봤으면 좋겠다.
일단 프로그래밍에 흥미를 느끼고 내게 프로그래밍에 대한 조언을 해주거나,
조언을 받기를 원하는 여성이라면 일단 만나보고 싶다...

잠깐 엉뚱한 곳으로 주제가 흘렀는데, 다시 본론으로 들어가서...


2. Mac Mini를 선택하고픈 이유

2.1. 하지만 MacBook은 배터리가 내장인걸로 알고 있다...(?확실치 않다?)
그렇다면 배터리를 관리하기 힘들어질것 같다. 지금 내가 가지고 있는 IBM(Lenovo) ThinkPad는 배터리를 낀 상태에서 전원 플러그까지 꽂아놓고 많은 시간을 사용하다보니 배터리의 건강(Health)가 많이 안좋아졌다...
완충(완전 충전) 후 10분정도면 완방(완전 방전)이 된다.

2.2. 내 현재 사용하는 랩탑(위에서 언급한 IBM으로 위장한 Lenovo)과 같은 경우는 와이드 해상도를 지원하지 않는다. 그래서 내 화면을 크게 보고 싶어서 모니터에 연결해서 봐도 별 메리트가 없다. 오히려 모니터에 맞지 않은 해상도를 쓰다보니 폰트나 그림이 보기 짜증스러워진다...

그래서 결론적으로...
MacBook의 배터리 수명과 비디오 카드가 지원하는 해상도 문제를 알아보고...
다시 고민해봐야겠다...
내가 위에서 언급한 Mac Mini와 MacBook의 장단점은 판단을 내리기 너무나 벅찬 tradeoff 관계를 가지고 있다...

오늘 회사에서 저녁먹으면서(<-야근했음 암시) TV를 보고 있는데 YTN에서 하는 돌발영상 코너가 나오고 있었다. 숭례문 화재 사건을 두고 책임을 서로 떠넘기는 소방방재청 사람과 문화재청 사람과 그두 두 사람에게 날카로운 질문을 던지는 사람... 뭐였는지는 모르겠지만, 어쨌든 서로 책임을 회피하면서 화재가 발생한 시각부터 진화되기까지 벌어졌던 일들에 대해서 말하고만 있었다. 책임을 묻기 위해서 그 과정이 필요하겠지...

하지만 잠깐... 굳이 일이 어떻게 벌어졌는지 알아야만 이틀전에 벌어진 참사의 책임자가 가려지나? 물론 상황에 따라서 그럴 수 있다... 하지만 일단 1차적인 책임은 숭례문 경비를 맏은 보안업체에 있다고 생각한다. 그리고 2차적인 책임은 불을 초기에 진화하지 못한 소방청에 있다고 보고, 그 다음으로 문화재청이라고 생각한다(어디까지나 개인적인 생각이다. 다음에 할 말을 이끌어내기 위해서 꺼낸 말임). 그리고 상황에 따른 책임유무 판단이 이루어져야 생각한다.

우리나라에서는 흔히 어떤 사건이 발생하면 딱히 책임질 사람이 없다는 것을 알 수 있다. 사건의 연루된 당사자들끼리 서로 책임을 지지 않으려고 하는 것은 물론이고, 따지고 보면 다 잘못했기 때문이다. 한사람의 과실로 인한 사건이었다면 오히려 사태 수습은 쉽게 된다. 하지만 대부분의 경우에는 한 사람이 아닌 여러명이 과실정도에 따라 발생한 사건에 대한 책임의 정도도 다르게 지어야 한다. 하지만 과실 정도는 객관적으로 판단하기 어렵기 때문에 대부분 가장 큰 책임을 져야 하는 사람만 또는 최악의 경우에는 엉뚱한 사람이 그 대가를 치루는 경우가 허다한것 같다. 결국 우리나라는 거의 대부분의 경우에는 가장 높은 지위에 있는 사람이 타격을 제일 크게 받게 되고 조직의 말단에 있는 사람들은 이미 끝난 문제이므로 자신들의 과오를 잊고 나중에 또 다시 문제를 터뜨리곤 한다.

우리나라의 사회는 불합리한 면이 많다... 어느 사회나 마찬가지지만, 우리나라가 더더욱 그렇게 느껴지는것은 아마도 머지 않은 옛날만 하더라도 후진국이었다는 그런 인상 때문인것 같다. 그리고 따지고 보면 많은 선진국들에 비해 사회 시스템이 많이 낙후되어있는것도 사실이다.

우리나라 기업문화만 봐도 이번 숭례문 화재 사건과 같이 어떤 큰 문제에 대해서 책임을 누가 져야 하는지 불분명한 우리나라 사회의 한 단면을 볼 수 있다. 나는 엔지니어다. 내가 개발에 참여하고 있는 제품은 여러분야의 전문가들이 모여 뜻을 모아 협력하여 탄생하게 된다. 하지만 이 과정에서 정말 많은 일을 다양한 분야의 사람들이 나눠서 하기 때문에 문제가 생기지 않을 수 없다. 하지만 문제가 생기면 책임질 사람은 없다... 책임질 사람이 없으면 우리 회사와 같은 경우에는 가장 복잡한 부분을 담당하고 있는 우리 부서가 누명을 쓴다. 확실한 증거없이 우리가 책임을 져야 한다. 복잡한 부분을 담당하는 만큼 문제가 자주 발생하는 부서이기도 하지만 그렇다는 이유만으로 어떤 현상에 대해서 설명이 불가능한 부분에 대해서는 우리가 누명을 쓴다. 이런일이 더욱 많이 일어나는 이유중에 또다른 이유는 문제가 생기면 그것을 개선할 생각은 안하고 숨기기에 급급한 사람들이 많다...

우리 회사를 볼때나 우리나라의 사회를 볼때 우리의 가장 큰 문제점은 크게 세가지라고 생각한다.

첫번째는, 각자가 담당하는 업무에 대해 정확히 정의가 되어있지 않다.
두번째는, 실무자간의 커뮤니케이션이 형편없게 이루어진다.
세번째는, 문제가 발생해도 인정하지 않으려고 하고, 문제 발단의 증거물을 없앤다.

개개인 또는 부서간의 업무가 확실히 정의되어있지 않고, 개개인 서로간에 또는 타 부서간의 업무가 잘 맞아 떨어지는 경우가 없다. 그래서 개개인의 업무나 부서간의 업무영역의 경계는 참 애매모호하다... 현실이 이렇다보니 문제가 생겨도 책임질 사람은 없고, 문제 발생의 원인 분석도 하기 힘들다. 그러다 보니 연대책임으로 사건이 마무리 되고 사건이 해결됨으로써 그 문제는 우리의 기억속에 잊혀진다. 그러다보면 비슷한 문제로 또 문제가 발생하곤 한다.

이번 사건을 통해 우리 사회도 좀 변했으면 좋겠다... 아마 서로간의 업무가 정확하게 정의되어있고, 화재 사건이 발생했을때 대처 방법도 정확히 정의되어있었으면 책임자를 지목하는것은 그다지 어렵지 않았으리라 생각한다. 아마 내가 생각하는 우리나라 사회가 갖고 있는 3가지 문제점 때문에 일은 크게 벌어졌고, 그에 따라 책임자를 가리는 일도 어려워진것 같다.

한동안 내 자신의 모습을 잃고 살았다...

내 뜻과는 너무나 다르게 내 인생은 흘러가고만 있었고, 점점 무기력해지고 뭐든지 의욕이 없었다. 시간적인 여유가 없어진 탓도 있겠지만, 더 큰 이유는 목표의식이 없어져 뚜렷하게 하고 싶은 일이 없고, 사회 생활이 내가 생각했던것과 너무 달라서 많이 실망한 나머지 너무 비관적으로 살아가고 있기 때문인것 같았다.

앞으로 펼쳐질 내 인생에 대한 큰 기대감도 이젠 없고, 내게 흥미진진한 일도 일어나지 않고...
기다려지는 일도 없기에, 하루하루를 그냥 보내버린다...

출근하고 일하고 퇴근하고... 하고싶은게 있어도, 야근이 잦고 퇴근시간이 불규칙한 우리나라에서는 시간 쪼개서 취미생활을 하기가 힘들다... 다른 사람들은 역시 내가 게으르기 때문이라고 하겠지만, 내가 다니는 회사에서는 정말 눈치 안보면서 그런 생활하기는 많이 힘들다는게 나와 내 동료들의 견해다... ㅡ.ㅡ;

어쨌든... 나도 이대로 계속 살 수 없다는 생각에 조금이라도 생산적으로 살기로 마음먹었다. 그리고 친구와 대화를 하던 중에 Google에서 Android용 application을 공모를 한다는 소식을 들었다...

그래서 결정해버렸다... 당분간 Android에 매진하기로 했다...
지금 친구랑 application 개발을 위한 아이디어를 구상중이다...
핸드폰에 들어가있으면 좋을것 같은 application이 뭐가 있을까???

진정한 내 삶의 원동력이 되기를 바라면서... 열심히 하겠다고 한번 다짐해 본다...
그동안 쌓아온 프로그래밍 및 설계 능력을 마음껏 뽐내보자~

오늘 Naver를 통해서 스포츠 기사를 보고 있는데 눈에 띄는 기사 하나가 있었다...


...이게 무슨 말인가 했다...
기사를 읽어보니 이천수가 현재 소속되어있는 네덜란드의 축구 클럽 폐에노르트 로테르담의 감독이 네덜란드 국가 대표 축구팀 차기 감독으로 유력하다는 기사였다... 많은 사람들은 나와 다르게 첫 두 단어를 "이천수의 감독"이라고 무의식중에 읽었을지도 모르지만 난 분명히 "이천수 감독"으로 읽고 이해했다. 이 기사를 쓴 기자에 대한 실망감을 느꼈다...

물론 대중매체의 입장에서는 사람들의 관심을 끄는 기사를 많이 써서 독자를 되도록 많이 확보해서 광고수입을 올려야 하겠지만, 또다른 한편으로는 정보를 전달하는 입장에 서 있으므로 보다 명료하게 정보를 전달해야 한다고 생각한다.

관심을 끌기 위해서 teaser성, 또는 낚임성 제목을 다는 경우도 있지만, 위의 경우는 그런 경우와는 엄연한 차이가 있다고 생각한다... 기사를 다 읽어보기 전에는 무슨 내용인지 모르게 하는 경우와 기사 제목에서부터 독자에게 잘못된 정보를 전달될 여지가 있는 경우는 다르지 않은가?

내가 국어를 잘해서 이런것을 시시콜콜하게 따지자는것은 아니다. 난 글 쓰는 재주도 없고, 논리적으로 글을 풀어가는 능력또한 부족하다. 그것을 알기에 항상 글을 쓸때 독자의 입장에서 어떤식으로 내 생각을 전개해야 하고 전달해야 정확하게 이해할 수 있을지 고민을 많이 한다. 나 조차도 이런 고민을 많이 하면서 글을 쓰는데, 전문적으로 글을 써서 돈을 버는 사람의 입장에서 저런식으로 아무렇지도 않게 국어를 사용하는 모습을 보면 참 안타깝다. 의도적으로 저렇게 쓴것일지도 모르겠지만, 서두에서 말했듯이 저런 문장 구사는 신문기자로써 바람직하지 않다고 생각한다.

우리나라는 우리 자신의 것을 얼마나 소중하게 여기는가? 그리고 얼마나 많은 자긍심을 느끼는가? 저런 사소한 곳에서까지 나는 우리나라의 언어조차 제대로 취급받지 못하고 있다는 생각이 들었다. 바로 어제 발생한 남대분 화재 사건만 봐도 우리나라 국민은 우리나라의 문화적 자산을 소홀히 관리하는지 알 수 있다. 방화로 추정되는 화재가 정말로 방화에 의한 화재였다면 방화를 저지른 사람이나, 화재에 즉각적으로 대처하지 못한 관련 기관들을 보면 그렇지 아니한가?

언젠가부터, 아니면 우리나라는 해방의 기쁨을 맛본 순간부터 가난에서 벗어나기 위해서 당장 눈 앞에 보이는 이득을 챙기기에만 급급했고, 우리나라의 전통이나 문화는 돈보다 뒷전이었던것 같다. 그런 반면에 나이, 부, 또는 신분에 의해 생기는 계층에따라 알게 모르게 행세되어오던 권위주의와 같은 낡고 안좋은 관습은 그대로 유지되어왔다...

숭례문은 이미 불타고 무너져내렸다... 어차피 복원할것이고, 복원해야만 한다... 숭례문은 우리나라의 하나의 자존심과 같은것이라 생각된다. 이왕 복원하는 김에 우리나라 자존심도 다시 세우고, 그동안 오래도록 존속해오던 잘못된 관습과 관행을 타파하고 반듯한 대한민국으로 다시 일어섰으면 좋겠다...