IT는 다른 학문에 비해 비교적 신입이기 때문에 다른 학문에서 나왔지만 IT에 적용되는 이런저런 법칙들이 있다. 잘 알려진 8:2이 법칙은 성능이나 오류의 문제를 설명하는데 사용되곤 한다.

그밖에도 양화구축 - 혹은 16세기 영국 재무장관 그레셤의 이름을 딴 그레셤의 법칙이라는 게 있다. 

16세기 영국의 주요 화폐는 금화와 은화였다. 처음에는 금화의 포함된 금과 은의 가치와 금화의 가치가 거의 차이가 없었다. 그러나 화폐의 유통이 활발해지면서 화폐를 만들 금과 은이 부족해지면서 점차 금과 은의 함량을 줄인 화폐를 발행하였다.

일반 사람들로서는 최악의 상황에서 언제든 동일한 가치로 교환할수 있는 이전의 금화 은화는 자신의 금고에 두고 이 후에 발행된 함량이 부족한 화폐(악화,惡貨, bad money)만을 사용하게 되는데 이는 화폐의 신뢰문제로 이어지게 되었다.

근세 화폐 경제 체제에서 악화(함량이 부족한 금화)가 양화(1:1비율의 금화)를 구축하는 현상이 심화되자, 사람들은 통용되는 금화와 은화를 믿지 않게 된다. 일일이 금과 은의 함량을 재면서 거래를 하다 보니 화폐의 의미가 크게 퇴색하고 말았다. 결국 근세 화폐 경제 체제가 붕괴 직전까지 가고 말았다.

대항해 시대의 영국은 당시 국제통화로서의 가치를 잃고 싶지 않았고 당시 영국의 재무관이었던 T. 그레셤은 엘리자베스 여왕에게 이런 상황을 개탄하는 편지를 올렸다. 악화를 개주(改鑄)하는 작업을 거치지 않고는 영국이 외환을 지배할 수 없다는 취지였다. 19세기 중반 H. 마크로드는 그레셤의 보고에 ‘그레셤의 법칙’이라는 이름을 붙였고, 이는 훗날 경제학사에 가장 유명한 법칙의 하나가 됐다. 오늘날에서는 나쁜 것이 좋은 것을 압도하는 현상 일반을 지칭하는 용어가 됐다.

최근의 신용중심으로 변한 금융시장에서 그레셤의 법칙은 그 의미를 찾기 힘들지만 IT에서는 종종 사용되곤 한다. 대표적으로 좋은 글이나 사이트가 자극적이고 저급한 글에 밀려 사라지게 되는 현상이나 좋은 아이디어나 프로그램이 상업주의에 밀려 없어질때 사용되곤 한다.(물론 단순히 변명으로 사용되기도 한다.)





Broken Window 혹은 깨진 유리창 이론은 사회학에서 유래한 용어이다. 깨진 유리창 이론(Broken Windows Theory)은 미국의 범죄학자인 제임스 윌슨과 조지 켈링이 1982년 3월에 공동 발표한 깨진 유리창(Broken Windows)이라는 글에 처음으로 소개된 사회 무질서에 관한 이론이다.

깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다. 오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 담당자들이 그 건물에 별 관심이 없다는 느낌 말이다. 그래서 다른 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서가 등장한다. 심각한 구조적 손상이 시작된다. 꽤 짧은 시간 안에 소유주가 그걸 고치려는 의지를 넘어설 정도로 건물이 손상되고, 결국 버려진 느낌은 현실이 되어 버린다.


이는 사람들이 쓰레기를 다른 쓰레기가 버려져 있는 곳에 버리는 것과 비슷한 이치이다. 길에 쓰레기가 하나도 없다면 처음으로 쓰레기를 버리고자 하는 사람은 망설여지지만 이미 쓰레기가 버려져 있다면 그다지 죄책감을 가지지 않는 다는 것에 기인한다.

깨진 유리창을 일소하듯이 경범죄 단속에 힘쓰는 것이 중범죄 예방에 효율적인 전략이냐에 대해서는 논란이 좀 있지만 Broken Window 이론은 리팩토링 논리의 바탕이 되는 이론이다. 

깨진 창문 - 즉 조악한 설계의 코드, 형편없는 경영상의 결정 등 프로젝트 기간 동안 팀이 동고동락해야 하는 것들 - 내리막길로 가는 첫걸음이다. 깨진 창문이 꽤 있는 프로젝트를 한다면, "나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐."라는 사고로 빠져들기 너무도 쉽다. … 같은 맥락에서, 코드가 청순할 정도로 아름다운(깨끗하고, 잘 설계되었으며 우아한) 프로젝트와 팀에 여러분이 속해 있다면, … 별도의 특별한 주의를 기울여서 엉망으로 만들지 않도록 노력할 확률이 높다. 비록 불길이 일어날지라도 (데드라인, 출하 날짜, 시사회 데모 등) 엉망진창으로 만드는 첫째 사람이 자신이 되는 것만은 피하려 한다. 그래서 지속적인 리팩토링이 필요하다는 논리이다.




물리학에서는 잘 알려진 엔트로피의 법칙이 있다. 엔트로피란 물질계의 열적 상태를 나타내는 물리량의 하나이다. 통계 열역학적 정의로 엔트로피는 열역학적 계의 통계적인 ‘무질서도’를 나타낸다.

열역학 제 1법칙은 에너지 보존에 관한 법칙이다. 즉 제 1법칙은 "에너지는 그 형태를 달리 할 수는 있으나, 없어지지는 않는다" 는 법칙이다

IT에서 주로 회자되는 원칙은 열역학 제 2법칙으로 우주의 진화 방향에 관한 법칙이다. 즉 제 2 법칙은 "자연계에 있어서 자발적인 진화 방향은 혼란도(또는 emtropy)가 증가하는 방향"이라는 법칙이다. 우주의 에너지는 일정하지만 변화는 계속되기 때문에 결국은 엔트로피가 더 이상 증가할 수 없는 극도의 혼란한 상황에 이르게 된다. 그렇게 되면 더 이상의 자연적인 변화는 불가능하다. 이것이 바로 열죽음이라고 부르는 우주의 종말이다.

이는 사람들이 bit의 조합은 코드는 영원히 순수하리라 기대하지만 실제 코드는 버그수정과 기능 추가등을 통해 부패한다. 따라서 코드의 부패를 막기 위해서는 임의적인 작업이 이루어져야 하며 이는 코드의 생존주기 내내 끝없는 리팩토링의 필요성의 근거이론으로 사용된다.



14세기 영국의 논리학자이며 프란체스코회 수사였던 오컴의 윌리엄에서 이름을 딴 오컴의 면도날이라는 원칙도 있다. 오컴은 보다 적은 수의 논리로 설명이 가능한 경우 많은 수의 논리를 세우지 말라. 라는 말을 자주했는데 이를 약간 변형하여 가장 단순한 것이 답이다. 라는 것으로 알려져 있다.

독일의 Bauhaus 운동의 아키텍트이자 리더인 Ludwig Mies van der Rohe(1886-1969)가 직접 오컴의 면도날 원칙을 참조했는지는 알수 없지만, 설계에 있어서의 최소주의 설계(minimalist design)라는 개념을 주장하였다.

그는 Less is More를 모토로 삼았는데 의미는 단순성(simplicity)과 명료성(clarity)이 좋은 설계를 만들게 된다라는 것으로 현대 설계의 아키텍처의 단순한 형태(style)와 관련된 용어이다.

SW 아키텍처에서는 견실한(consistent) 아키텍처는 동일한 것에 대해 수행하는 두가지 이상의 방법을 제공하지 않는다는 것을 의미하며, 이는 사용자로 하여금 어떤 것을 사용할지를 선택하도록 강요하는 시간 낭비를 유발시킬 수 있기 때문이다.
따라서, 견실한 SW 아키텍처는 배우기가 더 쉽고 빨라야 하며, 일단 처음에 배운 내용을 거의 알지 못한다고 하더라도 그 나머지에 대해서는 쉽게 예상할 수 있게 구성되어야 한다. 특별한 경우에 대해서 염두하고 처리할 필요가 없이 코드는 더 깔끔해지고 테스트 코드는 더 적어야 한다.



원칙까지는 아니지만 혹시 기타를 쳐본 사람들은 시나위의 기타리스트 신대철의 명언을 알것이다. "기타가 펜더면 뭐해? 손꾸락이 펜더여야지" (펜더(Fender)-Gibson 사와 더불어 세계 최고의 일렉기타 메이커)

이는 IT 세일즈의 주장과는 달리 좋은 툴을 든 바보도 그냥 바보다. 라는 말과 일맥상통한다. 이전에 적은대로 툴이든 방법론이든간에 기본적으로 어려운것을 쉽게 해주는 것은 무척이나 어렵다. (아주 가끔 일어나기는 한다.) 단지 복잡하거나 귀찮은 것을 단순하게 만들어 줄 수 있을 뿐이다.

이 주장이 조금 과격해지면 툴은 사람을 바보로 만든다 라는 주장에 쓰이기도 하는데 개인적으로는 그렇게까지는 생각하진 않고 좋은 툴이라도 바보를 똑똑하게 만들지는 못한다 정도로만 이해하는게 좋을 것 같다. 이는 소프트웨어 작업에서 가장 중요한 요소는 프로그래머들이 사용하는 도구나 기술이 아닌 프로그래머들 자신들의 자질(quality)임을 말해준다.


그 밖에도 IT에서 회자되는 타학문의 원칙들은 다음에.. ..






'Framework > 아키텍쳐 일반' 카테고리의 다른 글

예언?  (0) 2009.06.12
패키지의 설계 원칙  (0) 2009.06.08
AOP  (0) 2009.06.08
Self-Signed Java Applets  (0) 2009.06.01
여섯번째 계 - Encapsulation  (0) 2009.04.14
Posted by bleujin