로컬 LLM 기반 일정관리(MVP) 흐름 정리

 

 

 

로컬 LLM로 “일정관리”를 만든다고 할 때, 흐름은 이렇게 간다

핵심은 간단하다. LLM은 “일정 확정자”가 아니라 초안 생성기다. 최종 확정(날짜/시간)은 사람이 한다. (정확도가 더 중요하니까)

1) 입력: 사람이 자연어로 메모를 던진다

예: “다음주 월요일 10시에 서버 로그 점검, 3월 1일까지 이벤트 스크립트 수정…”

• 여기서 중요한 건 문장이 예쁘지 않아도 된다는 점
• 단, 추출 정확도를 위해서는 문장이 짧고 명확할수록 유리

2) 추출: LLM이 JSON으로 구조화한다 (Draft 생성)

PHP가 로컬 LLM(Ollama)에 요청을 보내고, LLM은 아래처럼 구조화된 JSON을 반환한다. 이 단계의 결과는 “확정”이 아니라 초안(draft)이다.

[
  {"task":"서버 로그 점검","date_text":"다음주 월요일 10시에","scope":"ops","priority":"medium"},
  {"task":"이벤트 스크립트 수정","date_text":"3월 1일까지","scope":"dev","priority":"high"}
]

• task: 할 일(행동)
• date_text: 원문에 있던 날짜/시간 텍스트(변환하지 않음)
• scope: dev/ops/biz 같은 분류
• priority: 규칙 기반(오늘/내일/까지 = high 등)

3) 저장: DB에는 “기억”으로 남긴다

여기서 중요한 포인트가 나온다. LLM은 생각(추론)을 할 뿐, 스스로 기억을 유지하지 않는다. 그래서 PHP가 DB에 저장해서 “기억”을 만든다.

• batch: 입력 원문(raw_text) + LLM 응답(llm_json) + 모델/프롬프트 정보
• task_item: 추출된 일정 항목들(기본 상태 = draft)

즉, 처리기(LLM)와 기억(DB)은 분리되어 있고, 덕분에 LLM(엔진)을 바꿔도 일정 데이터는 남는다.

4) 검수: 웹 화면에서 사람이 “확정”한다

이 단계가 MVP의 핵심이다. 자연어 날짜를 LLM이 완벽히 실제 날짜로 바꾸기 어렵다면, 사람이 datepicker로 찍어서 확정하게 만들면 된다.

• draft 목록을 보여준다
• 사람이 task_text / scope / priority를 필요하면 수정한다
• due_at(실제 날짜/시간)은 datepicker로 직접 선택
• 확정 버튼 누르면 status = confirmed

이렇게 하면 “날짜 해석”의 난이도를 AI에게 떠넘기지 않고, 정확성과 통제력을 사람이 가져갈 수 있다.

5) 알림: 확정 안 된 draft는 ‘기능’으로 알람을 때린다

일정이 추출되었는데 사람이 확인을 안 했다면, 그 자체가 리스크다. 그래서 미확정 draft를 감지해서 알람을 보낼 수 있다.

• draft 생성 후 일정 시간 경과
• needs_review=1 상태가 계속 유지
• 그때 “확인 안 했다” 알림을 발생

즉, 알람은 “추가 기능”이 아니라 정확도를 확보하는 핵심 장치가 된다.

정리: MVP 일정관리의 역할 분담

• LLM = 초안 생성기 (제안자)
• PHP = 라우팅/검증/저장/상태관리 (통제자)
• DB = 기억 (로그/히스토리/확정 상태)
• 사람 = 최종 확정자 (특히 날짜/시간)

이 구조의 장점은 단순하다. 엔진(모델)을 바꿔도 일정 데이터와 흐름은 유지된다. 로컬 LLM이든 외부 API든, PHP가 어디로 요청을 보내느냐만 바꾸면 된다.

다음 단계(선택)

• draft/confirmed 3페이지 MVP 구현
• 미확정 draft 알람(크론 기반)
• 추후 자연어 날짜를 실제 날짜로 바꾸는 별도 모듈 추가