코딩테스트를 준비한 취업 준비생들의 풀이 기록을 보다 보면 정답 코드는 꽤 많이 쌓여 있는데, 정작 본인이 왜 그 방식으로 풀었는지 설명하지 못하는 경우를 자주 봅니다. 어떤 준비생은 해시를 사용한 문제를 맞혔지만 면접 연습에서 왜 해시를 썼는지 묻자 빠르기 때문이라고만 답했고, 또 다른 준비생은 DP 문제를 풀어놓고도 점화식을 어떻게 떠올렸는지 설명하지 못해 자신감이 크게 떨어졌습니다. 저는 이 지점이 코딩테스트 준비가 단순 문제 풀이에서 끝나면 안 되는 이유라고 생각합니다. 개발자 면접에서는 정답 코드보다 문제를 읽고 판단하고 개선한 사고과정이 더 중요하게 보일 수 있습니다. 그래서 알고리즘 공부는 기록습관과 함께 정리되어야 면접 답변의 재료가 됩니다.
코딩테스트 준비에서 사고과정이 드러나야 하는 이유
- 공감 상황
코딩테스트를 준비하는 사람들을 보면 처음에는 대부분 문제 수를 기준으로 실력을 판단합니다. 하루에 몇 문제를 풀었는지, 백준이나 프로그래머스에서 어느 단계까지 풀었는지, 정답률이 얼마나 되는지를 중요하게 봅니다. 물론 문제를 많이 풀어보는 것은 필요합니다. 하지만 실제 풀이 기록이나 면접 연습을 보면 문제 수가 많다고 해서 면접 답변이 자연스럽게 좋아지는 것은 아닙니다. 정답 코드는 남아 있는데 처음에 어떤 조건을 보고 접근했는지, 왜 그 알고리즘을 선택했는지, 시간복잡도를 어떻게 판단했는지 설명하지 못하는 경우가 많습니다.
- 막히는 원인
이 문제가 생기는 이유는 코딩테스트를 정답 제출 중심으로만 보기 때문입니다. 시험 환경에서는 제한 시간 안에 정답을 맞히는 것이 중요합니다. 그러나 취업 준비 전체로 보면 코딩테스트는 문제를 어떻게 이해하고 해결하는지 보여주는 과정이기도 합니다. 면접관이 관심을 갖는 부분은 단순히 이 문제를 풀 수 있는가에만 있지 않습니다. 문제의 조건을 어떻게 읽었는지, 처음 접근이 왜 부족했는지, 어떤 기준으로 더 나은 풀이를 선택했는지까지 확인하려고 합니다. 평소에 이 과정을 남기지 않으면 면접에서는 정답을 맞힌 경험도 짧은 답변으로 끝날 수 있습니다.
- 실제 예시
풀이 기록을 점검하다 보면 이런 장면이 자주 보입니다. 예를 들어 두 수의 합을 찾는 문제에서 처음에는 이중 반복문으로 풀었다가 시간 초과가 나서 해시를 사용한 경우가 있습니다. 그런데 기록에는 최종 코드만 남아 있고, 왜 이중 반복문이 부족했는지, 입력 크기를 보고 어떤 판단을 했는지는 빠져 있습니다. 면접에서 이 문제를 설명하라고 하면 해시를 사용했습니다라는 말로 끝나기 쉽습니다. 반대로 입력 크기가 커서 O(n²) 방식은 어렵다고 판단했고, 이미 확인한 값을 빠르게 찾기 위해 해시를 사용했습니다라고 말하면 문제를 분석한 과정이 드러납니다.
저는 이 차이가 매우 크다고 생각합니다. 정답 코드를 제출한 사람과 문제를 구조적으로 이해한 사람은 면접에서 다르게 보입니다. 특히 신입 개발자 면접에서는 완벽한 알고리즘 전문가를 뽑는 것이 아니라, 문제를 만났을 때 어떻게 생각하는 사람인지 확인하려는 경우가 많습니다. 따라서 코딩테스트 준비는 문제를 푸는 훈련이면서 동시에 자신의 사고방식을 정리하는 훈련이어야 합니다.
- 문제를 풀 때는 처음 떠올린 접근을 반드시 남기는 것이 좋습니다. 많은 준비생이 틀린 풀이를 지우고 정답 코드만 남기려 하지만, 실제로는 그 틀린 접근이 면접 답변의 중요한 재료가 될 수 있습니다. 처음에는 완전탐색을 생각했지만 입력 크기 때문에 어렵다고 판단했다면, 그 과정 자체가 문제해결력입니다. 면접에서는 처음부터 정답을 떠올린 사람보다 한계를 발견하고 개선한 사람의 답변이 더 설득력 있게 들릴 수 있습니다.
- 입력 조건과 시간복잡도 판단도 함께 기록해야 합니다. 알고리즘 문제는 대부분 제한사항 안에 풀이 선택의 힌트가 들어 있습니다. 입력 크기가 작으면 완전탐색이 가능할 수 있고, 입력이 크면 정렬, 해시, 이분 탐색, 그래프 탐색, DP 같은 접근이 필요할 수 있습니다. 이 판단을 기록해 두면 나중에 면접에서 왜 그 방식이 적절했는지 설명할 수 있습니다. 단순히 외운 알고리즘이 아니라 조건을 보고 선택한 풀이였다는 점이 드러납니다.
- 해결 방향
앞으로 문제를 풀 때는 정답 여부만 확인하지 말고, 풀이 후 5분 정도를 사고과정 정리에 사용해야 합니다. 문제에서 핵심 조건은 무엇이었는지, 처음 떠올린 접근은 무엇이었는지, 그 방식의 한계는 무엇이었는지, 최종적으로 어떤 알고리즘을 선택했는지를 간단히 적어두면 됩니다. 이 기록은 처음에는 귀찮게 느껴질 수 있지만, 시간이 지나면 자신만의 면접 답변 자료가 됩니다. 저는 코딩테스트 준비에서 가장 아쉬운 순간이 정답은 맞았지만 배운 것이 남지 않는 경우라고 생각합니다. 문제를 많이 푸는 것도 중요하지만, 그 문제를 통해 어떤 판단을 했는지가 남아야 합니다. 그래야 코딩테스트 경험이 단순 시험 대비가 아니라 기술면접에서 말할 수 있는 문제해결 경험으로 바뀝니다.
알고리즘 풀이 기록이 면접 답변으로 연결되는 과정
- 공감 상황
코딩테스트를 꽤 오래 준비한 사람도 면접 직전에 다시 문제를 보면 기억이 흐릿한 경우가 많습니다. 분명히 풀었던 문제인데 왜 그렇게 풀었는지 생각나지 않고, 코드만 보면 그때의 고민이 떠오르지 않습니다. 실제로 준비생들의 GitHub나 개인 노션 기록을 보면 문제 제목과 정답 코드는 정리되어 있지만, 문제를 읽고 어떤 판단을 했는지에 대한 설명은 비어 있는 경우가 많았습니다. 어떤 준비생은 기록을 남겼다고 했지만, 내용을 보니 알고리즘 이름과 코드만 있었고 면접에서 말할 수 있는 문장은 거의 없었습니다. 저는 이런 기록은 복습 자료로도 약하고, 면접 답변 자료로도 부족하다고 봅니다.
- 막히는 원인
풀이 기록이 면접 답변으로 이어지지 않는 이유는 기록의 목적을 잘못 잡기 때문입니다. 많은 사람이 기록을 정답 코드 보관용으로 생각합니다. 하지만 취업 준비에서 필요한 기록은 코드 저장이 아니라 사고의 흔적입니다. 문제를 처음 봤을 때 어떤 유형이라고 판단했는지, 왜 해당 자료구조를 선택했는지, 어디에서 틀렸고 무엇을 수정했는지가 남아야 합니다. 이런 내용이 없으면 기록은 쌓이지만 실력은 분산됩니다. 면접에서 문제해결 경험을 묻는 질문이 나와도 많이 풀었습니다라는 말 외에는 구체적인 사례를 꺼내기 어렵습니다.
- 실제 예시
예를 들어 BFS 문제를 풀었다고 해보겠습니다. 단순히 BFS 사용이라고만 기록하면 나중에 다시 봤을 때 큰 도움이 되지 않습니다. 하지만 최단 거리 조건이 있었기 때문에 DFS보다 BFS가 적절하다고 판단했고, 중복 방문을 막기 위해 방문 배열을 사용했으며, 큐에 넣는 시점에서 방문 처리해야 같은 노드가 반복해서 들어가지 않는다는 점을 배웠다고 적으면 완전히 다른 기록이 됩니다. 면접에서 그래프 탐색 문제를 어떻게 접근했는지 질문이 나왔을 때, 이 기록은 바로 답변으로 바뀔 수 있습니다. 정답 코드보다 중요한 것은 왜 그 구조가 필요했는지 설명하는 문장입니다.
저는 풀이 기록을 보면 준비생의 공부 방식이 어느 정도 보인다고 생각합니다. 단순히 코드만 모아둔 기록은 문제를 소비한 흔적에 가깝습니다. 반면 실패한 접근, 수정한 이유, 다시 풀 때 주의할 점이 남아 있는 기록은 성장한 흔적에 가깝습니다. 면접관도 신입 지원자에게 완벽한 실무 경험을 기대하기보다는, 문제를 만났을 때 어떻게 배우고 개선하는지를 보고 싶어 할 가능성이 큽니다. 따라서 풀이 기록은 단순 복습이 아니라 학습 태도와 문제해결 방식을 보여주는 자료가 되어야 합니다.
- 풀이 기록에는 반드시 틀린 이유와 수정 과정을 남겨야 합니다. 준비생들은 틀린 풀이를 부끄러워해서 지우는 경우가 많지만, 실제로는 그 부분이 가장 가치 있는 기록일 수 있습니다. 처음에는 시간 초과가 났고, 그 이유가 중복 탐색 때문이었다면 그 사실을 적어야 합니다. 이후 어떤 자료구조로 개선했는지까지 남기면 면접에서 실패를 개선한 경험으로 설명할 수 있습니다.
- 기록은 짧아도 일정한 형식으로 남기는 것이 좋습니다. 문제 유형, 핵심 조건, 처음 접근, 최종 풀이, 시간복잡도, 실수한 부분, 다시 풀 때 주의할 점을 고정 항목으로 두면 됩니다. 매번 긴 글을 쓸 필요는 없지만, 이 항목들이 있으면 나중에 복습할 때 사고 흐름을 빠르게 되살릴 수 있습니다. 특히 기술면접 전에는 이 기록을 보면서 자신이 자주 실수하는 유형과 강한 유형을 확인할 수 있습니다.
- 해결 방향
풀이 기록을 면접 답변으로 활용하려면 처음부터 답변 문장으로 바꿀 수 있게 적어야 합니다. 예를 들어 이 문제는 입력 크기가 커서 완전탐색으로는 어렵다고 판단했고, 탐색 시간을 줄이기 위해 해시를 사용했습니다와 같은 문장을 남겨두면 좋습니다. 또는 최단 거리 조건이 있어 BFS를 선택했고, 중복 방문을 막기 위해 방문 배열을 사용했습니다처럼 정리할 수 있습니다. 이렇게 기록하면 면접에서 질문이 나왔을 때 외운 답변이 아니라 자신의 풀이 경험을 말할 수 있습니다. 저는 기록습관이 있는 준비생이 면접에서 훨씬 안정적으로 답한다고 생각합니다. 이유는 단순합니다. 머릿속에만 있던 생각은 시간이 지나면 흐려지지만, 문장으로 남긴 사고과정은 다시 꺼내 쓸 수 있기 때문입니다. 코딩테스트 기록은 공부의 부가 작업이 아니라 면접 답변을 만드는 핵심 과정입니다.
기록습관이 문제해결력을 설명하는 기준이 되는 이유
- 공감 상황
문제를 반복해서 풀다 보면 어느 순간 유형이 익숙해집니다. 정렬 문제, 해시 문제, 투 포인터 문제, 그래프 탐색 문제를 보면 대략 어떤 방식으로 접근해야 할지 감이 생깁니다. 하지만 면접에서는 이 감을 말로 설명해야 합니다. 실제 면접 답변 연습을 보면 저는 투 포인터로 풀었습니다, 정렬해서 풀었습니다, DP를 사용했습니다처럼 알고리즘 이름만 말하고 멈추는 경우가 많습니다. 면접관이 왜 그 방식을 선택했나요, 다른 방식은 왜 어렵다고 봤나요, 시간복잡도는 어떻게 되나요라고 물으면 답변이 흔들립니다. 이 장면을 보면 반복 훈련이 아직 설명 가능한 문제해결력으로 바뀌지 않았다는 생각이 듭니다.
- 막히는 원인
이 문제가 생기는 이유는 혼자 문제를 풀 때 말로 설명하는 훈련을 하지 않기 때문입니다. 코딩테스트는 혼자 푸는 시간이 많습니다. 그래서 머릿속으로 대략 이해하고 넘어가도 당장 정답 제출에는 문제가 없을 수 있습니다. 하지만 면접은 다릅니다. 면접에서는 생각의 흐름을 언어로 드러내야 합니다. 어떤 조건을 보고 접근을 골랐는지, 어떤 예외 케이스를 고려했는지, 구현 중 어떤 실수를 조심했는지 설명해야 합니다. 이 연습이 없으면 문제를 풀 수는 있어도 개발자다운 문제해결력으로 전달하기 어렵습니다.
- 실제 예시
예를 들어 투 포인터 문제를 풀었다고 가정해 보겠습니다. 단순히 투 포인터를 사용했습니다라고 말하면 답변이 짧습니다. 하지만 배열이 정렬되어 있고, 양쪽 끝에서 값을 조정하면서 조건에 맞는 합을 찾을 수 있다고 판단했기 때문에 투 포인터를 사용했습니다라고 말하면 선택 근거가 보입니다. 또 포인터가 이동하는 기준과 종료 조건을 함께 설명하면 구현 이해도도 드러납니다. DP 문제도 마찬가지입니다. DP를 사용했습니다라고 말하기보다, 같은 하위 문제가 반복되고 이전 결과를 재사용할 수 있는 구조였기 때문에 DP로 접근했습니다라고 설명해야 합니다. 이런 문장 하나가 면접 답변의 수준을 바꿉니다.
저는 코딩테스트 준비에서 가장 중요한 전환점이 혼자 이해한 것을 남에게 설명할 수 있는 순간이라고 생각합니다. 개발자는 혼자 정답 코드를 만드는 사람만이 아니라, 자신이 해결한 문제를 동료에게 설명하고 공유해야 하는 사람입니다. 면접에서도 이 부분이 드러납니다. 정답 여부보다 설명이 더 중요한 순간이 있습니다. 풀이를 설명하는 과정에서 문제 이해도, 논리성, 개선 가능성, 학습 태도가 함께 보이기 때문입니다.
- 문제 풀이 후 1분 설명 연습을 해보는 것이 좋습니다. 문제를 풀고 나서 바로 넘어가지 말고, 이 문제의 핵심 조건은 무엇이었는지, 왜 이 알고리즘을 선택했는지, 시간복잡도는 어떻게 되는지 소리 내어 말해보는 방식입니다. 말이 막히는 부분은 아직 이해가 부족한 부분일 가능성이 큽니다. 이 연습을 반복하면 면접장에서 예상하지 못한 질문이 나와도 생각을 정리해 말하는 힘이 생깁니다.
- 답변은 문제 이해, 접근 선택, 구현 주의점, 검증 순서로 정리하면 좋습니다. 먼저 문제에서 요구하는 결과와 제한 조건을 말하고, 그 조건 때문에 어떤 접근을 선택했는지 설명해야 합니다. 이후 구현하면서 주의한 부분과 예외 케이스를 덧붙이면 답변이 더 안정적입니다. 마지막으로 시간복잡도나 개선 가능성을 말하면 단순 풀이 설명을 넘어 개발자다운 검토 과정이 드러납니다.
- 해결 방향
반복 훈련을 면접 답변으로 바꾸려면 문제를 풀 때마다 짧은 설명 템플릿을 적용해야 합니다. 이 문제는 어떤 조건 때문에 어려웠는지, 처음에는 어떤 접근을 생각했는지, 최종적으로 어떤 알고리즘을 선택했는지, 왜 그 방식이 더 적절했는지, 다시 푼다면 무엇을 개선할 것인지를 정리하는 것입니다. 이 흐름을 3~5 문장으로 말할 수 있으면 면접 답변이 훨씬 자연스러워집니다. 저는 코딩테스트 준비가 단순히 코딩 실력을 증명하는 과정만은 아니라고 생각합니다. 제대로 정리하면 문제를 분석하고 개선하는 사람이라는 인상을 줄 수 있습니다. 따라서 앞으로는 문제 수를 늘리는 것과 함께, 풀이를 설명하는 시간을 반드시 가져야 합니다. 기록하고, 말해보고, 다시 고치는 과정이 반복될 때 코딩테스트 준비는 면접 답변과 연결되는 강한 경험이 됩니다.
- conclusion
코딩테스트 준비가 면접 답변과 연결되는 이유는 정답 코드보다 사고과정이 더 오래 남기 때문입니다. 문제를 많이 푸는 것도 중요하지만, 왜 그 알고리즘을 선택했는지, 어떤 조건을 보고 판단했는지, 실패한 접근을 어떻게 개선했는지 설명할 수 있어야 합니다. 지금 코딩테스트를 준비하고 있다면 세 가지를 점검해야 합니다. 첫째, 정답 코드만 남기고 있지는 않은지 확인해야 합니다. 둘째, 풀이 기록에 처음 접근, 선택 이유, 시간복잡도, 실수한 부분이 들어 있는지 봐야 합니다. 셋째, 문제를 푼 뒤 3~5 문장으로 면접 답변처럼 설명할 수 있는지 연습해야 합니다. 저는 기록습관이 있는 준비생이 결국 면접에서도 더 안정적으로 답한다고 생각합니다. 코딩테스트는 합격을 위한 관문이지만, 제대로 정리하면 개발자다운 문제해결력을 보여주는 가장 좋은 자료가 될 수 있습니다.
