코딩테스트 통과의 지름길, 문제풀이 후 코드 리뷰 습관 만들기

당신이 놓치고 있는 것

코딩테스트 준비하면서 매일 알고리즘 문제를 풀어본다. 하루에 3개, 5개, 때로는 10개까지. 맞았다고 나오면 다음 문제로 넘어가고, 틀렸다면 해설을 보거나 구글링해서 방법을 찾아본다. 빠르게 많은 문제를 푼다는 것 자체가 실력을 키우는 것이라고 믿으면서.

하지만 여기서 정말 중요한 게 빠져있다는 걸 알고 있는가? 바로 자신이 쓴 코드를 다시 읽어보는 습관이다.

 

나도 처음엔 그랬다. 알고리즘 문제 풀 때는 마치 시험을 보는 심정으로 문제를 풀고, 통과하면 끝이라고 생각했다. 입사 시험도 아니고 그냥 연습이잖아. 빨리빨리 많은 문제를 풀어야 내 실력이 늘겠지 하는 생각으로 말이다.

 

그런데 인턴십 때 팀장님한테서 받은 피드백은 충격이었다.

 

"코드는 맞는데, 왜 이렇게 짜셨어요?"

 

문제는 풀렸지만, 풀이 방식이 최선이 아니었다는 뜻이었다. 같은 결과를 내지만 더 효율적인 방법이 있었고, 가독성 면에서도 부족했다. 메모리는 더 많이 쓰고 속도도 느렸다. 단순히 "동작한다"는 것만으로는 부족했던 것이다.

 

그 날부터 내 코딩테스트 준비 방식이 완전히 바뀌었다. 이제는 문제를 풀고 나서 항상 다시 한 번 내 코드를 객관적으로 보고, 뭐가 부족한지 찾아내는 시간을 갖는다. 이걸 반복하면서 합격 통보를 받을 수 있었다.

코드 리뷰가 뭔데 자기 코드를 리뷰한다고?

"코드 리뷰는 팀 내에서 누군가 다른 사람의 코드를 검토하는 과정 아닌가?"

당연히 그게 맞다. 하지만 코딩테스트 준비 단계에서는 자신의 코드를 스스로 리뷰하는 습관을 들여야 한다. 회사에 들어가서 할 코드 리뷰 문화를 미리 체험하는 셈이다. 그리고 가장 중요한 건, 이 과정이 당신의 코드 품질을 극적으로 높인다는 거다.

 

자기 코드를 객관적으로 보기는 생각보다 어렵다. 본인이 쓴 코드는 마치 자신의 아이처럼 느껴지기 때문이다. "이 코드는 맞아", "이게 최선이야"라고 생각하기 쉽다. 하지만 다시 한 번 냉철하게 보면 수많은 개선 포인트가 보인다.

 

내가 지금 사용하는 방법은 간단하다. 코드를 다 쓰고 나서 한 30분쯤 기다렸다가 다시 읽어본다. 그 사이 뇌가 "작가 모드"에서 "독자 모드"로 전환되기 때문이다. 신기할 정도로 그동안 못 봤던 문제들이 눈에 들어온다.

구체적으로 뭘 리뷰하나

처음 이 습관을 들일 때는 뭘 봐야 할지 몰라서 막막했다. 그래서 체크리스트를 만들었고, 지금까지 이걸 기준으로 코드를 본다. 너도 이 기준으로 시작하면 금방 감을 잡을 거다.

 

알고리즘의 시간 복잡도와 공간 복잡도

가장 먼저 보는 건 이거다. 내 풀이 방식이 문제에서 요구하는 시간 내에 동작할까? 메모리는 충분할까?

예를 들어, 배열의 모든 원소를 비교해야 하는 문제라면 O(n²) 또는 O(n log n) 정도를 목표로 한다. O(n³) 정도면 데이터 크기가 작을 때는 통과하겠지만, 대규모 데이터에서는 시간 초과가 난다.

 

내가 자주 하는 실수는 "일단 풀리니까 괜찮겠지" 하면서 비효율적인 알고리즘으로 제출하는 거였다. 회사 인터뷰나 코딩테스트 채점 시스템은 단순히 "맞는지 틀렸는지"만 보지 않는다. 효율성도 본다.

 

변수명이 명확한가

코드를 다시 읽을 때 가장 먼저 거슬리는 게 이거다. a, b, tmp, cnt 같은 이름들이 쏟아져 나온다.

 

"여기서 a가 뭔데? 아, 입력받은 배열이구나."

 

이 정도의 해석 시간이 필요하면 안 된다. 변수명만 봐도 뭔지 알아야 한다. inputArray, currentIndex, maxValue 정도면 충분하다. 한글 변수명도 나쁘지 않다. 최댓값, 현재위치 정도면 명확하다.

 

회사 코드 리뷰에서 가장 먼저 피드백받는 부분이 변수명이다. 인터뷰어들은 너의 알고리즘 실력도 보지만, 코드의 가독성이 좋은지도 본다. 그게 팀에서 협업할 수 있는 개발자인지를 판단하는 기준이기 때문이다.

 

중복 코드가 있는가

코드를 쓰다 보면 같은 로직을 여러 번 반복하게 된다.

if (A > B) {
    result = calculateValue(A);
    updateStatus(A);
}

if (C > D) {
    result = calculateValue(C);
    updateStatus(C);
}

이런 식으로 쓰면 나중에 버그가 발생했을 때 여러 곳을 수정해야 한다. 중복을 없애는 방법을 생각해야 한다. 함수로 뽑아내든, 루프로 처리하든, 전략 패턴을 쓰든.

 

코딩테스트에서는 개별 문제만 풀면 되니까 중복이 크리티컬하지 않을 수 있다. 하지만 회사에서 일할 때는 유지보수 악몽이 된다.

 

엣지 케이스를 처리했는가

이 부분이 가장 자주 놓친다. 문제는 풀었지만, 엣지 케이스가 있는가?

• 입력 비어있으면?
• 음수면?
• 배열의 크기가 1이면?
• 모든 값이 같으면?

실제 테스트 케이스에는 당신이 생각 못 한 예상치 못한 입력들이 숨어있다. 코드를 다시 읽으면서 "혹시 이 경우는 어떻게 되지?"라고 계속 물어봐야 한다.

 

예를 들어, 배열에서 최댓값을 찾는 코드를 쓴다고 하자.

max = arr[0]
for i in 1 to len(arr)-1:
    if arr[i] > max:
        max = arr[i]
return max

이 코드는 배열이 비어있으면 오류가 난다. 첫 번째 줄에서 arr[0]에 접근할 수 없으니까. 코드 리뷰할 때 이런 부분을 반드시 체크해야 한다.

 

좀 더 간결한 방법이 없을까

같은 결과를 내지만 더 짧고 간결한 코드가 있다면? 예를 들어, 파이썬에서는 max() 함수를 쓸 수 있는데 굳이 루프를 돈다거나.

물론 너무 복잡한 한 줄짜리 코드는 가독성이 떨어진다. 하지만 표준 라이브러리나 자주 쓰는 패턴을 활용해서 코드를 간결하게 만들 수 있다면 좋다.

 

"와, 이렇게도 할 수 있네?"

이런 경험들이 쌓이면서 너의 코딩 스타일이 점점 더 전문적으로 변한다.

실제로 적용해본 경험

내가 이 방법을 시작한 지 몇 달 되니까, 변화가 확실히 느껴진다.

 

처음에는 코드 리뷰하면서 30분, 1시간씩 걸렸다. "어, 이건 왜 O(n²)이지?", "이 함수는 뭐 하는 함수지?" 이렇게 자기 코드를 자기가 못 이해하는 경험들이 자주 생겼다.

 

지금은 문제를 푼 후 코드 리뷰하는 데 5~10분 정도면 충분하다. 변수명이 명확하고, 로직이 간결하기 때문이다. 그리고 리뷰 결과는?

• 첫 제출 통과율이 올라갔다
• 같은 문제를 푸는 데 걸리는 시간이 줄었다 (처음 풀이는 길어도, 최적화가 빨라졌단 뜻)
• 면접 때 내 코드를 설명하기 훨씬 자연스러워졌다
• 팀 코드 리뷰에서 받는 피드백이 줄어들었다

마지막 포인트가 가장 중요하다. 회사에서 일할 때, 코드 리뷰는 피할 수 없다. 하지만 미리 스스로 리뷰하는 습관이 있으면, 받는 피드백의 양이 현저히 줄어든다. 그리고 받는 피드백도 "당신의 기초가 탄탄하네요"라는 수준이 된다.

좀 더 체계적으로 하려면

지금까지는 내 경험 기반으로 얘기했는데, 좀 더 구조적으로 접근할 수도 있다.

Google의 코드 리뷰 가이드를 보면 체크리스트가 나온다.

1. 디자인: 코드의 구조가 합리적인가
2. 기능: 코드가 의도대로 동작하는가
3. 복잡도: 코드가 불필요하게 복잡하지 않은가
4. 테스트: 충분한 테스트가 있는가
5. 네이밍: 변수, 함수명이 명확한가
6. 코멘트: 필요한 부분에 설명이 있는가

코딩테스트에서 테스트까지 짜야 하는 건 아니지만, 나머지는 모두 적용할 수 있다.

 

또 다른 방법은 체크리스트를 만드는 것이다. 내가 자주 실수하는 부분을 메모해두고, 매번 코드를 리뷰할 때 그 항목들을 확인한다.

예를 들어, 내 체크리스트는 이렇다.

• 시간 복잡도와 공간 복잡도 확인
• 변수명이 명확한가
• 함수 이름이 무엇을 하는지 나타내는가
• 엣지 케이스 처리했는가
• 불필요한 루프가 있는가
• 라이브러리 함수로 더 간결하게 할 수 있는가
• 주석은 적절한가 (너무 많진 않은가)
• 코드 스타일이 일관되는가 (들여쓰기, 따옴표 등)

매번 이걸 체크하다 보니, 자동으로 좋은 습관이 생긴다. 처음 코드를 쓸 때부터 "어차피 이건 리뷰할 거니까 제대로 쓸까"라는 마음가짐이 생기는 거다.

팀과 함께하는 코드 리뷰 문화

개인 차원의 리뷰도 중요하지만, 가능하면 친구나 스터디 그룹과 함께 코드를 리뷰하는 게 더 좋다.

 

왜냐하면, 자기 코드는 자기가 쓴 로직으로 가득 차 있어서 객관성이 떨어지기 때문이다. 다른 사람의 눈으로 보면 "어, 이 부분은 왜 이렇게 했어?"라는 질문이 나온다. 그리고 그 질문이 바로 개선 포인트다.

 

나도 요즘 주말에 코딩 스터디를 하는데, 그룹에서 가장 효과 있는 시간이 바로 "코드 리뷰 세션"이다. 각자 풀어온 문제를 돌아가며 설명하고, 다른 사람들이 "왜 이렇게 했어?", "이렇게 할 수도 있지 않을까?"라고 물어본다.

 

그 과정에서 나는

• 내 코드를 설명하는 능력을 기른다 (면접 때 필수)
• 다른 사람의 풀이 방식을 배운다
• 같은 문제를 여러 각도에서 본다
• 자신감을 얻는다

회사에서 코드 리뷰 문화가 가장 강한 팀들이 고급 개발자들을 많이 배출한다는 건 우연이 아니다.

회사 입사 후의 이점

코딩테스트 준비할 때 코드 리뷰 습관을 들이면, 회사에 입사한 후에 차별점이 생긴다.

 

대부분의 신입들은 처음 코드 리뷰를 받으면 당황한다. "내 코드에 왜 이렇게 많은 피드백이 있어? 뭐가 문제야?"

하지만 이미 자기 코드를 리뷰하는 습관이 있는 사람은 다르다. 받는 피드백이 적고, 받더라도 "아, 그렇구나. 좋은 지적이네"라고 객관적으로 받아들인다.

 

또한, 코드 리뷰를 할 때도 마찬가지다. 누군가 다른 사람의 코드를 리뷰해야 하면, 자신이 이미 리뷰받아본 경험이 있으니 어떤 관점으로 봐야 할지 자연스럽게 나온다.

마지막 조언

코딩테스트 준비하면서 이 습관이 중요하다는 걸 깨닫고 나서, 나는 다음과 같은 원칙으로 공부한다.

1. 속도보다 품질 우선
   많은 문제를 빨리 푸는 것도 좋지만, 한 문제를 제대로 푸는 게 더 중요하다. 코드 리뷰를 통해 한 문제에서 얻는 배움이 더 크다.
2. 자신의 코드가 최선이 아니라고 생각하기
   "내 코드는 맞으니까 됐어" 이 마음가짐을 버려야 한다. 모든 코드는 개선의 여지가 있다.
3. 정기적으로 과거 코드 보기
   예를 들어, 3개월 전에 풀었던 문제를 다시 보자. 그땐 이렇게 짰는데, 지금은 이렇게 할 수 있다는 걸 깨닫는 순간이 있다. 이게 성장의 신호다.
4. 온라인 문제 풀이 플랫폼 활용
   Programmers, LeetCode 같은 플랫폼들을 보면 다른 사람들의 풀이가 나온다. 내 코드를 먼저 리뷰한 후, 상위 등급의 풀이와 비교해보자. 뭐가 다른지, 왜 그렇게 했는지 분석하는 게 큰 공부가 된다.

코딩테스트는 단순히 "문제를 풀 수 있는가"를 묻지 않는다. "얼마나 좋은 코드로 풀 수 있는가"를 묻는다. 그리고 면접관은 당신의 코드를 보고 "이 사람이 우리 팀에서 좋은 팀원이 될까?"를 판단한다.

 

문제를 푼 후 코드를 다시 한 번 보는 30분이 당신의 합격 확률을 수십 퍼센트 올린다. 그리고 입사한 후 팀과의 협업도 더 수월하게 만든다.

 

지금 이 글을 읽고 있다면, 다음 번에 코딩 문제를 풀 때 한 가지만 더 해보자. 문제 푸는 데 30분 걸렸다면, 코드 리뷰하는 데 5분을 더 쓰자. 그 작은 습관이 당신을 다른 개발자와 구분되게 만들 것이다.

 

입사 코딩테스트 준비, 강의와 교재는 이것들로 충분하다