TIL. Aug 8, 2026

오늘 한 내용

문제를 보면서 예전에 풀었던 CPU 스케줄링 문제가 연상됐다. CPU 스케줄링은 현재 들어온 작업만 보고 결정하면 최적의 결과를 만들기 어렵고, 앞으로 어떤 작업이 들어올지까지 알아야 한다.

LeetCode 3302도 현재 인덱스에서 문자를 고를 때 뒤에 어떤 문자들이 남아 있는지를 알아야 했다. 실제 배열은 한 번에 주어지므로 미래를 기다릴 필요는 없지만, 인덱스 포인터의 시점에서는 뒤쪽 정보를 미리 알고 있어야 한다.

그래서 word1을 뒤에서부터 확인하면서 각 위치 이후에 word2의 문자를 얼마나 맞출 수 있는지 계산해뒀다. 앞에서는 사전순으로 가장 앞선 인덱스를 고르되, 선택 이후에 남은 문자를 모두 맞출 수 있을 때만 문자 변경 기회를 사용했다.

특별히 새로운 알고리즘을 배웠다기보다는, 나중에 필요한 정보를 미리 만들어두면 현재의 그리디 선택을 단순하게 만들 수 있다는 점을 다시 확인했다. 이런 식으로 뒤에서 계산한 정보를 앞에서 사용하는 문제는 풀이가 꽤 릿코드스럽게 느껴졌다.

Stack Day를 처음에는 매일 해야 할 일을 관리하는 앱처럼 만들고 있었다. 구현을 진행하면서 기능은 하나씩 늘어나는데, 정작 이 앱이 어떤 문제를 해결하는지 나 자신도 명확하게 설명하기 어려워졌다.

리마인더나 투 두 앱은 아직 하지 않은 일을 보여주고 관리한다. 내가 만들고 싶은 앱은 사용자가 실제로 반복한 행동을 기록하고, 그 기록이 얼마나 이어졌는지를 보여주는 습관 앱에 가까웠다. 두 앱은 비슷해 보이지만 관리해야 하는 데이터가 다르다.

그래서 기존 구현을 이어서 수정하는 대신, 컨셉부터 다시 정리했다.

Stack Day는 할 일을 관리하는 것이 아니라, 실제로 이어온 습관을 기록하고 관리한다.

처음 MVP에서는 매일 수행 여부를 기록하는 습관만 지원하기로 했다. 로그인, 서버 동기화, 알림 같은 기능은 일단 제외하고, 습관 생성부터 완료 기록과 과거 기록 확인까지의 핵심 흐름을 먼저 검증한다.

초반에 작성한 Stack Day 코드를 그대로 끌고 가지 않고, 앱의 컨셉과 MVP 범위를 다시 정리했다. 구현 중간에 방향을 바꾸는 비용이 아깝기는 하지만, 기준이 없는 상태에서 코드를 계속 추가하는 것보다는 지금 멈추는 편이 낫다고 판단했다.

내일부터는 이 컨셉과 정책을 기준으로 실제 도메인 용어와 데이터 구조를 정리할 예정이다.