GuideNet 주간 작업기: 이제 실제 일감이 오가고, 다시 방문할 이유를 만들기 시작했다

GuideNet 프로젝트를 계속 진행하고 있습니다. GuideNet은 동남아시아 현지 가이드와 랜드사, 즉 현지 여행사를 연결하는 B2B 플랫폼입니다.쉽게 말하면, 랜드사는 필요한 가이드를 찾고, 가이드는 새로운 일감을 찾을 수 있는 서비스입니다. 지난 단계까지는 서비스의 기본 뼈대를 만드는 데 집중했습니다.회원가입이 되고,가이드와 랜드사를 구분하고,관리자가 등록된 정보를 승인하고,랜드사가 채용 공고를 올리고,가이드가 공고에 지원할 수 있는 구조를 만들었습니다. 여기까지는 한마디로 “서비스가 안전하게 돌아갈 수 있는 구조”를 만드는 일이었습니다. 그런데 이번 주 작업의 성격은 조금 달랐습니다. 이번 주에는 GuideNet이 단순히 정보를 등록하는 서비스에서 벗어나, 실제 일감이 오가고, 사용자가 다시 들..

GuideNet 프로젝트를 진행하면서 나는 나름대로 Codex를 구조적으로 쓰고 있다고 생각했다.처음 바이브코딩을 했을 때처럼 “이거 만들어줘”, “알아서 고쳐줘”라고 던지는 방식은 아니었다. 이제는 GPT를 통해 Codex에게 전달할 프롬프트를 먼저 정리했다. 작업 목적, 범위, 하지 말아야 할 일, 검증 기준, 보고 형식까지 꽤 자세히 적었다. 나름대로 체계가 생겼다고 생각했다. 그런데 막상 Codex로 작업을 계속 진행하다 보니 새로운 문제가 보였다.토큰이 너무 빨리 소진됐다. 처음에는 당연한 비용이라고 생각했다. 정확하게 지시하려면 긴 프롬프트가 필요하고, 긴 프롬프트를 쓰면 토큰을 많이 쓰는 게 어쩔 수 없다고 생각했다. 하지만 작업이 반복될수록 이상했다.매번 거의 같은 내용을 다시 설명하고 있..

GuideNet SEA Phase 2를 진행하면서 예상하지 못한 산출물이 하나 생겼다. 처음부터 만들려고 했던 문서는 아니었다.하지만 Phase 2가 깊어질수록 이 문서가 필요하다는 생각이 강해졌다. 문서 이름은 AI Team Operating Model이다.처음에는 단순한 작업 규칙 정도로 생각했다.하지만 만들고 나니 성격이 달랐다. 이 문서는 “Codex에게 어떻게 일을 시킬 것인가”를 정리한 문서가 아니었다.더 정확히는 PM과 AI들이 하나의 프로젝트 팀처럼 일하기 위한 운영 모델이었다. 지난 글에서 GuideNet Phase 2가 정적 프로토타입을 실제 MVP 구조로 바꾸는 과정이었다고 정리했다.Supabase, Auth, RLS, 관리자 승인, 공고 지원, 공고 마감, 역할별 QA 같은 작업을 ..

GuideNet SEA 프로젝트의 Phase 2를 계속 진행하고 있다. 지난 작업에서는 관리자 승인 기능(Admin Approval MVP) 을 만들고 QA했다.사용자가 등록한 가이드 프로필, 랜드사 정보, 채용 공고, 행사 입찰 데이터가 바로 공개되지 않고, 관리자가 검수한 뒤 승인된 데이터만 노출되는 구조였다. 오늘은 새로운 기능을 크게 만드는 날은 아니었다. 오히려 오늘의 핵심은 이런 질문에 가까웠다. “이제 GuideNet Phase 2를 끝낼 수 있는 상태인가?”“아직 끝났다고 말하기 전에 반드시 확인해야 할 위험은 무엇인가?”“다음 검증은 어떤 순서로 해야 하는가?” 개발자가 아닌 PM 입장에서 보면, 오늘은 코드를 많이 만든 날이라기보다 프로젝트 종료 기준을 점검한 날이었다.1. 오늘의 출발..

GuideNet SEA 프로젝트의 Phase 2를 계속 진행하고 있다.지난 글에서는 Phase 2의 큰 방향을 정리했다.Phase 1이 정적 프로토타입이었다면, Phase 2는 실제 저장, 인증, 권한, 승인 프로세스를 붙여 신뢰 가능한 B2B MVP로 전환하는 단계였다. 오늘 Codex를 통해 진행한 작업은 그중에서도 꽤 중요한 부분이었다.바로 관리자 승인 기능(Admin Approval MVP) 이다. 처음에는 단순하게 생각할 수 있다. “관리자가 승인 버튼을 누르면 approved 상태로 바꾸면 되는 것 아닌가?” 하지만 실제로 작업을 해보니 전혀 단순하지 않았다.관리자 승인 기능은 버튼 하나가 아니라, 플랫폼의 신뢰를 지키는 운영 구조에 가까웠다.1. 왜 관리자 승인 기능이 중요한가GuideNet..

지난 글에서는 GuideNet SEA 프로젝트 Phase 1을 마무리하며, 내가 처음 경험했던 바이브코딩 시즌1과 시즌2의 차이를 정리했다. 처음 바이브코딩을 했던 오늘수영 프로젝트에서는 Codex에게 내가 생각한 자연어를 그대로 던졌다. “이런 서비스 만들어줘.”“이 기능도 추가해줘.”“전체적으로 개선해줘.” 그 결과 Codex는 빠르게 움직였다. 하지만 동시에 너무 많은 것을 스스로 판단했다.내가 명확히 정하지 않은 개발 범위를 넓게 잡기도 했고, 방향을 임의로 설정하기도 했다. GuideNet에서는 방식을 바꿨다.PM, UX, FE, QA 스레드를 분리했다.프로젝트 저장소도 하나로 고정했다. 내가 생각한 내용을 Codex에게 바로 던지지 않고, 먼저 GPT를 통해 작업 지시서로 정제했다. 그리고 이..

오늘수영에서 GuideNet으로, AI와 일하는 방식이 완전히 달라졌다.바이브코딩(Vibe Coding)을 처음 시작했을 때만 해도 AI는 그저 빠르게 코드를 만들어주는 개발자라고 생각했습니다.몇 달 동안 두 개의 프로젝트를 진행하면서 그 생각은 완전히 바뀌었습니다. 첫 번째 프로젝트는 ‘오늘수영’이었습니다.서울시 공공 수영장 정보를 한곳에 모아, 오늘 당장 이용할 수 있는 수영장을 쉽고 빠르게 찾을 수 있도록 만드는 정보 조회 서비스였습니다. 두 번째 프로젝트는 현재 개발 중인 GuideNet입니다.GuideNet은 일반 소비자를 위한 서비스가 아니라 여행 가이드와 여행사 등 여러 참여자가 함께 사용하는 B2B 플랫폼입니다. 아직 개발 중인 프로젝트라 자세한 기능은 공개하기 어렵지만, 여러 역할의 사용..

6월 23일부터 24일까지 이틀 동안 GuideNet 프로젝트 Phase 1을 마무리했다. GuideNet은 여행·가이드·현지 액티비티 영역에서 사용할 수 있는 B2B 플랫폼을 가정하고, 초기 제품 구조를 빠르게 만들어보는 실험 프로젝트다. 이번 Phase 1의 목표는 완성형 서비스를 만드는 것이 아니었다.목표는 더 명확했다.“제품의 기본 골격을 만들고, 실제 프로젝트 형태로 실행 가능한 수준까지 끌어올리는 것.” 즉, 아이디어를 문서에만 남기는 것이 아니라, AI와 함께 실제 화면과 코드 구조로 만들어보는 작업이었다.요즘 말로 하면 바이브코딩이었다. 하지만 이번 작업은 내가 처음 바이브코딩을 경험했던 오늘수영 프로젝트와는 달랐다.오늘수영이 바이브코딩 시즌1이었다면,GuideNet은 바이브코딩 시즌2였다..

오전 10시 30분. Slack은 조용했습니다. 평소라면 그 시간에 Traffic Daily Report가 와야 했습니다.전날 교통 서비스의 퍼널 전환율.주문과 취소 실적.그리고 자동 해석 코멘트까지. 매일 오던 메시지였습니다. 그런데 오지 않았습니다. 처음엔 지연이라고 생각했습니다.몇 분쯤 늦을 수 있으니까요. 하지만 곧 이메일함이 눈에 들어왔습니다. Databricks 작업 실패 알림. 순간 느낌이 왔습니다. “아, 이건 그냥 늦는 게 아니다.” Slack이 조용한 데는 이유가 있었습니다.1. 메시지가 오지 않았다문제는 단순해 보였습니다. Slack 알림이 안 왔다. 하지만 장애는 늘 단순한 얼굴로 나타납니다.겉으로는 Slack 문제처럼 보였습니다. 그런데 정말 Slack 문제일까요? 가능성은 두 가..

바이브코딩을 하다 보면 가끔 이런 착각을 한다. “AI가 코드를 대신 짜주니까, 이제 나는 기능만 말하면 되겠지.” 그런데 오늘은 그 생각이 꽤 순진했다는 걸 다시 배웠다.오늘 내가 한 일은 멋진 기능 개발이 아니었다.오히려 반대에 가까웠다. 쓰기 권한 하나를 제대로 잡지 못해서 프로젝트 폴더를 옮겼다가, 다시 원래 폴더로 돌아왔다. 겉으로 보면 허무한 하루다.하지만 실제로는 꽤 중요한 교훈이 있었다. 바이브코딩에서 사람의 역할은 단순히 “무엇을 만들지 말하는 것”이 아니다.AI가 작업할 수 있는 환경을 정리하고, 실패했을 때 어디까지 되돌릴지 판단하고, 그래도 오늘의 실질적 개선을 끝까지 만들어내는 일까지 포함된다. 오늘은 그걸 제대로 겪은 날이었다.오늘수영 프로젝트, 문서 정리부터 시작했다오늘 작업의..