코프링 프로젝트 투입 일주일 전: 주니어 개발자의 코틀린 도입 이야기 | 인프콘2023

인프런 inflearn·인프콘 2023 2023·2023년·

#kotlin#spring-boot#testing#backend#webflux#team-communication#technology-adoption

AI 요약

Java·Spring 팀이 새 프로젝트에 Kotlin을 도입한 과정을, 주니어 개발자가 6개월간 학습·POC·공유로 신뢰를 쌓아 기술 제안을 현실화한 이야기로 풀어낸다. 도입은 언어 자체보다 팀 설득과 책임의 문제임을 보여준다.

핵심 포인트

Kotlin Koans·공식 문서·Effective Kotlin에 Android 팀 코드까지 읽어 취향이 아닌 검증 가능한 근거(JVM·Spring 호환성, 커뮤니티, IntelliJ 지원)로 제안을 준비
WebFlux는 전 구간 반응형 요구와 MySQL R2DBC 성숙도·장애 대응 경험 부족, 높은 처리량 요구 부재로 제외하고 MVC 유지 — 표현력 있는 Kotest와 final 클래스 모킹에 적합한 MockK 선택으로 새 기술 범위를 통제
기본 final 클래스를 Spring 프록시가 상속하도록 all-open, JPA엔 기본 생성자용 no-arg, Spring Boot 3의 Jakarta 차이까지 맞추는 빌드 설정과 Kotlin Logging·ktlint·Fixture Monkey 같은 도구 소개
느린 IDE 분석, scope function 남용, nullable·Optional 혼용 등 사전 합의가 필요한 함정을 POC로 검증하고, 시니어 검증 부담을 줄이며 모든 걸 한꺼번에 바꾸지 않는 태도로 도입 성사

왜 읽나기존 스택 팀에 코프링 같은 새 기술을 조심스럽게 도입하려는, 특히 설득과 준비 과정 자체를 성장 자산으로 삼으려는 개발자에게.

챕터별 상세

010:06 – 7:25

Kotlin을 선택하기 전 쌓은 학습 기반

Kotlin 도입을 회의적으로 보던 주니어 개발자가 언어와 생태계를 직접 익히며 새 프로젝트의 기술 선택을 준비한 과정을 소개한다. Kotlin Koans, 공식 문서와 Effective Kotlin을 따라 문법과 관용구를 익히고 Android 팀의 글과 라이브러리 소스까지 읽어 실제 사용 방식을 확인한다. JVM·Spring과의 호환성, 활발한 커뮤니티와 IntelliJ 지원을 근거로 취향이 아닌 검증 가능한 도입 제안을 만들기 시작한다.

Java·Spring·MySQL을 쓰던 팀은 JVM과 기존 프레임워크 지식을 유지할 수 있고 사전 학습 경험도 있어 새 프로젝트에 Kotlin을 받아들인다. 반면 WebFlux는 전체 경로가 반응형이어야 하고 당시 MySQL R2DBC의 성숙도와 팀의 장애 대응 경험이 부족했으며 높은 처리량 요구도 없어 MVC를 유지한다. Spring Data JPA를 기반으로 표현력 있는 Kotest와 final 클래스 모킹에 적합한 MockK를 선택해 새로운 기술의 범위를 통제한다.

애플리케이션 코드는 기존 Spring 방식과 비슷하지만 빌드에는 Kotlin JVM, 어노테이션 처리를 위한 KAPT와 프레임워크별 보완 플러그인이 필요하다. 기본적으로 final인 클래스를 Spring 프록시가 상속할 수 있게 all-open 계열 플러그인을 쓰고, JPA에는 기본 생성자를 만드는 no-arg 설정과 대상 어노테이션을 추가한다. Spring Boot 3의 Jakarta 패키지 차이까지 맞추면 컨트롤러·엔티티·테스트는 익숙한 구조를 유지하면서 Kotlin 문법의 이점을 사용할 수 있다.

Kotlin Logging은 SLF4J 스타일을 간결하게 제공하고 필요한 로그 레벨에서만 람다를 평가해 기존 Spring Boot 로깅 구현체와 자연스럽게 연결된다. RefreshVersions로 의존성 버전을 한곳에서 확인·갱신하고 ktlint Gradle 플러그인과 Git hook으로 코드 스타일을 빌드·커밋 단계에서 강제할 수 있다. Fixture Monkey는 필요한 필드만 지정하고 나머지를 생성해 주어 복잡한 테스트 객체 준비 비용을 줄이며 Kotlin용 스타터도 제공한다.

도입 전에는 느린 IDE 분석, 다양한 코드 스타일과 scope function 남용, nullable과 Optional 혼용, Kotest의 성능·기능 공백과 JPA 작성 방식처럼 팀 합의가 필요한 지점을 검증해야 한다. 발표자는 프로젝트 시작 6개월 전부터 다른 팀의 Kotlin 코드를 읽고 API와 POC를 만들며 자료·위키·라이브 코딩으로 학습 내용을 반복해서 공유했다. 시니어의 검증 부담을 줄이고 모든 기술을 한꺼번에 바꾸지 않는 태도로 신뢰를 얻어 Kotlin과 Spring Boot 3 도입을 성사시켰으며, 제안이 거절돼도 준비 과정 자체가 성장 자산이 된다고 말한다.