Hanbbi's DevLog

정보처리기사

정보처리기사 필기(2) - 소프트웨어 개발

2023-12-25

필기 시험 공략

개인적으로 필기 시험의 경우 기출문제를 많이 풀어보는 것으로 충분하다고 생각한다.

구글 앱 스토어에서 "정보처리기출문제"라는 키워드로 검색해서 앱에 등록된 문제들을 많이 풀어보면 좋을 것 같다.

나의 경우 아래의 순서로 필기한 후, 기출문제를 많이 풀어본 후에 시험을 쳤다.

표 등 일부 내용은 깃허브에서 보는 것이 더 편하다.

  1. 소프트웨어 설계

  2. 소프트웨어 개발

  3. DB구축

  4. 프로그래밍 언어 활용

  5. 정보시스템 구축 관리

본문은 요약본으로, 노출 빈도가 높다고 느낀 키워드는 ★표로 강조하였다.

단위 모듈

  • 소프트웨어 구현에 필요한 다양한 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것을 의미한다.
  • 사용자 또는 다른 모듈로부터 값을 전달받아 시작되는 작은 프로그램이다.
  • 독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입될 수 있다.
  • 두 개의 단위 모듈이 합쳐지면 두 개의 기능들을 같은 모듈로 구현할 수 있다.
  • 종류 : 화면, DB접근, 인터페이스, 비즈니스 트랜잭션, 데이터 암호화 등

모듈화의 원리

  • 소프트웨어 개발에 있어 기능을 나누고 추상화하여 소프트웨어의 성능을 향상시키고 유지보수를 효과적으로 구현하기 위한 기법을 의미한다.
  • 종류
    • 분할과 지배(Dibide Conquer) : 복잡한 문제를 분해, 모듈 단위로 문제를 해결한다.
    • 정보 은폐(Information Hiding) : 어렵거나 변경 가능성이 있는 모듈을 타 모듈로부터 은폐시킨다.
    • 자료 추상화(Data Abstraction) : 함수 내에 자료 구조의 표현 명세를 은폐, 자료와 자료에 적용 가능한 오퍼레이션을 함께 정의한다.
    • 모듈의 독립성(Module Independence) : 낮은 결합도, 높은 응집도를 갖도록 한다.

단위 모듈 테스트

  • 프로그램의 단위 기능을 구현하는 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것이다.
  • 화이트박스 테스트와 블랙박스 테스트 기법이 있다.

구현 단계의 작업 절차

코딩 계획 => 코딩 => 컴파일 => 테스트

통합 개발 환경

IDE(Integrated Development Environment)

  • C++, JAVA 등의 언어를 이용한 소프트웨어 개발 단계에서 패키지 인크루딩, 소스 코드 편집, 컴파일, 디버깅, 바이너리 배포 등 모든 작업을 통합 지원한다.
  • 편집기, 컴파일러, 디버거 등의 다양한 도구를 하나의 인터페이스로 통합하여 제공한다.
  • 오류 체크를 시각화하여 확인 및 수정을 쉽도록 지원한다.
  • 컴파일에 필요한 외부 추가 기능을 연계하여 개발의 편의성을 높였다.
  • 종류 : 이클립스, 비주얼 스튜디오, XCode, 안드로이드 스튜디오, IDEA, VSC 등

빌드 자동화 도구

  • 소스 코드 컴파일 후 다수의 연관된 모듈을 묶어 실행 파일로 만든다.
  • 소프트웨어 개발자가 반복 작업해야 하는 코딩을 잘 짜여진 프로세스를 통해 자동으로 실행하여, 신뢰성 있는 결과물을 생산해 낼 수 있는 작업 방식 및 방법이다.
  • 소스 코드를 컴파일, 테스트, 정적 분석 등을 실시하여 실행 가능한 애플리케이션으로 자동 생성하는 프로그램이며, 지속해서 증가하는 라이브러리의 자동 추가 및 관리(전처리, Preprocessing)를 지원한다.
  • 최근에는 오픈소스인 Gradle이 등장했으며, 구글이 안드로이드의 기본 빌드 시스템으로 Gradle을 선택하면서 사용자가 급증하였다.
  • 기능 : 코드 컴파일, 컴포넌트 패키징, 파일 조작, 개발 테스트 실행, 버전 관리 도구 통합, 문서 생성, 배포 기능, 코드 품질 분석
  • 프로세스 : 컴파일 => 패키징 => 단위 테스트 => 정적 분석 => 리포팅 => 배포 => 최종 빌드
  • 종류 : Gradle, Jenkins, Makefile, Ant, Maven 등

제품 소프트웨어 패키징

애플리케이션 패키징(배포)

  • 개발이 완료된 소프트웨어를 고객에게 인도하기 위해 패키징하고, 설치 메뉴얼, 사용 메뉴얼 등을 작성하는 일련의 배포용 설치 파일을 만드는 작업을 의미한다.
  • 패키징 시 사용자 시스템의 환경, 직관적 UI, 관리 서비스 형태 제공, 패키징 변경 및 개선 관리를 통한 안정적 배포를 고려해야 한다.

패키징 프로세스

  • 기능 식별
    • 입/출력 데이터를 식별하고 전체적인 기능 정의 및 데이터 흐름을 식별한다.
    • 기능 단위 및 출력에 대하여 상세 정의한다.
  • 모듈화
    • 모듈화를 위하여 모듈 간 결합도와 응집도를 분석한다.
    • 분류할 수 있는 기능 단위 및 서비스 단위를 모듈 별로 분류한다.
    • 공유 가능한 기능과 재활용 기능을 분류한다.
  • 빌드 진행
    • 신규 개발 소스 및 컴파일 결과물을 준비한다.
    • 정상적으로 빌드되는 기능 단위 및 서비스를 분류한다.
    • 빌드 도구를 선별하여 선택하고, 해당 빌드 도구를 이용하여 빌드를 수행한다.
    • 컴파일 회의 에디터 등의 관련 도구 기능을 확인한다.
  • 사용자 환경 분석
    • 고객의 편의를 위하여 최소 사용자 환경 사전을 정의한다.
    • 다양한 사용자 환경 테스트를 수행한다.
  • 패키지 적용 시험
    • 실 사용자 환경에서의 패키징 적용을 테스트한다.
    • 사용자 관점에서 UI 및 시스템상의 편의성을 점검한다.
  • 패키징 변경 개선
    • 사용자 관점에서 패키징 적용 시 개선점을 도출하여 서비스 가능한 수준의 개선 후 개선 버전을 다시 패키징한다.

패키징 도구의 구성요소

구성특징
암호화 (Encryptoin)콘텐츠 및 라이센스를 암호화하고, 전자 서명을 할 수 있는 기술이다. (ex. PKI, Symmetric/Asymmetric Encryption, Digital) Signature
키 관리 (Key Management)콘텐츠를 암호화한 키에 대한 저장 및 배포 기술이다. (관리 방식 : 분산형, 중앙)집중형
암호화 파일 생성 (Packager)콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술이다. (ex. Pre-packaging, On-the-fly) Packaging
식별 기술 (Identificatoin)콘텐츠에 대해 식별하고 체계화하는 기술이다. (ex. DOI, URI)
저작권 표현 (Right Expression)저작권의 라이센스 내용을 표현하는 기술이다. (ex. XrML/MPGE-21 REL, ODRL)
정책 관리 (Policy Management)라이센스 발급 및 사용에 대한 정책 표현 및 관리 기술이다. (ex. XML, Contents Management) System
크랙 방지 (Tamper Resistance)크랙에 의한 콘텐츠 사용 방지 기술이다.(Code Obfuscation, Kernel Debugger Detection, Module Certification) (ex. Secure DB, Secure Time Management, Encryption)
인증 (Authentication)라이센스 발급 및 사용의 기준이 되는 사용자 인증 기술이다. (ex. User/Device Authentication, SSO, Digital Certificate)

릴리즈 노트

  • 애플리케이션 최종 사용자인 고객에게 제공하는 잘 정리된 배포 정보 문서이다.
  • 애플리케이션 릴리즈 노트에는 상세 서비스를 포함하여 수정/변경된 정보를 담고 있는 문서이다.
  • 사용자에게 최종 배포된 릴리즈 노트를 보면 테스트가 어떻게 진행됐는지, 개발팀의 제공 사양을 얼마나 준수했는지를 확인해 볼 수 있다.
  • 전체적인 버전 관리 및 릴리즈 정보를 체계적으로 관리할 수 있다.
  • 릴리즈 노트는 현재 시제로 개발팀에서 직접 작성하여야 하며, 명확하고 정확하며 완전한 정보를 제공해야 한다.
  • 개발자와 테스터가 함께 협업해야 하고 최초 및 변경, 개선 항목까지 연결되어 다음 항목에 대한 정보들이 릴리즈 노트를 통해 작성되어야 한다.

릴리즈 노트 작성 항목

  • 헤더(Header) : 문서명, 제품명, 배포 버전 번호, 릴리즈 날짜, 참고 날짜, 문서(릴리즈 노트) 버전 등
  • 개요 : 제품 및 변경에 대한 정보를 간략하게 작성한다.
  • 목적 : 제품의 버그 픽스(오류 수정)와 새로운 기능을 포함한 릴리즈의 새로운 사항의 나열과 더불어 릴리즈 노트의 목적에 대한 간략한 개요를 작성한다.
  • 이슈 요약 : 문제가 되는 버그의 간단한 설명과 개선사항 항목을 요약하여 작성한다.
  • 재현 항목 : 버그 발생을 재현하기 위한 절차이다.
  • 수정 및 개선 내용 : 수정 및 개선 내용을 간략하게 서술한다.
  • 최종 사용자 영향도 : 최종 사용자에게 필요한 조치로, 이 변경사항으로 인해 다른 기능이 영향을 받는지 간략히 서술한다.
  • 노트 : 소프트웨어 및 하드웨어 설치 항목, 제품, 문서를 포함한 업그레이드 항목을 서술한다.
  • 면책 조항 : 회사와 표준 제품과 관련된 메시지를 작성한다.(프리웨어, 불법 복제 금지 등)
  • 연락 정보 : 사용자 지원 및 문의 관련한 연락처 정보를 작성한다.

릴리즈 노트 작성 순서

  1. 모듈 식별
    • 모듈 및 빌드 수행 후 릴리즈 노트 기준의 항목을 순서대로 정리한다.
    • 소스를 통하여 처리되는 입/출력 데이터의 형, 기능 정의, 데이터 흐름을 정리한다.
    • 메인 함수 이외의 호출 함수를 정의하고 이에 대한 출력 값을 식별한다.(ex. I/O 데이터, Function Data Flow)
  2. 추가 개선 항목 식별
    • 추가 개선에 따른 추가 항목을 식별하여 릴리즈 노트를 작성한다.
    • 추가 개선에 대한 베타 버전을 이용 테스트 수행한다.
    • 테스트 중 발생한 긴급 버그를 수정한다.
    • 사용자 요청에 따른 추가 개선을 계획하고 수정한다.(ex. 베타 버전, 긴급 버그, 사용자 요청)

형상관리 ★★★

  • 개발 단계에서 생성되는 모든 문서, 코드 등 소프트웨어의 변경사항을 체계적으로 관리하기 위하여 추적하고 통제하는 것이다.
  • 작업 산출물을 형상 항목(Configuration Item)이라는 형태로 선정하고, 형상 항목 간의 변경사항 추적과 통제 정책을 수립하고 관리한다.
  • 요구사항 변경 또는 오류로 지속해서 변화하는 자료이며, 이러한 변화를 이력화하여 유지보수성을 향상할 수 있다.
  • 소프트웨어는 눈으로 확인할 수 있는 가시성이 없으므로 개발 과정의 진행 정도를 확인하는 도구로 사용된다.
  • 단순 버전 관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 의미한다.

형상 관리 항목(Configuration Item)

  • 개발 프로세스에서 생산되거나 사용되는 작업 산출물, 작업 산출물들의 집합체를 의미한다.
  • 대표적인 소프트웨어 형상 항목 : 프로젝트 요구 분석서, 운영 및 설치 지침서, 요구사항 명세서, 설계/인터페이스 명세서, 테스트 설계서, 소프트웨어 품질보증, 형상 관리, V & V 계획서(확인 및 검증)와 같은 계획서, 코드 모듈(소스와 오브젝트 모두)

형상 관리 종류

  • 형상 관리는 버전관리, 리비전 관리, 변경 관리, 빌드 관리, 이슈 관리 등을 모두 포함한다.

  • 버전 관리

    • 다양한 형상항목이 과거부터 현재에 이르기까지 요구사항 등의 변화에 따라 버전을 부여함으로써 이력을 관리하는 것이다.
    • 버전을 통해 시간적인 변경사항과 해당 작업 담당자를 추적할 수 있다.

  • 변경 관리

    • 변경된 요구사항에 대하여, 비용 및 기간 등을 고려하고 타당성을 평가한다.
    • 요구사항이 타당한 경우 제품 또는 산출물을 변경하고, 그렇지 않을 경우 변경을 거부하는 활동이다.

형상 관리의 필요성과 효과

  1. 형상관리의 필요성
    • 이미 수정된 오류가 갑자기 다시 나타나거나, 사용하던 문서나 코드가 갑자기 사라지거나 찾을 수 없는 경우가 발생할 수 있다.
    • 원시 코드와 실행 코드의 버전이 일치하지 않는다.
    • 요구사항이 자주 변경되고, 변경이 어떤 결과를 가져올지 예측할 수 없다.
    • 무엇을 변경해야 할지 막연하고, 따라서 변경에 대한 노력을 예측할 수 없다.
    • 분산된 지역에서 소프트웨어를 병렬적으로 개발하기 어렵다.
    • 제품 납기일을 맞추기가 어렵고, 프로젝트가 계획대로 잘 진행되고 있는지 모르겠다.
  2. 형상 관리의 효과
    • 관리적 효과
      • 표준 확입으로 전사적 IT 자원 관리가 쉬워, 기간별/팀별/업무별 산출물 현황 및 변경 이력 통계를 파악할 수 있다.
      • 제품 개발 관련 산출물이 자동 생성되고 관리된다.
      • 개발/유지보수 활동을 통합 관리할 수 있다.
      • 변경 프로세스의 체계를 확립하고, 외주 개발 통제 및 현황 파악을 도와준다.
    • 품질 향상 효과
      • 산출물 버전 관리를 자동으로 생성 관리할 수 있어 결함 및 오류가 감소한다.
      • 변경 프로그램의 이력 관리를 통하여 문제 파악 및 버그 수정이 쉬워지고, 변경 내용의 영향 분석이 쉬워진다.

형상 관리 절차

  • 형상 관리는 최초 계획을 수립하고 형상 식별, 통제, 감사, 기록 및 보고와 같은 활동들을 통해 일련의 과정들을 거치게 된다.
  1. 형상 식별(Configuration Identification)
    • 형상 관리의 가장 기본이 되는 활동으로 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정이다.
    • 변경 추적성 부여와 대상 식별을 위해 ID와 관리 번호를 할당한다.
    • 형상 항목 대상 : 품질 관리 계획서, 품질 관리 메뉴얼, 요구사항 명세서, 설계/인터페이스 명세서, 테스트 설계서, 소스 코드
  2. 형상 통제
    • 형상통제위원회 운영을 통하여 변경 통제가 이루어져야 한다.
    • 요구사항 변경 요구를 관리하고, 변경 제어, 형상 관리 등의 통제를 지원하고 기준선에 대한 관리 및 형상 통제를 수행할 수 있다.
  3. 형상 보고 및 감사
    • 기준선의 무결성 평가 단계로서 개발자, 유지보수 담당자가 아닌 제3자의 객관적인 확인 및 검증 과정을 통해 새로운 형상의 무결성을 확보하는 활동이다. -형상 감사 시 고려사항 - 명시된 변경이 정확하게 수정되었는가? - 기술 검토를 수행하였는가? - 개발 프로세스를 준수하였는가? - 변경 발생 시, 형상 관리 절차를 준수하였는가? - 변경에 대한 정보(변경일, 변경인, 변경사항)를 기록하였는가?
  4. 형상 기록/보고
    • 소프트웨어 개발 상태에 대한 보고서를 제공하는 단계로 기준선에 대한 변경과 처리 과정에서의 변경을 상태 보고에 모두 기록한다.
    • 기록/보고 항목 : 승인된 형상 리스트, 계획된 변경 상태, 승인된 변경의 구현 상태

형상 관리, 버전 관리, 변경 관리

형상 관리 (Configuration Management)버전 관리 (Version Management)변경 관리(Version Management)
버전, 변경 관리 개념을 포함하고, 프로젝트 진행 상황, 빌드와 릴리즈 퍼블리싱까지 모두 관리할 수 있는 통합 시스템이라고 할 수 있다.변경 이력을 추적 관리하는 가장 좋은 방법이 버전으로 구분하는 것이다. 사소한 체크인, 체크아웃부터 릴리즈, 퍼블리싱의 과정을 버전으로 관리한다.소스 코드의 변경 상황을 관리한다. 문서의 변경 이력과 복원 등의 기능이 제공된다.

주요 버전 관리 도구

  • CVS(Concurrent Versions System)
    • 동시 버전 시스템이다.
    • 소프트웨어 프로젝트를 진행할 때, 파일로 이뤄진 모든 작업과 모든 변화를 추적하고, 여러 개발자가 협력하여 작업할 수 있게 한다.
    • 오픈소스 프로젝트에서 널리 사용되었다.
    • 최근에는 CVS가 한계를 맞아 이를 대체하는 Subversion이 개발되었다.
  • RCS(Revision Control System)
    • CVS와의 차이점은 소스 파일의 수정을 한 사람만으로 제한한다.
    • 다수의 사용자가 동시에 파일 수정을 할 수 없도록 파일 잠금 방식으로 버전을 관리하는 도구이다.
  • SubVersion(SVN)
    • CVS보다 속도 개선, 저장 공간, 변경 관리 단위가 작업 모음 단위로 개선되었다. 2000년부터 콜랩넷에서 개발되었다.
    • CVS와 사용 방법이 유사해 CVS 사용자가 쉽게 도입해 사용할 수 있다.
    • 아파치 최상위 프로젝트로서 전 세계 개발자 커뮤니티와 함께 개발되고 있다.
    • 디렉토리, 파일을 자유롭게 이동해도 버전 관리가 가능하다.
    • repository(저장소) : 프로젝트의 파일 및 변경 정보가 저장되는 장소이다.
    • trunk : 메인 개발 소스. 개발 소스를 커밋했을 때 개발 소스가 모이는 곳이다.
    • branch : trunk에서 분기된 개발 소스로 실험적인 기능을 추가하거나, 출시를 위한 안정화 버전 작업을 할 때 사용한다.
    • tag : 특정 시점에서 프로젝트의 스냅샷을 찍어 두는 것을 의미한다.
  • Bitkeeper
    • SVN과 비슷한 중앙 통제 방식으로 대규모 프로젝트에서 빠른 속도를 내도록 개발된 버전 관리 도구이다.
  • Git
    • 프로그램 등의 소스 코드 관리를 위한 분산 저장소 방식 시스템이다.
    • 리누스 토르발스가 리눅스 커널 개발에 이용하려고 개발하였으며, 현재는 다른 곳에도 널리 사용되고 있다.
    • 지역 저장소와 원격 저장소 2개의 저장소가 존재한다.
    • 지역 저장소에서 버전 관리가 진행되어 버전 관리가 빠르다.
    • 깃의 작업 폴더는 모두 전체 기록과 각 기록을 추적할 수 있는 정보를 포함하고 있으며, 완전한 형태의 저장소이다.
    • 네트워크에 접근하거나 중앙 서버에 의존하지 않는다.
  • Clear Case
    • 복수 서버, 복수 클라이언트 구조이다.
    • 서버 확장 요구가 있을 때 필요한 서버를 하나씩 추가할 수 있다.

애플리케이션 테스트 관리 ★★★

소프트웨어 테스트

  • 소프트웨어 개발 단계에서 사용자 요구사항에 서술된 동작과 성능, 사용성, 안정성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동으로 품질 향상, 오류 발견, 오류 예방 관점에서 수행하는 행동이다.
  • 품질 향상 관점 : 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증 활동이다.
  • 오류 발견 관점 : 잠재된 오류를 발견하고 이를 수정하여 올바를 프로그램을 개발하는 활동이다.
  • 오류 예방 관점 : 코드 리뷰, 동료 검토, 인스펙션 등을 통해 오류를 사전에 발견하는 활동이다.

소프트웨어 테스트의 원리

  • 테스팅은 결함이 존재함을 밝히는 활동이다.
    • 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타낸다.
  • 완벽한 테스팅은 불가능하다.
    • 무한 경로, 무한 입력값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중하는 것을 의미한다.
  • 테스팅은 개발 초기에 시작해야 한다.
    • 애플리케이션의 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻이다.
  • 결함 집중(Defect Clustering)
    • 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다. 파레토 법칙이 좌우한다.
  • 살충제 역설(Pesticide Paradox)
    • 동일한 테스트 케이스로 반복 테스트 시 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다.
  • 테스팅은 정황(Context)에 의존한다.
    • 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다.
  • 오류 부재의 궤변(Absence of Errors Fallacy)
    • 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해도, 해당 애플리케이션의 품질이 높다고 말할 수 없다.

파레토의 법칙(Law of Pareto)

  • 80 대 20 법칙 또는 2:8 법칙이라고도 한다. 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다. 예를 들어 20%의 VIP 고객이 백화점 전체 매출의 80%에 해당하는 만큼 쇼핑하는 현상을 의미한다.

테스트 케이스(Test Case)

  • 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서를 의미한다.
  • 명세 기반 테스트의 설계 산출물이다. (명세 기반 테스트 : 테스트 수행의 증거로도 활용되며, 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인)
  • 테스트 케이스를 설계 단계에 작성하면 테스트 시 오류를 방지하고, 테스트 수행에 있어 낭비를 줄일 수 있다.
  • 표준 테스트 케이스 형식
  1. 테스트 계획 검토 및 자료 확보
  2. 위험 평가 및 우선 순위 결정
  3. 테스트 요구사항 정의
  4. 테스트 구조
  5. 설계 및 테스트 방법 결정
  6. 테스트 케이스 정의
  7. 테스트 케이스 타당성 확인 및 유지보수

테스트 케이스의 구성 요소(ISO/IEC/IEEE 29119-3)

  • 식별자(Identifier)
  • 테스트 항목(Test Item)
  • 입력 명세(Input Specification)
  • 출력 명세(Output Specification)
  • 환경 설정(Environmental Needs)
  • 특수 절차 요구(Special Procedure Requirement)
  • 의존성 기술(Inter-case Dependencies)

테스트 프로세스(Test Process)

계획 및 제어 => 분석 및 설계 => 구현 및 실행 => 평가 => 완료

테스트 커버리지(Test Coverage)

  • 테스트 수행 정도로서 구문 커버리지, 결정 커버리지, 조건 커버리지, 조건/결정 커버리지, 변경 조건/결정 커버리지, 다중 조건 커버리지로 구분한다.

테스트 오라클(Test Oracle)

  • 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참(True) 값을 입력하여 비교하는 기법 및 활동을 말한다.
  • True 오라클
    • 모든 입력값에 대하여 적합한 결과를 생성하여, 발생한 오류를 모두 검출 할 수 있는 오라클이다.
  • 일관성 검사(Consistent) 오라클
    • 애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인하는 오라클이다.
  • 샘플링(Sampling) 오라클
    • 임의로 선정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공한다.
  • 휴리스틱(Heuristic) 오라클
    • 샘플링 오라클을 개선한 오라클로, 임의 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리한다.

테스트

테스트 레벨

  • 애플리케이션 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 설치 테스트로 분류한다.
  • 애플리케이션을 테스트하기 위한 총체적으로 관리하기 위한 테스트 활동의 묶음이다.
  • 각각의 테스트 레벨은 서로 독립적, 각각 다른 테스트 계획과 전략이 필요하다.

테스트 레벨의 종류

  • 단위 테스트
    • 개발자가 원시 코드를 대상으로 각각의 단위를 다른 부분과 연계되는 부분은 고려하지 않고 단위 자체에만 집중하여 테스트한다.
    • 객체지향에서 클래스 테스팅이 여기에 해당한다.
  • 통합 테스트
    • 단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트 간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트한다.
  • 시스템 테스트
    • 단위/통합 테스트가 가능한 완벽히 완료되어 기능상 문제가 없는 상태에서 실제 환경과 가능한 유사한 환경에서 진행된다.
    • 시스템 성능과 관련된 요구사항이 완벽하게 수행되는지를 테스트하기 때문에 사전 요구사항이 명확해야 한다.
    • 개발 조직과는 독립된 테스트 조직에서 수행한다.
  • 인수 테스트
    • 일반적인 테스트 레벨의 가장 마지막 상위 레벨로, SW 제품에 대한 요구사항이 제대로 이행되었는지 확인하는 단계이다.
    • 테스팅 환경을 실 사용자 환경에서 진행하며 수행하는 주체가 사용자이다.
    • 알파, 베타 테스트와 가장 밀접한 연관이 있다.

알파/베타 테스트

  • 알파 테스트
    • 개발자 관점에서 수행되며, 사용상의 문제를 반영되도록 하는 테스트이다.
    • 개발자의 장소에서 사용자가 개발자 앞에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법이다.
    • 개발자는 사용상의 문제를 기록하여 반영되도록 하는 테스트이다.
  • 베타 테스트
    • 선정된 다수의 사용자가 자신들의 시용 환경에서 일정 기간 사용하면서 테스트한다.
    • 문제점이나 개선 사항 등을 기록하고 개발 조직에 통보하여 반영되도록 하는 테스트이다.

정적 테스트

  • 애플리케이션을 직접 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 방식이다.
  • 소프트웨어 개발 초기에 결함 발견이 가능하여, 개발 비용을 낮출 수 있다.
  • 종류 : Inspection, walk-through, Code Test, Orthogonal Array Testing, Prior Defect History Testing, Risk-Based Testing, Run Chart, Statistical Profile Testing

동적 테스트

  • 애플리케이션을 직접 실행하여 오류를 찾는 테스트 방식이다.
  • 소프트웨어 개발의 모든 단계에서 테스트를 수행한다.
  • 종류 : 블랙박스 테스트(명세 기반), 화이트박스 테스트(구조 기반)

테스트 기반(Test Bases)에 따른 테스트

  • 구조 기반 테스트
    • 소프트웨어 내부의 구조(논리 흐름)에 따라 테스트 케이스를 작성하고 확인하는 테스트 방식이다.
    • 종류 : 구문 기반, 조건 기반, 데이터 흐름
  • 명세 기반 테스트
    • 사용자의 요구사항에 대한 명세를 기반으로 테스트 케이스를 작성하고 확인하는 테스트 방식이다.
    • 종류 : 동등 분할, 경계값 분석, 분류 트리, 상태 전이, 결정 테이블, 원인-결과, 조합 테스트, 시나리오, 오류 추정
  • 경험 기반 테스트
    • 테스터의 경험을 기반으로 수행하는 테스트 방식이다.
    • 요구사항에 대한 명세가 미흡하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적이다.
    • 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅

목적에 따른 테스트

  • 성능(Performance) : 소프트웨어의 응답 시간, 처리량 등을 테스트한다.
  • 회복(Recovery) : 소프트웨어에 고의로 부하를 가하여 실패하도록 유도하고 올바르게 복구되는지 테스트한다.
  • 구조(Structured) : 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가한다.
  • 회귀(Regression) : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인한다.
  • 안전(Security) : 소프트웨어가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인한다.
  • 강도(Stress) : 소프트웨어에 과도하게 부하를 가하여도 소프트웨어가 정상적으로 실행되는지 확인한다.
  • 병행(Parallel) : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 두 결과를 비교/확인한다.

테스트 기법

화이트박스 테스트(White Box Test)

  • 모듈의 원시 코드를 오픈시킨 상태에서 코드의 논리적 모든 경로를 테스트하는 방법이다.
  • Source Code의 모든 문장을 한 번 이상 수행하여 모듈 안의 작동을 직접 관찰할 수 ㅅ있다.
  • 산출물의 기능별로 적절한 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검한다.

화이트박스 테스트 종류

  1. 기초 경로 검사(Base Path Testing)
  2. 제어 구조 검사

화이트박스 테스트 검증 기준

  • 문장 검증 기준 : 소스 코드의 모든 구분이 한 번 이상 수행된다.
  • 분기 검증 기준 : 소스 코드의 모든 조건문이 한 번 이상 수행된다.
  • 조건 검증 기준 : 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행된다.
  • 분기/조건 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우 한 번 이상 수행된다.

블랙박스 테스트(Black Box Test)

  • 블랙박스 테스트는 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트로 기능 테스트라고도 한다.
  • 요구사항 명세를 보면서 테스트하며, 주로 구현된 기능을 테스트한다.
  • 소프트웨어 인터페이스에서 실시되는 테스트이다.

블랙박스 테스트 종류

  1. 동치 분할 검사(Equivalence Partitioning)
    • 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법이다.
    • 입력 조건에 타당한 입력 자료와 그렇지 않은 자료의 개수를 균등하게 분할해 테스트 케이스를 설정한다.
  2. 원인-효과 그래프 검사(Cause and Effect Graphing)
    • 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한다.
    • 효용성이 높은 테스트 케이스를 선정해 검사한다.
  3. 오류 예측 검사(Error Forecast)
    • 과거의 경험이나 감각으로 테스트하는 기법이다.
    • 다른 테스트 기법으로는 찾기 어려운 오류를 찾아내는 보충적 검사 기법이다.
  4. 비교 검사(Comparision Testing)
    • 동일한 테스트 자료를 여러 버전의 프로그램에 입력하고 동일한 결과가 출력되는지 테스트하는 기법이다.
  5. 경계값 분석(Boundary Value Analysis)
    • 입력 자료에만 치중한 동치 분할 기법을 보완한 기법이다.
    • 입력 조건 경계값에서 오류 발생 확률이 크다는 것을 활용하여 경계값을 테스트 케이스로 선정해 검사한다.
    • 대표적인 명세 기반 기법(Specification based Technique)이다.

단위/통합 테스트

단위 테스트

  • 소프트웨어 최소 기능 단위인 모듈, 컴포넌트를 테스트하는 것으로 사용자의 요구사항을 기반으로 한 기능 테스트를 제일 먼저 수행한다.
  • 인터페이스, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 결제 조건 등을 테스트한다.
  • 구조 기반 테스트와 명세 기반 테스트로 분류할 수 있으나 주로 구조 기반 테스트를 시행한다.

통합 테스트(Integration Test)

  • 각 모듈 간을 결합하여 시스템을 완성시키는 과정에서 모듈 간 인터페이스 혹은 통합된 컴포넌트 간 상호작용 오류 및 결함을 찾아 해결하기 위한 테스트 기법이다.
  • 통합 방식
    • 비점진적 통합 방식(빅뱅 통합)
      • 모든 모듈이 결합된 프로그램 전체를 대상으로 테스트한다.
      • 규모가 작은 소프트웨어에 적합하다.
      • 오류 발견/장애 위치 파악 또는 수정이 어렵다.
    • 점진적 통합 방식(상향식/하향식)
      • 단계적으로 통합하며 테스트한다.
      • 오류 수정이 쉽다.
      • 인터페이스 관련 오류를 테스트할 수 있다.

하향식 통합

  • 상위 컴포넌트를 테스트하고 점증적으로 하위 컴포넌트를 검사한다.
  • 주요 제어 모듈 기준으로 아래로 통합하며 진행한다.
  • 하위 컴포넌트 개발이 완료되지 않은 경우 스텁(Stub)을 사용하기도 한다.
  • 우선 통합법, 깊이 우선 통합법, 넓이 우선 통합법 등이 있다.
  • 하위 레벨 모듈들은 특정한 소프트웨어 부가 기능을 수행하는 클러스터들에 결합된다.

상향식 통합

  • 프로그램 구조에서 최하위 레벨인 모듈을 구성하고 상위 모듈 방향으로 통합하며 검사한다.
  • 가장 하위 단계의 모듈부터 수행되므로 스터브가 필요 없으나 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터가 필요하다.(Driver 사용)

빅뱅 통합

  • 시스템을 구성하는 모듈을 각각 따로 구현하고 전체 시스템을 한 번에 테스트를 진행한다.
  • 테스트를 위한 Driver와 Stub 없이 실제 모듈들로 테스트를 진행한다.
  • 단시간 테스트를 수행하나 결함의 격리가 어려운 방식이다.

샌드위치 통합

  • 상향식과 하향식의 장점을 이용하는 방식(하향식 + 상향식)이다.
  • 하위 프로젝트가 있는 대규모 프로젝트에 사용하는 방식이다.
  • 병렬 테스트가 가능하고 시간 절약이 가능하다.
  • 스텁(Stub)과 드라이버(Driver)의 필요성이 매우 높은 방식이며, 비용이 많이 들어간다.

애플리케이션 성능 개선

성능 측정 지표

  • 처리량(Throughput) : 주어진 시간에 처리할 수 있는 프로세스 처리 수
  • 응답 시간(Response Time) : 데이터 입력 완료 시부터 응답 출력이 개시될 때까지의 시간
  • 경과 시간(Turnaround Time) : 입력한 시점부터 그 결과의 출력이 완료할 때까지 걸리는 시간
  • 자원 사용률(Resource Usage) : 프로세스 처리 중 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량

유형별 성능 분석 도구

  • 성능/부하/스트레스(Performance/Load/Stress) 정검 도구 : 측정 지표인 처리량, 응답 시간, 경과 시간 등을 점검하기 위해 가상의 시스템 부하나 스트레스를 통해 성능을 분석하는 도구이다.
  • 모니터링(Monitoring) 도구 : 성능 모니터링, 성능 저하 원인 분석, 시스템 부하량 분석, 장애 진단, 사용자 분석, 용량 산정 등의 기능을 통하여 애플리케이션 실행 시 자원 사용량을 확인하고 분석 가능한 도구이다.

애플리케이션 성능 저하 원인

DB 연결 및 쿼리 실행 시 발생되는 성능 저하 원인

  1. DB Lock
    • 과도한 데이터 조회/업데이트/인덱스 생성 시 발생한다.
    • Lock의 해제 시까지 대기하거나 처리되지 못하고 종료된다.
  2. 불필요한 DB Fetch
    • 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우 발생한다.
    • 결과 세트에서 마지막 위치로 커서를 옮기는 작업이 빈번한 경우 응답 시간 저하 현상이 발생한다.
  3. 연결 누수(Connection Leak)
    • DB 연결과 관련한 JDBC 객체를 사용 후 종료하지 않을 경우 발생한다.
  4. 부적절한 Connection Pool Size
    • 커넥션 풀 크기가 너무 작거나 크게 설정한 경우 발생한다.
  5. 기타
    • 트랜잭션이 Commit되지 않고 커넥션 풀에 반환되거나, 잘못 작성된 코드로 인해 불필요한 commit이 자주 발생하는 경우 발생한다.

내부 로직으로 인한 성능 저하 원인

  • 웹 애플리케이션의 인터넷 접속 불량이나 대량의 파일로 인해 부하가 발생하는 경우이다.
  • 정상적으로 처리되지 않은 오류 처리로 인한 부하나 트랜잭션이 수행되는 동안 외부 트랜잭션(외부 호출)이 장시간 수행되거나, 타임아웃이 일어나는 경우이다.

잘못된 환경 설정이나 네트워크 문제로 인한 성능 저하 원인

  • 환경 설정으로 인한 성능 저하 : Thread pool, Heap Memoty의 크기를 너무 작게 설정하면 Heap Memory Full 현상이 발생한다.
  • 네트워크 장비로 인한 성능 저하 : 라우터, L4 스위치 등 네트워크 관련 장비 간 데이터 전송 실패 또는 전송 지연에 따른 데이터 손실이 발생한다.

알고리즘

  • 주어진 과제를 해결하기 위한 방법과 절차를 의미한다.
  • 알고리즘은 자연어, 의사코드(Pseudocode), 순서도, 프로그래밍 언어를 이용하여 표현 가능하다.
  1. 분할 정복법(Divide & Conquer)
    • 제시된 문제를 분할이 불가할 때까지 나누고, 각 과제를 풀면서 다시 병합해 문제의 답을 얻는 Top-down 방식이다.
    1. 분할(Divide) : 정복이 필요한 과제를 분할이 가능한 부분까지 분할하고,
    2. 정복(Conquer) : 1에서 분할된 하위 과제들을 모두 해결(정복)한다.
    3. 결합(Combine) : 그리고 2에서 정복된 해답을 모두 취합(결합)한다.
    • ex. Quick sort, Merge sort 알고리즘
  2. 동적 계획법(Dynamic Programming)
    • 주어진 문제를 해결하기 위해 부분 문제에 대한 답을 계속적으로 활용해 나가는 Bottom-up 방식이다.
      1. 부분 문제로 분리
      2. 가장 낮은 단계의 부분 문제 해답 계산
      3. 이 부분 문제의 해답을 이용해 상위 부분 문제를 해결
    • 이전 단계의 해답을 활용하기 위해 반드시 기억할 수 있는 저장소가 필요하기 때문에 속도는 빠르지만, 공간 복잡도가 커지는 단점이 있다.
    • ex. 플로이드 알고리즘, 피보나치 수열 알고리즘(재귀 호출(동적 계획법) 뿐만 아니라 분할 정복법을 통해서도 구현 가능)
  3. 탐욕법(Greedy Method)
    • 국소적인 관점에서 최적의 해결 방법을 구하는 기법으로 최적의 해결 방법을 구하지는 못하나 동적 계획법보다 효율적이라고 할 수 있다.
    • ex. 크루스칼 알로리즘, 다익스트라 알고리즘
  4. 백트래킹(Back tracking)
    • 어떤 문제의 최적해를 구하기 위해 모든 가능성을 찾아가는 방법이다.
    • N-Queen 문제 해결 시에 응용된다. -동적 계획법과 같이 기억할 저장소를 필요로 한다.
  5. 분기 한정법(Branch & Bound)
    • 정해진 범위(Bound)를 벗어나는 값들은 가지치기(Branch)해가며 결과값을 추적해 나가는 방식이다.
    • ex. 최적 우선 탐색(Best First Search) 알고리즘, A* 알고리즘
  6. 근사 해법(Approximation Algorithm)
    • 복잡도가 매우 높은 문제게 대해 가장 근사치의 값을 구하는 기법이다.- NP-Hard 문제를 해결하기 위해, 주어진 시간에 최적해를 가장 가까운 답을 찾는 결정성 알고리즘을 구현하는 기법이다.
    • 시간 복잡도, 공간 복잡도, 정밀도를 척도로 평가된다.
    • ex. 근사 알고리즘

시간 복잡도에 따른 알고리즘

  • 시간 복잡도는 알고리즘이 문제를 해결하기 위한 시간(연산)의 횟수를 말한다.
  • 시간 복잡도를 고려하는 것을 최적화를 위해 필요하다.
  • 알고리즘의 소요 시간에 대한 정확한 평가는 어려워 자료의 수 n이 증가할 때 시간이 증가하는(Time Complexity) 대략적인 패턴을 의미한다.
  • 시간 복잡도 Big-O 표기법
    • O(1) : 상수 시간의 복잡도를 의미하며 입력값 n이 주어졌을 때, 문제를 해결하는데 오직 한 단계만 거친다.(해시 함수).
    • O(log₂n) : 로그 시간의 복잡도를 의미하며 입력값 n이 주어졌을 때, 문제를 해결하는데 필요한 단계들이 연산마다 특정 요인에 의해 줄어든다.(이진 탐색)
    • O(nlog₂n) : 선형 로그 시간의 복잡도를 의미하며, 문제 해결을 위한 단계 수는 n log2 n 번의 수행 시간을 갖는다.(퀵 정렬, 병합 정렬)
    • O(n) : 선형 시간의 복잡도를 의미하며 문제를 해결하기 위한 단계의 수와 입력값 n이 1:1 관계이다.(순차 탐색)
    • O(n²) : 제곱 시간의 복잡도를 의미하며 문제를 해결하기 위한 단계의 수는 입력값 n의 제곱근이다.(버블 정렬, 삽입 정렬, 선택 정렬)
    • O(Cⁿ) : 지수 시간의 복잡도를 의미하며 문제를 해결하기 위한 단계의 수는 주어진 상수값 C의 n 제곱이다.

소스 코드 최적화

  • 읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성하는 것을 의미한다.
  • 소스 코드 품질을 위해 기본적으로 지킬 원칙과 기준을 정의하고 있다.
  • 나쁜 코드
    • 다른 개발자가 로직을 이해하기 어렵게 작성된 코드
    • 변수/메서드에 대한 명칭을 알 수 없는 코드이다. -동일한 처리 로직이 중복되게 작성된 코드이다.
    • 스파게티 코드
    • 유형 : 오염, 문서 부족, 의미 없는 이름, 높은 결합도, 아키텍처 침식
  • 클린 코드
    • 깔끔하게 잘 정리된 코드
    • 중복 코드 제거로 애플리케이션의 설계가 개선된다.
    • 가독성이 높아 애플리케이션의 기능에 대해 쉽게 이해할 수 있다.
    • 버그를 찾기 쉬워지며, 프로그래밍 속도가 빨라진다.
    • 클린 코드 최적화 원칙 : 가독성, 단순성, 의존성 배제, 중복성 취소화, 추상화
    • 유형 : 보기 좋은 배치, 작은 함수, 분석 가능한 제어 흐름, 오류 처리, 간결한 주석, 의미 있는 이름

코드 간결성 유지 지침

  • 공백을 이용하여 실행문 그룹과 주석을 명확히 구분하고, 복잡한 논리식과 산술식은 괄호와 들여쓰기(Indentation)를 통해 명확히 표현한다.
  • 빈 줄을 사용하여 선언부와 구현부를 구별하고 한 줄에 되도록 적은 문장을 코딩한다.

클린 코드의 작성 원칙

  • 가독성 : 이해하기 쉬운 용어를 사용하고 들여쓰기 등을 활용하여 코드를 쉽게 읽을 수 있도록 작성한다.
  • 단순성 : 클래스/메서드/함수는 최소 단위로 분리해 한 번에 한 가지 기능만 처리한다.
  • 의존성 배체 : 다른 모듈에 미치는 영향을 최소화하여 코드 변경 시 다른 부분에 영향이 없도록 작성한다.
  • 중복성 최소화 : 중복된 코드는 삭제하여 공통된 코드로 사용한다.
  • 추상화 : 상위 클래스/메서드/함수에서 간략하게 애플리케이션 특성을 나타내고, 상세 내용은 하위 클래스/메서드/함수에서 구현한다.

소스 코드 최적화 유형

  1. 클래스 분할 배치
    • 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이도록 한다.
    • 모듈 크기를 작게 작성한다.
  2. 좋은 이름 사용
    • 변수나 함수 이름은 Namming Rule을 정의하여 기억하기 좋고, 발음이 쉽게 사용한다.
  3. 코딩 형식 준수
    • 개념적 유사성 높은 종속 함수를 사용하여 논리적으로 코드를 라인별로 구분하여 가독성을 높이다.
    • 호출하는 함수 앞쪽에, 호출되는 함수를 배치하고, 지역 변수는 각 함수 맨 처음에 선언한다.
  4. 느슨한 결합(Loosely Coupled)
    • 클래스 간 의존성이 느슨하게 하기 위해 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메서드를 구현한다.
  5. 적절한 주석
    • 코드의 간단한 기능 안내 및 중요 코드를 표시할 때 적절히 사용한다.

인터페이스 구현

  • 송/수신 시스템 간의 데이터 교환 및 처리를 실현해주는 작업이다.
  • 사전에 정의된 기능 구현을 분석하고 인터페이스를 구현한다.
  • 인터페이스 기능 구현을 기반으로 인터페이스 구현 방법을 분석하고 분석된 인터페이스 구현 정의를 바탕으로 인터페이스를 구현한다.

AJAX(Asynchronous Javascript And Xml)

  • javascript를 사용한 비동기 통신 기술로 클라이언트와 서버 간에 XML 데이터를 주고받는 기술이다.
  • 브라우저가 가지고 있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법이다.

JSON(Javascript Object Notation)

  • 데이터 통신을 이용한 인터페이스 구현 방법이다.
  • 웹과 컴퓨터 프로그램에서 용량이 적은 데이터를 교환하기 위해 데이터 객체를 속성/값의 쌍 형태로 표현하는 형식으로 JS를 토대로 개발된 형식이다.
  • 속성/값의 쌍(Attribute-Value Pairs)인 데이터 객체 전달을 위해 사람이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷으로 비동기 처리에 쓰이는 AJAX에서 XML을 대체하는 주요 데이터 포맷이다.

인터페이스 보안

  • 모듈 컴포넌트 간 데이터 교환 시 데이터 변조/탈취 및 인터페이스 모듈 자체의 보안 취약점이 존재할 수 있다.
  1. 데이터 통신 시 데이터 탈취 위협
    • 스니핑(Sniffing) : 네트워크 주변을 지나다니는 패킷을 엿보면서 계정(ID)과 비밀번호를 알아내는 보안 위협이다.
    • 스푸핑(Spoofing) : 일반 사용자가 인터넷상에서 통신하는 정보를 크래커의 사이트를 통하도록 하여 비밀번호를 알아내는 보안 위협이다.
  2. 데이터베이스 암호화
    • 데이터베이스의 기밀성을 유지하기 위해 중요 민감 데이터는 암호화한다.
    • 대칭 키, 해시, 비대칭키 알고리즘이 사용된다.
  3. 시큐어 코딩
    • OWASP(Open Web Application Security Project) Top 10을 참고하여 KISA(한국 인터넷 진흥원)에서 SW 보안 약점 가이드를 발표하였다.
    • SW 보안 취약점, 약점 및 대응 방안이 구체적으로 서술되어 있으며 이를 바탕으로 시큐어 코딩을 하도록 한다.

데이터베이스 보안

  • 데이터베이스의 기밀성 유지를 위하여 중요하고 민감한 데이터는 암호화 기법을 활용하여 암호화하도록 한다.
  • 데이터베이스의 접근 권한 및 SQL, 프로시져, 트리거 등 데이터베이스 동작 객체의 보안 취약점을 보완하도록 한다.
  • 민감하고 중요한 데이터는 암호화와 익명화 등을 통하여 데이터 자체 보안 방법도 고려해야 한다.
  • 영역 : 비인가자 접근 관리, 악의적 코드 삽입 금지, 민감 데이터 관리, 악의적 시도 시 에러 처리

데이터베이스 암호화 알고리즘

  • 대칭키 알고리즘 : ARIA 128/129/256, SEED
  • 해시 알고리즘 : SHA-256/384/512, HAS-160
  • 비대칭키 알고리즘 : RSA, ECDSA, ECC

참조 : Github repository

정보처리기사 카테고리의 다른 글

    COMMENTS