패치 (컴퓨팅)

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

1. 개요

패치(patch)는 소프트웨어의 오류 수정, 기능 변경 등을 위해 배포되는 코드 조각을 의미한다. 초창기에는 물리적인 방식으로 배포되었으나, 인터넷의 발달로 웹사이트나 자동 업데이트를 통해 다운로드하는 방식으로 변화했다. 패치는 바이너리 파일 형태와 소스 코드 형태가 있으며, 대규모 수정 사항은 서비스 팩 또는 소프트웨어 업데이트로 배포되기도 한다. 패치는 몇 바이트에서 수백 메가바이트까지 크기가 다양하며, 운영체제와 컴퓨터 서버의 보안 취약점을 해결하는 데 중요한 역할을 한다. 또한, 핫픽스, 포인트 릴리스, 보안 패치, 서비스 팩 등 다양한 유형으로 분류되며, 비디오 게임 및 소프트웨어 개발에서 광범위하게 사용된다.

더 읽어볼만한 페이지

소프트웨어 유지 보수 - 기술 부채
기술 부채는 소프트웨어 개발에서 발생하는 개념으로, 현재의 편의적인 설계가 미래에 추가적인 비용을 발생시키는 것을 의미하며, 다양한 원인으로 발생하여 개발 비용 증가, 프로젝트 지연, 경쟁력 약화 등의 부정적인 결과를 초래할 수 있다.
소프트웨어 유지 보수 - 소프트웨어 유지보수
소프트웨어 유지보수는 개발 후 발생하는 변경 및 수정 활동으로, 소프트웨어 자산 가치 유지 및 시스템 수명 연장에 중요한 역할을 하며, 오류 수정, 기능 개선, 진화, 융합, 지속적인 개선 및 발전 등을 포함하고 수정, 예방, 적응, 완전화 유지보수 등으로 분류된다.

패치 (컴퓨팅)
일반 정보
종류	데이터
용도	프로그램의 오류 수정 기능 향상 보안 취약점 해결
적용 대상	소스 코드 실행 파일 라이브러리
배포 방식	공식 업데이트 비공식 패치
기술적 측면
구현 방식	차이점 파일 (diff file) 대체
적용 방법	자동 패치 수동 패치
핫픽스 (Hotfix)	긴급 수정 패치
관련 용어
업데이트 (Update)	프로그램의 전체적인 개선 및 변경
서비스 팩 (Service Pack)	여러 개의 패치를 묶어 제공하는 형태
롤백 (Rollback)	패치 적용 이전 상태로 되돌리는 것

2. 역사

소프트웨어 패치의 역사는 초창기 컴퓨터 프로그래밍 시대로 거슬러 올라간다. 초기에는 프로그램 오류를 수정하기 위해 종이 테이프나 천공 카드의 특정 부분을 물리적으로 수정하거나 교체하는 방식이 사용되었다. 이후 기술이 발전하면서 패치는 자기 테이프를 통해 배포되기 시작했으며, 이동식 디스크 드라이브가 발명된 후에는 디스크나 CD-ROM과 같은 저장 매체에 담아 우편 등으로 전달되었다. 인터넷이 널리 보급되면서 패치 배포 방식은 다시 한번 크게 변화했다. 개발사의 웹사이트에서 사용자가 직접 패치를 다운로드하거나, 소프트웨어 업데이트 기능을 통해 자동으로 패치를 적용받는 방식이 일반화되었다.

2. 1. 초창기 역사

최초의 디지털 컴퓨터 가운데 하나인 1944년 하버드 마크 I의 프로그램 테이프. 천공된 부분을 물리적인 패치 조각으로 덮어 수정했다.

"패치(patch)"라는 용어는 초창기 컴퓨터에서 프로그램이 천공 테이프에 기록되던 시절, 프로그램 오류를 수정하기 위해 테이프의 구멍을 물리적인 조각(패치)으로 막거나 새로 뚫었던 방식에서 유래했다.^[31] 당시에는 프로그램의 오류를 수정하거나 기능을 변경하기 위해 이처럼 물리적인 패치 조각을 사용하여 구멍을 막거나 새로운 구멍을 뚫는 방식으로 코드를 직접 수정했다. 최초의 디지털 컴퓨터 중 하나인 하버드 마크 I의 프로그램 테이프에서도 이러한 물리적 패치의 흔적을 찾아볼 수 있다. 오른쪽 사진은 하버드 대학교 자연사 박물관에 전시된 1940년대 하버드 마크 I용 천공 테이프로, 사진 상단의 숫자 '260' 위아래 구멍을 회색 패치로 막고 다른 위치에 구멍을 새로 뚫어 코드를 수정한 모습을 보여준다. 천공 카드 역시 비슷한 방식으로 수정되었다.

역사적으로 소프트웨어 공급업체들은 수정된 부분만 담은 종이 테이프나 천공 카드 조각을 사용자에게 배포했다. 사용자는 이를 받아 원본 테이프나 카드 덱(deck)의 해당 부분을 잘라내고 새 조각으로 교체(패치)하는 방식으로 프로그램을 수정했다. 이후 기술이 발전하면서 패치는 자기 테이프를 통해 배포되기 시작했다. 이동식 디스크 드라이브가 발명된 후에는 디스크에 담아 제공되었고, 이후에는 우편으로 배송되는 CD-ROM을 통해 배포되기도 했다.

인터넷이 보급되면서 사용자는 개발사의 웹사이트에서 직접 패치를 다운로드하거나, 자동화된 소프트웨어 업데이트 기능을 통해 패치를 적용받을 수 있게 되었다. 특히 컴퓨터 네트워크 속도가 느렸던 초기 인터넷 시대에는 프로그램 전체를 다시 받는 것이 매우 비효율적이었다. 따라서 변경된 부분만을 추출한 차분 데이터 형태의 패치가 널리 사용되었다. 프로그램 전체를 다운로드하는 데 몇 시간이 걸릴 수 있었지만, 차분 패치는 몇 분 만에 다운로드를 완료할 수 있어 시간을 절약할 수 있었다. 또한, 상시 접속 환경이 보편화되지 않았던 시기에는 다운로드 시간이 길어질수록 통신 비용이 많이 들었기 때문에, 차분 패치는 비용 절감 측면에서도 유용했다. 차분 데이터를 추출하고 이를 이용해 프로그램을 업데이트하기 위해서는 별도의 전용 소프트웨어가 필요했으며, 수동으로 업데이트할 때는 원래 프로그램의 버전과 패치 버전이 정확히 일치해야 오류 없이 적용될 수 있었다.

오늘날에는 네트워크 브로드밴드화와 상시 접속 환경의 보급으로, 수십 메가바이트(MB) 크기의 컴파일된 애플리케이션이라도 업데이트 시 전체 파일을 다시 다운로드하는 경우가 많아졌다. 하지만 여전히 상용 소프트웨어나 OS의 버그 수정, 오픈 소스 소프트웨어의 변경 사항을 배포할 때에는 차분 패치 방식이 사용된다. 특히 유닉스(UNIX) 계열 환경에서 사용자가 자신의 환경에 맞게 소스 코드를 수정할 때도 패치 형식이 흔히 쓰인다. 이는 서버의 전송 부하를 줄이고 전체적인 다운로드 시간을 단축하는 데 여전히 효과적이기 때문이다.

2. 2. 인터넷 시대

인터넷이 보급되면서 패치를 배포하는 방식에도 큰 변화가 생겼다. 이전에는 종이 테이프나 천공 카드, 자기 테이프, 디스크, CD-ROM 등을 우편으로 보내는 방식이었지만, 인터넷 시대가 열리면서 사용자들이 직접 개발사의 웹사이트에서 패치를 다운로드하거나 자동화된 소프트웨어 업데이트 기능을 통해 패치를 받는 것이 가능해졌다.

컴퓨터 네트워크 속도가 지금처럼 빠르지 않았던 초기 인터넷 시대에는 프로그램 전체를 다시 다운로드하는 것은 비효율적이었다. 따라서 프로그램의 변경된 부분만을 차분 데이터 형태로 추출하여 배포하는 방식이 널리 사용되었다. 전체 프로그램을 다운로드하는 데 몇 시간이 걸릴 수 있었지만, 차분 데이터만 받으면 몇 분 만에 업데이트를 완료할 수 있었다. 이는 당시 네트워크 속도가 느렸을 뿐만 아니라, 상시 접속 환경이 보편화되지 않아 통신 요금을 절약해야 했던 사용자들에게 유용한 방식이었다. 다만, 차분 데이터를 이용한 업데이트는 전용 소프트웨어가 필요했고, 원래 프로그램의 버전을 정확히 확인하고 맞는 패치를 적용해야 오류를 피할 수 있었다.

오늘날에는 브로드밴드 네트워크와 상시 접속 환경이 일반화되면서, 수십 메가바이트에 달하는 컴파일된 프로그램이라도 업데이트 시 전체 파일을 다시 다운로드하는 경우가 많아졌다. 그럼에도 불구하고, 상용 소프트웨어나 OS의 버그 수정, 오픈 소스 소프트웨어의 변경 사항 공유, 또는 사용자가 자신의 환경에 맞게 소스 코드를 수정할 때에는 여전히 패치 방식이 활발하게 이용된다. 이는 서버의 데이터 전송량을 줄이고 전체적인 다운로드 시간을 단축하는 데 여전히 효과적이기 때문이다.

3. 유형

패치는 배포 방식이나 목적에 따라 여러 유형으로 나눌 수 있다. 대표적으로 실행 파일 형태로 배포되는 바이너리 패치와 소스 코드 변경점 형태로 배포되는 소스 코드 패치가 있다. 또한, 수정 규모가 매우 큰 경우에는 서비스 팩이나 소프트웨어 업데이트 등으로 불리기도 한다.

3. 1. 바이너리 패치

상용 소프트웨어의 패치는 일반적으로 소스 코드가 아닌 실행 파일 형태로 배포된다. 이 파일들은 실행 시 메모리에 프로그램을 로드하여 디스크 상의 대상 프로그램에 패치 코드를 설치한다.

다른 종류의 소프트웨어 패치는 패치 코드를 포함하는 데이터 파일 형태로 배포되기도 한다. 이 파일들은 설치를 수행하는 패치 유틸리티 프로그램에 의해 읽힌다. 이 유틸리티는 대상 프로그램의 실행 파일, 즉 프로그램의 기계어 코드를 직접 수정한다. 일반적으로 기존 코드를 새로운 패치 코드로 덮어쓰는 방식으로 작동한다.

인라인 패치(Inline Patch): 만약 새로운 코드가 기존 코드와 크기가 같거나 작아서 원래 공간에 들어갈 수 있다면, 기존 코드를 직접 덮어쓰는 방식으로 패치가 이루어진다.
코드 추가 방식: 새로운 코드가 기존 코드보다 커서 원래 공간에 맞지 않는 경우, 패치 유틸리티는 대상 프로그램의 오브젝트 파일에 새로운 코드를 포함하는 로드 레코드를 추가한다. 그리고 원래 코드 위치에는 분기 명령어(점프 또는 호출)를 삽입하여 실행 흐름이 새로 추가된 코드로 이동하도록 수정한다.

예를 들어, 초기의 8비트 마이크로컴퓨터였던 라디오셱 TRS-80의 운영 체제에는 텍스트 파일 형태의 패치 데이터를 읽어 대상 프로그램의 실행 바이너리 파일에 수정 사항을 적용하는 `PATCH/CMD` 유틸리티가 포함되어 있었다.

작은 규모의 기계어 패치는 CP/M의 DDT나 MS-DOS의 DEBUG와 같은 시스템 디버그 유틸리티를 사용하여 수동으로 적용할 수도 있다. BASIC 인터프리터 환경에서는 프로그래머들이 `POKE` 명령어를 사용하여 시스템 서비스 루틴이나 인터프리터 자체의 기능을 변경하는 경우가 많았다.

바이너리 패치의 크기는 몇 바이트에서 수백 메가바이트에 이르기까지 매우 다양하다. 패치의 크기는 변경 사항의 규모뿐만 아니라, 패치가 파일 전체를 포함하는지 또는 변경된 부분만 포함하는지에 따라 달라진다. 특히 컴퓨터 게임의 패치처럼 그래픽이나 사운드 파일 같은 프로그램 외적인 데이터를 추가하거나 교체하는 경우 패치 크기가 상당히 커질 수 있다.

바이너리 파일 패치는 온라인 게임의 버전 업데이트나 소프트웨어의 현지화(예: 일본어화) 등 다양한 분야에서 널리 사용된다.

바이너리 파일 패치는 텍스트 파일 패치와는 다른, 효율성을 높이기 위한 특화된 알고리즘으로 만들어진다. 예를 들어, bsdiff^[28]는 xdelta^[29]보다 50~80%, RTPatch^[30]보다 15% 더 작은 패치 파일을 생성한다고 알려져 있다.

3. 2. 소스 코드 패치

패치는 소스 코드 수정의 형태로도 유통될 수 있다. 이 경우, 패치는 일반적으로 "diff"라고 불리는 두 소스 코드 파일 간의 텍스트 차이로 구성된다. 이러한 유형의 패치는 주로 오픈 소스 소프트웨어 프로젝트에서 나온다. 개발자는 사용자가 새 파일 또는 변경된 파일을 직접 컴파일할 것으로 예상한다.

3. 3. 대규모 패치

"패치"라는 단어는 일반적으로 작은 규모의 수정을 의미하는 경우가 많다. 따라서 규모가 큰 수정이나 프로그램의 상당 부분을 변경하는 경우에는 다른 명칭을 사용하기도 한다. 이러한 대규모 패치는 주로 "서비스 팩" 또는 "소프트웨어 업데이트"라는 이름으로 배포된다. 예를 들어, 마이크로소프트의 윈도우 NT 및 그 이후 버전들(윈도우 2000, 윈도우 XP, 윈도우 비스타, 윈도우 7 등)에서는 대규모 업데이트를 "서비스 팩"이라고 부른다.^[3] 과거 IBM에서는 이러한 업데이트를 "FixPak"이나 "수정 서비스 디스켓"이라는 용어로 지칭하기도 했다.^[4]

4. 적용

상용 소프트웨어의 패치는 일반적으로 실행 파일 형태로 배포되며, 소스 코드 형태로 배포되지는 않는다. 이 파일을 실행하면 메모리에 프로그램을 로드하여 디스크의 대상 프로그램에 패치 코드를 설치한다.

다른 종류의 소프트웨어 패치는 패치 코드를 포함하는 데이터 파일 형태로 배포되는 경우가 많다. 이 파일들은 설치를 수행하는 패치 유틸리티 프로그램에 의해 읽힌다. 이 유틸리티는 대상 프로그램의 실행 파일(기계어)을 직접 수정하는데, 보통 기존 바이트를 새 패치 코드를 나타내는 바이트로 덮어쓴다. 새 코드가 이전 코드와 같은 공간(바이트 수)에 들어맞으면, 이전 코드를 직접 덮어쓰는 방식으로 삽입될 수 있다. 이를 인라인 패치(inline patch)라고 한다. 만약 새 코드가 이전 코드보다 크다면, 패치 유틸리티는 패치할 대상 프로그램의 오브젝트 파일에 새 코드를 포함하는 로드 레코드를 추가한다. 패치된 프로그램이 실행될 때, 기존 코드 중 새 코드가 필요한 위치에 분기 명령(점프 또는 호출)을 삽입하여 실행 흐름을 새 코드로 이동시킨다. 예를 들어, 초기 8비트 마이크로컴퓨터였던 TRS-80의 운영 체제에는 텍스트 파일에서 패치 데이터를 읽어 대상 프로그램의 실행 바이너리 파일에 수정 사항을 적용하는 PATCH/CMD 유틸리티가 포함되어 있었다.

패치 코드는 실행될 때 메모리 공간이 필요하다. 인라인 패치는 비교적 간단하지만, 추가 메모리 공간이 필요할 경우 프로그래머는 임시적인 해결책을 찾아야 한다. 숙련된 프로그래머는 나중에 확장을 위해 미리 메모리 공간을 예약해두기도 한다. 패치할 코드를 직접 만들지 않은 프로그래머는 필요한 추가 공간을 찾아야 하는데, 패치할 루틴이 별도의 모듈로 존재하면 비교적 쉽다. 이 경우 모듈의 크기를 나타내는 포인터나 길이 표시자만 조정하면 된다. 하지만 그렇지 않다면, 프로그래머는 기존 루틴을 줄여 공간을 확보해야 한다. 이때 더 효율적인 명령어를 사용하거나, 메시지 문자열 같은 데이터 영역을 압축하거나, 일부 기능을 디스크 오버레이 등으로 외부화하거나, 덜 중요하다고 판단되는 기능을 제거하는 방법을 사용하기도 한다.

작은 메모리 내 기계어 패치는 CP/M의 DDT나 MS-DOS의 DEBUG 같은 시스템 디버그 유틸리티를 사용하여 수동으로 적용할 수도 있다. BASIC 인터프리터 사용자들은 POKE 명령을 사용하여 시스템 서비스 루틴이나 인터프리터 자체의 기능을 변경하기도 했다.

패치의 크기는 몇 바이트에서 수백 메가바이트까지 매우 다양하다. 변경 사항이 클수록 패치 크기도 커지지만, 패치가 파일 전체를 포함하는지 아니면 변경된 부분만 포함하는지에 따라서도 달라진다. 특히, 컴퓨터 게임 패치처럼 그래픽이나 사운드 파일 같은 프로그램 외 데이터를 추가하거나 교체하는 경우 패치 크기가 상당히 커질 수 있다. 소프트웨어 초기 설치에 비해 패치를 적용하는 데 걸리는 시간은 일반적으로 길지 않다.

운영 체제 및 컴퓨터 서버 소프트웨어의 경우, 패치는 보안 취약점을 수정하는 데 특히 중요한 역할을 한다. 일부 중요한 패치는 드라이버 관련 문제를 해결하기도 한다.^[5] 패치를 적용하기 위해 다른 패치가 미리 적용되어야 하거나, 여러 소프트웨어 구성 요소를 동시에 업데이트해야 할 수도 있다. 업데이트 과정을 쉽게 하기 위해 운영 체제는 종종 자동 또는 반자동 업데이트 기능을 제공한다. 하지만 완전 자동 업데이트는 패치의 안정성 문제나 소프트웨어 회사가 시스템 통제권을 과도하게 가질 수 있다는 관리자의 우려 등으로 인해 기업 환경에서는 널리 퍼지지 못했다. 패키지 관리 시스템은 다양한 수준의 패치 자동화를 제공할 수 있다.

완전 자동 업데이트는 마이크로소프트 윈도우가 이를 지원하고, Windows XP 서비스 팩 2(2004년 출시)에서 기본적으로 활성화하면서 소비자 시장에서 널리 보급되었다. 하지만 신중한 사용자, 특히 시스템 관리자는 수정 사항의 안정성을 확인할 때까지 패치 적용을 미루는 경향이 있다. 마이크로소프트의 (W)SUS는 이러한 지연 적용을 지원한다. 대규모 패치나 중요한 변경 사항이 포함된 패치의 경우, 배포자는 종종 베타 테스트를 통해 자격을 갖춘 개발자에게만 먼저 공개하기도 한다.

펌웨어에 패치를 적용하는 것은 특별한 주의가 필요하다. 단순히 변경된 부분만 적용하는 것이 아니라, 완전히 새로운 펌웨어 이미지를 제공해야 하는 경우가 많기 때문이다. 패치는 보통 바이너리 데이터 형태의 펌웨어 이미지와, 이전 버전을 새 버전으로 교체하는 공급 업체가 제공하는 특수 프로그램으로 구성된다. 마더보드 BIOS 업데이트가 대표적인 펌웨어 패치의 예이다. 업데이트 도중 정전과 같은 예기치 않은 오류나 중단이 발생하면 마더보드를 사용할 수 없게 될 위험이 있다. 이를 방지하기 위해 마더보드 제조업체는 안전 장치를 마련하기도 한다. 예를 들어, 업데이트 전에 펌웨어 백업 복사본을 만들고, 업데이트 후 체크섬(CRC) 등을 이용해 기본 복사본이 손상되었는지 확인하여 문제가 있을 경우 백업본을 사용하도록 하는 방식이다.

컴퓨터 네트워크 속도가 느렸던 과거에는 프로그램의 일부를 변경하기 위해 전체 프로그램을 다시 다운로드하는 것은 매우 비효율적이었다. 그래서 변경이 필요한 부분만 차분 데이터로 추출하여 배포하는 패치 형식이 널리 사용되었다. 전체 프로그램을 다운로드하는 데 몇 시간이 걸릴 수 있었지만, 차분 데이터만 받으면 몇 분 만에 완료할 수 있었기 때문이다. 이는 네트워크 속도 문제뿐만 아니라, 상시 접속 환경이 보편화되기 전에는 긴 다운로드 시간으로 인한 통신 요금 부담을 줄이는 데도 유용했다. 차분 데이터를 추출하거나 이를 이용해 업데이트하려면 전용 소프트웨어가 필요했고, 수동 업데이트 시에는 원본 프로그램의 버전을 정확히 확인하고 맞는 패치를 적용해야 오류를 피할 수 있었다.

오늘날에는 브로드밴드 네트워크와 상시 접속 환경이 보편화되면서, 수십 메가바이트 크기의 컴파일된 애플리케이션이라도 업데이트 시 전체를 다시 다운로드하는 방식이 많아졌다. 하지만 상용 소프트웨어나 운영 체제의 버그 수정, 오픈 소스 소프트웨어의 변경 사항 게시, 유닉스 커뮤니티 등에서 개별 환경에 맞게 소스 코드를 수정할 때에는 여전히 패치(차분) 형식이 이용된다. 이는 서버의 전송량 부담을 줄이고 전체적인 다운로드 시간을 단축하는 목적에는 변함이 없기 때문이다.

5. 비디오 게임에서의 패치

비디오 게임은 다른 소프트웨어처럼 초기 출시 후 호환성 문제를 해결하기 위해 패치를 받는다. 또한 게임 규칙이나 알고리즘을 변경하기 위해 적용되기도 한다. 특히 멀티플레이어 게임에서는 다른 플레이어보다 부당한 이점을 얻는 데 사용될 수 있는 악용이 발견되면 이를 막기 위해 패치가 이루어진다. 추가 기능이나 게임 플레이 조정이 이루어지기도 한다.

이러한 패치는 1인칭 슈팅 게임 중 멀티플레이어 기능을 갖춘 게임이나 MMORPG에서 흔하게 볼 수 있다. MMORPG는 내용이 방대하고 매우 복잡하여 초기 출시 이후 패치에 크게 의존하는 경향이 있다. 패치를 통해 플레이어에게 새로운 콘텐츠나 능력이 추가되기도 한다. MMORPG에서는 악용 문제로 인해 짧은 시간 안에 모든 플레이어 간의 밸런스나 공정성이 심각하게 훼손될 수 있다. 따라서 MMORPG 서버는 중요한 수정 사항이 포함된 패치를 적용하기 위해 때때로 예고 없이 중단되기도 한다.

한편, 일부 게임 회사들은 게임에 버그가 있다는 것을 알면서도 출시하는 경우가 있다. 1994년 게임 잡지 ''컴퓨터 게이밍 월드''의 스코피아는 "패치와 업그레이드로 넘어갈 수 있다는 것을 알고 조잡한 제품을 출시하고, 고객을 ''유료'' 테스터로 만드는 수많은 회사"를 비판했다.^[6]

6. 소프트웨어 개발에서의 패치

패치는 때때로 자주 사용되거나 유지보수 중인 프로그램의 라이브러리 또는 소스 코드의 일부 문제점을 수정하기 위해 필수적으로 적용되기도 한다. 이는 매우 대규모의 소프트웨어 프로젝트에서 흔히 발생하지만, 소규모 개발에서는 드물게 일어난다.

오픈 소스 프로젝트에서는 개발자들이 특정 문제를 해결하거나 프로젝트의 로케일 외부의 현지 언어 지원과 같은 특정 기능을 추가하는 패치를 흔히 받거나, 많은 사람들이 패치를 게시한다. 리눅스 커널 초기 개발 사례에서, 최초 개발자인 리누스 토르발스는 수많은 프로그래머로부터 자신의 초기 버전에 적용할 수 있는 수십만 개의 패치를 받았다.

아파치 HTTP 서버는 원래 브라이언 베렌도프가 NCSA HTTPd를 개선하기 위해 수집한 다수의 패치로 발전했으며, 따라서 이름은 패치 모음집을 의미한다("패치가 많은 서버"). 이 프로젝트 공식 사이트의 FAQ에 따르면 '아파치'라는 이름은 아파치 족에 대한 존경심에서 선택되었다고 한다. 하지만 '패치가 많은 서버'라는 설명이 처음에는 프로젝트 웹사이트에 제시되었다.^[7]

7. 변형

소프트웨어 패치는 그 목적과 배포 방식에 따라 여러 형태로 나뉜다. 긴급한 버그 수정을 위한 핫픽스, 작은 버그 수정이나 정리를 위한 포인트 릴리스, IBM 환경에서 사용되는 프로그램 임시 수정(PTF), 보안 취약점을 해결하는 보안 패치, 여러 업데이트를 묶어 제공하는 서비스 팩, 공식 개발자가 아닌 제3자가 만든 비공식 패치, 실행 중인 프로그램의 일부를 동적으로 수정하는 몽키 패치 등이 있다. 각 패치는 특정 상황과 요구에 맞춰 적용된다.

7. 1. 핫픽스 (Hotfix)

핫픽스 또는 퀵 픽스 엔지니어링 업데이트(QFE 업데이트)는 소프트웨어 제품의 문제(예: 버그)를 해결하기 위해 배포되는 단일 누적 패키지이다. 주로 하나 이상의 파일 형태로 제공되며, 특정 고객의 문제를 해결하기 위해 만들어지는 경우가 많다. 마이크로소프트는 과거에 이 용어를 사용했으나, 현재는 일반 배포 릴리스(GDR) 및 제한적 배포 릴리스(LDR)라는 용어를 더 선호하며 사용을 중단했다. 반면, 블리자드 엔터테인먼트는 핫픽스를 "정기적인 콘텐츠 패치까지 기다릴 수 없을 정도로 중요한 변경 사항"으로 정의하고 있다.

7. 2. 포인트 릴리스 (Point release)

포인트 릴리스는 소프트웨어 프로젝트의 마이너 릴리스로, 특히 중요한 기능을 추가하기보다는 버그를 수정하거나 작은 정리 작업을 수행하기 위한 릴리스이다. 종종 버그가 너무 많아 한 번의 메이저 또는 마이너 릴리스로 모두 수정하기 어려울 때 포인트 릴리스가 필요하게 된다.

7. 3. 프로그램 임시 수정 (Program temporary fix, PTF)

프로그램 임시 수정 또는 제품 임시 수정(Program temporary fix, PTF)은 IBM에서 사용하는 표준 용어로, 특정 날짜에 맞춰 고객이 설치할 수 있는 형태로 배포되는 단일 버그 수정 또는 여러 수정 사항의 묶음을 의미한다. PTF는 과거에 "ZAP"이라고 불리기도 했다.^[8]

고객은 PTF가 특정 문제를 성공적으로 해결했을 때, 해당 패치를 운영 체제의 영구적인 부분으로 적용할 수 있는 선택권을 가진다. 이 때문에 사용자들 사이에서는 PTF라는 약어를 "영구적인 임시 수정(Permanent Temporary Fix)"이나 "아마 이것이 고칠 것이다(Probably This Fixes-it)"와 같이 유머러스하게 해석하기도 한다.

7. 4. 보안 패치 (Security patches)

'''보안 패치'''는 소프트웨어의 약점, 즉 취약점으로 설명되는 부분을 수정하기 위해 적용되는 변경 사항이다. 이러한 수정 조치는 성공적인 악용을 방지하고, 특정 취약점을 이용하려는 위협의 능력을 제거하거나 완화하는 역할을 한다. 패치 관리는 취약점 관리의 일부이며, 취약점을 식별하고 분류하며, 이를 수정하고 완화하는 순환적인 과정을 포함한다.

보안 패치는 소프트웨어의 보안 취약점을 해결하는 주요 방법이다. 예를 들어, 마이크로소프트는 매달 한 번씩 정기적으로 보안 패치를 배포하는데, 이를 '패치 화요일'이라고 부른다. 다른 운영 체제나 소프트웨어 프로젝트 역시 보안팀을 운영하며, 취약점이 알려지면 가능한 한 빨리 신뢰할 수 있는 패치를 배포하기 위해 노력한다. 보안 패치의 배포 과정은 책임 있는 공개 원칙과도 밀접하게 연관되어 있다.

이러한 보안 패치를 적용하는 것은 기업이나 조직의 비즈니스 프로세스가 외부 위협으로 인해 영향을 받지 않도록 하는 데 매우 중요하다. 2017년 발생한 워너크라이 랜섬웨어 공격은 대표적인 사례이다. 이 공격은 일부 버전의 마이크로소프트 윈도우에 존재하던 취약점을 악용하여 사용자 파일을 암호화하고 비트코인으로 몸값을 요구했다. 당시 많은 기업이 피해를 입었으며, 이에 마이크로소프트는 해당 랜섬웨어의 실행을 막는 긴급 패치를 배포하여 대응했다.

7. 5. 서비스 팩 (Service pack)

서비스 팩(SP) 또는 기능 팩(FP)은 소프트웨어 프로그램에 대한 업데이트, 수정 사항, 향상된 기능들을 모아 하나의 설치 가능한 패키지로 만든 것이다. 소프트웨어 개발사는 특정 프로그램에 대한 개별 패치의 수가 일정 수준 이상이 되거나, 사용자 피드백이나 Bugzilla 같은 버그 추적 시스템을 통해 소프트웨어의 안정성이 확인되었을 때 서비스 팩을 출시하는 경우가 많다. 오피스 제품군, 운영 체제, 데이터베이스 소프트웨어, 네트워크 관리 도구처럼 규모가 큰 소프트웨어의 경우, 제품 출시 후 1~2년 안에 서비스 팩이 나오는 것은 흔한 일이다. 서비스 팩을 설치하면 여러 개의 개별 패치를 하나씩 설치하는 것보다 간편하고 오류 발생 가능성도 적다. 특히 네트워크를 통해 여러 컴퓨터를 한 번에 업데이트할 때 유용하다.

7. 6. 비공식 패치 (Unofficial patches)

비공식 패치는 원래의 소프트웨어 개발자가 아닌 제3자에 의해 작성된 프로그램용 패치이다. 일반적인 패치와 마찬가지로, 소프트웨어 버그 또는 단점을 완화한다. 예시로는 소프트웨어 제작사에서 공식 패치를 배포하는 데 시간이 너무 오래 걸릴 때 보안 전문가가 제공하는 보안 수정 사항이 있다.^[9]^[10] 또 다른 예시로는 지원이 중단된 비디오 게임의 게임 커뮤니티에서 만들어진 비공식 패치가 있다.^[11]^[12]

7. 7. 몽키 패치 (Monkey patches)

몽키 패치는 프로그램을 지역적으로 확장하거나 수정하는 것을 의미한다(프로그램의 실행 인스턴스에만 영향을 미침).

8. 핫 패칭 (Hot patching)

''핫 패칭''(hot patching)은 ''라이브 패칭''(live patching) 또는 ''동적 소프트웨어 업데이트''(dynamic software updating)라고도 하며, 시스템이나 관련 프로그램을 종료하고 다시 시작하지 않고 패치를 적용하는 것을 말한다. 이는 시스템이나 프로그램에서 제공하는 서비스의 사용 불가와 관련된 문제를 해결한다.^[13] 이 방법은 시스템을 중단하지 않고 리눅스 커널을 업데이트하는 데 사용될 수 있다.^[14]^[15] 이 방식으로 적용할 수 있는 패치를 ''핫 패치''(hot patch) 또는 ''라이브 패치''(live patch)라고 한다. 이는 모바일 앱 분야에서 흔히 사용되는 기술이 되고 있다.^[16] Rollout.io와 같은 회사는 메서드 스위즐링을 사용하여 iOS 생태계에 핫 패치를 제공한다.^[17] iOS 앱의 핫 패칭을 위한 또 다른 방법은 JSPatch이다.^[18]

클라우드 제공업체는 기본 인프라를 업데이트할 때 고객의 다운타임을 방지하기 위해 핫 패칭을 자주 사용한다.^[19]

9. 슬립스트리밍 (Slipstreaming)

컴퓨팅에서 슬립스트리밍은 패치(예: 서비스 팩)를 원래 앱의 설치 파일에 통합하여 업데이트된 앱을 직접 설치할 수 있도록 하는 행위이다.^[20]^[21]

슬립스트리밍은 처음에 시간과 노력이 필요하지만, 장기적으로 보면 많은 시간과 비용을 절약할 수 있다. 이는 많은 수의 컴퓨터를 관리하는 관리자에게 특히 유용하다. 일반적으로 각 컴퓨터에 운영 체제를 설치할 때는 원본 미디어를 사용한 다음 설치가 완료된 후 각 컴퓨터를 업데이트해야 한다. 하지만 슬립스트리밍을 통해 업데이트가 통합된 최신 소스로 설치를 시작하면, 이후에 필요한 업데이트 수를 줄일 수 있어 전체 설치 시간을 크게 단축할 수 있다.

그러나 모든 패치를 슬립스트리밍 방식으로 적용할 수 있는 것은 아니다. 또한, 특정 패치가 나중에 문제를 일으키는 원인으로 밝혀질 경우, 원본의 슬립스트리밍되지 않은 설치 소스를 사용하지 않고는 해당 패치를 제거하기 어렵다는 단점이 있다.

10. 소프트웨어 업데이트 시스템

소프트웨어 업데이트 시스템은 사용자와 소프트웨어 개발자가 업데이트를 관리할 수 있도록 지원한다. 2017년 페트야 사이버 팬데믹 당시에는 금융 소프트웨어 "MeDoc"의 업데이트 시스템이 해킹되어, 업데이트 과정을 통해 멀웨어가 확산되는 사건이 발생했다.^[22]^[23] 토르 블로그에서 사이버 보안 전문가 마이크 페리는 이러한 공격에 대응하기 위해 결정적 컴파일과 분산 빌드가 중요하다고 언급했다. 그는 이것이 단일 공식 서명을 통한 업데이트가 수백만 시스템을 감염시키는 것을 막는 유일한 방법일 수 있다고 주장했다.^[24]

업데이트 관리자는 보안 업데이트를 빠르고 광범위하게 적용하는 데 중요한 역할을 한다. 예를 들어, 리눅스 환경의 Synaptic과 같은 업데이트 관리자는 사용자가 컴퓨터에 설치된 모든 소프트웨어를 한 번에 업데이트할 수 있게 해준다. Synaptic과 같은 도구는 업데이트를 적용하기 전에 암호화 체크섬을 사용하여 원본 파일과 로컬 파일의 무결성을 검증함으로써 멀웨어 감염 위험을 줄인다.^[25]^[26]

과거 컴퓨터 네트워크 속도가 느렸던 시절에는 프로그램 일부를 변경하기 위해 전체 프로그램을 다시 다운로드하는 것은 매우 비효율적이었다. 이 때문에 변경이 필요한 부분만 차분 데이터 형태로 추출하여 배포하는 패치 방식이 널리 사용되었다. 전체 프로그램을 다운로드하는 데 몇 시간이 걸릴 수 있었지만, 패치를 이용하면 몇 분 만에 다운로드를 완료할 수 있었다. 이는 느린 네트워크 속도뿐만 아니라, 상시 접속 환경이 보편화되지 않아 긴 다운로드 시간으로 인한 회선 사용료 부담을 줄이는 데도 유용했다. 다만, 차분 데이터를 추출하고 이를 이용해 프로그램을 업데이트하려면 전용 소프트웨어가 필요했으며, 수동 업데이트 시에는 원래 프로그램의 버전을 정확히 확인하고 해당 버전에 맞는 패치를 적용해야 오류를 피할 수 있었다.

오늘날에는 네트워크의 브로드밴드화와 상시 접속 환경의 보급으로, 수십 메가바이트 크기의 컴파일된 애플리케이션이라도 업데이트 시 전체를 다시 다운로드하는 방식이 흔해졌다. 그럼에도 불구하고, 상용 소프트웨어나 OS의 버그 수정, 오픈 소스 소프트웨어의 변경 사항 배포 시에는 여전히 패치가 활용된다. 특히 UNIX 커뮤니티에서는 사용자의 특정 환경에 맞게 소스 코드를 조정할 때 패치 형식이 일반적으로 사용된다. 이는 상시 접속 환경이 보편화된 현재에도 서버의 전송량을 줄이고 전체적인 다운로드 시간을 단축하는 데 여전히 유효하기 때문이다.

11. 악의적인 업데이트

일부 해커는 합법적인 소프트웨어 업데이트 채널을 손상시키고 악성 코드를 주입할 수 있다.

참조

_[1] 뉴스 Microsoft issues biggest software patch on record http://www.news.com.[...] 2009-10-14
_[2] 웹사이트 What is a Bug Fix? – Definition from Techopedia http://www.techopedi[...] 2015-07-29
_[3] 웹사이트 Service Pack and Update Center http://windows.micro[...] 2015-06-01
_[4] 웹사이트 Glossary of terms http://www.tavi.co.u[...] 2016-11-23
_[5] 서적 Computercare's Laptop Repair Workbook: The 300 Cases of Classic Notebook Computers Troubleshooting and Repair https://books.google[...] AuthorHouse 2015-01-08
_[6] 간행물 So You Want To Be A Hero? http://www.cgwmuseum[...] 1994-04
_[7] 웹사이트 Apache HTTP Server Project http://www.apache.or[...] 1997-06-15
_[8] 웹사이트 SPZAP (a.k.a. Superzap): Dynamically update programs or data https://www.ibm.com/[...] 2020-02-23
_[9] 웹사이트 Unofficial patch for Windows URI problem http://www.h-online.[...] The H Security 2012-01-29
_[10] 웹사이트 Another unofficial IE patch offered to counter critical flaw http://www.computerw[...] Computer Weekly 2013-07-09
_[11] 웹사이트 Keeping the Myths Alive http://linuxdevcente[...] linuxdevcenter.com 2012-12-22
_[12] 웹사이트 Opening the Source of Art http://timreview.ca/[...] Technology Innovation Management Review 2012-12-30
_[13] 웹사이트 Oracle Magazine http://www.oracle.co[...] Oracle.com 2013-01-04
_[14] 웹사이트 Live patching the Linux kernel https://developer.ib[...] 2020-10-25
_[15] 웹사이트 Linux Kernel Live Patching: What It is and Who Needs It https://www.infosecu[...] 2020-10-25
_[16] 웹사이트 Hot or Not? The Benefits and Risks of iOS Remote Hot Patching « Threat Research Blog https://www.fireeye.[...] 2016-10-26
_[17] 웹사이트 Rollout.io Puts Mobile Developers Back In Control Of Their Apps https://techcrunch.c[...] 2016-10-26
_[18] 웹사이트 bang590/JSPatch https://github.com/b[...] 2016-10-26
_[19] 웹사이트 Hot Patching SQL Server Engine in Azure SQL Database https://techcommunit[...] 2019-09-15
_[20] 웹사이트 Build an XP SP3 Recovery Disc https://www.pcmag.co[...] Ziff Davis 2017-09-07
_[21] 웹사이트 Slipstreaming Windows XP with Service Pack 3 (SP3) http://winsupersite.[...] Penton (company) 2016-12-03
_[22] 웹사이트 Virus (cough, cough, Petya) goes postal at FedEx, shares halted https://www.theregis[...] 2017-06-29
_[23] 웹사이트 New Petya Distribution Vectors Bubbling to Surface https://threatpost.c[...] Threatpost 2017-06-28
_[24] 웹사이트 Deterministic Builds Part One: Cyberwar and Global Compromise {{!}} The Tor Blog https://blog.torproj[...] 2017-07-11
_[25] 서적 Introducing Ubuntu: Desktop Linux https://books.google[...] Cengage Learning 2017-07-11
_[26] 서적 HWM https://books.google[...] SPH Magazines 2017-07-11
_[27] 웹사이트 How Malicious Software Updates Endanger Everyone https://www.aclu.org[...] american civil liberties union
_[28] 문서 bsdiff, bspatch http://www.daemonolo[...]
_[29] 문서 Xdelta http://xdelta.org/
_[30] 문서 RTPatch http://www.pocketsof[...]
_[31] 뉴스 ソフトウェアの修正プログラムのことをなぜ「パッチ(当て布)」と呼ぶのか？ https://gigazine.net[...] 2017-01-17
_[32] 뉴스 Microsoft issues biggest software patch on record http://www.news.com.[...] 2009-10-14
_[33] 웹인용 What is a Bug Fix? – Definition from Techopedia http://www.techopedi[...] 2015-07-29