[SOU-421] 프로덕션 서버 무중단 배포 구현

[bum0w0]

Summary by CodeRabbit

릴리스 노트

• New Features

  • Blue/Green 배포 전략 구현으로 무중단 배포 지원

• Bug Fixes

  • 데이터베이스 스키마 초기화 안정성 개선

• Chores

  • 프로덕션 배포 워크플로우 자동화
  • 프로덕션 환경에서 Docker Compose 비활성화

[coderabbitai]

Walkthrough

프로덕션 배포 파이프라인을 자동화하도록 CI/CD 워크플로우를 수정하고, 블루/그린 배포 메커니즘을 구현하는 새로운 배포 스크립트를 추가하며, 프로덕션 환경에서 Docker Compose를 비활성화하고 데이터베이스 마이그레이션을 안전화합니다.

Changes

Cohort / File(s)	Summary
CI/CD 워크플로우 .github/workflows/prod-cicd.yaml	워크플로우 트리거를 workflow_dispatch에서 main 브랜치의 pull_request 및 push로 변경하여 자동 실행을 활성화합니다. NCP_* 보안 비밀들을 배포 환경으로 전파하고 deploy/prod/.env 파일에 작성합니다.
배포 스크립트 deploy/prod/scripts/deploy.sh	블루/그린 배포를 구현하는 새로운 Bash 스크립트를 추가합니다. 프라이빗 레지스트리에서 이미지를 가져오고, nginx 업스트림 설정을 확인한 후 활성 포트를 파악합니다. 대상 Docker Compose 프로젝트를 배포하고 헬스 체크를 수행한 후, 성공 시 nginx 트래픽을 전환하고 이전 배포를 중지합니다.
프로덕션 설정 src/main/resources/application-prod.yaml	spring.docker.compose.enabled를 false로 설정하여 프로덕션 환경에서 Docker Compose 사용을 비활성화합니다.
데이터베이스 마이그레이션 src/main/resources/db/migration/V1__init_schema.sql	CREATE SCHEMA를 CREATE SCHEMA IF NOT EXISTS로 변경하여 안전성을 향상시킵니다. 스키마 및 확장 프로그램의 소유권 변경과 주석 처리를 제거합니다.

Sequence Diagram(s)

sequenceDiagram
    participant GHA as GitHub Actions
    participant Reg as Docker Registry
    participant Docker as Docker Engine
    participant HC as Health Check
    participant Nginx as Nginx
    participant Old as Old Container

    GHA->>Reg: Pull latest image
    Reg-->>GHA: Image pulled
    GHA->>Docker: Validate image
    Docker-->>GHA: Image valid
    GHA->>Nginx: Read current upstream config
    Nginx-->>GHA: Active port info
    GHA->>Docker: Select blue/green target port
    Docker-->>GHA: Target port assigned
    GHA->>Docker: Pull and start Docker Compose<br/>on target port
    Docker-->>GHA: Container running
    GHA->>HC: Health check loop (with retries)
    HC-->>GHA: Target port healthy
    GHA->>Nginx: Update upstream to<br/>route traffic to new target
    Nginx-->>GHA: Upstream updated
    GHA->>Old: Stop previous container
    Old-->>GHA: Container stopped
    GHA->>Docker: Prune unused images
    Docker-->>GHA: Cleanup complete
    GHA-->>GHA: Deployment successful

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 분

Possibly related PRs

• [SOU-420] blue/green docker-compose 구성 추가 #209: 메인 PR의 새로운 프로덕션 배포 스크립트와 워크플로우 변경이 추출된 PR에서 추가된 블루/그린 docker-compose 파일에 직접 의존합니다.
• [NO-ISSUE] 개발환경에선 도커 컴포즈 비활성화 #191: 두 PR이 모두 동일한 설정 속성(spring.docker.compose.enabled = false)을 서로 다른 프로필 YAML(prod vs dev)에 추가합니다.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 풀 리퀘스트의 주요 변경사항인 프로덕션 서버의 무중단 배포 구현을 명확하게 요약하고 있습니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/SOU-421-prod-script

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8ec3d6eb87

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

최초 배포에서 upstream 파일 부재를 허용하라

현재 스크립트는 upstream-souzip.conf가 없으면 즉시 종료하기 때문에, 바로 아래에 있는 "최초 배포(upstream 없음)" 분기로 도달하지 못합니다. 신규 서버 프로비저닝 직후나 nginx 설정 파일이 아직 생성되지 않은 환경에서는 blue/green 첫 배포가 항상 실패해 배포 파이프라인이 막히므로, 파일이 없을 때 기본 upstream 파일을 생성하거나 초기값으로 진행할 수 있게 처리해야 합니다.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Flyway에서 PostGIS extension 생성을 보장하라

이 변경으로 V1 마이그레이션이 postgis extension을 생성하지 않게 되었는데, 애플리케이션은 거리 검색에서 ST_DWithin/ST_Distance 같은 PostGIS 함수를 사용합니다(SouvenirRepository native query). 따라서 새 DB를 V1부터 올리는 환경(신규 prod/stage 또는 ephemeral test DB)에서는 extension이 사전 설치되지 않으면 해당 기능이 function does not exist로 런타임 실패할 수 있어, 마이그레이션에서 extension 보장을 유지하거나 별도 선행 마이그레이션으로 명확히 분리해야 합니다.

Useful? React with 👍 / 👎.

[coderabbitai]

Actionable comments posted: 4

🧹 Nitpick comments (1)

deploy/prod/scripts/deploy.sh (1)

112-119: nginx 설정 파일 무백업 덮어쓰기로 인한 복구 불가능한 상태 발생 위험

현재 코드는 nginx -t 또는 nginx -s reload 실패 시 원본 설정을 복구할 방법이 없습니다. 설정 변경 전 백업을 생성하고, 각 단계의 성공 여부를 검증한 후 실패 시 자동 복구하는 절차가 필요합니다.

🔧 제안 수정안

+BACKUP_FILE="$(mktemp)"
+sudo cp "$NGINX_UPSTREAM_FILE" "$BACKUP_FILE"
+
 sudo tee "$NGINX_UPSTREAM_FILE" > /dev/null <<EOF
 upstream souzip {
     server 127.0.0.1:${TARGET_PORT};
 }
 EOF
 
-sudo nginx -t
-sudo nginx -s reload
+if ! sudo nginx -t; then
+  echo -e "${RED}[ERROR] nginx 설정 검증 실패, 이전 설정으로 복구합니다.${NC}"
+  sudo cp "$BACKUP_FILE" "$NGINX_UPSTREAM_FILE"
+  exit 1
+fi
+
+if ! sudo nginx -s reload; then
+  echo -e "${RED}[ERROR] nginx 리로드 실패, 이전 설정으로 복구합니다.${NC}"
+  sudo cp "$BACKUP_FILE" "$NGINX_UPSTREAM_FILE"
+  exit 1
+fi
+
+rm -f "$BACKUP_FILE"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deploy/prod/scripts/deploy.sh` around lines 112 - 119, Before overwriting
NGINX_UPSTREAM_FILE, create a timestamped backup (or tmp copy) of the current
file, then write the new upstream (using TARGET_PORT) to a temp file and
atomically move it into place only after nginx -t succeeds; if nginx -t or nginx
-s reload fails, restore the backup and log the error. Concretely: back up
NGINX_UPSTREAM_FILE, write new content to a temp path, run sudo nginx -t against
the new file, if the test passes move the temp into NGINX_UPSTREAM_FILE and run
sudo nginx -s reload, otherwise restore the backup and abort with a clear error
message; ensure all steps check exit codes and clean up temp files.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/prod-cicd.yaml:
- Around line 4-9: The workflow is missing a workflow-level concurrency setting,
so multiple pushes can trigger overlapping runs and cause concurrent execution
of the deploy job (risking blue/green and nginx race conditions); add a
top-level concurrency stanza to the workflow (e.g., concurrency: { group:
"deploy-${{ github.ref }}", cancel-in-progress: true }) to serialize runs for
the same branch/ref and ensure the existing deploy job is executed one at a
time.

In `@deploy/prod/scripts/deploy.sh`:
- Around line 11-13: The hardcoded WORK_DIR (and DEPLOY_DIR) in deploy.sh causes
mismatches with the workflow's /home/${{ secrets.GCP_PROD_USER }}/souzip path;
change deploy.sh to compute paths relative to the script location instead of a
fixed user folder by deriving the script directory (e.g., from $0) and setting
WORK_DIR based on that directory, then set DEPLOY_DIR relative to WORK_DIR so
the script works regardless of GCP_PROD_USER or the home path.
- Around line 9-34: The script currently hardcodes :latest which breaks
reproducible deploys; introduce an IMAGE_TAG variable (default from env or CI)
and replace all uses of :latest so docker pull ${REGISTRY}:${IMAGE_TAG} is used,
update NEW_IMAGE to query ${REGISTRY}:${IMAGE_TAG}, and change
docker-compose.blue.yaml and docker-compose.green.yaml image fields to reference
the IMAGE_TAG (e.g., use environment substitution or a template placeholder) so
docker compose pull / docker compose up will use the immutable tag; ensure CI
injects the IMAGE_TAG (commit SHA or semver) and the deploy.sh and any docker
compose pull commands consume that variable (symbols to change: IMAGE_TAG,
REGISTRY, NEW_IMAGE, docker pull invocation, docker-compose.blue.yaml and
docker-compose.green.yaml image fields, and any docker compose pull calls).

In `@src/main/resources/db/migration/V1__init_schema.sql`:
- Around line 32-39: The PostGIS extension creation is commented out in
V1__init_schema.sql which breaks runtime queries used by
SouvenirRepository.findNearbySouvenirs (uses ST_DWithin, ST_Distance,
ST_SetSRID, ST_MakePoint). Re-enable the extension creation (uncomment or add
CREATE EXTENSION IF NOT EXISTS postgis) in V1__init_schema.sql, or alternatively
add a migration check that verifies/creates the extension before any spatial
queries run; ensure the migration uses "CREATE EXTENSION IF NOT EXISTS postgis"
so the findNearbySouvenirs query will succeed.

---

Nitpick comments:
In `@deploy/prod/scripts/deploy.sh`:
- Around line 112-119: Before overwriting NGINX_UPSTREAM_FILE, create a
timestamped backup (or tmp copy) of the current file, then write the new
upstream (using TARGET_PORT) to a temp file and atomically move it into place
only after nginx -t succeeds; if nginx -t or nginx -s reload fails, restore the
backup and log the error. Concretely: back up NGINX_UPSTREAM_FILE, write new
content to a temp path, run sudo nginx -t against the new file, if the test
passes move the temp into NGINX_UPSTREAM_FILE and run sudo nginx -s reload,
otherwise restore the backup and abort with a clear error message; ensure all
steps check exit codes and clean up temp files.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9d03e8dd-4edf-4dbf-abc2-3542b620a9b5

📥 Commits

Reviewing files that changed from the base of the PR and between 9ca18c7 and 8ec3d6e.

📒 Files selected for processing (4)

• .github/workflows/prod-cicd.yaml
• deploy/prod/scripts/deploy.sh
• src/main/resources/application-prod.yaml
• src/main/resources/db/migration/V1__init_schema.sql

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check for concurrency settings and triggers in the prod-cicd workflow
echo "=== Checking for concurrency settings ==="
rg -nP '^\s*concurrency\s*:' .github/workflows/prod-cicd.yaml || echo "No concurrency block found"

echo -e "\n=== Checking for trigger configuration ==="
rg -nP '^\s*(pull_request|push|on):' .github/workflows/prod-cicd.yaml

echo -e "\n=== Full workflow file content ==="
cat -n .github/workflows/prod-cicd.yaml

Repository: souzip/souzip-api

Length of output: 5432

---

동시 배포 실행 제어가 누락되었습니다.

push 트리거로 연속 발생 시 deploy 작업이 동시에 실행되어 blue/green 배포와 nginx 설정에서 경합이 발생할 수 있습니다. 배포를 직렬화하기 위해 워크플로우 레벨에 concurrency 설정이 필요합니다.

🔧 제안 수정안

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

+concurrency:
+  group: prod-deploy
+  cancel-in-progress: false

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/prod-cicd.yaml around lines 4 - 9, The workflow is missing
a workflow-level concurrency setting, so multiple pushes can trigger overlapping
runs and cause concurrent execution of the deploy job (risking blue/green and
nginx race conditions); add a top-level concurrency stanza to the workflow
(e.g., concurrency: { group: "deploy-${{ github.ref }}", cancel-in-progress:
true }) to serialize runs for the same branch/ref and ensure the existing deploy
job is executed one at a time.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# latest 태그 의존 지점 확인
echo "=== Checking deploy.sh ==="
cat -n deploy/prod/scripts/deploy.sh | sed -n '1,50p'

echo -e "\n=== Searching for :latest tags in deployment files ==="
rg -n ':latest' deploy/prod/ .github/workflows/ 2>/dev/null | head -30

Repository: souzip/souzip-api

Length of output: 2102

---

🏁 Script executed:

#!/bin/bash
# Check how docker-compose files are used and if they reference the pulled image
echo "=== Checking docker-compose usage in deploy.sh ==="
cat -n deploy/prod/scripts/deploy.sh | grep -A 20 -B 5 "docker-compose"

echo -e "\n=== Checking docker-compose.blue.yaml content ==="
head -20 deploy/prod/docker-compose.blue.yaml

echo -e "\n=== Checking how NEW_IMAGE is used after being set ==="
cat -n deploy/prod/scripts/deploy.sh | grep -A 15 "NEW_IMAGE="

Repository: souzip/souzip-api

Length of output: 1788

---

🏁 Script executed:

#!/bin/bash
# Check how docker-compose files are invoked and if NEW_IMAGE is used
echo "=== Searching for docker-compose invocations in deploy.sh ==="
rg -n "docker-compose" deploy/prod/scripts/deploy.sh

echo -e "\n=== Full deploy.sh to see complete flow ==="
wc -l deploy/prod/scripts/deploy.sh

Repository: souzip/souzip-api

Length of output: 289

---

🏁 Script executed:

#!/bin/bash
# Get the full deploy.sh to understand the complete deployment flow
cat -n deploy/prod/scripts/deploy.sh

Repository: souzip/souzip-api

Length of output: 3856

---

프로덕션 배포에서 :latest 태그 사용으로 인한 재현성 및 롤백 추적성 저하

배포 스크립트(32, 34번 줄)뿐만 아니라 docker-compose 파일들(blue.yaml, green.yaml 5번 줄)에서도 :latest 태그가 하드코딩되어 있어, 동일한 이미지 버전을 보장하지 못합니다. 특히 82-83번 줄의 docker compose pull은 compose 파일의 :latest 정의를 따릅니다.

commit SHA 또는 semantic version 같은 immutable 태그로 고정하되, 다음을 함께 변경해야 합니다:

• deploy.sh에서 IMAGE_TAG 변수화
• docker-compose.blue.yaml, docker-compose.green.yaml에서 image 필드 수정
• 필요시 CI/CD 워크플로우에서 태그를 동적으로 주입

🔧 제안 수정안

--- a/deploy/prod/scripts/deploy.sh
+++ b/deploy/prod/scripts/deploy.sh
@@ -1,6 +1,7 @@
 #!/bin/bash
 set -e
 
+IMAGE_TAG="${IMAGE_TAG:-latest}"
 RED='\033[0;31m'
 GREEN='\033[0;32m'
 YELLOW='\033[1;33m'
@@ -29,11 +30,11 @@ cd "$WORK_DIR" || exit 1
 
 echo -e "${YELLOW}[1/7] 최신 이미지 다운로드${NC}"
 
-docker pull ${REGISTRY}:latest
+docker pull "${REGISTRY}:${IMAGE_TAG}"
 
-NEW_IMAGE=$(docker images ${REGISTRY}:latest -q)
+NEW_IMAGE=$(docker images "${REGISTRY}:${IMAGE_TAG}" -q)

--- a/deploy/prod/docker-compose.blue.yaml
+++ b/deploy/prod/docker-compose.blue.yaml
@@ -2,7 +2,7 @@ version: "3.8"
 
 services:
   backend:
-    image: asia-northeast3-docker.pkg.dev/souzip-488211/souzip-prod-repo/souzip-api:latest
+    image: asia-northeast3-docker.pkg.dev/souzip-488211/souzip-prod-repo/souzip-api:${IMAGE_TAG:-latest}
     container_name: souzip-api-blue

--- a/deploy/prod/docker-compose.green.yaml
+++ b/deploy/prod/docker-compose.green.yaml
@@ -2,7 +2,7 @@ version: "3.8"
 
 services:
   backend:
-    image: asia-northeast3-docker.pkg.dev/souzip-488211/souzip-prod-repo/souzip-api:latest
+    image: asia-northeast3-docker.pkg.dev/souzip-488211/souzip-prod-repo/souzip-api:${IMAGE_TAG:-latest}
     container_name: souzip-api-green

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deploy/prod/scripts/deploy.sh` around lines 9 - 34, The script currently
hardcodes :latest which breaks reproducible deploys; introduce an IMAGE_TAG
variable (default from env or CI) and replace all uses of :latest so docker pull
${REGISTRY}:${IMAGE_TAG} is used, update NEW_IMAGE to query
${REGISTRY}:${IMAGE_TAG}, and change docker-compose.blue.yaml and
docker-compose.green.yaml image fields to reference the IMAGE_TAG (e.g., use
environment substitution or a template placeholder) so docker compose pull /
docker compose up will use the immutable tag; ensure CI injects the IMAGE_TAG
(commit SHA or semver) and the deploy.sh and any docker compose pull commands
consume that variable (symbols to change: IMAGE_TAG, REGISTRY, NEW_IMAGE, docker
pull invocation, docker-compose.blue.yaml and docker-compose.green.yaml image
fields, and any docker compose pull calls).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, verify the hardcoded WORK_DIR in the deploy script
cat -n deploy/prod/scripts/deploy.sh | head -20

Repository: souzip/souzip-api

Length of output: 648

---

🏁 Script executed:

# Search for workflow files that might use GCP_PROD_USER
find .github -name "*.yaml" -o -name "*.yml" | head -10

Repository: souzip/souzip-api

Length of output: 125

---

🏁 Script executed:

# Look for references to the hardcoded path in other files
rg "souzip-prod" --type sh --type yaml

Repository: souzip/souzip-api

Length of output: 497

---

🏁 Script executed:

cat -n .github/workflows/prod-cicd.yaml | grep -A 5 -B 5 "GCP_PROD_USER\|WORK_DIR\|/home"

Repository: souzip/souzip-api

Length of output: 1121

---

🏁 Script executed:

# Check for any secrets usage in the workflow
cat .github/workflows/prod-cicd.yaml | head -100

Repository: souzip/souzip-api

Length of output: 2442

---

워크플로우 경로와 스크립트 경로 불일치로 배포 실패 위험이 있습니다.

워크플로우는 /home/${{ secrets.GCP_PROD_USER }}/souzip으로 파일을 배포(line 97, 109)하지만, deploy.sh의 WORK_DIR은 /home/souzip-prod/souzip로 고정되어 있습니다(line 11). GCP_PROD_USER 값이 souzip-prod와 다르면 스크립트가 파일을 찾지 못해 배포가 실패합니다.

상대 경로 기반으로 변경하여 스크립트 위치에 따라 동적으로 경로를 결정하는 것을 권장합니다.

🔧 제안 수정안

--- a/deploy/prod/scripts/deploy.sh
+++ b/deploy/prod/scripts/deploy.sh
@@
-WORK_DIR="/home/souzip-prod/souzip"
-DEPLOY_DIR="$WORK_DIR/deploy/prod"
+SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
+DEPLOY_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+WORK_DIR="$(cd "$DEPLOY_DIR/../.." && pwd)"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deploy/prod/scripts/deploy.sh` around lines 11 - 13, The hardcoded WORK_DIR
(and DEPLOY_DIR) in deploy.sh causes mismatches with the workflow's /home/${{
secrets.GCP_PROD_USER }}/souzip path; change deploy.sh to compute paths relative
to the script location instead of a fixed user folder by deriving the script
directory (e.g., from $0) and setting WORK_DIR based on that directory, then set
DEPLOY_DIR relative to WORK_DIR so the script works regardless of GCP_PROD_USER
or the home path.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check the migration file content around lines 32-39
echo "=== Migration file content (lines 25-45) ==="
sed -n '25,45p' src/main/resources/db/migration/V1__init_schema.sql

echo -e "\n=== Check SouvenirRepository for ST_DWithin/ST_Distance usage ==="
rg -n 'ST_DWithin|ST_Distance|ST_SetSRID|ST_MakePoint' src/main/java/com/souzip/domain/souvenir/repository/SouvenirRepository.java

echo -e "\n=== Check all PostGIS extension references in migration files ==="
find src/main/resources/db/migration -name "*.sql" -exec grep -n 'postgis\|PostGIS' {} +

echo -e "\n=== Full SouvenirRepository.java file (checking lines around 21-46) ==="
wc -l src/main/java/com/souzip/domain/souvenir/repository/SouvenirRepository.java

Repository: souzip/souzip-api

Length of output: 1686

---

🏁 Script executed:

#!/bin/bash
# View the full SouvenirRepository.java to understand the query context
echo "=== Full SouvenirRepository.java content ==="
cat -n src/main/java/com/souzip/domain/souvenir/repository/SouvenirRepository.java

echo -e "\n=== Check if other Java files use PostGIS functions ==="
rg -l 'ST_DWithin|ST_Distance|ST_SetSRID|ST_MakePoint' src/main/java/

echo -e "\n=== Check for any PostGIS setup in other migration files ==="
find src/main/resources/db/migration -name "*.sql" | sort

Repository: souzip/souzip-api

Length of output: 3282

---

PostGIS 확장 생성이 주석 처리되어 있어 런타임 쿼리 실패를 초래합니다.

SouvenirRepository.java의 findNearbySouvenirs() 메서드(37-45줄)가 ST_DWithin, ST_Distance, ST_SetSRID, ST_MakePoint 등 PostGIS 공간 함수를 직접 사용하고 있습니다. 현재 V1__init_schema.sql 32줄과 39줄의 PostGIS 확장 생성 구문이 주석 처리되어 있어, 이 쿼리는 데이터베이스에 해당 확장이 설치되지 않으면 실행 시 실패합니다.

확장 생성 구문을 활성화하거나, 외부 프로비저닝을 사용한다면 마이그레이션에서 존재 여부를 검증해야 합니다.

제안 수정안

--- a/src/main/resources/db/migration/V1__init_schema.sql
+++ b/src/main/resources/db/migration/V1__init_schema.sql
@@ -29,6 +29,6 @@
 -- Name: postgis; Type: EXTENSION; Schema: -; Owner: -
 --
 
--- CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA cdb_admin;
+CREATE EXTENSION IF NOT EXISTS postgis;

@@ -36,4 +36,4 @@
 -- Name: EXTENSION postgis; Type: COMMENT; Schema: -; Owner: 
 --
 
--- COMMENT ON EXTENSION postgis IS 'PostGIS geometry and geography spatial types and functions';
+COMMENT ON EXTENSION postgis IS 'PostGIS geometry and geography spatial types and functions';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/resources/db/migration/V1__init_schema.sql` around lines 32 - 39,
The PostGIS extension creation is commented out in V1__init_schema.sql which
breaks runtime queries used by SouvenirRepository.findNearbySouvenirs (uses
ST_DWithin, ST_Distance, ST_SetSRID, ST_MakePoint). Re-enable the extension
creation (uncomment or add CREATE EXTENSION IF NOT EXISTS postgis) in
V1__init_schema.sql, or alternatively add a migration check that
verifies/creates the extension before any spatial queries run; ensure the
migration uses "CREATE EXTENSION IF NOT EXISTS postgis" so the
findNearbySouvenirs query will succeed.