이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 수업 팀 프로젝트에서 Java와 Oracle DB를 연동해 주문 처리 시스템을 만드는 과제를 맡았습니다. 기능 자체는 빠르게 구현했는데, 테스트 도중 특정 조건에서 롤백이 안 되는 오류가 생겼습니다. 처음엔 로직 문제라고 생각해 코드를 반복해서 봤는데 원인을 못 찾았습니다. 나중에 알고 보니 커넥션 풀에서 받은 연결이 자동 커밋 모드로 열린 상태였고, 명시적으로 트랜잭션을 시작하지 않아서 중간 오류가 생겨도 롤백이 되지 않았습니다.
트랜잭션 설정을 코드에서 명시적으로 관리하도록 바꾼 뒤 문제가 해결됐습니다. 이후엔 DB 연결을 쓸 때 자동 커밋 여부를 항상 먼저 확인하는 습관이 생겼습니다. 처음엔 이 부분을 당연하다고 여겨서 확인하지 않았던 게 실수였습니다. 기본 설정을 믿지 말고 직접 확인하는 것이 중요하다는 걸 배웠습니다.
인턴 때 기존 시스템에서 특정 조회가 유독 느린 문제를 확인해달라는 요청을 받았습니다. 해당 쿼리를 실행해보니 데이터가 수십만 건인 테이블에서 풀 스캔이 일어나고 있었습니다. 처음엔 쿼리를 최적화하려고 조건 순서를 바꿔봤는데 차이가 없었습니다. 실행 계획을 확인하니 조회 조건으로 쓰는 컬럼에 인덱스가 없는 것이 원인이었습니다. 인덱스를 추가했더니 조회 시간이 12초에서 0.3초로 줄었습니다. 생각보다 극적인 차이여서 놀랐습니다. 이후엔 느린 쿼리를 볼 때 코드보다 실행 계획을 먼저 확인하는 순서로 바꿨습니다. 처음엔 쿼리 문법만 보다가 시간을 낭비한 게 아쉬웠는데, 그 경험이 DB 최적화를 접근하는 방식을 바꿔줬습니다.
졸업 프로젝트에서 Java로 만든 배치 프로그램이 시간이 지날수록 느려지는 문제가 생겼습니다. 처음엔 데이터가 늘어서 그런 줄 알았는데, 데이터 양에 비해 너무 빠르게 느려졌습니다. 메모리 사용량을 확인했더니 실행할수록 메모리가 계속 증가하는 것을 발견했습니다. 코드를 살펴보니 DB 연결을 열고 닫지 않는 부분이 있었습니다. 예외가 발생한 경우에 close()가 호출되지 않는 경로가 있었는데, 테스트 데이터에서는 예외가 잘 나지 않아 발견하지 못했습니다.
try-with-resources로 수정하니 자원 누수가 멈췄고, 장시간 실행해도 메모리가 안정적으로 유지됐습니다. 예외 경로에서 자원을 제대로 닫는 처리가 얼마나 중요한지 이 경험으로 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.