바이브쉴드: 보안 아키텍처에 도전하다

인증·인가 체계를 다루다 보니 자연스럽게 “이 코드가 정말 안전한가”라는 질문에 관심이 옮겨갔습니다. AI 코딩 도구를 매일 쓰면서 든 또 다른 의문은 “AI가 만들어준 코드에 존재하지 않는 API를 호출하는 경우가 있는데, 이걸 잡아내는 도구가 있는가”였습니다. 이 두 질문에서 시작해 3인 팀으로 “바이브쉴드”를 만들었고, 저는 관제시스템·보안 아키텍처를 담당했습니다. 중소벤처기업부 「모두의 창업 프로젝트」에도 선정됐습니다.

왜 로컬 실행형으로 설계했는가

코드를 분석하는 도구를 만들면서 가장 먼저 정한 원칙은 “코드가 외부로 나가지 않는다”였습니다. 보안 취약점을 찾는 도구가 정작 코드를 클라우드로 전송한다면, 폐쇄망 환경이나 보안에 민감한 기업에서는 애초에 도입할 수 없습니다. 그래서 Tree-sitter 기반 다언어 AST 파서와 YAML 룰베이스 매칭을 전부 로컬에서 실행되도록 설계했고, 이 결정이 바이브쉴드의 도입 장벽을 낮추는 핵심 요소가 됐습니다.

패턴 매칭이 잡을 수 없는 영역: LLM 환각 API

OWASP Top 10 기반 9종 취약점(SQL 인젝션, XSS, 하드코딩된 비밀키, 명령어 주입, 경로 조작, 취약한 암호화, 안전하지 않은 역직렬화, SSRF, 인증·인가 누락)은 기존 SAST 도구들도 어느 정도 탐지합니다. 저희가 다르게 접근한 지점은 “존재하지 않는 API를 호출하는 코드”였습니다. 이건 문법적으로는 완전히 정상이기 때문에, 패턴 매칭만으로는 구조적으로 잡을 수 없습니다.

그래서 PyPI·npm 공식 인덱스를 화이트리스트로 두고, 코드에서 호출하는 API가 실제로 그 패키지에 존재하는지 대조하는 방식을 택했습니다. 현업 개발자 9인을 대상으로 한 PoC에서 샘플 50건 기준 환각 API 탐지율 83%를 기록했고, 동일 샘플에서 Semgrep·SonarQube는 0%였습니다. 이 지표를 보고 나서야 “패턴 매칭 기반 도구와 화이트리스트 대조 기반 도구가 아예 다른 문제를 풀고 있다”는 걸 명확히 이해했습니다.

결정론을 선택한 이유

탐지 엔진을 LLM 기반으로 만들 수도 있었지만, 룰베이스 결정론을 채택했습니다. 이유는 감사·규제 대응이라는 용도 자체에 있습니다. 전자금융감독규정, ISMS-P 인증기준 같은 규제 조항에 코드 패턴을 매핑해 감사 리포트를 자동 생성하려면, 같은 코드에는 항상 같은 판정이 나와야 합니다. LLM 단독 도구는 같은 입력에도 판정이 달라질 수 있어 감사 증빙으로 쓰기 어렵다고 판단했고, 이 구조적 차이가 저희 도구의 방향을 결정했습니다.

관제·보안 아키텍처를 맡으며 배운 것

개발자로 일하며 보안을 “지켜야 하는 규칙”으로만 대했던 것과, 보안 도구를 직접 설계하며 “왜 이 규칙이 이렇게 생겼는가”를 되짚어보는 것은 전혀 다른 경험이었습니다. 오탐률을 3.8%로 낮추기 위해 규칙 하나하나를 현업 개발자 9인의 피드백을 받아 조정하는 과정에서, 보안 도구의 완성도는 탐지율만큼이나 “얼마나 덜 방해하는가”에 좌우된다는 걸 배웠습니다.