1. 어려웠던 부분 : 오늘은 지금까지 계속 속을 썩이고 있는 CI/CD 에서 CD부분 오류를 해결하려고 시도했다. 성공한 듯 했으나 숨겨져야할 appication.properties 파일이 깃헙에 올라가버린 참사가 발생해서 그렇다면 이 파일을 암호화해보기로 했다. GPG암호화 라고 검색하면 파일을 암호화 하는 법이 나온다. 내가 하진 않았지만 팀원분이 하시는 걸 보니, 암호화를 하면 .tar 라는 파일이 생성되고 깃헙에 올렸을 때 자물쇠가 채워진 채로 올라간다. 신기하다  ! 그래서 CD의 결론은 결국 성공한 줄 알았으나 하지 못했다는 점... 그리고 웹소켓 세션도 지난주 멘토링때 레디스에 저장하시면 된다고 하셔서 다른 팀원분이 계속해서 여러가지 방법으로 시도를 하셔지만 결론은 성공하지 못했다. 우리가 내린 결론 = 세션을 객체 자체론 레디스에 저장할 수 없다는 것 ! 세션 아이디만 String 값으로 빼서 저장하는 건 가능한데, 우리가 필요한 작업은 객체 자체를 넣는 것이기 때문에 일단 철수하기로 ...

2. 느낀 점 : 프론트엔드 분들은 뷰작업과 백엔드에서 만들어놓은 코드에 값을 붙이시느라 정신없이 바쁘다. 백엔드는 상대적으로 시간이 남았다. 물론 몇가지 해결해야할 에러들이 있고 내가 맡았던 부분이 아니라 지식이 많이 부족해서 같이 구글링을 도와드려도 사실 이해가 잘 되지 않았다. 뭔가 붕 뜬 느낌이다. 이 시간을 어떻게 밀도있게 잘 보낼 수 있을까

3. 새로 알게 된 내용 : 오늘 어제 들었던 도커관련된 강의를 좀 더 찾아보고 팀원분이 맡으셨던 CI/CD가 해결이 잘 되지 않아 나도 같이 공부를 해보았다. 내가 개념이 좀 더 있으면 같이 에러를 해결하는데 좀 더 도움이 될까 싶어서였다. CI/CD는 자동 빌드, 테스트, 배포를 해주는 인프라 작업이다. 이를 통해 개발자가 좀 더 개발에만 집중할 수 있도록 해준다. 여러가지 프로그램이 있는데 그중에서 우리는 깃헙액션과 AWS CodeDeploy를 사용한 CI/CD 시도 하고 있다. 젠킨스 라는 프로그램도 많이 사용되고 있는데, 깃헙액션보다 사전에 환경설정을 해줘야 할 부분이 많아서 깃헙액션을 사용하기로 했다. 배움엔 끝이 없다 ! 

4. 셀프칭찬 (오늘 잘한 일) : CI/CD에 관련도니 우테코 영상및 여러가지 자료들을 찾아보았다. 글로만 봤을 땐 참 쉬운데, 내가 직접 깃헙에서 CI 파일을 구축하려고 해보니 경로설정때문에 꽤 애를 먹었다. 그냥 블로그 글만 보고 복붙해서 되는게 아니라, 각자 파일의 구조에 따라 다르다는 것 ...! 결국 테스트용 파일 하나 다시 만들어서 CI에 성공했다. 코린이인 나에겐 아직도 어려운게 너무 많다. 삽질의 연속인 하루하루 ... 그래도 삽질을 통해 하나 더 배웠다. 

5. 내일 할 일 : 이번주 중간발표 자료 준비

[오늘 공부한 부분] 

• CI/CD 공부

[14] 2주차 기술멘토링 피드백 정리

[15] Spring CI/CD

1. 어려웠던 부분 : 오늘도 프론트엔드에 값을 넘겨줄 때 자잘한 에러가 있었다. 공지사항에 오답일 경우 "닉네임"님의 정답은 오답이라고 뜨는 부분이 있는데 여기서 닉네임 부분에 null값이 들어갔다. 백엔드 코드에서 이 닉네임을 Member Repository에서 받아오고 있었는데, 게임 로직을 수정하면서 이젠 Member 엔티티가 필요한게 아니라 프론트에서 넘겨주는 값을 받아야 했다. 

이 부분을 수정하기 위해 GameDto 라는 디티오를 만들고 (RequestDto 가 되겠다.) 프론트에서 게임을 하면서 넘겨주는 닉네임값을 받아주었다. 그리고 여기서 받은 닉네임을 아래의 사진과 같이 필요한 부분에 붙여주니 정상 작동 되었다.

2. 느낀 점 : 지난주 멘토님의 피드백을 반영해 도커를 시도해 보려했다. 참 개발은 공부의 끝이 없는 것 같다. 예전에 어떤 멘토분께서 개발은 파면 밑도 끝도 없으니 그때 그때 필요한 정보를 필요한 만큼만 알아내는 것도 능력이라고 하셨는데 무슨 의미인지 알 것 같다. 개발을 시작하기 전엔 전혀 몰랐던 분야를 접하고 보니, 세상엔 참 내가 모르는 것들이 많다는 사실이 새삼 다시 한번 느껴졌다. 아직 고작 3개월 차 코린이 인데 모르는게 더 많은게 당연한 거니까 조급해 하지말고, 천천히 단단하게 배워나가야 겠다.

3. 새로 알게 된 내용 : 3조에서 코드윗미 라는 인텔리제이회사에서 만든 서비스를 이용하는 것을 보았다. 서로 실시간으로 코드 수정을 볼 수 있고, 누가 어떤 부분을 수정하는지 알 수 있는 서비스이다. 개발이라는 분야를 시작한지 이제 3개월 정도 되었는데, 참 다양한 툴이 많고 협업하기 좋은 환경인 것 같다. 그리고 오늘 처음으로 도커라는 것을 공부했다. 생활코딩 강의와 몇개의 블로그 글들으 보면서 따라해 봤는데, 일단 따라는 했는데, 사용해 보지 않아서 정확히 어떤 점이 도커의 장점인지 어떻게 사용하는 건지는 와닿지 않았다. 일단 오늘은 세팅한 것에 의의를 ... 

4. 셀프칭찬 (오늘 잘한 일) : 오늘 프론트엔드에서 null값이 뜨는 오류가 있다고 했을때 너무 자연스럽게 왜 그러지 알 것 같았다. 아 맞다 그부분 수정했어야 했는데! 라는 생각이 들었다. 예전 같았으면 왜지? 라는 생각만 들었을 텐데 그만큼 코드를 보는 눈이 조금은 생긴 것 같달까? 느리지만 조금씩 성장하고 있는 나를 칭찬한다. 

5. 내일 할 일 : 아직 우리팀에서 해결하지 못한 CI/CD + 웹소켓 세션 객체를 레디스에 저장하는 법 같이 에러 찾아보기

[오늘 공부한 부분] 

• 코드 에러 수정
• log 공부
• 도커 공부

[11] Docker (1)

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

[52] Spring boot Logging(@Slf4j)

1. 어려웠던 부분 : 오늘은 프론트엔드분들이 채팅으로 공지사항을 내리는 부분에 받는 값이 없다는 이슈가 있다고 하셔서 그 부분을 수정하는 작업을 했다. 우린 분명히 값을 보내고 있는데 아예 받는 값이 없는 문제였다. 알고보니 백엔드 코드와 프론트엔드 코드에 몇가지 수정할 부분이 있었다. 

1. 컨트롤러에서 "/pub" 떼기 (백엔드)
2. gameroomId -> gameRoomId (프론트)
3. start -> START (프론트)

1. 처음엔 아래와 같이 컨트롤러 부분에 "/pub" 으로 시작하는 URL 주소를 사용했다.

@MessageMapping 을 사용했기 때문에 보내는 입장인 백엔드에선 "/pub"을 제외하고 아래와 같이 수정해 주었다.

2. 아래와 같이 우리는 메세지 타입을 대문자 START로 보내고 있었는데, 프론트에선 소문자 start 로 받고 있었다. 이부분을 수정해주었다.

위와 같이 사소한 부분들을 수정해주니 제대로 동작하였다. 다행히 오류를 찾는에 오래 걸리진 않았다. 다시한번 느끼지만 점 하나, 슬래시 하나때문에 모든게 동작하지 않는 컴퓨터의 언어. 컴퓨터는 잘못 없어 내가 잘못 쳤어 ... ^^

2. 느낀 점 : 이번 프로젝트를 하면서 오랜만에 협업을 경험하니 새롭고 재미있다. 전 직장에서 일할때도 팀워크가 맞을때 참 짜릿하고 좋았는데, 이번에 팀을 잘 만나서 덕분에 나도 많이 배우고 재밌게 하고 있다. 열심히 하는 팀원분들을 보면서 동기부여도 되고 스스로 반성하게 되는 것 같다. 

3. 새로 알게 된 내용 : 오늘 전체조회를 두번이나 하면서 랜덤으로 카테고리를 뿌려주는 로직을 Enum을 활용해 훨씬 더 효율적인 코드로 수정했다. 사실 Enum이라는 개념이 너무 생소해서 지난주에 공부하긴 했지만 그래도 와닿지가 않았는데, 직접 코드에 적용해 보면서 아 ! 이게 이렇게 쓰이는 거구나 라는 걸 알 수 있었다. 역시 코딩은 글로 읽는게 아니라 직접 해봐야 더 이해가 되는 것 같다.

4. 셀프칭찬 (오늘 잘한 일) : 이번 프로젝트 때 내가 맡은 부분이 그렇게 크진 않아서 최대한 팀한테 어떻게 도움이 될까 많이 고민했다. 내가 할 수 있는 도움은 에러가 터졌을 때 같이 찾아보는 정도인데, 내가 로직은 잘 못짜고 더디더라도 오타 하나만큼은 잘 찾느 것 같다. 오타를 잘 찾았던 오늘의 나를 칭찬해줄래 

5. 내일 할 일 : 도커 공부하기 

[오늘 공부한 부분] 

• 오류 수정
• CI/CD 공부 

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

1. 어려웠던 부분 : 

• 비교적 순탄했던 지난주와 다르게 매일매일을 새로운 에러메세지와 마주해야했던 고된 한 주 였다. 생각보다 WebRTC 시그널링 연결이 오래 걸렸는데, http인 로컬 서버로만 했을 때는 문제없던 기능들이 https 서버로 환경을 바꿔주었더니 틈만나면 아래와 같은 에러 혹은 403, 404, 405에러, 혹은 http 어쩌구리 parsing 에러를 뱉어냈다. 

• 알고보니 https를 배포할 때 인증서 발급을 받는데, 거기에 프론트엔드 도메인 주소와 백엔드 주소를 모두 기입하지 않고 백엔드 주소만 입력해서 발새한 문제였다. 두 주소 모두 같은 인증서에 등록해주니 이 문제는 일차적으로 해결이 되었다.
• 그러나 이어서 다시 기능을 좀 수정하고 Redis 서버로 배포하기위해 돌리는 과정에서 의존성주입에러가 발생하기 시작했다. 호~ 구글링해서 나온 모든 사이트를 들여다 봤다고 해도 과언이 아니다. 그런데도 불구하고 아직까지 해결하지 못했다. 아마 내일부터 다시 이 에러를 해결해야 할 것 같다. 거진 다 끝났다고 생각했는데 하루에 하나씩 새로운 에러가 터지니 새롭다 정말 ^_^

2. 느낀 점 :

• 팀원들 모두 매일 늦게까지 고생한 한 주 였다. 프론트 백에드 할 것 없이 같이 에러를 수정해보고 계속 고치면서 테스트해보고, 이 과정이 모두 지칠법 한데도 서로 배려하는 분위기라 팀원들한테 많이 배운 2주차 였다. 에러때문에 지치긴 했지만 디자이너 님이 우리 제안한 사항을 잘 반영해서 너무 좋은 디자인을 만들어 주셔서 뭐가 힘을 낼 수 있는 주차였던 것 같다.

3. 새로 알게 된 내용 : 

• Spring vs Spring boot
• Git vs Github vs Gitflow vs Github flow
• Refresh Token
• Truble shooting
• WebRTC , WebSocket 개념 재정리
• https 배포

4. 셀프칭찬 : 내가 맡은 부분이 다른 팀원들에 비해 적은편이라 빨리 끝낼 수 있었다. 맡은 부분을 끝내놓고 다른 팀원들의 에러를 같이 해결하기 위해 노력한 한 주였다. 같이 구글링을 해보고 덕분에 내가 담당하지 않았지만 다른 팀원이 맡은 기능에 대한 공부도 해보고, 스스로 풀어지지 않고 열심히 하려고 한 나를 칭찬한다.

5. 다음주 할 일 : 다음주 주말에 중간 회고가 있다. 어떻게든 MVP 구현하기 ! 

[ 이번주 공부한 부분 링크 정리] 

< 트러블 슈팅 정리 >

[41] 트러블 슈팅 : nonuniqueresultexception: query did not return a unique result

[42] 트러블 슈팅 : Type definition error

[43] 트러블 슈팅 : @RequestMapping의 produces 속성

[46] 트러블 슈팅 : InvaliDataAccessApiUsageException: detached entity passed to persist

[49] 트러블 슈팅 : JWT signature does not match locally computed signature

[50] 트러블 슈팅 : CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource (allowedOrigins)

[51] 트러블 슈팅 : (WebRTC) Error parsing HTTP request header

트러블 슈팅 : Invalid character found in method name. HTTP method names must be tokens

< 기본 개념 정리 >

[44] Spring vs Spring boot 차이

[45] Git vs Github vs Git Flow

[03] (Spring Boot) WebSocket / WebRTC

[08] Spring Security + Refresh Token (1)

[10] Spring Security Refresh Token (2)

[47] Enum

< 그 외 >

[02] Redis 설치 및 명령어 정리

[04] 카카오 로그인 PostMan 테스트 방법

[05] Hashmap을 JSON으로 변환하는 법

[06] Spring Security 인증인가 - 예외 커스텀 핸들링

1. 어려웠던 부분 : 오늘 기술멘토링이 있는 날이었다. 우리가 궁금했던 부분을 여쭤봤는데, 사실 시원한 해답을 얻진 못했다. 그냥 더 열심히 구글링하고 깨지면서 해결을 해봐야 한다. 그래도 이제 https 문제느 해결이 됐는데, 다른 팀원분이 CrudRepository를 적용한 파일을 테스트용으로 빌드하고 배포하는 과정에서 아래와 같은 에러가 발생했다. 

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'signalHandler': Unsatisfied dependency expressed through field 'gameRoomSessionRepository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'gameRoomSessionRepository' defined in com.example.namoldak.repository.GameRoomSessionRepository defined in @EnableRedisRepositories declared on RedisRepositoriesRegistrar.EnableRedisRepositoriesConfiguration: Invocation of init method failed; nested exception is java.lang.reflect.InaccessibleObjectException: Unable to make field private final transient 
java.net
.InetSocketAddress$InetSocketAddressHolder 
java.net
.InetSocketAddress.holder accessible: module java.base does not "opens 
java.net
" to unnamed module @e580929

거의 반나절을 구글링을 해봤다.

뭔가 @Autowired 어노테이션이 잘못된 것 같아서 구글링에서 나온대로 여기 저기 @Repository 어노테이션도 붙여보고 @Quilifer 어노테이션으로 이름도 붙여줘보고, @Primary 어노테이션으로 우선순위도 줘보려고 해지만 계속해서 같은 오류메시지가 떴다. 근데 결국 새벽 1시가 될때까지 해결하지 못했다. ㅜㅜ 산넘어 산이다 정말.

2. 느낀 점 : 어떻게 해야 효율적으로 정보를 찾을 수 있을까? 이번주 내내 에러의 늪에 빠져보며서 좋은 해답을 얻기 위해선 어떻게 구글링을하고 좋은 자료를 찾을 수 있을까에대한 고민이 깊어졌다. 기본기가 탄탄하다면 더 좋았을 텐데, 너무 많은 양을 단기간에 배웠다보니 이런 부분에서 부족함이 느껴지는 것 같다.

3. 새로 알게 된 내용 : 멘토님이 Refresh 토큰을 도입하고 저장하는 부분에대해 고려해봤냐고 질문을 주셨다. 사실 아무 생각없이 코드만 구혀해 놓았기 때문에 오늘 피드백이 끝나고 그 부분을 공부해봤다. 아직 프론트와 맞춰보지 않았기때문에 상황이 달라질 수 있지만, 프론트에 전달할 땐 로컬 스토리지에 저장하고 서버에 저장할 땐 Redis 스토리지에 저장하는 방법을 사용하게 될 것 같다. 어렵다 어려워. 공부가 더 필요하다 ! !

4. 셀프칭찬 (오늘 잘한 일) : 존버하는 하루 하루

5. 내일 할 일 : WIL 작성하기

[오늘 공부한 부분] 

[10] Spring Security Refresh Token (2)