IoTcube / HatBOM

01

입력부터 결과 조회까지 연결

구현·유지보수

DEBUN, BOLT, Unified SBOM, VEXCO 등 약 10종의 도구를 업로드–분석–결과 조회 흐름으로 통합했습니다. 각 도구의 실행 조건과 입출력을 분석하고, 파일 언어·형식에 맞춰 실행 도구를 선택하는 로직을 개발했습니다.

ZIP·TAR 입력과 분석 결과를 처리하고, VEX 통계 저장 모델·Top CVE·기간별 추세·CVSS 조회 API와 화면을 구현했습니다.

02

기존 Kafka 파이프라인 유지보수

운영·유지보수

Spring Boot Producer·Result Listener와 Python Consumer로 구성된 기존 Kafka 비동기 분석 파이프라인을 유지보수했습니다. BinBOM 2.0을 기존 요청·결과 처리 흐름에 마이그레이션하고, 파일·아카이브 호환성과 분석 결과를 검증했습니다.

03

데이터와 분석 결과 검증

구현·검증

약 1,500만 건의 C/C++ OSS 해시 데이터 기반 분석·조회 기능을 유지보수하고, DB 마이그레이션 전후 결과를 비교했습니다. 이 수치는 다룬 데이터 규모입니다.

Maven·Gradle 의존성을 CycloneDX SBOM에 보강해 Spring·Lombok·MySQL Connector 미탐지를 개선하고, CVE의 패치 여부와 오탐 가능성을 검토했습니다.

04

배포 자동화와 실행 자산 분리

구축·운영

로컬 빌드·셸 스크립트 배포를 Gitea·Jenkins CI/CD로 전환해 배포 시간을 약 10분에서 1분 30초로 줄였습니다. main·develop 브랜치를 운영·/dev 경로에 독립 배포해 반영 전 검증 환경을 마련했습니다.

Spring 코드에 삽입된 도구 실행 스크립트를 Docker·환경변수 기반으로 정리하고 실행 자산을 별도 저장소로 분리했습니다. 관리자 인증·세션·CSRF/CORS 정책과 설정 분리 등 보안점검 후속 조치도 반영했습니다.

05

IoTcube 2.0 독립 Worker 전환

설계·문서화

일부 도구를 요청 처리 흐름에서 동기 실행하는 구조의 HTTP 지연·자원 점유·배포 결합을 분석했습니다. Kafka 작업 큐와 도구별 독립 Docker Worker로 실행 책임을 분리하는 전환안을 설계했습니다.

작업 상태·공통 스키마·timeout·retry·dead-letter 처리와 8주 단계별 전환 로드맵을 문서화했습니다. 기존 Kafka 운영·유지보수 경험과 별개인 전환 설계이며, 전체 전환 완료 성과로 기재하지 않았습니다.