운영과 팀 도입
“나만 쓰는 노하우는 노하우가 아니다”
02이 차시를 마치면
- 1.CI/CD로 배포를 자동화하고, 문제가 생기면 이전 버전으로 되돌리는 롤백 절차를 실행할 수 있다.
- 2.프로덕션과 분리된 스테이징 환경을 구성해 위험 없이 먼저 확인할 수 있다.
- 3.로그·에러 추적 도구를 연결해 사용자가 알리기 전에 문제를 먼저 파악할 수 있다.
- 4.무료 티어에서 유료로 전환할 시점을 판단 기준에 따라 결정하고, AI 사용 토큰/비용 예산을 세울 수 있다.
- 5.타인이 15분 안에 세팅할 수 있는 온보딩 문서를 작성할 수 있다.
03왜 필요한가
지금까지는 혼자 만들고 혼자 배포해왔다. 그런데 이제 이 프로젝트를 동료에게 넘기거나, 팀원과 함께 이어가야 하는 시점이 왔다. 배포는 되어 있지만 '어떻게 배포했는지', '문제가 생기면 어떻게 되돌리는지'는 전부 자신의 머릿속에만 있다. 새 팀원이 합류하면 매번 화면 공유로 한 시간씩 설명해야 하고, 배포 도중 사고가 나면 밤늦게 혼자 복구해야 한다.
- 배포가 수동이라 매번 같은 명령어 순서를 기억해야 하고, 한 단계라도 빼먹으면 사고로 이어진다.
- 잘못 배포했을 때 되돌리는 절차를 미리 연습해두지 않아, 막상 필요한 순간 방법을 찾느라 시간을 허비한다.
- 에러가 나도 로그를 볼 방법이 없어 사용자가 신고할 때까지 문제를 모른다.
- 나만 아는 세팅 방법이라 팀원에게 인계할 때마다 몇 시간씩 붙어서 설명해야 한다.
04개념 설명
배포 자동화와 롤백 — 사람이 개입하지 않아도 안전하게
CI/CD(지속적 통합·배포)는 코드를 저장소에 올리면 테스트→빌드→배포까지 자동으로 이어지는 절차다. 자동화의 진짜 가치는 속도가 아니라 '같은 실수를 반복하지 않는 것'과 '언제든 되돌릴 방법이 준비돼 있는 것'에 있다.
롤백은 배포가 잘못됐을 때 이전에 정상 동작했던 버전으로 되돌리는 절차다. 이 절차는 사고가 난 다음에 급하게 찾는 것이 아니라, 사고가 나기 전에 미리 만들어두고 한 번 연습해봐야 하는 것이다.
- 저장소에 push하면 테스트와 배포가 자동으로 이어진다
- 테스트가 실패하면 배포가 자동으로 중단된다
- 이전 버전으로 되돌리는 절차를 문서로 만들고 실제로 한 번 실행해본다
스테이징과 관측 — 사용자 앞에서 실험하지 않는다
스테이징은 프로덕션(실제 서비스)과 거의 동일한 환경을 하나 더 만들어, 실사용자에게 영향을 주지 않고 먼저 확인하는 공간이다. 무료 티어 안에서도 별도 프로젝트나 브랜치 미리보기 기능으로 충분히 구현할 수 있다.
관측(로그·에러 추적)은 배포 후 서비스 안에서 무슨 일이 일어나는지 지켜보는 장치다. 사용자가 문의하기 전에 에러 발생 사실을 먼저 아는 것과, 사용자의 항의로 처음 아는 것은 대응 속도가 완전히 다르다.
| 환경 | 역할 |
|---|---|
| 스테이징 | 실사용자 영향 없이 먼저 확인 |
| 프로덕션 | 실제 서비스 |
| 관측 (로그 · 에러 추적) | 문제를 사용자보다 먼저 안다 |
- 프로덕션과 분리된 별도 환경변수·URL을 만든다
- 배포 전 마지막 확인은 항상 스테이징에서 한다
- 에러가 발생하면 알림이 오도록 로그·에러 추적 도구를 연결한다
비용 감각 — 무한정 쓸 수 있는 자원은 없다
무료 티어는 영원하지 않다. 사용량이 늘면 언제 유료로 전환해야 하는지 판단하는 기준이 필요하다 — 트래픽이 무료 한도에 자주 걸리는지, 서비스가 잠들었다 깨는 지연이 사용자 경험을 해치는 수준인지가 대표적인 신호다.
AI 사용 비용도 마찬가지다. 모든 작업에 가장 성능 좋은(비싼) 모델을 쓸 필요는 없다. 간단한 반복 작업과 복잡한 설계 작업에 서로 다른 모델을 쓰는 감각이 비용을 관리하는 실질적인 방법이다.
| 신호 | 전환 판단 |
|---|---|
| 무료 한도 도달 빈도 | 자주 걸리면 유료 전환 검토 |
| 콜드 스타트 지연 | 사용자 경험을 해치면 검토 |
| 작업 난이도 | 간단하면 가벼운 모델, 복잡하면 고성능 모델 |
- 무료 한도 도달 빈도와 지연 체감을 유료 전환 신호로 삼는다
- 간단한 작업엔 가볍고 빠른 모델을, 복잡한 설계엔 성능이 높은 모델을 쓴다
- 월 단위 토큰/비용 예산을 정하고 사용량 알림을 설정한다
팀 도입 — 이양 가능한 저장소와 온보딩 문서
나만 아는 노하우는 조직 입장에서는 없는 것과 같다. 이 과정의 마지막 목표는 '타인이 15분 안에 이 저장소를 내려받아 실행할 수 있는 상태'를 만드는 것이다.
온보딩 문서는 설명을 위한 글이 아니라 순서대로 따라 하면 되는 절차다. 실제로 다른 사람에게 그 문서만 주고 따라 하게 해봐야 빠진 부분이 드러난다.
- 설치부터 실행까지 순서대로 따라 할 수 있는 절차로 작성한다
- 환경변수·계정 등 사람마다 달라지는 값은 별도로 표시한다
- 작성한 문서를 실제로 다른 사람에게 테스트받는다
05실습 가이드
1. 배포 자동화(CI/CD) 설정하기
- P10-1 프롬프트로 AI에게 저장소에 push하면 자동으로 테스트와 배포가 실행되는 파이프라인 설정을 요청한다.
- 설정 파일을 프로젝트에 추가하고, 실제로 코드를 한 줄 바꿔 push해서 자동 실행되는지 확인한다.
- 테스트를 일부러 실패하게 만들어, 배포가 자동으로 중단되는지도 확인한다.
예상 결과 — push할 때마다 테스트와 배포가 자동으로 실행되고, 테스트 실패 시 배포가 멈춘다.
안 될 때 — 파이프라인이 실행 안 되면 설정 파일 위치나 문법 오류일 가능성이 높다. 실행 로그 메시지를 그대로 P10-5(복구 프롬프트)에 붙여 물어본다.
2. 롤백 절차 만들고 실제로 연습하기
- P10-2 프롬프트로 AI에게 방금 만든 배포 자동화에서 이전 버전으로 되돌리는 절차를 요청한다.
- 일부러 오류가 있는 코드를 배포한 뒤, 만들어둔 절차대로 실제로 롤백해본다.
- 걸린 시간과 단계를 온보딩 문서 초안에 그대로 기록해둔다.
예상 결과 — 일부러 낸 오류를 롤백 절차대로 되돌려 정상 버전으로 복구한다.
안 될 때 — 롤백 후에도 오류가 남아있으면 캐시나 배포 플랫폼 쪽 지연일 수 있다. 몇 분 기다린 뒤 다시 확인하고, 그래도 안 되면 배포 플랫폼의 배포 이력 화면에서 직접 이전 버전을 선택한다.
3. 스테이징 환경 구성하기
- 현재 프로덕션과 별도로 쓸 수 있는 스테이징용 프로젝트(또는 브랜치 미리보기)를 만든다.
- 환경변수를 프로덕션과 분리해서 등록한다 — 특히 결제·메일 발송처럼 실제로 동작하면 곤란한 기능은 테스트용 값으로 바꾼다.
- 앞으로 배포 순서를 '스테이징 확인 → 문제 없으면 프로덕션'으로 정하고 문서에 적어둔다.
예상 결과 — 프로덕션과 분리된 스테이징 주소가 생기고, 그곳에서 먼저 확인하는 절차가 정해진다.
안 될 때 — 환경변수를 분리하는 방법이 헷갈리면 지금 쓰는 배포 플랫폼에서 '환경별 변수' 설정 기능을 AI에게 물어 확인한다.
4. 로그·에러 추적 도구 연결하기
- P10-3 프롬프트로 AI에게 에러 발생 시 알림을 받을 수 있는 방법을 요청한다.
- 안내받은 도구 또는 방법을 연결하고, 일부러 에러를 발생시켜 알림이 실제로 오는지 확인한다.
- 알림이 너무 잦으면 놓치게 되므로, 심각한 에러만 알림 가도록 기준을 조정한다.
예상 결과 — 일부러 낸 에러가 로그에 남고, 설정한 채널로 알림이 온다.
안 될 때 — 알림이 안 오면 연결 설정(키, 프로젝트 ID 등)이 빠졌을 가능성이 크다. 설정 화면을 다시 확인하고, 안내 문서의 연결 단계를 순서대로 다시 따라간다.
5. 무료→유료 전환 판단 기준 정리하기
- 지금 쓰는 서비스(배포·DB 등)의 무료 한도와 현재 사용량을 확인한다.
- 한도에 자주 걸리는지, 무료 서버가 잠들었다 깨는 지연이 실제 사용자에게 문제가 되는 수준인지 점검한다.
- 이 두 신호를 기준으로 '지금은 무료로 충분하다' 또는 '이 지점에서 유료로 전환한다'를 문서 한 문단으로 정리한다.
예상 결과 — 현재 사용량 대비 무료/유료 전환 판단 기준이 문서로 정리된다.
안 될 때 — 판단이 애매하면 P10-6 프롬프트로 AI에게 현재 사용량 수치를 주고 일반적인 전환 시점 기준을 물어본다.
6. AI 토큰/비용 예산 세우고 모델 선택 기준 만들기
- 최근 한 달간 AI 사용 내역(가능하다면)을 확인해 월 예산 상한을 정한다.
- P10-6 프롬프트로 AI에게 상황별(간단한 반복 작업 vs 복잡한 설계 작업)로 어떤 모델을 쓰는 게 적절한지 기준을 요청한다.
- 정리된 기준을 온보딩 문서에 '이 프로젝트에서 AI를 쓰는 방식' 항목으로 추가한다.
예상 결과 — 월 예산 상한과 상황별 모델 선택 기준이 문서 한 항목으로 정리된다.
안 될 때 — 사용 내역을 확인할 방법을 모르겠으면, 사용 중인 도구의 사용량/청구 화면 이름을 AI에게 물어 안내받는다.
7. 온보딩 문서 작성하기
- P10-4 프롬프트로 AI에게 이 프로젝트를 처음 받는 사람이 15분 안에 실행 화면까지 볼 수 있는 절차 문서를 요청한다.
- 설치, 환경변수 설정, 실행, 스테이징/프로덕션 배포, 롤백 절차까지 순서대로 포함시킨다.
- 가능하면 팀원이나 지인에게 이 문서만 주고 실제로 따라 해보게 한 뒤, 막힌 지점을 보완한다.
예상 결과 — 처음 보는 사람이 문서만 보고 15분 안에 프로젝트를 실행 화면까지 띄울 수 있다.
안 될 때 — 15분을 넘기면 어느 단계에서 막혔는지 확인하고, 그 단계만 더 자세히 쪼개거나 스크린샷을 추가한다.
8. 캡스톤 발표 준비하기
- 1~7단계에서 만든 파이프라인, 롤백 절차, 스테이징 환경, 로그 연결, 비용 기준, 온보딩 문서를 하나의 저장소로 모은다.
- 중급과정 전체에서 무엇이 왜 무너졌었고(1차시), 무엇으로 통제했는지(2~9차시)를 짧게 되짚어 발표 흐름을 구성한다.
- 발표 자료에 실제 동작 화면(배포, 롤백, 알림)을 스크린샷 또는 짧은 시연으로 포함시킨다.
예상 결과 — 이양 가능한 파이프라인 저장소와 온보딩 문서, 그리고 이를 설명하는 발표 자료가 준비된다.
안 될 때 — 시간이 부족하면 모든 차시를 다 언급하려 하지 말고, 가장 인상 깊었던 문제와 그것을 해결한 장치 한두 가지에 집중해 발표를 구성한다.
06실전 프롬프트
07이것만은 주의
무슨 일이 생기나 — 실제 사고가 난 순간 처음 그 절차를 따라 하면, 문서에 빠진 단계나 잘못된 순서를 그제서야 발견하게 된다.
대처 — 이번 차시 안에 일부러 오류를 배포하고 실제로 롤백까지 한 번 완주해본다.
무슨 일이 생기나 — 분리했다고 생각했지만 환경변수를 잘못 복사해 스테이징에서 실험한 내용이 실제 프로덕션 데이터에 영향을 준다.
대처 — 배포 전에 환경변수 값 자체(키, DB 주소)가 서로 다른지 직접 확인한다.
무슨 일이 생기나 — 에러가 많이 발생하는 시기에 로그 저장 한도를 초과해, 정작 중요한 시점의 로그가 잘려 나간다.
대처 — 로그·모니터링 도구의 무료 한도도 다른 무료 서비스와 똑같이 확인하고 알림을 설정한다.
무슨 일이 생기나 — 본인은 이미 알고 있는 전제를 생략하고 적어서, 실제로 다른 사람이 따라 하면 중간에 막힌다.
대처 — 작성 후 반드시 다른 사람에게 문서만 주고 따라 하게 해서 걸리는 시간과 막히는 지점을 확인한다.
무슨 일이 생기나 — 무료 플랜의 DB나 서버는 일정 시간 접속이 없으면 잠들고, 깨어나는 첫 응답이 느려 발표 중 '고장난 것처럼' 보인다.
대처 — 발표 몇 분 전에 미리 접속해 깨워두고, 첫 화면 로딩까지 확인한다.
08자가 점검
09과제
지금까지 중급과정에서 다룬 컨텍스트 관리, 스펙 기반 개발, 자동화, 훅과 CI, MCP, 멀티에이전트, 프로덕션 품질 점검을 거쳐온 자신의 프로젝트를, 이번 차시에서 배포 자동화·롤백·스테이징·로그 추적·비용 기준·온보딩 문서까지 갖춘 상태로 마무리한다. 이를 캡스톤 발표 자료로 정리해 중급과정 전체를 마무리한다.
제출 형식 — ① 저장소 링크(CI/CD 설정, 롤백 절차 포함) ② 온보딩 문서 ③ 다른 사람이 온보딩 문서로 세팅을 테스트한 결과(걸린 시간 포함) ④ 캡스톤 발표 자료(문제 진단 → 해결 과정 → 최종 산출물 요약)를 하나로 묶어 제출한다.
10더 알아보기
- 무료 배포 서비스 최신 한도표 — 유료 전환 판단 전 최신 수치 재확인용
- 사용 중인 배포 플랫폼의 롤백/모니터링 공식 문서 — 세부 화면과 메뉴는 플랫폼마다 다르므로 실습 직전 확인
- CI/CD
- — 코드를 저장소에 올리면 테스트·빌드·배포가 자동으로 이어지는 절차(지속적 통합·지속적 배포).
- 스테이징
- — 프로덕션과 분리해 배포 전 마지막으로 확인하는 환경.
- 롤백
- — 문제가 생긴 배포를 이전 정상 버전으로 되돌리는 절차.
다음 차시 예고 — 이것으로 중급과정 10차시를 마칩니다. 여기서 멈추지 않고 더 나아가고 싶다면 확장 트랙을 참고하세요 — 내 서비스에 AI 기능을 직접 넣는 EXT-A, 문서 검색과 RAG를 다루는 EXT-B, 모바일 앱으로 같은 파이프라인을 재사용하는 EXT-C, 조직 도입과 거버넌스를 다루는 EXT-D까지 네 갈래로 이어집니다.