설정값 변경, 이틀 만에 원상복구

며칠 전 어떤 설정값을 바꿨다가 사용자 피드백을 받고 즉시 되돌렸다. 큰 기능 개발이나 버그 수정은 아니지만, 이런 작은 의사결정과 롤백이 반복되면서 배운 게 많아서 정리해 본다.

배경: 설정 변경의 배경

6월 11일, 어떤 이유로 ssul 설정값을 기존의 80/day에서 4/day로 내렸다. 아마도 특정 한계 상황 테스트, 또는 리소스 절감 같은 목적이 있었을 것 같다. 하지만 사용자 입장에서는 갑자기 제약이 커진 셈이었다. 문서에 그 변경을 기록하고 커밋했는데, 이틀 뒤인 6월 13일 사용자로부터 피드백을 받고 바로 원래 값으로 되돌렸다.

왜 이렇게 빨리 되돌렸나

일단 이 변경은 문서(docs/hedvion-CLAUDE.md)에만 적혀 있었다. 프로덕션 코드의 하드코딩 값이 아니라 외부 설정 문서로 관리하니까 변경도 빠르고 추적도 쉬웠다. 사용자가 "이거 너무 낮은데?" 하고 알려주면, git history에서 변경 이력을 확인하고 즉시 revert 커밋을 남길 수 있었다.

만약 이 설정이 소스코드 깊숙이 박혀 있었다면 어땠을까. 변경을 감지하는 데 더 시간이 걸렸을 것이고, 롤백도 릴리스 사이클을 기다려야 했을 수도 있다. 하지만 문서 기반 설정이라서 롤백도 문서 한 줄, git commit 한 번의 일이었다.

설정 변경의 투명성

중요한 건 변경 의도를 명확히 남기는 것이다. 커밋 메시지에 "4/day per user 2026-06-13" 이렇게 한정적인 시간을 넣은 건, "이건 실험이고 곧 원래대로 돌릴 수도 있다"는 신호다. 만약 "더 나은 리소스 관리" 같은 모호한 말만 남겼다면, 나중에 이 값이 정책이 된 건 아닌지 헷갈렸을 수도 있다.

팀 규모가 커지고 협업이 많아질수록 이런 "임시 변경"과 "영구 정책"의 경계가 중요해진다. 커밋 메시지, branch 이름, PR description에 scope을 명시하는 습관이 생기니까 나중에 "이거 왜 이렇게 돼 있어?" 같은 혼동도 줄어든다.

회고: 배포 전략의 작은 교훈

이 사례는 A/B 테스트나 feature flag 같은 복잡한 인프라 없어도, 커밋 메시지와 문서 관리만으로도 충분히 빠른 의사결정을 할 수 있다는 걸 보여준다. 특히 조직 초기에는 "설정을 어떻게 관리할 것인가"가 "코드를 어떻게 관리할 것인가" 못지않게 중요하다.

또 하나는 사용자 피드백에 귀 기울이고 빨리 대응하는 것의 가치다. 48시간 내에 피드백을 받고 롤백한 덕분에, 사용자 만족도 손실을 최소화할 수 있었다. 완벽한 계획보다는 "빨리 시도하고, 피드백 받고, 빨리 조정"하는 사이클이 조직 초기에 더 효과적일 때가 많다.

지금은 80/day로 다시 돌아왔지만, 향후 이 값을 조정해야 한다면 더 신중하게 하거나, 아니면 처음부터 feature flag로 관리하는 것도 고려해 볼 만하다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.