인프런 퇴근길 밋업 with KotlinConf 2023 Global 후기

doxxx·2023년 4월 26일
0

후기, 리뷰

목록 보기
1/4

지인분의 티켓 양도를 받아서, 판교의 인프랩에서 진행하는 인프런 퇴근길 밋업에 다녀왔다. 글을 쓴 시점에는 발표자료나 영상이 올라오지 않은 상태이다.

진행은, 6시반부터 7시까지 체크인을 시작으로

위와 같다.

6시 35분?쯤 도착했는데 이미 거의 가득찬 상태였다.

바로 본론으로 들어가자.

KotlinConf is back!(부제: after the party)

당근 마켓의 박용권님은 당근 마켓에 합류하게 되면서 코틀린을 쓰기 시작해 약 18개월..? 8개월..? 차라고 하셨다. 합류하자마자 새로운 기능을 만들게 되었다고 하셨다.

당근 마켓에서의 코틀린 사용량은 리포지터리 기준으로 타입 스크립트, 고랭 다음으로 10% 정도의 비율을 보이고 있다고 한다.

지난 4월 12일부터 14일까지 진행했던 KotlinConf의 기조연설 내용을 정리 발표해주셨다. KotlinConf앞의 링크는 코틀린 블로그에 올라온 기조연설 정리 공식 글이다.

각 주제에 대해서 아주 간략하게 정리를 해보았다.

K2 compiler

K2 컴파일러가 Kotlin 2.0으로 출시된다. 현재는 1.8.20 버젼이다. 특히 프론트엔드 컴파일링 속도가 현저하게 개선되었다고 한다.
작년 Kotlin 'Summer' Night 2022 Seoul
에서의 발표에서는 정량적인 비교도 담겨있었던 거로 기억하는데, 비교해보면 좋을 것 같다.(위 영상의 데브시스터즈의 박세란님의 코루틴 내용이 상당히 재밌다.글 링크)

기타 언어 소식

KEEP은 코틀린 개선 요구들을 이슈로 남기고, 이에 대한 디스커션과 진행 내용들이 업데이트 되는 리포지터리이다.

여기서 많은 관심을 받아온 제안들이 2.0에서 제공이 된다는 내용이다. 해당 내용과 이슈를 링크로 남기겠다.

멀티플랫폼

현재 코틀린 멀티플랫폼은 실험적 - 알파 - 베타 - 안정화 에서 베타에 위치하고 있다.

인프런강의 는 박용권님의 앞광고(?) 강의지만 무료다.

컴포즈 for iOS, Web

사실 여기서부터 좀 어려웠는데, 쉽게 설명해서 코틀린이 플러터와 리액트(넥스트)의 전장에 뛰어들었다. 라고 설명을 해주셨다.
실제로 시연 영상을 보여주셨는데, 안드로이드, 데스크톱, 웹은 코틀린 선에서 해결할 수 있었고, ios는 몇가지 세팅 후, xcode에서 swift를 조금 건드려서 직접 보여주셨다.

(사실 이해 못함)

데뷰 - 그 여자 APP, 그 남자 SDK: Kotlin Multiplatform 적용기 를 참고하는 것을 추천하셨다. 정말 재밌게 보셨다고 한다.

멀티플랫폼에 대한 질문들이 나왔지만, 사실 이해 잘 못했다.

함수형 코틀린

김용욱님(유튜브 달리나음IT)의 발표였다.

Kotlin & Functional Programming라는 주제로 Urs Peter의 Kotlin Dev Day 발표 영상 을 정리한 내용이다.

사실 발표는 좋았지만, 위의 영상이 너무 arrow framework를 알리기위한 홍보 영상과 같은 느낌이라 전체 내용이 다 들어오질 않았다.

위 그림이 발표의 흐름이다. 좌 하단부터 화살표 방향에 맞게 넘버링해서 표현해보겠다.

주된 내용은

  • 선언형 언어 빌드업,
  • 고차 함수에 대한 설명,
  • 카테고리 이론 ~ 함수형 언어에 대한 설명(모나드를 곁들인)
  • 코틀린에서 FP를 하기위한 노력, arrow framework (잡솨봐)이다.

위 순서대로 보단 그냥 내 생각대로 요약을 해보겠다.

함수형 프로그래밍

현재 프로그래밍에서 다뤄지는 기술들은 사실 과거에 이미 이론적으로 완성이 되어있는 경우가 많다고 한다. 코루틴 58년, lisp 60년, 모나드 80년대, OOP는 7~80대 등등..

OOP는 특히 80년대에 이미 이론적으로 완성되었지만, FP는 갑론을박이 남아있다는 것 같다.

그 기준 또한 고차함수 유무, 관심사의 분리, 모나드의 사용 등.. 사실 정확하게 듣질 못했다.

아무튼 코틀린을 선택하게 된 이유는 google trends에서 나머지 언어에 비해 코틀린이 떠오르고 있기 때문이라고 한다.

고차 함수

위와같은 상황을 어떻게 처리할 수 있을까?

박스친 메서드를 제외하고 내용이 사실상 동일하다. 고차 함수(Higer-Order Function)은 함수의 파라미터에 함수를 받을 수 있다.

이런 내용은 솔직히 허졉한 내 글이 아닌 다른 좋은 글들을 통해 공부하는 것이 좋을 것 같다.

이제 말도 많고 탈도 많은 모나드에 대한 내용을 다룬다.

모나드

발표에서는 모나드를 컨테이너라고 생각하면 된다고 한다.
코틀린의 모나드는 아래 네 종류라고 한다.

  • Collections
  • Optional
  • Future
  • Result

모나드의 기준은
1. 서로 combine 할 수 있다.
2. elements들을 transform(데이터, 값 변형을 뜻하는 듯하다) 할 수 있다.
3. nesting없이 모나드 elements(마트료시카와 같이 모나드 속 모나드)를 transform 할수 있다.

라고 한다.

솔직히 여기서 부터는 정신을 잃었다.

결론은 망치질을 하기 위해서 망치에 대한 공부를 할게 아니라 그냥 잘 쓰면 되듯, 모나드도 그러하다는 내용이었다.

이후는 arrow framework에 대한 내용이라 skip..

네트워킹

14, 15명씩 두개의 그룹으로 네트워킹을 시작했다.

발표자분이 한개의 그룹씩 얘기를 나누고 스몰 토킹이 진행되었다.

  • 클라이언트 개발자 분들은 이미 구글이 하라는대로 코틀린이라는 선택지 뿐이다. 라고 현재의 상황에 대해서 재밌게 말씀해주셨다.
  • 자바에서 코틀린으로 넘어오게 된 분들의 경우 자바가 버젼이 올라가게 되면서 점차 코틀린의 기능들을 갖추게 되었지만, null safety는 자바가 어떻게 할 수 없으니 돌아갈 거 같지 않다는 답변을 들었다.
  • loom에 대해서는 박용권 발표자분께서는 코틀린과 자바가 서로 대척점에 놓인게 아니라 선택지가 늘어난 것일 수도 있다. 라고도 하셨던 거 같다. 사실 여기에 대해선 정확한 내용을 알고 계신분이 없었어서 따로 공부해보면 좋을 것 같다.
  • 데브시스터즈의 개발자분께서는 최근 scala를 도입하게 되었다고 하셨는데 코틀린으로는 원하는 만큼의 함수형 프로그래밍을 구현하기에 부족했다는 말씀을 해주셨다.
  • JPA대신 Exposed나 안드로이드 Room. 코틀린과 자바의 ORM JPA(하이버네이트)이 미스매칭이 발생하여 이를 해결하기 위해 너무 많은 input이 들어가서 애초에 jpa를 배제했다는 개발자 분들이 좀 있었다.

코틀린 알못의 코틀린 네트워킹은 꽤나 재밌었던 것 같다.

  • 좋았던 점: 시간, 위치, 진행이 되게 매끄러웠다.
  • 개선 하면 좋을 점: 네트워킹시 인원을 좀더 소수로 나누면 좋을 것 같다. 관심사에 맞게 소그룹을 먼저 분류를 해도 좋을 것 같다.

References

1개의 댓글

comment-user-thumbnail
2023년 5월 2일

와 정리가 엄청나신데요. 저는 발표를 준비하며 원 발표가 조금 Arrow에 치중된 게 아쉬웠는데 Recap 발표라서 가능한 그대로 전달하려고 하였습니다.

함수형에 대해 갑론을박이 있다고 하면서 이야기 드린 부분은 제 사견을 소개드렸는데 하스켈이 나오면서 드디어 순수 함수형 언어가 나왔고 (90년대) 그래서 서로의 이견이 많았던게 아닌가 생각을 했었습니다.

  1. 누구는 고차 함수만 쓰면 함수형이다 주장하는 것 같고
  2. 어떤 이는 관심사의 분리가 중요하다고 주장하는 것 같았는데요. What을 선언적으로 기술하고 How를 선언하는 런타임, 옵티마이저에게 전달하여 처리해야 함수형이다고 주장하는 케이스가 있었던 것 같고요.
  3. 하스켈, 스칼라 측에는 모나드를 써야 한다고 생각하는 이들이 많은 것 같습니다.

전 여기에 대해서 어느 측도 동의하지는 않는데 Urs Peter는 3번에 가깝고 Arrow를 지지 하는 사람인 것 같습니다. 실제로 그가 일하는 Xebia가 Arrow를 만드는 회사이기도 하고요.

그럼에도 저는 뭔가 인사이트를 얻을 수 있던 부분은 있었던 것 같습니다. 코틀린의 언어적인 한계에도 불구하고 수신 객체(Receiver) 지정 람다를 이용해서 극복하려는 시도는 저런 형태로 해결할 수 있구나 생각이 들었고 모나드 컴프레헨션이 아니더라도 같은 방식으로 응용할 수 있겠다는 생각을 했습니다.

모나드를 여러 겹으로 했을 때 코틀린에서는 해법이 없기 때문에 하나만 쓰고 suspend, nullable을 같이 잘 활용하자란 내용도 있었던 것 같습니다. Xebia나 47 Degrees의 다른 발표자를 보니 Either만을 활용하려는 시도가 있더라고요. Optional한 부분도 Either<Unit, T>의 형태로 해서 사용하고 Either를 Result용도로도 사용하는 형태로요. Arrow나 다른 모나드를 사용할 때도 Either 정도만 사용해보자란 생각을 하게 되었습니다.

답글 달기