Category: 뉴스

You are here:

왜 홈페이지에 적힌 자격 인증을 AI는 “보지 못했다”고 할까? (2026)

저희 홈페이지 ‘회사 소개’에는 ISO 9001, ISO 20000, 소프트웨어 저작권 21건이 하나도 빠짐없이 기재되어 있는데도, 어떤 AI는 “이 회사의 자격 증명 정보를 찾을 수 없다”고 답했습니다. 검색해 보니 ‘인증 보유’로 검색되는 회사들은 모두 「○○회사, ○○인증 획득」이라는 제목의 독립된 글 한 편에 의존하고 있었고, 홈페이지에 나열된 자격 목록에 의존한 곳은 한 곳도 없었습니다.

자세히 보기 »

AI가 “어디가 좋아?”라고 답할 때, 왜 당신의 공식 홈페이지는 절대 보지 않을까? (2026)

우리는 대조 실험을 한 세트 진행했습니다. 회사 이름만 입력하면 공식 홈페이지가 가장 앞에 나오지만, “어때요?”를 붙이는 순간 공식 홈페이지가 완전히 사라집니다. “어디가 좋아?”라고 물으면 상위 20개 안에 어느 회사의 공식 홈페이지도 없습니다. 이유는 아주 명확합니다. “당신이 좋은지 아닌지”는 당신이 스스로 말해서 정해지는 것이 아니기 때문입니다. 이 글에서는 재현 가능한 실험 방법과 가성비 순으로 정리한 4단계 실천법을 제시합니다.

자세히 보기 »

AI가 우리 회사가 누구인지 정확히 말하게 하려면? 구조화 데이터 실전과 세 가지 함정(2026)

앞선 글들에서는 사람이 보는 콘텐츠를 어떻게 써야 하는지 다뤘다면, 이번 글은 기계가 보는 콘텐츠, 즉 구조화 데이터를 다룹니다. ‘우리 회사가 누구인지’를 기계가 곧바로 읽을 수 있는 형식으로 다시 한 번 정리하는 작업입니다. 이는 ‘잘못 말하기’와 ‘빠뜨리기’ 두 가지 문제를 해결합니다. 실제로 AI가 회사명을 동음 오타로 적어 넣은 사례, 그리고 자격 정보가 홈페이지에 분명히 있는데도 AI가 ‘자격 정보를 보지 못했다’고 답한 사례를 겪었습니다. 이 글에서는 기업 신원 정보에 어떤 필드를 써야 하는지, 중요한 선 하나(별칭은 써야 하지만 잘못된 이름은 절대 넣으면 안 된다는 점—그것은 스스로도 그렇게 불린다고 인정하는 것과 같습니다), 저희가 모두 겪은 세 가지 함정(작성했지만 반영되지 않음/본문과 불일치/같은 페이지에 여러 개가 서로 충돌), 2분 검증법, 그리고 이 작업의 올바른 위치를 제시합니다. 만능 열쇠가 아니라, ‘AI가 이미 당신을 언급하려는 바로 그 순간’에 오차를 줄여 주는 수단입니다.

자세히 보기 »

두 페이지가 서로 순위를 잡아먹고 있을 수 있습니다: 키워드 자기잠식 자가진단과 역할 분담(2026)

숨은 문제 하나: 각 페이지를 따로 보면 잘 쓰여 있지만, 두 페이지가 같은 키워드를 두고 경쟁하고 있습니다. 검색엔진은 보통 한 사이트의 같은 키워드에 대해 한 페이지만 대표로 내세우기 때문에, 세 배의 노력을 들이고도 순위에 오르지 못합니다. 저희 자가진단에서 전형적인 사례를 찾았습니다. 홈페이지와 서비스 랜딩 페이지의 제목이 거의 동일했고, 설명조차 같은 문단의 두 가지 버전이었습니다. 이 글에서는 5분 자가진단법(제목을 나란히 놓고 비슷한 것 찾기, 키워드를 검색해 어느 페이지를 선택했는지 확인하기), 네 가지 페이지 유형별 역할 분담표, 그리고 저희의 처리 방식을 소개합니다. 홈페이지는 건드리지 않고(주력 페이지라 변동 비용이 큼), 서비스 페이지를 ‘어디가 좋은가’에서 ‘구체적으로 무엇을 하는가’로 바꿔 두 페이지가 각기 다른 검색 의도를 담당하게 했습니다. 세 가지 주의사항도 덧붙입니다(이미 순위가 있는 페이지는 건드리지 말 것, 콘텐츠도 함께 분리할 것, 페이지 삭제로 해결하지 말 것).

자세히 보기 »

순위를 확인해 보니 조금 부족하다는 걸 알았다면, 무엇을 고쳐야 할까? 먼저 페이지 제목부터 (2026)

앞선 글들에서는 색인 확인, 순위 확인, 크롤러 확인 방법을 다뤘습니다. 확인 후 가장 흔한 고민은 “2페이지에 걸린 건 알겠는데, 그럼 무엇을 고쳐야 하나”입니다. 답은 먼저 페이지 제목을 고치는 것입니다. 비용은 몇 분이면 충분하고, 검색 순위와 AI 인용에 동시에 영향을 주는데, 대부분의 기업이 잘못 쓰고 있습니다. 이 글에서는 상위 10여 개 사이트의 제목 작성 방식을 비교하고(핵심 업무 키워드를 앞에 나열하고 회사명은 맨 뒤에 배치), 네 가지 흔한 실수를 정리하며, 자체 점검에서 발견한 두 가지 대표적 문제도 공개합니다. ① 사이트명 접미사가 너무 길어 업무 키워드가 잘려 나가는 문제 ② 서비스 페이지와 문의 페이지에 어느 회사에나 통하는 “제품 서비스”, “문의하기” 같은 범용 단어를 쓴 문제. 제목 작성 4원칙과 함께, 설명(description)은 마케팅 구호가 아니라 “사실 요약”으로 써야 하는 이유도 담았습니다. AI가 요약할 때 이 설명을 그대로 인용하는 경우가 많기 때문입니다.

자세히 보기 »

AI가 당신을 못 찾는다면, 아주 조금 부족할 뿐: 먼저 자신의 순위를 확인하세요(2026)

「색인됨」과 「AI가 활용할 수 있음」은 전혀 다른 문제입니다. AI의 웹 검색은 상위에 노출된 결과만 봅니다. 3위든 300위든 모두 ‘색인됨’에는 해당합니다. 저희는 이 기준으로 페이지를 넘겨가며 직접 확인했고, 결과는 예상 밖이었습니다. 검색되지 않는 것이 아니라 2페이지 3번째에 있었고, 1페이지 진입까지 아주 조금 부족했습니다. 이 발견은 무엇을 해야 하는지를 곧바로 바꿔놓았습니다. 이 글에서는 페이지를 넘겨 순위를 확인하는 투박한 방법, 네 가지 위치에 대응하는 네 가지 해법(2~3페이지가 가성비가 가장 높습니다), 그리고 덤으로 찾아낸 문제 하나를 소개합니다. 검색 결과에 표시되는 제목과 설명이 몇 년 전 구버전이라는 것은 색인이 전혀 갱신되지 않았다는 뜻입니다. 능동적으로 제출하는 진짜 가치는 새 페이지를 발견하게 하는 것뿐 아니라 낡은 기록을 새로 고치는 데 있습니다.

자세히 보기 »

회사에서 AI를 직접 구축하는 것, 현실적일까? 먼저 따져야 할 네 가지(2026)

「우리 회사에서 AI를 직접 구축할 수 있을까요? 데이터를 외부로 보내고 싶지 않은데」——최근 가장 많이 받는 질문입니다. 가능합니다. 다만 장비에 돈을 쓰기 전에 네 가지를 먼저 따져야 합니다. ① 어떤 경우에 자체 구축이 정말 가치가 있는지(데이터가 내부망을 벗어날 수 없다는 것이 유일하게 계산할 필요가 없는 이유입니다) ② 하드웨어는 좋은 GPU 한 장만 사면 되는 것이 아니며, 성패를 가르는 것은 VRAM 용량과 메모리 대역폭이고, 모델 선택의 철칙은 파라미터 총량만 보지 않는 것입니다 ③ 가장 값진 한 가지: 저희가 세 번의 「느림」을 점검했지만 한 번도 하드웨어 문제가 아니었습니다——사고 모드를 끄지 않아 한참 기다린 끝에 빈 응답을 받거나, 출력이 엉뚱한 필드에 들어가거나, 진짜 느린 것은 첫 토큰 지연이었습니다(캐시를 제대로 켜면 십몇 초에서 2초 미만으로) ④ 운영 인력을 비용에 포함시키는 것입니다. 세 단계 권장 경로도 함께 제시합니다. 먼저 몇백 위안으로 온라인 서비스를 써서 시나리오를 검증하고, 그다음 몇만 위안을 쓸지 결정하세요.

자세히 보기 »

특정 AI가 당신을 추천하지 않는다면, 그 검색엔진에 몇 건이나 등록됐는지 먼저 확인하세요(2026 실측: 저희는 3건뿐)

GEO에서 가장 흔한 실수는 모든 AI를 하나로 보고 최적화하는 것입니다. 실제로 각 AI 어시스턴트는 인터넷에 연결될 때 자체 검색엔진을 사용하므로, 「특정 AI가 당신을 추천하지 않는다」는 본질적으로 「그 검색엔진에 당신이 등록되지 않았거나 순위에 들지 못했다」는 뜻입니다. 저희는 이 기준으로 한 차례 점검했습니다. 한 대형 플랫폼 검색에서 site: 조회 결과는 3건뿐이었고, 사이트 내에는 326개 페이지가 있었으며, 그 3건마저도 몇 년 전의 옛 제목과 오래된 글이었습니다. 이 글에서는 5분이면 되는 두 가지 확인 방법(site:로 등록 수량 확인, 업무 키워드로 순위 확인), 자체 문제를 배제하는 세 단계(크롤러가 왔는지/보안 장비에 차단됐는지/크롤러 UA로 콘텐츠 완전성 검증), 그리고 크롤링은 되지만 등록되지 않는 세 가지 원인과 대응 조치를 제시합니다.

자세히 보기 »

AI 크롤러가 정말 우리 사이트에 왔을까? 서버 로그로 확인하는 방법과 우리가 직접 찾아낸 두 가지 함정(2026)

「AI가 우리를 어떻게 보는가」에 대한 대부분의 판단은 간접적인 추측일 뿐입니다. 직접적인 증거는 서버 로그뿐입니다. 누가 왔는지, 몇 번 왔는지, 어떤 페이지를 가져갔는지, 우리 쪽에서 막아서 못 들어갔는지까지 로그에 남습니다. 이 글에서는 세 단계 확인 방법(각 크롤러의 수집량 집계/상태 코드로 차단 여부 확인/핵심 페이지를 가져가는지 확인)을 제시하고, 이 방법으로 자사 사이트를 점검하며 찾아낸 두 가지 함정을 함께 정리했습니다. ①robots 파일에 등록된 6개 사이트맵 주소가 전부 무효였습니다. 리다이렉트 후 반환되는 것은 XML이 아니라 웹페이지였고, 실제로 유효한 주소는 아예 등록되어 있지 않았습니다. 결국 모든 크롤러가 잘못된 목록을 받아간 셈입니다. ②한 검색엔진 크롤러가 이미 존재하지 않는 옛 주소 구조를 기준으로 404를 대량으로 발생시키며 수집 할당량을 낭비하고 있었습니다. 10분 자가 점검 체크리스트도 함께 제공합니다.

자세히 보기 »

방화벽이 1,080건 경보를 냈는데, 분석해 보니 88%는 누가 한 건지 알 수 없었다(2026 로그 자체 점검 가이드)

한 고객이 3일치 방화벽 위협 로그 1,080건을 내보내며 「이걸 처리해야 하나요」라고 물었습니다. 분석 결과는 이렇습니다. 일단 서두르지 마세요. 이 로그 자체에 거의 쓸 수 없게 만드는 세 가지 문제가 있습니다. ①경보의 88%는 출처가 전부 자사 내부망 게이트웨이를 가리킵니다(상위에서 주소 변환을 해 실제 출처가 지워짐). 로그대로 IP를 차단하면 자기 자신을 차단해 전사 네트워크가 끊깁니다. ②동작의 34.2%는 「경보만」이고 차단하지 않았으며, 그중 고위험 6건이 그대로 통과했습니다. 10초 안에 이미 공개된 취약점 두 개를 연달아 두드린 요청도 포함됩니다. ③건수 1위인 29.3%는 자사 시스템의 정상 통신이 오탐된 것이고, 게다가 중복 집계까지 됐습니다. 올바른 로그 확인 순서(위협 등급이 아니라 동작 열을 먼저 봅니다)와 5가지 자체 점검 체크리스트를 함께 실었습니다.

자세히 보기 »