코딩 테스트에서 계속 떨어지다가
합격한 방법
7번 탈락, 2개월 공부, 그리고 드디어 통과한 날의 기록
7번 연속으로 떨어졌다
이직을 준비하면서 코딩 테스트를 처음 봤다. 첫 번째 회사에서 떨어졌다. 두 번째도. 세 번째도. 처음엔 "이 회사가 나랑 안 맞나 보다"라고 생각했다. 일곱 번째 떨어지고 나서야 "내가 준비가 안 된 거구나"를 인정했다.
평소에 코드를 잘 짠다고 생각했다. 실무에서 Next.js로 기능을 만들고, 성능 최적화도 하고, 코드 리뷰도 받으면서 일했다. 근데 코딩 테스트는 달랐다. 실무 코딩과 코딩 테스트는 완전히 다른 것이었다. 그걸 일곱 번 떨어지고 나서야 알았다.
# 7번의 탈락 기록 (이직 준비 1개월 차)
[FAIL] A사 → 3문제 중 1문제만 통과. 시간 초과
[FAIL] B사 → 2문제 중 부분 점수. 로직 틀림
[FAIL] C사 → 4문제 중 1문제. 나머지 손도 못 씀
[FAIL] D사 → 2문제 중 0. 그래프 문제 처음 봄
[FAIL] E사 → 3문제 중 1.5. DP 접근 방향 틀림
[FAIL] F사 → 3문제 중 2. 마지막 문제 시간 부족
[FAIL] G사 → 5문제 중 2. 중간 난이도도 못 품
─────────────────────────────────────────
공통 원인: 패턴 인식 못 함 / 시간 복잡도 계산 안 됨 / 구현 속도 느림
왜 떨어졌는지 — 분석부터 했다
처음엔 "문제를 더 많이 풀면 되겠지"라고 생각했다. LeetCode를 켜고 문제를 닥치는 대로 풀었다. 한 달 뒤에 또 떨어졌다. 문제를 많이 풀었는데 왜 안 되는지 몰랐다.
그때 유형별로 내가 틀린 원인을 분류해봤다. 거의 모든 실패가 두 가지 중 하나였다. 첫째, 이 문제가 어떤 유형인지 못 알아본다. 둘째, 유형은 알겠는데 구현이 느려서 시간이 모자란다. 문제를 많이 푸는 게 아니라 패턴을 익히는 것과 구현 속도를 올리는 것이 필요했다.
C사 테스트 결과지를 다시 펼쳤다. 4문제 중 1문제. 나머지 3문제를 왜 못 풀었는지 복기했다. 두 번째 문제는 BFS인데 DFS로 접근했다. 세 번째는 DP인데 완전탐색으로 시작해서 시간 초과. 네 번째는 그냥 손을 못 댔다.
"문제를 보고 어떤 알고리즘을 써야 하는지 모른다." 이게 핵심이었다. 알고리즘 자체는 어렴풋이 알고 있는데, 어떤 상황에서 무엇을 쓰는지를 몰랐다. 이걸 깨닫고 공부 방향을 완전히 바꿨다.
유형 인식부터 — 이걸 먼저 익혀야 했다
코딩 테스트 문제에는 패턴이 있다. 문제를 읽고 "이건 어떤 알고리즘이야"를 30초 안에 분류하는 연습이 먼저였다. 내용이 아니라 구조를 보는 눈을 키우는 것이었다.
최단 경로, 레벨 순회, 연결 요소 탐색. "최소"라는 단어 나오면 BFS 우선 고려.
겹치는 부분 문제가 있을 때. "최대/최소 경우의 수" 물어보면 DP 고려.
연속 구간, 부분 배열. 완전탐색 O(n²) → O(n)으로 줄이는 핵심.
정렬된 배열에서 탐색. O(log n). "범위 내에서 최대/최소" 패턴.
Stack: 괄호, 모노스택. Queue: BFS. Heap: K번째 최대/최소.
문제를 읽고 바로 코딩하지 않는다. 먼저 메모장에 "이 문제는 [유형]이다. 이유는 [단서]이다"를 적는다. 처음엔 틀린다. 틀릴 때마다 "왜 이 단서가 [유형]을 의미하는지"를 정리한다. 이 연습을 30문제만 해도 패턴 인식이 달라진다.
2개월 공부 계획 — 실제로 쓴 것
7번 떨어지고 나서 2개월을 집중했다. 방향이 생기니까 계획이 구체적이 됐다.
BFS/DFS, DP, 투 포인터, 이진 탐색 각 유형 5문제씩. 코딩 안 하고 "이 문제가 왜 이 유형인지"만 분석. 뼈대 코드 외우기.
각 유형 30문제씩. 시간 제한 없이 풀되, 30분 넘으면 답 보고 분석. "왜 이 접근이 맞고 내 접근이 틀렸는지"를 반드시 적음.
문제당 30분 제한. 못 풀면 그냥 다음으로. 실제 테스트처럼. 시간 배분 감각 익히기. 1시간 기준 2문제 확실 + 3번째 도전.
프로그래머스 모의고사 주 2회. 풀고 나서 틀린 문제 분석. 가장 약한 유형 집중 보완. 코드 작성 속도 의식적으로 높이기.
가장 효과 있었던 공부법 — 구체적으로
문제를 풀고 나서 맞든 틀리든 분석 노트를 썼다. 형식은 간단했다. 유형, 내 접근법, 정답 접근법, 다른 점, 핵심 인사이트. 특히 틀린 문제는 "내가 왜 이 방향으로 생각했는지"를 적었다. 그게 다음에 비슷한 패턴에서 같은 실수를 안 하게 했다.
한 달 뒤에 이 노트를 다시 읽었다. 내가 반복해서 틀리는 유형이 보였다. 그래프 문제에서 방문 처리를 빠뜨리는 게 세 번이나 나왔다. 의식하지 않으면 계속 같은 실수를 한다. 기록이 그걸 막았다.
### 내 접근 DFS로 모든 경로 탐색 후 최솟값 반환 → 시간복잡도: O(4^n) → 시간 초과
### 정답 접근 BFS로 레벨 단위 탐색 → 시간복잡도: O(n*m) → 통과
### 핵심 인사이트 "최단 거리/최소 횟수"가 나오면 BFS 먼저 생각하기 DFS는 경로 자체가 필요할 때 (존재 여부, 백트래킹)
### 다음번 체크포인트 □ BFS 쓸 때 visited 배열 선언 먼저 □ 큐에 초기값 넣기 전 방문 표시 □ 레벨 구분이 필요하면 dist 배열 따로
# 이 노트를 1개월 후에 읽으면 실수 패턴이 보임
처음에 문제 하나에 2~3시간을 쓰곤 했다. 효율이 나빴다. 실제 테스트에서 한 문제에 2시간을 쓸 수 없다. 30분 룰을 도입했다. 30분 안에 못 풀면 답을 본다. 대신 답을 보고 나서 "왜 이 접근이 맞는지"를 반드시 이해한 뒤 직접 다시 짠다.
이 방법이 "스스로 생각하는 능력"을 포기하는 것 같아서 처음엔 죄책감이 들었다. 아니었다. 답을 보고 이해하고 다시 짜는 것이, 모르는 채로 3시간 씨름하는 것보다 훨씬 많이 배웠다. 좋은 풀이를 많이 보는 것이 결국 패턴 인식을 늘린다.
코딩 테스트 중에 BFS를 짜야 할 때마다 "큐를 어떻게 선언하지, 방문 배열 크기는 어떻게 하지"를 생각하는 시간이 있었다. 이 시간이 축적되면 30분이 순식간에 간다. 뼈대 코드를 외워서 이 고민을 없앴다.
각 유형의 뼈대 코드를 손으로 10번씩 썼다. 손이 기억하게 했다. BFS, DFS, DP 테이블 초기화, 이진 탐색 while 조건 — 이것들을 생각 없이 치는 수준이 되니까 실제 로직에만 집중할 수 있었다.
while (queue.length) { const node = queue.shift(); // 처리 로직 for (const next of graph[node]) { if (!visited.has(next)) { visited.add(next); queue.push(next); } } } };
// 이진 탐색 뼈대 — 외워서 쓰는 것 let left = 0, right = max; while (left <= right) { const mid = Math.floor((left + right) / 2); if (check(mid)) { left = mid + 1; // 또는 right = mid - 1; (조건에 따라) } else { right = mid - 1; } }
// 이 뼈대들을 생각 없이 칠 수 있을 때까지 반복
합격한 날 — 드디어
테스트가 시작되고 첫 문제를 읽었다. "아, 이건 BFS네." 30초 안에 유형이 보였다. 뼈대 코드를 치기 시작했다. 손이 기억하고 있었다. 로직에만 집중할 수 있었다. 15분 만에 풀었다.
두 번째는 DP였다. 점화식이 바로 보이지 않았다. 5분 동안 예시를 써가면서 패턴을 찾았다. 보였다. 짰다. 통과했다. 세 번째는 시간이 부족해서 부분 점수만 받았다. 결과는 3/4 통과. 합격이었다.
그날 결과 문자를 받고 혼자 "됐다"를 소리 내서 말했다. 7번 떨어지고 2개월 갈아넣은 뒤에 첫 통과였다. 기억에 오래 남을 것 같다.
# 2개월 집중 학습 후 (4회 응시)
[PASS] H사 → 4문제 중 3 통과. 합격 ✓
[PASS] I사 → 3문제 중 3 통과. 만점 ✓
[PASS] J사 → 5문제 중 4 통과. 합격 ✓
[NEAR] K사 → 4문제 중 2.5. 아쉬운 탈락
─────────────────────────────────────────
달라진 것: 유형 인식 속도 / 뼈대 코드 자동화 / 시간 배분
# 7번 연속 탈락 → 4번 중 3번 합격
코딩 테스트는 코딩 능력 테스트가 아니라 패턴 인식 테스트다. 실무를 잘 한다고 통과하는 게 아니고, 알고리즘 패턴을 얼마나 빠르게 인식하고 구현하는지를 보는 것이다. 준비를 다르게 해야 하는 이유가 거기 있다.
지금 코딩 테스트 준비 중인 분들에게
7번 떨어졌을 때 "나는 개발자 자질이 없나"라는 생각이 들었다. 아니었다. 코딩 테스트 준비를 안 한 것이었다. 이 둘은 완전히 다르다. 실무에서 코드를 잘 짜는 것과 코딩 테스트를 잘 통과하는 것은 다른 스킬이다. 코딩 테스트는 준비하는 것이다.
지금 여러 번 떨어졌다면, 더 많이 풀기 전에 왜 떨어지는지를 먼저 분석하는 게 맞다. 유형 인식이 안 되는지, 구현이 느린지, 시간 배분이 안 되는지. 원인에 따라 공부법이 달라진다. 그 분석 없이 문제만 많이 풀면 같은 자리에서 맴도는 경우가 많다.
최근에 떨어진 테스트 문제들을 다시 열어본다. 각 문제가 어떤 유형이었는지, 내가 왜 못 풀었는지를 적는다. 거기서 패턴이 보인다. 그 패턴이 공부 방향을 만든다. 이 분석 없이 LeetCode를 무작정 켜는 것보다 이 한 시간이 훨씬 가치 있다.
2개월 동안 갈아넣은 게 아깝지 않다. 코딩 테스트를 통과하는 것이 목적이었지만, 그 과정에서 알고리즘 사고방식이 생겼다. 실무에서도 "이 로직이 O(n²)인데 투 포인터로 O(n)으로 줄일 수 있다"는 게 보이기 시작했다. 목적은 테스트 통과였는데 부산물로 실무 능력도 올라갔다.
7번 떨어졌던 기억이 나쁘게만 남지 않는다. 그 7번이 없었으면 진짜로 문제를 분석하지 않았을 것이다. 결국 7번의 실패가 공부 방향을 만들었다.
💬 코딩 테스트 준비하면서 효과 있었던 방법이 있으신가요?
유용했던 사이트, 특이한 공부법, 반복해서 틀린 유형 — 어떤 경험이든 댓글로 나눠주세요. 지금 코딩 테스트 준비 중인 분들에게 가장 현실적인 힌트가 될 것 같습니다.
'개발자 > 취업 커리어 입문' 카테고리의 다른 글
| 개발자 채용 플랫폼 비교 후기 (원티드, 프로그래머스, 링크드인) (0) | 2026.08.16 |
|---|---|
| 개발자 이직, 처음 마음먹게 된 순간 (0) | 2026.08.09 |
| 인턴에서 정규직 전환, 솔직하게 어떻게 했나 (1) | 2026.08.02 |
| 신입 개발자가 입사 첫 날 받은 충격 (0) | 2026.07.26 |
| 개발자 취업 준비 6개월, 실제로 공부한 것과 쓸모없었던 것 (0) | 2026.07.19 |
