[학습] 채널톡이 Dropwizard를 선택한 이유
개념 설명
채널톡 공식 입장 (기술 블로그)
채널톡 "채널팀의 API서버를 소개합니다" 포스팅에서 직접 언급한 이유:
1. 해외 검증: "국내에서는 생소하나 Airbnb·Uber 등 해외 스타트업에서 검증됨"
2. 모듈화 유연성: Jetty·Jersey·Jackson 내장, 필요한 것만 선택 조합 가능, 점진적 개선에 적합
3. DI 자유도: 내장 DI 없이 Google Guice를 자유롭게 붙임. Spring IoC 컨테이너에 종속되지 않음
4. 현재 스택: Dropwizard + Guice + Jersey + Jooq
왜 이것만으로 설명이 부족한가
"Spring도 당시 충분히 많이 쓰였는데?"라는 반문이 유효하다. 빠진 맥락:
도입 시점이 핵심이다.
| 시점 | 맥락 |
|---|---|
| 2014년 4월 | Spring Boot 1.0 출시 — 아직 생태계 안정화 전 |
| 2014~2015년 | 채널코퍼레이션 창업, 초기 백엔드 스택 결정 시점 |
| 2011~2014년 | Dropwizard 존재, Airbnb·Uber 프로덕션 검증 완료 |
| 당시 Spring | Spring MVC + XML 설정의 엔터프라이즈 이미지 |
스타트업이 2014~2015년에 Java 백엔드를 선택할 때, "Airbnb·Uber 검증된 경량 Dropwizard" vs "Spring Boot 초기 불안정" 구도였다. 사용 빈도는 Spring이 높아도, 스타트업 맥락에서의 신뢰 가능한 레퍼런스는 Dropwizard가 오히려 높았다.
현재는 레거시 전환 비용 문제다.
운영 중인 대규모 B2B SaaS를 Spring으로 전환하는 것은 리스크·비용이 크다. Core팀의 존재 이유 중 하나가 "공통 프레임워크·기술표준 유지"이므로, 현 스택 고도화가 전환보다 합리적이다.
왜 중요한가
면접에서 "왜 Dropwizard 쓰세요?"가 나올 수 있다. 단순 "Spring보다 가볍다"를 넘어 도입 시점 맥락 + 레거시 비용 인식을 담으면 설득력이 다르다.
실전 적용
면접 답변 한 줄 정리
"Dropwizard 선택은 2014~2015년 도입 시점에서의 합리적 선택이었고 —
Spring Boot 안정화 이전, Airbnb·Uber 실전 검증, DI 자유도(Guice) —
이후 대규모 전환 비용보다 현 스택 고도화가 낫다는 판단이 유지되고 있는 것 같습니다."
Dropwizard vs Spring Boot 포지셔닝
- Dropwizard: REST 마이크로서비스 특화, 경량, DI 선택 자유, Spring 생태계 독립
- Spring Boot: 다양한 서비스 타입(REST·JMS·메시징), 내장 DI, 엔터프라이즈 복합 앱 적합
- Spring의 약점: AOP/IoC 필수 구조, 과다한 선택지로 의사결정 부담, 높은 학습곡선
함정 / 주의점
- "Dropwizard가 더 낫다"가 아니라 "도입 시점에서의 합리적 선택"이 포인트 — 우열 논쟁으로 가지 말 것
- 현재 채널톡이 Spring으로 이전할 계획이 있는지는 알 수 없으므로 단정 금지
복습 일정
| 단계 | 날짜 | 완료 |
|---|---|---|
| Day 0 (초학습) | 2026-05-24 | ☐ |
| Day 7 | 2026-05-31 | ☐ |
| Day 37 | 2026-06-30 | ☐ |
| Day 127 | 2026-09-28 | ☐ |
참고
- [채널팀의 API서버를 소개합니다](https://channel.io/ko/blog/articles/e24a772d) (채널톡 공식 블로그)
- [스프링의 단점과 대안](https://www.bangseongbeom.com/spring-downsides-alternatives.html) — Channel.io 사례 인용
- [Java Bootstrap: Dropwizard vs. Spring Boot](https://www.harness.io/blog/java-bootstrap-dropwizard-vs-spring-boot)