지난 글에서는 AI Meta Clean을 바이브코딩하기 위한 하네스와 개발환경을 세팅했습니다.

Git 저장소를 만들고 브랜치 전략을 정하고, AI가 프로젝트의 현재 상태를 이해할 수 있도록 기본 문서도 준비했습니다.

솔직히 여기까지는 제품을 만든다기보다 제품을 만들 수 있는 환경을 만드는 과정에 가까웠습니다.

화면도 없고, 기능도 없고, 사용자에게 보여줄 만한 결과물도 아직 없습니다.

그래도 이 과정을 먼저 해둔 이유가 있습니다.

AI와 개발하다 보면 처음에는 빠르게 무언가가 만들어집니다. 그런데 작업이 조금만 길어져도 브랜치가 꼬이고, 이전에 내린 결정이 사라지고, 새로운 세션을 열 때마다 같은 설명을 반복하게 됩니다.

그래서 이번에는 서두르지 않고 바닥부터 깔았습니다.

그리고 이제 정말 첫 번째 작업을 시작합니다.

TASK-001

첫 번째 작업은 AI Meta Clean의 제품 기획입니다.

저는 AI와 개발할 때 작업 단위를 먼저 만듭니다

저는 AI와 개발할 때 하나의 작업을 가능한 한 되돌릴 수 있는 단위로 나눕니다.

기능 하나가 될 수도 있고, 설계 하나가 될 수도 있고, 이번처럼 제품 기획 문서 하나가 될 수도 있습니다.

제가 생각하는 기준은 단순합니다.

이 작업만 따로 검토하고, 병합하고, 필요하면 되돌릴 수 있는가?

그렇다면 하나의 TASK로 만듭니다.

각 TASK는 별도의 브랜치에서 진행합니다.

develop
└── task/001-ai-meta-clean-project-product-planning

작업 방향이 잘못되거나 내용이 크게 바뀌어도 develop 브랜치에는 영향을 주지 않습니다.

작업이 끝난 뒤 결과를 검토하고 병합해야 비로소 프로젝트의 공식적인 결과가 됩니다.

이 흐름을 매번 Git 명령어로 직접 관리할 수도 있지만, 저는 제가 만든 vibeops를 사용하고 있습니다.

전체적인 작업 흐름은 다음과 같습니다.

이번 TASK에서는 코드를 구현하지 않습니다.

제품이 무엇인지부터 정합니다.

TASK-001 생성하기

프로젝트 디렉터리에서 다음 명령어를 실행했습니다.

vibeops task add

그러자 현재 어떤 일을 하려고 하는지 짧게 입력하라는 질문이 나왔습니다.

✔ What are you doing now? (short)

여기에 다음과 같이 입력했습니다.

AI Meta Clean Project 제품기획

전체 실행 결과는 다음과 같습니다.

goodtek aimetaclean % vibeops task add
vibeops task add

→ Checking integration branch…
Integration develop is ready.

✔ What are you doing now? (short) AI Meta Clean Project 제품기획
· Scaffold via codex-oauth
✓ Created TASK-001 → docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md

→ Starting task branch…
  integration  develop @ 95fbbd4
  task branch  task/001-ai-meta-clean-project-product-planning
Stashed governance-only changes (.vibeops/, docs/) before branch switch.
Restored stashed governance paths on the task branch.
✓ Branch task/001-ai-meta-clean-project-product-planning ready
  file         docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md

Next in Cursor
  Ask:  @docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md — plan Scope / Acceptance Criteria
  Agent: same file — implement
  Ship: vibeops task ship TASK-001

goodtek aimetaclean %

입력한 작업 내용을 바탕으로 vibeops가 TASK 번호와 파일명, 브랜치명을 자동으로 만들었습니다.

생성된 TASK 문서는 다음과 같습니다.

docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md

작업 브랜치도 자동으로 생성되고 체크아웃되었습니다.

task/001-ai-meta-clean-project-product-planning

현재 브랜치를 확인해 봤습니다.

git branch

  develop
  main
* task/001-ai-meta-clean-project-product-planning

별도의 Git 명령어로 브랜치를 만들거나 체크아웃하지 않았지만, 이미 작업 브랜치에 들어와 있습니다.

이제부터 작성되는 제품 기획 문서는 이 브랜치 안에서만 관리됩니다.

제품 기획은 AI에게 한 번에 맡기지 않았습니다

제품 기획을 할 때 AI에게 이렇게 요청할 수도 있습니다.

AI Meta Clean 제품 기획서를 작성해 줘.

그러면 그럴듯한 문서는 빠르게 만들어집니다.

문제는 그 문서가 내가 만들고 싶은 제품의 기획서인지, 아니면 AI가 제품 이름만 보고 추측해서 만든 문서인지 알기 어렵다는 것입니다.

그래서 저는 바로 기획서를 작성해 달라고 하지 않았습니다.

먼저 저에게 필요한 질문을 해달라고 요청했습니다.

AI Meta Clean이라는 제품 기획을 하려고 합니다.

저에게 필요한 질문을 해주시고 분석이 완료되면
TASK-001-ai-meta-clean-project-product-planning.md에 정리해 주세요.

제가 생각하는 AI와의 제품 기획은 문서를 대신 작성하게 하는 일이 아닙니다.

AI가 질문하고, 제가 답하고, 다시 AI가 빈틈을 찾고, 제가 판단하는 티키타카의 과정에 가깝습니다.

좋은 답을 받으려면 먼저 좋은 질문이 나와야 합니다.

Codex가 제품 기획 전에 물어본 것들

Codex는 현재 TASK 문서에 기본적인 구조만 있고 제품 정의는 비어 있다고 판단했습니다.

그리고 바로 기획서를 작성하는 대신 여덟 가지 질문을 했습니다.

1. AI Meta Clean이 정리하려는 ‘메타’는 무엇인가?

제품 이름에는 Meta라는 단어가 들어가지만, 메타데이터의 범위는 매우 넓습니다.

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

• 이미지와 영상의 EXIF 및 위치정보
• 문서 안에 포함된 작성자와 개인정보
• 웹사이트와 소셜 계정의 데이터
• AI 생성물에 포함된 메타데이터
• 파일의 생성 도구와 편집 이력

이 범위를 먼저 정하지 않으면 서비스의 형태 자체가 완전히 달라질 수 있습니다.

2. 주요 고객은 누구인가?

Codex는 다음 사용자 중 누구를 우선 대상으로 할 것인지 물었습니다.

• 개인 사용자
• 콘텐츠 제작자
• 기업 보안팀
• 에이전시
• 개발자

모두 잠재 고객이 될 수 있지만, 첫 버전부터 모두를 만족시키려고 하면 제품이 복잡해집니다.

MVP에서는 개인 사용자와 콘텐츠 제작자, 그리고 이미지 자산을 자주 사용하는 바이브코딩 개발자를 주요 사용자로 보기로 했습니다.

3. 사용자는 언제 이 제품을 사용하는가?

기능보다 중요한 질문이었습니다.

사용자가 정확히 어떤 순간에 이 서비스를 찾는지 생각해 봤습니다.

• 중고거래 사이트에 집에서 찍은 사진을 올리기 전
• SNS에 스마트폰 사진을 공유하기 전
• 고객에게 이미지 파일을 전달하기 전
• 랜딩페이지나 서비스 데모에 이미지 자산을 넣기 전
• 외부 커뮤니티에 스크린샷이나 사진을 첨부하기 전

사용 상황을 구체적으로 떠올리니 필요한 기능과 필요하지 않은 기능이 조금씩 구분되기 시작했습니다.

4. 해결하려는 핵심 문제는 무엇인가?

단순히 메타데이터를 지운다는 것만으로는 부족합니다.

사용자가 겪는 문제와 제품이 제공할 해결 방식을 다음처럼 정리했습니다.

이 과정을 거치며 제품의 핵심이 단순한 삭제 기능만은 아니라는 점도 알게 됐습니다.

사용자가 무엇이 들어 있는지 이해하고, 무엇을 제거했는지 확인할 수 있어야 한다는 것이 더 중요했습니다.

5. 첫 출시는 어떤 형태로 할 것인가?

Codex는 다음 선택지를 제시했습니다.

• 웹 서비스
• 데스크톱 앱
• 모바일 앱
• 브라우저 확장 프로그램
• API
• CLI

저는 우선 웹 서비스로 시작하기로 했습니다.

사용자가 별도의 프로그램을 설치하지 않고 파일을 올린 뒤, 결과를 바로 내려받을 수 있어야 하기 때문입니다.

제가 참고한 사용 경험은 remove.bg였습니다.

복잡한 설정 화면보다는 다음처럼 단순한 흐름을 원했습니다.

이미지 업로드
    ↓
메타데이터 확인
    ↓
정리 실행
    ↓
결과 확인
    ↓
다운로드

6. MVP에 무엇을 넣고 무엇을 뺄 것인가?

제품 기획에서 기능을 정하는 것만큼 중요한 것이 있습니다.

바로 처음에는 하지 않을 일을 정하는 것입니다.

MVP에는 다음 기능을 포함하기로 했습니다.

• 이미지 업로드
• 메타데이터 조회
• 제거 항목 선택
• 전체 메타데이터 정리
• 제거된 항목과 유지된 항목 확인
• 정리된 파일 다운로드
• 처리 파일 자동 삭제

반면 다음 기능은 초기 버전에서 제외했습니다.

• 사용자 계정
• 처리 이력
• 여러 이미지 일괄 처리
• API 및 CLI
• 유료 구독
• 고급 이미지 포맷 전체 지원
• 장기 파일 보관

좋은 아이디어가 떠오를 때마다 기능을 추가하면 MVP는 끝나지 않습니다.

이번에는 한 장의 이미지를 안전하고 이해하기 쉽게 정리하는 경험만 완성하기로 했습니다.

7. 데이터와 보안은 어떻게 처리할 것인가?

이미지를 다루는 서비스이기 때문에 이 질문을 가볍게 넘길 수 없었습니다.

다음 원칙을 먼저 정했습니다.

• 원본 파일을 영구적으로 보관하지 않는다.
• 결과 파일도 영구적으로 보관하지 않는다.
• 처리한 이미지를 AI 학습이나 다른 목적으로 사용하지 않는다.
• 삭제 시점과 처리 방식을 사용자에게 명확히 알린다.
• 다운로드 주소는 다른 사용자가 추측할 수 없도록 한다.
• 파일은 사용자 세션 단위로 격리한다.

아직 브라우저에서 직접 처리할지 서버에서 처리할지는 결정하지 않았습니다.

그것은 기술 타당성 조사 이후에 선택할 문제입니다.

이번 TASK에서는 구현 방식보다 제품이 반드시 지켜야 하는 원칙을 먼저 정했습니다.

8. 어떤 제품처럼 느껴져야 하는가?

제품의 기능이 같아도 사용자가 받는 느낌은 전혀 다를 수 있습니다.

AI Meta Clean은 보안 도구처럼 어렵고 무거운 서비스보다는, 누구나 바로 사용할 수 있는 친근한 도구가 되어야 합니다.

제가 원하는 기준은 다음과 같았습니다.

• 별도의 설명서를 읽지 않아도 사용할 수 있을 것
• 전문 용어를 그대로 노출하지 않을 것
• 업로드부터 다운로드까지 단계가 짧을 것
• 제거된 정보와 남아 있는 정보를 숨기지 않을 것
• 프라이버시를 강조하되 불안감을 과도하게 자극하지 않을 것

그런데 원래 생각했던 제품은 조금 달랐습니다

사실 AI Meta Clean을 처음 떠올렸을 때의 목적은 지금 정리된 제품 기획과 조금 달랐습니다.

원래는 이미지에 포함된 일반적인 위치정보나 촬영기기 정보뿐만 아니라, AI 생성·편집과 관련해 남아 있는 메타 정보도 확인하고 정리하는 서비스를 생각했습니다.

AI로 이미지를 생성하거나 편집한 뒤 파일을 확인해 보면, 사용한 도구나 편집 과정과 관련된 정보가 남아 있는 경우가 있습니다.

제가 생각한 출발점은 단순했습니다.

내 파일 안에 어떤 정보가 들어 있는지 확인하고, 필요하지 않은 정보는 내가 직접 정리할 수 있게 하자.

특정 플랫폼을 속이거나 불법적인 목적으로 사용하려는 것은 아니었습니다.

파일의 주인이 자신의 파일 안에 있는 정보를 확인하고 관리할 수 있게 하자는 정도였습니다.

그런데 GPT와 제품을 기획하다가 예상하지 못한 벽을 만났습니다.

제가 지금까지 사용해 본 AI 중에서 GPT는 아마 가장 윤리적인 놈입니다.

정말 제가 조금이라도 윤리적으로 어긋날 가능성이 있는 일을 하는 꼴을 못 봅니다. ㅋㅋㅋ

위험한 목적으로 만들려는 것이 아니라고 설명했지만, GPT는 AI 생성 사실을 숨기거나 플랫폼의 표시와 탐지를 우회하는 기능으로 사용될 가능성을 계속 경계했습니다.

그래서 완성된 기획 문서에는 다음과 같은 내용이 아주 단호하게 들어갔습니다.

- AI 생성 여부를 숨기거나 일반 사진으로 위장하는 기능 제외
- 플랫폼의 AI 탐지·라벨링·콘텐츠 정책을 우회하는 기능 제외
- 특정 플랫폼에서 AI 이미지로 인식되지 않는다는 보장 제외

처음에는 제 의도와 조금 다르게 해석된 것 같아서 다시 설명해 볼까도 생각했습니다.

하지만 GPT를 설득할 힘도 없고, 사실 설득할 수도 없습니다.

여기에서 계속 실랑이하다가는 첫 번째 TASK부터 끝나지 않을 것 같았습니다.

그래서 일단 결론을 내렸습니다.

GPT가 안 된다고 하는 부분은 빼고 먼저 진행하자. ㅋㅋㅋ

현재 MVP에서는 AI 탐지 회피나 AI 생성 사실 은폐와 관련된 부분은 빼고, 이미지 파일에 포함된 일반적인 메타데이터를 확인하고 정리하는 프라이버시 도구로 범위를 좁혔습니다.

우선 다룰 대상은 다음과 같습니다.

• GPS 위치정보
• 촬영 날짜와 시간
• 촬영기기 제조사와 모델
• 작성자 정보
• 저작권과 설명
• 사용한 소프트웨어
• EXIF, XMP, IPTC 등 파일 내부 메타데이터

AI 생성·편집과 관련된 메타데이터를 기술적으로 어디까지 읽을 수 있는지, 그리고 일반 메타데이터와 어떻게 구분되는지는 다음 기술 타당성 조사에서 확인할 생각입니다.

다만 현재 제품의 공식적인 목적은 명확하게 정리했습니다.

사용자가 이미지 파일 안에 어떤 정보가 들어 있는지 확인하고, 개인정보와 불필요한 메타데이터를 스스로 정리할 수 있게 한다.

처음 생각했던 아이디어와 완전히 같지는 않지만, 첫 번째 버전으로는 오히려 범위가 더 선명해졌습니다.

이런 것도 AI와 제품을 기획하면서 실제로 생기는 일입니다.

AI가 시키는 대로 제품을 만드는 것은 아니지만, AI가 강하게 제동을 거는 부분에서 첫 TASK부터 끝없는 토론을 벌일 필요도 없습니다.

일단 만들 수 있는 범위부터 만들고, 실제 기술과 사용자의 요구를 확인하면서 다음 판단을 하면 됩니다.

질문에 답하자 제품이 한 문장으로 정리됐습니다

제가 질문에 답한 뒤 Codex는 제품을 다음과 같이 정의했습니다.

AI Meta Clean은 이미지 파일에 남아 있는 위치·기기·편집 이력 등 불필요한 메타데이터를 확인하고, 원본을 보관하지 않은 채 내려받기용 정리본을 만드는 간편한 웹 서비스다.

처음에는 저도 ‘이미지 메타데이터를 지우는 서비스’ 정도로 생각했습니다.

하지만 질문에 답하며 제품의 의미가 조금 더 구체적으로 바뀌었습니다.

단순히 지우는 것이 아니라 다음 경험을 제공하는 제품입니다.

1. 이미지에 어떤 정보가 들어 있는지 알려준다.
2. 사용자가 제거할 정보를 선택할 수 있게 한다.
3. 실제로 제거된 정보와 남은 정보를 보여 준다.
4. 정리된 파일을 바로 내려받게 한다.
5. 처리한 파일을 서비스에 남겨두지 않는다.

한 줄 정의가 정리되니 이후 기능의 우선순위를 판단하기도 쉬워졌습니다.

제품의 비전과 핵심 원칙

Codex와 대화하며 정리한 제품 비전은 다음과 같습니다.

누구나 이미지를 공유하기 전에 공개될 수 있는 정보를 이해하고 스스로 통제할 수 있게 한다.

핵심 가치는 네 가지입니다.

이 원칙은 앞으로 기술을 선택할 때도 기준이 됩니다.

예를 들어 어떤 라이브러리가 더 많은 메타데이터를 제거할 수 있더라도, 원본 화질을 심하게 떨어뜨리거나 제거 결과를 검증하기 어렵다면 제품의 원칙과 맞지 않을 수 있습니다.

핵심 사용자 정의

초기 사용자는 크게 세 그룹으로 나눴습니다.

여기에서 바이브코딩 개발자를 넣은 것은 제가 실제로 자주 겪는 상황이기 때문입니다.

서비스를 만들다 보면 스크린샷, AI 생성 이미지, 휴대전화로 촬영한 사진을 문서나 랜딩페이지에 자주 사용합니다.

그때마다 이 이미지에 어떤 정보가 포함되어 있는지 확인하기는 쉽지 않습니다.

제가 직접 필요하다고 느낀 문제이기 때문에 제품을 만들면서도 사용자의 상황을 구체적으로 떠올릴 수 있습니다.

MVP에서 구현할 기능

첫 번째 버전은 로그인 없이 하나의 이미지를 처리하는 흐름에 집중합니다.

1. 파일 업로드

사용자는 이미지를 끌어다 놓거나 파일 선택 창에서 고를 수 있습니다.

지원하지 않는 형식이나 용량 제한이 있다면 업로드 이후가 아니라 가능한 한 빠르게 알려줘야 합니다.

2. 메타데이터 조회

업로드한 파일에서 실제로 탐지된 정보를 범주별로 보여 줍니다.

예상하는 주요 범주는 다음과 같습니다.

• 파일 기본 정보
• EXIF
• XMP
• IPTC
• GPS 위치정보
• 촬영기기 정보
• 작성자 정보
• 저작권 및 설명
• 편집 도구 및 생성 이력

모든 항목을 기술적인 키와 값으로만 보여 주면 일반 사용자는 이해하기 어렵습니다.

가능하면 다음처럼 사람이 읽기 쉬운 표현으로 바꿔야 합니다.

GPSLatitude
→ 촬영 위치의 위도 정보

Make / Model
→ 사진을 촬영한 기기 제조사와 모델

Software
→ 이미지를 생성하거나 편집한 프로그램

3. 메타데이터 정리

사용자는 제거할 항목을 직접 선택하거나 전체 정리를 실행할 수 있습니다.

초기에는 복잡한 세부 옵션보다 몇 가지 정리 수준을 제공하는 방식도 고려할 수 있습니다.

기본 정리
- 위치정보 제거
- 촬영기기 정보 제거

개인정보 중심 정리
- 위치정보 제거
- 작성자 정보 제거
- 기기정보 제거

전체 정리
- 제거 가능한 메타데이터 모두 제거

실제로 어떤 항목까지 안전하게 제거할 수 있는지는 다음 기술 조사 TASK에서 확인해야 합니다.

4. 결과 확인

처리가 끝난 뒤 단순히 완료라고만 표시해서는 안 됩니다.

사용자가 확인해야 할 정보는 다음과 같습니다.

• 제거된 항목
• 유지된 항목
• 제거할 수 없었던 항목
• 처리 실패 또는 제한 사유
• 파일 변환 여부
• 이미지 재인코딩 여부
• 처리 전후 파일 크기

이 부분이 제품의 신뢰를 만드는 핵심이라고 생각합니다.

5. 파일 다운로드

정리가 완료된 파일은 바로 내려받을 수 있어야 합니다.

초기 버전에서는 회원가입이나 이메일 입력을 요구하지 않습니다.

파일명은 원본과 구분할 수 있도록 변경합니다.

original.jpg
→ original-cleaned.jpg

6. 파일 자동 삭제

원본과 결과 파일은 처리 목적이 끝나면 삭제합니다.

구현 방식에 따라 다음 중 하나가 될 수 있습니다.

• 다운로드 완료 직후 삭제
• 짧은 세션 만료 후 삭제
• 브라우저에서만 처리하여 서버에 업로드하지 않음

어떤 방식을 선택하든 사용자에게 삭제 시점과 조건을 정확히 알려야 합니다.

의도적으로 제외한 기능

앞서 이야기했듯이 AI Meta Clean이라는 이름 때문에 AI 생성 이미지의 흔적을 숨기는 서비스로 오해될 수 있습니다.

하지만 현재 기획된 AI Meta Clean은 플랫폼의 AI 탐지나 라벨링을 피하기 위한 도구가 아닙니다.

다음 기능은 현재 제품 범위에서 제외했습니다.

• 이미지 픽셀을 조작해 AI 탐지를 피하는 기능
• AI 생성 또는 편집 사실을 일반 사진처럼 위장하는 기능
• 플랫폼의 AI 표시 정책을 우회하는 기능
• 특정 플랫폼에서 AI 이미지로 인식되지 않는다고 보장하는 기능
• AI 탐지 성공률을 제품의 성능 지표로 사용하는 것

이미지 메타데이터를 제거하는 것과 플랫폼이 AI 이미지를 탐지하는 것은 다른 문제입니다.

플랫폼은 파일 안의 메타데이터 외에도 여러 신호를 사용할 수 있습니다.

• 이미지 자체의 패턴
• 업로드 방식
• 계정의 활동
• 파일 인코딩 특성
• 콘텐츠 출처
• 플랫폼 내부의 별도 분석

따라서 현재 AI Meta Clean은 제품이 실제로 확인하고 통제할 수 있는 범위만 다룹니다.

파일 안에서 확인 가능한 메타데이터를 보여 주고, 제거 가능한 정보만 정확하게 정리한다.

할 수 없는 일을 할 수 있다고 말하지 않는 것도 제품의 중요한 원칙입니다.

비기능 요구사항도 함께 정리했습니다

기능 목록만으로는 제품을 만들 수 없습니다.

특히 사용자의 파일을 처리하는 서비스라면 성능과 보안, 프라이버시 기준을 미리 정해야 합니다.

이 단계에서는 구체적인 기술이나 수치를 확정하지 않았습니다.

예를 들어 최대 파일 크기를 10MB로 할지 20MB로 할지는 기술 타당성 조사와 실제 테스트 이후에 결정할 수 있습니다.

하지만 어떤 기준을 지켜야 하는지는 지금부터 문서에 남겨둡니다.

무엇으로 성공을 판단할 것인가

초기 지표도 함께 정리했습니다.

반면 다음 항목은 성공 지표에서 제외했습니다.

특정 플랫폼에서 일반 사진으로 인식되는가?
AI 라벨이 표시되지 않는가?
AI 탐지를 통과하는가?

이것은 AI Meta Clean이 통제하거나 보장할 수 있는 영역이 아니기 때문입니다.

AI가 만든 문서를 사람이 다시 봅니다

Codex는 제가 답한 내용을 바탕으로 TASK 문서에 다음 항목을 정리했습니다.

• 제품 목표
• 작업 범위
• 작업 제외 범위
• 완료 조건
• 테스트 계획
• 제품 한 줄 정의
• 제품 비전
• 핵심 사용자
• 사용자 문제와 해결 방식
• MVP 기능
• 비기능 요구사항
• 성공 지표
• 후속 TASK
• 프로젝트 문서 업데이트 대상

문서가 완성됐다고 해서 바로 TASK를 종료하지는 않았습니다.

여기부터는 사람이 해야 할 일입니다.

저는 문서를 읽으며 다음 내용을 확인했습니다.

• 내가 만들고 싶은 제품과 같은 방향인가
• AI가 제 의도를 과도하게 해석한 부분은 없는가
• MVP 범위가 너무 커지지는 않았는가
• 기능보다 정책이 앞서 나가지는 않았는가
• 빠진 사용자 상황은 없는가
• 다음 TASK를 시작할 수 있을 만큼 구체적인가
• 제품이 하지 않을 일이 분명하게 적혀 있는가

이것이 제가 생각하는 휴먼 인 더 루프입니다.

AI가 질문하고 정리하고 문서를 만들지만, 방향을 확정하는 것은 사람입니다.

특히 제품 기획처럼 정답이 없는 일은 AI가 대신 결정하도록 두면 안 됩니다.

AI는 선택지를 넓히고 빈틈을 찾는 데 강하지만, 어떤 제품을 만들 것인지는 결국 만드는 사람이 책임져야 합니다.

제품 기획 TASK 종료하기

문서를 검토한 뒤 이번 TASK는 여기에서 닫기로 했습니다.

기술 스택이나 세부 구현 방식은 다음 TASK에서 결정합니다.

작업을 종료하기 위해 다음 명령어를 실행했습니다.

vibeops task ship

실행 결과입니다.

goodtek aimetaclean % vibeops task ship
vibeops task ship TASK-001
  file  docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md

Sections
  ✓ Result
  ✓ Test Result

  commit message (LLM): docs(task-001): add TASK-001 AI Meta Clean Project product planning
✓ Committed: docs(task-001): add TASK-001 AI Meta Clean Project product planning
✓ Status → Shipped
✓ Committed: docs(task-001): mark shipped
✓ Pushed task/001-ai-meta-clean-project-product-planning → origin
✓ Pull request: https://github.com/goodtekxyz/aimetaclean/pull/1

MR/PR URL is on the host — not written to TASK md (use task merge).

✓ Created PR #1 → https://github.com/goodtekxyz/aimetaclean/pull/1
Next: vibeops task merge (or merge in the host UI), then vibeops task sync

goodtek aimetaclean %

vibeops task ship은 단순히 git commit과 git push만 실행하지 않습니다.

이번 TASK에서 AI와 대화하며 결정한 내용을 TASK 문서의 결과로 정리합니다.

## Result

제품 비전, 사용자, MVP 기능, 처리·보안 원칙,
명시적 제외 범위, 성공지표와 후속 TASK를 정리했다.

테스트 결과도 함께 기록합니다.

## Test Result

- Goal 및 Scope 반영 여부: 통과
- 사용자 유형·문제·해결 방식 문서화 완료
- MVP와 이후 확장 범위 구분 완료
- 프로젝트 문서와의 충돌 여부 확인
- 후속 TASK 진행 가능 여부 자체 검토 완료

이렇게 하면 TASK 문서는 단순한 할 일 목록이 아니라 하나의 작업 기록이 됩니다.

AI와 주고받은 긴 대화가 사라져도 TASK 문서만 보면 그 작업의 배경과 결과를 이해할 수 있습니다.

develop 브랜치에 통합하기

task ship으로 커밋과 푸시, PR 생성까지 완료됐습니다.

이제 작업 결과를 개발 통합 브랜치인 develop에 병합합니다.

vibeops task merge

goodtek aimetaclean % vibeops task merge
vibeops task merge TASK-001
  file       docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md
  MR/PR      https://github.com/goodtekxyz/aimetaclean/pull/1
  target     develop (develop)
  method     squash

✓ Pull request merged into develop.

Next: vibeops task sync

PR은 develop 브랜치에 스쿼시 머지되었습니다.

task/001-ai-meta-clean-project-product-planning
                    ↓ squash merge
                 develop

애플리케이션 코드가 포함된 TASK라면 이 시점에 개발환경 CD도 함께 실행됩니다.

이번에는 문서 작업이기 때문에 배포할 화면이나 기능은 없지만, 제품 기획이 이제 프로젝트의 공식적인 기준점으로 통합됐습니다.

작업 브랜치 정리하기

병합이 끝났으니 작업 브랜치를 정리합니다.

vibeops task sync

goodtek aimetaclean % vibeops task sync
vibeops task sync TASK-001
  task branch  task/001-ai-meta-clean-project-product-planning
  integration  develop
  file         docs/tasks/TASK-001-ai-meta-clean-project-product-planning.md
  note         Git cleanup only — TASK md stays Shipped

On task/001-ai-meta-clean-project-product-planning — switching to develop first.
✓ Fetched origin (--prune)
✓ On develop
✓ Up to date with origin/develop (--ff-only)
✓ Ready to sync — develop contains the task commits.
✓ Deleted local branch task/001-ai-meta-clean-project-product-planning
git ✓ Deleted origin/task/001-ai-meta-clean-project-product-planning

Next: vibeops task add

현재 브랜치를 다시 확인했습니다.

git branch

* develop
  main

로컬 작업 브랜치와 원격 작업 브랜치가 모두 삭제됐습니다.

TASK 문서는 develop에 남아 있지만, 작업을 위한 임시 브랜치는 사라졌습니다.

이제 다음 TASK를 시작할 준비가 끝났습니다.

이번에 사용한 TASK 흐름 정리

vibeops task add
        ↓
AI와 계획 및 작업
        ↓
vibeops task ship
        ↓
vibeops task merge
        ↓
vibeops task sync
        ↓
다음 TASK 시작

각 명령어가 담당하는 역할은 다음과 같습니다.

vibeops task add

• 새로운 TASK 번호 생성
• TASK 문서 생성
• 작업 내용을 기반으로 브랜치명 생성
• 작업 브랜치 생성
• 작업 브랜치 체크아웃

vibeops task ship

• 작업 결과 정리
• 테스트 결과 기록
• TASK 상태 변경
• Git 커밋
• 원격 저장소 푸시
• CI 실행
• PR 생성

vibeops task merge

• PR 병합
• develop 브랜치에 작업 결과 통합
• 코드 작업이라면 개발환경 CD 실행

vibeops task sync

• develop 브랜치 최신화
• 로컬 작업 브랜치 삭제
• 원격 작업 브랜치 삭제
• 다음 작업을 시작할 수 있는 상태로 정리

vibeops task release

• 운영 배포 준비
• 운영 브랜치 통합
• 무중단 운영 배포
• 릴리스 기록 관리

TASK 기록만으로는 부족합니다

작업 결과가 전체 제품 구조나 설계에 영향을 준 경우에는 TASK 문서만 업데이트해서는 부족합니다.

예를 들어 다음 TASK에서 이런 결정을 내렸다고 가정해 보겠습니다.

• 이미지 처리는 서버가 아니라 브라우저에서 수행한다.
• JPEG와 PNG만 우선 지원한다.
• C2PA 정보는 제거하지 않고 별도로 표시한다.
• 서버에 올라온 파일은 최대 10분 안에 삭제한다.
• 결과 파일은 객체 스토리지에 임시로 저장한다.
• 처리 상태는 Redis로 관리한다.

이 내용이 해당 TASK 문서에만 있으면 다른 AI 세션은 현재 아키텍처를 제대로 알기 어렵습니다.

그래서 전체 구조에 영향을 주는 내용은 프로젝트 공통 문서에도 반영해야 합니다.

docs/project/
├── 03-architecture.md
├── 05-current-state.md
└── 06-decisions.md

예를 들어 처리 위치를 브라우저로 확정했다면 06-decisions.md에 다음과 같은 기록을 남길 수 있습니다.

## 이미지 처리 위치 결정

- 결정: 지원 가능한 포맷은 우선 브라우저에서 처리한다.
- 이유: 원본 파일이 서버로 전송되지 않아 프라이버시 측면에서 유리하다.
- 제약: 브라우저 라이브러리에서 지원하지 않는 포맷과 메타데이터가 있을 수 있다.
- 후속 조치: 기술 타당성 조사 후 서버 처리 대상을 별도로 결정한다.

그리고 03-architecture.md의 파일 처리 흐름도 함께 수정합니다.

사용자 브라우저
    ↓
메타데이터 분석
    ↓
선택 항목 제거
    ↓
브라우저에서 결과 생성
    ↓
사용자 다운로드

※ 원본 파일은 서버로 전송하지 않음

이 문서들이 항상 최신 상태를 유지해야 새로운 AI 세션에서도 현재 프로젝트를 이해할 수 있습니다.

AI 코딩에서 가장 자주 사라지는 것은 코드가 아니라 맥락입니다

AI와 개발하면서 가장 불편했던 것은 모델의 코딩 능력이 아니었습니다.

새로운 세션을 열 때마다 프로젝트를 다시 설명해야 하는 것이 더 큰 문제였습니다.

• 왜 이 기술을 선택했는지
• 어떤 기능을 의도적으로 제외했는지
• 현재 어디까지 구현됐는지
• 다음에 무엇을 해야 하는지
• 예전에 어떤 문제가 발생했는지
• 어떤 기준으로 결과를 검증했는지

이 내용이 대화에만 남아 있으면 세션이 끝나는 순간 함께 사라집니다.

TASK와 프로젝트 문서를 남기는 이유는 AI에게 모든 것을 기억시키기 위해서가 아닙니다.

AI가 필요할 때 현재의 사실을 다시 읽을 수 있게 하기 위해서입니다.

대화에만 있는 맥락
→ 세션이 끝나면 사실상 사라짐

프로젝트에 기록된 맥락
→ 다른 세션, 다른 모델, 다른 도구에서도 다시 사용 가능

저는 Codex만 사용하지 않습니다.

작업에 따라 ChatGPT를 사용할 수도 있고, Cursor나 Claude Code를 사용할 수도 있습니다.

어떤 도구로 프로젝트에 접근하더라도 같은 문서를 읽고 현재 상태를 이해할 수 있어야 합니다.

그래야 도구가 바뀌어도 프로젝트의 방향은 흔들리지 않습니다.

코드는 한 줄도 작성하지 않았지만 제품은 전보다 선명해졌습니다

이번 TASK에서는 애플리케이션 코드를 한 줄도 작성하지 않았습니다.

그런데 TASK를 시작하기 전보다 제품은 훨씬 구체적으로 바뀌었습니다.

좋은 제품 기획 문서가 완성됐다고 말하기에는 아직 이릅니다.

실제 사용자에게 보여 주고, 구현해 보고, 예상과 다른 부분을 계속 고쳐야 합니다.

그래도 최소한 무엇을 만들고 무엇을 만들지 않을지는 정해졌습니다.

이제부터 기술을 선택하고 기능을 구현할 때도 이 문서를 기준으로 판단할 수 있습니다.

다음 단계는 기술 스택과 아키텍처 결정입니다

AI Meta Clean의 제품 기획은 여기에서 마쳤습니다.

이번 TASK에서는 무엇을 만들 것인지, 누구를 위한 제품인지, MVP에 무엇을 넣고 무엇을 제외할지를 정했습니다.

현재 전체 과정에서의 위치는 다음과 같습니다.

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

다음 단계는 기술 스택과 아키텍처 결정입니다.

바로 Next.js나 특정 라이브러리부터 고르는 방식으로 시작하지는 않을 생각입니다.

먼저 제품 기획에서 정한 요구사항을 기준으로 실제 기술적인 조건을 확인해야 합니다.

다음 TASK에서는 대략 이런 내용을 검토하게 됩니다.

• JPEG, PNG, WebP, HEIC 지원 가능 여부
• EXIF, XMP, IPTC 처리 범위
• AI 생성·편집 도구와 관련된 메타데이터의 종류
• C2PA와 콘텐츠 자격 증명 처리 원칙
• 브라우저 처리와 서버 처리 비교
• 메타데이터 제거 시 재인코딩 여부
• 화질 손실 가능성
• 처리 전후 메타데이터 검증 방법
• 파일 크기와 처리 성능
• 악성 파일과 비정상 이미지 방어
• 파일 보관과 자동 삭제 방식

이 결과를 바탕으로 프론트엔드와 백엔드를 어떻게 나눌지, 브라우저에서 처리할지 서버에서 처리할지, 어떤 라이브러리와 저장소를 사용할지를 결정할 예정입니다.

먼저 기술을 정하고 제품을 거기에 맞추는 것이 아니라, 제품의 요구사항을 확인한 뒤 그에 맞는 기술을 선택하겠습니다.

첫 번째 TASK를 끝냈습니다.

아직 화면도 없고 클릭할 수 있는 버튼도 없습니다. 심지어 처음 생각했던 기능 중 일부는 GPT에게 막혀서 기획 범위에서 빠졌습니다. ㅋㅋㅋ

그래도 AI Meta Clean은 이제 머릿속에만 있는 아이디어는 아닙니다.

제품의 목표와 사용자, MVP 범위, 하지 않을 일이 문서로 남았고 Git에 커밋됐으며 PR을 거쳐 develop 브랜치에 통합됐습니다.

이제 다음 TASK에서 이 제품을 실제로 구현할 수 있는 기술 스택과 아키텍처를 결정해 보겠습니다.

빌드인퍼블릭은 계속됩니다.