이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 월별 정산 배치 로직을 Stored Procedure로 작성하는 과제를 맡았습니다. 처음에는 애플리케이션 레이어에서 루프로 돌렸더니 실행 시간이 40분을 넘겼고, SP로 이전해 집합 연산 기반 쿼리로 재작성하니 같은 작업이 3분 이내로 줄었습니다. 트랜잭션 분리 수준과 예외 처리 블록(BEGIN...EXCEPTION...END)을 명시적으로 설정하는 패턴도 이때 익혔습니다. 이후 SP 디버깅이 일반 코드보다 어렵다는 점을 실감했고, 중간 결과를 임시 테이블에 기록해 실행 흐름을 추적하는 습관을 만들었습니다. 성능 문제는 로직 구조를 바꾸는 것만으로도 수십 배 차이가 날 수 있다는 것을 이 경험에서 처음 몸으로 배웠습니다.
Stored Procedure를 작성하면서 여러 테이블을 동시에 업데이트할 때 교착이 발생하는 상황을 경험했습니다. 두 개의 배치 SP가 서로 다른 순서로 같은 테이블에 접근하다 서로 상대방의 잠금을 기다리며 둘 다 멈추는 교착이 생겼습니다. DEADLOCK GRAPH를 SSMS에서 확인해 어느 테이블에서 잠금 충돌이 발생했는지 파악했습니다. 테이블 접근 순서를 두 SP에서 동일하게 맞추니 교착이 재현되지 않았습니다.
SP는 단독으로 봤을 때는 문제가 없어 보여도, 동시에 실행되는 다른 SP와의 잠금 관계를 의식해서 설계해야 한다는 것을 이 경험으로 배웠습니다.
레거시 시스템에서 오래된 Stored Procedure를 ORM 기반 레이어로 이관하는 작업을 맡은 적이 있습니다. SP는 복잡한 집합 연산을 DB에서 처리하기 때문에 성능이 좋았는데, ORM으로 옮기면 같은 로직을 애플리케이션 레이어에서 처리하면서 N+1 문제가 생기거나 쿼리 최적화 여지가 줄어드는 경우를 겪었습니다. 복잡한 배치 집계는 SP로 두고, 단순 CRUD 위주 로직은 ORM으로 이관하는 방식으로 경계를 나눴습니다.
네이티브 쿼리를 ORM과 혼합하는 방식도 검토했는데, 유지보수 시 어느 경로로 동작하는지 추적이 어려워지는 단점이 있었습니다. SP와 ORM 중 하나를 선택하는 것보다 어디에 무엇을 쓸지 경계를 명확히 하는 것이 중요하다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.