사수 없는 디자이너는 어떻게 성장해야 할까?

“사수가 없는데 가도 될까요?” 절박하다면 가릴 거 없이 다 하겠지만, 아무리 절박하더라도 온 우주와 내 촉이 말리는 것들이 있다. 사수가 없는 곳에 디자이너로 입사하는 것이 그중 하나일 것이다.

디자이너가 나 혼자인데 성장할 수 있을까요? 대표님이 디자인을 잘 모르는데 괜찮을까요? 개발자와 기획자뿐인 팀에서 배울 수 있을까요? 등 각종 기출 변형이 많지만, 핵심은 ‘그 이후의 내 디자이너 인생이 막혀버리면 어떡하지’라는 걱정이라는 점에서는 같다.

물론 질문한 사람의 절박함을 모르는 건 아니다. 하도 첫 직장이 중요하다고 하니 걱정될 것이다. 돈과 경험이 급하다고 덜컥 입사하면 앞으로의 커리어를 망치지는 않을지, 나 혼자 하느라 잘못된 습관만 배우고 몇 년을 허비하지는 않을지 말이다. 요즘처럼 한 번의 이직도 쉽지 않은 시장이라면 더 그렇다.

그런데 이 질문에 ‘사수가 없으면 가지 마세요’ 혹은 ‘혼자서도 충분히 성장할 수 있어요’라고 둘 중 하나를 골라 답할 수 없다. 현실은 그보다 따질 것들이 더 많다. 심지어 그렇게 이분법적으로 가냐 마냐를 따질 수도 없다. 사수가 없다는 사실 하나만으로 좋은 회사와 나쁜 회사를 가를 수 없기 때문이다.

사수가 있어도 홀로 방치되거나 사수가 오히려 악영향을 주는 회사가 있고, 디자인 팀도 없고 사수가 없어도 날카롭고 영양가 높은 프로덕트 피드백을 주고받는 곳도 있다. 반대로 모두가 친절하고 칭찬도 잘해주는데, 정작 어떤 디자인이 왜 나은지 설명을 못 하니 내가 이대로 타성에 젖어버리는 건 아닌지 걱정되는 조직도 있다. 그래서 이 글에서는 사수 없이 시작한 내 경험을 바탕으로, ‘사수가 없다’는 말을 어떻게 뜯어봐야 하는지와 혼자서도 성장 구조를 만드는 방법, 그래도 떠나야 하는 회사의 조건을 차례로 살펴본다.

나의 첫 사수는 한 달 만에 떠났다

내 첫 사수는 비전공자인 내가 인턴 6개월을 마치고 정규직이 된 지 한 달 만에 회사를 떠났다. 그래서 사실상 중소회사의 1인 디자이너로 시작했다.

내가 스스로의 사수가 되어 잘 성장했다고는 하지만, ‘내가 내 사수가 되어줬다’는 건 지금에서야 할 수 있는 생각이다. 그때는 당황스러웠고, 여기서 계속 이런 작업만 하다가 경력이 끝나면 어떡하지 하는 고민을 항상 했다. 나 혼자서 어떻게든 버티고 살아남아야 하니, 닥치는 대로 뭐든 다 배워봤다. 다 따라해보고, 다 읽어보고, 사람들과 계속 어울리려고 했다. 그때 처음으로 페이스북에서 디자이너 그룹에 참가했고, 메신저를 통해 디자이너 모임 단체방에 들어갔던 것 같다.

초반에는 이 방식이 꽤 나쁘진 않았다. 작은 조직에서 홀로 일하는 디자이너에게는 디자인 전문성 자체보다는 빠른 손과 눈썰미, 얕더라도 적당히 넓은 시야와 이것저것 다 70% 정도는 가능한 업무 역량이 오히려 더 효과적이었다. 그게 회사 입장에서도 더 유용한 포지션이 된다. 전체적인 사업 역량을 다 키워야 하는 부실한 초기 조직에서 새는 곳곳을 틀어막으면서 전문가가 올 때까지 버텨줄 수 있는 제너럴리스트는 매우 소중한 자원이기 때문이다.

그때 필요한 ‘이것저것’을 스스로 찾아 배우며 해결했다. 사수가 없다는 사실은 다시 말해 내가 디자인 결정권을 가지고 있다는 뜻이니, 오히려 빠르게 영역을 넓히는 계기가 되기도 했다. 기획도 들여다보고, 외주 개발사에서 왜 안 된다고 하는지도 물어보고, 운영에서 반복되는 문제도 직접 개선해보려고 노력했다. 덕분에 혼자 해결할 수 있는 범위가 넓어졌다. 지금 돌아보면 그때 어떻게 해서라도 나 스스로를 증명하고 싶었던 것 같고, 그때로 다시 돌아가더라도 똑같이 할 것 같다.

다만 경력이 쌓일수록 혼자 배우는 방식에는 분명한 한계가 생겼다. 계속 내가 이미 알고 있는 방식 안에서만 문제를 해결해보려고 했고, 연차가 쌓이면서 넓은 커버리지보다는 더 날카롭게 벼려진 직무 전문성을 요구하는 곳들이 늘어갔다. 시니어의 더 높은 디자인 기준을 직접 본 경험이 부족하니 무엇을 놓치고 있는지도 알기 어려웠다.

그렇다고 그 당시부터 이런 한계를 또렷하게 알고 있었던 건 아니고, 그저 혼자서도 어떻게든 되겠지 하는 마음으로 버텼던 게 더 컸던 것 같다. 데이터로 디자인을 검증하는 환경이 필요하다는 사실을 절감한 건 훨씬 뒤의 일이고, 그 결핍은 여전히 존재하는 것 같다. 데이터로 디자인을 개선한다는 경험을 줄 수 있는 회사가 많지 않다 보니 이직 과정에서 관련 경험이 부족하다는 판단이 자주 들었다. 그러다 보니 직접 개인 프로젝트를 진행해보면서 회사가 주지 못한 경험을 보완해보고 있다. 당시의 나는 부족한 피드백을 다른 구조적인 방법으로 채워야 한다는 생각은커녕, 그런 방법이 필요하다는 사실조차 모르고 그저 닥치는 대로 뭐라도 다 하면서 버티던 사람에 더 가까웠다.

사수는 사람이 아니라 기능이다

우리는 흔히 사수를 한 사람으로 생각한다. 내 작업을 봐주고, 틀린 부분을 알려주고, 다음에 무엇을 공부해야 할지 말해주는 연차 높은 디자이너 말이다. 물론 상위 조직에서 부당한 업무가 내려오면 막아주는 든든한 조력자이자 방패일 수도 있다. 그런 사람이 있다면 당연히 좋다. 시행착오를 줄여주고, 조직 안에서 통하는 기준을 빠르게 배우게 하며, 내가 보지 못한 문제를 먼저 발견해준다. 다만 사수라는 사람에게 기대하는 것을 뜯어보면 사실 여러 역할이 섞여 있다. 우리가 사수가 필요하다고 하는 건 이런 역할을 해줄 수 있는 사람이 필요하단 뜻일 거다.

• 첫째, 내가 만들어야 하는 디자인의 품질 기준이 되어주는 일이다.
• 둘째, 내가 만든 디자인의 근거를 확인하는 일이다.
• 셋째, 조직이 어떤 맥락으로 일하는지 연결해주는 일이다.
• 넷째, 지금 내가 부담 없이 해볼 수 있는 일의 범위를 알려주는 일이다.
• 다섯째, 실제로 내 역량 이상의 일을 주면서 나를 조금씩 더 성장시키는 일이다.

이 다섯 가지 역할이 한 명에게 모두 들어 있으면 훌륭한 사수다. 물론 현실에서 이 모든 역량을 갖춘 사수는 유니콘이다.

그래서 사수가 없는 환경에서 가장 먼저 할 일은 없는 사수의 빈자리를 정신력으로 버티는 게 아니다. 내가 사수에게 가장 필요로 하는 역할이 무엇인지 나 스스로에게 묻는 일이다. 내가 사수가 필요하다고 느끼는 이유가 디자인 기준이 없어서인지, 내 디자인을 반박하거나 피드백해 줄 사람이 없어서인지, 윗선의 알력을 막아주거나 디자인 조직의 목소리를 내줄 사람이 필요해서인지, 더 어려운 문제를 풀어보고 싶은데 도무지 나 혼자서는 진행할 자신이 없어서인지를 구분해야 한다. ‘사수가 없어요’라고 한 덩어리로 말하면, 해결책 역시 ‘사수 있는 곳으로 이직하세요’와 ‘전 혼자서도 할 만 했어요’ 사이에서 방황한다.

혼자 일해도 괜찮아지는 법

물론 사수가 있다면 단점보다는 장점이 더 많을 수 있다. 아무리 별로인 사수여도 일단 혼자 일하지 않아도 된다는 안심이 생긴다. 하지만 우후죽순처럼 스타트업이 생겨나는 요즘 시대에 2인 이상의 디자인 조직을 꾸릴 수 있는 회사는 많지 않다. 앞서 말했듯 초기 단계의 중소회사에서 여러 업무 영역을 동시에 견인하려면, 디자인 앞뒤의 일까지 오너십을 가지고 최소한 펑크가 나지 않게 버텨줄 수 있는 제너럴리스트 디자이너 1인으로 가는 경우가 너무 많다.

그럼 내게 사수가 필요한 이유를 찾았다면, 천천히 해결해보자. 디자인을 할 때 어떤 기준으로 결과물을 만들어야 하는지 모르겠다면, 지금부터라도 내가 왜 이렇게 디자인했는지를 기록해놓는 것이 필요하다. 처음엔 별거 없지만, 이후에는 내가 어떤 디자인을 하더라도 이전에 어떤 기준으로 판단을 내렸는지를 참고할 수 있다. 과거의 내가 현재의 나에게 사수가 되어 주는 셈이다.

이번 작업에서 어떤 디자인을 하기로 했는지, 왜 그렇게 했는지, 하면서 다른 부서나 임원진, 결정권자의 의견은 어떤 게 있었는지를 적는다. 작업을 마무리하고 나면, 처음과 실제 결과물이 어떻게 달라졌는지 그 이유도 남긴다. 거창할 필요도 없고, ‘가입 항목이 많아서 이탈한다고 봤는데 테스트해보니 항목 수보다 개인정보 동의를 왜 받는지 이해하지 못한 것이 문제였다’ 정도면 충분하다.

디자인을 할 때도 비교 대상을 의도적으로 만들어야 한다. 레퍼런스를 예쁘다거나 나중에 이렇게 해봐야지 하는 마음으로 무작정 저장하지 말고, 이 서비스가 왜 이 순서로 정보를 놓았는지, 우리 서비스에서는 무엇이 달라져야 하는지 적어본다. 같은 문제를 두 가지 안으로 만들어 회사 사람들에게 보여준다. 이때 ‘어느 쪽이 나으세요?’, ‘어떤 게 더 좋으세요?’처럼 취향을 묻는 게 아니라, 어떤 상황과 조건이 있을 때 어느 시안이 더 나은지, 이유는 뭔지 묻는다. 취향을 묻는 자리가 되지 않도록 하는 것이 매우 중요하다. 사수가 없다고 피드백까지 없는 것은 아니다. 피드백처럼 보이지 않던 재료를 내가 피드백으로 바꾸지 않았을 뿐일 수 있다.

데이터를 쓰고 있는 회사라면 내가 할 수 있는 한 작은 실험을 만드는 것도 중요하다. 시행착오가 비싸다는 말은 맞다. 그렇다고 모든 결정을 누군가가 해봤던 것에만 의존해서 그대로 따라간다면 실패 비용은 줄어들지 몰라도 이다음에 내가 직접 판단하는 능력도 함께 사라진다. 되돌리기 어려운 결제 구조나 개인정보 정책을 혼자 시험하라는 뜻이 아니다. 버튼 문구 두 개, 문구 순서 두 가지처럼 간단한 것부터 비교하면 된다. 혼자 실험하고 분석하는 게 두려워 큰 실패를 피하려고 작은 실패까지 기피해버린다면, 결국 실전에서는 아무리 작은 판단도 가장 비싸고 치명적인 실패가 될 수밖에 없다.

커뮤니티는 대리 결정 서비스가 아니다

사수가 없을수록 커뮤니티를 찾게 된다. 문제는 질문의 형태다. ‘이렇게 해도 될까요?’, ‘보통 몇 장 넣나요?’, ‘이 회사 괜찮나요?’라고 물으면, 답하는 사람은 질문자의 조건을 거의 모른 채 자기 경험의 평균을 말하게 된다. 평균은 좋다. 적당히 얼버무리기 좋고, 적당히 무난하게 가기 좋다. 그런데 평균의 함정이 있다. 0과 100이라는 극단적인 상황에서도 평균은 50이 나온다. 회사마다 상황이 모두 다를 텐데, 단편적인 상황 하나만 놓고 누군가의 평균을 가져오려는 건 너무나 위험하다.

예를 들어 ‘포트폴리오는 한 프로젝트당 10장이 좋더라’라는 답을 들으면 왜 10장인지 이유를 파악하는 게 더 중요한데, 대부분은 ‘아 10장으로 해야 하는구나’라고만 생각하고 말아버린다. 10장이 넘으면? 안 넘으면? 그러면 또 커뮤니티에 질문하기 시작한다. 10장이 넘는데 줄여야 하냐, 10장이 안 되는데 어떻게 하냐 등 어느새 10장은 이유가 아니라 법칙이 된다. 원래는 ‘프로젝트를 전개하면서 흡인력을 만들고 설계 논리와 스토리를 정리하다 보면 그 정도 분량이 얼추 나온다’라는 맥락이 있었겠지만, 10장이라는 숫자만 남는다.

커뮤니티에 좋은 질문을 하기 위해선 나 스스로 어떻게 시도했는지 흔적이 있어야 한다. 내 상황은 무엇이고, 비슷한 사례를 어디까지 찾아봤고, 무엇을 직접 해봤는데 이런 부분에서 막혔다는 구체적인 맥락과 실패 경험이 필요하다. 질문도 ‘어떻게 해야 하나요?’가 아니라 ‘저는 이런 이유로 A가 낫다고 보는데 놓친 조건이나 반례가 있을까요?’라고 묻는다. 이 정도가 되어야 커뮤니티에 모여 있는 사람들의 집단지성을 제대로 활용할 수 있다. 마지막 판단까지 남에게 맡기지는 말아야 한다.

질문을 많이 하는 것이 수동적이라는 뜻은 절대 아니다. 제대로 조사하고 시행착오를 줄이기 위해 다른 사람들의 사례를 묻는 일은 필요하다. 하지만 사례를 모으는 것과 선택하는 책임을 넘기는 것은 다르다. 전자는 내 가설이나 의견을 더 단단하고 풍부하게 만들지만, 후자는 골라온 답이 틀렸을 때 다시 혼란에 빠지게 한다. 사수에게 물어보든 커뮤니티에 묻든, 답변을 듣고 ‘그래서 나는 어떻게 하겠다’까지 이어지지 않는다면 배운 것은 거의 없다.

그럼에도 떠나야 하는 회사는 있다

그렇다고 사수 없는 환경을 무조건 견디라는 이야기는 아니다. 성장 환경을 내가 아무리 만들더라도, 조직 차원에서 그 환경을 지원할 수 없는 곳이 있다. 스스로 성장 환경을 만들라는 말만으로 회사가 져야 할 책임까지 내가 질 순 없다.

데이터 수집은커녕 사용자와 만나는 채널도 없고, 동료에게 이유를 물어도 ‘대표님이 이게 좋다던데요’로 끝나는 회사가 있다. 성과가 안 나면 이 팀 잘못이네 저 팀 잘못이네 떠넘기기만 하고, 왜 실패했는지 무엇이 문제였는지 조직 차원에서 전략을 다시 짤 생각이 없다. 일정은 늘 촉박한데 더 나은 방법을 시험할 여지는 없고, 디자인 외 업무는 끝없이 나한테 떨어지지만 정작 디자인을 제대로 해볼 권한은 주지 않는 곳도 있다. 이런 환경에서는 혼자 아무리 시도하더라도 금방 의욕이 떨어진다.

참 어려운 건, 디자인 외의 일을 한다는 이유만으로 ‘아 여긴 디자이너를 존중하지 않아’라고 생각하면서 성장할 수 없는 회사라고 단정할 수도 없다는 것이다. 디자이너가 기획을 들여다보고, 운영에서 생기는 문제를 확인하고, 개발 제약을 이해하면 디자인을 못하게 되는 게 아니라, 오히려 디자인을 더 잘할 수 있는 판단 재료가 늘어나는 경우가 많기 때문이다. 물론 디자이너에게 영수증 처리 업무를 맡긴다거나 마케팅 전반을 다 떠넘기는 건 다른 이야기다. 다만 그 선을 구분하는 기준도 실제 일을 겪으면서 내가 얻는 것과 잃는 것이 뭔지 알려고 해야 보인다. 아는 만큼 보이지만, 역설적으로 경험하지 않으면 내가 무엇을 모르는지도 잘 보이지 않는다.

떠나야 할 시점은 ‘사수가 없어서’보다 ‘배울 수 있는 피드백 과정을 만들 방법이 없어서’에 가까운 것 같다. 내가 성장할 수 있다는 자신이 있고 회사가 그런 환경이 된다면 사수가 없어도 꽤나 다닐 만했다. 실제로도 회사가 돈을 벌어오는 과정에 대해 이해하기도 했고, 디자인을 하려면 앞에서 어떤 일들이 더 생겨야 하는지, 뒤에서 내 디자인이 어떻게 쓰이는지 알 수도 있었다. 즉, 어떤 게 풀어야 할 문제인지 내가 알 방법이 없고, 다른 직군의 관점에도 접근할 수 없고, 시도가 계속 막히며, 같은 수준의 일만 반복된다면 환경을 바꿔 볼 때다. 반대로 완벽한 사수는 없어도 질문할 동료가 있고, 내가 한 일의 결과를 확인할 수 있고, 내가 하는 만큼 책임 범위가 조금씩 넓어진다면 배울 것은 남아 있다. 이직 여부도 결국 사수의 유무가 아니라 성장 구조의 유무로 판단해야 한다.

마치며: 좋은 사수를 기다리는 동안 해야 할 것

사수가 없는 것은 분명 위험하다. 특히 첫 커리어라면 잘못된 기준을 스스로 알아채기 어렵고, 남들보다 먼 길을 돌아갈 수도 있다. 하지만 사수가 있다고 성장이 자동으로 시작되는 것도 아니다. 좋은 선배의 말을 또 하나의 정해진 답으로만 소비한다면 옆에 최고의 사수가 있어도 판단력은 자라지 않는다. 반대로 내 가설을 기록하고, 다른 직군과 사용자에게서 피드백을 모으고, 작은 실험으로 확인하며, 구체적인 질문으로 외부 커뮤니티의 도움을 받을 수 있다면 사수의 기능을 여러 곳에 나눠 만들 수 있다.

결국 사수 없는 디자이너에게 필요한 건 혼자서 다 해내겠다는 독기가 아니다. 나를 계속 틀리게 만들고, 틀린 걸 확인하고, 다음에는 조금 덜 실패해보는 걸 고를 수 있는 구조다. 좋은 사수를 만나는 건 운이지만, 피드백을 구하는 방식과 배운 것을 다음 행동으로 옮기는 일까지 운에 맡길 필요는 없다. 사수나 누군가가 마냥 끌어주기를 기다리며 성장에 투자하지 않으려는 사람과, 사수가 없어도 내 흔적이 나를 다시 키우게끔 시간을 쓰는 사람의 차이는 연차가 갈수록 커진다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.