[산성비] 첫 프로젝트의 시작과 끝

 

 

산성비

2020. 06. 29 - 07. 10

 

 

concept

타이핑 게임 + 코드

코딩을 시작한 우리에게는 타이핑마저 어렵다!

컨셉 이미지

 

 

아이디어를 내고 팀원들과 함께 만드는 팀 프로젝트를 처음 진행하게 되었어요. 

풀스택 포지션으로서 Express와 Sequelize를 다루며 서버를 구현하였고,  로그인 화면을 구성하여 유저의 권한 설정에 대한 서버 요청까지 맡게 되었죠. 또한 팀장으로서 작업이 어떻게 진행되는지 머릿속에 그림을 그리며 단계적으로 해야 할 일을 미리 생각해야 했어요. 부담감이 상당했지만 적극적인 팀원들 덕분에 끝까지 해낼 수 있었어요.

 

 

스테이지 수정 권한

기존의 산성비 게임은 단순히 내려오는 텍스트를 빠르고 정확하게 타이핑하는 데에 그쳤지만 이번 프로젝트의 서비스에는 유저가 자신만의 스테이지를 생성, 수정, 제거할 수 있도록 만들었어요. CRUD를 생각하다가 떠올랐죠. 유저가 게임 중에 내려올 코드를 작성하여 저장하면 스테이지를 시작했을 때 작성한 코드가 랜덤으로 내려오게 됩니다. 유저가 작성한 스테이지를 생성, 읽기, 수정, 삭제하는 과정에서 유저의 데이터를 가져와서 비교하고 권한을 주었습니다. 권한을 부여하는 것이 당연하지만 보지 못하고 지나칠 뻔했어요.

 

스테이지를 플레이하거나 새로 만들 수 있는 페이지

 

 

로그인 유지 기능

로그인 유지 기능은 프로젝트를 시작하기 전에 진행했던 과제에서 구현하지 못한 경험이 있었습니다. 그래서 더욱 신경 쓰며 구현하게 되었는데요. 생각보다 해결책은 간단하였습니다. 

app.use(
  session({
    resave: false,
    saveUninitialized: false
  })
);

이전 과제에서는 saveUninitialized라는 옵션이  true  이었기 때문에 세션 아이디가 계속 바뀌어서 아무리 세션에 데이터를 저장하여도 참조할 수 없었습니다. saveUninitailized가 false일 경우에는 세션을 수정할 경우에만 세션 아이디가 발급되어 요청을 보낼 때 클라이언트의 세션 아이디로 서버에서 세션 데이터를 참조할 수 있었습니다. 

 

그런데 한가지 아쉬운 선택을 하게 되었습니다. 세션 아이디를 header로 주고받지 않고 body에 넣어서 GET방식이 아닌 POST방식의 통신을 하도록 어리숙한 코드를 작성한 거죠. 또한 로그인이 되었다는 정보를 서버에서만 가지고 있어서 새로고침을 할 때마다 로그인 페이지에서 로그인 여부를 확인하고 원래의 페이지로 넘어가도록 코드를 작성했습니다. 이 때문에 새로고침을 할 때마다 유저는 로그인 화면에서 통신이 완료되는 시간 동안 잠시 기다려야 했죠. 시간 관계상 로그인과 유지에 매달릴 수 없어서 이 정도로 마무리해야만 했습니다. 만약에 로그인 유지를 다시 구현한다면 클라이언트 쿠키나 로컬 스토리지에 로그인 여부를 저장하고 중요한 순간에만 서버에 요청하여 여부를 다시 확인하는 방법을 사용할 것입니다. 

 

세션/쿠키의 문제

정보를 서버에 세션으로 저장하고 클라이언트의 쿠키를 사용하는 방법은 여러 가지 문제를 가지고 있다고 합니다.

1. 모든 요청시 해당 서버에서 조회해야 하기 때문에 부하를 야기할 수 있다. 

2. 만약에 서버를 확장한다면 각 서버마다 세션정보를 저장해야 한다. 

3. 기존의 클라이언트는 웹 브라우저가 유일했으나 이제는 모바일로 접근하는 경우도 처리해야 한다.  

 

이런 문제들을 해결하기 위한 최선의 방법이 토큰을 사용하는 방법이라는데 토큰에도 단점이 있다고 합니다. 보안 문제이죠. 암호화되지 않고 인코딩 된 데이터이기 때문에 디코딩을 한다면 데이터를 볼 수 있어요. 그리고 데이터가 많아질수록 토큰의 길이가 늘어나서 네트워크 통신에 부하를 줄 수 있어요. 

 

기술의 장단점을 파악하여 적절하게 사용할 수 있는 방법을 찾고, 이번 프로젝트에서 작성한 코드를 발전시켜서 다음 프로젝트에 활용해야 겠습니다.