개발의 즐거움/Architecture 10

AOSA 1권. 8장 HDFS 정리

http://www.aosabook.org/en/hdfs.html 의 내용을 정리하였으며 웹 상에서 여러 다른 정보도 참조하였습니다. 8장.HDFS introduction ㅇ 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)은 기성 하드웨어에서 실행할 수 있도록 디자인된 분산 파일 시스템. ㅇ 다른 분산 파일 시스템과의 차이점 HDFS는 fault-tolerant 하고 저비용 하드웨어를 통해 배포할 수 있도록 설계됨. HDFS는 응용 프로그램 데이터의 접근에 높은 처리량을 제공하고, 대용량 데이터 집합을 갖는 응용 프로그램에 적합 ㅇ 하둡의 중요한 특징은 수 없이 많은 데이타와 계산의 파티션, 병렬 계산의 실행임 ㅇ hdfs는 메타데이타와 데이타를 분리하여 저장한..

엔터프라이즈 환경에서 아키텍처 팀의 역할

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 프로젝트를 해요?~~~프로젝트 사업을 만든다, 고객의 요구사항을 듣는다,제안서를 작성한다, 요구사항 분석서를 작성한다, 고객의 요구사항 중 비기능 요구사항을 식별한다, 비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요..

아키텍트의 역할과 자질에 대한 고찰

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 왜 아키텍트일까? 흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅..

아키텍트 직무 역할

"아키텍트 직무" 여기엔 수퍼맨처럼 묘사되지만.. 이런 능력을 모두 가질수가 있으면.. 이 글 보고 계시겠어요? ^^;; 이런 사상과 능력을 보유하기위해서 노력해야 하고.. 각 역할이나 자질 중에서 몇개를 자신이 계발중인가? 또는 수행하고 있는가가 요점입니다. 흔히 얘기하는 SW 설계자로서의 아키텍트를 얘기하고자 하는 마인드 맵이니... 그렇게 이해하고 키워드 위주로만 보시면 좋을 것 같습니다. 여기 저기서 참조하고 "아키텍트 이야기" 책에서 참조한 마인드 맵입니다. 참조할 수 있는 자료를 온라인에 오픈 해 주신 여러~ 분들에게 감사드립니다. 목차, 구성 사례는 조금 맞지 않을 수도 있습니다만,, 현업에서 일반적으로 사용되는 구성방식이다.. 라고 판단하시면 될 것 같구요. ( 물론 SAiP 2ed 나, ..

신기술 도입시 고려사항

신기술을 사용할 때 ( 요즘 트렌드로 보면.... ) 신프레임웍을 도입할때 고려해야할 질문 1. 이 기술이 실무에 잘 적용된다는 게 실험으로 완벽하게 증명됐는가? 2. 성공적이라는 것이 신기술 자체가 그렇다는 것인가? 아니면 사용하는 사람들이 성공적이었다는 것인가? 3. 신기술은 완벽한 것인가? 아니면 실무에 적용될 때 또 확장, 변경 해야하는 것인가? 4. 신기술이 연구실 환경에서 개발된 것이라면, 그것이 정말로 실세계 문제를 해결할 수 있을 것인가? 5. 신기술이 프로그래머의 사기를 저하시킬 가능성은 없는가? 6. 신기술을 잘못 적용할 수도 있는가? 7. 신기술을 사용함으로써 발생할 수 있는 위험 요소에 대해 설명한 자료가 있는가? 8. 신기술이 어떻게 실무와 통합되는지 기술한 자료가 있는가? 9. ..

나를 열광시키는 책. Documenting Software Architectures

소프트웨어 아키텍처 문서화에 대한 책이 나옵니다. 영어에 대한 이해도가 짧아서 원서를 읽고도 이해를 못하고 그냥 훑기만 했는데.. 번역된다는 소식을 접한것이 작년 이맘때~ 드디어 번역서가 출간 되었습니다. Wow! 매우 흥분이 되네요. 강컴에서는 이미 예약을 받고 있습니다. 아키텍처 문서화를 어떻게 해야 할까를 고민하는 분에게는 정말 멋진 바이블이 우리의 언어로 재탄생한거죠.. ^^ 솔직히 리뷰어를 통해서 진행하면 참가하고픈 마음이 굴뚝 같았으나~~~ Root 를 몰라서뤼~~ 조만간 에이콘블로그를 통해서 공지도 나오겠군요. 지금 보고 잇는 책들이 좀 있어서 언제 주문하게 될지는 모르겠으나~ 바쁘게 봐야겠습니다~ 이 책을 보기 전에 꼭 봐야할 책이 있죠... 패턴 지향 소프트웨어 아키텍처 지은이 프랑크 부..

토요일 세미나 참여

재미있는 세미나를 손영수님이 기획하셨네요. 박현철 이사님에게 적극적으로 구애하신듯,,, 좋은 인연을 페이퍼미팅때 만드셨네요~ 좋은 행사 감사합니다. 책에서 말하지 않는 이야기는 여러 가지가 있다. 허접해서 차마 말할 수 없는 것(에구, 찔끔). 내용이 어렵거나 방대해서(수조원 이상?) 짧은 지면으로는 녹여내기 어려운 사항들. 국가 또는 기업의 기밀 유지가 필요한 사항들(국방, 비자금?)... 꼭 이런 것들이 아니라도, 책이라는 일방적인 매체를 통해 실제 발생하는 프로젝트 상황을 명확하게 전달하기는 어렵고, 일 잘하는 사람들이 의외로 글재주가 없는 경우가 많아 좋은 지식이 전달되기 어렵고, 일은 진짜 못하지만 글재주가 비상한 경우는... 열심히 읽을 때는 좋았는데, "그래서?"라는 의문만 남는다... "책..

PLOP Paper List

손영수님의 http://arload.wordpress.com 블로그에서 발췌하여 개재합니다.항상 패턴 관련하여 새로운 소식과 몰랐던 것들을 알려주셔서 감사드립니다.지금껏 패턴을 이해할 수 있는 수준이면 되지 뭐 라고 생각했으나, 이젠 조금씩 공부해 놓아야 할 필요성을 느끼고 있습니다. ======================================================== 패턴 학회 PLOP를 아시나요? 1994년 부터 시작된 패턴을 공유하고 활성화하기 위한 Conference로 객체 지향의 유명한 Conference인 OOPSLA와 같은 장소에서 연이어 열립니다. 우리가 알고 있는 유명한 Pattern 서적의 저자라면 이곳을 이미 다 거쳐갔습니다. GoF의 Ralph Johnson, POS..