이력서를 읽긴 읽은 걸까요?

유남주(가명)님은 갓 대학을 졸업한 취업준비생인 프론트엔드 개발자입니다. 쾌활하고 소통에 적극성이 전해지는 개성을 갖고 있습니다. 이력서는 깔끔하고 보기 좋아서 좋은 인상을 남기는데 반해, 내용은 너무 무난해서 이력서 작성자를 파악하기 어려웠습니다.

하도 서류 전형에서 탈락해서 어느 시점부터는 탈락 피드백을 요청했다고 합니다. 대부분 답신이 없는 와중에 받은 피드백을 모두 읽은 유남주님은 당혹스러웠다고 합니다. 피드백 대부분은 채용담당자가 자신의 이력서를 제대로 읽었는지 확신이 안 설 정도로 엉뚱한 사람으로 자신을 인식했기 때문이죠. 처음엔 어떤 역량이 부족하다고 하면 그걸 공부할 요량이었는데, 갑자기 이력서를 고칠 방향을 잃었다고 하네요.

채용담당자들은 유남주님의 이력서를 제대로 봤을 거예요. 저라도 그들이 느낀 인상을 받았거든요. 과감하게 요약하면 유남주님의 이력서는 이렇습니다.

주제 : 주도적으로 문제를 해결하는 개발자.

프로젝트 1

프로젝트 2

아이고. 좀 덜 요약할 걸 그랬나. 이렇게 건조할리 없다며 울상을 짓네요. 감정선이 직선을 그리는 제겐 감정 풍부한 사람의 시시각각 변하는 감정을 따라잡기 버겁습니다. 어쨌든, 자, 멘토링을 시작합니다.

주도적으로 문제를 해결하는 개발자라는 주제를 보니 여러가지 궁금증이 일어납니다. 유남주님이 말하는 주도성은 어떻게 생각하고 행동하는 걸까요? 유남주님이 봤을 때 어떤 사람이 어떻게 행동하면 주도적이라고 생각하는지 물었습니다. 문제를 해결하려고 노력하는 것이라고 대답하다가 동어반복이라는 걸 깨닫고는 다시 고민합니다. 뭔가 생각나는 건 있는데 말로 잘 설명이 안 되는지 말을 하려다 말고 하려다 마네요. 자연스러운 모습입니다. 우리는 자신이 명확하고 구체적으로 생각하고 있다고 생각하지만, 막상 말이나 글로 설명하려고 하면 명확하지도 구체적이지도 않다는 걸 그제서야 깨닫지요.

“스스로 나서서 문제가 시작된 본질을 찾아내려고 도전하는 것. 그게 제가 생각하는 문제 해결을 위한 주도성이예요.”

좋네요. 유남주님은 주도적인 사람이 되려고 고민을 해온 게 분명합니다. 다음 궁금증으로 넘어가도 되겠어요. 가용 가능한 자원이 한정된 상황에서 해결하려는 문제가 많아서 우선순위를 매긴다면 가장 우선순위가 높은 문제는 어떤 종류인지 물어봤습니다. 머리는 엔지니어링 문제라 말하고 싶지만, 발생했을 때 가장 마음을 불편하게 하는 건 사용자에게 발생한 문제라는 대답이 인상적입니다.

“종합하면, 사용자가 겪는 문제를 스스로 나서서 문제의 본질과 원인을 찾아내고, 그 문제를 해결하는 개발자라는 거군요”

“음. 맞아요. 근데 사용자가 겪는 문제 뿐만 아니라 다른 문제도 포함해요”

“그렇죠. 해결하지 못할 때도 있고, 사용자의 문제를 해결하는 것과 무관한 리팩터링을 고민할 때도 있을 거예요. 그렇죠?”

“아... 무슨 말씀하시는지 알겠어요. 그런 행동 중 저를 움직이게 하는 힘이 가장 강한 동인을 하나 정해서 집중해야 한다는 거군요”

“훌륭합니다. 주제 문구는 나중에 다듬기로 하고, 오늘 커피챗에서는 이 주제를 중심으로 놓고 이력서를 살펴봅시다”

이력서에 첫 번째로 배치된 프로젝트는 대학 출석을 관리하는 팀 프로젝트입니다. 3인이 1개월만에 만들었으며, 출시해서 실제 사용자도 있습니다. 이 프로젝트에서 유남주님은 기획에 적극 참여하여 사용자 만족에 기여했다는 걸 소구하고 싶어했습니다. 이유를 묻자 개발 측면에서는 구현이 간단하여 기술적으로 눈길을 끌기 어렵기 때문이라 합니다. 의도는 좋습니다. 신입과 주니어가 개발하는 포트플리오는 대개 기술적으로 까다로운 구현을 하는 경우는 많지 않거든요. 프로젝트나 기술 역량을 호소하는 건 변별력이 떨어집니다.

의도는 좋지만, 지금처럼 개발자가 기획 참여를 호소하는 건 아무래도 오해나 편견을 살 것 같아요. 왜 기획에 참여했는지 설명을 해야 하지요. 다시 말해 개발자로서 개발에 어떤 영향을 미치게 하려고 기획에 참여했는지 설명이 되어야 합니다. 유남주님의 경우, 기획에 참여하는 것은 왜(Why)가 아니라 어떻게(How)에 해당하거든요.

“생각해보니 제가 기획에 참여하는 게 특별하진 않네요. 프로젝트에 참여하는 사람이라면 누구든 기획에 참여하거나 기여하는 게 당연한 건데...”

왜 기획에 참여했냐는 질문에 잠시 생각하더니 다소 시무룩해지며 답합니다.

“당연하진 않아요. 설령 당연하더라도 유남주님이 참여하는 동인과 다른 사람이 참여하는 동인은 다를 거예요. 유남주님은 기획에 누구든 참여하거나 기여하는 것이 왜 당연하다고 생각하세요?”

“기획, UX/UI 디자인, 개발 모두 사용자가 사용할 제품을 만들잖아요. 각자가 자기 기술로 제품을 만드는 거죠.”

“이 프로젝트에서 남주님이 기획에 참여하던 상황은 어떤 상황이었어요? 기획자가 없었어요? 아니면 팀원 모두가 기획에 참여해야 하는 상황이었나요?”

“UX/UI 디자인, 백엔드, 프론트엔드 이렇게 세 명이어서 기획자는 없었어요. UX/UI 디자이너가 주로 기획 관련 작업을 했고요. 그런데 그 당시에 디자이너가 첫 화면을 디자인하는 걸 까다로워했어요. 기획이 늦어지면 개발도 늦어지는데, 디자이너와 협업을 많이 하는 건 프론트엔드 개발을 하는 저였어요. 그래서 도왔어요”

“왜요?”

충분히 설명했다고 생각했는지 다시 되묻자 유남주님이 제 질문의 목적을 이해 못하겠다는 듯 자기 자신도 본 적 없었을 표정을 지었습니다. 제가 알고 싶은 건 신념이나 지향점, 철학처럼 유남주라는 사람의 깊은 곳에서 기획에 참여하게 만든 것이 무엇인지였습니다. 기획이 병목이라고 누구나 기획에 참여하는 건 아니거든요. 질문의 의도, 제가 알고 싶은 것을 설명하자 유남주님은 금방 답했습니다.

“사용자가 겪을 문제가 무엇인지를 최대한 사용자에게 직접 듣고 싶었어요. 디자이너를 거친다는 건 디자이너의 생각을 거치는 거잖아요. 제가 기획에 참여하여 디자이너를 거치지 않고 같은 수준에서 사용자의 문제에 접근하고 싶었어요. 디자이너를 믿지 못해서 그런 건 아니예요.”

“사용자의 문제에 한 걸음 더 접근하고 싶었다는 거군요. 좋아요. 그럼 더 접근하려고 어떤 행동을 했어요?”

“사용자 인터뷰를 했어요.”

“개발 단계에서요?”

“네. 학교에 가서 거리 인터뷰를 시도했어요. 열 명 정도 했던 것 같아요.”

드디어 나온 것 같습니다. 이제 왜(Why)를 더 물어봐야 계속 순환할 것 같거든요. 이력서에 이 프로젝트에 대해 작성한 타이틀을 바꾸는 게 좋겠습니다. 사용자 인터뷰를 토대로 사용자 경험을 최적화한 대학 출석 관리 프로젝트. 프로젝트명으로는 채용담당자가 뭔지 알지 못하니 작성자 자신이 드러나는 타이틀을 쓰자는 말을 유남주님이 비로소 이해했다며 좋아합니다.

두 번째 프로젝트는 포트폴리오 단골 소재인 “모여서 각자 코딩”(이하 모각코) 프로젝트입니다. 그런데 여느 모각코에 비해 프로젝트 기간이 깁니다. 모각코 치고는 말이죠. 모각코를 3개월이나 만들 일인가? 알고보니 출시 후 실제 운영을 한 기간을 포함한 거였습니다. 왜 계속 운영하지 않았느냐 묻자 백엔드 개발자가 취직하여 이탈하게 되어 자연스러운 수순인 것처럼 운영을 종료했다고 하네요.

모각코 프로젝트를 만들 때 프론트엔드 개발자가 도전할만한 구현 사항 중 하나는 지도입니다. 지도 출력은 지도 API를 사용하니 간단하지만, 유려한 사용자 경험을 주면서 코드를 깔끔하게 정리하기 꽤 까다롭거든요. 지도 위에 핀을 표시하는 것을 예로 들면, 개발하는 과정에선 지도에 핀 몇 개만 나오니 간과하기 쉬운 게 핀이 몇 백 개인 경우입니다. 또, 핀을 표시하는 우선순위도 고려해야 하죠. 모바일에서는 화면이 좁아서 지도 사용자 경험이 안 좋기 일쑤고요.

유남주님이 참여한 학교에서 모각코하는 프로젝트는 출시하고 2개월이나 운영했습니다. 출시 후 운영은 눈길을 끌지만, 역시 기술적으로는 특이사항이 보이지 않습니다. 지도도 딱히 차별화 요소가 있진 않았죠.

“이 프로젝트에서 유남주님이 소구하는 요소는 무엇인가요? 이 프로젝트에도 기획에 참여한 거예요?”

“맞아요. 기획에 참여해서 사용자 UI를 개선해 사용율을 높였어요.”

“오, 대단하네요! 근데 사용자 UI에 기여한 거라는 건 무엇을 근거하는 거예요?”

“사용자가 저희 서비스에서 어떤 행동을 하는지 데이터를 쌓아서 분석했어요.”

그 말에 흥미가 생겼습니다. 이제 제 관심은 그동안 숱하게 봐온 모각코 프로젝트에서 지표 분석으로 넘어갔지요. 유남주님은 MaxPunnel이라는 도구를 썼다고 합니다. 어떤 문제가 있었기에 지표 분석 도구를 썼는지 흥미를 감추지 못하고 물어봤습니다.

개설된 모각코 모임이 너무 없었다고 대답합니다. 서비스에 가입한 사용자는 4천여 명인데, 모임은 1주일 내내 두세 개 밖에 없었대요. 회의를 해봤지만 확 꽂히는 가설은 나오지 않았는데, 곧 있으면 시험 기간이기 때문에 가능하면 시험 기간 전에 문제를 해결하고 싶었다고 합니다. 고민에 빠져 잠기기 직전, 유남주님의 머리 속에서 섬광처럼 떠오른 생각이 있었습니다. 사용자가 우리 서비스에서 하는 행동을 기록해서 분석해보고 싶다는 생각이었죠.

“처음엔 직접 만들려고 했어요. 간단해보였거든요. 근데 막상 구현을 생각해보자 구현하기 어렵다는 걸 깨달았어요. 그래서 열심히 웹을 검색하여 지표 추적과 분석하는 도구가 있다는 걸 알게 됐어요. 뭘 써야할지 몰라서 어떤 솔루션 업체에서 추천하는 제품을 선택했어요. 무료 플랜이 있더라고요”

신입이 만드는 포트폴리오 프로젝트에서 지표 분석 도구를 보다니, 흥미롭습니다.

“그런데 왜 지표 추적과 분석을 한 거예요?”

이번엔 제 질문 방식에 익숙해졌는지 질문 의도와 목적에 맞는 대답을 합니다.

“마음 같아서는 사용자를 만나 인터뷰하며 문제를 찾고 싶었어요. 근데 당시 상황으로는 곧 사용자가 모두 이탈해서 아무도 이용하지 않을까봐 겁이 났어요. 한시라도 빨리 사용자의 피드백을, 그것도 가능한 한 많은 사용자의 피드백을 받아야 했죠.”

“처음엔 지표 추적과 분석 도구 존재를 몰랐던 것 같은데, 어떤 과정을 거쳐서 지표 추적과 분석 도구에 이른 거예요?”

“예전에 특정 페이지를 기존 버전과 변경한 버전으로 구분해서 사용자 반응을 보고 싶었던 적이 있어요. 그러려면 사용자가 로그인을 해야 누가 어떤 페이지를 마주친 것인지 알텐데, 로그인 사용자 수는 로그인 안 한 사용자보다 훨씬 적을 것 같아서 포기했죠.”

역시 밑도끝도 없이 사용자의 행동을 추적하고 싶다는 생각에 이를리가 없어요. 평소에도 사용자가 어떻게 행동하는지, 어떤 상황에서 문제에 봉착하는지 알고 싶어했고, 소프트웨어 엔지니어링 역량이 더해지자 엔지니어링 방식으로 해결할 고민에 이른 거지요.

“지표 분석 결과, 문제는 현재 위치에서 모임을 개설하는 걸 사용자들이 부담스러워했어요. 실제로 사용자 이동 경로를 보면 모임 개설까지는 가요. 근데 그 페이지에서 사용자 조작을 보면 다른 위치에서 모임을 개설하는 걸로 보이는 이력이 반복되더라고요. 저희는 지도 쓰기가 불편하니 사용자가 편하게 모임 개설하도록 위치 정보를 사용해 현 위치에 모임을 개설하게 한 건데, 사용자는 불편하더라도 지도를 쓰고 싶어했어요. 왜 그런지는 아직도 모르겠어요. 몇 몇 가설은 있지만요.”

“그럼 문제를 해결한 후 변화는 어떠한가요?”

“접속 대비 모임 개설율이 0.5%에서 8%로 올랐어요”

“대단한 업적이네요! 방금 남주님 얘기를 요약하면 사용자를 만나는 것과 사용자를 빨리 만나는 것이 도출되는데요. 이 둘 중에 아주 조금이라도 더 중요하게 여기는 건 뭐예요?”

이번엔 꽤 길게 침묵이 이어집니다. 고심을 마친 유남주님은 대답합니다.

“사용자를 만나는 거요”

사용자를 많이 만나 빠르게 핵심 지표의 문제를 해결하여 16배 상승시킨 모각코 프로젝트. 두 번째 프로젝트의 타이틀은 유남주님이 지었습니다. 만족스러워하고 저도 만족스러웠습니다.

유남주님은 이력서 주제를 어떡해서든 고객에게 피드백을 받아 고객의 실제 문제를 해결하는 개발자로 잡았다고, 커피챗을 한 날로부터 며칠 후에 알려줬습니다. 서류 전형 통과 소식을 알려주면서 말이죠. 그는 탈락할 때 탈락하더라도 왜 탈락했는지 막막해서 답답했던 기분이, 이제는 들지 않아 좋다고 합니다. 실제로 그렇든 아니든, 어떡해서든 고객에게 피드백을 받아 고객의 실제 문제를 해결하는 자신을 탈락시켰다고 생각하게 되었고, 속상하지만 막막하여 답답한 기분은 해소됐다고 합니다. 예전처럼 채용담당자가 자신을 전혀 엉뚱한 사람으로 인식하지 않을테니 말이죠.

🚨 본 컨텐츠에 등장하는 인물 중 글쓴이를 제외한 모든 인물의 이름은 가명이며, 지명, 시간, 단체나 기관, 사건은 각색하고 창작하였습니다. 일부라도 비슷하거나 겹치는 경우는 우연히 일치하는 것이니 이 점, 양지해주시길 바랍니다. 🚨