Nuxt3에 게시판 붙이기
11-05 10:45
안녕하세요, H:Dev+ 팀입니다. Nuxt3로 서비스를 만들다 보면 게시판 하나 넣는 일이 생각보다 큽니다. 게시물 저장용 테이블을 설계하고, 목록·상세·등록 API를 만들고, 페이지네이션과 검색까지 백엔드 코드를 따로 짜야 하기 때문입니다. 작은 프로젝트라도 이 과정을 건너뛸 수는 없어서, 화면보다 서버 작업에 먼저 손이 가게 됩니다. H:Dev+는 이 과정을 서버 코드 작성 없이 커넥터 호출로 대체합니다. 1. 커넥터를 설치하고 연결 정보를 설정합니다 H:Dev+는 Nuxt3 전용 커넥터를 @hdevplus/connector-nuxt3 패키지로 npm에 공개하고 있습니다. 공식 문서대로 npx nuxi@3.2 init으로 Nuxt3 프로젝트를 만든 뒤 이 패키지를 설치하고, .env에 보안키(HDP_SECURE_KEY)와 API 주소(NUXT_PUBLIC_HDP_API_URL)를 적고, nuxt.config.ts의 modules에 커넥터를 등록하면서 runtimeConfig로 이 값을 연결하면 준비가 끝납니다. 이 커넥터는 Nuxt3 전용이라 버전 없이 npx nuxi init으로 만든 Nuxt4 프로젝트에는 설치되지 않습니다. 보안키는 시스템(System) 콘솔의 설정(Settings) 메뉴에서 발급받는 값이며, 공식 문서는 개발 초기에 가입 없이 바로 쓸 수 있는 데모 보안키도 함께 안내합니다. 2. 데이터 식별자로 목록을 불러옵니다 연결이 끝나면 화면마다 필요한 데이터를 "데이터 식별자(JSON)"로 정의하고 useNuxtApp().$connector(requestData)를 호출합니다. 게시물 목록은 GET_POST_LIST 식별자에 board_seq, 정렬(order)·검색(search_keyword)·페이지(page, list_per_page) 조건을 담아 요청하면 됩니다. 응답에는 post_list 배열과 함께 전체 게시물 수·페이지 번호 같은 pagination 정보도 같이 들어 있어, 받은 post_list를 템플릿에서 그대로 반복(v-for) 출력하고 pagination 값으로 페이지 이동 링크를 만들면 목록 화면이 완성됩니다. 별도의 목록 API를 설계하거나 데이터베이스 쿼리를 짜는 과정은 없습니다. 3. 등록은 폼 속성만으로 처리합니다 게시물 등록은 ADD_POST 식별자로 커넥터를 호출해 게시판 목록(board_list)을 받은 뒤, id="frm_save_post"인 폼에 board_seq·subject·content 같은 정해진 name 속성을 지정하는 방식입니다. 저장 뒤 이동할 경로는 return_url 속성으로, 회원이 아닌 방문자가 쓸 경우의 작성자 정보·비밀번호 입력칸은 email·cell_phone·reg_name·password 속성으로 지정합니다. 저장 버튼을 누르면 커넥터가 저장 요청과 응답 처리까지 맡으므로, 등록 페이지에서도 별도의 요청 코드를 작성하지 않습니다. 공식 Nuxt3 퀵스타트 샘플 저장소에 목록·등록 화면 전체 예제가 공개돼 있어, 프로젝트 구조를 그대로 참고할 수 있습니다. 백엔드 코드 없이, 커넥터 설정만으로 이 글에서는 Nuxt3 프로젝트에 커넥터를 설치하는 단계, 게시물 목록을 불러오는 방법, 게시물을 등록하는 방법 세 가지를 소개했습니다. 게시물 보기·수정·삭제·코멘트 기능도 같은 방식(데이터 식별자 정의 → 커넥터 호출 → 응답 사용)으로 연동할 수 있습니다. 실 서비스에 쓸 보안키 발급이나 게시판별 세부 옵션은 관리 콘솔에서 별도로 확인해야 합니다. 설치 명령과 전체 예제 코드는 빠르게 시작하기 문서 보기에서 확인하실 수 있습니다.
2026-10-29 10:37:06
납품 뒤 고객사가 직접 관리하는 게시판 만들기 (에이전시 활용법)
안녕하세요, H:Dev+ 팀입니다. 에이전시로 일하다 보면 사이트를 납품한 뒤에도 "이번 공지사항 하나만 추가해 주세요", "오타가 있어서 수정해야 해요" 같은 연락을 계속 받으신 적이 있으실 겁니다. 게시판 하나 때문에 매번 코드를 열어 수정하고 재배포하는 일이 반복되면, 그만큼 다음 프로젝트에 쓸 시간이 줄어듭니다. H:Dev+로 게시판을 붙이면, 고객사 담당자가 해당 사이트의 관리 콘솔에 접근할 수 있는 계정과 운영 범위를 갖춘 경우 콘텐츠 관리를 콘솔에서 직접 맡아볼 수 있어, 에이전시는 운영 단계에서 반복되는 수정 요청에서 벗어날 수 있습니다. 1. 게시판 데이터 식별자로 목록과 등록을 연결합니다 H:Dev+ 커넥터 연동이 준비된 프로젝트에서, 게시물 목록은 GET_POST_LIST 데이터 식별자와 board_seq를 사용해 불러오고 응답 데이터를 화면에 표시합니다. 게시물 등록은 ADD_POST 식별자를 쓰는 frm_save_post 폼을 사용하며, 제목·본문 외 입력값과 저장 후 이동 경로(return_url)는 공식 문서 및 회원/비회원 구성에 맞춰 설정합니다. 별도로 게시판 테이블을 설계하거나 저장 로직을 짜는 과정은 없지만, 이 글은 전체 설치나 권한 설정을 완료하는 절차가 아니라 게시판 연동과 운영 콘솔 활용의 개요입니다. 2. 콘텐츠 관리는 콘솔로 넘깁니다 게시판을 다 붙였다면 다음은 운영 단계입니다. H:Dev+는 게시판마다 대시보드·게시물 목록·게시물 등록 화면을 갖춘 게시판 관리 콘솔을 자동으로 제공합니다. 공식 FAQ는 이 콘솔을 "기획자, 마케터, 운영자도 쉽게 사용할 수 있도록 설계"했다고 안내하며, 게시물을 CMS처럼 "등록, 수정, 삭제"할 수 있다고 밝히고 있습니다. 즉 코드를 다시 열지 않고도 콘솔 화면에서 글을 쓰고 고치고 지울 수 있다는 뜻입니다. 3. 운영 접근 범위를 확인하고 콘솔 사용법을 안내합니다 납품할 때는 먼저 고객사 담당자가 해당 사이트의 관리 콘솔에 접근할 수 있는 계정과 운영 범위를 확인한 뒤, 이 콘솔 화면 사용법을 안내합니다. 공식 FAQ는 운영자가 콘솔에서 콘텐츠를 등록·수정·삭제할 수 있다고 설명합니다. 접근 권한이 갖춰진 뒤에는 고객사 담당자가 직접 콘솔에서 게시물을 수정할 수 있어, 에이전시 쪽에서 반복적으로 코드를 열어 문구를 바꾸고 다시 배포하는 작업이 줄어듭니다. 다만 고객사별 계정 이관 절차나 에이전시 계정과 분리된 전용 권한·역할(role) 체계가 있는지는 공개 문서·FAQ에서 확인되지 않아, 콘솔을 공유 계정으로 쓸지 별도 계정을 발급할지는 프로젝트별로 따로 확인해야 합니다. 게시판을 여러 개 운영하는 사이트에서 콘솔 메뉴가 게시판별로 어떻게 구분되는지도 이번 조사에서는 로그인 없이 확인하지 못했습니다. 코드 한 번, 운영은 콘솔로 이 글에서는 프론트엔드에 게시판 데이터 식별자를 연결하는 흐름과, 고객사의 콘솔 접근 권한을 확인한 뒤 사용법을 안내하는 흐름 두 가지를 소개했습니다. 커넥터·화면 구성과 운영 접근권한 확인이 전제되면, 게시물을 추가할 때마다 코드를 다시 열 필요는 없습니다. 게시판 연결에 쓰는 입력값과 각 화면의 데이터 구조는 게시물 목록 문서 보기에서 확인하실 수 있습니다.
10-29 10:37
2026-10-24 14:13:04
홈페이지 문의폼을 백엔드 없이 만드는 법
안녕하세요, H:Dev+ 팀입니다. 랜딩페이지 하단에 "문의하기" 폼 하나 넣으려다가 폼 데이터를 받을 서버부터 새로 만들어야 했던 경험, 한 번쯤 있으실 겁니다. 저장과 관리자 확인 화면까지 갖추려면 단순한 폼치고는 손이 많이 갑니다. H:Dev+ 웹 폼 기능은 콘솔 설정과 HTML 연결, 두 가지 절차로 안내되어 있습니다. 오늘은 공식 문서와 화면을 기준으로 그 절차를 정리해 드립니다. 1. 콘솔에서 폼부터 만듭니다 가장 먼저 할 일은 코딩이 아니라 설정입니다. 웹 폼 콘솔의 "폼 관리"에서 설문 제목, 설명, 작성 권한(회원 전용 또는 익명)을 설정하면 해당 폼의 고유 코드(form_code)가 발급됩니다. 작성 권한을 "익명"으로 두면 회원가입 없이 누구나 제출할 수 있는 공개 문의폼으로, "회원 전용"으로 두면 로그인한 사용자만 제출할 수 있는 폼으로 바로 전환됩니다. 텍스트 입력 외의 선택형(select)·체크박스·라디오 버튼 같은 항목은 다음 단계인 HTML 연결에서 구성합니다. 2. 프론트엔드에는 공식 문서의 HTML 폼을 연결합니다 발급받은 form_code를 HTML 폼에 연결합니다. 문서가 제공하는 예시처럼 id="frm_web_form" 폼 안에 form_code와 제출 후 이동할 return_url을 hidden 값으로 넣습니다. 이름·이메일 같은 응답자 정보는 answerer_name/answerer_email 필드에 채우고, 문의 항목은 이와 별도로 answer[번호][label]/answer[번호][value] 형식으로 채웁니다. 선택형(select)·체크박스·라디오 버튼 같은 입력 항목도 공식 문서의 HTML 예시처럼 프론트엔드에서 구성하며, 체크박스 값은 answer[번호][value][]로 전송합니다. 이름 입력칸에 data-validation="not-empty", 이메일 입력칸에 data-validation="email"을 지정하면 빈 값이나 잘못된 이메일 형식을 제출 전에 걸러낼 수 있습니다. 다만 이 검증은 브라우저 단에서 이뤄지는 프론트엔드 검증으로, 서버 측 검증을 대체하지는 않습니다. 3. 제출된 문의는 콘솔에서 바로 확인합니다 사용자가 폼을 제출하면 지정한 return_url로 이동하며, 운영자는 같은 웹 폼 콘솔의 "답변 목록"과 "답변 상세" 화면에서 접수된 문의를 확인하는 구조입니다(공식 문서와 콘솔 화면을 기준으로 확인한 내용이며, 제출부터 관리자 조회까지 전체 과정을 직접 재현해 검증하지는 않았습니다[미확인]). 목록 화면에서는 응답자 정보와 제출 일시를, 상세 화면에서는 문의 항목별 답변 내용을 확인할 수 있습니다. 메일 서버나 별도 관리자 페이지를 새로 만들지 않고도 콘솔 화면에서 접수 내용을 확인하는 방식입니다. 콘솔 설정과 폼 태그 연결, 문서 기준 두 단계로 정리합니다 이 글에서 다룬 작업은 콘솔에서 폼을 설정하는 것과, 발급받은 폼 코드를 공식 문서의 HTML 예시에 연결하는 것, 두 단계입니다. 문서에 안내된 범위에서는 별도 서버 코드를 새로 짜거나 데이터베이스 테이블을 설계할 필요가 없습니다. 입력 항목 구성과 코드 전체 예시, 그리고 프론트엔드 검증의 적용 범위는 웹 폼 문서 보기에서 확인하실 수 있습니다.
10-24 14:13
2026-10-12 00:39:15
Supabase·Firebase 대신 H:Dev+, 언제 무엇을 쓰나 (공정 비교)
안녕하세요, H:Dev+ 팀입니다. 백엔드를 고를 때 Supabase나 Firebase부터 떠올리는 분이 많습니다. 두 서비스 모두 훌륭한 BaaS(Backend As a Service)입니다. 다만 모든 프로젝트에 정답은 아닙니다. 오늘은 H:Dev+가 이 둘과 어떻게 다른 자리에서 쓰이는지, 공식 요금제와 기능을 기준으로 정리해 드립니다. 셋의 구조부터 다릅니다 CMS(워드프레스 등)는 플러그인으로 백엔드를 붙이는 방식이라 프론트 개발이 제한적입니다. Supabase·Firebase 같은 BaaS는 인증·자동 생성 API 등 기본 백엔드 기능 자체는 제공합니다(Supabase는 DB 스키마에서 API를 자동 생성해 브라우저에서 직접 호출할 수 있다고, Firebase는 백엔드 서비스·SDK·바로 쓰는 UI를 제공한다고 각 공식 문서에서 밝히고 있습니다). 다만 프로젝트별 데이터 모델·권한 설정과 업무 로직, 운영용 관리 화면은 별도로 구현해야 합니다. H:Dev+는 회원·게시판·웹폼 등 제공 기능 범위 안에서는 프론트엔드가 데이터 식별자를 정의하고 커넥터를 호출하기만 하면 되고, 기능별 관리 콘솔도 함께 제공돼 그 범위 안에서는 별도 백엔드 구현 부담이 줄어듭니다. H:Dev+는 이 범위 안에서 프론트엔드 개발자와 기획자가 별도 SDK 연동 없이 바로 쓸 수 있도록 설계됐다는 점이 다릅니다. 비용 구조를 직접 비교하면 Supabase는 무료 Free 플랜(월 0달러, DB 500MB) 외에 유료 플랜은 월 구독료 + 포함량 초과분 추가 과금 구조입니다. Pro는 월 25달러부터 시작해 월간 활성 사용자 10만 명·디스크 8GB 등 포함량을 넘으면 추가 요금이 붙고, Team은 월 599달러부터 시작합니다(2026-10-09 공식 pricing 페이지 기준, 변경될 수 있음). Firebase는 무료 Spark 플랜과 사용량 기반 Blaze 플랜 두 가지이며, Blaze는 월 기본료 없이 무료 한도를 넘는 사용량만큼만 과금됩니다. 즉 Supabase는 "월 구독료 기반+초과 사용량 과금", Firebase는 "기본료 없는 순수 사용량 과금"으로 구조가 다릅니다. H:Dev+는 현재 베타 기간이라 누구나 무료로 쓸 수 있고, 정식 요금제는 사용자 피드백을 반영해 준비 중입니다(변경될 수 있음). 그래서 언제 무엇을 쓰면 좋을까요 DB 스키마를 직접 설계하고 쿼리를 세밀하게 제어해야 하거나, 이미 익숙한 백엔드 개발팀이 있다면 Supabase·Firebase가 더 맞을 수 있습니다. 반대로 프론트엔드 리소스만으로 빠르게 MVP를 띄워야 하거나, 운영자가 코드 없이 콘솔에서 콘텐츠를 관리해야 한다면 H:Dev+가 더 맞습니다. 관리 콘솔이 기능별로 자동 제공돼 회원·게시판·웹폼을 별도 개발 없이 운영할 수 있다는 점이 가장 큰 차이입니다. 결국 "어느 쪽이 더 낫다"가 아니라 "어느 쪽이 지금 필요한가" 세 가지 중 뭐가 절대적으로 우월한지는 없습니다. 팀 구성과 프로젝트 단계에 따라 맞는 도구가 다를 뿐입니다. H:Dev+가 어떤 구조로 동작하는지 더 궁금하시다면 H:Dev+란?에서 자세히 확인하실 수 있습니다.
10-12 00:39
2026-10-08 16:37:03
H:Dev+ 2026 업데이트: 오랜만에 전하는 소식 (지금 운영 중인 기능 총정리)
안녕하세요, H:Dev+ 팀입니다. 그동안 블로그로 따로 소식을 전하지 못한 사이, 콘솔 안에서는 꽤 많은 기능이 쌓였습니다. 오늘은 지금 운영 중인 기능을 화면 그대로 모아서 소개해 드립니다. 로그인부터 — 구글 계정으로 바로 시작 회원가입의 첫 장벽인 로그인 화면에는 이제 구글 로그인이 추가됐습니다. 설정 방법은 지난 글 프론트엔드에 구글 로그인 붙이기에서 자세히 다뤘으니, 아직 안 보셨다면 참고해 주세요. 게시판 · 웹폼, 알림을 각각 켜고 끌 수 있습니다 콘솔에서 게시판이나 웹폼을 만들거나 수정하는 화면에는 "알림 설정" 항목이 있습니다. 게시판은 게시글 등록·수정, 코멘트 등록, 좋아요 각각을, 웹폼은 폼 전송 시점을 선택해 알림을 받을지 말지 정할 수 있습니다. 여기에 더해 System > Settings 화면의 "관리자 알림 수신" 버튼으로 전체 알림을 한 번에 켜고 끌 수도 있습니다. 게시판마다, 웹폼마다 따로 정할 수 있어서 운영자는 꼭 필요한 알림만 골라서 받을 수 있습니다. 업그레이드 전에는 콘솔에서 바로 백업 버전을 올리기 전 걱정되는 건 역시 데이터입니다. System > Upgrade 화면에는 현재 버전과 함께 "DB Backup" 목록이 있고, 하단의 BACKUP NOW 버튼을 누르면 그 자리에서 바로 백업이 만들어집니다. 백업 목록에는 최근 백업 5개가 나란히 쌓이고, 각각 RESTORE 버튼으로 그 시점으로 되돌릴 수 있습니다. 새 버전이 나왔을 때도 같은 화면에서 릴리즈 내용을 확인하고 업그레이드할 수 있어서, 무엇이 바뀌는지 모른 채 올리는 일은 없습니다. 위젯으로, 코드 몇 줄에 화면 한 조각 더하기 콘솔에서 위젯을 만들고 나면, 기존에 쓰던 데이터 식별자에 widget 속성을 추가하고 위젯 코드를 배열로 넣으면 됩니다. 그러면 응답의 widget 항목에 위젯 제목과 게시물 목록이 함께 내려오고, 이것을 원하는 자리에 출력하기만 하면 됩니다. 게시글 목록 옆에 인기글을 보여주거나, 홈페이지 한쪽에 최신글을 노출하는 식으로 — 새로 백엔드를 만들지 않고도 화면을 조금씩 넓혀갈 수 있습니다. 결국 콘솔 하나로 운영까지 이 모든 기능의 공통점은, 백엔드를 따로 개발하지 않아도 콘솔에서 화면으로 관리할 수 있다는 점입니다. 회원·게시판·웹폼·위젯 — 기능이 늘어날 때마다 관리 콘솔도 함께 넓어지고 있습니다. 전체 기능과 사용법은 H:Dev+ 문서 전체 보기에서 확인하실 수 있습니다.
10-08 16:37
2026-10-04 15:44:55
프론트엔드에 구글 로그인 붙이기 — H:Dev+ OAuth 연동
안녕하세요, H:Dev+ 팀입니다. 로그인 화면에 "Google 계정으로 이용하기" 버튼, 보신 분들 계실 텐데요. H:Dev+에 구글 로그인(OAuth) 연동 기능이 추가되었습니다. 이번 글에서는 이 기능이 왜 필요한지, 그리고 여러분의 서비스에 어떻게 붙이는지 안내해 드립니다.회원가입 한 줄이 이탈로 이어지는 이유이메일과 비밀번호를 새로 만들어야 하는 회원가입 폼은 생각보다 큰 진입 장벽입니다. 비밀번호를 또 하나 기억해야 한다는 부담, 이메일 인증을 기다려야 하는 시간이 사용자를 돌아서게 만듭니다. 구글 로그인은 이미 로그인돼 있는 구글 계정으로 버튼 한 번만 누르면 끝나기 때문에, 이 장벽을 없애는 가장 확실한 방법 중 하나입니다. 특히 MVP를 빠르게 검증해야 하는 스타트업이나, 운영 리소스가 부족한 소규모 팀일수록 회원가입 단계의 마찰을 줄이는 일이 더 중요합니다.H:Dev+에서는 어떻게 동작하나요H:Dev+의 구글 로그인은 테넌트별로 자신의 구글 앱을 직접 연결하는 방식(BYO, Bring Your Own)입니다. 그래서 사용자가 구글 로그인 동의 화면을 볼 때 H:Dev+가 아니라 여러분의 서비스 이름이 표시됩니다. 설정은 세 단계입니다.Google Cloud Console에서 OAuth 2.0 클라이언트(웹)를 만들고, 승인된 리디렉션 URI에 콜백 페이지 주소를 등록합니다.H:Dev+ 관리 콘솔의 System > Settings에서 'Google 로그인' 카드에 발급받은 Client ID와 Secret을 저장합니다.로그인 폼에 h-btn-sign-in-google 클래스를 가진 버튼 하나를 추가합니다.이게 끝입니다. 일반 로그인과 똑같은 데이터 식별자(SIGN_IN)를 그대로 쓰기 때문에 백엔드 쪽에서 새로 만들어야 할 코드가 없습니다. 로그인 폼과 구글 인증이 끝난 뒤 돌아오는 콜백 페이지 모두 같은 구조의 폼 하나로 처리되고, 로그인 성공 시 구글 이메일로 기존 회원을 찾거나, 없으면 새 회원으로 자동 가입 처리됩니다.보안도 챙겼습니다. 콘솔에 저장한 Client Secret은 테넌트마다 다른 키로 암호화되어 저장되고, 로그인 처리에 필요한 순간에만 복호화해서 사용합니다. 저장한 뒤에는 콘솔 화면에도 원문이 다시 표시되지 않고 마지막 4자리만 보이며, 서버 로그에도 값이 가려진 채로 남습니다.설정할 때 주의할 점설정할 때 가장 많이 걸리는 부분은 리디렉션 주소입니다. Google Cloud Console에 등록하는 승인된 리디렉션 URI와 H:Dev+ 로그인 폼에 넣는 콜백 주소는 문자 하나까지 정확히 일치해야 합니다. 다르면 구글 쪽에서 redirect_uri_mismatch 오류를 돌려줍니다. 또 콘솔에 Client ID·Secret을 아직 저장하지 않은 테넌트에서 버튼을 누르면 "구글 로그인이 설정되지 않았다"는 안내를 받게 되니, 운영 전에 설정이 저장됐는지 한 번 더 확인해주세요.지금 바로 적용해보세요이미 H:Dev+로 서비스를 운영 중이시라면, 로그인 폼에 버튼 하나 추가하는 것만으로 구글 로그인을 켤 수 있습니다. 설정 방법과 전체 코드 예시는 H:Dev+ 구글 로그인 문서에서 확인하실 수 있습니다.
10-04 15:44