프론트엔드·백엔드·DB 언제 필요할까? 고객관리 앱 3단계로 이해하기

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

고객관리 앱은 개인용 화면과 브라우저 저장소에서 시작해, 공동 사용에는 백엔드·DB를, 직원별 접근 제한에는 로그인·권한 검사를 추가하는 3단계로 이해할 수 있다.

📌 핵심 요점

1. 기술 선택은 사용자의 요구에서 출발한다. 혼자 쓰는지, 여러 직원이 데이터를 공유하는지, 직원마다 접근 범위가 다른지가 필요한 구성을 결정한다.
2. 개인용 앱은 프런트엔드와 브라우저 저장소로 구현할 수 있다. 실습에서는 React로 화면을 만들고 IndexedDB에 데이터를 저장했다. 다만 다른 브라우저와 자동으로 공유되지 않으며, 저장소 삭제에 대비한 백업이 필요하다.
3. 공동 사용에는 중앙 저장소와 요청 처리 구조를 추가한다. Cloudflare D1은 데이터를 저장하고, Workers의 백엔드는 API를 통해 조회·수정 요청과 업무 규칙을 처리한다. 고객 ID는 고객·거래·접촉 기록을 연결한다.
4. 직원별 접근 제한에는 인증과 인가가 필요하다. 인증은 사용자가 누구인지, 인가는 무엇을 할 수 있는지 확인한다. 버튼을 숨기는 것만으로는 부족하며 백엔드에서 실제 권한을 검사해야 한다.
5. AI의 구현 결과는 사람이 검증해야 한다. 수정값의 저장, 다른 브라우저에서의 조회, 미인증 접근 차단, 역할별 권한을 확인하고 배포 후 운영 설정도 점검한다. 이번 앱은 다시 조회하면 최신 데이터가 보이는 범위까지 구현했다.

🧩 배경과 문제 정의

• AI로 고객 관리 앱을 만들더라도 데이터베이스·프레임워크·백엔드를 언제 도입해야 하는지 판단하기는 어렵다. 기술 선택의 기준은 고객 수, 공동 작업 여부, 로그인과 권한 요구다.
• 혼자 사용하는 앱은 엑셀과 브라우저 저장소로도 구현할 수 있지만, 여러 직원이 같은 정보를 수정하려면 공통 저장소와 요청 처리 구조가 필요하다.
• 가상의 고객 관리 데이터를 이용해 개인용 앱, 데이터 공유 앱, 로그인과 역할별 권한을 갖춘 앱으로 확장하면서 프런트엔드·백엔드·데이터베이스의 역할을 구분한다.

🕒 시간순 섹션별 상세정리

1. 기술 도입의 기준은 사용 규모와 업무 요구다

• AI는 PostgreSQL, Supabase, SQLite, Cloudflare D1 등 여러 기술을 추천하지만, 비개발자는 어떤 선택이 필요한지 판단하기 어렵다 [00:54]
• 고객이 몇십 명이고 관리자가 한 명이면 엑셀로도 충분할 수 있다. 고객이 수백 명으로 늘고 여러 직원이 정보를 수정하거나 담당 고객별 접근 제한이 필요해지면 요구되는 기술이 달라진다 [01:29]

2. 엑셀의 고객 ID가 데이터 사이의 관계를 만든다

• 실습 데이터에는 고객 61명, 거래 220건, 접촉 이력 약 150건이 있으며 고객 평가, 등급 기준, 업무 일정과 대시보드도 포함된다 [03:03]
• 고객 목록·거래 현황·접촉 이력에 공통으로 들어 있는 고객 ID를 이용하면 특정 고객의 구매와 연락 기록을 연결할 수 있다. 이 연결 방식은 관계형 데이터베이스 설계에도 활용된다 [04:00]

3. 개인용 앱은 화면과 브라우저 저장소로 구성한다

• 혼자 고객을 등록·검색·수정하고 다른 직원과 공유하지 않는 조건에서는 인터넷 서버에 데이터를 저장할 필요가 크지 않다 [04:47]
• 프런트엔드는 고객 목록, 검색 입력, 상세 정보처럼 사용자가 보고 조작하는 영역이다. 화면 구성에는 React를, 데이터 형식을 명확하게 관리하는 데는 TypeScript를 사용한다 [05:20]

4. 첫 앱에서 고객 조회와 수정 내용의 저장을 확인한다

• 엑셀 파일과 요구사항으로 앱을 만든 뒤 개발 서버에 접속한다. 접속되지 않았던 화면은 개발 서버를 실행하고 새로고침한 뒤 정상적으로 열린다 [08:20]
• 고객을 선택하면 상세 정보와 거래·접촉 기록을 확인할 수 있다. 연락처를 수정하고 다시 편집 화면을 열었을 때 변경값이 유지되며, 수정 내용은 IndexedDB에 저장된다 [09:19]

5. 브라우저 저장소는 다른 브라우저와 자동으로 공유되지 않는다

• 다른 브라우저에서 같은 앱을 열면 앞서 수정한 연락처가 반영되지 않는다. 데이터가 서버가 아닌 해당 브라우저의 저장 공간에 있기 때문에 다른 브라우저나 컴퓨터와 자동으로 동기화되지 않는다 [10:11]
• 브라우저 저장 데이터를 삭제하면 앱 데이터도 사라질 수 있으므로 실제 사용에는 백업이나 데이터 내보내기가 필요하다 [10:19]

6. 여러 직원이 함께 쓰려면 중앙 저장소가 필요하다

• 직원 다섯 명이 함께 사용한다면 한 직원이 수정한 전화번호와 방문 기록을 다른 직원도 확인해야 한다. 엑셀 파일을 주고받는 방식은 전달과 최종 수정본 확인을 반복하게 만든다 [11:23]
• 여러 직원이 공통 데이터를 사용하려면 중앙 저장소가 필요하다. 이 요구에 맞춰 데이터베이스와 백엔드를 추가한다 [11:34]

7. 코드 작업과 브라우저 설정 작업을 연결한다

• Claude Code는 코드 작성과 명령 실행을 맡고, 어사이드 브라우저는 웹사이트의 화면 확인과 설정을 돕는다. 두 도구를 연결하면 개발 작업과 웹 설정 작업을 이어서 수행할 수 있다 [12:33]
• 어사이드 CLI 연결과 공식 설정 확인을 요청한 뒤 CLI 업데이트와 로그인 상태 확인을 거쳐 공식 MCP 서버를 Claude Code에 등록한다 [13:58]

8. Cloudflare 개발 환경을 준비하고 중요한 승인은 직접 처리한다

• Cloudflare Workers는 서버 쪽 프로그램 실행에, D1은 데이터 저장에 사용한다. Wrangler는 개발 환경 설정, 테스트와 배포를 수행하는 CLI 도구다 [15:13]
• 우선 대시보드와 Workers·D1 사용 가능 여부만 점검하고 데이터베이스는 생성하지 않도록 범위를 정한다. 로그인이나 중요한 권한 승인은 사람이 직접 확인하고 처리한다 [16:43]

9. 엑셀 시트를 관계형 데이터베이스의 테이블로 옮긴다

• D1은 SQLite 기반의 관계형 데이터베이스 서비스다. 엑셀에서 고객 목록·거래 현황·접촉 이력을 시트로 나눴던 것처럼 데이터베이스에서도 테이블을 나눠 저장한다 [18:46]
• 고객 테이블에는 고객 ID·이름·연락처를, 거래 테이블에는 거래 ID·고객 ID·날짜·금액을 저장한다. 거래와 접촉 테이블의 고객 ID를 통해 고객 정보와 관련 기록을 연결한다 [19:07]

10. 백엔드와 API가 화면의 요청을 처리한다

• 백엔드는 서버 쪽에서 사용자의 요청을 처리하고 업무 규칙을 적용한다. Workers를 사용하면 서버 컴퓨터를 직접 설치하고 관리하지 않아도 서버 쪽 프로그램을 실행할 수 있다 [19:40]
• 고객 검색 요청은 프런트엔드에서 백엔드로 전달되고, 백엔드는 데이터베이스를 조회해 결과를 돌려준다. 프런트엔드는 받은 정보를 화면에 표시하며, 이런 요청과 응답의 접점이 API다 [20:18]

11. 공유 구조로 바꾸고 브라우저 사이의 변경 반영을 검증한다

• 기존 화면을 유지하면서 데이터 저장을 D1으로 옮기고 Workers API를 연결하는 구조로 변경한다. 먼저 로컬에서 테스트하도록 요청한다 [21:17]
• API 동작 테스트를 통과한 뒤 한 브라우저에서 고객 전화번호를 수정하고 다른 브라우저를 새로고침한다. 같은 수정값이 나타나면서 브라우저 사이에 데이터가 공유되는 것을 확인한다 [23:20]

12. 인증과 인가를 구분해 직원별 접근 범위를 정한다

• 일반 직원은 자신이 담당하는 고객 정보를 수정하고, 고객 전체 삭제나 담당자 변경은 관리자만 수행하도록 요구사항을 정한다 [24:46]
• 인증은 사용자가 누구인지 확인하는 과정이고, 인가는 그 사용자가 어떤 일을 할 수 있는지 결정하는 과정이다. 로그인에 성공해도 모든 기능을 사용할 수 있는 것은 아니다 [25:18]

13. 권한 검사는 백엔드에서 최종적으로 수행한다

• 일반 직원에게 삭제 버튼을 숨겨도 API를 직접 호출할 수 있으므로 접근을 막기에 충분하지 않다. 백엔드가 실제 삭제 권한을 검사해야 한다 [26:28]
• 관리자·일반 직원·조회 전용으로 역할을 나누고, 고객 수정과 삭제 권한을 백엔드에서 검사하도록 구현을 요청한다. Cloudflare Access와 연결할 수 있는 구조도 요구한다 [26:53]

14. 테스트 배포 중 Access 대신 다른 로그인 방식으로 변경한다

• 실제 직원 로그인까지 검증하기 위해 가상의 고객 데이터를 사용하는 테스트 앱을 인터넷에 배포한다. 최종 운영 주소에 공개하는 단계는 아니며, 허용된 테스트 계정과 역할별 권한을 확인하는 것이 목적이다 [27:49]
• 이메일 별칭 세 개를 테스트 계정으로 사용하고 Access 연결에 필요한 리소스 생성을 승인한 뒤, 원격 데이터 확인과 Worker 배포를 진행한다 [28:24]

15. 인증·권한 검증을 마치고 실제 사용 주소의 배포를 준비한다

• 브라우저 검증이 모두 통과한 것으로 확인된다. 인증되지 않은 사용자의 접근을 차단하고, 인증된 사용자에게도 필요한 권한만 허용하는 앱으로 발전해진다 [29:36]
• 실제 사용할 주소로 배포하는 작업을 준비한다. CLI 연결, Cloudflare 개발 환경 설정, 테스트 환경의 로그인·권한 확인을 마쳤으므로 설정을 처음부터 반복할 필요는 없다 [29:58]

16. 운영 환경 배포와 고객 데이터 공유

• Claude Code는 코드와 배포 설정을 준비하고, Wrangler는 Cloudflare 배포를 수행하며, 브라우저 도구는 설정과 결과를 확인한다. 배포 후에는 운영 데이터베이스와 접근 제한 설정도 확인해야 한다. [30:00]
• 운영 환경을 별도로 분리하고 엑셀의 가상 데이터를 넣는다. 관리자 계정으로 임시 비밀번호에 로그인한 뒤 비밀번호를 변경하고, 로컬호스트가 아닌 외부 접속 가능한 사이트로 배포를 완료한다. [31:03]

17. 고객 정보 수정으로 확인한 역할 분담과 요구 사항의 확장

• 고객 상태를 ‘교체’로 수정하고 저장한 뒤 다시 열어 변경 결과를 확인한다. 프론트엔드는 사용자 입력을 전달하고 백엔드는 데이터베이스에 저장하며, 앱은 요청 처리·데이터 관리·권한 검사 구조를 갖춘다. AI의 코드 생성과 올바른 작동 검증은 별개의 작업이다. [31:58]
• 첫 앱은 React와 IndexedDB로 혼자 사용하며 별도 백엔드 없이 작동했다. 두 번째는 화면을 로컬에 둔 채 Cloudflare D1과 Workers API로 데이터를 공유했고, 세 번째는 직원별 로그인과 역할별 권한 검사를 추가했다. Cloudflare Access는 비용 문제로 다른 방법을 선택했다. [33:00]

18. 저장 목적과 실행 구조에 따라 달라지는 기술 선택

• Cloudflare가 모든 웹앱의 정답은 아니다. 간단한 설정은 로컬 스토리지, 개인용 웹의 구조화된 데이터는 IndexedDB, 단순한 데이터 관리와 보고서는 엑셀로도 처리할 수 있다. [34:46]
• SQLite는 별도 데이터베이스 서버 없이 사용할 수 있고, PostgreSQL은 다양한 규모의 관계형 데이터 처리에 활용된다. Supabase는 PostgreSQL 기반으로 인증과 데이터베이스를 함께 제공한다. DuckDB는 대량 데이터 조회·집계에 강점이 있어, 고객 정보를 수시로 등록·수정하는 시스템과는 주된 용도가 다르다. [35:09]

19. 사용 환경 질문으로 기술 구성을 좁히는 진단 도구

• 비개발자가 겪는 기술 선택의 어려움을 줄이기 위해, 앱의 사용 환경에 관한 질문에 답하면 적합한 기술 구성을 추천하는 진단 도구를 구상한다. [36:20]
• 혼자 쓰는지 여러 사람이 함께 쓰는지, 다른 컴퓨터에서도 데이터를 확인해야 하는지 등을 묻는 진단 시트를 별도로 만들어 공유할 예정이다. 처음 바이브 코딩을 시작할 때 기술을 고르는 단계에서 막히는 어려움을 줄이는 것이 목적이다. [36:50]

20. AI에 구현을 맡겨도 사람이 판단하고 검증해야 하는 것

• 엑셀에서 출발해 개인용 고객 관리 앱을 만들고 여러 직원이 접근하도록 배포하는 과정에서 프론트엔드·백엔드·데이터베이스의 역할을 확인했다. 이 과정에 쓰인 기술을 모두 직접 배워야 한다는 뜻은 아니다. [37:17]
• 전문 개발에서는 언어·프레임워크·데이터베이스 지식이 여전히 중요하지만, AI에 구현의 상당 부분을 맡길 수 있다. 해결할 문제, 사용자, 데이터 관리 방식, 결과의 정상 작동 여부를 판단하는 일은 여전히 사람의 몫이다. [37:39]

🧾 결론

• 프런트엔드는 화면과 입력, 백엔드는 요청 처리와 업무 규칙, 데이터베이스는 저장과 조회를 맡는다. 실제 구성에서 역할이 겹치더라도 책임을 구분하면 이해하기 쉽다.
• 개인용·공동 사용·로그인과 권한 관리라는 세 단계는 요구가 늘어날 때 어떤 기술을 추가할지 판단하는 기준이다.
• Cloudflare가 모든 앱의 정답은 아니다. 엑셀, 브라우저 저장소, SQLite, PostgreSQL 등은 저장 목적과 실행 환경에 따라 선택해야 한다.
• AI에 구체적으로 구현을 맡기려면 사용자, 저장 위치, 정보별 접근 대상과 정상 작동 기준을 먼저 설명할 수 있어야 한다.

📈 투자·시사 포인트

• AI로 앱을 만들더라도 문제 정의와 결과 검증은 사람의 역할로 남는다. 코드 생성 이후에도 데이터 관리와 접근 권한을 판단할 역량이 필요하다.
• 업무 도구의 확장에서는 화면 변화보다 저장·공유·권한 구조의 변화가 중요할 수 있다. 실습에서도 비슷한 화면을 유지하면서 내부 구성을 바꿨다.
• 플랫폼 선택에는 기능뿐 아니라 계정 설정과 이용 조건도 영향을 준다. 영상에서는 카드 정보 입력을 피하려고 Cloudflare Access 대신 다른 로그인 방식을 선택했다.
• 공유 데이터베이스 도입과 화면의 실시간 갱신은 별개다. 업무에서 요구하는 최신 정보 반영 수준을 기술 선택 전에 정해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Cloudflare Access를 대체한 최종 로그인 방식의 구체적인 구현은 제공된 자료에 설명되지 않는다. 인증 정보 검증과 비밀번호 처리 방식은 추가 확인이 필요하다.
• 무료 이용에도 카드 정보가 필요한 것으로 보였다는 실습 경험만으로 모든 계정의 이용 조건이나 비용을 단정할 수 없다. 당시의 선택 이유와 실제 적용 조건을 구분해야 한다.
• 자료는 브라우저 간 변경 조회와 역할별 테스트 통과를 설명하지만, 동시 수정 충돌 처리나 대규모 사용 성능의 검증 결과는 제시하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 앱을 누가 사용하는지, 다른 컴퓨터에서 같은 데이터를 봐야 하는지, 사용자마다 어떤 작업을 허용할지 작성한다.
• 엑셀의 고객 ID 연결, 중복 이름, 누락 연락처, 상태값과 날짜 형식을 점검한다.
• 개인용 저장 방식을 선택한다면 데이터 내보내기와 백업 방법을 마련하고, 브라우저 저장소 삭제에 따른 영향을 확인한다.
• 공동 사용 앱에서는 한 브라우저에서 수정한 값이 다른 브라우저와 컴퓨터에서 다시 조회되는지 확인한다.

❓ 열린 질문

• 현재 업무에는 수정 후 다시 조회하는 방식이면 충분한가, 화면의 자동 갱신까지 필요한가?
• 여러 직원이 같은 고객 정보를 동시에 수정할 때 어떤 처리 규칙이 필요한가?
• 실제 사용자 수와 데이터 관리 방식에 비춰 엑셀·IndexedDB·중앙 데이터베이스 중 어느 구성이 적합한가?