코드를 치기 전에 승부가 난다
코딩 테스트를 처음 준비할 때 가장 흔한 착각은 "빨리 코드를 쓰는 사람이 유리하다"는 생각입니다. 물론 구현 속도는 중요합니다. 하지만 더 중요한 것은 무엇을 구현해야 하는지 정확히 아는 것입니다. 문제를 잘못 이해한 채로 빠르게 작성한 코드는, 아무리 문법적으로 완벽해도 정답이 될 수 없습니다.
코딩 테스트 문제는 보통 짧은 이야기처럼 시작합니다. 택배 상자가 움직이고, 사람이 줄을 서고, 지도 위에서 로봇이 이동하고, 숫자들이 어떤 규칙에 따라 바뀝니다. 하지만 개발자가 읽어야 할 것은 이야기의 겉모습이 아닙니다. 그 안에 숨어 있는 입력, 출력, 조건, 반복되는 구조, 선택해야 할 기준입니다.
문제를 읽는다는 것은 단순히 문장을 이해하는 일이 아닙니다. 문제를 계산 가능한 형태로 바꾸는 일입니다. 이 장에서는 문제를 처음 만났을 때 어떤 순서로 생각해야 하는지, 예제만 보고 함정에 빠지지 않으려면 무엇을 확인해야 하는지, 정답 풀이가 바로 떠오르지 않을 때 어떻게 브루트포스에서 최적화로 나아가야 하는지 살펴보겠습니다.
문제를 읽을 때 먼저 분리해야 할 것들
문제를 처음 읽을 때는 전체 내용을 한 번에 이해하려고 하지 않아도 됩니다. 오히려 처음부터 모든 것을 완벽히 이해하려고 하면 중요한 정보와 부가적인 설명이 뒤섞여 머릿속이 복잡해집니다. 먼저 문제를 네 부분으로 나누어 보아야 합니다.
입력으로 무엇이 주어지는가
출력으로 무엇을 요구하는가
제한 조건은 어느 정도인가
중간 과정에서 지켜야 할 규칙은 무엇인가
예를 들어 "학생들의 점수가 주어졌을 때 평균 이상인 학생 수를 구하라"는 문제가 있다고 해봅시다. 이 문제에서 입력은 학생 수와 점수 목록입니다. 출력은 평균 이상인 학생 수입니다. 제한 조건은 학생 수의 최대값과 점수의 범위입니다. 중간 규칙은 평균을 계산한 뒤 각 점수를 비교해야 한다는 점입니다.
이렇게 분리하면 문제는 더 이상 긴 문장이 아니라 처리 절차가 됩니다. 컴퓨터가 해야 할 일은 결국 데이터를 받아서, 규칙에 따라 처리하고, 원하는 값을 내보내는 것입니다.
특히 출력 조건은 반드시 정확히 읽어야 합니다. "최댓값을 출력하라"인지, "최댓값을 만드는 경우의 수를 출력하라"인지, "최댓값의 위치를 출력하라"인지에 따라 풀이는 완전히 달라집니다. 사람은 비슷하게 느낄 수 있지만, 코드는 이 차이를 절대 알아서 보정해주지 않습니다.
입력과 출력은 풀이의 출발점이다
입력 형식을 읽을 때는 단순히 변수 이름만 보는 것이 아니라 데이터의 모양을 상상해야 합니다. 숫자 하나인지, 배열인지, 2차원 격자인지, 문자열인지, 관계 정보인지에 따라 사용할 수 있는 사고 도구가 달라집니다.
예를 들어 다음과 같은 입력들이 있다고 생각해봅시다.
5
1 3 2 5 4이 입력은 숫자 목록을 다루는 문제일 가능성이 큽니다. 정렬, 최댓값·최솟값, 누적합, 투 포인터 같은 접근을 떠올릴 수 있습니다.
반면 다음과 같은 입력이라면 어떨까요?
4 4
0100
1110
0010
0000이것은 격자 문제일 가능성이 큽니다. 위, 아래, 왼쪽, 오른쪽으로 이동하는 탐색 문제가 될 수 있고, BFS나 DFS를 떠올릴 수 있습니다.
또 이런 입력도 있습니다.
5 4
1 2
1 3
2 4
3 5두 숫자의 쌍이 여러 줄 주어진다면 관계를 나타내는 문제일 수 있습니다. 사람과 사람의 연결, 도시와 도로, 작업의 선후 관계처럼 그래프 구조를 의심해야 합니다.
이처럼 입력의 모양은 알고리즘 후보를 좁히는 첫 번째 힌트입니다. 문제의 설명이 길고 복잡해도, 입력이 배열이라면 배열 문제로, 격자라면 탐색 문제로, 쌍의 나열이라면 그래프 문제로 번역할 수 있습니다.
출력도 마찬가지입니다. 출력이 "가능하면 1, 불가능하면 0"이라면 판별 문제입니다. 출력이 "최소 횟수"라면 최단 거리, BFS, 그리디, 동적 계획법을 의심할 수 있습니다. 출력이 "경우의 수"라면 조합, DP, 백트래킹, 모듈러 연산이 등장할 수 있습니다. 출력이 "가장 큰 값" 또는 "가장 작은 값"이라면 최적화 문제입니다.
문제를 읽으며 "이 문제는 무엇을 묻고 있는가?"라고 질문해야 합니다. 합을 묻는가, 개수를 묻는가, 가능 여부를 묻는가, 최솟값을 묻는가, 순서를 묻는가. 이 질문에 답하면 풀이 방향의 절반은 정리됩니다.
제한 조건은 알고리즘의 속도 제한 표지판이다
코딩 테스트 문제에서 제한 조건은 장식이 아닙니다. 제한 조건은 출제자가 "이 정도 크기의 입력이 들어올 수 있다"고 알려주는 표지판입니다. 그리고 이 표지판을 제대로 읽어야 시간 초과를 피할 수 있습니다.
예를 들어 배열의 길이 N이 최대 100이라면 모든 쌍을 비교하는 O(N²) 풀이도 충분히 가능할 수 있습니다. 100개의 원소에서 모든 쌍은 약 10,000개 정도이기 때문입니다. 하지만 N이 100,000이라면 이야기가 완전히 달라집니다. 모든 쌍을 비교하면 약 10,000,000,000번, 즉 100억 번에 가까운 연산이 필요합니다. 일반적인 코딩 테스트 환경에서는 매우 위험합니다.
제한 조건을 볼 때는 다음처럼 머릿속으로 대략적인 후보를 세울 수 있어야 합니다.
N이 20 이하라면 부분집합, 순열, 백트래킹 같은 완전 탐색을 고려할 수 있습니다.N이 1,000 정도라면O(N²)풀이가 가능할 때가 많습니다.N이 100,000 이상이라면 보통O(N log N)이나O(N)에 가까운 풀이를 생각해야 합니다.값의 범위가 매우 크고 개수는 적다면 정렬, 해시, 좌표 압축을 고려할 수 있습니다.
그래프에서 정점과 간선 수가 크다면 인접 행렬보다 인접 리스트가 적합한 경우가 많습니다.
물론 이것은 절대적인 규칙이 아니라 감각을 잡기 위한 기준입니다. 실제 가능 여부는 언어, 시간 제한, 연산의 복잡도에 따라 달라집니다. 하지만 문제를 보자마자 "이중 반복문은 괜찮을까?", "정렬을 해도 될까?", "모든 경우를 다 세면 터질까?"를 판단하는 습관은 매우 중요합니다.
제한 조건은 풀이를 막는 벽이 아니라 방향을 알려주는 나침반입니다. 입력이 작으면 단순하게 풀 수 있고, 입력이 크면 더 영리한 구조를 찾아야 합니다.
예제 입출력은 정답 보증서가 아니다
많은 수험자가 예제 입출력에 맞으면 풀이가 맞다고 생각합니다. 하지만 예제는 문제 이해를 돕기 위한 샘플일 뿐, 모든 경우를 대표하지 않습니다. 예제는 대개 친절합니다. 너무 작고, 너무 정직하고, 너무 보기 좋습니다. 실제 채점 데이터는 훨씬 까다롭습니다.
예제만 믿고 제출하면 자주 만나는 문제가 있습니다. 가장 대표적인 것은 경계값을 놓치는 경우입니다. 배열의 길이가 1일 때, 값이 모두 같을 때, 답이 존재하지 않을 때, 입력이 이미 정렬되어 있을 때, 반대로 완전히 역순일 때 같은 상황입니다. 예제에는 이런 경우가 빠져 있을 수 있습니다.
예를 들어 "가장 큰 두 수의 합을 구하라"는 문제가 있다고 해봅시다. 예제가 1 5 3 2라면 답은 쉽게 8입니다. 그런데 입력이 5 5 5일 때는 어떨까요? 같은 값을 두 번 선택할 수 있는지, 서로 다른 위치의 원소라면 같은 값이어도 되는지 확인해야 합니다. 입력이 숫자 하나뿐이라면 어떻게 해야 할까요? 문제에서 최소 개수를 보장하는지도 봐야 합니다.
반례를 찾는 습관은 실력을 빠르게 끌어올립니다. 반례란 내 풀이가 틀리는 입력입니다. 좋은 반례는 대개 복잡하지 않습니다. 오히려 아주 작고 단순한 입력에서 많이 나옵니다.
반례를 만들 때는 다음과 같은 상황을 의식적으로 확인해보면 좋습니다.
가장 작은 입력 크기
가장 큰 입력 크기에 가까운 구조
모든 값이 같은 경우
값이 하나만 다른 경우
이미 정렬된 경우와 역순인 경우
답이 0이거나 존재하지 않는 경우
여러 정답이 가능한 경우
특히 "내 코드가 운 좋게 예제만 맞은 것은 아닌가?"라는 의심을 가져야 합니다. 이 의심은 불안이 아니라 실전에서 점수를 지키는 안전장치입니다.
문제를 작은 단계로 쪼개는 법
문제가 어렵게 느껴지는 이유는 대부분 한 번에 너무 많은 일을 하려고 하기 때문입니다. "이 문제를 풀어야 한다"라고 생각하면 막막하지만, "입력을 배열로 저장한다", "각 원소를 확인한다", "조건을 만족하면 개수를 늘린다"처럼 나누면 훨씬 다루기 쉬워집니다.
문제를 작은 단계로 분해하는 가장 좋은 방법은 먼저 사람의 말로 절차를 써보는 것입니다. 이때 아직 코드 문법을 신경 쓰지 않아도 됩니다. 중요한 것은 흐름입니다.
예를 들어 "배열에서 합이 K인 두 수가 존재하는지 확인하라"는 문제가 있다고 합시다. 곧바로 코드를 쓰지 말고 다음처럼 생각할 수 있습니다.
1. 숫자 목록을 입력받는다.
2. 각 숫자 x를 하나씩 확인한다.
3. 이전에 K - x가 나온 적 있는지 확인한다.
4. 있다면 두 수의 합이 K가 되므로 가능하다고 판단한다.
5. 없다면 현재 숫자 x를 기록한다.
6. 끝까지 찾지 못하면 불가능하다고 판단한다.이것이 의사코드입니다. 의사코드는 실제 프로그래밍 언어는 아니지만, 코드에 가까운 생각의 설계도입니다. 의사코드를 쓰면 머릿속의 막연한 아이디어가 실행 가능한 절차로 바뀝니다.
좋은 의사코드는 너무 추상적이지 않아야 합니다. "잘 처리한다", "적절히 비교한다" 같은 표현은 도움이 되지 않습니다. 무엇을 저장하고, 무엇과 비교하고, 언제 답을 갱신하는지 드러나야 합니다.
예를 들어 다음 문장은 좋지 않습니다.
배열을 잘 탐색해서 답을 찾는다.반면 다음 문장은 훨씬 좋습니다.
왼쪽부터 원소를 하나씩 보면서, 현재까지 본 값 중 필요한 값이 있었는지 해시 집합에서 확인한다.이 정도로 정리되면 구현은 훨씬 쉬워집니다. 코드는 생각을 대신해주지 않습니다. 이미 정리된 생각을 정확히 실행할 뿐입니다.
브루트포스는 실패한 풀이가 아니라 출발점이다
많은 사람이 브루트포스, 즉 모든 경우를 다 해보는 풀이를 낮게 평가합니다. 하지만 실제 문제 해결에서는 브루트포스가 매우 중요합니다. 정답 풀이가 바로 떠오르지 않을 때 가장 먼저 해야 할 일은 "가장 단순하게 풀면 어떻게 되는가?"를 생각하는 것입니다.
브루트포스는 두 가지 장점이 있습니다. 첫째, 문제의 의미를 정확히 이해하게 해줍니다. 둘째, 더 빠른 풀이를 찾기 위한 기준이 됩니다.
예를 들어 배열에서 합이 K인 두 수를 찾는 문제를 생각해봅시다. 가장 단순한 방법은 모든 쌍을 확인하는 것입니다.
for i from 0 to N-1:
for j from i+1 to N-1:
if arr[i] + arr[j] == K:
return true
return false이 풀이는 O(N²)입니다. N이 작다면 그대로 통과할 수 있습니다. 하지만 N이 100,000이라면 어렵습니다. 그러면 다음 질문을 던져야 합니다.
"정말 모든 쌍을 확인해야 할까?"
두 수의 합이 K가 되려면, 현재 수가 x일 때 필요한 다른 수는 K - x입니다. 그렇다면 이전에 본 숫자 중 K - x가 있었는지만 빠르게 확인하면 됩니다. 이때 해시 집합을 사용하면 평균적으로 빠른 조회가 가능합니다.
이렇게 브루트포스에서 최적화로 이동하는 과정은 다음과 같습니다.
모든 쌍을 확인한다.
→ 중복되는 확인이 많다는 것을 발견한다.
→ 현재 값에 대해 필요한 값만 찾으면 된다고 바꿔 생각한다.
→ 빠른 조회가 가능한 자료구조를 사용한다.즉, 최적화는 하늘에서 떨어지는 번뜩임이 아닙니다. 느린 풀이를 적어보고, 그 안에서 반복되는 낭비를 찾아 줄이는 과정입니다.
느린 풀이에서 빠른 풀이로 가는 질문들
정답 풀이가 떠오르지 않을 때는 가만히 머리를 싸매기보다 질문을 바꿔야 합니다. 좋은 질문은 생각의 방향을 열어줍니다.
가장 먼저 할 질문은 "입력이 작다면 어떻게 풀 수 있는가?"입니다. 입력이 아주 작다고 가정하면 대부분의 문제는 풀 수 있습니다. 모든 순서를 만들어보거나, 모든 구간을 확인하거나, 모든 위치에서 시작해보면 됩니다. 이 단순한 풀이를 먼저 세우면 문제의 본질이 보입니다.
그다음 질문은 "어디에서 시간이 많이 쓰이는가?"입니다. 이중 반복문이 문제라면 안쪽 반복문을 없앨 방법을 찾습니다. 매번 합을 다시 구하고 있다면 누적합을 고려합니다. 매번 최솟값을 찾고 있다면 힙이나 정렬을 고려합니다. 매번 존재 여부를 확인하고 있다면 해시를 고려합니다.
이런 식으로 자주 등장하는 최적화 방향이 있습니다.
반복해서 찾는 값이 있다면 해시나 집합을 사용한다.
구간의 합을 자주 구한다면 누적합을 사용한다.
정렬했을 때 관계가 단순해진다면 먼저 정렬한다.
최솟값이나 최댓값을 계속 꺼내야 한다면 우선순위 큐를 사용한다.
같은 계산을 반복한다면 동적 계획법으로 저장한다.
모든 경로를 확인해야 한다면 BFS나 DFS로 상태를 체계적으로 탐색한다.
이 목록을 외우는 것보다 중요한 것은 연결 감각입니다. "느린 이유가 무엇인가?"를 찾고, 그 느린 부분을 줄여주는 도구를 선택하는 것입니다.
조건문 하나에도 문제 해석이 들어 있다
초보자가 작성한 코드를 보면 반복문 구조는 맞는데 조건문에서 틀리는 경우가 많습니다. >=인지 >인지, <=인지 <인지, 같은 값을 허용하는지, 시작점을 포함하는지 제외하는지 같은 작은 차이가 오답을 만듭니다.
예를 들어 "길이가 K 이상인 구간"이라는 말과 "길이가 K인 구간"이라는 말은 다릅니다. "이하"와 "미만"도 다릅니다. "서로 다른 두 원소"라는 말은 인덱스가 달라야 한다는 뜻이지 값이 반드시 달라야 한다는 뜻은 아닐 수 있습니다. "연속된 부분 배열"은 중간을 건너뛸 수 없지만, "부분 수열"은 원래 순서를 유지하면서 일부를 고를 수 있습니다.
이런 표현들은 문제에서 자주 함정이 됩니다. 문제를 읽다가 조건을 발견하면 머릿속으로만 넘기지 말고 풀이 설계에 명확히 반영해야 합니다.
예를 들어 다음과 같이 적어볼 수 있습니다.
- 같은 위치를 두 번 사용할 수 없다.
- 값이 같은 것은 가능하다. 단, 인덱스는 달라야 한다.
- 구간의 양 끝은 포함한다.
- 이동할 수 없는 칸은 탐색하지 않는다.이렇게 조건을 문장으로 다시 쓰면 구현할 때 실수가 줄어듭니다. 조건문은 단순한 문법이 아니라 문제 해석의 결과입니다.
예제로 손 시뮬레이션하기
풀이 방향을 잡았다면 예제를 직접 손으로 따라가 보아야 합니다. 이것을 손 시뮬레이션이라고 부를 수 있습니다. 손 시뮬레이션은 머릿속 알고리즘이 실제로 원하는 답을 만드는지 확인하는 과정입니다.
예를 들어 큐를 사용하는 BFS 문제라면 처음 위치를 큐에 넣고, 하나를 꺼내고, 다음 위치를 넣고, 방문 표시를 하는 순서를 직접 써봅니다. 정렬 문제라면 정렬 전과 후의 배열을 써보고, 포인터가 어떻게 이동하는지 표시합니다. DP 문제라면 작은 입력에 대해 테이블 값이 어떻게 채워지는지 적어봅니다.
이 과정에서 자주 발견되는 실수가 있습니다. 방문 표시를 큐에 넣을 때 해야 하는지, 꺼낼 때 해야 하는지 헷갈릴 수 있습니다. 구간의 끝 인덱스를 포함해야 하는데 제외할 수도 있습니다. 답을 갱신하는 위치가 반복문 안인지 밖인지 잘못 잡을 수도 있습니다.
손 시뮬레이션은 귀찮아 보이지만, 디버깅 시간을 크게 줄여줍니다. 특히 시험 중에는 한 번 제출하고 틀린 뒤 원인을 찾는 시간이 더 비쌉니다. 코드를 쓰기 전에 작은 예제로 흐름을 검증하는 편이 훨씬 안전합니다.
변수의 의미를 먼저 정하라
코드를 작성하기 전에는 사용할 변수의 의미를 정해야 합니다. 변수 이름은 단순한 라벨이 아닙니다. 변수의 의미가 흐릿하면 코드 전체가 흔들립니다.
예를 들어 count라는 변수를 사용할 때도 무엇을 세는지 분명해야 합니다. 지금까지 조건을 만족한 원소 수인지, 현재 연속 구간의 길이인지, 가능한 경우의 수인지에 따라 증가하는 시점이 달라집니다. answer도 마찬가지입니다. 현재까지 찾은 최댓값인지, 최종 출력할 문자열인지, 가능한 최소 비용인지 정해야 합니다.
특히 인덱스를 다룰 때는 더 조심해야 합니다. left와 right가 가리키는 범위가 양쪽 모두 포함인지, 오른쪽은 제외인지 명확히 해야 합니다. 예를 들어 파이썬의 슬라이싱처럼 [left, right) 구조를 생각한다면 right는 포함되지 않습니다. 반면 많은 문제 풀이에서는 left와 right를 모두 포함하는 구간으로 처리하기도 합니다.
변수의 의미를 먼저 정하면 조건문과 반복문이 자연스럽게 따라옵니다. 반대로 변수의 의미가 애매하면 코드를 다 쓴 뒤에도 스스로 설명하기 어렵습니다. 설명할 수 없는 코드는 대개 틀릴 가능성이 높습니다.
풀이를 설명할 수 있어야 구현할 수 있다
코딩 테스트에서 풀이 설명은 면접에서만 필요한 것이 아닙니다. 혼자 문제를 풀 때도 자신의 풀이를 말로 설명할 수 있어야 합니다. 설명이 막히는 지점은 이해가 부족한 지점입니다.
좋은 풀이 설명은 다음 흐름을 가집니다.
1. 문제에서 요구하는 값을 정의한다.
2. 단순한 방법을 생각한다.
3. 단순한 방법이 왜 느린지 확인한다.
4. 어떤 성질을 이용해 줄일 수 있는지 설명한다.
5. 사용할 자료구조나 알고리즘을 정한다.
6. 시간 복잡도를 확인한다.예를 들어 "각 숫자가 이전에 나온 적 있는지 확인해야 하므로 집합을 사용한다"라는 설명은 좋습니다. 자료구조를 선택한 이유가 있기 때문입니다. 반면 "그냥 해시를 쓴다"는 설명은 약합니다. 왜 필요한지, 어떤 연산을 빠르게 만들기 위한 것인지 빠져 있습니다.
풀이를 설명하는 연습은 코드를 더 단단하게 만듭니다. 설명하면서 빠진 조건을 발견할 수 있고, 시간 복잡도가 맞지 않는다는 사실을 뒤늦게라도 알아차릴 수 있습니다.
막혔을 때의 생각 순서
문제를 풀다 보면 아무리 읽어도 풀이가 떠오르지 않는 순간이 옵니다. 이때 중요한 것은 당황하지 않고 정해진 순서로 다시 돌아가는 것입니다. 막혔다는 것은 재능이 없다는 뜻이 아니라, 아직 문제를 충분히 구조화하지 못했다는 뜻일 때가 많습니다.
먼저 출력이 무엇인지 다시 확인합니다. 가능 여부인지, 최솟값인지, 경우의 수인지 다시 묻습니다. 다음으로 제한 조건을 봅니다. 완전 탐색이 가능한 크기인지, 반드시 최적화가 필요한 크기인지 판단합니다. 그다음 아주 작은 입력을 직접 만들어봅니다. 입력 크기가 1, 2, 3일 때 답이 어떻게 나오는지 손으로 구합니다.
그래도 모르겠다면 브루트포스를 작성 가능한 수준으로 생각합니다. 모든 경우를 다 해본다면 무엇을 반복해야 하는지 적어봅니다. 그 후 느린 부분을 찾습니다. 같은 계산을 반복하는지, 같은 값을 여러 번 찾는지, 불필요한 경우까지 탐색하는지 확인합니다.
막혔을 때는 다음 문장을 스스로에게 던져보면 좋습니다.
입력이 아주 작다면 나는 이 문제를 어떻게 풀 것인가?
그 풀이에서 가장 시간이 많이 드는 부분은 어디인가?
그 부분을 빠르게 하기 위해 저장하거나 정렬하거나 탐색 순서를 바꿀 수 있는가?이 세 질문만으로도 많은 문제가 풀리기 시작합니다.
문제 해결 루틴 만들기
실전에서는 긴장 때문에 평소보다 생각이 흐트러집니다. 그래서 문제를 풀 때마다 같은 루틴을 반복하는 것이 좋습니다. 루틴은 머리를 대신하는 장치가 아니라, 머리가 엉뚱한 곳으로 새지 않도록 잡아주는 레일입니다.
다음은 한 문제를 만났을 때 사용할 수 있는 기본 루틴입니다.
1. 문제의 출력 목표를 한 문장으로 다시 쓴다.
2. 입력의 형태와 제한 조건을 확인한다.
3. 가능한 가장 단순한 풀이를 떠올린다.
4. 시간 복잡도가 제한 조건에 맞는지 판단한다.
5. 맞지 않으면 느린 부분을 찾아 최적화한다.
6. 예제와 직접 만든 반례로 손 시뮬레이션한다.
7. 의사코드를 쓴 뒤 구현한다.
8. 경계값을 다시 확인하고 제출한다.처음에는 이 과정이 느리게 느껴질 수 있습니다. 하지만 반복하면 오히려 시간이 줄어듭니다. 무작정 코드를 쓰다가 틀리고, 다시 읽고, 고치고, 또 틀리는 과정을 줄일 수 있기 때문입니다.
코딩 테스트에서 안정적으로 점수를 얻는 사람은 모든 문제의 정답을 처음부터 아는 사람이 아닙니다. 문제를 만나면 흔들리지 않고 해석하고, 분해하고, 검증하고, 구현하는 사람입니다.
작은 문제를 정확히 푸는 힘
어려운 알고리즘을 많이 아는 것도 중요합니다. 하지만 그보다 먼저 필요한 것은 작은 문제를 정확히 해석하고 끝까지 맞히는 힘입니다. 입력을 잘못 읽지 않는 것, 출력 형식을 놓치지 않는 것, 예제에 없는 반례를 생각하는 것, 변수의 의미를 분명히 하는 것. 이런 기본기가 쌓이면 어려운 알고리즘도 훨씬 잘 이해됩니다.
문제 해결력은 갑자기 생기지 않습니다. 문제를 읽을 때마다 "무엇을 입력받는가?", "무엇을 출력해야 하는가?", "제한 조건상 어떤 풀이가 가능한가?", "내 풀이가 틀리는 작은 반례는 없는가?"를 반복해서 묻는 동안 만들어집니다.
다음 장에서는 이 질문들 중에서도 특히 중요한 시간 복잡도와 공간 복잡도를 다룹니다. 제한 조건을 보고 어떤 풀이가 가능한지 판단하는 감각은 코딩 테스트 전체를 관통하는 핵심 능력입니다. 문제를 구조화하는 눈을 갖추었다면, 이제 그 풀이가 실제 시간 안에 실행될 수 있는지 판단하는 감각을 키울 차례입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.