2025년 10월 10일·7분
프레임워크를 줄이면 팀 속도가 빨라지는 이유
프레임워크 수를 줄이면 컨텍스트 전환이 줄고 온보딩이 단순해지며 공유 도구가 강화되어 팀이 더 빠르고 예측 가능하게 기능을 배포할 수 있습니다.
프레임워크 수를 줄이면 컨텍스트 전환이 줄고 온보딩이 단순해지며 공유 도구가 강화되어 팀이 더 빠르고 예측 가능하게 기능을 배포할 수 있습니다.
“프레임워크를 줄인다”는 기술 스택 전체를 하나의 도구로 축소하라는 뜻이 아니다. 동일한 종류의 것을 만드는 방법의 수를 의도적으로 제한해 팀이 코드를 공유하고, 기술을 재사용하며, 패턴과 도구를 공유하게 만드는 것이다.
프레임워크 확산은 조직이 유사한 제품을 위해 여러 겹치는 프레임워크를 쌓을 때 발생한다—대개 인수합병, 높은 팀 자율성, 혹은 “한번 써보자” 식의 결정들이 폐기되지 않으면서 나타난다.
일반적 사례:
이들 자체가 무조건 잘못된 건 아니다. 문제는 다양성이 이를 지원할 역량을 초과할 때 발생한다.
속도는 ‘우리가 몇 스토리 포인트를 소모했나’가 아니다. 실제 팀에서 속도는 다음과 같이 드러난다:
프레임워크가 늘어나면, 모든 변경이 더 많은 컨텍스트, 번역, 맞춤형 도구를 필요로 하기 때문에 이 지표들이 악화되는 경우가 많다.
통합은 전략이지 평생의 계약이 아니다. 건전한 접근법은 현재 요구에 맞는 소수의 스택을 선택하고(예: 연간) 검토 시점을 정하며, 전환은 계획된 마이그레이션을 통해 이루어지게 하는 것이다.
팀이 선호 도구를 고르는 지역 최적화를 일부 포기하는 대신(더 빠른 온보딩, 공유 컴포넌트, 단순한 CI/CD, 적은 엣지 케이스 실패 등) 시스템 수준의 이득을 얻는다. 이하에서는 그 절충이 가치있는 경우와 그렇지 않은 경우를 다룬다.
팀은 보통 “프레임워크 하나만 더” 도입할 때 즉시 비용을 느끼지 못한다. 비용은 작은 지연—추가 회의, 긴 PR, 중복된 설정—으로 나타나 점차 쌓여, 모든 사람이 열심히 일해도 전달 속도가 느려진 것처럼 느끼게 만든다.
동일한 기능을 구현할 수 있는 여러 방법이 있으면 엔지니어는 선택하는 데 시간을 쓰고 구축하는 데 쓰지 못한다. 이 페이지는 프레임워크 A의 라우팅을 쓸까, 프레임워크 B의 것을 쓸까? 어떤 상태 접근법을 택할까? 어떤 테스트 러너를 쓸까? 선택 하나당 30분이 걸리더라도 여러 티켓에 걸쳐 반복되면 며칠이 사라질 수 있다.
혼합 스택에서는 개선이 확산되지 않는다. 한 프레임워크에서 배운 성능 개선, 접근성 패턴, 오류 처리 방식은 다른 프레임워크로 그대로 재사용하기 어렵다. 그 결과 동일한 버그가 반복적으로 발생하고, 같은 교훈을 다른 팀들이 다시 배우게 된다.
일관되지 않은 패턴은 리뷰어에게 컨텍스트 전환을 강요한다. PR은 단지 “이게 맞나?”가 아니라 “이 프레임워크에서는 이렇게 해야 하지 않나?”가 되어 리뷰 시간이 늘고 버그 위험이 올라간다. 프레임워크 특유의 미묘한 엣지 케이스가 놓치기 쉽다.
프레임워크 확산은 다음 영역에서 중복 노력을 낳는다:
결과는 코드의 추가뿐만 아니라 추가 유지보수다. 프레임워크 하나가 더해질 때마다 업그레이드, 보안 패치, "여기서는 X를 어떻게 하지?"라는 대화가 하나 더 생긴다.
속도는 타이핑 속도만이 아니다—문제를 얼마나 빨리 이해하고 안전하게 변경해 배포할 수 있느냐의 문제다. 프레임워크 확산은 인지 부하를 높여 개발자가 사용자의 니즈 해결보다 "이 앱은 어떻게 구현됐더라"를 더 많이 기억하게 만든다.
여러 프레임워크를 다루면 모든 작업에 숨겨진 워밍업 비용이 있다. 서로 다른 문법, 규약, 도구로 정신을 전환한다. 작은 차이(라우팅 패턴, 상태관리 기본값, 테스트 라이브러리, 빌드 설정)도 마찰을 만든다.
이 마찰은 리뷰 지연, “여기선 X를 어떻게 하지?”라는 질문 증가, 변경의 리드 타임 증가로 드러난다. 일주일 단위로 보면 큰 지연 한 번이 아니라 수십 번의 작은 지연이다.
표준화는 동작을 예측 가능하게 만들어 개발 생산성을 높인다. 표준화가 없으면 디버깅은 보물찾기가 된다:
결과: 진단 시간 증가, 구축 시간 감소.
인증, 애널리틱스, 에러 리포팅 같은 일반적 통합은 지루해야 한다. 여러 프레임워크가 있으면 각 통합마다 커스텀 글루 코드와 특수 처리가 필요해 더 많은 엣지 케이스와 잠재적 실패 지점이 생긴다. 운영 오버헤드가 증가하고 온콜 지원이 더 스트레스받게 된다.
팀 속도는 자신 있는 리팩토링에 달려 있다. 코드베이스를 진정으로 이해하는 사람이 적으면 엔지니어는 구조적 개선을 주저하고 문제 주위에 패치만 해댄다. 복잡성은 늘고 인지 부하는 계속 상승한다.
프레임워크를 줄인다고 모든 어려운 문제가 사라지는 건 아니지만, "어디서부터 시작하지?"라는 순간을 줄여 시간과 집중을 확보하게 해준다.
프레임워크 확산은 기능 전달 속도를 늦출 뿐 아니라 사람들이 함께 일하기 어렵게 만든다. 각 팀이 고유한 "구축 방식"을 가지면 조직은 럼프업(learning) 시간, 채용 마찰, 약한 협업이라는 비용을 치른다.
신규 입사자는 제품, 고객, 워크플로를 배워야 한다. 여기에 여러 프레임워크를 배워야 한다면 온보딩 시간이 길어진다—특히 "우리는 이렇게 페이지를 구조화한다", "우리는 이렇게 데이터를 가져온다", "우리의 테스트 패턴은 이렇다"라는 반복 학습 기회를 잃게 된다.
그 결과 다른 사람을 더 자주 기다리고, 작은 실수가 늘고, 독립적 소유권을 얻는 데 더 오랜 시간이 걸린다.
멘토링은 시니어가 문제를 빠르게 식별하고 전이 가능한 패턴을 가르칠 때 가장 효과적이다. 프레임워크가 많으면 시니어가 여러 스택에 분산되어 멘토링 효과가 떨어진다.
결과:
공유 프레임워크가 적으면 시니어의 멘토링이 여러 레포에 걸쳐 효율적으로 작동한다.
프레임워크 목록이 길면 채용과 인터뷰가 어려워진다. 후보자는 스스로 제외되거나 인터뷰가 도구의 잡학으로 흐르기 쉽다.
표준 스택이 있으면 기초 역량(제품 사고, 디버깅, 시스템 설계)에 초점을 맞추고 프레임워크 특수성은 온보딩으로 일관되게 가르칠 수 있다.
페어링, 코드 리뷰, 인시던트 지원 같은 크로스팀 도움은 패턴이 공유될 때 더 잘 작동한다. 프로젝트 구조를 인식하면 다른 엔지니어가 자신있게 기여하고 빠르게 리뷰하며 긴급 상황에 뛰어들 수 있다.
몇 가지 차이는 남겠지만 소수의 표준화된 프레임워크는 "어떤 엔지니어든 도울 수 있는" 코드베이스 표면적을 크게 늘린다.
소수의 프레임워크를 공유하면 재사용은 이상이 아니라 일상적 관행이 된다. 동일한 빌딩 블록이 여러 제품에서 작동하므로 문제를 다시 해결하는 데 드는 시간이 줄고 출시 시간이 빨라진다.
디자인 시스템은 채택하기 쉬울 때만 ‘진짜’가 된다. 스택이 적으면 단일 UI 컴포넌트 라이브러리가 여러 팀에 포팅 없이 제공될 수 있다(React 버전, Vue 버전, 레거시 버전 불필요). 그 결과:
프레임워크 다양성은 같은 유틸리티를 여러 번 재구현하게 만든다. 표준화하면 다음 같은 공유 패키지를 실용적으로 유지할 수 있다:
"우리 앱은 다르게 한다" 대신 팀들이 신뢰할 수 있는 이식 가능한 패턴을 얻게 된다.
입력 컴포넌트에 키보드 동작, 포커스 상태, ARIA 속성이 내장되어 있으면 그 개선은 제품 전반에 자동으로 전파된다.
마찬가지로 공유 린팅, 테스트 헬퍼, 리뷰 체크리스트는 대부분의 레포에 적용되므로 의미가 있다.
각 프레임워크는 설정 가이드, 컴포넌트 사용법, 테스트 규약, 배포 노트를 곱절로 만든다. 스택이 적으면 문서는 더 명확하고 완전해진다—더 많은 사람들이 유지하고 더 자주 사용하기 때문이다.
그 결과는 새로운 합류자가 내부 플레이북을 읽을 때 특히 가치있는 "특별 케이스"와 부족한 관행이 줄어드는 것이다.
속도는 단지 개발자가 코드를 얼마나 빨리 쓸 수 있는가가 아니다. 코드가 얼마나 빨리 빌드되고 테스트되며 배포되고 안전하게 운영되는가도 중요하다. 소수의 합의된 프레임워크를 쓰면 "프로덕션 머신"이 단순해지고 눈에 띄게 빨라진다.
프레임워크 확산은 보통 레포마다 특수한 파이프라인 로직을 요구한다: 다른 빌드 명령, 다른 테스트 러너, 다른 컨테이너화 단계, 캐싱 전략 등. 표준화는 이 다양성을 줄여준다.
일관된 빌드/테스트 단계가 있으면:
특수 파이프라인 대신 대부분의 프로젝트가 소폭 수정으로 채택할 수 있는 몇 가지 권장 패턴을 얻게 된다.
다양한 프레임워크는 의존성 표면적을 넓힌다. 그만큼 취약점 어드바이저리를 추적해야 할 수가 늘고 업그레이드가 깨질 확률도 올라간다.
프레임워크가 적으면 다음을 표준화할 수 있다:
이로써 보안 작업은 화재 진압이 아니라 정기적 유지보수가 된다—특히 고심각도 이슈가 발생했을 때 많은 레포를 빠르게 패치해야 하는 경우에 유리하다.
로깅, 메트릭, 추적은 일관될 때 가장 유용하다. 프레임워크마다 미들웨어 스택, 요청 ID 관행, 오류 경계가 다르면 관측성은 분절된다.
스택을 줄이면 공통 기본값(구조화된 로그, 공유 대시보드, 일관된 트레이스)에 맞출 수 있어 팀들이 "텔레메트리를 작동시키는" 데 시간을 덜 쓰고 신뢰성 개선에 더 많은 시간을 쓸 수 있다.
린터, 코드 생성기, 템플릿, 스캐폴딩 도구는 만들고 유지하는 데 비용이 든다. 많은 팀이 거의 손대지 않고 쓸 수 있을 때 투자 수익이 난다.
표준화하면 플랫폼/엔에이블먼트 작업이 확장된다: 한 좋은 템플릿이 수십 개 프로젝트를 가속하고 한 세트의 규약이 조직 전반의 리뷰 사이클을 줄여준다.
예컨대 일부 팀은 Koder.ai 같은 “vibe-coding” 플랫폼을 사용해 내부 도구 생성 시 페이브드-로드 스택을 강제한다—예: React 프론트엔드와 Go + PostgreSQL 백엔드를 챗 워크플로에서 생성하여 출력물이 조직의 기본에 맞게 나오도록(그리고 소스 코드로 내보내 유지보수 가능하게) 한다.
소수의 프레임워크를 고른다는 것은 영원한 단일 승자를 고르는 것이 아니다. 기본 스택과 승인된 대안을 소수로 정의해 팀이 매 스프린트마다 기본을 놓고 논쟁하지 않게 만드는 것이다.
주요 표면 영역마다(예: 프론트엔드, 백엔드 서비스, 모바일, 데이터) 하나의 기본을 목표로 하라. 옵션이 꼭 필요하면 플랫폼당 1–2개로 제한하라. 간단한 규칙: 새 프로젝트를 시작할 때 회의 없이 기본을 선택할 수 있어야 한다.
기본 스택은 다음이어야 잘 작동한다:
설명하기 쉽고 조작하기 어려운 기준에 합의하라:
프레임워크가 점수를 잘 받더라도 운영 복잡성(빌드 시간, 런타임 튜닝, 인시던트 대응)을 증가시킨다면 그 비용을 실제 비용으로 고려하라.
예외를 승인할 소규모 그룹(플랫폼 팀이나 시니어 IC 위원회)을 만들되 속도를 유지하라:
기본 스택, 승인 목록, 예외 절차를 단일 진실 소스(예: /docs/engineering-standards)에 두고 프로젝트 템플릿과 온보딩 자료에서 링크하라.
소수의 프레임워크로 표준화한다고 해서 극적인 리라이트가 필요한 것은 아니다. 가장 안전한 마이그레이션은 거의 지루하게 진행된다: 작은 단계로 이루어지고, 가치를 계속 배송하며, 각 릴리스마다 리스크를 줄인다.
새 앱, 새 서비스, 새 UI 표면, 내부 도구 등 모든 새 작업에 기본 스택을 기본값으로 설정하라. 이렇게 하면 레거시를 건드리지 않고도 확산을 즉시 늦출 수 있다.
안정적이고 가치를 전달하는 레거시 앱은 당장은 그냥 두라. 강제 리라이트는 긴 동결, 마감일 실패, 팀 분산을 초래한다. 대신 실제 제품 변경에 의해 마이그레이션이 추진되게 하라.
현대화가 필요할 때 자연스러운 경계에 따라 마이그레이션하라:
패턴은 단순하다: 구 시스템을 유지하면서 기능의 한 조각을 새 스택으로 리다이렉트하고 반복한다. 시간이 지나면 새 구현이 구 구현을 "조여서" 남은 레거시를 안전하게 퇴출할 수 있다.
사람들은 가장 쉬운 길을 따른다. 기준을 심어둔 템플릿과 스타터 킷을 만들어라:
이들을 잘 알려진 위치에 두고 내부 문서(예: /engineering/stack, /engineering/starter-kits)에서 링크하라.
마이그레이션은 "아무도 담당하지 않는 일"일 때 실패한다. 각 폐기 대상 프레임워크/의존성에 대해:
진행 상황과 예외를 공개적으로 게시해 팀들이 작업을 계획할 수 있게 하라.
표준화는 현실적이어야 한다. 비표준 프레임워크가 옳은 선택인 순간은 있지만, “한 번의 예외”가 다섯 개의 병렬 스택으로 번지지 않도록 규칙을 두어라.
명확하고 방어 가능한 이유가 있는 경우에만 예외를 허용하라:
"팀이 좋아해서"라는 근거는 측정 가능한 성과로 뒷받침될 때까지 선호로 간주하라.
모든 예외는 경량의 “지원 계약”을 포함해야 한다:
이 없으면 향후 운영 비용을 예산 없이 승인하는 셈이 된다.
예외는 갱신되지 않으면 만료되어야 한다. 간단한 규칙: 6–12개월마다 검토하라. 검토 시 질문:
성능 목표, 컴플라이언스 요구, 총 소유비용, 채용/온보딩 영향, CI/CD·관측성 통합 등을 포함한 체크리스트로 개인적 취향과 실제 필요를 구분하라. 체크리스트를 통과하지 못하면 스택에 들어오지 못한다.
프레임워크 통합은 도박이다: 확산 감소가 인지 부하를 줄이고 개발자 생산성을 높일 것이라는 가정이다. 그 결과를 알기 위해선 마이그레이션 중의 느낌만 보지 말고 시간을 두고 결과를 측정하라.
기준 윈도우(예: 통합 전 6–8주)를 정하고 표준화된 스택에서 실제 작업을 배포한 이후의 안정기와 비교하라. 전환 중 일시적 하락은 예상하고, 변화가 흡수된 이후의 추세가 중요하다.
아이디어에서 실행 중인 소프트웨어까지 전체 경로를 반영하는 소수의 지표를 사용하라:
이 지표들은 플랫폼 팀과 엔지니어링 지원 그룹에게 특히 유용하다. 조작하기 어렵고 추세 파악이 쉽다.
프레임워크 통합은 온보딩 시간을 줄여야 한다. 추적 항목:
또한 팀들이 공유 컴포넌트와 패턴을 얼마나 빈번히 재사용하는지 관찰하라.
PR 리뷰 시간, 재작업 루프, 결함률을 표준화 전후로 모니터링하라. 빨라지는 것은 품질이 유지될 때만 의미가 있다.
지각된 마찰, 문서 품질, 배포 자신감에 관한 짧은 반복 설문(5문항 내외)과 몇 번의 인터뷰를 결합해 지표가 놓치는 부분을 캡처하라.
소수의 프레임워크로 표준화하는 것은 기술적 결정이라기보다 신뢰의 문제다. 사람들은 ‘하나의 스택’ 규칙이 혁신을 죽이고 락인을 만들며 팀 자율성을 빼앗을까 걱정한다. 그들 걱정을 직접 다루고 경로가 실용적으로 느껴지게 하면 더 잘 진행된다.
“이게 혁신을 죽인다.” 속도 향상이 목표이지 실험을 막는 게 아니다. 시간 제한된 실험은 허용하되 성공한 실험은 폭넓게 채택되기 쉽게 만들어라—그렇지 않으면 격리된 상태로 두라.
“우리가 락인된다.” 락인은 대개 인기 프레임워크 선택이 아니라 커스텀 글루 코드와 부족한 문서, 부족한 경계에서 온다. API, 디자인 토큰, 서비스 계약 등 경계를 문서화해 프레임워크 선택이 전반에 스며들지 않게 하라.
“팀 자율성을 빼앗는다.” 자율성은 결과를 빠르게 내는 것으로 재프레이밍하라. 팀은 여전히 제품 방향을 결정하고, 플랫폼은 불필요한 변동을 제거해 작업을 더 수월하게 만든다.
기본이 되는 잘 지원된 스택(페이브드 로드)을 제공하라: 템플릿, 라이브러리, 문서, 온콜 준비된 툴링. 그런 다음 기본에 맞지 않는 경우에 대해 명확한 예외 프로세스를 정의해 예외가 가시적이고 정당화되며 지원받도록 하라.
표준에 대한 RFC 프로세스를 운영하고, 정기 오피스아워를 운영하며, 마이그레이션 지원(예제, 페어링, "쉬운 승리" 백로그)을 제공하라. 선택한 프레임워크, 지원 버전, “지원”의 의미를 단순한 페이지에 게시하라.
언제 여러 프레임워크가 정당화될 수 있나?
몇 가지 합리적 경우가 있다: 학습 속도가 장기 유지비보다 중요한 단기 실험, 즉시 리팩터링할 수 없는 인수된 제품, 런타임 제약이 근본적으로 다른 경우(임베디드 vs 웹 등). 핵심은 이들을 종료 계획이 있는 예외로 다루는 것이다.
"표준화"와 "모듈화"와 "리라이트" 중 어떻게 결정하나?
팀들이 이미 다른 스택에 크게 투자했으면 어떻게 하나?
그들의 작업을 무시하지 마라. 먼저 인터페이스에 맞춰 정렬하라: 공유 컴포넌트 계약, API 규약, 관측성, CI/CD 요구사항. 그런 다음 새 프로젝트에 대한 기본 프레임워크를 정하고 변화가 많은 영역부터 점진적으로 수렴하라(가장 "성가신" 부분이 아닌 곳부터).
더 깊은 가이드는 /blog/engineering-standards를 참고하라. 인에이블먼트 툴이나 플랫폼 지원을 평가 중이라면 /pricing이 도움이 될 수 있다.
"프레임워크를 줄인다"는 동일한 종류의 제품을 만드는 여러 겹치는 방법(예: 웹 UI 기본 스택 1개, 서비스 프레임워크 1개)을 제한해 팀이 기술, 컴포넌트, 도구, 운영 관행을 재사용할 수 있게 한다.
모든 것을 하나의 도구로 줄이거나 예외를 금지하는 뜻은 아니며, 불필요한 다양성을 줄이는 것이 핵심이다.
프레임워크 확산은 유사한 문제를 해결하는 여러 스택이 쌓여 있을 때 발생한다(자율성, 인수합병, 혹은 퇴출되지 않은 실험 때문인 경우가 많음).
간단한 점검: 두 팀이 컴포넌트를 쉽게 공유하거나, 코드 리뷰를 하거나, 온콜 지원을 교체할 수 없다면, 확산 비용을 지불하고 있을 가능성이 높다.
스토리 포인트가 아니라 끝에서 끝까지의 전달을 측정하세요. 유용한 지표:
통제 집단(통합 전 6–8주 등)을 정해 기준을 만들고, 전환기 동안의 일시적 하락을 예상한 뒤 정상화 후 추세를 비교하세요.
예—제약이 실제로 다르거나 시간 한정인 경우엔 복수 스택을 유지할 수 있다. 일반적인 합당한 경우:
이들은 예외로 취급하고 명시적 소유권과 검토 날짜를 부여하세요.
각 주요 영역(웹, 서비스, 모바일, 데이터)에 대해 ‘기본 스택’을 정하고 허용할 수 있는 대안은 플랫폼당 1–2개로 제한하세요.
도구 논쟁을 피하려면 사전에 합의된 기준을 사용하세요:
목표는 새 프로젝트가 회의 없이 기본을 선택할 수 있게 하는 것이다.
거버넌스는 가볍고 빠르게 유지하세요:
모든 것을 한 곳(/docs/engineering-standards 같은)에 문서화하세요.
빅뱅 리라이트를 피하세요. 안전한 패턴:
이 방식은 위험을 줄이면서 지속적으로 가치를 전달하게 해준다.
예외는 반드시 사전 ‘지원 계약’을 포함해야 한다:
예외가 지원과 검토를 약속하지 않으면 단순한 선호일 가능성이 높고, 결국 스프롤을 재생성한다.
통합은 대체로 온보딩과 협업을 개선한다:
영향을 가시화하려면 "첫 PR 병합까지의 시간"과 "첫 기능 배포까지의 시간"을 추적하세요.
설득은 강제가 아니다—지원으로 보여주세요:
온보딩과 템플릿에서 표준과 예외 경로를 연결해 두세요(예: /docs/engineering-standards).