서론

"장대현 멘토님과 마지막 대면 멘토링을 했습니다. 최종 발표 PPT의 텍스트를 줄이고 핵심 화면 위주로 구성을 다시 잡으라는 피드백과 함께, 수동 진단 조치 결과 보완, Argus 자동 진단 기준(httpx / ZAP) 정리, 시연 영상 자막·하이라이트 보완 방향을 받아 반영했습니다."

마지막 멘토링에서 최종 발표 PPT·대본·시연 영상 수정 포인트를 정리하고, 피드백별 반영 내용을 기록합니다.

1. 멘토링 개요

항목 내용
일시 최종 평가 전 대면 멘토링 / 기록일 2026년 7월 17일
멘토 장대현 멘토님
참석자 개발팀 전원
안건 최종 발표 PPT 텍스트 축소·구성 수정, 수동 진단 조치 결과 보완, Argus 탐지 기준(httpx / ZAP) 명시, 시연 영상 가시성 보완

마지막 멘토링에서 공통으로 받은 지시는 단순했습니다.

  • PPT는 긴 문장보다 핵심 키워드와 화면이 먼저 보이게
  • 팀·구조·도구 설명은 파편화하지 말고 흐름으로
  • 수동·자동 진단의 역할과 기준을 분명히
  • 시연 영상은 빠르더라도 어디가 취약한지 보이게

그래서 이번에는 아래 순서로 손봤습니다.

  1. 프로젝트 개요·ONDE 구조·Argus 소개 슬라이드 압축
  2. 수동 진단 조치 결과와 “왜 수동인가” 대본 정리
  3. Argus 목표·아키텍처·검색엔진 기준을 앞으로 배치
  4. httpx / ZAP 역할 분담과 시연 영상 자막·하이라이트
  5. 차주 Argus AWS 인프라 착수를 위한 Next Step 정리

2. 멘토링 핵심 피드백 ①: 최종 발표 PPT 줄이기와 구성 수정

멘토님께서는 슬라이드에 글이 많아 발표가 길어지고 전달력이 떨어질 수 있다고 보셨습니다. 긴 문장은 줄이고, 핵심 키워드와 화면이 먼저 보이도록 PPT와 대본을 다시 맞추라는 지시였습니다.

① 프로젝트 개요 — 대비가 보이게

발표가 길어지지 않도록 대본 분량을 줄이고, PPT 문장도 최소화했습니다. 특히 개요 슬라이드는 긴 설명보다 대비가 바로 보이게 만드는 쪽이 중요했습니다.

기존에는 ‘동작하지만 신뢰할 수 없는 코드’ 이미지가 있었지만, 왜 위험한지를 말로 충분히 붙이지 못했습니다. 이번에는 대본에 위험 이유를 보강하고, 슬라이드에서는 두 메시지를 색으로 갈랐습니다.

  • 빨강: 동작하지만 신뢰할 수 없는 코드
  • 청록: 심각한 피해를 막는 유일한 방파제

같은 화면에 문제와 해결의 톤을 나누니, 발표자가 길게 읽지 않아도 평가자가 방향을 먼저 잡습니다. 여기에 대기업 솔루션 비용을 감당하기 어려운 스타트업·소규모 팀의 현실(간단한 비용 예시)을 더해, Argus가 “있으면 좋은 도구”가 아니라 필요한 보안 진단 도구라는 점을 비용 예시로 보강했습니다.

② 팀 소개·ONDE 구조도 — 세 시점으로 보이게

팀 소개는 7명 R&R을 처음부터 파편적으로 나열하던 방식을 접었습니다. 먼저 팀 공통 개발 전략과 협업을 말하고, 특이 사항이 있을 때만 개인으로 내려가도록 순서를 바꿨습니다. 평가자가 “누가 무엇을 했는지”보다 “팀이 어떤 기준으로 일했는지”를 먼저 이해하게 하려는 변경입니다.

ONDE 전체 기능 구조도도 같은 원칙이었습니다. 우리가 보여 주고 싶은 시점은 원래 일반 사용자 · 판매자 · 관리자 세 가지였습니다. 그런데 기존 슬라이드는 일반 사용자를 비로그인 / 로그인으로 나눠 그려 두어서, 실제로는 시점이 네 개처럼 보였습니다. 역할은 세 개인데 화면 구획만 하나 더 생긴 느낌이었습니다.

이번에는 일반 사용자 쪽(비로그인·로그인)을 한 흐름으로 합쳐, 슬라이드가 처음부터 세 시점으로 보이게 바꿨습니다. 숙소·항공·렌터카·보험 → 예약·결제 → 지도·여행기·마이페이지는 일반 사용자 축 안에 두고, 판매자 재고·정산과 관리자 검수·권한·취소가 어디서 맞닿는지만 보이게 정리했습니다.

이렇게 하면 “진단 대상이 샘플이 아니라 역할이 나뉜 실서비스”라는 점도, 시점 개수를 세느라 헷갈리지 않고 짧게 전달됩니다.

③ Argus 소개 — 실제 진단 화면 확대

Argus 도구 소개는 기능 목록을 길게 읽히기보다, 실제로 보이는 진단 UI를 크게 확대하는 쪽으로 바꿨습니다. 공격 표면 지도(엔드포인트 인벤토리)와 챕터별 진단 항목이 한 화면에 들어오면, “무엇을 자동으로 돌리는 도구인가”가 문장보다 빨리 전달됩니다.

이 화면에서는 검증된 엔드포인트 수, WRITE surface, 스키마 커버리지와 함께 XSS/CSRF·Injection 같은 자동 진단 항목, 그리고 수동 진단으로 표시된 항목이 함께 보입니다. 이후 슬라이드에서 “왜 어떤 항목은 수동으로 빠지는지”를 말할 때, 이 구분이 화면에서 먼저 보여야 설명이 짧아집니다.

④ 수동 진단의 한계 / 자동 진단의 필요성 — 앞으로 배치

세부 기능 나열보다 자동 진단이 왜 필요한지를 앞으로 당기라는 피드백을 반영했습니다. 수동 진단은 인력·시간이 크고 전문 지식이 필요하며, 자동 진단은 반복 점검을 표준 기준으로 돌려 효율과 신뢰를 같이 가져가겠다는 메시지를 한 장에 압축했습니다.

Argus 아키텍처 설계도도 뒤쪽에 두지 않고, 목표·이점 다음에 바로 보이도록 순서를 앞으로 옮겼습니다. “도구 설명 → 나중에 구조”가 아니라 문제 → 목표 → 구조 → 화면 순으로 읽히게 맞춘 것입니다.

3. 멘토링 핵심 피드백 ②: 수동 진단 조치 결과와 자동·수동 구분

취약점 종합 평가 슬라이드에 이행 점검 후 대응방안이 비어 있던 부분을 채웠습니다. 대표 취약점 2개를 골라, 아래 흐름으로 정형화했습니다.

  1. 어떤 탐지 방법으로 확인했는지
  2. 몇 건의 취약 포인트가 나왔는지
  3. 어떤 대응을 적용했는지
  4. 최종적으로 양호 상태로 닫혔는지

수동 진단과 자동 진단을 비교하려면, 자동으로 되지 않는 항목은 자동 범위에서 빼고 수동 진단으로 두는 구분이 필요합니다. 그래서 자동화 파이프라인 설명 슬라이드 이미지에서는 수동 진단 대상 취약점을 넣지 않았고, 왜 그 항목들은 자동 진단이 안 되어 수동으로 빠지는지는 대본에서 발표 때 설명하도록 정리했습니다.

4. 멘토링 핵심 피드백 ③: httpx / ZAP 기준과 시연 영상 보완

자동 진단 기준이 모호하다는 지적에 맞춰, 검색엔진 슬라이드에 httpx와 OWASP ZAP의 탐지 영역을 명시했습니다.

  • httpx / 검색엔진 쪽: URL·API·Swagger 소스 기반의 가벼운 변조와 상태 코드 매칭
  • ZAP·동적 진단 쪽: 실제 동적 점검과 스크린샷 증적이 붙는 파이프라인

역할이 겹쳐 보이지 않게 나누고, 시연 영상도 같이 손봤습니다.

  • 빠른 배속에 맞춰 발표 음성과 화면 싱크를 대본으로 다시 맞춤
  • 진단+스크린샷 구간에 어디가 취약한지 안내 자막 추가
  • 취약 지점에 빨간 테두리로 시선 유도
  • 결과서 화면에서는 자동·수동 결과를 비교하며 “자동 진단이 이렇게 나왔다”를 말로 강조

PPT가 아무리 짧아도, 영상이 휙 지나가면 평가자는 근거를 놓칩니다. 오늘은 PPT 압축과 시연의 가시성을 같은 우선순위로 맞췄습니다.

5. Next Step: Argus 실배포를 위한 AWS 인프라 구축

마지막 멘토링 피드백에 따른 PPT·영상 보완이 정리되면, 다음 핵심은 Argus 인프라 구축입니다. Private Subnet에 은닉 배치하는 방향을 전제로 사전 정비를 이어갑니다.

  • config.docker.yaml의 하드코딩 타깃 IP → ONDE Private IP
  • 오픈 리다이렉트 콜백 redirect_sink_base 주소 수정
  • ZAP JVM·Playwright Headless를 고려한 인스턴스(t3.xlarge 이상)
  • SSH(22) 대신 SSM Session Manager, ECR pull 최소 권한
  • Compose 볼륨의 부모 디렉터리 노출 제거, PDF용 나눔 폰트 경로 검수

차주 월요일부터 인프라 트랙으로 본격 착수합니다.

6. 정리

첫째, PPT는 문장을 늘리기보다 대비와 구성 순서가 중요했습니다. 문제/해결 색 구분과 팀·구조·도구 흐름을 정리하니 대본을 줄여도 전달이 됐습니다.

둘째, 수동·자동을 비교할 때 자동으로 안 되는 부분은 자동 쪽에서 빼고 수동 진단으로 둡니다. 자동화 파이프라인 슬라이드에도 그 항목을 넣지 않았고, 빠진 이유는 대본에서 설명했습니다.

셋째, 시연은 배속보다 어디를 봐야 하는지가 중요했습니다. 자막과 빨간 테두리가 없으면 결과서만 스쳐 지나갑니다.

Day 42는 마지막 멘토링 피드백을 PPT·대본·시연 영상에 반영해 수정한 날입니다. 개요 슬라이드의 색 대비, ONDE 3시점 구조도, Argus 실화면 확대, 수동/자동 필요성 전면 배치, 조치 결과 정리, httpx·ZAP 기준과 시연 자막·하이라이트까지 맞춰 두었습니다.

다음 주부터는 이 발표 구성을 기준으로, Argus AWS 인프라 구축으로 넘어갑니다.