품질 관리

품질 관리 (Quality Management)

이 문서는 SQLite의 품질 관리 계획(Quality Management Plan)이에요. SQLite 개발 팀이 어떻게 일하며, 소프트웨어 품질을 어떻게 유지·검증하는지 설명해요.

출처: 문서

본문

이 문서는 SQLite의 품질 관리 계획이에요.

품질 관리 문서는 대개 아무도 읽지 않는 난해한 전문 용어로 가득한 바인더로 커지기 마련이에요. 이 문서는 간결하고 유용함으로써 그러한 패턴을 깨고자 해요.

이 문서의 영감은 DO-178B예요. 품질 표준 중 DO-178B가 서류 대비 유용성 비율이 가장 높아 보여요. 그래도 완전한 DO-178B 구현에 필요한 문서량은 방대해요. SQLite는 민첩하고 절차를 가볍게 유지하려고 노력하며, 그런 이유로 요구되는 DO-178B 문서 중 상당수를 생략해요. SQLite 같은 오픈소스 소프트웨어 프로젝트의 품질을 실질적으로 개선하는 부분만 유지해요.

이 문서의 목적은 SQLite 개발 팀이 어떻게 일상적으로 기능을 향상시키고 이미 높은 신뢰성을 개선하기 위해 노력하는지를 독자에게 알려 주는 것이에요. 이 문서를 훑어본 유능한 개발자가 개발 팀에 빠르게 적응할 수 있다면, 문서는 목적을 달성한 거예요.

이 문서에 대해 (About This Document)

품질 관리 계획은 원래 DO-178B의 11절(48~56쪽)에 나오는 산출물 설명을 검토하고 SQLite와 관련 있는 요소를 적어 내려가며 작성됐어요. 이후 텍스트는 SQLite 품질 프로세스의 개선을 따라가도록 개정될 거예요.

소프트웨어 개발 계획 (Software Development Plan)

이 절은 DO-178B의 "인증을 위한 소프트웨어 측면 계획"과 "소프트웨어 개발 계획" 절을 결합한 것이에요.

SQLite 소프트웨어가 무엇을 하는지, 어떻게 다른지에 대한 개요는 About SQLite를 참고하세요.

소프트웨어 수명 주기 (Software Life Cycle)

SQLite는 지속적 통합(continuous integration) 프로세스를 사용해요. 소프트웨어는 지속적으로 향상되고 다듬어져요. 최신 trunk 체크인은 내부적으로 미션 크리티컬 운영에 자주 사용돼요.

미리 정의된 릴리스 주기는 없어요. 기능 향상 및/또는 버그 수정이 임계 수준에 도달하면 릴리스가 발생해요. 역사적으로 릴리스는 연간 약 5~6회 발생했어요. SQLite 사용자는 필요에 따라 웹사이트에서 새 릴리스를 받아요.

유지보수 릴리스 (Maintenance Releases)

일상적인 유지보수 릴리스에는 기능 향상, 성능 향상, 그리고/또는 중요하지 않은 문제 수정이 포함돼요. 주 버전(major release)의 버전 번호는 어떤 정수 N에 대해 "3.N.0" 형식이에요. 자세한 내용은 버전 번호 규칙 문서를 참고하세요.

예정된 유지보수 릴리스는 예상 릴리스 약 2주 전에 SQLite 포럼에서 공지돼요. 릴리스 약 1주 전에 수석 개발자가 "pencils down"(새 기능 체크인 중단)을 선언한 뒤, trunk에서는 버그 수정 체크인만 허용돼요. 새 릴리스 체크리스트가 만들어지고 필요에 따라 갱신돼요. 체크리스트 항목이 검증되면 체크되어 초록색으로 바뀌어요. 체크리스트의 모든 항목이 초록색이 되면 릴리스가 발생해요. 그 과정은 보통 약 1주가 걸려요.

패치 릴리스 (Patch Releases)

때때로 심각한 문제가 발견되어 일반 유지보수 릴리스에 대해 작은 "패치" 릴리스를 내야 할 때가 있어요. 패치는 이전 릴리스에서 바뀐 코드 줄 수가 적다는 점에서 유지보수 릴리스와 구별돼요. 유지보수 릴리스가 버그가 없도록 만들어 패치 릴리스를 피하기 위해 최선을 다해요.

패치 릴리스에는 문제에 따라 릴리스 체크리스트가 있을 수도 있고 없을 수도 있어요. 이는 프로젝트 리더의 판단에 달려 있어요.

릴리스 이력 (Release History)

문서 시스템은 과거 릴리스의 연대기와, 변경 요약이 포함된 SQLite 릴리스 전체 목록을 자동으로 유지해요.

일정 (Schedule)

SQLite는 장기적인 비전을 갖고 있어요. 계획은 SQLite가 적어도 2050년까지 사용·지원될 것이라는 가정 아래 이루어져요. 모든 코드는 언젠가 아직 태어나지 않은 사람들이 읽고 유지 관리하게 될 것이라는 생각으로 작성돼요. 코드는 미래의 개발자들이 논리와 배경을 더 쉽게 이해하도록 돕는 데 초점을 맞춰 조심스럽게 주석 처리돼요.

소프트웨어 개발 환경 (Software Development Environment)

SQLite는 이식성 높은 C 코드로 작성돼요. 개발 작업은 Linux, Mac, Windows 워크스테이션 혼합에서 이루어져요. 개발자들은 명령줄 도구를 사용하며 가능하면 통합 개발 환경(IDEs)을 피해요. 모든 개발자는 unix 명령줄에 능숙할 것이 요구돼요.

정식 소스에서 SQLite를 컴파일하고 테스트하기 위한 최소 설정은 다음과 같아요.

  • 32비트 또는 64비트 주소 공간을 가진 호스트 컴퓨터. OS는 Linux, Mac, Windows, *BSD, Solaris 등일 수 있어요.
  • GCC(Windows용 MinGW 변형 포함), Clang, MSVC 같은 C99 컴파일러.
  • 사용자가 선택한 UTF-8 텍스트를 지원하는 텍스트 편집기.
  • Tcl 8.6 이상.
  • "make" 유틸리티, 또는 Windows의 경우 선택적으로 "nmake".

Tcl 스크립트 언어는 정식 소스 코드를 amalgamation으로 변환하고 테스트를 관리하는 데 사용돼요. Tcl 자체는 SQLite에서 직접 사용되지는 않아요(컴파일 옵션으로 요청하지 않는 한). amalgamation 소스를 사용하는 최종 사용자는 Tcl이 필요 없어요.

CLI를 빌드할 때 다음 타사 라이브러리가 있으면 도움이 되지만 필수는 아니에요.

SQLite의 완전한 릴리스 테스트에는 추가 소프트웨어가 필요해요.

SQLite는 모든 현대 운영체제, 모든 현대 컴퓨터 아키텍처, 모든 현대 C 컴파일러에서 동일하게 동작하고 정확히 동일한 온디스크 형식을 사용할 것으로 기대돼요. 개발자들은 구할 수 있는 한 다양한 플랫폼에서 SQLite를 지속적으로 테스트해요.

소프트웨어 검증 계획 (Software Verification Plan)

SQLite의 테스트 프로세스는 testing 문서에 설명돼 있어요. 테스트 목표는 다음과 같아요.

  • 제공되는(as-delivered) 구성에서 100% MC/DC
  • 소스 코드와 목적 코드(object code) 모두 테스트
  • 여러 플랫폼, 여러 컴파일러에서 테스트
  • 퍼즈(fuzz) 테스트
  • 코드 변경 검사
  • 코드의 동적·정적 분석

테스트 프로세스는 릴리스 테스트 체크리스트로 통제돼요. 체크리스트는 SQLite를 완전히 검증하는 데 필요한 모든 단계를 간결히 요약하고, 각 검증 단계가 언제 누구에 의해 수행됐는지 기록해요.

릴리스 체크리스트의 항목 집합은 릴리스마다 갱신될 수 있어요. 각 릴리스 체크리스트의 내용과 전체 이력은 기록으로 보존돼요.

소프트웨어 구성 관리 (Software Configuration Management)

버전 관리 (Version Control)

SQLite 소스 코드는 Fossil 버전 관리 시스템으로 관리돼요. Fossil은 SQLite 개발을 지원하기 위해 특별히 작성됐어요. Fossil은 분산 버전 관리와 이슈 추적을 모두 제공해요.

생존성 (Survivability)

모든 코드는 세 대의 별도 머신에 보관돼요: https://sqlite.org, https://www2.sqlite.org, https://www3.sqlite.org. 이 머신들은 서로 다른 도시(각각 Dallas, Newark, San Francisco)에 위치하며, 서로 다른 두 호스팅 회사(Linode가 처음 두 곳, Digital Ocean이 세 번째)가 관리해요. 이런 다양성은 단일 실패 지점을 피하기 위한 것이에요.

Dallas의 주 머신 https://sqlite.org/이 기본 서버이고 대부분의 사람들이 사용해요. 나머지 두 곳은 백업으로 간주돼요.

공식 저장소 외에도 개발자들은 보통 모든 소프트웨어의 전체 복제본을 개인 머신에 보관해요. 인터넷 곳곳에도 다른 복제본이 흩어져 있어요.

저장소 (Repositories)

SQLite 소스는 여러 저장소로 나뉘며, 각각 아래 섹션에서 설명해요.

SQLite 소스 코드 (SQLite Source Code)

SQLite 소스 코드와 TCL 테스트 모음은 하나의 저장소에 함께 저장돼요. 이 저장소 하나만 있으면 SQLite 소스를 빌드할 수 있어요. 소스 저장소는 공개되어 있으며 인터넷의 익명 방문자가 읽을 수 있어요.

SQLite 문서 소스 (SQLite Documentation Sources)

문서 소스에는 SQLite 웹사이트 문서를 구성하는 데 필요한 스크립트와 makefile과 함께 문서 텍스트 및 이미지가 포함돼요. 이 문서 자체도 문서 소스 안에 포함돼요. 문서 소스는 소스 코드와는 구별되는 별도의 저장소에 보관돼요. 문서 소스 저장소는 공개적으로 읽을 수 있어요.

문서를 생성하는 데 사용되는 makefile과 스크립트는 문서 소스 저장소의 기준 문서에서 텍스트를 수집해요. 추가 텍스트는 SQLite 소스 코드의 주석에서 추출돼요. 요구사항 커버리지 정보는 소스 저장소에 포함된 TCL 테스트 모음과, 별도의 비공개 저장소에 있는 TH3 테스트 모음의 주석에서 추출돼요.

SQL 로직 테스트 (SQL Logic Test)

SQL 로직 테스트는 SQLite가 다른 SQL 데이터베이스 엔진과 동일하게 동작함을 보여 주도록 설계된 테스트 케이스 모음이에요. 이 테스트는 별도의 공개 코드 저장소에 호스팅돼요.

테스트 하네스 #3 (Test Harness #3)

테스트 하네스 #3(TH3) 테스트 모음은 제공되는 구성에서 SQLite를 100% MC/DC로 테스트하는 데 사용되는 비공개 테스트 케이스 집합이에요. TH3 소스는 다른 SQLite 저장소와 같은 서버에서 제공되지만, 독점적이라는 점에서 다르며, SQLite 개발자만 접근할 수 있어요.

Dbsqlfuzz

dbsqlfuzz 모듈은 SQLite용 libFuzzer 기반 퍼저예요. dbsqlfuzz는 SQL과 데이터베이스 파일을 동시에 퍼징해요. dbsqlfuzz는 맞춤형 변이기(mutator)를 사용해요.

dbsqlfuzz는 사용 가능한 다른 어떤 퍼저보다 문제를 찾는 데 더 뛰어난 것 같아요. 그래서 비공개로 유지돼요. 해커들이 이 기술에 접근하는 것을 원하지 않아요.

소프트웨어 검증 결과 (Software Verification Results)

릴리스 테스트는 체크리스트로 진행돼요. 각 체크리스트의 현재 상태와 전체 변경 이력은 별도의 SQLite 데이터베이스 파일에 저장돼요. 이 파일들은 버전 관리되지 않지만, 비공개 백업 서버에 별도의 사본이 유지돼요.

체크리스트를 실행하는 소프트웨어의 소스 코드는 https://sqlite.org/checklistapp의 자체 Fossil 저장소에 저장돼요.

소프트웨어 요구사항 표준 및 데이터 (Software Requirements Standards And Data)

SQLite 프로젝트에서 "요구사항"은 프로젝트 문서예요. 문서 텍스트의 특별한 마크업이 개별 요구사항을 식별해요. 요구사항 번호는 정규화된 요구사항 텍스트의 암호화 해시를 기반으로 해서, 요구사항 번호를 바꾸지 않고 요구사항 텍스트를 바꾸는 것은 불가능해요.

문서 텍스트(따라서 요구사항 텍스트)는 위에 설명된 SQLite 문서 소스 저장소와 구현의 주석에서 가져와요. 문서를 빌드하는 makefile은 문서 소스 저장소에 있어요.

문서가 빌드될 때 요구사항이 식별되고 라벨이 붙어요. 문서 빌드 프로세스는 각 요구사항을 검증하는 테스트 케이스도 스캔하여, 어떤 요구사항이 테스트됐는지와 그 요구사항을 테스트하는 구체적인 테스트 케이스를 보여 주는 매트릭스를 구성해요.

소프트웨어 설계 및 코딩 표준 (Software Design And Coding Standards)

SQLite의 객관적인 코딩 표준은 최소한이에요.

  • 들여쓰기는 2칸
  • 80자를 초과하는 줄 없음
  • 탭 사용 금지

그 외 모든 설계·코딩 규칙은 주관적이에요. 여기서 목표는 소프트웨어를 2050년까지 읽기 쉽고 유지 관리 가능하게 만드는 것이에요. 그를 위해 간결하면서도 유용한 주석(보일러플레이트 없음), 신중하게 고른 변수명, 각 데이터 구조의 의미와 각 코드 블록의 역할에 대한 세심한 설명을 지향해요.

문제 보고 (Problem Reports)

모든 문제는 신속하게 수정돼요. SQLite 소프트웨어에는 오래 방치된 문제가 없어요.

SQLite가 사용하는 Fossil 버전 관리 시스템에는 티켓 추적이 내장돼 있어요. 이 내장 티켓 시스템은 많은 역사적 문제를 추적하고 기록하는 데 사용돼요.

SQLite 커뮤니티 포럼은 인터넷의 누구나 SQLite에 대해 질문하거나 버그를 보고할 수 있는 곳이에요. 타사가 발견한 버그는 종종 처음에 포럼에 보고돼요. 포럼에 보고된 버그는 때때로 티켓으로 전환되는데, 최근에는 포럼에서 그냥 처리하는 추세예요. 포럼은 훌륭한 전문 검색 기능을 갖추고 여러 머신에 미러링되며 티켓 시스템만큼 검색 가능하고 생존 가능하므로, 포럼에서 발생한 버그 보고를 티켓 시스템에 중복 등록할 필요가 없어 보여요. 포럼의 공개 위치는 다음과 같아요.

소스 저장소와 마찬가지로 포럼도 다양한 비공개 머신으로 동기화돼요. Fossil의 방식 때문에 이 "백업"들은 단순한 읽기 전용 백업 이상이에요. 데이터 입력으로도 기능할 수 있어요. 어느 저장소에 입력하든 모든 내용이 모든 저장소로 동기화돼요.

더 알아보기 (Learn more)