개발 외주 주지 마세요.. 기획서 하나면 Atoms 에이전트 팀이 배포까지 끝냅니다.. ㄷㄷ

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Atoms 에이전트 팀은 기획서를 바탕으로 웹서비스의 첫 버전 배포까지 진행할 수 있지만, 데이터 검증과 수익화는 사람이 계속 풀어야 할 과제다.

📌 핵심 요점

1. 수익화의 출발점은 AI로 만들 수 있는 기능이 아니라 고객이 돈을 내고 해결하려는 불편이다. 발표자는 기능을 계속 추가하기보다 일정 수준의 품질을 갖춘 뒤 반응을 빠르게 확인하라고 강조한다.
2. 사례는 해외여행 중 한국에서 먹던 약과 성분이 같거나 비슷한 미국 약을 찾는 웹서비스다. 국내외 의약품 데이터 비교와 검색 화면을 핵심 기능으로 삼고, 여행 보험·항공 관련 제휴를 수익모델 후보로 제시한다.
3. 서비스 기획서에는 해결할 문제, 핵심 기능, 반드시 지킬 조건 등을 담는다. 이를 PDF로 Atoms에 전달하고 팀 리더 에이전트를 호출하면, 에이전트들이 요구사항을 분석하고 미확정 항목을 질문하며 작업을 나눈다.
4. 시연에서는 GitHub에 코드를 저장하고 Vercel로 배포하며 Supabase를 연결한다. SEO 에이전트의 작업을 팀 리더가 받아 엔지니어에게 넘기는 등 역할별 협업도 보여준다.
5. 배포된 화면은 확인했지만 상용 서비스의 완성이나 매출 발생을 입증한 영상은 아니다. 의약품 매칭 대부분은 추가 확인이 필요하고, 영상 끝에도 Supabase 데이터베이스 연결 작업이 진행 중이다.

🧩 배경과 문제 정의

발표자는 AI 에이전트가 조사·제작·검증을 나누어 수행하면서 비개발자도 서비스를 만들기 쉬워졌다고 설명한다. 하지만 제작이 쉬워졌다는 이유만으로 고객이 돈을 내는 것은 아니며, 누구나 만들 수 있는 결과물을 그대로 배포하거나 기능 추가에만 몰두하는 방식에는 한계가 있다고 지적한다.

영상은 해외여행 중 익숙한 한국 약 대신 어떤 현지 약을 찾아야 하는지 어렵다는 불편을 사례로 삼는다. 한국과 미국 의약품의 성분을 비교하는 웹서비스를 기획하고, Atoms 에이전트 팀에 기획서를 전달해 첫 버전 구현과 배포를 진행한다. 수익화는 여행 관련 제휴를 통한 향후 과제로 남으며, 의약품 데이터 검증과 데이터베이스 연결도 완결됐다고 보기 어렵다.

🕒 시간순 섹션별 상세정리

1. 에이전트 시대에도 남는 수익화 질문

• 발표자는 에이전트의 결합으로 비개발자도 간단한 프롬프트와 데이터 조합을 통해 서비스를 만들기 쉬워졌다고 보여준다. 조사·제작·검증을 맡길 자원이 늘었다는 주장이다. [00:48]
• 핵심 질문은 사람들이 비슷한 서비스 대신 자신이 만든 서비스에 왜 돈을 내느냐는 것이다. 앞서 만든 주식 분석 도구는 TradingView 데이터를 얹은 개인 사용 목적의 사례라고 구분한다. [01:17]
• 기존 수익화 경험자는 에이전트로 익숙한 구조를 빠르게 실행할 수 있지만 초보자는 활용 사례 자체를 익혀야 한다며, 새로운 사업 아이디어를 기획부터 보여주겠다고 예고한다. [02:06]

2. 고객의 불편과 초기 반응을 먼저 확인하기

• 수익화의 본질을 불편 해결로 보여준다. 케이크를 자르기 불편할 때 칼에 돈을 지불하는 비유로, 기능의 존재보다 해결되는 문제가 중요하다고 드러낸다. [03:01]
• 처음부터 모든 부분을 완벽하게 만들 필요는 없지만 기본 품질은 갖춰야 한다. 기능을 계속 붙이기보다 해결할 불편을 좁히고 사용자 반응을 먼저 테스트하라고 제안한다. [03:45]

3. 쉽게 만든 결과물과 제작 몰입의 함정

• 에이전트가 금방 만든 주식 분석 도구를 그대로 유료 서비스로 내놓으면 차별성이 부족하다고 보여준다. 누구나 비슷하게 만들 수 있으므로 구체적인 디테일이 필요하다는 주장이다. [04:14]
• 디테일을 더한다는 이유로 몇 달씩 제작에만 몰두하는 것도 경계한다. 현재 문제를 분석하고 해결 아이디어를 세운 뒤 에이전트로 빠르게 테스트하는 흐름을 강조한다. [04:59]

4. 오픈소스와 공개 데이터를 서비스 재료로 쓰기

• 해결법을 처음부터 만들기보다 GitHub 등에 공개된 오픈소스를 가져와 목적에 맞게 고치는 접근을 제시한다. 내부 로직과 바이너리 이해를 돕는 도구를 예시로 든다. [05:51]
• 공개 데이터를 자신의 서비스와 연결하면 단순한 봇 응답보다 구체적인 불편을 해결하는 결과물을 만들 수 있다고 보여준다. [06:18]

5. 문제 발견부터 배포까지 순서 세우기

• 전체 과정을 불편 발견, 검증, 실제 동작하는 서비스 제작, 배포로 정리한다. 무엇을 만드는지와 작동 구조를 모른 채 결과물부터 배포하면 차별성과 유지보수에 문제가 생긴다고 지적한다. [06:52]
• 자동화의 가치는 구조를 이해하고 불편 해결에 맞게 사용하는 데 있다고 강조한다. 자신도 해결할 문제와 품질을 높일 데이터를 먼저 고민한 뒤 서비스를 만들겠다고 보여준다. [07:31]

6. 여행 중 현지 약을 찾는 서비스와 수익모델 구상

• 해외 약국에서 한국에서 먹던 약을 구하기 어려울 때, 현지 약의 성분과 기존 약의 관계를 판단하기 어렵다는 불편을 사례로 선택한다. [08:01]
• 한국과 미국 약의 성분을 비교하고 사용자가 검색할 웹사이트를 만드는 두 가지 핵심 작업을 정한다. 운영 시 트래픽 비용이 발생하므로 수익모델도 함께 생각해야 한다고 드러낸다. [08:33]
• 여행 보험·항공 관련 제휴를 수익모델 후보로 제시하고 약 자체의 제휴는 하지 않겠다고 보여준다. 성분 비교는 의학적 조언이 아닌 참고 정보라는 안내를 넣고, 최소한의 기획에서 에이전트와 대화하며 발전시키겠다고 한다. [09:27]

7. Atoms의 역할별 에이전트와 협업 방식 소개

• Atoms에는 팀 리더, 광고·SEO 전문가, 프로덕트 매니저, 아키텍처·엔지니어·데이터 분석·심층 조사 역할이 나뉘어 있어 여러 작업이 필요한 서비스에 적합하다고 보여준다. [10:49]
• 발표자는 플랫폼과 함께 영상을 준비했다고 드러낸다. 에이전트를 태그해 호출할 수 있으며 데이터 분석 담당자에게 미국 FDA 약 조사를 맡기는 식의 요청이 가능하다고 보여준다. [11:34]
• 이번 시연은 짧은 요청만 입력하는 대신 서비스 기획서를 기반으로 진행하며, 시청자에게도 템플릿을 제공하겠다고 예고한다. [11:42]

8. 디자인 선택과 서비스 기획서 전달

• 테마와 색상을 선택할 수 있는 화면을 보여주고, 의약품이라는 주제에 맞춰 신뢰감을 주려는 파란색 테마를 고른다. [12:09]
• 기획서에는 만들 서비스, 불편한 지점, 핵심 기능, 반드시 지킬 조건 등을 작성한다. 여행 중 한국 약과 성분이 같거나 비슷한 현지 약을 찾는 웹서비스로 내용을 채운다. [12:54]
• 기획서를 PDF로 저장해 Atoms에 첨부하고 팀 리더 마이크에게 프로젝트 진행을 요청한다. 상세 내용이 파일에 있으므로 실행 프롬프트는 간단하게 작성한다. [13:12]

9. 요구사항 질문에 답하고 구현 범위 확정하기

• 팀 리더가 업무를 정리하고 엔지니어 알렉스를 호출한다. 에이전트는 파악한 요구사항, 미확정 항목, 사용자가 결정해야 할 질문을 제시한다. [13:37]
• 구현까지 진행할지, 어떤 기술 구성을 사용할지, 어느 정도의 약 데이터를 다룰지 질문한다. 발표자는 기획 보완과 구현을 진행하고 Vercel·Supabase를 사용하며 대표 약을 최소 100개 이상 다루겠다고 답한다. [14:29]
• 에이전트들이 협업을 이어가는 동안 외부 서비스 연결에 필요한 키를 요청한다. [14:40]

10. GitHub 저장소와 Vercel 배포 권한 연결

• 비공개 GitHub 저장소를 만들고 접근 토큰을 발급한다. 시연에서는 클래식 토큰을 사용하지만, 저장소와 권한을 더 세밀하게 정하는 파인그레인드 토큰도 보여준다. [15:52]
• GitHub 토큰을 Atoms에 전달하고, 같은 GitHub 계정으로 Vercel에 가입하거나 로그인한다. 코드가 준비된 후 프로젝트를 가져올 수 있다고 보여준다. [16:21]
• Vercel 토큰의 범위와 만료일을 설정해 Atoms에 전달한다. 시연에서는 전체 프로젝트를 대상으로 선택하고 만료일을 약 7일로 설정한다. [16:52]

11. Supabase 연결과 데이터 출처 확인

• Supabase 프로젝트를 만들면서 주요 이용자의 위치를 기준으로 리전을 선택한다. 미국 여행자를 대상으로 하므로 미국 지역을 택하고 행 수준 보안 설정도 언급한다. [17:30]
• Atoms 커넥터로 Supabase를 연결한다. GitHub 역시 커넥터로 연결할 수 있으며, 영상에서는 토큰과 커넥터 두 방식을 보여주기 위해 다르게 진행했다고 보여준다. [17:59]
• 작업 보고에서 국내 식약처 자료는 인증키가 필요해 확인하지 못했고 미국 FDA 자료는 가져올 수 있었다는 내용을 읽는다. 공개 데이터의 필드와 출처 표시·라이선스 조건도 확인해야 한다고 강조한다. [18:52]

12. 첫 비교 화면과 의약품 데이터의 검증 과제

• 첫 버전에 약 3,000개에 가까운 비교 결과가 표시된다. 에이전트들이 분야를 나누어 작업했지만 모든 결과가 유사한 것은 아니며 대부분 확인이 필요하다고 보여준다. [19:20]
• 두 제품의 성분, 겹치는 성분, 판단 출처를 보여주는 비교 화면을 살펴본다. 전문적인 서비스에는 면책 문구를 넣어야 한다고 다시 강조한다. [19:37]
• 발표자는 화면에 표시된 성분이 전부인지 의문을 제기한다. 데이터에서 가져왔다는 이유만으로 검토를 생략하지 않고 하나씩 비교해 완성도를 높여야 한다고 드러낸다. [19:56]

13. SEO 작업을 다른 에이전트와 구현에 연결하기

• 데이터가 많다는 이유만으로 방문자가 오지는 않는다며 SEO 전문가를 호출한다. 약 성분 비교와 관련된 글을 웹사이트에 추가하도록 요청한다. [20:25]
• SEO 작업을 팀 리더가 전달받아 엔지니어를 다시 호출하고, 메타데이터·사이트맵·오픈 그래프 등을 점검하는 모습을 보여준다. [20:56]
• 새로 생긴 이용 가이드에서 사용법과 검색 방법을 확인한다. 발표자는 이런 내용도 계속 발전시킬 대상으로 본다. [21:21]

14. 실제 도메인 배포 확인과 남은 사업화 과제

• 에이전트가 GitHub에 코드를 푸시하고 Vercel과 연동해 배포한 화면을 확인한다. 실제 도메인에서도 이용 가이드까지 반영된 모습을 보여준다. [21:46]
• 이번 결과를 기획서의 내용을 채우고 에이전트와 방향을 조율해 만든 첫 번째 서비스 버전으로 정리한다. 이후에도 개선하며 수익화에 도전하겠다고 드러낸다. [22:10]
• 약 자체의 수익화에는 위험이 있다고 보고 여행 보험사·항공사 제휴를 다시 제안한다. 이를 위해 양질의 정보와 많은 트래픽이 필요하며 후속 영상에서 이어가겠다고 한다. [22:38]

15. 추가 기능·플랜 안내와 미완료 작업을 남긴 마무리

• 서비스 제작 외에도 비디오 생성, 분석, 심층 검색을 활용할 수 있다고 보여준다. 다른 사용자의 예시와 웹사이트 템플릿에서 아이디어를 얻거나 수정해 사용할 수 있다고 보여준다. [23:17]
• 무료 체험과 프로·맥스 플랜을 보여준다. 발표자는 서비스 제작에 100크레딧 이상이 드는 것 같다고 추정하고, 연간 가입 시 21% 할인 혜택이 있다고 안내한다. [23:48]
• 마지막에도 에이전트가 Supabase 데이터베이스 연결을 진행 중이며 계속 개선하겠다고 드러낸다. 기획서 템플릿을 고정 댓글과 설명란에 남기겠다고 안내한 뒤 구독 등을 요청하며 영상을 끝낸다. [24:26]

🧾 결론

• 기획서는 에이전트에게 서비스의 방향과 제약을 전달하는 기준점이다. 짧은 실행 요청도 상세한 기획서가 뒷받침할 때 의미가 있다.
• 에이전트의 분업은 조사·구현·검색 유입 준비·배포를 연결하지만, 사용자는 진행 내용을 읽고 데이터와 결과물의 품질을 확인해야 한다.
• 첫 버전을 만드는 속도와 고객이 사용할 이유는 별개의 문제다. 발표자가 제시한 다음 과제는 정보의 완성도 개선, 트래픽 확보, 제휴 수익화다.

📈 투자·시사 포인트

• 제작이 쉬워질수록 단순히 AI로 만들었다는 사실의 차별성은 약해진다. 영상은 구체적인 불편 해결과 데이터의 디테일을 서비스 경쟁력의 근거로 제시한다.
• 사업성은 개발 비용뿐 아니라 배포 후 트래픽 비용과 고객 유입 경로까지 함께 검토해야 한다. 사례에서는 SEO 콘텐츠와 여행 관련 제휴를 연결하는 구상을 제시한다.
• 공개 데이터와 오픈소스는 처음부터 만드는 부담을 줄이는 재료다. 다만 출처·라이선스와 실제 데이터 품질을 확인하는 작업도 필요하다.
• 무료 체험과 유료 플랜이 소개되지만, 실제 제작 비용이나 수익성은 검증되지 않았다. 발표자의 크레딧 사용 추정과 제휴 구상을 확정된 비용·매출로 해석해서는 안 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 국내 식약처 자료는 인증키 문제로 확인하지 못했다는 에이전트 보고가 나온다. 최종 서비스에서 국내 데이터가 어디까지 확보·검증됐는지는 영상만으로 확정하기 어렵다.
• 약 3,000개에 가까운 비교 결과가 표시되지만, 발표자는 대부분 추가 확인이 필요하다고 설명한다. 성분 누락 가능성도 언급하므로 결과 수를 검증된 대체약 수로 해석할 수 없다.
• 발표자는 참고용 정보와 면책 문구를 강조한다. 그러나 영상은 의약품 매칭의 정확성이나 개인별 복용 적합성, 면책 문구의 충분성을 검증하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 해결하려는 불편, 대상 사용자, 핵심 기능, 반드시 지킬 조건을 서비스 기획서에 적고 PDF로 정리한다.
• 첫 버전의 범위를 정한 뒤 에이전트가 묻는 구현 단계, 기술 구성, 데이터 범위에 답한다.
• 데이터의 출처·인증 요구사항·라이선스·출처 표시 조건을 확인하고, 대표 사례를 직접 비교해 누락과 잘못된 매칭을 점검한다.
• GitHub·Vercel·Supabase 연결 시 권한 범위와 만료일을 검토하고, 배포된 도메인에서 검색·비교·데이터 연결을 확인한다.

❓ 열린 질문

• 국내 데이터의 인증 문제를 해결한 뒤에도 한국·미국 의약품 성분을 일관되게 비교할 수 있는가?
• 추가 확인이 필요한 매칭을 어떤 기준과 절차로 검증하고, 데이터 변경에 맞춰 어떻게 유지보수할 것인가?
• 여행 중 약을 찾는 사용자의 수요가 반복적인 검색 유입과 보험·항공 제휴 수익으로 이어질 것인가?