예외처리 관련 참고문서

http://www.nextree.co.kr/p3239/

저작자표시 비영리

'JAVA' 카테고리의 다른 글

로깅(Logging) 참고문서  (0) 2017.06.11
JAVA - 향상된 for 문 (from Java1.5)  (0) 2017.02.26
system32와 systemWOW64  (0) 2017.02.26
SAPJCO 연동 설정  (0) 2017.02.26
JAVA_리팩토링  (1) 2017.01.08

로깅(Logging) 관련 참고문서


http://www.nextree.co.kr/p5584/

저작자표시 비영리

'JAVA' 카테고리의 다른 글

예외처리 관련 참고문서  (0) 2017.06.11
JAVA - 향상된 for 문 (from Java1.5)  (0) 2017.02.26
system32와 systemWOW64  (0) 2017.02.26
SAPJCO 연동 설정  (0) 2017.02.26
JAVA_리팩토링  (1) 2017.01.08

'조대협의 블로그'에 방문해서 이런저런 글을 보다가 아키텍트 키워드가 눈에 들어오길래 쭉 읽어봤다 ㅎㅎ

공감되는 말이 많아 퍼왔다. 



아키텍트

아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다.
아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다.
비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지에 대한 내용으로 사업 전략,비젼,요구사항 분석과 같은 범주와 관련이 된다. 시스템의 구현 목적은 어떤 비지니스의 목적을 달성하기 위함이다. 사업 전략이야 COO 분들이나, 아니면 비지니스 컨설턴트가 진행을 하기는 하지만, 비지니스 요건을 어떻게 시스템으로 구현하여 효과를 낼지는 IT 아키텍트의 역할이다. 그래서, 비지니스에 대한 아키텍쳐링도 매우 중요하다. 
다음이 테크니컬 아키텍쳐인데, 전체 시스템의 그림을 그리고, 비지니스 요건을 충족하기 위한 기술적인 설계를 하는 역할이다.
 강조하고자 하는 바는 비지니스 요건을 잘 이해해야 한다는 것이다.
예를 들어 분산 트렌젝션 요건이 있다고 하자. "주문과 결재" 두가지 기능을 묶어야 할경우, 여러가지 선택이 있다.
XA기반의 분산 트렌젝션을 사용하는 방법, 보상 트렌젝션 처리, 로깅을 통해서 유실분에 대한 처리, 아니면 유실되는 것 데로 놔두는 것...
고급 기능과 아키텍쳐에는 돈이 든다. 물론 XA기반으로 구현하면 좋겠지만, 해당 시스템이 느린 경우 LOCK 경합 문제가 발생할 수 도 있고, 복잡도가 높아지는 만큼 테스팅에 대한 코스트도 높아진다.
 유료 회원 가입 프로세스 경우 차라리 에러가 나는데로 놔두는 것이 비용 측면에서 훨씬 유리할 수 있다. 공짜로 가입되었다고 Complain할 사람은 그리 없으니까는.
 즉. 완벽한 보안 장치를 하기 위해서, 서랍에 자물쇠를 하느냐 몇천만원짜리 지문 인식 장치를 하느냐가 아닐까?

아키텍트의 능력 중에서 중요한 것은

숲을 보는 능력
아키텍트는 전체 시스템을 보는 능력이 매우 중요하다. 개개의 시스템과 구현 방법에 대해서는(나무를 보는 능력) Senior Developer만으로도 충분하다. 전체 시스템을 조망하고, 그 방향을 잡는 조타수의 역할이 아키텍트이다.

기술에 대한 폭 넓은 지식
제대로 된 설계를 하기 위해서는 어떤 기술이 적절한지 장단점과 위험 요소는 무엇인지를 파악해서 적재 적소에 알맞은 기술을 배치해야 한다. 아니면. 결국 벤더 영업이나 마케터 손에 놀아나게된다. 마치 피라미드 그룹에 걸린것 처럼.

현실을 인지하는 능력
아키텍쳐는 현실적이라야 한다. 아무리 좋은 아키텍쳐라도 금액과, 수행하는 팀원의 능력에 맞지 않으면 말짱 도루묵이다. 적절한 시간과 Learning Curve에 드는 시간도 충분히 고려되어야 한다.

그리고 인맥
왠 갑자기 인맥이냐라고 할 수 있지만. 아무리 뛰어난 아키텍트라도 여러 프로젝트를 경험해보기는 쉽지 않다. 인맥을 통해서, 경험을 공유하고, 문서 템플릿, Reference Architecture, Delivery methodology등을 수집할 수 있는 것은 좀더 안정적이고 성숙된 아키텍쳐를 설계할 수 있는 빠르고 확실한 방법을 제공한다.

커뮤니케이션
아키텍쳐는 기존의 아키텍쳐나 이해관계, 또는 새로운 도전등에 대한 반감에 부딪히기 쉽다. 이를 논리적으로 설득하고, 함께 일할 수 있는 협업 분위기를 만드는것 역시 아키텍트의 역할이다.

프로젝트를 하다보면 많은 AA (Application Architect)를 만난다. 프로젝트의 꽃이자 기술의 마지노선이 AA이다.
그런데 국내 AA를 보면, 숲보다는 나무를 보는 경우가 많고, 중반 이후에는 아키텍쳐에 대한 책임을 지지 않으려는 방어적인 자세로 가는 경우를 종종 봐 왔다. 실제적으로 AA에 대한 시간 배정과 역할에 대한 이해가 부족한 면도 있고. AA 들 자체가 좀더 전략적인 사고 를 가질 필요가 있다.



출처: http://bcho.tistory.com/252 [조대협의 블로그]

저작자표시 비영리

'Application Architect > AA 일반' 카테고리의 다른 글

[AA Role] 프로젝트 계획단계  (0) 2017.11.28

+ Recent posts

티스토리툴바