LiveAmonth

Contents

1. 📢 프로젝트 기획
2. 📃 프로그램 요구사항
3. 📂 개발 진행 과정
4. 🔎 애플리케이션 기능
5. 🖥 소프트웨어 아키텍처

📢 프로젝트 기획

1. 한 달 살기에 대한 선호도 증가

설문조사 결과 10명중 8명은 살아보는 여행을 꿈꾸고, 15일 이상의 장기 여행을 선호

한 달 살기를 시작한 이유

자연경관이 좋은 곳에서 휴식하고 싶다. (24.8%)
나를 돌아보는 시간을 갖기 위해서 (22.3%)
현지인처럼 살아보고 싶어서 (17.4%)
짧은 여행으로는 여행지를 제대로 보기 힘들어서 (14.0%)
새로운 곳에서 새로운 것들을 배우고 싶어서 (14.0%)

한 달 살기를 하면서 힘들었던 점

한 달 동안 생활을 하는 비용이 많이들고 관리가 힘듦

한 달 동안 한 것

주로 주변 여행지를 다니거나, 자연속에서 휴식을 즐기며, 지역의 특색에 관련된 활동

한 달 살기를 해보고 싶은 지역

제주가 앞도적으로 높은 응답을 보였지만, 전국 곳곳의 여행지도 선호

2. 사용자들이 원하는 핵심 요소 파악

장소

스스로 의미있는 시간을 보내고, 충분히 휴식을 하기 위한 장소

비용

한 달 동안 생활하기 위한 비용

계획

한 달 살기 기간 동안의 생활을 계획

📃 프로그램 요구사항

• 장소를 위해 여행지를 점수화 하여 직관적으로 표시
• 각 지역별로 유명한 관광정보를 정리
• 위해 개인 별 한달 살기 비용을 업로드
• 원하는 조건을 선택해 확인 할 수 있게 하고, 계획을 위해 공유 가능한 캘린더 작성 기능

📂 개발 진행 과정

🔎 애플리케이션 기능

1. City

• 서울, 강릉, 경주, 부산, 여수, 제주 총 6개의 대표적인 도시 안내
• 각 도시의 간략한 설명, 유명한 볼거리와 먹을거리들을 소개
• 정류장 및 노선 개수를 바탕으로 알고리즘을 사용해 점수화한 교통 정보를 제공
• 전년도 기온 정보를 제공해 대략적인 기온 예측에 도움

2. Schedule

• 한 달 살기 계획을 작성하거나, 한 달 살기 기록을 할 수 있는 캘린더를 제공
• 자신의 일정을 도시 별로 캘린더에 등록하고, 사용한 비용을 기록
• 다른 사용자의 캘린더를 원하는 성별, 나이대 와 관심있는 도시로 추천순, 최신순, 조회순으로 검색 가능
• 좋아요와 댓글 기능

3. Review

• 게시판을 통해 사용자들은 주제별, 도시별로 각자의 경험을 게시글로 작성
• 검색, 좋아요, 댓글 기능

4. My Page

• 사용자 자신의 회원정보 확인 및 수정
• 프로필 또한 단순한 이름이 아닌 닉네임, 프로필 사진 등 자유롭게 자신을 표현
• 자신의 게시물(shcedule, review)을 확인, 관리
• 1:1문의 기능
• 네이버 로그인 기능

5. Customer Center

• 개인정보 처리방침, 이용약관, 공지사항, FAQ 기능

🖥 소프트웨어 아키텍처

1. 인프라

• 부족한 기술을 보완하기 위해 웹 애플리케이션 및 서비스를 간편하게 배포, 조정 할 수 있는 서비스인 AWS의 Elastic Beanstalk 사용해 간편하게 구축했습니다
• 코드 작성에 더욱 집중해서 개발을 할 수 있었으며 애플리케이션 짧은 기간, 인력 대비 생산성을 높였습니다.

• 로드 밸런싱을 통한 여러 대의 서버를 분산처리하고 오토 스케일링을 사용해 서버의 사이즈를 탄력적으로 운영했습니다.
• S3 Bucket을 사용해 사이트의 애플리케이션 버전과 사이트에서 사용되는 이미지를 저장해 애플리케이션의 크기를 줄였습니다.

2. 운영 및 배포

• 젠킨스, AWS S3 Bucket을 사용해 자동 빌드, 배포 환경을 구축했으며 이로 인해 개발자는 직접 서버 환경에 애플리케이션 코드를 올리지 않아도 Github에 코드만 Push해 애플리케이션을 배포했습니다.
• Rolling 방식으로 배포해 서버를 하나씩 버전업을 시켜 실제 서비스가 중단되지 않고 계속 유지되도록 했습니다.

3. 개발 환경

• Java를 기반으로 스프링 프레임워크를 사용했습니다

• Presentation Layer는 jsp언어로 jquery, bootstrap 등 여러 오픈소스 라이브러리를 사용했습니다.

• 데이터 베이스는 mysql를 사용했으며 SQL작성을 위해 myBatis를 사용했습니다.

4. 디자인 패턴

5. 코드

1) Presentation Layer

• JSP 소스의 가동성을 높이고 유지 보수성을 향상시키기 위해 JSTL을 사용했습니다.
• Ajax를 사용해 좋아요와 댓글 기능 서버쪽의 랜더링 없이 화면 전환이 가능하도록 했습니다.
• Tiles Framework를 사용해 반복된 레이아웃을 한 곳에서 관리해 중복된 코드 및 리펙터링시 효율성을 높였습니다.

2) Business Logic Layer

🔑 지속적인 리펙토링을 위해 유지보수, 생산성을 높이는 것에 중점을 두어 개발

• 전체 코드 내에 상수에 대해 constant package를 만들어 enum 클래스를 사용해 한 곳에서 관리했습니다.

• 메시지, 파일 이름 등 고정적인 상수에 대해 변경이 있더라도 전체 코드를 고치는 것이 아닌, 만들어둔 constant package의 enum클래스의 값만 변경해 사용할 수 있도록 했습니다.

• 중복되는 함수를 일반화하여 하나의 부모 클래스를 생성했습니다.
  
• 코드의 가독성을 높이는 효과를 보였습니다.

• 각 계층 사이 인터페이스 타입을 사용했습니다.
• 객체의 교환성이 높아져 컴퓨터의 부품을 교체하듯이 변경점이 있다면 해당 인터페이스의 구현체만 바꾸어 사용할 수 있어서 유지보수성이 향상되는 효과를 보았습니다.

3) Data Access Layer

🔑 MyBatis를 사용해 DB에 접근을 했습니다.

• 소스코드와 SQL을 분리하여 사용가능 했고, SQL의 세부적인 내용 변경에 유리했으며 동적 쿼리 사용시 JAP와 같은 ORM에 비해 간편하게 구현이 가능했습니다.

6. 데이터베이스 디자인

• E-R Diagram

• 정보 제공 및 사용자 간의 의사소통 및 사용자 중심 일정 작성이 핵심 기능이기 때문에, 복잡한 비즈니스 로직보다는 입출력 구조가 더 많이 존재해 OR Mapping이 아닌, SQL Mapping을 적용했습니다.

• 데이터 추출 시, 트레픽 과부하를 최소화하기 위해, 쿼리문을 최대한 깨끗하게 작성하려고 노력했습니다.

한 SQL 스테이트먼트가 한 테이블에서 하나, 혹은 두 개의 필드를 선택하고 다른 SQL 스테이트먼트가 이 정보를 이용해서 다른 테이블의 데이터를 가져온다면, 이 두 가지를 두 테이블에서 데이터를 돌려보내는 하나의 스테이트먼트로 작성했습니다.