바이브코딩으로 병원에서 사용할 SaaS 직접 만들어서 서비스까지
바이브코딩 툴(거의 클로드 코드)를 사용해서 병원에서 사용하는 주사제 일정 관리 앱을 만들고 서비스하기 까지 과정을 소개하려고 합니다.
현재 병원에서 잘 쓰고 있고 다음 프로젝트는 정말로 에이전틱 ai를 의료 데이터에 접목시켜 보려고 구상하고 있습니다. (진료 기록과 RAG의 만남)
결론부터 바로 가면 이 앱을 만들었습니다. 도메인 보면 아시겠지만 일단은 vercel을 그대로 쓰고 있어요. 나중에 성공하면 고유도메인 하나사서 갈아탈까 싶습니다. 글을 쓰면서 혹시나 이런 것들에 익숙치 않은 분들을 위해 blockquote로 달아두겠습니다.
vercel: 아주 쉽게 웹에 배포할 수 있게 도와주는 서비스. 일단 무료
랜딩페이지는 크게 신경쓰지 않고 클로드코드가 만들어준 초안을 그대로 가져갔습니다. 저는 기능에 관심이 있고 디자인은 전혀 감이 없어서요. prd 문서 만들어서 넣어줬고 그걸 토대로 만들어진 랜딩 페이지에 거의 손을 안댔습니다.
PRD(Product requirements document): 프로덕트에서 필요한 사항들을 기술해둔 문서
로고는 GPT로 적당히 돌려서 만들었습니다. 지금이면 나노바나나로 만들어볼 것 같네요.
앱 내부를 한번 둘러볼까요?
관리자 계정이라 사이드바에 뭐가 많습니다. 이렇게 활동 로그 보이게도 해뒀고요. 화면에 보이는 데이터는 신경안쓰셔도 됩니다. 시연용으로 더미기관과 더미 데이터를 하나 만들어뒀습니다. 병원 간 데이터는 당연히 분리해야 해서 다기관 사용이 가능하도록 구조를 만들었거든요(multi-tenancy라고 하네요.)
적당히 둘러보면 이렇게 스케줄이 있고 그걸 관리하는 스케줄러입니다.
이걸 만들게 된 이유는 관리하는 부서에서 이걸 일일이 손으로 계산하거나 엑셀 수식으로 계산해서 넣거나 각자만의 방식으로 하고 있는데 그러다보니 데이터의 연결이 잘 안되더라구요. 그 문제를 하나의 플랫폼으로 관리해서 해결하려고 만들었습니다.
기능으로만 보면 굉장히 심플합니다. 특정주기마다 실행 해야하는 일정이 있고, 그걸 7일전부터 미리 알려주고, 예정일보다 늦어지면 연체로 표시. 거기에 확인 버튼 누르면 자동으로 다음 주기 날짜 계산해서 새로 일정 등록까지. 하지만 이런 걸 직접 해보신 분들이라면 아마 이 단순한 기능을 구현하기 위해 얼마나 많은 코드들이 필요한지 아실 겁니다.
달력으로 보기 가능하구요.
자주 쓰는 일정 템플릿으로 만들어서 관리
통계 등도 볼 수 있습니다.
여기에 이걸 사용하는 사람이 관리자, 주치의, 간호사로 역할이 나뉘고 역할에 따라 보이는 화면, 기능 분리도 되어 있습니다. 이런 부분이 좀 복잡했던 것 같아요. 그리고 여기엔 안보이지만 채널톡으로 문의하기 라던지 지정된 일정에서 3~4일 전 안내 문자 발송 자동화 기능도 구현되어 있습니다.
어떻게 만들었을까
일단 순수 바이브코딩입니다. 개발 전 과정은 제가 클로드코드와 제미나이, 챗지피티를 사용해서 혼자 만들었습니다. 많은 분들이 아시는 Cursor맛피아 님이 코드베이스를 보고 한번 피드백을 주셨습니다.
비개발자도 '해줘'만 하면 뚝딱...까지는 아닌 것 같아요. 코딩언어 공부를 안했을뿐 이걸 만드는 과정에서 공부를 많이 했습니다. 바이브 코딩은 아무것도 몰라도 된다보다는 다른 걸 공부해야한다가 아닐까 싶네요.
대략 과정을 복기해보면
일단 requirements문서를 만들었습니다. 괜히 영어로 쓰면 뭔가 양식이 있을 것 같지만 그냥 내가 무엇을 원하는 가를 나열하는 정도였습니다.
지금 일정을 각자 제멋대로 관리하니까 통합 플랫폼이 필요하다.
가장 중요한 건 여러 종류의 주사제에 따라 주기가 다르고 그 주기를 자동을 계산해 사람이 그걸 일일이 계산해야하는 수고를 덜어주는 것이 목적이다.
의사들은 자기 담당환자들을 우선으로 볼 수 있어야 한다.
간호사는 본인의 소속 부서 환자들을 우선으로 볼 수 있어야 한다.
이런 식으로 생각나는 대로 쭉 나열해서 썼습니다. 하다보면 미리 설계 단계에서 꼼꼼하면 꼼꼼할수록 뒤에 고생을 덜합니다...만은 어쩔 수 없는 거 같아요. 하다보면 qa도 하고, 설계 때는 몰랐던 불편한 부분, 생각지도 못했던게 보이고 하거든요. ai와 티키타카 하면서 가능한 많은 사용자 여정을 미리 그려두면 그래도 편합니다.
그리고 기획할 때는 어느 정도 타협은 해야하지만 꿈은 좀 크게 꿔두는게 좋은 것 같습니다. 저는 이전에 mvp로 몇개 만들어본 적이 있어서 이걸 만들 때 일단 무조건 최소로 필요한 기능만 빠르게 구현해야지 하고 정말 최소화 설계를 했거든요. 기억나는 문제라면, 분명 언젠가 서비스를 확대할거고 그러면 다기관 사용이 가능하도록 데이터베이스에 기관을 기록하는 항목을 두고 거기에서 차곡차곡 쌓아야할텐데 무조건 최소화!를 외치고 DB에 기관 항목을 안만들고 시작했습니다. 건물로 치면 기초공사 때 해야하는 부분을 넘어갔던거죠. 그렇게 단일 기관에서 사용할 때는 아무런 문제 없이 행복했지만 이제 다른 곳에서도 사용할 수 있게 만들어야 하는 순간이 왔습니다. 집은 그대로 있는데 그 집을 유지하면서 밑에 기초를 하나 더 하는 느낌인데요...2주 정도를 하루에 10시간 가까이 작업해야했습니다. 저도 이렇게까지 자세하게 알고 싶진 않았어요...
바이브코딩도 여러 방법론이 있더라구요. 저는 그 중에 한가지 방법론을 배웠고 그 방식으로 만들었습니다. requirements를 만들면 이걸 토대로 prd 문서를 만들고 여기서 userflow 문서, database 스키마 문서를 만들었습니다. 내 요구사항을 토대로 프로덕트가 필요한 것들에 대한 문서를 만든 다음 이를 기반으로 사용자들은 어떻게 사용하는지, 그 뒤의 데이터 베이스의 설계는 어떻게 되는지 SOT(source of truth)라는 근거 문서를 만드는 과정입니다.
처음보는 용어라 굉장히 복잡해보이지만 사실상 여기서 제가 직접 작성한 건 requirements 문서 하나 뿐입니다. 잘 짜여진 프롬프트가 있으면 'requirements.md 파일을 읽은 다음 ...해서 prd문서를 만들어줘.', 'prd.md파일을 읽은 다음 ...해서 userflow.md, database.md파일을 만들어줘.' 이런 식으로 하나하나 쌓아나가면 됩니다.
그리고 사실 이걸 만드는 중에 클로드 스킬이 나왔거든요. requirements.md만 작성한 다음 스킬을 잘 설정해서 SOT 문서 생성, 그 문서 읽고 페이지 나누기, 페이지별 기능 나누기, 상태(state) 평가 문서 작성, 구현 계획 작성, 구현 계획 토대로 구현, 구현 후 제대로 구현되었는지 확인, qa 테스트까지 사실상 머릿속에 있는 모든 과정을 한번에 시킬 수 있습니다. 중간에 확인 과정을 생략하도록 하면 혼자서 1~2시간 일하고 일단은 계획한 것들이 구현되었다고 주장하는(?) 결과물이 만들어집니다. 여기에 서브에이전트를 미리 만들어서 스킬이 사용할 수 있게 쥐어주면 더 좋고요.
해보지 않은 분들에게는 여전히 뜬구름 잡는 느낌일거라는 건 이해합니다. 저도 그랬거든요. 처음 클로드 스킬 써보기전까진 저도 유튜브 영상, 영상 요약본만 보면서 해볼까말까 고민만 몇주를 했거든요. 해보면, 정말 쉽습니다. 클로드에 스킬을 만드는 스킬도 있거든요. 그거 써서 내가 이런 작업을 하는 스킬을 만들거고, 이 스킬에 사용할 서브에이전트도 같이 만들고 싶다고 하면 어떤 작업을 할지 명확하게 설명만 잘했다면 꽤 훌륭한 스킬이 만들어집니다. 이 부분은 직접 경험해보기 전까진 가늠이 안될 수 있으니 설명은 이만하면 될 것 같습니다.
여기까지 했다면 그 다음은 디버깅 과정입니다. 사실 여기서부터 정말 많은 시간과 노력이 들어갑니다. 한번에 제대로 구현은 아직 안되거든요. 그래서 유튜브 같은데 보면 바이브 코딩 허상이다 막상 해보면 안된다 이런 이야기가 많나 봅니다. 하지만 딸깍!으로 만드는게 안된다는 거지 붙잡고 욕하면서 뒹굴다보면 또 어떻게 돌아가게는 할 수 있습니다. 그리고 희망적인 건 제가 소넷 4.0 때 바이브코딩을 시작했는데 그때보다 클로드에게 화내고 욕하는(!) 빈도가 훨씬 줄었습니다. 하다보면 늪에 빠질 때가 있거든요. '이게 문제입니다.->실수 했습니다. 저게 문제였습니다.->어 아니네요. 아까 그 문제인거 같은데요?' 이 루프에 한번 걸리면 시간, 토큰이 정말 사라집니다. 그런데 요즘 점점 그런 일이 줄고 있어요. 저 문제의 원인은 보통 나쁜 코드를 만든게 조금씩 누적되면서 잘못된 context로 오염이 되서 저러는 건데, 아주 조금은 제 경험이 쌓이면서 나쁜 컨텍스트가 쌓이지 않게 관리해서도 있겠지만 더 좋은 모델, 클로드라면 opus 4.5라서 일겁니다.
그리고 앞으로 더 좋은 모델들이 나올테고 점점 더 쉬워질거라 생각합니다. 딸깍으로 안만들어진다고 이야기하고 있지만 결국 우리가 꿈꾸는 미래는 딸깍으로 만들어내는 세상 아니겠습니까.
그리고 얼마전 구글에서 antigravity를 출시 했는데 이 것도 아주 좋습니다. 원래도 gemini 2.5가 입력 토큰을 많이 줘서 전체 코드베이스 리뷰 시키기 좋았거든요. 그런데 더 성능이 좋은 3.0이 나왔죠. antigravity 에이전트 매니저 창에서 전체 코드베이스에 대한 리뷰를 gemini 3.0에게 시켜서 전체적인 오류나 개선 제안을 받고 editor 창에서 터미널 열고 클로드코드로 작업 시키니까 아주 쾌적하고 좋습니다.
이런 좋은 툴들이 계속 나오고 있어서 공부할 것도 많지만 점점 편해진다는 걸 느끼고 있습니다.
결과와 배운 점
아주 텍스트로 가득한 글이지만 읽어주셨다면 감사하고 혹시 소개한 앱 더미기관으로 로그인해서 기능들을 한번 둘러보고 싶으시다면 웹페이지에 채널톡으로 문의 주셔도 되고 아니면 저에게 쪽지 주시면 로그인할 수 있게 데모용 아이디, 비번을 알려드리겠습니다.