TIL - 20260618

juni·2026년 6월 18일

TIL

목록 보기

381/468

0618 AWS 운영 실무 기초 (9/N): 백업, 복구와 장애 대응 전략

✅ 1. 백업이란 무엇인가?

백업(Backup)은 장애, 실수, 해킹, 데이터 손상에 대비해서 중요한 데이터를 별도로 복사해두는 작업입니다.
웹서비스 운영에서는 DB, 업로드 파일, 서버 설정, 환경변수 구조, 배포 스크립트, 로그 등을 백업 대상으로 봐야 합니다.
백업은 “있으면 좋은 것”이 아니라, 실제 운영 서비스에서는 장애 대응의 마지막 안전장치입니다.

➕ 1-1. 백업이 필요한 이유

실수 복구
- 운영 DB에서 잘못된 DELETE, UPDATE를 실행했을 때 복구할 수 있습니다.
장애 대응
- RDS 장애, EC2 장애, S3 파일 손상, 배포 실패 등에 대응할 수 있습니다.
보안 사고 대응
- 해킹이나 랜섬웨어, 잘못된 권한 변경으로 데이터가 손상되었을 때 이전 상태로 되돌릴 수 있습니다.
서비스 신뢰도 유지
- 고객 데이터, 주문 데이터, 상담 신청 데이터가 사라지면 서비스 신뢰도가 크게 떨어집니다.

✅ 2. 백업과 복구는 함께 봐야 한다

백업 파일이 있다고 해서 복구가 가능한 것은 아닙니다.
실제로 복구 절차를 모르거나, 백업 파일이 깨져 있거나, 복구 시간이 너무 오래 걸리면 운영 장애로 이어질 수 있습니다.

나쁜 상태:
백업은 있다고 생각하지만 복구 테스트를 해본 적 없음

좋은 상태:
백업 위치, 복구 명령어, 복구 예상 시간, 담당자가 정리되어 있음

➕ 2-1. 백업 전략의 핵심

무엇을 백업할 것인가?
얼마나 자주 백업할 것인가?
어디에 저장할 것인가?
얼마나 오래 보관할 것인가?
누가 접근할 수 있는가?
어떻게 복구할 것인가?
복구 테스트를 해봤는가?

✅ 3. 백업해야 할 대상

➕ 3-1. 데이터베이스

회원 정보
상담 신청 정보
주문 정보
상품 정보
관리자 계정
변경 이력
결제/정산 관련 데이터
이벤트/사전예약 신청 데이터

가장 중요한 백업 대상:
운영 데이터베이스

DB는 서비스의 핵심 데이터가 들어있는 곳이므로 백업 우선순위가 가장 높습니다.

➕ 3-2. 업로드 파일

상품 이미지
이벤트 배너
사용자 첨부파일
관리자 업로드 파일
엑셀 업로드/다운로드 파일
계약서, 증빙 파일
DB에는 파일 경로만 있고 실제 파일은 S3나 서버 디스크에 있을 수 있습니다.
DB만 백업하고 파일을 백업하지 않으면, 복구 후 이미지나 첨부파일이 깨질 수 있습니다.

➕ 3-3. 서버 설정

Nginx 설정
PM2 ecosystem 설정
배포 스크립트
Docker Compose 파일
SSL 인증서 설정
Crontab
시스템 서비스 설정

/etc/nginx/sites-available/
/etc/nginx/sites-enabled/
/home/ubuntu/apps/
/home/ubuntu/.pm2/

서버 설정을 문서화하지 않으면 EC2를 새로 만들 때 복구 시간이 길어집니다.

➕ 3-4. 환경변수 구조

실제 Secret 값은 안전하게 관리해야 하지만, 어떤 환경변수가 필요한지는 문서화해야 합니다.

DATABASE_URL=
JWT_SECRET=
AWS_REGION=
AWS_S3_BUCKET=
CORS_ORIGIN=
SMS_API_KEY=

.env.example은 반드시 관리하는 것이 좋습니다.
운영 .env 파일은 Git에 올리면 안 됩니다.

✅ 4. RDS 백업 전략

AWS RDS는 자동 백업과 수동 스냅샷 기능을 제공합니다.
운영 DB는 RDS 자동 백업을 활성화하고, 중요한 작업 전에는 수동 스냅샷을 남기는 것이 좋습니다.

➕ 4-1. RDS 자동 백업

RDS 자동 백업은 설정한 보존 기간 동안 특정 시점으로 복구할 수 있게 해줍니다.

예시:
자동 백업 보존 기간 7일
  ↓
최근 7일 내 특정 시점으로 복구 가능

➕ 4-2. 자동 백업 설정 기준

서비스 단계	보존 기간 예시
테스트 DB	1일 ~ 3일
소규모 운영 DB	7일
중요 운영 DB	14일 ~ 35일

보존 기간이 길수록 복구 가능 범위는 넓어지지만 비용도 증가할 수 있습니다.
비용을 아끼겠다고 운영 DB 백업을 꺼버리면 안 됩니다.

✅ 5. RDS 수동 스냅샷

수동 스냅샷은 특정 시점의 DB 상태를 직접 저장해두는 백업입니다.
위험한 작업 전에는 수동 스냅샷을 남기는 습관이 필요합니다.

➕ 5-1. 수동 스냅샷이 필요한 상황

운영 DB 마이그레이션 전
대량 데이터 수정 전
대량 데이터 삭제 전
테이블 구조 변경 전
사전예약/런칭 이벤트 오픈 전
외부 API 연동 구조 변경 전
배포 범위가 큰 기능 반영 전

작업 전:
RDS 수동 스냅샷 생성

작업 후:
정상 동작 확인

문제 발생:
스냅샷 기반 복구 검토

✅ 6. DB Dump 백업

RDS 스냅샷 외에도 pg_dump, mysqldump 같은 도구로 SQL 백업 파일을 만들 수 있습니다.
스냅샷은 RDS 단위 복구에 좋고, dump 파일은 특정 DB나 테이블 단위 백업에 유용합니다.

➕ 6-1. PostgreSQL pg_dump 예시

pg_dump -h RDS_ENDPOINT -U USER -d DB_NAME > backup_20260618.sql

➕ 6-2. 압축 백업 예시

pg_dump -h RDS_ENDPOINT -U USER -d DB_NAME | gzip > backup_20260618.sql.gz

➕ 6-3. S3 업로드 예시

aws s3 cp backup_20260618.sql.gz s3://togethermall-backups/db/2026/06/18/

백업 파일에 개인정보가 포함될 수 있으므로 S3 public 경로에 올리면 안 됩니다.
백업 버킷은 접근 권한을 엄격히 제한해야 합니다.

✅ 7. S3 백업 전략

S3는 파일 저장소이면서 백업 저장소로도 사용할 수 있습니다.
다만 S3에 파일이 있다고 해서 무조건 안전한 것은 아닙니다.
권한, 버전 관리, Lifecycle 정책, 삭제 보호를 함께 고려해야 합니다.

➕ 7-1. S3 백업 대상

DB dump 파일
서버 설정 압축본
Nginx 설정 백업
배포 스크립트 백업
업로드 파일 원본
로그 아카이브

➕ 7-2. S3 Versioning

Versioning은 같은 key의 파일이 덮어쓰기 되거나 삭제될 때 이전 버전을 보관하는 기능입니다.
실수로 파일을 덮어썼을 때 복구에 도움이 됩니다.

banner.webp 업로드
  ↓
같은 이름으로 새 파일 업로드
  ↓
Versioning이 켜져 있으면 이전 버전 보관

중요한 백업 버킷이나 파일 버킷에는 Versioning을 고려할 수 있습니다.
단, 버전이 계속 쌓이면 비용이 증가하므로 Lifecycle 정책도 함께 설계해야 합니다.

✅ 8. S3 Lifecycle과 백업 보관 기간

백업 파일은 무한히 쌓이면 비용이 증가합니다.
Lifecycle 정책으로 오래된 백업을 저렴한 스토리지로 이동하거나 삭제할 수 있습니다.

➕ 8-1. 예시 정책

db/daily/
- 30일 보관
- 30일 후 Glacier 이동
- 180일 후 삭제

db/monthly/
- 1년 보관

tmp/
- 7일 후 삭제

➕ 8-2. 보관 정책 설계 기준

최근 장애 복구에 필요한 기간
법적 보관 필요 여부
개인정보 포함 여부
비용 부담
복구 속도
장기 보관 필요성

Glacier 계열은 저장 비용은 낮지만 복구 시간이 걸릴 수 있습니다.
빠르게 복구해야 하는 백업은 바로 접근 가능한 스토리지에 보관하는 것이 좋습니다.

✅ 9. EC2 서버 백업

EC2는 서버 설정, 배포 구조, Nginx 설정, PM2 설정이 들어 있습니다.
EC2가 장애 나면 새 서버에 같은 환경을 빠르게 구성할 수 있어야 합니다.

➕ 9-1. EC2에서 백업할 것

/etc/nginx/
/home/ubuntu/apps/
/home/ubuntu/.pm2/
/etc/systemd/system/
crontab 설정
배포 스크립트

➕ 9-2. 서버 설정 압축 예시

sudo tar -czf server-config-20260618.tar.gz \
  /etc/nginx \
  /home/ubuntu/.pm2

➕ 9-3. S3 업로드

aws s3 cp server-config-20260618.tar.gz \
  s3://togethermall-backups/server/2026/06/18/

서버 전체를 백업하는 것보다, 재구성에 필요한 설정과 문서를 관리하는 것이 더 실용적일 때가 많습니다.
가능하면 서버 세팅 절차를 문서화하거나 스크립트화하는 것이 좋습니다.

✅ 10. AMI와 EBS 스냅샷

EC2 서버 상태를 이미지로 저장하고 싶다면 AMI나 EBS 스냅샷을 사용할 수 있습니다.

➕ 10-1. AMI

AMI(Amazon Machine Image)는 EC2 인스턴스의 현재 상태를 이미지로 저장한 것입니다.
같은 설정의 새 서버를 빠르게 만들 수 있습니다.

운영 EC2 세팅 완료
  ↓
AMI 생성
  ↓
장애 발생 시 AMI로 새 EC2 생성

➕ 10-2. EBS 스냅샷

EBS 스냅샷은 EC2 디스크의 특정 시점 상태를 저장합니다.
서버 디스크 복구나 새 볼륨 생성에 사용할 수 있습니다.

➕ 10-3. 주의점

오래된 AMI와 스냅샷은 비용이 발생할 수 있습니다.
민감정보가 포함된 서버 이미지 관리에 주의해야 합니다.
AMI만 믿지 말고 배포 문서와 환경변수 구조도 같이 관리해야 합니다.

✅ 11. 복구 전략

복구 전략은 장애가 발생했을 때 어떤 순서로 서비스를 되살릴지 정리한 계획입니다.
백업은 복구 전략이 있을 때 의미가 있습니다.

➕ 11-1. 복구 유형

상황	복구 방식
잘못된 DB 수정	RDS 특정 시점 복구, dump 복구
EC2 서버 장애	새 EC2 생성, AMI 복구, 배포 재실행
파일 삭제	S3 Versioning, 백업 파일 복구
배포 실패	이전 커밋 재배포, 롤백
DNS 오류	기존 Route 53 레코드 복원
인증서 문제	Certbot/ACM 재발급 또는 설정 복구

✅ 12. RTO와 RPO

백업과 복구 전략에서 자주 나오는 개념이 RTO와 RPO입니다.

➕ 12-1. RTO

RTO(Recovery Time Objective)는 장애 발생 후 서비스를 몇 시간 안에 복구해야 하는지를 의미합니다.

RTO 1시간:
장애 발생 후 1시간 안에 서비스 복구 목표

➕ 12-2. RPO

RPO(Recovery Point Objective)는 장애 발생 시 최대 어느 시점까지의 데이터 손실을 허용할 수 있는지를 의미합니다.

RPO 1시간:
최대 1시간 전 데이터까지 손실 가능

➕ 12-3. 실무 예시

중요 상담 신청 서비스:
RTO 1~2시간
RPO 1시간 이내

테스트 서버:
RTO 하루
RPO 하루 이상 가능

중요한 서비스일수록 RTO/RPO를 짧게 가져가야 합니다.
다만 짧게 가져갈수록 비용과 운영 복잡도는 증가합니다.

✅ 13. 장애 대응 기본 흐름

장애가 발생하면 당황해서 이것저것 누르기보다 순서대로 확인해야 합니다.

➕ 13-1. 기본 대응 순서

1. 장애 범위 확인
2. 사용자 영향 확인
3. 최근 변경사항 확인
4. 로그와 지표 확인
5. 임시 조치
6. 근본 원인 파악
7. 복구 또는 롤백
8. 재발 방지 작업
9. 장애 기록 작성

➕ 13-2. 장애 범위 확인

전체 사이트가 안 되는가?
API만 안 되는가?
관리자만 안 되는가?
특정 기능만 안 되는가?
특정 사용자만 안 되는가?
모바일에서만 안 되는가?

전체 장애:
DNS, Nginx, EC2, SSL, CloudFront 확인

특정 API 장애:
백엔드 로그, DB, 외부 API 확인

이미지만 안 보임:
S3, CloudFront, 파일 key, 권한 확인

✅ 14. 장애 유형별 확인 순서

➕ 14-1. 502 Bad Gateway

1. PM2 프로세스 online 여부 확인
2. pm2 logs 확인
3. Nginx error.log 확인
4. 백엔드 포트 확인
5. 환경변수 누락 확인
6. DB 연결 확인
7. 최근 배포 확인

pm2 list
pm2 logs api
sudo tail -f /var/log/nginx/error.log

➕ 14-2. DB 연결 실패

1. RDS 상태 확인
2. EC2에서 RDS 접속 테스트
3. RDS 보안 그룹 확인
4. DATABASE_URL 확인
5. DB 사용자/비밀번호 확인
6. Prisma migrate 상태 확인
7. 최근 환경변수 변경 확인

psql -h RDS_ENDPOINT -p 5432 -U USER -d DB_NAME

➕ 14-3. 이미지/파일 장애

1. DB에 저장된 S3 key 확인
2. S3에 실제 객체가 있는지 확인
3. CloudFront 403/404 확인
4. S3 버킷 정책 확인
5. OAC/OAI 설정 확인
6. CloudFront 캐시 확인
7. 파일 MIME 타입 확인

➕ 14-4. 배포 후 화면 깨짐

1. 브라우저 Network 탭 확인
2. JS/CSS 404 확인
3. CloudFront 캐시 확인
4. index.html 캐싱 확인
5. 환경변수 API URL 확인
6. React Router 직접 접속 확인
7. 이전 빌드로 롤백 검토

✅ 15. 롤백 전략

롤백(Rollback)은 문제가 생긴 배포를 이전 정상 상태로 되돌리는 작업입니다.
배포 전에는 항상 “문제가 생기면 어떻게 되돌릴지”를 생각해야 합니다.

➕ 15-1. 코드 롤백

git log --oneline
git checkout <previous-commit>
npm install
npm run build
pm2 reload api

실제 운영에서는 checkout 방식보다 이전 릴리즈 재배포, Docker 이미지 태그, GitHub Actions 재실행 같은 방식이 더 안정적일 수 있습니다.

➕ 15-2. 프론트엔드 롤백

이전 dist 파일 보관
  ↓
문제 발생 시 이전 dist를 S3 또는 /var/www에 재배포
  ↓
CloudFront 캐시 무효화 또는 index.html 갱신

React 배포에서는 index.html과 JS/CSS 캐시 관계를 조심해야 합니다.
새 index.html이 이전 asset을 바라보거나, 이전 index.html이 새 asset을 못 찾으면 화면이 깨질 수 있습니다.

➕ 15-3. DB 변경이 포함된 롤백

DB 마이그레이션이 포함된 배포는 롤백이 어렵습니다.
컬럼 삭제, 테이블 삭제, 데이터 변환이 들어가면 단순히 코드만 되돌려도 해결되지 않을 수 있습니다.

위험한 변경:
컬럼 삭제
테이블 삭제
대량 데이터 수정
enum 값 변경
unique 제약 추가

이런 변경 전에는 RDS 스냅샷을 남기고, 롤백 가능성을 미리 검토해야 합니다.

✅ 16. 장애 기록 작성

장애가 지나가면 반드시 기록을 남겨야 합니다.
기록을 남기지 않으면 같은 문제가 반복될 가능성이 높습니다.

➕ 16-1. 장애 기록 템플릿

## 장애 기록

### 발생 일시
- 2026-06-18 14:30

### 장애 내용
- 관리자 상담 목록 API 500 오류 발생

### 영향 범위
- 관리자 페이지 상담 목록 조회 불가
- 고객 신청 기능은 정상

### 원인
- 최근 배포에서 DATABASE_URL 환경변수 누락

### 조치 내용
- 운영 서버 .env 수정
- PM2 reload 진행
- API health check 확인

### 복구 일시
- 2026-06-18 15:05

### 재발 방지
- 배포 전 환경변수 체크리스트 추가
- GitHub Actions에서 필수 환경변수 검증 추가

장애 기록은 경력기술서에도 좋은 근거가 됩니다.
단순히 “장애 처리함”보다 “원인 분석 → 복구 → 재발 방지”가 훨씬 실무적으로 보입니다.

✅ 17. 1인 개발자 기준 최소 백업 전략

1인 개발자는 복잡한 엔터프라이즈 구조보다 현실적인 최소 안전장치부터 갖추는 것이 중요합니다.

➕ 17-1. 최소 구성

RDS 자동 백업 7일
중요 배포 전 RDS 수동 스냅샷
S3 업로드 파일 Versioning 검토
DB dump 주기적 S3 저장
서버 설정 백업
.env.example 관리
배포 기록과 장애 기록 작성
AWS 비용 알림 설정

➕ 17-2. 매주 확인할 것

RDS 자동 백업이 켜져 있는가?
최근 스냅샷이 필요한 만큼 남아 있는가?
오래된 스냅샷이 비용을 만들고 있지 않은가?
S3 백업 파일이 public이 아닌가?
CloudWatch 알람이 정상인가?
서버 설정 변경이 문서에 반영되어 있는가?

✅ 18. 실무 체크리스트

➕ 18-1. 백업 체크리스트

운영 DB 자동 백업이 활성화되어 있는가?
백업 보존 기간이 정해져 있는가?
중요한 배포 전 수동 스냅샷을 생성하는가?
DB dump 파일을 안전한 위치에 저장하는가?
S3 파일과 DB 데이터의 정합성을 고려하는가?
서버 설정과 배포 스크립트가 백업되어 있는가?
.env.example로 필요한 환경변수 목록을 관리하는가?
백업 파일 접근 권한이 제한되어 있는가?

➕ 18-2. 복구 체크리스트

RDS 특정 시점 복구 방법을 알고 있는가?
스냅샷으로 새 RDS를 만드는 방법을 알고 있는가?
복구 후 DATABASE_URL 변경이 필요함을 알고 있는가?
S3 파일 복구 방법을 알고 있는가?
새 EC2에 서버를 재구성할 수 있는가?
복구 절차를 문서화했는가?
실제 복구 테스트를 해본 적이 있는가?

➕ 18-3. 장애 대응 체크리스트

장애 범위를 먼저 확인하는가?
최근 배포나 설정 변경을 확인하는가?
PM2, Nginx, CloudWatch, RDS 지표를 순서대로 확인하는가?
임시 조치와 근본 해결을 구분하는가?
롤백 기준이 정해져 있는가?
장애 후 기록과 재발 방지 작업을 남기는가?

✅ 19. AI를 활용해 장애 대응을 할 때 질문법

장애 상황에서는 AI에게 질문할 때 정보를 구조화해서 줘야 합니다.
“사이트 안 돼”라고만 하면 원인 범위가 너무 넓습니다.

➕ 19-1. 좋은 질문 예시

AWS EC2 + RDS + S3 + CloudFront 환경에서 배포 후 장애가 발생했어.

상황:
1. React 프론트엔드는 CloudFront + S3로 배포
2. 백엔드는 EC2에서 NestJS + PM2로 실행
3. DB는 RDS PostgreSQL
4. 배포 후 관리자 상담 목록 API에서 500 발생
5. 고객 메인 페이지는 정상 접속됨
6. PM2 logs에는 Prisma 에러가 있음
7. RDS CPU는 정상
8. 최근 Prisma migration을 적용함
9. 배포 전 RDS 수동 스냅샷은 생성해둠

확인 순서, 임시 조치, 롤백 여부 판단 기준을 알려줘.
위험한 명령어는 제외하고 설명해줘.

➕ 19-2. AI 답변 검증 기준

장애 범위를 먼저 좁히는가?
로그와 지표를 순서대로 확인하게 하는가?
DB 마이그레이션과 코드 배포를 함께 고려하는가?
운영 DB에 reset/drop 명령어를 권하지 않는가?
스냅샷 복구가 기존 DB를 바로 덮어쓰는 것이 아님을 설명하는가?
임시 조치와 근본 해결을 구분하는가?
장애 기록과 재발 방지를 안내하는가?

📌 요약

백업은 장애, 실수, 해킹, 데이터 손상에 대비해서 중요한 데이터를 별도로 보관하는 작업입니다.
백업은 복구 절차와 함께 관리해야 의미가 있습니다.
운영에서는 RDS 자동 백업, 수동 스냅샷, DB dump, S3 파일 백업, 서버 설정 백업을 함께 고려해야 합니다.
S3 백업 파일은 public으로 열면 안 되고, Versioning과 Lifecycle 정책을 함께 검토해야 합니다.
EC2는 AMI, EBS 스냅샷, 서버 설정 문서화를 통해 빠르게 재구성할 수 있어야 합니다.
RTO는 복구 목표 시간, RPO는 허용 가능한 데이터 손실 시점을 의미합니다.
장애 대응은 장애 범위 확인, 최근 변경사항 확인, 로그/지표 확인, 임시 조치, 복구, 재발 방지 순서로 진행해야 합니다.
DB 변경이 포함된 배포는 롤백이 어렵기 때문에 배포 전 수동 스냅샷과 마이그레이션 검토가 중요합니다.
장애가 끝난 뒤에는 반드시 장애 기록을 남기고, 재발 방지 작업을 문서화해야 합니다.

juni

이전 포스트

TIL - 20260617

다음 포스트

TIL - 20260618

TIL

0618 AWS 운영 실무 기초 (9/N): 백업, 복구와 장애 대응 전략

✅ 1. 백업이란 무엇인가?

➕ 1-1. 백업이 필요한 이유

✅ 2. 백업과 복구는 함께 봐야 한다

➕ 2-1. 백업 전략의 핵심

✅ 3. 백업해야 할 대상

➕ 3-1. 데이터베이스

➕ 3-2. 업로드 파일

➕ 3-3. 서버 설정

➕ 3-4. 환경변수 구조

✅ 4. RDS 백업 전략

➕ 4-1. RDS 자동 백업

➕ 4-2. 자동 백업 설정 기준

✅ 5. RDS 수동 스냅샷

➕ 5-1. 수동 스냅샷이 필요한 상황

✅ 6. DB Dump 백업

➕ 6-1. PostgreSQL pg_dump 예시

➕ 6-2. 압축 백업 예시

➕ 6-3. S3 업로드 예시

✅ 7. S3 백업 전략

➕ 7-1. S3 백업 대상

➕ 7-2. S3 Versioning

✅ 8. S3 Lifecycle과 백업 보관 기간

➕ 8-1. 예시 정책

➕ 8-2. 보관 정책 설계 기준

✅ 9. EC2 서버 백업

➕ 9-1. EC2에서 백업할 것

➕ 9-2. 서버 설정 압축 예시

➕ 9-3. S3 업로드

✅ 10. AMI와 EBS 스냅샷

➕ 10-1. AMI

➕ 10-2. EBS 스냅샷

➕ 10-3. 주의점

✅ 11. 복구 전략

➕ 11-1. 복구 유형

✅ 12. RTO와 RPO

➕ 12-1. RTO

➕ 12-2. RPO

➕ 12-3. 실무 예시

✅ 13. 장애 대응 기본 흐름

➕ 13-1. 기본 대응 순서

➕ 13-2. 장애 범위 확인

✅ 14. 장애 유형별 확인 순서

➕ 14-1. 502 Bad Gateway

➕ 14-2. DB 연결 실패

➕ 14-3. 이미지/파일 장애

➕ 14-4. 배포 후 화면 깨짐

✅ 15. 롤백 전략

➕ 15-1. 코드 롤백

➕ 15-2. 프론트엔드 롤백

➕ 15-3. DB 변경이 포함된 롤백

✅ 16. 장애 기록 작성

➕ 16-1. 장애 기록 템플릿

✅ 17. 1인 개발자 기준 최소 백업 전략

➕ 17-1. 최소 구성

➕ 17-2. 매주 확인할 것

✅ 18. 실무 체크리스트

➕ 18-1. 백업 체크리스트

➕ 18-2. 복구 체크리스트

➕ 18-3. 장애 대응 체크리스트

✅ 19. AI를 활용해 장애 대응을 할 때 질문법

➕ 19-1. 좋은 질문 예시

➕ 19-2. AI 답변 검증 기준

📌 요약

TIL - 20260617

TIL - 20260619

0개의 댓글