Kotlin 리드·아키텍트 기술면접

대규모 이커머스에서는 Saga 패턴의 Choreography 또는 Orchestration 방식을 권장합니다. 2PC는 강한 일관성을 보장하지만 코디네이터 장애 시 전체 시스템이 블로킹되고, 분산 환경에서 성능 저하가 심합니다. Saga는 최종 일관성(Eventual Consistency)을 제공하며, 각 서비스가 로컬 트랜잭션과 보상 트랜잭션을 실행합니다. Kotlin Coroutine과 Flow를 활용해 비동기 이벤트 처리를 구현하고, 각 단계별 상태를 Event Sourcing으로 저장하여 장애 시 복구 가능하도록 설계합니다. 멱등성 보장을 위해 각 요청에 고유 ID를 부여하고, 보상 트랜잭션은 반드시 실패하지 않도록 재시도 로직을 포함시킵니다.

inline 함수는 컴파일 시점에 함수 호출부를 함수 본문으로 치환하여 함수 호출 오버헤드를 제거합니다. 특히 고차함수를 인자로 받을 때 람다가 별도 객체로 생성되는 것을 방지해 성능을 향상시킵니다. reified 키워드는 inline 함수에서만 사용 가능하며, 런타임에 타입 정보를 유지하여 제네릭 타입 소거 문제를 해결합니다. 예를 들어 JSON 파싱 라이브러리에서 타입 안전하게 객체를 변환할 때 활용됩니다. 제약사항으로는 inline 함수는 재귀 호출이 불가하고, 코드 크기가 증가할 수 있어 큰 함수에는 부적합하며, private 멤버 접근이 제한됩니다. 실무에서는 DSL 빌더, 리소스 관리(use 함수), 타입 안전한 API 설계에 주로 활용합니다.

먼저 VisualVM이나 MAT로 Heap Dump를 분석하여 어떤 Coroutine Context가 GC되지 않는지 참조 체인을 추적합니다. 주요 원인은 GlobalScope 사용으로 인한 Coroutine 누수, Job 취소 미처리, 또는 긴 수명의 CoroutineScope에서 무한 루프 실행입니다. 코드 검토를 통해 GlobalScope 대신 CoroutineScope를 명시적으로 관리하고, 구조화된 동시성 원칙에 따라 부모-자식 관계를 설정합니다. supervisorScope나 coroutineScope를 사용해 예외 발생 시 적절히 취소되도록 하고, 장기 실행 작업에는 withTimeout을 적용합니다. 또한 애플리케이션 종료 시 CoroutineScope.cancel()을 호출하여 모든 Coroutine을 정리하고, 모니터링 메트릭에 활성 Coroutine 수를 추가하여 지속적으로 관찰합니다.

JPA/Hibernate는 객체-관계 매핑을 자동화하여 도메인 모델 중심 설계가 가능하지만, N+1 문제, 지연 로딩 이슈, 복잡한 쿼리 최적화의 어려움이 있습니다. Exposed나 jOOQ는 SQL을 타입 세이프하게 직접 작성하여 쿼리 제어가 정밀하고 성능 튜닝이 용이하지만, 보일러플레이트 코드가 증가하고 도메인 로직과 영속성 로직이 혼재될 수 있습니다. 복잡한 비즈니스 로직과 풍부한 도메인 모델이 필요한 경우 JPA를 선택하되, Kotlin의 data class와 sealed class를 활용해 불변성을 유지합니다. 반면 대량 데이터 처리, 복잡한 조인, 성능이 중요한 경우 Exposed나 jOOQ를 사용하며, Kotlin DSL의 표현력을 활용해 가독성을 높입니다. 실무에서는 CQRS 패턴으로 명령과 조회를 분리하여 각각 JPA와 쿼리 빌더를 혼용하는 방식도 효과적입니다.

먼저 비즈니스 영향도와 기술 부채를 분석하여 전환 우선순위를 정합니다. Strangler Fig 패턴으로 새로운 기능은 Kotlin으로 개발하고, 기존 모듈은 점진적으로 교체합니다. Java-Kotlin 상호운용성을 활용해 두 언어가 공존하는 하이브리드 상태를 유지하며, 유틸리티와 DTO부터 시작해 점차 비즈니스 로직으로 확대합니다. 각 전환 단계마다 충분한 테스트 커버리지를 확보하고, Feature Toggle로 배포 리스크를 최소화합니다. 팀 교육을 위해 Kotlin 코딩 컨벤션과 Best Practice를 문서화하고, 페어 프로그래밍과 코드 리뷰를 강화합니다. Null Safety와 Coroutine 도입으로 인한 아키텍처 변화는 별도 스파이크를 통해 검증하고, 성능 벤치마크를 지속적으로 모니터링합니다. 롤백 계획과 장애 대응 시나리오를 사전에 준비하여 비즈니스 연속성을 보장합니다.

먼저 프로파일링으로 병목 지점을 식별합니다. CPU 집약적 작업은 Dispatchers.Default로, IO 작업은 Dispatchers.IO로 분리하고, 커스텀 Dispatcher로 스레드 풀을 조정합니다. Flow의 buffer() 연산자로 생산자-소비자 속도 차이를 흡수하되, 메모리 사용량을 모니터링하며 적절한 버퍼 크기를 설정합니다. 모든 이벤트 처리가 필요하면 buffer()를, 최신 값만 필요하면 conflate()나 collectLatest()를 사용해 백프레셔를 관리합니다. 배치 처리를 위해 chunked()로 이벤트를 묶어 DB 쓰기 횟수를 줄이고, flowOn()으로 각 처리 단계의 컨텍스트를 분리하여 병렬성을 높입니다. SharedFlow를 사용해 여러 구독자가 효율적으로 이벤트를 소비하도록 하고, 메트릭 수집으로 처리량과 지연시간을 지속적으로 모니터링합니다.

효과적인 답변은 Situation(상황), Task(과제), Action(행동), Result(결과) 구조로 구성되어야 합니다. 상황 설명에서는 당시 프로젝트 맥락과 왜 Kotlin 도입이 필요했는지 배경을 제시하세요. 과제 부분에서는 팀원들의 구체적인 반대 이유(학습 곡선, 레거시 호환성, 생산성 저하 우려 등)를 명확히 하세요. 행동 단계에서는 데이터 기반 설득(벤치마크, PoC 결과), 점진적 도입 계획, 교육 프로그램 마련, 정기적인 회고를 통한 피드백 수렴 등 구체적인 액션을 설명하세요. 결과에서는 정량적 성과(생산성 향상, 버그 감소율)와 정성적 변화(팀 만족도, 기술 역량 향상)를 모두 언급하세요. 중요한 것은 일방적 추진이 아닌 팀원들의 우려를 경청하고 함께 해결책을 찾아가는 협업적 리더십을 보여주는 것입니다.