AIMetaClean 빌드인퍼블릭: 바이브코딩 프로젝트 환경 하네스 세팅

아이디어를 떠올리는 것부터 기획하고, 만들고, 출시하고, 홍보하는 순간까지.

이번에는 AIMetaClean이라는 웹서비스가 만들어지는 전 과정을 가감 없이 빌드인퍼블릭으로 공개하고 있습니다.

완성된 제품을 그럴듯하게 소개하는 것이 아니라 다음 과정을 모두 기록합니다.

• 왜 이런 아이디어를 떠올렸는지
• 제품을 어떻게 기획하는지
• 어떤 기술과 도구를 선택하는지
• AI와 어떻게 협업하는지
• 개발하면서 어떤 문제가 생기는지
• 실제로 출시까지 할 수 있는지
• 사람들에게 어떻게 알리는지
• 사용자의 반응은 어떤지

잘된 선택만 모아놓은 성공담이 아니라, 실제로 제품 하나를 만드는 과정에서 생기는 고민과 시행착오까지 그대로 남겨보겠습니다.

AIMetaClean 아이디어는 어디서 시작됐나

AIMetaClean은 AI 이미지에 포함된 메타데이터를 확인하고, 필요에 따라 정리할 수 있도록 돕는 웹서비스입니다.

아이디어는 조금 엉뚱한 경험에서 시작됐습니다.

제 실제 사진으로는 SNS 셀피 인증에 실패했는데, AI로 만든 인물 이미지는 통과했습니다.

물론 이 한 번의 경험만으로 인증 시스템에 문제가 있다고 단정할 수는 없습니다. AI 이미지가 통과한 이유가 메타데이터 때문이라고 확정할 수도 없습니다.

하지만 여기서 한 가지 궁금증이 생겼습니다.

AI 이미지에는 어떤 정보가 들어 있고, 그 정보는 어디까지 외부에 공개되고 있을까?

AI로 생성한 이미지에는 단순한 픽셀만 들어 있는 것이 아닙니다.

사용한 도구에 따라 다음과 같은 정보가 함께 저장될 수 있습니다.

• 프롬프트와 네거티브 프롬프트
• 생성 모델과 모델 버전
• 시드, 샘플러, 스텝, CFG 값
• LoRA와 ControlNet 정보
• Stable Diffusion 생성 파라미터
• ComfyUI 워크플로
• 이미지 생성 및 편집 도구 정보
• C2PA와 Content Credentials
• 일반 EXIF와 위치 정보

창작자에게는 유용한 작업 기록이지만, 외부에 이미지를 공개하거나 고객에게 납품할 때는 숨기고 싶은 제작 노하우가 될 수도 있습니다.

그래서 단순한 사진 메타데이터 삭제 도구가 아니라, AI 이미지에 포함된 생성·편집·출처 정보를 전문적으로 확인하고 정리하는 서비스를 만들어 보기로 했습니다.

아이디어가 시작된 자세한 이야기는 VibeCrew에 먼저 정리해 두었습니다.

👉 진짜 사람 사진은 실패했고, AI 사진은 통과했다

아직 사람들이 실제로 필요로 하는 서비스인지, 돈을 내고 사용할 만한 서비스인지도 모릅니다.

그래서 아이디어 단계부터 전부 공개하며 확인해 보려고 합니다.

이번 글에서는 바이브코딩 환경을 세팅합니다.

아이디어가 생기면 바로 에디터를 열고 코드를 작성하고 싶어집니다.

특히 바이브코딩을 시작하면 AI에게 첫 화면부터 만들어 달라고 요청하고 싶습니다.

하지만 이번 프로젝트에서는 코드를 작성하기 전에 먼저 언제 어디서든 프로젝트를 이어서 개발할 수 있는 구조를 만들기로 했습니다.

AIMetaClean은 다음과 같은 방식으로 진행할 예정입니다.

• 주 개발 도구는 Codex
• 작업 성격에 따라 GPT-5.6 Sol, Terra, Luna를 적절히 활용
• PC에서는 Codex와 로컬 개발 환경으로 작업
• 모바일에서는 ChatGPT 리모트를 통해 프로젝트 작업을 이어서 진행
• GitHub에서 코드와 브랜치 관리
• VibeOps를 이용해 TASK, 브랜치, 커밋, Push, Pull Request 관리

목표는 단순합니다.

PC 앞에 있든 밖에서 모바일을 사용하든, 프로젝트의 현재 상태를 잃지 않고 언제든 이어서 바이브코딩할 수 있게 만든다.

AI에게 생각나는 내용을 그때그때 말하며 빠르게 만드는 것도 바이브코딩입니다.

하지만 프로젝트가 조금만 커지면 문제가 생깁니다.

• 이전 세션에서 어떤 결정을 했는지 기억나지 않는다.
• AI마다 프로젝트 구조를 다르게 이해한다.
• 무엇을 완료했고 무엇이 남았는지 알기 어렵다.
• 작업 중 브랜치가 꼬인다.
• 문서와 실제 코드의 상태가 달라진다.
• 다른 PC나 모바일에서 작업을 이어가기 어렵다.
• AI가 이미 끝난 논의를 다시 시작한다.

이번 프로젝트에서는 이런 문제를 줄이기 위해 처음부터 최소한의 하네스를 씌우고 시작합니다.

프로젝트 관리는 VibeOps로 진행한다

전체 프로젝트 관리는 제가 만든 VibeOps를 사용합니다.

VibeOps는 바이브코딩 프로젝트를 TASK 단위로 관리하는 CLI 도구입니다.

AI가 코드를 대신 작성하더라도 프로젝트를 무작정 변경하지 않도록 다음 흐름을 관리합니다.

TASK 생성
→ 작업 브랜치 생성
→ 계획 작성
→ 구현
→ 문서 업데이트
→ 커밋 및 Push
→ Pull Request
→ develop 병합
→ main 배포

쉽게 말하면 AI에게도 최소한의 작업 레일을 깔아주는 도구입니다.

VibeOps가 직접 코드를 작성하는 것은 아닙니다.

Cursor, Claude Code, Codex 같은 코딩 에이전트가 실제 계획과 구현을 담당하고, VibeOps는 TASK 파일과 Git 브랜치, 커밋, Push, Pull Request 같은 프로젝트 흐름을 관리합니다.

VibeOps를 사용하지 않아도 괜찮습니다.

직접 브랜치를 만들고 TASK 문서를 관리하면서 같은 방식으로 진행하면 됩니다.

VibeOps가 처음이라면 아래 저장소를 참고하면 됩니다.

👉 VibeOps GitHub 저장소

GitHub 저장소 만들기

이번 프로젝트는 비교적 가볍게 개발할 예정이고, 향후 오픈소스 전환도 고려하고 있습니다.

그래서 코드 저장소는 GitHub를 선택했습니다.

GitHub와 GitLab 중 무엇을 선택해야 할지 고민된다면 아래 글을 참고하면 됩니다.

👉 GitHub이냐 GitLab이냐, 바이브코더에게 맞는 선택은?

먼저 GitHub에 aimetaclean이라는 Private 저장소를 만들었습니다.

aimetaclean

원격 저장소 주소는 다음과 같습니다.

git@github.com:goodtekxyz/aimetaclean.git

아직 제품 기획과 구조가 확정되지 않았기 때문에 Private으로 시작합니다.

제품 구조가 안정되고 공개해도 되는 단계가 되면 오픈소스 전환도 검토할 예정입니다.

VibeOps 설치와 LLM 연결

VibeOps가 처음이라면 먼저 설치합니다.

설치 방법과 사용 방법은 GitHub 저장소에서 확인할 수 있습니다.

👉 VibeOps 설치 및 사용 방법

설치를 마친 뒤 VibeOps가 사용할 LLM 서비스를 연결합니다.

vibeops llm connect

VibeOps는 비용 최적화를 위해 별도의 API를 직접 호출하는 방식 대신, 사용자가 구독 중인 LLM 서비스를 OAuth로 연결해서 사용할 수 있도록 구현했습니다.

LLM은 주로 다음 작업에 사용됩니다.

• TASK 초안 생성
• 작업 내용 정리
• 커밋 메시지 작성 보조
• Ship 단계의 변경 내용 요약
• Pull Request 설명 작성

실제 코딩은 선택한 코딩 에이전트에서 진행합니다.

이번 프로젝트에서 저는 VibeOps의 LLM을 Cursor CLI에 연결해서 진행하겠습니다.

VibeOps로 프로젝트 초기화하기

GitHub 저장소를 만들었으니 로컬 프로젝트 폴더로 이동한 뒤 VibeOps를 초기화합니다.

vibeops init

실행하면 먼저 어떤 코딩 에이전트를 사용할지 선택합니다.

Agent clients

? Which coding agents will you use? (Space toggle · Enter confirm)

❯◉ Cursor (.cursor/rules, .cursor/skills)
 ◯ Claude Code (CLAUDE.md, .claude/skills)
 ◯ Codex CLI (.agents/skills)

↑↓ navigate • space select • a all • i invert • ⏎ submit

VibeOps에서는 여러 에이전트를 동시에 선택할 수도 있습니다.

선택한 에이전트에 따라 프로젝트에 필요한 규칙과 스킬 파일이 자동으로 생성됩니다.

예를 들면 다음과 같습니다.

• Cursor: .cursor/rules, .cursor/skills
• Claude Code: CLAUDE.md, .claude/skills
• Codex CLI: .agents/skills

이번 초기 설정에서는 Cursor를 선택했습니다.

주 개발은 Codex 중심으로 진행할 예정이지만, VibeOps의 LLM 연결과 초기 프로젝트 관리 구조는 Cursor로 구성해 보겠습니다.

브랜치 정책은 GitFlow Lite

다음으로 프로젝트의 브랜치 정책을 선택합니다.

Branch policy

? Branch policy

❯ GitFlow lite — develop (integration) + main (production)
  Trunk — main only (integration and production = main)
  Custom branch names

AIMetaClean은 개발 서버와 운영 서버를 나누어서 진행할 예정입니다.

그래서 이번 프로젝트에는 GitFlow Lite가 가장 적합하다고 판단했습니다.

브랜치는 다음과 같이 사용합니다.

task/* → develop → main

각 작업은 task/* 브랜치에서 진행합니다.

개발이 끝나면 develop 브랜치에 병합하고 개발 서버에서 먼저 확인합니다.

운영 배포가 가능한 상태가 되면 develop을 main에 병합합니다.

각 브랜치의 역할은 다음과 같습니다.

• task/*: 개별 기능 개발
• develop: 개발 서버와 통합 테스트
• main: 운영 서버와 실제 배포

혼자 개발하는 작은 프로젝트에서는 main 브랜치 하나만 사용하는 Trunk 방식도 충분합니다.

하지만 AIMetaClean은 실제 서비스 출시까지 진행할 예정이므로 개발과 운영을 구분하기로 했습니다.

기본 하네스 구조가 자동으로 만들어졌다

설정을 마치면 VibeOps가 프로젝트에 필요한 기본 파일을 생성합니다.

→ vibeops init
→ /Users/goodtek/Library/CloudStorage/GoogleDrive-hello@goodtek.xyz/Shared drives/goodtek/projects/aimetaclean

  project: aimetaclean
  vibeops: 2.5.0
  clients: Cursor (.cursor/rules, .cursor/skills)
  git:     integration=develop, production=main

✓ created   .cursor/rules/01-task-source-of-truth.mdc
✓ created   .cursor/rules/02-git-safety.mdc
✓ created   .cursor/rules/03-docs-before-ship.mdc
✓ created   AGENTS.md
✓ created   docs/logs/README.md
✓ created   docs/project/03-architecture.md
✓ created   docs/project/05-current-state.md
✓ created   docs/project/06-decisions.md
✓ created   docs/tasks/TASK-000-template.md
✓ created   .cursor/skills/implement-task/SKILL.md
✓ created   .cursor/skills/plan-task/SKILL.md
✓ created   .vibeops.json
✓ created   .vibeops.env.example
✓ created   .gitignore

done: 14 created, 0 overwritten, 0 skipped.

단순히 설정 파일 몇 개만 만드는 것이 아닙니다.

AI가 프로젝트를 이해하고 안전하게 작업할 수 있도록 기본 문서 구조와 규칙을 함께 만듭니다.

AGENTS.md

프로젝트에서 AI 에이전트가 따라야 할 공통 규칙을 정의합니다.

새로운 AI 세션을 시작하더라도 이 문서를 기준으로 프로젝트의 작업 방식을 다시 이해할 수 있습니다.

docs/project/03-architecture.md

프로젝트의 전체 아키텍처를 기록합니다.

프론트엔드, 백엔드, 데이터베이스, 스토리지, 배포 구조처럼 장기적으로 유지해야 하는 정보를 정리합니다.

docs/project/05-current-state.md

현재 프로젝트가 어디까지 진행됐는지 기록합니다.

다른 PC나 새로운 AI 세션에서 작업을 시작할 때 가장 먼저 확인할 수 있는 문서입니다.

docs/project/06-decisions.md

프로젝트를 진행하면서 내린 중요한 결정을 기록합니다.

예를 들면 다음과 같은 내용입니다.

• 왜 GitHub를 선택했는가
• 왜 GitFlow Lite를 사용하는가
• 왜 특정 프레임워크를 선택했는가
• 어떤 대안을 검토했고 왜 제외했는가

결론만 기록하는 것이 아니라 이유도 함께 남깁니다.

그래야 나중에 새로운 AI 세션을 시작했을 때 이미 끝난 논의를 다시 반복하지 않습니다.

docs/tasks

실제 작업을 TASK 단위로 관리하는 공간입니다.

앞으로 기능을 추가할 때마다 다음과 같은 문서가 만들어집니다.

TASK-001-product-planning.md
TASK-002-project-architecture.md
TASK-003-image-upload.md

각 TASK에는 목표, 범위, 완료 조건, 구현 내용과 검증 결과가 기록됩니다.

첫 커밋은 당연히 해야 한다

기본 파일 생성이 끝나면 VibeOps가 초기 커밋을 만들 것인지 묻습니다.

Git repository

? Create initial commit?

❯ Yes
  No

첫 커밋은 당연히 진행합니다.

아직 제품 코드는 한 줄도 작성하지 않았지만, 프로젝트의 기본 구조 자체가 중요한 시작점이기 때문입니다.

Git repository

✔ Create initial commit? Yes
✔ Initial commit message Initialize AI MeteClean Project

초기 커밋 메시지는 다음과 같이 입력했습니다.

Initialize AI MeteClean Project

VibeOps가 Git 저장소와 브랜치를 자동으로 설정합니다.

Git setup:

✓ git init
✓ production branch main
✓ initial commit on main
✓ integration branch develop

결과적으로 다음 작업이 한 번에 처리됐습니다.

1. Git 저장소 초기화
2. 운영 브랜치 main 생성
3. 초기 파일 커밋
4. 통합 브랜치 develop 생성

직접 Git 명령어를 하나씩 입력해도 됩니다.

하지만 프로젝트마다 같은 과정을 반복하다 보면 브랜치 이름이나 커밋 순서에서 실수가 생기기 쉽습니다.

그래서 반복되는 Git 초기 설정도 VibeOps에 포함했습니다.

기존 GitHub 저장소 연결하기

다음으로 원격 저장소가 어디에 있는지 선택합니다.

Remote setup — used later for pull requests / merge requests.

? Where will this project's remote live?

❯ GitHub
  GitLab
  Skip for now (local only)

이번 프로젝트는 GitHub에서 진행하므로 GitHub를 선택합니다.

그러면 새 저장소를 만들지, 기존 저장소에 연결할지 묻습니다.

Create a new repository
> Connect an existing repository

앞에서 이미 GitHub에 aimetaclean 저장소를 만들어 두었으므로 기존 저장소 연결을 선택했습니다.

저장소를 미리 만들지 않았다면 VibeOps에서 새 저장소를 생성할 수도 있습니다.

다만 저장소 자동 생성과 Pull Request 관리를 사용하려면 GitHub CLI 또는 GitLab CLI가 설치돼 있어야 합니다. 물론 GitHub에 OAuth 또는 SSH Key를 등록해서 접근이 가능한 상태여야 합니다.

• GitHub: gh
• GitLab: glab

두 도구 모두 이후에도 계속 사용하게 되므로 미리 설치해 두는 편이 좋습니다.

기존 GitHub 저장소 주소를 입력합니다.

✔ Repository URL or owner/repo git@github.com:goodtekxyz/aimetaclean.git

연결이 끝나면 VibeOps가 main과 develop 브랜치를 원격 저장소에 Push합니다.

Remote bootstrap:

✓ pushed main → origin
✓ pushed develop → origin

현재까지 생성한 기본 하네스와 Git 브랜치가 모두 GitHub에 저장됐습니다.

프로젝트 초기 세팅 완료

마지막으로 VibeOps가 다음 작업을 안내합니다.

Next steps:

  1. Read AGENTS.md
  2. Cursor: @docs/tasks/TASK-001-….md in Ask, then Agent (+ /plan-task, /implement-task)
  3. vibeops llm connect — LLM for task add / task ship
  4. vibeops task add — branches from develop (pulls latest first)
  5. vibeops task ship → merge → sync — TASK lifecycle on github

이제 프로젝트의 기본 세팅은 완료됐습니다.

아직 AIMetaClean의 화면도 없고, 기술 스택도 확정하지 않았으며, 실제 기능도 하나도 구현하지 않았습니다.

하지만 중요한 기반은 만들어졌습니다.

• GitHub 원격 저장소 연결
• main과 develop 브랜치 분리
• TASK 기반 작업 구조
• 프로젝트 아키텍처 문서
• 현재 상태와 의사결정 기록
• AI 에이전트 공통 규칙
• 커밋과 Push를 위한 기본 흐름

이 상태부터는 기능이 생각날 때마다 바로 코딩하는 대신 TASK를 하나씩 추가하며 진행합니다.

vibeops task add

TASK가 만들어지면 develop을 기준으로 새로운 작업 브랜치가 자동으로 생성됩니다.

계획과 구현이 끝나면 다음 명령으로 작업을 Ship합니다.

vibeops task ship

이후 Pull Request를 병합하고 로컬 프로젝트 상태를 동기화합니다.

vibeops task merge
vibeops task sync

이 흐름을 반복하면 프로젝트의 코드와 작업 기록이 GitHub에 체계적으로 쌓입니다.

덕분에 PC에서 작업하다가 멈추더라도 다른 환경에서 다음 내용을 확인하고 바로 이어서 진행할 수 있습니다.

• 현재 진행 중인 TASK
• 지금까지 내린 결정
• 프로젝트의 전체 구조
• 완료된 작업과 남은 작업
• 작업에 사용된 Git 브랜치
• 변경된 코드와 문서
• 원격 저장소의 최신 상태

바이브코딩의 속도는 유지하면서도 프로젝트가 무질서해지는 것은 막는 방식입니다.

세팅보다 중요한 것은 계속 이어갈 수 있는 구조

작은 토이 프로젝트라면 이런 과정이 번거롭게 느껴질 수 있습니다.

폴더를 만들고 AI에게 바로 “웹사이트 하나 만들어줘”라고 말하는 편이 훨씬 빠르게 보입니다.

실제로 첫 화면이 만들어지는 속도는 그쪽이 더 빠릅니다.

문제는 그다음입니다.

기능이 늘어나고, AI 세션이 바뀌고, 다른 기기에서 작업하고, 배포 환경을 분리하기 시작하면 처음의 속도는 금방 사라집니다.

AI가 만들어 준 코드를 사람의 기억으로만 관리하기는 어렵습니다.

그래서 이번 프로젝트에서는 코드를 빠르게 만드는 것보다 언제 어디서든 안전하게 이어서 만들 수 있는 구조를 먼저 선택했습니다.

바이브코딩에도 최소한의 레일은 필요합니다.

레일이 코딩을 느리게 만드는 것이 아니라, 프로젝트가 커진 뒤 길을 잃지 않도록 해줍니다.

다음 TASK는 AIMetaClean 기획하기

프로젝트 저장소와 바이브코딩 환경 세팅은 여기까지입니다.

이제 첫 번째 실제 TASK를 시작합니다.

다음 작업은 코딩이 아니라 AIMetaClean의 제품 기획입니다.

아직 정해야 할 것이 많습니다.

• AIMetaClean이 해결할 핵심 문제는 무엇인가
• 가장 먼저 사용할 사람은 누구인가
• 어떤 이미지 형식을 지원할 것인가
• 어떤 메타데이터를 확인할 것인가
• 삭제와 보존 정책을 어떻게 나눌 것인가
• C2PA와 Content Credentials를 어떻게 다룰 것인가
• 브라우저에서 처리할 것인가, 서버에서 처리할 것인가
• 무료 서비스의 범위는 어디까지인가
• 첫 번째 MVP에는 무엇을 넣고 무엇을 제외할 것인가

다음 글에서는 VibeOps로 첫 TASK를 만들고, AI와 함께 AIMetaClean의 제품 기획을 시작해 보겠습니다.

아이디어 하나가 실제 서비스로 출시될 수 있을지.

기획과 개발은 물론 출시 이후의 홍보와 사용자 반응까지 계속 공개하겠습니다.

AIMetaClean 빌드인퍼블릭 진행 과정

• 아이디어 발견
• 프로젝트 환경 세팅 ← 현재
• 제품 기획
• 기술 스택과 아키텍처 결정
• MVP 개발
• 배포
• 사용자 모집
• 출시와 홍보
• 실제 반응과 개선

완성된 결과만 보여주는 것이 아니라, 만들어지는 과정을 전부 기록합니다.