문제 풀이 글을 랜덤으로 보면 왜 이 풀이에서 Map을 쓰고, 다른 풀이에서는 스택이나 포인터를 쓰는지 감이 잘 잡히지 않습니다.
JS 코딩테스트는 배열 조작부터 익숙해져야 합니다
JavaScript로 코딩테스트를 준비할 때 첫 단계는 거창한 알고리즘보다 배열을 다루는 손 감각입니다. 입력을 배열로 바꾸고, 반복문으로 값을 훑고, 조건에 맞게 필터링하거나 누적하는 일이 거의 모든 풀이의 바닥에 깔립니다. map, filter, reduce를 외우는 것보다 for문과 인덱스로 값을 추적하는 연습이 먼저입니다. 배열 메서드 기준은 JavaScript 배열 메서드를 같이 보면 풀이 코드가 덜 낯설어집니다.
해시는 값을 세거나 빠르게 찾을 때 등장합니다
배열만으로 모든 문제를 풀 수는 있지만, 값의 등장 횟수나 존재 여부를 자주 확인해야 하면 Map을 쓰는 편이 훨씬 단순해집니다. 학급 회장처럼 후보별 득표수를 세거나, 아나그램처럼 문자 개수를 비교하는 문제가 대표적입니다. 이 유형은 값을 하나씩 보면서 저장소를 갱신하는 감각이 중요합니다. 해시 풀이를 익히려면 모든 아나그램 JS 풀이처럼 카운팅과 윈도우가 같이 나오는 문제로 확장하면 좋습니다.
const stack = [];
for (const char of input) {
if (char === '(') stack.push(char);
if (char === ')') {
if (stack.length === 0) return false;
stack.pop();
}
}
return stack.length === 0;스택은 순서가 되돌아가는 문제에서 의심합니다
스택은 마지막에 들어온 값이 먼저 나가는 구조입니다. 괄호가 제대로 닫히는지 확인하거나, 최근에 쌓인 값을 기준으로 비교해야 하는 문제에서 자주 등장합니다. 처음에는 push와 pop만 정확히 이해해도 충분합니다. 값을 넣고, 조건이 맞을 때 마지막 값을 꺼내고, 남은 값으로 결과를 판단합니다. 스택 개념이 약하다면 별도 글인 자료구조 스택 글을 먼저 보고, 올바른 괄호 JS 풀이 같은 문제로 넘어가면 연결이 자연스럽습니다.
투 포인터는 범위를 줄이는 사고방식입니다
정렬된 배열 두 개를 합치거나, 양쪽 끝에서 값을 좁혀가며 조건을 맞추는 문제는 투 포인터로 볼 수 있습니다. 핵심은 모든 조합을 다 보는 대신 왼쪽과 오른쪽 위치를 움직이며 후보를 줄이는 것입니다. 처음에는 포인터가 언제 증가하고 언제 감소하는지 조건을 문장으로 써보는 것이 좋습니다. 두 배열 합치기 JS 풀이처럼 포인터 이동이 눈에 보이는 문제부터 시작하면 덜 막힙니다.
슬라이딩 윈도우는 구간을 다시 계산하지 않는 방식입니다
연속된 구간의 합이나 개수를 다룰 때 매번 처음부터 다시 계산하면 시간이 금방 늘어납니다. 슬라이딩 윈도우는 오른쪽 값을 더하고 왼쪽 값을 빼면서 구간을 이동합니다. 배열, 해시, 투 포인터가 어느 정도 익숙해진 뒤에 보는 것이 좋습니다. 추천 순서는 배열, 해시, 스택, 투 포인터, 슬라이딩 윈도우입니다. 이 순서를 따르면 풀이가 외운 공식이 아니라 문제의 모양에 맞춰 선택하는 도구로 보입니다.
문제 유형은 쉬운 입력 추적부터 쌓아가는 것이 좋습니다
코딩테스트를 준비할 때 처음부터 어려운 알고리즘 이름을 외우면 풀이가 오래 남지 않습니다. 먼저 입력을 어떻게 배열로 바꾸고, 반복문에서 어떤 값을 추적할지 적어보는 연습이 필요합니다. 대부분의 문제는 현재 값, 이전에 본 값, 지금까지 누적한 값을 어떻게 관리하는지에서 출발합니다.
스택이나 해시도 결국 값을 보관하는 방식의 차이입니다. 해시는 특정 값을 빠르게 찾거나 개수를 셀 때 쓰고, 스택은 최근에 들어온 값을 먼저 확인해야 할 때 씁니다. 투 포인터와 슬라이딩 윈도우는 모든 경우를 다시 보지 않기 위해 범위를 움직이는 방식입니다. 이름보다 “무엇을 줄이려고 쓰는가”를 먼저 보면 유형이 더 잘 구분됩니다.
풀이를 공부할 때는 정답 코드를 바로 외우기보다, 왜 배열만으로는 불편했는지, 어떤 값을 저장했는지, 반복문 한 번이 끝날 때 상태가 어떻게 바뀌었는지를 확인해야 합니다. 이 습관이 생기면 비슷한 문제를 만났을 때 도구를 더 빨리 고를 수 있습니다.
문제 유형은 쉬운 입력 추적부터 쌓아가는 것이 좋습니다
코딩테스트를 준비할 때 처음부터 어려운 알고리즘 이름을 외우면 풀이가 오래 남지 않습니다. 먼저 입력을 어떻게 배열로 바꾸고, 반복문에서 어떤 값을 추적할지 적어보는 연습이 필요합니다. 대부분의 문제는 현재 값, 이전에 본 값, 지금까지 누적한 값을 어떻게 관리하는지에서 출발합니다.
스택이나 해시도 결국 값을 보관하는 방식의 차이입니다. 해시는 특정 값을 빠르게 찾거나 개수를 셀 때 쓰고, 스택은 최근에 들어온 값을 먼저 확인해야 할 때 씁니다. 투 포인터와 슬라이딩 윈도우는 모든 경우를 다시 보지 않기 위해 범위를 움직이는 방식입니다. 이름보다 “무엇을 줄이려고 쓰는가”를 먼저 보면 유형이 더 잘 구분됩니다.
풀이를 공부할 때는 정답 코드를 바로 외우기보다, 왜 배열만으로는 불편했는지, 어떤 값을 저장했는지, 반복문 한 번이 끝날 때 상태가 어떻게 바뀌었는지를 확인해야 합니다. 이 습관이 생기면 비슷한 문제를 만났을 때 도구를 더 빨리 고를 수 있습니다.
마지막에는 독자가 바로 적용할 기준을 남깁니다
코딩테스트 JS 자료구조 로드맵: 배열, 해시, 스택, 투 포인터 순서을 읽는 독자는 단순한 정의보다 “그래서 지금 내 코드에서는 무엇을 먼저 확인해야 하는가”를 알고 싶어 합니다. 그래서 글을 작성할 때는 개념을 설명한 뒤 바로 판단 질문으로 이어지는 흐름이 필요합니다. 이 값은 어디에서 만들어졌는지, 어느 컴포넌트나 페이지가 책임지는지, 배포나 빌드 뒤에도 같은 방식으로 동작하는지처럼 실제 작업에서 바로 확인할 수 있는 질문을 남겨야 합니다.
또 하나 중요한 기준은 기존 글과의 거리입니다. 이미 자세히 다룬 문법이나 오류 해결 절차를 다시 길게 반복하면 새 글의 역할이 흐려집니다. 이 글은 독자가 흩어진 글을 어떤 순서로 읽을지 알려주는 입구이거나, 서로 다른 개념을 연결하는 브릿지여야 합니다. 세부 구현은 관련 글로 넘기고, 현재 글에서는 왜 그 글을 그 시점에 읽어야 하는지 설명하는 것이 더 좋습니다.
실제 작성 과정에서는 예시를 하나 정해 끝까지 밀고 가는 편이 자연스럽습니다. 카드 UI, 블로그 상세 페이지, 장바구니 상태, 코딩테스트 입력 배열처럼 작은 상황 하나를 잡고 설명하면 개념이 공중에 뜨지 않습니다. 독자가 자신의 코드에 대입할 수 있는 기준이 생기면, 글은 단순 요약이 아니라 다음 작업을 결정하는 안내문 역할을 하게 됩니다.
마지막 정리는 “무엇을 외울 것인가”보다 “무엇부터 확인할 것인가”로 끝내는 것이 좋습니다. 처음 볼 파일, 먼저 나눌 상태, 우선 점검할 설정, 다음에 읽을 기존 글을 짧게 안내하면 독자가 바로 움직일 수 있습니다. 이런 마무리가 있어야 허브 글과 브릿지 글이 기존 글을 반복하지 않고도 충분한 가치를 가집니다.
읽는 순서를 정하면 글도 덜 흩어집니다
코딩테스트 JS 자료구조 로드맵: 배열, 해시, 스택, 투 포인터 순서의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.