[바이브코딩 기초 4] 앱 만들기

앱을 만들어서 서비스를 시작하려고 합니다. 그런데 손님은 어디서 우리 서비스를 처음 만날까요? 상품이나 콘텐츠를 검색해서 들어오게 하려면, 검색 결과에서 열어볼 웹페이지가 필요합니다. 앱을 만들더라도 웹을 함께 만들 일이 있는 거예요.

그래서 저는 웹을 먼저 만들고, 앱에서도 그 화면을 함께 쓰는 방식을 권합니다. 어차피 만들 웹이라면 상품 목록·예약·공지 같은 화면을 앱용으로 다시 만들 필요는 없으니까요. 앱에는 카메라나 알림처럼 필요한 기능을 더하면 됩니다.

이번 글에서는 이 웹을 웹뷰로 보여주는 앱을 만들어볼게요.

검색으로 손님을 받으려면 웹도 필요합니다

평소 쓰는 앱을 떠올려보세요. 당근도 웹버전이 있고, 쿠팡도 브라우저에서 이용할 수 있습니다. 앱으로 유명한 서비스도 찾아보면 웹을 함께 운영하는 경우가 많아요. 이런 테크기업들도 앱과 웹을 둘 다 만드는 거죠. 검색으로 찾아오거나 공유 링크를 누른 사람에게도 서비스 내용을 보여줄 수 있으니까요.

우리가 만든 서비스에서 캠핑장을 예약할 수 있다고 해볼게요. 손님이 검색창에 캠핑장 이름을 입력했을 때, 해당 캠핑장의 사진과 시설 안내를 보고 예약할 수 있는 페이지가 있으면 좋겠죠.

앱만 만들었다면 그 내용을 보여줄 웹페이지를 따로 준비해야 합니다. 앱 소개나 설치 링크를 보여주는 것과, 손님이 찾던 캠핑장의 정보를 바로 보여주는 것은 다르니까요. 상품과 콘텐츠를 검색해서 들어오는 서비스를 생각한다면 “앱만 만들 건데요”로 끝내기가 어렵습니다.

공유할 때도 마찬가지입니다. 손님이 앱에서 캠핑장을 보고 친구에게 링크를 보냈는데, 친구는 앱이 없습니다. 웹페이지가 있으면 친구도 사진과 가격부터 살펴볼 수 있어요. 먼저 써보고 계속 이용하고 싶을 때 앱을 설치하는 거죠.

물론 페이지를 만들기만 하면 검색 결과에 바로 나오는 것은 아닙니다. 검색 엔진이 읽을 수 있도록 공개 페이지를 준비하는 작업도 필요해요. 여기서 말하고 싶은 것은 검색과 공유에 쓸 웹을 만들 거라면, 그 화면을 앱에서도 함께 쓸 수 있다는 점입니다.

웹뷰는 앱 안에서 웹을 보여주는 브라우저예요

Chrome이나 Safari처럼 인터넷 주소를 열어주는 프로그램을 브라우저라고 합니다. 브라우저에서 접속해 예약이나 상품 구매 같은 기능을 사용하는 서비스를 웹앱이라고 해요.

웹뷰는 앱 안에 넣는 브라우저라고 생각하면 쉽습니다. 사용자가 우리 앱 아이콘을 누르면, 앱 안의 웹뷰가 우리가 만든 웹 주소를 열어주는 거예요. 화면을 보여주는 역할만 보면 앱이 우리 서비스 전용 브라우저인 셈입니다.

손님은 Safari에서 캠핑장을 예약할 수도 있고, 설치한 앱에서 예약할 수도 있습니다. 두 곳에서 같은 웹 화면을 쓰고, 같은 서버에 예약을 저장해요.

앱 화면을 네이티브로 직접 만들고 웹 화면도 따로 만들면, 같은 예약 항목을 바꿀 때 양쪽 코드를 각각 고쳐야 합니다. 리액트 네이티브 앱 안에서 기존 웹을 보여주면 공통 웹 코드 한곳에서 수정할 수 있어요. 웹과 앱에서 같은 기능을 제공할 때, 화면을 함께 쓰는 쪽이 관리하기 편한 이유입니다.

AI에게 개발을 맡길 때도 이 차이가 있습니다. 같은 기능을 두 벌 만들면 대표님도 두 결과를 살펴봐야 하니까요. 공통 화면을 쓰면 같은 내용을 두 번 요청하고 맞추는 일을 줄일 수 있어요.

2편 웹 서비스 만들기에서 만든 관리자페이지도 그대로 씁니다. 대표님이 상품이나 공지를 한 번 등록하면 웹과 앱에서 같은 내용을 보여줍니다.

웹으로 만들면 앱보다 별로이지 않을까요?

“그래도 웹으로 만든 건 좀 별로이지 않을까요?”

웹뷰로 앱을 만들자는 이야기에 이런 의문이 들 수도 있습니다.

저는 그럴 때 리액트 네이티브가 처음 나왔을 무렵을 떠올립니다. 리액트 네이티브는 아이폰과 안드로이드 앱을 만들 때 코드를 함께 쓸 수 있게 돕는 도구예요. 지금은 여러 서비스가 이 도구로 앱을 만들지만, 초창기에는 “안드로이드와 iOS를 각각 따로 만들어야 제대로 된 앱이지”라는 이야기를 들었던 기억이 있습니다.

기술은 계속 발전하는데, 사람들의 인식은 그보다 늦게 따라오는 것 같아요. 예전에 부족했던 점을 기억해서, 지금도 그럴 거라고 생각하는 거죠. 웹으로 만든 앱을 보는 시선에도 그런 점이 있지 않을까요?

리액트 네이티브로 만든 앱 안에도 웹뷰를 넣을 수 있습니다. 이 글에서 소개하는 구성도 그렇게 만들 수 있어요. 리액트 네이티브로 앱을 만들고, 그 안의 웹뷰에서 기존 웹 화면을 보여주는 겁니다. React Native WebView 같은 도구가 이 역할을 합니다.

아래 화면은 웹으로 만들었습니다. 사진을 누르면 목록의 작은 사진이 상세 화면으로 이어집니다.

웹뷰를 쓴다고 이런 움직임을 포기할 필요는 없어요. 브라우저에서 쓰던 화면 전환을 앱 안에서도 사용할 수 있습니다.

위 GIF에는 웹의 화면 전환을 만드는 도구인 SSGOI를 사용했습니다. AI에게는 이렇게 요청할 수 있어요.

https://ssgoi.dev/llms.txt 를 읽고 현재 웹 화면에 맞는 전환을 적용해줘. 상품 목록에서 상세로 들어가고 다시 돌아올 때 자연스럽게 이어지면 좋겠어.

카메라·알림·로그인도 연결할 수 있어요

화면을 웹으로 보여주더라도 앱에서 제공하는 기능은 함께 쓸 수 있습니다. 웹 화면의 ‘사진 찍기’를 누르면 앱이 카메라를 열고, 촬영한 사진을 웹 화면에 돌려주는 식이에요.

아이폰이나 안드로이드가 제공하는 카메라·알림 같은 기능을 앱 코드에서 사용하는 것을 네이티브 기능을 쓴다고 표현합니다. 웹 코드가 앱 코드에 이런 기능을 요청하고 결과를 받는 연결을 브릿지라고 불러요.

웹뷰는 상품 목록이나 예약 화면을 보여주고, 앱 코드는 카메라나 알림을 맡습니다. 브릿지로 둘을 연결하면 웹 화면에서도 이 기능을 요청할 수 있어요. 서버와 DB는 기존 웹 서비스의 것을 함께 씁니다.

3편 로그인 붙이기에서 만든 소셜 로그인도 앱에서 이어 쓸 수 있습니다. 사용자가 로그인을 누르고, 계정을 선택한 뒤, 앱으로 돌아와 보던 상품을 계속 보는 흐름까지 연결하는 거예요.

웹에서 직접 못 하는 기능은 앱 쪽에서 구현하고 브릿지로 연결하면 됩니다. 카메라나 로그인이 필요하다는 이유로 상품·예약 화면 전체를 앱용으로 다시 만들 필요는 없어요.

리액트 네이티브 쪽에서 카메라나 알림 기능을 붙이고, 웹뷰와 브릿지로 요청과 결과를 주고받으면 됩니다. 이미 만든 기능을 묶어둔 라이브러리를 가져다 쓸 수도 있고, 필요한 기능을 직접 작성해 연결할 수도 있어요.

만든 웹을 앱으로 연결해볼게요

앞선 글에서 웹 서비스를 만들었다면, 이제 리액트 네이티브로 그 웹을 보여줄 앱을 준비합니다. 앱을 만들기 위한 코드와 설정의 묶음을 앱 프로젝트라고 해요. 앱 이름과 아이콘, 처음 열 웹 주소, 사용할 기기 기능을 여기에 설정합니다.

AI에게는 이렇게 요청할 수 있습니다.

지금 만든 웹 서비스를 아이폰과 안드로이드 앱에서도 쓰고 싶어.
앱을 열면 웹뷰에서 현재 배포한 웹 주소를 보여주게 만들어줘.
기존 상품·예약 화면과 회원 데이터, 로그인 서버를 함께 사용할 거야.

리액트 네이티브로 앱 프로젝트를 만들고,
React Native WebView로 기존 웹 화면을 보여줘.
앱 이름과 아이콘을 설정하는 방법도 알려줘.
사진 촬영, 푸시 알림, 소셜 로그인을 앱 기능과 연결해줘.
로그인을 마치거나 알림을 누르면 해당 웹 화면을 이어서 보여줘.

이 요청에서 중요한 것은 기존 웹 화면을 함께 쓴다는 조건입니다. 화면은 이미 만들었으니, 앱에서 그 화면을 열고 필요한 기능을 연결하는 작업을 추가하는 거예요.

휴대폰에 설치할 앱 파일을 만드는 과정을 빌드라고 합니다. AI에게 “이 앱을 내 아이폰과 안드로이드폰에 설치해서 써보려면 무엇을 준비하면 돼?”라고 이어서 요청할 수 있어요.

설치한 뒤에는 손님처럼 상품을 보고, 로그인하고, 예약해봅니다. 사진 촬영과 알림도 써보고요. 웹에서 만든 서비스에 앱 기능까지 연결한 모습을 실제 휴대폰에서 확인하는 단계입니다.

앱스토어에 올릴 자료를 준비해요

내 휴대폰에서 확인했다면 다른 사람도 설치할 수 있게 공개할 차례입니다. 아이폰 앱은 Apple App Store, 안드로이드 앱은 Google Play 같은 스토어에 등록할 수 있습니다.

스토어에는 앱을 올릴 운영자의 개발자 계정이 필요합니다. 앱 파일과 함께 사용자에게 보여줄 이름·아이콘·설명·화면 캡처를 준비하고, 어떤 개인정보와 기기 기능을 사용하는지도 작성합니다.

스토어는 제출한 앱을 검토합니다. Apple은 단순히 웹사이트를 포장한 수준을 넘어 앱으로서 사용할 만한 기능과 경험을 제공하는지도 봅니다. 웹뷰를 썼다는 이유만으로 통과 여부를 정할 수는 없어요. Apple 앱 심사 기준

등록 순서는 Apple의 앱 등록 안내와 Google Play의 앱 설정 안내에서 확인할 수 있습니다. 사용하는 앱 개발 도구와 맞춰 필요한 준비를 AI에게 정리해달라고 요청하면 됩니다.

웹과 앱을 함께 만들고, 함께 고칩니다

검색으로 처음 찾아온 손님은 웹에서 상품을 보고, 앱을 설치한 손님은 앱에서 같은 서비스를 씁니다. 대표님은 같은 상품·예약 화면을 관리하면서 앱에 필요한 기능만 추가할 수 있어요.

공통 웹 화면을 고친 뒤에는 앱에서도 잘 보이는지 살펴봅니다. 앱에 포함한 코드를 바꿨다면 새 앱 파일을 만들고 스토어 업데이트를 준비하고요.

컴윗에는 이렇게 웹을 함께 쓰면서 필요한 앱 기능을 연결하는 개발 스킬을 내장해두었어요. AI가 이 스킬을 참고해, 만들려는 서비스에 가장 적합한 기술을 선택하고 앱을 구현하도록 돕습니다.