Stan 기술블로그

사내 전체에 시스템을 소개하는 법

기능 대신 전과 후를 보여 주고 정하지 않은 건 말하지 않은 사내 발표

10월 6일, 사내 전체를 대상으로 모니터링 시스템과 배포관리 시스템을 소개하는 발표를 했다. 한 달 전 TabbyML 발표는 개발자 앞이었고 이번엔 사내 전체였다. 처음엔 어떻게 만들었고 무엇이 들어 있는지를 빠짐없이 보여 주려 했는데 다시 보니 듣는 사람이 궁금한 건 그게 아니었다. 이 글은 그 자료를 여러 번 고친 기록이다. 슬라이드는 사내 자료라 올리지 않는다.

기능 소개로는 들리지 않는다

처음 자료는 Tabby 발표처럼 이야기 구조로 짰다. 왜 만들었나 → 무엇인가 → 어떻게 만들었나 → 운영하며 고친 것 → 어떻게 쓰나 → 앞으로. 다음 날에는 기능을 빠짐없이 보여 주는 15장으로 바꿨다.

둘 다 만드는 쪽에서 보면 자연스러운 순서다. 어떻게 만들었고 무엇이 들어 있는지는 만들고 운영하는 사람에게 중요한 이야기다. 사내 전체가 궁금한 건 하나였다. “그래서 나한테 뭐가 바뀌나.”

기능 대신 전과 후를 놓았다

두 시스템을 자료 두 개로 나누고 장마다 전과 후를 놓았다. 핵심은 이 표였다.

  전 후
서버 상태 확인 사람이 서버에 들어가 본다 이상하면 알림이 먼저 온다
장애를 아는 때 장애가 난 뒤 장애 전, 기준을 넘는 순간
정기 점검 매일 주 1회로 줄일 예정
배포 목록 이력을 뒤져 엑셀로 정리 화면에서 파일을 체크
배포 요청 메신저와 엑셀로 화면에서 요청, 커밋 메시지가 함께
반영 사람이 손으로 승인하면 시스템이

배포관리 쪽은 예전 방식의 불편을 양쪽에서 짚었다. 인프라는 반영 시간과 실수 가능성을, 개발자는 기다림을 떠안고 있었다. 기능은 “무엇인가” 한 장(요청·반영·승인·기록)으로 줄이고 나머지는 누가 무엇을 덜 하게 되는지에 썼다.

이름도 듣는 사람의 말로 바꿨다. 제목에는 사내 약칭 대신 “모니터링 시스템”, “배포관리 시스템”을 쓰고 약칭은 부제로 내렸다. 알림 단계 이름도 “비정상 알림”, “정상 알림”으로 풀었다.

한 장에 한 문장

다시 짠 자료도 한눈에 안 들어왔다. 세어 보니 장마다 글 조각이 15~29개였다. “직접 접속에서 알림으로”라는 같은 말이 한 자료에 다섯 번 나왔고 정작 듣는 사람이 궁금해할 숫자 칸은 비어 있었다. 본문 글자는 24~28px라 프로젝터로 띄우면 더 작다.

규칙을 정했다. 장마다 제목 한 문장과 그림 하나만 남기고 설명은 발표자 메모로 옮긴다. 본문은 32px 이상, 핵심어는 그보다 크게 쓴다. 모니터링 자료는 11장에서 9장으로, 배포관리 자료는 10장에서 8장으로 줄었다.

흐름은 덩어리로 그렸다

배포 흐름은 배포 목록 생성 → 요청 → 반영 → 수정 → 요청 → 반영 → 운영 반영 요청 → 운영 반영, 여덟 단계다. “무슨 요청이고 무슨 반영이냐”는 질문에 단계마다 설명을 붙였더니 칸은 작아지고 글은 늘어 난잡해졌다.

준비, 테스트, 운영 세 덩어리로 묶고 테스트 안에서 고치고 다시 요청하는 반복은 화살표 하나와 “확인될 때까지 반복”으로 대신했다. 여덟 칸이 여섯 칸이 됐다.

정하지 않은 건 말하지 않는다

처음 목차에는 “앞으로” 장이 있었다. 발표 전에 받은 마지막 피드백으로 이 장을 뺐다. 사내 전체 앞에서 말한 다음 단계는 일정이 붙은 약속으로 들린다. 배포관리 자료에서도 일정과 먼 목표는 빼고 지금 적용한 범위와 바로 붙일 것만 남겼다.

질문도 같은 기준으로 준비했다.

예상 질문 답의 핵심
기존 모니터링 도구를 두고 왜 직접 만들었어요? 우리 환경(사내망, 사내 로그인, 이미 있는 DB를 SQL로 붙이는 구조)에 맞춘 범용 엔진이라는 데까지만 답한다
에러 모니터링(Sentry)이랑 뭐가 달라요? Sentry는 앱 안에서 난 에러를, 모니터링 시스템은 서버 자체의 상태를 본다. 서로 보완한다
알림이 너무 많이 오면요? 기준을 잠깐 넘는 걸로는 울리지 않는다. 몇 분 넘게 이어질 때만 울린다

가장 세게 준비한 건 첫 질문이었다. 다른 도구보다 낫다고 말하려면 근거를 대야 하는데 확인한 근거가 없었다. 그래서 우리 환경에 맞췄다는 사실까지만 말하기로 했다.

배운 것

듣는 사람이 바뀌면 같은 시스템도 다른 이야기가 된다. Tabby 발표는 개발자에게 왜 이 도구인지를 설득하는 자리였고 이번 발표는 사내 전체에 무엇이 나아지는지를 보여 주는 자리였다. 기능은 그 답을 뒷받침하는 자리로 내려갔다. 줄일 때는 감 대신 세어 보고 줄였다. 같은 말이 몇 번 나오는지 세자 무엇을 발표자 메모로 보낼지가 바로 정해졌다. 아직 정하지 않은 것은 말하지 않는다. 다음 단계도 근거 없는 비교도 듣는 사람에게는 약속이나 주장으로 남는다.

인프라 운영 카테고리의 글