프로그래머스 Lv. 2를 전부 풀고 난 기념 공부법 돌아보기

6720·2023년 9월 26일

주절주절

목록 보기
3/3

나는 과연 제대로 공부하고 있었을까?

2022년 12월 후반부터 2023년 9월 초반까지 결코 짧은 시간이 아니었고, 무의미하게 보내지도 않았다.

하지만 마음 속 한 켠에 남아 있는 불안함은 과연 이렇게 해서 얻은 성과는 있냐며 자문하고 있다.

정겨운 추억 얘기만 했으니 본격적으로 혼날 시간이다.

이번에는 내 공부법은 자세히 살펴보며 어떤 부분을 가져갈 지, 어떤 부분을 버리고 갈지 반성하는 자리를 가져보겠다.

공부 방법을 점검해보자

하루에 코테에 투자하는 양

시작부터 백준과 프로그래머스를 병행하는 입장에서 둘 중 어떤 사이트도 포기할 수 없었다.

그렇기 때문에 하루에 백준 1문제, 프로그래머스 1문제를 풀어 지금까지 유지하였고, 결국 프로그래머스 Lv. 2 까지 다 풀게 되었다.

백준의 경우, solved.ac에 스트릭이라는 시스템이 도입되어 있기 때문에 이런 꽉 채워진 모습을 봐야 성이 풀리는 내 성격상 반강제적으로 풀게 되었다.

물론 꾸준히 난이도 높은 애들만 풀진 않았다. 도저히 풀고 싶지 않은 날이나 아파서 집중을 못하겠는 날에는 브론즈 문제를 풀기도 했다. 물론 좋은 방법도 아니고 추천할 정도로 떳떳한 방법도 아니다.

하지만 계속 난이도 높은 문제만 풀다가 안풀리는 경우가 다반수라면 가끔은 난이도를 낮춰서 힐링하는 시간을 가지는 것도 좋은 멘탈관리라고 생각한다.

프로그래머스의 경우, 스트릭이라는 기능이 존재하지 않아서 비교적 널널하게 스케줄을 잡아 풀었다. 주말에는 풀지 않는 등의 방법으로 말이다.

옛날에는 이 정도의 양에서 리팩토링하는 시간까지 따졌을 때 2~3시간이 걸렸고, 어쩔때는 더 많이 걸리는 날도 있었다. 거기에 새로운 알고리즘 공부, 깨달은 바가 있으면 벨로그에 게시글을 업로드한 시간까지 따지면 메인 공부보다도 더 많은 시간을 잡아먹었다.

코테는 메인 공부가 되면 안된다는 생각이 머리를 스치자마자 바로 공부 방법을 변경했다.

우선 새로운 문제 푸는 건 백준 하나, 프로그래머스 하나로 유지하되, 리펙토링이나 알고리즘 업로드 일정을 유하게 잡았다.

리펙토링은 하루에 한 사이트당 하나씩으로 잡았고, 알고리즘 업로드는 문제를 푼 5일 내로 업로드하기로 변경했다.

장점

1일 2문제 풀기 자체로만 생각했을 때, 실력 향상에 도움이 된다.

예를 들어서 프로그래머스에서 어렵게 생각해 공부해뒀던 유형을 백준에서 다시 만나 복습하게 되는 경우나, 혹은 그 반대의 상황이 굉장히 많이 나왔기 때문이다.

단점

지금은 프로그래머스 Lv. 2를 다 푼 입장이고, 아직 Lv. 3를 풀 생각이 없어서 스케줄이 널널한 편이지만, 1일에 2문제 풀기는 생각보다 피로와 지루함을 준다.

내 코딩 공부의 시작은 코딩테스트 풀기였는데, 처음부터 어려운 문제가 나오거나, 알고리즘 공부를 업로드 하는 등, 해야할 일이 예정보다 많아지게 되면 피로감이 생겼고,

이 과정이 9개월 간 이어졌기 때문에 지루함도 생겼다.

앞으로의 개선점

다음에서는 지금까지 얘기했던 부분에서 챙길 것과 버릴 것을 생각해보자.

[챙길 것]

  • 코테는 메인 공부가 되면 안된다.
  • 하루에 한 문제는 풀어야 한다.
  • 알고리즘 공부를 업로드한다.

[버릴 것]

  • 안 풀리거나 바쁜 날에는 브론즈 문제를 풀기도 했다
    → 문제 풀이보단 스트릭에 강박적이다.
  • 알고리즘 공부를 “벨로그”에 업로드한다.
    → 벨로그와 병행해야 한다는 부분에 스트레스 받는다.
  • 코딩테스트 공부 자체를 공부 처음에 진행한다.
    → 어쩔때는 코테만 하다가 끝남.

[최종 개선]

  • 백준 한 문제 고정
    • 쉬고 싶은 날에는 실버 V 이상으로 풀기
  • 모르는 알고리즘 공부는 개인적으로 작성.
    • 앞으로의 업로드의 경우는 이렇게 공부 방식을 점검하거나, 일주일 동안 뭐 배웠는지 등으로 정리해야 할 듯.
    • 개인적으로 작성하는 것은 노션 이용 혹은 옵시디언 고려
    • 알고리즘 공부는 되도록 평일보다는 주말에 한 번에 모아서 공부하기
      • 주말에도 방금 코테를 풀고 온 컨디션을 유지하기 위해 문제 푼 과정 메모하기
  • 코딩테스트는 메인 공부 중간 중간에 하도록 하기
    • 마치 영어 단어 외우듯 접근해야 할 것 같음.
      • 1차 시도에 풀지 못했으면 틀린 이유, 잘 모르겠으면 접근 방법을 자세히 작성
      • 2차 시도는 메인 공부가 어느 정도 진행된 후 진행
      • 2차 시도에서는 1차 시도에서 작성한 메모 활용 후 다시 시도
      • 한 문제에 투자하는 시간이 길어질 경우(한 문제 당 1시간 30분을 지나갈 경우), GG 치기

코테 문제를 기록한 페이지 양식

노션에는 각 문제 당 하나의 페이지를 만들어 데이터베이스에 넣어서 관리했다. 이렇게 여러 페이지를 모을 수 있는 노션의 특징이 정리할 때 유리하게 작동하는 것 같다.

  • 문제에서 복사해 오는 것
    • 문제 설명
    • 문제 조건
    • 입출력 & 입출력 풀이
    • 메모리 제한, 시간 제한에 대한 컷트라인
  • 직접 문제를 풀 때 작성하는 것
    • 문제 접근: 문제를 풀면서 어떤 흐름으로 문제를 읽고 이해했는지에 대한 생각의 흐름을 작성하는 칸
    • 문제 코드: 문제를 푼 다음에 나온 코드
      • 실패했을 경우에는 실패한 코드와 그 이유를 간단하게 서술
      • 만약 해당 코드를 어딘가에서 참고했다면 참고 링크도 아래에 참조
      • 이해가 안가거나 나중에 봤을 때 풀이과정을 못보곤 이해를 못할 것 같을 때를 대비해 코드 흐름 설명 (되도록 주석을 안쓰려고 노력함)
      • 새로 배운 문법이 있다면 문법 서술
    • 한줄평: 문제를 풀고 느낀점 서술
      • 간단하게 이런 접근 좋았는데 아쉬웠고 이런 걸로 더 풀어봤을 좋았을 텐데 등의 피드백을 남김
      • 리팩토링을 해야할지 말아야할지에 대한 여부 작성
    • 리팩토링 코드
      • 리팩토링 과정에서 나온 코드 작성
      • 리팩토링에 대한 풀이, 왜 이런 방식으로 리팩토링 했는지

굉장히 항목이 많아보이지만 생각보다 별로 많지 않다.

문제 풀이에 대한 핵심은 나중에 까먹었을 미래의 나를 위해 친절하게 1부터 설명하는 것이다.

주석을 사용하지 말라는 피드백을 들은 이후부터는 이렇게 글로 남기는 연습을 하고 있다.

리팩토링을 해야할 때 이해가 되지 않을 때, 혹은 다시 찾아와서 어떤 코드였는지 번거롭게 다시 읽지 않도록 할 때, 좋은 참고서가 되도록 작성하는 것이 목표였고, 지금도 계속 이렇게 하고 있다.

장점

위에서 언급한 것처럼 미래의 나를 위해 설명하는 컨셉이라서 나중에 글을 볼 때 문제의 구성이 어떤 식인지 글만 읽고도 파악할 수 있다.

단점(?)

구성에 대한 단점은 아니지만, 가끔 문제 접근이나 한줄평을 쓸 때 소홀히 작성하는 부분이 없지 않다.

앞으로의 개선점

문제를 접근할 때 문제 풀기 전에 했던 생각을 꼼꼼이 적고, 한줄평에 미래의 내가 리팩토링할 때 어디를 봐야하는지 알 수 있도록 알리도록 습관을 들여야겠다.

끝까지 포기하지 않고 풀었나요?

보통 새롭게 문제를 풀 때는 1시간 정도의 시간이 소요된다. 하지만 풀어보지 못한 유형이나 새로운 개념에 대한 문제가 나오면 2-3시간을 잡아도 못 풀 때가 많았다. 그럴때는 항상 다른 사람은 어떻게 풀었나 검색해서 풀이과정을 찾아봤다.

물론 모르는 부분을 확인한거라면 상관없지만 조금만 생각하면 알 수 있던 문제나 머리 속으로 상상한 문제 풀이는 맞았지만 그걸 코드로 구현하지 못한 문제도 다반수여서 그럴때마다 '조금만 더 생각해볼껄' 후회하기도 하였다.

그렇다고 하나의 포스팅만 찾아보지는 않는다. 내가 풀고 있는 언어와 맞는 포스팅을 탭에 5개 이상은 올려두고 이 사람과 이 사람의 풀이는 어디가 다른지, 문제 접근은 어떻게 다른지, 이 사람들이 참고한 다른 포스팅은 무엇인지 찾으려고 했다.

다른 사람의 풀이를 찾아볼 때는 반드시 내 것으로 만들어야 한다는 의무를 가지고 포스팅을 확인해봤다. 물론 정말 이해가 안되는 문제 유형(이를테면 DP, DP, DP..)은 여러번 풀어보고 있다.

장점

  • 다른 사람이 어떻게 풀었는지 알 수 있다.
    - 다른 사람이 어떻게 풀었는지 알 수 있다는 것은 곧 보편적인 풀이 방식을 알 수 있다.
    - 문제 접근 방식이 풀어져있는 포스팅의 경우는 해당 알고리즘에 대한 접근 공식을 만들 수 있도록 도와준다.

단점

  • 많이 생각하지 않고 문제를 푸는 경우가 많다.
  • 모르는 문제가 나와도 다른 사람 풀이 찾아보면 된다는 생각으로 임하게 된다.

앞으로의 개선점

[챙길 것]

  • 모르는 문제를 확인하는 것
    - 모르는 것을 확인하는 건 공부하는 과정에서 자연스러운 부분이므로 이 부분까지 버릴 생각은 없다.

[버릴 것]

  • 문제를 가볍게 여겨 풀이를 쉽게 확인하는 것
  • 조금만 생각하면 풀 수 있는 문제까지 확인하는 것

[최종 개선]

  • 모든 문제
    1. 2시간은 잡고 풀어보기
    2. 되도록 오픈북 금지
    3. 2시간을 초과하면 그때부터는 다른 사람 풀이 참고
  • 알고리즘을 알아야 풀 수 있는 문제
    1. 알고리즘에 대한 공부 진행
    2. 문제 한 번 풀어보기
    3. 그래도 안풀리면 다른 사람 풀이 참고
  • 조금 더 생각해봐야 풀 수 있는 문제
    1. 만약 2시간이 넘을 것 같다면 주말로 킵하고 다른 문제 풀기
    2. 2시간 안에는 해결할 수 있다면 더 생각하고 풀어보기

결론

앞으로의 계획, 마음가짐

백준 solved.ac

다음 목표는 백준 상위 100문제를 전부 골드 이상으로 덮는 것이다.

원래는 solved.ac 등급을 올릴까 생각했지만 해당 문제들이 너무 어려워(;;) 더 알고리즘을 공부해야 겠다는 생각을 했기 때문에 우선은 나중으로 미뤄뒀다.

목표치곤 의외로 빨리 끝날 것 같지만 하루에 한 문제만 푸는 상황에서는 시간이 꽤 걸리는 목표이다. 대신 이와 동시에 앞으로 남아있는 백준 알고리즘 리팩토링을 부지런히 해서 문제푸는 날과 리팩토링하는 날의 주기를 한 달로 맞춰야 겠다.

profile
뭐라도 하자

0개의 댓글