오픈소스 현황과 승인 상태를 한눈에
6인 사내 CoP에서 프론트엔드를 단독으로 맡았습니다. 승인 이후 목록에 결과가 나타나지 않는 문제를 쿼리 갱신 정책으로 해결하고, 인증 만료와 일반 오류의 처리 기준을 분리했습니다.
승인 목록만 갱신해서는 변경 결과가 보이지 않았습니다
어떤 서비스에 어떤 오픈소스가 쓰이는지 수작업으로 확인하면, 취약점이 발견돼도 영향 범위를 파악하기 어렵습니다. 사내 학습 모임에서 SBOM을 바탕으로 자산과 취약점, 대응 현황을 조회하는 플랫폼을 개발하고 있습니다.
팀 리더로 개발 범위와 마일스톤을 정하고 프론트엔드 설계와 구현을 맡았습니다. 서버와 인프라는 다른 팀원의 담당 영역입니다. 승인 처리가 끝나도 저장소 목록이 그대로인 문제를 계기로, 승인 유형과 영향을 받는 화면을 함께 정리했습니다.
승인 유형마다 갱신할 쿼리를 한곳에서 관리합니다
모든 승인에서 승인 목록 캐시를 무효화하고, 변경된 업무 데이터도 함께 무효화합니다. 화면별로 갱신 대상을 흩어 두지 않고 approvalInvalidationKeys 함수에 모았습니다.
| 승인 유형 | 승인 목록 외 갱신 대상 |
|---|---|
| 저장소 등록 / 삭제 | repositories |
| SBOM 업로드 | sbom + repositories |
| 취약점 등록 | vulnerabilities |
| 취약점 예외 | response + vulnerabilities |
조회 재시도와 사용자 변경 요청을 구분했습니다
공통 API 클라이언트에서 인증 만료, 권한 오류, 빈 응답과 JSON이 아닌 응답을 구분합니다. 인증이 만료되면 로그인 화면으로 한 번만 이동하도록 전역 처리합니다.
| 상황 | 현재 구현 |
|---|---|
| 인증 만료 조회 | 재시도 없이 로그인 화면으로 이동 |
| 그 밖의 조회 오류 | 최대 1회 재시도 |
| 데이터 변경 요청 | 자동 재시도하지 않음 |
| 창으로 다시 돌아옴 | 자동 재조회하지 않음 / staleTime 5분 |
갱신 대상 누락을 테스트로 고정했습니다
2026.09.20 승인 캐시 갱신 테스트 6개를 실행했습니다. 모든 승인에 공통 캐시가 포함되는지, 각 유형의 업무 캐시가 포함되는지, 중복 키가 없는지 확인했습니다.
SBOM 업로드는 sbom과 repositories를, 취약점 예외는 response와 vulnerabilities를 함께 갱신하도록 테스트했습니다. 승인 유형이 추가될 때 빠지기 쉬운 갱신 대상을 테스트로 확인할 수 있게 했습니다.
취약점 상세와 AI 요약
영향받는 패키지와 대응 현황, AI 요약과 원문 링크를 한 화면에서 확인할 수 있도록 구성했습니다.
지금 팀이 풀고 있는
문제는 무엇인가요?
서비스 출시 부터 운영까지,
제가 기여할 수 있는 일을 함께 하고 싶습니다.