단일 진실의 원천(SSOT), 왜 중요할까?

개발 공부하다 보면 "SSOT"라는 단어가 꼭 한 번은 튀어나오는데, 처음 보면 뭔가 되게 어려워 보인다.
사실 알고 보면 개념은 생각보다 단순하고, 실무에서 엄청 중요하게 쓰인다.

이번 포스팅에서는 SSOT가 뭐고, 왜 중요한지, 예시랑 함께 쉽게 정리해보려고 한다.

SSOT(Single Source of Truth, 단일 진실의 원천)란?

SSOT = Single Source of Truth, 말 그대로 진실은 하나의 출처에서만 나오게 하자는 개념이다.

즉, 어떤 데이터나 정보가 여러 군데 흩어져 있지 않고, 딱 하나의 기준만 존재하게 만들자는 의미이다.
그래야 헷갈리지 않고, 문제 생겼을 때도 어디만 보면 되는지 알 수 있다.

예를 들어서 쉽게 설명하면,

📅 회사 스케줄 표가 있다라고 하자.

누구는 구글 캘린더에, 누구는 슬랙에, 누구는 메모장에 따로따로 적어놨다. 그러면 누군가가 스케줄을 바꿔도 다른 데엔 그대로라서 사고가 나기 딱 좋다.

그래서 다 같이 구글 캘린더 하나만 쓰기로 하면? 그 캘린더가 SSOT가 되는 것이다.
모두가 같은 곳을 보고, 정보도 하나만 업데이트하면 끝이다.
이런 식으로, SSOT는 정보의 일관성을 유지하고, 혼란을 줄이는 데 도움을 준다.

SSOT가 왜 중요할까?

• 1. 데이터 일관성 유지: 모든 구성원이 동일한 데이터를 사용하므로, 정보의 일관성이 유지된다.
• 2. 업무 효율성 향상: 중복된 작업을 줄이고, 데이터 관리가 간소화되어 업무 효율성이 향상된다.
• 3. 신뢰성 있는 의사결정: 정확하고 최신의 데이터를 기반으로 의사결정을 내릴 수 있다.
• 4. 문제 해결 용이: 문제가 발생했을 때, 단일한 데이터 출처를 확인하여 신속하게 원인을 파악하고 해결할 수 있다.

개발에서 SSOT가 어떻게 쓰일까?

1. 상태 관리

React 같은 프론트엔드 개발에서는, 앱 상태를 어디서 관리하냐가 중요한데 컴포넌트마다 제각각 state를 들고 있으면 나중에 다 꼬인다.
그래서 Redux, Zustand 같은 걸로 중앙에 상태를 하나만 둬서 다 거기서 가져오게 만든다. 그 중앙 상태가 SSOT라고 볼 수 있다.

2. 데이터베이스

백엔드에서는 데이터베이스가 SSOT 역할을 한다. 모든 데이터는 DB에 저장되고, 애플리케이션은 DB에서 데이터를 가져와서 사용한다. 이렇게 하면 데이터의 일관성을 유지할 수 있다.

3. .env 같은 환경 설정

앱의 설정 값 (예: API URL, 비밀번호 등)이 여기저기 흩어져 있으면 추후에 관리하기가 매우 어려워진다. 개발할 때, API 키나 비밀번호 같은 중요한 정보는 .env 파일에 저장한다. 이 파일이 SSOT 역할을 해서, 모든 환경에서 동일한 설정을 사용할 수 있게 해준다.

4. 디자인 시스템

버튼 디자인을 페이지마다 다르게 하면 유지보수하기가 매우 힘들어진다. 디자인 요소들의 규칙과 재사용 가능한 컴포넌트들을 정리한 디자인 시스템을 만들면, 모든 페이지에서 같은 컴포넌트을 사용하게 된다.
이때, 이 컴포넌트가 디자인 시스템의 SSOT 역할을 한다. 즉, 컴포넌트의 디자인과 동작이 통일되고, 변경이 필요할 때도 한 곳만 수정하면 된다.

Frontend 관점에서 바라보는 SSOT

상태 관리: 전역 상태를 한 곳에 모으기

프론트엔드에서 SSOT는 주로 state 관리와 관련이 있다.

React에서는 컴포넌트의 상태를 관리하기 위해 useState와 같은 Hook을 사용한다.
부모 컴포넌트에서 상태를 관리할 때, 여러 컴포넌트가 동일한 상태를 공유해야 하는 경우가 많다.
보통 부모 컴포넌트에서 state를 관리하고, 자식 컴포넌트에 props로 전달하거나, Context API등을 사용하여 상태를 공유하는 방법을 사용한다.

하지만 부모 컴포넌트 하위에 있는 자식 컴포넌트에서 같은 로직에 해당되는 state들을 따로 선언하고 관리하게 되면, 하나의 컴포넌트에서 state가 바껴도 다른 컴포넌트에서는 바뀌지 않게 된다.
이는 SSOT의 개념에 어긋난다고 볼 수 있고 SSOT가 왜 중요한지 알 수 있는 예시가 된다.

UI 시스템: 디자인 시스템 기반 컴포넌트

버튼이나 카드 같은 UI 요소들을 페이지마다 제각각 구현하면 나중에 디자인 수정이 정말 힘들어진다.

그래서 보통 shared/ui 폴더나 @/components/common/ 디렉토리에 공통 UI 컴포넌트들을 정의하고 재사용한다.
여기서 Button.tsx, Input.tsx 같은 컴포넌트는 디자인의 SSOT 역할을 합니다.

만약 디자인 바뀌게 되면 이 컴포넌트들만 수정하면 되기 때문에 관리가 편리해진다.
따라서 전역적인 일관성과 유지보수성 확보을 위해 UI 컴포넌트들을 한 곳에 모아두는 것이 좋다.
이런 식으로 UI 컴포넌트들을 모아두는 것을 디자인 시스템이라고 한다.

개인적으로 본인은 FSD (Feature-Sliced Design)를 선호하는데, 이 방법은 컴포넌트를 기능 단위로 나누어 관리를 효율적으로 할 수 있도록 도와준다.
여기서도 공통 자원은 shared/, features/ 같은 디렉토리에 모은다.
이렇게 하면 각 기능별로 필요한 컴포넌트들을 쉽게 찾을 수 있고, 재사용성도 높아진다.

따라서 FSD는 SSOT를 "어디에 위치시키고 어떻게 참조할지"를 구조적으로 잡아주는 도구라고 볼 수 있다.

마무리

SSOT(Single Source of Truth)는 데이터의 일관성, 신뢰성, 유지보수성을 확보하는 데 핵심적인 개념이다.
정보가 여러 곳에 분산되었을 때 발생하는 불일치, 혼란, 반복작업을 막고, 모든 구성원이 동일한 데이터를 참조할 수 있도록 하는 구조를 만드는 것이 목적이다.
SSOT를 제대로 구현하려면 단순히 "한 곳에 두자"라기 보다는, 어떻게 하면 모든 팀원이 그 정보를 쉽게 접근하고 이해할 수 있을지를 고민해야 한다.
결국 SSOT는 단순한 기술이 아니라, 설계 철학이자 협업 문화에 가깝다.
잘 구축된 SSOT는 프론트엔드와 백엔드, 디자이너, 기획자 모두에게 신뢰할 수 있는 기준점을 제공하며, 이는 곧 제품의 품질과 개발 효율성으로 이어질 수 있다.