아키텍트의 아키텍처

아키텍트

항상 누가 아키텍처 설계서를 읽을지 고려한다.
아키텍처는 설계와 구현을 위한 지침이다.

아키텍트의 임무는 시스템 특징에 적합한 설계와 구현의 지침인 아키텍처를 작성하고, 이것을 개발팀 전원이 파악할 수 있도록 하는 것이다.

IT 아키텍트에게 요구되는 세 가지 힘
→ 균형감각, 추상화 능력, 예지 능력

ISO9126에 따른 품질 모델

분류	내용
기능성	타당성, 정확성, 상호운용성, 표준적합성, 보안성
신뢰성	성숙성, 내구성, 회복성
사용성	이해성, 학습성, 조작성
효율성	시간효율성, 자원효율성
유지보수성	분석용이성, 변경용이성, 안정성, 테스트용이성
호환성	환경적응성, 설치용이성, 규칙적합성, 치환용이성

가만히 있어서는 품질 특성에 대한 최종 사용자의 의견을 듣기 어렵다. 적극적으로 제안하고 질문해야 한다.

아키텍처를 통해 시스템 개발을 성공으로 이끄는 것이 아키텍트의 사명이다.

프로젝트가 시작되고 가장 먼저 열리는 킥 오프(kick off) 미팅은 프로젝트의 목적와 개요를 설명하는 것만이 아니라 팀원들을 직접 보면서 아키텍처를 전달하는 데 의미가 있다. 또, 팀원들이 지닌 공통 지식을 확인하는 자리가 되기도 한다.

팀원에게 아키텍처나 프레임워크에 대한 피드백을 받는다. 미팅을 통해 팀원이 적극적으로 참여하도록 권장한다.

아키텍트는 기술과 사람의 중재자이다. 기술은 도구다. 기술은 사람을 위해 활용해야 하는 것이다. 기술을 사람과 결부시키는 것이야말로 프로페셔널한 아키텍트가 지녀야 할 능력이다.

팀원들에게 프레임워크를 사용하게 할 동기를 부여해야 한다.

프레임워크로 편안하고 간단하게 개발한다.

• 컴포넌트는 컴파일 후에 바이너리 코드로 제공되는 재사용이 가능한 소프트웨어 부품이다.
• 아키텍트는 방침을 정의하는 것으로 실체가 있는 것은 아니다.
• 시스템에서 결정한 아키텍처를 실현하는 설계와 구현이 프레임워크인 것이다.

프레임워크를 이용한다는 것은 이미 정해진 구조 위에 해당 프로젝트에 필요한 부품을 만들어 붙여, 독자적인 완성품을 만드는 것이라고 할 수 있다.

장점

• 공통 부분 설계를 재사용 할 수 있어, 설계 비용이 절감된다.
• 공통 부분 설계는 반복해서 사용해 왔기 때문에 신뢰도가 높다.
• 옵션으로 된 부품을 범용으로 개발할 수 있다.
• 높은 기술 수준이 필요하지 않으므로, 인건비를 절감할 수 있다.

아키텍트의 중심 업무는 설계 단계에서 이루어진다.

잘못된 상태에서 벗어나려면, 잘못된 현재 상태에 얽매이지 말고 우선 이상적인 형태를 그려본다.

아키텍트는 시스템의 성공 요인을 분석하여, 중요한 부분을 미리 준비한다. 예를 들어, 품질 특성 중 기능성과 효율성이 문제고, 각각 '지원하는 데이터의 종류’와 '처리 능력(throughput)'의 개선이 필요하다고 판단하는 것이다.

다양한 특성을 100% 모두 지원하는 것은 현실적으로 불가능하다. 목록으로 만든 설계과제를 아키텍트나 프로젝트 관리자 같은 각 담당자가 직접 혹은 간접적으로 해결해 가는 것이 중요하다.

아키텍트는 프로젝트에 참가할 때, 아키텍처로 무엇을 해결할 것인지, 또 무엇부터 해결해야 하는지 염두에 두어야 한다.

아케텍트는 프로젝트를 폭넓게 바라보고 기술을 지원한다.

프로젝트 정성화를 위한 접근 방법

과제	원인	대책
유지보수 어려움, 확장의 어려움	아키텍처가 없다, 부적절한 아키텍처	아케텍트에 의한 적절한 아키텍처 구축
요구사항이 기하급수적으로 늘어남, 요구사항이 서로 일치하지 않음	요구사항의 변화와 증가에 임시변통으로 대처, 부적절한 우선순위 산정	요구분석 담당자가 요구사항의 우선순위를 만들고, 그 요구사항을 어떻게 실시할지 합의하는 과정까지 프로세스로 만듦
범위, 일정, 비용 조정이 어려움	고객과의 관계 부족	프롲게트 관리자/영업 담당자에 의한 관계 개선

아키텍처로 문제를 해결하기 위해는 실무자들에게 실제 효과가 있음을 인정받아야 한다.

뛰어난 프로그래머라면 설계나 프로그래밍에 대한 자기만의 노하우가 있다. 이것을 회사 내에서 그리고 프로젝트 내에서 공유하면 전체 조직의 생산성과 품질이 크게 향상될 것이다.

이슈 관리, 문서 관리 프로그램을 활용한다. redmine, dokuwiki

기술적인 정확함과 완벽함을 기하는 것보다 비즈니스 관점에서 판단할 수 있는 근거로 필요한 정보를 간략하게 전달해야 한다.

아키텍트의 직무를 수행하기 위해서는 누구에게도 뒤지지 않을 정도의 설계와 프로그래밍 능력과 함께 사전 영업에서 유지보수, 시스템 운용까지 시스템 개발의 각 단계와 천차만별한 고객의 비즈니스 요구에 폭넓게 대응 할 수 있는 능력이 필요하다.

애자일

폭포수 모델은 프로젝트 초기에 요구사항 전체를 분명하게 정의하고, 이를 만족시키는 설계와 구현을 단계에 따라 순차적으로 진행한다.

애자일(agile)은 민첩하고 기민하다는 의미를 갖는다.
애자일 선언이 게재된 홈페이지. http://www.agilealliance.org/home

최소한으로 필요한 문서만을 작성하고 뛰면서 새각하자

프로그래머가 추가 기능이 생길 것이라고 미리 예상해 당장 필요 없는 기능들을 설계에 넣는 것을 경계하는 말이다.

언젠가는 필요할 것이라는 예측은 대부분 맞지 않는다. 필요한 때에 최소한으로 설계하자.

패턴은 신중하지만 적극적으로 적용한다.

애자일 방식으로 개발할 경우 테스트 자동화가 필수다

기초 프레임워크(Foundation Framework), 수확된 프레임워크(Harvested Framework)

테스트

이상적으로는 개발팀과 테스트팀을 분리하는 것이 좋다. 분담이 어렵다면, 개발자에서 테스트 담당자로 인식을 바꿔서 일할 수 있도록 강한 동기를 부여해야 한다.

빈틈없는 테스트로 품질을 향상시키는 것은 불가능하다. 테스트는 품질을 높느끼 위해서가 아니라 품질을 확인하기 위한 것이다.

테스트를 쉽게 하기 위한 핵심은 모듈 분할에 따른 의존관계를 정리하는 것이다. 서브시스템이나 레이어 단위로 모듈을 분할한다.

테스트하기 어려운 부분에는 가능한 한 로직을 포함시키지 않는다. 테스트하기 어려운 부분에 포함되어 있는 로직은, 클래스나 메서드로 분할하여 테스트하기 쉽게 한다.

결함 테스트는 각 프로그램을 작성한 개발자 사이에 인식 차이가 있는지를 검증하는 것이 목적이다. 개발하는 사람이나 회사가 다르면 반드시 인식의 차이가 잠재해 있다. 올바른 인식이 필요한 공개 인터페이스를 최소화하여 결함 테스트 자체를 최소한으로 한정할 수 있다.

다양한 테스트 방법을 이해하자.

통합테스트는 '사용자가 요구한 것’을 개발했는지 확인하는 테스트다.

모든 결합 테스트를 자동화해서는 안 된다.

테스트를 개발자에게만 맡겨서는 안 된다.

아키텍처

EC¹ 사이트에서는 Sorry 화면 방식²을 채택해서는 안 된다.

어플리케이션 개발자가 설계서대로 개발해 줄 것이라고 생각해서는 안 된다.
표준화의 핵심은 반드시 어플리케이션 개발자와 함께 작성해야 한다는 것이다.

사용자가 성능 요건을 정해줄 것이라고 생각해서는 안 된다.

동일 서버 내의 웹 서비스를 호출해서는 안 된다.

24시간 가동 시스템이라고 모든 것을 24시간 동작시키려고 해서는 안 된다.

클라이언트/서버형 시스템을 가볍게 보아서는 안 된다.

데이터베이스

데이터 구조의 품질/성능이 나빠지는 것을 고려해야 한다.

데이터베이스 설계의 4단계

개념설계	논리설계	물리 설계	운용 설계
데이터베이스의 요건정의 요구한 데이터 정의	연관성 정의 데이터 정규화 데이터 비정규화	용량 설계 테이블 설계 인덱스 설계	감시 설계 리커버리 설계 백업설계

백업 설계를 먼저 해서는 안 된다. 가장 먼저 해야 할 일은 업무 요건을 설계한 후의 복원(recovery) 설계다.

레코드 길이 X 건수로 데이터 용량을 결정해서는 안 된다.

뷰, 트리거를 많이 사용해서는 안 된다.

현상만 보고 튜닝을 서둘러서는 안 된다.

소스 코드

공개 기능 클래스의 인스턴스를 직접 생성해서는 안 된다.
→ Factory Method로 간접화한다.

거대한 정수 클래스를 만들어서는 안 된다.
→ 정수 클래스는 기능이나 목적에 맞게 적절한 사이즈가 되도록 분할해야 하다.

분량이 많은 코딩 큐칙을 만들어서는 안 된다.
→ 프로그래머가 코딩 규칙을 읽는 것은 구축 작업을 하기 전이어야 하며, 그 때 규칙을 충분히 이해하고 나서 코딩 작업을 해야 한다.

오픈소스는 무료라고 생각해서는 안 된다.
→ 지원을 받지 않으려면 필요한 정보를 스스로 모아야 한다.

소스코드에 HTML 생성 코드를 포함해서는 안 된다.
→ 템플릿 엔진을 사용한다.

글로벌 변수나 순환 참조를 사용해서는 안 된다.

스레드 세이프로 하는 것을 잊어서는 안 된다.
→ 스레드 고유의 변수 저장에는 로컬 변수가 안전하다
→ 스레드 마다 인스턴스를 생성한다.

매직 넘버를 이용해서는 안 된다.

실 환경에서 갑자기 테스트를 해서는 안 된다.
→ 서버 가상화 소프트웨어를 사용하여 테스트 환경과 실 기기 환경을 구축하면, 실 환경의 이미지 파일을 테스트 서버에 복사하는 것만으로 테스트 환경을 구축할 수 있다.

플랫폼

메모리 관리를 처리계³에 맡겨서는 안 된다

네트워크

자동시별 모드와 전이중 모드를 혼재시켜서는 안 된다.

랜 스위치로 루프 구조를 만들어서는 안 된다.

운용 설계

SLA⁷를 뒤로 연기해서는 안 된다

운용 비용 절감만을 목표로 해서는 안 된다.

운용 절차 없이 운용해서는 안 된다.

용어

YAGNI

You are not gonna need it (그것은 필요 없을 것이다)

루프백 주소(loopback address)

네트워크의 입력과 출력 기능이 제대로 되는지를 테스트하기 위해 가상으로 할당한 인터넷 주소(127.0.0.1)를 말함. 사실 외부 네트워크에 연결되어 있지 않은 소프트웨어적 입출력 주소로, 발송된 데이터들이 이 주소로 되돌아서 다시 이 주소로 수신된 것처럼 동작한다. 웹 서버나 인터넷 소프트웨어의 네트워크 동작 기능을 테스트하는 데 사용

FLP(Fast Link Pulse) 버스트(burst)

ARP(Address Resolution Protocol)

STP(Spanning Tree Protocol)

RSTP(Rapid Spanning Tree Protocol)

장황화

예비의 시스템을 유지하여 고장이나 장애가 발생하였을 경우에 신속하게 대처하는 것

스레드 세이프(thread safe)

어플리케이션을 멀티스레드로 동작시켜도 문제가 되지 않는 것

순환 참조

구조화 된 데이터의 자식이 자기 자신을 참조하고 있는 경우.

템플릿 엔진

텍스트를 정형화해서 출력하는 엔진. 펄이라면 Template Toolkit, PHP이면 Smarty 등.

RPM(redhat package manager)

레드했에서 만든 패키지 배포 및 관리 프로그램으로 리눅스 소스나 컴파일된 프로그램의 배포, 업그레이드 등을 쉽게 관리하기 위해 프로그램과 설정 파일 등을 하나로 묶어서 마든 것

Factory Method 디자인 패턴

오브젝트의 생성을 맡고 있는 메소드를 이용하여 간접적으로 오브젝트를 생성하는 방법

SAN

Storage Area Network의 약자. "광저장 장치 영역 네트워크"라고 함. 대규모 네트워크 사용자를 위해 서로 다른 종류의 데이터 저장 장치 관련 데이터 서버에 연결하여 별도의 랜이나 네트워크를 구성하여 저장 데이터를 관리하는 특수 목적용 고속 네트워크를 말함.

FC (fiber channel) 스위치

채널에 네트워크 개념을 구현하기 위해 채널 스위치 개념이 도입되었는데, 파이버 채널(FC)을 망으로 결합한 회선 교환 스위치를 말함. 광대역 통신 및 접속 지연을 개선한 채널 방식과 네트워크 방식의 장점을 취한 네트워크 기술

다중도

서버(CPU)의 효율을 극대화하기 위해 여러 개의 사용자 프로그램(스레드)이 마치 동시에 실행되는 것처럼 처리하는 정도 혹은 처리가 가능한 수를 말함

기능적 요건(Functional Requirements)

시스템이 작동하도록 사용자가 요구하는 기능과 특성으로, 고객 요구 사항 중에 수행될 기능과 관련된 입력과 출력 및 입출력 사이의 처리 과정, 목표로 하는 제품의 구현을 위해 가져야 할 기능들을 말함.

비기능적 요건(Non-functional Requirements)

최종 사용자가 시스템 인수를 요구하는 시스템 특성으로, 제품의 품질 기준 등을 만족시키기 위해 시스템이 가져야 할 성능(응답 시간, 처리량 등), 사용의 편리성, 신뢰성, 보안, 운용상의 제약, 안정성, 유지보수성 등과 같은 행위적 특성을 말함

스루풋(throughput)

컴퓨터 시스템의 처리 능력을 나타내는 개념으로, 단위 시간당 처리할 수 있는 업무 단위량

정합성

논리적으로 모순이 없는 성질로 무결성과 유사한 의미. 시스템의 물리적인 부품간의 상호 용량이나 치수가 서로 잘 맞는 상태. 즉 모순이 없는 상태를 말함

SOAP (Simple Object Access Protocol)

클라이언트가 물리적으로 인접하지 않은 서버에 객체 혹은 함수를 호출하고 반환하는 방법 중의 하나로, HTTP 이점을 활용하기 위해 만들어짐

OS 파라미터

OS(시스테)를 운영 또는 가동하기 위해 설정된 값을 말함. 어떤 조건에서는 일정한 값을 갖지만 조건을 바꾸면 다른 값을 갖는 계수로 부팅 조건, 언어, 글꼴, 해상도, 디스플레이, 계정 등이 있음

파일 디스크립터(file descriptor)

파일을 관리하기 위해 시스템 즉, 운영체제가 필요로 하는 파일 정보를 갖는 기억장치의 한 영역을 말함. 파일마다 독립적으로 존재하고 시스템마다 다른 구조를 갖기도 함.

자체 검사 (health check, self-check)

장애를 미연에 방지하기 위해 미리 해결 방책이 정해진 일정한 규칙을 실행하여 장애가 있는지 없는지를 결정하는 컴퓨터의 자기 진단 기능을 말함.

비공식 구조

공식 구조의 작업을 수정하고 보조하는 통로로, 비공식적인 구조에서 의사소통이 이루어지는 것을 뜻함. 이러한 비공식 구조를 이해하지 않고 섣불리 바꾸는 것은 위험하다.

블랙박스 테스트

테스트 대상이 되는 프로그램의 내부 구조나 구현을 모든다는 전제 하에, '대상이 외부 명세를 만족시키고 있는가’라는 관점에서 행하는 테스트

테스트 주도 개발^TDD

Test-Driven Development

다형성^Polymorphism

객체지향 언어의 인터페이스나 상속 또는 추상 클래스를 사용하여 코드를 재사용하는 기술. 다형성은 동일한 이름으로 호출되는 메서드를 다양하게 구현할 수 있도록 하는 클래스의 기능. 다형성을 통해 메서드에서 제공하는 특정 구현 내용에 관계 없이 클래스의 메서드를 호출 할 수 있다.

리팩터링

겉으로 보이는 동작의 변화 없이 소프트웨어의 내부 구조(설계)를 바꾸는 작업

스파이크 솔루션

기술적 또는 설계에서 어려운 문제를 해결하거나 숨어 있을 수 있는 문제를 찾아내, 일정 추정에 대한 신뢰를 높이기 위해 만드는 간단한 프로그램

반복주기(iteration)

반복형 개발에서, 설계, 구현, 테스트가 한 차레 이루어지는 과정을 이터레이션(iteration)이라 부름

할리우드 법칙(Hollywood’s law)

제작자 우위의 환경인 할리우드에서 제작자가 필요로 할 때만 배우를 불러내는 식의 제작자와 배우의 관계를 말함

B2C

Business to Customer

EIS 티어

Enterprise Information System의 약자로 다른 데이터베이스나 ERP 소프트웨어(통합 업무 패키지) 등 외부 시스템과 연계하는 부분이다.

JTA

Java Transactino API

JNDI

Java Naming and Directory Interface

참고

• 아키텍트 이야기 - 야마모토 케이지 (인사이트, 2007)
• IT 아키텍트가 하지 말아야 할 128가지 - 니케이시스템즈 (로드북, 2012)
• 테스트 중독 Test Infected

참고 문헌

• 리팩토링 : 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법 - 마틴 파울러(대청, 2002)
• GOF의 디자인 패턴 (피어슨에듀케이션코리아, 2002)
• 실용주의 프로그램 - (인사이트, 2005)
• 소프트웨어 장인정신 - Pete McBreen (피어슨에듀케이션코리아, 2002)

---

1. EC: Electronic Commerce의 약자. 전자상거래 ↩

2. 로드 밸런서로 동시 접속자수를 제어하고, 한계값이 넘으면 Sorry 화면을 표시한다. ↩

3. 처리계: 처리에 있어서 가장 핵심적인 부분으로 은행을 예로 들어 말하면 입금, 출금 처리를 하는 계정 처리를 말함. 다른 것으로는 채널계⁴, 정보계⁵,운영계⁶ 등이 있다. ↩

4. 채널계: 시스템간의 데이터 정합성 및 표준화를 위해 정보를 제공하는 역할. ↩

5. 정보계: 처리계에서 수집된 데이터를 가공하여 각 부분의 업무 처리를 위해 정보를 제공하는 역할. ↩

6. 운영계: 프로그램을 유지보수하고 시스템을 위한 각종 스케쥴을 관리하는 역할 ↩

7. SLA: (Service Level Agreement)는 IT 서비스를 제공하는 조직이, 자신이 제공하는 서비스의 내용이나 품질 레벨에 대해 수치 목표를 정의하고, 그 목표에 대해 사용자와 합의를 한 것. ↩