점검 기간

여러 포스팅을 통해 LAH가 정말 바쁜 시간을 보내고 있다는 얘기를 했습니다.
신규 서비스도 있고, 리뉴얼도 있고, 더군다나 AI의 지원 덕분에 더 바빠졌죠.

그래도 지금처럼 바빴던 일들이 조금은 안정화되고 있습니다.
곧 오픈인 서비스도 있고, 리뉴얼 서비스도 1차 기획은 마무리되었으니까요.

마무리라고는 하지만 사실 앞으로 할 일도 너무 많습니다.
개발할 것도 많고, 콘텐츠와 마케팅 구성도 다 해야 합니다.
그래도 이번에는 점검 기간을 가져보려고 합니다.

꽤 긴 기간 동안 가장 높은 우선순위는 PMF를 찾는 일이었고, MVP를 개발하는 일이었습니다. 사실 지금도 비슷하긴 합니다.
이렇게 우선순위가 설정되어 있으면 놓치는 것들이 많습니다.
과거 포스팅에서는 테스트 코드가 부재했다거나, 배포 시스템이 없었다거나 여러 이슈가 있었지만, 지금은 또 다릅니다.

서비스 운영 관점에서 기존에 구성된 관리자와 아키텍처, 모니터링에 대한 점검이 필요하다는 생각이 들었습니다.
신규 개발 우선순위가 너무 높다 보면, 운영 과정에서 불편함이나 심지어 빈도가 낮거나 CS로 처리가 가능한 이슈들은 개발을 미루게 됩니다.
가장 단적인 예시로, GCP의 Cloud SQL을 사용하면 자동 백업을 설정합니다.
자동 백업 기능은 정기적으로 DB를 백업해 주는 기능인데, 이때는 DB에 접근이 안 될 수 있습니다.
GCP는 백업 일정을 시간대별로 설정할 수 있습니다.
2시 ~ 6시와 같이 설정할 수 있고, 대부분 서비스는 새벽 시간대로 되어있습니다.
DB 백업은 5분 내외로 완료되는데, 마침 그 시간에 접속한 고객은 서비스 이용이 안 될 수도 있었습니다.

이제 회사 서비스들의 규모도 많이 커졌고, 서비스의 안정성도 매우 중요해졌습니다.
지금까지는 불이 활활 타서 철을 녹이는 시기였다면, 이제는 망치로 두드려야 하는 시기가 아닐까 생각합니다.
아키텍처도 단단해져야 하고, 이를 운영하는 담당자와 개발자 모두가 단단해져야 하는 시기가 왔습니다.

이번에도 LAH만의 방향과 속도를 설정할 수 있어, 즐겁습니다.
이러한 문제를 인식하고, 불편함을 경험하고, 고민해서 개선하는 과정은 참 귀한 경험입니다.
언젠가, 변경하면서 겪은 경험을 공유하는 포스팅으로 꼭 돌아오겠습니다.

---