KnotNet, Taker에서 Giver로 전환
아담 그랜트의 '기브 앤 테이크'라는 책을 읽었던 적이 있습니다.
책을 읽고도 실천 못하는건 여전한 것 같습니다.
KnotNet의 모바일앱을 런칭하고 나서,
이제 푸쉬 메시지를 보낼 수 있게 되었으니 리텐션은 당연히 올라갈 것이라는 낙관적인 예측을 했습니다.
사용자의 기존 기록을 분석해서 추가 질문을 던지면, 개인화된 질문에 유저가 좀 더 기록을 할 것이라 생각했습니다.
겉보기엔 개인화된 것처럼 보이지만, 푸쉬에 따른 리텐션 증가는 거의 없었습니다.
좀 더 고민해보니 이 푸쉬 메시지는 사용자에게 무엇인가 더 하라고 요구(take)하는 방식이었다는 생각이 들었습니다. 이건 사용자의 에너지를 빼앗는 구조입니다.
KnotNet은 기록을 통해 유저가 더 자신을 이해하고 성장할 수 있는 것을 돕는다는 철학을 가지고 있습니다. 그렇다면 유저에게 더 많이 기록하라고 다그칠 것이 아니라, 유저의 적은 기록으로 인사이트를 제공(give)하는 것이 핵심이라는 생각이 들었습니다.
그래서 매일 저녁 보내는 푸쉬를 추가 질문을 요구하는 것이 아닌,
사용자의 기록 속에서 발견된 ‘나를 이해하는 인사이트’ 자체를 푸시로 보내기로 했습니다.
이번 달 기록을 관통하는 건 "나는 지금 원하는 삶을 살고 있는가?"라는 질문이에요.
당신은 경제적 자유와 안정, 직업 선택, 개인적 목표 등 여러 측면에서 자신의 삶을 돌아보고 있는 것 같아요. 이러한 고민은 결국 '나는 지금 원하는 삶을 살고 있는가?'라는 질문으로 이어>지는 듯해요. 당신의 최근 기록들에서 나타나는 다양한 주제들은 이 질문에 대한 탐구의 일환으로 보입니다.
푸쉬를 클릭하지 않아도 유저는 즉각적으로 기록의 가치를 느낄 수 있습니다.
푸시의 철학이 Take에서 Give로 바뀐 순간, 사용자 경험 자체가 완전히 달라졌습니다.
유저에게 먼저 가치를 주면, 유저는 자연히 좋은 인사이트를 보기 위해서는 더 기록을 해야 하겠다고 생각할 수 있습니다.
리텐션은 푸쉬라는 기능이 아닌 유저와 대화하는 방식의 심리적 요인이 훨씬 큽니다.
KnotNet은 Taker에서 Giver로 정체성 변경을 했고, 이후 유저의 변화를 살펴보려 합니다.
Vercel 롤백의 숨겨진 로직: 2시간의 삽질로 배운 교훈
문제의 시작
로컬에서 완벽하게 작동하는 코드를 Vercel에 배포했다. 몇 분 후 "Deployed Successfully" 메시지를 확인했다.
프로덕션 사이트를 열었다. 변경사항이 반영되지 않았다.
"캐시인가?" 하드 리프레시를 했다. 여전히 이전 버전이다.
"뭐지?"
디버깅의 시작
1차 시도: 코드 재확인
로컬과 프로덕션이 다르다면 코드 문제일 것이다. 코드를 다시 확인했다.
문제없다. 로컬에서는 완벽하게 작동한다.
2차 시도: 환경 변수
프로덕션 환경 변수가 잘못되었을 수도 있다. Vercel 대시보드에서 환경 변수를 확인했다.
모두 정상이다.
3차 시도: 재배포
혹시 배포 과정에서 뭔가 잘못되었을까? 재배포를 했다.
"Building... Deployed Successfully!"
프로덕션 확인. 여전히 이전 버전.
4-8차 시도: 계속된 재배포
"이번엔 뭔가 다를 거야."
코드를 약간 수정하고 재배포. 안 됨. 다른 부분을 수정하고 재배포. 안 됨. 콘솔 로그를 추가하고 재배포. 안 됨. 완전히 다른 접근으로 수정하고 재배포. 안 됨.
2시간이 지났다.
깨달음
Vercel 대시보드를 다시 자세히 봤다.
Deployments:
✅ v13 - Deployed 2m ago
✅ v12 - Deployed 15m ago
✅ v11 - Deployed 30m ago
✅ v10 - Deployed 1h ago
→ v9 - Production (Active)잠깐.
v13까지 배포했는데 왜 v9가 Production인가?
각 배포를 클릭해서 상태를 확인했다:
- v13: Ready (but not Production)
- v12: Ready (but not Production)
- v11: Ready (but not Production)
- v9: Production
모든 최신 배포가 프로덕션이 아니었다.
진짜 원인: 롤백의 숨겨진 로직
타임라인을 재구성했다:
어제:
- v10을 프로덕션에 배포
- 버그 발견
- v9로 롤백 (Promote to Production)
오늘:
- v11 배포 → 자동으로 staging
- v12 배포 → 자동으로 staging
- v13 배포 → 자동으로 staging
Vercel의 로직:
과거 버전으로 수동 롤백을 하면, 시스템은 "의도적인 프로덕션 고정"으로 인식한다. 그 이후의 모든 배포는 자동으로 프로덕션에 적용되지 않고 staging 상태로 남는다. 프로덕션에 적용하려면 명시적으로 "Promote to Production"을 해야 한다.
이것을 몰랐다.
해결
v13 배포를 찾아서 "Promote to Production" 버튼을 클릭했다.
몇 초 후, 모든 변경사항이 프로덕션에 반영되었다.
2시간의 삽질이 끝났다.
왜 이런 로직인가?
처음에는 이해가 안 갔다. "왜 최신 배포가 자동으로 프로덕션이 안 되지?"
하지만 생각해보니 합리적이다.
시나리오:
- 프로덕션에 치명적 버그 발생
- 급하게 과거 버전으로 롤백
- 버그를 수정하고 새 버전 배포
- 근데 수정이 완벽하지 않아서 또 배포
- 여러 번 시도...
이 과정에서 모든 배포가 자동으로 프로덕션에 적용된다면?
각 배포마다 프로덕션이 요동친다. 사용자들은 혼란스럽다. 버그가 반복된다.
Vercel의 접근: 롤백 = "지금은 프로덕션을 안정화하고 싶다"는 신호 → 이후 배포는 staging으로 → 충분히 검증하면 수동으로 Promote
안전장치였다.
배운 점
1. 롤백은 단순한 과거 회귀가 아니다
롤백은 시간을 되돌리는 것이 아니라, 배포 파이프라인의 상태를 변경하는 행위다.
많은 배포 시스템에서 롤백은 이후 동작에 영향을 미친다:
- Vercel: 롤백 후 모든 배포가 staging
- AWS CodeDeploy: 롤백 후 auto-deployment 비활성화
- Kubernetes: rollback 후 새 deployment는 manual approval
- Heroku: 롤백 후 pipeline promotion 필요
2. "Deployed Successfully" ≠ "Production에 적용됨"
배포 시스템은 여러 단계로 구성된다:
- Build
- Deploy
- Promote to Production
"Deployed Successfully"는 Deploy 단계까지만 의미한다.
3. 상태를 제대로 봐야 한다
Vercel 대시보드에서 각 배포의 상태가 표시된다:
- ✅ Production
- 🔵 Preview
- 🟡 Ready (staging, 롤백 후)
나는 "Deployed Successfully"만 보고 안심했다. 상태를 자세히 확인했어야 했다.
4. 로컬-프로덕션 차이의 진짜 원인
"로컬에서는 되는데 프로덕션에서는 안 돼"라는 문제의 원인은 다양하다:
흔한 원인:
- 환경 변수 차이
- 빌드 환경 차이
- 의존성 버전 차이
내 경우:
- 배포 상태 차이 (staging vs production)
코드는 전혀 문제가 없었다.
5. 문서를 읽자
Vercel 문서에는 이 동작이 명확히 설명되어 있다:
"When you rollback to a previous deployment, subsequent deployments will not automatically be promoted to production. You must manually promote them."
하지만 나는 문서를 자세히 읽지 않았다. 2시간을 낭비했다.
체크리스트 업데이트
이제 배포 후 체크리스트에 이것을 추가했다:
배포 후 확인사항:
- Build 성공 확인
- Deploy 완료 확인
- 배포 상태 확인 (Production? Staging?)
- 최근 롤백 이력 확인
- 필요시 "Promote to Production" 실행
- 프로덕션 사이트에서 직접 확인
- 주요 기능 동작 테스트
특히 롤백 이후에는 더 주의깊게 확인해야 한다.
비슷한 경험들
이 글을 쓰면서 다른 개발자들에게 물어봤다. 비슷한 경험이 많았다:
A 개발자: "AWS CodeDeploy에서 롤백했는데, 다음 배포가 자동으로 안 돼서 한참 헤맸어요. Auto-deployment가 비활성화된 걸 몰랐죠."
B 개발자: "Kubernetes에서 rollback 하고 나서 새 deployment가 pending 상태로만 있더라고요. Manual approval이 필요한 걸 나중에 알았어요."
C 개발자: "Heroku pipeline에서 롤백 후에 새 빌드가 production에 자동으로 안 올라갔어요. Promote 버튼을 직접 눌러야 했죠."
패턴이 보인다. 롤백은 배포 파이프라인에 "수동 모드"를 활성화한다.
결론
2시간의 삽질은 아까운 시간처럼 보였다. 하지만 값진 투자였다.
이제 나는:
- Vercel의 롤백 로직을 이해한다
- 배포 상태를 제대로 확인한다
- "Deployed Successfully"를 맹신하지 않는다
- 롤백 후 더 주의깊게 배포한다
그리고 이 글을 읽는 누군가의 2시간을 절약할 수 있다면, 내 2시간은 충분히 가치있다.