AI 시대 디자인 시스템의 한계, 이제는 글쓰기가 먼저인 이유

들어가며, 피그마보다 먼저 열어야 할 파일이 있다 요즘 팀에서 일하다 보면 이런 순간 다들 겪어보셨을 거예요. 누군가 피그마 파일을 열고 이것저것 만지다 보면, 어느새 그게 공식 방향이 되어버리는 흐름이요. 아무도 승인한 적 없는데 그냥 쌓이고 쌓여서 기정사실이 되는 거죠.

최근 해외 디자인 커뮤니티에서 이 문제를 정면으로 짚은 글 두 편이 화제였어요. 결론은 하나로 모입니다. AI 시대에는 만들기 전에 쓰는 게 먼저라는 거예요. 오늘은 이 얘기를 실무 맥락에서 풀어볼게요.

디자인 시스템이라는 이름 자체가 함정이었다 디자인 시스템은 원래 좋은 의도로 만들어졌어요. 컴포넌트, 토큰, 가이드라인을 한곳에 모아서 개발자와 디자이너가 같은 언어로 소통하자는 거였죠. 그런데 문제가 하나 있어요. AI는 컴포넌트를 소비하지 않아요. AI는 맥락을 소비합니다.

디자인 시스템이 아무리 정교해도, AI에게 "이 컴포넌트로 화면을 만들어"라고 하면 눈에 보이는 규칙은 잘 따라요. 근데 눈에 안 보이는 제약은 다 놓쳐요. 왜 이 인터랙션을 선택했는지, 어떤 예외가 허용되는지 같은 정보는 컴포넌트 라이브러리 안에 없거든요. 슬랙 대화방에, 누군가의 기억 속에, 아니면 아무 데도 없이 흩어져 있죠.

AI가 만든 화면이 왠지 어색하게 느껴지는 이유 AI가 생성한 UI, 한 번쯤 보셨을 텐데요. 개별로 보면 그럴듯한데 전체로 보면 뭔가 따로 노는 느낌이 들어요. SAP의 최고 디자인 책임자는 이걸 이렇게 진단했어요. "고정된 화면을 전달하는 방식에서 벗어나, 디자이너는 이제 모델 기반 인터페이스가 어떻게 작동할지 이끄는 제약 조건과 안전장치를 설계해야 한다"고요.

이게 핵심이에요. AI는 지금 이 순간의 프롬프트에 최적화된 결과를 내놓아요. 그 제품이 왜 이 방향으로 진화해왔는지, 어떤 역사적 예외가 있었는지는 전혀 모른 채로요. 그래서 화면 하나하나는 말이 되는데, 쌓이면 표류하게 됩니다. 이걸 "가속된 표류"라고 부르더라고요. 사람은 어느 정도 맥락을 기억하면서 버텼지만, AI가 대량으로 화면을 뽑아내기 시작하면 맥락 부재의 비용이 폭발적으로 커진다는 뜻이에요.

프로덕트 컨텍스트, 컴포넌트보다 훨씬 넓은 개념 프로덕트 컨텍스트는 디자인 시스템보다 범위가 훨씬 넓어요. 디자인 시스템이 "어떻게 보이는가"를 정의했다면, 프로덕트 컨텍스트는 "왜 그렇게 결정했는가"까지 포함하거든요.

구체적으로는 시각적 토큰과 컴포넌트, 인터랙션 모델, 콘텐츠 원칙과 톤앤보이스, 접근성 결정, 규정 준수 경계, 그리고 예외가 생긴 이유까지 포함한 역사적 맥락이 여기 다 들어가요.

이 맥락들이 지금 어떻게 존재하냐면, 여러 팀에 흩어져 있고 문서화 수준도 제각각이고 많은 경우 암묵적인 사회적 합의로만 유지되고 있어요. 사람끼리는 맥락 없이도 어느 정도 통하지만 AI는 그게 안 됩니다. SK AX의 최근 분석도 같은 얘기를 하고 있어요. 중요한 건 누가 코드를 작성했는가가 아니라, 그 설계가 왜 이런 선택을 했는지 설명할 수 있는가라는 거예요. 결국 사람의 암묵지를 형식지로 바꾸는 작업이 먼저 되어야 한다는 뜻이죠.

글이 먼저다, 쓰기 우선 설계란 무엇인가 쓰기 우선 설계는 간단해요. 피그마 파일 열기 전에 먼저 문서를 씁니다. 왜 그럴까요? 목업은 설득력 있는 물건이에요. 겉으로 완성된 것처럼 보이면 그 아래 생각이 덜 익어 있어도 티가 안 나요. 근데 글은 숨길 수가 없어요.

"우리는 이 변경이 사용자 경험을 개선할 거라고 믿는다, 왜냐하면 현재 사용자들이 로딩 상태를 잘못 읽고 있기 때문이다" 이렇게 써놓으면 문장 하나하나가 논쟁 대상이 돼요. 근거가 맞는지, 데이터가 있는지 따지게 되죠. 이게 오히려 좋은 거예요. 피그마에서 일주일 작업하고 방향이 틀렸다는 걸 아는 것보다, 문서 토론 단계에서 하루 전에 아는 게 훨씬 저렴하니까요.

실제 프로세스는 이렇게 흘러가요. 먼저 탐색 문서를 씁니다. 핵심은 가설 문장이에요. "우리는 [변화]가 [결과]를 만들 거라고 믿는다, 이유는 [근거]이기 때문이다." 이 문장을 못 쓴다면 아직 문제를 충분히 이해하지 못한 거예요.

그다음은 동료 검토, 결정은 댓글 스레드에서 텍스트로 이뤄져요. "모바일 먼저 할까 데스크탑 먼저 할까" 같은 질문이 잘 쓴 댓글 하나로 해결되는 경우도 많아요. 회의도 재작업도 없이요. 그다음에 디렉션 문서가 나오고 빌드가 시작돼요. 코드를 쓸 때쯤이면 어려운 생각은 이미 다 끝난 상태인 거죠.

한국 팀에서 실제로 적용하는 법 외국 이야기처럼 들릴 수 있지만 한국 팀에서도 충분히 적용 가능해요. 빠르게 AI 도구를 도입하는 팀일수록 오히려 더 절실합니다.

첫 번째는 가설 문장 습관이에요. 새 기능을 시작할 때 슬랙이나 노션에 딱 한 줄, "우리는 무엇이 무슨 결과를 만들 거라고 믿는다, 이유는 무엇이다"를 먼저 씁니다. 이 습관 하나만으로 불필요한 디자인 작업을 꽤 줄일 수 있어요.

두 번째는 맥락 문서 축적이에요. 이 UI 결정을 왜 이렇게 했는지, 왜 이 예외를 허용했는지 짧게라도 남기는 거죠. AI를 프로덕트 개발에 쓸수록 이 맥락 문서가 AI를 틀린 방향으로 못 가게 잡아주는 가드레일이 돼요.

세 번째는 디자인 시스템 재정의예요. 컴포넌트 라이브러리를 디자인 시스템의 전부로 보지 말고, 왜 이렇게 결정했는지까지 포함하는 프로덕트 컨텍스트 문서로 확장하는 거예요. 눈에 안 보이던 걸 텍스트로 만드는 작업이죠.

저장하고 싶어지는 문장들 "AI는 잘 보이는 규칙은 따르고, 보이지 않는 제약은 놓친다. 맥락을 명시적으로 만들지 않으면 AI는 제품을 표류하게 만든다."

"결정을 말로 먼저 하면, 아름다운 결과물을 지키기 위해 잘못된 결정을 합리화하는 함정을 피할 수 있다."

"단락 안에서 틀리는 건 오후 한 나절의 비용이다. 코드 안에서 틀리는 건 스프린트 하나의 비용이다. 그래서 우리는 단락에서 대부분의 실수를 해야 한다."

마무리 AI가 본격적으로 프로덕트 개발에 들어오는 시대, 기획자와 디자이너의 역할은 오히려 더 중요해져요. 다만 방향이 달라져요. 더 예쁜 컴포넌트를 만드는 게 아니라 AI가 제대로 된 방향으로 갈 수 있게 맥락을 설계하는 일이 핵심이 됩니다. 디자인 시스템이 끝난 게 아니라 그 위에 쌓여야 할 게 아직 부족한 거예요. 그리고 그건 컴포넌트가 아니라 글로 시작됩니다. 다음번에 새 기능을 시작할 때, 피그마 대신 문서 파일을 먼저 열어보세요.