입사 코딩테스트 준비할 때 ‘주석’과 ‘가독성’ 좋은 코드 작성 실전 팁

요즘 이직 준비하면서 코딩테스트를 꾸준히 풀다 보니, 예전에는 그냥 “통과만 하면 됐지” 하고 넘겼던 주석과 코드 가독성이 점점 더 신경 쓰이기 시작했다. 특히 실무 경력이 있다 보니, 면접관 입장에서는 “이 사람이 문제만 푸는 사람이냐, 팀에서 같이 코드를 유지보수할 수 있는 사람이냐”를 코드를 통해 보고 싶어 한다는 생각이 자꾸 들었다.
 
그래서 이번 글은 코딩테스트를 준비하면서 직접 신경 쓰고 있는 주석 스타일과 가독성을 챙기는 구체적인 습관들을 한 번 정리해 보려고 한다. 시험장에서는 시간에 쫓기니까 모든 걸 적용하긴 어렵지만, 평소 연습할 때부터 이런 기준을 몸에 익혀 두면 면접에서 코드 리뷰를 할 때나, 사후 풀이를 블로그에 정리할 때도 꽤 큰 도움이 된다.
 

코딩테스트에서 주석은 얼마나 중요한가?

먼저 짚고 넘어가야 할 게 하나 있다. 온라인 코테 자동 채점 환경에서는 사실 주석이 점수에 직접적인 영향을 주지 않는다. 컴파일/실행 시에 주석은 다 무시된다. 그럼에도 불구하고 주석을 연습해야 하는 이유는 크게 세 가지 정도로 정리할 수 있다.

면접 전형과 연계될 때

• 어떤 회사는 온라인 코테를 보고 나서, 면접에서 본인이 작성한 코드를 같이 리뷰하기도 한다. 이때 코드에 최소한의 구조와 설명이 달려 있으면, 기억도 되살리기 쉽고, 논리를 다시 설명하기도 수월하다. “아, 이때 이렇게 생각해서 이 방법을 선택했구나”를 스스로도 다시 확인할 수 있다.

과제형/오픈북 코테에서의 가독성

• 특정 기업에서는 Git 저장소로 과제를 제출하게 하거나, 로컬에서 프로젝트 형태로 문제를 푸는 방식도 쓴다. 여기서는 사실상 실무에 가까운 코드 스타일이 중요하고, 주석과 가독성을 어느 정도 신경 쓰지 않으면 감점 요인이 될 수 있다. 클래스/메서드 레벨의 간단한 설명만 잘 달아줘도 평가하는 입장에서는 훨씬 읽기 편해진다.

자기 공부용으로 남길 때

• 코딩테스트를 준비하다 보면, 같은 유형의 문제를 몇 번이나 다시 만나게 된다. 그런데 예전에 풀었던 코드가 주석 하나 없이 난해하게 적혀 있으면, “이게 뭐였지?” 하면서 다시 처음부터 고민해야 한다. 반대로 핵심 아이디어와 시간 복잡도 정도만 달아둬도 복습 속도가 확 줄어든다.
• 특히 블로그에 풀이를 정리할 때, “주석 + 설명글” 구조로 풀어놓으면 나중에 면접 준비할 때도 요약 자료로 쓰기 좋다.

결론만 말하면, 순수 온라인 자동 채점 환경에서의 점수 = 주석과 무관이지만, 장기적으로 나의 학습 효율 + 면접 대응력까지 생각하면 주석 연습은 이득이다.

코테용 주석, 어디까지 달아야 할까?

주석은 “많이” 다는 게 중요한 게 아니라, “딱 필요한 만큼만, 정확히” 다는 게 중요하다. 개인적으로 코딩테스트 풀면서 유지하려고 하는 기준은 다음 정도다.
 

최소한 이 정도는 달아두자

코딩테스트 풀이 코드에서 아래 네 가지는 웬만하면 항상 남기려고 한다.
 
문제 핵심 요약 (한두 줄)
“어떤 문제인지”를 나중에 봐도 바로 떠올릴 수 있는 정도의 요약.

// N개의 수에서 부분수열 합이 S가 되는 경우의 수를 구하는 문제

 
접근 방법/알고리즘 이름 한 줄
단순 구현인지, DFS/BFS인지, DP인지, 정렬 + 투 포인터인지 등 어떤 전략으로 풀었는지를 짧게.

// 백트래킹(부분수열 모두 탐색)으로 해결, 시간복잡도 O(2^N)

 
시간·공간 복잡도
특히 N의 범위가 넉넉지 않을 때, 왜 이 방법을 선택했는지 설명이 된다.

// N <= 20 이므로 모든 부분집합 탐색 가능, O(2^N)

 
특이 케이스 처리 부분
예를 들어, “합이 0일 때 공집합은 제외한다” 같은 조건을 처리하는 코드에는 반드시 주석을 붙인다.

// 공집합은 합이 0이어도 경우의 수에서 제외해야 함

이 네 가지만 지켜도, 나중에 내 코드만 봤을 때도 “아, 이게 이런 문제였지” 하고 금방 이해 가능하다.
 

달지 않는 편이 좋은 주석

반대로, 코테 풀이에서 굳이 달지 않는 편이 좋은 주석도 있다.
 
코드 그대로 반복하는 주석

int n = sc.nextInt(); // n을 입력받는다

이런 건 사실 거의 정보가 없다. 변수 이름만 n이 아니라 numberOfNodes 정도로만 바꿔줘도 굳이 주석이 필요 없다. “코드만 읽어도 충분히 이해”되게 만드는 게 더 낫다.

 

이미 너무 유명한 API/문법 설명
Java에서 Arrays.sort(arr); 정도는 대부분 개발자가 알기 때문에 굳이 “배열 정렬”이라고 주석을 달 필요가 없다. 오히려 알고리즘 단계에 대한 설명을 다는 게 더 낫다.

// 정렬 후 투 포인터로 두 수의 합이 S가 되는 경우 탐색
Arrays.sort(arr);

 
나중에 봐도 모호한 감정/상태 주석

// 여기서 시간 초과 나는 듯?
// 이 부분은 좀 더 생각해보기

이런 메모 수준의 주석은, 깔끔하게 정리해서 블로그에 올리기 전에는 그냥 본인 연습 코드에만 남기는 게 좋다. 제출용 혹은 공유용 코드에서는 최종적으로 선택한 접근과 근거만 남기는 게 정리된 느낌을 준다.

가독성 높은 코드는 결국 "구조"에서 갈린다

주석을 잘 다는 것도 좋지만, 근본적으로는 주석이 없어도 읽히는 코드가 가장 이상적이다. 그 핵심은 결국 “구조”다. 코테 풀이에서 특히 신경 쓰는 구조화 포인트를 몇 가지로 정리해 보자.
 

함수 분리: "한 함수 = 한 역할"

코테 풀다 보면 main 함수 안에 모든 걸 다 때려 넣고 싶을 때가 많다. 그런데 조금만 여유가 있으면 역할별 함수 분리를 하는 게 좋다. 예를 들어, 전형적인 BFS 문제라면 아래처럼 나누는 식이다.

• 입력 처리
• BFS/DFS 로직
• 결과 출력

Java 기준으로는 최소한 BFS/DFS, 혹은 핵심 로직은 별도 메서드로 빼는 습관을 들이는 게 좋다.

// BFS로 최단 거리 계산
private static int bfs(int startX, int startY) {
    // ...
}

이렇게 해두면 main 안에서는 bfs를 호출하는 흐름만 보면 되기 때문에 읽기가 한결 수월해진다.

 

이름 짓기: 축약보다 의미 전달

코테에서는 타이핑 수를 줄인다고 변수명을 a, b, c, arr, list 정도로만 쓰는 경우가 많다. 하지만 반복해서 풀다 보면, 이름을 조금만 정성 들여 짓는 것만으로도 코드 해석 속도가 크게 빨라진다.

 
예를 들면 다음과 같이 바꾼다.

• arr → numbers, heights, distances 등 문제 도메인에 맞는 이름
• visited → visited, isVisited (이건 이미 충분히 의미가 명확하다)
• temp → candidate, current, next 등 역할이 드러나는 이름

구체적으로는 아래와 같은 식이다.

// 나쁨
int[] arr = new int[n];

// 좋음
int[] heights = new int[n];

특히 면접에서 코드를 같이 보면서 설명해야 할 때는, 변수 이름만 제대로 지어놔도 구두 설명이 훨씬 부드럽게 흘러간다.
 

공백과 줄바꿈: "코드도 문단이 있다"

글을 쓸 때 문단을 나누는 것처럼, 코드도 의미 단위마다 공백과 줄바꿈을 적당히 써주는 것이 좋다.
 
개인적으로 신경 쓰는 포인트는 대략 이렇다.

• 입력/초기화 블록과 알고리즘 실행 부분 사이에 한 줄 띄우기
• 큰 루프/조건문 안에서도 “준비 → 처리 → 후처리”가 구분되면 적당히 줄바꿈
• if/for 괄호 안의 조건이 복잡하면, 적어도 연산자 기준으로 공백을 맞춰 주기

예를 들어,

if(currentDistance + weight < dist[next]) {
    dist[next] = currentDistance + weight;
    pq.add(new Node(next, dist[next]));
}

이 정도만 돼도, 디테일한 설명 없이도 “최단 거리 업데이트 + 큐 삽입”이라는 흐름이 눈에 들어온다.

실제 코테 풀이 코드에 어떻게 적용할까 (Java 예시 위주)

이제 조금 더 구체적으로, 코테 문제 하나를 푼다고 가정하고 어디에 어떤 주석과 구조를 넣을지를 단계별로 정리해 보자. 실제 코드 수준으로 예를 들어 보되, 여기서는 아이디어 전달이 목적이니까 문제 자체는 단순화한다.
 

파일 상단: 문제 요약 + 접근법 + 복잡도

연습용 코드라면, 파일 맨 위에 아래 세 가지를 남기는 습관을 들이면 좋다.

/*
 * 문제: N개의 정수에서 합이 S가 되는 부분수열의 개수를 구하라.
 * 접근: 백트래킹으로 모든 부분수열 탐색.
 * 시간복잡도: N <= 20이므로 O(2^N) 가능.
 */

나중에 이 코드를 블로그에 가져다 쓸 때도, 이 세 줄이 글의 첫 부분 요약이 된다.
면접에서 “이 문제 풀이 과정을 설명해보세요”라고 했을 때도, 저 세 줄만 보고 다시 떠올리면 된다.
 

핵심 로직 함수에만 주석을 집중

전체 코드에 10줄, 20줄씩 주석을 다는 것보다, 핵심 로직이 들어 있는 함수 한두 개에 설명을 집중하는 편이 훨씬 효율적이다.
 
예를 들어 백트래킹 함수라면

// idx: 현재 고려 중인 인덱스
// sum: 지금까지 선택한 원소들의 합
private static void dfs(int idx, int sum) {
    // 종료 조건: 모든 원소를 다 고려했을 때
    if (idx == n) {
        // 공집합은 제외해야 하므로, 최소 한 개 이상 선택했는지 체크 필요
        if (sum == s && selectedCount > 0) {
            answer++;
        }
        return;
    }

    // 1) 현재 원소를 선택하는 경우
    selectedCount++;
    dfs(idx + 1, sum + numbers[idx]);
    selectedCount--;

    // 2) 현재 원소를 선택하지 않는 경우
    dfs(idx + 1, sum);
}

이 정도만 써줘도, 나중에 보면 “아, 이게 부분집합 구하는 전형적인 백트래킹이구나” 하는 게 바로 떠오른다. 특히 예외적인 조건(공집합 제외 같은)은 반드시 주석으로 남겨두는 편이 좋다.

"시험장에서 이걸 다 지킬 수 있을까?"에 대한 현실적인 기준

여기까지 이야기하면 보통 바로 떠오르는 고민이 이거다.
“실제 시험에서는 시간도 부족한데, 이걸 다 지키면서 코드를 짜는 게 가능할까?”
 
개인적으로 잡은 기준은 다음과 같다.
 
온라인 자동 채점 코테 (시간 빡셀 때)
우선순위는 무조건 “정확하게 통과하는 코드”다. 이때는 불필요한 장식은 과감히 버리고, 딱 아래 정도만 챙기려고 한다.

• 파일/코드 상단에 한 줄짜리 접근법 요약
• 핵심 로직 함수에 간단한 주석 2~3줄
• 변수 이름은 최소한 길더라도 의미가 드러나게

이 정도면 시간 낭비 없이도, 나중에 봐도 무슨 코드인지 알아볼 수 있는 수준은 된다.
 
과제형/오프라인 혹은 여유 있는 코테
시간이 좀 넉넉하고, 코드 자체를 평가하는 비중이 높아 보이는 경우는

• 함수 분리를 조금 더 적극적으로 한다.
• 클래스/메서드 단위에 한 줄짜리 설명을 붙인다.
• 예외 처리(엣지 케이스) 있는 부분에는 주석을 꼭 붙인다.
• 입출력/비즈니스 로직/헬퍼 유틸을 물리적으로도 구분해 둔다.

연습/복습/블로그용 코드
이때는 가독성과 설명을 최우선으로 삼는다. 실제 시험에서 작성한 날것의 코드를 그대로 올리기보다는, 아래 과정으로 한 번 “리팩터링 버전”을 만들어 두는 걸 추천한다.

• 변수/함수 이름 정돈
• 출력문 정리 (디버깅용은 제거)
• 핵심 로직 중심으로 주석을 다시 다듬기
• 비슷한 코드 중복이 있으면 헬퍼 메서드로 추출

이렇게 정리한 버전을 블로그에 올리면, 나중에 비슷한 문제를 볼 때 사실상 개인 레퍼런스 코드처럼 활용할 수 있다.

블로그에 풀이를 올릴 때 쓸 만한 주석/설명 패턴

코딩테스트 준비를 하다 보면, 풀이를 블로그에 정리하는 것 자체가 공부가 된다. 이때 “코드 안의 주석”과 “글의 설명”을 어떻게 나눌지 애매할 때가 있는데, 다음 패턴이 꽤 쓸만하다.
 
글에서 문제 요약 + 입력/출력 형식 설명
코드 주석에는 문제 전체 설명을 길게 쓰기보다는, 블로그 글 상단에서 텍스트로 정리하는 편이 좋다.
 

코드 상단에는 접근법/복잡도만 요약
위에서 말한 것처럼 /* 접근, 시간복잡도 */ 정도의 주석만 남겨둔다.

 
코드 중간에는 "아이디어가 숨어 있는" 부분에만 집중 주석
단순 반복/입력 처리 등은 굳이 주석을 많이 쓰지 않고,
“왜 이렇게 해야 하는지” 설명이 필요한 로직에만 주석을 집중한다.
 
글 본문에서 그림이나 예시와 함께 보충 설명
예를 들어, 슬라이딩 윈도우 알고리즘이라면,
코드 주석에서는 “왼쪽 포인터를 이동시키며 윈도우 축소” 정도만 적어두고,
글에서는 실제 예제 배열을 가지고 포인터가 어떻게 움직이는지 그림이나 표로 보여준다.
 
이렇게 하면, 코드 자체는 깔끔하게 유지하면서도, 글은 충분히 친절하게 쓸 수 있다.

평소 연습 루틴에 "주석 + 가독성"을 끼워 넣는 방법

주석과 가독성을 “신경 써야지”라고 마음 먹는 것만으로는 잘 안 바뀐다. 결국 평소 연습 루틴 속에 체크 리스트처럼 끼워 넣는 게 제일 확실하다. 예를 들어, 코딩테스트 사이트에서 문제 하나를 풀 때 다음 순서를 반복하는 식이다.
 
첫 풀이: 일단 통과하는 코드 작성
여기서는 시간 복잡도만 대략 맞추고, 테스트 케이스를 통과하는 데 집중한다. 변수 이름은 너무 심하게 줄이지만 않도록 정도만 신경 쓴다.
 
통과 후 2~3분 투자해서 정리

• 파일 상단에 문제/접근/복잡도 요약 주석 추가
• 핵심 로직 함수에 필요한 곳만 주석 추가
• 자명하지 않은 변수 이름 한두 개 정리

이 과정은 진짜 2~3분이면 충분해서, 하루에 여러 문제를 풀어도 큰 부담이 되지 않는다.
 
다른 사람 코드 구경할 때, "주석/가독성 관점"도 같이 보기
같은 문제를 푼 사람들 중에 “잘 정리된 풀이”를 보면, 그 사람의 변수 이름, 함수 분리 방식, 주석 스타일을 눈여겨보는 것도 좋다. 실제로 실무 코드를 잘 쓰는 사람들 보면, 코테 풀이도 비슷한 감각으로 깔끔하게 정리해 놓는 경우가 많다.
 
블로그에 올릴 때는 "최종 버전"으로 정리해서 업로드
온라인 저지에 제출한 날것의 코드를 그대로 붙여넣지 말고,

• 이름 정리
• 주석 다듬기
• 불필요한 print 제거

“면접장에서 보여줘도 부끄럽지 않은 버전” 느낌으로 정리해서 올려두면 나중에 자기소개서나 포트폴리오에도 활용하기 좋다.

코딩테스트 코드는 결국 "면접장까지 간다"는 생각으로

지금 당장은 코딩테스트 점수만 중요해 보일 수 있다. 하지만 실제로 입사를 준비하다 보면, 온라인 코테에서 한 번 끝나는 게 아니라 그 이후 기술 면접, 코드 리뷰, 과제 전형 등으로 계속 이어지는 경우가 많다. 이때 결국 평가받게 되는 것은 “이 사람이 코드를 어떻게 생각하고, 어떻게 정리하는 사람인지”다.
 
그래서 코딩테스트 연습을 할 때부터

• 불필요하게 장황한 주석은 줄이고, 꼭 필요한 설명만
• 변수/함수 이름에 약간의 정성을 들이고
• 핵심 로직에는 최소한의 구조와 주석을 붙여 주고
• 연습 후에는 2~3분이라도 리팩터링 시간을 투자하는 습관을 들이는 것

이 네 가지만 꾸준히 지켜도,
나중에 내 코드를 다시 볼 때 “이때 정말 열심히 준비했구나”라는 생각이 들 만큼 결과물이 달라진다.
 
이 글에서도 정리한 내용들은 사실 거창한 이론이라기보다는, 코딩테스트를 준비하면서 직접 시행착오를 겪고 조금씩 고쳐 온 습관들이다. 앞으로도 문제를 더 풀어 보면서, 실제 면접장에서 코드 리뷰를 어떻게 하는지, 어떤 코드 스타일이 더 좋은 평가를 받는지 경험이 쌓이면, 그때그때 다시 정리해서 공유해 보려고 한다.
 
일단 지금 단계에서는,

• 문제/접근/복잡도 요약 주석
• 핵심 로직 주석
• 함수 분리 + 의미 있는 이름
• 연습 후 2~3분 리팩터링 루틴

이 네 가지를 같이 연습해 보면 좋을 것 같다. 코딩테스트 준비하면서, 단순히 점수만 남기는 게 아니라 “나만의 깨끗한 풀이 코드 레퍼런스”를 쌓아 가는 느낌으로 같이 해보자.

입사 코딩테스트 준비, 여러 언어로 효율적으로 문제 풀기