이전에 있었던 프로젝트에서 앱을 완성시키면 보통 앱을 로컬에서 작동시켜왔었고, 배포를 한 것이라고 생각했다.
로컬에서 서비스를 운영을 하고, 사용자를 받을거라면 배포를 한 것이라 봐도 무방하다고 생각한다.
서비스를 운영한다고 했는데, 이를 위해 보통 컴퓨터를 24시간 매일 구동시켜야할 것이다.
상식적으로 생각했을 때 본인의 컴퓨터를 24시간 매일 구동시키는 것은 어려운 일이다.
또, 사용자가 진~짜 많은 서비스를 운영한다고 했을 때 발생하는 많은 트래픽들을 감당하긴 어려울 것이고, 내 컴퓨터로 다른 개인적인 작업을 하는 데도 지장이 있을 것이다.
결국 24시간 매일 서버를 구동할 수 있고, 사용자가 접근할 수 있는!
서비스를 적절하게 운영할 수 있는 환경에서 앱이 배포한 것이라고 말할 수 있을 것 같다.
배포 이전에는 빌드 그리고 테스트를 거치게 된다.
이는 효율적으로 서비스를 운영하고, 사용자에게 만족감을 주기 위한 단계라고 생각한다.
각 단계에 대해 간단히 얘기해보겠다.
빌드는 개발 환경에서의 대량의 리소스들을 운영하기에 최적화된 리소스로 변환 또는 압축하는 작업이다.
빌드를 통해서 생성되는 산출물은 소프트웨어 특성마다 다양하다.
(ex. react 앱을 빌드하면 압축된 정적파일들이 생성된다.)
테스트는 다양한 케이스에서 특정 기능을 테스트해서 안정성을 높이기 위한 작업이다.
구현을 다 했다고 해서 땡이 아니라, 사전에 구현한 것에 대한 테스트를 진행해서 결함을 발견하고 없애야 한다.
코딩테스트도 생각해보면, 구현했다고 해서 땡이 아니라 많은 테스트 케이스를 통해 구현한 것이 옳은지 결론이 난다.
그리고 옳은 구현이라는 목적을 위해 코드를 다시보며 버그를 해결해야 했다.
따라서 테스트는 중요한 단계라고 생각한다.
CI/CD를 한 번쯤 들어봤을 것 이다.
그리고 이 용어와 함께 항상 따라오는 것이 통합 자동화, 배포 자동화이다.
배포에 대해 중심적으로 얘기할 거기 때문에, 배포 자동화에 대해서만 얘기해보겠다.
이번에 API서버를 처음으로 배포 자동화를 적용해서 배포를 했다.
적용하기 이전에는 수동으로 ec2에다 배포를 했다.
이를 위한 과정을 간단하게 보자.
1. 원격 프로그램 실행
2. key 입력
3. 터미널 접속, 브랜치 업데이트
4. 의존 모듈 설치
5. 앱 재로드
번거로운데다가 귀찮고 또 실수 할 여지가 있다.
운영할 서비스에 실수를 저질렀다?? 😱 상상만으로도 끔찍하다....
하지만 이 과정을 자동화시킨다면 사전에 정의된 step대로 순차적으로 실행이 되기때문에 문제될 게 없을 것이다.
배포 프로세스 또한 빠르게 진행되기 때문에 결론적으로 통합 자동화와 함께 배포 자동화는 팀 생산성을 향상시키는데 가치있는 방법이라고 생각한다.
이전에는 빌드나 배포하는 이유를 보며 아~그렇구나 하고 말았었다. 깊게 이해하려 하지 않았다. 아마 그때의 나는 이런 용어들이 와닿지 않아서 그랬었던 것 같다.
이번에 본격적으로 배포를 해보면서 왜 이렇게 까지해야할까? 라는 고민을 통해, 아~ 이래서 이렇게 해야되구나! 하며 이해를 할 수 있었고 글로 내 생각을 풀어냄으로서, 1주일간 배포 & 배포 자동화를 구현하며 느낀 것들을 정리할 수 있었다.
배포, 빌드, 테스트에 대한 생각이 너무 깔끔하시고 명쾌하시네요..! 덕분에 많이 배워갑니다 >3<