사이드 프로젝트를 하는 이유

이 글은 기술 글이 아닙니다. 사이드 프로젝트를 하며 들었던 말들, 그럼에도 계속한 이유, 그리고 그 결과에 대한 이야기입니다.

"그걸로 빅테크 못 간다"

생 신입 시절, 사이드 프로젝트를 한다고 했을 때마다 저에게 돌아온 반응들이 있습니다.

• "사이드 프로젝트로는 빅테크 못 간다."
• "경력에 뒷받침이 안 된다."
• "실무 경험이 아니면 의미 없다."
• "그 시간에 알고리즘이나 풀어라."
• "그 기술은 어차피 현업에서 못쓴다."

틀린 말은 아닐지도 모릅니다. 그래서 상처받은 경험도 많습니다. 마음 속엔 불안함이 가득했고, 확신이 필요했던 시기에 저런 말들은 저에게 가시와도 같았습니다.

사실 사이드 프로젝트 자체가 이력서에 한 줄 적힌다고 해서 면접관이 감동하는 경우는 거의 드뭅니다. 대부분의 사이드 프로젝트는 TODO 앱 수준에서 끝나고, 배포조차 하지 않고 그만두는 경우가 많습니다. 실제로 현업에서 만큼의 좋은 인프라를 구축하기도 힘들기에 현실에 좌절하고 멈추는 사람들도 많습니다. 그런 프로젝트가 경력에 도움이 되느냐고 묻는다면, 솔직히 아닐 수도 있습니다. 저 또한 확신은 없습니다.

하지만 그 말들이 전제하고 있는 것이 하나 있습니다. 사이드 프로젝트를 "결과물"로만 본다는 것. 또한 사이드 프로젝트를 포트폴리오 용도로만 본다는 것. 이것이 저 말을 하는 사람들의 전제조건 일지도 모릅니다.

내가 사이드 프로젝트를 하는 이유

사이드 프로젝트의 진짜 가치는 결과물이 아니라 의사 결정의 밀도입니다. 또한 현업에서 하지 못한 아쉬움을 풀어 내고자 하는 수단입니다.

회사에서는 아키텍처가 이미 정해져 있습니다. 프레임워크, 데이터베이스, 배포 파이프라인, 코드 컨벤션. 대부분의 결정은 내가 그 회사에 합류하기 전에 이미 끝난 결정 뿐입니다. 나는 그 결정 위에서 기능을 구현하는 사람일 뿐입니다. 물론 그 과정에서도 배우지만, "왜 이 기술을 선택했는가"를 직접 고민할 기회는 많지 않습니다.

하지만 사이드 프로젝트에서는 모든 결정이 내 몫입니다.

• REST만 쓸 것인가, gRPC를 도입할 것인가?
• 트랜잭션 경계를 어디에 둘 것인가?
• 이벤트를 Kafka로 보낼 것인가, Outbox로 쌓을 것인가?
• 모놀리스로 갈 것인가, 서비스를 분리할 것인가?

내가 이 결정들을 직접 내리고, 그 결과를 직접 감당합니다. 잘못된 선택을 하면 코드가 꼬이고, 좋은 선택을 하면 구조가 깔끔하게 잡힙니다. 이 즉각적 피드백 루프를 반복하는 것은 회사에서 경험할 수 없는 성장의 핵심 요소라고 생각합니다. 그것이 사이드 프로젝트에서만 얻을 수 있는 경험이라고 생각합니다.

"자바스크립트가 아니어도 충분하다"

이전 회사에서의 메인 기술 스택은 Classic ASP와 MSSQL이었습니다.

엑셀 다운로드 하나를 위해 2,000줄짜리 Stored Procedure를 작성하고, 그 안에 비즈니스 로직, 데이터 포맷팅, 접근 로직이 뒤섞여 있었습니다. 그리고 Classic ASP 페이지에서 그 결과를 그대로 뿌리는 구조였습니다. 그리고 그것을 그들만의 핵심 "기술"이라고 불렀습니다. 신입에게도 이러한 기술이 강요되기 마련이었죠. 신입에게 오래된 기술이 강요되던 그 시간은, 말 그대로 삶의 낭비처럼 느껴졌습니다.

사이드 프로젝트에서 TypeScript와 React, NestJS를 쓰고 있다고 했을 때, 혹은 신규 시스템을 개발하거나 이전 레거시 시스템을 마이그레이션 한다고 했을 때 돌아온 반응은 다음과 같았습니다.

• "자바스크립트가 아니어도 충분하다."
• "신기술 쫓지 말고 지금 하는 것에 집중해라."
• "SP 잘 짜는 게 실력이다."

항상 똑같은 답이었죠. 또 다시 상처였고, 서럽기도 했습니다. 지금 제가 가고 있는 이 길이 잘못된 건가 하루에도 몇 번씩 스스로를 의심하기 마련이었습니다. 그리고 내가 느꼈던 서러움이 나를 더 집요하게 만들었습니다.

내가 가진 역량을 무시하는 말들도 많이 들었습니다. 새로운 기술을 배우는 것이 마치 현재 업무를 소홀히 하는 것처럼 취급받기도 했습니다. 하지만 저는 2,000줄짜리 SP 안에 비즈니스 로직, 데이터 접근, 포맷팅이 전부 섞여 있는 구조가 "기술"이라고 불려야 하는 건지 납득이 되지 않았습니다. 지금도 이 생각에 변함은 없습니다.

그래서 더 사이드 프로젝트에 매달렸습니다. 회사에서 배울 수 없는 것을, 회사 밖에서 배우는 수밖에 없었습니다. 하루도 빠짐없이 개발 아티클을 읽고 구독하기도 하고, 구현에 매몰되어 열심히 했습니다. 다른 사람들은 함수 하나를 잘 짜기 위해 어떠한 아이디어를 내는지 매일같이 궁금해 했습니다. 회사에서 배울 수 없는 것, 스스로 배워야 하는 것. 그게 내 성장의 유일한 길이었습니다.

2023년의 나

2023년, 처음 HoBom이라는 이름으로 사이드 프로젝트를 시작했을 때 만든 것은 기술 블로그 프론트엔드였습니다. Vue로 만든, 글 목록을 보여주고 상세 페이지로 이동하는 단순한 웹사이트 였습니다.

그때의 기술 스택은 다음과 같았습니다.

• Vue 3 + TypeScript
• 정적 페이지 렌더링
• 별도의 백엔드 없음

사실 2022년도에는 JavaScript로 시작했습니다.

솔직히 말하면, 그때는 이 정도가 제 한계였습니다. 백엔드를 직접 설계해 본 적도 없었고, 데이터베이스 트랜잭션이 왜 중요한지도 느껴본 적이 없었습니다. API를 호출하는 것과 API를 설계하는 것이 전혀 다른 일이라는 것도 몰랐습니다.

2026년의 나

지금 HoBom 시스템은 8개의 레포지토리, 6개의 언어로 구성된 폴리글랏 시스템입니다.

TypeScript, Go, Kotlin, C#, Groovy, Vue.. 필요한 문제에 맞는 언어를 선택해서 쓰고 있습니다.

언어와 기술 스택을 문제에 맞춰 선택하고, 직접 라이브러리를 만들어 배포하며 시스템에 접목했습니다. 이 과정에서 경험한 성장과 고통은 회사에서는 상상도 못할 수준이었습니다.

hobom-grid는 Turborepo 모노레포로 관리하는 UI 그리드 컴포넌트 라이브러리입니다. Vite로 빌드하고, Vitest로 테스트하고, VitePress로 문서화하고, GitHub Actions로 배포합니다. 라이브러리를 만들고, 배포하고, 실제 서비스에 통합하는 경험. 이건 프론트엔드 개발자로서도, 라이브러리 메인테이너로서도 성장한 것입니다.

noname은 함수형 유틸리티 라이브러리입니다. Lazy evaluation과 함수형 프로그래밍 패러다임을 TypeScript로 구현했습니다. 남이 만든 라이브러리를 쓰는 것과, 그 라이브러리가 어떻게 만들어졌는지 이해하고 직접 만드는 것은 완전히 다른 차원의 경험입니다.

3년 전에 Vue로 블로그 프론트엔드를 만들던 사람이, 단순 프론트엔드를 넘어 풀스택 역량을 쌓았고, 라이브러리를 직접 설계하고 배포하는 단계까지 왔습니다. 분산 시스템의 Dual Write 문제를 고민하고, gRPC 서비스 간 트랜잭션 경계를 설계하고, Outbox와 Kafka를 어디에 배치할지 아키텍처 결정을 내리고 있습니다. Transactional Outbox 패턴으로 이벤트 정합성을 보장하고, AsyncLocalStorage로 MongoDB 세션을 전파하고, Puppeteer로 법령 사이트를 스크래핑하여 LLM과 연동하고 있습니다.

이 성장은 회사 업무만으로는 불가능했습니다. 회사에서는 "주어진 스펙을 구현하는 것"을 하지만, 사이드 프로젝트에서는 "스펙 자체를 정의하는 것"부터 시작합니다. 그 차이가 3년 동안 쌓이면, 기능을 구현하는 개발자와 시스템을 설계하는 엔지니어 사이의 간극이 됩니다.

멸시를 당하면서도 계속한 이유

"사이드 프로젝트로는 안 된다"는 말을 들을 때마다 생각한 것이 있습니다. 그 말을 하는 사람들은, 사이드 프로젝트를 끝까지 해본 적이 없는 사람들이었습니다. 회사 외의 시간을 활용하여 노력을 해 본 경험이 없는 사람들 이었고, 어쩌면 저만큼 성장에 대한 갈망이 없는 사람들 이었을지도 모릅니다. HoBom이 아니었다면 저는 이만큼 성장할 수 있었을까요? 면접에서 저의 기술력을 더욱 잘 어필할 수 있었을까요?

TODO 앱을 만들다가 포기한 경험으로 "사이드 프로젝트는 의미 없다"고 결론 내린 그 사람들의 경험이 의미가 없었던 건 사이드 프로젝트가 아니라, 중간에 그만둔 것이었을지도 모릅니다.

사이드 프로젝트의 가치는 시간이 지나야 보입니다. 처음에는 CRUD를 만들고, 그다음에는 인증을 붙이고, 그다음에는 트랜잭션을 고민하고, 그다음에는 서비스를 분리하고, 그다음에는 이벤트 정합성을 설계합니다. 이 과정에서 매번 벽을 만나고, 그 벽을 넘을 때마다 시야가 넓어집니다.

굽히지 않고 계속한 이유는 단순합니다. 매번 벽을 넘을 때마다, 이전의 내가 보이지 않던 것이 보였기 때문입니다.

빅테크에 입사하고 나서 느낀 것

결국 빅테크에 입사했습니다. 그리고 입사 후에 깨달은 것이 있습니다.

면접에서 제가 받은 질문들은,시스템 설계, 트레이드오프 분석, 장애 시나리오 대응과 같은 실무적인 것들 이었습니다. 이것들은 알고리즘 문제집을 풀어서 답할 수 있는 것이 아니었습니다. 또한 2000줄의 Stored Procedure를 개발하며 경험할 수 있는 것들이 아니었습니다. "이 아키텍처를 왜 선택했는가", "이 방식의 단점은 무엇인가", "규모가 커지면 어떻게 대응할 것인가". 이 질문들에 답할 수 있었던 건, 사이드 프로젝트에서 직접 결정을 내리고 그 결과를 겪어봤기 때문입니다.

또한 사이드 프로젝트를 통해 멸시를 당하던 그 순간에도 기회를 갈망하며 매달렸던 저의 의지의 결과물 이었습니다. 소중하게 얻은 기회에서 사이드 프로젝트의 경험을 기반으로 더욱 좋은 시스템을 설계할 수 있었고, 현업에서 백엔드를 실제로 경험하며 분산 시스템에서도 당황하지 않고 운영할 수 있었기에 빅테크 면접에서도 저의 역량을 한껏 발휘할 수 있었으리라 확신합니다.

사이드 프로젝트가 이력서에 한 줄 적혀서 합격한 것이 아닙니다. 사이드 프로젝트를 하면서 쌓인 의사 결정의 경험이, 면접에서 질문에 답하는 깊이를 만들어 준 것입니다. 또한 상상만으로는 대답할 수 없는 실제 경험들을 진솔하게 풀어냈기 때문에 좋은 결과를 받았으리라 생각합니다.

빅테크에도 성장을 멈춘 사람들은 있다

빅테크에 오면 모두가 끊임없이 공부하고 성장할 것이라고 생각했습니다. 하지만 현실은 사뭇 달랐습니다.

본인의 기술에 고집이 있는 사람들이 있습니다. 자신이 익숙한 기술 스택에서 벗어나지 않으려는 사람들. 혹은 새로운 패러다임이나 도구가 나와도 "지금 것으로 충분하다"고 말하는 사람들. 첫 회사에서 들었던 "자바스크립트가 아니어도 충분하다"와 본질적으로 같은 태도를 빅테크에서도 보게 될 줄은 몰랐습니다.

더 이상 공부하지 않는 사람들도 있습니다. 입사가 목표였고, 목표를 달성한 뒤에는 현재 위치를 유지하는 데만 집중하는 사람들. 기술은 끊임없이 바뀌는데, 배움을 멈추면 그 순간부터 뒤처지기 시작합니다.

그리고 요즘 특히 눈에 띄는 것이 있습니다. AI에게 모든 것을 맡기고, 자신은 프롬프트만 작성하는 사람들. AI 드리븐 디벨롭먼트. AI는 분명 강력한 도구입니다. 하지만 AI가 생성한 코드가 왜 그렇게 작성되었는지, 그 구조가 적절한지, 트레이드오프가 무엇인지를 판단할 수 없다면, 그것은 개발이 아니라 복붙입니다. 도구를 쓰는 것과 도구에 의존하는 것은 다릅니다.

사이드 프로젝트를 계속하는 이유가 하나 더 생겼습니다. 환경이 바뀌어도, 스스로 성장하는 습관은 바뀌지 않아야 한다는 것. 빅테크에 입사했다고 끝이 아닙니다. 빅테크도 결국 환경일 뿐이고, 성장은 환경이 아니라 태도에서 옵니다.

사이드 프로젝트를 하려는 사람들에게

"사이드 프로젝트로는 안 된다"는 말을 들을지도 모릅니다. 그 말을 하는 사람들의 의도가 나쁜 것은 아닐 수 있습니다. 하지만 그 말이 맞는지 아닌지는, 직접 끝까지 해봐야 알 수 있습니다.

한 가지 확실한 것은, 사이드 프로젝트는 꾸준히, 오래, 점진적으로 해야 의미가 있다는 것입니다. 한 달 만에 화려한 결과물을 내는 것이 아니라, 1년, 2년, 3년에 걸쳐 하나의 시스템을 키워 나가는 것. 그 과정에서 자연스럽게 더 어려운 문제를 만나게 되고, 그 문제를 풀면서 성장합니다.

Vue 블로그 프론트엔드 하나에서 시작한 프로젝트가, 3년 후에 8개의 레포지토리와 6개의 언어로 구성된 분산 시스템이 되었습니다. 처음부터 이걸 목표로 한 것이 아닙니다. 그냥 매번, 지금의 나보다 조금 더 어려운 문제를 풀었을 뿐입니다.

HoBom이라는 이름은 내가 사랑하는 사람과 함께 만든 이름입니다. 기술에 대한 갈망, 성장에 대한 욕심, 그리고 사랑하는 사람과 함께하는 시간. 이 세 가지가 만나서 만들어진 것이 HoBom 시스템입니다.

그것이 제가 과거에도, 그리고 여전히 지금도 사이드 프로젝트를 하는 이유입니다.