TIL - 20260812

juni·2026년 8월 12일

목록 보기

429/468

0812 인프라/DevOps 운영 심화 (10/N): 운영 성숙도 점검, 우선순위와 다음 성장 전략

✅ 1. 인프라/DevOps 운영 심화 마무리

인프라/DevOps 운영 심화에서는 단순히 서버 명령어를 외우는 것이 아니라, 서비스를 안정적으로 운영하기 위한 기준을 정리했습니다.
개발자가 코드를 잘 작성해도 배포, 환경변수, 로그, 장애 대응, 백업, 보안이 약하면 운영 서비스는 쉽게 흔들립니다.
특히 1인 개발자는 개발자이면서 동시에 배포 담당자, 장애 대응자, 보안 관리자, 문서 관리자 역할까지 해야 합니다.

로컬 개발환경
  ↓
Docker / OrbStack
  ↓
Nginx / HTTPS
  ↓
S3 + CloudFront
  ↓
GitHub Actions CI/CD
  ↓
환경변수 / Secret / SSM
  ↓
로그 / 모니터링
  ↓
배포 체크리스트 / Runbook
  ↓
운영 자동화 로드맵

➕ 1-1. DevOps를 배워야 하는 이유

개발:
기능을 만든다

DevOps:
기능을 안전하게 운영한다

운영:
사용자가 문제없이 계속 쓸 수 있게 한다

실무에서는 “기능 구현”보다 “문제 없이 운영되는 기능”이 더 가치 있습니다.
지금처럼 실제 고객과 운영자가 쓰는 서비스에서는 DevOps 역량이 개발 실력의 일부입니다.

✅ 2. 지금까지의 주제 요약

➕ 2-1. 0802 로컬/배포/운영 환경 구분

로컬, 개발, 스테이징, 운영 환경을 구분하는 기준을 정리했습니다.
같은 코드라도 환경변수, DB, API URL, Secret, 로그 레벨이 달라야 합니다.

local:
개인 Mac 개발

development:
내부 개발 테스트

staging:
운영 반영 전 검증

production:
실제 고객/운영자 사용

➕ 2-2. 0803 Docker, OrbStack과 개발 DB 운영

Docker와 OrbStack으로 PostgreSQL, Redis 같은 개발 인프라를 컨테이너로 운영하는 기준을 정리했습니다.
백엔드/프론트는 로컬 Node로 실행하고, DB/Redis만 컨테이너로 두는 방식이 현실적이라고 정리했습니다.

앱:
Mac Node에서 npm run dev

DB:
OrbStack PostgreSQL 컨테이너

Redis:
필요할 때만 컨테이너

주의:
localhost와 service name 구분

➕ 2-3. 0804 Nginx, Reverse Proxy와 HTTPS

Nginx가 외부 요청을 받아 백엔드 앱으로 전달하는 Reverse Proxy 구조를 정리했습니다.
HTTPS, proxy header, 502/413/504, WebSocket, CORS, Cookie 설정까지 운영에서 자주 만나는 문제를 다뤘습니다.

사용자
  ↓
Nginx :443
  ↓
NestJS / PM2 / Docker :3000

➕ 2-4. 0805 S3 + CloudFront 정적 배포와 캐시 전략

React/Vite 프론트 빌드 결과물을 S3에 올리고 CloudFront로 제공하는 구조를 정리했습니다.
index.html은 짧은 캐시, hashed assets는 긴 캐시가 핵심입니다.

S3:
원본 파일 저장

CloudFront:
CDN 캐시 제공

중요:
index.html과 assets 캐시 분리
SPA fallback 설정
CloudFront invalidation

➕ 2-5. 0806 GitHub Actions CI/CD 기본

push/PR 시 lint, test, typecheck, build를 자동 실행하는 CI 구조를 정리했습니다.
운영 배포는 처음부터 완전 자동화하기보다 workflow_dispatch 수동 실행으로 시작하는 것이 안전합니다.

push / PR
  ↓
GitHub Actions
  ↓
verify
  ↓
배포 가능 여부 확인

➕ 2-6. 0807 환경변수, Secret 관리와 AWS SSM

.env, .env.example, GitHub Secrets, AWS SSM Parameter Store를 정리했습니다.
프론트 env는 브라우저에 노출되고, 백엔드 Secret은 SSM/SecureString 등으로 관리해야 합니다.

프론트 env:
공개된다고 생각

백엔드 Secret:
SSM SecureString

원칙:
Git에 Secret 금지
AI에게 Secret 제공 금지

➕ 2-7. 0808 로그, 모니터링과 장애 대응

로그, requestId, 핵심 이벤트 로그, health check, 장애 등급, postmortem을 정리했습니다.
상담 신청 실패, 관리자 로그인 실패, 상태 변경 실패 같은 비즈니스 이벤트 로그가 중요합니다.

로그:
무슨 일이 있었는지 기록

모니터링:
문제가 커지기 전에 감지

장애 대응:
증상 → 영향 범위 → 최근 변경 → 로그 → 임시 대응 → 근본 해결

➕ 2-8. 0810 배포 체크리스트와 Runbook

배포 전후 체크리스트, Smoke Test, 롤백 기준, 장애별 Runbook을 정리했습니다.
배포는 명령어 실행이 아니라 검증, 반영, 확인, 기록까지 포함하는 운영 절차입니다.

배포 전:
verify + env + migration + rollback 확인

배포 후:
health check + smoke test + log 확인

문제 발생:
Runbook 기준 대응

➕ 2-9. 0811 1인 개발자 운영 자동화 로드맵

로컬 verify, CI, AI diff 리뷰, 프론트 배포 자동화, 백엔드 관측성, SSM, 작업 기록 자동화까지 단계별 로드맵을 정리했습니다.
자동화는 사람의 판단을 없애는 것이 아니라 반복 검증과 기록을 표준화하는 도구입니다.

자동화:
검증, 배포, 기록, 알림 보조

사람:
최종 판단, 운영 승인, 장애 대응

✅ 3. 현재 운영 성숙도 점검 기준

운영 성숙도는 “얼마나 복잡한 기술을 쓰는가”가 아닙니다.
서비스가 문제 없이 운영되고, 문제가 생겼을 때 빠르게 찾고, 복구하고, 기록할 수 있는지가 기준입니다.

➕ 3-1. Level 0: 수동 운영

특징:
로컬에서 직접 빌드
배포 명령어 기억에 의존
로그 확인 위치 불명확
장애 대응 즉흥적
작업 기록 없음

위험:

배포 실수 반복
문제 원인 추적 어려움
성과 설명 어려움
혼자 감으로 운영

➕ 3-2. Level 1: 기본 검증 운영

특징:
pnpm verify 또는 npm run verify 존재
배포 전 체크리스트 존재
Smoke Test 기준 존재
.env.example 정리
GitHub Actions CI 일부 적용

목표:

깨진 코드 배포 방지
배포 전 확인 습관화

➕ 3-3. Level 2: 표준 배포 운영

특징:
프론트 S3/CloudFront 배포 스크립트 존재
CloudFront invalidation 기준 존재
백엔드 재시작 절차 문서화
배포 기록 템플릿 존재
롤백 Runbook 존재

목표:

배포 절차 표준화
문제 발생 시 되돌릴 기준 확보

➕ 3-4. Level 3: 관측 가능한 운영

특징:
health endpoint 존재
API request log 존재
상담 신청 실패 로그 존재
관리자 로그인 실패 로그 존재
Nginx/PM2/Docker 로그 확인법 문서화
장애 기록 템플릿 존재

목표:

장애를 감으로 찾지 않기
로그 기반으로 원인 좁히기

➕ 3-5. Level 4: 자동화된 운영 기록

특징:
git diff 리뷰 자동화
커밋 메시지 추천
작업 요약 자동 생성
릴리즈 노트 초안 생성
Notion/Markdown 기록
장애 기록 초안 생성

목표:

운영 기록 자동화
성과 자료화
1인 개발자의 기억 의존도 감소

➕ 3-6. Level 5: 안정적 운영 체계

특징:
staging/production 분리
production 수동 승인 배포
SSM Secret 관리
알림/모니터링
백업/복구 Runbook
비용/보안 점검

목표:

운영 사고 방지
장애 대응 속도 향상
서비스 신뢰도 확보

지금은 Level 5를 바로 목표로 하기보다 Level 1~3을 확실히 만드는 것이 중요합니다.
운영 성숙도는 한 번에 올라가지 않고, 배포와 장애 경험을 문서화하면서 올라갑니다.

✅ 4. 지금 프로젝트 기준 가장 중요한 운영 흐름

온라인 휴대폰 판매몰에서는 모든 기능이 똑같이 중요하지 않습니다.
운영 자동화도 핵심 흐름부터 봐야 합니다.

➕ 4-1. 고객 핵심 흐름

메인/상품 목록
  ↓
상품 상세
  ↓
혜택/요금 확인
  ↓
상담 신청 CTA
  ↓
상담 신청 모달
  ↓
전화번호/정보 입력
  ↓
신청 완료

중요한 이유:

상담 신청은 매출/리드와 직접 연결
모바일 사용성 영향 큼
폼 검증/에러 처리 중요

➕ 4-2. 관리자 핵심 흐름

관리자 로그인
  ↓
상담 목록 조회
  ↓
검색/필터
  ↓
상담 상세 확인
  ↓
상태 변경
  ↓
엑셀/운영 처리

중요한 이유:

운영자가 매일 사용하는 핵심 화면
상태 변경 오류는 업무 혼선 유발
권한/로그/검색 재현성 중요

➕ 4-3. 배포 핵심 흐름

git diff 확인
  ↓
verify
  ↓
CI
  ↓
env/migration 확인
  ↓
배포
  ↓
health check
  ↓
Smoke Test
  ↓
로그 확인
  ↓
배포 기록

중요한 이유:

기능 추가보다 배포 안정성이 운영 신뢰를 결정
배포 기록이 있어야 장애 원인 추적 가능

운영 성숙도는 이 3개 흐름을 얼마나 안정적으로 지키는지로 판단해도 됩니다.
고객 신청, 관리자 처리, 배포 검증이 흔들리면 다른 개선은 우선순위가 낮아집니다.

✅ 5. 지금 바로 적용할 10개 항목

복잡한 DevOps 전체를 한 번에 적용하기보다, 당장 효과가 큰 10개부터 진행하는 것이 좋습니다.

1. pnpm verify 또는 npm run verify 정리
2. GitHub Actions CI 추가
3. 고객 상담 신청 Smoke Test 문서화
4. 관리자 상담 목록 Smoke Test 문서화
5. 프론트 배포 체크리스트 작성
6. 백엔드 배포 체크리스트 작성
7. CloudFront 캐시 Runbook 작성
8. Nginx 502 Runbook 작성
9. 상담 신청 실패 로그 추가
10. 배포 기록 템플릿 작성

➕ 5-1. 우선순위 이유

항목	효과
verify	배포 전 기본 검증
CI	main 안정성 확보
Smoke Test	핵심 기능 장애 조기 발견
체크리스트	반복 실수 방지
Runbook	장애 대응 속도 향상
실패 로그	원인 추적 가능
배포 기록	장애/성과 추적 가능

이 10개만 있어도 운영 안정성이 크게 올라갑니다.
특히 “상담 신청 실패 로그”와 “배포 기록”은 나중에 매우 크게 도움이 됩니다.

✅ 6. 운영 자동화에서 버려야 할 욕심

운영 자동화는 욕심내면 오히려 유지보수 부담이 커집니다.
지금 규모와 역할에 맞는 수준으로 가야 합니다.

➕ 6-1. 지금 당장 과한 것

Kubernetes
복잡한 Blue-Green 배포
대규모 APM 전체 도입
모든 테스트 E2E 자동화
운영 DB 자동 migration rollback
모든 장애 자동 복구
멀티 리전 구조

➕ 6-2. 지금 필요한 것

검증 명령어
CI
수동 승인 배포
health check
핵심 이벤트 로그
Runbook
배포 기록
작업 요약 자동화

좋은 개발자는 최신 기술을 무조건 붙이는 사람이 아닙니다.
현재 서비스에 필요한 안정성을 현실적으로 만드는 사람이 실무에서 더 강합니다.

✅ 7. 운영 문서 구조 최종안

지금 프로젝트에는 문서 구조를 너무 복잡하게 만들 필요는 없습니다.
아래 정도면 1인 개발자 운영 기준으로 충분합니다.

docs/
  ops/
    README.md
    environments.md
    secrets-ssm.md
    deploy-frontend.md
    deploy-backend.md
    smoke-test.md
    monitoring.md
    rollback.md

  runbooks/
    incident-nginx-502.md
    incident-consult-submit-failed.md
    incident-admin-login-failed.md
    incident-cloudfront-cache.md
    incident-db-migration.md

  releases/
    2026-08-12.md

  daily/
    2026-08-12.md

➕ 7-1. `docs/ops/README.md`

운영 문서 소개
배포 전 기본 루틴
장애 발생 시 확인 순서
주요 문서 링크

➕ 7-2. `docs/ops/environments.md`

local/development/staging/production 차이
DB/API URL 기준
주의할 환경변수
운영에서 금지할 값

➕ 7-3. `docs/ops/secrets-ssm.md`

SSM 경로 규칙
String/SecureString 기준
AWS profile 기준
GitHub Secrets 목록
Secret rotation 기준

➕ 7-4. `docs/ops/smoke-test.md`

고객 화면 Smoke Test
관리자 화면 Smoke Test
백엔드 Health Check
배포 후 로그 확인

문서는 많다고 좋은 것이 아닙니다.
실제로 열어서 따라 할 수 있어야 합니다.

✅ 8. 배포 전 최종 루틴

실제 배포 전에는 아래 루틴만 지켜도 사고 가능성이 줄어듭니다.

1. git status 확인
2. git diff 확인
3. AI diff 리뷰 선택적으로 실행
4. pnpm verify 실행
5. CI 통과 확인
6. env 변경 여부 확인
7. DB migration 여부 확인
8. 배포 위험도 판단
9. 롤백 가능성 확인
10. 배포 실행

➕ 8-1. 배포 전 멈춰야 하는 경우

verify 실패
CI 실패
운영 env 불명확
DB migration 영향 불명확
상담 신청 영향 확인 안 됨
관리자 로그인 영향 확인 안 됨
롤백 방법 불명확
Secret이 코드에 포함됨

배포 전 불안한 지점이 있으면 멈추는 것이 맞습니다.
운영에서는 빠른 배포보다 안전한 배포가 더 중요합니다.

✅ 9. 배포 후 최종 루틴

1. health check 확인
2. 운영 URL 접속
3. 고객 상담 신청 흐름 확인
4. 관리자 로그인 확인
5. 상담 목록/검색/상태 변경 확인
6. Nginx/Backend 로그 확인
7. API 5xx 증가 여부 확인
8. CloudFront 캐시 반영 확인
9. 배포 기록 작성
10. 남은 TODO 정리

➕ 9-1. 배포 후 바로 봐야 하는 에러

프론트 흰 화면
Chunk Load Error
CORS error
401/403 반복
API 500
Nginx 502
DB connection error
상담 신청 실패
관리자 로그인 실패

배포 후 확인은 짧고 집중적으로 해야 합니다.
가장 중요한 것은 상담 신청과 관리자 처리 흐름입니다.

✅ 10. 장애 발생 시 최종 루틴

1. 장애 등급 판단
2. 영향 범위 확인
3. 최근 배포 확인
4. 로그 확인
5. 임시 대응 결정
6. 롤백 또는 hotfix 판단
7. 복구 확인
8. 장애 기록 작성
9. 재발 방지 TODO 생성
10. Runbook 업데이트

➕ 10-1. 장애 판단 기준

P0:
사이트 전체 접속 불가

P1:
상담 신청 불가
관리자 로그인 불가
상담 처리 불가

P2:
일부 운영 기능 실패
알림톡/엑셀 실패

P3:
일부 UI 깨짐
문구/이미지 오류

➕ 10-2. 장애 대응에서 피해야 할 것

원인 모르고 서버만 반복 재시작
운영 DB를 감으로 수정
로그 없이 추측
장애 기록 없이 종료
롤백 기준 없이 계속 hotfix
Secret을 공유 채팅에 붙여넣기

장애는 침착하게 좁혀야 합니다.
빠른 대응과 무작정 대응은 다릅니다.

✅ 11. 보안 운영 최종 기준

DevOps에서 보안은 별도 과목이 아니라 모든 운영 절차에 포함됩니다.

➕ 11-1. 반드시 지킬 것

.env Git 커밋 금지
프론트 env에 Secret 금지
GitHub Actions 로그에 Secret 출력 금지
운영 DB를 로컬/CI 테스트에 사용 금지
DB/Redis 외부 포트 공개 금지
S3 public access 의도 없이 열지 않기
AWS IAM 최소 권한
AI에게 Secret/개인정보 제공 금지

➕ 11-2. 보안 점검 루틴

배포 전:
Secret 노출 여부 확인

공개 레포 전:
gitleaks detect

AWS 작업 전:
profile/region/account 확인

운영 장애 공유 전:
로그/스크린샷 마스킹

Secret 노출 의심:
즉시 rotation

보안은 일이 터지고 나면 수습이 어렵습니다.
습관으로 막는 것이 가장 싸고 빠릅니다.

✅ 12. 비용 운영 최종 기준

DevOps 운영에는 비용 관리도 포함됩니다.
AWS 비용은 작은 설정 실수로도 늘어날 수 있습니다.

➕ 12-1. 비용 확인 대상

EC2
RDS
S3
CloudFront
CloudWatch Logs
ECR
Data Transfer
NAT Gateway

➕ 12-2. 비용 관리 루틴

AWS Budgets 알림 설정
CloudWatch Logs 보관 기간 설정
S3 lifecycle 검토
안 쓰는 EBS/EIP/스냅샷 확인
RDS 스토리지 증가 확인
CloudFront 트래픽 확인

➕ 12-3. 1인 개발자 기준

월 1회 비용 점검
예상보다 증가하면 원인 확인
로그 저장 비용 방치하지 않기
미사용 리소스 정리

비용은 기술 문제가 아니라 운영 책임입니다.
특히 회사 AWS에서는 더 보수적으로 관리해야 합니다.

✅ 13. 백업과 복구 최종 기준

백업은 “있는 것”보다 “복구 가능한 것”이 중요합니다.

➕ 13-1. 백업 대상

RDS/PostgreSQL
S3 업로드 파일
SSM Parameter 목록
배포 artifact
GitHub repository
운영 문서

➕ 13-2. 복구 기준

DB snapshot에서 복구 가능한가?
S3 파일을 이전 버전으로 되돌릴 수 있는가?
이전 프론트 build로 롤백 가능한가?
운영 Secret을 재생성할 수 있는가?
Runbook으로 복구 절차를 따라 할 수 있는가?

➕ 13-3. 주의

백업 파일 Git 커밋 금지
운영 DB 덤프 로컬 저장 주의
개인정보 포함 dump 보관 주의
복구 테스트 없는 백업은 반쪽짜리

고객 데이터가 들어간 백업은 보안 자산입니다.
백업 파일을 함부로 내려받고 방치하면 또 다른 위험이 됩니다.

✅ 14. 운영 자동화를 성과로 바꾸기

DevOps 작업은 눈에 잘 보이지 않지만, 제대로 표현하면 강력한 성과가 됩니다.
단순히 “GitHub Actions 설정”이 아니라 “배포 전 검증 체계 구축”으로 표현해야 합니다.

➕ 14-1. 검증 체계

프론트엔드와 백엔드 배포 전 lint/test/typecheck/build 검증 흐름을 정리하고 GitHub Actions CI를 도입해 main branch 안정성과 운영 반영 전 검증 체계를 개선했습니다.

➕ 14-2. 배포 안정화

S3 + CloudFront 기반 프론트 배포 절차, 캐시 무효화 기준, Smoke Test 체크리스트를 정리해 배포 후 구버전 파일 노출 및 상담 신청 장애 가능성을 줄였습니다.

➕ 14-3. 관측성 개선

상담 신청, 관리자 로그인, 상태 변경 같은 핵심 이벤트의 성공/실패 로그 기준을 정리해 운영 장애 발생 시 원인 추적이 가능한 관측 기반을 마련했습니다.

➕ 14-4. 장애 대응 체계

Nginx 502, CloudFront 캐시, 상담 신청 실패, 관리자 로그인 실패 상황별 Runbook과 배포 후 Smoke Test를 문서화해 장애 대응 절차를 표준화했습니다.

➕ 14-5. Secret 관리

환경변수와 Secret을 로컬/개발/운영 기준으로 분리하고 AWS SSM Parameter Store 기반 관리 방안을 정리해 민감정보 노출 위험을 줄이는 구조를 설계했습니다.

이런 표현은 개발회사뿐 아니라 일반 회사에서도 이해됩니다.
핵심은 “운영 안정성, 실수 방지, 장애 대응 속도”입니다.

✅ 15. 다음 학습 방향

인프라/DevOps 운영 심화를 마무리했다면 다음은 3가지 방향으로 갈 수 있습니다.

➕ 15-1. 데이터베이스 실무 심화

주제:
PostgreSQL
Prisma
Index
Transaction
Lock
Query Optimization
Migration Strategy
Backup/Restore
Audit Log

적합한 이유:

상담/주문/상품/유입 데이터가 서비스 핵심
관리자 검색/필터 성능과 직접 연결
DB migration과 운영 안정성에 중요

➕ 15-2. 백엔드 아키텍처 고도화

주제:
Domain Service
Repository Pattern
Transaction Boundary
Queue/Worker
Event-driven
Webhook
ExportJob
Audit Log
Permission Policy

적합한 이유:

3사 프로젝트 확장
상담/주문/상태 변경 이력
엑셀 Export
알림톡/외부 API 연동에 중요

➕ 15-3. AI 업무 자동화 실전

주제:
local-llm-work-report
Git diff 요약
Notion 업로드
커밋 메시지 자동화
릴리즈 노트 자동화
장애 기록 자동화
QA 체크리스트 자동 생성

적합한 이유:

이미 진행 중인 local-llm-work-report와 직접 연결
작업 기록과 성과 자료화에 효과적
1인 개발자 생산성 향상

개인적으로는 다음 흐름으로 데이터베이스 실무 심화가 가장 좋습니다.
이유는 운영 안정성 다음에는 데이터 정합성, 검색 성능, migration 안정성이 실무에서 가장 크게 체감되기 때문입니다.

✅ 16. 추천 다음 시리즈

0813 데이터베이스 실무 심화 (1/N): PostgreSQL 기본 구조, 테이블과 관계 설계

➕ 16-1. 이어갈 주제 후보

0813:
PostgreSQL 기본 구조, 테이블과 관계 설계

0814:
Prisma Schema 설계와 Migration 전략

0815:
Index 기본, 검색/필터 성능 최적화

0816:
Transaction, 동시성 문제와 데이터 정합성

0817:
상담/주문 상태 변경 이력과 Audit Log 설계

0818:
Pagination, Sorting, 관리자 목록 조회 최적화

0819:
Soft Delete, 복구, 데이터 보존 정책

0820:
DB Backup, Restore와 운영 장애 대응

0821:
Query 분석, EXPLAIN과 느린 쿼리 개선

0822:
1인 개발자 DB 운영 체크리스트

이 흐름은 현재 관리자 상담 목록, 주문관리, 엑셀, 유입 분석, 상태 변경 이력과 직접 연결됩니다.
실제 프로젝트에 바로 반영하기 좋습니다.

✅ 17. 최종 실무 체크리스트

➕ 17-1. 개발환경

로컬/개발/스테이징/운영 환경이 구분되어 있는가?
OrbStack/Docker로 DB를 재현할 수 있는가?
새 Mac에서 실행 절차가 문서화되어 있는가?
.env.example이 최신인가?
운영 Secret이 로컬에 불필요하게 남아 있지 않은가?

➕ 17-2. 배포

pnpm verify 또는 npm run verify가 있는가?
GitHub Actions CI가 있는가?
프론트 S3/CloudFront 배포 절차가 문서화되어 있는가?
CloudFront invalidation 기준이 있는가?
백엔드 배포/재시작 절차가 있는가?
배포 후 Smoke Test가 있는가?
배포 기록을 남기는가?
롤백 기준이 있는가?

➕ 17-3. 운영

/health endpoint가 있는가?
Nginx/PM2/Docker 로그 확인법이 있는가?
상담 신청 실패 로그가 있는가?
관리자 로그인 실패 로그가 있는가?
상태 변경 실패 로그가 있는가?
API 5xx 증가를 확인할 수 있는가?
장애 기록 템플릿이 있는가?
주요 Runbook이 있는가?

➕ 17-4. 보안

.env가 Git에 올라가지 않는가?
프론트 env에 Secret이 없는가?
GitHub Actions 권한이 최소화되어 있는가?
SSM 개발/운영 경로가 분리되어 있는가?
DB/Redis 포트가 외부에 열려 있지 않은가?
S3 public access가 의도대로 관리되는가?
로그에 개인정보가 원본으로 남지 않는가?
Secret 노출 시 rotation 기준이 있는가?

➕ 17-5. 자동화/성과

AI diff 리뷰 프롬프트가 있는가?
커밋 메시지 자동화 기준이 있는가?
QA 체크리스트 자동 생성 기준이 있는가?
작업 요약 템플릿이 있는가?
릴리즈 노트 템플릿이 있는가?
local-llm-work-report와 연결 가능한가?
Notion/Markdown 기록 흐름이 있는가?
운영 개선을 성과 문장으로 정리할 수 있는가?

✅ 18. AI에게 운영 성숙도 점검을 맡길 때 좋은 질문법

온라인 휴대폰 판매몰을 1인 개발자로 운영하고 있어.

현재 구조:
1. 프론트는 React + Vite, S3 + CloudFront 배포
2. 백엔드는 NestJS + Prisma, PostgreSQL/RDS 사용
3. 로컬은 Mac + OrbStack PostgreSQL 사용
4. GitHub Actions CI/CD를 도입하려고 함
5. 환경변수와 Secret은 AWS SSM/GitHub Secrets로 관리하려고 함
6. 고객 핵심 흐름은 상품 상세 → 상담 신청
7. 관리자 핵심 흐름은 로그인 → 상담 목록 → 상태 변경
8. AI/Codex와 local-llm-work-report로 작업 기록 자동화를 하고 싶음

요청:
- 현재 운영 성숙도 Level 평가 기준
- 가장 먼저 보완할 10개 항목
- 배포 전/후 최종 루틴
- 장애 대응 최종 루틴
- 보안/비용/백업 체크리스트
- 문서 구조 추천
- 다음 학습 시리즈 추천
- 연봉협상/경력기술서에 쓸 성과 표현
을 실무 기준으로 정리해줘.

➕ 18-1. AI 답변 검증 기준

현재 규모에 비해 과한 구조를 강요하지 않는가?
상담 신청과 관리자 상담 처리를 핵심으로 보는가?
운영 DB/Secret/개인정보 위험을 낮게 보지 않는가?
배포 후 Smoke Test와 로그 확인을 포함하는가?
장애 기록과 Runbook 업데이트를 강조하는가?
성과 표현이 과장되지 않고 실무 효과 중심인가?

📌 요약

인프라/DevOps 운영 심화의 핵심은 최신 도구를 많이 쓰는 것이 아니라, 서비스를 안전하게 배포하고 장애를 빠르게 발견·복구·기록할 수 있는 체계를 만드는 것입니다.
현재 프로젝트에서 가장 중요한 운영 흐름은 고객의 상품 상세 → 상담 신청, 관리자의 로그인 → 상담 목록 → 상태 변경, 개발자의 검증 → 배포 → Smoke Test → 로그 확인 → 기록입니다.
운영 성숙도는 수동 운영 → 기본 검증 → 표준 배포 → 관측 가능한 운영 → 자동화된 운영 기록 → 안정적 운영 체계 순서로 올라갑니다.
지금 바로 적용할 핵심 10개는 verify, CI, Smoke Test, 배포 체크리스트, CloudFront/Nginx Runbook, 상담 신청 실패 로그, 배포 기록 템플릿입니다.
지금 당장 Kubernetes, 복잡한 Blue-Green, 모든 E2E 자동화 같은 과한 구조보다, 실제 운영 실수를 줄이는 작은 체계가 더 중요합니다.
배포 전에는 git diff → verify → CI → env/migration 확인 → 위험도 판단 → 롤백 가능성 확인을 지켜야 합니다.
배포 후에는 health check → 고객 상담 신청 → 관리자 로그인/상담 목록 → 로그 확인 → 배포 기록을 확인해야 합니다.
장애 발생 시에는 영향도 판단, 최근 배포 확인, 로그 확인, 임시 대응, 롤백/hotfix 판단, 장애 기록, Runbook 업데이트 순서로 움직여야 합니다.
Secret, 운영 DB, 개인정보, AWS 권한은 DevOps 전체에서 가장 조심해야 할 영역이며, AI에게 실제 값을 제공하면 안 됩니다.
다음 시리즈로는 데이터베이스 실무 심화가 가장 자연스럽고, 관리자 검색/필터, 주문/상담 상태 변경, migration 안정성, 유입 분석과 직접 연결됩니다.

juni

이전 포스트

TIL - 20260811

다음 포스트

TIL - 20260812

TIL

0812 인프라/DevOps 운영 심화 (10/N): 운영 성숙도 점검, 우선순위와 다음 성장 전략

✅ 1. 인프라/DevOps 운영 심화 마무리

➕ 1-1. DevOps를 배워야 하는 이유

✅ 2. 지금까지의 주제 요약

➕ 2-1. 0802 로컬/배포/운영 환경 구분

➕ 2-2. 0803 Docker, OrbStack과 개발 DB 운영

➕ 2-3. 0804 Nginx, Reverse Proxy와 HTTPS

➕ 2-4. 0805 S3 + CloudFront 정적 배포와 캐시 전략

➕ 2-5. 0806 GitHub Actions CI/CD 기본

➕ 2-6. 0807 환경변수, Secret 관리와 AWS SSM

➕ 2-7. 0808 로그, 모니터링과 장애 대응

➕ 2-8. 0810 배포 체크리스트와 Runbook

➕ 2-9. 0811 1인 개발자 운영 자동화 로드맵

✅ 3. 현재 운영 성숙도 점검 기준

➕ 3-1. Level 0: 수동 운영

➕ 3-2. Level 1: 기본 검증 운영

➕ 3-3. Level 2: 표준 배포 운영

➕ 3-4. Level 3: 관측 가능한 운영

➕ 3-5. Level 4: 자동화된 운영 기록

➕ 3-6. Level 5: 안정적 운영 체계

✅ 4. 지금 프로젝트 기준 가장 중요한 운영 흐름

➕ 4-1. 고객 핵심 흐름

➕ 4-2. 관리자 핵심 흐름

➕ 4-3. 배포 핵심 흐름

✅ 5. 지금 바로 적용할 10개 항목

➕ 5-1. 우선순위 이유

✅ 6. 운영 자동화에서 버려야 할 욕심

➕ 6-1. 지금 당장 과한 것

➕ 6-2. 지금 필요한 것

✅ 7. 운영 문서 구조 최종안

➕ 7-1. docs/ops/README.md

➕ 7-2. docs/ops/environments.md

➕ 7-3. docs/ops/secrets-ssm.md

➕ 7-4. docs/ops/smoke-test.md

✅ 8. 배포 전 최종 루틴

➕ 8-1. 배포 전 멈춰야 하는 경우

✅ 9. 배포 후 최종 루틴

➕ 9-1. 배포 후 바로 봐야 하는 에러

✅ 10. 장애 발생 시 최종 루틴

➕ 10-1. 장애 판단 기준

➕ 10-2. 장애 대응에서 피해야 할 것

✅ 11. 보안 운영 최종 기준

➕ 11-1. 반드시 지킬 것

➕ 11-2. 보안 점검 루틴

✅ 12. 비용 운영 최종 기준

➕ 12-1. 비용 확인 대상

➕ 12-2. 비용 관리 루틴

➕ 12-3. 1인 개발자 기준

✅ 13. 백업과 복구 최종 기준

➕ 13-1. 백업 대상

➕ 13-2. 복구 기준

➕ 13-3. 주의

✅ 14. 운영 자동화를 성과로 바꾸기

➕ 14-1. 검증 체계

➕ 14-2. 배포 안정화

➕ 14-3. 관측성 개선

➕ 14-4. 장애 대응 체계

➕ 14-5. Secret 관리

✅ 15. 다음 학습 방향

➕ 15-1. 데이터베이스 실무 심화

➕ 15-2. 백엔드 아키텍처 고도화

➕ 15-3. AI 업무 자동화 실전

✅ 16. 추천 다음 시리즈

➕ 16-1. 이어갈 주제 후보

✅ 17. 최종 실무 체크리스트

➕ 17-1. 개발환경

➕ 17-2. 배포

➕ 17-3. 운영

➕ 17-4. 보안

➕ 17-5. 자동화/성과

✅ 18. AI에게 운영 성숙도 점검을 맡길 때 좋은 질문법

➕ 18-1. AI 답변 검증 기준

📌 요약

TIL - 20260811

TIL - 20260813

0개의 댓글

➕ 7-1. `docs/ops/README.md`

➕ 7-2. `docs/ops/environments.md`

➕ 7-3. `docs/ops/secrets-ssm.md`

➕ 7-4. `docs/ops/smoke-test.md`