💌 프로젝트 소개

프로젝트 명

너는, 나는

기획 의도

서로 좋아하거나 사랑하는 사이라도 직접적으로 말하기 어려웠던 점은 없나요?

혹은 상대에 대해 더 알아가고 싶었던 적이 있었나요?

가장 가까운 사이라도 이야기하지 못했던, 혹은 궁금했던 점들이 있었나요?

어떻게 하면 재밌고 더 편하게 질문할 수 있을지 고민하다가 너는, 나는 을 만들게 되었습니다.

프로젝트 설명

너는 어떻게 생각해? 나는…

질문을 공유해서 공유된 질문에 대한 답변으로 서로에 대해 더 알아갈 수 있는 서비스입니다.

주요 사용자 타겟은 연인입니다.

• 사용자가 너는, 나는 서비스에 접속하여 로그인 후 나누고 싶은 질문을 선택 후 초대 링크를 통해 해당 질문을 연인에게 보냅니다.
• 초대 링크를 받은 상대가 해당 질문에 답변을 작성하고 로그인을 하면 초대가 수락되며, 질문에 대한 서로의 답변을 확인할 수 있습니다.
• 질문은 하루에 한 번만 선택할 수 있고, 질문에 대한 답변은 양쪽 모두가 답변을 작성해야만 확인이 가능합니다.
• 질문 리스트는 DB에 저장해 둔 프리셋 질문들을 사용합니다.

나중에 추가하고 싶은 기능

작업을 하면서 이런 기능들이 있으면 사용자들이 더 편하게 서비스를 이용할 수 있겠다고 생각되었던 것들을 정리해 보았습니다.

1. 질문 현황 페이지

2. 답변 수정

3. 커스텀 질문 등록

4. 알림 기능

프로젝트 주요 기능 소개

로그인	동작
메인 페이지에서 ‘카카오 로그인’ 버튼을 누르면 카카오 소셜 로그인 페이지로 이동하여 카카오 로그인을 할 수 있습니다.
사용자 초대	동작
상대방에게 묻고 싶은 질문을 선택하고, 카카오톡 친구에게 공유하여 초대할 수 있습니다.
초대 수락	동작
- 초대받은 사용자는 카카오톡으로 공유된 링크에 접속하여 질문에 대한 답변을 작성할 수 있습니다. - 초대받은 사용자가 답변을 등록하려면 로그인을 해야 하며, 답변 작성 후 등록시 카카오 로그인 페이지로 리다이렉트됩니다. - 로그인에 성공하면 로그인 전에 작성한 답변을 등록할 수 있으며, 커플이 맺어짐과 동시에 서로의 답변을 확인할 수 있습니다.
질문 선택	동작
커플이 답변할 질문을 질문 선택 페이지에서 매일 한개씩 선택할 수 있습니다. 질문을 선택하면 대화 상세 페이지로 이동하며, 선택한 질문이 하단에 추가된 것을 확인할 수 있습니다.
답변 등록	동작
대화 상세 페이지에서 선택한 질문을 클릭하여 답변을 작성할 수 있습니다. 두 사람 모두 작성한 후 답변을 확인할 수 있으며, 둘 중 한 명만 답변했을 경우 안내 메시지가 오버레이되며 답변을 확인할 수 없습니다.
대화 상세 페이지	동작
선택한 질문과 이에 대한 답변은 채팅 형식으로 대화 상세 페이지에 누적됩니다. 로그인한 사용자의 답변은 오른편에, 상대방의 답변은 왼편에 배치됩니다. 최신 질문일수록 하단에서 확인할 수 있으며, 오래된 질문은 스크롤을 위로 올려 확인할 수 있습니다.

🚀 프로젝트 실행 방법

요구사항

• Java 17
• Docker
• MySQL 8.0

프로젝트 클론

git clone https://github.com/coding-union-kr/youare-iam-be.git

프로젝트 루트 폴더에 .env 파일 작성

DB_HOSTNAME=
DB_NAME=
DB_PASSWORD=
DB_USERNAME=
ENCRYPTION_IV=
ENCRYPTION_SECRET_KEY=
JWT_SECRET=
OAUTH_CLIENT_ID=
OAUTH_CLIENT_SECRET=
OAUTH_REDIRECT_URI=

프로젝트 실행

• 작은 프로젝트라서 prod와 local환경으로만 구성

./gradlew build && java -jar -Dspring.profiles.active=local ./common/build/libs/common-0.0.1-SNAPSHOT.jar

---

5. 아키텍처

🛠️ 백엔드 기술 스택

기술 스택💙

• JAVA 17
• Spring boot 3.2.0
• MySQL 8.0.33
• Querydsl 5.0.0
• JPA
• JWT 0.11.2
• Oauth 2.0

Dev Ops💚

• Elastic Beanstalk
• Amazon RDS
• Amazon EC2
• AWS
• Github Actions

사용한 Tools🧡

• Github
• Swagger 3.0
• IntelliJ
• DataGrip

---

😊프로젝트 진행을 위한 노력😊

저희는 3주간의 기획 기간과 3주간의 개발 기간을 합쳐 총 6주차에 MVP를 출시하겠다는 목표를 세웠습니다.
그러나 6주차에 프론트엔드는 MVP 기능 중 초대하기와 무한스크롤 기능, 백엔드는 인증과 배포 구현이 완료되지 않은 상태였습니다.
또한 기존의 MVP 목표에 리프레시 토큰 구현이 추가되었고 테스트를 하며 서비스를 더 보완하는 시간을 가졌습니다. 5주 간의 추가 개발 기간을 가진 후 11주차에 릴리즈를 하게 되었습니다.

1. 그라운드 룰📃

• 팀 일정 관리 도구🛠
  • 프로젝트 기간 동안 일정 관리를 위해서 노션(Notion) 캘린더, 슬랙(Slack)을 이용했습니다.
  • 회의 일정, 작업 진행 상황 및 마일스톤을 공유해서 팀원 간 진행 상황을 투명하게 공유할 수 있도록 했습니다.
• 주간 스크럼 및 코어 타임⏰
  • 매주 4회, 오후 1시부터 6시까지 스크럼 회의와 코어타임을 진행했습니다.
  • 스크럼 회의에서는 각 팀원이 현재 진행 중인 작업과 그 진행 상황, 앞으로 해결해야할 계획을 공유했습니다.
  • 코어타임에는 프론트엔드와 백엔드 팀이 각각 나뉘어 작업 목표를 설정하고, 이를 달성하기 위해서 집중적으로 협업했습니다.
  • 또한, 코어타임 중에는 화면 공유를 통해 서로의 작업 과정을 실시간으로 확인하고, 필요한 경우 페어 프로그래밍을 진행했습니다.
• 정기 회고 회의📝
  • 매주 일요일에 주간 회고 회의를 진행했습니다. 이 회의에서는 팀원들의 회고를 공유하면서 한 주간의 팀 운영에 대한 피드백을 진행했습니다.
  • 회의 결과를 차주의 목표에 반영했습니다.
• 마일스톤 일정 조정✅
  • 프로젝트 진행 중 일부 기능 개발에 예상보다 더 많은 시간이 소요된 경우에는, 회의를 통해서 마일스톤 일정을 조정하고, 추가적인 리소스를 해당 작업에 할당해서 프로젝트를 완료할 수 있었습니다.

2. 회고를 통한 팀원들의 성장

쪙이🧡

Liked

• 서로 알고 있는 지식을 공유하면서 문제를 해결해 나가는 방식이 좋았다. 그리고 작업 중에 막히는 부분이 생기면 같이 찾아봐주거나 해결이 될 때까지 차분히 기다려주고 격려해주면서 개인이 아닌 우린 한 팀이라는 의식을 갖게 해주었다.

Lacked

• 아무래도 아직 개발 경험이 부족하다보니 개발을 하다가 해당 방법으로 구현하는게 맞는지 확실히 하지 못 했다.

Learned

• 개발을 하면서 제가 생각하지 못 했던 로직을 생각해내는 것을 보고 코드를 짤 때 더 깊이 있게 흐름을 파악해야겠다는 생각이 들었다.

Longed for

• 운영 기간 동안 큰 이슈없이 무사히 서비스를 마치는 것이다.

밤밤🤎

Liked

• 프로젝트 시작하기 전에 목표했던 기획부터 서비스 배포까지의 사이클을 경험해볼 수 있었다.
• 팀원들과 적극적으로 소통하면서 프로젝트를 진행했다.
  • 예상치 못한 상황이 발생했을 때 우리 팀은 문제 상황에 대해서 슬랙 메시지로 공유하고, 이를 확인한 팀원들이 문제 상황을 파악하고 필요한 경우에는 회의를 만들어서 소통을 했는데, 이 부분이 코어타임에 진행되는 경우는 문제 해결 속도를 더 빠르게 했고, 문서화 효과도 줘서 프로젝트에 전반적으로 어떤 이슈가 있는지에 대해서 팀원들 모두 공유하기가 수월했다.

Lacked

• 일정을 지키지 못한 점이 아쉬움이 남는다.
  • 프로젝트를 시작할때 일정을 산정하는 단계에서 계획했던 기능 구현 완료 시기를 잘 계획하지 못한 점이 크다. 팀원들이 구현할 수 있는 속도와 구현해야 하는 기능의 볼륨을 잘 파악하지 못했기 때문이라고 생각한다. 하지만 이 점은 기능을 구현하는 경험을 더 많이하게 되면 나아질 것 같다.
  • 배포 서버 환경에서 테스트를 프로젝트 초반에 진행하지 못한 점도 일정관리에 영향을 끼친 것 같다. 초반에는 배포된 서버를 사용하고 배포가 내려간 뒤에는 백엔드 팀원의 로컬 서버를 사용했다. 릴리즈 전에는 다시 배포된 서버를 사용했다. 릴리즈 전에 있었던 네트워크 이슈를 제외하더라도 서버환경이 바뀌는 부분이 프론트엔드 개발 일정에 블로커로 작용하는 부분이 있었다. 한 팀원의 로컬 환경에서는 A기능이 구현되지 않아서 다른 팀원의 로컬 서버로 연결해야 하는 등. 어떤 식으로 진행을 해야하는지를 잘 알지 못해서 이 부분에 대해서 제대로된 제안을 하지 못했던 것 같다.
  • 한 가지 이슈를 너무 오랜 기간 끌고 간 점도 일정에 영향을 미쳤다. 개인적으로는 로그인과 api 모듈화 관련된 기능, 라우팅 관련한 로직을 처리하는데 너무 많은 시간을 소요했다. nextjs를 프로젝트에 처음 사용하면서 서버사이드 환경을 제대로 이해하지 못한 부분이 컸기는 했지만, 좋은 설계나 효율적인 코드 같은 부분에 집착 아닌 집착을 해서 더 일정을 길게 잡아먹었던 것 같다.

Learned

• 내가 기술적으로 해결할 수 있는 부분 뿐만 아니라 문제 상황을 팀원들과 소통하면서 문제를 해결해나갈 수 있다는 걸 배웠다.

Longed for

• 계획한 추가 기능을 기간 안에 마치기
• 개인적으로는 지치지 않고 좋은 팀플레이어가 되고 싶다.

비얌💙

Liked

• 매일 팀원들의 상황을 자세하게 공유할 수 있어서 좋았다. 매일 스크럼 시간을 가지며 팀원들의 컨디션을 공유했다. 그리고 코어타임 시작과 끝에 작업 현황을 공유했다. 이렇게 상황을 투명하게 공유한 덕에 협업 과정에서의 불안감을 크게 줄일 수 있던 것 같다.
• 역할 분담을 적절하고 빠르게 하였고, 모두가 맡은 역할을 책임감 있게 수행한 점이 좋았다.
• 팀원들과 머리를 맞대고 회의하며 문제를 해결해나가는 과정이 어려웠지만 그만큼 즐거웠다.

Lacked

• 릴리즈 목표 날짜가 계속해서 밀렸던 것이 아쉽다. 모두가 프로젝트를 더 완벽하게, 잘 하는 것에 대한 열망이 있어서 시간이 더 걸린 것 같다는 생각이 든다.
• 초기에 기획, 디자인이 부족했던 것 같다. 기획적으로 처음에는 생각하지 못했던 부분을 중반, 후반에 다시 생각하고 실제로 개발에 반영하며 어려움을 겪었다. 또한 상세한 디자인을 완성하지 않고 개발에 들어가서 UI 컴포넌트를 만들 때 어려움이 있었다. 기획자와 디자이너가 없었기에 더욱 쉽지 않았던 것 같다.

Learned

• 책임감 있고 계획적인 팀원들과 협업하며 소프트스킬과 하드스킬을 배울 수 있었다.
• 협업하며 과정 공유가 안된다거나, 독성 말투를 듣는 등의 이유로 불안감을 느낀 적이 없다. 이렇게 신뢰를 주는 팀원들과 협업하며 함께 일하는 법을 배울 수 있었다.
• 협업하며 팀원으로부터 컴포넌트화된 코드가 무엇인지 배웠다.
• 주4회 5시간씩 코어타임을 가지며 그동안 부족했던 코딩 시간을 채웠다. 코딩을 많이 한 만큼, 많은 시행착오를 겪고 많이 배울 수 있었다.

Longed for

• 이번 프로젝트에서 배운 점을 토대로 다음번에는 프로젝트 도중 겪을 수 있는 어려움에 미리 대비하고 싶다.

감티💛

Liked

[내가 필요하고 사용할 것 같은 서비스를 기획했다!]

"너는, 나는"은 이전에 작업했던 프로젝트보다 사용자 입장에서 고민하며 기획하고 작업했다.

기획부터 서비스 타겟을 좁히려고 노력했다. 원래는 나이 상관 없이 더 친해지고 싶은 사람이 있는 사용자라는 굉장히 광범위한 타겟을 잡았었다. 그래서 질문과 답변을 주고 받을 그룹을 일대일로 할지, 다대다로 할지, 아니면 일대다로 할지 갈팡질팡하고 기획의 끝이 나지 않았었다.

예전에 스터디를 같이 했던 마케터분이 타켓을 좁힐 수록 좋다고 하신 적이 있다. 또 팀원끼리 기획의 방향을 정하지 못해서 도움을 받은 멘토링에서는 타겟이 지나치게 넓기 때문에 좁혀서 더 뾰족하게 기획하는 것이 좋을 것 같다는 피드백을 받았다. 그렇지만 서로 더 알고 싶고 대화하고 싶은데 시작이 어려운 사람들을 돕고 싶다는 프로젝트 목표는 포기하고 싶지 않았다. 그래서 주 타겟을 커플로 정하고 제공되는 질문은 커플이 아니어도 고를 수 있게 가벼운 질문도 섞어서 준비했다.

항상 기획은 기획과 거리가 멀고 취업 준비를 하고 있는 개발자들끼리만 하게 돼서 옳은 선택인지 방향이 틀어지진 않았는지 고민이 많았는데 멘토링도 받고, 또 이번 기획은 취업 준비를 하면서 여러 이유로 다소 멀어지고 더 가까워지고 싶은 사람들이 있는 사용자의 입장로써 생각하고 준비해서 더 괜찮게 나온 것 같아서 좋았다.

[나도 모르고 팀원도 모르면 같이 힘을 합쳐서 해결하기!]

우리 팀에는 "어려운 부분이 있거나 문제가 있는 경우 투명하게 공유하기"라는 규칙이 있다.

그런데 나는 기능에서 문제점을 공유하는 것이 익숙하지 않다. 오기가 생겨서 혼자 계속 붙잡고 있는 단점이 있다.

이번에는 어느 부분이 문제인지 감도 안잡히는 이슈가 발생했다. AWS Beanstalk을 이용해서 EC2 인스턴스에 백엔드 서버 배포 했는데, 어떤 때에는 백엔드 서버로의 연결이 되고 또 어떤 때에는 연결이 되지 않고 504 Time out 에러가 떴다. 로그를 보기 위해서 CloudWatch를 활성화했지만 로그에서도 이상한 부분을 찾을 수 없었다. 나는 CS 지식이 부족한 편인데 이 문제는 네트워크 문제였다. nslookup 명령어로 연결한 도메인에 지정된 IP 2개를 알 수 있었는데, ping 테스트를 해보니 하나는 정상인데 다른 하나는 비정상 응답이 돌아왔다. NginX로 로드밸런싱을 하려다가 SSL 인증서를 내가 배포된 서버에서 직접 관리하기엔 부담이 되고 AWS에서도 권장하는 방법이 아니라서 ALB로 변경하면서 생긴 문제인 것 같았다. (이 문제는 따로 정리해서 블로그에 글을 올리려고 한다.)

네트워크에 대해서 거의 아는 게 없는 나는 전혀 감이 오지 않았을 때 같은 백엔드 팀원에게 도움을 요청했고 둘 다 원인을 몰랐지만 같이 고민하고 원인을 검색하면서 나눴더니 정신적인 피로감도 덜 했고 예상보다 빨리 해결했다. 사실 나는 3~4일은 걸릴 것이라 생각했는데 힘을 합쳤더니 2일 밖에 걸리지 않았다.

이건 팀원과의 협업과는 다른 이야기지만 어려운 부분이 있는 경우 바로바로 멘토님께 물어보는 습관이 생긴 것도 이번 프로젝트의 좋은 점인 것 같다. 물론 기본적인 것은 공부하고 물어봤다! 그리고 내가 원인이나 이상하다고 생각하는 부분도 정리해서 질문을 드리려고 노력했다!

Lacked

[무너진 멘탈 잡기...]

국비 학원에 이어서 부트캠프까지 나는 개발자 취업에서 두번의 고배를 마셨다.

그래도 개발이 재밌어서 개발자가 되려고 노력하고 있지만 정신적으로 무너지는 것은 막을 수 없었다.🥲

"너는, 나는" 프로젝트를 시작하기 전에 이미 흔들리고 무너지고 있었고, 그래서 이번 프로젝트에서 최고의 퍼포먼스를 내지 못했기 때문에 이번 프로젝트 목표 기간이 늘어나고 좀 더 늘어나게 됐다.

그래도 추가 기능 구현 기간인 현재는 어느 정도 회복을 했고, 릴리즈를 시작하고 마케팅을 하고 유저 테스트를 시작하니까 마음이 편하고 기뻐서 긍정적인 마음을 갖게 된 상태이다.

Learned

[고가용성도 중요하지만 이득이 되는 방향으로!]

부트캠프의 프로젝트에서 지나친 고가용성을 챙기느라 하루에 7~9달러의 비용이 발생했었다. 금액이 너무 두렵고, 클라우드에 대한 지식이 너무 얕아서 어떤 서비스를 사용해야 하는지, EC2 인스턴스 유형도 어느 정도면 충분한지, 몇 개를 띄워야 하는지 감이 오지 않아서 멘토님께 질문을 드렸다.

프리티어 인스턴스면 충분할 것 같다고 하셨고 배포 후 상황을 보고 업그레이드를 하거나 개수를 늘리거나 하는 것이 좋을 것 같다고 말씀해주셨다. 그리고 부하 테스트를 통해 얼마나 버틸 수 있는지 테스트하고, 가용 영역도 하나만 써도 될 것 같다고 말씀해주셨다.

나의 클라우드라는 서비스의 이해를 가장 높여준 피드백은 사용하는 가용 영역에서 문제가 발생했을 때 1시간 동안 셧다운 됐을 때의 손해와 가용 영역 두 곳 이상을 사용해서 나온 비용을 비교해봐야 한다는 것이었다. 당연한 이야기일 수도 있지만 앞으로 인프라를 구축할 때 아주아주 도움이 많이 될 피드백이었다.

[성장한 마인드!]

"너는, 나는" 프로젝트는 도움을 주시는 멘토님이 계셨는데 개발 마인드 부분도 많이 배우고 도움을 받았다.

질문을 할 때 기초적이고 기본적인 것을 부끄러워하지 않았으면 좋겠다고 말씀을 해주셨고, 특히 기능 관련 질문을 할 때도 방법이 하나만 있는 것은 아니라는 말씀을 자주 해주셨다. 한가지 방법만 파고 이게 맞겠지?!하던 나를 아주 부끄럽게 만드는 피드백이었다.🤣

멘토님과 버디님 덕분에 배포와 유저 테스트까지 올 수 있었습니다!😊

Longed for

[추가 기능이 밀리지 않게 멘탈 꽉 잡아서 끝까지!]

1차 릴리즈를 시작하고 지금은 추가 기능 구현 + 리팩토링 + 그리고 아직 테스트 코드를 작성하지 않아서 테스트 코드 작성!이 남아있다! 이력서도 작성하고 포트폴리오도 다듬고 지원도 해야하지만! 취업이 목표지만!

긍정적인 감정을 유지하고 있고 다시 개발이 즐거워진 지금을 계속 유지해서 남은 할 일들을 끝까지 잘 해내고 싶다. 이번에는 밀리지 않고 정한 기한까지 추가 기능을 끝내고 싶다.

[꾸준한 블로깅]

"너는, 나는" 프로젝트를 진행하며 진행 상황이나 배운 것, 구현한 것들을 블로그에 글로 적으려고 노력했지만... 익숙하지 않고 게으른 완벽주의자라 임시 글만 10개가 넘은 상태이다.

나를 위해서, 취업을 위해서 하나씩 하나씩 공부했던 것, 해냈던 것을 글로 적어서 출간하고 싶다!

3. 기능 우선순위💈

• 첫 기획 완료 후 필수 기능과 추가 기능이 무엇인지 정의하고 나눠서 MVP 목표를 설정했습니다.
• MVP 목표 중에서도 중요도로 정리를 해서 소셜 로그인, 질문 선택 후 등록, 답변 등록, 질문과 답변 상세 조회 를 핵심 기능으로 설정했습니다.
  • 핵심 기능으로 설정한 이유🧐
    • 소셜 로그인 : 커플을 맺는 플로우가 확립되지 않았기 때문에 핵심 기능 바로 다음 우선순위인 초대 관련 기능을 구현하기 위해선 소셜 로그인이 구현되어야 했기 때문입니다.
    • 질문 선택 후 등록, 답변 등록, 질문과 답변 상세 조회 : 이 프로젝트의 핵심이 대화의 포문을 열 수 있는 질문을 선택해서 서로 답변을 하고 확인하는 것이기 때문에 해당 기능들을 핵심 기능으로 설정했습니다.
• MVP 목표 중에서는 핵심 기능을 1순위로 두고 먼저 작업하였으며 핵심 기능 구현 후 작업이 완료된 기능을 보완하거나 그 기능과 연관된 기능을 다음 우선순위로 결정하였습니다.
• 이후에는 프론트엔드의 흐름에 따라 필요한 기능을 먼저 작업하거나 팀 회의를 통해서 서비스 흐름의 방향이 수정되거나 추가 됐을 때 필요한 기능을 0순위로 잡아서 작업했습니다.

4. 백엔드 업무 분담 기준🎈

• 백엔드 업무를 크게 세 가지로 나눌 수 있습니다. => '로그인', '배포', '기능 API'
• 업무를 나눌 때, 저희는 각자의 도전 과제와 가장 하고 싶은 일을 중심으로 고려했어요. => 쪙이: sns 로그인, 감티: 배포
• 그래서 '로그인'과 '배포' 업무를 먼저 분담하고, '기능 API'는 각자가 나눠서 맡았습니다.
• 그리고 추후에 로그아웃 및 리프레쉬 토큰 기능을 구현해야 했는데, 각자 해당 업무에 투자할 수 있는 시간이 달라서 해당 업무에 더 많은 시간을 투자할 수 있는 사람이 맡게 되었습니다.

🤝 팀 소개

❣️팀 소개

멋진 개발자, 멋개!

저희 팀 이름은 ‘멋개’ 입니다.

선후배 개발자 분들에게 선한 영향력을 줄 수 있는 멋진 개발자가 되자는 의미로 ‘멋개’ 라고 지었습니다.

❣️팀원 소개

🧡김미정(쪙이)🧡 백엔드 https://github.com/meezzui	💛전다빈(감티)💛 백엔드 https://github.com/samjan29	🤎이슬(밤밤)🤎 프론트 https://github.com/seul-dev	💙이지선(비얌)💙 프론트 https://github.com/biyamn
한 번 시작한 일은 절대 포기하지 않아요😊 Springboot, Mybatis, Mysql, JPA 경험이 있으며 현재 JPA를 공부 중 입니다!! [담당기능] - sns 로그인 - 사용자 초대 관련 API	개발을 좋아하고 문제 해결이 재밌어요! [담당기능] - Refresh token - 로그아웃 - 질문, 답변 관련 API - 배포	컴포넌트화, 모듈화, 클래스화를 좋아합니다. [담당기능] - 온보딩 ui 구현 - 카카오 소셜 로그인 - 레이아웃 구현	새롭게 배우고 코드에 적용해보는 것을 좋아해요. [담당기능] - 무한 스크롤 - 페이지 라우팅 - 공통 컴포넌트 구현 - 배포 자동화