질문에는 답하고, 애매하면 되묻는 봇 | AI 노트앱 만들기 12

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

연결에 성공한 AI가 곧 대화할 줄 아는 것은 아니다.

연결 확인과 대화 구현은 무엇이 다른가?

앞 단계에서 확인한 것은 서버가 AI 서비스에 닿고, 정해 둔 모델이 정해 둔 짧은 문장에 예상한 답을 돌려주는지다. 이 검사는 수도관에 물이 흐르는지 보는 일과 비슷하다. 물이 나온다고 주방의 동선까지 완성되는 것은 아니다. 어떤 메시지를 질문으로 보고, 어떤 문장을 저장 요청으로 보고, 결과를 어디까지 남길지는 별도의 설계가 필요하다. 그래서 연결 점검에는 개인 메모나 실제 대화를 넣지 않는다. 고정된 가상 문장 한 번으로 모델, 응답 형식, 연결 대상이 맞는지만 확인한다. 이 단계의 성공을 두고 ‘메모 앱이 대화한다’고 말하면 범위를 부풀리게 된다. 일반 질문에 답하고 저장 의도를 구분하는 기능은 다음 버전에서 별도로 붙는다.

실용적인 기준은 단순하다. 연결 점검은 통로를 확인하고, 대화 구현은 행동 규칙을 정한다. 둘을 나누면 연결 장애와 판단 오류를 구별하기 쉽다. 또한 연결은 살아 있지만 대화 기능은 꺼 둔 상태도 정상으로 받아들일 수 있다. 기능을 한꺼번에 켜기보다 작은 경계를 하나씩 검증하는 편이 운영하기 쉽다.

질문은 왜 메모로 저장하지 않는가?

대화 기능이 켜지면 봇은 개인 텍스트를 먼저 질문, 명시적 저장, 확인이 필요한 문장으로 나눈다. 일반 질문은 답변만 보낸다. 예를 들어 계산이나 문장 다듬기처럼 답을 원하는 입력은 노션 페이지를 만들 이유가 없다. 대화와 기록을 구분하지 않으면 잠깐 물어본 내용까지 메모함에 쌓이고, 나중에는 무엇이 의도적으로 남긴 자료인지 알기 어려워진다. 여기서 ‘저장하지 않는다’는 말은 노션 메모 페이지를 만들지 않는다는 뜻이다. 서버는 메시지를 받아 처리해야 하므로 비공개 SQLite에는 수신 기록이 남는다. 질문에 답한 뒤 노션이 늘지 않았다는 사실과, 서버에 아무 흔적도 남지 않았다는 주장은 전혀 다르다. 공개 설명에서도 이 둘을 섞지 않아야 사용자가 실제 데이터 흐름을 이해할 수 있다.

후속 질문에 필요한 문맥도 무제한으로 가져오지 않는다. 같은 대화에서 전송이 확인된 최근 문답 가운데 7일 이내 최대 4쌍만 모델에 붙인다. 이것은 답변에 제공하는 문맥 범위이지 SQLite 기록을 7일 뒤 지우는 보존 정책이 아니다. 짧은 대화의 흐름은 이어 가되, 전체 기록을 늘 읽는 앱처럼 표현하지 않는 것이 정확하다.

저장인지 질문인지 애매하면 어떻게 묻는가?

사람의 문장은 명령어처럼 늘 분명하지 않다. 아이디어를 적어 놓고 끝낼 수도 있고, 그 아이디어에 대한 의견을 기대할 수도 있다. AI가 저장 의도로 추정했다고 바로 노션에 쓰게 하면 편리해 보이지만, 추정이 곧 권한이 되는 문제가 생긴다. 이 앱에서는 모델이 저장이나 확인 필요로 판단해도 쓰기 작업을 만들지 않고 먼저 선택 카드를 보낸다. 카드에는 메모로 저장, 질문으로 답변, 취소 세 버튼이 나온다. 메모로 저장을 고르면 확인한 원문을 저장하고, 질문으로 답변을 고르면 같은 문장을 다시 애매하다고 되묻지 않고 답변한다. 취소를 고르면 노션 페이지를 만들지 않는다. AI는 갈림길을 제안하지만, 어느 길로 갈지는 사람이 정하는 구조다.

사진이나 링크만 도착한 경우에도 저장 승인으로 보지 않는다. 이 단계에는 사진 원본 수집과 링크 본문 가져오기가 없기 때문이다. 처리할 수 없는 재료를 받은 뒤 그럴듯한 메모를 만들어 내기보다, 현재 가능한 범위를 분명히 알리는 편이 낫다. 기능이 없는 곳에서 침묵하거나 추측하는 대신 확인을 요청하는 것이 대화형 앱의 중요한 태도다.

세 버튼을 누른 뒤에는 무엇이 달라지는가?

버튼은 단순한 화면 장식이 아니라 사용자의 결정을 남기는 경계다. 메모로 저장을 누르기 전에는 노션 페이지가 없다. 선택 뒤에는 카드가 보여 준 대상 원문만 새 준비 공간에 저장한다. 질문으로 답변을 누르면 답은 돌아오지만 노션 페이지는 생기지 않는다. 취소한 카드는 나중에 저장으로 되돌릴 수 없도록 닫힌다.

같은 카드의 저장 버튼을 다시 눌러도 페이지를 하나 더 만들지 않는다. 같은 텔레그램 메시지가 다시 전달되는 경우도 이미 받은 메시지로 구분한다. 다만 사용자가 같은 문구를 복사해 새 메시지로 두 번 보내면 메시지 자체가 둘이므로 별도 입력이다. 문장이 같다는 이유만으로 하나로 합치면 서로 다른 시점의 의도를 임의로 지우게 된다.

실패가 불확실한 쓰기도 자동으로 반복하지 않는다. 노션 요청이 성공했는지 분명하지 않은 상태에서 다시 생성하면 중복 페이지가 생길 수 있기 때문이다. 이때는 읽기 전용 대조로 이미 만들어졌는지 확인하고, 근거 없이 재전송하지 않는다. 빠른 재시도보다 한 번의 선택과 한 번의 쓰기를 정확히 결속하는 쪽을 우선한다.

내 봇에는 어떤 요청을 적용할 수 있는가?

자신의 앱에 이 흐름을 적용하려면 모델의 말투보다 먼저 입력별 행동을 적어 보는 것이 좋다. 질문은 어디에 남고, 저장은 어느 표현에서 확정되며, 애매한 입력에는 어떤 선택지를 보여 줄지 정한다. 특히 ‘AI가 저장이라고 판단하면 저장한다’와 ‘AI가 저장 후보라고 판단하면 사람에게 확인한다’는 전혀 다른 설계다.

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

내 개인 텍스트 봇의 입력을 세 갈래로 나눠줘. 명시적 저장 요청은 원문을 저장하고, 일반 질문은 답변만 하되 노션 페이지를 만들지 마. 저장인지 질문인지 애매하면 ‘메모로 저장·질문으로 답변·취소’ 세 버튼으로 확인해줘. 질문의 서버 수신 기록과 노션 저장을 구분하고, 사진이나 링크만으로는 저장을 승인하지 마.

이 요청에서 중요한 부분은 세 버튼의 이름보다 권한의 순서다. 모델은 분류와 답변을 맡고, 저장 승인은 사용자가 맡는다. 구현 뒤에는 각 선택에서 노션 페이지 수가 어떻게 변하는지, 같은 버튼을 다시 눌렀을 때 중복이 생기지 않는지, 취소 뒤 저장이 막히는지를 차례로 확인한다.

이 단계에서 아직 기대하지 말아야 할 것은?

질문에 답하는 봇이 생겼다고 기존 노션 전체를 검색하는 것은 아니다. 최근 문답 일부를 답변 문맥으로 쓰는 기능과, 오래된 메모를 찾아 근거로 답하는 검색 기능은 별개다. 예약 알림, 자동 반복 작업, 웹 검색, 사진 원본 처리도 아직 없다. 새 준비 공간의 기록이 기존 메모 웹앱에 바로 나타나는 전환도 이 단계의 범위가 아니다.

서버에 배포했다는 사실만으로 맥을 실제로 끈 상태까지 검증했다고 쓸 수도 없다. 자동 작업이 없으므로 일정에 맞춰 스스로 다시 실행하는 앱도 아니다. 지금 완성된 경험은 더 작고 분명하다. 질문에는 답하고, 저장 요청은 저장하며, 뜻이 애매하면 세 버튼으로 사람에게 결정권을 돌려준다.

이 작은 차이가 메모 앱의 성격을 바꾼다. 모든 말을 수집하는 상자가 아니라, 대화와 기록을 구분하는 도구가 된다. 다음 단계에서는 이 원칙을 한 문장 저장을 넘어 최근 대화를 기획서 초안으로 정리하는 흐름에 적용한다.

기록 기준: 2026년 10월 21~22일. 이 글은 고정 문장으로 끝나는 AI 연결 점검과, 실제 질문 답변·저장 확인 흐름을 단계별로 검증한 기록을 바탕으로 썼다. 아직 구현하지 않은 검색·알림·사진 처리 기능은 포함하지 않았다.

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