새벽 04:00 운영 배포를 시작하지 않았습니다. 확인할 건 한 건입니다.
- 배포 전 점검
- 8개
- 통과
- 7개
- 배포 보류
- 1건
- 1RST-0930-03: 9/30 03:00 백업을 복원해 보니 테이블 41개 중 40개만 살아났습니다. reservation_logs가 백업 대상에서 빠져 있습니다.
- 2중단 조건 ②에 따라 배포를 보류했고, 운영은 9/25 배포 그대로입니다. 백업 목록 수정 PR과 배포 계획서 v3, 롤백 절차 초안을 준비했습니다.
개발 및 운영(DevOps) 에이전트
21:40새벽 운영 배포를 앞둔 밤
GitHub에서 한 번,
로그 창에서 한 번,
Slack 채널에서 또 한 번.
배포하는 밤이면 창 여섯 개를 번갈아 열어 손으로 확인했습니다.
맡길 범위만 정해 주세요.
되돌릴 길은 제가 먼저 만듭니다.
쓰던 GitHub와 배포 도구에 권한을 연결하면, 에이전트가 배포 계획서와 롤백 절차를 먼저 쓰고 백업이 실제로 복원되는지 확인합니다. 내보낼지는 사람이 정합니다.
지금 운영 중
배포 전 백업 복원 리허설열린 PR·검사 결과 한 장 요약배포 후 헬스체크 확인보호 경로 변경은 사람 승인 대기결정·승인·실행 기록 정리
22:00권한 연결
맡긴 만큼만 합니다.
한 일은 전부 남깁니다.
어디까지 맡길지는 스위치로 정합니다. 환경 변수와 키 파일은 열어 보지 않고, 에이전트가 한 모든 조작은 시각과 결과까지 기록으로 남습니다.
맡긴 범위
- 읽기코드·검사 결과·배포 상태허용
- 복원 리허설실제로 복원해 보기허용
- PR·배포 실행승인한 건만승인 후
- 기본 브랜치 수정·강제 덮어쓰기하지 않음안 함
작업 기록
- GitHub권한 연결저장소 2곳 · 읽기와 초안 PR성공
- GitHub검사 결과 조회PR #482 · 38개보관
- Vercel미리보기 헬스체크5개 경로200
- AWS백업 확인9/30 03:00 백업 파일보관
- AWS복원 리허설RST-0930-03 · 테이블 41개 중 40개확인 요청
- Vercel배포 시작 안 함중단 조건 ② · 04:00 배포보류
- GitHub초안 등록승인 3건 · 초안 PR #486등록 완료
23:40그 시각 에이전트가 하는 일
여덟 단계를 거쳐 배포까지,
사람은 승인할 곳에서만 부릅니다.
- 01
원래는요청은 메신저와 회의록에 흩어져 있어, 무엇까지 되면 끝인지 배포 직전에 다시 묻습니다.
이제는요청을 모아 영향 범위와 검수 기준까지 한 장으로 정리해 둡니다.
- 02
원래는무엇을 바꾸고 어떻게 되돌릴지는 머릿속에만 있고, 검토는 코드가 다 된 뒤에 시작합니다.
이제는범위·영향·되돌리는 방법을 고칠 수 없는 판본으로 올리고, 서로 승인한 범위만 만듭니다.
- 03
원래는배포 전 점검은 체크리스트를 눈으로 훑고, 문제가 생기면 로그 수천 줄을 거슬러 올라갑니다.
이제는점검 항목마다 통과·실패를 판정하고, 실패하면 원인을 한 줄로 짚어 둡니다.
- 04
원래는배포 버튼은 되돌릴 방법을 확인하기 전에 눌리고, 무엇을 했는지는 기억에만 남습니다.
이제는되돌릴 방법이 확인되지 않으면 배포를 멈추고, 판단 근거와 함께 사람에게 올립니다.
03:40배포 전 점검 · 복원 리허설 · 중단
배포하기 전에 되돌릴 길부터 확인하고,
복원되지 않는 백업 하나를 찾아냅니다.
9월 30일 04:00 운영 배포 · 배포 계획서 v2점검 중 0%
| 점검 | 항목 · 대상 | 결과 | 소요 | 판정 |
|---|---|---|---|---|
| CHK-01 | 커밋·대상 환경운영 · 커밋 a3f9c21 | 계획서와 일치 | — | 통과 |
| CHK-02 | 검사(CI)PR #482 · 예약 취소 사유 | 38개 중 38개 통과 | 6분 12초 | 통과 |
| 변경 규모PR #479 · 의존성 갱신 | 1,842줄 · 자동 생성 1,796줄 | — | 통과 | |
| CHK-04 | 데이터 구조 변경마이그레이션 2개 · 보호 경로 | 사람 승인 9/29 19:10 | — | 통과 |
| 복원 리허설9/30 03:00 백업 → 점검용 DB | 테이블 41개 중 40개 | 18분 | 중단 | |
| CHK-06 | 설정 항목Vercel 운영 · 값은 열람 안 함 | 12개 중 12개 있음 | — | 통과 |
| CHK-07 | 미리보기 헬스체크Vercel 미리보기 | 5개 경로 200 | 1분 40초 | 통과 |
| CHK-08 | 롤백 지점직전 배포 9/25 · 커밋 7c1e0b4 | 되돌리기 가능 | — | 통과 |
배포 전 점검 8개 항목 · 배포 계획서 v2 · 표시된 항목을 눌러 보세요
08:30출근
출근하면,
멈춘 배포와 그 이유가 먼저 보입니다.
08:34승인
멈춘 이유와 고칠 방법,
승인하면 그대로 올립니다.
작업 초안 3건
| 초안 PR | #486 백업 대상에 reservation_logs 추가 | 리뷰 요청 |
| 배포 계획 | 운영 · 10/1 04:00 · 커밋 a3f9c21 | 복원 통과 후 |
| 중단 조건 | 복원된 테이블 41개 미만 | 배포 안 함 |
| 롤백 절차 | 직전 배포 9/25 · 되돌리기 스크립트 2개 | 리허설 포함 |
GitHub변경 요청 · 배포 기록| 일자 | 구분 | 내용 | 상태 | 올린 이 |
|---|---|---|---|---|
| 09-29 | 배포 계획 | 운영 · 9/30 04:00 · 커밋 a3f9c21 | 승인됨 | 운영 책임자 |
초안을 승인하면 여기에 올라갑니다.
10:20질문
메뉴를 찾지 말고,
물어보세요.
답에는 늘 근거가 된 점검 항목과 기록이 붙습니다. 연결되지 않은 도구로 한 일은 했다고 말하지 않습니다.
새벽 배포 왜 멈췄어?
복원 리허설(RST-0930-03)에서 9/30 03:00 백업이 테이블 41개 중 40개만 복원됐기 때문입니다. 빠진 reservation_logs는 오늘 마이그레이션이 바꾸는 테이블이라, 문제가 생기면 되돌릴 수 없었습니다. 중단 조건 ②에 따라 시작하지 않았고, 운영은 9/25 배포 그대로입니다.
- 점검 RST-0930-03
- 배포 계획서 v2 중단 조건 ②
- 복원 기록 03:22~03:40
연결하는 시스템
어떤 도구로 배포하든,
하는 일은 같습니다.
시스템에이전트가 하는 일
GitHub- 커밋·변경 요청·검사 결과 요약
- 승인한 변경을 초안 PR로 올리기
Vercel- 배포 상태·미리보기 헬스체크 확인
- 설정 항목은 값을 보지 않고 있는지만 확인
Supabase- 데이터 구조 변경·접근 정책 검토
- 적용 결과가 의도대로인지 확인
AWS- 서버·데이터베이스·백업 보관 상태 확인
- 복구 절차가 실제로 동작하는지 점검
Slack- 아침 배포 브리핑 게시
- 질문에 점검 기록 근거로 답변
요금
맡길 만큼 고르고,
넘으면 쓴 만큼만.
구독 플랜마다 매달 쓸 수 있는 사용량(포함 작업량)이 정해져 있고, 한도를 넘는 추가분은 쓴 만큼 내는 종량 요금(크레딧)으로 적용됩니다. 널리 쓰이는 AI 구독 서비스와 같은 방식입니다.
01
문구·설정 손질
화면 문구와 기본값을 조정합니다
02
쓰던 화면 확장
기존 화면에 필터나 항목을 더합니다
03
새 기능 하나
새 화면과 저장·검증을 만듭니다
04
여러 화면에 걸친 개편
업무 흐름을 여러 화면에 걸쳐 바꿉니다
05
새 모듈
새 업무 영역을 엽니다
Starter
작은 손질부터 맡깁니다
19만원 / 월
VAT 별도
월 포함 작업량 · 대략 이 정도
문구·설정 손질 3건 안팎
- ✓ 월 포함 작업량
- ✓ 작업 증적·승인 기록
- ✓ 정책집·워크플로 기반 실행
Plus
기능 하나를 통째로 맡깁니다
99만원 / 월
VAT 별도
월 포함 작업량 · 대략 이 정도
새 기능 1건 + 쓰던 화면 확장 1건 안팎
또는 쓰던 화면 확장 4건 안팎
- ✓ 월 포함 작업량
- ✓ 작업 증적·승인 기록
- ✓ 정책집·워크플로 기반 실행
- ✓ 초과분은 종량 크레딧으로 이어서
Pro
팀의 개발·운영을 맡깁니다
299만원 / 월
VAT 별도
월 포함 작업량 · 대략 이 정도
새 기능 5건 안팎
또는 여러 화면에 걸친 개편 3건
또는 새 모듈 2건
- ✓ 월 포함 작업량
- ✓ 작업 증적·승인 기록
- ✓ 정책집·워크플로 기반 실행
- ✓ 우선 처리
- ✓ 초과분은 종량 크레딧으로 이어서
Business
조직의 요건에 맞춰 운영합니다
협의
VAT 별도
월 포함 작업량 · 대략 이 정도
필요한 만큼 함께 산정합니다
- ✓ 월 포함 작업량 협의
- ✓ 보안·감사 요건 대응
- ✓ 도입 지원
- ✓ 초과분은 종량 크레딧으로 이어서
- · 환산은 이해를 돕는 예시입니다. 실제 소모량은 작업의 복잡도에 따라 달라집니다.
- · 포함된 작업량을 다 쓰면 추가 크레딧으로 이어서 사용할 수 있습니다.
- · 착수 전에 작업별 예상 크레딧을 먼저 안내합니다.
- · 플랫폼 결함으로 다시 시도한 작업은 차감하지 않습니다.
- · 가격은 정식 출시 전에 조정될 수 있습니다.
브로셔로 먼저 살펴보세요
브로셔 내려받기 ⤓하는 일과 8단계 승인 흐름, 안전장치와 요금을 PDF 한 부에 담았습니다.
- 01조직을 만듭니다
함께 일할 사람을 초대하고 역할을 정합니다.
- 02정책집과 워크플로를 정합니다
승인 기준과 금지 사항, 예외 처리 방법을 문서로 정해 둡니다.
- 03첫 작업부터 같은 절차로
요청 하나를 맡기면 변경 요청서부터 배포 기록까지 같은 순서로 진행합니다.