이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트에서 Kotlin + Spring Boot 기반 REST API를 처음 구현했습니다. 자바 배경이 있어 언어 자체는 빠르게 익혔지만, 코루틴 기반 비동기 처리가 처음에는 낯설었습니다. 기존 블로킹 방식으로 구현하니 DB 조회가 많은 엔드포인트에서 응답이 느렸고, suspend function으로 전환하자 처리량이 개선됐습니다. 테스트에서는 MockK를 처음 써봤는데, Kotlin의 final 클래스 특성 때문에 처음에는 모킹이 안 돼 설정을 찾아야 했습니다.
Spring Boot 자동 설정의 편리함과 그로 인해 내부 동작을 모를 때 생기는 디버깅 어려움을 동시에 경험했고, 프레임워크를 쓸 때는 설정 원리를 함께 이해하는 것이 중요하다는 결을 배웠습니다.
Kotlin 코루틴 전환이 실제로 효과가 있었는지를 간단한 부하 테스트로 확인했습니다. 블로킹 방식과 suspend function 방식을 각각 적용한 엔드포인트에 동시 요청을 보내면서 응답 시간을 비교했는데, 동시 요청 수가 늘어날수록 비동기 방식의 응답 시간이 더 안정적으로 유지됐습니다.
이 결과에서 비동기가 빠른 것이 아니라 처리량 증가 상황에서 더 안정적이라는 것을 직접 확인했습니다. 블로킹 방식은 스레드가 대기하는 동안 다른 요청을 처리하지 못하는 한계가 있었고, 코루틴은 그 대기 시간을 다른 작업에 활용할 수 있었습니다.
기술 도입에서 결과를 확인하는 것이 중요한 이유는 이론적으로 좋은 것과 실제로 내 코드에서 효과가 있는 것이 다를 수 있기 때문입니다. 직접 측정해서 확인한 결과가 기술 선택의 근거가 된다고 생각합니다.
Spring Boot를 처음 쓸 때 자동 설정이 편리하다는 것은 알았지만, 문제가 생겼을 때 어디서 설정이 적용됐는지를 찾는 것이 어려웠습니다. 빈 이름 충돌로 애플리케이션이 시작되지 않는 오류가 생겼는데, 자동 설정과 수동 설정이 어떻게 우선순위가 결정되는지를 몰라서 원인을 찾는 데 시간이 오래 걸렸습니다.
이 경험 이후 Spring Boot의 자동 설정 조건(@ConditionalOn 계열)과 Bean 등록 우선순위를 찾아 공부했습니다. 설정 원리를 이해하고 나서는 유사한 오류에서 원인을 더 빠르게 파악할 수 있었습니다.
프레임워크를 사용할 때 배운 것은 편리한 기능일수록 내부 동작을 이해하는 것이 디버깅 역량을 만든다는 점입니다. 문제가 없을 때는 몰라도 되지만, 문제가 생겼을 때 내부를 이해하는 것이 해결 속도를 결정합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.