📄 2026.02.12 (Day 76) - 개발방법론 강의 및 프로젝트 준비
1. 오늘 한 일
오늘은 루키즈 과정 공통 강의로 개발 방법론 ABC (Agile 개발 프로세스) 강의를 들었다. SK AX 소속 한정헌 강사의 강의로, 초급 개발자를 위한 소프트웨어 개발 프로세스와 관리 프로세스 전반을 다루는 내용이었다.
강의 자체는 개발자 대상이다 보니 보안 컨설팅 프로젝트와는 직접적인 연관이 적었지만, 프로젝트 전반의 구조를 이해하는 데는 도움이 됐다.
2. 강의 주요 내용 요약
개발 프로세스의 핵심 4단계
| 단계 | 설명 | 주요 활동 | 특징 |
|---|---|---|---|
| 분석 | 무엇을 만들지? (WHAT) | 요구사항 수집, 화면 흐름 정의, 사용자 시나리오 작성 | 추상적 |
| 설계 | 어떻게 만들지? (HOW) | 와이어프레임, DB 설계(ERD), API 설계 | 논리적 |
| 개발 | 실제로 구현 | HTML/CSS/JS, 백엔드 API, DB 테이블 생성 | 기술적 |
| 테스트 | 동작 검증 및 오류 수정 | 기능 테스트, UI 테스트, 버그 수정 | 물리적, 구체적 |
SDLC 모델 종류
폭포수 모델 (Waterfall Model)
- 순차적 단계별 진행: 분석 → 설계 → 개발 → 테스트
- 각 단계 완료 후 다음 단계로 진행
- 관리 용이하지만 변경에 취약
- 작동 시스템이 후반부에 나옴
프로토타입 모델 (Prototyping Model)
- 시제품을 먼저 만들어 사용자 확인
- 요구사항이 불명확할 때 유용
- 개발자-사용자 간 오해 조기 해소
증분 모델 (Incremental Model)
- 프로토타입 + 폭포수 결합
- 전체 요구사항 정의 후 세부 개발은 점진적 진행
애자일 (Agile) - 스크럼(Scrum)
- 짧은 주기(Sprint) 단위 반복 개발
- 변화하는 요구사항에 유연 대응
- 협업과 소통 중시
아키텍처 스타일
- 레이어드 아키텍처 (Layered)
- 이벤트 기반 아키텍처 (Event-Driven)
- 서비스 기반 아키텍처 (Service-Based)
- 마이크로서비스 아키텍처 (MSA)
협업 준비 (0단계)
개발 전 공통 기반 구축 항목:
- 개발환경 구성 (로컬, 서버)
- 코드 관리 체계 (Git 브랜치 전략)
- 표준 수립 (코드 컨벤션, 명명규칙)
- 협업 툴 정리 (Jira, Notion, Slack)
- 공통 문서 표준 (README, API 명세)
3. 보안 컨설팅 관점에서의 생각
개발 프로세스 vs 컨설팅 프로세스
개발 방법론은 “요구사항이 변할 수 있다"는 전제 하에 설계됐다. 특히 애자일은 변화에 빠르게 대응하는 것이 핵심이다.
반면 보안 컨설팅은 정적 분석에 가깝다:
- 법령과 인증기준이 이미 정해져 있음 (개인정보보호법, ISMS-P)
- 현황 분석 → 취약점 점검 → 위험평가 → 보고서 순서가 고정적
- 중간에 “요구사항 변경"이나 “스프린트 분할"이 어려움
- 체크리스트 기반이므로 프로토타이핑 개념도 맞지 않음
그래도 얻을 수 있는 것
프로젝트 구조화 관점:
- WBS(Work Breakdown Structure) 작성 시 단계별 명확한 산출물 정의 필요
- 0단계 “협업 준비” 개념은 컨설팅에도 적용 가능
- 문서 표준 (체크리스트 양식, 보고서 템플릿)
- 역할 분담 명확화
- 공유 도구 세팅 (Google Drive, Notion)
단계별 검증 원칙:
- 폭포수 모델처럼 각 단계 완료 후 검증(Progress Review) 필요
- 1차 멘토링 → 협약서 검토 → 2차 멘토링으로 진행
- 이전 단계 산출물이 다음 단계 입력이 되는 구조는 동일
4. 배운 점 및 인사이트
오늘의 감상
강의 자체는 개발자 대상이라 보안 컨설팅 프로젝트와는 결이 달랐다. 애자일이나 스프린트 같은 개념은 컨설팅에 직접 적용하기 어렵다는 생각이 들었다. 컨설팅은 이미 정해진 프레임워크를 따라가는 것이고, 법령 기반이라 중간에 요구사항이 바뀔 여지가 거의 없기 때문이다.
하지만 “프로젝트를 구조화하는 방법"이나 “협업 준비 단계"의 중요성은 충분히 가져갈 만했다. 특히 0단계에서 문서 표준, 역할 분담, 공유 환경을 먼저 세팅한다는 개념은 우리 팀에도 그대로 적용할 수 있다.
프로젝트 준비 방향
우리 팀에 적용할 것:
- 문서 작업 표준 먼저 정하기 (체크리스트 양식, 협약서 템플릿)
- Google Drive 폴더 구조 세팅 (차수별 산출물 분리)
- 역할 분담 초안 작성 (누가 어떤 산출물을 담당할지)
- Notion으로 일정 및 진행 상황 공유
적용하지 않을 것:
- 애자일, 스프린트 같은 반복 개발 방식 (컨설팅은 순차적 단계 구조)
- 요구사항 변경 대응 프로세스 (법령 기반이라 요구사항 고정)
- 프로토타이핑 (체크리스트 자체가 이미 표준화됨)
5. Quick Reference
개발 프로세스 vs 컨설팅 프로세스 비교
| 구분 | 개발 프로세스 (Agile) | 보안 컨설팅 프로세스 |
|---|---|---|
| 진행 방식 | 반복적, 스프린트 단위 | 순차적, 단계별 검증 |
| 요구사항 | 변경 가능, 유연 대응 | 법령 기반, 고정적 |
| 산출물 | 동작하는 소프트웨어 | 체크리스트, 보고서, 협약서 |
| 핵심 가치 | 변화 대응, 빠른 피드백 | 컴플라이언스 준수, 정확성 |
| 적용 모델 | Scrum, XP 등 | Waterfall에 가까움 |
컨설팅 프로젝트에 적용 가능한 개념
협업 준비 (0단계):
- 문서 표준 수립 (양식 통일)
- 공유 환경 세팅 (Drive, Notion)
- 역할 분담 명확화
- 일정 관리 체계
단계별 검증:
- 1차 멘토링: 계획서 검토
- 2차 멘토링: 협약서, 체크리스트 검토
- 3차 멘토링: 진단 실습 및 현황 작성 검토
- 4차 멘토링: 결과 보고서 초안 검토
- 5차 멘토링: 최종 발표
산출물 연계:
- 이전 단계 산출물 = 다음 단계 입력값
- 협약서 보안 요구사항 → 체크리스트 항목 반영
- 체크리스트 진단 결과 → 결과 보고서 작성
Today’s Insight:
오늘은 직접적으로 프로젝트에 적용할 내용을 배운 날은 아니었다. 개발 방법론은 개발자의 언어이고, 컨설팅은 컴플라이언스의 언어다. 하지만 “프로젝트를 어떻게 구조화하고 관리할 것인가"라는 메타적 관점에서는 배울 게 있었다. 특히 협업 준비 단계의 중요성은 팀장으로서 꼭 챙겨야 할 부분이다. 기술이 다르고 방법론이 달라도, 사람들이 함께 일하는 방식에는 공통점이 있다. 그 공통점을 잘 설계하는 것이 팀장의 역할일 것이다.