Day 4 — 첫번째 멘토링

서론

"취약점 진단이 어떻게 이뤄지는지 모른 채 자동화 플랫폼을 만들면 단순한 기능 구현에 그칠 수 있습니다."

첫번째 멘토링에서 SK쉴더스 실무 취약점 진단 가이드를 살펴보고, 프로젝트 방향을 여행 플랫폼 먼저 개발 → 실무 가이드 기반 수동 진단·모의해킹으로 전환했습니다. 이어서 풀스택·인프라 서브 도메인 R&R도 다시 나눴습니다.

1. 멘토링 개요

항목	내용
일시	2026년 5월 23일 (토)
멘토	장대현 멘토님
참석자	개발팀 전원
주제	1차 주간 멘토링 피드백 반영 — 프로젝트 방향성 재정립 및 서브 도메인별 세부 R&R 구체화

2. 멘토링 핵심 피드백: 실무 취약점 진단의 본질과 방향성 전환

SK쉴더스 실무 취약점 진단 가이드의 이해

멘토님께서 SK쉴더스 현업에서 실제로 활용하는 실무 취약점 진단 가이드를 기반으로, 대표적인 핵심 취약점과 프로세스의 일부 예시를 짚어주셨습니다.

SQL Injection

개념: 입력값 검증 미흡으로 조작된 쿼리문이 서버를 거쳐 DB로 전달될 때, 비정상적으로 데이터가 조회되거나 변조되는 핵심 공격입니다.
진단 방향: 단순히 “툴이 취약점을 잡아냈다”는 겉핥기식 이해가 아니라, 실제 공격 스크립트를 수동으로 직접 삽입해 보고 DB 파이프라인에서 동작이 어떻게 왜곡되는지 눈으로 확인하는 동작 기반의 깊은 이해가 필수적임을 배웠습니다.

인증(Authentication) vs 인가(Authorization)

인증(Authentication): 시스템에 접근하는 사용자가 누구인지 신원을 확인하는 과정 (예: JWT 토큰 검증, 로그인)
인가(Authorization): 신원이 확인된 사용자가 무엇을 할 수 있는지 권한을 결정하는 과정 (예: 일반 회원 vs 총괄 관리자 권한 제어)
프로젝트 반영: 비즈니스 로직에서 인증과 인가의 차이를 소스 코드에서 분명히 구현하고, 권한 우회 취약점을 막고 확인할 수 있도록 아키텍처를 구성해야 합니다.

동일 취약점 분류 내 다양한 로직 케이스

동일한 취약점이라도 비즈니스 설계에 따라 다른 케이스로 발현될 수 있습니다. 이번에 개발할 여행 플랫폼 특성을 고려해, 아래 3대 로직 조작 케이스를 깊이 연구해야 합니다.

파라미터 조작: Request 값 변조로 타인의 예약 정보·개인정보를 무단 열람
가격 조작: 항공권·숙소 결제 프로세스의 허점을 노려 결제 금액 요청 값을 위변조
게시글 조작: 인가 검증 누락으로 타인의 게시글을 강제 수정·삭제

개발 및 진단 방향성의 근본적 전환

처음에는 취약점 진단 자동화 서비스(SaaS)를 먼저 만들려고 했지만, 멘토님에게 방향을 다시 생각하게 하는 중요한 피드백을 받았습니다.

핵심 조언: 취약점 진단의 원리를 모르는 상태에서 자동화 플랫폼을 만들면 단순 기능 구현에 그칠 수 있습니다. 자동화 도구를 돌리기 전에 취약점이 생기는 원인과 수동 점검 방법부터 익혀야 실제 개발 보안 역량으로 이어지고, 면접과 실무에서도 활용할 수 있습니다.

취약점 진단을 직접 해 보지 않고 자동화를 이야기하기는 어렵다는 점에 공감해, "여행 플랫폼을 먼저 개발하고, 실무 가이드라인에 따라 취약점 진단과 시나리오 모의해킹을 직접 수행하는 방식"으로 방향을 바꿨습니다. 자동화 스크립트는 이후 일정에서 다시 논의하기로 했습니다.

피드백 기반 수정 및 최종 주제 확정

팀 내 논의: 멘토링 직후 회의를 열어, 피드백을 바탕으로 기획안을 처음부터 다시 검토했습니다.
최종 프로젝트 주제 확정: 복잡한 비즈니스 로직(항공, 숙박, 금융, 위치 기반 서비스)이 얽혀 있어 권한 우회·로직 결함·파라미터 변조 등 다각도의 취약점을 심도 있게 도출할 수 있는 [여행 플랫폼 개발 및 이를 기반으로 한 실무 취약점 진단]을 최종 주제로 확정했습니다.

3. 피드백 반영에 따른 서브 도메인별 R&R 구체화

확정된 여행 플랫폼을 구축·진단하기 위해, 풀스택 5개 도메인과 인프라 2개 파트의 세부 R&R을 다시 쪼개고 기능 명세를 확정했습니다.

풀스택 트랙 (Full-Stack & DB)

인증 및 본사 보안 관리 (Auth & Admin Security): 회원 마스터 기능, JWT 기반 사용자/관리자 인증 체계, 전체 권한 제어 로직
항공 & 여행자 보험 서비스 (Core Service 1): 항공권 예약/스케줄링 파이프라인, 여행자 보험 가입/조건 검증 도메인 로직 및 UI
숙소 & 렌터카 서비스 (Core Service 2): 숙박 리스팅/실시간 예약, 렌터카 대여·반납 프로세스 엔드투엔드 구현
정산, 리워드 및 통계 대시보드 (Finance & Analytics): 결제·정산 데이터 처리, 리워드(포인트) 시스템, 금융 데이터 통계 대시보드
위치 기반(LBS) 및 커뮤니티/알림 서비스 (Infra & Content): 위치 기반 주변 정보 추천, 커뮤니티, 비동기 실시간 알림
공통 보안 스펙: 전체 관리자 권한 및 등급(Admin Role)에 따른 세부 권한 경계를 명확히 결정

인프라 트랙 (Infra & Security)

클라우드 아키텍처 설계 및 기본 틀 구축: VPC·가상 서버 기본 아키텍처 세팅, 클라우드 사용 계획서 작성
로컬 표준화 및 모니터링 체계 수립: 팀 공통 로컬 개발 컨테이너 환경, CloudWatch 기반 로그/메트릭 모니터링 검토
인프라 세부 사양 확정: 확장성·관리 효율을 고려해 핵심 인프라 사양(EC2 vs EKS) 기술 검토 완료, 아키텍처 정의서 보완 착수

4. 오늘의 주요 성과

멘토님과의 첫 만남: 앞으로 프로젝트를 진행하며 조언을 받을 멘토님과 첫 멘토링 세션 진행
주제 전환: “진단의 원리를 모른 채 자동화를 논할 수 없다”는 피드백을 반영해, 가상 서비스 선개발 후 실무 진단을 수행하는 여행 플랫폼 도메인으로 바꾸고 7인 R&R을 다시 정리했습니다.
실무 취약점 진단 가이드 이해: 실무 가이드라인의 프로세스·리스크 관리 요소를 파악하고, SQLi·인증/인가·케이스 분석을 통해 수동 점검 중심의 기초를 맛봄

5. 다음 단계: 파트별 상세 설계 및 WBS 수립

파트별 개별 개발 일정(WBS) 수립: 도메인별 세부 개발 태스크 분해 및 전체 통합 WBS 일정 관리 반영
프론트엔드 UI/UX 상세 화면 설계: 주요 비즈니스 도메인별 와이어프레임을 바탕으로 한 상세 화면 설계 착수
백엔드 및 DB 시스템 아키텍처 구조화: 각 서브 도메인별 ERD 데이터 모델링 및 엔티티 관계 구조 설계
클라우드 사용 계획서 및 아키텍처 정의서 보완: 멘토링 자문 내용을 바탕으로 클라우드 인프라 설계서 업데이트