텔레그램 메시지가 서버에 닿기까지 | AI 노트앱 만들기 10

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

준비해 둔 수신기가 실제 메시지를 받고 안내를 돌려준다.

9편의 점선은 어디까지 이어졌을까?

9편에서는 텔레그램을 새 입력 통로로 쓰기 위한 코드와 구조를 준비했지만, 서버에서 실행하지는 못했다. 새 봇에 메시지를 보내도 서버가 받는 웹훅이 연결되지 않았고, 준비한 검사도 실제 PHP 환경에서는 돌리지 못한 상태였다. 이번에는 그 점선을 실제 왕복으로 잇는다. 서버에 수신기를 배치하고 텔레그램이 메시지를 전달할 입구를 등록한 뒤, 들어온 메시지가 기록되고 고정 안내가 대화창으로 돌아오는지 확인한다.

중요한 변화는 기능이 많아졌다는 데 있지 않다. 코드가 준비됐다와 운영 환경에서 한 번 왕복했다 사이의 빈칸을 채웠다는 데 있다. 연결 직전 대기하던 시작 메시지 한 건이 서버의 비공개 기록에 들어왔고, 수신했다는 안내도 실제 텔레그램 대화에 도착했다. 이로써 9편에서 미실행으로 남긴 입구, 기록, 안내의 세 구간이 실제 환경에서 이어진다. 이 과정에서도 기존 그록봇과 메모 웹앱, 운영 중인 노션 원본은 바꾸지 않는다. 새 통로를 확인하는 일과 기존 입력을 전환하는 일은 여전히 다른 결정이다.

메시지는 어떤 순서로 움직일까?

사용자가 텔레그램에 글을 보내면 텔레그램은 등록된 서버 입구로 업데이트를 전달한다. 수신기는 요청의 형식과 크기를 살피고, 허용한 개인 대화인지 확인한 다음 내용을 비공개 SQLite에 기록한다. 그 뒤에는 “메시지를 받았다”는 고정 안내를 보낸다. 사용자가 보는 말풍선은 이 마지막 단계의 결과다. 안내가 도착했다면 텔레그램에서 서버로 들어왔다가 다시 텔레그램으로 나가는 기본 왕복이 성립한 것이다. 서버가 요청을 받았다는 웹 응답과 사용자의 대화창에 보이는 안내도 같은 것이 아니다. 두 결과를 따로 확인해야 입구만 열리고 안내는 빠지는 상황을 놓치지 않는다.

이때 SQLite는 서버 안에서 수신 사실과 처리 상태를 관리하는 작은 장부다. 아직 노션 메모 페이지를 만드는 곳은 아니다. 메시지 본문과 첨부 정보가 수신 기록에 남더라도, 정리·요약·분류가 일어나지는 않는다. 사진 원본을 내려받는 기능도 없고 예약 작업도 없다. 10편의 완료선은 일상 입력을 모두 처리하는 서비스가 아니라, 허용한 메시지를 잃지 않고 받아 고정된 답을 돌려주는 수신 통로다.

누가 보낸 메시지인지 왜 먼저 확인할까?

메모는 공개 게시물이 아니므로 서버가 아무 대화나 받아서는 안 된다. 새 수신기는 지정한 소유자의 개인 대화만 처리한다. 다른 사용자가 보내거나 그룹에서 들어온 메시지는 메모로 받아들이지 않는다. 텔레그램에서 그룹 초대를 막는 설정과 서버가 발신자를 검사하는 일도 따로 확인한다. 앞의 설정만으로 뒤의 검사가 끝났다고 보지 않는 이유다.

허용하지 않은 입력에는 자세한 내부 이유를 돌려주지 않고, 서버는 처리 대상이 아니라는 상태만 남긴다. 반대로 허용한 메시지도 곧바로 노션이나 AI로 넘기지 않는다. 이 단계에서는 수신 장부와 안내까지만 움직인다. 접근 범위를 먼저 좁히면 다음 단계에서 저장 기능을 붙일 때도 “메시지가 도착했다”와 “메모로 쓰기로 했다”를 분리할 수 있다.

같은 메시지와 같은 문구는 무엇이 다를까?

통신 과정에서는 텔레그램이 이미 보낸 메시지를 다시 전달할 수 있다. 서버는 텔레그램이 붙인 메시지 식별 정보를 기준으로 같은 전달인지 확인한다. 실제 확인에서도 동일한 업데이트나 동일한 대화의 동일 메시지를 다시 전달했을 때 중복으로 처리됐고, 수신 기록과 안내는 더 늘지 않았다. 같은 사건을 두 번 세지 않기 위한 경계가 실제 서버에서 작동한 것이다.

하지만 사용자가 같은 문장을 복사해 새 메시지로 한 번 더 보내는 경우는 다르다. 문구가 같아도 텔레그램에서는 새로운 메시지이므로 별도의 입력으로 취급될 수 있다. 내용만 비교해 무조건 지우면 사용자가 의도해 두 번 남긴 기록까지 잃을 수 있다. 따라서 같은 메시지의 재전달은 중복으로 막고, 같은 문구의 새 메시지는 새 사건으로 본다. 이후 저장 결과가 불확실할 때 같은 문구를 다시 보내지 말아야 하는 이유도 여기에 있다. 중복 방지는 글자 비교가 아니라 한 메시지의 전달 이력을 기준으로 삼아야 사용자의 반복 입력을 임의로 지우지 않는다.

AI와 노션은 왜 아직 움직이지 않을까?

수신기가 연결됐다고 해서 AI 비서가 완성된 것은 아니다. 이 왕복에서는 Claude API를 호출하지 않았고, 노션 저장도 꺼져 있었다. 메시지를 질문으로 판단하거나 내용을 요약하는 기능도 없다. 고정 안내는 AI가 만든 답변이 아니라 서버가 미리 정한 문장이다. 이렇게 단계를 좁혀 두면 문제가 생겼을 때 텔레그램 전달, 서버 기록, 외부 저장 가운데 어디에서 멈췄는지 찾기 쉽다.

검사도 숫자를 크게 보여 주는 데 목적이 있지 않다. 정상 요청뿐 아니라 잘못된 형식, 허용하지 않은 발신자, 중복 전달이 수신 경계를 넘지 않는지 살폈고, 비공개 설정과 기록이 공개 주소에서 열리지 않는지도 확인했다. 다만 이를 모든 공격과 장애를 막았다는 보증으로 넓히지는 않는다. 이번 단계가 확인한 것은 정해 둔 입구와 규칙이 실제 운영 환경에서 작동한다는 사실이다.

내 서비스에서는 무엇을 요청하면 좋을까?

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

기존 서비스는 바꾸지 말고 새 메시지 수신 경로만 실제로 연결해 줘.
누가 보낸 어떤 메시지를 받을지 먼저 제한해 줘.
텔레그램 수신, SQLite 기록, 안내 전송을 각각 확인해 줘.
같은 메시지의 재전달과 같은 문구를 새로 보낸 경우를 구분해 줘.
노션 저장과 AI 처리는 아직 연결하지 말고 남은 일로 보고해 줘.

요청의 핵심은 처음부터 저장과 AI 기능을 한꺼번에 붙이지 않는 것이다. 먼저 한 종류의 메시지가 서버까지 도착하고 한 번만 기록되는지 확인한다. 다음으로 안내가 실제 대화에 돌아오는지 본다. 이 작은 왕복이 확인돼야 저장 단계의 실패를 수신 실패와 혼동하지 않는다.

이제 텔레그램은 준비 화면 속 도식이 아니라 실제 입력 통로가 된다. 다만 통로가 열렸다는 사실만으로 모든 말을 메모로 만들지는 않는다. 다음 편에서는 서버에 도착한 메시지 가운데 사용자가 분명히 “저장해 달라”고 한 내용만 새 노션 준비 공간에 남기는 규칙을 연결한다.

기록 기준: 2026년 10월 21~22일. 이 글은 텔레그램 수신기 0.1 운영 연결과 실제 왕복 기록을 바탕으로 썼다. 노션 저장과 AI 처리는 이 단계에서 실행하지 않았다.

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