1. 반정규화를 통한 성능향상 전략

가.반정규화의 정의

• 반정규화는 정규화된 엔티티,속성,관계를 시스템의 성능향상 및 개발과 운영의 단순화를 위해 중복,통합,분리 등을 수행하는 데이터 모델링 기법이다.
• 디스크 I/O량이 많아서 조회시 성능이 저하되거나, 테이블끼리의 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나, 컬럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 된다.
• 업무적으로 조회에 대한 처리성능이 중요하다고 판단될때 부분적으로 반정규화를 고려하게 된다.
• 설계단계에서 반정규화를 적용하게 되며, 반정규화 미수행시에는 다음과 같은 현상이 발생된다.
  • 성능이 저하된 데이터베이스가 생성될 수 있다.
  • 구축단계나 시험단계에서 반정규화를 적용할 때 수정에 따른 노력비용이 많이 든다.

나.반정규화의 적용방법

• 반정규화에 대한 필요성이 결정되면 컬럼의 반정규화 뿐만 아니라, 테이블의 반정규화, 관계의 반정규화를 종합적으로 고려하여 적용해야 한다.
• 반정규화는 막연하게 중복을 유도하는 것만을 수행하기 보다는 성능을 향상시킬 수 있는 다른방법을 고려하고 그 이후에 반정규화를 적용하도록 해야 한다.

• 반정규화의 대상을 조사한다.
  • 자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고, 항상 일정한 범위만을 조회하는 경우에 반정규화를 검토한다.
  • 테이블에 대량데이터가 있고 대량의 범위를 자주 처리하는 경우, 성능을 보장할 수 없는 경우에 반정규화를 검토한다.
  • 통계성 프로세스에 의해 통계정보를 필요로 할 때, 별도의 통계테이블(반정규화)를 생성한다.
  • 테이블에 지나치게 조인을 많이 하게 되어, 데이터를 조회하는 것이 기술적으로 어려울 경우 반정규화를 검토한다.

• 반정규화의 대상에 대해 다른 방법으로 처리할 수 있는지 검토한다.
  • 테이블에 많은 조인하여 데이터를 조회하는 것이 기술적으로 어려운 경우 VIew를 검토한다. 조회성능을 향상 시키지는 않지만, SQL작성의 미숙함으로 인하여 생기는 성능저하를 예방할 수 있다.
  • 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나, 인덱스 조정을 통해 성능을 향상 시킬수 있다.
  • 대량의 데이터는 PK의 성격에 따라 파티셔닝 기법을 적용하여 성능저하를 방지할 수 있다.
  • 어플리케이션에서 로직을 구현하는 방법을 변경하므로써 성능을 향상 시킬수 있다.

• 반정규화를 적용한다.
  • 반정규화 대상으로는 테이블, 속성, 관계에 대해 적용할 수 있으며, 중복을 통한 방법만이 반정규화가 아니고, 테이블,속성,관계를 추가/분할/제거할 수도 있다.

2. 반정규화의 기법

가.테이블 반정규화

나.컬럼 반정규화

다.관계 반정규화

테이블, 컬럼의 반정규화는 데이터 무결성에 영향을 미치나, 관계의 반정규화는 데이터 무결성을 깨뜨리지 않고도 성능을 향상시킬 수 있는 반정규화의 기법이다.

3. 정규화가 잘 정의된 데이터 모델에서 성능이 저하될 수 있는 경우

전화번호,메일주소,위치정보가 이력형태로 관리되는 데이터모델

• 공급자정보를 가져올 때, 최근의 전화번호/메일/위치정보를 가져오기 위해서는 복잡한 조인을 거쳐야 함.
• 공급자 테이블에 최근 변경된 전화번호,메일주소,위치컬럼을 반정규화하면 간단하게 정보를 조회할 수 있음

4. 정규화가 잘 정의된 데이터 모델에서 성능이 저하된 경우

분산환경에서 타서버의 테이블에서 정보를 가져올때

• 서버B에서 데이터를 조회할 때, 항상 부서명을 가져오기 위해서 서버A를 거쳐야 하므로 성능저하가 발생한다.
• 부서명을 서버B의 연계테이블에 반정규화함으로 써 성능을 개선 시킬 수 있다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743790&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

데이터 과학자들은 머신러닝을 사용해 폐암을 탐지하고 있다. 지난 1월부터 전세계 약 1만 명의 데이터 과학자들이 데이터 사이언스 볼(Data Science Bowl) 대회에서 의료 전문가들이 폐암을 좀더 빨리 탐지할 수 있도록 도와주는 효과적인 알고리듬을 개발하는데 경쟁해왔다.

2010년 NLST(National Lung Screening Trial)는 사람들이 저조도 CT(computed tomography)를 통해 매년 검진을 받는다면 폐암으로 인한 사망자 20%를 줄일 수 있다는 것을 보여줬다. 하지만 조기 탐지를 위한 돌파구를 마련한 이 기술은 전통적인 X레이 이미지와 비교했을 때 오탐지율이 상대적으로 높다.


NCI의 고해상도 폐 영상, Credit: NATIONAL CANCER INSTITUTE

머신러닝업체인 캐글(Kaggle) CEO 앤서니 골드블룸은 부즈 앨런 해밀턴(Booz Allen Hamilton)이 매년 주최하는 데이터 사이언스 볼(Data Science Bowl)에서 "이런 강력한 접근 방법으로 20% 이상의 암 사망율을 낮췄지만, 오진율이 매우 높다"며, "수많은 사람이 자신이 암에 걸렸다는 말을 듣고 이후에 암이 아니라는 얘길듣는다. 이는 당사자에게 엄청난 스트레스를 가하는 것이다"고 말했다.

그래서 올해 데이터 사이언스 볼에서 부즈 앨런과 캐글은 오진율 문제를 해결하기 위해 데이터 과학과 머신러닝의 힘을 빌리기로 결정했다. 양사는 로라 앤 존 아놀드 재단(Laura and John Arnold Foundation)에서 100만 달러의 상금을 확보해 이 대회를 톱 10 콘테스트에 등록시켰다.

사회적 공익을 위한 데이터 과학 
부즈 앨런의 수석 데이터 과학자이자 수석 부사장 조쉬 설리반은 "부즈 앨런과 캐글은 2015년 데이터 과학자를 사회적 공익에 초점을 맞추기 위해 데이터 사이언스 볼을 만들었다"고 말했다.

설리반은 "우리는 자사의 이익보다 더 큰 사회적 공익을 위해 무언가 함께 만들고 싶었다. 상당한 가치가 있는 공익을 위한 일은 어떤 것이 있는가? 자사의 이익, 고객의 이익이 아니라 공공을 위한 과학적 발견이 가져올 수 있는 그 무언가를 원한다. 오픈소스와 크라우드 소스를 통해 전세계 사람들에게 공급할 것이다"고 설파했다.

제 3회 데이터 사이언스 볼 대회에서는 300건이 넘는 아이디어가 제출됐다. 이전 대회에서는 해양 생태계 측정과 심장 질환 탐지에 초점을 맞췄다. 설리반은 "궁극적으로 더 많은 환자들에게 더 많은 치료법을 제공하고 암 예방과 조기 발견을 향상시키기 위해 암 연구를 가속화하기 위해 노력 중인 보 바이든 암퇴치(Beau Biden Cancer Moonshot)와 미국암연구소(National Cancer Institute, NCI)를 돕기로 결정했다"고 말했다.

NCI는 데이터 사이언스 볼에 2,000개의 익명화된 고해상도 CT 스캔 영상을 제공했는데, 각 영상의 데이터 용량은 기가바이트급이었다. 설리반은 이 가운데 1,500개의 이미지는 최종 진단을 동반한 훈련 세트라고 말했다. 나머지 500개의 이미지는 문제의 집합이다. 머신러닝 알고리듬은 훈련 세트를 이용해 500개의 이미지에 담겨진 폐의 병변이 암인지의 여부를 정확히 결정하는 방법을 배워야 했다. 이 알고리듬은 정확한 진단의 백분율을 기준으로 채점됐다.

이 데이터는 캐글의 플랫폼에 저장되어 있다. 지난 3월 구글이 인수한 캐글은 2010년 골드블룸에 의해 설립됐으며, 특히 예측 모델링과 분석 기술 대회를 주최해왔다. 기업과 연구원들은 그들의 데이터를 게재해 데이터 과학자들이 최고의 모델을 만드는데 경쟁할 수 있도록 한다. 캐글은 전세계 200여 국가에서 수십만 명의 등록된 '캐글러(Kagglers)'를 보유하고 있다.

이번 경쟁에서 캐글러들은 나선구조신경망(convolutional neural networks, CNN) 전문가였다. 나선구조신경망은 생체 내 시각적 매커니즘에 영감을 받은 딥 러닝 신경망의 한 유형이다.

CNN은 다른 유형의 문제에도 유용하지만 컴퓨터 가시성 문제에 뛰어나다. 이전 캐글 경쟁에서 캐글러들은 소셜 미디어에서 개와 고양이 그림을 구별할 수 있는 CNN 기반 알고리듬을 만들기 위해 경쟁하기도 했다.

NCI에 의해 제공된 CT 영상에 대해 골드블룸은 "이 데이터는 전혀 새로운 것이었다.
실제 이는 나선구조신경망을 이전에는 가지 않았던 방향으로 밀어붙였다. 의료 데이터 세트는 데이터 세트의 크기로 인해 항상 문제가 되어왔다. 인터넷에서 고양이와 개의 그림은 몇 개나 될까? 아마도 수백만 개일 것이다. 그러나 의료 이미지를 모두 수집하는 데에는 극도로 많은 비용이 든다. 개와 고양이 사진을 찍는 것보다 CT 촬영을 하는 이는 더 적다"고 설명했다.

골드블룸은 "CNN에 대해 관찰 수에 비해 너무 많은 매개변수를 갖고 있기 때문에 기본 관계보다 잡음을 설명하는 경향이 많은 과적합(overfitting)의 가능성이 높다"고 말했다.

과적합이 되지않은 나선구조신경망을 만드는 것은 어려우며, 데이터 세트가 작을수록 더 어려운 경향이 있다. 이는 실제 이 기술이 갖고 있는 문제로, 상대적으로 적은 수의 이미지를 갖고 일반화해야 한다.

거의 1만 명에 가까운 캐글러들이 이번 데이터 사이언스 볼 대회에 참여했다. 총괄적으로 이 참가자들은 15만 시간을 보내고 약 1만 8,000개의 알고리듬을 제출했다. 다수의 방사선 전문의들은 자신의 전문지식을 활용해 캐글의 포럼 참가자들을 지원했다.

데이터 사이언스 볼 수상자 
결국, 우승자는 중국 칭화대학의 연구원인 랴오 팡저우와 저 리였다. 네덜란드 머신러닝 엔지니어인 줄리안 더 빗과 대니얼 해먹이 2위를 차지했다. 네덜란드 기반의 기업에서 근무하는 팀은 3위를 차지했다.

미국 국립보건원(National Institutes of Health, NIH)은 미국 식품 의약품국(Food and Drug Administration, FDA)와 협력해 CT 영상을 읽는 소프트웨어 내 이런 분석 기술이 적용될 수 있게끔 한다는 방침이다. 설리반은 "이것이 우리가 추구하는 것이며, 효과다"고 말했다.

설리반은 "NIH와 FDA는 다수의 최적절한 알고리듬을 고려할 것을 기대한다. 최고의 팀간에는 사실 약간의 점수차에 불과했으며 일부는 좀더 많은 발전 가능성과 확장성을 갖고 있다"고 말했다. editor@itworld.co.kr 

원문보기: 
http://www.itworld.co.kr/t/54649/%EB%B9%85%EB%8D%B0%EC%9D%B4%ED%84%B0/104665#csidx5595e3a51b0c498b08b330aa65e9af5 

현업 사용자들이 직접 BI에 접근하고 툴을 사용하는 이른바 '새로운 분석'의 시대가 도래했다.

약 2년 전, 케어퍼스트 블루크로스 블루실드(CareFirst BlueCross BlueShield)는 기업 전체에 산재하고 있는 복수의 스토리지로부터 얻은 막대한 분량의 데이터를 취합하고 분석하기 위해 셀프서비스 BI를 구축했다.

캘리포니아의 팔로 알토에 위치한 클릭테크(QlikTech)가 개발한 이 기술은 CA 테크놀로지스의 프로젝트 관리 제품에 대한 보완재로 도입됐다. 현재까지 케어퍼스트는 프로젝트 비용에서 1,000만 달러를 절감할 수 있었으며 이것을 사용하는 외부 계약업체를 25%까지 줄일 수 있었다.

과거 18개월이 소요되던 활동은 현재 2일 이내에 가능해 졌다. 또한 프로젝트 관리 부서는 더 이상 BI 보고서를 작성하기 위해 중앙의 분석팀에게 기댈 필요가 없게 됐다.

매릴랜드(Maryland)에 있는 케어퍼스트 같은 기업들은 전문가들이 말하는 BI 및 데이터 분석 활동에서 극적인 변화에 직면하고 있다.

컨설팅 기업 PwC는 이것을 ‘새로운 분석’이라고 부르고 있다. 중앙에 집중된 하향식 데이터 수집, 보고, 분석에 의존하는 기존의 BI 및 데이터 분석모델과는 이 새로운 물결은 BI 보고 및 데이터 분석의 최대 수혜자인 영업부문 사용자들에게 직접 접속권한과 툴을 제공하는 것이라고 지난 화요일에 공개한 보고서에서 PwC가 밝혔다.

"새로운 분석은 중앙부서가 분석할 수 없는 해답을 찾기 위해 광범위한 비즈니스 생태계의 전문지식을 활용한다"라고 PwC는 전했다. "중앙식 분석을 위한 당면과제는 사업부가 스스로 어떤 것을 찾고 있거나 어떤 증거를 원하고 있는지 확신이 서지 않을 때 현업의 필요에 부응하는 것이다. 새로운 물결은 발견을 위해 노력하는 사람들에게 접속권한과 툴을 제공한다."

새로운 분석의 배경
BI시장에서 두 가지 트렌드가 변화를 이끌고 있다. 하나는 클라우드 컴퓨팅, 모바일 컴퓨팅, 소셜 미디어 등으로 인한 데이터의 폭발적인 증가다. 저렴한 하드웨어, 메모리, 스토리지 기술 덕분에 기업들이 거대하면서 다양하고 빠르게 성장하는 데이터 세트를 손쉽게 수집할 수 있게 됐다는 점이다. 현재 많은 기업들이 이 모든 데이터를 검토하고 분석해 비즈니스적 장점을 누릴 수 있는지 조사하고 있다.

또 다른 트렌드는 기업들이 좀 더 쉽게 거대한 데이터 세트를 취합하고 분석할 수 있도록 하는 툴의 이용성 증가다. 많은 툴들이 빅 데이터를 취급하고 인메모리 데이터베이스, NoSQL 지원, 데이터 시각화, 연합 검색, 자연어 처리 등 기업들이 데이터를 좀 더 쉽고 빠르게 분석할 수 있도록 하는 기능을 포함할 수 있도록 설계되고 있다.

예를 들어, 케어퍼스트는 셀프서비스 BI 클릭뷰(QlickView) 기술을 이용해 전통적인 BI 접근방식으로 투자한 시간과 노력의 일부만으로 프로젝트와 자원에 대한 실시간 가시성을 확보할 수 있다고 매릴랜드에 있는 케어퍼스트 PMO 담당 이사 캐롤 처치는 말했다.

이 기술을 통해 케어퍼스트는 복수의 데이터 스토리지에서 데이터를 수집하고 속도가 빠른 인메모리 데이터베이스에서 한데 취합해 예전보다 더욱 빠른 속도로 모든 종류의 분석을 수행한다.

전통적인 분석 처리 툴을 이용하는 분석가들은 우선 일련의 질문을 개발하고 IT가 관련 데이터를 취합하길 기다렸다가 데이터를 다듬고 상이한 데이터 요소들 사이에서 통로를 구축하여 분석을 가능하게 한다고 매년 120~140개의 프로젝트를 관리하고 있다는 처치는 말했다.

한편, 애널리스트들은 클릭뷰를 이용해 데이터 요소를 자유롭게 비교하고 상황에 따라 애드 혹(Ad Hoc) 기반으로 관련성을 찾는다고 그녀가 말했다.

이와 유사한 기능을 활용하고 있는 또 다른 기업은 시멘트블록(CementBloc)으로 뉴욕에 있으며 거대 제약회사들이 의사소통과 마케팅 전략을 미세조정하고 최적화할 수 있도록 돕고 있다. 해당 기업은 팁코의 스폿파이어(Sportfire) 분석 플랫폼을 이용해 복수의 정보 출처로부터 얻은 데이터를 통합 및 분석하고 있다.

"전통적인 BI 툴을 사용할 때는 무엇을 예측하게 될지 알아야 한다"라고 시멘트블록의 정보 및 분석담당 부사장 아이라 하이모위츠는 말했다. "고객 부분, 위치, 프로그램에 관한 지도별로 무엇을 예측하게 될지 알아야 하며, 그 다음 쿼리와 보고서를 생성해야 한다"라고 하이모위츠가 설명했다.

스폿파이어의 인메모리 데이터베이스 기술과 검색 및 데이터 시각화 역량을 통해 이런 요건을 상쇄할 수 있다. 이 기술 덕분에 시멘트블록은 마음대로 거대하고 다양한 데이터 세트를 연구하고 이전에는 알지 못했던 데이터 요소들 사이의 관계를 발견할 수 있게 되었다고 그가 말했다.

클릭뷰와 팁코만이 BI, 데이터 시각화, 데이터 분석 툴을 제공하는 것은 아니다. 지난 몇 년 동안 버스트(Birst), 타블로(Tableau), 데이터미어(Datameer), 스플렁크(Splunk) 등 많은 IT업체들이 새로운 BI 애플리케이션을 내놓으며 IBM, 테라데이타, SAS 등과 경쟁하고 있다.

해당 툴들을 통해 기업들은 "데이터를 수집하고 이동하여 분석할 수 있는 더 많은 방법을 얻게 되었다"라고 PwC의 적용 분석 책임자 빌 아보트는 말했다. 일부 기업들은 이런 툴들을 적용하여 기존의 데이터 세트를 통합, 추출, 분석하고 있다. 다른 많은 기업들이 하둡 등의 빅 데이터 기술에 기반하여 새로운 데이터 인프라 위에서 이것들을 사용하고 있다고 아보트가 말했다.

"20년 전에는 요건 취합을 매우 강조했었다. 왜냐하면 모든 대답을 사전에 계산하고 싶어했기 때문이다"라고 클릭테크의 CTO 안토니 다이튼이 말했다. "사용자들이 물어보고 싶어할만한 모든 질문을 미리 예상해야 했다. 이를 통해 BI 프로젝트를 위한 서비스 중심적인 이행 모델을 얻을 수 있었다"라고 그는 전했다.

PwC는 자사 보고서에서 새로운 분석은 "예상하지 못했던 기회와 위협을 검출하거나 존재를 알지 못했던 미래의 고객이 될 수 있는 사람들을 찾아내는 것이다"라고 밝히고 있다. "이것은 중요하다고 생각했던 것들이 아니라 실제로 무엇이 중요한지를 배우는 것이다. 이것은 기업이 가장 크게 변화시켜야 할 부분을 찾고 수용하여 이행하는 것이다." ciokr@idg.co.kr

원문보기: 
http://www.ciokorea.com/news/12664?page=0,1#csidxe618239bb5126c996a3e62ede213ab2 

챗봇과 대화하다가 민감한 개인 정보를 입력하는 경우가 많다. 기업 내 챗봇 보안을 강화하고 프라이버시 위협을 최소화하는 방법을 알아보자.

빅데이터에서 챗봇이 새로운 취약점이 될 가능성이 있을까? 그렇다. 기본적 인사과 질문에 대답하거나 기업 단위 설문조사를 실시할 때, 사용자를 특정인과 연계하기 전 정보를 얻는 챗봇은 슬랙과 기타 메시지 앱에 부가 기능으로 추가되어 보안 위험을 높인다.

챗봇 업체 탈라(Talla) CEO 롭 메이는 보안 위기가 봇을 구입하는 방식에서 온다고 말했다. 즉, “SaaS 초기에는 마케팅 부서가 IT 부서의 승인 없이도 웹 브라우저만 있으면 바로 소프트웨어를 구입하는 방식으로 판매되었고, IT 부서는 큰 문제가 없다고 생각했지만 결국 기업 전체가 SaaS 방식으로 운영되기 시작했다”고 설명했다. 그러면 갑자기 기업의 핵심 운영이 난데없이 나타난 사용자나 데이터 관리 경험 없는 플랫폼으로 운영되기 시작한다. 챗봇에서 오는 데이터 취약점을 차단하기 위해 메이는 현재의 봇 구입과 이행 간소화를 권장한다.

안타깝게도 직원들은 이미 챗봇으로 급여정보, 의료보험 세부사항 같은 기밀 데이터를 공유하고 있을지 모른다. IT 부서가 데이터를 안전하게 보호하기 위해 어떤 조치를 취할 수 있을까? 어떻게 하면 이 취약점을 미리 막을 수 있을까? 그 외에 어떤 질문이 유용할까?

챗봇을 활용하는 방식을 파악하라
컴퓨터 및 네트워크 보안 제공자 라피드7(Rapid7)의 개발자 프라이야 도드워드 는 현재의 상황을 분류하는 것부터 시작하라고 말했다. 그리고 나서 구매에 앞서 사용자와의 면담을 실시한다. 이렇게 하면 2가지 측면에서 도움이 된다. 우선, 사용자 반응을 통해 도입 고려 중인 챗봇을 계획대로 활용하게 될지를 알 수 있어 사용자 도입 및 생산성을 높인다. 또 면담은 위협 수준 평가에 도움이 된다. 보호하고 있는 데이터의 유형을 알면 챗봇 프라이버시 문제에 더욱 잘 대비할 수 있다.

라피드7이 새로운 챗봇을 고려할 때 도드워드는 “우리는 우선 ‘일단 어떤 정보가 수반되는가? PII(Personally Identifiable Information) 데이터인가 아니면 기밀 또는 매출 관련 데이터인가?’고 생각한다. 봇이 가장 걱정스러운 요소”라고 말했다. 라피드7은 슬랙 채팅에 gif를 붙여 넣는 등 필수적이지 않은 작업에는 엄격하지 않은 프로세스로 봇을 운용하고 있다.

하지만 문제는 사람들이 부적합한 도구를 통해 중요한 주제로 채팅한다는 점이다. 허브스폿(Hubspot)의 CIO였던 짐 오닐은 “인간들이 자진해서 데이터를 제공한다는 사실을 기억하라”고 경고했다. 예를 들어, gif 봇으로 직원이 재미 있는 문병 메시지를 보내고, 사람들이 이어서 암 진단에 관해 이야기하는 경우다. 오닐은 “봇과의 대화 상호작용의 경우 우리는 의도한 것보다 더 많은 정보를 포기할 수 밖에 없다”고 말했다.

챗봇이 작동하려면 질문을 던져야 한다. 획득하는 데이터는 상황을 평가하고 훈련하는데 도움이 된다. 오닐은 “봇이 더 많은 도움을 제공하고 더 많이 배우기 위해 더 많은 것을 질문할수록 더 민감한 데이터를 많이 얻게 된다”고 말했다. 예를 들어, 의료보험 고객을 사안에 따라 관련 부서로 이관하는 봇을 생각해 보자. 봇은 우선 고객의 청구 번호를 요청하고, 사용자는 “번호는 4652이며 발진에 대한 조치를 취해야 하기 때문에 STD 테스트가 처리되는지 알아야 한다”고 입력할 것이다.

그 외에 챗봇 정보를 보는 사람은 누구인가?
IT는 시스템에 예상치 못한 데이터가 입력되는 상황에 대비해야 하고, CSO는 이 정보를 보는 사람이 누구인지도 파악해야 한다. 새 업체를 고려할 때 메이는 데이터가 필연적으로 이동하는 곳이 어디인지를 파악하라고 권고한다. 데이터가 로컬에 저장되는가? 아니면 클라우드에 저장되는가? 누구에게 이관되는가? 봇은 어떻게 훈련되는가?

대부분의 머신 러닝에서처럼 사람들은 엔진을 개선하기 위해 기업 챗봇의 작업을 확인하는 경우가 많다. 인간 검토 작업이 업체 프로세스에 포함되어 있는 경우 메이는 이렇게 질문하라고 말했다. “데이터를 보는 사람은 누구인가? 아마존의 미케니컬 터크(Mechanical Turk) 서비스 밖으로 유출되는가? 집단 파일에서 벗어나는가? 이 문제에 관심을 쏟고 있는가?”

메이에 따르면 이 방법에는 “장단점이 있다”. 때로는 챗봇이 유일한 수단일 수도 있기 때문이다. 결단을 내려야 한다. 데이터가 유출되어도 괜찮은가? 데이터는 어디로 유출되는가? 봇은 어떻게 훈련되는가?”

메이는 챗봇 위험에 관한 SLA(Service Level Agreement)를 이행하는 것이 하나의 방법이라고 말했다. 일반적으로 SLA에 포함되는 업타임(Uptime) 요건, 품질 기대치, 기타 사안을 포함하는 것 외에 계약서에서 챗봇 암호화와 유사한 보안 기대치를 다루어야 한다. 업체는 어떤 외부 제공자(아마존 터크 등)를 취급하는가? 계약기간 동안 SSAE-16/SSAE-18 인증 또는 SOC 2 준수성이 유지될까? 그렇지 않은 경우 어떻게 되는가?

챗봇 개념 증명부터 시작하라
위험을 완화하기 위해 도드워드는 라피드7에 있는 대부분의 외부 챗봇이 개념 증명(POC)으로써 시작된다고 말했다. POC에 성공한 후에야 광범위하게 도입된다. 그는 POC가 필요를 다시 평가할 수 있는 기회이기도 하다고 말했다. “해당 봇의 범위를 파악하는 것이 중요하다. 모든 직원들에게 도달할까? 아니면 특정 부서에서만 활용될까? 이 문제는 우리가 배치를 계획하고 이를 중심으로 훈련하는 방식에 영향을 끼친다.” 도드워드는 라피드7이 기술 기업임에도 불구하고 많은 직원들이 “기술에 능하지 않기 때문에 봇이 매우 직관적이어야 한다”고 말했다.

직관적일수록 좋다. 챗봇은 구매 목적에 알맞은 솔루션을 제공할 수 있고, 사용자들도 개인적이고 불필요한 데이터를 입력하지 않게 된다. 의료보험 예시로 돌아가면, 사용자가 너무 많은 데이터를 제공하지 않도록 봇이 “다른 정보는 없이 청구 번호만을 알려주세요”라고 요청하는 경우 발진 등의 의료 정보에 관해 이야기하는 사용자가 줄어들 것이다.

직원 대응 챗봇은 사용자 교육을 통해 공유에 적합한 정보 수준을 알려준다. 또, 직원 교육은 SaaS 초기에 목격되었던 악의적인 이행의 위험을 낮춘다. 직원들이 챗봇 프라이버시 위험의 중요성을 이해한다면 설치에 앞서 IT가 관리하는 새로운 봇을 사용할 수 있다.

사소한 챗봇 데이터 유출도 인지하라
메이는 IT가 권한이 있는 사람을 판단해야 한다고 말했다. “점심 메뉴 설문조사를 수행하는 봇은 간단하게 여겨지기 쉽지만, 사실 많은 봇들이 크리덴셜을 이용해 시스템을 연결한다”는 것이다. 이것을 어떻게 모니터링할까?

개인의 즉석 설치까지 제한하려면, 직원들에게 소규모 데이터 유출이라도 큰 피해를 끼칠 수 있음을 인지시킨다. 메이는 탈라를 설립하기 전 회사인 백업피파이(Backupify)에서 해킹을 시도했던 사례를 공유했다. 누군가 CFO의 이메일 주소를 이용해 은행 계좌에서 자금을 인출하려다 실패한 일이 있었다. 메이는 “봇이 회사에 대해 안다면, 사람들이 일련의 질문을 던지고 정보를 검색하며 데이터를 추가할 때 부적절한 정보가 제공된다”고 말했다.

데이터를 제출할 때 동료를 위협해서는 안 된다. 현재 여러 가지 기업 활동 중 봇에 가장 큰 영향을 받는 것은 HR이다. 기업 챗봇은 채용을 더욱 효율화하고 새로운 직원을 고용하며 직원이 이직할 가능성을 예측할 때 사용된다. 탈라의 챗봇은 “남아 있는 휴가 기간은?” 등의 보편적인 질문에 답하면서 HR 직원들의 수고를 덜어준다. HR 챗봇 등이 작동하려면 직원들이 반드시 편안하게 대화할 수 있어야 한다. 오닐은 “PII, PHI 등 모든 정보가 제공될 것이다. 우회하기보다는 포용하라. 데이터의 흐름을 이해하고 봇과 채팅 상호작용 통합을 추진하는 기업을 신뢰하게 되면 더 나은 결과에 대한 확신이 설 것이다. 그러면 더 나은 데이터를 얻고 더 많은 정보에 기초한 결정을 내릴 수 있다”고 조언했다. editor@itworld.co.kr 

원문보기: 
http://www.itworld.co.kr/news/106622#csidxaa9682ef890ae73ab78deebeab78634 

1. 성능 데이터 모델링의 정의

성능 데이터 모델링 데이터베이스 성능향상을 목적으로 설계단계의 데이터 모델링 때 부터 정규화, 반정규화, 테이블통합, 테이블분할, 조인구조, PK, FK등 여러가지 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것이다.

2. 성능 데이터 모델링 수행시점

성능 데이터 모델링은 언제하면 좋은가?

• 사전에 할 수록 비용이 들지 않는다.
• 분석/설계단계에서 성능을 고려한 데이터 모델링을 수행하면, 나중에 성능저하때문에 발생하는 재업무(Rework)비용을 최소화할 수 있다.

비즈니스 처리에 핵심적인 트랜잭션이 있다면, 프로젝트 초기에 운영환경에 대비한 테스트환경을 구축하고 트랜잭션을 발생시켜 실제 성능테스트를 해보아야 한다.
데이터 모델의 구조도 변경하면서, 가장 적절한 구조인지를 검토하여 디자인하는 전략이 요구된다.

3. 성능 데이터 모델링 고려사항

일반적으로 성능 데이터 모델은 다음과 같은 프로세스로 진행하는 것이 데이터 모델링 단계에서 성능을 충분히 고려할 수 있는 방안이 된다.

1) 데이터 모델링을 할 때 정규화를 정확하게 수행한다.
2) 데이터베이스 용량산정을 수행한다.
3) 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
4) 용량과 트랜잭션 유형에 따라 반정규화를 수행한다.
5) 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행한다.
6) 성능관점에서 데이터 모델을 검증한다.

=> 데이터모델을 검토할 때는 일반적인 데이터 모델규칙만 검증하지 말고, 충분하게 성능이 고려되었는지도 체크리스트에 포함하여 검증하도록 한다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743520&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제4절 관계(Relationship)

1. 관계의 개념

가. 관계의 정의

• 인스턴스 사이의 논리적 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태

나. 관계의 페어링(Relationship Paring)

• Relationship 은 Entity 안의 Instance 가 개별적으로 관계를 가지는 것(Paring)이고 이것의 집합을 관계로 표현한다는 것이다.
  따라서 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 Entity 사이에 2개 이상의 관계가 형성 될 수 있다.

2. 관계의 분류

3. 관계의 표기법

가. 관계명(Membership) : 관계의 이름

나. 관계차수(Degree / Cardinality) : 1:1, 1:M, M:N

다. 관계선택사양(Optionality) : 필수관계, 선택관계

4. 관계의 정의 및 읽는 방법

가. 관계 체크사항

• 두개의 Entity 사이에 관심있는 연관규칙이 존재하는가?
• 두개의 Entity 사이에 정보조합이 발생되는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

나. 관계 읽기

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743462&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제3절 속성(Attribute)

1. 속성(Attribute)의 개념

• 속성(Attribute) 의 사전적 의미
  • 사물의 성질, 특징, 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것
  • 본질적 송석이란 어떤 사물 또는 개념에 없어서는 안될 징표의 전부이다.
  • 징표는 사물이나 개념이 어떤것인지를 나타내고 그것을 다른 것과 구별하는 성질
• 데이터 모델링 관점에서 속성(Attribute) 의 정의
  • 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위
  • 엄무상 관리하기 위한 최소의 의미 단위
  • 속성은 엔터티를 성명하고
  • 속성은 인스턴스의 구성요소
• 예시
  • 생년월일은 그 자체로 의미가 있으므로 속성이라 할 수 있다.
    생년, 생월, 생일 로 분리가 가능하지만 이는 하나의 속성을 관리목적으로 분리한 것일 뿐 각각을 속성이라 할수는 없다.
  • 이름과 주소는 각각 의미있는 속성이지만 '이름주소'로 묶는다면?
    하나의 속성이 두가지 의미를 가지므로 기본 속성이라 할 수 없다.
    차라리 '이름주소'가 아닌 '인적사항'정도로 관리한다면 속성으로 볼수도 있다.

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

가. 엔터티, 인스턴스, 속성, 속성값의 관계

나. 속성의 표기법

3. 속성의 특징

• Entity 와 마찬가지로 해당 업무에서 필요하고 관리하고자 하는 정보
• 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
• 하나의 속성은 하나의 값만 가진다.
  하나의 속성에 여러개의 값이 있는 경우, 별도의 Entity 를 이용하여 분리한다.

4. 속성의 분류

가. 속성의 특성에 따른 분류

• 1) 기본속성 : 업무로부터 추출한 모든 속성
• 2) 설계속성 : 코드성 데이터, Entity 식별용 일련번호
• 3) 파생속성 : 다른 속성에 영향을 받아 발생하는 속성, 계산된 값, 합계, 재고, 잔액
  • 파생속성은 그속성이 가지고 있는 계산방법에 대해 반드시 어떤 엔터티에 어떤 속성에 의 해 영향을 받는지 정의가 되어야 한다.
  • 타 속성에 의해 지속적으로 영향을 받아 자신의 값이 변하는 성질을 가지고 있는 속성
  • 파생속성은 꼭 필요한 경우에만 정의하여 업무로직이 속성내부로 스며들지 못하도록 주의해야 한다.
  • 파생속성을 정의한 경우라면 그 값의 정합성을 유지할 수 있도록 해야 한다.
  • 통계관련 엔터티, 배치작업 수행 관련

나. 엔터티 구성방식에 따른 분류

5. 도메인(Domain)

• 속성이 가질 수 있는 값의 범위

6. 속성의 명명(Naming)

• 용어사전 : 속성 이름을 정확하게 부여하고, 용어의 혼란을 없애기 위함
• 도메인정의 : 각 속성이 가지는 값의 범위를 명확하게 하기 위해
• 속성명 부여 원칙
  • 1. 해당 업무에서 사용하는 이름을 부여한다.
  • 2. 서술식 속성명은 사용하지 않는다.
  • 3 약어사용은 가급적 제한한다.
  • 4. 전체 데이터 모델에서 유일성 확보하는 것이 좋다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743420&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.