오늘 마실 술, 뭐랑 먹을까? 취향 기반으로 술-안주 페어링을 추천하고, 후기와 레시피, 페어링 팁을 공유하는 커뮤니티입니다.
| 팀원 | 팀원 | 팀원 | 팀원 | 팀원 |
|---|---|---|---|---|
 김윤지 |
 김진호 |
 남우경 |
 이재근 |
 이현수 |
오늘! 뭐랑? 은 사용자의 술 취향과 상황을 기반으로, 가장 잘 어울리는 안주/요리 페어링을 추천하고 그 결과를 커뮤니티에서 공유·토론할 수 있게 만든 서비스입니다.
- 🧪 페어링 추천 엔진: 술(소주/맥주/와인/사케/위스키 등)과 안주 태그(매콤/담백/기름짐/바삭/풍미 등) 매칭 점수 기반 추천
- 📝 레시피/후기/사진 공유: 누구나 요리·페어링 레시피와 맛 노트를 카드 형태로 게시
- 💬 취향형 반응(리액션) 4종:
술술 들어가요·참신해요·맛없어요·궁금해요 - 🛡️ 안전한 커뮤니티: 신고/블랙리스트, 운영자 승인 게시물 업로드 로직, 버전 이력 관리
- 📅 SNS 기능: 내가 쓴 글/댓글/즐겨찾기/팔로우, 사진 리뷰와 라운지 기능
.jpg?raw=true)
- 구독 서비스로 접하는 새로운 주류가 많아지면서, 소비자들은 어떤 안주와 조합해야 할지 고민이 늘어남.
- 집에서 혼자 또는 소규모로 술을 즐기는 문화 확산 → 간편하지만 잘 어울리는 안주 정보 필요.
-
사용자들은 단순히 먹고 마시는 것을 넘어서 직접 경험을 공유하고 싶어 함.
-
SNS, 블로그 등 파편화된 정보 대신 한 곳에서 후기·레시피·페어링 팁을 교류할 수 있는 장이 부족함.
-
즉석 추천: 술 종류 선택 → 안주 후보 (조회순/최신순) 탐색 가능
-
카테고리 탐색: 술 종류/조리법/맛 태그/지역 안주 필터
-
설명 가능한 추천: 매칭 근거(향/지방/매운맛 등 점수) 배지 표기
-
게시글/댓글/파일첨부/라운지: 자유로운 정보 공유와 참여
-
리액션 4종:
술술 들어가요·참신해요·맛없어요·궁금해요 -
신고/블랙리스트: 운영자 승인시 게시글 게시 / 신고 일정 횟수시 활동정지
-
내 페어링 기록, 즐겨찾기(북마크), 작성글/댓글/신고내역
-
사진 리뷰/라운지: 다른 사용자에게 추천받은 안주에 대한 리뷰 / 리뷰들을 한눈에 볼 수 있는 라운지 기능
-
술BTI: 설문 기반으로 주량·주종 성향을 재미있게 알아보는 테스트
-
월드컵 게임: 후보(술/안주)를 토너먼트 방식으로 선택해 최종 우승자 결정 -> 랭킹으로 조회 가능
공통
header
footer
home
회원/관리자
회원가입
게시글
게시글스크랩
게시글 작성
내 게시글 확인
다른 주류 게시글
안주 게시글
주류 게시글
사진 리뷰
목록
작성
상세페이지
이벤트
월드컵 게임
술 선택 화면
게임 진행
최종 우승 안주
주간 월드컵 순위
술BTI
설문지
결과 화면
라운지
라운지
문의사항
고객센터
내 문의사항 조회
문의사항 작성
문의사항 수정 및 삭제
관리자 문의사항 조회
관리자 문의사항 답변
마이페이지
내 마이페이지
다른사람 마이페이지
신고
신고 모달
월드컵 게임
술BTI
메시지
작성
댓글 작성
댓글 수정&삭제
고객센터
문의사항 생성
문의사항 수정 및 삭제
관리자 문의사항 조회
관리자 문의사항 답변
관리자 문의사항 수정 및 삭제
라운지
라운지 페이지 이동
마이페이지
마이페이지 페이지 이동
신고
게시글 작성
게시글 반응, 댓글
스크랩
조회순, 반응순, 댓글순 조회
| 조원 이름 | 회고 |
|---|---|
| 김윤지 | 백엔드 개발이 마무리된 후 프론트 개발을 시작하기 전에 기존 코드를 리팩토링하며 구조를 전반적으로 점검했다. 초기에 기능 구현에만 집중하느라 놓쳤던 부분들을 보완하면서 코드의 일관성과 유지보수성을 높였다. 이후 본격적으로 게시글 기능을 구현하며 프론트 개발을 진행했다. 게시글 CRUD를 비롯해 이미지 업로드, 정렬, 조회 기능을 직접 구현했고 사용자 경험을 고려해 본문 내 첫 번째 이미지를 자동으로 커버 이미지로 설정하는 로직을 추가했다. 또한 백엔드와의 연동 과정에서 응답 데이터 구조가 달라질 때마다 화면이 정상적으로 표시되지 않는 문제가 발생했지만 원인을 분석해 axios 인터셉터와 헬퍼 함수를 활용해 안정적인 데이터 흐름을 구축했다. 이러한 과정에서 단순히 UI를 만드는 것에 그치지 않고 서비스 전반의 데이터 흐름과 사용자 경험을 함께 고민하는 프론트엔드 개발자로 성장할 수 있었다. 팀원들과 협력해 문제를 해결하고 기능을 완성해 나가며 협업의 중요성을 실감했고 하나의 서비스가 완성되는 과정을 직접 경험하며 개발의 본질적인 즐거움을 느낄 수 있었다. 이번 프로젝트는 나에게 기술적 성장뿐 아니라 문제를 끝까지 해결하려는 끈기와 자신감을 심어준 값진 경험이었다. |
| 김진호 | 두번째 프로젝트 이후 약 한달 동안의 시간이 있었는데, 10일 가량의 긴 연휴동안 지난 백엔드 프로젝트에서 부족했던 점들을 보완하고, 프론트엔드 수업을 들었다. HTML 과 CSS를 배우면서 웹 페이지의 구조와 시각적인 요소를 배우고, Node.js와 JavaScript를 통해 함수형 프로그래밍 언어와 이벤트, 비동기적 데이터 처리에 대해 배우고, 이것들을 SPA로 개발하기 위한 프레임워크인 Vue를 배웠다. 프론트엔드 프로젝트는 특히나 시간이 많이 부족해 보여서 최대한 처음에 프로젝트 구조를 잘 짜놔야겠다고 생각해서, 수업 내용과 다른 프로젝트들을 참고해서 폴더 구조를 만들었다. 예를들어, 팀원간 분업을 효율적으로 하기 위해 공통된 컴포넌트는 같이 관리/개발해서 코드 중복을 피하고 라우터 구조를 먼저 설계해서 그 라우터가 뿌려주는 페이지 구조에 맞춰 체계적으로 개발을 진행했다. 지금까지의 프로젝트와는 달리 사용자에게 직접 보이고, 상호작용하는 웹을 처음 만드는 과정은 굉장히 흥미로웠다. 단순히 백엔드와 연동하고 동작하는것에 집중하는것이 아니라, "내가 진짜 사용자라면 어떻게 생각할까"라는 생각을 가지고 우리 웹사이트의 철학과 킥/아하 모먼트등을 생각해서 UX/UI도 신경써서 만들었다. 짧은 시간이였지만 후회없이 최선을 다했고, 결과도 만족스러웠다. |
| 남우경 | 백엔드 프로젝트가 끝난 후 기능 수정 및 추가해야하는 리펙토링들이 많았습니다. 프론트 프로젝트 하기 전에 리펙토링들을 진행하였고, 대부분 완료를 하였으나 프론트 프로젝트를 진행하면서 리펙토링이 더 추가되고 수정되어야 하는 것들이 점점 늘어났습니다. 곰곰히 생각하여 사전에 리펙토링을 정의하고 수정하였지만, 프론트적 관점으로 보았을 때 필요한 것들이 많았습니다. 여기서 제가 느낀 점은 백엔드를 개발하면서 프론트적 관점에서도 생각하면서 기능을 개발을 해야겠다는 점입니다. Vue를 통해 프론트 개발을 진행 중 한 가지를 깨달았습니다. 프론트에서 백엔드 기능을 개발 할 수도 있는 것이었습니다. 하지만 이렇게 백엔드 기능을 프론트에서 다 처리한다면 유지보수에 힘들다는 점입니다. 처음 페이지를 구성하면서 새롭기도 했지만, 제가 세세하게 생각했던것보다 많은 기능을 구현하지 못해서 아쉬웠습니다. 특히 이벤트의 월드컵게임 같은 파트는 백엔드에서 하드 코딩을 통해 알고리즘을 작성해 그것을 프론트에서 불러와서 진행하고 싶었지만 프론트 상에서 알고리즘을 통해 작성하였습니다. 다음 데브옵스, 최종프로젝트 때는 하고자하는 기능들을 명확히 정의하고 100% 구현하려고 할 것이며 지금보다 더 발전된 모습으로 우상향을 그릴 것입니다. |
| 이재근 | 이번 프로젝트는 이전 프로젝트에서 구축한 백엔드를 기반으로 시작했다. 초기 단계에서 전체적인 화면 구성이나 웹의 컨셉은 정했었지만, 프론트엔드를 본격적으로 구현하면서 세부적인 화면 구성과 흐름이 달라진다는 걸 느꼈다. 이에 따라 프론트엔드 변경 사항을 반영하기 위해 백엔드 로직을 수정해야 하는 경우가 있었다. 이 과정에서 프론트, 백엔드, 디자인이 단순히 역할을 나누는 것이 아니라, 서로 유기적으로 맞물리며 발전해야 한다는 점을 몸소 느꼈다. 결국 이번 경험을 통해, 설계를 잘 하는 것도 물론 중요하지만 개발 과정에서의 지속적인 소통과 조율 또한 매우 중요하다는 것을 깨달았다. 프론트, 백엔드, 디자인이 조화롭게 어우러질 때 비로소 완성도 높은 서비스가 만들어진다는 점을 배울 수 있었고, 프로젝트 결과 또한 만족스러웠다. |
| 이현수 | 이번 프로젝트에서는 처음으로 Vue를 사용해 보았다. 막연히 컴포넌트를 나눠서 개발한다는 말은 알고 있었지만, 실제로 화면을 쪼개고 상태를 흘려보내고, 재사용 가능한 조각으로 쌓아 올리는 과정을 거치면서 컴포넌트 단위 설계의 중요성을 느꼈다. 특히 리스트/상세/작성 같은 흐름을 구성할 때 UI를 기능별로 분리하지 않으면, 한 파일이 비대해지고 상태 관리가 꼬여 수정도 위험해진다는 사실을 뼈저리게 경험했다. 결과적으로 처음부터 과감하게 쪼개기—작은 책임을 가진 컴포넌트로 구획하기—명확한 props/emit 설계하기가 생산성과 유지보수성 모두에 이롭다는 걸 배웠다. 백엔드는 완벽하지 않아도 기본 골격과 계약(API 스펙)이 단단해야 프론트가 편하다는 것도 크게 느꼈다. 실제로 엔드포인트 주소, HTTP 메서드, 요청/응답 DTO, 에러 코드 규칙 등 최소한의 약속이 먼저 잡혀 있어야 Axios 모듈과 뷰 컴포넌트를 빠르게 붙일 수 있었다. 반대로 이 약속이 비어 있거나 중간에 자주 바뀌면, 프론트는 더미 데이터와 임시 분기문을 늘려가며 시간을 태우게 된다. 이번에 경험해 보니 초기 설계 단계에서 Swagger로 문서화하고, Postman으로 샘플 요청/응답을 확정해 두는 것만으로도 시행착오가 크게 줄었다. |