나만의 AI 업무 시스템 만들기 3. 내일 일정과 할 일을 물어보고 확인한 것

비서에게 “내일 일정과 할 일”을 물었습니다. 짧은 요청이지만 답을 만들려면 캘린더와 할 일 기록을 함께 읽어야 했습니다. 답변이 자연스러운지만 보고는 같은 날짜를 조회했는지, 목록의 일부가 빠졌는지 알 수 없었습니다.

2026년 9월 17일에는 서버의 두 비서에서 이 흐름을 시험했습니다. 이 글은 그때 확인한 문제와 보완 결과에서 출발합니다. 이후 회의록 화면과 업무 기록 서비스를 만들었지만, 9월 28일 현재 모든 기능을 하나의 업무 흐름으로 연결한 상태는 아니어서 전체 구조를 다시 검토하고 있습니다.

같은 내일을 읽고 있는가

사람에게 ‘내일’은 익숙한 말이지만 조회 도구에는 기간을 넘겨야 합니다. 캘린더와 할 일 목록이 서로 다른 시간대를 기준으로 삼으면 같은 요청에 다른 하루가 섞일 수 있습니다. 처음 요청할 때뿐 아니라 실패한 조회를 다시 시도할 때도 기준이 유지돼야 했습니다.

초기 시험에는 재시도하면서 시간대가 달라지는 문제가 있었습니다. 답에 날짜가 적혀 있다는 사실만으로는 충분하지 않았습니다. 조회 도구가 실제로 받은 기간을 확인해야 했습니다. 보완 뒤에는 한국시간으로 같은 하루를 조회하는 범위를 확인했습니다.

일정 내용을 틀리지 않게 요약하는 일보다 앞에, 필요한 날짜의 자료를 가져오는 일이 있었습니다. 이 구간이 틀리면 모델이 읽은 내용을 충실하게 설명해도 제가 물은 질문의 답이 아닐 수 있습니다.

목록의 끝까지 읽었는가

목록이 길면 조회 결과가 여러 페이지로 나뉩니다. 첫 응답에 항목이 들어 있다는 이유로 목록을 다 읽었다고 볼 수는 없었습니다. 실제 시험에서도 중간에서 잘리는 문제가 있어 다음 페이지를 이어서 가져오는 동작을 보완했습니다.

이 문제는 답변 문장만 읽으면 알아보기 어렵습니다. 빠진 항목은 답에 나타나지 않기 때문입니다. 도구가 반환한 목록과 페이지 처리 과정을 함께 확인해야 했습니다.

자료를 읽을 기능이 설치됐는지와 이번 요청에서 그 기능을 썼는지도 다릅니다. 두 비서의 주 대화에서 실제 캘린더·할 일 조회 도구가 사용되는 것을 확인했습니다. 모델이 이전 대화에 있던 내용을 다시 설명하는 것만으로 조회 성공을 판단하지 않았습니다.

이때의 검증은 특정 요청과 보완한 처리 범위에 대한 것입니다. 모든 표현의 질문이나 모든 길이의 목록에서 누락이 없다는 품질 보증은 아닙니다.

읽는 시험에서 쓰기까지 허용하지 않기

조회 순서를 바꾼 뒤에는 쓰기 요청이 계속 차단되는지도 시험했습니다. 이번에 확인할 것은 일정과 할 일을 읽고 설명하는 흐름이었습니다. 조회가 된다는 이유로 일정을 옮기거나 할 일을 완료 처리하는 기능까지 같은 결과로 묶을 수는 없습니다.

나중에 쓰기를 연결하면 완료 기준도 달라집니다. “바꿨습니다”라는 답 뒤에 실제 상태를 다시 조회할 수 있어야 합니다. 같은 요청을 다시 보냈을 때 중복으로 처리하지 않는지도 확인해야 합니다. 이는 이번 조회 시험에서 끝낸 일이 아니라 다음 단계에서 검증할 부분입니다.

답변의 품질을 볼 때도 출처를 읽은 과정과 실제 변경 결과를 구분해야겠다고 생각했습니다. 이 구분이 있어야 무엇을 이미 맡길 수 있고 무엇을 더 확인해야 하는지 알 수 있습니다.

기능마다 확인한 단계가 다릅니다

조회 이후에는 회의록을 만들고 검토하는 화면을 붙였습니다. 할 일을 저장할 서비스와 위키로 변경을 보내는 부분도 별도로 준비했습니다. 다음은 9월 28일에 기록을 대조한 상태입니다.

부분	확인한 범위	아직 남은 연결
일정과 할 일 조회	두 비서의 실제 도구 사용, 시간대·페이지 처리, 쓰기 차단	상태를 바꾸는 실제 업무 흐름
회의록 화면	9월 22~23일 단계별 검토·편집·문서 생성 기능 배포	문서에서 후속 업무와 전체 위키 반영까지 이어가기
업무 기록 서비스	DB와 수정 버전·중복 요청 처리 등의 구현, 합성 자료로 통합 시험	실제 업무의 기준 기록 전환과 화면·비서 연결
위키 동기화	변경을 보내고 받는 구현 브랜치와 보완 과제	서버 통합·충돌·재시도 처리 및 운영 확인

회의록에서 사람의 수정이 다음 문서의 입력으로 이어지는 것은 확인한 구현입니다. 그것이 회의에서 나온 할 일을 자동 등록하고 여러 기기에서 완료 처리하는 기능까지 뜻하지는 않습니다. 하나의 화면 안에서 이어지는 과정과 여러 서비스가 공유하는 업무 흐름은 따로 확인해야 했습니다.

도메인별 DB를 먼저 활용하기로 한 방향은 있지만 도입 작업은 전체 구조 검토와 함께 대기 중입니다.

구조를 다시 검토하는 동안

기능을 직접 붙이다 보니 요청 창구와 AI 실행 도구를 얼마나 직접 만들어야 하는지도 다시 보게 됐습니다. 9월 28일에는 새 구현·병합·설치·배포를 멈추고 최종 구조를 재검토하기로 했습니다. 현재 동작하는 기능을 되돌리는 결정은 아닙니다.

비교할 방향에는 공급사가 제공하는 원격 작업 세션, 별도 비서 프로그램을 통한 연결, 필요한 도구를 직접 잇는 구성이 있습니다. 아직 어느 방식이 제 작업에 더 적합한지 같은 조건의 시험으로 결론 내리지는 않았습니다. 검토 중 먼저 나온 제품 추천을 최종 채택으로 쓰지 않으려 합니다.

방식이 달라도 확인해야 할 장면은 구체적입니다. 컴퓨터에서 요청한 검토를 휴대폰에서 찾아 후속 지시할 수 있는지, 다른 도구에 넘겨도 원래 요청과 대상 문서가 남는지, 실행이 끊긴 뒤 결과를 다시 확인할 수 있는지입니다. 이들은 앞으로 비교할 요구이며 현재의 성공 사례가 아닙니다.

지금까지 얻은 것은 연결 기능의 목록보다, 완료를 판단할 때 볼 항목입니다. 조회했다면 기간과 누락을 보고, 저장했다면 실제 기록을 다시 읽고, 검토했다면 어느 버전의 결과인지 확인합니다. 다음 구조를 고를 때도 이 요청과 기록이 이어지는지를 기준으로 삼으려 합니다.