apt update 중복 소스 오류 해결 방법

중복된 apt 소스 오류의 의미

중복된 apt 소스 오류는 하나의 저장소가 두 개의 서로 다른 파일에 선언되어 있어 APT(advanced package tool)가 두 복사본을 모두 발견했음을 의미합니다. Ubuntu 24.04 이상 버전에서는 타사 설치 스크립트가 기존의 한 줄짜리 .list 파일을 생성하는 반면, 동일한 저장소에 대한 deb822 형식의 .sources 파일이 이미 디스크에 존재하기 때문에 거의 항상 발생합니다. 데이터가 손상된 것은 아니며 패키지에도 아무런 위험이 없습니다. 두 선언 중 하나를 삭제하면 메시지가 사라집니다.

다음은 사용자들이 검색창에 입력하는 오류 메시지 예시입니다.

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

메시지를 끝부분부터 읽어 보십시오. 파일 두 개가 각각의 줄 번호와 함께 동일한 내용을 선언하고 있습니다. Target Packages는 apt가 저장소에서 제공하는 패키지를 파악하기 위해 다운로드하는 인덱스이며, stable/binary-amd64/Packages은 해당 인덱스가 다루는 구성 요소(stable)와 아키텍처(amd64)를 지정합니다. 즉, apt는 stable 구성 요소에 대한 amd64 인덱스가 docker.list의 1번 줄과 docker.sources의 1번 줄에 중복 설정되어 있다고 알리는 것입니다.

Ubuntu 25.04 이상 및 Debian 13부터 적용되는 apt 3.0 이상 버전에서는 동일한 메시지가 W: 대신 Warning:로 시작합니다. 접두사 뒤의 텍스트는 동일합니다.

위의 경고는 경미한 경우입니다. apt가 두 선언을 병합하므로 업데이트는 정상적으로 실행됩니다. 두 선언이 동일한 키를 가진 동일한 아카이브를 설명하기 때문입니다. 하지만 심각한 경우에는 모든 작업이 중단됩니다.

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

이 경우 apt는 두 선언이 하나의 아카이브에 대해 서로 다른 서명 키를 지정하고 있기 때문에 작업을 거부합니다. apt는 동일한 선언 두 개는 병합할 수 있지만, 서로 다른 Signed-By 값 중 하나를 임의로 선택하지는 않습니다. 잘못된 키를 선택하면 아카이브 소유자가 서명하지 않은 키를 기준으로 패키지 서명을 검증하게 되기 때문입니다. 따라서 apt는 소스 파일을 전혀 읽지 않게 됩니다. 파일을 직접 수정하기 전까지는 apt update와 apt install 모두 동일한 두 줄의 오류 메시지를 출력하며 실패합니다.

중복이 발생하는 이유

두 형식은 확장자가 다른 별도의 파일에 존재하므로, 디스크상에서 두 파일이 공존하는 것을 막는 요소는 없습니다. apt는 모든 소스 파일을 가져올 인덱스 대상 목록으로 확장하는 시점에야 비로소 중복을 감지합니다. 그전까지 docker.list와 docker.sources는 서로 관련 없는 두 개의 파일일 뿐입니다.

다음 네 가지 일반적인 상황에서 이 쌍이 생성됩니다.

• 벤더 설치 스크립트나 오래된 게시물에서 복사한 명령어가 tee 라인이 포함된 /etc/apt/sources.list.d/vendor.list를 생성합니다.
• 이후 벤더의 패키지가 /etc/apt/sources.list.d/vendor.sources를 배포하여 설치합니다.
• Ubuntu 24.04 이상에서 add-apt-repository는 deb822 형식의 .sources 파일을 작성하므로, 이전에 수동으로 추가했던 .list 형식의 PPA(개인 패키지 아카이브)가 .sources 형식으로 다시 나타납니다.
• 릴리스 업그레이드 과정에서 배포판 자체의 소스 파일이 deb822 형식으로 재작성되었으나, 사용자가 직접 작성한 .list 파일은 그대로 남겨집니다.

각 경로는 개별적으로는 타당합니다. 중복은 이 중 두 가지 상황이 동일한 시스템에서 수개월의 간격을 두고 발생할 때 나타나는 결과입니다.

두 가지 형식의 비교

기존 형식은 저장소당 한 줄을 사용하며, 모든 구성 요소가 위치에 따라 결정됩니다.

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

순서는 고정되어 있습니다. 유형(바이너리 패키지는 deb, 소스 패키지는 deb-src), 대괄호로 묶인 옵션, 아카이브의 URI(Uniform Resource Identifier), 스위트(suite), 하나 이상의 컴포넌트 순입니다. 위치에 따라 의미가 결정되므로, 공백 하나만 잘못 들어가도 apt가 읽는 내용이 달라집니다.

deb822는 동일한 내용을 이름이 지정된 필드들의 스탠자(stanza)로 표현합니다. 이름은 Debian이 패키지 제어 파일에 이미 사용 중인 메일 헤더 스타일인 RFC 822에서 유래했습니다.

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

동일한 저장소, 동일한 키를 사용하며 추가된 내용은 없습니다. 매핑은 직접적입니다. deb는 Types이 되고, 아카이브 주소는 URIs, 스위트는 Suites, 컴포넌트는 Components이 됩니다. 각 대괄호 옵션은 개별 필드가 되어 signed-by=는 Signed-By:로, arch=은 Architectures:로 변환됩니다.

모든 필드는 공백으로 구분된 목록을 허용하므로 필드 이름은 복수형입니다. 하나의 스탠자 내에 있는 Suites: noble noble-updates noble-backports은 세 개의 개별 deb 줄을 대체합니다. 빈 줄은 스탠자의 끝을 의미하므로, 하나의 .sources 파일에 여러 저장소를 담을 수 있습니다. 또한 deb822는 기존 한 줄 형식에서 다루기 어려웠던 설정들을 지원합니다. 저장소를 비활성화하는 Enabled: no, Trusted, Check-Valid-Until, 그리고 모든 줄을 한 칸 들여쓰고 빈 줄은 점 하나로 표기하여 Signed-By에 직접 붙여넣는 인라인 키 등이 이에 해당합니다.

파일 위치

• /etc/apt/sources.list: 원본 단일 파일입니다. Ubuntu 24.04 이상 버전에서는 보통 비어 있거나 새로운 위치를 가리키는 주석만 포함되어 있습니다.
• /etc/apt/sources.list.d/*.list: 한 줄짜리 항목으로, 일반적으로 저장소당 파일 하나를 사용합니다.
• /etc/apt/sources.list.d/*.sources: deb822 형식의 스탠자입니다. Ubuntu 24.04 이상 버전은 배포판 자체 저장소를 이곳의 ubuntu.sources에 보관합니다.
• /etc/apt/keyrings/: 사용자가 추가한 키가 위치하는 곳입니다. /usr/share/keyrings/에는 패키지에서 제공된 키가 저장됩니다.

apt는 .list 또는 .sources로 끝나는 파일만 읽으며, 파일 이름에는 영문자, 숫자, 밑줄, 하이픈, 마침표만 사용할 수 있습니다. 다른 확장자를 가진 파일은 알림과 함께 무시되는데, 이는 아래의 수정 작업에서 중요하게 다뤄집니다.

중복 쌍 찾기

디렉터리 목록에서 시작합니다:

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

동일한 이름(stem)에 확장자만 다른 두 파일이 일반적인 쌍이지만, 파일 이름만 믿어서는 안 됩니다. 파일 내용은 무엇이든 될 수 있으므로 중복이 숨어 있을 수 있습니다. 따라서 내용을 읽어야 합니다:

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

이 쌍은 동일한 호스트와 동일한 스위트(suite)를 가진 두 항목입니다. 둘 다 https://download.docker.com/linux/ubuntu 및 스위트 noble를 가리키고 있으므로, 동일한 저장소가 두 번 작성된 것입니다. 또한 두 항목의 Signed-By 경로가 일치하지 않으며, 이것이 앞서 표시된 Conflicting values 오류를 발생시키는 원인입니다.

이 단계에서는 apt 명령 대신 grep을 사용하십시오. apt는 이미 충돌로 인해 중단된 상태이므로 소스 목록을 표시할 수 없으며, apt-cache policy을 실행해도 원하는 답변 대신 동일한 오류만 출력됩니다.

문제 해결: deb822 파일은 유지하고 레거시 파일은 제거하기

.sources 파일을 유지하십시오. 이는 현재 apt 도구가 작성하는 형식이며, Debian과 Ubuntu 모두 이 방향으로 나아가고 있습니다. 무엇인가를 삭제하기 전에 디스크에 다음 두 키 경로 중 어느 것이 존재하는지 확인하십시오:

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

/etc/apt/keyrings/docker.asc만 존재하므로 deb822 파일이 올바른 정보를 담고 있으며, .list 파일은 제거된 키를 가리키고 있습니다. 만약 유지하려는 파일에 누락된 키가 명시되어 있다면, 먼저 작동하는 경로를 해당 파일에 복사한 뒤 다른 파일을 삭제하십시오.

레거시 파일을 즉시 삭제하는 대신 디렉터리 밖으로 이동시키십시오:

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

파일 이름을 docker.list.bak로 변경하여 제자리에 두는 방법도 가능합니다. apt는 알 수 없는 확장자를 무시하기 때문입니다. 하지만 이 경우 apt를 실행할 때마다 다음 메시지가 출력됩니다:

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

파일을 다른 곳으로 옮기면 화면에 해당 알림이 뜨지 않으며 백업본도 유지할 수 있습니다. 이후 정상적인 apt update 상태는 다음과 같으며, 두 파일을 가리키는 줄이 없어야 합니다:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

이제 저장소가 편집 후에도 정상적으로 유지되는지 확인하십시오:

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

만약 공급업체의 문서가 여전히 한 줄짜리 파일을 기준으로 작성되어 있다면, 해당 파일을 유지하고 대신 .sources 파일을 삭제해도 됩니다. 어떤 방식을 선택하든 한 가지 규칙만 지키면 됩니다. 특정 아카이브와 제품군을 선언하는 파일은 반드시 하나여야 합니다.

왜 깨진 서드파티 소스 하나가 apt update를 멈추게 하는가

인접한 실패 사례는 양상은 다르지만 근본 원인은 동일합니다. apt가 사용할 수 없는 서드파티 소스 때문입니다. 첫 번째 버전은 키가 누락된 경우입니다.

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Signed-By 필드가 누락되었거나, 유효한 키 파일이 아닌 곳을 가리키고 있어 apt가 아카이브의 InRelease 파일에 대한 서명을 검증할 수 없습니다. apt는 검증할 수 없는 패키지 목록을 신뢰하는 대신 해당 저장소 전체를 폐기합니다. 키 파일 자체를 확인하십시오.

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

정상적인 키라면 키 ID가 포함된 pub 라인과 공급업체 이름이 명시된 uid 라인이 출력됩니다. gpg: no valid OpenPGP data found.가 출력된다면 해당 파일은 키가 아니라는 뜻이며, 이는 보통 키 URL이 변경되어 다운로드 시 오류 페이지가 저장되었음을 의미합니다. 키를 다시 가져와 파일을 확인한 후 apt update을 실행하십시오.

두 번째 버전은 릴리스 업그레이드 후에 발생합니다.

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

PPA가 해당 제품군(suite)에 대해 아무것도 게시하지 않았으므로 서버에 경로가 존재하지 않아 요청 시 404 오류가 반환됩니다. 다른 저장소는 여전히 업데이트되며 이미 보유한 패키지는 영향을 받지 않습니다. 그러나 실행 결과가 0이 아닌 값으로 종료되므로, apt update의 종료 상태를 확인하는 모든 스크립트는 실행될 때마다 실패를 보고하게 됩니다. 이것이 무인 보안 업그레이드가 구성된 서버에서 죽은 소스를 정리해야 하는 이유입니다. 매일 발생하는 오류 메시지 속에 실제 장애가 숨어들기 때문입니다. 공급업체 설치 스크립트들은 이러한 두 가지 버전을 모두 겪게 되며, 이것이 대부분의 Ubuntu에서의 Tailscale 설치 오류가 스크립트가 작성하지 않은 키링 문제이거나 아카이브가 지원하지 않는 릴리스 코드네임 문제로 귀결되는 이유입니다.

나머지 설정에 영향을 주지 않고 특정 소스 비활성화하기

deb822 형식 파일의 경우, 스탠자에 필드 하나를 추가하고 저장합니다:

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

apt 매뉴얼은 스탠자의 각 줄을 주석 처리하는 것보다 이 방법을 권장하며, 되돌리기도 더 쉽습니다. 한 줄로 된 파일의 경우, 줄 시작 부분에 #를 추가합니다. 두 형식 모두 /etc/apt/sources.list.d/에서 파일을 이동시키는 방법도 유효하며, 저장소가 영구적으로 삭제된 경우 이 방법을 선택해야 합니다.

sudo apt update를 다시 실행합니다. 해당 저장소에 대한 Err: 블록이 사라지며, 종료 상태는 0으로 반환됩니다. 이는 다음 줄에서 echo $?을 통해 확인할 수 있습니다.

sudo rm /etc/apt/sources.list.d/*을 사용하여 손상된 소스를 수정하지 마십시오. Ubuntu 24.04 이상 버전에서 이 명령을 실행하면 배포판 자체 저장소를 담고 있는 ubuntu.sources이 삭제됩니다. 이로 인해 apt는 패키지 목록을 전혀 확보하지 못하게 되며, 분명히 존재하는 소프트웨어에 대해서도 E: Unable to locate package curl 오류를 보고하게 됩니다. 이미 명령을 실행했다면 파일을 다시 작성하십시오:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

이 내용을 /etc/apt/sources.list.d/ubuntu.sources으로 저장하고, noble 부분을 lsb_release -cs에서 확인한 본인의 릴리스 이름으로 바꾼 뒤 sudo apt update을 실행하십시오.

레거시 .list 파일을 deb822 형식으로 변환

2026년 8월부터 apt 3.0 이상 버전은 이를 위한 변환 도구를 제공합니다. Debian 13, Ubuntu 25.04 및 26.04를 포함한 이후의 모든 릴리스에 이 도구가 포함되어 있습니다. 버전을 확인한 후 다음 명령을 실행하십시오.

apt --version
sudo apt modernize-sources

이 명령은 /etc/apt/sources.list.d/ 아래에 있는 한 줄짜리 파일들을 deb822 형식의 .sources 파일로 다시 작성합니다. 출력 내용을 확인한 다음, 직접 디렉터리 목록을 조회하고 apt update을 실행하여 결과를 신뢰할 수 있는지 검증하십시오. Ubuntu 24.04는 해당 하위 명령이 없는 이전 버전의 apt를 사용하므로, 이 명령을 실행하면 E: Invalid operation modernize-sources이라는 응답이 출력됩니다. 해당 릴리스에서는 위에서 설명한 필드 매핑을 참고하여 수동으로 변환해야 합니다.

현재 apt는 두 형식 모두 읽을 수 있으므로 변환은 선택 사항입니다. 하지만 앞으로 계속 운영할 서버라면 변환하는 것이 좋습니다. 소스 파일을 작성하는 모든 도구가 이제 deb822 형식을 사용하므로, .sources 파일만 존재하는 환경을 유지하면 형식 중복 문제를 방지할 수 있습니다.

서버의 서드파티 소스 관리하기

서드파티 저장소는 서버에서 가장 빠르게 노후화되는 부분입니다. 각 저장소는 타인이 사용자의 Ubuntu 릴리스에 맞춰 패키지를 계속 배포하겠다는 약속과 같습니다. 릴리스 업그레이드를 진행하면 그 모든 약속이 같은 날 오후에 한꺼번에 시험대에 오르게 됩니다.

• 배포판 패키지로 해결할 수 없을 때만 서드파티 저장소를 추가하십시오. Ubuntu 24.04의 LAMP 스택과 같은 일반적인 환경은 서드파티 저장소가 필요 없습니다. Ubuntu 아카이브는 해당 스택이 사용하는 모든 패키지를 포함하며, 릴리스 수명 동안 보안 업데이트를 제공합니다.
• 키는 /etc/apt/keyrings/에 저장하고, 벤더별로 파일을 하나씩 생성하며, 권한은 644로 설정하십시오. 권한이 없는 _apt 사용자가 다운로드를 수행하며 키를 읽어야 하므로, root만 읽을 수 있는 키 파일은 저장소에서 데이터를 가져올 때마다 권한 오류를 발생시킵니다.
• 각 스탠자(stanza)에서 Signed-By가 해당 파일을 정확히 가리키도록 설정하십시오. /etc/apt/trusted.gpg나 /etc/apt/trusted.gpg.d/에 위치한 키는 서버의 모든 저장소에 대해 신뢰를 부여합니다. 즉, 수년 전에 추가한 벤더 키가 출처를 알 수 없는 패키지까지 검증할 수 있게 됩니다.
• 릴리스 업그레이드 전에 소스 목록을 검토하고, 각 벤더가 업그레이드하려는 릴리스용 패키지를 이미 배포하고 있는지 확인하십시오.

기존의 전역 키링에 있는 키는 업데이트를 수행할 때마다 다음과 같은 경고를 발생시킵니다.

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

해당 키를 별도의 파일로 내보낸 뒤, 저장소 스탠자에서 해당 파일을 가리키도록 수정하십시오.

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

저장소 스탠자에 Signed-By: /etc/apt/keyrings/docker.gpg를 추가하고 sudo apt update를 실행하십시오. 기존 키링에 의존하는 저장소가 없으면 경고는 사라지며, 이후 sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8을 사용하여 해당 항목을 삭제할 수 있습니다.

한 가지 습관이 가장 큰 고통을 줄여줍니다. do-release-upgrade은 업그레이드 시 서드파티 소스를 비활성화하고 업그레이드 후에도 꺼진 상태로 유지합니다. 이를 하나씩 수동으로 다시 켜는 과정에서 중복 선언이 발생하기 쉽습니다. 시작하기 전에 Ubuntu 24.04에서 26.04로의 업그레이드 가이드를 읽고, 여전히 필요한 저장소가 무엇인지 기록해 두십시오. 새로 구축한 서버라면 새 VPS에서의 첫 10분 동안 소스 설정을 올바르게 잡는 것이 가장 효율적입니다. 이때는 서버에 Ubuntu가 기본으로 제공한 항목들만 존재하기 때문입니다.

FAQ

apt에서 대상이 여러 번 설정되었다는 메시지가 나오는 이유는 무엇입니까?

/etc/apt/sources.list.d/ 아래의 파일 두 개가 동일한 저장소, 제품군, 구성 요소를 선언하고 있기 때문입니다. 메시지에는 docker.list:1 및 docker.sources:1와 같이 파일 이름과 줄 번호가 표시됩니다. apt는 이들을 병합하여 작업을 계속하므로 업데이트 자체는 정상적으로 수행됩니다. 하지만 중복 설정은 제거하는 것이 좋습니다. 두 파일이 서로 다른 서명 키를 지정하는 즉시 apt는 E: Conflicting values set for option Signed-By 오류를 발생시키며 모든 소스 읽기를 거부하고, 이로 인해 apt install 작업까지 차단되기 때문입니다.

.list 파일과 .sources 파일 중 무엇을 유지해야 합니까?

.sources 파일을 유지하십시오. deb822는 Ubuntu 24.04 이상에서 add-apt-repository가 사용하는 형식입니다. 이 형식은 대괄호 안의 위치 기반 텍스트 대신 설정별로 명명된 필드를 사용하며, 향후 배포판의 표준이 될 방식입니다. .list 파일을 삭제하기 전에 .sources 파일 내부의 Signed-By 경로가 ls -l /etc/apt/keyrings/ 명령으로 확인 가능한 실제 키를 가리키고 있는지 확인하십시오. 기존 파일을 /etc/apt/sources.list.d/ 디렉터리 내부에서 이름만 바꾸지 말고 디렉터리 밖으로 이동시키십시오. .bak 확장자를 가진 파일이 남아 있으면 apt가 실행될 때마다 무시된 파일이라는 알림을 출력하기 때문입니다.

apt 저장소를 삭제하지 않고 비활성화하려면 어떻게 합니까?

deb822 형식의 .sources 파일에서는 해당 스탠자에 Enabled: no를 추가하십시오. 한 줄로 된 .list 파일에서는 줄 맨 앞에 #를 삽입하십시오. 어느 경우든 이후에 sudo apt update를 실행하면 해당 저장소의 Err: 블록이 사라집니다. 서드 파티 저장소에 현재 사용 중인 Ubuntu 릴리스용 패키지가 없어 404 오류로 인해 apt update 명령이 0이 아닌 종료 코드를 반환할 때 이 방법을 사용하는 것이 좋습니다.

한 줄로 된 sources.list 형식은 사라집니까?

해당 형식은 폐기 예정(deprecated)일 뿐 제거된 것은 아닙니다. apt는 여전히 .list 파일을 읽으며 앞으로도 오랫동안 지원할 것이므로 서버의 기존 설정이 당장 중단되지는 않습니다. 새로운 도구들은 deb822 형식을 작성합니다. Ubuntu 24.04 이상은 배포판 저장소를 /etc/apt/sources.list.d/ubuntu.sources에 유지하며, add-apt-repository은 .sources 파일을 생성합니다. apt 3.0 이상에서는 sudo apt modernize-sources 명령을 사용하여 기존 파일을 변환할 수 있습니다.