1탄에서 말씀드린 것처럼, BullMQ 기반 비동기 Job Queue 시스템을 구현하고 분석 완료 알림을 보내도록 만들었습니다. 그런데 누군가가 merge 할 때마다 알림이 안 오는 이슈가 생겼습니다. 문제의 원인은 Git Conflict였습니다.

dev 브랜치에 merge할 때 충돌이 났습니다. 사실 큰 충돌은 아니었습니다. 몇 번 안 됐습니다. 그런데 이 과정이 익숙하지 않은 누리님에게는 엄청난 두려움이었습니다. 코드가 꼬이면 어떡하지? 내가 뭘 잘못 건드리면? 그 불안감이 작업 속도를 늦췄습니다.

그래서 merge 충돌 및 PR 생성 스킬을 만들었습니다.

# Create Pull Request Skill

Automate the process of merging with dev branch, resolving conflicts, and creating a PR.

## Usage

When the user wants to create a PR, use this skill to automate the entire workflow:
- Merge with dev branch
- Resolve conflicts
- Push to remote
- Create PR via GitHub CLI

## Prerequisites

1. **GitHub CLI installed**: Check with `gh --version`
   - If not installed: `brew install gh` (macOS) or visit https://cli.github.com/
2. **GitHub CLI authenticated**: Run `gh auth status`
   - If not authenticated: `gh auth login`

## Implementation Steps

### 1. Check Current Branch
```bash
git branch --show-current

2. Fetch Latest Dev

bash
git fetch origin dev

3. Merge with Dev

bash
git merge origin/dev

4. If Conflicts Occur

• For .claude/settings.local.json conflicts (local config):

  bash
  git checkout --ours .claude/settings.local.json
  git add .claude/settings.local.json

• For other conflicts: Ask user to resolve manually

5. Complete Merge (if conflicts were resolved)

bash
git commit -m "Merge origin/dev into <current-branch>

- Resolved conflicts in .claude/settings.local.json
- Integrated changes from dev branch"

6. Run Type Check

bash
pnpm --filter @own-it/web type-check

7. Push to Remote

bash
git push origin <current-branch>

8. Create PR via GitHub CLI

bash
gh pr create --base dev --title "<PR-TITLE>" --body "<PR-BODY>"

Claude Code가 충돌 상황을 파악하고, 어떤 코드를 살리고 어떤 코드를 버려야 하는지 가이드해주는 스킬입니다. 누리님이 혼자서도 충돌을 해결할 수 있게 됐습니다.

두려움이 도구가 되는 순간이었습니다.

이 글을 본 지인을 통해서, 이 과정을 클로드코드 마켓플레이스에 등록을 하고, 플러그인으로 팀 단위, 프로젝트에서 편하게 관리할 수 있는 방법을 알게 되어서, 이 방법은 다시 한번 공유해보겠습니다.

Daily Review, Portfolio 기능을 각자 개발하는 과정에서, 간단하게 서로가 어떤 작업을 하고 있는지는 공유가 됐습니다. 하지만 확인하는 차원에서 하나하나 코드 리뷰를 진행하기는 시간적으로 어려웠습니다. 코드 리뷰를 하더라도, 무수히 쏟아지는 코드들을 설명할 자신도 없었습니다.

또한, 저는 web, api, worker 세 개의 프로젝트를 모노레포로 관리하고 있었습니다. 무섭게 추가되는 환경 변수(AWS, GitHub, DB)들과 씨름해야 했고, Drizzle ORM 관련해서 수시로 바뀌는 DB 구조도 골칫거리였습니다. 개발이 끝나도 문제였습니다. 서로에게 변경사항을 공유하는 것 자체가 또 하나의 일이었습니다.

환경 변수 문제 해결:

각 폴더(web, api, worker)마다 .env 파일이 따로 있다 보니, 동기화가 안 맞는 경우가 생겼습니다. 별도의 스크립트를 만들어서 각 폴더의 환경 변수들을 한 번에 복사하고, 압축 파일로 만들었습니다. 압축 파일을 풀면 바로 각 폴더에 붙여 넣을 수 있도록 했습니다. 보안상 민감한 정보가 담긴 파일이기 때문에, Git에는 절대 올리지 않고 둘만 사용하는 메신저로 공유했습니다.

DB 마이그레이션 문제 해결:

수시로 바뀌는 DB 구조는 Docker 파일로 마이그레이션을 관리해서 해결했습니다. 로컬 환경에서든 배포 환경에서든 동일한 DB 구조를 유지할 수 있었습니다.

PR 시 공유 문제 해결:

PR을 올릴 때 꼭 확인해야 하는 내용들이 있었습니다. 환경 변수가 업데이트됐거나, DB 마이그레이션이 필요한 경우 등. 이런 내용을 매번 말로 전달하기엔 누락되기 쉬웠습니다. 그래서 PR에 별도의 문서 파일을 추가했습니다. Claude Code가 해당 문서를 참조해서 "이 PR을 머지하려면 환경 변수 X를 추가해야 해", "마이그레이션을 먼저 실행해야 해" 같은 내용을 자동으로 파악하고 안내할 수 있도록 했습니다. 결국 문서화 문제는 사람이 기억하는 게 아니라, AI가 참조할 수 있게 만드는 것으로 해결했습니다.

핵심 기능은 완성됐습니다. 프로젝트 분석, 포트폴리오 생성, Daily Review. 그런데 그 다음이 문제였습니다.

"다음 기능은 뭐지?"

이번 빌더톤을 진행하면서 다양한 피드백을 받을 수 있었습니다. 빌더분들께서 본인의 경험을 기반으로 정말 어디서도 들을 수 없는 귀중한 경험을 공유해주셨습니다.

"B2B" 시장의 진입에 대한 어려움, "킬링 컨텐츠의 부족"이 저희 서비스가 겪고 있는 문제였습니다.

그렇기에 다음 기능을 찾는 데만 꽤 오랜 시간이 걸렸고, 이 과정이 팀 레벨에서 역량을 쌓는 계기가 됐습니다.

---

4주차는 각자 다른 일을 했습니다.

• 윤누리: IR 발표 준비. 빌더분들 앞에서 Own-it을 설명해야 했습니다.
• 황인준: 안정화. Sentry 연동, CI/CD 파이프라인 구축, SSR 에러 수정, 국제화. 화려하진 않지만 서비스를 서비스답게 만드는 작업들이었습니다.

돌아보면, 하나의 서비스를 개발하는 과정은.. 개발도 있지만, 그 이외에 기획도 하고, 서비스 방향도 잡고, 피드백도 정리하고... 홍보도 해야되는 혼자서는 어려운 일이였습니다.

개발만 하던 개발자 시절에는 절대 알수 없을 일이였습니다.

이때 옆에 누리님이 있어서 정말 든든했습니다. 제가 나머지 시간에 개발에 집중할 수 있었던 건, 기획과 제품 방향을 누리님이 잡아줬기 때문입니다. IR 발표 준비하랴, 사용자 피드백 정리하랴, 다음 기능 기획하랴. 고생 많았습니다 누리님

팀이 둘다 개발자이거나, 둘다 기획자로 구성이 되었다면 이 부분에서 꽤 어려움을 느꼈을거라 생각이 들었습니다.

기획자, 개발자 바이브코더 팀이 상황에 맞게 유연한 업무 분배가 이 과정을 잘 이겨낼 수 있던 방법이라고도 느껴졌습니다.

저희는 5주간의 빌더톤 기간 동안, 이렇게 협업했고. 정말 기대하지도 못했던 좋은 성과를 얻게 되었습니다.

저 혼자였다면 이 프로젝트는 시작도 못 했을 것입니다. 시작하더라도 반도 개발하지 못했을거라 확신 했습니다.

성공적으로 끝난 뒤에 회고를 해보자면, 단순히 개발을 빠르게 한 것을 제외하더라도, 팀 단위에서 프로젝트의 이해도가 높은 상황에서 빠르게 의사결정을 하고, AI의 도움을 통해 서로에게 공유하는 과정에서 커뮤니케이션 비용을 상당히 낮췄다는 점이 가장 크게 느껴집니다.

또한 개발 범위를 단순히 프론트/백으로 나누지 않고, 기능 단위로 나눠서, 최소한의 자신이 맡은 파트에 대한 책임감과 재미를 얻어 끝까지 프로젝트를 완주하는 동력이 되었습니다.

또한 그때 그때, 팀 상황에 맞는 클로드 스킬(merge 이슈, 문서 최신화)을 만들어서 문제를 해결했다는 점이 협업하면서 도움이 됐습니다. 서로의 방식을 바꾸려 하지 않고, 대신 도구를 만들어서 간극을 메웠습니다. 이게 바이브 코딩 팀의 협업 방식이라고 생각이 됐습니다.

이 과정에서 약간 아쉬움이 남았던 점은 후반부에 QA에 시간을 너무 많이 쓰여서 추가로 구현하려고 했던, 바이브로그(커뮤니티) / 팀(팀 단위로 AI 사용 경험 경쟁) 기능을 구현하지 못한 것이 아쉬움인데,

초반부터, test code 작성을 진행하고, 이것 마져도 스킬로 만들었더라면? 이라는 아쉬움이 남았습니다.

앞으로

현재는 팀 기능을 본격적으로 기획하고 있습니다. 이번에는 @kay kim님께서 레시피에 올려주신 여러 방법들을 참고하여, 프로젝트 레벨에서 전체를 재점검하고 있습니다.

목표는 명확합니다: 사용자들이 매일 찾는 서비스. 포트폴리오는 한 번 만들면 끝입니다. 하지만 Daily Review는 매일 쓸 수 있습니다. 팀 기능은 매일 확인하고 싶어집니다. 바이브 로그도 준비 중입니다.

Own-it이 바이버들의 일상에 스며드는 서비스가 되길 바라며, own-it의 소식과 그때 그때 경험하는 경험들 공유하겠습니다!

1탄에서 말씀드린 것처럼, BullMQ 기반 비동기 Job Queue 시스템을 구현하고 분석 완료 알림을 보내도록 만들었습니다. 그런데 누군가가 merge 할 때마다 알림이 안 오는 이슈가 생겼습니다. 문제의 원인은 Git Conflict였습니다.

dev 브랜치에 merge할 때 충돌이 났습니다. 사실 큰 충돌은 아니었습니다. 몇 번 안 됐습니다. 그런데 이 과정이 익숙하지 않은 누리님에게는 엄청난 두려움이었습니다. 코드가 꼬이면 어떡하지? 내가 뭘 잘못 건드리면? 그 불안감이 작업 속도를 늦췄습니다.

그래서 merge 충돌 및 PR 생성 스킬을 만들었습니다.

# Create Pull Request Skill

Automate the process of merging with dev branch, resolving conflicts, and creating a PR.

## Usage

When the user wants to create a PR, use this skill to automate the entire workflow:
- Merge with dev branch
- Resolve conflicts
- Push to remote
- Create PR via GitHub CLI

## Prerequisites

1. **GitHub CLI installed**: Check with `gh --version`
   - If not installed: `brew install gh` (macOS) or visit https://cli.github.com/
2. **GitHub CLI authenticated**: Run `gh auth status`
   - If not authenticated: `gh auth login`

## Implementation Steps

### 1. Check Current Branch
```bash
git branch --show-current

2. Fetch Latest Dev

bash
git fetch origin dev

3. Merge with Dev

bash
git merge origin/dev

4. If Conflicts Occur

• For .claude/settings.local.json conflicts (local config):

  bash
  git checkout --ours .claude/settings.local.json
  git add .claude/settings.local.json

• For other conflicts: Ask user to resolve manually

5. Complete Merge (if conflicts were resolved)

bash
git commit -m "Merge origin/dev into <current-branch>

- Resolved conflicts in .claude/settings.local.json
- Integrated changes from dev branch"

6. Run Type Check

bash
pnpm --filter @own-it/web type-check

7. Push to Remote

bash
git push origin <current-branch>

8. Create PR via GitHub CLI

bash
gh pr create --base dev --title "<PR-TITLE>" --body "<PR-BODY>"

Claude Code가 충돌 상황을 파악하고, 어떤 코드를 살리고 어떤 코드를 버려야 하는지 가이드해주는 스킬입니다. 누리님이 혼자서도 충돌을 해결할 수 있게 됐습니다.

두려움이 도구가 되는 순간이었습니다.

이 글을 본 지인을 통해서, 이 과정을 클로드코드 마켓플레이스에 등록을 하고, 플러그인으로 팀 단위, 프로젝트에서 편하게 관리할 수 있는 방법을 알게 되어서, 이 방법은 다시 한번 공유해보겠습니다.

Daily Review, Portfolio 기능을 각자 개발하는 과정에서, 간단하게 서로가 어떤 작업을 하고 있는지는 공유가 됐습니다. 하지만 확인하는 차원에서 하나하나 코드 리뷰를 진행하기는 시간적으로 어려웠습니다. 코드 리뷰를 하더라도, 무수히 쏟아지는 코드들을 설명할 자신도 없었습니다.

또한, 저는 web, api, worker 세 개의 프로젝트를 모노레포로 관리하고 있었습니다. 무섭게 추가되는 환경 변수(AWS, GitHub, DB)들과 씨름해야 했고, Drizzle ORM 관련해서 수시로 바뀌는 DB 구조도 골칫거리였습니다. 개발이 끝나도 문제였습니다. 서로에게 변경사항을 공유하는 것 자체가 또 하나의 일이었습니다.

환경 변수 문제 해결:

각 폴더(web, api, worker)마다 .env 파일이 따로 있다 보니, 동기화가 안 맞는 경우가 생겼습니다. 별도의 스크립트를 만들어서 각 폴더의 환경 변수들을 한 번에 복사하고, 압축 파일로 만들었습니다. 압축 파일을 풀면 바로 각 폴더에 붙여 넣을 수 있도록 했습니다. 보안상 민감한 정보가 담긴 파일이기 때문에, Git에는 절대 올리지 않고 둘만 사용하는 메신저로 공유했습니다.

DB 마이그레이션 문제 해결:

수시로 바뀌는 DB 구조는 Docker 파일로 마이그레이션을 관리해서 해결했습니다. 로컬 환경에서든 배포 환경에서든 동일한 DB 구조를 유지할 수 있었습니다.

PR 시 공유 문제 해결:

PR을 올릴 때 꼭 확인해야 하는 내용들이 있었습니다. 환경 변수가 업데이트됐거나, DB 마이그레이션이 필요한 경우 등. 이런 내용을 매번 말로 전달하기엔 누락되기 쉬웠습니다. 그래서 PR에 별도의 문서 파일을 추가했습니다. Claude Code가 해당 문서를 참조해서 "이 PR을 머지하려면 환경 변수 X를 추가해야 해", "마이그레이션을 먼저 실행해야 해" 같은 내용을 자동으로 파악하고 안내할 수 있도록 했습니다. 결국 문서화 문제는 사람이 기억하는 게 아니라, AI가 참조할 수 있게 만드는 것으로 해결했습니다.

핵심 기능은 완성됐습니다. 프로젝트 분석, 포트폴리오 생성, Daily Review. 그런데 그 다음이 문제였습니다.

"다음 기능은 뭐지?"

이번 빌더톤을 진행하면서 다양한 피드백을 받을 수 있었습니다. 빌더분들께서 본인의 경험을 기반으로 정말 어디서도 들을 수 없는 귀중한 경험을 공유해주셨습니다.

"B2B" 시장의 진입에 대한 어려움, "킬링 컨텐츠의 부족"이 저희 서비스가 겪고 있는 문제였습니다.

그렇기에 다음 기능을 찾는 데만 꽤 오랜 시간이 걸렸고, 이 과정이 팀 레벨에서 역량을 쌓는 계기가 됐습니다.

---

4주차는 각자 다른 일을 했습니다.

• 윤누리: IR 발표 준비. 빌더분들 앞에서 Own-it을 설명해야 했습니다.
• 황인준: 안정화. Sentry 연동, CI/CD 파이프라인 구축, SSR 에러 수정, 국제화. 화려하진 않지만 서비스를 서비스답게 만드는 작업들이었습니다.

돌아보면, 하나의 서비스를 개발하는 과정은.. 개발도 있지만, 그 이외에 기획도 하고, 서비스 방향도 잡고, 피드백도 정리하고... 홍보도 해야되는 혼자서는 어려운 일이였습니다.

개발만 하던 개발자 시절에는 절대 알수 없을 일이였습니다.

이때 옆에 누리님이 있어서 정말 든든했습니다. 제가 나머지 시간에 개발에 집중할 수 있었던 건, 기획과 제품 방향을 누리님이 잡아줬기 때문입니다. IR 발표 준비하랴, 사용자 피드백 정리하랴, 다음 기능 기획하랴. 고생 많았습니다 누리님

팀이 둘다 개발자이거나, 둘다 기획자로 구성이 되었다면 이 부분에서 꽤 어려움을 느꼈을거라 생각이 들었습니다.

기획자, 개발자 바이브코더 팀이 상황에 맞게 유연한 업무 분배가 이 과정을 잘 이겨낼 수 있던 방법이라고도 느껴졌습니다.

저희는 5주간의 빌더톤 기간 동안, 이렇게 협업했고. 정말 기대하지도 못했던 좋은 성과를 얻게 되었습니다.

저 혼자였다면 이 프로젝트는 시작도 못 했을 것입니다. 시작하더라도 반도 개발하지 못했을거라 확신 했습니다.

성공적으로 끝난 뒤에 회고를 해보자면, 단순히 개발을 빠르게 한 것을 제외하더라도, 팀 단위에서 프로젝트의 이해도가 높은 상황에서 빠르게 의사결정을 하고, AI의 도움을 통해 서로에게 공유하는 과정에서 커뮤니케이션 비용을 상당히 낮췄다는 점이 가장 크게 느껴집니다.

또한 개발 범위를 단순히 프론트/백으로 나누지 않고, 기능 단위로 나눠서, 최소한의 자신이 맡은 파트에 대한 책임감과 재미를 얻어 끝까지 프로젝트를 완주하는 동력이 되었습니다.

또한 그때 그때, 팀 상황에 맞는 클로드 스킬(merge 이슈, 문서 최신화)을 만들어서 문제를 해결했다는 점이 협업하면서 도움이 됐습니다. 서로의 방식을 바꾸려 하지 않고, 대신 도구를 만들어서 간극을 메웠습니다. 이게 바이브 코딩 팀의 협업 방식이라고 생각이 됐습니다.

이 과정에서 약간 아쉬움이 남았던 점은 후반부에 QA에 시간을 너무 많이 쓰여서 추가로 구현하려고 했던, 바이브로그(커뮤니티) / 팀(팀 단위로 AI 사용 경험 경쟁) 기능을 구현하지 못한 것이 아쉬움인데,

초반부터, test code 작성을 진행하고, 이것 마져도 스킬로 만들었더라면? 이라는 아쉬움이 남았습니다.

앞으로

현재는 팀 기능을 본격적으로 기획하고 있습니다. 이번에는 @kay kim님께서 레시피에 올려주신 여러 방법들을 참고하여, 프로젝트 레벨에서 전체를 재점검하고 있습니다.

목표는 명확합니다: 사용자들이 매일 찾는 서비스. 포트폴리오는 한 번 만들면 끝입니다. 하지만 Daily Review는 매일 쓸 수 있습니다. 팀 기능은 매일 확인하고 싶어집니다. 바이브 로그도 준비 중입니다.

Own-it이 바이버들의 일상에 스며드는 서비스가 되길 바라며, own-it의 소식과 그때 그때 경험하는 경험들 공유하겠습니다!