| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #3 | 라이브 DB, ERD, SQL 문서가 서로 다르고 죽은 회원가입 트리거가 남아 있었음 | DB를 직접 점검해 SQL 정본, RLS, FK, CHECK, DEFAULT, 트리거, Storage를 동기화하고 죽은 트리거 제거 |
| #4 | develop의 최신 DB 문서가 main에 반영되지 않음 | 라이브 DB 기준으로 정리된 SQL 정본을 main에 동기화 |
| #5 | ERD에 workspace 구조가 빠지고 role이 두 곳에 중복됨 | workspaces와 workspace_members를 추가하고 역할을 workspace_members.role로 일원화 |
| #6 | Wiki 버전 생성과 게시 과정의 경계가 불명확함 | 생성·검증·리뷰·게시를 분리하고 Agent·Report 공용 조회 계약 확정 |
| #7 | Wiki 공개 인터페이스만 있고 실제 DB·Storage 쓰기 구현이 부족함 | Wiki command 함수 6개와 Supabase 통합 테스트 구현 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #15 | 분석 결과가 Wiki 지식 자산으로 전환되지 않음 | 이슈·주제 페이지 자동 생성, 계층화, 검증, 승인, 게시, 아카이빙 파이프라인 구축 |
| #16 | Agent citation 누락·허위 ID로 API가 500 오류 발생 | 실제 조회한 근거와 citation을 대조하고 잘못된 근거는 답변 불가 처리 |
| #17 | Wiki가 일일 리포트 실행 때만 갱신됨 | 최근 분석 결과를 사용하는 독립적인 주기적 Wiki 갱신 배치 구현 |
| #19 | 실행마다 issue_key가 바뀌어 같은 사건의 Wiki가 반복 생성됨 | 카테고리와 공유 근거 비율로 기존 이슈를 찾아 새 버전으로 갱신 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #21 | Vercel이 하위 frontend 디렉터리를 자동 빌드하지 못함 | vercel.json으로 빌드·출력 경로 지정 |
| #22 | JWT 방식 불일치, Google News 빈 본문, 네이버 오류 무음 처리 | JWKS 인증, 뉴스 원문 URL 디코딩, 명시적 API 오류 처리 |
| #23 | Wiki 출처 API에 제목·매체명·날짜·신뢰도가 없음 | 관련 테이블을 조인해 출처 메타데이터 제공 |
| #24 | Wiki 화면이 실제 API 대신 목업 데이터 사용 | Wiki 트리와 본문을 실제 백엔드에 연결 |
| #26 | 뉴스 수집·정제 스크립트가 자동 실행되지 않음 | 2시간 주기 GitHub Actions 워크플로우 추가 |
| #27 | Wiki 갱신 주기와 대화 보관 설정이 실제 동작하지 않음 | workspace 설정 DB·API, Wiki 게이트, 대화 삭제 배치 구현 |
| #29 | 백엔드 운영 배포 환경이 없음 | Docker, Oracle VM, GitHub Actions, Cloudflare Tunnel 배포 구축 |
| #30 | 브라우저 API 요청이 CORS preflight에서 차단됨 | FastAPI CORS 미들웨어와 운영·Preview Origin 허용 |
| #31 | 로그인 UI가 실제 Supabase 세션을 만들지 않음 | Google·GitHub OAuth, 세션 동기화, 실제 로그아웃과 프로필 연결 |
| #32 | #31과 동일한 수정이 병렬로 중복 생성됨 | 중복 PR을 닫고 추가 수정만 #31에 합쳐 작업 충돌 방지 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #34 | 게시 문서가 0건이면 화면이 무한 로딩됨 | 게시 문서 없음 상태를 별도로 표시 |
| #35 | 낮은 confidence 문서가 영구 pending으로 남지만 수동 승인 경로가 없음 | 현재 자동화 제품 정책에 맞춰 검증 통과 시 자동 승인·게시 |
| #36 | 70점 기준 때문에 실제 후보가 항상 0건 | 실제 데이터 분포와 MEDIUM 등급 기준에 맞춰 임계값을 40으로 조정 |
| #39 | Wiki 마크다운이 일반 텍스트로 표시됨 | react-markdown 렌더러 적용 |
| #40 | 설정 화면 값이 localStorage에만 저장됨 | Wiki 주기와 대화 보관 설정을 실제 백엔드 API에 연결 |
| #41 | README의 인프라가 실제 배포 구조와 다름 | VM·Docker·Cloudflare·Vercel·Actions 기반 아키텍처 문서화 |
| #42 | 랜딩·인증·온보딩 흐름이 없고 사용자가 바로 앱에 진입함 | 랜딩→인증→선호조사→대시보드와 제한형 게스트 모드 구현 |
| #43 | 리포트 카테고리와 Wiki page type 불일치로 생성 실패 | Wiki 유형을 8종으로 확장하고 프롬프트·검증·DB 제약 동기화 |
| #44 | 새 Wiki 유형이 프론트에서 영문으로 표시됨 | 공급망·생산, 정책·규제, 시장·경영 라벨 추가 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #46 | Wiki 업데이트 알림 토글이 실제 기능이 아님 | Web Push 구독 API, VAPID 발송, 만료 구독 정리 구현 |
| #47 | 푸시 알림 백엔드는 있지만 브라우저 연결이 없음 | Service Worker, 권한 요청, Push 구독, 토글 상태 연결 |
| #48 | 뉴스는 수집되지만 분석 배치가 없어 Wiki에 반영되지 않음 | 분류→신뢰도→중요도→랭킹 자동 분석 워크플로우 구현 |
| #49 | Service Worker 활성화 전에 구독해 오류 발생 | navigator.serviceWorker.ready 이후 구독 |
| #50 | 토글을 켤 때마다 새 구독이 생길 수 있음 | 기존 Push 구독을 조회하고 재사용 |
| #51 | 수집과 분석이 따로 실행돼 최신 데이터를 놓치는 레이스 발생 | 수집→정제→분석을 하나의 설정 기반 워크플로우로 통합 |
| #52 | 데이터 갱신 주기 UI와 저장 피드백이 없음 | 데이터 주기 설정과 저장 성공 토스트 구현 |
| #53 | README가 프로젝트 초기 상태에 머물러 있음 | 실제 구현·배포·로드맵·실행 방법 기준으로 전면 갱신 |
| #54 | 일부 AI 모듈이 팀 확정 모델과 다른 모델을 사용 | DeepSeek V4 Flash로 통일하고 V4 Pro 폴백 추가 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #55 | 연결된 Wiki 문서가 항상 0건 | 공유 원문을 기반으로 관련 Wiki를 동적 계산해 API 제공 |
| #56 | 관련 Wiki API가 화면에 연결되지 않음 | 백엔드 related_pages를 프론트 문서 카드에 연결 |
| #57 | 팀 공유 대화에서 메시지 작성자를 구분할 수 없음 | chat_messages.user_id와 profiles FK 추가 |
| #58 | 팀·개인 Agent 세션 연결 방향이 문서화되지 않음 | 구현 설계와 단계별 계획을 작성해 팀에 공유 |
| #59 | 주제 페이지가 이슈 페이지와 거의 같은 제목으로 생성됨 | 제목 유사도 가드와 주제 범위 프롬프트 추가 |
| #60 | 이미 쌓인 중복 Wiki는 신규 예방 로직으로 해결되지 않음 | LLM 판정·병합·아카이빙·자식 재연결 Dedup 배치 구현 |
| #62 | Dedup 배치가 15분 제한 때문에 중간에 종료됨 | 실제 처리 속도를 기준으로 30분으로 상향 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #73 | Wiki 본문의 [N] 각주를 클릭할 수 없음 |
근거 순서와 원문 URL을 매핑해 링크로 렌더링 |
| #74 | 본문에는 6개 각주가 있지만 실제 근거는 3개인 경우 발생 | LLM 규칙 강화와 범위 밖 각주 코드 제거 |
| #75 | Agent 답변 마크다운이 텍스트로 노출됨 | Agent 답변에 react-markdown 적용 |
| #76 | Agent 본문 각주가 실제 출처 URL과 연결되지 않음 | source_url 전달과 [N] 링크 렌더링 구현 |
| #77 | 수정 전 생성된 Wiki에는 죽은 각주가 남아 있음 | 기존 published 문서를 검사하고 새 버전으로 정리하는 배치 추가 |
| #78 | 메인 대시보드 KPI가 모두 고정 목업 값 | 수집·리포트·Wiki·신뢰도 실데이터 요약 API 구현 |
| #79 | 대시보드 요약 API가 프론트 카드에 연결되지 않음 | 백엔드 응답을 KPI 카드 형태로 변환해 연결 |
| PR | 발견한 문제 | 해결한 내용 |
|---|---|---|
| #119 | Wiki 출처 영역에 내부 UUID가 노출됨 | 제목·매체명·날짜 형식으로 변경하고 운영 문서 23건 백필 |
| #120 | 리포트 출처에도 document_version_id와 wiki_page_id가 노출됨 | 리포트 모델과 렌더러에 사람이 읽을 수 있는 출처 필드 추가 |
| #123 | Agent 답변을 Wiki에 저장하면 원문이 그대로 들어가 문서 형식이 섞임 | 제목·질문·답변 요약·핵심 근거·출처의 구조화된 템플릿 생성 |
| #127 | 수집에 20~24분이 걸려 정제·분석 전에 30분 타임아웃 발생 | 제한을 55분으로 늘리고 동시 실행을 취소하지 않고 대기하도록 설정 |
| #136 | 500건 이상의 문서 ID를 한 번에 조회해 PostgREST 400 오류 발생 | ID를 150개 단위로 청크 처리해 대형 백로그에서도 조회 가능하게 개선 |
myWiki 프로젝트에서 제가 해결한 핵심 과제는 개별 기능을 추가하는 것보다는 서로 끊겨 있던 시스템 전체를 하나의 서비스 흐름으로 연결하는 것 이였다 생각합니다.
초기에는 다음과 같은 문제가 있었습니다.
저는 이 문제들을 사용자 증상, 운영 로그, 실제 데이터베이스 상태, 코드 흐름을 함께 확인하며 해결했습니다.
그 결과 다음의 전체 흐름을 완성했습니다.
뉴스 수집 → 정제 → 분석 → 후보 선정 → Wiki 자동 생성·갱신 → 검증·게시 → 사용자 조회 → Agent 질의응답 → 근거 확인 → 알림
또한 실제 OAuth 로그인, 사용자 설정, 브라우저 푸시 알림, 대시보드 실데이터, 연결된 Wiki 문서, 중복 정리, Docker 배포, Vercel 배포, 운영 데이터 백필과 확장성 개선까지 연결했습니다.
가장 큰 기여는 각각의 기능을 따로 만든 것이 아니라, 데이터가 수집된 뒤 실제 지식 자산으로 축적되고 사용자가 이를 조회하고 활용할 수 있도록 서비스의 전체 흐름을 처음 끝까지 연결한 것이라 생각합니다
https://www.erdcloud.com/d/qgLNBqodLMJAqG9FG