사이드 프로젝트가 본업에 미치는 영향 — 실무에서 느낀 점

게시일: 2025년 9월 12일 · 12분 읽기

사이드 프로젝트에서 배운 기술이 회사에서 써먹어진 적이 한두 번이 아니다

지난 경험간 나는 항상 사이드 프로젝트를 했다. 때로는 성공했고, 때로는 실패했다. 때로는 번아웃의 원인이 되기도 했다.

이 글은 사이드 프로젝트와의 올바른 거리에 대한 것이다.

사이드 프로젝트의 이점

1. 새로운 기술 학습

회사에서는 Electron만 쓰지만, 사이드 프로젝트에서 Rust를 배웠다. 그리고 2년 후, 회사에서 Rust가 필요해졌다. 나만 할 수 있었다.

2. 포트폴리오

사이드 프로젝트가 없으면, 이직할 때 "회사에서 했던 일"만 설명할 수 있다. 하지만 사이드 프로젝트가 있으면 "내가 정말 흥미 있는 분야"를 보여줄 수 있다.

3. 자유로운 기술 선택

회사의 기술 스택에 갇혀있지 않다. 새로운 방식을 실험할 수 있다.

4. 부수 소득

작지만 꾸준한 수입이 생길 수 있다. 내 경우 사이드 프로젝트로 월 50-200만원 정도 버는 때도 있었다.

5. 정신 건강

회사의 일이 따분할 때, 사이드 프로젝트는 활력이 된다. "내가 만드는 것"이라는 소유감은 번아웃을 막는다.

사이드 프로젝트의 위험성

1. 번아웃 가속

회사에서 40시간, 사이드에서 30시간. 주당 70시간이 된다.

나는 이것으로 한 번 번아웃을 경험했다. (위 글 참고)

2. 본업 성과 저하

피로하면 회사에서의 집중력이 떨어진다. 리뷰가 대충 해지고, 버그가 늘어난다.

3. 시간 우선순위 뒤틀림

사이드 프로젝트가 재밌으면, 회사 일을 미루게 된다. 리뷰는 느려지고, 데드라인을 놓친다.

4. 사이드 프로젝트 자체의 실패

피로한 상태에서는 사이드 프로젝트도 잘 못 한다. 악순환이다.

내가 배운 원칙

원칙 1: 본업이 최우선

사이드 프로젝트는 본업에 영향을 주면 안 된다. 회사의 성과가 떨어지면 절대로 안 된다.

체크리스트:

원칙 2: 에너지 적립

사이드 프로젝트는 에너지가 있을 때만 한다. 피로한 시점에는 무조건 멈춘다.

내 경우:

원칙 3: 사이드 프로젝트의 목표 명확히

단순히 "재미"만으로는 위험하다. 명확한 목표가 있어야 한다:

목표를 정했을 때, 일정과 시간 투자를 계획한다.

원칙 4: 정기적 평가

분기마다 사이드 프로젝트를 평가한다:

하나라도 "아니오"면 프로젝트를 일시 중지한다.

사이드 프로젝트 타입별 조언

1. 학습 목표형
"Rust를 배우고 싶다"

권장: 월 10-15시간
기간: 3-6개월
후: 중단 또는 다른 기술로 전환

2. 수입 목표형
"SaaS를 만들어서 월 1000만원 버는 걸 목표로"

권장: 월 20-30시간
기간: 1-2년
후: 성공하면 전업, 실패하면 학습

3. 포트폴리오형
"GitHub에 멋진 프로젝트를 올리고 싶다"

권장: 월 15-20시간
기간: 2-3개월
후: 포트폴리오 완성 시 중단

실제 경험담

성공 사례: Rust CLI 도구

- 목표: Rust 학습
- 기간: 3개월, 월 12시간
- 결과: Rust를 배우고, GitHub에 스타 500개 획득
- 회사 영향: 긍정적 (회사에서도 Rust 도입할 때 리더 역할)

실패 사례: 모바일 앱

- 목표: 수입 창출
- 기간: 6개월, 월 40시간 (과다)
- 결과: 앱 완성 후 300명만 다운로드, 월 수입 5만원
- 회사 영향: 부정적 (번아웃, 회사 일 품질 저하)

언제 사이드 프로젝트를 멈춰야 하는가

신호 1: 본업 성과 저하

회사에서:

→ 즉시 사이드 중단

신호 2: 번아웃 증상

피로, 짜증, 흥미 감소 → 사이드 전부 중단

신호 3: 사이드가 본업이 됨

"사이드가 진짜 하고 싶은 건데..."라는 생각이 들면, 그것은 더 이상 사이드가 아니다. 경력 변경을 고려해야 한다.

결론

사이드 프로젝트는 장점이 크지만, 조건이 있다:

  1. 본업이 최우선이어야 한다
  2. 에너지가 있을 때만 한다
  3. 명확한 목표가 있어야 한다
  4. 정기적으로 평가한다

오래 개발해 온 내 기준으로는: 사이드 프로젝트는 성장의 기회지만, 과욕하면 둘 다 망친다.

iL
ian.lab

실무 개발자입니다. 현장에서 겪은 문제와 해결 과정을 기록합니다. 오류 제보는 연락처로 보내주세요.