혼돈은 왜 반복되는가?

지켜지지 않는 UI, 반복되는 수정, 그 시작은 어디였을까

혼돈의 시작

똑같은 버튼을 세 번째 만들고 있다는 사실을 알게 된 건, 어느 늦은 밤이었다. 지난 프로젝트에서도 만들었고, 그 전 프로젝트에서도 비슷한 걸 만든 기억이 있었다.

그런데 새로운 페이지를 열 때마다, 데자뷰인지 처음부터 다시 디자인을 하고 있었고 크기도, 색도, 텍스트 정렬도 매번 조금씩 달랐다. 파일을 넘긴 뒤엔 어김없이 이런 피드백이 돌아왔다.

이거, 지난 화면이랑 왜 달라요?

처음엔 단순히 내 정리가 부족했던 탓이라고 생각했다.그래서 컴포넌트 이름도 바꿔보고, 정리된 디자인 파일을 만들어 공유해봤다. 하지만 정리한 자료는 금방 낡았다. 디자인은 프로젝트마다 조금씩 바뀌었고, 그때마다 기준도 따라 바뀌었다. 이전 기준은 금방 무시되거나 삭제됐다.

파일은 점점 복잡해졌고, 컴포넌트는 쓸수록 예외가 많아졌다. 기준을 세우는 것보다, 예외를 허용하는 게 더 빠르다는 공기가 돌았다. 어느새 ‘왜 또 다르지?’라는 의문을 가지게 되었고, 지켜지지 않는 기준. 반복되는 수정. 협업 중의 충돌. 문제는 단순히 디자인의 문제를 넘어서고 있었다.

하지만, 이 혼돈은 나만 겪는 게 아니었다. 팀 안에서, 디자이너마다 다른 스타일이 섞이고 있었고 심지어 디자이너들끼리 프로젝트마다 디자인 방식이 달랐다. 각자가 ‘좋다고 생각한 방식’을 쓰는 일. 그것은 ‘자유’가 아니라 ‘불일치’였다. 결국, 디자인 시스템은커녕 누구도 책임지지 않는 UI만 계속 쌓이고 있었다.

프로젝트는 바뀌지만, 문제는 반복된다

늘 ‘처음처럼’ 시작되는 프로젝트 한 프로젝트가 끝나고, 새로운 프로젝트가 시작될 때면 팀은 항상 비슷한 질문으로 회의를 시작했다

“이번에는 버튼 사이즈를 어떻게 하지?”
“지난 프로젝트에서는 어떤 컬러를 썼더라?”
“그 컴포넌트, 피그마 어디에 저장돼 있어요?”

마치 이전 프로젝트의 자산은 존재하지 않았던 것처럼. 우리는 매번 모든 걸 새로 정리하고, 새로 정의하고, 새로 그렸다. ‘어딘가’ 있었던 기준을 누군가는 기억하지만, 그 기준이 어디에 있었는지, 지금도 유효한지, 함께 일하는 모든 사람이 알고 있는지는 아무도 확신하지 못했다.

경험의 축적이 아니라 혼돈의 반복

개발자들은 스타일 값을 매번 새로 정의해야 했고, 디자이너들은 과거의 디자인을 참고하기보다 새로 만드는 쪽이 빠르다고 여겼다. 협업의 속도는 느려졌고, 디테일의 누락과 의도치 않은 오류가 잦아졌다.

나는 그제야 문제의 본질을 보게 되었다. 이건 사람의 문제가 아니라, 구조의 문제였다. 디자인 시스템이 없다는 건 “기준이 없어도 각자 잘하겠지”라는 막연한 믿음 위에 모든 걸 맡기는 일이다. 일관성 없는 결과는, 당연한 결과였다. 우리는 이미 알고 있다. 어떤 UI가 좋고 나쁜지를 말하기 전에, 어떤 기준이 있었고 그 기준이 지켜졌는지를 먼저 물어야 한다는 걸.

결국 문제는 ‘사일로’가 아닌, ‘시스템’의 부재였다

‘각자 잘하는 사람’들이 모였음에도 불구하고 결과물이 일관되지 않았다는 건, 사람이 아니라 시스템의 문제라는 것이다. 디자인 시스템은 단순히 버튼, 모달, 색상 코드만의 문제가 아니었다. 그건 협업 방식의 재정의였고, 프로덕트를 바라보는 통합된 관점의 정립이었다. 우리는 그동안 다음과 같은 착각 속에 있었다.

가이드가 몇 장 있다면 시스템이라 생각했다.
컴포넌트를 복사해 쓰면 재사용이라 착각했다.
컴포넌트를 만들었지만, 팀 전체가 그 구조를 이해하지 못했다.

그래서 나는 이 글을 쓰기 시작했다. 더는 똑같은 버튼을 세 번째 만들지 않기 위해, 혼돈 그 자체인 사내 시스템을 벗어나기 위해 디자인 시스템을 만들어야 할 때라고 생각했기 때문에.

그리고 이 글은 그 시작을 담은 기록이다.

혼돈을 반복하지 않기 위한, 작은 구조의 시작.