코딩테스트 합격자들이 쓰는 오답노트 활용법: 반복되는 실수에서 벗어나기

입사 코딩테스트는 많은 개발자들이 거쳐야 할 관문입니다. 저도 지난 몇 년간 여러 회사의 코딩테스트를 응시하면서 느낀 점이 있는데, 단순히 문제를 많이 푸는 것보다 어떻게 실수를 기록하고 분석하는가가 최종 합격을 좌우한다는 것입니다. 특히 우리처럼 이미 실무 경험이 있는 개발자들에게는 더욱 그렇습니다.
 
과거의 나는 코딩테스트를 준비할 때, 프로그래머스나 리트코드에서 어려운 문제들을 닥치는 대로 풀었습니다. 맞으면 넘어가고, 틀리면 답을 봤다가 다시 풀고... 이런 식의 반복이었습니다. 하지만 몇 달이 지나도 합격 소식은 오지 않았고, 여전히 같은 유형의 문제에서 같은 실수를 반복하고 있다는 것을 깨달았습니다.
 
변화는 오답노트를 체계적으로 작성하기 시작했을 때 생겼습니다. 이 글에서는 제가 실제로 경험하면서 효과를 본 오답노트 활용법을 구체적으로 공유해드리겠습니다. 단순한 정오표가 아니라, 진정한 학습 도구로서의 오답노트 활용 전략입니다.

왜 오답노트가 필요한가?

코딩테스트 준비를 하다 보면 문제 풀이에만 집중하기 쉽습니다. 문제를 풀고, 답을 확인하고, 다음 문제로 넘어가는 식의 반복 말입니다. 이것을 "량의 전략"이라고 부르겠습니다. 하지만 이런 방식으로는 같은 유형의 문제에서 계속 실수를 반복하게 됩니다.
 
저는 최근 한 달간의 풀이 기록을 분석해봤습니다. 놀랍게도 제가 틀린 33개 문제 중에서 8개 문제는 이전에 이미 같은 방식으로 틀렸던 문제였습니다. 즉, 한 번 설명을 들었는데도 다시 틀린 것입니다. 이것이 바로 체계적인 오답 관리 없이는 개선할 수 없는 악순환입니다.
 
제 경험상 대부분의 합격자들은 어떤 형태로든 자신의 실수를 기록하고 있었습니다. 손으로 작성한 수첩일 수도, 노션이나 깃허브 같은 디지털 도구일 수도 있지만, 체계적으로 실수를 관리하는 프로세스를 가지고 있다는 점이 공통적이었습니다.
 
면접에서도 이 부분이 드러나곤 합니다. 합격자들은 자신의 약점을 명확히 알고 있고, 그것을 극복하기 위해 구체적으로 어떤 노력을 했는지 설명할 수 있었습니다. 반면 불합격자들은 "많이 풀어봤어요", "어려운 문제들 해봤어요" 정도의 추상적인 답변만 할 수 있었습니다.
 
오답노트의 진정한 가치는 "이전에 한 실수를 다시 하지 않기 위한 시스템"입니다. 같은 실수를 반복한다는 것은 그 실수가 충분히 분석되지 않았다는 의미이거든요. 오답노트는 이 악순환에서 벗어나는 방법입니다.

실제로 도움이 된 오답노트 작성 항목들

단순 정오표가 아닌 근본 원인 분석

많은 사람들이 오답노트를 단순하게 생각합니다. "이 문제가 틀렸다, 정답은 이것이다" 정도만 기록하는 식입니다. 하지만 이 방식은 큰 효과가 없습니다. 왜냐하면 실수의 원인을 파악하지 못하기 때문입니다.
 
저는 오답노트에 다음 항목들을 꼭 포함하려고 했습니다.
 
문제 분류 및 핵심 개념: 먼저 이 문제가 어떤 알고리즘이나 자료구조 개념을 다루고 있는지 명확히 합니다. 예를 들어 "동적계획법 - 배낭 문제 변형", "그래프 - BFS를 이용한 최단 거리", "문자열 - KMP 알고리즘" 같은 식입니다. 단순히 "동적계획법"이라고만 하기보다는, 더 구체적인 분류가 필요합니다. 나중에 복습할 때 같은 종류의 문제를 효율적으로 찾을 수 있기 때문입니다.
 
내 풀이 과정 및 사고: 제가 어떻게 접근했는지, 어떤 생각으로 그 코드를 작성했는지 기록합니다. 이것이 정말 중요합니다. 왜냐하면 틀린 풀이라도 제 사고 과정이 어디서 꺾였는지 알아야 하기 때문입니다. 예를 들어, "처음에는 그리디 접근으로 시도했으나 반례가 있었다" 또는 "재귀로 구현했으나 시간복잡도를 계산하지 않았다" 같은 식으로 기록합니다.
 
실수 유형 및 근본 원인: 가장 중요한 부분입니다. 실수가 발생한 이유를 분류하는 것입니다. 저는 다음과 같이 카테고리를 나눴습니다:

• 문제 이해 오류: 문제를 잘못 읽거나 요구사항을 놓친 경우. 예를 들어 "0부터 시작"인 줄 알았는데 "1부터 시작"이었던 경우
• 엣지 케이스 미고려: 일반적인 경우는 맞게 풀었지만, 특수한 경우를 생각하지 못한 경우. 예: 배열 크기가 1인 경우, 음수가 포함된 경우, 중복된 값이 있는 경우
• 알고리즘 선택 오류: 잘못된 알고리즘을 선택하거나, 알고리즘의 개념을 잘못 이해한 경우
• 시간/공간복잡도 초과: 논리는 맞지만 알고리즘 최적화를 하지 못한 경우
• 구현 오류: 알고리즘은 맞는데 코딩할 때 실수한 경우. 예: 배열 인덱스 범위 오류, 변수명 오류
• 논리 오류: 조건문이나 반복문에서 논리적 실수를 한 경우
• 자료구조 선택 오류: 다른 자료구조를 사용했으면 쉬웠을 경우

이렇게 분류하다 보면 자신의 패턴이 명확하게 보입니다. 어떤 사람은 항상 엣지 케이스를 놓치는 경향이 있을 수 있고, 다른 사람은 문제를 너무 빨리 이해한 줄 착각하는 경향이 있을 수 있습니다. 또 어떤 사람은 특정 알고리즘(예: 동적계획법이나 그래프)에서만 자꾸 실수할 수도 있습니다.
 
정답 풀이 및 통찰: 정답 코드를 그냥 복사하기보다는, 내 말로 정리합니다. "왜 이런 접근이 필요한가?", "여기서 핵심은 무엇인가?", "내 풀이와 정답 풀이의 차이점은 무엇인가?" 이런 질문들에 답하는 식으로 정리하는 것입니다. 이 과정에서 진정한 학습이 일어납니다.
 
코드 스니펫 및 주의점: 정답 코드의 핵심 부분을 간단히 기록하고, 나중에 같은 실수를 하지 않기 위한 체크 리스트를 만듭니다. 예를 들어 "다음번에 이 문제 유형을 만나면 반드시 엣지 케이스 먼저 확인하기" 같은 식입니다.
 

실수 패턴의 카테고리 분류

시간이 지나면서 오답노트가 쌓이면, 후에 보기 좋게 분류해야 합니다. 저는 다음과 같이 다층적으로 분류했습니다.
 
알고리즘 유형별 분류: 정렬, 탐색(BFS/DFS), 동적계획법, 그래프(최단거리/위상정렬 등), 그리디, 완전탐색, 이분 탐색, 분할 정복 등으로 나눕니다. 이렇게 하면 "나는 동적계획법에서 특히 약하다"거나 "그래프 문제에서는 항상 안 된다" 같은 것을 알 수 있습니다.
 
실수 패턴별 분류: 이것이 정말 중요합니다. 제 경우, 지난 한 달간의 실수를 분석한 결과는 다음과 같았습니다.

• 엣지 케이스 미고려: 34%
• 문제 이해 오류: 22%
• 구현 오류: 19%
• 시간복잡도 초과: 16%
• 알고리즘 선택 오류: 9%

이 데이터를 바탕으로, "자주 하는 실수 TOP 5"를 따로 만들어두고 테스트 보기 전에 항상 체크하는 습관을 들였습니다. 예를 들어, 엣지 케이스 미고려가 34%를 차지한다면, 문제를 푸는 과정에서 "이 문제에서 고려해야 할 엣지 케이스가 무엇인가?"를 제일 먼저 생각해야 한다는 뜻입니다.
 
난이도별 분류: 쉬운 문제에서 실수했다면 더 신경을 써야 할 신호입니다. 반복적으로 쉬운 문제에서 실수하는 패턴이 있다면, 이것은 알고리즘의 부족이 아니라 집중력이나 꼼꼼함의 문제일 수 있습니다. 실제로 저는 Level 1-2 문제에서 자꾸 엣지 케이스를 놓치는 경향이 있었는데, 이것을 인식한 후로 쉬운 문제를 풀 때 더 신중해졌습니다.
 
회사별/플랫폼별 분류: 프로그래머스, 리트코드 등 플랫폼별로 문제 특성이 조금씩 다릅니다. 어느 플랫폼이 내게 약한지 파악하는 것도 유용했습니다. 예를 들어, 리트코드 문제는 엣지 케이스가 많고, 프로그래머스 문제는 한국 회사 특성상 좀 더 현실적인 시나리오를 다룹니다.
 

주기적인 복습 체계

오답노트는 만든 것만으로는 의미가 없습니다. 반복적으로 봐야 합니다. 저는 다음과 같은 복습 주기를 실행했습니다.
 
당일 저녁 (Day 0): 그날 푼 문제 중 틀린 것들을 바로 그 날 저녁에 정리합니다. 이 시점에서는 정답을 보고, 무엇이 잘못됐는지 분석하고, 실수 유형을 분류합니다. 그 후 한 번 더 봅니다. 아직 신선한 상태이기 때문에 이해가 빠릅니다.
 
3일 후 (Day 3): 같은 오답들을 다시 봅니다. 이 단계에서는 두 가지를 합니다. 첫 번째, 오답노트의 분석 내용을 다시 읽으면서 "맞다, 이 부분이 문제였지" 하며 회상합니다. 두 번째, 오답노트를 보고도 처음부터 다시 풀어봅니다. 이제는 정답을 보지 말고 스스로 풀어보는 것입니다. 이 단계에서 대부분의 사람들이 "아, 이제 풀릴 것 같은데?"라고 느낍니다.
 
1주일 후 (Day 7): 정말로 이해했는지 처음부터 다시 풀어봅니다. 오답노트를 보지 말고 말입니다. 이 단계에서 실패하면 아직 충분히 학습되지 않은 것입니다. 저는 이 단계에서 70% 이상 정확히 풀 수 있을 때까지 반복했습니다.
 
2주일 후 (Day 14): 같은 유형의 다른 문제를 찾아서 풀어봅니다. 이것이 진정한 학습의 증거입니다. 예를 들어, "백트래킹을 이용한 순열 문제"를 틀렸다면, 같은 주제의 다른 순열 또는 조합 문제를 풀어보는 것입니다. 이 단계에서 새로운 문제를 잘 풀 수 있다면, 이제 그 개념을 내 것으로 만든 것입니다.
 
한 달 후 (Day 30): 월간 복습입니다. 지난 달 틀렸던 모든 문제를 한 번 더 봅니다. 이 단계에서는 오답노트를 보지 말고, 직접 풀거나 풀이를 설명해봅니다.
 
이런 식으로 반복하다 보면, 실수의 패턴이 명확해집니다. 그리고 같은 실수를 반복하는 횟수가 점점 줄어듭니다. 더 나아가, 비슷한 새로운 문제를 만났을 때 "아, 이 패턴이다. 이렇게 하면 될 거야"라는 직관이 생깁니다. 이것이 바로 진정한 학습입니다.

도구 선택: 어떤 방식으로 기록할 것인가?

오답노트를 어떤 도구로 기록할지도 중요합니다. 저는 여러 가지를 시도해봤습니다.
 
종이 수첩의 장단점: 처음에는 종이 수첩에 손으로 적었습니다. 손으로 쓰는 것이 기억에 더 잘 남는다는 여러 연구 결과가 있습니다. 실제로 손으로 쓸 때 뇌의 더 많은 부분이 활성화된다고 알려져 있습니다. 하지만 이 방법의 큰 단점은 나중에 검색하기가 어렵다는 것입니다. "동적계획법 + 엣지 케이스 실수" 조합으로 빠르게 찾아야 할 때, 손으로 적은 노트에서는 직접 넘겨가며 찾아야 합니다.
 
노션 활용: 나중에는 노션으로 옮겼습니다. 테이블 형식으로 만들어서 날짜, 문제번호, 문제명, 알고리즘 유형, 실수유형, 난이도, 링크 등을 필터링할 수 있게 했습니다. 이 방법의 장점은 정말 강력합니다. 예를 들어, "동적계획법" 필터로 필터링한 후, 그 중에서 다시 "엣지 케이스" 실수만 보기 같은 것이 가능합니다. 또한 각 행에 상세 내용을 클릭하면 펼쳐지는 형식으로 만들 수 있어, 나중에 검색하기도 쉽습니다. 단점은 초반에 템플릿을 만드는 데 시간이 걸린다는 것입니다.
 
깃허브 마크다운: 개발자답게 깃허브 리포지토리에 마크다운으로 정리하는 방법도 좋습니다. 코드 스니펫을 깔끔하게 관리할 수 있고, 버전 관리도 되며, 나중에 블로그 포스트로도 변환할 수 있습니다. 또한 다른 개발자들과 공유하기도 좋습니다. 저는 특히 어려웠던 문제나, 좋은 풀이 방법을 리뷰할 때 깃허브 방식을 선호합니다.
 
엑셀/구글시트 활용: 간단한 통계와 분석을 하기에는 스프레드시트가 효율적입니다. 엑셀의 COUNTIF 함수를 이용하면 어떤 알고리즘 유형에서 가장 많이 실수하는지, 어떤 실수 패턴이 반복되는지 쉽게 집계할 수 있습니다. 피벗 테이블을 이용하면 다양한 각도에서 데이터를 분석할 수 있고, 그래프로 시각화할 수 있습니다. 예를 들어, "날짜별 오답 수 추이"를 꺾은선 그래프로 보면 자신의 학습이 진행되고 있는지 시각적으로 알 수 있습니다.
 
혼합 접근법 (추천): 개인적으로 가장 효과적이었던 방법은 여러 도구를 혼합하는 것입니다. 저는 노션 테이블에서 먼저 기본 정보를 기록하고, 복습할 때는 깃허브 마크다운으로 작성한 더 상세한 분석을 봅니다. 월간 분석을 할 때는 엑셀로 정리된 통계 자료를 봅니다. 이렇게 하면 각 도구의 장점을 모두 활용할 수 있습니다.
 
도구보다 중요한 것은 꾸준히 사용하는 것입니다. 아무리 좋은 시스템도 사용하지 않으면 의미가 없습니다. 제 조언은 이것입니다: 완벽한 도구를 찾느라 시간을 낭비하지 말고, 지금 당신이 가장 쉽게 접근할 수 있는 도구로 시작하세요. 나중에 필요하면 언제든지 옮길 수 있습니다.

실수 패턴 분석: 데이터로 말하기

오답노트를 계속 작성하다 보면 자신의 약점이 명확히 보입니다. 저는 매월 오답 분석 보고서를 만들었습니다. 이것이 정말 도움이 됐습니다.
 
예를 들어, 지난 3개월간 제가 수집한 데이터는 이렇습니다.
 
월별 풀이 통계

• 전체 풀이: 150개
• 틀린 문제: 32개 (약 21%)
• 첫 시도에서 맞은 문제: 118개 (79%)

실수 원인 분석

• 엣지 케이스 미고려: 11개 (34%)
• 문제 이해 부족: 7개 (22%)
• 시간복잡도 초과: 5개 (16%)
• 단순 구현 실수: 6개 (19%)
• 논리 오류: 3개 (9%)

난이도별 분석

• Level 1-2에서의 오답: 8개 (25%) ← 더 집중해야 할 부분
• Level 3에서의 오답: 14개 (44%)
• Level 4-5에서의 오답: 10개 (31%)

알고리즘 유형별 분석

• 동적계획법: 7개 실수
• 그래프: 6개 실수
• 완전탐색: 5개 실수
• 정렬: 3개 실수
• 이분탐색: 2개 실수

이런 분석을 하면 어디에 집중해야 할지가 명확합니다. 제 경우에는 "엣지 케이스 미고려"가 가장 큰 약점이었고, 특히 쉬운 문제(Level 1-2)에서 이 패턴이 도드라졌습니다. 따라서 저는 의식적인 노력을 기울였습니다. 문제를 풀기 전에 항상 체크리스트를 만들었습니다.

1. "이 문제에서 고려해야 할 엣지 케이스가 무엇인가?"
2. "입력값의 최대/최소 경계는?"
3. "특수한 경우(0, 1, 음수, 중복)는 어떻게 처리할 것인가?"

이렇게 의식적인 노력을 기울인 후 두 달이 지났을 때, 엣지 케이스 미고려로 인한 오답이 34%에서 18%로 줄어들었습니다. 이것이 바로 데이터 기반 학습의 효과입니다.

시험 직전 오답노트 활용법

실제 시험을 보기 며칠 전부터는 오답노트 활용법이 달라집니다. 이 시점에서는 새로운 문제를 푸는 것보다, 자신의 약점을 파고드는 것이 훨씬 중요합니다.
 
저는 시험 일주일 전부터는 새로운 문제보다 자신의 상위 5개 실수 유형에 해당하는 문제들만 다시 풀었습니다. 기본적인 개념은 충분히 학습했기 때문에, 이제는 같은 실수를 반복하지 않는 것에 집중해야 합니다.
 
예를 들어

• 엣지 케이스 미고려 (34%) → 쉬운 문제들을 다시 풀기, 이번엔 엣지 케이스에만 집중
• 문제 이해 오류 (22%) → 문제를 읽는 속도를 늦추고, 요구사항을 정확히 파악하기
• 시간복잡도 초과 (16%) → 각 풀이의 시간복잡도를 계산해보기

또한 시험 당일 아침에도 오답노트를 봤습니다. 특히 "자주 하는 실수" 섹션을 다시 한 번 읽고 들어갔습니다. 이것이 심리적 안정감을 주기도 했고, 실제로 시험에서 비슷한 실수를 하려고 할 때 "아, 이 패턴이다. 여기 주의해야겠다"라고 인식하고 멈출 수 있게 해줬습니다.
 
예를 들어, 시험 중 배열 범위를 확인하다가 "어라, 1부터 시작하네?" 라고 인식할 수 있었습니다. 이전에 오답노트에 기록한 "오프셋 실수"와 완전히 동일한 패턴이었기 때문입니다. 오답노트가 없었다면 아마 그냥 넘어갔을 것입니다.

오답노트 작성 시 주의사항

오답노트를 작성할 때 피해야 할 함정들도 있습니다. 제 경험에서 배운 것들입니다.

• 너무 많이 기록하려는 욕심: 모든 세부사항을 적으려고 하면 시간만 낭비합니다. 예를 들어, 정답 코드를 모두 복사하고, 설명을 길게 적고, 관련 개념들을 죄다 정리하려고 하면, 오답노트 작성에만 하루가 갈 수 있습니다. 이것은 본말이 전도된 것입니다. 저는 이제 핵심만 간결하게 정리합니다. 핵심은 무엇인가? 내가 무엇을 놓쳤는가? 다음에는 어떻게 할 것인가? 이 세 가지만 적습니다.
• 설명을 이해한 후 그냥 넘어가기: 이것은 정말 흔한 실수입니다. "아, 이렇게 하는 거네"라고 이해한 후 다음 문제로 넘어가는 것입니다. 하지만 설명을 읽고 이해한 것과 직접 풀 수 있는 것은 다릅니다. 반드시 처음부터 다시 풀어봐야 합니다. 오답노트에 "1주일 후 재풀이" 같은 항목을 추가해서 반드시 이 단계를 거치도록 강제했습니다.
• 오답노트 정리에만 시간을 쓰기: 오답노트는 학습 도구일 뿐, 목적이 아닙니다. 너무 깔끔하게 정리하려다 보면 복습 시간이 부족해집니다. 저는 처음에 노션을 너무 예쁘게 꾸미려고 했는데, 결과적으로는 수정하고 정렬하는 데 시간을 다 썼습니다. 지금은 그냥 기능성에만 집중합니다. 가독성 있으면 충분합니다.
• 복습 없이 쌓기만 하기: 앞에서 말했지만, 오답노트는 반복 복습이 생명입니다. 정기적으로 봐야 합니다. 많은 사람들이 오답노트를 열심히 만들지만, 다시 보지 않습니다. 이것은 마치 일기장을 쓰는 것과 같습니다. 도움이 안 됩니다. 복습 일정을 캘린더에 입력하거나, 리마인더를 설정해서라도 반드시 정기적으로 봐야 합니다.
• 다른 사람의 오답노트와 비교하기: 각자의 약점은 다릅니다. 남의 오답노트는 참고만 하고, 자신만의 패턴을 찾는 것이 중요합니다. 저는 처음에 깃허브에 올려진 다른 사람의 오답노트를 보며 불안해했습니다. "저 사람은 이렇게 체계적으로 정리했는데, 나는?" 이런 식으로요. 하지만 결국 중요한 것은 다른 사람의 방법이 아니라, 내 약점을 체계적으로 파악하고 개선하는 것입니다.

내 경험상 가장 큰 변화

오답노트를 체계적으로 작성하고 복습하기 시작한 후 가장 큰 변화는 무엇일까요? 정답 정렬도 빨라졌지만, 가장 큰 변화는 자신감이었습니다.
 
같은 유형의 실수를 두 번, 세 번 반복하면서 고쳐내다 보면, 그 부분에 대해 확신을 갖게 됩니다. "아, 나는 배열 인덱스 오류를 이전에 3번 했는데, 이제는 이렇게 체크하니까 안 한다"는 경험이 쌓이면, 실제 시험에서도 당황하지 않고 침착하게 대응할 수 있습니다.
 
또한 오답노트를 만들면서 자신을 객관적으로 볼 수 있게 됐습니다. "나는 어디서 자주 실수하는가", "내 강점은 무엇인가", "어느 알고리즘은 잘하고 어느 것은 약한가"라는 질문에 데이터 기반 답변을 할 수 있게 된 것입니다. 이것은 단순한 자기계발을 넘어, 과학적인 학습 전략입니다.
 
심리학적으로도 의미가 있습니다. 오답노트를 작성하면서 이전 실수를 다시 마주하는 것은 불편합니다. 하지만 이것을 반복하면, 같은 실수를 반복하는 두려움이 사라집니다. 왜냐하면 "이미 여러 번 했고, 매번 극복했으니까 이번에도 될 거야"라는 확신이 생기기 때문입니다. 이것이 최고의 싼리 상태입니다.

실제로 효과가 있었나?

네, 효과가 있었습니다. 저는 지난 3개월간 여러 회사의 코딩테스트를 응시했는데, 오답노트를 시작한 후부터는 합격률이 눈에 띄게 올라갔습니다. 구체적으로는 1차 필기전형 통과율이 크게 개선됐습니다.
 
전과 후를 비교하면
오답노트 도입 전 (3개월)

• 응시: 12회
• 1차 통과: 2회 (17%)
• 2차 진출: 0회

오답노트 도입 후 (3개월)

• 응시: 15회
• 1차 통과: 7회 (47%)
• 2차 진출: 2회

숫자로 봐도 명확한 개선입니다. 하지만 더 중요한 것은 합격 여부보다, 코딩테스트 준비 과정 자체가 변했다는 점입니다. 처음에는 무작정 많은 문제를 푸는 것에만 집중했다면, 지금은 깊이 있는 학습을 하고 있습니다. 같은 문제를 여러 번 보고, 내 실수를 분석하고, 같은 실수를 반복하지 않기 위해 의식적으로 노력하는 것입니다.
 
또한 면접에서도 이것이 드러났습니다. 면접관이 "어려웠던 경험을 말해보세요"라고 물었을 때, 저는 구체적으로 답할 수 있었습니다. "처음에는 엣지 케이스를 자주 놓쳤는데, 이를 의식적으로 개선했습니다. 이제는 문제를 풀기 전에 항상 엣지 케이스를 먼저 확인합니다"라고 말이죠. 이런 답변은 면접관에게 긍정적인 인상을 줍니다. 왜냐하면 자신의 약점을 인식하고, 체계적으로 개선하려고 노력했다는 것을 보여주기 때문입니다.

지금 시작하는 분들을 위해

만약 지금 코딩테스트를 준비하고 있다면, 제 조언은 이것입니다.
 
오답노트는 선택이 아닙니다. 필수입니다.
 
하지만 그것이 거창하거나 어렵지는 않습니다. 지금 당신이 사용하는 노션, 깃허브, 심지어 간단한 메모장으로도 시작할 수 있습니다. 중요한 것은 형식이 아니라, 실수를 기록하고, 분석하고, 반복하는 프로세스입니다.
 
특히 저처럼 경력이 있는 개발자들에게는 더욱 효과적입니다. 이미 기본기가 있기 때문에, 지금 필요한 것은 "어떻게 더 실수를 줄일 것인가"에 대한 전략입니다. 오답노트는 정확히 그 질문에 답하는 도구입니다.
 
마지막 조언입니다. 완벽한 오답노트를 만들려고 기다리지 마세요. 지금 바로 시작하세요. 오늘 틀린 문제부터 오답노트를 만들기 시작하세요. 첫 번째 오답노트는 형편없을 겁니다. 하지만 그것으로 충분합니다. 시간이 지나면서 자신의 방식이 자연스럽게 정형될 것입니다.
 
당신의 약점을 숨기지 말고, 직면하고, 기록하고, 반복하세요. 그것이 합격으로 가는 가장 확실한 길입니다.

코딩테스트 준비, 힘내세요. 당신의 노력은 반드시 결과로 돌아올 것입니다. 그 결과는 합격이 될 수도, 성장이 될 수도 있습니다. 어느 쪽이든 당신은 이전보다 나은 개발자가 되어 있을 것입니다.

[코딩테스트 합격 비법] 실전처럼 연습하는 모의고사 시뮬레이션 루틴과 멘탈 관리 완벽 가이드