_Kulsum Shannan 작성

_공개 사항: 저는 아래에서 설명하는 보안 테스트에 사용된 도구인 Perfai Security에서 인턴으로 근무하고 있습니다. 하지만 다른 점에 대해서도 솔직하게 말씀드리고 싶습니다. GardenOS는 Perfai를 테스트하기 위해 만들어진 것이 아닙니다. 저는 실제로 이 앱이 존재하기를 원했기 때문에 만들었습니다. 보안 테스트는 그 이후의 과정이었는데, 제품이 안전하기를 바랄 만큼 이 제품에 애착을 가졌기 때문입니다.

이것을 만든 이유
저는 가끔씩 정원을 가꾸는데, 매년 무엇을 심었는지, 언제 물을 주었는지, 그리고 계절이 바뀔 때 실제로 무엇이 효과가 있었는지 파악하지 못하고 놓치곤 합니다. 메모는 공책, 휴대폰 사진, 혹은 아예 어디에도 남지 않은 채 흩어져 버리고, 다음 해 봄이 되면 대부분의 내용을 잊어버리게 됩니다.

저는 정원의 역사가 매년 봄마다 초기화되는 대신 계속 유지되는 단 한 곳을 원했습니다. 즉, 모든 식물의 관리 이력, 저널(journal) 기록, 그리고 수확물이 연속적인 기록으로 보관되는 곳 말입니다. 또한 가족이나 도우미가 누군가 작업을 잘못 기록하거나 제가 한 시즌 동안 공들여 만든 식물 기록을 삭제할 위험 없이 정원을 확인할 수 있는 방법도 원했습니다. 그것이 GardenOS가 되었습니다. GardenOS는 Owner(소유자)가 실제 권한을 갖고, Admin(관리자)은 완전한 접근 제어 없이 일상적인 관리를 할 수 있으며, Gardener(정원사)는 관리 내용을 기록하고 저널을 추가할 수 있고, Viewer(조회자)는 데이터에 대한 위험 없이 가시성을 확보할 수 있는 역할 기반(role-based) 정원 플랫폼입니다.

저는 제품, 역할, 페이지, 워크플로우(workflows), 그리고 기술 아키텍처(technical architecture)를 아우르는 길고 상세한 하나의 프롬프트(prompt)로 시작하여 Lovable을 통해 이를 구축했습니다. 결과물은 빠르게 완성되었고, 프로세스가 끝날 무렵에는 실제 완성된 제품처럼 보였습니다. 계정 기능이 작동하고, 대시보드(dashboards)는 역할별로 구분되었으며, 데이터가 지속(persisted)되었고, 공개 URL을 통해 라이브 상태가 되었습니다.
보통 '바이브 코딩(vibe-coded)' 앱의 이야기는 여기서 끝납니다. 이 포스트는 왜 그러면 안 되는지에 대한 이야기입니다.

이 포스트의 목적
제가 이 글을 쓰는 이유는 단순히 GardenOS에 대해 이야기하기 위해서가 아닙니다. 현재 Lovable, Bolt, v0와 같은 AI 앱 빌더(AI app builders)를 사용하여 앱을 만드는 많은 사람들이, 제가 거의 그랬던 것과 같은 지점에서 멈추고 있다고 생각하기 때문입니다. 즉, 앱이 실행되고, 외관이 깔끔하며, 데모가 잘 작동하니 작업이 끝났다고 생각하는 지점 말입니다.

그렇지 않습니다. "이 앱이 작동한다"와 "이 앱에 실제 사용자의 데이터를 넣어도 안전하다" 사이의 간극은 이러한 도구들이 여러분을 대신해 확인해 주는 것이 아닙니다. 그 간극이 바로 이 포스트의 실제 주제입니다.

"배포(Published)"가 실제로 증명하는 것
GardenOS를 배포하는 데는 몇 번의 클릭만 필요했습니다. Lovable이 라이브 URL을 생성했고, 그 시점부터 누구나 앱을 방문하고, 가입하고, 사용할 수 있게 되었습니다.

하지만 이 단계가 증명하지 못하는 것들이 있습니다:

• UI에서의 클릭뿐만 아니라, 백엔드(backend)에 대한 직접적인 요청 상황에서도 권한 모델(authorization model)이 유지되는지 여부
• 한 정원의 뷰어(Viewer)가 의도적이든 우발적이든 자신이 속하지 않은 정원의 데이터에 접근할 수 있는 경로가 없는지 여부
• 누군가가 요청(request)을 조작하여 다른 사용자의 비공개 식물 기록이나 일기 항목에 접근할 수 없는지 여부
• 인증 엔드포인트(authentication endpoints)가 남용에 내성이 있는지 여부

이 중 어느 것도 앱을 정상적으로 사용할 때는 나타나지 않습니다. 대시보드는 적절히 분리된 것처럼 보입니다. 역할 제한(role restrictions)도 제대로 작동하는 것처럼 보입니다. 버튼은 숨겨져 있고, 페이지는 있어야 할 곳으로 리다이렉트(redirect)됩니다. 바로 이 점이 이 간극을 위험하게 만듭니다. 대부분의 빌더들이 확인하는 유일한 관점인 프런트엔드(front end)에서는 모든 것이 정상적으로 보이기 때문입니다.

특히 역할 로직(Role logic)은 기만적입니다. Owner, Admin, Gardener, Viewer 권한이 정원(gardens), 식물(plants), 작업(tasks), 저널 항목(journal entries) 전체에 걸쳐 일관되게 작동하도록 만드는 과정은 전체 빌드 과정 중 그 어떤 단일 기능보다 더 많은 반복(iteration)을 필요로 했습니다. UI에서 버튼 하나를 숨기는 것은 사소한 일입니다. 하지만 그 제한 사항이 기초 데이터가 접촉되는 모든 곳, 즉 모든 API 호출(API call)과 모든 데이터베이스 쿼리(database query)에서 실제로 유지되도록 보장하는 것은 완전히 다른 문제이며, 이는 "내가 이것저것 클릭해 볼 때는 앱이 잘 작동한다"라는 말로는 답할 수 없는 문제입니다.

그럼에도 불구하고 내가 테스트를 진행한 이유 (그리고 여러분도 그래야 하는 이유)
GardenOS를 출시 준비가 된 상태로 간주하기 전에, 나는 라이브 배포(live deployment) 버전을 Perfai Security를 통해 실행했습니다. 이 단계가 무엇이었고 무엇이 아니었는지 명확히 하고 싶습니다.

이것은 재빌드(rebuild)가 아니었습니다. 두 번째 개발 단계도 아니었습니다. 이것은 앱이 모바일에서 작동하는지, 환경 변수(environment variables)가 올바르게 구성되었는지, 또는 에러 상태(error states)가 의도한 대로 작동하는지 확인하는 것과 동일한 범주의 출시 점검(release check)이었습니다. Perfai는 배포된 애플리케이션을 직접 테스트했습니다. 즉, 소스 코드나 Lovable이 생성한 인터페이스를 단순히 검토하는 대신, 앱의 접근 가능한 기능, 역할(roles), 경로(routes), 요청(requests)을 매핑한 다음 각각의 취약점을 테스트했습니다.

첫 번째 스캔 결과, 0개의 심각한 문제(critical issues)와 11개의 중간 수준 문제(medium issues)가 발견되었습니다.
심각한 문제가 없었다는 점은 다행입니다. 몇 가지 중간 수준의 문제가 있었지만, 살펴보니 그리 중요해 보이지는 않았습니다. 내 앱이 준비되었음을 확신할 수 있도록 앱을 실행해 보는 것은 좋은 관행이었습니다. Perfai 결과에서 많은 심각한 문제가 나타났던 적도 있었습니다. 디자인은 다듬어져 있었습니다. 대시보드는 역할별로 분리되어 있었습니다. 인증(Authentication)은 존재했고 정상적으로 작동했습니다. 내가 시도한 모든 일반적인 흐름은 예상대로 정확히 작동했습니다. 만약 내가 "사용할 때는 잘 작동한다"라는 단계에서 멈췄다면, 나는 8개의 심각한 권한 부여(authorization) 문제를 가진 앱을 출시했을 것이고, 이를 알 방법도 없었을 것입니다.

나는 문제들을 수정하고 스캔을 다시 실행했습니다. 두 번째 패스(pass) 결과는 깨끗하게 나왔습니다.

실질적인 교훈 (The Actual Takeaway)
Lovable은 제가 요청한 것을 정확히 수행했고, 매우 빠르게 해냈습니다. 길고 상세한 제품 사양(product spec)을 작동 가능한 풀스택 (full-stack) 애플리케이션으로 변환하는 능력은 진정으로 인상적이며, 이 능력이 과소평가되어서는 안 된다고 생각합니다. 하지만 제품을 구축하는 것과 출시해도 안전한지 확인하는 것은 별개의 작업이며, 바이브 코딩 (vibe-coding) 도구가 대신 해주는 것은 그중 하나뿐입니다.

계정, 역할 (roles), 권한 (permissions) 또는 타인의 데이터와 관련된 무엇인가를 구축하고 있다면—대부분의 실제 제품이 그러하듯—"배포되었고 작동한다"는 주장과 "이를 실제 사용자에게 전달해도 안전하다"는 주장은 동일하지 않습니다. 데이터가 유출되지 않도록 하고, 한 사용자가 다른 사용자의 기록에 접근하지 못하게 하며, UI에만 존재하는 권한 모델 (authorization model)을 갖지 않도록 보장하는 것은 별개의 단계입니다. 이는 단순히 코드를 읽거나 데모를 클릭해 보는 것이 아니라, 빌드(build) 이후 실제 배포된 환경(live deployment)을 대상으로 이루어져야 합니다.

보안 테스트 (Security testing)는 제품을 구축하는 것을 대체하는 것이 아니며, 제품 구축을 가리게 해서도 안 됩니다. 제품은 여전히 사용할 가치가 있어야 합니다. 하지만 계정, 권한 및 개인 기록을 다루는 것이 합리적으로 '준비되었다'고 불리기 위해서는 반드시 거쳐야 하는 점검 사항 중 하나입니다. 저는 Perfai에서 인턴으로 일하고 있고 제가 가장 잘 아는 도구이기 때문에 Perfai를 사용했지만, 어떤 도구를 사용하든 근본적인 요점은 동일합니다. 작업을 완료했다고 말하기 전에, 권한 모델을 실제로 깨뜨리려고 시도하는 무언가를 앱의 실제 배포 버전(live, deployed version)에 실행해 보십시오.

GardenOS를 체험해 보세요:
앱 자체에 대한 피드백뿐만 아니라, AI 앱 빌더로 만든 무언가를 출시하기 전의 "마지막 단계"에 대해 여러분의 생각이 바뀌었는지에 대한 피드백도 진심으로 환영합니다.