choijami 괜찮은 책이다.
좋은(쉬운) 아키텍쳐가 필요하다. 2008-11-12   (0)

이프렌즈 ▶ 책내용
개발자 정년 35세를 운운하는 시대에 더욱 절실한 존재, 아키텍트.

아키텍트는 누구이고, 어떤 일을 하는가?
아키텍트는 기술적 관점에서 시스템을 바라보고 설계와 구현 전체를 책임져, 개발팀을 이끄는 이를 뜻한다. 개발에 관한 기본 방침, 즉 아키텍처를 정하고 이를 바탕으로 프레임워크를 설계하고 구현을 총괄하는 것이 주 업무라 할 수 있다. 또한 복잡하게 얽힌 프로젝트 이해당사자 즉 사용자, 발주자, 개발자들 사이에서 각각의 요구를 기술적인 관점에서 비용, 개발 범위, 품질 그리고 일정의 균형을 맞춰 나가는 사람이라고도 할 수 있다.

이 책은 가상의 아키텍트를 등장시켜, 아키텍트가 프로젝트의 작업흐름에 따라 어떠한 역할을 하는지 쉽게 보여준다. 이를 통해 아키텍트가 어떻게 시스템 개발 프로젝트의 문제를 해결하고, 프로젝트 성공에 기여하는지에 대한 궁금증을 해소시킨다. 그동안 아키텍트가 뭘 하는지 대략 알지만 명확하게 파악되지 않았던 사람들에게 쉽고 현실감 있게 설명하는 아키텍트 소개서가 될 것이다.

이 책은 무언가를 창조해내는 것에 기쁨을 느끼는 개발자의 속성을 지적하고, 어느 정도 경력이 차면 관리자나 영업 전선으로 배치되는 현실과 다른 길이 있음을 제시해 준다. 진정 개발자가 원하는 것이 무엇인가 다시 한 번 생각하도록 해주는 것이다. 그리고 그 희망이 결코 현실과 동떨어져 있지 않음을 확인할 수 있도록 해준다.

[추천의 글]

생생한 사례로 아키텍트의 세계로 안내한다
오병곤 (정보처리 기술사, 『대한민국 개발자 희망보고서』 저자)

바야흐로 IT 시스템이 대형화, 복잡화되고, 고객의 요구사항이 까다로워지면서 시스템을 전체적인 시각에서 볼 수 있는 안목이 필요한 시대가 되었다. 이러한 변화는 시스템 아키텍처에 대한 거시적인 조망은 물론 비즈니스와 시스템의 조율, 고객과 팀원에 대한 기술적인 커뮤니케이션을 요구한다. 그렇지만 아직까지 아키텍처에 대한 인식은 일천하다. 시스템을 '어떻게' 개발할 것인지에 대해서만 관심을 기울일 뿐 정작 '왜?' '무엇을?' 개발해야 하는지에 대한 근본적인 질문에 대해서는 인색하다. 기술적인 원칙과 방향을 제시하는 아키텍처를 보고 전체의 상황을 파악하기보다는 구축할 시스템의 프로그램에 집착한다.
이제 아키텍처를 제대로 이해하고 시스템과 비즈니스에 적용할 수 있는 전문가, 즉 아키텍트가 필요하다. 아키텍트(책임 설계자)는 영업, 요구사항 분석, 설계, 구현, 테스트, 유지보수에 이르기까지 프로젝트 전반에 걸쳐 시스템의 청사진과 기술적인 지침을 제시하고 주도하는 사람이다. 나아가 저자가 언급한 것처럼 고객의 비기능 요구사항을 정확히 파악하고 프로젝트 팀원들에게 전달하는 기술과 사람의 중개자 역할을 해야 한다.
많은 개발자가 아키텍트를 꿈꾸지만 아직까지 생소하게 느끼는 듯하다. 이 책은 아직 낯설게 느껴지는 아키텍트가 되기 위해서 구체적으로 무엇을 준비해야 하고, 무슨 일을 해야 하는지에 대한 궁금증을 쉽게 풀어준다. 아키텍트에 대해 답답한 갈증을 느끼고 있는 개발자가 적지 않기에 이 책의 출간은 시의적절하다. 자신의 미래를 아키텍트로 설계하는 이들에게 분명 좋은 참고가 될 것이다. 더욱이 저자는 자신이 경험한 생생한 사례를 바탕으로 아키텍트의 세계로 친절하게 안내한다.
나는 감히 단언한다. '개발자가 기술에 대한 애정을 가지고 직업적인 안정성을 보장받을 수 있는 길은 아키텍트다.'

앞으로 연마해야 할 것들이 무엇인지 깨달을 수 있게 해준... 책이다
곽중선(IT 경력 12년차, 클라우드나인 개발실장, sunnykwak.egloos.com)

프로그래머의 미래는 무엇일까? 경력이 쌓이면 후배들에게 자리를 물려주고 영업이나 관리를 해야 할까? 지금 하고 있는 일, 누구보다 잘할 수 있는 일을 계속 할 수는 없을까? 이런 고민을 하지 않는 개발자는 거의 없을 것이다.
세상에 없는 무언가를 창조하고, 상상한 것들을 실제 동작하게끔 만들어 내는 일이 즐겁기에 선택한 직업이니 말이다.
『아키텍트 이야기』는 새롭게 떠오르고 있는 아키텍트라는 새로운 직종과 개발자의 미래상을 명확히 보여주며 더불어 나아갈 길을 구체적으로 안내하고 있다. 아키텍트의 구체적인 역할을 이해할 수 있도록 가상 프로젝트를 통해 구체적인 문제 상황과 그 대처법, 그리고 아키텍트의 실질적인 업무를 보여준다.
마치 소설처럼 편안하게 읽히면서도 기술적인 부분의 묘사가 정확하다. 저자는 자신의 경험을 독자에게 전달하는 솜씨가 예사롭지 않은데다가 중간중간 꼭 기억해야 하는 원칙들을 짧게 삽입하여 핵심을 파악하기 쉽게 서술했다. 이웃나라의 이야기라 우리의 실상과 다르지 않을까 하는 우려가 있었으나, 놀랍도록 공감하며 많은 점을 배울 수 있었다.
실제 개발자로서 겪어온 경험들을 후배들에게 전수하겠다는 의도로 쓰인 책이기 때문에 읽기 편하고, 개발자가 상위의 전문가로 거듭나는 데에 도움이 될만한 것이 많이 녹아 있다.
IT 개발 현장에서 10년이 넘게 일해 왔음에도 아직 스스로 아키텍트라 칭하기는 부끄럽지만 앞으로 연마해야 할 것들이 무엇인지 깨달을 수 있게 해준 책이다. 게다가 10년 후에도 이 책을 곁에 두고 참고할 수 있을 것이라 생각하니 유행에 민감한 기술 레퍼런스 서적들에 비해 더욱 중요하게 여겨진다.

아키텍트가 되고자 하는 이들의 책상에 꽂혀야 할 책
김태현 (SKcommunications 기술그룹 차장, 데브피아 아키텍처&디자인 시삽)

중국 춘추전국시대의 손무와 그의 손자 손빈이 쓴 손자병법은 실전에서 쌓은 경험을 바탕으로 쓰여졌기 때문에 오늘날까지 그 가치를 인정받고 있다고 한다. 이 책은 그 손자병법과 같은 책이다. 추상적인 이론의 완성도를 자랑하는 것이 아니라 철저하게 현장 실무자의 입장에서 아키텍트가 해야 할 일들에 대해 설명하고 있다.
소프트웨어 아키텍처를 설명하기란 참 어렵다. 나는 개발자들의 미래가 소프트웨어 아키텍처에 있다고 믿고, 동료들과 온/오프라인에서 만나는 개발자들에게 소프트웨어 아키텍처를 설명하고 전파하고자 했다. 그를 위해 적지 않은 책들과 웹사이트를 섭렵하였지만 일선의 개발자들이 쉽게 이해할 수 있는 설명은 찾기 힘들었다.
이 책은 모호한 소프트웨어 아키텍처를 명쾌하게 설명한다. 아키텍처를 만드는 사람이 누구인가? 바로 아키텍트다. 이 책이 이끌어준 대로 아키텍트가 무슨 일을 하는지 따라가다 보면 아키텍처가 무엇인지도 어렵지 않게 알 수 있을 것이다. 마치 드라마처럼 아키텍트와 개발자가 나누는 대화를 보여 주기 때문에 실무자들이 어떻게 아키텍처를 만들고 프로젝트에 적용할지도 쉽게 파악할 수 있을 것이다.
이 책은 소프트웨어 아키텍처가 무엇인지, 어떤 쓰임새가 있는지, 실전에 어떻게 적용하는지를 알고자 하는 개발자, PM, PL, 팀장들이 기다려왔던 책이 아닌가 싶다
CMU SEI의 소프트웨어 아키텍처 관련 이론서들과 함께, 이 책도 아키텍트가 되고자 하는 이들의 책상에 꽂혀야 할 책 중의 하나다.

현장의 냄새가 물씬 난다
안영회 (소프트웨어 개발 컨설턴트, http://Younghoe.Info)

누가 쓴 글인지 알지 못한 채 원고를 읽었지만, 얼마 지나지 않아 원고에서 현장의 냄새가 물씬 난다는 것을 느낄 수 있었다. 이 책은 생동감 있는 개발 관련 에세이다. 흥미로운 사실은 이 책이 에세이에만 그치는 것이 아니라, 전문 개발자에서 아키텍트로 향해 가는 이에게 지침서가 될 수 있다는 점이다. 관련 영역의 포괄적인 이슈를 풍부한 경험과 해박한 지식으로 풀어내고 있다.
이 책의 특징은 핵심적인 사항을 놓치지 않으면서도 간결한 글로 전체적인 그림을 이해하는데 도움을 준다는 데 있다. 여기서 다루는 광범위한 주제를 고려해보면, 종종 독자가 자신의 경험을 토대로 이해하기는 힘든 부분이 있을 수도 있다. 그렇게 되면, 전달하는 내용이 모두 추상적이기 때문에 쉽게 읽기 힘들다. 그러나, 적재적소에 배치되어 있는 도식화된 설명과 잘 편집된 요약 정리는 도대체 이렇게 방대한 내용을 어찌 그리 얇은 책으로 소화했는가 하는 궁금증을 해소해준다.
만일 여러분이 아키텍트를 소망하는 전문 개발자라면 이 책에서 말하는 내용 정도는 숙지하고 있어야 한다. 아키텍트가 되기 위해서는 프로젝트와 시스템 전체를 조망하는 시야를 갖추어야 한다. 분명 짧은 시간에 쉽게 갖출 수 있는 역량은 아니지만, 이 책이 여러분의 꿈을 이루는 데 도움을 줄 것이다.



▶ 목차
감수자의 글
머리말

1장. 개발자의 다음 단계
프로그래머의 소망
시스템 전체를 바라보는 재미
프로젝트에서 아키텍트의 역할
아키텍트와 다른 업무 담당자의 관계
아키텍트의 주요 업무
10년 후에도 기술자로 활약하기 위해

2장. 요구사항 정의에 참여
요구사항 정의에 대한 기술적 지원
아키텍트의 요구분석 단계 업무
사용자 중심의 명세 설계
플랫폼 선정의 현실
팀원을 고려하여 개발 계획을 세운다
아키텍트가 있다면 당연히 순조롭게 진행되는가?

3장. 아키텍처 설계
아키텍처는 초기에 설계한다
아키텍처는 요구사항에서 만들어진다
기술 문제를 정리하자
항상 누가 아키텍처 설계서를 읽을지 고려한다
아키텍처 설계서를 써 본다
앞으로 어떤 작업이 이루어질지를 그려낸다
개요를 확실히 이해해야 한다
기술 요소를 정확하게 설명한다
막히기 쉬운 부분은 상세하게 설명해 놓는다
의도를 전달하는 것이 중요하다

4장. 프레임워크를 준비한다
소프트웨어에 요구되는 품질
아키텍처를 프로젝트 ...팀에 침투시킨다
개발팀 킥 오프
아키텍트는 기술과 사람의 중개자
프레임워크를 준비하자
팀원들의 의견을 이끌어내다
적절한 리뷰로 설계를 제어한다
칼럼: 프레임워크로 편안하고 간단하게 개발한다
프레임워크는 아키텍처의 구체적인 실체
할리우드의 법칙
프로젝트의 프레임워크
프레임워크를 이용할 때의 장점과 단점

5장. 말썽 많은 프로젝트 되살리기
전화 벨소리
문제는 어디에 있는가?
문제는 아키텍처에도 있다
아키텍처에서 해결할 수 있는 부분을 확인한다

6장. 테스트를 즐기자
개발자와 테스트 담당자 사이의 깊은 골
빈틈없는 테스트로 품질을 향상시키는 것은 불가능하다
TDD로 공격적인 테스트를 한다
단위 테스트
테스트하기 쉬운 아키텍처
아키텍트의 도움이 필요한 테스트
다양한 테스트 방법을 이해하자

7장. 개발 현장 밖에서 활약한다
문제를 해결하기 위해 필요한 기술
기술로 이해할 수 없는 것들
비기술자가 기술적인 결정을 내린다
위험요소를 줄이기 위해
일의 영역을 넓혀 보자
어떤 시스템을 만들어야 하는가?
아키텍트에게 요구되는 것
기술을 몸에 익히기 위해

8장. 애자일 프로젝트의 아키텍트
뛰면서 생각한다
문서를 버리고 사람과 대화한다
사전 설계는 손해다
점진적인 설계
사전에 설계해야 하는 경우도 있다
프레임워크는 나중에 추출한다
Architectus Oryzus와 Architectus Reloadus

9장. 아키텍트가 되고 싶다!
해커와 아키텍트
아키텍트가 왜 돌파구인가?
비즈니스 애플리케이션 개발은 사회 활동
프로 개발자

맺음말
참고문헌
찾아보기 2008-04-29   (0)