개발에서 운영까지

한눈에 보는 개발·배포 흐름도

역할을 어디에 둘 것인가

local · MacBook

사람이 개발을 주도하고 에이전트에게 지시·협업. 에이전트가 코드 수정·로컬 테스트·커밋·push·PR 실행

GitHub · Git / CI

CI·자동 리뷰·dev/main 자동 병합·verify에 연결된 릴리스 자동 발행

tom · staging

main 자동 설치·스모크 + 고강도 자동 테스트·검증. 사람이 실제로 사용해볼 환경 제공

사람 · 1번과 6번

1번 개발 지시·에이전트 협업. 6번 tom 실사용 후 OK하면 해당 커밋의 verify를 에이전트에게 지시

ome-on · 운영

verify에 연결된 릴리스 태그 자동 설치·운영 스모크·서비스 실행

bean · 별도 테스트 호스트

5번 이후 tom, 8번 이후 ome-on에 접속해 주기적으로 실사용 시나리오를 실행하고 결과·대상 버전 기록

local 테스트는 개발 중 빠른 피드백입니다. 공식 CI는 GitHub가 실행합니다. tom은 main을 병합하지 않고, 병합된 코드를 설치·검증합니다. 별도 dev 테스트 호스트는 이 개선안의 필수 구성에 넣지 않습니다.

검증과 승격을 나눈 8단계

1. 사람 + 에이전트 개발·테스트

   사람이 주도 / MacBook — 사람이 작업을 정하고 에이전트에게 개발을 지시하며 결과를 보면서 협업합니다. 에이전트가 dev에서 작업 브랜치를 만들고 코드 수정·로컬 테스트·커밋·push·PR을 수행합니다.

   다음 조건: 개발 결과와 테스트 근거를 갖춘 PR. 이후 병합·배포마다 별도 사람 승인 단계는 두지 않습니다.

2. 작업 PR → dev 자동 병합

   GitHub / 자동 — PR CI와 정해진 자동 리뷰·품질 검사를 통과한 변경을 dev에 병합합니다. 사람의 PR 리뷰·승인 단계는 두지 않습니다.

   다음 조건: 작업 PR의 최신 변경에 대한 필수 자동 검사 충족.

3. 합쳐진 dev의 CI

   GitHub Actions / 자동 — dev 병합 결과를 테스트·빌드·린트합니다. 개별 작업 브랜치의 통과 결과로 대신하지 않습니다.

   다음 조건: 승격할 dev 커밋의 필수 CI 통과. 실패하면 중단·보고하고 수정 뒤 재검사합니다.

4. dev → main 자동 승격

   GitHub / 자동 — 승격 PR을 만들고 dev CI·승격 PR의 필수 자동 검사를 충족하면 일반 병합합니다. 사람의 승인 단계는 두지 않고 tom에 병합 책임을 두지 않습니다.

   다음 조건: 최신 dev와 main 조합에 필요한 검사가 유효하고 자동 병합 보호 규칙 충족. 기준 코드가 바뀌면 다시 검사.

5. tom 설치·스모크 + 고강도 테스트·검증

   tom / 자동 — main의 특정 커밋을 설치하고 스모크로 기본 기동·연결을 확인한 뒤, 실제 DB·모델·서비스를 사용하는 강도 높은 자동 테스트·검증을 수행합니다. 예를 들어 통합·E2E·회귀·실패 경로와 데이터 보존을 검증하며 구체 항목·기준은 테스트 명세로 정합니다. 설치 SHA와 결과·근거를 기록합니다.

   다음 조건: 설치·스모크·필수 고강도 검증 통과. 스모크만으로 완료 처리하지 않습니다. 설치된 tom은 별도 bean의 주기적 실사용 검사 대상이 됩니다.

6. 사람이 실사용 → OK → verify 지시

   사람의 최종 사용 판단 / tom — 사람도 tom을 직접 사용해 변경 기능과 사용 흐름을 확인합니다. 만족하면 에이전트에게 verify를 지시하고, 에이전트가 사람이 확인한 동일 설치 커밋에 검증 기록을 남깁니다. 확인 중인 설치 커밋은 고정하거나 자동 갱신을 잠급니다.

   다음 조건: 사람의 실사용 OK + 그 지시에 따른 verify SHA·근거 기록. 자동 테스트나 bean의 통과로 사람의 OK를 대신하지 않습니다. 코드가 바뀌면 재검증합니다.

7. 릴리스 자동 발행

   GitHub / 자동 — verify와 릴리스 대상의 코드 연결을 자동 확인하고, release-please PR을 자동 병합해 버전 태그·릴리스를 발행합니다. 추가 사람 승인은 없습니다.

   다음 조건: 유효한 verify + 검증 뒤 추가된 기능 변경 없음 + 릴리스 검사 통과. 허용된 버전·변경 로그 메타데이터 외 코드 변경이 있으면 중단.

8. 운영 자동 배포

   배포 자동화 → ome-on — 발행 태그가 유효한 verify에 연결되는지 자동 검사한 뒤 고정 태그를 설치하고 운영 스모크를 실행합니다. 추가 사람 승인은 없습니다.

   완료 조건: 배포 대상으로 고정한 릴리스 태그의 커밋 SHA = 운영 설치 SHA, 그리고 그 릴리스 코드가 verify한 코드에 연결됨 + 스모크 통과. 실패 시 완료 처리하지 않고 중단·보고합니다.

bean: tom과 운영을 계속 써보는 별도 호스트

bean 하나를 메인 플로우의 5번 tom과 8번 ome-on에 직접 연결합니다. 화살표는 설치된 두 서비스를 주기적으로 검사하는 관계를 뜻합니다. 별도 배포 단계나 중복된 tom·ome-on을 만들지 않습니다.

bean → tom · 5번 이후

설치된 staging에 접속해 사용자 시나리오를 주기적으로 실행합니다. tom 자체의 고강도 테스트와 별도로 외부 사용자 관점에서 검사합니다.

bean → ome-on · 8번 이후

배포된 운영 서비스에 접속해 실사용 흐름이 계속 동작하는지 주기적으로 검사합니다. 배포 직후 스모크와 구분합니다.

결과와 증거

대상 호스트·설치 SHA 또는 버전·시나리오·실행 시각·통과/실패·근거를 기록합니다. 실패는 해당 환경의 문제로 알립니다.

bean의 주기적 검사는 사람의 실사용 확인·verify를 대신하지 않습니다. 검사 실패는 결과·대상 버전과 함께 보고합니다. 반복 검사의 주기·시나리오, 그 결과를 승격 차단이나 자동 복구에 연결할지는 구현 때 별도로 정할 항목이며, 현재 정해진 정책처럼 가정하지 않습니다.

머신 · Git · 사람 상세 관계도

같은 절차를 역할별로 펼친 스윔레인 다이어그램입니다. 작은 화면에서는 좌우로 스크롤할 수 있습니다. 상세 관계도 PNG

승격 기준

• 검사한 코드만 다음 단계로: CI·설치·verify·태그를 SHA로 연결하고 PR 갱신 뒤 이전 통과 결과를 재사용하지 않습니다.
• 메인 필수 검사 실패 시 다음 단계 중단: 메인 플로우의 필수 CI·설치·고강도 검증 실패나 verify 부재가 있으면 승격하지 않습니다. bean 반복 검사 실패의 차단·복구 정책과는 구분합니다.
• 사람은 1번 개발과 6번 실사용 판단: 에이전트를 시켜 개발하고, tom을 직접 써본 뒤 OK하면 verify를 지시합니다. 중간 병합·릴리스·운영 배포에 추가 사람 승인은 두지 않습니다.
• 세 종류의 확인을 구분: tom의 고강도 자동 검증, bean의 주기적 외부 실사용 검사, 사람의 실사용 OK·verify는 서로 다른 근거입니다.
• verify 뒤에는 자동: 동일 검증 코드에 연결된 릴리스만 자동 발행·배포합니다. 검증 누락·코드 불일치·메인 필수 검사 실패 시 중단하고 보고하며, 통과 결과를 우회하지 않습니다.
• 검증 SHA와 태그 SHA를 구분: verify 커밋과 릴리스 태그 커밋은 버전·변경 로그 같은 허용된 릴리스 메타데이터 변경으로 달라질 수 있습니다. 코드 계보·변경 범위를 검사해 검증된 기능 코드가 유지되는지 확인하고, 운영 설치 SHA는 배포 대상으로 고정한 태그 SHA와 일치해야 합니다.
• 검증 중 설치본 고정: tom 자동 갱신과 사람의 검증이 겹치지 않게 SHA 고정 또는 잠금을 둡니다.
• 모니터는 관측: 보드는 코드 위치·설치·증거를 보여 주며 배포나 병합을 실행하지 않습니다.

현재 설정에서 맞춰야 할 부분

2026-10-20 15:29 KST에 GitHub 워크플로·보호 규칙·최근 promote 실행 기록, tom PM2 목록, 모니터 API를 다시 대조한 설정과 개선안의 차이입니다. 구현 완료 목록이 아닙니다.

고강도 테스트의 필수 항목·통과 기준, bean의 검사 주기·시나리오·실패 연계 정책, 릴리스 메타데이터의 허용 변경 범위는 아직 구체화할 구현 항목입니다. 기존 모니터가 기대하는 rc·승인 규약도 새 흐름에 맞춰 연결해야 하며, 문서가 맞다는 확인을 실제 자동화 완료나 기능 검증 완료로 취급하지 않습니다.