s2n 기반 정적 분석 + 서비스 취약점 연계 스캐너 설계 정리 -1
3줄 요약
- s2n은 기능 확장 자체보다 어떻게 실전에서 더 쉽게 쓰게 만들 것인가가 먼저 중요했다.
- 초기 제품 방향은 서버형 SaaS보다 로컬 기반 Chrome Extension 구조가 더 현실적이었다.
- 목표는 단순 GUI 추가가 아니라, 레드팀 관점의 사전 분석 보조 도구로 발전시키는 것이다.
시작하며
처음에는 단순히 이런 생각이었다.
s2n에 정적 분석을 붙이고, 포트 서비스 버전 분석을 붙이고, CVE 연계를 붙이면 더 강한 도구가 되지 않을까?
틀린 생각은 아니다.
근데 실제로 프로젝트를 이어가다 보니 기능 추가만으로는 부족하다는 게 보였다.
보안 도구는 기능이 많아도 실제로 손이 잘 안 가면 의미가 없다.
특히 CLI 기반 도구는 익숙한 사람에겐 편하지만,
처음 접하는 사람이나 협업 환경에서는 다음 같은 문제가 생긴다.
- 실행 방법을 따로 익혀야 한다
- 옵션이 많아질수록 사용 진입장벽이 커진다
- 결과를 파일이나 로그로 직접 뒤져야 한다
- 이전 실행 이력을 다시 보기 불편하다
- 분석 엔진은 좋은데 도구 자체는 덜 다듬어진 느낌이 난다
그래서 어느 순간부터 질문이 바뀌었다.
무슨 기능을 더 넣을까? 보다
이걸 어떻게 하면 더 실전적으로, 더 자주 쓰게 만들 수 있을까?
이걸 먼저 보게 된 거다.
이 글은 그 방향 전환에 대한 기록이다.
즉, 왜 s2n을 로컬 중심으로 재정리했고, 왜 Chrome Extension 방향으로 잡았는지를 정리한 문서다.
전체 방향 전환
처음 흐름은 사실상 이런 구조에 가까웠다.
[CLI Scanner]
|
v
[결과 JSON / 로그]
|
v
[사용자가 직접 확인]이 구조는 개발자 입장에서는 단순하고 빠르다.
근데 사용자 입장에서는 생각보다 불친절하다.
- 터미널에서 실행해야 하고
- 옵션은 직접 기억하거나 문서를 다시 찾아봐야 하고
- 결과는 JSON, 로그, 콘솔 출력으로 흩어질 수 있고
- 반복 실험 결과를 한 눈에 비교하기 어렵다
그래서 방향을 바꾸기로 했다.
[Chrome Extension UI]
|
v
[스캔 실행 / 상태 확인 / 결과 확인]
|
v
[로컬 저장 / JSON 내보내기 / 히스토리 관리]핵심은 단순하다.
스캐너를 만드는 것에서 끝나는 게 아니라,
실제로 계속 쓰게 되는 분석 도구 형태까지 포함해 설계하자는 거다.
이 방향은 단순 편의성 개선이 아니라,
프로젝트를 포트폴리오 관점에서 봤을 때도 훨씬 의미가 있다.
왜냐하면 “기능 구현”만 한 사람이 아니라,
보안 도구를 어떤 방식으로 제품화할지 고민한 사람이라는 점까지 보여줄 수 있기 때문이다.
1. 왜 굳이 로컬화하려 했는가
이건 단순히 가볍게 만들고 싶어서가 아니다.
초기 단계에서 불필요한 복잡도를 줄이고 핵심 기능에 집중하기 위해서다.
보안 스캐너를 서버형으로 만들면 겉보기엔 더 멋있어 보일 수 있다.
근데 실제로는 너무 많은 문제가 한꺼번에 따라온다.
서버형 구조에서 바로 생기는 문제
| 항목 | 문제 |
|---|---|
| 대상 정보 처리 | 스캔 대상 정보가 외부 서버를 거치게 된다 |
| 결과 저장 | 사용자 결과를 서버 기준으로 설계해야 한다 |
| 인증/권한 | 로그인, 세션, 권한 관리가 필요해진다 |
| 운영 부담 | 배포, 장애 대응, 모니터링 등 운영 이슈가 늘어난다 |
| 확장 방향 | 스캐너보다 플랫폼 관리가 더 큰 문제가 될 수 있다 |
이러면 프로젝트의 본질이 흐려진다.
지금 우리가 만들고 싶은 건 거대한 SaaS 플랫폼이 아니다.
핵심은 s2n의 분석 기능을 더 실전적으로 활용할 수 있게 만드는 것이다.
그래서 초기 단계에서는 서버를 붙이는 것보다
사용자 로컬 환경에서 바로 실행되고, 바로 결과를 볼 수 있는 구조가 더 적절하다고 판단했다.
로컬 구조의 장점
- 설치 후 바로 테스트 가능
- 대상 정보가 외부 서버를 굳이 거치지 않는다
- 결과를 사용자가 직접 보관할 수 있다
- MVP 단계에서 구현 범위를 통제하기 쉽다
- 핵심 엔진 개선에 더 집중할 수 있다
즉, 로컬화는 편의성 선택이 아니라
개발 우선순위를 바로잡기 위한 설계 선택이었다.
2. 왜 Electron이 아니라 Chrome Extension인가
로컬 GUI를 만든다고 하면 보통 Electron 같은 데스크탑 앱도 충분히 후보가 될 수 있다.
근데 이번에는 Chrome Extension 쪽이 더 잘 맞는다고 봤다.
이유는 분명하다.
s2n이 다루는 대상과 사용 흐름이 웹 환경과 더 가깝기 때문이다.
Chrome Extension을 선택한 이유
| 항목 | 이유 |
|---|---|
| 접근성 | 설치와 실행 진입장벽이 낮다 |
| 사용성 | 브라우저 안에서 바로 열 수 있어 흐름이 빠르다 |
| 구조 단순성 | Popup, Options, Background 구조만으로 핵심 흐름 구현이 가능하다 |
| 테스트 편의성 | 개발 단계에서 빠르게 로컬 테스트가 가능하다 |
| 권한 통제 | 필요한 권한만 제한적으로 줄 수 있다 |
| 웹 친화성 | 웹 서비스 대상 분석 흐름과 잘 맞는다 |
Electron은 자유도가 높은 대신,
앱 자체를 만드는 비용이 더 커진다.
반면 Chrome Extension은 초기 MVP를 만들 때 더 가볍고,
웹 서비스 중심 보안 도구라는 성격에도 잘 맞는다.
즉, 이번 선택의 기준은 “무엇이 더 멋있나”가 아니라
“무엇이 더 빨리, 더 현실적으로 핵심 보안 분석 흐름을 구현하나”였다.
3. Chrome Extension 구조가 s2n에 잘 맞는 이유
s2n의 핵심 강점은 플러그인 확장 구조다.
그러면 GUI도 그 철학을 망치면 안 된다.
Chrome Extension 구조는 이 점에서 꽤 잘 맞는다.
[Popup]
- 빠른 실행
- 대상 입력
- 플러그인 선택
[Background]
- 스캔 작업 관리
- 상태 유지
- 요청 흐름 제어
[Options]
- 세부 설정
- 결과 목록
- 히스토리 확인
- 내보내기역할 분리가 명확하다.
이 구조가 좋은 이유
- UI는 가볍게 유지할 수 있다
- 실제 작업은 Background에서 관리할 수 있다
- 결과 저장과 화면 표시를 분리할 수 있다
- 플러그인 추가가 전체 UI 수정으로 번지는 걸 막을 수 있다
즉, 내부 엔진 구조와 사용자 인터페이스 구조가 서로 충돌하지 않는다.
이건 포트폴리오 관점에서도 중요하다.
단순히 “GUI 붙였다” 수준이 아니라,
확장형 보안 도구에 맞는 인터페이스 구조를 고민했다는 흔적이 되기 때문이다.
4. 왜 이 방향이 레드팀 관점에서도 의미가 있는가
나는 원래 레드팀 지향으로 공부하고 있고,
도구를 볼 때도 단순 점검 툴보다는 실전에서 어떤 흐름에 들어갈 수 있느냐를 더 중요하게 본다.
그 관점에서 보면 이번 구조 전환은 단순 UI 개선이 아니다.
이 도구는 잘 다듬으면 다음 같은 흐름의 앞단에 놓을 수 있다.
실전 관점 흐름
[대상 식별]
|
v
[포트 / 서비스 파악]
|
v
[기술 스택 / 버전 / 구조 추정]
|
v
[정적 분석 / 취약 구성 탐지]
|
v
[CVE / 공격 가능성 / 방어 포인트 정리]즉, 이건 단순 취약점 스캐너가 아니라
사전 정찰과 기술 표면 분석을 보조하는 도구로 확장될 수 있다.
레드팀에서 중요한 건 단순히 “취약점 하나 찾기”가 아니다.
대상 환경을 빠르게 이해하고,
어떤 기술 스택이 돌아가고 있고,
어느 부분이 약한지 우선순위를 잡는 과정이 중요하다.
그런 의미에서 s2n의 방향을
- 정적 분석
- 서비스 버전 분석
- CVE 연계
- 설명 가능한 리포트
로 잡은 건 꽤 일관된 선택이었다.
그리고 여기에 Chrome Extension 형태를 붙이면,
이 분석 흐름이 더 자주, 더 빠르게 실행될 수 있다.
즉, 실전형 분석 도구로서의 접근성이 올라간다는 점에서 의미가 있다.
5. 우리가 만들고 싶은 건 거대한 플랫폼이 아니라 “손이 가는 분석 도구”다
프로젝트를 하다 보면 자꾸 욕심이 생긴다.
- 계정 시스템도 넣고 싶고
- 협업 기능도 넣고 싶고
- 서버 동기화도 넣고 싶고
- 대시보드도 크게 만들고 싶다
근데 그렇게 가면 초기에 가장 중요한 걸 놓친다.
지금 필요한 건 거대한 플랫폼이 아니다.
핵심은 작아도 실제로 계속 쓰게 되는 도구다.
우리가 원하는 건 대충 이런 흐름이다.
- 대상 입력
- 스캔 시작
- 진행 상태 확인
- 결과 요약 확인
- 필요하면 JSON 내보내기
- 이전 기록 다시 확인
이 흐름만 제대로 돌아가도 도구로서의 완성도는 꽤 높다.
즉, 이번 방향 전환은 기능 축소가 아니라,
핵심 사용 경험에 집중하기 위한 범위 통제에 가깝다.
6. 사용자 경험 측면에서도 구조 전환 효과가 크다
기존 CLI 중심 흐름은 보통 이렇다.
설치 -> 명령어 확인 -> 옵션 입력 -> 실행 -> 로그 확인 -> 결과 파일 열기반면 Extension 기반 흐름은 이렇게 바뀐다.
확장 실행 -> 대상 입력 -> 버튼 클릭 -> 상태 확인 -> 결과 확인 -> 내보내기겉보기에 단순한 차이 같지만,
실제 사용성에서는 큰 차이를 만든다.
비교
| 항목 | 기존 방식 | 변경 후 |
|---|---|---|
| 실행 진입 | 터미널 필요 | 버튼 클릭 중심 |
| 설정 접근 | 옵션 기억 필요 | UI에서 선택 가능 |
| 결과 확인 | 파일/로그 직접 확인 | 화면에서 바로 확인 |
| 히스토리 | 직접 관리 | 로컬 저장 가능 |
| 반복 사용성 | 숙련자 중심 | 더 넓은 사용자 접근 가능 |
보안 도구는 결국 반복 사용성이 중요하다.
한 번만 돌려보고 끝나는 도구보다,
자주 열고 자주 실험하게 되는 도구가 훨씬 강하다.
그 점에서 이번 구조 전환은 단순 UI 개선이 아니라
도구의 생명력을 늘리는 선택이었다.
7. 보안 도구답게 권한은 최소화해야 한다
Chrome Extension으로 가면 편의성은 좋아지지만,
동시에 권한 문제를 더 신중하게 봐야 한다.
보안 도구가 과하게 많은 권한을 요구하면
오히려 신뢰성을 해칠 수 있다.
그래서 기본 원칙은 분명하다.
권한 설계 원칙
- 꼭 필요한 권한만 요청한다
- 특정 대상에만 접근하도록 제한한다
- 불필요한 페이지 접근은 최소화한다
- 로컬 저장 중심으로 설계한다
- 외부 전송이 필요하다면 명확한 목적과 범위를 둔다
이건 단순한 구현 이슈가 아니라,
보안 도구로서 어떤 태도를 가지는가와 연결된 문제다.
실제로 레드팀이든 보안 엔지니어링이든,
도구 설계에서 권한과 신뢰를 어떻게 다루는지는 꽤 중요한 역량으로 본다.
8. 초기 범위를 줄인 것도 의도된 선택이다
프로젝트는 초반에 범위를 너무 넓히면 무너지기 쉽다.
그래서 이번 단계에서는 일부러 다음 정도에 집중하는 게 맞다고 봤다.
초기 MVP에서 중요한 것
- 스캔 실행 가능
- 상태 확인 가능
- 결과 요약 가능
- JSON 내보내기 가능
- 로컬 히스토리 확인 가능
아직 굳이 넣지 않아도 되는 것
- 멀티유저 협업
- 서버 동기화
- 과금 모델
- 계정 시스템
- 복잡한 팀 단위 관리 기능
이렇게 해야 목표가 흐려지지 않는다.
즉, 이번 결정은 기능을 포기한 게 아니라,
핵심 가치를 먼저 살리기 위한 전략적 축소에 가깝다.
9. 포트폴리오 관점에서 이 글이 보여주는 것
이 문서는 단순히 “Chrome Extension 만들기로 했다”를 적는 글이 아니다.
회사 포트폴리오 관점에서 보면,
이 글은 다음을 보여준다.
이 문서가 드러내는 역량
| 항목 | 보여주는 내용 |
|---|---|
| 보안 관점 | 단순 스캐너가 아니라 분석 흐름 전체를 고려함 |
| 제품 관점 | 기능 구현에서 끝나지 않고 사용 방식까지 설계함 |
| 구조 설계 | 플러그인 구조와 UI 구조의 결합 방식을 고민함 |
| 우선순위 판단 | 서버형보다 로컬 MVP가 적절하다고 판단함 |
| 실전성 | 레드팀 관점의 사전 분석 보조 도구로 확장 가능성을 봄 |
즉, 이 프로젝트는 “툴 하나 만들었다” 수준보다,
실전 보안 도구를 어떤 형태로 설계할지 고민한 과정까지 함께 보여줄 수 있다.
이건 실제 지원서나 포트폴리오에서 생각보다 중요하다.
왜냐하면 기업 입장에서는 단순 구현 능력만 보는 게 아니라,
문제를 어떤 방식으로 구조화하고,
제약 조건 안에서 어떤 선택을 했는지도 보기 때문이다.
마치며
이번에 로컬화와 Chrome Extension 방향을 선택한 이유는 단순하다.
기능이 많아도 실제로 잘 안 쓰이면 의미가 없기 때문이다.
s2n은 원래도 확장 가능한 구조를 갖고 있었고,
이제는 여기에 맞는 사용 형태를 붙이려는 단계로 넘어왔다고 보면 된다.
정리하면 이렇다.
- 서버형보다 로컬 구조가 초기 단계에 더 적절했다
- Electron보다 Chrome Extension이 더 가볍고 현실적이었다
- 목표는 단순 GUI 추가가 아니라 실전형 보안 분석 도구 설계였다
- 레드팀 관점에서도 이 방향은 사전 분석 보조 도구로 확장 가능성이 있다
아직 완성된 상태는 아니다.
근데 방향은 꽤 분명하다.
s2n을 단순히 실행하는 스캐너가 아니라,
실제로 자주 열어보게 되는 분석 도구로 바꾸는 것.
이 글은 그 출발점에 대한 정리다.
