이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Kotlin + Spring Boot 조합으로 REST API 서버를 처음 만들어봤습니다. 가장 도전적인 부분은 코루틴 기반 비동기 처리와 Spring의 Servlet 모델을 결합할 때 발생하는 스레드 컨텍스트 문제였습니다. @Transactional 안에서 코루틴을 쓰다가 트랜잭션이 롤백되지 않는 버그를 만났고, 코루틴이 다른 스레드에서 재개될 때 트랜잭션 컨텍스트가 끊기는 원인을 찾았습니다. 적합한 디스패처로 교체하고 트랜잭션 전파 설정을 명시적으로 지정해 해결했습니다. 이 과정에서 Kotlin 코루틴의 컨텍스트 전파 메커니즘을 깊이 이해하게 됐고, JVM 스레드 모델과의 경계를 의식하며 설계하는 습관이 생겼습니다.
Kotlin과 Spring Boot 프로젝트에서 또 다른 도전은 기존 Java 라이브러리와 Kotlin을 함께 쓰는 것이었습니다. Kotlin의 null safety는 컴파일 타임에 null 오류를 잡아주지만, Java 코드에서 반환된 값은 Kotlin이 null 여부를 보장할 수 없는 경우가 있었습니다. Java 메서드에 @Nullable 어노테이션이 없으면 Kotlin에서는 플랫폼 타입으로 처리돼, 런타임에 NullPointerException이 발생하는 문제를 겪었습니다. 경계 지점마다 requireNotNull()이나 ?.let {} 체인으로 명시적으로 처리하는 방식을 습관화했습니다.
Java와 Kotlin을 함께 쓸 때는 타입 시스템의 경계를 의식적으로 다루는 것이 안정성의 출발점이라는 것을 배웠습니다.
Kotlin을 쓰면서 data class와 불변 설계가 버그를 줄이는 데 생각보다 크게 기여한다는 것을 경험했습니다. Java에서는 DTO를 mutable하게 만들고 setter로 값을 채우는 방식이 익숙했는데, Kotlin에서는 생성자에 모든 값을 넣고 `val`로 선언하는 방식이 자연스럽게 됐습니다. 불변 객체는 여러 스레드에서 공유해도 상태가 바뀌지 않는다는 것을 보장하기 때문에, 병렬 처리 코드에서 상태 오염 문제가 생길 가능성이 줄었습니다.
copy() 메서드로 일부 값만 바꾼 새 객체를 만드는 방식이 처음에는 어색했는데, 원본을 보존하면서 변환할 수 있다는 것이 오히려 안전하다는 것을 알게 됐습니다. 언어가 불변성을 기본으로 유도하는 방향이 버그를 설계 단계에서 줄이는 방법이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.