계약을 수주하면 PM은 계약서를 처음부터 끝까지 읽고, 마감일과 산출물을 직접 엑셀이나 메모장에 옮겨 적었다. 프로젝트가 여러 건 겹치면 어느 계약이 언제 마감인지 머릿속으로 관리해야 했고, 클라이언트에게 진행상황을 공유할 때도 매번 계약서를 다시 펼쳐 확인 후 메일을 새로 작성했다. 계약 건수가 늘어날수록 이 과정은 누적되는 관리 부담이 되었다.
계약서(PDF 또는 텍스트)를 업로드하면 AI가 고객사명, 계약금액, 계약기간, 마일스톤 목록을 구조화하여 자동 추출한다. 애매하거나 불명확한 항목은 "확인 필요"로 표시되어 사람이 검토 후 확정한다. 저장된 데이터는 단일 프로젝트 대시보드(진행률/마일스톤 타임라인)와 멀티 프로젝트 간트차트로 시각화되어, 여러 계약의 일정을 한 화면에서 파악할 수 있다. 클라이언트 공유가 필요할 때는 AI가 현재 마일스톤 현황을 바탕으로 메일 초안을 생성하며, 사람이 검토 후 직접 발송한다.
새 프로젝트를 수주하면 계약서가 온다. PM은 그 계약서를 처음부터 끝까지 읽고, 중요한 정보를 하나씩 옮겨 적는다. 계약금액, 계약기간, 중간보고는 언제까지, 최종 납품은 언제까지. 이 작업 자체는 어렵지 않다. 문제는 프로젝트가 2건, 3건 겹치기 시작할 때다.
어느 계약이 다음 주에 마감인지, 어느 프로젝트가 슬슬 위험 신호를 보내고 있는지, 매번 계약서 폴더를 뒤져가며 확인해야 했다. 클라이언트에게 진행상황을 공유할 때도 마찬가지였다 — 계약서를 다시 펼치고, 날짜를 다시 확인하고, 메일을 새로 썼다.
이 반복 작업을 AI에게 맡길 수 있을지 검증해보기로 했다.
한 번에 완벽한 시스템을 만들려고 하지 않았다. 대신 "이 엔진이 실제로 쓸만한가"를 단계별로 검증하면서 나아갔다.
1단계 — 계약서 분석. PDF나 텍스트로 계약서를 업로드하면, AI가 고객사명, 계약금액, 계약기간, 그리고 마일스톤 목록을 추출한다. 여기서 가장 중요하게 지킨 원칙은 하나였다 — AI는 절대 추정하지 않는다. 계약서에 명시되지 않은 날짜나 금액은 절대 유추해서 채우지 않고, 비워둔 채로 사람이 확인하도록 했다. 모든 추출 항목에는 "이 문장을 근거로 뽑았다"는 원문까지 같이 저장해서, 나중에 왜 이 날짜가 나왔는지 항상 추적할 수 있게 했다.
2단계 — 단일 프로젝트 대시보드. 저장된 계약 하나를 열면, 계약 진행률과 마일스톤 타임라인이 보인다. 마감일이 지났는데 완료 처리가 안 된 항목은 자동으로 "지연" 뱃지가 뜨고, 7일 이내로 다가온 항목은 "임박"으로 표시된다. 상태나 마감일을 바로 그 자리에서 수정할 수도 있다.
3단계 — 멀티 프로젝트 대시보드. 계약이 여러 건 쌓이면서, 한 화면에서 전체를 봐야 할 필요가 생겼다. 카드형 리스트와 함께, 간트차트 뷰도 만들었다 — 가로축은 날짜, 각 계약이 가로 막대로, 마일스톤은 그 위에 점으로 찍힌다. 오늘 날짜를 가리키는 기준선도 그어서, "지금 어디쯤 와 있는지"를 한눈에 볼 수 있게 했다.
4단계 — 클라이언트 메일 초안. 마일스톤 현황을 바탕으로 AI가 진행상황 공유 메일을 초안으로 만들어준다. 단, 발송 버튼은 없다. 초안을 만들어주고, 복사하거나 메일 앱을 열어주는 것까지만 한다. 발송은 항상 사람의 몫으로 남겨뒀다.
이 프로젝트를 진행하면서 두 가지 오류를 발견했다.
하나는 메일 초안을 검증하던 중이었다. 최종 납품 마일스톤의 날짜가 계약서에 적힌 것과 다르게 표시되고 있었다. 원인을 추적해보니, 이전 단계에서 마감일 입력 버그를 테스트하는 과정에서 잘못된 값이 그대로 데이터베이스에 남아있었던 것이다.
다른 하나는 상태값 문제였다. 화면에서는 아무 문제 없이
"예정"이라고 잘 보였지만, 실제 데이터베이스에는 영문
pending이 저장되어 있었다. 화면의 폴백 로직 덕분에
겉으로는 멀쩡해 보였을 뿐이다.
두 건 모두 AI가 "빌드 성공, 검증 완료"라고 보고한 뒤였다. 하지만 그 보고를 그대로 믿지 않고 실제 화면을 열어 눈으로 확인하는 과정에서 발견됐다. AI의 자체 검증 보고서는 참고 자료일 뿐, 최종 확인은 언제나 사람의 몫이라는 걸 다시 한번 확인한 순간이었다.
4단계까지 다 만들고 나서 스스로에게 물었다 — 이 메일 초안 기능, 정말 자주 쓰게 될까?
돌이켜보니 계약 진행상황을 클라이언트에게 공유하는 건 격주에서 한 달에 한 번 정도의 빈도였다. 직접 쓰면 5분이면 끝날 일을, AI가 대신 써주는 게 과연 "자동화할 가치가 있는 병목"인지 다시 생각하게 됐다.
결론은 이렇다 — 이 기능은 없애지 않고 그대로 남겨두되, 우선순위를 낮추기로 했다. 만들 수 있다는 것과 만들 가치가 있다는 것은 다른 문제다. AI로 뭔가를 만들 수 있다고 해서 무조건 자동화하는 게 아니라, 실제로 반복되는 병목인지를 기준으로 판단하는 게 더 중요하다는 걸 이번에 다시 배웠다.
이번에 만든 핵심 엔진은 결국 하나의 패턴으로 요약된다 — "비정형 문서를 넣으면, 구조화된 데이터가 나오고, 그걸 바탕으로 대시보드나 알림이 만들어진다."
이 패턴은 계약서 분석에만 국한되지 않는다. 회의록에서 스코프 변경을 조기에 감지하거나, 프로젝트 리스크를 미리 경보하는 것도 같은 구조 위에서 만들 수 있다. 이번 4단계는 그 첫 번째 검증이었고, 실제로 작동한다는 걸 확인했으니 나머지도 재사용해서 확장할 수 있는 기반이 마련된 셈이다.
설계의 핵심은 "AI가 추정하지 않는다"는 원칙이다. 계약서에 명시된 내용만 추출하고, 날짜나 금액이 불분명하면 절대 유추하지 않고 null로 남겨 사람의 확인을 거치도록 했다. 모든 추출 항목에는 원문 근거 문장(source_excerpt)을 함께 저장해, PM이 "이 마일스톤이 왜 이 날짜로 잡혔는지" 항상 추적할 수 있게 했다.
구현 과정에서 실제로 두 건의 오류가 발견됐다 — 마일스톤 마감일이 계약 종료일과 혼동되어 잘못 표시된 사례, 그리고 상태값이 영문/한글로 혼재되어 저장된 사례. 두 건 모두 AI의 "빌드 성공, 검증 완료" 보고를 그대로 믿지 않고 실제 화면을 직접 확인하는 과정에서 발견되어 수정했다. 이는 AI 산출물을 최종 게이트 없이 신뢰해서는 안 된다는 원칙을 재확인시켜준 계기였다.
또한 4단계(메일 초안 생성)까지 구현을 완료한 뒤, 실사용 빈도를 검토한 결과 이 기능이 저빈도 작업임을 확인했다. 자동화 가치가 낮다고 판단했지만 완전히 삭제하지 않고 남겨두기로 했다 — 이는 "만들 수 있는가"가 아니라 "반복되는 병목인가"를 기준으로 우선순위를 판단해야 한다는 교훈을 남긴 결정이었다.
이 기능의 핵심 엔진은 "비정형 문서 → 구조화 데이터 → 대시보드/알림"이라는 패턴이다. 계약서 분석에 국한되지 않고, 회의록 기반 스코프 변경 감지, 프로젝트 리스크 조기 경보 등 유사한 문서 기반 업무 자동화 아이디어 4건(idea-12~15)이 동일한 엔진 위에서 확장 가능하도록 설계되었다. 즉 이번 구현은 단발성 자동화가 아니라, 재사용 가능한 방법론의 첫 검증 사례다.
관련 프로젝트
프로젝트 개요 기획자(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 스토리텔링 소재로 활용