바이브코딩 실전 · 서버 확장 준비 9편
대화창 하나로 메모와 질문을 받되, 모든 대화를 저장하지 않는다.
그록봇에 가볍게 남긴 메모를 노션에 모으고, 별도의 웹앱에서 읽는 흐름을 만들었다. 8편까지는 이 읽는 화면과 원본을 바꾸는 버튼의 경계를 다뤘다. 이제 입력 통로를 텔레그램으로 넓히려 한다. 이번 편은 완성된 봇 사용법이 아니라, 새 봇을 준비하며 무엇을 결정했고 어디까지 확인했는지 정리한 기록이다.
왜 텔레그램으로 입력을 넓힐까?
출발점은 새 앱을 하나 더 갖는 일이 아니다. 제목과 태그를 먼저 정하지 않고도 생각 한 줄이나 링크를 남기려는 것이다. 다만 개발을 도와주는 AI 도구와, 평소 메시지를 받아 처리하는 서버의 역할은 나눈다. Aside는 만들고 고치고 배포하는 일을 돕고, 완성 뒤의 수신·정리·알림은 서버가 맡도록 방향을 정한다. 맥을 끈 뒤에도 입력이 처리되는 구조가 목표지만, 지금 그 동작이 검증된 것은 아니다.
기존 그록봇과 새 서버를 동시에 원본을 고치는 주체로 두기보다, 전환 후 입력과 후처리를 서버 한쪽으로 모으려 한다. 기존 입력을 중단하는 시점은 새 경로의 실제 저장 시험을 통과한 뒤다. 설계를 골랐다는 이유로 지금 쓰는 봇이나 웹앱부터 바꾸지는 않는다.
새 보관함은 복사만 하면 끝날까?
메모 전용 노션 공간에 준비본을 만들고, 기존 속성·본문·사진·메모 사이의 관계를 대조한다. 복사된 메모는 식별값이 달라지므로 관계도 새 대상을 가리키도록 맞춰야 한다. 새 연결이 준비한 두 데이터베이스를 읽고 수정하고 생성할 수 있는지도 따로 확인한다. 이 결과를 기존 웹앱 연결의 쓰기 권한까지 검증한 것으로 확대하지 않는다.
준비본은 실시간 동기화가 아니다. 복사 뒤 기존 보관함에 새 메모가 들어오면 둘의 내용은 다시 달라질 수 있다. 현재 웹앱과 그록봇은 기존 원본을 계속 사용한다. 실제 전환 직전에는 그동안 생긴 변경분을 다시 대조하고, 입력을 잠시 멈출 시점과 새 설정을 적용할 순서를 정해야 한다. 새 보관함을 만든 일과 원본을 옮겨 쓰기 시작한 일은 다른 단계다.
메모와 질문을 어떻게 구분할까?
처음에는 메모 모드와 대화 모드를 나누는 방안도 살폈지만, 사용자는 말하기 전에 매번 모드를 고르는 방식을 원하지 않았다. 방향을 바꿔 메시지와 대화 맥락으로 의도를 판단하되, 애매할 때만 확인하도록 설계한다. 질문에 붙인 링크와 사진을 무조건 메모로 저장하지 않고, 짧은 후속 답변도 새 메모로 오인하지 않게 하는 것이다.
명확한 저장 요청은 저장 대상으로, 명확한 질문은 답변 대상으로 나눈다. 대화하다 발전시킨 아이디어도 사용자가 정리해 저장하라고 할 때 기획서 한 건으로 남기는 방향이다. 그때 사용자 결정과 AI 제안, 아직 정하지 않은 항목을 구분한다. 자동 의도 판단과 기획서 저장은 아직 구현 전이며, 아래 그림은 그 규칙을 설명하기 위해 새로 만든 예시다.
봇이 답하면 서버도 연결된 것일까?
새 전용 봇은 생성했고 그룹에 초대되지 않도록 설정했다. 소유자가 보낸 시작 메시지를 확인하고, Bot API로 직접 보낸 안내가 도착하는 것까지 살폈다. 여기까지는 텔레그램 쪽 기본 송수신 확인이다. 메시지를 처리할 서버 주소를 등록하는 웹훅은 아직 없으므로, 새 봇에 말을 걸었다고 PHP 서버가 읽고 노션에 저장하는 상태는 아니다.
토큰은 봇을 제어하는 비밀값이므로 소스나 배포 예시에 넣지 않고 비밀 저장소에 분리했다. 수신기에는 허용된 소유자의 개인 대화만 받도록 검사하는 코드를 준비했다. 그룹 초대를 막았다는 사실만으로 서버의 사용자 검사까지 끝났다고 말할 수는 없다. Claude API를 쓰기로 정한 일도 공급자 선택일 뿐이며, 실제 연결과 모델 호출은 아직 진행하지 않았다.
코드 준비와 실행 확인은 다르다
수신기는 PHP와 서버의 예약 작업을 쓰는 방향으로 준비했다. 들어온 요청은 짧게 받고, 시간이 걸리는 처리와 나누어 맡기려는 구조다. 같은 메시지가 다시 들어왔을 때 중복 처리하지 않도록 식별값과 상태를 남기는 코드도 포함했다. 저장 결과가 불확실한 쓰기는 무조건 다시 보내지 않는다는 원칙은 앞선 읽음 버튼과 같다.
검사 항목 60개를 준비했지만 실행한 검사는 0개다. 로컬에 PHP 실행 환경이 없어 문법·동작 시험을 하지 못했다. 정적 검토에서 JSON 처리에 쓴 잘못된 상수를 세 곳 찾아 수정하고 재확인했으나, 이것 역시 실제 실행 검증을 대신하지 않는다. 파일이 있다는 말, 검토했다는 말, 서버에서 왕복했다는 말을 완료 보고에서 나누는 이유다.
외부 장애가 나면 어디서 멈출까?
서버에 올리는 단계에서는 Hostinger 관리 화면과 API 장애에 막혔다. 2026년 10월 20일 이 글을 준비하며 확인한 공식 공지는 관리 도구의 중단과 기존 호스팅 사이트의 정상 운영을 구분했고, 복구 예정 시각은 제시하지 않았다. 사이트가 열리는데 관리 화면은 작동하지 않는 상황이 가능하다는 뜻이다. 이 기록을 읽는 시점의 장애 여부는 아래 공식 공지에서 다시 확인해야 한다.
외부 장애를 계정 문제로 단정해 비밀번호나 로그인 방식을 바꾸지 않았다. 서버 업로드와 웹훅 등록도 진행한 것처럼 기록하지 않는다. 그동안 할 수 있는 일은 비밀값 없는 소스 검토와 검수 기준 정리다. 반복해서 시도하는 것보다 어디서 멈췄는지를 남겨야 다음 사람이 같은 구간을 다시 추측하지 않는다.
다음에 확인할 순서를 적는다
- 관리 도구가 복구되면 실제 서버 경로와 PHP 확장을 확인한다.
- 비공개 설정과 코드를 배포하고 서버 자체 검사부터 실행한다.
- 허용하지 않은 사용자와 중복 입력이 거절되는지 확인한다.
- 새 봇에만 웹훅을 등록하고 실제 텔레그램 메시지의 서버 왕복을 시험한다.
- 그다음 노션 저장과 AI 처리를 단계별로 연결하고, 마지막에 기존 입력의 전환을 결정한다.
다음은 독자가 바꿔 쓸 실습용 요청문이며, 당시 사용자 발언을 옮긴 인용문은 아니다.
기존 메모와 입력 경로를 유지한 채 새 텔레그램 수신기를 준비해 줘.
완료·코드 준비·실행 미검증·미연결을 나누어 보고해 줘.
비밀값은 소스와 설명 이미지에 넣지 마.
질문은 자동 저장하지 않고, 애매한 입력만 확인하도록 설계해 줘.
중복 입력과 결과 불확실 쓰기를 구분해 줘.
기존 운영 전환은 새 경로의 실제 저장을 확인한 뒤 별도로 결정해 줘.이번에 완성한 것은 모든 메시지를 처리하는 서비스가 아니라, 다음 연결을 안전하게 확인할 출발점이다. 메모를 남길 때 정리까지 해야 하는 부담은 덜되, 무엇을 저장할지는 사용자의 뜻을 따른다. 편한 입력과 함부로 저장하지 않는 동작을 함께 만드는 것이 이번 확장의 기준이다.
기록 기준: 2026년 10월 20일. 전용 노션 준비본 대조와 새 봇의 기본 API 송수신은 확인했다. 새 PHP 수신기 실행·서버 배포·웹훅·노션 저장·AI 처리의 전체 경로는 미검증 또는 미연결이다. 개인 메모·인증정보·실제 계정 화면은 싣지 않았고, 도판은 모두 설명용으로 제작했다.
직접 확인할 공식 자료
- 텔레그램 Bot API기본 API 요청과 업데이트 수신 방식의 공식 문서.
- 텔레그램 웹훅 안내봇 생성 뒤 메시지를 서버에 전달하는 연결은 별도로 구성한다.
- 노션 연결과 권한새 연결의 접근 범위와 기존 연결의 권한을 혼동하지 않는다.
- 이 기록에 해당하는 Hostinger 장애 공지본문의 관찰 시점과 현재 상태를 구분해 읽는다.
이 글은 실제 제작 기록을 바탕으로 AI의 도움을 받아 구성하고 검수했다. 구현된 동작과 설계 예시를 구분했다.