아키텍트 이야기 by

[ 밑줄/연결 ]

 

아키텍처나 프레임워크의 품질은 시스템 전체의 품질에 직접 영향을 끼치므로 그 책임이 막중하다.

 

아키텍트는 설계와 구현의 specialist인 동시에 시스템에 대한 다각적인 관점을 겸비한 generalist 역할이 요구되는 자리..

 

(요구분석 담당자)

ㅇ 무엇을 만들지 결정하는 사람으로 분석가라고도 함

ㅇ 사용자와 고객 등 프로젝트의 이해관계자와 직접 협의하는 업무를 진행함

ㅇ 업무 전체의 요구사항을 정리하여 새로운 방식의 업무 흐름을 만든다든가, 비즈니스 요구사항을 분석함

ㅇ 분석을 토대로 시스템으로 만들 범위를 정하고 (시스템 요구사항 정의), 구체적으로 시스템에 들어갈 기능을 결정하는 업무를 함

ㅇ '무엇을, 어떤 계획과 방법으로 만드는 것이 옳은가'를 결정함

 

(인프라 담당자)

ㅇ HW, NW, 미들웨어 같은 Application이 탑재될 기반을 정비하는 것이 역할

ㅇ 성능, 정지시간(downtime), 백업 같이 시스템이 직접 수행하는 기능이라고 보기 어려운 구조적이고 관리적인 요구사항, 즉 비기능 요구사항을 수집해서 정리하고 이것을 만족시키는 인프라를 구축하기 위해서 어떤 제품을 써야 할지도 결정함

ㅇ NW, HW, OS, DBMS, Application Server 등 미들웨어, 선택할 제품의 가격과 공급 방법, 기간, 기능적 특징, 튜닝 방법 등 필요한 지식은 실로 방대함

ㅇ 시스템의 운용 환경, 개발 환경, 테스트 환경 등을 구축

 

(프로그래머)

ㅇ 프로그래밍이야말로 시스템 개발의 근간

 

(테스트 담당자)

ㅇ 시스템에 대한 테스트 전반을 책임짐

ㅇ 시스템이 올바르게 실행되는지 판단함

ㅇ 테스트 계획하고, 실제 테스트를 통해 결과를 검증하고 품질을 평가하는 등의 업무를 수행함

ㅇ test case에 기술된 항목에 따라 test를 진행하는데, 버그를 찾고, 처리와 검증 과정을 추적하고, 진척 사항을 관리하면서 동시에 버그의 원인과 그 버그를 수정하는 과정에서 발생하는 품질 문제를 분석함

ㅇ 

 

(운용 담당자)

ㅇ 완성된 시스템을 무사하게 안정적으로 가동하는 것이 운용 담당자의 역할

ㅇ 장애 발생에 따른 대책 역시 수립해야 함

 

(교육 담당자)

ㅇ 사용자가 시스템을 올바르고 편리하게 사용할 수 있도록 교육을 함

ㅇ 사용자가 시스템을 익숙하게 사용할 수 있도록 함

 

(아키텍트의 주요 업무)

ㅇ 개발에 쓰일 다양한 탬플릿을 만드는 일

ㅇ 용어 통일부터 시작해 개발에 필요한 여러 요소를 표준화하는 등 팀원들이 작업할 템플릿을 준비하는 것이 필요함

ㅇ 용어나 개념의 이해는 개인에 따라 다르므로, 아키텍트가 탬플릿을 정리해 제공함

ㅇ 사전에 설계와 구현 단계에서 개발자가 내려야 할 판단에 대한 지침을 제시함

ㅇ 아키텍트는 아키텍처와 프레임워크를 이용해서 기술 수준이나 경험이 제각각인 개발자들의 협조하여 일할 수 있도록 이끄는 역할을 함

ㅇ 추상적인 방침인 아키텍처의 핵심 기능 중 공통으로 이용할 수 있는 기능을 구현해 프레임워크로 제공함

 

(프레임워크를 준비하자)

ㅇ 아키텍처를 따르게 하는 강제적인 방법은 프레임워크를 제공하는 것

ㅇ JTA(Java Transaction API)에 따라 데이터베이스의 데이터를 갱신하는 트랜잭션을 수행하는 경우...

(1) 트랜잭션 시작

(2) 커넥션 얻기

(3) 각종 갱신 처리

(4) 커넥션 해제

(5) 트랜잭션 commit

(5.1) (예외 시) 트랜잭션의 rollback 라는 정형적인 처리가 필요하다. 

 

ㅇ 데이터베이스에 변경을 가하지 않고 단순히 조회만 한다면...

(1) 커넥션 얻기

(2) 각종 조회 처리

(3) ResultSet이나 커넥션 해제......라는 언뜻 보아 비슷하나 또 다른 정형적인 처리를 하게 된다.

ㅇ DB 접속을 예로 들어보면, 갱신용과 단순 조회용의 탬플릿 메서드를 프레임워크 쪽에 준비해 두면 좋을 것이다. 

ㅇ 정형적인 처리는 프레임워크에서 기능을 제공하며, 각 개발자가 일일이 기술하지 않도록 함. 정형적인 처리는 버그 발생을 방지할 뿐 아니라, 개발자의 코딩 분량을 줄이는 장점이 있으므로, 프레임워크를 사용할 것...

 

(프레임워크는 아키텍처의 구체적인 실체)

ㅇ Component: VB이나 델파이에서 사용하는 GUI 텍스트 박스나 라디오 버튼 등....컴파일 후에 바이너스 코드로 제공되는 재사용이 가능한 SW 부품

 

ㅇ Architecture: 설계방침. 예를 들면 '트랜잭션은 EJB를 사용하고 컨테이너에서 관리한다' 등...MVC가 대표적인 아키텍처의 예 ( 애플리케이션을 (Model - View - Controller)의 셋으로 분류하여 뒤죽박죽되기 쉬운 GUI 애플리케이션 설계를 정리하기 위한 아키턱처......아키텍처는 방침을 정의하는 것으로 실체가 있는 것이 아님. 시스템에서 결정한 아키텍처에 따라 개별적인 설계와 구현을 하게 됨

 

ㅇ Framework: 실체가 없는 아키텍처를 클래스라고 한다면 프레임워크는 아키텍처의 인스턴스라고 할 수 있음. 결국, 시스템에서 결정한 아키텍처를 실현하는 설계와 구현이 프레임워크인 것... 예를 들어 MVC의 모델, 뷰, 컨트롤러같은 추상적인 개념을 스트럿츠 프레임워크에서는 모델 - A 클래스, 뷰 - B 클래스,  컨트롤러 - C클래스를 상속하여 작성하는 것같이 구체적인 클래스로 제공함.

 

ㅇ 일반적으로 라이브러리는 SW 재사용이라고 할 수 있다. 단, 라이브러리와 프레임워크에는 결정적인 차이가 있다. 라이브러리를 이용한 개발에서, 프로그램의 주가 되는 흐름은 독자 개발을 해야 하므로 거기서 적당한 라이브러리를 호출하는 식으로 처리가 진행된다. 한편, 프레임워크를 이용한 개발에서는 프로그램의 주된 개발 흐름을 프레임워크가 맡고 애플리케이션마다 해당되는 요구사항을 만족시키기 위한 일부만을 독자 개발한다. 

 

ㅇ 프로젝트의  독자적인 프레임워크에는 비기능 요구사항에 따른 기능외에도 인쇄나 메일 발송 같은 기능을 어떻게 구현할지와 관련된 내용도 포함한다. 

 

ㅇ 프레임워크가 어떤 기능을 갖고 애플리케이션 컴포넌트에 어느 범위까지 맡길 것인지 등의 전략이 중요....프레임워크가 지나치게 커지면 프레임워크 자체의 유지보수에 악영향을 끼치며, 애플리케이션의 유연성도 저하됨. 반대로, 프레임워크가 지나치게 작으면 팀원마다 프로젝트에서 필요로 하는기능을 가진 표준 API를 한번쯤은 다 검토해야 하고, 실행할 때는 예외를 어떻게 처리할지 고민해야 한다. 이 부분에서 버그가 발생할 수 있을 뿐 아니라, 품질이나 생산성을 높이기 어렵게 된다..

 

(프레임워크를 이용할 때의 장점과 단점)

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

 

(장점)

ㅇ 매번 설계해야 하는 범위가 크지 않기 때문에 공수를 절감할 수 있음. 소스코드나 바이너리 코드도 재활용할 수 있음

ㅇ 신규로 개발하는 애플리케이션의 독자적인 코드보다 프레임워크 자체의 신뢰성이 높음. 많은 시스템에서 이용된 것을 근거로 해서 개발하므로, 높은 품질을 보장할 수 있음. 정제된 코드기 때문에 견고함

ㅇ 부품 가운데 많은 시스템에서 반복해서 사용한 것이 신뢰도가 높으며, 신규 개발의 공수를 절감해 줌

ㅇ 경험이 없는 사람도 제 몫을 할 수 있음

 

(단점)

ㅇ 한정된 범위를 벗어나면 프레임워크를 이용할 수 없음.

ㅇ 프레임워크에서 애플리케이션을 개발하는 수준으로는 개발자의 기술이 향상되지 않음

 

[ 자평 ]

 

필요한 부분만 선별하여 읽었다. 

선별하여 읽은 부분은 만족스러러웠다.