도커의 작동원리. 도커라는게 이제야 이해되는 중

Docker 빌드 기술부채 해결 과정에서 배운 내용 정리

아무리 해도 node.js로 작업된게 빌드가 안됨

# Docker 빌드 시 오류 발생

Error: Invalid `prisma.xxx.findMany()` invocation

DATABASE_URL environment variable is not set

 

처음에는 정적 HTML생성을 시도도 해보고

DB접근 권한 있는 페이지에 전부  

export const dynamic = 'force-dynamic'

 

설정도 했는데 그래도 빌드가 안됐다

여러 시도를 하는 과정이 있었는데

더미 DB를 설정하기도 하고 

JWT환경변수가 잘못 잡히기도 해서 빌드하는데만 2시간 넘게 걸렸다

심지어 정면 돌파도 못하고 빌드만 간신히 되게 만든 수준

 

결국 잔뜩 쌓아둔 기술부채를 단계별로 

클라이언트 컴포넌트로 교체하고 API Route를 분리하면서 하나씩 뜯어내 교체 하는 중이다.

swr도 설치하고 클라이언트에서 조치되게 바꿔가고 점진적으로 force-dynamic을 줄여나갔다

 

기본적으로... 

도커라는 거 자체가 이해가 안되서 

VM밖에 모르던 구시대 개발자가 이해하는데 꽤나 애먹었다.

다음은 이해한 대로 정리한 내용

 

---

 

🗄️ DB는 어떻게 관리되나?
기본 구조
DB는 Docker 컨테이너 안에서 실행되지만, 실제 데이터는 Volume이라는 별도 공간에 저장된다.

Docker Container (PostgreSQL 엔진)
└─ Volume (실제 데이터 저장소)
└─ 컨테이너를 삭제해도 데이터는 유지됨!
개발 환경:

DB: Docker PostgreSQL (localhost:5432)
데이터: 서비스, 볼륨으로 구분
운영 환경:

DB: 별도 PostgreSQL (클라우드 또는 서버)
데이터: 운영 서버의 Volume
🔄 DB 스키마는 어떻게 동기화하나?
Prisma가 중간 전달자 역할
Prisma는 DB 종류나 위치에 상관없이 동일하게 작동한다.

핵심: .env 파일의 DATABASE_URL만 바꾸면 어디든 연결됨!

개발 DB ← Prisma → 운영 DB
(Docker) (어디든 OK!)
스키마 변경 흐름
1. 개발 환경에서 스키마 수정
↓
schema.prisma 파일 수정
↓
npx prisma migrate dev --name 변경내용
↓
개발 DB에 적용 + 마이그레이션 파일 생성

2. Git으로 전송
↓
git add prisma/migrations/
git commit & push
↓
마이그레이션 파일이 Git에 저장됨

3. 운영 환경에서 적용
↓
git pull (마이그레이션 파일 다운로드)
↓
npx prisma migrate deploy
↓
운영 DB에 동일한 스키마 적용!

 

결론:

데이터는 분리 (개발 ≠ 운영)
스키마는 동기화 (개발 = 운영)
Prisma가 중간에서 모든 걸 처리
🚀 소스 코드는 어떻게 배포하나?
로컬 환경 구조
로컬 PC
├─ 방법 1: npm run dev (개발 서버)
│ └─ http://localhost
│ └─ Hot Reload, 빠른 개발
│
└─ 방법 2: docker-compose up (Docker)
└─ http://localhost
└─ 프로덕션 모드 테스트
주의: 같은 포트라서 동시 실행 불가!

운영 서버 2가지 방식
방식 A: 일반 서버 (Node.js 직접 설치)
# 배포 과정
git pull origin main
npm install
npm run build
pm2 restart service
특징:

✅ 빠른 재시작
✅ 디버깅 쉬움
❌ 환경 설정 복잡
방식 B: Docker 서버
# 배포 과정
git pull origin main
docker-compose down
docker-compose build
docker-compose up -d
특징:

✅ 환경 일관성 (로컬과 동일)
✅ 설치 간단 (Docker만 있으면 됨)
❌ 빌드 시간 오래 걸림
💡 CD 굽던 시대와 비교하면?
옛날 방식 (CD 시대)
프로그램 개발
↓
CD에 구워서
↓
이메일로 전송
↓
PC1, PC2에서 설치
지금 방식 (Git + Docker)
소스 코드 수정
↓
Git에 업로드 (이메일 대신)
↓
각 서버에서 다운로드
↓
각자 빌드해서 실행 (CD 굽기 대신)
비유로 이해하면:

Git = 이메일 (코드 전송 수단)
빌드 = CD 굽기 (실행 파일 만들기)
각 서버 = PC1, PC2 (각자 실행)
차이점:

옛날: 완성품(CD) 전송 → 느리고 무거움
지금: 소스만 전송 → 빠르고 가벼움

🎯 핵심 정리
DB 관리
DB 엔진은 Docker 안, 데이터는 Volume에 저장
Prisma가 개발/운영 DB를 동기화
마이그레이션 파일을 Git으로 관리
소스 배포
Git으로 코드 전송
각 서버에서 빌드
일반 서버 또는 Docker 중 선택
서버 재시작
docker-compose restart
DB 접속 (pgAdmin)
Host: localhost
Port: 5400
Database: service
Username: dba

📝 결론
Docker와 Prisma 덕분에:

개발 환경 = 운영 환경 (일관성)
DB 스키마 동기화 자동화
배포 과정 단순화
결론: 복잡해 보이지만, 결국 "코드 전송 → 빌드 → 실행"이라는 단순한 흐름!

 

---

 

과거엔 소스를 개발해놓고 서버 구축해서 환경변수 잡고

JAVA깔고 DB깔고 또 환경변수 잡고 껐다켜고 되니마니 하고 연결테스트하고 

이 모든 과정을 VM을 깔고 그안에서 또 설정하고 왜 안되는지 원인 찾고 했었던 것을

 

도커라는 건

쉽게 말하면 테스트서버에서 잘 갖춰진 서버, 라이브러리를 잔뜩 깔아놓고

CD같은 이미지로 구워서 서버 넘겨서

서버1, 서버2, 서버3 동일하게 설정할 수 있고

중간에 git을 두고 소스가 수정되면 이미 구축된 이미지 위에 동일한 방식의 소스를 뿌려서 똑같이 적용되게 만들겠다는 CI/CD전략인 거

 

소스는 그렇게 처리하는 거고 DB는

똑같이 git으로 처리는 하는데 DB스키마를 prisma라는 친구가 DB는 내가 살펴볼께 하고 스키마를 관리한다는거

칼럼이 추가되면 git에 올라가서 칼럼 추가됐다고 기다리고 있다가 서버1,서버2,서버3에 동일하게 내려가서

나 프리스마인데 니네 전부 칼럼 추가해야돼 라고 전한다는 이야기

하긴 DB도 스키마만 전달하면 똑같겠지 데이터를 직접 전송해야되는 게 아니니 (심지어 전송도 env에서 환경만 바꾸면 1->2로 전송하는게 가능하니까) 스키마만 중앙관리하면 된다는 구조였다

 

얼마 전 도커로 배포되는 소스가 있어서 컨테이너 설치하고 이미지를 받아 사용해본 적이 있는데

직접 이미지를 말아보니 이해가 더 쉽게 됐다