[Sangle 2편] 나의 🌟첫 솔로(?)🌟 서버 개발 이야기

[Sangle 2편] 나의 🌟첫 솔로(?)🌟 서버 개발 이야기

 

Sangle의 기능

1편에 작성했던 내용처럼 생글에는 흥미로운 기능 이 많다.

IA 기준으로

• 회원가입 (앱 자체 가입, 소셜 로그인)
• 매일 주어지는 3개의 랜덤 글감
• 글 작성, 수정, 삭제
• 좋아요, 스크랩, 검색 (유저, 글감, 게시글 내용)
• 글감별 피드, 지난 글감
• 유저 정보 관련 (프로필, 정보 수정 등)
• 캘린더 (주별 달성률, 달별 기록)
• 명예의 전당 (어제의 가장 인기있었던 글감 별 게시글)
• 푸시 알림
• 활동 배지
• 공지사항
• 회원탈퇴

가 있다.

 

flow 반영 뷰 (블러처리 맞아욤)

 

여기에다 당연히 만들어야 하는, 그리고 개인적인 욕심으로도 만들고픈 관리자 웹 개발도 진행했다. 이렇게 개발하다 보니 세세한 부분까지 하나하나 캐치하다 api가 약 70개 정도가 나오게 되었다, 물론 sql 쿼리는 기능상 비슷한 쿼리문이 많아 160개 정도가 나오게 되었다. 혼자 모든 서버를 개발하려다 보니 느낀 점이 굉장히 많았던 생글 개발 이야기 지금부터 진짜 Start ! !

 

나의 첫 Spring Boot Project

 

1. 회원가입

생글 개발을 시작하는 순간, 또 스스로의 한계와 부딪혔다. 스프링 부트의 MVC를 이전 JSP 사용했을 때와 Node.js로 개발했을 때를 떠올려 빠르게 적응했지만 첫 기능이 소셜 로그인이었다. 물론, 앱 내의 회원가입도 있었지만 회의 끝에 소셜 로그인의 가입률이 훨씬 높다는 주위의 조언과 경험에 따라 애플 로그인과 구글 로그인도 구현하기로 했다. 소셜 로그인을 처음 접하는 만큼 초반에 플로우를 이해하는 면에서 헷갈리는 부분이 많았고, 분명 확신을 하고 넘어간 후에도 다시 재확인을 하는 경우가 있었다. 개인적으로 애플 로그인이 훨씬 어려웠다. 구글로그인은 개발적인 측면에서는 애플로그인에 비해 간단(?)한 편이었지만, 보안적으로는 좋지 않다고 생각했다. 이에 비해 애플로그인이 보안적으로 여러 번 체크를 해야 하는 만큼 개발적인 부분이 깊게 파고들 수밖에 없었다. 특히 미안했던 (?) 점은 애플 로그인을 구현하기까지 iOS 개발자를 괴롭힐 수밖에 없었다...ㅠ 계속 테스팅을 해보고 애플 로그인의 경우 검증가능 한 토큰의 유효시간이 10분 정도로 너무나도 짧았기 때문에 계속 토큰을 보내달라고 할 수밖에 없었다ㅠㅠㅠ 그럼에도 불구하고 둘 다 해내고야 말겠다는 의지로 계속 테스팅을 하다가 ✨성공✨했다. (이때 너무너무 뿌듯했다 ㅎㅎ)

2. 랜덤 글감, 이미지

이제 다음 랜덤 글감으로 넘어갔을 때, js가 그리웠다. 랜덤인 특성상 db에서 오늘의 글감 3개를 랜덤으로 가져와야 했고, 그 3개 중에서도 유저마다 또 랜덤으로 넘겨줘야 했다. shuffle을 쓰면 금방 해결이 되지만 클라이언트와 통신하려면 유저가 이 글감을 썼는지, 다른 유저들은 이 글감을 몇 개나 썼는지, 글감 별 랜덤 이미지 등 한 번에 response로 돌려주어야 했기 때문에 이 모든 data를 해결하려니 list를 간편하게 썼던 js가 잠시 그리웠던 순간이었다. 그럼에도 불구하고 계속 해결방안을 찾아내어 Collection을 사용해 원하는 결과를 얻을 수 있었다.

3. 글 작성, 수정, 삭제

이는 대부분의 간단한 프로젝트에서 다 하는 예제들이니 길게 회고하지 않고 넘어갈 것이다. 그중 가장 기억에 남았던 것은 클라이언트도 할 일이 너무 많았기 때문에 일을 덜어주고자 sql 쿼리문으로 작성한 시점의 연도, 월, 일, 요일, 시간도 적절히 분배해 response로 주었다. 그리고 게시글의 공개 여부도 같이 관리해주어야 했다.

4. 좋아요, 스크랩, 검색

좋아요, 스크랩 기능은 외래 키 연결만 잘하면 되기 때문에 길게 회고하지 않을 것이다. 하지만 이 부분을 진행하면서 이전에는 POST로만 통신했다면 이번에는 GET으로 @PathVariable을 이용해 진행했다.

5. 글감 별 피드, 지난 글감

글감 별로 피드를 보여주는 부분은 유저가 이미 사용한 글감이라면 그 글감에 관한 모든 피드를 보여주고, 아니면 블라인드 처리로 막아두는 뷰다. 따라서 개인적으로 이 부분은 클라이언트 개발자들이 힘들었을 부분이라 생각이 된다. 지난 글감은 이전 10일 동안의 글감과 유저들이 글감을 사용한 카운트도 같이 보여준다. 생글을 개발하면서 느낀 점이 날짜 관련 기능이 굉장히 많다는 것이다..❗

6. 유저 정보 관련

회의를 진행하면서 커뮤니티성을 나타내는 앱으로 갈 것인지, 말 것인지에 대한 안건이 여러 번 있었다. 자주 이야기 나누어보면서 결론은 진행하자는 것이었고, 따라서 다른 유저들의 프로필도 볼 수 있도록 진행했다. 나는 개인적으로 다른 유저의 정보를 볼 수 없으면 나만 글 쓰고 끝내는 앱이라고 생각이 들어 커뮤니티적인 부분을 넣자고 의견을 내었다. 대부분의 SNS를 보면 다른 사람의 프로필을 볼 수 있기 때문이다. 하지만 이 외에 개발할 기능들이 많이 남아있어 의견을 내면서 클라이언트 개발자들에게 뷰는 크게 다르지 않아도 되니 서버에서 data만 다르게 다 줄 수 있다며 진행하자고 했다. 그리고 다들 동의해준 후, 빠~르게 개발 후 api 명세서를 작성해 넘겨주었다 >,<

7. 캘린더

생글을 진행하면서 클라이언트가 가장 힘들어했던 부분이자 내가 DB에 테이블 하나를 달력으로 두었던 캘린더 기능..! 다행히도 캘린더는 인터넷 검색을 통해 몇십 년간의 데이터를 받아올 수 있었다. 그리고 한 번 response 잘 못 전달해 여러 api로 통신하기보다는 서버에서 처음 희생(?) 하는 게 낫다고 생각해 모든 캘린더 내 게시글 작성 관련 날짜 기능은 다 서버에서 처리해서 넘겨주었다. 따라서 달마다 매일매일 유저가 작성한 해당 날짜별 글감 사용 수를 넘겨주었고, 아래에는 주별 달성률을 프로그레스 바로바로 쓸 수 있게끔 다 계산해서 넘겨주었다. 이를 진행하면서 내 머릿속에서도 기능 구현이 여러 번 그려져 💫내 두뇌도 말랑말랑 해지는 느낌💫이었다 ㅎㅎ

8. 명예의 전당

서버 개발 기준 sql 쿼리 문의 길이가 상당 했던 부분..ㅎㅎㅎ.. 쿼리문이 길다고 좋은 것도 아니지만 날짜 비교도 하면서 지난 글감이 아니라 '어제'의 글감 기준으로만 명예의 전당 기능을 구현해야 했기에 상당한 길이의 쿼리문으로 진행했다. 사실 쿼리를 짜면서 이런저런 시도를 많이 해보았다. 바로 아래의 사진이 최종 쿼리문이다. 실제 실무에서는 이런 쿼리가 자주 쓰일까?라는 궁금증이 들기도 했다..! 이렇게 금, 은, 동 명예의 전당 기능을 끝냈다❗😱 

 

명예의 전당 쿼리문

 

9. 푸시 알림

내 첫 푸시 알림..! 사실 마루에서 해보았지만 완전한 내 담당이 아니었기에 흐름만 알고 있었다. 따라서 실제 구현하기는 생글 푸시 알림이 처음이다. 알림은 총 3개의 알림으로 분류된다. 명예의 전당, 동기부여, 좋아요 알림이 있다. 푸시 알림을 구현하면서 firebase를 연동했는데 fcm 알림의 한계(?)💥를 느꼈다... 토큰 리스트에 여러 토큰이 해당되어도 어떤 유저는 알림을 못 받기도, 어떤 유저는 30분 후에 받기도 했다. aws 프리티어의 한계인지, firebase의 한계인지 정확한 원인은 찾지 못했다. 개인적으로 유명한 서비스의 블로그에서 깃 헙을 들어가 본 후, 여기는 카카오 api도 사용한다는 것을 알게 되었다. 가끔 나도 이 앱의 알림을 못 받을 때가 있어서 앱을 들어가고 나서야 뒤늦게 알림을 알게 되는 경우가 꽤 있다. 도대체 무엇이 문제일까.. 하지만 무예산 프로젝트인 우리 입장에서는 유료 서비스는 지양하고 있기 때문에 이 문제가 커진다면 다른 해결방안을 찾아봐야 할 것 같다..ㅠ 현재는 이렇게 알림이 날아온다..! 물론 글감은 테스트용으로 마구마구 집어넣어서 실제 글감은 아니다. 실제 글감은 더 고퀄로 찾아오겠어요 ㅎㅎ!

 

생글 푸시 알림 구현

 

 

10. 활동 배지

활동 배지는 머릿속에 당근 마켓 배지를 생각해보면 될 것이다. 활동 배지라는 단어가 쉽게 와 닿지 않을 것이다. 일러스트도 너무 귀엽고 이쁘지만 아직 보안상 자랑할 수 없기에 이 정도로 연상해달라고만 말하는 게 너무 아쉽다ㅠ😭 배지를 구현하면서도 고민이 깊었다. 실시간 웹소켓 통신을 해야 하나.. 왜냐하면 우리는 배지를 받을 상황이 되면 바로 뷰에 띄워주는 것이 목표였기 때문이다. 그러나 조금만 생각을 바꿔보면 소켓이 아닌 rest api로 response를 줄 때, 잘 맞춰 주기만 하면 되는 것이었다. 그렇게 18개의 배지를 구현하였다. 여기서 스스로가 느꼈다. 예전 같았으면 포기하거나 소켓을 미친 듯이 공부하는 대신 시간 안에 완성을 못하거나 했겠지만 지금은 이렇게도 저렇게도 생각해보고 최선의 선택을 할 수 있게 되었다는 것을...! (나름 뿌듯해) 그리고 한 번은 이러한 기능을 가진 당근 마켓 개발자에게 다짜고짜 연락을 드려 힌트라도 얻고 싶었고 배우고 싶었다. 물론 다 배우는 것이 아니라 토픽을 던져주시면 내가 열심히 공부하는 계획이었다 헤헤.. 하지만, 무례한 행동일 것 같기도 했고 무엇보다 연락처를 알 수 없었던 것이.... ㅠ 아쉽게 고민만 하다 직접 연락을 못 해봤지만 다음번에는 이 기능 구현을 더 나은 방법으로 개발해보고 싶다.

11. 공지사항

이 기능에 대한 회의도 길었다. 공지사항을 1.0 버전에서 보여줄 것인가, 말 것인가. 주로 앱 공지사항이나 배지를 얻었을 때 보여주는 알림뷰다. 클라이언트가 개발할 부분이 많았기 때문에 개발 기간이 늘어나면서 다 할 수 있을 것인가였다. 이 또한 내가 다 data로 보내줄 테니 클라이언트는 간단한 뷰만 만들어달라 했다. 리스트뷰 만드는 데 얼마나 걸리냐 물어보았고, 짧게 걸린다 해서 하기로 결정했다.

12. 회원 탈퇴

마지막으로 회원 탈퇴 기능까지 전부 마무리했다. 탈퇴 기능 만들면서도 우리 앱을 탈퇴하지 말아 주세요ㅠ라는 생각이 들었다.. 여러분 탈퇴하지 말아주세욥!!!! 그만큼 자주 사용할 수 있도록 노력할게요 헤헤😍

13. 관리자 웹 개발

출시를 한다면 당연히 필요한 부분이고, 테스트를 하면서도 데이터를 건드려야 하는 부분이 많았기 때문에 팀원들을 위해 하루를 빠짝 투자했다. 부트스트랩 템플릿을 받아 스프링 부트 첫 웹을 만들어보았다. 간단한 관리자 웹이지만 대시보드를 만들어 보았다. 유저 통계나 앱 내 필요한 통계 부분을 차트들로 나타낸 메인화면과 글감 관리 기능, 유저 관리기능, 공지사항 관리기능 등이 포함된 관리자 웹을 만들어주었다. 디자인은 우리의 생글로 맞춰보았다 ㅎㅎ.. 갓 디자이너의 피그마에서 생글 디쟌 주섬주섬 >,< 타임리프를 이용해보았고 확실히 타임리프가 편했다. 물론 static 폴더 아래가 아닌 templates 폴더 아래에서 실행시키며 오류는 몇 번 겪었지만 값진 경험이 되었다. 다음 웹은 리액트도 배워서 써봐야지!(지금 기초부터 공부하는 중이다) 아직 두 개의 프로젝트 웹 개발이 남았는데 스프링 부트를 쓰면서 다양한 기술 스택을 경험해 볼 것이다. 하루 동안 틈틈이 개발해 만들어서 팀원들에게 전달해 준 후 반응이 좋아서 더 뿌듯했다 헤헤

14. Docker, Jenkins

남들은 이미 예전부터 써왔지만 나는 미루고 미루어 다음번에 해봐야지 다짐만 해보았던 도커,, 사실 윈도우에서 설치했다가 난장판이 되어 포기했었다.. 하지만 지금의 나는 과거의 나와 다르다. 일단 맥북을 사면서 이상한 자신감이 자꾸 든다...ㅎ... 모든 게 다 잘 설치될 것이라는 자신감..ㅎㅎㅎㅎ.. 도커를 EC2에 설치했고 이미지로 빌드시켜 run까지 성공했다. 오히려 도커 실행보다 도커 파일 등 설정에서 시간이 더 걸렸던 것 같다. 도커파일 작성에서 블로그마다 다 내용이 달랐기에 정확한 이해를 하지 못했다. 역시 레퍼런스가 최고.. 그리고 젠킨스는 서버 자동 배포를 해보자!라는 생각에 여러 번 오류 해결 끝에 깃-젠킨스-도커까지 모두 Success! 하지만..........하지만..................나의 ec2 프리티어는 너무 버거운가 보다......... 실제로 실무자분에게 여쭤보니 프리티어는 젠킨스를 감당하기 굉장히 힘들다고 한다. 따라서 실제 릴리즈 때는 어떻게 할지 고민이다. 당장의 서버 비용이 없기 때문.. 이래서 스타트업이 초기 투자금을 받아오나보다,,,,,,,,,,,,,,,,,ㅠ_ㅠ 우리는 사이드 프로젝트라 속상해.... 하지만 일단은 성공해서 여러 번의 실패 끝에 얻은 소중한 경험이 되었기에 행복하다. 나도 해봤다!!!!!!!!!!!! 그리고 역시 너무 간편했다. 내가 짠 코드를 한번 커밋만 하면 내 서버에 자동 배포가 되니 하나하나 들어가서 작동시키고 멈출 일이 확연히 줄었기 때문이다. 이래서 다들 예전부터 썼나 보다.

생글의 모든 서버 개발을 마치고

이 정도면 기업 규모다. 월급달라! 라는 장난을 칠 정도로 끝이 나지 않던 사이드 프로젝트가 드디어 서버 개발을 1차적으로 끝냈다. 하지만! 역시! 끝날 때까지 끝난 게 아니다. 지금 클라이언트가 서버 통신 중인데 예외처리 부분을 다시 수정했다. 그리고 무엇보다 정말 성장한 나를 볼 수 있었다. 아직 부딪혀야 할 내 한계도 많고, 배워야 할 것도, 더 성장해야 할 부분도 정말 많이 남았다.

그래도 스프링 부트를 '생각'만 했던 나는 '실제로 사용'했다. 도커와 젠킨스를 '미루기'만 했던 나는 '실제로 반영'했다. 4개월 간 인턴생활을 하면서 퇴근 후 틈틈이, 주말에 쉬면서도 틈틈이 개발하면서 꼼꼼하지 못했던 부분은 다시 채워나갔고 어려운 기능 개발은 끝까지 포기하지 않고 어떻게든 방법을 찾아나갔다. 개발하면서 실무에서는 어떻게 개발할지 궁금했고 더 배우고 싶어졌다. (물론 인턴을 했지만 대부분 내가 다른 프로젝트에서 한 기술들을 사용해서 새로운 기술 스택도 배우고 싶다ㅠ)

생글은 나에게 가장 기억에 남는 프로젝트가 되지 않을까. 사이드 프로젝트 4개 동시 개발에 인턴까지. 면역력 부족에 대상포진으로 고생했고 출근하다 쓰러지며 난리 났지만 아프면서도 뭐가 그렇게 재밌었는지 😂 꿋꿋하게 진행했던 과거를 되돌아보며 지금도 후회는 없다. 그리고 무엇보다 혼자 서버 개발을 맡으며 DB 설계부터 구축, api 개발, 관리자 대시보드 개발, 클라우드 연동, CI/CD 등 해보고 싶은 기능을 다 사용해볼 수 있었던 흔치 않은 기회를 얻을 수 있어서 정말로 팀원들에게 감사하고 있다. 앞으로 출시하게 되면 유지보수를 하며 더 신경을 많이 써야 하고 관리해야겠지만 이마저도 되게 설렌다. 노력한 만큼 잘 되었으면 좋겠고, 잘 되었으면 하는 바람에 더 노력할 것이다.

출시 후 회고로 돌아오도록 약속하며 또 다른 프로젝트 회고로 돌아올게요!

아직 프로젝트 2개나 더 있어요 ㅎㅎ,, 생글 대박 나자 💙