AI가 정리해도, 적용은 사람이 고른다 | AI 노트앱 만들기 14

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

AI의 정리안은 메모가 아니라, 사람이 고르는 미리보기다.

왜 자동 정리보다 ‘제안’이 먼저인가?

메모를 저장하는 일과 메모를 해석하는 일은 분리하는 편이 안전하다. 원문 저장은 받은 문장을 그대로 남기는 단계다. 이때는 AI를 부르지 않는다. 저장 뒤에 사용자가 정리 제안 버튼을 선택할 때만 별도의 분석이 시작된다. 원문이 있다는 이유만으로 분류 작업을 예약하거나 속성을 채우지 않는다. 이 구조의 핵심은 쓰기 전에 볼 수 있다는 점이다. AI가 만든 결과는 곧바로 데이터베이스에 들어가지 않고 미리보기 카드로 나타난다. 사람은 원문 인용과 여덟 가지 제안값을 함께 살핀 뒤 적용하거나 취소한다. 미리보기의 문장이 자연스럽더라도 원문의 의도까지 자동으로 인증되는 것은 아니다.

제안 카드는 일정 시간 안에서 한 번의 판단을 받는다. 같은 메모에 자동 재생성이나 재적용을 반복하지 않는다. 결과가 불확실할 때 같은 내용을 다시 보내 새 메모를 만드는 방식도 피한다. 생성, 검토, 적용을 나누면 AI가 정리를 돕되 최종 선택권은 사람에게 남는다.

AI는 어떤 여덟 칸만 제안하는가?

제안 범위는 한줄요약, 유형, 영역, 용도, 태그, 핵심어, 분류 확신도, 검토필요의 여덟 칸이다. 유형과 영역처럼 선택지가 있는 칸은 이미 마련된 옵션만 쓴다. AI가 그럴듯한 새 분류명을 즉석에서 만들거나 데이터 구조를 늘리지 않는다.

내용을 압축하는 칸은 한줄요약과 핵심어다. 찾아보기 위한 칸은 유형, 영역, 용도와 태그다. 사람의 재검토를 돕는 칸은 분류 확신도와 검토필요다. 반대로 제목, 원문, 본문, 날짜, 처리상태, 사용자가 직접 쓴 요약과 신뢰도 같은 값은 제안 적용 대상에서 뺀다. 분류 확신도는 AI가 자기 분류를 얼마나 확실하게 보는지 나타내는 보조값일 뿐, 자료의 진실성이나 출처 신뢰도를 뜻하지 않는다. 원문 인용이 정확해도 요약의 의미가 정확하다는 보장은 없으므로 검토 단계가 필요하다.

확인을 누르면 무엇이 바뀌는가?

운영 환경에서는 개인 자료와 구별되는 가상 메모를 만들어 적용 흐름을 확인한다. 미리보기에 표시된 여덟 값과 실제 저장된 여덟 값을 대조하자 모두 일치한다. 원문 전체와 보호 대상으로 정한 다른 속성은 그대로 남고, 처리상태도 바뀌지 않는다. 정리 제안이 메모 자체를 다시 쓰는 기능이 아니라 제한된 속성 보완이라는 뜻이다. 적용은 버튼을 눌렀다는 사실만으로 성공 처리하지 않는다. 쓰기 직전에 대상 페이지, 원문, 본문, 스키마와 보호 속성을 다시 읽고, 정해 둔 상태와 맞는지 확인한다. 실제 검증에서는 쓰기 뒤의 값도 다시 읽어 미리보기와 정확히 같은지 대조한다. 같은 적용 버튼이나 생성 버튼을 다시 선택해도 추가 변화가 생기지 않도록 막는다.

다만 이 검증은 값이 기술적으로 정확히 들어갔음을 보여준다. AI가 붙인 유형이나 태그가 독자의 목적에 가장 알맞다는 뜻은 아니다. 기술적 일치와 의미 판단을 분리해야 사람이 고른다는 원칙이 형식적인 확인 절차로 끝나지 않는다.

취소하면 정말 아무 속성도 쓰지 않는가?

취소 흐름도 별도의 가상 메모로 확인한다. AI는 여덟 칸의 제안을 만들지만, 사용자가 취소를 선택하자 해당 칸은 모두 적용 전 상태로 남는다. 원문과 다른 보호 속성도 변하지 않는다. 취소 뒤에 이전 적용 버튼을 다시 선택해도 추가 효과가 생기지 않는다.

이 차단은 ‘마음에 들지 않으면 나중에 되돌린다’와 다르다. 되돌리기는 한 번 쓴 값을 복원하는 과정이지만, 여기서는 애초에 제안값을 쓰지 않는다. 정리 결과를 비교해 보고 버릴 수 있어야 AI 제안이 사람의 메모보다 우선하지 않는다.

또한 취소가 서버의 모든 기록을 없앤다는 뜻은 아니다. 제안을 만들고 선택을 처리한 비공개 운영 기록은 남을 수 있다. 노션 메모의 여덟 속성을 바꾸지 않았다는 것과 시스템 내부에 아무 흔적도 없다는 주장은 구분해야 한다.

거짓 충돌을 고친 뒤 진짜 변경은 어떻게 지키는가?

첫 적용 시험에서는 실제 내용이 바뀌지 않았는데도 충돌로 중단되는 문제가 나타난다. 매 요청마다 달라지는 응답 식별값까지 스키마의 일부로 비교했기 때문이다. 시스템은 이 실패에서 원문이나 속성을 쓰지 않았고, 같은 제안을 다시 생성하거나 재적용하지도 않는다. 먼저 비교 기준을 고친 뒤 새 가상 메모로 적용을 다시 검증한다.

수정한 기준은 표시용 응답 정보와 안정된 데이터 정의를 구분한다. 객체의 키 순서는 정돈해 비교하고, 태그와 용도는 반환 순서가 달라도 같은 값의 집합이면 같다고 본다. 반면 실제 옵션이 추가되거나 빠지고, 본문 블록이나 보호 속성의 값과 순서가 달라지면 충돌로 처리한다. 단순한 응답 차이를 진짜 편집으로 오인하지 않으면서도 중요한 변경은 느슨하게 넘기지 않는다.

이어 다른 가상 메모의 한줄요약을 시험자가 먼저 바꾼 뒤 적용을 시도한다. 앱은 이 외부 변경을 발견하고 전체 적용을 중단하며 수동값을 그대로 둔다. 나머지 일곱 칸도 쓰지 않는다. 다만 이 방식은 마지막 읽기와 쓰기 사이를 하나의 원자적 비교·교환으로 묶은 것이 아니다. 아주 짧은 동시 수정 틈은 남고, 체크되지 않은 값이 기본값인지 사용자가 해제한 값인지 완전히 구별하지 못한다.

내 메모 앱에는 어떻게 요청하면 좋을까?

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

저장 원문은 그대로 두고, 한줄요약·유형·영역·용도·태그·핵심어·분류 확신도·검토필요만 제안해줘. 기존 선택지만 쓰고 미리보기를 보여준 뒤, 내가 적용 또는 취소할 때까지 쓰지 마. 적용 직전에 원문과 보호 속성을 다시 읽고 달라졌다면 전체 적용을 중단해줘.

요청문에서 중요한 부분은 ‘AI로 정리해 달라’가 아니라 쓰기 범위와 판단 시점을 정하는 일이다. 어떤 속성을 건드리지 말아야 하는지, 취소했을 때 무엇이 그대로여야 하는지, 외부 변경을 발견하면 부분 적용할지 전체 중단할지를 먼저 정한다.

마지막으로 실패 뒤의 행동도 명시한다. 자동 재호출이나 재적용은 비용만 늘리는 문제가 아니라 다른 버전의 제안을 섞을 수 있다. 불확실한 결과는 읽기 전용으로 확인하고, 사람이 현재 메모를 살핀 뒤 다음 행동을 고르는 편이 안전하다. AI 정리의 완성도보다 사람이 확인하기 전에는 쓰지 않는 구조가 먼저다.

기록 기준: 2026년 10월 21~22일. 메모 수신기 0.6의 운영 검증을 바탕으로 저장 원문 한 건의 정리 제안, 적용·취소와 충돌 보호를 정리한다. 실제 개인 메모는 싣지 않고 설명용 예시를 쓴다.

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