저장 완료 뒤에도 원문과 분류를 확인하는 이유 | AI 노트앱 만들기 17

나만의 AI 노트앱 만들기 · 17

긴 원문을 직접 보존하고, 분류와 영역을 맞춰 다시 찾아 읽기 좋은 메모로 다듬었다.

원문과 분류까지 갖춘 저장 결과 만들기

장문은 서버에 도착한 저장 대상 메시지에서 직접 가져오고, 모델에는 제목과 정리처럼 판단이 필요한 부분을 맡기는 구조로 고쳤다. 기존 메모를 보완한 뒤 원문의 끝부분과 분류를 다시 읽어 확인했다. 새 항목을 늘리지 않고 필요한 내용을 채웠으며, 검토 필요 표시도 유지했다.

이 확인을 모든 저장의 의무 절차로 삼지는 않았다. 일상 저장은 생성 응답을 확인하는 경로로 처리하되, 그것을 전체 속성과 본문을 다시 조회한 검증처럼 안내하지 않는다. 누락이나 오분류가 의심되는 항목은 따로 읽어 확인한다. 새 메모를 만드는 일과 기존 메모의 빠진 내용을 보완하는 일을 구분해야, 문제를 고치면서 중복 항목까지 늘리는 일을 피할 수 있다.

입력부터 저장까지 장문 처리 범위 맞추기

문장이 빠졌다고 노션의 저장 한도부터 늘리면 원인을 놓칠 수 있다. 메시지가 서버에 들어오는 크기, 현재 요청에 넣는 범위, 이전 대화를 다시 전달하는 범위, 첨부 텍스트를 읽는 범위가 각각 다르다. 그 뒤에도 모델 도구 입력, 저장 스키마, 실제 본문 쓰기 단계의 상한이 남아 있다. 앞에서 이미 빠진 문장은 뒤의 저장 공간이 넉넉해져도 돌아오지 않는다.

이전 자료 저장에서는 대화 입력 단계에 원문 일부가 전달되지 않아 정리본만 남았다. 이를 원문 전체 보존으로 보고하지 않았다. 수정할 때도 저장 단계 하나에만 손대지 않고 입력부터 저장까지 여러 구간의 상한을 함께 늘렸다. 이후 특정 기존 메모를 다시 읽어 원문의 마지막 부분이 보이는지 확인했다. 어디를 바꿨는지와 어느 자료를 다시 읽었는지를 함께 남겨야 수정 결과를 설명할 수 있다.

그렇다고 모든 장문과 첨부 형식이 통과한다고 말할 수는 없다. 텔레그램 자체의 입력 방식과 외부 서비스 제한도 남아 있으며, 이번에는 관련 항목을 확인했을 뿐 전체 기능을 전수 검사하지 않았다. 장문 지원을 비교할 때 처리 가능한 글자 수 하나만 묻기보다, 자료가 전달되는 각 구간에서 무엇을 받아 무엇을 넘기는지 살피는 이유다.

원문은 모델의 출력 밖으로 옮긴다

긴 원문을 모델에게 그대로 다시 출력하게 하고 그 답을 저장하는 방법에도 문제가 있다. 다시 쓰는 동안 요약이나 생략, 문장 교정이 끼어들 수 있고, 출력 상한에 닿으면 또 잘린다. 원문 보존 경로를 모델의 재작성과 분리한 까닭이다. 같은 소유자가 보낸 저장 대상 메시지는 서버 기록에서 직접 읽어 본문과 원문 영역에 넣고, 모델에는 제목이나 정리처럼 판단이 필요한 부분을 맡겼다.

긴 원문은 저장 서비스가 받아들일 수 있는 블록 단위로 나누어 쓴다. 일부 블록의 쓰기 결과가 불확실할 때 같은 내용을 새 페이지로 자동 재생성하지는 않는다. 이미 들어간 내용이 있을 수 있으므로, 실패 안내를 곧바로 새 항목 생성의 근거로 삼아서는 안 된다. 기존 기록을 보완하는 경로와 새로 만드는 경로가 이 지점에서도 갈린다.

서버에서 직접 옮겼다는 사실은 모델이 원문을 이해했다는 증거가 아니다. 서버에 도착한 문자열을 가능한 한 그대로 보존하는 방식이며, 수신 전에 빠진 내용까지 복원하지는 못한다. 또한 다른 사용자의 메시지나 관련 없는 대화를 가져오지 않도록 소유자와 저장 요청의 대응을 확인해야 한다. 수정한 장문 메모의 끝부분을 다시 읽은 것도 이런 전달 범위를 점검하는 일이었다.

미정 분류도 받아들이도록 저장 형식 개선하기

원문을 보완하면서 화면의 분류와 내용의 영역도 따로 맞췄다. 분류는 보관함에서 묶어 찾는 기존 선택값이고, 영역은 메모가 속한 활동 분야를 나타내는 별도 속성이다. 책 기획 분류의 메모가 출판 영역에 속할 수 있다. 둘을 같은 값으로 다루면 영역만 채워지고 목록 분류가 비거나, 분류 이름을 영역에 그대로 복사하게 된다. 실제 수정에서도 기존 메모 한 건의 두 값을 각각 맞춘 뒤 화면의 분류와 원문 끝부분을 함께 확인했다.

그 과정에서 분류를 추론하지 못하면 category 필드에 null이 남아 메모 전체가 유효하지 않다고 거절되는 오류가 드러났다. 본문 내용이 잘못된 것이 아니라, 선택값이 정해지지 않은 상태를 저장 형식에서 잘못 표현한 검증 버그였다. 수정 뒤에는 사용할 수 있는 기본 분류를 고르거나, 결정되지 않은 필드를 아예 보내지 않게 했다. 분류가 아직 없는 상태를 잘못된 분류값과 구별하면 본문까지 함께 버리는 일을 막을 수 있다.

유튜브 주소만 저장한 기록의 기준

링크 메모는 무엇을 저장했는지에 따라 확인 항목도 달라진다. 주소만 보낸 유튜브 링크는 미분석 북마크로 먼저 남기도록 경로를 나누었다. 영상 식별값으로 같은 주소의 반복 저장을 줄이고, 제목이나 본문에 링크를 보존하되 분석 성공으로 표시하지 않는다. 이 선저장 경로에서 모델 호출은 0회였다. 링크 보관을 위해 모델이 영상을 읽거나 내용을 정리한 것은 아니다.

북마크를 확인할 때는 원본 주소가 맞는지, 어떤 기준으로 중복을 억제하는지, 미분석 상태가 표시되는지를 보면 된다. 질문이나 분석 요청이 함께 왔다면 별도의 대화와 도구 경로가 필요하다. 그 결과를 분석 메모라고 부르려면 영상 프레임, 음성 전사, 주제 요약 가운데 실제로 처리한 범위와 실패한 지점을 밝혀야 한다. 주소가 노션에 들어간 사실만으로 영상 전체를 이해했다고 소개할 수는 없다.

메시지 한 건 안의 여러 호출

저장 뒤에 무엇을 더 확인할지는 사용량과도 연결된다. 사용자가 텔레그램 메시지를 한 번 보냈더라도 모델 호출은 여러 번 일어날 수 있다. 답을 계획하는 호출 뒤에 메모 검색이나 저장 도구를 선택하고, 도구 결과를 읽어 최종 답변을 만드는 호출이 이어진다. 수정과 재확인이 붙으면 같은 메시지 안에서 호출이 더 늘어난다. 초기에 둔 일일 호출 상한이 메시지 수보다 먼저 찬 이유다.

한도 정책은 이후 별도로 조정했지만, 메시지 수와 모델 호출 수가 다른 단위라는 점은 바뀌지 않는다. 사용량 화면에서도 둘을 따로 읽어야 한다. 다음 요청은 장문 보존 경로를 처음 점검하거나 누락이 의심되는 메모를 보완할 때 쓴다. 일상 저장의 기본 절차와는 구분해, 문제가 생긴 자료에 확인을 집중하는 방식이다.

장문 메모를 저장할 때 모델이 원문을 다시 작성하지 말고, 같은 사용자의 저장 대상 메시지를 서버 기록에서 직접 보존해줘. 저장 뒤에는 원문의 마지막 부분과 분류·영역을 다시 읽고, 분류를 정하지 못했으면 null을 잘못된 값으로 보내 전체 저장을 실패시키지 마. 유튜브 주소만 오면 모델 없이 미분석 북마크로 먼저 저장하고, 분석했다고 표현하지 마. 한 메시지에서 도구 사용과 최종 답변 때문에 모델 호출이 여러 번 생길 수 있으니 메시지 수와 호출 수를 따로 기록해줘.

이 요청의 결과를 볼 때는 저장 응답과 원문 끝부분, 분류와 영역을 각각 대조한다. 값이 정해지지 않았다는 이유로 본문 전체가 거절되지 않는지도 살핀다. 링크만 남겼다면 미분석 표시까지 확인하고, 이 과정에서 발생한 호출은 메시지 수와 별도로 집계한다. 다시 읽기를 어디에 썼는지 알 수 있어야 누락을 바로잡은 효과와 확인에 든 사용량을 함께 판단할 수 있다.

기록 기준: 2026년 10월 22~23일. 제한된 실사용과 수정 기록을 바탕으로 썼다. 구현된 권한과 실제 확인한 동작을 구분하며 전수 검증이나 모든 자료의 성공을 뜻하지 않는다. 계정 정보·개인 메모·키·내부 식별값은 싣지 않는다.

이 글은 실제 제작 기록을 바탕으로 AI의 도움을 받아 구성하고 검수했다. 구현된 동작과 설명용 예시를 구분했다.