어제 API 호출을 통한 데이터를 저장했음으로, 이제 프론트로 보낼 데이터는 갖췄다고 생각한다.
여기서 큰 분기점이 될 것이라 생각하는데,
가 되겠다.
1번의 근거로는
2번의 근거로는
이후 곰곰히 생각을 해봤는데 바로 배포를 하는것이 좋을거 같다는 생각을 했다.
배포를 하는것에 대한 이점을 생각해 봤다.
1. 이 프로젝트의 목표를 생각해 보자.

https://velog.io/@kts5927/개인-프로젝트
프로젝트의 첫번째 글에 목적을 적어놨다.
내가 만들고 싶은걸 만들고 있고,
많은 사람들이 쓸 수 있는건 지금으로써는 어찌 할 수 없다.
하지만 기술적 지식을 습득 할 수 있는 프로그램이라는 것이 단순히 Spring 프레임워크를 주구장창 쓴다는건 아니라고 생각한다.
왜냐면 전체적인 개발 프로세스를 이해하고, 내가 코드를 적는것이 어떤 흐름을 통해 client에 보여지는지를 이해하는 것이 정말 중요하다고 생각했고, 그래서 프레임워크와 언어, 기법 등에 공부하기 위해 상당히 많은 시간을 소비했다.
2. 배포를 하였을때 이점이 무엇인가?

현재 상황을 생각해 보자.
기획(plan) -> 코딩(code) -> 실행(build) -> 테스트(test) 까지는 했지만
release, deploy, operate, monitor 부분이 완전히 빠져 있다.
즉, 정말 간단하게나마 돌아가는 프로그램을 만들지만, 그건 Local 환경에서만 돌아가는 코드뭉치일 뿐이라는 것이다. 프로그램으로서 반쪽자리라는 뜻이다.
또한 코드들이 점점 커지면서 배포 했을때 테스트도 해야 하는데, 모든 상황을 가정하고 테스트 코드를 작성할 수도 없다. 즉, 코드가 작을때부터 가능한 모든 상황을 테스트하고, 코드의 품질을 높히며 신중하게 프로그램을 키우면 된다는 것이다.
요약을 하자면,
프로그램의 품질을 높히고 변수를 통제하기 위해서는 기능이 적을때 배포를 해서 테스트를 확실하게 하는게 좋다고 생각한다.
3. 배포에 어려움은 무엇이 있는가?

https://velog.io/@kts5927/프로젝트-아키텍처
가장 큰 난관은 앞으로 사용해야 할 프로그램들을 이해해야 하는 것이다.
당장 AWS만 하더라도 정글 교육과정때 직원분들이 오셔서 질답을 받고 강의를 해주실 만큼 쉽게 접근할 수는 없는 서비스이다. 또한 GitHub Action, Jenkins, Docker 등등 CI/CD 툴을 활용해야 한다.
또한 Commit을 잘못했을때 어떻게 대처를 해야할지, 크롤링 봇들의 공격이 들어왔을때는 어떻게 해야할지 등등 한번 대처 잘못했다가 많은 리스크를 가질 수도 있기 때문에 조심해야 한다.
(물론 그럴 확률은 적겠지만 많은사람들이 말하는 것을 보면 조심해서 나쁠게 없다.)
이러한 생각을 통해 배포를 우선적으로 하기로 하였고, 앞으로의 계획은
가 되겠다.
갈길이 멀고 끝이 보이지 않지만, 하나씩 꾸준히 해 나가자.