나는 'K' 코딩 테스트가 싫어요

이것이 'K' 코딩 테스트다

최근 클럽하우스에서 개발자 지망, 진로에 대해 모더레이터로 참여하고 있으면서 비전공과 학원, 자격증 등 여러 문제를 논의했지만 그중 내가 가장 문제의식을 느낀 것은 개발자로 '취직'을 하기 위해 장벽인 코딩 테스트 부분이다. 물론 해외에서도 코딩 테스트는 진행 중이며 이것은 우리나라에 국한되는 것이 아닌 글로벌하게 기업에서 진행되고 있다는 것을 알고 있다. 문제는 한국의 코딩 테스트가 외국과 태도가 다르다는 점이 우려스러울 따름이다.

 

나는 코딩 테스트가 싫다. 정확히는 한국식 코딩 테스트가 싫다. 요즘에는 앞에 'K' 를 붙이는 것이 유행하던데 코딩테스트에도 한 번 붙여서 'K' 코딩 테스트라고 하자. 코딩 테스트의 모든 것을 부정하는 것은 아니지만, 내가 코딩 테스트를 싫어하는 이유가 몇 가지 존재한다. 먼저, 한국은 시험(Test)에 죽고 시험에 사는 나라. 그러한 문화는 코딩 열풍이 불면서 코딩 테스트로 넘어왔다.

 

공시에 매달리고 수능이라는 단 한 번의 시험으로 대학이 결정되고 그것에 대부분 진로, 인생을 순응하며 사는 국가. 테스트라는 말 자체를 자격의 증명보다는 다른 사람보다 우수, 줄 세우기로 여기는 성향. 얼마 전 유머를 살펴보다가 어느 한 고등학교에서 코드의 품질에 대해 효율성이 아닌 그저 단순 타이핑 속도로 코딩 수행평가 점수를 메겼다는 글을 보았는데, 한 마디로 말하면 어이없는 상황. 그래서 '유머' 탭에 있었던가?

 

교육을 가르치는 교사조차 코딩, 정확히는 개발에 대한 이해가 부족한 상태로 임하고 있는 실정에 제대로 된 테스트를 기대하는 것조차 문제다. 우리나라는 무엇이든 고시화시키려는 경향이 있다. 문제를 기계식으로 풀어낸다. 방법에 관계없이 그저 정답만을 추구하는, 그런 식의 교육이 너무나도 익숙해져 버린 탓에 코딩도 그렇게 된 것이다. 나는 이런 것을 코딩 테스트를 연습하면서도 느꼈다.

 

코딩 테스트는 고시화되어 수능시험처럼 제한시간 안에 주어진 문제를 풀어내는 것으로 변질되어 버렸다. 그래서 어딘가에서는 '타이핑 속도' 따위 같은 것에 점수를 부여하는 수준까지 와버렸다. 악착같이 반복해서 풀어내면서 문제가 주어지면 기계처럼 자동으로 응답하는 수준까지 되며 단골로 나오는 패턴과 같은 경우에는 코드를 통째로 외우는 경우도 보았다. 그렇게 하면 실제로 빠른 속도로 정답이란 걸 낼 수 있으니까. 코딩 테스트의 목적이 그저 '시험'이라는 것에 국한한다면 그래도 된다. 아니, 그 방법이 고득점을 위한 시험에는 더 적합한 방법이다.

 

정말, 이 현상을 개발이라고 할 수 있는가?

 

말 시키지 마세요

고시화 되어버린 코딩은 질문이 결여되어 그저 주어진 시간에 문제에 대한 정답만을 찾는 기계로 전락한다. 그 방법론 자체에 대한 사유 없이 정답에 집착한다. 개발자는 문제가 주어지면 해당 유형을 찾아 정답을 찾아 적용시키는 직업이 아니다. 매번 다른 비즈니스 상황과 기술 스택에 따른 유연함과 사고가 필요하다. 하지만 우리나라는 질문하지 않는다. 심지어 이미 문제에 많은 것이 나와있어서 질문할 생각도 안 하게 한다.

얼마 전 애플의 한 개발자와 이야기를 나눈 적이 있다. 코딩 테스트에 대한 의견을 물으니, 코딩 테스트 자체는 부정하지 않지만, 다른 점이 있다면 그들은 정답이 아닌 과정을 본다는 이야기였다. 심지어는 물어보는 사람도 정답을 모르고 던진다고도 한다. 나는 여기에서 한국과는 너무나도 다르다는 것을 느꼈다. 과정이라면 어떤 것을 이야기할까? 여기서 말하는 과정이란, 이 사람이 해당 문제를 풀어감이 있어서 어떠한 접근방식을 취하는지를 말한다. 오히려 그들에게 '정답' 은 크게 중요하지 않다.

 

나는 처음에 이를 리팩터링(Refactoring)으로 착각했다. 하지만 리팩터링은 이미 정답이 있는 상태에서 코드를 개선하는 것이므로 그들이 말하는 '과정' 과는 다른 이야기임을 깨달았다.

 

비행기 안에 탁구공이 얼마나 들어갈까요?

 

이 질문에는 어떠한 전제도 안 붙어있다. 어떤 비행기인지, 어떤 탁구공인지에 대한 것도 없다. 어떠한 방법을 쓰라는 것도 명시되어 있지 않다. 필요하다면 구글에 검색을 해봐도 된다. 주어진 질문에 많은 것이 빠져있어서 되려 우리가 질문을 해야 한다. 하지만 영상에서도 나와있듯, 한국식 교육은 정답을 먼저 찾으려 하는 성향이 있어서 질문 없이 이미 머릿속에 전제를 깔고 간다. 해당 문제가 주어진 비즈니스 상황의 고려가 전혀 없는 상태로 개인의 머릿속에서 상상을 하며 문제를 풀기 때문이다.

 

한국의 흔한 초중고를 나온 나는 교실에서 수업 중에 질문하면 속된 말로 '나댄다' 고 하며 친구들이 비아냥하거나 눈치를 주는 경우가 많았고, 게다가 '틀릴 수도 있다'는 그 사실조차 두려워 안 한 적도 많았다. 그때는 '그래, 틀릴 수도 있지'라는 마인드로 접근하지 못했다. 왜냐, 한국 교육에서 '정답'이 아닌 것을 이야기하면, 남들에게서 오는 시선이 두려웠기 때문이다. 한창 대인관계에 민감했을 청소년기였으니 더 그랬다.

얕은 질문의 답은 책에, 두꺼운 질문은 생각하자

그저 정답에 급급한 코딩 테스트는 사유하지 않는 개발자를 양성한다. 마치 수학 문제은행 풀듯이 해당 유형의 문제가 나오면 기계적으로 어떤 알고리즘을 적용시켜 정답을 찾는다. 코드가 공식화 되어버리는 터무니없는 일이 발생한 것이다. 클론 코딩을 하면서도 강사자가 적어놓은 코드를 '정답'이라고 여겨 코드가 그 형태에서 벗어나질 못하고 그대로 머무는 것을 보았다.

 

내가 그토록 고민했지만 개발을 그만두지 않는 이유 중 하나는 하나의 문제에 대해 여러 해결책이 있다는 것이다. 그중에도 좋고 나쁜 코드가 있는 것인데, 그것을 공식화시켜버리면 아무런 창의성도 발휘되지 않고 문제가 주어지면 유형을 찾아 그저 똑같은 코드만 적는 바보가 된다. 내가 그래서 학교에서 배우는 수학이 싫었던 것이었나 보다. 중학생 시절 아무런 이유도 가르쳐주지 않고 그저 외우라던 '곱셈 공식' 과 '근의 공식' 이 너무 싫었다. 그저 정답만을 추구하면 그 알고리즘을 왜 써야 하고 어떤 점이 좋고, 코드를 어떻게 더 좋게 개선할 수 있는지는 크게 중요시 여기지 않는다.

 

여기서 '좋게'라는 것은 그저 알고리즘의 시간, 공간 복잡도를 이야기하는 것이 전혀 아니다. 문제에 대한 테스트케이스, 컨벤션, 변수와 함수 작명, 더 나은 코드의 구조와 유지 보수하기 쉬운 코드와 같이 여러 고려해주어야 할 것들이 많음에도 불구하고 다 필요 없이 정답과 복잡도만 해결된다면 이를 '정답'이라고 한다. 사실 정답이라고 정해놓는 것조차 싫어한다.

코드로 예술을 하려 들지 마라?

똑같은 문제에 대해 코드를 함수며 객체며 아무것도 하지 않고 변수 이름을 그저 a, b, c 라고 처리한 것과, 그와 반대로 변수 및 함수의 이름을 의미있게 짓고 코드를 구조적으로 설계한 것이 있는데, 결과가 같다면 이를 기계적으로 채점하는 코딩 테스트라면 둘 다 '정답'이다. 똑같은 입력을 넣고 기대하는 출력이 나왔기 때문이다. 아니, 어쩌면 전자에 더 높은 점수가 나올지도 모른다. 코드의 길이가 짧아지기 때문이다.

 

결과가 같으면 그것을 나타내는 과정 따위는 무시된다. 하지만 상식적인 상황이라면 당연히 후자에 더 좋은 점수를 주어야 한다. 기업이 개발자를 클라이언트의 관점에서 채용하는 것이 아닌 이상 말이다. 나는 코드란 게 단순 알고리즘의 시간, 공간 복잡도로만 판단할 수 있는 거라고 생각하지 않는다.

 

이 경우 개발 속도는 후자가 더 느릴 수도 있다. 개발의 속도가 중요한가? 미래에 감당해야 할 더 큰 비용을 감수하면서까지? 만약 프로그램을 고객에 납품해야 하고 일정이 빠듯하다면 기업이라면 속도는 중요할 수 있다. 그러면서 누군가는 코드로 예술을 하려 들지 말라는 말을 하는데, 결코 공감하지 않는다. 이해하고 싶지 않다. 현실과는 관계없이 이상을 추구하는 것이 인간이다. 코드의 구조를 찾아가며 고민하고 사유하며 짜는 것은 그저 현실과 동 떨어진 동화 속 세상일 뿐이라고 말하는 사람들이 싫다.

 

과거에 어느 회사에 입사 후, 외주를 맡겼다던 프로그램을 받아 본 적 있다. 그 프로그램은 그저 '동작'만 하는 프로그램, 어떠한 입력을 넣으면 기대하는 결괏값이 나오는, 여기서 말하는 '정답'인 것이었다. 하지만 그 프로그램은 태초 설계에서부터 발생한 데이터베이스의 구조, 소스코드가 엉망이어서 납품받은 뒤 1년 정도가 지나자 큰 문제가 발생했고, 결국에는 사내 데이터에 손실을 일으켜 제작사 측에서 큰 배상을 해야 하는 문제에 직면했다.

 

눈앞에 주어진 당장의 '정답' 만을 추구하고 '과정' 은 무시한 끝에 시간에 쫓겨 소탐대실(小貪大失)이 발생한 것이다. 이 문제에 대해 직접 문의해보고 코드를 보여주니 '전부 뒤집어야 한다'라고 했다. 본인들도 그 문제를 이미 인지하고 있었다는 증거다. 기계적으로 템플릿을 적용하거나 그들이 말하는 '프로그램', 그러니까 '정답' 만을 고려한 상태에서 코드만 국수처럼 뽑아대는 것은 성장하는 개발자가 될 수 없다고 생각한다. 많은 이들이 가고자 하는 기업에서는 그런 것보다는 설계와 같은 가치를 더 중요시 여긴다. 나는 이런 이유로 'K' 코딩 테스트를 싫어한다.

더 읽을거리

개발자의 연봉 상승 모멘텀, ―그리고 환상

당신의 클론 코딩, 안녕하신가요?

프로그래밍 언어를 선택하고 공부하기 위한 팁, ― 개발자가 되고 싶은 당신에게