맨위로가기

소프트웨어 품질

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 품질은 소프트웨어의 신뢰성, 효율성, 보안, 유지보수성 등을 포괄하는 개념으로, 위험 관리 및 비용 관리 측면에서 중요하다. 소프트웨어의 실패는 인명 피해와 막대한 경제적 손실을 초래할 수 있으며, 낮은 품질은 유지보수 비용 증가, 데이터 손상, 보안 침해로 이어진다. 소프트웨어 품질은 ISO, ASQ, NIST, PMI 등 다양한 표준화 기구/단체에서 정의하며, 제품 품질, 사용 품질, 공정 품질로 구분된다. 소프트웨어 품질은 또한 기술적 품질과 사용자의 경험 모두를 포함하며, 이해 가능성, 완전성, 간결성, 이식성 등 다양한 요인에 의해 결정된다.

더 읽어볼만한 페이지

  • 시스템 과학 - 동조
    동조는 개인의 지각, 의견, 행동을 사회적 규범에 맞춰 변화시키는 경향을 의미하며, 사회의 안정성을 위한 기능과 개인의 주체성 상실이라는 양면성을 지닌다.
  • 시스템 과학 - 델파이 기법
    델파이 기법은 전문가들의 의견을 반복적인 피드백을 통해 수렴하여 문제를 해결하는 하향식 의견 도출 방법으로, 익명성, 정보 흐름의 구조화, 정기적인 피드백을 특징으로 하며 다양한 분야에서 활용된다.
  • 소프트웨어 품질 - 신뢰성 공학
    신뢰성 공학은 제품이나 시스템이 정해진 기간 동안 지정된 조건에서 의도된 기능을 수행할 확률을 다루는 공학 분야이며, 확률, 의도된 기능, 기간, 조건을 고려하여 시스템의 신뢰성을 높이고, 신뢰성 시험 및 다양한 기법을 활용하여 안전 공학 및 제조업 분야에서 중요한 역할을 한다.
  • 소프트웨어 품질 - 정확성
    프로그램이나 시스템이 의도한 대로 작동하는지를 나타내는 컴퓨터 과학 및 철학의 개념인 정확성은 알란 튜링의 정지 문제와 같은 컴퓨터 과학의 근본적인 문제와 관련되어 철학적 논의의 대상이 된다.
  • 소스 코드 - 헤더 파일
    헤더 파일은 프로그래밍 언어에서 코드 재사용성, 모듈화, 컴파일 시간 단축에 기여하며 함수 프로토타입, 변수 선언 등을 포함하고 `#include` 지시어로 소스 코드에 포함되어 사용되는 파일이다.
  • 소스 코드 - 헝가리안 표기법
    헝가리안 표기법은 변수 이름에 데이터 타입이나 목적을 나타내는 접두사를 붙이는 명명 규칙으로, 찰스 시모니가 고안하여 마이크로소프트에서 널리 사용되었으나, 코드 가독성 향상에 대한 유용성 논란과 함께 최신 IDE 환경에서는 불필요하다는 비판도 있다.
소프트웨어 품질
소프트웨어 품질
세부 사항
설명소프트웨어 품질은 기능적 품질과 구조적 품질이라는 두 가지 관련 있지만 구별되는 개념을 나타낸다.
기능적 품질기능적 품질은 일반적으로 다음의 측면에서 측정된다.
소프트웨어 테스트, 결함 수, 또는 요구 사항 충족 여부와 같은 방식으로 측정된다.
이것은 사용자가 인식할 수 있는 것이다.
구조적 품질구조적 품질은 코드의 줄 수당 평균 결함 수와 같이 측정된다.
이는 사용자가 직접적으로 인식할 수 없지만, 기능적 품질의 유지보수성 또는 신뢰성과 같은 특징에 영향을 미친다.
품질 속성안정성, 보안, 유지보수성 및 성능과 같은 다양한 품질 속성들이 있다.
이러한 속성들은 소프트웨어의 성공에 중요한 역할을 한다.
품질 보증 및 통제
설명소프트웨어 품질은 소프트웨어 품질 보증 및 소프트웨어 품질 통제와 같은 실천을 통해 보장되고 유지될 수 있다.
표준
설명소프트웨어 품질은 ISO/IEC 9126과 ISO/IEC 25010과 같은 표준에 의해 공식화될 수 있다.
CISQ(정보 및 소프트웨어 품질 컨소시엄)은 소프트웨어의 크기 및 구조적 품질을 측정하기 위한 표준을 제공한다.
관련 용어
설명소프트웨어 품질은 소프트웨어 버그와 관련이 있다.
외부 링크
설명정보기술 시스템 품질 컨소시엄 (CISQ)

2. 소프트웨어 품질의 정의 및 중요성

소프트웨어 품질은 소프트웨어가 의도된 목적에 부합하고 사용자의 기대를 충족하는 정도를 나타내며, 다양한 관점에서 정의될 수 있다. 소프트웨어 품질은 크게 위험 관리와 비용 관리 측면에서 그 중요성이 강조된다.


  • 위험 관리: 소프트웨어 오류는 단순한 불편함을 넘어, 보잉 737 사건, 의도하지 않은 가속 사건,[22][23] Therac-25 사건[24]과 같이 인명 피해를 야기할 수 있다. (소프트웨어 버그 목록 참조) 이러한 이유로, 특히 의료 기기나 중요한 기반 시설을 제어하는 임베디드 소프트웨어에는 엄격한 품질 요구 사항이 적용된다. 미국 연방 항공국(FAA)은 항공 제품에 사용되는 소프트웨어에 대한 지침을 제공하며,[26] DO-178C, ISO 26262, IEC 62304 등의 인증 표준이 활용된다.
  • 비용 관리: 우수한 품질의 소프트웨어는 유지보수 비용이 적게 들고, 비즈니스 요구 변화에 더 효율적으로 대응할 수 있다.[27] 산업 데이터에 따르면, 전사적 자원 관리(ERP)나 고객 관계 관리(CRM) 같은 핵심 비즈니스 애플리케이션에서 낮은 품질의 소프트웨어 구조는 비용 및 일정 초과, 재작업( 무다 (일본어 용어) 참조) 등의 낭비를 초래한다.[28][29][30] 또한, 낮은 소프트웨어 구조 품질은 데이터 손상, 애플리케이션 중단, 보안 문제, 성능 저하 등 비즈니스 중단을 야기할 수 있다.[31]


CISQ의 추정에 따르면, 2020년 소프트웨어 품질 저하로 인한 비용은 2.08조달러에 달했다.[32][33] IBM 보고서에 따르면, 2020년 데이터 침해의 평균 글로벌 비용은 386만달러였다.[34][35]

2. 1. ISO, ASQ, NIST, PMI 등 표준화 기구/단체의 정의

미국 품질 협회(ASQ)는 '소프트웨어 품질'을 소프트웨어 제품의 바람직한 속성을 설명하는 것이라고 정의한다. 여기에는 결함 관리와 품질 속성이라는 두 가지 주요 접근 방식이 있다.[42]

프로젝트 관리 협회(PMI)의 PMBOK 가이드 "소프트웨어 확장"은 소프트웨어 품질 보증(SQA)을 "다른 소프트웨어 프로세스가 제대로 실행되고 있는지 감사하는 지속적인 프로세스(예: 소프트웨어 품질 관리 계획 포함)"으로, 소프트웨어 품질 관리(SCQ)는 "개발 또는 수정 중인 소프트웨어의 품질 요구 사항을 충족하기 위해 방법, 도구, 기술을 적용하는 것을 관리하는 것"으로 정의한다.[44]

소프트웨어 보증(SA)은 소프트웨어의 속성과 이를 달성하기 위한 프로세스 모두를 포함한다.[43]

  • 소프트웨어가 의도적으로 설계되었거나 소프트웨어 수명 주기 동안 우발적으로 삽입된 취약점으로부터 자유롭고, 의도한 대로 기능한다는 정당한 확신
  • 소프트웨어 생명 주기 프로세스와 제품이 요구 사항, 표준 및 절차를 준수하도록 보장하는 계획적이고 체계적인 활동 집합


소프트웨어 품질은 품질 보증, 문제 해결 관리[57], 품질 관리[58], DevOps와 혼동되기도 한다. 그러나 테스트뿐만 아니라 프로세스, 관리, 개선, 평가 등에도 초점을 맞추고 있다는 점에서 뚜렷하게 구별된다.[58]

2. 2. 역사적 정의 및 기타 관점

셰워트는 품질에 대해 "인간의 존재와는 무관한 객관적인 현실로서의 사물의 품질에 대한 고려"와 "객관적인 현실의 결과로 우리가 생각하고, 느끼고, 감지하는 것"이라는 두 가지 측면을 제시했다.[45] 즉, 품질은 객관적인 측면과 주관적인 측면을 모두 가진다.

키친햄과 플리거는 데이비드 가빈의 가르침을 인용하여 품질에 대한 다섯 가지 다른 관점을 제시한다.[46][47]

  • 초월적 관점: 품질은 형이상학적 측면을 다룬다. "우리가 이상으로 추구하지만 완전히 구현하지 못할 수도 있는 어떤 것"으로, 정의하기 어렵지만 "보면 안다".[48][49]
  • 사용자 관점: 주어진 사용 맥락에서 제품의 적절성과 관련이 있다. 사용자 요구를 충족하는 제품 특성에 기반한다.[48]
  • 제조 관점: 품질을 요구 사항 준수로 나타낸다. ISO 9001과 같은 표준에서 강조되며, 품질을 "일련의 고유한 특성이 요구 사항을 충족하는 정도"로 정의한다(ISO/IEC 9001[50]).
  • 제품 관점: 품질이 제품의 고유한 특성을 측정하여 파악할 수 있음을 의미한다.
  • 가치 기반 관점: 다양한 이해 관계자에게 품질의 서로 다른 관점이 서로 다른 중요성 또는 가치를 가질 수 있음을 인식한다.[38]


W. 에드워즈 데밍은 월터 A. 셰워트를 인용하며, 품질을 정의하는 어려움은 "사용자의 미래 요구를 측정 가능한 특성으로 변환하여 제품이 설계되고 생산되어 사용자가 지불할 가격으로 만족을 줄 수 있도록 하는 것"이라고 말했다.[51]

또한 품질은 "고객의 실제 경험을 바탕으로, 명시적이거나 묵시적이거나, 의식적이거나 단지 감지된 것이거나, 기술적으로 작동하거나 완전히 주관적인 요구 사항에 따라 측정되며, 항상 경쟁 시장에서 움직이는 목표를 나타낸다"라고 정의된다.[52]

주란은 품질을 "고객의 요구를 충족시켜 제품 만족을 제공하는 제품 기능"과 "결함이 없는 것"이라는 두 가지 의미로 정의하며, 짧게는 "사용 적합성"으로 정의한다.[53]

톰 드마르코는 "제품의 품질은 제품이 세상을 얼마나 더 좋게 변화시키느냐에 달려 있다"고 제안했다. 이는 기능적 품질과 사용자 만족도가 구조적 품질보다 더 중요하다는 의미로 해석할 수 있다.

제럴드 와인버그는 "품질은 어떤 사람에게 가치가 있는 것이다"라는 정의를 제시했다.[54][55]

"모두가 그것을 이해한다고 느낀다"[56]는 점은 품질을 정의하는 데 있어 어려운 점 중 하나이며, 다른 소프트웨어 품질의 정의는 비즈니스에서 사용되는 품질 개념에 대한 다양한 설명을 확장하는 것을 기반으로 할 수 있다.

2. 3. 소프트웨어 품질의 중요성

소프트웨어 품질은 다음 두 가지 주요 관점에서 중요하게 다루어진다.

  • '''위험 관리''': 소프트웨어 오류는 단순한 불편함을 넘어 인명 피해를 야기할 수 있다. (소프트웨어 버그 목록 참조) 예를 들어, 보잉 737 사건, 의도하지 않은 가속 사건,[22][23] Therac-25 사건[24] 등이 있다. 이러한 위험 때문에, 특히 의료 기기나 중요한 인프라를 제어하는 임베디드 소프트웨어에는 엄격한 품질 요구 사항이 적용된다. 미국 연방 항공국(FAA)은 항공 제품에 사용되는 소프트웨어에 대한 지침을 제공하며,[26] DO-178C, ISO 26262, IEC 62304 등의 인증 표준이 활용된다.
  • '''비용 관리''': 우수한 품질의 소프트웨어는 유지보수 비용이 적게 들고, 비즈니스 요구 변화에 더 효율적으로 대응할 수 있다.[27] 산업 데이터에 따르면, 전사적 자원 관리(ERP)나 고객 관계 관리(CRM) 같은 핵심 비즈니스 애플리케이션에서 낮은 품질의 소프트웨어 구조는 비용 및 일정 초과, 재작업 등의 낭비를 초래한다.[28][29][30] 또한, 낮은 소프트웨어 구조 품질은 데이터 손상, 애플리케이션 중단, 보안 문제, 성능 저하 등 비즈니스 중단을 야기할 수 있다.[31]


CISQ의 추정에 따르면, 2020년 소프트웨어 품질 저하로 인한 비용은 2.08조달러에 달했다.[32][33] IBM 보고서에 따르면, 2020년 데이터 침해의 평균 글로벌 비용은 386만달러였다.[34][35]

3. 소프트웨어 품질의 측정

소프트웨어 품질 측정은 시스템 또는 소프트웨어가 바람직한 특성을 어느 정도 가지고 있는지를 정량화하는 것이다. 이는 질적 또는 양적 수단, 또는 둘의 혼합을 통해 수행할 수 있다. ISO 9126-3 및 후속 ISO/IEC 25000:2005 품질 모델은 소프트웨어 품질 관리에 적용할 수 있는 속성 및 메트릭의 구조, 분류 및 용어를 제공한다.

소프트웨어의 바람직한 특성(오른쪽)과 측정 가능한 속성(왼쪽) 간의 관계


위 그림은 소프트웨어 품질 특성과 측정 가능한 속성 간의 관계를 보여준다. 사용자나 비즈니스 시스템 소유자에게 중요한 특성(오른쪽)은 측정 가능한 속성(왼쪽)에 따라 달라진다. 이러한 속성에는 애플리케이션 아키텍처 및 코딩 관행, 애플리케이션 복잡성, 문서화, 이식성, 기술 및 기능 볼륨 등이 포함된다.

코드 오류의 대부분(92%)은 코드 수준에서 발생하지만, 이로 인한 생산 결함은 10%에 불과하다. 반면, 아키텍처 수준의 문제는 전체 결함의 8%를 차지하지만, 문제 해결에 드는 노력의 절반 이상을 소비하며, 생산에서 심각한 신뢰성, 보안 및 효율성 문제의 90%를 초래한다.[61][62]

기능적 소프트웨어 품질은 주로 소프트웨어 테스팅을 통해 측정되지만,[59] 테스팅만으로는 충분하지 않다. 연구에 따르면 개별 프로그래머는 버그 발견에 50% 미만의 효율성을 보이며, 대부분의 테스팅은 35%의 효율성만을 보인다.[60]

3. 1. 코드 기반 분석

소스 코드 분석을 통해 소프트웨어의 구조적 품질을 측정할 수 있다. 코드 복잡도, 모듈화, 응집도, 결합도, 중복 코드, 코드 스멜 등 다양한 지표가 활용된다.[61][62]

소프트웨어 품질 측정은 주로 소스 코드를 파싱하여 개별 명령어,[63] 토큰,[64] 제어 구조(복잡도), 객체 등의 구조적 요소를 계산한다.[65]

구조적 품질 분석 및 측정은 소스 코드, 아키텍처, 소프트웨어 프레임워크, 데이터베이스 스키마를 시스템의 개념적 및 논리적 아키텍처를 함께 정의하는 원칙 및 표준과의 관계를 통해 수행된다. 이는 주로 구현 고려 사항에 관계하며, 디버깅 및 테스팅 활동 중 중요한 개발 도구에서 일반적으로 수행되는 기본적이고 국지적인 컴포넌트 수준의 코드 분석과는 다르다.

컴퓨터에게는 깔끔하게 작성된 소스 코드라는 개념은 의미가 없다. 그러나 인간에게는 프로그램이 어떻게 작성되었는지는 이를 유지보수할 때 중요한 의미를 갖는다. 다양한 프로그래밍 기법은 가독성이나 언어 고유의 규약을 강조하여 소스 코드의 유지보수성을 향상시키고, 디버깅 및 수정을 용이하게 한다. 그 외에도 잘 작성된 코드라는 개념에는 코드가 관리 가능한 부분으로 논리적으로 분할되어 있다는 것 등도 포함된다.

품질 향상 기법으로는 리팩토링 (프로그래밍)이 있다.

3. 2. 신뢰성 (Reliability)

소프트웨어 신뢰성은 주어진 환경에서 소프트웨어가 오류 없이 정상적으로 작동하는 정도를 나타낸다. 이는 소프트웨어 품질을 측정하는 중요한 척도이자 관점이다.[89] 신뢰성은 평균 고장 간격(MTBF), 고장률, 가용성 등의 지표를 사용하여 객관적으로 측정할 수 있다.

불량한 신뢰성은 주로 우수한 아키텍처 및 코딩 관행을 따르지 않아 발생한다. 이러한 문제는 애플리케이션의 정적 품질 속성을 측정하여 감지할 수 있다. 신뢰성의 근간이 되는 정적 속성을 평가하면, 운영 시 발생할 수 있는 잠재적인 오류 및 결함의 가능성과 비즈니스 위험 수준을 추정할 수 있다.

신뢰성 평가를 위해서는 다음과 같은 소프트웨어 공학 모범 사례 및 기술 속성을 점검해야 한다.

  • 애플리케이션 아키텍처 관행
  • 코딩 관행
  • 알고리즘 복잡성
  • 프로그래밍 관행의 복잡성
  • 객체 지향 및 구조적 프로그래밍 모범 사례 준수(해당하는 경우)
  • 컴포넌트 또는 패턴 재사용 비율
  • 더티 프로그래밍
  • 오류 및 예외 처리(모든 계층 - GUI, 로직 및 데이터)
  • 다중 계층 설계 준수
  • 리소스 경계 관리
  • 소프트웨어는 예상치 못한 동작을 유발하는 패턴을 피해야 함
  • 소프트웨어는 데이터 무결성 및 일관성을 관리해야 함
  • 트랜잭션 복잡성 수준


애플리케이션 아키텍처와 사용된 타사 구성 요소(예: 외부 라이브러리 또는 프레임워크)에 따라, 위의 모범 사례 목록 외에 사용자 지정 검사를 정의하여 신뢰성을 더 정확하게 평가할 수 있다.

임베디드 시스템에서 소프트웨어 문제는 단순한 불편함을 넘어 인명 피해를 야기할 수 있다.[89] 미국에서는 미국 식품의약국(FDA)과 연방 항공국(FAA)이 소프트웨어 개발에 대한 요구 사양을 제정하고 있다.

소프트웨어 신뢰성 개선은 소프트웨어 개발을 다루기 쉽고 이해 가능한 것으로 만들려는 노력에서 비롯되었다. 초기에는 수익 추구와 관련이 없었지만, 소프트웨어 산업이 성숙하면서 사용자의 품질 기대 수준이 높아졌고, 신뢰성 확보가 수익으로 이어지는 상황이 되었다.

소프트웨어 신뢰성은 실행 시 판정을 통해 평가할 수 있는데, 이는 테스트와 유사하지만 성능, 다른 코드와의 상호 운용성, 특정 하드웨어 구성에서의 동작 가능성 등을 평가한다는 점에서 더 단순하다.

3. 3. 효율성 (Efficiency)

소프트웨어의 성능 효율성은 자원(CPU, 메모리, 네트워크 등)을 얼마나 효율적으로 사용하는지를 나타낸다. 응답 시간, 처리량, 자원 사용률 등의 지표가 사용된다.[73] 성능 비효율성의 원인은 애플리케이션의 정적 품질 속성을 측정하여 감지할 수 있는 훌륭한 아키텍처 및 코딩 관행 위반에서 발견되는 경우가 많다. 이러한 정적 속성은 특히 복잡한 알고리즘이나 방대한 양의 데이터를 처리하기 위해 높은 실행 속도가 필요한 애플리케이션의 잠재적인 운영 성능 병목 현상과 미래의 확장성 문제를 예측한다.

성능 효율성을 평가하기 위해서는 최소한 다음의 소프트웨어 엔지니어링 모범 사례와 기술 속성을 확인해야 한다.

  • 애플리케이션 아키텍처 관행
  • 비용이 많이 들거나 원격 리소스와의 적절한 상호 작용
  • 데이터 액세스 성능 및 데이터 관리
  • 메모리, 네트워크 및 디스크 공간 관리
  • 코딩 관행 준수[73] (최적의 코딩 관행)

3. 4. 보안 (Security)

소프트웨어 보안은 소프트웨어 품질에 포함된다.[69] SQL 삽입이나 크로스 사이트 스크립팅과 같은 열악한 코딩 및 아키텍처 관행은 많은 보안 취약점의 원인이 된다.[70][71] 이러한 취약점들은 CWE에서 관리하는 목록과 카네기 멜론 대학교의 SEI/컴퓨터 비상 대응 센터 (CERT)에 잘 문서화되어 있다.[72][73]

소프트웨어 보안을 평가하기 위해서는 최소한 다음의 소프트웨어 엔지니어링 모범 사례 및 기술 속성을 확인해야 한다.

  • 보안 개발 수명 주기(Microsoft) 또는 IBM의 Secure Engineering Framework와 같은 보안 인식 및 강화 개발 프로세스의 구현 및 관리.[74]
  • 보안 애플리케이션 아키텍처 관행 준수.[75][76]
  • 다중 계층 설계 규정 준수.
  • 입력 유효성 검사, SQL 삽입, 크로스 사이트 스크립팅, 접근 제어 등 보안 모범 사례 준수.[77][78]
  • 안전하고 우수한 프로그래밍 관행 준수.[73]
  • 오류 및 예외 처리.

3. 5. 유지보수성 (Maintainability)

유지보수성은 소프트웨어가 얼마나 쉽게 수정, 개선, 확장, 또는 다른 환경으로 이식될 수 있는지를 나타내는 중요한 품질 특성이다. 이는 코드의 가독성, 모듈성, 응집도, 결합도, 그리고 문서화 수준과 같은 다양한 지표를 통해 평가된다.[79]

유지보수성을 평가하기 위해 고려해야 할 주요 기술적 속성은 다음과 같다.

속성설명
애플리케이션 아키텍처 관행소프트웨어의 전반적인 구조와 설계 원칙
소스 코드 문서화아키텍처, 프로그램, 코드에 대한 상세한 설명
코드 가독성코드가 얼마나 이해하기 쉬운지
코드 스멜코드 내 잠재적 문제점을 나타내는 징후
복잡성 수준트랜잭션, 알고리즘, 프로그래밍 관행의 복잡도
객체 지향 및 구조적 프로그래밍 준수객체 지향 또는 구조적 프로그래밍 원칙의 적용 여부
구성 요소/패턴 재사용 비율기존 컴포넌트나 디자인 패턴의 활용 정도
동적 코딩 제어동적 코드 사용의 적절성
결합 비율모듈 간의 의존성 정도
문서화시스템 및 코드에 대한 문서의 완성도
플랫폼 독립성하드웨어, 운영체제, 미들웨어, 소프트웨어 구성 요소, 데이터베이스로부터의 독립성
다중 계층 디자인 준수다중 계층 아키텍처 패턴의 적용 여부
이식성다른 환경으로의 이전 가능성
프로그래밍 관행 (코드 수준)코드 작성 규칙 및 표준 준수
중복 코드 감소코드 중복 최소화
소스 코드 파일 구성파일 및 폴더 구조의 체계성



유지보수성은 워드 커닝햄의 기술 부채 개념과 밀접하게 관련되어 있다.[80][81] 기술 부채는 유지보수성이 낮은 코드로 인해 발생하는 추가적인 비용을 의미한다. 유지보수성 부족은 개발자의 능력 부족, 시간 제약, 목표와 부주의, 그리고 유지보수 가능한 소스 코드 작성의 중요성에 대한 인식 부족 등 다양한 요인에 의해 발생할 수 있다.[82]

3. 6. 크기 (Size)

소프트웨어의 크기를 측정하는 방법에는 크게 기술적 크기 측정과 기능적 크기 측정이 있다.

  • 기술적 크기 측정은 코드 라인 수, 파일 수, 함수, 클래스, 테이블 수 등 기술적인 요소를 기반으로 한다. 널리 알려진 방법으로는 코드 라인 수가 있으며, 이를 통해 백파이어링 기능 점수를 계산할 수 있다.[83]
  • 기능적 크기 측정은 사용자의 관점에서 소프트웨어가 제공하는 기능의 크기를 측정한다. 가장 일반적인 방법은 기능 점수 분석이며, 사용자 요구 사항을 기반으로 입력, 출력, 데이터 저장소 등을 식별하고 가중치를 부여하여 측정한다. 국제 기능 점수 사용자 그룹(IFPUG)에서 표준을 지원한다.[83]


기능 점수 분석은 소프트웨어 개발 초기 단계에 적용할 수 있으며, 기술에 구애받지 않고 조직 및 산업 간 비교에 사용할 수 있다는 장점이 있다. 기능 점수 외에도 COSMIC, NESMA, 유스 케이스 포인트, FP Lite, Early and Quick FP, 스토리 포인트 등 다양한 기능적 크기 측정 방법이 존재한다.[83]

기능 점수는 통계적 정확성을 바탕으로 애플리케이션 개발 관리(ADM) 또는 아웃소싱 계약에서 작업 측정 단위로 활용되기도 한다. 그러나 수동으로 측정해야 하기 때문에 노동 집약적이고 비용이 많이 들 수 있다는 단점이 있다. 이러한 단점을 극복하기 위해 IT 소프트웨어 품질 컨소시엄(CISQ)에서는 소프트웨어 크기 측정을 자동화하는 표준을 도입하고자 노력하고 있다.[83]

CISQ는 소프트웨어 크기 추정을 비용 견적, 진행 상황 추적 등 소프트웨어 프로젝트 관리를 지원하기 위한 활동으로 정의한다. 소프트웨어의 기능적 크기를 측정하는 '자동 기능 점수'와 기능적/비기능적 코드 크기를 함께 측정하는 '자동 향상 점수' 두 가지 표준이 사용된다.[83]

3. 7. 치명적 프로그래밍 오류 식별

치명적 프로그래밍 오류는 즉각적 또는 장기적으로 비즈니스 중단 위험이 가장 높은 특정 아키텍처 및/또는 코딩의 나쁜 관행이다.[84]

이러한 오류는 기술과 관련이 있으며, 맥락, 비즈니스 목표 및 위험에 크게 의존한다. 어떤 사람들은 명명 규칙 준수를 중요하게 생각하는 반면, 다른 사람들(예: 지식 이전을 준비하는 사람들)은 이를 매우 중요하게 여길 것이다.

치명적 프로그래밍 오류는 CISQ 특성별로 분류할 수 있다. 기본적인 예는 다음과 같다.

특성설명
신뢰성
효율성
보안
유지 관리 용이성


3. 8. 운영화된 품질 모델 (Operationalized Quality Models)

스퀘일 및 Quamoco[85]와 같은 새로운 품질 모델 제안은 품질 속성 정의와 측정의 직접적인 통합을 확산시킨다. 품질 속성을 세분화하거나 추가 계층을 정의함으로써, 복잡하고 추상적인 품질 속성 (예: 신뢰성 또는 유지 보수성)을 더 관리하고 측정하기 쉽게 만들 수 있다. 이러한 품질 모델은 산업 현장에서 적용되었지만 널리 채택되지는 않았다.

4. 소프트웨어 품질 요인 (Factors)

소프트웨어 품질 요인은 기능 외적인 요구사항으로, 고객과의 계약에 명시되는 경우는 드물지만, 소프트웨어 품질을 강화하는 데 중요한 역할을 한다.[89]

소프트웨어 품질은 다양한 관점에서 측정되는데, 모든 사람이 동의하는 측정 관점은 드물다. 어떤 사람들은 정량적 측정이 필수적이라고 생각하지만, 다른 사람들은 정량적 측정이 유효한 경우는 제한적이라고 여겨 정성적 측정을 선호한다.[90][91]

자주 사용되는 척도로 검출된 버그 수가 있다. 버그가 적은 소프트웨어는 버그가 많은 소프트웨어에 비해 품질이 높다고 여겨진다. 소프트웨어는 인간이 만드는 것이므로, 소프트웨어 품질 척도는 어떤 의미에서 인간의 행동을 측정하는 것이다.[92]

소프트웨어 품질 요인은 내용 표현이 모호하여 측정이 어렵다. 그러나 기능 이외의 요구 사항을 충족하는지 여부를 밝히기 위해서는 어떤 형태로든 측정해야 한다. 예를 들어, 신뢰성은 자체로는 평가할 수 없지만, 장애 발생 간격(MTBF), 장애 발생률, 시스템 가용성 등 신뢰성과 관련된 측정 가능한 요소들이 존재한다. 이식성 역시 프로그램 내의 플랫폼 종속적인 구문의 수로 나타낼 수 있다.

4. 1. 주요 소프트웨어 품질 요인

주요 소프트웨어 품질 요인은 다음과 같다.

요인설명
제품 품질요구 사항 명세 및 프로그램 명세에 얼마나 잘 맞는가 (소프트웨어 신뢰성과 관련됨)
확장성새로운 기능을 추가하거나 성능을 향상시키기 쉬운 정도
정당성소프트웨어가 정확하게 동작하는지
완전성필요한 모든 기능이 제대로 구현되었는지
버그 없음버그는 소프트웨어 품질을 저해하는 주요 요인
결함 감내 시스템오류 발생 시에도 시스템이 정상 작동하는 능력
유지보수성소프트웨어를 얼마나 쉽게 수정하고 개선할 수 있는지
소프트웨어 문서화소프트웨어 이해와 유지보수를 돕는 문서
이해 가능성목적, 설계, 사용 방법 등이 명확하여 이해하기 쉬운 정도 (개발자용 소프트웨어는 초보자 이해 불필요)
간결성불필요한 정보나 코드가 없는지 (메모리 제한 환경, 코드 행 수 감소에 중요)
이식성다양한 하드웨어나 운영체제에서 쉽게 작동하는지
일관성표기법, 용어, 코드 스타일 등이 일관적인지
시험성기능을 쉽게 테스트하고 검증할 수 있는지 (복잡한 설계는 시험성 저해)
사용성사용자가 편리하고 실용적으로 사용 가능한지 (사용자 인터페이스 중요)
신뢰성오류 없이 목적한 기능을 제대로 수행하는지 (일정 시간 내 수행, 오류 발생 시에도 중단 없는 견고성(Robustness) 포함)
구조화 정도구성 요소들이 균일한 패턴을 가지는지 (Pascal 같은 구조화 언어로 작성된 소프트웨어)
효율성메모리, 프로세서 사용 시간 등 리소스를 효율적으로 사용하는지
보안데이터와 시스템을 부당한 접근, 악의적 조작으로부터 보호하는지 (컴퓨터 보안 기구 유무 관련)



소프트웨어 품질 측정은 다양한 관점이 존재하여 쉽지 않다. 모든 사람이 동의하는 측정 관점은 드물지만, 검출된 버그 수가 자주 사용되는 척도(메트릭)이다. 그러나 버그 수만으로는 품질을 평가하기 어려우며, 버그 종류, 심각성, 소프트웨어 규모, 복잡성 등 다양한 요소를 고려해야 한다.

소프트웨어 품질 요인은 모호한 표현이 많아 측정이 어렵지만, 기능 외적 요구사항 충족 여부 확인을 위해 어떤 형태로든 측정해야 한다. 신뢰성은 측정 가능한 요소(장애 발생 간격(MTBF), 장애 발생률, 시스템 가용성 등)로 간접 평가할 수 있다.

각 요인(특성)별 관련 질문을 통해 채점하여 품질을 정량화할 수 있다.

요인질문 예시
이해 가능성변수명이 기능을 잘 나타내는가? 주석문으로 코드 이해가 가능한가? 데이터 구조 기능 분할은 적절한가?
완전성일반 시스템에 없는 서브 프로그램이 있는가? 필요 파라미터가 모두 갖춰졌는가? 입력 데이터가 모두 있는가?
간결성실행되지 않는/불필요한 코드는 없는가? 루프 밖에서 실행 가능한 코드를 루프 내 반복 실행하는가? 분기 판정이 복잡한가?
이식성특정 플랫폼 의존 시스템/라이브러리가 있는가? 기종 의존 코드가 구분되었는가? 엔디안, 문자 인코딩에 의존하는가?
일관성변수명, 상수 표현, 동일 연산, 들여쓰기 스타일이 일관적인가?
유지보수성미래 확장용 메모리 확보? 모듈 응집도 적절? 데이터 구조 변경에 쉽게 대처? 기능 변경 시 전체 재구성 필요?
시험성코드 구조가 복잡? 상세 설계 단계 의사 코드 제시? 멀티태스킹/멀티스레드 테스트 수단?
사용성GUI 사용? 온라인 도움말/사용자 매뉴얼 제공? 에러 메시지 이해 용이?
신뢰성한계값 검사 수행? 0으로 나누기 방지? 예외 처리 수행?
구조화 정도모듈 분할 크기 적절? 모듈 간 제어 전달 방식 명확, 예외 없이 준수?
효율성실행 시간 최적화? 반복 코드 블록 서브루틴화? 메모리 누수 방지?
보안부정 접근 방지? 보안 정책 조작자 설정? 보안 기구 구현 올바름? 공격 상정 설계? 취약점(버퍼 오버런, 형식 문자열 문제 등) 존재?


4. 2. 소프트웨어 품질 요인 측정

소프트웨어 품질 요인은 모호하고 주관적인 경우가 많아 측정이 어렵지만, 정량적, 정성적 방법을 결합하여 측정할 수 있다. 주요 소프트웨어 품질 요인은 다음과 같다.

요인설명
이해 가능성(Understandability)제품의 목적이 명확하고, 설계 문서나 사용자 문서가 쉽게 이해 가능한 형태로 작성되어 있는지 여부. 예상되는 사용자에 따라 중요도가 달라진다.
완전성(Completeness)제품이 단독으로 기능할 수 있고, 그 기능이 목적에 대해 충분한지 여부. 외부 라이브러리가 필요하다면, 입수 방법과 버전 등의 정보가 제공되어야 한다.
간결성(Conciseness)불필요한 정보가 없는지 여부. 메모리 용량이 제한된 환경이나 코드 행 수를 줄이는 것이 중요한 경우에 특히 중요하다.
이식성(Portability)다양한 컴퓨터 구성(하드웨어, OS 차이)에서 쉽게 작동하는지 여부.
일관성(Consistency)표기법과 용어가 일관되는지 여부.
유지 보수성(Maintainability)새로운 요구를 충족하기 위해 개선이 용이한지 여부. 문서 완비, 복잡성, 메모리 용량/성능 여유 등이 영향을 미친다.
시험성(Testability)허용 기준이 명확하고 성능 평가가 가능한지 여부. 설계 단계에서의 통합과 복잡한 설계는 시험성을 저하시킨다.
사용성(Usability)사용자에게 편리하고 실용적인지 여부. 특히 사용자 인터페이스가 중요하다.
신뢰성(Reliability)사용자에게 영향을 미치는 오류를 방지하고, 목적하는 기능이 충분히 실현되는지 여부. 일정 시간 내 기능 수행, 오류 발생 시에도 중단 없이 작동(견고성, 로버스트니스(Robustness))하는 것도 포함된다.
구조화 정도(Structuredness)구성 요소가 균일한 패턴을 가지고 있는지 여부. 구조화 언어(Pascal)로 작성된 소프트웨어는 이 특성을 만족시킨다.
효율성(Efficiency)목적 달성 시 리소스(메모리 사용량, 프로세서 사용 시간)를 낭비하지 않는지 여부.
보안(Security)부당한 접근으로부터 데이터를 보호하고, 악의적인 조작에 내성을 갖는지 여부. 인증 기구, 접근 제어, 암호화 등 컴퓨터 보안 기구의 유무와 관련된다.


5. 사용자의 관점

소프트웨어의 기술적 품질 외에도 최종 사용자의 경험 또한 소프트웨어 품질을 결정하는 중요한 요소이다. 이러한 종류의 소프트웨어 품질을 사용성이라고 부른다. 유료 여부와 관계없이 지원을 받을 수 있는지 여부도 소프트웨어의 사용성을 좌우한다.

5. 1. 사용성 (Usability)

소프트웨어의 기술적 품질 외에도 최종 사용자의 경험 또한 소프트웨어의 품질을 결정한다. 이러한 종류의 소프트웨어 품질을 사용성이라고 부른다. 소프트웨어 제품의 사용성을 정량화하는 것은 어렵다. 사용성을 정성적으로 파악하기 위한 중요한 질문들은 다음과 같다.

  • 사용자 인터페이스는 직관적인가?
  • 단순한 조작은 쉬운가?
  • 복잡한 조작은 적절한가?
  • 오류 메시지는 이해하기 쉬운가?
  • 위젯은 예상대로 작동하는가?
  • 소프트웨어 문서는 충분한가?
  • 사용자 인터페이스의 반응성은 좋은가?


또한, 유료 여부와 관계없이 지원을 받을 수 있는지 여부도 소프트웨어의 사용성을 좌우한다.

5. 2. 지원 (Support)

유료 여부와 관계없이 지원을 받을 수 있는지 여부도 소프트웨어의 사용성을 좌우한다.

6. 한국의 소프트웨어 품질 관련 현황 및 정책 (추가 제안)

한국은 IT 강국으로서 소프트웨어 산업의 중요성이 매우 크며, 정부와 민간 차원에서 소프트웨어 품질 향상을 위한 다양한 노력을 기울이고 있다. 특히 더불어민주당은 소프트웨어 산업의 발전과 품질 향상을 주요 정책 과제로 삼고, 관련 정책 및 지원을 강화해 왔다.

참조

[1] 웹사이트 Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine https://re-magazine.[...] 2021-02-25
[2] 서적 Software Engineering: A Practitioner's Approach McGraw-Hill Education
[3] 웹사이트 About the Automated Source Code Quality Measures Specification Version 1.0 https://www.omg.org/[...] 2021-02-25
[4] 웹사이트 How to Perform End-to-End Testing https://smartbear.co[...] 2021-02-25
[5] 웹사이트 How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations http://www.omg.org/C[...] 2013-10-18
[6] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[7] 웹사이트 ISO/IEC 25010:2011 https://www.iso.org/[...] 2021-02-23
[8] 논문 A measure of control https://doi.org/10.1[...] 2012-06-01
[9] 논문 Software's secret sauce: the "-ilities" [software quality] https://ieeexplore.i[...] 2011-11-01
[10] 웹사이트 Code Quality Standards {{!}} CISQ - Consortium for Information & Software Quality https://www.it-cisq.[...] 2021-02-25
[11] 웹사이트 Software Sizing Standards {{!}} CISQ - Consortium for Information & Software Quality https://www.it-cisq.[...] 2021-02-25
[12] 간행물 J. Bohnet, J. Döllner http://www.hpi.uni-p[...]
[13] 웹사이트 IIA - Global Technology Audit Guide: IT Change Management: Critical for Organizational Success https://na.theiia.or[...] 2021-02-26
[14] 웹사이트 Meltdown and Spectre fallout: patching problems persist https://blog.malware[...] 2021-02-26
[15] 웹사이트 Best practices for software updates - Configuration Manager https://docs.microso[...] 2021-02-26
[16] 서적 Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium Association for Computing Machinery 2009-08-25
[17] 논문 Software release management 1997-11-01
[18] 웹사이트 7 Ways to Improve Your Software Release Management https://www.cio.com/[...] 2021-02-26
[19] 웹사이트 iRobot says it'll be a few weeks until it can clean up its latest Roomba software update mess https://www.theverge[...] 2021-02-25
[20] 웹사이트 Top 25 Software Errors https://www.sans.org[...] 2021-02-25
[21] 웹사이트 'Turn it Off and On Again Every 149 Hours' Is a Concerning Remedy for a $300 Million Airbus Plane's Software Bug https://gizmodo.com/[...] 2019-07-30
[22] 웹사이트 MISRA C, Toyota and the Death of Task X http://blog.gimpel.c[...] 2021-02-25
[23] 웹사이트 An Update on Toyota and Unintended Acceleration « Barr Code https://embeddedguru[...] 2021-02-25
[24] 간행물 Medical Devices: The Therac-25* http://sunnyday.mit.[...]
[25] 간행물 Embedded Software http://ptolemy.eecs.[...]
[26] 웹사이트 Aircraft Certification Software and Airborne Electronic Hardware http://www.faa.gov/a[...] 2014-09-28
[27] 웹사이트 The Cost of Poor Software Quality in the US: A 2020 Report {{!}} CISQ - Consortium for Information & Software Quality https://www.it-cisq.[...] 2021-02-25
[28] 웹사이트 What is Waste? {{!}} Agile Alliance https://www.agileall[...] 2016-04-20
[29] 웹사이트 Report: Software failure caused $1.7 trillion in financial losses in 2017 https://www.techrepu[...] 2021-02-25
[30] 웹사이트 Financial Cost of Software Bugs https://medium.com/@[...] 2021-02-25
[31] 간행물 Software Failures: An Overview http://link.springer[...] Springer International Publishing 2021-02-25
[32] 웹사이트 Poor software quality cost businesses $2 trillion last year and put security at risk https://www.ciodive.[...] 2021-02-26
[33] 웹사이트 Synopsys-Sponsored CISQ Research Estimates Cost of Poor Software Quality in the US $2.08 Trillion in 2020 https://finance.yaho[...] 2021-02-26
[34] 웹사이트 What Does a Data Breach Cost in 2020? https://digitalguard[...] 2021-03-08
[35] 웹사이트 Cost of a Data Breach Report 2020 {{!}} IBM https://www.ibm.com/[...] 2021-03-08
[36] 웹사이트 ISO - ISO 9000 family — Quality management https://www.iso.org/[...] 2021-02-24
[37] 웹사이트 ISO/IEC/IEEE 24765:2017 https://www.iso.org/[...] 2021-02-24
[38] 웹사이트 Mastering automotive software https://www.mckinsey[...] 2021-02-25
[39] 웹사이트 ISO/IEC 25010:2011 https://www.iso.org/[...] 2021-02-24
[40] 서적 Proceedings 26th Annual NASA Goddard Software Engineering Workshop IEEE Comput. Soc 2002
[41] 웹사이트 ISO/IEC 25023:2016 https://www.iso.org/[...] 2023-11-06
[42] 웹사이트 What is Software Quality? {{!}} ASQ https://asq.org/qual[...] 2021-02-24
[43] 간행물 SAMATE - Software Assurance Metrics And Tool Evaluation project main page https://samate.nist.[...] 2021-02-03
[44] 서적 Software extension to the PMBOK guide https://www.worldcat[...] 2013
[45] 서적 Economioc control of quality of manufactured product. https://www.worldcat[...] Martino Fine Books 2015
[46] 간행물 Software quality: the elusive target [special issues section] https://ieeexplore.i[...] 1996-01
[47] 서적 Managing quality : the strategic and competitive edge https://www.worldcat[...] Free Press 1988
[48] 문서 B. Kitchenham and S. Pfleeger, "Software quality: the elusive target", IEEE Software, vol. 13, no. 1, pp. 12–21, 1996.
[49] 서적 Metrics and models in software quality engineering https://www.worldcat[...] Addison-Wesley 2003
[50] 문서 International Organization for Standardization, "ISO/IEC 9001: Quality management systems -- Requirements," 1999.
[51] 문서 W. E. Deming, "Out of the crisis: quality, productivity and competitive position". Cambridge University Press, 1988.
[52] 문서 A. V. Feigenbaum, "Total Quality Control", McGraw-Hill, 1983.
[53] 문서 J.M. Juran, "Juran's Quality Control Handbook", McGraw-Hill, 1988.
[54] 서적 Quality software management: Volume 1, Systems Thinking https://www.worldcat[...] Dorset House
[55] 서적 Quality software management: Volume 2, First-Order Measurement https://www.worldcat[...] Dorset House
[56] 문서 Crosby, P., Quality is Free, McGraw-Hill, 1979
[57] 웹사이트 SUP.9 – Problem Resolution Management - Kugler Maag Cie https://www.kuglerma[...] 2021-02-25
[58] 웹사이트 Organizations often use the terms 'Quality Assurance' (QA) vs 'Quality Control' (QC)… https://medium.com/t[...] 2019-11-29
[59] 간행물 Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric https://www.nist.gov[...] 1996-08-01
[60] 웹사이트 What Is Code Quality? And How to Improve Code Quality https://www.perforce[...] 2021-02-28
[61] 웹사이트 OMG Whitepaper {{!}} CISQ - Consortium for Information & Software Quality https://www.it-cisq.[...] 2021-02-26
[62] 웹사이트 How to Deliver Resilient, Secure, Efficient and Agile IT Systems in Line with CISQ Recommendations - Whitepaper | Object Management Group http://www.omg.org/C[...] 2013-10-18
[63] 웹사이트 Software Size Measurement: A Framework for Counting Source Statements https://resources.se[...] 1992-08-31
[64] 서적 Elements of Software Science (Operating and programming systems series) https://dl.acm.org/d[...] Elsevier Science Inc. 1977
[65] 간행물 A metrics suite for object oriented design https://ieeexplore.i[...] 1994-06
[66] 서적 Release It! https://www.worldcat[...] Pragmatic Bookshelf 2007
[67] 웹사이트 CWE - Common Weakness Enumeration https://cwe.mitre.or[...] 2016-05-20
[68] 문서 Boehm, B., Brown, J.R., Kaspar, H., Lipow, M., MacLeod, G.J., & Merritt, M.J. (1978). Characteristics of Software Quality. North-Holland.
[69] 웹사이트 Code quality and code security: How are they related? {{!}} Synopsys https://www.synopsys[...] 2019-05-24
[70] 웹사이트 Cost of a Data Breach Report 2020 {{!}} IBM https://www.ibm.com/[...] 2020
[71] 웹사이트 Key Takeaways from the 2020 Cost of a Data Breach Report https://www.bluefin.[...] 2021-03-09
[72] 웹사이트 CWE - Common Weakness Enumeration http://cwe.mitre.org[...] Cwe.mitre.org 2013-10-18
[73] 웹사이트 SEI CERT Coding Standards - CERT Secure Coding - Confluence https://wiki.sei.cmu[...] 2021-02-24
[74] 서적 Security in Development: The IBM Secure Engineering Framework {{!}} IBM Redbooks http://www.redbooks.[...] 2016-09-30
[75] 서적 Enterprise Security Architecture Using IBM Tivoli Security Solutions {{!}} IBM Redbooks http://www.redbooks.[...] 2016-09-30
[76] 웹사이트 Secure Architecture Design Definitions {{!}} CISA https://us-cert.cisa[...] 2021-03-09
[77] 웹사이트 OWASP Foundation {{!}} Open Source Foundation for Application Security https://owasp.org/ 2021-02-24
[78] 웹사이트 CWE's Top 25 http://www.sans.org/[...] Sans.org 2013-10-18
[79] 문서 IfSQ Level-2 A Foundation-Level Standard for Computer Program Source Code http://www.ifsq.org/[...]
[80] 웹사이트 TechnicalDebtQuadrant http://martinfowler.[...] 2009-10-14
[81] 웹사이트 Code quality: a concern for businesses, bottom lines, and empathetic programmers https://stackoverflo[...] 2021-10-18
[82] 서적 2012 International Conference on Software and System Process (ICSSP) http://publica.fraun[...] IEEE Computer Society 2012-06-03
[83] 웹사이트 Software Sizing Standards {{!}} CISQ - Consortium for Information & Software Quality https://www.it-cisq.[...] 2021-01-28
[84] 웹사이트 Why Software fails https://spectrum.iee[...] 2005-09-02
[85] 간행물 Operationalised product quality models and assessment: The Quamoco approach http://elib.uni-stut[...] 2015
[86] 간행물 Software Process versus Design Quality: Tug of War?
[87] 웹사이트 Software Quality Professional {{!}} ASQ https://asq.org/qual[...] 2021-01-28
[88] 웹사이트 Software Quality Journal https://www.springer[...] 2021-01-28
[89] 문서 Medical Devices: The Therac-25 http://sunnyday.mit.[...]
[90] 문서 http://www.kaner.com[...]
[91] 문서 http://www.softwareq[...]
[92] 문서 Software Engineering Metrics: What Do They http://www.kaner.com[...]
[93] 서적 Software Engineering: A Practitioner's Approach 2005
[94] 웹인용 How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations http://www.omg.org/C[...] 2013-10-18
[95] 웹인용 ISO 25000:2005 http://webstore.iec.[...] 2013-10-18
[96] 웹인용 ISO/IEC 25010:2011 http://www.iso.org/i[...] ISO 2016-03-14


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com