LLM 분석이란 — 결과와 대화하는 진단

---

들어가며 — 세 번째 시점을, 이번엔 '대화'로

이번 주 월요일에는 ViewCheck가 왜 두 개의 엔진을 함께 쓰는지 이야기했습니다. 코드(DOM) 데이터를 정해진 논리로 빠르게 판정하는 규칙 엔진, 그리고 화면을 보고 코드로는 못 잡는 시각적 컴포넌트를 감지하는 시각 AI 엔진. 이 둘이 분업해서 846규칙을 판정하고, 코드가 pass/fail로 확정한 건 AI가 뒤집지 않는다는 원칙까지 짚었습니다. 그 두 엔진이 만들어내는 게 바로 "분석 결과"입니다.

오늘은 그 결과 "위에서" 벌어지는 이야기입니다. 첫 주에 웹 품질을 보는 세 가지 시점을 말씀드렸지요. 만들기 전(설계), 만든 후(운영), 그리고 그 위에서(판단). 앞의 두 시점은 지지난주 URL 분석(운영)과 지난주 Figma 분석(설계)에서 각각 풀었습니다. 오늘은 마지막 남은 세 번째 시점, 바로 판단 시점입니다. ViewCheck 용어로는 LLM 분석이라고 부릅니다.

그런데 이 세 번째 시점은 앞의 둘과 성격이 조금 다릅니다. 설계 시점과 운영 시점은 "기준에 맞나 안 맞나"를 판정합니다. 결과물이 보고서 형태로 나옵니다. 그런데 판단 시점은 그 결과를 앞에 놓고 "그래서 이게 무슨 의미인가", "우리는 뭐부터 해야 하나"를 다룹니다. 그리고 이걸 일방적인 보고서가 아니라 대화로 풀어냅니다. 오늘 글의 제목을 "결과와 대화하는 진단"이라고 붙인 이유입니다.

먼저 오해 하나를 풀고 시작하겠습니다. "LLM 분석"이라고 하면 요즘 흔히 쓰는 대화형 인공지능을 떠올리실 텐데, 그런 것과는 결정적으로 다른 지점이 하나 있습니다. 일반적인 대화형 AI는 세상의 온갖 정보를 학습해서 그럴듯한 답을 만들어냅니다. 질문을 던지면 어디선가 배운 지식을 바탕으로 답을 지어내지요. 그런데 ViewCheck의 LLM 분석은 다릅니다. 분석을 돌려서 나온, 그 사이트의 실제 데이터를 근거로 답합니다. 허공에서 그럴듯한 말을 만드는 게 아니라, 눈앞에 놓인 분석 결과를 읽고 그걸 바탕으로 대화하는 것입니다. 이 차이가 오늘 글에서 가장 강조하고 싶은 부분입니다.

왜 판단 시점을 굳이 대화로 풀었는지, 그 이유도 짧게 앞세워 두겠습니다. 앞의 두 시점은 "기준에 맞나"를 기계가 판정하는 영역이라, 사람이 끼어들 여지가 적을수록 좋습니다. 그래야 결과가 일관되니까요. 그런데 판단 시점은 다릅니다. "이게 우리에게 무슨 의미인가"는 사람마다, 기관마다 답이 갈리는 물음이라, 처음부터 사람이 개입하도록 열려 있어야 합니다. 정해진 답을 통보받는 게 아니라, 물으며 함께 찾아가는 구조가 자연스러운 것이죠. 그래서 앞의 두 시점은 자동 판정으로, 판단 시점은 대화로 — 이 형식의 차이는 우연이 아니라 각 시점의 성격에서 나온 결과입니다.

미리 짚어둘 게 있습니다. 오늘은 이번 달의 "개요 한 바퀴" 흐름을 따라, LLM 분석이 대략 무엇을 하는지 큰 그림을 잡는 데 목표를 둡니다. 판단 시점의 세부 작동 원리 — 이를테면 코드로 판단이 안 돼 N/A(해당 없음)로 빠진 항목을 어떻게 채우는지, 개선안을 어떤 방식으로 만들어내는지 — 는 이번 주 금요일 글에서 한 겹 더 들어가고, 본격적으로 깊게 파는 건 8개월차(LLM 분석 편)에서 다룹니다. 그러니 오늘은 "결과와 대화한다는 게 어떤 것이고, 왜 그게 보통의 AI 대화와 다른가"를 잡고 가시면 충분합니다.

---

본론 1 — "결과와 대화한다"가 무슨 뜻인가

분석이 끝난 자리에서 시작한다

LLM 분석의 첫 번째 특징은, 그것이 "무에서 시작하지 않는다"는 것입니다. 대화가 시작되는 지점은 언제나 이미 분석이 한 번 돌아간 다음입니다.

순서를 그려보겠습니다. 사용자가 주소 한 줄을 넣거나 디자인 파일을 올려 분석을 돌립니다. 그러면 두 엔진이 846규칙을 판정하고, 접근성·반응형·성능·보안 같은 여러 영역을 함께 훑어서 결과를 내놓습니다. 여기까지가 운영 시점과 설계 시점의 일입니다. 그런데 이 결과를 받아 든 담당자의 머릿속에는 대개 질문이 남습니다. "이게 다 무슨 뜻이지?", "이 중에 뭐가 진짜 급한 거지?", "이 위반은 왜 문제라는 거지?" LLM 분석은 바로 이 질문들이 시작되는 자리에서 문을 엽니다.

그래서 LLM 분석은 "결과를 대신 만드는 것"이 아니라 "이미 나온 결과를 함께 읽는 것"에 가깝습니다. 이 구분이 중요합니다. 판단 시점이 앞의 두 시점을 대체하는 게 아니라 그 위에 얹힌다는 첫 주의 이야기가, 여기서 구체적인 모습을 갖춥니다. 토대가 되는 데이터는 규칙 엔진과 시각 AI가 이미 깔아두었고, LLM 분석은 그 데이터를 앞에 놓고 사람과 대화하며 "그래서 무엇을 어떻게"를 함께 풀어가는 것이죠.

이게 왜 자연스러운 설계인지 조금 더 풀어보겠습니다. 분석 결과라는 건, 솔직히 말해 그 자체로는 읽기가 만만치 않습니다. 846개 규칙의 판정, 수십 곳의 위반 위치, 여러 영역의 점수가 한꺼번에 쏟아지니까요. 웹 전문가가 아닌 담당자분께 이걸 통째로 건네면, "숫자는 많은데 그래서 뭘 하라는 건지 모르겠다"가 되기 쉽습니다. 첫 주에 말씀드린 "위반 200건을 받았지만 손도 못 댄" 그 상황이 정확히 이 지점입니다. 데이터가 부족해서가 아니라, 데이터를 행동으로 옮길 판단이 빠져서 멈추는 것이죠. LLM 분석은 그 멈춤을 푸는 쪽에 있습니다. 결과 더미를 앞에 두고 "여기서 제일 급한 것부터 알려주세요"라고 물으면, 그 사이트의 실제 판정을 근거로 답을 정리해 줍니다.

왜 하필 '대화'인가

여기서 한 가지 물으실 수 있습니다. "우선순위를 정리해 주는 거라면, 그냥 보고서로 쫙 뽑아주면 되지 왜 굳이 대화 형태인가?" 좋은 질문입니다. 실제로 ViewCheck는 종합 보고서도 만들어냅니다. 그런데 보고서만으로는 채워지지 않는 게 있습니다. 바로 "사람마다 궁금한 지점이 다르다"는 사실입니다.

일방적인 보고서는 만든 사람이 정한 순서와 깊이로 흘러갑니다. 잘 만든 보고서라도, 읽는 사람의 그 순간 궁금증에 정확히 맞아떨어지기는 어렵습니다. 어떤 담당자는 "접근성 위반이 왜 이렇게 많은지"가 궁금하고, 어떤 담당자는 "예산이 한정돼 있는데 뭐부터 손대야 하는지"가 급하고, 또 어떤 분은 "이 항목은 우리가 일부러 그렇게 한 건데 그래도 위반인지"를 확인하고 싶어 합니다. 이 서로 다른 질문에 보고서 한 장이 다 답하기는 힘듭니다.

대화는 이 지점을 메웁니다. 궁금한 걸 그 자리에서 물으면, 그 질문에 맞춰 답이 나옵니다. 그리고 답을 듣고 또 궁금한 게 생기면 이어서 물을 수 있습니다. "제일 급한 게 A라고 하셨는데, A는 왜 그렇게 급한가요?", "그럼 A를 고치려면 대략 어느 정도 일인가요?" 이렇게 파고들 수 있는 것이죠. 정해진 순서를 따라가는 게 아니라, 사람의 관심을 따라 흘러갑니다. 이게 보고서와 대화의 결정적 차이입니다.

여러 번 주고받는다는 것

그래서 LLM 분석은 한 번 묻고 한 번 답하고 끝나는 방식이 아닙니다. 여러 번 주고받는 대화를 지원합니다. 이게 생각보다 중요합니다.

한 번의 질문과 답으로 끝난다면, 그건 사실 검색과 크게 다르지 않습니다. 그런데 진짜 진단이라는 건 원래 주고받으며 좁혀 들어가는 과정입니다. 병원에서 의사가 "어디가 아프세요?" 한 번 묻고 처방을 내리는 게 아니라, "언제부터 그랬나요", "이럴 때도 아픈가요", "예전에 이런 적 있었나요"를 이어가며 원인에 다가가는 것과 비슷합니다. 웹 품질 진단도 그렇습니다. "우리 사이트 문제가 뭔가요"라는 큰 질문에서 출발해, "그중 접근성이 왜 문제인가요", "그 접근성 위반이 어느 페이지에 몰려 있나요", "그럼 그 페이지부터 고치면 되나요"로 점점 좁혀 들어갈 때 진짜 쓸모 있는 답이 나옵니다.

여러 번 주고받는다는 건, 앞의 대화를 이어받아 다음 답을 한다는 뜻이기도 합니다. "그럼 그 페이지부터 고치면 되나요"라고 물었을 때, 바로 앞에서 이야기한 "접근성 위반이 몰린 페이지"가 무엇인지를 기억하고 답하는 것이죠. 매번 처음부터 설명을 다시 해야 한다면 대화라고 부르기 어렵습니다. 맥락이 이어지기 때문에, 사람은 짧게 물어도 되고 대화는 점점 구체적인 곳으로 내려갑니다. 큰 데서 작은 데로, 두루뭉술한 데서 실행 가능한 데로 좁혀지는 이 흐름이 진단의 본질에 맞닿아 있습니다.

정리하면, LLM 분석은 "이미 나온 분석 결과를, 사람의 질문을 따라, 여러 번 주고받으며 함께 읽어가는" 방식입니다. 결과를 대신 만드는 게 아니라 결과를 함께 소화하는 것, 정해진 순서가 아니라 사람의 관심을 따라가는 것, 한 번이 아니라 이어가며 좁히는 것. 이 세 가지가 "결과와 대화한다"는 말의 실체입니다.

결과를 '통째로 읽는 것'과 '대화로 좁히는 것'

같은 분석 결과를 앞에 두고도, 그걸 통째로 읽는 것과 대화로 좁혀 들어가는 것은 체감이 완전히 다릅니다. 이 차이를 조금 더 그려보겠습니다.

분석 결과를 통째로 마주하는 건, 두꺼운 진단서를 처음부터 끝까지 정독하는 것과 비슷합니다. 성실한 방법이긴 합니다만, 웹을 잘 모르는 담당자에게는 첫 장을 넘기기도 전에 지치는 일입니다. 846규칙의 판정이 카테고리별로 늘어서 있고, 위반 위치가 페이지마다 흩어져 있고, 영역별 점수가 각기 다른 기준으로 매겨져 있으니까요. 어디가 시작이고 어디가 핵심인지, 무엇을 건너뛰어도 되는지가 한눈에 안 잡힙니다. 그래서 정독을 시도하다 중간에 덮어버리는 경우가 많습니다.

대화로 좁히는 건 정반대 방향입니다. 두꺼운 진단서를 통째로 읽는 대신, "제일 중요한 게 뭐죠?"라고 먼저 물어 핵심으로 곧장 들어가는 것이죠. 그 답을 듣고 나서 관심 가는 곳만 골라 더 파고듭니다. 필요 없는 부분은 지나치고, 궁금한 부분만 깊게 봅니다. 결과 전체를 다 읽지 않아도, 지금 나에게 필요한 판단에 이르는 길이 훨씬 짧아집니다. 방대한 데이터를 다 소화해야 한다는 부담이, "궁금한 걸 물으면 된다"는 가벼움으로 바뀌는 것입니다.

물론 이게 "결과를 대충 봐도 된다"는 뜻은 아닙니다. 정밀한 데이터는 그대로 다 남아 있고, 필요하면 언제든 근거를 따라 그 상세로 내려갈 수 있습니다. 다만 그 방대한 데이터에 이르는 입구를, 정독이 아니라 대화로 열어둔 것이죠. 데이터의 깊이는 유지하되 접근의 문턱은 낮추는 것 — 이게 대화라는 형식이 진단에 주는 실질적인 이점입니다.

---

본론 2 — 핵심은 '근거를 달고 답한다'는 것

여기가 오늘 글의 심장입니다. 앞에서 "보통의 AI 대화와 결정적으로 다르다"고 한 그 지점을 자세히 풀겠습니다.

"그럴듯하게 말하는 것"과 "데이터를 근거로 말하는 것"

요즘 대화형 인공지능을 한 번쯤 써보셨을 겁니다. 무엇을 물어도 막힘없이, 자신 있게 답을 내놓습니다. 문장도 매끄럽고 그럴듯합니다. 그런데 여기에 잘 알려진 함정이 하나 있습니다. 그 답이 맞는지 아닌지를 그 자리에서 확인하기 어렵다는 것입니다. 자신 있게 말하지만, 그 근거가 무엇인지는 대개 보이지 않습니다. 때로는 실제로 존재하지 않는 걸 사실인 양 지어내기도 합니다. 문장이 매끄러울수록 오히려 검증하기가 더 어렵습니다. 그럴듯함이 판단을 흐리니까요.

공공 웹 품질 진단에서는 이게 치명적입니다. 담당자가 "우리 사이트 접근성이 왜 문제인가요"라고 물었는데, AI가 그냥 일반론으로 "공공 사이트는 접근성이 중요하며 대체텍스트와 키보드 접근성을 지켜야 합니다"라고 그럴듯하게 답한다면, 그건 우리 사이트 이야기가 아닙니다. 어디서나 통하는 교과서적인 말일 뿐이지요. 정작 담당자가 알고 싶은 건 "우리 사이트의, 어느 페이지의, 어떤 요소가, 어떤 규칙에 걸렸는지"입니다.

ViewCheck의 LLM 분석은 정확히 이 지점에서 갈라집니다. 답이 허공에서 나오지 않습니다. 그 사이트를 실제로 분석해서 나온 데이터를 근거로 삼습니다. "접근성이 왜 문제인가요"라고 물으면, 일반론이 아니라 "이 사이트의 이 페이지에서, 이러이러한 규칙이 미통과로 판정됐고, 그게 이런 사용자에게 이런 영향을 준다"는 식으로, 실제 판정 결과에 뿌리를 두고 답합니다. 같은 질문이라도 사이트마다 답이 다릅니다. 당연합니다. 사이트마다 실제 데이터가 다르니까요.

답 옆에 근거가 함께 붙는다

말로만 "데이터를 근거로 한다"고 하면 여전히 미덥지 않을 수 있습니다. 그래서 ViewCheck의 LLM 분석은 답을 낼 때 그 답이 무엇에 기댔는지를 함께 보여줍니다. 어떤 규칙, 어떤 판정 결과를 근거로 했는지가 답변 곁에 표시되는 것이죠. 이걸 근거 표시, 혹은 참조 표시라고 부릅니다.

이게 왜 결정적이냐면, 근거가 보이는 순간 답을 "확인할 수 있게" 되기 때문입니다. AI가 "이 항목이 제일 급합니다"라고 말했을 때, 그 옆에 "왜냐하면 이 규칙이 이렇게 걸렸기 때문"이라는 근거가 붙어 있으면, 사람은 그 근거를 직접 눌러 확인할 수 있습니다. "아, 정말 이 규칙이 이 페이지에서 걸렸네" 하고 두 눈으로 볼 수 있는 것이죠. 답을 그냥 믿는 게 아니라, 근거를 따라가 검증할 수 있습니다. 이게 "그럴듯한 말"과 "근거 있는 답"을 가르는 실질적인 장치입니다.

첫 주에 말씀드린 이야기와 이어집니다. 그때 "준수율이라는 숫자가 신뢰를 가지려면, 그 숫자가 왜 나왔는지를 규칙 하나하나까지 거슬러 올라가 설명할 수 있어야 한다"고 했습니다. "설명되지 않는 점수는 숫자일 뿐, 근거가 아니다"라고도 했지요. LLM 분석의 근거 표시가 바로 그 정신을 대화에까지 이어주는 장치입니다. 답변도 마찬가지입니다. 근거가 따라붙지 않는 답은 그럴듯한 말일 뿐, 진단이 아닙니다. 답에서 근거로, 결론에서 데이터로 거슬러 올라갈 수 있어야 비로소 "이 답을 믿고 보고에 쓸 수 있다"가 됩니다.

왜 이게 공공 진단에서 특히 중요한가

근거가 붙는다는 게 실무에서 얼마나 큰지 조금 더 풀어보겠습니다. 공공기관의 웹 담당자분은 자기 선에서 판단을 끝내는 경우가 드뭅니다. 위로 보고를 하고, 예산을 요청하고, 개발사와 협의를 합니다. 그 모든 자리에서 "왜?"라는 질문이 따라옵니다. "이걸 왜 고쳐야 하죠?", "이게 왜 제일 급하다는 거죠?", "근거가 뭐죠?"

이때 "AI가 그렇게 말했습니다"라고 답하면 보고가 거기서 막힙니다. 그런데 "이 규칙이 이 페이지에서 이렇게 걸렸고, 그 근거 화면이 여기 있으며, 이 위반은 이런 사용자를 배제합니다"라고 답하면 이야기가 다음 단계로 넘어갑니다. "그래서 언제까지 어떻게 고칠 것인가"로 논의가 진전되는 것이죠. 근거가 추적되는 답은 회의 시간을 줄이고, 담당자가 방어에 쓰는 부담을 덜어줍니다. 첫 주에 보고서를 두고 했던 이 이야기가, 대화형 진단에서도 똑같이 성립합니다.

반대로 근거 없는 답은, 아무리 그럴듯해도 보고 자리에서는 힘을 못 씁니다. 공공 영역은 세금으로 운영되고, 그래서 모든 판단에 근거를 요구합니다. "감으로", "AI가 그렇다니까"는 통하지 않습니다. LLM 분석이 근거를 답에 함께 붙이도록 설계된 건, 바로 이 공공 영역의 요구를 정면으로 마주한 결과입니다. 그럴듯함이 아니라 검증 가능성을 택한 것이죠.

구체적인 장면으로 한 번 더 그려보겠습니다. 담당자가 "우리 사이트에서 제일 급한 게 뭐죠?"라고 물었다고 해봅시다. 근거 없이 답하는 도구라면 "접근성을 먼저 챙기시는 게 좋습니다" 정도로 끝날 것입니다. 틀린 말은 아니지만, 이걸 받아서 무엇을 할 수 있는지는 여전히 막막합니다. 반면 근거를 붙이는 LLM 분석은 "이 사이트에서는 신청 페이지의 어떤 위반이 가장 무겁게 잡혔고, 그건 화면을 못 보는 사용자가 신청 자체를 완료하지 못하게 만들며, 위험도가 가장 높은 등급으로 분류됐다"는 식으로, 실제 판정을 짚어 답합니다. 그리고 그 옆에 "이 결론은 이 규칙, 이 페이지의 이 판정에 기댔다"는 근거가 붙습니다. 담당자는 그 근거를 눌러 "정말 그런지" 두 눈으로 확인하고, 그대로 보고 자료에 옮길 수 있습니다. 같은 질문에 대한 답인데, 하나는 흘려듣고 마는 말이고 다른 하나는 그대로 실행에 옮길 수 있는 재료입니다. 근거가 붙느냐 아니냐가 이 차이를 만듭니다.

한 가지 더 솔직하게 짚겠습니다. "근거를 붙인다"고 해서 AI의 모든 답이 100퍼센트 완벽하다는 뜻은 아닙니다. AI는 여전히 판단을 돕는 도구이지, 판단을 대신하는 최종 결재자가 아닙니다. 다만 근거가 붙어 있으면, 사람이 그 근거를 확인하며 답의 신뢰도를 스스로 가늠할 수 있습니다. 근거가 탄탄하면 그대로 받아들이고, 근거가 약하면 걸러낼 수 있는 것이죠. 근거 표시의 진짜 값어치는 "AI를 무조건 믿게 만드는 것"이 아니라 "AI의 답을 사람이 검증할 수 있게 만드는 것"에 있습니다. 이 차이가 오래 신뢰받는 도구와 한 번 쓰고 마는 도구를 가릅니다.

---

본론 3 — 대화 중에 그 자리에서 다시 확인한다

세 번째로 짚을 기능은 "대화 중 재분석"입니다. 이것도 보통의 AI 대화에는 없는, ViewCheck LLM 분석만의 특징입니다.

궁금하면 다시 돌려본다

대화를 하다 보면 이런 순간이 옵니다. "잠깐, 이 부분은 지금 다시 한번 확인해봐야겠는데?" 예를 들어 답을 듣다가 특정 규칙의 판정이 정말 맞는지 궁금해지거나, 어떤 페이지를 콕 집어 다시 보고 싶어지는 경우입니다. 보통의 AI 대화라면 여기서 막힙니다. AI는 이미 학습한 것과 대화에 주어진 정보 안에서만 답할 수 있으니까요. 새로 확인할 방법이 없습니다.

그런데 ViewCheck의 LLM 분석은 대화 도중에 그 자리에서 다시 분석을 돌리거나 특정 규칙을 재확인하도록 할 수 있습니다. "이 부분 다시 확인해 주세요"라고 하면, 이미 나와 있는 결과를 되풀이해 읽는 데 그치지 않고 실제로 다시 들여다보는 것이죠. 그리고 그 재확인 결과를 근거로 대화를 이어갑니다. 대화가 정적인 게 아니라, 필요하면 새 데이터를 그 자리에서 끌어오는 셈입니다.

이게 왜 유용한지 장면으로 그려보겠습니다. 담당자가 "우리 사이트에서 제일 급한 게 뭐죠?"라고 물어 답을 받았습니다. 그런데 그 답에 나온 어떤 위반이 "정말 지금도 그런지" 확신이 안 섭니다. 사이트를 최근에 조금 손봤을 수도 있으니까요. 이럴 때 "그 항목을 지금 다시 확인해 주세요"라고 하면, 그 자리에서 다시 확인해 최신 상태로 답을 갱신할 수 있습니다. 결과를 받아 든 시점과 대화하는 시점 사이의 간극을, 재확인으로 메우는 것입니다.

또 다른 쓸모도 있습니다. 개선 작업을 하다 보면 "방금 고쳤는데 이게 제대로 반영됐을까?"가 궁금해지는 순간이 옵니다. 예전 같으면 처음부터 분석을 통째로 다시 돌리고, 그 방대한 결과를 또 뒤져 해당 항목을 찾아야 했습니다. 번거로우니 확인을 미루게 되고, 미루다 보면 고친 게 정말 반영됐는지 모른 채 넘어가기 쉽습니다. 그런데 대화 중에 특정 규칙만 콕 집어 재확인할 수 있으면, "그 항목 하나만 지금 다시 봐 달라"고 해서 바로 결과를 받을 수 있습니다. 고친 것을 그 자리에서 확인하고 다음 작업으로 넘어가는 흐름이 만들어지는 것이죠. 진단과 개선이 별개의 큰 덩어리로 뚝뚝 끊기는 게 아니라, 대화 안에서 촘촘히 맞물려 돌아갑니다.

"고정된 결과"가 아니라 "살아 있는 진단"

이 재분석 기능이 주는 진짜 의미는, LLM 분석이 "한 번 찍어낸 고정된 결과"를 읽어주는 데 그치지 않는다는 데 있습니다. 필요하면 그 자리에서 다시 확인하니까, 대화가 진행되는 동안 진단이 계속 살아 있는 셈입니다.

첫 주와 지지난주에 "같은 주소를 같은 기준으로 언제든 다시 넣을 수 있다"는 반복 가능성을 강조했습니다. 사람의 점검은 매번 일회성이라 어제와 오늘을 비교하기 어렵지만, 기계는 같은 방식으로 다시 볼 수 있다고 했지요. LLM 분석의 재분석은 그 반복 가능성을 "대화 안으로" 들여온 것입니다. 궁금할 때마다, 대화의 흐름을 끊지 않고, 그 자리에서 다시 볼 수 있습니다. 진단이 대화의 리듬을 따라 갱신되는 것이죠.

다만 여기서도 경계를 분명히 해두겠습니다. "그 자리에서 다시 확인한다"는 게 "무엇이든 무한정 다시 만들어낸다"는 뜻은 아닙니다. 재확인이 닿는 범위는 어디까지나 분석이 다룰 수 있는 영역 안입니다. 로그인 안쪽처럼 애초에 접근이 제한된 곳이나, 사람의 최종 판단이 필요한 맥락은 재분석만으로 해결되지 않습니다. 이 경계에 대해서는 뒤에서 다시 솔직하게 짚겠습니다. 지금은 "대화 도중에도 필요하면 새로 확인할 수 있다"는 특징만 잡고 가시면 됩니다.

---

본론 4 — 눈높이를 맞추고, 빠르게 답한다

LLM 분석에는 대화를 더 쓸모 있게 만드는 두 가지 편의가 더 있습니다. 설명 수준을 조절하는 것, 그리고 간단한 질문에 빠르게 답하는 흐름입니다.

쉬운 말로도, 전문가 말로도

앞에서 공공기관 담당자분이 대부분 웹 전문가가 아니라는 이야기를 했습니다. 지지난주 URL 분석 편에서도 짚었지요. 행정 업무를 보다가 홈페이지 관리까지 겸하는 분이 많고, 그런 분들께 전문 용어로 가득한 답을 내밀면 시작조차 막막합니다. 반대로, 웹을 잘 아는 개발자나 디자이너가 대화 상대일 때 지나치게 풀어 쓴 설명만 나오면 답답합니다. 이미 아는 걸 길게 설명하니까요.

그래서 LLM 분석은 설명 수준을 조절할 수 있습니다. 쉬운 말 모드에서는 전문 용어를 최대한 풀어서, 웹을 모르는 분도 이해할 수 있게 답합니다. "ARIA 속성이 누락됐습니다" 대신 "화면을 못 보는 분이 쓰는 보조기기가 이 버튼의 이름을 읽지 못합니다"처럼요. 전문가 모드에서는 군더더기 없이 정확한 용어로, 개발자가 바로 작업에 착수할 수 있게 답합니다. 같은 위반이라도 받는 사람에 맞춰 설명의 옷을 갈아입는 것이죠.

이게 사소해 보여도 실무에서는 꽤 큽니다. 하나의 진단 결과를 두고, 담당자는 쉬운 말로 이해해서 윗선에 보고하고, 개발사는 전문가 말로 받아서 바로 고칠 수 있습니다. 같은 데이터를 두 언어로 번역해 주는 셈입니다. 사람이 그 사이에서 통역하느라 쓰던 수고가 줄어듭니다. 그리고 어느 쪽으로 설명하든 바탕이 되는 근거는 같습니다. 설명의 눈높이만 달라질 뿐, 그 아래 데이터는 흔들리지 않습니다.

간단한 건 빠르게

LLM 분석에는 간단한 질문에 빠르게 답하는 흐름도 있습니다. 모든 질문이 깊은 분석을 필요로 하는 건 아니니까요. "이 점수가 무슨 뜻이죠?", "이 용어가 뭐예요?" 같은 가벼운 질문에는 무겁게 다시 파고들 필요 없이 빠르게 답하는 게 낫습니다.

이건 대화의 리듬을 위해 필요한 배려입니다. 사람이 진단 결과를 소화하는 과정에는 큰 질문과 작은 질문이 섞여 있습니다. "우리 사이트 전체에서 뭐가 제일 문제인가"라는 큰 질문도 있고, "그런데 방금 그 용어가 무슨 뜻이더라"라는 짧은 확인도 있습니다. 작은 질문에까지 매번 무거운 분석이 돌면 대화가 답답해집니다. 그래서 가벼운 건 가볍게, 깊은 건 깊게 흘러가도록 되어 있습니다. 사람이 실제로 대화하는 방식에 가깝게 맞춘 것이죠.

하나의 진단, 여러 사람의 언어

이 눈높이 조절이 실무에서 어떻게 작동하는지 한 장면으로 정리해 보겠습니다. 웹 품질 진단 결과 하나를 두고, 실제로는 여러 사람이 각기 다른 목적으로 그걸 들여다봅니다. 담당자는 "내가 이걸 이해해서 위에 설명해야" 하고, 기관장은 "핵심만 30초 안에" 파악하려 하고, 개발사는 "정확히 뭘 고치면 되는지"를 알고 싶어 합니다. 세 사람이 원하는 언어가 다 다릅니다.

예전 같으면 이 통역을 사람이 다 떠맡았습니다. 담당자가 전문 데이터를 붙들고 끙끙대며 쉬운 말로 옮겨 보고서를 쓰고, 다시 개발사에는 기술 용어로 정리해 전달하고 — 그 사이에서 오역과 누락이 생겼습니다. 옮기는 과정에서 근거가 떨어져 나가기도 하고, 강조점이 엉뚱하게 바뀌기도 했습니다. LLM 분석의 눈높이 조절은 이 통역 부담을 덜어줍니다. 같은 진단을 두고, 필요에 따라 쉬운 말로도 전문가 말로도 다시 받을 수 있으니까요. 중요한 건 어느 언어로 옮기든 그 아래 근거는 동일하다는 점입니다. 표현만 바뀔 뿐, 근거가 되는 데이터는 세 사람 모두에게 같습니다. 그래서 "담당자가 이해한 것"과 "개발사가 받은 것"이 서로 어긋나지 않습니다. 통역은 유연하되 원본은 하나인 구조, 이게 진단 결과를 여러 이해관계자가 함께 쓰게 만드는 열쇠입니다.

정리하면, LLM 분석은 근거 있는 답이라는 뼈대 위에 "눈높이 조절"과 "빠른 응답"이라는 편의를 얹었습니다. 근거는 흔들리지 않게 붙잡되, 그 근거를 전하는 방식은 사람과 상황에 맞춰 유연하게 바꾸는 것입니다. 딱딱한 진단 결과가 사람의 언어로, 사람의 리듬으로 건네지는 자리입니다.

---

본론 5 — LLM 분석이 잘하는 것과, 솔직한 경계

여기까지 읽으면 LLM 분석이 만능처럼 들릴 수 있는데, 그러면 첫 주부터 내내 경계해 온 "한 시점만 보고 안심하는" 함정을 똑같이 만드는 셈입니다. 그래서 LLM 분석이 무엇을 잘하고 무엇은 못 하는지, 그 경계를 솔직하게 짚겠습니다.

잘하는 것 — 데이터를 판단할 거리로 바꾼다

LLM 분석이 가장 잘하는 건, 앞의 두 시점이 깔아둔 데이터를 "사람이 판단할 수 있는 형태"로 바꿔주는 것입니다. 규칙 엔진과 시각 AI가 내놓은 결과는 정확하지만, 그 자체로는 방대하고 건조합니다. LLM 분석은 그 위에서 "그래서 무엇이 중요한지", "왜 그런지", "무엇부터 하면 좋은지"를 대화로 풀어냅니다. 데이터를 없애는 게 아니라, 데이터를 소화할 수 있게 도와주는 것이죠.

특히 우선순위를 매기는 데 강합니다. 첫 주에 봤듯, 위반 수백 건을 그냥 나열하면 받는 사람은 막막합니다. "다 고쳐야 한다"는 사실상 "아무것도 안 고친다"가 되기 쉽습니다. LLM 분석은 위험도(P0~P3)로 등급화된 데이터를 근거로, "이것부터"라는 순서를 대화로 정리해 줍니다. 막막함을 순서로 바꾸는 것, 이게 판단 시점이 데이터를 행동으로 잇는 지점입니다.

경계 ① — 토대가 부실하면 판단도 부실하다

첫 번째 경계는 가장 근본적입니다. LLM 분석은 앞의 두 시점이 깔아준 데이터 "위에서" 작동합니다. 그러니 토대가 되는 그 데이터가 부실하면, 그 위의 판단도 부실해집니다. 잘못 수집된 화면, 부정확한 판정 위에서 아무리 그럴듯하게 대화해봐야 결론은 틀립니다. 첫 주에 "AI가 아무리 그럴듯해도, 잘못 수집된 화면을 보고 판단하면 결론도 틀린다"고 한 그대로입니다.

그래서 LLM 분석은 URL 분석과 Figma 분석을 대체하는 게 아니라, 그 위에 반드시 얹혀야 하는 것입니다. 판단 시점 하나만 떼어내 "AI한테 물어보면 다 해결된다"고 하면, 그거야말로 또 하나의 "한 시점만 보기"입니다. 세 시점이 다 필요하다는 이야기가, LLM 분석 편에서도 똑같이 성립합니다. 오히려 판단 시점이야말로 앞의 두 시점에 가장 크게 기대는 시점입니다.

경계 ② — 최종 판단은 결국 사람의 몫

두 번째 경계입니다. LLM 분석은 판단을 "돕는" 것이지 판단을 "대신하는" 게 아닙니다. "이 위반이 우리 기관 맥락에서 얼마나 급한지", "이건 규칙은 어겼지만 의도된 예외인지", "한정된 예산에서 무엇을 먼저 할지" 같은 최종 결정은 여전히 사람의 몫입니다. LLM 분석은 그 결정에 필요한 재료를 근거와 함께 잘 정리해서 갖다주는 쪽에 가깝습니다.

이건 한계라기보다 올바른 역할 분담입니다. 기관마다 사정이 다르고, 예산도 다르고, 우선하는 가치도 다릅니다. AI가 데이터로 "이게 규칙상 제일 심각합니다"라고 짚어줄 수는 있어도, "우리 기관은 이번 분기엔 저것부터 하기로 한다"는 결정은 그 조직의 사람이 내려야 합니다. LLM 분석은 그 결정을 흐리지 않습니다. 오히려 단순 확인 작업에 묻혀 있던 사람의 판단력을, 진짜 결정에 쓰도록 되돌려주는 쪽입니다.

경계 ③ — 못 보는 영역은 여전히 못 본다

세 번째 경계입니다. LLM 분석이 대화로 근거 있는 답을 준다고 해서, 앞의 두 시점이 못 보던 영역까지 갑자기 보게 되는 건 아닙니다. 지지난주 URL 분석 편에서 짚은 한계들 — 로그인 안쪽 페이지, 눌러봐야 나오는 복잡한 상호작용 — 은 LLM 분석에서도 그대로입니다. 애초에 수집되지 않은 데이터를 대화로 만들어낼 수는 없으니까요.

이걸 분명히 하는 이유가 있습니다. 대화가 매끄러우면, 마치 AI가 모든 걸 다 아는 것처럼 느껴지기 쉽습니다. 그런데 LLM 분석이 아는 건 어디까지나 "분석이 실제로 다룬 범위"까지입니다. 그 범위 밖을 물으면, 솔직하게 "그건 이 분석에서 다루지 않았다"고 하는 게 맞습니다. 모르는 걸 그럴듯하게 지어내지 않는 것 — 근거에 기대 답한다는 원칙은, 뒤집으면 근거가 없는 곳에서는 함부로 단정하지 않는다는 뜻이기도 합니다. 이 정직함이 없으면, 근거를 붙이는 의미도 사라집니다.

이 경계들을 굳이 적는 이유는 첫 주부터 한결같습니다. LLM 분석이 강한 영역(데이터를 근거로, 대화로, 판단할 거리로 바꾸는 것)은 분명한데, 그게 전부인 척하면 오히려 신뢰가 깨지니까요. 잘하는 걸 잘한다고 하고, 못 하는 건 다른 시점이 메우거나 사람이 맡는다고 하는 것. LLM 분석도 그 틀 안에 있습니다.

---

본론 6 — 실무에서 LLM 분석은 언제, 어떻게 쓰나

개념은 그렇고, 실무에서는 어떤 순간에 LLM 분석을 꺼내 쓰게 될까요. 몇 가지 상황으로 나눠 보겠습니다.

결과를 받았는데 막막할 때

가장 흔한 순간입니다. URL 분석이나 Figma 분석을 돌려 결과를 받았는데, 위반이 잔뜩 나와서 어디서부터 봐야 할지 막막한 상황입니다. 이럴 때 "여기서 제일 급한 것부터 알려주세요"라고 물으면, 그 사이트의 실제 판정을 근거로 우선순위를 정리해 줍니다. 방대한 결과를 통째로 붙들고 씨름하는 대신, 대화로 핵심에 먼저 다가가는 것이죠. 첫 주에 "위반 200건을 받고 손도 못 대던" 그 상황을 푸는 자리가 바로 여기입니다.

위로 보고해야 할 때

담당자가 상급자나 기관장께 보고해야 하는 상황도 많습니다. 이때 "이게 왜 문제인지", "고치면 어떤 효과가 있는지"를 설득력 있게 정리해야 하는데, 전문 데이터를 그대로 올리면 잘 전달되지 않습니다. LLM 분석에 "이 위반을 비전문가도 이해하게 설명해 주세요"라고 하면, 쉬운 말로 풀어줍니다. 그리고 그 설명에 근거가 붙어 있으니, "근거가 뭐냐"는 질문에도 바로 답할 수 있습니다. 보고 자리에서 막히지 않는 것, 이게 근거 있는 대화의 실무적 값어치입니다.

개발사와 협의할 때

반대로 개발사나 외주 업체와 실제 수정을 협의할 때는 전문가 모드가 유용합니다. "이 항목들을 개발자가 바로 작업할 수 있게 정리해 주세요"라고 하면, 정확한 용어로 무엇을 어떻게 고쳐야 하는지를 짚어줍니다. 발주처가 "다 됐습니다"라는 말을 그대로 믿는 대신, 근거를 손에 쥐고 협의에 임할 수 있습니다. 지지난주에 URL 분석을 "검수의 마지막 관문"이라고 했는데, LLM 분석은 그 검수 결과를 두고 개발사와 대화하는 자리까지 이어줍니다.

한 항목이 정말 문제인지 따져볼 때

"이 위반은 우리가 일부러 그렇게 한 건데, 그래도 문제인가?" 이런 확인이 필요한 순간도 있습니다. 이럴 때 그 항목을 두고 대화하며, 필요하면 그 자리에서 다시 확인해 볼 수 있습니다. 규칙상 위반으로 잡혔더라도, 그게 우리 기관 맥락에서 실제로 고쳐야 할 일인지 아닌지는 사람이 판단해야 하는데, LLM 분석은 그 판단에 필요한 근거를 대화로 정리해 줍니다. 최종 결정은 사람이 내리되, 그 결정의 재료를 잘 갖춰주는 것이죠.

공통점 — 언제나 '결과 다음'이다

이 상황들에는 공통점이 있습니다. LLM 분석은 언제나 "분석 결과가 나온 다음"에 등장합니다. 결과 없이 LLM 분석부터 시작하는 경우는 없습니다. 이게 판단 시점의 자리를 정확히 말해줍니다. 앞의 두 시점이 깔아준 데이터가 있어야, 그 위에서 대화가 의미를 갖습니다. 그래서 LLM 분석은 세 시점의 마지막에 오고, 앞의 둘을 대체하지 않으며, 그 위에 얹혀 "발견 → 이해 → 개선"의 마지막 두 단계(이해와 개선)를 잇습니다.

한 가지 덧붙이면, 이 네 가지 상황은 실제로는 하나의 흐름 안에서 자연스럽게 이어지는 경우가 많습니다. 결과를 받아 막막할 때 우선순위를 물어 핵심을 잡고, 그 핵심을 쉬운 말로 정리해 위에 보고하고, 보고에서 승인이 나면 전문가 말로 바꿔 개발사와 협의하고, 협의 중에 애매한 항목은 그 자리에서 다시 확인해 따져보는 식입니다. 막막함에서 시작해 보고, 협의, 확인으로 이어지는 이 한 흐름이 전부 같은 대화 안에서, 같은 근거 위에서 굴러갑니다. 상황마다 다른 도구를 꺼내 드는 게 아니라, 하나의 대화가 상황을 따라 옷을 갈아입는 셈입니다. 그래서 LLM 분석은 "특정 순간에만 쓰는 기능"이라기보다, 결과를 받아 든 뒤 개선에 이르기까지 곁에서 함께 걷는 동반자에 가깝습니다.

---

그래서 ViewCheck는

ViewCheck의 LLM 분석이 바로 이 판단 시점을 담당합니다. URL 분석과 Figma 분석이 깔아둔 결과를 앞에 놓고, 사용자와 대화하며 진단을 돕습니다. "이 위반이 왜 문제죠?", "제일 급한 것부터 알려주세요"라고 물으면, 그 사이트의 실제 분석 데이터를 근거로 답합니다. 답 옆에는 어떤 규칙, 어떤 판정을 근거로 했는지가 함께 붙고, 궁금하면 그 자리에서 다시 확인할 수 있으며, 설명은 쉬운 말로도 전문가 말로도 갈아입습니다. 위에서 본 실화면들이 그 결과물입니다.

거창하게 들릴 수 있는데, 결국 첫 주에 짚은 세 번째 시점을 대화로 푸는 것뿐입니다. 사람이 방대한 결과 앞에서 막막해하던 걸, 근거 있는 대화로. 그리고 그 대화가 허공의 그럴듯한 말이 아니라 실제 데이터에 뿌리를 두게 함으로써, "AI가 그럴듯하게 말하는 것"과 "데이터를 근거로 말하는 것"의 경계를 분명히 그은 것입니다.

한 가지만 다시 강조하고 싶습니다. LLM 분석의 가치는 "AI와 대화할 수 있다"에 있지 않습니다. 대화형 AI는 이제 흔합니다. LLM 분석의 진짜 가치는 "그 대화가 우리 사이트의 실제 분석 데이터에 근거하고, 그 근거가 답에 함께 붙어 검증 가능하다"는 데 있습니다. 그럴듯한 말은 어디서나 들을 수 있지만, 우리 사이트의 실제 판정을 근거로, 확인 가능한 형태로 답하는 대화는 흔하지 않습니다. 그러니 LLM 분석을 "AI 챗봇이 하나 달렸구나" 정도로 이해하면 절반만 이해한 것입니다. "분석 데이터를 근거로 검증 가능하게 대화하는 진단"으로 이해해야 이 시점의 진짜 값어치가 보입니다.

오늘은 큰 그림만 봤습니다. "분석 결과를 앞에 놓고, 근거를 달아, 대화로 판단을 돕는다" 정도입니다. 이 안에서 코드로 판단이 안 돼 N/A로 빠진 항목을 어떻게 채우는지, 개선안을 어떻게 만들어내는지 같은 더 구체적인 작동 방식은 이번 주 금요일 글에서 한 겹 더 들어가고, 본격적으로는 8개월차 LLM 분석 편에서 풀겠습니다.

---

🔐 특허로 지키는 부분

오늘 본 "분석 결과 데이터를 근거로 삼아 사용자와 대화하고, 그 답에 어떤 규칙·어떤 판정을 근거로 했는지를 함께 붙이며, 대화 도중 필요하면 그 자리에서 다시 확인하는 그 과정"은 ViewCheck가 출원한 특허 중 분석 데이터 기반 대화형 판단·근거 연결 주제와 맞닿아 있습니다. 말로는 "AI한테 물어보면 답해준다"로 간단해 보여도, 그 답이 허공이 아니라 실제 분석 데이터에 뿌리내리도록 하고, 근거를 답에 이어 붙여 검증 가능하게 만들고, 대화의 흐름 안에서 재확인까지 엮는 절차를 권리로 정리해 둔 것이 차별점입니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 대화의 품질은 이 근거 연결이 실제로 정확한 데이터 위에서 얼마나 충실히 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. (특허 출원 기술 / 자체 개발)

---

마무리

오늘은 판단 시점, LLM 분석의 큰 그림을 잡았습니다. LLM 분석은 URL 분석과 Figma 분석이 깔아둔 결과를 앞에 놓고, 사람의 질문을 따라 여러 번 주고받으며 진단을 돕습니다. 핵심은 그 답이 허공의 그럴듯한 말이 아니라 그 사이트의 실제 분석 데이터를 근거로 한다는 것, 그리고 그 근거가 답에 함께 붙어 검증 가능하다는 것입니다. 궁금하면 그 자리에서 다시 확인할 수 있고, 설명은 쉬운 말과 전문가 말 사이를 오가며, 간단한 질문에는 빠르게 답합니다.

정리하면 LLM 분석은 "이미 나온 분석 결과를, 실제 데이터를 근거로, 근거를 함께 붙여, 대화로, 사람의 판단을 돕도록" 읽어가는 것입니다. 이 한 문장이 판단 시점의 전부입니다. AI와 대화한다는 사실이 새로운 게 아니라, 그 대화가 검증 가능한 데이터에 뿌리를 둔다는 점이 핵심입니다. 그리고 이 판단 시점이 있어야 비로소 세 시점이 완성됩니다. 설계에서 미리 잡고, 운영에서 실물을 확인하고, 그 위에서 판단으로 의미를 더하는 — 첫 주에 그린 그 큰 그림이 오늘로 한 바퀴를 돕니다.

이 세 시점을 한 흐름으로 엮는 게 어떻게 가능한지, 그 밑바탕에 어떤 기술이 자리하는지는 다음 주 특허 편에서 정리하겠습니다. 오늘은 그 마지막 조각인 판단 시점을 채운 셈입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. "AI가 그럴듯하게 말하는 것"과 "우리 사이트의 분석 데이터를 근거로, 확인 가능하게 말하는 것"은 다릅니다. LLM 분석은 후자입니다. 답을 그냥 믿는 게 아니라, 근거를 따라가 확인할 수 있다는 것 — 그게 판단 시점이고, LLM 분석입니다.

이번 주 나머지 글에서 이걸 더 구체화하겠습니다. 금요일엔 LLM 분석이 실제로 무엇을 해주는지 — 코드로 판단이 안 돼 N/A로 빠졌던 항목을 어떻게 채우고, 개선안을 어떻게 정리하는지 — 를 한 겹 더 들어가 풀겠습니다. 오늘이 "LLM 분석이 무엇이냐"였다면, 금요일은 "그래서 결과 위에서 무엇을 해주느냐"인 셈입니다. 그리고 다음 주(5주차)에는 이 세 방법을 하나로 엮는 ViewCheck의 특허 이야기로 이번 달을 마무리하겠습니다.

오늘도 끝까지 읽어주셔서 고맙습니다. 금요일에 이어가겠습니다.

krds.viewcheck.co.kr

---