오류 문구를 그대로 찾는 사전

104개의 오류 문구를 무슨 뜻이고 왜 났고 어떻게 하는지로 풀었습니다.

고치는 명령에는 값이 따릅니다. git reset --hard는 커밋하지 않은 일을 버리고, 강제 푸시는 남의 커밋을 지우며, docker system prune은 이름 없는 볼륨을 지웁니다. 그런 자리는 설명에 그 값을 적어 두었습니다.

Git29

git의 오류는 거의 다 "지금 상태에서 그 일을 하면 무언가 잃는다"는 거절이고, fatal:은 아무것도 하지 않고 멈췄다는 뜻이니 첫 줄보다 그 아래 hint: 줄이 실제 해법을 담고 있는 경우가 많습니다.

npm20

npm ERR!로 시작하는 줄은 대개 마지막 여섯 줄이 아니라 첫 code XXXX 한 줄에 원인이 적혀 있고, 오류가 내 코드가 아니라 의존성 나무나 네이티브 빌드에서 온 것이면 node_modules를 지우고 다시 설치하는 것으로 절반이 풀립니다.

JavaScript15

브라우저와 node의 오류는 대개 무엇이 잘못되었는지만 알려 주고 왜 그 값이 그렇게 되었는지는 알려 주지 않아서 — undefined를 읽었다, 함수가 아니었다, JSON이 아니었다 — 고칠 자리는 터진 줄이 아니라 그 값을 만든 위쪽에 있고, ?.와 기본값으로 그 줄만 조용하게 만들면 같은 문제가 더 먼 곳에서 더 알아보기 어려운 꼴로 다시 나타납니다.

Uncaught TypeError: Cannot read properties of undefined (reading 'name')점 왼쪽의 값이 undefined인데 그 속성을 읽으려 했다는 뜻이고, 괄호 안의 이름이 읽으려던 속성이니 잘못된 것은 그 앞의 값입니다. 아직 도착하지 않은 응답, 옵션으로 넘기지 않은 prop, 한 겹 깊이를 잘못 짚은 data.user.name 같은 자리에서 나며, 배열이 비어 있을 때 arr[0].id도 여기로 옵니다. 값이 없을 수 있는 자리라면 user?.name으로 짧게 끊을 수 있지만, 반드시 있어야 하는 값이었다면 ?.는 오류를 undefined로 바꿔 다음 줄로 미루는 것일 뿐입니다 — 왜 undefined인지를 위에서 찾으세요. Chrome 78 이전에는 같은 오류가 Cannot read property 'name' of undefined로 적혔습니다.TypeError: items.map is not a function그 이름이 있기는 하지만 함수가 아니라는 뜻이고, 이름이 아예 없으면 문구가 undefined 쪽으로 나옵니다. 배열이라고 생각한 것이 실은 객체나 NodeList일 때, API가 배열 대신 {data: [...]}를 돌려줄 때, 또는 import한 모듈의 기본 내보내기를 잘못 짚었을 때 납니다. 무엇인지 먼저 찍어 보세요 — console.log(typeof items, items) 한 줄이 이 오류의 절반을 그 자리에서 끝냅니다. NodeList나 Set이면 Array.from(items)로 감싸면 되고, {data: [...]}였다면 감싸지 말고 items = res.data로 바로잡는 것이 맞습니다.RangeError: Maximum call stack size exceeded호출이 쌓이는 깊이가 엔진의 한도를 넘었다는 뜻이고, 대개 깊은 재귀가 아니라 끝나지 않는 재귀입니다. 멈추는 조건이 없거나 닿지 않는 함수, 서로를 부르는 두 함수, 자기 자신을 담고 있는 객체를 JSON.stringify로 넘기는 경우, React라면 렌더 중에 자기가 의존하는 상태를 바꾸는 경우가 원인입니다. 콘솔의 스택에서 되풀이되는 두세 프레임을 보면 고리가 바로 보이니, 거기서 멈추는 조건을 고치세요. 깊이가 정말 필요한 계산이라면 재귀를 반복문이나 명시적인 스택으로 바꾸는 것이 유일한 길입니다 — 브라우저의 스택 한도는 늘릴 수 없습니다.SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSONJSON.parse에 넘긴 것이 JSON이 아니라 HTML이었다는 뜻입니다. 문구에 남은 <!DOCTYPE 조각이 증거이고, 그것은 서버가 404나 502, 로그인 리다이렉트 페이지를 HTML로 돌려주었다는 뜻입니다 — 그러니 진짜 잘못은 파싱이 아니라 그 앞의 요청에 있습니다. 주소가 틀렸거나, 개발 서버의 프록시가 API 대신 index.html을 내주었거나, 인증이 만료되어 로그인 페이지로 넘어간 경우입니다. res.json()을 부르기 전에 res.ok를 보고, 아니면 res.text()로 실제로 무엇이 왔는지 읽어 보세요 — curl -s로 그 주소를 직접 쳐 보는 것이 가장 빠릅니다. Chrome 111과 Node 20 이전에는 같은 오류가 Unexpected token < in JSON at position 0으로 적혔습니다.SyntaxError: Unexpected end of JSON inputJSON을 읽다가 문서가 끝나 버렸다는 뜻이고, 거의 언제나 몸통이 아예 비어 있었던 것입니다. 204 No Content나 본문 없는 오류 응답에 res.json()을 부른 경우, 응답 본문을 이미 한 번 읽어 두 번째에는 빈 것이 온 경우, 또는 쓰다 말고 끊긴 파일을 읽은 경우입니다. 먼저 텍스트로 받아서 비었는지 보고 나서 파싱하면 정확한 진단이 됩니다 — const t = await res.text(); if (!t) return null;. JSON.parse(text || 'null')처럼 기본값으로 덮는 것은 빈 응답을 정상으로 만들어 버리니, 서버가 왜 빈 몸통을 보냈는지 먼저 확인하세요.TypeError: Failed to fetch요청이 응답을 받지 못하고 끝났다는 뜻이고, 브라우저가 이유를 일부러 감춘 문구입니다 — CORS로 막힌 것과 주소가 죽은 것과 인증서가 잘못된 것과 광고 차단 확장이 끊은 것이 모두 같은 다섯 글자로 나옵니다. fetch가 던지는 이 오류는 상태 코드와 상관이 없어서 404나 500은 여기까지 오지 않으므로, 서버는 아예 응답을 시작하지 못한 것입니다. 콘솔의 이 줄 위나 Network 탭에 실제 이유가 한 줄 더 있는 경우가 많으니 그것을 먼저 읽고, curl -i로 그 주소를 직접 쳐 보면 서버가 살아 있는지가 갈립니다. 파이어폭스에서는 같은 상황이 NetworkError when attempting to fetch resource로 나옵니다.Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.요청은 서버에 닿았고 응답도 왔지만, 그 응답에 이 출처를 허락하는 머리글이 없어 브라우저가 자바스크립트에게 넘기기를 거부했다는 뜻입니다. 브라우저만 이 규칙을 지키므로 같은 주소를 curl로 치면 잘 됩니다 — 그래서 서버가 멀쩡한데 브라우저에서만 막히는 것으로 보입니다. 고칠 곳은 언제나 서버이고, 응답에 Access-Control-Allow-Origin: http://localhost:3000을 붙이는 것입니다. 프런트엔드에서는 아무것도 할 수 없고, 남의 서버를 고칠 수 없다면 내 서버를 거쳐 부르는 프록시가 유일한 길입니다. Allow-Origin: *는 쿠키를 함께 보내는 요청에서는 통하지 않고, 그 경우에는 출처를 정확히 적고 Allow-Credentials까지 켜야 합니다.SyntaxError: Cannot use import statement outside a modulenode나 브라우저가 그 파일을 CommonJS 스크립트로 읽었는데 그 안에 ESM 문법인 import가 있었다는 뜻입니다. .js 파일은 package.json에 type 표시가 없으면 CommonJS로 읽히고, 브라우저라면 <script>에 type="module"이 없을 때 같은 일이 납니다. npm pkg set type=module로 그 패키지 전체를 ESM으로 선언하면 풀리지만, 그 순간부터 그 패키지의 모든 .js에서 require와 __dirname이 사라지므로 남아 있는 CommonJS 파일들을 함께 옮겨야 합니다 — 파일 하나만 옮기고 싶다면 확장자를 .mjs로 바꾸는 편이 좁고 안전합니다.ReferenceError: require is not defined in ES module scope, you can use import instead앞의 오류와 정확히 반대편입니다 — 이 파일은 ESM으로 읽히고 있는데 그 안에 CommonJS의 require가 있는 것입니다. package.json에 "type": "module"을 넣은 직후에 옛 스크립트가 그대로 남아 있을 때 거의 언제나 이렇게 됩니다. 그 파일 하나만 옛 방식으로 두고 싶으면 mv script.js script.cjs로 확장자를 바꾸는 것이 가장 좁은 수정이고, ESM으로 옮기려면 require를 import로 바꾸면서 __dirname과 require.main === module 같은 CommonJS 전용 값들도 함께 손봐야 합니다.Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/app/src/util' imported from /app/src/index.jsESM으로 실행할 때는 import 경로를 브라우저처럼 그대로 파일 이름으로 쓰기 때문에, './util'은 './util.js'가 아니라 없는 파일입니다. CommonJS에서는 node가 확장자를 붙여 보며 찾아 주었고 TypeScript로 쓴 코드는 컴파일 뒤에도 확장자 없는 import를 그대로 남기기 때문에, tsc로 빌드한 프로젝트를 node로 처음 돌릴 때 이 오류가 무더기로 납니다. 상대 경로 import에 .js 확장자를 붙이면 됩니다 — TypeScript 파일 안에서도 './util.js'라고 적는 것이 맞습니다(컴파일 결과가 .js이기 때문입니다). node_modules의 패키지 이름에는 확장자를 붙이지 않습니다.ReferenceError: window is not defined그 코드가 브라우저가 아니라 서버의 node 안에서 돌았다는 뜻입니다. node에는 window도 document도 localStorage도 없기 때문에, Next.js나 Nuxt처럼 먼저 서버에서 한 번 렌더하는 틀에서 모듈을 읽는 시점에 window를 만지면 여기서 멈춥니다 — 컴포넌트 바깥에 놓인 한 줄이나, 브라우저 전용 라이브러리의 import 자체가 원인인 경우가 많습니다. 브라우저에서만 할 일이라면 typeof window !== 'undefined'로 감싸거나, 더 낫게는 그 코드를 useEffect 안으로 옮기세요 — 효과는 브라우저에서만 돌기 때문입니다. 라이브러리 전체가 브라우저 전용이면 Next.js에서는 dynamic(() => import('./C'), { ssr: false })로 서버 렌더에서 아예 빼는 것이 답이고, 그 대신 그 부분은 서버가 만든 HTML에 담기지 않습니다.Hydration failed because the initial UI does not match what was rendered on the server서버가 만들어 보낸 HTML과 브라우저가 첫 렌더에서 만든 결과가 달라 React가 둘을 이어 붙이지 못했다는 뜻입니다. 렌더 안에서 new Date()나 Math.random()을 쓰거나 localStorage를 읽거나 window의 폭에 따라 다르게 그리면, 서버와 브라우저의 답이 다를 수밖에 없습니다 — <p> 안에 <div>를 넣은 것처럼 브라우저가 태그를 고쳐 버리는 경우도 같은 결과가 됩니다. 첫 렌더에서는 서버와 같은 것을 그리고, 달라지는 부분은 useEffect가 돈 뒤에 바꾸는 것이 정석입니다. 그 대가로 그 부분은 잠깐 늦게 나타나고, 서버가 만든 HTML에는 담기지 않습니다. React 19에서는 같은 상황이 "the server rendered HTML didn't match the client"로 적히고, 어느 쪽이 달랐는지 diff까지 보여 줍니다.Objects are not valid as a React child (found: object with keys {name, id})화면에 그리라고 넘긴 값이 문자열이나 숫자가 아니라 객체라는 뜻이고, 괄호 안의 열쇠 목록이 그 객체가 무엇인지 알려 줍니다. {user} 대신 {user.name}을 적어야 하는 자리이거나, 응답 전체를 그대로 그리려 한 경우입니다. 열쇠 목록 대신 found: [object Promise]가 보이면 원인이 다릅니다 — await를 빠뜨린 채 async 함수의 결과를 그리려 한 것입니다. 그릴 필드를 골라 적는 것이 답이고, 디버깅 중이라면 JSON.stringify(user)로 잠깐 볼 수 있지만 그것을 화면에 남기지는 마세요.Each child in a list should have a unique "key" prop.목록으로 그린 형제 요소들에 key가 없어, 다음 렌더에서 어느 것이 어느 것인지 React가 짝지을 수 없다는 뜻입니다. items.map(...)으로 요소를 만들면서 key를 빼먹은 것이고, 이것은 경고라 화면은 일단 그려지지만 목록이 바뀔 때 조용한 버그로 돌아옵니다 — 입력 칸의 값이나 애니메이션이 엉뚱한 줄에 남는 것이 그 증상입니다. 데이터에 있는 안정된 id를 key로 주세요. 배열의 인덱스를 key로 쓰는 것은 순서가 절대 바뀌지 않고 중간에 끼워 넣거나 지우지 않는 목록에서만 안전하고, 그렇지 않으면 key가 없는 것과 사실상 같은 문제를 냅니다. React 19부터는 앞머리에 붙던 Warning:이 사라졌습니다.Too many re-renders. React limits the number of renders to prevent an infinite loop.렌더가 상태를 바꾸고 그 상태가 다시 렌더를 부르는 고리에 빠졌고, React가 무한 반복을 막으려고 끊었다는 뜻입니다. 거의 언제나 함수를 넘겨야 할 자리에 함수를 호출해 둔 것입니다 — onClick={setOpen(true)}는 렌더할 때마다 즉시 실행되므로 onClick={() => setOpen(true)}여야 합니다. 다른 흔한 꼴은 렌더 본문에서 곧바로 상태를 바꾸는 것과, useEffect의 의존성 목록에 자기가 바꾸는 값을 넣는 것입니다. 상태를 바꾸는 일은 이벤트 처리기나 useEffect 안으로 옮기고, 렌더 중에 계산만 하면 되는 값이라면 상태로 둘 필요가 없는지 되돌아보세요.

Python18

파이썬의 오류는 Traceback의 마지막 한 줄에 무엇이 틀렸는지, 그 위의 프레임들에 어디서 틀렸는지가 나뉘어 적혀 있어서 마지막 줄만 읽으면 이름은 알고 자리는 놓치게 되고, 특히 NoneType과 KeyError처럼 값이 없어서 나는 오류는 터진 자리보다 그 값을 만들어 준 위쪽 프레임에 원인이 있습니다.

빌드·타입10

빌드가 내는 오류는 실행 전에 도구가 거절한 것이라 그 자리에서 프로그램을 망가뜨리지는 않지만 대신 두 가지를 물어봅니다 — 타입이나 경로를 실제 모양에 맞게 고칠 것인가, 아니면 as any나 인용 부호 하나로 그 줄만 통과시킬 것인가 — 그리고 대소문자와 확장자, 환경 변수처럼 내 컴퓨터에서만 맞는 것들은 여기서 처음 드러납니다.

error TS2307: Cannot find module 'lodash' or its corresponding type declarations.tsc가 그 모듈의 자리도, 그 모듈의 타입 선언도 찾지 못했다는 뜻이고, 문구가 둘을 함께 말하는 것이 중요합니다 — 패키지가 아예 없을 수도 있고, 패키지는 설치되어 있는데 타입만 없을 수도 있습니다. 설치는 했는데 이 말이 나오면 타입 쪽이니 npm i -D @types/lodash처럼 짝이 되는 타입 패키지를 넣으면 되고, 최근 패키지들은 타입을 안에 담고 있어 @types가 아예 없는 경우도 많습니다. 상대 경로 import에서 이 오류가 나면 대소문자와 tsconfig의 paths를 보세요 — 자기 파일을 가리키는 경로는 @types와 아무 상관이 없습니다.error TS2339: Property 'user' does not exist on type 'Request'.그 타입에 그 속성이 선언되어 있지 않다는 뜻입니다. 라이브러리 타입에 없는 필드를 얹으려 할 때(Express의 Request에 user를 붙이는 것이 대표적), 오타, 또는 좁혀지지 않은 유니온에서 한쪽에만 있는 속성을 읽을 때 납니다. 타입을 실제 모양에 맞게 고치는 것이 답이고, 유니온이면 'x' in y나 판별용 필드로 좁히면 그 안에서는 접근이 열립니다. as any로 지우는 것은 컴파일러의 입만 막는 것이라, 그 자리는 이제 잘못된 속성 이름도 통과시킵니다.error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.함수가 받기로 한 타입과 넘긴 값의 타입이 다르다는 뜻이고, 문구가 어느 쪽이 무엇인지 순서대로 적어 줍니다 — 앞이 넘긴 것, 뒤가 받기로 한 것입니다. 폼 입력값이나 URL의 조회 문자열, JSON에서 온 값이 문자열인 채로 숫자를 받는 자리에 들어갈 때가 가장 흔합니다. 경계에서 한 번 변환하는 것이 답이지만, Number(value)는 실패했을 때 예외 대신 NaN을 돌려주므로 그 NaN이 그대로 흘러가지 않게 검사해야 합니다 — Number.isFinite(n)이 그 자리입니다.error TS18048: 'user' is possibly 'undefined'.그 값이 undefined일 수도 있는데 그 가능성을 처리하지 않았다는 뜻이고, 이것은 tsc가 잡아 준 미래의 Cannot read properties of undefined입니다. 선택적 필드나 배열의 find() 결과, 없을 수 있는 환경 변수를 곧바로 이어 쓸 때 납니다. 없을 때 무엇을 할지 정하는 것이 답이니, 함수 앞머리에서 if (!user) return null로 끊거나 user?.name으로 짧게 넘기세요. 느낌표를 붙여 user!.name으로 지우는 것은 "내가 보증한다"는 선언이고, 그 보증이 틀리면 런타임에 예외로 돌아옵니다 — 검사와 달리 아무 안전망을 남기지 않습니다.error TS7006: Parameter 'req' implicitly has an 'any' type.매개변수에 타입이 적혀 있지 않고 tsc가 추론할 근거도 없어서 암묵적으로 any가 되었다는 뜻이고, noImplicitAny가 켜져 있으면 그것을 오류로 봅니다. 자바스크립트에서 옮겨 온 파일이나 콜백을 따로 떼어 변수에 담을 때 나며, 반대로 items.map(x => ...)처럼 문맥이 있는 자리에서는 tsc가 알아서 추론하므로 이 오류가 나지 않습니다. 그 자리에 타입을 적어 주는 것이 답이고, any를 명시적으로 적어 넘길 수도 있지만 그것은 검사를 그 매개변수에서 완전히 끄는 선택입니다 — 무엇인지 모를 때는 unknown이 더 정직하고, 쓰기 전에 좁히도록 강제합니다.Parsing error: Unexpected tokenESLint가 그 파일을 규칙에 걸어 보기도 전에, 문법을 읽는 단계에서 멈췄다는 뜻입니다. 코드가 정말 깨진 경우보다, 파서가 그 문법을 모르는 경우가 훨씬 많습니다 — TypeScript 파일을 기본 파서로 읽거나, JSX를 켜지 않았거나, 데코레이터나 아주 새로운 문법을 옛 파서로 읽을 때입니다. npx eslint --print-config app.ts를 그 파일에 대고 돌리면 어떤 parser와 어떤 parserOptions가 실제로 적용되는지 그대로 나오니, 짐작하지 말고 그것부터 보세요. TypeScript면 @typescript-eslint/parser가 필요하고, 그 파일이 아예 검사 대상이 아니어야 한다면 ignores에 넣는 것이 맞습니다.You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.webpack이 Module parse failed 뒤에 붙이는 줄로, 그 파일을 자바스크립트로 읽으려 했지만 자바스크립트가 아니었다는 뜻입니다. TypeScript나 JSX, CSS, 이미지, .vue처럼 변환이 필요한 파일을 module.rules에 규칙 없이 import했거나, node_modules에 있는 패키지가 컴파일되지 않은 소스를 내보내면서 그 폴더가 exclude에 걸려 있는 경우입니다. 그 확장자에 맞는 loader 규칙을 module.rules에 더하는 것이 답이고, 어느 파일에서 멈췄는지는 문구 위에 적힌 경로가 알려 줍니다. exclude: /node_modules/를 그냥 지워 해결하면 전체 빌드가 눈에 띄게 느려지므로, 그 패키지 하나만 예외로 두는 편이 낫습니다.Failed to resolve import "./utils" from "src/main.ts". Does the file exist?그 경로에서 파일을 찾지 못했다는 뜻이고, 함께 나오는 "Does the file exist?"가 실제로 확인해야 할 세 가지를 가리킵니다 — 이름의 대소문자, 확장자, 그리고 tsconfig나 vite.config의 별칭입니다. macOS와 윈도우의 파일시스템은 대소문자를 구별하지 않으므로 ./Utils라고 적어도 내 컴퓨터에서는 잘 돌아가고, 리눅스에서 도는 CI와 배포에서만 처음 깨집니다 — 이 오류가 "내 컴퓨터에서는 되는데"의 가장 흔한 정체입니다. git ls-files src | grep -i utils로 저장소에 실제로 어떤 철자로 들어가 있는지 확인하세요. 별칭(@/utils)이면 vite.config의 resolve.alias와 tsconfig의 paths를 둘 다 맞춰야 하고, 하나만 고치면 편집기는 조용한데 빌드만 깨집니다.You're importing a component that needs useState. This React hook only works in a client component.App Router에서는 모든 컴포넌트가 기본으로 서버 컴포넌트인데, useState처럼 브라우저에서만 뜻이 있는 훅을 쓰는 파일을 서버 컴포넌트가 import했다는 뜻입니다. 지시어는 파일 맨 위에 'use client' 한 줄이고, 그것을 붙이면 그 파일과 그것이 import하는 모든 것이 클라이언트 묶음으로 들어갑니다 — 그래서 페이지 전체 대신 상태가 필요한 가장 작은 조각에만 붙이는 것이 값이 싼 선택입니다. 반대 방향으로, 클라이언트 컴포넌트가 자식으로 서버 컴포넌트를 받는 구조로 나누면 데이터 가져오기는 서버에 남겨 둘 수 있습니다. Next.js 13에서는 같은 상황이 "It only works in a Client Component but none of its parents are marked with \"use client\""로 적혔습니다.The engine "node" is incompatible with this module. Expected version ">=20"설치하려는 패키지가 package.json의 engines에 필요한 node 판을 적어 두었고, 지금 쓰는 판이 그 범위 밖이라는 뜻입니다. 뒤에 붙는 Expected와 Got이 요구 범위와 내 판을 나란히 보여 주니 그 둘만 보면 됩니다 — CI에서만 이 오류가 난다면 그곳의 node 판이 내 컴퓨터와 다른 것입니다. nvm install 20 && nvm use 20처럼 node를 올리는 것이 정면의 답이고, .nvmrc나 CI 설정에도 같은 판을 적어 두어야 다음에 또 갈라지지 않습니다. yarn의 --ignore-engines로 넘길 수는 있지만 그것은 경고를 지우는 것일 뿐 호환성을 만들어 주지 않아, 그 패키지가 새 문법을 쓰면 실행 중에 문법 오류로 터집니다. npm은 같은 상황을 EBADENGINE 경고로 알리고 기본적으로는 설치를 막지 않습니다.

Docker12

docker의 오류는 어느 층에서 났는지를 먼저 갈라야 읽히는데 — 클라이언트가 데몬에 닿지 못한 것, 레지스트리가 거절한 것, 빌드 중에 RUN이 실패한 것, 컨테이너가 뜨자마자 죽은 것이 서로 다른 문제입니다 — 특히 빌드와 실행 단계의 오류는 문구 자체가 이유가 아니라 그 안에서 돌던 명령이 남긴 출력에 이유가 있고, 고치는 명령의 값도 층마다 다릅니다.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?docker 명령은 자기가 아무것도 하지 않고 데몬에게 부탁하는 클라이언트인데, 그 소켓에 아무도 응답하지 않았다는 뜻입니다. 데몬이 꺼져 있거나, macOS·윈도우에서 Docker Desktop이 아직 뜨지 않았거나, 리눅스에서 내 사용자가 docker 그룹에 없어 소켓을 열 권한이 없는 경우입니다 — 셋 다 같은 한 줄로 나옵니다. 리눅스면 sudo systemctl start docker로 띄우고, Desktop이면 앱을 먼저 켜세요. 권한 쪽이면 sudo usermod -aG docker $USER 뒤에 다시 로그인해야 하며, 그 그룹은 사실상 root와 같은 힘을 줍니다.Bind for 0.0.0.0:8080 failed: port is already allocated-p로 호스트의 그 포트를 잡으려 했지만 이미 다른 컨테이너나 프로세스가 쓰고 있다는 뜻입니다. 앞서 띄운 컨테이너를 --rm 없이 돌려서 멈춘 채로 남아 있거나, compose가 옛 컨테이너를 아직 붙잡고 있는 경우가 대부분입니다. docker ps --filter publish=8080이 그 포트를 게시한 컨테이너를 바로 짚어 주고, 컨테이너가 아니라 호스트의 다른 프로그램이라면 lsof -i :8080으로 찾습니다. 급하면 -p 8081:80처럼 호스트 쪽 번호만 바꿔도 되지만, 남아 있는 옛 컨테이너를 정리하지 않으면 같은 일이 다음에도 납니다.Conflict. The container name "/api" is already in use by container--name으로 준 이름을 이미 다른 컨테이너가 쓰고 있다는 뜻입니다. 이름은 돌고 있는 컨테이너뿐 아니라 멈춘 컨테이너까지 통틀어 하나뿐이라, 어제 죽은 컨테이너가 그 이름을 계속 붙잡고 있는 경우가 대부분입니다 — docker ps에는 안 보이고 docker ps -a에만 보입니다. docker rm -f api로 그 컨테이너를 지우면 이름이 풀리지만, 그 컨테이너에만 있던 쓰기 계층은 함께 사라집니다(이름 붙은 볼륨은 남습니다). 한 번만 쓰고 버릴 컨테이너라면 처음부터 docker run --rm으로 띄우면 이 일이 생기지 않습니다.failed to register layer: Error processing tar file(exit status 1): no space left on device이미지 계층을 풀어 놓을 자리가 디스크에 없다는 뜻입니다. 대개는 프로젝트가 큰 것이 아니라 도커가 몇 달치 옛 이미지와 빌드 캐시, 그리고 지운 컨테이너의 볼륨을 계속 들고 있는 것입니다. docker system df가 이미지·컨테이너·볼륨·빌드 캐시별로 얼마씩 쓰고 무엇이 회수 가능한지 먼저 보여 주니 그것부터 읽으세요. docker system prune은 멈춘 컨테이너와 떠 있는 이미지, 안 쓰는 네트워크와 빌드 캐시를 지우는데 캐시가 사라진 다음 빌드는 눈에 띄게 느려지고, --volumes를 붙이면 컨테이너에 붙어 있지 않은 볼륨까지 지웁니다 — 사람들이 데이터베이스를 잃는 자리가 정확히 여기입니다.pull access denied for myapp, repository does not exist or may require 'docker login'레지스트리가 그 저장소를 보여 주지 않았다는 뜻이고, 문구가 두 가지 원인을 한꺼번에 말하는 것이 핵심입니다 — 없는 이름이거나, 있지만 내게 권한이 없는 것입니다. 비공개 저장소에 로그인하지 않았거나, 이름에 사용자·조직을 빼먹었거나(myapp과 myorg/myapp은 다른 저장소입니다), 존재하지 않는 이름을 적은 경우입니다. 비공개라면 docker login으로 그 레지스트리에 로그인하고, 공개 이미지인데도 이 말이 나오면 이름의 철자를 다시 보세요. 레지스트리는 없는 것과 못 보는 것을 일부러 구별해 알려 주지 않습니다 — 이름의 존재 여부가 정보가 되기 때문입니다.manifest for myapp:v2 not found: manifest unknown저장소는 찾았지만 그 태그가 그 안에 없다는 뜻입니다. 앞의 pull access denied와 달리 이쪽은 이름은 맞았다는 신호이니, 이제 볼 것은 태그뿐입니다 — 지우거나 옮긴 태그, latest만 올려 두고 v2를 만들지 않은 파이프라인, 또는 그 태그가 내 아키텍처용 이미지를 갖고 있지 않은 경우입니다. docker manifest inspect myapp:v2로 그 태그가 실제로 풀리는지, 어느 platform이 들어 있는지 확인할 수 있습니다. latest로 바꿔 넘어가는 것은 재현이 안 되는 빌드를 만드는 값을 치르니, 태그를 고치는 편이 낫습니다.unauthorized: incorrect username or password레지스트리가 보낸 자격 증명을 거절했다는 뜻입니다. 비밀번호를 틀린 경우보다, 요즘은 계정 비밀번호로는 로그인할 수 없게 된 레지스트리에 비밀번호를 넣은 경우가 많습니다 — Docker Hub는 2단계 인증을 켜면 액세스 토큰만 받고, GitHub·GitLab의 레지스트리는 처음부터 토큰이나 배포 키만 받습니다. docker logout으로 저장된 자격 증명을 지우고 토큰으로 다시 docker login하세요. echo $TOKEN | docker login -u user --password-stdin으로 넣으면 토큰이 셸 기록에 남지 않습니다.failed to solve: process "/bin/sh -c npm ci" did not complete successfully: exit code: 1Dockerfile의 그 RUN 줄이 0이 아닌 코드로 끝났다는 뜻입니다. 여기에 적힌 것은 실패한 명령과 종료 코드뿐이고 진짜 이유는 그 위에 흐른 그 명령의 출력에 있는데, BuildKit이 성공한 단계를 접어 두기 때문에 잘 보이지 않습니다. docker build --progress=plain으로 다시 돌리면 모든 단계의 출력이 그대로 펼쳐지고, 캐시된 단계가 옛 오류를 감추고 있다면 --no-cache까지 붙이세요 — 대신 처음부터 다시 빌드하므로 시간이 많이 듭니다. exit code: 1은 이유가 아니라 그 명령이 실패했다는 사실일 뿐입니다.COPY failed: file not found in build context or excluded by .dockerignoreCOPY는 빌드 컨텍스트 안의 것만 가져올 수 있는데 그 자리에 그 파일이 없다는 뜻입니다. docker build 뒤의 마지막 인자가 컨텍스트이므로, 상위 폴더의 파일을 ../x로 가리키거나 .dockerignore가 그 파일을 걸러 낸 경우가 대부분입니다 — node_modules나 *.env를 걸러 두고 정작 그 안의 파일을 COPY하려 할 때 그렇습니다. 문구가 두 원인을 함께 말하니 cat .dockerignore를 먼저 읽고, 경로는 컨텍스트의 뿌리를 기준으로 다시 적으세요. 컨텍스트를 넓혀 해결하려 하면 그 폴더 전체가 데몬으로 전송되어 빌드가 느려집니다.exec /usr/local/bin/entrypoint.sh: exec format error커널이 그 실행 파일의 헤더를 알아보지 못했다는 뜻이고, 요즘은 거의 언제나 아키텍처가 어긋난 것입니다 — Apple Silicon에서 만든 arm64 이미지를 amd64 서버에서 돌리거나 그 반대입니다. 셸 스크립트라면 첫 줄의 #!/bin/sh가 빠졌을 때도 같은 문구가 나옵니다. docker build --platform=linux/amd64로 굽는 것이 흔한 대처지만, 그것은 어긋남을 없애는 것이 아니라 에뮬레이션으로 덮는 것입니다 — QEMU를 거치는 빌드와 실행은 원래 아키텍처보다 몇 배 느려집니다. 오래 쓸 이미지라면 buildx로 두 아키텍처를 함께 굽는 것이 값을 치르지 않는 길입니다.standard_init_linux.go: exec user process caused: no such file or directory컨테이너의 진입점을 실행하려 했지만 커널이 "그런 파일이 없다"고 답했다는 뜻이고, 파일은 분명히 그 자리에 있는데도 이 말이 나오는 것이 함정입니다. 스크립트의 줄 끝이 CRLF라서 첫 줄이 #!/bin/sh\r로 읽히고, 커널은 이름이 sh\r인 실행 파일을 찾다가 실패하는 것입니다 — 윈도우에서 클론했거나 git의 autocrlf가 켜져 있으면 이렇게 됩니다. dos2unix entrypoint.sh로 그 파일만 되돌릴 수 있고(없으면 sed -i 's/\r$//' entrypoint.sh), 다시 나지 않게 하려면 저장소에 .gitattributes를 두고 *.sh text eol=lf를 적으세요. alpine 이미지에 없는 인터프리터를 #!에 적었을 때도 같은 문구가 납니다.OCI runtime create failed: exec: "bash": executable file not found in $PATH: unknown컨테이너는 만들어졌지만 그 안에서 실행할 프로그램을 $PATH에서 찾지 못했다는 뜻입니다. alpine 계열 이미지에는 bash가 없고 sh만 있어, docker run -it myapp bash나 CMD ["bash", ...]가 정확히 이 오류로 끝납니다 — 도구가 컨테이너 안에 있다고 생각한 것이 실은 호스트에만 있는 경우도 같습니다. docker run --rm -it myapp sh로 먼저 들어가 보면 그 이미지에 무엇이 있는지 바로 알 수 있습니다. 굳이 bash가 필요하면 Dockerfile에 RUN apk add --no-cache bash를 넣으면 되지만, 이미지가 커지는 값을 치릅니다.

오류 문구를 읽는 법

첫 줄부터 읽습니다. 아래로 갈수록 도구 내부 이야기이고, 정작 원인은 맨 위에 적혀 있습니다.
파일 이름과 줄 번호가 있으면 거기가 시작점입니다 — 스택의 가장 위가 아니라, 내가 쓴 파일이 나오는 가장 위 줄입니다.
문구를 그대로 검색합니다. 다만 내 경로와 변수 이름은 지웁니다 — 그 부분이 검색을 방해합니다.
같은 문구가 도구 판마다 다르게 나옵니다. 검색 결과가 안 맞으면 판 번호를 함께 넣어 봅니다.
고치는 명령을 붙여 넣기 전에 그 명령이 무엇을 버리는지 확인합니다. 되돌릴 수 없는 것이 섞여 있습니다.

자주 묻는 질문

Q. 오류 문구를 번역하지 않는 이유가 무엇인가요?

검색할 것이기 때문입니다. 도구는 영어로 출력하고, 번역한 문구로는 아무것도 찾을 수 없습니다. 언어를 따르는 것은 그 뜻과 대처뿐입니다.

Q. 문구가 제 화면과 조금 다릅니다.

도구 판마다 표현이 바뀝니다. 경로와 변수 이름을 지운 뒤 남는 뼈대가 같으면 같은 오류입니다. 판이 다르면 검색에 판 번호를 함께 넣어 봅니다.

Q. 고치는 명령을 그대로 실행해도 되나요?

무엇을 버리는지 먼저 봅니다. git reset --hard와 강제 푸시, docker system prune은 되돌릴 수 없는 것을 지웁니다 — 그런 자리는 설명에 적어 두었습니다.

Q. 여기 없는 오류는 어떻게 찾나요?

문구에서 제 경로·이름·숫자를 지우고 남는 부분만 검색합니다. 그 뼈대가 도구가 정해 둔 문장이고, 그것으로 찾으면 결과가 맞습니다.