회의가 끝나면 결정사항과 할 일이 회의록 텍스트 안에만 존재했습니다. 누가 뭘 언제까지 하기로 했는지 확인하려면 회의록 전체를 다시 읽어야 했고, 담당자나 기한이 불명확하게 넘어간 항목은 아무도 다시 짚지 않은 채 묻히는 경우가 있었습니다.
회의록 텍스트를 붙여넣으면 AI가 할 일·담당자·기한을 자동으로 추출합니다. 원문에 담당자와 기한이 명확히 적혀 있으면 검증됨으로 표시하고, 애매하면 "AI 추정" 배지를 붙여 사람이 다시 확인하도록 했습니다. 추출된 항목은 체크박스로 완료 처리하거나, 인라인으로 수정·삭제하거나, AI가 놓친 항목을 수동으로 추가할 수 있습니다.
회의가 끝나면 결정사항과 할 일은 회의록 텍스트 안에만 남았습니다. 누가 뭘 언제까지 하기로 했는지 확인하려면 회의록 전체를 다시 읽어야 했고, 담당자나 기한이 불명확하게 넘어간 항목은 아무도 다시 짚지 않은 채 그대로 묻히는 경우가 있었습니다.
이번에 만든 기능은 단순합니다. 회의록 텍스트를 붙여넣으면 AI가 할 일과 담당자, 기한을 자동으로 추출합니다. 원문에 담당자와 기한이 명확히 적혀 있으면 검증됨으로 표시하고, 애매하면 "AI 추정" 배지를 붙여 사람이 다시 확인하도록 했습니다. 추출된 항목은 체크박스로 완료 처리할 수 있고, 인라인으로 수정하거나 삭제할 수 있고, AI가 놓친 항목은 수동으로 추가할 수도 있습니다.
이 기능을 설계하면서 처음부터 다시 만든 건 거의 없었습니다. AI에게 문서 요약을 맡기면 애매한 부분을 그럴싸하게 채워 넣는 문제가 늘 따라옵니다. 이 문제를 처음 겪은 건 계약서 분석 기능을 만들 때였고, 그때 세운 원칙이 "AI는 원문에 명시된 것만 채우고, 애매하면 미검증 표시를 남긴다"였습니다. 이번 기능은 이 원칙을 세 번째로 재사용한 결과물입니다. 미팅 브리핑 기능에서 이미 한 번 재사용했던 원칙을, 회의록이라는 새로운 도메인에 다시 적용한 셈입니다.
실제로 이 원칙이 작동한 사례가 있었습니다. 회의록에 이런 문장이 있었습니다.
"말씀드린 챗봇 기능 외에, 관리자가 직접 FAQ 답변을 수정할 수 있는 관리자 페이지도 이번 프로젝트에 포함해서 만들어 주실 수 있나요? 원래 계약서에는 없던 부분인데 저희 쪽에서 중요하다고 판단했습니다."
AI는 이 문장을 "관리자 페이지 추가 요청에 대한 견적/일정 영향 검토 및 답변"이라는 할 일로 추출하면서, 담당자를 미지정으로 남기고 미검증 배지를 붙였습니다. 담당자나 기한이 없는 요청이니 당연한 판단이었지만, 이 문장 자체가 다음 단계에서 만들 예정인 기능(계약 범위 변경 감지)의 좋은 실험 재료가 되어주었습니다.
같은 원칙을 세 번 적용해보고 나서 확실해진 게 있습니다. "AI가 만든 결과물에 사람이 신뢰 수준을 표시하고, 필요하면 직접 고칠 수 있어야 한다"는 구조는 계약서든 회의록이든 미팅 준비 자료든 크게 다르지 않았습니다. 도메인마다 달라지는 건 "무엇을 추출할 것인가"뿐이고, "신뢰를 어떻게 관리할 것인가"는 재사용 가능한 하나의 엔진이라는 걸 다시 확인했습니다. 비정형 텍스트에서 정보를 추출하는 다른 업무 — 고객 문의, 이메일, 통화 메모 — 에도 같은 구조를 그대로 옮길 수 있을 것 같습니다.
AI에게 문서 요약을 맡기면 애매한 부분을 그럴싸하게 채워 넣는 문제가 항상 따라옵니다. 이 문제는 이번이 처음이 아니었습니다. 계약서 분석 기능을 만들 때 같은 문제를 겪었고, 그때 세운 원칙이 "AI는 원문에 명시된 것만 채우고, 애매하면 미검증 표시를 남긴다"였습니다. 이번 기능은 그 원칙을 세 번째로 재사용한 결과물입니다. 미팅 브리핑 기능에서 이미 한 번 재사용했던 원칙을, 회의록이라는 새로운 도메인에 다시 적용했습니다.
실제로 이 원칙이 작동한 사례가 있었습니다. 회의록에 "관리자가 직접 FAQ 답변을 수정할 수 있는 관리자 페이지도 이번 프로젝트에 포함해서 만들어 주실 수 있나요? 원래 계약서에는 없던 부분"이라는 문장이 있었는데, AI는 이걸 담당자 미지정, 미검증 상태로 정확히 걸러냈습니다. 담당자나 기한이 없는 요청이니 당연한 판단이었지만, 이 문장 자체가 다음 단계(계약 범위 변경 감지)의 좋은 실험 재료가 되었습니다.
"AI가 만든 결과물에 신뢰 수준을 표시하고, 필요하면 사람이 직접 고칠 수 있어야 한다"는 구조는 도메인에 종속적이지 않습니다. 계약서, 미팅 준비 자료, 회의록까지 세 번 적용해본 결과, 도메인마다 달라지는 건 "무엇을 추출할 것인가"뿐이고 "신뢰를 어떻게 관리할 것인가"는 그대로 재사용 가능했습니다. 비정형 텍스트에서 정보를 추출하는 다른 업무(고객 문의, 이메일, 통화 메모 등)에도 같은 구조를 그대로 옮길 수 있습니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용