프로젝트 회고록 JAVA SpringBoot Javascript React.js 취준 백엔드 프론트엔드 풀스택 웹 개발 MUMUL

MUMUL 프로젝트 회고록

https://mumul.site 사이드 프로젝트, MUMUL을 개발하고 작성하는 회고록입니다. 성공적으로 배포까지 완료한 첫 웹 프로젝트로 다소 부족해도 학부생의 몸부림이라고 봐주면 감사하겠습니다. 🤭

Aug 18, 2023

Contents

❓About MUMUL.📅개발 기간 🛠기술 스택 Back-End Front-End DevOps Collaboration & Tools 💻서비스 주기능 💡트러블 슈팅 경험 프론트엔드 개발자의 부재 - 협업의 중요성 질문과 답변의 1:N N:1 연관관계 테이블 설계 🚀차후 계획 🧐느낀 점 🌐결과물 사이트에 방문하고 싶으면 ✨여기✨를 클릭하세요

❓About MUMUL.📅개발 기간 🛠기술 스택 💻서비스 주기능 💡트러블 슈팅 경험 프론트엔드 개발자의 부재 - 협업의 중요성 팀 구성의 변화(4명 → 2명)리액트 개발과 갈등 효과적인 해결책 - 데일리 스크럼 도입 협업의 가치와 배운 교훈 질문과 답변의 1:N N:1 연관관계 테이블 설계 문제 상황과 해결 과정 문제 해결의 실제 예시 열정과 포부 🚀차후 계획 🧐느낀 점 🌐결과물 사이트에 방문하고 싶으면 ✨여기✨를 클릭하세요

⚠️

해당 글은 편의 상 반말로 작성되었습니다🙇‍♀️ 감안해 주시고 읽어 주세요

❓About MUMUL.

MUMUL은 무물, ‘무엇이든 물어보세요’의 줄임말이다. 흔히 영어권 국가에서는 Ask Me Anything(A.K.A AMA) 라고 불리우며 우리나라에서는 '무물' 이라고 통용된다. 인스타그램 스토리에서 무물이 컨텐츠로 소비되는 것에서 영감을 얻었고 무물만을 위한 서비스가 있다면 재밌지 않을까 라고 호기심이 생겨 제작하게 되었다.

📅개발 기간

2023.04~ 2023.07 동안 개발한 애증의 MUMUL 프로젝트가 결국 배포까지 완성되고 이렇게 회고록을 뒤늦게 작성한다. 3달 동안 쭉 개발을 한 게 아니라 중간 6월은 중간고사 기간 때문에 어중간하게 떠버렸다. 그래서 실질적인 개발 기간은 약 3개월 정도이다.

🛠기술 스택

Back-End

Java

SpringBoot

Front-End

React.js

HTML5

DevOps

MySQL

Collaboration & Tools

Slack

IntelliJ, VS Code

Figma

Github

💻서비스 주기능

MUMUL의 주기능 플로우는 다음과 같다.

사용자가 로그인을 한다

자신의 스페이스가 생성되고 스페이스 이동을 통해

다른 사람의 스페이스에 질문을 남기고

답변을 받는다

추가로 다른 스페이스를 팔로우 할 수 있다.

💡트러블 슈팅 경험

프론트엔드 개발자의 부재 - 협업의 중요성

팀 구성의 변화(4명 → 2명)

우리 팀은 처음에 프론트엔드 2명, 백엔드 2명으로 총 4명의 팀원으로 시작했다. 그러나 프론트엔드 팀은 다른 업무로 바빠서 프로젝트에 참여하기 어렵다고 판단했고 팀 전체 회의에서 프론트엔드 팀원 2명을 제외하기로 결정했다. 프론트엔드 팀원 추가 모집을 시도했지만 성사되지 않았고, 결국 백엔드 팀인 우리가 프론트엔드 개발까지 맡게 되었다.

리액트 개발과 갈등

리액트를 전혀 모르는 상태에서 프론트엔드 개발을 시작했다. 아직도 리액트에 대한 숙련도는 많이부족한 상태지만 이번 경험으로 많은 것을 배웠고 또한 성장할 수 있는 기회였다. 물론 익숙하지 않은 기술 스택을 습득하면서 동시에 개발을 진행하는 것은 쉽지 않았다. 이로 인해 개발 진도가 예상보다 더디게 나갔으며, 서로의 업무 예민도도 높아지게 되었다. 이러한 상황으로 인해 소통도 원활히 이루어지지 않았다.

효과적인 해결책 - 데일리 스크럼 도입

이에 대한 대안으로 팀원 분이 매일 오전 10시에 각자의 개발 진행 상황과 오늘의 계획을 전화를 통해 5분씩 공유하는 방식을 제안하셨다. 처음에는 상황 개선 가능성에 대한 의문을 가졌지만, 결국 매일 정해진 시간에 통화를 하며 서로 상황을 공유하고 자극을 주고 받음으로써 개발에 박차를 가할 수 있었다.

중간에 업무 피로도 및 압박감으로 인해 포기하고 싶은 마음이 들 때도 있었지만, 팀원에게 의지하며 극복하는 순간도 있었다. 이렇게 함께 노력하고 의지하며 프론트엔드 개발까지 무사히 완료할 수 있었다. (SHOUT TO 팀원📣🤘)

협업의 가치와 배운 교훈

나중에 알게 된 사실인데 매일 아침 10시에 진행한 5분 통화가 데일리 스크럼이라는 미팅 방식이었다는 것이다. 질 높은 협업이 개발에 얼마나 큰 도움을 주는지를 몸소 체감할 수 있었다. 부끄럽지만 혼자하는 개발이 편리하다고 자만하던 나였다.

무슨 일을 하든 혼자서 작업을 해본 경험이 있는 사람이라면 공감할 수 있을 것이다. 처음에는 혼자서 다할 수 있을 것만 같다. 하지만 결국 혼자 파고 들다가 시야는 좁아지고 스스로 골방에 가두는 꼴이 되어 버린다. 작업 후반부에는 업무 텐션이 현저히 떨어지고 일의 완성도 또한 떨어질 가능성이 매우 높다. 그러다 실패하면 자책감과 함께 패배주의에 빠져 버리는 상황까지 갈 수도 있다😂☠ (본인 경험…)

물론 혼자서도 작업을 완료할 수 있는 훌륭한 1인 개발자 분들도 계시지만, 나 같은 보통의 사람은 일을 하는데 동료와 함께 하는 협업이 필수적이라고 생각한다. 이번 계기를 통해 팀원의 필요성과 역할 분배의 중요성을 더욱 뼈저리게 몸소 느꼈고, 훗날 동료들과 함께 일하는 것을 고대하며 설레는 마음을 갖고 있다.😘

질문과 답변의 1:N N:1 연관관계 테이블 설계

MUMUL 프로젝트를 개발하면서 데이터베이스 설계 과정에서 겪은 어려움과 그 해결 과정에 대한 내용이다.

문제 상황과 해결 과정

프로젝트 초기에는 질문과 답변 간의 관계를 효율적으로 관리하지 못하여 데이터의 추적에 어려움을 겪었다. 특히, 사용자 간의 질문과 답변을 연결하는 과정에서 문제가 발생하여 데이터의 정확성과 일관성이 손상되었다.

문제 해결의 실제 예시

이 문제를 해결하기 위해 연관관계 테이블을 설계하기로 결정했다. 이전에는 사용자가 질문을 작성하고 답변을 받아도 어떤 질문에 해당하는 답변인지 추적할 수 없었다. 그래서 1:N 및 N:1 연관관계를 활용하여 각 질문과 답변을 서로 연결하고 추적할 수 있는 방법을 선택했다.


@NoArgsConstructor
@AllArgsConstructor
@Data
@Entity
@Builder
@Table(name = "questions")
public class QuestionEntity {
   
		// --------- 생략 ------------


   // 1:N 연관관계 -> 하나의 질문은 여러 개의 답변을 가질 수 있음
    @OneToMany(mappedBy = "question",
            cascade = CascadeType.REMOVE,
            fetch = FetchType.LAZY)
    @Builder.Default
    @Column(nullable = false, name="answers")
    private List<AnswerEntity> answers=new ArrayList<>(); 
}

질문의 엔터티 클래스 (1 : N 연관관계)


@NoArgsConstructor
@AllArgsConstructor
@Data
@Builder
@Entity
@Table(name = "answers")
public class AnswerEntity {

		// --------- 생략 ------------



    // N:1 연관관계 -> 여러 개의 답변은 하나의 질문에 속함		
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "question_id") // 외래 키 컬럼: 질문 식별 가능
    private QuestionEntity question; 
}

답변의 엔터티 클래스 (N : 1 연관관계)

이렇게 각 질문과 답변을 매핑함으로써, 특정 사용자의 질문과 그에 따른 답변을 빠르게 식별하고 분석할 수 있었다. 이러한 접근으로 데이터의 일관성을 유지하고 시스템의 안정성을 확보할 수 있었다.

열정과 포부

이 경험으로 데이터베이스 설계의 중요성을 조금이나마 이해하게 되었다. 효율적인 테이블 간의 관계 설정과 데이터 관리는 더 나은 사용자 경험으로 이어진다. 이를 통해 끊임없는 학습과 도전으로 나의 역량을 키우고 실제 문제 해결에 기여하고자 하는 의지가 더욱 확고해졌다.

🚀차후 계획

아직은 질문과 답변 등록, 팔로잉 기능이 주기능으로 존재하지만 여기에 추가해서 리무물(re-mumul) 기능도 나중에 추가해서 남의 스페이스에 맘에 드는 질문이 있다면 리무물해서 본인 스페이스로 퍼올 수 있도록 하고 싶다. 그리고 리무물이 많이 된 질문을 트렌드 페이지에서 보여준다면 사용자 경험에도 좋은 영향을 끼칠 거라고 생각한다.

🧐느낀 점

MUMUL 프로젝트는 내게 의미 있는 작품이다. 강제성이 없다는 특징 때문인지 지금까지 진행했던 사이드 프로젝트들은 중간에 무산이 된 적이 많았다. 그래서 이번 프로젝트는 내게 스프링부트와 리액트를 공부할 수 있는 고마운 계기였고 팀원과 함께 무언가 해냈다는 성취감을 느끼게 해줬다. 뭔가를 성공한 경험은 다른 무언가에 도전할 때도 해낼 수 있을 거라는 자신감을 심어주는 거 같다.

만약 이 글을 보고 있는 당신도 개발하고 싶은 서비스가 있다면 일단 시작하라고 말해주고 싶다.

나도 했으니 너도 할 수 있어💪