한 걸음씩 확실하게

저는 어드벤트 캘린더 형식의 크리스마스 익명 편지 서비스인 "Ginger Hotel 🎄"의 2023년 이야기를 적어볼까 합니다.

🛠️ 팀진저의 백엔드에서는 이런 기술 스택을 선택했습니다.

저는 백엔드 개발을 맡아서 진행하게 되었습니다. 가장 먼저 했던 것은 기술 스택을 선택하는 일이었습니다.

팀진저에서 선택했던 백엔드 기술 스택은 Nest.js, Typescript, PostgreSQL이었습니다.

"Java, Spring으로 공부하고 계신데 왜 Node 기반의 기술 스택을 선택하게 되었나요?"

저에게도 큰 도전이었던 것 같습니다. 팀원 한분이 풀스택으로 참여를 희망하셨어서 Front-End 개발팀에서 선택했던 언어인 Typescript에 맞추기 위함이 가장 큰 이유였습니다.

저도 처음 사용해 보는 기술 스택들이었기 때문에 신중하게 선택을 했었습니다.

Typescript의 경우에는 타입의 안정성을 고려하며 개발할 수 있어서 언어 선택에 있어서는 주저함이 없었습니다.

프레임워크는 Nest.js를 선택했던 이유는 모듈 단위로 나누어 개발을 할 수 있고, 확장성에 있어서도 부족함이 없다고 생각했습니다.

또한 Spring가 굉장히 유사한 구조를 가지고 있어 러닝커브를 빠르게 극복할 수 있다고 판단했습니다.

그리고 개발을 하며 느꼈던 점은 npm에 정말 유용한 라이브러리가 많아서 부족함 없이 개발을 했던 것 같습니다.

마지막으로 데이터베이스는 PostgreSQL을 선택했습니다. 가장 큰 이유는 진저호텔에서는 Member -> Hotel -> HotelWindow -> Letter -> Reply와 같이 굉장히 깊은 연관 관계의 Depth가 있었습니다.

그래서 Join과 같은 연산 처리 능력이 뛰어난 데이터베이스를 고려해야 했습니다. 또한 2022년 진저호텔(편지 약 650만 개)이 가지고 있는 데이터를 무시할 수는 없었기 때문에 대용량 데이터에서 성능이 좋은 데이터베이스를 찾다 보니 Oracle과 PostgreSQL을 찾게 되었습니다.

저희는 클라우드 플랫폼으로 AWS를 사용하기로 결정이 된 상태이기 때문에 라이센스 비용 또한 고려해야 했기 때문에 라이센스 비용이 무료였던 PostgreSQL을 최종적으로 선택하게 되었습니다.

☁️ 팀진저의 클라우드 이야기

제가 이번 프로젝트에서 얻어가고 싶은 경험 중 하나가 "클라우드 플랫폼"을 이용하여 서버를 운영해 보는 경험이었습니다.

그래서 개발보다도 더 많은 시간을 쏟으면서 찾아보고, 적용해보고 했던 것 같습니다.

처음 구성 했던 아키텍처는 위와 같습니다. 구글링을 통해서 구성해 봤던 아키텍처였습니다. (AWS는 맨날 EC2 만 써봐서...)

Application Load Balancer는 부하 분산을 위해 EC2를 증설할 계획을 가지고 있었는데, 그래서 미리 적용해 두게 되었습니다.

여기서 Cloud Front는 본래 용도는 CDN 서버로 자주 사용되는 데이터를 캐시 하여 비용을 줄이는 용도로 많이 쓰인다고 합니다.

하지만, 지금 현재 아키텍처에서는 Cloud Front가 캐시의 역할이 아닌 그냥 AWS Certificate Manager와의 상호작용을 통해 SSL 인증서를 확인해 주는 역할 밖에 하지 않았습니다.

이대로 서비스에 나간다면 Cloud Front를 거치는 비용이 계속 나갈 것으로 판단되었고, 멋쟁이 사자처럼 대학 동아리에서 인연이 있었던 높으신 분께 현재 상황에 대한 피드백을 요청했었습니다.

Cloud Front 제거

얻은 피드백에서는 Load Balancer에서도 AWS Certificate Manager와 상호작용할 수 있는 방법이 있다는 것이었습니다.

[aws] ELB Application Load Balancer를 이용한 SSL 설정

이렇게 되면 기존 Cloud Front를 떼어내서 아키텍처가 가벼워지고, Cloud Front에서 과금될 비용들을 다른 곳에 쓸 수 있게 되기 때문에 바로 적용하게 되었습니다.

Cloud Front를 떼어내고 난 후의 아키텍처입니다. 생각보다 빠르게 떼어낼 수 있었습니다.

비용도 줄이고, 서버 아키텍처가 더 간결해지고, 깔끔해질 수 있었습니다! ✨

CI/CD 파이프라인에 Docker 적용

기존에는 CI/CD 과정에서 Github Actions로 EC2에 접근하여 미리 적어둔 스크립트를 실행시키도록 해두었습니다.

즉, EC2에서 프로젝트 build 작업까지 하다 보니 인스턴스에 부하가 모이게 되는 것 같았습니다.

그래서 Docker Image를 이용하기로 했습니다.

관련된 내용은 따로 글에 정리를 잘해뒀습니다. 

https://hoonsb.tistory.com/98

EC2 인스턴스 추가, RDS Multi-AZ 다중화 배포 적용

진저호텔 서비스를 운영하는 데 있어서 가장 중요하게 여겼던 것은 2가지가 있습니다.

1. 사용자들이 주고받은 편지를 안전하게 보관하자!
2. 사용자들이 서비스를 이용하는 과정에서 끊기지 않도록 중단 없이 확장할 수 있는 서버를 만들자!

먼저 서버 중단 없이 기능을 확장하고, hotfix를 처리하기 위해서 EC2 인스턴스를 추가하여 Load Balancer의 대상 그룹에 추가했습니다.

이렇게 구성하고, 하나의 서버에 배포 변경 사항을 적용하고 Health Check가 통과되었을 때, 다른 하나의 서버를 배포하게 되었습니다.

이렇게 진저호텔은 12월 한 달간 한 번의 서버 중단 없이 서비스를 유지할 수 있었습니다.

그다음은 데이터 백업입니다. 기존 RDS는 Single-AZ로 하나의 Availability Zone을 사용했기 때문에 데이터 백업 중에는 데이터베이스가 중단된다는 문제점이 있었습니다. 중단 없이 백업할 수 있는 방법은 없을까 방법을 찾다가 AWS RDS에서는 "Multi-AZ 다중화 배포" 옵션을 제공했고, master DB와 standby DB가 있어서 백업의 경우에는 standby에서 진행되어 master DB는 계속 중단 없이 사용할 수 있게 됩니다. 또한 master DB에 문제가 생겼을 때, standby DB가 바로 master로 승격하게 되면 장애 대응에도 신속한 특징을 가지고 있어 운영 환경에서는 적용하게 되었습니다.

이렇게 변경한 후의 아키텍처는 다음과 같습니다.

서버 인스턴스의 상태를 모니터링하자.

이 부분은 운영 환경에서는 필수라고 여겨지는 부분이라 현재 팀진저에서 소통 수단으로 쓰고 있던 Discord의 Web Hook과 AWS의 CloudWatch를 연동하여 사용하기로 결정했습니다.

서버 모니터링이 중요했던 이유는 RDS의 경우 만약 쿼리 병목이나 슬로우 쿼리가 발견되어 과도한 부하가 걸리게 되거나, 요청에 대한 처리 속도가 늦어지게 되는 경우를 조기에 발견하고 대응해야 된다고 생각되었습니다.

그래서 CloudWatch에 EC2, ALB, RDS에서 감지할 옵션들의 임계값을 설정하고, 임계값을 넘어선 경우에 AWS SNS를 통해 AWS Lambda에서 Event를 받아 Discord로 알림을 바로 줄 수 있도록 구성했습니다.

이렇게 서버 인스턴스 모니터링 과정을 거치게 되면 다음과 같은 메시지(경보)를 Discord에서 확인하고, 바로 대응할 수 있습니다.

제가 무적 짱짱맨이어서 24시간 안 자고, 계속 서버만 모니터링할 수 있다면 좋았을 텐데 저는... 무적 짱짱맨이 아니기 때문에 다른 팀원들의 눈과 귀를 빌리고자 Discord를 적극적으로 사용하게 되었습니다.

✉️ 편지, 답장 차단 프로세스에 대한 고민

작년에 편지 차단에 대한 피드백이 굉장히 많았었습니다. 그래서 올해는 편지 차단 기능에 힘을 많이 쓰게 되었습니다.

차단 기능에 있어서 익명 편지 서비스이다보니 편지를 보낸 사람이 누구인지 특정할 수 없도록 하는데 고민을 많이 했었습니다.

고민 했었던 부분은 한 명이 여러 닉네임으로 편지를 보냈을 때의 상황이었습니다. 위 예시를 보면 "헤르미온느"와 "론"으로부터 받은 편지가 있습니다. "헤르미온느"와 "론"은 모두 훈섭이라는 사람이 보낸 편지입니다.

만약 기존에 생각하고 있던 프로세스로 편지를 받은 철수가 훈섭을 차단했을 때, block_history 테이블에 차단한 사람은 철수, 차단당한 사람은 훈섭으로 하게 되었을 때 아래와 같은 고민이 있었습니다.

철수가 "헤르미온느"를 차단했는데, "론"에게 받은 편지도 차단된다면, 철수는 "헤르미온느"와 "론"이 같은 사용자라는 것을 유추할 수 있게 됩니다. 그래서 차단 프로세스에서 차단 횟수를 넣게 되었습니다.

각 편지는 별개로 차단을 할 수 있고, 발신자에 대한 차단을 횟수로 관리하여 편지 차단을 진행합니다. "헤르미온느"에게 온 편지를 차단하면 차단한 사람은 철수, 차단당한 사람은 훈섭 그리고 차단 횟수가 1이 됩니다. 이렇게 되면 훈섭은 철수에게 편지를 보낼 수 없고, "헤르미온느"에게 온 편지를 차단했을 때, "론"에게 온 편지에는 어떠한 영향도 주지 않기 때문에 "헤르미온느"와 "론"이 같은 발신자라는 것을 유추할 수 없게 됩니다.

반대로 차단을 해제하게 되면 차단 횟수는 감소하게 됩니다.

"론"에게 받은 편지에 대한 차단을 해제했을 때는 아직 훈섭(헤르미온느)에게 받은 편지를 차단한 상태이기 때문에 훈섭에게는 편지와 답장을 받을 수 없습니다.

"헤르미온느"에게 받은 편지까지 차단 해제를 하면 철수가 훈섭을 차단했던 횟수가 0이 되기 때문에 해당 데이터는 사라지게 됩니다. 이제는 훈섭이 철수에게 편지를 보낼 수 있게 됩니다.

대부분 인프라 관련된 클라우드 이야기였지만, 제가 프로젝트를 진행하며 느꼈던 내용과 왜 이런 결정을 했는지에 대해서 기록해두고 싶어서 정리하게 되었습니다.

여기까지 2023년 진저호텔의 백엔드 개발 이야기를 풀어봤습니다. 🎄

스터디를 시작한 이유

스터디를 시작했었던 가장 큰 이유는 CS 공부를 하는 데 있어서 어느 정도의 강제성이 필요하다고 스스로 느꼈고, 마침 활동하고 있는 디프만에서 인프런 강의를 이용한 "인프런 스터디"를 모집하고 있어서 바로 관심 버튼 꾹 눌렀습니다.

다른 재미있는 강의들도 많았는데, 그중에서 지금 당장 저에게 유용하고 공부를 해도 해도 항상 부족하다고 느껴졌던 CS 스터디였습니다.

CS 강의는 인프런에 있는 개발남노씨님의 "기출로 대비하는 개발자 전공면접 [CS 완전정복]" 였습니다.

커리큘럼을 봤을 때, 자료구조, 운영체제, 데이터베이스, 네트워크의 핵심적인 부분들을 깔끔한 예시 영상을 통해서 정리해 주시는 거 같았습니다. 12월 31일까지 계획된 스터디에서 1주에 1개의 과목씩 해결한다고 생각했을 때는 가장 적당했던 강의라고 생각됩니다.

쿠폰이 50%까지 할인이 되었는데, 할인받아서 강의를 구매했습니다.

스터디 방식은?

스터디원은 총 7명이 모였고, OT를 진행하며 스터디 방식, 규칙에 대해서 정하는 시간을 가졌습니다.

1. 일주일에 한 과목(자료구조, 운영체제, 데이터베이스, 네트워크)씩 강의를 듣고 개인적으로 정리해 보기.
   • 정리해 둘 수 있는 노션 페이지를 따로 만들어서 진행했습니다.
2. 해당 과목에 대한 예상 질문 만들기
   • 최대한 다른 사람의 질문과 겹치지 않도록 하고, 최소한 2개씩은 만들어오기로 정했습니다.
   • 스터디를 매주 월요일 오후 9시 비대면으로 진행되었고, 내용 정리 + 예상 질문은 매주 목요일 오후 10시까지 만들기로 정했습니다. (만들어진 예상 질문을 스터디원 중 한 분이 매우 공정한 방법(사다리 타기)을 이용해서 담당자를 분배했습니다.)
   • 여기서 어느 정도의 강제성을 주기 위해서 인당 40,000원씩 모아서 매주 정한 규칙을 지키지 않았을 때 10,000원씩 차감하기로 규칙을 정했습니다.
3. 매주 월요일 이전까지 질문 답변 담당자는 자신이 맡은 질문에 대한 대답을 작성합니다.
4. 매주 월요일 오후 9시에 비대면으로 게더 타운에서 모여 스터디를 진행합니다.
   1. 모두 모이면 서로 오늘 있었던 일이나, 가벼운 스몰 토크로 체크인을 진행했습니다.
   2. 맡았던 질문들에 대한 답변과 추가적으로 준비한 꼬꼬무(꼬리에 꼬리를 무는) 질문에 대해서도 발표를 합니다.
   3. 준비해 온 답변에 궁금한 점이나 보충할 부분에 대한 피드백을 진행합니다.
   4. 모든 스터디가 끝나면 오늘 스터디는 어땠는지에 대한 응답으로 체크아웃을 진행하고 마무리했습니다.

위와 같은 과정으로 스터디를 진행했습니다.

스터디 후기

1주차에는 서로 어색한 분위기를 풀고, 서로의 소소한 스몰토크(?)도 하면서 분위기를 풀고 스터디 규칙을 만들었습니다.

각자 주차에 정해진 강의를 듣고, 강의 내용을 정리하는 과정에서 궁금했던 부분도 많이 찾아볼 수 있었고 알았던 부분은 다시 한번 리마인드 해서 좋았고, 가볍게 알고 넘어갔던 부분들은 보충하는 시간을 가질 수 있었습니다.

서로 준비해 온 질문에 대한 "질문자"와 "답변자"를 정해서 노션에 페이지를 하나 만들어 답변을 준비했습니다.

먼저 팀원분들이 너무 적극적으로 참여해 주셨고, 서로 말하지 않아도 꼬꼬무 질문을 스스로 만들어서 준비해 왔던 것이 너무 좋았습니다.

서로 꼬리까지 물어가며 적극적으로 참여를 했고, 네트워크를 마지막으로 2024년 1월 2일에 스터디를 종료했습니다!

처음에 벌금으로 모았던 돈으로 추후 대면 일정이 있을 때, 커피나 밥을 먹기로 하고, 이제 2월까지 마무리해야 하는 각자 팀의 프로젝트가 있기 때문에 거기에 집중하기로 했습니다.

이렇게 강의에서 제공해 주는 질문들도 충분히 도움이 되지만, 서로 공부하고 고민하면서 모았던 질문들도 소중한 자산이 된 것 같습니다.

물론 계속해서 공부해야겠지만, 앞으로 할 공부에 큰 도움이 되지 않았을까 하는 마음으로 스터디를 마무리하게 되었습니다.

디프만을 선택한 이유

이번에 백엔드 부트캠프를 마무리하고, 지금까지 배웠던 기술 스택을 종합해서 프로젝트를 만들어 보고 싶다는 생각을 했습니다. 그리고 내가 만든 서비스를 런칭해보고 싶다는 생각을 많이 했었는데, 디프만에 들어오시는 분들 대부분이 같은 목표와 열정을 가지고 있다고 생각을 했습니다. 

13기 때 디프만을 알게 되었었는데, 그때는 사실 "넣어도 떨어지겠지..?"라는 생각으로 도전 조차 못해봤었습니다. 백엔드 부트캠프에서 Java, Spring을 학습하고, 프로젝트도 참여해 보면서 사실 자신감도 많이 얻었던 것 같습니다. 부트캠프에서도 열정적인 분들과 만나서 치열하게 고민하고, 프로젝트를 했던 경험이 너무 의미 있었습니다. 그래서 지금까지 배운 지식들을 가지고, 새로운 개발자, 디자이너분들과 함께 서비스 런칭을 목표로 프로젝트를 진행해 보는 것도 너무 의미있고, 재미있을 거 같아서 디프만을 선택하게 되었습니다. 😄

서류 접수

서류 접수는 10월 2일부터 8일까지 진행되었습니다. 저는 13기 때 디프만을 알게 된 후로 멀리서 쳐다보고 있어야지 하는 생각으로 디프만 인스타 공식계정을 팔로우하고 있다가 14기 모집 소식을 알게 되었습니다.

문항은 총 8개 정도였는데, 마지막 2개는 깃허브 링크와 포트폴리오 링크여서 작성해야 하는 문항은 6개 정도입니다. 저는 2일 날 서류 접수 소식을 바로 알아서 조금 여유 있게(?) 진행했던 거 같습니다. 막판에는 여유가 없었습니다. 🙀

저는 노션을 많이 활용하는 편이어서 질문을 모두 노션에 옮겨적고, 문항들을 채워나가기 시작했습니다. 부트캠프를 바로 마무리한 후에 지원을 하게 되어서 쓸 말이 너무 많았습니다. 그래서 문항을 읽고 흐름대로 일단 작성을 한 것 같습니다. 제출하기 전에 계속 검토를 하고... 검토를 하고... 검토를 하다가 제출을 하게 되었습니다. 문항은 지원동기, 프로젝트 협업 경험, 자신있는 기술 스택에 관련된 문항들이 있었습니다.

그렇게 서류 마감 후 10일 정도 있다가 메일이 하나 왔습니다. 메일 제목은 "디프만 14기 서류 결과 안내"였습니다. 

서류 합격 메일을 받고, 바로 4일 뒤인 22일 날 면접을 봐야 했었기 때문에 조급해하면서 여기저기 막 구글을 찾아 나서기 시작했습니다. 

온라인 면접 준비

뭘 물어보실지 모르기 때문에 면접은 항상 긴장되고, 무서운 것 같습니다. 서류 결과가 나오고 하루 정도 있다가 면접과 관련된 메일이 하나 도착했습니다.

면접은 Zep이라는 가상 공간에서 진행됐습니다. 면접 날짜는 서류 접수 당시에 선택할 수 있었던 거 같습니다. 저는 일요일이 모든 시간이 널널했기 때문에 22일을 선택했었습니다. 저는 13시 30분에 면접을 30분 동안 봐야 하는 사람이 되었습니다. 덜덜덜 🥲

진짜 인터넷에서 찾을 수 있는 디프만 면접 관련 링크는 다 확인해봤던거 같습니다. 이전 기수분들이 블로그에 많이 작성을 해두셔서 도움이 많이 되었습니다.

저는 4일이라는 기간동안 어떻게 준비해야 할까 하다가 서류에 작성했던 내용을 집중적으로 먼저 확인을 하자는 목표를 세웠습니다. 후기들을 많이 참고하긴 했는데, 기술 질문 관련 내용들은 후기마다 많이 달랐던 것 같습니다. 그래서 "내가 써본 것 중에서 여쭤보실 것이다!"라는 결론을 내리게 되었습니다.

그래서 관련해서 적었던 기술들, 프로젝트에서 썼던 기술들을 위주로 준비를 했던 것 같습니다. 제가 서류에 자신 있는 기술에 QueryDSL을 썼었습니다. 가장 최근에 마무리했던 프로젝트에서 복잡한 쿼리를 많이 다뤘어서 QueryDSL과 완전 친구를 먹었어서 썼던 거 같습니다.

그래서 프로젝트에서 사용했었던 DB(MySQL), JPA, QueryDSL, Spring, Java, AWS, CI/CD 위주로 기술 질문을 준비했습니다. 혼자 내가 면접관이면 나한테 무슨 질문을 할까라는 생각을 하면서 질문을 만들어 스스로 답변을 했습니다. 하나 하나 다 적고 나니 너무 많아서... 사실 모두 답변을 준비하지는 못했습니다.

온라인 면접 당일

일요일날 아침 7시 40분에 일어나서... 어제 보다가 잠든 질문들을 한번 다시 쓱 봤습니다. 면접은 다대다 면접이었고, 같은 파트 사람들끼리 면접을 진행합니다. 같이 보는 인원은 2명에서 3명이라고 되어있었습니다.

저는 면접관님이 두 분이셨고, 면접자는 저를 포함해서 2명이었습니다. 기본적인 질문들을 해주시는 면접관님 한 분과 기술 질문을 담당해 주시는 면접관님이 계셨습니다.

기본적으로 자기소개를 시작으로 해서 각자 위치에 맞는 질문을 해주시는 것 같았습니다. 저는 취준을 하고 있었기 때문에 취준과 병행이 가능한지에 대해서 여쭤보셨었습니다. 아무래도 팀을 이뤄서 2월까지 프로젝트를 마무리하는 동아리이기 때문에 "이 사람 끝까지 포기하지 않고 할 수 있는 사람인가?"를 확인해보시기 위한 질문이 대부분이었던 거 같습니다. 편하게 질문을 이어가주셔서 되게 좋았습니다. 😄

이제 대망의 기술 질문이 시작되고, 심장이 요동쳤었는데 커피챗한다는 느낌으로 참여해 주시면 좋을 거 같다고 말씀을 하시고 시작했습니다. 기술 질문은 공통 질문이 없었고, 각자 사용해 보거나 자신 있다고 적었던 기술 스택 위주로 질문을 주셨습니다. 저는 QueryDSL을 적었어서 관련된 질문을 많이 받았습니다. 그 외에도 DB, JPA 위주의 질문을 해주셨습니다. 준비한 것 외에서 나온 것도 몇 개 있었는데 프로젝트하면서 알게 된 내용 위주로 답을 했습니다. 사실 뭐라고 대답을 했는지도 긴장하고 있어서 기억이 안 났습니다. 기술 질문에서 제가 느꼈던 것은 "이 기술을 쓴 이유가 있는지? 제대로 알고 프로젝트에 사용한 것이 맞는지?"에 대해서 확인을 하시려고 했던 것 같습니다.

그렇게 30분을 순삭하고, 나와서 유부 초밥을 왕창 먹었습니다. 디프만 사이트에는 최종 합격은 10월 31일 날 나온다고 쓰여 있어서 이제 기다림의 시간만이 남았습니다.

최종 발표

최종 발표 메일은 10월 29일날 왔습니다. 제가 언제부터인가 메일을 거의 카톡처럼 확인하는 습관이 생겨서 계속 수시로 보다가 저녁에 메일을 확인하게 되었습니다.

진짜 확인하고 나서 진짜 붙은건가 진짜인가 이러면서 확인을 했었습니다. 디프만 13기 때 쳐다만 보다가 14기에 이렇게 붙으니 진짜 기분이 묘했습니다. 개발직군 경쟁률은 10.7대 1이라고 인스타그램에 나와있어서 기분이 뭔가 좋았습니다. 😁

디프만에서 이제 2월까지 활동을 하게 되었는데, 중간중간 회고를 작성해 볼 생각입니다. (계획은...항상 거창하게)

3월부터 시작해서 벌써 7개월이 지나 마지막 날이 되었습니다. 짧다고 하면 짧고, 길다면 길 수 있는 시간이 지났습니다.

"10월이 되면 조금 성장해 있을까?"라는 생각을 하면서 부트캠프에 참여했던 거 같습니다.

7개월 동안 부트캠프에서 진행했었던 프로젝트의 과정을 기록해보려고 합니다.

첫 번째 프로젝트

첫 번째 프로젝트는 개인 프로젝트였습니다. Java만을 이용하여 콘솔로 입력을 받고, 콘솔에 출력을 하는 "스마트 스토어"를 만드는 프로젝트였습니다. 이 프로젝트에서는 List, Map, Set과 같은 컬렉션 프레임워크의 사용이 금지되었습니다. 즉, 사용할 거면 직접 구현해서 사용했던 프로젝트입니다. 평소에 편리하게 그냥 가져다 쓰던 List, Map, Set 등 편리한 컬렉션들이 어떻게 작동되는지 느껴볼 수 있었던 프로젝트였습니다.

다른 부트캠프에 비해서 제가 참여했던 패스트캠퍼스에서는 Java 언어 수강 기간이 꽤나 큰 비중을 차지했었습니다. 강사님의 강의는 대부분 라이브 코딩을 통해서 진행되었고, 중간에 받은 질문이나 오류들을 같이 트러블 슈팅하며 꽤나 깊은 영역까지 확인해 보며 학습할 수 있었던 거 같습니다. 하지만, 트러블 슈팅에 시간을 많이 쓰셔서 진도를 제시간에 나가지 못하는 경우도 꽤나 있어서 불만이 있는 수강생분들도 있었던 것으로 기억합니다. 저는 개인적으로 문제 해결 능력을 기를 수 있었던 재미있는 수강 시간이었던 것 같습니다.

두 번째 프로젝트

두 번째 프로젝트는 "야구관리 프로그램"이었습니다. Java와 JDBC 그리고 Database(MySQL)를 이용하는 토이 프로젝트였습니다. 데이터베이스 설계에 대한 이론 강의를 진행한 후에 프로젝트가 진행되어 직접 요구사항에 대한 데이터베이스 설계를 해 볼 수 있었습니다.

경기장, 팀, 선수, 퇴출 선수에 대한 테이블을 설계했고, 요구사항에 맞게 비즈니스 로직을 Service에 구현했습니다. 두 번째 프로젝트에서는 두 명이서 팀을 이뤄서 진행한 첫 번째 팀 프로젝트였기 때문에 Github Commit Message Convetion을 정하고, Pull Request를 이용해서 Rebase Merge를 하는 방식으로 프로젝트를 진행했습니다. 야구 관리 프로그램을 진행할 때, 패키지 설계에 대한 고민도 했었습니다. 이때는 기능을 기준으로 db, dto, model, service, view 이렇게 패키지를 분리해서 작업을 했었습니다.

독학할 때, 유튜브로 봤었던 최주호 강사님이 데이터베이스 수업을 맡아주셨었는데 수업을 하실 때 적절한 비유를 통해서 이해를 쉽게 할 수 있도록 도와주셨던 것 같습니다. Index에 대한 개념, Index는 언제 사용하면 좋을지, OneToOne, OneToMany, ManyToOne, ManyToMany 등 여러 가지 의존 관계에 대해서 배울 수 있었습니다. 지금까지도 유용하게 잘 사용하고 있는 지식들입니다.

https://github.com/khsrla9806/fastcampus-toyproject2

세 번째 프로젝트

세 번째 프로젝트는 그 유명한 "게시판" 프로젝트입니다. 드디어 Springboot를 사용하기 시작한 토이 프로젝트입니다. Spring Data JPA와 MyBatis에 대한 이론 강의를 진행한 후 프로젝트가 진행되어 요구 사항에서는 사용자 서버는 Spring Data JPA를 이용하고, 관리자 서버는 MyBatis를 사용하라는 요구 사항이 있었습니다. 백엔드 팀원끼리 진행했던 프로젝트였기 때문에 View는 Thymeleaf와 Bootstrap를 이용하여 Server Side Rendering을 했습니다.

세 번째 프로젝트에서 사용자 서버와 관리자 서버를 따로 분리해서 API 통신을 할지 아니면 멀티 모듈로 구성해서 Entity들을 공유하여 사용할지 결정해야 했었습니다. 관리자의 기능은 사용자 기능이 완료된 후에 함께 구현하기로 했었기 때문에 프로젝트의 남은 기한을 고려했을 때, 새로운 저장소를 만들어 서버 자체를 분리하는 데는 무리가 있다고 판단하여 멀티 모듈로 사용자는 8080 포트, 관리자는 8081 포트로 분리하기로 결정했습니다.

두 번째 프로젝트에서 유용하게 사용했었던 Github Convention과 Pull Request & Rebase Merge 전략을 그대로 가져와서 새로운 팀원들과 살을 붙여 이용했습니다. 추가로 작업 내용을 Issue화 해서 협업을 진행했습니다. Commit Message에 Issue 번호를 적어서 작성하면 어떤 작업에서 발생된 Commit 내용인지 빠르게 파악할 수 있어서 좋았습니다.

개인적으로 멀티모듈이 생각했던 거보다 구성하는 것이 힘들었고, 패키지 구조가 복잡해지고 내가 찾고자 하는 클래스 파일을 찾는데 힘들었던 것 같습니다. 다음 프로젝트에서 같은 상황이 존재한다면 서버 자체를 분리하고, API 통신을 하지 않을까라는 생각을 하게 되었던 프로젝트였습니다.

https://github.com/khsrla9806/board-project

네 번째 프로젝트

네 번째 프로젝트는 "연차 & 당직 프로젝트"였습니다. 이번 프로젝트는 처음으로 프런트 개발팀과 함께 진행했던 협업 프로젝트였습니다. 처음 진행하는 협업 프로젝트여서 협업 특강을 따로 진행해 주었고, 요구사항도 그렇게 어렵지 않고 간단했습니다.

처음 하는 협업 프로젝트여서 지금까지 했던 방향과는 다르게 진행했습니다. 싱크업 미팅을 가진 후 프런트엔드 팀과 함께 먼저 주어진 기획을 가지고 와이어프레임을 작성했습니다. 와이어프레임을 함께 작성했던 이유는 요구 사항도 많지 않았고, 서로 생각하고 있는 개발 방향을 맞추기 위해서였습니다. 같은 기획서를 가지고, 다른 방향으로 충분히 생각할 수 있기 때문에 의견을 맞추는 것이 우선 되어야 한다고 생각했습니다.

와이어프레임을 작성한 후 백엔드 팀원끼리 모여 ERD 설계를 진행하고, API 명세서도 프런트 엔드 팀원분들과 함께 작성했습니다. 둘 다 처음 하는 협업이어서 어떤 Request를 받고, 어떤 Response를 줘야 할지에 대해서 의논했습니다. 처음 했던 협업 치고는 순탄하게 진행되었던 거 같습니다.

이번 프로젝트에서 새롭게 해 볼 수 있었던 것은 AWS Lightsail과 FileZilla를 가지고, 서버를 실제로 배포해 보는 경험을 해볼 수 있었습니다. 그리고 클라이언트 서버(HTTPS)와의 통신을 위해서는 SSL 인증서를 발급받아 도메인을 구매한 후 연결을 했어야 했습니다. 도메인은 가비아에서 저렴하게 구입했고, LetsEncrypt를 이용하여 인증서를 발급하고, application.yml에 설정을 추가해 줌으로써 프로젝트를 진행할 수 있었습니다.

https://github.com/khsrla9806/mini-annual-work-project

다섯 번째 프로젝트

다섯 번째 프로젝트는 "기업연계" 프로젝트였습니다. 지금까지 했던 4개의 프로젝트는 이 파이널 프로젝트를 위한 발판이라고 할 수 있습니다. 진행되는 과정은 연계된 기업의 대표분들이 직접 어떤 설루션을 해결해줬으면 하는지, 어떤 프로젝트를 진행하고 싶은지를 말하는 시간을 갖고 나서 1 지망, 2 지망, 3 지망 선택했습니다. 같은 기업을 선택한 사람들끼리 랜덤으로 팀이 구성되었습니다. 거의 모든 사람이 1 지망에 선택했던 프로젝트를 진행하셨던 거 같습니다. 기업연계 프로젝트는 PM, UX/UI도 합류를 하기 때문에 소통이 매우 중요했던 프로젝트였습니다.

패스트캠퍼스의 모든 프로젝트를 진행하며 조금 아쉽다고 생각되었던 부분이 팀을 랜덤으로 정해준다는 것이었습니다. 참여 점수, 성적 등을 고려하여 팀을 배정해 준다고는 하지만, 5~6개월이 지나는 동안 어느 정도 함께 해보고 싶은 사람들이 있다고 생각이 됩니다. 뭐 누구를 만나든 최선을 다해야 하는 것은 맞지만, 열정이 비슷한 사람들끼리 팀을 이루면 그 시너지 효과가 더욱 클 것이라고 생각되었기 때문입니다.

하지만, 불만과는 다르게 파이널 프로젝트에서 만났던 팀원분들은 열정이 넘치고, 오프라인 강의장까지 출석하시면서 함께 진행했습니다. 마지막 프로젝트이기 때문에 함께 이루고 싶은 팀의 공동 목표를 정했던 것 같습니다. 저희 팀에서 정한 공동 목표는 배포 자동화(CI/CD) 환경 구성, 테스트 커버리지 50% 이상 유지가 있었습니다.

실제로 프로젝트에서 Github Actions와 SSH를 이용하여 배포 자동화 환경을 구성했고, 테스트 커버리지는 57%를 달성했습니다. 그리고 새롭게 Java Code Convention도 정했습니다. 이때 나온 컨벤션이 거의 15개... 모두 다 지키지는 못했지만, 컨벤션을 정하는 과정에서도 배움이 있었습니다. 추가로 이번에는 Gitflow 전략을 도입하고, Rebase Merge 전략이 아닌 Squash Merge 전략을 사용했습니다. Squash Merge 전략을 사용한 이유는 하나의 작업에서 발생하는 Commit을 세분화하다 보니 너무 많은 Commit이 생겼고, 오히려 해당 작업을 추적하기가 어려워졌었습니다. 그래서 Squash Merge를 사용해서 세분화된 Commit들을 하나의 Commit으로 합쳐서 효과적으로 커밋을 관리하고, 가독성을 높일 수 있을 것이라고 생각했습니다.

https://github.com/livable-final/server

마무리 회고

처음에는 Github를 Push, Pull 정도만 이해하고 사용했었습니다. 프로젝트를 거치면서 Pull Request도 사용해 보고, 충돌을 해결하기 위해서 Rebase도 사용해 볼 수 있었습니다. 더 나아가 Issue를 적극적으로 사용하게 되었고, 마지막에는 Organization을 생성하여 Client와 Server를 함께 관리하고, 상황에 적절한 Gitflow 전략과 Merge 전략을 선택해서 사용할 수 있을 정도로 성장을 했습니다.

프로젝트를 진행하며 점점 필요에 의해서 기술을 학습했던 거 같습니다. 사실 패스트캠퍼스에서 제공되었던 실시간 강의는 개인적으로 조금 부실하다고 느껴졌었습니다. 글씨가 너무 작거나 짧은 시간에 너무 많은 정보를 제공하려고 해서 너무 복잡했던 거 같습니다. 그래서 달마다 지급되었던 지원금을 모아서 인프런에서 김영한 님의 강의를 구매해서 수강했었습니다. 필요하다고 생각될 때마다 HTTP 강의, Spring 강의, JPA, QueryDSL, MVC 모두 구매해서 수강하고, 바로 진행하고 있던 프로젝트에 활용해 보며 학습했습니다.

다음에 프로젝트를 진행한다면 Docker를 사용해서 배포환경을 구성해보고 싶습니다. 그리고 파이널 프로젝트에서 잠깐 사용했었던 JMeter를 조금 심오하게 사용해서 성능 개선도 해보고 싶다는 목표가 생겼습니다. 지금까지 프로젝트에서 문서화를 할 때 접근하기 좋았던 Notion을 주로 사용했지만, Swagger를 사용하여 API 문서화를 진행해보려고 합니다. 무조건 한다. 👊🏻

결국에는 스스로 하지 않고 가만히 있으면 가마니가 됩니다. 어느 곳을 가던 하는 만큼 얻어갈 수 있다고 생각합니다. 제가 열심히 하고, 열정적으로 참여하면 주변 사람들도 그런 사람들로 채워졌던 거 같습니다. 비전공자로 개발을 시작했지만, 10개월 동안 좋은 사람들과 함께 진행할 수 있어서 좋았던 활동이었다고 말할 수 있을 거 같습니다.

저번에 9주 차 회고를 작성했었는데, 벌써 5주가 지나서 14주 차가 되었습니다. 허허 가볍게 회고록을 작성해보려고 합니다.

🙋🏻‍♂️ Database/Spring 실시간 강의 시작

저번 Java 수업이 끝나고 이제 Database와 Spring 실시간 강의를 시작했습니다. 혼자서 Spring 공부해 볼 때 최주호 강사님이 운영하는 메타코딩이라는 유튜브 채널에서 공부를 한 적이 있었는데, 이번 Spring 실시간 강의 강사님으로 오셔서 약간 기대가 되었습니다.

지금 벌써 강의를 시작한지 몇 주가 지났는데, 개인적으로 실시간 강의 만족도는 매우 높습니다. 모르고 넘어갈만한 내용들을 자세하게 알려주셨습니다. 특히 그림으로 그리면서 적절한 예시를 항상 들어서 설명해 주시는데 이 부분이 만족도가 굉장히 높았습니다.

Database, JDBC, MyBatis 강의를 지나서 지금은 Hibernate와 JPA에 대해서 강의를 진행중인데, 다음 주에는 두 번째 토이 프로젝트가 예정이 되어 있습니다. 간단한 프로젝트이긴 한데 이번에는 2인 1조로 프로젝트가 진행돼서 약간 기대반 설렘반입니다.

🥇 백준 골드 달성

저번 회고 글에서 다음 회고 글에서는 골드가 되어있었으면 좋겠다고 했었는데, 골드를 달성했습니다. 알고리즘 문제는 빠짐없이 매일 1문제씩 백준에서 풀고 있습니다.

골드 구간으로 넘어오고 나서 요즘은 삼성 기출 코딩테스트 구현 문제를 하나씩 건들고 있는데, 확실히 난이도가 높아지고 있는 것을 느끼고 있습니다. 다음 회고 글에서는 플래티넘이 되었으면 좋겠다고 쓰고 싶지만 경험치도 엄청 천천히 오르고 문제는 어려워져서 힘들 거 같습니다. 하지만 목표로 잡은 플래티넘이 되는 날까지 꾸준히 풀어갈 계획입니다.

🧑🏻‍💻 사이드 프로젝트 계획

이 부분은 정규 커리큘럼은 아니지만 팀원 분들과 의견이 맞아서 계획 중에 있습니다. 처음에는 Spring MVC를 공부하면서 Springboot와 Thymeleaf로 백엔드 팀원들끼리만 프로젝트를 진행해보려고 했었는데, 계획을 하다보니 프론트 팀원분들을 모집하게 되었습니다.

완성도 높은 프로젝트를 해보면 좋겠지만, 지금은 앞으로 있을 미니 프로젝트와 파이널 프로젝트를 대비하기 위한 간단한 연습정도로 생각하고 참여해볼 생각입니다. 그렇다고 느슨하게 할 생각은 없습니다. 프로젝트는 프론트 팀원분들이 확정되면 기획을 마무리하고 바로 개발에 들어가 볼 계획을 가지고 있습니다. 다음 회고글에서는 사이드 프로젝트 결과에 대해서 다루고 있을 수도 있겠네요.

지난 3주 차 회고를 작성한 지 벌써 6주가 흘러 9주 차 회고를 쓰게 되었습니다. 준비할 건 많고, 하루는 부족하고... 하루하루가 정말 빠르게 지나가는 것 같습니다.

👋🏻 Java 실시간 강의 종료

9주 차에 회고를 쓰게 된 이유는 Java 실시간 강의가 끝났기 때문입니다. 사실 여러 부트캠프를 보면 Java를 엄청 빠르게 끝내는 부트캠프들이 많은데, 제가 듣고 있는 과정에서는 화요일, 목요일에 Java 실시간 강의를 진행했었습니다.

언어를 너무 오랫동안 하는 거 아닌가에 대한 의문도 있었지만, 강사님이 Java의 상당히 깊은 부분까지 고려하면서 강의를 진행해 주셔서 저는 오히려 좋았던 거 같습니다. 어설프게 알고 있었던 부분들을 확실히 짚고 넘어가는 시간이 됐었습니다.

🥈 백준 실버 달성

이미 골드, 플래티넘이신 분들에게는 가소로워 보일 수도 있지만 실버를 달성했습니다. 골드를 향해서 빠르게 달려가고 있습니다. 😆

3주 차와 비교했을 때 자료구조, 알고리즘 제대로 학습을 한 뒤부터는 문제를 보는 눈이 조금은 달라졌다고 생각합니다. 문제를 읽었을 때, 입력 범위를 보고 나올 수 있는 시간 복잡도를 생각해 보고 어떤 자료구조가 적합할지 고민해 보는 노력을 하고 있어서 그런 거 같습니다.

기존에는 문제를 보면 그냥 바로 코드부터 치면서 시작했었는데, 경험해 보신 분들은 아시겠지만 이렇게 작성하다가 중간에 막히면 정말 답도 없습니다. 코딩 테스트 부분에서는 패스트캠퍼스에서 지정된 멘토님의 영향을 조금 받았다고 생각합니다. 사실 매일 적어도 1문제씩은 풀어보기라는 과제를 내주신 분이기도 하고, 알고리즘 문제 접근법이나 좋은 습관을 형성하는 데 있어서 도움을 많이 받았습니다. 다음 회고 글에서는 골드가 되어있었으면 좋겠습니다. 😄

📖 그룹 CS 스터디

이 부분은 부트캠프 정규 커리큘럼에는 존재하지 않지만, 각자 4명에서 5명으로 지정된 피어 그룹이 있는데, 저희 그룹원들과 따로 진행하고 있는 스터디입니다. 도서는 면접을 위한 CS 전공지식 노트라는 책을 사용해서 하고 있고, 전체적으로 짜여 있는 구성은 좋지만 면접 대비 도서라서 그런지 들어가 있는 내용은 다소 학습을 하는 데 있어서는 부족할 수 있다고 생각됩니다.

하지만 오히려 각자 맡은 부분에 있어서 책에 있는 내용 이외에도 추가적으로 학습해서 정리해서 발표를 진행했어서 부족함 없이 진행하고 있는 스터디라고 생각합니다. 다들 많은 내용을 공유해 주고, 학습하고 싶다는 열정이 있어서 가능한 스터디라고 생각됩니다. 

스터디 규칙은 매주 맡은 부분에 대해서 발표를 하고, 자신이 맡은 부분이 아니어도 해당 내용을 모두 숙지하고 오자는 규칙을 정했습니다. 그리고 따로 Github Organization을 만들어서 레포지토리를 만들고, 각자 정리한 내용을 Pull Request 하는 방식으로 스터디를 진행하고 있습니다.

👥 타 그룹과의 교류

부트캠프 후반부에 협업으로 진행하는 프로젝트가 존재합니다. 그래서 같은 기수에 교육을 듣고 계신 많은 분들과 소통해 볼 수 있는 자리가 있었으면 좋겠어서 저희 그룹 조장님을 앞세워 타 그룹과의 교류를 진행했었습니다.

모든 사람들과 교류해보지는 못했지만 그래도 많은 분들이 참여를 희망하셔서 다양한 분들을 만나볼 수 있었던 시간이 있었습니다. 교류를 하는데 이용했던 시간은 주로 1주일에 2번 존재하는 그룹 활동 시간을 이용했습니다. 

그때의 연이 닿아서 지금은 다른 그룹원분들과 함께 진행하고 있는 발표 스터디도 진행 중에 있습니다. "아니 무슨 스터디를 이렇게 많이 해?"라고 생각하시는 분들도 있을 거 같아서 다른 그룹원분들과 진행하고 있는 발표 스터디는 강제성이 없는 가벼운 스터디로 만들었습니다.

이 발표 스터디는 자신이 한 주 동안 학습한 내용들 중에 궁금했었던 내용이나 공유하고 싶은 내용들을 자유롭게 발표하는 스터디입니다. 발표할 내용이 없으면 굳이 하지 않아도 되고, 가볍게 시작했던 스터디인데 생각보다 다양한 주제를 가져오시는 것을 보고 나름 흥미를 느끼고 있는 스터디입니다.

이외에도 많은 일들이 있었지만 저번 회고글과 조금 달라진 점을 위주로 작성해 봤습니다. 다음에도 작성할 내용이 생기면 회고록 작성하러 달려오겠습니다. 🙇🏻‍♂️