정글 [week5] WIL + React(Component, State, Hooks)

이번 주 목표

이번 주 학습 키워드는 동적 계획법(DP) 과 탐욕 알고리즘(Greedy), 두 가지였다.

처음에는 키워드가 적어서 비교적 쉬운 주차가 될 것이라고 생각했다. 하지만 실제로 공부해 보니 전혀 그렇지 않았다. 오히려 가장 기본적으로 보이지만, 문제에 따라 가장 어렵게 느껴질 수도 있는 개념이라고 생각했다.

저번 주까지는 알고리즘마다 어느 정도 ‘공식처럼 적용할 수 있는 로직’이 있다고 느꼈다면, 이번 주에 배운 개념들은 단순히 외워서 적용하기보다 문제를 보고 스스로 규칙을 찾아야 한다는 점에서 마치 IQ 테스트를 푸는 느낌에 가까웠다.

💡 ### 1. 문제해결 **목표:** 동적 계획법(DP), 탐욕 알고리즘(Greedy) 개념을 설명할 수 있고, 관련 문제를 풀며 풀이 원리를 말할 수 있기 **결과: 50%** DP와 Greedy 둘 다 아주 기본적인 수준에서는 설명할 수 있지만, 아직 제한적인 수준에 머무르고 있다고 느꼈다. 예를 들어 DP는 1차원 배열로 푸는 피보나치나 계단 오르기 같은 문제는 설명할 수 있지만, 그보다 복잡한 문제에서는 상태 정의나 점화식을 스스로 세우는 데 어려움을 느꼈다. Greedy 역시 개념은 말할 수 있지만, 왜 그 선택이 항상 최적해가 되는지까지 깊게 설명하는 수준은 아직 부족하다고 느꼈다. 즉, 개념을 완전히 모르는 것은 아니지만, 문제에 따라 스스로 적용하고 설명하는 힘은 아직 더 길러야 한다고 생각했다. --- ### 2. 설계 **목표:** 문제를 풀기 전에 아이디어, 시간복잡도, 예외 케이스를 먼저 생각하고 구현하기 **결과: 30%** 이번 주에는 설계를 체계적으로 했다고 보기 어려웠다. 아이디어가 어느 정도 떠오르는 문제에서는 적어보기도 했지만, 아예 아이디어가 잘 생각나지 않는 문제에서는 설계 자체를 생략하고 바로 막히는 경우가 있었다. 또한 시간복잡도나 예외 케이스까지 충분히 고민하고 들어가기보다는, 문제를 풀다가 막히거나 다 풀고 난 뒤에 다시 생각하는 경우가 많았다. 즉, 문제를 풀기 전 설계를 하는 습관이 아직 충분히 자리 잡지 않았고, 특히 어려운 문제일수록 더 흐트러졌던 것 같다. --- ### 3. 구현 **목표:** 코드를 짜기 전에 함수 역할 주석과 TODO를 적고 시작하기 **결과: 50%** DP 문제를 풀 때는 TODO를 적어본 적이 있었지만, Greedy 문제를 풀 때는 그렇게 하지 못했다. 특히 습관이 아직 자리 잡지 않아서, 생각나는 문제에서만 적고 그렇지 않은 경우에는 바로 코딩으로 들어갔다. 또 아이디어가 아예 떠오르지 않을 때는 TODO를 적는 것 자체도 하지 못했다. 다만 이번 주를 통해, 앞으로는 막연하게 TODO를 적으려고 하기보다는 **함수 단위로 나누고, 어떤 함수가 필요한지 중심으로 적는 방식**이 더 잘 맞겠다는 기준을 조금 세울 수 있었다. --- ### 4. 품질 **목표:** 변수명을 더 의미 있게 짓고, 읽기 쉬운 코드로 작성하기 **결과: 70%** 이번 주에는 변수명을 조금 더 신경 쓰려고 노력했다. 특히 AI에게 물어보면서 더 의미 있는 변수명을 지으려고 했고, 실제로 그렇게 적용한 적도 있었다. 다만 항상 잘 되었던 것은 아니어서, 여전히 변수명을 대충 지어서 나중에 다시 볼 때 헷갈렸던 적도 있었다. 즉, 이전보다 분명히 신경은 더 쓰게 되었지만, 아직 완전히 자연스럽게 좋은 변수명을 짓는 수준까지는 가지 못한 것 같다. --- ### 5. 유지보수 **목표:** 주석을 남겨서 나중에 봐도 이해할 수 있게 만들기 **결과: 60%** 이번 주에는 주석을 남기려고 꽤 노력했다. 다만 문제를 보자마자 아이디어가 바로 떠오르고 쉽게 느껴졌던 문제들은 주석을 거의 남기지 않았고, 조금 복잡하거나 다시 봤을 때 헷갈릴 수 있을 것 같은 문제들 위주로 적으려고 했다. 특히 변수의 의미를 적는 것이 중요하다고 느꼈고, 실제로 변수명을 대충 지었을 때는 나중에 다시 봐도 헷갈린다는 점을 경험했다. 하지만 아직도 **주석을 정확히 어디에, 어떤 방식으로 달아야 하는지에 대한 감은 완전히 잡히지 않았다.** --- ### 6. 협업 **목표:** 팀원에게 모르는 것을 질문하고 같이 이해하기 **결과: 60%** 이번 주에는 팀원에게 질문한 적이 있었고, 실제로 도움이 되었다. 예를 들어 문제를 어떤 식으로 subproblem으로 나눌 수 있을지 물어본 적이 있었는데, 그 질문이 문제를 보는 데 도움이 되었다. 하지만 여전히 질문하지 못하고 넘어간 경우도 있었다. 그 이유는 단순히 소극적이어서라기보다는, **내가 무엇을 정확히 이해하지 못하고 있는지 스스로 정리하지 못한 상태**였기 때문이다. 그래서 질문을 잘 정리하지 못해 그냥 넘어간 적이 있었다. 다음에는 다 같이 코어타임을 할 때, 막히는 부분을 더 구체적으로 정리해서 질문해보고 싶다고 느꼈다. --- ### 7. 태도 **목표:** 공유학습과 수요 코딩회에 더 적극적으로 참여하기 **결과: 30%** 이번 주에도 Codex가 너무 많은 코드를 작성해줘서, 그 코드를 충분히 이해하지 못한 채 넘어간 부분이 있었다. 실제로 결과물은 있었지만, 그 안의 구조와 흐름을 완전히 이해했다고 말하기는 어려웠다. 그래서 단순히 따라가기보다는, 내가 주도적으로 이해하고 있는지 계속 점검했어야 했다는 아쉬움이 남는다. 즉, 참여는 했지만 **이해를 끝까지 붙잡고 가는 태도** 면에서는 아직 부족했다고 느꼈다. --- ### 8. 비즈니스 이해 **목표:** 기능을 만들 때 왜 필요한 기능인지 한 번 더 생각하기 **결과: 0%** 이번 주에는 이 부분을 거의 생각하지 못했다. 구현 자체를 따라가고 결과물을 만드는 데 집중하느라, 이 기능이 왜 필요한지, 사용자 입장에서는 어떤 의미가 있는지를 생각할 여유가 없었다. 그래서 비즈니스 이해 측면에서는 이번 주 목표를 달성하지 못했다고 느꼈다. --- ### 9. AI 활용 **목표:** 내가 무엇을 모르는지 정확히 파악하고 AI에게 질문하기 **결과: 50%** 이번 주를 돌아보면서, AI를 더 잘 활용하려면 먼저 **내가 무엇이 궁금한지 스스로 더 생각하고 정리해야 한다**는 점을 느꼈다. 무작정 “모르겠다”고 질문하고, 답변을 본 뒤에도 다시 “그래도 모르겠다”고 하는 방식은 학습에 큰 도움이 되지 않는다는 생각이 들었다. 앞으로는 개념이 헷갈리는 건지, 아이디어가 안 떠오르는 건지, 문법이 막히는 건지를 먼저 나누고, 그에 맞게 프롬프트를 짜서 질문해야겠다고 느꼈다. 완전히 잘했다고 보기는 어렵지만, 적어도 이번 주에 이런 문제의식을 가지게 된 점은 의미 있었다고 생각한다. --- ### 10. 학습 민첩성 **목표:** 강의나 해설을 보고 설명할 수 있을 정도로 개념 정리하기 **결과: 20%** 이번 주에는 강의나 해설을 보고 “이제는 내가 설명할 수 있다”고 느낄 정도까지 정리된 개념은 많지 않았다. 해설을 볼 때는 이해된 것처럼 느껴지지만, 막상 다시 설명하거나 혼자 풀어보려고 하면 어려운 경우가 많았다. 즉, 단순히 본 것과 내 것으로 만든 것은 다르다는 점을 다시 느꼈고, 이 부분은 다음 주에 더 보완해야 할 부분이라고 생각했다.

시도한 접근 방식

이번 주에는 지난주에 충분히 하지 못했던 시간 복잡도 고려를 하면서 문제를 풀어보려고 했다.

문제를 보자마자 바로 코드부터 작성하기보다는, 어떤 방식으로 접근해야 하는지와 시간 복잡도가 적절한지를 먼저 생각해 보려고 노력했다.

하지만 문제 난이도가 너무 높아서 혼자 힘으로 흐름이 잡히지 않을 때는, 해당 문제에 대한 해설 영상이 있다면 그것을 보면서 원리를 이해하는 식으로 공부했다. 단순히 정답만 보는 것이 아니라, 왜 그런 방식으로 풀리는지 이해하려고 하면서 접근했다.

문제와 해결 과정

이번 주에 가장 많은 시간을 들인 문제는 DP 문제 ‘평범한 배낭’(백준 12865) 이었다.

백준 12865 평범한 배낭

  # DP - 평범한 배낭 (백준 골드5)
  # 문제 링크: https://www.acmicpc.net/problem/12865
    
  def solve():
      # 1. 입력 받기
      n, k = map(int, input().split())
    
      # 2. dp 테이블 생성: 행(k+1개, 무게 0~k) x 열(n개, 물건 0~n-1)
      # 초기값은 모두 0으로 설정
      dp = [[0] * n for _ in range(k + 1)]
    
      items = []
      for _ in range(n):
          w, v = map(int, input().split())
          items.append((w, v))
    
      fisrt_w, first_v = items[0]
      if fisrt_w <= k:
          dp[fisrt_w][0] = first_v
    
      # 3. 물건을 하나씩 확인 (열을 하나씩 채워나감)
      for baggage in range(1, n):
          current_w, current_v = items[baggage]
    
          # [Case 2] 두 번째 물건부터 처리
          # Step 1: 이전 열(j-1)의 결과를 현재 열(j)로 그대로 복사
          for i in range(k + 1):
              dp[i][baggage] = dp[i][baggage - 1]
    
          # Step 2: 밀어내기 (물건을 넣는 경우)
          for i in range(k + 1):
              # 이전 물건까지의 결과(i)에 현재 물건(current_w)을 더했을 때 한도 내라면
              if i + current_w <= k:
                  # 도착지 칸(i + current_w)에 기존 값과 새 값을 비교하여 더 큰 값 이면 가방에 담고 작으면 가방에 안담고
                  dp[i + current_w][baggage] = max(dp[i + current_w][baggage], dp[i][baggage - 1] + current_v )
    
      # 4. 결과 출력: 마지막 열(n-1)에 담긴 값들 중 최댓값
      # 리스트 컴프리헨션을 사용하여 마지막 열의 값들을 모아 최댓값을 찾습니다.
      result = max(dp[i][n - 1] for i in range(k + 1))
      print(result)
    
  solve()

코드 자체만 보면 비교적 단순해 보일 수 있지만, 실제로는 그 원리를 이해하는 데 많은 시간이 걸렸다.

이 문제를 풀면서 가장 어려웠던 점은 2차원 DP 테이블을 어떤 기준으로 해석해야 하는지 이해하는 것이었다.

내가 이해한 방식으로 설명하자면, 가방에 현재 물건을 넣지 않는 경우에는 이전 열의 값을 그대로 참고하기 때문에 무게를 더하지 않는다. 반면, 현재 물건을 넣는 경우에는 이전 상태에서 현재 물건의 무게를 더한 위치로 이동하면서 가치를 갱신한다.

즉, 이전까지의 결과를 그대로 가져오는 경우와, 현재 물건을 추가해서 새로운 상태를 만드는 경우를 비교하면서 테이블을 채워 나가는 방식이라고 이해했다.

머리로는 어느 정도 이해했지만, 이것을 2차원 표의 흐름으로 완전히 설명하는 것은 아직도 쉽지 않다. 그래도 이 문제를 오래 붙잡고 고민하면서 DP가 단순한 암기 개념이 아니라, 상태를 어떻게 정의하고 전이시키는지 이해하는 과정이라는 것을 느낄 수 있었다.

새롭게 배운 점

이번 주에는 알고리즘뿐 아니라 리액트를 직접 구현해보는 경험도 할 수 있었다.

그 과정에서 Component, useEffect, useState, useMemo와 같은 핵심 개념들이 어떤 역할을 하는지 조금 더 알게 되었다. 단순히 문법만 보는 것이 아니라, 직접 구현해 보면서 왜 이런 개념이 필요한지 생각해 볼 수 있었다는 점이 의미 있었다.

또 이번 주 발표를 들으면서, 어떤 조는 코덱스에 스킬을 적용하고 하네스 기법을 활용한 방식으로 작업을 진행했다는 점이 인상적이었다.

그 모습을 보며 다음 주에는 나도 최소 기능부터 직접 구현해 보면서, AI나 다른 도구에 끌려다니기보다 내가 흐름을 주도하면서 개념을 더 단단히 잡아보고 싶다는 생각이 들었다.

다음 주 계획

다음 주에는 파이썬이 아니라 C 언어로 자료구조를 구현하게 된다.

아직 C 언어를 제대로 다뤄본 적이 없어서 걱정도 되지만, 새로운 언어를 배우는 만큼 기본 개념을 더 탄탄하게 다질 수 있는 기회가 될 것이라고 생각한다. 두려움이 있지만, 그만큼 더 열심히 해봐야겠다는 생각이 들었다.