ARCHIVE
아카이브
기존에 공개한 글을 원래 주소 그대로 보관합니다.
과거의 글에는 작성 당시의 기술과 관점이 담겨 있습니다.
356개 글 · 1 / 12 페이지
· KO
AI 검색 최적화를 위한 SEO·접근성 점검과 답변 검증
AI 검색이 문서를 찾고 답변을 만드는 원리에서 SEO와 웹 접근성의 역할을 설명합니다. 가상의 요금 안내 페이지를 바탕으로 수집 경로와 정보의 정확성을 확인하고, 체크리스트와 LLM 검토를 CMS 운영에 적용하는 방법을 살펴봅니다.
· KO
미용실이 ChatGPT로 홈페이지를 만드는 시대, 웹 개발의 가치는 어디에 있을까요
미용실의 홈페이지 직접 수정 사례에서 별도 예약 시스템과 무료 정적 호스팅, 운영 기술부채를 살펴보고 AI 시대 웹 제작사와 개발자에게 필요한 검색·접근성·UX 역량을 생각합니다.
· KO
디지털 지갑을 쓰지 못하는 사람의 인증 경로
디지털 지갑과 웹이 연결돼도 이용자가 인증을 마칠 수 있는지는 별개다. 동의·취소·복구 과정을 살피고, 대체 경로의 접근성과 필요한 신원 확인·개인정보 보호를 함께 검토하는 표를 제안한다. 실제 구현을 시험한 결과는 아니다.
· KO
MCP 거버넌스 감사에서 성공 종료는 성공을 증명하지 않는다 — 15회 실행 전부 exit 0이었지만 측정은 실패했다
검증 파이프라인이 성공 신호를 보내도 실제로는 아무것도 측정하지 못했을 수 있다. 15회 실행이 전부 성공 종료 코드로 끝났지만, 결과 파일이 없거나 출력이 비어 있어 측정 자체가 실패한 사례를 보여준다.
· KO
MCP 서버 리스크 점검은 결과 파일이 없으면 0점으로 기록된다 — 리스크 0과 측정 불가를 구분하는 규약이 먼저다
점검 도구가 성공이라고 말해도 결과 파일이 비어 있으면 그 0점은 리스크 없음이 아니라 측정 안 됨이다. 점수 도구 도입 전에 설정 파일 스냅샷과 셀별 결과 파일이 없으면 실패로 기록되는 저장 규약부터 만들어야 한다.
· KO
AI 학습만 거부하고 검색 노출과 인용을 유지하는 robots.txt 설정은 OpenAI 봇 토큰에서는 공식 문서로 보장되지만, Google-Extended는 학습과 인용을 한 토큰에 묶어 그 분리를 제공하지 않는다
robots.txt 파일 하나로 AI 로봇의 방문을 통제할 때, 검색에는 나오면서 학습만 막는 설정이 제공사마다 가능 여부가 다르다. 이 글은 내 사이트의 실제 파일과 여섯 로봇의 응답 실험, OpenAI와 Anthropic의 공식 문서를 대조해 어디서 분리 설정이 보장되는지 좁혀 본다.
· KO
MCP 로드맵에 적힌 기능은 MCP 스키마에 아직 없다
시장 앞 전단지에 적힌 물건과 진열대에 실제 놓인 물건은 다르다. 공식 계획 문서에 이름이 있는 기능이 규격 문서에는 없는 현실을 직접 재서 확인했다.
· KO
AGENTS.md 와 CLAUDE.md 를 심볼릭 링크로 묶는 방법은 오늘도 통하지만, 이를 보증하는 문서는 어디에도 없다
두 프로그램에 규칙 문서 한 벌을 나눠 먹이는 심볼릭 링크 방법이 흔한 관행이 됐다. 그러나 링크가 동작하는 것은 어느 도구의 약속이 아니라 파일이 그 자리에 있어서이며, 폴더를 옮기면 절대 경로 링크는 끊긴다.
· KO
클로드에서 CLAUDE.md 규칙이 닿는지는 파일 위치가 아니라 세션을 띄운 폴더가 결정한다
같은 규칙 문서를 쓰더라도 작업 세션을 어느 폴더에서 열어 주느냐에 따라 닿는 범위가 달라진다. 대화 한가운데에야 도착한 규칙은 처음부터 준 규칙의 절반만 받아들여졌다.
· KO
AGENTS.md를 CLAUDE.md에 연결하는 세 가지 방법과 감싼 한 줄의 함정
AGENTS.md를 CLAUDE.md로 끌어오는 공식 방법 세 가지를 실제로 돌려 비교한 결과, 세 방법은 같은 결과를 냈다. 대신 예시로 감싼 한 줄이 문서 전체를 아무 알림 없이 지워 버리는 함정이 확인됐다.
· KO
사용자가 딱 한 가지 반대로 요청하면 Claude Code는 CLAUDE.md 규칙 문서 전체를 버린다
냉장고에 붙인 메모 같은 규칙 문서가 실제로 어디까지 효과가 있는지 6번씩 반복해 쟀다. 사용자 요청이 규칙 하나와 충돌하는 순간 충돌하지 않은 규칙까지 문서 전체가 공격으로 판정되어 버려지는 결과가 6번 중 6번 나왔다.
· KO
구글 검색 인공지능 답변: 사이트를 넣는 방법엔 전용 문서를, 빼는 방법엔 문장 하나를 남겼다
2026년 8월 20일 구글이 내놓은 선호 출처 기능의 문서 두께를, 빼는 방법의 문서 두께와 나란히 세어 본 기록이다. 공식 문서 세 표면과 자사 페이지 12 URL을 직접 세어, 더 보여 주기와 덜 보여 주기의 비대칭이 숫자로 어떻게 나타나는지 짚는다.
· KO
웹 접근성 리플로우 기준을 통과해도 400% 확대 화면에서는 글을 못 읽을 수 있다
WCAG 리플로우의 가로 기준(320픽셀에서 가로 스크롤 없음)을 통과해도 세로 읽기는 보장되지 않는다. 화면 높이와 무관하게 고정 요소가 항상 82픽셀의 세로 공간을 가져가므로, 400% 확대 화면에서는 통과 판정 옆에 세로 측정을 따로 해야 한다.
· KO
에이전트 세션을 버려도 되는 캐시로 취급하고 통제를 정책 평면으로 옮겼더니 벤더 락인이 관리 가능해졌다
세션 이식은 쓸모 있는 작업 맥락을 살려 준다. 그러나 인증, 훅, 정책, MCP 접속, 런타임 설정은 원래 클라이언트에 남는다. 오래 가는 답은 승인과 감사를 에이전트 하네스 밖에 두는 데 있다.
· KO
MCP 로드맵을 출시 일정이 아니라 운영 계획서로 읽었더니 지금 만들 것이 바뀌었다
MCP 로드맵은 납품 일정표가 아니다. 카탈로그 경제성, 문서의 출처 면, 교체 가능한 신원 경계가 다음 스펙이 나오기 전에 엔지니어링 리더가 손대야 할 것을 결정한다.
· KO
같은 규칙을 CLAUDE.md, 스킬, 서브에이전트로 옮겨보니 결정 기준은 비용이 아니었다
CLAUDE.md, SKILL.md, 서브에이전트는 적용 범위와 수명이 서로 다른 문제를 푼다. 세 계층을 가르는 진짜 경계는 강제력이며, 셋 중 어느 것도 통제 평면이 아니다.
· KO
400% 확대에서 남는 화면을 실측했더니, 뷰포트 높이와 무관한 고정 px 통행료가 나왔다
320px 리플로우 판정을 통과한 페이지에서도 짧은 뷰포트에서는 본문에 남는 세로 공간이 118px까지 줄었다. 손실은 비율이 아니라 82px짜리 고정 픽셀 통행료였고, 대부분 우리 CSS 밖의 제3자 고정 컨테이너에서 나왔다. 측정 방법과 배포 회귀 게이트 설계까지 정리했다.
· KO
에이전트 비용 28배 차이를 뜯어보니, 결정권은 하네스에 있었다
MCP를 붙일지 말지는 에이전트 비용의 주요 결정이 아니다. 하네스 7종과 모델 5종을 고정 과제로 돌린 통제 실험, 직접 잰 도구 정의 페이로드, 실패에 묶인 지출 비율을 놓고 비용과 신뢰성과 감사 가능성을 실제로 결정하는 층이 어디인지 짚는다. 플랫폼 팀이 바꿀 것도 적었다.
· KO
AI 검색에서 사이트를 빼는 스위치를 공식 문서에서 찾아봤더니 있는 건 포함 레버뿐이었다
Google의 AI 기능 문서 원문 177,842바이트에서 opt out, opt-out, exclude를 전수로 세어보니 전부 0건이었다. AI Overviews와 AI Mode 전용 배타 레버가 왜 없는지, robots.txt 대신 무엇을 손봐야 하는지 18런 실측으로 정리했다.
· KO
스팸 업데이트 시작 시각을 분 단위로 긁어봤더니 Search Console 조인 키는 하루 단위 그대로였다
Google Search Status Dashboard의 incidents.json은 스팸 업데이트 시작 시각을 초 단위로 공개한다. Search Console 조인 키는 PT 날짜 하나다. 두 해상도를 대조해, 분 단위 정밀도가 경계일 조인에서 사라지는지 직접 확인했다.
· KO
Search Console 플랫폼 속성: 화면은 넷으로 넓어졌고 API는 둘에 멈췄다
Search Console 플랫폼 속성은 Instagram·TikTok·X·YouTube의 구글 검색 성과를 보여준다. 전면 공개 3주 뒤에도 헬프센터는 점진 롤아웃이라 적고 API 참조는 2024년에 멈춰 있다. 측정을 자동화한 팀이 왜 새 데이터를 늦게 보는지 정리했다.
· KO
규칙이 잘려도 에러는 나지 않는다 robots.txt와 AGENTS.md 219런 실측
2026년 8월 17일 세 개의 robots.txt 파서와 두 코딩 에이전트 CLI를 219번 돌렸다. 규칙이 잘리거나 잘못 읽혀도 프로세스는 0으로 끝났고 차단 의도 10셀에서 ALLOWED나 UNDEFINED가 나왔다. 32 KiB 경계와 RFC 9309 사양의 구멍을 정리한다.
· KO
CSS로는 Escape를 받을 수 없다: 툴팁 일곱 개로 잰 SC 1.4.13
툴팁에 :focus-visible만 붙이면 접근성은 끝난 줄 알았다. 구현 일곱 개를 만들어 Dismissible·Hoverable·Persistent 세 항목을 각각 재보니 CSS만으로 통과한 것은 하나도 없었고, popover="hint"조차 절반만 대신해 주었다.
· KO
Chrome의 에이전트 스킬을 세어봤다: 가이드 138개, 접근성 2개, 검색 0개
Google Chrome 팀의 Modern Web Guidance 0.0.180을 설치해 가이드 138개를 세고, 22개 질의로 검색을 찔러봤다. 상위 유사도는 UI 0.643, 접근성 0.508, 구조화 데이터 0.267. 빈자리를 프로젝트 규칙으로 메우는 방법까지 정리했다.
· KO
320px로 재면 리플로우는 절반만 잰 것이다: 400% 확대의 높이 200px
WCAG 1.4.10 리플로우를 320x844, 320x256, 320x200 세 조건으로 같이 재봤다. 가로 판정은 세 조건이 한 픽셀도 다르지 않았고, 400% 확대에서 실제로 달라지는 것은 높이였다. 82px짜리 sticky 헤더가 뷰포트의 41%를 먹고 있었다.
· KO
인용된 문장으로 되돌아오는 링크: 코드 블록에서만 15개 중 14개가 끊겼다
AI 답변이 내 글의 한 문장을 인용하고 그 문장으로 가는 링크를 걸었을 때, 그 링크가 실제로 동작하는지 크로미움에서 69개 확인했다. 산문 48개는 전부 도착했고 코드 블록 15개 중 14개가 끊겼다. 텍스트 프래그먼트의 블록 경계·단어 경계 규칙을 실측으로 정리한다.
· KO
자간을 0.12em 넓혔더니 570곳이 잘렸다: 검사기가 통과시킨 AA 기준
axe-core는 WCAG 1.4.12 텍스트 간격 기준에 위반 0건을 줬다. 그런데 그 기준이 요구하는 네 줄을 실제로 적용하자 570개 요소에서 글자가 잘렸다. 네 줄을 하나씩 따로 걸어 -webkit-line-clamp가 어디서 콘텐츠를 잃게 하는지를 분해해봤다.
· KO
W3C 정답지 1,213장에 검사기를 걸었다: 자동 접근성 게이트가 결정하는 것
W3C ACT가 공개한 정답 붙은 테스트 케이스 1,213장에 axe-core를 전수로 돌렸다. 실패해야 하는 예제 387장 중 해당 성공기준으로 위반이 잡힌 것은 145장(37.5%)이었고, 36개 기준 중 22개는 0건이었다. 침묵의 일부는 규칙이 그냥 꺼져 있어서였다.
· KO
Tab으로 0건, Shift+Tab으로 16건: 스티키 헤더가 삼킨 키보드 포커스
같은 6개 페이지를 Tab으로 내려가며 재면 WCAG 2.4.11 위반이 0건, Shift+Tab으로 올라가며 재면 16건이었다. 브라우저가 포커스 대상을 화면에 넣는 정렬이 진행 방향에 따라 달라지기 때문이다. CSS 한 줄로 16건을 0건으로 줄인 바로 그 실측이다.
· KO
1년 전 글의 Last-Modified가 어제였다: 배포가 지우는 캐시 검증자
작년에 쓴 글을 curl로 찔러보니 Last-Modified가 어제 배포 시각이었다. ETag는 파일 수정 시각과 크기를 16진수로 이어붙인 값이다. 같은 소스로 다시 빌드한 HTML 1,346장이 100% 바이트 동일한데도, 배포 한 번이 사이트 전체의 조건부 요청을 무효로 만든다.