[유스콘] 유스콘 2022 후기

후 신청자가 200명이 넘어서 추첨으로 된 것 같다. 다행히 이번에는 당첨돼서 참여할 수 있었다.

같이 할수 있었던, Ader, 후 에게도 감사의 말을 전하고 싶다!

 

1. 진행 세션

이번 세션에서 기술 세션들에 관심이 많았다.

민규님의 introduce to clean Architecture를 시작으로

Java 17 vs Kotlin 1.7

Unit Test Puzzler

토비의 스프링 같이 읽기

Flyway 순으로 들을 생각이었다.

 

다만 중간에 망나니 개발자 님과 소통하는 시간이 잡혀서 Unit Test Puzzler은 듣지 못하게 되어 조금 아쉽다.

대신 ㅎㅎ 망나니 개발자 님과 대화를 나눌 수 있어서 좋았던 시간이다.

 

2. 한줄 세션 후기

기술 내용 정리보다는 기억에 남는 한 줄 요약!

들으면서 타이핑하면서 정리 하지는 않았기 때문에 기억력으로 적어본다... 나중에 영상이랑 자료가 유튜브로 공개되는 것으로 알고 있기에 듣기만 했다 ㅎㅎ

 

2 - 1) Introduce to clean Architecture

우리가 구글을 통해 검색을 하면 자주 나오시는 블로거 망나니 개발자님 께서 발표해 주셨다.

https://mangkyu.tistory.com/

MangKyu's Diary

아키텍처에서 중요한 것이 무엇인지?를 시작으로 이야기를 해주셨다.

 

과연 DB, 캐시, 프레임워크가 중요한가? → yes, 물론 중요는 하다!

하지만, 가장 중요한가??라고 묻는다면, 가장 중요하지는 않을 수 있다.

 

중요한 것은 핵심 비즈니스 로직과 유스케이스이다!

핵심 비즈니스는 시스템이 없어도 유효하며, 유스케이스는 시스템이 있어야만 가치가 있다.

 

이 외에도 SRP, 계층형 구조, 헥사고날 아키텍처등 여러 아키텍처를 설명해 주셨다.

 

가장 중요한 도메인과 덜 중요한 인프라 를 나눠 생각하자!

도메인은 세부사항에 의존해서는 안됨!

예를 들면 service에서 jdbc, jpa와 같은 특정 기술에 의존성을 가지면 좋지 못하다. 변경의 여파가 클 수 있다.

 

가장 중요한 것은 변경할 포인트가 많은 아키텍처가 중요하다.

 

2 - 2) Java 17 vs Kotlin 1.7

2 - 2 - 1: Record 타입

Record 타입이 기억에 남는다.

특히 개인적으로 내가 하는 프로젝트에서 DTO를 전부 Record 타입으로 처리 중이었기 때문에 더욱 이해가 되었다.

Data class로 사용하기에 매우 적절한 타입이라 적극 활용 중이다.

 

단, java의 record class는 field를 final로 지정된 점은 처음 알게 되었다.

 

여담이지만 Lombok의 @Builder가 현 Record 타입 이름 위에 바로 추가하면 먹히지 않는 중이다... 다음 코드를 살펴보자.

@Builder // 이렇게 사용하면 빌더가 안먹힘
public record PostLookupRequest(

        @NotBlank String userId,
        @NotBlank String postId,
        @NotNull Post post,
        @NotNull UserLookUpResponse findUser
) {
}

만약 필드가 많아진다면 static 메서드나, 생성자로 처리해야 하는 부분에 불편함이 조금 있다.

아니면 @Builder를 Record타입의 생성자를 만들고 생성자 위에 추가하면 되기는 하는데... 이러면 그냥 Class 쓰는 편이 좋다 생각된다...

 

2 - 2 - 2: Sealed classs

jdk17부터 공식지원하는 내용이다. 상속 및 구현 클래스를 명시적으로 지정할 수 있다는 장점이 있다.

sealed class Hero permits Batman, Superman, Spiderman {}

• 같은 패키지 내에서의 확장만 가능하다.
• 지정된 클래스에서는 final, sealed, non-sealed 중 하나를 필수적으로 선언

 

이 외에도 pattern matching for switch, instanceof를 통한 타입 캐스팅 등에 대하여 설명하여 주셨다!

 

2 - 3) 토비의 스프링 같이 읽기

여러분 DI 할 객체라면 무조건 Interface를 씁시다!!

굳이 꼭 써야 하냐고요?? 그냥 원래 이렇게 사용하도록 쓰게 돼 있다고 우기자고요! (다음 사진 속 본문과 같이 ㅋㅋ)

 

2 - 4) Flyway로 DB 형상 관리 시작하기

flyway는 DB 형상관리 오픈소스 툴이다. 즉, db schema가 변경이 발생할 때 flyway라는 툴로 관리를 할 수 있는 것이다.

약간 Git으로 소스 코드 관리하는 느낌이랄까? 신기한 기술인 것 같아 Hand-On 세션에 참여하여 실습을 수행하고 오니 대략적인 감이 오게 되었다.

 

flyway와 유사한 liquibase가 있다고 하셨는데, 사용의 편의성에서는 flyway가 더 좋다 하셨다.

다만 중간에 나온 질문인 "Cherry Pick 하듯 따와서 반영하고 싶다면?"에 대한 답은 flyway에서는 불가능하다 하셨다.

애당초 flyway는 선형적으로 스키마들을 관리하기 때문이다.

따라서 Cherry Pick처럼 반영하고 싶다면 liquibase를 사용하자!

 

다만 지금 프로젝트에 적용할지는 의문이다.

어느 정도 Schema가 고정되어 버린 애플리케이션이자, 큰 규모의 애플리케이션 이 아니기 때문에 당장은 적용할 기술적 이유는 없다 생각되었다.

 

다만, "큰 규모의 애플리케이션 이 아니기 때문"에 오히려 연습 겸 적용해보면 더 좋을 것 같다는 생각도 든다.

 

3. 망나니 개발자 님과의 대화시간

운이 좋아 망나니 개발자 님과 대화를 나누고 고민거리를 소통할 수 있었다.

실물 너무 잘생시신 망나니 개발자님!

개인적으로 다전공에 대한 고민이 엄청 많았는데, 이번 짧은 시간을 통해 방향성을 정할 수 있게 된 것 같아 너무 좋았다 ㅎㅎ

 

요즘 어느 학교든 컴공 다전공, 전과는 정말 힘들다.

내가 다니는 학교만 해도 학점 4.1은 넘어야 하며, 여러 포트폴리오를 들고 심사를 받아야 다전공, 전과가 가능한 상황이다...

그만큼 현 한국의 산업이 IT 쪽에 몰빵인 것은 부정할 수 없는 현실인 것 같다. 

어쩌면 나 또한 그러한 흐름의 한 명이기에 ㅎㅎ

 

여하튼 어렵게 성공한 다전공을, 이번 휴학을 하면서 개인적으로 꾸준히 학습을 하다 보니 꼭 필요한가? 란 생각을 하게 되었다...

자고 일어나면 하루에 한 번씩 다전공 포기 유무를 두고 왔다 갔다 하는 중이었는데...

 

이번에 망나니 개발자님과 30분 정도 소통을 하고 나니, 남은 학기의 방향을 정할 수 있게 되었다.

 

나랑 같이 공부했던 코드스쿼드 동료들이 하나, 둘 다 취업을 해가는 점에 있어 마음 한 편 불함이 있는 것은 사실이지만,

학교에서의 학습은 충분히 가치가 있다 생각된다.

너무 조급하게 취업전선에 뛰어들지 말고, 비록 조급할지언정 탄탄한 길로 멀리 돌아갈 생각이다.