본문 바로가기
애플제품/MacBook

MacBook Air 13인치로 사이드 프로젝트 1년 — 개발자 시점

by 하늘011 2026. 9. 14.
APPLE 장기 사용기 · 사이드 프로젝트 1년

MacBook Air 13인치로 사이드 프로젝트 1년 — 개발자 시점

퇴근 후 2시간, 주말 카페 세션으로 Next.js 풀스택 프로젝트를 1년간 혼자 만들었습니다. MacBook Air가 어디까지 버텨주는지, 어디서 벽에 부딪혔는지 개발자 시각으로 전부 씁니다.

💻 MacBook Air M2 13인치 ⏰ 퇴근 후 + 주말 세션 🚀 실제 배포까지 완료

회사 업무는 충분히 잘 하고 있었습니다. 그런데 늘 마음 한켠에 "내 것을 만들고 싶다"는 생각이 있었습니다. 유저가 실제로 쓰는 서비스, 내가 설계하고 내가 배포하는 것. 그래서 작년 1월, 퇴근 후 두 시간과 주말 카페 세션을 사이드 프로젝트에 쓰기로 했습니다. 기기는 MacBook Air 13인치. 가볍고 배터리 오래 가는 게 조건이었습니다. 1년이 지난 지금, 실제로 사용자가 있는 서비스를 배포했습니다. MacBook Air가 어디까지 버텨줬는지, 어디서 한계가 왔는지 개발자 시점에서 전부 털어놓겠습니다.

MacBook Air 13인치로 사이드 프로젝트 1년
MacBook Air 13인치로 사이드 프로젝트 1년
12개월사이드 프로젝트 기간
1,240회Git 커밋 수
3개실제 배포한 프로젝트
평균 2.3h일일 사이드 작업 시간

🛠️ 1년간 사용한 기술 스택

사이드 프로젝트의 스택은 회사 업무와 겹치는 부분도 있고, 새로 배운 것들도 있었습니다. MacBook Air에서 이 스택이 얼마나 쾌적하게 돌아갔는지가 이 글의 핵심입니다.

🛠️ 사이드 프로젝트 기술 스택

⚛️
Next.js 14
App Router 풀스택
🔷
TypeScript
전체 코드베이스
🎨
Tailwind CSS
스타일링
🐻
Zustand
클라이언트 상태
🟩
Supabase
DB + Auth + Storage
Vercel
배포 + Edge
🐳
Docker
로컬 개발 환경
🔺
Prisma
ORM
🔷
VS Code
주 에디터
🐙
GitHub
버전 관리
🌊
Figma
디자인·목업
📮
Postman
API 테스트

📊 MacBook Air M2 — 사이드 개발 성능 실측

1년 동안 같은 작업을 반복하면서 자연스럽게 성능 패턴이 쌓였습니다. 공식 벤치마크가 아닌 실제 개발 워크로드 기준입니다.

⚡ 실제 개발 작업별 성능 체감

Next.js dev 서버 기동
 
약 3~5초 — 체감 빠름, 불만 없음
TypeScript 빌드 (next build)
 
중규모 프로젝트 기준 45~80초
Docker + Supabase 로컬
 
Docker 컨테이너 4개 동시 — 팬 시작, 체감 저하
VS Code + Chrome 탭 10개
 
16GB 통합 메모리 덕분에 여유로움
Figma (복잡한 파일)
 
컴포넌트 100개 이상 파일에서 렉 발생
GitHub Actions 로컬 실행 (act)
 
Rosetta 오버헤드 + Docker 동시 → 쓰로틀링
배터리 개발 세션 지속
 
dev 서버 기준 5~6시간 — 카페 세션 완주 가능
✅ 가장 놀라웠던 것 — 16GB 통합 메모리

사이드 프로젝트에서 가장 체감된 스펙은 CPU가 아니라 메모리였습니다. VS Code, Chrome(탭 10개), Slack, Figma, 터미널 3개를 동시에 띄워도 스왑이 일어나지 않았습니다. 8GB였다면 이 조합에서 분명히 메모리 스왑이 발생했을 겁니다. 사이드 프로젝트용 MacBook Air를 고른다면 반드시 16GB로 가야 합니다.

⚙️ 개발 워크플로 유형별 평가

🌐 최고 조건

Vercel 기반 풀스택 개발

Next.js + Vercel + Supabase 조합은 MacBook Air에서 가장 잘 맞는 스택이었습니다. 로컬에서는 dev 서버만, 무거운 작업은 Vercel·Supabase 클라우드가 담당해서 Air에 부담이 거의 없었습니다.

🔥 기대 이상

빠른 이터레이션 · 핫 리로드

코드 수정 → 저장 → 브라우저 반영까지 1~2초. M2 칩의 단일 코어 성능이 빠른 피드백 루프에서 진가를 발휘했습니다. 사이드 프로젝트의 특성상 이 속도가 의욕 유지에 실질적인 도움이 됐습니다.

📐 충분히 가능

Figma 디자인 + 코드 병행

Figma와 VS Code를 같이 띄우는 건 가능합니다. 다만 Figma 파일이 복잡해질수록 팬이 돌기 시작했습니다. 단순한 목업 작업은 문제없고, 대형 디자인 시스템 파일은 버거웠습니다.

🧪 무난

Vitest 단위 테스트 실행

테스트 파일 수백 개를 watch 모드로 돌려도 쾌적했습니다. Jest보다 Vitest가 M2에서 훨씬 빠르게 동작한다는 걸 직접 확인했습니다. 테스트 주도 개발을 하기에 불편함이 없었습니다.

🐳 타협 필요

Docker 멀티 컨테이너

컨테이너 3개 이상을 동시에 돌리면 팬리스 특성이 한계를 드러냈습니다. 쓰로틀링이 시작되면 개발 서버 핫리로드 속도도 눈에 띄게 느려졌습니다. Docker는 꼭 필요한 컨테이너만 켜두는 습관이 생겼습니다.

🏗️ 한계 명확

전체 빌드 + Docker 동시

next build와 Docker를 동시에 돌리는 조합은 Air에서 가장 힘든 작업이었습니다. 팬리스 구조에서 쓰로틀링이 시작되면 빌드 시간이 2배 이상 늘어났습니다. 이 작업만큼은 Docker를 먼저 내리고 진행하는 루틴을 만들었습니다.

🌙 퇴근 후 사이드 세션 — 시간대별 에너지 흐름

1년 동안 퇴근 후 사이드 개발 세션의 패턴이 시간대별로 굳어졌습니다. 피로도와 집중도가 시간에 따라 크게 달랐습니다.

🌙 퇴근 후 사이드 세션 집중도 패턴

오후 7~8시
 
퇴근 직후 — 밥 먹고 잠깐 쉬다 보면 의욕이 안 생김
오후 8~9시
 
황금 시간대 — 집중이 가장 잘 되는 구간
오후 9~10시
 
최고 집중 — 외부 방해 없이 몰입 가능
오후 10~11시
 
피로 누적 시작 — 새 기능보다 버그 수정에 적합
오후 11시 이후
 
비효율 구간 — 이 시간대 커밋은 다음 날 수정 확률 높음
주말 오전 10~12시
 
최고 생산성 — 카페 세션, 2시간에 평일 4시간 몫
💡 MacBook Air가 사이드 세션에 특히 좋은 이유

퇴근 후 사이드 개발에서 MacBook Air가 빛나는 이유는 성능보다 무게와 배터리입니다. 1.24kg의 가벼움으로 카페·회사 → 집 이동이 부담 없고, 충전기 없이 5~6시간 dev 세션이 가능합니다. Pro의 성능이 더 좋지만, 퇴근 후 지친 상태에서 무거운 가방을 들고 싶지 않다는 심리적 장벽이 사이드 프로젝트 지속성에 영향을 줬습니다. 가벼워서 꺼내기 쉬운 것이 결국 더 많이 쓰게 만들었습니다.

🚀 1년간 주요 마일스톤 — 실제로 만들어진 것들

🚀
3개월 차

첫 번째 MVP 배포 — 개발자 링크 공유 서비스

Next.js App Router + Supabase + Vercel 조합으로 처음 실제 배포를 완료했습니다. 기능은 단순했지만, "내가 만든 게 인터넷에 올라가 있다"는 감각이 처음이었습니다. 첫 사용자가 생겼을 때 손이 떨렸습니다.

📚
5개월 차

Turborepo 모노레포 도입 — Air의 한계를 처음 맛봄

두 번째 프로젝트에서 Turborepo 모노레포 구조를 도입했습니다. 전체 빌드 시 팬리스 Air가 쓰로틀링을 일으키기 시작한 게 이때였습니다. Docker와 동시 실행을 피하는 루틴이 이 시점에 생겼습니다.

💀
7개월 차

3주 번아웃 — 사이드 프로젝트 중단

회사 업무가 바빠진 시기와 겹쳐 3주 동안 사이드 프로젝트를 거의 못 했습니다. 복귀 후 코드를 보니 맥락이 기억 안 나는 부분이 있어서 주석과 README를 보강하는 데 일주일을 썼습니다. 문서화의 중요성을 몸으로 배운 시기였습니다.

📈
9개월 차

실사용자 100명 돌파 — 첫 피드백 루프

두 번째 서비스가 실사용자 100명을 넘겼습니다. 사용자 피드백을 받아 기능을 개선하는 사이클이 처음 돌아간 시점이었습니다. MacBook Air가 Vercel 로그를 보면서 핫픽스를 배포하는 데 충분히 빠르게 반응해줬습니다.

🏁
12개월 차

세 번째 프로젝트 배포 — 1년 결산

1년 동안 총 3개 프로젝트를 배포했습니다. 누적 사용자 약 350명, GitHub 스타 합산 120여 개. MacBook Air는 처음부터 끝까지 이 과정의 유일한 도구였습니다. 한 번도 "기기를 바꿔야겠다"는 생각이 들지 않았습니다.

⚖️ MacBook Air vs Pro — 사이드 프로젝트 관점에서

항목 Air (팬리스) Pro (팬 포함) 사이드 개발 선택
일반 Next.js 개발 충분히 쾌적 더 빠름 Air ✅
Docker 멀티 컨테이너 3개 이상 쓰로틀링 안정적 Pro 우위
퇴근 후 이동 편의 1.24kg 최경량 1.4~2.1kg Air ✅
충전기 없이 세션 5~6시간 8~11시간 (Pro) Pro 우위
Figma 대형 파일 버거움 쾌적 Pro 우위
next build 속도 45~80초 30~55초 둘 다 충분
가격 (16GB 기준) 약 169만 원 약 249만 원~ Air 80만 원 절약
카페·이동 작업 최적 무거움 Air ✅
⚠️ Air 팬리스 — 사이드 개발에서 실질적 제약

사이드 프로젝트에서 Air 팬리스의 제약이 체감되는 순간은 딱 두 가지였습니다. Docker 컨테이너 3개 이상 동시 실행next build + Docker 동시 작업. 이 두 가지만 피하면 Air는 사이드 개발 머신으로 전혀 부족하지 않습니다. 실제로 두 가지 다 작업 루틴을 바꾸는 것으로 해결했습니다.

📅 1년 사이드 프로젝트 타임라인

1~2개월 차 — 환경 세팅과 첫 삽
Next.js 14 App Router가 막 안정화된 시점이었습니다. 새 라우팅 패턴을 익히면서 동시에 프로젝트를 시작하니 학습과 개발이 뒤섞여서 진도가 느렸습니다. 그래도 Air의 빠른 핫리로드가 시행착오를 짧게 만들어줬습니다.
3개월 차 — 첫 배포, 손이 떨렸다
Vercel에 처음으로 프로덕션 배포를 했습니다. 터미널에 "Deployment complete" 메시지가 뜨는 순간 진심으로 손이 떨렸습니다. 첫 사용자가 회원가입을 했을 때 Supabase 대시보드를 새로고침하며 5분 동안 지켜봤습니다.
5개월 차 — 기술 부채와 리팩토링
빠르게 만들다 보니 코드가 지저분해졌습니다. Turborepo 도입과 함께 전면 리팩토링을 결심했고, 이 과정에서 Air의 빌드 한계를 처음 맛봤습니다. 리팩토링은 새 기능보다 훨씬 더 시간이 걸린다는 걸 다시 배웠습니다.
7개월 차 — 3주 공백, 번아웃
회사 업무가 터지면서 3주 동안 사이드 프로젝트를 못 했습니다. 복귀했을 때 내가 짠 코드인데도 맥락이 안 잡혔습니다. 그날 이후 커밋 메시지를 상세하게, README를 꾸준히 업데이트하는 게 습관이 됐습니다.
9개월 차 — 실사용자 피드백 사이클
사용자가 100명을 넘기면서 처음으로 "이 기능이 불편해요"라는 피드백을 받았습니다. 당일 저녁 핫픽스를 배포하는 경험이 처음이었고, Air에서 Vercel 로그 보면서 배포하는 과정이 충분히 빠르고 쾌적했습니다.
12개월 차 — 1년 결산, 계속하기로
3개 프로젝트 배포, 350명 사용자, 1,240 커밋. 1년을 돌아보니 MacBook Air는 한 번도 발목을 잡지 않았습니다. 오히려 가볍고 조용하다는 특성이 카페 세션에서 집중력을 높이는 데 기여했습니다. 내년에도 이 기기로 계속하기로 했습니다.

😟 구매 전 걱정했던 것

  • 팬리스라 빌드할 때 느려질까
  • 8GB로 살걸 16GB가 필요할까
  • 13인치가 너무 작지 않을까
  • Docker 쓰면 한계 오지 않을까
  • 사이드 프로젝트 1년 버틸 수 있을까

😌 1년 후 실제 결과

  • Docker 3개 이상 동시만 피하면 OK
  • 16GB 통합 메모리 — 스왑 한 번도 없음
  • 카페에서 오히려 13인치가 최적
  • 작업 루틴 조정으로 Docker도 해결
  • 3개 프로젝트 배포, 발목 잡은 적 없음
1년간 사이드 프로젝트를 하면서 깨달은 것: MacBook Air의 성능이 사이드 프로젝트의 병목이 된 경우는 거의 없었습니다. 진짜 병목은 항상 '오늘 몇 시간 짤 수 있는가'와 '의욕이 있는가'였습니다. 가벼운 Air를 배낭에 쉽게 넣고, 카페에서 꺼내는 심리적 장벽이 낮다는 것이 1년을 지속하게 만든 가장 중요한 요소였습니다.

MacBook Air 13인치 사이드 개발 1년 종합 평가

사이드 프로젝트에 최적화된 기기 — 단, 16GB는 필수

만족도 91점
Next.js 개발 속도
 
메모리 여유도
 
휴대성·이동 편의
 
카페 배터리 세션
 
Docker 중부하 작업
 
장시간 빌드 안정성
 
MacBook Air 13인치는 사이드 프로젝트 개발자에게 최고의 기기 중 하나입니다. 가벼워서 항상 들고 다니게 되고, 배터리가 오래 가서 카페 세션을 완주할 수 있으며, Next.js + Vercel + Supabase 스택에서는 Pro와 비교해도 체감 차이가 거의 없습니다. 단, 16GB 메모리는 타협하지 마세요. 그리고 Docker 의존도가 높은 프로젝트라면 Pro를 진지하게 고민해야 합니다. 그 외의 사이드 프로젝트라면 Air 13인치는 충분히 좋은 동반자입니다.

결론 — 기기보다 습관이 사이드 프로젝트를 지속시킨다

1년 동안 MacBook Air가 발목을 잡은 건 단 두 번이었습니다. Docker 멀티 컨테이너 동시 실행, 그리고 전체 빌드와 Docker 병행. 두 번 다 기기 한계가 아니라 작업 루틴을 바꿔서 해결했습니다. 결국 사이드 프로젝트를 지속하게 만든 건 기기의 성능이 아니었습니다. 매일 맥북을 꺼내게 만드는 가벼움, 충전기 없이 카페를 버티게 해주는 배터리, 그리고 빠른 핫리로드가 주는 즉각적인 피드백이 의욕을 유지시켰습니다.

사이드 프로젝트를 시작하려는 개발자분께 한마디만 드리겠습니다. 기기가 완벽할 때를 기다리지 마세요. 지금 있는 기기로 일단 시작하세요. 가장 좋은 사이드 프로젝트 환경은 매일 꺼내기 가장 편한 기기 위에 있습니다.

사이드 프로젝트 하시는 분들 이야기가 궁금합니다

어떤 기기로 사이드 개발을 하고 계신가요? 퇴근 후 세션을 이어가는 나만의 루틴이 있다면 댓글로 공유해 주세요. 특히 Air와 Pro 사이에서 고민하고 계신 분들의 이야기도 듣고 싶습니다.


소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 나무핀