SW 아키텍처 분석방법

SW 아키텍처 참조모델
소프트웨어 구조의 평가 및 개선을 위한
소프트웨어 아키텍처 분석
[Version 1.0 20140324]
SW공학센터
SW공학기술팀
SW아키텍처 실무자 포럼 모바일 분과
SEC-2014-RM005
Copyright(c)2014 by SW공학센터

p
소프트웨어 아키텍처 참조모델(아키텍처분석 분과)
3
본 문서는 국내 기업의 소프트웨어 품질 및 생산성 향상을 지원하기 위하여 작성되었
습니다.
본 문서는
미래창조과학부 산하
정보통신산업진흥원 부설
SW공학센터
SW아키텍처 실무자 포럼
에서 작성되었습니다.
SW공학센터는 SW제품 생산능력 향상, SW공학기술 산업현장 적용 등을 위해 대학 및
전문 연구기관과 기업 현장을 연결하는 중심 허브가 되어 SW개발 중소기업들에게 전문
컨설팅을 제공하고 있습니다. 이 같은 역할을 충실히 수행하기 위해 산업과 기업의 SW
공학기술 관련 요구사항에 전문적이고 신속한 대응을 할 수 있는 핵심 기능 연구와 SW
개발 프로젝트의 성공 여부와 문제점을 미리 예측하여 SW품질과 생산성, 제품결함 등을
총체적으로 진단 할 수 있는 SW공학 컨설팅 등도 추진하고 있습니다. 이와 더불어 SW
품질과 생산성, 비용 등을 체계적으로 추적 평가할 수 있는 데이터 수집체계도 강화하여
SW기업들이 이를 손쉽게 활용하게 함으로써 전체적인 국가 SW품질을 향상시키는 업무
도 수행중입니다.
본 문서의 모든 권리는 SW공학센터가 가지고 있습니다. 문서의 내용을 이용하거나 활
용할 시에는 반드시 SW공학센터의 출처를 밝히고 사용하여야 합니다. 본 문서의 내용을
공공의 증진이나 내부의 품질 향상을 위한 용도 이외의 상업적 목적으로 사용할 시에는
필히 사전에 SW공학센터의 허가를 받아야 합니다.
사전에 SW공학센터의 허가를 받거나 논의하지 않은 모든 형태의 책임에 대하여 SW공학
센터에서는 보증하지 않습니다.
본 지침에 대한 더 많은 정보와 SW공학에 대한 추가 정보를 얻고 싶다면, SW공학센터
홈페이지(www.software.kr)를 방문하여 주십시오.
담당자 강승준 책임 [ksj@nipa.kr, 02-2132-1344]

4 SEC-2014-RM005
이름 경력 비고
손영수 분과장
NHNNEXT 교수
indigoguru@gmail.com
소프트웨어 공학과 아키텍팅을 국내
개발자들에게 널리 알리기 위해 노력하고
있으며, NHNNEXT 에서 소프트웨어
아키텍팅과 모바일을 가르키고 있다.
국내 최초의 패턴 전문가 Hillside 그룹의
이사회 위원이며, 아시아 패턴 학회인
AsianPLoP 의 공동 의장이다..
- 소프트웨어 마에스트로 멘토를 포함한
다양한 멘토링 경험과 다수의 공모전 수상.
- 한국 공개 SW 포럼 인력양성 분과장
- AsianPLoP 공동의장.
- PLoP 이사회 Hillside Group Board
Member
- PLoP (소프트웨어 패턴학회) 인증 소프트웨어
패턴 저자 활동 및 다수의 패턴 발표.
- 소프트웨어 공학 커뮤니티 EVA 10 년간
운영.
양현철
URQA Committer
wolfses@hotmail.com
2013 대한민국 소프트웨어 마에스트로
(NIPA)로 인정받았으며 패턴학회 PLOP에서
아키텍처 시각화 패턴 논문을 기고하였다.
현재 UrQA 커미터로 활동 중이다.
-2013 소프트웨어 마에스트로
-소프트웨어 아키텍쳐 분석기 STANly 제작
-모바일 버그 리포트 서비스 UrQA 커미터
-현 KAIST 석사과정
정승수
드래곤 플라이
sjdmldi@gmail.com
소프트웨어 마에스트로 3 기 연수생으로
활동하면서 PLOP에 아키텍처 시각화 패턴
논문을 기고하였다.
아키텍처와 관련하여 관심이 많으며 현재는
게임회사에 재직중이다.
-소프트웨어 마에스트로 3 기 연수생
-마이크로 소프트웨어 패턴 관련 기고
Plop2013 아키텍처 시각화 논문 기고
드래곤 플라이 재직
오혜성
이스트 시큐리티
mse201@gmail.com
소프트웨어 마에스트로 3 기 연수생으로
활동하면서 PLOP 에 아키텍처 시각화
패턴 논문 기고하였다.
서버 및 웹 프로그래밍 분야에 관심이
많다.
현재는 IT 기업에 재직중이다.
-소프트웨어 마에스트로 3 기 연수생
-마이크로 소프트웨어 패턴 관련 기고
Plop2013 아키텍처 시각화 논문 기고
이스트 소프트 재직
분과원 소개

p
5
목 차
제 1 장 소프트웨어 아키텍처 분석 ·························································································· 7
제 1 절 소프트웨어 아키텍처 개요 ·································································································· 7
제 2 절 소프트웨어 아키텍처 분석 목적 및 배경 ········································································· 9
제 3 절 소프트웨어 아키텍처 분석의 장점 ·················································································· 12
제 2 장 소프트웨어 아키텍처 정방향 분석 ·········································································· 15
제 1 절 소프트웨어 아키텍처 정방향 분석 개요 ········································································· 15
제 2 절 소프트웨어 아키텍처 정방향 분석의 목적 ····································································· 16
제 3 절 소프트웨어 아키텍처 평가/분석(ATAM) ······································································· 16
제 3 장 소프트웨어 아키텍처 역방향 분석 ·········································································· 22
제 1 절 소프트웨어 아키텍처 역방향 분석 개요 ········································································· 22
제 2 절 소프트웨어 아키텍처 역방향 분석의 특징 ····································································· 25
제 3 절 도메인 분석을 활용한 소프트웨어 아키텍처 분석 ······················································· 27
제 4 절 지표를 이용한 소프트웨어 아키텍처 분석 ····································································· 35
제 5 절 시각화를 활용한 소프트웨어 아키텍처 분석 ································································· 70
제 6 절 소프트웨어 아키텍처 역방향 분석 정리 ···································································· 112
제 4 장 도구를 활용한 소프트웨어 아키텍처 분석 ··························································· 113
제 1 절 STAN4J ····························································································································· 113
제 2 절 Metrics ····························································································································· 130
제 3 절 CodePro Analytix ··········································································································· 136
제 4 절 CppDepend ····················································································································· 154

6 SEC-2014-RM005
제 5 장 소프트웨어 아키텍처 분석 결과의 활용 ······························································· 164
제 1 절 아키텍처 분석 결과 활용을 위한 대상 선정 ······························································· 164
제 2 절 공개 소프트웨어 아키텍처 분석 결과의 활용 ····························································· 165
제 3 절 공개 소프트웨어 아키텍처 분석 후 개선 활동 ··························································· 170
제 6 장 소프트웨어 아키텍처 분석의 결론 ········································································ 174
제 1 절 소프트웨어 시각화 지표별 특성 및 범위 ·································································· 174
제 2 절 소프트웨어 아키텍처 분석 제품들의 분류 ··································································· 175
제 3 절 맺음 ··································································································································· 176

p
7
제 1 장 소프트웨어 아키텍처 분석
제 1절 소프트웨어 아키텍처 개요
소프트웨어 아키텍처에 대한 정의는 매우 많이 이뤄지고 있지만, 소프트웨어 아키텍처에
관한 연구를 주도하고 있는 미국 카네기멜론 대학의 SEI(Software Engineering Institute)에서는
일반적으로 다음과 같이 정의한다.
"Software architecture for a system is the structure or structures of the system, which
compromise elements, their externally-visible properties, and the relationship among them."
"한 시스템의 소프트웨어 아키텍처란 그 시스템의 한 구조나 구조들로 각 요소들과 외부에
보이는 특성들 그리고 그들 간의 관계를 절충한다. "
소프트웨어 아키텍처는 소프트웨어를 구성하는 컴포넌트와 컴포넌트의 관계를 추상적인 수준에서
정의한다. 소프트웨어 전체 구조를 한눈에 볼 수 있게 해주면, 각 컴포넌트와 컴포넌트 사이의
관계에 대한 이론적 근거를 판단할 수 있다. 소프트웨어 아키텍처는 소프트웨어에 대한 이해를
돕고 시스템 수준의 설계 모델을 재사용할 수 있게 해주며, 품질 요구사항을 반영할 수 있게
해주며, 소프트웨어 상세 설계 및 구현 이전 초기 설계 단계에서 소프트웨어가 가질 품질 요구사항을
예측할 수 있게 해준다.
소프트웨어 아키텍처가 중요한 이유는
 첫째, 이해 관계자와의 커뮤니케이션을 위하여 정의된 형상이자 표현의 수단이다. 소프트웨어
아키텍처를 통해 이해 관계자들(프로젝트 관리자, 품질 담당자, 개발자, 테스터, 고객등)은
보다 원활한 커뮤니케이션을 할 수 있다.
 둘째, 소프트웨어 아키텍처는 설계 방향의 가이드가 된다. 전체적인 관점에서 품질 속성을
고려하여 목표 시스템의 설계 방향을 조기에 결정할 수 있도록 지원하고, 향후 발생할 수
있는 위험요소를 감소시킬 수 있다.
 셋째, 재사용 가능한 시스템의 추상화를 제공함으로써 소프트웨어 아키텍처가 시스템을
구성하는 요소와 이들간의 관계를 간략하고 명확하게 나타낼 수 있다. 따라서, 비슷한 기능과

8 SEC-2014-RM005
품질 요소를 가지는 다음 시스템에서의 큰 규모의 재사용이 가능하고, 소프트웨어 조직의
자산(asset)으로써 재사용 또한 용이해진다.
소프트웨어 아키텍처는 요구사항을 제대로 구현하기 위해 도움을 줄 수 있는 커뮤니케이션
툴이자 개발 초기의 요구사항과 실제 솔루션간의 간극을 좁혀줄 수 있는 휼륭한 도구이기도
하다.
[그림 1-1] 소프트웨어 아키텍처의 역할]
1) 소프트웨어 아키텍처는 소프트웨어 요소를 정의한다.
소프트웨어 아키텍처는 소프트웨어를 구성하는 기본적인 요소들 간의 관계 정보를 담고 있다.
이때 기본 요소들은 개발 단계에 따라 상세화의 수준이 달라질 수 있다. 즉, 초기 아키텍처링
단계에서는 추상적 수준의 요소들이었다가, 이후 개발 단계가 진행됨에 따라 상세화될 수 있다.
이러한 속성을 “아키텍처 추상화(Architecture Abstraction)”이라고 한다. 다시 말해 아키텍처는
특정 목적과 관련이 없는 요소의 자세한 정보를 생략할 수 있다. 또한 아키텍처 요소들 간의
관계는 인터페이스(interface)를 통해 상호작용을 표현할 수 있다. 일반적으로 인터페이스는
“공개 인터페이스”와 “비공개 인터페이스”로 구분할 수 있는데, 보통 공개 인터페이스만을 고려하고,
내부 소통을 위한 비공개 인터페이스는 아키텍처에 꼭 표시할 필요는 없다.
2) 시스템은 하나 이상의 소프트웨어 아키텍처로 구성될 수 있다.
시스템은 한개 이상의 소프트웨어 아키텍처를 포함할 수 있으므로, 어느 한 소프트웨어 아키텍처만을
소프트웨어 아키텍처라고 말할 수 없다. 예를 들어 구성단위와 실행 단위와 한 가지 이상의 연관
관계가 표시될 수 있고 (연관 관계, 병렬 프로세스를 동기화하는 연관관계 등), 한가지 이상의
시점이 존재할 수 있다.

p
9
3) 소프트웨어가 들어간 컴퓨팅 시스템에는 전부 소프트웨어 아키텍처가 있다.
매우 단순한 시스템인 경우에는 시스템 자체를 하나의 단일 요소로 볼 수 있다. 이것을
일반론적인 관점에서 소프트웨어 아키텍처라고 보긴 어렵지만, 그래도 소프트웨어 아키텍처라고
볼 수 있다.
4) 시스템 요소의 행위를 다른 요소에서 인식 할 수 있다면, 이는 소프트웨어 아키텍처로 표현될
수 있다. 외부에 드러나는 시스템 요소의 행위는 다른 시스템 요소와의 상호 작용 방법을
제시하므로 분명히 소프트웨어 아키텍처라고 할 수 있다
제 2절 소프트웨어 아키텍처 분석 목적 및 배경
1. 소프트웨어 아키텍처 분석 목적
시스템의 아키텍처에 대한 가장 중요한 사실 중 하나는, 비록 소프트웨어가 아직 개발이 되어
있지 않는 상황에서도 소프트웨어 아키텍처는 시스템의 중요한 요소에 대해서 표현하고 있다는
것이다. 소프트웨어 아키텍처를 바탕으로 이해관계자 및 아키텍트는 중요한 의사결정을 할 수
있게 될 뿐만 아니라 예상되는 사이드 이펙트(side effect), 위험요소 및 시스템 구성에 대한
예측을 할 수 있게 된다. 만약 소프트웨어 아키텍처가 없다면 이해관계자나 아키텍트, 혹은
관리자들이 쉽게 파악할 수 없는 소프트웨어에 대해서 특별한 해결책 없이 의사결정을 해야만
하고 그로 인한 위험이나 불확실성은 시스템의 규모가 크고 복잡해질수록 기하급수적으로
커지게 된다.
아키텍트가 소프트웨어 아키텍처를 파악할 수 있게 되면, 정교한 의사결정이 가능하게 되고,
우선순위화도 쉽게 결정할 수 있게 된다. 또한, 다양한 아키텍처의 팁 및 패턴의 적용이 가능
하여, 소프트웨어 시스템이 더욱 견고해지고 개발과 유지보수가 용이해 지게 된다. 이러한
이유로 소프트웨어 아키텍처는 “분석 가능한” 상태이어야 한다. 다시 말해, 소프트웨어 아키텍처가
분석 가능하면 이해관계자 및 아키텍트는 중요한 의사결정을 내릴 수 있을 뿐만 아니라, 성공하는
소프트웨어를 위한 다양한 전략 및 패턴의 적용이 가능하고, 개발자와 테스터들도 분석된 소프트웨어
아키텍처를 기반으로 개발 및 검증이 가능하여 보다 견고한 소프트웨어 시스템을 개발 및
배포할 수 있게 된다. 또한, 소프트웨어의 지속성 및 업데이트를 고려하여 다양한 소프트웨어
아키텍처의 발전 및 유지 보수가 가능하게 된다. 이러한 소프트웨어 아키텍처의 분석은 심지어
아직 개발이 완료되지 않은 소프트웨어에 대해서도 충분히 적용이 가능하다.

10 SEC-2014-RM005
[그림 1-2] 소프트웨어 아키텍처 분석]
정교한 의사결정 및 더욱 견고한 소프트웨어 시스템 개발을 위한 소프트웨어 아키텍처 분석의
목적은 아래와 같다.
소프트웨어 프로젝트에서 문제를 찾아내는 시기가 빠를수록, 더 나은 소프트웨어의 개발이
가능하고, 더 나은 소프트웨어 아키텍처의 설계가 가능하다.
만약 적합하거나 분석할 수 없는 소프트웨어 아키텍처를 설계하게 되면, 소프트웨어 시스템의
결과는 예측할 수 없을 정도로 망가졌거나 품질 불량을 가져오게 될 것 이다.
소프트웨어 시스템의 품질 불량에 대한 가장 큰 원인은 소프트웨어 아키텍처의 부재나 혹은 불량한
소프트웨어 아키텍처이고, 품질 불량은 소프트웨어 프로젝트 전체의 실패로 이어지게 된다.
소프트웨어 아키텍처 분석은 이러한 소프트웨어 프로젝트의 실패를 사전에 방지하기 위한
중요한 활동 중에 하나이며, 가장 비용이 적게 드는 활동이기도 하다.
2. 소프트웨어 아키텍처 분석 시점
일반적으로 가능한 이른 시점에 소프트웨어 아키텍처를 분석하면 할수록 비용절감의 효과를
크게 노릴 수 있다. 즉, 문제를 빨리 발견할수록 고치기가 쉬워지며 요구사항이나 스펙, 특징,
기능 등 필요한 부분에 쉽게 적용시킬 수 있다. 소프트웨어 품질은 프로젝트의 마지막 부분에
점검하는 것이 아니고, 가능한 시작점으로부터 시작되고 그 품질 검증이 프로젝트의 마지막까지,
테스트 마지막 시점까지 연결되고 상속되어야 한다.
소프트웨어 아키텍처를 분석하는 시기에 대해서는 특별히 정해진 단계나 프로세스는 없으나,

p
11
일반적으로 소프트웨어 아키텍처를 분석하기 위한 최적의 시점은 디자인 단계로 이야기된다.
그러나 소프트웨어 아키텍처 분석은 많은 단계에서 수행되면 다양한 문제점 분석 및 소프트웨어
아키텍처의 개선을 가져올 수 있기 때문에, 전체 소프트웨어 프로젝트 라이프 사이클 단계에서
몇 개의 지점을 선택하는 것이 좋다. 만약 소프트웨어 아키텍처가 아직 정해져 있지 않고 많은
의견이 오가는 단계이면, 여러 가지 의사 결정을 위해 소프트웨어 아키텍처 분석을 실시할 수
있고, 이미 소프트웨어 아키텍처가 정해지고 개발을 진행하는 단계라면, 개발이 소프트웨어 아키텍처를
잘 참조하여 개발하고 있는지 혹은 개발에 문제가 있거나 다시 고려해야 할 아키텍처 요소가
없는지, 아니면 소프트웨어 아키텍처를 재설계할 필요가 있는지를 파악하기 위해서 분석을 실시
할 수 있다. 이미 개발되고 완료된 소프트웨어 프로젝트나 레거시 코드라면 소프트웨어 아키텍처를
분석을 통해서 기존 아키텍처를 쉽게 파악하면서, 개선이나 유지보수가 필요한 점을 찾을 수도
있고, 재활용한 컴포넌트나 구조에 대해서 자산화(asset)을 할 수 있다. 그리고 다른 시스템이나
다른 구조로 적용(porting)을 위한 레거시 시스템의 분석 기준으로도 삼을 수 있다.
결국, 소프트웨어 아키텍처 분석은 소프트웨어 시스템이 품질 속성이나 시스템의 요구사항을
어떻게 잘 만족시키고 있냐를 다수의 사람들이 쉽게 이해하고 파악할 수 있는 최고의 발굴 행동
이라고 할 수 있다.
더군다나, 만약에 매우 크고 긴 개발기간을 가진 소프트웨어 시스템이라면, 개발팀이 소프트웨어
아키텍처 분석을 통해서 전체적인 큰 그림과 디자인을 파악하고, 후보 아키텍처와 트레이드
오프에 대해서 상호 토론을 통해서 발전시켜 나가는 것이 매우 중요하다. 이러한 것을 통해서
개발팀은 중요한 품질(속성)에 대한 팀의 의견을 통일 시키고 지속성장 가능한 소프트웨어
아키텍처를 유지, 발전 시켜나갈 수 있게 된다.
3. 주요 소프트웨어 아키텍처 분석 방법
소프트웨어 아키텍처를 분석하는 방법은 크게 정방향 분석 방법과 역방향 분석 방법, 두 개의
분류로 나눌 수 있다. 정방향 분석 방법으로는 미국 카네기 멜론 대학의 SEI 에서 제세한 소프트웨어
아키텍처 평가 방법(예. ATAM, CBAM 등)이 가장 많이 그리고 활발히 사용된다. 역방향 분석
방법으로는 PMD 나 reverse engineering 툴 등 시스템 개발 환경에 맞춘 다양한 툴을 활용하여
소스 코드로부터 소프트웨어 아키텍처를 분석하는 방법이 있다.
일반적으로 기존 소스 코드 없이 요구사항 등을 가지고 프로젝트 초반에 소프트웨어 아키텍처
분석을 실시할 때는 정방향 분석을 주로 실시하고, 레거시 코드나 기존 시스템이 있는 경우에는
역방향 분석을 통해서 기본 아키텍처를 분석/도출한 후에 소프트웨어 아키텍처 분석을 수행한다.
각 방법 및 사례에 대해서는 제 2 장 ~ 3 장에서 자세히 다루도록 하겠다.

12 SEC-2014-RM005
제 3절 소프트웨어 아키텍처 분석의 장점
소프트웨어 아키텍처 분석을 수행하게 되면 얻을 수 있는 일반적인 장점들은 아래와 같다.
1. 비용 절감 측면
초기에 소프트웨어 아키텍처 분석을 수행하게 되면 가장 먼저 얻을 수 있는 장점이 비용
절감이다. 특히 고객과 이해관계자가 참석하여 소프트웨어 아키텍처 분석을 수행하게 되면 고객들이
생각하는 가치나 사용자의 가치에 대해서 충분히 토론을 하게 되면서, 해당 품질 속성이나
소프트웨어의 가치가 아키텍처에 반영될 수 있게 된다.
만약 프로젝트 중/후반에 소프트웨어 아키텍처 분석을 하게 되어 그때 고객이나 사용자의 추가
요구사항이나 가치들이 반영이 되여야 하게 되면, 변경에 따른 비용적인 부담이 만만치 않게
일어나게 되기 때문에, 비용절감의 장점을 최대한 누리기 위해서는 프로젝트 초반에 소프트웨어
아키텍처 분석을 수행하여 아키텍처 변경에 따른 여러 가지 사이드 이펙트나 추가 고려사항도
점검을 하도록 하는 것이 좋다.
2. 프로젝트 참여자들의 이해도 향상
소프트웨어 아키텍처 분석 절차를 통해서 얻을 수 있는 두 번째 장점은 이해관계자 및 개발팀이
아키텍처에 대해서 반강제적으로 리뷰를 할 수 있게 된다는 점이다. 아직도 많은 소프트웨어
시스템들은 개발자들이 소프트웨어 아키텍처 설계에 참여하지 않을 뿐만 아니라, 본인이
개발하고 있는 소프트웨어 시스템의 아키텍처에 대해서 제대로 이해하지 않고 있다. 소프트웨어
아키텍처 분석 절차를 통해서 이러한 개발자들이 참여를 해서 소프트웨어 아키텍처 설계를 같이
리뷰하고 의사결정 포인트에 대해서 토론을 하며, 더 나은 대안을 찾으려 하기 때문에 해당
소프트웨어 아키텍처에 대한 이해도가 높이 올라가는 효과를 볼 수 있다. 또한, 개발 중이나
레거시 시스템의 역방향 분석을 통해서 개발하는 소프트웨어에 대한 구조적인 문제가 없는지, 더
나은 대안은 없는지 빠르게 파악할 수 있으며, 개발 중인 소프트웨어가 소스 코드에 대한 잠재적인
위험 요소와 문제에 대해서 쉽게 파악할 수 있어서, 더 견고하고 안정적인 소프트웨어의 개발이
가능하게 된다. 더불어 개발자들과 아키텍트 사이, 그리고 이해관계자 및 고객과 아키텍트
사이의 커뮤니케이션 오류도 많이 줄어드는 효과를 볼 수 있다.
3. 논리적인 소프트웨어 아키텍처 설계
소프트웨어 아키텍처 분석은 매우 특별한 질문에 대답하기 위한 특별한 분야에 집중이 된다.

p
13
다시 말해서, 이러한 특별한 질문에 대답하기 위해서는 논리적인 설계 및 디자인의 근거가
있어야 하고, 그 의사결정이나 디자인이 최선의 선택이어야 한다. 실제로 소프트웨어 아키텍처
설계를 할 때는 많은 트레이드 오프가 발생을 하게 되는데, 그때의 의사 결정에 대한 논리적이고
합당한 근거가 필요하게 된다. 이러한 논리적이고 합당한 아키텍처의 근거는 추후 설계나 디자인
변경이 발생할 경우, 혹은 요구사항이 급변하여 소프트웨어 아키텍처에 대한 재검토가 이뤄졌을
경우 매우 효과적으로 활용할 수 있게 된다.
4. 문제점의 빠른 발견 및 해결
위에서 언급한 것처럼, 초기에 소프트웨어 아키텍처 분석을 통해서 문제점을 발견하고 그것을
고친 경우 비용절감은 프로젝트 후반부에 문제점을 발견하고 수정한 것에 비해서 몇 배나 비용
절감의 효과를 가져 온다.
소프트웨어 아키텍처 분석을 수행하게 되면 논리적이지 않은 요구사항, 소프트웨어 퍼포먼스
등 품질 속성에 대한 문제, 잠재적인 위험 요소에 대한 문제들을 발견할 수 있게 되는데, 이러한
것들 통해서 아키텍트나 개발자들은 해당 소프트웨어 시스템이 가지고 있는 잠재적인 문제나
제약사항 등에 대해서 조기에 발견하고 대응할 수 있게 된다. 또한, 소프트웨어 아키텍처 분석을
통해서 해당 소프트웨어 시스템의 성능/역량등에 대해서 파악이 가능하므로 구현이나 예외처리
관련 디자인에 더 좋은 힌트를 얻을 수 있게 된다.
5. 요구사항 검증
소프트웨어 아키텍처 분석 절차를 통해 아키텍처가 얼마나 요구사항을 잘 만족 시키고 있는지에
대한 활발하고 열린 토론이 일어난다. 어떤 설계와 디자인이 요구사항에 대한 명확한 이해를
바탕으로 하고 있는지 파악할 수 있고, 우선순위가 잘 설정이 된 것인지 파악할 수 있다.
일반적으로 프로젝트 초반에 대화나 토론 없이 진행되는 요구사항의 아키텍처에 대한 반영은
다른 디자인과 충돌을 일으키는 경우가 종종 있기 때문에, 소프트웨어 아키텍처 분석을 통해서
해당 요구사항에 대한 객관성을 명확히 할 필요가 있다. 소프트웨어 아키텍처 분석을 통해서
다양한 요구사항을 자연스럽게 검증할 수 있고, 그것에 따른 디자인적인 충돌, 트레이드 오프
등을 파악 및 결정할 수 있다.
6. 소프트웨어 아키텍처 설계 품질 향상
소프트웨어 아키텍처 분석을 통해서 도출한 잠재적인 위험 요소, 성능 향상을 위한 요소 등의
개선을 통해 전체적인 소프트웨어 아키텍처 설계의 품질을 향상시킬 수 있다. 이해관계자와

14 SEC-2014-RM005
개발자들의 참여를 통해서 여러 가지 이슈나 요구사항에 대한 즉각적인 토론이 이뤄지며, 그러한
문제들의 해결과 결과를 통해서 소프트웨어 시스템의 성능/역량 향상으로 연결이 된다. 더불어,
이러한 개발문화를 통해서 개발 초기 단계뿐만 아니라 개발 중간 단계에서도 다양한 분석, 개선
및 입력을 통해서 시스템 전체의 품질 향상을 가져올 수 있다.

p
15
제 2 장 소프트웨어 아키텍처 정방향 분석
제 1절 소프트웨어 아키텍처 정방향 분석 개요
제 1 장에서 짧게 언급한 것처럼 소프트웨어 아키텍처를 분석하는 방법은 크게 정방향 분석
방법과 역방향 분석 방법으로 나눌 수 있다. 정방향 분석은 아키텍쳐 평가 방법을 활용하여
소프트웨어 아키텍처를 분석하거나 소프트웨어 아키텍처 뷰를 활용하여 설계된 아키텍처를
분석하기도 한다.
가장 널리 알려진 정방향 분석 방법으로는 미국 카네기 멜론 대학의 SEI 에서 제세한
소프트웨어 아키텍처 평가 방법(예. ATAM, CBAM 등)이 있다. 전 세계적으로 가장 많이
그리고 활발히 사용되는 중이고, QAW 및 다른 방법론과 병행하여서 소프트웨어 아키텍처를
분석 및 평가하는데 사용되기도 한다.
소프트웨어 아키텍처의 정방향 분석 후 결과는 의사 결정에 중요한 포인트가 되며, 트레이드
오프를 통해서 해당 소프트웨어 시스템의 디자인을 결정하는데 사용된다. 일반적으로 기존 소스
코드 없이 요구사항 등을 가지고 프로젝트 초반에 소프트웨어 아키텍처 분석을 실시할 때는
정방향 분석을 주로 실시 하고, 레거시 코드나 기존 시스템이 있는 경우에는 역방향 분석을
통해서 기본 아키텍처를 분석/도출한 후에 소프트웨어 아키텍처 분석을 수행한다.
정방향 분석 방법은 주로 소프트웨어 아키텍처를 평가하는 방법을 기반으로 분석을 한다.
소프트웨어 아키텍처 평가는 소프트웨어 아키텍처의 잠재적인 위험요소나 품질 요소, 비기능
요구사항등을 인지하고 분석하여서 해당 소프트웨어 시스템에 적합한 디자인을 가능하게 한다.
[그림 2-1] 다양한 아키텍처 뷰

16 SEC-2014-RM005
제 2절 소프트웨어 아키텍처 정방향 분석의 목적
일반적으로 소프트웨어 아키텍처 정방향 분석을 하는 목적은 크게 해당 아키텍처의 완결성과
일관성을 유지시키고, 사전에 문제점 및 잠재 위험요소를 파악하는 것에 있으며, 이해관계자와
아키텍트, 개발자와 테스트등 프로젝트 참여자들간의 커뮤니케이션을 향상시키고 공감대를 끌어
내는 것에 그 목적이 있다.
소프트웨어 아키텍처를 분석함에 있어서, 해당 소프트웨어 시스템의 외적 완결성과 내적
완결성을 추구하게 되는데, 외적인 완결성은 시스템의 요구사항과 관련된 것으로써, 거대한
소프트웨어 시스템의 요구사항이나 아키텍처의 복잡성을 해결하기 위한 노력이고, 아키텍처뿐만
아니라 복잡한 요구사항을 기록하고 추적하기 위한 많은 범례 및 기호들을 해결하려는 노력이다.
내적인 완결성은 소프트웨어 아키텍처의 경향이나 잠재적인 의도에 관한 것인데, 각 소프트웨어
아키텍처의 관련된 기호나 연결이 제대로 표현되고 모델화 되었냐를 해결하기 위한 노력이고
주요 의사 결정사항에 대한 기록이나 근거가 소프트웨어 아키텍처에 제대로 표현이 되었냐를
확인하기 일련의 행위이다. 소프트웨어 아키텍처의 내부 요소에 대한 일관성을 유지하는 것은 각
모델이나 디자인, 아키텍처의 요소가 충돌이나 혼란을 가져오기 않게 하기 위함인데, 특히 이름,
인터페이스, 행위, 상호교류 등에 대해서 전체 소프트웨어 아키텍처의 일관성을 유지하는 것이
매우 중요하다.
프로젝트 초반이나 개발 초기 단계에서 소프트웨어 아키텍처 평가 방법을 활용하여 소프트웨어
아키텍처를 분석함으로써 소프트웨어가 구체적으로 실체화/구현화/테스트 되기 이전에, 현재의
소프트웨어 아키텍처의 적합성 여부를 분석해 수정/보완함으로써 차후의 적합하지 않은
소프트웨어 아키텍처를 채택함으로 인해 생길 수 있는 위험을 최소화하는 것이 소프트웨어
아키텍처 정방향 분석의 가장 주요한 목적이라고 할 수 있다.
제 3절 소프트웨어 아키텍처 평가/분석(ATAM)
1. 개요
Architecture Tradeoff Analysis Method(이하 ATAM)은 미국 카네기 멜론 대학의 SEI
연구소에서 제시한 소프트웨어 아키텍처 분석을 위한 방법으로 아키텍처가 특정 품질 목표를
만족하는지 여부와 품질 목표들간에 발생하는 충돌에 대해서 분석하는 평가 기법이다.
아키텍처가 처음에 의도했던 방향대로 제대로 설계되었는지를 검증하는 분석 방법이며 설계된

p
17
아키텍처가 시스템 성능, 가용성, 확장성 등과 같은 비기능 요구사항에 대한 항목에 대해 초기에
의도했던 품질 목표를 만족시키고 있는지 분석하고, 여러 가지 품질 목표가 상호간에 어떻게
작용하는지 파악하는 것이 주요 역할이다.
• ATAM 은 일반적인 아키텍처 분석 방법과 유사하지만, 특히 다음과 같은 점이 중요하다.
• 이해 당사자의 능동적이고 적극적인 참여
• 핵심 이해 당사자의 충분한 준비
• 아키텍처디자인 이슈와 분석 모델에 대한 이해
• 비기능 요구사항에 대한 명확한 정리
품질 목표들간에 충돌을 프로젝트 초기(요구사항 정의 또는 설계 단계)에 알아냄으로써 비교적
경제적인 방법으로 문제를 해결할 수 있고 변경, 다른 시스템과의 통합, 업그레이드 등이 필요한
레거시 시스템을 분석하는데도 사용할 수 있다.
[그림 2-2] ATAM 개념도
2. ATAM 수행 목적
아키텍처 평가의 목적은 설계된 아키텍처의 결함을 확인하고, 비기능 요구사항의 관점에서
평가하는 것이 목적이며 아키텍처의 잠재적인 위험 요소를 감지하는 도구 역할을 한다. 또한
아키텍처의 중요성을 일깨우고 아키텍처와 관련된 산출물의 수준을 높이는 것과 함께 아키텍처
분석 시 위험요소, Trade-off 요소 등에 대해 파악하고 향후 개선안을 도출하는 것이 이 평가의
중요한 목표이다.
• ATAM 을 통해서 아래의 질문에 대한 대답을 얻을 수 있다.

18 SEC-2014-RM005
• 현재 소프트웨어 아키텍처가 요구사항, 특히 비기능적 요구사항(Architectural Requirement,
Quality Attribute)을 만족하도록 설계되었는가?
• 현재 소프트웨어 아키텍처가 내포하고 있는 위험(Risk)는 무엇인가?
• 여러 개의 소프트웨어 아키텍처 대안이 있을 경우, 어느 것이 가장 적합한가?
즉, ATAM 을 통해 비기능 요구사항에 대한 자세한 분석, 아키텍처의 결정사항에 대한 이해,
그리고 그 결정사항이 요구사항을 만족시킬 수 있는지를 분석할 수 있다.
3. ATAM 의 주요 장점
ATAM 을 수행함으로써 얻을 수 있는 주요 이점은 다음과 같다.
• 품질 속성 요구사항을 명확히 할 수 있다
• 아키텍처 문서화를 향상 시킬 수 있다
• 아키텍처 의사 결정의 주요한 기준을 도출해 낼 수 있다
• 프로젝트 초반 혹은 제품의 전체 라이프 사이클의 초기에 위험 요소를 파악 할 수 있다
• 이해관계자들 간의 커뮤니케이션을 원할 히 하는데 도움이 된다.
즉, ATAM 은 소프트웨어 개발 주기의 초기 단계에서 수행할 수 있으며, 구현이 아닌 설계된
디자인을 평가하기 때문에 상대적으로 비용이 저렴하고 빠르다는 것이 장점이다.
4. ATAM 주요 절차
[그림 2-3] ATAM 수행 절차

p
19
가. Present the ATAM
평가팀이 모든 이해 관계자에게 평가 절차에 대해서 설명하는 단계이다. 평가 자체에 대한
설명 및 평가를 진행하는 동안 지켜야 할 여러 가지 규칙에 대해서 설명한다. 참여자에게 평가를
통해 얻을 수 있는 기대사항 등을 질의하며, 평가팀 멤버의 역할 및 다른 참여자의 역할에 대해
설명한다. 평가가 진행되는 동안 생성되는 유틸리티 트리, 시나리오, 아키텍쳐 접근 방법, 아키텍쳐
분석을 위한 기술 및 위험요소, Trade-off 목록에 대해서 자세히 설명하여 적극적인 참여를 유도
한다.
나. Present the Business Drivers
프로젝트의 PM 이 비즈니스 관점에서 평가팀에게 시스템에 대해서 설명하는 단계이며 다음의
사항을 위주로 설명한다.
• 가장 중요한 기능적 요구사항
• 기술적, 관리적, 정치적 제약사항
• 비즈니스 목표
• 중요한 이해관계자
품질 목표를 만족시키기 위한 아키텍쳐의 중요사항 평가팀은 비즈니스 드라이버 소개를 듣고
난 후 평가될 시스템의 범위를 정하고, 언급된 이해 관계자, 중요 품질 목표, 제약사항 등을
이해하고 목록을 작성한다.
다. Present the Architecture
아키텍트가 평가팀에게 아키텍쳐에 관해서 가능한 자세하게 설명하는 단계이다.
• OS, 하드웨어, 미들웨어 등 이미 결정된 기술적인 제약사항
• 연동해서 사용해야 하는 다른 시스템
• 품질 요소를 만족시키기 위해 사용한 아키텍쳐 접근 방법
절차 기록자는 아키텍트가 설명할 때 중요 부분을 기록한다.
평가팀은 소개된 아키텍쳐 접근 방법, 잠재 위험요소, 추가적인 이해 관계자의 역할 등을
이해한다.

20 SEC-2014-RM005
라. Identity the Architectural Approaches
‘가. Present the Architecture’에서 소개된 아키텍쳐 고유의 접근 방법과 아키텍쳐 스타일을
파악하는 단계이다.
아키텍쳐 접근방법을 확인하는 방법으로는 S/W 아키텍트에게 질의할 수도 있으며 각각의
평가팀 멤버에게서 투표로써 접근방법을 조사할 수도 있다. 시나리오 기록자는 파악된 아키텍쳐
접근 방법을 기록한다.
마. Generate the Quality Attribute Utility Tree
평가팀, 아키텍쳐 팀, 프로젝트 매니저 등이 협력하여 유틸리티 트리를 작성하는 단계이다.
[그림 2-4] 유틸리티 트리의 예
이 단계에서 만들어진 유틸리티 트리는 이후의 평가 스텝에서 가이드 역할을 하며 분석의
목표를 구체화하는 효과를 기대할 수 있다.
유틸리티 트리를 통해 평가팀이 아키텍쳐의 어느 부분에 집중해야 할지 등을 파악하고 평가의
범위를 결정하는 데 도움이 된다.
바. Analyze the Architectural Approaches
유틸리티 트리를 통해 평가 범위를 결정한 후, 아키텍쳐 접근 방법과 결정사항을 평가하는
단계로 아키텍쳐의 중요한 부분을 알아낸다.

p
21
이 단계의 가장 중요한 결과물은 Risk, Sensitivity point, Trade-off 등이며, 이들을 유틸리티
트리의 시나리오와 연계하여 품질요소에 대해 평가한다.
[그림 2-5] 유틸리티 트리 작성
사. Brainstorm and Prioritize Scenarios
전체 이해 관계자로부터 시나리오를 생성하는 단계이다. 이 시나리오는 전체 이해관계자가
참여하는 투표 프로세스를 통해 우선순위가 정해진다.
유틸리티 트리는 시나리오를 생성하기 위한 하향식 메커니즘을 제공하는 반면에, 시나리오
Brainstorming 은 상향식 접근법으로 시나리오를 생성하는 것이다.
평가 리더는 이해 관계자가 차례로 시나리오에 대해 말할 수 있도록 라운드로빈 방식으로
진행시킨다. 시나리오 기록자는 Brainstorming 결과를 기록하여 전 참여자가 볼 수 있도록
게시한다. 참여자는 게시된 시나리오 결과에 대해 토론하여 합치거나 삭제하여 시나리오를 정제
한다. 시나리오가 결정된 후 투표를 실시한다. 결정된 시나리오의 수의 30%의 투표권을 할당
한다.
아. Analyze the Architectural Approaches
테스크 2 에서 선정된 높은 우선순위의 시나리오를 분석한다. 부가적인 아키텍처 접근 방법,
위험 요소, 민감 요소 등을 찾아낸다.
자. Present the Results
스텝 1~2 를 통해 수행한 평가 결과에 대해 최종 보고서를 작성 한다.

22 SEC-2014-RM005
제 3 장 소프트웨어 아키텍처 역방향 분석
제 1절 소프트웨어 아키텍처 역방향 분석 개요
아키텍처 정방향 분석 방법들을 이용하여 개발할 프로젝트의 아키텍처를 정립 후 실제 개발을
하게 되면 처음 의도와는 다른 방향으로 바뀔 가능성이 존재하며, 이에 따라서 원치 않았던
잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는
상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의
아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해 나가야만 한다. 이러한 소프트웨어
시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스
코드를 분석하여 파악하는 방법들이 존재한다.
소프트웨어 시스템의 아키텍처를 파악하기 위한 방법 중 가장 단순한 방법은 바로 소스
코드를 모두 살펴보는 방법을 사용할 수 있다. 하지만 코드 전체를 살펴보는 방법은 소프트웨어
시스템을 자세하게 분석하기 때문에 세부적인 내용에 대해서 확실하게 파악할 수 있지만, 분석에
매우 많은 시간이 걸리기 때문에 빠르게 아키텍처를 파악하기 위한 방법으로는 매우 부적절하며,
또한 소프트웨어 시스템을 너무 세부적으로 바라보기 때문에 전체적인 아키텍처를 그리기가
힘들어져서 아키텍처의 문제점과 문제를 발견하지 못할 가능성도 높아진다.

p
23
[그림 3-1] 개발 중 클래스 다이어그램을 통해서 분석하는 것에는 한계 존재
소스 코드 리뷰 말고 또 다른 분석 방법으로는 클래스 다이어그램을 이용할 수 있다. 이 방법은
앞서 소개한 코드 분석에 비해서 큰 시점에서 바라보기 때문에 소프트웨어 시스템의 아키텍처의
큰 그림을 그리기에 비교적 용이하며, 비교적 빠르게 분석할 수 있다. 하지만 너무 큰 시점에서
분석하기 때문에 한정적인 정보(상속, 포함)만 얻을 수 있어, 좀 더 자세한 소프트웨어 시스템의
아키텍처적인 문제점과 문제들을 파악하기에는 무리가 있다.
위에서 제기 하였던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나,
너무 좁은 범위에서만 보아서 생기는 것이다. 그렇기 때문에 적절한 수준에서 소프트웨어
시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할
수 있게 된다. 그렇기 때문에 실제 프로젝트를 개발하는 중에는 아키텍처를 분석하기 위해서는
위에서 설명한 방법들을 적용하는 것보다는 실제 프로젝트의 산출물인 코드를 이용하여 분석하여
가공된 정보들을 추출하여 소프트웨어 시스템의 아키텍처를 분석하게 되면 앞서 이야기 했던
분석 방법들보다 좀 더 적절하게 문제에 대응할 수 있게 된다. 그리고 이렇게 실제 소스 코드에서

24 SEC-2014-RM005
정보를 추출하여 아키텍처를 분석하는 방법을 아키텍처 역방향 분석 방법이라고 한다.
아키텍처 역방향 분석 방법은 앞서 이야기 한 것처럼 실제 결과물에서 정보들을 추출하여
분석하는 방법으로 코드의 일정한 기준을 정하여 특정 요소에 대하여 수치를 부여하여 이를
분석하는 지표 분석 방법과 실제 결과물내의 존재하는 다양한 컴포넌트간의 관계들을 추출하여
관계적 문제점(상호참조, 영향력 등)을 분석하는 관계 분석 방법, 그리고 지표 분석 방법과 관계
분석 방법에서 나온 결과들을 이용하여 복합적으로 분석할 수 있는 시각화 자료를 생성하여
다각도적으로 아키텍처를 분석할 수 있게 해주는 시각화 분석 방법이 존재한다.
[그림 3-2] 아키텍처 역방향 분석 방법의 구성
이번 장에서는 이러한 아키텍처 역방향 분석 방법들의 장단점과 지표 분석과 관계 분석, 그리고
시각화 분석 방법들이 구성되는 원리들과 이렇게 구성된 정보를 바탕으로 현재 프로젝트가
당면하고 있는 문제가 어떠한 것인지 분석할 수 있는 방법들에 대하여 구체적으로 소개하겠다.

p
25
제 2절 소프트웨어 아키텍처 역방향 분석의 특징
1. 소프트웨어 아키텍처 역방향 분석의 주요 특징 및 장점
아키텍처 역방향 분석을 프로젝트 진행 중에 이용하게 된다면, 우선 코드를 직접 분석하지 않고
프로젝트가 가지고 있는 잠재적인 문제들, 즉 컴포넌트간의 의존성이나 복잡성들을 최소한으로
줄일 수 있게 해주며, 더 나아가서는 코드의 품질 수준을 높여 프로젝트의 유지 보수를 보다
쉽게 만들어 준다. 그리고 실제 개발을 담당하는 프로그래머가 아닌 기획자나 다른 관리자들도
현재 프로젝트가 당면한 현 상황의 문제를 손쉽게 파악할 수 있도록 도와줘서 프로젝트의 진행
상황을 모두와 공유할 수 있게 도와준다.
또한 아키텍처 역방향 분석은 앞서 이야기한 것처럼 프로젝트의 품질을 관리하는 기능뿐만
아니라 구성에 대한 시각화 정보들과 다른 정보들을 참고하여 자신이 관여하지 않은 다른
프로젝트의 구성에 대한 이해하는데 도움을 줄 수 있다.
[그림 3-3] 소스코드에서 보기 힘든 문제를 적절한 뷰를 통해 가공하여 보여 준다

26 SEC-2014-RM005
2. 소프트웨어 아키텍처 역방향 분석의 단점
여러 장점을 가지고 있는 아키텍처 역방향 분석에도 몇 가지 단점을 가지고 있는데, 아키텍처
역 방향 분석 방법이 기본적으로 실제 프로젝트의 소스 코드를 기반으로 아키텍처를 분석하는
만큼 분석의 범위가 프로젝트의 소스 코드로 한정되어지기 때문에 프로젝트에 영향을 주는 다양한
요소들, 즉 DataBase 의 구성이나 데이터 통신 방법등 소스코드에서 얻기 힘든 코드 외적인
요소들에 대한 내용들은 파악하는데 무리가 있다. 그렇기 때문에 소스 코드에서 얻을 수 없는
다른 정보들은 다른 분석 방법들을 통하여 문제점을 파악해야할 필요성이 있다.
또한 아키텍처 역방향 분석은 일반적인 문제들에 대하여 분석결과를 제공하기 때문에 실제
현장에서 일어날 수 있는 다양한 트레이드 off 를 제대로 반영하지 못한다는 단점이 있다. 그렇기
때문에 아키텍처 역방향 분석으로 나온 결과를 해석할 때, 분석한 프로젝트의 성격과 특성들을
고려하여 내용을 이해해야 분석으로 인한 문제 해결의 효율을 극대화 시킬 수 있을 것이다.
장점 단점
- 코드를 직접 분석하지 않고 문제를 파악할 수 있다.
- 의존성이 적은 코드를 구성할 수 있다.
- 코드의 품질이 올라가 유지 보수가 쉬워진다.
- 정량적으로 문제들이 표시되어 프로그래머가
아닌 사람들도 문제를 파악할 수 있다.
- 코드의 이해도를 높일 수 있다.
- 소스 코드에 한정된 단편적인 뷰만을 제공한다.
- 실제 현장에서 발생하는 다양한 트레이드 off 들을
제대로 반영하지 못할 수 있다.
[그림 3-4] 아키텍처 역방향 분석의 장점과 단점]

p
27
제 3절 도메인 분석을 활용한 소프트웨어 아키텍처 분석
1. 도메인 개요
소프트웨어 시스템의 소스코드는 MECE(Mutually Exclusive and Collectively Exhaustive)이라는
대 전제 하에 기반으로 작성되어있다. MECE 란, 항목들이 상호배타적이면서 모였을 때는 완전한
전체를 이루는 것을 의미한다. 이를테면, 자바 소스코드에서 필드와 메서드가 서로 겹치지 않고,
모였을 때는 클래스를 이루고, 또한 클래스들은 서로 겹치지 않고 모였을 때 패키지를 이룬다. 이처럼
도메인이란 소프트웨어 시스템이 가진 기본속성 MECE 를 기반으로 사람이 인식하기 쉽게 적절한
레벨링을 하는 것을 의미한다.
소프트웨어 시스템의 아키텍처를 분석하고자 할 때 객체지향언어로 작성된 코드를 세분화시켜
(매서드, 필드로만) 분석하게 되면, 의존성, 지표를 계산 하더라도 그 결과는 사용자가 보기에
너무 복잡하다. 예를 들면 아래 그림과 같다.
[그림 3-5] 복잡한 아키텍처 분석도

28 SEC-2014-RM005
또한 세분화 시키지 않고 분석하게 되면, 사용자에게 보여줄 수 있는 정보가 매우 적어진다.
그렇기 때문에 사람들이 인지할 수 있는 적절한 레벨로 도메인을 나누어야 한다.
이때 소스코드의 도메인을 잡는 기준은 누구나 보아도 쉽게 이해 할 수 있는 단위어야 한다.
소프트웨어 시스템의 소스코드는 MECE 원칙을 기본으로하여 구분되는 단위로 작성되어있기 때문에
도메인의 기준은 소스코드에 내포되어있다. 이러한 소스코드에 내포된 도메인 기준을 사람들이
이해할 수 있는 단위로 그대로 사용한다. 객체지향언어의 한 종류인 JAVA 를 예로 들면 Method,
Class, Package, Package Set, Project, Workspace 6 개의 도메인으로 나누도록 한다. 또한
나눠진 각각의 도메인들은 Tree 구조로 나타낼 수 있다.
 Method & Field : Class 를 이루는 구성 요소들이다. Field 는 Class 내에서 사용 되는
변수들이고 Method 는 클래스에서 사용하는 함수들이다.
 Class : 의존성 분석에 있어서 가장 기본이 되는 단위로 Method 와 Field 가 모여서
SRP(Single Responsibility Principle)의 원칙을 따르는 하나의 일을 하는 단위이다.
 Package : 연관된 Class 들이 모여서 서로 상호 작용하여 복합적인 요구사항을 처리한다.
 Package Set : 연관된 Package 들 끼리 모여 작은 서브 시스템을 이룬다.
 Project : Workspace 의 일부로 소프트웨어 시스템에서 각각의 역할을 맡은 컴파일 되는
단위의 서브 시스템이다.
 Workspace : 소프트웨어 시스템으로 완전한 하나의 소프트웨어를 뜻한다.
[그림 3-6] 도메인 트리 구조도

p
29
이렇게 도메인을 나누면 코드를 단계별로 분석할 수 있게 되며, 사용자는 적절한 단계의 분석
결과를 볼 수 있어 직관적인 이해가 가능하게 된다. 그렇기 때문에 소프트웨어 아키텍처 역방향
분석을 하기위해서 가장 먼저 해야 할 작업은 소프트웨어의 도메인을 구분하는 것이다. 앞으로
설명할 용어를 설명하기위해 도메인 나누기를 통해 나눠진 각각의 Method, Class, Package 등을
엘리먼트 또는 노드라고 지칭하겠다.
2. 도메인 나누기 구현
도메인 나누기를 구현하기위해 JAVA 를 기준으로 설명하도록 하겠다.
￭ 기본 절차
 1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다.
 2 단계: Top-down 방식으로 클래스, 메소드 도메인을 구한다.
 3 단계: 반면 패키지묶음, Project, Workspace 도메인은 Bottom-up 방식으로 구한다.
예제 소스 코드
package ABC;
class A{
int B;
void C(void){
int D;
}
}
￭ 절차 설명
- 1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다. 추상구문트리는
소스 코드 의미 단위로 나누어 노드로 나타낸 트리이다. 앞에서 언급하였던 예제 소스
코드를 추상 구문 트리로 변환한다면 다음의 그림과 같다.

30 SEC-2014-RM005
[그림 3-7] 변환된 추상 구문 트리
- 2 단계: Top-down 방식으로 클래스, 메소드 도메인을 구한다. 코드파일을 추상구문트리로
변환하였기 때문에 클래스가 추상구문트리의 상위노드에 해당 한다. 따라서 트리구조상
패키지 도메인이 가장 먼저 구해지며 다음으로 클래스, 메소드 도메인을 구한다.
[그림 3-8] TopDown 방식으로 도메인을 분류

p
31
- 3 단계: 반면 패키지묶음, Project, WorkSpace 도메인은 Bottom-up 방식으로 구한다.
하나의 추상구문트리 탐색이 끝날때마다 클래스 도메인의 패키지 정보, 서브 시스템 정보를
이용하여, 부모 도메인을 구한다. 이러한 방식으로 도메인이 구해지는 이유는, 추상구문트리가
코드파일을 단위로 만들어지기 때문이다.
3. 소프트웨어 의존성 분석
가. 소프트웨어 의존성 개요
각각의 도메인들은 서로 간의 확실한 경계를 가지고 상호 배타적이다. 도메인끼리 서로 아무
의존성이 없으면 소프트웨어 시스템을 구성하는 것은 불가능하다. 그래서 도메인끼리 서로 간의
의존성을 가지고 있고 이러한 의존성과 도메인이 모여서 하나의 서브시스템을 이룬다. 이처럼
도메인 사이의 의존성은 서로 다른 경계를 가진 도메인을 이어 하나의 서브시스템이 되게
해준다.
아키텍처를 파악하기 위해서는 도메인들 사이의 정확한 의존성을 파악해야 한다.
도메인을 나누기는 소프트웨어 내의 의존성을 분석하기위한 기본 수단이었다. 따라서 단순
도메인 나누기로는 각각의 도메인들의 의존성과 관련된 정보들을 포함되지 않아 정확한 아키텍처를
분석하는데 어려움이 있다.
그렇기 때문에 도메인 사이의 모든 종류의 의존성을 정의해야 한다. 의존성을 가진 두
도메인의 레벨 및 정확한 이름을 파악해야 한다. 이를 위해 각 도메인 간의 모든 의존성을 파악
하고 정의한다. 소프트웨어 시스템 안에서 발생하는 서로 간의 상속, 포함 등을 모두 정확히 파악
해야 한다. Class 도메인의 하위 도메인 사이의 의존성을 정의하면 상위 도메인들은 하위 도메인들의
의존성을 기반으로 구성되기 때문에 모든 의존성을 파악 할 수 있다. 또한 명확한 의존성을
파악하기 위해서는 도메인 사이의 의존성 사이에서 Source 와 Target 을 정확히 알아야 하고 어느
레벨의 도메인인지 정확히 파악해야 의존성을 제대로 정의 할 수 있다. 대략적으로 소프트웨어
시스템의 의존성은 다음과 같은 기본 분류 기준에 따라서 분류된다.
의존성은 Source 도메인에서 Target 도메인 사이에서 정의된다.
객체 지향 언어에서 사용되는 다양한 관계(상속, 참조 등)를 기반으로 분류한다.
상위 도메인은 하위 도메인의 의존성을 기반으로 구축되어야 한다.

32 SEC-2014-RM005
Source Dependency Kind Target Description
Class Extends Class The source type extends/implements
the target type
Class Contains Class The source type contains a nested
class whose type is the target type
Class Contains Field The source type contains the target
field
Method Returns Class The source method declares a
return type based on the target type
Method Has param Class The source method declares a
parameter based on the target type
나. 소프트웨어 의존성 구분
소프트웨어 시스템이 가지고 있는 의존성은 대상이 되는 객체 지향 언어에 따라 매우 다양하다.
이 문서에서는 앞에서 제시한 내용처럼 JAVA 언어를 기반으로 가정하여 다음의 구분, 구현
절차를 설명하겠다.
￭ 기본 절차
 1 단계: 대상 소프트웨어의 분석단위가될 도메인을 나눈다.
 2 단계: Class 도메인 및 하위 도메인 사이의 모든 의존성을 정의한다.
 3 단계: 소스코드 및 목적코드에서 2 번에서 정의한 의존성을 추출 한다.
 4 단계: 추출한 의존성을 표에서 정했던 템플릿으로 기록한다.
￭ 절차 설명
- 1 단계: 대상 소프트웨어의 분석 단위가 될 도메인을 나눈다. 도메인간의 의존성을 정의
하는 과정이다. 우선적으로 모든 도메인들이 정의되어 있어야 각각의 의존성을 명확히
구현 할 수 있다.
- 2 단계: Class 도메인 및 하위 도메인 사이의 모든 의존성을 정의 한다. 여러 가지 언어에서
모든 종류의 의존성을 정의할 수 있지만 객체 지향 언어 중 JAVA 에서 어떻게 의존성들을
정의 했는지 아래의 표와 같이 정의하였다.
[표- Java 의 의존성의 종류]

p
33
Source Dependency Kind Target Description
Method Throws Class The source method declares the
target type in its throws clause
Method Calls Method The source method code invokes
the target method
Method Accesses Field The source method code accesses
the target field
Field is of type Class The source field's type is based on
the target type
Any References Class Any relation not covered by one of
the others, e.g.
- generic type parameters/bounds
- parameter/return types of called
methods
- local variable types
- types declared in catch blocks
- types used in an instanceof operator
- 3 단계: 소스코드 및 목적코드에서 2 번에서 정의한 의존성을 추출 한다.
A) 이미 한번 컴파일 된 목적 코드가 있는 경우
이미 한번 컴파일 된 목적코드로 손쉽게 구현하는 방법이 있다. 이는 모든 도메인 이름이
정확히 목적 코드 안에 명시 되어있으므로 매우 손쉽게 도메인들이 어떤 의존성을 이루고
있는지 알 수 있다. 하지만 한번 컴파일 된 코드를 가지고 구현하는 것이기 때문에 구현하고
나서 사용하기에 IDE 와 연계되어서 사용하거나 JAR 처럼 라이브러리 형태만 분석할 수 있는
단점이 있다.
B) 소스코드만 존재하는 경우
소스코드에서 의존성을 구하는 것이다. 소스코드에서 구현되기 때문에 목적코드 분석보다
범용성이 늘어난다. 소스코드만 제공하면 분석이 가능하기 때문에 IDE 와 연계할 필요가
없어서 제약사항이 줄어들게 된다. 하지만 단점으로 소스코드에서 의존성을 뽑아내는것 자체가
이미 컴파일된 목적코드에서 뽑아내는 것보다 힘들고 외부 라이브러리가 포함된 프로젝트는
완벽한 분석이 불가능 하다.

34 SEC-2014-RM005
구현 할 때 단순히 코드를 파싱하는 형태로 구현하면 이름이 중복되거나 줄줄이 호출하는
형태의 소스 코드는 정확한 의존성을 표현하기가 힘들다. 그래서 소스 코드를 추상 구문
트리(Abstract Syntax Tree)로 변경하여 구현하는 편이 훨씬 편리하게 도메인들의 의존성을
구할 수 있다. 추상 구문 트리(이하 AST)는 각 구문에 따라서 Tree 의 형태로 표현하는
것이다.
예를 들어 아래의 그림은 자바의 소스코드를 AST 의 형태로 표현한 것이다.
[그림 3-9] 예제 소스 코드
[그림 3-10] AST
위의 그림과 같이 AST 로 소스코드를 변환하게 된다면 void PrintLog() 함수 내부에서
m_LogManager 의 타입을 찾아 어떤 함수를 호출 하였는지 쉽게 파악 할 수 있다. 그리고
처리 속도도 늘어나게 된다. 분석할 필요가 없는 것들을 가지를 쳐내게 된다면 모든 소스코드를
분석해야 하는 것보다 훨씬 빠른 속도로 처리할 수 있다.

p
35
- 4 단계: 추출한 의존성을 표에서 정했던 템플릿으로 기록 한다
위에서 추출한 의존성을 Source - Relationship - Target 의 형태로 기록한다. 여러가지
방법이 존재하는데 일단 도메인 사이를 이어주는 Edge 의 형태로 기록하여도 되고 따로
List 를 생성해서 기록하여도 상관 없다. 하지만 각 Source 와 Target 의 도메인은 정확히
분별 할 수 있도록 기록하여야 한다.
제 4절 지표를 이용한 소프트웨어 아키텍처 분석
1. 소프트웨어 지표 개요
소프트웨어 지표는 소프트웨어 사양 또는 속성을 측정하기위한 방법 중에 하나다. 정량적 측정은
모든 분야에서 필수적이기 때문에, 소프트웨어를 정량적으로 측정하기위한 소프트웨어 공학의
실무자와 이론가에 의해 지속적인 연구가 되어왔다. 소프트웨어 지표의 목표는 일정 및 예산
계획, 비용 추정, 품질 보증 테스트, 소프트웨어 디버깅, 소프트웨어 성능 최적화 및 최적의 인력
작업 할당에서 수많은 중요한 응용 프로그램이 있을 수 있다.
소프트웨어 지표를 이용할 경우에는, 다양한 문제점들을 단순히 나열하는 수준에서 해결 방법을
찾는 것이 아니라, 다양한 문제점들을 정의하고 관련된 기초 데이터를 수집하고, 문제점들을
객관적이고 과학적인 수치에 의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 찾을
수 있게 된다. 가장 큰 효과는 문제점을 단편적으로 해결하는 것이 아니라, 다양한 문제점들을
종합적으로 해결할 수 있는 프로세스 및 능력을 갖게 된다는 것 이다.
가. 측정(Measurement)의 정의
측정은 숫자 또는 심볼을 실세계에 존재하는 엔티티(Entity)의 애트리뷰트(Attribute)에 해당하는
프로세스로서, 명확하게 정의된 규칙에 따라서 이 애트리뷰트들을 묘사하기 위한 것이다.
측정은 엔티티의 에트리뷰트에 대한 정보를 포착하는 것에 중점을 둔다. 엔티티는 실세계의
객체로서, 사람, 방(root), 여행과 같은 이벤트, 또는 소프트웨어 프로젝트의 테스팅 단계 등의
예가 있다. 애트리뷰트는 우리가 관심을 갖는 엔티티의 특징(feature) 또는 특성(property)으로서,

36 SEC-2014-RM005
사람의 키 또는 혈압, 방의 면적 또는 색상, 여행의 경비, 테스팅 단계의 기간 등의 예가 있다.
애트리뷰트의 직접적인 측정(Direct measurement)은 다른 애트리뷰트의 측정에 종속되지 않고
측정하는 것이다.
애트리뷰트의 간접적인 측정(Indirect measurement)는 하나 이상의 애트리뷰트의 측정 결과에
의해 측정하는 것이다. 측정 결과는 현재 상황의 평가 또는 미래 상황에 대한 예측 활동에 활용되게
된다. 측정에 관한 다음과 같은 어구들이 있다. 측정하지 못하는 것은 제어 할 수 없다. 측정하지
못하는 것은 예측할 수 없다. 그렇기 때문에 측정은 어떠한 일을 제어하고 예측하기위해선
필수적인 일이다.
소프트웨어 측정에 대한 그래프를 아래와 같이 나타낼 수 있다.
[그림 3-11] Software Enginnering Measurement - the METKIT View[Fenton, 1991]

p
37
나. 소프트웨어 지표(Metrics)의 정의
소프트웨어 지표 기술은 소프트웨어의 측정 기술을 기반으로 소프트웨어 생명 주기 동안에
소프트웨어의 특징 또는 특성을 과학적인 수치로 정량화 할 수 있도록 하는 기술이다. 또한, 다양한
문제점들을 정의하고, 관련된 기초 데이터를 수집하고, 문제점들을 객관적이고 과학적인 수치에
의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 탐색하며, 다양한 문제점들을 종합적으로
해결할 수 있는 문제 분석 프로세스 및 시스템에 대한 기술이다.
지표는 소프트웨어 공학 분야에서 다양하게 정의되어 있고 소프트웨어 지표는 크게 Products,
Processes, Resource 로 나눌 수 있다. 본 문서에서는 소프트웨어의 아키텍처의 정방향 분석법을
다루기 위해 Products 에 관련된 지표에 대해서만 다루도록 한다. 다음은 Products 와 관련하여
USE, FACTOR, CRITERIA 와 지표와의 관계를 도식화한 그래프 이다.
[그림 3-12] 소프트웨어 품질 모델[Fenton, 1991
위의 그래프로 알 수 있듯이 메트릭을 통해 소프트웨어의 다양한 항목들을 객관적으로 평가
할 수 있게 된다.

38 SEC-2014-RM005
2. 소프트웨어 지표(Metrics)의 한계
가. 프로그래머의 인간성을 배제한 관리
개인의 능력을 수치화하고 이를 모두 확인하는 방법은 매우 어렵다. 관리자는 가장 재능 있는
프로그래머에게 가장 어려운 부분시킨다. 즉, 그 부분의 작업이 가장 시간이 오래 걸리고 버그도
많아 질 것으로 예상되고 있기 때문이다.
나. 편향
개발자는 팀의 능력을 잘 보이려고 하는 경향이 있기 때문에, 결과적으로 정량화시 일종의
편향이 작용한다. 예를 들어, 코드 행 수 능력을 측정하고자하는 경우, 프로그래머는 가능한 한
행 수가 많아보이도록 코드를 작성 할 수 있다.
다. 부정확
의미가 있고, 정확한 측정 방법은 알려져 있지 않다. 코드 행수는 정확하게 요구되지만, 문제의
어려움의 정도는 정확하게 수치화 할 수 없다. 기능 점수는 코드나 사양의 복잡성을 보다 정확하게
측정하는 방법으로 개발되었지만 잘 운영하려면 개인의 판단이 필요하다. 추정 방법이 다르면
결과도 달라진다. 때문에 함수 포인트를 만 명이 공정하게 이용하는 것은 어렵다.
이러한 소프트웨어 지표에 한계가 있는 것을 인지하고 사람이 아닌 소프트웨어를 평가하는
객관적 지표로 사용할 때 소프트웨어 지표 측정의 정확한 의의를 실현할 수 있다.
3. 소프트웨어 지표 종류
소프트웨어 지표의 앞서 설명했듯이 Products, Process, Resource 로 나눌 수 있고 여기서
집중할 Products 에 관한 지표는 Count, Complexity, Coupling, Object Oriented 등으로 나눌
수 있다.
가. Count Metrics
a) Number of Component
Number of Component 는 문자 그대로 Component 의 갯수를 의미한다. 여기서 Component 란

p
39
Library, Package, Class, Method, Function, Variable 등 소프트웨어 코드의 각각의 도메인
개채에 해당한다. Number of Component 지표를 통해서 소프트웨어의 크기 정도를 가늠한다.
￭ 측정방법
도메인 나누기에서 하였던 방법을 그대로 응용하여 구할 수 있다.
 1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다.
 2 단계: Top-down 방식으로 클래스, 메소드, 변수의 갯수를 구한다.
 3 단계: 반면 패키지묶음, Project, Workspace 도메인은 Bottom-up 방식으로 각각의
컴포넌트 갯수를 구한다.
b) Source Lines of Code (SLOC)
Source lines of code (SLOC) 은 프로그램의 소스코드 라인수를 나타내는 값이다. SLOC 는
일반적으로 프로그램을 개발하는데 필요한 노력의 양을 예측하는데 사용된다. 또한 프로그래밍의
생산성과 유지보수성을 측정하는데 사용되기도 한다.
￭ 측정방법
많은 유용한 비교는 프로젝트의 코드 라인의 크기의 순서만을 포함한다. 각각의 소프트웨어
프로젝트는 1 부터 100,000,000 라인 이상으로 다를 수 있다. 20,000 줄 프로젝트와 21,000 줄
프로젝트를 비교하는 것보다 10,000 줄 프로젝트와 100,000 줄 프로젝트를 비교하는 것이 유용하다.
어떻게 코드 라인 수를 측정하는 지에는 논쟁의 여지가 있다. 소스코드의 라인수의 차이는
소프트웨어의 복잡성을 평가하거나 인력 투입의 지표가 될 수 있다.
SLOC 를 측정하는 방법에는 물리적인 SLOC 와 논리적인 SLOC 로 나눌 수 있다. 이 두가지
방법의 구체적인 정의는 다양하다. 그러나 실제 SLOC 의 일반적인 정의는 주석 행을 포함하여
프로그램의 소스 코드의 텍스트 라인수 이다. 섹션의 코드 라인이 25%이하의 빈행으로 된 줄도
포함 할 수 있다. 만약 섹션에 25%를 초과하여 빈 줄이 있을 경우 계산에 제외할 수 있다. 논리적인
SLOC 는 실행되는 “statements”의 수를 측정한다. 그러나 논리적 SLOC 는 특정언어마다 다르게
계산되어 질 수 있다. (예를 들어 논리적 SLOC 측정법 중 간단히 C 와 같은 프로그래밍 언어는
세미콜론’;’의 수로 라인수를 측정할 수 있다.) 논리적 SLOC 보다 물리적 SLOC 의 경우 보다.

40 SEC-2014-RM005
쉽게 툴을 통해 측정 가능하며 정의 설명도 쉽다. 하지만 물리적 SLOC 는 논리적으로 무관한
형식과 스타일 규칙에 민감하다. 반면에 논리적 SLOC 는 형식과 스타일 규칙에 덜 민감하다.
대부분의 SLOC 측정들은 측정방법이 논리적인지, 물리적인지 명시해 놓지 않은것이 많다. 논리적
SLOC 와 물리적 SLOC 는 크게 다를 수 있으므로 SLOC 지표를 읽을때 어떤 것인지 구분하는
것이 중요하다.
SLOC 를 측정의 모호성을 보이기 위해 C 코드의 SLOC 를 측정하는 의 예제를 보도록 하겠다.
for (i = 0; i < 100; i++) printf("hello"); /* 다음의 경우 이 코드는 몇줄인가? */
이 예제에서 우리는
물리적 SLOC 의 경우 1 줄.
논리적 SLOC 의 경우 2 줄. (for 문, printf 문)
주석 1 줄로 측정할 할 수 있다.
또한 프로그래머, 코딩 스타일에 따라 위 1 줄의 코드는 여러 줄로 나뉘어 쓸 수 도 있다.
/* 다음의 경우 이 코드는 몇줄인가? */
for (i = 0; i < 100; i++)
{
printf("hello");
}
이 예제에서는
물리적 SLOC 의 경우 5 줄
논리적 SLOC 의 경우 2 줄
주석 1 줄로 측정할 수 있다.
논리적”, “물리적” SLOC 값은 큰 숫자를 가질 수 있다. Robert E. Park(소프트웨어 엔지니어
학회)는 SLOC 값을 정의하기 위해 프레임 워크를 개발했다. 덕분에 사람들은 소프트웨어 프로젝트의
SLOC 측정 방법에 대해 자세하게 설명할 수 있게 되었다. 예를 들어, 대부분의 소프트웨어

p
41
시스템은 코드를 재사용하고 결정하는 측정 값을보고 할 때 재사용 코드를 포함 할 수 (있는
경우)하는 것이 중요하다.
SLOC 를 지표로서 처음 사용하게 되었을 때는 대부분 포트란, 어샘블리어와 같이 Line-oriented
언어였다. 이러한 언어는 주로 천공 카드로 프로그래밍을 하던 시절에 개발되었다. 하나의 천공카드가
일반적으로 하나의 줄을 나타낸다. 이것은 쉽게 샐 수 있는 하나의 개체였다. 그리고 눈에 보이는
프로그래머의 결과물이었기 때문에 메니저가 프로그래머의 생산성을 쉽게 측정할 수 있는
수단이었다. 당시 이 지표를 “Card Images”로 표현되기도하였다. 오늘날은 컴퓨터 언어는 형식제약
사항이 없다. 텍스트 라인은 어디성 높이 80, 폭 96 자가 아니며 하나의 라인에 하나의 코드만
들어갈 필요도 없다.
￭ SLOC 측정의 사용법
SLOC 측정법은 때때로 논란의 여지가 있다. SLOC 가 클수록 소프트웨어 개발에 많은 시간과
노력이 드는것은 누구나 동의 할 수 있는 사실이다. 하지만 SLOC 가 기능성과는 그리 많은 관계가
있지는 않다. 숙련된 개발자는 같은 기능을 하는 코드를 더 적은 줄로 코딩이 가능하다. 그렇기
때문에 동일한 기능을 하는 적은 SLOC 로 작성된 프로그램이 더 기능적이라고 할 수 있다. 특히나
SLOC 는 개개인의 생산성을 측정하는 대는 적합하지 않다. 기능성 측면에서 개발자는 적은 수의
줄로 코딩을 할수록 그렇지 못한 개발자보다 생산성이 높다고 볼 수 있다. 좋은 개발자는 여러
줄의 코드 모듈을 한 줄의 모듈로 합친다. 이처럼 코드 줄을 줄이게 될 수록 쓸데없는 코드에서
생기는 버그의 발생률 또한 줄 게 된다. 특히 숙련된 개발자는 가장 어려운 작업을 할당받게
되는 경향이 있으며, 따라서 때때로 SLOC 측정법에 의해 평가한다면 숙련된 개발자는 낮은
생산성을 나타나게 된다. 게다가 초보 개발자는 중복코드를 자주 발생한다. 이러한 중복코드는
많은 버그와 높은 유지보수 비용을 야기한다. 하지만 SLOC 값은 높게 나타나게 된다.
SLOC 는 다른 언어로 작성된 프로그램을 비교할 때는 부적합 하다. 다양한 컴퓨터 언어는
간결성과 명확성을 다른 방법으로 나타낸다. 극단적인 예를 들어보면, 어샘블리언어는 다른
언어로 몇 줄이면 되는 것을 구현하기위해 몇백 줄을 요하기도 한다.
아래 예제는 C 언어로 작성된 “Hello world” 프로그램을 COBOL 로 다시 작성한 예제 이다.
(COBOL 은 잘 알려진 3 세대 프로그래밍 언어이다)

42 SEC-2014-RM005
Year Operating System SLOC (Million)
1993 Windows NT 3.1 4-5
1994 Windows NT 3.5 7-8
1996 Windows NT 4.0 11-12
2000 Windows 2000 more than 29
2001 Windows XP 45
2003 Windows Server 2003 50
최근의 소프트웨어는 자동으로 생성되는 코드의 양이 많아져 SLOC 를 비교하는데 또 다른
문제점이 생기기도 한다. GUI 기반의 소프트웨어는 기본적으로 많은 줄의 소스코드가 필요하고
이를 구현하기위해 템플릿형식으로 프로그래밍 툴에서 제공한다. 한 예로, GUI 자동생성기는
수십줄의 라인을 간단하게 마우스를 아이콘에 드레깅하여 생성하기도 한다.
그렇기 때문에 디바이스 드라이버와 같이 항상 사람의 손으로 작성하는 코드와 GUI 와 같이
자동 생성되는 코드의 SLOC 를 비교하는 것은 적합하지 않다.
비용, 스케줄, 노력을 산출하기위해 SLO 를 파라미터로 하는 추정 모델이 있다. 널리 쓰이는
Berry Boehm이 고안안 COCOMO(Constructive Cost Model), 시스템의 가격을 추산하는 Galorath의
SEER-SEM 등이 이 중 하나이다. 이 모델은 좋은 예측을 할 수 있게 해준다.
Vincent Maraia 에 따르면 마이크로소프트의 Windows 제품의 SLOC 는 다음과 같다.

p
43
David A. Wheeler 는 리눅스 운영체제의 레드햇 버전 7.1 의 경우 3 천만 이상의 물리적
SLOC 를 가졌다고 발표했다. 또한 이 작업은 약 8,000 man-year 가 소요되었으며 노력의 산물로
조 단위 이상의 가치를 가지고 있다고 발표했다.
비슷한 작업으로 데비안 GUN/Linux 버전 2.2 는 5 천 5 백만 줄 이상의 SLOC 를 가지고 있으며,
이것은 14,000 man-year 와 1 조 9 천억의 개발비용이 들었다고 측정하였다. 최근 자동화된 툴에
의해 데비안 리눅스의 SLOC 를 측정해본결과 2005 년에 1 억 줄, 최근에는 2 억줄의 SLOC 로
측정되었다.
나. Complexity Metrics
a) Cyclomatic Complexity (CC)
Cyclomatic complexity 는 Thomas J. McCabe 가 1976 년도에 고안한 지표로써, 소프트웨어의
복잡도를 나타내는 지표이다. 일반적으로 Cyclomatic complexity 는 V(G)로 알려져있다. 소프트웨어
메트릭에서 일반적으로 많이 사용되는 지표중 하나이다. 이 지표는 복잡성을 나타내는 다른
지표들에 비해 이해하기 쉬우며 직접 계산하기도 어렵지 않다. 또한 이 지표는 소스 코드내의
조건의 갯수를 컨트롤 할 수 있도록 해준다. Cyclomatic complexity 값을 적게하는 것이 소프트웨어의
복잡도를 줄이는 방법 중 하나이다.
Cyclomatic complexity 지표는 소프트웨어 코드의 분기점의 개수를 나타내기 때문에 다음과
같이 테스트케이스와 함께 생각하면 이해가 쉽다. Cyclomatic complexity 지표는 소프트웨어
테스트 케이스의 갯수와 비례한다. 따라서 Cyclomatic complexity 의 값이 작을수록 소프트웨어를
테스트할 경우의 수가 줄고 소프트웨어의 품질을 높이기 쉽다고 할 수 있다.
Cyclomatic Complexity(CC)계산법은 다음과 같다.
CC = Number of Decisions point + 1
Cyclomatic Complexity 는 소프트웨어 코드의 결정 포인트에서 1 을 더한 값과 간다. 여기서
말하는 결정 포인트는 조건문에 의해서 생기는 코드의 분기점이다. 일반적인 예로 If..else if..else,
case, for ..next, until, while, catch 등이 있다. CC 를 구하는 간단한 방법은 이러한 조건문의
갯수를 세는 것이다. 또한 다중 결정포인트의 경우 CC 를 계산하는 몇가지 규칙이 있다. 다중

44 SEC-2014-RM005
Construct Decisions Reasoning
If..Then +1 An If statement is a single decision.
ElseIf..Then +1 ElseIf adds a new decision.
Else 0 Else does not cause a new decision. The decision is
at the If.
#If..#ElseIf..#Else 0 Conditional compilation adds no run-time decisions.
Select Case 0 Select Case initiates the following Case branches,
but does not add a decision alone.
Case +1 Each Case branch adds a new decision.
Case Else 0 Case Else does not cause a new decision. The
decisions were made at the other Cases.
For [Each] .. Next +1 There is a decision at the For statement.
Do While|Until +1 There is a decision at the start of the Do..Loop.
Loop While|Until +1 There is a decision at the end of the Do..Loop.
Do..Loop alone 0 There is no decision in an unconditional Do..Loop
without While or Until.
While +1 There is a decision at the start of the While..Wend
or While..End While loop.
Catch +1 Each Catch branch adds a new conditional path of
execution. Even though a Catch can be either
conditional (catches specific exceptions) or
unconditional (catches all exceptions), we treat all of
them the same way. *
Catch..When +2 The When condition adds a second decision. *
결정포인트란 if..else..else..else, switch..case..case..case 등과 같이 다양한 분기점이 생성되는
포인트를 말한다. 이때 계산규칙은 아래 표와 같다.
객체지향언어 마다 문법이 다를 수 있긴 하지만 기본은 위 표의 값을 따르면 된다. Cyclomatic
complexity 의 최소값은 1 이다. CC 값이 1 이라는 것은 소스코드에 어떠한 분기점도 없다는
말이다. 그리고 CC 값의 최대값은 지정되어 있지 않다. 소스코드 내에 분기점이 많으면 많을수록

p
45
CC 값이 커질 수 있다.
이 지표를 고안한 McCabe 는 Cyclomatic complexity 값을 10 이하로 유지하라고 권고하였다.
하지만 그때는 이미 30 년이 지났기 때문에 그 동안 프로그래밍 환경이 많이 변했다. 최근에는
많은 코딩표준이나 정적분석도구에서 10 이하로 유지하라고 하지는 않는다. C++ 코딩 표준 중
한가지인 JSF Air Vehicle C++ Coding Standard 의 경우 Cyclomatic Complexity 의 값을 20
이하로 유지하라고 명시해 두었다.
￭ Cyclomatic Complexity 의 특징
실제로 소프트웨어가 동작할 때 소스코드에 있는 모든 분기문이 동작하는 것은 아니다. 하지만
CC 값은 Run-time 시에 실제로 코드가 진행되는 분기점의 갯수를 측정하는 것이 아닌, 소스코드
상에서 나타난 분기점의 갯수를 측정하는 것이다.
Exit, Return과 같이 함수 종료, 프로세스 종료를 의미하는 소스코드는 Cyclomatic Complexity 값을
증가 시키지 않는다.

46 SEC-2014-RM005
Metric Name Boolean operators Select Case
Alternative
name
CC Cyclomatic
complexity
Not counted +1 for each
Case branch
Regular
cyclomatic
complexity
CC2 Cyclomatic
complexity
with Booleans
+1 for each
Boolean
+1 for each
Case branch
Extended or
strict
cyclomatic
complexity
CC3 Cyclomatic
complexity
without Cases
Not counted +1 for an entire
Select Case
Modified
cyclomatic
complexity
Cyclomatic Complexity 의 변형: Cyclomatic Complexity 를 약간 변형한 CC2(Cyclomatic
complexity with Booleans or extended cyclomatic complexity)와 CC3(Cyclomatic complexity
without cases or modified cyclomatic complexity)가 있다.
CC2 : Cyclomatic complexity with Booleans(“extended cyclomatic complexity”)
CC2 = CC + Boolean operators
CC2 는 CC 에 Booleans 연산자의 갯수를 더한 값이다. Booleans 연산자는 조건문에서 사용되는
And, Or, Xor, Eqv, AndAlso, OrElse 등이 있다. CC2 는 이러한 조건문내의 Booleans 연산자의
값을 더하게 된다. 하나의 조건문안에 여러 Booleans 연산자가 들어갈 수 있다. 예를 들어 if(x =
1 or y=2) 와 같은 조건문은 if(x=1) then, if(y=2) then 과 같이 2 개의 조건문으로 나눌 수 있다.
조건문 내에 다양한 Booleans 연산자를 사용하면 코드의 Readability 가 줄어든게 된다. CC 값은
이러한 문제를 반영할 수 없기 때문에 CC2 라는 변형된 지표를 사용하기도 한다.]
CC2의 또다른 이름은 ECC(Extended cyclomatic complexity) 또는 Strict cyclomatic complexity 라고
하기도 한다.
￭ CC3 : CC Where each Select block counts as one
http://www.aivosto.com/project/help/pm-complexity.html

p
47
￭ Cyclomatic Complexity 의 중요성
Cyclomatic Complexity 수치가 높다는 것은 코드가 복잡하고 에러가 발생할 확률이 높다는
것을 의미한다. 또한 Cyclomatic Complexity 값만큼 테스트 케이스의 경우의 수를 만들어야
한다는 것이다. 그렇기 때문에 Cyclomatic Complexity 의 값을 줄이기 위해 많은 노력을 하여야
한다. 아래 표는 기존의 버그를 고치려다가 의도치 않게 또 다른 오류가 발생할 확률을 다타내는
자료이다.
Cyclomatic Complexity 또 다른오류가생길확률
1~10 5%
20~30 20%
50 이상 40%
거의 100 60%
표에서 보듯이 Cyclomatic complexity 지표의 값이 높으면 유지보수성에 아주 안 좋은 영향을
끼친다.
￭ Cyclomatic Complexity 의 장점
 소프트웨어의 몇 안되는 정량적인 수치. 정수 하나로 된 숫자값 이기 때문에 이해가 쉽다.
 정량적이기 때문에 여러 설계를 수치적으로 직접 비교가 가능하다.
 개발자가 설계 단계에서 사용하기 쉽다.
￭ Cyclomatic Complexity 의 단점
 switch ~ case 문에서 지표의 값이 너무 높게 나타난다. 이 경우 Modified Cyclomatic
complexity 지표를 사용하면 된다.
 코드복잡도가 아닌 데이터 복잡도를 알기 힘들다.
 이 지표는 버그 발생 경향과 상관관계가 있지만, 25 이하에서는 강한 상관관계를 보이지
않는다.

48 SEC-2014-RM005
￭ Cyclomatic Complexity 예제
아래 소스코드를 보자.
public void testMethod(){
int a = 1;
boolean flag = false;
if(a == 1){
;
}else if(flag == true){
;
}
if(a != 1){
;
}
}
if~else, if 문이 있어 3 의 값을 가지고 여기에 1 을 더하게 되어 4 의 값을 가지게 된다.
또 다른 소스코드 예제를 살펴보자.
public void testMethod2(){
int a = 1;
boolean flag = false;
int b = 2;
if(a == 1 && flag == true || b == 2){
; //Do something
}
else{
; //Do something
}
a = 2;

p
49
}
if 조건문안에 boolean 조건 연산이 3 개가 있다. 일반적으로 Cyclomatic Complexity 수치는 2
지만, Strict cyclomatic complexity(Extended cyclomatic complexity)수치는 4 이다.
b) Total Cyclomatic Complexity
Total Cyclomatic Complexity 는 단어 그대로 Cyclomatic complexity 의 전체 값을 의미한다.
Total Cyclomatic Complexity 는 하위 도메인들의 Cyclomatic Complexity 의 값의 합과 간다.
[그림 3-13] 도메인 트리
JAVA 를 예로, 위 도메인 그림을 보면 Method 의 CC 값을 더하면 Class 의 CC 값이 나오며
Class 의 CC 값을 더하면 Package 의 CC 값을 구할 수 있다. 이 하위도메인의 Total Cyclomatic
Complexity 값은 상위도메인의 Cyclomatic Complexity 가 된다.
c) Fat
Fat 지표는 하위 도메인간의 참조 그래프에서 엣지의 갯수를 의미한다. Fat 지표는 다양한
도메인에서 구해질 수 있다.

50 SEC-2014-RM005
[그림 3-14] 코드 분석도
위 예제에서 urqa 라는 어플리케이션 도메인 내에서 많은 패키지 도메인 간의 참조관계를 볼
수 있다. 여기서 Fat 지표를 구하면 그래프의 엣지의 갯수에 해당하는 15 가 된다.
[그림 3-15] 클래스간 참조 관계
위 예제는 urqa.Collector 패키지 도메인 내에서 클래스간의 참조관계를 살펴볼 것이다.

p
51
여기서 Fat 지표를 구하면 그래프의 엣지의 갯수에 해당하는 5 가 된다.
이처럼 Fat 지표는 다양한 도메인 내에서 구할 수 있다. Fat 지표를 통해서 자식 도메인에서
서로간의 의존횟수를 파악 할 수 있다. Fat 지표는 그 차제만으로 의미를 갖기보다 “Number of
component(Library, Package, Class, etc…)”와 함께 하여 도메인의 복잡성을 파악할 수 있다.
Fat 지표와 “Number of component”지표를 함께 사용하여 ACD(Average Component Dependency)
지표를 구해낸다. ACD 에 관한 내용은 아래 설명하므로 여기서는 생략하겠다.
d) Tangled
Tnagle 지표는 소프트웨어 아키텍처를 분석할때 가장 중요한 지표이다. Tangle 지표는 소프트웨어의
역참조의 비율을 나타내는 지표이다. 소프트웨어를 구조적으로 작성하기 위해서는 역참조 관계를
지양해야한다. 역참조는 소프트웨어의 유지보수성을 매우 저하시킨다. 역참조란 도메인간의
참조관계가 순환(Cycle)을 형성하는 것을 의미한다.
Tangle(T)의 값을 구하는 수식은 다음과 같다.
T(%) = R / T * 100
여기서 R 은 역참조 갯수, T 는 전체 참조의 갯수이다.

52 SEC-2014-RM005
[그림 3-16] 패키지 참조
위 그래프에서 패키지간 참조 관계를 살펴보면 PackageA가 PackageB를 참조하면서 순환(Cycle)이
형성되는 것을 확인할 수 있다. 이처럼 도메인간의 순환이 형성되는 것을 역참조라고 하는데,
역참조가 생기면 소프트웨어내의 하나의 코드의 변화가 소프트웨어 전체에 영향을 끼칠 수도
있다. 또한 상위, 하위 Layer 에 대한 구분이 모호해 지기 때문에 소프트웨어의 구조 이해를 저해
시킨다.
위 그래프에서 역참조 갯수는 4, 전체 참조 갯수는 16 이다. 따라서 Tangle = 4 / 16 * 100 이므로
25%가 된다.
Tangle 지표는 이러한 역참조의 비율을 나타내 주어 소프트웨어의 얽힘 정도를 표현해 준다.
Tangle 의 값이 0 에 가까울 수 록 소프트웨어는 구조적으로 안정하다고 할 수 있다. Tangle 지표가
크면 클수록 소프트웨어의 분석이 용이 하지 않게 된다. 다른 지표보다 Tangle 지표가 중요한
이유는 이처럼 소프트웨어의 구조화 정도를 나타내주기 때문이다.

p
53
[그림 3-17] 패키지 관계
다시 한 번 오픈소스 urqa 를 보며 Tangle 값을 구해보도록 하겠다. 여기서 역참조의 갯수는
12(1+1+10), 전체 참조의 갯수는 159 이다. 따라서 Tangle 값은 12 / 159 * 100 = 약 7.55%가
된다.

54 SEC-2014-RM005
오픈소스 Logdog 오픈소스 ACRA
[그림 3-18] 두 오픈 소스의 구조
실제 소프트웨어의 구조를 파악할 때 Tangle 지표의 값이 0 인 소프트웨어와 그렇지 않은
소프트웨어를 비교해보면 그렇지 않은 소프트웨어를 파악하는 것이 매우 난해하다. 위에 보이는
소프트웨어는 안드로이드 클라이언트의 Log를 외부 서버로 전송하는 동일한 기능을 하는 소프트웨어이다.
오른쪽의 acra 는 구조가 매우 복잡하여 소스코드의 변화가 소프트웨어 전체에 어떠한 영향을
끼칠지 예측이 불가능하며, 기능파악에서 어려움이 있다. 반면 왼쪽의 logdog 은 역참조가 나타나지
않아 소프트웨어 구조파악에 용이하며 코드변화에 어떠한 영향을 미칠지 대략 예측이 가능하다.
Tangle 지표를 줄이기 위해서 역참조 관계를 야기하는 소스코드를 변경할 것을 권고하며 역참조
관계를 시각화하기 위해서는 본 문서의 DSM, Composition View 에 관한 내용을 살펴보길
바란다.
e) Average Component Dependency
ACD(Average Component Dependency)지표를 설명하기 위해서는 우선 CD(Component

p
55
Dependency), CCD(Cumulative Component Dependency), Maximum CCD(MCCD)의 의미부터
파악하여야 한다. Component Dependency 지표란 하나의 엘리먼트가 참조하는 동일한
도메인의 모든 엘리먼트의 갯수를 의미한다. 또한 순환 관계의 엘리먼트들은 모두 동일한
Component Dependency 지표 값을 가진다.
위의 그림을 보면 가장 하위 노드는 Dependency 가 없으므로 0 이 되고, 중간의 노드는
Dependency 노드가 2 개, CD 는 2 의 값을 갖는다. 최상위 노드는 Dependency 노드가 5 개
CD 는 5 의 값을 갖는다. 따라서 모든 CD 의 합인 CCD(Cumulative Component Dependency)는
9 가 된다.
또 다른 예를 들어보면 다음과 같다.
왼쪽 그래프의 CCD 는 6, 오른쪽 그래프의 CCD 는 20 이다. 이처럼 CCD 의 값이 크다는 것은
서로의 노드가 의존성이 높다고 할 수 있으며, 각 노드를 수정했을 때 다른 노드로 변화가
전파될 가능성이 크다고 볼 수 있다.

56 SEC-2014-RM005
그리고 ACD 는 다음의 수식으로 나타낸다.
ACD = CCD / MCCD * 100 (%)
여기서 MCCD(Maximum CCD)란 도메인 내에서 가질 수 있는 최대 CCD 를 의미한다.
위 그래프에서 노드의 갯수가 모두 서로를 참조한다고 했을때 CCD 는 30 이고, 이 값이
MCCD 와 같다. 이제 ACD 를 구해보면 ACD = 9 / 30 * 100% = 30 가 된다.
ACD 는 다음과 같은 3 가지의 성질이 있다.
 Empty : 만약 노드간에 참조가 없다면 ACD 는 0%이다.
 Chain : 만약 모든 노드가 하나의 패스를 형성하면 ACD 는 50%이다.
 Cycle : 만약 모든노드가 하나의 순환을 형성하면 ACD 는 100%이다.( 그 역도 참이다)
￭ 기본 절차
- 1 단계: 클래스간의 의존성을 그래프로 표현한다. ACD 의 연산을 쉽게 하기 위해 클래스를
그래프의 Node 로, 의존성을 Edge 로 표현한다.
- 2 단계: 그래프에서 싸이클을 이루는 노드들을 의미상 하나의 노드로 변환한다.
- 3 단계: 트리 그래프에서 Leaf 노드를 구한다.
- 4 단계: 새로 생성된 Leaf 노드의 CD 값은, 노드가 호출하는 이미 제외된 Leaf 노드의
CD 값의 합으로 구한다.

p
57
- 5 단계: 하나의 노드로 묶었던 싸이클을 이루는 노드를 다시 풀어주어 모두 동일한
CD 값을 적용시켜준다.
- 6 단계: 모든 노드의 CD 값의 평균을 구한다.
￭ 절차 설명
- 1 단계: 클래스간의 의존성을 그래프로 표현한다. ACD 의 연산을 쉽게 하기 위해 클래스를
그래프의 Node 로, 의존성을 Edge 로 표현한다.
[그림 3-19] 래프로 표현된 클래스들의 의존성
- 2 단계: 그래프에서 싸이클을 이루는 노드들을 의미상 하나의 노드로 변환한다. 싸이클을
이루는 노드들을 우선적으로 구별해 주어, 추후 계산할 그래프탐색에서 중복탐색을 줄여
속도를 개선시킬 수 있기 때문이다. 이 결과로 그래프는 트리의 형태로 변환 된다.

58 SEC-2014-RM005
[그림 3-20] 싸이클을 구분 한다
- 3 단계: 트리에서 Leaf 노드를 구한다. Leaf 노드는 다른 노드로 가는 Edge 가 없기 때문에
CD(Component Depandancy)값을 0 으로 우선적으로 구할 수 있다. 그 후 Leaf 노드를
그래프에서 제외시켜 새로운 Leaf 노드들을 생성한다.
[그림 3-21] Leaf 노드의 제외

p
59
- 4 단계: 새로 생성된 Leaf 노드의 CD값은, 노드가 호출하는 이미 제외된 Leaf 노드의 CD값의
합으로 구한다. 이 때 자식 중에 2 단계에서 적용했던 싸이클을 이루는 노드들을 호출한다면
CD 값에 싸이클을 이루는 노드의 갯수까지 더 해줘야한다. 그 후 Leaf 노드를 그래프에서
제외시켜 새로운 Leaf 노드들을 생성한다. 이러한 과정을, 모든 노드가 제외 될 때까지
반복한다.
[그림 3-22] Leaf 노드의 제외 반복
- 5 단계: 하나의 노드로 묶었던 싸이클을 이루는 노드를 다시 풀어주어 모두 동일한 CD 값을
적용시켜준다.
[그림 3-23] 동일한 CD 값 적용

60 SEC-2014-RM005
- 6 단계: 모든 노드의 CD 값의 평균을 구한다.
[그림 3-24] CD 값 평균
다. Robert C. Martin Metrics
[그림 3-25] Robert C. Martin

SW 아키텍처 분석방법

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SW 아키텍처 분석방법

Similar to SW 아키텍처 분석방법 (20)

More from YoungSu Son

More from YoungSu Son (20)

SW 아키텍처 분석방법