이전 글에서 클로드 코드를 소개했었는데, 이번엔 직접 써본 이야기입니다. 참고로 저는 코딩을 모르는 디자이너예요.
그런 제가 클로드 코드와 함께, 실제로 운영 중인 업무용 웹앱을 2개 만들었습니다. 추가 개발 비용은 0원이었고요.
하나는 숙소 예약을 관리하는 시스템, 다른 하나는 공유차량 운영을 관리하는 서비스예요.
둘 다 기존에 불편하게 돌아가던 업무를 직접 해결한 프로젝트입니다. 하나씩 보여드릴게요.
1. 첫 번째 프로젝트 — 숙소 예약관리 시스템
저희 팀은 숙소 예약 관리를 먼데이와 구글 시트, 두 곳에서 하고 있었어요.
내부 관리는 먼데이, 외부 공유는 구글 시트. 같은 예약 데이터를 두 번 입력하고, 두 곳을 번갈아 확인하는 이중 작업을 반복하고 있었습니다.
먼데이와 구글 시트 모두 훌륭한 도구이지만, 숙소 예약 관리라는 우리 상황에는 맞지 않는 부분이 있었어요.
숙소가 여러 개인데 리스트 형태로만 볼 수 있어서, 특정 날짜에 어떤 방이 비어 있는지 한눈에 알 수 없었고요.
같은 프로그램에 참여하는 여러 명을 한 명씩 개별 등록해야 해서 시간이 많이 들었어요.
관리자와 현장 담당자가 같은 화면을 보다 보니, 굳이 볼 필요 없는 정보까지 공유되는 것도 아쉬웠습니다.
모바일에서도 확인은 가능하지만, 작은 화면에서 시트를 옆으로 쭉 넘겨가며 봐야 하고,
예약 관리에 특화된 기능이 없다 보니 현장에서 빠르게 처리하기엔 불편했고요.
정리하면, 도구가 나쁜 게 아니라 우리 업무에 딱 맞는 도구가 필요했던 거예요.
그런데 개발자가 아니니까 직접 만들 수는 없잖아요.
왼쪽에 숙소 이름, 위에 날짜, 그리고 예약이 색상 바로 표시됩니다.
프로그램별로 색이 다르게 들어가서, 이번 주에 어떤 프로그램이 진행 중인지도 바로 알 수 있어요.
그런데 예쁘기만 한 게 아니라, 실제 업무를 바꿔놓은 기능들이 들어가 있어요. 하나씩 소개해볼게요.
* 개인정보로 인해 관리자용으로 보여드리지 않는 점 양해부탁드립니다.
하나. 먼데이와 실시간 양방향 연동.
이게 가장 큰 장점이에요. 웹앱에서 예약을 등록하면 먼데이에 자동으로 반영되고, 먼데이에서 수정한 내용도 웹앱에 그대로 나타나요.
예전처럼 같은 데이터를 두 곳에 따로 입력할 필요가 없어졌습니다. 이중 작업이 사라진 거예요.
둘. 캘린더 한눈에 보기
여러 숙소의 예약 현황이 하나의 화면에 다 보여요. 리스트를 하나씩 스크롤하며 찾던 시절은 끝났습니다.
특정 날짜에 어떤 방이 비어 있는지, 이번 주에 체크인·체크아웃이 몇 건인지, 캘린더만 보면 바로 알 수 있어요.
셋. 드래그로 여러 명 한번에 등록.
같은 프로그램 참여자 5명을 등록해야 할 때, 예전에는 한 명씩 5번 입력했어요.
이제는 캘린더에서 날짜 범위를 드래그하면 등록 폼이 뜨고, 한 번에 처리됩니다.
넷. 역할별로 다른 화면.
같은 시스템인데 보는 사람에 따라 화면이 달라요.
관리자는 게스트 이름과 상세 정보까지 볼 수 있지만, 청소팀은 인원수와 침구 정보만 보여요.
불필요한 개인정보가 노출되지 않도록 역할별로 나눈 거예요.
다섯. 모바일에서도 바로 확인
현장에서 급하게 예약을 확인하거나 변경해야 할 때, PC를 찾아갈 필요 없이 휴대폰으로 바로 처리할 수 있어요.
여섯. 대시보드로 한눈에 파악. 이번 달 예약이 총 몇 건인지, 프로그램별 비율은 어떤지, 주간 체크인·체크아웃 현황은 어떤지 —
따로 집계할 필요 없이 대시보드에서 자동으로 보여줍니다.
이 모든 게 파일 5개, 코드 약 3,500줄로 돌아가고 있어요. 순수 작업 시간으로 따지면 30시간이었습니다.
2. 두 번째 프로젝트 — 러카 (공유차량 관리 서비스)
첫 번째 프로젝트를 끝내고 나니, 또 다른 불편이 눈에 들어왔어요.
저희 팀은 공유차량도 운영하고 있는데, 예약부터 반납까지 전부 카카오톡 오픈채팅방에서 수동으로 처리하고 있었거든요.
이용자가 "러카 이용 가능할까요? 3/2일 15:00~17:00 마트 다녀오려고 합니다!" 형식으로 메시지를 보내면, 운영진이 확인하고 답변해요.
면허 확인은 개인정보 보호 때문에 1:1 대화로 따로 받아야 했고요.
출발할 때 차량 외부 4면, 내부 2장, 계기판까지 총 7장의 사진을 오픈채팅방에 올려야 하고, 반납할 때도 마찬가지로 8장.
정리하면 이런 상황이었어요.
- 예약: 오픈채팅방에 정해진 형식으로 메시지 면허 확인: 1:1 대화로 별도 전송
- 승인: 운영진이 채팅으로 직접 답변
- 사진 관리: 출발·반납 사진을 오픈채팅방에 직접 업로드
- 예약 겹침: 운영진이 수동으로 확인 ...
운영진은 모든 과정을 수동으로 처리해야 했고, 이용자 입장에서는 1:1 대화와 오픈채팅방이 나뉘어져 있어서 창구가 이원화돼 있었어요.
이용 절차도 직관적이지 않았고요 — 위키 페이지를 읽고, 메시지 형식을 맞춰야 했으니까요.
이걸 하나의 전용 앱으로 만들었습니다.
하나. 캘린더에서 빈 시간 확인하고 바로 예약
오픈채팅방에 메시지를 보내는 대신, 캘린더에서 날짜와 시간을 선택하면 끝. 다른 사람 예약과 겹치는지도 시스템이 자동으로 체크해줍니다.
둘. 면허 등록과 예약을 한 곳에서.
예전에는 1:1 대화로 면허증을 따로 보내야 했는데, 이제는 앱 안에서 면허증 사진을 등록하면 돼요.
운영진은 관리자 화면에서 확인하고 원클릭으로 승인하거나 반려할 수 있고요.
셋. 사진 업로드도 앱 안에서.
출발 전 차량 사진 7장, 반납 시 8장을 앱 안에서 바로 촬영·업로드할 수 있어요.
어떤 사진을 찍어야 하는지 가이드도 화면에 나와서, 따로 설명을 찾아볼 필요가 없습니다.
무엇보다 모든 사람이 보는 오픈채팅방에 올리지 않아도 된다는 게 가장 큰 변화예요. 사진은 예약별로 체계적으로 저장됩니다.
넷. 운영진은 관리자 대시보드에서 한눈에.
승인 대기, 오늘 현황, 전체 예약, 회원 관리가 탭으로 정리돼 있어요.
슬랙 알림 연동도 돼 있어서, 누군가 예약을 신청하면 운영진에게 자동으로 알림이 갑니다.
다섯. 역할에 따라 다른 화면.
예약관리 시스템과 마찬가지로, 운영자와 이용자가 보는 화면이 다릅니다.
이용자에게는 관리 기능이 보이지 않고, 운영자에게만 승인·회원 관리 메뉴가 나타나요.
여섯. 로그인할 때마다 이용안내 확인 필수.
이용 조건, 주의사항, 사진 촬영 가이드가 앱 안에 들어가 있고, 매 로그인 시 확인 동의를 거쳐야 사용할 수 있어요.
예전에는 별도 위키 페이지를 읽어야 했는데, 이제 앱 하나로 끝납니다.
이 프로젝트는 순수 작업 시간으로 따지면 23시간이 걸렸어요.
첫 번째보다 시간이 더 들었는데, 이번에는 여러 이용자가 함께 쓰는 서비스였기 때문이에요.
회원가입, 권한 분리, 사진 업로드, 보안까지 신경 쓸 게 훨씬 많았습니다.
3. 어떻게 만들었냐고요? 말로 했습니다.
두 프로젝트 모두, 제가 한 건 "이런 게 필요해"라고 설명한 거예요. 코드는 클로드 코드가 짰습니다. 과정은 대략 이랬어요.
"숙소 예약 현황을 캘린더처럼 한눈에 보고 싶어. 왼쪽에 숙소 이름, 위에 날짜, 예약이 색상 바로 보이게."
그러자 숙소×날짜 그리드가 만들어졌어요.
"공유차량 예약할 때 다른 사람 예약이랑 겹치면 안 돼. 시간대별로 빈 시간을 보여줘."
타임라인 기반 예약 시스템이 생겼습니다.
"관리자와 이용자가 보는 화면을 다르게 해줘."
로그인에 따라 다른 UI가 나오도록 만들어졌어요.
한 가지 팁이 있다면, 저는 처음에 클로드 코드에게 "나는 비개발자야, 차근차근 설명해줘"라고 알려줬어요.
그랬더니 전문 용어 대신 이해하기 쉬운 말로 바꿔서 안내해주고, 한 번에 다 하지 않고 단계별로 진행할 수 있게 도와줬어요.
처음 한 번 눈높이를 맞춰주면, 그다음부터는 알아서 제 수준에 맞게 대화해줍니다.
그리고 놀라웠던 건, 클로드 코드가 코딩 바깥의 작업까지 직접 처리해준 것이에요.
완성된 코드를 GitHub에 올리고, Vercel이라는 플랫폼에 배포하는 과정을 제가 하나하나 한 게 아니라,
클로드 코드가 터미널에서 명령어를 실행하면서 직접 처리해줬어요. 코드를 쓰는 것뿐 아니라 등록, 배포, 설정 같은 작업까지 대신해주는 거죠.
(다만 클로드 코드가 브라우저를 직접 제어하려면, 터미널에서 관련 도구를 설치하는 등 몇 가지 초기 설정이 필요하긴 합니다.)
러카에서는 슬랙 알림 연동도 클로드 코드가 해줬어요.
"누군가 예약하면 운영진 슬랙에 알림이 갔으면 좋겠어"
라고 말했더니, 연동까지 완성해줬습니다.
이전 글에서 소개한 바이브 코딩 기억하시나요? "코드를 직접 쓰지 않고, 원하는 걸 말로 설명하면 AI가 만들어준다"는 개념이요.
이 두 프로젝트가 바로 그 바이브 코딩의 실전 사례인 셈이에요.
4. 숫자로 정리하면 이렇습니다.
| 항목 | 예약관리시스템 | 러카 (카셰어링) |
| 추가 개발 비용 | 0원 | 0원 |
| 소요 시간 | 30시간 | 23시간 |
| 주요 버그 수정 | 21건 | CRITICAL 3건 + MEDIUM 9건 |
| 보안 점검 | 포함 (28번 수정) | 포함 (코드 감사 완료) |
'비개발자가 업무용 웹앱 2개를, 외부 개발자 없이 0원에 만들었다.' 글로 쓰면 이상하게 들리는데, 진짜 그렇게 됐습니다.
참고로 클로드 코드는 무료 플랜에서는 사용할 수 없어요.
다만 이런 프로젝트처럼 코드량이 많고 여러 차례 수정을 거치는 작업에는 사용량이 넉넉한 플랜이 편했습니다.
5. 직접 테스트하고, 직접 고쳤습니다.
사실 코드를 만드는 것보다 더 많은 시간이 든 건 테스트와 검수였어요. 비개발자에게 디버깅은 쉽지 않습니다.
코드를 읽을 수 없으니 어디가 문제인지 직접 찾아 들어갈 수가 없어요. 에러 메시지를 봐도 뭔 소린지 모르고요.
그래서 보통은 "개발자 아니면 고칠 수 없다"고 생각하기 쉬운데, 저는 다른 방식으로 접근했어요.
증상을 정확하게 설명하는 것. 그게 제가 할 수 있는 디버깅이었습니다.
화면이 나오면 직접 이것저것 눌러보고, 예약을 등록해보고, 수정해보고, 삭제해보면서 이상한 점을 하나씩 찾았어요.
버그를 발견하면 클로드 코드에게 증상을 설명했습니다.
"달력에서 3월 예약이 2월에 표시돼요."
"예약 수정 후 목록이 새로고침이 안 돼요."
"드래그로 등록할 때 마지막 날짜가 하루 빠져요."
이렇게 뭐가, 언제, 어떻게 이상한지를 구체적으로 전달하면, 클로드 코드가 원인을 찾아 수정해줬어요.
저는 다시 같은 상황을 재현해서 고쳐졌는지 확인하고요.그런데 여기서 멈추지 않았어요.
눈에 보이는 문제만 고치는 게 아니라, 전체 기능을 처음부터 끝까지 하나씩 점검했습니다.
예약 등록, 수정, 삭제가 정상 작동하는지. 날짜를 이상하게 입력하면 어떻게 되는지. 같은 방에 예약이 겹치면 어떻게 처리되는지.
관리자 화면과 이용자 화면에 각각 맞는 정보만 나오는지. 모바일에서 깨지는 건 없는지.
클로드 코드에게 전체 코드를 점검해달라고 요청하기도 했고요. 이렇게 보이는 버그 수정 + 전체 검수를 함께 진행했어요.
보안 부분도 인상적이었어요.
예약관리 시스템에서는 제가 따로 요청하지 않았는데 클로드 코드가 스스로 "이 부분은 보안상 위험할 수 있어요"라고 알려줬어요.
러카에서는 제가 보안 점검을 요청했더니, CRITICAL 3건을 포함해 12건의 보안 이슈를 찾아서 수정해줬고요.
어디가 왜 위험한지, 어떻게 고치면 되는지까지 친절하게 설명해줘서, 저도 "아, 이건 고쳐야 하는 거구나"를 이해할 수 있었습니다.
비개발자 혼자였다면 보안 문제가 있다는 사실조차 몰랐을 거예요. 클로드 코드가 개발 파트너이자 동시에 검수자 역할까지 해준 셈이에요.
코드를 읽을 줄 몰라도, 사용자 입장에서 "이건 이상한데?"를 판단하는 건 할 수 있었어요.
오히려 개발자가 아니기 때문에 기술적 관점이 아닌 실사용자 관점에서 더 꼼꼼하게 테스트한 부분도 있었다고 생각합니다.
개발자라면 "이 정도면 되겠지" 하고 넘길 수 있는 부분도, 저는 실제로 매일 이 시스템을 쓸 사람이니까 하나하나 확인할 수밖에 없었거든요.
결과적으로 이 시스템들은 "급하게 만든 프로토타입"이 아니라, 실제 업무에서 매일 쓰이고 있는 운영 도구가 됐습니다.
6. 솔직히, 쉽지만은 않았어요.
2개나 만들었다고 하면 "와 순탄하게 됐나 보다" 싶을 수 있는데, 전혀 그렇지 않았어요.
AI 도구를 쓰는 방법뿐 아니라, 그 이전 단계에서도 실수가 있었습니다.
방향을 잘못 잡으면 시간을 잃습니다.
사실 예약관리 시스템은 처음부터 지금 모습이 아니었어요.
저는 팀에 제대로 확인하지 않고 혼자 판단해서 청소관리 시스템으로 만들기 시작했거든요.
청소팀과 공유하는 것에 초점을 맞춰서 거의 다 만들었는데, 팀과 이야기하고 나서야 "이건 예약관리가 중심이어야 하는데"라는 걸 깨달았어요.
다행히 기존 작업이 있어서 전환 자체는 하루 정도 걸렸지만, 처음부터 팀과 확실하게 소통하고 내가 정확히 인지한 뒤 작업했다면
아끼지 않아도 될 시간이었어요. AI에게 뭘 시키든, "뭘 만들 건지"를 목적을 분명히하는 것이 가장 중요하다는 걸 이때 배웠습니다.
프로젝트별로 대화를 나눠라.
이전 글에서 소개한 실패 패턴 중 "한 대화에서 이것저것 시키기"라는 게 있었는데, 저는 이걸 미리 방지했어요.
프로젝트마다 각각의 대화와 작업 폴더를 분리해서 진행했습니다. 예약관리 시스템 대화에서 러카 이야기를 하지 않고, 러카 대화에서 예약관리를 건드리지 않았어요. 이렇게 하니까 대화가 꼬이거나 결과물이 엉키는 일 없이 깔끔하게 진행할 수 있었습니다.
그대로 믿으면 안 됩니다.
AI가 만든 결과물이 겉으로는 멀쩡해 보여도, 실제로 돌려보면 안 되는 부분이 있었어요.
"작동하는 것 같다"와 "실제로 작동한다"는 다르다는 걸 배웠어요.
그래서 앞서 이야기한 것처럼 직접 하나하나 테스트하고 검수하는 과정이 꼭 필요했습니다.
결국 AI는 만능이 아니라, 함께 문제를 풀어가는 도구라는 걸 다시 한번 느꼈습니다.
다만 그 속도가 사람 혼자 할 때와는 비교할 수 없을 만큼 빨랐을 뿐이에요.
마치며,
코딩을 모르는 사람도 자기 업무에 딱 맞는 도구를 직접 만들 수 있다는 것.
하나를 만들고 나면, "이것도 만들 수 있겠는데?"라는 생각이 자연스럽게 든다는 것.
물론 AI가 다 해주는 건 아니에요.
뭘 만들고 싶은지 명확하게 정리하는 건 사람의 몫이고, 결과물을 검증하는 것도, 방향을 잡는 것도 결국 사람이 해야 해요.
하지만 그 사이의 실행, 예전에는 전문가에게 맡기거나 포기해야 했던 그 부분을 AI가 메워주는 시대가 온 건 분명합니다.
이 시스템들은 지금도 실제로 쓰이고 있고, 계속 개선 중이에요.
앞으로도 새로운 시도가 있으면 이 플로그를 통해 공유하겠습니다.
긴 글 읽어주셔서 감사합니다. 🙏
이전 글에서 클로드 코드를 소개했었는데, 이번엔 직접 써본 이야기입니다. 참고로 저는 코딩을 모르는 디자이너예요.
그런 제가 클로드 코드와 함께, 실제로 운영 중인 업무용 웹앱을 2개 만들었습니다. 추가 개발 비용은 0원이었고요.
하나는 숙소 예약을 관리하는 시스템, 다른 하나는 공유차량 운영을 관리하는 서비스예요.
둘 다 기존에 불편하게 돌아가던 업무를 직접 해결한 프로젝트입니다. 하나씩 보여드릴게요.
1. 첫 번째 프로젝트 — 숙소 예약관리 시스템
저희 팀은 숙소 예약 관리를 먼데이와 구글 시트, 두 곳에서 하고 있었어요.
내부 관리는 먼데이, 외부 공유는 구글 시트. 같은 예약 데이터를 두 번 입력하고, 두 곳을 번갈아 확인하는 이중 작업을 반복하고 있었습니다.
먼데이와 구글 시트 모두 훌륭한 도구이지만, 숙소 예약 관리라는 우리 상황에는 맞지 않는 부분이 있었어요.
숙소가 여러 개인데 리스트 형태로만 볼 수 있어서, 특정 날짜에 어떤 방이 비어 있는지 한눈에 알 수 없었고요.
같은 프로그램에 참여하는 여러 명을 한 명씩 개별 등록해야 해서 시간이 많이 들었어요.
관리자와 현장 담당자가 같은 화면을 보다 보니, 굳이 볼 필요 없는 정보까지 공유되는 것도 아쉬웠습니다.
모바일에서도 확인은 가능하지만, 작은 화면에서 시트를 옆으로 쭉 넘겨가며 봐야 하고,
예약 관리에 특화된 기능이 없다 보니 현장에서 빠르게 처리하기엔 불편했고요.
정리하면, 도구가 나쁜 게 아니라 우리 업무에 딱 맞는 도구가 필요했던 거예요.
그런데 개발자가 아니니까 직접 만들 수는 없잖아요.
왼쪽에 숙소 이름, 위에 날짜, 그리고 예약이 색상 바로 표시됩니다.
프로그램별로 색이 다르게 들어가서, 이번 주에 어떤 프로그램이 진행 중인지도 바로 알 수 있어요.
그런데 예쁘기만 한 게 아니라, 실제 업무를 바꿔놓은 기능들이 들어가 있어요. 하나씩 소개해볼게요.
* 개인정보로 인해 관리자용으로 보여드리지 않는 점 양해부탁드립니다.
하나. 먼데이와 실시간 양방향 연동.
이게 가장 큰 장점이에요. 웹앱에서 예약을 등록하면 먼데이에 자동으로 반영되고, 먼데이에서 수정한 내용도 웹앱에 그대로 나타나요.
예전처럼 같은 데이터를 두 곳에 따로 입력할 필요가 없어졌습니다. 이중 작업이 사라진 거예요.
둘. 캘린더 한눈에 보기
여러 숙소의 예약 현황이 하나의 화면에 다 보여요. 리스트를 하나씩 스크롤하며 찾던 시절은 끝났습니다.
특정 날짜에 어떤 방이 비어 있는지, 이번 주에 체크인·체크아웃이 몇 건인지, 캘린더만 보면 바로 알 수 있어요.
셋. 드래그로 여러 명 한번에 등록.
같은 프로그램 참여자 5명을 등록해야 할 때, 예전에는 한 명씩 5번 입력했어요.
이제는 캘린더에서 날짜 범위를 드래그하면 등록 폼이 뜨고, 한 번에 처리됩니다.
넷. 역할별로 다른 화면.
같은 시스템인데 보는 사람에 따라 화면이 달라요.
관리자는 게스트 이름과 상세 정보까지 볼 수 있지만, 청소팀은 인원수와 침구 정보만 보여요.
불필요한 개인정보가 노출되지 않도록 역할별로 나눈 거예요.
다섯. 모바일에서도 바로 확인
현장에서 급하게 예약을 확인하거나 변경해야 할 때, PC를 찾아갈 필요 없이 휴대폰으로 바로 처리할 수 있어요.
여섯. 대시보드로 한눈에 파악. 이번 달 예약이 총 몇 건인지, 프로그램별 비율은 어떤지, 주간 체크인·체크아웃 현황은 어떤지 —
따로 집계할 필요 없이 대시보드에서 자동으로 보여줍니다.
이 모든 게 파일 5개, 코드 약 3,500줄로 돌아가고 있어요. 순수 작업 시간으로 따지면 30시간이었습니다.
2. 두 번째 프로젝트 — 러카 (공유차량 관리 서비스)
첫 번째 프로젝트를 끝내고 나니, 또 다른 불편이 눈에 들어왔어요.
저희 팀은 공유차량도 운영하고 있는데, 예약부터 반납까지 전부 카카오톡 오픈채팅방에서 수동으로 처리하고 있었거든요.
이용자가 "러카 이용 가능할까요? 3/2일 15:00~17:00 마트 다녀오려고 합니다!" 형식으로 메시지를 보내면, 운영진이 확인하고 답변해요.
면허 확인은 개인정보 보호 때문에 1:1 대화로 따로 받아야 했고요.
출발할 때 차량 외부 4면, 내부 2장, 계기판까지 총 7장의 사진을 오픈채팅방에 올려야 하고, 반납할 때도 마찬가지로 8장.
정리하면 이런 상황이었어요.
- 예약: 오픈채팅방에 정해진 형식으로 메시지 면허 확인: 1:1 대화로 별도 전송
- 승인: 운영진이 채팅으로 직접 답변
- 사진 관리: 출발·반납 사진을 오픈채팅방에 직접 업로드
- 예약 겹침: 운영진이 수동으로 확인 ...
운영진은 모든 과정을 수동으로 처리해야 했고, 이용자 입장에서는 1:1 대화와 오픈채팅방이 나뉘어져 있어서 창구가 이원화돼 있었어요.
이용 절차도 직관적이지 않았고요 — 위키 페이지를 읽고, 메시지 형식을 맞춰야 했으니까요.
이걸 하나의 전용 앱으로 만들었습니다.
하나. 캘린더에서 빈 시간 확인하고 바로 예약
오픈채팅방에 메시지를 보내는 대신, 캘린더에서 날짜와 시간을 선택하면 끝. 다른 사람 예약과 겹치는지도 시스템이 자동으로 체크해줍니다.
둘. 면허 등록과 예약을 한 곳에서.
예전에는 1:1 대화로 면허증을 따로 보내야 했는데, 이제는 앱 안에서 면허증 사진을 등록하면 돼요.
운영진은 관리자 화면에서 확인하고 원클릭으로 승인하거나 반려할 수 있고요.
셋. 사진 업로드도 앱 안에서.
출발 전 차량 사진 7장, 반납 시 8장을 앱 안에서 바로 촬영·업로드할 수 있어요.
어떤 사진을 찍어야 하는지 가이드도 화면에 나와서, 따로 설명을 찾아볼 필요가 없습니다.
무엇보다 모든 사람이 보는 오픈채팅방에 올리지 않아도 된다는 게 가장 큰 변화예요. 사진은 예약별로 체계적으로 저장됩니다.
넷. 운영진은 관리자 대시보드에서 한눈에.
승인 대기, 오늘 현황, 전체 예약, 회원 관리가 탭으로 정리돼 있어요.
슬랙 알림 연동도 돼 있어서, 누군가 예약을 신청하면 운영진에게 자동으로 알림이 갑니다.
다섯. 역할에 따라 다른 화면.
예약관리 시스템과 마찬가지로, 운영자와 이용자가 보는 화면이 다릅니다.
이용자에게는 관리 기능이 보이지 않고, 운영자에게만 승인·회원 관리 메뉴가 나타나요.
여섯. 로그인할 때마다 이용안내 확인 필수.
이용 조건, 주의사항, 사진 촬영 가이드가 앱 안에 들어가 있고, 매 로그인 시 확인 동의를 거쳐야 사용할 수 있어요.
예전에는 별도 위키 페이지를 읽어야 했는데, 이제 앱 하나로 끝납니다.
이 프로젝트는 순수 작업 시간으로 따지면 23시간이 걸렸어요.
첫 번째보다 시간이 더 들었는데, 이번에는 여러 이용자가 함께 쓰는 서비스였기 때문이에요.
회원가입, 권한 분리, 사진 업로드, 보안까지 신경 쓸 게 훨씬 많았습니다.
3. 어떻게 만들었냐고요? 말로 했습니다.
두 프로젝트 모두, 제가 한 건 "이런 게 필요해"라고 설명한 거예요. 코드는 클로드 코드가 짰습니다. 과정은 대략 이랬어요.
그러자 숙소×날짜 그리드가 만들어졌어요.
타임라인 기반 예약 시스템이 생겼습니다.
로그인에 따라 다른 UI가 나오도록 만들어졌어요.
한 가지 팁이 있다면, 저는 처음에 클로드 코드에게 "나는 비개발자야, 차근차근 설명해줘"라고 알려줬어요.
그랬더니 전문 용어 대신 이해하기 쉬운 말로 바꿔서 안내해주고, 한 번에 다 하지 않고 단계별로 진행할 수 있게 도와줬어요.
처음 한 번 눈높이를 맞춰주면, 그다음부터는 알아서 제 수준에 맞게 대화해줍니다.
그리고 놀라웠던 건, 클로드 코드가 코딩 바깥의 작업까지 직접 처리해준 것이에요.
완성된 코드를 GitHub에 올리고, Vercel이라는 플랫폼에 배포하는 과정을 제가 하나하나 한 게 아니라,
클로드 코드가 터미널에서 명령어를 실행하면서 직접 처리해줬어요. 코드를 쓰는 것뿐 아니라 등록, 배포, 설정 같은 작업까지 대신해주는 거죠.
(다만 클로드 코드가 브라우저를 직접 제어하려면, 터미널에서 관련 도구를 설치하는 등 몇 가지 초기 설정이 필요하긴 합니다.)
러카에서는 슬랙 알림 연동도 클로드 코드가 해줬어요.
라고 말했더니, 연동까지 완성해줬습니다.
이전 글에서 소개한 바이브 코딩 기억하시나요? "코드를 직접 쓰지 않고, 원하는 걸 말로 설명하면 AI가 만들어준다"는 개념이요.
이 두 프로젝트가 바로 그 바이브 코딩의 실전 사례인 셈이에요.
4. 숫자로 정리하면 이렇습니다.
'비개발자가 업무용 웹앱 2개를, 외부 개발자 없이 0원에 만들었다.' 글로 쓰면 이상하게 들리는데, 진짜 그렇게 됐습니다.
참고로 클로드 코드는 무료 플랜에서는 사용할 수 없어요.
다만 이런 프로젝트처럼 코드량이 많고 여러 차례 수정을 거치는 작업에는 사용량이 넉넉한 플랜이 편했습니다.
5. 직접 테스트하고, 직접 고쳤습니다.
사실 코드를 만드는 것보다 더 많은 시간이 든 건 테스트와 검수였어요. 비개발자에게 디버깅은 쉽지 않습니다.
코드를 읽을 수 없으니 어디가 문제인지 직접 찾아 들어갈 수가 없어요. 에러 메시지를 봐도 뭔 소린지 모르고요.
그래서 보통은 "개발자 아니면 고칠 수 없다"고 생각하기 쉬운데, 저는 다른 방식으로 접근했어요.
증상을 정확하게 설명하는 것. 그게 제가 할 수 있는 디버깅이었습니다.
화면이 나오면 직접 이것저것 눌러보고, 예약을 등록해보고, 수정해보고, 삭제해보면서 이상한 점을 하나씩 찾았어요.
버그를 발견하면 클로드 코드에게 증상을 설명했습니다.
이렇게 뭐가, 언제, 어떻게 이상한지를 구체적으로 전달하면, 클로드 코드가 원인을 찾아 수정해줬어요.
저는 다시 같은 상황을 재현해서 고쳐졌는지 확인하고요.그런데 여기서 멈추지 않았어요.
눈에 보이는 문제만 고치는 게 아니라, 전체 기능을 처음부터 끝까지 하나씩 점검했습니다.
예약 등록, 수정, 삭제가 정상 작동하는지. 날짜를 이상하게 입력하면 어떻게 되는지. 같은 방에 예약이 겹치면 어떻게 처리되는지.
관리자 화면과 이용자 화면에 각각 맞는 정보만 나오는지. 모바일에서 깨지는 건 없는지.
클로드 코드에게 전체 코드를 점검해달라고 요청하기도 했고요. 이렇게 보이는 버그 수정 + 전체 검수를 함께 진행했어요.
보안 부분도 인상적이었어요.
예약관리 시스템에서는 제가 따로 요청하지 않았는데 클로드 코드가 스스로 "이 부분은 보안상 위험할 수 있어요"라고 알려줬어요.
러카에서는 제가 보안 점검을 요청했더니, CRITICAL 3건을 포함해 12건의 보안 이슈를 찾아서 수정해줬고요.
어디가 왜 위험한지, 어떻게 고치면 되는지까지 친절하게 설명해줘서, 저도 "아, 이건 고쳐야 하는 거구나"를 이해할 수 있었습니다.
비개발자 혼자였다면 보안 문제가 있다는 사실조차 몰랐을 거예요. 클로드 코드가 개발 파트너이자 동시에 검수자 역할까지 해준 셈이에요.
코드를 읽을 줄 몰라도, 사용자 입장에서 "이건 이상한데?"를 판단하는 건 할 수 있었어요.
오히려 개발자가 아니기 때문에 기술적 관점이 아닌 실사용자 관점에서 더 꼼꼼하게 테스트한 부분도 있었다고 생각합니다.
개발자라면 "이 정도면 되겠지" 하고 넘길 수 있는 부분도, 저는 실제로 매일 이 시스템을 쓸 사람이니까 하나하나 확인할 수밖에 없었거든요.
결과적으로 이 시스템들은 "급하게 만든 프로토타입"이 아니라, 실제 업무에서 매일 쓰이고 있는 운영 도구가 됐습니다.
6. 솔직히, 쉽지만은 않았어요.
2개나 만들었다고 하면 "와 순탄하게 됐나 보다" 싶을 수 있는데, 전혀 그렇지 않았어요.
AI 도구를 쓰는 방법뿐 아니라, 그 이전 단계에서도 실수가 있었습니다.
방향을 잘못 잡으면 시간을 잃습니다.
사실 예약관리 시스템은 처음부터 지금 모습이 아니었어요.
저는 팀에 제대로 확인하지 않고 혼자 판단해서 청소관리 시스템으로 만들기 시작했거든요.
청소팀과 공유하는 것에 초점을 맞춰서 거의 다 만들었는데, 팀과 이야기하고 나서야 "이건 예약관리가 중심이어야 하는데"라는 걸 깨달았어요.
다행히 기존 작업이 있어서 전환 자체는 하루 정도 걸렸지만, 처음부터 팀과 확실하게 소통하고 내가 정확히 인지한 뒤 작업했다면
아끼지 않아도 될 시간이었어요. AI에게 뭘 시키든, "뭘 만들 건지"를 목적을 분명히하는 것이 가장 중요하다는 걸 이때 배웠습니다.
프로젝트별로 대화를 나눠라.
이전 글에서 소개한 실패 패턴 중 "한 대화에서 이것저것 시키기"라는 게 있었는데, 저는 이걸 미리 방지했어요.
프로젝트마다 각각의 대화와 작업 폴더를 분리해서 진행했습니다. 예약관리 시스템 대화에서 러카 이야기를 하지 않고, 러카 대화에서 예약관리를 건드리지 않았어요. 이렇게 하니까 대화가 꼬이거나 결과물이 엉키는 일 없이 깔끔하게 진행할 수 있었습니다.
그대로 믿으면 안 됩니다.
AI가 만든 결과물이 겉으로는 멀쩡해 보여도, 실제로 돌려보면 안 되는 부분이 있었어요.
"작동하는 것 같다"와 "실제로 작동한다"는 다르다는 걸 배웠어요.
그래서 앞서 이야기한 것처럼 직접 하나하나 테스트하고 검수하는 과정이 꼭 필요했습니다.
결국 AI는 만능이 아니라, 함께 문제를 풀어가는 도구라는 걸 다시 한번 느꼈습니다.
다만 그 속도가 사람 혼자 할 때와는 비교할 수 없을 만큼 빨랐을 뿐이에요.
마치며,
코딩을 모르는 사람도 자기 업무에 딱 맞는 도구를 직접 만들 수 있다는 것.
하나를 만들고 나면, "이것도 만들 수 있겠는데?"라는 생각이 자연스럽게 든다는 것.
물론 AI가 다 해주는 건 아니에요.
뭘 만들고 싶은지 명확하게 정리하는 건 사람의 몫이고, 결과물을 검증하는 것도, 방향을 잡는 것도 결국 사람이 해야 해요.
하지만 그 사이의 실행, 예전에는 전문가에게 맡기거나 포기해야 했던 그 부분을 AI가 메워주는 시대가 온 건 분명합니다.
이 시스템들은 지금도 실제로 쓰이고 있고, 계속 개선 중이에요.
앞으로도 새로운 시도가 있으면 이 플로그를 통해 공유하겠습니다.
긴 글 읽어주셔서 감사합니다. 🙏