시뮬레이션) Pro Lv2 [1차] 캐시

Git: https://github.com/Tarte12/CodingTest_KUT/commit/e68fda5151652234e219b0ad8b71960f58579609

1. 부족했던 문법/기초 실수

리스트 원본 변환 문제

for city in cities:
    city = city.lower()

→ 이건 cities 자체가 바뀌지 않음. 새 리스트를 만들어야 한다.

cities = [c.lower() for c in cities]

리스트 인덱싱/삭제 메서드 착각

• list.pop(x)는 인덱스를 받으므로 => 값으로 쓰면 IndexError
• 특정 값을 제거하려면 list.remove(value)

캐시 사이즈 0 처리 누락

• cacheSize=0이면 캐시가 아예 없으므로 항상 미스(+5)
• 특수 케이스로 바로 리턴해야 함

if cacheSize == 0:
    return 5 * len(cities)

2. 설계 방향

잘못된 설계 방향

• LRU를 기록하기 위한 리스트(lru)를 따로 둠
  - 매번 인덱스를 찾고 관리하는 건 불필요하게 복잡해짐
  - 결국 space 하나만 잘 관리하면 LRU가 됨
• 히트/미스 순서가 꼬임
  - 히트인지 판단하기 전에 리스트를 조작해 버려서 조건이 항상 참/거짓이 이상하게 나옴
• 히트 시 순서 갱신 누락
  - LRU 핵심은 “가장 최근 사용을 맨 뒤로 보내는 것”인데, 단순히 time += 1만 하고 넘어가서 LRU가 깨짐

좋은 설계 방향 (리스트 기반 단순 구현)

• space 하나로 “오래된 → 최신” 순서 관리
• 처리 루틴:

if city in space:  # 히트
    time += 1
    space.remove(city)
    space.append(city)  # 맨 뒤로 → 최신
else:  # 미스
    time += 5
    if len(space) == cacheSize:
        space.pop(0)  # 가장 오래된 것 제거
    space.append(city)  # 새로운 것 추가

3. 기타 놓친 부분 (다른 문제에도 반복될 수 있는 실수)

• 특수 케이스 처리
  - 캐시 크기 0처럼, 제약 조건 경계값을 놓치기 쉽다. 문제 조건을 꼼꼼히 읽어야 함
• 자료구조의 의미와 용도
  - pop, remove, append처럼 리스트의 메서드 차이를 제대로 이해하지 못하면 불필요한 디버깅 시간을 낭비한다.
  - LRU 문제는 사실상 큐(FIFO)와 유사하게 굴러가므로 리스트 순서 관리가 핵심
• 문제 요구사항의 본질 파악
  - "LRU 알고리즘"이라는 말에 끌려서 지나치게 복잡한 기록 리스트를 만들었음
  - 사실은 히트 시 재배치, 미스 시 교체라는 단순 규칙만 지키면 됨

✅ 정리

• 기본 문법 실수(리스트 조작 메서드, continue 문법, 리스트 변환) 줄이기
• LRU는 “히트 → 맨 뒤로, 미스 → 오래된 것 제거 후 추가” 규칙만 지키면 됨
• 캐시 사이즈 0 같은 특수 조건을 빠뜨리지 말자
• 앞으로는 “조건 확인 → 시간 가산 → 자료구조 갱신” 순서를 습관적으로 지켜야 한다.