Ting 이네 Software 이야기

아래 글은, 어떠한 논리적인 근거없이 작성된 개인적인 의견임을 먼저 명확히 명시합니다.

"부자 3대 못간다."라는 말이 있다. 비슷하게 회자되는 말로 "재벌 3세때 문제가 생긴다 - 3세 위기론"라고들 한다. 정말 그러한가? 잘 모르겠다. 첫 줄에 미리 언급한 바와 같이 어떠한 관련 근거도 찾아본 바 없다. 하지만, 그런 말들이 많이 회자 되는 것은 사실인 것 같다.
이 명제가 그럴 듯 하다고 가정하고, 이제부터 이유를 찾아 보려고 한다.

출처가 어딘지는 불문명하다, 이런 말을 들은 적이 있다. "창업주는 본인의 손으로 고생하면서 사업을 일으켰다. 2세는, 그 어려움을 보고 또 일부는 함께 하면서 자라서, 사업의 힘들고 어두운 면을 잘 안다. 하지만 3세는, 처음부터 안정적인 상태에서 큰 어려움 없이 자라서, 사업의 다양한 면을 알지 못하고 위기 대응 및 극복 능력이 떨어진다. 그래서 보통, 3세부터 문제가 생긴다."
어떤가? 설득력이 있게 들리는가? 물론, 이 말의 전제는, "창업주가 사업을 일으키고, 2세가 사업을 확장 및 안정시켜서, 3세에게 넘겨주는" 경우 - 사실 대한민국의 많은 재벌이 이 경우를 따른다 - 를 가정하고 있다. 나도, 이 말에 공감해 왔다. 하지만, 근래들어 새로운 관점이 생겨서 이에 대해서 이야기 하고자 한다.

먼저, 옛날 "군주"와 재벌의, 소위 "회장"은 어떠한 차이점이 있을까? 만약, 두 위치가 거의 비슷하다면, 어째서 "3세 위기론"을 옛 세습왕정국가에 적용하는 사례는 많지 않은가? 이 둘의 가장 큰 차이점은, "끊임없이 '왕좌'에 대한 위협이 존재하는가?" 라고 생각한다. 옛 왕국은 "장자세습"이 제도화 된 이후에도, 음모, 모략 등으로 인해 장자승계가 무난하지 않는 경우가 많았다. 승계서열 1위는 끊임없이 목숨의 위협을 느껴야 했다. 심지어 군주가 된 이후에도, 왕좌가 안정화 될때까지는 많은 시간이 소요되었다.
하지만, 현대 재벌들은 이러한 위협이 많지 않다. 목숨의 위협은 더더욱 없다. 특히 아들이 "하나"인 경우, 대부분의 경우 문제없이 승계가 이루어진다 - 대한민국의 경우, 지금은 많이 달라졌지만, 지금까지는 "남성", "장자" 우선 승계였다. 즉 위협 및 경쟁이 없다. 있다고 하더라도 아주 약하다. 난 이것이, 과거 "군주"와 현재 "회장"의 가장 큰 차이라고 생각한다. 그리고 이 차이가 "재벌의 수명"와 "왕국의 수명"의 차이 - 3세 위기론 - 를 만든다고 생각한다.

그럼, 구체적으로 이것이 어떠한 차이를 만들어내는 것일까? 앞서 이야기한, "어려움을 겪은 세대"와 "그렇지 않은 세대"의 차이일가? 좀 더 구체적으로, 이것이 무슨 차이를 만들어내는 것일까?
난, 이 모든 것에서 비롯된 "'사람 보는 눈'의 차이"가 근본적인 요인라고 생각한다. 어려움 없이, 처음부터 승계가 확정된 사람의 주위에는 다양한 종류의 인간 군상이 그 속내를 들어낼리가 없다. 사람은 관계가 변하면서 그 다면적인 모습을 드러내게 된다. 소위 "갑"을 대하는 "을"의 자세와, "을"을 대하는 "갑"의 자세는 다를 수 밖에 없다. 항상 "갑"의 위치에 있는 사람은 "을"일때 드러나는, 그 사람의 "단면"만을 보게 된다. 이것만으로 사람을 제대로 판단하는 것은 쉽지 않다.
앞서 이야기한 "어려움을 겪는" 다는 것은, 그 속에서, 다양한 역학관계를 가진 인적 네트워크를 경험하게 된다는 뜻이다. "갑"이 되었다가, "을"이 되기도 하고, 누군가를 믿어야만 하기도 하고, 배신을 경험하기도 한다. 이런 과정 속에서 믿고 신뢰할만한 사람을 찾게 되고, 사람을 보는 눈을 기르게 된다. 하지만, 항상 "절대 갑"의 위치에만 있었던 사람이라면 어떨까? 과연 그런 사람이 인간 군상의 다양한 면을 알고, 사람을 판단하는 "눈"을 가질 수 있을까?
결국 "군주"나 "회장"의 자리는 "사람을 쓰는 자리"이다. "인사가 만사"다. 물론 "의사결정"능력도 중요하지만, 본인이 모든 의사결정을 할 수는 없다. 때문에 "의사결정을 잘 할 수 있는 사람을 쓰는 일"이 가장 중요하다. 그런데 사람보는 눈이 없다면? 이것이 "3세 위기론"의 근본 문제라고 생각한다.

Let me share quite interesting observation.

Environment

• clang++: aarch64-linux-android34-clang++ of android NDK.
• Run on android device

Think about following project

a.cpp

namespace {
    std::map<std::string, int> m0_;
}
static std::map<std::string, int> m1_;

void noticeFromConstructor(const char *name, int value) {
    static std::map<std::string, int> m2_;
    m0_[name]  = value; // (*1)
    m1_[name]  = value; // (*2)
    m2_[name]  = value; // (*3)
}

b.cpp

namespace {
__attribute__((constructor)) void notify() {
    noticeFromConstructor("b", 1);
}

c.cpp

__attribute__((constructor)) static void notify() {
    noticeFromConstructor("c", 2);
}

SIGSEGV is signalled at both (1) and (2) when it run - from both b.cpp and c.cpp - but, (*3) is ok. I think it's because m0_ and m1_ are not initialized yet, but m2_ is initialized.
I'm not sure that there is any explicit description regarding initialization order for this case.

At early 2022, I used glib(2.66.x) for about 3 months for project run on OpenEmbedded Linux. Based on my short(3 months) experience, I would like review it. I mostly used gio and gdbus of glib. So, this review focus on those features.

Pros

• It seems that glib is very popular. However, I am not sure gio and gdbus are also as popular as glib.
• It has large set of features.
• It is easy to use in both C and C++.
• It supports multi-platform(Linux, Windows and so on).

Cons

• Lack of document. It was not easy for me to find useful documents and examples. Again, it's just my opinion. I think it may be caused from frequent changes of API.
• Some APIs doesn't give any response of error to caller. That is there is no way for caller to detect error happened inside API.
  • For instance, g_thread_pool_push() prints some error messages to stderr but doesn't return any error values to caller. I think it's because many APIs of glib provides very high-level functionality and use various techniques to improve performance and resource usage like memory pool, async operations and so on. However, it's very critical that there is no programmatic way for caller to detect error of API. I think it may be very critical defect when developers consider using glib at project requiring high-level stability like system daemon.
• Behavior of Linux file descriptor seems not intuitive to me. One of reasons may be glib provides unified API for multi-platform. For instance, in case of giving and taking file descriptor via GDBus, even if receiver receives only one file descriptor, sometimes, two new open file descriptors are created.
  • When using org.freedesktop.login1.Manager.Inhibit, even if only one file descriptor is passed via GD-Bus, two new file descriptor are created at /proc/<pid>/fd. So, even if FD(File Descriptor) passed via GD-Bus is closed, due to another open FD, inhibitor cannot be closed.
  • Same scinario work well as expected if sd-bus is used instead of GD-Bus.

Summary

After winning over lack of document and get used to it, it looks very powerful and useful library. However, as mentioned above, due to some APIs that don't give error response, it's usablity may be limitted at domain asking very high-level stability.