익명 사례 · 진단 제품
도메인 진단 SaaS
외부 웹사이트를 안전하게 수집하고, 측정 불가와 실제 실패를 분리해 설명 가능한 진단·근거·리포트로 전달한 익명 제품 사례입니다.
- 역할
- Product Engineer
- 영역
- B2B diagnostic product
- 시기
- Product implementation
- 공개 자료
- 1개 항목
문제와 제약
높은 평균 점수가 치명적 위험을 가리거나, 수집 실패가 낮은 품질로 오해되면 진단 제품의 신뢰가 무너집니다.
- C1외부 URL은 사설 네트워크 접근과 과도한 요청을 막아야 했습니다.
- C2AI 관측은 출처·버전·오류·비용을 함께 기록해야 재현할 수 있었습니다.
- C3웹과 PDF에서 같은 공개 기준이 적용되어야 했습니다.
내가 맡은 범위
- R1URL 입력부터 수집·분석·점수화·리포트 공개까지의 제품 계약 정리
- R2HTTP 우선 수집과 SPA 징후가 있을 때의 브라우저 전환 구현
- R3측정 불가와 실제 실패의 분리, 핵심 위험 상한 규칙 구현
- R4URL·capture·confidence·redaction 근거와 개선 우선순위의 정책화
핵심 판단
D01
총점보다 치명적 위험을 우선했습니다.
핵심 위험이 확인되면 다른 항목의 높은 점수가 이를 희석하지 않도록 점수 계산에 상한 원칙을 반영했습니다.
D02
측정 실패를 낮은 품질로 단정하지 않았습니다.
타임아웃·차단·외부 오류는 측정 불가로 분리하고, 확인하지 못한 사실을 낮은 점수처럼 보여주지 않았습니다.
D03
웹과 PDF의 공개 계약을 하나로 만들었습니다.
공개 허용 상태가 불명확하면 노출하지 않는 판정 함수를 공유해 우회 노출을 막았습니다.
D04
브라우저 자동화는 필요한 페이지에만 사용했습니다.
먼저 HTTP 응답을 분석하고 SPA 징후나 렌더링 의존성이 있을 때만 브라우저 수집으로 전환해 비용과 실패 지점을 줄였습니다.
D05
점수 옆에 다음 작업을 남겼습니다.
URL·화면 캡처·신뢰도·가림 상태를 근거로 저장하고, 발견 항목을 영향도·수정 비용·담당 기준으로 정리해 보고서가 작업 목록으로 이어지게 했습니다.
구현 구조
- I1Next.js 웹과 FastAPI 비동기 worker
- I2SSRF 방어·요청 제한·HTTP 우선 수집·조건부 브라우저 전환
- I3설명 가능한 scoring과 측정 불가 처리
- I4URL·capture·confidence·redaction evidence record
- I5impact·effort·owner가 있는 Web/PDF 보고서
- N1URL boundary
- N2Async audit
- N3Scoring policy
- N4Evidence record
- N5Web / PDF
내부 구조 원본이 아니라 공개 가능한 구성 요소만 단순화한 그림입니다.
검증과 확인된 결과
코드·문서에서 확인한 구현과 측정된 외부 성과를 별도 상태로 표시합니다. 외부 성과가 없으면 수치로 적지 않습니다.
검증
7개 카테고리 48개 항목의 진단 구조가 저장소 문서와 코드에 존재함을 확인했습니다.
공개 검증점수 계산, 수집 안전성, AI 오류·예산, 화면·PDF 공개 상태를 다루는 테스트 코드의 존재를 확인했습니다. 이번 검토에서는 전체 테스트 실행과 배포 상태를 재검증하지 않았습니다.
맥락 확인
확인된 결과
수집 실패, 규칙 기반 판정, AI 관측과 공개 경계를 하나의 설명 가능한 제품 흐름으로 연결했습니다.
맥락 확인