7년 동안 하나 만들었습니다: 프론트엔드 개발의 결정적 순간│인프콘2024

처음에는 모든 이벤트 메타데이터를 한 번에 불러와 이름으로 바꾸는 간단한 기능이었지만, 이벤트가 다른 고객의 천 배인 사례에서 화면과 로직이 무너졌다. 데이터의 양과 변화량을 미리 알면 경험을 제한하거나 렌더링 가상화를 적용하는 등 적절한 기술을 일찍 선택할 수 있다. 반복해서 참조하는 데이터는 정규화하거나 Map으로 구성하고 파일·컴포넌트 구조까지 참조하기 쉽게 만들면 성능과 일관성, 유지보수성이 함께 좋아진다.

기존 라이브러리를 대신해 블록 선택, 상대 날짜, 타임존과 날짜 동기화를 모두 포함한 캘린더를 직접 만들었지만 실제 요구는 예상과 다르게 변했다. UTC가 아닌 기준 시각과 서머타임 버전 차이까지 얽히면서 수정할수록 조건과 의존성이 늘어 아무도 건드리고 싶지 않은 컴포넌트가 됐다. 문제를 작게 정의하지 않은 채 해결책과 미래 기능부터 고정하면 선택지가 줄어들므로, 짧은 주기로 멈춰 설계를 바꾸고 완성된 사용 형태를 먼저 그린 뒤 중요한 부분부터 구현해야 한다.

무거워진 Redux를 대체하려고 성능과 구조를 검토한 뒤 Recoil을 도입했지만, 운영 이후 발견된 문제 때문에 결정을 크게 후회하게 됐다. 측정 자료 자체보다 도입하고 싶은 마음이 자신에게 유리한 근거를 더 크게 받아들이게 한 편향이 실패의 원인이었다. 새 기술은 일정 기간 유예한 뒤 임계점을 다시 확인하고, 특정 도구를 답으로 놓기보다 문제를 거꾸로 펼쳐 여러 해결 옵션 중 하나로 비교해야 한다.

7년 사이 기능과 코드가 크게 늘면서 리팩터링은 남의 잘못을 고치는 일이 아니라 과거 자신의 선택과 당시 맥락을 감수하는 일이 됐다. 서비스가 일정 복잡도를 넘으면 새로 작성한다는 선택이 어려워지므로 레거시를 없앨 대상으로만 보지 말고 다음 결정을 돕는 힌트와 유산으로 활용한다. 정해진 경력 공식을 따르기보다 같은 경험에서도 자신만의 의미를 발견할 때 그것이 개발자로 성장하게 하는 결정적 순간이 된다.