'즐거운 교류'에 해당하는 글 5건

작년에 진행했던 프로젝트에는 여러 기술적 토론이 있었습니다. 그 중 인상 깊었던 토론 하나는 특정 문제의 해결을 위해 웹워크(Webwork)에 있는 기능을 쓸 것인지 아니면 그냥 POJO를 이용하여 해결할지에 대한 토론이였습니다. 이 토론은 깊히 생각해볼만한 흥미로운 요소를 많이 가지고 있었기에 토론 자체에 대해 자세히 적어보는 것도 의미가 있다고 생각합니다. 하지만 저는 이번 글에서 이 문제를 좀 더 일반화시켜 이야기해보고자 합니다.

사용자 삽입 이미지

#그림1. 레이어의 성질

여러 층으로 구성되어 있는 레이어를 생각해볼 때 하위 레이어로 향할수록 '일반성'을 가지며 상위 레이어로 향할수록 '구체성'을 가지는 것을 볼 수 있습니다. 일반성을 가진다는 것은 해당 레이어가 보다 넓은 영역에서 사용될 수 있다는 것을 뜻합니다. 예를 들어 웹워크보다는 그 하위 레이어라 할 수 있는 자바 API가 보다 넓은 영역에서 사용될 수 있다는 점을 생각해볼 수 있습니다. 반대로 구체성을 가진다는 것은 해당 레이어가 자신이 다루는 영역에 대한 전문성을 가질 수 있다는 것을 뜻합니다. 위에 예를 다시 이용해보자면, 웹워크는 몇 가지 영역에서만큼은 자바 API 보다 전문성을 가집니다. 이것은 해당 영역에 관련한 부분을 개발하는데에 있어선 자바 API를 직접 이용하여 개발하는 것보다 웹워크에서 제공하는 API를 사용하는 것이 생산성이나 품질면에서 더 좋을 수 있다는 것을 뜻합니다.

그렇다면 우리는 문제 해결을 위해 항상 적당한 상위 레이어를 찾아서 써야 하는 걸까요? 이 질문을 좀더 구체적으로 표현하자면 이런 질문이 될수 있을 것입니다. "자바 개발을 할 때 최대한 프레임워크를 많이 사용해야 하나요?" "윈도우 개발을 할 때 최대한 컴포넌트를 이용하는 게 옳을까요?" 저는 이러한 질문에 대한 답변을 위해 아래 세 가지 측면을 생각해보고자 합니다.

첫번째는 무게입니다. 레이어가 갖는 무게는 아래와 같이 표현해볼 수 있을 것 같습니다.
n = 레이어의 레벨. 높을수록 상위 혹은 응용 레벨, 예를 들어 어떤 자바 프레임워크의 레벨이 5라면 그 프레임워크가 의존하는 자바 API는 4라 할 수 있다.

레이어(n)의 의존자 ⊂ 레이어(n - 1)의 의존자
따라서
레이어(n)의 의존자 수 ≤ 레이어(n - 1)의 의존자 수

∞ 레어어의 무게 = 의존자 수
위 정의에 따라 의존자를 많이 가지는, 즉 보다 하위에 존재하는 레이어가 상위 레이어와 비교하여 무게가 더 많이 나간다고 볼 수 있습니다. 또한 무게가 많이 나간다는 것은 그만큼 변화의 가능성이 적다는 것으로 볼 수 있습니다. 예를 들어 자바 기반에서 개발을 할 때 자바 기반 자체를 바꾸는 일은 왠만하면 없습니다. 반면에 자바 위에 올라가는 프레임워크는 자주 바뀝니다. 이러한 개발 현장의 모습은 우리가 보다 하위 레이어에 의존할 때 변화에 대한 안정성을 보다 확보할 수 있다는 것을 보여줍니다.

두번째는 유용성입니다. 상위 레이어는 해당 레이어가 지원할 수 있다고 하는 모든 상황에서 유용할까요? 저는 아니라고 생각합니다. 보통 상위 레이어는 특정 영역에 대한 구체성을 가지면서도 그 안에서 최대한의 범용성을 추구합니다. 이 범용성은 해당 상위 레이어가 널리 사용되려면 반드시 가져야 하는 필수적인 성질입니다. 그렇지만 이러한 범용성 때문에 우리가 만나는 구체적이고 다양한 상황에 대해서는 미흡함을 줄 때도 있습니다. 즉 문제에 대한 해결책은 제공하지만 그것이 지금 상황에 딱 들어 맞지는 않는 것입니다. 이것은 마치 몸에 맞지 않는 옷을 입은 것과 흡사하다 볼 수 있습니다. 비록 원래 목적인 몸을 가리는 것에는 성공했지만 보기 좋지 않고 불편한 것입니다.

세번째는 학습 비용입니다. 보통 특정 문제를 해결하기 위한 적합한 상위 레이어가 존재하더라도 그 레이어를 이용하기 위해서는 학습이 필요합니다. 학습에는 시간이라는 비용이 필요합니다.

혹시 현재 환경에서 변화를 최소화 하는 것이 가장 중요한가요? 그렇다면 보다 하위 레이어에 의존하여 개발을 하는 것이 현명할 것입니다. 빠른 개발이 필요한가요? 그렇다면 상위 레이어의 유용성과 학습 비용을 고려하여 적절한 상위 레이어를 선정하고 사용하는 것이 도움이 될 것입니다. 또 다른 경우로 유용성은 있어보이나 학습 비용이 너무 많이 드는 경우도 생각해볼 수 있습니다. 이럴 때는 각각이 주는 가치의 무게를 신중히 비교해보는 것이 도움이 될 것입니다. 만약 유용성에 비해 학습 비용이 지나치게 많이 든다면 하위 레이어를, 학습 비용이 많이 듬에도 불구하고 더 많은 유용성을 준다면 상위 레이어를 선택할 수 있을 것입니다.

결론적으로 앞서 던졌던 질문인 "우리는 문제 해결을 위해 항상 적당한 상위 레이어를 찾아서 써야 하는 걸까요?"에 대한 저의 대답은 "아니다" 입니다. 그것보다는 위에서 얘기했던 것처럼 세 가지 요소를 상황에 맞게 잘 고려한 후 의존할 곳을 신중히 선택하는 것이 현명한 결정이라 생각합니다.

2007/11/29 ~ 2008/07/16

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  1 , 댓글  2개가 달렸습니다.
  1. 플랫폼의 변경은 정말 적게 일어나지만, 프레임워크의 변경은 내가 생각한 것보다는 자주 일어나는 듯...API를 사용할때 비슷한 정도의 편의성과 이득이라면 가능한 하위를 사용하는 것이 변경에 더 좋더라~
secret
자바지기님 블로그의 "변화를 막을 수 없다면 변화에 빠르게 대응할 수 있는 방법을 찾아라.."라는 글에 대한 제 의견입니다.
세상에는 실용적이지도 않고 사람을 괴롭게 하는 지침이나 해결책들이 많습니다. 이러한 지침이나 해결책을 가만히 살펴보면 공통점을 가지고 있는 경우가 많습니다. 그 공통점이란 '인간의 불완전성'을 충분히 고려치 않았다는 점입니다.

인간의 불완전성에 대한 정의는 매우 어려워 보입니다. 대신 아래 내용이 인간의 불완전성을 잘 보여주는 예가 될 수 있다고 생각합니다.
- 인간의 생각은 많은 오류를 가지고 있다.
- 인간이 미래를 예측하는 것은 매우 어렵다.
- 인간은 복잡한 것을 다루는 것에 취약하다.

이런 점에서 "변화를 막을 수 없다면 변화에 빠르게 대응할 수 있는 방법을 찾아라"는 매우 지혜로운 전략이라 생각합니다. "변화를 막을 수 없다"라고 말하는 것은 인간의 불완전성에 대한 인정을 내포하고 있습니다. 이렇게 인정을 하게 되면 우리는 탄탄한 기반을 얻을 수 있습니다. 그것은 '인간의 불완전성 인정'이라는 기반입니다. 이 기반 위에서 우리는 양질의 지침이나 해결책을 만들 수 있을 것이며, 이것들은 실용적이며 사람을 괴롭히지도 않을 것입니다.

2007/11/27 ~ 2008/05/09

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  0 , 댓글  6개가 달렸습니다.
  1. 이 글의 마지막에 달려있는 날짜가 의미하는 바가 뭐지? 설마 네가 저 기간 동안 이 주제를 가지고 고민했다는 증거인가?

    나는 업무 처리할 때 가능한 내 자신이 천재가 아니라 바보라는 관점에서 접근하는 경우가 많다. 그래야 조금씩 발전시켜 나갈 수 있으며, 처음부터 욕심부리지 않을테니..

    인간은 불완전함에도 불구하고 완전해 지려는 것에 너무 집착하다보니 힘들고 스트레스를 많이 받는게 아닐까? 불안전함을 인정하면 마음의 안정을 찾을 수 있지 않을까?
    • 고민까지는 아니지만 해당 기간 동안 비공개 글 목록에 올려놓고 생각 날 때마다 고쳐 쓴 글입니다. 처음에는 꽤 긴 글이였는데 시간이 지나면서 쳐내고 쳐내고 하다보니 저렇게 짦은 글이 남았네요.

      팀장님 말씀 대로 너무 완전해 지려고 집착하면 많은 스트레스를 받는 것 같습니다. 저도 그런 성향이 좀 있는 편인데 나이가 들면서 조금씩 나아지는 것 같아요. 이렇게 변하하는 것이 좋은 것인지 나쁜 것인지에 대해서는 확실히 판단이 안 서네요.
  2. 인간에게 바라는 이상과 현실은 괴리감이 있을수 밖에 없고, 인정할건 인정해야지. 완벽한 것은 세상에 어디에도 없는듯.
  3. 내가 좋아하는 말... 대충해..ㅋㅋ 민창군에게는 어울리지 않네..
secret
아는 사람들의 블로그를 돌아다니다 보니  "블로그를 좀 하다 보니"라는 글이 눈에 띄었습니다. 내용은 인간적인 맛이 살아 있는 글을 써야하나라는 고민인데요. 저도 같은 고민을 저도 하고 있습니다. 방금전에도요.

처음 블로그를 만들 때 경계해야 한다고 생각했던 것은 블로그에서 개인 감정 표현을 하는 것이였습니다. 제 개인의 감정을 담은 글들은 쓸 때 제 마음이 편할지는 모르겠지만, 글을 읽는 사람들에게는 도움이 안 될 것이라 생각했습니다.

그런데 블로그 운영을 하다보니 때로는 답답하고 속시원히 한번 고함을 질러보고 싶을 때가 많습니다. 최근에는 어떤 주제에 대해 고함을 한번 지르고 싶어 글을 몇번이나 썼다가 지웠는지 모르겠습니다.

그런데 여전히 결론은 참자입니다. 지금까지 운영해온 원칙이 있기 때문에 일관성 때문이라도 참아야 할 것 같습니다. 일관성이 깨짐으로 인해 큰 일이 벌어지진 않을 것 같지만 저는 일관성이 깨지는게 무척 싫네요.

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  0 , 댓글  16개가 달렸습니다.
  1. 조금씩 변화를 주는 것도 좋은 것 같아.
  2. 블로그를 너무 심각하게 생각하면 글 안써지지.

    너무 참을 필요도 없을거 같고, 좀더 솔직한 생각이 담긴 블로그들이 많아져야 사고가 더 성장하는듯..
    • 예 그래서 제가 글 쓰는게 매우 힘들고 그 결과로 낮은 포스팅 빈도를 갖는 것 같아요. 조금 생각해볼 부분인 것 같습니다. 그런데 이런 고민을 하는 것 자체가 재밌네요. 블로그가 제 생활의 일부로 확실히 자리 잡은 것 같아서요 ㅋ
    • 참고로 애드센스는 몇달 째 8달러 정도 밖에 안 되서 어제 스킨 바꾸면서 귀찮아서 빼버렸습니다. 어떻게 100달러를 달성하셨는지 정말 신기하네요.
    • 인터넷 비즈니스 기업에 있는 만큼 클릭률 높이는 것도 공부가 될거야. 다시 한번 도전해봐..^^
    • 이거 CSS 안 깨지게 하려다 보면 꽤 어려워서 시간이 많이 소요되더라구요. 하지만 이대로 물러날순 없으니 한번 더 도전해 보도록 할께요 ㅋ
  3. 정재훈 2008.05.02 10:31
    매일 접하는 (좋다고 생각되는) 블로그가 그런 거라서 그런지 모르겠는데,
    내 개인적으로는 블로그에 기술적인 이야기를 쓰는 걸 안 좋아함.
    원래 web log => blog 였지.
    사실 난 동호회 게시판이 그립다.
    • 동호회 게시판이라면 예전 PC통신 시절에 글들 말씀하시는 건가요? 그거라면 저도 무척 그리워 하고 있는데요.
  4. 민달은 개발 이외의 주제로 포스팅하는것이 오히려 부자연스러워 보이는데..ㅋㅋ
  5. 공개된 블로그가 아니더라도 감정 표출은 필요한 것 같아요. 물론 블로그에 하면 시간이 조금 지나고 내가 참 바보 같은 짓을 했구나 싶고 지울 때도 많은데... 그게 사람이잖아요. 뭐 특정한 목적을 표방하는 블로거도 아니고 개인 블로그이니 괜잖지 않나 싶어요.

    비밀 공간을 만들어서라도 써보세요.
    • 예 오랫동안 제가 쓰던 일기장을 잊고 지냈는데 일기장에라도 써봐야겠습니다. 조언 감사드려요.
  6. 나는 블로그에 편하게 글 쓴다. 책으로 출판할 목적도 아니라면 편하게 써도 되지 않을까? 그 자체가 현재 내가 살아가는 모습이라고 생각해서..
    만약 특정 목적으로 블로그를 관리하고 싶다면 두개 이상의 블로그를 운영하는 것도 좋을거 같은데..귀찮니즘 때문에 지속적으로 관리하기 힘들지 않을까?
    • 예 모든 분들이 다 하나 같이 편하게 쓰라고 말씀하시네요. 근데 개인적으로 무척 결정하기 어려운 문제인 것 같습니다.
  7. adsense 플러그인 사용을 해보길 기본적인 위치는 잡아주거든, 위치에 따라서 클릭률이 달라지는데, 유저의 행동방식이 대략 유추 가능하지.
secret

제약과 자유

즐거운 교류 2008. 3. 12. 10:13
거칠마루님이 쓰신 "어느 scheme 책 서문에 나오는 프로그래밍 언어에 대한 말"에 대한 답글입니다.

원글을 보고나서 바로 찾아본 글이 있습니다. 바로 해커와 화가에 나왔던 '안전벨트 혹은 수갑?'이란 글입니다. 이 글은 동적 타입 체크와 정적 타입 체크에 대해서 다룬 글인데요, 해당 글에 마지막 부분에서 저자인 폴 그레이엄은 다소 애매한 결론을 내립니다. 그 결론이란 각각은 장단점이 있으며 (엄청난 엘리트인)본인은 동적 타입 체크를 좋아하지만 다른 똑똑한 친구들은 정적 타입 체크를 좋아한다는 것입니다.

저는 개인적으로 정적 타입 체크를 좋아합니다. 프로그래밍을 할 때의 정적 타입 체크는 제 머리속에서 만들어내는 수많은 오류를 재빨리 막아주는 역활을 합니다. 비슷한 맥락에서 저는 회사의 출근시간도 좋아합니다. 회사의 출근시간은 제가 적절한 시간에 잠을 자고 깰 수 있게 도와줍니다. 저는 이렇듯 제약이라 할 수 있는 것들을 무척이나 좋게 생각합니다. 제약은 저에게 일정한 틀을 제공하며, 저는 그 틀 안에서 최소한의 균형을 갖고 살 수 있기 때문입니다.

그런데 천재성과 예술적인 감각을 가지고 계신 분들은 제약을 못견디는 것 같습니다. 예를 들어 소설 달과 6펜스에서 등장하는 천재 화가 풀 고갱은 현실적인 제약이라 할 수 있는 직장과 가정을 버리고 자유를 찾아 떠납니다. 그리고 예술 작품을 만들어내죠. 또한 실제로 주위를 둘러 볼 때, 천재성과 예술적인 감각이 있어보이는 똑똑한 동료 개발자들이 사회나 회사로부터 오는 제약으로 인해 괴로워하는 것을 자주 목격할 수 있었습니다.

이런 것들을 종합해볼 때 천재성과 예술적인 감각이 있는 사람들에게는 '자유'가, 저 같은 보통 사람들에게는 '제약'이 어울리는 것 같습니다. 그동안의 주류언어들이 대게 정적 타입 체크를 지원해왔다는 사실은 이러한 생각을 뒷받침 하는 근거로도 볼 수 있을 것 같습니다. 주류언어라는 것은 결국 보통 사람들이 선호하는 언어라 볼 수 있기 때문입니다.

2007/03/06 ~ 2007/03/12

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  0 , 댓글  8개가 달렸습니다.
  1. 정재훈 2008.03.12 10:43
    솔직히 이런 생각을 해본 적은 전혀 없었는데요.^^
    한편 맞다는 생각도 들긴 하는데, 그럼 제가 천재? ㅋㅋ
    그건 아니라고 봐요~^^;

    해커와 화가의 '안전벨트 혹은 수갑'은 저도 읽어봤는데, 비유가 끝내주네요.
    민창님의 글에 동의하구요, 좋은 글 잘 읽었습니다.

    다른 분들께 제가 드리고 싶은 말씀은 두가지를 모두 직접 경험해 보시길 권해드립니다.
    안전벨트가 될지 수갑이 될지는 여러분의 마음 속에 있는 거랍니다.
    • 해커와 화가에 따로 나올 정도면 꽤 해묵은 논쟁인 것 같기도 하네요. 하지만 둘다 경험해보는 것이 중요하다는 데에는 이견이 없네요.
  2. 문제는 정적 타입 체크가 얼마나 문제를 사전 예방해줄 수 있느냐?

    일듯..

    차라리 타입 체킹을 IDE 역할로 넘겨버리는 것이 속편하지 않을까?
    • IDE가 그런 역활을 해야한다면 IDE 개발 업체들이 타입 체크 기술을 가져야 할 것 같은데 실제로 그렇게 구현된 사례가 있는거야?
  3. 제약 드리븐 인생 일까요?
    자신을 컨트롤할 수 있는 사람만이 자유를 만끽하는 것 같아요.
    아쉽게도 저 역시 제약이 어울리지만요 :)
    아마 제약이 없다면, 쉽게 폐인이 되었을것 같아요. 생각해보니 민달이님치럼 출근시간의 제약을 고맙게 느껴야겠네요 ^^

    시스템 개발시 제약은 필수라고 생각합니다. 특히 제가 속한 SI분야에선....
    생각속의 정리와 코드속의 정리는 타인의 이해도가 상당히 차이가 나거든요. (이 문장도 이해가 어렵네요 ^^)
    정형화가 되면 될 수록 이해도는 높아질 수 있는 것이라 생각합니다.
    • 저도 예전에 SI에서 잠시 일 했었는데 이젠 오래된 이야기네요. 많은 사람들이 모여서 일할 때는 부득이하게 제약이 생길 수 밖에 없는 것 같습니다. 하지만 그게 지나치다면 또 문제가 생길수도 있을 것 같네요. 제약이 있더라도 제약을 받아들이는 사람이 억압과 같이 느끼기보다는 목표를 위한 안전띠처럼 느끼게 하는 제약이면 좋을 것 같아요.
  4. 동적 타입(타입의 개념 자체도 언어마다 다르죠) 검사와 정적 타입 검사는 둘 다 타입 검사를 하는데 언제하느냐의 차이일뿐입니다. 저는 언제하느냐 보다는 타입 검사에 필요한 정보를 누가 주느냐가 더 영향이 크다고 생각합니다. 하스켈은 정적 타입 검사를 하지만 타입 정보를 적지 않아도 되죠. 자바처럼 사람이 정보를 준다면 동적 타입 검사 언어를 쓰고 프로그래머가 xUnit으로 타입 검사를 할 수도 있겠죠.

    정적 타입 검사 언어는 일종의 보험 시스템 같습니다. 보험회사는 사고에 대한 두려움을 부각시키고 소비자에게 안심을 제공하는 댓가로 돈을 받습니다. 사고가 터지면? 좋은 보험회사인지 나쁜 보험회사인지는 모르겠군요.

    IDE 타입 검사는 매일 쓰고 있는 이클립스에서 하고 있잖아요. 자바는 어차피 타입 검사를 해야 하기 때문에 IDE에서 실시간으로 해주면 피드백을 빨리 받을 수 있으니 장점이죠.
    • 정적, 동적 타입 검사에 대해서 스스로 좀 부정확하게 생각하는 경향이 있었던 것 같네요. 이 부분에 대해선 아래 링크 보고 좀 정리를 했습니다. 헤스켈에 대해서도 언급이 있네요.(http://cs.wwc.edu/~aabyan/LN/PL/book/node68.html)
secret
오늘 올블로그 추천 RSS에서 정말, 그 정신에 면세점 갔다온거야? "대단하다!" 라는 글을 받아 보았습니다. 개인의 아무 근거없는 추측을 바탕으로 이번에 귀국한 피랍자들을 비난하는 당황스런 글이였습니다.

그런데 글도 글이지만 이 글을 버젓히 추천 글로 등록한 올블로그측(올블로그의 추천은 사람들의 추천에 의해 글이 올라오는 시스템이라고 합니다)이 더욱 당황스럽게 느껴졌습니다.

올블로그측에 묻고 싶습니다. 도대체 글을 추천하는 기준이 무엇입니까? 혹시 흔히 우리가 찌라시라고 비하하는 언론처럼 자극적이어서 많은 PV를 유도할 수 있는 글을 추천하는건가요?

올블로그에서 하루에 10개씩 글을 추천하는 것 같은데, 이런 글을 추천하려면 차라리 추천을 안 하는게 좋을 것 같습니다. 앞으로 올블로그가 블로그 언론으로써 제대로 발전하려면 이런 수준이하의 운영은 없어야 할 것 입니다. 오늘 올블로그에 대해서 크게 실망했습니다.

2007/09/03일 15시 추가 : 글 쓸 당시에 추천을 올블로그에서 하는거라고 생각하고 글을 썼습니다만, 덧글을 통해 다른 분들 얘기를 들어보니 추천이 많이 된 글이 올라오는 구조인 것 같습니다. 제대로 모르고 이런 글을 써서 올블로그에 죄송하고 스스로는 민망하기도 합니다. 하지만 저는 여전히 이런 글이 추천글로 버젓히 올라올 수 있는 구조는 잘못되었다고 생각합니다. 올블로그에서 이런 부분에 대해 좀더 고민을 해주시면 좀더 긍정적인 환경을 만들어 나갈 수 있을 것이라 생각합니다.

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  0 , 댓글  8개가 달렸습니다.
  1. 올블에서 추천한게 아니라, 올블에서 그 글을 읽은 사람들이 추천한것이죠...
    그 점이 더 암울하긴 합니다만... ㅠㅠ
  2. 추천 글은 올블로그에서 찾아서 보여준다라기 보다는 사람들의 추천에 의해서 올라간거니깐요. 어떤 저희가 주관적인 개입을 통해서 글을 올리거나, 내리거나는 하지 않는답니다. (오히려 그게 더 문제가 될 것 같아요.) ^^;
    • 네 제가 잘못 생각한 부분이 있는 것 같습니다. 이 부분은 저의 실수이네요. 하늘이님도 덧글을 통해서 이미 말씀하셨지만 올블로그는 이미 적지않은 영향력이 있는만큼, 오늘과 같은 사건에 대해 책임감을 가지고 좀더 진지하고 신중하게 해결책을 고민해주시면 좋겠습니다.
  3. 올블로그의 잘못은 아니지만, 올블로그에 모이는 사람들 중, 낚시를 즐겨하는 사람들이 많이 있죠.
    별로 유쾌하지 않은...
    추측성 발언들 ^^;;
    • 네 그런면도 분명히 있는 것 같습니다. 하지만 위에서 여러번 언급한것처럼 구조적으로도 개선이 가능한 부분이 있을 것이라고 봅니다. 이 부분은 올블로그의 몫이겠지요.
  4. spiderjeong 2007.09.04 09:03
    그 글이 추천받았다면 그 또한 무슨 이유가 있어서겠죠 무턱대곤 안했을듯~
    • 네 아마도 많은 이들의 울분을 조금이나마 해소시켜준 글이 아닌가 싶습니다. 하지만 그것이 올바른가에 대해서는 생각해 볼 부분인 것 같네요. :)
secret