컴키
시작하기 →문의하기 →
문제 정의4 min read

AI가 읽을 수 있는 기록 vs 없는 기록 — 구조화가 만드는 차이

같은 사건을 적어도 어떻게 적었느냐에 따라 검색·집계·요약의 정확도가 달라집니다. AI가 잘 읽는 기록에는 규칙이 있습니다.

01같은 사건, 다른 기록

어제 있었던 일을 두 사람이 각각 적었습니다.

A의 기록

오늘 ○○기업 미팅 다녀왔습니다. 얘기 잘 됐고 다음 주에 다시 보기로 했어요. 몇 가지 이슈는 있었는데 정리해서 공유드리겠습니다.

B의 기록

맥락 ○○기업 재계약 3개월 전 정기 미팅 (참석: 고객사 실무팀장, 당사 영업·기술)
트러블 작년 4월 장애 이후 실무진의 안정성 신뢰가 낮음. 경쟁사 제안을 이미 받은 상태
액션 최근 6개월 가용성 지표를 수치로 제시, 전용 모니터링 옵션 제안
결과 실무진은 긍정적. 단 신규 부임 임원 결재선이 추가되어 다음 주 재방문 필요

A의 기록은 검색해도 나오지 않고, 집계에도 안 잡히고, 3개월 뒤에 읽으면 아무것도 알 수 없습니다. B는 담당자가 바뀌어도 대화가 이어집니다.

차이를 만든 것은 글쓰기 실력이 아니라 양식입니다. B는 4개 칸을 채웠을 뿐이고, 걸린 시간은 A보다 2분 더 길었습니다.

02AI 입장에서 무엇이 달라지나

구조화된 기록이 시스템에서 어떻게 다르게 처리되는지 봅시다.

A처럼 쓴 기록B처럼 쓴 기록
검색"장애 신뢰 문제"로 검색해도 안 나옴트러블 필드가 걸려 정확히 매칭
엔티티 추출고객사 1건만 인식고객사·제품·상태·이슈 유형까지 인식
집계"리스크 건수"에 안 잡힘상태 = 리스크로 자동 집계
요약요약할 내용이 없음핵심만 뽑아 브리핑 한 줄 생성 가능
근거 인용인용해도 정보 가치 없음답변의 근거로 그대로 활용

특히 집계가 중요합니다. "이번 달 리스크 건이 몇 건인가"에 답하려면 각 기록이 리스크인지 아닌지를 시스템이 알아야 합니다. 자유 서술만 있으면 AI가 매번 전체 본문을 읽고 추론해야 하고, 이는 느리고 부정확하며 비쌉니다.

03규칙 1. 메타데이터를 본문에 섞지 않는다

가장 흔한 실수입니다.

❌ "○○기업 TMS 도입 건 리스크 있음 — 담당 김프로"

읽기엔 문제없지만, 시스템 입장에서는 고객사·제품·상태·담당이 전부 문장 속에 녹아 있어 추출을 매번 추측에 맡기게 됩니다. 추측은 틀립니다.

✅ 고객사: ○○기업 / 제품: TMS / 상태: 리스크 → 본문에는 무슨 일이 있었는지만

필드에 넣을 수 있는 것은 필드에 넣으십시오. 본문은 사람이 읽을 서사를 담는 곳입니다.

04규칙 2. 결과에는 판단을, 액션에는 동사를

  • 결과 필드에 "완료"만 적지 마십시오. 무엇이 결정됐고 무엇이 남았는지가 실제 가치입니다.
  • 액션은 동사로 끝나야 합니다. "논의함"이 아니라 "가용성 지표를 수치로 제시함". 나중에 "우리가 뭘 했었지"를 검색할 때 동사가 걸립니다.

05규칙 3. 고유명사는 정식 표기로

AI 추출에서 가장 많은 오류가 여기서 납니다.

  • 같은 회사를 어떤 날은 "○○", 어떤 날은 "○○기업", 어떤 날은 영문 약어로 적으면 세 개의 다른 고객사로 집계됩니다.
  • 반대로 짧은 약어는 다른 이름에 포함되어 오탐을 만듭니다. TMS라고만 적으면 TMS Cloud 관련 문서까지 끌려옵니다.

해법은 개인의 주의력이 아니라 별칭 사전입니다. 회사가 "○○기업 = ○○ = OO Corp"을 마스터데이터로 등록해 두면, 어떻게 적어도 하나로 모입니다. 사람에게 표기 통일을 요구하는 규칙은 지켜지지 않습니다.

06규칙 4. 결정의 '이유'를 한 줄 남긴다

3개월 뒤에 가장 아쉬운 것은 언제나 이유입니다.

"B안으로 결정" → 6개월 뒤 아무도 왜 A를 버렸는지 모릅니다. 그리고 똑같은 논의를 처음부터 다시 합니다.
"B안으로 결정 (A안은 초기 구축 기간이 2개월 더 걸려 분기 목표 미달 우려)"

한 줄 차이가 회의 하나를 없앱니다. 조직에서 가장 비싼 낭비는 이미 내린 결정을 다시 내리는 것입니다.

07규칙 5. 사람이 태그를 달게 하지 않는다

여기까지 읽고 "규칙이 많다"고 느끼셨다면 정확한 반응입니다. 그래서 규칙 대부분은 사람이 아니라 시스템이 지켜야 합니다.

컴키의 방식은 이렇습니다.

  • 필드는 4개 고정 — 맥락·트러블·액션·결과. 사용자는 칸을 채우기만 합니다.
  • 고객사·제품은 자동 추출 — 마스터데이터에 실재하는 엔티티만 후보로 제시해 없는 이름을 만들어내지 않습니다.
  • 긴 표기 우선 매칭TMS Cloud가 있으면 TMS로 오탐하지 않도록 구간을 점유해 처리합니다.
  • 최종 확인은 사람 — 자동 추출 결과를 사용자가 한 번 보고 확정합니다(Human-in-the-Loop). 자동화의 정확도와 사람의 판단을 둘 다 씁니다.

사용자가 지켜야 할 규칙은 사실상 "칸에 맞게 쓴다" 하나로 줄어듭니다.

08자주 묻는 질문

Q구조화가 오히려 기록을 딱딱하게 만들지 않나요?
칸이 많으면 그렇습니다. 그래서 4개 이하를 권합니다. 4개는 서사를 해치지 않으면서 기계가 읽을 최소한의 뼈대를 만드는 지점입니다.
Q이미 쌓인 자유 서술 문서는 버려야 하나요?
아닙니다. 의미 기반 검색(임베딩)으로는 자유 서술도 충분히 검색됩니다. 다만 집계와 신호 탐지에는 약하므로, 과거 문서는 검색용으로 쓰고 새 기록부터 구조화하는 것이 현실적입니다.
QAI가 알아서 구조화해 주면 되지 않나요?
상당 부분 가능하고 실제로 그렇게 동작합니다. 다만 AI는 적혀 있지 않은 것을 만들어낼 수는 없습니다. "왜 그렇게 결정했는지"를 사람이 한 줄도 안 남기면, 어떤 모델도 복원하지 못합니다.
Get Started

회사를 벗어나지 않는
우리 회사 전용 AI 위키

같은 고민을 하고 계시다면, 실제로 운영 중인 화면을 보여드리겠습니다.

Read Next