개발자를 위한 실전 ‘코딩테스트’ 준비 팁

개발자라면 누구나 ‘코딩테스트’를 준비해 본 경험이 있을 겁니다. 코딩테스트는 여러분의 두뇌가 얼마나 비상한지, 복잡하게 꼬인 문제를 얼마나 천재적인 발상으로 해결할 수 있는지 시험하기 위한 절차가 아닙니다. 대신 정해진 범위 안에서 정형화된 유형별로 출제된 문제를 푸는 시험이죠. 즉, 누구나 공부하는 방법을 알고 제대로 공부한다면 충분히 통과할 수 있습니다.

저 또한 알고리즘에 대해 잘 아는 편이 아닙니다. 알고리즘 대회나 정보 올림피아드 등에 나간다면, 입상은 커녕 몇 문제나 풀 수 있을지도 모르겠습니다. 그러나 채용 과정에서 거치는 코딩테스트에는 항상 합격했고, 처음으로 낸 코딩테스트 책도 나름 자신 있게 집필할 수 있었습니다. 

사실 프로그래밍을 시작할 때 알고리즘은 크게 생각하지 않았습니다. 오히려 안드로이드 애플리케이션, 웹 등 개발 자체에만 관심이 있었죠. 그러나 코딩테스트를 준비하며, 알고리즘과 유형을 꼼꼼히 학습한 후에는 웬만한 코딩테스트에는 크게 겁먹지 않게 됐습니다.

이번 글에서는 코딩테스트를 어떻게 준비했는지 필자의 노하우를 소개할 예정이며, 개발자로서 코딩테스트에 어떻게 접근하면 좋을지 알아보겠습니다.

코딩테스트 언어

주변에 코딩테스트를 준비하는 분들을 보면, 코딩테스트와 본인의 개발을 별개로 생각하는 경우가 많습니다. 예를 들어, 이런 이야기를 합니다.

“슬슬 코딩테스트를 준비해야 할 것 같은데, 무슨 언어가 좋을까?”

코딩테스트를 대비하기 위한 언어는 어떻게 선택하면 좋을까요? 결론부터 말하자면, 새로운 언어보다는 이미 많이 다뤄본 언어, 앞으로 실무에서 많이 활용하게 될 언어를 사용하는 것이 좋습니다.

코딩테스트를 위해 새로운 언어를 공부한다면?

흔히 코딩테스트는 어려운 알고리즘들과 자료 구조를 익혀야 한다는 생각에, 이를 조금이나마 편하게 해주는 언어를 선택하려고 합니다. 그리고 언어를 추천받아 코딩테스트용으로 새롭게 공부합니다.

이렇게 새로운 언어로 코딩테스트를 준비하면, 알고리즘과 자료구조를 학습하는 것과 동시에 다룰 줄 아는 언어가 늘어나니 일석이조라고 생각할 수 있죠. 하지만 여기에는 모순이 존재합니다.

예를 들어, 백엔드 공부를 하며 자바와 스프링을 다뤄 본 개발자가 있습니다. 코딩테스트를 준비하는데, 파이썬이 유리하다는 이야기를 듣고 파이썬을 선택했다고 가정할게요. 이 개발자에 대한 첫인상은 자바와 파이썬 두 언어 중, 하나도 제대로 활용해 보지 못한 사람이라고 인식될 가능성이 큽니다.

코딩테스트 문제를 해결하다 보면, 프로젝트 경험에서는 알 수 없었던 해당 언어의 활용법을 더욱 잘 알게 됩니다. 코딩테스트와 프로젝트는 그 언어에 대해 각기 다른 역량을 키울 수 있기 때문입니다. 이런 상황에서 자바를 두고 파이썬을 새롭게 공부하면, 자바에 대한 추가적인 역량을 키울 기회를 날리게 되는 것입니다.

결국 자신이 익숙하지 않은 언어를 코딩테스트만을 위해 채택하는 것은 좋은 선택은 아닐 겁니다. 메인 언어에 대한 충분한 역량을 쌓을 수도 없고, 새로 공부한 언어도 앞으로 활용할 일이 없을 수 있어서, 장기적인 관점에서 단점이 더 큰 접근법이라고 생각합니다.

코딩테스트를 준비하는 마음가짐

코딩테스트를 준비하다 보면 이게 진짜 실무에서 쓰일까? 싶으면서 괜히 시간 낭비하고 있는 듯한 느낌이 들 때가 있습니다. 코딩테스트 준비를 단순히 여러 알고리즘과 자료 구조를 외우고, 문제에 대한 답을 외우는 과정이라고 생각한다면, 너무나 지루하고 귀찮은 과정이 아닐 수 없습니다.

따라서 코딩테스트를 제대로 준비하고 여러분의 개발 역량을 키우고 싶다면, 코딩테스트를 단순히 여러분의 취업 길을 막는 난관일 뿐이라는 인식을 바꿔야 합니다. 여기서 학습하는 자료 구조와 알고리즘은 여러 유명한 소프트웨어들이 어떻게 동작하는지를 파악할 수 있는 인사이트의 기반이 됩니다. 하지만 이외에도 여러분이 사용하는 언어에 대한 역량을 키울 수 있는 아주 큰 기회로 삼아야 합니다.

제가 자바로 코딩테스트 책을 집필할 때, 가장 신경 쓴 부분도 이것이었습니다. 어떻게 하면 문제를 더욱 자바답게 풀어낼 수 있을까? 코딩테스트 책인 만큼 알고리즘과 자료 구조에 대해 다루는 것은 당연했습니다. 여기에 단순히 일반적인 내용만 다루는 것을 넘어, Stream 활용, 클래스와 인터페이스 활용 등 자바를 자바답게 다루는 것에 집중했습니다.

이러한 내용은 코딩테스트를 넘어야 할 장애물이라는 인식으로 접근했을 땐 쉽게 보이지 않는 것들입니다. 즉,코딩테스트를 개발자로서 성장할 수 있는 기회라 여기고, 이를 통해 여러분이 자신 있고, 앞으로 많이 활용하게 될 언어의 역량을 발전시키는 과정이라 생각해 보세요. 스스로 더욱 수준 높은 개발자가 될 수 있는 계기로 만들어야 합니다.

코딩테스트 공부법

사실 코딩테스트를 ‘어떻게’ 공부해야 하는지에 대한 자료는 이미 넘쳐납니다. 하지만 그만큼 핵심적인 부분을 놓치기 쉽습니다. 이번에는 제가 코딩테스트를 준비하면서 가장 중요하다고 생각했고, 코딩테스트를 ‘성장 계기’로 삼기 위해 노력했던 몇 가지 내용에 대해 짚어보겠습니다.

시간 복잡도 계산하기

의외로 코딩테스트를 준비하는 많은 분들이 시간 복잡도를 경시하는 경향이 있습니다. 복잡한 재귀나 알고리즘이 들어가지 않는 한, 여러분이작성하는 코드에 대한 시간 복잡도는 확실히 계산할 수 있어야 합니다.

단순히 이분 탐색은 O(logN), 이진 탐색 트리의 탐색 시간은 O(logN), 반복문 하나당 O(N)과 같이 암기식으로 접근해서는 안 됩니다. 이러한 암기식 접근법으로는 충분히 예상 가능한 시간 초과도 놓치게 됩니다.

제 지인 중 한 명이 HashSet의 연산 시간은 O(1)이라는 사실만 가지고, 코드를 작성했다가 시간 초과로 고생한 적이 있습니다. HashSet<String>을 사용해서 발생한 문제였는데, 물론 HashSet의 연산 시간은 상수 시간이 맞습니다.

하지만 이러한 상수 시간 연산을 이끌어낼 수 있는 해시 코드를 구하기 위해서는 Set의 key가 되는 문자열의 길이에 비례하는 시간이 걸립니다. 즉, HashSet의 연산은 상수 시간이라는 사실만 가지고 코드를 작성하고, 어떻게 상수 시간을 만들어낼 수 있는지에 대해서는 깊이 생각하지 않은 것입니다. (이와 관련해 제 블로그에 자세히 다룬 글이 있으니 참고해 보셔도 좋습니다.)

시간 복잡도 계산이 어렵다고만 생각하지 말고, 간단한 코드부터 차근히 계산하는 연습을 해보세요. 그러다 보면 웬만한 코드는 굳이 시간 복잡도를 하나하나 따져보지 않더라도, 시간제한을 넘어갈지 아닐지 직관적으로 판단할 수 있는 순간이 올 겁니다.

알아야 하는 알고리즘과 자료 구조

코딩테스트에서는 알아야 할 알고리즘과 자료 구조가 정해져 있습니다. 아마 기업별로 다른 알고리즘과 자료 구조를 출제하다가, 점차 소프트웨어 공학의 기초가 되는 자료 구조와 알고리즘 위주로 문제들이 선별되기 시작했고, 그 내용이 정형화된 유형이 됐을 것으로 추측합니다.

개인적으로 코딩테스트에서 다루는 내용은 개발자라면 필수로 알고 있어야 하는 내용이라고 생각합니다. 이러한 내용들을 실무에서 직접 코드를 쳐가면서 구현할 일은 그다지 많지 않을지언정, 다른 사람의 코드, 가져다 사용하는 코드를 이해하는데 있 큰 도움이 되기 때문입니다.

자료 구조를 모른다면 리스트에서 중복을 제거하기 위해 몇 번이고 선형 순회를 할 수밖에 없습니다. 하지만 코딩테스트를 준비하면서 자료 구조를 공부했다면, Set을 이용해 간단한 구현으로 O(N)만에 처리할 수 있다는 사실을 알 수 있을 것입니다. 여기서 확장하면 다루는 데이터에 따라서 HashSet을 사용해 O(N)에 처리할지, TreeSet을 사용해 O(N logN)에 처리할지도 고민해 볼 수 있습니다.

이처럼 코딩테스트에서 다루는 알고리즘과 자료 구조는 단순히 하나의 기능을 구현할 때도 여러 선택지를 두고 고민할 수 있게 해줍니다. 이러한 내용이 머릿속에 쌓이다 보면, 더욱 유연하고 논리적인 사고를 할 수 있게 됩니다.

따라서 코딩테스트를 공부하면서 알게 된 내용을 여러분이 경험해 본 프로젝트에 어떻게 활용할 수 있을지, 사용해 본 라이브러리나 프레임워크는 이를 어떻게 사용해서 구현한 것일지 고민해 보세요. 이렇게 공부하면 재미도 있고, 개념을 명확히 이해하면서 공부할 수 있을 겁니다.

문제는 얼마나 많이 풀어봐야 할까?

당연히 문제는 많이 풀면 풀수록 좋습니다. 풀어야 하는 문제에 정해진 개수는 없지만, 여러분이 다음 단계로 넘어갈 준비가 됐다는 걸 판단할 수 있는 근거는 다음과 같습니다.

1. 하나의 유형에 대해 해설을 보고 이해할 때
2. 하나의 유형에 대해 해설 없이 정답 코드만 보고도 이해할 때
3. 하나의 유형에 대해 답을 보지 않고도 해결할 수 있을 때
4. 문제의 유형을 모른 채로 보고도 문제를 해결할 수 있는 여러 풀이를 떠올릴 수 있을 때
5. 시간 복잡도와 구현 복잡도를 고려해 문제에 대한 효율적인 풀이를 선택할 수 있을 때

처음에는 문제의 유형을 알고 이에 대한 자료 구조와 알고리즘을 공부했어도 문제를 풀기 힘들 수 있습니다. 접해 본 적도 없고, 활용해 본 적도 없는 내용이니 당연합니다. 또한 문제의 해설을 읽고 나서도 이해하기 힘든 경우가 많습니다. 이때 하나의 해설을 여러 번 읽으면서 놓친 부분을 최대한 상기하고, 같은 문제에 대한 여러 해설을 읽다 보면, 어느 순간 해설을 이해하게 될 때가 있습니다. 이때가 바로 첫 번째 관문을 넘는 시점입니다.

물론 하나의 문제에 대한 풀이를 이해했다고, 바로 다음 문제가 잘 풀리지는 않을 겁니다. 해설에 대한 이해도 마찬가지입니다. 아직은 유형에 익숙해져야 할 때입니다. 문제와 해설을 읽다 보면, 유형이 조금씩 익숙해지면서 해설 없이 코드만 보고도 이해되는 때가 옵니다. 문제의 유형이 눈에 익기 시작하면서, 다른 문제임에도 불구하고 코드가 비슷하게 생겼다는 것을 깨닫게 됩니다. 이때가 두 번째 관문을 넘는 시점입니다.

이렇게 문제의 접근법과 풀이 코드의 생김새에 익숙해지면, 단순히 읽고 이해하는 것을 넘어서 여러분이 스스로 코드를 작성할 수 있게 됩니다. 이제는 해당 유형에 대해 충분히 익숙해졌다고 판단할 수 있습니다. 

과연 문제의 유형을 모른 채, 같은 식으로 풀이를 떠올릴 수 있을까요? 아마 가능할 것입니다. 이미 해당 유형에 대해 익숙해진 상태이기 때문에, 해당 문제를 여러분이 학습한 유형으로 접근하는 방법을 떠올릴 수 있을 것입니다. 하지만 코딩테스트에서 나오는 유형은 한 가지가 아닙니다. 하나의 문제를 해결할 수 있는 여러 방법이 있습니다. 최대한 많은 접근법을 떠올려보고, 그 장단점을 비교하는 연습을 해보세요.

다음으로 여러 접근법을 비교해 보면, 서로 다른 점을 알 수 있습니다. 어떤 방식은 시간 복잡도를 계산해 보니 시간이 초과해 버려야 할 방식일 수 있습니다. 또 어떤 방식은 매우 효율적으로 문제를 해결할 수 있지만 구현이 너무 복잡할 수 있습니다.

이렇게 여러 관점에서 풀이들을 비교해 보고, 학습 시에는 시간제한에 걸리지 않는 한 많은 접근법을 구현하도록 연습해 보세요. 이러한 경험이 쌓여 실제 코딩테스트에서 시간제한에 걸리지 않을 만큼 효율적이면서, 가장 빠르게 구현할 방법으로 문제를 풀 수 있게 됩니다.

더 고민해야 할까, 답을 봐야 할까?

이제 여러분의 목표는 최대한 빠르고 효율적으로 위에서 살펴본 단계들을 돌파하는 것입니다. 그러기 위해서는 많은 해설과 정답 코드를 보고, 눈에 익히고 직접 써봐야 합니다. 물론 답을 보는 것에 대해 거부감이 있을 수 있습니다. 하지만 유형이 익숙하지 않은 상황에서 길게 고민하면, 오히려 사고가 잘못된 방향으로 굳어질 수 있습니다.

저도 아직 많은 문제에서 풀이를 참고합니다. 제가 세운 기준은 다음과 같습니다.

1. 문제를 보고 5분 동안 풀이 유형이 떠오르지 않는다면 정답을 참고합니다.
2. 문제를 보고 15분 동안 효율적인 풀이로 접근하고 있지 않다면 정답을 참고합니다.
3. 문제를 푼 후 구현에 어색했던 부분이 있다면 정답을 참고합니다.

즉, 15분 안에 정답을 볼지 말지를 판단합니다. 그 이상은 아무리 오래 잡고 있어도 큰 의미가 없다고 생각합니다. 코딩테스트에서 자료 구조와 알고리즘은 우리가 많이 경험해 보고 익혀야 할 대상이지, 아무것도 모르는 상태에서 스스로 깨우쳐야 할 대상이 아니기 때문입니다.

오히려 우리가 긴 시간 동안 깊게 고민하고 시도해 봐야 할 것은 그 풀이를 어떻게 구현하는가입니다. 문제의 유형과 풀이는 보고 이해하면 됩니다. 하지만 코드를 어떻게 작성해야 하고, 사용하는 언어의 특징을 얼마나 잘 살려서 코드를 작성하느냐는 온전히 여러분이 부딪혀봐야 할 문제입니다. 정리하면 문제 풀이를 보는 것을 창피해하지 마세요. 3시간 동안 풀이를 고민하다가 20분 만에 코드를 작성하는 것보다, 첫 20분에 정답을 보고 이해한 후 3시간 동안 코드를 고민하며, 여러 구현 방법을 시도해 보는 것이 훨씬 도움이 됩니다.

코딩테스트 실전 팁

코딩테스트는 시간과의 싸움입니다. 효율적인 풀이를 얼마나 빠르게 찾아내고 구현할 수 있는지, 디버깅을 얼마나 효율적으로 할 수 있는지에 따라서 통과와 탈락이 판가름 납니다. 이번에는 이러한 과정에 도움이 될 수 있는 실전 팁 몇 가지를 살펴보겠습니다.

코딩하지 않기

문제를 보고 유형 파악이 됐어도 바로 코딩으로 들어가서는 안 됩니다. 우리가 풀이를 머릿속으로 구상할 때는 추상적으로 접근하게 됩니다. 이 상태에서 바로 코드를 구현하면, 추상적인 풀이를 구체화하는 동시에 구현해야 합니다. 만약 추상적 풀이에서 놓친 부분이 있었다면, 작성했던 코드를 모두 버리고 다시 풀이부터 생각해야 합니다. 제한된 시간 내에 문제를 풀어야 하는 코딩테스트에서 이러한 과정은 심각한 시간 낭비로 이어집니다.

이를 방지하기 위해서는 풀이를 고안한 후, 노트 등에 실제 데이터가 처리되는 과정을 하나하나 살펴보는 과정이 필요합니다. 이 과정을 통해 시간 복잡도를 더욱 확실히 계산하며 효율성도 검증할 수 있고, 풀이가 제대로 문제를 해결하는지 또한 확인할 수 있습니다.

단계별로 구현하기

풀이를 확실히 검증한 후에는 이를 코드로 옮겨야 합니다. 이 과정에서도 많은 실수가 일어납니다. 이 과정 중 실수를 줄이기 위해서는 풀이를 역할에 따라 여러 단계로 나누고, 각 단계별로 구현과 테스트를 해나가야 합니다.

예를 들어, 제 블로그에 [프로그래머스/Java] 1, 2, 3 떨어뜨리기 - Lv. 4 문제 풀이라는 글이 있습니다. 이 글에서는 문제 풀이를 고안한 후, 단계적으로 코드를 작성합니다. 풀이를 여러 부분으로 나누고, 조금씩 구현하고 검증함으로써 구현상의 실수를 초기에 잡아낼 수 있고, 가독성 높은 코드를 작성할 수 있게 됩니다.

시간 복잡도로 알고리즘 유추하기

만약 문제를 읽고 도저히 풀이가 생각나지 않는다면, 문제의 제한 사항을 활용해 풀이의 시간 복잡도를 추측하고, 이를 바탕으로 어떠한 풀이로 접근해야 하는지 떠올려볼 수 있습니다. 이는 실제 코딩테스트에서 정말 모르겠을 때 한 번씩 활용해 보면, 상당히 높은 확률로 올바른 접근법을 유도해 낼 수 있는 방법입니다.

이러한 접근법은 시간제한과 입력 제한이 확실한 코딩테스트이기 때문에 적용할 수 있는 방법입니다. 하지만 그만큼 오히려 알고리즘과 자료 구조에 대한 시간 복잡도를 확실히 알고 있어야, 시도할 수 있는 방법이니 참고해 봐도 좋습니다.

마치며

무언가를 직접 만들고, 코드를 작성하는 대로 프로그램이 만들어지는 것에 재미를 느껴 개발자를 꿈꾸는 경우가 많습니다. 그래서 프로그래밍을 열심히 공부하지만, 코딩테스트는 어렵고 흥미가 떨어져 포기하는 사람도 있습니다.

프로그래밍을 잘하고 못하고는 기능을 구현할 수 있는지로 판가름 나는 것이 아닙니다. 코드의 효율성, 확장성 등 논리적인 사고를 통해 얼마나 좋은 코드를 작성할 수 있는지가 관건입니다. 코딩테스트는 그것을 위한 최소한의 논리적 사고 훈련이면서, 여러 구현 방법을 떠올릴 수 있는 기반 지식 공부입니다.

코딩테스트를 그저 장애물로 생각하지 말고, 한층 더 성장하는 개발자가 되기 위한 발판이라고 생각해 보세요. 그렇게 코딩테스트를 공부하면 더 좋은 코드를 쓸 수 있게 되고, 논리적으로 사고할 수 있는 힘을 기를 수 있을 것입니다. 쉬운 과정은 아니지만, 여러분이 꿈꾸던 개발자에 더 가까워질 수 있길 바랍니다.

 요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.