만드는 단계에서 운영하는 단계로

기능을 만들던 단계에서 만든 것을 운영하는 단계로 넘어가며 바뀐 것들을 정리합니다. 버전, 배포 자동화, 그리고 무엇이 도는지 들여다보는 일에 대한 이야기입니다.

지난 다섯 편은 "무엇을 어떻게 만들었나"에 대한 이야기였습니다. 어느 시점부터는 질문이 바뀌었습니다. 만드는 것보다 만든 것을 굴리는 일이 더 중요해졌습니다.

질문이 바뀌었습니다

만들 때의 질문은 단순합니다. "이게 되는가?" 동작하면 됩니다.

운영의 질문은 다릅니다.

• 지금 무엇이 돌고 있는가?
• 무엇이 언제 바뀌었는가?
• 깨지면 누가, 얼마나 빨리 아는가?

같은 코드를 두고도 보는 각도가 완전히 달라졌습니다. 이 질문들에 답하려고 몇 가지를 새로 갖췄습니다.

버전과 변경 이력 ("지금 뭐가 떠 있지?")

1편에서 서비스를 15개로 나눴다고 했습니다. 각 서비스가 따로 배포되니, 곧 "지금 어느 서비스가 어느 버전으로 떠 있는지"를 아무도 모르는 상황이 됐습니다.

처음엔 "최신이 맞겠지"로 버텼습니다. 하지만 문제가 생겼을 때, 최신이 무엇인지조차 헷갈렸습니다.

비유로 보면

매일 메뉴가 바뀌는 식당인데 메뉴판에 날짜가 없는 셈입니다. 손님도, 주방도 "오늘 뭐가 바뀌었지?"를 모릅니다.

그래서 두 가지를 도입했습니다.

• 커밋 메시지 규칙: 모든 변경이 "기능 추가인지, 버그 수정인지"를 일정한 형식으로 남기게 했습니다.
• 버전과 변경 이력 자동화: 그 커밋들을 모아 서비스별 버전을 올리고, 변경 이력(CHANGELOG)을 자동으로 만들게 했습니다. 사람이 손으로 적지 않습니다.

여기서 작은 결정 하나가 있었습니다. 처음엔 정기 배포(주 1회)마다 버전 번호를 한 칸씩 올렸는데, 매주 올리니 번호가 너무 빨리 커졌습니다. 그래서 사람이 보는 정기 배포 묶음에는 날짜 라벨을 붙이고, 실제 버전 번호는 변경량에 따라 자동으로 오르게 분리했습니다. 사람이 읽기 좋은 표시와 기계가 계산하는 값을 나눈 것입니다.

손으로 배포하는 걸 그만뒀습니다

초기에는 배포를 손으로 했습니다. 사람이 하면 사람마다 순서가 다르고, 한 단계를 빠뜨립니다. 특히 "데이터베이스 변경을 먼저, 그다음 서비스 배포" 같은 순서를 놓치면 사고로 이어집니다.

그래서 브랜치에 합치면 자동으로 배포되도록 바꿨습니다. 개발용 브랜치는 개발 환경으로, 운영용 브랜치는 운영 환경으로 흘러가게요. 손으로 옮기던 일을 컨베이어에 올린 셈입니다.

자동화의 진짜 이점은 속도가 아니라 매번 똑같이 한다는 점이었습니다. 사람의 컨디션에 배포가 좌우되지 않습니다.

들여다보기, 안 보면 모릅니다

운영에서 가장 먼저 부딪힌 벽은 "무슨 일이 일어났는지 안 보인다"였습니다. 지난 편들에서 반복된 사고들(조용히 버려진 쿠키, 조용히 지워진 메시지)이 오래간 이유도 결국 같았습니다. 보이지 않았기 때문입니다.

계기판 없는 차로 고속도로를 달리는 것과 같습니다. 속도도 연료도 모르면, 문제가 터지고 나서야 압니다. 그래서 들여다보는 장치를 갖췄습니다.

• 누가 언제 무엇을 했는지 남기는 감사 기록
• 무엇이 얼마나 도는지 보여주는 지표와 로그
• 쌓인 데이터를 모아 보는 대시보드

다 만든 뒤에야 깨달았습니다. 만드는 동안에는 관측이 사치처럼 느껴지지만, 운영에 들어가면 가장 먼저 필요한 것이었습니다.

만들 수 있다 ≠ 운영할 수 있다

이 단계를 지나며 일하는 기준이 바뀌었습니다. 예전에는 "기능을 얼마나 빨리 만드나"가 기준이었습니다. 지금은 "이걸 계속 굴릴 수 있나"가 기준입니다.

그래서 관리할 수 있는 만큼만 만드는 쪽으로 방향을 틀었습니다. 화려하게 많이 만드는 것보다, 적게 만들더라도 무엇이 도는지 알고 고칠 수 있는 상태가 중요해졌습니다.

마무리

• 만들 때의 질문("되는가?")과 운영의 질문("지금 무엇이 도는가, 깨지면 누가 아는가?")은 다릅니다.
• 서비스가 따로 배포되면 "지금 뭐가 떠 있지"가 안 보입니다. 커밋 규칙 + 버전·변경 이력 자동화로 답을 만들었습니다.
• 손 배포는 매번 달라집니다. 자동 배포의 진짜 이점은 매번 똑같다는 것입니다.
• 안 보면 모릅니다. 감사·지표·대시보드는 운영에 들어가면 가장 먼저 필요했습니다.
• 기준이 "빨리 만든다"에서 "계속 굴릴 수 있다"로 바뀌었습니다.

여기까지가 6개월간 백엔드·프론트엔드·인프라를 만들고 굴려 온 기록입니다. 다음 편에서는 이 과정을 통째로 돌아보며, 다시 시작한다면 무엇을 다르게 할지를 정리해 볼 생각입니다.