donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
main
llm-wiki/raw/interviews/native-query-addscalar-runtime-validation.md
T

6.0 KiB
Raw Permalink Blame History

title, source_type, status, related_branches, related_projects, tags, created, status_label
title source_type status related_branches related_projects tags created status_label
interview-prep / native-query-addscalar-runtime-validation interview-prep raw
experiment-nplus1-feed-api-replay
ca-skeleton
interview-prep
ca-skeleton
persistence
testing
hibernate
postgresql
static-analysis
2026-07-15 drafting

interview-prep: native-query-addscalar-runtime-validation

Layer: raw/interviews/ — 면접 질문 원본 수집·연구 노트입니다. 다듬어진 답변은 canonical 문서를 만든 뒤 wiki/interview/에 별도로 작성합니다.

Parent / 부모

질문 / Question

  • 질문 원문: Hibernate native query에서 addScalar를 썼는데도 SQL 문법이나 table/column 이름 오류를 Java compile-time에 잡을 수 없는 이유는 무엇이며, 어떤 검증으로 보완하셨습니까?
  • 출처: N+1 replay의 L12 native child projection을 설명할 때 예상한 면접 질문입니다.
  • 받은 날짜·맥락: 실제 면접에서 받은 질문은 아닙니다.

질문 의도 추론 / Why this question

  • 핵심 평가 대상: Java 타입 검증, ORM 결과 mapping, database SQL 실행 검증의 경계를 구분하는지 평가합니다.
  • 함정 / 흔히 빠지는 답변 패턴: addScalar가 SQL parser나 schema checker라고 설명하거나, Java compilation만으로 native SQL의 table/column 오류까지 검증됐다고 말하는 답변입니다.
  • 따라올 만한 후속 질문: 결과 컬럼의 runtime type이 맞지 않으면 어디서 실패하나요? Testcontainers만으로 query plan이나 production latency까지 말할 수 있나요?

답변 재료 / Raw answer material

  • 사실 1: 이 작업에서 addScalar는 native-query result extraction의 runtime type mapping으로 다뤘습니다. SQL 문자열의 문법, table/column 이름, query plan을 Java compiler가 검증하는 기능은 아닙니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay D5, §3 Crown과 L12의 의도적 차이)
  • 사실 2: addScalar type이 실제 결과와 맞지 않거나 native SQL이 잘못되면 Java compile이 아니라 integration/runtime 실행에서 실패합니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay §엣지·실패·의존)
  • 사실 3: 보완 수단으로 FeedReadModelUseCaseIT를 포함한 focused Gradle integration suite와 fresh Docker Compose PostgreSQL HTTP/SQL-row-count smoke를 수행했습니다. 이는 실제 PostgreSQL에서 query를 실행하는 검증입니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay D4, §검증 기록)
  • 프로젝트 작업에서 확인한 경험: L12 native child mapping을 addScalar로 실행했고, final L12 Docker smoke에서 reset, Crown feed, read-model response, invalid page HTTP 400, marker row count를 local 환경에서 확인한 기록이 있습니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay §Docker HTTP + PostgreSQL smoke — final L12 tag)
  • 트레이드오프: 이 작업의 선택은 Java compiler가 확인할 수 있는 코드 오류와 실제 PostgreSQL 실행이 확인할 native SQL 오류를 분리하는 방식입니다. addScalar만으로 검증 범위를 넓힌다는 선택은 채택하지 않았습니다. 업계 다수파·소수파에 대한 일반화는 이 raw note의 근거 범위 밖입니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay D5)
  • 한계 / "이건 안 해봤다": 실행한 test case와 fixture가 덮지 않은 SQL branch, representative production data에서의 query plan, latency SLA는 이 검증만으로 판단하지 않았습니다. (근거: raw/branch-notes/experiment-nplus1-feed-api-replay §Out of scope, §검증해야 할 주장)

Sources / 근거 (답변의 사실 근거)

미해결 / Unknown

  • PostgreSQL version, migration 순서, 실제 데이터량이 달라질 때 모든 native SQL path가 계속 유효한지는 별도 검증이 필요합니다.
  • addScalar mapping 변경이 API response contract에 미치는 영향은 fixture 기반 integration test만으로 모두 포괄했다고 말할 수 없습니다.
  • 확인 방법: relevant migration을 적용한 PostgreSQL에서 각 native-query endpoint와 FeedReadModelUseCaseIT를 실행하고, representative data에서는 EXPLAIN (ANALYZE, BUFFERS)와 별도 load test를 수행합니다.

답변 경계 / Answer boundary

  • 자신 있게 말할 수 있는 범위: 이 repository의 L12 native query에 대해 addScalar가 runtime 결과 mapping이고, 실제 PostgreSQL integration/runtime 실행으로 오류를 발견하도록 검증했다는 local evidence 범위입니다.
  • "이 부분은 공식 문서를 다시 보고 답변드리겠습니다" 라고 해야 하는 부분: Hibernate version별 API 세부사항, 다른 database vendor의 type coercion, 모든 SQL path의 coverage와 production query plan입니다.
  • 절대 과장하지 말 것: addScalar가 SQL syntax/schema를 compile-time에 검증한다고 말하지 않습니다. Testcontainers 결과를 모든 production data와 latency의 검증으로 말하지 않습니다. 한 번의 integration test가 native SQL의 모든 오류를 찾는다고 말하지 않습니다.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink