정보처리기사 2020 필기 1,2회 21~40번 문제
Technique정보처리기사 2020 필기 1,2회 21~40번 문제 해설
- 수제비 2020 정보처리기사 필기 도서와 수제비 카페 자료를 통해 작성
21,32. 테스트 지식 체계
소프트웨어 테스트 종류 - 화이트 박스 테스트(White-box Testing)
- 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트(구조 테스트)
- Source Code의 모든 문장을 한 번 이상 수행함으로써 진행됨
- 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트하는 방법
- 내부 소스코드의 동작을 개발자가 추적할 수 있어 동작의 유효성과 실행되는 과정을 확인 가능 (모듈 안의 작동을 직접 관촬 가능)
- 코드가 어떤 경로로 실행되며, 불필요한 코드 또는 테스트 되지 못한 부분을 확인할 수 있다.
- 산출물의 각 기능별로 적절한 프로그램의 제어구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검
- 단위 모듈 테스트의 가장 기본적인 방법
| 유형 | 설명 |
|---|---|
| 구문 커버리지 | 프로그램 내의 모든 명령문을 적어도 한 번 이상 실행하는 것을 기준으로 수행하는 테스트 커버리지 조건문 결과와 관계없이 구문 실행 개수로 계산 |
| 결정 커버리지 | 프로그램 내의 전체 결정문(조건문)이 적어도 한 번은 참/거짓의 결과를 수행하는 커버리지 |
| 조건 커버리지 | 전체 조건식 결과와 관계없이 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 커버리지 |
| 조건/결정 커버리지 | 전체 조건식뿐만 아니라 개별 조건식도 참/거짓을 모두 한 번씩 갖도록 수행하는 커버리지 |
| 변경 조건/결정 커버리지 | 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 커버리지 |
| 다중 조건 커버리지 | 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 커버리지 |
| 유형 | 설명 |
|---|---|
| 기초 경로 테스트 | 활동 다이어그램 또는 프로그램 코드에서 프로그램 수행 경로를 도출한 후 각 경로마다 테스트 케이스를 작성하여 테스트 결과와 예상 결과를 비교하는 테스트 기법 |
| 제어 흐름 테스트 | 프로그램의 제어구조를 그래프 형태로 나타내고, 그래프 구성 요소는 블록과 분기로 나타내어 내부 로직을 테스트하는 기법 |
| 조건 검사 | 프로그램의 조건문에 초점을 맞추어 검사 |
| 루프 검사 | 프로그램의 반복 구조에 초점을 맞추어 검사 |
| 데이터 흐름 테스트 | 제어흐름 그래프에 데이터 사용 현황을 추가한 그래프를 통해 테스트하는 기법 |
| 분기(Branch) 테스트 | 분기문을 실행하도록 테스트 케이스를 설계하여 내부 구조를 테스트하는 기법 |
검증 기준
- 문장 검증: 프로그램을 구성하는 문장들이 최소한 한 번씩 수행되는 경로 조사
- 선택 검증: 선택한 부분만 조사
- 경로 검증: 수행 가능한 모든 경로를 검사
- 조건 검증: if 문장이나 while 문장 안에 있는 조건식 조사
소프트웨어 테스트 종류 - 블랙 박스 테스트 (Black-box Testing)
- 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트(기능 테스트, 명세 테스트)
- 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 테스트
- 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점을 맞춰서 테스트
| 유형 | 설명 |
|---|---|
| 동등 분할 테스트 (Equivalence Partitioning) | 입력값의 범위를 유사한 특징을 갖는 그룹으로 나누고, 각 그룹마다 대표값을 선정하여 테스트 케이스를 도출해서 테스트하는 기법 입력값의 범위가 정해져 있는 경우 우용, |
| 경계값 분석 테스트 (Boundary Value Analysis) | 입력 조건의 중간값보다 결계값에서 에러가 발생될 확률이 높다는 점을 이용하여 경계값을 포함한 테스트케이스를 설계하여 테스트하는 기법 (ex: x값이 0~100 사이일 경우 x=0, x=100, x=100.1) |
| 결정 테이블 테스트 (Decision Table) | 요구사항의 논리와 발생조건을 테이블 형태로 나열하여, 조건과 행위를 모두 조합하여 테스트 하는 기법 |
| 상태전이 테스트 | 테스트 대상/시스템이나 객체의 상태를 구분하고, 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법 |
| 유스케이스 테스트 | 시스템이 실제 사용되는 유스케이스로 모델링되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행하는 테스트 기법 |
| 분류트리 테스트 | SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트하는 기법 |
| 페어와이즈 테스트 | 시스템에 대한 각 입력 매개 변수 쌍에 대해 해당 매개 변수의 모든 가능한 개별 조합을 테스트하는 소프트웨어 테스트 |
소프트웨어 테스트 종류 - 경험 기반 테스트
- 이전에 테스터가 다루었던 유사 애플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스를 추출하는 테스트
- 기법: 탐색적 테스팅, 오류 추정, 체크리스트 기반 테스팅
| 법칙 | 설명 |
|---|---|
| 파레토 법칙 (Pareto Principle) | 80대 20 법칙 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리키는 말 소프트웨어 테스트 원리 중 20%의 모듈에서 80%의 결함이 발견된다는 '결함집중' 원리를 내포함 |
| 요르돈의 법칙 (Yourdon's Law) | SW 개발 초기 체계적인 분석 및 설계가 수행되지 못하면 그 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커진다는 법칙(Snowball Effect, 눈덩이 법칙) |
| 브룩스의 법칙 (Brooks' law) | 지연되는 프로젝트에 인력을 더 투입하면 오히러 늦어진다는 이론
프레더릭 브룩스가 자신의 1975년 저서 《맨먼스 미신》(The Mythical Man-Month)에서 "지체되는 소프트웨어 개발 프로젝트에 인력을 추가하는 것은 개발을 늦출 뿐이다"라고 주장한 법칙 인력이 추가되서 개발 생산성이 향상되지 않고, 오히려 그 인력 때문에 방해된다는 의미를 내포 |
| 롱테일 법칙 (Long Tail) | 사소해 보이는 80%의 다수가 20%의 소수 핵심보다도 뛰어난 가치를 창출해낸다는 이론 파레토 법칙의 반대 이론 |
22,34. 트리(Tree)
- 데이터들을 계층화시킨 자료 구조
- 인덱스를 조작하는 방법으로 가장 많이 사용하는 구조
- 노드(Node)와 노드를 연결하는 링크(Link)로 구성
- 배열과 달리 노드들이 포인터로 연결되어 노드의 상한선이 없다.
| 용어 | 설명 | 그림 예시 |
|---|---|---|
| 루트 노드(Root Node) | 트리에서 부모가 없는 최상위 노드 트리의 시작점 | A |
| 단말 노드(Leaf Node) | 자식이 없는 노드 트리의 가장 말단에 위치 | D, G, H, F |
| 레벨(Level) | 루트 노드를 기준으로 특정 노드까지의 경로 길이 | E의 레벨 2 G의 레벨 3 |
| 조상 노드(Ancestor Node) | 특정 노드에서 루트에 이르는 경로상 모든 노드 | D의 조상 노드는 B, A |
| 자식 노드(Child Node) | 특정 노드에 연결된 다음 레벨의 노드 | E의 G, H |
| 부모 노드(Parent Node) | 특정 노드에 연결된 이전 레벨의 노드 | F의 부모는 C |
| 형제 노드(Sibling) | 같은 부모를 가진 노드 | E의 형제 노드는 F |
| 깊이(Depth) | 루트 노드에서 특정 노드에 도달하기 위한 간선의 수 | 트리의 깊이는 2 |
| 차수(Degree) | 특정 노드에 연결된 자식 노드의 수 | E의 차수는 2 |
| 구분 | 개념도 | 순회방법 |
|---|---|---|
| 전위 순회(Pre-Order Traversal) | A - B - D - C - E - G - H - F | Root → Left → Right |
| 중위 순회(In-Order Traversal) | D - B - A - G - E - H - C- F | Left → Root → Right |
| 후위 순회(Post-Order Traversal) | D - B - G - H - E - F - C - A | Left → Right → Root |
23. 테스트 레벨(Test Level)
- 함께 편성되고 관리되는 테스트 활동의 그룹
- 프로젝트에서 책임과 연관되어 있음
- 각각의 테스트 레벨은 서로 독립적
| 종류 | 설명 | 기법 |
|---|---|---|
| 단위 테스트 | 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계 | 인터페이스 테스트 자료 구조 테스트 실행 경로 테스트 오류 처리 테스트 |
| 통합 테스트 | 단위 테스트를 통과한 컴포넌트 간의 인터페이스를 테스트하는 단계 | 빅뱅 테스트 상향식/하향식 테스트 |
| 시스템 테스트 | 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트하는 단계 | 기능/비기능 요구사항 테스트 |
| 인수 테스트 | 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계 시스템이 인수조건을 만족시키는지, 사용자나 고객이 시스템을 인수할지 결정할 수 있도록 사용자의 필요, 요구, 비즈니스 프로세스를 고려해서 수행하는 공식적인 테스팅 | 알파/베타 테스트 |
| 테스트 | 설명 |
|---|---|
| 알파 테스트 | 공장 인수 테스트(Factory Acceptance Test) 개발하는 조직 내에서 잠재적인 고객에 의해 수행되는 테스트 개발자 환경에서 사용자가 수행하는 테스트 일반적으로 통제된 환경에서 사용자와 개발자가 함께 하면서 수행되는 검사 |
| 베타 테스트 | 필드 테스트. 사이트 인수 테스트(Site Acceptance Testing) 실제 업무 현장에 있는 인원(사용자, 잠재적인 고객)에 의해서 수행되는 테스트 실제 사용 환경에서 진행하는 테스트 |
| 감마 테스트 | 베타 버전 배포 후의 다수의 사용자 대상 테스트 |
24. 통합 테스트(Integration Test)
소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
| 테스트 방안 | 빅뱅 | 상향식 통합(Bottom Up) | 하향식 통합(Top Down) |
|---|---|---|---|
| 테스트 수행 방법 | 모든 모듈을 동시에 통합 후 테스트 수행 | 최하위 모듈부터 점직적으로 상위 모듈과 함께 테스트 | 최상위 모듈부터 하위 모듈들을 통합하면서 테스트 |
| 드라이버 / 스텁 | 드라이버/스텁 없이 실제 모듈로 테스트 | 상위의 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈인 '드라이버(Driver)'를 작성 | 모듈 및 모든 하위 컴포넌트를 대신하여 더미 모듈인 '스텁(Stub)'을 개발 |
| 장점 | 단시간 테스트 가능 작은 시스템에 유리 | 장애 위치 파악 쉬움 모든 모듈 개발에 대한 시간 낭비가 필요 없음 | 장애 위치 파악 쉬움 이른 프로토타입 가능 중요 모듈의 선 테스트 가능 |
| 단점 | 장애 위치 파악 어려움 모든 모듈이 개발되어야 가능 | 중요 모듈들이 마지막 테스트 가능성 높음 이른 프로토타입 어려움 | 많은 스텁이 필요 하위 모듈들의 불충분한 테스트 수행 |
- 스텁(Stub): 하위 모듈의 반환 값만 전달함
- 드라이버(Driver): 상위 모듈 흐름을 작성해야 하기 때문에 스텁이 개발하기 쉽다
25,37. 국제 품질 표준
| 품질 표준 | 설명 |
|---|---|
| ISO/IEC 9126 | ISO/IEC 9126의 품질 모델은 소프트웨어 품질을 측정하고, 평가하기 위해서 소프트웨어의 품질 요소와 특성을 정의 품질 특성은 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성으로 나눔 |
| ISO/IEC 12119 | 소프트웨어 패키지 제품에 대한 품질 요구사항 및 테스트 국제 표준 제품 설명서, 사용자 문서, 실행 프로그램 |
| ISO/IEC 14598 | 소프트웨어 제품 평가 프로세스 및 평가 모듈을 제공 패키지 소프트웨어와 SI 개발 소프트웨어에 있어서 개발 과정 또는 개발이 완료된 제품의 품질에 대한 평가 표준과 프로세스를 제공 개발자에 대한 소프트웨어 제품 품질 향상과 구매자의 제품 품질 선정 기준, 소프트웨어 제품 평가 프로세스 및 평가 모듈을 제공하는 국제 표준 |
| ISO/IEX 25000 | SQuaRE ISO/IEC 9126과 ISO/IEC 14598, ISO/IEC 12119를 통합하고, ISO/IEC 15288을 참고한 소프트웨어 제품 품질에 대한 통합적인 국제 표준 개발 공정 각 단계에서 산출되는 제품이 요구사항을 만족하는지 검증하기 위해 품질 측정 및 평가를 위한 모델 |
| 품질 표준 | 설명 | 세부 사항 |
|---|---|---|
| ISO/IEC 9001 | 설계/개발, 생산, 설치 및 서비스 과정에 대한 품질 보증 모델 필요한 품질 시스템 순기활동과 그에 따른 공급자와 구매자 각각의 관리책임을 명시하고 있으며 운영 중인 품질 시스템이 이 표준에 적합할 경우 품질 인증을 부여 | ISO 9000-3 (SIO 9001 표준을 소프트웨어 산업에 맞게 변형한 국제 표준) |
| ISO/IEC 12207 | 소프트웨어의 획득, 공급, 개발, 운영, 유지보수를 체계적으로 관리하기 위한 소프트웨어 '생명주기 단계별 필요 프로세스'를 규정한 국제표준 | 기본/조직/지원 프로세스 |
| ISO/IEC 15504 (SPICE) | 소프트웨어 프로세스를 평가하고 개선함으로써 품질 및 생산성을 높이고자 하는 국제 표준 소프트웨어 프로세스 영역을 ISO/IEC 12207에 준거하여 기본/지원/조직 프로세스로 구분하고 있으며 각 프로세스 영역별로 프로세스 카테고리와 기본 프로세스 정의 | 수행단계 구분: 불완전(0)-수행(1)-관리(2)-확립(3)-예측(4)-최적화(5) |
| CMMi | 기존 CMM 모델을 통합하고 ISO/IEC 15504(SPICE)를 준수하는 소프트웨어 개발 능력/성숙도 평가 및 프로세스 개선 활동의 지속적인 품질 개선 모델 적용 및 평가 방식은 조직차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를 평가하는 연속적 표현이 있음 | 프로세스 영역 목표 실행 공통 특징 |
| 품질 특성 | 설명 | 품질 부특성 |
|---|---|---|
| 기능성 (Functionality) | 소프트웨어가 특정 조건에서 사용될 때 명시된 요구와 내재된 요구를 만족하는 기능을 제공하는 능력 | 적합성, 정확성, 상호 운용성, 보안성, 준수성 등 |
| 신뢰성 (Reliability) | 명세된 조건에서 사용될 때 성능 유지가 가능한 능력 옳고 일관된 결과를 얻기 위하여 요구된 기능을 수행할 수 있는 정도 주어진 시간 동안 주어진 기능을 오류 없이 수행하는 정도 | 성숙성, 결함 허용성, 회복성, 준수성 등 |
| 사용성 (Usability) | 명시된 조건에서 사용될 경우, 사용자에 의해 이해되고, 학습되고, 사용되고 선호될 수 있는 능력 | 이해성, 학습성, 운용성, 친밀성, 준수성 등 |
| 효율성 (Efficiency) | 명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력 | 시간 반응성, 자원 효율성, 준수성 |
| 유지보수성 (Maintainability) | 소프트웨어 제품이 변경되는 능력 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 개작 등이 포함 | 분석성, 변경성, 안정성, 시험성, 준수성 등 |
| 이식성 (Portability) | 한 환경에서 다른 환경으로 전이될 수 있는 능력 | 적응성, 설치성, 공존성, 대체성, 준수성 등 |
27. DRM(Digital Rights Management)
디지털 콘텐츠에 대한 권리정보를 지정하고 암호화 기술을 이용하여 허가된 사용자의 허가된 권한 범위 내에서 콘텐츠의 이용이 가능하도록 통제하는 기술
- 콘텐츠 암호화 및 키 관리
- 콘텐츠 식별체계 표현
- 라이센스 발급 및 관리
| 구성요소 | 설명 |
|---|---|
| DRM 콘텐츠 | 서비스하고자 하는 암호화된 콘텐츠, 콘텐츠와 관련된 메타 데이터, 콘텐츠 사용정보를 패키징하여 구성된 콘텐츠 |
| 패키저(Packager) | 암호화된 콘텐츠, 콘텐츠 관련 메타 데이터, 클리어링 하우스에서 부여받은 콘텐츠 사용정보를 암호화한 콘텐츠로 변환하는 도구 |
| 구성요소 | 설명 |
|---|---|
| 콘텐츠 권한정책 | 라이선스 발급여부를 결정하는 정책에 대한 부합 여부 확인 적정한 사용 권한을 부여하는 역할 수행 |
| 콘텐츠 라이선스 | 클리어링 하우스에 의해서 사용자에게 전달되는 콘텐츠의 권리 인증 콘텐츠에 대한 사용조건 및 허가 정보를 포함 |
| 콘텐츠 관리정보 | 콘텐츠를 사용하고자 하는 사용자 정보 및 사용하고자 하는 콘텐츠에 대한 정보 |
| 콘텐츠 사용정보 | DRM 콘텐츠의 사용자 권한 및 그 권한에 따른 콘텐츠 정책에 대 한 정보 |
| 구성요소 | 설명 |
|---|---|
| DRM 컨트롤러 | 배포된 디지털 콘텐츠의 이용 권한을 통제 |
| 보안 컨테이너 | 원본 콘텐츠를 안전하게 유통하기 위한 전자적 보안장치 |
동작 절차 (콘텐츠 유통 과정)
1. 클리어링 하우스에 라이선스 등록, 유통시스템에 콘텐츠 등록
2. 콘텐츠 소비자가 유통시스템으로 라이선스 요청
3. 유통서비스에서 클리어링 하우스로 라이선스 요청 전달
4. 콘텐츠 소비자가 요금을 지불하면 클리어링 하우스에서 라이선스 발급
5. 콘텐츠 소비자가 제공자에게서 콘텐츠 다운로드
28. 인터페이스 보안
| 프로토콜 | 설명 |
|---|---|
| IPSec (IP Security) | IP계층(3계층)에서 무결성과 인증을 보장하는 인증헤더(AH)와 기밀성을 보장하는 암호화(ESP)를 이용한 IP 보안 프로토콜 |
| SSL (Secure Sockets Layer) /TLS | 응용 계층과 TCP/IP계층 사이의 웹 데이터 암호화 및 전송 시 기밀성을 보장하는 공개키 기반의 보안 프로토콜 |
| S-HTTP (Secure Hypertext Transfer Protocol) | 기존 HTTP 프로토콜에 송신자 인증, 메시지 기밀성과 무결성, 부인 방지 기능을 확장한 프로토콜 |
29. 설계 산출물
| 도구 | 설명 |
|---|---|
| xUnit | Java(Junit), C++(Cppunit), .Net(Nunit) 등 다양한 언어를 지원하는 단위테스트 프레임워크 |
| STAF | 서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크 |
| FitNesse | 웹 기반 테스트 케이스 설계/실행/결과 확인 등을 지원하는 테스트 프레임워크 |
| Selenium | 다양한 브라우저 지원 및 개발언어를 지원하는 웹 애플리케이션 테스트 프레임워크 |
| watir | Ruby 기반 웹 애플리케이션 테스트 프레임워크 |
30. 애플리케이션 패키징(Application Packaging)
| 고려사항 | 설명 |
|---|---|
| 사용자 시스템 환경 정의 | 사용자의 시스템 환경인 운영체제, CPU, 메모리 등의 수행을 위한 최소 환경을 정의 |
| UI 제공 | 사용자가 직관적으로 확인할 수 있는 UI를 제공하고, 매뉴얼과 일치시켜 패키징 작업 수행 |
| 관리 서비스 형태로 제공 | 애플리케이션은 하드웨어와 함께 통합 적용할 수 있도록 패키징을 관리 서비스 형태로 제공 |
| 패키징의 변경 및 개선 관리 고려 | 다양한 사용자의 요구사항을 반영하기 위해 패키징의 변경 및 개선 관리를 고려하여 패키징 배포 |
31. 소프트웨어 형상 관리 / 버전 관리 도구
소프트웨어 생명주기 동안 발생하는 변경사항을 체계적으로 관리하여 소프트웨어의 품질보증을 향상시키는 관리적 활동
개발 과정의 변경 사항을 관리
향상 관리 지침을 활용하여 제품 소프트웨어의 신규 개발, 변경, 개선과 관련된 수정 사항을 관리하는 도구
| 버전 관리 도구 | 설명 |
|---|---|
| CVS (Concurrent Versions System) | 서버와 클라이언트로 구성되어 다수의 인원이 동시에 범용적인 운영체제로 접근 가능하여 버전 관리가 가능한 도구 |
| SVN (Subversion) | 하나의 서버에서 소스를 쉽고 유용하게 관리할 수 있게 도와주는 도구 GNU의 버전 관리 시스템으로 CVS의 장점은 이어받고 단점은 개선하여 2000년에 발표됨 |
| PCS (Revision Control System) | CVS와 달리 소스 파일의 수정을 한 사람만으로 제한하여 다수의 사람이 파일의 수정을 동시에 할 수 없도록 파일 잠금 방식으로 버전을 관리하는 도구 |
| Bitkeeper | SVN과 비숫한 중앙 통제 방식으로 대규모 프로젝트에서 빠른 속도를 내도록 개발된 버전 관리 도구 |
| Git | 속도에 중점을 둔 분산형 버전 관리 시스템 대형 프로젝트에서 효과적이고 유용함 Git의 커밋(Commit) 동작은 로컬 저장소에서 이루어지고, 푸시(Push)라는 동작으로 원격 저장소에 반영 로컬 저장소에서 작업이 이루어져 매우 빠른 응답을 받을 수 있음 Git의 작업 폴더는 전체 기록과 각 기록을 추적할 수 있는 정보를 포함하는 완전한 형태의 저장소임 |
| Clear Case | 복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성을 기할 수 있음 |
33. 코드 유형
| 코드 | 설명 |
|---|---|
| 외계인 코드 (Alien Code) | 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 아주 어려운 프로그램 |
| 스파게티 (Spaghetti Code) | 프로그램 로직이 복잡하여 이해하기 어려운 프로그램 컴퓨터 프로그램의 소스 코드가 복잡하게 얽힌 모습을 스파게티 면발에 비유한 표현 정상적으로 작동하지만 코드가 어떻게 작동하는 지 파악하기 어려운 코드 |
| 클린코드 (Clean Code) | 잘 작성되어 가독성이 높고 단순하며, 의존성을 줄이고 중복을 최소화하여 깔끔하게 정리된 코드 - 작성 원칙: 누구든 쉽게 이해하는 코드 작성(가독성) / 단순, 명료한 코드 작성(단순성) / 다른 모듈에 미치는 영향 최소화(의존성) / 중복 최소화(중복성) / 클래스, 메소드, 함수에 대해 동일한 수준의 추상화 구현(추상화) |
| 원시 프로그램 (Source Program) | 사용자가 직접 작성한 프로그램 |
35, 36. 알고리즘(Algorithm)
| 기법 | 설명 |
|---|---|
| 분할과 정복 (Divide and Conquer) | 문제를 나눌 수 없을 때까지 나누고, 각각을 풀면서 다시 병합하여 문제의 답을 얻는 알고리즘 |
| 동적계획법 (Dynamic Programming) | 어떤 문제를 풀기 위해 그 문제를 더 작은 문제의 연장선으로 생각하고, 과거에 구한 해를 활용하는 방식의 알고리즘 |
| 탐욕법 (Greedy) | 결정을 해야할 때마다 그 순간에 가장 좋다고 생각되는 것을 해답으로 선택함으로써 최종적인 해답에 도달하는 방식의 알고리즘 |
| 백트래킹 (Backtracking) | 어떤 노드의 유망성 점검 후, 유망하지 않으면 그 노드의 부모 노드로 되돌아간 후 다른 자손노드를 검색하는 알고리즘 |
| 복잡도 | 설명 | 대표 알고리즘 |
|---|---|---|
| O(1) | 상수형 복잡도 자료 크기 무관하게 항상 같은 속도로 작동 알고리즘 수행시간이 입력 데이터 수와 관계없이 일정 | 해시 함수(Hash Function) |
| O(logn) | 로그형 복잡도 문제를 해결하기 위한 단계의 수가 log2n번 만큼의 수행시간을 가짐 n개 데이터를 log n번 검색 | 이진 탐색(Binary Search) |
| O(n) | 선형 복잡도 입력 자료를 차례로 하나씩 모두 처리 n개 데이터를 하나씩 확인하여 n번 검색 수행 시간이 자료크기와 직접적 관계로 변함(정비례) | 순차 탐색(Sequential Search) |
| O(nlogn) | 선형 로그 복잡도 문제를 해결하기 위한 단계의 수가 nlog2n번 만큼의 수행시간을 가짐 정렬된 n개 데이터를 처리하는 데 O(nlog2n)의 시간이 소요됨 | 퀵 정렬(Quick Sort) 병합 정렬(Merge Sort, 합병 정렬) |
| O(n²) | 제곱형 주요 처리 루프 구조가 2중인 경우 n크기 작을 때에는 n²이 nlogn보다 느릴 수 있음 | 거품 정렬(Bubble Sort) 삽입 정렬(Insertion Sort) 선택 정렬(Selection Sort) |
38. 내외부 인터페이스 기술 표준 확인
| 구축 유형 | 설명 | 특징 |
|---|---|---|
| 포인트 투 포인트 (Point-to-Point) | 중간에 미들웨어를 두지 않고 각각의 애플리케이션 간에 점대점 형태로 연결 | 솔루션 구매 없이 통합 상대적으로 저렴하게 통합 가능 변경, 재사용이 어려움 |
| 허브 앤 스포크 (Hub & Spoke) | 단일한 접점의 허브 시스템을 통하여 데이터를 전송하는 중앙 집중식 방식 | 모든 데이터 전송 보장 확장, 유지 보수 용이 허브 장애 시 전체 장애 발생 |
| 메시지 버스 (Message Bus) | 애플리케이션 사이 미들웨어(버스)를 두어 연계하는 미들웨어 통합 방식 | 뛰어난 확장성과 대용량 데이터 처리 가능 |
| 하이브리드 (Hybrid) | 그룹 내는 허브 앤 스포크 방식을 사용하고, 그룹 간에는 메시지 버스 방식을 사용하는 통합 방식 | 표준 통합 기술, 데이터 병목 현상 최소화 필요한 경우 한 가지 방식으로 구현 가능 |
39. 소스 코드 품질 분석
| 애플리케이션 변경 관리 | ChangeMiner |
|---|---|
| 애플리케이션 성능 관리 | Jeniffer, Nmon |
| 애플리케이션 정적 분석 | PMD: 자바 및 타 언어 소스 코드에 대한 버그, 데드 코드 분석 Cppcheck: C/C++ 코드에 대한 메모리 누수, 오버플로우 등 문제 분석 Checkstyle: 자바 코드에 대한 코딩 표준 검사 도구 SonarQube: 소스 코드 품질 통합 플랫폼. 플러그인 확장 가능 |
| 애플리케이션 동적 분석 | Avalanche: Valgrind 프레임워크 및 STP 기반 소프트웨어 에러 및 취약점 동적 분석 도구 Valgrind: 자동화된 메모리 및 스레드 결함 발견 분석 도구 |
40. 반정규화(De-Normalization)
정규화된 엔티티, 속성, 관계를 시스템의 성능 향상과 개발 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링 기법
| 기법 | 설명 |
|---|---|
| 테이블 병합 | 1:1 관계, 1:M 관계를 통합하여 조인 횟수를 줄여 성능을 향상 |
| 테이블 분할 | 테이블을 수직 또는 수평으로 분할하는 것으로 파티셔닝 - 수평 분할: 테이블 분할에 레코드를 기준으로 활용 - 수직 분할: 하나의 테이블이 가지는 컬럼의 개수가 증가하는 경우 활용. 갱신 위주의 컬럼, 수직 분할, 조회 빈도가 높은 컬럼을 분할 |
| 중복 테이블 생성/추가 | 대량의 데이터들에 대한 집계함수(GROUP BY, SUM 등)를 사용하여 실시간 통계정보를 계산하는 경우에 효과적인 수행을 위해 별도의 통계 테이블을 두거나 중복 테이블을 추가 - 통계(집계) 테이블 추가, 이력(진행) 테이블 추가, 부분 테이블 추가 |
| 구분 | 기법 | 설명 |
|---|---|---|
| 컬럼 | 중복 컬럼 생성 | 조인 시 성능 저하를 예방하기 위해, 중복된 컬럼을 위치시킴 대량의 이력 데이터 처리 시 불특정일 조회나 최근 값을 조회할 때 나타날 수 있는 성능 저하를 예방하기 위해 기능성 컬럼을 추가 |
| 관계 | 중복관계 추가 | 데이터를 처리하기 위한 여러 경로를 거쳐 조인이 가능하지만 이때 발생할 수 있는 성능 저하를 예방하기 위해 추가적 관계를 맺는 방법 |
