DESIGN.md => 코드 방향은 자동화하기 쉬운데, 반대로 코드에 새로 생긴 패턴이 DESIGN.md로 올라오는 건 자동이 안 돼서 사람이 직접 챙겨야 하더라구요. 시간이 지나면 코드엔 자잘한 하드코딩이 쌓이는데 문서엔 안 올라가는 일이 누적되구요.
다만 이 포맷의 철학 자체가 "디자인 시스템을 코드베이스 안에서 계속 가꾸어 나간다"는 쪽이라, 이게 단점이라기보다는 의도된 운영 방식에 가깝다고 봅니다. Notion이나 PDF에 박제해두던 가이드를 PR 단위 리뷰 대상으로 끌어내린 만큼, 사람이 주기적으로 손보는 책임도 같이 따라오는 구조인 것 같아요. 저희 프로젝트에 도입해 봤는데 도입 전보다 화면 일관성이 확실히 올라갔고, 그 효용이 체감되니 수동 리뷰가 부담으로 느껴지지 않더라구요. 결국 AI가 따라야 할 기준을 팀이 얼마나 명확하게 남겨두는가의 문제이고, 그 기준을 살아있게 유지하는 손길까지는 사람이 가져가는 구조라고 정리하게 됐습니다.
궁금한게 있는데 DESIGN.md는 디자인을 뽑아내기 위한 지시사항이라고 보면. 결국 처음 몇페이지.. 또는 한 페이지, 무드 보드를 생성하기 위해 사용되고. 그 이후에는 코드 - 지시.md 간의 불일치가 발생해서 계속 양방향 동기화를 해야 하지 않나요?
결국 이후의 디자인은 코드를 source of truth로 보고 일관성있게 변수나 이름 같은 것들을 재사용해야 하는데. DESIGN.md를 지속적으로 업데이트하며 SSoT로 관리하지 않으면 계속 토큰을 하드코딩하는 게 아닌가 싶은데. 실제 사용에 있어 이런 문제가 없는지 궁금합니다.