안녕하세요, 오늘 오키를보는데 알고리즘(코딩테스트)에 대해 뜨거운감자가 되어있더라구요.. 저도 현재 신입으로서 구직을 하는 입장으로서 백엔드(서버) 포지션으로서 소소히 의견을 남기고 싶어서 불을 지펴볼까 합니다.
Chapter 1 알고리즘? 중요할까?..
일단 저는 제목에도 언급했다 싶이 '알고리즘이 과연 개발에 직접적인 도움이 될까?' 라는 의문을 가진 사람입니다.
알고리즘의 첫 시작은 입시경쟁을 위한게 아닌 장시간 생각을 하면서 남들과 경연을 치루기 위한 대회(정보올림피아드, ACM ICPC 등)가 첫 시발점인걸로 알고있습니다. 하지만 미국 실리콘밸리, 구글에서 시작한 이후로부터 한국에서는 너도나도 도입하기 시작이 된게 알고리즘입니다.
하지만 저는 앞서 말했다싶이 코딩테스트 의문론자입니다. '처음에는 하드코어하게 즐기자' 라는 스포츠적 성격의 알고리즘이 어느순간 토익과 같은 성적지표화가 되어가고 있습니다. 저는 웹개발을 해오면서 저는 BFS, DFS 등 이런 고급기술이 쓰이는 개발은 거의 경험해본적이 없습니다. (만약 알고리즘을 전문적으로 써야하는 개발주제가 있다면 항공권 예약매칭 시스템, 효율적인 메모리 최적화에 고착화된 코드 등에 쓰이지 않았을까 싶습니다.)
그렇지만 이 글을 쓰는 저도 순수한 알고리즘에 다가감에 있어선 아예 알고리즘을 부정할 수는 없었습니다. 효율적인 코드, 서버 자원(CPU, 메모리)을 효율적으로 쓰기 위해알고리즘을 알아야하는건 명백합니다.. 초반에는 알고리즘이 아주 서투른 상태로 개발을 해왔더니 그 결과 SQL N+1이 발생된다던지, 어떤 작업의 알고리즘 개선 전/개선 후 코드에 있어 개선 전의 종료시간이 늦게 끝난다던지(map을 통해 한방에 해결가능한걸 2중포문을 돌렸었음) 하게 되더라구요..
사실 실개발에서 알고리즘이 모호해진게 다음 아래와 같은 이유때문이라고 생각합니다.
1) (서버) 퍼포먼스를 높이기 위해 좋은 오픈소스가 많기 때문인 것 같습니다. 이를테면 Redis 같은거랄까요.
2) 프레임워크 혹은 언어 내에서 메소드(혹은 함수)가 잘 지원되어 있습니다.
하지만 먼 훗날 기업 구직에 있어 코딩테스트는 단시간만에 문제를 풀어내야 하다보니, 여간 스트레스가 장난이 아니었습니다. 그리고 과연 코딩테스트가 먼 미래에 효율적인 코드를 짤 수 있는지에 대한 의문도 듭니다 :
1) 최단시간에 짜낸 코드가 클린코드일까?
2) 지금은 정답이 주어져있어서 그렇지 나중에 동일한 시간+정답을 모르는 상황에서 코딩하라 하면 제대로 해낼까?
3) 코딩에는 많은 테스트가 필요한데, 테스트가 아닌 실제 개발에서 테스트를 제대로 해낼 수 있을까?
결국 제가 개발을 하면서 느낀건
1) 알고리즘과 실전개발은 전혀다른 영역이다.
2) 알고리즘보단 프레임워크를 써봤는지 부터 프레임워크의 활용, 오픈소스의 활용, 에러핸들링 경험, 더나아가 실전개발에 쓰이는 기술(AWS 등)이 더 가치있다고 생각합니다.
였습니다.
Chapter 2 기업
하지만 현실은 기업에서는 '일단 코딩테스트부터 보고 시작하자' 입니다. 아무리 오픈소스, 프레임워크를 잘 쓰며 개발을 할 줄 안다 해도, 코테에서 떨어지면 면접도 못본 채 아웃입니다.
뭔가 면접 때 포폴 개발을 하면서 겪었던 이야기, CS 전공지식, 백엔드 기술론에 대해 이야기를 나누고 싶어서 근질거리는데, 이 발언권을 얻으려면 '코딩테스트 합격' 이라는 티켓이 주어져야 하더라고요.. 이 부분 때문에 좌절감을 겪었던게 한두번이 아니었습니다.
또한 제가 대기업의 신입공채, 경력직(수시모집) 코테 두번 다 본 적이 있는데 두 유형의 난이도가 너무나도 다른걸 보고 느낀게 '결국 알고리즘보단 기술싸움인 것 같다'라는걸 느끼게 됐습니다..
Chapter 3 채용방식의 다양화좀..
기업은 다양한 방식으로 지원자를 채용했으면 좋겠습니다.. 최근에는 프로그래머스에서 일부 회사들이 코딩테스트 전형이 아닌 과제형 방식으로 신입공채를 열기 시작했습니다.
'기간은 약 1달 줄테니, 우리가 주는 기획서를 참고해서 이런 주제의 프로젝트를 만들어와라.' 라는 방식의 채용방식이었는데, 개인적으로 저는 과제형 채용방식이 낫다는 이유는 다음 이유를 꼽았습니다.
1) 기간이 아주 넉넉하다.
2) 지원자가 가진 기술지식을 확실히 볼 수 있다.
3) 운이 좋다면 과제의 피드백도 얻어낼 수 있다. (이를 통해 지원자는 어디부분의 실력이 부족한지 알 수 있다.)
주어진 동일한 상황에 있어 누군가는 사전 구현에 있어 많은 생각을 가졌거나(확장성 등), 느긋한 성격으로 코드를 짜다보니 시간이 오래걸리는 사람이 있는데 이런분들이 어찌보면 코딩테스트가 많이 어려워할 수 있습니다. 하지만 과제형 테스트는 최대한 넉넉한 시간을 주면서도 쓸 수 있는 기술도 거의 무한하다보니 오히려 제 기준에서는 과제형 테스트가 나은 케이스인 것 같습니다.
하지만 과제형 테스트는 사실 경력직 혹은 포폴 위주로 개발을 해본 신입에게나 유리하지, 아예 개발을 접해보지도 못한 신입에게 있어 불리한게 현실입니다.
하지만 그렇다고 '입사시험에 있어 과제형만 도입하자!' 라는건 아니고, 공채든 수시채용이든 입사시험에 있어 코테만 있는게 아닌 과제형도 있었으면 하는 바램이 있습니다.
또 아니면 지원자의 Github 포토폴리오도 보여주는 선택지도 있으면 좋고요!
Chapter4 지금 실무자들은?..
(욕먹을 각오로 글 씁니다.)
이건 좀 조심스러운 얘기이긴 하나, 과거 코딩테스트가 없던 시절 실무자로 오신분중에 대기업 공채 코딩테스트를 풀면 합격자가 얼마나 나올까에 대해서 궁금증이 떠올랐습니다. 17년도 카카오 코딩테스트 합격률 지표를 보면 공채기준 언어 하나당 평균 30%을 웃돕니다. (https://tech.kakao.com/2017/09/27/kakao-blind-recruitment-round-1/)
하지만 신입에게 이런 어려운 코딩테스트를 현직 실무자분들께 풀어보라하면.. 개인적으로 합격률이 얼마나 나오는지 궁금합니다.
Chapter5 궁시렁 궁시렁..
어디 답답함을 호소할데도 없었는데 마침 오늘 오키에서 알고리즘에 대해 뜨거운 논쟁이 오가가지고 제 의견을 표현하면서 다른분들의 의견또한 들어보고 싶어서 글을 쓰게 됐습니다. 긴 글 읽어주셔서 감사하고, 여러분들의 의견도 댓글로 남겨주세요!
정리
1. 코테, 진짜 실무개발과 접목이 될까? 알고리즘을 대체할 좋은 오픈소스, 메소드도 많은데..
2. 알고리즘 지식을 무조건 부정할 순 없다. 알고리즘을 모른 채 코드를 비효율적으로 짜게되면 SQL N+1, 서버자원(CPU, RAM 등) 낭비가 심하다.
3. 코테를 떨어지면 면접관 얼굴도 못보는게 억울하다.
4. 지원자 평가에 있어 공채든 수시채용이든 코딩테스트 하나만 선택지가 아닌 과제형 혹은 Github 포폴 평가도 있었으면 좋겠다..