제18장 실전 3: 비개발자의 첫 앱

비개발자가 Antigravity를 처음 열면 자주 두 가지 착각을 한다. 하나는 "이제 코드를 하나도 몰라도 서비스 하나쯤은 금방 만들겠네"라는 기대다. 다른 하나는 "그래도 결국 개발자 없이는 아무것도 못 하겠지"라는 체념이다. 둘 다 반만 맞다.

Antigravity는 실제로 기획, 구현, 실행, 검증을 한 흐름으로 이어 주는 도구다. 계획 문서를 만들고, 코드를 쓰고, 브라우저에서 확인하고, 결과를 Artifacts로 남기는 식의 작업이 가능하다.¹² 그래서 PM이나 1인 창업자도 "아이디어를 말로 설명해 실제 앱 모양으로 바꾸는 경험"을 훨씬 빠르게 할 수 있다. 하지만 여기서 중요한 단서가 하나 있다. 코드를 직접 쓰지 않아도, 무엇을 만들지와 무엇을 만들지 말아야 하는지는 사람이 반드시 통제해야 한다.

이 장의 목표는 바로 그것이다. 1인 창업자와 PM이 한국어로 프롬프트를 써서 첫 프로토타입을 만들고, 외부 API를 붙이고, 빠르게 배포하되, 최소한의 기술 부채만 남기는 법을 익히는 것. 쉽게 말해 "손은 덜 쓰되, 판단은 더 정확하게 하는 법"이다.

첫 앱은 제품 전체가 아니라 업무 한 조각이어야 한다

첫 프로토타입에서 가장 흔한 실패는 기술이 아니라 욕심이다. 로그인, 결제, 관리자 화면, 알림, 분석 대시보드, 모바일 대응, 다국어, 팀 협업까지 한 번에 넣으려는 순간, 프로토타입은 순식간에 무덤이 된다.

첫 앱은 작아야 한다. 작다고 해서 하찮다는 뜻은 아니다. 오히려 작아야 빨리 검증된다. 좋은 첫 앱은 대체로 세 가지 조건을 만족한다.

• 입력이 단순하다.

• 출력이 눈에 보인다.

• 성공 기준을 한 문장으로 말할 수 있다.

예를 들어 "경쟁사 키워드를 입력하면 최신 기사 몇 개를 모아 한국어로 요약해 주는 브리핑 앱"은 좋은 첫 앱이다. 입력은 키워드다. 출력은 기사 카드와 요약이다. 성공 기준도 명확하다. "매일 아침 10분 걸리던 시장 조사 초안을 1분 안에 뽑는다."

반면 "우리 회사를 위한 올인원 AI 운영 플랫폼"은 첫 앱으로 최악이다. 입력도 많고, 출력도 많고, 누가 성공인지도 모른다.

비개발자에게 특히 중요한 감각은 이것이다. 첫 앱은 기술 데모가 아니라 의사결정 도구여야 한다. 내가 이 앱으로 고객 반응을 보려는지, 내부 팀 시간을 줄이려는지, 투자자에게 방향을 보여 주려는지부터 정해야 한다. Antigravity는 만드는 속도를 올려 주지만, 무엇을 실험할지 대신 정해 주지는 않는다.

10분짜리 첫 프로토타입은 Streamlit이 잘 어울린다

비개발자의 첫 앱은 대개 내부 툴이나 데모에 가깝다. 이때는 Next.js보다 Streamlit이 더 빠르게 감이 온다. 폼 하나, 버튼 하나, 결과 카드 몇 개, 표 하나만 있어도 충분하기 때문이다.

이번 장에서는 예제로 한국어 경쟁사 뉴스 브리핑 앱을 상상해 보자. 사용자는 키워드를 입력한다. 앱은 외부 뉴스 API를 호출한다. 결과를 가져와 한국어로 짧게 정리한다. 그리고 기사 링크, 핵심 포인트, "이번 주에 왜 중요한가" 한 줄 코멘트를 보여 준다.

이 앱이 좋은 이유는 단순하다. PM도 바로 가치 판단을 할 수 있고, 창업자도 고객 인터뷰 없이 먼저 자기 문제를 줄여 볼 수 있다. 또 외부 API 연동, 한국어 프롬프트, 빠른 배포라는 이 장의 핵심 요소가 모두 들어 있다.

처음 의뢰는 이렇게 주면 좋다.

한국어 경쟁사 뉴스 브리핑 앱의 첫 버전을 만들어 주세요.
대상 사용자는 1인 창업자와 PM입니다.
기술 스택은 Python + Streamlit으로 해 주세요.
사용자는 키워드를 입력하고, 앱은 외부 뉴스 API에서 최근 기사를 가져와 카드 형태로 보여 주세요.
각 카드에는 제목, 출처, 링크, 한국어 3줄 요약, 제품/시장 관점의 시사점 1줄을 포함해 주세요.
첫 버전에서는 로그인, DB 저장, 관리자 기능은 넣지 마세요.
API 키는 환경 변수로만 읽고, .env.example 파일을 만들어 주세요.
개발 서버를 실행하고 브라우저에서 정상 동작을 검증해 주세요.
결과물로 Task List, Implementation Plan, Code Diff, 스크린샷을 남겨 주세요.

이 프롬프트의 좋은 점은 화려하지 않다는 데 있다. 무엇을 만들지, 무엇을 제외할지, 어떻게 검증할지를 다 적었다. 첫 앱일수록 "더 많은 기능"보다 "더 적은 오해"가 중요하다.

한국어 프롬프트는 번역문이 아니라 운영 문서다

많은 사람이 한국어 프롬프트를 쓸 때 "그냥 한국어로 설명하면 되겠지"라고 생각한다. 어느 정도는 맞다. 하지만 좋은 결과를 원하면, 한국어 프롬프트도 문서처럼 구조화해야 한다. 지시를 앞에 두고, 맥락을 분리하고, 원하는 결과 형식과 제약을 분명히 쓰는 방식이 훨씬 안정적이다.³

여기에 한국 사용자 맥락까지 더하면 결과 품질이 확 달라진다. 한국어 앱은 단순히 문장만 한국어면 끝나지 않는다. 존댓말/반말, 날짜 표기, 원화 단위, 사업자 문맥, 지역 맥락 같은 요소가 실제 신뢰감에 큰 영향을 준다.⁴

예를 들어 이런 식의 문장은 애매하다.

예쁜 한국어 앱으로 만들어 줘.

이 문장은 사람에게도 모호하다. 에이전트에게는 더 모호하다. 반면 이렇게 바꾸면 훨씬 좋아진다.

앱의 모든 UI 문구는 자연스러운 한국어 존댓말로 작성해 주세요.
날짜는 YYYY.MM.DD 형식을 사용하고, 시간은 KST 기준으로 표시해 주세요.
숫자는 천 단위 쉼표를 넣고, 금액이 있으면 원화 기준으로 보여 주세요.
에러 메시지는 기술 용어보다 사용자가 이해할 수 있는 문장으로 써 주세요.

좋은 한국어 프롬프트에는 보통 다음이 들어간다.

• 대상 사용자: 누구를 위한 화면인지

• 언어 규칙: 존댓말, 용어 수준, 한국식 표기 규칙

• 완료 조건: 무엇이 되면 끝인지

• 제외 범위: 이번 버전에서 하지 않을 일

이 네 가지가 없으면, 앱은 대개 "뭔가 많이 했지만 딱히 쓸모 없는 상태"가 되기 쉽다.

한국어 프롬프트에서 자주 망하는 세 문장

실전에서 특히 자주 보이는 실패 문장이 있다.

첫째는 "깔끔하게 만들어 줘"다. 깔끔함은 감상이고, 구현 단위가 아니다. 대신 "상단에 입력창, 아래에 결과 카드 5개, 모바일에서는 세로 1열 정렬"처럼 관찰 가능한 형태로 바꿔야 한다.

둘째는 "AI스럽게 만들어 줘"다. 이건 거의 주문이 아니라 기도에 가깝다. 어떤 모델을 어디에 쓰는지, 요약이 필요한지, 분류가 필요한지, 추천이 필요한지를 나눠서 써야 한다.

셋째는 "일단 다 넣어 줘"다. 첫 앱에서 이 문장을 쓰는 순간, 에이전트는 열심히 일하지만 제품은 흐려진다. PM이 요구사항을 쓰듯, 첫 버전의 완료 기준을 좁혀야 한다.

짧게 정리하면 이렇다. 좋은 프롬프트는 친절한 설명문이 아니라 작은 명세서다.

외부 API 연동은 '붙여 줘'가 아니라 '계약부터 정하자'로 시작한다

비개발자가 제일 흥분하는 순간은 외부 API를 붙일 때다. "오, 이제 진짜 서비스 같아지네?" 맞다. 하지만 그때부터는 재미와 함께 책임도 들어온다.

외부 API 연동에서 가장 좋은 습관은, 구현 전에 통합 메모를 먼저 시키는 것이다. 바로 코드를 만들게 하지 말고, 먼저 다음 질문에 답하게 해야 한다.

• 어떤 엔드포인트를 쓸 것인가

• 인증 방식은 무엇인가

• 무료 한도와 과금 기준은 무엇인가

• 실패하면 어떤 에러가 오는가

• 응답 JSON에서 실제로 필요한 필드는 무엇인가

이 단계를 먼저 거치면, 에이전트가 문서를 헤매는 시간을 크게 줄일 수 있다. 특히 에이전트가 다루기 쉬운 API는 공통점이 있다. 에러가 구조화돼 있고, 가능한 대안을 알려 주고, 모델이나 엔드포인트 이름이 틀렸을 때 스스로 수정할 힌트를 준다. 이런 API는 에이전트가 사람 도움 없이도 더 빨리 복구할 수 있다.⁵

그래서 두 번째 프롬프트는 이런 식이 좋다.

이 앱에 사용할 뉴스 API를 통합하기 전에 먼저 Integration Memo를 작성해 주세요.
포함 내용은 다음과 같습니다.\

1. 사용할 엔드포인트\

2. 인증 방식과 필요한 환경 변수 이름\

3. 무료 요금제 한도 또는 호출 제한\

4. 성공 응답 예시와 우리가 실제로 사용할 필드\

5. 실패 응답 예시와 사용자에게 보여 줄 fallback 메시지\

6. 개발 중에는 mock mode로도 실행 가능하게 할 방법

이렇게 하면 사람도 API를 이해하고, 에이전트도 더 안정적으로 일한다. 특히 비개발자는 이 단계를 건너뛰면 안 된다. 나중에 "왜 갑자기 안 되지?"가 아니라, 처음부터 "언제, 왜, 얼마나, 어떻게 실패할 수 있는지"를 알아야 하기 때문이다.

API 키는 코드가 아니라 운영 문제다

여기서 꼭 짚고 넘어갈 것이 있다. API 키는 기술 세부사항이 아니라 운영 책임이다. 비개발자일수록 오히려 더 조심해야 한다.

실전에서는 다음 원칙만 지켜도 절반은 안전하다.

• 실제 운영 키를 채팅창에 그대로 붙여 넣지 않는다.

• .env.example만 만들고 실제 값은 로컬 또는 배포 환경 변수로 넣는다.

• 첫 버전에서는 반드시 테스트 키나 샌드박스 키를 쓴다.

• 사용량 제한이 있다면 일일 상한을 미리 확인한다.

에이전트에게도 이 원칙을 분명히 적어 줘야 한다.

실제 비밀값은 코드에 하드코딩하지 말고 환경 변수로만 읽어 주세요.
.env.example에는 키 이름만 남기고, 테스트 키 기준으로 동작을 설명해 주세요.
API 호출 실패 시 앱이 죽지 말고, 사용자에게 이해 가능한 안내 문구를 보여 주세요.

이건 별것 아닌 문장 같지만, 프로토타입이 나중에 팀 자산으로 남을지, 일회용 해킹으로 끝날지를 가르는 차이다.

Streamlit과 Next.js는 속도가 아니라 목적이 다르다

처음 앱을 만들 때 사람들은 자꾸 "뭐가 더 좋아요?"라고 묻는다. 하지만 더 정확한 질문은 "무엇을 검증하려고 하나요?"다.

비개발자의 첫 앱이라면 기본값은 Streamlit 쪽이 안전하다. 하루 안에 가설 검증이 가능하고, 디자인보다 흐름 검증에 집중할 수 있기 때문이다. 반대로 이미 외부 사용자에게 보여 줄 링크가 필요하고, 랜딩 페이지 느낌이나 모바일 반응형 완성도가 중요하다면 Next.js가 낫다.

다만 여기서 꼭 알아야 할 사실이 있다. Antigravity는 로컬에서 빠르게 프로토타입을 만드는 데 매우 강하지만, 공개 배포는 별개의 단계다. 실제로 사람에게 링크를 뿌리려면 GitHub, Vercel, Firebase, Cloud Run 같은 외부 플랫폼과 비밀값 관리까지 따라온다.⁶ 즉, "앱을 만들었다"와 "서비스를 운영할 수 있다"는 같은 말이 아니다.

배포를 맡길 때 사람이 꼭 쥐고 있어야 할 7개의 손잡이

코드를 안 써도 배포를 완전히 눈 감고 맡기면 안 된다. 배포는 기술 작업이면서 동시에 제품 결정이기 때문이다. 최소한 아래 일곱 가지는 사람이 쥐고 있어야 한다.

• 누가 쓸 링크인가: 내부 팀 전용인지, 고객에게 보낼 공개 링크인지 먼저 정한다.

• 어디에 올릴 것인가: Streamlit Cloud, Vercel, Cloud Run 중 무엇이 목적에 맞는지 고른다.

• 비밀값은 어디서 관리할 것인가: 환경 변수 이름과 주입 위치를 분명히 한다.

• 실패하면 무엇을 보여 줄 것인가: API 오류, 빈 결과, 로딩 지연에 대한 화면을 정한다.

• 얼마까지 쓸 것인가: API 호출량, 호스팅 과금, 모델 사용량 상한을 확인한다.

• 무엇을 로그로 남길 것인가: 최소한 배포 버전, 호출 실패, 주요 사용자 액션은 보이게 한다.

• 문제 생기면 어떻게 되돌릴 것인가: 이전 버전 복구 방법이나 환경 변수 롤백 절차를 남긴다.

이 일곱 가지를 안 정하고 배포하면, 앱은 떠도 서비스는 안 선다.

Antigravity로 배포까지 갈 때의 실제 흐름

배포가 처음인 사람은 자꾸 마지막부터 보려 한다. "그래서 링크는 어디서 나오죠?" 하지만 Antigravity로 갈 때 더 좋은 순서는 늘 같다.

먼저 Planning 모드로 시작한다. 구현보다 계획을 먼저 읽는다. 그다음 에이전트가 앱을 만들게 한다. 로컬에서 실행한다. 브라우저로 직접 검증한다. 마지막에 배포 스크립트나 설정 파일을 만들고, 배포 후 스모크 테스트를 한 번 더 돌린다.

이 순서가 좋은 이유는 간단하다. 로컬에서 안 되는 앱은 인터넷에 올려도 안 된다.

Antigravity의 배포형 워크플로우는 이 점에서 꽤 실용적이다. 공식 Codelab에서도 계획 수립, 인프라 스크립트 생성, 앱 코드 생성, 배포, 그리고 결과 검증까지를 Artifacts와 Walkthrough 형태로 이어 간다.⁷ 즉, "배포했다"는 말만 듣는 것이 아니라, 무엇을 만들었고 무엇을 확인했는지까지 같이 볼 수 있다.

예를 들어 Cloud Run으로 올릴 생각이라면 이런 프롬프트가 좋다.

이 Streamlit 앱을 Google Cloud Run에 배포할 수 있게 준비해 주세요.
필요한 파일과 설정을 생성하고, 환경 변수 목록을 정리해 주세요.
배포 전 체크리스트와 배포 후 스모크 테스트 절차를 문서로 남겨 주세요.
실제 비밀값은 넣지 말고 placeholder만 사용해 주세요.

Next.js라면 Vercel 기준으로 비슷하게 요청하면 된다. 중요한 것은 플랫폼 이름보다도, 배포 문서와 검증 절차를 함께 남기게 하는 것이다.

최소한의 기술 부채만 남기려면, 첫 버전에서 네 가지만 남겨라

프로토타입은 어차피 빨리 만드는 것이니 엉망이어도 된다고 생각하기 쉽다. 하지만 정말 좋은 프로토타입은 생각보다 단정하다. 거창한 아키텍처는 없어도, 다음 사람이 이어받을 발판은 남겨 둔다.

첫 버전에서 꼭 남겨야 할 것은 네 가지면 충분하다.

첫째, README.md다. 실행 방법, 필요한 환경 변수, 앱 목적을 한 페이지로 정리한다.

둘째, .env.example이다. 실제 값은 없더라도 어떤 키가 필요한지는 보여 줘야 한다.

셋째, mock mode다. 외부 API가 죽거나 키가 없을 때도 기본 데모가 돌아가게 해 두면, 제품 검증이 API 상태에 종속되지 않는다.

넷째, 브라우저 기준 검증 기록이다. 스크린샷 한 장, 혹은 "어떤 입력으로 어떤 결과를 확인했는지" 정도만 남아도 훨씬 낫다.

여기까지 남겨 두면, 첫 앱은 장난감이 아니라 다음 반복의 기반이 된다.

비개발자의 첫 앱에서 가장 중요한 것은 '통제 가능한 단순함'이다

결국 이 장의 핵심은 하나다. 코드를 안 써도 제품 책임은 사라지지 않는다.

비개발자와 PM이 Antigravity로 앱을 만드는 시대가 왔다고 해서, 이제 아무 생각 없이 "만들어 줘"만 외치면 된다는 뜻은 아니다. 오히려 반대다. 직접 구현을 덜 하는 만큼, 더 선명하게 정의하고 더 집요하게 검증해야 한다.

무엇을 만들지.

누가 쓸지.

어디까지가 첫 버전인지.

어떤 API를 믿을지.

실패하면 어떻게 보일지.

어디에 배포할지.

이 질문에 답할 수 있다면, 비개발자도 충분히 첫 앱을 만들 수 있다. 그리고 그 앱은 단순한 "바이브 코딩 결과물"이 아니라, 다음 결정을 끌어내는 제품 실험이 된다.

Agent-First 시대에 중요한 사람은 코드를 가장 빨리 치는 사람이 아니다. 가장 좋은 질문을 던지고, 가장 위험한 범위를 잘라 내고, 가장 믿을 수 있는 검증 기준을 세우는 사람이다. 비개발자의 첫 앱은 바로 그 감각을 가장 빨리 가르쳐 주는 훈련장이다.

다음 장에서는 이제 한 걸음 물러나, Antigravity와 Cursor, Claude Code를 나란히 놓고 비교해 본다. 누가 더 똑똑한가보다, 누가 어떤 철학으로 일을 시키게 만드는가가 더 중요해지는 구간이다.

참고

¹Google Antigravity

²Google Antigravity 시작하기 | Google Codelabs

³OpenAI API를 활용한 프롬프트 엔지니어링 모범 사례

⁴How to Ground a Korean AI Agent in Real Demographics with Synthetic Personas

⁵에이전트 우선 API 설계: AI Agent가 실제로 이해할 수 있는 API를 구축하는 방법

⁶Build Quick Prototypes in Google Antigravity with Gemini 3 Pro

⁷Antigravity로 Google Cloud에 빌드 및 배포