빅데이터를 적극 활용하게 만드는 7가지 툴

거대하고 다양한 정보가 축적되는 빅데이터는 비즈니스 인텔리전스분야에서 그 중요성이 더욱더 크게 부각되고 있음. 오픈소스 하둡이나 NoSQL기술을 기반으로 한 제품을 공급하는 업체들의 기술은 빅데이터를 수집하고 관리하는데 용이하게 하며, 유저가 원하는 정보를 보다 쉽게 생성할 수 있도록 해줍니다.

　　

특히, 하둡은 빅데이터 활용에 있어 안정적이고 확장이 용이한 분산컴퓨팅 환경으로 현재 널리 사용되고 있습니다. 기업의 정보를 최대한 활용하여 비즈니스를 향상 시킬 수 있는 빅데이터 리포팅, 분석, 시각화, 통합 등을 구현하는 하둡을 적극적으로 활용할 수 있게 만드는 7가지 툴을 소개합니다.

재스퍼소프트 BI 스위트(Jaspersoft BI Suite) 

• 재스퍼소프트 패키지는 데이터베이스로부터 리포팅(Reporting)을 생성하기 위한 오픈소스 비즈니스 인텔리전스 분석 툴 중 하나임

펜타호 비즈니스 애널리틱스(Pentaho Business Analytics)

• 재스퍼소프트처럼 펜타호는 리포팅 생성 엔진으로 시작한 오픈소스 비즈니스 인텔리전스 툴임

카르마스피어 스튜디오와 애널리스트(Karmasphere Studio and Analyst)

• 카르마스피어 스튜디오는 이클립스(Eclipse) 상위 레이어에 구축된 플러그인으로, 하둡 작업 수행에 특화된 솔루션임

탈렌드 오픈 스튜디오(Talend Open Studio)

• 탈렌드는 하둡의 데이터 처리 작업을 위한 이클립스(Eclipse) 기반의 그래픽 유저 환경을 제공하며, 탈렌드의 툴들은 데이터 통합, 데이터 품질 관리들을 원활하게 처리하기 위해 설계됨

스카이트리 서버(Skytree Server)

• 스카이트리 서버는 더욱 정교한 기계학습(machine-learning) 알고리즘을 수행하는 번들을 제공함

타블로 데스크톱과 서버(Tableau Desktop and Server)

• 타블로 데스크톱은 유저가 새로운 방식으로 데이터를 처리할 수 있게 하는 시각화 툴로 이 툴은 유저가 자신의 데이터와 다른 데이터를 합쳐 또 다른 관점에서 기존의 데이터를 검토해 볼 수 있는 장점을 지니고 있음

스플렁크(Splunk)

• 스플렁크는 엄밀하게 말하자면 리포팅 생성 툴이 아니라 데이터를 분석, 인덱싱하는 솔루션으로 방식은 텍스트 검색 프로세스에 더 가까움

자세히 보기 →

다중 SW개발 프로젝트 관리를 위해 갖추어야 할 9가지 테크닉

SW개발 PM들은 보통 2가지 이상의 프로젝트를 책임지고 있습니다. 여러 SW개발 프로젝트를 효과적으로 관리하는데 도움이 될 관리기술로 4가지 비공식적인 기법과 5가지 공식적인 기법을 살펴보도록 하겠습니다. 이러한 기법들은 기존에 모두 존재해 왔고 관리자 대부분이 잘 알고 있으나, 이의 실제 활용을 통해 크고 복잡한 프로젝트를 리드할 경험을 지니는 데 조금이나마 도움이 되고자 합니다.

비공식적인 기법

1. 신뢰할 수 있는 정보원을 가질 것
2. 고객에게 우선권이 있다는 것을 명심할 것
3. 상호 의존하는 것을 배울 것
4. 시간 관리를 철저히 할 것

공식적인 기법

1. 표준화된 공용 보고서를 사용할 것
2. 비용관련 수치들을 주시할 것
3. 프로젝트 주요 진행사항은 문서화 할 것
4. 지속적으로 의사소통할 것
5. 결정은 신속하게 할 것

동시에 다중 프로젝트를 관리하는 것을 통해 향후 크고 복잡한 프로그램 프로젝트를 이끄는데 필요한 경험과 지혜를 발전시킬 수 있다는 긍정적인 측면에서 접근하는 자세가 매우 중요함에 따라 상기 제시된 여러 가지 방법을 활용하여 프로젝트를 성공적으로 이끌 것으로 기대합니다.

자세히 보기 →

12명의 Architect에게 물어 본 “아키텍트의 길” part 1

요구사항분석 , 프로세스와 팀 빌딩 , 설계 시 고려사항

요구사항

모든 요구 사항을 수렴하는 소프트웨어는 존재하지 않는다 . - Mark Richards

전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다 . 소프트웨어 아키텍트 들이라면 알아야 하고 , 이해해야 하며 , 그리고 고객 , 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다 .

1620 년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa 호 ’ 라는 배 이야기입니다 . 스웨덴 국왕은 전쟁을 빨리 끝내기 위해 Vasa 호라는 특별한 배를 만들라고 주문했습니다 . 이 배가 갖춰야 했던 조건 ( 요구사항 ) 들은 그 당시의 어떤 배와도 비교할 수 없었습니다 . 선체가 200 피트 정도 더 길고 , 2 개의 갑판에 64 개의 총을 적재할 수 있고 , 300 명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다 . 배를 건조하는 데드라인 ( 시간 ) 을 엄수해야 했으며 , 재정 ( 자금 ) 적으로도 여유롭지 않았습니다 . 또한 배 설계자 ( 아키텍트 ) 는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다 . 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다 . 그럼에도 불구하고 , 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa 를 설계하고 건조하기 시작했습니다 . 그 배는 결국 설계대로 건조되었고 마침내 배를 출항하는 날이 왔습니다 . 어떻게 되었을까요 ? Vasa 호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다 .

Vasa 호의 문제는 명확합니다 . 그 어느 누구도 1600~1700 년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다 . 전투함과 운송선 2 개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠 .

국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고 , 불완전한 배를 만들 수밖에 없었던 것입니다 . 저희 소프트웨어 설계자들은 Vasa 호로부터 많은 것을 배울 수 있습니다 . 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠 . 하지만 Vasa 호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다 .

프로세스와 팀 빌딩

가장 큰 문제는 기술이 아니라 기회를 잡을 수 있느냐 이다. - Mark Ramm4)

대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다. 한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다. 이러한 경우들에서 문제를 해결하는데 필요한 기술은 매우 오래되었지만 정말 잘 입증되었습니다. 사실 이 기술은 인류의 역사에서 가장 중요한 기술 혁신일 것입니다. 여러분에게 필요한 것은 대화입니다. 기교로써 대화에 단지 익숙해지는 것만으로 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중에 하나입니다.

설계

불확실성을 설계의 지표로 사용해라! - Kevlin Henny7)

여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다. A와 B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다.

자세히 보기 →