말로 부탁해 나만의 AI 노트앱 만들기 | AI 노트앱 만들기 1

말로 부탁해 나만의 앱까지, AI 노트앱 만들기 1편 대표 도판

바이브코딩 실전 · 1/5

메모를 남기는 일보다, 필요한 순간 다시 꺼내는 일이 어렵다.

이 앱은 노션에 모은 메모를 분류별로 읽고, 단어로 찾고, 연결된 기록을 펼쳐 보는 작은 서재다. 그록봇이 첫 앱을 만들고 어사이드(Aside)가 점검·배포·화면 개선을 이어받는다. 사람은 코드를 한 줄씩 지시하는 대신, 무엇을 남기고 어떻게 읽고 싶은지 정한다. 먼저 지금의 읽기 화면부터 보자.

현재 1.1.1 메모 뷰어의 홈에 가상 메모7개와 최근 기록·분류·통계를 표시한 밝은 화면
그림 1-1. 현재1.1.1 뷰어의 홈을 가상 메모7개로 재현한다. 실제 운영 노션에 연결한 화면이 아니며 동기화 시각도 재현용 값이다. 이미지를 누르면 크게 볼 수 있다.
현재 메모 뷰어의 어두운 연결지도에 가상 메모19개와 본문·분류·태그 관계80개를 표시한 화면
그림 1-2. 가상 메모19개로 연결지도 기능을 시연한다. 본문·분류·태그 표시를 켠 화면의 연결은80개이며, 관계와 제목은 가독성을 위해 구성한 예시다. 실제 운영 메모나 AI 의미 추론 결과가 아니다. 이미지를 누르면 크게 볼 수 있다.

두 화면은 현재 1.1.1 앱에 가상 자료를 넣은 재현이다. 첫 화면은 가상 메모 일곱 개를, 그래프는 관계를 읽기 쉽도록 짧은 제목의 가상 메모 열아홉 개를 사용한다. 실제 운영 메모가 아니다. 완성 화면을 먼저 펼쳐 놓고, 이제 이 화면으로 이어지는 첫 요청부터 따라간다.

첫 부탁은 ‘앱을 만들어 줘’여야 할까?

출발점은 기능 목록이 아니라 저장에 관한 질문이다. 그록봇에게 메모를 계속 넣어도 되는지 묻고, 이어 다음을 확인한다.

어디에 저장되? 계속 저장되어 있고 계속 검색해서 알려주기도 할수 있나?

‘저장’과 ‘검색’이 한 문장에 들어 있다. 채팅창에 정리된 답이 한 번 나타나는 것과, 그 답의 재료가 남아 다음에도 쓰이는 것은 다르다. 그래서 첫 단계에서는 화려한 화면보다 메모가 남는 자리부터 살핀다. 원래 입력한 문장이 있는지, 분류된 기록을 다시 펼칠 수 있는지가 기준이다.

이 질문은 뒤이어 노션을 저장소로 쓰고 읽는 화면을 따로 만들 수 있는지 묻는 요청으로 구체화된다.

노션을 데이터베이스로 쓰는 별도 앱을 요청하는 사용자 문장과 그록봇의 구조 설명을 발췌한 도판
그림 1-3. 사용자 요청 중 핵심 문장과 그록봇의 구조 설명을 원문에서 발췌한다. 대화 화면은 편집용으로 다시 그린 것이며 원본 앱 캡처가 아니다. 이미지를 누르면 크게 볼 수 있다.

위 대화 도판은 실제 그록봇 대화의 발췌를 다시 그린 편집 재구성이다. 화면이 어떤 기술로 움직이는지보다, 사람이 어떤 필요를 말하고 AI가 그것을 어떤 구조로 바꾸는지에 주목하면 된다.

그록봇은 전체 기록을 시간순 파일에 덧붙이고 분류별 파일에도 정리한다. 이후 노션 보드를 만들면서 메모를 눈으로 읽을 자리도 생긴다. 책기획·할일·자료·마케팅처럼 주분류 하나를 붙이고, 여러 성격이 겹치면 태그로 덧붙이는 구조다. 입력할 때마다 이 항목을 사람이 모두 채우는 대신, 짧은 생각이나 링크를 보내고 그록봇이 정리하도록 맡긴다.

이것이 여기서 다루는 바이브코딩의 출발이다. 처음부터 개발 설계도를 완성할 필요는 없다. 다만 ‘잘 정리해 줘’에서 멈추지 않고, 정리한 것을 어디에 남기고 어떻게 다시 꺼낼지를 묻는다. 결과를 열어 보고 다음 요구를 보태는 일이 제작의 일부가 된다.

AI가 요약하면 원문은 버려도 될까?

제목과 요약은 훑어보기에 좋지만 처음 생각을 전부 담지는 못한다. 메모를 줄이는 일과 메모를 보관하는 일을 나누어야 하는 이유다. 이 프로젝트에서는 입력 원문과 출처, 확인 내용을 함께 남기는 구조를 쓴다. 목록에서는 짧게 읽고, 필요할 때 본문으로 들어가 재료를 확인한다.

초기 수집 과정에는 링크를 다시 확인한 뒤 내용을 정정하는 사례가 있다. 같은 주소가 다시 들어오면 기존 항목을 고치고 중복 저장을 생략하는 사례도 있다. 여기서 배울 점은 AI가 언제나 정확히 정리한다는 것이 아니다. 원문과 확인 결과를 나누어 두면, 잘못된 요약을 발견했을 때 돌아갈 기준이 생긴다는 점이다.

사람이 확인할 것도 구체적이다. ‘저장했어요’라는 답을 받으면 저장 위치를 열어 본다. 제목만 있는지 본문까지 있는지 살피고, 고쳐 쓴 문장이 원문을 덮어쓰지는 않았는지 확인한다. 메모를 잘 모으는 앱은 입력이 편한 앱이기도 하지만, 무엇을 남겼는지 다시 확인할 수 있는 앱이기도 하다.

메모 한 줄은 어떤 길을 지나갈까?

이후 설명에는 다음 가상 메모를 공통 예시로 쓴다.

연습용 가상 메모: 베란다 텃밭 초보를 위한 책 목차를 생각해 보기. 계절별로 나누고 실패 사례도 넣고 싶다.

예시에서 이 메모의 주분류는 ‘책기획’이다. ‘텃밭’과 ‘목차초안’은 태그 후보가 된다. 짧은 제목은 목록을 훑는 데 쓰고, ‘실패 사례도 넣고 싶다’는 처음 문장은 본문에 남긴다. 앱에서 텃밭을 찾으면 그 재료로 돌아가고, 홍보 아이디어처럼 연관된 메모로 이동하는 흐름을 설명할 수 있다. 실제 도서 제작 성과를 뜻하는 사례는 아니다.

사용자가 목적을 정하면 그록봇이 분류하고 노션이 원문을 보관하며 웹앱이 읽는 흐름을 나타낸 설명용 도식
그림 1-4. 가상 메모 한 줄이 분류·보관·읽기로 이어지는 설명용 도식. 실제 프로그램 화면을 캡처한 그림은 아니다. 이미지를 누르면 크게 볼 수 있다.

자료가 이동하는 길을 이렇게 나누면 도구의 역할도 분명해진다. 그록봇은 입력을 정리하고, 노션은 메모를 보관하며, 웹앱은 기록을 읽는 화면을 맡는다. 셋이 같은 일을 중복하는 것이 아니다. 저장소를 그대로 둔 채 읽는 방식을 바꿀 수 있으므로, 화면을 고칠 때마다 원본을 새 도구로 옮기지 않아도 된다.

현재 앱의 문자 검색과 연결 화면은 메모를 다시 읽는 기능이다. 텔레그램으로 질문하고 서버의 클로드가 기록을 분석해 답하는 구상은 아직 구현하지 않은 다음 단계다. 여기서 만드는 범위는 모으고, 정리하고, 다시 읽는 데까지다.

내 메모로 시작하려면 무엇을 요청할까?

다음은 독자가 고쳐 쓸 재사용용 요청 예시다. 실제 대화 인용이 아니다.

앞으로 짧은 생각과 링크를 메모로 남길게.
주분류 하나, 짧은 요약, 태그와 입력 원문을 함께 보관해 줘.
어디에 저장했는지 알려주고, 다시 찾아 읽을 방법을 보여 줘.
직접 확인한 내용과 아직 확인하지 못한 내용은 구분해 줘.
먼저 가상 메모 세 개로 저장 결과를 보여 줘.

첫 시험에서는 메모를 많이 넣기보다 서로 다른 성격의 세 건이면 충분하다. 생각 한 줄, 해야 할 일 하나, 다시 읽을 자료 하나를 넣고 분류와 원문이 어떻게 나뉘는지 본다. 이는 독자가 시작할 때 쓸 연습 방법이지, 이 프로젝트에서 세 건으로 시험했다는 뜻은 아니다.

말로 부탁하는 제작에서 사람의 역할은 사라지지 않는다. 요청을 건네고, 나온 것을 보고, 마음에 들지 않는 지점을 다시 말한다. 다음 편에서는 이 원칙을 노션 보드에 적용한다. 메모를 저장했다는 답에서 한 걸음 더 나아가, 휴대폰에서 제목을 읽을 수 있는 화면을 만드는 과정이다.

직접 확인할 참고 자료

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

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