코딩 테스트 풀이 절차와 컴파일 환경 맞추기
분석 70%·구현 30%, 그리고 -std=c++17
문제를 읽자마자 코드를 치던 순서를 바꿨다. 분석에 70%를 쓰는 4단계 절차와, 로컬에서 통과한 코드가 채점 서버에서 컴파일 에러가 나는 걸 막는 -std=c++17 환경 세팅.
C++ 코딩테스트 강의를 시작하며 가장 크게 바뀐 건 문제를 대하는 순서였다. 읽자마자 코드를 치던 습관을 버리고 분석에 70%, 구현에 30%를 쓰는 절차로 옮기는 것. 이 글에서는 그 문제 풀이 전략과, 그 전에 반드시 맞춰야 하는 컴파일 환경 세팅을 이야기하려 한다. 트러블슈팅이랄 게 없는 대신, “로컬에서 돌아가는 코드가 시험 서버에서 깨지는” 함정 하나를 미리 막는 이야기가 들어간다.
강의가 지향하는 방향
첫 강의에서 가장 먼저 짚은 건 목표 설정이었다. 이 강의는 모든 문제를 푸는 게 목표가 아니라 코딩 테스트 합격이 목표다. 그래서 빈출 유형 중심으로 학습하고, 출제 확률이 낮은 고난도 수학 알고리즘은 아예 다루지 않는다. 대신 빈출 개념은 단순 풀이에 그치지 않고 면접에서 답할 수 있는 수준까지 깊이 들어간다. 접근 순서도 개념 → 사고 과정 → 코드 순이다.
특히 해설 코드를 보기 전에 아이디어를 어떻게 도출하는지를 강조했다. 예를 들어 괄호 짝 맞추기 문제라면, 정답 코드가 아니라 “왜 스택으로 생각하게 되는가”의 사고 과정을 먼저 설명하는 식이다.
전체 커리큘럼은 네 챕터로 구성된다.
- 챕터 1 — 코딩 테스트 이해: 시험 개념, 환경 설정
- 챕터 2 — 기초 다지기: 시간 복잡도, 공간 복잡도, 필수 문법, STL(C++ 표준 라이브러리), 효율적 구현
- 챕터 3 — 빈출 알고리즘: 재귀, 배열, 정렬, 스택/큐, 트리/그래프, 백트래킹
- 챕터 4 — 고급 알고리즘: 최단 경로(다익스트라, 벨만포드), 해시, 동적 계획법, 그리디
개발 환경 설정
환경 세팅은 Visual Studio Community를 설치하고 “C++을 사용한 데스크톱 개발” 워크로드를 선택하는 것부터 시작한다. 빈 프로젝트를 만들어 프로젝트/솔루션 이름을 지정하고, 코드를 작성한 뒤 CTRL + F7로 컴파일, F5로 실행한다. 코드는 프로젝트 단위로 관리한다.
여기서 중요한 포인트가 하나 있었다. 시험 환경과 컴파일러 버전을 동일하게 맞춰야 한다는 것. 프로그래머스 기준 컴파일 옵션은 다음과 같다.
1
-std=c++17
Visual Studio에서는 이렇게 맞춘다.
1
프로젝트 → 속성 → C/C++ → 언어 → ISO C++17
버전이 다르면 내 PC에서는 정답인 코드가 시험 서버에서는 컴파일 에러가 날 수 있다. 로컬에서 잘 돌아간다고 안심하면 안 되는 이유다.
프로그래머스 사이트 구조도 훑었다. 주요 메뉴는 모든 문제, 입문 문제, 알고리즘 고득점 Kit, 기업 기출이 있고, 문제는 상태·난이도·사용 언어로 필터링할 수 있다. 난이도는 LV.3 이하를 추천받았다.
코딩 테스트라는 시험의 본질
코딩 테스트는 제한 시간이 있고, 효율성을 요구하며, 정답과 성능 둘 다 만족해야 하는 시험이다. 필요한 역량으로는 요구사항을 정확히 파악하는 것, 효율적인 코드를 작성하는 것, 논리적으로 설계하는 것, 예외를 처리하는 것 네 가지를 꼽았다.
목표 설정 방법도 인상적이었다. “한 달에 100문제” 같은 추상적 목표 대신, 내 취약 유형을 분석하고 데이터 기반으로 계획을 세워 사이클을 반복하라는 것이다.
1
2
3
4
5
학습 데이터 분석
→ 계획 수립
→ 공부 진행
→ 블로그 정리
→ 다시 분석
지금 쓰고 있는 이 기록도 저 사이클의 “블로그 정리” 단계인 셈이다.
문제 풀이 전략 — 분석 70%, 구현 30%
이 강의에서 가장 크게 가져간 건 문제 풀이 과정 자체다.
1
2
3
4
1. 문제 요약
2. 입출력 분석
3. 전략 설계
4. 구현
시간 배분은 분석에 70%, 구현에 30%. 문제를 읽자마자 코드부터 치는 게 아니라, 분석에 대부분의 시간을 쓰라는 얘기다.
실제 예시로 오픈채팅방 문제를 단계별로 분석했다. 먼저 문제를 3문장으로 요약하고 특이사항과 제한사항을 정리한다. 다음으로 입출력 예시를 따라가며 흐름을 확인하고 잘못 이해한 부분을 바로잡는다. 전략은 논리 수준에서 설계하고, 바로 코드를 작성하는 건 금지다. 이후 추가 테스트를 만들어 예외 케이스와 반례를 확인한다. 마지막으로 시간 초과 가능성을 따진다 — 이 문제는 record가 최대 10만 개라 단순하게 짜면 O(N²)(입력이 커질수록 연산량이 제곱으로 늘어나는 구조)이 되므로, 적절한 자료구조를 써야 한다는 결론이 나온다.
채점 방식도 알아둘 필요가 있다. 프로그래머스는 2단계로 채점한다. 정확성 테스트는 10초 이내에 정답이 일치하는지를 보고, 효율성 테스트는 시간 복잡도 기준을 통과하는지를 평균 수행 시간 기반으로 본다.
핵심 깨달음
- 입출력 예를 통과했다고 정답이 아니다.
- 시간 초과는 설계 문제다.
- 구현 실패는 전략 문제다.
핵심 요약 — 코딩 테스트는 정답과 성능을 둘 다 요구하는 시험이며, 문제를 읽자마자 코드를 치는 게 아니라 분석(요약→입출력→전략 설계)에 70%의 시간을 써야 한다. 컴파일 환경도 시험 서버(-std=c++17)와 동일하게 맞춰야 로컬 정답이 서버에서 깨지지 않는다.