IT

요즘 미니 스택 얘기 자꾸 보여서 직접 써봤다. 결론부터 말하면 반은 맞고 반은 글렀다. 우리 팀 백엔드 5명인데 온보딩할 때마다 docker-compose up 한 번에 되는 사람이 단 한 명도 없었다. 진짜 한 명도. 평균 환경세팅 1.7일 걸렸다. M1 맥 나오고 나서는 2.3일로 늘었다. arm64 이미지 안 맞아서 삽질하는 시간이 순수하게 추가됐다. 매번 "야 README 최신이야?" 이 질문이 슬랙에 주 3회 이상 올라왔다. 미니 스택 컨셉은 단순하다. DB는 SQLite나 임베디드로 돌리고, 메시지큐는 인메모리로 대체하고, 캐시도 로컬 맵으로 끝내는 거다. Docker 레이어 자체를 없애버리겠다는 발상인데, 이게 생각보다 현실성 있는 게 요즘 SQLite가 WAL 모드에서 동시 읽기 처리량이 꽤 나온다. 벤치마크 찍어보면 단일 노드 기준 초당 읽기 10만 쿼리 넘기는 건 일도 아니다. 실제로 사이드 프로젝트 하나를 미니 스택으로 전환해봤다. 기존에 docker-compose.yml에 postgres, redis, rabbitmq 3개 올리던 구성이었는데 전부 걷어냈다. **바뀐 수치들:** - 콜드 스타트: 47초 → 3초. 열다섯 배 차이. - 메모리 점유: 2.1GB → 340MB. 컨테이너 3개 띄우던 게 프로세스 1개로 줄었으니 당연하다. - CI 파이프라인: 4분 12초 → 1분 38초. 도커 이미지 빌드+풀 시간이 통째로 사라졌다. - 온보딩: git clone하고 go run . 치면 끝. 환경세팅 시간 측정 자체가 의미없어졌다. 여기까지만 보면 왜 진작 안 했나 싶은데. 문제는 스케일이 커질 때 나온다. DAU 500 이하일 때는 진짜 아무 문제 없다. 근데 운영 트래픽 태워보면 얘기가 달라진다. SQLite는 쓰기 동시성에서 한계가 명확하다. 쓰기 초당 100건 넘어가면 SQLITE_BUSY 뜨기 시작하고, 인메모리 큐는 프로세스 죽으면 메시지가 증발한다. 새벽 3시에 서버 재시작됐는데 큐에 있던 결제 콜백 47건이 날아갔다고 생각해봐라. 그건 장애 보고서 쓰는 수준이 아니라 사직서 쓰는 수준이다. 그래서 내 결론은 이렇다. **쓸 만한 경우:** - 사이드 프로젝트, MVP, 내부 어드민 툴 - DAU 1,000 이하 서비스 - 개발/스테이징 환경 (이건 진짜 강추) - 1인 개발이나 소규모 팀 **쓰면 안 되는 경우:** - 결제 들어가는 서비스 - 쓰기 비율 높은 서비스 (채팅, 로깅 등) - 장애 시 데이터 유실 허용 안 되는 곳 Docker 지옥에서 벗어나는 건 맞다. 근데 그 지옥이 괜히 있던 게 아니었다는 것도 쓰면서 알게 된다. 컨테이너 격리가 주는 안정성, 볼륨 마운트로 데이터 보존하는 것, 네트워크 분리 같은 것들. 불편했지만 다 이유가 있었던 거다. 지금 우리 팀은 개발 환경만 미니 스택으로 바꾸고 스테이징부터는 기존 Docker 구성 유지하는 방식으로 갔다. 개발자 경험 점수 설문 돌려보니까 10점 만점에 4.2에서 7.8로 올랐다. 환경 관련 슬랙 질문은 주 3회에서 월 1회로 줄었고. 이 정도면 도입 가치는 확실히 있다. 다만 이걸 프로덕션까지 밀고 나가겠다는 글들 보면 좀 걱정된다. 로컬에서 잘 돌아가는 것과 새벽에 트래픽 몰릴 때 버텨주는 건 완전히 다른 문제니까. 편한 만큼 잃는 것도 있다는 거 인지하고 쓰면 꽤 괜찮은 선택지다.