'아키텍트'에 해당되는 글 2건
- 2012.03.07 :: [신간소개] IT 아키텍트가 하지 말아야 할 128가지
- 2012.01.02 :: 왜 IT 아키텍트가 중요한가?
신간소개
2012. 3. 7. 16:52
l 엮은이: 니케이시스템즈
l 옮긴이: 최석기
l 페이지: 396
l 판형: 신국판(152x225)
l 도수: 1도
l 정가: 23,000원
l 발행일: 2012년 3월 15일
l ISBN: 978-89-966598-8-4
[강컴] [교보] [리브로] [반디] [11번가] [알라딘] [예스24] [인터파크]
sample.pdf_도서 내용
IT 현장에는 별로 중요시 되지 않는 것처럼 생각되어 무관심하게 지나쳤던 것들이, 터무니 없는 트러블을 일으키는 “해서는 안 된다”는 것들이 있습니다. 예를 들면, 오버헤드가 큰 “DBMS의 암호화 기능”을 함부로 사용하게 되면 성능 저하를 초래한다거나 자동 백업이나 툴에 의존하다 보면 정말로 백업이 되고 있는지 확인이 나태해져, 결국 복구 데이터가 남아있지 않는 사태에 부닥치곤 합니다.
이러한 “해서는 안 되는 것 128가지”를 정리한 책입니다. 개발자뿐만 아니라 아키텍트까지 반드시 숙지해야 할 내용들로 구성하였습니다.
_대상 독자
_목차
_대상 독자
시스템 프로젝트 현장 개발자
프로젝트 전체를 조율하고 책임지는 프로젝트 매니저와 아키텍트_목차
1장. 설계
No.001 EC 사이트에서는 Sorry 화면 방식을 채택해서는 안 된다
No.002 어플리케이션 개발자가 설계서대로 개발해 줄 것이라고 생각해서는 안 된다
No.003 사용자가 성능 요건을 정해줄 것이라고 생각해서는 안 된다
No.004 동일 서버 내의 웹 서비스를 호출해서는 안 된다
No.005 24시간 가동 시스템이라고 모든 것을 24시간 동작시키려고 해서는 안 된다
No.006 클라이언트/서버형 시스템을 가볍게 보아서는 안 된다
No.007 데이터 구조의 품질/성능이 나빠지는 것을 고려해야 한다
No.008 백업 설계를 먼저 해서는 안 된다
No.009 레코드 길이×건수로 데이터 용량을 결정해서는 안 된다
No.010 참조 정합성 제약 기능을 여러 번 사용해서는 안 된다
No.011 테스트 데이터로 성능 평가를 해서는 안 된다
No.012 파티션 분할을 가볍게 해서는 안 된다
No.013 오랜 시간 종료하지 않은 트랜잭션을 사용해서는 안 된다
No.014 기술 영역만 고려해서는 안 된다
No.015 기기의 스펙(명세서)을 bps만으로 판단해서는 안 된다
No.016 가상 네트워크를 물리 네트워크와 똑같이 생각해서는 안 된다
No.017 QoS라는 말로 숨겨서는 안 된다
No.018 QoS를 과신해서는 안 된다
No.019 구축 멤버의 시선만으로 로그 출력을 설계해서는 안 된다
No.020 GC를 정하지 않고 자바 어플리케이션을 설계해서는 안 된다
No.021 실물 모형과 프로토 타입을 혼동해서는 안 된다
No.022 어플리케이션을 함부로 리치화해서는 안 된다
No.023 화면 디자인이나 화면 이동의 변경에 “이것이 최선”이라고 생각해서는 안 된다
_주요 내용
누구도 알려주지 않았던 시스템 개발 현장의 128가지 해결책
"해서는 안 되는 것"에서 배우는 시스템 개발 현장의 바이블
개발자에서 아키텍트까지 알아야 할 경험적 노하우
시스템을 튼튼하게 만들 수 있는 건강한 개발자 그리고 유능한 아키텍트로 성장할 수 있는 경험적 노하우를 담았습니다.
누구나 맞닥뜨릴 수 있는 실제 상황을 제시한다!
이론을 다루지 않습니다. 누구나 현장에서 부딪힐 수 있는 실제 사례를 다룹니다.
나쁜 아키텍처를 알면, 좋은 아키텍처가 보인다
이 책은 하지 말아야 할 ‘나쁜 아키텍처’를 제시합니다. 이유를 설명하고 적절한 처방전을 내놓습니다. 128가지의 다양한 처방전을 적재적소에 활용할 수 있습니다.
분야별로 나누어 찾아보기 쉽습니다
설계, 방법론, 구축 및 테스트, 운용, 보안 분야로 나누어 찾아보기 쉽게 정리했습니다.
_편집자 코멘트
IT 현장에는 별로 중요시 되지 않는 것처럼 생각되어 무관심하게 지나쳤던 것들이 터무니 없는 트러블을 일으키는 “해서는 안 된다”는 것들이 있습니다. 기술이나 제품이 날로 발달하고 복잡해지면서 “해서는 안 되는 것” 또한 급증하고 있습니다. 그러나 이런 부분에 대해 현장에서 올바르게 전달되지 않는 경우가 늘고 있고 또 잘못 알고 있는 경우도 많습니다.
“해서는 안 되는 것”을 모르면 시스템 품질 저하로 이어집니다.
예를 들면, 오버헤드가 큰 “DBMS의 암호화 기능”을 함부로 사용하게 되면 성능 저하를 초래한다거나 소스코드를 안이하게 유용하다 보면 라이선스 문제에 노출될 수도 있고 자동 백업이나 툴에 의존하다 보면 정말로 백업이 되고 있는지 확인이 나태해져, 결국 복구 데이터가 남아있지 않는 사태에 부닥치곤 합니다.
누구나 알고 있을지 모를 아주 간단한 예를 들었지만, 굉장히 중요한데 의외로 지켜지지 않은 경우가 많습니다. 물론, 모든 경우를 100% 정리할 수는 없었지만 개발 현장에서 이 정도는 개발자와 아키텍트가 숙지하고 있어야 하지 않을까 싶습니다.
_저자 소개
집필진
신쿠보 코지(인사이트테크놀로지)
APC 재팬 서비스 사업부 솔루션 엔지니어링부
APC 재팬 비지니스 개발부
미즈구치 히로유키(APC 재팬)
옮긴이
최석기
효성데이터시스템(현재 노틸러스효성)에 입사하여 일본 히타치제작소의 인사급여패키지를 개발하였다. 물류나 판매의 SAP 구축 프로젝트의 컨설턴트로 활동하였으며 현재, 한솔그룹의 물류 관련 아키텍트로 한솔CSN 및 한솔제지 등의 SAP 혹은 웹 기반의 SM 업무를 담당하고 있다.
_끝
'신간소개' 카테고리의 다른 글
| [신간소개] 스토리로 이해하는 UX 디자인 프로세스 (0) | 2012.06.25 |
|---|---|
| [신간소개] 이제 실전이다 HTML5&CSS3 사이트 제작의 모든 것 (2) | 2012.04.11 |
| [신간소개] Xcode4로 시작하는 아이폰 프로그래밍 (2) | 2012.01.05 |
| [신간소개] 빅 데이터 시대를 위한 NoSQL 핵심 가이드 (0) | 2011.12.19 |
| [신간소개] 웹 디자이너를 위한 jQuery (2) | 2011.11.15 |
IT 포스팅
2012. 1. 2. 02:45
본 컬럼은 2012년 2월 출간예정인 로드북의,
<아키텍처, 이렇게 설계하지 말라>(가제)
에서 발췌한 컬럼 내용 중 일부입니다.
<아키텍처, 이렇게 설계하지 말라>(가제)
에서 발췌한 컬럼 내용 중 일부입니다.
“따로 IT 아키텍트라고 하지 않아도 기술 리더라든가, 공통팀 담당이라든가, 지금까지 그렇게 불리기도 했고, 그걸로 된 거 아냐?”.
“IT 아키텍트가 뭐야?”, “구체적으로 어떤 일을 하는 거야?”라든가, “IT 아키텍트가 정말 필요한 거야?”라는 질문을 많이 받습니다. 그 때마다 IT 아키텍트는 이러한 입장이고 이러한 일을 수행하는 역할이고, 시스템을 성공시키기 위해 필요한 직종이라고 열심히 이야기를 하곤 합니다.
물론, 이전부터 공통팀이나 표준화팀이라는 형태로 어떤 기술 중심적인 역할의 조직이나 팀을 배치하고 있는 기업에서도 서두와 같은 질문을 받습니다.
물론, 이전부터 공통팀이나 표준화팀이라는 형태로 어떤 기술 중심적인 역할의 조직이나 팀을 배치하고 있는 기업에서도 서두와 같은 질문을 받습니다.
“IT 아키텍트”라는 말의 의미를 “아작스(Ajax)”나 “웹2.0(Web 2.0)”을 근거로 얘기해 보겠습니다.
“아작스(Ajax)”는 Jesse James Garrett씨가 만든 용어입니다. 자바 스크립트(Java Script)에서 비동기 통신을 하고, 리치한 사용자 체험을 가능하게 하는 기술적인 개념입니다. 아작스(Ajax)라는 말이 나오기 이전, 자바 스크립트는 웹 시스템 개발자에게 미움을 받았습니다. 보안 문제가 있었으며 웹 브라우저 간의 호환성에 문제가 있었던 것이 주된 원인이었습니다.
하지만, 상황은 아작스(Ajax)가 등장하면서 크게 변했습니다. 아작스(Ajax)의 대명사가 된 구글 맵(Google Maps)이 화제로 되면서, 지금까지 웹에는 없었던 획기적인 조작을 할 수 있다는 인식이 생기게 되어 눈 깜박할 사이에 보급이 되었습니다. 아작스(Ajax)라는 말은 프로그래밍 언어나 소프트웨어 등 특정의 무엇인가를 가리키는 말은 아닙니다. 어디까지나 비동기 통신 등을 중심으로 한 기술적인 개념에 지나지 않습니다. 단, 이러한 기술적인 개념들에 이름을 붙임으로써 큰 변화가 생겨나게 된 것입니다.
아작스(Ajax)라는 개념을 정의함으로써, 막연하게 엔지니어들이 생각해왔던 개념(보다 리치한 사용자 체험을 가능하게 하는 것)을 공유할 수 있게 되었습니다. 그로 인해 커뮤니케이션의 오류가 일어나지 않게 되었을 뿐만 아니라, 리치한 사용자 체험을 의식하지 않았던 엔지니어들이 흥미를 갖게 되면서, 보다 복잡하고 고도의 웹 어플리케이션이 점점 등장하게 되었습니다. 아작스(Ajax)라는 말이 없었다면 요즘의 자바 스크립트에 의한 고도의 사용자 인터페이스는 여기까지 급속하게 보급되지 않았을 것입니다.
Tim O’Reilly씨가 제창하는 웹2.0에 대해서도 마찬가지입니다. Tim O’Reilly씨는 웹 진화 과정을 개념적으로 명확히 함으로써 웹 진화를 촉진시켰습니다. 웹2.0이란 말이 널리 퍼지기 시작하면서 웹이나 업계 전체가 활기차게 된 것은 틀림없습니다. 웹2.0이 해 준 역할이 상당히 큽니다.
타인에게 설명하기는 어렵지만 커뮤니케이션을 하기 위해 필요한 개념에 대해 이름을 붙입니다. 그렇게 함으로 커뮤니케이션이 원활하게 되고, 막연하기만 했던 개념이 사람들에 의해 인식되는 “형태”가 되어 보급됩니다.
IT 아키텍트라는 말도 아작스나 웹2.0과 같이 시스템 개발을 원활하게 하여 IT의 질을 향상시키는 요소로써 필요한 개념입니다.
'IT 포스팅' 카테고리의 다른 글
| <자바의 신>은 자바의 예약어 this를 어떻게 설명할까? (2) | 2013.03.07 |
|---|---|
| 워드프레스란 무엇인가? (0) | 2013.02.22 |
| 4탄_소프트웨어 버그의 속성, 세균을 닮았다 (0) | 2011.12.07 |
| CentOS 5.4 & Ruby 1.8.7 설치 가이드 (0) | 2011.11.15 |
| 3탄_Scrum의 돼지와 닭 이야기 (0) | 2011.08.12 |