항해 99 - 2023.03.28 TIL

거의 3주만에 TIL을 쓰는 것 같다.

 

그동안 클론코딩 프로젝트를 마무리하고, 현재는 최종 프로젝트를 진행 중이다.

어쩌다 보니 B2B SaaS 공모전에 참가하게 되어, 사내에서 사용할 만한 기능을 주제로 애플리케이션을 만들고 있다.

 

https://github.com/Bipum-In/Bipum-In-BE

GitHub - Bipum-In/Bipum-In-BE: 비품인 백엔드 레포입니다.

 

프로젝트 명은 비품인 (Bipum-In) 사내 비품 관리를 편리하게 할 수 있는 일종의 ERP이다.

 

비품인 관리자 메인화면

 

아직은 프로젝트가 진행중인 관계로, 자세한 소개는 프로젝트 종료 후에 해보려고 한다.

 

 

내가 현재까지 담당한 역할은 다음과 같다.

 

1. 서버 세팅

2. 유저 / 로그인 (소셜 로그인)

3. 관리자 / 사용자 대시보드

4. 유저 요청서 작성 페이지

 

 

구현하면서 느낀 점에 대해서 회고해보고자 한다.

---

서버 세팅

이번에는 서버를 담당하게 되어 EC2 + S3 + RDS를 연동해서 서버 환경을 구축했다.

CI / CD도 CodeDeploy와 GitHubActions를 사용해서 비교적 쉽게 진행할 수 있었다.

 

https://bcp0109.tistory.com/356

AWS 1편: EC2 생성 후 Spring Boot 띄우기

 

NGINX 를 이용해서 리버스 프록시를 적용하였고, SSL 인증서는 무료 인증서인 LetsEncrpyt를 사용했다.

결과적으로 서버에 HTTPS 를 적용할 수 있었다.

 

NGINX 를 세팅할 때 특히나 문제가 많았는데, 리눅스 환경에서 세팅하는 것이 익숙하지 않아서 어려움이 컸다. 

 

https://livelyoneweek.tistory.com/13

스프링 서버 HTTPS(Nginx, letsencrypt 활용) 적용

블로그 글을 따라하되, 동작 원리를 최대한 이해해보려고 노력했다. 그럼에도 아직 프로토콜에 대한 이해나 포트 포워딩 등 작업을 위해 필요하지만, 왜 필요한가? 에 대해서는 이해가 부족한 것 같다.

 

서버 세팅을 진행하면서 그 동안 해보지 못했던 여러가지 경험을 할 수 있어서 의미있었다.

특히, AWS 계정의 권한 설정과 리눅스 환경에서 직접 서버를 세팅해보면서 막연하게만 느껴졌던 분야에 대한 두려움을 덜어낼 수 있었다.

 

 

---

유저 / 로그인 (소셜 로그인)

이전에 Oauth2 구현 경험이 있었던 관계로 가장 자신있고 쉬울거라고 예상했던 기능이다.

 

카카오 소셜로그인만 구현하기로 결정했고, 기능 구현을 위해서 시간은 그리 오래 걸리지 않았다.

 

의외로 어려웠던 것은 인증코드 전달 방법에 대한 문제였다.

 

이전에는 코드스니펫을 통해서 프론트 환경을 구축해서 한번에 테스트를 진행할 수 있었는데, 이번에는 서버 쪽만 구현이 되어 테스트를 해볼 방법이 떠오르지 않았다. 프론트와의 협업이 반드시 필요한 부분이였다. 

 

처음 API 진행 방식을 보고, 프론트에서 카카오 서버로 인증요청을 보내고 카카오는 백엔드 서버로 Redirect를 보내 인증코드를 전달해주어 토큰을 프론트 측으로 전달해주면 될 것 같다고 생각했다.

즉, 프론트에서는 요청만 보내고 서버쪽에서 모든 작업을 처리하는 방식이였는데 이렇게 하면 프론트와 서버는 API로 연결되어 있지 않기 때문에, 토큰을 다시 Response로 전달해 줄 방법이 없었다.

 

프론트에서 카카오 서버와 통신하여 인증코드를 받고, 다시 서버로 인증코드를 전달해주는 방법으로 해결했다.

 

 

---

대시보드 기능 구현

대시보드는 여러가지 데이터를 종합하여 Dto를 만들고, 여러 Dto를 종합하여 최종적으로 전달해주는 방법으로 어렵지 않게 구현할 수 있었다.

 

대시보드 내에 알림 기능이 있었는데, 새로고침 할때마다 새로 로딩되도록 구현할 수도 있었지만 조금 더 욕심을 내어 실시간 알림으로 구현해보고 싶었다.

 

구글링해보니, 웹소켓과 SSE 두 가지 방법이 있었는데 실시간 알림에 좀 더 적합한 것이 SSE 였다.

 

https://tecoble.techcourse.co.kr/post/2022-10-11-server-sent-events/

Spring에서 Server-Sent-Events 구현하기

https://gilssang97.tistory.com/69

알림 기능을 구현해보자 - SSE(Server-Sent-Events)!

 

SSE는 기존 HTTP 통신에서 요청을 보내면 응답을 보내고 통신이 종료되는 특징(비연결성) 과 다르게 프론트에서 SSE 구독 요청을 보내면, 그 시점부터 연결이 종료될 때까지 서버에서 프론트로 데이터를 보내주는 단방향 통신을 가능하게 한다.

 

서버 쪽 기능 구현이 끝나고, 프론트와 테스트를 진행해보니 요청은 들어오는데 Emitter를 생성한 후에 다시 프론트로 전달이 되지 않는 현상이 발생했다. 

 

구글링해보니, NGINX 사용 시, 기본 설정이 HTTP 1.0 으로 맞추어져있다고 한다. HTTP 1.1 부터는 지속 연결이 가능하지만 1.0은 요청 시 Header에 Connection: close 속성을 사용하게 되어 연결이 끊어지게 된다고 한다. 

 

그리고 NGINX 자체에 proxy-buffer 기능이 있는데, 이 기능이 SSE 가 실시간으로 응답할 수 없도록 만든다고 한다.

 

따라서 NGINX 내 설정 파일의 역할을 하는 conf 파일에 관련 코드를 추가하였다.

 

코드를 추가해도 여전히 동작하지 않아, 일주일 째 진행이 막혀있는 상황이였는데.. 구글링 중에 원인을 찾게 되었다.

NGINX 설정을 변경하고 재시작을 하지 않아 서버에 적용되지 않았던 것이다.

NGINX 는 설정이 변경되면 반드시 재시작을 해주어야 한다!!

 

해결 후에는 정말 허탈해서.. 다시는 깜빡하지 않을 것 같다.

 

 

메시지가 전달되는 것은 확인되었는데, 프론트 쪽에서 설정한 유효시간 전에 연결이 종료되고, 다시 재연결하는 현상이 발생했다. 재연결하면 서버에는 Emitter가 계속해서 쌓이게 되는데, 이벤트가 발생하면 알림이 나가게 되고 Emitter는 전부 비워져서 기능 상의 문제는 없지만 프론트 쪽에서 1분마다 지속적으로 에러가 발생하고 있어, 해결이 필요한 상태이다.

 

 

구글링을 해도 관련 정보가 없어서 아직 해결하지 못한 상태이다. 해결 후에 관련 정보를 업로드 하도록 하겠다.

 

 

---

느낀 점

사용자의 입장에서 생각해서 기능을 만드는 것이 생각보다 많이 까다롭고 어렵게 느껴졌다.

이것 저것 여러가지를 시도해보고 구현해보았는데, 완벽히 이해하고 사용한 것은 아니기 때문에 내 것이 되었다는 생각은 들지 않는 것 같다. 

구글링을 통해서 새로 접하는 기술에 대한 설명을 볼 때마다 CS 용어가 많이 나오는데, 대부분의 CS 용어가 생소하게 느껴지다 보니 기술에 대한 원리들을 이해하기가 어렵게 되는듯 하다.

 

이제 항해도 1달 정도밖에 남지 않았는데 시간이 참 빠르게 간다.

부트캠프가 끝나면 취업준비에 집중하겠지만, 남는 시간에 CS 공부를 겸해서 미리 준비를 해놓아야겠다.