Life/Society

진짜는 굳이 의미를 부여할 필요가 없다.

얼마 전 꿈에서 내가 나한테

진짜는 굳이 의미를 부여할 필요가 없다.

고 말했다.[각주:1]
꿈의 통찰에 완전히 감탄했다.

가짜는 본질의 회피하기 위해서 다양한 의미를 부여해야 한다.
뭔가 설명이 필요하고 더구나 설명이 복잡하면 그건 본질이 아니다.

누군가의 관계에 꼭 의미를 붙여야만 한다면 진정한 만남이 아니다.
자신이 하는 일에 이런 저런 합리화가 필요하다면 분명히 그른 일이다.
나의 감정/느낌/생각에 대한 설명이 길어진다면 거짓을 꾸미고 포장하는 것이다.[각주:2]

진짜는 짧고 단순하고 명쾌하다.
추가되는 내용이 있다면 단지 부연하는 것 뿐이다.
덧붙이지 않아도 아무런 상관이 없다.

가짜는 온갖 부차적인 이유와 설명이 꼭 필요하다.
진실의 가리기 위해서 수많은 부연이 수반된다.

  1. 꿈이 훨씬 통찰력이 있다고 생각되었다. 깨어있을 때는 자아의 온갖 방어 기제가 거짓을 말하기 때문에 듣지 못한 것 같다. [본문으로]
  2. 거짓임을 자각하지 못할 수도 있다. [본문으로]
저작자 표시 변경 금지
신고
Life/Society

사람을 믿는 기준

도덕과 윤리에서 사람을 믿고 도움을 줘야 한다라고 배웠다.
아무나 어떤 상황에서도 믿어야 할까?
무조껀 신뢰하는 것은 항상 불신하는 것만큼이나 어리석다.
이 글에서 믿음의 기준에 대해서 탐구하고자 한다,

상대방이 반격하더라도 막아낼 수 있다면 웬만하면 믿음을 가져라.
그러나, 나를 지킬 수 없을 것 같으면 자신을 보호하는 것이 우선이다.

이런 이유로 집에 혼자 있는 아이나 여성은
아는 사람이라고 하더라도
함부로 집에 들어오게 하면 안된다.

어린이가 택배 기사의 방문에 대문을 열어주지 않는 것은
그분이 나쁜 사람이라서가 아니라
자신을 지킬 수 없기 때문이다.

"나 못 믿어?"
"속고만 살았어?"

별의 별 소리를 해도
상대의 공격을 막을 수 없다면 방어적으로 나가야한다.

"사람을 믿고 열린 자세로 가져야 합니다."

라는 도덕적/종교적인 지침에도 이는 적용된다.

상대방의 반격을 막아낼 능력이 없으면 관용적인 자세는 실효성이 없다.

반대로, 상대의 반격에 웬만큼 대응할 수 있다면 열린 자세를 갖는다.
이 세상의 많은 일은 상호 교류와 소통에서 온다.

저작자 표시 변경 금지
신고
Theory/Project Management

일단 만들어라. 두 번 만들어라. 그러면 보일 것이다.

내가 실무에서 배운 최고의 설계 방법은?
일단 만들어라. 두 번 만들어라. 그러면 보일 것이다.


문제를 이해하는 가장 좋은 방법은 만들어보는 것이다.
생각만으로는 알 수 없다.[각주:1]
구현하면서 문제에 대한 이해가 높아진다.


첫번째 구현에서는 문제의 탐색에 초점을 두어야 한다.
머릿속에 떠오르는 이상적인 시나리오를 직선적으로 표현한다.
세세한 예외 상황이나 아름다운 코딩 등에 시간을 빼앗기지 말자.


그림에 비유하자면, 머릿속에 떠오른 이미지를 거침없이 스케치를 하는 것과 같다.
화폭에 그리면서 전반적인 이야기와 구도를 잡는 것이 가장 효과적이다.
이 단계에서는 세부적인 부분에 신경 쓰지 않는다.


종종 문제 탐색이란 목적을 잊고 멋진 코드를 만드는데 집중하는 실수를 하곤 한다.
문제의 탐색이 늦어지면 그만큼 손해다.
프로젝트 중반에 드러나는 설계의 문제는 치명적이다.


그림의 구도를 파악하기도 전에 세세한 묘사에 빠지는 것과 같다.
어느정도 그림을 완성한 후에 문제를 발견하면 고치는데 상당한 비용이 든다.


이때 "문제만 탐색하고 버릴 코드"라는 생각이 도움이 된다.
우리는 버릴 것에는 공을 들이지 않는다.


이전에 얻은 교훈은 다음번 탐색 구현에서 적용한다.
이 과정을 문제에 대해서 충분한 파악이 될 때까지 반복한다.
보통 두세번이면 충분하다.
더 이상 반복해도 그다지 나아지지 않는다.
투자한 시간과 노력보다 얻는 이익이 적다.


탐색이 끝나면 공을 들여 코딩한다.
이후 생산되는 코드는 반드시 아름다워야 한다.


  1. 창의적인 아이디어도 만들면서 나온다. 관련 링크: <a href="http://unipro.tistory.com/164" target="_blank">창의적인 일을 찾지 말고 창의적으로 일을 하라.</a> [본문으로]
저작자 표시 변경 금지
신고
Theory/Unclassified

민주주의 서비스 아키텍쳐

민주주의는 그냥 표를 많이 얻는 이가 권력을 가지는 제도이다.
표를 많이 얻은 사람이 훌륭하다는 보장이 없다.
따라서, 민주주의는 훌륭한 사람 능력있는 사람을 뽑는데 적합한 제도가 아니다.
다만, 이상한 사람이 권력을 잡아도 나쁜 짓을 아주 많이 못하게 한다.[각주:1]
민주주의의 핵심은 평화적이고 합법적으로 권력을 교체할 수 있다는 것에 있다.

- 차이나는 클래스에서 유시민


비슷한 원리를 서비스 아키텍쳐에 도입하면 어떨까?
이를 "민주주의 서비스 아키텍쳐"라고 이름을 붙이자.

이 아키텍쳐는 최고의 시스템을 만드는 것을 목표로 하고 있지 않다.
문제가 있더라도 극복할 수 있는 탄력적인 시스템을 만드는 것이 핵심이다.[각주:2]

  1. 박근혜 전대통령의 탄핵이 대표적인 예. [본문으로]
  2. 세부 기술과 방법은 생각나면 진행할 예정이다. 어쩌면 여기까지가 끝일 수도 있다. [본문으로]
저작자 표시 변경 금지
신고
Practice/Debugging

문제가 발생하면 근본 원인 찾아라.

문제가 발생하면 근본 원인 찾아라.[각주:1]
근본 원인을 찾지 않고 성급하게 해결하는 것은 나쁘다.

대표적인 사례가 핵(hack)이다.
핵은 원인을 고치지 않고 드러나는 문제만을 처리한다.
근본 원인 파악 없이 방어 코드로 해결한다.

자동차의 시동을 두세번 시도해야 비로서 작동하는 문제가 있다고 가정해보자.
핵를 쓰는 엔지니어는 시동 걸릴 때까지 자동으로 반복해주는 기능을 추가한다.
여러 가능성이 있는 원인을 조사하지 않고 표면적인 문제만을 처리하였다.[각주:2]

그러나, 이러한 방식은 문제를 감추었을 뿐 근본이 해결되었는지 알 수 없다.
숨겨진 문제가 언제 드러날지 누구도 알 수 없다.
게다가, 이렇게 원인이 해결 안 된 문제들이 숨겨지면서 누적된다는 것이 더 심각하다.

시동이 잘 안걸렸던 이유가 배터리가 망가지고 있었기 때문일 수도 있다.
만약 그렇다면, 핵으로 진짜 문제를 숨겨준 셈이다.
외딴 곳에 있을 때 배터리가 완전히 망가진다면
또는 고속도로 주행 중에 시동이 꺼진다면
아주 큰 문제에 직면하게 된다.
실력있는 엔지니어는 진짜 원인을 찾아내어 이런 사태를 사전에 예방했을 것이다.

더불어, 핵을 자주 사용하면 개인의 실력 향상에도 좋지 않다.
문제를 정의하고 원인을 파악하는 능력은 문제 해결에서 매우 중요하다.
핵은 이 능력을 길러주지 않는다.

핵을 쓸 수 밖에 없는 피치 못할 상황도 있긴 하다.
예를 들면, 긴급하게 처리해야 하는 상황,
우리가 수정할 수 없는 외부 라이브러리 등의 이유가 있겠다.
이러한 경우, 코드에 반드시 핵을 썼다는 사실과 이유 등을 주석을 남겨야한다.[각주:3]
나중에 이런 부분을 찾아서 반드시 제대로 고쳐야 한다.


  1. 가능성 있는 진짜 원인을 찾아가는 도구 중에 <a href="http://unipro.tistory.com/112" target="_blank">5 Whys</a>라는 것이 꽤 유용하다. [본문으로]
  2. 문제를 빨리 해결하여 마치 실력자처럼 보일 수도 있다. 이런 착시 때문에, 일부 프로그래머는 자신의 무능함을 감추고자 핵을 자주 이용한다. [본문으로]
  3. 관례적으로 주석의 시작에 "HACK" 또는 "XXX"라고 붙이다. [본문으로]
저작자 표시 변경 금지
신고

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 68
Yesterday : 341
Total : 179,320