플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의하기
문제 정의 — 경계가 모호할 때 발생하는 실제 비용과 리스크
플랫폼 팀과 애플리케이션 팀 사이의 책임·지원 경계가 불분명하면 즉시 드러나는 손실이 생깁니다. 아래 항목은 조직이 실제로 겪는 주요 비용과 리스크를 정리한 것입니다.
- 중복 작업: CI/CD 파이프라인, 모니터링, 로그·메트릭 수집 시스템을 팀마다 중복 구축해 인력과 시간이 낭비되고 유지보수 비용이 증가합니다.
- 장애 복구 지연: 소유권이 불분명해 핸드오프가 늦어지고 MTTR이 길어져 고객 영향이 커집니다.
- 보안 취약점: 패치, 비밀 관리, IAM 정책의 책임이 모호하면 취약점과 규정 준수 실패 위험이 높아집니다.
- 비용 비효율: 사용하지 않는 인스턴스나 스냅샷 방치, 과다 프로비저닝으로 예상치 못한 청구가 발생합니다.
이들 문제는 일시적인 혼란이 아니라 운영 부채로 누적되어 기술적·비즈니스 리스크를 키웁니다. 실무적으로는 소유권 맵 작성, 책임자와 SLA 명시, 공통 컴포넌트의 운영 주체 지정 같은 간단한 체크리스트부터 적용해 보세요. 플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의는 이러한 비용을 줄이는 출발점입니다.
원칙 수립 — 누가 무엇을 책임지는지 결정하는 기준
플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의는 역할 불명확으로 인한 중복 작업과 장애 대응 지연을 줄이기 위한 출발점입니다. 이 경계는 단순한 항목 나열이 아니라 소유권, 제품 관점, API 계약, 그리고 비즈니스 영향 네 가지 관점에서 일관된 기준으로 정립해야 합니다.
핵심 원칙
- 소유권 — 코드, 인프라, 운영에서 변경·롤백 권한을 가진 팀이 1차 책임자입니다. 단일 책임자 원칙을 적용해 책임선을 명확히 합니다.
- 제품 사고 — 플랫폼은 사용성, 온보딩, 문서, 운영성(operability)을 제품으로 책임지고, 애플리케이션은 소비자 관점에서 요구와 우선순위를 제시합니다.
- API 계약 — 인터페이스, 버전, SLA, 모니터링 포인트를 문서화하고, 변경 시 영향 분석·테스트·공지 절차를 공동으로 수행합니다.
- 비즈니스 영향 — 고객이나 매출에 직접 영향을 주는 기능은 애플리케이션 팀이 주도합니다. 반면 공통 기반 서비스의 장애는 플랫폼 팀이 우선적으로 대응합니다.
이 원칙은 변경관리 프로세스(RFC·테스트·배포 표준), 모니터링·대응 역할, 정기적 사례 리뷰로 보완되어야 합니다. 문서화된 기준이 있으면 실무 적용이 훨씬 수월해집니다. 체크리스트 예: 소유자(담당자·연락처), 롤백 권한, 영향 범위 및 모니터링 담당자 지정.
영역별 책임 매핑 예시 — 인프라, 배포, 관찰성, 보안, 비용
| 영역 | 플랫폼 팀 (권한·책임·제공물) | 애플리케이션 팀 (권한·책임·제공물) |
|---|---|---|
| 인프라 |
|
|
| 배포 |
|
|
| 관찰성 |
|
|
| 보안 |
|
|
| 비용 |
|
|
운영 모델과 지원 수준 정의 — 셀프서비스, 지원 레벨, 온콜
플랫폼은 셀프서비스 포털을 통해 표준 템플릿·이미지·권한을 제공하고, 애플리케이션 팀은 해당 포털로 배포·설정·권한 요청을 직접 수행하도록 설계하세요. 지원 모델은 1차(애플리케이션 팀 자체 대응)와 2차(플랫폼 팀의 심화 대응)로 명확히 구분합니다. 각 팀의 책임과 지원 범위는 서비스 카탈로그에 문서화해 누구나 참고할 수 있도록 하세요. 플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의도 반드시 명문화해 혼선을 줄이세요.
- SLA/SLO: 가용성과 응답 시간에 대한 SLO를 수립하고, 에러 버짓을 계산해 이를 SLA로 전환·공유하세요.
- 온콜·에스컬레이션: 온콜 로테이션과 에스컬레이션 경로(1→2→관리자), 연락처 및 대체자 정보를 명확히 문서화하세요.
- 런북 설계: 런북에는 증상·영향·우선순위 정의, 원인 추론 가이드, 단계별 복구·롤백 절차를 담고, 검증 체크리스트와 관련 대시보드·스크립트 링크도 포함하세요.
자동화된 테스트·롤백과 모니터링 훅, 정기적인 복구 연습을 통해 운영 신뢰도를 유지하세요. 실무 체크리스트 예: 온콜 교대표 최신화, 분기별 복구 연습 실시, 런북 및 자동화 스모크 테스트 정기 검증.
계약·프로세스·도구로 경계 고정하기 — 서비스 카탈로그와 자동화
플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의를 실무에 정착시키려면 서비스 카탈로그, 계약(ROE·SLA), 템플릿·레포, 접근 제어를 조합해 '무엇을, 누가, 어떻게' 제공할지 분명히 정해야 한다. 이렇게 하면 기대치가 일관되게 관리된다.
- 서비스 카탈로그: 서비스 정의와 제공 범위, 버전, 온보딩 체크리스트를 항목별로 정리해 기대치를 표준화한다.
- 계약(ROE·SLA): 지원 수준, 책임 분계점, 에스컬레이션 절차와 제외 항목을 수치와 예시로 명문화해 모호함을 줄인다.
- 템플릿·레포: 인프라·애플리케이션 템플릿과 CI/CD 파이프라인 레포를 표준화해 재사용성과 감사 가능성을 확보한다.
- 접근 제어·자동화: 역할 기반 권한과 승인 흐름, 자동 프로비저닝·청구·모니터링 알림 등으로 운영 인터페이스를 자동화한다.
- 변경·갱신 프로세스를 계약에 포함시켜 책임 경계가 진화할 때도 실무적 혼선이 없도록 한다. 실무 체크리스트 예시: 갱신 주기, 변경 소유자, 영향 범위와 통지 방식 등 최소 항목을 명시한다.
거버넌스와 변화 관리 — 측정 지표, 정기 검토, 실무 베스트 프랙티스
성공지표는 명확해야 한다: 배포 빈도(주/월 단위), MTTR(평균 복구 시간), 소유권 위반 건수(플랫폼·애플리케이션 경계 위반 케이스). 각 지표별 수집 주기와 책임자를 정해 자동 대시보드로 모니터링한다. 또한 초기 설계 단계에서 플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의를 합의해 두는 것이 중요하다.
- 정기 리뷰·교육: 분기별 거버넌스 검토, 월별 릴리스 회고, 온보딩·변경 교육은 반기 단위로 시행.
- 역할 예시: 플랫폼팀은 가드레일과 모니터링을 제공하고, 애플리케이션팀은 런북을 관리하며 초기 대응을 담당한다.
- 실제 사례: 한 조직은 소유권 위반이 잦아 플랫폼이 CI 템플릿 적용을 의무화했고, 위반 건수가 약 70% 감소했다.
지속 개선을 위한 체크리스트:
- 핵심 지표를 정의하고 대시보드를 가동한다
- 정기 리뷰 일정을 고정하고 회고 결과를 기록·공유한다
- 교육 커리큘럼과 온보딩 문서를 최신 상태로 유지한다
- 소유권 위반 발생 시 근본 원인을 분석하고 가드레일을 보완한다
- 자동화 우선순위와 책임을 정해 반복 작업을 줄이고 휴먼 에러를 방지한다
경험에서 배운 점
경계가 모호하면 책임 회피, 중복된 작업, 사고 대응 지연이 생깁니다. 실무에서 자주 보이는 실수는 '플랫폼이 다 알아서 해준다'는 전제인데, 이로 인해 애플리케이션 팀이 플랫폼 내부 변경(인터페이스, 버전, 배포 파이프라인 등)에 대비하지 못하는 경우가 많습니다. 반대로 플랫폼 팀이 애플리케이션의 비즈니스 요구나 데이터 소유권을 대신 판단하려 드는 것도 문제입니다. 그래서 누가 무엇을 소유하는지 문서화하고, 지원 수준(1/2/3라인, 응답 시간, 에스컬레이션 경로)을 명확히 해 두지 않으면 운영 중 반복적인 충돌이 발생합니다. 플랫폼 팀과 애플리케이션 팀 간 책임·지원 경계 정의는 한 번 합의한다고 끝나는 것이 아니라, 운영을 통해 계속 조정해야 합니다.
실무 체크리스트(간단명료하게 합의하고 주기 검토):
- RACI 또는 유사 책임 매트릭스로 '소유자', '지원자', '정보 수신자'를 분명히 한다.
- 지원 범위 문서화: 1/2/3라인 책임, 예상 응답·해결 시간, 에스컬레이션 절차를 포함한다.
- 계약적 인터페이스 정의: API·계약(버전 정책 포함)과 배포 파이프라인 책임(누가 릴리스하는가)을 명시한다.
- 모니터링·알림 책임 분리: 플랫폼이 제공할 SLI·알림과 애플리케이션이 관리해야 할 항목을 구분한다.
- 런북과 롤백 책임: 인시던트 플레이북과 롤백 주체·조건을 사전에 합의한다.
- 권한·비용·리소스 한계: IAM, 쿼터와 비용 책임 소재를 명확히 한다.
- 변경 공지와 호환성 테스트: 플랫폼 변경 전 영향 범위 공지와 애플리케이션 호환성 검증 절차를 규정한다.
- 정기 리뷰: 책임 문서는 살아있는 문서로서 분기별 또는 주요 변경 시 재검토한다.
댓글
댓글 쓰기