Last updated
Was this helpful?
Last updated
Was this helpful?
요즘 이상하게 글이 잘 안써지네. 옛날에는 글을 쓰면서 생각을 정리하고 그러다가 의외의 답을 찾아가는 그런 경험들을 했었는데, 요즘은 머리속으로 충분히 생각을 하는 것만으로도 어느정도 결론이 도출되니 글로 옮기는 과정이 좀 지루하게 느껴지는 것 같다.
어제 이라는 글을 썼는데, 그 이후 생각이 조금 달라진 부분들도 있고 해서, 관련 이슈들을 큰 그림으로 되짚어봐야겠다는 생각이 들었다.
진짜 문제가 무엇이냐
지난주 특정 확장자에서 배경제거가 되지 않는 이슈가 있었다.
20시쯤 PM, QA가 모두 퇴근한 뒤 프로덕션 서버 배포가 이루어졌고
해당 배포 건에 jpg 이미지로 배경제거시 결과 이미지를 webp로 반환하는 코드가 포함되었고 이는 서비스에서 지원하지 않는 확장자여서 오류메시지가 노출되는 상황이었다.
배경제거를 시도하는 많은 이미지들은 jpg 확장자를 가지고 있어서 고객 영향범위가 넓었고
저녁 배포때문에 장애 시간이 16시간정도로 길어지게 되었다.
사실 위의 내용은 문제라기보다는 이미 벌어진 사건이자 현상이다. 그렇다면 진짜 문제는 무엇일까?
정해진 배포일이 아니라 비정기적으로 임의 배포를 진행한다.
장애 상황을 빠르게 확인할 수 없는 늦은 시간 배포가 이루어졌다.
스테이징 환경에서 충분히 QA를 거치지 않고 프로덕션 배포가 이루어졌다.
스테이징, 프로덕션 배포 시점을 PM, QA가 정확하게 알 수 없다.
진짜 문제를 해결하기 위한 방법은 무엇인가
단순 해결책을 생각하면 사실 하나다.
한 팀의 예외없이 정기배포일을 지켜서 배포를 하면 된다.
그런데 만약 이게 불가능한 경우라면? 그 팀이 이 규칙을 따르고 싶지 않아한다면?
그렇다면 우리는 해당 팀이 비정기적으로 QA를 거치지 않고 배포를 해도 안정적으로 서비스를 운영할 수 있는 방법을 찾아야 한다.
모니터링 자동화 툴을 이용하여 실서버를 30분 간격으로 체크한다.
--> 장애를 막지 못한다면 최대한 빠르게 캐치할 수 있도록 한다.
웬만큼 급하지 않다면, 저녁 배포는 하지 않는다. --> 10시 ~ 16시 사이에 배포를 진행한다.
배포 시점을 PM, QA가 알 수 있도록 한다 --> github-slack 연결을 통해 배포 알림이 자동 전송되도록 한다.
스테이징에서 충분히 QA를 진행한 뒤 배포될 수 있도록 한다.
남겨진 질문들
처음에는 전체 규칙을 따르지 않는 한 명의 개발자로 인해 함께 일하는 PM, QA가 함께 책임을 져야한다는 것이 부당하다는 생각이 들었는데 개발 리드분, QA분이랑 함께 이야기를 나눠보면서 조금씩은 그 분들을 이해할 수 있게 되었다. 개발 리드분이 말씀하신 것처럼 어쩌면 비정기배포가 앞으로 나아가야할 방향이고, 내가 전통적인 방법에 갇혀있었던 것은 아닐까.
스쿼드에 계속 있으면서 실제로 그 분이 뾰족하고 어려운 이슈들을 해결하는 과정을 보면서 정말 실력으로 입증을 해낸다면, 다른 것은 다 눈감아줄 수도 있겠구나-싶은 생각이 들었다. 뾰족한 하나의 강점을 가진 사람이 이래서 필요하구나, 사람의 강점에 집중하는 것이 중요하겠구나- 깨닫게 되는 계기가 되었다. (점점 스며들고 있는건가...)
2025.05.01