한끼표 서비스 개발 후기(feat. Codex)

프로젝트

아이디어

평소 소위 말하는 결정 장애가 꽤 심해서 매 끼니 때 마다 ..
뭐 먹지.. 오늘은 뭘 먹지.. 고민하는 경우가 아주 많았었다.

더구나 이제 회사 근처 식당을 가볼만큼 다 가본 동료들과 점심 메뉴를
고르는게 매번 쉽지 않았다.

매번 오늘은 뭘 먹을까요? 질문 받고.. 질문 하고..
그러다가 이 참에 하나 만들어보자 하고 생각을 하게 되었고
기존 서비스들을 찾아보니 완전히 메뉴를 랜덤하게 선정해서 '짜잔 이거 드세요!' 하는 종류의 서비스 밖에 안보였다.
내가 원하는건 이미 알고 있는 메뉴나 식당 중에서 골라줬으면 했던건데
이런걸 제공하는 곳은 딱히 없는 것 같아서 바로 착수하게 되었다.

개발 시작

처음에는 다른 토이 때 처럼 앱으로 개발을 할까 생각했다가 아무래도 이 서비스는
스토어에서 검색해서 설치하고 사용하는 방식보다 그냥 검색해서 바로 이용할 수 있게 제공되는게 좋을 것 같아서
이번에는 웹으로 해보기로 결정하고 진행했다.
앱이나 데스크탑 프로그램만 만들어봤지 제대로된 웹을 만든적은 없기도 하고 LLM으로 진행하는게
빠르게 결과 보기 좋아서 바로 코덱스의 'Sites' 기능을 호출하고 컨셉, 약간의 기획 내용 등을 전달하고 '해줘'로 진행했다.

디자인

요즘 나는 바이브 코딩으로 개발을 진행할 때 LLM과 기획 회의를 진행하면서 문서로 결정 사항을 정리한 후
정리된 내용을 바탕으로 디자인 시안을 먼저 작성해달라고 요청한다.
디자인을 초반에 잡지 않고 진행하다보면 결과물이 나올 때 은근슬쩍 디자인이 자꾸 바뀌는 경우가 있어서
최근에는 디자인 먼저 정리하고 진행하고 있다.

디자인은 예전에 검색하다 보니 'frontend-design'이라는 스킬이 AI가 그린거 같지 않게 결과물이 꽤 좋다는 평을 보고
그때부터 잘 사용하고 있다.
(클로드 스킬인데 코덱스한테 줘도 잘 쓰더라.)
FrontEnd Design

근데 이번 프로젝트는 'Sites' 기능으로 먼저 기반을 잡고 해당 스킬로 디테일을 잡도록 요청하는 식으로 진행했다.
코덱스의 Sites 스킬의 결과물이 궁금하기도 했고, 디자인 스킬로 디테일 잡는 연습?도 해보고 싶어서 그렇게 진행했다.

개발 중

Sites 기능의 결과물은 생각보다 괜찮았다.
디자인을 잡고 진행한게 아님에도 그렇게 촌스럽지도 않고 필요한 기능이나
버튼들이 적재적소에 잘 배치되어있다고 느껴졌다. 물론 이건 지극히 내 기준이고.. 진짜 디자이너분들이 보신다면......
몇몇 부족한 부분이나 좀 디자인이 깨지는 부분들도 있긴했지만 나름 만족스러운 결과물이었고 부족한 부분들은
아까 말한 것 처럼 FrontEnd Design 스킬로 보강하면서 프로젝트를 진행했다.

Sites 기능은 특이하게도 개발뿐만 아니라 배포, 그러니까 호스팅까지 직접 해준다고 했다.
정말 '해줘'로 만들고 결과물이 괜찮네? 하면 '배포해줘' 하면 자체적으로 호스팅도 해준다는 것이었다.
내부적으로 Cloudflare worker와 연동되서 간단한 DB 기능도 가능하다고 해서 이번에 이걸로 해볼까 싶었다.

근데 아무래도 현재는 요금제 구독을 한 사람들에게 무료로 제공되고 있다고는 하는데 언제 가격 정책이 바뀔지
모른다는 생각에 간단한 테스트만 진행하고 바로 개인 서버에서 동작시킬 수 있게 리팩토링을 해달라고 요청했다.

코덱스가 또 열심히 cloudflare 관련 코드 걷어내고, DB 구조 다시 잡고 등등 리팩토링을 쭉 진행해줬다.
도커로 구성할꺼라고 미리 요청을 해둬서 결과물로 바로 도커 파일들이 나왔고
로컬에서 구동시켜보면서 본격적인 디테일 잡기를 시작했다.

개발 마무리

아무래도 LLM이 만든거다 보니 문장 구성이 어색하기도 하고 코덱스만의 특징인지는 몰라도 특정 단어에 꽂히면
하지말라고 할 때까지 그 단어를 계속 활용하는 모습이 있어서 그런 부분을 하나하나 페이지 보면서 수정 요청을 했다.

내가 원하는 문장이나 단어가 있으면 바로 요청하고 생각나는게 없다면 해당 문장을 다시 작성하라고 요청하는 식으로
디테일을 잡아나갔고, 디자인도 마찬가지로 부족한 부분은 동일한 방식으로 수정 요청을 하면서 디테일을 잡았다.

그러면서 부족한 기능이나 생각나는 기능도 하나씩 추가하고, 관리자 페이지도 필요할 것 같아서 '해줘' 시전. 그렇게 며칠을 디테일 잡고, 기능 추가/수정 하면서 프로젝트를 진행해나갔고 시간과 함께 토큰도 어마어마하게 사라졌다..

서버 구성

기존에 쓰고 있는 카페24 서버에 이번것도 올려야되나... 블로그랑 이거저거 돌고 있어서 이미 리소스 풀인데.. 괜찮을까..
고민하던 차에 오라클 프리티어 서버가 놀고 있던게 생각나서 카페24 서버랑 프리티어 서버 연동하고
카페24 서버에서 프록시 설정하는 방식으로 가면 되겠다 싶어서 바로 세팅을 진행했다.

아무래도 프리티어쪽을 웹상에 그대로 노출하는게 좀 꺼려져서 터널링으로 연결하는 방법이 없나 찾아봤는데
Tailscale로 간단하게 구성할 수 있다고 하길래 예전에 잠깐 썼던 기억이나서 바로 차용하고 구성에 포함시켰다.

아래는 간단히 mermaid로 그려둔 구성도.

flowchart LR
    User["사용자 브라우저"]

    subgraph A["A 서버 · 프록시 서버"]
        subgraph DockerA["Docker Compose"]
            Proxy["Nginx Proxy<br/>도메인 · HTTPS"]
            Blog["개인 블로그"]
            Gateway["hankkipyo-gateway<br/>한끼표 요청 중계"]
        end
    end

    subgraph B["B 서버 · 애플리케이션 서버"]
        subgraph DockerB["Docker Compose"]
            Cleanup["데이터 정리 작업"]
            App["한끼표<br/>Next.js"]
            DB[("PostgreSQL")]
        end
    end

    User -->|"HTTPS"| Proxy

    Proxy --> Blog
    Proxy -->|"한끼표 요청"| Gateway
    Gateway -->|"Tailscale 사설망"| App

    Cleanup --> DB
    App --> DB

다이어그램을 불러오는 중입니다.

tailsacle은 이전에 써봤던 터라 바로 등록해주고 서버끼리 서로 핑도 잘 주고 받는 것도 빠르게 확인했다.
그 이후는 이미 카페24에 기반이 다 있기도 했고 도커 구성이라서 크게 막히는 부분은 없었다.

기존 도메인에 CNAME 추가해서 서브 도메인 하나 만들어주고, 해당 도메인으로 들어오는 요청은 모조리 프리티어로
던지도록 세팅해주고 마무리.

배포

프리티어 서버 스펙이 스펙이다 보니 도커 이미지를 서버에서 빌드 시도를 했더니 시간이 어마어마하게 오래걸렸다.
처음에는 30분 정도 걸리더니 .. 나중에는 1시간 가까이 빌드만 하고 있기에 시간이 너무 아까워서 배포 구성은 좀 바꾸기로 했다.
아직 자동화 구성 전이어서 신규 버전 릴리즈 하고 서버에서 수동으로 빌드해서 쓰고 있었는데
릴리즈가 되면 github actions로 이미지를 빌드하고 해당 이미지를 서버에서 다운받아서 run 할 수 있도록 구성했고
테스트 해보니 1시간 걸리던게 늦어도 10분만에 끝나는걸 확인했다.

마무리

최근 토이 프로젝트는 귀찮음도 있지만 새로운 환경을 접해보려고 하면서 바이브 코딩으로 대부분 진행하고 있는데
웹 프로젝트는 처음이라 잘 될까 싶었었는데 생각외로 결과물이 좋았던 Sites 기능과
FrontEnd Design 스킬 덕분에 비교적 수월하게 진행했던 것 같다.

거기다 최근 좀 잦았던 토큰 사용량 리셋 덕분에 토큰 걱정없이 제대로 버닝할 수 있었던 것 같다.