디자인 시스템을 다시 정리하면서 컴포넌트 이름을 들여다보고 있는데요, 피그마에서 칩이라고 부르던 게 코드에는 태그로 올라가 있더라고요. 둘 다 틀린 이름은 아니라서 오히려 더 애매했어요. 저는 일단 개발팀 쪽 이름을 따라가는 걸로 기울고 있는데, 그러면 예전 디자인 문서들이 통째로 어긋나는 게 걸립니다. 이름을 맞추는 기준, 다들 어떻게 정하셨는지 궁금합니다.
#디자인시스템#컴포넌트#네이밍#개발협업#피그마
10.1 01:47조회수 0댓글 9
나윤영상 디자이너 · 신입
저도 회사에서 팀 안에서만 쓰는 이름 때문에 비슷한 걸 겪었거든요. 영상 쪽이라 결이 좀 다를 수 있는데, 저희는 인트로에 붙는 모션을 디자인팀에선 "타이틀 모션"이라고 부르고 마케팅팀 요청서엔 "로고 인트로"로 적혀 오더라고요. 둘 다 같은 걸 가리키는데 시안 파일명은 계속 따로 놀았어요.
근데 궁금한 게 하나 있는데요, 개발팀 쪽 이름이 코드에 태그로 올라가 있는 건 그쪽에서 정한 컨벤션 문서 같은 게 따로 있어서인가요, 아니면 처음 구현한 분이 그냥 그렇게 쓰신 게 굳어진 건가요. 문서에 적혀 있는 이름이 있다면 맞추는 근거가 되는데 그게 아니면 옛날 디자인 문서를 갈아엎을 이유로는 좀 약한 것 같아서요.
10.1 01:48
수민BX 디자이너 · 9년차
저는 인하우스라 코드 쪽 이름은 볼 일이 잘 없었는데, 가이드 개정 때 비슷한 걸 겪었습니다. 같은 요소를 문서마다 다르게 부르고 있어서 어느 쪽으로 통일할지보다 그 요소를 뭐로 볼지부터 막히더라고요. 칩과 태그도 이름 문제가 아니라 그 컴포넌트가 무슨 역할을 하는 건지에서 갈리는 것 같고요.
그래서 저는 이름을 고르기 전에 정의를 한 줄씩 적어두는 편입니다. 선택 상태가 있으면 칩, 분류 표시면 태그, 이런 식으로요. 그렇게 적어두니 예전 문서가 어긋나도 어디까지 바꿔야 하는지는 보였습니다.
다만 개발팀 이름을 따라가는 게 맞는지는 저도 판단이 안 서요. 현우 님은 개발팀 이름을 따르기로 기울었다고 하셨는데, 그 이름들이 어디에 정의로 적혀 있나요. 저는 근거가 코드에만 있으면 다음 개정 때 또 같은 자리로 돌아올 것 같아서요. 다들 어떻게 하시는지 궁금합니다.
10.1 01:48
소영BX 디자이너 · 8년차
이름 통일보다 먼저 정해두면 좋은 게, 언제까지 예전 문서를 유효한 걸로 볼 건지 날짜를 박아두는 겁니다. 저는 BX 쪽이라 컴포넌트 라이브러리를 직접 관리해본 적은 없는데요, 팀 룰 문서를 한 장에서 세 장으로 가르면서 비슷한 걸 겪었거든요. 네이밍은 고정, 대신 고정하는 시점에 "이 날짜 이전 문서의 칩은 지금 태그를 말한다" 한 줄을 남겼습니다. 옛날 문서를 다 고치는 건 애초에 안 되더라고요.
이름 자체보다 걸리는 건 왜 태그로 정했는지가 어디에도 안 남는 경우예요. 개발팀 이름을 따라가는 것 자체는 합리적인데, 3주쯤 지나서 누가 "칩이 더 맞지 않나요" 하고 다시 열면 그때 꺼낼 근거가 없으면 또 처음부터 시작하거든요. 결정된 것, 왜 그렇게 정했는지, 다음에 누가 뭘 바꾸는지 세 줄이면 충분한 것 같아요. 궁금한 게 있는데, 혹시 이번 정리에서 이름이 어긋난 컴포넌트가 몇 개쯤 되나요?
전면 통일인지 몇 건짜리인지에 따라 결이 좀 다를 것 같아서요.
10.1 01:49
현우작성자시니어 프로덕트 디자이너 · 12년차
이번 건은 전면 통일은 아니고 어긋난 게 아홉 개였어요. 칩/태그처럼 아예 다른 단어인 건 세 개고, 나머지는 대소문자나 단수 복수 정도라 사실 반나절이면 끝나는 양이었는데요, 그런데도 일주일을 끈 건 말씀하신 그 세 줄이 없어서였습니다. 결정만 있고 근거가 없으니 누가 물어볼 때마다 제가 다시 설명했어요.
그래서 지금은 이름 옆에 왜 이쪽으로 갔는지랑 기준 날짜를 같이 적어두는 쪽으로 정리하고 있어요.
10.1 01:49
채원스타트업 디자이너 · 3년차
저도 이름 어긋나는 문제를 겪었는데요, 저희는 코드 쪽을 따라갔습니다. 근거는 하나였어요. 디자인 문서는 저 혼자 고치면 되는데 코드 네이밍 바꾸면 개발자분이 컴포넌트 파일이랑 import 전부 건드려야 하거든요. 고치는 비용이 싼 쪽을 움직이는 게 맞다고 봤어요.
근데 저는 예전 문서를 다 맞추진 않았습니다. 시리즈A라 그 시간에 시안 하나 더 만드는 쪽을 택하는 편이라, 지금 살아있는 화면에 쓰이는 컴포넌트만 이름 바꾸고 나머지는 그냥 뒀거든요. 어차피 안 보는 문서는 이름이 맞아도 안 보더라고요. 한 가지 걸리는 건, 12년차에 시니어시면 문서가 팀 자산으로 굴러가는 규모일 수도 있겠다 싶어서요.
혹시 현우님 팀은 예전 디자인 문서를 실제로 다시 열어보는 일이 자주 있는 편인가요? 그 빈도에 따라 판단이 달라질 것 같아서 궁금합니다.
10.1 01:50
현우작성자시니어 프로덕트 디자이너 · 12년차
저희는 자주 열지는 않는데, 열리는 타이밍이 정해져 있더라고요. 리뉴얼 논의나 비슷한 화면 새로 짤 때 "예전에 이거 왜 이렇게 했더라" 하고 찾아 들어가는 식이에요. 1년에 몇 번 안 되는데 그때 이름이 어긋나 있으면 문서를 못 찾아서 결국 사람한테 물어보게 되고, 그게 팀 자산으로 안 굴러가는 지점이었어요.
그래서 저도 전면 통일은 안 할 생각이고, 대신 살아있는 컴포넌트 기준이 아니라 다시 열릴 가능성이 있는 문서 기준으로 자르려고요. 판단이 남아 있는 문서만요. 채원님 쪽은 그때 못 찾으면 물어볼 사람이 아직 회사에 남아 있는 규모인가요?
10.1 01:50
채원스타트업 디자이너 · 3년차
저희는 남아 있긴 한데 그게 더 문제였어요. 시리즈A라 인원이 적어서 물어볼 사람은 옆자리에 있는데, 그러니까 아무도 문서를 안 찾거든요. 그냥 물어보는 게 빠르니까요. 저도 3년 다니면서 예전 화면 왜 이렇게 했는지 두 번쯤 다시 열어봤는데, 결국 문서 말고 사람 기억으로 해결했어요.
근데 그래서 다시 열릴 문서 기준으로 자르시는 건 저한테도 설득력 있게 들리는데요, 저희 규모에선 그 기준으로 잘라도 대상이 서너 개밖에 안 나올 것 같아요. 판단이 남아 있는 문서가 애초에 그만큼밖에 없어서요.
10.1 01:51
나린프로덕트 디자이너 · 11년차
칩/태그 케이스랑 비슷한 걸 저희도 겪었는데, 저희는 개발팀 이름을 따라가되 "언제부터"를 코드 릴리즈 버전에 붙였습니다. 이름을 통째로 바꾸면 예전 문서가 어긋나는 게 아니라, 어느 시점 기준으로 어긋난 건지 아무도 모르게 되는 게 더 컸거든요.
그리고 저는 이름 두 개가 다 맞아 보일 때 기준을 하나만 봅니다. 장애나 QA 이슈 올라올 때 어느 이름으로 불리느냐. 저희는 티켓 제목을 쭉 검색해봤더니 개발팀 이름이 압도적이었고, 그래서 체감으로 고르지 않고 그 기록으로 정했어요. 예전 문서는 안 고쳤습니다. 대신 구 문서 상단에 "이 문서의 컴포넌트 명칭은 v2.x 기준"만 박았고, 그게 전수 수정보다 싸게 끝났더라고요
🙂 현우님 쪽은 예전 디자인 문서를 아직 참조하는 사람이 있나요? 참조가 없으면 맞추는 비용이 거의 안 들 텐데요.
10.1 01:51
현우작성자시니어 프로덕트 디자이너 · 12년차
예전 문서를 참조하는 사람이 있냐고 물으시니 답부터 드리면, 있습니다. 자주는 아닌데 리뉴얼 논의나 비슷한 화면 새로 짤 때 "예전에 이거 왜 이렇게 했더라" 하고 열어보는 식이라 1년에 몇 번 수준이에요.
그런데 그때 열어보는 사람이 대체로 신규 입사자라, 어긋난 이름을 보고 저를 찾아오는 비용이 생기더라고요. 티켓 제목 검색은 저도 바로 해볼 수 있는 방법이라 쓸모가 있어 보이고, 구 문서 상단에 기준 버전만 박는 것도 전수 수정보다 확실히 싸겠네요. 완벽한 해결은 아니겠지만 그 두 개는 그대로 가져가볼 생각입니다.
저도 회사에서 팀 안에서만 쓰는 이름 때문에 비슷한 걸 겪었거든요. 영상 쪽이라 결이 좀 다를 수 있는데, 저희는 인트로에 붙는 모션을 디자인팀에선 "타이틀 모션"이라고 부르고 마케팅팀 요청서엔 "로고 인트로"로 적혀 오더라고요. 둘 다 같은 걸 가리키는데 시안 파일명은 계속 따로 놀았어요. 근데 궁금한 게 하나 있는데요, 개발팀 쪽 이름이 코드에 태그로 올라가 있는 건 그쪽에서 정한 컨벤션 문서 같은 게 따로 있어서인가요, 아니면 처음 구현한 분이 그냥 그렇게 쓰신 게 굳어진 건가요. 문서에 적혀 있는 이름이 있다면 맞추는 근거가 되는데 그게 아니면 옛날 디자인 문서를 갈아엎을 이유로는 좀 약한 것 같아서요.
저는 인하우스라 코드 쪽 이름은 볼 일이 잘 없었는데, 가이드 개정 때 비슷한 걸 겪었습니다. 같은 요소를 문서마다 다르게 부르고 있어서 어느 쪽으로 통일할지보다 그 요소를 뭐로 볼지부터 막히더라고요. 칩과 태그도 이름 문제가 아니라 그 컴포넌트가 무슨 역할을 하는 건지에서 갈리는 것 같고요. 그래서 저는 이름을 고르기 전에 정의를 한 줄씩 적어두는 편입니다. 선택 상태가 있으면 칩, 분류 표시면 태그, 이런 식으로요. 그렇게 적어두니 예전 문서가 어긋나도 어디까지 바꿔야 하는지는 보였습니다. 다만 개발팀 이름을 따라가는 게 맞는지는 저도 판단이 안 서요. 현우 님은 개발팀 이름을 따르기로 기울었다고 하셨는데, 그 이름들이 어디에 정의로 적혀 있나요. 저는 근거가 코드에만 있으면 다음 개정 때 또 같은 자리로 돌아올 것 같아서요. 다들 어떻게 하시는지 궁금합니다.
이름 통일보다 먼저 정해두면 좋은 게, 언제까지 예전 문서를 유효한 걸로 볼 건지 날짜를 박아두는 겁니다. 저는 BX 쪽이라 컴포넌트 라이브러리를 직접 관리해본 적은 없는데요, 팀 룰 문서를 한 장에서 세 장으로 가르면서 비슷한 걸 겪었거든요. 네이밍은 고정, 대신 고정하는 시점에 "이 날짜 이전 문서의 칩은 지금 태그를 말한다" 한 줄을 남겼습니다. 옛날 문서를 다 고치는 건 애초에 안 되더라고요. 이름 자체보다 걸리는 건 왜 태그로 정했는지가 어디에도 안 남는 경우예요. 개발팀 이름을 따라가는 것 자체는 합리적인데, 3주쯤 지나서 누가 "칩이 더 맞지 않나요" 하고 다시 열면 그때 꺼낼 근거가 없으면 또 처음부터 시작하거든요. 결정된 것, 왜 그렇게 정했는지, 다음에 누가 뭘 바꾸는지 세 줄이면 충분한 것 같아요. 궁금한 게 있는데, 혹시 이번 정리에서 이름이 어긋난 컴포넌트가 몇 개쯤 되나요? 전면 통일인지 몇 건짜리인지에 따라 결이 좀 다를 것 같아서요.
이번 건은 전면 통일은 아니고 어긋난 게 아홉 개였어요. 칩/태그처럼 아예 다른 단어인 건 세 개고, 나머지는 대소문자나 단수 복수 정도라 사실 반나절이면 끝나는 양이었는데요, 그런데도 일주일을 끈 건 말씀하신 그 세 줄이 없어서였습니다. 결정만 있고 근거가 없으니 누가 물어볼 때마다 제가 다시 설명했어요. 그래서 지금은 이름 옆에 왜 이쪽으로 갔는지랑 기준 날짜를 같이 적어두는 쪽으로 정리하고 있어요.
저도 이름 어긋나는 문제를 겪었는데요, 저희는 코드 쪽을 따라갔습니다. 근거는 하나였어요. 디자인 문서는 저 혼자 고치면 되는데 코드 네이밍 바꾸면 개발자분이 컴포넌트 파일이랑 import 전부 건드려야 하거든요. 고치는 비용이 싼 쪽을 움직이는 게 맞다고 봤어요. 근데 저는 예전 문서를 다 맞추진 않았습니다. 시리즈A라 그 시간에 시안 하나 더 만드는 쪽을 택하는 편이라, 지금 살아있는 화면에 쓰이는 컴포넌트만 이름 바꾸고 나머지는 그냥 뒀거든요. 어차피 안 보는 문서는 이름이 맞아도 안 보더라고요. 한 가지 걸리는 건, 12년차에 시니어시면 문서가 팀 자산으로 굴러가는 규모일 수도 있겠다 싶어서요. 혹시 현우님 팀은 예전 디자인 문서를 실제로 다시 열어보는 일이 자주 있는 편인가요? 그 빈도에 따라 판단이 달라질 것 같아서 궁금합니다.
저희는 자주 열지는 않는데, 열리는 타이밍이 정해져 있더라고요. 리뉴얼 논의나 비슷한 화면 새로 짤 때 "예전에 이거 왜 이렇게 했더라" 하고 찾아 들어가는 식이에요. 1년에 몇 번 안 되는데 그때 이름이 어긋나 있으면 문서를 못 찾아서 결국 사람한테 물어보게 되고, 그게 팀 자산으로 안 굴러가는 지점이었어요. 그래서 저도 전면 통일은 안 할 생각이고, 대신 살아있는 컴포넌트 기준이 아니라 다시 열릴 가능성이 있는 문서 기준으로 자르려고요. 판단이 남아 있는 문서만요. 채원님 쪽은 그때 못 찾으면 물어볼 사람이 아직 회사에 남아 있는 규모인가요?
저희는 남아 있긴 한데 그게 더 문제였어요. 시리즈A라 인원이 적어서 물어볼 사람은 옆자리에 있는데, 그러니까 아무도 문서를 안 찾거든요. 그냥 물어보는 게 빠르니까요. 저도 3년 다니면서 예전 화면 왜 이렇게 했는지 두 번쯤 다시 열어봤는데, 결국 문서 말고 사람 기억으로 해결했어요. 근데 그래서 다시 열릴 문서 기준으로 자르시는 건 저한테도 설득력 있게 들리는데요, 저희 규모에선 그 기준으로 잘라도 대상이 서너 개밖에 안 나올 것 같아요. 판단이 남아 있는 문서가 애초에 그만큼밖에 없어서요.
칩/태그 케이스랑 비슷한 걸 저희도 겪었는데, 저희는 개발팀 이름을 따라가되 "언제부터"를 코드 릴리즈 버전에 붙였습니다. 이름을 통째로 바꾸면 예전 문서가 어긋나는 게 아니라, 어느 시점 기준으로 어긋난 건지 아무도 모르게 되는 게 더 컸거든요. 그리고 저는 이름 두 개가 다 맞아 보일 때 기준을 하나만 봅니다. 장애나 QA 이슈 올라올 때 어느 이름으로 불리느냐. 저희는 티켓 제목을 쭉 검색해봤더니 개발팀 이름이 압도적이었고, 그래서 체감으로 고르지 않고 그 기록으로 정했어요. 예전 문서는 안 고쳤습니다. 대신 구 문서 상단에 "이 문서의 컴포넌트 명칭은 v2.x 기준"만 박았고, 그게 전수 수정보다 싸게 끝났더라고요 🙂 현우님 쪽은 예전 디자인 문서를 아직 참조하는 사람이 있나요? 참조가 없으면 맞추는 비용이 거의 안 들 텐데요.
예전 문서를 참조하는 사람이 있냐고 물으시니 답부터 드리면, 있습니다. 자주는 아닌데 리뉴얼 논의나 비슷한 화면 새로 짤 때 "예전에 이거 왜 이렇게 했더라" 하고 열어보는 식이라 1년에 몇 번 수준이에요. 그런데 그때 열어보는 사람이 대체로 신규 입사자라, 어긋난 이름을 보고 저를 찾아오는 비용이 생기더라고요. 티켓 제목 검색은 저도 바로 해볼 수 있는 방법이라 쓸모가 있어 보이고, 구 문서 상단에 기준 버전만 박는 것도 전수 수정보다 확실히 싸겠네요. 완벽한 해결은 아니겠지만 그 두 개는 그대로 가져가볼 생각입니다.