tei.fxpark 자칫 어려울 수 있는 Effect System 개념을 예제와 같이 쉽게 풀어서 알려주고, Effect System을 만들기 위해서 과거부터 어떤 고민이 있었는지 알아볼 수 있었습니다. Side Effect가 없는 안전한 코드를 만들고 싶은 분들께 이 글을 추천합니다.hyeoni.c Side Effect라는 불확실성을 Effect System을 활용하여 안정성과 유지보수성을 모두 잡을 수 있는 방법을 쉽게 알려줍니다. 더 나아가 Effect System의 미래까지 확인하고 싶다면 이 글을 추천합니다!여러분은 위 코드를 보고 어떤 동작을 수행하는지 알 수 있나요? 메서드명만 보면 어딘가에 이벤트를 보내는 것 같습니다. 혹시 여러분도 저처럼 메서드의 이름만 보고 동작을 유추하고 있지는 않나요?이해를 돕기 위해 실제로 서비스에 적용해보겠습니다.만약 내가 담당하고 있는 서비스에 위 코드를 적용한다고 가정해 보겠습니다. 적용하려는 곳이(사용자 결제와 직접적으로 연관 있는) 크리티컬한 영역이라면 어떨까요? 아마 자연스럽게 의심부터 시작할 것입니다.타 팀에서 sendEvent 메서드를 서비스에 적용하는 과정에서 아래와 같은 질문을 받았습니다.• sendEvent를 호출하면 이벤트는 어디로 어떻게 전송하는 것인가요?• sendEvent만 호출했다 하면 간헐적으로 알 수 없는 Exception이 터져서 이후에 있는 기존의 로직이 실행이 되질 않습니다. 매출에 영향이 있으니 얼른 고쳐주세요.• sendEvent는 얼마나 오래 걸리나요? 우리 서비스는 사용자 결제 UX와 직접적으로 연관이 있기 때문에 빠르게 처리돼야 합니다. 많은 시간을 소모하지 않았으면 합니다.적용을 했는데 간헐적으로 NPE(NullPointerException)가 발생한다거나 CPU, 메모리 사용량이나 Latency가 증가하는 등 운영을 하기 전까지는 알 수 없는 문제가 발생할 수 있습니다. 특히 개발 환경에서는 문제가 없었는데 운영 환경에만 배포하면 문제가 발생할 경우 개발자를 야근의 늪으로 빠뜨리는 하나의 요소가 될 수 있습니다.왜 우리는 코드만 보고도 숨은 의도나 이슈를 파악하지 못해 늘 문제가 터진 뒤에야 대응하게 되는 것일까요? 왜 매번 Null check를 빼먹어서 NPE를 맞이하는 걸까요? 문서화, 테스트 코드 작성 등의 활동으로 어느 정도 이슈를 커버할 수는 있지만 모든 불확실성을 커버하기란 쉽진 않습니다. 뭔가 더 나이스한 방법은 없는 것일까요?이 문서에서는 Effect System을 이용하여 사이드 이펙트를 명시적으로 드러내고 조합하는 방법을 살펴보고자 합니다. Effect System을 처음 듣는 사람도 있고 경험해 본 독자도 있을 텐데요. Effect System이 뭔지는 뒤에 가서 좀 더 살펴보도록 하겠습니다.이 글은 Effect System의 기법들과 개념들을 간략하게 살펴보는 입문용 글로서 주로 Scala 언어로 설명하지만 상황에 따라 Java나 Kotlin 언어를 사용하여 설명합니다. 따라서 Scala, Kotlin 언어를 다뤄봤으면서 좀

안녕하세요! 저는 쿠키런: 마녀의 성 서버를 담당하고 있는 5년 차 게임 서버 개발자 주윤아입니다.이직을 고민하고 계신가요? 새로운 팀에 합류하거나, 전혀 다른 코드베이스에서 일하게 된다는 건 많은 개발자에게 큰 도전으로 다가올 수 있습니다. 저 역시 같은 고민을 했습니다. 전 직장에서는 하나의 프로젝트에 4년 동안 몸 담으며 처음부터 끝까지 모든 과정을 경험했기 때문에, 새로운 환경에서 타인의 코드를 이해하고, 빠르게 적응해 성과를 낼 수 있을지 걱정이 컸습니다.하지만 그런 두려움에도 불구하고, 저는 데브시스터즈에서 1년 동안 두 개의 프로젝트에 참여해 각기 다른 코드베이스를 학습하고, 저의 것으로 만드는 과정을 거쳤습니다. 그 과정에서 크고 작은 기능 구 현과 업데이트를 성공적으로 완료 하며 팀에 완전히 녹아들 수 있었죠.본론에 들어가기 앞서, 첫 번째 팀이 아닌 두 번째 팀인 쿠키런: 마녀의 성 코드베이스 적응 과정에 집중하려고 합니다. 그 이유는, 두 번째 팀에서 경험한 것이 저에게 더욱 큰 도전이었기 때문입니다. 이전 팀에서는 익숙했던 C# 기반의 객체 지향 프로그래밍 언어를 사용했지만, 두 번째 팀에서는 함수형과 객체 지향 멀티 패러다임 언어인 Scala 를 처음 접하게 되었고, 더불어 새로운 아키텍처를 학습해야 했습니다. 또한 당시 혼자서 학습을 해야 했던 특수한 상황이었기에 그 과정은 더욱 까다로웠습니다.이번 글에서는 제가 새로운 코드베이스에 적응하고, 그것을 내 것으로 만드는 과정에서 느꼈던 고민들과 배운 점들을 공유하려 합니다. 이직 후 새로운 팀에 적응하는 것이 막연하게 느껴지는 주니어 개발자들에게 이 글이 작은 도움이 되길 바랍니다.새로운 팀에 합류하면서 낯선 코드 베이스와 프로그래밍 언어를 어떻게 효율적으로 익힐 수 있을지 고민이 컸습니다. 사람 마다 학습 방법이 다르겠지만, 저처럼 정석보다는 꼼수에 의존해온 사람에게는 특히나 공부의 순서를 정하는 것이 어려웠습니다. 제가 정한 학습 흐름은 크게 세 가지 단계로 나눌 수 있었습니다.• 문법 학습 : 새로운 언어의 기본 문법을 익히는 것이 가장 중요했습니다. 이 과정에서 사내에서 모든 스칼라 개발자가 완독했다는 빨간 책이라는 scala 관련 서적을 참고했습니다.• 스칼라로 배우는 함수형 프로그래밍 (제이펍, 2015)• 프레임워크 학습 : 서버 개발을 위해 사용되는 ZIO 프레임워크의 구조와 동작 방식을 파악했습니다.• 상업 코드 분석 : 실무에서 작성된 코드를 분석하고 작은 퀘스트들을 수행하며 경험치를 쌓았습니다.기존에 알고 있던 객체지향 언어들과 달리 새로운 패러다임을 익히는 과정은 고통스럽기도 했지만, 사내 상업 코드를 보며 월급을 받으며 새로운 언어를 학습할 수 있다니, 완전 럭키비키🍀 였습니다.새로운 팀의 코드 아키텍처현재 팀의 코드베이스는 제가 익숙했던 기본 아키텍처와는 달랐습니다. 헥사고날 아키텍처와 도메인 주도 설계(DDD)를 기반으로 한 방식은 개념으로만 알고 있었고, 실제로 적용해 본 적은 없었습니다.처음에는 낯선 함수형 언어와 새로운 아키텍처에 당

Unity Catalog로 전환 하면서 겪은 모든 것안녕하세요, 베이글코드 데이터 엔지니어 하석윤 입니다. 베이글코드 데이터팀의 메타스토어를 Hive Metastore에서 Unity Catalog로 전환한 여정을 소개드리고자 합니다.왜 Unity Catalog를 도입하게 되었나요?베이글코드의 DATA&AI 팀은 2018년부터 Databricks를 활용하여 데이터 웨어하우스의 기반을 구축하고, 사내의 데이터 기반 의사결정을 지원해 왔습니다. 현재 약 10,000여 개의 테이블을 ETL, 데이터 분석 및 활용에 사용하고 있습니다. 그동안 이 모든 테이블은 Databricks의 Hive Metastore에서 관리되었습니다.2021년, Databricks는 새로운 Metastore 솔루션인 Unity Catalog를 발표합니다. 하지만 데이터 엔지니어로서 실무에서 Unity Catalog의 임팩트를 체감하기까지는 여러 장애물이 있어 시간이 걸렸습니다. 그래도 DAIS(Databricks AI Summit) 컨퍼런스에 다녀온 팀원들이 테이블 계보(Table Lineage)나 Serverless Compute와 같은 기능들을 정리해 공유해 주셨고, 팀에서는 “이 기능을 언제쯤 써볼 수 있을까?”, “UC가 있다면 작업에 정말 도움이 될 것 같다”는 기대를 하였습니다.Databricks는 매력적인 신기능들을 지속적으로 출시했지만, Unity Catalog 환경에서만 지원 하는 경우가 종종 있었고, Hive Metastore를 사용하는 저희는 기능들을 도입하고 싶어도 도입하지 못하는 상황이었습니다. 제약 사항을 더 이상 방치할 수 없다고 생각하게 된 저희는 2024년 상반기 프로젝트로 ‘Unity Catalog 마이그레이션’을 계획하였고, 약 5개월간의 과정 끝에 데이터 팀의 Metastore를 Unity Catalog로 성공적으로 이전하였습니다!왜 Databricks는 Unity Catalog를 출시하였는가?Overview of Unity CatalogDatabricks의 테크 블로그에 기고된 “Understanding Unity Catalog”라는 아티클을 읽어보면, Unity Catalog를 개발하게 된 이유와 히스토리를 엿볼 수 있습니다. 아티클의 내용을 정리하면 아래와 같습니다.Databricks 사용자 중에 Multi-Workspace를 사용하는 경우가 종종 있었다고 합니다. 이 Workspace들은 하나의 데이터 소스에서 데이터를 읽고 사용했는데, 같은 Access Control을 Workspace 마다 반복 진행하는 게 번거로웠다고 합니다. 이것은 Hive Metastore가 Workspace 레벨로 존재하기 때문입니다.Hive Metastore의 경우, Schema 전체를 허용해 주거나 개별 Table을 일일이 허용해 주어야 했습니다. 이것은 새로운 테이블이 추가될 때마다 접근 정책을 변경해야 하는 번거로움이 있었습니다.S3와 같이 External Location에 접근하는 경우, 그 접근 권한이 Cluster의 Instance Pro

안녕하세요. 스튜디오 킹덤에서 쿠키런: 킹덤의 서버 개발자로 재직하고 있는 전윤재입니다. 이번 글에서는 스칼라로 개발된 쿠키런: 킹덤 서버의 빌드 속도를 개선하기 위해 수행했던 과정과 결과를 소개해 드리려 합니다.스칼라는 정교한 타입 시스템, 매크로, implicit과 같은 강력한 기능들을 제공하여, 더 안전하고 생산적인 코드를 작성할 수 있도록 합니다. 이러한 기능들은 프로그램의 안정성을 높이고, 복잡한 로직을 간결하게 표현할 수 있게 해줍니다. 하지만 공짜 점심은 없듯이 프로젝트의 규모가 커질수록 컴파일러에 전가된 많은 작업이 오히려 컴파일 속도를 저하해 개발 생산성을 떨어뜨리는 결과를 초래할 수 있습니다.쿠키런: 킹덤 서버는 국내에 몇 안 되는 스칼라 및 함수형 프로그래밍 패러다임을 적용한 서버로 Scala2로 작성되어 있으며 sbt로 빌드하고 있습니다. 시간이 흐르며 프로젝트의 규모가 커지다 보니 이에 따라 느려진 컴파일 속도로 인한 불편함을 저희도 체감하게 되었습니다.컴파일 속도를 저하하는 요인은 다양합니다. 이 글에서는 typeclass 를 활용할 때 빌드 성능 저하를 피하는 방법, 그리고 build pipelining 을 적용하기 위한 과정과 그 과정에서 경험한 트러블슈팅을 담았습니다.본론으로 들어가기에 앞서 내용 이해를 돕기 위해 컴파일러에 대한 간단한 설명을 드리겠습니다. 컴파일은 여러 단계로 이루어지는데 이를 페이즈(phase)라고 합니다. 스칼라 컴파일러에서 수행되는 여러 페이즈는 네 가지 카테 고리로 분류할 수 있습니다.• 프론트엔드(frontend) - 소스코드로부터 초기 구조를 생성하는 과정• parser - 소스 코드를 트리 형태로 변환 (타입 정보는 없음)• 그 외에 여러 페이즈 포함• 피클러(pickler) - 프론트엔드 단계에서 생성된 트리를 직렬화하여 저장하는 단계• 트랜스폼(transform) - 런타임에 적합한 로우레벨 형태로 변환 (패턴매치 변환, 타입 이레이저 등이 포함)• 백엔드(backend) - 최종적으로 바이트 코드를 생성하는 단계이 중 핵심적인 페이즈는 프론트엔드와 백엔드입니다. 프론트엔드 페이즈는 주로 코드를 분석하여 컴파일러가 이해할 수 있는 구조로 변환하는 데 집중하고, 백엔드 페이즈는 이러한 구조를 최종 실행 가능한 코드로 변환합니다.스칼라를 사용하다 보면 typeclass를 자주 접하게 됩니다. 이때 typeclass의 인스턴스를 어디에 정의하는지에 따라 컴파일 속도에 많은 영향이 있을 수 있습니다. 이는 컴파일러가 인스턴스를 검색할 때, 인스턴스의 정의된 위치에 따라 소요되는 시간이 다르기 때문입니다.위와 같은 typeclass가 있다 고 할 때 인스턴스를 정의하고 사용하는 방법은 대략 세 가지로 나눌 수 있습니다.• 별도 trait에 정의하고, 이를 extends해서 스코프로 가져오기• 별도 object에 정의하고, 이를 import해서 스코프로 가져오기세 가지 모두 유효한 방법이지만 빌드 속도에 유의미한 차이를 가져옵니다. 그러면 프로파일링 결과를 보면서 어떤 차이가 있는지