[TIL] 24.09.25 WED

GDORI·2024년 9월 25일
0

TIL

목록 보기
52/79
post-thumbnail

풋살온라인 팀프로젝트 끝.

튜터님들의 피드백과 구현해보고 싶었던 것들이 많아서 시간 틈틈이
쪼개서 수리 진행해보고자 한다.

맞닥들인 문제들이 많았지만 그 중 제출 10분 전에 원인을 알게된 사례에 대하여 써보려고 한다.

로컬에서는 되는데 EC2 올리면 오류처리가 안돼.

프론트엔드와 백엔드를 컴퓨터에서 구동 시켰을 때에는 잘 됐다.
팀 3명 초과 시 에러 송출

팀원을 3명까지 장착할 수 있는데, 한명을 더 끼고자 하면 "팀은 최대 3명까지만 가능합니다."라는 내용의 에러내용을 백엔드단에서 반환한다.

프론트에서는 그 내용을 Catch하여 클라이언트에게 반환한다.
근데 문제는, EC2 ubuntu 서버에만 올리면 안된다.

소스코드가 바뀐 것도 아니야~ 그냥 그대로 올렸습니다. 아주 골 때리는 상황인거죠. 발표는 하루도 안 남은 상태인데.

CORS 문제인가? 방화벽이 문제인가?

CORS 미들웨어를 사용하여 내 도메인과 포트를 추가한 상태였다.
혹시 몰라 지우고 시도를 해보았는데, 이번엔 CORS 위반이라고 뜬다.
아 CORS 문제 아니네. 제외,

그럼 방화벽이 문제인가? 방화벽은 애초에 ubuntu 서버에 활성화 되어있지도 않았다.

EC2 보안정책 문제인가? 아니다. 관련된 포트는 다 허용해놓아서 접속되고 조회되는거지, 에러만 중간에 변조될리 없다.

발표 10분 전, 이유를 찾았다.

진짜 밤 세워가면서 구글링하고 적용해보고 코드도 바꿔보고,
별 거 다 해보았는데 갑자기 떠오른 생각이 바로 위에 쓴 내용인 중간에 패킷(?)이 변조?

조심스럽게... 내 작업표시줄 확장버튼을 눌러보았고...

니놈 짓이였구나. 내 response를 가로채서 전달 안해준놈이.
끄니까 바로 해결 되었다.
예전에 광고차단 목적과 변조 방지 목적으로 돈주고 설치해놓은 프로그램이 내 몇시간을 버리게 만든 원인이었다는 것을 알았다.

원인을 생각해 보았다.
저 프로그램이 HTTP 및 HTTPS 트래픽을 관리하는 리버스 프록시 인데, 이놈이 에러 응답을 가로채 스스로 에러처리 하는 것 같다.

아니면 클라이언트가 보내는 도중 리버스 프록시에 들어가게 되고
서버에서 나온 반환 값을 다시 프록시 서버에 들렸다가 가니까 그 과정속에서 변조되었을 가능성이 농후했다.

해결은 좀 더 알아보고...

일단은 끄면 정상작동 된다라는 것을 알았고 서버단에서 어떻게
에러 반환을 해야 프록시 서버를 거쳐도 변조되지 않는지에 대해 알아보고 적용하려 했다.

근데.. 이게 API와 웹서버는 내 EC2에 올라가 있는데 DB가 조장
계정에 있다...

이미 삭제되어버려서 이참에 개인 서버에 우분투 설치되어 있으니까 Node도 띄우고 도커로 MySQL을 올려서 환경만 구성해 놓고 차근차근 고쳐봐야겠다~ 생각했다~

하지만 또 문제가 생기고 말았는데..

도커를 설치하고 MySQL을 올린 후 VSCode에서 연결 테스트를 진행하는데...

도커에 설치된 MySQL이 8버전이라 인증 방식이 caching_sha2_password 프로토콜로 바뀌어서 조회가 안된다...
방안은 MySQL 버전을 내리는 것이라고 하는데 그냥 깔끔히 포기하고 DBeaver를 이용하여 조회하기로 했다..

어차피 Prisma는 연결하는데 이상이 없기 때문에 조금 편하게 DB 확인하자고 굳이 과거 버전을 쓸 필요가 있을까 싶었다.

아 모르고 root 비밀번호에 @를 넣었네

습관성으로 사용하는 비밀번호를 root 계정 비밀번호로 설정하고나서 .env DB path를 수정하는데 아. @ 넣었다는 것을 그제서야 인지.

...

바꿔야지 뭐.

alter user 'root'@'localhost' identified with caching_sha2_password by '사용할 비밀번호';

flush privileges;

수정이 끝나고 mysql 내에서 접속 테스트를 마친 후 DBeaver
접속 테스트를 진행했는데~~~

아니 정확하게 입력했고, 서버에도 테스트 해볼 때 정상적인데 왜 잘되던 조회가 안되는 것인가...
쉽게 진행되는 것이 없었다.🤮🤮🤮

무지하면 몸이 고생해요.

난 지금껏 root 계정 비밀번호를 수정해본적이 없고 설정하고 바로 사용만 해왔어서 간과한 사실이 하나 있다.

" root 계정은 사실 2개다 "

아니 이게 무슨, 주인장이 뭔 2명이야.

select Host,User,plugin from mysql.user;

localHost를 위한 root가 있고, 외부 접근용(%) root 계정이 있더라.

아이고.. 공부할게 많아서 행복하네
내가 아까 수정한 root 는 localhost였기 때문에 ubuntu 내
root 접속은 되었지만, 윈도우 환경에서는 접속이 안된 이유였던 것이다.

이것까진 바로 해결

alter user 'root'@'%' identified with caching_sha2_password by '사용할 비밀번호';

flush privileges;

바로 위 명령어로 외부용 root도 수정해주니 정상 접근이 가능했다.

그 외에..

공유기 설정에서 포트포워딩, DDNS 설정으로 LAN 환경 밖에서도 구동할 수 있게 설정하고.. 환경 구축이 끝났다..

힘겨웠다.

GOOD

프로젝트 끝났다고 바로 폐기하지 말고.. 여기까지 과정이 힘겨웠던 만큼 시간날 때 마다 해결되지 못한 문제, 튜터님들이 피드백 주신 내용 참고해서 쓸만하게 수정해 봐야겠다.

팀프로젝트 회고록

KEEP (잘된 점)

팀원 간 활발한 소통: 팀원들이 서로 적극적으로 소통하며 프로젝트를 원활하게 진행함.
능동적인 프로젝트 진행: 각자가 부족한 부분을 보완하며 능동적으로 프로젝트에 참여하고 책임감 있게 진행함.

PROBLEM (문제점)

스키마 설계의 어려움: 데이터베이스 스키마 설계에 혼란이 있어 개발 진행에 차질이 발생함.
기록 부족: 팀 노션에 중요한 정보와 진행 상황을 충분히 기록하지 않아 정보 공유에 어려움이 있었음.
회의록 미작성: 회의 후 논의된 내용을 기록하지 않아 나중에 회의 내용을 참고하거나 피드백하는 데 어려움이 발생함.
시간 부족: 연휴로 인해 구현에 필요한 충분한 시간을 확보하지 못함.
코드리뷰 부족: 서로 간의 코드 리뷰를 자주 진행하지 못함.
코드의 함수화: 코드작성을 쫌더 디테일하게 함수화하지 못했던점

TRY (시도할 점)

스키마 설계에 시간 투자: 스키마 설계에 충분한 시간을 들여 꼼꼼하게 진행하여 이후 개발 과정에서 문제를 줄이기.
기록의 적시성: 중요한 사항과 진행 상황을 제때 기록하고, 팀 노션을 활용해 정보 공유 강화.
회의록 작성 및 공유: 회의 후 각자 회의록을 작성하여 이를 합쳐 공식 회의록으로 공유, 소통 명확화.

profile
하루 최소 1시간이라도 공부하자..

0개의 댓글