Microsoft Azure Everywhere

코엑스에서 Microsoft Azure 컨퍼런스가 열려 오전 세션만 듣고 옴.

개요

• 행사명 : Azure Everywhere The 1st Wave

• URL : http://www.microsoftazuresummit.com

• 기조연설 동영상 : https://www.facebook.com/MicrosoftKorea/videos/291811018145452/

• 일정 : 2019년 01월 11일(금) 08:30 - 17:30

• 장소 : Coex GrandBallroom

• 세션 :

  Time	Session
  08:30 - 09:30	Registration & Booth tour
  09:30 - 09:50	Microsoft Azure 오늘, 그리고 미래 한국마이크로소프트, 최주열 이사
  09:50 - 10:30	개발자 중심의 클라우드 플랫폼 응용과 진화의 방향 Git Hub, Paul St. John, WW VP
  10:30 - 11:00	1% + 99% = AI 대중화 Databricks, Jason Bissell, GM
  11:00 - 11:30	클라우드 중심의 Digital Transformation 여정 Johnson Controls, Youngchoon Park, VP
  11:30 - 12:00	글로벌 기업들이 이야기 하는 Panel Discussion

현장

기타

01. Microsoft Azure 오늘, 그리고 미래

• 발표자 : 최주열 이사 (한국마이크로소프트)

오픈소스 + 클라우드

Digital Transformation

Digital Transformation을 위해서는 인적 자원, 고객, 제품, 운영 피드백들이 필요.

Data - intelligence - Action

수 많은 기술 중 최선/차선/차악/최악 등을 찾아 개선하려 함.

Microsoft Azure가 이를 도울 수 있음.

Productive - Hybrid - Intelligent - Trusted

Productive

Azure regions는 54 곳으로 글로벌하게 서비스 중

한국은 중부(서울)과 남부(부산)으로 있음. (https://azure.microsoft.com/ko-kr/global-infrastructure/locations/)

개발자를 위한 통합된 도구를 제공하며,

120개 이상의 다양한 서비스를 제공하며,

단일화된 관리 환경을 제공함.

MS는 developer developer를 강조하며 폐쇄적이던 스티브 발머 사장 시절과 달라졌음.

2014년부터 MS love linux 를 시작으로 VS Code, Github 등을 제공하며 필요한 서비스를 대중화하려 함.

기술이 우선이 아니라 필요한 것들을 끌어내기 위함임.

MS의 이 모든 생각이 집약된 것이 Azure

현재는 Azure의 3~4개의 서비스로 간단히 비즈니스를 형상화할 수 있음.

고성능 컴퓨팅 환경도 지원함.

기존 단순한 Data와 Application의 연결이 아니라 연결된 Intelligent Edge를 연결하는 것이 될 것.


AI 관련해서는 이미 학습된 모델들이 Azure에 올라가 있음. (사용자가 처음부터 학습시킬 필요 없음)

데이터의 양보다는 데이터의 모호함 등이 문제이며 이를 시각화 등으로 지원함.

Azure는 사용자의 요구를 받아들여 반영 개선하려 함.

02. 개발자 중심의 클라우드 플랫폼 응용과 진화의 방향

• 발표자 : Paul St. John (Git Hub), WW VP

깃헙의 시작은 협업을 위한 툴 / 허브 / 개발자 커뮤니티.

깃헙에서는 혁신에 대한 고민 중.

예전 주요 회사들은 현재는 많이 도태된 경우가 많음.

현재 주요 회사들은 S/W 기업들이 주가 되며, S/W회사라고 해야 투자자들도 투자하기를 좋아함.

금융 기업들도 Cloud를 많이 쓰는 추세임.

자동차 제조사들도 S/W가 중요해지고 Walmart의 경우도 아마존을 따라가기 위해 실리콘 밸리에 랩을 차리고 혁신 중.

결국 개발자들이 혁신의 중심이 되가고 있음.

그래서 MS는 개발자에 대한 지원 등을 중요하게 생각함.

개발자들이 업무 중 코딩하는 것은 48% 정도라고 함.

회의, 문제 해결, work flow로 인한 대기 등으로 효율성이 떨어짐.

Innovation (Speed) <--------> Reliability (Controll)

개발자들이 운영에서 벗어나면 혁신에 치중해 새로운 것들을 만들수가 있음.

하지만 컨트롤이 쉽지 않음.

기업에서는 저 두 개념 사이에서 밸런스를 잡기 어려워 함.

깃헙이 이를 해결하기 위해 도와준다고 함.

주로 깃헙은 개발자들이 배우러 들어오는 경우가 많음.

그러면서 협업자도 찾을 수 있고, 창의력 넘치는 방법들도 찾게 됨.

현대 S/W 개발에서는 오픈소스가 필수임.

MS도 예전에는 오픈소스를 비웃었지만, 당시에도 확실한 위협이었음.

오픈 소스는 실제 프로젝트에 많이 사용되고, 깃헙에 가장 많이 있음.

InnerSource

기업에서 소스를 오픈하거나 폐쇄적으로 관리하는 방법이 일반적임.

이너소스를 통하면 누구가가 좋은 아이디어로 올려놓은 소스를 통해 도움이 될수 있고, 숨어있던 전문가와 협업이 가능해짐. (인력 관리 측면에선 인재 찾기도 가능해짐.)

이너소스나 코드 재사용은 최대한 줄이는게 필요하긴 함.

또 규제 등을 받는 부분은 아이디어 코드를 숨겨놔야 할 수도 있음.

Coinbase라는 회사의 경우는 깃헙을 배우고 적응하는 것이 쉬워 인력 관리에 도움을 받은 사례임.

깃헙은 오픈 소스 커뮤니티를 제공하여 업계의 공동대응을 지원하기도 함.

오픈소스를 사용하며, 알럿을 받을 수 있다면 더 좋을 것임.

고객 의견, 혁신에서 개발은 너무 멀리 있지만, 오픈소스가 이를 지원해 줌.

깃헙은 코드와 프로세스를 보다 개선시켜 줌.

기존에 IBM과 일하며 상호간에 좋은 영향을 미쳤던 사례가 있음.

당시 IBM 사람이 쓴 기사.

A fool with a tool is still a fool

바보가 툴을 가지면 단지 툴을 가진 바보일 뿐임.

툴과 함께 문화가 있어야 기업이 바뀔 수 있음.

그래서 깃헙에서는 문화에 대해서 기업에 많은 질문을 던지려고 함.

MS와 깃헙은 혁신을 만들고 실제 서비스를 만드는 것을 중요하게 생각함.

이제 깃헙에서 Azure의 많은 서비스 접근이 가능해짐.

MS와 깃헙은 빠른 혁신에 도움이 되려고 함.

이에 대한 댓가를 따로 바라지는 않음. (그 예로 private repository도 무료화 함)

엣지에서 하기 어려운 테스트 등도 클라우드와 깃헙의 오픈소스를 사용하면 가능함.

Q & A

Q : 깃헙 액션 베타의 사용은 언제부터 가능한지?

A : 깃헙 액션이란 개발자가 work road를 수정할 수 있게 하려는 서비스임. 범위 통제 등도 제어.

​ 곧 또는 다음 분기를 예상하며, 곧 깃헙 3천만의 유저들이 work flow를 복사해서 쓸수도 있게 될 거임.

03. 1% + 99% = AI 대중화

• 발표자 : Jason Bissell (Databricks), GM

Databricks에서 현재 생각하는 것들

• innovation
• collaboration
• AI

아직은 1%정도의 기업들이 AI를 사용 중일 것임.

데이터 관련 직군은 월요일 아침에 많은 문제가 쌓인다는 것을 앎.

AMPLab의 Lester와 Matei라는 사람이 Netfliz Prize를 통해 Data 알고리즘을 풀어 백만장자가 될뻔 했으나 제출시간이 20분 늦어 실패함.

(그만큼 시간이 중요함?)

Spark는 600개의 코드라인에서 시작됨.

현재는 Spark로 수많은 UseCase들이 깃헙에 있음.

이제는 많은 기없들이 AI를 논함. (99%?)

1. Data is not ready for Analytics

   • 많은 Data가 Data Lake에 있지만 느리고 비용이 듦.
   • Data 분석이 안되서 그런 것이며 이는 Spark가 해결해 줌.

2. A Zoo of new ML Frameworks

   • 너무 다양하고 많은 ML 프레임워크가 있음.
   • 하나의 솔루션으로는 문제 해결에 어려움이 있음.
   • Databricks를 통해 여러 Frameworm를 사용하는데 도움이 됨.

3. Data Science & Engineering silos

   

   • 위 과정이 오래 걸리지만 databricks + ML Flow로 속도 개선이 가능함.

     

   • Azure Databricks 곧 한국에 서비스할 예정임.

     

기업 고객들이 원하는 것

• 데이터나 소스 활용도를 높이는 것

• 종합된 통계를 통해 Optimization하는 것

• 위 flow 들을 실시간으로 하는 것

  

대기업들도 대규모 데이터의 Optimization 속도 문제를 겪고 있음.

데이터 프레임워크 서비스로 이를 해결할 수 있으며, AI와 ML로 아이디어를 빠르게 구현할 수 있을 것임.

04. 클라우드 중심의 Digital Transformation 여정

• 발표자 : Youngchoon Park (Johnson Controls), VP

Johnson Controls는 130여년이 된 회사로 작년 37조 매출인 빌딩/명소 매니징 업체임.

매커니컬 중심의 회사가 변화를 어떻게 했는지 소개함.

Digital Transformation : 결국 value 창출의 대한 고민이 됨.

2011년에 Panoptix 라는 클라우드 기반 빌딩 제어시스템을 성공적으로 개발했으나, 사업적으로 망함.

2013년 Connected Product라는 서비스를 다시 만들어 절반의 성공을 거둠.

실패의 원인은?

너무 클라우드 중심이었고, 고객 경험을 고려치 못함.

데이터 엔지니어들을 모아 예상하지 않고, 바로 Product를 만들었음.

데이터 스케일링 아웃을 하려면 사람도 스케일링이 가능해야 함.

value 체인닝의 변화를 고려해야 했음.

기술 혁신으로 시작해 마켓 유통도 변화될 수가 있었음. (중간의 Reseller 가 필요없어진다던지)

AI 기술이 어떤 문제인지 어떻게 고쳐야 하는지를 제시해주지만,

비즈니스 관련 데이터 매칭이나 오프라인에서 걸리는 시간들(이동거리, 툴 렌트시간) 등이 실제 서비스 지연의 원인이 됨.

즉 Fault가 빨리 발견되어도 빨리 고칠수 있는지가 고객에겐 중요한 문제였음.

기술이 좋아도 실제 기존 서비스 경험과 고객의 비즈니스에 도움이 되어야 했음.

개발시 자기의 장점을 알아야 함. 조그만 밸류들이 모여 큰 밸류가 될 수 있음.

기술을 쓸 때 비즈니스 관점도 좋지만, 반복할 수 있을지도 생각이 필요함.

05. 글로벌 기업들이 이야기 하는 Panel Discussion

인텔, 팔로알토, Verizon, Microsoft 관계자 Q & A 형식의 좌담회?

Q : 인텔과 MS의 파트너십 전망은?

인텔 : 두 회사의 파트너십이 기술 시장을 이끌어 왔고, 앞으로도 이끌고 갈 거임.

Q : MS에서 고성능 CDN 지원이 필요해 네트워크 기술이 필요함.

버라이즌 : 버라이즌은 컴퓨팅 브로드밴드 사업도 함. 전세계 네트워킹의 10% 트래픽을 담당 중이며, 보안 및 트랙픽 대규모 지원을 함. 멀티미디어 서비스 지원 등의 호환성도 높이고 있음.

Q : Network 보안솔루션 소개? Azure 보안과의 차이는?

팔로알토 : Azure 마켓의 팔로알토 차세대 VM 시리즈는 알려진 위협, 알려지지 않은 공격에 대해 즉각적으로 분석 후 지원함. 보안 지표 등을 시각적으로도 제공함.

Q : SAP HANA를 위한 M-Series VM이란?

MS : M 시리즈는 핵심적인 피처임. 포괄적인 지원 머신(SAP를 위한?). 정확한 사이즈로 머신을 지원 가능케 함. 꼭 하이엔드 머신을 안써도 됨.

Q : 버라이즌 Digital Media Service의 공격적인 국내 투자는?

버라이즌 : MS 협업 전부터 확장을 고려했음. 컨텐츠 배포 등을 잘 지원하며 한국 게임이나 컨텐츠 시장을 특별히 생각함 (다른 시장과 다른 요구사항들이 나옴.)

Q : MS는 3500명의 인원과 1조원의 보안투자를 하는 중임. MS와 보안 협력 전략은?

팔로알토 : 보안은 크게 3가지로 보며 경계구간(네트워크), 실제 서비스 보안, 데이터 센터 보안으로 봄. 자산관리, 레드락 등을 제공하며 컨플루언스를 준수해 보안을 지원함.

Q : SAP와 MS의 파트너십 전망은?

MS : 30년 넘게 유지된 파트너십임. 현재 SAP 모든 시스템이 Azure로 옮김. Azure 팀이 SAP를 지원하며, SAP의 문제는 MS도 책임을 지고 개선하려 함.

Q : 미래형 클라우드 데이터 센터는? Project Brainwave란?

IBM : 고객이 더 쉽고 빠르게 Cloud AI 서비스를 사용 가능하도록 하는 것이 Project Brainwave임. 유연성이 높고 상대적으로 성능이 낮은 범용 프로세서와 유연성은 낮지만 성능이 좋은 특정 목적 프로세서의 중간인 FPG도 지원함.

Azure는 오픈 클라우드를 지향한다고 함.

Naver Tech Concert Day-1

07. Obfuscation 101: 난독화, 프로가드, R8, 트랜스포머 API

• 발표자 : 김용욱 (카카오뱅크)
• 동영상 : https://tv.naver.com/v/4655623/list/272653
• 슬라이드 : https://www.slideshare.net/NaverEngineering/16obfuscation-101-r8-api
• 세션설명 : 안드로이드의 앱들은 현재 프로 가드를 통해서 보호되고 있고 향후로는 구글이 작성한 R8으로 대체할 예정에 있다. 난독화 도구들을 써봤지만 막연히 쓰는 경우가 많은데 난독화 도구가 어떤 일을 하고 있고 기본적인 메커니즘이 어떻게 구현되어있는지 프로가드, R8은 무엇인지, 그리고 안드로이드 빌드 과정에 어떻게 통합되는지를 살펴보는 시간을 갖는다.

안드로이드 코드의 특징

• 이식에 좋은 바이트 코드 사용
• 동적 컴파일에 기반한 성능 향상
• 의존성도 동적으로 로드
• 암호화되지 않은 클래스와 리소스로 구성
• 공간 효율적인 데이터 포맷

바이트 코드에 대한 간략한 이해

자바 Bytecode

• 스택 기반의 VM을 사용 (검증이 쉽지만 레지스터 기반의 실제 기기와 차이로 성능상 단점)
• 32비트 스택 하나의 요소가 대부분의 타입 커버
• 256개의 연산

자바는 상수의 종류를 구반하지 않음.

1+2 연산시 1과 2의 스택을 쌓은 후 두 스택을 꺼내 연산 후 3을 스택에 쌓음.

istore의 i는 int형을 의미.

기본적으로 ARM이나 x86 기계어보다는 단순함.

달빅 Bytecode

• 레지스터 기반의 VM 사용 (실제 하드웨어와 매핑에 이점으로 메모리 덜 쓰나, 상대적으로 검증이 어려운 단점)
• 32비트 레지스터 하나의 요소가 대부분의 타입 커버
• 64K 개의 레지스터 하지만 주로 앞의 256개, 가끔은 16개만 사용.

const 명령을 통해 레지스터 v1, v2에 상수를 넣음.

add-int를 통해 v2와 v3의 합을 v0에 저장.

자바와 달빅 bytecode 차이점

desugar는 자바 8을 지원하기 위함. (람다 등을 제거하여 자바 7 컴파일러가 돌 수 있도록)

.class 파일을 dex(dx, d8)을 통해 .dex 파일로 변환.

• DX - 안드로이드 스튜디오 3.0 전 (D8보다 시간이 오래 걸리고 용량도 큼)
• D8 - 안드로이드 스튜디오 3.0 이후 (써드파티 툴에서 새로운 DEX를 지원하지 못하는 문제 있을 수도)
• gradle.properties에서 android.enableD8 = true | false

DX/D8 비교는 안드로이드 스튜디오의 APK Analyzer로 비교 가능.

Jack & Jill을 통해 .java를 .dex로 한번에 빌드하는 것을 구글에서 시도했지만, 기술을 폐지하기로 함.

(써드파티 생태계에서 달빅 바이트코드를 제어하지 않기에)

Transform API

구글이 써드파티를 위해 제공한 API

.class -> Transformer -> .class 형태를 가짐.

프로가드 등의 도구들도 Transform API에 의존적이나 여전히 그러지 못한 도구들이 존재함.

Transform 을 상속받아 transform을 구현하여 입력받은 클래스 파일을 변조 후 출력하면 됨.

ProGuard, Realm Transformer, Desugar 등도 표준화된 API를 따름.

Transformer를 만들 때는 ASM, BCEL 같은 Low Level를 쓰거나 (주로 Google), AspectJ 같은 High Level을 쓰기도 함 (Jake Wharton). 또는 그 중간인 Javassist를 사용하기도 함 (Realm).

동적 컴파일에 기반한 성능 향상

인터프리터 vs JIT(코드 일부를 컴파일해 개선) vs AOT(미리 빌드)

1. 아무 정보 없을 때 인터프리터로 해석. (느림)
2. 일정 횟수 이상 수행된 메서드만 컴파일해 JIT 코드 캐쉬에 저장. (프로파일링 정보에 기반해 업데이트)
3. 주기적으로 dex2aot 데몬이 코드를 빌드해서 oat 파일을 생성.
4. 다른 앱에 의해 사용되면 전체 빌드, 아니면 프로파일에 기반해 빌드.
5. JIT 컴파일과 AOT 컴파일이 있다면 JIT 컴파일 사용.(동적 최적화)

의존성도 동적으로 로드

자바는 모든 것이 동적으로 로딩.

메서드 명, 클래스 명, 필드 명이 공개되며, 안드로이드 앱의 경우 Activity, Fragment, Service 등을 외부로 공개해야 함.

난독화 도구에 exlcue/include 항목을 설정해야 함.

암호화되지 않은 클래스와 리소스로 구성

1. 클래스와 리소스는 암호화되어 있지 않음.
2. 기본 클래스 로더가 암호화를 지원하지 않아 한계가 존재. 기본 클래스 로더가 호출되기 전에 암호화가 풀린 클래스를 가로챌 수 있음.
3. 클래스 암호화는 선호되는 보호 방법이 아님.

공간 효율적인 데이터 포맷

1. LEB-128 사용해 가변 바이트(1-5바이트)로 32비트 잘 저장 7비트 단위로 나누어 그룹화 하여 앞에 첫문자인지 0/1로 구분
2. 부호가 있는 수를 위한 SLEB128, 부호 없는 수를 위한 ULEB128과 -1만 지원하는 ULEB128p1이 있음. ULEB128p1일 경우 -1이면 0.
3. 여러 클래스에서 상수 공유 (.class가 아닌 .dex 지원으로 가능)
4. 상대 주소 사용 (특정 주소(1024) 이후엔 상대적인 주소(1)로 사용)
5. 메서드 갯수까지 효율적으로. (64K)

난독화와 앱 보호에 대한 간략한 이론

1. 클래스/리소스에 암호화를 적용
   • 클래스를 암호화하고 커스텀 로더 사용
   • Packer와 Protector로 나누어짐.
   • 해독을 위해 클래스를 전달해야 하며, 결국 커스텀 로더가 공격의 취약점이 됨.
   • 많은 패커와 프로텍터는 ODEX 복사나 심지어 Dex2Jar 툴에 의해 쉽게 풀림.
2. 리소스 사이에 클래스를 매복
   • 이미지 파일로 dex 파일을 숨기는 방법
   • 수상하게 큰 파일을 찾거나 파일 포맷 검증으로 혐의가 좁혀짐.
3. 네이티브 코드로 핵심 코드를 숨김
   • 성능상의 이점도 있지만 그래도 기계어 코드도 해석이 가능하긴 함.
   • VM 밖에선 온갖 하드웨어 이슈를 경험할 수 있음.
   • ABI 세트 맞추기 어려움.
4. 서버에 핵심 코드를 숨김
   • 리얼 타임 응답성이 떨어짐. 로컬 DB 필요할 수도.
   • 서버 다운시 사용 불가. 로컬 캐쉬 이용해서 풀백 구현도 어려움.
5. 템퍼 감지를 추가
   • 디버거, ptrace 를 발견하는 코드 삽입
   • 에뮬레이터 감지
   • 해당 부분 우회시 대부분 앱 진입이 가능함.
6. 클래스, 필드, 메서드 명 변경
   • ProGuard부터 대부분의 도구가 지원
   • 짧고 간격한 이름으로 클래스, 필드, 메서드 명 변경하지만 외부에서 import 되거나 export 되는 명칭은 변경 불가
   • 위 처리로 공간 복잡도도 줄이고 실행시간에도 긍정적인 영향 줌.
   • 명칭만 바뀌는 것이라 결국 해결 가능.
   • 도구마다 고유의 네이밍 패턴이 있음. (APKiD에서 검출)
7. 리플렉션 호출 추가
   • 메서드 호출 단계를 추가
   • ProGuard는 지원 못하지만, DexGuard나 Arxan 등 유료도구에서 지원
   • 리플렉션이 반복적인 패턴을 가지기 때문에 기계적으로 풀 수 있음. (ex. Dex-Oracle에서 DexGuard 패턴 해제)
   • 많은 단말에서 리플렉션 크래시 보고됨.
8. 노이즈 추가
   • 메서드 외부에 아무런 영향이 없는 코드 추가
   • 클래스 상태 변경, I/O, 반환 값 등이 없음.
   • 디버거나 디스컴파일러가 깨지는 코드를 추가하기도 하지만, 그만큼 쉽게 고쳐짐.
9. 제어 흐름
   • 반복문이나 분기문을 불필요하게 추가
   • If 문 대신 try-catch 블록을 사용하기도 함.
   • switch 문을 중첩적인 레이블로 변경하기도 함.
   • 브랜치를 jsr 명령 (goto)로 변환하기도 함.
   • 일반적으로 속도를 저하시키는 요인.

ProGuard와 R8의 역할

프로가드는?

6. 클래스, 필드, 메서드 명 변경

7. 사용하지 않은 클래스, 필드, 메서드 제거

.class->ProGuard->.class

위는 아래와 같음.

.class->Shrinker->.class->Name Obfuscator->.class

안드로이드 빌드에 통합된 프로가드

.java->javac->.class

​ ->Desugar Transform->.class

​ ->ProGuard Transform->ProGuard->.class

​ .dex<-Dex<-

통합되지 않은 난독화 도구들의 흐름

.java->javac->.class

​ ->Desugar Transform->.class

​ ->Dex->.dex->Dex2jar->.class

​ .dex<-Dex<-.class<-Obfuscator<-

R8

.java->javac->.class

​ ->Desugar Transform->.class

​ ->R8->.dex

R8 = D8 + Shrinker + Name Obfuscator

(ProGuard 버리려는 계획?)

Naver Tech Concert Day-1

06. Android Kotlin을 통한 개발 전략

• 발표자 : 신동길 (네이버 / 네이버앱개발)
• 동영상 : https://tv.naver.com/v/4655590/list/272653
• 슬라이드 : https://www.slideshare.net/NaverEngineering/15android-kotlin
• 세션설명 : 코틀린을 안드로이드에 적용하기 위해서는 안드로이드에 맞는 모듈의 개발, 거버넌스, 코딩 패턴, 디자인 패턴 등의 전략적 고려 사항이 필요합니다. 네이버앱에 코틀린을 적용한 경험을 토대로, 기존 프로젝트(또는 신규 프로젝트)에 코틀린을 적용할 때 반드시 고려해야 할 사항과 적용하면서 나온 사례를 통해서 최적화된 적용 방법을 공유합니다.

네이버 테크 콘서트 앱는 머티리얼 디자인만 사용하여 개발함.

자바를 컨버팅해 코틀린을 적용한 경우 심플하지 않고 문제도 많았음.

컨버팅시 물음표를 너무 많이 만듬.

코틀린 코드를 자바에서 사용할 경우 코틀린 코드에 붙어야할 부분도 많음.

코틀린을 배워도 자바 스타일로 짜는 경우가 많음. (코드를 너무 줄여서 가독성이 떨어진다는 평들)

코틀린으로도 긴 소스를 유지보수 명목으로 전달받았을 때 사례

• 정적 호출이 많아 클래스명부터 쓰는 코드들이 많음.
• 위의 문제로 alias 목적으로 함수 작성하여 사용.

아래 3코드는 동일한 기능임. (적어도 1번째는 피하도록 해보자.)

• Java

if(LoginManager.getInstance().isLoggedIn() == false) {
    LoginManager.getInstance().loginWithDialog(this, ActivityCode.INAPP_WEBVIEW_BOOKMARK_LOGIN);
}

• Kotlin

if(naverLoggined == true) {
    naverLogin.loginWithDialog(this, ActivityCode.INAPP_WEBVIEW_BOOKMARK_LOGIN)
}

• Kotlin (DSL)

isNaverLoggined {
    naverLogin.loginWithDialog(this, ActivityCode.INAPP_WEBVIEW_BOOKMARK_LOGIN)
}

코틀린의 유용한 기술들

• 람다 (Java 8, Javascript)
• 오퍼레이터 (C++)
• 오버로딩 (C++)
• Method Extension (C#)
• Property (Object Pascal)
• DataStream Model (Direct X, java 8)

함수형

함수의 파라미터와 리턴형으로 함수를 표현한 자료형.

모든 함수는 함수형으로 형으로 표현 가능.

함수, 람다, 익명함수, 함수 참조 등을 변수로 선언 & 전달할 때 사용.

val onClickListener = object: View.OnClickListener {
    override fun onClick(view: View?): Unit { }
}
typealias onClick = (View?)->Unit

val runable = object: Runnable() {
    override fun run(): Unit { }
}
typealias aliasRun = ()->Unit

람다 식(Lamda Expression)

함수를 불필요한 부분 생략하고 기호화하여 간결화한 것.

Expression 이므로 함수와 달리 코드 중간에서 값을 리턴하지는 못함.

val buttonClick: onClick = { view -> /* Code */ }
val buttonClick2: onClick = fun(view: View?) { /* Code */ }

연산자 재정의

프로퍼티

• 변수에 대한 처리와 변수 값을 묶어 놓은 것
• 함수는 내부 저장을 안하지만, 프로퍼티는 내부에 저장하는 필드를 두어 중복 동작을 막을 수 있음.
• 프로퍼티는 작성하는 사람은 복잡하지만 쓰는 사람을 위한 개념.

fun loadNaverAppIcon(): Drawable? { return icon }

val naverAppIcon: Drawable? = null
get() {
    if(field != null) return field
    // Code
    return field
}

자바 코드 변환

예전에는 모든 프로퍼티를 nullable (? 붙여서)로 해주었으나, 이젠 컴파일 에러 나도록 변환해 줌. (개발자가 생각해보고 고쳐야 함.)

멤버 변수의 초기화

• Optional(?)

  • Null로 초기화하고 나중에 값을 지정

    private var mTitle: TextView? = null

• lateinit (기존 코드 바꿀때는 정석으로 보임)

  • 초기 값을 지정하지 않고 생략 후 나중에 대입

  • 변수 접근시 초기화 여부를 확인하지 않음

    private lateinit var mTitle: TextView

• by lazy (delegator)

  • 사용 시점 초기화 됨.

  • 코드 블록으로 초기화 하므로 다른 처리 가능

    private val mTitle: TextView by lazy { findViewById<TextView>(R.id.txt_name) }

• init{} (Activity나 Fragment는 onCreate 시점에 init을 해야해서 적절하지 않음. View 정도에나 적절할 듯)

  • 초기 값을 지정하지 않고, 이 함수에서 지정 가능

  • 객체의 초기화 시에 값을 지정할 수 있음.

    init {
        mTitle = findViewById(R.id.txt_name)
    }

Nullable 처리

• Java

  public View getView(int position, View convertView, ViewGroup parent) { }

• Kotlin

  override fun getView(position: Int, convertView: View, parent: ViewGroup): View { }

위에서 convertView는 null이 가능해 @Nullable를 붙여줘야 컨버팅시 nullable이 가능해짐.

클래스 중첩 최적화

코틀린은 한 파일에 여러 개의 객체 선언 가능하나, 최대한 빼내는게 깔끔함.

opinion 으로 스태틱 쓰는 경우도.

해당 파일에서만 쓸 경우 private 붙임.

internal class Monet {
    fun request(): ImageRequest = ImageRequest()
    inner class ImageRequest { }
}

inner class ImageRequest { }

internal class Monet {
    fun request(): ImageRequest = ImageRequest()
}

Optional(?.) 최적화

• ? 선언
  • 꼭 필요한 경우만 쓰고 init/late init/lazy 로 피할 수 있으면 피해라
  • !!는 확실히 검증된 경우만 사용
• let, apply 표준확장 함수
  • 동일 변수에 2개 이상의 ?.를 사용할 때 쓰며, 과용하면 오히려 어려워짐.
• Elvis(?:)
  • 조건문 내에 쓸 때 생각해볼 것

체인닝을 하는 건 좋지만, 길어지면 해석이 어려워짐.

네이버 앱의 브라우징 제일 큰 클래스의 경우 3800 라인 정도였으나, 코틀린 변경 후 2500 라인으로 줄어들음.

코드 효율화를 위한 툴킷 정의와 활용

• 패키지 레벨 전역 변수 함수

  • Global Context : Application Context, Handler 등등
  • Systems Managers : ConnectionManager, ActivityManager 등등
  • System Util Functions : Screen info, dp2px 등등
  • 3가지 초기화 방식 (단순변수, 지연 초기화된 변수, Property)

• 연산자

  • setOnClickListener 등을 plusAssign 연산자 등으로 대체 가능
  • get/setExtra 관련 함수들도 get/set 연산자 등으로 대체 가능

• 고차함수 정의 (DSL 스타일)

  • Orientation 예제

    val isPortrait: Boolean
    	inline get() = appContext.resources.configuration.orientation == Configureation.ORIENTATION_PORTRAIT
    
    inline fun isPortrait(block:()->Unit) = if(isPortrait == true) block() else Unit
    inline fun isPortrait(blocks:Pair<()->Unit, ()->Unit>) = if(isPortrait == true) blocks.first() else blocks.second()
    
    fun testOrientation() {
        isPortrait{ showToast("Screen is portrait!") }
        
        isPortrait{ 
            showToast("Screen is portrait!") 
        } others {
            showToast("Screen is landscape!") 
        }
    }

  • API Levels 예제

    inline fun sdkRange(sdk: IntRange, block: ()->Unit): Any = if(SDK_INT in sdk) { block() } else Unit
    inline fun sdkFrom(sdk: Int, block: ()->Unit): Any = if(SDK_INT >= sdk) { block() } else Unit
    inline fun sdkTo(sdk: Int, block: ()->Unit): Any = if(SDK_INT <= sdk) { block() } else Unit
    
    const val OS_N = android.os.Build.VERSION_CODES.N
    
    sdkFrom(OS_N) { /* New OS */ }
    sdkRange(JB..KK) { /* Old OS */ }

  • Catch all Exceptions 예제

    var safeReportDebugProc: ((String?)->Unit)? = { }
    inline fun safe(block:()->Unit): Throwable? {
        val result = try {
            block()
            null
        } catch (e:Throwable) {
            e.printStackTrace()
            safeReportDebugProc?.invoke(e.message?:"")
            e
        }
        return result
    }
    
    fun testSafe() {
        safe {
            val file = File("")
            FileInputStream(file).use {
                it.read()
            }
        }
    }

팀 개발 공동 개발을 위한 거버넌스

• 너무 다양한 스타일이 존재
• 개발자의 언어 이해 능력의 차이가 나므로 스타일을 어느 정도 정할 필요 있음.
• 어떤 스타일의 금지가 아니라 어떤 패턴의 코드에는 어떤 스타일을 우선할 것을 권장하게 정의
• 시스템 클래스에 대한 함수확장이나 전역변수의 대한 가이드 라인도 어느 정도 필요

Q&A

Q : Kotlin 기본 내장 함수인 let, apply, with, run 등은 비슷하게 사용할 수 있어 보이는데, 규칙 같은걸 정하는지?

A : 각 함수마다 개념적인 정의대로 사용하며, 될 수 있으면 중첩하지 않도록 사용 중. 네이버도 적용 중이라 완벽히 정해지지 않았음.

Q : 확장 함수 사용시 해당 클래스의 메소드인지 확장함수의 메소드인지 구분짓는 규칙이 있는지?

A : interface를 쓰면 됨. Kotlin에서는 interface에 companion이나 함수도 정의 가능하고, class에 다중 상속도 허용되는 구조.