마주봄 — 기술 안건

[yujinimda]

마주봄 — 기술 안건

---

안건 1. Supabase 클라이언트 라이브러리 사용 여부

배경

Supabase는 두 가지 방식으로 사용할 수 있다.

• A) 라이브러리 사용: @supabase/supabase-js + @supabase/ssr
• B) REST API 직접 호출: Supabase가 제공하는 REST 엔드포인트를 fetch로 호출

A) 라이브러리 사용

장점

• Auth 전체 플로우(회원가입, 로그인, 토큰 갱신, 탈퇴)가 내장되어 있어 인증 관련 코드량이 크게 줄어든다
• @supabase/ssr이 Next.js App Router 환경에서 쿠키 기반 세션을 자동 관리해준다 (서버 컴포넌트, 미들웨어, Route Handler 간 세션 공유)
• RLS 정책이 자동으로 적용된다 — 라이브러리가 요청마다 세션 토큰을 헤더에 포함시키므로 auth.uid()가 작동한다
• pgvector 유사도 검색을 supabase.rpc() 한 줄로 호출할 수 있다
• Realtime 구독이 필요할 경우 WebSocket 연결을 직접 관리하지 않아도 된다

단점

• Supabase에 대한 의존도가 높아진다 — 추후 DB를 다른 서비스로 마이그레이션할 경우 클라이언트 코드 전체를 수정해야 한다
• 라이브러리 내부 동작(토큰 갱신 타이밍, 세션 저장 방식 등)이 추상화되어 있어 디버깅 시 블랙박스가 될 수 있다
• 번들 사이즈가 추가된다 (@supabase/supabase-js ~50KB gzipped)

B) REST API 직접 호출 (fetch)

장점

• Supabase 외 의존성이 없다 — fetch만 사용하므로 다른 DB로 전환 시 API 레이어만 교체하면 된다
• 요청/응답 흐름을 완전히 제어할 수 있어 디버깅이 명확하다
• 번들 사이즈 추가가 없다

단점

• Auth 흐름을 직접 구현해야 한다 (토큰 발급, 갱신, 쿠키 저장, 만료 처리)
• 모든 요청에 apikey, Authorization 헤더를 수동으로 조립해야 한다
• RLS가 동작하려면 유저 토큰을 직접 헤더에 넣어야 하는데, 서버 컴포넌트 / 클라이언트 / 미들웨어별로 토큰 접근 방식이 달라 분기 코드가 많아진다
• pgvector RPC 호출 시 엔드포인트 URL + 파라미터 직렬화를 직접 처리해야 한다

건의

A) 라이브러리 사용을 제안한다.

마주봄는 Auth(회원가입/로그인/탈퇴) + RLS(본인 데이터 접근 제어) + pgvector(벡터 유사도 검색)를 모두 사용하는 구조다. 이 세 가지를 REST API로 직접 구현하면 인증 토큰 관리, RLS 헤더 주입, RPC 호출 조립을 전부 수작업해야 하는데, 이는 마주봄의 핵심 가치(AI 매칭)와 무관한 인프라 작업이다. 라이브러리를 사용하면 이 부분을 위임하고 도메인 로직에 집중할 수 있다.

---

안건 2. 차트 라이브러리 선정

배경

검사 결과 화면에서 레이더 차트(5축: 반복 작업 선호 / 대인관계 / 신체 활동 / 세밀한 손작업 / 환경 민감도)를 표시해야 한다. 현재 사용하는 차트는 이 레이더 차트 1개뿐이다.

후보 비교

기준	Recharts	Chart.js (react-chartjs-2)	D3.js
React 통합	React 컴포넌트 네이티브	래퍼 라이브러리 필요	DOM 직접 조작, React와 충돌 가능
레이더 차트	<RadarChart> 내장	<Radar> 내장	직접 구현
번들 사이즈 (gzip)	~14KB (트리쉐이킹)	~60KB (전체 로드)	~30KB
선언적 작성	<Radar dataKey="value" /> JSX	config 객체 기반	명령형 코드
반응형	<ResponsiveContainer> 내장	canvas 기반, 별도 처리 필요	직접 구현
접근성	SVG 기반 → 시맨틱 마크업 가능	canvas 기반 → 접근성 제한	SVG 기반
커스터마이징	중간 (props 기반)	중간 (config 기반)	무제한

건의

Recharts를 제안한다. 이유는 3가지:

1. SVG 기반이라 접근성에 유리하다. 마주봄의 타겟이 장애인 보호자인 만큼 스크린 리더 호환이 중요한데, Chart.js는 canvas 렌더링이라 접근성 대응이 어렵다. Recharts는 SVG로 렌더링되어 시맨틱 마크업과 aria-label 적용이 가능하다.
2. React 컴포넌트 방식이라 코드 일관성이 유지된다. Chart.js는 config 객체를 넘기는 방식이고, D3는 명령형이다. Recharts는 JSX 선언형이라 나머지 코드베이스와 동일한 패턴으로 작성할 수 있다.
3. 트리쉐이킹으로 번들 최적화가 된다. 레이더 차트 관련 컴포넌트만 import하면 ~14KB 수준이다. Chart.js는 전체 모듈을 로드해야 해서 레이더 차트 하나를 위해 ~60KB를 추가해야 한다.

사용 예시

import {
  RadarChart, PolarGrid, PolarAngleAxis, Radar, ResponsiveContainer
} from 'recharts';
 
const data = [
  { axis: '반복 작업', value: 90 },
  { axis: '대인관계', value: 30 },
  { axis: '신체 활동', value: 50 },
  { axis: '손작업', value: 85 },
  { axis: '환경 민감도', value: 70 },
];
 
<ResponsiveContainer width="100%" height={280}>
  <RadarChart data={data}>
    <PolarGrid />
    <PolarAngleAxis dataKey="axis" />
    <Radar dataKey="value" fill="#4166E7" fillOpacity={0.2} stroke="#4166E7" />
  </RadarChart>
</ResponsiveContainer>

---

안건 3. AI 파이프라인 구현 방식

배경

AI 호출이 발생하는 시점이 3가지 있다.

시점	내용	특성
검사 완료	자녀 프로필 → 벡터화 → 직종 매칭 → AI 설명 생성	유저가 결과를 기다리는 중 (실시간)
공고 분석	채용공고 텍스트 → AI가 환경 요소 추출 → 프로필과 매칭	유저가 결과를 기다리는 중 (실시간)
공공데이터 수집	워크넷/장애인고용공단 API → DB 적재	유저와 무관 (주기적 배치)

후보 비교

기준	Next.js Route Handler	GitHub Actions	n8n
실시간 응답	✅ 유저 요청 → 즉시 응답	❌ 트리거 지연 있음	❌ 외부 서비스 경유
주기적 배치	❌ 서버리스라 cron 불가	✅ cron 스케줄 내장	✅ cron 내장
인프라 관리	없음 (Vercel 배포)	없음 (GitHub 내장)	셀프호스팅 or 유료 클라우드
비용	Vercel 무료 범위 내	무료 (월 2,000분)	셀프호스팅 시 서버 비용
복잡한 파이프라인	단순 요청-응답만 적합	단순 스크립트 적합	멀티스텝 워크플로우에 강점

건의

실시간은 Route Handler, 배치는 GitHub Actions로 분리한다. n8n은 사용하지 않는다.

시점	구현 방식	이유
검사 완료 → 매칭	Next.js Route Handler	유저가 대기 중이므로 외부 서비스를 경유하면 지연만 추가된다
공고 적합도 분석	Next.js Route Handler	동일. 분석 결과는 posting_analysis_cache에 저장하여 동일 공고 재분석을 방지한다
공공데이터 배치 수집	GitHub Actions (cron)	유저와 무관한 주기적 작업. 별도 인프라 없이 스케줄 실행 가능

n8n을 제외하는 이유: n8n은 "이벤트 → 여러 단계를 거쳐 → 최종 결과" 같은 복잡한 파이프라인에 강점이 있다. 마주봄의 AI 호출은 "입력 → AI API 호출 → 결과 저장" 일직선 구조라 Route Handler 하나로 충분하며, n8n을 추가하면 셀프호스팅 관리 비용만 늘어난다.

매칭 플로우 상세

비용과 속도를 위해 2단계로 나눈다.

[1단계 — DB 레벨 필터링 (빠르고 무료)]
pgvector 코사인 유사도로 상위 N개 후보 추출
 
          ↓
 
[2단계 — AI 정밀 분석 (후보만 대상)]
후보 N개에 대해 적합도 라벨 + 설명 생성
→ match_results 테이블에 캐싱

공고 1,000개를 전부 AI에 넘기면 비용 + 응답 시간이 비현실적이므로 pgvector로 먼저 50개 수준으로 좁힌 후 AI 분석을 수행한다.

응답 시간 전략

MVP — 동기 처리

유저 제출 → 로딩 화면 ("AI가 분석 중이에요...") → 완료 → 대시보드 이동

Route Handler에서 AI 호출 후 응답을 기다린다. 예상 소요 시간 10~30초.

2차 — 비동기 처리 (유저 증가 시)

유저 제출 → 즉시 대시보드 이동 ("분석 중" 상태 표시)
          → 백그라운드에서 AI 처리
          → 완료 시 Supabase Realtime으로 UI 갱신

Supabase Edge Function 또는 Vercel Background Function 활용. MVP에서는 불필요하며 유저 규모에 따라 전환한다.

[yujinimda]

1. Supabase 클라이언트 라이브러리 사용 여부: REST API 직접 호출, 라이브러리를 사용하면 룰을 적을게 너무 없을꺼같아서 api관련은 우리가 정할수있는게 너무 없다 공부적인 차원 + 수퍼베이스 의존도가 너무 높아진다

2. 차트 라이브러리 선정: Recharts, 사용법이 쉽다(https://coding-daily.tistory.com/394)

3. AI 파이프라인 구현 방식: 실시간은 Route Handler, 배치는 GitHub Actions로 분리한다. 위 의견이 좋다

[aahreum]

1. Supabase 클라이언트 라이브러리 사용 여부

저는 라이브러리 사용하는 방향이 좋을 것 같아요!
DB나 pgvector RPC 같은 기능들도 supabase 종속기능이라 라이브러리를 사용하지 않는다고 해도 의존도는 크게 다르지 않을까 싶습니다
인증/세션/헤더 관련된 부분은 라이브러리 사용하고 api route 안에서 supbase를 호출하면 api 관련 로직(아니면 서버액션)도 저희가 다룰 수 있지 않을까요..??!

2. 차트 라이브러리 선정

차트 라이브러리 Recharts 좋은 것 같아요! 사실 저는 3개다 접해보지 못해서 다 배워야하는건 마찬가지인데 Recharts가 JSX 방식이라 좀 더 금방 익숙해질 것 같아서요

그런데 혹시 차트 데이터를 아까 html 자체를 저장한다고 말씀하셨던 것 같은데 제가 이해한게 맞을까요...?? (A안 방식...??)

3. AI 파이프라인 구현 방식

저도 작성해주신 방식대로 하는게 좋은 것 같아요!

공공데이터 api 사용해서 주기적으로 계속 가져오고 DB에 있는걸 조회해서 맞춤형 공고를 찾아주는 방식인건가요...??
그러면 공고 스키마 설계도 필요할 것 같아요..!

[yujinimda]

아 제가 html로 한방식은 ECharts에요~! 저도 Recharts는 처음 써보긴합니다!
ECharts는 컨버스 기반이라 접근성이 불리해서 ai가 Recharts로 추천했나봐용!

처음은 실시간 배정하고 너무 api응답이 느리면 db저장을 해서 시간을 비교해볼까요?

[aahreum]

아하 설명감사합니다!!!
오 좋아요! 실시간으로 한번 보고 느리면 저장해도 좋을 것 같아요

[chldntjr1321]

Supabase 클라이언트 라이브러리 사용 여부

• 라이브러리에 너무 의존을 안하고 싶긴한데, 아름님 코멘트 읽어보니까 이미 Supabase에 의존하는 기능들을 사용하고 있는 것도 사실인 것 같아서 절충안으로 api route 안에서 호출하는 것으로 해도 괜찮을 것 같아요!

차트 라이브러리 선정

• 저도 Recharts에 한표 넣겠습니다. Recharts가 트리쉐이킹 덕분에 용량을 작게 가져갈 수 있는 부분도 괜찮은 것 같아요.

AI 파이프라인 구현 방식

• Route Handler + GitHub Actions 방식 괜찮은 것 같아요!
• GitHub Actions로 DB에 주기적으로 데이터를 업데이트를 하는 방식이잖아요??
  혹시 그러면 북마크를 해둔 공고가 공고 마감일이 지나지 않았는데 기업 측에서 사람을 뽑아서 공고를 닫았는데 업데이트 시간이 아직인 경우에는 데이터 불일치? 문제가 생길 수도 있을 것 같은데, 이건 안고가야하는 거겠...죠?