이미지 업로드가 실패한 줄 알고 한참을 헤맸는데, 사실은 성공한 뒤였습니다. 업로드가 끝나면 뜨는 설정 창이 화면을 가리고 있었고, 저는 그걸 실패로 읽었습니다. 그 과정을 그대로 적습니다.
무슨 일이 있었나
블로그에 이미지 아홉 장을 자동으로 올리는 작업이었습니다. 파일을 넘기고 기다린 뒤, 올라간 이미지 주소를 읽어 오는 순서였습니다.
그런데 주소가 안 나왔습니다. 대신 다른 글에 쓰인 이미지 주소들만 잔뜩 나왔습니다. 목록에서 예전 이미지를 긁어 온 것이었습니다.
“업로드가 안 됐구나”라고 판단했습니다. 이 판단이 틀렸습니다.
같은 곳에서 계속 막혔다
다시 시도했더니 이번엔 “이미지 삽입” 버튼을 못 찾겠다는 오류가 났습니다. 조금 전까지 잘 눌리던 버튼입니다.
여기서 저는 화면이 아직 안 그려졌다고 봤습니다. 그래서 기다리는 시간을 늘리고, 여러 번 다시 찾도록 고쳤습니다. 여전히 못 찾았습니다.
같은 방향으로 세 번쯤 더 시도했습니다.
화면을 그냥 봤더니
결국 화면 전체를 읽어 봤습니다. 거기 “레이아웃 선택”이라는 창이 열려 있었습니다. 크기와 정렬을 고르는 창이었습니다.
이 창은 업로드가 끝나야 뜹니다. 즉 이게 떠 있다는 건 아홉 장이 이미 다 올라갔다는 뜻이었습니다. 그리고 이 창이 화면 위를 덮고 있어서 아래 도구 모음이 안 잡혔던 겁니다.
실패의 증거로 읽은 것이 성공의 증거였습니다.
내가 놓친 것
첫 판단을 검증하지 않고 그 위에 계속 쌓았습니다. “업로드 실패”라고 정해 두고, 이후의 모든 이상 신호를 그 틀에 맞춰 해석했습니다. 버튼을 못 찾는 것도 “화면이 덜 그려져서”로 읽었습니다.
화면을 안 봤습니다. 특정 요소를 찾는 것만 반복했고, 전체가 어떤 상태인지는 확인하지 않았습니다. 한 번 통째로 봤으면 바로 끝났을 일입니다.
규칙으로 바꿔 뒀다
- 같은 방식으로 두 번 실패하면 방식을 바꾼다. 세 번째부터는 시간 낭비였습니다.
- 요소를 못 찾으면 먼저 전체 상태를 본다. 덮고 있는 창이 있는지부터 확인합니다.
- 실패했다고 단정하기 전에 성공했을 가능성을 본다. 성공 다음 화면을 실패로 착각할 수 있습니다.
덧붙임
이 내용을 작업 메모에 적어 뒀습니다. 같은 함정에 다시 빠지지 않으려면 기억이 아니라 기록이 필요합니다. 이번에도 예전에 비슷한 걸 겪었을 텐데 기억나지 않았습니다.
공식 안내로 보는 이미지 삽입과 겹쳐 뜨는 창
Blogger 도움말에 따르면 글 편집 화면 위쪽의 이미지 삽입 버튼을 눌러 올릴 곳을 고르고, 이미지를 하나 이상 선택해 삽입하면 됩니다. 삽입한 뒤에는 이미지를 눌러 크기와 캡션, 정렬을 바꿀 수 있다고 안내합니다. 이 도움말은 삽입 뒤에 크기와 정렬을 고르는 단계가 있다는 데까지만 알려 줄 뿐, 이 글에서 만난 ‘레이아웃 선택’이라는 창 이름은 나오지 않습니다.
도움말은 올린 이미지가 웹용으로 압축·최적화될 수 있고, 이 이미지는 구글 저장 용량에 포함되지 않으며, 큰 이미지를 원본 화질로 보관하는 방법은 현재 없다고 설명합니다. 올린 이미지는 미디어 관리자(blogger.com/mediamanager)에서 관리하고 지울 수 있다고도 합니다. 그러니 업로드가 정말 실패했는지 의심될 때는 편집기 화면만 보지 말고 이런 별도 관리 화면에서 올라간 이미지를 확인해 볼 수 있습니다.
겹쳐 뜬 창이 뒤쪽 화면을 막는 것은 웹 접근성 지침에서도 정해진 동작입니다. W3C의 WAI-ARIA 작성 지침은 모달 대화상자를 다른 창 위에 겹쳐 띄우는 창으로 설명하고, 그 아래에 있는 창은 비활성(inert) 상태라서 사용자가 대화상자 바깥 내용과 상호작용할 수 없다고 밝힙니다. 대화상자가 열리면 초점이 그 안으로 옮겨 가고, Escape 키로 닫을 수 있으며, 닫히면 대개 창을 연 요소로 초점이 돌아옵니다. 그래서 자동화 도구가 뒤쪽의 도구 모음 버튼을 못 찾는 것은 오류라기보다 설계된 동작일 수 있습니다.
| 보인 현상 | 공식 문서가 설명하는 것 | 먼저 해 볼 일 |
|---|---|---|
| 뒤쪽 버튼이 눌리지 않음 | 모달 대화상자가 열려 있으면 그 아래 창은 비활성입니다(W3C). | 겹쳐 뜬 창이 있는지 화면 전체를 먼저 봅니다. |
| 삽입한 이미지의 모양이 바뀜 | 삽입한 뒤 크기·캡션·정렬을 바꿀 수 있습니다(Blogger 도움말). | 설정 창이 떠 있다면 선택을 마치고 닫습니다. |
| 올라갔는지 불확실함 | 미디어 관리자에서 올린 이미지를 관리할 수 있습니다(Blogger 도움말). | 미디어 관리자에서 목록을 확인합니다. |
성공 다음 화면에서 기록을 늘려 본 기준
완료 메시지 하나로 끝내지 않고 다음 화면에서 결과를 확인합니다. 그래서 이 기록도 결과만 적어 두지 않고, 다음에 같은 선택을 해야 할 사람이 확인할 순서를 남기는 쪽으로 보강했습니다. 작업마다 조건은 달라도, 무엇을 성공으로 볼지와 어디에서 멈출지를 먼저 정하면 판단이 훨씬 짧아집니다.
특히 화면에 보이는 한 장면만으로 원인을 단정하지 않았습니다. 입력, 실행 중 상태, 최종 결과는 서로 다른 사실입니다. 앞 단계가 정상이어도 다음 단계에서 달라질 수 있으므로, 확인한 사실과 아직 확인하지 못한 범위를 구분해 적는 습관이 필요했습니다.
| 확인 대상 | 기록할 질문 |
|---|---|
| 시작 전 | 무엇을 바꾸며, 원래 상태는 되돌릴 수 있는가 |
| 실행 중 | 어느 조건에서 멈추거나 다른 흐름으로 넘어가는가 |
| 완료 뒤 | 사용자가 실제로 보는 결과까지 확인했는가 |
결과를 바로 믿지 않기 위해
작업이 끝났다는 표시에는 여러 뜻이 섞일 수 있습니다. 저장이 끝난 것일 수도 있고, 화면이 바뀐 것일 수도 있으며, 실제 산출물이 원하는 형식으로 준비됐다는 뜻은 아닐 수도 있습니다. 그래서 확인은 한 번의 표시가 아니라 앞뒤가 이어지는지 보는 과정으로 두었습니다.
- 입력 확인 — 대상과 조건이 의도한 것인지 다시 봅니다.
- 중간 확인 — 진행 표시만 보고 정상이라고 결론 내리지 않습니다.
- 출력 확인 — 파일·화면·표시 중 이 글의 목적에 맞는 결과를 직접 봅니다.
- 경계 확인 — 실패하거나 미확인인 경우를 성공 사례와 섞지 않습니다.
이 순서는 느려 보이지만, 나중에 원인을 찾는 시간을 줄입니다. 재현이 안 되는 문제는 대개 “잘 안 됐다”라는 한 줄만 남았을 때 커집니다. 반대로 어느 단계까지는 맞았는지가 남아 있으면, 다음 시도는 처음부터 다시 하지 않아도 됩니다.
다음 작업에서 같은 판단을 쓰는 방법
이 글의 상황을 모든 작업에 그대로 적용할 수는 없습니다. 다만 판단의 뼈대는 옮길 수 있습니다. 바꾸려는 대상, 실패로 볼 신호, 끝난 뒤 확인할 화면을 각각 한 문장으로 적으면, 도구나 환경이 바뀌어도 확인 순서는 유지됩니다.
| 상황 | 바로 하기 쉬운 판단 | 남겨야 할 판단 |
|---|---|---|
| 한 번 통과함 | 항상 해결됐다고 봄 | 통과한 조건과 확인 범위를 함께 적음 |
| 오류가 남 | 원인을 하나로 단정함 | 입력·실행·결과 중 어느 단계인지 나눔 |
| 수정을 시작함 | 현재 상태를 덮어씀 | 되돌릴 기준과 비교 지점을 남김 |
이 기준은 화려한 방법론이 아니라, 같은 일을 두 번 겪지 않기 위한 메모 방식입니다. 다음 사람이 아니라 다음의 나 자신이 읽어도 이해할 수 있게, 관찰한 사실과 선택한 이유를 붙여 두는 것이 핵심입니다.
마무리할 때 확인한 항목
완료 보고를 짧게 하더라도 아래 항목은 남겨 두는 편이 좋았습니다. 숫자나 성능처럼 조건에 따라 바뀌는 값은 이번 기록에서 확인된 범위를 넘겨 일반화하지 않았습니다. 확인하지 못한 부분은 빈칸으로 두는 편이 그럴듯한 설명을 덧붙이는 것보다 낫습니다.
- 바꾼 것 — 무엇을 왜 바꿨는지 한 문장으로 설명할 수 있는가
- 확인한 것 — 실제로 본 결과와 확인 방법이 구분되어 있는가
- 남은 것 — 아직 검증하지 않은 조건을 성공으로 포장하지 않았는가
- 다음 행동 — 같은 문제가 나면 어디부터 다시 볼지 정했는가
이 글의 사건은 여기서 끝나지만, 판단 기준은 다음 작업으로 이어집니다. 작은 작업일수록 기록을 생략하기 쉽습니다. 그러나 작은 기준 하나가 쌓이면, 나중에는 문제를 더 빨리 설명하고 더 조심스럽게 고칠 수 있습니다.
기록을 다시 읽을 때의 질문
작업 기록은 그날의 메모로 끝나지 않습니다. 시간이 지난 뒤 다시 읽으면, 당시에는 당연했던 전제가 빠져 있는 경우가 많습니다. 그래서 결과 문장만 남기기보다 “어떤 조건에서 이 판단을 했는가”를 함께 적었습니다. 이 한 줄이 없으면 같은 결과를 다른 조건에 무리하게 적용하기 쉽습니다.
예를 들어 어떤 흐름이 한 번 끝까지 진행됐다는 사실은 중요합니다. 하지만 그 사실만으로 모든 입력, 모든 기기, 모든 상황에서 같은 일이 일어난다고 말할 수는 없습니다. 이 글에서도 확인한 범위는 사실로 두고, 범위를 벗어나는 부분은 다음 확인 과제로 남기는 쪽을 택했습니다.
| 다시 읽는 시점 | 확인할 내용 |
|---|---|
| 수정 전 | 원래 문제를 한 문장으로 다시 설명할 수 있는가 |
| 수정 중 | 처방이 원인과 직접 이어지는가 |
| 수정 후 | 처음 정한 성공 기준을 같은 방식으로 확인했는가 |
이 질문은 일을 더 크게 만들기 위한 절차가 아닙니다. 막연한 “잘 됨”과 설명 가능한 “여기까지 확인함”을 가르는 작은 장치입니다. 다음에 비슷한 문제가 생기면 이전 기록을 복사하는 대신, 조건이 같은지부터 대조할 수 있게 됩니다.
재발을 줄이는 작은 규칙
문제가 다시 생기지 않게 하는 가장 현실적인 방법은 복잡한 약속보다 확인 지점을 고정하는 것입니다. 시작 전에는 원래 상태를 남기고, 실행 뒤에는 결과를 직접 보고, 애매한 부분은 애매하다고 표시합니다. 이 세 가지는 도구가 바뀌어도 계속 쓸 수 있습니다.
- 비교 기준 — 바꾸기 전과 뒤를 같은 항목으로 확인합니다.
- 중단 기준 — 예상과 다른 신호가 보이면 다음 단계로 넘기지 않습니다.
- 설명 기준 — 확인한 사실과 추정한 이유를 한 문장에 섞지 않습니다.
이 글의 결론도 같습니다. 완성도는 길게 쓴 말이 아니라, 왜 그렇게 판단했는지 독자가 따라갈 수 있는지에서 나옵니다. 다음 작업에서 이 기준 중 하나라도 다시 쓰일 수 있다면, 이번 기록은 충분히 역할을 한 셈입니다.
확인 자료
- Blogger 도움말: 블로그에 이미지와 동영상 추가하기 (확인: 2026-10-18)
- W3C WAI-ARIA 작성 지침: 모달 대화상자 패턴 (확인: 2026-10-18)