여행 중 현지 약국에서 한국에서 먹던 약과 성분이 같거나 비슷한 미국 약을 찾아보는 웹 서비스 〈여행 약 성분 비교〉의 첫 버전입니다. 기획은 에이전트 서비스 기획서 PDF로 정리해 Atoms의 역할 에이전트 팀에 넘겼고, 코드는 GitHub, 데이터베이스는 Supabase, 배포는 Vercel에 연결했습니다.
기준 자료는 성공지식백과 유튜브 영상(24분 28초)과 그 안에 담긴 2026년 10월 16일 작업 화면입니다. 이 영상은 Atoms의 유료 광고를 포함합니다.
단계 제목 옆 시각은 영상에서 해당 장면이 나오는 위치입니다. 영상에서 나눠 주기로 한 에이전트 서비스 기획서 템플릿은 3단계에 빈 양식과 영상 예시 두 가지로 넣었습니다. Atoms는 atoms.dev에서 시작합니다.
시작 전 준비: 계정 네 개
이번 작업에는 Atoms, GitHub, Vercel, Supabase 계정이 쓰입니다. 영상에서는 GitHub 계정을 먼저 두고 Vercel과 Supabase에는 같은 GitHub 계정으로 로그인했습니다. 요금제와 크레딧 조건은 Atoms 요금 안내에서 확인합니다.
| 서비스 | 이번 작업에서 맡은 일 |
|---|---|
| Atoms | 역할 에이전트들이 기획 검토, 데이터 수집, 사이트 개발, SEO 글 작성을 나눠 맡음 |
| GitHub | 서비스 코드를 저장하는 비공개 저장소 |
| Vercel | GitHub의 코드를 받아 웹사이트로 배포 |
| Supabase | 약 데이터를 담을 데이터베이스 |
키를 넣은 것과 실제로 연결된 것은 따로 확인합니다. Atoms 채팅에 키 설정 완료 메시지가 남았는지, Supabase 커넥터에 프로젝트가 붙었는지, Vercel에 배포 기록이 생겼는지를 각 단계에서 봅니다.
시작 전 확인
0/5 완료
1. 해결할 불편과 수익 모델 정하기 · 07:31
영상의 아이디어는 해외여행 중 현지 약국에서 약을 사야 할 때 생기는 불편에서 출발합니다. 한국에서 먹던 약은 현지에서 팔지 않고, 현지 약 가운데 어떤 제품이 기존 약과 성분이 같거나 비슷한지 판단하기 어렵습니다.
핵심 기능은 두 가지로 줄였습니다. 하나는 한국 약과 해외 약(우선 미국)의 성분 비교이고, 다른 하나는 그 비교 결과를 누구나 검색할 수 있게 정리한 웹사이트입니다(영상 08:03).
웹사이트를 열면 트래픽 비용이 나가므로 수익 모델도 기획 단계에서 정합니다. 방문자가 여행자라는 점에 맞춰 여행자 보험과 항공사 제휴를 후보로 두었고, 약 판매·약 광고·약 제휴는 하지 않기로 했습니다(08:41). 약은 전문가 영역이라 의학적 조언이 아니라 성분이 비슷한 가장 가까운 제품을 알려 주는 참고용이라는 면책 문구를 웹사이트에 넣는 것도 처음부터 기획에 넣었습니다.
이 단계에서는 기획을 크게 키우지 않습니다. 불편, 핵심 기능, 꼭 지킬 것만 분명히 적고 나머지는 에이전트와 대화하며 구체화합니다.
2. Atoms 에이전트 팀과 테마 고르기 · 09:49
Atoms는 역할이 나뉜 AI 에이전트들이 조사, 기획, 개발, 마케팅을 나눠 맡는 서비스입니다. Atoms 첫 화면에 소개된 에이전트와 이번 영상에서 한 일은 아래와 같습니다(역할 소개는 2026년 10월 30일 확인).
| 에이전트 | 역할 | 이번 영상에서 한 일 |
|---|---|---|
| Mike | 팀 리더. 계획을 끝까지 진행하며 에이전트를 조율 | 기획서 PDF를 받아 작업을 나누고 진행 상황 정리 |
| Alex | 엔지니어. 프런트엔드·백엔드·연동·배포 | 기획서 분석, 데이터 출처 조사, 사이트 개발과 배포 |
| Emma | 프로덕트 매니저. 아이디어를 명세와 범위로 정리 | 기획서와 에이전트 제안을 합친 통합 기획 작성 |
| Bob | 아키텍트. 시스템 구조 설계 | 통합 기획과 데이터 검증 결과로 시스템 설계 |
| Sarah | SEO 전문가 | 이용 가이드용 SEO 글 두 편 작성 |
| David | 데이터 애널리스트 | @ 호출 예시로만 등장 |
| Iris, Adrian | 딥 리서처, 광고 전문가 | 소개만 하고 쓰지 않음 |
에이전트는 입력창에서 @와 이름으로 불러 일을 맡깁니다. 영상 11:27에서는 데이터 애널리스트 David에게 미국 식품의약국(FDA)의 약을 조사하게 하는 예시를 보여 줍니다. 이번 작업은 이런 짧은 지시 대신 기획서를 통째로 넘기는 방식으로 진행했습니다.
입력창의 Theme 메뉴를 열면 테마 관리자에서 테마별 미리보기를 보고, 고른 테마의 Edit 버튼으로 색을 직접 바꿀 수 있습니다. 영상에서는 약을 다루는 서비스라 신뢰감을 주는 파란색 계열의 Material You 테마를 골랐습니다(12:04).
3. 에이전트 서비스 기획서 채우기 · 12:11
에이전트 서비스 기획서는 에이전트가 첫 방향을 잡을 수 있게 핵심을 적어 두는 A4 양식입니다. 영상에서는 여행 약 성분 비교 서비스에 맞게 빈칸을 채운 뒤 다섯 쪽짜리 PDF로 저장했습니다. 칸은 내 기획(파랑), 꼭 지킬 것(빨강), 에이전트가 더 좋게 바꿔도 되는 내 생각(노랑), 에이전트가 찾을 것(보라)으로 나뉩니다.
핵심 기능과 꼭 지킬 것은 가능하면 채웁니다(영상 12:47). 양식 안내대로 기술 구성처럼 모르는 칸은 비워 둬도 되고, 데이터 칸에는 API 이름 대신 필요한 정보만 적습니다. 어떤 공개 API를 쓸 수 있는지는 에이전트가 찾아 구별합니다.
단계별로 적는 칸
양식은 1단계 기획 키우기, 2단계 데이터 만들기, 3단계 화면 만들기, 4단계 수익화·배포로 이어집니다. 2단계 맨 위의 "1단계 답에서 고른 것"만 에이전트의 1단계 답을 읽은 뒤 채우고, 나머지 칸은 처음에 함께 적습니다.
| 단계 | 사람이 적는 칸 | 양식에 미리 들어 있는 요청 |
|---|---|---|
| 1단계 기획 키우기 | 만들 서비스, 내가 찾은 불편, 핵심 기능, 꼭 지킬 것, 수익 모델, 방문자 모으기, 처음 시작 범위, 기술 구성, 필요한 데이터, 이 서비스만의 어려운 점, 나눠 맡길 에이전트 | 공개 API 조사와 구별, 어려운 점 해결 방법, 내 생각 개선, 기능 우선순위, 위험 요소, 역할 분담, 구현 순서, 답하는 방식 |
| 2단계 데이터 만들기 | 고른 데이터·API, 첫 버전 범위, 수익 모델, 데이터 가공 규칙, 확인용으로 보여 줄 것 | 공개 사용자는 읽기만 하는 데이터베이스 권한, API 키를 환경 변수에 두는 수집 스크립트 |
| 3단계 화면 만들기 | 사용 상황, 필요한 화면, 화면에서 꼭 지킬 것, 편의 기능 예시 | 없음 |
| 4단계 수익화·배포 | 수익 영역 넣는 방식, 방문자 모으기 작업, 배포 전 점검표 | 링크 주소를 설정 값으로 두기, 개인 정보 없는 클릭 집계, 배포 주소와 점검 결과 보고 |
각 칸 이름 뒤 괄호는 양식에 인쇄된 작성 요령입니다. "양식에 들어 있는 요청"은 에이전트에게 무엇을 조사하고 어떻게 답할지 정해 주는 문장이라 고치지 않고 그대로 둡니다.
빈 양식
아래 내용을 문서 프로그램에 붙여 넣고 각 칸의 콜론 뒤를 채운 다음 PDF로 저장합니다. 칸 하나에 여러 줄을 적을 때는 한 줄에 하나씩 씁니다.
에이전트 서비스 기획서 (Atoms에 넣을 프롬프트 양식) 서비스 이름: === 1단계 기획 키우기 (1/2) === 기획은 작게만 적습니다. 코드는 아직 만들지 않고, 에이전트가 조사해서 기획을 키우게 합니다. [만들 서비스] 만들 서비스 (누구의 무엇을 해결하는지 한 문장): [내 기획] 내가 찾은 불편 (한 줄에 하나씩): 핵심 기능 (한두 개면 충분): [꼭 지킬 것] 꼭 지킬 것 (면책 · 하지 않을 것 · 넘지 않을 선): [내 생각: 에이전트가 더 좋게 바꿔도 됨] 수익 모델 (내 생각만. 에이전트가 구체화·개선): 방문자 모으기 (SEO 글 · 커뮤니티 · SNS): 처음 시작 범위 (작게 시작할 범위): 기술 구성 (모르면 비워 두기): === 1단계 기획 키우기 (2/2) === 데이터는 API 이름을 주지 않고 필요한 정보만 적습니다. 어떤 API를 쓸 수 있는지는 에이전트가 찾아 구별합니다. [에이전트가 찾을 것] 필요한 데이터 (어떤 정보가 필요한지만. API 이름은 적지 않음): 이 서비스만의 어려운 점 (에이전트가 풀어 줘야 할 것): 나눠 맡길 에이전트 (Atoms의 역할 에이전트): [양식에 들어 있는 요청: 그대로 둠] 1. 데이터: [필요한 데이터]를 가져올 수 있는 공개 API·공개 데이터를 찾아 구별해 줘. - 바로 쓸 수 있는 것 / 키 발급이 필요한 것 / 상업 이용에 제한이 있는 것 / 쓸 수 없는 것 - 각각 주는 정보, 호출 한도, 갱신 주기 · 무엇을 어떻게 조합할지 추천 2. 어려운 점: [이 서비스만의 어려운 점]을 어떻게 풀지 3. 내 생각 개선: 수익 모델·방문자 모으기·시작 범위·기술을 더 구체화하거나 더 좋은 안을 이유와 함께 4. 기능: 첫 버전에 넣을 것과 미룰 것, 내가 생각 못 한 기능 5. 위험 요소: 법·안전·데이터 품질 면에서 조심할 것 6. 역할 분담: [나눠 맡길 에이전트]에게 어떤 일을 나눌지 7. 구현 순서: 작게 시작해서 키워 가는 단계 8. 답하는 방식: 내 기획에서 바뀌거나 늘어난 부분을 따로 표시하고, 내가 정해야 할 것을 질문 목록으로 === 2단계 데이터 만들기 === 1단계 답을 읽고, 에이전트가 제안한 것 중에서 고른 것을 적습니다. 고르는 건 사람이 합니다. [1단계 답에서 고른 것] 고른 데이터 · API (1단계 답의 API 목록에서): 첫 버전 범위 (1단계 답에서): 수익 모델 (1단계 답에서): [데이터 만들기] 데이터 가공 규칙 (묶기 · 비교 · 정리): [에이전트가 보여 줄 것] 확인용으로 보여 줄 것 (숫자 · 목록 · 예시 검증): [양식에 들어 있는 요청: 그대로 둠] - 데이터베이스 표와 접근 권한을 만든다. 공개 사용자는 읽기만 한다. - 고른 데이터를 가져오는 스크립트를 만든다. API 키는 코드에 넣지 않고 환경 변수에 둔다. === 3단계 화면 만들기 === 누가 어떤 상황에서 보는지부터 적습니다. 안내 문구는 기능보다 먼저입니다. [화면] 사용 상황 (어디서 · 무엇으로 보나): 필요한 화면 (한 줄에 하나씩): [꼭 지킬 것] 화면에서 꼭 지킬 것 (문구 · 표현 · 안내): [에이전트 제안] 편의 기능 예시 (에이전트가 하나 골라 넣음): === 4단계 수익화 · 배포 === 수익 영역은 핵심 결과와 분리합니다. 점검표로 확인한 뒤 배포합니다. [수익화] 수익 영역 넣는 방식 (어디에 · 어떻게 표시): [방문자 모으기] 방문자 모으기 작업 (페이지 · 글): [배포 전 점검] 배포 전 점검표 (에이전트가 확인할 항목): [양식에 들어 있는 요청: 그대로 둠] - 링크 주소는 나중에 넣을 수 있게 설정 값으로 둔다. 클릭 수는 개인 정보 없이 집계한다. - 배포하고 주소를 알려 준다. 점검표 결과를 보여 준다.
영상 예시: 여행 약 성분 비교
영상에서 채운 내용입니다. 2단계의 "1단계 답에서 고른 것"은 에이전트 답을 받은 뒤 적는 칸이라 영상의 PDF에서도 비어 있었습니다. 다른 서비스를 만들 때는 이 예시의 문장 길이와 구체성을 참고해 내용을 바꿉니다.
에이전트 서비스 기획서 (Atoms에 넣을 프롬프트 양식) 서비스 이름: 여행 약 성분 비교 === 1단계 기획 키우기 (1/2) === 기획은 작게만 적습니다. 코드는 아직 만들지 않고, 에이전트가 조사해서 기획을 키우게 합니다. [만들 서비스] 만들 서비스 (누구의 무엇을 해결하는지 한 문장): 여행 중에 한국에서 먹던 약과 성분이 같거나 비슷한 현지 약을 찾아 주는 웹 서비스 [내 기획] 내가 찾은 불편 (한 줄에 하나씩): 해외여행 중 현지 약국에서 약을 사야 할 때가 있는데, 한국에서 먹던 약은 없다. 현지 약 중 어떤 게 내가 먹던 약과 성분이 같거나 비슷한지 판단하기 어렵다. 이걸 도와주는 서비스가 마땅히 없다. 핵심 기능 (한두 개면 충분): 한국 약과 해외 약(우선 미국)의 성분 비교 그 비교를 누구나 검색할 수 있게 정리 [꼭 지킬 것] 꼭 지킬 것 (면책 · 하지 않을 것 · 넘지 않을 선): 의학적 조언이 아니다. 성분이 같거나 가장 가까운 제품을 알려 주는 참고용이라는 면책 문구를 넣는다. 약 판매·약 광고·약 제휴는 하지 않는다. 복용량을 계산하거나 개인에게 맞는 약을 판단해 주지 않는다. [내 생각: 에이전트가 더 좋게 바꿔도 됨] 수익 모델 (내 생각만. 에이전트가 구체화·개선): 방문자가 여행자니까 여행자 보험 제휴, 항공사 제휴. 트래픽 비용을 감당할 수 있을지도 봐 줘. 방문자 모으기 (SEO 글 · 커뮤니티 · SNS): 약·여행 관련 SEO 글로 사람들을 데려오고 싶어. 처음 시작 범위 (작게 시작할 범위): 한국 → 미국, 처방 없이 사는 약만. 기술 구성 (모르면 비워 두기): 데모는 Vercel + Supabase. === 1단계 기획 키우기 (2/2) === 데이터는 API 이름을 주지 않고 필요한 정보만 적습니다. 어떤 API를 쓸 수 있는지는 에이전트가 찾아 구별합니다. [에이전트가 찾을 것] 필요한 데이터 (어떤 정보가 필요한지만. API 이름은 적지 않음): 한국 약과 미국 약 정보(제품명, 성분, 함량, 효능, 주의사항) 이 서비스만의 어려운 점 (에이전트가 풀어 줘야 할 것): 나라마다 성분 이름·함량·표기가 다른데, 어떻게 같은 성분으로 묶고 비교할지 나눠 맡길 에이전트 (Atoms의 역할 에이전트): Deep Research, Data Analyst, SEO Specialist [양식에 들어 있는 요청: 그대로 둠] 1. 데이터: [필요한 데이터]를 가져올 수 있는 공개 API·공개 데이터를 찾아 구별해 줘. - 바로 쓸 수 있는 것 / 키 발급이 필요한 것 / 상업 이용에 제한이 있는 것 / 쓸 수 없는 것 - 각각 주는 정보, 호출 한도, 갱신 주기 · 무엇을 어떻게 조합할지 추천 2. 어려운 점: [이 서비스만의 어려운 점]을 어떻게 풀지 3. 내 생각 개선: 수익 모델·방문자 모으기·시작 범위·기술을 더 구체화하거나 더 좋은 안을 이유와 함께 4. 기능: 첫 버전에 넣을 것과 미룰 것, 내가 생각 못 한 기능 5. 위험 요소: 법·안전·데이터 품질 면에서 조심할 것 6. 역할 분담: [나눠 맡길 에이전트]에게 어떤 일을 나눌지 7. 구현 순서: 작게 시작해서 키워 가는 단계 8. 답하는 방식: 내 기획에서 바뀌거나 늘어난 부분을 따로 표시하고, 내가 정해야 할 것을 질문 목록으로 === 2단계 데이터 만들기 === 1단계 답을 읽고, 에이전트가 제안한 것 중에서 고른 것을 적습니다. 고르는 건 사람이 합니다. [1단계 답에서 고른 것] 고른 데이터 · API (1단계 답의 API 목록에서): (1단계 답을 읽고 적는 칸) 첫 버전 범위 (1단계 답에서): (1단계 답을 읽고 적는 칸) 수익 모델 (1단계 답에서): (1단계 답을 읽고 적는 칸) [데이터 만들기] 데이터 가공 규칙 (묶기 · 비교 · 정리): 성분을 같은 기준으로 묶고 한국 약 ↔ 미국 약 비교 결과를 계산한다. 자동으로 못 묶은 것은 억지로 맞추지 말고 "확인 필요"로 남긴다. [에이전트가 보여 줄 것] 확인용으로 보여 줄 것 (숫자 · 목록 · 예시 검증): 가져온 제품 수, 비교된 쌍 수, 확인 필요 목록 많이 찾는 약 10개(타이레놀, 판콜에이, 지르텍 등)의 미국 쪽 결과가 맞는지 표로 [양식에 들어 있는 요청: 그대로 둠] - 데이터베이스 표와 접근 권한을 만든다. 공개 사용자는 읽기만 한다. - 고른 데이터를 가져오는 스크립트를 만든다. API 키는 코드에 넣지 않고 환경 변수에 둔다. === 3단계 화면 만들기 === 누가 어떤 상황에서 보는지부터 적습니다. 안내 문구는 기능보다 먼저입니다. [화면] 사용 상황 (어디서 · 무엇으로 보나): 여행 중 약국 앞에서 휴대폰으로 본다. 모바일 먼저, 글씨는 크게. 필요한 화면 (한 줄에 하나씩): 첫 화면: 검색창 하나. 약 이름·성분·증상으로 찾기. 한글 일부, 영어 성분명도. 결과: 성분·함량이 같은 것, 함량만 다른 것, 일부 성분만 같은 것을 나눠서. 데이터 출처와 마지막 갱신 날짜 표시. [꼭 지킬 것] 화면에서 꼭 지킬 것 (문구 · 표현 · 안내): 면책 문구는 모든 결과 화면 위쪽에. 임신·수유, 어린이, 지병, 다른 약 복용 중이면 약사와 상의하라는 안내. "추천" 대신 "성분이 같은 제품", "성분이 비슷한 제품". [에이전트 제안] 편의 기능 예시 (에이전트가 하나 골라 넣음): 약사에게 보여 줄 영어 화면 === 4단계 수익화 · 배포 === 수익 영역은 핵심 결과와 분리합니다. 점검표로 확인한 뒤 배포합니다. [수익화] 수익 영역 넣는 방식 (어디에 · 어떻게 표시): 제휴 영역은 약 비교 결과와 분리하고 "광고·제휴" 표시를 붙인다. [방문자 모으기] 방문자 모으기 작업 (페이지 · 글): 약마다 고정 주소 페이지, 메타 태그, 사이트맵. 1단계에서 제안한 SEO 글 두 개 먼저(면책 문구 포함). [배포 전 점검] 배포 전 점검표 (에이전트가 확인할 항목): 모든 결과 화면에 면책 문구가 있는가 약 광고·약 제휴가 없는가 공개 사용자가 데이터를 고칠 수 없는가 API 키가 코드에 없는가 [양식에 들어 있는 요청: 그대로 둠] - 링크 주소는 나중에 넣을 수 있게 설정 값으로 둔다. 클릭 수는 개인 정보 없이 집계한다. - 배포하고 주소를 알려 준다. 점검표 결과를 보여 준다.
4. 기획서 PDF를 팀 리더 Mike에게 넘기기 · 12:56
채운 기획서를 PDF로 저장하고 Atoms 입력창으로 끌어다 놓습니다. 영상에서는 양식 화면의 인쇄 메뉴로 PDF를 만들었고, 다섯 쪽짜리 파일이 그대로 첨부됐습니다. 세부 내용은 PDF에 들어 있으므로 프롬프트는 짧게 씁니다. 팀 리더 Mike를 @로 부르고 아래 한 줄을 함께 보냈습니다(13:04).
@Mike 기획서 양식대로 프로젝트를 진행해보자Mike는 PDF를 읽고 작업을 만든 뒤 엔지니어 Alex에게 양식 분석을 먼저 맡겼습니다(13:19). 분석 결과는 서비스 요구사항, 비어 있거나 미확정인 필수 항목, 사용자에게 먼저 확인할 질문으로 정리돼 나옵니다.
5. 에이전트가 묻는 세 가지에 답하기 · 13:28
분석이 끝나면 Atoms는 개발 전에 정해야 할 선택형 질문 세 개를 보여 줍니다. 영상 화면의 질문과 선택지, 실제로 고른 답은 다음과 같습니다.
| 질문 | 화면의 선택지 | 영상에서 고른 답 |
|---|---|---|
| 진행 방식 | PDF 1단계의 데이터 조사·위험 검토·MVP 제안부터, 이미 확정한 기획으로 구현 준비, 기획서 수정부터 | 기획서와 에이전트가 더한 기획을 합쳐 구현까지 진행 |
| 기술안 | Vercel + Supabase 유지, Atoms Cloud로 변경 허용, 비교 제안 후 결정 | Vercel + Supabase로 진행 |
| 초기 데이터 | 약 10개 검증부터, 사용자 지정 목록, 조사 후 작은 후보 목록 제안 | 대표적인 약 최소 100개 이상 |
Atoms Cloud는 로그인, 데이터베이스, 연동, 호스팅을 Atoms 안에서 제공하는 백엔드입니다(Atoms 첫 화면 소개 기준). 영상에서는 기획서에 적은 대로 Vercel과 Supabase를 유지했습니다. 답은 질문 번호에 맞춰 세 줄로 보냈습니다.
1. 기획과 추가로 기획한 부분을 다 합쳐서 구현까지 진행
2. Vercel + Supabase 로 진행
3. 최소 100개 이상 대표적인 약으로 진행
6. GitHub·Vercel·Supabase 연결하기 · 14:40
Vercel과 Supabase로 진행한다고 답하자 Atoms가 채팅 아래쪽에 키 입력 양식을 띄웠습니다. 영상에서는 GITHUB_TOKEN과 VERCEL_TOKEN 두 값을 요구했고, 둘 다 넣고 제출하면 두 키의 설정을 마쳤다는 메시지가 채팅에 남습니다(16:57).
토큰은 계정 권한을 넘기는 비밀값입니다. Atoms 도움말의 GitHub 연결 문서는 토큰과 비밀번호를 채팅 메시지에 붙여 넣지 말라고 안내합니다. Atoms가 띄운 키 입력 양식이 아니라 일반 채팅창이라면 붙여 넣지 않습니다.
GitHub 저장소와 토큰 만들기 · 14:40
GitHub는 서비스 소스 코드를 저장하는 곳으로, 새 저장소를 만들어 이름을 정하고 공개 범위를 비공개(Private)로 둡니다. 영상에서는 Medicine Finder라는 이름으로 medicine-finder 저장소를 만들었습니다(14:54).
다음은 에이전트가 이 저장소를 다룰 수 있게 하는 개인 액세스 토큰입니다. GitHub 설정의 Developer settings에서 Personal access tokens를 열면 Fine-grained tokens와 Tokens (classic)이 있습니다. 영상에서는 Generate new token에서 classic을 골라 Note에 atoms를 적고, 만료일(Expiration)은 30일, 범위는 repo 하나만 체크했습니다.
GitHub의 토큰 관리 문서는 가능하면 classic 대신 fine-grained 토큰을 쓰고 만료일을 두라고 권합니다. fine-grained 토큰은 접근할 저장소를 고르고 권한을 세밀하게 나눌 수 있어, 영상 15:35에서도 AI에게 권한을 주는 것이 불안하면 이쪽을 쓰라고 설명합니다. 생성된 토큰 값을 복사해 Atoms 입력 양식의 GITHUB_TOKEN 칸에 붙여 넣습니다.
같은 Atoms 도움말에 따르면 GitHub는 Connectors 메뉴에서 OAuth로 연결할 수도 있고, 이때는 개인 액세스 토큰이 필요 없습니다. 이 방식은 연결한 개인 계정에 새 비공개 저장소를 만들며 기존 저장소에는 연결하지 않습니다. 영상 17:55에서도 GitHub를 커넥터로 연결하면 더 빠르다고 설명하며, 영상은 두 방법을 모두 보여 주려고 GitHub에는 토큰 방식을 썼습니다.
Vercel 토큰 만들기 · 16:02
Vercel은 GitHub에 올라간 코드를 웹사이트로 배포하며, 방금 저장소를 만든 GitHub 계정으로 가입하거나 로그인합니다. 새 프로젝트 가져오기는 코드가 올라간 뒤에 할 수 있으므로 이 단계에서는 토큰만 만듭니다.
Vercel 대시보드 왼쪽 검색창에 token을 검색해 Tokens 화면으로 갑니다. 영상에서는 토큰 이름을 atoms로 적고, 범위(Scope)는 자신의 프로젝트 전체가 담긴 개인 팀으로, 만료일은 7일로 정했습니다(16:32). Vercel의 액세스 토큰 문서에 따르면 범위는 계정 전체(Full Account)나 특정 팀으로 고를 수 있고, 토큰 값은 만들 때 한 번만 보입니다. 나온 값을 복사해 Atoms 입력 양식의 VERCEL_TOKEN 칸에 넣고 Submit을 누릅니다.
Supabase 프로젝트와 커넥터 연결하기 · 16:55
Supabase는 약 데이터를 담을 데이터베이스입니다. 같은 GitHub 계정으로 로그인한 뒤 새 프로젝트를 만들고, GitHub 항목에는 앞에서 만든 저장소를 고릅니다. 프로젝트 이름과 데이터베이스 비밀번호도 정합니다.
지역(Region)은 서비스를 가장 많이 쓸 사람이 있는 곳으로 고릅니다. 영상은 미국에 온 여행자를 주 사용자로 보고 Americas를 그대로 두었습니다. 보안(Security)은 Enable Data API를 켜고, Automatically expose new tables는 끄고, Enable automatic RLS를 켰습니다(17:22). 화면 설명에 따르면 자동 RLS는 public 스키마에 새로 생기는 모든 테이블에 행 수준 보안(Row Level Security)을 켜는 트리거를 만들고, 새 테이블 자동 노출 항목에는 접근을 직접 관리하려면 끄기를 권한다는 문구가 붙어 있습니다.
Supabase의 RLS 문서는 외부에 노출되는 스키마의 모든 테이블에 RLS를 켜라고 안내합니다. 배포 전 권한 점검 기준은 바이브 코딩 보안 가이드에 따로 정리돼 있습니다.
프로젝트를 만든 뒤 Atoms로 돌아와 Connectors에서 Supabase를 고르고 New Organization을 누릅니다. GitHub로 로그인하고 Authorize Atoms를 누르면 토큰을 따로 만들지 않고 연결됩니다(17:44). Atoms 도움말의 Supabase 연결 문서에 따르면 New Organization은 새 Supabase 조직을 만드는 버튼이 아니라 계정에 이미 있는 다른 조직을 승인하는 버튼이고, 승인한 조직에서 쓸 프로젝트를 골라 Connect를 누릅니다.
7. 에이전트 작업 읽기: 국내·미국 약 데이터 출처 · 18:00
에이전트가 일하는 동안 결과만 기다리지 않고 진행 기록을 읽습니다. 엔지니어 Alex는 출처 보고서에서 실제로 접근해 본 결과와 확인하지 못한 범위를 나눠 적었습니다(18:08).
| 구분 | 영상 속 보고 내용 |
|---|---|
| 키 없이 받은 국내 자료 | 공공데이터포털의 건강보험심사평가원(심평원) 의약품 주성분·표준코드 파일. 일반명코드, 성분명, 함량, 한글상품명, 품목기준코드 등 |
| 인증키가 필요한 식품의약품안전처(식약처) 자료 | e약은요는 키 없이 시험한 호출이 실패했고, 의약품 제품 허가정보 API도 인증키 기반이라 키 없는 출처에서 뺌 |
| 키 없이 받은 미국 자료 | FDA의 openFDA NDC(National Drug Code) 목록. 상품명, 성분·함량, 제형, 투여 경로 등 |
공공데이터포털의 식약처 의약품 제품 허가정보 API 페이지도 활용신청으로 받은 인증키를 요청에 넣어야 호출되는 구조입니다. 식약처 자료를 쓰려면 활용신청으로 인증키를 받아 에이전트에게 넘기는 단계가 더 필요합니다.
공개 데이터를 가져올 때는 출처 표시 의무도 확인합니다(18:44). openFDA 이용 약관은 별도 표시가 없는 자료를 공공 영역(CC0)으로 두고 출처 표시는 의무가 아닌 요청으로 적었습니다. 공공데이터포털의 심평원 의약품 주성분 파일은 이용허락범위가 출처표시(제1유형)입니다.
영상 18:40에서 본 openFDA 화면에는 generic_name, brand_name, substance_name 같은 필드가 데이터셋별로 정리돼 있습니다. openFDA 필드 안내에 따르면 데이터셋마다 상품명과 일반명 같은 식별자가 달라 같은 약을 찾기 어렵고, 표기가 정확히 일치해야 묶이므로 일부 제품은 묶이지 않습니다.
8. 첫 버전 비교 결과 확인하기 · 18:54
첫 버전은 "이름은 달라도, 성분으로 비교하세요."라는 제목 아래 한국 약 이름이나 성분을 넣는 검색창과 비교 후보 목록으로 나왔습니다. 녹화 시점의 비교 후보는 2,957쌍이었고 전체, 일치에 가까움, 성분 유사, 확인 필요 탭으로 나뉩니다. 비교 보기를 누르면 두 제품의 원문 성분·함량·제형·투여 경로와 겹치는 성분이 나란히 나옵니다.
뒤에 붙은 이용 가이드는 2,957쌍을 일치에 가까움 63쌍, 성분 유사 980쌍, 확인 필요 1,914쌍으로 나눴습니다. 같은 가이드는 HIGH 근거 등급이 0쌍이고 2,957쌍 모두 추가 라벨 검토가 필요하다고 적었습니다. 영상에서도 데이터에서 가져온 결과라 지어낸 것은 아니겠지만 두 약에 이 성분만 있을 것 같지는 않다며, 하나씩 비교해 완성도를 높여야 한다고 말합니다(19:39). 결과 화면 위쪽에는 의학적 조언이 아닌 성분 비교 참고 정보라는 안내가 붙어 있고, 실제로 약을 고를 때는 현지 약사나 의사에게 확인해야 합니다.
성분이 같아도 함량, 제형, 사용 조건이 다를 수 있어 비교 결과는 복용 대체 가능성을 뜻하지 않습니다. 성분집합 점수가 높은 쌍도 라벨 원문을 다시 확인해야 하는 후보입니다.
FDA의 openFDA 의약품 라벨 API 문서도 이 데이터로 의료 결정을 내리지 말고 의료인과 상의하라고 안내합니다. 임신·수유 중이거나 어린이, 지병이 있거나 다른 약을 먹고 있다면 특히 먼저 상의합니다.
9. SEO 에이전트로 이용 가이드 붙이기 · 19:57
약 목록만 올려서는 검색으로 사람이 들어오지 않으므로 SEO 작업을 따로 맡깁니다. 왼쪽 에이전트 채팅에 아래 한 줄을 보내 SEO 전문가 Sarah를 불렀습니다(20:08).
SEO 스페셜 에이전트를 소환해서 우리 웹사이트 SEO 작업을 진행해줘.Sarah가 성분 비교 서비스와 관련된 글 두 편을 쓰자 Mike가 결과를 받아 엔지니어 Alex를 다시 불렀고, Alex는 글을 사이트에 반영하면서 메타데이터, 사이트맵, Open Graph까지 확인했습니다(20:36). 작업이 끝나면 첫 화면에 없던 이용 가이드 메뉴가 생기고, 비교 결과를 읽는 방법과 검색하는 방법을 다룬 글이 붙습니다.
10. Vercel 배포 주소 확인하기 · 21:22
GitHub와 Vercel을 연결해 두었으므로 Atoms 에이전트가 코드를 GitHub에 올리고 Vercel 배포까지 진행합니다. Vercel 프로젝트 화면에서 운영 배포(Production Deployment)가 Ready인지 보고, Domains에 나온 vercel.app 주소를 열어 Atoms 미리보기와 같은 화면이 나오는지 확인합니다. 영상의 배포 기록에는 "성분 비교 SEO 가이드 2개와 공식 도메인 메타 통합"이라는 커밋이 올라가 있었습니다.
배포 주소의 첫 화면에는 "Supabase DB 미연결" 표시가 있었고, 영상 23:52에서도 에이전트들이 Supabase 데이터베이스를 마지막으로 연결하는 중이라고 말합니다. 녹화 시점의 사이트는 분석 결과 스냅샷을 보여 주는 첫 버전이었습니다.
수익화는 다음 단계로 남아 있습니다. 영상의 계획은 약과 관련 없는 여행자 보험사나 항공사와의 제휴이고, 그러려면 사이트에 쓸모 있는 정보를 쌓아 방문자를 늘려야 한다고 정리합니다(22:20).
바이브 코딩 전에 정할 것: 요구사항·데이터·완료 조건
화면이 생겼다는 이유만으로 앱의 요구사항이 충족되지는 않습니다. 작은 자료 보관 앱을 예로 기능 범위, 데이터 변경 규칙, 성공과 실패의 수용 조건을 구체화합니다.
온스페이스로 마음미술관 앱 만들기: 마스터 프롬프트 전문 가이드
오늘 마음을 한 줄 적으면 메트로폴리탄 미술관의 실제 명화 세 점과 해설을 보여주는 앱 마음미술관을 온스페이스에서 프롬프트 한 개로 만들었습니다. 영상에서 쓴 마스터 프롬프트 전문과 넣는 순서, 자주 막히는 부분, 배포와 결제까지 정리했습니다.
AI로 만든 앱, 출시 뒤에는 무엇을 관리해야 할까
앱이 공개된 뒤에는 계정 접근, 오류와 비용 변화, 데이터 복구를 계속 맡을 사람이 필요합니다. 작은 서비스에 맞춘 운영 책임표와 복구 확인 기준을 정리합니다.