사용자가 AI로 만든 앱에 사진을 업로드하게 하려면 (앱이 멈추지 않게)

앱이 단순한 텍스트를 넘어 사용자가 사진을 업로드할 수 있게 되는 순간, 뭔가가 달라집니다. 이미지와 파일 업로드를 추가한다는 건 사용자가 자기 기기에서 사진, 영수증, 문서를 앱으로 보내면 앱이 그걸 저장했다가 나중에 다시 보여준다는 뜻입니다 — 프로필 사진, 영수증, 파손된 택배 사진, PDF 계약서 같은 것들이죠. 이건 겉보기엔 체크박스 하나만 켜면 끝날 것 같은데 실제로는 몇 가지 날카로운 모서리를 감추고 있는 기능 중 하나입니다. 어느 것도 어렵지는 않습니다. 다만 아무도 미리 경고해주지 않는 것들은 대개 출시 3주 후, 그것도 보통 가장 열정적인 사용자로부터 터져 나옵니다.

이 글에서는 누군가 “업로드”를 누를 때 실제로 무슨 일이 일어나는지, 나중에 발목을 잡는 세 가지 실수는 무엇인지, 그리고 그걸 피하기 위해 빌더에게 정확히 무엇을 요청해야 하는지 살펴봅니다.

앱에 사진을 업로드하면 실제로 무슨 일이 일어날까?

사진을 업로드하면 순서대로 네 단계가 일어납니다. 휴대폰이 파일을 앱에 넘기고, 앱은 그걸 (데이터베이스가 아닌) 별도의 파일 스토리지로 보내고, 앱은 그 파일에 대한 링크를 레코드 옆에 저장하고, 나중에 누군가 그 레코드를 볼 때마다 그 링크로 파일을 가져옵니다.

단계별로 풀어보면 이렇습니다.

1. 휴대폰이 앱에 파일을 넘깁니다. 요즘 휴대폰 사진은 흔히 4MB에서 12MB 사이입니다. 결코 작은 용량이 아니죠.
2. 앱은 그 파일을 어딘가에 저장하도록 보냅니다 — 앱의 데이터베이스가 아니라, 파일 전용으로 만들어진 별도의 스토리지 버킷입니다.
3. 앱은 그 파일에 대한 _링크_를 데이터베이스에, 레코드의 나머지 정보 옆에 저장합니다 (이 영수증은 이 지출 항목에 속한다는 식으로요).
4. 나중에 누군가 그 레코드를 볼 때, 앱은 그 링크를 이용해 스토리지에서 파일을 가져와 보여줍니다.

사람들이 흔히 잘못 이해하는 부분이 바로 2단계와 3단계입니다. 다들 사진이 “앱 안에 저장된다”고 생각하죠. 그렇지 않고, 그래서도 안 됩니다. 파일은 스토리지에 살고, 데이터베이스는 그 위치만 기억합니다. 이 구분을 제대로 해두면 그 이후 모든 게 훨씬 쉬워집니다.

업로드한 사진을 데이터베이스에 직접 저장해도 될까?

안 됩니다 — 그리고 이게 가장 흔한 업로드 실수입니다. 구체적으로 지시하지 않으면 AI 빌더가 기본값으로 이렇게 처리해버리는 경우도 있습니다. 10MB짜리 사진을 데이터베이스에 그대로 쑤셔 넣는 건 가구를 지갑 속에 보관하는 것과 비슷합니다. 데이터베이스는 이름, 날짜, 가격 같은 작고 구조화된 데이터를 위해 만들어졌습니다. 거기에 사진을 쏟아부으면 속도가 느려지고, 백업 용량이 부풀어 오르고, 어느 날 예전엔 순식간에 열리던 페이지가 고해상도 이미지 백여 개를 질질 끌고 다니느라 6초씩 걸리게 됩니다.

대신 원하는 방식은 이렇습니다. 파일은 파일 스토리지(빌더에 따라 “스토리지 버킷”이나 “블롭 스토리지”라고 부를 수도 있습니다)로 보내고, 데이터베이스에는 그 링크만 담아둡니다. 이렇게 직접 요청하세요.

“업로드된 이미지는 데이터베이스가 아니라 파일 스토리지에 저장해줘. 레코드에는 파일 URL만 남겨줘.”

사용자가 잘못된 파일 형식이나 지나치게 큰 파일을 업로드하지 못하게 하려면?

허용할 파일 형식, 용량 제한, 그리고 명확한 오류 메시지를 미리 정해서 빌더에게 명시적으로 전달해야 합니다. 이런 규칙이 없으면 앱은 업로드를 아예 멈춰버리게 만드는 파일까지 포함해서 무엇이든 받아들이게 됩니다. 테스트할 땐 멀쩡했던 실제 앱에서 나온 두 가지 사례가 이유를 잘 보여줍니다.

한 케이터링 사업을 운영하는 여성분이 고객이 마음에 든 케이크 사진을 업로드할 수 있는 앱을 만들었습니다. 잘 작동했는데, 어느 고객이 전문 카메라로 찍은 47MB짜리 사진을 그대로 업로드하자 문제가 생겼습니다. 업로드가 멈춰버렸고, 고객은 포기했고, 그분은 “앱이 고장 났다”는 얘기를 전해 들었습니다. 사실 고장 난 게 아니었어요 — 단지 용량 제한을 설정해두지 않아서, 거대한 파일을 삼키려고 하염없이 붙들고 있었던 겁니다.

또 다른 사례: 한 프리랜서가 고객들이 “자신의 로고”를 업로드하는 클라이언트 포털을 만들었습니다. 한 고객은 .zip 파일을 올렸고, 다른 고객은 90페이지짜리 PDF를 올렸습니다. 앱은 그걸 전부 받아들였습니다 — 로고가 어떤 형태여야 하는지 아무도 알려주지 않았으니까요.

다음 세 가지를 미리 정해두세요.

• 어떤 파일 형식을 허용할까? 사진만 받을 건가요? 그렇다면 JPG와 PNG만 허용하고 나머지는 친절한 메시지와 함께 거절하세요.
• 용량은 얼마까지? 사진이라면 5MB에서 10MB 정도가 적당합니다. 실제 휴대폰 사진을 담을 만큼 넉넉하면서도, 카메라 원본 파일 통째 업로드는 막을 만큼 작은 값입니다.
• 잘못됐을 땐 어떻게 할까? 앱은 그냥 멈춰버리는 게 아니라 친절하게 알려줘야 합니다 — “10MB 이하의 JPG나 PNG 파일을 업로드해 주세요”처럼요.

빌더에게 이렇게 전달하세요.

“10MB 이하의 JPG와 PNG 이미지만 허용해줘. 다른 형식이거나 너무 크면, 조용히 실패하는 대신 명확한 메시지를 보여줘.”

사진이 많아지면 왜 앱이 느려질까?

보는 사람마다 매번 축소된 사본이 아니라 원본 파일 전체를 다운로드하기 때문입니다 — 그것도 각자의 휴대폰으로, 각자의 데이터 요금제로, 누군가 그 레코드를 열 때마다 매번요. 누군가 선명한 8MB짜리 사진을 하나 올렸다면 그 자체로는 문제없이 잘 작동합니다. 하지만 이걸 스무 장짜리 갤러리로 곱하면, 빠릿빠릿하던 앱이 진흙탕을 헤쳐나가는 것처럼 느껴지게 됩니다.

해결책에는 이름이 있고, 빌더가 알아들을 만한 용어이니 알아둘 가치가 있습니다. 바로 썸네일, 즉 크기를 줄인 버전입니다. 아이디어는 이렇습니다. 원본은 그대로 보관하되 웹에 적합한 작은 사본도 함께 만들고, 목록이나 미리보기에서는 그 작은 사본을 보여줍니다. 원본 전체는 누군가 실제로 크게 보고 싶어할 때만 불러옵니다.

“이미지가 업로드되면 미리보기와 목록용으로 크기를 줄인 버전도 함께 만들어줘. 기본적으로는 작은 버전을 보여주고, 누군가 클릭해서 볼 때만 원본 이미지를 불러와줘.”

이게 어떻게 구현되는지 이해할 필요는 없습니다. 다만 이런 기능이 존재한다는 것만 알아두면, 앱이 느려지고 나서가 아니라 그 전에 미리 요청할 수 있습니다.

조용하지만 챙겨둘 만한 몇 가지

다음 세 가지는 건너뛴다고 해서 앱이 당장 망가지지는 않지만, 나중에 뜯어고치는 것보다 지금 정해두는 게 훨씬 저렴합니다 — 파일을 누가 볼 수 있는지, 레코드가 삭제될 때 파일은 어떻게 되는지, 그리고 휴대폰에서도 업로드가 되는지.

• 누가 파일을 볼 수 있을까? 프로필 사진이라면 누구든 봐도 괜찮습니다. 하지만 스캔한 신분증이나 서명된 계약서라면 얘기가 다릅니다. 파일이 비공개여야 한다면, 링크가 누구나 열 수 있는 공개 URL이 아니라 로그인을 요구해야 한다고 빌더에게 알려주세요. 민감한 정보라면 제가 가장 강하게 밀어붙일 부분이 바로 이 지점입니다.
• 레코드가 삭제되면 어떻게 될까? 누군가 지출 항목을 삭제하면 영수증 사진도 함께 정리돼야 할까요? 그렇지 않으면 저장 비용은 계속 나가는데 존재조차 잊어버린 고아 파일이 서서히 쌓이게 됩니다.
• 휴대폰에서도 작동할까? 업로드는 대부분 휴대폰에서 일어나고, 휴대폰은 “지금 바로 사진 찍기”와 “라이브러리에서 선택하기” 두 가지를 모두 제공합니다. 파일을 그저 드래그해서 넣기만 하는 노트북이 아니라, 실제 휴대폰에서 두 방식 모두 테스트해보세요.

낯선 사람이 쓰듯 테스트하기

실제 사용자가 실수로 저지를 법한 방식으로 일부러 앱을 망가뜨려 보세요 — 평범한 사진, 지나치게 큰 파일, 잘못된 파일 형식, 실시간 휴대폰 카메라 업로드, 그리고 삭제까지 — 다 확인하기 전엔 완성됐다고 하지 마세요.

• 평범한 휴대폰 사진을 업로드해보세요. 잘 나타나나요? 미리보기는 빠른가요?
• 아주 큰 파일을 업로드해보세요. 앱이 명확한 메시지로 막아주나요, 아니면 그냥 멈춰버리나요?
• 잘못된 형식을 업로드해보세요 — 사진이 필요한 곳에 PDF를 넣어보는 식으로요. 규칙을 설명해주나요?
• 휴대폰으로 앱을 열고 카메라에서 바로 업로드해보세요.
• 레코드를 삭제하고, 그에 딸린 파일이 정해둔 방식대로 처리되는지 확인하세요.

이 다섯 가지가 모두 제대로 작동한다면, 대부분의 사람을 붙잡는 모서리는 다 넘어선 셈입니다.

업로드는 “데모에서는 잘 되는 것”과 “12MB짜리 고양이 사진을 든 채 기차 안에 있는 낯선 사람에게도 잘 되는 것” 사이의 간극이 정확히 위에서 다룬 결정들로 채워지는 기능 중 하나입니다. 어느 것도 어렵지 않습니다. 다만 건너뛰기 쉬울 뿐이죠 — 그리고 나중에 고치는 것보다 지금 요청하는 게 훨씬 쉽습니다.

업로드 기능 추가를 큰 기술적 도전처럼 느껴져서 미뤄왔다면, 그렇지 않습니다. 빌더를 열고, 용량 제한과 썸네일이 딸린 이미지 스토리지를 요청한 뒤 무엇이 나오는지 지켜보세요. 그다음 휴대폰으로 직접 망가뜨려 보세요 — 그게 진짜 테스트이고, 5분이면 충분합니다.