문제풀이 실력은 정답 코드를 많이 읽는 것보다 문제를 작은 단계로 나누고 실패 원인을 기록할 때 늘어납니다. 처음부터 최적 알고리즘을 떠올리려고 멈추기보다 작은 입력에서 동작하는 단순한 풀이를 먼저 만드세요.
[목차]
문제를 읽고 네 줄로 정리합니다
- 입력: 무엇이 몇 개 들어오는가?
- 출력: 정확히 어떤 값을 요구하는가?
- 제약: 입력 최대 크기와 값의 범위는?
- 예외: 빈 경우, 중복, 음수, 최대·최솟값은?
예제를 손으로 계산해 입력이 결과로 변하는 과정을 설명할 수 없다면 아직 구현을 시작하지 않는 편이 좋습니다.
완전 탐색부터 기준 답안을 만듭니다
작은 입력에서 확실히 맞는 느린 풀이를 만들면 최적화한 코드와 결과를 비교할 수 있습니다. 입력 제한이 작다면 완전 탐색 자체가 정답일 수도 있습니다. 제약을 보지 않고 무조건 복잡한 자료구조를 쓰지 마세요.
구현은 함수로 나눕니다
def solve(values):
# 핵심 로직만 작성
return result
def test():
assert solve([1, 2, 3]) == expected
assert solve([]) == empty_expected
입출력 처리와 핵심 로직을 분리하면 작은 입력을 직접 넣어 테스트하기 쉽습니다.
테스트 케이스를 직접 만듭니다
- 원소가 0개 또는 1개인 경우
- 모든 값이 같은 경우
- 이미 정렬됐거나 역순인 경우
- 최대·최소 범위의 값
- 정답이 여러 경로로 만들어지는 경우
시간복잡도는 병목을 찾는 도구
입력이 100,000개인데 모든 쌍을 비교하는 O(n²) 풀이라면 연산량이 지나치게 커질 수 있습니다. 중복 조회를 set이나 dict로 바꾸거나, 정렬 후 한 번 순회하는 방법을 검토합니다. 단, Big O가 더 좋아도 작은 입력에서는 구현이 단순한 풀이가 적합할 수 있습니다.
오답 노트에는 원인만 기록합니다
- 문제 조건을 놓침
- 자료구조 선택이 부적절함
- 인덱스·경계값 오류
- 복잡도 초과
- 언어 문법이나 API 오해
정답 코드를 그대로 보관하기보다 다음에 같은 유형을 만났을 때 확인할 한 문장 규칙을 적습니다. 예: “최단 간선 수 문제는 먼저 BFS 가능 여부를 확인한다.”
60분 학습 루틴
- 10분: 조건과 예제 분석
- 20분: 단순 풀이 구현
- 15분: 실패 케이스와 복잡도 개선
- 10분: 다른 풀이 비교
- 5분: 오답 원인 기록
공식 참고자료
관련 글
내용 검토 및 업데이트: 2026년 8월 27일
