카카오 개발자 컨퍼런스 후기

늦은 후기이지만 기록은 해놓고 공유를 하진 않아서 기록해둔 자료를 기록하기위해 남깁니다.

전체적인 카카오 데브 컨퍼런스의 느낌은...

세션이 워낙 다양해서 모두가 그런건 아닐테지만  

개발적인 코드 이야기가 조금 부족하고, 설명이 딥하진 않아서 아쉬웠습니다.

다음번 컨퍼런스가 열릴땐 좀 더 깊이있고 코드도 난무(?) 하는 다양한 해결 경험담 또는

적용해본 내용을 다뤘으면 좋겠다는 생각을 하게되었습니다.

다음 모바일 첫 화면 개선기

다음 모바일 첫 화면 의문

아직도 다음 많이 쓰나요?

-> 많이 쓴다

컨텐츠가 많이 바뀌었다

수량, 퀄리티, 보여지는 전반적인 부분에 대해서 개선이 이루어짐.

이로인해 더 높은지표가 생겼다.(유저 증가)

개선전에는 거의 성장지표가 평평했다 하지만 개선 후 꾸준히 증가추세.

포털이란?

수많은 사이트를 특정한 분류에 따라 정리해 놓고 찾아갈 수 있도록 만든 사이트

유저들이 필요로 하는 컨텐츠가 가장 기본이고 본질적인 문제로 중요하다

수집 > 분류 > 선정 > 노출

4가지 과정을 거친다.

콘텐츠 수집

과거 : 수집 관리 시스템 + Human Power

• 초기에는 컨텐츠 URL과 내용을 수집했다.

• 인력이 많이 필요했었음

• 하루 1~2천개 가량의 콘텐츠 수집

• 에디터들이 일일이 수집

• 미 수집된 콘텐츠 존재

• 수집의 불편함이 존재

• 크롬 extension 수집툴로 보완

개선 후 : 시스템을 통한 모든 서비스 컨텐츠 수집

• 전사 콘텐츠를 모으는 콘텐츠 큐 구축

• 여러 외부 커뮤니티 콘텐츠 수급

• 하루 2~5만 콘텐츠 실시간 수급

개선 후 : 더 많은 콘텐츠가 주는 효과

• 더 많은 콘텐츠 노출과 더 많은 클릭이 이루어짐.

• 자연스럽게 유저수도 증가

콘텐츠 분류

과거 - Human Power

• 사람이 일일이 분류

• 비 일관적인 분류

• 오랜시간 소요

• 컨텐츠를 모두다 읽고난 후 컨텐츠를 분류 했기때문.

개선 후 : 이제는 사람이 할 수 없다!?

• 하루기준 약 4만건의 컨텐츠가 쌓임.

• 얼마나 많은 인력과 시간이 소요될까?

• Machine Learning 자동 분류 시스템 사용 도입

• 

• 
  

• 수집되는 동시에 콘텐츠 뷴류 0.01초

• 사내 AI 조직의 콘텐츠 분류 API 사용

• 자체 학습셋 구축

• 자체 분류 알고리즘 적용

• 앙상블하고, 유연한 분류 시스템

콘텐츠 설정

과거 : Human Power

• 직접 선택

• 노출 이미지, 타이틀 편집

개선 후 : 추천 알고리즘 + Human Power

• 아직도 일부 영역은 Human Power에 의존을 하고 있는 상태 ...

• 하지만 트렌트가 바뀌었고 이제는 추천이다!

• 콘텐츠의 분류, 출처, 태그, 타입등을 특정 조건으로 각각 필터링

• 특정 주제별 콘텐츠 묶음을 구성

• 그리고 추천에 필요한 학습셋으로 활용

콘텐츠 노출

과거 : 서버 렌더링 이용

• 개인별 추천 적용 이전

• 모두 똑같은 화면

• 대규모 트래픽에 적합

• 고성능 시스템

• 장애에 강함

• 

개선 후 : 추천 API를 사용하면서 겪었던 문제

• 사용자의 요청이 있으면 추천

• 

• 

• 

• 서킷브레이커 패턴 적용 결과

• 평소보다 두세배 정도 많은 트래픽이 발생했으나 이전보다 안정적으로 서비스가 되었다.

• 

노출 관리, 품질 관리도 해줘야한다.

• 노출 이력관리

• 데드 링크 관리 (링크가 열리지 않는 링크는 리스트에서 자동으로 알림이 오거나 제외시키는 시스템 구축함)

• 이미지 크기 관리

앞으로는?

• 콘텐츠의 개선을 가지고 많은 시도를 할 수 있다.

• 더 많은 시도 예정

• 다양한 콘텐츠를 쉽게 발견하고, 서비스를 함에 있어서도 독자적인 콘텐츠 플랫폼을 활용해서 많은 좋은 반응을 얻었고 콘텐츠 기반으로한 많은 것들을 시도해볼 예정이다.

7년동안 무중단 무점검

중단없이 수만은 서비스 추가 및 운영이 이루어져왔다.

코틀린 서버 도입 배경

도입을 고민할 때 할 만한 걱정들

“코틀린은 언어만 익히면, 프레임웍에 대한 러닝커브가 없는게 장점이라고 생각한다.”

코틀린 데이터 타입

자바와 코틀린 비교

• 코드라인은 확연히 줄었다.

• 바이트코드 사이즈는 조금 늘었는데 인라인 함수와, 바이트코드 변환 되는 내용 때문인것으로 보인다.

• 컴파일 시간은 확연히 늘어났는데, 체감될 정도는 아니라 무시해도 될 수준인것 같다.

 

이하 자세한 내용은 생략하였습니다. (이유)

• 내용을 다 집중력있게 들었으나, 전체적으로 코틀린 책 1~2장에 나올법한 기본적인 내용

• 데이터 타입은 무엇이고, 코틀린 역사, data class 사용법 등등..

순서

- 개발 - 오픈 - 운영까지 시간 순으로 설명
- 각 시간 시점의 주요 이벤트 별 비하인트 스토리
- 질문 예측 자답 시스템

대략 구성도

2016.05.01 우리가 은행앱을 만든다고?

• 안드로이드 1명, 아이폰 1명, 디자명 1명 서로 모여 앉아...

• 은행을 만든다고 해서 오긴왔는데 ..

• 실감 나지 않고 불안했던 시기

 

 

 

 

2016.06.01

이체 - 계좌조회 - 예금 - 적금 - 대출 - 외환

정도만 생각 했음.

• 코드량을 줄 일 수 있다고 판단되어 오픈소스 라이브러리 적극적으로 도입했음. (검증된 내용만)

• 보안적으로 강화하기위해 여러업체를 선정하고 미팅도 자주 했다.

카카오뱅크에서 사용하고 있는 보안 솔루션은?

• 백신은 안넣으려고 했는데 결국은 넣게되더라 ..

• 공인인증서를 애초에 넣지 않는걸로 생각했다. 공인인증서를 넣을거면 모일필요가 없었다.

개좌 개설 프로세스는 아래와 같았다.

• 생각보다 길 줄알았는데 생각보다 괜찮네? 라는 반응이 있었음.

개발적으로 중요한 결정

좌충우돌 험난한 시련

• 까도까도 할 거리가 계속나온다.

• 처음에 생각했던 전체적인 할거리 리스트는 아래와 같다.

• 

• 이정도면 될줄 알았는데

• 할 일이 끝도 없이 많다.

• 안드로이드 , iOS 두벌로 하니 싱크맞추는것과 개발자체가 쉽지 않았다.

• 왜 하이브리드 하지 않고 네이티브로 했느냐라는 말을 엄청 많이 들었다.

 

 

 

 

 

왜 네이티브로 했는지?

네이티브 앱의 단점

“은행앱이 자주 바뀌는 이유는 하나의 UX로 커버하려고 하기때문에 더 유지보수 비용이 들지 않을까?”

은행의 입장이 아닌 고객의 입장에서 앱을 만들기로 결정하고 진행

아무도 가보지 않은 길이기 때문에 하이브리드로 왜 안하냐는 말들이 많았다.

 

 

 

은행이 되기 위한 최종 심사

• 시연을 할때 실제로 모니터로 보여줬었다.

2017. 04. 05 본인가 승인 (이제 은행영업을 시작할 수 있다.)

2017. 05. 25 클로즈베타 오픈

2017. 07. 27 출시

이후에는 글 작성중에 데이터가 날아가버리는 바람에 스크린샷만 첨부합니다 ㅠ

느낀점

코드는 한줄도 나오지 않아서 아쉬운 부분이 있었습니다.

카카오뱅크의 서비스를 처음 시작부터 끝까지 들을 수 있는 기회였어서 서비스적인 측면에서는 좋았습니다.

그리고 기억에 남는 부분은 카카오뱅크 개발팀의 배포 철칙이었는데

• 3명이상 코드리뷰를 받지 않으면(통과하지 않으면) 배포 불가

• 테스트 자동화 (에스프레소 도입) UI 테스트가 자동으로 되는데 신기 했습니다.

• 단위테스트 구축

위와 같은 개발 방법으로 커다란 이슈 없이 안정적인 서비스를 운영할 수 있었다고 합니다.

코드리뷰와 테스트에 대해서 중요함을 한번더 느낄 수 있는 자리였습니다.

2.0 UX 업데이트 이후 많은 좋은 피드백을 받았다. 웹툰 2.0, 2.1 UX 개편은 어떻게 했는지 설명해드리겠다.

그럼 어떻게 만들었을까?

• 이 모든 것은 디자이너와 협업해서 만들었다.

• 이걸 만들기위해서 디자이너의 애니메이션을 넣기위한 디자인이 필요

• 애니메이션 각각의 섬세한 시간, 타임에 대한 조언 필요

협업시 가장 중요한것

• 동일한 UX컨셉을 가는것

• Creative : 좀더 다른것을 만들어야 한다

• Natural : 자연스러워한다.

• Focusing : 시선 분산이 되지 않고 한곳으로 집중되어야 한다.

• Meaningful : 디자인에 대한 의미가 있어야 한다.

Work Process : 디자이너와 일하는 방식

• 디자인 프로토 타이핑

• ㄴ 디자이너가 본인이 원하는 디자인을 가지고 와서 온다.

• 디자인 검토

• ㄴ 디자인 검토, 개발 검토

• 개발 프로토 타이핑

• 리뷰

그리고 나선 위에 일련의 작업을 다시 반복한다. (단 한번에 된 적이 없기때문)

언제까지? > 디자이너와 개발자가 만족할때 까지

 

Splash

• 스플래시 시간동안 서버작업을 진행

• 

• 

코드 내용

Symbolic Icon

ViewPager이동마다 왼쪽상단에 바뀌는 이미지구현

위의 내용을 코드로 구현하면?

(생각보다 복잡하다)

개발 프로토타입을 만들었는데 뭔가 부자연스럽다

=> 다시 토론

디자이너와 개발자가 만족할때까지 반복 또 반복한다.

 

 

 

List Animation

ISSUE

• 스크롤시 애니메이션이 제대로 다 먹지 않는다

해결방법

리스트뷰 애니메이션 내용은 기존에 DefaultItemAnimator를 커스텀해서 구현완료

 

 

Title Page

웹툰 리스트를 클릭 했을 때, 나오는 타이틀 페이지 구현

한가지 떠오르는 예상 해결방안 > ActivityTransition SharedElement를 쓰면되지 않을까?

하지만 아래와 같은 이슈가 3가지가 있어 사용불가.

Issue1 : SharedElement로 사용되는 이미지 로드가 느림
Issue2 : getLocationInWindow() 값이 StatusBar Height 만큼 어긋남
Issue3 : ChangeBounds가 오동작하여 이미지 Scale이 어긋남

그럼 어떻게 해결했는가?

안되면 커스텀한다.

 

 

 

 

 

 

추가 요청건) 디자이너분이 Curve Animation을 넣어달라고 한다

커브드 애니메이션은 생각보다 간단(?)하다 위처럼 하면 끝!

 

추가로 마음에 안들어서 추가 했던 부분 )

만화 보기를 눌렀는데 데이터를 다 못가져온 상태라면 통신이 완료될때까지

화면을 그리는데 약간의 딜레이가 발생

 

 

해결방안 ) Ripple Effect를 넣어서 상단에서 시선을 끌자

Ripple 효과는 물방울이 떨어지는 느낌으로 통신하는 시간동안 추가로 상단 이미지에 적용하여

사용자가 기다리는 느낌을 덜 받을 수 있게 시선을 분산함.

BackPressed (뒤로가기) 버튼을 눌렀을 때, 다시 원래상태로

돌아오는데 애니메이션이 없으니 뭔가 부자연스럽다.

원래 만화내용을 볼때처럼 자연스러운 애니메이션을 넣으면 어떨까?

 

Issue 1

TitlePage Activity Start 사용시

• Image onPreDraw 시간만큼 딜레이 존재

Solution1

• EnterTranstion을 Main에서 처리 (lifecycle 활용) 아키텍쳐 라이프사이클

• 

Issue 2

• MainActivity로 돌아갔을때 Cross Fade 느낌이 없음

Solution 2

• ActivityTransition Fade 사용하기로 함

정리

• Creative : 좀더 다른것을 만들어야 한다 > Splash

• Natural : 자연스러워한다. > Symbolic Icon

• Focusing : 시선 분산이 되지 않고 한 곳으로 집중 되어아 한다. > Ripple, List

• Meaningful : 디자인에 대한 의미가 있어야 한다. > All

느낀점

• 뭐든지 만만한 작업은 없겠구나

• 서비스 하나를 제대로 만드려면 끝없는 (될때까지) 노력이 필요하다.

• 애니메이션을 딥하게 사용하면 저렇게까지 응용이 가능하다

• 디자이너와 개발자와의 협업은 정말 중요하다

• Fabric 기준 크래시 Free 유저가 99.8%라고 한다. 많은 사용자들이 사용하는 앱은 안정성을 확보하기 위해 끊임없는 테스트 필요

• 개발 > 디자이너+개발자 테스트 1주 > 전문 QA팀에서 테스트 1주 > 배포 과정을 거친다고함. 또 한번 테스트의 중요성을 느낄 수 있었음.