익숙한 MySQl 대신 MongoDB 도전하기

많은 프로젝트 경험이 있는 것은 아니지만, 프로젝트를 할 때마다 도구에 대한 고민이 큰 편은 아니었다. 데이터베이스설계 과목으로 인해 MySQL은 친숙했고, 인턴십에서 진행하는 프로젝트의 데이터베이스는 MariaDB 이다보니 NoSQL에 대한 고려는 전혀 하지 않았었다.

✅ 하지만 인턴십을 진행하면서, 매일 6500 정도의 사용자가 활발히 이용하는 서비스에 추가 기능 개발을 진행하니, SQL의 불편함을 서서히 느끼게 되었고, 서비스의 규모가 커지면서 MySQL이 지배하고 있던 나의 데이터베이스 셰계관이 흔들리기 시작했다!

확장하려면 선행 작업이 많다

데이터베이스를 확장하기가 매우 어렵다. 개발을 하면서, 확장이 어렵다는 SQL의 특성은 스키마로 인해 기인한 것 같다는 생각이 많이 들었다. 도메인의 내용을 예시로 들 순 없어서 다른 예를 들자면, 사용자가 게시물에 좋아요를 누른다고 했을 때, SQL을 사용한다면 데이터 정합성을 위해 여러 확인 절차를 거친다.

사용자가 게시물에 좋아요를 누른다는 것에서 알 수 있는 정보들은 다음과 같다.

• 사용자가 서비스를 탈퇴하지 않고 이용 중
• 게시물이 삭제되지 않고 존재

이때 좋아요 뿐만 아니라 댓글도 추가해야 한다면 어떻게 할까? 먼저 게시글 데이터의 id, 사용자의 id, 댓글 내용을 content로 담고 있는 relational 테이블을 하나 만들고, pk, fk 설정을 해야할 것이다. 테이블이 생성되지 않는다면 댓글 기능은 넣을 수 없다!

데이터에 엄격한 규칙을 부여하는 느낌이 들었다. 물론 인턴십에서 진행하는 프로젝트는 정확성이 중요하기 때문에 이런 작업이 필연적으로 선행되어야 하는 것은 맞다.

사이드 프로젝트에서는 NoSQL을 사용해보자

사이드 프로젝트 TodoChallengers에서는 SQL 기반 데이터베이스가 아닌 NoSQL 기반 데이터베이스인 MongoDB를 사용하기로 했다. 스키마를 짤 때부터, 지금까지 관계형 데이터베이스 스키마를 설계하던 버릇이 있어 어려움에 봉착했다.

사이드 프로젝트 주제는 사용자 일정 관리 + 도전할 일에 대해서는 함께 챌린지하는 것으로 정했다. 시중에 이런 기능을 가진 앱, 웹 서비스는 많다. ✅ 하지만 스프링 프레임워크 / 자바 / NoSQL 데이터베이스에 대해 “이유를 알고” “깊이 고민하며” 코드를 짜고 싶어 간단한 주제를 골랐다!

(이 글을 쓰고 난 후 개발을 시작하면서, 주제가 간단하더라도 백엔드 / 서버에서 고민할 것들이 매우매우 많음을 느끼고 주제의 간단함과 기술적 단순함은 비례하지 않음을 깨달았다…)

사용자 일정 관리

user [
       {
	    id : v4,
		input_id : string,
		input_password: string,
		name : string,
		profile : string,
		birth : date
		friends [
			{ friend_id : v4 },
			{ friend_id : v4 },
		],
		goals [
		  {
			  goal_id : v4,
			  goal_name: string,
			  state : string,
			  color : string,
			  todos [
					{
					  todo_name : string,
					  state : string,
					  start : date,
					  end : date,
					  routine [...],
					}
				], // todos
			}
		], // goals
		user_challenge [
		  { challenge_id : v4 },
		  { challenge_id : v4 },
		]
	}
] // user

뜻이 맞는 사람끼리 함께하는 챌린지

challenge [
	{
            id : v4,
            challenge_name : string,
            start : date,
            end : date,
            category : string // 카테고리 추가!
            challenge_leader_id : v4,
            state : string
            participants [
                {
                    participant_id : v4
                    challenge_checklist [
                        {
                            checklist_id : v4
                            checklist_date : date,
                            checklist_photo : string,
                            state : string // 챌린지도 공개 범위 설정 추가!
                            reaction [
                                {
                                    reaction_id : v4
                                    reaction_giver_id : v4,
                                    comment : string,
                                }
                            ] // reaction
                    }
                    ]
                }
            ] // challenge_checklist
	}
] // challenge

분명히 변경이 있을 것이다

아무래도 관계형 데이터베이스의 스키마에 너무 익숙해져 있고, NoSQL은 처음이라, 이 구조에서 변경이 반드시 생길 것이다. 변경이 생길 때마다 어떤 이유로 어떻게 변경하게 되었는지, 변천사를 이 글에 이어서 작성해야겠다.