코테 스터디 0주차 [효율적으로 코딩 테스트 공부하기]

※ 글 최초 작성일자 : 2024. 10. 02

※ 글 수정일자 : 2025. 03. 04

수정된 부분 : c++책 표지 → 파이썬책 표지, 그 외에 없음

수정한 이유 : LinkedIn 스터디그룹 활동을 위함

 

코테 스터디에서 진행하는 책, 출처: 교보문고

혼자서 실력은 크게 늘지 않고, 적적하게 백준의 낮은 난이도 문제만 전전 긍긍하던 중

우리가 수학 문제를 풀 때 접근법이 있는 것처럼

코테 문제도 분명 접근법과 이상적인 풀이 방법이 있을 것이라 생각했고

여러 후보 중 하나를 골라 [코딩테스트 합격자 되기 - 파이썬 편]을 구매하게 되었다.

 

혼자 책으로 독학을 하던 중 책 저자님이

코딩 테스트 합격자 되기 - C++편 으로 스터디원을 모집하셔서 지원하게 되었다. (24.10.02 기준)

(개념을 정리할 수 있는 기회가 찾아와서 정말 기쁘다!)

나는 파이썬으로 코테를 준비하고 있으나, 저자님이 강의의 기본 언어는 C++이지만

대부분 알고리즘 개념이므로 다른 언어로 공부해도 크게 지장이 없다고 하셨다!

(사실 학부생 때 객체지향 프로그래밍으로 C++을 수강한 적이 있어서 강의를 보면 반가울 것 같음)

25.03.04 기준으로 파이썬 편 강의 수강하면서 기존 글 내용 복습 및 수정 예정

 

강의는 인프런에서 수강하고, 스터디의 커리큘럼에 따라 매 주차 강의를 수강하고

카페에 글을 정리해서 작성하는 형식으로 스터디는 진행된다. (질문은 카페 질문 게시판 활용)

 

1주 차 강의[시간 복잡도]를 수강하기 전에

0주 차 강의 [효율적으로 코딩 테스트 공부하기]에 대해 수강하고 정리한 내용과 느낀 점을 정리해보려 한다.

나는 기존에 문제를 보면 바로 vs code에서 구현하고, 에러가 있으면 그 코드를 다시 고치는 방법으로 코테 문제를 풀었다.

나 스스로도 느끼기에 어디선가 되게 비효율적이라고 느낀 접근법이었으므로

이번 기회에 길더라도 확실히 효율적인 공부법을 정리했다.

 

 

 

[효율적으로 코딩 테스트 공부하기 정리]

• 타인의 풀이를 보는 공부 법
  • 알고리즘이란 시간을 가지고 지겹도록 생각해야 하는 학문
  • 이러한 사고 과정에서 깨달음도 얻고 구현능력 향상까지 이어지는 경우가 많음
    • 하지만 대부분의 수험생들은 시간이 부족함...
    • 그렇다고 타인의 코드를 무조건 카피는 x
  • [1] 아무리 바빠도 최소한 30분~1시간 정도 고민해야 함
    • 바로 코드 카피를 하게 되면 내가 무엇을 모르는지 알 수가 없다
    • 고민하지 않으면 공부의 의미가 없음
  • [2] 그래도 답이 나오지 않을 경우, 답안 코드를 본다
    • 답안 코드와 내가 고민했던 부분들 비교
    • 답안 코드에서 내가 해결하지 못한 부분을 해결한 코드를 명확히 정리해야 함
    • 답안 코드에서 사용한 알고리즘에 대한 힌트를 문제 어느 부분에서 얻을 수 있는지 분석해야 함
    • 코테 문제들은 패턴화가 되어있음. 문제가 묻고자 하는 바를 인지하는 과정을 학습을 통해 익숙해져야
      • 문제를 보자마자 아이디어가 떠오를 수 있게 하는 힘을 기르기 위함
    • 2주 정도 후에 다시 구현 (적어도 일주일)
      • 답안을 본 상태이므로, 텀을 가지고 구현하는 게 좋음
  • 정리 예시
    • 문제 입력값이 100만인데, O(N^2) 알고리즘으로 접근해서 TLE 발생
      • 정답 코드는 unordered_map을 활용해서 O(N)으로 개선함
      • -> 각 숫자를 unordered_map의 키로 활용
    • 깨달은 점
      • 다음부터는 입력값을 꼭 확인해서 문제에서 요구하는 시간복잡도를 충족시키자!
      • 자료구조에 의해서도 시간 복잡도가 영향을 받을 수 있음(자료구조에 맞게 구현하므로)

 

• 아는 것만 공부하지 말자(7 : 3)
  • 당연한 건데 지키지 못하는 사람이 꽤 많음
  • 가장 피해야 하는 공부법!
  • 내가 알지 못하는 것은 불편함... 몰라도 되는 것 같은 착각을 하게 됨
  • 아는 것만 공부하면 얻는 것은 자신감뿐...
  • 비율을 모르는 부분 7, 아는 부분 3으로 지킬 것
  • 정리할 때 단순기록(복붙) 대신 나만의 용어로 정리
• 알고 있는 부분(30%)
  • 기존 지식을 활용한 문제 풀이
  • 기존에 틀렸던 부분 복습
• 모르는 부분(70%)
  • 새로운 개념 학습 및 문제 풀이
  • 기존에 많이 틀렸던 알고리즘 문제 풀이
  • 해결하지 못한 부분은 명확히 정리
• 단순 기록 대신 나만의 용어로 정리
  • 나열식 정리는 타자연습과 다를 바 없음 (자기만족 + 머리에 남은 것 없이 텅텅)
  • 개념을 머릿속에서 끝까지 이해한 후에, 완성된 문장으로 정리
  • 이건 뭘까.,,? 이런 형식이면 정리하는 의미 x
• 정리 예시
  • 위키백과 같은 곳에서 엄청 장문으로 설명된 내용을 나만의 언어로 변환
  • 정렬
    • 사용자가 정의한 기준대로, 데이터를 나열하는 것
    • -> 이진탐색 사용가능
  • 시간복잡도
    • 바교정렬 : O(NlogN)
    • 비-비교 정렬 : O(N)까지 가능
  • 예시 코드
    • //something

 

• 테스트 케이스 설계 하는 법(기본 케이스)
  • 문제에서 설명한 "기본 동작"이 제대로 동작하는지 확인하는 케이스
  • 문제 : 두 정수를 입력받아 값을 반환하라.
    • 입력 : a=2, b=3
    • 기대 출력 : 5
    • 테스트 케이스 : assert sum[2, 3] == 5
  • 문제 : 주어진 문자열을 뒤집어 반환하라.
    • 입력 : "hello"
    • 기대 출력 : "olleh"
    • 테스트 케이스 : assert reverse ("hello") == "olleh"

 

• 테스트 케이스 설계 하는 법(경계 값)
  • 입력값의 양 끝값을 테스트함
  • 문제 : 주어진 양의 정수의 제곱근을 반환하라. 정수 부분만 반환한다.
    • 입력 범위 : 1에서 10^6까지
    • 최소값 입력 : 1
    • 테스트 : assert sqrt(1) == 1
    • 최대값 입력 : 10^6
    • 테스트 : assert sqrt (10^6) == 1000
  • 문제 : 정수 배열과 타겟 정수가 주어졌을 때, 타겟의 인덱스를 반환하라, 없으면 -1을 반환
    • 입력 : 배열 [2,3,5,7,11], 타켓 3
    • 경계값 테스트 케이스 
      • 배열의 첫 요소 : 2
      • 테스트 : assert find_index([2, 3, 5, 7, 11], 2) == 0
      • 배열의 마지막 요소 : 11
      • 테스트 : assert find_index([2, 3, 5, 7, 11], 11) == 4

 

• 테스트 케이스 설계 하는 법(에지 케이스)
  • 예상치 못한 입력값이나 특수한 조건을 체크
  • 문제 : 주어진 정수가 소수인지 아닌지를 판별하라.
    • 에지 케이스(이것도 되나? 하고 테스트하는 거)
      • 음수 입력
      • 테스트 : assert is_prime(-1) == False
      • 입력 : 0 (숫자 체크할 때 0 같은 거 꼭 넣어봄)
      • 0은 소수가 아닙니다.
      • 테스트 : assert is_prime(0) == False
      • 입력: 1
      • 1은 소수가 아닙니다.
      • 테스트 : assert is_prime(1) == False

 

• 의사코드 작성하기
  • 구현하기 전에 비 프로그래밍 언어로 동작을 나열하는 것
  • 장점
    • 구현 전 예외 사항을 충분히 고려할 수 있음
    • 구현보다 시간이 적게 걸림
    • 문제점 발견 시 수정이 쉬움

 

• ★ 의사코드 설계하기(문제분석 후 바로 구현시 문제점)
  • [문제 분석]----------->[구현]
  • 바로 구현 시 아쉬운 점
    • 바로 구현 자체가 쉽지 않음. 중간 정리하는 게 없기 때문.
    • 구현 후, 문제 수정은 시간이 오래 걸림 (프로그래밍 언어의 문법까지 고려해서 수정해야 하므로)
    • 문제가 있어도 확인이 쉽지 않음
    • 흐름이 한눈에 보이지 않음(코드가 기니까. 한눈에 잘 들어오지 않음)
  • [문제 분석]--------->[의사코드 작성] --------->[구현]
  • 보완된 점
    • 코드를 바로 구현하지 않고, 자유롭게 설계 후 구현
    • 의사코드 작성 시 확인되는 문제는 수정이 쉬움(프로그래밍 언어가 아니므로)
    • 의사코드는 흐름을 한눈에 확인 가능
    • 전체적인 구조를 잡고 구현하면 코드 품질이 좋아짐

 

• ★ 의사코드 설계하기(의사코드 작성법)
  • 일반인도 이해할 정도의 논리 흐름으로 작성(세부사항까진 x. 동작의 흐름 정도만)
  • 추후 의사 코드 대로 구현하는 경우가 많음
  • 프로그래밍 문법 사용 지양해야 함
    • 의사 코드가 지저분해지고, 고민이 많아지기 때문
    • 의사 코드 목적을 벗어나서 내 관점이 구현 관점으로 변하기 때문

 

• 의사코드 설계하기(잘못된 예시 vs 잘된 예시)
  • Bad Case
    • 변수 A를 DataBase에 저장
    • 포인터 변수 P에 컨테이너의 주소값 저장
  • Good Case(동작 중심으로 작성)
    1. 사용자의 정보를 저장한다
       • 사용자의 이름과 나이를 수집한다.
       • 수집한 정보를 기록한다.
    2. 제품 목록을 업데이트한다
       • 새로운 제품 정보를 확인한다.
       • 제품 목록에 새 제품을 추가한다.

 

• 의사코드 설계하기(예시 - 알고리즘 문제 1)
  • 문제 : "정수 배열이 주어지면, 모든 원소의 합을 구하고, 이를 출력하는 프로그램을 작성하시오."
    1. 숫자로 이루어진 리스트를 준비한다.
    2. 모든 숫자의 합을 계산한다 (계산은 어떻게?)
       • 합을 저장할 곳을 마련한다.
       • 리스트의 각 숫자를 차례대로 합에 더한다.
    3. 계산된 합을 출력한다.

 

• 의사코드 설계하기(예시 - 알고리즘 문제 2)
  • 문제 : "사용자가 입력한 두 수를 비교하여 더 큰 수를 출력하는 프로그램을 작성하시오."
    1. 사용자로부터 두 개의 숫자를 입력받는다.
    2. 두 숫자를 비교한다(어떻게?)
       • 만약 첫 번째 숫자가 두 번째 숫자보다 크면, 첫 번째 숫자를 선택한다.
       • 그렇지 않으면, 두 번째 숫자를 선택한다.
    3. 선택된 숫자를 출력한다.

 

• 의사코드 설계하기(예시 - 알고리즘 문제 3)
  • 문제 : "리스트에 있는 숫자들 중 가장 자주 등장하는 숫자를 찾아 출력하고, 그 숫자가 몇 번 등장했는지도 출력하는 프로그램을 작성하시오."
    1. 숫자로 이루어진 리스트를 준비한다.
    2. 각 숫자가 몇 번 등장하는지 세어서 기록한다.
       • 숫자별로 등장 횟수를 저장할 공간을 만든다.
       • 리스트의 각 숫자에 대해, 해당 숫자의 등장 횟수를 1 증가시킨다.
    3. 가장 많이 등장한 숫자를 찾는다.
       • 가장 많이 등장한 숫자를 기록한다.
       • 모든 숫자의 등장 횟수를 확인하면서, 가장 높은 등장 횟수를 갖는 숫자를 찾는다.
    4. 가장 많이 등장한 숫자와 그 등장 횟수를 출력한다.

 

• ★ 의사 코드 설계단계에서 구현으로 넘어갈 때 TIP!
  • 의사 코드를 점점 구체화하면서 구현하는 게 Best
  • 한 줄 구현하고 한 줄 구현하고 하는 방식도 ㄱㅊ
  • 구현 전 의사코드 설계 단계에서 테스트 케이스 고민해 보는 게 좋다
    • 전체적인 관점에서 문제를 바라보기 때문에
    • 구현단계에서보다 의사코드 설계단계에서 더 나은 테스트케이스를 만들 확률이 높다!
  • 양식이 있는 게 아니라, 내 생각을 정리해 본다는 관점에서 의사코드 설계
  • 가장 나쁜 습관은?
    • 문제를 보고 대충 읽고, 구현을 하고 틀리면 수정한다
    • 이러면 망한다. 쉬운 문제는 풀 수 있을지 몰라도... 공부할 때 좋은 습관을 들어놔야 한다.
  •  어느 문제가 와도 풀 수 있는 프로세스를 충분히 익혀야 한다. 문제 분석하는 것도 공부해야 하고.
  • 문제 분석하고 나서 의사코드를 설계하는 게 익숙해질 때까지 충분히 연습이 필요함
    • 이 두 단계가 구현단계보다 훨씬 중요함
    • 이것만 되어도 구현단계는 금방 할 수 있음
    • 이 단계에 많은 시간을 투자해야겠다는 마인드를 가지고 문제를 공부해야 실력이 향상된다!

 

 

---

 

 

▶ 강의를 수강하고 느낀 점

글 초반에 작성한 것처럼 나는 코딩 테스트 문제를 풀 때

문제를 읽고 나서 머릿속으로 '이러한 과정으로 풀면 풀리겠는데?'라고 생각한 뒤에

바로 코드를 작성하고 run 시킨 뒤에 오류가 없으면 제출, 오류가 있으면 틀린 부분 탐색 후 수정하는 방식을 고집했다.

근데 이러한 습관이 가장 나쁜 습관이였다니....

 

그나마 다행인 점은 어려운 코테 문제를 풀고싶어도 이러한 방식에 벽을 느껴서

책을 구매하고, 코테 스터디를 참여해서 강의를 들을 수 있다는 점이다.

무엇이 문제인지 인지했으니, 나쁜 습관은 도려내고 좋은 습관을 정착시키면 된다.

거의 스킵하는 부분없이 효율적으로 공부하는 법을 장문으로 정리를 했으니

앞으로 이 글을 가이드라인 삼아 남은 강의를 수강하면서 문제를 풀어볼 계획이다.

 

같은 시간을 공부하는데 쓰더라도 효율적으로 쓰는게 무조건, 무조건 좋다고 생각한다.

그 동안 나쁜습관으로 날린 나의 시간들... 아디오스