2008.11.25 21:00

오래된 주제...애플리케이션의 복잡도를 새로운 관점으로...

과거에 소프트웨어 위기(Software Crisis)가 있었다. 이는 미국 인력의 대부분이 소프트웨어 개발에 매달려도 해결하기 힘들만큼 전체 시스템에서의 소프트웨어 비중이 커졌을 뿐 아니라, 복잡해졌기 때문에 발생한 위기였다. 소프트웨어에 대한 의존도가 그만큼 커지면서, 소프트웨어 오류로 인한 피해도 심각해졌다. Therac-25의 의료사고나 Ariane의 폭발사건 등은 너무나도 유명한 사례들이다. 대부분의 프로젝트들은 실패했고, 많은 자금이 낭비되었다.

컴퓨터공학자들은 이렇게 비용면에서 비효율적인 이유는 적절히 개발 관리가 되지 않기 때문이라고 생각했는데, 바로 그 관리를 하기 위해서는 개발 과정에서 등장하는 여러 상황이나 요소들의 상태를 판단하고, 적절히 제어할 수 있어야 했다. 결국, 대상에 대한 정확한 측정이 필요했다. 대상을 여러 기준에 따라 수치에 따라 측정한 값으로 판단하고, 계획하기 위해서였다. 그리하여, 소프트웨어 척도(Metrics)는 소프트웨어 공학이 생기는 초기부터 주목을 받아왔다.

하지만, 척도라는 것은 너무나도 다양한 요소들의 영향을 받는다. 뿐만 아니라, 측정의 대상도 빠르게 바뀌기 때문에 매번 척도에 적용되는 변인들을 새로 고려해 주어야 했다. 분명 중요한 문제임에도 불구하고, 정확한 측정이 어렵기 때문이다. 그래서, 아직까지도 가시적인 성과를 내지 못하고 있는 분야이다.

잠깐, 이야기를 돌려서... 우리가 소프트웨어를 설계할 때는 한 가지 관점으로 보지 않는다. 구조적, 행위적, 논리적 관점 등 다양한 관점이 존재한다. UML 모델 다이어그램을 보더라도 클래스 다이어그램, 액티비티 다이어그램, 인터랙션 다이어그램 등 10가지가 넘는다. 이러한 다양한 관점들의 설계가 모여서 애매모호함을 제거하고, 소위 말하는 오차를 줄여주는 역할을 한다.

복잡도의 경우도 마찬가지이다. 대부분의 복잡도는 크기와 상당한 관계를 가지고 있다. 그러므로, 소프트웨어의 크기와 복잡도를 거의 유사하게 생각하기도 한다. 하지만, 실제로는 크기와 상관없이 복잡도를 가지기도 한다. 아무리 크기가 작더라도 구조적으로 복잡할 수 있고, 간결한 구조를 가진다면 크기가 크더라도 오히려 간단하게 느낄 것이다. 우선 생각해볼 수 있는 것이 바로 이러한 구조적 복잡도이다. 구조적 복잡도는 크기를 어느 정도 반영하기는 하지만, 큰 관련을 가지지는 않는다. 바로, "엔트로피"가 구조적 복잡도를 측정할 수 있는 좋은 방법 중 하나이다.

엔트로피는 열역학에서 그 유래를 찾을 수 있지만, 정보공학에서 이야기하는 엔트로피는 섀넌(C. Shannon)의 1948년 논문인 "A Mathematical Theory of Communication" 에서 시작되었다고 볼 수 있다. 엔트로피는 가장 효율적인 정보 압축의 한계를 계산해주기도 하는데, 평균 정보량 또는 모호함의 정도를 의미한다. 각 객체의 정보량을 그 확률로 곱해서 합한 값이 바로 정보 엔트로피이며, 각 객체의 정보량은 그 객체의 확률에 밑이2인 로그를 취한값에 마이너스를 붙혀서 만든다. 셰넌은 자신의 논문에서 아래와 같은 일반적인 커뮤니케이션 모델을 가정했으며, 정보 소스로부터 목적지로 정보가 전송된다고 가정했다. 실제로 엔트로피는 모호함의 증가치를 나타내기 때문에, 최종적으로 우리의 모호함이 0이 되는 것으로 계산하면 원래 대상에 대한 전체 모호함의 크기가 나오게 된다.
정보 엔트로피에 대해 더 자세히 알고 싶으면, http://en.wikipedia.org/wiki/Information_entropy 를 참고하여 관련 링크들을 읽어보기 바란다. (하지만, 엔트로피를 이해하기 위해 수식까지 모두 이해할 필요는 없다고 생각된다.)


그 외에도 엔트로피는 객체의 복잡도를 측정하기 위해 사용되기도 했다. 객체 지향 시스템 등을 대상으로 몇몇 연구들이 존재한다. 이를 웹 애플리케이션에 대해서도 생각해볼 수 있는데, 각 페이지에 대한 참조 확률을 바탕으로 엔트로피를 이용하는 방법이다. 즉, 웹에서는 웹 소스로부터 개발자에게로 구조적 정보가 전달된다고 본다. 다음은 이러한 방법으로 계산된 복잡도 결과를 일부 보여준다.


총 3개의 실제 웹 애플리케이션의 엔트로피값은 중간에 파란색 선으로 표시된 것이고, 양쪽의 히스토그램에서 오른쪽의 것은 랜덤 생성한 웹 애플리케이션, 왼쪽은 재구조화(CCA모델로 재구조화)시킨 결과 얻어진 엔트로피의 빈도로 히스토그램을 나타낸 것이다. 실제로 3번째 웹 애플리케이션은 2번째 보다 페이지 수도 20개 정도 많고, 관계의 개수는 1000개(4배) 가량 많기 때문에, 크기로 비교한다면 2번째 보다 3번째 애플리케이션이 크다. 하지만, 엔트로피는 더 작을 수 있음을 보여준다. 그만큼 단순한 구조를 가지게 되면 구조에 대한 모호함이 줄어들기 때문에 엔트로피값이 낮아진 것이다.

물론, 이러한 결과 때문에 실제로는 크기의 영향을 많이 받는 예측되는 오류의 개수나 이해 노력도 등 다른 품질 요소들과의 관련성이 떨어질 수도 있다. 이러한 이유 때문에, 엔트로피는 유사한 크기의 애플리케이션 구조 복잡도를 비교하거나 동일한 애플리케이션이 진화하는 과정을 모니터링할 때 더 유용하다.

지금까지 엔트로피에 대해서만 이야기했지만, 복잡도에 영향을 주는 또다른 요소도 있다. 바로 "유사성"이다. 극단적인 예를 들면, 100개의 동일한 페이지와 5개의 서로 다른 페이지를 비교한다면, 분명 5개의 서로 다른 페이지를 이해하는데 드는 비용이 더 클 것이다. 즉, 크기는 작더라도 복잡도는 더 높아지게 된다. 이러한 이유로 유사한 개체들을 많이 포함한 시스템은 덩치가 크더라도 단순할 수 있다는 것이다.

그 외에도 복잡도에 영향을 줄 수 있는 요소들은 많이 있다. 다양한 복잡도 요소들에 대해 분석하고, 이들을 묶어서 일종의 패턴으로 본다면, 훨씬 정밀한 비용 예측이나 복잡도 계산을 할 수 있으리라 생각한다. 복잡도는 분명 중요한 연구 주제 중 하나이지만 어렵고 재미가 없는 주제이기도 하다. 너무 재밌는 주제만 하다가 가끔 실증이 날 때, 이러한 조금은 답답하고 그리 좋은 결과가 나오지도 않는 오래된 주제들을 다뤄보는 것도 좋을 것이라 생각된다.

"코드가 복잡하다고 느끼는 이유는 무엇일까?" 또는
"아키텍처가 복잡하다고 느끼는 이유는 무엇일까?"

이러한 질문들에 대한 새로운 관점이나 해석이 연구의 출발점이 될 것이다.
Trackback 0 Comment 4
  1. 넘버3 2008.12.02 13:24 address edit & del reply

    잘 알지 못하지만 엔트로피에 대해서 관심을 가지고 있었는데, 좋은 내용의 글로 생각합니다.
    소프트웨어나 개발쪽에서 엔트로피에 대해서 공부를 하려면 어떤 것을 참고하면 될까요?

    이 댓글 보시면 꼭 좀 답변 남겨주세요.

    감사합니다.

    • swinside 2008.12.09 22:00 신고 address edit & del

      몇몇 논문들이 있습니다. 주로 OO관련한 것들이 있구요. 엔트로피 이론과 관련한 내용은 위키피디아를 통해 보시면 관련 좋은 링크들이 많습니다.
      이를 SE와 관련지은 논문들은... 주로 메트릭 관련이 많지만... 다음과 같은 것들이 있습니다.

      ** 유명한 셰넌의 A Mathematical Theory of Communication 이 아무래도 제일 시작점이구요.

      ** W. Harrison, "An Entropy-Based Measure of Software Complexity," IEEE TSE, vol.18, no.11, 1992. ( 좀 옛날 논문이지만, SE관련으로 엔트로피 기반 메트릭 기본이 되는 논문...)

      그리고 저자가 Kapsu kim인 "Complexity Measures for Object-Oriented Program Based on the Entropy"는 연구실 선배님이 쓰셨던 논문입니다.

      첨언하면... 엔트로피는 크기 기반은 아니지만, 분명 "복잡한 정도라거나 무질서도와 관련이 있어서" software fault의 밀도와 관련성이 있는 것으로 알고 있어요. 전체 개수와는 상관없구요.

      여튼 뭐 엔트로피 이론이라는 것이 워낙 좀 우주 전체에서 나타나는 현상인지라... 인위적인 사람들의 개발 대상물에서도 나타나는지는 아직까진 모르겠지만... 잘 찾아보면, 그럴싸한게 있을지도 모르겠어요^^;

      그리고, 이건 한글 사이트이지만, 정보이론에 대해 꽤 쉽게 잘 정리되어 있는 내용이라서 링크 알려드립니다.
      http://www.aistudy.com/control/information_theory.htm

  2. 화사 2008.12.10 12:43 address edit & del reply

    복잡도에 대한 관점이 어떤 기준에 따라 크게 달라질 수 있다는 생각을 해봅니다.

    코드가 OOP로 디자인 되어 있고, 이에 대한 복잡도를 측정한다고 할 때,
    디자인 패턴을 공부한 사람이라면 복잡한 계층을 가진 OOP 프로그램도 단순하게 느껴질 것이고, OOP를 알더라도 디자인 패턴을 공부하지 않은 사람에게는 매우 복잡하게 느껴질 것입니다..

    즉, OOP를 직관적인 관점에서 복잡도를 이해할 것인가, 디자인 패턴 관점에서 이해할 것인가에 따라 복잡도는 상이하다고 보아지는데요.

    웹 프로그램이라면 MVC 구조라든가, 객체DB라든가 하는 것을 사용하면 관점에 따라 더 복잡해 보일 수도, 덜 복잡해 보일 수도 있을 것 같습니다.

    또 다른 예로, MFC가 프로그램 구조를 복잡하게 하는 것인가? 단순화 하는 것인가?는 관점에 따라 틀린 것 같습니다.

  3. 이장석 2011.02.25 10:44 address edit & del reply

    글 잘 보았습니다.
    좋은 하루 되십시오.