WEB-BE-05 · 배포·운영·장애 추적
내 컴퓨터의 localhost에서 실행한 프로그램은 기본적으로 그 컴퓨터에서만 접근합니다. 다른 사용자가 안정적으로 접속할 수 있는 환경에 코드를 옮기고 실행하는 과정을 배포라고 합니다. 배포 뒤에는 실행 여부, 오류와 성능을 계속 관찰하고 복구할 운영 책임이 생깁니다.
실행 환경 구분
| 환경 | 목적 | 기본 원칙 |
|---|---|---|
| 로컬 | 개인 개발과 빠른 확인 | 실습 데이터와 개발 설정 사용 |
| 개발(Dev) | 팀의 변경 통합·시험 | 운영과 분리된 계정·데이터 사용 |
| 스테이징(Staging) | 운영 반영 전 최종 확인 | 가능한 한 운영과 같은 설정 구조 사용 |
| 운영(Production) | 실제 사용자 서비스 | 승인된 변경·최소 권한·복구 절차 적용 |
모든 작은 프로젝트에 네 환경이 필요한 것은 아닙니다. 사용 인원, 데이터 민감도와 장애 영향을 기준으로 필요한 환경만 두되 운영 데이터와 실험용 데이터는 분리합니다.
설정과 비밀정보
코드와 환경마다 달라지는 주소·포트·기능 설정은 환경변수나 승인된 설정 저장소로 전달합니다. API 키·데이터베이스 비밀번호·토큰은 소스코드와 Git에 넣지 않고 승인된 비밀정보 관리 방법을 사용합니다.
브라우저용 환경변수는 빌드된 JavaScript에 포함될 수 있으므로 비밀정보 저장소가 아닙니다. 비밀키가 유출되면 코드에서 지우는 것만으로 끝내지 않고 즉시 폐기·재발급하고 접근 기록과 영향 범위를 확인합니다.
Docker와 CI/CD의 위치
Docker 이미지는 애플리케이션과 실행에 필요한 파일을 묶고 컨테이너는 그 이미지를 실행한 인스턴스입니다. 개발·시험·운영에서 비슷한 실행 환경을 재현하는 데 도움이 되지만 웹앱 배포의 필수 조건은 아닙니다.
컨테이너는 호스트의 커널과 CPU 구조 제약을 받습니다. Windows·Linux 또는 x86-64·ARM에서 같은 이름의 이미지를 사용하려면 대상 플랫폼을 지원하는 이미지인지 확인해야 합니다.
CI는 변경마다 필요한 검사와 빌드를 자동 실행하고, CD는 검증된 결과의 배포를 자동화합니다. 필요한 검사와 배포 흐름이 정해지기 전에 자동화를 크게 만들지 않습니다. 실행 횟수·시간·외부 서비스 비용과 실패 알림의 담당자를 함께 정합니다.
운영 상태를 관찰하는 세 가지 신호
| 신호 | 답하는 질문 | 예시 |
|---|---|---|
| 로그 | 어떤 사건과 오류가 발생했는가 | 요청 ID, 실패 단계, 정제한 오류 |
| 메트릭 | 상태가 시간에 따라 어떻게 변하는가 | 요청 수, 오류율, 응답 시간, CPU·메모리 |
| 트레이스 | 한 요청이 어느 구간에서 시간을 쓰고 실패했는가 | 프론트엔드 → API → DB 호출 구간 |
정상 요청마다 같은 성공 문구를 반복하기보다 운영자가 조치해야 하는 경고와 오류를 분명히 남깁니다. 로그에 비밀번호·토큰·불필요한 개인정보와 전체 요청 본문을 기록하지 않습니다. 로그 수집이 실패하더라도 최소 상태와 진단 자료를 확인할 대체 경로를 둡니다.
장애 추적 순서
- 같은 조건에서 문제를 재현하고 발생 시각을 기록합니다.
- 브라우저 Network에서 요청·응답과 상태 코드를 확인합니다.
- 같은 요청 ID나 시각의 백엔드 로그를 확인합니다.
- 데이터베이스 반영 여부와 외부 서비스 응답을 확인합니다.
- 원인을 고친 뒤 대표·경계·실패 사례와 기존 기능을 다시 검사합니다.
LAB-02 · 복구 지점과 오류 해결에서는 실습 서버 재시작과 체크포인트 복구를 구분합니다.
공식 근거
- Docker · 멀티 플랫폼 빌드 — 컨테이너의 OS·CPU 제약과 플랫폼별 이미지
- Docker · 지속적 통합 — 자동 빌드·시험에서 컨테이너를 사용하는 방법
- OpenTelemetry · 관측 가능성 입문 — 로그·메트릭·트레이스와 분산 요청 관찰
- OWASP · 비밀정보 관리 — 비밀정보의 저장·접근·교체와 감사