Senior Designer

#Retrospect #Life · 2023. 5. 23

올해 초에 조직 개편을 진행하면서, 역할에 2가지 변화가 생겼다. 디자인 시스템을 만들던 플랫폼 디자이너에서 프로덕트 디자이너로 직무 역활이 변했고, 스쿼드들이 모인 트라이브 단위의 조직이 생기면서 ‘시니어 디자이너’ (팀에서는 트라이브 디자이너라고 불렸다. 이하 시니어 디자이너) 역할도 함께 수행하게 되었다.

이 글은 약 6개월간 시니어 디자이너 역할을 수행하면서 내가 집중했던 것과 부족했던 것을 기록해두려고 작성한다. 새로운 조직개편을 앞둔 시점에 남겨보지 않으면, 영영 시간이 없을 것 같아서.. 남겨본다. 늘 그렇지만 되도록이면 매우 솔직하게 남겨보려고 노력한다.

새로운 역할, 시니어 디자이너

시니어 디자이너란 무엇일까? 직군의 전문성 레벨을 기준으로 판단했을 때 ‘주니어→시니어→스태프→프린시플 그 중간 단계를 이야기 하는 것일까? 아마 각 회사와 제품이 지금 어떤 단계인지에 따라서 시니어 디자이너 또는 그 상위 레벨의 디자이너에게 기대하는 역할이나 요구하는 역량이 매우 달라질 것 같다.

가장 보편적으로 요구하는 것은 주니어 또는 엔트리 레벨의 디자이너들 멘토링, 주도적인 프로젝트 진행 능력, 타 직군 또는 타 팀과 커뮤니케이션 주도다.

팀에서 나에게 요구하는 시니어 디자이너 역할은 크게 아래 4가지 정도였다. 제품 팀 리드가 요구했던 역할도 있고(1번과 2번), 실제로 내가 경험하면서 필요에 의해서 추가한 역할(3번)도 있다.

장기적인 관점의 제품 로드맵 또는 컨셉 설계와 탐구를 진행한다.

스쿼드와 트라이브는 일정한 스프린트 단위로 동작한다. 대부분 모두 장기적인 (1년 단위 +a ) 비전을 설정하지만 스프린트를 소화하면서 리소스를 투입해서 장기적인 비전을 실행안을 그리기 위한 여력은 부족하다.

그렇기 때문에 전반적인 도메인을 이해하면서 구조적, 구현적으로 실행이 가능한 비전을 탐구할 수 있는 디자이너가 필요했다.

스쿼드의 프로덕트 디자이너들에게 직접적인 도움을 주고 피드백도 전달한다.

도메인은 복잡한 문제를 다루는 경우가 많았지만 스쿼드는 엔트리 레벨의 디자이너들로 구성되어있었다.

따라서 디자이너들이 판단하기 어려운 것들이나 놓치기 쉬운 설계 영역, 구현 영역을 챙겨줄 수 있는 디자이너가 필요했다.

트라이브 레벨에서 고민할 수 있는 주제를 탐색하고 실행을 준비한다.

트라이브는 비슷한 맥락 또는 연계가 되면 좋은 도메인을 다루고 있는 스쿼드들이 시너지를 만들어 낼 수 있도록 모아둔 그룹이었다. 하지만 스쿼드의 빠듯한 스프린트 일정과 많은 이슈들로 좋은 연계 경험을 설계하는게 쉽지 않았다.

조금 더 넓은 관점에서 프로덕트 매니저 리드, 프로덕트 엔지니어 리드와 이야기하면서 트라이브 리소스를 조율하고, 각 도메인의 연계를 고민할 수 있는 디자이너가 필요했다.

디자인 리드 역할을 수행하지 않는다.

스쿼드 또는 목적 기반 조직으로 일하는 것은 일정 수준의 자율성을 보장한다는 것이 전제된다. 반면 우리 디자이너 문화는 리뷰와 컨펌 그 오묘한 지점을 지나고 있었다.

스쿼드에서 제품을 만드는 디자이너들의 의견과 결정을 좀 더 존중하고, 디자이너들이 일을 더 잘하기 위해서 도움을 줄 수 있는 사람이 필요했다.

지금 돌이켜 생각해보면 일반적인 시니어 디자이너에게 요구하는 역량보다는 조금 더 넓은 범위가 요구되었던 것 같다. 아마 시니어와 스태프 그 어딘가가 아니었을까?

어떻게 했을까?

쉽게 생각했는데, 막상 경험해보니 쉽지 않았다. 솔직히 이야기하면 ‘힘들었다’가 조금 더 정확한 표현이다. 매우 자세히 서술해볼까 하다가.. 너무 구구절절한 것 같아서 짧게 이야기 해본다.

처음 집중했던 것은 스쿼드 디자이너들에게 의미있는 도움을 주는 것이었다. 일종의 페어 디자인 형식으로 매일 오전에 만나서 진행사항을 함께 보면서 풀어내는 경우도 있었고, 스쿼드 위클리나 싱크 회의에 참석해서 디자이너의 의견을 보조해주거나, 피드백을 전달하는 방식을 많이 사용했다. 이외에도 디자이너들 자리를 찾아가거나, Figma 파일과 Slack 쓰레드 구경도 수시로 했다.

나도 스프린트마다 스쿼드를 바꿔가면서 PD 업무도 함께 진행했기 때문에 물리적으로 꽤 힘들었던 기억이 있다. 도메인 맥락이 정말 많기도 했고, 내가 많은 관여를 하게되면서 내 업무와 해당 스쿼드 디자이너 업무가 지연되는 경우가 점점 빈번하게 발생하게 되었다.

이 시점을 지나면서 디자이너들의 업무 과정이 내가 관여한 이슈라면 나의 확인을 받는 방향으로 점점 변하고 있는게 느껴졌다. 그래서 나의 관여도를 낮추면서도 디자이너들 사이에 서로 도움이 되는 리뷰가 활발하게 일어날 수 있도록 디자인 위클리를 시작했다.

(위클리를 만들기 전에 디자이너들끼리 유대감을 형성할 수 있도록 서로 많은 노력을 했다. 일주일에 한번은 꼭 함께 점심을 먹거나 / 정제되지 않은 디자인을 편하게 공유할 수 있게 비밀 채널을 운영한다던지.)

위클리가 만들어지고, 의견 교류가 활발해지면서 장기적인 관점의 비전 설계, 트라이브 레벨에서 시작할 수 있는 주제들에 조금 더 시간을 투자할 수 있게 되었다. 실제로 몇 가지 비전안을 설계하기도 했고, 트라이브에서 함께 고민할 수 있는 주제들을 발굴하기도 했지만 실행은 결국 스쿼드에서 해야하기 때문에, 구체적인 그림을 그리는게 어렵다는 것을 많이 경험했다.

무엇을 느꼈을까?

새로운 조직개편에서 다시 한번 시니어 디자이너 역할을 소화할 수 있다면 더 잘 할 수있을 것 같다는 이야기를 가볍게 했던 적이 있는데, 나는 짧았던 6개월간 처음으로 시니어 역할을 수행하면서 무엇을 느꼈을까?

중요한 것은 선택과 집중. 모든 것을 챙길 수 없다.

시니어 디자이너로서 스쿼드에서 이뤄지는 결정 또는 디자이너 레벨에서 이뤄지는 결정 대부분에 반드시 참여해야한다는 부담이 있었다.

또한 설계 관점 의견은 구현을 목전에 둔 상태에서 전달한다면, 방향이 완전히 재설정 되거나 일정이 미뤄지는 경우도 빈번하게 발생했기 때문에, 되도록 빠르게 파악하고 사전에 의견을 전달하려고 많은 노력을 했다.

부담감과 너무 많은 것을 한번에 파악하다보니 육체적으로, 정신적으로 여유가 사라지고 오히려 성급하게 나쁜 결정을 내릴때가 더 많아졌다.

모든 것을 파악하는 것을 어렵다는 것을 인정하고, 영향 범위와 문제 해결 난이도, 설계의 복잡함 등을 나름의 기준으로 내 시간을 어떤 프로젝트에 투자할지 선택과 집중을 하기로 했다.

고민의 시간이 길어지고 각 도메인 지식을 깊게 이해하는 과정이 반복되면서 오히려 트라이브 전반적인 여러 맥락을 더 쉽게 파악할 수 있게 되었다.

함께하는 동료들을 믿는 것

팀에서 시니어 레벨을 담당하고 있는 디자이너들은 대부분 구현 지식을 바탕으로 시스템적인 사고를 하는 사람들이었고, 무의식적으로 디자이너로서 성장 방향을 이 방향으로 정해두었던 것 같다.

그렇다보니 자연스럽게 함께 하는 디자이너들에게도 시스템적인 사고와 구현 지식을 꽤 많이 요구하는 피드백을 주었다.

또한 각 디자이너들만의 강점이 있더라도 그 기반은 시스템적인 사고를 해야만 의미가 있다고 생각했다. 그러다보니 시스템적인 설계 역량을 보여주지 못한 동료 디자이너들의 디자인 방향성 결정을 신뢰할 수 없다고 여겼다.

하지만 모든 것을 챙길 수 없다는 것을 솔직하게 인정한 이후로 디자이너들의 이전 프로젝트 결정 히스토리, 고민의 깊이와 다양한 시도들을 보고, 내가 기여하지 않았는데 오히려 더 좋은 성과를 보여주는 디자이너들을 보면서 각자만의 강점은 분명히 있고, 그것이 반드시 특정한 역량이 뒷받침 되어야하는게 아니다라는 것을 알게되었다.

디자이너들의 강점을 서로 파악하고, 각자가 고민하고 내린 결정을 신뢰하게 되면서 오히려 이전보다 서로 주도적으로 이야기하고 부족함을 채워주면서 더 많은 시너지가 발생할 수 있게 되었다.

마무리

6개월간 많은 일이 있었다. 내가 디자이너들에게 도움을 주기 위해서 노력했지만, 오히려 디자이너들과 함께 일하면서 더 많은 것을 배웠던 것 같다. 팀에서는 명확하게 시니어 디자이너로서 내 업무 성과에 대한 평가를 하지 않겠지만. 객관적으로 내가 잘 했다고 이야기할 수 있을까? 혹은 우리 트라이브 동료들, 디자이너들에게 내가 좋은 영향을 주었을까? 부디 내가 노력한 6개월이 함께 고생한 동료들에게 의미있는 도움이 되었다면 좋겠다…!