바이브코딩 실전 · 새 공간 전환 15편
겉은 그대로 두고, 앱이 바라보는 메모 공간만 바꾼다.
주소와 로그인을 그대로 두고 바꿀 수 있을까?
웹앱을 교체한다고 새 주소와 새 계정을 다시 만드는 것은 아니다. 이번 전환은 사용하던 주소, 암호 규칙과 로그인 세션을 유지한 채 앱이 읽는 메모 공간을 새 작업 공간으로 바꾸는 방식이다. 기존 인증 환경은 그대로 두고 새 공간을 지정하는 설정만 더한다. 전환 실패를 숨기기 위해 옛 공간으로 조용히 돌아가는 방식도 쓰지 않는다. 새 설정이 잘못됐거나 필요한 데이터 구조가 맞지 않으면 읽기를 실패로 표시한다. 그래야 사용자는 새 공간을 보고 있다고 믿으면서 실제로는 옛 데이터를 보는 혼합 상태를 피할 수 있다.
기존 앱의 소스와 설정은 원복할 수 있도록 보존한다. 여기서 ‘새 앱으로 교체한다’는 말은 운영 화면의 읽기 대상을 바꾼다는 뜻이다. 원본 메모 데이터나 기존 봇의 기술 설정을 삭제한다는 승인으로 넓혀 해석하지 않는다.
원본과 사진, 관계는 어떻게 보존하는가?
전환 전에는 옛 공간의 원본과 새 공간의 대응본을 같은 기준으로 읽어 비교한다. 제목 몇 개가 비슷해 보인다는 이유가 아니라 명확한 식별 대응을 기준으로 속성, 본문과 사진을 대조한다. 검증에서는 대응되는 원본들의 속성과 본문이 일치했고, 사진도 파일 크기만 비슷한 것이 아니라 바이트 단위로 같음을 확인한다. 관계 데이터는 메모 자체의 관련 항목과 별도 연결 기록을 구분해 읽는다. 두 출처가 같은 두 메모를 가리키면 지도에서는 한 선으로 보일 수 있지만, 상세 정보에는 방향과 출처를 남긴다. 관계가 있다는 사실은 연결 이유가 참이라는 인증도, 사용자가 그 관계를 확정했다는 뜻도 아니다.
운영 교체 뒤에도 기존 메모와 연결 기록의 속성 및 수정 시각이 바뀌지 않았는지 다시 확인한다. 이 비교의 목적은 자료 보존 여부를 판단하는 데 있다. 시험 기록이 섞인 전체 건수를 생산성이나 실사용 성과처럼 소개하지 않고, 무엇을 서로 대조했으며 차이가 있었는지를 설명하는 편이 정확하다.

옛 주소와 개인 상태는 어떻게 이어지는가?
메모 공간이 바뀌면 같은 내용도 내부 식별값이 달라질 수 있다. 옛 메모 링크를 무조건 제목 검색으로 추정해 연결하면 동명이거나 수정된 제목에서 잘못된 메모를 열 수 있다. 그래서 명확한 대응표가 있는 옛 식별값만 새 식별값으로 바꿔 상세 화면을 연다. 대응이 없거나 중복이면 임의로 추정하지 않는다. 즐겨찾기, 읽음과 최근 열어 본 메모 같은 개인 상태도 데이터 공간별로 나눠 저장한다. 새 공간을 처음 열 때 명확히 대응되는 상태만 한 번 옮기고, 애매한 항목은 옛 저장소에 남긴다. 옛 상태를 삭제하거나 덮어쓰지 않으므로 전환 뒤 문제가 생겨도 비교와 원복의 근거가 유지된다.
로그인 세션은 계속 이어지지만, 개인 상태가 모두 자동으로 완벽하게 승계된다고 약속하지는 않는다. 정확한 대응이 있는 것만 옮기는 보수적인 방식은 일부 항목을 남길 수 있다. 대신 잘못된 즐겨찾기나 최근 기록을 다른 메모에 붙이는 위험을 줄인다.
날짜 없는 메모에서는 왜 버튼이 사라졌나?
후보 앱의 자동 검사만 통과한 상태에서 끝내지 않고 실제 운영 화면을 열자 새로 저장된 날짜 없는 메모에서 읽음, 미루기와 보관 버튼이 보이지 않는 문제가 나타난다. 기존 화면 조건이 날짜가 있는 메모를 기준으로 작성돼, 날짜가 비어 있으면 소유자용 동작 영역까지 함께 숨겼기 때문이다.
수정은 권한 경계를 넓히지 않으면서 날짜 조건만 분리하는 작은 보정으로 진행한다. 소유자로 로그인한 상태와 허용된 메모라는 기존 조건은 유지하고, 날짜가 없다는 이유만으로 버튼이 사라지지 않게 한다. 이 동작을 따로 검사하는 회귀 항목을 추가한 뒤 수정본을 다시 배포한다.
이 사례는 교체 검증에서 ‘페이지가 열린다’만 확인하면 부족하다는 점을 보여준다. 새 입력 경로가 만드는 메모는 옛 데이터와 빈 필드의 모양이 다를 수 있다. 날짜, 분류와 관계가 비어 있는 메모를 실제 화면에서 열고, 소유자가 해야 할 핵심 동작이 보이는지 확인해야 한다.
운영 쓰기는 어디까지 확인했는가?
실제 쓰기는 기존 자료와 구별되는 가상 메모 한 건에만 제한한다. 수정본에서 읽음, 일주일 미루기, 보관을 차례로 선택하고 세 번의 저장 결과를 다시 읽는다. 각 단계에서 허용한 상태만 바뀌고, 본문과 다른 속성은 그대로임을 확인한다. 기존 메모와 관계 기록에는 쓰지 않는다.
확인하지 못한 경계도 남는다. 보관 취소는 브라우저 도구에 기본 확인 대화상자 이벤트가 전달되지 않아 운영 화면에서 검증하지 못한다. 보관 버튼을 다시 누르지 않았으므로 취소가 실제로 저장을 막는다고 주장할 수 없다. 별도 가상 단위 검사에서 취소 흐름이 통과한 것과 운영 화면의 실제 취소 확인은 구분한다.
반응형 화면은 여러 너비의 동일 출처 문서로 검사했지만 실제 휴대전화 터치 동작은 확인하지 않았다. 상태 저장도 현재 값을 읽고 비교한 뒤 수정하는 방식이지 원자적 CAS가 아니다. 마지막 읽기와 쓰기 사이의 짧은 동시 수정 가능성은 남는다. 따라서 이번 완료는 확인한 세 동작과 보존 범위에 한정된다.

교체 요청에는 무엇을 분명히 써야 할까?
독자가 바꿔 쓸 요청 예시이며 실제 발언 인용이 아니다.
기존 주소와 로그인은 유지한 채 새 메모 공간으로 전환해줘. 원본 본문·사진·관계·개인 상태의 대응을 먼저 검증하고, 옛 메모 링크는 명확한 대응이 있을 때만 새 메모로 이어줘. 기존 봇 설정은 보존하고, 날짜 없는 메모에서도 소유자 버튼이 보이는지 확인해줘. 실제 쓰기는 구별된 시험 메모 한 건에만 제한해줘.
교체 요청에는 유지할 것과 바꿀 것을 함께 적어야 한다. 주소, 인증, 원본과 원복본은 유지하고, 앱의 활성 데이터 공간만 바꾼다고 선을 긋는다. 시험 쓰기의 대상과 허용 속성도 미리 제한하면 운영 검증이 기존 자료를 건드리는 일을 막을 수 있다.
새 입력 기준을 선택한 일과 기존 입력 도구를 없앤 일도 구분한다. 앞으로 새 메모를 어느 경로로 받을지 정했지만, 기존 그록봇 설정을 삭제하거나 구독을 해지하거나 기술적으로 중단하지 않는다. 교체가 성공하려면 새 공간이 보이는 것만큼 무엇이 여전히 남아 있는지도 정확히 기록해야 한다.
기록 기준: 2026년 10월 21~22일. 메모 웹앱 1.7.0 r2의 운영 교체와 검증 기록을 바탕으로 썼다. 도식은 설명용이며, 실제 운영 캡처에는 새로 만든 시험 메모만 남겼다. 기존 개인 메모·첨부 사진·계정 설정은 싣지 않는다.
직접 확인할 공식 자료
- 노션 연결과 권한연결된 데이터에 접근하는 권한과 범위를 확인한다.
- 텔레그램 Bot API메시지와 callback 등 봇이 받는 기본 입력 구조를 확인한다.
이 글은 실제 제작 기록을 바탕으로 AI의 도움을 받아 구성하고 검수했다. 구현된 동작과 설명용 예시를 구분했다.
