date
slug
author
status
tags(최대 3개)
summary
type
thumbnail
category
updatedAt
TL;DR
- 사내 인프라 문의는 2024년 745건에서 올해 9월까지 1,267건으로 늘었습니다. 사람을 늘리는 대신, 누가 받아도 같은 맥락에서 시작하는 출발선을 만들었습니다.
- 문의가 올라오면 5분 안에 티켓과 담당자가 정해집니다. 늦게 답하던 문의(상위 10%)는 56분에서 16분으로, 아무도 답하지 않은 문의는 7.4%에서 2.3%로 줄었습니다.
- 인프라팀 리드에게 배정된 지라 티켓은 비중은 58%에서 22%로 내려왔습니다. 그 사이 팀원들은 기술블로그 6편을 작성했고, 운영 봇을 직접 만들었습니다.
배경: 늘어난 업무 요청과 줄어든 팀원
올해 1분기 팀 규모가 작아졌지만 들어오는 업무 요청은 오히려 늘었습니다. 인프라팀의 업무 요청 슬랙을 보면 들어온 문의는 2024년 약 745건, 2025년 1,219건이었습니다.
올해는 9월까지 벌써 1,267건입니다.
당시엔 관련 지라 티켓의 절반이 넘을 정도로 팀 리드인 제가 주도하여 업무 요청을 담당했습니다. 그러다 보면 팀 업무에 병목이 생기는 상황도 빈번했습니다. 업무 요청 플로우를 개선할 필요가 있었습니다.
먼저 연관된 모든 이해관계자를 정리하고 시작했습니다.
누구 | 바라는 것 |
요청자 | 요청 채널을 헤매지 않고, 빠르게 답을 획득 |
담당자 | 과거 맥락을 파악하고, 요구사항을 한번에 이해 |
팀원 | 반복 요청을 자동화하고, 불필요한 시간을 절약 |
팀장 | 사람이 판단해야 하는 예외 상황에만 투입 |
4명의 이해관계자를 한번에 만족시키는 방법은 같은 출발선에서 동일한 정보를 제공하는 것이었습니다.
출발선의 구성: 지식·창구·가드레일
창구는 이 지식DB들을 볼 수 있는 공간입니다. 업무 요청자와 담당자는 슬랙, 터미널, 사내 포털처럼 익숙한 소통 공간에서 쉽게 조회할 수 있습니다.
가드레일은 지켜야 할 정책입니다. 사람이 승인해야할 기준, 조회의 범위 등의 인프라 정책을 적어 팀 공용 저장소에서 관리합니다. 3월에 66개였던 정책 파일이 9월에는 220개가 됐고, 병합된 변경의 38%는 제가 아닌 팀원이 기여했습니다.
지식, 창구, 가드레일은 특정 AI 모델에 한정하지 않습니다. 우리 규칙을 제대로 따르는지 묻는 시험 문항을 두고 모델별로 채점해 보니, 클로드는 100%를 코덱스와 딥시크 조합은 79%의 정확도를 보였습니다. 코덱스와 딥시크 조합에서 틀린 문항은 모두 팀 공통 규칙 문항이었습니다. 어떤 모델을 쓰든 대부분 비슷한 결과를 내지만, 팀 규칙은 아직 모델마다 편차가 있습니다. 모델별 점수는 매주 업데이트합니다.
업무 요청자: 5분 내 담당자 자동 배정
지난 5월부터 인프라팀의 문의 채널을 5분마다 읽도록 설정했습니다. AI가 글을 분류하고 티켓을 만든 뒤, 해당 파트의 1차 온콜 담당자를 지정해 스레드에 답글을 답니다.
지표 | 자동 배정 전 (5월 중순 이전) | 자동 배정 후 (5월 중순 이후) |
첫 응답 중앙값 | 4분 | 2분 |
첫 응답 상위 10% 경계 | 56분 | 16분 |
응답하지 않은 문의 | 7.4% | 2.3% |
봇 답글이 달린 문의 | — | 98.6% (중앙값 3분) |
이전에도 빨랐던 중앙값은 더욱 빨라졌습니다. 주목할 점은 중앙값이 아니라 뒤늦게 답하거나 답변을 놓친 문의들입니다. 늦은 밤에 들어오거나 담당이 애매한 문의가 한 시간씩 떠 있던 게 문제였는데, 담당자를 자동으로 정하자 그런 문의가 줄었습니다. 같은 시기에 온콜 정책과 인원 구성도 바뀌었기 때문에, 이 차이를 자동 배정 하나의 효과로 보지는 않습니다.
담당자: 온콜 자동 호출과 트리아지 가이드
담당자는 이제 "누가 봐야 하지?"를 고민하지 않습니다. 매일 아침 봇이 파트별 온콜을 알리고, 답이 없으면 1차 담당자에서 순차적으로 팀 리드까지 넘어갑니다. 팀에 새로 합류한 구성원은 기존 담당자의 온콜을 함께 따라다니다가 곧 정식 1차 담당자로 배정됩니다.
온콜 문서에는 다음 문장이 있습니다.
힘들면 언제든 에스컬레이션 레이어 조정 가능. 블레임은 리더가 우선 받습니다.
요청 사항의 맥락도 미리 붙어서 옵니다. 티켓이 만들어지면 몇 분 안에 자동 트리아지 가이드가 댓글을 작성합니다. 추정 분류, 관련 런북 링크, 팀 지식에 쌓인 판단 규칙, 과거의 비슷한 사례의 해결 방법까지 들어 있습니다.
CloudFront 주소 교체(CF SWAP), 유료 인증서 교체, WAF 공격 대응처럼 한 번 어긋나면 여러 고객사에 영향이 가는 민감한 상황일수록 이 메모가 힘을 발휘합니다.
지난 달, 한 고객사에서 다음과 같은 문의가 들어왔습니다.
주소에 www를 붙이면 보안 인증서가 적용되지 않아요.
접수한지 4분만에 자동 가이드가 인증서와 CloudFront 관련 런북 세 개를 붙였습니다. 다시 6분 뒤, 이제 막 수습기간을 마친 SRE 담당자 승민님이 답변을 작성했습니다. 임시 인증서로 먼저 www 접속을 살리고, 고객이 구매한 유료 인증서는 재발급을 걸어 자동으로 바뀌게 해 두었습니다. 접수부터 해결까지 10분이 채 걸리지 않았습니다. 얼마 뒤 접수한 비슷한 문의도 같은 순서로 풀었습니다.
장애 대응: 영역별로 동시 투입
자주 반복되는 요청을 자동화 구조가 받쳐 주니, 위급한 상황에 사람이 자기 영역에 집중할 수 있었습니다. 1년 간 전사 장애 데이터를 모두 살펴 보았습니다. 인프라팀의 첫 답글은 중앙값 24초였습니다. 신고 양식이 인프라팀 구성원을 모두 호출해 이전부터 빠른 대응이 가능했습니다.
장애 한 건에 인프라 팀원이 평균 3.5명 붙었습니다. 5분 안에 두 명 이상 붙은 비율은 68%, 77%, 86%로 올라갔습니다.
각자 업무 범위에 집중해 DB 담당은 DB로, SRE는 서버 증설로, DevOps는 EKS로, 보안 담당은 WAF를 살펴봅니다.
장애 일시 | 상황 | 동시에 투입한 영역 | 정상화까지 걸린 시간 |
2025년 11월 | 배포 뒤 DB 잠금과 서버 과부하 | 서버 증설 · DB 쿼리 정리 · 보안 지표 추적 | 14분 |
2026년 2월 | 야간 대량 공격 | WAF 차단·VIP 전환 · DB·캐시 확인 · CloudFront 경로 확인 | 23분 |
2026년 5월 | DB 쓰기 경로 문제 | 1분 안에 DB 담당 둘·SRE·리드가 각자 다른 작업 | 17분(1차) |
"제가 볼까요?"라고 묻는 사람은 없었습니다. 각자 무엇을 맡아야할지 알기 때문입니다.
팀원: 기술블로그와 운영 봇 ‘라이스’
인프라 요청 업무를 개선하니 팀원들의 업무 생산성도 크게 향상되었습니다. 기술블로그를 쓰거나 AI 봇을 만들어 팀에 기여하는 일이 많아졌습니다.
각자의 담당 업무를 중심으로 4개월동안 팀원들은 6편의 기술블로그를 발행했습니다.
DevOps 담당자 호수님은 같은 출발선에서 움직이는 운영 봇 '라이스'를 만들었습니다. 9월 한 달 동안 사람이 직접 올린 커밋만 367개입니다.
AI 세션 기록을 남기는 사람도 바뀌었습니다. 올해 초와 비교해 팀원이 쓴 비중이 20%에서 92%로 크게 늘었습니다.
최근에는 AI 교정 사례를 분석해 공유했는데, 답글 대부분이 팀원들로부터 나왔습니다. 인프라팀의 주간 정책 회의가 탄생한 순간이기도 합니다.
한계: 아직 부족한 지표
긍정적인 수치만 보면 발전할 여지가 좁아집니다. 부족한 점도 함께 기록합니다.
- 담당자 자동 배정은 14%의 오차 범위를 보입니다.
- 셀프 서비스로 넘기려던 18건 가운데 13건은 실제로 쓸 수 없었습니다. 검색이 본문을 보지 않고 제목만 훑고 있었습니다.
- 4개월만에 표준 답변 17개 가운데 4개는 잘못된 답변을 하고 있었습니다. 낡은 답변은 매주 업데이트하고, 적중률을 확인합니다.
- 파트별 정책이 AI 세션에 한 번도 불려오지 않았습니다. 파일은 있는데 불러오는 경로가 잘못 설정돼 있었고, 비교적 최근에 수정했습니다. 적어 둔 규칙과 실제 작동하는 규칙은 다릅니다.
- 첫 답은 여전히 팀 리드에게 몰립니다. 담당자가 자동으로 정해져도 문의 채널 첫 답글의 37%를 리드가 답니다. 자동 배정 전과 같은 수치입니다. 의도적으로 팀 리드가 한 박자 늦게 관여하는 연습이 필요합니다.
- 팀원 모두가 지식DB에 기여해야 합니다. 아직까지 지식DB의 절반 이상을 리드가, 나머지는 한 명의 팀원이 작성하고 있습니다. 상반기에 9명이 기여하던 정책 저장소도 현재 3명으로 줄었습니다.
다음 단계: 에이전트 권한 4단계
이렇게 설정한 출발선 위에서 파트별 에이전트를 만들고 있습니다. 라이스(DevOps)는 운영 중이고, 보안(WAF·Okta) 봇을 준비 단계이며, DB·개인정보·SRE도 라이스의 구조를 본떠 만들기 시작했습니다.
에이전트에게 권한을 넘기는 순서는 신입 구성원의 온콜과 같습니다.
단계 | 팀원(신입) | 에이전트 |
1 | 모니터링만 한다 | 조회만 한다 |
2 | 1차 온콜, 기존 담당자가 서포트한다 | 제안만 한다. 쓰기는 승인 카드까지 |
3 | 정식 담당자가 된다 | 사람이 승인하면 실행한다 |
4 | 다른 파트와 함께 해결한다 | 기준을 넘으면 스스로 만들고 고치고 지우며, 에이전트끼리 한 문제를 나눠 푼다 |
라이스는 지금 3단계로 넘어가고 있습니다. 쓰기 작업은 승인 카드로만 올리고, 카드를 올리기 전에 그 작업이 실제로 통과하는지 먼저 시험합니다. 도구를 부르는 횟수에도 상한을 뒀습니다.
4단계로 가기 전에 할 일이 있습니다. 노트북 밖에서도 휴대폰과 음성으로 같은 답을 빨리 받게 하고, 응답 속도와 토큰 비용을 줄여야 합니다. 한 칸 올리는 기준도 필요했는데, 이렇게 정했습니다.
4주 동안 에이전트의 제안이 사람의 판단과 90% 이상 일치하고, 되돌린 작업이 한 건도 없으면 다음 단계로 넘깁니다. 신입 구성원의 온콜을 정식 1차 담당자로 지정할 때 던지는 질문과 같습니다.
“이 사람에게 맡겼을 때 되돌릴 일이 없었는가”
마치며
이전까지 업무 요청에 빠르게 대응하면서 팀원이 하고 싶은 일을 할 수 있도록 돕는 것은 이상적인 목표처럼 보였습니다. 반복되는 요청을 정리해 일관된 정보를 제공하면, 업무 요청자와 담당자의 시간을 모두 아낄 수 있습니다. 나아가 팀의 생산성에도 기여할 수 있습니다.
인프라팀의 업무 요청 출발선은 지금도 개선하고 있습니다. 이후엔 파트별 에이전트가 발전하는 과정을 다뤄보겠습니다.
김용현 Infra Lead
추측 대신 실측으로.
사람은 예외 상황에만 집중할 수 있는 효율적인 운영 구조를 만듭니다.