소프트웨어 스토리

과거에 소프트웨어 위기(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개의 서로 다른 페이지를 이해하는데 드는 비용이 더 클 것이다. 즉, 크기는 작더라도 복잡도는 더 높아지게 된다. 이러한 이유로 유사한 개체들을 많이 포함한 시스템은 덩치가 크더라도 단순할 수 있다는 것이다.

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

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

이러한 질문들에 대한 새로운 관점이나 해석이 연구의 출발점이 될 것이다.

보통 잘 되어있는 소프트웨어 개발 프로세스를 보면 사용자들로 부터 버그 리포트 등을 받게 되면 이를 관리자가 검토한다음 수정해야할 버그라고 생각되면 담당 개발자에게 할당 (Assign)하게 된다. 그런 다음 이 개발자는 자신에게 적당한 버그면 수정을 하고 그렇지 않다면 이 버그는 다른 새발자에게 넘겨준다 (Tossing)

보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?

그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.



우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.

재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?

우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?

여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?