자율 프로젝트 end




시작 당시 사용하려 했던 기술을 사용해서 웹게임을 구현했고, 3일간 싱글게임 약 400회 멀티게임 약 250회가 플레이 되었다. 애시당초 구현하려던 충돌 멀티엔진은 실패 했지만 문서화나 사람들의 플레이 후기가 썩 괜찮았던 만족스러운 프로젝트 시작 때 사용하려 했던 기술들에 대해 다시 한번 짚으려고 한다. 

webSocket 과 STOMP 

컨트롤러에서 어노테이션으로 간단하게 연결가능 했으며 sub한 유저들에게 pub 해준다 라는 다소 난해한 설명과 달리 http 요청과 흡사하게 사용할 수 있었던 것 같다. 해당 기능으로 다른 유저의 방 접속 여부, ready 여부, 움직임 등을 공유해서 멀티 플레잉을 구현했으며 채팅과 달리 키입력을 모두 주고 받았음에도 동시에 5명 정도는 매우 매끄럽게 통신이 가능했다.

물론 규모가 커지면 내부 simplebroker를 외부 브로커로 적용 시키고, 서버를 따로 두는 등의 노력을 해야한다. 

+ 소켓이 연결 및 해제될 때 중간 중간 잡아주는 ChannelInterceptor 가 있는데, 해당 부분에서 메세징 보내는걸 몇번이나 실패했다. 

gradle 

시작할 때 건들고 이후 몇번 implementation 을 추가한 것 이외에는 별로 접해보지 않았다. 빌드 속도나 편리성에서 사실 maven 보다 월등한 점은 모르겠다. 다만 eclipse 기준으로 import 해오는 방식이 굉장히 복잡하고 문제가 발생할 여지가 많은 것 같은 기분, 이름이 겹치기만 해도 프로젝트를 자바프로젝트로 인식 하지 못하는 문제가 존재한다. 이번에 이를 겪으며 트러블 슈팅한 경험은 다행.

이클립스에서 import할 때 여기 이름이 일치하는지도 살펴보자

Redis

Redis repository 로 JPA 와 비슷하게 사용하였다. 
save()를 이용하여 저장할 경우 데이터가 hash로 저장되며 이때의 key는 "Object:id" 의 형태가 된다. 우리의 경우 Access 라는 객체에 sessionId를 @id로 저장했기 때문에 "access:qt4qpjc5" 이런 형태의 데이터가 존재하게 되었다. 


jwt + spring security

jwt를 사용하여 API를 사용하기 전 보안 처리를 하려면 결국 security config를 활용하는 것이 가장 쉬운 것 같다. 저번 특화 프로젝트에서 이를 사용하여 OAuth 로그인을 구현했을 때와 결국 같은 의미를 가진다. 
이 때 swagger에서 api 테스트를 해보려면 header에 jwt를 실어 보내주어야 하는데 swagger 설정을 사용해서 추가 가능하다. 

로그인 후 받은 jwt를 입력하면 자물쇠가 닫히며 로그인 후 사용할 수 있는 api 테스트가 가능해진다.

Jasypt

프로젝트 막바지 보안을 위한 검색 도중 발견하였는데 application.property/yml 에 고정적으로 들어가게 되는 정보 (url, id, password ...)을 암호화 하여 사용할 수 있다. 물론 이를 위한 key나 코드가 노출 될 수 있기에 public한 repository에 저장되는 프로젝트라면 이를 사용한 데이터까지 모두 빼야 하지만 private한 경우 원문이 그대로 노출되지 않기에 조금 더 보안에 신경 쓰는 것 아닐까




ssafy에서 프로젝트를 위해 배포해준 서버는 앞으로 일주일 남짓 후면 내려간다. 해서 현재는 우리 조가 따로 aws 서버를 이용해 따로 배포 진행 중에 있다. 게더타운을 통해 협업을 진행했고 막바지 홍보까지 하면서 이벤트를 진행했다. 치킨과 커피를 걸자 꽤나 플레이가 모였고, 비록 결선 진출은 실패했지만 배운게 많은 프로젝트가 되었다.

댓글

이 블로그의 인기 게시물

git-receive-pack not permitted on 깃 허브 로그인 관련 문제