항해99 1주차 WIL

WIL - Weekly, I Learned

11/01	11/02	11/03	11/04	11/05	11/06
팀 배정	진행 상황 공유	진행 상황 공유	AWS 서버 세팅	깃 및 진행상황 공유	회고 멘토링 준비
프로젝트 기획	[강의] 웹개발 플러스 4주차	로그인 기능 구현	도메인 연결	오류 점검	멘토님과 회고 멘토링 진행
와이어 프레임 설계	Git Hub 팀 계정 생성 및 세팅	회원가입 기능 구현	깃 및 진행상황 공유	선택과 집중의 시간	주특기 선택 면담
스코프 분배	진행 상황 공유	깃 및 진행 상황 공유	메인페이지 오류 수정	최종 점검	주특기 최종 선택
개발 기능 정리		메인페이지 기능 구현	깃 및 진행상황 공유	서버 업로드
S.A 제출				유튜브 업로드
[강의] 웹개발 플러스 2주차				프로젝트 마감

---

11/01 월요일

팀 배정

팀장이 될 일은 많았지만 자리에 대한 책임을 갖는 게 너무 싫어서 20년을 넘게 피했는데 이번엔 못 피했다. 팀은 총 4인으로 구성되었으며, 내가 팀장이다. 아무래도 개발에 대한 사전 지식이 있기 때문에 뽑힌 것 같다. 너무 싫었지만 그래도 협업을 중요시하는 주제의 미니 프로젝트의 팀장이라 그나마 다행이라 생각한다. 그것도 잠시였다...

 

프로젝트 기획

첫 프로젝트를 회의를 시작했다. 다들 개발이 처음이신 어른이 분들의 모임이라 서비스 중점의 프로젝트보다는 이걸 했네?라는 생각을 시작으로 개발에 흥미를 가졌으면 해서 간단한 포스팅 기능을 중심으로 기획했다. 전 기수들이 했던 프로젝트를 훑어보니 그 어디에나 있는 여행 사진 업로드로 정했다. 그냥 여행사진 업로드면 뭔가 심심한 느낌이라 "나만의 감성 가득한 장소를 다른 사람과 함께 공유 가능한 서비스입니다"라는 감성의 설명을 추가했다. 그리하여 프로젝트 제목은 "감성에 빠지는 spot", 프로젝트 팀 이름은 "감.빠.스".

 

와이어 프레임 설계

브레인스토밍을 먼저 할까 하다가 그럼 너무 복잡해지고 이게 뭐지?라고 생각할 것 같아 팀원 모두에게 생각하는 페이지를 간단히 그려오세요~ 해서 모두의 의견을 취합해 가장 설계하기 쉬운 걸 정했다.

 

스코프 분배

스코프란 단어는 아직 다른 팀원들이 익숙하지 않은 것 같아 페이지 분배라고 했다.

1. 로그인 + 회원가입 페이지
2. 메인 페이지
3. 게시글 페이지
4. 프로필 페이지

 

개발 기능 정리

기능	Method	URL	request	response
로그인	POST	/api/login	{'uId':uId, 'uPw':uPw}	회원 정보
회원가입	POST	/api/signup	{'uId':uId, 'uPw':uPw, 'uName':uName, 'uEmail':uEmail}	작성 회원 정보
회원 중복 확인하기	GET
로그아웃	POST	/logout
메인	GET	/api/main
포스팅	POST	/api/posting	{'pNum':pNum, 'uId':uId, 'title':title, 'comment':comment}	작성 포스팅 데이터
포스팅 상세보기	GET	/api/detail	{'pNum':pNum, 'uId':uId, 'title':title, 'comment':comment}
포스팅 수정하기	POST	/api/detail	{'pNum':pNum, 'uId':uId, 'title':title, 'comment':comment}
포스팅 삭제하기	POST	/api/detail	{'pNum':pNum, 'uId':uId, 'title':title, 'comment':comment}
댓글 작성	POST
댓글 불러오기	GET

API에 대해 잘 모르는 나는 결국 빠른 시간 내에 작성하기로 마음먹고 프로필을 댓글로 변경하였다.

사실 팀원 한 분이 이런 프로젝트도 처음이고, 사전 강의도 전부 수강하지 않은 상태라 많이 부담되셨는지 장문의 카톡을 보낸 후 나가셨다... 잡을 기회도 주지 않고 가셨다. 아 그렇게 팀은 3명이 되었습니다. 제가 진짜 쉬운 거 드렸어요... 제가 먼저 다 하고 도와드리려 했는데 왜 가셨나요...)

일단 S.A 제출 시간이 코 앞이라 API에 대해 공부도 없이 제출 완료.

 

[강의] 웹개발 플러스 2주차

프로젝트를 바로 시작할까 생각했지만 그냥 만들면 재미없다며 항해에서 필수 포함 사항을 포함해서 완성하라는... 그런... 무시무시한 퀘스트 조건을 만들었기 때문에 팀원 모두 그 조건에 적합한 강의 2주 차, 4주 차를 수강하고 진행하기로 했다.

1. Jinja2 템플릿 엔진을 이용한 서버사이드 렌더링 (어떤 장점이 있을까?)
2. JWT 인증 방식으로 로그인 구현하기 (쿠키/세션 방식에 비해 어떤 장점이 있을까?)

영상을 보는 것보다는 강의 자료에 필요한 걸 찾아서 하라는데 아직 개발 어른이인 우리는 그냥 마음을 편히 하고 영상을 시청함

 

최대한 필요한 부분만 봐야지, 오늘 무조건 일찍 자야지, 수요일부터 새벽까지 할 텐데 첫날은 그래도 일찍 쉬어야지라고 생각했지만 실패했다. 강의도 길지만 강사님의 설명이 강의 자료에 많이 첨부되어 있지 않았으며, 말도 빠르신 편이라 바른 자세로 공부했다. 너무 많은 강의를 한 번에 들으니 정리는 안 됐지만 그래도 필요한 부분은 어떻게 구현하는지 습득 완료! 그 부분 이외에 다른 부분도 좋은 설명이 많으니 일요일에 다시 들어야겠다 생각했지만 난 지금 이걸 쓰고 있다. 시간이 참 빠르게 지나갑니다.

 

---

11/02 화요일

진행 상황 공유

첫 팀 회의를 시작했다. 월요일에 참여 못 하신 팀원까지 총 3명이 모여 회의를 시작.

메인 페이지가 첫 화면에 뜨는 게 좋을까 고민했지만 웹개발 플러스 강의는 로그인 화면이 첫 화면이기 때문에 쉽게 그걸 그대로 사용하기로 했다. 그렇다고 코드를 복사 붙여넣기 하는 것도 이게 무슨 기능인지 알아야 가능한 일이니 4주 차를 듣기로 했다. 다른 팀들은 뼈대 개발하고 필요한 부분들만 강의 영상으로 본다고 하는데... 다들 천재인가 대단하다. 하지만 그건 그들의 진행 상황이니 우리도 빨리 시작해야지란 생각은 없었다.

팀원 또 사라지면 어떡해...

 

[강의] 웹개발 플러스 4주차

팀이 3명으로 축소되어 로그인, 회원가입 부분을 다 가져와서 그 부분만 들어야지 했다가 또 실패했다. 난 팀장이니 혹시 모를 상황을 대비하여 도움이 될 대부분은 알아야 한다 생각이 들어 완강했다. 기분 탓인지 모르겠지만 강의 속도가 좀 있어 이것도 일요일에 다시 봐야지 했는데 그렇게 난 오늘 이걸 쓰고 있다.

 

Git Hub

예전 프로젝트 진행 때 깃허브로 고생을 많이 한 경험으로 월요일에 모든 팀이 깃을 합치고 있을 때 우리는 최대한 뒤로 미루다가 오류를 맞이해도 기쁘게 빠르게 최대한 금요일에는 오류를 만들면 안 되겠다 라는 생각으로 깃을 합치기 시작했다. 깃을 먼저 합치며 많은 오류를 접한 다른 팀들이 많이 도와주셔서 우리는 다른 팀보다는 수월하게 깃을 끝냈다. 깃 하나 제대로 알지 못하는 팀장을 욕하지 않고 같이 찾아봐 준 천사 같은 팀원들...

 

진행 상황 공유

강의를 어디까지 수강했는지 진도 상황 공유 후 오늘까지 전부 수강하기로 하여 내일부터 진짜 프로젝트 작업을 시작하기로 했다. 제출한 S.A에 대해 멘토님이 피드백을 주셨지만 반영은 못할 것 같다. 다음 날 점검이지만 죄송해요... 저도 파이썬은 처음이라...

와이어프레임, API 문서 모두 예쁘게 채워져 있네요.
적당한 범위인 것 같습니다. 다만 댓글 작성, ID 중복확인 등의 URL이 빠져있어서, 채워주시고 개발 시작하면 좋을 것 같아요.
화이팅!

---

11/03 수요일

진행 상황 공유

 

개발하려는 웹은 로그인 후 메인 페이지로 연결되니 내가 제일 먼저 만들어야 코드 합친 후 테스트를 시작하기 때문에 나를 제외한 다른 팀원들은 강의를 들으며 맡은 부분은 개발하기로 했다. 멘토링 시간에 필요한 질문지를 따로 만들까 했지만 아직 파일도 없기 때문에 일단 개발부터 시작!

 

로그인 기능 구현

로그인 페이지

회원가입 기능 구현

회원가입 페이지

깃 및 진행 상황 공유

완성된 로그인, 회원가입 페이지를 깃에 push 하며 무거움 마음 1은 내려놓음. 남은 내 무거운 마음은 99...

메인페이지 기능 구현

메인페이지

사실 메인 페이지는 다른 분이 맡으셨지만 혹시나 하는 마음에 시작. 어차피 프로젝트 진행은 다들 같은 강의를 바탕으로 하기 때문에 코드는 비슷하지 않을까, 중간중간 내 코드에 합쳐서 올리면 오류도 줄고 깔끔하지 않을까 싶은 마음으로 가볍게 시작했다. 가벼운 마음으로 시작해서 그런지 card 형식에서 예시로 올린 이미지 피카츄가 3등분 되고 난리였다. 아주 매우. CSS에서 margin, display 설정으로 피카츄의 몸은 더 이상 분해되지 않았다고 한다.

---

11/04 목요일

AWS 서버 세팅

메인 페이지까지 완성하고 배포했을 때 에러가 없나 확인차 연결했지만 인스턴스 값인지 터미널인지 해석도 불가능한 오류라 새 인스턴스를 생성.

Filezilla 이용하여 AWS - EC2 세팅 완료! 포트 포워딩 완료! Filezilla 업로드 완료! flask 실행+설치 완료! 포트 포워딩 성공! nohup 성공!

처음부터 새롭게 인스턴스 생성하면 금방 끝날 일을 오류 찾겠다고 2시간을 고뇌... 오류를 해결하는 순간 오는 희열은 좋지만 해결하지 못하고 새로 시작했을 때 오는 현타는 언제쯤 익숙해질지...

 

도메인 연결

미니 프로젝트 용이라 도메인을 다시 사긴 애매해서 종합반 때 구매한 도메인을 재사용하기로 결정했다. 새 인스턴스 IP 값으로 변경하는 일이라 간단하지 아주 쉽지! 이거 변경하고 10분 후에 확인하고 자면 그만이겠지! 했는데 20분이 지나도, 30분이 지나도 반영되지 않는다. 찾아보니 최대 48시간 걸린다고 한다. 목요일 새벽에 변경했고 최대 48시간이면 토요일 새벽 2시에 변경된다는 말인데 프로젝트 마감은 금요일 오후까지다... 제발 가비아 일해 주라... 자고 일어나면... 괜찮겠지...

그렇게 아침에도 반영되지 않았다고 한다.

 

깃 및 진행상황 공유

도메인 관련 이슈를 전달 및 코드 합치기(두근)

물론 마음대로 짠! 하고 합쳐지진 않았다. 팀원의 메인 페이지와 내가 만든 메인 페이지가 매우 비슷하기 때문에 그나마 CSS까지 적용된 내 페이지에 서버를 연결하기로 했다. 팀원은 내 의견에 한 번도 싫다고 하지 않는다... 다만 대답이 없을 뿐... 

 

메인 페이지 오류 수정

파일 받는 부분에서 오류가 났는지 삭제를 눌렀을 때 전체 사진이 삭제되는 상황이 생겼다. 무슨 일인가 한참 고민 끝에 찾아보니 모든 파일명이 file.jpg, file.png로 변경되어 업로드된 것이다. 그로 인해 file이란 이름을 가지면 다 삭제가 됐다. 이미지 파일의 이름이 중복되게 db에 저장되는 현상이 발생한 것이다. 팀원과 함께 해결 방법을 찾기로 했다. 금요일까지 고칠 수 없다면 과감하게 빼고 글만 업로드하는 방식으로 변경하도록...

깃 및 진행상황 공유

합쳤더니 오류 덩어리... 너란 녀석... 그리고 도메인은 아직도 답이 없다.

---

11/05 금요일

깃 및 진행상황 공유

프로젝트 마감! D-DAY! 프로필 페이지 연결 완료! 오류 수정 아직! 도메인도 아직! 이미지도 아직! 하지만 우리에겐 아직 시간이 남았기 때문에 다들 큰 오류보다는 작은 오류부터 수정을 시작.

오류 점검

그들은 과연 비전공인가... 그들은 과연 코딩이 처음인가...

첫날과 다르게 열심히 구글링을 한 결과 이미지 업로드를 성공! 강의자료와 구글링을 통해 datetime의 오늘 시간, strftime 함수의 현재 시간을 파일명 뒤에 붙여 DB에 저장되는 파일의 이름을 다르게 생성하여 해결 완료.

남은 오류는 프로필 페이지 진입 시 각 유저의 프로필을 확인하고 개인 포스팅만 불러와야 하는데 특정 유저가 아닌 모든 유저의 포스팅을 가져온다. 남은 시간이 더 없다면 기능을 제외하려 했지만 아직 시간도 충분하고 꼭 성공시키고 싶으신 마음이신 것 같아 좀 더 시간을 갖기로 했다.

 

선택과 집중의 시간

프로필 사진이 메인 페이지 카드에도 표시되었지만 계속된 오류로 인하여 제외.

특정 유저의 포스팅이 아닌 모든 유저의 포스팅을 가져오는 오류로 인하여 제외.

 

최종 점검

시간도 늦었고 Git에 합치다 코드 중복으로 오류에 더 이상 시간 뺏기고 싶지 않아 코드는 카톡으로 전달받아 추가했다. 최종 코드는 각 컴퓨터에 실행하여 테스트했더니 이상 없으며, 포트 포워딩까지 수월하게 끝냈다. 도메인은 48시간이 되기 직전에 연결 성공했다. 정말 아주 많이 다행이다. 

 

깃허브 업로드

https://github.com/Gambbas/GambbasProject

서버 업로드

http://cloudh.shop/

유튜브 업로드

https://youtu.be/m7i4y6Wfydo

항해99 4기 미니프로젝트 9조 영상

 

프로젝트 마감

슬랙으로 프로젝트 제출까지 끝. 첫 프로젝트를 성공적으로 마무리했다. 처음 보는 사람, 처음 코딩하는 사람끼리 모여 어떻게 프로젝트를 진행할까 생각했지만 서로 존중하고 배려하면 큰 일 없이 평범하게 마무리 가능하다. 원래 평범한 게 제일 힘들다.

---

11/06 토요일

회고 멘토링 준비

1. 소스코드에 주석 달기
2. GitHub에 readme.md 작성하기
3. Trouble Shooting 정리하기

 

멘토님과 회고 멘토링 진행

원활한 멘토링을 위해 질문지를 정리하던 중 팀원 한 분이 어제 제외시킨 기능 중 하나를 Trouble shooting 시키셨다. 이 분들 코드에 진심이다. 어제도 엄청 아쉬워하셔서 조만간 고치시지 않을까 했는데 그걸 이렇게 고치시다니... 결국 우리는 팀 프로젝트에 관한 질문보다는 곧 있을 주특기에 대한 질문을 했다. 아 우리 팀원은 수줍음이 많아서 팀 밖으로 나가서는 말이 없다. 멘토님이 안 친해지셨냐고 물어보는데 우리 그전까지 열심히 떠들었는데... 억울...

 

주특기 선택 면담

node.js를 주특기로 만들기 위해 항해99 부트캠프에 탑승했다. 하지만 spring 튜터님의 설명을 듣고 엄청 흔들렸다. 엄청 너무 많이 흔들려서 개인 멘토, 팀 멘토, 매니저님, 전 기수 분들 모두와 면담했다. 사실 제일 많이 흔들린 건 python으로 페이지를 구현하며 spring의 편리함에 미련 남았다.

 

spring

• 회사가 많다 = 취업 시장이 튼튼함
• 언어 : 자바 = 핵노잼
• 이미 알고 있어서 주특기 공부 때 편함
• 취업 후 혼자 공부하기엔 자바 진짜 노잼
• 어차피 회사에서 spring 다 공부함

node.js

• spring 대비 애기라 시니어 개발자 적음
• 언어 : 자바스크립트 = 존잼
• 모르지만 자바스크립트 존잼
• 취업 후 혼자 공부하기엔 자바스크립트 존잼
• 10년 뒤에 사라진다는 소리도 들리지만 내가 그때까지 살아있을지 그것도 미스터리
• 하지만 회사에서 spring 다 공부함

 

주특기 최종 선택

Hello Node.js!

어차피 지금 선택한 언어로 평생 먹고사는 게 아니다.

항해99 부트캠프 기간 동안 재밌게 코딩해야 중간에 지쳐서 이탈하지 않는다.

부트캠프 자금의 투자자께서 50년 뒤에도 존재할 spring을 선택하라 했을 때 절대 그럴 수 없지 라는 생각이 들며 확실하게 마음을 정했다. 투자자가 하라고 해도 당당히 하기 싫다면 그건 정말 하기 싫은 일이기 때문. 

프로젝트하면서 알게 된 사람들 모두 spring으로 가서 매우 슬프지만... Node.js 외로운 길이지만... 취업하면 외롭진 않겠지... 응... 그럴거야... 그러겠지...

 

---

11/07 일요일

한 주를 마치며

시작은 간단히 주제와 코멘트 형식으로 진행하여 빨리 끝내고 자바스크립트 강의 들어야지 했는데 어떡하지 벌써 22시.

다음 주는 매일 열심히 회고록을 올려 주말 정리는 간단히 해야겠다.라고 매번 못 지킬 말을...

코드 리뷰도 하고 하고 싶은 건 엄청 많았지만 코드 업로드를 시작으로 회고록은 다음날 끝날 것 같기에 코드 리뷰는 다음 주부터 열심히 차근차근한다. 꼭 한다. 뭐든 꾸준히 올린다. 무조건 한다. 

---

그래도 이건 외우고 자야지

Rest API

REST API 설계 가이드

1. URI는 정보의 자원을 표현
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현

회원정보를 가져오는 URI

X - GET / members / show / 1
O - GET / members / 1
* 회원 정보를 가져오니 GET, 회원 추가 행위 표현은 POST

HTTP METHOD의 알맞은 역할

• POST : POST를 통해 해당 URI를 요청하면 리소스를 생성
• GET : GET를 통해 해당 리소스를 조회. 조회 후 해당 document에 대한 자세한 정보 가져옴
• PUT : PUT를 통해 해당 리소스를 수정
• DELETE : DELETE를 통해 리소스 삭제

URI 설계 시 주의할 점

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는 데 사용
4. 밑줄(_)은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일 확장자는 URI에 포함시키지 않는다.

참고링크 : https://meetup.toast.com/posts/92

 

JWT(JSON Web Token)

JSON 객체를 사용해 정보를 안정성 있게 전달하는 웹표준이다.

jWT는 Json Web Token의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻합니다.

세션/쿠키 방식과 유사하게 사용자는 Access Token(JWT 토큰)을 HTTP 헤더에 실어 서버로 보내게 됩니다.

 

토큰을 만들기 위해 필요한 3가지

• Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어갑니다.
• Payload : 서버에서 보낼 데이터가 들어갑니다. 일반적으로 유저의 고유 ID 값, 유효기간이 들어갑니다.
• Verify Signature : Base64 방식으로 인코딩한 Header, payload 그리고 SECRET KEY를 더한 후 서명된다.

최종 결과 : Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header, Payload는 인코딩 될 뿐 따로 암호화되지 않는다.

결론은 JWT 토큰에서 Header, Payload는 누구나 디코딩하여 확인 가능하다.

*누구나 디코딩 가능 : Payload에는 유저의 중요한 정보가 들어가면 쉽게 노출 가능하다.

그러나 Verify Sifnature는 SECRET KEY를 알지 못하면 복호화 불가능하다.

 

인증방식

1. 사용자가 로그인을 한다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣습니다.
3. JWT 토큰의 유효기간 설정
4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN 발급
5. 사용자는 Access Token을 받아 저장 후, 인증이 필요한 요청마다 토큰을 Header에 보낸다.
6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간 확인
7. 검증이 완료되면 Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.

쿠키 세션 대비 장점

1. 간편하다. 세션/쿠키는 별도의 저장소 관리가 필요하나 JWT는 발급 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다.
2. 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. Facebook/Google 로그인 등은 모두 토큰을 기반으로 인증을 한다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있다.

쿠키 세션 대비 단점

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없습니다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용될 때 해당하는 세션을 지워버리면 해결된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어간다. 해결책은 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있다.
2. Payload 정보가 제한적이다. Payload는 따로 암호화되지 않기에 디코딩하면 누구나 정보 확인이 가능하다. (세션/쿠키 방식은 유저의 정보가 전부 서버의 저장소에 안전히 보관됨) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.
3. 세션/쿠키 방식에 비해 JWT의 길이는 길다. 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생한다.

참고링크 : https://tansfil.tistory.com/58?category=255594

 

SSR(Server-Side Rendering)

전통적인 웹 어플리케이션 방식으로, 브라우저가 서버에 요청을 하고 서버는 제공할 HTML을 생성한다. 브라우저는 HTML을 받아와서 렌더링 하게 된다. 웹서버에 요청할 때마다 Browser 새로고침이 일어나고 서버에 새로운 페이지에 대한 요청을 하는 방식입니다.

 

장점

1. 초기 로딩 속도가 빠르기 때문에(한 번에 다 읽어오지 않음) 사용자가 콘텐츠를 빨리 볼 수 있다.
2. 모든 검색엔진에 대한 SEO(검색엔진 최적화)가 가능하다.

단점

1. 매번 페이지를 요청할 때 새로고침이 되기 때문에 사용자 UX가 다소 떨어진다.
2. 서버에 매번 요청을 하기 때문에 트래픽, 서버 부하가 커진다.

참고링크 : https://clearwater92.tistory.com/30

 

CSR(Client-Side Rendering)

브라우저가 서버에 HTML과 JS파일을 요청한 후 로드되면 사용자의 상호작용에 따라 자바스크립트를 이용하여 동적으로 렌더링 킴

 

장점

1. 첫 로딩에 HTML과 static파일들만 다 받으면, 동적으로 빠르게 렌더링 하기 때문에 사용자 UX가 뛰어나다.
2. 서버에 요청하는 횟수가 적기 때문에 서버 부담이 덜하다.

 

단점

1. 모든 스크립트 파일이 로드될 때까지 기다려야 하기 때문에 초기 로딩 시간이 길다.
2. 검색엔진 최적화 문제가 발생할 수 있다.(검색엔진의 검색 봇이 크롤링을 하는데 어려움을 겪는다)
3. SPA는 초기에 HTML이 비어 있기 때문에 검색 엔진에 적절한 정보를 제공할 수 없다.(구글과 같은 검색 엔진은 크롤링 과정에서 자바스크립트 실행 결과까지 알 수 있다)

참고링크 : https://clearwater92.tistory.com/30