소프트웨어를 어떻게 만들 것인가: 개발 방법론과 테일러링
목차 23
5과목 정보보호 영역(47~53강)이 '무엇으로 지키나'를 다뤘다면, 54강부터는 무대가 'SW를 어떻게 만드나'로 바뀐다. 같은 소프트웨어라도 프로젝트마다 만드는 방식이 다르고, 표준 방식을 우리 프로젝트에 맞게 고쳐 쓰는 것 — 그게 이 강의 중심인 테일러링이다. 이 단원은 보안과 정반대다. 보안은 뚫리면 끝이라 정답이 하나로 수렴했지만, 개발 방법론은 프로젝트마다 답이 달라서 '맞춰 쓴다'가 핵심이다. 2~3회에 1문제가 꾸준히 나오는 단원이다. 다섯 묶음으로 잡는다. ① 소프트웨어 공학과 SDLC 5단계, ② SDLC 5대 모형 ★폭프나V애★(폭포수·프로토타입·나선형·V모델·애자일, 위험 분석=나선형), ③ 애자일 실천 — 스크럼·XP(★프작고변★·★의단피용존★), ④ 개발 방법론 5대 분류(★구정객컴애★)와 테일러링(내부 ★목요규기★·외부 ★법납이기★·절차 ★목환기상검★), ⑤ 프레임워크 vs 라이브러리(IoC=제어의 역전). 핵심 두음과 함정 6선이 반사적으로 튀어나오면 이 단원은 정복이다.
대단원 1 — 소프트웨어 공학과 SDLC
소프트웨어 공학과 3대 목표 — 좋게·싸게·빠르게 ·기초·
[정의] 소프트웨어 공학(Software Engineering) = 소프트웨어를 경제적·신뢰성 있고 효율적으로 개발·운영·유지보수하기 위한 공학적 접근 방법. 혼자 짜는 5분짜리 스크립트와 100명이 3년간 만드는 대형 시스템은 차원이 다르다 — 절차·문서·테스트·인력 관리가 따라붙어 '공학'이 된다.
[표] 3대 목표
| 목표 | 핵심 의미 |
|---|---|
| 품질(Quality) | 정확·신뢰·유지보수 용이 |
| 비용(Cost) | 개발·운영·유지보수 비용 최소화 |
| 납기(Time) | 약속된 일정 내 완료 |
🔑 암기 품질·비용·납기 세 꼭짓점. 셋의 우선순위는 프로젝트마다 다르다 — 금융은 품질, 콘텐츠 서비스는 납기, 대형 SI는 비용을 앞세운다. 이 '프로젝트마다 다르다'가 뒤에 나올 테일러링의 출발점이다. 🎯 빈출 3대 목표 매칭은 가볍게. 본 빈출은 SDLC·애자일·테일러링이다. 💡 '품질·비용·납기 중 무엇이 가장 중요한가'의 정답은 '프로젝트마다 다르다'. 정답이 하나가 아니라는 게 이 단원 전체의 철학이다.
SDLC 5단계 — 단계와 모델은 차원이 다르다 ·기초·
[정의] SDLC(Software Development Life Cycle) = 소프트웨어가 태어나서 폐기될 때까지 전 과정을 체계적으로 정리한 공정 모델. 큰 일을 작은 단계로 나눠 관리한다.
[표] SDLC 5단계 공통 절차
| 단계 | 핵심 활동 | 산출물 |
|---|---|---|
| ① 요구분석 | 무엇을 만들지 파악 | 요구사항 명세서(SRS) |
| ② 설계 | 어떻게 만들지 구조화 | 아키텍처·UI/DB 설계서 |
| ③ 구현 | 실제 코딩 | 소스코드 |
| ④ 테스트 | 품질 확인 | 테스트 결과서 |
| ⑤ 유지보수 | 운영 중 수정·개선 | 유지보수 리포트 |
🔑 암기 요·설·구·테·유. 이 5단계를 '어떤 순서로, 얼마나 반복하느냐'에 따라 폭포수·프로토타입·나선형·V모델·애자일로 갈린다 — 다음 대단원의 ★폭프나V애★다. ⚠️ 함정 SDLC 5단계(요·설·구·테·유)와 SDLC 모델 5종(폭·프·나·V·애)을 섞으면 오답. 단계는 '만드는 절차', 모델은 '그 절차를 돌리는 방식' — 층위가 다르다. 🎯 빈출 5단계 순서, 단계 ↔ 산출물 매칭, 단계와 모델의 구분.
대단원 2 — SDLC 5대 모형 ★폭프나V애★
폭포수(Waterfall) 모형 — 한 방향으로만 흐른다 ·빈출·
[정의] 폭포수 모형 = 요구분석→설계→구현→테스트→유지보수를 순차적·단방향으로 진행하는 가장 고전적인 SDLC 모델. 폭포가 위에서 아래로만 떨어지듯 되돌아갈 수 없다.
[표] 특징
| 항목 | 내용 |
|---|---|
| 흐름 | 순차적·비가역(되돌아갈 수 없음) |
| 장점 | 관리 쉬움, 단계별 산출물 명확, 대규모 인력 투입 가능 |
| 단점 | 요구 변경 대응 취약, 후반 결함 발견 시 비용 폭등 |
| 적합 | 요구사항이 명확·안정한 대형 SI·공공·국방 |
| 부적합 | 요구가 자주 바뀌는 B2C·스타트업 서비스 |
🔑 암기 시그니처는 '순차·단방향·비가역'. 한 번 쓴 유언장처럼 고치려면 처음부터 다시 써야 한다 — 초기 요구분석이 생명. ⚠️ 함정 '폭포수는 요구사항 변경에 유연하다' ❌ → 100% 오답. '유연' 키워드가 폭포수 선지에 붙으면 즉시 X. 변경에 강한 모델은 애자일·프로토타입·나선형이다. 🎯 빈출 특징 고르기, '옳지 않은 것' 고르기. 거의 매 회차 단골. 📝 기출 기출 2
프로토타입(Prototype) 모형 — 시제품은 버린다 ·간헐·
[정의] 프로토타입 모형 = 시제품(샘플)을 빠르게 만들어 사용자 피드백을 받고, 그 결과를 반영해 본 제품을 개발하는 SDLC 모델.
[표] 특징
| 항목 | 내용 |
|---|---|
| 흐름 | 시제품 → 피드백 → 수정 → 본 제품 |
| 장점 | 요구 명확화, 사용자 만족도 ↑, 의사소통 격차 ↓ |
| 단점 | 시제품 폐기 비용, 본 제품 일정 지연 가능 |
| 적합 | 요구가 불명확하거나 UI/UX 검증이 중요한 프로젝트 |
🔑 암기 핵심은 '시제품은 폐기 전제(Throwaway)'. 결혼식 드레스 샘플을 입어보고 핏만 확인한 뒤 본 드레스는 새로 맞추는 것과 같다. ⚠️ 함정 '프로토타입은 시제품을 그대로 본 제품으로 사용한다' ❌ → 오답. 시제품은 폐기, 본 제품은 별도로 만든다. 🎯 빈출 '시제품·피드백·폐기 전제' 키워드 매칭. 간헐.
나선형(Spiral) 모형 — 위험 분석이면 무조건 이것 ·빈출·
[정의] 나선형 모형 = 점진적·반복적 개발 방식으로, 매 반복(사이클)마다 위험 분석(Risk Analysis)을 수행하는 SDLC 모델. Barry Boehm이 1988년 제안.
[표] 나선형 한 사이클 4단계
| # | 단계 | 핵심 |
|---|---|---|
| ① | 계획(Planning) | 목표·대안·제약 식별 |
| ② | 위험 분석(Risk Analysis) | 이번 사이클의 위험 평가·관리 |
| ③ | 개발 및 검증(Engineering) | 시제품·산출물 제작 |
| ④ | 평가(Evaluation) | 결과 검토 후 다음 사이클 진입 |
🔑 암기 ★위험분석=나선형★ — 'Boehm' · '1988' · '위험 분석' 셋 중 하나만 보여도 무조건 나선형. 안에서 바깥으로 나선처럼 점진 확장한다. ⚠️ 함정 'V모델이 위험 분석을 포함한다' ❌ → 위험 분석은 나선형 전용. 대규모·장기 프로젝트에 적합하나 위험 분석 전문가가 필요해 복잡·고비용이다. 🎯 빈출 설명 → 모형 찾기(Boehm·위험 분석). 매 회차급 단골. 📝 기출 기출 1
V모델(V-Model) — 개발과 테스트의 거울 매칭 ·간헐·
[정의] V모델 = 폭포수를 확장해 각 개발 단계에 대응하는 테스트 단계를 좌·우 V자로 매칭한 SDLC 모델. 1980년대 후반 독일 정부 표준에서 출발.
[표] V자 매칭 구조
| 좌측(개발) | ↔ | 우측(테스트) |
|---|---|---|
| 요구분석 | ↔ | 인수 테스트 |
| 시스템 설계 | ↔ | 시스템 테스트 |
| 상세 설계 | ↔ | 통합 테스트 |
| 구현·코딩 | ↔ | 단위 테스트 |
🔑 암기 시그니처는 '테스트 짝(쌍) 매칭'. 가장 깊은 V자 꼭짓점이 '코딩 ↔ 단위 테스트'. 사람 목숨이 걸린 SW(자율주행·의료기기·항공)에서 표준이다. ⚠️ 함정 V모델은 위험 분석 ❌(나선형 전용), 반복 ❌(폭포수 한계 상속). V모델 = 테스트 매칭 한 줄로 끝. 🎯 빈출 V자 매칭 구조, 폭포수와의 차이. 간헐.
애자일(Agile)과 4대 가치 ★프작고변★ — 변화에 적응한다 ·빈출·
[정의] 애자일 = 변화에 빠르게 대응하기 위해 짧은 주기로 반복 개발하는 경량 SDLC 패러다임. 2001년 2월 미국 유타주 스노버드(Snowbird)에서 17명의 개발자가 발표한 애자일 선언문(Agile Manifesto)에서 출발. Kent Beck·Martin Fowler·Robert Martin 등이 참여했다.
[표] 애자일 4대 가치 ★프작고변★ (왼쪽 < 오른쪽)
| # | 왼쪽(전통) | < | 오른쪽(애자일이 선호) | 두음 |
|---|---|---|---|---|
| ① | 프로세스와 도구 | < | 개인과 상호작용 | 프 |
| ② | 포괄적인 문서 | < | 작동하는 소프트웨어 | 작 |
| ③ | 계약 협상 | < | 고객과의 협력 | 고 |
| ④ | 계획을 따르기 | < | 변화에 대응하기 | 변 |
🔑 암기 ★프작고변★ — 프(로세스)<개인 / 작(동SW)>문서 / 고(객협력)>계약 / 변(화대응)>계획. 4속성은 반복·점진·피드백·적응. ⚠️ 함정 ④번 왼쪽은 '계획 따르기'이지 '엄격한 문서화'가 아니다(②번이 이미 문서). '애자일은 왼쪽을 부정한다' ❌ → 원문은 '왼쪽도 가치 있지만 오른쪽을 더 중시'. '애자일은 문서를 전혀 안 쓴다' ❌ → 덜 중시일 뿐 작성은 한다. 🎯 빈출 4대 가치 원문 짝짓기, '해당하지 않는 것' 고르기. 2회에 1문제급. 📝 기출 기출 3 💡 12원칙 중 시험 단골은 고객 만족(최우선)·변경 환영(후반에도)·자주 전달(짧은 주기)·작동 SW가 진척도·단순성(YAGNI)·정기 회고 정도만 가볍게.
★폭프나V애★ 5종 비교 — 결정 키워드 자동 반응 ·빈출·
[표] SDLC 5종 한눈에
| # | 모델 | 핵심 키워드 | 적합 도메인(일반화) |
|---|---|---|---|
| ① | 폭포수 | 순차·단방향·비가역 | 공공·국방·대형 SI |
| ② | 프로토타입 | 시제품·피드백·폐기 전제 | UI/UX 검증 프로젝트 |
| ③ | 나선형 | Boehm 1988·위험 분석 | 대형 금융 차세대·국방 |
| ④ | V모델 | 테스트 짝 매칭 | 자율주행·의료기기·항공 |
| ⑤ | 애자일 | 반복·점진·피드백·적응 | B2C 서비스·금융 슈퍼앱 |
[표] 결정 포인트(키워드 → 정답)
| 보기에 나오면 | 정답 |
|---|---|
| 위험 분석 / Boehm / 1988 | 나선형 |
| 테스트 매칭 / 거울 / V자 | V모델 |
| 시제품 / 폐기 전제 / 피드백 후 본제품 | 프로토타입 |
🔑 암기 폭포수와 애자일은 양극단. 폭포수(절차 전형·변경 차단) ↔ 애자일(자유도·변경 환영) — 두 극 사이에 나머지 셋을 배치하면 위치 감각으로 정답이 잡힌다. 🎯 빈출 설명 → 모형 찾기가 이 단원 최다 출제 유형.
대단원 3 — 애자일 실천: 스크럼·XP·경량 방법론
스크럼(Scrum) — PO·SM·DevTeam 딱 3역할 ·빈출·
[정의] 스크럼 = 애자일을 현실에서 굴리는 대표 프레임워크. 럭비의 스크럼처럼 팀이 한 덩어리로 밀고 나간다.
[표] 3대 역할
| 역할 | 한 줄 정의 |
|---|---|
| PO(Product Owner) | '무엇을' 만들지 결정 — 우선순위·요구 책임 |
| SM(Scrum Master) | 프로세스 코치 — 장애물 제거·팀 보호(지휘자 아님) |
| DevTeam(개발팀) | '어떻게' 만들지 결정 — 보통 5~9명 자율 운영 |
[표] 5대 이벤트 + 백로그 2종
| 이벤트 | 주기 | 핵심 |
|---|---|---|
| 스프린트(Sprint) | 2~4주 | 본 작업 사이클 |
| 스프린트 계획(Planning) | 스프린트 시작 | 무엇을 할지 결정 |
| 데일리 스크럼(Daily) | 매일 | 15분 — 어제·오늘·장애물 공유 |
| 스프린트 리뷰(Review) | 스프린트 종료 | 산출물 시연·피드백 |
| 스프린트 회고(Retrospective) | 리뷰 후 | 프로세스 자체 개선 |
백로그 2종 — 제품 백로그(전체 우선순위 목록, PO 소유) / 스프린트 백로그(이번 스프린트에 할 작업, DevTeam 소유).
🔑 암기 3대 역할 = PO·SM·DevTeam 딱 3개. 스프린트 2~4주, 데일리 15분 숫자 고정. ⚠️ 함정 '프로젝트 매니저(PM)가 스크럼 3대 역할에 포함된다' ❌ → 스크럼엔 PM이 없다. PM은 전통(폭포수) 용어다. '위에서 내려찍는' 지휘 역할은 스크럼 자율 철학과 정반대. 🎯 빈출 3대 역할 '해당하지 않는 것'(PM 함정), 이벤트 주기(데일리 15분). 단골. 📝 기출 기출 4
XP(eXtreme Programming) ★의단피용존★ — 소규모·빠른 피드백 ·간헐·
[정의] XP = Kent Beck이 1999년 제안한 극단적 프로그래밍 방법론. 소규모 팀과 빠른 피드백을 강조한다.
[표] 5대 가치 ★의단피용존★
| 가치 | 의미 |
|---|---|
| 의사소통(Communication) | 팀·고객 간 즉시 대화 |
| 단순성(Simplicity) | YAGNI — 필요한 것만 만들기 |
| 피드백(Feedback) | 빠른 피드백 루프 |
| 용기(Courage) | 두려움 없이 리팩토링·변경 |
| 존중(Respect) | 팀원·고객 존중 |
[표] 5대 실천법(Practices)
| 실천법 | 한 줄 |
|---|---|
| Pair Programming | 두 명이 한 화면에서 코딩(드라이버·내비게이터) |
| TDD | 테스트 코드 먼저 → 본 코드 |
| Refactoring | 외부 동작 유지 + 내부 구조 개선 |
| CI(지속적 통합) | 자주 통합·자주 빌드 |
| Small Release | 작은 단위로 자주 배포 |
🔑 암기 ★의단피용존★ — 의(사소통)·단(순성)·피(드백)·용(기)·존(중). 1과목 3강(UML과 애자일)에서 본 것과 같은 암기법이다. 실천법은 Pair·TDD·Refactoring·CI·Small Release. ⚠️ 함정 'XP는 장기·대형 프로젝트에 적합하다' ❌ → 핵심은 소규모·빠른 피드백이라 단기·소규모가 본령이다. 장기·대형은 스크럼·SAFe 같은 큰 프레임워크 영역. 🎯 빈출 5실천법 키워드(Pair·TDD·Refactoring·CI), 5가치. 간헐.
칸반·Lean·FDD·DSDM·Crystal — 경량 방법론 키워드 ·간헐·
🌟 빈칸·짝짓기로 간헐 출제 — 키워드 하나씩만 외워두면 충분하다.
[표] 경량 방법론 5종
| 방법론 | 핵심 키워드 | 시그니처 |
|---|---|---|
| 칸반(Kanban) | WIP 제한·Pull·시각화 | 진행 중 작업 수 상한, 보드 시각화 |
| Lean(린) | 낭비 제거·가치 흐름 | 생산 방식의 SW 적용 |
| FDD | 기능(Feature) 중심 | Feature-Driven Development |
| DSDM | 타임박스·80/20 | Dynamic Systems Development Method |
| Crystal | 팀 크기·중요도별 가변 | Cockburn — 팀별 맞춤 |
🔑 암기 WIP·시각화·Pull=칸반 / 낭비 제거=Lean / 기능 중심=FDD / 타임박스·80/20=DSDM / Cockburn·팀별 맞춤=Crystal. 🎯 빈출 키워드 → 방법론 짝짓기. 한 방법론만 쓰는 게 아니라 혼합 운영이 현실 — 이게 곧 테일러링의 본령이다.
대단원 4 — 개발 방법론과 테일러링
개발 방법론 — 4구성요소와 5대 분류 ★구정객컴애★ ·빈출·
[정의] SW 개발 방법론(Methodology) = SDLC 단계를 구체적인 절차·기법·산출물·도구로 정형화한 체계적 개발 방식. SDLC 모델보다 한 단계 더 큰 틀이다.
[표] 4구성요소(김밥 비유)
| 구성요소 | 정의 | 비유 |
|---|---|---|
| 절차(Procedure) | 어떤 순서로 진행하나 | 김밥 마는 순서 |
| 기법(Technique) | 어떻게 구체적으로 하나 | 재료 자르는 칼질 |
| 산출물(Deliverable) | 무엇을 결과로 남기나 | 완성된 김밥 |
| 도구(Tool) | 무엇으로 지원하나 | 김발·도마·칼 |
[표] 5대 분류 ★구정객컴애★ (역사 발전순)
| 방법론 | 시기 | 중심 | 대표 기법 |
|---|---|---|---|
| 구조적 | 1970s | 프로세스(기능) | DFD·Pseudo Code |
| 정보공학 | 1980s | 데이터 | ERD·DA |
| 객체지향 | 1990s | 객체 | UML·캡슐화·상속·다형성 |
| CBD(컴포넌트) | 2000s | 재사용 컴포넌트 | EJB·COM·CORBA |
| 애자일 | 2001~ | 반복·변화 대응 | Scrum·XP·Kanban |
🔑 암기 4구성요소 = 절차·기법·산출물·도구. 5대 분류 ★구정객컴애★ — 구(조적70s)·정(보공학80s)·객(체지향90s)·컴(포넌트CBD 00s)·애(자일01~). 중심이 기능→데이터→객체→컴포넌트→변화로 진화했다. ⚠️ 함정 '방법론 구성요소는 절차·도구 2가지' ❌ → 4가지다. '네트워크·프로그래밍·데이터베이스 방법론' 같은 이름은 ❌ → 진짜 5대 분류는 구조적·정보공학·객체지향·CBD·애자일뿐. 🎯 빈출 4구성요소 빈칸, 5대 분류 '아닌 것' 고르기(가짜 이름 함정). 단골. 📝 기출 기출 7 💡 CBD·제품선(Product Line)처럼 재사용 중심 방법론도 출제 보기로 등장 — 둘 다 '재사용' 키워드로 묶어 두면 된다.
테일러링(Tailoring) — 방법론을 프로젝트에 맞춰 고친다 ·빈출·
[정의] 테일러링 = 프로젝트 상황·특성에 맞게 표준 SW 개발 방법론의 절차·기법·산출물·도구를 수정·보완·조정하는 작업. Tailor(양복 재단사)처럼 기성복(표준 방법론)을 프로젝트 몸에 맞게 고쳐 입는 것이다.
[표] 내부 기준 ★목요규기★ vs 외부 기준 ★법납이기★
| 내부(통제 가능) ★목요규기★ | 외부(통제 불가) ★법납이기★ |
|---|---|
| 목표 — 프로젝트 목적·범위 | 법·규제 — 법적 요구·산업 표준 |
| 요구사항 — 명확도·복잡도 | 납품 일정 — 계약상 마일스톤 |
| 규모 — 인력·예산·기간 | 이해관계자 — 발주처·감독기관 |
| 기술환경 — 기술 스택·플랫폼 | 기술 트렌드 — 외부 신기술 압력 |
🔑 암기 내부 ★목요규기★(목표·요구·규모·기술환경) = 회사가 통제 가능 / 외부 ★법납이기★(법·납품·이해관계자·기술트렌드) = 회사 의지로 못 바꿈. ⚠️ 함정 '법·규제는 내부 기준' ❌ → 외부다. '테일러링은 시작 전 1회만 수행' ❌ → 진행 중에도 환경 변화에 맞춰 지속적으로 조정한다. 🎯 빈출 정의 → 용어 찾기(리팩토링·리엔지니어링·역공학과 구분), 내부/외부 기준 구분. 이 단원 최대 빈출. 📝 기출 기출 5
테일러링 5단계 ★목환기상검★ — SDLC 5단계와 헷갈리지 말 것 ·빈출·
[정의] 테일러링 절차 = 방법론을 프로젝트에 맞게 조정하는 5단계. SDLC 5단계(SW를 만드는 과정)와 층위가 다르다.
[표] ★목환기상검★ 5단계
| # | 두음 | 단계 | 내용 |
|---|---|---|---|
| ① | 목 | 목표 정의 | 프로젝트 목적·범위 명확화 |
| ② | 환 | 환경 분석 | 내부·외부 기준 파악 |
| ③ | 기 | 기준 수립 | 무엇을 조정할지 기준 설정 |
| ④ | 상 | 상세 수행 | 절차·기법·산출물·도구 실제 수정 |
| ⑤ | 검 | 검토·조정 | 결과 검토 후 지속 보완 |
🔑 암기 ★목환기상검★ — 목(표)→환(경)→기(준)→상(세)→검(토). SDLC가 '집 짓는 순서'면, 테일러링은 '집 짓는 방식을 우리 땅에 맞게 고치는 순서'. ⚠️ 함정 '테일러링 첫 단계는 환경 분석' ❌ → 첫 단계는 목표 정의(목)다. 또 ★목환기상검★(절차 5단계)과 ★목요규기★(내부 기준 4축)를 섞지 말 것 — 둘 다 '목'·'기'로 시작하지만 절차 vs 기준으로 층위가 다르다. 🎯 빈출 5단계 순서·빈칸 짝짓기. 단골. 📝 기출 기출 8
대단원 5 — 프레임워크와 라이브러리
프레임워크 vs 라이브러리 — 제어권은 누구에게?(IoC) ·빈출·
[정의] 프레임워크(Framework) = 공통 기능을 미리 만들어 둔 반제품 구조. 개발자는 정해진 규칙에 따라 빈 곳만 채워 완성한다(레고 블록 세트). 4특징 = 모듈화·재사용성·확장성·제어의 역전(IoC).
[표] 라이브러리 vs 프레임워크 — 결정자는 제어권(IoC)
| 구분 | 라이브러리 | 프레임워크 |
|---|---|---|
| 제어권 | 내가 호출 | 프레임워크가 내 코드를 호출 |
| 호출 방향 | 내 코드 → 라이브러리 | 프레임워크 → 내 코드 |
| 비유 | 공구상자에서 꺼내 씀 | 컨베이어 벨트 위에 올라탐 |
| 자유도 | 높음 | 낮음(규칙 강제) |
| 예 | Lodash·jQuery·NumPy | Spring·Django·React |
🔑 암기 ★IoC=제어의 역전★ — 라이브러리=내가 호출 / 프레임워크=프레임워크가 내 코드 호출. 시그니처 한 줄은 할리우드 원칙 "Don't call us, we'll call you"(우리가 부를 테니 기다려라). ⚠️ 함정 '프레임워크는 개발자가 필요할 때 호출해 쓴다' ❌ → 그건 라이브러리다. 프레임워크=IoC=프레임워크가 호출. 라이브러리/프레임워크 바꿔치기 함정 단골. 🎯 빈출 틀린 설명 고르기(제어권 방향), 라이브러리/프레임워크 구분. 시험·면접 둘 다 최다 단골. 📝 기출 기출 6 💡 IoC(제어의 역전) = 객체의 생성·생명주기·호출 제어권을 개발자가 아닌 프레임워크/컨테이너가 가져가는 것.
전자정부 표준프레임워크 + Spring 4특징 ·간헐·
[정의] 전자정부 표준프레임워크 = 대한민국 행정안전부가 공공 정보화 사업 품질 향상을 위해 배포하는 Spring 기반 오픈소스 표준 개발 프레임워크.
[표] 핵심 사실
| 항목 | 내용 |
|---|---|
| 주관 기관 | 행정안전부(표준프레임워크 센터 운영·NIA 협력) |
| 기술 기반 | Java·Spring(최신 버전은 Spring Boot 기반으로 전환) |
| 라이선스 | 오픈소스(Apache License 2.0) |
| 적용 | 공공기관 정보화 사업 의무 적용 |
| 목적 | 품질 향상·생산성 ↑·중복 개발 방지 |
[표] Spring Framework 4대 특징
| 특징 | 한 줄 |
|---|---|
| IoC/DI | 객체 생성·의존성 주입을 Spring이 관리 |
| AOP | 공통 기능(로깅·트랜잭션)을 핵심 로직과 분리 |
| POJO | 순수 Java 객체로 개발 |
| MVC | 웹 3계층 구조 표준 지원 |
🔑 암기 기반 기술 = Spring / 주관 기관 = 행정안전부 / 라이선스 = Apache 2.0. 이 세 줄이면 한 문제 그대로. ⚠️ 함정 '전자정부 표준프레임워크는 ASP.NET 기반' ❌ → Java·Spring 기반이다. 🎯 빈출 기반 기술·주관 기관 묻기, Spring 4특징(IoC/DI·AOP·POJO·MVC). 간헐.
기출 다지기
[기출 1 출제] 다음이 설명하는 소프트웨어 생명주기(SDLC) 모형은? (설명 → 용어)
Barry Boehm이 1988년 제안한 모형으로, 개발 과정의 위험을 최소화하기 위해 각 반복마다 위험 분석 단계를 거치며 점진적으로 개발한다.
- ① 폭포수 모형
- ② 프로토타입 모형
- ③ 나선형 모형
- ④ V모형
정답 및 해설 보기
정답: ③ 나선형 모형(Spiral Model)
| 보기 | 판정 | 해설 |
|---|---|---|
| ① 폭포수 | ❌ | 순차·단방향 — 위험 분석 단계 없음 |
| ② 프로토타입 | ❌ | 시제품 기반 요구 수렴 — 위험 분석 아님 |
| ③ 나선형 | ✅ | Boehm(1988), 4단계(계획·위험 분석·개발·평가) 점진 반복 |
| ④ V모형 | ❌ | 폭포수 확장 — 테스트 짝 매칭이 핵심(위험 분석 ❌) |
🔑 암기 ★위험분석=나선형★ — 'Boehm'·'1988'·'위험 분석' 셋 중 하나만 보여도 나선형 확정.
[기출 2 출제] 폭포수(Waterfall) 모형의 특징으로 옳지 않은 것은? (옳지 않은 것 고르기)
- ① 각 개발 단계가 순차적으로 진행된다
- ② 각 단계의 산출물이 명확하다
- ③ 요구사항 변경에 유연하게 대응할 수 있다
- ④ 단계별 검증 후 다음 단계로 진입한다
정답 및 해설 보기
정답: ③ 요구사항 변경에 유연하게 대응할 수 있다
| 보기 | 판정 | 해설 |
|---|---|---|
| ① | ❌(옳음) | 순차·단방향 진행 |
| ② | ❌(옳음) | 요구서·설계서 등 산출물 명확 |
| ③ | ✅(틀림) | 폭포수는 단방향·비가역이라 변경 대응에 취약 |
| ④ | ❌(옳음) | 각 단계 검토·승인 후 다음 단계 진입 |
🔑 암기 '폭포수' + '유연' = 100% 오답. 변경에 강한 모델은 애자일·프로토타입·나선형.
[기출 3 출제] 애자일 선언문(Agile Manifesto)의 4대 가치에 해당하지 않는 것은? (해당하지 않는 것 고르기)
- ① 프로세스와 도구보다 개인과 상호작용을
- ② 포괄적인 문서보다 작동하는 소프트웨어를
- ③ 계약 협상보다 고객과의 협력을
- ④ 엄격한 문서화보다 변화에 대응하기를
정답 및 해설 보기
정답: ④ (표현 왜곡 — 원문은 '계획 따르기보다 변화에 대응하기')
| 보기 | 판정 | 해설 |
|---|---|---|
| ① | ❌(옳음) | 프(로세스) < 개인과 상호작용 |
| ② | ❌(옳음) | 작(동 SW) > 포괄적인 문서 |
| ③ | ❌(옳음) | 고(객 협력) > 계약 협상 |
| ④ | ✅(틀림) | ④번 왼쪽은 '계획 따르기'이지 '엄격한 문서화'가 아님 |
🔑 암기 ★프작고변★ — 변(화 대응)은 '계획'과 짝. ②번이 이미 '문서'라 ④를 또 문서화로 쓰면 중복 함정.
[기출 4 출제] 스크럼(Scrum)의 3대 역할(Role)에 해당하지 않는 것은? (해당하지 않는 것 고르기)
- ① 프로덕트 오너(Product Owner)
- ② 스크럼 마스터(Scrum Master)
- ③ 프로젝트 매니저(Project Manager)
- ④ 개발팀(Development Team)
정답 및 해설 보기
정답: ③ 프로젝트 매니저(Project Manager)
| 보기 | 판정 | 해설 |
|---|---|---|
| ① PO | ❌(역할 맞음) | '무엇을' 만들지 결정 |
| ② SM | ❌(역할 맞음) | 프로세스 코치 |
| ③ PM | ✅(아닌 것) | 전통(폭포수) 용어 — 스크럼엔 없음 |
| ④ DevTeam | ❌(역할 맞음) | '어떻게' 만들지 결정 |
🔑 암기 스크럼 3대 역할 = PO·SM·DevTeam 딱 3개. PM이 보이면 즉시 X.
[기출 5 출제] 다음이 설명하는 용어는? (설명 → 용어)
프로젝트 상황·특성에 맞게 기존 SW 개발 방법론의 절차·기법·산출물·도구를 수정·보완·조정하는 작업
- ① 리팩토링(Refactoring)
- ② 테일러링(Tailoring)
- ③ 리엔지니어링(Reengineering)
- ④ 역공학(Reverse Engineering)
정답 및 해설 보기
정답: ② 테일러링(Tailoring)
| 보기 | 판정 | 해설 |
|---|---|---|
| ① 리팩토링 | ❌ | 외부 동작 유지 + 내부 구조 개선(코드 차원) |
| ② 테일러링 | ✅ | 방법론을 프로젝트에 맞게 조정·수정·보완 |
| ③ 리엔지니어링 | ❌ | 기존 시스템을 재분석·재설계 |
| ④ 역공학 | ❌ | 결과물에서 거꾸로 설계 도출 |
🔑 암기 '방법론' + '절차·기법' + '수정·보완·조정' = 테일러링. 코드 구조 개선이면 리팩토링.
[기출 6 출제] 소프트웨어 프레임워크(Framework)에 대한 설명으로 틀린 것은? (틀린 설명 고르기)
- ① 재사용 가능한 공통 기능을 제공하는 반제품 소프트웨어 구조이다
- ② 개발자는 정해진 규칙에 따라 확장·커스터마이징할 수 있다
- ③ 제어권이 개발자에게 있어 필요할 때 호출해 사용한다
- ④ 대표적으로 Spring, Django, React 등이 있다
정답 및 해설 보기
정답: ③ 제어권이 개발자에게 있어 필요할 때 호출해 사용한다
| 보기 | 판정 | 해설 |
|---|---|---|
| ① | ❌(옳음) | 반제품 구조 |
| ② | ❌(옳음) | 확장·커스터마이징 가능 |
| ③ | ✅(틀림) | 제어권은 프레임워크가 가짐 — IoC(제어의 역전) |
| ④ | ❌(옳음) | 모두 대표 프레임워크 |
🔑 암기 라이브러리=내가 호출 / 프레임워크=프레임워크가 내 코드 호출. 시그니처 'Don't call us, we'll call you'(할리우드 원칙).
[기출 7 출제] 소프트웨어 개발 방법론의 분류로 적절하지 않은 것은? (적절하지 않은 것 고르기)
- ① 구조적 방법론
- ② 정보공학 방법론
- ③ 객체지향 방법론
- ④ 네트워크 방법론
정답 및 해설 보기
정답: ④ 네트워크 방법론
| 보기 | 판정 | 해설 |
|---|---|---|
| ① 구조적 | ❌(분류 맞음) | 1970s 프로세스 중심 |
| ② 정보공학 | ❌(분류 맞음) | 1980s 데이터 중심 |
| ③ 객체지향 | ❌(분류 맞음) | 1990s 객체 중심 |
| ④ 네트워크 | ✅(아닌 것) | 정식 분류가 아닌 가짜 이름 |
🔑 암기 ★구정객컴애★ — 구조적·정보공학·객체지향·CBD·애자일 5개만 진짜. 네트워크·프로그래밍·DB·디버깅 방법론은 모두 가짜.
[기출 8 출제] 테일러링(Tailoring) 수행 절차를 순서대로 바르게 나열한 것은? (순서 나열)
- ① 환경 분석 → 목표 정의 → 기준 수립 → 상세 수행 → 검토·조정
- ② 목표 정의 → 환경 분석 → 기준 수립 → 상세 수행 → 검토·조정
- ③ 목표 정의 → 기준 수립 → 환경 분석 → 검토·조정 → 상세 수행
- ④ 기준 수립 → 목표 정의 → 환경 분석 → 상세 수행 → 검토·조정
정답 및 해설 보기
정답: ② 목표 정의 → 환경 분석 → 기준 수립 → 상세 수행 → 검토·조정
| 보기 | 판정 | 해설 |
|---|---|---|
| ① | ❌ | 첫 단계가 환경 분석 — 목표 정의가 먼저 |
| ② | ✅ | ★목환기상검★ 정확한 순서 |
| ③ | ❌ | 환경 분석과 기준 수립 순서가 뒤바뀜 |
| ④ | ❌ | 기준 수립이 첫 단계로 옴 |
🔑 암기 ★목환기상검★ — 목(표)→환(경)→기(준)→상(세)→검(토). 목적부터 정해야 환경 분석 기준이 잡힌다. ★목요규기★(내부 기준 4축)와 혼동 금지.
한 장 요약
4대 축 한눈에
| 축 | 핵심 | 두음 |
|---|---|---|
| SDLC 모델 | 개발 순서의 큰 틀 | ★폭프나V애★(위험 분석=나선) |
| 애자일 | 변화 대응 철학 | ★프작고변★ + 스크럼(PO·SM·DevTeam) + XP(★의단피용존★) |
| 방법론 | 절차+기법+산출물+도구 / 역사순 5분류 | ★구정객컴애★ |
| 테일러링 | 프로젝트 맞춤화 | 내부 ★목요규기★ · 외부 ★법납이기★ / 절차 ★목환기상검★ |
| 프레임워크 | 반제품 위에 올라타기 | ★IoC=제어의 역전★(할리우드 원칙) |
핵심 매칭 — 즉답
| 질문 | 즉답 |
|---|---|
| 위험 분석·Boehm·1988 | 나선형 |
| 테스트 짝 매칭·V자 거울 | V모델 |
| 시제품·폐기 전제·피드백 후 본제품 | 프로토타입 |
| 순차·단방향·비가역 | 폭포수 |
| 스크럼 3대 역할 | PO·SM·DevTeam(PM ❌) |
| 데일리 스크럼 주기 | 매일 15분 |
| 애자일 4대 가치 두음 | ★프작고변★ |
| XP 5대 가치 두음 | ★의단피용존★ |
| 방법론 5대 분류 두음 | ★구정객컴애★ |
| 테일러링 정의(방법론 수정·조정) | 테일러링 |
| 테일러링 5단계 절차 | ★목환기상검★ |
| 테일러링 내부 / 외부 기준 | ★목요규기★ / ★법납이기★ |
| 프레임워크 vs 라이브러리 결정자 | 제어권(IoC) |
| 전자정부 표준프레임워크 기반 / 주관 | Spring / 행정안전부 |
핵심 함정 6선 (모두 X — 보기에 나오면 오답)
| 오답 ❌ | 정답 ✅ |
|---|---|
| 폭포수는 변경에 유연하다 | 단방향·비가역(변경 취약) |
| V모델은 위험 분석을 포함한다 | 위험 분석=나선형(Boehm 1988) |
| 애자일은 문서를 전혀 안 쓴다 | 덜 중시일 뿐 작성은 함 |
| 스크럼 3대 역할에 PM이 있다 | PO·SM·DevTeam 3개뿐 |
| 프레임워크는 개발자가 호출한다 | 그건 라이브러리(IoC=프레임워크가 호출) |
| 테일러링은 시작 전 1회만 수행 | 진행 중에도 지속 조정 |
연결 지도: 47~53강이 정보보호('무엇으로 지키나')를 닫았다면, 54강은 무대를 'SW를 어떻게 만드나'로 옮겨 SW공학 영역의 첫 깃발을 꽂는다. SDLC 모델(★폭프나V애★)로 큰 틀을 잡고 → 방법론(역사순 ★구정객컴애★)으로 정형화하고 → 테일러링(★목환기상검★)으로 프로젝트에 맞추고 → 프레임워크(IoC)라는 반제품 위에 올린다. 다음 55강은 이 방법론으로 짠 프로젝트의 '비용과 일정을 어떻게 계산하나' — COCOMO·기능점수(FP)·임계 경로의 계산형 단원으로 이어진다.
54강 한 문장: "SDLC 큰 틀은 ★폭프나V애★(위험 분석=나선형), 애자일은 ★프작고변★ + 스크럼(PO·SM·DevTeam) + XP(★의단피용존★), 방법론 5분류는 역사순 ★구정객컴애★, 테일러링은 내부 ★목요규기★ · 외부 ★법납이기★ · 절차 ★목환기상검★, 프레임워크는 ★IoC=제어의 역전★(할리우드 원칙)으로 잡는다."
