vault backup: 2026-05-05 22:50:02

포트폴리오/포트폴리오.md

@@ -63,7 +63,7 @@ Spring Boot와 .NET 기반으로 인증/인가, 비동기 작업 파이프라인
 
 ### 담당 역할
 
-**1인 백엔드 + 인프라 + 설계 담당.** 프론트엔드를 제외한 전 영역.
+**백엔드 + 인프라 + 설계 담당.**
 
 - 백엔드 API: 인증·인가, Space 관리, 파일/폴더 CRUD, 업로드/다운로드 파이프라인, Quota, 공유 링크
 - 데이터베이스 설계: 12개 엔티티 ERD, EF Core Configuration, Migration 자동화
@@ -71,7 +71,7 @@ Spring Boot와 .NET 기반으로 인증/인가, 비동기 작업 파이프라인
 - CI/CD: GitLab CI 파이프라인 (test → build → image push to GHCR)
 - 설계 문서화: API/ERD/Conventions/ADR 등 살아있는 문서 체계 구축
 
-### 아키텍처
+### 아키텍처 / 설계 방향
 
 **모듈러 모놀리스 + Clean Architecture.** MVP 단계에서 마이크로서비스의 운영 복잡도를 피하면서도, 코드 레벨에서 도메인 경계를 엄격히 분리해 추후 분리 가능성을 확보했습니다. 의존성 방향은 `Api → Core ← Infrastructure`로, 도메인이 HTTP나 DB, 파일시스템을 알지 못하게 했습니다.
 
@@ -130,7 +130,7 @@ Redis에 `HMAC-SHA-256(token, secret)` 해시만 저장하여 원문을 노출
 
 Google Drive처럼 자동 rename(`파일명(1).pdf`) 대신 `FILE_NAME_CONFLICT` 에러를 반환하도록 설계했습니다. 활성 FileItem과 활성 FileReservation을 함께 검사하고, DB UNIQUE 제약(`(space_id, folder_id, normalized_name) on active rows`)으로 이중 보장합니다. "모호함보다 명시적 실패가 낫다"는 설계 철학을 반영한 결정이었습니다.
 
-### 인프라 구성
+#### 6) 인프라 구성
 
 | 서비스 | 외부 노출 | 역할 |
 |--------|-----------|------|
@@ -172,19 +172,25 @@ Google Drive처럼 자동 rename(`파일명(1).pdf`) 대신 `FILE_NAME_CONFLICT`
 
 ## 2. Didit — GitHub 통합 팀 협업 플랫폼
 
+> **GitHub 저장소 기반 개발 워크플로우**를 OAuth2 인증, 화상회의, AI 이슈 분석, SSE 실시간 이벤트로 연결한 팀 협업 플랫폼입니다.
+
 ### 프로젝트 개요
 
 GitHub 저장소를 사용하는 개발 팀은 이슈 우선순위를 수동으로 판단하고, 화상회의·채팅·이슈 트래킹이 각각 다른 도구에 흩어져 있어 워크플로우 단절이 반복적으로 발생했습니다. 이를 해결하기 위해 **GitHub OAuth2 기반 인증, OpenVidu WebRTC 화상회의, AI 이슈 분석, SSE 실시간 이벤트**를 하나의 Spring Boot 서버로 통합한 팀 협업 플랫폼을 설계하고 구현했습니다.
 
 ### 담당 역할
 
-백엔드 개발자로 참여하여 다음을 담당했습니다.
+**백엔드 + 인프라 + AI 비동기 파이프라인 담당.**
 
-- Spring Boot 4.0 기반 REST API 전체 설계 및 구현 (30개+ 엔드포인트)
+- 백엔드 API: Spring Boot 4.0 기반 REST API 전체 설계 및 구현 (30개+ 엔드포인트)
-- Redis 기반 AI 비동기 작업 큐 및 Pub/Sub 메시징 아키텍처 설계
+- 비동기 파이프라인: Redis 기반 AI 작업 큐 및 Pub/Sub 메시징 아키텍처 설계
-- SSE(Server-Sent Events) 실시간 이벤트 시스템 구현
+- 실시간 시스템: SSE(Server-Sent Events) 이벤트 허브 구현
-- Flyway 기반 데이터베이스 스키마 설계 및 마이그레이션 관리
+- 데이터베이스 설계: Flyway 기반 스키마 설계 및 마이그레이션 관리
-- Docker Compose 인프라 구성 및 GitLab CI/CD 파이프라인 구축
+- 인프라 구성: Docker Compose 구성 및 GitLab CI/CD 파이프라인 구축
+
+### 아키텍처 / 설계 방향
+
+**Spring Boot 기반 모듈러 서버 + Redis 비동기 파이프라인.** GitHub API 연동, AI 분석 요청, 실시간 이벤트 전달을 하나의 백엔드에서 처리하되, 장시간 ML 추론은 Redis List/Pub/Sub으로 분리했습니다. 서비스 계층은 `Result<T>` 패턴을 적용해 성공/실패 흐름을 값으로 통일하고, Flyway + JPA validate로 DB 스키마 정합성을 이중 확인했습니다.
 
 ### 주요 기여
 
@@ -252,15 +258,25 @@ GitHub이 이슈의 Source of Truth이지만 AI 우선순위·담당자 매핑
 
 ## 3. 술통여지도 (Sulmap) — AI 기반 술집 추천 플랫폼
 
+> **위치·날씨·시간·사용자 맥락**을 바탕으로 GPT 추천 엔진이 술집 Top 10과 추천 이유를 생성하는 지도형 풀스택 웹 애플리케이션입니다.
+
 ### 프로젝트 개요
 
 한국의 다회차 음주 문화(1차·2차·3차)에서 다음 장소 선정의 어려움을 해결하기 위해, GPT-5.2 기반 개인화 추천 엔진을 갖춘 지도형 풀스택 웹 애플리케이션을 구현했습니다. 사용자의 위치, 날씨, 시간대, 성별, 나이, 그룹 성격 등 컨텍스트 데이터를 종합하여 200개 후보 중 최적의 술집 Top 10을 자연어 이유와 함께 제공합니다.
 
 ### 담당 역할
 
-- 백엔드: Spring Boot 3계층 Clean Architecture 설계, MyBatis 기반 DB 모델링, GPT API 연동 파이프라인 구현
+**백엔드 + AI 추천 엔진 + 데이터 파이프라인 담당.**
+
+- 백엔드 API: Spring Boot 3계층 Clean Architecture 설계, MyBatis 기반 DB 모델링
+- AI 연동: GPT API 추천 파이프라인, Structured Output, Defensive Normalization 구현
+- 검색/추천: Elasticsearch 위치 기반 검색, 2단계 Cascade Ranking 설계
 - 데이터 파이프라인: .NET 9 기반 Qdrant + OpenAI Embedding 활용 공공데이터 ETL 자동화
 
+### 아키텍처 / 설계 방향
+
+**Spring Boot 3계층 구조 + AI 추천 파이프라인.** API/Service/Repository 계층을 분리하고, 추천 요청은 위치 기반 후보 검색 후 GPT 2단계 랭킹으로 정제했습니다. 외부 AI 응답은 신뢰하지 않고 허용 ID 검증, 중복 제거, Reason 정제, 폴백 추천을 거치도록 설계해 AI 장애와 hallucination을 방어했습니다.
+
 ### 주요 기여
 
 #### 1) 2단계 Cascade Ranking 추천 엔진 설계
@@ -330,14 +346,24 @@ GPT API 호출이 네트워크 이슈, 타임아웃, Rate Limit 등으로 실패
 
 ## 4. TusBlazorClient — Blazor WASM용 tus 프로토콜 클라이언트 라이브러리
 
+> **tus-js-client를 C# API로 감싼 Blazor WASM 라이브러리**로, JavaScript를 직접 다루지 않고 재개 가능한 대용량 업로드를 사용할 수 있게 합니다.
+
 ### 프로젝트 개요
 
 Blazor WebAssembly에서 순수 C# 코드로 대용량 파일을 전송할 경우, 브라우저 메모리 제약과 느린 I/O로 인해 전송 실패 또는 멈춤 현상이 발생하고, 네트워크 중단 시 처음부터 다시 업로드해야 하는 문제가 있었습니다. JavaScript의 `tus-js-client`를 C# API로 감싸, Blazor 개발자가 JavaScript를 직접 다루지 않고도 재개 가능한 대용량 파일 업로드를 사용할 수 있도록 설계하고 구현했습니다.
 
 ### 담당 역할
 
-- 라이브러리 전체 설계 및 구현 (1인 개발)
+**라이브러리 설계 + JS Interop 브릿지 + NuGet 배포 담당.**
-- Public API 설계, JS Interop 브릿지 구현, DI 통합 구성, NuGet 배포
+
+- Public API 설계: `TusClient`, `TusUpload`, `TusOptions` 중심의 C# 업로드 API 구성
+- JS Interop: tus-js-client 이벤트 콜백을 .NET 델리게이트로 전달하는 브릿지 구현
+- DI 통합: Blazor WASM에서 `AddTusBlazorClient()` 한 줄로 등록 가능한 구조 설계
+- 배포: NuGet 패키지 배포 가능한 라이브러리 형태로 구성
+
+### 아키텍처 / 설계 방향
+
+**C# Facade + JS Interop Adapter.** tus 프로토콜 구현은 검증된 `tus-js-client`에 맡기고, Blazor 사용자는 C# 타입과 DI를 통해 업로드 생명주기를 제어하도록 추상화했습니다. JS 모듈은 Lazy 초기화하고, 업로드 인스턴스 생성 경로를 `TusClient.Upload()`로 제한해 콜백 브릿지 누락을 방지했습니다.
 
 ### 주요 기여
 
@@ -376,6 +402,13 @@ DI 등록 한 줄과 직관적인 C# 코드만으로 업로드를 처리할 수
 | tus-js-client | tus 프로토콜의 검증된 JS 구현체로, 재개 가능한 업로드 로직을 직접 구현하지 않고 안정적으로 활용 |
 | IJSRuntime / JS Interop | Blazor WASM에서 JS 라이브러리를 C#으로 연결하는 공식 메커니즘 |
 
+### 프로젝트 성과
+
+- Blazor WASM에서 C# API만으로 tus 기반 재개 가능 업로드를 사용할 수 있는 라이브러리 구현
+- `AddTusBlazorClient()` 기반 DI 통합과 NuGet 배포 가능한 패키지 구조 구성
+- JS 이벤트 콜백을 .NET 델리게이트로 전달하는 Interop 브릿지 구현
+- `TusUpload` 생성 경로 제한으로 콜백 연결 누락 가능성 제거
+
 ### 회고
 
 - **인터페이스 미분리에 대한 판단**: 라이브러리 규모가 작고 Selenium E2E 테스트로 커버하고 있어 인터페이스 분리의 실질적 이득이 크지 않다고 판단했습니다. 외부 사용자가 테스트 대역을 구성해야 하는 상황이 생기면 인터페이스 추출이 필요할 것입니다.