웹앱 개발에서 프론트엔드와 백엔드를 분리해야 하는 3가지 이유
간단한 웹앱을 만들 때, HTML 파일 하나에 모든 기능을 넣으려는 유혹에 빠지기 쉽습니다. 하지만 실무적인 관점과 보안 측면에서 볼 때, 프론트엔드(UI)와 백엔드(Server)의 분리는 선택이 아닌 필수입니다. 그 이유를 정리합니다.
1. 보안의 핵심: "금고 열쇠를 길거리에 두지 마라" (Security)
가장 결정적인 이유는 API Key(자격 증명)의 노출입니다.
단일 파일의 문제: 유튜브 API를 사용하려면 고유의 API 키가 필요합니다. 이를 HTML/JS 파일 하나에 다 넣으면, 브라우저의 '소스 보기'만으로도 누구나 사장님의 키를 훔쳐갈 수 있습니다. 타인이 내 키를 도용해 할당량을 다 써버리거나 부정 사용을 할 경우 그 책임은 고스란히 주인에게 돌아옵니다.
분리 시 장점: 백엔드(
Code.gs)는 구글 서버 내부에서만 실행됩니다. API 키를 서버라는 '금고' 안에 숨겨두고 결과값만 화면에 던져주기 때문에 외부에서는 절대 키를 알 수 없습니다.
2. 통신의 장벽: "CORS(교차 출처 리소스 공유) 문제" (Connectivity)
브라우저는 보안상 자신이 접속한 도메인이 아닌 다른 곳(유튜브 서버 등)으로 직접 데이터를 요청하는 것을 엄격히 제한합니다.
단일 파일의 문제: 일반 HTML 파일에서 유튜브 API를 직접 호출하면 브라우저가 "위험한 요청"이라며 차단해 버리는 경우가 허다합니다.
분리 시 장점: 백엔드(GAS)는 서버 대 서버로 통신합니다. 구글 서버가 직접 유튜브 서버에 "사장님이 요청하신 데이터 좀 줘"라고 말하는 방식이라 브라우저의 제약에서 자유롭고 훨씬 안정적입니다.
3. 유지보수와 확장성: "공장 라인과 전시장 분리" (Scalability)
단일 파일의 문제: 기능이 늘어날수록 코드가 수천 줄로 불어나 스파게티처럼 꼬이게 됩니다. 디자인 수정하려다 핵심 로직을 건드리는 사고가 빈번해집니다.
분리 시 장점: * 프론트엔드: '어떻게 보여줄 것인가(UI/UX)'에만 집중합니다. (디자인 수정이 자유로움)
백엔드: '어떻게 데이터를 처리할 것인가(Logic)'에만 집중합니다. (기능 추가가 용이함)
나중에 데이터베이스(구글 시트) 연동이나 AI 분석 기능을 추가할 때도 백엔드만 톡 건드리면 되므로 훨씬 전문적인 관리가 가능합니다.
