저장해 달라는 말만 메모로 남기기 | AI 노트앱 만들기 11

바이브코딩 실전 · 서버와 AI 연결 11편

수신된 말과 저장하기로 한 메모는 같은 것이 아니다.

받았다는 말은 저장했다는 뜻일까?

10편에서 텔레그램 메시지는 서버의 비공개 SQLite에 도착하고 고정 안내를 돌려주기 시작했다. 그러나 수신과 메모 저장은 다른 사건이다. 질문도 서버에는 도착하고, 설명을 위해 적은 인용문도 수신 기록에는 남는다. 이 모든 입력을 곧바로 노션 페이지로 만들면 대화와 메모가 섞이고, 사용자가 남길 생각이 없던 문장까지 보관함을 채운다. 대화창에서 “받았다”는 안내를 보았다는 이유만으로 노션 저장까지 성공했다고 이해해서도 안 된다. 수신 안내는 서버 입구의 결과이고, 페이지 생성은 별도의 저장 조건과 확인을 통과한 뒤의 결과다.

그래서 0.2 단계에서는 임시로 아주 단순한 규칙을 택한다. 사용자가 일반 텍스트의 맨 앞에서 저장을 분명히 요청한 경우만 새 노션 준비 공간에 쓴다. 질문인지 메모인지 AI가 추측하지 않는다. 이 단계의 AI 호출은 0회다. 사용자의 표현이 명확하면 정해진 저장 경로로 보내고, 그렇지 않으면 노션 페이지를 만들지 않는다.

어떤 문장이 저장 요청이 될까?

명시 저장에는 /save 내용, 저장해줘: 내용, 메모로 저장해줘: 내용처럼 시작부터 의도가 드러나는 형식을 쓴다. 명령 뒤에 줄바꿈이 이어져도 본문으로 받을 수 있다. 반면 일반 질문, 부정문, 시작·도움말 명령, 저장 문구를 설명하기 위해 인용한 예시는 자동 저장하지 않는다. 사진이나 파일도 이 단계에서는 원본을 갖추지 못했으므로 노션 메모로 만들지 않는다.

이 규칙은 완성된 대화 경험이라기보다 안전한 첫 연결이다. 매번 형식을 맞춰야 하는 불편은 있지만, 아직 AI가 의도를 판단하지 않는 상태에서 사용자의 저장 결정을 가장 직접적으로 남긴다. 이후 애매한 말에 확인 버튼을 보여 주는 기능을 더하더라도, 명시 저장은 AI를 거치지 않는 빠르고 예측 가능한 통로로 남길 수 있다.

실제 원문은 어디까지 같았을까?

실제 연결 시험에서는 질문과 인용문 두 건이 노션에 쓰이지 않았고, 명시한 저장 요청 한 건만 새 페이지를 만들었다. 저장한 내용은 공개용 예시가 아니라 기능 확인을 위한 가상 원문이었다. 개인 메모를 공개하지 않으면서도 여러 줄, 한글, 확장 유니코드, 따옴표, 역슬래시처럼 전송 과정에서 달라지기 쉬운 문자를 포함했다.

서버가 받은 원문과 노션에서 다시 읽은 본문을 문자 단위로 대조한 결과, 초기 실제 원문 150자가 일치했다. 입력창에서는 화면 표현 때문에 줄바꿈이 더 많아 보일 수 있었지만, 실제 전송 원문과 저장 결과는 처음 의도한 줄바꿈 그대로였다. 페이지가 생겼다는 사실만 보지 않고, 무엇이 저장됐는지 다시 읽어 확인해야 저장 완료라고 말할 수 있다. 제목이나 앞부분만 맞는 것으로는 부족하다. 전체 본문을 읽어 길이와 문자를 대조해야 따옴표나 줄바꿈이 전송 중 달라진 문제까지 발견할 수 있다.

SQLite 기록과 노션 페이지는 어떻게 다를까?

SQLite는 텔레그램에서 무엇을 받았고 어떤 처리를 시도했는지 관리하는 서버 내부 장부다. 질문과 인용도 여기에 수신 기록으로 남을 수 있다. 노션은 사용자가 메모로 남기겠다고 분명히 정한 내용을 보는 준비 공간이다. 따라서 “질문은 저장하지 않는다”는 말은 서버에 흔적이 전혀 없다는 뜻이 아니라, 질문으로 노션 메모 페이지를 만들지 않는다는 뜻이다.

노션에 저장된 페이지도 아직 기존 메모 웹앱에는 나타나지 않는다. 기존 웹앱은 운영 원본을 계속 읽고, 이번 저장은 별도의 준비 공간을 향한다. 노션에 한 페이지가 생겼다는 사실과 기존 앱의 입력 경로가 전환됐다는 사실을 구분해야 한다. 요약·분류·관계 속성도 자동 생성하지 않으며, 원문을 보존한 새 메모 한 건만 만든다.

중복과 불확실한 저장은 어떻게 다룰까?

저장을 요청한 동일한 텔레그램 메시지가 다시 전달되면 이미 처리한 메시지로 보고 페이지를 더 만들지 않는다. 실제 재전달 시험에서도 수신 기록, 안내, 노션 저장 수가 늘지 않았다. 하지만 같은 문구를 사용자가 새 메시지로 다시 보내면 새로운 메시지 식별값이 생긴다. 내용이 같다는 이유만으로 앞선 메시지와 합칠 수 없고, 별도의 저장 요청으로 처리될 수 있다.

이 차이는 응답이 늦거나 끊겼을 때 특히 중요하다. 노션 생성 요청을 보낸 뒤 결과를 확실히 확인하지 못했다고 같은 내용을 새 메시지로 보내면, 첫 저장이 성공했을 경우 두 페이지가 생길 수 있다. 그래서 생성 요청은 한 번만 보내고, 결과가 불확실하면 자동으로 다시 만들지 않는다. 이미 있는 페이지를 읽어 원문과 식별 정보를 대조할 뿐이다. 사용자에게도 불확실 안내가 오면 같은 내용을 재전송하지 말고 확인을 기다리도록 알린다. 이때 복구 동작은 새 페이지를 만드는 쓰기가 아니라, 이미 생성된 결과가 있는지 읽어서 대조하는 일에 한정한다.

명시 저장 규칙을 어떻게 부탁할까?

독자가 바꿔 쓸 요청 예시이며 실제 발언 인용이 아니다.

텔레그램 수신 기록과 노션 메모 생성을 분리해 줘.
“저장해줘:”처럼 명시한 일반 텍스트만 새 준비 공간에 저장해 줘.
질문, 인용 예시, 애매한 문장은 노션에 쓰지 말아 줘.
저장할 때는 원문을 줄바꿈과 기호까지 다시 읽어 대조해 줘.
결과가 불확실하면 자동 재생성하거나 같은 내용을 재전송하지 말고 조회만 해 줘.

설명용 메모로 시험한다면 “베란다 텃밭 초보를 위한 책 목차”처럼 공개해도 되는 가상 내용을 쓸 수 있다. 먼저 일반 질문으로 보내 노션 페이지가 생기지 않는지 보고, 다음에는 저장 문구를 앞에 붙여 원문 한 건이 생성되는지 확인한다. 그 뒤 같은 텔레그램 메시지의 재전달이 새 페이지를 만들지 않는지도 살핀다.

11편에서 얻는 것은 화려한 자동 정리가 아니라 저장 결정의 기준이다. 서버는 대화를 받되, 노션에는 명시한 원문만 남긴다. AI는 이 판단에 참여하지 않고, 저장 뒤에는 원문을 다시 읽어 확인한다. 다음 단계에서 질문에 답하고 애매한 입력에 되묻는 기능을 더하더라도, 이 경계가 있어야 대화가 사용자의 승인 없이 메모로 바뀌지 않는다.

기록 기준: 2026년 10월 21~22일. 이 글은 수신기 0.2의 명시 저장 시험을 바탕으로 썼다. 실제 시험 원문은 공개하지 않고 길이와 문자 단위 대조 결과만 밝혔다.

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