오버엔지니어링을 멈춰라: 모멘텀을 잃지 않고 스케일러블 앱을 구축하는 방법
Source: Dev.to
실제 문제 (단순히 조기 최적화가 전부는 아니다)
우리는 모두 조기 최적화가 나쁘다는 것을 알고 있다. 하지만 더 교묘한 버전이 있다:
조기 아키텍처.
아직 존재하지도 않는 문제에 대한 해결책을 설계하고 있는 것이다.
- 12명의 사용자만 있을 때 “확장성을 위해” 레이어를 추가하기
- 한 번만 사용되는 재사용 가능한 컴포넌트 만들기
- 할 일 목록에 대해 상태 관리를 과도하게 고민하기
비용: 개발 속도 저하, 디버깅 난이도 상승, 끊임없는 재검토.
아무도 말해 주지 않는 진실
확장 가능한 시스템은 설계되는 것이 아니라 진화한다.
성공적인 제품의 초기 코드를 보면: 지저분하고, 아마도 부끄러울 정도지만 배포되었다. 리팩토링은 고통이 실제로 느껴질 때 일어난다. 무엇이 깨질지 예측할 수는 없고, 깨졌을 때 빠르게 대응하는 능력만 키울 수 있다.
대신 이렇게 해라
1단계: 작동하게 만들기
코드를 하드코딩하고, 추상화를 건너뛰고, 기능을 바로 배포한다.
2단계: 고통을 느낄 때까지 기다리기
“이걸 바꾸는 게 고통스럽다” 혹은 “이게 너무 느리다” 라는 느낌이 들 때가 신호다. 그 전에는 아니다.
3단계: 그때 리팩터링
이제 실제로 무엇을 재사용해야 하고, 무엇이 느리며, 무엇이 고통스러운지 알게 된다. 그때 비로소 아키텍처가 의미를 갖는다.
실제 예시 (React 폴더 구조)
아주 단순하게 시작
src/
components/
pages/
utils/잘 동작한다.
나중에 파일이 너무 많아졌을 때
src/
features/
auth/
components/
hooks/
api/
dashboard/
components/
services/
shared/
ui/
hooks/이 구조는 스스로 획득한 것이다; 처음부터 그렇게 시작한 것이 아니다.
과도하게 하는 징후
다음과 같은 생각이 들면:
- “나중에 필요할 수도 있다”(실제로는 필요 없을 것이다)
- “이걸 정말 재사용 가능하게 만들자”(한 번만 쓰인다)
- “여러 경우를 지원해야 한다”(사실은 한 경우만 있다)
- 코딩보다 조직화에 더 많은 시간을 쏟는다
멈추고, 숨을 크게 쉬고, 무언가를 배포하라.
실제로 효과가 있는 규칙들
- 오늘을 위해 구축하라, “만약 1천만 명이 된다면”을 위해서가 아니라.
- 코드를 두 번 복제한 뒤에 세 번째로 추상화한다.
- 거의 이해하지 못하는 라이브러리를 추가하지 않는다.
- 문제를 측정할 수 있을 때만 최적화한다.
- 리팩터링보다 더 빨리 배포한다.
지금 무언가를 만들고 있다면…
마이크로서비스, 화려한 상태 머신, 엔터프라이즈 수준의 아키텍처는 필요 없다.
작동하는 기능, 피드백, 그리고 속도가 필요하다. 그 외의 모든 것은 화려한 모자를 쓴 미루기일 뿐이다.
최고의 개발자는 완벽한 시스템을 설계하는 사람이 아니라, 언제 입을 다물고 바로 그걸 만들어야 하는지를 아는 사람이다.