AOSA 1권 9장. CI 정리
http://www.aosabook.org/en/integration.html
| AOSA 1권 9장. CI 정리 (0) | 2012/10/12 |
|---|---|
| AOSA 1권. 8장 HDFS 정리 (0) | 2012/10/04 |
| 엔터프라이즈 환경에서 아키텍처 팀의 역할 (0) | 2012/07/08 |
| 아키텍트의 역할과 자질에 대한 고찰 (0) | 2012/07/08 |
| 프로젝트 에서 아키텍처 팀의 역할 (0) | 2011/04/20 |
| 아키텍트 직무 역할 (3) | 2011/03/22 |
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
| AOSA 1권 9장. CI 정리 (0) | 2012/10/12 |
|---|---|
| AOSA 1권. 8장 HDFS 정리 (0) | 2012/10/04 |
| 엔터프라이즈 환경에서 아키텍처 팀의 역할 (0) | 2012/07/08 |
| 아키텍트의 역할과 자질에 대한 고찰 (0) | 2012/07/08 |
| 프로젝트 에서 아키텍처 팀의 역할 (0) | 2011/04/20 |
| 아키텍트 직무 역할 (3) | 2011/03/22 |
나는 지식 노동자다.
그래. 노동자다.
아직 비즈니스를 만들고 어쩌고는 ... 뭐 먼 나라 얘기다.
엔지니어 이다. 라고는 말하지만, 예전의 기준으로 보면 배운놈이 하는 일을 하는 거다.
다만, 기술을 가지고 하니깐,,,, 엔지니어니 뭐니... 하는 거다.
자신의 지식을 가지고 모니터와 대화하고 같은 지식 배경을 가진 사람들과 갑론을박 하면서 살아가는 이 세상에서 늘어가는 것은 기술과 자신의 지식에 대한 자부심과 아집일듯 하다.
'지식 노동자' 란 내가 가진 지식으로 인정을 받고 싶어하는 사람일게다.
그러다 보니 자기도 모르게 상대방을 누르려고 하기도 하고 자신의 영향력을 키우기 위한 행동을 하게 되기도 한다.
아직도 인정받지 못하면 자괴감과 더불어 '그 자리에 내가 왜 있나?' 를 생각하기도 한다.
그래도 자존심을 세우나 보다.
그런데...근래 들어서 그런 기술적인 다툼을 피하려고 하는 내 모습을 자주 발견한다.
솔직히 솔루션 이라는 것이 어떤 방법을 사용하든 된다 돼!
어떻게든... 그게 효율적이든 효율적이지 않든.
| 지식노동자 로서의 당면 과제 (0) | 2012/08/02 |
|---|---|
| [읽기 좋은 코드가 좋은 코드다] 1장. 코드는 이해하기 쉬워야 한다. (0) | 2012/07/16 |
| [책정리]읽기 좋은 코드가 좋은 코드다 (0) | 2012/07/14 |
| computer driven communication (?) (1) | 2012/07/10 |
| 애자일 프로세스를 접하는 우리의 자세 (0) | 2012/03/31 |
| 전역상태와 public 메타포 - junitInAction2 에서 (0) | 2012/03/13 |
코드는 이해하기 쉬워야 해!
무엇이 코드를 '더 좋게' 만들까?
return exponent >=0 ? mantissa *(1 << exponent) : mantissa / (1 << -exponent);
위 코드가 더 보기 좋은가? 아니면 아래의 코드가 더 보기 좋은가?
if ( exponent >= 0 )
return mantissa * (1 << exponent);
else
return mantissa / ( 1 << -exponent );
- 정답은 없다. 관습의 차이와 사람의 흔한 습관적인 부분일 수도 있다.
- 나는 적어도 두번째가 내 눈에 잘 들어온다.
가독성의 기본
- 코드는 다른 사람이 그것을 이해 하는데 들이는 시간을 최소화 하는 방식으로 작성되어야 한다.
분량이 적으면 항상 좋은가?
- 예전 환경에서는 어땠을 지 모른다. 하지만, 현재의 환경 (display, memory 등의 변화) 에서는 별 무리 없이 모든 것들이 수행되게 된다.
- 오히려 변수를 길게 서술형으로 쓰는 유명인들도 꽤 있다.
그!러!나! 실천하기 어려운 부분이 있다.
- 상상속에서 다른 사람이 내 코드를 읽는 다고 생각하면 당연히 추가적인 시간과 노력이 들고 ,
지금까지와는 다른 사고방식이 필요하게 된다.
자... 하지만, 이런 목표를 받아들여서 스스로를 자랑스럽게 해보자.
| 지식노동자 로서의 당면 과제 (0) | 2012/08/02 |
|---|---|
| [읽기 좋은 코드가 좋은 코드다] 1장. 코드는 이해하기 쉬워야 한다. (0) | 2012/07/16 |
| [책정리]읽기 좋은 코드가 좋은 코드다 (0) | 2012/07/14 |
| computer driven communication (?) (1) | 2012/07/10 |
| 애자일 프로세스를 접하는 우리의 자세 (0) | 2012/03/31 |
| 전역상태와 public 메타포 - junitInAction2 에서 (0) | 2012/03/13 |
( 맨날 뭐 하려고 하면 거창하게 생각하고 거창하게 시작해서 아무것도 못하는 것 같아서...
스텝 바이 스텝으로 천천히 생각하기로 했다.
오늘부터 한 챕터씩 '읽기 좋은 코드가 좋은 코드다' 를 정리해보기로 했다.
'소설처럼 읽히는 코드' - 이게 내 평소 지론이다.
이것을 도와주는 책으로는 국내 책중에는 현재까지는 Clean Code 가 최고였다만,,,,
이 책 역시 던져주는 메시지가 꽤 좋으므로... 정리.
목차는 다음과 같다.
1장. 코드는 이해하기 쉬워야 한다 01. 무엇이 코드를 '더 좋게' 만드는가? 02. 가독성의 기본 정리 03. 분량이 적으면 항상 더 좋은가? 04. 이해를 위한 시간은 다른 목표와 충돌하는가? 05. 어려운 부분 PART I. 표면적 수준에서의 개선 2장. 이름에 정보 담기 01. 특정한 단어 고르기 02. tmp나 retval 같은 보편적인 이름 피하기 03. 추상적인 이름보다 구체적인 이름을 선호하라 04. 추가적인 정보를 이름에 추가하기 05. 이름은 얼마나 길어야 하는가? 06. 이름 포메팅으로 의미를 전달하라 요약 3장. 오해할 수 없는 이름들 01. 예: Filter() 02. 예: Clip(text, length) 03. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라 04. 경계를 포함하는 범위에는 first와 last를 사용하라 05. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라 06. 불리언 변수에 이름 붙이기 07. 사용자의 기대에 부응하기 08. 예: 이름을 짓기 위해서 복수의 후보를 평가하기 요약 4장. 미학 01. 미학이 무슨 상관인가? 02. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기 03. 메소드를 활용하여 불규칙성을 정리하라 04. 도움이 된다면 코드의 열을 맞춰라 05. 의미 있는 순서를 선택하고 일관성 있게 사용하라 06. 선언문을 블록으로 구성하라 07. 코드를 '문단'으로 쪼개라 08. 개인적인 스타일 대 일관성 요약 5장. 주석에 담아야 하는 대상 01. 설명하지 말아야 하는 것 02. 생각을 기록하라 03. 코드를 읽는 사람의 입장이 되어라 04. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라 요약 6장 명확하고 간결한 주석 달기 01. 주석을 간결하게 하라 02. 모호한 대명사는 피하라 03. 엉터리 문장을 다듬어라 04. 함수의 동작을 명확하게 설명하라 05. 코너케이스를 설명해주는 입/출력 예를 사용하라 06. 코드의 의도를 명시하라 07. 이름을 가진 함수 파라미터 주석 08. 정보 축약형 단어를 사용하라 요약 PART II. 루프와 논리를 단순화하기 7장. 읽기 쉽게 흐름제어 만들기 01. 조건문에서 인수의 순서 02. if/else 블록의 순서 03. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현 04. do/while 루프를 피하라 05. 함수 중간에서 반환하기 06. 악명 높은 goto 07. 중첩을 최소화하기 08. 실행 흐름을 따라올 수 있는가? 요약 8장. 거대한 표현을 잘게 쪼개기 01. 설명 변수 02. 요약 변수 03. 드모르간의 법칙 사용하기 04. 쇼트 서킷 논리 오용하기 05. 예: 복잡한 논리와 씨름하기 06. 거대한 구문 나누기 07. 표현을 단순화하는 다른 창의적인 방법들 요약 9장. 변수와 가독성 01. 변수 제거하기 02. 변수의 범위를 좁혀라 03. 값을 한 번만 할당하는 변수를 선호하라 04. 마지막 예 요약 PART III. 코드 재작성하기 10장. 상관없는 하위문제 추출하기 01. 소개를 위한 예: findClosestLocation() 02. 순수한 유틸리티 코드 03. 일반적인 목적의 코드 04. 일반적인 목적을 가진 코드를 많이 만들어라 05. 특정한 프로젝트를 위한 기능 06. 기존의 인터페이스를 단순화하기 07. 자신의 필요에 맞춰서 인터페이스의 형태를 바꾸기 08. 지나치게 추출하기 요약 11장. 한 번에 하나씩 01. 작업은 작을 수 있다 02. 객체에서 값 추출하기 03. 더 큰 예제 요약 12장. 생각을 코드로 만들기 01. 논리를 명확하게 설명하기 02. 라이브러리를 알면 도움이 된다 03. 논리를 쉬운 말로 표현하는 방법을 더 큰 문제에 적용하기 요약 13장. 코드 분량 줄이기 01. 그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다 02. 요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라 03. 코드베이스를 작게 유지하기 04. 자기 주변에 있는 라이브러리에 친숙해져라 05. 예: 코딩 대신 유닉스 도구를 활용하기 요약 PART IV. 선택된 주제들 14장. 테스트와 가독성 01. 읽거나 유지보수하기 쉽게 테스트를 만들어라 02. 이 테스트는 어떤 점이 잘못되었을까? 03. 이 테스트를 더 읽기 쉽게 만들기 04. 읽기 편한 메시지 만들기 05. 좋은 테스트 입력값의 선택 06. 테스트 함수에 이름 붙이기 07. 이 테스트 코드는 무엇이 잘못되었는가? 08. 테스트에 친숙한 개발 09. 지나친 테스트 요약 15장. '분/시간 카운터'를 설계하고 구현하기 01. 문제 02. 클래스 인터페이스 정의하기 03. 시도1: 순진한 해결책 04. 시도2: 컨베이어 벨트 설계 05. 시도3: 시간-바구니 설계 06. 3가지 해결책 비교하기요약
| 지식노동자 로서의 당면 과제 (0) | 2012/08/02 |
|---|---|
| [읽기 좋은 코드가 좋은 코드다] 1장. 코드는 이해하기 쉬워야 한다. (0) | 2012/07/16 |
| [책정리]읽기 좋은 코드가 좋은 코드다 (0) | 2012/07/14 |
| computer driven communication (?) (1) | 2012/07/10 |
| 애자일 프로세스를 접하는 우리의 자세 (0) | 2012/03/31 |
| 전역상태와 public 메타포 - junitInAction2 에서 (0) | 2012/03/13 |
사용자 추가 하다가... 기록.
이전 5.0 대 버전에서의 사용자 추가는 아래같은 설정으로 우분투에서 추가했었다.
( mysql server setting )$ sudo apt-get install mysql-server mysql-clientroot 패스워드 : root 로 설정sudo vi /etc/mysql/my.cnf#bind-address = 127.0.0.1 --> 로 처리
sudo /etc/init.d/mysql restart
mysql -u root -p
use mysql
select host, user from user ;#사용자추가INSERT INTO user (Host, User, Password) VALUES ('%','root',password('root'));INSERT INTO user (Host, User, Password) VALUES ('localhost', 'myuser', password('myuser'));
그런데 5.5 버전에서는 이외의 필드들이 모두 필수가 되었는지 insert 가 되지 않는다.
http://blog.naver.com/lawofbest?Redirect=Log&logNo=100140706664
블로그를 참고하고...
아래의 사용자 추가 명령으로 사용자를 추가.
create user 'myuser'@'%' identified by 'myuser';
grant all privileges on *.* to 'myuser'@'%';
mac 에서의 설치는 http://j07051.tistory.com/377 를 참고.
| mysql5.5 초기 설정(사용자추가) (0) | 2012/07/12 |
|---|---|
| HTTP 1.1 status codes (0) | 2008/10/10 |
| Document 생성하기 (0) | 2008/08/20 |
일을 하면서 대화를 하다보면 최초에 이야기 한 것과 달라져서 당황해 하는 나를 발견할 때가 있다.
우리가 어떤 일을 처리하거나 서로간의 대화를 통해서 이야기를 풀어나가는 프로세스를 분석하고 싶어졌다.
나는 프로그래머다.
정확한 정보가 없으면 솔루션을 제시할 수도 해결의 단초를 생각하기도 힘들다.
때로는 해결책을 겨우 생각해 내고 이야기를 진행해 가는데 진행하다보면 전혀 다른 문제여서 접근법을 달리 해야 한다는 생각이 들때 당황하면서 상대를 질책하게 된다.
그렇기 때문에 Garbage in garbage out 의 규칙에 생각조차도 얽매여 있는 것 같다는 생각이 든다.
반대로 컨설팅 및 멘토링의 프로세스는 무언가를 꺼내어 놓을 지 모르는 상대방을 탐구하고 상대방과 대화를 하면서 욕구를 끄집어 내는 것을 먼저 진행한다.
엔지니어로서의 내 대화법 및 사고 방식은 전자를 많이 따라가다 보니 지인들과의 문제 해결에 대한 대화를 나누다가 충돌할 때가 가끔 있다. 나도 모르게 상대방을 질책하고 있다.
충분한 정보를 주지 않아서 전혀 다른 곳으로 방향진행이 되고 있었기 때문이다.
상대에게서 올바른 정보를 얻어내려면
배경/목적/환경/현황 등을 명확하게 이야기 해야 답을 얻을 수 있다는 생각을 함으로써 일어나는 일들이다.
그런데 내가 너무 기계 혹은 컴퓨터 적인 사고에 빠져서 살고 있는 건 아닌가? 하는 생각이 들었다.
원래의 내 성향(잔소리 많은) 이 좌우 했겠지만,
고기를 직접 잡아 주는 것 보다는 같이 접근해 나가는 방향을 선호하는 성향도 좌우했겠지만,
그것보다 먼저 말한대로 사고/접근법 자체가 사람을 대하는 컨설팅/멘토링 의 형태가 아닌
input 을 통한 output 을 도출해 나가는 데에 너무 익숙해서 일어나는 일이 아닐까 싶은 생각이.. 번뜩....
고민해 볼일이다.
| [읽기 좋은 코드가 좋은 코드다] 1장. 코드는 이해하기 쉬워야 한다. (0) | 2012/07/16 |
|---|---|
| [책정리]읽기 좋은 코드가 좋은 코드다 (0) | 2012/07/14 |
| computer driven communication (?) (1) | 2012/07/10 |
| 애자일 프로세스를 접하는 우리의 자세 (0) | 2012/03/31 |
| 전역상태와 public 메타포 - junitInAction2 에서 (0) | 2012/03/13 |
| 맥에서 파이썬 입문하기-3 (0) | 2011/12/10 |
- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다.
프로젝트를 해요?~~~
프로젝트 사업을 만든다,
고객의 요구사항을 듣는다,
제안서를 작성한다,
요구사항 분석서를 작성한다,
고객의 요구사항 중 비기능 요구사항을 식별한다,
비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다,
아키텍처를 설계하고 검증을 위한 선도 개발을 한다 ,
개발 표준을 제시하고 개발 표준의 준수여부를 체크한다.
위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요? 고객 또는 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 조직과의 커뮤니케이션 등이 아키텍처팀이 해야 할 커뮤니케이션이라 할 수 있습니다. 그리고 아키텍처가 틀이 잡히고 위험요소들에 대한 검증이 마무리가 되어가면 아키텍처 팀은 각 서브 프로젝트 팀으로 배치되어서 기술적인 리드를 수행하고 아키텍처팀에게는 역으로 피드백을 할 수 있는 선순환 고리가 마련이 되어야 할 것입니다.
마지막으로 아키텍처 팀을 한마디로 정의 내려보자면
‘프로젝트의 기술적인 방향을 결정하지만, 실제로는 프로젝트의 각 영역간의 의사결정이 모호한 회색지대를 메우는 팀’ 이라고 정의를 하고 싶습니다.
| AOSA 1권 9장. CI 정리 (0) | 2012/10/12 |
|---|---|
| AOSA 1권. 8장 HDFS 정리 (0) | 2012/10/04 |
| 엔터프라이즈 환경에서 아키텍처 팀의 역할 (0) | 2012/07/08 |
| 아키텍트의 역할과 자질에 대한 고찰 (0) | 2012/07/08 |
| 프로젝트 에서 아키텍처 팀의 역할 (0) | 2011/04/20 |
| 아키텍트 직무 역할 (3) | 2011/03/22 |
- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만,
이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다.
다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ.
왜 아키텍트일까?
흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅을 통해서 발전해 가는 것이 겨우 가능해 졌지만, 그 역시도 충분하지는 않다. 소프트웨어의 비가시적인 특성상 기 구축 사례를 보고 얻어내기가 쉽지만은 않다.
갈수록 소프트웨어가 거대해지고 기술의 복잡도가 증가하며 난이도도 증가하고 있다.
거기에 근래의 환경은 클라우드 기반으로 모든 인프라가 돌진하고 있고 모바일,웹,하이브리드웹,RIA 등의 각종 환경적인 변화까지 가속도를 더해가고 있다.
개발 패러다임으로 보자면 절차지향적인 패러다임에서 객체지향 패러다임 그리고 함수기반 언어들까지 맹위를 떨치고 있다.
UI의 기능은 날이 갈수록 강력해지고 사용하는 Device 의 종류도 너무 많아져서 모든 경우의 수를 다 대비해야 하는 현실이다.
이런 기술의 홍수들 속에서 새로운 기술 패러다임의 본질을 꿰뚫고 복잡하고 다양하게 등장하고 있는 여러 기술 및 솔루션들의 특성과 장단점을 구체적으로 파악하여 IT 시스템 구축 프로젝트에 올바르게 적용함으로써 프로젝트의 성공과 수익성 제고에 기여할 수 있는 능력을 갖춘 소프트웨어 기술 전문가들이 필요하다. 이제는 아키텍트라는 역할이 어느 정도 보편화 되어 있고 아키텍처 팀을 만들어서 운영하는 기업들도 많아 졌다.
아키텍트의 역할
그렇다면 아키텍트는 프로젝트에서 어떤 역할을 가져야 할까?
일반적으로 아키텍트는 기술적인 문제에 대한 해결사의 역할을 요구 받는다.
개발 시스템의 전체 아키텍처를 수립하고 수립된 아키텍처를 중심으로 소프트웨어 시스템의 설계 및 구현과정을 선도하는 역할까지 담당한다.
『Applied Software Architecture 』 에서 소개하는 소프트웨어 아키텍트의 역할에 대한 7가지 정의를 보면
비전제시자
IT 기술의 트렌드와 전망으로 토대로 고객의 요구를 만족하는 솔루션을 만들어내고 시스템의 명확한 모습을 그려냄을 통해 프로젝트 구성원에게 확신을 심어주는 역할을 할 수 있어야 한다.
핵심기술조언자
프로젝트에서 수없이 맞닥뜨리는 이슈들과 위험, 문제들에 대해서 기술적인 조언을 하는 역할을 할 수 있는 역량을 갖추어야 할 것이다.
의사결정자
기술 조언과 더불어 문제 해결에 대한 중요한 사안에 대한 의사 결정을 할 수 있어야 한다.
코치
수립된 아키텍처를 프로젝트 조직원 들에게 전파하고 정확하고 일관된 코칭을 통해 프로젝트 조직원들이 시스템을 구축 할 때 아키텍처와 일치할 수 있도록 해야 한다.
조정자
프로젝트에서 일어나는 다양한 형태의 대립을 조정하는 조정자 역할을 할 수 있어야 한다.
이때 기술적인 판단력과 더불어 커뮤니케이션 능력 역시 요구되게 된다.
구현능력
아키텍트는 ‘한 줄의 코드로도 시스템의 성능을 높일 수 있는 자’ 혹은 ‘선도 구현을 통해 개발자를 리드하는 자’ 여야 한다.
아키텍트는 자신이 수립한 아키텍처가 실제로 어떤 모습으로 구현될 것인지를 보여줄 수 있어야 한다. 이를 위해서 프로토타이핑을 통한 아키텍처의 검증 수행, 그 결과를 기반으로 아키텍처를 정제해야 한다.
또한, 개발조직이 참조할 수 있는 표준, 샘플 소스 등을 통해서 개발자에게 가이드 역할을 해주어야 한다.
대변자
아키텍처가 소프트웨어 개발 프로젝트에서 차지하는 비중과 중요성을 지속적으로 전파하는 것을 말한다.
시스템에 질서를 부여하고 복잡함을 제어하기 위해서 아키텍트는 위의 일곱 가지 역할에 대한 역량을 가지고 일관된 비전과 의사결정을 통해 시스템이 아키텍처와 같은 모습으로 구현될 수 있도록 끊임없이 의사소통하고 가이드 해야 할 것이다.
즉, 시스템의 아키텍처를 설계하고 설계 결과를 다양한 방식으로 검증하며 설계자/개발자들의 아키텍처 준수여부의 모니터링, sw 엔지니어를 리드하고 시스템 설계 의사 결정을 지속적으로 수행하며 기술에 꾸준한 관심을 가지고 해결능력을 배양하며 비즈니스와 개발팀간의 중재자 역할을 하는 사람을 아키텍트라고 할 수 있다.
아키텍트의 자질과 역량
그래서 아키텍트에게 요구되는 자질은
프로젝트의 목표를 명확하게 정의하고 이를 달성할 수 있는 방법을 정확하게 파악할 수 있는 통찰력,논리성,창의성 과 더불어 리더쉽, 의사소통 능력 , 기술력, 경험등이라고 생각을 하는데 이런 자질과 역량들을 갖추기 위해서 해야 할 것들은 무수히 많다.
기술적으로는 설계, 프로그래밍, 인프라구축, 명세수립, 테스트 방법, 요구사항정의, 품질관리, 비즈니스 이해
기술 외적으로는 인문학에 대한 이해와 커뮤니케이션 능력, 군림하는 것이 아닌 섬기는 리더쉽, 공감능력 등 이런 것들을 키우기 위해서 노력을 해야 할 것이다.
그렇다면 프로젝트에서 아키텍트가 어떤 일을 해 줘야 할까?
답은 없을 것이고 여러 책들에서도 소개가 이미 된 부분이고 필자가 이런 정의를 하는 것 자체가 어불성설 이긴 하지만, 아래의 기술된 Activity 정도는 해야 하지 않을까 한다.
모든 사람이 아키텍처를 정확하게 활용할 수 있도록 아키텍처를 정의하고 문서화 및 배포하라.
아키텍처는 소프트웨어 프로젝트의 모든 시점에서 의사결정의 기준이 되고 방향 결정의 방향타 역할을 한다.
모든 상황에서의 레퍼런스 역할을 하므로 아키텍처를 정확하게 활용가능한 수준으로 정의하여 배포해야 한다.
소프트웨어와 하드웨어가 조화를 이루도록 설계하라.
소프트웨어를 개발하는 것이 하드웨어를 배제하고는 이루어질 수 없다. 하드웨어 인프라 기반에서 소프트웨어가 동작하므로 하드웨어와 조화를 잘 이룰 수 있도록 하는 것이 필요하다. 특히 근래의 hadoop 으로 대표되는 클라우드 개발 쪽으로 가면 더더욱 필요하게 될 것이다.
개인적으로도 Computer Architecture 를 깊게 학습해야 하는 도전꺼리를 안고 있다. 기존에 소프트웨어만 알아도 되던 시대는 지나가고 하드웨어( CPU, Memory, Cache, N/W 등) 에 대한 지식이 아키텍트에게 요구되고 있다.
아키텍처 전도사가 되라. 관리조직에게 아키텍처를 이해시켜라
아키텍처를 널리 알리고 구성원들이 동의할 수 있도록 전도하는 역할을 적극적으로 수행해야 한다. 또한, 관리조직부터 아키텍처를 이해하게 될 때 아키텍처를 통한 개발자의 구현이 아키텍처의 사상과 아키텍처의 제한사항을 충족 시킬 수 있도록 아키텍처에 대해서 구성원들에게 이해 시키고 공감대를 가지기 위해서 노력해야 한다.
아키텍처와 일관되게 설계/구현 하는지 확인해라.;
아키텍처의 일관성에 대한 아키텍트의 노력은 절대로 과다함이 없다. 물론 융통성을 가지고 접근해야 하나 항상 아키텍처를 전파함을 통해서 아키텍처와 일관된 설계/구현이 될 수 있도록 리뷰하고 공감대를 가지려는 노력을 기울여야 할 것이다.
시스템 환경이나 개발 툴 배포 등과 같은 문제를 제기하라
시스템 개발을 할 때 개발자가 환경셋팅이나 개발 툴에 대해서는 자유도를 가지고 개발자가 그 정도는 해야 하지 않겠느냐 라고 이야기 할수 있다. 그러나 시스템 개발이 팀 단위로 이뤄지고 팀간의 커뮤니케이션 까지 고려했을 때는 그에 대한 표준이 없다면 곤란할 것이다.
개발자에게 배포하여 주어진 순서대로 실행하면 로컬에서 배포 테스트 가능할 정도의 환경을 미리 셋업해주려는 노력을 해야 한다.
선도 개발 및 검증을 통해서 배포하는 역할을 직접 해야 한다.
이해관계자를 찾아서 상호작용하고 요구를 만족시켜 주어라
아키텍처에 관련된 수많은 이해관계자들을 식별하고 그들과 상호작용해라.
그들 각자가 가진 요구사항들에 대해서 적극적으로 대처하고 솔루션을 제공하려고 노력해야 한다.
아키텍처를 만들 때 배치와 유지보수에도 적합하게 만들어라
아키텍처를 만든다는 것은 항상 해당 시스템을 생성시에 만들게 된다. 해당 작업의 특성상 아키텍트는 생성에 대한 경험만을 보유하고 있을 수도 있다.
그러나 아키텍처가 부여하는 효과가 유지보수 및 배치에도 있다는 것에 동의 한다면 유지보수가 가능하고 손쉬운 배포가 가능한 아키텍처를 만들려는 노력을 게을리 해선 안된다.
기술문제를 해결하고 해당 논쟁과 상충하는 문제점들을 조율하라.
소프트웨어 아키텍트가 직면한 문제들은 비즈니스 적인 문제일 수도 있지만 가장 가까운 것은 기술문제이다.
해당 기술 문제를 해결하고 상충하는 문제들에 대한 논쟁에 대해서 조율하고 해결해라.
훌륭한 설계나 인상 깊은 발표를 통해 조직의 사기를 높여라.
훌륭한 설계를 하여 이해관계자들을 감동 시키고 개발자의 자기 계발 욕구를 만족시킨다면 이보다 좋을 순 없겠다.
결과물이 좋은 것에 못지 않게 중요한 것은 훌륭한 발표이다. 이해관계자들에게 인상 깊은 발표를 통해서 감동을 주어라.
새로운 기술을 도입 시 시스템이 나아가야 할 방향을 이해하고 제시해라.
새로운 문제가 대두되면 새로운 기술들을 찾게 될 때가 있다.
기술적인 트렌드는 계속 등장하고 그에 따른 변화의 흐름을 놓치지 않을 필요가 있다.
평소의 리서치와 리포트를 통해서 솔루션을 가질 수 있는 준비를 갖출 필요가 있다.
시스템의 기본 사상과 방향을 이해하고 조율하면서 새로운 기술들을 도입해야 한다.
아키텍처와 관련된 위험을 찾아 대비하라.
아키텍처 설계자는 자신의 사상에 깊은 이해를 가지고 있으므로 시스템의 아키텍처로 인하여 발생되는 문제들에 대해서는 모를 가능성이 있다.
아키텍처 대안을 검토할 때 객관적인 입장에서 검토하고, 특정한 검증 프로세스를 통해서 아키텍처와 관련된 위험을 도출할 필요가 있다.
맺음말
아키텍트들은 항상 아래와 같은 사항에 관심을 가진다.
소프트웨어 품질 속성, 개발 프레임워크, 시스템 요소의 구성/관계, 공통기능과 개발 지원에 필요한 것들, 기술자와 비즈니스 관계자 사이의 조정자 역할, 기술자의 의견을 적절히 전달할 수 있는 쉬운 용어의 사용, 개발팀에의 리더쉽, 선 하나의 결정이 시스템 전체에 미치는 영향 등등.
이런 모든 역할을 아키텍트 한 두명이 모두 할 수는 없다. 그리고 한 사람이 위의 능력들을 모두 가지기도 힘들 뿐더러 모두 갖추고 있다고 해도 프로젝트에서 주어지는 시간으로 따져보면 모든 역할을 해내기는 불가능하다. 언젠가 주변의 지인이 말한 것 처럼 ‘저 많은 것을 다 해야 해?’ 라는 생각으로 ‘현실적이지 않다’ 라고 말할 수도 있다.
그러나 아키텍트가 프로젝트에서 해야 할 수많은 역할에 대한 이해를 가지고 노력을 해야 할 것이다.
모두 다 할 순 없다. 모두 다 하는 것은 자연인 한 사람의 영역이 아닌 조직의 영역이라 할수 있을 것이다.
다만, 역할에 따른 자질과 역량을 키우는 데 노력하다보면 언젠간 쓸만한 아키텍트가 되어 있지 않을까?
| AOSA 1권. 8장 HDFS 정리 (0) | 2012/10/04 |
|---|---|
| 엔터프라이즈 환경에서 아키텍처 팀의 역할 (0) | 2012/07/08 |
| 아키텍트의 역할과 자질에 대한 고찰 (0) | 2012/07/08 |
| 프로젝트 에서 아키텍처 팀의 역할 (0) | 2011/04/20 |
| 아키텍트 직무 역할 (3) | 2011/03/22 |
| 신기술 도입시 고려사항 (0) | 2009/10/16 |
어떻게 하다가 이런 기능이 올라왔는데..
이름을 몰라서 죽이지 못하고 ... 불편하게 자꾸.. 까만 박스가 확성화된 곳을 가리키네...
아후..... 답답해.
저 까만 박스가에서 글자 나오는 거하고
활성화된 내 app 에서 까맣게 활성화 되는 기능이 도대체 뭘까?
| 이놈의 기능이 뭔지를 알아야 disable을 시키지.. (3) | 2012/07/02 |
|---|---|
| [참고할만한 글]성공하는 컨설턴트를 위한 7가지 습관 (0) | 2008/12/10 |
| 조엘온 소프트웨어 (0) | 2008/11/03 |
| IT 전문가들이 말하는 13개의 아웃소싱 성공 노하우 (0) | 2008/09/09 |
| [Links]2008-09-04 (0) | 2008/09/04 |
| Chicken wing exercise - 사내 메일중 (0) | 2008/09/01 |
|
