그록봇에서 Aside로, 실제 주소에 배포하기 | AI 노트앱 만들기 4

바이브코딩 실전 · 4/5

앱을 만드는 일과 내 주소에서 쓰게 하는 일은 다르다.

그록봇의 실행 환경에서 화면이 열리면, 다음은 내가 쓰는 호스팅에 올릴 차례다. 이 프로젝트에서는 그 사이에 로그인과 배포 설정이라는 두 관문이 놓인다. 나는 계정의 로그인 방식을 바꾸기 전에 작업을 이어받을 도구부터 살핀다.

로그인에서 막히면 무엇을 바꿀까?

그록봇은 첫 앱을 만들고 노션 연결까지 시험한다. 하지만 Hostinger 관리 화면에 들어가는 단계에서는 그쪽 브라우저의 Google 로그인이 진행되지 않는다. 코드 제작의 실패가 아니라 계정에 접근하는 환경의 문제다. 나는 Hostinger 비밀번호를 새로 만드는 방법도 검토하다가, 이미 같은 계정을 사용하는 Aside를 떠올린다.

계정 기존 aside가 활용하고 있어서 그런데, gmail 로그인으호 연결은 어려워?

이때 그록봇이 설명하는 제한은 해당 실행 환경의 상황이다. 모든 AI 도구에서 Google 로그인이 불가능하다는 뜻으로 넓힐 필요는 없다. Aside는 기존 접속 환경을 이용해 이어받을 수 있다. 나는 그록봇에 다음과 같이 전달한다.

아래 처럼 해줘. aside브라우저 통해서 올릴께

그 뒤에는 Aside가 안내한 ZIP과 실행 설명 요청을 붙인다. 이 부분은 내가 새로 쓴 요구사항이 아니라, 배포를 맡을 도구의 안내를 제작 도구에 옮기는 인계다. 다른 AI로 넘어간다고 처음부터 앱을 다시 만들지는 않는다. 코드는 이어받고, 접근할 수 있는 환경을 바꾼다.

ZIP만 넘기면 다음 AI가 이어갈 수 있을까?

앱 파일만으로는 실행 조건이 빠질 수 있다. Aside가 함께 요청하는 것은 실행·빌드 방법, 필요한 Node.js 버전, 환경변수 이름과 용도, 노션 연결과 로그인 설정 방법이다. ZIP에는 실제 비밀값 대신 설정 예시를 넣고, 필요한 값은 서버에서 따로 설정한다.

작업 범위도 같이 넘긴다. 기존 출판 사이트를 수정하지 않고 별도 서브도메인에 앱을 올린다. 노션을 원본 저장소로 유지하고, 기본 비공개 운영에서는 메모를 읽는 화면과 메모 조회 API에 인증을 둔다. 비공개 응답은 CDN 캐시에서 제외하도록 한다. 화면을 예쁘게 올리는 것과 비공개 메모를 다루는 것은 한 묶음의 과제다.

역할은 세 갈래로 나뉜다. 그록봇은 최초 코드를 만들고, Aside는 받은 파일을 검토해 운영에 맞게 수정하고 배포한다. 나는 사용할 주소와 분리 배포 방향을 정하고 파일을 전달한다. 여기서 중요한 것은 누가 더 많은 일을 하느냐가 아니다. 다음 작업자가 어느 파일과 조건을 기준으로 시작하는지 분명해야 한다.

이 앱은 Hostinger의 관리형 Node.js 환경에서 Express로 실행한다. 이미 WordPress 사이트가 있다고 해서 같은 방식으로 앱을 올릴 수 있는 것은 아니다. 비슷한 작업을 맡길 때도 명령어부터 외우기보다, AI에게 현재 호스팅의 앱 지원 여부와 기존 사이트에 영향을 주지 않을 범위를 확인하게 하는 편이 순서에 맞다.

첫 배포가 실패하면 파일을 더 보내야 할까?

첫 배포에서 호스팅은 build-mock이라는 명령을 실행한다. 빌드에 꼭 필요한 이름처럼 보이지만, 최초 코드에서 이 명령은 그록봇 컴퓨터의 메모 파일을 읽어 시험 자료를 만드는 용도다. 운영 서버에는 그 파일이 없으므로 배포가 실패한다.

이때 빠진 개인 파일을 서버로 옮기는 것은 해결 방향이 아니다. 운영 앱의 자료는 노션에 있다. Aside는 개발용 시험 자료를 만드는 단계와 운영용 검사 단계를 분리한다. 한 번 명령을 제거해도 Hostinger에 이전 설정이 남아 재시도가 실패한다. 최종적으로는 같은 명령 이름이 운영 검사를 실행하도록 호환 별칭을 남겨 설정과 코드를 맞춘다.

Build command: npm run build-mock
Error: ENOENT: no such file or directory, open '/workspace/memo/inbox.md'

사용자가 여기서 판단할 것은 복잡한 명령어 문법이 아니다. 실패 원인이 원본 자료 부족인지, 실행 환경의 차이인지 묻는 일이다. 전자라면 자료를 확인해야 하지만, 이 경우에는 서버가 잘못된 작업을 실행하고 있다. AI가 실패를 설명할 때 어떤 명령이 무엇을 읽으려 했는지까지 확인하면, 관계없는 개인 자료를 추가로 넘기는 우회를 피할 수 있다.

바이브코딩은 요청을 한 번 보내고 완료 안내만 받는 과정이 아니다. 결과가 요청과 다르면 그 차이를 짚어 다시 맡긴다. 이 장면에서는 배포 로그가 다음 요청의 재료가 된다. 나는 운영할 범위를 유지하고, Aside는 그 범위 안에서 실행 조건을 고친다.

배포 완료 표시는 어디까지 확인해 줄까?

관리 화면에서 배포가 끝나도 실제 사용은 별도로 확인한다. Aside는 실제 주소의 로그인 화면, 로그인 전 메모 조회 차단, 로그인 뒤 노션 본문 읽기를 점검한다. 기존 출판 사이트가 계속 열리는지도 확인한다. 여기서 확인하는 접근 제한은 메모 페이지와 조회 API다. 모든 정적 파일까지 비공개라고 확대해 설명하지 않는다.

앞에서 이어 오는 가상 메모 ‘베란다 텃밭 책기획’으로 보면 흐름이 간단하다. 노션에 둔 원문을 앱이 읽고, 검색 결과에서 본문을 연다. 배포를 위해 기획 내용을 새로 옮겨 적거나 그록봇의 기록 규칙을 다시 만들 필요는 없다. 바뀌는 것은 접속 주소와 읽는 환경이지 원본의 위치가 아니다.

아래는 이 인계 과정을 바탕으로 정리한 재사용용 요청 예시다. 실제 발언을 옮긴 인용문은 아니다.

다른 AI가 만든 앱을 검토하고 내 호스팅에 배포해 줘.
ZIP과 실행 설명을 먼저 확인하고, 필요한 설정 항목을 알려줘.
기존 사이트는 바꾸지 말고 별도 앱으로 분리해 줘.
실패하면 어떤 명령과 조건에서 막혔는지 확인해 줘.
완료 후에는 실제 주소에서 읽기와 접근 제한을 점검해 줘.

인계할 것은 이전 대화 전체가 아니라 다음 작업에 필요한 코드와 조건, 확인된 상태다. 실제 주소에서 메모를 읽을 수 있으면 다음 질문으로 넘어간다. 열리는 앱을 어떻게 다시 찾아 쓰고 싶은 서재로 만들 것인가.

설명 기준은 메모 뷰어1.1.1이다. 초기 버전 비교는 별도로 표시한다. 앱 화면은 가상 자료로 재현하고, 대화 도판은 실제 문구를 발췌해 재구성한다. 기본 비공개 운영과 개발용 임시 공개 설정은 구분한다.

실제 프로젝트를 바탕으로 AI의 도움을 받아 작성·편집한다. 원문 인용과 재사용 요청 예시를 구별하며, 이 연재에 개인 메모나 인증정보를 싣지 않는다.