경험 중심 1인칭 답변
팀 프로젝트에서 디자이너가 완성한 UI를 구현 단계에서 바꿔야 하는 상황이 생겼습니다. 기술적으로 특정 애니메이션 효과가 당시 사용하는 프레임워크에서 성능 문제를 일으켰는데, 이미 디자이너가 여러 화면에 동일하게 적용한 상태였습니다. 처음에 제가 '이건 안 된다'고 직접 말했더니 디자이너 입장에서는 갑작스러운 통보처럼 느껴졌습니다. 이후에는 방식을 바꿔서 구현이 어려운 부분을 미리 공유하는 기술 리뷰 세션을 디자인 중반부에 넣었습니다. 서로 초안 단계에서 제약 조건을 공유하니 이후에 수정이 크게 줄었고, '개발이 막는다'는 인식도 없어졌습니다. 협업에서 갈등은 대부분 정보 공유 타이밍 문제라는 걸 배웠습니다. 지금도 협업 초반에 기술 제약을 먼저 공유하는 습관을 유지합니다. 앞으로도 협업할 때 기술 제약을 디자인 초반에 공유하는 방식을 유지하겠습니다.
협업의 갈등은 대부분 정보 공유 타이밍 문제에서 시작됩니다. 서로의 제약을 일찍 알면 의도치 않은 수정 비용이 사라집니다. 조율은 결과물보다 과정에서 이뤄져야 합니다.