[ je 개발 일지 ] 115, 116일차 "에러 하나에 두통"

---

[ 오늘의 TODO & DONE ]

1. 개인 공부) 자바 / 스프링 학습 (115일차)
   - Exception 처리
   https://github.com/Je-chan/spring-study/tree/main/fast-campus/spring-boot-basic/exception 
2. 개인 공부) 함수형 프로그래밍 학습 (116일차)
   - Array 를 함수형 프로그래밍으로 작성하는 방법
   https://github.com/Je-chan/typescript-functional-programming/tree/main/handleArray
3. 독서) 리팩터링 읽기
   - 4-1 자가 테스트 코드의 가치
   - 4-2 테스트할 샘플 코드
   - 4-3 첫 번째 테스트
   - 4-4 테스트 추가하기
   - 4-5 픽스처 수정하기
   - 4-6 경계 조건 검사하기
   - 4-7 끝나지 않은 여정
4. 생활) 물 1L 이상 마시기
5. 생활) 최소 30분은 운동하기

GitHub - Je-chan/typescript-functional-programming

GitHub - Je-chan/spring-study

---

[ 어제, 오늘의 회고 ]

1. 내가 어제 블로그를 남기지 않았던 이유? 에러 때문에 두통 와서

  하....

 

  에러.....

 

  어제 발생한 에러는 도대체 무슨 에러인지를 모르겠다. 내가 통신을 보내면 301 Status 코드를 보내준다. 백엔드에서는 Redirect 를 해주는 로직이 전혀 없는데도 그런 에러가 났다. 내 쪽에서 무슨 일이 있는 건가 싶어서 Vite 의 Proxy 를 사용해봤다. 아주 재밌는 건, Proxy 를 사용했을 때는 CORS 에러 없이 301이 뜨고, Proxy 를 사용하지 않았을 때는 CORS 에러와 함께 301이 뜬다. 더 재밌는 건, 내가 Proxy 를 사용하지 않더라도 같은 도메인의 다른 Path 에서는 CORS 에러가 뜨지 않는다. 이 말들을 종합해보면 지금 301 이 뜨는 그 페이지가 매우 특수한 상황이라는 건데 도대체 무엇이 문제인가...? 301 에러 코드가 뜨는 건 사실, Client 딴의 API 의 호출과 관련된 로직에서 발생시킨 문제일텐데, 여기서 너무 어이가 없는 건 내가 사용하고 있는 API 는 Axios Instance 를 만들어 공유하면서 사용하고 있다는 점이다. 301 문제를 일으키는 API 의 Instance 를 공유하는 다른 API 호출은 정상적으로 작동한다. ...도대체 뭐지? 뭐가 문제인 거야. 

 

  진짜 이 에러는 어떻게든 고쳐본다. 정말로.

 

2. 다음 프로젝트 땐 백엔드도 조금씩 하기로 했다. (근데 JS가 훨씬 재밌음)

  다음 프로젝트를 진행할 때는 나도 백엔드에 조금은 기여하기로 했다. 아주 큰 역할을 맡는 건 아니고 그냥 간단하게 API 만드는 정도지 않을까 싶다. 솔직히, 내가 지금 백엔드 공부를 완전 몰입해서 하고 있는 것도 아니고, 부트 캠프에서 공부한 것도 아니고, 심지어 나는 Node.js 기반으로 백엔드를 만진다고 하면 어려운 기능도 할 수 있을 거 같은데 자바다 보니까 너무 어렵다.

 

  그리고 내가 공부할 때마다 느끼는 거긴 한데 자바보다 자바스크립트가 훨씬 재밌다. 강의를 들어도 자바 관련 강의는 듣기가 겁나 힘든데 자바스크립트나 타입스크립트 강의를 들을 때는 왜이렇게 재밌는지 모르겠다. 물론, 아직 내가 자바를 잘 모르기 때문에 그런 것일 수도 있기는 한데 아무튼 백엔드를 할 것이냐 프론트엔드를 할 것이냐. 이 기로에서 나는 아직 프론트엔드가 더 맞다고 생각한다. 그래도, 백엔드를 공부한 지 얼마 안 됐기에 이런 생각을 할 수 있는 것이라 일단은 좀더 해보고 커리어에 대해서 깊이 있게 고민해봐야 할 것 같다.