1. 어려웠던 부분 : 

• 오늘 팀원A분이 CI/CD하는 것을 화면공유로 볼 수 있었다. 지난주부터 계속 해결되지 않던 오류들이 있어서 아직 성공하지 못했는데, 오늘 팀원B분이 성공하셨다. 사실 나도 직접해봐야 더 도울 수 있고, 이해도 될텐데 의욕이 없다. 

2. 느낀 점 : 

• 벌써 항해를 시작한지 3달정도 되었다. 첫 시작부터 카운트 하자면 3달 반이 지났다. 그리고 이제 3주가량 남았다. 그동안 열심히 해왔다고 생각했지만, 아직 턱없이 부족하다. 처음 항해99를 시작했을 땐, 취업률 90프로 이상, 그리고 기술매니저님들도 수료만 하면 일단 취업은 된다고 하시길래 그동안 힘들고 포기하고 싶던 적이 많았지만 배수진을 쳤다 생각하고 꾹 참고 버텨왔다. 
• 그런데, 이제 곧 수료가 다가오고 채용사이트를 보면서 객관적으로 나의 실력에 대해 생각해보니 이대로는 어디도 갈 수 없을 것 같다. 항해99가 끝나면 물론 지원은 해보겠지만, 꽁꽁 얼어버린 채용시장에서 과연 지금의 내가 경쟁력이 있을까. 그렇다면 더 공부를 해야할까? 더 공부를 한다고 꽁꽁얼어버린 개발자 취업시장에서 취업할 수 있을까? 등 생각이 많아지는 요즘이다. 
• 그리고 3개월 전에 수료를 마친 8기 분들의 취업률이 58%라고 들었다. 이런 경제상황 속에 나쁘지 않은 취업률이라는 생각이 들다가도, 어 그럼 세달이나 지났는데 40프로는 아직도 취준이겠구나. 이게 나의 미래인가 하는 생각도 들었다. 착잡하다.

3. 새로 알게 된 내용 :

• 오늘 백엔드 팀원들이랑 지난주에 고려했던 동시성제어 테스트를 했다. 근데 생각보다 짜여지 로직이 괜찮은지 조금씩 고치다보니 우려했던 동시성 제어문제는 발생하지 않았다.
• 게임방 입장과 퇴장만 리더분이 동시성제어로 비관적락을 걸어 주셨고, 그 외의 로직엔 동시성제어와 관련된 코드가 필요하지 않았다.(아직까지는)
• 그리고 오늘 그동안 테스트하느라 여기저기 중구난방으로 붙여놨던 로그도 지우고 불필요한 주석이나 코드를 정리하는 리팩토링 작업을 했다. 게임로직도 게임과 게임레어 두 가지 서비스로 나눠있었는데, Repository Service 클래스를 만들어 그와 관련된 로직을 다 분리하니 코드가 생각보다 길지 않아 하나로 통합했다. 

4. 셀프칭찬 (오늘 잘한 일) : 

• 오늘은 아침 점심 저녁 산책을 3번 나갔다. 생각이 많을 땐 걷는게 최고다.
• 최고로 의욕이 없고 집중이 잘 되지 않는 날, 자신감이 최저인 오늘, 그래도 조금이라도 잘 보내고 싶어서 개발자 취업 관련된 영상도 많이 보고 미뤄왔던 혼공자 마지막 챕터를 공부했다. 

5. 내일 할 일 : 코드리뷰 + 리팩토링

[오늘 공부한 부분] 

• 코드 리팩토링 - 관심사 분리 + 게임 로직 합치기
• 게임방을 게임중에 그냥 창 자체를 닫아버렸을 경우 혹은 그냥 닫아버릴 경우 에러없이 DB에서도 잘 삭제되도록 하는 로직 추가
• 자바 보조스트림 공부
• 팀원들이 진행하는 CI/CD 관찰

[33] JAVA 보조 스트림

[34] JAVA 입출력 API

1. 어려웠던 부분 :

• 지난주 멘토님의 피드백을 반영해서 CI/CD, 웹소켓 세션 객체 Redis 저장을 시도했지만, 아쉽게도 둘다 해결하지 못했다.
• https 서버 배포후 알 수 없는 에러를 프론트엔드 서버를 EC2로 다시 배포함으로써 임시방편으로 해결했지만 그 전 에러의 원인을 여전히 알 수 없다.
• 이번주 중간 발표를 위해 모든 팀원이 MVP구현을 위해 노력했다. 특히 정신없이 뷰작업을 해주신 프론트엔드분들 진짜 고생 많으셨다.
• 아직 동시성제어, 그리고 무중단배포, 리프레시토큰 적용 등 해결해야 할 과제들이 남아있다. 

2. 느낀 점 : 

• 다시한번 모두가 열심히 하는 팀을 만난 것에 감사함을 느낀다.
• 지칠법도 한데, 열심히 새로운 기술을 공부하고 해결하고 솔선수범하는 팀원들을 보며 반성하고 많이 배웠다.
• 사실 처음엔 이게 될까?라는 생각이 있었는데, 되는걸 보니 신기하고 뿌듯하다.
• 우리팀에서 나만 잘하면 된다.

3. 새로 알게 된 내용 :

• 서버가 다운될 수도 있다. 그럴땐 AWS 접속해서 차분하게 다시 재부팅 하자.
• 동시성제어 - 비관적락만이 정답이 아닐 수 있다. MVCC에 대해 알아보자
• 발표와 면접에 가장 중요한부분은 기술스택 선정 이유와 이해도 이다. 열심히 공부하고 파고들어 보자.

4. 셀프칭찬 : 

• 사실 의욕이 많이 떨어진 주차였다. 개인적인 일도 있고, 그렇지만 그럼에도 불구하고 최대한 티 안내고 집중하려고 노력했다. 
• 자꾸 남들과 비교하면 밑도 끝도 없이 자존감이 떨어진다. 객관적으로 나를 보려고 노력했다. 아직 코딩을 시작한지 3개월 차인 코린이일 뿐이다. 충분히 잘 하고 있다. 

5. 다음주 할 일 : 

• 게임스타트셋 DB MySQL로 변경 (1순위)
• 동시적으로 게임 시작했을 때 발생하는 오류 원인 파악 (1순위)
• 원인 파악 후 로직 수정 (1순위)
• CI/CD 엔진엑스 사용해서 마무리 (2순위)
• Refresh Token 작업 (2순위)
• JWT 예외 처리 수정 (2순위)
• 레파지토리 서비스 관심사 분리 (3순위)
• 테스트 코드 진행 (3순위)

[ 이번주 공부한 부분]

[11] Docker (1) 

[12] 게임 로직 - 랜덤으로 카테고리 / 키워드 뿌려주기

[13] 트러블 슈팅 : HTTPS 배포 유의사항

[52] Spring boot Logging(@Slf4j)

[15] Spring CI/CD

[16] Docker 실행 / 명령어 정리

+ 노션에 정리한 부분

https://www.notion.so/cd4bad2d032343c8bafcb640b597f6bc

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c

1. 어려웠던 부분 : 오늘 아침에 멘토님의 예상 질문을 받고 팀원들과 답변을 준비했다. 어떤 문제는 질문 자체도 잘 이해가 되지 않았다. 그리고 예상치 못한 부분도 있었다. 우리가 너무 생각없이 Redis를 서브 디비로 사용한건가 라는 생각에 뒷통수를 맞은 느낌이었다. 아래는 질문과 우리가 준비한 답변이다. 

- 여러 기수의 프로젝트에 의아한 부분이었는데, Redis 는 메모리 기반의 DB 이지만 휘발성을 가진것은 아니다. 그러면 DB 가 아니라 Cache 정도로 명명하지 않았을까?

• Redis를 단순히 캐시로 사용하는 것 뿐만 아니라 RDB(SnapShot), AOF 와 같은 방식으로 일정 주기와 명령어를 통해 데이터를 보존할 수 있다는 것을 알고 있다. 그런데 우리 서비스에서는 게임을 하고 있을 때에만 필요한 데이터를 Redis에 저장해서 사용하고 있다. 게임이 끝나면 바로 삭제하는 일시적 데이터라 영속화할 필요가 없어 휘발성이라는 단어에 초점을 맞춰 선택했다고 설명했으나, 생각해보면 우리의 일시적인 데이터도 휘발성에 의존하고 있지 않다. 시간을 정해주고 데이터를 날리는 것이 아니고, 서버가 주기적으로 다운되는 것도 아니며 우리의 로직으로 데이터를 삭제하고 있기 때문이다.
• 이 부분에 있어서는 우리 로직에 Redis 선택의 이유로 휘발성을 넣은 것은 잘못된 부분이라고 생각한다. 빠르고 접근하기 용이하며 비용 절감이 가능하기에 Redis를 선택했다 라고 설명하는 것이 맞는 것 같다.

- 개발자 입장에서 동시성에 성능문제를 풀려하지말고, 로직으로 고민하는 지혜가 필요하다. 심지어 Mesh 를 사용중이라면 충분히 MySQL 로도 처리 가능하다고 생각하는데, Redis 를 사용하지 않는 어떤 방식으로 풀지?

• 무슨 소리인지 못 알아들었다.
• 현재 WebRTC를 P2P 방식으로 사용하기 때문에 서버 부하가 적을 것으로 예상되어 게임 로직에 필요한 데이터를 굳이 Redis를 사용하지 않고 MySQL에 저장해서 사용하는게 낫다는 말씀이실지

- 비관적락/낙관적락 둘 모두 트랜잭션 외의 트랜잭션의 작업을 블록하거나 무시하는것인데, 실시간성이 중요한 로직에서 적합한지 의문, 차라리 MVCC 솔루션이 좋지 않을지. 비관적락의 특성과 그걸 사용하려는 이유에 대해 서술

• 동시성을 제어하는 대표적인 방법이 낙관적 혹은 비관적 락으로 알고 있어서 해당 방법을 사용하려고 했다.
• 비관적락의 특성은 미리 충돌이 발생할 것을 예상하고 미리 락을 거는 것인데 충돌이 없으면 오버헤드가 발생한다는 단점이 있다고 알고있다.
• 실시간성이 중요한 게임이지만 실제 서비스에서 비관적 락을 걸었을 때 딜레이가 얼마나 발생하는지 레퍼런스가 없었기 때문에 우선적으로 시도하고자 했다.

- 무중단 배포 지원에 대해서 구체적으로 어떤 전략을 가지고 있는지

• 무중단 배포를 이제 막 시작하려는 단계여서 디테일한 전략이 정해지진 않았지만, Nginx를 활용해서 하나의 서버로 Blue-Green 형식의 무중단 배포를 생각하고 있습니다.
• EC2 프리티어 1대로 구성한 다음 Port를 2개로 나눠 블루-그린 배포 방식으로 진행할 것이다. 비용 측면에서 이 방식이 효율적이라고 생각했다. 새로운 버전 또한 기존 EC2 인스턴스에 그대로 적용하면 되므로 배포를 위해 AWS EC2 인스턴스가 추가로 더 필요하지 않다. 구조는 EC2 혹은 리눅스 서버에 Nginx 1대와 스프링 배포 파일 Jar 2대를 사용하면 되므로 간단하다.
  • Nginx에는 80(http), 443(https) 포트를 할당한다.
  • 스프링 1에는 8081 포트를 할당한다.
  • 스프링 2에는 8082 포트를 할당한다.

- validateToken 의 경우 info 가 아닌 공통으로 정의한 StatusCode 로 CustomException 발생시킨 후 Advise 에서 캐치해도 좋을듯한데, 이에 대한 의견

• 멘토님 말씀이 맞다. 지금 그 부분만 공통 처리 부분에서 제외가 되어 있는데, 이 부분에 대해서 미처 생각하지 못했다. 추후에 수정하도록 하겠습니다.

2. 느낀 점 : 중간 회고 발표를 통해 우리에게 어떤 부분이 보안되어야 하는지 알 수 있었다. 발표는 리더분이 해주셨는데, 나도 혼자서라도 남들에게 발표하고 설명하는 연습, 말하는 연습을 해야겠다고 느꼈다. 설명을 잘 할 수록 면접을 볼 때에도 도움이 많이 될 것 같다. 말을 차분히 잘 하는 사람들을 보면 참 멋있고 부럽다 ! 

3. 새로 알게 된 내용 : 발표를 통해 우리가 왜 이 기술스택을 선택했는지에 대한 부분이 많이 부족하다는 것을 알게되었다. 그리고 Redis를 사용한다고 비용적으로 MySQL에 비해 그렇게 저렴한것도 아니라는 사실도 알게되었다. 중간 회고 발표가 끝난 후 팀원들과의 회의를 통해 오늘 기술스택 선정 이유를 다시한번 정리해 보았다. 그리고 다음주에 Redis에 저장하고 있는 GameSet부분을 MySQL로 돌려보고 동시성제어를 잡아보기로 했다. 

4. 셀프칭찬 (오늘 잘한 일) : 오늘은 명절 전이고 다들 지쳐있어서 일찍들 퇴근을 했다. 퇴근하기 전에 다른 팀원분들에게 부탁해서 같이 만든 게임을 해보았다. 생각보다 다들 재밌어해주셔서 뿌듯했다 : ) 

5. 내일 할 일 : 이번주 WIL 정리하기

[오늘 공부한 부분] 

• 중간 발표 사전 질문 답변 준비하기
• 중간 발표 후 기술스택 선정이유 정리
• https://www.notion.so/cd4bad2d032343c8bafcb640b597f6bc

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c

1. 어려웠던 부분 : 오늘은 내일 발표를 위해 여러가지 테스트를 해보았다. 우리가 아직 생각하지 않았던 부분이 동시성제어 문제였는데, 분명히 터질거라고 예상은 하고 있었다. 먼저 아래와 같은 실험을 해봤다.

1. 한 방에 4명이 맥시멈이다. 일단 3명을 입장시켜 놓고 나머지 1자리를 두고 3명이 동시에 입장해보기. 

 - 이 실험은 다행히 문제없이 통과되었다.

2. 방을 3-4개 만들어 놓고 동시에 시작해보기

- 오! 터졌다 ^^! 어떤 방은 시작이되고 어떤 방은 제대로 시작이 되지 않는다. 웹소켓에  게임의 기본설정 정보를 gameStartSet이라는 Repository에 저장하고 있는데 그부분에서 터지는 것 같다! 

일단 여러 자료를 통해 동시성제어엔 비관적락과 낙관적락이 있다는 것은 알았고, 우린 이 정보를 Redis에 저장하고 있기 때문에 Redis에서 동시성제어 하는 법을 열심히 구글링해 보았다.

구글링을 통해 첫번째로 아래의 방법을 시도했다.

1. @EnableTransactionManagement 을 붙이고 Redisconfig 파일에 아래 코드 추가하기 -> 실패 ! 여전히 오류 발생

    @Bean
    public PlatformTransactionManager transactionManager() {
        return new JpaTransactionManager();
    }

위 방법 참고자료 : https://wildeveloperetrain.tistory.com/137

2. SessionCallBack 사용 - 이부분 코드는 팀원분한테 있어서 나중에 업로드 할 예정

결과적으로 위 콘솔에 뜬 에러는 사라지긴 했지만, 여전히 게임 동시시작에 문제가 있고, 몇 번의 테스트 후 서버가 먹통이 되고 다운되어 버렸다. 

어떻게 수정해야할지 아직 잡히지 않아서 더 공부하고 적용해 봐야할 것 같다.

2. 느낀 점 : 거의다 끝났다고 생각했지만, 역시나 끝은 없다. 너무 어렵다 ㅎㅎㅎ 하하핳 !! 

3. 새로 알게 된 내용 : 지난번에 팀원분이 CI/CD 테스트를 여러번 하셨던 적이 있는데 그때도 서버가 다운되어 버리는 문제가 있었다. 이번에도 여러번 테스트를하니 서버가 그냥 먹통이 되어버렸다. 이럴때 해결 방법 ! 일단 AWS에 가서 먹통이 되어버린 인스턴스를 중지시킨다. 그리고 다시 새로운 인스턴스를 생성하고 생성중이 뜨면 다시 중지시키고 원래 먹통이라 중지시켰던 인스턴스를 다시 재부팅한다. 신기하게도 먹힘... ! 원래 협업에선 이렇게 안할텐데 제대로된 방법을 모르겠다  ㅎ... 

4. 셀프칭찬 (오늘 잘한 일) : 팀원들과 같이 동시성제어에 관련된 비관적락 낙관적락 트랜잭션 등에 관한 공부를했다. 어제부터 집안일 때문에 중간 중간 집중이 되지 않았지만, 최대한 팀원들한테 티 안내고 피해주지 않으려고 정말 많이 노력했다 ! 프로젝트가 끝나면 바로 고모가 좋아하셨던 꽃을 사서 인사드리러 가야지! 이효리가 한 말중에 그런 말이 있다. 다른사람은 몰라도 나 자신은 내가 노력한 걸 알아주면 된다고. 잘 하고 있어! 끝까지 잘 하자 ! 

5. 내일 할 일 : 중간 회고 발표 / 피드백 정리하기

[오늘 공부한 부분] 

• 동시성 제어 - 비관적 락 / 낙관적 락 ( 우테코 짱 )
• https://www.youtube.com/watch?v=w6sFR3ZM64c
  https://www.youtube.com/watch?v=ZXV6ZqMyJLg
  https://www.youtube.com/watch?v=onBpJRDSZGA

1. 어려웠던 부분 : 오늘까지 이번주 토요일에 있을 중간 회고 발표 자료를 제출해야 했다. 프론트엔드분들은 바쁘기 때문에 일단 백엔드에서 깃허브 리드미 작성과 발표자료 준비를 했다. 기술스택 선정 이유가 중요한데 이유를 설명하기가 생각보다 쉽지 않았다. 이부분이 중요할텐데.. 허허 ... ! 그리고 해결된 줄 알았던 https 배포에 또 문제가 생겼다. 현재 프론트엔드는 AWS cloudfront 를 이용해 배포가 되었고 백엔드는 AWS EC2를 사용해 배포를 한 상태인데, 계속 이부분에서 오류가 생긴다. 결국 팀의 리더분이 백엔드임에도 불구하고 혼자 뚝딱뚝딱 프론트엔드 서버를 EC2로 재배포 하셨다. 당장의 문제는 해결되긴 했는데, 정확한 이유를 알지 못해서 찝찝하다.

2. 느낀 점 : 우리팀 백엔드분들을 보시면 참 잘하신다. 문제가 발생하면 구글링해서 뚝딱 하고 고쳐내고, 코드도 뚝딱 하고 만들어내고. 그리고 심지어 매번 테스트 할때마다 프론트엔드한테 부탁하기가 미안하다고 VSCode 까지 다운받아서 직접 로컬서버를 띄우고 작업을 하시기에 이르렀다. 진짜 멋지고 대단하다. 근데 나를 돌아보면, 난 아직도 로직을 구현하는데 시간도 걸리고 어떤 개념을 보았을 때 이해하는데도 상당한 시간이 걸린다. 나름대로 나도 열심히 해오고 있다고 생각했는데, 이 부트캠프 안에서 이렇게 실력차이를 느낄때마다 좀 막막한 마음은 어쩔 수 없다. 언제쯤 나도 빠릿빠릿한 이해력을 가질 수 있을까. 

3. 새로 알게 된 내용 : 오늘 발표 전 테스트를 하면서 위 사진과 같은 오류를 발견했다. 원래 맥시멈 4명만 입장이 가능한데, 만약 직접 url주소를 치고 들어오면 저렇게 입장이 되어버린다. 로직이 잘못되었나 라는 생각에 백엔드 코드를 수정해야하나 싶었는데 놀랍게도 프론트엔드에서 저 부분을 막아줄 수 있다고 하셨다. 이번 프로젝트를 하면서 프론트엔드가 참 하는일이 많다는 것을 몸소 느끼고 있다. 클라이어트단에서 막아주는 부분이 정말 많고 그밖에 뷰작업, 세심한 디테일 작업까지. 누가 프론트엔드가 쉽다고 했던가. 

4. 셀프칭찬 (오늘 잘한 일) : 사실 오늘 집에 일이 생겨서 집중이 잘 안되는 하루였다. 프로젝트 끝날때까지 멘탈을 잘 잡고 싶어서 집중은 안되지만 인강을 틀어놓고 최대한 집중하려고 했다. 홧탱 ! 

5. 내일 할 일 : 발표 전 마지막 준비 + 사소한 에러 잡기 ! 

[오늘 공부한 부분] 

[16] Docker 실행 / 명령어 정리