AI가 정보를 읽는 법

올해 초 개편된 Product Division 지식 공유 세션에서 AI 친화적인 콘텐츠의 요건을 다뤄보면 어떻겠냐는 제안을 받았습니다. 검색의 창구가 포털 사이트에서 AI 서비스로 넘어간 건 이미 대세였고, GEO니 AEO니 하는 키워드들이 대두되고 있었으니까요. 당시 3월 출시를 목표로 한창 개발 중이던 AI 에이전트의 답변 품질에도 영향을 줄 수 있는 문제였습니다.

저도 막연히 필요하겠다고 생각한 주제였지만 사실 마음 속엔 약간의 반감이 있었습니다. AI가 인간의 언어를 더 잘 이해하게 발전하는 게 옳은 방향 아닌가? 왜 인간이 AI 이해하기 좋으라고 글을 뜯어야 되나. 뭐 이런 약간의 빈정상함이랄까요. 내가 너 땜에 또 일을 만들어서 해야겠니? 같은 피로감이기도 했습니다.

그렇게 얼마쯤 내키지 않는 마음이지만 매도 먼저 맞는 게 낫다고, 예정된 발표일을 앞당겨서 준비를 시작했습니다.

헬프센터 가이드는 코드베이스, 블로그, 고객지원 문서 등 AI 에이전트가 참조하는 주요한 지식 베이스 중 하나입니다. 현재는 LLM Wiki로 SSOT 지식 베이스를 구축하고 있지만, 헬프센터 가이드는 사람의 손을 거쳐 잘 정리·정제·검수된 믿을 만한 원천 자료로 여전히 기능합니다. 다만 사용자가 직접 문서를 읽고 이해해야 했던 기존과 달리 AI가 대신 검색하고 답변을 제공하게 된 만큼, 달라진 콘텐츠 소비 주체에 맞게 제품 지식에 필요한 변화도 탐색해야 합니다.

AI를 쓰기 시작하고 얼마 안 되서 우리 모두가 깨달은 것처럼, AI는 대충 말한 걸 찰떡같이 알아듣지 못합니다. 그래서 엄청나게 똑똑하고 아는 게 많지만 세상물정을 전혀 모르는 인턴처럼 다뤄야 한다고 하죠. 떠먹여주듯 하나하나 친절하고 자세하게 설명하다 보면 오래 전에 본 '샌드위치 코딩' 영상이 떠오릅니다. '이렇게 말하면 알겠지' 하는 짐작이 전혀 먹히지 않는 컴퓨터의 방식을 짓궂은 아빠는 몸소 보여주며 아이들의 분노를 돋웁니다.

AI는 때로 이상한 답변을 내놓곤 합니다. 언뜻 번듯해 보이지만 자세히 읽어보면 엉뚱하게 해석해서 왜곡됐거나 아예 사실 관계가 틀린 정보를 포함하는 경우를 심심찮게 봅니다. 사용자가 이런 경험을 몇 번 반복하면 에이전트에 대한 신뢰도가 떨어지고 사용을 포기하면서, AI를 통한 사용자 경험 개선과 고객지원 비용 최적화도 실패로 돌아갈 수 있겠죠.

어떻게 하면 이런 오류를 줄이고 정확성과 신뢰도 높은 답변을 안정적으로 제공할 수 있을까요?

AI가 잘 읽고 이해하는 콘텐츠를 작성하려면 먼저 AI가 정보를 읽고 이해하는 방식을 살펴봐야 합니다. 크게 정보를 조각으로 나누는 청킹(Chunking), 그 조각을 좌표 공간에 배치하는 벡터화(Embedding), 좌표상 가까운 정보를 찾아내는 벡터 검색(Vector search)의 공정을 거쳐 이뤄집니다.

정보 분할 | Chunking

문서를 작은 텍스트 조각(chunk)으로 나누는 과정입니다. 일정한 토큰 수를 기준으로 자르는 고정 크기 방식(Fixed-size chunking), 헤더·문단·목록 등 구조적 요소를 기반으로 자르는 방식(Document structure-based chunking), 의미적 유사성을 기반으로 자르는 방식(Semantic chunking) 등 다양한 전략이 사용됩니다. 정보를 어떻게 나누느냐에 따라 맥락이 끊기거나 유지되기 때문에 청킹은 에이전트 또는 검색 증강 생성(RAG)의 검색 정확도에 큰 영향을 미칩니다. 관건은 충분히 의미 있는 정보를 담을 만큼 크면서도, 빠른 응답이 가능할 만큼 작은 청크를 찾는 것입니다.

벡터화 | Embedding

텍스트의 의미를 벡터로 변환하는 과정입니다. 벡터는 텍스트의 의미를 컴퓨터가 계산할 수 있도록 변환한 숫자의 배열을 가리킵니다. 청크를 숫자의 배열로 바꾸면 좌표 공간에 배치(embed)할 수 있게 되고, 청크 사이의 거리를 계산해 의미가 얼마나 비슷한지 유사도를 측정할 수 있게 됩니다. 의미가 비슷한 청크일수록 좌표상 가까운 위치에 놓입니다.

벡터 검색 | Vector search

좌표 공간에 놓인 벡터들 중, 질문의 벡터와 가장 가까운 것을 찾아내는 과정입니다. 의미가 비슷한 정보일수록 좌표상 거리가 가깝기 때문에 거리 계산만으로 관련 있는 정보를 추려낼 수 있습니다. 다만 의미 기반 검색은 '그로스 플랜'처럼 정확히 일치해야 하는 고유한 값을 포함할 때, 플랜 전반에 관한 비슷한 내용만 인출하고 정확히 '그로스 플랜'에 해당하는 문서를 찾아내지 못할 수 있습니다. 그래서 의미 유사도를 보는 벡터 검색과 정확한 단어 일치를 보는 전통적인 키워드 검색 방식을 함께 써서 서로의 약점을 보완합니다.

이 세 단계 공정을 토대로 AI가 읽기 쉬운 콘텐츠의 조건을 역으로 생각해 볼 수 있습니다. 실제 의미대로 청킹되려면 콘텐츠가 의미 단위에 맞게 나뉘어 있어야 하고, 청크 하나 안에서 뜻이 통해야 인출됐을 때 말이 되는 정보를 전달할 수 있겠죠. 또 AI가 여러 청크를 조합할 때 오류가 없으려면 청크들 간의 관계가 명확히 밝혀져 있어야 합니다.

원자화: 의미 단위로 쪼개기

의미 경계 나누기 | Heading hierarchy

노션같은 마크다운 기반 플랫폼에서 문서를 작성할 때 #이나 ##를 앞에 붙여서 헤딩 서식을 적용하죠. H1, H2, H3로 이어지는 헤딩은 의미 단위와 위계를 반영하기 때문에 AI가 청크를 나눌 '절단선'으로 인식합니다. 목록과 표도 경계로 작용합니다. 단순 나열 대신 글머리 기호로 병렬 관계를 표현하고 비교 정보는 표로 정리하면, AI가 항목 간의 관계를 구조화된 단위로 인식합니다.

메타데이터 | Metadata

헬프센터 가이드에는 플랜이나 권한처럼 특정한 조건에 해당하는 경우에만 유의미한 정보도 있습니다. AI 에이전트의 답변을 한참 읽었는데 알고 보니 나한테 권한이 없거나 우리 조직 플랜에서 지원되지 않는 기능이라면 시간을 낭비한 셈이 되잖아요. 이런 속성을 메타데이터로 기록해두면 AI가 사용자 상황에 맞는 문서만 골라낼 수 있습니다. 또 문서가 사용법(HowTo)인지, 문서(Article)인지, 자주 묻는 질문(FAQ)인지를 타입으로 명시하면, AI가 가장 유용한 정보를 빠르게 인출할 수 있습니다.

환각 방지 서술 | Zero-hallucination

할루시네이션, 즉 환각을 방지하려면 AI가 자의적으로 해석할 여지를 차단하고 확인된 근거에 기반한 답변을 내놓도록 서술해야 합니다. '이 기능', '해당 설정'처럼 대신 가리키는 말은 사람에겐 자연스럽지만 AI에겐 모호합니다. 대명사 대신 고유 명칭을 사용하고, 동작의 주체가 관리자인지 시스템인지와 같은 논리 관계를 명시해야 합니다. '할 수 있다'처럼 모호한 표현도 피해야 합니다. '해야 한다/하면 안 된다', '지원된다/지원되지 않는다'처럼 이분법적으로 서술해야 AI가 추측에 의존하지 않고 확인된 답을 내놓을 수 있습니다.

자기완결형 서술 | Self-containment

청킹된 정보 조각을 단독으로 봤을 때도 그게 무엇에 관한 내용인지 알 수 있어야 합니다. 새로운 단락마다 기능명과 메뉴 경로를 반복해서 명시하고, 하위 항목을 쓸 때도 상위 주제를 생략하지 않아야 합니다. SDK 설치 후 테스트 진행 방법을 설명하는 문서에서 '안드로이드'라는 헤딩 아래 확인할 필드값만 나열하면 AI가 헤딩 기준으로 그 청크를 인출했을 때 어떤 맥락인지 알 길이 없습니다. 'SDK 테스트 – 안드로이드 설치 이벤트 검증하기'처럼 헤딩에 맥락을 박아두면 그 청크 하나만 읽어도 이해하는 데 충분합니다.

구조화: 길목에 표지판 세우기

의존 관계 설계 | Dependency mapping

'A를 하려면 B가 먼저 필요하다'는 전제 조건을 길목에 표지판처럼 세웁니다. 권한, 플랜, 필수 도구 같은 사전 준비사항을 작업 설명보다 먼저 배치해두면, AI가 사용자 문제 해결 과정에서 누락된 게 없는지 역추적할 수 있습니다. AI는 먼저 조건을 충족하는지 확인하고, 지금 무슨 문제가 발생했는지 파악한 후, 지식 베이스에 근거해 해결책을 제시하는 '필터링 - 진단 - 액션'의 순서로 추론하고 답변합니다. 콘텐츠도 이러한 AI의 사고 흐름에 맞게 전개되면 어디에서 막힌 건지 AI가 구체적으로 짚어줄 수 있게 됩니다.

분기 로직 설계 | Decision logic

복잡한 조건을 섞어버리지 않고 목적지와 갈림길이 1:1로 대응하는 단순한 표지판으로 쪼갭니다. 'A, B 방향은 분홍색 또는 초록색 차선'이라고 하지 않고 'A 방향은 분홍색 차선', 'B 방향은 초록색 차선'처럼 쪼개면, AI가 사용자 상황에 맞는 길을 정확히 고를 수 있습니다. 예외 조항을 한 문단에 섞어 쓰지 않는 것과 상황별로 섹션을 분리하는 것도 같은 원리입니다. 참인지 거짓인지가 분명해야 AI도 헤매지 않습니다.

발표를 마친 후 이어진 질의응답 중에 이런 질문이 있었습니다.

명확하고 좋을 것 같긴 한데 사람이 읽기에 좀 어색해지진 않을까요? 예를 들어서, 기능 이름을 매번 반복해서 써주면 명확하긴 하지만 좀 이상하잖아요.

저 역시 마음 한 켠에 품고 있던 의문! 혹시나 하면 역시나 나오더라구요. 말이 좋아서 명확하지, 로봇도 아니고 (ㅋㅋ) 어떻게 매번 말하냐구요. 특히 한국어는 주어를 생략하는 경우가 흔합니다. 문어체 영어에서는 주어가 없으면 문장이 성립하지 않지만, 한국어에서는 맥락으로 주어를 유추하는 게 자연스러워서 주어를 꼬박꼬박 쓰면 오히려 이상해지잖아요.

그 질문에 저는 나 역시 같은 생각을 해봤노라고 솔직하게 말하면서, 아마 기계적으로 매번 지칭하라는 뜻보다 청킹되는 단위 안에서 대상, 주체, 맥락을 명확하게 하라는 뜻이 아니겠냐는 어정쩡하지만 나름 최선의 답변을 했습니다.

그런데 나중에 실제로 AI 최적화를 진행하면서 이런 회의는 사라졌는데요. 로봇처럼 말하지 않고도 한 단락, 한 헤딩 안에서 명확하게 쓰는 게 어렵지 않았습니다. 한 PM 동료는 개선된 가이드를 보고 "유치원생도 이해하겠다"고 했어요. 아무리 그래도 저희 초1 아들이 Amazon S3 연동 가이드를 이해하진 못 할 것 같지만... 저는 영어의 "fool-proof"라는 단어를 떠올렸습니다. 개선된 버전을 보고 있으면 헷갈리거나 잘못 해석할 여지를 싹 막아버린 것 같았거든요.

사실 생각해보면 주어를 생략해서 생기는 혼선, 모호한 대명사가 만드는 오해는 AI한테만 일어나는 일이 아닙니다. 슬랙이나 미팅에서도 생략된 정보나 서로 다른 표현, 중간에 슬쩍 건너뛴 갈림길 때문에 대화가 엉키는 일이 자주 있잖아요. 저도 "'이렇게'가 어떻게예요?"라던가 "'우리'가 누구죠?"라던가 "누가 누구한테 했다구요?" 같은 질문을 종종 하거든요. (네, 직업병입니다.)

AI가 인간의 언어를 제대로 이해하지 못 해서 사람이 이 고생을 한다는 마음으로 시작했지만, AI가 읽기 좋은 글은 사람이 읽기에도 좋다는 결론에 이르렀습니다. 글쓰는 사람 입장에선 꽤나 아름다운 대화합이군요.

다음 편에서는 이 AI 최적화 원칙들을 실제 가이드에 적용하는 과정을 다뤄보겠습니다.