AIMetaClean이라는 웹서비스를 새로 만들기 시작했습니다.
이번에는 완성된 결과만 소개하지 않고,
아이디어 → 기획 → 개발 → 배포 → 출시 → 홍보 → 사용자 반응
까지 전 과정을 빌드인퍼블릭으로 공개해 보려고 합니다.
잘된 선택만 정리하지 않고, 중간에 방향이 바뀌거나 실패한 부분도 가능한 한 그대로 기록할 생각입니다.
이번 글은 첫 번째 기록입니다.
아직 화면도 없고 기능도 없습니다.
대신 앞으로 PC와 모바일 어디서든 프로젝트를 이어서 개발할 수 있도록 바이브코딩 환경과 프로젝트 관리 구조부터 만들었습니다.
AIMetaClean은 어떤 서비스인가
AIMetaClean은 AI 이미지에 포함된 생성 정보와 메타데이터를 확인하고 정리하는 서비스입니다.
아이디어는 조금 특이한 경험에서 시작됐습니다.
제 실제 사진으로는 SNS 셀피 인증에 실패했는데, AI로 만든 사람 사진은 통과했습니다.
물론 AI 이미지가 통과한 이유가 메타데이터 때문이라고 단정할 수는 없습니다.
하지만 그 일을 겪고 나니 이런 궁금증이 생겼습니다.
AI로 만든 이미지에는 어떤 정보가 들어 있고,
이미지를 공개할 때 그 정보는 어디까지 함께 전달될까?
AI 이미지는 단순한 픽셀 파일처럼 보이지만, 생성 도구에 따라 다양한 정보가 포함될 수 있습니다.
-
사용한 프롬프트
-
네거티브 프롬프트
-
생성 모델과 버전
-
시드 값
-
샘플러와 스텝
-
CFG 설정
-
LoRA와 ControlNet 정보
-
Stable Diffusion 생성 파라미터
-
ComfyUI 워크플로
-
C2PA와 Content Credentials
-
일반 EXIF와 위치 정보
창작자 입장에서는 유용한 제작 기록이지만, 외부 공개나 고객 납품 시에는 감추고 싶은 정보가 될 수도 있습니다.
그래서 일반적인 사진 EXIF 삭제 도구가 아니라, AI 이미지에 남아 있는 생성·편집·출처 정보를 확인하고 목적에 맞게 정리하는 도구를 만들어 보기로 했습니다.
아이디어가 시작된 자세한 이야기는 아래 글에 먼저 정리했습니다.
👉 [AIMetaClean] 진짜 사람 사진은 실패했고, AI 사진은 통과했다
이번 프로젝트는 Codex를 중심으로 진행합니다
이번 프로젝트에서는 Codex를 주 개발 도구로 사용할 예정입니다.
작업 성격에 따라 GPT-5.6의 여러 모델도 적절히 섞어서 사용해 보려고 합니다.
-
Luna: 빠르게 방향을 잡거나 반복 작업을 처리할 때
-
Terra: 일반적인 구현과 문서 작업
-
Sol: 구조 설계나 복잡한 판단이 필요한 작업
특정 모델 하나만 고정해서 사용하는 것이 아니라, 작업의 난이도와 목적에 따라 나누어 사용할 생각입니다.
개발은 PC에서만 하지 않습니다.
모바일 ChatGPT에서도 프로젝트의 현재 상태를 확인하고, 다음 작업을 계획하거나 TASK를 정리할 수 있도록 설정할 예정입니다.
목표는 단순합니다.
PC에서 작업하다가 멈춰도, 모바일이나 다른 환경에서 현재 상태를 잃지 않고 다시 이어서 개발한다.
바이브코딩을 하다 보면 코드 자체보다 이전 세션의 맥락을 잃는 문제가 더 크게 느껴질 때가 있습니다.
새로운 세션을 열 때마다 AI에게 프로젝트를 다시 설명해야 하고, 이미 끝난 논의를 반복하거나 기존 구조와 다른 방향으로 코드를 작성하는 일도 생깁니다.
그래서 이번에는 코드를 만들기 전에 먼저 프로젝트의 맥락을 유지할 구조부터 준비했습니다.
프로젝트 저장소는 GitHub로 선택했습니다
이번 프로젝트는 비교적 가볍게 시작할 예정이고, 향후 오픈소스 전환도 고려하고 있습니다.
그래서 원격 저장소는 GitHub를 선택했습니다.
먼저 GitHub에 Private 저장소를 하나 만들었습니다.
aimetaclean
저장소 주소는 다음과 같습니다.
git@github.com:goodtekxyz/aimetaclean.git
아직 제품 구조와 비즈니스 방향이 확정되지 않았기 때문에 우선 Private으로 시작했습니다.
프로젝트가 어느 정도 안정되면 공개 저장소로 전환하는 것도 고려하고 있습니다.
GitHub와 GitLab 중 무엇을 골라야 할지 고민된다면, 프로젝트 공개 여부와 운영 방식을 기준으로 보면 됩니다.
-
오픈소스와 외부 공개가 중요하면 GitHub
-
자체 서버와 CI/CD 통제가 중요하면 GitLab
-
작은 사이드 프로젝트라면 익숙한 쪽
-
운영 인프라까지 직접 관리한다면 GitLab도 좋은 선택
이번 AIMetaClean에는 GitHub가 조금 더 잘 맞는다고 판단했습니다.
GitHub와 GitLab 비교는 더 자세히 비교한 글을 참조하시면 좋을 것 같네요.
👉 GitHub vs GitLab, 바이브코더는 무엇을 골라야 할까
VibeOps로 프로젝트에 기본 레일을 깔았습니다
전체적인 프로젝트 관리는 제가 만든 VibeOps라는 도구를 사용합니다.
VibeOps는 바이브코딩 프로젝트를 TASK 단위로 관리하는 CLI 도구입니다.
AI가 직접 코드를 작성하더라도 프로젝트가 무질서하게 변경되지 않도록 다음 흐름을 관리합니다.
TASK 생성
→ 작업 브랜치 생성
→ 계획 작성
→ 구현
→ 문서 업데이트
→ 커밋
→ Push
→ Pull Request
→ develop 병합
→ main 배포
VibeOps가 직접 코딩하는 것은 아닙니다.
Cursor, Claude Code, Codex 같은 코딩 에이전트가 실제 작업을 하고, VibeOps는 그 작업이 프로젝트 규칙 안에서 진행되도록 관리합니다.
예를 들면 다음과 같은 부분입니다.
-
TASK마다 별도 브랜치 생성
-
작업 전 계획 문서 작성
-
완료 조건 기록
-
구현 후 프로젝트 문서 업데이트
-
커밋과 Push
-
Pull Request 생성
-
병합 후 로컬 브랜치 정리
VibeOps를 사용하지 않는다면 이 과정을 직접 관리하면 됩니다.
중요한 것은 도구가 아니라 AI에게 바로 코드를 맡기기 전에 작업 단위를 분리하고 기록을 남기는 것입니다.
VibeOps 저장소는 아래에서 확인할 수 있습니다.
👉 https://github.com/goodtekxyz/vibeops
구독 중인 LLM을 OAuth로 연결했습니다
VibeOps는 별도의 API 키를 입력해서 매번 사용량만큼 결제하는 방식 대신, 현재 구독 중인 LLM 서비스를 OAuth로 연결해서 사용할 수 있도록 만들었습니다.
먼저 다음 명령어로 LLM을 연결합니다.
vibeops llm connect
연결된 LLM은 다음과 같은 작업을 보조합니다.
-
새로운 TASK 초안 작성
-
작업 목표와 완료 조건 정리
-
변경 내용 요약
-
커밋 메시지 작성
-
Pull Request 설명 생성
-
Ship 단계에서 누락된 문서 확인
이번에는 Cursor 구독을 연결해 사용해 보기로 했습니다.
실제 구현은 Codex를 중심으로 진행하더라도, TASK 관리와 문서 정리에는 다른 LLM을 함께 사용할 수 있습니다.
프로젝트를 초기화했습니다
GitHub 저장소를 만든 다음 프로젝트 폴더에서 아래 명령어를 실행했습니다.
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를 선택했습니다.
브랜치 정책은 GitFlow Lite로 정했습니다
다음으로 브랜치 정책을 선택합니다.
Branch policy
? Branch policy
❯ GitFlow lite — develop (integration) + main (production)
Trunk — main only (integration and production = main)
Custom branch names
AIMetaClean은 개발 서버와 운영 서버를 나누어 진행할 예정입니다.
그래서 develop과 main을 분리하는 GitFlow Lite를 선택했습니다.
브랜치 흐름은 다음과 같습니다.
task/* → develop → main
각 브랜치의 역할은 단순합니다.
-
task/*: 개별 기능 작업 -
develop: 개발 서버와 통합 테스트 -
main: 운영 서버와 실제 배포
작업을 시작하면 develop에서 새로운 TASK 브랜치가 생성됩니다.
기능 구현이 끝나면 develop에 병합하고 개발 서버에서 먼저 확인합니다.
문제가 없으면 main으로 병합해 운영 서버에 배포합니다.
혼자 만드는 작은 프로젝트에서는 main 하나만 사용해도 충분합니다.
하지만 실제 서비스를 운영할 계획이라면 개발 중인 코드와 운영 중인 코드를 분리하는 편이 안전합니다.
초기화 후 프로젝트 하네스가 자동 생성됐습니다
설정을 마치면 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 에이전트가 지켜야 할 공통 규칙을 기록합니다.
새로운 세션을 시작하더라도 이 문서를 기준으로 작업 방식을 다시 이해할 수 있습니다.
docs/project/03-architecture.md
프로젝트의 전체 구조를 기록합니다.
프론트엔드, 백엔드, 데이터베이스, 스토리지, 인증, 배포 구조 같은 내용을 계속 업데이트합니다.
docs/project/05-current-state.md
현재 프로젝트가 어디까지 진행됐는지 기록합니다.
다른 PC나 모바일에서 작업을 이어갈 때 가장 먼저 확인할 문서입니다.
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에는 목표, 작업 범위, 완료 조건, 구현 결과와 검증 내용이 포함됩니다.
Git 저장소와 원격 브랜치까지 한 번에 설정했습니다
기본 파일을 만든 다음 첫 커밋을 생성했습니다.
Git repository
? Create initial commit?
❯ Yes
No
아직 실제 제품 코드는 없지만, 프로젝트의 하네스 구조 자체가 첫 번째 중요한 변경사항이기 때문에 바로 커밋했습니다.
✔ Create initial commit? Yes
✔ Initial commit message Initialize AI MetaClean Project
VibeOps가 다음 작업을 자동으로 처리했습니다.
Git setup:
✓ git init
✓ production branch main
✓ initial commit on main
✓ integration branch develop
이후 원격 저장소 위치로 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 저장소는 이미 만들어 둔 상태라 기존 저장소 연결을 선택했습니다.
Create a new repository
> Connect an existing repository
저장소 주소를 입력했습니다.
✔ Repository URL or owner/repo git@github.com:goodtekxyz/aimetaclean.git
연결이 끝나자 main과 develop 브랜치가 모두 GitHub에 Push됐습니다.
Remote bootstrap:
✓ pushed main → origin
✓ pushed develop → origin
이제 로컬 프로젝트가 없어지거나 다른 PC에서 작업하더라도 GitHub에서 다시 받아 이어서 진행할 수 있습니다.
앞으로는 TASK를 하나씩 추가하며 개발합니다
초기 설정이 끝났으니 앞으로는 기능이 생각날 때마다 바로 코딩하지 않고 TASK를 먼저 추가합니다.
vibeops task add
TASK가 만들어지면 최신 develop을 기준으로 새로운 작업 브랜치가 생성됩니다.
계획과 구현이 끝나면 작업을 Ship합니다.
vibeops task ship
이 과정에서 변경된 코드와 문서가 확인되고, 커밋과 Push, Pull Request 생성까지 이어집니다.
병합 후에는 다음 작업을 진행합니다.
vibeops task merge
vibeops task sync
이 흐름을 반복하면 다음 정보가 GitHub와 프로젝트 문서에 함께 쌓입니다.
-
현재 진행 중인 작업
-
완료된 작업
-
남아 있는 작업
-
프로젝트 아키텍처
-
중요한 기술적 결정
-
각 기능이 만들어진 브랜치
-
코드 변경 내용
-
테스트와 검증 결과
AI가 아무리 빠르게 코드를 만들어도 이런 기록이 없으면 프로젝트가 커질수록 관리가 어려워집니다.
반대로 최소한의 구조만 잡아두면 새로운 AI 세션이나 다른 기기에서도 이전 맥락을 빠르게 복원할 수 있습니다.
바이브코딩에서도 속도보다 먼저 필요한 것
폴더를 하나 만들고 AI에게 “서비스 하나 만들어줘”라고 요청하면 첫 화면은 빠르게 나옵니다.
처음에는 그것이 가장 효율적으로 보입니다.
하지만 기능이 늘어나면 상황이 달라집니다.
-
AI 세션마다 프로젝트를 다시 설명해야 합니다.
-
이미 결정한 기술을 다시 논의합니다.
-
브랜치와 커밋이 뒤섞입니다.
-
문서와 실제 코드가 달라집니다.
-
모바일에서 작업을 이어가기 어렵습니다.
-
어느 기능이 완료됐는지 알기 어려워집니다.
그래서 이번 프로젝트에서는 화면을 빠르게 만드는 것보다 프로젝트를 계속 이어갈 수 있는 구조를 먼저 선택했습니다.
바이브코딩에도 최소한의 레일은 필요합니다.
그 레일이 AI의 속도를 늦추는 것이 아니라, 프로젝트가 커졌을 때 길을 잃지 않게 해준다고 생각합니다.
다음 빌드인퍼블릭은 제품 기획입니다
프로젝트 저장소와 바이브코딩 환경 설정은 여기까지입니다.
다음 작업은 AIMetaClean의 제품 기획입니다.
아직 결정해야 할 내용이 많습니다.
-
누구를 위한 서비스인가
-
사용자가 가장 불편해하는 문제는 무엇인가
-
어떤 이미지 형식을 지원할 것인가
-
어떤 AI 메타데이터를 찾을 것인가
-
어떤 정보는 삭제하고 어떤 정보는 보존할 것인가
-
C2PA와 Content Credentials는 어떻게 처리할 것인가
-
이미지를 서버에 업로드할 것인가
-
브라우저 안에서 처리할 수 있는가
-
무료 사용 범위는 어디까지인가
-
실제 수익화 가능성이 있는가
-
첫 MVP에서 제외할 기능은 무엇인가
다음 글에서는 첫 TASK를 만들고, 이 질문들을 하나씩 정리해 보겠습니다.
아이디어 하나가 실제 제품이 될 수 있을지, 출시 후 사람들이 사용할지 아직은 알 수 없습니다.
기획부터 개발, 배포, 출시와 홍보까지 계속 공개하겠습니다.
📌 AIMetaClean 빌드인퍼블릭 진행 상황
-
✅ 아이디어 발견
-
✅ 프로젝트 환경 세팅
-
⏳ 제품 기획
-
⏳ 기술 스택과 아키텍처 결정
-
⏳ MVP 개발
-
⏳ 개발·운영 서버 배포
-
⏳ 사용자 모집
-
⏳ 제품 출시와 홍보
-
⏳ 실제 사용자 반응과 개선
전체 명령어와 터미널 실행 과정은 블로그에 더 자세히 정리했습니다.