코딩테스트가 달라져야 한다는 글을 보고 많은 생각이 들어서 썼다.
나는 코딩이 글쓰기를 하는 작가의 관점이나, 문제를 정의 하는 오너의 관점에서는 많이 벗어난 단계라고 생각한다.
대부분 상식처럼 이야기 하는 '무엇이 문제인지 정의만 하면된다 그리고 문제를 정의 하고 푼다'는 개념에서 그 문제라는 것도 예전엔 엔지니어한테 묻는 질문이 '이게 뭐가 문제지?' 누군가가 물었다면 이제는 '이게 문제인데, 이걸 해결해줘'라는 질문을 받는 경우가 많아졌다.
시대가 변했고,
이판에 사람들이 많아졌으며,
그만큼 일이 세분화 되고 있다.
예전에는 프로그래머(굳이 이단어를 가져다 쓰는 이유도 생각해보기 바란다)에게 다 물었다. 제품(서비스라고 하지 않고 제품이라고 하는 이유도 좀 생각해보기 바란다)의 전략(요구사항/제경설계/관계전략등)부터 서비스 운영 C/S까지 다 물었다. 사람이 없거나, 정말로 능력이 출중하거나 해서 이 모든것에 다 답을 할 수 있는 사람도 있겠지만 대부분의 사람들은 그렇지 않다. 그냥 일반적인 능력의 사람이다.
문제는 고민 하지 않아도 되고 ( 또는 이미 누군가 뭐가 문제인지는 고민을 해놨다. 즉 화성을 가야만 하는 것에 대한 고민은 누군가 해둔 상황), 엔지니어들은 잘 만들기만 하면 되는 시기 또는 원래 그러해야 하는데 잘 알려지지 않았거나 여튼 만드는것에만 집중하면 된다.
물론 이런 상황에 거부감을 느끼는 사람들도 많겠지만
나는 이 상황에 느끼는 개인적인 감정들의 합리/불합리 또는 기분나쁨/좋음을 내가 정의 하기 보단 그냥 그런 시대가 되었다고 알려주는 거다. 내가 만들지도 않은 세상이니까. 그리고 뭔가를 원론부터 이야기 하는 시대는 이미 지나갔다(또는 지나가고 있다). 그러다 보니 코더가 컴퓨터를 모르는 시대가 동시에 왔지만 어쨌든 우린 그러한 시대를 살고 있다.
프로그래머가 하는 활동중에 코딩이 있다. 코드를 입력기를 사용해서 넣는 단계다. 그리고 난 코드를 입력해서 넣는 방법이 이제는 많은 부분 공통화 되어 있다고 생각한다. 라이브러리, 프레임워크 들이 이러한 역할을 해내고 있고, 편리에 의해서 나온 이런 프레임워크들도 이제는 복잡해져서 편리와는 좀 거리가 있지만 주저없이 쓴다. 이를테면 자바라는 언어로 코드를 입력한다 라고 할때 다들 '아! 스프링 쓴다는 이야기 구나' 또는 '스프링 부트를 쓴다는 이야기 구나'라고 생각하지, 아무도 워드패드에서 자바를 막 입력하는걸 생각하지 않는다. 그리고 이 순간 부터는 자바라는 표준(자바 만든 제임스 고슬링은 자바언어를 공개하면서 자기가 만든 표준의 구현체 라고 했고, 그 표준도 같이 공개했다. 오라클 자바, 오픈 자바, 코레토 자바가 구현체다)을 사용하는게 아니라 스프링 이라는 피보탈 제품을 쓰는거다.
그리고 대부분의 코딩 지식이란 이 피보탈 제품의 사용법과 관련이 있다(적어도 스프링으로 시작하는 애들을 사용한다면 말이다). 이미 지식이 어느 정도는 제한된 상태의 제품에 대한 정보와 해석이 되었다. 그래서 이렇게 이야길 한다. '우리가 만들 이번 제품에선 스프링에서 이 기능을 , 새로운 버전의 스프링에 들어간 이 기능을 ...' 뭐 이런식으로 공리화 되었고 '이번 기능은 성능이 어느정도 나와야 해요 그러니 요 통신 방식이나 요런 알고리즘을 씁시다(또는 씁니다)'로 이야기 할때 거부감이 드나? 오히려 굉장히 전문가 처럼 느껴지며 자바/스프링의 달인처럼 느껴진다.
아주 아주 예전에는 numerical recipes in C(C++, Java, Python)같은 책을 옆에 두는게 프로그래머의 기본 또는 자랑 또는 예의었다. 그때 부터도 알고리즘은 레시피 수준이었지(가져다 쓴다는 의미고, 모두가 사용한다는 의미 정도다, 비난/하대 아님). 그 이상도 이하도 아니었다.
말은 길었지만, 이미 코딩이라는 활동이 있는거 가져다 쓰는(최적화이기도 하고, 그것도 어렵다 ㅡㅡ. 분명하게 이야기 했다. 어렵다고 ㅡㅡ+) 형태 이기 때문에 기능/지식/정보를 단위별로 묶어서 넣고 있다. 코팅 자체가 이렇게 달라졌기 때문에, 코딩 테스트 역시 그에 따라 바뀌었다. 코딩 테스트 자체가 바뀐게 아니라 이제야 이런 형태의 코딩 테스트가 진행되고 있다는게 더 좋은 설명인것 같다. 주로 알고리즘을 묻는거긴 하지만, 그 짧은 시간에 CS를 다 물어볼 수도 없다. 문제에 대해서 적절한 알고리즘을 가져다 쓸 수 있는지 정도를 체크 하는거지. 코딩점수로 그 사람의 능력을 다 평가할 수 없지만, 어느정도 필터링은 가능하다.
자 나는 이렇게 바꿔보길 원한다 코딩 테스트 대신에 수학시험이라고 단어를 바꾸면 어떻게 될까?
1. 모든 시험에는 정답이 있다.
실제로 인터뷰에서 물어봤던 질문중에 '수학에 왜 자유가 있다고 생각하냐?'였다. 응시자 분이 수학을 좋아하는데 거기에 자유가 있다고 이야기 해서 물어봤다(내가 먼저 저런 질문을 하지 않는다). 그 분의 대답은 다양한 방법이 있기 때문이라는데, 나도 박사과정을 2개까지 하면서 수학은 좀 해봤는데 수학에는 다양한 방법도 없지만, 있다 하더라도 정답은 있다. 어떤 형태의 방법이던 답이 0 이라면 0이 나와야 한다. 그렇지 않다면 수학이 아니다 또는 정말 새로운 이론을 만들어 내는 건데, 공리/정리들로 똘똘 뭉쳐진 2000년도 넘는 역사를 가진 수 의 학문을 깨긴 어렵다. 코딩도 마찬가지다. 알고리즘을 공식처럼 생각한다면(실제로 공식이다 라고 나는 생각한다), 어떤 공식을 써서 문제를 해결하느냐는 분명있다. 그리고 그걸 코딩테스트로 낸다.
2.시험은 빨리 치뤄야 한다.
수학 공식을 유도해서 푸는 사람들이 과연 있을까? 내가 봤던 공업수학 시험은 3시간동안 푸는데 공식을 유도하는게 아니라 있는 공식을 답지에 손으로 적는데만 3시간이 걸린다. 거의 외우는 아니 다 외워야만 그 시간에 풀수 있다. 교수님은 자정까지도 시간을 준다고 하지만 3시간안에 못적는 건 공부량이 부족해서다.
갑론을박이 있지만 공부량이 많아지면 수학공식을 외우게 된다. 수학 공식을 외우는건 결과적인 거다. 거기에 창의성이나 뭐 이런게 있나? 어차피 외우는거 푸는건데? 그런데 느리게 푼다? 원리를 생각하고 푼다?
코딩테스트도 마찬가지다. 코딩 테스트에서 낼 수 있는 문제는 굉장히 제한적이고, 대부분 패턴화 되어 있다. 정말로 문제집한권정도 사서 잘 보면 거의 대부분통과할 수 있을정도로 다 알려져 있다. 그런데 통과를 못한다면... 아무리 경력자라도 그냥 정성의 부족정도로 밖에 가늠할 수 없다. 절대 능력 부족은 아니란거다. 물론, 코딩테스트 문제집을 이해할 수 없는 정도의 지식을 가지고 있다면 이건 완전히 다른 이슈이긴하다.
3.품질
빨리 푸는 수학 문제에서 퀄리티를 아무도 보지 않는다. 그리고 수학시험과 달리 입사용 코딩테스트는 이후 면접시간에 이런 질문을 반드시 한다 '시간의 여유가 좀 있다면 어떻게 바꿔보고 싶어요? 또는 이 코드에서 어떤 부분을 개선하고 싶으세요?' 식으로 시간에 구애 받지 않으면 해보고 싶은것들을 물어본다. 그 과정에서 오히려 당락이 결정되는 경우가 흔하다.
4.어려운 문제는 변별성이 아주 높다.
수학 시험에서 어려운 문제를 내면 잘하는 사람과 못하는 사람의 차이가 현격하게 난다. 이걸 입사용 코딩테스트에 적용해도 마찬가지다. 대신 이렇게 되면 통과하는 사람들이 확 줄기 때문에 회사 입장에선 사람을 뽑을 수가 없게되어서 늘 줄다리기를 한다. 그렇다고 더 쉽게 내진 않지만 반대로 더 어렵게 내려고 하지도 않는다.
5. 직업적으로 필요하진 않다?
이것도 갑론을박이 있지만, 수학이 과연 직업에 필요한가?를 묻는 것이랑 같다. 아니다 다르네. 코딩에 들어가는 기술들은 직업적으로 분명 필요하다. 좀 더 정확하게 이야기 하면 어느정도는 분명 필요하다. 써먹을 일들도 생각보단 꽤 많다. 코딩이라는게 결국은 루프들을 어떻게 효율적으로 푸는가에 대한 또는 중복을 어떻게 제거 하는가에 대한 '방법'들이기 때문이다. 그리고 이 코딩이라는건 결국 이 방법들의 연결 또는 결합 또는 조합인 시대가 되었다. 수학은? 글세 공대에서 공업수학 2를 '필수'가 아닌 선택이 되어 버린 시대에 직업에 필요할까? 수 많은 프로그래머들이 믿는것과 달리 프로그램에서 사용하는 '수학'은 사칙연산 외엔 몇 개 없다. 그리고 코딩과 수학은 본질적으로는 아무 관계가 없다. 혹시 4칙연산을 수학이라고 한다면 또 모르겠다. 프로그램으로 BLAS나 Matrix Solver를 만든다면 또 모르겠지만 MKL같은거를 아무 거리낌 없이 가져다 쓰는 시대에 이걸 만드는 사람이 몇이나 있을까? 한때는 그런걸 다 만들어서 썼다 한 40년전쯤.
과제형으로 코딩테스트를 대체? 과제형의 폐단(선별기준, 문제의 난이도, 대부분 도메인 문제 즉 경력이 필요) 때문에 간단한 코딩 테스트로 바뀐거다.
두괄식 미괄식으로 다시 한번 코딩이 이렇게 기존것들 가져다 써서 원하는 형태로 동작하게 하는 것으로 바뀌었고, 그러다 보니 현재의 코딩 테스트들이 적당한 알고리즘을 선택하게 해서 정해진 시간안에 정답을 써서 내는 형태로 정착하게 되었다는 것이다.
이런 세태에 대해서 내가 가지는 불만/만족과는 별개로 세상은 그렇게 정착되어 가고 있다.
'O2, 엔지니어링 season2' 카테고리의 다른 글
WWDC 23, apple vision pro, 공간 아마추어 (1) | 2023.06.06 |
---|---|
GPT, Nocode, 사라짐,변화 (0) | 2023.06.03 |
멸공과 편익분석 (0) | 2022.01.12 |
KT 장애에 부쳐서. (0) | 2021.10.30 |
GPU를 활용한 분산 컴퓨팅 프레임워크 성능 개선 연구 (0) | 2021.04.26 |