DAMOA — 인테리어·건설 견적 매칭 플랫폼

프로젝트 배경

인테리어·건설 시공 견적을 요청·매칭·상담·거래·리뷰로 연결하는 플랫폼입니다. 일반 사용자·파트너 기업·운영자 세 주체가 각기 다른 권한과 목적을 갖고 접근하는 구조라, 인증/인가·상태 전이·상담·SEO·관리자 운영 기능이 핵심 과제였습니다.

담당 범위

• 사용자·파트너 라우트, 견적 요청 검색, 파트너 대시보드, 회사 인증, 파트너 프로필 관리, 채팅, 마이페이지 등 주요 화면 구현
• 운영자 백오피스 — 문의·FAQ·공지·CMS 카테고리·지역·고객/기업 사용자 관리·채팅 구현
• JWT 세션 역할 기반 라우트 그룹별 접근 제어 + 소셜/이메일/토큰 로그인 흐름을 동일 세션 규격으로 통합
• Next.js 미들웨어 취약점 대응, 프록시 뒤 호스트 인식/리다이렉트 문제 해결, 검색 유입을 고려한 SEO 구조 정리

문제 정의

• 3주체 · 다중 로그인 경로 — 같은 견적 데이터를 사용자·파트너·운영자가 서로 다른 권한으로 다뤄야 했고, 로그인 경로도 소셜·이메일·토큰으로 여럿이었습니다. 인가 기준이 경로마다 갈라지면 접근 제어에 구멍이 생깁니다.
• 인프라 없는 실시간성 — 상담 채팅은 즉시성이 필요했지만 WebSocket 인프라가 없었습니다. 그렇다고 짧은 주기로 전체를 폴링하면 서버 부하가 감당되지 않습니다.
• 유입·보안이 곧 서비스 품질 — 검색 유입이 중요한 서비스라 SEO가 매출과 직결됐고, 동시에 Next.js 미들웨어 취약점과 프록시 뒤 호스트 인식·리다이렉트 문제가 기능 정상 동작을 위협했습니다.

기술적 의사결정

1. 역할을 라우트 그룹 단위 인가로 통합

• 배경 — 로그인 경로가 여러 개여도 접근 제어 기준은 하나여야 합니다.
• 선택 — JWT 세션의 역할 정보를 기준으로 사용자·파트너·운영자 라우트 그룹의 접근을 제어하고, 소셜·이메일·토큰 로그인을 동일한 세션 규격으로 통합했습니다. 로그인 경로가 여러 개여도 인가 기준은 하나로 유지했습니다.
• 트레이드오프 — 화면(액션)마다 개별 권한을 다는 방식은 세밀하지만 규칙이 흩어집니다. 라우트 그룹 단위로 큰 경계를 먼저 세워 인가의 단일 기준을 확보하는 쪽을 우선했습니다.

2. 상담 채팅을 폴링 차등 갱신으로 해결

• 배경 — WebSocket 없이 즉시성을 확보하되 서버 부하를 억제해야 했습니다.
• 선택 — 폴링으로 즉시성을 확보하되, 변경이 감지될 때만 전체 데이터를 갱신하는 차등 갱신으로 불필요한 렌더·요청을 줄였습니다.
• 트레이드오프 — 폴링은 WebSocket만큼의 실시간성은 아니지만, 상담 채팅의 체감 즉시성에는 충분했습니다. 인프라 도입 비용 대신 폴링 주기·차등 갱신으로 실시간성과 부하의 균형을 조정했습니다.

3. SEO·미들웨어 보안을 서비스 구조에 반영

• 배경 — 검색 유입과 프록시 환경 대응이 기능만큼 서비스 성패를 좌우했습니다.
• 선택 — 검색 유입을 고려한 SEO 구조를 정리하고, Next.js 미들웨어 취약점과 프록시 뒤 호스트 인식·리다이렉트 문제를 함께 대응해, 기능뿐 아니라 유입·보안까지 정상 동작하도록 다뤘습니다.

결과

• 3주체 역할 기반 인증/인가를 라우트 그룹 접근 제어로 통합, 다중 로그인 경로를 단일 세션 규격으로 수렴
• WebSocket 없이 폴링 차등 갱신으로 상담 채팅 즉시성 확보·요청량 절감
• 파트너 견적·프로필 관리와 운영자 CMS 백오피스 구현
• 미들웨어 취약점·프록시 호스트 인식·리다이렉트·SEO 구조 대응