AOSA 1권 9장. CI 정리 



http://www.aosabook.org/en/integration.html






블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|



http://www.aosabook.org/en/hdfs.html 

의 내용을 정리하였으며 웹 상에서 여러 다른 정보도 참조하였습니다. 




















8.HDFS

introduction

하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)은 기성 하드웨어에서 실행할 수 있도록 디자인된 분산 파일 시스템.

ㅇ 다른 분산 파일 시스템과의 차이점

HDFS  fault-tolerant 하고 저비용 하드웨어를 통해 배포할 수 있도록 설계됨.

HDFS는 응용 프로그램 데이터의 접근에 높은 처리량을 제공하고, 대용량 데이터 집합을 갖는 응용 프로그램에 적합

ㅇ 하둡의 중요한 특징은 수 없이 많은 데이타와 계산의 파티션, 병렬 계산의 실행임

ㅇ hdfs는 메타데이타와 데이타를 분리하여 저장한다.

namenode 에 메타 데이타 저장

datanode 에 데이타 저장

TCP 를 이용하여 서로 통신

ㅇ 목적

대용량 분산 파일 시스템에서 사용

ㅇ 높은 안정성

 –파일을 여러 개 복제하여 하드웨어 장애에 안정적임

 –결함 탐지와 자동 복구를 수행함

ㅇ 일괄처리 최적화

 –매우 높은 대역폭 제공

ㅇ 특징

ㅇ single-writer & multiple-reader 모델

ㅇ 전체 클러스터에 대한 하나의 namespace를 가짐

   ㅇ namespace는 계층적인 파일, 디렉토리를 가진다.

    –권한 등의 속성, 수정/접근 시간, 디스크 공간 할당량 등을 기록함

ㅇ 시스템의 메타데이터, 응용프로그램의 데이터를 분할하여 저장

 - 시스템 메타데이터: NameNode / 응용프로그램 데이터: DataNode

ㅇ 파일 내용을 블록단위로 분할 및 복제

- 각 블록은 독립적으로 여러 DataNode 에 복제 - replica (일반적으로 3)



<Read&Write에 대한 간략한 도식화는 http://bcho.tistory.com/650 의 프로세스와 순서 설명을 참고한다.>


Architecture

1. namenode

파일시스템의 namespace 를 관리 

 - 파일 목록 

 - 파일이름과 파일의 블록 목록 맵핑 

 - 블록과 DataNode 위치 맵핑 


그 외에도

 - 클라이언트의 요청 (읽기/쓰기

 - CheckpointNode , BackupNode 를 관리하며 image, checkpoint, journal 을 저장한다. 


2. image and journal

inodes name system 의 메타데이타를 저장하는 블록의 목록을 이미지라고 함

클라이언트의 시작 트랜잭션이 journal 에 기록하고 ack가 클라이언트로 전송되기 전에 저널 파일은 플러쉬 되고 동기화 된다


image 

- 파일시스템의 메타 데이터 

- inode data + 각 파일의 블록과 블록의 복제인 replica들의 목록 


checkpoint ( image에 대한 지속적인 기록을 위해서 사용 )

   - 파일 시스템의 메타데이터 보호 위해 사용하는 메커니즘. 


journal 

- image의 수정사항에 대한 쓰기 전에 commit 로그 ( 파일 시스템의 변경사항 기록 )


checkpoint journal 손상 대비하여 checkpoint, journal을 다른 볼륨이나 다른 서버에 저장 


3. datanodes

데이터노드는 로컬 파일 시스템의 파일에 HDFS 데이터를 저장

ㅇ 데이터노드는 HDFS에 관한 지식이 없음.

 - 로컬파일시스템에 분리된 파일들로 HDFS 블록을 저장 

ㅇ 파일을 같은 디렉토리에 생성하지 않음 

 - 디렉토리당 최적의 파일수를 판단하고 서브디렉토리 생성 

ㅇ 블록레포트 : 네임노드가 시작할때(주기적으로) 로컬파일시스템에 있는 모든 HDFS 블록들을 검사후 정상적인 블록의 목록을 만들어 네임노드에 전송


ㅇ 블록 서버로서의 역할 

- 응용 프로그램의 데이터 저장 

- 블록의 메타 데이터 저장 

- 클라이언트에게 데이터와 메타데이터 제공 

ㅇ Block Report (주기적으로 NameNode로 전송, Namespace에게 replica들의 위치를 알림 )


ㅇ heartbeat 

- 주기적으로 NameNode로 전송 

- 해당 replica가 사용 가능함을 알림    


ㅇ handshake 

- 시스템 시작 동안 각 DataNode NameNode가 수행 

- Namespace ID DataNode S/W 버전 불일치 시 자동 종료   

- Handshake 성공 후, DataNode는 자신의 storage ID NameNode에 등록



4. HDFS client 

사용자 응용 프로그램이 파일시스템에 접근 위해 사용 




- HDFS 클라이언트가 파일을 read할 경우 

1)replica들의 목록 및 위치를 알기 위해 NameNode에 요청

2)클라이언트와 가장 가까이에 있는 replica 확인 

3)DataNode에 직접 접근하여 원하는 replica의 전송 요청 







- HDFS 클라이언트가 파일을 write할 경우 

1)replicas 생성을 위해 NameNode DataNode로부터 블록 할당 요청 ( 권한 체크 

2)DataNode가 파이프라인을 구성하면 클라이언트는 첫 블록에 데이터 전송 

3)전송 완료 후 클라이언트는 DataNode에게 다음 replica를 위한 새로운 블록 선택 요청 

4)새로운 파이프라인이 구성되고 클라이언트는 데이터 전송 

5)복제가 모두 끝나면 Ack 를 보내고 파일 쓰기를 완료한다.



- 파이프 라인 구성 및 데이터 전송 

1)DataNode로부터 replica 들을 위한 블록들이 할당됨 

2)DataNode는 클라이언트에서 마지막 replica블록 까지의 전체 네트워크 거리를 최소화 하는 파이프라인 형성 

3)패킷 버퍼가 가득 차면 데이터가 파이프라인에 push




NameNode 는 또 다른 역할을 가질수가 있는데 checkpointNode 또는 BackupNode 로서의 역할이다. 

5 CheckpointNode

- 주기적으로 새로운 checkpoint 생성 

ㅇ checkpoint + journal = new checkpoint, empty journal 

ㅇ 파일 시스템의 메타데이터 보호 위해 존재하는 역할


6 BackupNode

- 파일시스템의 블록 위치를 제외한 모든 메타데이터 정보를 갖고 있음 

- 항상 NameNode 상태와 동기화 유지 

ㅇ namespace의 최신 데이터를 내부 메모리에 유지 

ㅇ NameNode 결함 시 BackupNode namespace 복구 



7 Upgrades and Filesystem Snapshots

ㅇ HDFS에서 스냅샷 생성 목적 

ㅇ 시스템 시작 시 클러스터 관리자 선택에 의해 스냅샷 생성 

 클러스터의 각 DataNode storage 디렉토리의 복사본과 실제 존재하는 block파일들의 하드링크 생성 

ㅇ DataNode에서 블록 삭제는 단지 하드링크만 제거하고 수정 시에는 복사, 쓰기를 수행 


8  

마스터/슬레이브 구조 로 관리됨

• HDFS 클러스터( 1.NN + N.DN )

 # 마스터 - 단일 네임노드  : 파일 시스템 네임스페이스를 관리(메타데이터)  

* 클라이언트에 의한 파일접근을 통제  

* 데이터노드의 블록 매핑 


# 슬레이브 

- 많은 데이터노드  : 스토리지를 관리  

* 파일은 여러개의 블록으로 분리되며 여러개의 데이터노드에 저장  

* 네임노드의 지시에 따라 블록 생성, 삭제, 복제 수행



 File I/O Operations and Replica Management

1 File Read & Write

- 위의 Hdfs Client 에서의 Read & Write 참조 


2 Block Replacement

replica 배치 정책 목적 

ㅇ HDFS를 다른 분산 파일 시스템과 구분 시킴 

ㅇ 데이터의 안전성, 신뢰성, 가용성, 네트워크 대역폭 이용 극대화 


ㅇ 하나의 DataNode에는 같은 블록의 replica를 하나만 포함해야 함 





3 Replication Management

ㅇ 하나의 rack은 같은 블록 replica를 두 개 이상 포함하지 않아야 함 Block Placement 

- 첫번째 replica : 로컬 rack의 하나의 노드에 배치 

- 두번째 replica : 로컬 rack의 다른 노드에 배치 

- 마지막 replica : 두 번째와 같은 rack의 다른 노드에 배치

- 추가적인 replica는 랜덤으로 배치 (기본적으로 3개의 replica 사용복사본이 두 개 이상의 rack에 저장되므로 하드웨어 장애에 안정적

4 Balancer

- HDFS 클러스터에서 디스크 공간 사용을 위한 균형 도구임. 


5 Block Scanner

DataNode가 주기적으로 replica들을 검사하여 저장된 checksum이 블록 데이터와 일치하는지 확인하는 도구 

ㅇ 손상된 replica블록 감지 시 ( 데이터를 보존하는 것을 목표로 하는 정책임)

-NameNode에 알리고 NameNode는 해당 replica를 손상된 것으로 표시 하고 바로 삭제 하진 않고 블록의 정상 replica를 추가로 생성 한다. 

-replica들 중 절반이 손상된 replica가 될 경우에만 손상된 replica를 삭제




참고자료 

http://www.aosabook.org/en/hdfs.html

http://bcho.tistory.com/650




블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 



프로젝트를 해요?~~~

프로젝트 사업을 만든다, 

고객의 요구사항을 듣는다,

제안서를 작성한다, 

요구사항 분석서를 작성한다, 

고객의 요구사항 중 비기능 요구사항을 식별한다, 

비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 

아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 

개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 

위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요? 고객 또는 P.M 입니다. 

하지만, 실제 프로젝트를 수행하다보면 이런 행정상의 문제 혹은 정치적인 문제 뿐만이 아닌 기술적인 문제에서 우리는 누가 해야 할 지 모를 일을 두고 서로 모르는체 넘어가는 경우가 있습니다. 일명 ‘회색지대’ 라고 부르는 영역이죠. 저는 그런 영역을 책임지고 가이드하고 리드하는 조직이 아키텍처 팀이라고 생각을 합니다.

 


아키텍처팀은 리드 아키텍트와 시니어, 주니어 로 구성된 아키텍트로 구성이 됩니다. 

예전엔 ‘공통팀’ 이라고 불리웠던 팀이 프로젝트가 대형화되고 조직화 되면서 시스템의 아키텍처를 담당하는 팀이 있어야 하므로 존재하게 되었습니다. EA 의 정의에 나오는 AA, TA, BA, DA  의 조직일 수도 있고 Software Architecture 에서 이야기 하는 SA Team 일 수도 있습니다. 

어떻게 명명이 되던지 아키텍처팀은 조직마다 역할이 달라지는 경향이 있습니다. 해당 조직에서 어떻게 Architecture 라는 놈을 바라보느냐에 달려있는 것 같습니다. 

여러가지 이견이 있을 수 있지만, 일반적으로 엔터프라이즈급 프로젝트를 하면 EA 기반하에 진행되는 경우가 많습니다. 그래서 역할명도 도메인 설계에 관련된 역할은 Application Arhcitecture Team 이 인프라나 미들웨어 관련 역할은 Technical Architecture Team이 Data 관련 사항은 Data Architecture Team 이 책임을 가지게 됩니다. 

저는 EA 의 정의를 따르지 않고 순수하게 Software 를 바라보는 Software Architect 의 입장에서 SA Team 을 바라보고 거기에 따른 얘기를 하려고 합니다. 굳이 비교를 하자면 SA 가 EA에서 말하는 AA와 TA 를 연결하는 선상에 있다고 생각을 하고 싶습니다. 


일반적으로 프로젝트를 하다보면 ‘애매~~한’ 상황이 생기기 마련입니다

예를 들면… 

구현과 설계의 매핑이 되지 않아요? 구현 후에 테스트를 어떻게 할 지 모르겠어요? 개발 환경 설정은 어떻게 하죠? 도대체 에러가 어디서 발생하는 거에요? 로그는 어떻게 보죠? 테스트 데이타는 어디 있어요? 테스트를 이렇게 손과 눈으로 해야 하나요? 테스트 시나리오는 어디서 도출해야 하나요? 그게 맞는지 검증은 어떻게 하나요? 비즈니스 검증은 누가 해야 하나요? 버전이 도대체 뭐가 최종이에요? 커뮤니케이션 문제발생시 해결방법은 어떻게 해야 하나요? 조직 구성 ( off-shore 등 ) 의 특성에 따른 프로세스를 고려 하고 있나요? 이슈관리 , 위험 관리는 어떤 프로세스로 관리 해야 하나요?  관련 문서는 어디서 찾아봐야 하나요?


이런 이슈제기나 질문을 하는 경우가 있습니다. 요고 요고 애매~합니다. 이거 정해 드립니다. 

‘기술적인 의사결정이 필요한 경우’ 

요고 요고 애매 하죠? 누가 의사결정을 하느냐? 관리자냐? 고객이냐? 개발자냐?

네 그렇습니다. 요놈은 ‘아키텍처팀’ 이 합니다. 

‘String Utility 하나 만들어주세요.’ 요론거.. 요론거는 기술적인 의사 결정 아니죠? 이거는 아키텍처팀의 역할 아닙니다. 정말 ‘공통팀’ 이 하는 겁니다. 아마도 ‘아키텍처팀’ 의 하부조직으로 만드는 것이 좋을 것 같습니다. 

‘각 모듈 개발이 시작할 때 전체 관점에서 방향제시’ 네. 기술적인 방향제시, 전체 구조상의 방향제시. 요놈은 ‘아키텍처팀’ 이 하는 거 맞습니다. 

가끔 대략적인 컨셉만 주고 ‘각 모듈팀에서 알아서 하세요’ 하는 경우 있는데 이거 아닙니다. 아키텍처팀이 해야 합니다. 실제 아키텍처 팀에서는 스스로 내놓은 솔루션을 검증하기 위해 Pilot Test 를 필수로 진행해야 합니다. 


그렇다면 아키텍처팀의 존재 목적이 위의 두어가지 역할만 하면 되는 것인가? 

아마도 회사의 아키텍처팀 이냐 프로젝트의 아키텍처팀 이냐에 따라서 달라질 것입니다. 

어느 조직이든 간에 비슷한 역할은 정책결정, 기술리드, 리서치 및 솔루션 제시 , 품질에 대한 가이드, 학습조직 등의 역할을 하리라 생각이 됩니다.

 특히, 프로젝트 혹은 운영 팀의 경우 아키텍처를 담당하는 팀에서는 아래와 같은 사항이 기술적으로 집중적으로 관리 되어야 할 사항입니다. 

‘어느 개발자가 오더라도 개발환경 셋팅을 쉽게 하고 샘플을 개발할 수 있는 가이드 마련, 코드 표준 , 권한/로그 등의 표준 , 요구사항 추가/변경에 따른 기술적인 대안 마련 , 자동화된 테스트 구현을 위해 테스트 프레임워크 마련 , 자동화된 빌드 환경 구축’ 

이런 것들이 집중 관리되고 있어야 프로젝트 진행 중에 문제 발생 확률이 적어지리라 생각을 합니다. 


저는 프로젝트 초반의 역할이 정말 중요하다고 생각이 되는데요. 

‘기능/비기능 요구사항에 대한 수집, 프로젝트의 품질 요구사항에 적합한 기술구조 수립, stakeholder 별 뷰 작성, 필요한 기술구조에 대한 숙련자 선별 , 필요한 기술구조 학습, 품질 요구사항에 따른 대안 마련, 대안별 파일럿 작성, 프로토타이핑을 수행할 우선순위에 따른 모듈 선택, 빌드 프로세스 수립, 로그 표준 작성, 예외 표준 작성, 프로젝트 요건에 따른 대안 샘플링 테스트, 선정 모듈 프로토타이핑, 프로젝트 개발 템플릿 작성, 개발자 가이드 작성, 필요 도구 개발, 빌드 파일 개발, 테스팅 도구 개발’ 

등을 통해서 프로젝트 초반에 기틀을 확실히 하려고 노력해야 프로젝트 진행 중 위험요소가 적어질 수 있다고 생각을 합니다. 어느정도 아키텍처가 자리를 잡고 구성원 모두가 같은 뷰를 바라보게 되는 시점에서는 아키텍처팀의 분산이 일어나야 합니다. 그래서 프로토 타이핑 수행 후 각 모듈팀으로 아키텍처팀원들의 분산 & 기술 리더 역할을 수행하고 각 프로젝트 팀의 이슈사항들을 아키텍처 팀으로 피드백 반영을 하는 역할을 수행해야 합니다. 


아키텍처팀은 개발 프로세스에도 관여를 해야 합니다. 근래에는 전통적인 프로세스들과 애자일 프로세스가 양립하며 애자일 프로세스를 선호하는 조직도 많습니다. 따라서 애자일 프로세스의 실천법들을 프로젝트에 적용을 할 수 있는 선도 역할을 해야 합니다. 특히 TDD 나 Pair Programming 같은 부분에서는 아키텍처팀에서 먼저 실천을 해 볼 수 있으면 좋을 것이고 아니라해도 경험자적인 측면에서 아키텍트들의 리드가 필요할 수 있습니다. 


위의 나열한 여러가지 역할을 수행하기 위해서 아키텍처 팀의 필요 보유 역량으로는 

첫째로 품질요건 도출 및 솔루션 제시를 할 수 있어야 합니다. 즉, 요구사항 분석 내용에서 품질 속성 도출, Legacy 시스템 등 연동 요건에서의 품질 요소 도출, 아키텍트의 경험 및 운영자의 경험에서 비롯된 품질 속성 도출, 일반적인 Enterprise 기반 시스템에서의 품질 속성 도출 등의 Activity 를 통해서 품질속성들을 도출하고 해당 품질 속성을 만족시키기 위한 기술적인 요소들을 설계 할수 있어야 합니다. 그러기 위해서 아키텍처팀은 기술 트렌드 파악하는데 많은 학습을 필요로 합니다. 시장을 주도하는 기술 트렌드의 특징 및 속성에 대한 지속적인 정보를 파악해야 하고 , 전사 거버넌스 차원에서의 전략에 기반한 기술 트렌드 파악, 프레임워크 등의 세부 기술요소 들에 익숙해지고 숙달되어야 합니다. 

둘째로 프로젝트 진행중에는 여러가지 문제가 일어나는 만큼 문제 해결을 할 수 있는 역량 역시 중요합니다. 

WAS, ESB 등의 플랫폼 기술에 대한 기술 스펙, WAS 셋팅, 트러블 슈팅, 메모리 관리 원리, ESB 의 작동 원리, WebService , XML Parsing 기술, API 설계/구현 능력, 공통 API 설계 능력, Framework Wrapping, 기능 공통 구현 능력 등을 갖추려 노력해야 하고 실제로 실현함으로써 프로젝트 팀을 기술적으로 리드할 수 있습니다. 

셋째로 프로젝트의 기술적인 리드 입니다. 선장 없는 배가 흔들리듯이, 건축가 없는 건축물이 기초도 뼈대도 불안하듯이 소프트웨어 역시 튼튼한 기반을 갖추기 위한 소프트웨어 설계자가 필요합니다. 이런 몇가지 역량중에서도 가장 중요한 것은 역시 세번째의 기술적인 리드라 할 수 있겠습니다. 

이렇게 아키텍트팀이 갖춰야 할 역량은 많습니다. 그러나 S/W 아키텍트로서의 역할을 팀이 온전히 할 수 있려면 역시 기술적인 트렌드에 밝아야 하고 커뮤니케이션에 능통해야 합니다. 고객과의 커뮤니케이션은 물론이고 관리자와의 커뮤니케이션, 개발자를 리드할 수 있는 커뮤니케이션 능력, QA등의 Project Support 조직과의 커뮤니케이션 등이 아키텍처팀이 해야 할 커뮤니케이션이라 할 수 있습니다. 그리고 아키텍처가 틀이 잡히고 위험요소들에 대한 검증이 마무리가 되어가면 아키텍처 팀은 각 서브 프로젝트 팀으로 배치되어서 기술적인 리드를 수행하고 아키텍처팀에게는 역으로 피드백을 할 수 있는 선순환 고리가 마련이 되어야 할 것입니다. 


마지막으로 아키텍처 팀을 한마디로 정의 내려보자면

‘프로젝트의 기술적인 방향을 결정하지만, 실제로는 프로젝트의 각 영역간의 의사결정이 모호한 회색지대를 메우는 팀’ 이라고 정의를 하고 싶습니다. 


블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|





- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 

이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 

다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 


 




왜 아키텍트일까? 

흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅을 통해서 발전해 가는 것이 겨우 가능해 졌지만, 그 역시도 충분하지는 않다. 소프트웨어의 비가시적인 특성상 기 구축 사례를 보고 얻어내기가 쉽지만은 않다. 

갈수록 소프트웨어가 거대해지고 기술의 복잡도가 증가하며 난이도도 증가하고 있다.

거기에 근래의 환경은 클라우드 기반으로 모든 인프라가 돌진하고 있고 모바일,웹,하이브리드웹,RIA 등의 각종 환경적인 변화까지 가속도를 더해가고 있다. 

개발 패러다임으로 보자면 절차지향적인 패러다임에서 객체지향 패러다임 그리고 함수기반 언어들까지 맹위를 떨치고 있다.

UI의 기능은 날이 갈수록 강력해지고 사용하는 Device 의 종류도 너무 많아져서 모든 경우의 수를 다 대비해야 하는 현실이다. 

이런 기술의 홍수들 속에서 새로운 기술 패러다임의 본질을 꿰뚫고 복잡하고 다양하게 등장하고 있는 여러 기술 및 솔루션들의 특성과 장단점을 구체적으로 파악하여 IT 시스템 구축 프로젝트에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 소프트웨어 기술 전문가들이 필요하다. 이제는 아키텍트라는 역할이 어느 정도 보편화 되어 있고 아키텍처 팀을 만들어서 운영하는 기업들도 많아 졌다. 

아키텍트의 역할

그렇다면 아키텍트는 프로젝트에서 어떤 역할을 가져야 할까? 

일반적으로 아키텍트는 기술적인 문제에 대한 해결사의 역할을 요구 받는다.

개발 시스템의 전체 아키텍처를 수립하고 수립된 아키텍처를 중심으로 소프트웨어 시스템의 설계 및 구현과정을 선도하는 역할까지 담당한다. 

『Applied Software Architecture 』 에서 소개하는 소프트웨어 아키텍트의 역할에 대한 7가지 정의를 보면

비전제시자

IT 기술의 트렌드와 전망으로 토대로 고객의 요구를 만족하는 솔루션을 만들어내고 시스템의 명확한 모습을 그려냄을 통해 프로젝트 구성원에게 확신을 심어주는 역할을 할 수 있어야 한다. 

핵심기술조언자

프로젝트에서 수없이 맞닥뜨리는 이슈들과 위험, 문제들에 대해서 기술적인 조언을 하는 역할을 할 수 있는 역량을 갖추어야 할 것이다. 

의사결정자

기술 조언과 더불어 문제 해결에 대한 중요한 사안에 대한 의사 결정을 할 수 있어야 한다.

코치

수립된 아키텍처를 프로젝트 조직원 들에게 전파하고 정확하고 일관된 코칭을 통해 프로젝트 조직원들이 시스템을 구축 할 때 아키텍처와 일치할 수 있도록 해야 한다. 

조정자

프로젝트에서 일어나는 다양한 형태의 대립을 조정하는 조정자 역할을 할 수 있어야 한다. 

이때 기술적인 판단력과 더불어 커뮤니케이션 능력 역시 요구되게 된다. 

구현능력

아키텍트는 ‘한 줄의 코드로도 시스템의 성능을 높일 수 있는 자’ 혹은 ‘선도 구현을 통해 개발자를 리드하는 자’ 여야 한다. 

아키텍트는 자신이 수립한 아키텍처가 실제로 어떤 모습으로 구현될 것인지를 보여줄 수 있어야 한다. 이를 위해서 프로토타이핑을 통한 아키텍처의 검증 수행, 그 결과를 기반으로 아키텍처를 정제해야 한다. 

또한, 개발조직이 참조할 수 있는 표준, 샘플 소스 등을 통해서 개발자에게 가이드 역할을 해주어야 한다. 

대변자 

아키텍처가 소프트웨어 개발 프로젝트에서 차지하는 비중과 중요성을 지속적으로 전파하는 것을 말한다.

시스템에 질서를 부여하고 복잡함을 제어하기 위해서 아키텍트는 위의 일곱 가지 역할에 대한 역량을 가지고 일관된 비전과 의사결정을 통해 시스템이 아키텍처와 같은 모습으로 구현될 수 있도록 끊임없이 의사소통하고 가이드 해야 할 것이다. 

즉, 시스템의 아키텍처를 설계하고 설계 결과를 다양한 방식으로 검증하며 설계자/개발자들의 아키텍처 준수여부의 모니터링, sw 엔지니어를 리드하고 시스템 설계 의사 결정을 지속적으로 수행하며 기술에 꾸준한 관심을 가지고 해결능력을 배양하며 비즈니스와 개발팀간의 중재자 역할을 하는 사람을 아키텍트라고 할 수 있다. 


아키텍트의 자질과 역량


그래서 아키텍트에게 요구되는 자질은 

프로젝트의 목표를 명확하게 정의하고 이를 달성할 수 있는 방법을 정확하게 파악할 수 있는 통찰력,논리성,창의성 과 더불어 리더쉽, 의사소통 능력 , 기술력, 경험등이라고 생각을 하는데 이런 자질과 역량들을 갖추기 위해서 해야 할 것들은 무수히 많다.

기술적으로는 설계, 프로그래밍, 인프라구축, 명세수립, 테스트 방법, 요구사항정의, 품질관리, 비즈니스 이해

기술 외적으로는 인문학에 대한 이해와 커뮤니케이션 능력, 군림하는 것이 아닌 섬기는 리더쉽, 공감능력 등 이런 것들을 키우기 위해서 노력을 해야 할 것이다. 

그렇다면 프로젝트에서 아키텍트가 어떤 일을 해 줘야 할까? 

답은 없을 것이고 여러 책들에서도 소개가 이미 된 부분이고 필자가 이런 정의를 하는 것 자체가 어불성설 이긴 하지만, 아래의 기술된 Activity 정도는 해야 하지 않을까 한다. 


모든 사람이 아키텍처를 정확하게 활용할 수 있도록 아키텍처를 정의하고 문서화 및 배포하라.

아키텍처는 소프트웨어 프로젝트의 모든 시점에서 의사결정의 기준이 되고 방향 결정의 방향타 역할을 한다. 

모든 상황에서의 레퍼런스 역할을 하므로 아키텍처를 정확하게 활용가능한 수준으로 정의하여 배포해야 한다.

소프트웨어와 하드웨어가 조화를 이루도록 설계하라.

소프트웨어를 개발하는 것이 하드웨어를 배제하고는 이루어질 수 없다. 하드웨어 인프라 기반에서 소프트웨어가 동작하므로 하드웨어와 조화를 잘 이룰 수 있도록 하는 것이 필요하다. 특히 근래의 hadoop 으로 대표되는 클라우드 개발 쪽으로 가면 더더욱 필요하게 될 것이다.

개인적으로도 Computer Architecture 를 깊게 학습해야 하는 도전꺼리를 안고 있다. 기존에 소프트웨어만 알아도 되던 시대는 지나가고 하드웨어( CPU, Memory, Cache, N/W 등) 에 대한 지식이 아키텍트에게 요구되고 있다. 

아키텍처 전도사가 되라. 관리조직에게 아키텍처를 이해시켜라

아키텍처를 널리 알리고 구성원들이 동의할 수 있도록 전도하는 역할을 적극적으로 수행해야 한다. 또한, 관리조직부터 아키텍처를 이해하게 될 때 아키텍처를 통한 개발자의 구현이 아키텍처의 사상과 아키텍처의 제한사항을 충족 시킬 수 있도록 아키텍처에 대해서 구성원들에게 이해 시키고 공감대를 가지기 위해서 노력해야 한다. 

아키텍처와 일관되게 설계/구현 하는지 확인해라.;

아키텍처의 일관성에 대한 아키텍트의 노력은 절대로 과다함이 없다. 물론 융통성을 가지고 접근해야 하나 항상 아키텍처를 전파함을 통해서 아키텍처와 일관된 설계/구현이 될 수 있도록 리뷰하고 공감대를 가지려는 노력을 기울여야 할 것이다. 

시스템 환경이나 개발 툴 배포 등과 같은 문제를 제기하라

시스템 개발을 할 때 개발자가 환경셋팅이나 개발 툴에 대해서는 자유도를 가지고 개발자가 그 정도는 해야 하지 않겠느냐 라고 이야기 할수 있다. 그러나 시스템 개발이 팀 단위로 이뤄지고 팀간의 커뮤니케이션 까지 고려했을 때는 그에 대한 표준이 없다면 곤란할 것이다. 

개발자에게 배포하여 주어진 순서대로 실행하면 로컬에서 배포 테스트 가능할 정도의 환경을 미리 셋업해주려는 노력을 해야 한다. 

선도 개발 및 검증을 통해서 배포하는 역할을 직접 해야 한다. 

이해관계자를 찾아서 상호작용하고 요구를 만족시켜 주어라

아키텍처에 관련된 수많은 이해관계자들을 식별하고 그들과 상호작용해라.

그들 각자가 가진 요구사항들에 대해서 적극적으로 대처하고 솔루션을 제공하려고 노력해야 한다.

아키텍처를 만들 때 배치와 유지보수에도 적합하게 만들어라

아키텍처를 만든다는 것은 항상 해당 시스템을 생성시에 만들게 된다. 해당 작업의 특성상 아키텍트는 생성에 대한 경험만을 보유하고 있을 수도 있다.

그러나 아키텍처가 부여하는 효과가 유지보수 및 배치에도 있다는 것에 동의 한다면 유지보수가 가능하고 손쉬운 배포가 가능한 아키텍처를 만들려는 노력을 게을리 해선 안된다. 

기술문제를 해결하고 해당 논쟁과 상충하는 문제점들을 조율하라.

소프트웨어 아키텍트가 직면한 문제들은 비즈니스 적인 문제일 수도 있지만 가장 가까운 것은 기술문제이다.

해당 기술 문제를 해결하고 상충하는 문제들에 대한 논쟁에 대해서 조율하고 해결해라.

훌륭한 설계나 인상 깊은 발표를 통해 조직의 사기를 높여라.

훌륭한 설계를 하여 이해관계자들을 감동 시키고 개발자의 자기 계발 욕구를 만족시킨다면 이보다 좋을 순 없겠다. 

결과물이 좋은 것에 못지 않게 중요한 것은 훌륭한 발표이다. 이해관계자들에게 인상 깊은 발표를 통해서 감동을 주어라.

새로운 기술을 도입 시 시스템이 나아가야 할 방향을 이해하고 제시해라.

새로운 문제가 대두되면 새로운 기술들을 찾게 될 때가 있다. 

기술적인 트렌드는 계속 등장하고 그에 따른 변화의 흐름을 놓치지 않을 필요가 있다.

평소의 리서치와 리포트를 통해서 솔루션을 가질 수 있는 준비를 갖출 필요가 있다.

시스템의 기본 사상과 방향을 이해하고 조율하면서 새로운 기술들을 도입해야 한다. 

아키텍처와 관련된 위험을 찾아 대비하라.

아키텍처 설계자는 자신의 사상에 깊은 이해를 가지고 있으므로 시스템의 아키텍처로 인하여 발생되는 문제들에 대해서는 모를 가능성이 있다.

아키텍처 대안을 검토할 때 객관적인 입장에서 검토하고, 특정한 검증 프로세스를 통해서 아키텍처와 관련된 위험을 도출할 필요가 있다.



맺음말 


아키텍트들은 항상 아래와 같은 사항에 관심을 가진다. 

소프트웨어 품질 속성, 개발 프레임워크, 시스템 요소의 구성/관계, 공통기능과 개발 지원에 필요한 것들, 기술자와 비즈니스 관계자 사이의 조정자 역할, 기술자의 의견을 적절히 전달할 수 있는 쉬운 용어의 사용, 개발팀에의 리더쉽, 선 하나의 결정이 시스템 전체에 미치는 영향 등등. 


이런 모든 역할을 아키텍트 한 두명이 모두 할 수는 없다. 그리고 한 사람이 위의 능력들을 모두 가지기도 힘들 뿐더러 모두 갖추고 있다고 해도 프로젝트에서 주어지는 시간으로 따져보면 모든 역할을 해내기는 불가능하다. 언젠가 주변의 지인이 말한 것 처럼 ‘저 많은 것을 다 해야 해?’ 라는 생각으로 ‘현실적이지 않다’ 라고 말할 수도 있다. 

그러나 아키텍트가 프로젝트에서 해야 할 수많은 역할에 대한 이해를 가지고 노력을 해야 할 것이다. 

모두 다 할 순 없다. 모두 다 하는 것은 자연인 한 사람의 영역이 아닌 조직의 영역이라 할수 있을 것이다. 

다만, 역할에 따른 자질과 역량을 키우는 데 노력하다보면 언젠간 쓸만한 아키텍트가 되어 있지 않을까? 


블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|


마인드 맵으로 두어시간에 만들어봤습니다.





이거 말고 .... 현남선배가 publish 해 보라고 제안하신게 있는데 그건 나중에 다시 해 보겠습니다.
( 프레임워크 구현자 또는 프레임워크 전문가 와 아키텍처를 핸들링하는 역할과의 관계성에 대해서~~~ )
블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

"아키텍트 직무"
여기엔 수퍼맨처럼 묘사되지만.. 이런 능력을 모두 가질수가 있으면.. 이 글 보고 계시겠어요? ^^;;
이런 사상과 능력을 보유하기위해서 노력해야 하고.. 
각 역할이나 자질 중에서 몇개를 자신이 계발중인가? 또는 수행하고 있는가가 요점입니다. 
흔히 얘기하는 SW 설계자로서의 아키텍트를 얘기하고자 하는 마인드 맵이니...
그렇게 이해하고 키워드 위주로만 보시면 좋을 것 같습니다.

여기 저기서 참조하고 "아키텍트 이야기" 책에서 참조한 마인드 맵입니다.
참조할 수 있는 자료를 온라인에 오픈 해 주신 여러~ 분들에게 감사드립니다.

 

목차, 구성 사례는 조금 맞지 않을 수도 있습니다만,, 현업에서 일반적으로 사용되는 구성방식이다.. 라고 판단하시면 될 것 같구요.

( 물론 SAiP 2ed 나, DSA 에는 약간 다릅니다.. )

스프링 노트에서 올리면 이상하게 깨지고..
사내망에서 티스토리에는 글쓰기는 안되는데 이미지 업로드 후 수정은 되는군요

이미지 공유의 BP 가 필요해~~ ^^;; ( BP를 언젠가부터 무쟈게 좋아하게 되었다는.. 쩝.. )

 

 

 

.

블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|


신기술을 사용할 때
( 요즘 트렌드로 보면.... ) 신프레임웍을 도입할때 고려해야할 질문

 1. 이 기술이 실무에 잘 적용된다는 게 실험으로 완벽하게 증명됐는가?
2. 성공적이라는 것이 신기술 자체가 그렇다는 것인가? 아니면 사용하는 사람들이 성공적이었다는 것인가?
3. 신기술은 완벽한 것인가? 아니면 실무에 적용될 때 또 확장, 변경 해야하는 것인가?
4. 신기술이 연구실 환경에서 개발된 것이라면, 그것이 정말로 실세계 문제를 해결할 수 있을 것인가?
5. 신기술이 프로그래머의 사기를 저하시킬 가능성은 없는가?
6. 신기술을 잘못 적용할 수도 있는가?
7. 신기술을 사용함으로써 발생할 수 있는 위험 요소에 대해 설명한 자료가 있는가?
8. 신기술이 어떻게 실무와 통합되는지 기술한 자료가 있는가?
9. 의미있는 성과를 얻기 위해선 신기술이 완전히 적용되어야 하는가? 아니면 일부만 적용되어도 되는가?

-professional software development 

블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|


소프트웨어 아키텍처 문서화

에 대한 책이 나옵니다.

영어에 대한 이해도가 짧아서 원서를 읽고도 이해를 못하고 그냥 훑기만 했는데..
번역된다는 소식을 접한것이 작년 이맘때~
드디어 번역서가 출간 되었습니다.
Wow!
매우 흥분이 되네요.
강컴에서는 이미 예약을 받고 있습니다.
아키텍처 문서화를 어떻게 해야 할까를 고민하는 분에게는 정말 멋진 바이블이 우리의 언어로 재탄생한거죠.. ^^
솔직히 리뷰어를 통해서 진행하면 참가하고픈 마음이 굴뚝 같았으나~~~
Root 를 몰라서뤼~~

조만간 에이콘블로그를 통해서 공지도 나오겠군요.

지금 보고 잇는 책들이 좀 있어서 언제 주문하게 될지는 모르겠으나~
바쁘게 봐야겠습니다~

이 책을 보기 전에 꼭 봐야할 책이 있죠...

패턴 지향 소프트웨어 아키텍처 상세보기

소프트웨어 아키텍처 이론과 실제 상세보기

먼저 선행학습이 있으면 좋을 것 같습니다.

P.S. 태클 거는 사람들이 많아서... 책이 모든 것을 해결해 주지는 않습니다만~ 참고서적, 그리고 가이드 서적 정도는 되겠죠~
모든 것은 자신의 논리와 실행방법으로 체계화 시키는 것이 핵심이 아닐까 싶습니다.( 전 아직도... 이걸 찾아서 헤메고 있습니다.... OTUL.... )


블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

재미있는 세미나를 손영수님이 기획하셨네요.
박현철 이사님에게 적극적으로 구애하신듯,,,

좋은 인연을 페이퍼미팅때 만드셨네요~
좋은 행사 감사합니다.


 
책에서 말하지 않는 이야기는 여러 가지가 있다. 허접해서 차마 말할 수 없는 것(에구, 찔끔). 내용이 어렵거나 방대해서(수조원 이상?) 짧은 지면으로는 녹여내기 어려운 사항들. 국가 또는 기업의 기밀 유지가 필요한 사항들(국방, 비자금?)... 꼭 이런 것들이 아니라도, 책이라는 일방적인 매체를 통해 실제 발생하는 프로젝트 상황을 명확하게 전달하기는 어렵고, 일 잘하는 사람들이 의외로 글재주가 없는 경우가 많아 좋은 지식이 전달되기 어렵고, 일은 진짜 못하지만 글재주가 비상한 경우는... 열심히 읽을 때는 좋았는데, "그래서?"라는 의문만 남는다...

"책에서 들려주지 않는 아키텍트 이야기"라는 세미나를 통해, 그 동안 많은 사람들이 접하지 못했을, 실제 경험을 통해 얻어왔던 지식들을, 부족하지만... 전달하고자 한다.
주 제 Meet The Architect : 책에서 들려주지 않는 아키텍트 이야기
개최일시 2008년 8월 23일 15:00~18:00
장소 한국 마이크로소프트 Potential Room (포스코센터 서관 5층)
참가대상 아키텍트와 만나고 싶은 사람
강사소개 박현철 - 투이 컨설팅 이사, 건국대학교 컴퓨터공학과 겸임 교수
내용수준 최상급
가 격 무료
시 간 Session 강 좌 제 목
15:00 ~ 15:50 50분 Session 1 니 경험 있나? 내도 있다.
15:50 ~ 16:00 10분 휴식
16:00 ~ 16:50 50분 Session 2 중요한 것은 뭐고, 중요하다는 것은 또 뭔데?
16:50 ~ 17:00 10분 휴식
17:00 ~ 17:50 50분 Session 3 그래서 어떻게 하라고?
* 각 섹션의 쉬는 시간은 유연성 있게 조절합니다.
Session 1 : 니 경험 있나? 내도 있다.
[역할]
Programmer, Modeler, Product Tester, Development/Operation Manager, Team Leader, Auditor, Process Consultant, Project Consultant, Mentor, Architect, PMO...

[프로젝트]
100% Round-Trip + WAN구간 Component 운용 + 2Phase Commit 이게 될까?
13만 사용자 + 2500개 유관 기관 + 270조 돈관리... 하기.
멀티코아 장착 휴대폰을 위한 소프트웨어 프레임워크를 칩에 꿉기.
인도/소련/미국/중국/동남아... 등 다국적 팀 구성, Java, Finance, No ER Really?
제품 하나에서 COM, CORBA, EJB, One source I18N... 모두 지원하기....
Session 2 : 중요한 것은 뭐고, 중요하다는 것은 또 뭔데?
기술? Yes!
패턴? Yes!
메타? Y... Yes!
규모? Y... Yes!
방법론? Y... Yes!
시장? Ye...Ye... Yes!
품질? Ye...Ye... Yes!
사람? Yes! Yes?
한국? Yes! Yes???
Session 3 : 그래서 어떻게 하라고?
Needs & Trade-off
Organization
Requirement
Technology
Software Paradigm & Architecture
Function driven
Data driven
Object driven
Component driven
Service driven
+ Aspect driven, Test driven, Agile driven
Planning, Infrastructure & Operation

[선릉역 1번 출구 ] 포스코센터 서관 5층

- 행사 협찬 : 한국마이크로소프트

- 세미나 당일 주차는 지원되지 않습니다. 가급적이면 대중교통을 이용하여 주시기 바랍니다.
- 문 의 : 02-511-4824(#218)


*** 회원님들의 많은 참여로 세미나 신청을 마감합니다. ***

블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|

손영수님의 http://arload.wordpress.com 블로그에서 발췌하여 개재합니다.

항상 패턴 관련하여 새로운 소식과 몰랐던 것들을 알려주셔서 감사드립니다.

지금껏 패턴을 이해할 수 있는 수준이면 되지 뭐 라고 생각했으나,

이젠 조금씩 공부해 놓아야 할 필요성을 느끼고 있습니다.


========================================================

패턴 학회 PLOP를 아시나요?

1994년 부터 시작된 패턴을 공유하고 활성화하기 위한 Conference로

객체 지향의 유명한 Conference인 OOPSLA와 같은 장소에서 연이어 열립니다.

PLOP 08

우리가 알고 있는 유명한 Pattern 서적의 저자라면 이곳을 이미 다 거쳐갔습니다.

GoF의 Ralph Johnson, POSA 2의 Douglas C. Schmidt이 이곳에서 두드러진 활동을 보여 주시고 계시며,

패턴 계의 거룩한 전설인 POSA 시리즈를 비롯해,

요즘 나온 패턴 서적들인 XUnit Test Pattern, Patterns for Fault Tolerant Software

여러분이 알고 있는 많은 패턴들이 이 학회를 통해 먼저 소개 되고, 검증 받았다는 것입니다.

많은 분들이 아키텍트에게 패턴이 꼭 필수적이지 않다고 말하시지만,

이것은 인류가 만든 지식 공유의 철학과 가치를 무시하는 처사입니다.

이미 탑을 쌓기 위한 좋은 가이드라인이 있는데, 왜 그 가이드라인을 무시하고 처음부터 탑을 쌓으실려고 하는걸까요?

패턴에 대한 불신을 가지는 이유 에 대해서 매체를 통해 언급한 적이 있지만,

좋은 소프트웨어를 만들기 위해서는 반드시 익혀야할 초식이라고 할수 있겠습니다.

그 지식의 결과들을 여러분에게 공유합니다.

PLoP 2007 [Online proceedings]

PLoP 2006 [Online proceedings]

PLoP 2005 [Online proceedings]

PLoP 2004 [Online proceedings]

PLoP 2003 [Online proceedings]

PLoP 2002 [Online proceedings]

PLoP 2001 [Online proceedings]

2000 [Online proceedings]

1999 [Online proceedings]

1998 [Online proceedings]

1997 [Online proceedings]

1996

1995

1994



그리고 EuroPLOP, ChilliPLOP와 같은 각 대륙권 PLOP가 또 있으니

관심있는 분은 http://www.hillside.net 을 방문하시길 바랍니다.

그중  EuroPLoP는 유럽인들을 위해 열린 PLOP 행사로서, 매년마다 꾸준히 열리는 패턴 학회입니다.  PLoP 본행사 못지 않게 유용한 패턴이 많이 발표되는 학회입니다. 


EuroPLOP Paper List

블로그 이미지

[짱가™]

그 두번째 이야기 | 아키텍처에 대한 단상, 그리고 살아가는 이야기 | 대한 민국 아키텍트로 가는 길 | 열정전도사 "짱가|