트랜잭션 롤백 범위를 잘못 설계했던 경험
팀 프로젝트에서 주문과 결제를 하나의 트랜잭션으로 묶어 처리했는데, 외부 결제 연동에서 지연이 발생하면서 트랜잭션이 오래 유지돼 다른 요청까지 지연되는 문제를 겪었습니다. 원인을 분석해 결제 요청은 별도 트랜잭션으로 분리하고, 실패 시 보상 처리를 별도로 두는 방식으로 구조를 바꿨습니다. 이 경험으로 트랜잭션 범위를 무조건 넓게 잡는 것이 안전이 아니라 오히려 위험이 될 수 있다는 것을 배웠습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
팀 프로젝트에서 주문과 결제를 하나의 트랜잭션으로 묶어 처리했는데, 외부 결제 연동에서 지연이 발생하면서 트랜잭션이 오래 유지돼 다른 요청까지 지연되는 문제를 겪었습니다. 원인을 분석해 결제 요청은 별도 트랜잭션으로 분리하고, 실패 시 보상 처리를 별도로 두는 방식으로 구조를 바꿨습니다. 이 경험으로 트랜잭션 범위를 무조건 넓게 잡는 것이 안전이 아니라 오히려 위험이 될 수 있다는 것을 배웠습니다.
Java로 개발하다 팀 프로젝트에서 처음 Kotlin과 Spring Boot를 함께 사용하게 됐는데, null 안전성과 간결한 문법에 적응하는 데 시간이 걸렸습니다. 기존 Java 코드의 동작 방식을 먼저 이해한 뒤 Kotlin 문법으로 옮겨보는 방식으로 학습했고, 이 과정에서 null을 명시적으로 다루는 습관이 오히려 런타임 오류를 줄여준다는 것을 체감했습니다. 새로운 언어라도 기존 지식을 기반으로 차이점에 집중해 학습하는 것이 효율적이라고 느꼈습니다.
프로젝트를 마무리하며 부하 테스트를 진행했는데, 동시 요청이 늘어나자 특정 API에서 응답 시간이 급격히 늘어나는 것을 발견했습니다. 확인해보니 트랜잭션 안에서 불필요하게 외부 API를 호출하고 있었고, 이를 트랜잭션 밖으로 분리하니 처리 시간이 크게 줄었습니다. 기능 개발이 끝났다고 완성이 아니라, 실제 부하 상황에서 검증하는 과정까지가 개발이라는 것을 이 경험을 통해 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.