본문 바로가기

대학원 기록/기록

취업준비 - 왜 알고리즘 테스트일까?

https://www.podbbang.com/channels/9126/episodes/21821835

 

알고리즘 특집 1부

프로그래밍은 문제 해결이다! 코딩 인터뷰가 보편화 됨에 따라 부쩍 재 조명을 받고 있는 알고리즘에 대해 ‘프로그래밍 대회에서 배우는 알고리즘 문제 해결전략’의 저자 구종만님, 그리고

www.podbbang.com


위의 팟캐스트를 들어보는 것을 추천하고 싶다.

 

결론부터 말하면... 알고리즘은 기초 체력이다!

 

이번 글에는 IT기업은 왜 왜 알고리즘 테스트를 통해서 직원을 채용할까에 대한 개인적인 생각을 적어보고자 한다.

 

"프로그래밍 대회에서 배우는 알고리즘 문제 해결전략"의 저자인 구종만님이 게스트로 참여한 팟캐스트에서 정말 좋은 가르침들을 배울 수 있었다.

 

 

선수들이 개인 시간에 체육관에 가서 기초 체력을 유지하거나 혹은 늘리기위해 훈련하듯
개발자에게는 알고리즘 공부를 통해 기초적인 문제해결 역량을 향상할 수 있다.

개인적으로 좋은 메타포였다고 생각한다.

 

개발과 관련된 자기계발서에서 개발자라는 직군은 "운동선수"를 통한 메타포로 자주 비유되곤 한다.

 

2가지 부분에서의 메타포 영역을 살펴볼 수 있는데

 

하나는 이직(이적)과 관련된 사안이고 다른 하나는 끊임없는 자기 관리이다.

 

자기 관리

 

운동선수들은 감을 잃지 않고 기초 체력을 계속 유지하기 위해 비시즌 시기든 시즌 시기이든 끊임없이 운동을 해줘야 한다. 그리고 최고 품질의 음식을 먹고 최고 품질의 휴식을 취한다.

 

동시에 팀원들과 함께 서로의 합을 맞추며 협업하는 시간을 가지고 결정적인 경기 시간에 최고의 모습을 보여줘야 한다.

 

나는 개발자도 운동선수와 비슷한 루틴을 가져야 한다고 생각하는 편이다. 

 

계속 변화하고 있는 시장에 맞는 기술들을 살펴보고, 자신의 분야와의 접목 가능성을 살펴보고, 가능성이 높다면 그 기술을 한번 체험해보는 것.

 

그리고 한동안 사용하게 될 프로그래밍 언어와 프레임워크에 대해서 튼튼한 기초역량을 유지하기 위해 지속적으로 공부하는 것.

 

중요한 프로젝트에서는 문제가 되지 않도록 충분히 건강관리를 잘하는 것.

 

내 주변에서 볼 수 있는 다른 회사원이나 기타 전문직들에 비해서 개발자는 순간적으로 변화하는 시장에 민감한 반응을 보여야 하고 동시에 기초적인 체력(물리적인 체력과 지식과 관련된 체력)도 꾸준하게 관리되어야 한다.

 

이것이 개발자의 숙명이다. 자기 계발 역량이 장착되지 않는다면 이 바닥에서 정말 힘든 시간을 보내야 할 수도 있다.

 

자기 계발의 과정을 즐기지 못한다면 개발자는 썩 유쾌하지 않은 직업이 될 수 있다.

 

알고리즘(문제 해결)은 개발 과정에서 마주하게 되는 작은 문제들부터 큰 전략적인 문제들까지 다양한 관점으로 해결할 수 있는 시야를 제공해주는 일종의 시뮬레이션을 제공해준다.

 

이 시뮬레이션을 경험하면 경험할수록 기초체력이 튼튼하게 유지되고, 나아가 전공과 관련된 지식 프로그래밍 언어 설계에서 해당 로직을 어떻게 처리하는지에 대한 세세한 지식까지 습득해볼 수 있다.

 

물론 실제 개발환경에서 문제해결 시뮬레이션에서 경험했던 상황과 정확히 일치하는 상황을 마주할 일은 거의 없다.

 

그래서 많은 이들이 알고리즘 테스트가 시간낭비적이라고 힘든 상황을 토로하곤 한다.

 

하지만 시간 낭비가 아니라고 말하고 싶다. 구종만 저자의 말처럼 우리는 헬스장에 가서 실제 근육을 활용하기 위해서 무산소 운동을 즐기는 게 아니다.

 

그 자체로 뿌듯한 느낌을 제공해주기도 하고, 기초적인 체력이 튼튼해지며 나아가 특정한 상황에서는 근육을 활용해야 하는 순간이 오기 때문이다.

 

알고리즘도 마찬가지다. 시뮬레이션 문제를 해결했다는 뿌듯함을 줄 수 있고, 기초적인 자료구조와 알고리즘 전략이 튼튼해지며 실제 현장에 투입돼서 개발할 때 특정 문제 전략을 활용하게 되는 기쁜 순간이 올 수도 있다.

 

이 모든 상황을 고려한다면 문제 해결 시간에 쏟는 노력은 헛되지 않을 수 있다.

 

이직

 

개발자라는 직군은 다른 직군과 다르게 이직이 상당히 활발하다. 전체 직군을 통틀어서 IT 관련 종사자보다 이직이 많은 직업은 전무하지 않을까 싶을 정도로 헤드헌터 시장이 꽤나 큰 직업군이다.

 

그뿐일까. 실력이 증명되었다면 연차에 상관없이 더 높은 직군으로 점프할 수 있다.

 

이 과정에서 해당 인물을 검증할 수 있는 수단이 필요한데, 컴퓨터 공학과 관련된 분야에서는 이런 검증을 거치는 게 쉽지가 않다.

 

네트워크, OS, 하드웨어, 머신러닝, 딥러닝, 소프트웨어 설계, 보안 등등

 

컴퓨터 공학의 하위 분야에서의 특정 문제를 검증하는 것은 상당히 까다롭다.

문제를 설계하기도 힘들고, 이 문제가 가장 옳은 정답이라고 설득하거나 결정하는 것도 어렵다.

거기에 이러한 시험을 만들기 위해 고급인력을 따로 차출해서 시간을 투자하는 것에는 엄청난 비용이 필요하다.

 

그마나 가장 나은 방안은 참여했던 프로젝트를 살펴보고, 그 프로젝트에 대한 얘기를 잠시 나눠보는 게 가성비 좋은 검증일 것이다.

 

하지만 프로젝트는 늘 허수를 가지고 있다.

 

예전에 직업 설명회에 가서 나는 전문가에게 다음의 질문을 한 적이 있다.

 

"프로젝트 참여할 때 갈등 상황을 마주해본 적이 있는지, 그 갈등 상황을 회사에서는 어떻게 해결하는지 궁금합니다."

 

전문가 분은 솔직하게 말해줬다.

 

"프로젝트 참여에 있어서 가끔은 일에 전혀 도움이 되지 않거나, 일을 해야 하는데 이를 기피하는 사람들이 존재한다. 이러한 갈등 상황을 가끔 만나는데 이는 피할 수가 없다. 특별한 해결책이 없고 가장 무난한 방법은 순조롭게 대화로 시작하는 것이다. 이에 대해선 명확한 답을 해줄 수가 없는데, 나의 경우도 프로젝트에 참여해서 정말 큰 기여를 한 적이 있기도 하고, 아예 아무것도 안 하는(무임승차)를 경험해 본 적이 있다. 그러니 그러한 상황은 되도록 피하면 좋겠으나 그 상황 자체에 큰 스트레스를 받지 않았으면 한다. 모두가 정당한 일을 하면서 진행되는 프로젝트는 경험상 드물었다." 

 

즉 프로젝트에 참석해서 전반적인 얘기는 할 수 있을지라도 그 프로젝트를 진행한 실력까지는 확인해보기가 까다로울 수 있다는 것이다. [ 그 사람이 프로젝트의 핵심이었는지 허수였는지는 확실하게 알기가 힘들다. (피어 리뷰를 거칠 수 있긴 하지만..) ]

 

이런 경우는 기초 체력을 보는 게 상당히 좋다. 

 

그러면 튼튼한 개발자를 확인하는데 좋은 지표가 뭐가 있을까? 아마도 알고리즘 테스트가 아닐까 한다.

 

하나의 공정한 지표 기둥. 알고리즘 테스트

 

대부분의 사람들은 시험을 싫어한다.

 

대부분의 고등학생들을 수능을 싫어한다.

 

어렸을 때부터 중간고사, 기말고사, 모의고사 등등 시험을 통해 검증받는 과정을 거치는 대한민국의 대부분의 사람들에게 "시험"은 정말 피하고 싶은.. 매번 주기적으로 오는 고통의 시간이다.

 

이 사실을 모르는 사람들이 없다. 교육계, 부모, 학생, 기업 등등..

 

그런데 아무도 시험을 대체할 수 있는 해결책을 내놓지 못했다.

 

그 이유는 시험은 그나마 가장 공정하면서 깔끔하게 구분되는 결과를 제공해주고 비용적인 측면에서 효율적이기 때문이다.

 

억울할 수도 있다. 누군가는 찍어서 정답을 맞출 수 있고, 누군가는 어제 벼락치기로 공부한 부분에서 운 좋게 시험문제에 나올 수 있다.

 

하지만 이는 어디까지나 운의 영역일 때의 이야기다. 진짜 중요한 것은 기초적인 지식이고 체력이다. 

 

알고리즘 테스트는 그러한 점에서 컴퓨터 공학에서 그나마 가장 공정하고 명쾌한 정답지를 제공해줄 수 있는 영역이라고 생각된다.

 

메모리와 시간 효율성만 통과한다면 그 어떤 알고리즘이든 그 문제를 해결한 것으로 확인해주기 때문..

 

결론. 알고리즘 테스트는 정말 힘든 과정이다. 하지만 즐길 수 있다는 생각은 가지도록 해보자.

 

원하는 회사로 이직하고자 할 때도 알고리즘 테스트는 피할 수 없다.

 

개발자라면 기초적인 역량을 검증받는 그 과정을 피하기란 상당히 까다로울 것이다. [ 따로 자격증이나, 대회 수상 경력이 있는 게 아니라면... ]

 

그리고 "알고리즘 테스트"라는 표현보다는 "문제 해결 시뮬레이션"이라는 표현을 사용해보자.

 

몇몇 문제들은 가식적인 문제가 아닌 실제 도메인에서 도출된 문제를 내기도 한다. (카카오 블라인드 테스트는 그런 점에서 양질의 문제의 보기 좋은 사례라고 생각한다.)

 

개발을 진행하면서 작든 크든 우리는 지속적으로 도메인의 문제를 해결해 나가야 한다.

 

그건 성능일 수도 있고, 요소 간의 관계일 수도 있고, 혹은 명확한 개념들의 관리일 수도 있다.

 

문제 해결 시뮬레이션을 통해서 우리는 지속적으로 문제해결 역량을 자연스럽게 성장시킬 수 있다.

 

나아가 이 과정을 다른 이와 참여하면서 서로의 생각과 관점에 공감하면서 진행한다면 협업 능력도 자연스럽게 올라간다.

 

나는 프로그래머스 사이트에서 내가 푼 문제에 있어서 다른 사람의 문제 풀이를 볼 때 입이 떡 벌어지는 답을 상당히 많이 봤다. 놀라운 순간이었고 이렇게 생각해볼 수 있구나! 하면서 놀란 적이 한두 번이 아니다.

 

이런 과정도 하나하나 공감각적인 협업의 시간이라고 생각된다.

 

코드 리뷰가 자연스럽게 생기는 것이다. "이 부분은 정말 끝내주는데?, 이 부분은 좀 아쉬웠어, 와 어떻게 이렇게 생각하지?, 진짜 깔끔하다 등등.

 

공부할게 상당히 많다는 것을 알지만 

 

개발자라면 문제 해결 시뮬레이션 과정을 피하지 않고 즐길 수 있었으면 좋겠다.

 

나도 정말 힘들지만, 위의 팟캐스트를 듣고 생각이 많이 바뀌게 되었다.

 

이직할 때 누구보다 더 멋지게 검증될 수 있는 모습을 보여줄 수 있고

 

자연스럽게 협업 능력을 향상해주며

 

자연스럽게 기초 역량을 튼튼하게 만들어 자신의 역량의 가치를 높일 수 있다는 것.

 

알고리즘 테스트에 부정적인 감정이 있었다면 이 글을 통해 어느 정도 조금은 해소되었기를 바란다.

 

시간이 된다면 다른 글에서는 왜 우리는 "알고리즘 테스트"를 거부하게 될까에 대한 글을 써보고자 한다.

반응형