소프트웨어 리스크 진단

버그만 찾으면
절반만 본 것이다.

Prober 는 기능 · 정책/법무 · 코드 세 축에서 제품의 문제와 리스크를 찾습니다. 발견에는 근거와 심각도가 붙고, 끝에는 언제나 해결책 제안이 따라옵니다.

무엇을 진단하나리포트 형식 보기

세 개의 축

테스트가 통과해도 약관과 어긋나면 제품은 위험합니다. 약관이 완벽해도 코드에 구멍이 있으면 마찬가지입니다. 한 도구가 세 축을 같은 형식으로 다뤄야 우선순위를 한 번에 매길 수 있습니다.

LENS 01

기능 QA

명세대로 동작하는가?

  • 테스트 케이스 저작 · 회귀 스위트
  • 변경(PR·이슈) 에서 테스트 대상 자동 추출
  • 배포 전 스모크 게이트 — 실제 브라우저 실행
  • 경계값·동등분할 기법 강제로 케이스 누락 차단
LENS 02

정책 · 법무 리스크

약관이 약속한 것과 제품이 실제 하는 일이 같은가?

  • 이용약관 · 개인정보처리방침 vs 실제 동작 대조
  • 수집 항목 · 보유 기간 · 제3자 제공 고지 누락
  • 동의 흐름 — 필수/선택 분리, 사전 체크 여부
  • 다크패턴 · 해지 경로 은닉 점검
LENS 03

코드 · 구조 리스크

무너질 곳은 어디인가?

  • 신뢰 경계 — 입력 검증 · 권한 확인 누락
  • 비밀키 하드코딩 · 로그 유출
  • 에러 처리 누락으로 인한 데이터 손실 경로
  • 성능 함정 · 되돌리기 어려운 구조 부채

결과는 언제나 같은 모양으로

어느 축에서 나온 발견이든 리포트 한 장의 형식은 동일합니다. 축마다 문서가 따로 놀면 결국 아무도 안 읽습니다.

발견
회원 탈퇴 시 결제 이력이 즉시 삭제되지만, 개인정보처리방침은 5년 보관을 고지하고 있음
근거
privacy-policy.md L42 "전자상거래법에 따라 5년 보관" ↔ user.service.ts L118 hardDelete(payments)
심각도
HIGH 법정 보존 의무 위반 + 고지 불일치
해결책
결제 이력은 소프트 삭제 + 익명화로 전환하고 보존 기간 만료 배치를 둔다. 방침 문구를 실제 보존 대상과 일치시킨다.

어떻게 도는가

점검 항목은 md 파일로 남고 git 이 이력을 갖습니다. 별도 DB 없이 코드와 같은 리뷰 흐름을 탑니다.

plan

무엇을 볼지 정한다. 3축 범위 산정 + 기존 커버리지 갭 분석.

author / extract

점검 항목을 저작하거나 변경 diff 에서 자동 추출한다.

run

스모크 게이트를 실제 브라우저에서 돌리고 증거를 남긴다.

report

발견을 근거·심각도와 함께 묶고 해결책을 제안한다.