[WIL] 크래프톤 정글 0주차 - 정글 입성(미니 프로젝트)

프로젝트 요약

1. 크래프톤 정글 입학 시험 때 공부한 기술들(jQuerry, Flask, MongoDB)을 이용하여 3박4일(실제 시간 : 3박 3일)간 어떻게 돌아가는 웹 서비스를 개발했음

2. SSR(Server Side Rendering) & CSR(Client Side Rendering)과 Jinja2

3. JWT(Json Web Token) 인증 방식의 로그인 구현 (토큰을 발급받아 클라이언트의 쿠키에 저장하여 사용했다.)

4. Bootstrap 외의 CSS 라이브러리 사용(우리 팀은 Bulma를 사용했다.)

 

프로젝트를 통해 공부한 것

SSR과 CSR의 비교 및 Jinja2 템플릿 사용

SSR

서버 사이드 렌더링은 서버에서 HTML에 필요한 정보를 모두 가져와 만들어진 HTML을 동적으로 제어할 수 있는 소스 코드와 함께 클라이언트에 보내는 방식이다.

CSR

클라이언트 사이드 렌더링은 클라이언트에서 HTML을 렌더링하는데 필요한 정보를 서버에 요구하여 가져오는 방식이다.

 

클라이언트 입장에서는 SSR 방식에서는 페이지가 한번에 만들어져 보이는 방식이라면, CSR은 페이지가 렌더링되는 과정을 직접 보는 방식이라고 하면 될 것 같다.

비유적으로 쉽게 생각하면 모바일 네이버 웹툰에서 화면을 한번에 확확 내리면 로딩되지 않은 부분이 보이는데 이걸 CSR 방식이라고 생각하면 될 것 같다(실제 작동 방식은 그렇지 않을 수 있음)

 

웹페이지를 구성하는 데이터가 적으면 CSR이 유리한 경우도 있지만, 웹페이지를 구성하는 데이터가 많은 경우에는 SSR이 유리, 템플릿이 동일한 페이지가 많은 경우에는 SSR이 유리하다.

 

JWT(Json Web Token), 쿠키, 세션 중 JWT를 사용

JWT는 쿠키, 세션과 함께 웹 애플리케이션에서 인증 방식으로 사용되는 방법 중 하나이다.

이 글에서는 JWT에 대해서만 다루고 나중에 기회가 되면 세가지 방식을 제대로 공부하고 비교하며 설명하는 글을 쓸 예정이다.

 

JWT 방식의 인증 방식은 쿠키의 장점과 세션의 장점을 합친 듯한 느낌을 받았다.

쿠키의 경우에는 클라이언트 쪽에서 저장을 하여 인증을 할 때 마다 서버로 보내와 서버가 확인을 하여 인증을 해주는 방식이지만, 쿠키를 조작하기가 쉬워 보안에서 취약점이 있고,

세션의 경우에는 클라이언트 별로 고유한 세션 ID를 부여하여 서버에서 관리하여 쿠키보다 안전하지만, 세션 ID를 서버에 저장하고 관리하기 때문에 서버에 부하가 올 수 있다는 단점이 있었다.

 

JWT 방식은 간단하게 말하면 사용자의 정보를 토큰에 포함시켜 암호화 한 뒤, 토큰을 클라이언트 쪽에서 저장하게 시켜 서버에 부하를 줄이고, 사용자가 토큰을 조작하려 해봐도 암호화 된 뒤이므로 조작하기 힘들어 보안 쪽 강화도 한 방식이다.

 

JWT

JWT의 구조는 세가지로 이루어진다. Header, Payload, Signature가 그 세가지이다.

JWT의 구조(출처 : https://velopert.com/2389)

-헤더(header)

header는 토큰의 타입, 해쉬 알고리즘(HS256, RSA 등)으로 구성되어있다.

 

여기서 말하는 해쉬 알고리즘이 위에서 암호화시키는 알고리즘이라고 보면 된다.

 

-내용(payload)

payload에는 claim이 담겨있다.

 

claim이란 key-value 형식으로 이루어진 한 쌍의 정보로, 엔티티(주로 사용자)에 대한 속성을 설명한다.

(claim에도 registered, public, private과 같이 여러 종류가 있긴 하지만 여기서 추가적으로 더 설명하지는 않겠다.)

따라서 payload에는 클라리언트 고유 ID 값, 유효 기간 등, 유저의 정보가 담겨있다고 봐도 무방하다.

 

-서명(signature)

signature은 header와 payload를 인코딩한 뒤, header에 명시된 해시함수를 적용하여 암호화하고, 개인키로 서명한 전자서명이 담겨있다.

 

여기서 거창하게 개인키로 서명한 전자서명이라 하지만 실제 프로젝트에서는 소스 코드 내에 secret key를 따로 선언해둬서 그 것을 signature로 사용하였다.

 

header와 payload는 단순히 인코딩된 값이어서 누구든지 복호화가 가능하지만, signature의 경우에는 서버에서 관리하는 이 secret key가 있어야만 복호화가 가능하다.

 

따라서 이 signature 부분으로 토큰의 위변조 여부를 확인할 수 있어 토큰을 클라이언트 단에서 저장하고 관리하지만 보안

적인 측면에서는 안전하다고 볼 수 있다.

프로젝트 중 어려웠던 것들

1. 불필요한 데이터 검색

나는 이 프로젝트에서 백엔드 개발을 맡았다. 그러다 보니 어떤 데이터를 저장해야되고 사용해야하는지에 대해 깊이 고민을 했었다. 또, 상품, 사용자, 참여자의 정보만 저장하고 보여주는 것이 아닌, 구매 내역 데이터도 보여줘야 했기에 고민을 더 많이 했던 것 같다.

팀원들과 고민했던 내용이 적힌 칠판

 

구매 내역 정보의 경우, 원래 계획했던 상품, 사용자, 참여자 정보가 모두 필요한 경우가 발생하여 불필요하게 db에 접근을 많이 하게 될 것 같았다. 따라서 불필요하게 여러 data collection에서 필요한 것들을 끌어오는 것이 아닌, 구매 내역 데이터를 따로 저장하여 데이터를 이분화하는 것이 낫겠다고 판단했다.

 

그렇게 되면 마이페이지에 들어갔을 때, 사용자 본인의 id를 통해 내역 data collection에 접근하여 해당 id가 일치하는 것만 골라오면 되므로 접근해야하는 collection의 개수를 3개에서 1개로 줄일 수 있고, 횟수도 줄일 수 있어 더 효율적일 것이라 판단했다.

2. Datatype 맞추기

상품의 데이터를 저장할 때, 해당 상품 데이터 만의 고유 값을 만들어 사용해야 데이터 검색 시 중복되는 값이 나오지 않아 에러를 막을 수 있을 것이라고 생각했다.

 

sql을 사용하는 RDB의 경우 schema를 설계할 때 primary key로 두고 auto_increment 속성을 두어 해결할 수 있었겠지만, 프로젝트에서는 입학 시험 때 공부한 noSql 기반의 mongoDB를 써야했기에 어떡하면 고유값을 만들 수 있을까 생각했다.

생각하고 찾아본 결과, mongoDB의 경우 데이터를 넣기만 하면 중복되지 않는 ObjectId 타입의 _id 값을 알아서 생성하여 같이 넣어주는 기능이 있었고 이 값을 이용하면 될 것이라 생각했다.(실제로는 아주 x 9999999999 작은 확률로 겹칠 수는 있지만 사실 상 겹치지 않을 것이라 판단하고 사용했다. 참고 : https://kim-jong-hyun.tistory.com/95)

 

하지만 이 값의 타입이 ObjectId라는 mongoDB에서만 지원하는 특이한 타입이었고, 이 값을 이용하려면 계속해서 데이터 타입을 변환시켜주며 사용해야했다.

 

실제로 ObjectID 타입은 jsonify가 되지 않아 int형이든 str형이든 jsonify가 되는 타입으로 바꿔주고 프론트로 return해주어야했고, 프론트에서 데이터를 요구할 때에는 받아온 데이터를 다시 ObjectId로 데이터 타입 변환을 시켜준 다음 검색을 해야 DB에서 정상적으로 검색이 되었다.

 

이 데이터 타입이 계속해서 오류를 유도했고, 다음 프로젝트를 할 때에는 나와 팀원들의 정신 건강과 편리함을 위해 좀 더 새로운 방법을 찾아서 사용해야겠다고 생각했다.

 

사실 일의 효율성만 따지면 자동 생성되는 값을 사용하는게 효율적이긴 하지만, 효율성만 따져서는 제대로 작동하는 서비스를 개발하지 못할 것이라고 생각하기에 위와 같이 생각했다.

마무리

처음 공부하는 개념들, 공부했었지만 다 까먹은 기술들을 가지고 처음 진행하는 웹 프로젝트였지만, 팀원들이 힘을 잘 합치고 진행하다보니 처음 기획한대로 전부 구현에 성공하였다.

 

혹시라도 프로젝트가 궁금하면 github링크를 클릭하여 확인해볼 수 있다.

 

github 049(공구할 사람 구함) : https://github.com/Jungle-5/Jungle0_5