인스턴스

버튼 색을 바꾸는 일이 이틀짜리 작업이던 시절이 있었습니다. 화면을 그릴 때마다 앞 화면에서 버튼을 복사해 붙여 넣었으니, 파일 안에는 똑같이 생긴 버튼이 마흔 개 흩어져 있었습니다. 하나를 고치면 나머지 서른아홉 개는 그대로 남았습니다.

페이지덱에서도 같은 일이 있었습니다. 규원이 강조색을 조금 진하게 바꾸자고 한 날, 민서는 시안 파일을 열어 화면을 하나씩 넘기며 버튼을 찾아 색을 다시 지정했습니다. 이틀이 걸렸고 세 곳을 놓쳤습니다. 놓친 세 곳은 두 주 뒤 개발 중에 드러났습니다. 태오가 "이 화면만 버튼 색이 다른데 의도하신 건가요" 하고 물어서야 알았습니다.

문제는 손이 느린 것이 아니라 같은 모양이 마흔 군데에 따로 저장되어 있다는 데 있었습니다. 어느 것이 기준인지 파일에 적혀 있지 않으니 고칠 때마다 사람이 기억으로 찾아다녀야 했습니다. 그래서 디자인 도구는 원본을 한 자리에만 두고 화면에는 그 원본을 가리키는 복제본만 놓는 쪽으로 방향을 바꿨습니다. 이 복제본이 인스턴스입니다.

원본 부품 하나를 만들어 두고 화면마다 그 원본을 가리키는 복제본을 놓으면, 원본을 고칠 때 복제본이 전부 따라옵니다. 복제본은 모양을 자기가 들고 있는 것이 아니라 원본을 가리키는 주소를 들고 있습니다. 순서는 넷입니다.

1. 원본을 만듭니다. 버튼을 한 번 제대로 그린 뒤 부품으로 등록합니다. 원본은 보통 화면 바깥의 정리용 공간에 둡니다.
2. 화면에 가져다 놓습니다. 부품 목록에서 끌어다 놓으면 그 자리에 인스턴스가 생깁니다. 마흔 개 화면에 마흔 번 끌어다 놓아도 원본은 여전히 하나입니다.
3. 자리마다 다른 부분만 덮어씁니다. 어떤 자리는 글자가 저장이고 어떤 자리는 취소입니다. 글자·아이콘·보임 여부처럼 자리마다 달라야 하는 값은 인스턴스에서 바꿀 수 있고, 덮어쓴 값은 원본이 바뀌어도 남습니다.
4. 원본을 고칩니다. 덮어쓰지 않은 속성은 마흔 개가 함께 바뀝니다. 모서리 둥글기를 4에서 8로 바꾸면 마흔 개 화면의 버튼이 전부 둥글어지고, 3번에서 글자를 바꿔 둔 자리는 글자는 그대로 둔 채 둥글기만 받습니다.

겉에 드러나는 내용은 자리마다 다르게 두고 구조와 규격은 원본이 쥐는 것이 이 경계의 규칙입니다. 버튼 높이를 인스턴스에서 바꿀 수 없는 것은 제약이 아니라 설계입니다.

원본과의 연결을 끊는 선택도 있습니다. 인스턴스를 떼어 내면 그 자리는 평범한 도형 묶음이 되어 원본을 더 이상 따라오지 않습니다. 원본에 없는 모양이 한 자리에만 필요할 때 쓰지만, 떼어 낸 자리는 다음 갱신부터 조용히 빠집니다. 반년 뒤 화면 하나만 옛 모양으로 남는 일이 대개 여기서 나옵니다.

인스턴스는 부품을 모아 둔 곳과 그 부품을 쓰는 화면 사이를 잇는 자리마다 나타납니다. 자리는 셋입니다.

1. 시안 작업. 피그마처럼 여러 사람이 같은 파일을 편집하는 도구에서 화면을 그릴 때, 버튼과 입력창은 새로 그리지 않고 부품 목록에서 끌어다 놓습니다. 화면 한 장을 만드는 일이 그리는 일에서 고르는 일로 바뀝니다.
2. 부품 공유. 팀이 컴포넌트 라이브러리, 즉 화면을 이루는 부품을 한 번 만들어 모아 둔 파일을 따로 두면 원본은 거기 있고 각자의 작업 파일에는 인스턴스만 들어옵니다. 라이브러리 쪽에서 버튼을 고치면 작업 파일마다 갱신 알림이 뜨고, 받을지 말지는 파일 주인이 정합니다. 배포 시점을 원본 쪽이 쥐는 구조입니다.
3. 개발로 넘기기. 핸드오프, 곧 디자인을 개발에 넘기는 과정에서 개발자는 화면의 각 요소가 인스턴스인지 따로 그린 도형인지를 먼저 봅니다. 인스턴스면 이미 코드로 만들어 둔 부품을 그대로 쓰면 되고, 떼어 낸 도형이면 왜 달라야 하는지 물어야 합니다. 시안 위의 연결 상태가 그대로 구현 비용이 됩니다.

인스턴스 비율은 디자인 시스템이 실제로 쓰이는지 재는 값이기도 합니다. 화면의 버튼 120개 중 90개가 인스턴스고 30개가 따로 그린 도형이면, 그 30개는 시스템이 필요를 못 따라갔거나 급해서 건너뛴 자리입니다. 그렇게 쌓인 정리 비용을 디자인 부채라고 부릅니다.

"이거 인스턴스 맞죠? 떼어 낸 거면 저희가 버튼을 새로 만들어야 해서요."

원본과 이어져 있으면 기존 코드 부품을 그대로 쓰고, 끊겨 있으면 구현 일감이 하나 늘어난다는 뜻입니다.

"라이브러리 업데이트 받으시면 버튼 높이가 40으로 바뀝니다."

원본이 바뀌었으니 각자 파일의 인스턴스가 갱신을 받아야 한다는 안내입니다.

"여기만 인스턴스를 떼어 놨네요. 왜 그랬는지 기억나세요?"

이 자리만 원본을 따라오지 않으니 그럴 만한 이유가 있었는지 확인하는 말입니다.

페이지덱에서 민서가 요금제 화면을 만드는 날의 순서는 이렇습니다. 라이브러리에서 버튼을 끌어다 놓고 글자만 무료로 시작하기로 바꿉니다. 며칠 뒤 규원이 강조색을 바꾸자고 하면 민서는 원본 하나를 고치고 라이브러리를 배포합니다. 다음 날 태오가 파일을 열면 갱신 알림이 떠 있고, 받는 순간 화면 마흔 장의 버튼이 함께 새 색이 됩니다.

그날 눈에 띄는 것은 따라오지 않은 자리입니다. 옛 색으로 남은 버튼 하나를 민서가 들여다보니 지난달 마감에 쫓겨 떼어 낸 자리였습니다. 그 모양이 쓸 만하면 원본에 형태를 하나 더해 되돌려 붙이고, 그때뿐인 예외였으면 원본 것으로 갈아 끼웁니다.

인스턴스는 손댈 수 없으니 고치려면 떼어 내야 한다는 말을 자주 듣습니다. 원본을 따라온다는 설명만 들으면 자연스러운 짐작입니다. 실제로는 글자와 아이콘과 보임 여부는 인스턴스에서 그대로 바꿀 수 있고, 그렇게 덮어쓴 값은 원본이 갱신돼도 살아남습니다. 이걸 모르고 글자 한 줄 때문에 떼어 내면 그 자리는 이후 모든 갱신에서 빠지고, 색이나 높이가 바뀌는 날 혼자 옛 모양으로 남습니다.

복사해 붙인 것과 결국 같다는 오해도 흔합니다. 화면을 눈으로 보면 둘은 구별되지 않고, 만드는 순간의 품도 비슷하니 굳이 나눌 이유가 없어 보입니다. 차이는 처음 고치는 날에 드러납니다. 인스턴스 마흔 개는 원본 한 번으로 끝나고 복사본 마흔 개는 마흔 번이 듭니다. 복사로 쌓아 둔 파일은 화면이 늘수록 고치는 비용이 같이 늘고, 결국 색 하나 바꾸자는 요청에 누구도 선뜻 답하지 못하게 됩니다.