컴퓨터로 작업하다 보면 가끔 파일 형식을 바꾸거나, PDF를 정리하거나, QR 코드를 만들어야 할 때가 있다. 나도 그럴 때마다 검색해서 도구 사이트를 찾아 썼다. 어느 날은 반대로 생각했다. 이런 기능은 대부분 브라우저 안에서 돌아가고, 정적 웹은 무료로 호스팅할 수 있다. 그렇다면 작은 도구를 여러 개 만들어 광고를 붙이면 큰돈은 아니어도 용돈 정도는 벌 수 있지 않을까.
예전에는 서버를 빌리고 사용자가 많은 서비스를 상상했다. 하지만 상상은 컸고 당장 시작하기에는 비용과 구현 범위가 부담스러웠다. 이번에는 기준을 하나만 남겼다. 서버 없이 실행할 수 있는 기능부터 실제로 공개해 보자. 개발 공부 자체보다, 바이브 코딩으로 사람들이 쓸 만한 서비스를 만들고 수익까지 연결할 수 있는지 시험하는 것이 목적이었다.
첫 서비스는 이미지 변환소였다
커밋 기록상 첫 시작은 2026년 7월 19일의 이미지 변환소다. PNG, JPG, WebP 형식을 바꾸고 이미지 크기와 용량을 조절하는 도구를 한곳에 모았다. 사용자가 올린 이미지는 서버로 보내지 않고 브라우저에서 처리하도록 만들었다. 서버 비용이 들지 않고, 파일을 외부에 전송하지 않는다는 설명도 명확하게 할 수 있었다.
서비스 이름으로는 오래 사용한 아이디인 cora1022를 그대로 선택했다. 가비아에서 cora1022.com 도메인을 19,800원에 샀다. 각각의 도구마다 도메인을 새로 사는 것은 부담스러웠기 때문에 image.cora1022.com, pdf.cora1022.com처럼 서브도메인을 나눴다. 도메인 하나와 무료 호스팅만으로 여러 서비스가 각자의 주소를 갖게 됐다.
쉬운 기능부터 빠르게 늘렸다
처음의 선정 기준은 특별하지 않았다. 서버가 없어도 되고 구현하기 쉬운 기능이면 됐다. 커밋을 다시 펼쳐 보니 7월 20일에는 서비스 메인과 돌림판, 테트리스가 올라왔고 7월 21일에는 PDF 편집기와 QR 코드 생성기가 이어졌다. 이후 사다리게임과 주사위, 반응속도 테스트가 추가됐고 8월에는 BMI 계산기도 들어왔다.
테트리스는 도구 사이트의 방향과 조금 달라 보이지만, 단순한 게임도 정적 웹으로 운영할 수 있는지 확인해 보고 싶어서 만들었다. 처음부터 완벽한 서비스 목록을 설계한 것이 아니라, 만들 수 있는 것을 실제 주소에 하나씩 올리면서 사이트의 범위를 찾아간 셈이다.
정적 웹의 편리함과 선명한 한계
HTML과 JavaScript만으로 기능이 돌아가면 서버 대여료가 없고 별도의 운영 작업도 거의 없다. 작은 수정은 Git에 올리면 Netlify가 다시 배포한다. 사용자가 많아져도 파일을 변환해 주는 서버를 내가 유지하지 않으니 초기 실험에 잘 맞았다.
처음에는 GitHub Pages도 사용했다. 그러나 수익화를 전제로 운영하기에는 관련 규정이 마음에 걸렸고, 확인한 뒤 메인 서비스 배포를 Netlify로 옮겼다. 이전 자체는 생각보다 어렵지 않았다. 도메인과 서브도메인을 연결하고 나니 별도 서버 없이도 여러 개의 독립 서비스가 돌아갔다.
반대로 브라우저 안에서 끝낼 수 없는 기능은 곧 한계에 닿는다. 계정, 데이터베이스, 여러 사용자의 실시간 연결처럼 고차원적인 기능에는 결국 서버가 필요하다. 그래서 정적 웹은 최종 형태라기보다 낮은 비용으로 아이디어와 사용 반응을 확인하는 첫 단계에 가깝다.
CORA 로고를 붙인 순간
처음에는 기능만 모아 둔 단순한 홈페이지를 원했다. 하지만 서비스가 늘어날수록 서로 관련 없는 사이트를 한곳에 링크한 것처럼 보였다. 로고를 붙이고 메인과 서브도메인에 같은 이름을 사용한 뒤에야 처음으로 하나의 서비스처럼 느껴졌다.
문제는 각 도구를 빠르게 만들면서 화면의 글꼴, 색상, 카드와 버튼 모양이 모두 달라졌다는 점이었다. 지금은 공통 UI 기준 문서를 두고 흰색 화면, 보라색 포인트, 제목과 본문 글꼴, 입력과 결과 패널, 접근성, 카드 이미지 규격까지 맞추고 있다. 처음에는 각 페이지를 고치는 일이었지만, 결국 새 서비스를 추가할 때 따라야 할 제품 규칙을 만드는 일이 됐다.
모바일 화면도 한 번에 해결되지 않았다. 데스크톱에서 여러 카드가 가로로 놓인 모습은 괜찮았지만 세로로 긴 휴대폰에서는 카드가 억지로 좁아졌다. 현재는 PC에서 다음 카드가 살짝 보이는 가로 레일을 사용하고, 모바일에서는 한 열로 내려가도록 나눴다. 서비스가 늘어날 것을 생각해 콘텐츠를 숨기는 ‘더보기’ 대신 계속 옆으로 확장할 수 있는 구조를 선택했다.
2026년의 바이브 코딩은 프롬프트 한 번이 아니었다
올해 들어 바이브 코딩은 재미있는 결과를 만드는 수준을 넘어 실제로 사용할 만한 도구가 됐다고 느꼈다. 그렇다고 Codex에게 “웹사이트를 만들어 줘”라고 한 번 말하면 모든 것이 끝난 것은 아니었다. 결과가 흔들릴 때마다 더 긴 프롬프트를 쓰는 것보다, 에이전트가 일할 환경을 정리하는 편이 효과적이었다.
서비스마다 저장소를 분리하고, 운영에 필요한 프로젝트만 하나의 작업공간에 모았다. 작업공간에는 저장소별 실행·검증 방법을 적은 AGENTS.md, 공통 디자인을 고정하는 UI-STANDARD.md, 다음 작업에서도 운영 상태를 이어받을 수 있는 인수인계 문서를 뒀다. 변경은 작은 범위로 나눠 브랜치와 Pull Request에 남기고, 각 저장소의 테스트와 빌드를 거친 뒤 실제 배포 주소까지 확인했다.
나는 이 과정을 하네스 엔지니어링에 가깝다고 생각한다. AI가 코드를 생성하는 능력만 보는 것이 아니라, 어떤 파일을 읽어야 하는지, 어디까지 바꿀 수 있는지, 어떤 검사를 통과해야 완료인지와 실패했을 때 어디로 돌아갈지를 설계하는 일이다. 화면이 마음에 들지 않으면 결과만 비난하는 대신 공통 규칙을 문서에 추가했고, 모바일에서 깨지면 다음 작업의 검증 목록에 모바일 화면을 넣었다.
이 방향은 현재 Codex 활용 흐름과도 닿아 있다. OpenAI는 저장소의 AGENTS.md, 로컬 스킬, 검증 스크립트와 GitHub Actions를 이용해 반복 작업을 코드 가까이에 두는 사례를 소개한다. 프런트엔드 작업 역시 화면 자료를 입력으로 사용하고 실제 화면을 다시 확인하는 흐름을 권장한다. Codex 저장소 워크플로 사례와 반응형 프런트엔드 활용 사례에서 비슷한 방향을 확인할 수 있다.
내가 만든 것은 코드만이 아니었다
아이디어와 완료 기준은 내가 정하고, Codex가 읽을 문맥과 규칙을 저장소에 남겼다. 생성된 화면을 다시 보고 요구사항을 수정하고, 테스트·커밋·배포 확인까지 하나의 반복 과정으로 묶었다. 바이브 코딩으로 빠르게 만드는 것과 아무 기준 없이 만드는 것은 다른 일이었다.
첫 광고 수익은 아직 0원
사이트를 만든 지 오래되지 않아 실제 사용자는 아직 거의 없다. 이 실험의 첫 번째 성공 기준은 애드센스 승인이고, 두 번째는 금액과 관계없이 첫 광고 수익이 생기는 것이다. 지금은 두 기준 모두 달성하지 못했다.
앞으로도 정적 웹으로 만들 수 있는 서비스는 계속 추가할 생각이다. 반응이 생기면 서버가 필요한 기능으로도 범위를 넓히고 싶다. 다만 서비스를 여러 개 만들었다고 애드센스 승인까지 자연스럽게 따라오지는 않았다. 그 이야기는 다음 기록에서 이어진다.