우리 상황엔 언제 무엇을 보나 — 상황별 선택 가이드, 그리고 KRDS를 우리 일정에 끼워 넣는 법

들어가며 — "다 해야 한다"는 말이 제일 무책임하다

월요일엔 세 시점(설계·운영·판단)이라는 큰 그림을 펼쳤고, 수요일엔 한 시점만 보다가 통과 도장을 받고도 민원이 터진 사례들을 봤습니다. 두 글을 다 읽고 나면 자연스럽게 드는 생각이 하나 있습니다. "그래서 결국 세 개 다 하라는 거 아닌가?" 그리고 그 뒤에 곧바로 따라오는 한숨. "우리는 사람도 시간도 예산도 부족한데, 세 시점을 다 보라니. 또 그림의 떡이네."

이 한숨을 정면으로 받아내는 게 오늘의 목표입니다. 결론부터 말씀드리면, 세 시점을 항상 똑같은 무게로 다 보라는 게 아닙니다. 그건 현실을 모르는 소리입니다. 진짜 실무의 답은 이렇습니다. 세 시점이 있다는 걸 의식하되, 우리 상황에 맞춰 무게중심을 옮긴다. 새로 만드는 중이냐, 이미 운영 중인 걸 점검하느냐, 정기적으로 관리하느냐에 따라 지금 당장 봐야 할 시점이 달라집니다.

"다 해야 한다"는 말은 사실 제일 무책임한 조언입니다. 듣는 사람을 움직이게 만들지 못하니까요. 인력이 둘인 팀에게 "세 시점을 다 완벽하게 보세요"라고 하면, 그건 "아무것도 시작하지 마세요"와 같은 말입니다. 부담만 주고 첫걸음을 막습니다. 반대로 "지금 우리 상황에선 이 하나가 가장 급하다"고 짚어주면, 사람은 그 하나부터 시작할 수 있습니다. 그리고 그 하나를 제대로 끝내고 나면, 자연스럽게 다음 빈자리가 보입니다. 오늘 글은 그 "지금 우리한테 가장 급한 하나"를 어떻게 찾는지에 대한 실무 가이드입니다.

그러니 오늘은 거창한 방법론이 아니라, 책상 앞에서 바로 써먹을 수 있는 결정표를 만들어 보겠습니다. 우리 사이트가 지금 어떤 국면에 있는지를 먼저 묻고, 그 국면에 맞는 시점의 무게중심을 정하고, 그 시점을 KRDS 846규칙으로 어떻게 점검할지까지 한 장으로 묶습니다. 이번 주 세 글 중 가장 짧게 끝나도 되는 글이지만, 가장 자주 다시 펼쳐 볼 글이 되길 바랍니다.

미리 한 가지를 짚고 가겠습니다. 오늘 가이드의 전제는 "세 시점은 셋이지만, 판정의 기준은 하나"라는 것입니다. 상황에 따라 설계를 더 볼지 운영을 더 볼지는 달라지지만, 무엇을 통과로 보고 무엇을 위반으로 볼지는 KRDS 846규칙이라는 단일 기준으로 고정돼 있습니다. 이 전제가 있어야 가이드가 의미를 갖습니다. 만약 국면마다 잣대가 달라진다면, "이 국면엔 이 시점" 같은 선택은 아무 소용이 없습니다. 시점을 어떻게 고르든 결과를 비교할 수 없을 테니까요. 846규칙이라는 고정된 잣대 위에서 시점의 무게중심만 옮긴다는 것 — 이게 오늘 가이드를 떠받치는 뼈대입니다.

그리고 이 846규칙이 그냥 추상적인 권고가 아니라는 것도 기억해 두시면 좋겠습니다. 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개로 영역이 또렷이 나뉜 구체적인 검증 항목들입니다. 어느 국면에서 점검하든, 결국 이 846개 항목 중 무엇을 지키고 무엇을 어기는지로 답이 모입니다. 그래서 가이드를 따라 시점을 고르는 일은, 곧 "이 국면에서 846규칙의 어느 영역을 집중해서 볼지"를 고르는 일과 같습니다. 오늘 본론을 읽으며 각 국면이 846규칙의 어떤 영역과 맞닿는지를 함께 보시면, 가이드가 한층 손에 잡힐 것입니다.

어떤 상황이든 출발점은 같습니다. URL 하나를 넣으면 운영 중인 사이트를 자동으로 돌아 846규칙 종합 결과를 한 화면에 펼쳐 주는 전체 규칙 대시보드. 상단 점수 카드, 카테고리별 위반 TOP, 레이더, 추이까지 (기관명·도메인 블러)

본론 1 — 새로 만들거나 크게 개편하는 중일 때

세 시점을 시간 순서대로 다 태우는 게 이상적이다

가장 이상적인 국면은 사실 "지금 새로 만들거나 크게 개편하는 중"일 때입니다. 왜냐하면 이때는 세 시점을 시간 순서대로 차곡차곡 다 거칠 수 있기 때문입니다. 사이트가 아직 굳지 않았으니, 설계에서 한 번 거르고, 배포 후 운영에서 한 번 확인하고, 그 위에 판단을 얹어 우선순위를 정하는 흐름이 자연스럽게 깔립니다.

구체적으로 보면 이렇습니다.

디자인 단계 → 설계 시점(Figma 분석)으로 미리 잡습니다. 시안이 KRDS 표준에서 벗어나 있으면 화면을 그리기도 전에 잡습니다. 수요일에 본 1:10:100 법칙을 떠올리면, 설계 단계의 1짜리 결함을 여기서 막는 게 가장 싸게 먹힙니다.
개발·배포 후 → 운영 시점(URL 분석)으로 실물을 확인합니다. 시안의 의도가 실제 코드로 제대로 옮겨졌는지, 배포본에서 깨진 데는 없는지를 진짜 화면으로 봅니다. "디자인은 통과인데 배포본은 위반"이라는 그 간극을 여기서 메웁니다.
그 위에서 → 판단 시점(LLM 분석)으로 우선순위를 매기고 개선안을 정리합니다. 오픈 일정이 코앞이라면 모든 위반을 다 고칠 순 없습니다. "P0부터 먼저, 나머지는 오픈 후 차수로"를 여기서 정합니다.

이 세 단계를 순서대로 태우면, 수요일 첫 번째 사례의 "설계는 통과인데 실물을 아무도 안 본" 함정이 구조적으로 안 생깁니다. 설계에서 거르고, 운영에서 확인하고, 판단에서 정리하니까요. 시점 사이에 빈틈이 생길 자리가 없습니다.

설계(도면)→운영(브라우저)→판단(AI) 세 단계를 시간 순서대로 거치는 신축·개편 국면의 점검 흐름 도식 (Gemini 1:1)

설계 시점이 왜 가장 싼지, 숫자로 다시 보기

새로 만드는 국면에서 설계 시점을 강조하는 데는 분명한 이유가 있습니다. 같은 결함이라도 언제 잡느냐에 따라 고치는 비용이 완전히 달라지기 때문입니다. 수요일에 살짝 언급한 1:10:100 법칙을 여기서 조금 더 풀어 보겠습니다. 디자인 단계에서 잡으면 비용이 1입니다. 시안을 고치는 건 파일 하나 수정하는 일이니까요. 그런데 같은 결함을 개발이 끝난 뒤 잡으면 비용이 10으로 뜁니다. 이미 짜인 코드를 뜯어고치고 다시 테스트해야 하니까요. 그 결함을 배포한 뒤, 사용자 민원으로 발견하면 비용이 100이 됩니다. 운영 중인 서비스를 멈추거나 긴급 패치하고, 그동안 쌓인 불만까지 수습해야 하니까요.

공공 사이트는 이 100 단계의 비용이 특히 무겁습니다. 민간 서비스라면 "다음 업데이트 때 고치죠" 하고 넘어갈 수 있지만, 공공 사이트의 결함은 곧바로 민원이 되고, 감사 지적이 되고, 때로는 접근성 관련 법적 리스크로 번집니다. 그래서 새로 만드는 국면에서 설계 시점을 건너뛰는 건, 눈앞의 일정을 아끼려다 나중에 100배의 비용을 떠안는 선택이 됩니다. "지금 시안 단계에서 한 번 보는 게 귀찮아서" 미룬 점검이, 오픈 후엔 손도 못 댈 만큼 커져서 돌아옵니다. 새 프로젝트일수록 설계 시점에 가장 먼저 투자해야 하는 이유입니다.

설계 단계의 점검은 "느낌"이 아니라 "기준"이어야 한다

디자인 단계에서 점검한다고 하면, 흔히 선임 디자이너가 시안을 보며 "이 색은 좀 연한데", "여기 간격이 어색하다" 하고 코멘트를 다는 장면을 떠올립니다. 이런 정성적 리뷰도 가치가 있지만, 그것만으로는 부족합니다. 사람의 눈은 일관되지 않고, 리뷰어가 바뀌면 기준도 바뀝니다. 어제는 통과시킨 색상을 오늘은 지적할 수도 있습니다. 그래서 설계 시점의 점검도 "느낌"이 아니라 "기준"으로 받쳐야 합니다.

KRDS 846규칙 중 디자인 스타일(DS) 120개가 바로 이 기준입니다. 색상, 타이포그래피, 간격, 레이아웃이 정해진 토큰과 수치에 맞는지를 사람의 감이 아니라 정해진 값으로 봅니다. "이 파란색이 KRDS 색상 토큰에 맞는지", "본문 글자 크기가 기준 안에 드는지", "버튼 사이 간격이 그리드를 따르는지"를 정량으로 판정합니다. 시안을 이 DS 규칙으로 한 번 거르면, 리뷰어의 컨디션과 무관하게 같은 기준이 적용됩니다. 설계 시점이 "느낌의 영역"에서 "기준의 영역"으로 올라서는 순간입니다. 그리고 이 DS 기준은 나중에 운영 시점에서 배포본을 볼 때도 똑같이 적용되니, 두 시점이 같은 잣대로 이어집니다.

개편 프로젝트에서 가장 무서운 건 "시안과 배포본의 간극"이다

개편을 해보신 분은 아실 겁니다. 가장 골치 아픈 건 새 디자인을 만드는 것 자체가 아니라, 그 디자인이 개발을 거치면서 조금씩 어긋나는 것입니다. 디자이너가 정한 색상 토큰이 개발 과정에서 비슷한 다른 값으로 바뀌고, 버튼 간격이 미묘하게 달라지고, 모바일에서 의도와 다르게 접힙니다. 하나하나는 사소하지만, 이게 수십 개 화면에 누적되면 "우리가 만들기로 한 사이트"와 "실제로 배포된 사이트"가 다른 물건이 됩니다.

여기서 KRDS 846규칙이 두 시점을 잇는 공통 자가 됩니다. 설계 시점에서 시안을 846규칙으로 한 번 보고, 운영 시점에서 배포본을 똑같은 846규칙으로 다시 봅니다. 그러면 "시안은 지켰는데 배포본은 어겼다" 같은 간극이 같은 항목 위에서 또렷이 드러납니다. 잣대가 같으니 비교가 되는 것입니다. 만약 설계는 디자인 가이드로 보고 배포본은 코드 검사로 봤다면, 둘은 애초에 비교가 안 되는 다른 기준이라 간극을 잡을 수가 없습니다. 같은 846규칙으로 두 번 보는 게 핵심입니다.

새로 만들 땐 "끝나고 한 번"이 아니라 "단계마다"

새로 만드는 국면에서 흔한 실수가 하나 더 있습니다. 점검을 "다 만들고 마지막에 한 번"으로 미루는 것입니다. 오픈 직전에 몰아서 점검하면, 그제야 무더기로 쏟아지는 위반을 손볼 시간이 없습니다. 일정은 코앞인데 고칠 게 산더미니, 결국 "이번엔 일단 오픈하고 나중에 고치자"가 됩니다. 그 "나중"이 영영 안 오는 걸 우리는 다 압니다.

그래서 새로 만드는 국면일수록 점검을 단계마다 쪼개 넣는 게 좋습니다. 디자인이 어느 정도 잡히면 설계 시점으로 한 번, 주요 화면이 개발되면 운영 시점으로 한 번, 전체가 붙으면 다시 한 번. 매 단계의 결과를 같은 846규칙으로 쌓아 두면, "이번 단계에서 새로 생긴 위반이 뭔지"가 차이로 보입니다. 마지막에 몰아서 받는 충격이 없어지고, 위반이 작을 때 작게 처리됩니다. 이게 1:10:100 법칙을 실무 일정에 녹이는 방법입니다.

본론 2 — 이미 운영 중인 사이트를 점검할 때

디자인 파일이 없거나 의미 없을 땐, 운영 시점이 주력이다

현실에서 더 흔한 국면은 "이미 한참 돌아가고 있는 사이트를 점검해야 할 때"입니다. 몇 년 전에 만들어졌고, 그동안 담당자도 몇 번 바뀌었고, 디자인 파일은 어디 있는지도 모르거나 있어도 현행 화면과 안 맞습니다. 이럴 때 설계 시점은 사실상 무용지물입니다. 비교할 시안 자체가 없으니까요.

그래서 이 국면에선 운영 시점이 압도적 주력입니다. 디자인 파일이 뭐라고 했든 상관없이, 지금 실제로 돌아가는 사이트를 실물 그대로 보는 것. 사용자가 마주하는 바로 그 화면을 846규칙으로 훑어 "지금 이 사이트가 무엇을 지키고 무엇을 어기고 있는지"를 그대로 찍어내는 방식입니다. 과거의 의도가 아니라 현재의 실태를 봅니다. 그리고 그 위에 판단 시점을 얹어 "그래서 뭐부터 손대야 하나"를 정리합니다.

이 국면의 좋은 점은, 출발이 단순하다는 것입니다. 디자인 파일을 찾아 헤맬 필요도, 개발 문서를 뒤질 필요도 없습니다. URL 하나만 있으면 됩니다. 운영 중인 사이트는 이미 살아 있으니, 그 주소를 넣고 돌리면 현재 상태가 그대로 나옵니다. 점검의 진입 장벽이 가장 낮은 국면이기도 합니다.

"과거의 의도"가 아니라 "현재의 실태"를 본다는 것

운영 시점의 본질은 "지금 이 순간 사용자가 마주하는 화면"을 본다는 데 있습니다. 이게 왜 중요한지는, 운영 중인 사이트가 어떻게 변해 왔는지를 떠올리면 분명해집니다. 처음 만들 땐 분명 디자인 가이드를 따랐을 것입니다. 그런데 그 뒤로 몇 년간 콘텐츠가 쌓이고, 게시판이 추가되고, 외주 업체가 일부 페이지를 손봤습니다. 그러는 사이 원래 의도는 조금씩 닳아 없어집니다. 디자인 파일에 적힌 "이래야 한다"와 실제 화면의 "이렇게 돼 있다" 사이의 거리가 점점 벌어집니다.

설계 시점이 보는 건 "이래야 한다"는 의도입니다. 운영 시점이 보는 건 "이렇게 돼 있다"는 실태입니다. 운영 중인 사이트를 점검할 때 의도가 아니라 실태를 봐야 하는 이유가 여기 있습니다. 사용자는 디자인 파일을 보지 않습니다. 화면을 봅니다. 그 화면에서 막히고, 그 화면에서 떠나고, 그 화면을 두고 민원을 넣습니다. 그러니 이미 운영 중인 사이트라면, 아무리 훌륭한 과거의 의도가 있었어도 지금 화면의 실태부터 봐야 합니다. 운영 시점은 그 실태를 846규칙이라는 같은 잣대로 찍어, "의도는 잊고 현재만 보면 이렇다"를 정직하게 내놓습니다.

운영 점검에서 따라오는 보너스 — 디자인 외의 영역까지

운영 중인 사이트를 실물로 본다는 건, 디자인뿐 아니라 디자인 파일로는 절대 알 수 없는 영역까지 한꺼번에 본다는 뜻입니다. 실제로 화면을 띄워 보니, 모바일에서 어떻게 접히는지가 보이고(반응형), 페이지가 얼마나 빨리 뜨는지가 측정되고(성능), 검색엔진이 읽을 메타 정보가 제대로 박혀 있는지가 확인되고(개방성), 보안 헤더가 빠지지 않았는지가 드러납니다(신뢰성). 시안에는 이런 게 아예 없습니다. 살아 있는 사이트를 직접 띄워 봐야만 알 수 있는 것들입니다.

그래서 운영 시점은 KRDS 846규칙 점검에 더해, 행정안전부 「전자정부 웹사이트 품질관리 지침」이 요구하는 여러 품질 영역을 함께 봅니다. 디자인이 A등급이어도 보안이 F등급일 수 있고, 화면은 예뻐도 모바일에서 깨질 수 있습니다. 운영 중인 사이트를 점검한다는 건 이 모든 영역을 한 번에 본다는 뜻이고, 그게 바로 디자인 파일로 못 하는 운영 시점만의 폭입니다. 이미 돌아가는 사이트일수록 이 폭넓은 실태 점검의 가치가 큽니다.

가장 흔한 실수 — 운영 점검을 "메인 한 페이지"로 좁히는 것

그런데 이 국면에서 사람들이 가장 자주 저지르는 실수가 있습니다. 운영 점검을 "메인 페이지 하나 보는 것"으로 좁혀 버리는 것입니다. 수요일 두 번째 사례가 정확히 이거였습니다. 메인은 가장 공들여 만든 페이지라 대체로 깨끗합니다. 메인만 보고 "괜찮네" 하고 덮으면, 정작 문제투성이인 신청 페이지, 상세 조회 페이지, 로그인 흐름은 한 번도 안 본 채 통과 도장이 찍힙니다.

이미 운영 중인 사이트는 페이지가 수백 개씩 됩니다. 그래서 운영 시점이야말로 전수로 봐야 의미가 있습니다. 한 페이지가 아니라 사이트 전체를 같은 846규칙으로 돌려야, "메인은 통과인데 신청 3단계에서 깨진다" 같은 진짜 문제가 잡힙니다. 여기서 다중 페이지 분석이 결정적입니다. 사이트를 자동으로 돌면서 각 페이지를 같은 기준으로 보고, "한 페이지라도 어기면 사이트 전체의 문제"로 집계하는 방식. 이게 메인 착시를 깨는 장치입니다. 운영 점검은 "메인 한 장"이 아니라 "사이트 전수"라고 못을 박고 가야 합니다. 이 다중 페이지 분석은 6개월차에서 한 달을 통째로 다룹니다.

운영 점검에서 KRDS가 빛나는 지점 — 서비스 패턴(SP)

운영 중인 사이트를 점검할 때 KRDS 846규칙 중에서도 특히 진가를 발휘하는 영역이 있습니다. 서비스 패턴(SP) 172개입니다. SP는 로그인, 검색, 신청, 정책 안내 같은 "사용자가 실제로 무언가를 하는" 흐름을 점검하는 규칙들입니다. 디자인 파일만 봐서는 절대 검증할 수 없는 영역입니다. 시안에는 "로그인 화면"이 한 장 그려져 있을 뿐, 실제로 아이디를 잘못 넣었을 때 어떤 오류가 뜨는지, 비밀번호 찾기로 어떻게 넘어가는지, 그 흐름이 KRDS 기준에 맞는지는 살아 있는 사이트를 직접 돌려봐야 압니다.

그래서 운영 중인 사이트, 특히 신청·민원·예약처럼 실제 업무가 돌아가는 공공 사이트일수록 SP 규칙의 점검 가치가 큽니다. 사용자가 가장 자주 막히고 가장 많이 민원을 넣는 게 바로 이 "무언가를 하는 흐름"이기 때문입니다. 메인 페이지가 예뻐도 신청 흐름에서 막히면 사용자는 떠납니다. 운영 시점은 이 흐름을 실물로 끝까지 따라가며 SP 규칙으로 점검합니다. 설계 시점이 못 보는 영역을 운영 시점이 메우는 대표적인 자리입니다. 이 서비스 패턴의 세계는 5개월차에서 본격적으로 다룹니다.

운영 점검 뒤에서 일하는 두 엔진

운영 시점이 "URL 하나로 사이트 전수를 846규칙으로 본다"고 했는데, 그 뒤에서 실제로 무슨 일이 벌어지는지 잠깐 들여다보겠습니다. 점검은 성격이 다른 두 엔진의 분업으로 돌아갑니다. 하나는 규칙 엔진입니다. 사이트에서 뽑아낸 DOM(화면을 이루는 구조 데이터)을 받아, 846규칙을 수 초 만에 정해진 논리로 빠르게 판정합니다. ARIA 속성이 있는지, CSS 값이 기준에 맞는지처럼 구조로 답이 나오는 영역은 이 엔진이 정확하고 빠르게 처리합니다.

문제는 구조 데이터만으로는 판단이 안 되는 영역입니다. 이미지로 된 버튼, 비표준으로 만든 UI, 색상 대비처럼 "실제로 화면을 봐야" 아는 것들. 이런 항목은 규칙 엔진이 "판단 보류(N/A)"로 남깁니다. 여기서 두 번째 엔진, 시각 AI 엔진이 나섭니다. 스크린샷을 직접 보고, 규칙 엔진이 보류한 N/A 항목과 시각적 영역을 통과·미통과로 메웁니다. 운영 중인 사이트일수록 비표준 구현이 많아 N/A가 늘어나는데, 이 엔진이 그 빈자리를 채웁니다. 두 엔진 사이엔 분명한 원칙이 있습니다. 규칙 엔진이 통과/위반으로 이미 확정한 건 시각 AI가 뒤집지 않습니다. AI는 어디까지나 "보류된 자리"와 "구조로 못 보는 자리"만 메웁니다. 그래서 빠르고 정확한 구조 판정 위에, 시각적 보강이 얹히는 구조입니다. 운영 점검이 메인 한 장이 아니라 사이트 전수를, 그것도 빠르게 처리할 수 있는 건 이 분업 덕분입니다.

본론 3 — 정기적으로 관리해야 할 때

한 번 보고 끝이 아니라, 같은 기준으로 반복해서 본다

세 번째 국면은 "한 번 점검하고 끝이 아니라 계속 관리해야 할 때"입니다. 공공 사이트는 한 번 만들고 방치하는 게 아니라, 콘텐츠가 계속 올라오고 기능이 추가되고 외주 업체가 일부를 수정합니다. 그러면서 처음엔 멀쩡했던 부분이 조금씩 망가집니다. 새 게시판이 비표준으로 붙고, 추가된 팝업이 접근성을 깨고, 수정된 폼이 오류 처리를 빼먹습니다. 이런 "서서히 무너짐"은 한 번의 점검으로는 절대 못 잡습니다.

그래서 이 국면의 핵심은 운영 시점을 주기적으로 돌리는 것입니다. 매달, 매분기, 같은 846규칙으로 같은 사이트를 다시 봅니다. 중요한 건 "같은 기준"입니다. 이번 달은 이 사람이 이 기준으로 보고, 다음 달은 저 사람이 저 기준으로 보면, 두 결과는 비교가 안 됩니다. 점검할 때마다 잣대가 흔들리면 "나아졌나 나빠졌나"를 답할 수가 없습니다. 846규칙이라는 고정된 기준으로 반복해야, 비로소 변화가 숫자로 보입니다.

"작년보다 나아졌냐"는 질문에 답을 못 하는 문제가 바로 여기서 풀립니다. 같은 기준으로 쌓인 점검 기록이 있으면, "리뉴얼 직후 준수율에서 1차 개선 후 얼마, 2차 후 얼마"처럼 추이로 답할 수 있습니다. 점검이 일회성 행사가 아니라, 사이트 품질을 꾸준히 관리하는 연속적인 활동이 되는 것입니다.

정기 관리에서 진짜 가치는 "추이"와 "회귀 감지"

정기 관리를 제대로 하면 두 가지를 얻습니다. 첫째는 추이입니다. 우리 사이트가 좋아지고 있는지 나빠지고 있는지, 어떤 영역은 개선됐고 어떤 영역은 제자리인지가 시간 축 위에 그려집니다. 이건 보고할 때도, 다음 계획을 세울 때도 강력한 근거가 됩니다. "그냥 열심히 했습니다"가 아니라 "준수율을 분기마다 꾸준히 올렸습니다"라고 말할 수 있으니까요.

둘째는 회귀 감지입니다. 정기 점검의 숨은 가치가 이것입니다. 분명 지난번엔 통과했던 항목이 이번엔 위반으로 바뀌었다면, 그 사이에 누군가 뭔가를 건드려서 망가뜨렸다는 신호입니다. 새 콘텐츠, 외주 수정, 기능 추가 — 어디선가 회귀가 일어난 것입니다. 같은 기준으로 반복해서 보지 않으면 이 회귀는 영영 안 보입니다. 그냥 "어느 날부터 민원이 늘었다"로 끝납니다. 정기 점검은 망가지는 순간을 비교로 잡아내, 작을 때 되돌릴 기회를 줍니다.

공공 사이트가 특히 정기 관리가 필요한 이유

민간 서비스도 정기 점검이 필요하지만, 공공 사이트는 그 필요가 더 절박합니다. 이유가 몇 가지 있습니다. 첫째, 공공 사이트는 콘텐츠 갱신이 잦습니다. 공지, 보도자료, 입찰 공고, 정책 안내가 매일 올라옵니다. 그때마다 비표준 마크업이나 접근성을 깨는 요소가 슬쩍 끼어들 위험이 있습니다. 둘째, 유지보수가 여러 업체로 쪼개져 있는 경우가 많습니다. 메인 페이지는 A업체, 게시판은 B업체, 민원 시스템은 C업체가 관리하면, 각자 자기 영역만 신경 쓰다가 사이트 전체의 일관성이 깨집니다. 셋째, 담당 공무원이 주기적으로 순환 보직으로 바뀝니다. 인수인계가 충분치 않으면 "왜 이렇게 돼 있는지" 아무도 모르는 상태로 사이트가 굴러갑니다.

이런 환경에서 한 번의 점검은 의미가 약합니다. 점검한 다음 날 또 콘텐츠가 올라오고, 또 다른 업체가 손을 대니까요. 그래서 공공 사이트는 "점검을 일정에 박아 두는 것"이 핵심입니다. 분기마다, 혹은 큰 갱신이 있을 때마다 같은 846규칙으로 다시 봅니다. 그래야 잦은 변화 속에서도 품질이 일정 수준 아래로 떨어지지 않게 붙잡을 수 있습니다. 정기 관리는 공공 사이트의 "느슨해짐"을 주기적으로 조여 주는 안전장치입니다.

분석을 반복하며 준수율 변화를 추적하는 성과 대시보드. "지난번보다 나아졌나"에 숫자로 답하는 정기 관리 국면의 핵심 화면 (기관명·도메인 블러)

정기 관리일수록 "사람 손이 덜 가게" 만들어야 지속된다

정기 관리의 가장 큰 적은 사실 "귀찮음"입니다. 처음 몇 번은 의욕적으로 점검하다가, 분기가 지나고 담당자가 바뀌고 일이 바빠지면 슬그머니 멈춥니다. 그래서 정기 관리를 설계할 때 가장 중요한 건 "사람 손이 최대한 덜 가게" 만드는 것입니다. 점검할 때마다 사람이 페이지를 일일이 열어 항목을 대조해야 한다면, 그 점검은 오래 못 갑니다.

여기서 다시 두 엔진의 분업이 의미를 갖습니다. 규칙 엔진이 구조를 빠르게 판정하고, 시각 AI 엔진이 규칙 엔진으로는 판단 못 한 항목을 화면으로 메웁니다. 사람은 "URL 넣고 돌리기"와 "결과 읽기"만 하면 됩니다. 점검 자체의 노동을 도구가 가져가니, 분기마다 반복해도 부담이 적습니다. 정기 관리가 지속되려면 이 "노동의 이전"이 반드시 필요합니다. 의지로 버티는 점검은 반드시 멈추고, 손이 덜 가는 점검만 살아남습니다.

본론 4 — 한 장 요약: 상황별 선택 가이드

표 하나로 정리한 무게중심

지금까지 본 세 국면을 한 장으로 압축하면 이렇게 됩니다. 어떤 상황이든 세 시점을 다 의식하되, 무게중심만 옮기면 됩니다.

상황	설계(Figma)	운영(URL)	판단(LLM)	무게중심
새로 만들기 / 개편	◎ 미리	◎ 배포 후	○ 정리	설계 → 운영 → 판단 순서대로
운영 중 점검	△ 다음 개편 때	◎ 전수	◎ 우선순위	운영 + 판단
정기 관리	△	◎ 주기적	○	운영 반복

◎ 필수 · ○ 권장 · △ 상황 따라

세 상황(새로 만들기·운영 점검·정기 관리)을 세 시점(설계·운영·판단)에 매핑해 우선순위 칸을 고르는 3×3 매트릭스 도식 (Gemini 1:1)

이 표를 읽는 법은 간단합니다. 먼저 우리 사이트가 지금 어느 줄에 있는지 고릅니다. 새로 만드는 중인가, 이미 돌아가는 걸 점검하는가, 계속 관리하는가. 줄을 골랐으면, 그 줄에서 ◎가 찍힌 시점이 지금 당장 봐야 할 곳입니다. △는 "지금은 급하지 않지만 나중에 채울 자리"입니다. 이렇게 보면 "세 개 다 하라"는 막막함이, "지금은 이 하나, 다음은 저 하나"라는 순서로 바뀝니다.

우리 줄을 잘못 고르는 흔한 실수

가이드 표가 단순해 보여도, 막상 우리 줄을 고를 때 헷갈리는 경우가 있습니다. 가장 흔한 혼동은 "개편 중인데 운영 점검만 하는 것"입니다. 큰 개편을 하면서 설계 시점은 건너뛰고, 다 만든 뒤에 운영 점검 한 번으로 끝내려 합니다. 그러면 새로 만드는 국면의 가장 큰 이점, 즉 "설계에서 미리 싸게 거르는" 기회를 통째로 날립니다. 개편 중이라면 반드시 설계 시점부터 ◎로 깔아야 합니다. 운영 점검은 그다음입니다.

반대 방향의 실수도 있습니다. "이미 운영 중인 사이트인데 디자인 파일부터 찾는 것"입니다. 몇 년 된 사이트를 점검하라고 했더니, 없는 디자인 파일을 찾느라 시간을 다 쓰고 정작 실물은 못 봅니다. 운영 중인 사이트라면 디자인 파일은 △로 미루고, 운영 시점을 전수로 도는 데 집중해야 합니다. 줄을 잘못 고르면 같은 노력으로 엉뚱한 시점만 보게 됩니다. 그래서 표를 펴고 가장 먼저 할 일은 "우리가 지금 정확히 어느 국면인지"를 솔직하게 판단하는 것입니다. 새로 만드는 중인데 운영 점검처럼 접근하거나, 운영 중인 사이트인데 신축 프로젝트처럼 접근하면, 무게중심이 어긋납니다.

한 가지 더, 세 줄은 칼같이 나뉘는 게 아니라 겹칠 수도 있습니다. 예를 들어 "운영 중인 사이트를 정기 관리하면서, 일부 페이지를 개편하는" 복합 국면이 있습니다. 이럴 땐 두 줄의 ◎를 합쳐서 봅니다. 개편하는 페이지는 설계 시점을, 나머지 운영 페이지는 정기적 운영 점검을. 표는 단일 국면을 가정하지만, 현실은 섞여 있으니 줄을 합쳐 읽는 유연함이 필요합니다. 중요한 건 어느 경우든 "비어 있는 ◎가 없게" 만드는 것입니다.

어느 줄이든 공통으로 던지는 한 가지 질문

표를 다 만들고 나면, 모든 줄을 관통하는 질문 하나가 남습니다. "지금 내가 안 보고 있는 시점은 누가 보고 있지?" 새로 만드는 중이라면 "배포본 실물은 누가 확인하지?", 운영 점검 중이라면 "메인 말고 깊은 페이지는 누가 보지?", 정기 관리 중이라면 "지난번 대비 회귀는 누가 잡지?". 이 자문 한 번이, 수요일 사례의 기관들이 놓쳤던 그 빈자리를 미리 막습니다.

여기서 중요한 건, 이 질문에 답하는 기준이 모든 줄에서 똑같이 846규칙이라는 점입니다. 새로 만들 때도, 운영 점검할 때도, 정기 관리할 때도, 결국 "846규칙 중 무엇을 지키고 무엇을 어기는가"로 답이 모입니다. 상황에 따라 보는 시점의 무게는 달라지지만, 판정의 잣대는 변하지 않습니다. 그래서 어느 국면에서 점검했든 결과가 같은 언어로 쌓이고, 국면이 바뀌어도 이전 점검과 비교가 됩니다. 잣대가 하나라는 게, 시점을 옮겨 다녀도 길을 잃지 않게 해주는 닻입니다.

국면별 "첫 30일" 실행 플랜

가이드 표가 방향을 정해 줬다면, 이제 첫 한 달을 어떻게 쓸지 그려 보겠습니다. 국면별로 현실적인 첫 30일은 이런 모습입니다.

새로 만들기/개편 국면의 첫 30일. 1주차에 현재(개편 전) 사이트를 한 번 측정해 기준선을 남깁니다. 개편이 끝났을 때 "얼마나 좋아졌는지"를 증명할 비교점이 됩니다. 2주차부터는 시안이 나오는 대로 설계 시점 점검을 붙입니다. 시안 전체가 완성되길 기다리지 말고, 주요 화면 단위로 나올 때마다 거릅니다. 4주차엔 개발된 화면이 있다면 운영 시점으로 첫 확인을 돌립니다. 핵심은 점검을 일정 뒤에 붙이는 게 아니라 일정 안에 심는 것입니다.

운영 중 점검 국면의 첫 30일. 1주차에 사이트 전수 분석을 돌리고 결과를 그대로 읽습니다. 손대지 말고 일단 실태 파악만. 2주차에 판단 시점을 얹어 P0·P1 위반을 추리고, 각각의 수정 방법을 확인합니다. 3~4주차에 P0부터 실제 수정에 들어가고, 고친 뒤 같은 기준으로 재분석해 해소를 확인합니다. 한 달 안에 "측정 → 우선순위 → 첫 수정 → 재확인" 한 바퀴를 작게라도 도는 게 목표입니다. 이 한 바퀴를 돌아 본 조직과 아닌 조직은 그다음 속도가 완전히 다릅니다.

정기 관리 국면의 첫 30일. 1주차에 첫 회차 측정을 남기고, 2주차에 점검 주기를 정해 일정표에 박습니다(분기 권장, 갱신이 잦으면 월간). 3주차엔 결과를 받아 볼 사람과 형식을 정합니다. 담당자만 볼지, 팀장까지 올릴지, 어떤 요약으로 올릴지. 4주차엔 다음 회차 알림을 걸어 둡니다. 정기 관리의 첫 달은 점검 그 자체보다 "반복될 구조"를 만드는 데 쓰는 게 좋습니다. 구조 없이 시작한 정기 점검은 두 번째 회차를 넘기지 못합니다.

자주 나오는 반론 세 가지에 미리 답하기

이 가이드를 현장에 소개하면 비슷한 반론이 돌아옵니다. 미리 답해 두겠습니다.

"예산이 없어요." 점검 자체의 비용은 생각보다 낮습니다. 첫 진단은 무료로 시작할 수 있고, 진짜 비용은 점검이 아니라 "점검 안 해서 터지는 사고"에서 나옵니다. 수요일 사례의 민원 대응, 긴급 수정, 신뢰 손실이 그 비용입니다. 예산 논리로 보면 점검은 지출이 아니라 보험입니다.

"사이트는 외주사가 관리하는데요." 그렇다면 더 필요합니다. 외주사에 "잘 관리해 주세요"라고 말하는 것과, "846규칙 기준으로 현재 위반이 이만큼이니 이 순서로 고쳐 주세요"라고 말하는 건 완전히 다른 관리입니다. 발주처가 같은 잣대를 쥐고 있어야 외주 관리가 감이 아니라 근거로 돌아갑니다. 점검 결과는 외주사를 다그치는 무기가 아니라, 발주처와 수행사가 같은 지도를 보게 만드는 공용 언어입니다.

"846개는 너무 많아요." 846개를 다 외우라는 게 아닙니다. 판정은 도구가 하고, 사람은 결과 중 우선순위 높은 것부터 보면 됩니다. 실제로 담당자가 손대는 건 "몇백 건 중 P0 몇 건"입니다. 846이라는 숫자는 사람의 부담이 아니라, 도구가 빠짐없이 봐 준다는 커버리지의 약속으로 읽으시면 됩니다. 오히려 규칙 수가 적은 점검일수록 의심해야 합니다. 항목이 적다는 건 그만큼 안 보는 영역이 넓다는 뜻이고, 안 보는 영역이 어디인지는 점검 결과 어디에도 안 나오기 때문입니다.

지금 바로 시작하는 법 — 첫 진단은 무료로

표에서 우리 줄을 골랐다면, 다음 질문은 "그래서 오늘 뭘 하지?"입니다. 답은 세 줄 모두 같습니다. 일단 현재 상태를 한 번 재는 것. 새로 만드는 중이면 기존 사이트의 기준선을, 운영 점검이면 현재 실태를, 정기 관리면 첫 회차 기록을. 어느 국면이든 첫 측정 없이는 시작이 안 됩니다.

그리고 이 첫 측정의 진입 장벽은 생각보다 낮습니다. ViewCheck는 URL 하나로 시작하는 무료 진단을 제공합니다. 설치할 것도, 계약할 것도 없이 사이트 주소만 넣으면 현재 상태의 윤곽이 나옵니다. 오늘 가이드 표에서 우리 줄을 골랐다면, 그 줄의 첫 ◎를 바로 오늘 시작할 수 있다는 뜻입니다. "언젠가 제대로 점검해야지"를 "일단 지금 상태부터 보자"로 바꾸는 것. ViewCheck는 그 첫걸음의 비용을 최대한 낮춰 두었습니다.

본론 5 — 결국 한 자리에서 옮겨 다니지 않는 게 핵심이다

도구를 갈아타는 비용이 생각보다 크다

지금까지의 이야기를 들으면 이런 반론이 가능합니다. "그럼 설계는 디자인 검수 도구로, 운영은 코드 검사 도구로, 정기 관리는 또 다른 모니터링 도구로 각각 쓰면 되는 거 아닌가?" 맞는 말 같지만, 여기엔 숨은 비용이 있습니다. 도구를 갈아탈 때마다 결과를 합치는 수고, 그리고 합치는 과정에서 생기는 누락과 편차입니다.

디자인 검수 도구의 "통과"와 코드 검사 도구의 "통과"가 같은 기준의 통과인지 아닌지부터 불분명합니다. 도구마다 잣대가 다르니까요. 정기 관리용 모니터링 도구가 잡은 위반이 개편 때 디자인 검수가 봤던 그 항목과 같은 건지도 확인하기 어렵습니다. 결국 사람이 여러 도구의 결과를 머릿속에서 억지로 끼워 맞춰야 하고, 그 과정에서 시점 사이의 간극은 또 가려집니다. 수요일에 본 "흩어진 통과 도장"의 문제가 도구 차원에서 반복되는 셈입니다.

세 시점을 한 기준으로 묶으면, 옮겨 다닐 필요가 없다

ViewCheck가 URL·Figma·LLM 세 방법을 한 도구에 묶은 이유가 정확히 여기 있습니다. 상황마다 무게중심만 옮기면 되도록, 세 시점을 한 흐름으로, 하나의 846규칙 위에 준비해 둔 것입니다. 새로 만들 땐 Figma 분석부터 시작하고, 운영 중인 걸 점검할 땐 URL을 전수로 돌리고, 계속 관리할 땐 URL을 주기적으로 반복합니다. 도구를 옮겨 다닐 필요 없이, 한 자리에서 무게중심만 옮기면 되는 것이죠.

이게 단순히 "편하다"의 문제가 아닙니다. 세 시점이 같은 846규칙 위에 있으니, 국면이 바뀌어도 결과가 한 언어로 연속됩니다. 개편 때 본 점검과 운영 점검과 정기 점검이 전부 같은 항목으로 쌓여, "이 사이트의 품질 이력"이 끊김 없이 이어집니다. 도구를 갈아탔다면 매번 끊겼을 그 이력이, 한 도구 안에서 하나의 흐름으로 남습니다. 시점을 옮겨도 길을 잃지 않는 건, 바로 이 연속성 덕분입니다.

한 자리에 묶이면 "시점 간 간극"이 저절로 보인다

도구를 한 자리에 묶었을 때 얻는 가장 큰 이득은, 사실 "편의"가 아니라 "발견"입니다. 세 시점을 따로 보면, 각 시점은 자기 안에서만 통과/위반을 말합니다. 설계 시점은 "시안은 통과", 운영 시점은 "배포본은 위반"이라고 각자 말할 뿐, 그 둘 사이의 간극은 누가 합쳐 보기 전엔 드러나지 않습니다. 그런데 세 시점이 같은 846규칙 위에 한 화면으로 모이면, "이 항목이 설계에선 통과인데 운영에선 위반"이라는 간극이 합치는 수고 없이 저절로 눈에 띕니다.

이 "시점 간 간극"이야말로 수요일 글의 핵심이었습니다. 통과 도장을 여러 개 받고도 민원이 터진 건, 도장들 사이의 빈 곳을 아무도 안 봤기 때문입니다. 그 빈 곳은 도장을 한 줄로 늘어놓고 같은 기준으로 비교할 때 비로소 보입니다. 도구를 갈아타며 따로 보면 영영 안 보이고, 한 자리에서 같은 잣대로 보면 저절로 보입니다. 그래서 "언제 무엇을 보나"의 답에는 "어디서 보나"도 포함됩니다. 같은 자리에서, 같은 846규칙으로, 세 시점을 나란히 놓고 보는 것. 그게 간극을 발견하는 가장 확실한 방법입니다.

두 부류의 독자, 하나의 결론

마지막으로 한 가지 말씀드리겠습니다. 어떤 국면에서 점검하든, 그 결과를 읽는 사람은 늘 두 부류입니다. 한쪽엔 "그래서 우리 사이트 상태가 괜찮은가, 뭐가 제일 급한가"를 빠르게 알고 싶은 의사결정자가 있고, 다른 한쪽엔 "어느 페이지의 어떤 요소를 어떻게 고치라는 건지" 구체적 지시가 필요한 실무자가 있습니다. 좋은 점검은 이 둘을 한 결과 안에서 동시에 만족시킵니다.

그래서 세 시점의 분석이 하나의 보고서로 합쳐질 때, 그 보고서는 층으로 쌓입니다. 맨 위엔 임원이 30초에 핵심을 잡는 요약, 그 아래엔 영역별·국면별 진단, 가장 아래엔 실무자가 그대로 작업에 쓰는 위반 상세와 수정 방법. 의사결정자는 위만 봐도 되고, 실무자는 아래까지 파고들면 됩니다. "언제 무엇을 봐야 하나"라는 오늘의 질문도, 결국 이 한 장의 결론으로 모입니다. 어느 국면이든, 두 부류의 독자가 각자 필요한 깊이만큼 읽을 수 있는 하나의 보고서로요.

그래서 ViewCheck는

이번 주 세 글을 한 줄로 줄이면 이렇습니다. 세 시점이 있고, 상황에 따라 무게중심이 다를 뿐, 어느 경우든 하나만으로는 전체가 안 보입니다. 그리고 오늘 글의 결론은 거기에 한 걸음을 더합니다. "다 해야 한다"가 아니라 "지금 우리한텐 이거 하나면 충분"을 먼저 찾는 게 출발입니다. 빈칸이 많을수록, 그게 다음에 채울 자리일 뿐입니다.

ViewCheck는 그 "지금 이거 하나"를 쉽게 고르고, 고른 다음 바로 실행하고, 나중에 다음 칸으로 자연스럽게 넘어가도록 세 시점을 한 도구에 묶어 두었습니다. 새로 만들 땐 설계부터, 운영 점검은 전수로, 정기 관리는 주기적으로 — 전부 같은 846규칙 위에서요. 상황이 바뀌어도 잣대는 그대로니, 점검 이력이 끊기지 않고 한 흐름으로 쌓입니다. 그래서 이 도구는 "한 번 쓰고 마는 진단기"가 아니라 "사이트 품질을 계속 따라가는 관리 도구"에 가깝습니다.

다시 강조하지만, 이건 기술 자랑이 아닙니다. 그냥 우리 같은 현장이 "다 하긴 어렵지만 그렇다고 아무것도 안 할 순 없을 때", 지금 가장 급한 하나부터 손에 잡히게 해주려는 것뿐입니다. 가이드 표를 펴고, 우리 줄을 찾고, ◎ 찍힌 시점부터 시작하면 됩니다. 그 한 걸음이 쌓이면, 어느새 세 시점이 다 덮입니다.

한 가지 덧붙이면, 도구가 세 시점을 묶어 주는 것의 진짜 가치는 "선택을 쉽게 만드는 데" 있습니다. 도구가 세 개로 흩어져 있으면, 우리는 매번 "이 국면엔 어느 도구를 켜야 하지", "이 도구 결과를 저 도구 결과와 어떻게 합치지"부터 고민해야 합니다. 그 고민 자체가 점검을 미루게 만드는 마찰입니다. 반대로 한 도구 안에서 무게중심만 옮기면 되면, 마찰이 사라집니다. 새로 만드는 중이면 설계부터, 운영 점검이면 URL을 전수로, 정기 관리면 같은 URL을 주기적으로 — 도구를 바꾸는 게 아니라 보는 깊이만 바꾸면 됩니다. 선택의 부담이 낮아지면 점검을 더 자주 하게 되고, 자주 하면 품질이 따라 올라갑니다. 결국 "언제 무엇을 보나"를 쉽게 답할 수 있게 만드는 것이, 점검을 지속하게 만드는 가장 현실적인 장치입니다.

🔐 특허로 지키는 부분

오늘 본 "상황에 따라 세 시점을 골라 묶고, 같은 기준으로 점검 이력을 연속해서 쌓는 방법"은 ViewCheck가 출원한 특허 중 시점 비교(설계·운영 교차 검증) 주제와 닿아 있습니다. 세 도구를 각각 갖추는 건 누구나 하지만, 상황에 맞춰 시점을 한 기준(846규칙)으로 엮어 빈틈 없이 덮고, 국면이 바뀌어도 같은 잣대로 비교 가능한 이력으로 누적하는 절차를 하나의 권리로 정리해 둔 것이 차별점입니다.

다만 이번 주 내내 달았던 단서를 오늘도 답니다. 특허는 "방법을 지키는 장치"지 "품질 보증서"가 아닙니다. 오늘 가이드 표가 작동하는 건 특허 그 자체가 아니라, 세 시점을 실제로 같은 기준으로 보는 분석 방식 덕분입니다. 특허는 그 방식을 보호할 뿐입니다. 그래서 "특허 있으니 믿으세요"가 아니라 "이 방법을 직접 설계하고 권리로 지켜 두었다"로 받아들여 주시면 됩니다. 가이드의 신뢰는 특허가 아니라 분석의 정직함에서 나옵니다. (특허 출원 기술 / 자체 개발)

마무리

이번 주를 정리하겠습니다. 월요일엔 "세 시점이 있다"는 큰 그림을, 수요일엔 "한 시점만 보면 새는 이유"를 사례로, 그리고 오늘 금요일엔 "그래서 우리 상황에선 언제 무엇을 보면 되는가"를 한 장의 가이드로 묶었습니다. 세 글을 관통하는 메시지는 단순합니다. 시점은 셋이고, 상황마다 무게중심이 다를 뿐, 어느 경우든 하나만으로는 전체가 안 보입니다. 그러니 "다 해야 한다"는 부담을 내려놓고, "지금 우리한텐 이거 하나"부터 시작하시죠.

한 가지만 더 당부드리고 싶습니다. 오늘 가이드 표를 보고 "우리는 △ 칸이 너무 많네" 하고 위축되실 필요는 없습니다. 빈칸이 많다는 건 우리 점검이 부실하다는 뜻이 아니라, 앞으로 채워 갈 여지가 많다는 뜻입니다. 중요한 건 지금 우리 줄의 ◎ 하나를 제대로 시작하는 것이고, 그 하나를 끝내면 다음 칸이 자연스럽게 눈에 들어옵니다. 한 번에 완벽할 필요 없습니다. 한 칸씩 채워 가면 됩니다.

다음 주부터는 본격적으로 첫 번째 시점, **URL 분석(운영 시점)**으로 깊이 들어갑니다. 운영 중인 사이트를 어떻게 실물 그대로 읽어내는지, URL 하나에서 846규칙 판정까지 어떤 기술이 돌아가는지, 그 안의 두 엔진은 각각 무엇을 보는지를 하나씩 풀어 보겠습니다. 이번 주가 "세 시점의 큰 그림과 선택"이었다면, 다음 주는 "그 첫 시점을 손에 잡히게 들여다보는" 시간입니다.

오늘 가이드 표는 출력해서 책상 한쪽에 붙여 두시길 권합니다. 새 프로젝트가 시작될 때, 운영 사이트 점검 요청이 들어올 때, 분기 정기 점검 일정이 돌아올 때 — 그때마다 표를 보고 "지금 우리는 어느 줄이고, 어느 ◎부터 시작할까"를 30초 안에 정하면 됩니다. 점검을 시작할지 말지 고민하는 시간을 줄여 주는 것, 그게 이 한 장의 가장 큰 쓸모입니다. 완벽한 점검 계획을 세우느라 첫걸음을 못 떼는 것보다, 표를 보고 ◎ 하나부터 바로 시작하는 게 언제나 낫습니다.

마지막으로 오늘 글의 실천 과제를 하나로 줄이면 이것입니다. 지금 이 글을 닫기 전에, 우리 사이트가 세 줄 중 어디인지 30초만 생각해 보시죠. 새로 만드는 중인가, 운영 점검이 필요한가, 정기 관리 단계인가. 줄이 정해졌다면 그 줄의 첫 ◎가 오늘의 할 일입니다. 계획서를 쓰는 게 아니라 첫 측정을 하는 것 — 그게 이번 주 세 글이 도달하려던 결론입니다.

이번 주 세 편을 끝까지 따라와 주셔서 고맙습니다. 세 시점이라는 지도를 손에 넣으셨으니, 이제 그 지도의 첫 번째 영역을 확대해 볼 차례입니다. 다음 주 월요일, URL 분석의 안쪽에서 만나요.

krds.viewcheck.co.kr