"professional-engineer" 태그로 연결된 295개 게시물개의 게시물이 있습니다.

데이터 저장 특성 개요​

데이터 저장 특성 개념​

• 웹 서비스와 인터넷 패러다임의 변화로 인해 데이터의 저장, 접근, 처리 기술의 발전

데이터 저장 방식 변화의 필요성​

• FS에서 인터넷의 등장으로 DB 공유, 웹3.0의 출현으로 탈중앙화와 소유의 개념을 가진 블록체인 구조에 정보 저장

파일, 데이터베이스, 블록체인 개념 및 비교​

파일, 데이터베이스, 블록체인 개념​

아래 그림

• FS: Inode -> block
• DB: Table, System Catalog
• BlockChain: hash based linked list block + merkle tree

파일, 데이터베이스, 블록체인 상세비교​

구분	파일	데이터베이스	블록체인
저장단위	파일	테이블	블록체인
저장위치	로컬	중앙 시스템	분산 시스템
저장속도	빠름	트랜잭션처리, 빠름	합의알고리즘, 느림
데이터 저장 방식	FS API	DDL, DML	합의 알고리즘
트랜잭션	없음	ACID 보장	합의 알고리즘으로 트랜잭션 처리
데이터 중복	단일 데이터	역정규화로 일부 허용	참여자 전체 중복 저장
종류	FAT, NFTS	RDBMS, NoSQL	Public, Private, Hybrid

블록체인 저장 방식의 문제점과 해결방안​

블록체인 저장 방식의 문제점​

• 탈중앙화, 확장성, 보안성 중 모두를 만족할 수 없는 블록체인 트릴레마 존재
• 합의 알고리즘 수행에 시간이 걸리므로, 실시간 웹 서비스에는 부적합

블록체인 저장 특성 문제 해결방안​

구분	내용	비고
레이어링	데이터와 처리계층의 분리로 확장성 향상	오프체인, 사이드체인
샤딩	데이터 불할 처리로 확장성 향상	체인네트워크 샤딩, 코디네이션
하이브리드	중앙집중과 탈중앙화의 절충점으로 신뢰성, 보안성, 실시간성 강화	RDBMS, 카프카 사용

• 블록체인 트릴레마와 실시간성 극복을 위해 데이터를 분리하여 처리

파일, 데이터베이스, 블록체인 적용방안​

파일	데이터베이스	블록체인
개인/기업 데이터저장	엔터프라이즈 어플리케이션	암호화폐
멀티미디어	웹 어플리케이션	공급망 관리
IPFS	빅데이터 분석	스마트 컨트랙트

오토스케일링 개념​

• 시스템 자원 매트릭을 모니터링하여 서버 사이즈를 자동으로 조절하는 기술
• 클라우드 컴퓨팅의 온디맨드 방식을 기반으로 자원 최적화, 고가용성, 온프레미스 대비 운영의 단순화를 위해 필요

오토스케일링의 구성​

Pod, 메트릭모니터링, 로드밸런서 이미지

구성요소​

구분	기능	설명
정책, 모니터링	메트릭 수집, 알람 전송	-
서버 이미지 배포	Scale-Out, Scale-In, 서버 프로비저닝	-
서비스 연결	Health-Check, 트래픽 제어	-

오토스케일링시 서버 추가까지 필요한 경우, Scale-Up이 비용절감의 효과를 가져올 수 있음.

비교​

스케쥴기반, 부하기반​

구분	스케쥴 기반 오토스케일링	부하 기반 오토스케일링
트리거	예약된 시간	트래픽
수치	예측 가능한 부하	실제 사용량 기반
장점	트래픽 증가 지연 방지	효율적인 리소스 사용량
단점	예측을 벗어날시 리소스 낭비, 부족	인스턴스 배포시간으로 인한 지연

Scale Up, Scale Out​

구분	Auto Scale Up	Auto Scale Out
추가리소스	CPU, Memory	인스턴스
장점	인스턴스, NW관리 없어 간단	높은 확장성, 인스턴스 장애 격리
단점	물리적 한계, 고비용, 시스템 다운타임	복잡한 NW구성, 세션 처리 등

성공포인트​

• maxUnavailable, maxSurge 적절히 조절
• scale down 으로 비용 절감

클라우드 컴퓨팅의 개념​

• 가상화 기술을 이용하여 사용자 필요시 인터넷을 통해서 서비스 형태로 IT자원을 제공하는 컴퓨팅 기법
• 서비스 책임범위, 인프라 소유권에 따라 다양한 모델 등장

클라우드 컴퓨팅 모델의 구성도, 구성요소, 비교​

클라우드 컴퓨팅 모델의 구성도​

클라우드 컴퓨팅 모델의 구성요소​

• 서비스 모델: 클라우드 자원의 제공 방식에 따른 분류

구분	내용	비고
IaaS	-	사용자 관리 책임
PaaS	-	공통 관리 책임
SaaS	-	제공자 관리 책임

• 배포 모델: 클라우드 자원 소유주체와 관리방식에 따른 분류

구분	내용	비고
Private	-	사용자 소유
Public	-	제공자 소유
Hybrid	-	혼합 모델

배포모델과 서비스모델 비교​

구분	배포모델	서비스모델
목적	지속 가능 서비스 기반	온디맨드 서비스
범위	클라우드 구성 환경	클라우드 서비스
접근	온프레미스와의 연결성	비용 절감

• 온프레미스 서비스의 구성 환경에 따라 배포모델을 선택하고, 비지니스 요구사항과 비용에 맞는 서비스모델을 선택.

클라우드 컴퓨팅 활성전략​

구분	내용	비고
배포모델	공공기관/지자체 민관협력형 클라우드	-
-	금융사 하이브리드 멀티 클라우드	-
서비스모델	CNCF Cloud Native App	-
-	K-PaaS	-

• 기업은 목적에 맞는 전략을 활용하여 적절한 모델을 선택.

클라우드 컴퓨팅 고려사항​

• 해당 국가의 법, 제도적 규제사항을 만족하기위한 소버린클라우드와 재난시 빠른 복구가 가능한 멀티클라우드 구축 고려

129

화이트박스, 블랙박스 테스트 개요​

화이트박스, 블랙박스 테스트 개념​

화이트박스, 블랙박스 테스트 배경​

• 테스트 V모델에서 요구사항/분석/설계/코딩 측면은 개발자 관점의 화이트박스 테스트로 Verification 하고,
• 단위/통합/시스템/사용자 테스트 측면은 사용자 관점의 블랙박스 테스트로 Validation 하게 설계 필요.

화이트박스, 블랙박스 테스트 개념도, 핵심요소, 적용방안​

화이트박스, 블랙박스 테스트 개념도​

• 내부구조를 파악하는지 여부에 따라 기법 변경

화이트박스, 블랙박스 테스트 핵심요소​

구분	화이트박스	블랙박스
테스트기반	소스코드, 제어흐름그래프	요구사항명세서, 유스케이스
테스트설계	문장커버리지, 결정커버리지, 조건커버리지, 경로커버리지	동등분할, 경계값 분석, 오류추정, 원인/결과 분석
테스트목표	코드의 정확성, 안정성, 완전성 검증	기능요구사항 충족여부, UX 및 시스템 동작 검증
테스트시점	개발 초기 단계	개발 후반 단계
테스트자동화	JUnit, Jest 등 단위테스트 프레임워크	Selenium, Playwright 등 UI테스트 프레임워크
장점	숨겨진 결함 발견 용이, 테스트 커버리지 향상	사용자 관점 검증, 비교적 쉬운 TC 설계
단점	높은 비용, 시간 소모, 코드 변경시 TC 수정 필요	숨겨진 결합 발견 어려움, 낮은 TC 커버리지

화이트박스, 블랙박스 테스트 적용방안​

구분	화이트박스	블랙박스
단위테스트	각 함수, 모듈 기능 검증	없음
통합테스트	모듈간 인터페이스 상호작용 검증	여러 모듈 통합 후 기능 검증
시스템테스트	없음	전체 시스템 기능, 성능 검증

테스트시 고려사항​

• 화이트박스와 블랙박스 테스트의 장점을 결합하여 제한적 내부 정보를 활용한 그레이박스 테스트 기법 고려

128

모듈화​

모듈화의 개념​

• 시스템을 분해하고 추상화하여 SW 성능을 향상시키거나, 시스템의 디버깅, 테스트, 통합 및 수정을 용이하도록 하는 SW 설계 기법

모듈화의 장점​

• 모듈 재사용성, 개발과 유지보수성
• 복잡성 감소
• 오류 파급효과 최소화
• 기능 분리가능, 인터페이스 단순화
• 낮은 결합도, 높은 응집도

응집도와 결합도 개요​

응집도와 결합도의 개념​

• 응집도: 하나의 모듈 내부의 처리요소 간 기능적 연관성을 측정하는 척도
• 결합도: 모듈 간의 관련성을 측정하는 척도

응집도와 결합도의 배경​

• 최근 MSA 적용에 따른 모듈화의 중요성이 증가되었고, MSA의 각 서비스 단위(컴포넌트)는 응집도가 높고 결합도가 낮게 구현되어야함.

응집도와 결합도 종류 및 설명​

응집도의 종류 및 설명​

우논시절통순기

종류	설명	응집도
기능적	모든 요소가 단일 기능 수행	높음
순차적	한 기능의 출력이 다른 기능의 입력으로 사용	▲
통신적	동일한 입출력 데이터로 다른 기능 수행	⎮
절차적	기능 요소가 반드시 특정 순서대로 실행	⎮
일시적	기능 요소가 모두 같은 시간에 실행	⎮
논리적	논리적으로 유사하나 관계가 밀접하지 않음	⎮
우연적	모듈 내 요소가 연관이 없음	낮음

• 가능한 높은 응집도를 추구하여 유지보수 용이성 확보
• 모듈 간 결합도는 최소화하여 각 모듈은 높은 응집도 확보
• Co-incidental -> Logical -> Temporal -> Procedural -> Communicational -> Sequential -> Functional

결합도의 종류 및 설명​

내공외제스자

종류	설명	결합도
자료	모듈 간 파라미터 전달	낮음
스탬프	모듈 간 자료구조 전달	⎮
제어	다른 모듈을 제어하기 위해 플래그 전송	⎮
외부	모듈이 SW외부 환경과 연관	⎮
공통	모듈들이 공통 데이터 참조	▼
내용	다른 모듈의 내부 데이터 변경	높음

• 모듈 상호간 낮은 결합도 추구
• 모듈 간 사이드 이펙트(리플 이펙트) 최소화
• Contents -> Common -> External -> Control -> Stamp -> Data

응집도, 결합도 적용방안​

구분	내용	비고
설계	시스템 모듈화, API통신	유지보수 용이성
개발	모듈간 인터페이스 단순화, 명확한 역할 분담	의존성 주입

모듈성을 높이기 위한 고려사항​

• 코드리뷰를 통해 개발단계에서의 의존성 문제, 인터페이스 불일치 등 저해요인 방지
• MSA 설계시 서비스 단위로 높은 응집도, 낮은 결합도를 갖게 설계

129

몽키테스트, 회귀테스트 개요​

몽키테스트와 회귀테스트 개념​

몽키테스트와 회귀테스트 배경​

• 애자일 개발 방법론 도입으로 소프트웨어의 잦은 변경으로 인하여 자동화되고 연속적인 테스트의 필요성이 증가.
• 기존 테스트로를 지속하면 살충제 패러독스가 발생하므로, 새로운 버그 발견을 위해 몽키테스트 실행.

몽키테스트와 회귀테스트 개념도, 구성요소​

몽키테스트와 회귀테스트의 개념도​

• 테스트케이스나 시나리오 없이 예측할 수 없는 방식으로 무작위 테스트

• 코드, 기능 변경 후 기존 기능이 정상적으로 동작하는지 테스트

몽키테스트와 회귀테스트 구성요소​

구분	몽키테스트	회귀테스트
목적	예기치 못한 버그 발견	기존 기능 동작 확인
방식	무작위 입력, 스트레스, 랜덤 클릭	기존 테스트케이스 재실행
시기	주로 시스템테스트 단계	통합, 시스템, 인수테스트 변경시
완료	오류 미검출	사이드이펙트 수정 완료
장점	예상치 못한 행동 시뮬레이션	SW안정성 유지
단점	재현 어려움, 비일관성	살충제 패러독스

통합테스트 계획시 포함할 주요사항​

• 시스템 목적, 범위
• 대상시스템 구조
• 테스트 자원, 일정
• 시작 및 종료 조건
• 테스트 시나리오
• 테스트 방법 및 절차 교육

130

데이터옵스, 데브옵스 개념​

• 데이터옵스: 데이터 분석/관리 프로세스에 DevOps 원칙을 적용하여 분석 처리의 효율성을 높이는 방법론
• 데브옵스: 개발과 운영을 통합하여 SW개발주기를 단축하고 품질을 향상시키는 방법론
• 데이터 요구사항, 비지니스 요구사항에 실시간으로 대응하기 위해 필요성 대두

데이터옵스, 데브옵스 개념도, 구성요소, 적용방안​

데이터옵스, 데브옵스 개념도​

데이터옵스, 데브옵스의 구성요소​

구분	데이터옵스	데브옵스
목표	데이터 파이프라인 자동화	개발, 배포, 운영 자동화
프로세스	데이터 수집, 저장, 처리, 분석, 시각화, 품질관리	계획, 개발, 빌드, 테스트, 배포, 운영, 모니터링
조직	데이터엔지니어, 데이터과학자, 데이터분석가, DBA	개발자, QA엔지니어, 보안엔지니어, 시스템엔지니어
도구	Apache Airflow, Spark	Jenkins, GitLab
협업	기업 전체 데이터 관련 부서	IT부서
기대효과	스토리지, 워크플로우, 데이터파이프라인 최적화	짧은 개발주기, 지속적 통합, 배포

데이터옵스의 추가적인 고려사항​

• AI를 활용하는 MLOps로까지 확장하여, 데이터 기반의 의사결정을 더 빠르게 가져갈 수 있음.

131

소프트웨어 안정성 분석 개요​

• 각 개발 수명주기에서 안전 보증, 확인 활동 수행
• SW시스템의 오류, 장애, 실패를 예방하고, 위험을 회피, 전가, 감수, 수용하기 위해 시스템 위험요소를 식별하고 평가하는 과정.
• IoT와 안전필수시스템(자율주행, UAM 등)의 기능적 사고로 인한 인명피해방지를 위해 필요

소프트웨어 안정성 분석 주요 기법​

FTA, Fault Tree Analysis​

• 시스템 주요 실패 이벤트를 트리구조롤 분석하여 원인 규명
• Top-Down 방식
• 분석범위의 정의 및 분석수준의 결정 -> 대상제품의 특성 파악 -> 정상사상 정의 -> 결함수의 구성 -> 결함트리의 정성적 분석 -> 결함트리의 정량적 분석 -> 분석결과의 평가 및 보고

FMEA, Failure Mode and Effects Analysis​

• 분석 과제 정의 및 분석 준비 -> 분석 실시 -> 분석 결과의 정리 및 심층 분석

HAZOP, Hazard and Operability study​

• 목적 및 분석범위 설정 -> 분석팀 구성 -> 예비조사 -> 브레인스토밍 -> 분석결과 기록

소프트웨어 안정성 분석시 고려사항​

• ISO 26262 등 해당 산업의 규제 및 표준을 준수하여 분석 수행

통합테스트 개요​

통합테스트 개념​

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트 방법

통합테스트 필요성​

• 시스템에서 일부 모듈만 새로 구축하는 경우 안정성을 위해 통합테스트 필요.
• 연결된 외부 모듈의 테스트 환경이 제공되지 않을 경우 상위 모듈이면 테스트 드라이버로 모킹, 하위 모듈이면 테스트 스텁으로 모킹.

통합테스트의 절차, 통합방식 비교​

통합테스트의 절차​

• 통합계획 수립시 통합 방식 결정
• 모듈 통합시 테스트 드라이버, 테스트 스텁 사용

통합테스트 비점진적 통합방식, 점진적 통합방식 비교​

구분	비점진적	점진적
개념	프로그램을 이루는 각 모듈을 하나로 통합하여 테스트 수행	완성모듈을 기존 모듈과 하나식 통합하면서 테스트 수행
종류	빅뱅테스트	하향식, 상향식, 샌드위치 테스트
장점	소규모 적합, 절차 간단	오류 발견용이, 오류시 직전 통합테스트 모듈 확인
단점	오류 및 원인파악 어려움	더미모듈, 테스트스텁, 테스트드라이버 개발 리소스 필요

점진적 통합을 위한 테스트 드라이버, 테스트 스텁 비교​

구분	테스트 드라이버	테스트 스텁
개념	하위모듈 호출, 상위모듈로 데이터 전달용 가상 모듈	하위모듈 기능 대체 가상 모듈
활용	하위모듈이 있으나 상위모듈 없는 경우, 상향식	상위모듈 있으나 하위모듈 없는 경우, 하향식
목적	하위 모듈 동작 검증	상위 모듈 동작 검증
예시	가입테스트시 인증서버 모듈	가입 페이지 없는 경우 기능 모방
-	서버 가상모듈 제작	클라이언트 가상 모듈 제작

통합테스트 고려사항​

• 일관된 기준 데이터를 각 스테이지별로 두어 데이터 정합성으로 인한 테스트 이슈 방지

129

리팩토링 개요​

리팩토링 개념​

• 외부적 기능은 수정하지 않고, 내부를 단순화하여 유지보수성을 향상시키는 기법

리팩토링 필요성​

• 애자일 개발 방법론의 도입으로 TDD를 기반으로 코드스멜을 제거하기 위한 리팩토링의 중요성이 강조됨.

리팩토링의 개념도, 세부절차, 적용방안​

리팩토링의 개념도​

리팩토링의 세부절차​

구분	내용	비고
리팩토링 대상선정	코드스멜을 통해 개선 필요 코드 선정	중복 코드, 긴 메소드명 등
테스트코드 작성	로직의 기대결과를 테스트로 작성	TDD
리팩토링	리팩토링 후 코드스멜 발생시 반복	메소드 분리 등

리팩토링의 적용방안​

구분	내용	비고
결합도 측면	이동	패키지 재구성, 메소드 이동
-	분리	기능 분리 별도 클래스화, 인터페이스 분리
응집도 측면	일반화	중복 메소드 제거
-	통합	공통 필드 수퍼 클래스 통합
가독성 측면	재명명	목적과 이름이 다른 경우
-	주석	테스트코드만으로 설명할 수 없는 경우

리팩토링시 고려사항​

• sonarlint, eslint 등 정적분석 도구를 활용하여 가독성, 복잡도 등 코드스멜 감지 및 수정 자동화