Repository navigation
[11/04][Extension] 저장·임베딩 상태 안내와 새 코드 검색 확인 #29
Description
완료 — 2026-11-05
PR #34이 develop에 병합됐고, 병합된 develop에서 실제 저장·검색·원본 이동과 UI 회귀를 확인했습니다.
- 구현 커밋:
d35d92fc6948b5d765394c7c18d17d216252e2da - 최종 develop:
5dd2edc69ac0e4b5eb944bb473d87b1644bad7da - 병합 커밋과 검증한 구현 커밋의 파일 차이는 없습니다. 로컬 develop의 clean 및 origin/develop 대비 0/0은 사용자가 확인했습니다.
- 아래 실제 실행 결과는 사용자가 Windows 확장 개발 호스트와 Dev Container에서 실행해 공유한 로그·화면 확인을 근거로 기록했습니다.
완료한 항목
- 최신 develop 및 공식 저장·검색 계약 반영.
- 기존 요청 7개 필드·필수 프로젝트명·상대 경로 유지.
- ready / failed / 최종 상태 확인 불가를 구분하고 확인된 저장 ID 보존.
- 모델 warmup·저장 중 안내·제한 시간 설정·시간 초과 안내 적용. POST 자동 재전송 없음.
- 계약에 없는 상태 조회·재처리 API를 추가 호출하지 않음.
- Windows 단위 테스트 26개 통과, TypeScript·ESLint·esbuild 완료.
- mock=false와 실제 Backend 주소로 새 코드 저장 후 같은 ID의 DB 원문·벡터 대조.
- 같은 질문·limit=10의 API·UI 순서·코드·메타데이터·유사도 표시 대조.
- ID 8 결과의 실제 원본 파일 열기 확인. 파일·메타데이터 범위는 safe_divide.py 1~4줄.
- 새 빈 편집기에서 코드 복사·붙여넣기 및 삽입 성공.
- 빈 검색 결과·검색 오류 표시 확인, 실제 API 주소 복원 및 임시 서버 종료.
실제 저장·DB·UI 근거
- 병합 전 id=6: HTTP 200 / ready / error=null, 표시 요청 시간 0.70초. 7개 필드·CRLF·들여쓰기 일치, 768차원, norm 1.000000036425305. 저장 기록은 검색 준비됨.
- 입력 한도 시험 id=7: 600줄 전체 보존, HTTP 200 / failed / embedding_input_invalid, 벡터 NULL, 표시 시간 0.30초. 저장 기록은 검색 준비 실패.
- 병합된 develop에서 새 저장 id=8: HTTP 200 / ready / error=null, 표시 시간 0.76초. 원문·7개 필드 일치, 768차원, norm 출력 1.000000, DB/API comparison: OK.
- 실제 질문: 0으로 나누는 경우를 처리하는 나눗셈 함수. API와 UI 모두 id=6 / safe_divide / 0.825 → id=8 / safe_divide / 0.825 → id=2 / even_numbers / 0.810 → id=1 / add / 0.789 → id=3 / sort_users / 0.761 → id=5 / sort_users / 0.761 순서. 점수는 소수점 3자리 표시값입니다.
- id=6·8은 같은 코드를 각각 저장한 별도 행이며, 새 id=8은 실제 2위입니다. 점수는 코사인 유사도이며 정확도 퍼센트가 아닙니다.
- ID 8의 원본 열기와 코드 복사·삽입을 사용자가 확인했습니다.
빈 결과·오류 시험과 복원
실제 DB를 유지하고 임시 검색 응답 서버(8011)에서 200/results=[] 및 503/detail=Search service unavailable를 반환하도록 설정했습니다. 사용자가 빈 결과와 서버 오류 표시를 확인했습니다.
이는 GET /search UI의 응답 주입 시험이며 실제 DB·모델 장애나 POST 저장 503의 수동 재현으로 기록하지 않습니다.
시험 후 API를 http://127.0.0.1:8000으로 복원해 실제 검색 복구를 확인했고 임시 서버를 종료했습니다.
기록·범위
- 공식 API 계약
- 실행·상태 안내
- 병합 전 정상·입력 한도 검증 기록
- 병합 후 id=8과 UI 회귀 결과는 이 이슈 및 #30에 추가 기록했습니다.
- HTTP 503의 저장된 ID 보존·저장 확인 불가는 단위 테스트로 확인했습니다.
- 요청 시간들은 각 1회 관측값입니다. 저장 제한 시간 기본값 10초는 유지하며 평균·p95·최적 제한 시간으로 일반화하지 않습니다.
- LLM/RAG 답변과 추가 모델 비교는 후속 범위입니다.
실행 전 계획 보존
목표
Backend와 합의한 저장 응답을 반영하고, 새로 저장한 코드가 실제 검색 결과에 나타나는지 확인한다.
- 예정 모임: 2026-11-04(수) KST
- 담당: Extension 담당 /
feature/extension - 기준: 2026-11-03 확인, develop
a44efca - 개발 계획이며 실행·완료 기록은 실제 검증 후 추가한다. PR base는 develop이다.
선행 조건
- [11/04][공통] 자동 임베딩 처리·응답·재처리 규칙 확정 #25: 저장 성공과 검색 준비 상태를 구분하는 계약
- [11/04][Backend] 스니펫 저장 후 E5 자동 임베딩 연결 #27: 실제 자동 임베딩 저장 API 검증
확인·수정할 기존 파일
현재 저장 처리는 응답 숫자 id를 확인하고 성공 메시지를 표시한다. 요청 제한은 10초다. 기존 실제 검색 UI는 재사용한다.
작업
- 최신 develop과 개정 API_CONTRACT.md를 먼저 확인한다.
- 기존 7개 요청 필드, 필수 프로젝트명, 상대 경로 수집을 유지한다.
- 합의한 저장·임베딩 준비 결과만 반영해 안내한다. 준비 전·임베딩 실패를 원문 저장 실패와 혼동하지 않게 한다.
- 10초 제한·모델 첫 준비 시간을 고려해 대기·시간 초과 안내를 조정한다.
- 대기·시간 초과 뒤 POST를 자동 재전송하지 않는다. 기존 저장 여부를 먼저 확인하는 절차를 둔다.
- 현재 계약에 없는 상태 조회·재처리 API를 임의로 호출하지 않는다.
- npm.cmd run compile 후 실제 개발 호스트에서 codeMemory.mock=false와 실제 Backend 주소를 확인한다.
- 새 테스트 코드를 선택해 저장하고 실제 반환 id의 원문·벡터를 DB 담당과 대조한다.
- 같은 자연어 질문의 API·UI 결과 순서·코드·메타데이터·점수 표시를 대조한다.
- 열린 프로젝트의 실제 원본 파일과 줄 범위로 이동한다.
- 기존 복사·삽입·빈 결과·오류 표시를 회귀 확인한다.
완료 조건
- 실제 API 응답에 맞춰 저장 결과와 검색 준비 결과를 안내한다.
- 새 코드의 저장 → 자동 임베딩 → UI 검색 → 원본 이동이 확인된다.
- 실제 빌드·테스트·반환 id·SHA를 기록한다.
삽입 검사는 새 빈 편집기에서 한다. score는 코사인 유사도이며 정확도 퍼센트로 표시하지 않는다. 필요한 상태 표시 범위만 수정하고 새 검색 UI를 처음부터 다시 만들지 않는다.
Activity