계약 범위 변경(CR) 조짐을 회의록에서 자동으로 감지하는 기능을 설계하면서, 이미 만들어둔 "위험 마일스톤 조기 경보" 기능과 똑같은 방식으로 만들면 될 거라고 생각했습니다. 별도 테이블 없이, 화면을 그릴 때마다 실시간으로 계산해서 보여주는 방식이었습니다. 마감일 계산은 어차피 날짜 빼기 연산이라 비용이 거의 들지 않으니까요.
빠뜨렸네요. Before/재설계 근거/만들 가치 판단/재현성 사이에 "After" 섹션을 넣어서 실제로 뭐가 달라졌는지 결과를 짚어야 구조가 완성됩니다. 재설계 근거 다음, 만들 가치 판단 앞에 들어가는 게 자연스럽습니다.
After scope_change_candidates 테이블을 만들어 키워드 1차 필터 → Claude API 판단 → 결과 저장까지 이어지는 구조로 완성했습니다. 회의록에서 "추가로", "당초", "구두로" 같은 표현이 담긴 문장만 걸러 AI에게 보내고, AI는 그 문장이 실제 계약 범위 변경 징후인지 판단합니다. AI에게는 원문을 다시 쓰게 하지 않고 문장 번호만 응답하게 해서, 실제 고객 발화 원문이 저장 단계에서 왜곡될 위험도 없앴습니다. 감지된 후보는 기존 "위험 마일스톤 조기 경보" 옆에 나란히 노출되고, 확인/기각 버튼으로 사람이 최종 판단을 내립니다. 기각할 땐 사유도 함께 남기도록 했는데, 이건 나중에 "AI가 왜 오탐을 내는지" 패턴을 데이터로 확인하기 위해서입니다. 판단하려면 원본 회의록 전체를 봐야 할 때도 있어서, 후보 카드에서 바로 해당 회의록으로 이동해 자동으로 펼쳐지는 딥링크도 함께 만들었습니다. dev에서 전체 흐름을 검증한 뒤 prod까지 배포를 마쳤고, 실제 회의록 데이터로 CR 후보가 감지되고 저장되는 것까지 확인했습니다.
만들 가치 판단
기능이 완성된 후, "건별로 검사하는 것 대신 여러 회의록을 한 번에 검사하는 기능도 같이 만드는 게 어떻겠냐"는 제안을 받았습니다. 기술적으로 충분히 가능한 확장이었습니다. 다만 지금 만들면 신규 테이블, 신규 AI 로직, 신규 화면을 한꺼번에 검증해야 하는 상황에서 트리거 방식까지 두 갈래로 늘어나, 문제가 생겼을 때 원인을 특정하기가 훨씬 어려워질 수 있었습니다. 반면 나중에 필요해지면 이미 만든 검사 로직을 그대로 재사용해 짧은 시간 안에 붙일 수 있는 확장이기도 했습니다. "만들 수 있다는 것과 만들 가치가 있다는 것은 다른 문제"라는 원칙에 따라, 건별 검사부터 먼저 안정화하고 일괄 검사는 후속 과제로 남겨두는 쪽을 선택했습니다.
기존 기능의 실제 코드를 먼저 조사해보니, 예상과 다른 그림이 나왔습니다. 위험 마일스톤은 정말로 테이블 없이, due_date와 오늘 날짜를 비교하는 순수 함수 하나로 동작하고 있었습니다. 그런데 이번 기능은 판단 주체가 날짜 계산이 아니라 Claude API였습니다. 페이지를 열 때마다 회의록 전체를 AI에게 보내 판단받는 구조라면, 조회할 때마다 몇 초씩 지연이 생기고 API 비용도 조회 횟수에 비례해서 계속 발생하게 됩니다. "겉보기에 비슷한 종류의 알림 기능이라도, 판단 비용이 0에 가까운지 아닌지에 따라 설계가 완전히 달라진다"는 것을 코드를 직접 확인하고 나서야 알게 되었습니다. 결국 AI 판단 결과를 저장하는 신규 테이블(scope_change_candidates)을 만드는 방향으로 설계를 수정했습니다. 이미 만들어둔 "회의 브리핑 자동 생성" 기능도 같은 이유로 저장 방식을 쓰고 있었다는 것을 뒤늦게 확인하면서, 이번 결정이 새로운 원칙이 아니라 이미 검증해둔 원칙을 다시 확인한 것이었다는 점도 알게 되었습니다.
이번 작업에서 반복 가능했던 것은 특정 기술 스택이 아니라 판단 순서였습니다.
같은 순서를 다음 기능 설계에도 그대로 적용할 수 있다는 점에서, 이 판단 과정 자체가 재사용 가능한 자산이라고 생각합니다.
관련 프로젝트
프로젝트 개요 기획자(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 스토리텔링 소재로 활용