웹 프로젝트 맛집전공 개발 기록
2021.07.05. ~ 2021.08.01.
교내 웹 개발 동아리에서 처음으로 한 프로젝트이자 내 개발자 인생에서 처음으로 진행한 협업 프로젝트였다. 학기 중에 기획을 구체화하고 방학 1달 간 개발에 돌입했다. 백엔드 개발에 사용한 기술 스택에 대해 정리하고, 개발 과정을 회고하며 간단하게 성찰해보겠다.
Spring boot & Gradle 프로젝트 그리고 Spring Data JPA
1. 스프링 부트
Spring은 우리나라 백엔드 개발에서 가장 많이 쓰이는 프레임워크다. 전자정부 표준프레임워크도 스프링을 기반으로 하고 있을 정도. 스프링은 정형화된 패턴과 레퍼런스가 많아 안정적이며 POJO를 기반으로 한다는 것이 장점이지만 설정이 복잡하다는 게 문제였다. Spring boot는 그런 스프링을 더 쉽게 사용할 수 있게 dependency를 버전에 맞추어 자동으로 설정해주며(AutoConfiguration) 톰캣이 내장되어 있어 jar 파일로 손쉽게 배포할 수 있다.
2. gradle
우선 gradle은 빌드를 관리해주는 도구인데, 빌드 자동화를 도와주는 것에는 maven도 있다. 근데 gradle이 스크립트가 더 간결해서 커스터마이징이 훨씬 간편하고, Incremental한 컴파일 방식을 사용하며 Build Cache가 있어서 속도가 훨씬 빠르다. maven을 써온 사람이라면 갈아타는 게 어색하고 꺼려질 수 있겠으나 요즘에는 거의 gradle로 갈아타는 추세라고 한다.
3. Spring Data JPA
Spring Data JPA는 스프링에서 JPA를 더 간편하게 쓸 수 있도록 만든 라이브러리고, JPA는 RDB 테이블을 객체지향적으로 사용하기 위한 기술인 ORM(Object-Relational Mapping) 표준 인터페이스다. 기본적인 쿼리를 자동으로 생성해주기 때문에 객체 중심 설계로 패러다임을 전환할 수 있으며 개발 생산성을 크게! 높일 수 있다. 인터페이스라서 Hibernate같은 구현체가 필요한데 Spring Data JPA를 쓰면 구현 클래스 없이 인터페이스만으로 개발할 수 있고 메서드 이름만으로 쿼리 생성이 가능해서 정말 편리하다 !!
AWS EC2와 RDS, S3 그리고 CloudFront
1. EC2
EC2는 안전하고 크기 조정이 가능한 컴퓨팅 용량을 클라우드에서 제공하는 웹 서비스이다. 한 마디로 AWS에서 제공하는 클라우드 컴퓨팅 서비스이고, 아마존이 구축한 데이터 센터의 서버용 컴퓨터를 임대해 서버로 쓰는 것이다. RDS, S3, VPC 등 다른 AWS 서비스와 함께 사용할 수 있어 통합성이 우수하며 사용자가 인스턴스(가상 서버)를 완전히 제어할 수 있다는 장점이 있고, 안정성과 보안성 및 네트워크 기능이 우수하다. 또한 사용한 만큼만 비용을 지불하는 탄력적인 방식이어서 저렴하고 효율적이다.
free tier에서는 EC2 인스턴스 하나를 한 달에 750시간 이내로 작동시킬 수 있기 때문에 하나의 인스턴스만 돌린다면 한 달 내내 무료로 사용이 가능하다.( 24시간/일 * 31일 = 744시간이므로. 물론 두 개 이상 돌리면 그때부터 과금되기 때문에 주의해야 한다. 나는 이번에 프로젝트 진행하면서 바보같이 전에 했던 개인 프로젝트 인스턴스랑 같이 돌려서 과금 먹었다!ㅎㅎ^^)
2. RDS
RDS란 AWS의 관계형 데이터베이스 서비스이다. EC2에 관계형 데이터 베이스를 직접 구축할 수도 있지만, AWS RDS를 쓰면 얘가 백업과 스케일링, 소프트웨어 패치 등을 관리해주어서 편리하다. 직접 설치하는 방법보다 돈이 더 많이 들긴 하지만 데이터베이스 관리와 운영에 드는 시간을 절약할 수 있어서 좋다.
3. S3
S3는 AWS의 인터넷용 스토리지 서비스다. 웹 서비스 인터페이스를 사용해 간편하게 데이터를 저장하고 검색할 수 있다. 버킷에 저장할 수 있는 객체에 제한이 없어 확장과 축소에 신경 쓰지 않아도 되며 내구성과 가용성이 높고 버킷마다 권한을 설정할 수 있어서 보안이 우수하다. 다만 같은 리전이 아니라면 데이터 전송 시에 요금이 부과된다는 것이 단점이다.
4. CloudFront
CloudFront는 AWS의 CDN(Content Delivery Network, 콘텐츠 전송 네트워크)으로 엣지 로케이션을 일종의 캐시처럼 사용하는 서비스 방식이다. 엣지 로케이션에 콘텐츠가 있으면 CloudFront가 바로 제공하고, 없으면 오리진 로케이션(S3나 웹 서버)에서 콘텐츠를 검색한 후 엣지 로케이션에 추가한다. free tier는 무료로 월 50기가까지 데이터를 송신할 수 있고 HTTP, HTTPS 요청은 200만 건까지 무료로 가능해서 S3와 CloudFront를 연결하여 사용하면 비용을 줄일 수 있다. 또한 객체의 사본이 엣지 로케이션에 위치되므로 안정성과 가용성이 증가하고 콘텐츠 배포 속도가 빨라진다.
이외에도 도메인 연결 시 Route53과 Load Balancer 등을 사용했다! lambda 함수를 사용해 이미지 리사이징도 하려고 하였으나 시간이 없어서 그냥 포기했다.
개발 과정
크게 3가지로 나눌 수 있다.
개발 전 준비 : 협업 규칙(깃허브 커밋 메시지 컨벤션, 프로젝트 구조, 코드 컨벤션) 정하기, DB 구축(개념적, 논리적 모델 설계 및 테이블 생성, RDS 연결)
개발 : 기능 정리(IA)와 역할 분담, API 명세서 작성, API 구현
배포 : 서버에 배포, 도메인 연결, 보안 설정
1-2번 과정에서 느낀 것은.. 디비 설계는 어떻게 해도 수정이 되기 마련이라는 것. 기획도 아무리 꼼꼼히 했다고 자부해도 빼먹은 게 분명히 있다는 것!!!! 과제 다 제출하고 나서야 빼먹은 거 알아서 따로 수정한 기능도 있다ㅋㅋㅋ.. 테이블마다 기본 CRUD 기능이 있는지, 없어도 되는지는 꼬옥 체크하고 넘어가자.
이전에 책 보고 따라할 때 생각보다 배포 단계에서 오류가 많이 나서 시간이 굉장히 오래 걸렸기 때문에 배포 단계가 만만치 않다는 걸 알고 잔뜩 경계하고 있었는데.. 보안 때문에 ssh로 ec2에 접속 가능한 ip를 내 아이피로 제한해놔서 배포는 거의 내가 했다. 아니 다 내가 한 듯.. 근데 보안을 유지하는 다른 방식도 있다는 걸 알게 되어서 다음 번에는 그 방법을 사용해 볼 생각이다 !
기록
- 테스트를 하나도 안 만들었다는 게 프로젝트 진행하는 내내 찝찝했다. 처음에는 조금 만들다가, 나 말고 다른 팀원들은 postman으로 확인하는 게 더 익숙하다고 해서 다수결에 따라서 테스트 안 만들고 그렇게 확인하기로는 했는데, 내가 공부하면서 읽었던 책들에서 얼마나 TDD를 중시했는지 알고 있으니까 TDD는 커녕 테스트도 안 만드는 개발.. 이대로 괜찮은가(?) 싶었다. 근데 아마 전혀 괜찮지 않겠지 하하 이제라도 추가해야겠다. 근데 나 말고 다른 팀원들은 별 생각 없는 거 같아서 조금 고독하다🤣 내가 사서 고생하는 건가 괜히?
- 이번에 이슈를 사용해서 기능별로 브랜치를 만든 후에 pr하고 머지하는 방식으로 진행했다. 처음으로 프로젝트 보드도 사용해보고. 다음 번에는 프로젝트 보드를 더 적극적으로 이용하고 싶고, 코드리뷰도 서로 하고 머지하는 방식으로도 해보고 싶다. 시간이 시간인지라 이번에는 거의 코드 리뷰 없이 그냥 되는대로 각자 각개전투처럼 코드짜고 pr하고 알아서 머지했는데.. 각자 코드 짜는 방식이 다르니까 서로 참고하면 더 좋은 코드를 짤 수 있을 거라고 생각해서 적극적으로 코드리뷰 주고 받고 싶다.
- 위에서 잠깐 언급했지만 이번에 ec2에 ssh로 접근 가능할 때 ip를 제한했었어서 나만 ec2에 접근이 가능했다. 나도 매번 ip가 바뀌면 새로 등록해야 했고. 다음에는 ec2 ssh port를 변경하는 방법으로 보안을 유지해보려고 한다.
- 이번에 내가 맡았던 건 솔직히 이전에 책보면서 한 번 해봤던 것들이 대부분이라 (물론 s3랑 cloudfront는 처음이었지만) 다음에는 이미지를 다뤄보거나 일반적인 회원가입과 로그인 기능 구현을 해보고 싶고 오픈소스도 써보고 싶다! 이번에는 건너뛴 lambda 함수를 써서 이미지 리사이징을 하는 것도 해보면 좋을 듯 하다.
- 아직 프론트랑 합쳐서 배포를 하지 못한 상태다. 틈틈이 시도는 하고 있지만 뭐가 잘 되지 않는다. 으음 포기하고 싶어도 그럴 수 없다.. 얼른 성공했으면.. 다음 번에는 아예 처음부터 연결하고 시도하고 싶은 마음도 있다.