최근 YouTuber 세토 코지(瀬戸弘司) 씨가 X(트위터)에 다음과 같은 글을 올렸습니다.

Codex나 Claude Code를 이용해 앱을 만든다고 해도, 무슨 일이 일어나고 있는지 모른 채 채팅만 하는 것이기 때문에 이것은 앱 개발이라고 할 수 없습니다. 마치 유능한 부하 직원을 거느린 지식 제로의 상사 같아서 답답함을 느낍니다. 역시 공부가 필요합니다. 만들면서 열심히 배워나갈 수밖에 없습니다.

비(非)엔지니어가 AI에게 앱을 만들게 하는 경험을 매우 잘 표현했다고 느꼈습니다.

앱 개발을 하려면 엔지니어로서의 공부는 물론 해야 합니다.

다만, 그것과는 별개로 '상사로서 최소한의 판단'은 가지고 있어야 할 부분입니다.

구체적인 코드 작성 방법이나 기술 스택의 세부 선택에 대한 이야기는 아닙니다.

• 자신이 앞으로 무엇을 만들려고 하는지
• 그것이 무엇에 노출되는지
• 무엇이 일어나면 큰 손해를 볼 수 있는지

이 3가지는 AI 부하 직원에게만 맡길 수 없는 '상사'의 역할입니다.

본문에서는 AI에게 앱을 만들게 하기 전에, '지식 제로의 상사'가 숙지하면 사고를 줄일 수 있는 포인트를 대략적으로 정리합니다.

비엔지니어를 예상 독자로 하므로 다소 엄밀성이 부족한 부분이 있을 수 있지만, 양해 부탁드립니다.

TL;DR

• AI에게 앱을 만들게 하기 전에 '누가 사용할지'는 반드시 스스로 결정해야 합니다. 판단의 90%는 여기서 결정됩니다.
• 실제 API 키, 개인 정보, 기밀 정보는 AI에게 보여주지 마십시오.
• 공개할 경우 보안뿐만 아니라 비용의 무한대(青天井)에도 대비해야 합니다.

이 글을 통해 가져가야 할 것들

• 가장 큰 분기점은 '나만을 위한 것인가 / 타인도 사용하게 할 것인가'
• 자신만을 위한 것이라도 AI에게 넘긴 정보는 더 이상 손안에만 있는 것이 아니라는 전제하에 생각해야 합니다.
• 공개할 경우 보안보다 먼저 비용의 무한대(青天井)에 대비하는 것이 중요합니다.
• 완전 관리형(Full Managed)이며 무료 사용 범위가 넓은 서비스를 선택하는 것만으로도 진입 장벽이 크게 낮아집니다.

가장 큰 분기점: 자신만을 위한 앱인가? 타인에게도 사용할 수 있게 할 것인가?

여기가 가장 중요한 분기점입니다.

• 자신만을 위한 경우: 자신의 PC(와 AI)만으로 완결됩니다. 누구에게도 만지게 하지 않습니다.
• 타인에게도 사용하게 하는 경우: 가족, 친구, 회사 내부, 불특정 다수 등.

이 중 어느 쪽을 선택하느냐에 따라 주의해야 할 내용의 양과 질이 급격히 달라집니다.

자신만을 위한 앱이라면, 솔직히 신경 쓰지 않아도 되는 것들

자신만을 위한 앱(자신의 PC 안에서, 자신만 만지는 앱)이라면, 신경 쓰지 않아도 되는 것이 상당히 많습니다.

• 정교한 인증 메커니즘은 필요하지 않습니다 (이미 자신의 PC에 있다는 점에서 접근 권한이 있음).
• 정교한 에러 처리도 필요하지 않습니다 (스스로 알면 됨).
• 정교한 디자인도 필요하지 않습니다.
• 비밀번호를 코드에 직접 작성하는 것도 용도에 따라서는 괜찮습니다 (후술).

엔지니어의 관점에서는 앱이 다소 조잡하게 만들어져도, 자신만을 위한 것이라면 전혀 문제가 없습니다. 고장 나면 고치면 되고, 데이터가 사라져도 자신이 곤란할 뿐입니다.

다만, 'AI에게 넘겨서는 안 되는 것'만은 별개

여기서 이번에 가장 강조하고 싶은 포인트입니다.

최근 AI가 비약적으로 발전하기 전에는 개발의 경계선이 '로컬(자신의 PC)'과 '클라우드(서버)' 사이에 그어져 왔습니다. 로컬이면 안전하고, 클라우드에 올리면 공개 위험이 있다는 식의 감각입니다.

하지만 AI에게 개발을 맡기는 지금은 이 경계선이 다시 그려진 것처럼 느껴집니다.

AI에게 넘긴 순간, 그것은 더 이상 손안만의 정보가 아닙니다.

Claude Code나 Codex는 코드나 파일 내용을 읽어 외부 추론 서버로 전송합니다. 당신이 '로컬에서 개발하고 있다고 생각하는' 것이라도, AI에게 보여주는 순간 외부에 노출되는 것입니다.

따라서 자신만을 위한 앱이라 하더라도, AI에게 넘겨서는 안 되는 것은 넘기지 않는다는 규칙만은 가지고 있어야 합니다.

구체적으로는,

• 실제 API 키 (OpenAI, Stripe, AWS, SendGrid 등 돈이나 실제 서비스와 연결되는 열쇠)
• 실제 개인 정보 (자신 외의 주소, 전화, 신용카드 번호 등)
• 타인의 비밀번호, 로그인 정보
• 직장의 기밀 정보, 사내 데이터

이런 부분들은 비록 자신의 PC 안에서 작동하는 앱을 만들고 있더라도 AI에게 보여줘서는 안 됩니다.

반면, '로컬 PC에서 작동하는 앱만 가진 계정의 비밀번호'처럼 외부에 유출되어도 본인이 약간 불편해지는 정도는 괜찮습니다. 이것은 코드에 직접 작성하더라도 크게 신경 쓸 필요가 없습니다.

코드 상에 `password =

그것이 유출되었을 때, 나 이외의 누군가가 곤란해지는가, 혹은 돈이 움직이는가

라는 기준으로 판단하는 것만으로도 충분하다고 생각합니다.

그렇다고는 해도, 이러한 감각 자체가 어렵다고 느껴진다면, 일률적으로 하드코딩(Hardcoding)하지 않기로 규칙을 정해두는 편이 안전합니다.

「나만 쓸 생각」이 가장 위험하다

흔히 발생하는 패턴은, 처음에는 자신 전용으로 만들었던 앱이 어느샌가 타인도 사용하게 되는 경우입니다.

• 가족에게 살짝 보여줬더니 쓰고 싶다고 했다
• 친구에게 DM으로 「URL 보낼게」라고 말해버렸다
• 완성도가 높아서 Twitter(X)에 소개했다

이렇게 되었을 때, 자신 전용을 전제로 만든 앱은 타인이 사용하는 것을 전제로 한 최소한의 대비가 되어 있지 않습니다.

타인의 데이터가 그대로 노출되거나, 인증(Authentication)에 구멍이 뚫리는 일이 흔히 발생합니다.

「타인에게 보여준다/사용하게 한다」의 선을 넘는 순간, 그것은 별개의 앱이라고 생각하는 것이 좋습니다. 처음부터 「이것은 나중에 공개할지도 모른다」라고 결정하고 만들거나, 공개하기 직전에 다시 만들 정도의 각오가 필요합니다.

「URL을 알려주지 않았다 = 공개하지 않았다」도 통하지 않는다

또 다른 비슷한 오해가 있습니다.

「나만 쓸 용도지만, 외부에서도 쓰고 싶어서 웹(Web)에 올렸다. URL은 아무에게도 알려주지 않았으니 실질적으로는 나만의 전용이다」라는 케이스입니다.

이는 상당히 위험한 발상으로, 「URL을 아무에게도 알려주지 않았다 = 공개되지 않았다」는 성립하지 않습니다.

예를 들어, 독자적인 도메인을 취득하고 HTTPS 인증서를 발급하면, 그 시점에서 도메인 이름은 CT(Certificate Transparency) 로그라는, 누구나 열람할 수 있는 공개 로그에 기록됩니다.

이 로그를 상시 모니터링하는 공격자는 실제로 존재하며, 새로 나타난 도메인에 대해 차례차례 접속을 시도해 옵니다.

즉, 웹에 올린 순간 공격자에게는 이미 발각되었다고 생각하는 편이 좋습니다.

「타인에게 전달할 의도가 없다 = 나만의 전용」과 「물리적으로 타인이 접할 수 없다 = 나만의 전용」은 별개의 문제입니다.

웹에 올린 시점에서, 그것은 이미 "타인도 사용할 수 있는" 그룹에 속해 있다고 생각해야 합니다.

나만 쓸 생각이라도 웹을 통해 사용하고 싶은 케이스라면,

• 최소한 로그인 기능(나만 들어올 수 있는 구조)을 넣는다
• 혹은, 나만 액세스할 수 있는 경로를 마련한다 (VPN이나 Cloudflare Access, Tailscale 등)

둘 중 하나는 반드시 필요합니다. 「URL을 말하지 않을 뿐」으로는 방어가 되지 않습니다.

타인이 사용하게 할 경우 (범위와 형태)

타인이 사용하게 하겠다고 결정했을 경우, 조금 더 세부적인 분류가 있습니다.

어디까지 넓게 배포할 것인가

• 지인만 (가족, 친구, 사내 등)
• 불특정 다수 (누구나 접속할 수 있는 URL)

지인뿐이라면 어느 정도 느슨함은 허용됩니다.
예를 들어 비밀번호로 액세스를 제한하거나, 초대제로 운영하거나, 로그인 기능을 간소하게 유지하는 것이 현실적입니다.

불특정 다수가 되면 이야기가 완전히 달라집니다.
누가 액세스할지 알 수 없으므로, 악의를 가진 누군가가 접속할 것을 전제로 만들어야 합니다.
여기서부터 이른바 「보안(Security)」과 「비용(Cost)」 리스크가 본격적으로 발생합니다.
※ 단, 지인이라 하더라도 타인의 개인정보, 사진, 업무 정보, 돈과 관련된 정보를 맡게 된다면 불특정 다수 대상과 유사한 신중함으로 생각하는 것이 좋습니다.

웹 앱(Web App)인가, 네이티브 앱(Native App, 스마트폰 앱)인가

비엔지니어(Non-engineer) 분들이 자주 묻는 질문입니다.
결론부터 말씀드리면, 고민된다면 웹 앱으로 해도 괜찮다고 생각합니다.
이유는 단순합니다. 네이티브 앱(iPhone이나 Android용 앱)은 타인에게 배포하기 위한 허들이 압도적으로 높기 때문입니다.

• App Store 심사 (리젝트(Reject)를 극복해야 함)
• Apple Developer Program 연회비 (연간 99달러)
• Android 측도 최초 등록비가 있음
• 업데이트를 배포할 때마다 심사가 있음

반면, 웹 앱은,

• URL을 보내는 것만으로 사용하게 할 수 있음
• 업데이트도 이쪽에서 수행하면 상대방은 아무것도 할 필요가 없음
• 심사가 없음

「네이티브 앱 같은 사용감을 원한다」는 경우에는 PWA(Progressive Web App)라는, 홈 화면에 추가할 수 있는 웹 앱 형식이 있습니다.
이것으로 「앱 같은 경험」은 상당히 구현할 수 있습니다.
따라서 AI에게 앱을 만들게 할 경우, 당분간은 웹 앱을 전제로 생각하는 것을 추천합니다.

공개한다면 맞닥뜨리게 될 2가지 리스크

불특정 다수에게 공개할 때 맞닥뜨리는 대표적인 리스크는 두 가지입니다.

1. 보안 리스크 (Security Risk): 정보 유출

이는 흔히 말하는 이야기입니다.

• 사용자의 개인정보가 유출됨
• 타인의 데이터가 다른 사람에게 보임
• 로그인이 뚫림

뉴스가 되는 것은 바로 이런 종류의 리스크입니다.

하지만 초보자 입장에서의 직접적인 실질적 피해라는 측면에서는, 사실 다음의 리스크가 더 크다고 생각합니다.

2. 비용 리스크 (Cost Risk): 청구 금액의 무한 증식

초보자가 AI로 만든 앱을 공개했을 때 실제로 뼈아픈 경험을 하기 쉬운 쪽은 이쪽입니다.

아니, 엔지니어조차도 이런 종류의 실수를 저지르곤 합니다.

예를 들어,

• AI에게 질문할 수 있는 기능을 넣었더니, 악의적인 사용자가 대량으로 질문을 던져 AI API 청구액이 월 수십만 엔에 달함
• 이미지 생성 기능을 넣었더니, 이미지 생성 API 청구액이 방대해짐
• 서버가 공격을 받아 서버 이용료가 예상의 100배가 됨
• 삭제했을 터인 설정이 삭제되지 않아 계속 과금됨
• 설정 실수로 방대한 처리를 실행하여 이용료가 폭발함

보안 사고는 신용이나 대응 비용으로서 무겁게 다가오지만, 개인 개발 앱의 초기 단계에서 막대한 피해가 발생하는 케이스는 드뭅니다.

반면, 비용 사고는 청구서라는 형태로 출시 직후 바로 눈에 보이는 데미지가 될 수 있습니다. 따라서 공개 전에는 보안만큼이나 비용이 얼마나 들지도 고려해 두어야 합니다.

비엔지니어(Non-engineer)라면, 비용이 무한정 늘어나는 리스크가 훨씬 더 무서운 리스크라고 생각하는 편이 좋습니다.

허들을 낮추는 서비스 선택법

여기까지 읽고 "공개하는 것이 참 힘들 것 같다(귀찮을 것 같다)"라고 느끼셨을지도 모릅니다.

네, 힘들고 귀찮습니다. 현역 엔지니어라도 신경을 많이 쓰는 부분입니다.

하지만 막막하기만 한 것은 아니며, 최근에는 공개할 때 사용하는 서비스를 잘 선정하면 허들을 상당히 낮출 수 있습니다.

선택 기준

서비스를 선택할 때는 다음 세 가지를 만족하는 것을 고릅니다.

• 풀 매니지드 (Full-managed): 서버 관리를 직접 할 필요가 없음. 요금제만 선택하면 됨.
• 넓은 무료 티어 (Free tier): 소규모 개인 개발이라면 무료로 해결될 가능성이 높음.
• 요금 상한 설정 가능: 비용이 무한정 늘어나는 리스크를 미연에 방지할 수 있음.

세 번째가 특히 중요합니다.

초보자의 비용 사고를 막아주는 가장 강력한 무기가 됩니다.

CLI는 AI가 실행해 줍니다

비엔지니어가 가장 헤매기 쉬운 부분이 서비스 설정(CLI, 터미널, 명령어 입력)입니다.

이것은 전부 AI에게 통째로 맡겨도 괜찮습니다.

Claude Code나 Codex는 적절한 서비스에 대해서는 스스로 셋업 명령어를 실행해 줍니다.

"Cloudflare에 배포해 줘"라고 부탁하면, 스스로 터미널을 열어 명령어를 실행합니다.

따라서 서비스를 고를 때도,

"나에게 이해하기 쉬운가"가 아니라,

"AI가 다루기 쉬운가"로 선택하는 것이 정답입니다.

구체적으로는 CLI가 잘 정비되어 있고, 문서가 풍부하며, AI의 학습 데이터에 포함되어 있는 서비스라는 뜻입니다.

추천 후보

다음 서비스들은 위의 기준을 만족하는 서비스들입니다.

• Cloudflare: 웹 앱 호스팅, 데이터베이스, 파일 저장 등을 하나로 해결할 수 있음. 무료 티어가 상당히 넓고 요금 상한을 걸기도 쉬움
• Vercel: 웹 앱 배포의 정석. 처음 사용하기에 매우 편리함
• Supabase: 데이터베이스와 사용자 인증을 통합 제공
• Convex: 데이터베이스와 서버 처리를 통합 관리할 수 있음

어느 것이 "정답"이라기보다는, AI에게 "이 앱을 공개하고 싶어. Cloudflare로 / Vercel로 / Supabase로 구성해 줘"라고 부탁하면 그럴싸하게 작동하는 결과물이 나옵니다.

처음에는 이름을 들어본 적이 있는 것이나, AI가 "이것으로 가시죠"라고 제안하는 것을 채택하는 정도로도 충분합니다.

AWS는?

엔지니어 세계에서는 정석이지만, AWS는 비엔지니어가 처음 접하는 것은 추천하지 않습니다.

강력하고 무엇이든 할 수 있는 반면, 설정 항목이 많고 요금 체계가 복잡하며, 요금 상한을 억제하는 메커니즘도 초보자 친화적이지 않기 때문입니다.

"AWS는 매우 강력하지만, 처음에는 피하는 것이 무난하다"라고만 기억해 두세요.

(GCP도 마찬가지입니다)

요약

"지식 제로의 상사"가 파악해 두어야 할 판단은 다음 표에 집약됩니다.

그리고 형태와 서비스 선택에 대해서는,

• 형태는 고민된다면 Web App (웹 앱). Native (네이티브)는 배포 장벽이 높으므로 우선은 Web (웹)으로
• 서비스는 Full-managed (풀 매니지드) / 무료 티어 (Free tier)가 넓음 / 요금 상한을 설정할 수 있음 을 충족하는 것을 선택
• AWS는 처음에는 피할 것

이것만 기억해 두어도 첫 사고는 상당히 줄일 수 있을 것이라 생각합니다.

그리고 자신 전용이든 공개용이든 공통적으로 가지고 있어야 할 멘탈 모델 (Mental model)은,

AI에게 넘긴 순간, 그것은 더 이상 수중에만 있는 정보가 아니다

이것뿐입니다.

「지식 제로의 상사」이기 때문에, 유능한 AI 부하에게 무엇을 넘기고 무엇을 넘기지 않을지는 스스로 결정할 필요가 있습니다.

그 점만 파악하고 있다면, AI로 앱을 만드는 즐거움을 안심하고 누릴 수 있지 않을까 생각합니다.

※ 뭐, 이 정도까지 할 수 있다면 「지식 제로」가 아니라 훌륭한 상사겠지만요!