왜 우리는 Perfect Data Models를 포기하고 (Duct Tape)로 더 나은 결과를 얻었는가

Source: Dev.to

현실을 직시하자

우리는 모두 그런 경험을 해봤습니다. 몇 주(혹은 몇 달) 동안 “완벽한” 데이터 모델을 정교하게 설계하고, 복잡한 ERD를 그리고, 정규화 규칙을 논의하며, 완벽하고 확장 가능한 스키마를 꿈꾸죠. 그런데 첫 번째 사용자가 시스템에 접속하고, 요구사항이 바뀌면서 여러분의 아름다운 다이어그램은 이제는 유물에 불과해 버립니다.

우리는 스타트업에서 수년간 고객 분석 플랫폼을 위해 그 잡히지 않는 “완벽한” 모델을 쫓아다녔습니다. 47개의 테이블로 구성된 단일 SQL 데이터베이스를 완벽히 정규화해서 구축했지만, 영업팀이 즉석에서 사용자 행동 패턴을 보고해야 할 필요가 생기면서 모델이 스키마의 절반을 다시 작성하지 않고는 이를 처리할 수 없다는 사실을 깨달았습니다.

우리는 완벽주의에 사로잡혀 마감일을 놓치고, 스스로 만든 사용자들을 좌절시켰습니다. 그 대가? 수개월에 걸친 낭비된 노력과 마치 모래 위에 세운 듯 불안정한 시스템이었습니다.

진실은, 데이터 모델링에서 완벽을 쫓는다는 것은 결코 도래하지 않을 미래를 위해 구축하는 것이며, 오늘 당장의 긴급한 요구를 무시한다는 점입니다. 이것이 게으름 때문이 아니라 전략적으로 현명하기 때문입니다. 사용자가 아직 없을 때 “완벽한” 구조에 집착한다면, 어둠 속에서 건설하고 있는 셈입니다.

우리는 힘들게 배웠습니다: 데이터 모델은 비즈니스를 위해 존재해야지, 그 반대가 되어서는 안 된다는 것을. 진정한 마법은 즉각적인 문제를 해결할 만큼 충분히 구조를 만들고, 배우면서 점진적으로 적응해 나갈 때 일어납니다. 이것은 지저분한 것이 아니라 실용적이며, 이론적인 우아함이 아니라 실제 가치를 제공하는 방법입니다. 탑에 올라가서 바라보는 것이 아니라, 지금 작동하는 무언가를 만들자.

왜 “완벽한” 데이터 모델은 실제로 항상 실패하는가

내부 도구를 위해 “미래에도 견딜” 수 있는 데이터 모델을 만들기 위해 6개월을 투자했는데, 6개월 뒤에 제품 방향을 전환해야 했던 적이 있나요? 네, 우리도 그 경험이 있습니다. 확장 가능한 사용자 프로필을 위해 설계한 “완벽한” 모델은 실시간 참여 지표를 추적해야 한다는 사실을 깨달았을 때 쓸모 없게 되었습니다.

비용은 단순히 시간만이 아니었습니다—팀 사기도 크게 떨어졌습니다. 우리는 “완벽한” 무언가를 깨뜨릴까 두려워 스키마를 바꾸지 못하고 분석 마비에 빠졌습니다.

하지만 현실은 이렇습니다: 데이터 모델은 돌에 새겨진 것이 아닙니다. 사용자 행동, 새로운 기능, 예기치 않은 비즈니스 변화에 따라 살아 움직이는 존재입니다. “완벽한” 모델은 정적인 요구사항을 전제로 하지만, 기술 세계에서 유일하게 변하지 않는 것은 변화 자체입니다.

예시: 우리 전자상거래 고객은 제품 변형(사이즈, 색상, 소재)에 대해 엄격하고 정규화된 모델을 고집했습니다. 두 달이 지나자 **“지속 가능성 등급”**이라는 필드를 추가하고 싶어했는데, 기존 테이블 어디에도 맞지 않았습니다. 모델을 다시 구축한다면 출시가 몇 주 지연될 상황이었습니다. 대신 우리는 새로운 데이터를 메인 products 테이블에 간단한 JSON 블롭으로 저장했습니다. 다소 지저분했지만 어제 출시했으며, 다음 분기에 출시되는 것이 아니었습니다.

핵심 인사이트: 완벽함은 “충분히 좋은” 것의 적입니다. 내일의 가설이 아닌 오늘의 문제를 최소한의 마찰로 해결하는 데 집중하세요. 한 엔지니어가 이렇게 말했습니다:

“30초짜리 Slack 메시지로 데이터 구조를 설명할 수 없으면, 그 구조는 너무 복잡한 겁니다.”

덕트 테이프 방법: 실제로 일을 끝내는 방법 (후회 없이)

그렇다면 “덕트 테이프” 접근법이란 무엇일까요? 코드를 대충 짜는 것이 아니라 전략적 유연성에 관한 것입니다.

1. 스스로에게 물어보세요: “지금 바로 피드백을 얻기 위해 만들어야 할 가장 작은 것은 무엇인가?”
   예시: 분석 대시보드에 새로운 기능을 만들 때, 복잡한 events 테이블을 설계하는 대신 클라우드에 저장된 간단한 CSV 파일을 사용했습니다. 처음엔 부끄러웠지만, 이틀 안에 핵심 사용자 흐름을 테스트할 수 있었고, 두 주가 걸렸을 때보다 훨씬 빨랐습니다.

2. 스키마가 아니라 가정을 문서화하세요.
   50페이지 분량의 ERD 작성을 중단하고, “우선 모든 사용자는 하나의 이메일만 가지고 있다고 가정하고, 필요하면 나중에 여러 개를 추가한다.”와 같은 짧은 메모를 쓰기 시작했습니다. 이렇게 하면 변경이 모델을 “깨는” 것이 아니라 “계획을 업데이트하는” 느낌이 들었습니다.

3. 간단한 규칙을 채택하세요: 데이터 필드가 한 달에 두 번 이상 변경된다면, 이를 정형화할 시점입니다.
   예시: 계속 수정하던 user_segment 필드는 세 번의 빠른 수정 후에 전용 테이블로 옮겨졌습니다.

덕트 테이프 방법은 구조를 건너뛰는 것이 아니라, 필요할 때까지 구조를 미루는 것입니다. 우리는 이제 JSON 스키마와 같은 도구를 사용해 일시적인 유연성을 확보하고, 데이터 패턴이 안정될 때만 관계형 테이블로 마이그레이션합니다. 이 방법으로 기능 전달 시간이 40 % 단축되고, 재작업이 70 % 감소했습니다.

Source: …

모델을 버릴 때 (그리고 모델을 만들 때)

가장 큰 함정? 언제나 덕트 테이프가 정답이라고 가정하는 것. 그렇지 않습니다.

각 데이터 도메인의 안정성, 가시성, 그리고 규제 영향을 평가함으로써, 견고한 스키마에 투자할 시점과 유연성을 유지할 시점을 결정할 수 있습니다.

---

“완벽한” 데이터 모델에 갇힌 느낌을 받은 적이 있다면, 덕트‑테이프 방식을 시도해 보세요: 작게 시작하고, 빠르게 반복하며, 패턴이 명확해질 때만 공식화합니다. 더 빨리 가치를 제공하고, 팀을 행복하게 유지하며, 모래 위에 건물을 짓는 일을 피할 수 있습니다.

Engineered. 핵심은 왜 모델을 만드는지를 아는 것입니다. 우리는 과거에 “기술 순수성”을 위해 모델을 만들었습니다. 이제는 비즈니스 영향을 위해 모델을 만듭니다. 데이터가 오늘 결정을 내리는 데 도움이 된다면 (예: “어떤 기능이 가장 많은 참여를 이끌어내는가?”), 최소한의 구조만으로도 충분합니다. 미래에 있을지도 모를 “멋진 기능”이라면 건너뛰세요.

우리는 새로운 프로젝트를 위해 데이터 모델 체크리스트도 만들었습니다:

1. 이것이 현재 비즈니스 문제를 해결합니까?
2. 필요할 경우 < 1 시간 안에 변경할 수 있습니까?
3. 이번 분기에 시간을 절약할 수 있습니까?

위 질문 중 어느 하나라도 아니오라면, 그것은 덕트‑테이프 영역입니다. 이 사고방식 전환 덕분에 데이터는 병목이 아니라 가장 빠른 성장 레버가 되었습니다.

관련 읽기

• 왜 Alteryx 사용을 중단했나요?
• 전후 분석을 위한 시각적 비교 기법
• 올바른 고객에 투자하기: CLV 분석이 유지 전략 최적화에 어떻게 도움이 되는가
• 대규모 상태 기반 스트림 처리
• 데이터 분석을 활용한 텍사스 오스틴 교통 개선
• Trello 대안 | Gato Kanban
• 이벤트 시간 vs 처리 시간 윈도우 패턴
• Slides 또는 Powerpoint 대안 | Gato Slide

제공: AICA & GATO