맨위로가기

소프트웨어 유지보수

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

1. 개요

소프트웨어 유지보수는 소프트웨어의 기능을 개선하고 오류를 수정하며 변화하는 환경에 적응시키기 위해 수행되는 일련의 활동을 의미한다. 1969년 매니 리먼에 의해 처음 연구되었으며, 소프트웨어 개발 수명 주기의 마지막 단계로, 전체 수명 주기 비용의 상당 부분을 차지한다. 소프트웨어 유지보수는 수정, 예방, 적응, 완전화 유지보수로 분류되며, 유지보수성은 소프트웨어의 중요한 품질 요소로 간주된다. 소프트웨어 유지보수는 인력, 아웃소싱, 오프쇼어링과 같은 측면에서 다양한 변화를 겪었으며, 레거시 시스템의 대안, 자동화 및 머신러닝 기술을 활용한 연구가 진행되고 있다.

더 읽어볼만한 페이지

  • 소프트웨어 유지 보수 - 기술 부채
    기술 부채는 소프트웨어 개발에서 발생하는 개념으로, 현재의 편의적인 설계가 미래에 추가적인 비용을 발생시키는 것을 의미하며, 다양한 원인으로 발생하여 개발 비용 증가, 프로젝트 지연, 경쟁력 약화 등의 부정적인 결과를 초래할 수 있다.
  • 소프트웨어 유지 보수 - 패치 (컴퓨팅)
    소프트웨어나 데이터의 오류 수정, 보안 강화, 기능 추가 등을 목적으로 추가되는 작은 코드나 파일을 패치라고 한다.
  • ISO/IEC 표준 - 프로젝트 관리
    프로젝트 관리는 제한된 자원 내에서 특정 목표를 달성하기 위해 상호 연관된 작업들을 계획, 실행, 모니터링 및 종료하는 일시적인 활동으로, 범위, 시간, 비용, 품질, 리스크 관리가 중요하며, 프로젝트 관리자는 표준 및 방법론을 활용하여 프로젝트의 성공을 책임진다.
  • ISO/IEC 표준 - ISO/IEC 646
    ISO/IEC 646는 ASCII 기반의 7비트 문자 인코딩 표준으로, 국가별 변형이 존재했으나, 최종 개정판은 ASCII와 호환되도록 정의되었고, 현재는 ITU-T 권고 T.50 IRA가 현행 표준으로 유지되고 있다.
  • IEEE 표준 - IEEE 754
    IEEE 754는 부동소수점 숫자를 표현하고 처리하기 위한 국제 표준으로, 다양한 형식과 연산, 반올림 규칙, 예외 처리 등을 정의한다.
  • IEEE 표준 - IEEE 802.2
    IEEE 802.2는 데이터 링크 계층의 LLC 서브레이어를 정의하는 IEEE 802 표준의 일부로, 비연결 및 연결 지향 모드를 지원하며, LLC 클래스 I, II, III, IV를 통해 다양한 서비스 유형을 제공하고, DSAP, SSAP 주소 및 제어 필드로 구성된 헤더와 필요에 따라 SNAP 확장을 사용해 네트워크 통신을 관리한다.
소프트웨어 유지보수
정의
소프트웨어 유지보수소프트웨어가 인도된 후 수정하는 과정
프로세스
주요 활동문제 및 수정사항 식별
설계 변경
코드 편집
테스트
문서화
카테고리
수정 유지보수소프트웨어 결함 수정
적응 유지보수변화하는 환경에 적응
완전화 유지보수새로운 요구사항 충족
예방 유지보수미래 문제 예방
표준
ISO/IEC 14764:2006소프트웨어 생명 주기 프로세스 — 유지보수

2. 역사

소프트웨어 유지보수와 시스템 진화는 1969년 매니 리먼(Manny Lehman)에 의해 처음 기술되었다. 20년이 지나, 그의 연구를 통해 리먼의 법칙이 만들어졌다. 그의 연구에서 발견된 주요 사항으로는 유지보수가 진화적인 개발 방식이며 유지보수의 결정은 시간이 지남에 따라 시스템(및 소프트웨어)에 발생하는 것을 이해함으로써 도움을 받는다는 것이다. 코드 리팩토링과 같은 조치를 통해 복잡성을 낮추지 않을 경우 진화를 거듭할수록 더 복잡하게 변모하게 된다.

1970년대 초, 기업들은 지원 업무로부터 소프트웨어 개발팀을 분리하기 위해 소프트웨어 유지보수를 별도의 엔지니어 팀으로 분리하기 시작했다. 1972년, R. G. 캐닝은 소프트웨어 유지보수가 기존 시스템이라는 추가적인 투입을 가진 소프트웨어 개발의 연장이라고 주장했다. 그 이후로 소프트웨어 유지보수라는 분야는 거의 변하지 않았다.[2] 21세기 혁신 중 하나는 기업들이 의도적으로 불완전한 소프트웨어를 출시하고 출시 후 완성할 계획을 세운 것이다. 이러한 유형의 변경, 그리고 기능을 확장하는 다른 변경은 종종 유지보수 대신 소프트웨어 진화라고 불린다.[2]

소프트웨어 유지보수 공정은 구조적 프로그래밍 운동이 활발해졌을 때 개발된 폭포수 모델에서 명확한 공정으로 고려되었다. 객체 지향이 부각되었을 때 개발된 나선형 모델에서는 소프트웨어 유지보수에 관해 명확하게 정의되어 있지 않다. 어쨌든 소프트웨어 유지보수는 중요하며, 소프트웨어의 라이프 사이클 전체에 소요되는 비용 중 3분의 2가 유지보수에 사용된다는 사실이 있다.[3].[4]

3. 소프트웨어 수명 주기

소프트웨어 개발 수명 주기(SDLC)에서 유지보수는 마지막 단계이며, 가장 긴 기간을 차지하는 경우가 많다. 유지보수 비용은 전체 수명 주기 비용의 80~90%를 차지하기도 한다.[2][3][4]

1988년의 전통적인 소프트웨어 개발 수명 주기 다이어그램


일부 모델에서는 유지보수를 소프트웨어 개발과 별도로 간주하여 소프트웨어 유지보수 수명 주기(SMLC)의 일부로 보기도 한다.[7] SMLC 모델은 코드를 이해하고, 수정하고, 다시 유효성을 검사하는 과정을 포함한다.[7]

소프트웨어 유지보수 프로세스는 JIS 규격 JIS X 0160 (소프트웨어 라이프 사이클 프로세스)로 규정되었으며, JIS X 0161:2008 (소프트웨어 라이프 사이클 프로세스 - 유지보수)에서 상세하게 규정되어 있다. 구조적 프로그래밍 운동이 활발했을 때 개발된 폭포수 모델에서는 소프트웨어 유지보수가 명확한 공정으로 고려되었으나, 객체 지향이 부각되었을 때 개발된 나선형 모델에서는 명확하게 정의되어 있지 않다.

소프트웨어 개발 조직은 버그 관리 시스템을 갖추고 있으며, 소프트웨어는 문제점이나 결함을 가진 상태로 출시되는 것이 일반적이다. 알려진 문제점은 릴리스 노트 등에 문서화되어 사용자가 회피책을 강구하거나 적합한 사용법을 알 수 있도록 한다. 알려지지 않은 문제점이나 결함은 사용자가 발견하여 개발 조직에 보고하고, 버그 관리 시스템에 정보가 입력된다. 소프트웨어 유지보수 담당자들은 이러한 문제들을 해결하고, 수정된 소프트웨어를 패치 (수정 프로그램)나 마이너 체인지 형태로 릴리스한다.

1970년대 초, 기업들은 소프트웨어 개발팀으로부터 지원 업무를 분리하기 위해 소프트웨어 유지보수를 별도의 엔지니어 팀으로 분리하기 시작했다.[2]

3. 1. 릴리스에서 유지보수, 수명 종료까지의 전환

소프트웨어는 종종 불완전한 상태로 제공된다. 개발자는 시간이나 자금이 소진될 때까지 제품을 테스트하는데, 이는 완벽하지 않은 제품에 대한 결과가 시간 초과나 예산 초과보다 적기 때문이다.[2] 개발팀에서 유지보수팀으로의 전환은 종종 비효율적이며, 알려진 문제 목록이나 유효성 검사 테스트가 없어 유지보수 팀이 이를 다시 생성할 가능성이 높다.[2] 릴리스 후에는 개발팀 구성원이 재할당되거나 다른 이유로 사용할 수 없게 될 가능성이 높다. 유지보수 팀은 릴리스 후 첫 해 동안 기술 지원과 개발 과정에서 남겨진 결함 수정 모두에 대해 추가 리소스를 필요로 한다.[2]

처음에는 소프트웨어가 릴리스 후 개선 기간을 거칠 수 있다. 사용자 피드백에 따라 새로운 기능이 추가된다. 어느 시점에서 회사는 기능 개선을 하는 것이 더 이상 수익성이 없다고 판단하여 지원을 버그 수정 및 긴급 업데이트로 제한할 수 있다. 소프트웨어 노후화로 인해 전문 지식이 부족하거나 아키텍처가 노후화되어 변경이 점점 더 어렵고 비용이 많이 든다. 제품이 더 이상 유지보수되지 않고, 이 제한적인 수준의 업데이트조차 받지 못하게 되면, 일부 공급업체는 제품이 점점 더 회피될 가능성이 높음에도 불구하고 가능한 한 오랫동안 소프트웨어에서 수익을 얻으려고 할 것이다. 결국, 소프트웨어는 시장에서 철수될 것이지만, 사용은 계속될 수 있다. 이 과정에서 소프트웨어는 레거시 시스템이 된다.[2]

3. 2. 변경 주기

변경 주기의 첫 번째 단계는 고객으로부터 변경 요청을 받아 문제를 확인하고, 변경 사항을 구현할지 여부를 분석하는 것이다.[2] 이 단계에는 여러 부서의 참여가 필요할 수 있다. 예를 들어, 마케팅팀은 변경 사항이 더 많은 비즈니스를 가져올 것으로 예상되는지 평가하는 데 도움을 줄 수 있다.[2] 소프트웨어 개발 노력 추정은 유지보수 변경 요청을 포함하여 어려운 문제이다.[2] 하지만 요청이 너무 비싸거나 실행 불가능하다면 거부될 가능성이 높다.[2] 요청을 구현하기로 결정한 경우, 예정된 릴리스에 할당하고 구현할 수 있다.[2] 애자일 소프트웨어 개발 방법론에는 유지보수 단계가 없지만,[2] 변경 주기는 스크럼 스프린트로 수행될 수 있다.[2]

기존 코드를 이해하는 것은 코드를 수정하기 전에 필수적인 단계이다.[2] 이해 속도는 코드베이스와 프로그래머의 기술에 따라 달라진다.[2] 명확한 함수 및 변수 이름을 사용하여 해당 목적에 부합하는 코딩 규칙을 따르면 이해가 더 쉬워진다.[2] 코드가 두 번 이상 실행될 수 있는 경우에만 조건 루프 문을 사용하고, 절대로 실행되지 않는 코드를 제거하면 이해도를 높일 수 있다.[2] 숙련된 프로그래머는 높은 수준에서 코드가 무엇을 하는지 더 쉽게 이해할 수 있다.[2] 소프트웨어 시각화는 이 과정을 가속화하는 데 사용되기도 한다.[2]

코드 수정은 어떤 방식으로든 이루어질 수 있다. 한편으로는 코드 문서를 업데이트할 충분한 시간을 할애하지 않고 즉시 수정 사항을 적용하는 경우가 많다.[2] 다른 한편으로는 구조화된 반복적 개선은 최상위 요구 사항 문서를 변경하고 변경 사항을 시스템 하위 레벨로 전파하는 것으로 시작할 수 있다.[2] 수정에는 종종 코드 리팩토링(기능을 변경하지 않고 구조 개선)과 재구성(구조와 기능을 동시에 개선)이 포함된다.[2] 상용 소프트웨어와 달리, 자유-오픈 소스 소프트웨어 변경 주기는 코딩 및 테스트에 크게 제한되며, 문서화는 최소화된다. 대신 오픈 소스 소프트웨어 프로젝트는 메일링 리스트와 많은 수의 기여자에 의존하여 코드베이스를 이해하고 버그를 효율적으로 수정한다.[2]

유지보수의 또 다른 문제는 코드를 변경할 때마다 거의 모든 경우 새로운 버그 또는 예기치 않은 파급 효과가 발생하여 또 다른 수정 작업이 필요하다는 것이다.[2] 안전 필수 코드의 경우, 변경 사항이 발생하면 전체 소프트웨어를 다시 검증해야 하므로 테스트가 유지보수 자원의 대부분을 소비할 수 있다.[2] 재검증에는 코드 검토, 회귀 테스트(단위 테스트의 하위 집합 포함), 통합 테스트, 시스템 테스트가 포함될 수 있다.[2] 테스트의 목표는 이전 기능이 유지되고 새로운 기능이 추가되었는지 확인하는 것이다.[2]

4. 소프트웨어 유지보수의 유형

국제 표준화 기구(ISO)/국제 전기 기술 위원회(IEC) 14764 규격 및 JIS X 0161:2008에 따르면, 소프트웨어 유지보수는 수정 유지보수, 예방 유지보수, 적응 유지보수, 완전 유지보수로 분류할 수 있다.[5]


  • '''수정 유지보수''': 버그나 요구 사항을 충족하지 못하는 기타 오류를 수정한다.
  • '''예방 유지보수''': 요구 사항을 계속 충족하거나 아직 나타나지 않은 문제를 해결하기 위해 소프트웨어를 미래 지향적으로 수정한다.
  • '''적응 유지보수''': 변경되었거나 변경되는 환경에서 지속적인 사용성을 보장하기 위해 수행되는 소프트웨어 수정이다.
  • '''완전 유지보수''': 사용자 경험, 처리 효율성 및 유지 관리성과 같은 품질을 향상시키기 위해 소프트웨어를 개선한다.

4. 1. 수정 유지보수 (Corrective Maintenance)

JIS X 0161:2008에서는 소프트웨어 유지보수를 다음과 같이 구분한다[5].

  • 수정 보수 (corrective maintenance): 발견된 문제를 해결하기 위한 유지보수 활동으로, 인도 후의 수동적인 수정이다. 흔히 버그 수정이라고 부른다.
  • 긴급 보수 (emergency maintenance): 수정 보수가 완료될 때까지 시스템 운용을 유지하기 위해 임시로, 계획 없이 수행하는 수정이다.

4. 2. 예방 유지보수 (Preventive Maintenance)

예방 유지보수는 요구 사항을 계속 충족하거나 아직 나타나지 않은 문제를 해결하기 위한 유지보수이다. 안전성이나 가용성이 높은 시스템에서 주로 수행된다. 소프트웨어 재생은 상태를 정리하고 향후 문제를 방지하기 위한 예방 유지보수의 한 형태이다. JIS X 0161:2008에서는 예방 유지보수를 인도 후의 소프트웨어 제품의 잠재적인 장애가 운용 장애가 되기 전에 발견하고, 시정하기 위한 수정으로 정의한다.[5]

4. 3. 적응 유지보수 (Adaptive Maintenance)

변화했거나 변화하고 있는 환경에서 소프트웨어 제품을 사용할 수 있도록 유지하기 위해 실시하는 소프트웨어 제품 인도 후의 수정이다.[5]

4. 4. 완전화 유지보수 (Perfective Maintenance)

사용자 경험, 처리 효율성, 유지 관리성 등 품질을 향상시키기 위한 유지보수이다. 다른 유형의 유지보수가 수행될 때 필요하며, 코드 리팩토링, 성능 조정 등이 포함될 수 있다. 일부 추정에 따르면, 개선(완전화 유지보수, 적응 유지보수)은 소프트웨어 유지보수의 약 80%를 차지한다.[5]

5. 유지보수성

유지보수성은 기존 기능을 손상시키지 않고 쉽게 수정할 수 있도록 하는 소프트웨어의 품질이다.[2] ISO/IEC 14764 규격에 따르면, 릴리스 전에 소프트웨어 유지보수성을 보장하기 위한 활동은 소프트웨어 유지보수의 일부로 간주된다.[3] 많은 소프트웨어 개발 조직에서는 유지보수성을 간과하지만, 그렇게 하면 장기적인 비용이 증가한다.[4] 프로그래머가 게으름이나 마감 기한을 맞추기 위한 급한 마음에 유지보수성을 코드에 구축하기보다는 빠르고 대충 처리하는 솔루션을 선택할 때 기술 부채가 발생한다.[5] 일반적인 원인은 소프트웨어 개발 노력 추정에서 과소 평가되어 개발에 충분한 리소스가 할당되지 않는 것이다.[6] 변경 사항으로 인해 기존 기능이 손상되었는지 감지할 수 있는 자동화된 소프트웨어 테스트를 갖추는 것이 중요하다.[2]

많은 소프트웨어 공학 과정에서 유지보수성의 과제를 강조하지 않고, 명확하고 변경되지 않는 사양을 가진 일회성 과제를 내준다.[7] 소프트웨어 공학 과정에서는 실제 세계에서 발생하는 것처럼 복잡한 시스템을 다루지 않는다.[8] 소프트웨어 유지보수에 대한 책임이 없다는 것을 아는 개발 엔지니어는 유지보수성을 구축할 유인이 없다.[2]

소프트웨어 유지보수에 특화된 기법 중 하나는 정적 슬라이싱이라고 불리는 기법으로, 특정 변수를 갱신하고 있는 프로그램 코드를 모두 찾아내는 방법이다. 리팩토링에 자주 사용되며, 2000년 문제 대응에서도 특히 많이 사용되었다.

6. 인력

소프트웨어 유지보수는 종종 소프트웨어 엔지니어들에게 보람 없는 일로 여겨지며, 유지보수를 맡게 되면 퇴사할 가능성이 더 높다.[2] 또한, 소프트웨어 개발 분야의 비슷한 직무보다 보수가 적은 경우가 많다.[2] 유지보수 엔지니어는 구식 기술에 익숙해야 하기 때문에 개발자보다 나이가 많은 경향이 있다.[2] 이 작업은 종종 임시직 근로자나 숙련도가 낮은 직원에게 할당되기도 한다.[2] 2008년, 미국에서 근무하는 130만 명의 소프트웨어 엔지니어와 프로그래머 중 약 90만 명이 유지보수를 담당했다.

기업들은 유지보수를 위한 별도의 팀을 구성하기 시작했고, 이는 이 작업을 다른 회사에 아웃소싱하는 것으로 이어졌다. 21세기 초에는 원래 회사 또는 별도 법인의 일부로 다른 국가로 오프쇼어링하기도 했다. 아웃소싱의 일반적인 출처는 미국, 영국, 일본, 호주와 같은 선진국이며, 목적지는 주로 중국, 인도, 러시아, 아일랜드와 같은 저비용 국가이다. 오프쇼어링의 이유는 낮은 인건비 활용, 24시간 지원 가능, 개발자의 시간 압박 감소, 제품 시장에 더 가까운 지원 이동 등이 있다. 오프쇼어링의 단점으로는 시차 및 조직적 분열과 문화적 차이와 같은 요인으로 인한 의사 소통 장벽이 있다. 많은 고용주가 유지보수를 숙련도가 낮은 작업으로 간주하고 오프쇼어링에 가장 적합한 소프트웨어 개발 단계로 간주하지만,[2] 고객과의 긴밀한 의사 소통과 빠른 대응이 필요하며, 이는 이러한 의사 소통의 어려움으로 인해 방해를 받는다.

7. 유지보수의 대안

소프트웨어 공학에서 레거시 시스템은 고정된 의미를 갖지 않지만, 크고, 수정하기 어렵고, 현재 비즈니스 요구에 필요한 구형 시스템을 지칭하는 경우가 많다. 종종 레거시 시스템은 구식 프로그래밍 언어로 작성되고, 문서가 부족하며, 수년간의 변경 후에 구조가 악화되고, 전문가에게 의존하여 작동을 유지한다.[1] 이러한 시스템을 다룰 때, 어느 시점에서는 너무 많은 기술 부채가 축적되어 유지보수가 실용적이지 않거나 경제적이지 않게 된다.[2]

레거시 시스템을 다루는 대안은 다음과 같다.


  • 동결: 레거시 시스템에 더 이상 작업을 수행하지 않는다.[3] 이 옵션은 공급업체가 유지보수 비용을 피하면서 가능한 한 오랫동안 수익을 창출하려는 경우 선택될 수 있다.[2]
  • 아웃소싱: 레거시 시스템의 기능을 다른 회사에 아웃소싱한다. 특히 핵심 비즈니스 기능으로 간주되지 않는 경우.[3]
  • 폐기 후 재개발: 기존 레거시 시스템을 폐기하고 레거시 시스템과 동일한 목적을 수행하는 새로운 애플리케이션을 처음부터 다시 개발한다.[3] 그러나 이 방식은 작동하는 시스템을 폐기하기 때문에 비효율적이며, 새로운 시스템이 변화하는 비즈니스 요구 사항을 충족하지 못할 위험이 있다.[3]
  • 래핑: 레거시 애플리케이션을 추상화 계층으로 래핑하여 오래된 인터페이스를 단순화한다.[3] 소스 코드는 수정되지 않지만 새로운 인터페이스를 통해 검증된 구성 요소에 최신 애플리케이션에서 액세스할 수 있다. 이 접근 방식은 레거시 시스템 유지보수와 관련된 문제를 해결하지 못한다.[4] 데이터베이스, 기능 및 전체 애플리케이션이 이러한 방식으로 래핑될 수 있다.[5]
  • 마이그레이션: 레거시 시스템을 새로운 플랫폼으로 마이그레이션하면 레거시 시스템의 구현, 설계, 사양 및 요구 사항을 재사용하여 새로운 소프트웨어 개발 비용을 줄일 수 있다.[6] 마이그레이션은 5~10년이 걸릴 수 있지만, 더 큰 유연성과 소프트웨어 유지보수 비용의 장기적인 절감 효과를 가져온다.[7] 비용의 최대 80%는 테스트에 소요된다. 즉, 새 시스템이 이전 시스템과 동일한 출력을 갖도록 보장하는 것이다.[8] 새 시스템이 완료된 후에는 비즈니스 기능에 대한 중단을 최소화하면서 이전 시스템에서 새 시스템으로의 전환이 필요하다.[8]

8. 연구 동향

소프트웨어 유지보수와 시스템 진화는 1969년 매니 리먼(Manny Lehman)에 의해 처음 기술되었다. 20년 후, 그의 연구를 통해 리먼의 법칙(리먼 1997) 공식이 만들어졌다. 그의 연구에서 발견된 주요 사항은 유지보수가 진화적인 개발 방식이며, 유지보수 결정은 시간이 지남에 따라 시스템(및 소프트웨어)에 발생하는 것을 이해함으로써 도움을 받는다는 것이다. 코드 리팩토링과 같은 조치를 통해 복잡성을 낮추지 않으면 소프트웨어는 진화를 거듭할수록 더 복잡하게 변한다.

소프트웨어 개발 자원의 대부분을 차지함에도 불구하고, 유지보수는 소프트웨어 개발 단계 중 가장 연구가 덜 된 단계이다. 관련 문헌 대부분은 처음부터 유지보수가 용이한 코드를 개발하는 방법에 초점을 맞추고 있으며, 엔지니어가 유지보수를 우선순위로 여기도록 동기를 부여하는 데는 상대적으로 덜 집중하고 있다. 2020년 현재, 유지보수 노력을 줄이기 위한 코드 리팩토링 자동화 솔루션과 머신러닝 기반의 유지보수성 평가가 활발히 연구되고 있다.[1]

참조

[1] 간행물 IEEE Std 610.12-1990, IEEE Standard Gloassary of Software Engineering Terminology http://www.mit.jyu.f[...]
[2] 웹사이트 Overview of Software Maintenance and Evolution https://cs.gmu.edu/~[...] 2018-01-01
[3] 서적 The Practical Guide to Structured Systems Design Yourdon Press 1980-01-01
[4] 서적 Software Maintenance Management:Evaluation and Continuous Improvement Wiley 2008-01-01
[5] 서적 ソフトウェア技術－ ソフトウェアライフサイクル－保守 財団法人　日本規格協会 2008-01-01
[6] 웹인용 ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance http://www.iso.org/i[...] Iso.org 2011-12-17
[7] 서적 Practical software maintenance: Best practices for managing your software investment Wiley Computer Pub. (New York) 1997-01-01
[8] 논문 Does Code Decay? Assessing Evidence from Change Management Data. IEEE Transactions on Software Engineering 2001-01-01


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

문의하기 : help@durumis.com