[개안뽑] ㊵개발자 채용 기준은 코딩 테스트가 아니라, 논리학 시험이어야 한다

pabii research
코딩 테스트로 개발자 선발하는 IT기업들 많았으나 최근들어 논리학 시험으로 내용 변경 중
암기로 실제 실력을 숨길 수 있는 문제 탓, 논리학 시험은 암기 영향 적어
실제 기업이 원하는 인재는 '똑똑한 인재'이지 코딩 테스트를 많이 암기한 인재 아냐

Data Scientist로 면접을 보던 시절에 한국에 널리 알려진 ‘코딩 테스트’라는 걸 처음 본 적이 있다. 갑자기 날 더러 C언어로 물을 1/1부터 1/10까지 다 채워넣는 가장 효과적인 코드를 짜라고 하던데, 그 경험을 다른 분들과 공유하니까 거긴 Data Scientist를 뽑는 곳이 아니라, 개발자를 뽑는 곳이라면서 그런 직장들을 다 피해서 지원해라는 추천을 들은 적이 있다.

그 외에 면접 중에 ‘코딩 테스트’와 가장 비슷한 경험을 겪은 것은 순서도(Flowchart) 그리기다. 초등학교 시절에 잠깐 배웠던 경험을 바탕으로 조건식들을 표현하면서 내 논리를 설명했었는데, 당시 면접관들이 나의 순서도 관련 지식을 확인하려고 했던 것이 아니라, 내가 어떤 논리로 생각을 하고 있었는지, 그걸 얼마나 잘 설명하는지를 볼려고 했었다고 생각한다.

요즘 한국에서 개발자를 채용한다는 많은 대기업들이 그 시절 내가 뒤돌아 보지도 않았던 기업들의 코딩 테스트를 그대로 갖고와서 직원을 선발하는 걸 보면서 여러 생각이 든다. 다른 옵션이 없는 지원자 입장에서 울며 겨자먹기로 준비해야 할 수도 있겠지만, 논리적 사고력을 바탕으로 한 코드 설계가 핵심이지, 어디에선가 봤던 문제들을 달달 암기해서 빠르게 쳐 내려가는 것이 목적이 아닌 과정이어야 하는데, 한국에 들어온 모든 해외 시스템이 그렇듯이 코딩 테스트로 ‘한국식 열화’가 되고 있는 것이 눈에 보이기 때문이다.

개발자-안-뽑음_202312
개발자-안-뽑음_202312

개발자 채용 기준은 코딩 테스트가 아니라, 논리학 시험이여야 한다

지난 몇 년간 개발자들을 뽑아보면서, 개발자를 굳이 다시 한국에서 뽑아야 한다면 딱 3가지 시험을 치뤄야겠다는 생각이 정리됐다.

  • 논리학 시험
  • 학습 속도
  • 문제 해결능력

이 중 가장 핵심은 논리학 시험인데, 코드 작업은 논리적 사고에 따른 글 쓰기와 크게 다르지 않다는 내 경험적 지식을 내재화한 인재를 뽑고 싶기 때문이다. 예를 들어, 모든 함수 내부에 동일한 변수를 지정한 탓에 함수 종료 선언문을 안 하고 다른 함수가 실행됐을 때 결과값이 엉망으로 나오는 상황을 피하려면 함수의 시작과 끝을 선언해야한다는 꼼꼼함이 중요하기 이전에, 논리적으로 어떻게 함수를 구성해야 하는지를 함수 1개 레벨이 아니라 함수 N개가 묶인 라이브러리 레벨, 라이브러리들을 묶은 프로젝트 레벨에서 이해할 수 있어야 개발 업무를 할 수 있지 않을까?

단순한 코드 베껴 붙이기를 하는 분들에게는 특정 프로젝트를 해 본 적이 있는지 여부가 중요하겠지만, 내가 도전하는 대부분의 IT개발은 한국 땅에서 해 본 경험이 있는 사람을 찾기 어려운 프로젝트들이 많다. 해 봤다고 주장해도 몇 마디를 나눠보면 내가 원하는 수준의 깊이까지 들어가 본 적도 거의 없고, 무엇보다 여러 작업 결과물들을 결합해서 안정적인 서비스를 만들어 낼 수 있는 역량이 있는지에 대한 근본적인 의구심이 드는 경우들이 대부분이었다.

이런 분들이 단지 경험치가 있다는 이유로 뽑을 것이 아니라, 차라리 논리적으로 사고력이 탄탄하게 갖춰져 있는 인력에게 결합 작업을 진행해라고 하는 것이 더 효과적이라는 것이 내 결론이다.

논리력을 기르는 방법은?

지식을 기르는 방법이 아니라 논리력을 기르는 방법이 있을까? 타고나는 것은 아닐까? 질문 및 답변으로 유명한 Quora에 프로그래머가 논리적 사고력을 기르려면 어떻게 해야할까는 질문 (How to develop my logical thinking in programming and software creation – Quora)에는 아래의 10가지를 추천하는 답변이 최상위에 등록되어 있다.

  1. 논리적 사고력을 키워주는 퍼즐을 많이 풀어라 (Practice Puzzles to Improve Logical Thinking)
  2. 프로그래밍 언어로 코드를 직접 작성해라 (Write and Code in the Programming Language)
  3. 복잡한 문제를 코드를 쳐서 직접 풀어봐라 (Try to Solve Simple to Complex Problems by Writing Codes)
  4. 조건적으로 사고해라 (Think Conditionally)
  5. 체스, 큐브, 스도쿠 같은 문제로 두뇌 훈련을 해라 (Exercise your Brain by Playing Chess, Rubik’s Cube and Sudoku)
  6. 삶의 태도를 바꿔라 (Change your Lifestyle)
  7. 복잡한 문제를 간단한 문제로 바꿔라 (Break Complex Problems into Simpler Problems)
  8. 다른 프로그래머의 코드를 읽고 이해해라 (Read and Understand Other Programmer’s Codes)
  9. 프로그래밍 언어와 알고리즘에 관한 자료를 많이 읽어봐라 (Read Plenty of Resources on Programming Language and Algorithms)
  10. 책을 읽어라 (Read Books)

사실 코딩 테스트는 위의 추천 사항 중 1~5, 7~9번 작업을 얼마나 많이 했는지에 따라 큰 영향을 받을 수 있다는 점에서 한편으로는 맞는 점검 방법이다. 그런데, 왜 코딩 테스트가 적절하지 않은 검증 방법이 됐을까?

코딩 테스트 문제가 유출됐고, 나올 수 있는 문제가 그렇게 많지 않은데다, 지원자들이 모범 답안 코드들을 통째로 암기하는 사태가 발생하기 때문이다. 목표에 맞춰 합리적인 과정을 골랐는데, 정작 그 시험을 잘 보는 사람들은 ‘속이기(Cheating)’ 작업을 한 사람들이 되어 버리는 것이다. 문제가 유출되더라도 나올 수 있는 문제가 헤아릴 수 없이 많으면 이런 부작용이 해결되겠지만, 코딩 테스트 문제를 그렇게 무한정 찍어내기는 쉽지 않다.

논리적 사고력을 점검하기 위해 인류는 오랜 기간 동안 철학이라는 학문을 발전시켜왔고, 그 철학에 기반해서 수 많은 학문들이 논리적인 결과물들을 만들어 냈다. 면접 중에 내가 썼던 논문을 설명하고, 중간중간에 왜 그런 생각을 하게됐는지 논리적으로 답변할 수 있는 역량을 보면서 나를 뽑을 수 있는 인재인지 판단하는 것도 역시 그런 역사적 전통에 기반한 과정이다.

단지 코딩 테스트는 그 역사가 너무 짧고, 때문에 너무 제한적인 범위로 국한된 탓에 적절한 검증 작업을 해내지 못하는 것이다.

사실 논리적인 것은 머리가 좋은 것이다

귀국 후 지난 몇 년간 대치동 일대의 학원가에서 ‘쪽집게 과외’ 방식으로 교육 받은 인재들이 여전히 유명대학 문을 뚫고 들어가기 쉬운 상황이 계속되는 걸 보면서, 한국 교육 자체가 위의 코딩 테스트와 유사한 문제를 겪고 있다는 생각을 하게 됐다. 누군가는 혼자 고민하는데 오랜 시간을 써야 겨우 따라갈 수 있는 내용을 엄청난 천재들은 순식간에 파악해 버리는데, 그런 시간 단축 작업을 논리적 이해를 생략하고 암기로 대체해버리는 것이 국내 ‘쪽집게 과외’ 교육 방식인데, 이런 폐해가 있으면 시험을 통한 교육 습득 역량 구분은 실패할 수밖에 없다.

말을 바꾸면, 아주 머리가 좋아서 혼자 힘으로 모든 지식을 깨우치는 학생과, 부모의 재력이 지원해준 암기식 학원으로 지식을 머리 속에 ‘입력’하는 학생 간에, 시험 점수라는 영역에서 차이는 거의 사라지는 것이다. 실제 두 학생의 잠재 능력은 하늘과 땅 차이일지라도, 시험 점수는 그 구분을 해내지 못한다.

좀 더 솔직하게 짚으면, 사실 시험은 머리가 좋은 학생이 얼마나 열심히 공부했는지를 구분해내기 위해 진행하는 절차다. 코딩 테스트는 평소에 얼마나 열심히 공부했는지를 따지기보다, 머리가 얼마나 좋은지, 그래서 얼마나 논리적으로, 그것도 빠른 속도로 생각할 수 있는지를 따져보는 확인하는 절차에 불과하다.

명목은 코딩 테스트지만, 사실은 두뇌 회전이 얼마나 빠르고, 그 빠른 회전이 얼마나 논리적으로 돌아가는지를 따지는 작업을 하는 과정인 것이다. 단지, 코드 작업을 많이 해야하니까 그 검증 작업을 코딩으로 진행했던 것인데, 암기라는 ‘반칙’이 효과적인 테스트를 방해하는 만큼, 어쩔 수 없이 새로운 문제를 끊임없이 만들어내거나, 더 근본적인 검증 방법을 골라야 한다.

많은 IT회사들이 요즘들어 코딩 테스트 대신 논리학 시험 점수로 1차 지원자를 거르는 것도 같은 맥락이다. 논리학 문제들을 다 암기하고 시험을 치를 수 없을만큼 논리학 문제들이 많이 쌓여있고, 다 암기한다고 해도 문제를 조금씩 바꾸기에도 용이하기 때문이다.

긴 시행착오 끝에 나도 논리학 시험으로 인재를 선발하게 됐다. 짧은 시간 안에 얼마나 많은 논리학 문제를 얼마나 빠른 시간 안에 풀어낼 수 있느냐가 결국은 그 인재의 잠재력을 판단하는데 가장 좋은 잣대라는 것을 알게 됐기 때문이다.

다른 회사 코드를 그대로 베끼는 작업을 할 것이 아닌 다음에야, 개발자를 채용할 때도 같은 방식으로 선별하는 것이 맞지 않을까 한다.

Similar Posts