Yoo HeehyeonYoo Heehyeon

보안 도구를 붙일 때 가장 먼저 봐야 하는 건 "어디서 실행할 것인가"다. 보통은 중앙 집중형 서버 모델이 익숙하지만, 개발자 주도 보안을 생각하면 로컬 독립형 모델도 충분히 대안이 된다. 여기서는 두 구조의 차이와, 왜 로컬 기반 설계가 실무적으로 의미가 있는지 정리한다.

1. 중앙 집중형 vs 로컬 독립형

대부분의 상용 SAST 도구는 중앙 서버 모델을 쓴다. 개발자가 코드를 커밋하면 CI가 이를 잡아서 분석 서버로 보내고, 결과는 중앙 대시보드에서 확인하는 방식이다.

1.1. 중앙 집중형 모델의 한계

관리자 입장에서는 통제가 쉽지만, 개발자 입장에서는 마찰이 생긴다.

• 피드백 지연: 코드를 올린 뒤 결과를 기다려야 해서 작업 흐름이 끊긴다.
• 인프라 종속성: 분석 서버가 죽으면 빌드나 배포도 같이 막힌다.
• 코드 외부 유출: 민감한 소스 코드를 외부 분석 서버로 보내야 하는 부담이 있다.

1.2. 로컬 독립형 모델의 강점

로컬 독립형 모델은 보안 도구를 컴파일러처럼 개발자 PC에서 바로 돌리게 만드는 방식이다.

• 즉각적인 피드백: 네트워크 왕복 없이 pre-push 같은 지점에서 바로 검사할 수 있다.
• 오프라인 동작: 인터넷이 없는 폐쇄망에서도 쓸 수 있다.
• Zero-Trust 측면의 이점: 소스 코드가 개발자 PC 밖으로 나가지 않는다.

2. 로컬 분석 도구의 아키텍처 설계

rootscan을 구상할 때도 이 로컬 독립형 모델을 기본 전제로 잡았다. 무거운 분석 서버를 두는 대신, 검증된 오픈소스 엔진을 감싸서 개발자 환경에 직접 배포하는 방식이다.

2.1. 엔진 레이어(Engine Layer)

핵심 엔진은 새로 만드는 것보다, 이미 검증된 도구를 가져다 쓰는 편이 낫다.

• Semgrep: 속도가 빠르고 Python 기반 커스텀 룰 작성이 쉬워서 SAST 엔진으로 적합하다.
• Trivy: CVE 데이터베이스를 로컬 DB 파일로 다룰 수 있어 오프라인 스캔에 유리하다.

2.2. 인터페이스 레이어(Interface Layer)

엔진이 뱉는 원본 로그는 그대로 보면 읽기 어렵다. 그래서 그 위에 인터페이스 레이어가 필요하다.

• CLI: scan 같은 단일 명령 중심으로 단순하게 만든다.
• Unified Reporter: 엔진마다 다른 JSON 출력을 하나의 Markdown 리포트 형식으로 정리한다.

3. Git Hook과의 결합 논리

이 구조에서 가장 중요한 연결 지점은 Git Hook이다. 좋은 도구도 실행하지 않으면 의미가 없다. 개발자가 매번 수동으로 돌리길 기대하는 방식은 오래 못 간다.

결국 도구는 개발자 습관 안에 숨겨 넣어야 한다. git push 시점에 훅이 자동으로 돌고, 임계치 이상 취약점이 나오면 push를 막는 식이다. 이렇게 해야 보안 점검이 선택 기능이 아니라, 기본 절차로 자연스럽게 붙는다.