성능 최적화를 한 번도 제대로 알아본 적이 없는 것 같아, 면접을 준비하면서 어떠한 방법들과 개념들이 있는지 알아보았다.

✅ 전송 최적화 - 네트워크 구간

브라우저가 페이지를 표시하기 위해 서버에서 HTML , CSS , JS , 이미지 등 여러 파일을 받아오는데, 이 다운로드 과정을 줄이거나 빠르게 만드는 방법이다.

📍 코드 분할 : Code Splitting

• 처음 페이지를 열 때, JS 파일이 너무 크면 다운로드, 해석, 실행이 오래 걸린다.
• 그래서 코드를 잘게 쪼개 필요한 순간에만 불러오면 초기 로딩이 빨라진다.
• React.lazy , import() 를 사용하여 해당 기능이 필요할 때만 가져오게 할 수 있다.
• 다만 지나치게 쪼개면 네트워크 요청이 많아져서 오히려 느려질 수 있다.

📍 트리 셰이킹 : Tree Shaking

• 번들에 사용하지 않는 코드까지 포함되면 파일이 불필요하게 커진다.
• 사용되는 코드만 남기고 나머지를 제거 하면 전송 용량이 줄어든다
• ES Module 방식 (import/export) 을 사용하고, 라이브러리는 필요한 함수만 가져오면 된다.

📍 압축 : gzip/brotli

• JS , CSS , HTML 은 텍스트이므로 압축하면 용량을 20~70% 줄일 수 있다.
• 서버나 CDN에서 Content-Encoding: br 이나 gzip 을 설정한다.
• 이미 압축된 이미지/폰트는 다시 압축해도 효과가 없다.

📍 이미지 최적화 : WebP/AVIF, lazy-loading

• 이미지가 페이지 로딩 속도를 가장 많이 잡아먹는 경우가 많다.
• JPG/PNG 대신 용량이 적은 WebP/AVIF 포맷을 사용한다.
• 또는 loading="lazy" 로 화면에 보이기 직전까지 다운로드를 지연시킨다.

📍 CDN & 캐시 : Cache-Control, ETag

• 같은 파일을 재방문 때 다시 다운로드하지 않게 하면 빠르다.
• 파일명에 버전 해시를 붙이고, CDN 에서 장기 캐시를 설정한다.

✅ 렌더링 최적화

서버에서 파일을 받아온 후, 브라우저가 빠르게 렌더링할 수 있도록 하는 방법

📍 SSR/SSG

• 서버에서 HTML 을 만들어 보내면, 브라우저가 바로 표시 가능하다.
• 검색 노출이 중요하거나 첫 홤녀 표시 속도가 중요한 경우 이를 사용하면 좋다.
• 하이드레이션(서버 렌더 HTML에 JS 이벤트 연결) 비용이 너무 크면 상호작용이 느려질 수 있다.

📍 CSR 지연 로딩

• 한 번에 많은 JS 를 실행하면 첫 화면 표시가 늦어진다.
• 화면 아래쪾의 컴포넌트는 InterSection Observer로 실제 보일 때 로딩하게 한다.

📍 Critical CSS / 폰트 최적화

• 화면 표시를 막는 CSS/폰트 로딩을 줄이면 LCP가 개선된다.
• 필요한 CSS만 HTML에 인라인, 나머지는 지연로딩
• 폰트는 rel=preconnect +font-display:swap 을 사용한다.
• CSS의 @import 는 로딩 차단이 커서 피해야 한다.

📍 레이아웃 스래싱 방지

• DOM의 레이아웃을 읽고 쓰는 동작이 섞이면 브라우저가 계쏙 다시 계산해야 해서 프레임 드랍이 난다.
• 읽기 작업 후 쓰기 작업으로 묶고, 위치 변경은 transform 을 사용한다.

✅ 런타임 최적화 - 실행 중

이미 로드된 페이지가 사용자의 입력/스크롤 등에 빠르게 반응하도록 실행 중 동작을 최적화하는 방법이다.

📍 메모이제이션

• 같은 계산을 반복하지 않게 캐싱해 CPU 낭비를 줄인다.
• React의 useMemo , useCallback , React.memo 등을 사용하면 된다.
• 다만, 계산이 빠른 작업에 남용하면 메모리 낭비가 될 수도 있다.

📍 가상 스크롤

• 수천 개의 리스트를 한 번에 그리면 느려진다.
• 화면에 보이는 범위만 DOM에 렌더링, 나머지는 가상으로 관리한다.

📍 이벤트 위임

• 수많은 자식 요소마다 이벤트를 달면 메모리와 성능이 낭비된다.
• 부모 요소에 이벤트를 한 번만 달고 event.target 으로 분기 처리를 해준다.

📍 Debounce/Throttle

• 입력/스크롤 같은 이벤트가 너무 자주 발생하면 렌더링이 느려진다.
• Debounce : 마지막 이벤트 후 일정 시간만 실행
• Throttle : 일정 주기마다 실행

🔗 핵심 지표

• LCP : 가장 큰 컨텐츠 표시까지 걸린 시간 (목표 ≤ 2.5s)
• CLS : 화면 요소의 예기치 않은 움직임 정도 (목표 ≤ 0.1)
• INP : 사용자 입력 후 반응 시간 (목표 ≤ 200ms)

• 자바스크립트는 원래 브라우저 안에서만 실행됨
• Node.js는 JS를 브라우저 밖에서도 실행할 수 있게 해주는 환경
• 우리가 사용하는 개발 도구들(Vite, ESLint, Tailwind 등)은 모두 Node.js 기반

🧐 패키지 매니저란 무엇이고, 어떤 역할을 할까?

• 다른 사람이 만든 라이브러리를 설치하고 관리해주는 도구
• 대표적으로 npm, yarn, pnpm 이 있음
• 패키지를 설치하면 node_modules/에 실제 파일이 설치되고 package.json과 lock 파일에 기록됨

🧐 npm, yarn, pnpm 중 무엇을 써야 할까?

🚨 주의 : 혼용 금지! lock 파일 충돌 + 구조 꼬임 발생

🧐 패키지 매니저들이 빠르다/디스크 적게 쓴다는 건?

• 캐시 : 한 번 받은 패키지를 저장해두고 다음에 재사용
• 디스크 용량 : 같은 파일을 여러 번 복사하느냐(→ 용량 낭비)

pnpm 은 하드링크를 사용해서 파일을 한 번만 설치하고 각 프로젝트가 링크만 걸어 쓰기 때문에 빠르고 가볍다.

🔎 하드링크란?

• 복사본이 아니라 이름표를 하나 더 만드는 방식
• 파일을 여러 경로에서 공유해서 접근하지만, 디스크에선 실제 파일은 하나만 존재

🧐 번들러란?

• 여러 파일(JS/CSS/이미지)을 하나로 묶어주는 도구
• 브라우저는 파일을 한 번에 불러올 수 없기 때문에, 번들러가 파일을 묶고 압축해서 효율적으로 전달해줌

🧐 Webpack과 Vite는 어떤 차이가?

🧐 HMR?

Hot Module Replacement

• 파일을 수정했을 때, 전체 페이지 새로고침 없이, 바뀐 모듈만 교체해서 적용되는 기능
• 상태/스크롤/입력값을 유지하면서 개발할 수 있어서 개발 속도가 엄청 빨라짐

🧐 SWC?

Speedy Web Compiler

• Babel보다 훨씬 빠르게 JS/TS/JSX를 변환해주는 컴파일러
• Rust로 만들어져서 속도가 빠르고, 최신 프레임워크에서 채택 중

• 프락시는 클라이언트와 서버 사이에서 중간자 역할을 하는 서버
• 클라이언트는 프락시를 통해 요청을 보내고, 프락시는 실제 서버 대신 요청 후 응답을 클라이언트에 전달
• 개발 중 CORS 문제 회피를 위해 프락시 서버를 설정하기도 한다.
• 요청이 프락시를 거치면, 실제 서버 주소가 숨겨지고 보안 또는 속도 개선이 가능하다.

✨ 포인트

• 캐시 프락시 : 자주 요청되는 리소스를 저장해 응답 속도를 높이고 트래픽 감소
• 콘텐츠 필터링 : 회사/학교 등에서 특정 사이트 차단할 때 사용
• 로깅 및 감시 : 요청 기록을 분석하거나 로그를 저장할 수 있다.

✅ㅤ웹 중개자

• HTTP 프락시 서버는 웹 서버이기도 하고, 웹 클라이언트이기도 하다.
• 프락시 서버는 하나의 클라이언트가 독점적으로 사용할 수도 있고 여러 클라이언트가 공유할 수도 있다.
• 대부분의 프락시는 공용이며, 공유된 프락시다.
• 중앙 집중형 프락시를 관리하는 게 더 비용효율이 높고 쉽다.

✅ㅤ프락시 VS 게이트웨이

실질적으로 프락시와 게이트웨이의 차이점은 모호하다. 프락시가 때떄로 약간의 프로토콜 변환을 하기도 하기 떄문

• 프락시 : 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
• 게이트웨이 : 서로 다른 프로토콜로 말하더라도 서로 간의 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작

✅ㅤ왜 프락시를 사용하는가?

• 서버는 각 리소스에 대해 올바른 MIME 타입을 설정해야 한다 ➡️ Content-Type 헤더

• 실용적이고 유용한 것이라면 무슨 일이든 한다.

• 보안을 개선하고 성능을 높여주며, 비용을 절약한다.

• 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에, 프락시는 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정할 수 있다.

• 예 ) 어린이 필터, 문서 접근 제어자, 보안 방화벽, 웹 캐시, 대리 프락시(=서버 가속기), 콘텐츠 라우터, 트랜스코더, 익명화 프락시

🔎ㅤ트래픽

• 네트워크 상에서 데이터가 오가는 양을 의미한다.
• 주로 클라이언트 ↔️ 서버 간에 오고 가는 요청과 응답을 모두 포함한다.

✅ㅤ프락시 서버 배치

어떻게 사용할지에 따라 프락시는 어디에든 배치할 수 있다.

📍 클라이언트 근처: 포워드 프록시

• 위치 : 클라이언트와 인터넷 사이
• 예시 : 사내 네트워크에서 외부 접속 제한할 때
• 기능 : IP 숨김, 보안 필터링, 내부 사용자 제어
• 활용 : CORS 우회 프록시로 활용, 외부 API에 서버 없이 프록시 요청 가능

📍 서버 근처: 리버스 프록시

• 위치 : 서버 앞단 (외부에서 보면 서버처럼 보임)
• 예시 : Nginx, Apache HTTPD, AWS ALB
• 기능 : 로드 밸런싱, 캐싱, SSL 종료, 보안
• 활용 : 프론트 요청을 리버스 프록시가 받아서 내부 API 서버에 전달

📍 네트워크 중간: 게이트웨이

• 위치 : 시스템 간 경계 지점 (API Gateway, 통신 변환)
• 기능 : 프로토콜 변환 (HTTP ↔ gRPC 등), 인증, 요청 라우팅
• 예시 : AWS API Gateway, Kong
• 활용 : 다양한 API를 단일 엔드포인트로 관리할 때 사용 (예: /api → 내부 마이크로서비스로 분기)

📍 보안 터널링 목적: 터널 프록시

• 위치 : HTTPS 요청 시 중간에서 암호화된 트래픽 전달
• 기능 : CONNECT 메서드로 TLS 연결만 열어줌
• 활용 : HTTPS 프록시 사용 시 인증서 문제 디버깅 시 이해 필요

✅ㅤ어떻게 프락시가 트래픽을 처리하는가

트랙픽은 클라이언트가 서버에 보내는 요청 + 서버가 클라이언트에 보내는 응답이고, 프락시는 이 요청/응답을 가로채서 중계하거나 조작할 수 있다.

• 프락시는 요청 헤더, 응답 헤더, 본문을 모두 수정할 수 있다.
• 응답 본문에서 금칙어를 필터링하거나, 이미지 포맷을 변경하는 것도 가능하다.

✅ㅤ클라이언트 프락시 설정

📍ㅤ브라우저 설정

• 사용자가 수동으로 브라우저에 프락시 주소를 입력
• 자동 프락시 설정 URL (PAC 파일)를 사용

📍 운영체제 차원에서 설정

• window, macOS 등에서는 시스템 전체에 적용할 전역 프락시 설정 가능
• 이 경우 브라우저뿐 아니라 curl , npm, git, 터미널 요청 등에도 적용된다.

📍 환경 변수 이용

• CLI 환경이나 서버 스크립트에서 자주 사용

✅ㅤ프락시 요청의 미묘한 특징

1️⃣ㅤURI 변경은 매우 민감하다

프락시 서버는 클라이언트 요청을 다른 서버로 전달할 때 절대 URI를 수정하지 않아야 한다.

• http://www.example.com:80/index.html처럼 포트 번호를 명시적으로 추가하거나, %7E 같은 이스케이프 문자로 인코딩된 URL을 디코딩하거나 재인코딩하는 일은 요청이 실패하거나 의도치 않은 응답을 받게 만들 수 있다.

HTTP 명세: 프락시는 절대 경로를 변경해서는 안 되며, 유일한 허용은 빈 경로를 /로 바꾸는 것뿐이다.

2️⃣ㅤ브라우저의 호스트명 자동 완성 차이

사용자가 주소창에 yahoo 라고 입력하면, 프락시의 존재 여부에 따라 브라우저의 동작이 달라진다.

📍 프락시가 없을 때

• 브라우저는 다양한 자동 확장을 시도한다.

  www. 접두사 + .com 접미사 → www.yahoo.com

• 로컬 DNS 서픽스 자동 검색 → yahoo.company.com 또는 host7.oreilly.com 등

📍 프락시가 있을 때

• 자동 확장이 중지된다.
• 브라우저는 그대로의 호스트명(예: yahoo)을 프락시에 전달한다.
• 따라서, 프락시가 직접 DNS 조회하거나 자체적으로 호스트명을 보완해야 한다.

✅ㅤ프락시 캐시

클라이언트와 서버 사이에서 캐시 역할을 수행하여 동일한 요청에 대해 서버에 재요청하지 않고 저장된 응답을 제공할 수 있다.

📍 캐시의 작동 방식

• 응답 저장 : 서버로부터 받은 응답을 저장하여, 동일한 요청이 들어오면 저장된 응답을 반환
• 조건부 요청 : 저장된 응답이 최신인지 확인하기 위해 서버에 조건부 요청을 보낼 수 있다.

📍 캐시 제어

프락시 캐시의 동작을 제어하기 위해 다양한 HTTP 헤더를 사용할 수 있다.

• Cache-Control : 캐시 동작을 세부적으로 제어할 수 있다.

  • no-cache : 응답을 캐시하지 않는다.
  • max-age : 응답의 최대 유효 시간을 지정한다.

• Pragma : HTTP/1.0에서 사용되던 캐시 제어 헤더로, no-cache 값을 사용하여 캐시를 방지한다.

✨ 포인트

• 실시간 데이터가 필요한 API 응답에는 Cache-Control: no-cache를 설정하여 캐시를 방지할 수 있다.
• 변경이 적은 정적 리소스에는 적절한 max-age 값을 설정하여 캐시를 활용할 수 있다.

📍 프락시 인증 방식

• Proxy-Authenticate 헤더 : 프락시 서버가 클라이언트에게 인증을 요구할 때 사용
• Proxy-Authorization 헤더 : 클라이언트가 프락시 서버에 인증 정보를 제공할 때 사용함

📍 프락시 로깅

프락시 서버는 요청 및 응답에 대한 로그를 기록하여 트래픽 분석 및 문제 해결에 활용할 수 있다.

• 요청 정보 : 클라이언트 IP, 요청 메서드, 요청 URL, 요청 시간 등
• 응답 정보 : 응답 상태 코드, 응답 시간, 응답 크기 등

• 웹 서버는 HTTP 요청을 받아 응답을 돌려주는 프로그램이다.
• 주된 역할은 리소스 제공, 요청 라우팅, 애플리케이션과 연동 등이다.
• 정적 컨텐츠 제공(HTML, CSS, JS, 이미지)과 동적 컨텐츠 처리(API, 서버 로직 실행) 모두 가능하다.
• 보안, 인증, 로깅, 캐싱, 압축 등을 통해 웹 통신을 최적화하고 관리한다.

✨ 포인트

• 정적 리소스 제공 : 프론트엔드 빌드 결과물을 서빙하는 기본 역할
• MIME 타입 관리 : 서버가 올바른 Content-Type 을 세팅해야 브라우저가 제대로 해석 가능
• 캐싱 제어 : Cache-Control, ETag 를 통해 정적 파일 업데이트 관리
• 압축 : 서버가 리소스를 압축해 전달하면 페이지 로딩 속도 형상
• CORS 처리 : 프론트와 백엔드 분리된 구조에서는 CORS 설정 필수 고려
• 리버스 프록시 사용 : Nginx 등 프록시 서버를 통해 API 서버와 프론트엔드 앱을 연결
• 보안 : 모든 통신은 기본적으로 HTTPS 적용이 필수
• 서버 오류 핸들링 : 404 ,500 에러 처리 페이지 커스터마이징 필요

✅ㅤ웹 서버의 기본 동작

• HTTP 요청 수신 ➡️ 요청 분석 ➡️ 적절한 응답 생성 ➡️ 전송 흐름으로 동작
• 리소스를 반환하거나, 동적 애플리케이션 서버에 요청을 넘겨 처리 결과를 받아 전달한다.

✅ㅤ정적 컨텐츠와 동적 컨텐츠

빌드된 React/Vue 앱은 정적 파일로 서버가 서빙하지만, API 요청은 동적으로 처리된다.

• 정적 컨텐츠 : HTML, CSS, JS, 이미지 파일처럼 변하지 않는 리소스
• 동적 컨텐츠 : 서버 측 애플리케이션이 요청에 따라 결과를 만들어내는 리소스

1. 사용자가 /index.html 요청

• 웹 서버가 정적 파일을 바로 전달

2. 사용자가 /user?id=1 요청

• 웹 서버가 동적 요청임을 인식
• WAS(Spring 등)에게 요청을 전달
• WAS가 DB에서 유저 정보를 조회
• WAS가 HTML을 생성해 웹 서버에 전달
• 웹 서버가 최종 응답을 클라이언트에 전달

✅ㅤMIME 타입

• 서버는 각 리소스에 대해 올바른 MIME 타입을 설정해야 한다 ➡️ Content-Type 헤더

✅ㅤ웹 서버의 추가 기능

• 캐싱 제어 : Cache-Control , ETag 헤더 설정
• 압축 : gzip , Brotli 압축을 통해 파일 크기 줄이기
• 보안 : HTTPS 적용, HSTS 설정
• 인증 : HTTP 기본 인증, 토큰 기반 인증 연동
• 로깅 및 모니터링 : 요청/응답 기록, 오류 추적

Cache-Control: no-cache , Cache-Control: max-age=~ 같은 설정으로 정적 파일 갱신 주기 조절

✅ㅤ리버스 프록시 서버

프론트 서버를 /에, API 서버를 /api로 연결하는 설정이 기본 패턴이다.

• 클라이언트 요청을 받아 실제 서버로 전달하는 중간 서버
• Nginx , Apache 가 많이 사용된다.
• 로드 밸런싱, HTTPS 종단, 정적 파일 서빙, API 서버/프론트 서버 분리 연결

✅ㅤ가상 호스팅

스테이징 서버와 운영 서버를 같은 서버에서 운영할 때 유용

• 하나의 물리적 서버에서 여러 도메인을 서비스하는 기술
• IP 주소 공유 방식으로 동작

✅ㅤ서버 오류 처리

• 4xx, 5xx 에러를 서버가 감지하고 적절한 에러 페이지를 응답한다.
• 커스텀 에러 페이지를 설정할 수 있다.

브라우저에서 커스텀 404 페이지를 띄우거나 SPA 앱에서는 history fallback 처리가 필요

🔎ㅤHistory Fallback

SPA에서는 주소창에 어떤 경로를 입력해도 서버가 항상 index.html 을 응답하여, 클라이언트 라우터가 화면을 알아서 전환하도록 만드는 설정

• SPA는 하나의 index.html 로 모든 페이지를 처리한다.
• 실제로 /about ,/profile 같은 경로에 별도 파일이 없다.
• 브라우저 주소창에 직접 경로를 입력하면 서버가 해당 파일을 찾으려고 한다 ➡️ 파일 ❌ = 404 에러
• 이를 막기 위해 서버가 항상 index.html 을 반환하도록 설정한다.
• 클라이언트 라우터가 URL을 해석해 알맞은 화면을 렌더링한다.

✅ㅤ리다이렉션

• 서버가 클라이언트에게 "다른 URL로 가라"고 알려주는 것
• 서버 응답 코드 3xx 로 동작한다.
• 리다이렉션 설정이 잘못되면 무한루프, SEO 문제를 일으킬 수 있다.

✅ㅤ보안 (SSL/TLS)

• HTTPS 연결을 위해 서버에 인증서를 설치한다. ➡️ SSL/TLS
• 클라이언트-서버 간 데이터 암호화를 보장한다.

✅ㅤ부하 분산 (로드 밸런싱)

• 여러 대의 서버에 트래픽을 분산시켜 성능과 안정성을 높인다.

프론트에서 가끔 "한 번 로그인했는데, 다른 서버에서는 로그아웃 상태" 와 같은 문제가 생길 수 있다. 이때, 세션 스토리지 방법이 중요하다.

✅ㅤ로깅

• 서버는 요청과 응답에 대한 로그를 남긴다.
• 요청 시간, 요청 IP주소, 요청 URL, 응답 상태 코드, 응답 시간
• 로깅은 문제 분석, 해킹 탐지, 사용량 분석 등에 필수적이다.

• HTTP 통신은 TCP 커넥션 위에서 이루어진다.
• 커넥션 관리가 제대로 안 되면 느린 속도, 리소스 낭비, 서버 과부하가 발생한다.
• HTTP/1.0 : 요청마다 새로운 커넥션을 생성 (비지속 연결)
• HTTP/1.1 : 기본적으로 커넥션을 유지 (지속 연결 - keep-alive)
• 성능 최적화를 위해 커넥션 재사용, 커넥션 풀, 타임아웃 관리가 필요하다.
• 프록시와 게이트웨이는 클라이언트-서버 사이에서 각각의 커넥션을 따로 관리한다.
• HTTP/2, HTTP/3에서는 하나의 연결로 여러 요청을 동시에 처리한다.

✨ 포인트

• TCP 커넥션은 비용이 크다 → 가능하면 재사용 해야 한다.
• 서버당 병렬 커넥션 수 제한 → 리소스 고갈(포트, CPU) 방지 (브라우저는 1도메인 당 6개 제한)
• 커넥션 타임아웃 설정 → 유휴 커넥션을 방치하면 메모리 누수/자원 낭비 위험
• 오래된 Keep-alive 커넥션을 주기로 정리 → 서버 부하 최소화
• HTTP/1.1 → Keep-alive 주의, 파이프라이닝 거의 사용 ❌
• HTTP/2~ → 커넥션 1개로 다수 요청, 멀티플렉싱 적극 활용

✅ㅤ커넥션 관리

API 서버 만들 때, 커넥션 풀 설정 ( keep-alive timeout, idle timeout ) 반드시 해야 한다.

• HTTP 자체는 상태를 유지하지 않지만, 실제 통신은 TCP 커넥션에 의존한다.
• 커넥션을 열고 닫는 작업은 네트워크, 서버, 클라이언트 모두에게 큰 비용을 발생시킨다.
• 따라서 "커넥션을 어떻게 효율적으로 유지하고, 끊고, 재사용할지"를 설계하는 것이 중요하다.

✅ㅤ비지속 연결 (HTTP/1.0)

기본은 요청 1개 → 응답 1개 → 커넥션 종료

• 매번 TCP 핸드셰이크(3-way handshake) 비용 발생
• 많은 리소스 다운로드 시 매우 느리다.
• Connection: keep-alive 헤더를 명시적으로 추가하면 여러 요청을 하나의 커넥션에서 처리할 수 있지만, 완벽 지원이 되지 않는 서버가 많았다.

✅ㅤ지속 연결 (HTTP/1.1)

• 기본값이 keep-alive 로 변경
• 커넥션을 끊지 않고 다음 요청까지 유지 → 핸드셰이크 오버헤드 감소
• 일정 시간 동안 추가 요청이 없으면 서버가 커넥션을 닫는다.
• 필요시 명시적으로 Connection: close 를 보내서 끊을 수 있다.

서버에서 keep-alive 타임아웃을 짧게 5~15초 정도로 잡아 서버 리소스를 절약

✅ㅤ파이프라이닝 (HTTP/1.1)

• 여러 요청을 순서대로 넣고 응답도 순서대로 받는다.
• 첫 번째 요청이 느리면, 뒤에 대기 중인 모든 응답이 지연된다 → HOLB
• 거의 쓰이지 않았다. (브라우저도 기본으로 비활성화)

HTTP/2 멀티플렉싱으로 대체되었다.

✅ㅤ병렬 커넥션의 사용

• 브라우저는 하나의 서버(도메인)당 최대 6개 커넥션 정도를 동시에 연다.
• 병목을 줄이고, 리소스 로딩 속도를 개선하기 위해
• 과거에는 도메인 샤딩 기법으로 커넥션 수를 늘렸다.
• HTTP/2 이상 사용 시 도메인 샤딩 금지 ❌ → 오히려 커넥션이 분산돼 성능 저하

🔎ㅤ도메인 샤딩

• 리소스를 여러 도메인에 분산해서 요청하는 기술이다.
• 여러 서브도메인에 리소스를 나눠 배포해 병렬로 더 많은 리소스를 동시에 다운받을 수 있다.
• 장점 ) 페이지 로딩 속도 개선, 서버 부하 분산 가능
• 단점 ) 추가 커넥션 생성 비용 발생, 오버헤드 발생, 복잡한 리소스 관리

✅ㅤ커넥션 관리 전략

• 지속 커넥션 사용 Keep-alive 활성화
• 유후 커넥션에 적절한 타임아웃 설정
• 커넥션 풀로 연결 수 제어 및 관리
• 부하가 심할 경우, 커넥션 수 제한과 L7 로드밸런싱 병행
• 서버 리소스를 보호하기 위해, 클라이언트 Keep-alive 를 무한히 허용하지 않는다.

✅ㅤ프록시와 커넥션 관리

• 프록시는 클라이언트와 서버 양쪽에 각각 커넥션을 맺는다.
• 프록시와 서버 간 커넥션을 계속 열어두고 다수 클라이언트 요청을 처리할 수 있다.
• 프록시가 커넥션 풀을 적극적으로 관리해 성능 최적화를 한다.

✅ㅤHTTP/2 & HTTP/3의 등장

📍 HTTP/2

• 하나의 TCP 커넥션에서 여러 요청/응답을 동시에 처리
• 헤더 압축으로 네트워크 최적화

📍 HTTP/3

• TCP 대신 UDP 기반 QUIC 프로토콜 사용
• 핸드셰이크 비용 감소, 리커넥트 속도 대폭 개선

HTTP 커넥션 관리는 서비스 성능과 서버 안정성의 핵심이다.

• HTTP 메시지 구조 : 시작줄 → 헤더 → 본문 순서의 데이터 블록
• 요청 메시지 : <메서드> <요청 URL> <버전> 으로 시작
• 응답 메시지 : <버전> <상태 코드> <사유 구절> 로 시작
• 헤더 : 요청/응답에 대한 부가정보 전달 (key:value 형태)
• 상태 코드 : 응답 결과를 1xx~5xx로 분류하여 나타냄
• CORS 관련 헤더 : 출처 제한, 인증 처리 등을 제어하는 보안 관련 필드

✨ 포인트

• PUT : 전체 수정 / PATCH : 일부 수정
• 로그인 상태 유지 → 토큰/JWT/쿠키 + Authorization 헤더 조합 필요
• Content-Type: application/json → JSON 형식 명시
• Authorization: Bearer <token> → 인증 정보 포함
• Accept → 받고 싶은 응답 포맷 설정

✅ㅤ메시지의 흐름

HTTP가 인터넷의 배달원이라면, HTTP 메시지는 소포와 같다. 데이터를 담은 메시지는 클라이언트 ↔️ 프락시 ↔️ 서버 사이를 흐르며 정보를 교환한다.

• 시작줄 → 헤더 → 본문 순으로 구성
• 인바운드 : 서버를 향함
• 아웃바운드 : 사용자 에이전트로 돌아옴
• 업스트림/다운스트림 : 네트워크의 방향을 나타냄

✅ㅤ메시지 문법

📌 요청 메시지 구조

<메서드> <요청 URL> <버전>
<헤더>
<본문>

📌 응답 메시지 구조

<버전> <상태 코드> <사유 구절>
<헤더>
<본문>

본문이 없더라도, 헤더 블록은 반드시 CRLF(빈 줄)로 끝나야 한다.

✅ㅤ메서드

✅ㅤ헤더

✅ㅤ본문

• 전송할 실제 데이터
• POST , PUT 등에서 주로 사용
• 프론트엔드에서는 보통 JSON.stringify() 로 감싼 JSON 데이터를 전송

  body: JSON.stringify({ name: 'Bo00oa' })

✅ㅤ상태코드

📌 주요 상태 코드

✅ㅤCORS 관련 헤더

• URL : Uniform Resource Locator - 웹 리소스의 주소
• URI : Uniform Resource Identifier - URL을 포함하는 상위 개념(이름 또는 위치로 식별)
• 스킴 : http:// 와 같은 통신 프로토콜 지정
• 호스트 : 도메인 또는 IP 주소
• 경로 : 리소스의 위치
• 쿼리 스트링 : ?key=value 형식의 추가 파라미터
• 프래그먼트 : #section1 - 브라우저 내 특정 위치 이동 (서버에는 전송 ❌)

<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

✨ 포인트

• 쿼리 파라미터는 검색, 필터링 등에 자주 활용
• 브라우저 라우팅(SPA)에서 # 사용 여부는 해시 라우터 VS 히스토리 라우터 기준

✅ㅤURL은 단순한 위치가 아닌 식별자

• 자원은 이름을 통해 식별된다.
• URL 은 리소스의 주소이자 이름이며, 웹에서 리소스를 식별하기 위한 표준적인 방법
• URL 은 단순한 위치가 아니라 자원의 고유한 식별자
• 클라이언트와 서버가 리소스를 주고받기 위해 사용하는 공통 언어

✅ㅤURL/URI/URN의 관계

URL은 URI의 하위 개념, URI는 다시 두 가지로 나뉜다

URL (Locator): 리소스의 위치를 명시 → https://example.com/index.html URN (Name): 리소스의 고유 이름을 명시 → urn:isbn:0451450523

✅ㅤ호스트와 포트

1️⃣ 호스트

• 리소스를 호스팅하는 인터넷 상의 장비를 의미
• 일반적으로 도메인 이름 또는 IP 주소로 표현
• 클라이언트는 이 정보를 통해 어떤 서버에 요청을 보낼지 판단

2️⃣ 포트

• 서버 내부에서 리소스를 제공하는 프로그램이 사용하는 네트워크 포트
• HTTP의 기본 포트는 80 , HTTPS는 443
• 포트는 명시하지 않으면 기본값을 사용하지만, 필요 시 명시할 수 있다.

✅ㅤ사용자 이름과 비밀번호

• 일부 URL 스킴(특히 FTP 등)은 인증 정보를 포함할 수 있다.
• URL에 포함된 형식 : ftp://username:password@host/path
• 생략 시, 기본 사용자 이름과 브라우저의 기본 비밀번호를 사용하는 경우도 있다.
• 보안 문제로 인해 현대 웹에서는 거의 사용되지 않으며, HTTPS에서는 권장되지 않는다.
  

✅ㅤ경로 (path)

• 서버 내에서 리소스가 어디에 위치하는지를 나타냄
• / 를 기준으로 여러 개의 경로 조각으로 나뉜다.
• 각 경로 조각은 개별적인 파라미터 컴포넌트를 가질 수 있다. (하지만 자주 사용되진 않음)

✅ㅤ파라미터

• 일부 스킴에서는 단순한 경로만으로는 충분하지 않다.
• 프로토콜이나 서버 동작에 필요한 추가 정보(파라미터)를 포함한다.
• 보통 각 경로 조각에 ;을 붙여 사용한다. /books;type=ebook;lang=en

하지만 실무에서는 RESTful URL 설계나 라우팅에서 거의 사용되지 않고 과거 프로토콜(FTP 등)에서 더 많이 쓰였다.

✅ㅤ쿼리 스트링

• URL의 ? 다음에 위치하며, 서버에 추가 정보나 옵션을 전달할 때 사용
• 이름=값 쌍의 리스트 형태로, & 로 구분
• 주로 게이트웨이나 웹 애플리케이션 서버에서 정보를 전달받을 떄 사용
  

✅ㅤ프래그먼트

• # 뒤에 위치하며, 리소스 내부의 특정 위치를 가리킨다.
• 서버에는 전달되지 않아서 서버는 항상 전체 리소스를 응답한다.
• 클라이언트가 리소스를 받은 후, 프래그먼트를 기준으로 해당 위치로 스크롤하거나 표시 한다.

• HTTP : HyperText Transfer Protocol - 웹의 요청/응답 통신 규칙
• 리소스 : URI로 식별 가능한 웹 상의 모든 대상 (HTML, 이미지, JSON 등)
• 요청/응답 : HTTP 는 요청-응답 기반의 통신 구조

✨ 포인트

• HTTP 는 비연결성 : 요청 간 상태를 유지하지 않는다.
• 로그인은 토큰, 세션, 쿠키 로 해결
• 프론트 코드에서 API 요청 → HTTP 요청의 시작
• fetch , axios 등은 결국 HTTP 요청을 보내는 도구!

✅ㅤHTTP의 정의

웹에서 HTML 문서를 주고받기 위해 만들어진 애플리케이션 계층의 통신 규약

🔎ㅤHTTP의 구조

• 애플리케이션 계층 : OSI 7계층 중 가장 위에서 동작, TCP/IP 위에서 동작하며 사용자는 직접 전함

🔎ㅤHTTP 메시지 구조

📤 요청 (request)

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Chrome/124.0

• 시작줄 : 메서드 / 경로 / 프로토콜
• 헤더 : 요청에 대한 부가 정보
• 본문 : POST / PUT 등에서 전송할 데이터 포함

📥 응답 (response)

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

• 상태줄 : HTTP 버전 + 상태코드 + 메시지
• 헤더 : 응답 관련 정보
• 본문 : 실제 클라이언트에게 보여줄 내용

✅ㅤHTTP와 TCP/IP

HTTP 는 TCP 위에서 동작하며, 데이터를 안전하게 전송하기 위해 3-way 핸드세이크를 이용

포트 번호

• HTTP → 80번 포트
• HTTPS → 443번 포트

✅ㅤURL과 URI의 차이

✅ㅤHTTP 요청 메서드

✅ㅤHTTP 상태 코드

✅ㅤMIME 타입 (Content-Type)

클라이언트와 서버가 전송하는 데이터의 종류를 명시

✅ㅤ상태 비저장성

• HTTP 는 기본적으로 상태 정보를 유지하지 않는다.
• 요청 간 연결된 상태를 유지하지 않기 때문에, 매 요청마다 모든 정보 포함 필요
• 쿠키, 세션, 토큰 등을 통해 상태 유지를 보완한다.

📍ㅤ제약 및 구현 조건

• 방들이 겹치거나 중간에 빈 공간이 생기지 않아야 한다.
• 규칙성 있게 확장되어야 하며, 나의 방은 항상 중앙에 위치해야 한다.
• 헥사곤 좌표계를 이용하여 배치한다.

🚨 10번째 방부터 중복 배치되는 현상

ㅤ

📍ㅤ문제 정의

헥사곤 그리드를 사용하여 방을 배치하는 과정에서 10번째 방 이후부터 중복 배치되는 현상이 발생했다. 육각형 그리드의 기하학적 특성과 좌표계의 일관성을 보장하지 못한 좌표 배치 로직에서 발생했다.

📎ㅤ헥사곤 그리드의 좌표 시스템

헥사곤 그리드를 코드로 구현하려면, 좌표 시스템이 필요하다. 여러가지 좌표 시스템이 있지만, 큐브 좌표계가 직관적이고 계산이 쉬워서 이를 활용했다.

✅ㅤ큐브 좌표계

• 형식 : [q, r, s]

• 항상 q + r + s = 0 조건을 만족해야 한다.

• 3개의 축(q, r, s)을 사용하며, 각 축은 6방향 중 3개의 방향을 표현

• 장점 : 방향 계산이 직관적이며, 인접 셀 계산이 쉬움.

  중앙: [0, 0, 0] | 왼쪽: [-1, 0, 1] | 오른쪽: [1, 0, -1]

🧐ㅤ문제 분석

• q + r + s = 0 조건을 만족하지 않는 좌표가 생성
• visited Set을 활용했으나, 잘못된 위치에서도 중복 방이 배치

const directions = [
  [1, -1, 0],    // 6. 위 오른쪽 대각선 상단
  [0, -1, 1],   // 5. 위 왼쪽 대각선 상단
  [0, 1, 1],    // 4. 아래 왼쪽 대각선 하단
  [-1, 1, 1],    // 3. 아래 오른쪽 대각선 하단
  [-1, 0, 1],    // 2. 왼쪽
  [1, 0, -1],    // 1. 오른쪽
];

for (let step = 0; step < steps && result.length < roomCount; step++) {
  const posKey = `${cubeX},${cubeY},${cubeZ}`;

  if (!visited.has(posKey)) {  // ✅ 방문 여부만 확인
    visited.add(posKey);
    result.push({ position: [cubeX, cubeY, cubeZ], room: rooms[roomIndex] });
    roomIndex++;
  }

  cubeX += directions[side][0];
  cubeY += directions[side][1];
  cubeZ += directions[side][2];
}

• 일부 dx, dy, dz 값이 q + r + s = 0 조건을 만족하지 않음
• 그로인해 헥사곤 그리드 내에서 유효한 위치로 간주되지 않음ㅤ➡️ㅤ중복 체크가 제대로 되지 않음
• visited.has(posKey) 만으로는 잘못된 위치의 중복 배치를 방지할 수 없음

✅ㅤ해결

• 큐브 좌표계의 조건을 유지하는 방향 벡터로 수정

• 중복 방지를 강화
• 배치 순서를 수정하여 순환 배치를 개선

const directions = [
  [-1, 0, 1],    // 1. 왼쪽
  [1, 0, -1],    // 2. 오른쪽
  [0, -1, 1],   // 3. 위 왼쪽 대각선 상단
  [1, -1, 0],    // 4. 위 오른쪽 대각선 상단
  [-1, 1, 0],    // 5. 아래 왼쪽 대각선 하단
  [0, 1, -1],    // 6. 아래 오른쪽 대각선 하단
];

for (let step = 0; step < (ring - 1) && placedInRing < positionsInRing; step++) {
  const [x, y, z] = currentPos;
  const posKey = `${x},${y},${z}`;

  if (!visited.has(posKey) && (x + y + z) === 0) {
    visited.add(posKey);
    result.push({ position: [x, y, z], room: rooms[roomIndex] });
    roomIndex++;
    placedInRing++;
  }

  currentPos = [x + dx, y + dy, z + dz];
}

🚨 18번째 방부터 아래쪽에서만 배치되는 현상

ㅤ

📍ㅤ문제 정의

헥사곤 그리드를 확장하면서 18번째 방 이후부터 배치 방향이 한쪽으로만 치우치는 현상이 발생했다.

🧐ㅤ문제 분석

• baseIndex 가 단일 위치로 고정되어 있음
• 새로운 위치를 찾을 때, 이전 링의 첫 번째 요소만 기준으로 사용하여 의도대로 안 이루어짐
• 그렇게 일부 방향에서 배치가 누락되면서 아래쪽으로만 방이 추가

const baseIndex = previousRing[directionIndex % previousRing.length];
const basePos = result[baseIndex].position;
const [dx, dy, dz] = dir;
const newPos: Position = [basePos[0] + dx, basePos[1] + dy, basePos[2] + dz];
const posKey = `${newPos[0]},${newPos[1]},${newPos[2]}`;

if (!visited.has(posKey) && newPos[0] + newPos[1] + newPos[2] === 0) {
  visited.add(posKey);
  result.push({ position: newPos, room: rooms[roomIndex] });
  return { roomIndex: roomIndex + 1, placedInRing: placedInRing + 1 };
}

✅ㅤ해결

• baseIndex 를 단일 위치가 아닌, 이전 링의 모든 위치를 순회하며 유효한 새 위치를 찾도록 수정

• (directionIndex + i) % previousRing.length 로 시작점을 조정하여 방형별 배치가 누락되지 않도록 개선

for (let i = 0; i < previousRing.length; i++) {
  const baseIndex = previousRing[(directionIndex + i) % previousRing.length];
  const basePos = result[baseIndex].position;
  const [dx, dy, dz] = dir;
  const newPos: Position = [basePos[0] + dx, basePos[1] + dy, basePos[2] + dz];
  const posKey = `${newPos[0]},${newPos[1]},${newPos[2]}`;

  if (!visited.has(posKey) && newPos[0] + newPos[1] + newPos[2] === 0) {
    visited.add(posKey);
    result.push({ position: newPos, room: rooms[roomIndex] });
    return { roomIndex: roomIndex + 1, placedInRing: placedInRing + 1 };
  }
}
return { roomIndex, placedInRing };

💬ㅤ비하인드

어지러운 x,y,z 좌표계.... 최상의 배치를 맞추기 위한 노력...

Front View	Top View

첫 번째 링을 완성하기 까지의 여정...

문어발 스타일	아래는 왜...

첫 번째 링 이후의 방황하는 방들...

#1	#2

여러가지 확장 방식을 시도해보면서 겪은 다양한 형태

문어발 스타일	아래는 왜...

WebGL 을 기반으로 한 JavaScript 라이브러리로, 웹 브라우저에서 3D 그래픽을 쉽게 렌더링할 수 있도록 도와준다. 기본적인 원리로는 WebGL을 직접 다루는 복잡한 과정을 추상화하여 사용자가 간단한 코드로도 강력한 3D 환경을 구현할 수 있게 해준다.

📎 Three.js의 핵심 개념

• Scene : 모든 3D 객체가 배치되는 공간
• Camera : 장면을 어떤 위치와 구조로 담아낼지 결정
• Renderer : 3D 장면을 캔버스에 그리는 역할
• Light : 3D 객체에 빛을 추가
• Mesh : 3D 모델을 구성하는 기본 단위로, Geometry와 Material로 구성
• Controls : 사용자 입력으로 카메라를 조작

📌 프로젝트에서 Three.js 활용

01. 3D 모델 불러오기

@react-three.drei 의 useGLTF 훅을 활용했다.

📎ㅤ@react-three/drei 란?

Three.js를 React에서 더 쉽게 사용할 수 있도록 도와주는 유틸리티 라이브러리이다. useGLTF 뿐만 아니라 카메라 컨트롤, 환경 설정 등을 손쉽게 구현할 수 있다.

const { scene } = useGLTF(modelPath) as GLTFResult;
<primitive object={scene} scale={0.68} rotation={[0, -Math.PI / 4, 0]} />

• modelPath 경로의 GLTF 모델을 로드하여 scene 으로 저장한다.
• primitive 를 사용하여 GLTF 모델을 Three.js 의 object 형태로 변환 후 렌더링

📎ㅤGLTF 란?

: 3D 모델을 압축하여 웹에서 빠르게 로드할 수 있도록 도와주는 포맷이다.

02. 위치 및 그림자 설정

useEffect(() => {
  if (scene) {
    scene.position.set(0, 0, 0);
    scene.traverse((object) => {
      if (object.isMesh) {
        object.castShadow = true;
        object.receiveShadow = true;
      }
    });
  }
}, [scene]);

• 모델의 위치를 설정, scene.traverse 를 이용하여 모델 내의 모든 Mesh 요소에 그림자 설정을 적용

📎ㅤtraverse 란?

: scene 내부의 모든 객체를 순회하면서 특정 동작을 수행하도록 해준다.

📎ㅤcastShadow와 receiveShadow 란?

• castShadow : 해당 객체가 빛을 받아 그림자를 만들도록 설정
• receiveShadow : 해당 객체가 다른 객체의 그림자를 받을 수 있도록 설정
• 이 두 속성을 모두 활성화해야 현실적인 그림자 표현이 가능하다

03. 모델 렌더링

<Canvas shadows camera={CAMERA_CONFIG}>
  <RoomLighting />
  <Suspense fallback={null}>
    <Center>
      <primitive object={scene} scale={0.68} rotation={[0, -Math.PI / 4, 0]} />
    </Center>
  </Suspense>
  <OrbitControls enableRotate={false} enablePan={false} minDistance={5} maxDistance={12} />
</Canvas>

• Canvas 컴포넌트를 사용하여 렌더링
• primitive 를 통해 Three.js의 scene 객체를 직접 렌더링
• OrbitControls 를 추가하여 카메라 이동 범위를 제한

📎ㅤOrbitControls 란?

: Three.js 에서 제공하는 컨트롤러로, 사용자가 마우스로 카메라를 회전, 이동, 줌할 수 있도록 도와주며 다양한 속성들로 설정하거나 막을 수 있다.

• enableRotate={false} : 회전 기능 비활성화
• enablePan={false} : 카메라 이동 비활성화
• minDistance 및 maxDistance : 줌 범위 조절

04. 조명 및 카메라 설정

재사용성과 관리의 용이성을 고려해서 별도의 constants 파일로 분리해서 사용하였다.

카메라 설정

export const CAMERA_CONFIG = {
  position: new Vector3(0, 4, 10),
  fov: 30,
};

📎ㅤFov 란?

: Field of View로 즉, 카메라가 한 번에 볼 수 있는 시야각을 의미한다. 값이 클수록 넓게 보이고, 작을수록 좁게 보인다. 이를 통해 원근감을 조절할 수 있다.

조명 설정

렌더링에서 가장 중요한 건 조명이다. 왜냐하면 조명의 유/무의 차이로 퀄리티가 달라보이기 때문에, 조명 설정이 가장 중요했다.

export function RoomLighting() {
  const { mainLight, ambient, fill } = LIGHT_CONFIG;

  return (
    <>
      <ambientLight intensity={ambient.intensity} color={ambient.color} />
      <directionalLight
        position={[mainLight.position[0], mainLight.position[1], mainLight.position[2]]}
        intensity={mainLight.intensity}
        color={mainLight.color}
        castShadow
        shadow-mapSize-width={mainLight.shadowConfig.mapSize[0]}
        shadow-mapSize-height={mainLight.shadowConfig.mapSize[1]}
        shadow-camera-near={mainLight.shadowConfig.camera.near}
        shadow-camera-far={mainLight.shadowConfig.camera.far}
        shadow-bias={mainLight.shadowConfig.bias}
      />
      <pointLight
        position={[fill.position[0], fill.position[1], fill.position[2]]} 
        intensity={fill.intensity}
        color={fill.color}
      />
    </>
  );
}

📎ㅤLight 종류

• ambientLight : 전체적인 기본 조명으로, 모든 방향에서 부드럽게 빛을 퍼뜨린다.
• directionalLighy : 태양빛과 유사한 조명으로, 특정 방향에서 평행하게 빛을 비춘다.
• pointLight : 특정 지점에서 모든 방향으로 빛을 방출하는 조명

05. 가구 모델링 분리 및 관리

방 내부에 배치되는 가구(책장, CD플레이어, 저금통, 방명록)은 useRoomItems 훅으로 따로 만들어 관리하고 있다.

🛋️ㅤ가구의 종류

• 저금통, 방명록 : 사용자가 편집할 수 없는 가구 ❌
• CD 플레이어, 책장 : 사용자가 편집할 수 있는 가구 ⭕️

➡️ㅤ사용자는 가구 토글 기능을 이용해 CD 플레이어, 책장를 배치하거나 삭제할 수 있다.

const { items } = useRoomItems({ roomId, furnitures });

• 방마다 배치된 가구의 종류가 다를 수 있기 때문에 roomId 에 따라 동적으로 구성

{items.map((item) => (
  <Suspense key={item.id}>
    <Furnitures item={item} onInteract={handleInteraction} onHover={handleHover} />
  </Suspense>
))}

• items 배열을 순회하여 Furnitures 컴포넌트를 렌더링
• onInteract 와 onHover 이벤트 핸들러를 통해 가구와의 상호작용을 구현

사용자가 원하는 테마로 변경 가능하다

06. 상호작용 구현 ( 가구 클릭 및 호버 이벤트 )

방명록	책장(도서)

CD플레이어(음악)	저금통(포인트)

const handlePointerOver = (e: MouseEvent) => {
  e.stopPropagation();
  scene.traverse((object) => {
    if (object.isMesh) {
      object.material.emissive = object.material.color;
      object.material.emissiveIntensity = 0.5;
    }
  });
};

const handlePointerOut = (e: MouseEvent) => {
  e.stopPropagation();
  scene.traverse((object) => {
    if (object.isMesh) {
      object.material.emissiveIntensity = 0;
    }
  });
};

• 호버하면(onPointerOver), emissive 값을 변경하여 하이라이트 효과 적용
• 호버 해제 시(onPointerOut), emissiveIntensity를 0으로 설정하여 원래 상태로 복구

📎ㅤEmissive 란?

• 모델이 자체적으로 빛을 내는 효과를 줄 수 있도록 하는 속성
• 호버 시, emissiveIntensity 값을 높여 하이라이트 효과를 부여

💬ㅤ비하인드

처음 사이트에 모델링을 렌더링 했을 때는 보이지도 않아서 뭐가 잘못되었는지... 카메라 세팅 끝에 방을 정중앙에 불러올 수 있었다.

이제 가구들은 먼지처럼 그저 흩어져 있었다. 사실 이 부분은 노가다로 위치를 찾고 회전을 시키는 것 밖에는 없는 것 같아서 일일히 맞추었다.

메인 페이지의 핵심 기능인 방 프리뷰는 사용자의 방을 중심으로 하우스메이트(팔로잉)의 방을 시각적으로 보여주는 기능이다. 3D 모델링된 방을 벌집 구조로 배치하여 한눈에 확인할 수 있도록 구현해야 한다.

📌ㅤ제약 및 구현 조건

• 방들이 겹치거나 중간에 빈 공간이 생기지 않아야 한다.
• 규칙성 있게 확장되어야 하며, 나의 방은 항상 중앙에 위치해야 한다.
• 헥사곤 좌표계를 이용하여 배치한다.

🛠️ 구현 로직 흐름

(1)ㅤ방 정보 조회

• 팔로잉한 유저 목록 가져오기ㅤ➡️ㅤgetFollowing() 호출
• 각 유저의 방 정보 가져오기ㅤ➡️ㅤgetRoomById(user.id) 호출
• 가져온 방 정보를 rooms 상태로 저장

useEffect(() => {
  const fetchData = async () => {
    try {
      const followingUsers = await getFollowing();
      const roomData = await Promise.all(
        followingUsers.map((user) => getRoomById(user.id))
      );
      setRooms(roomData);
    } catch (error) {
      console.error('방 정보 로딩 실패', error);
    }
  };
  fetchData();
}, []);

(2) 헥사곤 배치 규칙

• 중심(0,0,0) 좌표에 나의 방 배치
• 6가지 방향으로 첫 번째 링을 배치
• 이후 기존 배치를 기준으로 왼쪽, 오른쪽 방향으로 확장
• 중복 좌표 체크하여 중복 배치 방지
• 헥사곤 좌표계를 사용하여 (q,r,s) 좌표를 2D (x,y,z) 좌표로 변환

const getHexPosition = (index: number) => {
  const row = Math.floor(index / 3);
  const col = index % 3;
  const x = col * 1.5; // 간격 조정
  const z = row * 1.3;
  return [x, 0, z];
};

(3) 방 배치

• getHexPosition(index) 함수를 활용해 위치 계산
• Room 컴포넌트를 활용해 방을 배치

  <Canvas>
  {rooms.map((room, index) => (
    <Room
      key={room.id}
      modelPath={room.modelPath}
      userId={room.userId}
      position={getHexPosition(index)}
      scale={0.5} // 메인에서는 작게
      onClick={() => navigate(`/room/${room.userId}`)}
    />
  ))}
  </Canvas>

📁 로직 분리 및 구현

1. useRooms - 방 데이터 불러오기

📍 역할

• 현재 로그인한 사용자의 방 정보와 팔로잉한 사용자의 방 정보를 불러와 rooms 상태에 저장
• 방 테마 정보를 매핑하여 modelPath 추가

export default function useRooms(limit = 30, myUserId: number) {
  const [rooms, setRooms] = useState<Room[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const houseMateUsers = await housemateAPI.getFollowing(0, limit);
        const roomData = await Promise.all(
          houseMateUsers?.housemates?.map((mate: Housemate) =>
            roomAPI.getRoomById(mate.userId)
          )
        );

        const modelRooms = roomData.map((room) => {
          const themeKey = mapThemeKeyToFullThemeKey(room.theme);
          return { ...room, modelPath: FullThemeData[themeKey].modelPath };
        });

        setRooms(modelRooms);
      } catch (error) {
       ...에러처리 코드
    };
    fetchData();
  }, [limit, myUserId]);

  return { rooms, loading, error };
}

✅ㅤ로직의 흐름

(1) 로그인한 사용자의 방 정보 가져오기

• roomAPI.getRoomById(myUserId) 호출
• mapThemeKeyToFullThemeKey 를 이용해 테마 키를 변환 후, modelPath 추가

(2) 팔로잉한 유저들의 방 정보 가져오기

• housemateAPI.getFollowing(0, limit) 호출
• 각 유저의 방 정보를 비동기적으로 가져옴

(3) 데이터 저장

• 나의 방 정보와 팔로잉한 유저들의 방을 하나의 배열로 합쳐 rooms 상태로 업데이트

2. useHexagonGrid - 방을 헥사곤 그리드 형태로 배치

📍 역할

• rooms 배열을 헥사곤 구조로 배치
• 중앙을 기준으로 점진적으로 확장하며 배치

⚙️ㅤ이동 방향 벡터 (좌표 시스템)

const directions: Position[] = [
  [-1, 0, 1], [1, 0, -1], [0, -1, 1],
  [1, -1, 0], [-1, 1, 0], [0, 1, -1],
];

⚙️ㅤ링 확장 규칙을 정의한 배열

const expansions: Expansion[] = [
  { directionIndex: 2, dir: [-1, 0, 1], side: 'left' },
  { directionIndex: 0, dir: [-1, 0, 1], side: 'left' },
  { directionIndex: 4, dir: [-1, 0, 1], side: 'left' },
  { directionIndex: 3, dir: [1, 0, -1], side: 'right' },
  { directionIndex: 1, dir: [1, 0, -1], side: 'right' },
  { directionIndex: 5, dir: [1, 0, -1], side: 'right' },
];

⚙️ㅤexpandRing 함수

헥사곤 그리드의 새로운 링을 확장할 때 사용하며, 기존 링을 기준으로 새로운 헥사곤 방을 배치하는 역할을 한다. 원래는 useHexagonGrid 에서 코드 분리가 안되어 있었지만, 로직이 복잡해지는 관계로 따로 분리하여 사용하고 있다.

function expandRing(
  expansion: Expansion, // 확장 규칙
  previousRing: number[], // 이전 링에 속한 방의 인덱스 배열
  result: RoomPosition[], // 전체 배치된 방들의 목록
  visited: Set<string>, // 방문한 방 좌표를 기록한 Set
  rooms: Room[], // 배치할 전체 방 목록
  roomIndex: number, // 현재 배치 중인 방의 인덱스
  placedInRing: number, // 현재 링에 배치된 방 개수
  positionsInRing: number // 현재 링에 배치할 수 있는 최대 방 개수
)

// 헥사곤 그리드 확장 함수
function expandRing(...): { roomIndex: number; placedInRing: number } {
  const { directionIndex, dir } = expansion;
  if (placedInRing >= positionsInRing || roomIndex >= rooms.length)
    return { roomIndex, placedInRing };

  for (let i = 0; i < previousRing.length; i++) {
    const baseIndex = previousRing[(directionIndex + i) % previousRing.length];
    const basePos = result[baseIndex].position;
    const [dx, dy, dz] = dir;
    const newPos: Position = [basePos[0] + dx, basePos[1] + dy, basePos[2] + dz];
    const posKey = `${newPos[0]},${newPos[1]},${newPos[2]}`;

    if (!visited.has(posKey) && newPos[0] + newPos[1] + newPos[2] === 0) {
      visited.add(posKey);
      result.push({ position: newPos, room: rooms[roomIndex] });
      return { roomIndex: roomIndex + 1, placedInRing: placedInRing + 1 };
    }
  }
  return { roomIndex, placedInRing };
}

✅ㅤ로직의 흐름

(1) 배치 종료 조건 체크

• 현재 링에 배치된 방이 최대 배치 가능 개수를 초과하면 종료
• 남은 방이 없으면 종료

(2) 이전 링을 기준으로 새로운 방 배치

(3) 새로운 위치 계산

• 이전 링의 특정 위치를 기준으로 새 방의 좌표를 계산ㅤ➡️ㅤnewPos
• 새로운 위치를 posKey 문자열로 변환해 중복 체크에 사용

(4) 중복 체크 및 방 배치

• 이미 배치된 방이면 스킵
• 헥사곤 좌표계의 특성인 x + y + z = 0 을 만족하는 경우만 추가
• 방을 추가한 후 roomIndex 와 placedInRing 값을 증가

📌ㅤ주요 로직 : 헥사곤 그리드 배치

const result: RoomPosition[] = [];
const visited = new Set<string>();
const ringRooms: number[][] = [[]];

• result : 배치된 방들의 목록
• visited : 방문한 좌표를 저장하여 중복 방지
• ringRooms : 링별로 방 인덱스를 저장하는 배열

✅ㅤ로직의 흐름

// 중앙에 첫 번째 방 배치
result.push({ position: [0, 0, 0], room: rooms[0] });
visited.add('0,0,0');
ringRooms[0] = [0];
let roomIndex = 1;

// 첫 번째 링 배치 (최대 6개)
if (roomIndex < rooms.length) {
  const firstRingIndices: number[] = [];
  for (let dir = 0; dir < 6 && roomIndex < rooms.length; dir++) {
    const [dx, dy, dz] = directions[dir];
    const posKey = `${dx},${dy},${dz}`;

    if (!visited.has(posKey)) {
      visited.add(posKey);
      result.push({ position: [dx, dy, dz], room: rooms[roomIndex] });
      firstRingIndices.push(roomIndex);
      roomIndex++;
    }
  }
  ringRooms.push(firstRingIndices);
}

(1) 초기 방 배치

• 첫 번째 방(나의 방)을 (0,0,0) 에 배치
• 이후 6가지 방향을 돌며 첫 번째 링 완성

// 이후 링 확장
let ring = 1;
while (roomIndex < rooms.length) {
  const positionsInRing = Math.min(rooms.length - roomIndex, 6);
  let placedInRing = 0;
  const previousRing = ringRooms[ring];

  if (!previousRing) break;

  for (const expansion of expansions) {
    const updated = expandRing(
      ...매개변수
    );
    roomIndex = updated.roomIndex;
    placedInRing = updated.placedInRing;
  }

  if (placedInRing > 0) {
    ringRooms.push(result.slice(roomIndex - placedInRing, roomIndex).map((_, i) => roomIndex - placedInRing + i));
    ring++;
  } 
  ...

(2) 추가 방 배치

• 방이 많아지면 링을 확장하여 배치
• expandRing() 을 사용하여 각 방향에 배치 가능 여부 확인 후 추가
• 새 링 추가 시, ringRooms 에 추가

// 2D 좌표 변환 (q, r -> x, y 변환)
return result.map(({ position: [q, r], room }) => {
  const x = centerX + width * (q + r / 2);
  const y = centerY - height * (2.98 / 4.2) * r;
  return { room, position: [x, y, r * 0.7] };
});
}, [rooms, centerX, centerY]);

(3) 위치 변환

• q, r, s 좌표계를 화면 x, y 좌표로 변환ㅤ➡️ㅤ헥사곤 좌표계를 2D 좌표로 변환

3. HiveRooms - 방을 3D 씬에 렌더링

📍 역할

• useRooms 에서 가져온 방 데이터를 useHexagonGrid 로 배치 후, Three.js로 렌더링
• Canvas 를 활용하여 방 모델을 배치하고 마우스 이벤트를 처리

export default function HiveRooms({ myUserId }) {
  const { rooms } = useRooms(30, myUserId);
  const positionedRooms = useHexagonGrid(rooms, 0, 0);
  const [hoveredRoom, setHoveredRoom] = useState<number | null>(null);

  return (
    <div className='w-full h-screen relative'>
      <Canvas camera={{ position: [0, 4, 10], fov: 25 }} shadows>
        <RoomLighting />
        {positionedRooms.map(({ room, position }, index) => (
          <group
            key={index}
            position={position}
            onPointerOver={() => setHoveredRoom(index)}
            onPointerOut={() => setHoveredRoom(null)}>
            <HiveRoomModel room={room} />
          </group>
        ))}
      </Canvas>
      {hoveredRoom !== null && (
        <div className='absolute bottom-22 left-1/2 transform -translate-x-1/2'>
          ✊🏻 똑똑! {rooms[hoveredRoom]?.nickname}의 방에 들어가실래요?
        </div>
      )}
    </div>
  );
}

✅ㅤ로직의 흐름

(1) 방 데이터 가져오기

(2) 헥사곤 그리드 위치 계산

(3) Three.js로 방 모델 렌더링

• Canvas 내부에서 HiveRoomModel 을 반복 렌더링
• onPointerOver, onPointerOut을 통해 호버 효과 추가

(4) 마우스 이벤트 처리

• mousedown, mousemove, mouseup 이벤트를 활용해 드래그/클릭 감지
• 클릭한 방으로 이동하도록 구현

✨ 사용자 경험 개선

👉 UX 개선 포인트 ✅ㅤ프리뷰 기능의 직관적인 사용을 돕기 위해 가이드 애니메이션 추가

• 마우스 왼쪽 클릭으로 드래그 가능
• 휠 스크롤을 사용해 줌 인/아웃 조작 가능

이번에 처음으로 복잡한 css 처리를 포함한 Dock-Menu를 만들어 보았다. 이 메뉴는 [테마 설정], [취향 설정]을 위한 도구들이 모여 있으며,디자인에서는 자연스러운 애니메이션을 통해 선택된 아이콘이 바뀌고, 선택된 상태가 유지되도록 설계 했다.

• 기본적으로 메뉴가 호버되면 툴팁이 나타나고 선택된 메뉴는 아이콘이 변경되며, 나머지 메뉴들은 #ffffff 으로 바뀐다. 메뉴가 선택되면 메뉴는 자동으로 닫히고 관련된 컴포넌트가 렌더링된다.
• 이번에 가장 신경 쓴 부분은 UX와 부드러운 전환이다.

🔎ㅤ새로 알 게 된 것

• button : 기본적으로 키보드 접근성이 제공돼서 Tab 키로 이동 가능하다.
• span : 텍스트나 이미지를 감싸기 위해 사용하며, 스타일링을 위해 주로 쓰이는 인라인 요소로 적합하다.
• aria-label : 웹 접근성을 위한 속성으로, 스크린 리더 같은 보조 기술이 요소를 읽을 때 제공할 텍스트 설명을 설정하는 역할을 한다.

01. 배치 및 스타일링

구상

• 기본 상태 : 기본 도구 메뉴 아이콘만 보인다.
• 호버 : 높이가 커지고, 2개의 추가 아이콘(취향 설정, 테마 설정)이 위로 슬라이드 되어 나타난다.

메뉴의 초기 사이즈는 76px 였으나, 실제 화면에서 테스트해본 결과 크기가 너무 커 보였다. 그래서 일반적인 Dock-Menu는 어떤 사이즈일까 찾아보았다.

• 모바일 : 48~64px

• 태블릿/PC : 56~72px

• macOs Dock : 48~64px

• 결론적으로는 64px 로 변경하였다.

🧐ㅤ고정시킬 때 보통 어떤 걸 사용할까? Sticky VS Fixed

fixed

• 화면을 스크롤해도 항상 같은 위치에 고정된다.
• 하단에 고정된 Dock-Menu/floating Btn을 만들 때 사용된다.

sticky

• 부모 요소의 스크롤에 따라 위치가 변동된다.
• 예를 들어, 특정 섹션을 스크롤할 때 해당 섹션 안에서만 고정되는 요소를 만들 때 사용된다.

➡️ Dock-Menu 는 화면 하단에 고정되므로 fixed 사용

📍 Dock-Menu 구조

export default function DockMenu({ activeSettings, onSettingsChange }) {
  const [isOpen, setIsOpen] = useState(false);
  const menuRef = useRef(null);

  const getMainButtonBackground = () => {
    if (!hasSelectedSetting) {
      return 'bg-white';
    }
    if (!isOpen && activeSettings) {
      return 'bg-white';
    }
    return 'bg-transparent hover:bg-white/50';
  };

  return (
    <div
      ref={menuRef}
      className={`bottom-menu ... ${isOpen ? 'h-[202px]' : 'h-16'}`}
    >
      <div className="...">
        <button
          className={`bottom-menu-icon group absolute ${getMainButtonBackground()}`}
          onClick={() => setIsOpen(!isOpen)}
          aria-label="도구 메뉴 열기"
        >
          <img src={isOpen ? dockMenuNoselectIcon : dockMenuIcon} />
        </button>
        <div className={`bottom-menu-content transition-all duration-100 ${isOpen ? 'opacity-100' : 'opacity-0 pointer-events-none'}`}>
          {['preference', 'theme'].map((setting, index) => (
            <button
              key={setting}
              onClick={() => onSettingsChange(setting)}
              className={`bottom-menu-icon group absolute bottom-[${68 + index * 70}px] ${activeSettings === setting ? 'bg-white' : 'bg-transparent hover:bg-white/50'}`}
            >
              <img src={activeSettings === setting ? selectedIcons[setting] : unselectedIcons[setting]} />
              <span className="... opacity-0 group-hover:opacity-100 transition-opacity">
                {setting === 'preference' ? '취향 설정하기' : '테마 설정하기'}
              </span>
            ...
}

(1)ㅤ메뉴의 동작 및 상태에 따른 스타일링

• 메뉴가 열리면 bottom-menu 의 높이가 확장되며, 닫히면 기본 상태로 돌아간다.
• Dock-Menu 버튼 클릭시 setIsOpen(true) 로 메뉴를 열고 다시 클릭 시 setIsOpen(false) 로 닫는다.
• pointer-events-none : 메뉴가 닫혀있을 때 사용자가 메뉴 항목을 클릭할 수 없도록 설정
• getMainButtonBackground : 사용자가 특정 메뉴를 활성화하면 그 메뉴의 배경이 bg-white 로 변경되고 다른 메뉴는 bg-transparent 로 설정하여 어떤 메뉴가 활성화되어있는지 쉽게 알 수 있게 했다.

(2)ㅤ하위 메뉴 아이템

• 각 설정 버튼 preference 와 theme 는 absolute 로 위치가 고정되어 있고 메뉴가 열리면 버튼들이 각 위로 배치헸다.
• transition-opacity 와 group-hover:opacity-100 을 사용하여 hover 시 이미지의 투명도가 변경되도록 했다. 이로 인해 호버 시 좀 더 직관적인 구분이 가능하도록 했다.
• hover 하면 해당 메뉴의 툴팁이 나타나도록 group-hover:opacity-100 transition-opacity 효과를 추가

02. 상태 관리 및 로직 구현

Dock-Menu의 열림 상태 및 선택된 설정을 관리하기 위해 zustand 활용

const [isOpen, setIsOpen] = useState<boolean>(false);
const [hasSelectedSetting, setHasSelectedSetting] = useState<boolean>(false);

const handleSettingClick = (setting: string) => {
  if (setting === activeSettings) {
    setIsOpen(false);
    setHasSelectedSetting(false);
    onSettingsChange(null);
  } else {
    setIsOpen(false);
    setHasSelectedSetting(true);
    onSettingsChange(setting);
  }
};

const handleMainButtonClick = () => {
  if (isOpen) {
    setIsOpen(false);
    onSettingsChange(null);
    setHasSelectedSetting(false);
  } else {
    setIsOpen(true);
  }
};

• isOpen : Dock-Menu의 열림/닫힘 상태를 관리
• activeSettings : 부모 컴포넌트에서 관리하는 상태로, preference 또는 theme 설정이 선택됨을 관리
• hasSelectedSetting : 선택 여부 관리
• handleSettingClick : 이미 선택된 설정을 다시 클릭하면 해당 설정을 비활성화, 다른 설정을 클릭하면 새로운 설정을 활성화
• handleMainButtonClick : Dock-Menu가 열려있을 때, 클릭하면 닫고 설정을 초기화하고 닫혀있을 때 클릭하면 열리게 설정

03. 사용자 경험 개선

(1)ㅤ자동 닫힘 및 아이콘 변경

👉 UX 개선 포인트 ✅ㅤ불필요한 클릭 최소화 → 선택 후 자동 닫힘으로 사용자 조작 간소화 ✅ㅤ시각적 피드백 제공 → 아이콘 변경을 통해 현재 설정 상태를 명확하게 표현

const handleSettingClick = (setting: string) => {
  //...
  setIsOpen(false);
};

const getCurrentIcon = () => {
  if (!hasSelectedSetting) return dockMenuIcon;
  if (isOpen) return dockMenuNoselectIcon;
  if (activeSettings === 'preference' && !isOpen) return preferenceIcon;
  if (activeSettings === 'theme' && !isOpen) return themeIcon;
  return dockMenuIcon;
};

• 사용자가 preference 또는 theme 을 선택하면 Dock-Menu가 닫히도록 구현
• handleSettingClick 함수에서 setIsOpen(false) 호출하여 선택후 자동으로 닫히도록 처리
• 닫힌 후 기본 도구 메뉴 아이콘에서 getCurrentIcon 함수로 선택한 설정 메뉴 아이콘으로 변경되도록 설정

(2)ㅤDock-Menu 바깥 클릭 시 메뉴 닫기

👉 UX 개선 포인트 ✅ㅤ사용자 편의성 향상 → 사용자가 직접 메뉴를 닫을 필요 없이 자연스럽게 닫힘 ✅ㅤ자연스러운 인터랙션 → 바깥 클릭 시 닫히는 동작은 일반적인 UI 패턴과 일치하여 직관적인 경험 제공

const menuRef = useRef<HTMLDivElement>(null);

useEffect(() => {
  const handleClickOutside = (event: MouseEvent) => {
    if (menuRef.current && !menuRef.current.contains(event.target as Node)) {
      setIsOpen(false);
    }
  };
  document.addEventListener("mousedown", handleClickOutside);
  return () => document.removeEventListener("mousedown", handleClickOutside);
}, []);

• useRef 를 활용해 Dock-Menu 컨테이너를 참조
• mousedown 이벤트 리스너를 추가하여 바깥을 클릭하면 자동으로 닫히도록 구현
• menuRef.current.contains(event.target as Node) 를 검사하여 바깥 클릭 감지 후 setIsOpen(false) 수행

💬ㅤRoomE 의 탄생 배경

처음엔 멋진 프로젝트를 만들고 싶다는 마음에 신박한 아이디어를 찾으려 했다. 하지만 그런 아이디어일수록 이미 존재하는 서비스가 많았고 고민할수록 점점 무겁고 어려운 주제만 남아 막막해졌다. 그런 주제들은 구현 과정에서 부딪힐 문제들도 많아 보였고 아이디어 자체에만 집착하다 보니 결국 제자리걸음을 하고 있었다.

그래서 방향을 바꾸기로 했다. 우리 모두가 공감할 수 있고 개발하는 동안 진짜 재미있고 몰입할 수 있는 주제는 무엇일까? 이 질문을 시작으로, 자연스럽게 우리가 가진 고민들을 나누게 되었다. 우리는 모두 취업을 준비하고 있었고 저마다의 걱정이 있었지만, 본질적인 고민은 같았다. "나 자신을 제대로 알지 못하는데, 어떻게 날 잘 표현할 수 있을까?" 이 고민을 해결하려면, 먼저 나를 깊이 이해하는 과정이 필요하다는 걸 깨달았다. 하지만 바쁜 일상 속에서 우리는 점점 자신을 돌아볼 기회를 잃어가고 있었다. 그래서 우리는 자아 탐색과 심리적 안정을 위한 공간을 만들기로 했다.

그렇게 탄생한 RoomE는 사용자가 스스로를 더 잘 이해하고, 자신의 생각과 감정을 정리하며 성장할 수 있는 경험을 제공하는 프로젝트다. 우리는 이를 통해 각자가 자연스럽게 자신을 돌아보고 스스로의 방식으로 고민을 정리하며 앞으로 나아갈 수 있도록 돕고 싶었다.

💬ㅤ구현 가능성

우리의 기획은 기대되었지만, 현실적인 고민도 컸다. 처음 구상한 콘셉트는 싸이월드와 본디에서 영감을 받아, 사용자가 개성 있는 가상의 방을 만들고, 이웃과 연결되며 상호작용하는 시스템이었다. 방들이 연결되면서 하나의 네트워크를 이루는 구조를 생각했으며, 이는 시각적으로 더 매력적이고 인터랙션한 요소가 많았기에 다른 프로젝트들과 차별화 될 수 있는 강점이 많았다.

하지만 이를 구현하려면 3D 환경을 조성하고 방들이 어떻게 연결될지를 계산하는 복잡한 알고리즘이 필요했다. three.js를 사용하면 가능하겠지만, 팀원 중 누구도 3D 개발 경험이 없었고 주어진 개발 기간은 단 2~3주밖에 되지 않았다. 그렇기에 "이걸 현실적으로 해낼 수 있을까? 라는 고민이 깊어졌다.

그럼에도 불구하고, 이 프로젝트에서 3D는 핵심 요소였다. 기획과 디자인, 서비스의 퀄리티를 살리기 위해서는 3D 구현을 포기할 수 없다고 판단했다. 결국, 팀원 중 3D를 조금이라도 접해본 내가 직접 배워가며 구현해보기로 결심했다. 실패할 가능성도 고려해, 백업 플랜을 준비하고 팀원들과 함께 방향을 조율했다.

기획 단계에서 three.js 의 기본 개념과 사용법을 익히기 위해 강의를 듣기 시작했다.그러나 가장 큰 문제는 3D 모델링이었다. AI 툴을 사용해보기도 했지만, 그 결과물이 서비스의 스타일과 맞지 않았고 원하는 퀄리티를 얻기에는 한계가 있었다. 그래서 유튜브 강의로 블렌더를 배워 직접 모델링 작업에 도전하기로 했다.

처음 해보는 작업이라 막막하고 완성할 수 있을지 확신할 수 없었지만, 지레 겁먹고 주저하기보다 도전해보는 것이 더 많은 것을 배울 수 있는 기회라 생각했다.

💬ㅤ최종적인 회고

이번 프로젝트는 가장 힘들었지만, 가장 애정이 가는 프로젝트였다. 무엇보다도 끊임없는 도전과 팀워크의 진정한 가치를 몸소 체험할 수 있었기 때문이다.

가장 큰 난관은 타이트한 일정이었다. 디자인부터 3D 구현까지 혼자 맡다 보니 시간을 최대한 효율적으로 활용해야 했다. 하지만 다행히도 팀원들이 각자 잘할 수 있는 분야에서 적극적으로 도와주었고 내가 그 부분에 온전히 집중할 수 있도록 도와주었다. 이런 어려운 순간마다 서로 역할을 나누고 그 역할을 완수하기 위해 협력하는 과정은 정말 값진 경험이었다.

모든 팀원이 각자의 자리에서 최선을 다했기에, 제한된 시간 속에서도 우리가 낼 수 있는 최고의 퀄리티를 만들어낼 수 있었다고 생각한다. 개발을 시작한 이후 처음으로 '이게 진짜 팀워크구나' 하고 실감할 수 있었다. 이 과정은 정말 힘들었지만, 동시에 즐거웠다. 각자가 맡은 일에 완전히 몰입하며, 하나의 목표를 향해 나아가는 경험이 너무 좋았고, 이런 협업을 다시 한 번 경험하고 싶다는 생각이 들었다.

이 프로젝트를 무사히 끝마친 내 자신이 자랑스럽다. 중간에 어려운 순간들이 많았지만, 타협하지 않고 끝까지 도전한 경험이 가장 값진 결과라고 생각한다. 이 경험을 통해 배운 것들은 단순한 기술을 넘어, 앞으로 나아가는데 큰 자산이 될 거라고 생각한다.

🏆ㅤ결과

🎖️우수	🎖️인기

이 프로젝트의 끝이 눈에 보이는 성과로 이어져서 너무 기쁘다. 특히, 우수상은 프로젝트의 완성도와 기술적인 평가를 바탕으로 주어진 상이라 의미가 깊고, 인기상은 수료생들이 가장 마음에 들었던 프로젝트를 뽑는 상이라 더 특별한 의미가 있다.

완성도를 인정받은 것도 중요하지만, 사람들의 마음에 와닿았다는 점이 더 큰 기쁨이었다. 우리가 열심히 고민하고 노력한 결과가 진정성 있게 전달되어, 사람들이 그 매력을 느꼈다는 사실이 정말 뿌듯하다. 앞으로도 더 매력적이고 많은 사람들의 마음을 사로잡을 수 있는 프로젝트를 만들어 나가고 싶다.

💬ㅤ그 이후..

지금은 디벨롭하여 실제로 서비스를 운영해보고자 기획하고 있다. 시간이 부족하여 신경쓰지 못했던 부분들과 더 추가하고 싶었던 기능들을 보완하여 출시해볼 생각이다.

💬ㅤ비하인드

📍 팀 결성

이번 프로젝트는 FE 팀을 구성하고 주제 및 기획을 잡고 BE 팀을 구인하여 프로젝트를 진행해나가는 방식이었다. 그래서 부랴부랴 PR_PPT 디자인 작업도 했다. 생각보다 잘 나와서 여기에도 올려본다.

📍 3D 모델링의 역경

다행히 유튜브 강의가 잘 되어 있어서, 여러 가지 강의들을 보면서 하나씩 채워갔다.

특히 테마별로 방을 만드는 작업은 생각보다 재밌었다. 블렌더 툴에 점점 익숙해져서 시간도 절약할 수 있었다. 이런 프로그램들을 다룰 때마다 느끼는 점은, 어도비 툴이나 피그마처럼 한 가지 프로그램을 익혀놓으면 비슷한 유형의 프로그램을 처음 접하더라도 훨씬 수월하게 다룰 수 있다는 것이다. 나 역시 이번 경험에서 큰 도움이 되었다.

📍 조각 디자인 모음

RoomE 로고 디자인

• 귀엽고 포근한 느낌으로 작업했다.
• 사이트에 실제로 올려보니 컬러가 있는게 오히려 마이너스 인 것 같아 심플한 버전으로 채택

ㅤ

RoomE 메달 디자인

• 랭킹에 사용할 메달 디자인으로 로고의 캐릭터를 활용해서 작업했다.

RoomE CD 플레이어 디자인

• 음악이 재생될 때, CD 플레이어의 CD가 돌아가는 애니메이션을 주기 위해 따로 제작하였다.

RoomE 버튼 디자인

• 클릭할 때, 좀 더 역동감을 주고자 오락실 버튼에서 착안하여 제작하였다.

RoomE 커스텀 디자인

• 서비스와 어울리는 토스트/모달창을 디자인에 맞춰 제작하였다.

🚨 문제점

최종 QA를 진행 중, 팀원들 간 게임 속도가 상이하다는 것을 발견하였다. 해당 문제에 대해서 알아본 결과, 모니터 주사율(Hz)에 따라 게임 속도가 다르다는 것을 알게되었다. 기존에 구현했던 게임들은 프레임 기반 업데이트를 사용하였기에 주사율이 높은 모니터에서는 게임이 더 빠르게 실행되고 있었다. 이럴 경우, 사용자가 가진 모니터별로 난이도가 달라져 공평한 밸런스로 게임을 즐길 수 없는 문제가 발생된다.

💡 문제 분석

• 게임의 오브젝트 이동이 초당 프레임 수에 따라 결정되고 있다.

• 60 Hz 모니터의 경우 초당 60번 업데이트가 발생하지만, 144 Hz의 경우 초당 144번 업데이트가 발생하여 게임 속도가 증가한다.
• 즉, 프레임수에 비례하여 속도가 증가하는 구조

🔎ㅤ관련 개념과 용어들

📍 주사율 = 화면이 1초에 몇 번 새로고침 되는가?

모니터의 성능을 나타내는 단위 중 하나로, 1초에 화면을 몇 번 갱신하는지를 의미한다.

• 60Hz 모니터 → 1초에 60번
• 144Hz 모니터 → 1초에 144번
• 240Hz 모니터 → 1초에 240번
  ➡️ㅤ주사율이 높을수록 부드러운 화면을 볼 수 있다.

📍 프레임과 FPS 란?

• 프레임 = 한장의 화면
  • 게임에서는 프레임을 빠르게 변경하여 움직임을 표현한다.

    
    

• FPS = 초당 몇 개의 프레임을 보여주는가?
  • 1초 동안 화면이 갱신되는 횟수를 의미한다.
  • 60FPS → 1초에 60번
  • 144FPS → 1초에 144번
    ➡️ㅤFPS가 높을수록 부드러운 움직임을 볼 수 있다.

🤔 그런데 왜 게임 속도까지 달라질까?

• 게임 로직은 프레임을 기준으로 실행되는데, 모니터 주사율이 높을수록 프레임 수도 증가하기 때문에 게임이 더 빨리 실행되는 문제가 발생

function update() {
  character.x += 5; // 1프레임마다 5px 이동
}

• 60FPS (60Hz 모니터)

  • 1초 = 60프레임 → 5px * 60 = 300px 이동

• 144FPS (144Hz 모니터)

  • 1초 = 144프레임 → 5px * 144 = 720px 이동

➡️ㅤ같은 시간 동안 더 멀리 이동 → 게임 난이도 증가

이렇게 되면, 같은 게임이더라도 주사율이 높은 사람은 더 빠르게 진행 되고, 주사율이 낮은 사람은 느리게 진행되는 문제가 발생한다.

✅ㅤ해결 방법 : Delta Time 적용

이 문제를 해결하기 위해 Delta Time 을 적용하여 시간 단위로 이동 속도를 조정하였다.

📍ㅤDelta Time 이란?

• 각 프레임 사이의 시간 차이를 의미한다.
• 즉, 각 프레임이 실행될 때 걸린 시간을 계산하여, 속도를 보정 해주는 방법이다.
• 현재 프레임 시간 - 이전 프레임 시간 을 계산하여 프레임 간격을 구한다.
• 오브젝트의 이동 속도를 speed * deltaTime 형태로 적용하여 일정한 속도로 움직이도록 조정한다.

💬ㅤDelta Time 적용 시

let lastFrameTime = 0;
function update(timestamp) {
  if (!lastFrameTime) lastFrameTime = timestamp;
  const deltaTime = (timestamp - lastFrameTime) / 1000; // 초 단위로 변환
  lastFrameTime = timestamp;
  character.x += 100 * deltaTime; // 1초에 100px 이동하도록 보정
}

• 60FPS (60Hz 모니터)

  • deltaTime ≈ 1/60 = 0.016초
  • 이동 거리 = 100 * 0.016 = 1.6px (프레임당 이동)
  • 1.6px * 60 = 100px (1초 이동)

• 144FPS (144Hz 모니터)

  • deltaTime ≈ 1/144 = 0.007초
  • 이동 거리 = 100 * 0.007 = 0.7px (프레임당 이동)
  • 0.7px * 144 = 100px (1초 이동)

➡️ㅤ주사율이 다르더라도 1초에 같은 거리(100px)만큼 이동

🛠 적용한 코드

requestAnimationFrame 의 timestamp 값을 활용하여 Delta Time을 계산

let lastFrameTime = 0; // 이전 프레임 시간 저장

function main(timestamp) {
  if (!lastFrameTime) lastFrameTime = timestamp;
  const deltaTime = (timestamp - lastFrameTime) / 1000; // 밀리초 → 초 변환
  lastFrameTime = timestamp;

  if (!Enemy.isGameOver) {
    update(deltaTime);
    render();
    requestId.value = requestAnimationFrame(main);
  } else {
    stop();
    stopAllMusic();
    emits("open-game-over", score.value, currentTime.value);
    cancelAnimationFrame(requestId.value);
  }
}

• deltaTime = (현재시간 - 이전시간) / 1000 으로 프레임 간격을 계산
• 이동 속도에 speed * deltaTime 을 곱해 초당 일정한 속도를 유지
• 게임 오버 시 requestAnimationFrame 을 중단하여 불필요한 연산 방지

🔗ㅤKaplay를 사용한 적용 방식

Kaplay에서는 requestAnimationFrame 을 직접 사용하지 않고 엔진의 onUpdate() 메서드를 활용하여 Delta Time을 적용

let lastUpdateTime = performance.now();

k.onUpdate(() => {
  if (!isGameStarted.value) return;

  const currentTime = performance.now();
  const deltaTime = (currentTime - lastUpdateTime) / 1000;
  lastUpdateTime = currentTime;

  for (let i = 0; i < obstaclesLayer.parts.length; i++) {
    const currentPart = obstaclesLayer.parts[i];
    const nextPart = obstaclesLayer.parts[(i + 1) % obstaclesLayer.parts.length];

    if (currentPart.pos.x < -IMAGE_WIDTH) {
      currentPart.pos.x = nextPart.pos.x + IMAGE_WIDTH;
    }

    currentPart.move(obstaclesLayer.speed * deltaTime * 60, 0);
  }

  obstaclesLayer.speed -= 5 * deltaTime; // 속도 변화도 deltaTime을 반영
});

• performance.now() 를 사용해 밀리초 단위의 프레임 간격을 계산
• obstaclesLayer.speed -= 5 * deltaTime; 로 속도 감소도 Delta Time 기반으로 조정

🎯 결과

• 주사율(Hz)에 상관없이 장애물이 일정한 속도로 이동 ➡️ 프레임 속도 차이에 따른 게임 속도 문제 해결

🕹️ Flappy-Boo : 플래피 부

유령 캐릭터 "Boo"가 장애물을 피하며 날아가는 단순하면서도 중독성 있는 게임이다. space 키를 조작하여 유령을 점프시키며 장애물에 부딪히지 않고 최대한 오래 비행하는 것이 목표이다.

📍 Kaplay 라이브러리 사용

• 이 게임은 Kaplay 라이브러리를 활용하여 구현하였다. Kaplay 는 복잡한 게임 로직을 간결하게 구현할 수 있도록 도와주는 라이브러리이다.

• 객체 관리와 충돌 감지, 애니메이션 처리 등 플래피 부 게임을 개발하는 데 있어 필수적인 요소들을 간단한 코드로 구현할 수 있게 도와주었다.
• 이를 통해 반복적인 코드를 줄이고 직관적인 메서드를 사용하여 빠르게 게임을 개발할 수 있었다.

🎬 Kaplay 초기화 설정

k = kaplay({
  width: 1300,
  height: 750,
  letterbox: true,
  global: true,
  canvas: canvas,
});

• kaplay() : 게임 엔진을 초기화하고 캔버스를 설정
• letterbox : 화면 비율 유지를 위해 레터박스를 추가
• global : 전역으로 접근할 수 있도록 설정
• canvas : 사용할 HTML 캔버스를 지정

🎬 Scene 분리 — Start/Game

• 게임이 로딩되는 게임 시작 화면 과 실제 게임이 진행되는 게임 화면 을 구분하여 구현하였다.

• 게임 시작 화면에서 play 버튼을 누르거나 space 를 누르면 게임 화면으로 넘어가도록 하였다.

✔ㅤ구현 방식

• kaplay의 scene 기능을 사용하여 Start,Game 씬을 나누고 go()로 전환할 수 있게 구현하였다.
• k.scene("이름", 콜백함수) / k.go("이름")

// 🏁 Start 씬: 시작 화면
k.scene("start", async () => {
  makeBackground(k);

  const playBtn = k.add([
    k.sprite("playBtn"),
    k.scale(0.35),
    k.area(),
    k.anchor("center"),
    k.pos(k.center().x + 20, k.center().y + 40),
  ]);

  playBtn.onClick(goToGame);  // 버튼 클릭 시 main 씬으로 이동
});


// 🎮 Game 씬: 실제 게임 플레이 화면
k.scene("main", async () => {
  let score = 0;
  makeBackground(k);

  // 플레이어 생성 및 컨트롤 설정
  const player = makePlayer(k);
  player.setControls();

  // 충돌 처리
  player.onCollide("obstacle", async () => {
    if (player.isDead) return;
    player.isDead = true;
    isGameStarted.value = false;
    emit("open-game-over", score, currentTime.value);
    reset();
  });

  k.onKeyPress("space", () => {
    if (!isGameStarted.value) {
      startGame();
    } else if (!player.isDead) {
      player.jump(400);
    }
  });
});

⚙️ 게임 요소 관리

1. 게임 요소 로드

k.loadSprite("boo", "/assets/images/game/flappy/Boo.png");

• k.loadSprite("불러올 이름", "파일 경로")
• k.sprite("불러올 이름") 으로 나중에 사용하도록 준비
• 즉, 사용할 이미지를 미리 불러오는 역할

k.loadSound("jump", "/assets/images/game/flappy/jump.wav");
k.play("jump", { volume: 0.02 });

• k.loadSound("불러올 이름", "파일 경로") : 사운드를 로드하는 메서드로 게임의 사운드를
• k.play("불러올 이름" {볼륨}) : 사운드를 재생

2. 객체 추가

const player = k.add([k.sprite("boo"), k.pos(100, 100), k.area()]);

• k.add() : 게임 내 새로운 오브젝트(플레이어, 장애물, 배경 등)를 추가할 때 사용
• k.pos() : 위치 지정
• k.area() : 충돌 감지를 위한 hitbox 충돌 영역 지정
• k.sprite() : 오브젝트에 사용할 이미지 지정
• k.body() : 물리 속성

  k.setGravity(2500);

• 게임의 중력 값 설정

3. 업데이트 처리

k.onUpdate(() => {
  if (isGameStarted.value) {
    clouds.forEach((cloud) => {
      cloud.move(cloud.speed, 0);
      if (cloud.pos.x > canvas.width) {
        cloud.pos.x = -cloud.width;}})
}});

• k.onUpdate(callback) : 매 프레임마다 callback 실행
• 무한 스크롤 구현에 활용 : 화면에 벗어나면 오른쪽으로 다시 재설정

4. 특정 키 처리

k.onKeyPress("space", () => {
  if (!isGameStarted.value) {
    startGame();
  } else if (!player.isDead) {
    player.jump(400);
    if (audioEnabled.value) k.play("jump", { volume: 0.02 });
  }
});

• k.onkeyPress(key, callback) : 특정 키가 눌렸을 경우, 1번만 callback 실행
• 게임의 시작과 플레이어의 점프 이벤트 구현에 활용

5. 점수 관리

k.loop(1, () => {
  if (isGameStarted.value && !player.isDead) {
    score += 50;
    scoreLabel.updateScore(score);}
});

• 주어진 시간 간격마다 콜백함수를 실행
• k.loop(interval, callback)
• 게임 내 점수를 주기적으로 증가 시키는 로직에 활용

6. 충돌 감지

player.onCollide("obstacle", async () => {
  if (player.isDead) return;

  if (audioEnabled.value) k.play("hurt");
  player.isDead = true;
  player.disableControls();
  isGameStarted.value = false;
  obstaclesLayer.speed = 0;
  map.speed = 0;

  stop();
  emit("open-game-over", score, currentTime.value);
  reset();
});

• player.onCollide(tag, callback) : 특정 태그가 부딪혔을 때, 1번만 callback 실행
• 플레이어가 장애물에 부딪혔을 경우 충돌 감지에 활용

7. 카메라 세팅

k.setCamScale(k.vec2(1.2));
player.onUpdate(() => {
  if (isGameStarted.value && !player.isDead) {
    k.setCamPos(player.pos.x + 100, 400);}
});

• 카메라의 확대/축소 비율과 위치 조정
• 게임 내 카메라의 시야를 조정하여 플레이어의 움직임에 따라 카메라가 따라가도록 설정

💡 화면 크기 대응

🚨 문제점

모니터의 해상도가 다를 때, 게임 캔버스 크기가 고정되어 있으면 너무 작거나 크게 보이는 문제가 발생

✅ 해결

window.addEventListener("resize", setCanvasSize)를 사용하여 화면 크기가 변경될 때마다 캔버스 크기를 조절하도록 구현

// 캔버스 크기 조정 함수
function setCanvasSize() {
  const width = window.innerWidth;
  const height = window.innerHeight;

  game.setSize(width, height);
}

// 초기 캔버스 설정 및 리사이즈 이벤트 연결
setCanvasSize();
window.addEventListener("resize", setCanvasSize);

💡 장애물 생성 및 무한 스크롤 구현

🚨 문제점

장애물이 1번이 아닌 플레이어가 게임 오버 될 때까지 무한히 생성되어야 하며, 장애물을 전부 그릴 수 없기 때문에 1개의 장애물 파일로 계속 재활용해야 하는 상황

✅ 해결

onUpdate 메서드를 사용하여 장애물을 주기적으로 생성하고 화면 밖으로 나간 장애물을 다시 오른쪽 끝으로 재배치하는 로직을 구현

// 장애물 배열 및 속도 설정
const obstaclesLayer = {
  speed: -100,
  parts: [
    k.add([
      k.sprite("obstacles"),
      k.pos(0, 0),
      k.area(),
      k.scale(SCALE_FACTOR),
    ]),
    k.add([
      k.sprite("obstacles"),
      k.pos(IMAGE_WIDTH, 0),
      k.area(),
      k.scale(SCALE_FACTOR),
    ]),
  ],
};

// 장애물 무한 스크롤 처리
k.onUpdate(() => {
  const currentTime = performance.now();
  const deltaTime = (currentTime - lastUpdateTime) / 1000;
  lastUpdateTime = currentTime;

  if (isGameStarted.value) {
    for (let i = 0; i < obstaclesLayer.parts.length; i++) {
      const currentPart = obstaclesLayer.parts[i];
      const nextPart =
        obstaclesLayer.parts[(i + 1) % obstaclesLayer.parts.length];

      if (currentPart.pos.x < -IMAGE_WIDTH) {
        currentPart.pos.x = nextPart.pos.x + IMAGE_WIDTH;
      }
      currentPart.move(obstaclesLayer.speed * deltaTime * 60, 0);
    }
  }

  if (isGameStarted.value) {
    obstaclesLayer.speed -= 5 * deltaTime;
  }
});

• obstaclesLayer 로 2개의 장애물 파트를 배열로 관리하고 각각의 장애물이 화면 밖으로 나가면 다른 장애물 뒤로 재배치
• k.onUpdate 를 사용하여 모든 장애물을 매 프레임마다 왼쪽으로 이동시키고 화면 밖으로 나가면 다시 오른쪽 끝으로 보내는 방식으로 무한 스크롤을 구현

📎 참고

• 무한 스크롤 구현 참고 아티클

💡 난이도 상승

🚨 문제점

똑같은 장애물이 반복되기 때문에 사용자들이 재미를 느끼려면 점차 난이도가 상승되는 포인트가 필요

✅ 해결

게임이 진행됨에 따라 장애물의 속도를 점차 증가시켜 난이도를 증가시키는 로직 추가

if (isGameStarted.value) {
  obstaclesLayer.speed -= 5 * deltaTime;
}

• 초기에 장애물의 기본 속도는 -100 으로 설정 ( 왼쪽 방향으로 이동 )
• 매 프레임마다 5*deltaTime 만큼 감소

💡 충돌 감지 및 게임 오버 처리

🚨 문제점

플레이어와 장애물이 부딪혔을 시, 게임 오버 처리를 위해 충돌 감지 로직이 필요

✅ 해결

onCollide를 사용하여 플레이어와 장애물 충돌을 감지하고 충돌 시 게임 오버 화면으로 전환하도록 구현

// 플레이어 충돌 감지 및 게임 오버 처리
player.onCollide("obstacle", async () => {
  if (player.isDead) return;

  if (audioEnabled.value) k.play("hurt");
  player.isDead = true;
  player.disableControls();
  isGameStarted.value = false;
  obstaclesLayer.speed = 0;
  map.speed = 0;

  stop();

  // 게임 오버 화면 호출
  emit("open-game-over", score, currentTime.value);
  reset();
});

• 플레이어가 장애물과 충돌할 때 게임 오버가 발생하도록 처리
• 충돌 후에는 player.isDead=true 로 설정하고 장애물과의 상호작용을 비활성화

🚨 문제점

사용자가 이미지를 업로드할 때 이미지의 파일명이 한글로 된 경우 업로드 되지 않는 오류가 발생했다.

💡 문제 분석

• 한글 파일 이름 인코딩 문제 : 파일명에 한글이 포함된 경우, 서버에서 이를 처리하는 데 문제가 발생할 수 있다. 이는 URL 인코딩이나 파일 시스템에서 한글을 처리할 수 없는 경우로 인해 업로드 실패가 발생
• 브라우저의 파일 전송 문제 : 같은 이유로 브라우저가 한글 파일명을 URL로 올바르게 인코딩하지 못하는 경우 서버가 이를 처리하지 못하고 오류를 발생시킬 수 있다.

✅ 올바르게 인코딩 할 수 있도록 수정

• 파일명을 ASCII로 변환 : 한글 파일명을 ASCII로 변환하여 서버에서 인식할 수 있게 만든다. 이를 위해 normalize 메서드를 사용하여 유니코드를 정규화하고, 특수 문자를 제거하여 ASCII 문자만 남도록 처리한다.

const sanitizeFileName = (name) => {
  const extension = name.split('.').pop();
  const baseName = name.replace(/\.[^/.]+$/, "");
  const sanitizedBaseName = baseName
    .normalize("NFD") // 유니코드 정규화
    .replace(/[\u0300-\u036f]/g, "") // 발음 구별 기호 제거
    .replace(/[^a-zA-Z0-9-_]/g, ""); // 알파벳, 숫자, -, _ 만 허용
  return `${sanitizedBaseName}-${Date.now()}.${extension}`;
};

• 파일 객체 유효성 확인 : 업로드할 파일이 브라우저에서 기본 제공하는 File 객체인지 확인하고 유효한 형식인지 검사하는 로직 추가

  if (!(file instanceof File)) {
  throw new Error("유효하지 않은 파일 형식입니다.");
  }

  

수정 후 정상적으로 업로드 되는 것을 확인!

🔗 ASCII 파일명 변환 방식의 장점

✔ㅤ서버 호환성 향상

• ASCII 변환을 통해 한글, 특수문자, 공백 등이 포함된 파일 이름을 안전한 형식으로 변경, 이로 인해 서버나 파일 시스템에서 파일 이름 인코딩 문제를 방지

✔ㅤURL 안정성 확보

• 파일명이 URL 인코딩 없이도 안전하게 사용할 수 있다. URL에서 잘못 처리될 수 있는 문자를 제거하므로 업로드된 파일의 접근 URL이 더 간결하고 안정적이다.

✔ㅤ간단한 구현

• 파일명을 ASCII로 변환하는 로직은 비교적 간단하고 대부분 환경에서 호환된다.

🔗 normalize()

문자열을 유니코드 정규화 형태로 변환하는 메서드이다. 유니코드 정규화란? 유니코드 문자들을 표준화된 형태로 변환하여 같은 의미의 문자가 여러 가지 방식으로 표현되지 않도록 하는 방법이다.

✔ㅤ주요 용도

• 발음 구별 기호 제거
• 문자 결합 및 분리

✔ㅤ사용법

문자열을 특정 형태로 변환하는데, 가장 일반적으로 사용되는 것은 NFC, NFD, NFKC, NFKD

• NFC : 문자를 합성된 형태로 변환

• NFD : 문자를 분리된 형태로 변환

• NFKC : 문자들의 호환성을 고려하여 변환

• NFKD : NFKC 와 유사하지만, 분리된 형태로 변환

구성 흐름 : 파일 선택 → 미리보기 생성 → 상위 컴포넌트로 데이터 전달 → 서버 업로드 준비 → 업로드

🔎 컴포넌트 구조

📍 PostEditImg

: 다중 이미지 업로드 UI와 로직을 담당하는 부모 컴포넌트

• 최대 4개의 이미지 슬롯
• 이미지 미리보기와 업로드 트리거 관리

📍 PostEditImgCard

: 개별 이미지 카드를 렌더링하는 자식 컴포넌트

• 이미지가 있으면 미리보기를 표시하고, 없으면 업로드 버튼(+)을 표시
• 크기와 투명도를 props를 받아 동적으로 스타일링

🎨 이미지 업로드 UI

• <input type="file" multiple>를 4개 생성하여 각 슬롯에 연결
• v-for를 사용해 인덱스 별로 파일 입력을 동적으로 생성
• hidden 클래스로 input을 숨기고, PostEditImgCard 클릭 시 triggerFileSelect로 파일 선택을 트리거
• 이미지 업로드 후 미리보기는 URL.createObjectURl(file) 로 생성

🔗 임시 URL 생성

• URL.createObjectURL(file) 은 파일 객체를 가리키는 임시 URL을 생성해준다. 이 URLdmf <img> 태그의 src 속성에 설정하면 사용자가 업로드한 이미지를 화면에 미리보기로 보여줄 수 있다.

✔ㅤ메모리 관리

• createObjectURL 로 생성된 URL은 브라우저가 자동으로 해제하지 않기 때문에, 불필요한 메모리 사용을 방지하려면 사용이 끝난 후 URL.revokeObjectURL(url)을 호출하여 해제해야 한다.

[ 기존 코드 ]

handleFileChange(event, index) {
  const files = event.target.files;
  if (!files || files.length === 0) return;

  const newImages = Array.from(files).map((file) => ({
    file,
    preview: URL.createObjectURL(file),
  }));

  this.$emit("addImage", { index, images: newImages });
  event.target.value = "";
},

[ 수정 코드 ]

handleFileChange(event, index) {
  const files = event.target.files;
  if (!files || files.length === 0) return;

  if (this.images[index] && this.images[index].preview) {
    URL.revokeObjectURL(this.images[index].preview);
  }

  const newImages = Array.from(files).map((file) => ({
    file,
    preview: URL.createObjectURL(file),
  }));

  this.$emit("addImage", { index, images: newImages });
  event.target.value = "";
},

💬 코멘트

미리보기 구현에만 집중하다 보니, 이후의 처리를 충분히 고려하지 못했던 것 같다. 그래서 URL.createObjectURL 을 적용했지만, 메모리 누수를 방지하기 위해 URL.revokeObjectURL을 사용해야 한다는 점을 간과했다. 앞으로는 이러한 후처리까지 신중하게 고려하며 개발해야겠다.

🚨 이미지 추가 시 슬롯 위치 벗어남

🚨 문제점

이미지를 추가하면 의도된 슬롯에 위치해야 하지만, 제대로 렌더링 되지 않고, 레이아웃을 벗어나 예상치 못한 위치에 렌더링 되는 문제 발생

<post-edit-img-card
  v-if="images.length > 0"
  :imgSrc="images[0].preview || images[0]"
  :size="'w-[400px] h-[400px] lg:w-[440px] lg:h-[440px]'"
  :opacity="100"
  @click="handleRemoveImage(0)"
></post-edit-img-card>

📎 Vue의 동작 방식

• vue는 화면을 그리기 위해 Virtual DOM 이라는 가상 화면을 사용한다. 이 가상 화면은 실제 HTML을 미리 계산해서 효율적으로 업데이트 한다.
• v-if만 있을 때는, 조건이 거짓일 때 그 부분이 없어지는데, vue는 혼란스러울 수 있다.
• postEditImgCard 는 같은 컴포넌트를 재사용하기 때문에 이 부분에서 혼란이 생길 수 있다.

💡 문제 분석

• images.length > 0 일 때 0번 슬롯에 미리보기를 보여주고 클릭 시 해당 이미지를 삭제하게 조건부 처리를 해둔 상태
• 하지만 images.length > 0이 거짓일 때 어떻게 할지 명확하게 지정되어 있지 않고 있다.
• 결과적으로 이미지를 추가하면, 0번 슬롯에 미리보기가 들어가야 하지만 Vue가 레이아웃을 잘못 재정렬해서 다른 곳에 배치되게 만들었다는 가정

<post-edit-img-card
  v-else
  @click="triggerFileSelect(0)"
></post-edit-img-card>

✅ v-else 를 추가

• v-else를 추가하여 images.length > 0이 거짓일 때 렌더링 할 조건을 명확하게 함
• v-else가 없었을 때는 갱신 과정이 불안정해서 0번 슬롯이 레이아웃을 벗어났지만, 규칙이 제대로 잡히니 깔끔하게 갱신됨

🧐 다른 해결법 : key 속성으로 위치 고정

• key 속성을 주어서, Vue가 같은 컴포넌트를 새로 그리더라도 각각을 구분할 수 있게 함

  <post-edit-img-card
  v-if="images.length > 0"
  :key="'image-' + images[0].preview"
  :imgSrc="images[0].preview"
  ></post-edit-img-card>

📍 구현 로직 요약

<!-- 이미지 영역 -->
<post-edit-img-card
  v-if="images.length > 0"
  :imgSrc="images[0].preview || images[0]"
  :size="'w-[400px] h-[400px] lg:w-[440px] lg:h-[440px]'"
  :opacity="100"
  @click="handleRemoveImage(0)"
></post-edit-img-card>

• 게시글 업로드와 수정 기능에 컴포넌트를 같이 사용하므로, 업로드된 첫 번째 이미지가 있으면 렌더링하여 표시하도록 했다.
• 또한 @click 이벤트를 추가하여 클릭 시 해당 이미지를 삭제할 수 있게 했다.

<post-edit-img-card
  v-else
  @click="triggerFileSelect(0)"
></post-edit-img-card>

• 만약 첫 번째 이미지가 없다면, 클릭 시 파일 업로드가 되도록 했다.

🛠️ 추가 개선점

• 드래그 앤 드랍 기능 추가 : 이미지 업로드 UX 개선
• 이미지 추가/삭제 시 애니메이션 추가 : 부드러운 전환
• 파일 크기 유효성 검사 : 용량이 클 경우에 대한 검증 부재

💬 COMMA 의 배경

📍 어떤 니즈가 있을까?

현대 사회는 고물가, 빠듯한 직장 생활, 치열한 학업 등으로 인해 많은 사람들이 스트레스를 해소할 공간을 찾고 있다. 스트레스 해소 방법을 고민하던 중, 문득 게임이 떠올랐다. 게임을 즐기는 짧은 순간에도 도파민이 분비되어 정서적 안정감을 주는 등, 게임은 훌륭한 스트레스 해소 수단이 될 수 있을 것 같았다.

또한 자료 조사에 따르면, 현대 사회에서 레트로 문화가 하나의 휴식 방법으로 자리 잡고 있으며, 과거의 경험을 재현하는 것이 심리적 위안을 준다는 분석이 나왔다.

📍 어떻게 도출되었을까?

그렇게 "바쁜 현대인들에게 잠깐의 여유를 제공하고, 어린 시절 오락실의 감성을 되살릴 수 있는 공간이 있다면 어떨까?" 하는 생각이 도출되었고 자연스럽게 쉬다 -> 쉼 -> 쉼표 로 이어져 "추억을 꺠우는 즐거운 쉼표!" 의 COMMA가 탄생했다.

COMMA는 향수를 자극하는 경험과 새로운 소셜 연결을 동시에 제공하는 미니게임&커뮤니티 플랫폼으로 누구나 쉽게 접근할 수 있는 미니게임으로 짧은 시간 동안 스트레스를 해소하고 성취감을 느낄 수 있다.

💬 COMMA의 기획

📍 주요 기능 및 게임 종류

• 소셜 로그인
• 전광판
• 게임 커뮤니티
• 게임 (테트리스 / 플래피부 / 바운스볼 / 슈팅게임 / 지뢰찾기 )
• 자유 커뮤니티
• 게시글 작성/수정
• 댓글
• 랭킹
• 마이페이지

📍 IA

서비스의 전반적인 기능과 메뉴 구조를 볼 수 있게 작성하였다.

ㅤ

💬 KPT 회고

🚀 Keep

• 퍼블리싱이 확실히 익숙해지고 빨라졌다는 것을 느낄 수 있었다. 다른 팀원분들 것도 도와주면서 더 많이 익숙해진 것 같다.
• 가장 뿌듯했던 건 이번에 처음으로 라이브러리를 활용해보았는데, 라이브러리는 이렇게 활용하고 사용하는 거구나를 알 수 있는 계기가 된 것 같아서 잘한 선택인 것 같다.

🚨 Problem

• 가장 아쉬웠던 점은 supabase 를 공부하고 싶었는데, 그렇게 하지 못했다는 점이다. 아무래도 기간이 3주밖에 없어서 잘 아는 팀원이 붙어서 빠르게 작업을 할 수밖에 없었다. 하지만 배워가는 시기인데, 한 번 무모하게 도전을 해봐도 좋았을 거라는 생각이 든다.
• 그래서 이번 기회에 짜여져있는 것들을 참고하면서 supabase 에 대해서 좀 더 공부해보려고 한다.

🔥 Try

• 이번 프로젝트는 Vue 로 진행했는데, 이걸 다시 React로 마이그레이션 해보려고 한다.
• 또한 Supabase 백업본을 받아서 이걸 옮기는 작업도 해보면서 한번 유지 관리를 해보려고 한다.

• 학습 방식 : 챕터별로 함께 읽고 공유 및 문제 풀이

• 학습 시간 : AM 10:00 ~ PM 12:00
• 학습 목표 : ~ 09. 트리

💬 새로 알게 된 것

01. 트리

📕 [ P. 289 - 09 트리]

" 트리는 데이터를 저장하고 탐색하기에 유용한 구조를 갖고 있습니다... 프로그래밍 분야에서는 트리는 계층 구조를 표현하는 용도로 많이 사용합니다."

• 자동 완성 기능 : 트리는 문자열 처리에도 많이 활용된다. 예를 들어 검색 엔진에서 자동 검색어 추천 기능 도 트라이 라는 독특한 트리 구조를 활용한 것이다. 이를 활용하면 접두사나 패턴 검색을 쉽게 할 수 있다.
• 데이터베이스 : 데이터를 쉽게 검색, 삽입, 삭제를 할 수 있도록 트리를 활용해서 데이터를 구조화하고 인덱싱한다. 이때 B-트리 나 B+트리 를 많이 사용한다.

(1) 트리의 구조

• 노드 : 트리를 구성하는 요소로 간선으로 연결된 노드들은 부모-자식 관계가 있다고 표현한다. 가장 맨 위에 있는 노드를 루트 노드 이고 상대적으로 위에 있는 노드를 부모 노드 , 아래에 있는 노드를 자식 노드 라고 한다. 또한, 같은 부모 노드를 갖는 노드는 형제 노드 라고 한다.
• edge : 노드와 노드 사이를 이어주는 선으로, 단방향 간선으로 연결되 어 있다. 루트 노드로부터 특정 노드까지 거쳐가는 최소한의 간선 수를 레벨 로 표현한다.
• 리프 노드 : 자식이 없는 노드이다. 우리말로는 말단 노드라고 한다.
• 차수(degree) : 특정 노드에서 아래로 향하는 간선의 개수이다.

02. 이진 트리

📕 [ P. 291 - 09 트리 ]

" 트리 종류는 굉장히 다양하지만 코딩 테스트에서는 이진 트리만 제대로 알고 있으면 충분합니다. 이진 트리란 모든 노드의 최대 차수가 2를 넘지 않는 트리 를 말합니다. ( 간선이 최대 2개인 트리입니다. ) "

• 이진 트리는 배열 이나 포인터 로 구현할 수 있다.

03. 배열로 구현

배열은 선형 자료구조이고 트리는 계층 자료구조이다. 따라서 배열로 트리를 표현하려면 다음과 같은 3가지 규칙이 필요하다.

• 루트 노드는 배열 인덱스 1번에 저장한다.
• 왼쪽 자식 노드 의 배열 인덱스는 부모 노드의 배열 인덱스 X 2
• 오른쪽 자식 노드 의 배열 인덱스는 부모 노드의 배열 인덱스 X 2+1

⚠️ 루트 노드를 0 혹은 1로 정해야 할 경우, 다르니 주의!!

• 0 의 경우, 왼쪽 자식 노드는 부모 노드의 배열 인덱스 X 2 + 1 이 되고, 오른쪽 자식 노드 는 부모 노드의 배열 인덱스 X 2 + 2 가 된다.

03-2 배열로 표현한 트리

트리를 표현한 배열을 보면 빈 값이 꽤 많이 보인다. 노드들의 부모-자식 관계 를 곱셈 연산하여 배열의 인덱스로 사용 하기 떄문에 실제 노드 개수보다 많은 공간을 사용할 수밖에 없다.

• 즉, 배열로 트리를 표현하면 자식이 없거나 쓰지 않는 인덱스들은 모두 빈 값이므로 메모리가 낭비된다는 단점이 있다.
• 그렇다고 해서 배열 표현 방법이 나쁘지 않다. 메모리만 넉넉하다면 구현 시간을 단축하는 용도로 좋다.

04. 이진 트리 순회하기

(1) 전위 순회 ( preorder )

• 현재 노드를 부모 노드로 생각했을 때, 부모 노드 → 왼쪽 자식 노드 → 오른쪽 자식 노드 순서로 방문

(2) 중위 순회 ( inorder )

• 현재 노드를 부모 노드로 생각했을 때, 왼쪽 자식 노드 → 부모 노드 → 오른쪽 자식 노드 순서로 방문

(3) 후위 순회 ( postorder )

• 현재 노드를 부모 노드로 생각했을 때, 왼쪽 자식 노드 → 오른쪽 자식 노드 → 부모 노드 순서로 방문

05. 이진 트리 탐색하기

이진 트리에서 가장 중요한 것은 바로 탐색을 효율적으로 할 수 있도록 트리를 구축하는 것이다.

• 데이터 크기를 따져 현재 노드보다 값이 작으면 왼쪽 자식 위치에, 크거나 같으면 오른쪽 자식 위치에 배치하는 독특한 정렬 방식
• 데이터를 하나씩 삽입하면서 이진 탐색 트리를 구축한다. 즉, 삽입과 동시에 정렬을 한다.

1. 찾으려는 값이 현재 노드의 값과 같으면 탐색을 종료하고 크면 오른쪽 노드를 탐색한다.
2. 본인이 찾으려는 값이 현재 노드의 값보다 작으면 왼쪽 노드를 탐색한다.
3. 값을 찾으면 종료한다. 노드가 없을 때까지 계속 탐색했는데 값이 없으면 현재 트리에 값이 없는 것이다.

이러한 이진 탐색 트리의 시간 복잡도는 트리 균형에 의존 한다. 균현이 유지되었다고 가정했을 때, 삽입ㅂ과 탐색 연산 시 이진 탐색 트리에 저장된 노드가 N개라고 하면 O(logN)이다.

📌 문제 풀이

🎯 트리 순회 문제

• 이진 트리를 표현한 배열 nodes를 인자로 받습니다.
• 예를 들어 nodes가 [1, 2, 3, 4, 5, 6, 7]이면
• 이진 트리에 대하여 전위 순회, 중위 순회, 후위 순회 결과를 반환하는 solution() 함수를 구현하세요.

  ---

  ✔ 제한 조건

• 입력 노드값의 개수는 1개 이상 1,000개 이하입니다
• 노드값은 정수형이며, 중복되지 않습니다

✔ 입출력 예

• nodes : [1, 2, 3, 4, 5, 6, 7]
• return : ["1 2 4 5 3 6 7", "4 2 5 1 6 3 7", "4 5 2 6 7 3 1"]

#1 : 배열로 구현

• 전위 순회(pre-order) : "현재 노드 -> 왼쪽 자식 -> 오른쪽 자식"
• 중위 순회(in-order) : "왼쪽 자식 -> 현재 노드 -> 오른쪽 자식"
• 후위 순회(post-order) : "왼쪽 자식 -> 오른쪽 자식 -> 현재 노드"

function preOrderTreeArray(tree, index = 0, result = []) {
  if (index < tree.length && tree[index] !== undefined) {
    result.push(tree[index]);
    preOrderTreeArray(tree, 2 * index + 1, result);
    preOrderTreeArray(tree, 2 * index + 2, result);
  }
  return result;
}

function inOrderTreeArray(tree, index = 0, result = []) {
  if (index < tree.length && tree[index] !== undefined) {
    inOrderTreeArray(tree, 2 * index + 1, result);
    result.push(tree[index]);
    inOrderTreeArray(tree, 2 * index + 2, result);
  }
  return result;
}

function postOrderTreeArray(tree, index = 0, result = []) {
  if (index < tree.length && tree[index] !== undefined) {
    postOrderTreeArray(tree, 2 * index + 1, result);
    postOrderTreeArray(tree, 2 * index + 2, result);
    result.push(tree[index]);
  }
  return result;
}

function treeArray(nodes) {
  const tree = nodes;
  return {
    preOrder: preOrderTreeArray(tree),
    inOrder: inOrderTreeArray(tree),
    postOrder: postOrderTreeArray(tree)
  };
}

const nodes = [1, 2, 3, 4, 5, 6, 7];
const result = treeArray(nodes);
console.log('Pre-order:', result.preOrder);
console.log('In-order:', result.inOrder);
console.log('Post-order:', result.postOrder);

🎯 Lv.2 예상 대진표

• 게임 형식 : N명이 참가하는 토너먼트(2의 지수 승). 1번↔2번 , 3번↔4번 등으로 대결하며, 승자는 다음 라운드에 진출
• 참가자 번호 재배정 : 승자는 다음 라운드에서 1번부터 차례로 번호를 재배정 받음
• 목표 : A번 참가자와 B번 참가자가 몇 번째 라운드에서 만나는지 구하기

  ---

  ✔ 제한 조건

• N: 21 이상 220 이하 (2의 지수 승)
• A, B: N 이하 자연수, A ≠ B

function solution(n,a,b)
{
    let round = 1;
    while(a!==b) {
        a = Math.ceil(a/2);
        b = Math.ceil(b/2);
        round++;
    }
    return round;
}

• a 와 b가 같아질 때까지 반복문을 돌린다.
• 매 라운드마다 a와 b의 다음 라운드 번호로 갱신해준다.
  • 모든 그룹은 2명씩 짝이기 때문에 /2 로 나누고 Math.ceil 로 올려주면 다음 라운드 번호가 나온다.

🚀 회고

• 트리 같은 경우, 정처기를 공부하면서 이미 한 번 봤던 개념이라 좀 더 친숙하게 다가왔던 것 같다.
• 그리고 앞서 큐나 해시보다는 구현하기가 어렵지 않았다.

일단 Supabase 를 본격적으로 공부하기 전, 이게 어떤 것이고 어떤 점이 좋은지 알아보자.

✅ㅤ장점

• 오픈 소스 : Supabase 는 오픈 소스 프로젝트로, 코드가 공개되어 있어 커스텀마이징이 가능하다.
• PostgreSQL 기반 : PostgreSQL 을 사용하여 데이터베이스ㅡㄹ 관리하므로, 관계형 데이터베이스의 강력한 기능을 활용할 수 있다.
• 실시간 데이터 : 실시간 데이터베이스 업데이트를 지원하여, 실시간 애플리케이션 개발에 유리하다.
• 자동 API 생성 : 데이터베이스 테이블을 기반으로 자동으로 RESTFul API 를 생성해 주어, API 서버 구축이 간편하다.

📎ㅤPostgreSQL 이란?

• 오픈소스 관계형 데이터베이스 관리 시스템으로, 복잡한 쿼리와 트랜잭션을 처리하는 데 강력한 기능을 제공한다.
• 관계형 데이터베이스 : 데이터를 테이블 형식으로 저장하고, SQL을 사용해 데이터를 관리한다.
• ACID 준수 : 데이터 무결성 및 일관성을 보장하는 트랜잭션을 지원한다.
• 확장성 : 대규모 데이터 처리에 유리하며, 다양한 데이터 타입과 함수 확장이 가능하다.
• 오픈소스 : 무료로 사용 가능하며, 커스텀마이징이 가능하다.
• 고급 기능 : JSON, XML, GIS 데이터 처리 등 다양한 고급 기능을 제공한다.

✅ㅤ단점

• 기능 제한 : Firebase 에서 제공하는 일부 고급 기능 (ex. Cloud Functions , Firebase ML 등)은 Supabase 에서는 제공되지 않거나, 구현이 부족할 수 있다.
• 확장성 : 대규모 애플리케이션에서는 Supabase 의 확장성이 Firebase보다 떨어질 수 있다.

사이드 프로젝트에서 Supabase 를 이용해서 소셜 로그인 기능을 구현하고자. 팀원분들과 각자 공부해오기로 했다. 그래서 소셜 로그인 기능 을 중심으로 정리해보고자 한다.

📌ㅤSupabase에서의...

1. 프로젝트 설정

• 프로젝트 대시보드 : 프로젝트를 생성하면 대시보드로 이동한다.
• API 키 확인 : 대시보드에서 Project Settings > API 로 가면 anon API 키와 service_role API 키를 확인할 수 있다. ( 이 키를 나중에 사용 )

2. 인증 설정 ( 소셜 로그인 활성화 )

• Authentication 설정 : 대시보드에서 "Authentication" 메뉴를 클릭하고, "Providers" 탭으로 이동한다.

• 소셜 로그인 제공자 추가 : "Enable Sign in with ----" 섹션에서 사용할 소셜 로그인을 활성화한다. 예를 들어, Google 로그인을 사용하려면 "Enable Sign in with Google"를 활성화 한다.

  • Google 로그인 설정 : "Client IDs"와 "Client Secret (for OAuth)"가 있는데 이는 아이디와 비밀번호와 같다. Google API 콘솔에서 발급받은 클라이언트 ID와 클라이언트 비밀번호를 입력해야 한다.

  • 🚫 "Skip nonce checks" : 이는 ID 토큰에서 nonce 값을 확인하지 않도록 설정하는 옵션 이다. 즉, 인증 요청과 응답을 매칭하기 위한 고유 식별자로 보통 보안을 강화하기 위해 사용 되며, 이 옵션을 활성화시키면 보안 수준이 낮아질 수 있어서 권장되지는 않는다. ( 보통은 iOS 앱과 같이 nonce 를 설정할 수 없는 환경에서 사용한다.)

  • Callback URL (for OAuth) : 로그인 인증 후 사용자에게 다시 리디렉션되는 URL로, 만약 Google이면 Google OAuth 인증이 완료되면 사용자가 Supabase로 돌아올 수 있도록 지정된 URL이다. ➡️ 이 URL은 Google API 콘솔에 등록해야 한다. ( 사용자가 Google 로그인 후, 인증 결과를 Supabase가 처리할 수 있도록 연결하는 역할 을 한다. )

    📎ㅤ사용자 로그인 예시 과정

    1. 사용자가 로그인 버튼을 클릭 → Google 로그인 화면으로 이동
    2. Google 로그인 성공 → Callback URL로 리디렉션
    3. Supabase가 이 URL에서 결과를 받아 사용자를 인증 처리 🌟
    4. 사용자는 애플리케이션의 화면으로 이동

- Google 개발자 콘솔에 가서 "새 프로젝트 생성" 후, OAuth 2.0 클라이언트 ID를 생성하고, 이를 Supabase 설정에 입력헤야 한다.

> ###  📎ㅤGoogle API 콘솔에서 생성하는 단계
> 1. `Google Cloud Console` 에 접속
> 2. Google 계정으로 로그인 → 로그인 후, 프로젝트를 생성하거나 기존 프로젝트를 선택 할 수 있다.
> 3. 상단의 `"프로젝트 선택"` 을 클릭 → 새 프로젝트 만들기 선택 → 프로젝트 이름 입력, (필요시 조직 선택) 만들기 클릭 → `생성한 프로젝트 선택`
> 4. 왼쪽 메뉴에서 `APls 및 서비스 > OAuth 동의` 클릭 → 외부를 선택하고 만들기 클릭 → `앱 이름` , `사용자 이메일` , `앱 로고(선택)` 를 입력 → `앱 도메인` 입력 → 개인정보처리방침 및 서비스 약관 URL 입력 → 개발자 연락처 정보 → 저장 및 계속
> 5. `API 및 서비스 > 라이브러리` 선택 → 검색창에 `Google Identity Services API` 를 검색 → 활성화
> 6. `API 및 서비스 > 사용자 인증 정보` 선택 → ` + 사용자 인증 정보 만들기` 클릭 후 OAuth 클라이언트 ID를 선택 → 애플리케이션 유형 선택 → 클라이언트 ID 이름을 입력 → Supabase에서 제공한 `Callback URL` 를 입력 → 만들기

📌ㅤ프로젝트 파일에서의...

1. Supabase 클라이언트 설정

• Supabase JavaScript 라이브러리 설치 : 먼저 Supabase 클라이언트 를 설치해야 한다.

  npm install @supabase/supabase-js

• Supabase 클라이언트 초기화 : 프로젝트의 적절한 파일에 Supabase 클라이언트를 초기화 한다.

  import { createClient } from '@supabase/supabase-js';
  

const supabase = createClient('SUPABASE_URL', 'SUPABASE_ANON_KEY');

- `SUPABASE_URL` 과 `SUPABASE_ANON_KEY`는 대시보드에서 확인한 `API URL`과 `anon` 키를 입력한다.

### 2. 소셜 로그인 기능 구현
- 로그인 함수 : `signInWithOAuth` 메서드로 소셜 로그인을 처리한다.
```js
const signInWithGoogle = async () => {
  const { user, session, error } = await supabase.auth.signInWithOAuth({
    provider: 'google',
  });

  if (error) {
    console.error('로그인 오류:', error.message);
  } else {
    console.log('로그인 성공:', user);
  }
};

3. 로그인 상태 확인 🌟

• 로그인 상태 추적 : 로그인한 사용자의 정보를 추적하려면 supabase.auth.onAuthStateChange 를 사용하여 로그인 상태가 변경될 때마다 처리할 수 있다.
• onAuthStateChange 는 로그인, 로그아웃, 세션 갱신 등의 이벤트를 감지한다. ( useEffect 와 함께 사용하기에 적합하다. )

  import { useEffect, useState } from 'react';
  

const App = () => { const [user, setUser] = useState(null);

useEffect(() => { const { data: authListener } = supabase.auth.onAuthStateChange( (event, session) => { setUser(session?.user ?? null); } );

return () => {
  authListener?.unsubscribe();
};

}, []);

### 4. 로그아웃 기능
```js
const signOut = async () => {
  await supabase.auth.signOut();
  setUser(null);
};

const LogoutButton = () => {
  return <button onClick={signOut}>로그아웃</button>;
};

• signOut 메서드로 현재 세션을 종료할 수 있다.
• 로그아웃 후 상태를 초기화하려면 setUser(null)처럼 상태를 업데이트해야 한다.