1. 새 버전 소식에서 먼저 확인할 것
2026년 9월 24일 PostgreSQL 19 Beta 4가 공개됐습니다. 정식 버전 출시가 아니라 시험 단계의 네 번째 베타입니다. 공식 발표는 일부 예정 기능을 되돌렸으며, 다음 출시 후보와 정식 공개 시점도 시험 결과에 따라 결정된다고 설명합니다. 새 기능 목록을 읽을 때는 “어느 버전의 어떤 시점에 확인한 정보인가”를 함께 기록해야 합니다.
학생 프로젝트에서는 최신 버전이라는 이유만으로 운영 데이터베이스를 바꾸기보다 별도 실험 환경에서 기존 질의가 같은 답을 내는지 확인하는 과정이 좋은 학습 과제가 됩니다. 이번 글의 실습은 가상 도서 대출 데이터를 이용한 버전 비교 설계입니다. 특정 버전이 더 빠르다는 결과를 제시하는 글이 아니라, 그런 결론을 내리려면 무엇을 측정해야 하는지 알아봅니다.
베타 테스트의 가치는 기능을 빨리 써 보는 데만 있지 않습니다. 이전에는 작동하던 조건이 새 환경에서 실패하는 회귀 문제를 찾고, 다른 사람이 재현할 수 있도록 설명하는 것도 중요합니다. 버튼을 눌렀을 때 화면이 열린다는 확인에서 한 걸음 더 나아가 결과, 오류, 자원 사용을 각각 살펴보세요.
2. SQL은 요청이고 실행 계획은 처리 방법이다
도서 대출 기록에서 특정 이용자의 최근 기록을 찾는다고 생각해 봅시다. SQL은 어떤 행과 열이 필요한지 표현합니다. 데이터베이스는 테이블을 읽고 조건을 확인하며 정렬하는 구체적인 방법을 선택합니다. 이 처리 방법을 실행 계획이라고 합니다. 같은 질문도 데이터의 양과 분포에 따라 적절한 방법이 달라질 수 있습니다.
PostgreSQL의 EXPLAIN은 선택한 계획을 보여 줍니다. 출력에 있는 cost는 밀리초가 아니라 계획을 비교하기 위한 추정 비용입니다. rows 역시 해당 단계가 내보낼 것으로 예상한 행 수이지, 읽은 전체 행 수가 아닙니다. 숫자 옆의 의미를 모르고 비용이 절반이니 속도도 두 배라고 설명하면 잘못된 해석이 됩니다.
처음에는 계획 전체를 외우기보다 데이터를 읽는 단계, 조건을 거르는 단계, 정렬하는 단계를 찾아보세요. 수업에서 그리는 순서도처럼 입력이 어디서 들어와 어떤 연산을 거쳐 결과가 되는지 설명하면 됩니다. 계획을 읽는 목적은 어려운 용어를 나열하는 것이 아니라, 시간을 쓸 만한 작업이 어디에 있는지 가설을 세우는 데 있습니다.
근거 자료 · PostgreSQL 18 · 실행 계획 읽기
3. 추정과 실제 측정, 서비스 응답은 다르다
EXPLAIN에 ANALYZE 옵션을 넣으면 문장이 실제로 실행됩니다. 따라서 변경 문장을 단순히 미리 보기 위한 기능으로 생각하면 안 됩니다. 아래 실습은 별도로 만든 데이터에서 SELECT만 대상으로 합니다. BUFFERS는 버퍼 사용 정보를, FORMAT JSON은 프로그램이 읽기 쉬운 출력을 제공합니다. 실행 계획의 결과와 사용자에게 돌아가는 실제 조회 결과는 구분해 저장합니다.
데이터베이스 안의 실행시간이 짧아도 서비스 전체가 빠르다는 결론은 아직 이릅니다. Java 서버의 연결 대기, 결과 변환, 네트워크 전송 등 다른 구간이 있기 때문입니다. 공식 EXPLAIN 문서도 네트워크 전송 비용은 이 명령으로 조사할 수 없다고 설명합니다. 그래서 실습에서는 데이터베이스 측정과 요청 시작부터 응답 완료까지의 시간을 별도로 기록하도록 제안합니다.
비교표의 세 질문은 서로 대체할 수 없습니다. 계획을 보고 병목을 추정하고, 실행을 측정해 가설을 확인하고, 마지막으로 사용자 요청 전체를 관찰하는 순서가 유용합니다. 한 지표가 좋아져도 다른 지표가 나빠질 수 있으므로 결과 보고서에는 측정 범위를 이름에 포함하세요.
| 관찰 대상 | 알아보려는 것 | 혼동하면 안 되는 것 |
|---|---|---|
| EXPLAIN 계획 | 어떤 처리 방법을 선택했는가 | 예상 비용을 실제 시간으로 해석 |
| 실제 SQL 실행 | 같은 조건에서 얼마나 걸렸는가 | 한 번의 결과를 일반적인 성능으로 해석 |
| API 요청 전체 | 사용자가 얼마 동안 기다렸는가 | 모든 지연을 데이터베이스 탓으로 해석 |
4. 가상 대출 데이터로 비교 조건 만들기
실습용 loans 테이블에 loan_id, member_id, borrowed_at, returned_at 열을 둡니다. Python으로 가상 기록을 만들되 생성 규칙과 난수 시드를 기록하세요. 두 환경에 서로 다른 파일을 넣으면 버전 차이가 아니라 데이터 차이를 비교하게 됩니다. 같은 파일의 해시와 행 수를 확인하는 절차를 실험 시작 조건으로 두면 좋습니다.
이용자별 대출 건수를 모두 같게 만들지 말고 기록이 적은 이용자와 많은 이용자를 함께 넣어 보세요. 조건에 맞는 행이 몇 개인지에 따라 처리 부담이 달라지는 상황을 관찰하기 위한 제안입니다. 총 1만 행과 10만 행은 연습용 규모의 예시일 뿐이며 성능 보장이나 실제 측정값이 아닙니다. PC 자원에 맞게 줄여 시작해도 됩니다.
아래 SQL은 해당 테이블을 만든 뒤 사용할 설계 예시이며 여기서 직접 실행한 결과는 아닙니다. 정렬 기준에 loan_id를 추가한 것은 대출 시각이 같은 행끼리도 결과 순서를 정하기 위해서입니다. 비교하려는 조회의 의미를 분명히 정해야 두 환경의 결과가 달라졌을 때 정상적인 순서 차이인지 오류인지 판단할 수 있습니다.
-- 가상 loans 테이블을 전제로 한 실습 설계 예시
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT loan_id, borrowed_at, returned_at
FROM loans
WHERE member_id = 42
ORDER BY borrowed_at DESC, loan_id DESC
LIMIT 20;5. 실험에서 한 번에 바꿀 것은 하나다
첫 비교에서는 데이터와 스키마, 인덱스, 자원 제한을 맞추고 데이터베이스 버전만 바꿔 보세요. 다음 비교에서는 버전을 고정하고 인덱스 유무를 바꿉니다. 새 버전 환경에만 인덱스를 추가한 뒤 빨라졌다고 보고하면 어느 변화가 원인인지 알기 어렵습니다. 실험 표에 고정한 조건과 변경한 조건을 먼저 적는 이유입니다.
각 조건은 한 번만 실행하지 말고 정한 횟수만큼 반복합니다. 예를 들어 예열 실행과 측정 실행을 구분하고 측정값 열 개를 그대로 보관하는 방식을 제안합니다. 중앙값뿐 아니라 최소·최대와 실패 횟수도 함께 보면 한 번의 긴 지연을 숨기지 않을 수 있습니다. 작은 표본으로 실제 서비스의 모든 사용 상황을 대표한다고 말하지는 마세요.
클라우드나 컨테이너 환경에서는 이미지 버전, CPU·메모리 제한, 다른 작업의 동시 실행 여부도 기록합니다. 같은 장비에서 두 환경을 동시에 시험하면 자원을 놓고 경쟁할 수 있습니다. 순서를 바꾸어 반복해 보는 것도 검토할 만합니다. 완전히 동일한 환경을 만들 수 없다면 차이가 남아 있다는 사실을 보고서에 적고 결론의 범위를 좁히면 됩니다.
6. 정확성을 확인한 뒤 AI에게 설명을 맡기기
속도 비교보다 먼저 두 환경의 조회 결과를 확인합니다. 정렬이 명시된 질의는 행 순서까지 비교하고, 순서가 의미 없는 질의는 중복 개수를 보존하는 방식으로 비교해야 합니다. 결과를 단순한 집합으로 바꾸면 중복 행이 사라져 오류를 놓칠 수 있습니다. NULL과 빈 문자열, 시간대가 다른 시각의 처리 기준도 테스트 사례에 넣으세요.
Python은 두 결과 파일을 비교하고 차이가 난 행을 정리하는 역할을 맡을 수 있습니다. SQL은 실험 기록을 보관하는 데도 사용할 수 있습니다. run_id, 버전, 데이터셋 식별자, 질의 식별자, 실행시간, 결과 일치 여부를 저장하면 같은 조건끼리 묶어 비교하기 쉽습니다. Java에서는 동일한 매개변수를 보내고 응답 완료까지 재는 작은 조회 API를 만들어 볼 수 있습니다.
AI를 활용한다면 가상 데이터의 측정표와 실행 계획을 주고 관찰 사실과 추가 확인이 필요한 가설을 나누어 설명하게 해 보세요. 모델이 cost를 밀리초로 바꾸거나 결과가 다른 질의를 성공으로 요약하면 수정 대상입니다. AI 설명의 품질은 문장의 자연스러움뿐 아니라 원래 수치, 단위, 실패 사례를 보존하는지로 평가합니다.
7. 결과물은 가장 빠른 숫자가 아니라 재현 가능한 보고서
팀별 제출물은 데이터 생성 규칙, 환경 정보, 질의 세 개, 반복 측정 원본, 결과 비교표, 실패 사례를 포함하도록 제안합니다. 질의는 단일 이용자 최근 기록, 미반납 건수 집계, 기간별 대출 집계처럼 서로 다른 작업을 고르세요. 일부 조회만 개선되었다면 그 조건을 제목에 넣고 모든 SQL이 빨라졌다고 확대하지 않습니다.
평가에서는 결과 일치 여부를 첫 관문으로 두고, 그다음 실행시간의 변화와 환경 통제 수준을 봅니다. 재현되지 않는 빠른 숫자보다 느려진 사례를 정확히 설명한 보고서가 더 유용할 수 있습니다. 베타에서 문제가 보이면 최소한의 데이터와 질의로 다시 재현해 원인을 좁히세요. 특정 라이브러리나 설정 문제일 가능성도 남겨 두어야 합니다.
이번 학습의 핵심은 새 버전의 기능 수를 외우는 것이 아닙니다. 변경을 도입하기 전에 질문을 정하고, 같은 조건에서 데이터를 모으며, 기대와 다른 결과까지 보존하는 개발 습관을 기르는 것입니다. 이 방식은 데이터베이스뿐 아니라 AI 모델 교체, Python 라이브러리 업데이트, 클라우드 환경 변경을 평가할 때도 응용할 수 있습니다.
학생이 이 이슈에서 확인할 것
- 베타 발표와 정식 출시를 구분할 수 있나요?
- cost와 실제 밀리초의 차이를 설명할 수 있나요?
- 결과의 중복·NULL·순서를 보존해 비교했나요?
- 고정 조건과 변경 조건을 기록했나요?
가상 대출 데이터와 질의 세 개로 두 환경의 결과 정확성과 반복 실행시간을 비교하세요. 가장 빠른 값만 고르지 말고 원본 측정값과 실패 사례, 실험의 한계를 제출하세요.
관심 기술을 대학의 프로젝트로 연결하세요.
전공의 학습 흐름을 이해하고 학생이 직접 만든 결과를 확인한 뒤, 자신에게 맞는 입학 계획을 세워 보세요.