많은 개발자가 주말을 이용해 무언가를 만듭니다. 새로운 프레임워크를 학습하기 위해, 혹은 평소 느꼈던 사소한 불편함을 해소하기 위해 코드를 짭니다. 하지만 대부분의 이런 프로젝트는 깃허브(GitHub)의 수많은 저장소 중 하나가 되어 먼지만 쌓인 채 잊혀지곤 합니다. 우리는 이를 ‘레포 선반(Repo Shelf)에 올라갔다’고 표현합니다. 완벽한 설계도, 거창한 마케팅 전략, 막대한 예산이 투입된 프로젝트조차 실패하는 시대에, 정작 아무런 기대 없이 만든 ‘토이 프로젝트’가 조직 전체의 업무 방식을 바꾸는 현상은 어떻게 가능했을까요?

우리는 흔히 제품의 성공이 치밀한 기획과 시장 조사에서 온다고 믿습니다. 하지만 실제 현장에서 사용자의 선택을 받는 제품은 ‘가장 정교한 것’이 아니라 ‘가장 가려운 곳을 정확히 긁어주는 것’입니다. 펄사(Pulsar)라는 프로젝트가 겪은 예상치 못한 성공은, 현대의 기업 환경에서 진정한 ‘제품-시장 적합성(Product-Market Fit)’이 어떻게 내부적으로 구현되는지를 극명하게 보여주는 사례입니다.

기대치 제로의 프로젝트가 생존하는 법

펄사는 처음부터 전사적인 도입을 목표로 설계되지 않았습니다. 개발자가 스스로 사용하기 위해 만든 ‘도그푸딩(Dogfooding)’ 프로젝트였기 때문입니다. 도그푸딩이란 자신이 만든 제품을 직접 사용하며 문제점을 찾아내는 과정을 말합니다. 이 과정의 핵심은 ‘사용자와 개발자의 일치’에 있습니다. 외부의 요구사항 정의서가 아니라, 개발자 본인이 매일 느끼는 고통이 곧 제품의 스펙이 됩니다.

대부분의 기업용 소프트웨어는 상향식(Top-down)으로 결정됩니다. 경영진이 필요하다고 판단한 기능을 기획자가 정의하고, 개발자가 구현합니다. 이 과정에서 실제 실무자가 느끼는 미세한 불편함은 ‘우선순위’라는 이름 아래 삭제됩니다. 반면, 펄사와 같은 사이드 프로젝트는 철저하게 하향식(Bottom-up)으로 움직입니다. ‘이 기능이 없어서 내가 너무 불편하다’는 절실함이 구현의 동력이 되기에, 결과물은 극도로 실용적일 수밖에 없습니다.

기술적 구현과 단순함의 미학

펄사가 레포 선반에 머물지 않고 확산될 수 있었던 기술적 배경에는 ‘낮은 진입장벽’과 ‘즉각적인 가치 제공’이 있었습니다. 복잡한 설정 과정이나 방대한 매뉴얼이 필요한 도구는 아무리 성능이 좋아도 동료들의 선택을 받기 어렵습니다. 펄사는 사용자가 설치하고 가치를 느끼기까지의 시간을 최소화하는 데 집중했습니다.

기술적으로 펄사는 과잉 설계(Over-engineering)를 경계했습니다. 확장성을 위해 미리 구축해둔 복잡한 아키텍처 대신, 현재의 문제를 해결하는 가장 빠른 경로를 택했습니다. 이는 역설적으로 다른 부서 사람들이 도구를 이해하고 자신의 업무에 적용하는 속도를 높였습니다. 기술적 완결성보다 ‘사용성’이라는 실질적인 가치에 우선순위를 둔 전략이 적중한 것입니다.

예상치 못한 확산: 개발팀에서 재무팀까지

흥미로운 점은 펄사가 개발팀의 전유물로 남지 않았다는 것입니다. 인사(HR), 재무, 마케팅 부서까지 이 도구를 사용하기 시작했다는 사실은 시사하는 바가 큽니다. 비개발 직군이 기술 도구를 도입할 때 가장 중요하게 생각하는 것은 ‘내 업무 시간이 단축되는가’입니다. 펄사는 특정 직군에 특화된 기능이 아니라, 데이터의 흐름을 관리하거나 반복적인 작업을 자동화하는 ‘범용적인 불편함’을 해결했습니다.

이러한 확산 과정은 다음과 같은 단계로 진행되었습니다.

• 1단계: 개발자 본인의 생산성 향상 (개인적 가치 증명)
• 2단계: 옆자리 동료의 호기심과 전파 (소규모 신뢰 기반 확산)
• 3단계: 타 부서와의 협업 과정에서 도구의 효용성 노출 (교차 부서 확산)
• 4단계: 공식적인 업무 프로세스에 편입 (조직적 표준화)

펄사 모델의 장단점 분석

이러한 ‘우연한 성공’ 모델이 모든 프로젝트에 적용될 수 있을까요? 펄사의 사례를 통해 본 장점과 위험 요소는 명확합니다.

실무자를 위한 액션 아이템: 당신의 ‘펄사’를 만드는 법

모든 사이드 프로젝트가 전사 표준이 될 수는 없지만, 성공 확률을 높이는 방법은 있습니다. 단순히 코드를 짜는 것이 아니라 ‘제품’을 만드는 관점으로 접근해야 합니다.

1. ‘가장 작은 불편함’부터 해결하라

거대한 시스템을 구축하려 하지 마십시오. 매일 반복하는 5분짜리 작업, 엑셀에서 수동으로 옮기는 데이터 하나 등 아주 작은 불편함에 집중하십시오. 해결책이 작을수록 사용자가 느끼는 심리적 진입장벽은 낮아집니다.

2. ‘도그푸딩’을 강제하라

남을 위해 만들지 말고 나를 위해 만드십시오. 내가 매일 쓰지 않는 도구는 절대 남도 쓰지 않습니다. 스스로가 가장 열렬한 사용자가 되었을 때, 비로소 다른 사람을 설득할 수 있는 진정성 있는 기능이 나옵니다.

3. 공유의 시점을 앞당겨라

완벽해질 때까지 기다리지 마십시오. 80% 정도 완성되었다고 느낄 때, 가장 친한 동료 한 명에게 슬쩍 보여주십시오. “이거 써보니까 편하던데, 너도 한번 써볼래?”라는 가벼운 제안이 거창한 프레젠테이션보다 훨씬 강력한 전파력을 가집니다.

4. 피드백을 기능으로 즉시 전환하라

동료가 “이런 기능이 있으면 좋겠다”고 말하는 순간이 바로 제품이 성장하는 골든타임입니다. 사이드 프로젝트의 최대 강점은 빠른 수정입니다. 피드백을 받은 즉시 반영하여 ‘내 의견이 반영되는 도구’라는 경험을 사용자에게 제공하십시오.

결국 펄사의 성공은 기술력의 승리가 아니라 ‘공감’의 승리입니다. 사용자가 무엇을 원하는지 묻지 않고, 사용자의 고통을 함께 느끼며 만든 도구는 결코 레포 선반 위에서 먼지를 뒤집어쓰지 않습니다. 지금 당신의 깃허브에 잠들어 있는 프로젝트가 있다면, 그것을 다시 꺼내 당신의 일상에 적용해 보십시오. 그 작은 시도가 조직 전체의 문화를 바꾸는 시작점이 될지도 모릅니다.