❍ Reading Summary 

본 글은 비즈니스 이노베이션에 있어서 분석에 관한 자료로서, 데이터 분석이 기업에게 있어 어떤 이유로 대두되고 있으며, 현 상황을 조망하여 최종적으로 기업에게 필요한 Data Governance를 제시하고 있다. 

본문 초반 Moody의 미국 타이어 및 자동차 수리점인 Bridgestone의 분석 부서에 대한 이야기로 시작한다. 매장의 새로운 위치를 선정하기 위한 정교한 작업에 데이터 분석이 효과적인 역할을 수행하였으며, 이러한 분석 사용이 수 많은 기업간 경쟁에서 이기는데 도움이 되는 것을 강조하고 있다. 이러한 사례들이 늘어나면서 비즈니스의 기능뿐만 아니라 비즈니스 모델을 데이터 분석을 활용하여 근본적으로 혁신하는 기업이 늘어남에 따라, 본 글은 데이터 분석 기반의 혁신의 원동력에 대해 다루고 있다. 

주목할 만한 점은 본 글의 근거가 수많은 데이터 관리자들에 대한 설문을 통해 이루어졌다는 점이고, 이를 통해 보다 현실적인 기업의 데이터 분석 활용에 대해 알 수 있었다는 점이다. 이를 테면, 기업들은 현재 데이터가 넘쳐나는 환경에 처해 있으며, 보다 올바른 데이터 거버넌스를 필요로 한다는 점, 이제는 더 이상 경쟁 우위에 데이터 분석이 작용하고 있지는 않지만 그 만큼 보편화 되었다는 점 등을 들 수 있다. 

특히, 본 글에서 실제로 데이터 분석이 자주 그리고 효과적으로 사용되는 부서에 대해 언급하여 어떻게 기업들이 ‘현재’ 데이터 분석을 활용하고 있는지 들여다 볼 수 있었다. 예를 들어 신제품 혁신에 있어 판매(58%), HR(56%), 제품 개발(52%), R&D(49%)부서가 데이터를 사용한다는 구체적인 수치를 통해 기업의 관심과 협업 대상에 대해 짐작할 수 있었다. 

그리고 최종적으로 공유할 수 있는 데이터와 없는 데이터를 제어하여 데이터 공유를 장려하는 데이터 거버넌스에 대한 중요성을 통해 데이터 기반의 협력의 중요성을 강조하며 끝을 맺고 있다. 

❍ Comment 

본 글에서 언급되는 최적화나 혁신이나 기업 비즈니스 모델 개선에 있어서 데이터 분석의 ‘영속성’에 대해 좀 더 다루어졌으면 하는 바램이 있다. 기존의 다양한 데이터 기반의 분석 프로젝트를 수행하면서, 특히 본 수업시간에서 다루는 Feature Based Prediction 기반의 데이터 분석을 수행함에 있어서 과연 데이터 분석이 얼마나 꾸준히 업무가 생길 것이냐 하는 부분에 항상 의문이 있어왔다. 

물론, 파생변수를 생성하고 외부 2차 데이터간의 결합을 통해 끊임 없이 Feature를 만들어 낸다는 점은 얼핏 보면 영속성을 지니는 것처럼 보이지만 그 효율성 측면에 있어서는 그렇지 못하다. 이를 테면, 본문 초반의 자동차 수리점의 위치선정에 있어서 데이터 분석을 사용하여 핵심 key feature 기반의 모델을 수립했다고 하자. 해당 모델을 다른 2차 자료를 통해 보강하고 추가할 수 있겠으나, 한 번 특이점을 지난 모델을 만들어 내면 그 이후에 효율성이 증가하는 수치는 멱함수의 법칙에 의해 미비한 것이 사실이다. 이렇게 되면 해당 데이터 분석을 수행한 팀은 회사내의 다른 프로젝트로 옮겨지게 될 것이고 데이터 분석이 필요한 모든 부서에 핵심 모델들을 만들어 낸다면 그 이후의 일에 대한 the next thing에 대한 고민이 필요하게 된다. 

하지만, 본 글에서는 아직은 효율이 좋은 데이터 분석의 ‘현재’에 대해서만 언급되어 있는 부분이 아쉬운 부분이다. 새로운 서비스를 끊임없이 만들어 낼 수 있는 ‘개발’이나 ‘AI’ 분야에 비해 ‘데이터 분석’이 지니는 한계점까지 다루어 줬으면 하는 개인적인 바램이 있었으나 아쉬운 측면이 있는건 사실이다. 
또한, 본 글에서는 AI나 Machine Learning에 대해 사람을 대체하기 보다는 사람이 혁신 업무에 투입될 것이라는 가정에 기반을 두고 작성되었다. 본 글을 읽는 독자가 ‘기계가 아닌 사람’임을 고려하고 염려한 기술 방식이라고 추측된다. 혹은 대외적으로 기업들이 공개한 ‘사람들에게 더 나은 일자리를 제공할 것’이라는 HR 홍보부의 말을 그대로 옮긴 듯해 보인다는 점도 간과할 수 없다. 실제로 현장에서 이루어지는 데이터 분석의 자동화로 인한 일자리 감소로 인한 혁신에 대해서도 다루었으면 하는 아쉬움이 남는다. 

그럼에도 불구하고, 본 글은 현 시점이 데이터 분석 직군이 처음 신설되고 태동하는 단계임을 고려하였을 때, 다양한 실제 기업의 사례와 예시를 통해 효과적으로 데이터 분석의 중요성을 강조하고 있음에 그 의의가 있다. 특히, 대부분의 데이터 분석의 글에서는 마치 황금알을 낳는 거위마냥 상징화 하는 부분이 많았으나, 본 글은 다양한 수치 통계 기반의 해석과 데이터 분석이 경쟁의 핵심역량으로 여겨지는 비율이 상대적으로 보편화 되어감에 따라 떨어지고 있다는 점 또한 지적하고 있어 보다 객관성을 확보한 글이라 판단된다.
 
또한, ‘데이터 분석’에서 끝나는 글이 아니라 ‘데이터 거버넌스’를 비롯한 구체적인 데이터 분석 역량 확보 방안을 강조한 점 또한 인상적인 글이라 할 수 있겠다. 


Java 자바 프로그래밍: Spring, Mybatis vs JPA vs Hibernate

 
다음주에는 오전수업 스프링. 그 이후에는 자바스크립트.
요즘은 함수식 언어가 대세가 될 것 같아요. From 어제 컨퍼런스 임백준씨 발언.
My Batis는 제가 봐온 라이브러리 중에 제일 단순한 녀석이에요.
자바의 객체 지향 설계를 보면 테이블과 굉장히 유사해요.
2000년대 초반에는 객체지향 언어가 유행했죠. 모듈화 라던가 분업. 역할분배. 구성. 이런 것들에 대한 장점이 있었죠. DB가 되면서 DAO라는 패턴이 나오기 시작했죠.
RDBMS과 OOP가 관계가 많더라.
 -> SQL지상주의(DBA, Legacy 기존시스템)
  라이브러리를 사용해서 SQL를 좀 쉽게 객체화 시켜 쓰자!
 -> 새로운 방식
객체를 아예 관계 DB Object Relational Mapping 하자! 라는 말도 안되는 이야기가 있었죠. ORM 실패했습니다. 이게 되려면 DB와 객체지향 설계가 완벽했다는 이야기가 전제되어 있어요. 한국은 SQL의존도가 심했기에 망했죠. 미국, 호주에서는 꽤 흥했어요. Hibernate라는게 있었죠. 아무튼 우리나라에서는 SQL을 그대로 두고 그 결과를 가지고 SQL Mapping을 하기 시작했어요. iBatis가 나왔죠. Ver 2.x까지는 성공을 거두죠.
Mybatis vs JPA vs Hibernate 한국에서만 Mybatis를 사용하고 전 세계적으로는 아니죠.
.jsp 파일에서 #{title} -> getTitle() 과 같다.  이게 기능의 전부에요.
Mybatis를 프레임워크라고 생각하지 않아요. 확장을 할 수 없기 때문이죠.
꽤 성공적인 프로젝트였어요.
iBatis -> XML기반.
설정파일. Config 파일. SQL(매핑파일)
log4j.properties과 mybatisConfig.xml 파일은 Java -> src 폴더에 넣으시면 되고요.
mybatisConfig.xml 부분의 <mappers></mappers>부분 삭제
JDBC .jar파일 설정 할 것.

  • Mybatis 사용방법 3가지.
XML 만 사용하는 방식 = ibatis 방식
인터페이스의 Annotation 방식 = Mybatis 방식
두 가지를 혼용하는 방법. <- 강사님이 선호하는 방식.
 
TimeTest.java
SqlSessionFactoryBuilder ()
// 오늘은 Mybatis를 활용해서 오늘 날짜를 가져와 볼 거에요.
Mybatis는 단점이 하나 있죠. Mapper 파일이 없으면 동작을 할 수 없습니다. 넣어주고 시작.
Src -> 패키지 생성 -> new -> others -> xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
<mapper namespace="org.thinker.time.TimeMapper">
<select id = "getTime">
select sysdate from dual
</select>
</mapper>
설정파일이 로딩 될 때, xml파일이 로딩되도록 해야 해요.
사용자 가이드를 보면,
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
여기에서 resultType="Blog"는 무엇일까?
package org.mybatis.example;
public interface BlogMapper {
@Select("SELECT * FROM blog WHERE id = #{id}")
Blog selectBlog(int id);
}
하지만, 여기에서 TimeMapper.xml 파일에 문제가 생기면 모든게 안돌아가는 사태가 발생해요.
때문에 Mybatis에서는 초미세 작업단위로 접근하는게 필요해요.
 
// 숙제: Mybatis안에 if, for루프, 다이나믹 SQL에 대해 조사해 올 것.
스프링, ajax, 자바스크립트.
XML 방식을 쓰면, 파라미터 타입, 리턴 타입을 결정해줘야한다. Annotation 방식을 쓰면, 그런 불편한 점이 없어지죠.
간단한 쿼리문은 Annotation 방식이 편하고 복잡한 건, XML방식이 더 편하다.
두 가지 같이 쓸 수 있으면 Best
! XML에 있는 namespace값과 인터페이스의 패키지 명이랑 풀네임이 같으면 resource로 주지 않아도 먹힌다 !
Primary key와 VO는 제네릭을 사용할 수 있지 않을까요? 이렇게 해서 한 번 지정해서 쓸 수 있도록 하면, 공통적으로 전부 써먹을 수 있지 않을까요? XML 기준으로
Static block 이라는 걸로 try ~ with 구분을 넣어준다. Static block은 한 번만 불러온다.
게시판과 회원을 만들 때, 달라지는 것은 Mapper이름뿐이 아닐까요? 생성자로 Mapper 이름 받아오게.
이거 만들어 쓰는게 오늘의 키포인트. 여기까지 하면 제네릭 DAO를 만들어 낼 수 있겠죠.
그럼 제네릭 컨트롤러나 서비스를 만드는게 가능할 까요?
중요한 건 매뉴얼에 있는 내용이 아니라 Mybatis 블로그에 있는 내용이 중요.
// 팀별로 제네릭 DAO를 세팅하고 사용하는 방법을 익히실 것.
 
 
 
 
Java 자바 프로그래밍: Spring, CRUD

 
화면에 다 뿌릴 필요가 있었을까. 오라클을 이용하면 그럴 필요가 없었겠죠. 제로보드라고 하죠.
URL 페이지 번호에 음수를 넣으면 쿼리문이 다 나오는 에러가 발생.
쿼리문 날리는 부분에서 좀 더 보완을 할 수 있어요.
한 페이지에 10개, 10페이지 출력 (100개의 게시물 찾는 쿼리문)
101개의 게시물이 있으면 ">>" 다음 페이지 리스트 출력.
 
select
 rn, bbsno, title, writer, regdate, cnt
from
(
select /*+INDEX_DESC(tbl_mp3, pk_mp3) */
 bbsno, title, writer, regdate,
 count(bbsno) over()
from tbl_bbs
where bbsno > 0
and rownum <= (CEIL((page / 10))*100)+1)
)
rn> ((2-1)*10) and rn <=(2*10);
Count() over() 의 사용. 내부에서 집합함수 다시 사용한 것.
원글 데이터 뿐만 아니라 게시글에 필요한 숫자까지 한 번에 가져온 것.
내부적으로 Count (StopKey)가 들어가기 때문에 숫자 세는 것까지 들어간다.
요즘 나오는 게시판들은 맨 마지막으로 가는 버튼을 사용하지 않는다. (느려지기 때문에)
VO에 항목이 새로 생기면, VO를 새로 만들지 않고, 상속을 사용해서 추가하는 방법이 있다.
데이터 베이스에서 속도가 느려지는 부분은 검색이에요.
 
보니까 페이지 번호를 무는 게 어려운 경우가 많은 것 같아요.
일단은, 현재페이지(2)가 필요해요.
카운트(101)
라인 디스플레이(10)
페이지당 사이즈(게시물의 개수) (10)
위의 쿼리문에서 100+1 부분은
라인 디스플레이 * 페이지당 사이즈
 
-- 강사님 코딩 부분
PageMaker 유틸부터 제작. 변수 선언하고, 생성자 작성. 생성자를 오버로딩으로 3가지 경우를 작성. 파라미터 0~2개인 경우. Getter, setter, toString. 제작. 생성자 호출하기 전에는 다른걸 호출하지 못한다. 문자열 던져서 숫자로 바꾸어주는 static 메소드 선언.
 
서블릿-> Controller 생성.
 
<필기그림1>

 
<ul>과 <li> 태그 사용해서 리스트 .jsp파일에서 작성. 최대한 UI는 바보스럽게 코딩 해줘야 해.
Hasnext와 hasprev를 계속 만들어 내는 이유는 같은 리스트에서 계속 쓰기 위해서.
 
이번 시간에 했던 부분.
  • 가능하면, 테이블 스캔을 어려 번 쓰지 마라.
  • 자바의 객체를 써먹어라. UI를 최대한 바보스럽게 코딩해라. 
 
검색어를 입력해서 검색을 했을 때, 여러 페이지가 나올 수 있다. 이  때, 페이지 전환은 검색 조건을 유지한 상태로 넘어가야 하는 문제가 발생한다. 이 때는, <a> 태그의 링크가 엄청 복잡해 질 수 밖에 없다. 때문에 검색조건 필터링을 하는 사이트(예. 다나와)에서는 이를 컨트롤하는 것이 어려울 수 있다.

 
재사용하기도 어렵고 허접한 인터넷에 돌아다니는 게시판 소스말고. 이런거에 익숙해지라는 거에요.
전부 이해하지 못해도 괜찮아요. 번호를 클릭하면, hidden값만 바꾸고 submit을 날려버려.
<a href = 'javascript:_goPage(1)'>1</a>
자바스크립트를 만들고 Function의 _goPage() 생성. 값 전달.
모든 링크가 _goPage()로 만들고 _goPage()부분만 오버라이드 하면 된다.
PageMaker가 검색조건을 다 물고 있으면 페이지 구분 부터, 검색어 무는 것 까지 전부 처리가능.
이렇게 만들어진 소스는 include를 사용하면 재사용성이 증가한다.
PageMaker가 VO다. List 출력. 검색조건을 파라미터로 받아들인다면
게시판에서는 CRUD List가 전부야.
검색기준 Criteria를 가지는 객체생성.
Generic_DAO 생성.
CRUD에 List추가 - Public List <E> list(Criteria cri) throws Exception;
동작하는 기능을 파라미터로 던져줄 수 없으니까. 어쩔 수 없이 람다식이 나올 수 밖에 없는 것.
3단 구현: Interface -> 추상클래스 -> 구현
인터페이스마다 따로 구현해야하는 문제점에 직면한다. 이 문제를 자바에서는 해결할 수 없어요.
SQL Executor를 매번 바꿔야 할 문제. 해결할 수 있는 방안 -> My batis
이런 좋은 기능들은 여러 번 반복 작업을 해봐야 얼마나 좋은지 알게 된다.
My batis 는 한국에서만 열심히 사용 ㅠ ㅠ (전자정부 프레임워크)
쿼리문이 전부 XML로 빠지고 여기에서 값을 준다.
적당한 SQL과 적당한 파라미터만 던져주면 파라미터 세팅해주고 Resultset도 해결해준다.
파라미터를 자동으로 세팅해주고 결과데이터를 자동으로 처리해주는 녀석이 있다면, 우리는 게시판을 좀 더 쉽게 만들 수 있지 않을까. 목표를 DAO에 코딩을 넣지 않는 것. 무배포. 무코딩. 무설정.
원래 mybatis는 Spring하고 같이 써요.
// 일단 오늘 한 코드가 어떻게 돌아갔는지. 
// 우리 팀이 왜 결과가 안 나왔는지 분석 할 것. 다음에 만들면 어떻게 빨리 만들 것인가. 내가 뭘 할 것인가. 
 
2016-11-16 IS Impact 세미나 - 연세대학교 정보대학원 수업내용

포렌식 관련
 - 절차, 기술, 법률, 도메인
 
Measuring User Participation, User Involvement, and User Attitude, Barki, Henri, and Hartwick, Jon, MIS Quarterly, 18(1), June 1994, pp. 59-82.
 - 연구 방법에도 관심을 가졌으면 함. UTAUT까지 이어지는 TAM과 관련. 주제의 선정. 연구 방법 같은걸 응용할 수 있는 길이 참 많음.
  - User involvement. 이걸 동안 behavior/participation(action행동)이랑 혼용해서 사용해오곤 했다. 그런데 나는 이걸 importance and personal relevance(psychological state 믿음)로 보겠다. Attitude는 좋다/싫다에 대한 것.
  - 브랜드 충성도와 애착 굉장히 비슷해보임. 다른 것인가.
 - measurement를 만드는 건, 정말 full scale로 다 검토해보아야 함. 모든 validity 다 Test해줘야함. 새로운 변수랑 메트릭스를 제기하는 것도 좋은 논문이 될 수 있음. 
 
User Acceptance of Computer Technology: A Comparison of Two Theoretical Models,Davis, F. D., Bagozzi, R. P., and Warshaw, P. R., Management Science, 35(8), 982-1003, 1989
 - TAM가지고만 여러개 논문 냈음. 박사학위논문. TRA의 이론적 배경을 가지고 만든 것이 TAM. 실제적으로 IT분야에 적용되었을 때 어떤 부분이 더 우월한지를 보여주는 논문.
 - TRA (Theory of reasoned action) Fishbein and Ajzen (1975) 사람들의 의도를 이해하려고 만들어진 이론. BI (Behavioral Intention)  = A (Attitude) + SN (Subjective Norm)
 - 이런 논문의 특징을 catch하는게 중요. 개의 연구 방법을 비교하는 연구하는 방법.
 -

 
E.g. 시위를 예를 들었을 때 어떨지 생각해볼 것. 23분 13초
Beliefs and Evaluations -
Attitude Toward Behavior
Behavioral Intention
Actual Behavior
Subjective Norm
Normative Beliefs and Motivation to comply
 

Subjective Norm을 왜 뺐는지. 기업의 시스템을 쓰느냐 안쓰느냐에 대한 것에 있어서는 Subjective Norm이 상관없지 않을까. 다른 사람들이 다 쓰니까 나도 써야 하지 않을까 하는 압박이 회사에서는 어차피 도입되면 내가 반드시 써야 하는 것이기 때문에 상관 없다고 생각해서 뺐던 것일듯.
External Variables에 어떤게 들어갈까. Technology 자체의 Characteristic. Personal Characteristic. 네이트온을 사내 메신져로 쓰기로 한 Organization의 Characteristic. 이러한 External Variable을 찾으려고 모든 새로운 Technology 분야에서 사용되었음.
TAM을 쓰는데, Intention을 아예 안쓰는 경우가 많음. Actual Use와의 관계는 많이 나왔음. 다만, 아예 Actual Use를 하지 않았던 사용자들 대상으로 한 연구에서는 intention까지만 측정하기도 함. E.g., Wearable Device 사용 의도에 관한 연구.
 
Extending the Understanding of End User Information Systems Satisfaction Formation: An Equitable Needs Fulfillment Model Approach, N. Au, E. W. T. Ngai, and T. C. E. Cheng, MISQ Vol. 32, No. 1, pp. 43-66.
 - System Use End User Satisfaction 종속변수였음. 사람들이 End User 만족해서 쓰고 있다는 선행 변수들에 대한 연구는 중구난방으로 있었음. 이걸 정리했음. 사람들이 시스템에 만족을 하는 이유중에 이론적 배경을 가진 독립변수들을 추출해서 내놓게 된 논문임. 이론적 베이스가 여러개임. 가져온 이론에서 일부만 써도 상관없음. 왜 그렇게 썼는지만 잘 설명할 수만 있으면 된다. 타분야에서 쓰던 이론을 가져오는 것도 신선한 접근방법이 될 수 있음.
 - ( 제 관련) System Use 통합할 있는 정량적인 데이터를 수집할 수 있는 오픈소스 아키텍처가 없었다. System Use를 정량적으로 측정할 수 있는 방법론을 제시해볼까.
 - Expectancy Theory and Satisfaction
 - Equity Theory and Satisfaction
 - Needs Theory and Satisfaction
 - Formative Value 있어서 PLS 사용.
 - Formative는 부 e.g. 집합의 핵심 개념 3개 중 1개에 대한 20개의 문제. (대표성을 띄는 질문)
 - Reflective 필요충분. MECE e.g., 집합의 개념 3개에 대한 20개의 질문. MECE 질문.
 - Varience Measure Reflective? (녹취 확인 필요)
 - Process Measure
 
모든 Measurement 10년전에는 Reflective measure 썼었음. 갑론을박중임.
 
 Q & A. TAM 변수들을 추가한다. Self-developed.
 
 
 
 

+ Recent posts