초청 특강 Recommendation Systems : Concepts, Techniques, and Research Results
키워드 : 추천 시스템, 머신러닝
소개 : 최근 온라인 비즈니스에서 크게 각광을 받고 있는 추천 시스템 기술에 대해서 다룹니다. 먼저, 추천 시스템의 기본 개념, 최신 기술, 응용에 대해서 설명하고, 머신 러닝 기술을 이용하여 추천 시스템을 어떻게 실현하는가에 대해서 설명합니다. 또한, 최근 제안된 무관심 아이템이라는 새로운 개념을 제시하고, 이 개념을 통하여 기존 추천 시스템의 정확도가 어떻게 개선 되는가에 대해서 다양한 관점에서 논의합니다. 또한, 추천 시스템에서 다루는 그래프 데이터를 효과적으로 저장하는 새로운 그래프 엔진 RealGraph를 소개하고, 이를 통하여 추천 시스템의 성능을 크게 개선시킬 수 있음을 설명합니다.
추천 시스템은 예전 데이터가 많은 업체만 하던 것을 작은 업체들도 시도하고 있음.
추천 기술은 몇가지 기반 기술이 있음
Content-based filtering은 내 데이터만 봄
Trust-based 는 트러스트라는 관계 데이터가 필요함. 주변인 추천 같은?
Collaborative filtering (CF)는 나와 취향이 비슷한 이웃을 찾고 내가 모르는 아이템을 얼마나 좋아하는지 예측함. Rating Matrix 사용
1단계 취향유사도 계산은 Pearson Correlation Coefficient based Collaborative Filtering(PCC) 사용
2단계 내가 얼마나 좋아할지는 Heuristic based methods 사용
일반 평균, 유사도에 따른 가중치를 주거나 각 이웃의 평균치도 고려함
위 단계가 Matrix Factorization, Tensor Factorization 이며 점차 딥러닝으로 넘어가는 중
Social network analysis, Deep Learning 등
정확도를 높이기 위해 Unrating 개념 추가
Unrating은 존재를 모르거나 알고도 관심이 없는 경우도 있음(부정적인)
기존 선호도로 쓰이던 부분을 사전/사후 선호도를 나눔.
Uninteresting item 찾는게 과제임.
기존 사용자가 좋아하는 것만 추천했지만 한양대에서는 싫어하는 것까지 고려하려 함.
작은 Interesting 그룹과 큰 Uninteresting 그룹이 필요함
깃'깔나는 Git 워크플로 알아보기
키워드 : 개발 방법론, 생산성
소개 : 주요 Git 워크 플로우의 이해 각자 상황에 적합한 Git 워크플로를 찾는 팁
Git flow
메인브랜치 : master, develop (master에 버전 태그 추가)
서포팅브랜치 : feature, release, hotfix (필요시 생성/제거)
hotfix는 마스터에서 브랜치 생성
Github flow
master 브랜치는 항상 배포 가능한 상태 유지
topic 브랜치 (Git flow의 feature) 는 기능 설명이 명확하게 작명하고 merge시 pull request 사용
topic 브랜치는 CI 빌드 통과해야 함.
배포는 merge 순간 bot을 통해 진행함.
매우 빈번하게 배포함.
Gitlab flow
Git flow는 너무 복잡, Github flow는 너무 간단하게 생각되어 나옴.
Gitlab flow - 지속적인 배포가 어려울때
master에서 production 브랜치로 머지 후 배포
Gitlab flow - 환경별 배포시
Gitlab flow - 릴리즈 소프트웨어시
Commit과 Push는 자주 할것
Merge Request or Pull Request 는 완료 전이라도 논의 및 피드백 받을 목적으로도 사용.
merge 전엔 테스트 필요
NHN Edu사례
단기간,
장기간 배포 일정(코드네임 부여)
rebase 로 정리함.
QA 수정사항은 각 프로잭트 브랜치에서 추가함.
Release 브랜치 사용안함.
배포 후 각 프로젝트 브랜치에 rebase
각 프로젝트 rebase시 conflict이 발생할 수 있고, 그 경우가 복잡할 경우 프로젝트 브랜치 재생성하고 cherry-pick 함.
hotfix 는 Pull Request 로 코드 리뷰와 테스트만 하고 배포는 직접 진행함.
업무프로세스
Pull Request 시 사내 메신저 연동
Pull Request 통과 조건을 부여하여 통과시만 merge 가능(github 설정)
- 코드 리뷰 승인시 조건
- 테스트 옵션 – Unit Test와 Sonarqube
(Sonarqube 는 테스트 결과와 별개로 패스되므로 참고만 함.)
- develop에 최신 master 적용여부 체크
Pull Request 생성시 Jenkins 빌드 및 Unit Test연동
Sonarqube 결과도 댓글로 달림
Github Pull Request + Jenkins + Sonarqube
실용적인 프런트엔드 테스트 전략
키워드 : 프런트엔드, 테스트, 아키텍처
소개 : 프런트엔드 코드는 사용자 환경과 밀접하게 연결되어 있고 복잡한 시각적 요소를 다루기 때문에 테스트를 자동화하기가 어렵습니다. 본 세션에서는 수년간 다양한 방식으로 테스트를 작성해 온 경험을 공유하며, 최신 테스트 도구를 사용해서 실용적으로 프런트엔드 코드를 테스트하는 방법을 설명합니다.
테스트는 왜 하는가?
대부분 개발자가 테스트 코드 작성 후 자동화함
그 이유는 Confidence 때문임.
백엔드의 경우 테스트는 https 요청에 대한 응답이 대부분.
프런트엔드는 마우스 키보드 등 입력과 시각적 정보 출력하고 코드로 확인하기 어려움.
입력 : DOM Event, Routing IO
출력 : Html, css 비교 등
결과 확인
\1. Html 비교
\2. 스냅샷 테스트 : 에전 테스트 결과와 파일 비교. Jest 사용
하지만 html 확인만으로는 테스트 결과에 신뢰를 줄 수 없음
구현상세테스트 vs 동작테스트로 테스트 성향을 구분.
위의 결과 확인은 구현상세테스트 성향임.
동작테스트로시각적 회귀 테스트진행함. (회귀란 기존 버전과 비교하기 떄문)
하지만 픽셀 단위 비교도 브라우저 렌더링 등에 영향을 받음
그리고 커맨드 라인에서 테스트 결과 확인이 어려움.
테스트 실행 단위별 이미지 파일 히스토리 관리 필요.
결정적으로 시각적 테스트 전문 도구(유료)
Applitools, Percy, Chromatic
시각적 테스트는 속도 문제와 테스트의 장점 중 하나인 문서화 기능을 처리하기 어려움
이로 인해 TDD 진행도 어려움.
그리고 단일 테스트에 영향 주는 요소 많음.
시각적 테스트 vs 기능적 테스트
기능 테스트시 시각적 요소 의존성 제거해야 함
JQuery의 Selector들 같은 경우가 이에 속하며, 이를 제거하기 위해 data 속성을 이용해 test-id 등을 부여할 수 있음.
build.gradle 이나 gradle-wrapper.properties 파일 내 버전을 한쪽에 맞춰서 수정
4. 최소 gradle 버전에 적합한데도 발생한 경우
예전에 직접 gradle 쪽 초기화를 하고 싶어 직접 gradle 경로에서 파일들을 삭제 하던 중 폴더만 남고 삭제가 안된 경우가 있었음. 그로 인해 gradle 있지만 동작 안하는 것으로 감지한 듯함.직접 gradle zip 파일을 받아서 해당 경로에 풀어 주고 다시 gradle sync