코딩 테스트는 '천재성'보다 '재현 가능한 문제 해결'을 본다
코딩 테스트를 처음 준비하는 사람은 종종 이런 착각에 빠집니다. "알고리즘을 많이 외워야 하나?", "수학 머리가 좋아야 하나?", "하루에 열 문제씩 풀면 합격할까?" 물론 알고리즘 지식도 필요하고, 많은 문제를 풀어보는 경험도 중요합니다. 하지만 기업이 코딩 테스트를 통해 확인하려는 핵심은 단순히 "이 사람이 어려운 문제를 맞힐 수 있는가?"가 아닙니다.
기업은 제한된 시간 안에서 낯선 요구사항을 읽고, 핵심 조건을 파악하고, 적절한 자료구조와 알고리즘을 선택해, 실수 없이 코드로 구현할 수 있는지를 봅니다. 다시 말해 코딩 테스트는 개발자가 실제 업무에서 자주 마주치는 문제 해결 과정을 압축해 놓은 시험입니다.
실무에서도 개발자는 늘 이런 일을 합니다. 기능 요구사항을 읽습니다. 예외 상황을 고려합니다. 데이터가 많아졌을 때 느려지지 않을지 생각합니다. 이미 있는 기능을 망가뜨리지 않도록 조심하며 코드를 작성합니다. 코딩 테스트 문제는 현실의 서비스 코드와 생김새는 다르지만, 그 안에는 개발 업무에 필요한 기초 체력이 들어 있습니다.
따라서 코딩 테스트 준비의 첫 번째 목표는 "문제를 많이 푸는 것"이 아니라 "문제를 안정적으로 풀 수 있는 사고와 습관을 만드는 것"이어야 합니다. 같은 문제를 맞히더라도 우연히 맞힌 것과 이유를 알고 맞힌 것은 완전히 다릅니다. 시험장에서 믿을 수 있는 것은 운이 아니라 반복해서 훈련한 절차입니다.
기업이 평가하는 세 가지 핵심 역량
코딩 테스트에서 가장 자주 평가되는 역량은 크게 문제 해결력, 구현력, 시간 복잡도 감각입니다. 이 세 가지는 따로 떨어져 있지 않습니다. 문제 해결력이 좋아도 구현이 약하면 정답 코드로 완성하지 못합니다. 구현이 빨라도 시간 복잡도를 고려하지 않으면 큰 입력에서 시간 초과가 납니다. 시간 복잡도는 잘 알아도 문제를 어떻게 쪼갤지 모르면 출발조차 어렵습니다.
문제 해결력: 문제를 쪼개고 길을 찾는 힘
문제 해결력은 "어떤 알고리즘을 알고 있느냐"보다 넓은 능력입니다. 문제를 읽고 요구사항을 정확히 이해한 뒤, 입력과 출력 사이의 관계를 찾아내고, 풀이 방향을 세우는 힘입니다.
예를 들어 "가장 짧은 시간", "최소 비용", "가능한 모든 경우", "연속된 구간", "중복 없이 선택" 같은 표현은 문제의 방향을 알려주는 신호입니다. 가장 짧은 경로를 묻는다면 그래프 탐색이나 최단 경로를 떠올릴 수 있습니다. 가능한 모든 조합을 확인해야 한다면 완전 탐색이나 백트래킹을 생각할 수 있습니다. 같은 계산이 반복된다면 동적 계획법을 의심할 수 있습니다.
하지만 처음부터 알고리즘 이름을 맞히려고 하면 오히려 사고가 좁아집니다. 좋은 문제 해결은 작은 질문에서 시작합니다. "입력이 작다면 어떻게 풀 수 있을까?", "직접 모두 세어도 될까?", "중복 계산이 생기나?", "정렬하면 쉬워지나?", "빠르게 찾아야 하는 값이 있나?" 이런 질문을 던지다 보면 자연스럽게 필요한 도구가 드러납니다.
문제 해결력은 번뜩이는 아이디어만으로 생기지 않습니다. 여러 문제를 풀면서 "이 조건에서는 왜 이 방법이 가능한가"를 정리할 때 자랍니다. 정답을 본 뒤에도 "아, 이런 유형이구나"에서 멈추지 말고, 내가 왜 떠올리지 못했는지까지 확인해야 합니다.
구현력: 생각한 풀이를 코드로 끝까지 옮기는 힘
구현력은 코딩 테스트에서 가장 현실적인 벽입니다. 풀이 아이디어를 알고 있는데도 틀리는 경우가 많습니다. 인덱스를 하나 잘못 잡거나, 초기값을 잘못 두거나, 종료 조건을 놓치거나, 예외 케이스를 빠뜨립니다. 특히 문자열, 배열, 좌표 이동, 시뮬레이션 문제에서 구현력이 크게 드러납니다.
구현력이 좋다는 것은 단순히 문법을 많이 안다는 뜻이 아닙니다. 머릿속 절차를 명확한 코드 흐름으로 바꾸는 능력입니다. 변수 이름을 읽기 쉽게 짓고, 반복문의 범위를 안정적으로 잡고, 조건문이 복잡해질 때 코드를 적절히 나누고, 테스트 케이스를 직접 만들어 확인하는 습관까지 포함합니다.
초보자는 보통 "알고리즘을 몰라서 못 푼다"고 생각하지만, 실제로는 구현 기본기 때문에 막히는 경우가 많습니다. 배열을 뒤집고, 구간을 자르고, 빈도수를 세고, 좌표를 이동하고, 문자열을 파싱하는 코드는 코딩 테스트의 가장 기본적인 손동작입니다. 이 손동작이 익숙하지 않으면 어려운 알고리즘을 배워도 시험장에서 사용할 수 없습니다.
반대로 실무 경험이 있는 개발자는 추상화와 설계를 잘하지만, 짧은 시간 안에 간결한 코드를 작성하는 감각이 약할 수 있습니다. 실무 코드에서는 유지보수성과 구조가 중요하지만, 코딩 테스트에서는 제한된 시간 안에 정확하게 동작하는 코드가 우선입니다. 물론 지저분한 코드를 쓰라는 뜻은 아닙니다. 다만 과도한 구조화보다 문제 조건에 맞춘 단순하고 명확한 구현이 더 유리할 때가 많습니다.
시간 복잡도 감각: 이 풀이가 제한 시간 안에 끝날지 판단하는 힘
시간 복잡도는 입력 크기가 커질 때 실행 시간이 어떻게 늘어나는지를 대략적으로 판단하는 방법입니다. 코딩 테스트에서는 정답 아이디어만큼이나 중요한 기준입니다. 아무리 논리적으로 맞는 풀이여도 입력이 100,000개인데 모든 쌍을 비교하면 대개 시간 초과가 납니다.
시간 복잡도 감각은 수학 공식처럼 외우는 것이 아니라, 입력 크기와 가능한 연산량을 연결하는 감각에 가깝습니다. 예를 들어 입력 크기 N이 1,000 정도라면 O(N^2) 풀이도 가능할 수 있습니다. 하지만 N이 100,000이라면 보통 O(N log N)이나 O(N)에 가까운 풀이가 필요합니다. N이 20 이하라면 모든 부분집합을 살피는 O(2^N) 풀이도 가능할 수 있습니다.
문제를 풀 때는 풀이를 코드로 쓰기 전에 먼저 질문해야 합니다. "내 풀이가 대략 몇 번의 연산을 할까?" 이 질문을 건너뛰면, 열심히 구현한 뒤에야 시간 초과를 보고 처음부터 다시 시작하게 됩니다. 시험장에서는 이 손실이 치명적입니다.
시간 복잡도 감각은 알고리즘 선택의 나침반입니다. 정렬을 할지, 해시를 쓸지, 투 포인터를 쓸지, 우선순위 큐를 쓸지, 동적 계획법으로 중복 계산을 줄일지 결정하는 근거가 됩니다. 이 책의 뒤쪽 챕터에서 각 자료구조와 알고리즘을 배우게 되지만, 모든 장의 바탕에는 "입력 크기에 맞는 풀이인가?"라는 질문이 깔려 있습니다.
코딩 테스트의 세 가지 형태
기업마다 코딩 테스트 방식은 다릅니다. 크게 온라인 코딩 테스트, 라이브 코딩, 과제형 테스트로 나눌 수 있습니다. 같은 코딩 테스트라는 이름을 쓰지만, 실제로 평가하는 장면과 준비 방식은 조금씩 다릅니다.
온라인 코딩 테스트: 제한 시간 안에 정답을 제출하는 시험
온라인 코딩 테스트는 가장 일반적인 형태입니다. 정해진 시간 동안 여러 문제를 풀고, 플랫폼에 코드를 제출하면 테스트 케이스를 기준으로 채점됩니다. 지원자는 보통 문제 설명, 입력 형식, 출력 형식, 예제만 보고 풀이를 작성합니다.
이 방식에서는 속도와 정확도의 균형이 중요합니다. 쉬운 문제를 빠르게 맞히는 능력, 중간 난도의 문제에서 막히지 않는 기본기, 어려운 문제를 적절히 포기하거나 부분적으로 접근하는 판단력이 필요합니다. 모든 문제를 풀어야 합격하는 시험도 있지만, 많은 경우 주어진 시간 안에서 최대한 많은 점수를 안정적으로 얻는 것이 중요합니다.
온라인 테스트를 준비할 때는 실제 시험처럼 시간을 재고 푸는 연습이 반드시 필요합니다. 혼자 공부할 때는 한 문제에 두세 시간을 써도 괜찮지만, 시험에서는 20분 동안 방향이 안 잡히면 다음 문제로 넘어가야 할 수 있습니다. 문제를 푸는 실력뿐 아니라 문제를 고르는 전략도 연습해야 합니다.
라이브 코딩: 풀이 과정과 커뮤니케이션을 함께 보는 시험
라이브 코딩은 면접관이 지켜보는 상황에서 문제를 푸는 방식입니다. 화면을 공유하거나 온라인 에디터를 사용하기도 하고, 화이트보드나 문서에 의사코드를 작성하기도 합니다. 이때 중요한 것은 최종 정답만이 아닙니다. 면접관은 지원자가 문제를 어떻게 이해하고, 어떤 가정을 세우고, 막혔을 때 어떻게 대처하는지 봅니다.
라이브 코딩에서는 침묵이 길어지면 불리합니다. 머릿속으로만 생각하지 말고, 현재 이해한 내용을 말로 확인해야 합니다. "입력 크기가 이 정도라면 모든 쌍을 비교하면 어려울 것 같습니다", "정렬하면 인접한 값만 비교해도 될지 확인해보겠습니다", "우선 간단한 예제로 동작을 검증해보겠습니다"처럼 생각의 방향을 드러내는 것이 좋습니다.
또한 라이브 코딩에서는 완벽한 코드보다 협업 가능한 태도가 중요하게 평가되기도 합니다. 힌트를 받았을 때 방어적으로 반응하지 않고, 질문을 통해 조건을 명확히 하고, 실수를 발견하면 차분히 수정하는 모습이 좋은 인상을 줍니다. 실무에서 개발자는 혼자 천재적으로 문제를 해결하는 사람보다, 동료와 함께 문제를 명확히 하고 안정적으로 해결하는 사람이어야 하기 때문입니다.
과제형 테스트: 작은 제품을 완성하는 시험
과제형 테스트는 며칠의 시간을 주고 특정 기능이나 작은 애플리케이션을 구현하게 하는 방식입니다. 알고리즘 문제보다는 실제 개발 업무에 가깝습니다. API를 설계하거나, 화면을 구현하거나, 데이터를 저장하고 불러오거나, 테스트 코드를 작성하는 과제가 나올 수 있습니다.
과제형 테스트에서는 코드의 동작 여부뿐 아니라 구조, 가독성, 예외 처리, 테스트, 문서화가 중요합니다. 제한 시간이 길다고 해서 무작정 많은 기능을 넣는 것이 좋은 전략은 아닙니다. 요구사항을 정확히 만족하고, 실행 방법이 명확하며, 기본적인 예외 상황을 다루고, 읽기 쉬운 코드로 제출하는 것이 더 중요합니다.
준비 방식도 다릅니다. 알고리즘 문제만 풀어서는 부족합니다. 자주 사용하는 프레임워크나 라이브러리로 작은 프로젝트를 처음부터 끝까지 만들어보는 연습이 필요합니다. README를 쓰고, 실행 방법을 정리하고, 간단한 테스트를 추가하고, 커밋 단위를 정리하는 습관도 도움이 됩니다.
무작정 많이 풀기의 함정
코딩 테스트 준비에서 가장 흔한 조언은 "문제를 많이 풀어라"입니다. 틀린 말은 아닙니다. 하지만 절반만 맞는 말입니다. 문제를 많이 푸는 것보다 더 중요한 것은 문제를 푼 뒤 무엇을 남기느냐입니다.
하루에 열 문제를 풀었지만 모두 비슷한 방식으로 대충 넘겼다면 실력은 크게 늘지 않습니다. 반대로 하루에 두 문제를 풀더라도, 문제를 읽는 법, 풀이를 떠올리는 과정, 실패한 이유, 다른 풀이와의 차이, 시간 복잡도를 정리했다면 훨씬 단단한 실력이 쌓입니다.
코딩 테스트 공부는 운동과 비슷합니다. 무거운 기구를 많이 들었다고 무조건 몸이 좋아지는 것이 아닙니다. 자세가 틀어져 있으면 부상만 늘어납니다. 문제 풀이도 마찬가지입니다. 잘못된 습관으로 많은 문제를 풀면, 시험장에서 같은 실수를 반복하게 됩니다.
좋은 학습은 다음 흐름을 가집니다.
먼저 스스로 문제를 이해하고 최소한의 풀이를 시도한다.
막혔다면 정답을 보기 전에 작은 예제와 입력 크기를 다시 확인한다.
풀이를 본 뒤에는 코드를 외우지 말고 핵심 아이디어를 자기 말로 설명한다.
같은 유형의 문제를 며칠 뒤 다시 풀어 기억이 아니라 이해로 풀리는지 확인한다.
특히 "정답 코드를 읽고 이해했다"는 느낌을 조심해야 합니다. 남의 코드는 읽으면 쉬워 보입니다. 이미 길이 나 있기 때문입니다. 그러나 시험장에서 필요한 능력은 빈 화면에서 첫 줄을 쓰는 능력입니다. 정답을 본 문제는 반드시 다시 풀어야 합니다. 가능하다면 다음 날, 일주일 뒤처럼 시간을 두고 다시 푸는 것이 좋습니다.
초급자가 빠지기 쉬운 함정
초급자는 보통 알고리즘 이름에 압도됩니다. 그래프, 동적 계획법, 백트래킹, 최단 경로, 유니온 파인드 같은 단어를 보면 시작하기도 전에 겁이 납니다. 그래서 기초 구현이 부족한 상태에서 어려운 강의나 고난도 문제로 뛰어들곤 합니다. 이때 공부는 많이 하는데 풀 수 있는 문제는 늘지 않는 이상한 상태가 됩니다.
초급자에게 가장 중요한 것은 어려운 문제를 많이 보는 것이 아니라 쉬운 문제를 확실하게 맞히는 경험입니다. 배열을 순회하고, 조건을 나누고, 문자열을 다루고, 빈도수를 세고, 정렬한 뒤 비교하는 문제를 충분히 풀어야 합니다. 쉬운 문제를 무시하면 중간 난도 문제에서 작은 구현 실수로 계속 무너집니다.
또 다른 함정은 문법 공부와 문제 풀이를 분리하는 것입니다. 문법 책을 끝까지 본 다음 문제를 풀겠다고 마음먹으면 시작이 늦어집니다. 코딩 테스트에 필요한 문법은 문제를 풀면서 익히는 편이 더 효율적입니다. 리스트, 딕셔너리, 집합, 정렬, 반복문, 함수, 입출력처럼 자주 쓰는 기능부터 손에 익히면 됩니다.
초급자는 다음 기준으로 공부하면 좋습니다. 한 문제를 풀 때 정답 여부만 보지 말고, 문제를 읽고 입력과 출력을 직접 예제로 따라갈 수 있는지 확인합니다. 코드가 틀렸다면 에러 메시지를 읽고 어디서 잘못됐는지 추적합니다. 풀이를 본 뒤에는 같은 유형의 쉬운 문제를 하나 더 풀어 아이디어를 내 것으로 만듭니다.
실무 개발자가 빠지기 쉬운 함정
실무 개발자는 초급자와 다른 함정에 빠집니다. 이미 개발 경험이 있으므로 코딩 테스트도 금방 적응할 것이라고 생각하기 쉽습니다. 하지만 실무 개발과 코딩 테스트는 사용하는 근육이 조금 다릅니다.
실무에서는 프레임워크, 데이터베이스, API, 배포, 장애 대응, 협업이 중요합니다. 반면 코딩 테스트에서는 짧은 시간 안에 작은 문제를 독립적으로 해결하는 능력이 중요합니다. 실무에서는 검색과 문서 확인이 자연스럽지만, 코딩 테스트에서는 기본 자료구조와 알고리즘을 즉시 떠올려야 합니다.
실무 개발자는 과도하게 일반화된 코드를 작성하려는 경향도 있습니다. 문제 하나를 풀기 위해 클래스를 여러 개 만들고, 확장성을 고려하고, 지나치게 추상화하다가 시간이 부족해질 수 있습니다. 코딩 테스트 코드는 제품 코드가 아닙니다. 읽기 쉽고 정확해야 하지만, 미래의 모든 변경을 대비할 필요는 없습니다.
또 하나의 함정은 "이런 건 실무에서 안 쓰는데"라는 생각입니다. 물론 모든 알고리즘을 매일 업무에서 직접 구현하지는 않습니다. 그러나 코딩 테스트는 특정 알고리즘 자체보다 문제를 구조화하는 사고를 평가합니다. 해시를 이용해 조회를 빠르게 만들고, 큐로 처리 순서를 관리하고, 그래프로 관계를 표현하고, 동적 계획법으로 중복 계산을 줄이는 방식은 실무에서도 다양한 형태로 나타납니다.
실무 개발자는 기본 유형을 빠르게 복습한 뒤, 시간 제한을 두고 실전 감각을 회복하는 데 집중하는 것이 좋습니다. 특히 최근 몇 년간 알고리즘 문제를 풀지 않았다면, 쉬운 문제부터 다시 푸는 것을 부끄러워할 필요가 없습니다. 손이 굳었을 뿐, 기초가 다시 살아나면 학습 속도는 빠르게 올라갑니다.
준비 순서는 어떻게 잡아야 할까
코딩 테스트 공부에는 순서가 있습니다. 처음부터 어려운 알고리즘을 공부하면 개념은 알지만 문제에 적용하지 못합니다. 반대로 구현 문제만 오래 풀면 새로운 유형을 만났을 때 막힙니다. 기본기를 쌓고, 자주 나오는 도구를 익히고, 유형별 사고법을 연습한 뒤, 실전 모의고사로 마무리하는 흐름이 좋습니다.
가장 먼저 해야 할 일은 사용하는 언어를 정하는 것입니다. 코딩 테스트에서는 익숙한 언어가 가장 강력합니다. 파이썬, 자바, 자바스크립트, C++ 등 어떤 언어든 가능하지만, 시험 플랫폼과 기업의 허용 언어를 확인해야 합니다. 언어를 정했다면 기본 입출력, 배열과 문자열 처리, 정렬, 해시, 스택과 큐 같은 핵심 기능을 빠르게 익혀야 합니다.
그다음에는 시간 복잡도 감각을 함께 키워야 합니다. 문제를 풀 때마다 내 풀이가 O(N), O(N log N), O(N^2) 중 어디에 가까운지 말해보는 연습을 합니다. 정확한 증명까지 매번 할 필요는 없지만, 입력 크기와 풀이의 가능성을 연결하는 습관은 반드시 필요합니다.
이후에는 유형별 학습으로 넘어갑니다. 완전 탐색, 재귀와 백트래킹, 그래프 탐색, 그리디, 동적 계획법, 최단 경로, 트리와 유니온 파인드처럼 자주 등장하는 주제를 차례로 익힙니다. 중요한 것은 한 유형을 공부할 때 대표 문제 몇 개를 깊게 풀어보는 것입니다. 유형 이름만 외우면 실제 문제에서 알아보지 못합니다.
마지막 단계는 실전 훈련입니다. 제한 시간을 두고 여러 문제를 연속으로 풉니다. 이때 목표는 모든 문제를 완벽하게 푸는 것이 아니라, 쉬운 문제를 놓치지 않고, 막히는 문제에서 시간을 관리하며, 시험 후 리뷰로 약점을 찾아내는 것입니다.
4주 준비 로드맵: 시간이 부족할 때의 압축 전략
4주는 짧습니다. 이 기간에는 모든 알고리즘을 깊게 공부하려고 하면 오히려 실패합니다. 목표를 분명히 해야 합니다. 기본 문제를 안정적으로 맞히고, 자주 나오는 유형에서 최소한의 대응력을 갖추는 것이 핵심입니다.
첫 주에는 언어와 구현 기본기를 다집니다. 입출력, 배열, 문자열, 정렬, 해시, 스택과 큐를 집중적으로 연습합니다. 쉬운 문제와 중간 이하 난도 문제를 풀면서 실수를 줄이는 데 집중합니다. 이 시기에는 어려운 문제를 오래 붙잡기보다 기본 패턴을 많이 만나보는 것이 좋습니다.
둘째 주에는 완전 탐색, 재귀, 백트래킹, 그래프 탐색을 공부합니다. 코딩 테스트에서 매우 자주 등장하는 영역입니다. 특히 BFS와 DFS는 반드시 손으로 구현할 수 있어야 합니다. 격자 지도에서 상하좌우로 이동하는 문제, 연결 요소를 세는 문제, 최단 이동 횟수를 구하는 기본 문제를 반복해 풀어야 합니다.
셋째 주에는 그리디와 동적 계획법의 기본을 익힙니다. 이 두 주제는 처음에는 감이 잘 오지 않습니다. 그래서 너무 어려운 문제보다 대표적인 쉬운 문제를 통해 "왜 이 선택이 안전한가", "어떤 값을 저장하면 중복 계산을 줄일 수 있는가"를 이해하는 데 집중합니다.
넷째 주에는 실전 모의고사를 반복합니다. 실제 시험 시간과 비슷하게 2~4문제를 묶어서 풀고, 끝난 뒤에는 반드시 리뷰합니다. 틀린 문제를 다시 풀고, 시간 초과가 난 풀이의 복잡도를 계산하고, 구현 실수를 따로 기록합니다. 마지막 주에 새로운 고난도 개념을 무리하게 넣기보다, 이미 공부한 유형의 정답률을 높이는 편이 효과적입니다.
4주 과정에서는 포기할 것을 정하는 것도 전략입니다. 모든 고급 주제를 완벽히 다루기는 어렵습니다. 대신 정렬, 해시, 스택·큐, 완전 탐색, BFS·DFS, 기본 그리디, 기본 동적 계획법을 우선순위로 삼는 것이 좋습니다.
8주 준비 로드맵: 기본기와 유형 학습의 균형
8주는 가장 현실적인 준비 기간입니다. 기본기를 다지고, 주요 유형을 한 번씩 학습하고, 실전 연습까지 할 수 있습니다. 단, 계획 없이 문제만 풀면 8주도 금방 지나갑니다.
1~2주 차에는 구현 기본기와 시간 복잡도 감각을 만듭니다. 배열, 문자열, 정렬, 탐색, 해시, 집합, 스택, 큐를 다룹니다. 이때는 쉬운 문제를 빠르게 정확히 푸는 연습을 합니다. 문제를 풀 때마다 입력 크기를 보고 가능한 풀이를 예상하는 습관도 함께 들입니다.
3~4주 차에는 완전 탐색, 재귀, 백트래킹, BFS, DFS를 집중적으로 공부합니다. 이 구간은 많은 학습자가 실력이 눈에 띄게 오르는 시기입니다. 왜냐하면 단순 구현에서 벗어나 "상태를 탐색한다"는 감각을 배우기 때문입니다. 순열과 조합, 격자 탐색, 그래프 연결 관계, 방문 처리 같은 개념을 확실히 익혀야 합니다.
5~6주 차에는 그리디와 동적 계획법을 다룹니다. 그리디는 정렬과 함께 나오는 경우가 많고, 동적 계획법은 점화식이라는 형태로 문제를 재구성해야 합니다. 둘 다 풀이를 외우기보다 조건을 해석하는 연습이 중요합니다. 특히 동적 계획법은 "무엇을 상태로 둘 것인가"를 말로 설명하는 훈련을 해야 합니다.
7주 차에는 최단 경로, 우선순위 큐, 트리, 유니온 파인드처럼 조금 더 확장된 주제를 공부합니다. 모든 문제를 깊게 파고들기보다 대표 패턴을 익히는 것이 목표입니다. 예를 들어 다익스트라 알고리즘은 "현재까지 가장 비용이 작은 후보를 우선 처리한다"는 흐름을 이해하고, 우선순위 큐 구현에 익숙해져야 합니다.
8주 차에는 실전 모의고사와 오답 정리에 집중합니다. 실제 시험처럼 시간을 재고 풀며, 문제 선택 전략을 연습합니다. 리뷰할 때는 틀린 이유를 단순히 "몰랐다"라고 쓰지 말고 더 구체적으로 적어야 합니다. 조건을 잘못 읽었는지, 시간 복잡도를 놓쳤는지, 자료구조 선택이 틀렸는지, 구현에서 실수했는지 분류해야 다음 학습이 정확해집니다.
8주 로드맵의 핵심은 반복입니다. 한 번 배운 유형을 다음 주에 다시 만나야 합니다. 오늘 이해한 풀이도 일주일 뒤에는 희미해집니다. 다시 풀었을 때 손이 움직여야 진짜 실력입니다.
12주 준비 로드맵: 안정적인 합격권을 목표로
12주는 충분한 기간입니다. 이 시간을 잘 활용하면 기본기뿐 아니라 중상급 문제에 대한 대응력도 만들 수 있습니다. 다만 기간이 길수록 느슨해지기 쉽습니다. 주차별 목표와 복습 루틴을 분명히 해야 합니다.
1~3주 차에는 기초 구현과 자료구조를 탄탄하게 다집니다. 입출력, 문자열, 배열, 정렬, 이분 탐색, 해시, 집합, 스택, 큐, 덱을 공부합니다. 이 시기에 쉬운 문제를 많이 풀면서 실수를 줄여야 합니다. 목표는 "쉬운 문제는 반드시 맞힌다"입니다. 합격과 불합격은 어려운 한 문제보다 쉬운 문제를 놓쳤는지에서 갈리는 경우가 많습니다.
4~5주 차에는 완전 탐색, 재귀, 백트래킹을 공부합니다. 가능한 경우를 모두 살펴보는 문제에서 어떤 기준으로 가지를 줄일 수 있는지 배웁니다. 이때부터는 문제를 풀기 전에 상태, 선택, 종료 조건을 말로 정리하는 습관을 들이면 좋습니다.
6~7주 차에는 그래프 탐색을 집중적으로 다룹니다. BFS와 DFS는 코딩 테스트의 중심 도구입니다. 격자, 네트워크, 연결 요소, 최단 이동 횟수, 사이클 확인 등 다양한 형태로 등장합니다. 그래프 문제는 입력을 어떤 구조로 저장할지부터 중요하므로 인접 리스트, 방문 배열, 큐와 스택 사용에 익숙해져야 합니다.
8~9주 차에는 그리디와 동적 계획법을 깊게 공부합니다. 이 구간은 가장 어렵게 느껴질 수 있습니다. 그리디는 선택의 정당성을 확인해야 하고, 동적 계획법은 상태 정의와 점화식이 핵심입니다. 문제를 풀고 나면 반드시 "왜 이 풀이가 맞는가"를 짧게라도 설명해보세요. 설명할 수 없으면 비슷한 변형 문제에서 흔들립니다.
10주 차에는 최단 경로, 우선순위 큐, 트리, 유니온 파인드, 최소 신장 트리 같은 확장 주제를 공부합니다. 이 주제들은 모든 기업 시험에 항상 나오는 것은 아니지만, 출제되면 모르면 풀기 어렵습니다. 대표 문제를 통해 기본 구현과 사용 조건을 익히는 것이 좋습니다.
11주 차에는 고급 패턴과 약점 보완에 집중합니다. 투 포인터, 슬라이딩 윈도우, 누적 합, 비트마스크, 위상 정렬 같은 패턴을 필요에 따라 보강합니다. 지금까지의 오답 노트를 보고 자주 틀린 유형을 다시 풉니다. 이때 새 문제만 찾기보다 틀렸던 문제를 다시 푸는 것이 훨씬 효과적입니다.
12주 차에는 실전 모드로 전환합니다. 최소 두세 번은 실제 시험처럼 시간을 정하고 모의고사를 치릅니다. 문제를 풀 때는 쉬운 문제부터 확실히 맞히고, 막히는 문제에 시간을 얼마나 쓸지 정합니다. 시험 후에는 풀이뿐 아니라 시간 사용도 리뷰합니다. "1번 문제에서 40분을 썼는데 왜 그랬는가?", "3번 문제는 10분 더 봤으면 풀 수 있었는가, 아니면 빨리 넘겼어야 했는가?" 같은 질문이 실전 점수를 올립니다.
12주 과정에서는 실력의 층을 쌓을 수 있습니다. 처음 4주는 손을 만들고, 다음 4주는 사고의 도구를 늘리고, 마지막 4주는 실전 판단력을 기릅니다. 이 흐름을 지키면 단순히 많은 문제를 푼 사람보다 훨씬 안정적인 실력을 갖게 됩니다.
매일의 공부 루틴 만들기
준비 기간이 4주든 12주든, 결국 실력을 만드는 것은 하루의 루틴입니다. 긴 계획은 멋있어 보이지만, 오늘 무엇을 할지 정해져 있지 않으면 쉽게 무너집니다.
하루 공부는 가볍게 시작하는 것이 좋습니다. 먼저 이전에 틀렸던 쉬운 문제나 짧은 구현 문제로 손을 풉니다. 그다음 오늘의 주제 문제를 풉니다. 문제를 풀 때는 시간을 정해두세요. 예를 들어 30분 동안 고민해도 방향이 잡히지 않으면 힌트를 보거나 풀이를 확인합니다. 단, 풀이를 본 뒤에는 반드시 다시 구현해야 합니다.
공부의 마지막에는 기록이 필요합니다. 거창한 오답 노트를 만들 필요는 없습니다. 짧아도 괜찮습니다. 문제의 핵심 아이디어, 내가 막힌 지점, 시간 복잡도, 다시 풀 날짜를 적으면 충분합니다. 중요한 것은 기록이 다음 행동으로 이어지는 것입니다.
예를 들어 "BFS 문제인데 방문 처리를 큐에 넣을 때 하지 않고 꺼낼 때 해서 중복 방문이 많아졌다"라고 적었다면, 다음 BFS 문제에서는 방문 처리 위치를 의식하게 됩니다. 이런 작은 수정이 쌓이면 실수가 줄어듭니다.
좋은 루틴은 다음 세 가지를 포함합니다.
새로운 문제를 풀며 사고 범위를 넓힌다.
틀린 문제를 다시 풀며 약점을 줄인다.
시간 제한을 두고 풀며 실전 감각을 유지한다.
매일 오래 공부할 수 없다면 짧게라도 꾸준히 하는 편이 좋습니다. 코딩 테스트 실력은 벼락치기로도 일부 오를 수 있지만, 안정적인 구현 감각은 반복에서 나옵니다. 손이 기억할 만큼 자주 코드를 써야 합니다.
문제를 풀 때의 기본 절차
앞으로 이 책에서 여러 알고리즘과 자료구조를 배우겠지만, 어떤 문제를 만나든 기본 절차는 비슷합니다. 이 절차를 몸에 익히면 낯선 문제를 만나도 덜 당황합니다.
먼저 문제의 요구사항을 자신의 말로 바꿉니다. 입력으로 무엇이 들어오고, 출력으로 무엇을 내야 하는지 확인합니다. 조건에서 중요한 숫자를 표시합니다. N이 얼마인지, 값의 범위가 어떤지, 시간 제한이 있는지 봅니다.
그다음 가장 단순한 풀이를 생각합니다. 모든 경우를 다 해보면 풀리는지 확인합니다. 이 단순한 풀이가 시간 안에 가능하면 굳이 복잡한 알고리즘을 쓸 필요가 없습니다. 불가능하다면 왜 느린지 살펴보고, 어떤 계산을 줄일 수 있는지 생각합니다.
이후 적절한 자료구조나 알고리즘을 선택합니다. 빠른 조회가 필요하면 해시를, 최근에 들어온 것을 먼저 처리해야 하면 스택을, 순서대로 처리해야 하면 큐를, 최솟값이나 최댓값을 반복해서 꺼내야 하면 우선순위 큐를 고려합니다. 연결 관계를 따라가야 하면 그래프로 보고, 중복되는 부분 문제가 있으면 동적 계획법을 의심합니다.
코드를 작성한 뒤에는 예제로만 확인하지 말고 직접 작은 반례를 만들어야 합니다. 빈 입력에 가까운 경우, 값이 하나뿐인 경우, 모두 같은 값인 경우, 이미 정렬된 경우, 반대로 정렬된 경우처럼 경계 상황을 확인합니다. 많은 오답은 알고리즘을 몰라서가 아니라 이런 작은 조건을 놓쳐서 발생합니다.
마지막으로 시간 복잡도와 공간 복잡도를 다시 확인합니다. 제출 전에 이 검사를 하는 습관이 있으면 시간 초과나 메모리 초과를 줄일 수 있습니다.
합격을 위한 태도: 많이보다 정확하게, 빠르게보다 안정적으로
코딩 테스트를 준비하다 보면 조급해집니다. 다른 사람은 어려운 문제를 푸는 것 같고, 나는 쉬운 문제에서도 자꾸 틀립니다. 하지만 실력은 보통 계단식으로 오릅니다. 한동안 제자리처럼 느껴지다가 어느 순간 비슷한 문제가 보이기 시작합니다. 예전에는 막막했던 문제에서 "이건 정렬 후 비교해볼 수 있겠다", "여기서는 BFS가 맞겠다", "이 상태를 저장하면 DP가 되겠다"라는 생각이 떠오릅니다.
그 순간을 만들기 위해서는 공부의 방향이 중요합니다. 무작정 문제 수를 늘리는 대신, 문제를 읽는 법, 풀이를 세우는 법, 시간 복잡도를 판단하는 법, 구현 실수를 줄이는 법을 함께 훈련해야 합니다. 코딩 테스트는 암기 시험이 아니라 문제 해결 절차를 반복해서 재현하는 시험입니다.
이 책은 그 절차를 하나씩 쌓아가도록 구성되어 있습니다. 다음 장에서는 문제를 어떻게 읽고, 어떻게 쪼개고, 어떤 순서로 풀이를 만들어갈지 다룹니다. 알고리즘 이름을 외우기 전에 먼저 문제를 바라보는 눈을 만들어야 합니다. 그 눈이 생기면 이후에 배우는 자료구조와 알고리즘은 단순한 지식이 아니라 실제 문제를 여는 도구가 됩니다.
지금 필요한 것은 거창한 결심이 아닙니다. 오늘 풀 한 문제, 오늘 정리할 한 가지 실수, 오늘 다시 확인할 하나의 개념입니다. 그렇게 쌓은 작은 반복이 시험장에서 가장 믿을 만한 무기가 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.