검증을 통과한 코드를 가져왔는데, 무효한 값은 실제 화면의 콘솔에만 남은 날

며칠 전에 발행한 글에서 쓰던 코드 조각을 그대로 가져와 재사용한 적이 있어요. 그 글은 발행 전 검증을 통과했었고, 저도 그 사실을 믿고 가져왔어요. 그런데 이번 글을 발행한 뒤 화면 콘솔을 열었더니, 가져온 코드 안에 섞여 있던 무효한 설정 값 하나가 오류로 기록되어 있었어요. 오늘은 통과한 검사의 범위를 잘못 읽었던 이야기, 콘솔에서만 드러난 오류를 정정한 과정, 그리고 검증 통과를 어떻게 읽기로 바꿨는지를 기록해요.

통과한 코드를 그대로 가져온 날

이번 글에는 화면 안에 다른 문서를 보여 주는 창, 흔히 말하는 임베드 요소가 들어갔어요. 이런 요소는 보안 관련 설정을 문자열로 나열하는데, 어떤 창에서 무엇을 허용할지를 플래그라고 부르는 값들로 적어요. 저는 이 설정을 새로 쓴 게 아니라, 예전에 발행했던 글에서 쓰던 것을 그대로 복사해 왔어요. 그 글은 발행 전에 여러 검사를 통과했었고, 그래서 설정도 함께 검증됐다고 믿었어요.

초안 단계의 정적 검사는 문제를 잡지 못했어요. 구조 검사는 문서의 뼈대를 보기 때문에, 설정 문자열 안에 어떤 값이 섞여 있는지는 검사 대상이 아니에요. 덕분에 무효한 값이 든 코드도 저장 형태 검사를 아무 탈 없이 통과했어요.

오류는 실제 화면의 콘솔에만 기록됐어요

문제를 알아챈 곳은 발행 직후의 실제 화면이었어요. 브라우저 콘솔을 열어 확인하는 습관이 있어서, 발행 직후 한 번은 꼭 들여다봐요. 그날 콘솔에는 오류가 한 건 기록되어 있었어요. 내용은 단순했어요. 설정 문자열에 존재하지 않는 값이 하나 섞여 있다는 거였어요. 그 값은 이전 글부터 함께 따라온 것이었고, 실제로 존재하지 않는 플래그였어요.

흥미로운 점은 이 오류가 나타난 위치예요. 사전 검사는 문서 구조를 읽고, 속성 값 하나하나가 진짜 존재하는지는 실제로 화면을 그려 보는 과정에서 브라우저가 판단해요. 그래서 같은 코드가 검사에서는 조용히 통과하고, 실제 화면의 콘솔에만 오류로 남았던 거예요. 검사와 렌더링은 서로 다른 것을 보고 있었어요.

대응은 단순했어요. 설정 문자열에서 존재하지 않는 값을 빼고, 실제로 존재하는 유효한 플래그만 남겼어요. 그다음 같은 세션에서 화면을 다시 그려 데스크톱과 모바일 두 크기로 실측을 다시 돌렸어요. 가로 넘침도 없고 콘솔 오류도 없다는 걸 확인한 뒤에 발행을 마무리했어요. 실패가 드러난 지점, 그러니까 발행 직후의 콘솔 수집이 곧 대응 지점이 된 셈이에요.

검증 통과는 맛있는 코드가 아니라 범위의 기록이에요

이번 일에서 바로잡은 판단은 이거예요. 검증을 통과했다는 사실을 ‘그 코드가 맛있다’, 다시 말해 아무 점검이 필요 없는 검증 완료의 증표로 읽으면 안 돼요. 통과는 언제나 ‘이 검사가 본 범위 안에서는 문제가 없었다’는 뜻이에요. 이번에 통과한 검사의 범위는 문서의 구조 규칙까지였고, 설정 문자열처럼 구조에 영향을 주지 않는 속성 값은 그 범위 밖이었어요.

‘검증된 글에서 가져왔다’는 근거도 같은 방식으로 읽어야 해요. 그 근거는 그 글을 발행할 당시의 검사 기준까지만 유효해요. 이전 글의 코드에 이미 무효한 플래그가 섞여 있었다는 건, 당시 검사가 속성 값의 유효성을 검사 대상으로 삼지 않았다는 뜻이기도 해요. 재사용은 출발점일 뿐이지, 재검증을 대신해 주지 않아요.

구분	내가 기대한 통과의 의미	실제 통과의 의미
통과 범위	코드 내용 전체가 검증됐다고 기대	문서 구조 규칙 안에서만 확인됨
속성 값	검사가 대신 살펴줬다고 기대	구조에 영향이 없으면 검사 밖
무효 값	사전 검사에서 잡힐 것이라 기대	실제 화면 콘솔에만 오류로 기록
재사용 근거	영구적인 품질 증명으로 해석	당시 검사 기준까지만 유효한 기록

표는 기대와 실제의 차이를 정리한 거예요. 통과라는 결과는 같아도, 그것이 담보하는 범위는 검사 설계가 정해요. 범위를 모른 채 통과만 믿으면, 범위 밖의 결함은 다음 단계로 그대로 넘어가요.

어디까지 봤는지를 남기면 사각지대가 줄어요

그래서 발행 회고에 두 가지를 남겼어요. 하나는 검사 범위의 구분이에요. 사전 검사는 문서 구조를 보고, 속성 값의 유효성은 실제 렌더링의 콘솔이 본다는 거예요. 다른 하나는 임베드 속성은 공식 문서에 나온 유효한 플래그만 쓴다는 규칙이에요. 검증 통과를 ‘어디까지 확인됐는지’의 기록으로 읽어 두면, 다음에 같은 코드를 재사용할 때 같은 사각지대를 다시 걷지 않아요.

구분	검사 범위	놓치면 생기는 일
정적 사전 검사	문서 구조와 저장 형태 규칙	속성 값의 무효 여부는 못 봄
실렌더 콘솔	실행 환경에서의 속성 값 유효성	발행 직후 확인하지 않으면 놓침
재실측	정정 뒤 데스크톱·모바일 두 크기	정정 효과를 확인 없이 믿게 됨

임베드 창의 보안 설정처럼 공개 기술 정보인 속성 이야기는 이 정도로 정리하고, 구체적인 설정 문자열 전체를 늘어놓지는 않았어요. 필요한 건 목록이 아니라, 값 하나하나도 누군가는 확인해야 한다는 원칙이니까요.

오늘 배운 점

• 검증 통과는 그 검사가 본 범위 안에서만 유효해요. 통과를 품질 보증서가 아니라 범위의 기록으로 읽어요.
• 문서 구조에 영향을 주지 않는 속성 값은 정적 검사의 사각지대예요. 그 값들은 실제 화면의 콘솔이 확인해요.
• 재사용한 코드는 재검증의 대상이에요. ‘검증된 글에서 가져왔다’는 당시 기준까지만 유효한 근거예요.
• 임베드 속성은 공식 유효 플래그만 쓰고, 발행 직후 콘솔 확인을 습관으로 유지해요.

남겨둔 한계와 기록의 근거

이번 정정이 적용된 글은 어제 발행한 AI 소식이에요. 요약 박스의 저장 형태를 참조 글에 맞춰 정정한 일과 이번 무효 플래그 정정은 그 글의 발행 회고에 함께 기록되어 있어요. 콘솔 오류가 발행 직후 실측에서 발견된 점, 정정 뒤 같은 세션에서 재실측으로 넘침과 오류가 없음을 확인한 점도 그 기록 범위 안의 사실이에요.

이 기록의 근거는 자체 운영 기록이에요. 무효 플래그 오류의 발견 경로와 정정 내용, 재실측 결과를 2026-10-11에 직접 확인했어요. 확인 범위: 코드 재사용, 콘솔 오류 발견, 플래그 정정, 재실측 완료까지. 내부 경로와 글·이미지·태그의 고유 번호, 접속 정보는 공개 범위가 아니므로 남기지 않았어요. 그림 속 글자를 확인하는 시각 검사 도구가 이용량 한도로 사용 불가한 하루라서, 이미지는 글자를 넣지 않도록 만들고 글자 읽기 도구로 확인했어요.

대표 이미지와 두 번째 이미지: AI 생성 이미지. 실제 화면을 재현한 증거가 아니라, 확인 범위가 좁으면 검사 밖의 결함이 남는다는 것과 결함을 갈아 끼운 뒤 전체를 다시 밝혀 확인한다는 것을 상징적으로 표현한 일러스트예요.