4주차 회고 : 최선의 선빵

들어가며

혹시나 우리의 회고를 읽어주실, 그리고 우리의 CORS 에러(해결이 되면 문구 바꿀 예정입니다.)에 대한 해결책을 아실 분들이 있을 수 있기에 아래와 같이 전체 아키텍처 및 기타 부연 설명을 드립니다.

• https://zerohip.co.kr/ : 인증서 적용 상태

• https://www.zerohip.co.kr/ & https://api.zerohip.co.kr/ : 와일드카드 인증서 적용 상태

• 클라이언트랑 서버통신은 https , 서버내부통신 http

• 리버스 프록시 사용 상태

4주차 회고 : 최선의 선빵

지옥의 CORS

좌절, 희망 그리고.. 좌절

• CORS 개념을 배울 때까지만 해도, 웹 개발을 하면서 한 번쯤은 맞닥뜨린다는 CORS 에러가 나를 이렇게 극단적으로까지 괴롭게 할 것이라곤 상상도 하지 못했다.

• 이상하게도 내가 만든 페이지는 OAuth 말고는 CORS에러가 뜨지 않았고, 나머지 팀원 분들은 모든 페이지에서 CORS 에러가 뜨는 상태였다. 특히 은비님의 페이지는 진입하는 페이지부터 CORS 이슈가 있어서, 은비님은 그야말로 정말 아무것도 할 수 없는 상태였다.

• 아무리 생각해도 우리 쪽 문제는 아닌 것 같았지만 새벽 2시까지 아서 멘토님께서 java 코드를 검토해주셨고 그 결과 백엔드 코드에는 아무 이상이 없다고 하셨고 프론트 쪽에서 검토가 필요할 것 같다는 이야기를 해주셨다.

• 프론트엔드에서의 원인이 있나? withCredentials:true만 넣으면 된댔는데…

또 다시 희망

• 그러다 뭔가, 이상한 점을 발견했다.

• 제일 처음에 뜨는 정적 파일에서 CORS 에러가 나는 페이지는 Response Headers에 뭐가 되게 많이 있는 것이었다.

• 특히 바로 아래의 스샷에서 첫번째 첨부 이미지를 보면, 일단 Response Headers가 눈에 띄게 다르고, 특히 X-Matched-Path라는 항목이 CORS 에러가 나는 페이지에는 추가가 되어 있다.

• 찾아보니 X-Matched-Path는 nginx에서 사용되는 헤더였다…!

• nginx의 헤더에 Access-Control-Allow-Origin: * 이 추가되어 있었고, 이것은 프론트에서의 withCredentials: true 와 공존할 수 없는 속성이었다. (아래 발췌 블로그 링크)

• 하지만, 문제는 nginx의 헤더 설정은 되어 있지 않았고 spring security에서 CORS 관련 설정을 이미 다 해두셨던 것이다. (nginx 보다 설정할 수 있는 항목이 더 많음)

• 그래서 임의로 spring security의 설정을 주석처리하고 nginx에서 설정을 하면 이번에는 no header CORS 에러가 났다.. (사실 백엔드 쪽에서 요청하면 문제 및 결과를 전달받기만 하여 제대로 된 과정을 설명하기는 어렵지만, 이해하기에는 이렇다.)

• 두 군데 다 하면 이번에는 multiple value CORS 에러가 났다.

• 이번에는 CORS 에러가 나는 페이지에서는 301 Permanently moved (참고 링크) 응답이 왔다.
• 아직까지도 의문인게, 왜 내 페이지에서는 nginx가 리다이렉션을 안 시켰을까? 무슨 기준이지? 가 궁금하다…

• 백엔드에서는 모르겠지만, 프론트에서는 에러가 나는 줄 아래로는 내려가지 않는다.

• 다시 말해 해당 줄에서 실행을 멈추고 해당 에러를 처리해야 하며 에러가 발생한 줄 다음에 있는 코드는 실행되지 않다.

• 때문에 nginx 설정을 이리저리 바꿔봤을 때 에러메시지가 바뀌는 것 역시 일단 여기서 에러를 유발하고 있는 포인트라는 것은 내 기준에서 거의 확실한 것 같다.

• 그 방식으로 된다는 보장은 없었지만, 그래도 우리는 모든 가능성을 열어두고 시도해보아야만 했다.

그렇게 데모데이 당일, 7시간 전

• 뭔가 도와주고 싶은데… 그저 기다리면서 프론트 쪽 세팅에 대해 여쭤볼 때 바로 대답해주는 것밖에 할 수 있는 게 없었다.

• 참으로 무력했다.

 

데모데이 당일, 5시간 전

됐다.

멘토링에서의 깨달음

가장 중요한 것은 회고를 하는 것.

많은 기능보다 하나의 기능이 제대로 작동하는 것이 중요하다. 좋은 코드를 작성해라

• 변수명 가독성 있게 짓기

• 이 코드가 어떤 내용인지 전반적으로 흐름이 잘 나타나도록 코드 짜기

1. login Id, 비밀번호, 닉네임, 이메일 등의 인풋이 비었는가? 조건에 충족되지 않는가? → 각각 에러 메시지 출력하기

2. 로그인 버튼을 눌렀을 때, 에러 메시지가 있으면 → 버튼에 거절 애니메이션을 발동시키고 return 시키기

3. 로그인 버튼을 눌렀을 때, 에러 메시지가 없고 성공했으면 → 회원 등록 후, 바로 로그인 페이지로 리다이렉션하기

4. 로그인 버튼을 눌렀을 때, 에러 메시지가 없고 실패했으면 → 서버로부터 받은 에러 메시지 토스트 알람으로 출력하기

1. login Id, 비밀번호, 닉네임, 이메일 등 인자로 받는 함수를 따로 빼서 import하여 에러메시지를 출력 예) const newError = isInputValueValid(loginId, password, nickname, email);

2. 3~4에서의 로그인 성공/ 실패 처리를 useMutation을 통해 따로 모듈로 뺌 (try, catch와 비슷한 개념)

• 3~4에서의 에러메시지 유무로 성공/실패를 판단하는 로직까지도 따로 빼야한다는 것이었다..!!

가감없이 나를 보여주는 것

되돌아보며

힘들었던 것

• 가장 힘들었던 점은 잠이 올 때, 잘 수 없다는 것이었다.
• 일정관리, 브랜치, 배포, CORS… 자세한 이야기는 주차별 회고에 적혀있기에 생략하겠다.
• 메인 프로젝트를 하면서 결코 쉬웠던 하루가 없었다. 부트캠프에서 임했던 그 어느 때보다도 더 밀도깊은 하루 하루를 보냈다.
• 무엇보다도 늘 11시 30분이면 자야 했던 나의 생체 시간이, 해결되지 않는 문제를 해결해야 하는 압박 속에서 점점 늘어지기 시작했다.

• 촉박한 기간 내에 달성해야 하는 목표로 인해 평정심을 잡기가 쉽지 않았다.
• 조급함을 느낄 때마다 차분하게 문제 해결을 하고, 코드를 짜려고 많은 노력을 했다.
• 하지만 어쩔 수 없이 평정심을 살짝 잃고 집중을 못할 때도 있었다.
• 그런 의미에서 정말 좋은 경험이었다.
• 압박적인 상황 속에서 24시 크런치 모드로 해야 하는 일을 집중해서 업무에 몰입하여 최대의 생산성을 내는 것은 꼭 필요하다.

나의 K

• 그래도 해냈다.
• 포기하지 않았다. 지치지 않았다.
• 수많은 이슈를 맞닥뜨리며 포기할 수 있었지만, 그래도 결국 해냈다.
• 문제는 부딪히다 보면 언젠가는 해결은 된다. 어떤 방식이든간에.
• 어떻게든 문제 해결을 위해 다양한 제안을 시도했다.
• 우리는 엔지니어다. 중요한 것은 문제를 해결하는 것이다.

• 많은 것을 배웠다.
• 커뮤니케이션, 프로젝트 기초 세팅, 디자인 시스템, 새로운 기술 스택 등 많은 것을 배웠다.
• 그리고 많은 것을 배우고 싶어졌다.
• 특히 백엔드 쪽의 지식이 현재는 10% 정도 있는데, 50%까지 올리고 싶다.

나의 P

• 융통성이 과했다.
• 뭔가, 융통성은 나를 한 마디로 표현할 수 있는 말인 것 같다.
• 교사로 재직했을 때도, 뭔가 새로운 시도를 많이 했고 아이들에게 많은 자율성을 주었다. (코로나 시기에는 각자 집에서 메타버스에 접속해서 한국사 역할극을 열고, 학교 마스코트 콘테스트를 열어 각 학년별 캐릭터를 만들고, 학년 별 캐릭터로 키링 굿즈를 만들었다....ㅋㅋㅋㅋ)
• 우리 반을 담당하는 전담 선생님들께서는 ‘5학년 1반은 선생님 없어도 자기들끼리 잘 돌아간다’라는 피드백을 주셨다.
• 하지만 팀 프로젝트에서는 중심을 잡고, 검증된 레퍼런스 위주로 진행해야할 필요가 있다.

• 어떨 때는 조급한 마음에 괴랄한(?) 문제해결방식까지 도입하고자 시도했다.(ㅋㅋㅋㅋ)
• 나는 좀 일단 뭐~든지 시도해보고 해결되면? 땡큐!라면 은비님은 신중한 원리원칙주의자셨다.
• 따라서, 종종 브레이크 걸어주신 은비님께 감사드리며 부딪히면서도 많은 것을 배울 수 있었다! (은비라고 쓰고 근본뿌리라고 읽는다)

• 압박 속에서 벌어지는 문제 상황에서 의연하게 대처하는 자세 또한 필요하다.
• 우리에게 주어진 날은 하루, 그리고 막 배포가 된 상황.
• 그럼에도 불구하고 로컬 테스트를 하고 pr을 날린 후 merge를 했어야 했다.
• 하지만 급한 마음에 바로바로 dev에서 바로바로 코드를 날리며 테스트를 했다.
• 급할 수록 돌아가라 - 꼭 기억해야 할 원칙이다.
 

나의 T

1. 검증된 레퍼런스를 먼저 찾고, 이것저것 시도해보는 것도 좋지만 결과에 대해 신중하게 검토해보기

2. 전반적인 리팩토링하기

3. Postman, 로컬테스트 철저하게 하기

4. Next.js에 대한 다양한 기능 써보기 (SSG, 서버리스 등)

5. 사용자 정의 명세서 100% 달성하기

6. 얇고 길게 백엔드 강의도 듣기

“팀” 프로젝트 소감

• 멘토 님께서 멘토링 1주차 때 경험하기 쉽지 않은 팀 프로젝트인 만큼 많은 것을 얻을 수 있을 것이라고 하셨다.
• 그리고 버전 1 프로젝트가 마무리된 지금, 그게 무슨 의미인지 알게 되었다.
• 하나의 목표로 진심으로 프로젝트에 몰두할 수 있는 환경은 그 어디에서든 쉽게 경험할 수 없다.
• 만약, 그저 인터넷에서 사이드 프로젝트 팀원을 구하거나, 또는 친구들끼리 프로젝트를 시작한다면 이 정도의 진심과 시너지가 나오기는 쉽지 않을 것이다.

• 팀 프로젝트를 하면서 내가 가장 자신있게 이거 하나만은 얻었다! 라고 할 수 있는 것은 바로 선빵의 정신이다.
• 수 많은 이슈와 에러들이 있었지만 우리는 불화나 갈등이 없었다. (그쵸? 읍읍읍- 하시는 거 아니죠? ㅋㅋㅋㅋ)
• 그렇다고 하고 싶은 이야기를 꾹 참고 분위기에 맞춘 것도 아니었다.
• 나를 비롯해 그저 하고 싶은 말과 의견을 최선을 다해 개진했고, 그로인해 최선의 결과를 얻었다.
• 특히, 에러를 잡기 위해 프론트엔드인 내가 백엔드 팀원 분들께 이것저것 말도 안 되는 요청을 했을 수도 있다. (거의 100%다.. ㅋㅋㅋㅋㅋ )
• 하지만 진지하게 받아들여주셨고 제 생각엔 의미 없을 것 같은데 그래도 해볼게요 (ㅋㅋㅋㅋ)라고 말씀해주셔서 너무너무 감사했다.

• 서로를 위한 피드백 역시 아낌없이 해 주었다. 그 사람을 진심으로 생각하는 애정을 담아서.
• 나 역시 팀 안에서의 나는 이런 장단점이 있구나- 를 알 수 있었다.
• 그렇게 받은 피드백은 정말 소중하다.

• 에러가 났을 때 회의방에 누가 들어가 있으면, 어느 새 한 명씩 한 명씩 들어와 결국 6명이 한 방에 있곤했다.
• 우리 모두가 꺾이지 않은 마음으로 서로를 지탱했다.

이제 다시 시작

제로힙은 끝나지 않는다.