개발 조직에 규칙이 필요할 때 — EM의 거버넌스 수립 여정 (feat. AI)
EM 합류 약 2개월 차, 운영 릴리즈와 장애 회고를 겪으며
거버넌스 정책 수립을 시작했습니다!
AI와 함께 8대 카테고리 중 5개를 완성한 여정의 중간 기록을 공유합니다 🤔
왜 이 글을 쓰나요?
개발 조직을 리드하다 보면 한 번쯤 이런 생각이 스칩니다.
“우리 팀, 규칙이 있긴 한 건가…?”
코드 리뷰는 하고 있는데 기준이 사람마다 다르고, 배포는 하고 있는데 “금요일에 배포해도 되나요?” 같은 질문이 매번 반복되고, 장애가 터지면 일단 잘 아는 사람이 뛰어들어서 해결하긴 하는데… 그 흐름이 어디에도 적혀 있지 않죠.
저는 Worxphere 에서 Jobplanet 개발 조직을 리드하는 EM(Engineering Manager)입니다. FE, BE, Mobile, QA, Data, DevOps까지 여러 팀이 함께 일하고 있어요. 팀에 합류한 지 이제 막 한 달이 지난 시점인데요, 이 짧은 기간 동안 운영 릴리즈를 직접 경험하고 서비스 장애 회고를 진행하면서 한 가지를 절실히 느꼈습니다 — “우리, 이거 규칙으로 만들어야 해.”
릴리즈를 진행할 때 “이건 원래 누가 확인하는 거였죠?” 같은 질문이 나오고, 장애 회고를 하면서 “이 절차가 문서화돼 있었으면 대응이 더 빨랐을 텐데” 하는 아쉬움이 남더라고요. 암묵적으로 돌아가는 것들이 대부분 잘 돌아가고 있었지만, 그게 누군가의 머릿속에만 있다는 게 문제였어요.
그래서 지금, 거버넌스 정책을 처음부터 수립하는 여정의 한가운데에 있습니다.
이 글은 완성된 회고가 아니라, 진행 중인 기록이에요. 아직 절반도 안 끝났거든요ㅋㅋ 그래도 지금까지의 고민과 결정들이 같은 고민을 하고 있을 다른 EM이나 중간관리자분들에게 작은 참고가 될 수 있지 않을까 싶어 정리해봅니다.
거버넌스, 뭘 만들어야 하는 거야?
처음에 가장 막막했던 건 “뭘 만들어야 하는지” 자체였어요. “코드 리뷰 규칙” 같은 건 떠오르는데, 개발 조직 거버넌스의 전체 그림이 없으니 빠뜨리는 게 뭔지 알 수가 없더라고요.
그래서 먼저 갭분석 프레임워크를 세웠습니다. 업계 사례를 조사하고, 우리 조직에 맞게 8대 카테고리로 정리했어요:
| # | 카테고리 | 세부 항목 | 현재 상태 |
|---|---|---|---|
| G1 | 코드 관리 | 브랜치 전략, 커밋 규칙, 코드 리뷰, PR 규칙 | ✅ |
| G2 | 릴리즈 관리 | 릴리즈 프로세스, 롤백, 핫픽스, 배포 승인 | ✅ |
| G3 | 인시던트 관리 | 장애 대응, 포스트모템, 에스컬레이션, 온콜 | ⚠️ |
| G4 | 보안 | 접근제어, 시크릿 관리, 취약점 관리 | ❌ |
| G5 | 품질 | 테스트 표준, CI/CD 기준, QA 절차 | ❌ |
| G6 | 운영 | 모니터링, SLO, 변경 관리 | ✅ |
| G7 | 아키텍처 | 기술 의사결정 프로세스, 기술 부채 관리 | ⚠️ |
| G8 | 팀 프로세스 | 온보딩, 문서화 표준 | ❌ |
이렇게 놓고 보니까 “아, 우리가 당연하다고 생각하고 넘어간 것들이 이렇게 많구나” 싶더라고요. 특히 보안이나 품질 쪽은 “다들 알아서 잘 하고 있으니까…” 하면서 미뤄왔던 영역이었거든요.
핵심 원칙: “이미 잘 돌아가는 것을 제도화한다”
거버넌스를 수립하면서 가장 중요하게 생각한 원칙이 하나 있어요.
새 규칙을 만드는 게 아니라, 이미 잘 돌아가고 있는 것을 글로 적는 것.
이게 왜 중요하냐면요. 규칙을 만든다고 하면 팀원들이 본능적으로 경계하거든요ㅋㅋ “관료주의 도입하려는 거 아닌가?” “이거 때문에 속도가 느려지는 거 아닌가?” 이런 걱정요.
그런데 실제로 해보니, 우리 팀이 이미 하고 있는 것들을 문서로 적는 것만으로도 엄청난 가치가 있었어요:
- 6개월 뒤 신규 입사자가 “이거 왜 이렇게 하는 거예요?” 라고 물어볼 때 문서를 줄 수 있음
- “내가 기억하는 규칙”과 “네가 기억하는 규칙”이 다를 때 합의된 기준점이 됨
- 누가 진행하든 동일한 품질을 보장할 수 있음
문서화 대상을 판단하는 제 나름의 기준은 이거였어요:
“6개월 뒤 신규 입사자가 왜 이렇게 했는지 물어볼까?” — Yes면 문서화.
AI와 함께 정책을 만든다는 것
여기서 이 여정의 독특한 점을 이야기해야 할 것 같아요. 저는 이 거버넌스 정책들을 Claude(AI)와 대화하면서 만들고 있습니다.
솔직히 처음엔 “AI가 조직의 규칙을 만든다고?” 하는 생각이 있었어요. 거버넌스라는 게 결국 조직의 맥락, 문화, 히스토리를 알아야 만들 수 있는 건데, AI가 그걸 알 리가 없잖아요.
그런데 실제로 해보니, AI의 역할은 **“규칙을 만들어주는 것”이 아니라 “좋은 질문을 던져주는 것”**이었습니다.
워크숍형 협업이 핵심
실제 작업 흐름은 이랬어요:
[1] AI가 구조화된 질문을 던짐
→ "현재 배포 주기는?", "롤백 기준이 있나요?"
[2] 내가 현황을 설명함
→ "금요일 배포는 암묵적으로 금지", "롤백은 그때그때 판단"
[3] AI가 업계 사례를 조사해서 보여줌
→ "업계에서는 롤백을 3단계(즉시/판단 후/모니터링)로 나누는 게 일반적입니다"
[4] 함께 우리 조직에 맞게 조정
→ "우리는 2개 스쿼드가 독립 배포하니까..."
[5] 초안 완성 → 내가 검토/수정이게 왜 효과적이냐면요. 혼자 빈 문서 앞에 앉아서 “뭘 적어야 하지…” 하는 시간이 사라져요. AI가 프레임워크와 질문을 제공하니까, 나는 우리 조직의 맥락만 채워 넣으면 되거든요.
물론 AI가 처음부터 완벽한 걸 뱉어주진 않아요ㅋㅋ 몇 가지 재밌는 사례를 공유하면:
| 상황 | AI 제안 | 내 판단 | 결과 |
|---|---|---|---|
| SLO 목표치 | API 가용성 99.9% | “Rails→Spring 전환 중인데 너무 타이트해” | 99.5%로 하향 (보수적 시작) |
| ADR/RFC 프로세스 | 제안서 + 결정문서 분리 템플릿 | ”우린 문서 하나로 관리하는 게 맞아” | 단일 문서 방식으로 전면 재작성 |
| 인시던트 관리 | 완성된 정책 작성 | ”이건 BE 담당자가 가져가야 해” | v0.1 초안만 작성 + 보완 항목 체크리스트 |
결국 최종 판단은 항상 사람(EM)의 몫이에요. AI는 업계 표준이라는 “넓은 시야”를, 나는 우리 조직이라는 “깊은 맥락”을 가져오는 거죠.
지금까지 만든 것들
약 이틀에 걸쳐 5개의 거버넌스 정책을 수립했어요. 각각의 핵심 결정과 고민을 간단히 정리하면:
G1. 코드 리뷰 정책
핵심 결정: 긴급도를 D0~D4로 분류하는 시스템 도입
솔직히 코드 리뷰 규칙은 대부분의 팀이 가지고 있을 거예요. 우리 고민은 “핫픽스 때는 리뷰를 어떻게 하지?”였는데, D0(장애/핫픽스) = TL 승인 1명으로 즉시 머지 가능, 일반 PR은 D1~D4로 분류해서 리뷰 기한을 다르게 적용하는 방식을 채택했어요.
G2. 릴리즈 관리 정책
핵심 결정: 롤백 3단계 기준 + Go/No-Go 체크리스트
이미 운영하고 있던 릴리즈 워킹플랜 템플릿 위에 규칙 레이어를 얹는 방식으로 만들었어요. 기존 템플릿 = 실행 도구, 거버넌스 = 언제/누가/어떻게에 대한 규칙. 이 구분이 중요했습니다.
배포 회고 템플릿도 Notion에 직접 만들었는데, KPT(Keep/Problem/Try) 형식에 OKR 연계를 넣은 게 포인트예요. 회고가 그냥 “다음에 잘하자~” 로 끝나지 않게요.
G3. 인시던트 관리 정책 (초안)
핵심 결정: v0.1만 작성하고, BE 담당자에게 위임
이건 고민이 많았어요. EM이 모든 정책을 직접 완성해야 하나? 결론은 “뼈대는 내가 세우고, 살은 담당자가 붙인다”. Severity 분류(Sev1~4), 에스컬레이션 경로, 온콜 로테이션 기본 구조만 잡아두고, 세부 Runbook이나 팀별 대응 매뉴얼은 해당 팀이 채우는 방식이에요.
위임의 기술이랄까요ㅋㅋ 초안이 있으면 담당자 입장에서도 “빈 문서부터 시작”하는 것보다 훨씬 수월하거든요.
G6. SLO & 모니터링 기준
핵심 결정: Error Budget 개념 도입 + 보수적 시작
이 영역은 제가 솔직히 잘 몰랐어요ㅋㅋ SLI, SLO, SLA, Error Budget… 용어부터 정리가 필요했습니다. AI와 대화하면서 “우리 서비스에 SLA가 필요한가?” → “B2C라 공식 SLA는 불필요, 내부 SLO만 정의하자” 같은 판단을 하나씩 내려갔어요.
특히 Error Budget 정책이 마음에 들었는데요:
| Error Budget 잔량 | 상태 | 조치 |
|---|---|---|
| > 50% | 🟢 Green | 자유 배포 |
| 20~50% | 🟡 Warning | 배포 전 리뷰 강화 |
| < 20% | 🔴 Freeze | 신기능 배포 중단, 안정화 집중 |
| 0% | ⛔ Full Freeze | 전면 배포 중단 |
데이터에 기반해서 “배포해도 되는지”를 판단할 수 있게 된 거죠. “느낌적인 느낌”에서 벗어나는 첫 걸음이라고 할까요.
G7. 기술 의사결정 프로세스
핵심 결정: 단일 문서 방식 (RFC/ADR 템플릿 분리 X)
AI가 처음에 RFC(제안서)와 ADR(결정 기록)을 분리하는 템플릿을 제안했는데, 우리 조직 규모에는 과했어요. 이미 Notion에서 “초안 → 코멘터리 → 회의 결정” 흐름이 잘 돌아가고 있었거든요.
결국 정책 문서 1개 + Notion DB 버전 관리로 단순화했습니다. 관리상태(초안/관리중/아카이브), 버전(v1.0, v1.1…), 태그(수정가능/잠금) 세 가지 DB 속성만으로 충분하더라고요.
이게 아까 말한 “AI 제안을 그대로 쓰지 않고 맥락에 맞게 조정하는” 좋은 사례였어요.
여정 중간에서 느낀 것들
1. 거버넌스는 관료주의가 아니다
“규칙 = 속도 저하”라는 편견이 있었는데, 실제로는 반대예요. 규칙이 명확하면 “이거 해도 되나요?”라는 질문과 그에 대한 대기 시간이 사라져요. 오히려 속도가 빨라집니다.
단, 조건이 있어요. 규칙이 가벼워야 해요. 우리가 채택한 원칙들:
- 강제 차단은 하지 않음 — 습관화를 유도
- 위반 시 처벌이 아닌 안내와 교육
- 예외 상황을 명시적으로 인정 (긴급 장애 시 구두 결정 → 사후 문서화)
2. 완벽한 정책은 없다 (그래서 버전이 있다)
처음에 “완벽한 정책을 만들어야 한다”는 압박이 있었어요. 그런데 해보니까, v1.0은 시작점일 뿐이에요. 실제로 팀이 운영하면서 “이 부분은 현실과 안 맞네” 하는 피드백이 오면 그때 v1.1로 개정하면 되는 거예요.
정책 문서에 상태: Draft를 명시해두는 것도 이 때문이에요. “이건 아직 확정이 아니라 팀 리뷰를 거쳐야 하는 초안입니다”라는 메시지를 주는 거죠.
3. 위임할 수 있는 것은 위임한다
G3 인시던트 관리를 v0.1 초안만 작성한 결정이 의외로 정답이었어요. EM이 모든 정책을 완벽하게 만들어서 “자, 이거 따라!” 하면… 그건 거버넌스가 아니라 지시ㅋㅋ
뼈대를 세우고, 방향을 제시하고, 채우는 건 실무자에게 맡기는 것. 이래야 정책에 대한 오너십도 생기고, 현장의 맥락이 반영돼요.
4. AI는 “만능 작성자”가 아니라 “구조화 파트너”
AI가 정책을 대신 써주길 기대하면 실망할 거예요. AI의 진짜 가치는:
- 프레임워크 제공 — “이런 것들을 고려해야 합니다” 리스트
- 업계 사례 조사 — “다른 회사는 이렇게 합니다” 레퍼런스
- 구조화된 질문 — “현재 롤백 기준이 있나요?” 같은 빈칸 채우기 유도
- 초안 가속 — 빈 문서 → 80% 완성 초안까지의 시간 단축
나머지 20%를 채우는 건 조직을 아는 사람의 몫이에요. 그리고 그 20%가 정책의 품질을 결정합니다.
남은 여정
아직 갈 길이 멀어요ㅋㅋ 현재 백로그 상황:
| 우선순위 | 항목 | 상태 |
|---|---|---|
| P2 | G8 개발자 온보딩 체크리스트 | 미착수 |
| P3 | G5 테스트/CI/CD 품질 게이트 | 미착수 |
| P3 | G7 기술 부채 관리 | 미착수 |
| P3 | G4 시크릿 관리/취약점 스캔 | 미착수 |
| P4 | G8 문서화 표준 | 미착수 |
| P4 | G6 변경 관리 절차 | 미착수 |
이 글을 쓰는 시점(2026년 4월)에 5개 완료, 6개 미착수. 절반 왔다고 해야 하나, 절반 남았다고 해야 하나ㅋㅋ
다 만든다고 끝이 아니에요. 팀 리뷰를 거쳐서 확정하고, Notion wiki에 발행하고, 실제로 운영하면서 개정하는 — 살아있는 문서로 만드는 과정이 진짜 시작이죠.
마무리하며
같은 고민을 하고 있을 EM이나 중간관리자분들에게 한 줄 요약을 드리자면:
“완벽한 규칙을 만들려 하지 말고, 이미 하고 있는 것을 적는 데서 시작하세요.”
빈 문서 앞에서 막막하면, AI에게 “우리 팀에 코드 리뷰 규칙을 만들고 싶은데, 뭘 고려해야 해?”라고 물어보는 것도 좋은 시작이에요. 프레임워크와 질문이 주어지면, 여러분은 이미 답을 가지고 있을 거예요.
이 여정의 나머지 절반도 끝나면 후속편으로 돌아오겠습니다! 그때까지, 여러분의 조직에도 좋은 규칙이 자리잡길 바라요 :)
다음 글에서 봬요!
