개발 운영과 이력서/JD 큐레이션을 재현 가능하게 만든 Git 기반 개인 하네스 — 로컬 BGE-M3 RAG, MCP 검색, Git 훅 품질 게이트, JD-custom PDF 생성, 직행/Zighang 외부 피드백 루프와 안전한 T1/T2/T3 반영 체계를 통합

문제 해결 과정

기술 선택 근거

• •클라우드 벡터 DB 대신 로컬 BGE-M3 + sqlite-vec 선택: 마크다운 변경 직후 자동 재색인과 비용 통제를 우선
• •문서 규칙 대신 hook-first 강제 선택: 에이전트가 필요 시점에 문서를 읽지 않는 문제를 런타임 차단으로 보완
• •런타임별 수동 설정 대신 runtime surface compiler 선택: 생성물 드리프트를 줄이고 3개 하네스 정합성 검증을 자동화
• •검색 opt-in 대신 default-on 선택: 조사·리뷰·편집 같은 실제 프롬프트에서 근거 검색 누락을 줄이기 위해 UserPromptSubmit에 연결

주요 내용

• •런타임 서피스 자동 생성 + XML runtime contract로 3개 하네스 정합성 확보
• •로컬 BGE-M3 RAG로 548 파일·3,347 청크 색인, warm 쿼리 0.7초 달성
• •RAG default-on 전환으로 프롬프트 12자 이상 search_harness 자동 호출, 3개 하네스 15/15 테스트 통과
• •resume/portfolio JSON을 RAG 코퍼스로 통합, 109 청크 색인 + 32개 테스트 통과
• •브라우저·REPL 런타임 신뢰 경계와 fallback 순서 문서화, 3개 하네스 설정 반영
• •work-data schema v1.2와 outcome_metrics 기반 증거 큐레이션으로 279개 작업 항목 증분 수집·메트릭 보유율 44%→50% 개선
• •JD-custom PDF + 직행/Zighang 피드백 루프 구축, 쥬비스 92%→88% 통과권·넥슨 35% low-fit 분류로 과최적화 방지
• •직행/Zighang recruitment-roast 헬퍼를 main-scope 결과 저장·Puppeteer 실제 click·upload-form guard로 보강해 sidebar 과거 결과 오탐 방지

깨달은 점

• •AI 지원 개발 생산성은 프롬프트 품질만으로 유지되지 않고, 런타임 컨텍스트·규칙 강제·증거 검색·비용 관측성을 같은 운영 경로로 묶어야 재현 가능하다는 점을 체득
• •문서 규칙은 필요 시점에 읽히지 않으면 정책이 아니라 참고 자료에 머물기 때문에, 중요한 규칙은 훅·테스트·컴파일러 출력으로 강제해야 한다는 기준 정립

1만 동시 요청 환경에서 좌석 선점·결제·포인트 충전의 동시성 문제를 시나리오별 하이브리드 락 전략으로 해결한 콘서트 좌석 예약 서비스 — 낙관적 락 + Redisson 분산 락, Redis 캐싱 TPS 15배 향상, Kafka 이벤트 드리븐 아키텍처, K6 부하 테스트 기반 병목 개선

문제 해결 과정

기술 선택 근거

• •좌석 선점에 @Version 낙관적 락: 단일 좌석 경합에서 비관적 락 대비 처리량 우위, K6 1만 VU 검증
• •결제·충전에 Redisson 분산 락(userWalletLock:{userId}): 잔액 정합성 필수 트랜잭션에서 재시도 기반 낙관적 락의 무한 루프 위험 회피
• •Redis Sorted Set 대기열: 스코어=Unix timestamp로 입장 순서+만료 시간 이중 활용, DB 대기열 대비 O(log N)
• •Transactional Outbox 패턴: 결제 TX 내 outbox_event 행 삽입 → 스케줄러가 Kafka 발행, 메시지 유실 방지

주요 내용

• •낙관적 락으로 좌석 예약 응답 시간 50% 개선 (1,678ms → 835ms)
• •시나리오별 하이브리드 락 전략 설계 (낙관적 락 + Redisson 분산 락)
• •Redis 캐싱으로 TPS 15배 향상 (100 → 1,500), DB 쿼리 94% 감소
• •Kafka 이벤트 드리븐 아키텍처로 도메인 간 결합도 제거
• •K6 부하 테스트 기반 성능 병목 식별 및 개선

깨달은 점

• •비관적/낙관적/분산 락의 트레이드오프를 비교하며 동시성 제어의 본질적 차이를 이해
• •시나리오별 하이브리드 락 전략 설계로 단일 솔루션이 아닌 맥락 기반 선택의 중요성 학습

가족·조직 단위 공유 가계부 앱 — Next.js 16 풀스택, Supabase PostgreSQL, 3단계 역할 기반 접근 제어(OWNER/ADMIN/MEMBER), NestJS Cron 정기거래 자동 처리, 99.45% 라인 커버리지 단위 테스트 + 300건 이상 E2E 통합 테스트

문제 해결 과정

기술 선택 근거

• •NestJS Docker 분리: Vercel Hobby 플랜 Cron 제한(1일 1회) 우회, 정기거래 매일 15:00 KST 실행 보장을 위해 Mac mini에서 독립 운영
• •Supabase Auth + 앱 레벨 RBAC 이중화: SupabaseAuthGuard(JWT 검증) → MembershipGuard(역할 확인) → SuperAdminGuard(관리자 전용) 3단계 Guard 체인
• •Prisma + Supabase PG: Prisma의 타입 안전성과 마이그레이션 도구 활용, Supabase 커넥션 풀러 경유로 서버리스 환경 커넥션 관리

주요 내용

• •Vitest 397건 단위 테스트, 라인 커버리지 99.45% 달성
• •Playwright 300건+ E2E 테스트, 역할별 시나리오 분리
• •OWNER/ADMIN/MEMBER 3단계 RBAC + Supabase RLS 적용
• •NestJS Cron 정기거래 자동 처리 (Docker 배포)
• •풀스택 통합 테스트 환경 구축 (FE+BE+Supabase)

깨달은 점

• •Next.js 16 App Router와 Supabase Auth를 조합하여 SSR 환경에서의 인증 상태 관리와 Row Level Security 기반 데이터 접근 제어를 구현하며, 서버·클라이언트 컴포넌트 간 인증 컨텍스트 전파 패턴을 학습
• •OWNER/ADMIN/MEMBER 3단계 역할 체계를 설계하며 조직 단위 멀티테넌시에서의 권한 분리와 데이터 격리 전략을 경험

대신물류 배차현황 데이터를 Cheerio로 크롤링하고 카카오톡 챗봇 스킬서버와 Next.js 모바일웹으로 조회할 수 있는 서비스 — Clean Architecture + TSyringe DI, Express 5, Prisma SQLite, Traefik Blue-Green 무중단 배포

문제 해결 과정

기술 선택 근거

• •Clean Architecture + TSyringe DI: 크롤러·카카오 API·DB 등 외부 의존성 교체 가능성을 고려한 계층 분리, DI 토큰으로 인터페이스 바인딩
• •SQLite 선택: 단일 서버·읽기 위주 워크로드에서 PostgreSQL 대비 운영 오버헤드 제거, 파일 기반 볼륨 마운트로 Docker 이식성 확보
• •Traefik 파일 프로바이더: Docker 소켓 노출 없이 YAML 재작성으로 트래픽 전환, 보안성과 롤백 단순화 동시 달성

주요 내용

• •Clean Architecture + TSyringe DI로 계층 분리 설계
• •Cheerio 크롤링 + node-cron 자동 동기화 (월~토 매시)
• •카카오톡 챗봇 스킬서버 연동 (노선·차량·도착지 검색)
• •Traefik Blue-Green 무중단 배포 + 자동 배포 스크립트
• •Next.js 모바일웹 + Recharts 통계 대시보드

깨달은 점

• •Clean Architecture의 도메인·애플리케이션·인프라 계층 분리와 TSyringe DI 컨테이너를 적용하며, 비즈니스 로직과 외부 의존성(크롤러, DB, 카카오 API)의 결합도를 제거하는 설계를 학습
• •카카오 i 오픈빌더 스킬서버 프로토콜을 직접 구현하며 챗봇 플랫폼의 요청·응답 규격과 시나리오 블록 연동 방식을 이해