brunch

You can make anything
by writing

C.S.Lewis

by 엘비 May 25. 2020

인터뷰를 실패로 이끈 가설 세 가지

프로덕트 디자이너의 해외 취업 포트폴리오 리뷰 인터뷰

싱가포르에서 런던으로 이주해 근무하게 된지는 이제 고작 4개월차이지만, 한국을 떠나 해외에서 디자이너로 근무한지는 벌써 4년이 넘어가고 있다. 수많은 날 동안 여러 회사들의 인터뷰를 준비하면서 크게 도움을 받았던 해외 디자이너 분들의 경험을 담은 좋은 글들이 많아서, 나도 경험을 통해 한 꼭지 적어 보답해야겠다 다짐을 했었지만 많이 늦었다. 벌써 입사 4개월 차라니..

인터뷰 과정은 회사마다 다양하지만 포트폴리오 리뷰 인터뷰는 어디나 포함되므로, 그를 위주로 몇 자 남겨놓고자 한다. 언제고든 다시 만나게 될 인터뷰라는 순간은 이렇게 기록해두지 않으면 또다시 원점으로 돌아가 같은 실패를 반복하게 될까 두렵기도 하고.. 인터넷에 보면 포트폴리오를 어떤 구조로 준비해야 하는지는 이미 공유되어있는 많은 정보가 있기에 포트폴리오 자체 준비에 관하여는 생략하고, 어떤 가설을 세워 포트폴리오를 준비해서 들고 갔다가 인터뷰에 실패했었는지를 기록해두고자 한다.

나의 가설 1

인터뷰 시 인터뷰어의 사전 포트폴리오 리뷰는 당연하다

인터뷰를 들어갔는데, 인터뷰하겠다고 들어온 사람이 제 포트폴리오를 처음 보는 사람 같은 거예요. 어떻게 그런 기본적인 것을 질문할 수가 있죠? 사전에 보낸 포트폴리오에 이미 다 명시해 놓은 부분을 계속 질문해서 너무 시간을 잡아먹었어요. 덕분에 큰 그림을 다 설명하지 못했어요. 이렇게 지원자에게 관심이 없는 회사라면 들어가도 별로 배울 것이 없지 않을까요?

지원자로서는 사실 당연히 할 수밖에 없는 질문이 아닐까. 우리가 포트폴리오에 쏟는 정성과 시간이 과연 돈으로 환산이 가능키나 한 것인가? 나를 갈아 넣고 피땀을 넣어 완성한 것인데.. 머리를 쥐어뜯으며 잘 되지도 않는 영어로 하나하나 번역하며 뜬눈으로 지새운 밤이 도대체 셀 수나 있으려나. 그렇게 준비하고 들어간 인터뷰에 인터뷰어가 너무나 당연하게 명시되어있는 부분을 질문하면 울화가 치밀어 오르는 게 당연하다고 생각했다. 날 맘에 든다 하며 인터뷰에 초대했으면서 내 포트폴리오를 한 번도 안 열어봤다고? Are you serious?

분명 회사마다 다른 문제겠지만 단도직입적으로 얘기하면, 이런 생각은 나의 큰 오산이었다. 서류를 검토해서 통과시키는 사람과 인터뷰에 들어오는 사람이 언제나 일치하지 않기 때문이다. 인터뷰어가 인터뷰이의 정보를 꼼꼼히 검토하고 들어오는 경우는 안타깝지만 큰 회사일수록 극히 드물다. 그도 그럴 것이, 큰 회사의 인터뷰어일수록 여러 가지 프로젝트를 병행 진행하면서 인터뷰, 그것도 하루에 진행되는 여러 건 중 하나에 참여하는 경우가 많은 까닭이다. 이렇게 바쁜 상황에서 더더욱 인터뷰 참가자의 사전 정보 및 포트폴리오까지 모두 병행하여 숙지한 후 인터뷰에 임하는 것은 거의 불가능해 보인다. 대부분 인터뷰 이전에 정보를 전달받기는 하겠지만 글씨 토시 하나하나를 꼼꼼하게 읽어보고 인터뷰에 참가하여 그 내용을 토대로 질문을 할 것이라는 것은 인터뷰에 대한 환상이다.

포트폴리오에 기술했던 모든 내용을 처음 접하는 사람을 상대로 인터뷰를 준비했을 때와, 그렇지 않았을 때를 내 경험에 비추어 비교해보면, 발표 시 상대방이 하는 질문의 퀄리티가 극명하게 갈려서 전체 인터뷰의 경험 자체가 굉장히 달랐다. 특히나 시간제한이 있는 특수상황인 인터뷰라는 환경에서는 보여줄 수 있는 것에 한계가 있기 때문에, 꼭 고려해야 하는 부분이다.

따라서 이 가설은 오류였다.

나의 가설 2

내 포트폴리오는 내가 들려주고 싶은 나에 관한, 내 작업에 관한 이야기다

일단 이건 다시 봐도 너무나 당연해 보이는 가설이다.

종종 리뷰를 부탁받은 포트폴리오에 상당히 구체적이고 자세한 내용을 스토리텔링 기법으로 모두 설명해 놓은 분들을 많이 본다. 내 이직 준비 중 초기의 포트폴리오도 그랬다. 변을 하자면, 그렇게나 자세히 기술해서 보여주는 이유는 하나의 유저 문제를 풀기 위해 상당히 많은 프로세스를 거칠 수밖에 없는 경우가 대부분이기 때문이다. 어느 하나 설명하지 않기에는 스토리가 이어지지 않을뿐더러 내가 할 수 있는 부분을 다 보여주지 못하는 것 같고, 설명을 다 하자니 너무 길어지고.. 이런 경우 대부분 후자를 선택해서 구구절절 다 설명해 놓는 방법을 선택한다. 길지만, 내가 할 수 있는 부분을 모두 보여줄 수 있으니까. 영어로 길게 잘 정리된 포트폴리오를 보면 내심 뿌듯하기까지 하다. 보통 이런 경우에는, 어차피 너무 길면 보는 사람들이 스킵해서 보겠지? 하는 준비자의 기대감이 일조하는 듯하다. 나한테 관심 있는 사람이라면 내가 들려주고 싶어 하는 이야기를 끝까지 읽어줄 테니까.

하지만 정작 중요한 건 포트폴리오를 리뷰하는 인터뷰를 준비할 땐, 제한된 시간 동안 디자이너로서의 나라는 사람에 대해, 그리고 내가 이제까지 했던 일들을 어떻게 효과적으로 설명할 수 있을까를 고민하여야 한다는 것이다. 그것도 나와 내 프로젝트를 한 번도 접하지 못한 처음 보는 사람에게 말이다. 사실 생각해보면, 이건 우리가 늘 하는 일이다. 물론 그 상대는 인터뷰어가 아니라 유저이지만. 제한된 시간이 30분인데 내가 열정적으로 이 프로젝트에 참여했던 그 시절을 떠올리며 경험했던 모든 리서치 스텝에 관해 상세히 읊어준다면, 그 인터뷰어는 인터뷰 시작 초반부터 이미 마음속에 답을 정해두었을 가능성이 많다. 도입부부터 재미없는 영상을 집중해서 끝까지 지켜보는 사람이 얼마나 될까?

바꿔 생각하면 인터뷰에 참여하는 사람들은 내 포트폴리오를 사용하는 유저들이다. 이 사람들을 어떻게 하면 내 포트폴리오에 집중시켜 나의 이야기를 지루해하지 않고 즐기도록 유도할 수 있을지를 고민해 보아야 한다. 그렇다면 내가 하고 싶은 이야기를 하기보다, 그들이 듣고 싶어 하는 이야기를 들려주는 것이 중요해 보인다.

따라서 이 가설도 오류였다.

나의 가설 3

과정은 결과보다 중요하다

처음에는 포트폴리오는 결과보다 과정이 훨씬 부각되어 보여야 한다는 생각을 했다. 작업물은 보통 결과만이 남기에 그 과정을 다 기록해서 보여주는 것이 중요하지 않은가? 그렇게 때문에 이렇게 우리가 오랜 시간 과거의 자료들을 모으고 순서대로 정리하는 작업에 최선을 다하는 것이다. 내가 이 작업을 shipping 한 후의 결과보다는, 내가 했던 유저 리서치와 유저 테스트, 그 과정에서의 디자인 이터레이션 등을 강조해야 한다고 생각했다. 근데 결국 이것 또한 나의 불찰이었다는 것을 깨달았다.

한국말은 끝까지 들어야 된다 라는 말이 별개로 존재하듯 한국 문화에 익숙한 우리들은 꼭 중요한 이야기를 나중에 꺼내는 것을 좋아한다. 그 결과가 어떻게 나왔는지보다 그 과정을 장황하게 설명하는 것도 매우 좋아한다. 근데 영어는 조금 다르다. 주어 다음에 바로 동사가 나와버린다. 부연 설명 수식어는 그 뒤에 붙고. 그렇게 문화가 다르다 보니 우리나라 식으로 영어로 바꾸어 상대방에게 장황하게 설명을 하게 되면, 상대방이 나의 의도를 잘 못 이해하는 경우도 있고, 집중력을 잃고 결국 네가 무슨 얘기를 하고 싶은 건지 모르겠다는 반응을 보일 때도 있다. 다 알겠는데 그래서 어떻게 됐다고? 라고 물으며 말이다.

포트폴리오를 어떻게 잘 만들어야 할지에 관한 여러 글들을 읽어보면 어떻게 과정을 잘 나열해야 효과적인지를 강조하고 있다. 그래서인지 리뷰를 부탁받은 몇몇 포트폴리오들을 보면 과정을 지나치게 강조해놓은 것들이 많다. 대부분 과정 뒤에 결과를 나열하는데, 과정이 너무 강조된 나머지 결과가 뭔지 모르게 과정과 희석되어있는 것들을 종종 보게 된다. 과정이 그만큼 중요하다는 건 내가 이러한 결과를 내기까지를 보여주기 위한 뒷받침으로서 중요하다는 것이지, 결과를 가리도록 강조가 되어야 한다는 것은 아니다. 여러 포트폴리오를 리뷰하면서, 실력 있는 친구들이 이렇게 포트폴리오를 만들어 놓은 것을 꽤 봤다. 그래서 어떤 유저 문제를 이 친구가 결국 어떻게 해결해주었다는 것이지? 가 짧은 시간 동안 파악되지 않으면, 평가자들은 길을 잃을 수밖에 없다. 이걸 인터뷰에서 영어로 우왕좌왕 설명하다 보면 나 스스로 길을 잃는 경우까지도 발생한다.

프로덕트 디자이너의 포트폴리오는 내가 무슨 일을 했는지 그저 쭉 나열해서 보여주는 용도로 쓰이지 않아야 한다. 내가 A라는 유저의 문제를 어떻게 해결하였는지, 해결하기 위해 어떤 다양한 시도를 하였는지 명료하게 보여주는 용도로 사용되어야 마땅하다. 내가 무엇을 할 수 있는지, 어떤 일을 했는지 나열하는 것은 resume에 하는 것으로도 충분하다. 프로덕트 디자이너의 프로젝트의 시작점은 언제나 User problem 이므로, 이것이 해결되었는지, 해결되지 않았다면 왜 그러지 못했는지 유저 데이터를 토대로 탄탄하게 설명해주어야 한다.

따라서 이 가설도 반은 맞고, 반은 틀렸다.