데이터를 다룰 때 어려운 것

Anton Kropp님의 블로그를 의역/요약한 글입니다. --- 데이터를 잘 설계하는 것은 너무나 중요합니다. 대부분의 앱은 데이터를 사용합니다. 만약 데이터 설계가 잘 되어 있지 않다면, 정말 쉬운 문제도 어려워질 수 있습니다. 데이터가 복잡하면 API도 복잡해지며 사용하기 어려워집니다. 이름 짓는 것은 어렵다 이름 짓는 것은 어렵습니다. 변수 명, 테이블 명 등 이름을 지을 때 해당 이름이 데이터 도메인을 잘 나타내는지 고민해봐야 합니다. 장기적인 관점에서 누군가 이것을 봤을 때 이해할 수 있을지 고민해보세요. 이름을 짓는다면 일관성도 중요합니다. Snake case를 사용했다면 Snake case를 끝까지 유지하세요. 일관성은 인지 부하를 줄여줍니다. 인덱스나 FK를 설정할 때도 일관성을 유지하세요. fk_source_field_external_field 와 같은 로직이 담긴 이름이라면 계속 이 구성을 유지하세요. 일관성은 관계형 데이터를 표현할 때만 중요한 건 아닙니다. No-SQL 같은 형태라면 데이터의 구조가 있는데 이 구조를 일관성 있게 유지하는 것이 중요합니다. 원천 데이터 어떤 데이터를 저장할지 고민하세요. 데이터를 저장해야 하는지? 왜 저장하는지? 등 스스로 되물어보세요. 이 고민을 하는 이유는 정말 필요한 데이터만 저장하기 위함입니다. 그리고 데이터가 다른 곳에도 저장되었는지 생각해보세요. 원천 데이터를 잘 정립하지 못하면 데이터를 취급하는데 있어서 고민할 거리가 많아집니다. 테스트를 해보세요 제가 주로 사용하는 테스트는 “가장 단순한 CRUD로 도메인 관련 질의에 얼마나 쉽게 응답할 수 있는가?” 입니다. 특정 질의를 답하는데 4개의 데이터가 필요하고 항상 같이 불러와야 한다면, 애초에 나뉘어져야 하는 데이터인가요? 반대로 하나의 큰 데이터로 통합되어 있다면 나눠야 할까요? CRUD를 수행하는데 복잡하다면 데이터 설계에 적신호가 들어온 것과 같습니다. 제 경험 상 대부분의 질의는 단순하고 어려운 것도 몇 번의 JOIN만으로 해결할 수 있었습니다. 그리고 데이터는 항상 무-맥락이어야 합니다. 만약 특정 필드가 “이럴 때는 A고 저럴 때는 B야”라는 형태라면 절대 안됩니다. 이런 유형의 데이터는 시스템을 정의할 때 문제를 유발합니다. 예를 들면, X 조건일 때 id는 account_id고 Y 조건일 때 id는 user_id 같은 것입니다. 이런 데이터를 해독하고 유지 보수 해야 하는 개발자라면 신의 가호가 함께하길 기도합니다. 결론 데이터를 다루기 어려운 이유는 데이터도 시간의 흐름에 따라 변하기 때문입니다. 오늘 정의했던 도메인이 평생 동일할 것이라는 보장은 없습니다. 하지만, 데이터는 시스템에서 가장 기본이 되는 추상화 단계입니다. 만약 데이터가 복잡하고 쓰기 어렵다면, 그 위의 모든 단계에서 문제를 마주하게 될 것 입니다. 그런 의미에서 데이터를 잘 설계하고 정리하는데 시간을 쏟는 것은 그럴만한 가치가 있습니다. --- 원글: https://antonkropp.substack.com/p/challenges-with-data