이론적이거나 아카데믹한 근거가 아닌 현장에서의 경험을 근거로 해서 IT 아키텍처가 왜 필요한지를 설명하고 싶었다.

1. IT 아키텍처 팀 IT 아키텍처 정의
페이지 1 / 19
IT 표준화 – 아키텍처,프로세스
황인균
2015-09-22
실질적인 유지보수 관점에서의 IT 표준화 의미와 효과, 활용 원칙 그리고 IT 아키텍처
정의시의 고려사항을 정리한다.

2. IT 아키텍처 팀 IT 아키텍처 정의
페이지 2 / 19
수정 내용 일자 수정자
• 초안 작성
- IT 아키텍처 목적, 목표와 미션 그리고 아키텍처 기술의 틀
제시
2019.09.23 황인균
• 문서 제목 변경
- “IT 아키텍처 표준화 의미”  “IT 표준화 의미와 효과”
• IT 표준화 필요성 보강
• “문제 정의” 강화
• 비즈니스 요구사항 – 아키텍처 – 시스템 관계 추가
2019.09.24 황인균

3. IT 아키텍처 팀 IT 아키텍처 정의
페이지 3 / 19
내용
1. 개요.............................................................................................................................................................. 4
2. IT 표준화 필요성........................................................................................................................................ 4
2.1 상황 변화.............................................................................................................................................. 4
2.2 문제 정의.............................................................................................................................................. 5
2.3 IT 표준화 필요성.................................................................................................................................. 5
3. IT 표준화 대상(범위) ................................................................................................................................. 6
4. 시스템과 아키텍처 관계............................................................................................................................ 7
5. IT 아키텍처 정의........................................................................................................................................ 8
5.1 IT 아키텍처 개념 정의 ........................................................................................................................ 8
5.2 요구사항과 품질 .................................................................................................................................. 9
5.3 요구사항 분석 방법...........................................................................................................................10
5.4 요구사항, 품질, 아키텍처 관계........................................................................................................11
5.5 IT 아키텍처 활용................................................................................................................................12
5.6 IT 아키텍처 분류................................................................................................................................12
5.7 아키텍처 설계 프로세스 ...................................................................................................................13
6. IT 아키텍처 관리 체계 ............................................................................................................................15
7. IT 아키텍처 활용 원칙 ............................................................................................................................16
8. IT 아키텍처 효과......................................................................................................................................16
9. 고려사항 ....................................................................................................................................................17
10. 부록 - 품질 체계..............................................................................................................................18
10.1 ISO/IEC 9126 품질 체계.................................................................................................................18
10.2 McCall 품질 체계 ............................................................................................................................18

4. IT 아키텍처 팀 IT 아키텍처 정의
페이지 4 / 19
1. 개요
본 문서는 “시스템 운영 및 유지 보수”라는 관점을 위주로 해서 IT 아키텍처 및 표준화의 의미 및 도
입 효과를 살펴보고, 마지막으로 IT 아키텍처 정의 작업에 필요시 고려해야 하는 내용도 정리한다. 그
리고 “포스코 건설의 IT 아키텍처 표준화” 작업에 필요한 이론적인 근거를 뒤에 참고로 추가시켰다.
2. IT 표준화 필요성
2.1 상황 변화
상황 변화의 결론을 미리 말하면 다음처럼 정의될 수 있다.
• 시스템 중심의 IT 활동  아키텍처 중심의 IT 활동
• 경제 상황 슬럼프비용 절감
기존에는 비즈니스 프로세스 구현 및 안정화, 비즈니스 아키텍처와 IT 아키텍처의 상호 적응을 하는
단계로 비즈니스 관점의 이슈가 중심이 되었다. 그래서 비즈니스 중심의 이슈를 해결하기 위한 투자
와 운영 활동이 주된 일이었다. 이런 상황에서의 기술은 “지원”의 의미가 컸다. SI 프로젝트의 의미도
비즈니스 프로세스의 구현과 사용자의 사용자 편의성이 중심이었고, 운영 및 유지 보수 단계에서도
이런 관점의 이슈가 우선순위를 차지하게 되었다. 이제는 상황이 변했다.
우선 시스템이 갖춰야 하는 외부 조건 중에서 법적인 환경이 변하고 있고 이것이 변화의 시작이 될
것으로 본다. Privacy와 security가 법으로 강요된다는 것은 결국에 가서는 그것과 trade-off 관계에 있
는 performance 문제가 떠오를 것이다. 또한 유지 보수에 대한 긴축이 진행되면서 이전과 동일한 또
는 그보다 더 적은 인력 리소스로 앞의 목표를 달성하기 위해서는 다시 “유지보수성”, “호환성”, “테스
트 용이성” 같은 후속 목표들이 달성되지 않으면 힘들어진다.
이 상황은 무엇을 의미하는가? 바로 사용자와 비즈니스 요구사항 자체 보다는 그 사용자와 비즈니스
요구사항의 구현체들을 유지되도록 하는 인프라의 개선이 필요하다는 의미이다. 이전까지는 “시스템”
중심의 IT 활동이 중요했지만, 이제는 이 분야에서의 아주 새로운 비즈니스 요구사항보다는 “아키텍
처” 중심의 IT 활동이 필요한 상황이 되어 가고 있다는 것을 의미한다.
또 한가지는 국내, 국외의 경제 상황의 지속적인 슬럼프로 인해서 지금까지 구현된 IT의 운영 및 유
지 보수를 위한 비용을 계속 줄여가고 있는 상황이다. 이런 상황에서 외적인 리소스는 줄어들고 결국
은 효율화가 답일 수 밖에 없다.

5. IT 아키텍처 팀 IT 아키텍처 정의
페이지 5 / 19
2.2 문제 정의
“유지보수 단계에서의 문제”에 대한 정의를 미리 요약하면 다음과 같다.
요구 품질 확보 문제
상황 변화를 극복하기 위한 방안으로서의 IT 효율화의 문제는 결국 품질의 문제로 귀결된다. 품질개
선의 문제는 정보 시스템(소프트웨어)이 도입된 이후부터 계속된 화두이다. 최초로 등장한 품질 속성
은 “생산성”으로서 하드웨어의 발전속도를 따라 잡기 위해서 소프트웨어의 “생산성”이라는 목표를 달
성하기 위한 수많은 노력들이 있어 왔다.
“생산성” 달성은 크게 두 가지로 나뉘어 병행 진행되어 왔다 : 프로세스 개선, 재사용 증대. 전자는
애자일같은 소프트웨어 프로세스를 개선하려는 방향이고, 다른 하나는 OOP, CBD, SOA같은 개발 방
법론을 통해 재사용성을 증대시키려는 개선 방향이다1.
그러나 생산성과 재사용성은 아직까지도 완전히 해결하지 못하고 있는 품질 목표로서 다시 여러 목
표들을 낳게 되었다. 이런 품질 목표들은 다양한 체계로 정의되면서 “품질 관리”라는 다른 방향으로
문제를 해결하려는 노력이 있어 왔다.
이 품질 특성들 중에서 운영, 유지보수 단계에서 주목할 만한 것은 “재사용성”으로서 이것과 관련된
하위 속성들은 “호환성, 이식성, 유지보수성, 상호운용성”등이 대표적이다.
IT 아키텍처는 조직에서 목표로 하는 품질들을 정의하고 확보할 수 있는 방안을 보장하는 역할을 하
게 된다. 이런 품질들의 목표 달성은 IT 아키텍처 표준화를 통하지 않고서는 확보하기 힘들다. 필요성
을 요약하면 시스템 품질을 달성하기 위한 표준화 활동은 필수 불가결한 요소라 할 수 있다.
2.3 IT 표준화 필요성
필요성에 대한 요약은 아래와 같다.
• 외부 환경 제약 극복
• 통합 관리 필요성
소프트웨어 품질 특성들의 목표를 달성할 수 있는 구체적인 전략(tactic)중의 하나로 생각해 볼 수 있
는 것이 바로 IT 표준화이다. 표준화는 개발단계에서 뿐만 아니라 유지 보수 단계에서라도 달성해야
하는 기본적인 절차이다. 운영 및 유지 보수 활동에 대한 비용이 줄이고 효율화를 달성하고 그리고
1 “프로세스를 개선”은 정보 공학론, 폭포수론(Water fall) 그리고 요즘의 애자일 방법론 같은 소프트웨어 프로세스 프로세스를
개선하는 방식을 통해서 생산성을 달성하려는 방향이다. 또한 “재사용성”을 높이려는 방향은 OOP(객체지향 프로그래밍),
CBD(컴포넌트 기반 개발), SOA(서비스 지향 아키텍처) 같은 개발 방법론의 진화를 통해서 재사용의 단위를 확대하면서 진행되
어 왔다. 처음에는 재사용 단위가 객체였지만, 컴포넌트, 그리고 서비스로 확대되어 온 것이다.

6. IT 아키텍처 팀 IT 아키텍처 정의
페이지 6 / 19
새롭게 요구되는 품질(보안, 성능, 유지보수성, 호환성 등)을 해결하는 근본적인 방안으로 인식되고 있
다. 이를 현실적으로 어떻게 활용하여야 하는가에 대해서는 조직의 상황에 맞게 다양한 방안을 고민
해야 한다2.
SI 현실을 고려하면 운영 및 유지 보수 단계에서의 표준화 수립이 왜 필요한지에 대한인식이 생길
수 있을 것으로 보인다. 표준화를 통한 아키텍처의 정의는 SI 프로젝트 이전에 정의되어서 프로젝트
설계와 진행의 방향성을 제시해줘야 하지만, 현실은 그렇지 못한 경우가 많다. 아키텍처 정의는 결국
유지 보수 단계로 넘어와서 refactoring 작업을 통해서 마련해야 하는 것이 현실적 상황이다. 이런 현
실과 투자 감소 그리고 보안, 성능 및 유지 보수성이라는 품질 달성을 위해서는 아키텍처 및 프로세
스에 대한 표준화는 필수라 하겠다.
이 표준화는 또한 “통합 관리(Integration Management)의 툴로서의 의미도 크다. 전체 시스템과 프
로세스를 “통합적으로 모니터링하고 제어(monitoring & control)”하기 위해서는 필수이다3
.
효율적인 정보 및 자원관리는 관련 조직의 가장 중요한 목적중의 하나이다. 이미 도입되거나 도입될
다양한 시스템간의 통합과 연계는 이를 시스템으로 새로 구현한다고 해서 해결되는 단순한 문제는
아니다. 통합과 연계 그리고 그 절차들이 커다란 원칙과 규칙 아래 일관되게 관리할 필요가 있다.
참고로, 표준화의 준수 여부 모니터링 및 제어를 위해서는 적절한 도구가 필요할 수 있다. 적절한 도
구의 없이 품질 유지 관리 및 아키텍처의 유지 관리를 수행한다는 것은 현실적으로는 불가능에 가까
울 수 있다. IT 활동에 소요되는 비용을 줄이는 대신에 적절한 도구의 도입은 심각히 고려하여 정보
시스템 도입과 관리에 필요한 표준과 호환성 확보로 정보 및 자원관리의 짐을 덜 수 있을 것이다.
3. IT 표준화 대상(범위)
IT에서의 표준화 대상은 다음 두 가지이다.
시스템 & 프로세스
2 미국정부는 정보기술관리개혁법(Clinger-Cohen Act)을 통하여 정보기술 아키텍처를 제시하고, 이를 통한 표준의 적용과 정보
기술의 관리를 추진하고 있다. https://en.wikipedia.org/wiki/Clinger%E2%80%93Cohen_Act
3 PMP(Project Management Professional)에 있는 프로세스 영역중에서 “프로젝트 통합관리, Project Integration Management를
떠올려보자. 각 프로세스 영역에서 발생하는 이슈와 문제를 해결하기 위해서는 각 프로세스 영역은 “계획(planning)단계”를 통
해서 진행 기준 즉 진행에 대한 표준을 개발해야 한다.

7. IT 아키텍처 팀 IT 아키텍처 정의
페이지 7 / 19
Figure 1 표준화 대상
표준화 대상에 대한 원론적인 근거를 제시하자면 이렇다. 소프트웨어(시스템)을 만들어내는 프로젝트
를 진행할 때는, 제품의 품질을 개선하기 위한 “품질 관리(Quality Management)4“활동이 있다. 이 활
동에서는 제품 자체의 품질을 관리하는 작업도 있지만, 제품을 만들어내는 프로세스를 관리하는 작업
도 있다. 즉 “좋은 프로세스를 통해서 만들어진 제품은 믿을만하다”는 사상이다.
유지 보수 단계에서도 관심은 둘 모두에 두어야 한다. 운영 및 유지 보수 단계에서도 시스템에 대한
표준( IT 아키텍처)와 프로세스에 대한 표준을 기준으로 IT 활동이 진행되어야 한다.
다만 IT 아키텍처를 정의하는 단계에서는 필요한 부분을 우선적으로 고려해서 정의해 나가는 방법을
취할 수는 있을 것이다. 예를 들어 어플리케이션 레이어부터 진행하고 그것을 참조해서 네트워크 또
는 데이터 레이어로의 아키텍처 정의를 진행해 나갈 수 있을 것이다. 여기서는 “IT 아키텍처” 중심으
로 표준화를 이야기하도록 한다.
4. 시스템과 아키텍처 관계
더 진행하기 전에 시스템과 IT 아키텍처간의 관계에 대해서 정의한다.
IT 아키텍처는 시스템의 표준, 종합 설계도이다.
비즈니스 요구사항을 구현하기 위해서 시스템과 아키텍처가 어떤 부분을 담당하는지를 정의해보면
그 관계가 좀 더 구체적으로 될 수 있을 것이다.
시스템 : 기능적 요구사항 구현
아키텍처 : 비기능적 요구사항 즉 품질 요구사항을 시스템이 구현하도록 보장하는 역할
이 정의를 기반으로 관계를 설명하면 앞에서의 관계 요약이 된다. 시스템을 구현하는 프로세스를 보
더라도 이 관계는 명확해진다. 다음 그림은 비즈니스 요구사항 – 아키텍처 – 시스템간의 관계를 고려
한 프로젝트 진행 프로세스를 나타내고 있다.
4 Quality Management = Quality Control + Quality Assurance

8. IT 아키텍처 팀 IT 아키텍처 정의
페이지 8 / 19
Figure 2 시스템 개발 프로세스
(출처 : http://bcho.tistory.com/ )
요구사항은 기능적인 요구사항과 품질 요구사항으로 구분되는데, 각각을 시스템과 아키텍처에서 담당
하게 된다. 앞의 그림은 기능적인 요구사항은 품질 요구사항에 대한 표준 즉 아키텍처를 준수해서 구
현되어야 함을 보여주고 있다. 아키텍처는 시스템의 표준을 제시하는 역할을 한다.
5. IT 아키텍처 정의
5.1 IT 아키텍처 개념 정의
IT 아키텍처의 개념 정의는 공학적이거나 아카데믹한 정의와는 달리 할 필요가 있을 것 같다. 경험적
인 개념으로 정의하자면 반드시 다음과 같은 용어들이 필요하다 : 이해관계자, 요구사항, 품질. 이 용
어들을 조합해서 다음처럼 정의를 내려보겠다.

9. IT 아키텍처 팀 IT 아키텍처 정의
페이지 9 / 19
“다수의 이해관계자가 내어놓는 요구사항을 시스템의 품질로 반영하는 체계”5
일단 IT 아키텍처를 정의해서 공유하면 이해 관계자와의 커뮤니케이션이 용이해진다. 이해 관계자들
이 내어놓는 요구사항들간에 있을 수 있는 “충돌”을 쉽게 찾아낼 수 있다. 가장 쉬운 요구사항간의
충돌의 예는 “보안과 성능”이다. 보안을 강화하면서 성능을 높일 수는 없는 경우가 많다.
요구 사항간의 negotiation을 이해관계자들과 이야기할 수 있고, 개발시는 요구사항을 품질로 반영할
수 있다.
5.2 요구사항과 품질
품질의 분류는 많은 단체에서 다양하게 이뤄지고 있다. 아래 분류는 ISO/IEC 9126에 근거하여 품질을
구분한 예이다.
Figure 3 요구사항과 품질 관계
요구사항은 소프트웨어 공학에서는 “기능적인 요구 사항”과 “비기능적인 요구 사항”으로 분류한다.
“기능적 요구사항”이라면 해당 시스템(소프트웨어)이 목표로 하는 본연의 비즈니스 기능과 관련된 요
구사항이다. 예를 들어 건설의 “PMS”의 기능적 요구사항은 “프로그램 배포”이다. 만약 업무 어플리케
이션이라면 기능적인 요구사항은 업무적인 요구사항으로서 주로 BPR, PI에 의해서 결정되는 업무 프
로세스에 영향을 받는다. 반면에 “비기능적 요구사항”은 품질과 관련된 요구사항으로 그림에서 보여
지는 것처럼 “보안, 성능, 유지보수성, 사용성, 이식성”과 관련되어 있다6. 포스코 건설의 “넷클라이언
5 IT 아키텍처 정의 – 검색을 해 보면 아카데믹한 정의는 수없이 많다. 본 정의는 개인적인 견해를 근거로 하고 있어 이견의
여지는 있을 수 있다.
6 소프트웨어에 대한 근본적인 요구사항인 “생산성”과 “재사용성”을 정의하고 그리고 다시 “재사용성”을 달성하기 위해서 “호
계속>

10. IT 아키텍처 팀 IT 아키텍처 정의
페이지 10 / 19
트”같은 보안 프로그램의 경우 비즈니스적으로 요구하는 보안 즉 “불법 프로그램 단속”과 같은 기능
은 기능적 요구사항으로 볼 수 있지만, 넷클라이언트라는 소프트웨어 자체를 사용하기 위한 “인증,
권한 관리”, 넷클라이언트에서 사용하고 있는 데이터의 암호화, 통신 보호 등은 기능적인 요구사항과
는 비기능적인 보안과 관련된 요구사항이다7.
비기능적인 요구사항은 주로 시스템(소프트웨어)에서의 품질과 관련된 요구사항으로 이로 인해 “비기
능적 요구사항”이라는 용어대신에 요즘은 “품질 요구사항”이라는 용어를 자주 사용한다.
5.3 요구사항 분석 방법
요구사항 분석 방법이란 결국 요구되는 품질을 찾아내는 방법이다. 다음 그림은 각 이해관계자들이
내어놓는 요구사항을 통해서 어떻게 품질과 관련된 요구사항을 구분해 내는지를 보여주고 있다. 프로
젝트의 진행 단계를 따라가면서 기능적 요구사항별로 도출한 관심사를 “Core Concern”이라고 표현하
고 있다. 반면에 진행 단계를 따라가면서 요구사항과 요구사항간의 공통된 관심사를 도출해 내는 과
정이 필요하다. 이렇게 해서 나온 관심사를 “Cross-cutting concern”이라고 한다.
Figure 4 Cross-cutting concern
다음은 이런 Cross-cutting concern에 의해서 나올 수 있는 요구사항에 대한 예들이다.
환성”, “이식성”을 하위 목표로 다시 정의하는 등의 품질 체계는 주도하는 단체 및 조직에 따라서 다양하다.
7 보안은 그 중요도가 커지고 있어서 소프트웨어의 품질로서가 아니라 별도의 카테고리로 관리되기도 한다.

11. IT 아키텍처 팀 IT 아키텍처 정의
페이지 11 / 19
● 로깅 구조( 예외, 성능, 감사, 추적 )
● Configuration 관리 구조
● 배포 구조, 보안 구조
● 확장 구조
● 재사용 구조
● 기타
이처럼 cross-cutting concern은 대부분 품질을 구현하기 위한 기능들이다. 예를 들어 “로깅 구조”는
“신뢰성”을 확보하기 위한 전략중의 하나이다. 그리고 아키텍처란 이런 품질에 대한 요구사항을 어떻
게 어떻게 반영할 것인가에 대한 방법을 제공한다.
5.4 요구사항, 품질, 아키텍처 관계
요약을 하면 요구사항과 품질, 아키텍처의 관계는 다음과 같은 관계가 있다.
Figure 5 요구사항-품질-아키텍처 관계
요구사항을 분석해서 품질과 관련된 cross-cutting concern을 도출해서 아키텍처에 반영하는 절차를
표현하고 있다.
요구사항, 품질, 아키텍처의 관계를 다른 방식으로 표현할 수 있다. 기능적인 요구사항을 구현한 것이
“시스템”이라면, 비기능적인 요구사항 즉 품질 요구사항을 구현을 보장하는 것이 “아키텍처”라고 할
수 있다.
시스템 : 기능적 요구사항 구현
아키텍처 : 비기능적 요구사항 즉 품질 요구사항을 시스템이 구현하도록 보장

12. IT 아키텍처 팀 IT 아키텍처 정의
페이지 12 / 19
참고) 아키텍처를 설계하는 구체적인 절차는 앞의 그림보다 복잡하다. 위 그림은 개념적으로 설명하
고 있다. 아키텍처 설계 프로세스에 대한 예를 부록에 추가했다.
5.5 IT 아키텍처 활용
이렇게 정의된 아키텍처를 표현하기 위한 문서에는 다양한 내용이 포함될 수 있다. 아키텍처의 정의
는 시스템의 배포 구조 및 역할도, 조직도를 포함해서 조직 구성에도 영향을 줄 수 있다. 예를 들어
서 시스템의 배포 구조를 정의하면 그 구조에 맞게 팀을 구성할 수 있다. 이 외에도 아키텍처를 활용
할 수 있는 분야는 조직에 따라서 다양하다. 이런 내용은 아키텍처 문서에 포함되어야 하지만, 구두
로 공유되기도 한다.
사실 아키텍처 문서화 작업은 쉽지 않은 분야이다. 아키텍처 기술 언어8
등을 포함해서 아키텍처 문서
화9와 관련한 표준화 작업을 전문적으로 연구를 하는 단체도 있다.
5.6 IT 아키텍처 분류
이제 IT 아키텍처를 공학적인 관점에서 몇 가지로 분류할 수 있다. 이런 분류는 고정된 것은 없다. 아
키텍처 용어의 정의도 다른 조직과는 조금씩 다를 수 있다. 조직에 따라서 적절하게 정의해서 사용하
면 된다.
8
아키텍처 기술 언어 - ADML : Architecture Description Markup Language
9 4+1뷰와 유사한 정적, 동적인 표현 방법들이 있다.

13. IT 아키텍처 팀 IT 아키텍처 정의
페이지 13 / 19
Figure 6 아키텍처-아키텍트 정의 예
(출처 : http://bcho.tistory.com/ )
EA (Enterprise Architect) : 비즈니스 전략과 정보화 전략 통합, 연계
GA(Global Architect, Chief Architect) : 전체 아키텍처 관리. EA 역할을 겸하기도 함.
AA (Application Architect) : 애플리케이션 구조 설계, 표준 설정
TA (Technical Architect) : 하드웨어 인프라 설계
SA (Solution Architect) : 특정 소프트웨어 솔루션 구성 설계
DA (Data Architect) : 데이타 아키텍쳐 설계
5.7 아키텍처 설계 프로세스

14. IT 아키텍처 팀 IT 아키텍처 정의
페이지 14 / 19
Figure 7 아키텍처 설계 프로세스
(출처 : http://bcho.tistory.com/ )
그림은 Business Architecture가 정의되고 System Architecture가 정의되는 단계를 보여준다. System
Architecture가 설계될때는 소위 “맨땅에 헤딩(!)”을 하지는 않는다. Best practices로 널리 사용되는
“Reference architecture”들이 있다.
아키텍처를 정의함에 있어서 제일 먼저 하는 것은 “Architecture principals(아키텍처 원칙)”을 정하는
것이다. 이 원칙에는 경영적인 또는 영업적인 목표 등을 반영하고 있는 비즈니스 요구사항을 근거로
한다 예를 들어, “경영 악화 때문에 IT 투자를 줄여라”라는 요구 사항이 있다면, 아키텍처 역시 외주
개발팀에 의해서 “분산 개발”이 용이하도록 정의되어야 한다.
만약 운영 단계에서 경영 환경이 변화되어서 새로운 원칙이 필요하다면 이런 새로운 원칙을 반영할
수 있는 TO-BE 아키텍처로의 전환 계획이 필요하다. GAP 분석 등을 통해서 점차적 전환이 진행될
수 있을 것이다. 중요한 것은 이런 “원칙”이 정의되어 있고, 그리고 아키텍처를 설계하는 프로세스가
정의되어 있다는 것이다.
원칙이 정의되면 다음으로는 “Architecture Decision Process(아키텍처 의사 결정 프로세스)”를 통해서
구체적인 어플리케이션, 테크니컬, 데이터 아키텍처를 정의해 나가게 된다. 주요 설계 및 산출물은 다
음과 같다.

15. IT 아키텍처 팀 IT 아키텍처 정의
페이지 15 / 19
Architecture Sub Arch. Artifacts
Application Architecture Static arch. Level Diagram
Component relationship diagram
Dynamic arch. Activity Diagram( major use case
based )
Interface Spec. Msg Protocol, Msg Format, Msg
Exchage Pattern
Technical Architecture SW Deployment Architecture
HW Deployment Architecture
Data Architecture
6. IT 아키텍처 관리 체계
IT 아키텍처는 정보 기술적인 아키텍처뿐만 아니라 다음 같은 관리 체계 정의를 포함할 수도 있다.
이런 관리 체계를 포함함으로써 좀 더 IT 거버너스 구조로서의 역할을 수행할 수 있다.
Figure 8 IT 아키텍처 관리체계
구분 설명
조직 정보기술아키텍처 관리를 위한 인원구성과 역할을 정의함
운영절차 정보기술아키텍처 관리 프로세스의 정의, 운영지침의 개발, 지속적인 교육 및 자동화

16. IT 아키텍처 팀 IT 아키텍처 정의
페이지 16 / 19
관리 방안을 정의함
평가 정보기술아키텍처 현행 운영 현황과 향후 목표를 정립할 수 있는 평가체계를 정의함
7. IT 아키텍처 활용 원칙
IT 아키텍처를 정의하고 나면 IT 활동 및 시스템의 생명주기를 따라서 활용할 수 있는 원칙을 제공해
줄 수 있다.
Figure 9 IT생명주기에 따른 아키텍처 활용
• 아키텍처의 개별 사항들은 전체 업무 시스템의 설계, 구현, 테스트 및 검수의 기본 지침으로
활용
• 실제 업무 운영 시에 아키텍처에서 기술된 원칙에 위배, 변용 또는 누락이 발생되어서는 안
됨
• 기술되지 않은 원칙에 대해서는 IT 아키텍처 팀과 진행 이전에 사전 협의해야 함.
• 추가, 수정된 아키텍처 내용은 추후 아키텍처에 반영하는 활동 필요
• 만약 IT 아키텍처 분석, 설계시에 성과체계도 고려했다면, IT 활동 사후의 평가 체계도 제공할
수 있을 것을 것이다.
8. IT 아키텍처 효과
IT 아키텍처 및 프로세스 표준화를 통해 다음과 같은 효과를 기대할 수 있겠다.

17. IT 아키텍처 팀 IT 아키텍처 정의
페이지 17 / 19
기대 효과 설명
일관된 아키텍처 유지 • 조직에서 정의한 표준 체계하에서의 통제되고, 일관된 활
동을 통해서 표준 아키텍처의 유지가 가능해진다.
자동화 및 효율성 증대 • 예외와 일관되지 않은 아키텍처는 수작업이 많아지고, 수
작업이 많아지면 실수와 장애에 대한 가능성이 많아진다.
관리 대상이 되고 있는 시스템을 일관성있게 유지함으로써
관리와 유지 보수 활동의 자동화에 대한 기회가 증가한다.
유지 보수 리소스 절약 • 자동화 및 유지 보수 활동의 효율성은 결국 활동에 투입되
는 리소스(인력, 시간) 절약으로 이어질 수 있다.
신규 시스템 도입의 일관성 • 표준 아키텍처를 정의하면 신규 시스템의 구성에 대한 방
향성을 제공한다.
IT 아키텍처 활용 원칙 제공 • 관련자들에게 IT 아키텍처에 대한 활용 원칙으로 제공됨으
로써 활동에 대한 기준을 제공
일관된 업데이트 • 보안, 성능 및 기타 품질 향상을 위한 일관된 조치를 취할
수 있다.
9. 고려사항
정보기술 아키텍처를 분석하고 정의,개발하는 데는 몇 가지 고려해야 할 점이 있다. 고려사항은 장애
및 제약 사항으로 작용할 수 있다.
고려사항 설명
점진적 개발 프로세스 궁극적으로는 조직 전체의 통합된 아키텍처를 구축하는 방대한 작업이므로,
각 조직의 상태에 적합한 점진적인 개발 프로세스를 마련해야 한다.
초기 비용, 인력 새로운 아키텍처의 구축에 투입되는 초기 비용과 인력에 대한 고려가 되어
야 한다.
지속적 갱신, 관리 개발된 아키텍처를 지속적으로 갱신, 관리하기 위한 절차도 마련되어야 한
다.
개념 이해 최초 도입하는 조직에서는 생소한 개념의 이해가 더 필요할 수 있다. 관리
자 및 개발자가 업무 재설계, 정보화 전략계획 수립, 일반적인 시스템 아키
텍처 개발 등 기존 정보화 추진 방법과의 연계와 기능 차이를 이해하지 못
하면 중복적인 정보화 투자와 잘못된 아키텍처의 개발을 유발할 수 있다.
기술 및 문서화 한계 아키텍처 표준 단체에서 제시하는 방법대로 아키텍처를 완벽하게 기술하고

18. IT 아키텍처 팀 IT 아키텍처 정의
페이지 18 / 19
문서화할 수도 없을 것이다. 대신에 기술 및 문서화는 “운영 및 유지 보수”
에 실질적으로 도움이 되는 방식으로 시작을 고려해야 할 것이다.
10. 부록 - 품질 체계
시스템(소프트웨어)의 비기능적인 요구사항을 달성하기 위해서 품질 체계는 여러 가지가 있다. 그 중
에서 ISO/IEC 9126 체계와 McCall 품질 체계를 소개한다.
다시 한번 더 언급하지만 품질 체계 분류는 “탁상공론”이 아니다. 비즈니스 요구사항에 의해서 아키
텍처 원칙이 정해지고 이에 따라 강조되는 품질 특성이 달라진다. 품질 체계에 따라서 고려되어야
하는 품질들이 달라질 수 있다. 고려되는 품질 특성이 달라지면 품질을 달성하기 위한 전략이 달라
지고 전략이 달아지면 아키텍처가 달라진다.
10.1 ISO/IEC 9126 품질 체계
ISO/IEC 9126은 대표적인 품질 체계로서 다른 품질 체계의 기본으로 사용될 수 있다. 주로 개발 및
운영, 유지보수 단계 구분없이 고루 사용될 수 있다.
ISO/IEC 9126-1 Software engineering- Product quality- Part 1: Quality model
https://en.wikipedia.org/wiki/ISO/IEC_9126
10.2 McCall 품질 체계
McCall이 제안한 품질 체계는 운영, 유지 보수 단계에서 다른 체계보다 참조하기에 적절하다고 판단
된다. 이 체계는 제품의 운영, 수정, 이전 단계별로 관련있는 품질을 정리했다.
단계 관련 품질
Product operation(제품운영) 정확성(correctness)
신뢰성(reliability) :
사용 용이성(usability)
유용성
무결성(integrity)

19. IT 아키텍처 팀 IT 아키텍처 정의
페이지 19 / 19
효율성(efficiency)
Product revision(제품 개조) 유지보수성(maintainability)
유연성(flexibility)
검사이용성(testability)
Product Transition(제품 이전) 이식성( portability)
재사용성(reusability)
상호운용성(interoperability)
강건성(강인성)
McCall은 이해관계자별로도 관심 품질을 분류했다.
이해관계자 관련 품질
발주자 관점 최소비용, 생산성, 융통성
사용자 관점 기능의 정확성, 이해 용이성, 사용 용이성, 일관된 통합
유지보수자 이식성, 재사용성, 유지보수성, 상호운용성
발주자,사용자 효율성, 신뢰성
발주자,사용자, 유지보수자 신뢰성