DevOps

개념 시스템 개발자와 시스템 운영자의 협업과 자동화를 강조하는 개발 방법론

특징 개발 운영 협업 자동화

DevOps를 통해 소프트웨어 개발,배포,릴리즈 속도 향상 가능

개념도

설계 개발 빌드 테스트 배포 릴리즈 모니터링 피드백 (앞에 4개 CI, 뒤 4개 CD)

CI, CD가 순환하며 개발이 이루어짐

구성요소

품질 품질 기준: 정적 분석, 테스트 통과율 테스트 자동화: 자동화된 테스트로 빠른 검증

프로세스 지속적 배포: 운영 서버 반영 자동화 릴리즈와 배포의 구분: 변경사항 전달 시점 유연화

도구 지속적 통합: 형상관리 도구 활용 배포 자동화: 배포 스크립트를 통한 빠른 배포

DevOps는 품질, 프로세스, 도구라는 기준으로 나눠볼 수 있음

DevOps의 고려사항

인력

개발,운영간 화합
협업 문화

보안

빠른 배포 → 리스크 업
DevSecOps 관점 필요

비용

신규 도구 도입
클라우드 비용 업
장점을 취하고 한계를 보완하는 DevOps 도입 과정 필요

소프트웨어 안전성 분석 기법

FHA (Functional Hazard Analysis, 기능위험분석)
시스템이 아직 구체적인 설계나 구성요소로 분해되기 전, 개념/요구분석 단계에서 시스템이 수행해야 할 기능을 나열하고 각 기능이 상실되거나 오작동했을 때 발생할 수 있는 위험과 심각도를 평가하는 기법입니다. 설계에 대한 편견 없이 순수하게 “무엇을 하는 시스템인가” 관점에서 위험을 도출하기 때문에 안전분석 절차에서 가장 이른 시점에 수행되며, 그 결과가 이후 FTA나 FMEA 같은 세부 분석의 입력(시스템 수준 위험목록)이 됩니다.

PHA (Preliminary Hazard Analysis, 예비위험분석)
요구분석 단계에서 시스템/구성요소 수준의 잠재적 위험원을 초기에 식별하고 대략적인 심각도와 발생가능성을 평가하는 기법으로, 이후 정밀분석(FTA, FMEA 등)의 대상과 우선순위를 정하는 스크리닝 역할을 합니다. FHA가 기능 단위 관점이라면 PHA는 시스템/구성요소 단위 관점이라는 차이가 있으며, 두 기법은 상호보완적으로 함께 쓰이는 경우가 많습니다.

HAZOP (Hazard and Operability Study, 위험성 및 운전성 분석)
No, More, Less, Reverse, As well as 등 정해진 가이드워드를 프로세스나 설계의 각 요소에 체계적으로 적용해, 정상 운전조건에서 벗어나는 편차(Deviation)와 그로 인한 위험을 빠짐없이 탐색하는 기법입니다. 브레인스토밍에 가까운 팀 기반 검토 방식이라 분석가의 직관에 의존하지 않고 누락 없이 위험을 찾아낼 수 있다는 장점이 있지만, 대상 시스템이 크면 소요 시간이 많이 든다는 단점이 있습니다.

FTA (Fault Tree Analysis, 결함수분석)
최상위 사고(Top Event)를 먼저 정의한 뒤, AND/OR 게이트를 이용해 그 사고를 유발할 수 있는 하위 원인들을 트리 구조로 역추적해 나가는 하향식(Top-down) 기법입니다. 기본사건(Basic Event)에 발생확률을 부여하면 Top Event의 발생확률을 정량적으로 산출할 수 있어, 여러 원인이 복합적으로 결합해 사고를 유발하는 경우를 분석하는 데 강점이 있습니다.

FMEA (Failure Mode and Effects Analysis, 고장모드영향분석)
개별 구성요소가 어떤 방식으로 고장 날 수 있는지(고장모드)를 먼저 나열하고, 그 고장이 상위 시스템에 미치는 영향을 추적해 나가는 상향식(Bottom-up) 기법입니다. 심각도(S)·발생도(O)·검출도(D)를 곱한 RPN(Risk Priority Number)으로 개선 우선순위를 정량적으로 매길 수 있어 표 형태로 체계적인 문서화가 가능하지만, 여러 고장모드가 동시에 발생하는 복합적 상황을 분석하는 데는 한계가 있습니다.

SFMEA (Software Failure Modes and Effects Analysis, 소프트웨어 고장모드영향분석)
하드웨어용 FMEA를 소프트웨어 영역으로 확장한 기법으로, 소프트웨어는 물리적으로 마모되지 않는다는 특성 때문에 고장모드를 열화·부식 같은 물리적 메커니즘이 아니라 논리 오류, 예외 미처리, 타이밍/동기화 오류, 자료형 오버플로우 같은 설계적·논리적 결함으로 재정의해 모듈·함수·인터페이스 단위로 분석합니다. 주로 구현/시험 단계에서 적용되며, FTA로 시스템 수준 위험을 좁혀놓은 뒤 그 하위 구성요소를 SFMEA로 점검하는 방식으로 상호보완적으로 쓰입니다.

STPA (System-Theoretic Process Analysis, 시스템이론 프로세스 분석)
사고를 개별 구성요소의 고장이 아니라 시스템 전체의 부적절한 제어(Inadequate Control)의 결과로 보는 STAMP 이론에 기반한 기법으로, 제어자-액추에이터-제어대상 프로세스-센서로 이어지는 제어루프를 모델링한 뒤 각 제어행위가 언제·왜 불안전해지는지(Unsafe Control Action)를 분석합니다. 소프트웨어·인적·조직적 요인까지 포괄해서 분석할 수 있어 자율주행차나 항공 자동화처럼 소프트웨어 집약적이고 복잡한 시스템에 특히 적합하며, 요구분석부터 운영까지 전 생명주기에 걸쳐 제어구조를 지속적으로 갱신하며 적용된다는 점이 다른 기법들과 다릅니다.

객체지향 방법론에서의 캡슐화

종결어: 기법
키워드: 데이터, 연산, 객체, 상태 감춤, 접근지정자, 정보은닉, 메시지, 소통, 결합, 인터페이스
목적: 응집도 증가

구성도

클래스 다이어그램 2개, 화살표에 메시지 전송

객체지향 방법론에서의 추상화

종결어: 기법
키워드: 공통 속성, 추출, 단순화, 세부사항 제거, 핵심 속성과 행위만 표현
목적: 복잡성 은닉

구성도

Shape, Triangle, Rect. 트리 형태. getArea() 메서드

객체지향 방법론에서의 다형성

종결어: 기법
키워드: 업캐스팅, 오버라이딩, 오버로딩, 동적바인딩, 가상함수테이블, 상속다형성, 인터페이스다형성
목적: 재사용성, 확장성

개념: 하나의 메시지에 다양한 객체가 응답할 수 있는 기법

구성도

Animal 상위클래스/인터페이스 move() 메서드, Cat Dog Bird 구현
업캐스팅. Animal a = new Cat(); a.move();

객체지향 방법론에서의 정보은닉

종결어: 기법
키워드: 접근제어자, 내부 속성, 외부 접근 차단, private protected public, getter setter, 캡슐화 관련
목적: 결합도 감소

개념: 접근제어자를 사용해 객체의 상태를 외부에 숨기는 기법

구성도

Rectangular 클래스 다이어그램 1개. private 속성 width, height와 public getArea() 하나

객체지향 방법론에서의 상속

종결어: 기법
키워드: 클래스 재사용, 부모클래스, 자식클래스, 오버로딩, 오버라이딩, 다형성 관련, 추상클래스, 단일 상속, 다중 상속
목적: 계층적 분류 체계 형성, 재사용성

개념: 클래스들의 계층적 분류 체계를 형성하기 위해 기존 클래스를 재사용해 새로운 클래스를 구현하는 기법

구성도

       [Super Class]
        속성 + 메서드
             │
      extends│(상속)
             │
        [Sub Class]
   상속받은 속성/메서드
        + 신규/재정의 요소
             │
      ┌──────┴──────┐
   [단일상속]     [다중상속*]
   (Java,C#)    (C++, *인터페이스로 대체)

형상관리

두음: 식통감기
종결어: 기법
키워드: 산출물, 체계적 관리, 품질 향상, 형상 식별, 형상 통제, 형상 감사, 형상 기록, 저장소, CCB, 변경 허용, 변경 심사, 형상관리 도구, SVN, Git, 베이스라인
목적: 무결성과 추적성 확보를 위해 산출물의 변화를 체계적으로 관리

구성도

형상 식별                CCB
형상 통제   -> 저장소 <-  CR(Change Request)
형상 감사               변경 심사
형상 기록               변경 허용

git, svn등

소스코드 뿐만 아니라 기획서, 설계 문서, 테스트 등이 모두 형상에 포함됨

DevOps, CI/CD: 형상관리 자동화가 확장된 현대적 실천 방식

형상관리 기준선(Baseline)

두음: 기할제
종결어: 상태
키워드: 특정 시점, 검토, 승인, 공식적, CCB 검토, 기능 기준선, 할당 기준선, 제품 기준선, 형상 감사, 형상항목식별자
목적: 변경통제의 기준점 확보

개념: 변경 통제의 기준점을 확보하기 위해 공식적으로 승인된 형상의 상태

구성도

요구사항 → [기능기준선]
              ↓
설계    → [할당기준선]
              ↓
구현/시험 → [제품기준선]
              ↓
        (변경시 CCB 승인 → 갱신)

기능→할당→제품 3단계, 변경은 CCB 승인 후 갱신

증분형 개발 모델

종결어: 개발 방식
키워드: 범위 분할, 병렬적 개발, 개발 후 통합, 점진적 통합, 요구사항 분할, 전체 아키텍처, 증분 단위, 반복 주기, 점진적 통합, 회귀 테스트, 형상관리, 위험관리
목적: 가치를 조기에 전달하기 위해 명확한 요구사항을 기반으로 범위를 나누어 개발하고 통합하는 방식
요구사항이 명확한 프로젝트에서 사용 가능
분할을 잘못하면 통합시 큰 비용 발생

구성도

[요구사항 분석]→[전체 아키텍처 설계]  
├→[증분1: 설계-구현-테스트-인도]  
├→[증분2: 설계-구현-테스트-통합]  
└→[증분N: 설계-구현-테스트-통합]→[전체 시스템 완성]

아키텍처 고정 후 기능 순차 증분

구성요소

구분	구성요소	설명
계획	요구사항 분할	기능단위 우선순위 분류
계획	전체 아키텍처	증분 수용 골격 설계
실행	증분 단위	독립 개발·테스트 단위
실행	반복 주기	증분별 개발 사이클
통합	점진적 통합	기존 시스템에 순차 결합
통합	회귀 테스트	통합시 기존기능 검증

계획·실행·통합 3단계 반복구조

증분형 개발 모델을 사용하면 병렬 개발이 가능하지만 필수는 아님. 가치를 조기에 전달하기 위해 중요도가 높은 기능부터 범위를 분할해 개발함.

진화형 개발모델

종결어: 개발 방식
키워드: 반복적, 프로토타입, 요구사항 불명확, 최종 시스템, 형상관리, 위험관리
목적: 초기 요구사항이 불명확한 프로젝트의 핵심 기능부터 개발하고 피드백을 받아 개선하는 개발 방식

구성도

요구사항 분석, 설계, 구현, 테스트, 피드백
위 단계들의 순환
각 반복마다 요구사항 구체화 및 기능 확장
간글: 반복적 개발-평가 순환으로 시스템 완성

구분	구성요소	설명
프로세스	반복 개발	단계별 기능 점증 개발
프로세스	고객 피드백	매 반복 평가·수정 반영
산출물	프로토타입	반복별 실행 가능 버전
산출물	최종 시스템	반복 누적된 완성본
관리	형상관리	버전별 변경이력 관리
관리	위험관리	반복초기 고위험 식별

프로세스·산출물·관리 3범주로 구성

요구공학의 요구사항 개발

요구공학은 ‘요구사항 개발’과 ‘요구사항 관리’로 나뉨.

두음: 추분명검
종결어: 활동
키워드: 요구사항 추출, 요구사항 분석, 요구사항 명세화, 요구사항 검증, SRS 문서, 도출기법, 분석기법, 명세 산출물, 확인 검증, 기능, 비기능, 반복적, 점진적
목적: 요구사항을 확정하기 위해 이해관계자로부터 요구사항을 추출하고 분석, 명세화, 검증하는 활동

구성도

[요구도출]→[요구분석]→[요구명세(SRS 작성)]→[요구확인(SRS 확정)]→(변경관리 피드백)  
↑__________________________________________|

4단계 순차 진행, 변경시 재귀환

구분	구성요소	설명
도출기법	인터뷰	이해관계자 직접면담
도출기법	워크숍/브레인스토밍	집단 아이디어 수집
분석기법	요구사항 분류	기능·비기능 구분
분석기법	우선순위 결정	중요도·긴급도 평가
명세산출물	SRS 명세서	요구사항 표준문서화
확인검증	요구사항 검토·승인	완전성·일관성 확인

도출·분석·명세·확인 4범주로 구성

요구공학의 요구사항 관리

형상관리와 유사함

두음: 협기변검
종결어: 활동
키워드: 협상, 기준선 관리, 변경 관리, 검증, 요구사항 일관성, 추적성 확보, 변경 통제, 형상 항목
목적: 이해관계자의 변경되는 요구사항을 산출물에 일관성 있게 반영하고 추적성을 확보하는 활동

구성도

[협상]→[기준선 관리]→[변경 관리]→[검증]→(피드백, 협상/변경 재유입)

확정→고정→통제→확인 순환구조

구분	구성요소	설명
협상	Win-Win협상	이해관계자 상충조정
협상	우선순위기법	MoSCoW 등 순위화
기준선관리	형상항목(CI)	버전관리 대상 식별
기준선관리	CCB승인	공식 기준선 확정
변경관리	변경요청(CR)	수정 공식절차
변경관리	영향분석	비용·일정·범위 분석
검증	추적성매트릭스	요구-산출물 매핑
검증	리뷰/테스트	충족여부 확인

협상·기준선·변경·검증 4범주 구성

폭포수 개발방법론

종결어: 개발 모델
키워드: 전통적, 순차적, 후행없음, 요구사항 수집, 분석, 아키텍처 설계, 시스템 설계, 구현, 배포, 유지보수, 단계별 산출물
목적: 전통적 소프트웨어 개발 방법론으로서 각 단계를 순차적으로 후행없이 진행하는 개발 방법론

구성도

순서대로 우하향. 순차적 진행과 후행이 없다는 것을 구성도에 표기

구분	구성요소	설명
상위단계	요구분석	사용자 요구사항 정의
상위단계	설계	시스템·SW 구조 설계
개발단계	구현	코딩 및 단위개발
개발단계	시험	통합·시스템 테스트
운영단계	배포	실환경 설치 및 이관
운영단계	유지보수	결함수정·기능개선

상위·개발·운영 3단계로 구분

애자일 개발방법론

종결어: 개발 모델
키워드: 짧은 주기, 설계 구현 검증 피드백 반복, 백로그(프로덕트, 스프린트), 스프린트, 번다운차트, 데일리 스크럼 미팅, 프로덕트 오너, 스크럼 마스터
목적: 소규모 개발팀이 짧은 주기 동안 설계,구현,검증을 반복하며 고객에게 가치를 전달하는 개발 모델

구성도

프로덕트 백로그 → 스프린트 백로그 → 설계 구현 테스트 → 배포 및 피드백 수집 → 회고 → 다시 스프린트 백로그 순환

구분	구성요소	설명
프로세스	스프린트	1~4주 단위 개발주기
프로세스	데일리스크럼	매일 진행상황 공유
산출물	제품백로그	요구사항 우선순위 목록
산출물	스프린트백로그	해당주기 작업목록
역할	스크럼마스터	프로세스 촉진·장애제거
역할	프로덕트오너	요구사항 우선순위 결정

프로세스·산출물·역할 3범주 구성

모놀리식 아키텍처

종결어: 서비스 아키텍처
키워드: 하나, 통합된 소스코드, 단일 언어 사용, 수직 확장이 효율적, 수평 확장은 비효율적, 전통적 3계층 (표현, 비즈니스, 데이터 계층)
목적: 하나의 실행 단위에서 모든 기능을 제공하는 서비스 아키텍처

구성도

요청 → 서버 → 데이터베이스 각 1개

구분	구성요소	설명
계층구조	표현계층	UI·화면처리 담당
계층구조	비즈니스계층	핵심로직·트랜잭션 처리
계층구조	데이터계층	DB접근·영속성 관리
배포단위	단일실행파일	WAR/EXE 등 통합 패키징
배포단위	단일DB	전모듈 공유 데이터저장소
운영요소	스케일업	서버증설 방식 확장

모놀리식 아키텍처의 경우 주로 전통적 3계층 아키텍처를 사용

마이크로서비스 아키텍처

종결어: 서비스 아키텍처
키워드: 분할된 소스코드, 여러 언어 사용, 효율적인 수평 확장 가능, API Gateway, 서비스 디스커버리, REST/gRPC, 메시지 브로커, 서비스별 DB, 컨테이너 오케스트레이션, 서킷 브레이커
목적: 비즈니스 기능 단위로 서비스를 분리해서 제공하는 서비스 아키텍처

구성도

요청 → API Gateway → 앱 서버 2개 → 각각의 앱 서버에 DB

구분	구성요소	설명
접점계층	API 게이트웨이	단일 진입점 라우팅
접점계층	서비스 디스커버리	서비스 위치 동적 탐색
통신계층	REST/gRPC	서비스간 동기 통신
통신계층	메시지 브로커	비동기 이벤트 통신
데이터계층	서비스별 DB	데이터 소유권 분리
운영계층	컨테이너 오케스트레이션	배포·확장 자동관리

접점·통신·데이터·운영 4범주 구성

아키텍처 스타일(=아키텍처 패턴, 아키텍처 모델)

두음: 구통상, 계클마 파브이 모블인
종결어: 해결책
키워드: 아키텍처가 만족해야 할 품질 속성 달성, 반복적 일반적 문제 해결, 재사용
목적: 아키텍처가 만족해야 할 품질 속성을 달성하기 위한 반복적/일반적인 문제를 해결하는 검증된 해결책

TBD: 각 패턴의 다이어그램 정리

구성도

구조
1. 계층형
2. 클라이언트-서버
3. 마스터-슬레이브
통신/데이터 흐름
1. 파이프-필터
2. 브로커
3. 이벤트-버스
상호작용
1. 모델-뷰-컨트롤러
2. 블랙보드
3. 인터프리터

+a)

저장소 구조 (Repository)
MSA

‘소프트웨어 아키텍처 평가’ 토픽 추가

TODO: 아키텍처 설계 5단계 정리하기

요구사항 수집 → ?? → 4+1 View → 평가 → 프로토타입 → 배포

아키텍처는 5가지 그림을 그려줘야 함. 4+1 View

Use Case
Logical
Implementation
Process
Deployment

이 때 아키텍처 스타일이 필요함.

설계를 했으면 잘 됐는지 ‘평가’를 한다 → SAAM

아키텍처 평가 기법

두음:
종결어:
키워드: 품질 수준, 고수준 판단, 이해관계자 요구 반영, 시나리오 기반, 설계/혼합 기반
목적: 아키텍처가 요구되는 품질 수준을 충족하는지 아키텍처 수준에서 평가하는 기법

구성도

ADR과 ARID는 모듈/컴포넌트 상세 설계 적합성 검토 기법과 함께 사용

약어	원어(Full Name)	설명(10자 이내)
SAAM	Software Architecture Analysis Method	수정 용이성, 기능 분석
ATAM	Architecture Tradeoff Analysis Method	품질 속성 trade off 추가
EATAM	Extended ATAM	제품라인 가변성 확장평가
CBAM	Cost Benefit Analysis Method	경제적 평가 부분 보강 (경제적=비용 편익)
ADR	Architecture Decision Record	설계결정 기록문서
ARID	Active Reviews for Intermediate Designs (중간설계 능동적 검토)	아키텍처 일부를 초기에 평가

fyi) EATAM = ATAM + 변이점/가변성 분석 단계 → 단일 시스템이 아니라 제품군(패밀리) 전체를 대상으로 품질속성을 평가하는 확장 기법입니다.

아키텍처에 제품별 차이를 수용하기 위한 variation point를 정의하고, 각 variation point로부터 개별 제품을 적절히 파생할 수 있는지, 그리고 그 선택이 제품별 품질 속성과 품질 간 트레이드오프를 만족하는지를 평가하도록 ATAM을 확장한 것이 EATAM이다.

디자인 패턴

두음: 생구행
종결어: 해결책
키워드: 코드 수준, 반복, 설계 문제, 재사용, 검증된
목적: 코드 수준에서 반복되는 설계 문제에 대해 재사용 가능한 검증된 해결책

다 외울 필요는 없다.. 아래 정도만 정의 쓸 수 있게 적당히 외우기.

구성도

생성
1. 추상 팩토리
2. 팩토리 메서드
3. 빌더
4. 싱글톤
5. 프로토타입
구조
1. 어댑터
2. 프록시
3. 브릿지
4. Facade
5. Composite
6. Decorator
행위
1. 전략 패턴
2. 템플릿 메서드
3. 옵저버
4. 이터레이터
5. 비지터

허용적 라이선스

종결어: 오픈소스 라이선스
키워드: 파생저작물, 저작권 최소 제약, 라이센스 전파 의무 없음. 소스코드 비공개 가능, 확산/채택 극대화, MIT, Apache, BSD
목적: 파생저작물에 공개 의무가 없는 오픈소스 라이선스

구성도

[원저작물]→[사용/수정/재배포]→[저작권고지 유지]→[파생물 라이센스 자유선택]  
↳(카피레프트 미적용)

파생물에 원소스 공개 강제 없음

구분	구성요소	설명
라이센스 유형	MIT	최소조건, 고지문 유지
라이센스 유형	Apache 2.0	특허권 명시적 허여
라이센스 유형	BSD	3-Clause 무보증 명시
필수조건	저작권 고지	원저작자 표시 유지
필수조건	라이센스 사본 포함	배포시 원문 첨부
권리범위	상업적 이용	제한없이 판매·활용

MIT·Apache·BSD 대표 3유형, 고지의무만 부과

기업 활용도 높음

카피레프트 라이선스

두음:
종결어: 강약파 GLM
키워드: 파생저작물, 공개 의무, 전파성, 강도(강함, 약함, 파일단위)
목적: 파생저작물을 동일한 라이선스 공개해야 하는 오픈소스 라이선스

구성도

[원저작물]→(카피레프트 적용)→[배포/수정 허용]→[파생저작물]→(동일 라이선스 상속)→[재배포]

라이선스 조건이 파생물까지 전파

구분	구성요소	설명
강도별	강한 카피레프트(GPL)	파생물 전체 동일라이선스
강도별	약한 카피레프트(LGPL)	링크 라이브러리만 예외
강도별	파일단위(MPL)	수정파일만 공개의무
적용범위	소스코드 공개	배포시 소스 제공 의무
적용범위	상업적 이용 허용	영리목적 사용 가능
권리주체	저작자 권리 유지	저작권 자체는 보유

강도(GPL/LGPL/MPL)별 의무범위 상이

소프트웨어 안전성 분석 기법

두음:
종결어: 기술
키워드: 잠재적 위험 Hazard, 불확실성 Risk, 피해 Harm, 트리거, HAZOP 가이드워드. FTA 하향식, FMEA 상향식
목적: 소프트웨어로 발생할 수 있는 잠재적 위험을 식별하고 분석해서 제거·통제하는 기법

‘전통적’과 ‘최근’으로 크게 구분된다.

전통적 3총사, 하드웨어 중심

FTA, 트리 형태. 이벤트와 게이트(And, Or)
FMEA, 위험의 강도 측정할 때. 3가지 봄. 심발검 (심각도, 발생가능성, 검출 가능성)
HAZOP, 가이드워드

최근

STPA, (스탬프?)

구성도

요구분석
- FHA/PHA
- HAZOP
설계
- FTA
- FMEA
구현/테스트
- SFMEA
- 코드분석
운영
- 사고/변경 분석
- 재발방지

요구분석/설계 (정성적)

FHA: Functional Hazard Analysis, 기능위험분석
PHA: Preliminary Hazard Analysis, 예비위험분석
HAZOP: Hazard and Operability Study, 위험성 및 운전성 분석
- 가이드워드

설계 (정성적, 정량적)

FTA: Fault Tree Analysis, 결함수 분석
FMEA: Failure Mode and Effects Analysis, 고장모드 영향분석

구현/테스트

SFMEA: Software Failure Modes and Effects Analysis, 소프트웨어 고장모드 영향 분석

TODO: Hazard, Risk, Harm의 관계 정리. 3단락용

AOP(Aspect Oriented Programming)

종결어: 기법
키워드: 횡단 관심사, 핵심 관심사, 응집도, 재사용성, 중복 제거, OOP 보완 기법
목적: 횡단 관심사를 분리하여 응집도를 높이고 중복을 제거하는 OOP 보완 기법

구성도

방사형과 유사하게
가운데 AOP. 좌측은 ‘핵심 관심사’, 우측은 ‘횡단 관심사’
- 핵심 관심사 예시: 주문, 결제, 장바구니
- 횡단 관심사 예시: 보안, 인증, 로깅
핵심 관심사측에서 AOP로 오는 화살표, Joint Point
횡단 관심사 측에서 AOP로 오는 화살표, Advice
하단에는 Point Cut

구성도 좌측에 십자형으로 그리는게 낫나? 횡단, 핵심 관심사

구성요소

구분	구성요소	설명
관심사	핵심 관심사	핵심 비즈니스 로직
관심사	횡단 관심사	공통 부가 기능
프로그래밍 요소	Advice	횡단관심사 로직
프로그래밍 요소	Joint Point	적용 가능 지점
프로그래밍 요소	Point Cut	로직과 적용점 연결정보
프로그래밍 요소	Aspect	횡단관심사 모듈 (Advice + Point Cut)
프로그래밍 요소	Weaving	로직 결합 과정

3단락 AOP 구현방식 2가지 비교

Bytecode Weaving
- 컴파일,빌드,실행시 bytecode를 조작해 횡단 관심사 기능을 삽입
IoC 컨테이너 활용
- Proxy 객체를 활용하여 의존성 주입시 횡단 관심사 기능을 객체에 추가

객체지향 설계 원칙 5가지

두음: SOLID
종결어: 설계 원칙
키워드: 유지보수성, 재사용성, 응집도, 결합도
목적: 객체지향 패러다임에서 재사용성과 유지보수성을 높이기 위한 5가지 설계 원칙

구성도

[SRP]단일책임 → [OCP]개방폐쇄 → [LSP]리스코프치환
      ↓                              ↓
[ISP]인터페이스분리 ← ← ← ← [DIP]의존관계역전
        (상호보완적 설계원칙 5종)

5원칙 상호보완적 적용 구조

구성요소 5개 개념도 테이블 TBD: 다이어그램 추가

SRP
- 객체는 한가지 책임만 담당해야 함
- 다이어그램: Point → Point / Point Repository
OCP
- 클래스는 변경에는 닫혀있고 확장에는 열려있어야 함
- 다이어그램: OAuth → Google, Naver, Facebook
LSP
- 부모 클래스 대신 어떤 자식 클래스라도 대입 가능해야 함
- 다이어그램: Shape, Triangle, Rectangle
ISP
- 작은 단위로 인터페이스를 분리해야 함
- 다이어그램: Repository → QueryRepo, CommandRepo
DIP
- 구체 클래스가 아니라 인터페이스를 의존해야 함
- 다이어그램: List <<interface>> <- LinkedList, ArrayList

3단락

응집도와 결합도의 관점으로 본 객체지향 5원칙

응집도
- SRP, ISP
- 클래스,인터페이스 내부 응집 강화
결합도
- OCP, LSP, DIP
- 클래스 간 관계, 의존 구조 개선

휴리스틱에 의한 사용성 평가

두음: 상익 복일에 직효 핵명도
종결어: 기법
키워드: 사용성 원칙, 전문 평가자, 문제점 진단, 빠른 평가, 문제점 도출, 심각도 평가(0~4단계)
목적: 전문 평가자가 정립된 사용성 원칙을 기준으로 문제점을 진단하는 기법

구성도1

[평가계획]→[전문가 개별평가]→[휴리스틱 원칙 대조]→[문제점 도출]→[심각도 산정]→[통합 및 보고]

개별평가 후 결과취합 순차 구조

구성도2

사전 교육 -> 평가 수행 -> 심각도 판정 -> 결과 취합 -> 결과 보고

5단계 구성

원칙 10가지

상태 안내
익숙함
복구 가능성
일관성
에러 예방
직관성
효율성
핵심 정보
명확한 에러 문구
도움 서비스

구분	구성요소	설명
평가원칙	시스템상태 가시성	현재상태 사용자에 인지
평가원칙	오류방지 및 복구	오류예방·복구 지원
평가주체	사용성 전문가	3~5인 독립평가 수행
평가주체	진행촉진자	평가세션 조율·기록
평가결과	문제목록	발견된 사용성 결함
평가결과	심각도 등급	0~4단계 우선순위화

원칙·주체·결과 3범주로 구성

사용성 테스트

고객에게 물어보는 것.

대상자 찾아서 실행

두음: 탐평확비, 카페스
종결어: 기법
키워드: 실제 사용자, 제품 사용, 관찰/분석, 문제점/개선점, 탐색 테스트, 평가 테스트, 확인 테스트, 비교 테스트, 카드 소팅, 페이퍼 목업, 스크린 목업
목적: 실제 사용자가 제품을 사용하는 것을 관찰/분석해서 문제점/개선점을 발견하는 연구 기법

구성도

테스트 종류 4개 트리 형태, 탐평확비

구분	구성요소	설명
테스트 종류	탐색 테스트	문제점 발견 탐색
테스트 종류	평가 테스트	사용성 수준 평가
테스트 종류	확인 테스트	개선사항 검증
테스트 종류	비교 테스트	대안간 우열 비교
테스트 기법	카드 소팅	정보구조 분류
테스트 기법	페이퍼 목업	종이 시제품 테스트
테스트 기법	스크린 목업	화면 시제품 테스트

테스트 표준 ISO 29119

두음: 개테프도테키, 조관동, 명구경
종결어: 국제 표준
키워드: 계층화, 문서 표준화
목적: SW 개발 전 과정의 테스팅 프로세스 관련 국제 표준

구성도

Part1. 개념과 정의
Part2. 테스트 프로세스
Part3. 문서(Documentation)
Part4. 기법(Technique)
Part5. 키워드 기반 테스팅
연관표준: ISO 33063, 절차 평가용

2가 가운데에 있고 모든 파트와 ISO 33063에 화살표

구성요소

구분	구성요소	설명
프로세스	조직 테스트 프로세스	정책·전략 수립
프로세스	테스트 관리 프로세스	계획·모니터링·통제
프로세스	동적 테스트 프로세스	설계·실행·완료
기법	명세 기반	블랙박스 테스팅
기법	구조 기반	화이트박스 테스팅
기법	경험 기반	테스터 경험·직관 활용

프로세스·기법 2범주 구성

테스트 설계 기법 3가지: 명세(블랙박스), 구조(화이트박스), 경험기반

명세기반

불동경의상 유분페원오 구조기반
화제루 결구조 다변조 경험기반
탐색적 테스팅, 체크리스트, 특성 테스팅, 오류 추정, 분류 트리

ISO 25000 (SQuRE)

두음: 31024 요모관측평
종결어: 국제 표준
키워드: 요구사항, 품질 모델, 품질 관리, 품질 측정, 품질 평가
목적: SW 개발 공정 각 단계의 산출물의 품질을 측정하기 위한 국제 표준

구성도

구성요소

구분	구성요소	설명
2500n	품질관리부	표준군 전체 관리지침
2501n	품질모델부	품질특성 정의(25010)
2502n	품질측정부	품질측정지표 제공
2503n	품질요구부	요구사항 명세화
2504n	품질평가부	평가절차·방법 규정
품질	제품 품질	GS 인증
품질	프로세스 품질	PS 인증

관리·모델·측정·요구·평가 5분야

품질요소 2가지

제품 품질 → GS, Good Software
프로세스 품질 → SP, Software Process

인증 ‘제도’는 ‘법근거, 대상, 인증기준, 절차’ 4개가 나와야 함. 제도 공부할 때는 프레임워크처럼 이 4개로 공부하기

DevOps

종결어: 방법론
키워드: 적시 출시, 소통, 협업, 자동화, CI/CD, 순환, 형상관리, IaC, 신뢰성 엔지니어링
목적: 소프트웨어 적시 출시를 위해 개발과 운영의 소통, 협업, 자동화를 강조하는 개발 방법론

구성도

설계 → 구현 → 빌드 → 테스트
릴리즈 → 배포 → 운영 → 모니터링
옆으로 뉘운 8자로. 12시 시작해서 시계 반대방향. 좌측 Dev, 우측 Ops

구분	구성요소	설명
형상관리	코드 형상관리	- git등의 도구 도입
형상관리	지속적 통합	- 짧은 주기 Push
인프라	지속적 배포	- 자동화된 배포 시스템
인프라	IaC	- 인프라 형상관리
안전성	모니터링&로깅	- 에러 로그 알람 구성
안전성	신뢰성 엔지니어링	- DevOps 실천 방법론

DevOps 5가지 핵심 요소 CALMS

Culture: 개발/운영 협업 문화, 사일로 제거
Automation: 빌드, 테스트, 배포, 인프라 자동화
Lean: 낭비 제거, 작은 단위 반복 개선
Measurement: 지표 기반 모니터링/피드백
Sharing: 지식/책임 공유

3단락에 방사형으로 적어도 괜찮을듯?

회귀테스트 (Regression Test)

변경사항이 발생했을 때

사이드이펙트와 리플 이펙트를 확인하기 위함

두음: RS 올셀프점
종결어: 반복 시험
키워드: 사이드이펙트(부작용), 리플 이펙트(파급효과), 변경
목적: 소프트웨어에 변경이 발생했을 때 새로 발생하는 오류가 없는지 확인하는 반복 시험

구성도

구분	구성요소	설명
효과	사이드 이펙트	수정 시 오류 발생
효과	리플 이펙트	영향 파급 전파
테스트 종류	전체 테스트	전체 재실행
테스트 종류	선별적 테스트	연관 부분만 선별
테스트 종류	우선순위 테스트	위험도순 실행
테스트 종류	점진적 테스트	단계적 확대 실행

고려사항 (방사형)

개발 테스트 통합
테스트 자동화
테스트 축적
테스트 조직
개발 과정에서 수시로 자동화된 테스트 실행
작성된 테스트는 부작용/파급효과를 막는 자산이 됨
자동화하기 힘든 테스트를 수행하기 위한 전담 조직 필요

V-모델 (V-Model)

두음: 단통시인설
종결어: 개발 모델
키워드: 폭포수 확장, 단위, 통합, 시스템, 인수, 설치, 검증/확인 중심, 단계별 산출물, 추적성 확보
목적: 개발 단계와 테스트 종류를 1:1로 대응시켜 폭포수 모델을 확장한 개발 모델

구성도

요구분석 ────────────── 인수테스트
  \                        /
 시스템설계 ──────── 시스템테스트
    \                    /
  상세설계 ──────── 통합테스트
      \                /
     코딩 ────── 단위테스트

좌측 개발, 우측 테스트 V자 대응구조

구분	구성요소	설명
개발단계	요구분석/설계	좌측 하향식 개발과정
개발단계	상세설계/코딩	구현 직전 최종단계
테스트단계	단위/통합테스트	코드·모듈 검증
테스트단계	시스템/인수테스트	전체·사용자 검증
검증기법	정적/동적검증	산출물 리뷰·실행검증
검증기법	트레이서빌리티	요구-테스트 추적관리

개발·테스트·검증기법 3범주로 구성

3단락 다중 V-모델 (모프제)

점점 커지는 V자 3개
설계 구현 테스트
모델 검증, 프로토타입 검증, 제품 검증
규모가 크거나 반복/점증적으로 개발하는 프로젝트에 사용

화이트박스 테스트

두음: 화제루, 구결조 조변다
종결어: 테스트 기법
키워드: 개발자 관점, 내부 로직, 구조 기반
목적: 개발자 관점에서 내부 로직을 알고 수행하는 구조 기반 테스트 기법

구성도

구문 커버리지
- 모든 구문들이 최소 1번 이상 수행
결정 커버리지
- 전체 결정문이 참/거짓을 최소 1번 이상 수행
조건 커버리지
- 개별 조건문이 참/거짓을 최소 1번 이상 수행
조건/결정 커버리지
- 전체 조건과 개별 조건 모두 참/거짓을 갖도록 수행
변경조건/결정 커버리지
- 개별 조건이 독립적으로 전체 결정 결과를 바꾸도록 수행
다중 조건 커버리지
- 개별 조건들의 참/거짓이 가능한 모든 케이스로 수행

TODO: 커버리지 사례 정리, A와 B로

구성요소 테이블을

유형
설명
사례 3개 컬럼으로 적기

블랙박스 테스트

사용자 관점

두음: 불동경의상 유분페원오
종결어: 기법
키워드: 사용자 관점
목적: 사용자 관점에서 내부 로직을 모르고 수행하는 명세 기반 테스트 기법

구성도

동등 클래스 분할 기법
- 동일하게 처리되는 값들 중 대표값 1개 추출해서 테스트
경계값 분석
- 경계값과 인접값을 집중적으로 테스트
의사결정 테이블 테스팅
- 여러 조건의 조합에 따른 결과를 표로 정리하여 검증
상태 전이 테스팅
- 상태 전이를 다이어그램으로 표현해서 검증
유스케이스 테스팅
- 사용자 관점의 업무 시나리오 기반 테스트
분류 트리 기법
- 입력을 트리 구조로 분류하고 조합하여 테스트
페어와이즈 테스팅
- 모든 파라미터 쌍을 최소 1회 이상 테슽
원인-결과 그래프
- 입출력간 논리적 관계를 그래프로 표현
오류 예측 기법
- 테스터의 휴리스틱을 바탕으로 결함 발생 부위 예측

SW 분리발주 (상용SW 직접구매제도)

국내 제도 물어볼 때: 1. 법근거, 2. 대상, 3. 절차, 4. 예외

두음: 예외 기준 - 민통 현현현
종결어: 제도
키워드: SW 산업 겅쟁력, 상용 SW, 별도 발주
목적: SW 산업 경쟁력을 강화하기 위해 상용SW를 SI사업과 별도로 발주하는 제도

구성도

[발주기관] 
   ├─(직접계약)→ [상용SW 공급사]
   └─(별도발주)→ [IT서비스 사업자] → (SI 구축)
        ↑
   [조달청 종합쇼핑몰/디지털서비스몰] (등록·검증)
        ↑
   [대상판정: 사업규모+SW가격/쇼핑몰등록 요건]

발주기관이 SW·SI 이원화 계약 체결

법률: 소프트웨어 진흥법 제54조(국가기관등의 상용소프트웨어 구매) 지침(행정규칙): 소프트웨어사업 계약 및 관리감독에 관한 지침 제7조(직접구매 대상), 제8조(직접구매 제외) 대상: 1차 && 2차조건중 1개 이상 만족시

1차: 총 사업규모 3억원 이상
2차
- 1. 조달청 등록여부: 조달청 종합쇼핑몰 등록 SW
- 1. GS, CC, NEP, NET 인증 또는 국가정보원 검증·지정 SW로서 5천만원 이상인 경우 (동일 SW를 다량 구매해 5천만원을 초과하는 경우도 포함) 제외 기준
대상 사업: 민간투자형 SW사업
대상 SW
- 정보시스템 통합 불가능
- 현저한 사업비용 증가
- 현저한 사업기간 증가
- 현저하게 비효율적

절차 (개략 프로세스)

직접구매 대상 여부 판단: RFP 작성 단계에서 1차·2차 조건 검토
직접구매 대상 상용SW 구매계획 수립: 대상 품목·직접구매 여부·제외사유를 명시한 구매계획서 작성(발주기관 규정 별지서식)
제외사유 사전 검토 요청: 제외하고자 하는 SW가 있으면 사전 검토·소명 절차 진행
입찰공고 및 발주: SI사업과 SW구매를 분리 발주(경쟁입찰 또는 종합쇼핑몰 등을 통한 수의/카탈로그 구매)
BMT(성능시험) 실시: 경쟁입찰로 구매 시 BMT를 실시해 평가에 반영하되, 조달청 등록 제품은 BMT 생략 가능
계약·검수: 별도 계약 체결 후 SI사업자와의 연계·통합 관리

(BMT: BenchMark Test)

문제 풀이 시 자주 나오는 키워드 축으로 정리하면: 개념(구 분리발주) – 법적근거(진흥법 §54, 지침 §7·§8) – 대상(1차/2차 조건) – 제외기준(사업/SW) – 절차(판단→계획→검토→발주→BMT→계약) 순으로 구조를 기억해두면 서술형 답안 뼈대로 바로 활용할 수 있습니다.

fyi) 국내 SW 인증

구분	초점	소관 성격
GS(Good Software)	SW 품질 전반	소프트웨어산업 진흥법 계열
CC(Common Criteria)	보안성	국가정보원 계열 (보안SW 특화)
NEP (New Excellent Product)	신제품의 우수성	산업기술 인증 계열
NET (Net Excellent Technology)	신기술의 우수성	산업기술 인증 계열

SW 분할발주

법근거: 「행정기관 및 공공기관 정보시스템 구축·운영 지침」 제14조의4 — 분석·설계사업의 분할발주 허용

두음: 공기부
종결어: 방식
키워드: 사업 불확실성, 실패 위험, 정보시스템 구축 사업, 계약 나눔, 공정분할, 기능분할, 부품분할
목적: 사업 불확실성과 실패 위험을 줄이기 위해 정보시스템 구축 사업을 여러 계약으로 나누어 발주하는 방식

구성도

계획 수립 → 분할 전략 수립 → 발주 → 사업관리 → 인수 → 통합 및 종료. ⇒ 모양자 쓰기
(발주 → 사업관리 → 인수)를 분할공정별 반복

구성요소 테이블은 6단계 쓰기

테이블은 |#|단계|설명| 이렇게 3단으로

정보시스템 감리

두음: 예현시 (예비조사, 현장감시, 시정조치)
종결어: 제도
키워드: 제3자 관점, 전자정부법 제57조
목적: 정보시스템의 효율성 향상, 안전성 확보를 위해 제 3자적 관점에서 시스템을 독립적으로 점검/평가하는 활동

구성도

예비조사 → 현장감리 → 시정조치의 순차적 3단계

구성요소

예비조사
- 범위 확정
- 계획 수립
현장감리
- 문서 심사, 인터뷰
- 문제점 도출
시정조치
- 시정계획서 작성
- 사후관리 확인

구분	구성요소	설명
주체	감리법인	독립적 제3자 검증기관
주체	감리원	자격보유 전문인력
절차	감리계획수립	범위·기준 사전정의
절차	감리수행	현장점검·인터뷰·문서검토
산출물	감리보고서	문제점·개선사항 기술
산출물	시정조치계획	개선이행 계획 수립

법근거

전자정부법 제 57조

대상 (OR 조건임)

사업비
- 5억원 이상
특성
- 대국민 서비스
- 여러 행정기관등이 공동으로 구축
행정기관장의 필요성 판단

예외

구분	내용
제외 규정	사업비 1억 원 미만 소규모 + 비용 대비 효과 낮다고 인정 시
감리 생략	전자정부사업관리 위탁 수행 시, 사업비 5억 원 미만 또는 사업기간 5개월 미만이면 생략 가능
특수정보 관련(법 제57조제4항)	국방·외교·안보 등 국가안전보장 정보, 개인정보, 기밀성 높은 정보를 다루는 시스템은 별도 고려 대상

실무 판단 순서 (관계 정리)

사업비 5억 원 이상인지 먼저 확인 (가장 명확한 기준)
5억 원 미만이라도 시스템 특성(대국민서비스, 공동구축)에 해당하면 의무 대상 가능
판단 기준 시점은 예산 편성 단계가 원칙 (계약금액이 아닌 예산 기준)

절차

계획
수행
보고
사후관리

더 복잡한 절차 있겠지… 일단 이렇게 4단계로만 알고 넘어가자

PMO

두음: 기집사 (기획, 집행, 사후), 성변보 (성과, 변화, 보안)
종결어: 제도
키워드: 전자정부법 제 64조의 2, 사업 품질 향상, 발주자 관점, 사업 관리, 기술 지원
목적: 사업 품질 향상을 위해 발주자 관점에서 사업 관리를 수행하고 기술을 지원하는 제도

프로세스그룹 10개에서 성변보 추가

기획: 통합관리, 성과관리
집행: 10개 + 성변보 - 원가관리, 총 12개
사후: 통합관리, 성과관리, 변화관리

구성도

역삼각형 그리자. 꼭지점마다 ‘발주기관’, ‘PMO 사업자’, ‘PMO대상사업 수행자’, 역삼각형 가운데는 PMO
삼각형 선의 화살표 방향과 화살표 내용
- 발주기관 — (전자정부사업관리 위탁(PMO) 계약) ⇒ PMO 사업자
- 발주기관 — (관리/감독) ⇒ PMO대상사업 수행자
- PMO 사업자 — (사업관리/기술지원) ⇒ PMO대상사업 수행자

      발주기관                   PMO 사업자
      
      
      
                PMO대상사업
                  수행자

법근거

전자정부법 제 64조 2
전자정부법 시행령 제 78조 2 ~ 제 78조의 5

대상

의무 대상 없음
발주기관이 자체적으로 PMO 도입 여부를 결정함

절차 (기집사)

기획 단계
- 통합관리, 성과관리
집행 단계
- 통합관리, 범위관리, 일정관리, 품질관리, 자원 관리, 의사소통 관리, 위험 관리, 조달 관리, 이해관계자 관리, 성과관리, 변화관리, 보안관리
사후관리 단계
- 통합관리, 성과관리, 변화관리

3R

SDLC의 유지,관리 단계

역공학: 산출물 다시 만들어내기
재공학: >> 구조화 <<
재사용: 다른 프로젝트에 활용

리팩토링

가독성이 떨어지는 코드를 클린 코드로 바꾸는 과정

리팩토링 기법들 외우기.

SW규모산정 상향식 산정기법

‘규모산정’은 ‘SW규모산정’과 ‘HW규모산정’으로 바뀜.

SW 규모산정 → 개발비

SW 규모산정은 3가지 방식

상향식
하향식
수학적 방식 (상향식에 포함될 수 있음)

SW규모산정 하향식 산정기법

HW 규모산정

규모: 수참시

소프트웨어 결합도(Coupling)

자스제외공내

소프트웨어 응집도(Cohesion)

우논시절통순기

Explorer

19a4-기술사-SW공학

DevOps

소프트웨어 안전성 분석 기법

객체지향 방법론에서의 캡슐화

객체지향 방법론에서의 추상화

객체지향 방법론에서의 다형성

객체지향 방법론에서의 정보은닉

객체지향 방법론에서의 상속

형상관리

형상관리 기준선(Baseline)

증분형 개발 모델

진화형 개발모델

요구공학의 요구사항 개발

요구공학의 요구사항 관리

폭포수 개발방법론

애자일 개발방법론

모놀리식 아키텍처

마이크로서비스 아키텍처

아키텍처 스타일(=아키텍처 패턴, 아키텍처 모델)

아키텍처 평가 기법

디자인 패턴

허용적 라이선스

카피레프트 라이선스

소프트웨어 안전성 분석 기법

AOP(Aspect Oriented Programming)

객체지향 설계 원칙 5가지

휴리스틱에 의한 사용성 평가

사용성 테스트

테스트 표준 ISO 29119

ISO 25000 (SQuRE)

DevOps

회귀테스트 (Regression Test)

V-모델 (V-Model)

화이트박스 테스트

블랙박스 테스트

SW 분리발주 (상용SW 직접구매제도)

SW 분할발주

정보시스템 감리

PMO

3R

리팩토링

SW규모산정 상향식 산정기법

SW규모산정 하향식 산정기법

HW 규모산정

소프트웨어 결합도(Coupling)

소프트웨어 응집도(Cohesion)

로우코드 (Low Code)

노코드 (No code)

Graph View

Table of Contents

Backlinks