by
Jun 30. 2019
알고리즘이 필요한 '진짜' 이유에 대해서
왜 우린 코딩 테스트에 노예가 될 수밖에 없는 걸까?!
이번 글의 주제는
아주 핫한 이슈
알고리즘의 필요성
이 문제를 다루려고 합니다.
너무나 뜨거운 논쟁의 소재인지라,
다루기가 너무 어렵지만
아직도 여전히
알고리즘 쓸데없다 VS 알고리즘은 필수다
이 지속되는 두 가지 논쟁에 대해서
분석해 보려고 합니다.
우선 이 두 가지 시각이 온도차가 생긴 이유가
있습니다.
그건 알고리즘의 실효성의 문제입니다.
알고리즘이 어느정도 필요하고 기업에서는 얼마나 자주 알고리즘 능력을 필요로 한가?! 이 과목, 알고리즘 능력의 향상이 업무능력을 얼마나 향상 시킬 것인가?
사용하는 DB, 프레임워크, 프런트 개발 실제 업무에서 알고리즘이 사용되는 부분이 거의 없는 경우 알고리즘이 필요하지 않다고 여겨질 때 도 있습니다.
알고리즘 테스트를 통과하고 코딩 능력이 좋은 것과
실제로 문제를 검색하고 문제를 찾아내고 해결하는 과정에 대한 능력은 조금은 다른 능력이긴 합니다.
따라서 일을 해본 사람의 입장에서
알고리즘을 잘하는 능력만으로
코딩을 잘한다. 혹은 일을 잘한다. 또는 그렇지 않다고 평가하기는 매우 모호하다는 사실을 체감하고는 합니다.
그럼,
그럼에도 불구하고 왜 기업은 계속 알고리즘 테스트를
도입하려고 하는 것일까요?!
그리고 그것이 가져다주는 유익은 무엇일까요?
만약 알고리즘을 공부한다 하더라도,
왜 알고리즘이 필요한지 이해가 없이 그냥 알고리즘만
공부하다가는 실제 알고리즘을 써먹기 어려울 뿐 더러, 회사에 입사한 이후에도 알고리즘을 사용하지 않는다는 이유로 업무 자체에 실망감을 느낄 수도 있습니다.
알고리즘이 필요성에 대한 두 가지 입장에 대한 차이를
설명하고, 또 두 결론을 종합해 보도록 하겠습니다.
알고리즘이 필요한 입장
기업의 목적(업계의 현실)
기업 입장에서는 왜 알고리즘이 필요할까요? 좋은 기업으로 특징되는 많은 기업들은 신입, 경력 관계없이 알고리즘을 검증하는 단계를 도입하고 있습니다. 그렇다면 왜 그렇게 기업 입장에서는 이런 검증 단계를 도입하려고 하는 것일까요?
실상 기업의 입장에서 살펴본다면, 알고리즘을 도입하는 이유의 또 다른 이면은 업계의 불확실성의 증가입니다.
"아니, 알고리즘은 똑똑한 사람 뽑으려고 하는 거 아닌가? 업계 불확실성은 무슨 상관?" 이렇게 이야기할 수 있습니다. 일단, 업계라는 용어는 IT 대기업, IT 중견기업, 중소 하청을 포함, 스타트업도 포함할 수는 있을 것입니다. IT 업계에서 억대 연봉자들이 나오는 컨셉들이 발생하고 있기 때문에 표면적으로는 전체 업계가 잘되고 있다고 느낄 수 있습니다만, 여러 가지 법과 관련된 이슈 등등으로 큰 ICT 기업의 입장에서는 규모를 유지하는 부분에 많은 어려움들이 생기고 있습니다. 따라서 발주 규모가 축소되니 자연스럽게 정규직이든 비정규직이든 하청이든 프리든 모두 규모가 작아지는 겁니다.
이렇게 불확실성이 증가하게 될 경우 회사 입장에서는 성장보다는 안정과 유지라는 옵션을 선택할 수밖에 없습니다. 회사들이 성장하는 시점에는 성과에 따라 혹은 능력에 따라 차등적으로 옵션을 주고 공격적으로 사람을 영입할 수 있습니다만, 회사의 규모가 어려워지는 시점에서는 새로운 사람을 뽑는 것은 이래저래 여간 리스크일 수밖에 없습니다. 첫 번째는 신입을 뽑지 않는 것이고, 두 번째는 경력의 규모를 줄이는 것입니다.
하지만 이렇게 된다고 해서 산업의 특성상 퇴출을 감행하거나 아예 사람을 줄일 수는 없습니다.
이런 근거로 사람을 뽑을 때는, 조금 뽑아야 하고 어렵게 뽑아야 합니다. 그리고 고과의 결정도 다수에게 이익이 돌아가게 하는 게 아니라, 잘한다고 여겨지는 몇몇에게로 돌아가게 해야 합니다. 그렇기 때문에 이런 SW검정 시험 같은 것들이 활성화되고 검증의 요소로 생겨나게 된 부분도 있는 것입니다.
트렌드 반영
기존의 큰 ICT 회사의 입장에서는 여러 다른 성장하는 IT 기술기반 스타트업의 성장이 크게 달갑진 않습니다. 그 회사들이 정부의 발주나 큰 기업들의 발주를 가로채는 것은 아니지만, 결국 능력 있는 개발자들 중 많은 개발자들이 ICT 회사와 같은 SI 성 운영 및 개발회사에 가려고 하기보단, 좀 더 개발에 집중하는 곳을 가려고 하기 때문입니다. 첫째로 전문성, 둘째로 복지와 문화, 셋째로 미래 이 3가지 이유 때문에 각각 IT 업계의 핫한 기업들은 초봉이 천정부지로 올라갑니다. 이런 트렌드를 반영해서 큰 기업들도 초봉이 올라갈 수밖에 없고 또한 그 IT 기반 회사처럼 알고리즘 시험을 도입할 수밖에 없습니다.
본질적으로는 차이는 여기에 있습니다. IT 기반의 회사들은 알고리즘이 필요하고 적용해야만 하는 영역이 확실하게 존재하는 반면 큰 기업 입장에서는 특히나 SI 성 프로젝트 입장에서는 알고리즘 기술이 이 필요하다기보다는 빠른 생산성에 더 큰 가치(물론 이런 능력도 모두 능력이 필요합니다)가 있을 수도 있습니다.
다른 회사로 빠져나가는 인력의 눈높이를 맞추기 위해서, IT 업계 트렌드를 반영하여 알고리즘 테스트를 도입, 반영하는 경우입니다.
알고리즘이 실제 필요한 회사
알고리즘은 어디에 쓰일까요? 알고리즘이란 깊은 사고 체계를 의미하기도 합니다. 어디서부터 문제가 발생했고, 또 그 문재를 바로잡기 위해서는 어디서부터 문제를 풀어가야 할지 체계적인 사고가 필요합니다.
알고리즘에 대한 사람들이 가진 기본적인 생각들이 있습니다. 보통은 어려운 과목의 일부로 치부되기도 하는데요. 학부 때 알고리즘 수업을 듣을 땐, '도대체 이걸 어디에 쓴다는 거야?!'
이런 생각을 하기도 했었는데요. 9년간의 개발 과정 속에서 알고리즘이 필요했던 경우는, 코딩 테스트(입사), SW 검정 시험, 메뉴 만들기(그룹 매핑)-TREE, 소설에서 다음화 보기 시에 노드 기반의 알고리즘, 통계, 모니터링 시스템, 대시보드 등등인데 이중에서도 대부분은 DB를 통해 처리가 가능한 수준이었습니다. 보통 DB 가 우리가 해야 할 알고리즘의 많은 역할들을 대체하게 됩니다. DB SELECT의 효율을 높이면 빨라지고 , DB의 SELECT가 느려지면 점점 느려지는 부분들이 있었죠. 물론 이 과정에서 쓸데없는 로직들을 추가하면 당연 느려지지만 그런 과정이 없다면 대부분의 서비스들은 큰 문제가 없었습니다.
사실 원래 알고리즘은 별로 필요하지 않은 게 아닌가 문득 생각이 들기도 하지만 알고리즘은 필요합니다. 데이터가 있어야 할 곳에 데이터가 있다는 것을 아는 것(예를 들면 인사 디비에 어느 칼럼에 어떤 데이터가 들어있는지를 파악한다던지), 데이터가 변수를 통해 혹은 여러 가지 이유로 다양하게 매핑될 수 있다는 점(서버단에서 디비의 데이터를 API로 구성할 줄 안다던가), 이 데이터를 가공하는 다양한 방식(프런트 단에서 특정 형식에 맞춰 날짜 타입이나 숫자 형태로 보여주는 것 등등)들은 코딩, 그 이상 알고리즘들을 통해 알고 있고 체득되었던 내용입니다.
결론적으로 알고리즘은 깊이 있는 사고체계와 큰 연관성이 있습니다. 더 나은 선택을 하게 만들고, 더 나은 선택에 대해서 고민하게 합니다. 어떻게 하면 더 합리적으로 더 좋은 목적지에 빠르게 도달할 수 있는지를 고민할 때 비로소 사고의 확장이 일어나게 되고 이 것이 알고리즘의 순기능이 아닌가 싶네요.
이런 알고리즘을 필요로 하는 곳들이 많이 있습니다.
성장하는 기업들인데요. 더 빠르게 성장하기 위해서는 다양한 효율을 도입하기 마련입니다. 회사의 특성에 따라서 성장은 다양한 방식으로 일어나곤 합니다.
-데이터를 다루는 기업
다루지 않는 기업은 없습니다. 최근 커지고 있는 많은 회사들은 B2B, B2C를 비롯하여 다양한 데이터를 취급하게 됩니다. 고객의 성향을 분석하고, 고객에게 맞춤 서비스를 해야 하고, 또 좋은 교육을 제공하기 위해서 많은 양질의 콘텐츠가 그 콘텐츠를 원하는 사람에게 도달하게끔 하기 위해서는 많은 고민이 필요합니다.
앞서 알고리즘이란 최적화의 고민이 들어갑니다. 원하는 결과를 얻기 위한 많은 연산들이 들어가는데, 알고리즘의 기본적인 것은 bigO에 대한 이해입니다. 데이터를 다루는 기업일수록 그 해당 데이터를 처리하거나 연산하거나 도달하게 하기 위한 수많은 고민을 해야 하고 이것은 알고리즘과의 밀접한 관계가 있습니다.
-추천 서비스
데이터를 다루는 기업과 비슷한 맥락입니다. 큰 커머스 회사의 경우 추천 로직이 매우 중요한 로직 중에 하나입니다. 사용자를 분석해야 하고, 이 사용자의 기호와 관련된 추천 기법에 다양한 알고리즘이 필요합니다. 한 제품에 다른 제품이 추천되는 방식에 따라서 매출에 크게 달라지는 요인이 생기기 때문에 이 방식을 고민하는 것은 매우 중요한 요인입니다. 영화 추천 서비스, 책 추천 서비스, 콘텐츠 추천 서비스도 마찬가지로 고객의 관심사를 추적하여, 추천해야 합니다. 고객이 보는 뷰는 너무나 좁고 작기 때문에 그 작은 공간 안에서 고객을 짧은 시간에 파악해서 가장 비슷하고 가장 근접한 취향을 찾아내는 기법들은 많은 고민들이 녹아져 있는 부분입니다.
- 인공지능이 필요한 기업
최근에는 많은 기업들이 머신러닝의 발전으로 게임의 인공지능 캐릭터들을 활용하는 것을 넘어서 다양한 방식으로 학습 모델들들 강화하고 있습니다. 학부에서는 인공지능과 관련된 과목들을 알고리즘 만으로는 이해하기 어렵지만, 다양한 라이브러리를 비롯하여 음성 인식 학습, 길 찾기 학습, 오타에 대한 학습 등등 다양한 방식으로 학습을 시키고 그 결과들을 찾아내고 있습니다. 어떤 방식이 제일 효율적인가, 미술, 음악, 사회, 경제, 문화, 패션 등등 알고리즘이 많이 필요하고 사용되어 가는 영역입니다.
- 대량의 데이터를 처리해야 하는 기업
분산처리와 서버에 대한 이해도 알고리즘과 무관하다고 할 수 없습니다. 많은 기술들의 기반들은 더 안정적이고 빠른 것들을 추구합니다. 대량의 데이터에 병목이 발생하지 않고 잘 처리되도록 고안하고 설계하기 위해서는 알고리즘에 대한 이해가 필수 적일 것입니다. 물론 기술의 영역에 있어서 어떤 기술을 산택할지 그 선택의 문제는 다른 영역이긴 합니다.
- 금융, 카드 등 돈을 다루는 기업
금융에 무슨 알고리즘이 필요한가 라고 생각할 수도 있지만, 금융만큼 복잡하고 정교하고 디테일해야 하는 곳은 드뭅니다. 알고리즘을 정의하고 활용할 때 가장 중요한 것 중에 하나는 연산입니다. 아무리 해당 알고리즘을 잘 이해하고 있다고 하더라도 계산 과정이 틀리고 로직이 잘못되면 엉뚱한 결과를 도출할 수 있습니다. 금융은 숫자가 가장 중요하기 때문에 재무제표, 이연처리, 합계에 대한 로직을 짜기 위한 나름의 논리와 연산이 중요합니다. 이런 처리 능력과 알고리즘 능력은 연관이 없다고 할 순 없겠죠.
-새로운 그 이상의 영역
지금 생겨나는 수많은 새로운 스타트업들은 새로운 기술과 아이디어들을 접목시켜 기존에 없던 다양한 방식들의 효율을 찾습니다. 부동산 시장은 온라인 거래로 점점 변해가고, 여행 상품시장들은 훨씬 더 고도화되며 사람들의 니즈들을 기억하고 소화해 냅니다. 구글에 검색했던 데이터들은 다른 곳에서 활용되어 또 다른 추천 기법들로 쓰이게 됩니다. 페이스북에서 클릭했던 광고 한 번으로 수많은 연결고리들이 생겨나고, 또 다른 광고 미디어 매체들과의 개연성들이 생겨나게 됩니다.
이런 초연결적인 사고와 구조 그리고 개인의 신상과 기호 그리고 인문학적 분석 요인들은 서로 상호 간에 얽혀 개인의 패턴들을 분석해내고 유추해 냅니다.
이런 몇 가지 기업의 예시를 통해 알고리즘이 필요한 곳과 이유를 설명해 보았는데요.
이렇게 알고리즘은 다양한 기업에 필요로 하고 점점 더 많이 쓰이고 있습니다. 하지만 이런 영역의 전문가가 과연 많이 있는지의 문제에 대해서는 한번쯤 고민해 보아야 할 영역입니다. 모든 일에는 시작점, 성장, 성숙, 그리고 도태 이런 형태의 사이클이 있습니다. 인공지능의 시장과 머신러닝의 시장도 마찬가지로 이 과도기적 과정에서 성장, 도태의 과정을 거쳐 성장하는 곳들이 많아질 것이라고 생각합니다. 다만, 이런 과도기적 단계에서는 검증의 영역이 미지의 영역이고, 이 이야기는 기회인 동시에 실패의 과정도 의미합니다.
그럼 웹 기반이라던지, 앱 기반이라던지, 머신러닝, 알고리즘과 관계없는 프로그래머들은 알고리즘을 몰라도 상관없는 것일까요?
기본적인 웹을 하더라도 논리 없이 일을 진행할 수는 없습니다. 얼마나 정확한지 기능이 얼마나 되는지 그 기능에는 부하가 어느 정도인지 체크하고 측정할 필요가 있습니다. 앱도 마찬가지 겠죠. 프로그램을 설계하고 구현함에 있어서 이 복잡함 들을 이해하는 근간은 사실 이런 알고리즘의 영역입니다.
알고리즘이 필요하지 않다 말하는 입장
앞서 알고리즘이 필요한 입장에 대해 이야기를 해보았는데요.
알고리즘이 필요 없다고 말하는 입장은 무엇이고, 왜 그런 이야기가 나오게 되었는지 그 입장에 대해서
정리해 보려고 합니다.
기업의 업무적 특성
근본적으로 이 알고리즘이 필요하다고 말하거나 필요 없다고 말하는 요인 중에 하나는 알고리즘에 대한 정의로부터 비롯됩니다.
알고리즘을 보면 수도 코드라는 부분이 나옵니다. 어떤 로직을 이해하거나 문제를 풀 때 마치 소스를 작성하듯이 논리적인 것을 코드로 작성하는 부분입니다.
이 부분을 보면 마치 알고리즘은 코딩하는 것과 크게 다르지 않습니다.
알고리즘의 수업을 들어보면 알겠지만, 알고리즘의 이론적인 이야기들은 어떤 정보의 나열입니다. 트리, B Tree, BTS, DP 어떤 데이터의 정렬부터 시작해서 소팅, 길 찾기 알고리즘 등등 이런 정보를 학습하는 것, 알고리즘의 특성을 이해하는 일도 매우 중요하지만, 정말 중요한 것은 알고리즘을 적용하거나 문제를 푸는 일입니다. 알고리즘 과목이 어려운 이유는 이 많은 문제들 중에서 어떤 알고리즘을 사용하는 것이 이 문제를 해결할 수 있는가를 선택하는 지를 문제를 푸는 사람이 결정해야 한다는데 있습니다. 때로 어떤 문제들은 그냥 배열만 잘 활용해도 풀 수 있는 반면 어떤 문제들은 해당 알고리즘을 알고 있거나 이해해야지만 넘어갈 수 있습니다.
이야기가 길어졌습니다만, 이런 알고리즘 과목에서 주어진 문제 자체를 풀 때, 어려운 코딩이라는 느낌을 받게 됩니다. 이렇게 이 느낌이 만들어내는 갭은 알고리즘에 대한 진입 장벽을 만들어 냅니다.
이 차이가 만들어 내는 것은 실상 문제 해결 능력에 관한 것입니다. 수학 문제를 푸는 것과도 같습니다. 풀리지 않는 문제를 놓고 얼마나 오랫동안 붙들 수 있는가? 이 문제를 해결할 수 있는가? 해결하기 위해서 어떤 기법이나 어떤 사고를 활용했는가? 알고리즘은 이렇게 진입 장벽을 만들어 냅니다. 그리고 실상 이 것은 알고리즘이란 이름이 가지는 진입장벽이라기 보가는 깊이 사고하는 것 자체에 대한 진입 장벽입니다.
알고리즘이 필요 없다고 말하는 입장에서는 다양한 입장이 있지만 특히 기업의 일반적인 업무 특성을 보았을 때 알고리즘이 필요하지 않은 경우가 많다는 것입니다.
여기서 알고리즘이라는 것은 위에서 나열한 프로그램을 짜는 능력이라기보다는, 오히려 알고리즘에 나열되어있는 통상적인 알고리즘 기법들을 이야기합니다. 일단 기업에서 사용되는 업무들을 쪼개어 볼 필요가 있습니다.
우선 인사, 재무, 결제, 메일링, 게시판, 공지, 통계, 대시보드, 전략, 협업 도구, devOps, 인프라, 자산, 업종 특성, 문서관리, 툴체인 등등 기업에 따라 더 다양하게 구분될 수 있습니다만, 큰 기업에서는 휴가처리나 입사 퇴사 관리를 비롯한 월급, 평가정보들이 들어간 인사 정보 관리가 있습니다. 또한 돈이 들어오거나 나가는 일들을 처리하는 재무팀이 있기 마련인데 이런 재무관리의 영역이 있습니다. 대부분은 메일 시스템의 경우 메일만을 취급하는 곳에 맡기지만 직접 메일 관리를 하기도 합니다. 사내 게시판이나 공지사항 관리, 사내에 수집된 다양한 정보들을 가공해서 대시보드 형태로 보여주기도 합니다.
이런 나열된 정보들을 보았을 때 알고리즘이 필요한 부분이 눈에 띄지는 않습니다. 데이터를 잘 입력하고 출력하고 계산하면 되기 때문입니다.
이렇게 나열된 정보들을 곰곰이 생각해보면 작은 기업이든 큰 기업이든 이런 모든 정보들을 관리하는 요소들이 시스템의 형태로 필요하며 이런 시스템을 설계하거나 만들거나 생산하는 일들이 많이 생겨날 수밖에 없다는 생각이 듭니다.
즉, 기업에서는 이런 SI 성 형태의 많은 프로젝트들이 있고 이 일들은 돈이 되는 일들입니다. 그렇다고 해서 이 일에 모두 알고리즘의 기법이 들어가지는 않습니다. 하지만 이 일을 처리하기 위해서도 역시 백엔드의 기술이 필요하고, 프런트의 기술이 필요하고, 데이터의 양이나 트래픽이 많아질 경우들을 대비해서 분산처리나 서버 관리의 기술과 역량이 필요합니다.
이런 상황에서 알고리즘을 사용한다, 사용하지 않는다로 기술이 없다. 이상하다. 웹 개발자가 무슨 개발자냐?
라는 말이 나오는 부분 오해의 소지를 가중하는 부분입니다.
즉 알고리즘이라는 논리적 영역 이외에도 많은 기업들이 생각해 놓고 기술해 놓은 체계들을 한순간에 무시하기란 어려운 일입니다. 다만 경우에 따라 업그레이드가 느리거나 옛날 기술을 계속 우려먹는 게 문제라면 문제겠죠.
일을 잘하는 것과 알고리즘을 푸는 것은 다르다.
알고리즘을 잘 풀면 당연히 일도 잘하는 것 아닌가요? 그러니 기업이 코당 테스트를 하는 거 아닌가요?
어떤 이는 이렇게 반문할 수도 있습니다.
코딩을 잘하면, 일도 잘할 수 있습니다.
수학에 보면 필요조건과 충분조건이라는 말이 있습니다. 필요조건이지만 충분조건이 아닐 수 있고 충분조건이지만 필요조건이 아닐 수 있다.
필요충분조건은 동일하게 같은 것을 의미하지만, 일을 잘하는 것과 코딩을 잘하는 문제는 교집합이 있을 수 있는 영역일 뿐이지 어찌 보면 다른 영역이라고 할 수 있습니다.
코딩을 잘하는데 일을 못하는 경우를 예로 들어본다면, 우리가 업무에 대해서 이해하는 것과 문제를 푸는 것은 다를 수 있습니다. 또한 우리가 일을 하다 보면 업무라는 것은 대부분 사람 사이의 관계적인 영역으로 확장됩니다.
코딩을 매우 잘하는 사람이 들어왔는데, 윗사람의 업무가 마음에 들지 않고 업무 스타일이 다릅니다. 위에서 일을 시켰을 때 그 일을 하는 것이 아니라 다른 일들을 하고 자기 계발을 하고 실제로 원래 주어진 일 자체에 대해서는 관심 없는 영역이라는 이유로 대충 하거나 끝을 내지 않는 다면 윗사람은 그 사람을 신뢰하지 않게 될 것입니다.
이렇든 이 친구는 여전히 코딩을 잘할 수는 있지만, 일을 잘한다는 소리를 듣기는 힘이 듭니다. 하지만 상사가 매일 야근하는데, 눈치 보면서 같이 야근해주어야 하나요?라는 질문에 있어서 어쩌면 이렇게 부조리하고 불합리한 부분도 어느 정도 이해 범주가 있다면 일을 잘한다고 이야기를 들을 수 있습니다. 실제로 그런 경우를 종종 보기도 합니다. 하지만, 요새 같은 때에는 합당하지 않게 무작위로 일을 시키는 경우는 많이 줄었습니다. 법적 문제가 있기 때문이죠. 약간 이야기가 돌았으나, 일과 코딩의 문제는 약간 분리해서 생각해 볼 필요가 있다는 것입니다.
또 일을 잘하는 사람의 특징은 상대의 이야기를 경청한다는 것입니다. 문제를 잘못 이해해서 상대와의 감정선이 생긴다던지, 일정이 꼬여버리면 아무리 코딩을 잘해도 또 꼬이기 마련입니다. 업무처리 능력에는 상대에 대한 이해의 범주도 포괄합니다. 이처럼 일을 잘하는 것과 프로그래밍을 잘하는 것은 미묘한 차이가 있습니다. 물론 둘 다 잘한다면 금상 첨화이겠지만 말이죠.
결국 알고리즘의 능력과 일을 잘하는 것이 다르다고 느끼는 것은 이와 같은 것입니다. 알고리즘을 잘 푸는 사람은 문제에 대해서 다양한 접근 방식을 가지고 있습니다. 당연지사 사람과의 관계적인 문제들도 잘 풀 수 있는 열쇠를 가지고 있을 수 있겠죠. 다만 컴퓨터가 사람보다 더 친숙해서 아직까지 그 부분을 실행하지 못한 분이 있다면, 조금 더 많은 소통을 통해 이 문제가 해결되기를 바라봅니다.
기업에서 인정받으려면 일을 잘하면 됩니다.
신경 쓸 여력이 없다.
SW 검정 시험이 5년 전쯤 그 당시 회사에 도입되었습니다. 좋아하는 사람과 싫어하는 사람이 있었는데, 특정 등급을 넘기지 못하면 계속 재시험을 봐야 했고, 그 특정 등급에 도달해야만, 진급이 가능해지고, 더 빨리 진급이 일어나는 이상한 현상이었습니다.
앞서 말했던 일과 알고리즘의 상관관계가 많지 않음으로 말미암아 많은 직원들이 내부적인 불만에 있었는데요. '코딩 테스트를 더 자주 하면, 실력이 향상되고 더 좋은 거 아닌가' 싶은 생각이 드는 분들도 있을지 모르겠지만 꼭 그렇진 않습니다. 고과를 더 잘 받기 위해서는, 봉사활동도 해야 하고, 사회적인 콘퍼런스나 세미나도 해야 하고, 또 자격증이나 영어 점수도 올려야 했습니다. 이제는 시험 점수까지 올려야 하니, 이게 다 일이랑 무슨 상관인가 싶은데... 평가란 늘 난해하니까요. 물론 이중에 단 한 가지 만의 척도로 평가를 하겠다고 한다면 조금은 편해지고 그 하나에만 집중하고 올인할 수는 있겠지만, 회사에 온 이유가 시험을 통과하기 위해 회사를 온 것은 아니니까요.
조금 더 발전적이었으면 좋겠다는 생각에 이릅니다. 사람들의 코딩 테스트 능력을 키우는 것도 중요하지만, 이렇게 쌓아놓은 기술 기반의 새로운 분야들을 확장해 나가야 하는데, 시험만 보면....?? 뭐 하는 건가 생각이 들기 마련입니다.
업무를 위해 공부해야 할 것은 많습니다. 금융이면 금융적 지식을 쌓는 일, 제조면, 제조적 분야의 업종 특성을 공부하는 일, 스타트업이면 해당 업무나 도메인에 대한 이해를 증가시키는 일 등등해야 할 일은 넘쳐납니다.
업무의 효율을 늘리는 가장 좋은 방법은 작은 것 하나하나를 꿰차는 일입니다. 근데 시간도 없는데 알고리즘 공부를 하고 시험을 봐야 한다니...
당연 반발이 일어나는 겁니다. 주말에 시험을 보고 평일에 회사를 나오고 이게 반복되다 보면, 아마 알고리즘을 찬양하는 사람이 엄청나게 이해가 안 되는 상황이 발생하겠죠?
알고리즘을 공부해서 혜택을 본 사람들이 분명 있습니다. 외국계, 인공지능, 머신러닝, 추천 시스템, 검색 시스템 등등 IT에서 알고리즘이 가장 필요로 하고 최전선에 있는 부분에 취업을 하거나 선도적인 곳에서 기존에 사람들이 받는 연봉보다 훨씬 더 많은 혜택을 받는 사람들입니다.
다만 인지해야 하는 것은 모두가 그 프레 임안에 들어오기에는 업종 선택의 폭이 너무 좁다는 것입니다. 물론 시장의 커지는 속도를 보면 아직 충분히 여유가 있고 도전할 필요가 있습니다. 하지만 시장에는 다양한 업종이 있고 서로는 서로에 대해 이해할 필요가 있습니다.
그래도 꿈꾼다
알고리즘이 필요 없다는 하나의 프레임을 설명했지만, 그렇다고 해서 더 이상 생각할 필요가 없다는 것을 의미하진 않습니다. 누군가 선도해 나가면 나머지 시장은 뒤따르기 마련입니다. Java 1.4를 여전히 사용하고 있는 부서도 언젠간 java 1.8로 올리기 마련입니다.
순수 php만 하다가도 언젠가는 CI나 laravel과 같은 프래임 워크를 써볼 기회가 생기기도 하는 것입니다.
IT의 발전은 많은 새로운 것들을 가져왔고, 기업은 관성에 따라 여태 해왔던 많은 것들을 유지하려고 합니다. 그래도 새로움을 소비하고 촉진하고 바라는 사람들이 계속 생기고 하기 때문에 이 입장들도 서서히 바뀐다고 생각합니다.
맺음말
알고리즘이라는
어려운 주제로 글을 써보았는데요.
알고리즘이 필요한가? 혹은 필요하지 않은가?
