← 모든 글

잘못된 데이터베이스 결정의 15배 비용: 결정 타이밍에서 배운 교훈

세 가지 프로덕션 시스템에서 데이터베이스 결정의 비용을 측정했습니다. 마이그레이션 비용은 3년간 축적된 데이터와 스키마 의존성으로 인해 15배로 증가했습니다.

TL;DR

대부분의 엔지니어는 결정 타이밍을 뒤집어서 적용합니다. 되돌릴 수 있는 선택(어떤 API 클라이언트 라이브러리를 사용할지)에는 며칠을 고민하면서, 되돌릴 수 없는 결정(스프린트 플래닝 중 데이터베이스 스키마 설계)은 몇 분 만에 내립니다. Ray Dalio와 Jeff Bezos는 서로 다른 각도에서 같은 프레임워크를 설명합니다. 되돌릴 수 있는 결정은 빠르게 내려야 합니다. 지연이 불완전함보다 더 큰 비용을 초래하기 때문입니다. 되돌릴 수 없는 결정은 그 위험도에 비례하는 분석이 필요합니다. 저는 세 가지 시스템에서 이를 뼈저리게 배웠습니다. 초기 스키마 타협이 누적되어 6자리 마이그레이션 비용으로 불어났습니다.


마이그레이션에서 배운 교훈

ZipRecruiter에서의 첫해, 저는 이전 팀이 초기 개발 속도를 높이기 위해 비정규화된 스키마를 선택한 시스템을 물려받았습니다. 당시에는 합리적인 결정이었습니다. 빠르게 출시하고 나중에 정규화하자. “나중에”는 결코 오지 않았습니다.

2년차에는 세 개의 서비스가 비정규화된 구조에 의존하고 있었습니다. 3년차에는 스키마에 14개월분의 프로덕션 데이터가 축적되었고, 비정규화된 레이아웃을 전제로 한 외래 키 관계와 구조 변경 시 깨질 여섯 개의 리포팅 쿼리가 존재했습니다.

1개월 차의 마이그레이션 비용은 대략 엔지니어링 이틀이었을 것입니다. 12개월 차에는 2주. 36개월 차에는 3개월의 전담 엔지니어링 시간에 다운타임을 방지하기 위한 이중 쓰기 로직을 포함한 롤링 배포가 필요한 것으로 추정되었습니다. 이것이 15배 승수입니다. 문제가 더 어려워진 것이 아니라 매달 축적된 의존성과 함께 폭발 반경이 확장되었기 때문입니다.1


프레임워크

되돌릴 수 있는 결정: 몇 분 안에 결정하세요

프로토타입을 위한 프론트엔드 프레임워크 선택. 변수 명명 규칙 결정. 스테이징용 클라우드 리전 선택. 어떤 블로그 글을 먼저 쓸지 선택.

이들의 공통점은 방향을 바꾸는 비용이 언제 바꾸든 거의 동일하다는 것입니다. 결정을 미루면 결과를 개선하지 않으면서 시간만 낭비하게 됩니다.2

저의 기준: 다음 주에 하루 이내의 작업으로 이 결정을 되돌릴 수 있다면, 지금 바로 결정합니다.

이 사이트를 만들 때 약 10분 만에 React 대신 HTMX를 선택했습니다. HTMX가 잘못된 선택이었다면, 서버 렌더링 템플릿 기반의 개인 사이트에서 프레임워크를 교체하는 데 주말이면 충분했을 것입니다. 되돌리는 비용이 낮았기 때문에 분석보다 속도가 더 중요했습니다.

되돌릴 수 없는 결정: 며칠에 걸쳐 결정하세요

고객 데이터를 위한 데이터베이스 엔진 선택. 외부 시스템이 의존하게 될 API 계약 정의. 86개의 훅이 그 위에 구축될 훅 아키텍처 선택.

이런 결정들은 복리로 늘어납니다. 되돌리는 비용이 시간이 지남에 따라 증가하며, 종종 기하급수적으로 커집니다.3

저의 기준: 이 결정을 되돌리는 비용이 6개월마다 두 배로 증가한다면, 위험도에 비례하여 분석에 투자합니다.

저의 .claude/ 훅 아키텍처는 되돌릴 수 없는 결정을 제대로 내린 사례입니다. 단 하나의 훅을 작성하기 전에 훅 라이프사이클 모델(PreToolUse, PostToolUse, Stop 및 세 가지 다른 포인트)을 설계하는 데 2주를 투자했습니다. 이 설계는 현재 git 안전성, 재귀 제어, 철학 적용, 품질 게이트, 관측 가능성 전반에 걸쳐 86개의 훅을 지원합니다. 이 시점에서 라이프사이클 모델을 변경하려면 모든 훅을 다시 작성해야 합니다. 사전 분석은 투자 대비 몇 배의 가치를 돌려주었습니다.4


올바른 결정과 잘못된 결정 다섯 가지

올바른 결정: Tailwind 대신 순수 CSS 선택

유형: 되돌릴 수 있음. 소요 시간: 20분.

이 사이트에 Tailwind 대신 커스텀 프로퍼티를 활용한 순수 CSS를 선택했습니다. 잘못된 선택이었다면 주말이면 Tailwind로 마이그레이션할 수 있었습니다. 결정에 20분이 걸렸습니다. 프레임워크 생산성보다 CSS 기초를 배우는 것에 가치를 두었기 때문입니다. 2년이 지난 지금, 순수 CSS를 선택한 것이 만족스럽습니다. 모든 최적화(완벽한 Lighthouse 점수 달성)에는 CSS가 실제로 무엇을 하는지 이해하는 것이 필요했기 때문입니다. 그러나 어느 쪽을 선택하든 큰 결과 차이는 없었을 것입니다.

올바른 결정: 훅 아키텍처 설계에 투자

유형: 되돌릴 수 없음. 소요 시간: 2주.

현재 86개의 훅이 라이프사이클 모델에 의존하고 있습니다. 사전 설계에 투자한 모든 시간이 그만한 가치가 있었습니다.

잘못된 결정: 블로그 콘텐츠 스키마를 서둘러 결정

유형: 되돌릴 수 없음. 소요 시간: 30분.

블로그 글의 ContentMeta 데이터 클래스를 한 번의 세션에서 정의했습니다: title, slug, date, description, tags, author, published. category, series, hero_image, scripts, styles를 포함하지 않았습니다. 이후 각각을 추가할 때마다 파서를 수정하고, 메타데이터를 사용하는 모든 템플릿을 업데이트하고, 전체 블로그 파이프라인을 다시 테스트해야 했습니다. 3개월에 걸친 다섯 번의 추가가 처음부터 스키마를 신중하게 설계하는 것보다 총 더 많은 시간이 들었습니다.

잘못된 결정: 블로그 글 순서 고민

유형: 되돌릴 수 있음. 소요 시간: 기획 세션에서 2시간.

어떤 블로그 글을 먼저 쓸지 결정하는 데 2시간을 썼습니다. 순서는 완전히 되돌릴 수 있는 것이었습니다. 아무거나 먼저 쓰기 시작하고 배운 것을 바탕으로 나중에 순서를 재조정했어야 합니다.

올바른 결정: 신중한 합의 임계값 설계

유형: 되돌릴 수 없음. 소요 시간: 1주.

저의 심의 시스템은 작업에 따라 적응하는 합의 임계값을 사용합니다: 보안 결정 85%, 기능 80%, 리팩토링 65%, 문서화 50%. 이를 잘못 설정하면 정당한 작업을 차단하거나(임계값이 너무 높은 경우) 위험한 변경을 승인하게 됩니다(임계값이 너무 낮은 경우). 확정하기 전에 실제 작업 이력에 대해 각 임계값을 테스트했습니다.


흔히 발생하는 역전 현상

엔지니어들은 API 클라이언트 라이브러리(되돌릴 수 있음, 교체 비용 낮음)를 선택하는 데 며칠을 쓰면서, 데이터베이스 스키마(되돌릴 수 없음, 마이그레이션 비용 높음)는 스프린트 플래닝 미팅에서 설계합니다.

관리자도 마찬가지입니다. 프로젝트 관리 도구(되돌릴 수 있음)를 평가하는 데 몇 주를 쓰면서, 팀 재구성(되돌릴 수 없음, 인적 비용 높음)은 하룻밤에 결정합니다.5

이런 역전이 발생하는 이유는 되돌릴 수 있는 결정은 그 순간에 중요하게 느껴지고(팀이 내 라이브러리 선택을 판단할 수도 있다), 되돌릴 수 없는 결정은 추상적으로 느껴지기 때문입니다(마이그레이션은 3년 후의 일이다). 이 감정은 정확히 반대입니다.


모든 결정 전에 던져야 할 두 가지 질문

  1. 6개월 후에 되돌리는 비용이 얼마인가? 답이 “미미하다”면, 지금 바로 결정하세요.
  2. 기다리면 사용할 수 있는 정보가 개선되는가? 기다려도 새로운 데이터가 나오지 않는다면, 지금 바로 결정하세요.

두 가지 조건이 모두 기다리는 쪽에 유리할 때만 숙고하세요. 되돌리는 비용이 높고 동시에 시간이 지나면 더 나은 정보가 나타날 때만입니다.6 그 외 모든 것은 즉시 결정합니다.


핵심 시사점

엔지니어를 위한 조언: - 프로토타입을 위한 기술 스택 선택은 되돌릴 수 있습니다. 회의가 아닌 몇 분 안에 결정하세요 - 데이터베이스 스키마와 API 계약은 규모가 커지면 되돌릴 수 없습니다. 얼마나 많은 시스템이 이 결정에 의존하게 될지에 비례하여 사전 분석에 투자하세요 - 결정 비용을 추적하세요. 15배 마이그레이션 승수를 측정한 것이 사전 투자를 평가하는 방식을 바꿔놓았습니다

관리자를 위한 조언: - 도구 및 프로세스 변경은 대체로 되돌릴 수 있습니다. 빠르게 파일럿하고 반복하세요 - 팀 구조와 채용 결정은 되돌리는 비용이 높습니다. 그에 비례하여 숙고하세요 - 팀이 라이브러리 하나를 선택하는 데 일주일을 쓰고 있다면, 되돌리는 비용이 그만큼의 숙고 시간을 정당화하는지 물어보세요


참고 문헌


  1. ZipRecruiter의 세 가지 프로덕션 시스템에서 데이터베이스 마이그레이션 비용에 대한 저자의 분석. 마이그레이션 비용은 3년간의 데이터 축적과 스키마 의존성으로 인해 15배 증가했습니다. 

  2. Bezos, Jeff, “2015 Letter to Shareholders,” Amazon, 2016. “유형 1과 유형 2 결정” 프레임워크. 

  3. Dalio, Ray, Principles: Life and Work, Simon & Schuster, 2017. 의사결정 타이밍과 급진적 투명성에 관한 핵심 프레임워크. 

  4. 저자의 훅 아키텍처 설계 과정. 6개 라이프사이클 포인트에 걸친 86개의 훅, “Claude Code hooks”에 문서화. 

  5. Kahneman, Daniel, Thinking, Fast and Slow, Farrar, Straus and Giroux, 2011. 결정 피로와 인지 편향에 관한 연구. 

  6. Taleb, Nassim Nicholas, Antifragile, Random House, 2012. 선택성과 불확실성 하의 의사결정에 관한 프레임워크.