AI 콘텐츠 파이프라인 구축하기

설 연휴가 지나자마자 회사는 AX에 속도를 내기 시작했습니다. AI 캠프 1기 참가자를 모집한다는 소식에 저는 손을 번쩍 들고는 온갖 좋아 보이는 말을 신청서에 잔뜩 써내서 당첨되는 데 성공했어요. AI가 읽기 좋은 콘텐츠의 요건에 대해 발표를 준비하면서, 사용자가 반드시 이해해야 하는 제품 지식을 담고 있는 주요 가이드의 AI 최적화 파이프라인을 만들고 싶었거든요.

제품 에이전트 출시를 앞두고 헬프센터를 총괄하고 있는 저로서는 초조한 마음이 있었습니다. 콘텐츠 품질을 서둘러 확보하려면 관건은 규모(scalability)였습니다. CSM의 고객 온보딩 과정, 팀 논의, 사내 에이전트 검토 등을 참고해 선정한 핵심 가이드만 해도 89편에 육박했는데, 하나하나 분석하고, 구성하고, 작성하고, 리뷰하는 방식으로는 시작을 생각하는 것조차 힘든 분량이었어요. 전담 인력을 빼서 TF를 꾸릴 수 없는 스타트업에선 사실 '갈아넣는' 것 말고는 답이 없는 종류의 일이었죠.

하지만 2월 마지막 주 나흘간의 캠프에 참가하면서 '되겠다'는 생각을 했습니다. MCP로 노션과 슬랙을 조작하는 건 너무 쉬웠고, 헬프센터 콘텐츠를 검색하고 분석하는 것도 가능했기 때문에 충분히 구현할 수 있겠다는 믿음이 생겼어요.

노트에 손으로 써내려 간 아이디어를 실제로 구현하는 데는 하루면 충분했습니다. 물론 팀이 작업에 착수할 수 있을만큼 산출물 품질을 높이고 형식을 정리하는 데​ 훨씬 더 많은 시간이 걸렸지만요.

해결하고 싶었던 다섯 가지 문제

AI 워크플로우를 수립하는 동안 아래 다섯 가지 문제를 해결하는 데 주력했습니다. 규모를 확보해 자원의 제약을 뛰어넘으려면 이런 문제들이 AI로 해결돼야 유의미하다고 생각했거든요.

1. 89편의 상태를 평가하고 작업 순서를 정하려면 여러 요소를 복합적으로 고려해야 하는데, 사람이 하면 주관과 느낌이 개입하며 오래 걸릴 수 있으니 AI로 빠르고 일관되게 뽑자.
2. 가이드 한 편마다 동일한 작업 항목을 단위로 작업할 테니 노션 DB에 항목을 생성하고, 속성 필드를 채우고, 템플릿을 적용하는 등 반복적인 작업 관리를 최대한 자동화해보자.
3. 라이팅 가이드라인이 있어도 사람이 매번 꼼꼼하게 적용하길 기대하긴 어렵다. 그간 정립해 온 기준들을 AI가 참조하게 해서 좋은 수준의 초안을 가지고 휴먼 리뷰를 시작하면 좋겠다.
4. AI가 제안한 내용을 믿어도 좋을지 모르겠다. 어느 순간 '잘했겠지' 하며 익숙해져서 검토가 미흡해질 수 있다. 사람이 확인할 수 있게 AI 제안마다 근거를 남겨서 작업 과정의 신뢰도를 높여보자.
5. AI가 점점 더 믿을 만해지려면 사람이 검토 후 직접 수정한 내용을 되먹여야 한다. 리뷰 로그를 남겨서 AI가 어떤 점에서 미흡했고 사람은 어떻게 개선했는지 파악하고 학습에 활용하자.

제 담당이던 가이드 두 편을 샘플 삼아 돌리며 워크플로우를 만들어 나갔습니다. 산출물 서식과 하위 단계 순서를 여러 차례 수정한 끝에 이렇게 정리됐어요. 원래 없었던 단계도 하나 추가됐죠.

일관된 기준으로 빠르게 전수 평가하기

작업을 시작하기 전에 먼저 89개 가이드가 AI 최적화 관점에서 얼마나 괜찮거나 별로인지 상태부터 파악해야 했습니다. 89개를 선정하고 중요도에 따라 '필수'와 '보조'로 구분하는 것까진 팀이 의논해서 직접 처리했지만 평가는 AI로 빠르게 할 수 있을 거라고 생각했습니다. (지금이야 이 정도 작업은 당연한 듯 AI로 처리하지만 이건 떠듬떠듬 알아가던 3월 얘기입니다.)

처음에는 발표 자료에서 도출한 AI 최적화 규칙에 더해 팀에서 수립한 라이팅 가이드라인 2개 영역 각 60점씩 120점 만점으로 평가했습니다. Claude Code가 제안해서 그렇게 돌려보니 너무 복잡하더라고요. 결정적으로 이 평가의 목적은 정교한 절대 평가가 아니었습니다. 어차피 89편을 모두 개선한다는 목표는 똑같았고, 뭘 우선적으로 작업할지만 파악하면 됐거든요.

그래서 2개 영역 기준은 유지하되 점수가 아닌 A/B/C 등급으로 평가하고, 그렇게 평가한 근거를 확인할 수 있게 (AI 불신 이슈 👀) 주요 이유 3개를 한 줄에 간결하게 기록하게 했습니다. 스프레드시트로 만들어 둔 가이드 목록에 열을 추가하고, 조건별 서식을 적용하고, 평가 상세까지 기입하며 /evaluate 스킬을 완성했습니다.

반복적인 작업 관리를 자동화하기

우리 팀은 문서를 작성하고 리뷰를 거쳐야 하는 직무 특성상, 지라가 아닌 노션에 업무 관리 시스템을 갖추고 활용하고 있었어요. 이번 핵심 가이드 개선 프로젝트도 예외가 아니었는데요.

가이드 기준으로 parent task를 만들고, 하위에 5개의 subtasks를 생성해야 했습니다. MCP로 시도해보니 너무나도 손쉽게 항목을 생성하고 상태 변경을 자동화할 수 있었어요. /setup 커맨드를 가이드 번호와 함께 입력하면 Tasks DB에 프로젝트, 영역, 상태, 시작일, 담당자 필드값을 채워 지정된 형식으로 작업 항목이 일괄 생성됐습니다. 제목 형식 다르고, 필드 입력 빼먹고, 상태 업뎃 까먹는 문제가 사라졌어요. 솔직히 매번 클릭하기 귀찮긴 하잖아요.

나중에 마크다운 기반 플랫폼으로 헬프센터를 이전했을 때 활용하려고 만든 /metadata도 있습니다. SEO/GEO/AEO 최적화를 위해 가이드의 메타데이터를 YAML 형식으로 생성합니다. 문서 타입은 schema.org, 카테고리는 헬프센터, 플랜과 권한은 코드베이스를 참조하게 했습니다.

정립된 기준대로 분석과 작성 위임하기

다음으로 가이드마다 AI 최적화 기준에서 구체적으로 어떤 개선이 필요한지를 상세하게 분석하는 스킬, /analyze를 만들었습니다. 앞서 조사한 이론적 내용을 바탕으로 ① 의미 기반 위계, ② 메타데이터 설계, ③ 환각 방지 서술, ④ 정보 독립성, ⑤ 선형적 순서, ⑥ 비선형적 분기 등 AI 최적화 원칙 6개를 도출하고, 그 원칙에 비추어 가이드의 어떤 부분이 왜 부적합하며, 그래서 어떻게 개선해야 하는지 제안하도록 했습니다.

결과는 나쁘지 않았습니다. AI 최적화도 처음이고, AI 스킬로 자동화하는 것도 처음이었지만 퀄리티가 이전보다 훨씬 나아지겠다는 확신을 갖기에는 충분했죠. 다만, 줄글 형식의 분석 결과가 알아보기 어렵다는 팀원의 피드백을 반영해 개선 전·후 표와 구조 제안 표로 정리해서 subtask 중 하나인 '개선 제안' 페이지에 작성하게 했습니다.

이 '개선 제안'은 다음 단계인 '수정 초안'으로 이어집니다. /revise는 분석 결과를 바탕으로 기존 가이드를 다시 쓰는 스킬이에요. 라이팅 가이드라인에 따라 자연스러운 한국어, 이해하기 쉬운 문장 및 단락 구조, 보이스앤톤, 정해진 서식과 용어 등은 해치지 않게 했어요.

그런데 테스트 중 한 가지 문제를 발견했습니다. 라이팅 가이드라인으로 작성 규칙과 스타일은 반영할 수 있었지만, 기술적 정확성은 검토할 수 없었던 거예요. 핵심 가이드는 가장 기본적인 제품 지식을 다루는 만큼 초기에 쓰인 게 많았고, 빠르게 문서를 갖춰나가야 했던 당시 상황상 제품에 대한 이해가 아주 정확하지 않은 채로 작성했거나 퀄리티 기준이 일관되게 유지되지 못했다고 느껴지는 부분들이 종종 있었거든요. 기존 가이드가 갖고 있던 한계, 즉 애초에 누락된 내용이나 잘못 설정된 초점 등 내용적 한계까지 함께 개선되어야 의미가 있는데 이 부분을 간과했던 겁니다.

다행히 당시에는 사내 에이전트 abot이 개발되어 있었기 때문에 슬랙을 통해 검증을 요청할 수 있었어요. 테스트 중이던 28번 가이드를 돌려봤더니 UI 경로 축약, 조건 누락, 맥락 생략 등 수정 사항이 15건이나 쏟아졌습니다. 그래서 맨 마지막에 한번에 검증하는​ 대신 /revise 하위에 /verify 스킬을 끼워넣고 섹션마다 검증하는 루프로 바꿨습니다. 이로써 구조와 문장 재구성을 넘어 정확성까지 확보한 퀄리티로 작성을 위임할 수 있게 됐습니다.

영문 번역도 쉬워졌습니다. 일단 되는대로 그간의 AI 챗 내역을 최대한 긁어모아서 프롬프트를 구성한 뒤 /translate 스킬을 만들었어요. 나중에 영문 가이드라인도 나오면서 퀄리티는 안정화됐고요.

AI 제안에 근거를 확보해 신뢰도 높이기

AI가 후루룩 뽑아내는데 이걸 과연 믿어도 좋은지 안심하기 어려웠습니다. 일주일 단위로 빅뉴스가 터지며 AI 기술과 활용이 급속도로 진화하던 시기였으니까요.

관건은 분석 결과와 개선 제안이었습니다. 그게 가이드 재작성의 토대가 됐기 때문이죠. 제안 항목마다 무엇이 어떤 면에서 문제인지 설명하고 어느 프레임워크의 어떤 조항을 근거로 그렇게 도출했는지 기록하게 했습니다. 이놈이 일을 제대로 한 건지 보려는 목적이었는데 사실 거꾸로 배우는 것도 많았어요.

수정 초안은 원래 팀이 작업하던 방식대로 현재 본문과 수정 초안을 2단으로 나란히 비교할 수 있게 했습니다. 또 '개선 제안'의 내용을 표로 요약해 상단에 붙여서 앞에서 분석한 걸 수정안에 제대로 반영했는지 한 페이지 안에서 위아래로 이동하며 확인할 수 있게 했어요.

휴먼 리뷰 후 개선사항을 로그로 남기기

여기까지는 팀이 수립해 온 규칙과 기준을 적용해 자동화할 수 있는 영역이었습니다. 하지만 AI 초안을 사람이 직접 리뷰하며 90을 100으로 끌어올리는 수정 과정에 진짜 능력치가 있었죠. 규칙의 허술한 부분을 AI가 마음대로 처리한 부분이 없는지, 그래서 의미가 왜곡된 곳은 없는지, 원문의 표현이 좋았는데 개악하진 않았는지, 사람의 눈과 손을 거쳐서야 비로소 확정지을 수 있었습니다.

사람이 갖고 있는 제품 지식, 사고 능력, 언어 능력, 그밖에 히스토리·제약·관계에서 생겨난 복잡다단한 맥락을 동원해서 비판적으로 보완하며 완성도를 높이던 과정을 일부라도 파이프라인에 심을 수 있다면. 그게 없이는 비슷비슷한 AI의 실수를 사람이 매번 뒤치닥꺼리하는 형국을 피할 수 없을 것 같았습니다. 그렇게 AI 초안과 최종 배포본 사이 변경 내역을 기록하는 /review 스킬을 추가했어요.

회고

소위 '파이프라인'이라는 걸 만들어 보면서 새삼 깨달은 게 있습니다.

형식은 매우 중요하며 AI에게 맡길 수 없다. AI가 똑똑해서 필요한 분석과 정보를 쉽게 얻은 것 같지만, 같은 내용이라도 효과적으로 눈에 들어오는 형식을 갖춰야 그 쓸모가 제대로 발휘됩니다. 작업 흐름의 어느 단계에 어떤 형식으로 내용이 나와야 일하는 데 도움이 될지는 직접 그 일을 하는 사람이 가장 잘 압니다. /analyze와 /revise 스킬 산출물에 대한 팀원들의 피드백에 따라 템플릿의 형식을 개선한 것처럼 필요한 단계에 필요한 정보가 보기 쉬운 위치에 등장해줘야 '뭐가 잔뜩 써있는데 AI가 잘했겠지' 함정에 빠지지 않고 human-in-the-loop이 의미 있어집니다.

학습 루프가 없이는 총 효율이 나아지지 않을 수도 있겠다. 가이드 한 편을 재작성하는 건 확실히 빨라졌습니다. AI 최적화와 정확성 검증, 스타일 적용까지 몇십 분이면 뚝딱 되니까요. 하지만 그렇게 되기까지 AI 스킬을 한 땀 한 땀 만들고, 산출물 확인하고, 퀄리티 높이고, 형식 잡고 하는 데 만만찮은 시간이 투입됐습니다. 그렇게 재작성한 가이드를 사람이 리뷰하는 데도 시간이 꽤 많이 걸렸어요. 예상보다 속도가 나지 않아서 (AI 과신 이슈 👀) 기존 목표 대비 진척도가 50%도 못 미칩니다. 그래서 다음 단계로 필요한 건 학습 루프로 봅니다. 리뷰 로그를 읽어서 학습하고 스스로 고도화하는 과정까지 자동화해야 ROI가 나올 것 같아요.

원하는 결과물의 기준이 언어화되어 있어야 AI를 쓰는 의미가 있다. MGS26에서도 많은 연사분들이 언급하신 부분인데요. 특히 정제된 언어로 찍혀 나오는 (인쇄는 아니지만 어쨌든 '발행'되는) 문서를 만드는 일이라면 더더욱 목표와 대상부터 용어, 서식, 문장부호까지 일일이 정해둬야 사람이 매번 고치거나 프롬프트를 매번 고치는 개미지옥에 빠지지 않을 수 있습니다. 라이팅 가이드라인을 만들어 두길 정말 잘했다 싶었습니다. LLM 기반 AI의 등장으로 가장 먼저 갈아치울 수 있을 것 같던 직종이지만, 역설적으로 AI 덕분에 잘 정제된 문서의 중요성과 그 일을 할 수 있는 능력의 가치가 훨씬 더 대중적인 수준으로 확산되고 있다고 느낍니다.

그런데 흥미롭게도 예상치 못한 걸림돌이 바로 그 규칙과 기준을 정리해 둔 문서, 더 정확히는 그 문서들을 대하는 저의 태도에 있었습니다. 언제든 열어서 '관리한다'는 감각을 유지할 수 있는 정돈된 문서가 좋다고 생각했는데, AI 네이티브 업무방식에 잘 맞는 건 유연하게 진화하는, 그러나 사람이 읽기엔 다소 고역인 md 파일이었거든요. 다음 편에서는 이 문서들의 변천사를 다뤄보겠습니다.