ViewCheck 기술 블로그

다섯 특허 ↔ 세 방법, 한 장으로 보는 지도 — 1개월차 마무리

다섯 특허 ↔ 세 방법, 한 장으로 보는 지도 — 1개월차 마무리들어가며 — 오리엔테이션의 마지막, 한 장 지도오늘이 1개월차, 그러니까 오리엔테이션의 마지막 글입니다. 한 달 동안 꽤 많은 것을 깔아두었습니다. 처음엔 "왜 사람 손만으로는 웹 품질 점검이 버거운지"를 이야기했고, 그다음엔 "웹 품질을 보는 세 시점 — 설계·운영·판단"이라는 큰 틀을 세웠습니다. 이어서 그 세 시점을 하나씩, 운영 시점의 URL 분석과 설계 시점의 Figma 분석, 그리고 판단 시점의 LLM 분석으로 풀어드렸지요. 이번 주 월요일과 수요일에는 "그 방법들을 받치는 다섯 건의 특허"가 왜 필요했고, 기능은 베껴도 방법은 왜 못 베끼는지를 짚었습니다.오늘은 이 모든 것을 한 장으로 묶습니다. "다섯 개의 특허가 세 개의 방..

두 엔진의 분업과 협업 — 코드 보는 엔진, 화면 보는 엔진

두 엔진의 분업과 협업 — 코드 보는 엔진, 화면 보는 엔진들어가며 — 판단 시점의 문을 여는 이야기지난주까지 웹 품질을 보는 세 가지 시점을 한 바퀴 돌았습니다. 만들기 전에 보는 설계 시점, 만든 뒤에 보는 운영 시점, 그리고 그 위에서 무엇부터 손댈지를 정하는 판단 시점. 그중 설계 시점(Figma 분석)을 지난주에 다뤘고, 그 앞선 주에는 운영 시점(URL 분석)을 봤습니다. 이번 주는 마지막 남은 시점, 바로 판단 시점의 문을 엽니다.그런데 판단 시점 이야기를 제대로 하려면, 그 밑에 깔린 구조부터 짚고 가야 합니다. ViewCheck가 사이트 하나를 분석할 때, 실제로는 성격이 다른 두 개의 엔진이 함께 일합니다. 하나는 화면 뒤의 코드를 읽어 판정하는 규칙 엔진이고, 다른 하나는 실제로 그려..

LLM 분석이란 — 결과와 대화하는 진단들어가며 — 세 번째 시점을, 이번엔 '대화'로이번 주 월요일에는 ViewCheck가 왜 두 개의 엔진을 함께 쓰는지 이야기했습니다. 코드(DOM) 데이터를 정해진 논리로 빠르게 판정하는 규칙 엔진, 그리고 화면을 보고 코드로는 못 잡는 시각적 컴포넌트를 감지하는 시각 AI 엔진. 이 둘이 분업해서 846규칙을 판정하고, 코드가 pass/fail로 확정한 건 AI가 뒤집지 않는다는 원칙까지 짚었습니다. 그 두 엔진이 만들어내는 게 바로 "분석 결과"입니다.오늘은 그 결과 "위에서" 벌어지는 이야기입니다. 첫 주에 웹 품질을 보는 세 가지 시점을 말씀드렸지요. 만들기 전(설계), 만든 후(운영), 그리고 그 위에서(판단). 앞의 두 시점은 지지난주 URL 분석(운영)..

AI가 읽고 고친다 — N/A 해소와 개선안들어가며 — 이번 주의 마지막 조각, 판단이번 주는 1개월차의 마지막 주입니다. 월요일엔 ViewCheck가 어떻게 두 엔진으로 일을 나누는지(코드를 보는 규칙 엔진과, 화면을 보는 시각 AI 엔진)를 봤고, 수요일엔 그 위에 얹히는 LLM 분석이란 무엇인지(판단 시점, 결과를 사람처럼 해석하는 층)를 봤습니다. 오늘 금요일은 그 둘을 하나로 잇는 실용적인 이야기입니다. "AI가 읽고 고친다" — 규칙으로 딱 떨어지지 않아 빈칸으로 남은 것을 AI가 어떻게 읽어서 채우고, 나아가 "그래서 어떻게 고치면 되는지"까지 어떻게 이어주는가 하는 것입니다.먼저 솔직한 이야기부터 드리겠습니다. 지난 몇 주 동안 "846규칙을 자동으로 판정한다"고 말씀드렸지만, 사실 규칙만..

Figma 분석이란 — 만들기 전에 잡는다들어가며 — 시점을 하나 앞으로 당깁니다지난주에는 운영 시점, 그러니까 URL 분석 이야기를 드렸습니다. "이미 돌아가고 있는 진짜 사이트를 있는 그대로 본다"는 것이었죠. 이번 주에는 시점을 하나 앞으로 당겨보려 합니다. 아직 만들지도 않은, 디자인 단계의 화면을 보는 것. ViewCheck 용어로는 Figma 분석이고, 이번 달 첫 주에 말씀드린 세 시점 중 "설계 시점"에 해당합니다.요즘 웹사이트나 앱은 거의 다 Figma 같은 디자인 도구로 화면을 먼저 그립니다. 개발에 들어가기 전에, 디자이너가 색과 레이아웃과 버튼 모양을 미리 다 잡아두는 것이죠. 이 단계의 화면이 바로 "설계도"인 셈입니다. 건물로 치면 착공 전 도면입니다. 벽돌 한 장 쌓기 전에, ..

디자인은 통과, 개발에서 무너진 토큰 — 도면과 결과물 사이에서 새는 것들들어가며 — "디자인은 분명 맞게 했는데요"이번 주 월요일에 Figma 분석, 그러니까 "만들기 전에 도면 단계에서 기준을 보는" 이야기를 드렸습니다. 핵심은 하나였습니다. "고치는 비용은 단계가 뒤로 갈수록 폭발한다, 그러니 제일 싼 도면 단계에서 잡는 게 이득이다." 오늘은 그 도면 단계를 조금 더 입체적으로, 두 개의 사례로 풀어보려 합니다. 방향이 정반대인 두 이야기를 나란히 놓을 텐데, 그렇게 놓아야만 보이는 결론이 있어서입니다.하나는 "도면 단계에서 안 잡아서 비싸진" 경우입니다. 디자인에서 미리 봤으면 아주 싸게 끝났을 일을, 안 봐서 개발과 배포가 다 끝난 뒤에 비싸게 고친 이야기입니다.다른 하나는 "도면은 잘 잡았는..

Figma에서 KRDS 보는 법 — 도면을 실무에서 점검하는 순서들어가며 — 도면을 보는 "순서"이번 주 1개월차 세 번째 주의 마지막 글입니다. 월요일에는 "왜 도면 단계에서 보나(고치는 비용은 단계가 뒤로 갈수록 뛴다)"를, 수요일에는 "도면을 안 보거나 도면만 봐서 문제가 새는 사례들"을 살펴봤습니다. 오늘은 이번 주에서 가장 실용적인 부분을 다룹니다. 그래서 Figma 같은 디자인 파일에서 KRDS 준수를 실제로 어떻게 점검하느냐 하는 것입니다.미리 한 가지 말씀드리면, 오늘 글은 "Figma 사용법" 강좌가 아닙니다. 디자인 도구를 다루는 법은 디자이너분들이 저보다 훨씬 잘 아십니다. 오늘 다루려는 건 "디자인 파일을 KRDS 기준에 비춰볼 때 무엇을, 어떤 순서로 보면 되는지"라는 점검의 관점..

URL 한 줄만 넣으면 된다 — '운영 중인 진짜 사이트'를 보는 법들어가며 — 첫 타자는 가장 직관적인 시점, 운영지난주에 웹 품질을 보는 세 가지 시점 이야기를 드렸습니다. 만들기 전(설계), 만든 후(운영), 그 위에서(판단). 그리고 한 시점만 보면 절반만 보인다는 말씀도 드렸습니다. 이번 주부터는 그 세 시점을 하나씩 깊게 파볼 텐데, 첫 타자가 가장 직관적인 시점, 바로 운영 시점입니다. ViewCheck 용어로는 URL 분석이라고 부릅니다.운영 시점이 왜 첫 타자냐면, 어차피 사용자가 마주하는 건 디자인 파일도 코드도 아니라 "지금 돌아가고 있는 실제 사이트"이기 때문입니다. 거기서 불편하면 그걸로 끝입니다. 아무리 설계가 훌륭했어도, 아무리 코드가 깔끔했어도, 지금 이 순간 사용자 화면에서..

"테스트할 땐 멀쩡했는데요" — 왜 하필 '운영 중인 진짜 사이트'를 봐야 하나들어가며 — "테스트할 땐 멀쩡했는데요"월요일에 URL 분석 = 운영 시점, 그러니까 "지금 돌아가는 진짜 사이트"를 본다는 이야기를 드렸습니다. 오늘은 그 "진짜 사이트"라는 말에 왜 그렇게 힘을 주는지를, 현장에서 자주 듣는 한 문장으로 풀어보려 합니다."어? 테스트할 땐 멀쩡했는데요."개발을 하다 보면 정말 자주 듣는 말입니다. 개발자 본인 컴퓨터에선 잘 됐고, 테스트 서버(스테이징)에서도 잘 됐는데, 막상 진짜 운영 사이트에 올리니까 뭔가 깨집니다. 디자인이 어긋나거나, 어떤 기능이 안 되거나, 모바일에서만 이상합니다. 분명 똑같은 코드인데 왜 결과가 다를까요?이게 오늘의 주제입니다. "만든 환경"과 "사용자가 실제로 ..

분석 결과, 어디부터 봐야 하나 — 스무 개가 넘는 분석 영역, 읽는 순서들어가며 — 결과를 잘 읽는 것도 점검의 절반이다이번 주 1개월차 두 번째 주의 마지막 글입니다. 월요일엔 URL 분석이 무엇인지(운영 시점, 화면 기준으로 넓게 본다)를 봤고, 수요일엔 왜 운영본을 봐야 하는지(가정이 아니라 현실, 스테이징은 멀쩡한데 운영은 깨지는 이유)를 봤습니다. 오늘은 가장 실용적인 부분입니다. 분석을 한 번 돌리면 결과가 꽤 많이 쏟아지는데, 그걸 어디서부터 어떻게 읽느냐 하는 것입니다.URL 분석을 처음 돌려보면 결과가 생각보다 많습니다. 점수 카드도 있고, 영역이 여러 개 있고, 위반 목록도 깁니다. "정보는 많은데 무엇부터 봐야 할지 모르겠다"는 게 솔직한 첫 반응이실 겁니다. 지난주에 봤듯, 정보가..

우리 상황엔 언제 무엇을 보나 — 상황별 선택 가이드, 그리고 KRDS를 우리 일정에 끼워 넣는 법들어가며 — "다 해야 한다"는 말이 제일 무책임하다월요일엔 세 시점(설계·운영·판단)이라는 큰 그림을 펼쳤고, 수요일엔 한 시점만 보다가 통과 도장을 받고도 민원이 터진 사례들을 봤습니다. 두 글을 다 읽고 나면 자연스럽게 드는 생각이 하나 있습니다. "그래서 결국 세 개 다 하라는 거 아닌가?" 그리고 그 뒤에 곧바로 따라오는 한숨. "우리는 사람도 시간도 예산도 부족한데, 세 시점을 다 보라니. 또 그림의 떡이네."이 한숨을 정면으로 받아내는 게 오늘의 목표입니다. 결론부터 말씀드리면, 세 시점을 항상 똑같은 무게로 다 보라는 게 아닙니다. 그건 현실을 모르는 소리입니다. 진짜 실무의 답은 이렇습니다...

검수는 통과인데 왜 민원이 터질까 — 리뉴얼 검수가 놓치는 자리, 그리고 KRDS로 그 자리를 메우는 법들어가며 — "통과 도장"을 두 개나 받았는데월요일엔 "웹 품질을 보는 세 시점"이라는 큰 그림을 깔았습니다. 설계·운영·판단, 이 셋을 다 봐야 전체가 보인다는 이야기였습니다. 그리고 그 위에서 KRDS 846규칙이 시점별로 판정된다는 것까지 봤습니다. 오늘은 그 추상적인 개념을 실제 현장의 장면으로 가져와 보겠습니다. 한 시점만 보다가 실제로 어떻게 새는지, 현장에서 반복해서 벌어지는 패턴을 사례로 따라가 보시죠. 다 익명이고, 특정 기관 이야기가 아닙니다. 어디서나 비슷하게 일어나는 일이라서 오히려 사례로 쓸 수 있는 것이죠.장면은 이렇게 시작합니다. ㅇㅇ기관이 사이트를 크게 개편했습니다. 예산도..

코드 검사 한 번 돌리고 안심하셨나요? — 공공 웹 품질을 보는 세 가지 시점, 그리고 KRDS를 제대로 보는 법들어가며 — "점검했다"는 안도감이 가장 위험할 때공공 웹사이트 담당자분들께 "우리 사이트 KRDS 점검, 어떻게 하고 계세요?"라고 여쭤보면 대답이 크게 두 갈래로 나뉩니다. 하나는 "담당자가 체크리스트 들고 직접 봅니다"이고, 다른 하나는 "검사 도구 돌려봤는데 별문제 없다고 나왔어요"입니다.첫 번째 방식의 한계는 분명합니다. KRDS 점검 항목은 846개나 되고, 봐야 할 페이지는 수십에서 수백 장입니다. 인력은 부족하고, 시간은 모자라고, 보는 사람마다 기준이 흔들립니다. 분명히 봤다고 생각한 항목인데 정작 중요한 걸 놓칩니다. 846개나 되는 규칙을, 그것도 수십 수백 페이지에 걸쳐,..