출시 후 운영 모니터링
신규 기능 출시를 앞두고 기존의 20배 부하를 처리해야 했습니다. 부하테스트와 30시간 soak test로 검증한 뒤 운영 환경에 안정적으로 배포했습니다.
운영 배포 전에 진행한 테스트 기록을 공유합니다.
출시 후에는 CPU 사용률과 API 응답 시간을 확인했습니다.
CPU 사용률
06~18시 CPU 사용률은 약 26% 이하였습니다.
- MAX: 오전 9시대 약 26% → 18시 무렵 약 9%
API 응답 시간
| API | avg | p95 |
|---|---|---|
/v1/pc/challenge/attendance | 24ms | 48ms |
/v1/pc/challenge/reward | 4ms | 48ms |
/v1/pc/challenge/today | 7ms | 48ms |
/v1/pc/challenge/token | 2ms | 48ms |
/v1/web/challenge/attendance | 24ms | 48ms |
/v1/web/challenge/board | 10ms | 48ms |
사내 버셀과 바이브독 비교
사내 버셀을 비개발자도 사용할 수 있게 만들고 싶습니다. 여기어때의 바이브독도 AI로 만든 서비스를 사내에서 배포하고 공유하는 플랫폼이라, 참고할 기능을 비교했습니다.
바이브독은 공개 글을 정리한 자료, 사내 버셀은 현재 구현을 기준으로 봤습니다. 바이브독의 운영 부담은 설계에 대한 제 판단이며, 공개되지 않은 기능은 미확인으로 표시했습니다.
현재 AI 호출 방식
사내 버셀도 AI 도구로 사용할 수 있습니다. API 문서를 제공해 AI가 호출하도록 안내하고 있습니다. GitHub의 코드 변경을 감지해 테스트하고 배포하며, 배포 실패 시 복구와 데이터 보존도 구현했습니다.
다음 목표는 API의 기능·입력·호출 방법을 메타데이터로 제공하는 것입니다. MCP 연결도 계획에 포함돼 있습니다.
기능별 비교
바이브독은 AI에 배포를 요청하거나 화면·Git push로 배포합니다. 사내 버셀은 GitHub의 main에 push하면 자동으로 배포됩니다.
AI 도구에서 배포를 요청할 때 바이브독은 MCP를, 사내 버셀은 API 문서를 사용합니다.
바이브독의 내부 API 메타데이터 구조는 공개 자료만으로 확인하지 못했습니다.
| 항목 | 바이브독 | 사내 버셀 |
|---|---|---|
| 배포 방식 | AI 요청·화면·Git push | GitHub에 push → 자동 배포 |
| 지원 범위 | 정적 웹·백엔드 | FastAPI |
| 소스 관리 | 대리 commit·충돌 처리 | GitHub commit 기준 배포 |
| 실패 복구 | 공개 글에서 미확인 | 이전 이미지·데이터 복구, 교체 중 중단 |
| 데이터·API | API 인증 중계·Secret 주입 | SQLite·파일 보존 |
| 운영 환경 | AWS·사내 CI | 단일 서버·PostgreSQL |
| 보안 | Secret 검사·배포 권한 분리 | 관리 API 인증, Worker만 Docker 접근 |
| 사용 지표 | 배포 사용자 | 사용자 활동·배포 성공률 |
사용자 대신 처리할 일이 늘면 사내 버셀의 운영 부담도 커집니다. 특히 대리 commit과 자동 merge는 충돌 처리와 권한 관리까지 맡아야 하므로, 바로 도입하기는 부담스럽습니다.
바이브독 사례에서 적용해볼 기능
바이브독 사례를 참고해 두 기능을 적용해보려고 합니다.
- API connector: 앱에서 사내 API를 사용할 수 있도록 인증을 중계합니다. 실제 수요가 있는 읽기 전용 API부터 검토하려고 합니다.
- Secret 검사·수정 안내: 배포 전에 코드의 Secret을 탐지하고 수정 방법을 안내합니다. 오류 응답이나 로그에도 Secret이 노출되지 않도록 해야 합니다.
사내 적용 전 확인할 것
팀에 공개하기 전에는 개인 Mac과 SSH 연결 없이 사용할 수 있는 환경이 필요합니다. 도입 효과는 첫 배포까지 걸린 시간과 운영자 도움 없이 배포한 비율로 확인하려고 합니다.