어려운 것은 화면이 아니라
기능입니다
바이브 코딩으로 소개와 진료 안내 화면은 첫날에도 만들어집니다. 손이 멈추는 곳은 정해져 있습니다 — 로그인, 예약, 문의, 관리자 네 화면입니다. 이 화면들이 어려운 이유는 보기에 복잡해서가 아니라, 그리는 일이 아니라 데이터를 저장하고 신원을 확인하고 권한을 나누는 일이기 때문입니다. 그리고 여기에는 반드시 열쇠 관리가 따라옵니다.
보여주는 화면과
주고받는 화면
진료과목 소개는 한 방향입니다 — 병원이 쓴 내용을 환자가 읽고 끝납니다. 반면 예약과 문의는 양방향입니다. 환자가 남긴 것이 어딘가에 저장되고, 원내의 누군가가 그것을 열어 봅니다. 이 차이가 난이도의 전부입니다.
양방향 화면에는 세 가지가 따라옵니다. 데이터가 쌓일 자리, 그 데이터를 남긴 사람이 누구인지 확인하는 신원, 그리고 누가 무엇까지 볼 수 있는지 정하는 권한입니다. 화면 하나를 그리는 일에 비하면 결정할 것이 훨씬 많습니다.
AI는 이 코드를 아주 잘 씁니다. 문제는 무엇이 필요한지 모른 채 지시하면 그럴듯하지만 위험한 결과가 나온다는 데 있습니다. 화면이 잘 도는 것과 안전하게 도는 것은 눈으로 구분되지 않으므로, 여기에서는 알고 시키는 일이 특히 중요합니다.
각각 무슨 일을
실제로 하는가
이름만 보면 화면이지만 하는 일은 서로 다릅니다. 무엇을 하는 화면인지 알면 AI에게 무엇을 요구해야 하는지도 분명해집니다.
| 화면 | 실제로 하는 일 | 잘못 만들면 |
|---|---|---|
| 로그인 | 이 사람이 그 사람이 맞는지 확인하고, 확인된 상태를 일정 시간 유지합니다. 비밀번호를 직접 다루지 않고 구글 계정 같은 검증된 방식을 빌리는 것이 표준입니다. | 계정 도용 |
| 예약 | 희망 일시와 진료 내용을 받아 저장하고, 원내가 확인해 확정합니다. 같은 시간에 둘이 신청하면 어떻게 할지처럼 규칙을 미리 정해야 합니다. | 이중 예약 |
| 비로그인 문의 | 로그인 없이 누구나 남길 수 있어 문턱이 낮은 대신, 자동 프로그램이 쏟아붓기도 좋은 자리입니다. 받는 항목을 최소로 두는 것이 첫 번째 방어입니다. | 스팸 유입 |
| 관리자 | 접수된 내용을 열람하고 처리하는 화면입니다. 주소만 모르면 안전하다는 생각이 가장 흔한 착각이며, 권한으로 잠가야 합니다. | 정보 유출 |
병원이라 무게가 다릅니다 — 이 네 화면에 오가는 것은 환자의 이름과 연락처, 그리고 증상입니다. 일반 사이트에서는 불편으로 끝날 실수가 병원에서는 개인정보 사고가 됩니다. 예약 동선의 설계 자체는 병원 예약 시스템에 정리해 두었습니다.
기능에는 열쇠가 따라옵니다
데이터베이스에 접속하고 외부 서비스를 부르고 AI를 호출하는 순간, 그 자격을 증명하는 값 — 흔히 API 키라 부르는 열쇠 — 이 생깁니다. 비개발자가 가장 많이 사고를 내는 자리이며, 대부분은 이 값을 코드에 그대로 적어 두는 데서 시작됩니다.
열쇠가 생기는 자리데이터베이스 접속, 외부 서비스 연동, 알림 발송, AI 호출 — 기능을 붙일 때마다 하나씩 늘어납니다절대 하지 않을 것코드나 설정 파일에 값을 그대로 적고 저장소에 올리는 일입니다. 공개 저장소에 올라간 열쇠는 자동으로 수집됩니다Secret Manager구글 클라우드가 제공하는 비밀 값 보관소입니다. 코드에는 이름만 남고, 실제 값은 실행하는 순간 금고에서 꺼내 씁니다권한으로 잠그기누가, 어떤 서비스가 그 값을 꺼낼 수 있는지 계정 단위로 정합니다. 사람이 값을 몰라도 프로그램은 동작합니다교체와 이력노출이 의심되면 값만 새로 넣고 이전 것을 폐기합니다. 코드는 손대지 않아도 되고 버전 이력이 남습니다이미 클라우드에서 시작하셨다면 따로 도입할 것이 없습니다 — 같은 구글 클라우드 안의 기능이라 프로젝트를 만든 시점에 이미 쓸 수 있는 상태입니다.
열쇠가 새어 나가면 두 가지가 동시에 일어납니다. 제3자가 우리 이름으로 서비스를 쓰면서 요금이 청구되고, 그 열쇠가 데이터베이스로 향하는 것이었다면 그 안의 정보까지 열립니다. 병원이라면 후자가 훨씬 무겁습니다.
당사도 같은 방식으로 운영합니다 — 이 사이트가 쓰는 AI 열쇠는 코드가 아니라 Secret Manager에 있고, 코드에는 이름만 적혀 있습니다. 특별한 기술이 아니라, 기능을 만들기 시작하면 누구나 지켜야 하는 기본에 가깝습니다.
기능은 나중이 아니라
설계에서 갈립니다
기능 화면을 만들 때 순서를 지키면 대부분의 사고가 예방됩니다. 코드를 잘 쓰는 문제가 아니라 만들기 전에 정하는 문제이므로, 비개발자도 충분히 판단할 수 있는 영역입니다.
-
1단계 · 최소 수집무엇을 받을지부터 줄입니다
이름과 연락처, 증상 한 줄이면 상담을 시작할 수 있습니다. 받지 않은 정보는 새어 나갈 수도 없으므로, 항목을 줄이는 것이 가장 값싼 보안입니다.
-
2단계 · 검증된 부품직접 만들지 않아도 되는 것을 가려냅니다
로그인과 인증은 이미 검증된 방식을 빌려 씁니다. 직접 만들면 시간도 더 들고 위험도 더 큽니다 — 이 판단이 실력의 차이를 만듭니다.
-
3단계 · 열쇠는 금고에비밀 값을 코드에서 분리합니다
Secret Manager에 값을 두고 코드에는 이름만 남깁니다. 이 습관 하나로 가장 흔한 사고 유형이 사라집니다.
-
4단계 · 권한 나누기누가 무엇까지 볼 수 있는지 정합니다
관리자 화면은 주소를 숨기는 것이 아니라 잠급니다. 원내에서도 담당에 따라 볼 수 있는 범위를 나누어 두면 사고의 크기가 줄어듭니다.
네 단계 모두 코드를 쓰기 전에 내리는 결정입니다. 그래서 이 대목은 개발 실력의 문제가 아니라 무엇을 아느냐의 문제이고, 알고 나면 AI에게 내리는 지시도 함께 정확해집니다.
판단 기준은 여기에,
구현은 교육에서
이 문서는 네 화면이 무슨 일을 하고 무엇을 먼저 정해야 하는지까지를 다룹니다. 실제로 로그인을 붙이고 예약 데이터를 설계하며 열쇠를 금고에 넣는 작업, 그리고 권한이 잘못 열렸을 때 확인하는 방법은 교육에서 함께 다룹니다. 잘못 따라 하면 사고로 이어지는 영역이라 글로만 옮기지 않습니다.
기능에서 가장 많이 묻는 것들
로그인 기능은 직접 만들어야 하나요
직접 만들지 않는 편이 안전합니다. 비밀번호를 저장하고 검증하는 일은 잘못 만들면 그대로 사고가 되므로, 구글 계정 로그인처럼 검증된 방식을 붙이는 것이 표준입니다. 외국인 환자 예약에 구글 계정을 쓰는 이유도 같습니다 — 전 세계 공통 계정이라 별도 가입이 필요 없습니다.
예약 기능을 직접 붙일 수 있나요
가능합니다. 다만 국내 환자의 예약은 네이버 예약이 이미 익숙한 길이고, 네이버 예약은 네이버 안에서 관리되어 외부 홈페이지 데이터베이스로 넘어오지 않습니다. 그래서 직접 만드는 예약은 네이버가 감당하지 못하는 자리 — 외국인 환자와 시차 — 에 두는 편이 실속 있습니다.
AI가 만든 코드에 열쇠가 들어 있는지 어떻게 아나요
코드 안에 길고 무작위한 문자열이 그대로 적혀 있다면 대개 열쇠입니다. 습관을 하나 정해 두시는 편이 낫습니다 — 저장소에 올리기 전에 그런 문자열이 있는지 확인하고, 있다면 값을 금고로 옮긴 뒤 그 열쇠는 폐기하고 새로 발급받는 것입니다. 한 번 공개된 열쇠는 지워도 되살릴 수 없습니다.
만들어 놓은 뒤 유지보수는 어떻게 하나요
화면의 글과 사진을 바꾸는 일은 어렵지 않습니다. 손이 가는 쪽은 기능이 늘어난 뒤입니다 — 예약이 늘면 데이터가 쌓이고, 외부 서비스의 정책이 바뀌면 연결을 손봐야 합니다. 그래서 처음에 기능을 적게 두고 필요할 때 늘리는 편이 오래 갑니다.
어디까지 직접 하고 어디부터 맡기는 것이 좋을까요
기준을 하나로 잡자면 고칠 사람이 곁에 있는가입니다. 소개와 진료 안내처럼 자주 고치는 화면은 직접 만드시는 편이 유리하고, 결제나 민감한 개인정보가 오가는 기능은 책임의 소재가 분명한 선택이 낫습니다. 병원 홈페이지는 대부분 앞쪽에 속합니다.
네 화면을 함께 넘어 보시려면
교육에서는 환경 설정을 마친 환경 위에서 기능 화면의 구조를 함께 봅니다. 벽의 위치를 알고 넘는 것과 모르고 부딪히는 것은 걸리는 시간이 크게 다릅니다.
교육 과정 보기