본문으로 건너뛰기

속독 방법

· 약 4분

개요

  • 어렸을 때 어디선가 속독 책을 봤는데 기호가 난무하고 암호가 즐비한 책인 줄 알았다.
  • 한 번 봐도 큰 효과는 없길래 사기구나 싶었다.
  • "당신도 지금보다 10배 빨리 책을 읽는다"란 책 후기에 넘어가 도전해보려고 한다.

기준

단어 수 기준으로는 이렇다.

  • 일반인: 600자/분
  • 명문대학생: 1,500자/분
  • 따라읽기의 한계치: 3,000자/분
  • 속독: 10,000자/분

방법

완벽하게 하려고하지 않는다. 속으로 따라읽지 않는다. 머리나 몸은 고정한다.

빠르게 보기

  • 가로, 세로, 횡대각, 종대각
    • 눈에서 15~20cm 거리에 둔다.
    • 각 점을 따라 0.5초 이내의 속도 간격으로 눈동자를 크게 움직인다.
    • 1에서 10까지 10에서 1까지 돌아온다.
    • 각각 30초씩 반복한다.
    • 시선을 크고 빠르게 움직이는 것을 의식한다.
  • 원 운동
    • 눈에서 15~20cm 거리에 둔다.
    • 원 한 바퀴를 왕복하는데 10초 정도로 천천히 시선을 움직인다.
    • 원 운동을 3번 반복한다.
  • 기호 2점
    • 눈 가까이 가지고 올 필요는 없다.
    • 좌우의 점만을 교대로 응시한다.
    • 가능한 빠르게 60초 동안 본다.
  • 문자 2점
    • 눈 가까이 가지고 올 필요는 없다.
    • 좌우의 점만을 교대로 응시한다.
    • 가능한 빠르게 60~90초 동안 본다.

능동 시야, 수동 시야 늘리기

  • 단계
    • 1단계: 10단어씩 끊어서 그 시야 폭의 가운데를 본다.
    • 2단계: 능동시야를 1행으로, 수동시야를 3행으로 늘린다. 똑같이 문장의 가운데를 본다.
    • 3단계: 능동시야를 3행으로, 수동시야를 5행으로 늘린다. 속독의 시작.
  • 시야폭 늘리기
    • 눈에서 15~20cm 거리에 둔다. 마지막 사각형이 수동시야에 들어올듯 말듯한 거리
    • 작은 사각형에서 큰 사각형으로 본다. 큰 사각형까지 봤으면 다시 작은 사각형에서 시작한다.
    • 하나의 사각형을 0.5초 간격으로 본다.
    • 90~180초 동안 반복한다.

요약

  • 따라 읽지 않고, 글자를 더엉리로 보며 이해하는 연습을 꾸준히 하는 것
  • 시야 (수동시야)를 넓혀 한 번에 인식할 수 있는 양을 큰 폭으로 늘리는 것
  • 전자책은 수동시야에 다음 단락이나 문장이 보이지 않으므로 속독에는 비적합
  • 정독으로도 이해 못하는 내용은 속독으로도 이해 못한다.

화이트박스, 블랙박스 테스트

· 약 4분

129

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

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

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

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

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

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

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

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

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

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

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

테스트시 고려사항

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

모듈화, 응집도, 결합도

· 약 4분

128

모듈화

모듈화의 개념

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

모듈화의 장점

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

응집도와 결합도 개요

응집도와 결합도의 개념

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

응집도와 결합도의 배경

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

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

응집도의 종류 및 설명

우논시절통순기

종류설명응집도
능적모든 요소가 단일 기능 수행높음
차적한 기능의 출력이 다른 기능의 입력으로 사용
신적동일한 입출력 데이터로 다른 기능 수행
차적기능 요소가 반드시 특정 순서대로 실행
기능 요소가 모두 같은 시간에 실행
리적논리적으로 유사하나 관계가 밀접하지 않음
연적모듈 내 요소가 연관이 없음낮음
  • 가능한 높은 응집도를 추구하여 유지보수 용이성 확보
  • 모듈 간 결합도는 최소화하여 각 모듈은 높은 응집도 확보
  • Co-incidental -> Logical -> Temporal -> Procedural -> Communicational -> Sequential -> Functional

결합도의 종류 및 설명

내공외제스자

종류설명결합도
모듈 간 파라미터 전달낮음
탬프모듈 간 자료구조 전달
다른 모듈을 제어하기 위해 플래그 전송
모듈이 SW외부 환경과 연관
모듈들이 공통 데이터 참조
다른 모듈의 내부 데이터 변경높음
  • 모듈 상호간 낮은 결합도 추구
  • 모듈 간 사이드 이펙트(리플 이펙트) 최소화
  • Contents -> Common -> External -> Control -> Stamp -> Data

응집도, 결합도 적용방안

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

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

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

몽키테스트, 회귀테스트

· 약 3분

129

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

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

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

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

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

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

  • 테스트케이스나 시나리오 없이 예측할 수 없는 방식으로 무작위 테스트
  • 코드, 기능 변경 후 기존 기능이 정상적으로 동작하는지 테스트

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

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

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

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

데이터옵스, 데브옵스

· 약 3분

130

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

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

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

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

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

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

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

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

소프트웨어 안정성 분석

· 약 4분

131

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

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

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

FTA, Fault Tree Analysis

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

FMEA, Failure Mode and Effects Analysis

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

HAZOP, Hazard and Operability study

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

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

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

통합테스트

· 약 4분

131/3/3

통합테스트 개요

통합테스트 개념

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

통합테스트 필요성

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

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

통합테스트의 절차

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

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

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

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

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

통합테스트 고려사항

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

리팩토링

· 약 2분

129

리팩토링 개요

리팩토링 개념

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

리팩토링 필요성

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

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

리팩토링의 개념도

리팩토링의 세부절차

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

리팩토링의 적용방안

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

리팩토링시 고려사항

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

아키텍처 스타일, 디자인 패턴 비교

· 약 4분

131

아키텍처스타일과 디자인패턴의 개념

  • 아키텍처스타일: SW를 구성하는 서브시스템, 컴포넌트 간 관계를 분리하는 시스템 구조 스타일
  • 디자인패턴: SW개발 과정에서 발견된 설계의 노하우를 재사용하기 좋은 형태로 정리한 패턴

아키텍처스타일, 디자인패턴의 관계도, 주요 유형

아키텍처스타일, 디자인패턴의 관계도

아키텍처스타일의 주요 유형

구분내용비고
Layered Architecture소프트웨어를 계층으로 나누어 각 계층이 특정 기능을 담당하며 상위 계층이 하위 계층에 의존하는 구조MVC 패턴
Client-Server요청-응답 구조, 주로 네트워크 기반 애플리케이션에서 사용웹 애플리케이션
Microservices독립적으로 배포 가능한 작은 서비스들로 구성된 아키텍처로, 각 서비스는 특정 비즈니스 기능을 담당대규모 시스템에
Event-Driven시스템 구성 요소가 이벤트를 발생시키고, 이벤트를 수신하여 처리하는 구조실시간 처리
SOA서비스 단위로 시스템을 구성, 각 서비스는 명확하게 정의된 인터페이스로 통신재사용, 유연성 향상
Serverless요청시 CSP가 자동으로 서버 자원을 할당하고 실행하는 구조AWS Lambda 등
Reactive비동기 데이터 스트림을 사용하여 변화에 빠르게 반응하는 시스템을 구성고성능 실시간 시스템
Pipeline데이터가 여러 단계를 거쳐 처리되는 구조로, 각 단계는 독립적으로 작동하고 데이터를 변환ETL 프로세스 등
Broker클라이언트와 서버가 직접 통신하지 않고 중개자를 통해 통신하는 구조메시지 큐
Peer-to-Peer모든 노드가 동등한 자격으로 통신하고 자원을 공유하는 구조분산 시스템

디자인패턴 주요 유형

구분개념비고
생성패턴객체의 생성방식 결정, 클래스 정의, 구조화, 캡슐화Factory, Builder, Singleton
구조패턴객체 조직화 방법 제시, 객체 구성에 확장성 추가Adaptor, Bridge, Decorator
행위패턴객체 행위를 조직화, 그룹화, 객체와 클래스 연동Strategy, Observer, Visiter, Template

아키텍처스타일, 디자인패턴 적용시 고려사항

  • CBAM, ATAM을 통해 적절한 아키텍처 스타일 선택
  • 디자인패턴이 적용되어있는 프레임워크 사용

CBAM, 비용편익분석 방법

· 약 4분

128

CBAM의 개요

CBAM의 개념

  • Cost Benefit Analysis Method
  • 시스템 아키텍처 의사결정에 있어 시스템 엔지니어와 이해관계자들이 잠재적 비용과 편익을 비교한 SW아키텍처 평가모델

CBAM의 배경

  • SAAM, ATAM의 기술적 측면만 고려한 평가에서 기존 아키텍처 평가 방법의 한계로 비용 측면까지 고려 필요.
    • SAAM: Software Architecture Analysis Method
    • ATAM: Architecture Trade-off Analysis Method

CBAM의 구성도, 세부절차, 활용방안

CBAM의 구성도

  • 비용대비 편익 고려하여 최종 의사결정

CBAM의 세부절차

단계설명예시
목표설정아키텍처 목표 설정프로젝트 기대 성과
비용 추정아키텍처 구현 및 유지 비용 추정리소스, 시간, 노력
편익 추정예상되는 이익 추정기능개선, 비용절감, 성능향상

CBAM의 활용방안

분야설명활용예시
공공공공의 이익을 최대화하기 위한 정책 결정 지원인프라 프로젝트, 사회 서비스 개선 프로젝트
금융투자의 장기적 수익성과 리스크 평가를 위해 사용투자 은행에서의 대규모 투자 프로젝트 평가
민간비용 대비 이익 분석을 통해 사업의 경제적 타당성 확인기업에서의 신제품 개발 또는 사업 확장 결정

CBAM과 ATAM의 비교

구분CBAMATAM
평가기준비용과 편익 정량적 분석아키텍처 품질 속성 평가
특징품질속성과 경제성품질속성 상충관계
관심사항이해관계자 이익아키텍처 품질
결과비용효율적 아키텍처 선택품질요구사항 만족하는 아키텍처 선택
장점비용일정, 위험파악기존시스템 분석가능
단점품질속성 평가 미흡경제성 평가곤란

CBAM 고려사항

  • ATAM 이후 CBAM을 수행하여 품질속성 도출 후 비용편익이 좋은 아키텍처 결정