개발 스택을 22개 도구에서 14개로 줄였습니다. 무엇이 살아남았고 그 이유는 무엇일까요?
요약
Nventory 팀이 개발 효율성을 높이기 위해 22개의 도구를 14개로 최적화한 사례를 공유합니다. 복잡성을 줄이고 개발자 경험(DX)을 개선하기 위해 도구 선택의 기준을 기능 중심에서 워크플로우 속도와 단순함 중심으로 전환했습니다.
핵심 포인트
- 도구의 기능이 많은 것보다 워크플로우가 단순한 것이 도입에 유리함
- Linear 도입을 통해 티켓 생성 오버헤드를 획기적으로 줄임
- Notion을 활용해 파편화된 문서화 도구를 하나로 통합
- Loom을 활용한 비동기 커뮤니케이션으로 회의 부하 40% 감소
- Postman 대신 가볍고 계정이 필요 없는 HTTPie와 VS Code 확장 사용
Nventory를 구축한 지 6개월이 되었을 때, 우리는 22개의 도구를 동시에 사용하고 있었습니다.
그것은 우리가 그렇게 계획했기 때문이 아닙니다. 모든 문제마다 새로운 도구가 도입되었기 때문입니다. 새로운 직원이 채용될 때마다 그들이 선호하는 스택이 들어왔습니다. 매번 새로운 통합 (Integration)이 추가될 때마다 확인해야 할 대시보드가 하나씩 늘어났습니다.
그래서 우리는 전체 감사 (Audit)를 실시했습니다.
전체 삭제 목록 — 그리고 각 도구가 제외된 이유
Jira → Linear
Jira는 잘 작동합니다. 모든 것을 할 수 있습니다. 하지만 유지보수가 필요하고, 티켓 오버헤드 (Ticket overhead)를 발생시키며, 팀이 함께 사용하는 것이 아니라 우회해서 사용하게 만드는 인터페이스를 만들어냅니다.
Linear는 일주일 만에 그 자리를 대체했습니다. 기능 때문이 아닙니다 — Linear의 기능이 더 적기 때문입니다. 도입이 자연스럽게 이루어졌기 때문입니다. 엔지니어링 팀은 요청받지 않아도 스스로 Linear를 엽니다.
bash# Jira 워크플로우의 현실
- 티켓 생성 (5분 — 적절한 프로젝트, 에픽 (Epic), 스프린트 (Sprint) 찾기)
- 8개의 필수 필드 채우기
- 스토리 포인트 (Story points) 산정
- 스프린트에 할당
- 6개의 상태 컬럼 (Status columns)을 거쳐 이동
- 코멘트와 함께 티켓 종료
Linear 워크플로우의 현실
- C 누르기 — 이슈 생성
- 제목 입력
- Enter 누르기
- 완료
티켓 생성 속도는 개발자들이 실제로 티켓을 생성하는지 여부를 나타내는 대리 지표입니다. Linear가 승리했습니다.
Confluence → Notion
Confluence는 문서화가 죽어가는 곳입니다. 검색이 작동하지 않습니다. 페이지는 3단계 깊이로 중첩됩니다. 에디터는 사용자와 싸웁니다. Notion은 내부 위키 (Internal wiki), 엔지니어링 결정 사항, 통합 문서 (Integration documentation), 콘텐츠 캘린더, 그리고 회의록을 위해 그 자리를 대체했습니다. 하나의 도구. 하나의 검색. 첫 1년 동안은 무료 티어 (Free tier)로 모든 것을 해결했습니다. 팀원이 10명을 초과할 때까지 업그레이드하지 않았습니다.
Zoom 기본 사용 → Loom 기본 사용
진정으로 동기식 (Synchronous) 상호작용이 필요한 회의를 위해 Zoom은 유지했습니다. 하지만 기본 설정을 바꿨습니다. 모든 "이것 좀 설명해 줄 수 있나요?"는 Loom을 우선적으로 사용하게 되었습니다. 모든 코드 리뷰 설명, 모든 디자인 피드백 세션이 그렇게 되었습니다. 회의 부하가 40% 감소했습니다. 강요를 통해서가 아니라, Loom이 일정을 잡는 것보다 빠르기 때문에 가능했습니다.
Postman → HTTPie + VS Code REST Client
Postman은 클라우드 동기화 구독형 제품이 되었습니다.
그것이 도입한 복잡성 — 워크스페이스 (workspaces), 팀 동기화 (team sync), 버전 충돌 (version conflicts) — 이 우리의 사용 사례(use case)에서 얻는 가치를 넘어섰습니다.
bash
HTTPie — 터미널에서의 API 테스트
개발 중 웹후크 (webhook) 엔드포인트 테스트
http POST localhost:3000/webhooks/shopify
X-Shopify-Hmac-Sha256:abc123
topic:orders/create
shop_domain:example.myshopify.com
깔끔함. 빠름. 계정 불필요. 클라우드 동기화 없음.
VS Code REST Client가 나머지를 처리합니다:
http### 재고 동기화 엔드포인트 테스트
POST http://localhost:3000/api/inventory/sync
Content-Type: application/json
Authorization: Bearer {{token}}
{
"sku": "HOODIE-BLK-M",
"quantity": 47,
"channel": "shopify"
}
두 개의 도구가 교체되었습니다. 둘 다 무료입니다.
Datadog + New Relic → Grafana + Prometheus + Sentry
우리는 둘 중 무엇을 선택할지 결정하기 위해 두 달 동안 Datadog과 New Relic을 동시에 실행했습니다. 비용이 상당했습니다. 통찰력(insight)의 차이는 미미했습니다.
셀프 호스팅(Self-hosted)된 Grafana + Prometheus가 메트릭 (metrics)과 대시보드 (dashboards)를 커버합니다. Sentry는 특히 에러 트래킹 (error tracking)을 담당합니다. 총 비용: 서버 호스팅 비용. 총 역량: 대등함.
우리의 이벤트 기반 동기화 아키텍처 (event-driven sync architecture)에서 실제로 중요한 네 가지 메트릭:
javascript
// 우리가 실제로 확인하는 대시보드
const coreMetrics = {
syncLagP99: 'sync_lag_ms p99 < 5000', // 이벤트 전파 속도 (event propagation speed)
propagationSuccessRate: 'propagation_success / total > 0.99', // 채널 업데이트 신뢰도 (channel update reliability)
oversellRate: 'oversell_detected_24h === 0', // 제로 허용 오차 (zero tolerance)
dlqDepth: 'dead_letter_queue_depth < 100' // 실패한 전파 (failed propagations)
};
// 이 지표들이 녹색(정상)이 되기 전까지 다른 모든 지표는 노이즈에 불과합니다.
Amplitude → PostHog
Amplitude는 진정으로 강력합니다. 하지만 우리 단계의 팀에게는 진정으로 비용이 많이 듭니다.
PostHog의 셀프 호스팅(self-hosted) 무료 티어는 우리가 필요로 했던 기능의 90%를 수행합니다 — 퍼널 분석 (funnel analysis), 세션 녹화 (session recording), 피처 플래그 (feature flags), 그리고 코호트 분석 (cohort analysis)까지 말이죠. 나머지 10%의 차이는 우리 단계에서 비용 차이를 감수할 만큼 가치가 없습니다.
Intercom → Crisp
지원 요청(support volume)이 적은 상태에서 Intercom의 엔터프라이즈 가격 책정은 합리적이지 않습니다. Crisp의 무료 티어는 라이브 채팅과 기본적인 티케팅 (ticketing)을 처리할 수 있습니다. Intercom의 가격을 정당화할 만큼 볼륨이 커지면 — 그때 다시 검토하겠습니다. 그때까지는 Crisp를 사용합니다.
Retool → Next.js 내부 도구 (internal tools)
이것을 제거하는 것은 고통스러웠습니다. 왜냐하면 그 약속이 매우 매력적이었기 때문입니다. 코드를 작성하지 않고도 드래그 앤 드롭(drag-and-drop)으로 내부 도구를 만들 수 있다는 점 말이죠.
현실은 이랬습니다: 멀티채널 재고 동기화 (multichannel inventory sync)를 위한 우리의 데이터 모델은 Retool의 추상화 (abstractions)가 제약 사항이 될 정도로 충분히 복잡했습니다. 모든 커스텀 동작마다 컴포넌트를 직접 작성하는 것보다 더 오래 걸리는 우회 방법 (workarounds)이 필요했습니다.
우리는 내부 도구를 Next.js로 다시 구축했습니다. 초기에는 더 오래 걸렸습니다. 하지만 유지보수는 훨씬 쉬워졌습니다. 벤더 종속성 (vendor dependency)도 없습니다.
Height → Linear + Notion (분리)
Height는 작업 관리와 문서화를 통합하려고 시도했습니다. 이론적으로는 — 두 개의 도구를 쓰는 것보다 낫습니다. 하지만 실제로는 엔지니어링 모드와 문서화 모드 사이의 컨텍스트 스위칭 (context switching)이 실제로 유용합니다. 서로 다른 정신 상태에 따라 서로 다른 도구를 사용하는 것입니다.
살아남은 14개
엔지니어링 (Engineering):
├── VS Code (+ GitLens, REST Client, Error Lens, ESLint, Prettier)
├── GitHub (버전 관리 (version control) + CI/CD를 위한 GitHub Actions)
├── Docker + Docker Compose (로컬 개발 (local dev))
├── Warp (터미널 (terminal) — 셸 명령어를 위한 AI 자동 완성 (AI autocomplete))
├── TablePlus (데이터베이스 GUI — 무료 티어로 충분함)
├── Proxyman (HTTP 디버깅 (HTTP debugging) — 웹훅 (webhook) 디버깅에 매우 유용함)
└── Grafana + Prometheus + Sentry (모니터링 (monitoring) + 에러 트래킹 (error tracking))
팀 (Team):
├── Linear (엔지니어링 작업)
├── Notion (그 외 모든 것)
├── Loom (비동기 커뮤니케이션 (async communication))
├── Figma (디자인 — 무료 티어)
└── Slack (커뮤니케이션)
AI:
├── GitHub Copilot (자동 완성 (autocomplete) — 명확한 ROI)
├── Claude (작성, 추론, 코드 리뷰)
└── Perplexity (인용 출처가 포함된 리서치)
목록에는 포함되지 않았지만 언급할 가치가 있는 유용한 도구들
Excalidraw — 코드를 작성하기 전 모든 아키텍처 다이어그램을 그릴 때 사용합니다. 손으로 그린 듯한 미학(hand-drawn aesthetic)은 격식을 없애고 더 빠른 반복(iterate)을 가능하게 합니다. 주문 라우팅 엔진(order routing engine)과 이벤트 전파(event propagation) 아키텍처를 설계할 때 사용했습니다.
Warp — 실제로 의미 있는 터미널 업그레이드입니다. 셸 명령어를 위한 AI 자동 완성(autocomplete)은 일상 업무에서 진정으로 유용합니다. iTerm2에서 전환할 가치가 있습니다.
Raycast — macOS의 Spotlight를 대체합니다. 클립보드 기록, 윈도우 관리, Linear 연동, GitHub 연동 기능을 제공합니다. 무료 티어로 모든 것을 충족할 수 있습니다.
Proxyman — 대부분의 개발자가 필요해지기 전까지는 잘 모르는 도구입니다. 모든 네트워크 트래픽을 가로채고 검사하는 macOS용 HTTP 프록시(proxy)입니다. 웹훅(webhook) 전달 및 API 연동을 디버깅할 때 필수적입니다.
근본적인 원칙
도구가 추가될 때마다 다음과 같은 비용이 발생합니다:
const toolCost = {
contextSwitching: '진입하고 빠져나와야 하는 새로운 사고 모드 (new mental mode)',
decisionFragmentation: '다른 누구도 확인하지 않는 도구 내에서 내려지는 결정들',
maintenanceOverhead: '유지 관리해야 할 연동(integrations), 교체해야 할 자격 증명(credentials)',
onboardingCost: '신규 채용 시마다 늘어나는 새로운 학습 범위 (new surface area)'
};
function shouldAddTool(tool) {
const habitualAdoption = team.usesWithinTwoWeeks(tool);
const replacesExisting = tool.eliminates.length > 0;
const valueExceedsCost = tool.timeSavedWeekly * team.size >
Object.values(toolCost).reduce(sum) * tool.complexityMultiplier;
// 팀이 습관적으로 사용하지 않는다면 — 삭제하세요
return habitualAdoption && (replacesExisting || valueExceedsCost);
}
도구를 추가하기 전 던져야 할 질문: 생성되는 가치가 도입되는 조정 비용(coordination overhead)을 초과하는가?
대부분의 도구는: 아니오. 살아남은 14개는: 예, 입증 가능합니다.
이 스택으로 우리가 만들고 있는 것
Nventory — 멀티채널 재고 및 주문 관리 (multichannel inventory and order management). 40개 이상의 채널에 걸쳐 5초 이내에 이벤트 기반 동기화 (Event-driven sync)를 수행합니다. 평이한 영어로 가능한 AI 자동화. 스마트 주문 라우팅 (Smart order routing). 평생 무료.
→ nventory.io
→ Shopify Store
dev.to를 위한 질문
꼭 필요하다고 생각했지만 결국 삭제한 도구 하나는 무엇인가요?
그리고 아무도 블로그 포스트에 올리지 않지만, 팀의 업무 방식을 바꿔놓은 숨겨진 도구는 무엇인가요?
여러분이 실제로 사용하는 스택을 아래에 남겨주세요. 지향하는 스택이 아니라, 실제로 매일 사용하는 스택을 말이죠.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기