목차
codexCLI를 활용해 HTML·CSS·자바스크립트로 디데이 계산기와 오늘의 운세 웹도구를 구현한 과정을 준비 단계부터 배포까지 정리합니다. 바이브코딩 흐름에서 프롬프트 작성과 코드 검증 방법을 함께 소개합니다.
처음 작은 웹도구를 만들어 보고 싶다고 생각했을 때, 제 목표는 거창하지 않았습니다. 특정 날짜까지 남은 일수를 계산해 주는 디데이 계산기와 가볍게 볼 수 있는 오늘의 운세 정도면 충분했습니다. 하지만 HTML·CSS·자바스크립트 코드를 처음부터 끝까지 혼자 작성하는 것은 부담스럽게 느껴졌고, 그렇다고 노코드 툴에만 의존하면 구조를 제대로 이해하기 어렵다는 걱정도 있었습니다. 이때 선택한 방식이 자연어로 코드를 생성·수정하는 바이브코딩 흐름이었고, 이를 터미널에서 지원해 주는 도구가 codexCLI였습니다.
codexCLI는 터미널에서 자연어 명령을 입력하면, 그에 맞는 코드 파일을 생성하거나 수정하는 방식으로 작업을 도와주는 도구입니다. 브라우저를 열지 않고도 “HTML로 이런 구조를 만들어 달라”, “이 자바스크립트 함수에 예외 처리를 추가해 달라”와 같은 요구를 바로 전달할 수 있습니다. 저는 이 도구를 활용해 하나의 폴더 안에 index.html, style.css, script.js 구조를 만들고, 디데이 계산기와 오늘의 운세 기능을 하나씩 추가하는 방식으로 진행했습니다. 이 글에서는 준비 단계에서 어떤 기준으로 화면을 설계했는지, codexCLI에 어떤 프롬프트를 입력해 코드를 생성했는지, 그리고 완성된 결과물을 어떻게 점검·배포했는지까지 단계별로 정리해 보겠습니다.
codexCLI를 선택한 이유와 준비 과정
codexCLI를 선택한 이유는 크게 두 가지였습니다. 첫째, 브라우저 기반 에디터보다 터미널 중심 환경이 집중하기에 더 편리하다고 느껴졌기 때문입니다. 여러 창을 오가며 복사·붙여넣기를 하는 대신, 한 화면에서 파일 구조와 명령 결과를 동시에 보면서 작업하고 싶었습니다. 둘째, 단순히 코드 조각을 받아오는 수준이 아니라, 폴더 구조를 함께 설계하고 파일 단위로 수정 내역을 관리하고 싶었습니다. codexCLI는 “현재 프로젝트 안에 HTML·CSS·JS 파일을 이런 식으로 만들어 달라”는 식의 지시를 이해하고, 실제 파일로 반영해 주는 점이 매력적이었습니다.
준비 과정에서 저는 먼저 프로젝트 폴더를 하나 만들고, 그 안에 어떤 파일이 필요할지 목록을 정리했습니다. 기본적으로 index.html, style.css, script.js 세 파일을 중심으로 하되, 나중에 기능이 늘어날 가능성을 고려해 img 폴더와 assets 폴더를 미리 만들어 두었습니다. 그런 다음 터미널에서 해당 폴더로 이동해 codexCLI를 사용할 수 있는지, 버전은 최신인지, 권한 설정에 문제는 없는지 확인했습니다. 이 단계에서 중요하게 생각한 점은 “도구를 설치하는 시간보다, 실제로 화면을 설계하는 데 더 많은 시간을 쓰자”는 기준이었습니다.
구조 설계는 종이에 간단한 스케치를 하는 것에서 시작했습니다. 화면 상단에는 제목과 오늘 날짜, 중간에는 디데이 계산기 영역, 하단에는 오늘의 운세 영역을 배치하는 1페이지 구조를 기본으로 잡았습니다. 디데이 영역에는 날짜 입력 필드, 계산 버튼, 결과 표시 구역이 필요하고, 운세 영역에는 사용자의 이름 또는 별명 입력 필드, 결과 메시지를 보여 줄 텍스트 영역이 필요하다고 정리했습니다. 이렇게 텍스트로 정리한 요구사항을 그대로 codexCLI 프롬프트의 초안으로 사용하기 위해, 각 요소의 역할과 원하는 동작을 문장 형태로 정리해 두었습니다. 이 사전 작업 덕분에 실제 프롬프트를 작성할 때 모호한 표현을 줄일 수 있었고, 코드 생성 결과를 검토할 때도 “처음 설계와 일치하는지”를 기준으로 판단할 수 있었습니다.
디데이 계산기 웹도구 구현 과정
디데이 계산기 구현은 HTML 구조를 만드는 것부터 시작했습니다. 저는 codexCLI에 “index.html 파일을 생성해 달라. 상단에는 페이지 제목과 오늘 날짜를 보여 주고, 그 아래에 디데이 계산 영역을 만든다. 디데이 영역에는 날짜 입력 필드, ‘계산하기’ 버튼, 결과를 보여 줄 문단 요소를 포함해 달라”라고 자연어로 요청했습니다. codexCLI는 이 요구를 바탕으로 기본적인 HTML 뼈대를 생성했고, body 안에 헤더와 main, footer 구조를 가진 코드 초안을 만들어 주었습니다. 저는 생성된 코드를 열어 보고, 너무 복잡한 부분이 있다면 “구조를 더 단순하게 줄여 달라”고 다시 요청해 불필요한 div를 줄였습니다.
그 다음 단계는 실제 디데이 계산 로직을 담당할 자바스크립트를 작성하는 일이었습니다. 여기서도 저는 “script.js 파일에 오늘 날짜와 사용자가 선택한 날짜의 차이를 일수로 계산하는 함수를 만들어 달라. 날짜 입력 필드는 HTML에서 id로 접근하고, 결과는 특정 span 요소의 텍스트로 출력해 달라”는 식으로 구체적으로 프롬프트를 작성했습니다. codexCLI는 Date 객체를 사용한 코드와 버튼 클릭 이벤트 리스너를 함께 제안했고, 저는 이 코드가 주말·과거 날짜 등 다양한 상황에서도 정상적으로 동작하는지 테스트했습니다. 만약 과거 날짜를 선택했을 때 “며칠 지났는지”를 보여 주고 싶다면, 프롬프트에 그 조건을 추가하여 메시지 형식을 수정하도록 요청하는 방식으로 반복 개선을 진행했습니다.
스타일링 단계에서는 style.css에 적용할 기본 디자인을 codexCLI와 함께 정리했습니다. “전체 페이지는 가운데 정렬하고, 디데이 계산기 박스는 카드 형태로 배경색과 그림자를 주어 구분되게 해 달라”, “모바일에서도 날짜 입력 필드와 버튼이 한 줄 안에 너무 붙어 보이지 않도록 여백과 폰트 크기를 조정해 달라”와 같은 요구를 전달했습니다. codexCLI가 생성한 CSS를 적용한 뒤 실제 브라우저에서 확인하면서, 여백이나 색상이 마음에 들지 않을 때는 “버튼 색을 조금 더 진한 파란색 계열로 바꿔 달라”처럼 구체적인 수정 요청을 이어갔습니다. 이 과정에서 중요한 점은, 모든 것을 도구에 맡기기보다는, 매 단계마다 결과를 직접 확인하며 작은 차이를 조정하는 태도였습니다. 결과적으로 사용자가 날짜를 선택하고 버튼을 누르면, “D-10”, “D+3”처럼 직관적인 형식으로 남은 날 혹은 지난 날을 보여 주는 간단하지만 실용적인 디데이 계산기가 완성되었습니다.
오늘의 운세 웹도구 구현과 확장 아이디어
오늘의 운세 기능은 디데이 계산기보다 조금 더 자유로운 성격을 가지고 있었습니다. 반드시 정답이 있는 계산 로직이 아니라, 같은 날짜에는 같은 운세가 나오되, 사용자에게 너무 가볍게 느껴지지 않는 메시지를 구성하는 것이 목표였습니다. 먼저 HTML 구조부터 codexCLI에 요청했습니다. “디데이 계산 영역 아래에 오늘의 운세 영역을 추가해 달라. 이름 또는 별명 입력 필드와 ‘운세 보기’ 버튼을 두고, 결과는 카드 형태의 박스 안에 텍스트로 보여 달라”는 식으로 요구사항을 전달했습니다. codexCLI가 생성한 코드는 입력 필드, 버튼, 결과 영역을 적절히 배치했으며, 저는 클래스를 약간 수정해 전체 페이지 스타일과 어울리도록 조정했습니다.
운세 로직은 자바스크립트에서 간단한 난수와 날짜 정보를 조합하는 방식으로 구현했습니다. 저는 codexCLI에 “오늘 날짜와 사용자가 입력한 이름을 바탕으로, 매일 같은 결과가 나오도록 간단한 해시 값을 만들어 달라. 이 해시 값을 배열 인덱스로 사용해 운세 문구 목록에서 하나를 선택하는 함수를 작성해 달라”고 설명했습니다. 그러자 도구는 문자열과 날짜를 숫자로 변환해 일정 범위의 인덱스를 만드는 로직과, 여러 개의 운세 문구가 담긴 배열을 함께 제안했습니다. 저는 여기에 “너무 극단적으로 좋거나 나쁜 표현은 피하고, 하루를 조금 더 긍정적으로 보낼 수 있는 방향의 문구로 구성해 달라”는 조건을 추가해 문구를 정제했습니다.
스타일링 측면에서는 운세 영역이 장난스럽게 보이지 않도록, 디데이 계산기와 통일된 디자인 언어를 유지하는 것을 목표로 삼았습니다. 카드의 배경색과 테두리, 폰트 크기와 줄 간격을 CSS에서 세밀하게 조정하면서, 결과 문구가 한눈에 읽히도록 가독성을 우선했습니다. 사용성을 고려해, 이름을 입력하지 않고 버튼을 눌렀을 때는 “이름을 입력해 주세요”와 같은 안내 메시지를 보여 주고, 동일한 이름·날짜 조합으로 다시 눌렀을 때는 같은 결과가 나오는지 여러 번 확인했습니다. 이 과정에서도 codexCLI에 “입력값이 비어 있을 때는 경고 메시지를 표시하고, 운세 박스는 업데이트하지 말라”는 식으로 명확한 조건을 전달해 예외 처리를 강화했습니다.
완성 후에는 확장 아이디어도 몇 가지 정리해 보았습니다. 예를 들어 운세를 단순한 문장 한 줄이 아니라, “오늘의 한 줄 요약 + 추천 행동 + 피해야 할 행동”처럼 세 가지 항목으로 나누어 보여 주는 방식으로 바꾸거나, 요일에 따라 다른 아이콘을 표시하는 기능을 추가할 수 있습니다. 이런 아이디어는 나중에 다시 codexCLI에 “기존 운세 함수를 확장해 이런 구조로 바꿔 달라”고 요청하는 형태로 구현할 수 있도록, 미리 문서에 적어 두었습니다. 이렇게 디데이 계산기와 오늘의 운세 기능을 하나의 HTML 페이지 안에 통합함으로써, 작은 웹도구지만 사용자가 방문할 이유가 두 가지 이상이 되도록 구성할 수 있었습니다.
codexCLI를 활용하며 느낀 장단점과 활용 팁
codexCLI를 사용해 두 가지 기능을 구현하는 동안 가장 크게 느낀 장점은 “코드를 직접 타이핑하는 부담은 줄이면서도, 구조를 이해하는 경험은 그대로 가져갈 수 있다”는 점이었습니다. 단순히 코드를 복사·붙여넣기 하는 것이 아니라, 프롬프트로 요구사항을 설명하고, 그에 대한 결과를 검토하면서 HTML 구조와 자바스크립트 로직을 자연스럽게 읽어 볼 기회를 얻었습니다. 특히 이벤트 리스너, Date 객체 사용, 간단한 조건문과 반복문 같은 부분은, codexCLI가 작성한 코드를 기반으로 주석과 함께 다시 정리해 보면서 이해를 깊게 할 수 있었습니다.
반면, 단점 또는 주의할 점도 분명했습니다. 가장 큰 위험은 “프롬프트가 모호하면 결과도 모호해진다”는 점입니다. 예를 들어 “예쁘게 만들어 달라”, “적당한 색을 써 달라”처럼 추상적인 표현만 사용하면, 스타일 코드가 지나치게 복잡해지거나, 실제 브랜드 톤과 맞지 않는 결과가 나올 수 있습니다. 따라서 가능하면 “버튼 색은 이 코드 범위에서 선택해 달라”, “폰트 크기는 기본 16px를 기준으로 제목은 24px, 부제는 18px로 해 달라”처럼 수치와 조건을 명확하게 정리해 전달하는 것이 중요했습니다. 또 하나는, 생성된 코드를 무조건 신뢰하기보다, 한 번씩 브라우저에서 테스트하며 작은 오류를 직접 찾아보는 습관입니다. 예를 들어 시간대 문제로 디데이 계산이 하루 차이 나게 표시되는 현상은, 실제 테스트를 해 보기 전까지 발견하기 어렵습니다.
활용 팁 측면에서는, 처음부터 긴 프롬프트를 한 번에 보내기보다, 기능 단위로 나누어 요청하는 방식이 효율적이었습니다. 먼저 HTML 뼈대를 만들고, 그 다음 자바스크립트 로직, 마지막에 CSS 스타일을 추가하는 순서를 지키면, 문제가 생겼을 때 어느 단계에서 오류가 발생했는지 추적하기가 쉬웠습니다. 또한 codexCLI에게 “지금까지 만든 코드의 구조를 요약해 달라”거나 “이 함수들의 역할을 표 형식으로 정리해 달라”고 요청해, 나중에 참고할 수 있는 간단한 문서를 자동으로 생성하는 방법도 도움이 되었습니다. 이렇게 하면 시간이 지나서 프로젝트를 다시 열어볼 때, 당시의 의도를 빠르게 떠올릴 수 있습니다.
개인적인 느낌으로는, codexCLI를 사용한 바이브코딩 방식은 노코드와 순수 코딩의 중간 지점에 위치합니다. 노코드만 사용할 때보다 코드를 훨씬 깊이 이해할 수 있고, 순수 코딩만 할 때보다 구현 속도가 빠르며, 실수를 줄일 수 있습니다. 디데이 계산기와 오늘의 운세처럼 비교적 작은 웹도구를 대상으로 연습해 보면, 도구에 대한 감각도 익히고, HTML·CSS·자바스크립트에 대한 자신감도 함께 키울 수 있습니다.
결론: 요약 및 정리
챗GPT 시대에 codexCLI를 활용해 HTML·JS·CSS로 디데이 계산기와 오늘의 운세 웹도구를 구현해 본 경험은, 바이브코딩이 실제로 어떤 가치를 줄 수 있는지 확인하는 좋은 계기였습니다. 단순히 “코드를 대신 써 주는 도구”가 아니라, 자연어로 요구사항을 정리하는 과정에서 화면 구조와 기능을 명확히 설계하게 만들고, 생성된 코드를 읽고 수정하는 과정에서 웹 기술에 대한 이해를 한 단계 끌어올릴 수 있었습니다. 특히 디데이 계산기처럼 명확한 로직이 필요한 기능과, 오늘의 운세처럼 연출과 문구 구성이 중요한 기능을 함께 구현해 보면서, codexCLI가 숫자 처리와 텍스트 표현 모두에 유용하다는 점을 체감했습니다.
물론 모든 상황에서 codexCLI가 정답은 아닙니다. 대규모 프로젝트나 복잡한 비즈니스 로직이 필요한 서비스라면, 팀 내 개발 규칙과 코드 리뷰 체계를 먼저 갖추는 것이 우선입니다. 그러나 개인이 작은 웹도구를 만들거나, 소규모 팀이 프로토타입을 빠르게 검증하고 싶을 때, codexCLI 기반 바이브코딩은 충분히 현실적인 선택입니다. 이 글에서 소개한 것처럼, 먼저 종이와 텍스트로 화면 구조와 기능을 정리한 뒤, 이를 자연어 프롬프트로 옮겨 codexCLI에 전달하고, 결과를 반복해서 다듬는 흐름을 익히면, 이후 다른 웹도구를 만들 때도 같은 방식으로 확장할 수 있습니다. 디데이 계산기와 오늘의 운세 웹도구 구현 경험은 그 자체로 하나의 완성된 프로젝트이면서, 앞으로 더 복잡한 웹 개발로 나아가기 위한 발판이 될 수 있습니다.