문제 해결을 위해 무엇도 서슴지 않는 실행력의 배경

들어가며

무더운 8월 어느 날. 이력서 멘토링을 신청한 사람의 이력이 흥미롭습니다. 금융 업계에 있다가 프론트엔드 개발자로 전직을 했거든요. 개발자로 일하다 직업을 금융업으로 전직하는 경우는 몇 번 봤지만, 그 반대는 처음 봤습니다. 이력서는 간결하고, 훌훌 읽힙니다. 이력서 주제에 맞춰 이력서 내용이 잘 정렬되어 있네요. 웬지 신청자가 설정한 주제가 맞을 것 같은 예감이 듭니다.

한날 : 이력서를 보면 핵심 문장이 두 개네요. 어떤 게 이력서의 주제예요? 두 개 다 잡으신 건가요? 아니면 첫 번째 건가요?

👱‍♂️ : 첫 번째 거로 잡았습니다.

한날 : 문제 해결을 위해 무엇도 서슴지 않는 개발자 . 어떻게 문제에 임하는지 구체적이라 좋네요. 기존 프로젝트에서 이 주제에 부합하는 이야기가 있다면 들려주시겠어요?

👱‍♂️ : 일단 저는 두 가지로 말씀드리고 싶은데요. 사실 그 중에서도 제일 제가 첫 번째로 여기고 있는 부분은 게임 프로젝트에서 겪은 문제였어요. 디스플레이 주파수 관련해서 렌더링 횟수가 달라지는 문제가 있었는데, 그 문제를 해결하기 위해서 여러 문건들을 찾아보았어요. 자바스크립트 게임 엔진은 이 문제를 어떻게 해결했는지 좀 파고들고자 자바스크립트 게임 엔진 중에 제일 많이 사용되는 두 개의 라이브러리의 소스 코드를 파면서 작업을 했었거든요. 그래서 그거를 가장 중점적으로 말하고 싶습니다.

학습에 관한 흥미로운 신호가 발생했는데, 여러분도 느끼셨나요?

멘토링

학습하는 감이 좋다. 그런데 학습력도 따르는.

한날 : 그때 그 자바스크립트 게임 엔진을 파셨던 이유는 뭐예요? 그러니까 구글링하여 발견하는 문서를 참고하는 걸로 끝낼 법도 한데, 굳이 게임 엔진을 파셨던 이유가 궁금합니다.

👱‍♂️ : 일단 제가 생각했을 때는 rAF( requestAnimationFrame )라는 콜백 함수를 당연히 사용해야 된다고 생각을 했었거든요. 왜냐면 setInterval 같은 웹 API로는 애니메이션 구현하는 데 좀 한계점이 명확하고, 그런 한계점을 극복하기 위해서는 rAF라는 애니메이션 전용 API를 써야 해요. 그럼 자바스크립트 게임 엔진들은 이 문제를 어떻게 해결했을까, 라는 생각이 들었어요. 왜냐면 그들이 게임 애니메이션 최적화를 위해서는 rAF를 당연히 썼을 거고, 만약에 썼다면 저와 똑같은 문제에 봉착했을텐데, 그럼 그들은 이걸 어떻게 해결했을까, 라는 생각을 가지고 이렇게 소스 코드를 찾아봤던 것 같습니다.

한날 : 문제를 좁혀가신 과정이 인상적입니다. 근데 이 게임 프로젝트 기간이 상당히 짧네요?

👱‍♂️ : 아, 그건 부트캠프에서 진행한 졸업 프로젝트여서 그렇습니다. 3주가 주어졌어요.

한날 : 게임을 만들기엔 짧은 기간인 걸 인지하셨을 것 같은데, 왜 게임을 만드신 건가요?

👱‍♂️ : 제가 게임을 좋아하는 편이거든요. 요즘에는 L.O.L이라는 게임을 즐기고, 프롬 소프트웨어 사에서 만든 소울라이크 게임들을 좋아해요. 그리고 게임을 만들고 싶다는 생각을 대학에 다닐 때에도 했었어요. 제가 OOP를 배우면서 게임에 있는 개체 하나 하나가 객체로써 동작하고 상호작용한다는 생각이 들었고, 게임을 만들면 그런 세계를 제가 만든다는 느낌을 받았죠.

한날 : 그럼 이 게임 프로젝트에서 OOP에 대해 충분히 경험하셨어요?

👱‍♂️ : 저는 JavaScript를 좋아하는데 JavaScript에서 클래스 기반 OOP를 써보진 않았어요. 그래서 이번엔 클래스를 제대로 써보자 생각을 했고, 캔버스 API도 안 써봤어서 캔버스 API를 제대로 다뤄보자는 생각을 했었어요.

한날 : 그럼 개발 기간이 짧으니 게임 엔진을 잘 다루는 데 집중하는 게 더 효율이 좋았을 것 같은데, 왜 그 시점에 JavaScript에 대한 학습 성장 방향을 정한 건가요?

👱‍♂️ : 요즘에는 리액트 같은 프레임워크, 라이브러리를 많이 쓰는데, 저는 그 라이브러리나 프레임워크를 온전하게 제 걸로 만들기 위해서는 그것의 원초가 되는 언어를 정말 잘 알고 있어야 했다고 생각하거든요. 리액트 자체가 JavaScript로 구성된 언어이다 보니까 자마스크립트가 어떻게 구성되는지는 모르고서는 리액트를 익혀봤자 겉핥기 밖에 안된다고 생각했어요. 그리고 제가 비전공자인데, 전공자분들의 4년을 절대 무시할 수가 없거든요. 저 또한 이제 다른 전공으로 4년 동안 배우면서 기초 소양이나 근간들이 얼마나 중요한지 알기 때문에 전공자분들하고 경쟁하기 위해서는 저도 정말 밑에서부터 차근차근 착실히 올라가야 한다고 생각을 했습니다. 아니, 그걸 넘어 저만의 무기도 갖춰야 하고요.

한날 : 전공자, 비전공자를 떠나서 기초를 튼튼히 다지려는 자세는 참 좋습니다. 그런데 엔지니어링에 있어서 일정 준수도 매우 중요해요. 이력서를 보니 디자인 패턴도 학습하신 것 같은데, OOP와 디자인 패턴을 학습하는 데 얼마나 걸린 거예요? 하루 8시간을 1일로 기준으로 했을 때, 실제로 들어간 기간이요.

👱‍♂️ : 한 일주일 정도 됐던 것 같습니다.

한날 : 일주일이요? 흐음. 그럼 이 게임 프로젝트 만들 때 학습에 들어가는 시간은 어느 정도로 추정하셨어요? 가령, 캔버스를 처음 써봤다고 했으니 캔버스를 학습하는 시간도 필요했을테고, 애니메이션 처리나 키 입력 처리, 오디오 처리 등을 대부분 처음 학습했을 것 같은데 말이죠.

👱‍♂️ : 맞습니다. 딱 구분하긴 어려운데, 학습 자체를 한 시간과 시행착오를 거치며 학습한 시간을 합치면 한 5일 정도 들어간 것 같아요.

한날 : 대략 프로젝트 기간의 반 정도를 학습하는 데 쓴 셈이군요. 그럼 프로젝트 전과 후를 비교했을 때, 프로젝트를 하고나서 새롭게 알게 됐거나 막연하게 알던 걸 더 구체적으로 알게 된 게 있다면 무엇인가요?

👱‍♂️ : 콜스택하고 웹API에 대해 더 잘 알게 됐어요. 콜스택과 태스크큐, 이벤트루프는 JavaScript의 핵심이기도 한 거여서 막연하게라도 알고 있었는데, 실질적으로 문제를 해결하는 데 지식을 동원해야 하는 상황에 직면한 건 게임 프로젝트가 처음이었어요. setInterval 과 rAF를 비교해서 구현에 적용하려면 당연히 이벤트 루프를 타고 태스크큐가 어떻게 처리되는지 공부할 수밖에 없었고요. 태스크큐 관련해서 rAF는 렌더링 이전에 무조건 콜백 함수가 콜스택으로 들어가 처리된다는 걸 이해하고, setInterval 은 그것과 관계없이 일정 시간에 따라 돌아가는데 이 시간도 보장되는 게 아니라는 걸 알면서 애니메이션 처리에 대한 고민 자체를 더 깊게 할 수 있게 됐습니다.

한날 : 그걸 오픈소스 게임 엔진 소스를 파면서 이해하셨다고요?

👱‍♂️ : 아, 그게 문서도 읽고...

한날 : 문서 읽은 것과 소스 코드 파본 것 중 뭐가 더 그런 이해에 도움이 됐어요?

👱‍♂️ : 소스 코드를 파본 게 아무래도 더 도움이 된 것 같습니다.

한날 : 소스 코드에선 구현에 대한 설명이 되어 있진 않을텐데, 어떻게 소스 코드를 보며 개념 이해를 해내신 거예요?

👱‍♂️ : 구조와 설계를 먼저 이해하고, 구현 의도를 이해하려 노력했습니다. 또, 저도 구현을 따라하며 직접 비교 경험을 했고요. 그러니 어떨 때 어떻게 문제를 해결하는지 이해가 되면서 자연스레 기초 부분을 더 이해하게 된 것 같아요.

한날 : 대단하시네요. 손이 빠르신건지 이해력이 빠르신건지. 학습하는 감과 학습력은 확실히 좋으신 것 같고. 학습 능력, 특히 문제를 체계화하고 구체화하여 문제의 핵심을 감잡는 부분을 잘 설명하여 소구하면 좋겠어요.

👱‍♂️ : 제게 그런 능력이 있는지 잘 모르겠지만, 감사합니다.

한날 : 저는 많은 사람의 이력서에 대해 멘토링을 했잖아요. 이력서만으로 학습 능력이 읽히는 건 드물어요. 다만, 유남주님이 하신 일을 알거나 이해하는 사람이 봤을 때 그렇고요. 이 이력서를 인사팀의 채용담당자가 볼 수도 있죠. 그래서 뭔가를 학습했다면, 학습하기 전과 후가 대비되게 설명하면 좋을 것 같아요.

👱‍♂️ : 아직 잘 감이 오지 않아요.

한날 : 지금보다 더 대놓고 “나 학습 능력 좋다”는 것이 드러나도록 표현을 고치는 거죠. 비전공자라는 것도 의식할 필요 없어요. 다행히 이력서엔 그런 티가 나진 않네요.

그렇게 게임 프로젝트에 대해 이것 저것 물어보며 그의 학습 능력을 살펴보았습니다. 문제 정의를 구체적으로 잘하고, 그 문제를 해결해가는 과정에서 내리는 작은 문제 정의와 판단이 무척 적절했습니다. 자신은 왜 그런 판단을 했는지 모른다고 하는데, 암묵지가 작용했든지 아니면 기가 막히게 매번 좋은 판단을 했나 봅니다. 그게 말이 되는 확률인지는 모르겠지만요.

당연한 것처럼 깔끔하고 완결된 일 처리

한날 : 주어진 업무 범위를 넘어 회사의 이익에 필요한 일을 찾아 행동하는 사람 이라고 두 번째 주제를 잡으셨어요. 이력서에 기재한 프로젝트에서 이 주제를 설명하는 경험이 있다면 무엇인가요?

👱‍♂️ : 이력서에 쓴 프로젝트 중엔 없는 것 같습니다. 제가 생각했을 때 당연히 해야 된다고 여긴 건 주도적으로, 그리고 선제적으로 해왔거든요.

한날 : 팀이 작으니 선제적으로 대응해버리면 그런 상황이 생기지 않을 수도 있겠네요. 손이 빠른 게 맞는 것 같은데?

👱‍♂️ : 제가 저 문단을 쓴 이유는 이전 경력에 나오는 회사에서 뭐를 원하는지, 그리고 회사가 뭐를 추구하는지를 정말 빠르게 캐치해냈던 사람이라고 생각했거든요. 개발자라고 하면 개발하는 게 가장 중요하다고 생각할 수 있지만, 회사 입장에서는 그게 아닐 수도 있잖아요. 어떤 일을 처리해야 되는 계획이 회사에 있을 텐데 저는 그거를 빠르게 파악하는 능력이 있고, 그거를 위해서라면 언제든지 하던 일을 잠시 멈추고 빠르게 필요한 일에 집중하는, 이런 맥락 전환에 있어서 좀 특화된 사람이라고 생각을 해요. 그런 능력으로 회사가 저에게 굳이 요구하지 않아도 제가 알아서 찾아가서 해결하는 점을 어필하고 싶어서 수록했습니다.

한날 : 아하, 요는 빠른 업무 전환력과 적응력으로 회사에서 일어나는 다양하지만 필요한 일을 빠르게 해치울 수 있다는 거군요.

👱‍♂️ : 부끄럽지만, 저는 그렇다고 생각합니다.

한날 : 뭐가 부끄러워요. 저하고 멘토링하는 동안엔 최대한 본인을 자랑하고 뽐내야 합니다. 숨기면 이력서 주제를 잡기 어려워요. 근데 이력서 디자인은 도움을 받은 건가요?

👱‍♂️ : 제가 그냥 한 겁니다.

한날 : 그래요? 깔끔하고 예쁜데, 디자인도 하세요?

👱‍♂️ : 그렇진 않고요. 또, 제 이력서 디자인이 괜찮다고 생각하지 않기도 해요.

한날 : 저보다 훨씬 잘하시네요. 아, 내 디자인 수준이 너무 낮은 건가? 아무튼, 하나 정도 있을법한 오타나 오표기도 없고, 용어도 대소문자, 띄어쓰기까지 정확히 쓰고. 프로젝트 설명도 간결하지만 필요한 내용을 담아내고. 이 이력서는 몇 번 고치셨어요?

👱‍♂️ : 세 번째 버전이에요. 첫 번째 버전은 80군데 지원해서 단 한 곳도 서류 전형을 통과하지 못했고요. 두 번째 버전은 60군데 중에서 10군데 정도 서류 전형 통과했어요. 그래서 조금 더 보완해봤습니다.

한날 : 통과율이 오른 것도 대박인데, 요즘같은 시기에 60군데 중 10군데에서 통과했다니, 이 또한 대박이네요. 이력서에 있는 링크를 누르면 프로젝트 저장소가 나오는데, 이 저장소의 README도 물론 직접 쓰신 거죠?

👱‍♂️ : 네.

한날 : 문서화를 정말 잘 하셨군요. 관성적으로 작성하는 README.md가 아니라 포트폴리오용에 맞춰 채용담당자가 봐야 할, 알아야 할 내용을 딱 채워 넣으셨어요.

👱‍♂️ : 그야 당연히...

한날 : 당연하지 않아요. 왜 이렇게 작성하겠다고 생각하셨어요?

👱‍♂️ : 채용담당자가 제 깃헙 페이지에 온 건 이력서를 읽다 제가 작업한 것에 대해 자세히 알고 싶다는 걸 의미한다고 봐요. 하지만 여전히 저에 대해 잘 모른다 생각했던 것 같아요. 사실 이력서에 있는 내용을 풀어쓴 거라서 이렇게 써도 되나? 고민하고 있긴 해요.

한날 : 잘 쓰셨어요. 회사에 이익이 되는 일을 찾아서 행동하는 건 이력서만으로는 실제 그런 사람인지 모르겠지만, 일을 깔끔하게, 그리고 완결성있게 마무리하시는 것 같아요. 개발하신 프로젝트도 이 버전에선 여기까지 구현해야 해, 라고 정의하고 그 안에서 구현할 것을 깔끔하게 완결시키셨고요. 이력서도 오탈자, 표기, 디자인에 그치지 않고, 채용담당자 입장에서 서류 전형으로 인식하는 부분을 파악해서 목적과 용도에 맞춰 구비했네요. 더구나 README는 이렇게까지 공들여 쓰는 사람은 무척 드물거든요. 꼼꼼한 PM이 일처리해놓은 걸 보는 것 같아요.

👱‍♂️ : 좋게 봐주셔서 고맙습니다.

한날 : 개발자로서 신입이지 이전 경력이 있긴 하지만, 어쨌든 신입 개발자에겐 드문, 꽤 특이한 경우예요. 그래서 개발자로서 경력에서 어필하기 어려운 부분보다는 일을 깔끔하게 완결짓는 역량을 부각시키는 게 어떨까요. 이런 특성은 신입들에겐 흔치 않아요. 업무 경력이 적거나 없기 때문에 완결짓는다는 기준과 감을 잘 못잡죠.

👱‍♂️ : 아마 금융쪽에서 일을 배운 게 있어서 그런 것 같아요.

한날 : 그럴지도 모르겠네요. 제가 사수로서 보면 매력 요소로 보여요. 그런 점에서 본인의 매력 요소를 덜 드러내고 있고요.

👱‍♂️ : 동영상 편집 툴 프로젝트는 한날님 말씀만큼 완결성 있진 않은데, 그런 걸 어필해도 될런지...

한날 : 무엇을 기준으로 완결짓지 못했다고 보세요?

👱‍♂️ : 상용 제품으로 파는 데 필요한 최소한 기준에 미치지 못해서요.

한날 : 오, 이 프로젝트로 창업하려고 한 거였어요?

👱‍♂️ : 그건 아니고, 저 나름대로 정한 목표였어요.

한날 : 좋네요. 그럼 어느 정도 기간이 주어지면 완결지을 것 같아요?

👱‍♂️ : 음. 혼자 작업해서 3개월 정도 필요할 것 같습니다.

한날 : 왜 3개월인가요?

👱‍♂️ : 일단 품질. 영상 크기가 완벽하게 최적화가 안되어 있거든요. 그래서 이미지를 가공하는 데 있어서 영상을 만들면 용량이가 많이 커져요. 그래서 작업물을 내보내기(export) 할 때 뒷처리가 필요할 것 같고요. 그 외에도 앱까지 출시를 했는데, 지금 앱이랑 웹을 다 다루면서 백엔드 API를 관리를 하려고 하는데, 그걸 제가 다 다듬고 상품으로 내놓기까지는 3개월 정도는 걸릴 것 같습니다.

한날 : 그럼 그렇게 3개월 걸린다고 했을 때 기술적으로 시도해볼 만한 게 있어요?

👱‍♂️ : 기술적으로 시도해볼 만한 건가요?

한날 : 무척 다양한데, 예를 들면 테스트 코드를 안 짰으면 테스트 코드를 작성할 수도 있고 배포 자동화를 할 수도 있고.

👱‍♂️ : 아하. 현재 컴포넌트 테스트, 유닛 테스트까지는 커버리지가 60~70%정도 되는데, 백엔드엔 테스트 코드가 없어요. 그래서 백엔드 테스트 코드를 작성해야 하고요. 배포 자동화도 안 되어 있어서 CI/CD 구축과 파이프라인 구축도 좀 시간을 들여 해야 할 것 같아요. 백엔드는 익숙하지 않아서 어려움을 좀 겪었거든요. 그래서 일정을 보수적으로 잡아야 할 것 같아요.

한날 : 테스트 코드를 이미 작성하셨군요?! 언제부터, 그리고 왜 작성하셨어요?

👱‍♂️ : 유닛 테스트는 계속 작성하려고 했어요. 왜냐하면 뒤에서 로직 실행되는 것도 중요한데, 실제 유저한테 제대로 보여지느냐, 정확한 UX를 제공하느냐도 굉장히 중요한 부분이라 생각해왔어요. 그래서 컴포넌트 테스트는 꼭 하려고 하고 있습니다.

한날 : 그게 유남주님의 구현을 마무리 짓는 기준인가요?

👱‍♂️ : 생각해본 적 없는데, 그런 것 같아요. 유저에게 작업물이 나가는 데 있어서 최초로 그리고 최후에 검증하는 단계니까요.

한날 : 거봐요. 완결 기준이 참 합리적입니다.

마치며

유남주님은 자신은 비전공자이므로 전공자들이 4년 이상을 훈련한 시간을 따라잡으려면 많이 노력해야 하며, 따라잡는 데 그치지 않고 차별화 된 무엇인가를 가져야 한다고 생각했습니다. 그리고 그의 세 번째 이력서에서 보다시피 그럴 역량을 갖추고 있었습니다. 학습 능력과 일을 완결짓는 역량이 문제 해결을 위해 무엇도 서슴지 않는 실행력으로 발현된 것이라 생각을 해봤습니다.