이전

리뷰 (7)

한줄평
평점 분포
  • 리뷰 총점10 29%
  • 리뷰 총점8 43%
  • 리뷰 총점6 14%
  • 리뷰 총점4 14%
  • 리뷰 총점2 0%
연령대별 평균 점수
  • 10대 0.0
  • 20대 0.0
  • 30대 0.0
  • 40대 8.0
  • 50대 7.0
리뷰 총점 종이책
아키텍트가 무엇인가요 ?
"아키텍트가 무엇인가요 ?" 내용보기
소프트웨어 개발자라면 누구나 30대 후반부터 자신의 역할이 무엇이 될까에 대한 불안감을 가지고 있다. 그 나이가 되서도 디버깅에 밤잠을 설치는 개발자로 남아있을 수도 있고, 부하 직원의 일정관리와 상사에게 보고하는 보고서 작성에 하루종일을 보내게 되는 관리자가 될 수도 있고, 아니면 개발과는 아주 무관한 다른 분야에서 일하게 될지도 모른다. 이 책은 이 외에 아키텍트라
"아키텍트가 무엇인가요 ?" 내용보기

소프트웨어 개발자라면 누구나 30대 후반부터 자신의 역할이 무엇이 될까에 대한 불안감을 가지고 있다.

그 나이가 되서도 디버깅에 밤잠을 설치는 개발자로 남아있을 수도 있고, 부하 직원의 일정관리와 상사에게 보고하는 보고서 작성에 하루종일을 보내게 되는 관리자가 될 수도 있고, 아니면 개발과는 아주 무관한 다른 분야에서 일하게 될지도 모른다. 이 책은 이 외에 아키텍트라는 또하나의 길을 제시하고 있다.

 

저자가 일본인이라는 것이 이 책을 선뜻 손이 가지 않게 하였지만, 결론적으로 이 책의 선택은 충분히 좋은 선택이었다고 생각된다.

이 책은 요구사항 분석단계부터 시작하여, 소프트웨어 설계와 개발, 테스트에 참여하고, 비기술영역의 담당자와의 원활한 커뮤니케이션에도 도움을 주는 아키텍트에 대해 실 사례 위주로 잘 설명하고 있다.

 

아쉬움이 있다면, 'Iterative' 개발 방법론이 제시되고 있는 요즈음에, 'Waterfall' 방법론으로 이야기를 전개한 것이나, 다양한 IT 분야에 대해 다 섭렵하지 않고, 서버 애플리케이션에 국한해서 설명한 부분이다.  임베디드 애플리케이션에서도 서버 애플리케이션 아키텍트가 역량을 발휘할 수 있을까? 이 의문은 이 책을 읽고 난 후에도 풀리지 않는다.

 

이러한 아쉬움에도 불구하고, 소프트웨어 개발자 그 이상을 꿈꾸는 30대 초반의 개발자라면 한번쯤 읽는것은 분명히 도움이 될 듯 하다.

 

특히, 7장과 8장은 피부에 와닿는 이야기가 많아서 다시 한번 천천히 읽게 만든다.

h*****9 2007.04.15. 신고 공감 5 댓글 0
리뷰 총점 종이책
무미건조한 아키텍트 이야기
"무미건조한 아키텍트 이야기" 내용보기
개발자의 길에 발을 들여놓은 이들이 한 번쯤은 꿈꾸었을 법한 이름 - "아키텍트"소프트웨어 세계엔 존경해 마지않은 여러 아키텍트들이 있다. 개발자들은 그런 아키텍트가 되진 못하더라도 그와 같은 길을 걸어보고 싶을것이다. 단순히 연차만 채우고 관리자로 진급해서 개발자들을 닥달하고 퇴직하는 그런 사람이 되긴 싫을 것이다. 그런 측면에서 생각해 보면, "아키텍트 이야기"라는
"무미건조한 아키텍트 이야기" 내용보기
개발자의 길에 발을 들여놓은 이들이 한 번쯤은 꿈꾸었을 법한 이름 - "아키텍트"
소프트웨어 세계엔 존경해 마지않은 여러 아키텍트들이 있다. 개발자들은 그런 아키텍트가 되진 못하더라도 그와 같은 길을 걸어보고 싶을것이다. 단순히 연차만 채우고 관리자로 진급해서 개발자들을 닥달하고 퇴직하는 그런 사람이 되긴 싫을 것이다. 그런 측면에서 생각해 보면, "아키텍트 이야기"라는 제목의 이 책은 개발자들에게 내재되어 있는 로망을 깊은 곳으로 부터 불러 일으키게 한다. 나 또한 그런 로망을 가지고 이 책을 구입했다. 아키텍트란 과연 어떤 직업일까? 라는 환상을 가지고...

이 책은 이야기 형식을 빌려 아키텍트의 업무를 소개하려고 시도하고 있다. 주인공은 물론 아키텍트이다. 주인공은 영업사원이 개발을 수주받는 과정부터 요구사항, 설계, 개발, 테스팅, 납품에 이르는 과정을 여러 인물들을 등장시켜 이야기를 풀어나가려 한다.

하지만, 전반적인 책의 수준은 기대 이하인데, 이유는 대략 다음과 같다. 프로젝트를 해결해 나가는 과정의 묘사가 무미건조하다. 주인공을 비롯한 등장인물들의 캐릭터성이 결여되어 있다. 다른 책과 비교하자면, 프로젝트 관리자의 업무를 소설로 풀어놓은 톰 디마르코의 "데드라인" 같은 경우에는 설정 자체는 황당하지만, 프로젝트 수행에 관련된 내용이 실제적이였고 등장하는 인물의 캐릭터 성격 또한 개성적이여서 지루하지 않게 읽었다. 그런데 이 책의 캐릭터들은 무 캐릭터성의 전형 그 자체다. 전부 좋은 사람이거나 성격이 없는 사람들이다.
처음에는 불안했던 개발자가 나중에는 일취월장하는 그런 내용의 서술도 너무 단순하게 묘사된다.

그나마 흥미를 불러 일으켰던 실패하기 직전의 금융권 프로젝트도 구세주 아키텍트 주인공이 아주 간단하게 해결해 버린다. 물론 내용상에는 어려운 것처럼 표현하지만, 서술은 간단하게 해결해 버린다. 솔직히 이 부분에서 주인공의 눈부신 활약을 기대했다. 이부분만 좋았어도 실망하지 않았을 것이다. 그리고 금융권 프로젝트의 구원을 요청했던 곳에는 프로젝트 관리자가 있는데, 왜 잘 나가는 주인공 아키텍트의 프로젝트에는 프로젝트 관리자가 없는 것인가? 아키텍트가 프로젝트 관리자인가?  상황 설정 또한 허술하기 짝이 없다.

그래도 이 책에 담겨진 아키텍트에 대한 전반적인 내용은 보편적여서 기본적인 내용은 배울만한 점이 많다. 이야기 형식을 빌려 설명할 거라면 좀 더 재미있고 치밀하게 구성해서 적었어야 하지 않았을까? 이런 점이 이 책의 마이너스 적인 요소다. 아키텍트라는 직업에 대해 가슴 벅찰 정도의 지식과 "아키텍트"가 되고픈 이상을 높여주기에는 부족한 책이다.

인사이트의 책들은 대체로 수준이 높고 양서들을 많이 출판하는데 상대적으로 약간 실망스러운 책 선정이다. 번역의 질은 상당히 높은 편이라 내용을 이해하는 데 어려움이 없었다.
아키텍트가 어떤 것을 하는지 대략이라도 알고 싶다면 읽어볼 만은 한 책이다.
g*****i 2007.05.27. 신고 공감 2 댓글 0
리뷰 총점 종이책
아키텍트는 따는 자격증이 아니라 경험에서 나오는 리더쉽이다
"아키텍트는 따는 자격증이 아니라 경험에서 나오는 리더쉽이다" 내용보기
아키텍트란 이름이 유행처럼 번저나가고, 거의 꽤 많은 사람들이 이 직업이 갖는 것을 인생의 목표로 삼는것을 보았다. 아키텍트 자격증이란 것도 본적이 있다   이러한 때에 과연 아키텍트란 무엇인가 궁금해 지는데, 이 책은 그런 궁금증을 풀어주었다.   이 책을 읽고나서 이해하게된 아키택트는 직업이 아니다. 프로그래밍과 전문 분야에 많은 경험이 있고, 틈틈히 새로 나
"아키텍트는 따는 자격증이 아니라 경험에서 나오는 리더쉽이다" 내용보기

아키텍트란 이름이 유행처럼 번저나가고,

거의 꽤 많은 사람들이 이 직업이 갖는 것을 인생의 목표로 삼는것을 보았다.

아키텍트 자격증이란 것도 본적이 있다

 

이러한 때에 과연 아키텍트란 무엇인가 궁금해 지는데,

이 책은 그런 궁금증을 풀어주었다.

 

이 책을 읽고나서 이해하게된 아키택트는 직업이 아니다.

프로그래밍과 전문 분야에 많은 경험이 있고,

틈틈히 새로 나오는 기술이나 이론들을 섭렵하고,

더 나아가 팀을 효율적이고 성공적으로 이끌어

결과적으로 프로젝트의 성공에 기여하는 조직내 기술적 해결사 역활이다.

 

이 책을 읽으면서 생각하는 사람은 내 옛직장의 팀장이다.

그 사람이 하는 일이 프로젝트를 제안하고,

기술조사를 수행하여 세미나를 자주 열고,

프로젝트가 결정되면 라이브러리(프레임워크)를 제작하고

팀원들의 기술적인 어려움이나 방향에 대한 제시를 하며,

대외적으로 사업부서와 긴밀하게 협조하여

결과적으로 프로젝트를 성공적으로 이끈다.

 

결론적으로 아키텍트라는 역활은 이미 이전부터 있어왔다.

다만 이름이 아키텍트라 불리면서 선망의 직업이 된것이며 잘못된 것이다.

옛 회사에서는 아키텍트라는 말 대신에 시스템 엔지니어라고 불린다.

 

이 책은 아키텍트라는 역활을 잘 묘사하고 있다.

다른 사람은 처지는 프로젝트를 억지로 맡는 부분에서 억지라고 생각하던데,

내 생각에 C는 이미 그 회사내에서 많은 프로젝트를 섭렵했던 경력자이기

때문에 윗사람이 충분히 가능하다고 판단했으리라 생각한다.

 

결론적으로 많은 경험과 지식, 리더쉽, 신뢰, 조직내에서 이 4가지를 기르지 못한다면 아키텍트는 꿈도 꾸지 못한다는 것을 배웠다.

c****d 2009.03.05. 신고 공감 0 댓글 0
리뷰 총점 종이책
동감가는 이야기.. 그러나...
"동감가는 이야기.. 그러나..." 내용보기
30대 초반에 개발자로 남들 보다 많이 노력하려고 애쓰는 사람이다. 아침에 일어 나면 하루가 다르게 변하는 IT에서 유행을 따를 보다는 기본에 충실하려 무던히 애를 쓰지만 시장에서는 더욱더 새로운 것을 요구 하고 있다.   그러던 어느날 이 책을 구입하게 되었다... 사실 아키첵처를 설명 하는 책인줄 알고 구입 했다가.. 아키텍터를 이야기리 하길레 처음에는 잘 못 구입 했구
"동감가는 이야기.. 그러나..." 내용보기

30대 초반에 개발자로 남들 보다 많이 노력하려고 애쓰는 사람이다.

아침에 일어 나면 하루가 다르게 변하는 IT에서 유행을 따를 보다는 기본에 충실하려 무던히 애를 쓰지만 시장에서는 더욱더 새로운 것을 요구 하고 있다.

 

그러던 어느날 이 책을 구입하게 되었다...

사실 아키첵처를 설명 하는 책인줄 알고 구입 했다가.. 아키텍터를 이야기리 하길레 처음에는 잘 못 구입 했구나 했다가 결국은 주말을 이용 해서 완독을 해 버렷다..

 

저자의 말들은 주구 절절 다 맞는 말이나, 저자기 이야기 하는 아키텍터는 내 경험상 PL또는 PM의 영역으로 다들 알고 있으며 나 또한 그렇게 일을 하고 있다..

 

그리고 국내 IT상황으로 볼때 아키텍터라는 사람을 추가 해서 공수를 추가 하여 인건비를 발생하여 Project단가를 높이려고 하는 사람은 아무도 없을 것이다.

 

난 아키텍터는 단지 PM이나 PL이 가지고 있어야 하는 하나의 자질이라고 생각한다.

 

f***s 2007.04.16. 신고 공감 0 댓글 0
리뷰 총점 종이책
아키텍트 이야기
"아키텍트 이야기" 내용보기
근래에 좋은 소프트웨어를 만들기 위해서는 어떻게 해야 하는지에 대한 고민을 많이 하게 되는것 같습니다. 그러던중 아키텍트 온라인 세미나를 듣게 되었는데 세미나가 끝나고 아키텍트 입문서적에 대한 질문이 나오자 현직 아키텍트분께서 추천을 해주신 책이 "아키텍트 이야기" 였습니다.아키텍트라는 말 부터가 일단 어렵게만 느껴지지만 이 책은 그 아키텍트라는 용어가 조금은 친근
"아키텍트 이야기" 내용보기

근래에 좋은 소프트웨어를 만들기 위해서는 어떻게 해야 하는지에 대한 고민을 많이 하게 되는것 같습니다.
그러던중 아키텍트 온라인 세미나를 듣게 되었는데 세미나가 끝나고 아키텍트 입문서적에 대한 질문이 나오자 현직 아키텍트분께서 추천을 해주신 책이 "아키텍트 이야기" 였습니다.
아키텍트라는 말 부터가 일단 어렵게만 느껴지지만 이 책은 그 아키텍트라는 용어가 조금은 친근하게 들릴수 있게 해주는것 같습니다.

 

이 책에서는 아키텍트가 어떠한 일을 해야하며 무엇을 준비해야 하는지등에 관해서 아키텍트 C를 등장인물로 해서 보여주고 있습니다.
전체적인 프로젝트가 어떻게 흘러가는지에 대해서 보여주면서 평상시에 그냥 별거 아니라 생각하고 넘어가는 것들에 대해서도 왜 필요한 일들인지 많은 설명을 해주고 있습니다.
꼭 아키텍트가 되고자 하는 사람이 아닌 이제 개발일을 시작하는 분들도 읽어 놓으면 최소한 내가 현재 지시받아서 하고 있는 일이 하찮은 일이 아니라는 생각을 갖을 수 있지 않을까 합니다.

r***f 2008.06.28. 신고 공감 0 댓글 0
리뷰 총점 종이책
[2011-012] 일본인이 말하는 아키텍트 이야기 - 도입
"[2011-012] 일본인이 말하는 아키텍트 이야기 - 도입" 내용보기
이집트의 피라미드가 기원전 2,500년 경에 만들어졌다고 하니, 건축에 대하여 인간은 최소한 4,500년의 경험과 지식을 보유하고 있는 것이다. 이 긴 시간동안 다양한 장소의 수많은 사람들(Architect)이 다양한 형태의 건축물(Architecture)을 만들어 왔다. 건축물들은 꾸준히 지속적으로 주변의 자연 환경, 사회/문화/정치 등이 반영되어 때로는 화려하게 때로는 소박하게 만들어 졌으리
"[2011-012] 일본인이 말하는 아키텍트 이야기 - 도입" 내용보기

이집트의 피라미드가 기원전 2,500년 경에 만들어졌다고 하니, 건축에 대하여 인간은 최소한 4,500년의 경험과 지식을 보유하고 있는 것이다. 이 긴 시간동안 다양한 장소의 수많은 사람들(Architect)이 다양한 형태의 건축물(Architecture)을 만들어 왔다. 건축물들은 꾸준히 지속적으로 주변의 자연 환경, 사회/문화/정치 등이 반영되어 때로는 화려하게 때로는 소박하게 만들어 졌으리라 생각한다.  

이에 비하여,  인류 최초의 컴퓨터인 에니악(ENIAC)이 1946년에 만들어졌으니, 컴퓨터를 활용하기 위한 소프트웨어(Software)의 역사는 70년도 되지 않는다. 하지만, 이 짧은 기간 동안 급격한 변화를 이루어 왔다.

뭔 변화가 그리 많았는지...  "내가 처음 컴퓨터를 사용할 때는 HDD가 없는 컴퓨터에서 5.35인치 플로피 디스크에 프로그램을 보관했었다.", "내가 Microsoft 행사에 참여해서 기념품으로 8MB USB 저장장치를 받았었어!!"  이렇게 말하면  다들 시큰둥한 표정을 짓는다.  "뭔 옛날 이야기를 하시나요? 혹시 8GB 아닌가요? "
  
최초에는 컴퓨터를 이용하여  복잡한 계산을 빠르게 끝낼 수 있는 시스템을 만들고자 했다면, 지금은 기업의 복잡한 업무를 신속하고 정확하게 처리할 수 있는 시스템을 구축하는 데 주력하고 있다. 하지만, 기업의 복잡한 업무를 처리하기 위한  다양한 시스템 구축 프로젝트들이, 기한 내, 예산 내, 목표한 품질을 만족하며 끝나는 비율이 높지 않다. 무엇이 문제인가?

건축에 비하여 절대적으로 적은 소프트웨어시스템 구축 경험, 얼마나 만들어 졌는지 어떤 기능을 가지고 있는 지 실행파일만 가지고는 알 수 없는  소프트웨어의 비가시성(Invisibility), 소프트웨어 시스템을 구축하기 위하여 필요한 하드웨어 및 소프트웨어 기술의 급격한 변화가 가장 큰 문제가 아닐까?  

따라서 매번 개발자에 따라 결과가 달라지는 아트(Art)가 아닌, 누구라도 같은 기술,같은 프로세스에 따르면 같은 결과가 나올 수 있도록 하는 소프트웨어 공학(Software Engineering)적인 접근이 급격히 발전하게 되었다.(스티브 맥코넬의 "Professional 소프트웨어 개발"을 참조하기 바람) 

 

이 책은 소프트웨어 공학 중에서 "이해관계자의 기능 및 비기능 요구사항을 반영하여 소프트웨어 시스템의 논리적인 구성요소와 관계, 적용원칙 등을 어떻게 설계할 것인지 의사결정하는" 소프트웨어 아키텍트에 대하여 설명하고 있는 책이다.

저자가 일본인인데...  우리나라에도 소프트웨어 아키텍트의 발전을 위하여 노력하고 계신 분들이 많다. (최근에 관련 책들이 계속 출간되고 있다.)  한국소프트웨어 아키텍트 연합회( http://www.swarchitect.org/)를 참고하기 바란다.


우리나라가 IT 강국이라고 하는데...  특정 분야로 치우쳐져 있는 것같다.  대부분 하드웨어에 내장된 소프트웨어(Embedded Software)분야만 관심을 받는 것 같다.  당장 수출이 잘 되어서 돈을 벌 수 있는 분야이니, 주로 관심을 받고 있는 것은 당연한 것 같다. 

하지만, 주목받지 못한 분야에 있는 많은 소프트웨어 개발자들의 미래를 어떻게 그려야 할 것인가? 영화 "국가대표"가  비인기 종목의 설움을 보여주듯이,  IT분야에서 관심도 받지 못하면서도,  "월화수목금금금", "첨단 노가다", "5D"로 묘사되는 고단한 소프트웨어의 개발자가 미래에 치킨집이나 호프집을 운영하지 않고, 자신이 가장 잘 할 수 있는 소프트웨어 분야에서 삶을 영위할 수 있는 방법은 무엇인가?  이 문제에 대한 하나의 방안으로 저자는 "아키텍트"를 이야기하고 있다.

"월화수목금금금"을 해결할 수 있는 간단한 방법이 있다. (한이 맺혀서 인가... 책의 리뷰와 관련 없는 내용이 자꾸 추가되고 있다...  ) 소프트웨어 개발자에게 정당한 대가를 지불하면 된다. 그렇다면 지금은 소프트웨어 개발자에게 정당한 대가를 지불하지 않는다는 것인가?  나의 답변은 "아마도 그럴 것이다"이다.  왜냐하면, 소프트웨어 개발 자체가 인간의 지적인 작업이다 보니 소프트웨어 개발자의 역량을 측정하기도 힘들고 작업의 결과를 확인하기도 어렵다. 

주어진 작업의 난이도가 얼마나 되는지  4,500년 동안 측정을 해왔으면, 특정 작업을 하는데 어떤 사람이 얼마의 노력이 필요한지 표준이 나오지 않을까?  70년 밖에 되지 않은 역사, 기술과 관련된 지식이 수시로 변하면서, 결과물도 눈으로 측정하기 어려운 이런 분야에서, 주어진 작업의 난이도를 어떻게 표준화를 할 것인가? 

LOC(Line of Code), M/M(Man/Month), FP(Function Point)로 측정 단위가 계속 변하고 있는 이 분야에서 발주사와 수주사 양쪽이 모두 윈윈(win-win)할 수 있는 방법은 무엇인가? 아직도 소프트웨어 개발자나 사업자들은 시행착오를 더 거쳐야 하는 것인가?

"정당한 대가"와 관련된 많은 데이터들이 축적되고 많은 연구가 진행되어, IT 분야 종사자 특히 소프트웨어 개발자들의 미래가 밝아졌으면 좋겠다.. 그래야 프로젝트를 기획할 때 "가능한 많은 범위를, 가능한 적은 예산으로,  가능한 빨리, 시스템을 구축하겠다"는 생각은  시스템구축 프로젝트 실패의 지름길이며, 해당 책임은 기획자에 있다고 사회적으로 동의하게 될테니까 말이다.  프로젝트의 규모가 커질수록, 프로젝트 기획자는 비용 및 일정 추정이 너무 어렵고 계획 세우기가 너무 힘들다.(프로젝트 규모 추정은 SI업체에서 수 많은 프로젝트를 수행했었던 PM도 힘들어 한다.)  이들에게 근거있는 확실한 데이터를 제공해 준다면 합리적으로 판단하지 않겠는가? 


아키텍트와 우리나라 소프트웨어 시스템 개발 프로젝트 현실에 대해서 이야기하다보니 글이 너무 길어졌다.
글을 도입과 내용으로 분리해서 올리도록 하겠다.

t********s 2011.12.31. 신고 공감 0 댓글 0
리뷰 총점 종이책
실망스러운 책
"실망스러운 책" 내용보기
이전에 gonguri님이 쓰신 내용에 전적으로 동감합니다.   전체적인 내용과 구성이 많이 부족하다는 느낌과 문제해결에 댓한 단순한 전개에 많은 아쉬움이 남았습니다.   특히 자신의 프로젝트도 아닌 금융권 프로젝트에 대해 거절하지 못하고 끌려가는 모습은 지금 생각해도 너무도 어이없는 내용 전개라고 생각합니다.   이런 모습을 그려놓고 "아기텍트는 긍지를 가질만 하
"실망스러운 책" 내용보기

이전에 gonguri님이 쓰신 내용에

전적으로 동감합니다.

 

전체적인 내용과 구성이 많이 부족하다는 느낌과

문제해결에 댓한 단순한 전개에 많은 아쉬움이 남았습니다.

 

특히 자신의 프로젝트도 아닌 금융권 프로젝트에 대해

거절하지 못하고 끌려가는 모습은

지금 생각해도 너무도 어이없는 내용 전개라고 생각합니다.

 

이런 모습을 그려놓고

"아기텍트는 긍지를 가질만 하다.

프로그래머 다음 단계로 도전할 만한 가치가 있다"고

말하는 것도 아이러니 합니다.

 

책을 구입하기 보다는 그냥 서점에서

잠깐 읽어보시길 권합니다.

s*****t 2008.08.15. 신고 공감 0 댓글 0