[항해99] 부트캠프 1주차 회고

컴퓨터 sw를 전공했지만 개발과 멀리 떨어져 살았던 나는 다시 개발자가 되어야지 마음먹고 유튜브를 통해 코딩 강의를 듣게 되면서 항해99 라는 부트캠프를 접하게 되었다.
9 to 9 (오전9시~ 오후9시)이라는 몰입을 위한 시스템이 가장 마음에 와 닿았고 긴 고민없이 시작했다.
내가 공부하고 새롭게 배운 내용들을 정리하기 위해 앞으로 꾸준하게 이곳에 기록할 예정이다.

---

미니 프로젝트

처음 배정된 팀원들과 사전 준비기간에 공부한 웹개발에 대한 지식을 바탕으로
진행하는 프로젝트였다. 아이디어는 어떠한 주제도 상관없었고 jinja2 템플릿 을 이용한
SSR(서버사이드 렌더링) 과 JWT 토큰인증 방식을 이용한 로그인 구현, 이 두가지
필수 요소들을 포함해서 AWS EC2 에 업로드하고, 도메인을 붙여 제출하는 방식으로 진행됐다.

우리 조는 서울 서점 api 를 이용해 서울에 있는 독립서점에 대한 정보&리뷰를 공유하는 웹사이트를 만들기로 결정했다.
로그인/회원가입 기능과 시/구 구분을 통해 서점 정보를 불러오는 기능, 각 서점의 정보와 리뷰를 달 수 있는 기능 구현을 목표로 진행했다.

---

와이어프레임

---

결과물

• 프로젝트 시연 영상 : https://www.youtube.com/watch?v=-N7nkyff0g4
• github 주소 : https://github.com/durukim/hangae_project.git

원래 계획했던 서울뿐만 아니라 경기도, 인천 일부 지역, 경상남도 일부 지역까지 데이터를 확장해서 만들었고, 네이버 지도 api 를 이용해 각 서점의 위치 정보도 제공하는 웹사이트를 만들었다.

---

프로젝트 진행 중 우리 팀이 해결했던 문제

• 네이버 지도 api 인증 문제 : 허용 url에 ip 주소를 입력했을 때는 문제 발생했는데, 도메인 입력했을 때는 정상 작동하였다.

• 지역을 검색할 때 1차로 시도단위를 나누고, 2차로 시구군을 선택하게 하였다. 검색을 통해 비슷한 코드를 불러와서 수정하였다. 처음에 1차 단위를 선택하지 않아도 2차에 모든 선택 단위가 보이는 문제가 있었는데 페이지 로딩시 함수에 2차를 출력할 수 없는 임의값을 넣어 해결하였다. if문을 사용해 1차 변수값이 none일 경우 안내문 출력, else는 검색하도록 하였다.

• 책방 리스트 페이지에서 카드를 붙여넣기 하다보니 가시성이 떨어지는 문제가 있었으나 해당 부분을 표로 대체하여 페이지 완성도를 높였다.

• 동일한 상호를 지닌 책방이 존재해 상호를 기준으로 작성한 디테일 페이지를 제대로 불러오지 못하는 오류가 있었다. 상호가 겹치는 경우에는 데이터 베이스에서 상호(ex. 상호+지역명)를 변경하여 수정하였다.

• 코멘트 팝업창과 네이버 지도의 로고가 겹쳐보는 문제가 발생해서 스타일에서 z-index 설정 방법을 통해 지도와 팝업창의 보이기 순서를 변경하였다.

---

아쉬웠던 점 & 피드백

• 팀원 모두 처음이다 보니 어떤 방식이 효율적인 프로젝트 진행 방식인지 알지 못했다.
  프론트 부분과 백 부분 중 프론트 부분을 먼저 진행하고 기능 구현을 하는 방식이 좀 더 효율적인 진행 방식이라 생각이 들었고 다음 프로젝트때는 반영해서 진행할 것이다.

• 개인적으로는 로그인/회원가입 부분과 전체적인 프론트 엔드 부분을 담당했는데 로그아웃 버튼을 눌러서 로그아웃을 해도 리뷰 페이지에 들어가서 글을 작성하면 로그인 상태처럼 나오는 문제가 있었다. 프론트 부분에서만 로그아웃을 처리해줘서 생긴 문제였고 서버에서도 토큰의 만료기간을 수정해줘야 한다는 점을 배웠다. 또 회원가입시 서버에서도 중복 검사를 해줘야 한다는 점도 새로 배운 부분이다.

---

프로젝트를 통해 배운 개념들

프로젝트를 진행하면서 가장 중요하다고 생각하는 개념들을 유튜브나 블로그 검색 등을 통해
공부하고 나름의 정리를 해보았다.

로그인 인증 방식 : JWT (Jason Web Token)

• 구성요소 3가지
  • Header : Header, Payload, Verify Signature를 암호화할 방식(alg),
    타입(type)등을 포함.
  • Payload : 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함.
  • Verify Signature : Base64 방식으로 인코딩한 Header, Payload, Secret Key를
    더한 후 서명. Header, Payload는 암호화 되지 않으므로, 디코딩하여 확인이 가능하다.
• 토큰의 종류
  • Access Token : 수명이 짧은(몇 분 ~ 몇 시간) 토큰
  • Refresh Token : 수명이 긴(보통 2주) 토큰
• 인증 절차
  • 사용자가 로그인
  • 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID값을 부여한 후
    기타 정보에 함께 Payload를 집어 넣는다.
  • JWWT 토큰의 유효 기간을 설정함.
  • 암호화할 Secret Key를 이용해 Access Token을 발급함.
  • 사용자는 Access Token을 받아 저장 후, 인증이 필요한 요청마다 토큰을 헤더에
    실어 보냄.
  • 서버에서는 해당 토큰의 Verify Signature를 Secret Key로 복호화한 후, 조작 여부,
    유효 기간을 확인한다.
  • 검증이 완료되었을 경우, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옴.
• 장점
  • 간편하다.
    • 세션/쿠키 인증은 별도의 저장소 관리가 필요하지만 JWT는 발급한 후 검증만
      하기 때문에 추가 저장소가 필요하지 않음. 서버를 확장,유지,보수하는데 유리하다.
  • 확장성이 뛰어나다.
    • 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능
• 단점
  • 이미 발급된 JWT에 대해서는 유효 기간이 완료될 때 까지는 계속 사용이 가능하다.
    • 세션/쿠키 인증 방식은 쿠키가 악의적으로 이용될 경우 쿠키를 삭제하면 되지만
      JWT는 유효 기간이 지나기 전까지 정보들을 이용할 수 있다. 이에 대한 해결책은
      Access Token, Refresh Token 두가지 토큰을 발급. Access Token을 탈취당해도
      상대적으로 피해를 줄일 수 있다.
  • Payload 정보가 제한적이다.
    • Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수
      있어서 유저들의 중요한 정보들은 Payload에 넣을 수 없다.
  • JWT의 길이
    • JWT의 길이는 길기 때문에 인증이 필요한 요청이 많아질수록 서버의 자원낭비 발생

로그인 인증 방식 : Session / Cookie

• 인증 절차
  • 사용자가 로그인
  • 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후
    세션 저장소에 저장하고, 이와 연결되는 세션 ID를 발행
  • 클라이언트는 서버에서 해당 세션 ID를 받아 쿠키에 저장 후, 인증이 필요한 요청마다
    쿠키를 헤더에 끼워 보낸다.
  • 서버에서는 쿠키를 받아 세션 저장소에서 확인 한 후, 일치하는 정보를 가져온다.
  • 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.
• Session / Cookie
  • Session : 서버에서 가지고 있는 정보
  • 서버에서 발급된 세션을 열기 위한 키 값(세션 ID)
• 장점
  • 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을
    가지고 있지 않음. 중요한 정보는 서버 세션에 존재한다.
  • 고유의 ID 값을 발급 받는다.
    • 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지
      확인할 수 있어 서버의 자원에 접근하기 용이
• 단점
  • 세션 하이재킹 공격이 가능하다.
    • 해결책은 HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 하거나,
      세션에 유효 시간을 부여
  • 서버에서 추가적인 저장공간이 필요하다.
    • 서버에서 세션 저장소를 사용하므로 부하가 높아진다.

템플린 엔진 : CSR (Client Side Rendering)

• 쉽게 말해 클라이언트에서 다 하는것. 서버에서 필요한 데이터를 받아와서 HTML을 생성한다.

• 사용자가 첫 화면을 보기까지 시간이 오래 걸리고 검색엔진 최적화(SEO) 가 좋지 않다.

• Blinking Issue(깜빡임) 가 있고, 사용자가 웹사이트를 볼 수 있음과 동시에 클릭이 가능하다.

템플린 엔진 : SSR (Server Side Rendering)

• 서버에서 HTML 파일을 만들어서 클라이언트에게 보내주기 때문에 CSR을 사용할 때보다 첫 번째
  페이지 로딩이 빨라지는 장점이 있고 모든 컨텐츠가 HTML에 담겨 있기 때문에 더 효율적인
  검색엔진 최적화(SEO) 가 가능하다.

• Blinking Issue(깜빡임) 가 있고 서버에 과부화가 걸리기 쉽다.

• 사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 js를 아직 다운로드 받지 못해서 클릭해도 반응이 없는 경우가 발생한다.(TTV와 TTA 시점이 일치하지 않음)

  • TTV (Time To View)
  • TTA (Time To Interact)

API (Application Programming Interface)

• API 란 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

사실 이 API 라는 개념은 아직 확실하게 이해하지 못한 개념이라 추가적인 공부가 필요하다.

---

프로젝트를 마치면서

4일간의 짧다면 짧은 시간동안 프로젝트를 진행하면서 얻은 가장 큰 성과는 협업에 대한 중요성을 인식했다는 점이라 생각한다. 단순히 주변에서 협업의 중요성을 얘기했을 때는 느끼지 못했던걸
실제로 경험해보고 느끼게 되었다. 적극적인 소통과 협업을 위한 준비된 자세가 프로젝트의 완성도에 지대한 영향을 끼친다는걸 알게 되었다. 이번 프로젝트를 진행하면서 내 스스로의 자세에 대해 돌아보게 되었고 협업을 위한 준비된 자세를 갖추기 위해 앞으로도 계속 노력할 것이다.

---

다음 주차에 공부할 것

한 챕터는 금요일날부터 시작하기 때문에 이미 알고리즘 주차가 시작했다. 아직은 주특기 알고리즘을 찍어 먹어 보는 단계이기 때문에 회고는 다음주에 작성하기로 했다.

• 돌아오는 한 주에서 특히 신경써야 할 공부
  • 주특기 알고리즘 공부 (남들에게 설명할 수 있는 정도)
  • CS(Computer Science) 에 대한 공부
  • API 에 대한 개념(특히 REST API)